From Adam.Lewis@motorolasolutions.com Fri Jun 1 07:00:34 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD2F511E818E for ; Fri, 1 Jun 2012 07:00:34 -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 s1y88Ki0QrMX for ; Fri, 1 Jun 2012 07:00:33 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe001.messaging.microsoft.com [216.32.180.11]) by ietfa.amsl.com (Postfix) with ESMTP id 5B7F311E8189 for ; Fri, 1 Jun 2012 07:00:29 -0700 (PDT) Received: from mail102-va3-R.bigfish.com (10.7.14.243) by VA3EHSOBE008.bigfish.com (10.7.40.28) with Microsoft SMTP Server id 14.1.225.23; Fri, 1 Jun 2012 13:59:55 +0000 Received: from mail102-va3 (localhost [127.0.0.1]) by mail102-va3-R.bigfish.com (Postfix) with ESMTP id 9D073E0191 for ; Fri, 1 Jun 2012 13:59:45 +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: -1 X-BigFish: VPS-1(zzc85fh14ffIzz1202hzz8275bh8275dhz2fh2a8h683h839hd25hf0ah) Received-SPF: pass (mail102-va3: 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.244.181; KIP:(null); UIP:(null); (null); H:CH1PRD0410HT001.namprd04.prod.outlook.com; R:internal; EFV:INT Received: from mail102-va3 (localhost.localdomain [127.0.0.1]) by mail102-va3 (MessageSwitch) id 1338559182676069_29244; Fri, 1 Jun 2012 13:59:42 +0000 (UTC) Received: from VA3EHSMHS028.bigfish.com (unknown [10.7.14.254]) by mail102-va3.bigfish.com (Postfix) with ESMTP id A367B20057 for ; Fri, 1 Jun 2012 13:59:42 +0000 (UTC) Received: from il06msg01.mot-solutions.com (129.188.136.17) by VA3EHSMHS028.bigfish.com (10.7.99.38) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 1 Jun 2012 13:59:40 +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 q51Ej7II025840 for ; Fri, 1 Jun 2012 09:45:07 -0500 (CDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by il06msg01.mot-solutions.com (8.14.3/8.14.3) with ESMTP id q51Ej6sF025834 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 1 Jun 2012 09:45:07 -0500 (CDT) Received: from mail146-tx2-R.bigfish.com (10.9.14.239) by TX2EHSOBE006.bigfish.com (10.9.40.26) with Microsoft SMTP Server id 14.1.225.23; Fri, 1 Jun 2012 13:59:39 +0000 Received: from mail146-tx2 (localhost [127.0.0.1]) by mail146-tx2-R.bigfish.com (Postfix) with ESMTP id 42A8B4E03F7 for ; Fri, 1 Jun 2012 13:59:39 +0000 (UTC) Received: from mail146-tx2 (localhost.localdomain [127.0.0.1]) by mail146-tx2 (MessageSwitch) id 1338559177383874_979; Fri, 1 Jun 2012 13:59:37 +0000 (UTC) Received: from TX2EHSMHS026.bigfish.com (unknown [10.9.14.242]) by mail146-tx2.bigfish.com (Postfix) with ESMTP id 5AF5E320046 for ; Fri, 1 Jun 2012 13:59:37 +0000 (UTC) Received: from CH1PRD0410HT001.namprd04.prod.outlook.com (157.56.244.181) by TX2EHSMHS026.bigfish.com (10.9.99.126) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 1 Jun 2012 13:59:35 +0000 Received: from CH1PRD0410MB369.namprd04.prod.outlook.com ([169.254.5.147]) by CH1PRD0410HT001.namprd04.prod.outlook.com ([10.255.147.36]) with mapi id 14.16.0164.004; Fri, 1 Jun 2012 13:59:58 +0000 From: Lewis Adam-CAL022 To: "oauth@ietf.org" Thread-Topic: Inter-domain AS/RS communication (revisited) Thread-Index: Ac0//shvo0aY+zEHTyGf4RWqCiwctQ== Date: Fri, 1 Jun 2012 13:59:57 +0000 Message-ID: <59E470B10C4630419ED717AC79FCF9A90AECF419@CH1PRD0410MB369.namprd04.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [150.130.24.145] Content-Type: multipart/alternative; boundary="_000_59E470B10C4630419ED717AC79FCF9A90AECF419CH1PRD0410MB369_" MIME-Version: 1.0 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: CH1PRD0410HT001.namprd04.prod.outlook.com X-MS-Exchange-CrossPremises-SCL: -1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-rules-execution-history: Sample Spam Submissions X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-MS-Exchange-CrossPremises-ContentConversionOptions: False; 00160000; True; ; iso-8859-1 X-OrganizationHeadersPreserved: CH1PRD0410HT001.namprd04.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$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: [OAUTH-WG] Inter-domain AS/RS communication (revisited) X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 14:00:35 -0000 --_000_59E470B10C4630419ED717AC79FCF9A90AECF419CH1PRD0410MB369_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I've asked about the lack of standardization of the AS-RS interface in the = past, but I have a new twist on my question. What is the viability of perf= orming user "authentication" using OAuth with an RS in domain-1, and a whol= e bunch of AS's in different domains (assuming that the RS and AS is of the= same implementation)? RS (domain-1) AS-1 AS-2 AS-3 AS-4 AS-5 AS-6 AS-n Let me explain a bit further. I have a RS in domain-1 which exposes an API= , which is accessed by a native client, with users from (for example) 12 di= fferent domains. (Note: both the RS and native clients are of the same ven= dor implementation). Each of the 12 user domains has an AS, of the same im= plementation as the RS in domain-1. I'm thinking that native client users = from domain X should be able to authenticate to the AS in their home domain= using some primary authentication means, obtain an unstructured access-tok= en, and present that access-token to the RS in domain-1. Because they are = all of the same implementation, the RS in domain-1 should be able to make a= RESTful API call to the AS in domain X to obtain a JSON structure, contain= ing among other things, the user's name, and possibly other attributes. He= nce secondary authentication has been realized. This seems to work, but is this within the spirit of OAuth, or have I gone = off into LaLa land? We have looked at using the SAML bearer assertion prof= ile for OAuth, but we do a lot over wireless links, many of which are bandw= idth anemic, and the overhead of obtaining the SAML assertion and sending i= t are making me a bit squeamish. OAuth is attractive because of its light = weight-ness. Is the usage I'm proposing of OAuth (above) something that wo= uld be within the overall spirit of the OAuth framework? Tx! adam --_000_59E470B10C4630419ED717AC79FCF9A90AECF419CH1PRD0410MB369_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,<= /span>

 

I’ve asked ab= out the lack of standardization of the AS-RS interface in the past, but I h= ave a new twist on my question.  What is the viability of performing u= ser “authentication” using OAuth with an RS in domain-1, and a whole bunch of AS’s in different domains (assuming t= hat the RS and AS is of the same implementation)?

 

   &= nbsp;        RS (domain-1)

 

AS-1  &nb= sp;  AS-2     AS-3     AS-4&nb= sp;    AS-5     AS-6   &n= bsp; AS-n

 

Let me explain a bi= t further.  I have a RS in domain-1 which exposes an API, which is acc= essed by a native client, with users from (for example) 12 different domain= s.  (Note: both the RS and native clients are of the same vendor implementation).  Each of the 12 user domains = has an AS, of the same implementation as the RS in domain-1.  I’= m thinking that native client users from domain X should be able to authent= icate to the AS in their home domain using some primary authentication means, obtain an unstructured access-token, and pre= sent that access-token to the RS in domain-1.  Because they are all of= the same implementation, the RS in domain-1 should be able to make a RESTf= ul API call to the AS in domain X to obtain a JSON structure, containing among other things, the user’s n= ame, and possibly other attributes.  Hence secondary authentication ha= s been realized. 

 

This seems to work,= but is this within the spirit of OAuth, or have I gone off into LaLa land?=   We have looked at using the SAML bearer assertion profile for OAuth,= but we do a lot over wireless links, many of which are bandwidth anemic, and the overhead of obtaining the SAML asse= rtion and sending it are making me a bit squeamish.  OAuth is attracti= ve because of its light weight-ness.  Is the usage I’m proposing= of OAuth (above) something that would be within the overall spirit of the OAuth framework? 

 

Tx!
adam

--_000_59E470B10C4630419ED717AC79FCF9A90AECF419CH1PRD0410MB369_-- From James.H.Manger@team.telstra.com Fri Jun 1 07:33:06 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F01FE11E8174 for ; Fri, 1 Jun 2012 07:33:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.731 X-Spam-Level: X-Spam-Status: No, score=-0.731 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0VbJhcacSUZF for ; Fri, 1 Jun 2012 07:33:05 -0700 (PDT) Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by ietfa.amsl.com (Postfix) with ESMTP id 1983B11E80B0 for ; Fri, 1 Jun 2012 07:33:04 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,699,1330866000"; d="scan'208";a="76369089" Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipobvi.tcif.telstra.com.au with ESMTP; 02 Jun 2012 00:33:04 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6728"; a="66355183" Received: from wsmsg3751.srv.dir.telstra.com ([172.49.40.172]) by ipcdvi.tcif.telstra.com.au with ESMTP; 02 Jun 2012 00:33:01 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3751.srv.dir.telstra.com ([172.49.40.172]) with mapi; Sat, 2 Jun 2012 00:33:02 +1000 From: "Manger, James H" To: "adam.lewis@motorolasolutions.com" , "oauth@ietf.org" Date: Sat, 2 Jun 2012 00:33:02 +1000 Thread-Topic: [OAUTH-WG] Inter-domain AS/RS communication (revisited) Thread-Index: AQHNQANzysANC13Dq06SA9LuCnN8/A== Message-ID: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Inter-domain AS/RS communication (revisited) X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 14:33:06 -0000 Adam, You are describing OpenID Connect. -- James Manger ----- Reply message ----- From: "Lewis Adam-CAL022" Date: Sat, Jun 2, 2012 12:00 am Subject: [OAUTH-WG] Inter-domain AS/RS communication (revisited) To: "oauth@ietf.org" Hi all, I=92ve asked about the lack of standardization of the AS-RS interface in th= e past, but I have a new twist on my question. What is the viability of pe= rforming user =93authentication=94 using OAuth with an RS in domain-1, and = a whole bunch of AS=92s in different domains (assuming that the RS and AS i= s of the same implementation)? RS (domain-1) AS-1 AS-2 AS-3 AS-4 AS-5 AS-6 AS-n Let me explain a bit further. I have a RS in domain-1 which exposes an API= , which is accessed by a native client, with users from (for example) 12 di= fferent domains. (Note: both the RS and native clients are of the same ven= dor implementation). Each of the 12 user domains has an AS, of the same im= plementation as the RS in domain-1. I=92m thinking that native client user= s from domain X should be able to authenticate to the AS in their home doma= in using some primary authentication means, obtain an unstructured access-t= oken, and present that access-token to the RS in domain-1. Because they ar= e all of the same implementation, the RS in domain-1 should be able to make= a RESTful API call to the AS in domain X to obtain a JSON structure, conta= ining among other things, the user=92s name, and possibly other attributes.= Hence secondary authentication has been realized. This seems to work, but is this within the spirit of OAuth, or have I gone = off into LaLa land? We have looked at using the SAML bearer assertion prof= ile for OAuth, but we do a lot over wireless links, many of which are bandw= idth anemic, and the overhead of obtaining the SAML assertion and sending i= t are making me a bit squeamish. OAuth is attractive because of its light = weight-ness. Is the usage I=92m proposing of OAuth (above) something that = would be within the overall spirit of the OAuth framework? Tx! adam From jricher@mitre.org Fri Jun 1 08:00:27 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AB4B11E818A for ; Fri, 1 Jun 2012 08:00:27 -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 fKyciKMvw1MS for ; Fri, 1 Jun 2012 08:00:26 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 4478311E81A3 for ; Fri, 1 Jun 2012 08:00:26 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 837DF21B1D2B; Fri, 1 Jun 2012 11:00:25 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 325F021B1D21; Fri, 1 Jun 2012 11:00:25 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.227]) by IMCCAS01.MITRE.ORG ([129.83.29.78]) with mapi id 14.02.0283.003; Fri, 1 Jun 2012 11:00:25 -0400 From: "Richer, Justin P." To: "Manger, James H" Thread-Topic: [OAUTH-WG] Inter-domain AS/RS communication (revisited) Thread-Index: AQHNQANzysANC13Dq06SA9LuCnN8/Jbl0ZAA Date: Fri, 1 Jun 2012 15:00:24 +0000 Message-ID: <19000680-251A-4C0F-B287-B17E5A0F8720@mitre.org> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.13.161] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Inter-domain AS/RS communication (revisited) X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 15:00:27 -0000 More specifically, OpenID Connect with the addition of reusing the access_t= oken provided by the AS to get at other API services. This capability is ex= plicitly encouraged in Connect since it directly re-uses the OAuth2 infrast= ructure and tokens to do the identity protocol. -- Justin On Jun 1, 2012, at 10:33 AM, Manger, James H wrote: > Adam, >=20 > You are describing OpenID Connect. >=20 > -- > James Manger >=20 > ----- Reply message ----- > From: "Lewis Adam-CAL022" > Date: Sat, Jun 2, 2012 12:00 am > Subject: [OAUTH-WG] Inter-domain AS/RS communication (revisited) > To: "oauth@ietf.org" >=20 > Hi all, >=20 > I=92ve asked about the lack of standardization of the AS-RS interface in = the past, but I have a new twist on my question. What is the viability of = performing user =93authentication=94 using OAuth with an RS in domain-1, an= d a whole bunch of AS=92s in different domains (assuming that the RS and AS= is of the same implementation)? >=20 > RS (domain-1) >=20 > AS-1 AS-2 AS-3 AS-4 AS-5 AS-6 AS-n >=20 > Let me explain a bit further. I have a RS in domain-1 which exposes an A= PI, which is accessed by a native client, with users from (for example) 12 = different domains. (Note: both the RS and native clients are of the same v= endor implementation). Each of the 12 user domains has an AS, of the same = implementation as the RS in domain-1. I=92m thinking that native client us= ers from domain X should be able to authenticate to the AS in their home do= main using some primary authentication means, obtain an unstructured access= -token, and present that access-token to the RS in domain-1. Because they = are all of the same implementation, the RS in domain-1 should be able to ma= ke a RESTful API call to the AS in domain X to obtain a JSON structure, con= taining among other things, the user=92s name, and possibly other attribute= s. Hence secondary authentication has been realized. >=20 > This seems to work, but is this within the spirit of OAuth, or have I gon= e off into LaLa land? We have looked at using the SAML bearer assertion pr= ofile for OAuth, but we do a lot over wireless links, many of which are ban= dwidth anemic, and the overhead of obtaining the SAML assertion and sending= it are making me a bit squeamish. OAuth is attractive because of its ligh= t weight-ness. Is the usage I=92m proposing of OAuth (above) something tha= t would be within the overall spirit of the OAuth framework? >=20 > Tx! > adam > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From Adam.Lewis@motorolasolutions.com Fri Jun 1 09:19:51 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D17521F8A42 for ; Fri, 1 Jun 2012 09:19:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.967 X-Spam-Level: X-Spam-Status: No, score=-1.967 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, 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 4kVrZIQlbhFH for ; Fri, 1 Jun 2012 09:19:51 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe006.messaging.microsoft.com [216.32.180.16]) by ietfa.amsl.com (Postfix) with ESMTP id 70B9821F8A41 for ; Fri, 1 Jun 2012 09:19:49 -0700 (PDT) Received: from mail113-va3-R.bigfish.com (10.7.14.251) by VA3EHSOBE001.bigfish.com (10.7.40.21) with Microsoft SMTP Server id 14.1.225.23; Fri, 1 Jun 2012 16:19:17 +0000 Received: from mail113-va3 (localhost [127.0.0.1]) by mail113-va3-R.bigfish.com (Postfix) with ESMTP id 46E2A18009B for ; Fri, 1 Jun 2012 16:19:00 +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: -36 X-BigFish: VPS-36(zz9371I14ffI542M1432N98dKzz1202hzz1033IL8275bh8275dhz2fh2a8h683h839h944hd25hf0ah) Received-SPF: pass (mail113-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.244.181; KIP:(null); UIP:(null); (null); H:CH1PRD0410HT005.namprd04.prod.outlook.com; R:internal; EFV:INT Received: from mail113-va3 (localhost.localdomain [127.0.0.1]) by mail113-va3 (MessageSwitch) id 1338567531332099_25213; Fri, 1 Jun 2012 16:18:51 +0000 (UTC) Received: from VA3EHSMHS032.bigfish.com (unknown [10.7.14.240]) by mail113-va3.bigfish.com (Postfix) with ESMTP id 4851F360045 for ; Fri, 1 Jun 2012 16:18:51 +0000 (UTC) Received: from ct11msg02.am.mot-solutions.com (192.160.210.14) by VA3EHSMHS032.bigfish.com (10.7.99.42) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 1 Jun 2012 16:18:49 +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 q51GN7a3002550 for ; Fri, 1 Jun 2012 12:23:07 -0400 (EDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe005.messaging.microsoft.com [65.55.88.15]) by ct11msg02.am.mot-solutions.com (8.14.3/8.14.3) with ESMTP id q51GN6uP002547 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 1 Jun 2012 12:23:06 -0400 (EDT) Received: from mail187-tx2-R.bigfish.com (10.9.14.238) by TX2EHSOBE010.bigfish.com (10.9.40.30) with Microsoft SMTP Server id 14.1.225.23; Fri, 1 Jun 2012 16:18:47 +0000 Received: from mail187-tx2 (localhost [127.0.0.1]) by mail187-tx2-R.bigfish.com (Postfix) with ESMTP id 310C260159 for ; Fri, 1 Jun 2012 16:18:47 +0000 (UTC) Received: from mail187-tx2 (localhost.localdomain [127.0.0.1]) by mail187-tx2 (MessageSwitch) id 1338567516223712_10416; Fri, 1 Jun 2012 16:18:36 +0000 (UTC) Received: from TX2EHSMHS037.bigfish.com (unknown [10.9.14.249]) by mail187-tx2.bigfish.com (Postfix) with ESMTP id 241FC320047; Fri, 1 Jun 2012 16:18:36 +0000 (UTC) Received: from CH1PRD0410HT005.namprd04.prod.outlook.com (157.56.244.181) by TX2EHSMHS037.bigfish.com (10.9.99.137) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 1 Jun 2012 16:18:34 +0000 Received: from CH1PRD0410MB369.namprd04.prod.outlook.com ([169.254.5.147]) by CH1PRD0410HT005.namprd04.prod.outlook.com ([10.255.147.40]) with mapi id 14.16.0152.000; Fri, 1 Jun 2012 16:19:04 +0000 From: Lewis Adam-CAL022 To: "Richer, Justin P." , "Manger, James H" Thread-Topic: [OAUTH-WG] Inter-domain AS/RS communication (revisited) Thread-Index: AQHNQANzysANC13Dq06SA9LuCnN8/Jbl0ZAA///QszA= Date: Fri, 1 Jun 2012 16:19:03 +0000 Message-ID: <59E470B10C4630419ED717AC79FCF9A90AECF4B6@CH1PRD0410MB369.namprd04.prod.outlook.com> References: <19000680-251A-4C0F-B287-B17E5A0F8720@mitre.org> In-Reply-To: <19000680-251A-4C0F-B287-B17E5A0F8720@mitre.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [150.130.24.145] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: CH1PRD0410HT005.namprd04.prod.outlook.com X-MS-Exchange-CrossPremises-SCL: -1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-rules-execution-history: Sample Spam Submissions X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-MS-Exchange-CrossPremises-ContentConversionOptions: False; 00160000; True; ; iso-8859-1 X-OrganizationHeadersPreserved: CH1PRD0410HT005.namprd04.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%1294$Dn%MITRE.ORG$RO%2$TLS%3$FQDN%msgate.mot-solutions.com$TlsDn% X-FOPE-CONNECTOR: Id%1294$Dn%TEAM.TELSTRA.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] Inter-domain AS/RS communication (revisited) X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 16:19:51 -0000 Maybe I'm getting confused over the terminology. Connect speaks of a clien= t talking to a CheckID endpoint or UserInfo endpoint. Is the RS acting as = the client in this case? I'm actually looking at your famous PDF diagrams Justin, and it looks like = the client is in all cases the same client. E.g. the client that asks for = the access token is the same client performs the UserInfo request or CheckI= D request. In my mind, I want the client to get the access-token and prese= nt it to the RS, and then I want the RS to perform the UserInfo request or = CheckID request. =20 So if you're telling me that the RS is acting as the client, and the RS can= perform the UserInfo request or CheckID request, then I get it. But it wa= sn't obvious from the spec. =20 Tx! adam -----Original Message----- From: Richer, Justin P. [mailto:jricher@mitre.org]=20 Sent: Friday, June 01, 2012 10:00 AM To: Manger, James H Cc: Lewis Adam-CAL022; oauth@ietf.org Subject: Re: [OAUTH-WG] Inter-domain AS/RS communication (revisited) More specifically, OpenID Connect with the addition of reusing the access_t= oken provided by the AS to get at other API services. This capability is ex= plicitly encouraged in Connect since it directly re-uses the OAuth2 infrast= ructure and tokens to do the identity protocol. -- Justin On Jun 1, 2012, at 10:33 AM, Manger, James H wrote: > Adam, >=20 > You are describing OpenID Connect. >=20 > -- > James Manger >=20 > ----- Reply message ----- > From: "Lewis Adam-CAL022" > Date: Sat, Jun 2, 2012 12:00 am > Subject: [OAUTH-WG] Inter-domain AS/RS communication (revisited) > To: "oauth@ietf.org" >=20 > Hi all, >=20 > I've asked about the lack of standardization of the AS-RS interface in th= e past, but I have a new twist on my question. What is the viability of pe= rforming user "authentication" using OAuth with an RS in domain-1, and a wh= ole bunch of AS's in different domains (assuming that the RS and AS is of t= he same implementation)? >=20 > RS (domain-1) >=20 > AS-1 AS-2 AS-3 AS-4 AS-5 AS-6 AS-n >=20 > Let me explain a bit further. I have a RS in domain-1 which exposes an A= PI, which is accessed by a native client, with users from (for example) 12 = different domains. (Note: both the RS and native clients are of the same v= endor implementation). Each of the 12 user domains has an AS, of the same = implementation as the RS in domain-1. I'm thinking that native client user= s from domain X should be able to authenticate to the AS in their home doma= in using some primary authentication means, obtain an unstructured access-t= oken, and present that access-token to the RS in domain-1. Because they ar= e all of the same implementation, the RS in domain-1 should be able to make= a RESTful API call to the AS in domain X to obtain a JSON structure, conta= ining among other things, the user's name, and possibly other attributes. = Hence secondary authentication has been realized. >=20 > This seems to work, but is this within the spirit of OAuth, or have I gon= e off into LaLa land? We have looked at using the SAML bearer assertion pr= ofile for OAuth, but we do a lot over wireless links, many of which are ban= dwidth anemic, and the overhead of obtaining the SAML assertion and sending= it are making me a bit squeamish. OAuth is attractive because of its ligh= t weight-ness. Is the usage I'm proposing of OAuth (above) something that = would be within the overall spirit of the OAuth framework? >=20 > Tx! > adam > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From gffletch@aol.com Fri Jun 1 12:34:00 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB4A411E808A for ; Fri, 1 Jun 2012 12:34:00 -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 9qfdNDU98Xy4 for ; Fri, 1 Jun 2012 12:33:58 -0700 (PDT) Received: from imr-ma01.mx.aol.com (imr-ma01.mx.aol.com [64.12.206.39]) by ietfa.amsl.com (Postfix) with ESMTP id 7DF3411E8138 for ; Fri, 1 Jun 2012 12:33:58 -0700 (PDT) Received: from mtaout-mb06.r1000.mx.aol.com (mtaout-mb06.r1000.mx.aol.com [172.29.41.70]) by imr-ma01.mx.aol.com (8.14.1/8.14.1) with ESMTP id q51JXcGW025565; Fri, 1 Jun 2012 15:33:38 -0400 Received: from palantir.office.aol.com (palantir.office.aol.com [10.181.186.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout-mb06.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id BCB99E0000F6; Fri, 1 Jun 2012 15:33:37 -0400 (EDT) Message-ID: <4FC91911.1040901@aol.com> Date: Fri, 01 Jun 2012 15:33:37 -0400 From: George Fletcher Organization: AOL LLC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Lewis Adam-CAL022 References: <59E470B10C4630419ED717AC79FCF9A90AECF419@CH1PRD0410MB369.namprd04.prod.outlook.com> In-Reply-To: <59E470B10C4630419ED717AC79FCF9A90AECF419@CH1PRD0410MB369.namprd04.prod.outlook.com> Content-Type: multipart/alternative; boundary="------------050700000503090009030107" x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20110426; t=1338579218; bh=43k6xvnVcqpYRWtjjWs+heaibFHIPVAORj2hCZy8zWU=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=hzWgy/sR3VWgzs1oWhGFidnbjPXkbi3h+wuXCtDOGxLU3ee6j5oDmOcGZrRXv0M8U biKkPSUZ40VA/U1iphBrYkKsPW/akuw4kHWwLXj7yiSdGmxE0RIDQ8eJ+WhqZNjtZ9 4kqkttlW8rGvzZEV1Lmk9oVRD6N/lOeFnAGC4leY= X-AOL-SCOLL-SCORE: 0:2:461975840:93952408 X-AOL-SCOLL-URL_COUNT: 0 x-aol-sid: 3039ac1d29464fc919113277 X-AOL-IP: 10.181.186.254 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Inter-domain AS/RS communication (revisited) X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 19:34:00 -0000 This is a multi-part message in MIME format. --------------050700000503090009030107 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I'm not sure why the dependency on the "unstructured token". You can have a small "structured" token which provides some additional capabilities. That said, as long as the RS can determine "which" AS the token came from, this solutions works well. I believe a few other implementations use a similar solution. I consider this definitely within the spirit of OAuth:) We chose to use structured tokens (JWS) which allowed us to specify the URL of the AS as well as a user identifier and some other data. Thanks, George On 6/1/12 9:59 AM, Lewis Adam-CAL022 wrote: > > Hi all, > > I've asked about the lack of standardization of the AS-RS interface in > the past, but I have a new twist on my question. What is the > viability of performing user "authentication" using OAuth with an RS > in domain-1, and a whole bunch of AS's in different domains (assuming > that the RS and AS is of the same implementation)? > > RS (domain-1) > > AS-1 AS-2 AS-3 AS-4 AS-5 AS-6 AS-n > > Let me explain a bit further. I have a RS in domain-1 which exposes > an API, which is accessed by a native client, with users from (for > example) 12 different domains. (Note: both the RS and native clients > are of the same vendor implementation). Each of the 12 user domains > has an AS, of the same implementation as the RS in domain-1. I'm > thinking that native client users from domain X should be able to > authenticate to the AS in their home domain using some primary > authentication means, obtain an unstructured access-token, and present > that access-token to the RS in domain-1. Because they are all of the > same implementation, the RS in domain-1 should be able to make a > RESTful API call to the AS in domain X to obtain a JSON structure, > containing among other things, the user's name, and possibly other > attributes. Hence secondary authentication has been realized. > > This seems to work, but is this within the spirit of OAuth, or have I > gone off into LaLa land? We have looked at using the SAML bearer > assertion profile for OAuth, but we do a lot over wireless links, many > of which are bandwidth anemic, and the overhead of obtaining the SAML > assertion and sending it are making me a bit squeamish. OAuth is > attractive because of its light weight-ness. Is the usage I'm > proposing of OAuth (above) something that would be within the overall > spirit of the OAuth framework? > > Tx! > adam > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------050700000503090009030107 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I'm not sure why the dependency on the "unstructured token". You can have a small "structured" token which provides some additional capabilities.

That said, as long as the RS can determine "which" AS the token came from, this solutions works well. I believe a few other implementations use a similar solution. I consider this definitely within the spirit of OAuth:)

We chose to use structured tokens (JWS) which allowed us to specify the URL of the AS as well as a user identifier and some other data.

Thanks,
George

On 6/1/12 9:59 AM, Lewis Adam-CAL022 wrote:

Hi all,

 

I’ve asked about the lack of standardization of the AS-RS interface in the past, but I have a new twist on my question.  What is the viability of performing user “authentication” using OAuth with an RS in domain-1, and a whole bunch of AS’s in different domains (assuming that the RS and AS is of the same implementation)?

 

            RS (domain-1)

 

AS-1     AS-2     AS-3     AS-4     AS-5     AS-6     AS-n

 

Let me explain a bit further.  I have a RS in domain-1 which exposes an API, which is accessed by a native client, with users from (for example) 12 different domains.  (Note: both the RS and native clients are of the same vendor implementation).  Each of the 12 user domains has an AS, of the same implementation as the RS in domain-1.  I’m thinking that native client users from domain X should be able to authenticate to the AS in their home domain using some primary authentication means, obtain an unstructured access-token, and present that access-token to the RS in domain-1.  Because they are all of the same implementation, the RS in domain-1 should be able to make a RESTful API call to the AS in domain X to obtain a JSON structure, containing among other things, the user’s name, and possibly other attributes.  Hence secondary authentication has been realized. 

 

This seems to work, but is this within the spirit of OAuth, or have I gone off into LaLa land?  We have looked at using the SAML bearer assertion profile for OAuth, but we do a lot over wireless links, many of which are bandwidth anemic, and the overhead of obtaining the SAML assertion and sending it are making me a bit squeamish.  OAuth is attractive because of its light weight-ness.  Is the usage I’m proposing of OAuth (above) something that would be within the overall spirit of the OAuth framework? 

 

Tx!
adam



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

--------------050700000503090009030107-- From Adam.Lewis@motorolasolutions.com Fri Jun 1 12:41:10 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 963A611E80E2 for ; Fri, 1 Jun 2012 12:41:10 -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 14cEVGSKF0GW for ; Fri, 1 Jun 2012 12:41:08 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe006.messaging.microsoft.com [213.199.154.209]) by ietfa.amsl.com (Postfix) with ESMTP id 6BFF011E80CC for ; Fri, 1 Jun 2012 12:41:07 -0700 (PDT) Received: from mail112-am1-R.bigfish.com (10.3.201.254) by AM1EHSOBE003.bigfish.com (10.3.204.23) with Microsoft SMTP Server id 14.1.225.23; Fri, 1 Jun 2012 19:40:35 +0000 Received: from mail112-am1 (localhost [127.0.0.1]) by mail112-am1-R.bigfish.com (Postfix) with ESMTP id D2F2C3E04DA for ; Fri, 1 Jun 2012 19:40:34 +0000 (UTC) X-Forefront-Antispam-Report: CIP:129.188.136.18; KIP:(null); UIP:(null); IPV:NLI; H:il06msg02.am.mot-solutions.com; RD:none; EFVD:NLI X-SpamScore: -27 X-BigFish: VPS-27(zzbb2dI9371Ic85fh14ffI98dK4015Izz1202hzz1033IL8275bh8275dhz2fh2a8h683h839hd25hf0ah) Received-SPF: pass (mail112-am1: domain of motorolasolutions.com designates 129.188.136.18 as permitted sender) client-ip=129.188.136.18; envelope-from=Adam.Lewis@motorolasolutions.com; helo=il06msg02.am.mot-solutions.com ; olutions.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.244.181; KIP:(null); UIP:(null); (null); H:CH1PRD0410HT004.namprd04.prod.outlook.com; R:internal; EFV:INT Received: from mail112-am1 (localhost.localdomain [127.0.0.1]) by mail112-am1 (MessageSwitch) id 1338579632264436_15434; Fri, 1 Jun 2012 19:40:32 +0000 (UTC) Received: from AM1EHSMHS003.bigfish.com (unknown [10.3.201.244]) by mail112-am1.bigfish.com (Postfix) with ESMTP id 351723C0048 for ; Fri, 1 Jun 2012 19:40:32 +0000 (UTC) Received: from il06msg02.am.mot-solutions.com (129.188.136.18) by AM1EHSMHS003.bigfish.com (10.3.207.103) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 1 Jun 2012 19:40:31 +0000 Received: from il06msg02.am.mot-solutions.com (il06vts02.mot.com [129.188.137.142]) by il06msg02.am.mot-solutions.com (8.14.3/8.14.3) with ESMTP id q51Jf0Fn009275 for ; Fri, 1 Jun 2012 15:41:00 -0400 (EDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by il06msg02.am.mot-solutions.com (8.14.3/8.14.3) with ESMTP id q51Jex9F009272 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 1 Jun 2012 15:41:00 -0400 (EDT) Received: from mail123-tx2-R.bigfish.com (10.9.14.252) by TX2EHSOBE002.bigfish.com (10.9.40.22) with Microsoft SMTP Server id 14.1.225.23; Fri, 1 Jun 2012 19:40:28 +0000 Received: from mail123-tx2 (localhost [127.0.0.1]) by mail123-tx2-R.bigfish.com (Postfix) with ESMTP id 3B2738039C for ; Fri, 1 Jun 2012 19:40:28 +0000 (UTC) Received: from mail123-tx2 (localhost.localdomain [127.0.0.1]) by mail123-tx2 (MessageSwitch) id 1338579626121659_21687; Fri, 1 Jun 2012 19:40:26 +0000 (UTC) Received: from TX2EHSMHS035.bigfish.com (unknown [10.9.14.243]) by mail123-tx2.bigfish.com (Postfix) with ESMTP id 15E333A0044; Fri, 1 Jun 2012 19:40:26 +0000 (UTC) Received: from CH1PRD0410HT004.namprd04.prod.outlook.com (157.56.244.181) by TX2EHSMHS035.bigfish.com (10.9.99.135) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 1 Jun 2012 19:40:24 +0000 Received: from CH1PRD0410MB369.namprd04.prod.outlook.com ([169.254.5.147]) by CH1PRD0410HT004.namprd04.prod.outlook.com ([10.255.147.39]) with mapi id 14.16.0152.000; Fri, 1 Jun 2012 19:40:51 +0000 From: Lewis Adam-CAL022 To: George Fletcher Thread-Topic: [OAUTH-WG] Inter-domain AS/RS communication (revisited) Thread-Index: AQHNQC2Js3zXXnf6mE6PtwajHKF1zJbl21/g Date: Fri, 1 Jun 2012 19:40:45 +0000 Message-ID: <59E470B10C4630419ED717AC79FCF9A90AECF4FA@CH1PRD0410MB369.namprd04.prod.outlook.com> References: <59E470B10C4630419ED717AC79FCF9A90AECF419@CH1PRD0410MB369.namprd04.prod.outlook.com> <4FC91911.1040901@aol.com> In-Reply-To: <4FC91911.1040901@aol.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [75.149.88.198] Content-Type: multipart/alternative; boundary="_000_59E470B10C4630419ED717AC79FCF9A90AECF4FACH1PRD0410MB369_" MIME-Version: 1.0 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: CH1PRD0410HT004.namprd04.prod.outlook.com X-MS-Exchange-CrossPremises-SCL: -1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-rules-execution-history: Sample Spam Submissions X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-MS-Exchange-CrossPremises-ContentConversionOptions: False; 00160000; True; ; iso-8859-1 X-OrganizationHeadersPreserved: CH1PRD0410HT004.namprd04.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%1294$Dn%AOL.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] Inter-domain AS/RS communication (revisited) X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 19:41:10 -0000 --_000_59E470B10C4630419ED717AC79FCF9A90AECF4FACH1PRD0410MB369_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable My inclination for unstructured tokens is the size (20-30 bytes). I have s= ome edge cases where my wireless bandwidth drops down to pathetically anemi= c rates, and every byte counts. Even the smallest JWT token that I was abl= e to come up with (containing relevant material) was around 478 bytes. Of = course if I had a JWT, then I might not even need to do the introspection a= t all. This would be interesting. In fact ... I originally started down a= JWT path, but found OAuth implementation that could return a structured JW= T access-token to be scarce. I could be misinformed though. -adam From: George Fletcher [mailto:gffletch@aol.com] Sent: Friday, June 01, 2012 2:34 PM To: Lewis Adam-CAL022 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Inter-domain AS/RS communication (revisited) I'm not sure why the dependency on the "unstructured token". You can have a= small "structured" token which provides some additional capabilities. That said, as long as the RS can determine "which" AS the token came from, = this solutions works well. I believe a few other implementations use a simi= lar solution. I consider this definitely within the spirit of OAuth:) We chose to use structured tokens (JWS) which allowed us to specify the URL= of the AS as well as a user identifier and some other data. Thanks, George On 6/1/12 9:59 AM, Lewis Adam-CAL022 wrote: Hi all, I've asked about the lack of standardization of the AS-RS interface in the = past, but I have a new twist on my question. What is the viability of perf= orming user "authentication" using OAuth with an RS in domain-1, and a whol= e bunch of AS's in different domains (assuming that the RS and AS is of the= same implementation)? RS (domain-1) AS-1 AS-2 AS-3 AS-4 AS-5 AS-6 AS-n Let me explain a bit further. I have a RS in domain-1 which exposes an API= , which is accessed by a native client, with users from (for example) 12 di= fferent domains. (Note: both the RS and native clients are of the same ven= dor implementation). Each of the 12 user domains has an AS, of the same im= plementation as the RS in domain-1. I'm thinking that native client users = from domain X should be able to authenticate to the AS in their home domain= using some primary authentication means, obtain an unstructured access-tok= en, and present that access-token to the RS in domain-1. Because they are = all of the same implementation, the RS in domain-1 should be able to make a= RESTful API call to the AS in domain X to obtain a JSON structure, contain= ing among other things, the user's name, and possibly other attributes. He= nce secondary authentication has been realized. This seems to work, but is this within the spirit of OAuth, or have I gone = off into LaLa land? We have looked at using the SAML bearer assertion prof= ile for OAuth, but we do a lot over wireless links, many of which are bandw= idth anemic, and the overhead of obtaining the SAML assertion and sending i= t are making me a bit squeamish. OAuth is attractive because of its light = weight-ness. Is the usage I'm proposing of OAuth (above) something that wo= uld be within the overall spirit of the OAuth framework? Tx! adam _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_59E470B10C4630419ED717AC79FCF9A90AECF4FACH1PRD0410MB369_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

&n= bsp;

My incl= ination for unstructured tokens is the size (20-30 bytes).  I have som= e edge cases where my wireless bandwidth drops down to pathetically anemic = rates, and every byte counts.  Even the smallest JWT token that I was able to come up with (containing relevant material) w= as around 478 bytes.  Of course if I had a JWT, then I might not even = need to do the introspection at all.  This would be interesting. = In fact … I originally started down a JWT path, but found OAuth implementation that could return a structured JWT access-t= oken to be scarce.  I could be misinformed though.

&n= bsp;

-adam

&n= bsp;

From: George Fletcher [mailto:gffletch@aol.com]
Sent: Friday, June 01, 2012 2:34 PM
To: Lewis Adam-CAL022
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Inter-domain AS/RS communication (revisited)=

 

I'm not sure why the dependency on the "unstructu= red token". You can have a small "structured" token which pr= ovides some additional capabilities.

That said, as long as the RS can determine "which" AS the token c= ame from, this solutions works well. I believe a few other implementations = use a similar solution. I consider this definitely within the spirit of OAu= th:)

We chose to use structured tokens (JWS) which allowed us to specify the URL= of the AS as well as a user identifier and some other data.

Thanks,
George

On 6/1/12 9:59 AM, Lewis Adam-CAL022 wrote:

Hi all,=

 <= /o:p>

I’ve asked ab= out the lack of standardization of the AS-RS interface in the past, but I h= ave a new twist on my question.  What is the viability of performing u= ser “authentication” using OAuth with an RS in domain-1, and a whole bunch of AS’s in different domains (assuming t= hat the RS and AS is of the same implementation)?

 <= /o:p>

   &= nbsp;        RS (domain-1)

 <= /o:p>

AS-1  &nb= sp;  AS-2     AS-3     AS-4&nb= sp;    AS-5     AS-6   &n= bsp; AS-n

 <= /o:p>

Let me explain a bi= t further.  I have a RS in domain-1 which exposes an API, which is acc= essed by a native client, with users from (for example) 12 different domain= s.  (Note: both the RS and native clients are of the same vendor implementation).  Each of the 12 user domains = has an AS, of the same implementation as the RS in domain-1.  I’= m thinking that native client users from domain X should be able to authent= icate to the AS in their home domain using some primary authentication means, obtain an unstructured access-token, and pre= sent that access-token to the RS in domain-1.  Because they are all of= the same implementation, the RS in domain-1 should be able to make a RESTf= ul API call to the AS in domain X to obtain a JSON structure, containing among other things, the user’s n= ame, and possibly other attributes.  Hence secondary authentication ha= s been realized. 

 <= /o:p>

This seems to work,= but is this within the spirit of OAuth, or have I gone off into LaLa land?=   We have looked at using the SAML bearer assertion profile for OAuth,= but we do a lot over wireless links, many of which are bandwidth anemic, and the overhead of obtaining the SAML asse= rtion and sending it are making me a bit squeamish.  OAuth is attracti= ve because of its light weight-ness.  Is the usage I’m proposing= of OAuth (above) something that would be within the overall spirit of the OAuth framework? 

 <= /o:p>

Tx!
adam




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

 

--_000_59E470B10C4630419ED717AC79FCF9A90AECF4FACH1PRD0410MB369_-- From jricher@mitre.org Fri Jun 1 13:00:29 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AAFB21F8838 for ; Fri, 1 Jun 2012 13:00:29 -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 hgstUIAK3fF4 for ; Fri, 1 Jun 2012 13:00:28 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 289C721F8833 for ; Fri, 1 Jun 2012 13:00:28 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 1788F21B1D9F; Fri, 1 Jun 2012 16:00:24 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 0729921B1D96; Fri, 1 Jun 2012 16:00:24 -0400 (EDT) Received: from [129.83.50.12] (129.83.31.51) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.2.283.3; Fri, 1 Jun 2012 16:00:23 -0400 Message-ID: <4FC91F57.9050103@mitre.org> Date: Fri, 1 Jun 2012 16:00:23 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Lewis Adam-CAL022 References: <19000680-251A-4C0F-B287-B17E5A0F8720@mitre.org> <59E470B10C4630419ED717AC79FCF9A90AECF4B6@CH1PRD0410MB369.namprd04.prod.outlook.com> In-Reply-To: <59E470B10C4630419ED717AC79FCF9A90AECF4B6@CH1PRD0410MB369.namprd04.prod.outlook.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [129.83.31.51] Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Inter-domain AS/RS communication (revisited) X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 20:00:29 -0000 First, I have to give proper credit to my colleague Amanda Anganes for making those flow diagrams (which I agree are pretty awesome -- when coding I refer to them as often as the spec text itself, personally). Yes, you have it right, in this case the RS is the client of the identity API from the AS, which looking back at your original question isn't quite what you were asking, so I apologize for the confusion there. Just so I have this straight: You have a client, C, making an OAuth protected call to service RS using a token that's been generated by one of a set of trusted authorization servers, AS1-AS12. So RS needs to figure out: 1) Is the token any good? 2) Is the token issued by someone I know? 3) What's the user information tied to the token? (name and stuff) If that's the case, there are a few ways to handle this, but one of the simplest is to make use of the bearer token principle and chain the service calls around a bit. Especially if your AS's all use a structured token format, like JWT, that can point to the issuer of the token (and therefore which AS spit it out in the first place). So in concrete terms: Client C calls AS1 and gets access token AT. AT is a JWT that has in its claims section {iss: AS1}, among others. C passes AT to RS to make its call. RS can inspect the JWT and discover the token was sent from AS1 (by the issuer field). RS knows that AS1 is in its list of trusted AS's. RS validates the signature on AT against the key from AS1 (which can be done using JWK). Now that the token is good, the RS can start to fulfill the client's request. The RS could also call what's being termed an "introspection endpoint" at AS1 to help it figure out what the token is good for (scopes, permissions, timeouts, etc) in fulfilling the client's request. But say RS needs user information like a name and email address and all that. Well, if the AS's are all doing OpenID Connect, which would still give you a valid access token, then the AS's will all *also* have a User Info Endpoint defined. The RS can send the AT to the UserInfo Endpoint to get the user's information from it in a simple JSON schema. You can alternatively use SCIM or PoCo formatted endpoints to accomplish much of the same stuff, all protected over OAuth. There are some more complicated methods, with the RS trading in the AT for its own subscoped AT for instance, but this is a basic and fairly functional usage scenario. Do you think this covers what you'd want to do with it? It's still about 80% vanilla OAuth2. -- Justin On 06/01/2012 12:19 PM, Lewis Adam-CAL022 wrote: > Maybe I'm getting confused over the terminology. Connect speaks of a client talking to a CheckID endpoint or UserInfo endpoint. Is the RS acting as the client in this case? > > I'm actually looking at your famous PDF diagrams Justin, and it looks like the client is in all cases the same client. E.g. the client that asks for the access token is the same client performs the UserInfo request or CheckID request. In my mind, I want the client to get the access-token and present it to the RS, and then I want the RS to perform the UserInfo request or CheckID request. > > So if you're telling me that the RS is acting as the client, and the RS can perform the UserInfo request or CheckID request, then I get it. But it wasn't obvious from the spec. > > > Tx! > adam > > > > > -----Original Message----- > From: Richer, Justin P. [mailto:jricher@mitre.org] > Sent: Friday, June 01, 2012 10:00 AM > To: Manger, James H > Cc: Lewis Adam-CAL022; oauth@ietf.org > Subject: Re: [OAUTH-WG] Inter-domain AS/RS communication (revisited) > > More specifically, OpenID Connect with the addition of reusing the access_token provided by the AS to get at other API services. This capability is explicitly encouraged in Connect since it directly re-uses the OAuth2 infrastructure and tokens to do the identity protocol. > > -- Justin > > On Jun 1, 2012, at 10:33 AM, Manger, James H wrote: > >> Adam, >> >> You are describing OpenID Connect. >> >> -- >> James Manger >> >> ----- Reply message ----- >> From: "Lewis Adam-CAL022" >> Date: Sat, Jun 2, 2012 12:00 am >> Subject: [OAUTH-WG] Inter-domain AS/RS communication (revisited) >> To: "oauth@ietf.org" >> >> Hi all, >> >> I've asked about the lack of standardization of the AS-RS interface in the past, but I have a new twist on my question. What is the viability of performing user "authentication" using OAuth with an RS in domain-1, and a whole bunch of AS's in different domains (assuming that the RS and AS is of the same implementation)? >> >> RS (domain-1) >> >> AS-1 AS-2 AS-3 AS-4 AS-5 AS-6 AS-n >> >> Let me explain a bit further. I have a RS in domain-1 which exposes an API, which is accessed by a native client, with users from (for example) 12 different domains. (Note: both the RS and native clients are of the same vendor implementation). Each of the 12 user domains has an AS, of the same implementation as the RS in domain-1. I'm thinking that native client users from domain X should be able to authenticate to the AS in their home domain using some primary authentication means, obtain an unstructured access-token, and present that access-token to the RS in domain-1. Because they are all of the same implementation, the RS in domain-1 should be able to make a RESTful API call to the AS in domain X to obtain a JSON structure, containing among other things, the user's name, and possibly other attributes. Hence secondary authentication has been realized. >> >> This seems to work, but is this within the spirit of OAuth, or have I gone off into LaLa land? We have looked at using the SAML bearer assertion profile for OAuth, but we do a lot over wireless links, many of which are bandwidth anemic, and the overhead of obtaining the SAML assertion and sending it are making me a bit squeamish. OAuth is attractive because of its light weight-ness. Is the usage I'm proposing of OAuth (above) something that would be within the overall spirit of the OAuth framework? >> >> Tx! >> adam >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > > > > From Adam.Lewis@motorolasolutions.com Fri Jun 1 13:17:22 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 343D511E8074 for ; Fri, 1 Jun 2012 13:17:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.467 X-Spam-Level: X-Spam-Status: No, score=-0.467 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, 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 QmDeyzboUFZC for ; Fri, 1 Jun 2012 13:17:21 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe001.messaging.microsoft.com [213.199.154.204]) by ietfa.amsl.com (Postfix) with ESMTP id C461C11E80C9 for ; Fri, 1 Jun 2012 13:17:20 -0700 (PDT) Received: from mail17-am1-R.bigfish.com (10.3.201.250) by AM1EHSOBE001.bigfish.com (10.3.204.21) with Microsoft SMTP Server id 14.1.225.23; Fri, 1 Jun 2012 20:16:48 +0000 Received: from mail17-am1 (localhost [127.0.0.1]) by mail17-am1-R.bigfish.com (Postfix) with ESMTP id E4484380386 for ; Fri, 1 Jun 2012 20:16:47 +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(zzbb2dI9371I14ffI542M1432N98dKzz1202hzz1033IL8275bh8275dhz2fh2a8h683h839h944hd25hf0ah) Received-SPF: pass (mail17-am1: 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.244.181; KIP:(null); UIP:(null); (null); H:CH1PRD0410HT005.namprd04.prod.outlook.com; R:internal; EFV:INT Received: from mail17-am1 (localhost.localdomain [127.0.0.1]) by mail17-am1 (MessageSwitch) id 133858180660048_30906; Fri, 1 Jun 2012 20:16:46 +0000 (UTC) Received: from AM1EHSMHS018.bigfish.com (unknown [10.3.201.225]) by mail17-am1.bigfish.com (Postfix) with ESMTP id 0D08E460052 for ; Fri, 1 Jun 2012 20:16:46 +0000 (UTC) Received: from il06msg01.mot-solutions.com (129.188.136.17) by AM1EHSMHS018.bigfish.com (10.3.206.21) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 1 Jun 2012 20:16:45 +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 q51L2COi010543 for ; Fri, 1 Jun 2012 16:02:12 -0500 (CDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe010.messaging.microsoft.com [216.32.180.30]) by il06msg01.mot-solutions.com (8.14.3/8.14.3) with ESMTP id q51L2C5O010537 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 1 Jun 2012 16:02:12 -0500 (CDT) Received: from mail84-va3-R.bigfish.com (10.7.14.249) by VA3EHSOBE010.bigfish.com (10.7.40.12) with Microsoft SMTP Server id 14.1.225.22; Fri, 1 Jun 2012 20:16:42 +0000 Received: from mail84-va3 (localhost [127.0.0.1]) by mail84-va3-R.bigfish.com (Postfix) with ESMTP id 9D5DFC03CD for ; Fri, 1 Jun 2012 20:16:42 +0000 (UTC) Received: from mail84-va3 (localhost.localdomain [127.0.0.1]) by mail84-va3 (MessageSwitch) id 133858180010943_21090; Fri, 1 Jun 2012 20:16:40 +0000 (UTC) Received: from VA3EHSMHS019.bigfish.com (unknown [10.7.14.235]) by mail84-va3.bigfish.com (Postfix) with ESMTP id F35862E0046; Fri, 1 Jun 2012 20:16:39 +0000 (UTC) Received: from CH1PRD0410HT005.namprd04.prod.outlook.com (157.56.244.181) by VA3EHSMHS019.bigfish.com (10.7.99.29) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 1 Jun 2012 20:16:38 +0000 Received: from CH1PRD0410MB369.namprd04.prod.outlook.com ([169.254.5.147]) by CH1PRD0410HT005.namprd04.prod.outlook.com ([10.255.147.40]) with mapi id 14.16.0152.000; Fri, 1 Jun 2012 20:17:07 +0000 From: Lewis Adam-CAL022 To: Justin Richer Thread-Topic: [OAUTH-WG] Inter-domain AS/RS communication (revisited) Thread-Index: AQHNQDFM1Uu0yk0hv0Kr6F3eZEdpwpbl5YFA Date: Fri, 1 Jun 2012 20:17:06 +0000 Message-ID: <59E470B10C4630419ED717AC79FCF9A90AECF535@CH1PRD0410MB369.namprd04.prod.outlook.com> References: <19000680-251A-4C0F-B287-B17E5A0F8720@mitre.org> <59E470B10C4630419ED717AC79FCF9A90AECF4B6@CH1PRD0410MB369.namprd04.prod.outlook.com> <4FC91F57.9050103@mitre.org> In-Reply-To: <4FC91F57.9050103@mitre.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [75.149.88.198] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: CH1PRD0410HT005.namprd04.prod.outlook.com X-MS-Exchange-CrossPremises-SCL: -1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-rules-execution-history: Sample Spam Submissions X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-MS-Exchange-CrossPremises-ContentConversionOptions: False; 00160000; True; ; iso-8859-1 X-OrganizationHeadersPreserved: CH1PRD0410HT005.namprd04.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%1294$Dn%MITRE.ORG$RO%2$TLS%3$FQDN%msgate.mot-solutions.com$TlsDn% X-FOPE-CONNECTOR: Id%1294$Dn%TEAM.TELSTRA.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] Inter-domain AS/RS communication (revisited) X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 20:17:22 -0000 Hi Justin, Yes ... this is making me feel a lot better about things. So just a few mo= re points of clarification: 1. if the OAuth access-token is a JWT, then it seems there is nothing for m= e to introspect ... because all the info is in the JWT and the RS can valid= ate the signature itself. 2. what OAuth AS implementations today actually give me a structure JWT acc= ess-token? Most that I am aware of give me an unstructured token. 3. even if I could get a JWT (which I would definitely be interested in exp= loring) the unstructured token still gives my major bandwidth advantage (ag= ain, because of my edge cases). Tx! adam -----Original Message----- From: Justin Richer [mailto:jricher@mitre.org]=20 Sent: Friday, June 01, 2012 3:00 PM To: Lewis Adam-CAL022 Cc: Manger, James H; oauth@ietf.org Subject: Re: [OAUTH-WG] Inter-domain AS/RS communication (revisited) First, I have to give proper credit to my colleague Amanda Anganes for=20 making those flow diagrams (which I agree are pretty awesome -- when=20 coding I refer to them as often as the spec text itself, personally). Yes, you have it right, in this case the RS is the client of the=20 identity API from the AS, which looking back at your original question=20 isn't quite what you were asking, so I apologize for the confusion=20 there. Just so I have this straight: You have a client, C, making an OAuth protected call to service RS using=20 a token that's been generated by one of a set of trusted authorization=20 servers, AS1-AS12. So RS needs to figure out: 1) Is the token any good? 2) Is the token issued by someone I know? 3) What's the user information tied to the token? (name and stuff) If that's the case, there are a few ways to handle this, but one of the=20 simplest is to make use of the bearer token principle and chain the=20 service calls around a bit. Especially if your AS's all use a structured=20 token format, like JWT, that can point to the issuer of the token (and=20 therefore which AS spit it out in the first place). So in concrete terms: Client C calls AS1 and gets access token AT. AT is a JWT that has in its=20 claims section {iss: AS1}, among others. C passes AT to RS to make its=20 call. RS can inspect the JWT and discover the token was sent from AS1=20 (by the issuer field). RS knows that AS1 is in its list of trusted AS's.=20 RS validates the signature on AT against the key from AS1 (which can be=20 done using JWK). Now that the token is good, the RS can start to fulfill=20 the client's request. The RS could also call what's being termed an=20 "introspection endpoint" at AS1 to help it figure out what the token is=20 good for (scopes, permissions, timeouts, etc) in fulfilling the client's=20 request. But say RS needs user information like a name and email address=20 and all that. Well, if the AS's are all doing OpenID Connect, which=20 would still give you a valid access token, then the AS's will all *also*=20 have a User Info Endpoint defined. The RS can send the AT to the=20 UserInfo Endpoint to get the user's information from it in a simple JSON=20 schema. You can alternatively use SCIM or PoCo formatted endpoints to=20 accomplish much of the same stuff, all protected over OAuth. There are some more complicated methods, with the RS trading in the AT=20 for its own subscoped AT for instance, but this is a basic and fairly=20 functional usage scenario. Do you think this covers what you'd want to=20 do with it? It's still about 80% vanilla OAuth2. -- Justin On 06/01/2012 12:19 PM, Lewis Adam-CAL022 wrote: > Maybe I'm getting confused over the terminology. Connect speaks of a cli= ent talking to a CheckID endpoint or UserInfo endpoint. Is the RS acting a= s the client in this case? > > I'm actually looking at your famous PDF diagrams Justin, and it looks lik= e the client is in all cases the same client. E.g. the client that asks fo= r the access token is the same client performs the UserInfo request or Chec= kID request. In my mind, I want the client to get the access-token and pre= sent it to the RS, and then I want the RS to perform the UserInfo request o= r CheckID request. > > So if you're telling me that the RS is acting as the client, and the RS c= an perform the UserInfo request or CheckID request, then I get it. But it = wasn't obvious from the spec. > > > Tx! > adam > > > > > -----Original Message----- > From: Richer, Justin P. [mailto:jricher@mitre.org] > Sent: Friday, June 01, 2012 10:00 AM > To: Manger, James H > Cc: Lewis Adam-CAL022; oauth@ietf.org > Subject: Re: [OAUTH-WG] Inter-domain AS/RS communication (revisited) > > More specifically, OpenID Connect with the addition of reusing the access= _token provided by the AS to get at other API services. This capability is = explicitly encouraged in Connect since it directly re-uses the OAuth2 infra= structure and tokens to do the identity protocol. > > -- Justin > > On Jun 1, 2012, at 10:33 AM, Manger, James H wrote: > >> Adam, >> >> You are describing OpenID Connect. >> >> -- >> James Manger >> >> ----- Reply message ----- >> From: "Lewis Adam-CAL022" >> Date: Sat, Jun 2, 2012 12:00 am >> Subject: [OAUTH-WG] Inter-domain AS/RS communication (revisited) >> To: "oauth@ietf.org" >> >> Hi all, >> >> I've asked about the lack of standardization of the AS-RS interface in t= he past, but I have a new twist on my question. What is the viability of p= erforming user "authentication" using OAuth with an RS in domain-1, and a w= hole bunch of AS's in different domains (assuming that the RS and AS is of = the same implementation)? >> >> RS (domain-1) >> >> AS-1 AS-2 AS-3 AS-4 AS-5 AS-6 AS-n >> >> Let me explain a bit further. I have a RS in domain-1 which exposes an = API, which is accessed by a native client, with users from (for example) 12= different domains. (Note: both the RS and native clients are of the same = vendor implementation). Each of the 12 user domains has an AS, of the same= implementation as the RS in domain-1. I'm thinking that native client use= rs from domain X should be able to authenticate to the AS in their home dom= ain using some primary authentication means, obtain an unstructured access-= token, and present that access-token to the RS in domain-1. Because they a= re all of the same implementation, the RS in domain-1 should be able to mak= e a RESTful API call to the AS in domain X to obtain a JSON structure, cont= aining among other things, the user's name, and possibly other attributes. = Hence secondary authentication has been realized. >> >> This seems to work, but is this within the spirit of OAuth, or have I go= ne off into LaLa land? We have looked at using the SAML bearer assertion p= rofile for OAuth, but we do a lot over wireless links, many of which are ba= ndwidth anemic, and the overhead of obtaining the SAML assertion and sendin= g it are making me a bit squeamish. OAuth is attractive because of its lig= ht weight-ness. Is the usage I'm proposing of OAuth (above) something that= would be within the overall spirit of the OAuth framework? >> >> Tx! >> adam >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > > > > From gffletch@aol.com Fri Jun 1 13:42:25 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0A1A11E80B0 for ; Fri, 1 Jun 2012 13:42:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.995 X-Spam-Level: X-Spam-Status: No, score=-1.995 tagged_above=-999 required=5 tests=[AWL=0.603, 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 hmWE87HnoU9z for ; Fri, 1 Jun 2012 13:42:24 -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 28DB611E80B4 for ; Fri, 1 Jun 2012 13:42:24 -0700 (PDT) Received: from mtaout-ma01.r1000.mx.aol.com (mtaout-ma01.r1000.mx.aol.com [172.29.41.1]) by imr-db03.mx.aol.com (8.14.1/8.14.1) with ESMTP id q51KgFHv024274; Fri, 1 Jun 2012 16:42:15 -0400 Received: from palantir.office.aol.com (palantir.office.aol.com [10.181.186.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout-ma01.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id A35C1E00023F; Fri, 1 Jun 2012 16:42:14 -0400 (EDT) Message-ID: <4FC92926.4000403@aol.com> Date: Fri, 01 Jun 2012 16:42:14 -0400 From: George Fletcher Organization: AOL LLC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Lewis Adam-CAL022 References: <19000680-251A-4C0F-B287-B17E5A0F8720@mitre.org> <59E470B10C4630419ED717AC79FCF9A90AECF4B6@CH1PRD0410MB369.namprd04.prod.outlook.com> <4FC91F57.9050103@mitre.org> <59E470B10C4630419ED717AC79FCF9A90AECF535@CH1PRD0410MB369.namprd04.prod.outlook.com> In-Reply-To: <59E470B10C4630419ED717AC79FCF9A90AECF535@CH1PRD0410MB369.namprd04.prod.outlook.com> Content-Type: multipart/alternative; boundary="------------080701070005020501080902" x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20110426; t=1338583334; bh=NS7JlNO67j3UnfnZLCS55GqMF7geHd6kpjoV3fmuHiQ=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=BsAVMemIxncgWqVSuiVi33YMhpoSoJWr9k9eG1A8KYHBUHvYgTTnvbMDqfdCtoEqK CWZDqGnun+Tp2ZuRjg16XjbYNATlzf30TOE3ym9dfq4mMHu8/7tsy0/H0r5QujuLhy ND3gAn9FcEn6EwelQIioPV35FcgT6pW2HVwj7Z6k= X-AOL-SCOLL-SCORE: 0:2:466061152:93952408 X-AOL-SCOLL-URL_COUNT: 0 x-aol-sid: 3039ac1d29014fc92926243f X-AOL-IP: 10.181.186.254 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Inter-domain AS/RS communication (revisited) X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 20:42:25 -0000 This is a multi-part message in MIME format. --------------080701070005020501080902 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit If you are using the "userinfo endpoint" concept to verify the unstructured token with the appropriate AS, then all you really need from the unstructured token is which AS to send it to. If your problem space is constrained so that this is straight forward, then there isn't a significant reason to use a structured token over an unstructured one. Though I could probably argue, that if you can determine the originating AS from the "unstructured" token then it's really "structured"; just not using JWT:) Thanks, George On 6/1/12 4:17 PM, Lewis Adam-CAL022 wrote: > Hi Justin, > > Yes ... this is making me feel a lot better about things. So just a few more points of clarification: > > 1. if the OAuth access-token is a JWT, then it seems there is nothing for me to introspect ... because all the info is in the JWT and the RS can validate the signature itself. > 2. what OAuth AS implementations today actually give me a structure JWT access-token? Most that I am aware of give me an unstructured token. > 3. even if I could get a JWT (which I would definitely be interested in exploring) the unstructured token still gives my major bandwidth advantage (again, because of my edge cases). > > > Tx! > adam > > > -----Original Message----- > From: Justin Richer [mailto:jricher@mitre.org] > Sent: Friday, June 01, 2012 3:00 PM > To: Lewis Adam-CAL022 > Cc: Manger, James H; oauth@ietf.org > Subject: Re: [OAUTH-WG] Inter-domain AS/RS communication (revisited) > > First, I have to give proper credit to my colleague Amanda Anganes for > making those flow diagrams (which I agree are pretty awesome -- when > coding I refer to them as often as the spec text itself, personally). > > Yes, you have it right, in this case the RS is the client of the > identity API from the AS, which looking back at your original question > isn't quite what you were asking, so I apologize for the confusion > there. Just so I have this straight: > > You have a client, C, making an OAuth protected call to service RS using > a token that's been generated by one of a set of trusted authorization > servers, AS1-AS12. So RS needs to figure out: > > 1) Is the token any good? > 2) Is the token issued by someone I know? > 3) What's the user information tied to the token? (name and stuff) > > If that's the case, there are a few ways to handle this, but one of the > simplest is to make use of the bearer token principle and chain the > service calls around a bit. Especially if your AS's all use a structured > token format, like JWT, that can point to the issuer of the token (and > therefore which AS spit it out in the first place). > > So in concrete terms: > > Client C calls AS1 and gets access token AT. AT is a JWT that has in its > claims section {iss: AS1}, among others. C passes AT to RS to make its > call. RS can inspect the JWT and discover the token was sent from AS1 > (by the issuer field). RS knows that AS1 is in its list of trusted AS's. > RS validates the signature on AT against the key from AS1 (which can be > done using JWK). Now that the token is good, the RS can start to fulfill > the client's request. The RS could also call what's being termed an > "introspection endpoint" at AS1 to help it figure out what the token is > good for (scopes, permissions, timeouts, etc) in fulfilling the client's > request. But say RS needs user information like a name and email address > and all that. Well, if the AS's are all doing OpenID Connect, which > would still give you a valid access token, then the AS's will all *also* > have a User Info Endpoint defined. The RS can send the AT to the > UserInfo Endpoint to get the user's information from it in a simple JSON > schema. You can alternatively use SCIM or PoCo formatted endpoints to > accomplish much of the same stuff, all protected over OAuth. > > There are some more complicated methods, with the RS trading in the AT > for its own subscoped AT for instance, but this is a basic and fairly > functional usage scenario. Do you think this covers what you'd want to > do with it? It's still about 80% vanilla OAuth2. > > -- Justin > > On 06/01/2012 12:19 PM, Lewis Adam-CAL022 wrote: >> Maybe I'm getting confused over the terminology. Connect speaks of a client talking to a CheckID endpoint or UserInfo endpoint. Is the RS acting as the client in this case? >> >> I'm actually looking at your famous PDF diagrams Justin, and it looks like the client is in all cases the same client. E.g. the client that asks for the access token is the same client performs the UserInfo request or CheckID request. In my mind, I want the client to get the access-token and present it to the RS, and then I want the RS to perform the UserInfo request or CheckID request. >> >> So if you're telling me that the RS is acting as the client, and the RS can perform the UserInfo request or CheckID request, then I get it. But it wasn't obvious from the spec. >> >> >> Tx! >> adam >> >> >> >> >> -----Original Message----- >> From: Richer, Justin P. [mailto:jricher@mitre.org] >> Sent: Friday, June 01, 2012 10:00 AM >> To: Manger, James H >> Cc: Lewis Adam-CAL022; oauth@ietf.org >> Subject: Re: [OAUTH-WG] Inter-domain AS/RS communication (revisited) >> >> More specifically, OpenID Connect with the addition of reusing the access_token provided by the AS to get at other API services. This capability is explicitly encouraged in Connect since it directly re-uses the OAuth2 infrastructure and tokens to do the identity protocol. >> >> -- Justin >> >> On Jun 1, 2012, at 10:33 AM, Manger, James H wrote: >> >>> Adam, >>> >>> You are describing OpenID Connect. >>> >>> -- >>> James Manger >>> >>> ----- Reply message ----- >>> From: "Lewis Adam-CAL022" >>> Date: Sat, Jun 2, 2012 12:00 am >>> Subject: [OAUTH-WG] Inter-domain AS/RS communication (revisited) >>> To: "oauth@ietf.org" >>> >>> Hi all, >>> >>> I've asked about the lack of standardization of the AS-RS interface in the past, but I have a new twist on my question. What is the viability of performing user "authentication" using OAuth with an RS in domain-1, and a whole bunch of AS's in different domains (assuming that the RS and AS is of the same implementation)? >>> >>> RS (domain-1) >>> >>> AS-1 AS-2 AS-3 AS-4 AS-5 AS-6 AS-n >>> >>> Let me explain a bit further. I have a RS in domain-1 which exposes an API, which is accessed by a native client, with users from (for example) 12 different domains. (Note: both the RS and native clients are of the same vendor implementation). Each of the 12 user domains has an AS, of the same implementation as the RS in domain-1. I'm thinking that native client users from domain X should be able to authenticate to the AS in their home domain using some primary authentication means, obtain an unstructured access-token, and present that access-token to the RS in domain-1. Because they are all of the same implementation, the RS in domain-1 should be able to make a RESTful API call to the AS in domain X to obtain a JSON structure, containing among other things, the user's name, and possibly other attributes. Hence secondary authentication has been realized. >>> >>> This seems to work, but is this within the spirit of OAuth, or have I gone off into LaLa land? We have looked at using the SAML bearer assertion profile for OAuth, but we do a lot over wireless links, many of which are bandwidth anemic, and the overhead of obtaining the SAML assertion and sending it are making me a bit squeamish. OAuth is attractive because of its light weight-ness. Is the usage I'm proposing of OAuth (above) something that would be within the overall spirit of the OAuth framework? >>> >>> 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 > > --------------080701070005020501080902 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit If you are using the "userinfo endpoint" concept to verify the unstructured token with the appropriate AS, then all you really need from the unstructured token is which AS to send it to. If your problem space is constrained so that this is straight forward, then there isn't a significant reason to use a structured token over an unstructured one. Though I could probably argue, that if you can determine the originating AS from the "unstructured" token then it's really "structured"; just not using JWT:)

Thanks,
George

On 6/1/12 4:17 PM, Lewis Adam-CAL022 wrote: 
Hi Justin,

Yes ... this is making me feel a lot better about things.  So just a few more points of clarification:

1. if the OAuth access-token is a JWT, then it seems there is nothing for me to introspect ... because all the info is in the JWT and the RS can validate the signature itself.
2. what OAuth AS implementations today actually give me a structure JWT access-token?  Most that I am aware of give me an unstructured token.
3. even if I could get a JWT (which I would definitely be interested in exploring) the unstructured token still gives my major bandwidth advantage (again, because of my edge cases).


Tx!
adam


-----Original Message-----
From: Justin Richer [mailto:jricher@mitre.org] 
Sent: Friday, June 01, 2012 3:00 PM
To: Lewis Adam-CAL022
Cc: Manger, James H; oauth@ietf.org
Subject: Re: [OAUTH-WG] Inter-domain AS/RS communication (revisited)

First, I have to give proper credit to my colleague Amanda Anganes for 
making those flow diagrams (which I agree are pretty awesome -- when 
coding I refer to them as often as the spec text itself, personally).

Yes, you have it right, in this case the RS is the client of the 
identity API from the AS, which looking back at your original question 
isn't quite what you were asking, so I apologize for the confusion 
there. Just so I have this straight:

You have a client, C, making an OAuth protected call to service RS using 
a token that's been generated by one of a set of trusted authorization 
servers, AS1-AS12. So RS needs to figure out:

1) Is the token any good?
2) Is the token issued by someone I know?
3) What's the user information tied to the token? (name and stuff)

If that's the case, there are a few ways to handle this, but one of the 
simplest is to make use of the bearer token principle and chain the 
service calls around a bit. Especially if your AS's all use a structured 
token format, like JWT, that can point to the issuer of the token (and 
therefore which AS spit it out in the first place).

So in concrete terms:

Client C calls AS1 and gets access token AT. AT is a JWT that has in its 
claims section {iss: AS1}, among others. C passes AT to RS to make its 
call. RS can inspect the JWT and discover the token was sent from AS1 
(by the issuer field). RS knows that AS1 is in its list of trusted AS's. 
RS validates the signature on AT against the key from AS1 (which can be 
done using JWK). Now that the token is good, the RS can start to fulfill 
the client's request. The RS could also call what's being termed an 
"introspection endpoint" at AS1 to help it figure out what the token is 
good for (scopes, permissions, timeouts, etc) in fulfilling the client's 
request. But say RS needs user information like a name and email address 
and all that. Well, if the AS's are all doing OpenID Connect, which 
would still give you a valid access token, then the AS's will all *also* 
have a User Info Endpoint defined. The RS can send the AT to the 
UserInfo Endpoint to get the user's information from it in a simple JSON 
schema. You can alternatively use SCIM or PoCo formatted endpoints to 
accomplish much of the same stuff, all protected over OAuth.

There are some more complicated methods, with the RS trading in the AT 
for its own subscoped AT for instance, but this is a basic and fairly 
functional usage scenario. Do you think this covers what you'd want to 
do with it? It's still about 80% vanilla OAuth2.

  -- Justin

On 06/01/2012 12:19 PM, Lewis Adam-CAL022 wrote:

Maybe I'm getting confused over the terminology.  Connect speaks of a client talking to a CheckID endpoint or UserInfo endpoint.  Is the RS acting as the client in this case?

I'm actually looking at your famous PDF diagrams Justin, and it looks like the client is in all cases the same client.  E.g. the client that asks for the access token is the same client performs the UserInfo request or CheckID request.  In my mind, I want the client to get the access-token and present it to the RS, and then I want the RS to perform the UserInfo request or CheckID request.

So if you're telling me that the RS is acting as the client, and the RS can perform the UserInfo request or CheckID request, then I get it.  But it wasn't obvious from the spec.


Tx!
adam




-----Original Message-----
From: Richer, Justin P. [mailto:jricher@mitre.org]
Sent: Friday, June 01, 2012 10:00 AM
To: Manger, James H
Cc: Lewis Adam-CAL022; oauth@ietf.org
Subject: Re: [OAUTH-WG] Inter-domain AS/RS communication (revisited)

More specifically, OpenID Connect with the addition of reusing the access_token provided by the AS to get at other API services. This capability is explicitly encouraged in Connect since it directly re-uses the OAuth2 infrastructure and tokens to do the identity protocol.

  -- Justin

On Jun 1, 2012, at 10:33 AM, Manger, James H wrote:


Adam,

You are describing OpenID Connect.

--
James Manger

----- Reply message -----
From: "Lewis Adam-CAL022"<Adam.Lewis@motorolasolutions.com>
Date: Sat, Jun 2, 2012 12:00 am
Subject: [OAUTH-WG] Inter-domain AS/RS communication (revisited)
To: "oauth@ietf.org"<oauth@ietf.org>

Hi all,

I've asked about the lack of standardization of the AS-RS interface in the past, but I have a new twist on my question.  What is the viability of performing user "authentication" using OAuth with an RS in domain-1, and a whole bunch of AS's in different domains (assuming that the RS and AS is of the same implementation)?

            RS (domain-1)

AS-1     AS-2     AS-3     AS-4     AS-5     AS-6     AS-n

Let me explain a bit further.  I have a RS in domain-1 which exposes an API, which is accessed by a native client, with users from (for example) 12 different domains.  (Note: both the RS and native clients are of the same vendor implementation).  Each of the 12 user domains has an AS, of the same implementation as the RS in domain-1.  I'm thinking that native client users from domain X should be able to authenticate to the AS in their home domain using some primary authentication means, obtain an unstructured access-token, and present that access-token to the RS in domain-1.  Because they are all of the same implementation, the RS in domain-1 should be able to make a RESTful API call to the AS in domain X to obtain a JSON structure, containing among other things, the user's name, and possibly other attributes.  Hence secondary authentication has been realized.

This seems to work, but is this within the spirit of OAuth, or have I gone off into LaLa land?  We have looked at using the SAML bearer assertion profile for OAuth, but we do a lot over wireless links, many of which are bandwidth anemic, and the overhead of obtaining the SAML assertion and sending it are making me a bit squeamish.  OAuth is attractive because of its light weight-ness.  Is the usage I'm proposing of OAuth (above) something that would be within the overall spirit of the OAuth framework?

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

--------------080701070005020501080902-- From jricher@mitre.org Fri Jun 1 13:45:10 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 227B621F8887 for ; Fri, 1 Jun 2012 13:45:10 -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 EmhkFajNEEcK for ; Fri, 1 Jun 2012 13:45:09 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id BC89521F8881 for ; Fri, 1 Jun 2012 13:45:08 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 2873921B0E38; Fri, 1 Jun 2012 16:45:06 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 0B78F21B0E43; Fri, 1 Jun 2012 16:45:06 -0400 (EDT) Received: from [129.83.50.12] (129.83.31.51) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server (TLS) id 14.2.283.3; Fri, 1 Jun 2012 16:45:05 -0400 Message-ID: <4FC929D1.1010504@mitre.org> Date: Fri, 1 Jun 2012 16:45:05 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Lewis Adam-CAL022 References: <19000680-251A-4C0F-B287-B17E5A0F8720@mitre.org> <59E470B10C4630419ED717AC79FCF9A90AECF4B6@CH1PRD0410MB369.namprd04.prod.outlook.com> <4FC91F57.9050103@mitre.org> <59E470B10C4630419ED717AC79FCF9A90AECF535@CH1PRD0410MB369.namprd04.prod.outlook.com> In-Reply-To: <59E470B10C4630419ED717AC79FCF9A90AECF535@CH1PRD0410MB369.namprd04.prod.outlook.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [129.83.31.51] Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Inter-domain AS/RS communication (revisited) X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 20:45:10 -0000 Right, if you've got a fully signed JWT (using JWS) then you don't need much in introspection because you *can* pack everything in the token. But introspection gives you the option to put some bits in the token and leave some other bits as a callable API, which is nice. If you don't use a JWT, I would at least suggest using a slightly-structured token so that your RS can key which AS the token came from. Otherwise it's going to have to check all of them, which is a huge waste of bandwidth and time. (and very leaky security!!) We've got a JWT-spewing implementation built on top of Spring Security OAuth in our OpenID Connect server, if you're up on Java and Spring and Spring Security (like a lot of our enterprise is) then it might be up your alley. https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server This adds a set of token services to the existing Spring Security OAuth with some different capabilities, and one of these is a full Java JWT library. -- Justin On 06/01/2012 04:17 PM, Lewis Adam-CAL022 wrote: > Hi Justin, > > Yes ... this is making me feel a lot better about things. So just a few more points of clarification: > > 1. if the OAuth access-token is a JWT, then it seems there is nothing for me to introspect ... because all the info is in the JWT and the RS can validate the signature itself. > 2. what OAuth AS implementations today actually give me a structure JWT access-token? Most that I am aware of give me an unstructured token. > 3. even if I could get a JWT (which I would definitely be interested in exploring) the unstructured token still gives my major bandwidth advantage (again, because of my edge cases). > > > Tx! > adam > > > -----Original Message----- > From: Justin Richer [mailto:jricher@mitre.org] > Sent: Friday, June 01, 2012 3:00 PM > To: Lewis Adam-CAL022 > Cc: Manger, James H; oauth@ietf.org > Subject: Re: [OAUTH-WG] Inter-domain AS/RS communication (revisited) > > First, I have to give proper credit to my colleague Amanda Anganes for > making those flow diagrams (which I agree are pretty awesome -- when > coding I refer to them as often as the spec text itself, personally). > > Yes, you have it right, in this case the RS is the client of the > identity API from the AS, which looking back at your original question > isn't quite what you were asking, so I apologize for the confusion > there. Just so I have this straight: > > You have a client, C, making an OAuth protected call to service RS using > a token that's been generated by one of a set of trusted authorization > servers, AS1-AS12. So RS needs to figure out: > > 1) Is the token any good? > 2) Is the token issued by someone I know? > 3) What's the user information tied to the token? (name and stuff) > > If that's the case, there are a few ways to handle this, but one of the > simplest is to make use of the bearer token principle and chain the > service calls around a bit. Especially if your AS's all use a structured > token format, like JWT, that can point to the issuer of the token (and > therefore which AS spit it out in the first place). > > So in concrete terms: > > Client C calls AS1 and gets access token AT. AT is a JWT that has in its > claims section {iss: AS1}, among others. C passes AT to RS to make its > call. RS can inspect the JWT and discover the token was sent from AS1 > (by the issuer field). RS knows that AS1 is in its list of trusted AS's. > RS validates the signature on AT against the key from AS1 (which can be > done using JWK). Now that the token is good, the RS can start to fulfill > the client's request. The RS could also call what's being termed an > "introspection endpoint" at AS1 to help it figure out what the token is > good for (scopes, permissions, timeouts, etc) in fulfilling the client's > request. But say RS needs user information like a name and email address > and all that. Well, if the AS's are all doing OpenID Connect, which > would still give you a valid access token, then the AS's will all *also* > have a User Info Endpoint defined. The RS can send the AT to the > UserInfo Endpoint to get the user's information from it in a simple JSON > schema. You can alternatively use SCIM or PoCo formatted endpoints to > accomplish much of the same stuff, all protected over OAuth. > > There are some more complicated methods, with the RS trading in the AT > for its own subscoped AT for instance, but this is a basic and fairly > functional usage scenario. Do you think this covers what you'd want to > do with it? It's still about 80% vanilla OAuth2. > > -- Justin > > On 06/01/2012 12:19 PM, Lewis Adam-CAL022 wrote: >> Maybe I'm getting confused over the terminology. Connect speaks of a client talking to a CheckID endpoint or UserInfo endpoint. Is the RS acting as the client in this case? >> >> I'm actually looking at your famous PDF diagrams Justin, and it looks like the client is in all cases the same client. E.g. the client that asks for the access token is the same client performs the UserInfo request or CheckID request. In my mind, I want the client to get the access-token and present it to the RS, and then I want the RS to perform the UserInfo request or CheckID request. >> >> So if you're telling me that the RS is acting as the client, and the RS can perform the UserInfo request or CheckID request, then I get it. But it wasn't obvious from the spec. >> >> >> Tx! >> adam >> >> >> >> >> -----Original Message----- >> From: Richer, Justin P. [mailto:jricher@mitre.org] >> Sent: Friday, June 01, 2012 10:00 AM >> To: Manger, James H >> Cc: Lewis Adam-CAL022; oauth@ietf.org >> Subject: Re: [OAUTH-WG] Inter-domain AS/RS communication (revisited) >> >> More specifically, OpenID Connect with the addition of reusing the access_token provided by the AS to get at other API services. This capability is explicitly encouraged in Connect since it directly re-uses the OAuth2 infrastructure and tokens to do the identity protocol. >> >> -- Justin >> >> On Jun 1, 2012, at 10:33 AM, Manger, James H wrote: >> >>> Adam, >>> >>> You are describing OpenID Connect. >>> >>> -- >>> James Manger >>> >>> ----- Reply message ----- >>> From: "Lewis Adam-CAL022" >>> Date: Sat, Jun 2, 2012 12:00 am >>> Subject: [OAUTH-WG] Inter-domain AS/RS communication (revisited) >>> To: "oauth@ietf.org" >>> >>> Hi all, >>> >>> I've asked about the lack of standardization of the AS-RS interface in the past, but I have a new twist on my question. What is the viability of performing user "authentication" using OAuth with an RS in domain-1, and a whole bunch of AS's in different domains (assuming that the RS and AS is of the same implementation)? >>> >>> RS (domain-1) >>> >>> AS-1 AS-2 AS-3 AS-4 AS-5 AS-6 AS-n >>> >>> Let me explain a bit further. I have a RS in domain-1 which exposes an API, which is accessed by a native client, with users from (for example) 12 different domains. (Note: both the RS and native clients are of the same vendor implementation). Each of the 12 user domains has an AS, of the same implementation as the RS in domain-1. I'm thinking that native client users from domain X should be able to authenticate to the AS in their home domain using some primary authentication means, obtain an unstructured access-token, and present that access-token to the RS in domain-1. Because they are all of the same implementation, the RS in domain-1 should be able to make a RESTful API call to the AS in domain X to obtain a JSON structure, containing among other things, the user's name, and possibly other attributes. Hence secondary authentication has been realized. >>> >>> This seems to work, but is this within the spirit of OAuth, or have I gone off into LaLa land? We have looked at using the SAML bearer assertion profile for OAuth, but we do a lot over wireless links, many of which are bandwidth anemic, and the overhead of obtaining the SAML assertion and sending it are making me a bit squeamish. OAuth is attractive because of its light weight-ness. Is the usage I'm proposing of OAuth (above) something that would be within the overall spirit of the OAuth framework? >>> >>> Tx! >>> adam >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> > > > > > From Adam.Lewis@motorolasolutions.com Fri Jun 1 13:46:18 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7592D11E80B4 for ; Fri, 1 Jun 2012 13:46:18 -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=[AWL=-0.000, 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 XIlKKbixCPGv for ; Fri, 1 Jun 2012 13:46:13 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe005.messaging.microsoft.com [213.199.154.208]) by ietfa.amsl.com (Postfix) with ESMTP id 0789B11E8097 for ; Fri, 1 Jun 2012 13:46:12 -0700 (PDT) Received: from mail41-am1-R.bigfish.com (10.3.201.248) by AM1EHSOBE004.bigfish.com (10.3.204.24) with Microsoft SMTP Server id 14.1.225.23; Fri, 1 Jun 2012 20:45:40 +0000 Received: from mail41-am1 (localhost [127.0.0.1]) by mail41-am1-R.bigfish.com (Postfix) with ESMTP id 7BA8C2C01D3 for ; Fri, 1 Jun 2012 20:45:40 +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: -32 X-BigFish: VPS-32(zzbb2dI9371Ic85fh14ffI542M98dK4015Izz1202hzz1033IL8275bh8275dhz2fh2a8h683h839hd25hf0ah) Received-SPF: pass (mail41-am1: 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.244.181; KIP:(null); UIP:(null); (null); H:CH1PRD0410HT001.namprd04.prod.outlook.com; R:internal; EFV:INT Received: from mail41-am1 (localhost.localdomain [127.0.0.1]) by mail41-am1 (MessageSwitch) id 1338583537958253_18265; Fri, 1 Jun 2012 20:45:37 +0000 (UTC) Received: from AM1EHSMHS005.bigfish.com (unknown [10.3.201.229]) by mail41-am1.bigfish.com (Postfix) with ESMTP id E684A20047 for ; Fri, 1 Jun 2012 20:45:37 +0000 (UTC) Received: from il06msg01.mot-solutions.com (129.188.136.17) by AM1EHSMHS005.bigfish.com (10.3.207.105) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 1 Jun 2012 20:45:37 +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 q51LV4Pq014035 for ; Fri, 1 Jun 2012 16:31:04 -0500 (CDT) Received: from CH1EHSOBE015.bigfish.com (ch1ehsobe005.messaging.microsoft.com [216.32.181.185]) by il06msg01.mot-solutions.com (8.14.3/8.14.3) with ESMTP id q51LV4fv014032 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 1 Jun 2012 16:31:04 -0500 (CDT) Received: from mail141-ch1-R.bigfish.com (10.43.68.238) by CH1EHSOBE015.bigfish.com (10.43.70.65) with Microsoft SMTP Server id 14.1.225.23; Fri, 1 Jun 2012 20:45:35 +0000 Received: from mail141-ch1 (localhost [127.0.0.1]) by mail141-ch1-R.bigfish.com (Postfix) with ESMTP id 443E3403B5 for ; Fri, 1 Jun 2012 20:45:35 +0000 (UTC) Received: from mail141-ch1 (localhost.localdomain [127.0.0.1]) by mail141-ch1 (MessageSwitch) id 1338583532694795_15948; Fri, 1 Jun 2012 20:45:32 +0000 (UTC) Received: from CH1EHSMHS002.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.250]) by mail141-ch1.bigfish.com (Postfix) with ESMTP id A6223C0046; Fri, 1 Jun 2012 20:45:32 +0000 (UTC) Received: from CH1PRD0410HT001.namprd04.prod.outlook.com (157.56.244.181) by CH1EHSMHS002.bigfish.com (10.43.70.2) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 1 Jun 2012 20:45:32 +0000 Received: from CH1PRD0410MB369.namprd04.prod.outlook.com ([169.254.5.147]) by CH1PRD0410HT001.namprd04.prod.outlook.com ([10.255.147.36]) with mapi id 14.16.0164.004; Fri, 1 Jun 2012 20:46:03 +0000 From: Lewis Adam-CAL022 To: George Fletcher Thread-Topic: [OAUTH-WG] Inter-domain AS/RS communication (revisited) Thread-Index: AQHNQDcX3SO/RK1NMEWlK0iPy7zqW5bl7etA Date: Fri, 1 Jun 2012 20:46:03 +0000 Message-ID: <59E470B10C4630419ED717AC79FCF9A90AECF54E@CH1PRD0410MB369.namprd04.prod.outlook.com> References: <19000680-251A-4C0F-B287-B17E5A0F8720@mitre.org> <59E470B10C4630419ED717AC79FCF9A90AECF4B6@CH1PRD0410MB369.namprd04.prod.outlook.com> <4FC91F57.9050103@mitre.org> <59E470B10C4630419ED717AC79FCF9A90AECF535@CH1PRD0410MB369.namprd04.prod.outlook.com> <4FC92926.4000403@aol.com> In-Reply-To: <4FC92926.4000403@aol.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [75.149.88.198] Content-Type: multipart/alternative; boundary="_000_59E470B10C4630419ED717AC79FCF9A90AECF54ECH1PRD0410MB369_" MIME-Version: 1.0 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: CH1PRD0410HT001.namprd04.prod.outlook.com X-MS-Exchange-CrossPremises-SCL: -1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-rules-execution-history: Sample Spam Submissions X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-MS-Exchange-CrossPremises-ContentConversionOptions: False; 00160000; True; ; iso-8859-1 X-OrganizationHeadersPreserved: CH1PRD0410HT001.namprd04.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%1294$Dn%AOL.COM$RO%2$TLS%3$FQDN%msgate.mot-solutions.com$TlsDn% X-FOPE-CONNECTOR: Id%1294$Dn%MITRE.ORG$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] Inter-domain AS/RS communication (revisited) X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 20:46:18 -0000 --_000_59E470B10C4630419ED717AC79FCF9A90AECF54ECH1PRD0410MB369_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi George, I have other means to identify the domain/AS which generated the unstructur= ed token ... so this is not an issue. But I am still interested in JWT. My question (to all on this list) is sti= ll, which OAuth AS implementations out there will actually give me a struct= ured JWT access-token, in response to an Access Token request? I realize t= hat Connect may be looking to make more ubiquitous, but who does it today? Tx!! adam From: George Fletcher [mailto:gffletch@aol.com] Sent: Friday, June 01, 2012 3:42 PM To: Lewis Adam-CAL022 Cc: Justin Richer; oauth@ietf.org Subject: Re: [OAUTH-WG] Inter-domain AS/RS communication (revisited) If you are using the "userinfo endpoint" concept to verify the unstructured= token with the appropriate AS, then all you really need from the unstructu= red token is which AS to send it to. If your problem space is constrained s= o that this is straight forward, then there isn't a significant reason to u= se a structured token over an unstructured one. Though I could probably arg= ue, that if you can determine the originating AS from the "unstructured" to= ken then it's really "structured"; just not using JWT:) Thanks, George On 6/1/12 4:17 PM, Lewis Adam-CAL022 wrote: Hi Justin, Yes ... this is making me feel a lot better about things. So just a few mo= re points of clarification: 1. if the OAuth access-token is a JWT, then it seems there is nothing for m= e to introspect ... because all the info is in the JWT and the RS can valid= ate the signature itself. 2. what OAuth AS implementations today actually give me a structure JWT acc= ess-token? Most that I am aware of give me an unstructured token. 3. even if I could get a JWT (which I would definitely be interested in exp= loring) the unstructured token still gives my major bandwidth advantage (ag= ain, because of my edge cases). Tx! adam -----Original Message----- From: Justin Richer [mailto:jricher@mitre.org] Sent: Friday, June 01, 2012 3:00 PM To: Lewis Adam-CAL022 Cc: Manger, James H; oauth@ietf.org Subject: Re: [OAUTH-WG] Inter-domain AS/RS communication (revisited) First, I have to give proper credit to my colleague Amanda Anganes for making those flow diagrams (which I agree are pretty awesome -- when coding I refer to them as often as the spec text itself, personally). Yes, you have it right, in this case the RS is the client of the identity API from the AS, which looking back at your original question isn't quite what you were asking, so I apologize for the confusion there. Just so I have this straight: You have a client, C, making an OAuth protected call to service RS using a token that's been generated by one of a set of trusted authorization servers, AS1-AS12. So RS needs to figure out: 1) Is the token any good? 2) Is the token issued by someone I know? 3) What's the user information tied to the token? (name and stuff) If that's the case, there are a few ways to handle this, but one of the simplest is to make use of the bearer token principle and chain the service calls around a bit. Especially if your AS's all use a structured token format, like JWT, that can point to the issuer of the token (and therefore which AS spit it out in the first place). So in concrete terms: Client C calls AS1 and gets access token AT. AT is a JWT that has in its claims section {iss: AS1}, among others. C passes AT to RS to make its call. RS can inspect the JWT and discover the token was sent from AS1 (by the issuer field). RS knows that AS1 is in its list of trusted AS's. RS validates the signature on AT against the key from AS1 (which can be done using JWK). Now that the token is good, the RS can start to fulfill the client's request. The RS could also call what's being termed an "introspection endpoint" at AS1 to help it figure out what the token is good for (scopes, permissions, timeouts, etc) in fulfilling the client's request. But say RS needs user information like a name and email address and all that. Well, if the AS's are all doing OpenID Connect, which would still give you a valid access token, then the AS's will all *also* have a User Info Endpoint defined. The RS can send the AT to the UserInfo Endpoint to get the user's information from it in a simple JSON schema. You can alternatively use SCIM or PoCo formatted endpoints to accomplish much of the same stuff, all protected over OAuth. There are some more complicated methods, with the RS trading in the AT for its own subscoped AT for instance, but this is a basic and fairly functional usage scenario. Do you think this covers what you'd want to do with it? It's still about 80% vanilla OAuth2. -- Justin On 06/01/2012 12:19 PM, Lewis Adam-CAL022 wrote: Maybe I'm getting confused over the terminology. Connect speaks of a clien= t talking to a CheckID endpoint or UserInfo endpoint. Is the RS acting as = the client in this case? I'm actually looking at your famous PDF diagrams Justin, and it looks like = the client is in all cases the same client. E.g. the client that asks for = the access token is the same client performs the UserInfo request or CheckI= D request. In my mind, I want the client to get the access-token and prese= nt it to the RS, and then I want the RS to perform the UserInfo request or = CheckID request. So if you're telling me that the RS is acting as the client, and the RS can= perform the UserInfo request or CheckID request, then I get it. But it wa= sn't obvious from the spec. Tx! adam -----Original Message----- From: Richer, Justin P. [mailto:jricher@mitre.org] Sent: Friday, June 01, 2012 10:00 AM To: Manger, James H Cc: Lewis Adam-CAL022; oauth@ietf.org Subject: Re: [OAUTH-WG] Inter-domain AS/RS communication (revisited) More specifically, OpenID Connect with the addition of reusing the access_t= oken provided by the AS to get at other API services. This capability is ex= plicitly encouraged in Connect since it directly re-uses the OAuth2 infrast= ructure and tokens to do the identity protocol. -- Justin On Jun 1, 2012, at 10:33 AM, Manger, James H wrote: Adam, You are describing OpenID Connect. -- James Manger ----- Reply message ----- From: "Lewis Adam-CAL022" Date: Sat, Jun 2, 2012 12:00 am Subject: [OAUTH-WG] Inter-domain AS/RS communication (revisited) To: "oauth@ietf.org" Hi all, I've asked about the lack of standardization of the AS-RS interface in the = past, but I have a new twist on my question. What is the viability of perf= orming user "authentication" using OAuth with an RS in domain-1, and a whol= e bunch of AS's in different domains (assuming that the RS and AS is of the= same implementation)? RS (domain-1) AS-1 AS-2 AS-3 AS-4 AS-5 AS-6 AS-n Let me explain a bit further. I have a RS in domain-1 which exposes an API= , which is accessed by a native client, with users from (for example) 12 di= fferent domains. (Note: both the RS and native clients are of the same ven= dor implementation). Each of the 12 user domains has an AS, of the same im= plementation as the RS in domain-1. I'm thinking that native client users = from domain X should be able to authenticate to the AS in their home domain= using some primary authentication means, obtain an unstructured access-tok= en, and present that access-token to the RS in domain-1. Because they are = all of the same implementation, the RS in domain-1 should be able to make a= RESTful API call to the AS in domain X to obtain a JSON structure, contain= ing among other things, the user's name, and possibly other attributes. He= nce secondary authentication has been realized. This seems to work, but is this within the spirit of OAuth, or have I gone = off into LaLa land? We have looked at using the SAML bearer assertion prof= ile for OAuth, but we do a lot over wireless links, many of which are bandw= idth anemic, and the overhead of obtaining the SAML assertion and sending i= t are making me a bit squeamish. OAuth is attractive because of its light = weight-ness. Is the usage I'm proposing of OAuth (above) something that wo= uld be within the overall spirit of the OAuth framework? 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_59E470B10C4630419ED717AC79FCF9A90AECF54ECH1PRD0410MB369_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi George,

 

I have other means to identify the domain/AS= which generated the unstructured token … so this is not an issue.


But I am still interested in JWT.  My question (to all on this list) i= s still, which OAuth AS implementations out there will actually give me a s= tructured JWT access-token, in response to an Access Token request?  I= realize that Connect may be looking to make more ubiquitous, but who does it today?

 

Tx!!

adam

 

From: George Fletcher [mailto:gffletch@aol.com]
Sent: Friday, June 01, 2012 3:42 PM
To: Lewis Adam-CAL022
Cc: Justin Richer; oauth@ietf.org
Subject: Re: [OAUTH-WG] Inter-domain AS/RS communication (revisited)=

 

If you are using the "userinfo endpoint" con= cept to verify the unstructured token with the appropriate AS, then all you= really need from the unstructured token is which AS to send it to. If your problem space is constrained so that this is straight forward, the= n there isn't a significant reason to use a structured token over an unstru= ctured one. Though I could probably argue, that if you can determine the or= iginating AS from the "unstructured" token then it's really "structured"; just not using JWT:)

Thanks,
George

On 6/1/12 4:17 PM, Lewis Adam-CAL022 wrote: 

Hi Justin,
 
Yes ... this is making me feel a lot better about things.  So jus=
t a few more points of clarification:
 
1. if the OAuth access-token is a JWT, then it seems there is nothing =
for me to introspect ... because all the info is in the JWT and the RS can =
validate the signature itself.
2. what OAuth AS implementations today actually give me a structure JW=
T access-token?  Most that I am aware of give me an unstructured token=
.
3. even if I could get a JWT (which I would definitely be interested i=
n exploring) the unstructured token still gives my major bandwidth advantag=
e (again, because of my edge cases).
 
 
Tx!
adam
 
 
-----Original Message-----
From: Justin Richer [mailto:jrich=
er@mitre.org] 
Sent: Friday, June 01, 2012 3:00 PM
To: Lewis Adam-CAL022
Cc: Manger, James H; oauth@ietf.org<=
/a>
Subject: Re: [OAUTH-WG] Inter-domain AS/RS communication (revisited)
 
First, I have to give proper credit to my colleague Amanda Anganes for=
 
making those flow diagrams (which I agree are pretty awesome -- when <=
o:p>
coding I refer to them as often as the spec text itself, personally).<=
o:p>
 
Yes, you have it right, in this case the RS is the client of the =

identity API from the AS, which looking back at your original question=
 
isn't quite what you were asking, so I apologize for the confusion 
there. Just so I have this straight:
 
You have a client, C, making an OAuth protected call to service RS usi=
ng 
a token that's been generated by one of a set of trusted authorization=
 
servers, AS1-AS12. So RS needs to figure out:
 
1) Is the token any good?
2) Is the token issued by someone I know?
3) What's the user information tied to the token? (name and stuff)
 
If that's the case, there are a few ways to handle this, but one of th=
e 
simplest is to make use of the bearer token principle and chain the 
service calls around a bit. Especially if your AS's all use a structur=
ed 
token format, like JWT, that can point to the issuer of the token (and=
 
therefore which AS spit it out in the first place).
 
So in concrete terms:
 
Client C calls AS1 and gets access token AT. AT is a JWT that has in i=
ts 
claims section {iss: AS1}, among others. C passes AT to RS to make its=
 
call. RS can inspect the JWT and discover the token was sent from AS1 =

(by the issuer field). RS knows that AS1 is in its list of trusted AS'=
s. 
RS validates the signature on AT against the key from AS1 (which can b=
e 
done using JWK). Now that the token is good, the RS can start to fulfi=
ll 
the client's request. The RS could also call what's being termed an 
"introspection endpoint" at AS1 to help it figure out what t=
he token is 
good for (scopes, permissions, timeouts, etc) in fulfilling the client=
's 
request. But say RS needs user information like a name and email addre=
ss 
and all that. Well, if the AS's are all doing OpenID Connect, which 
would still give you a valid access token, then the AS's will all *als=
o* 
have a User Info Endpoint defined. The RS can send the AT to the =

UserInfo Endpoint to get the user's information from it in a simple JS=
ON 
schema. You can alternatively use SCIM or PoCo formatted endpoints to =

accomplish much of the same stuff, all protected over OAuth.
 
There are some more complicated methods, with the RS trading in the AT=
 
for its own subscoped AT for instance, but this is a basic and fairly =

functional usage scenario. Do you think this covers what you'd want to=
 
do with it? It's still about 80% vanilla OAuth2.
 
  -- Justin
 
On 06/01/2012 12:19 PM, Lewis Adam-CAL022 wrote:
Maybe I'm getting confused over the terminology.  Connect speaks =
of a client talking to a CheckID endpoint or UserInfo endpoint.  Is th=
e RS acting as the client in this case?
 
I'm actually looking at your famous PDF diagrams Justin, and it looks =
like the client is in all cases the same client.  E.g. the client that=
 asks for the access token is the same client performs the UserInfo request=
 or CheckID request.  In my mind, I want the client to get the access-=
token and present it to the RS, and then I want the RS to perform the UserI=
nfo request or CheckID request.
 
So if you're telling me that the RS is acting as the client, and the R=
S can perform the UserInfo request or CheckID request, then I get it. =
 But it wasn't obvious from the spec.
 
 
Tx!
adam
 
 
 
 
-----Original Message-----
From: Richer, Justin P. [mailto:j=
richer@mitre.org]
Sent: Friday, June 01, 2012 10:00 AM
To: Manger, James H
Cc: Lewis Adam-CAL022; oauth@ietf.or=
g
Subject: Re: [OAUTH-WG] Inter-domain AS/RS communication (revisited)
 
More specifically, OpenID Connect with the addition of reusing the acc=
ess_token provided by the AS to get at other API services. This capability =
is explicitly encouraged in Connect since it directly re-uses the OAuth2 in=
frastructure and tokens to do the identity protocol.
 
  -- Justin
 
On Jun 1, 2012, at 10:33 AM, Manger, James H wrote:
 
Adam,
 
You are describing OpenID Connect.
 
--
James Manger
 
----- Reply message -----
From: "Lewis Adam-CAL022"<Adam.Lewis@motorolasolutions.com>

Date: Sat, Jun 2, 2012 12:00 am


Subject: [OAUTH-WG] Inter-domain AS/RS communication (revisited)<=
/o:p>


To: "oauth@ietf.org"<oauth@ietf.org>


 


Hi all,


 


I've asked about the lack of standardization of the AS-RS interface in=
 the past, but I have a new twist on my question.  What is the viabili=
ty of performing user "authentication" using OAuth with an RS in =
domain-1, and a whole bunch of AS's in different domains (assuming that the=
 RS and AS is of the same implementation)?


 


            RS =
(domain-1)


 


AS-1     AS-2     AS-3 &n=
bsp;   AS-4     AS-5     =
AS-6     AS-n


 


Let me explain a bit further.  I have a RS in domain-1 which expo=
ses an API, which is accessed by a native client, with users from (for exam=
ple) 12 different domains.  (Note: both the RS and native clients are =
of the same vendor implementation).  Each of the 12 user domains has a=
n AS, of the same implementation as the RS in domain-1.  I'm thinking =
that native client users from domain X should be able to authenticate to th=
e AS in their home domain using some primary authentication means, obtain a=
n unstructured access-token, and present that access-token to the RS in dom=
ain-1.  Because they are all of the same implementation, the RS in dom=
ain-1 should be able to make a RESTful API call to the AS in domain X to ob=
tain a JSON structure, containing among other things, the user's name, and =
possibly other attributes.  Hence secondary authentication has been re=
alized.


 


This seems to work, but is this within the spirit of OAuth, or have I =
gone off into LaLa land?  We have looked at using the SAML bearer asse=
rtion profile for OAuth, but we do a lot over wireless links, many of which=
 are bandwidth anemic, and the overhead of obtaining the SAML assertion and=
 sending it are making me a bit squeamish.  OAuth is attractive becaus=
e of its light weight-ness.  Is the usage I'm proposing of OAuth (abov=
e) something that would be within the overall spirit of the OAuth framework=
?


 


Tx!


adam


_______________________________________________


OAuth mailing list


OAuth@ietf.org


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


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

 

--_000_59E470B10C4630419ED717AC79FCF9A90AECF54ECH1PRD0410MB369_-- From hannes.tschofenig@gmx.net Sat Jun 2 00:46:18 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A42221F895B for ; Sat, 2 Jun 2012 00:46:18 -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 1jfFitVF0sMF for ; Sat, 2 Jun 2012 00:46:17 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 2A8B921F8956 for ; Sat, 2 Jun 2012 00:46:16 -0700 (PDT) Received: (qmail invoked by alias); 02 Jun 2012 07:46:15 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.107]) [88.115.216.191] by mail.gmx.net (mp037) with SMTP; 02 Jun 2012 09:46:15 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19Zrnc8kmxZ0kCEvEGSWOB0LC4C+24+CMGW8C6Qu2 HslTMbPJA2tlmu From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 2 Jun 2012 10:46:14 +0300 Message-Id: <09CE58C6-9409-4E28-B4CA-DC76C37B898E@gmx.net> To: "oauth@ietf.org WG" Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Subject: [OAUTH-WG] Meeting slot for the Vancouver IETF meeting requested X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jun 2012 07:46:18 -0000 Hi all,=20 I have requested a 2,5 hour slot for the upcoming meeting.=20 While the next meeting is still a bit away it is nevertheless useful to = hear=20 * whether you plan to attend the next meeting, and=20 * whether you want to present something.=20 I could imagine that these documents will be discussed: * draft-ietf-oauth-dyn-reg * draft-ietf-oauth-json-web-token * draft-ietf-oauth-jwt-bearer * draft-ietf-oauth-revocation * draft-ietf-oauth-use-cases To the draft authors of these docuemnts: Please think about the open = issues and drop a mail to the list so that we make some progress already = before the face-to-face meeting.=20 I am assume that the following documents do not require any discussion = time at the upcoming IETF meeting anymore: * draft-ietf-oauth-assertions * draft-ietf-oauth-saml2-bearer * draft-ietf-oauth-urn-sub-ns * draft-ietf-oauth-v2 * draft-ietf-oauth-v2-bearer Ciao Hannes From Michael.Jones@microsoft.com Sat Jun 2 01:08:20 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9534411E8072 for ; Sat, 2 Jun 2012 01:08:20 -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 S+70iekOPDhb for ; Sat, 2 Jun 2012 01:08:20 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by ietfa.amsl.com (Postfix) with ESMTP id AF6A221F8A6D for ; Sat, 2 Jun 2012 01:08:17 -0700 (PDT) Received: from mail178-tx2-R.bigfish.com (10.9.14.236) by TX2EHSOBE010.bigfish.com (10.9.40.30) with Microsoft SMTP Server id 14.1.225.23; Sat, 2 Jun 2012 08:07:44 +0000 Received: from mail178-tx2 (localhost [127.0.0.1]) by mail178-tx2-R.bigfish.com (Postfix) with ESMTP id 088EF460201; Sat, 2 Jun 2012 08:07:44 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -42 X-BigFish: VS-42(zz9371Ic85fh179cM14ffI542M1432N98dK4015Izz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25hf0ah34h) Received-SPF: pass (mail178-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC101.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail178-tx2 (localhost.localdomain [127.0.0.1]) by mail178-tx2 (MessageSwitch) id 1338624462146071_16377; Sat, 2 Jun 2012 08:07:42 +0000 (UTC) Received: from TX2EHSMHS018.bigfish.com (unknown [10.9.14.246]) by mail178-tx2.bigfish.com (Postfix) with ESMTP id 16DE5160047; Sat, 2 Jun 2012 08:07:42 +0000 (UTC) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS018.bigfish.com (10.9.99.118) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 2 Jun 2012 08:07:39 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.189]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.02.0298.005; Sat, 2 Jun 2012 08:08:10 +0000 From: Mike Jones To: Eran Hammer , Hannes Tschofenig Thread-Topic: [OAUTH-WG] Error Encoding: Conclusion Thread-Index: AQHNORGtuzciwTXPbU2x0B3Abs7zkpbYRq5QgAA2y4CAAAHMgIAI6/dggALF+ICAAAlrAIAAHEsAgAJPNxA= Date: Sat, 2 Jun 2012 08:08:09 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436652630D@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B168042967394366516960@TK5EX14MBXC284.redmond.corp.microsoft.com> <0CBAEB56DDB3A140BA8E8C124C04ECA20104B3A1@P3PWEX2MB008.ex2.secureserver.net> <4E1F6AAD24975D4BA5B16804296739436651E440@TK5EX14MBXC284.redmond.corp.microsoft.com> <869336FE-0265-4982-B9DE-E2FAE06CD545@gmx.net> <0CBAEB56DDB3A140BA8E8C124C04ECA20105888A@P3PWEX2MB008.ex2.secureserver.net> In-Reply-To: <0CBAEB56DDB3A140BA8E8C124C04ECA20105888A@P3PWEX2MB008.ex2.secureserver.net> 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="_004_4E1F6AAD24975D4BA5B16804296739436652630DTK5EX14MBXC284r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Error Encoding: Conclusion X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 08:08:20 -0000 --_004_4E1F6AAD24975D4BA5B16804296739436652630DTK5EX14MBXC284r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable After speaking with the chairs, I volunteered to write a draft of the ABNF = text to keep things moving towards completion. An updated version of Core = including the ABNF and my previous proposed changes addressing the consensu= s call issues is attached. As long as I was at it, I also fixed the issues= that Phil identified and ran a spell/grammar check on the draft and correc= ted the issues identified. The significant diffs since my previous propose= d version, other than the new ABNF section, also follow inline for working = group review. I'll send a separate note with the new ABNF section outlining aspects of th= e ABNF that I believe should be specifically reviewed by the working group. Hopefully a new Core draft with all of these resolutions can be published s= hortly, at which point I'll be able to publish a Bearer draft that referenc= es these resolutions, enabling us to close the outstanding DISCUSS issues. Best wishes, -- Mike P.S. Bill, looking at it further, you were right that vestiges of the lead= ing ALPHA in the error syntax remained in my previous draft, making it inco= nsistent. I've addressed this in the new draft. 715,720c715,720 < o specifies the client type as described in Section 2.1, < o provides its client redirection URIs as described in < Section 3.1.2, and < o includes any other information required by the authorization < server (e.g. application name, website, description, logo image, < the acceptance of legal terms). --- > o specify the client type as described in Section 2.1, > o provide its client redirection URIs as described in Section 3.1.2, > and > o include any other information required by the authorization server > (e.g. application name, website, description, logo image, the > acceptance of legal terms). 807c807 < secret, it is exposed to the resource owner, and MUST NOT be used --- > secret; it is exposed to the resource owner, and MUST NOT be used 2663,2666c2663,2666 < Error codes MUST conform to the error-code ABNF, and SHOULD be --- > Error codes MUST conform to the error ABNF, and SHOULD be 2669,2670c2669,2670 < error-code =3D ALPHA *error-char < error-char =3D "-" / "." / "_" / DIGIT / ALPHA --- > error =3D 1*error-char > error-char =3D %x20-21 / %x23-5B / %x5D-7E < client, was issued to the that client by the authorization server. --- > client was issued to that client by the authorization server. 3128c3128 < respectively. For older browsers, javascript framebusting techniques --- > respectively. For older browsers, JavaScript framebusting techniques 3178c3178 < ([RFC5226]) after a two weeks review period on the [TBD]@ietf.org --- > ([RFC5226]) after a two week review period on the [TBD]@ietf.org 3238c3238 < Specification Required ([RFC5226]) after a two weeks review period on --- > Specification Required ([RFC5226]) after a two week review period on 3398,3403c3398,3403 < registered with a Specification Required ([RFC5226]) after a two weeks --- > registered with a Specification Required ([RFC5226]) after a two week 3463,3465c3463,3465 < after a two weeks review period on the [TBD]@ietf.org mailing list, --- > after a two week review period on the [TBD]@ietf.org mailing list, 3593a3594,3598 > [I-D.ietf-httpbis-p7-auth] > Fielding, R., Lafon, Y., and J. Reschke, "HTTP/1.1, part > 7: Authentication", draft-ietf-httpbis-p7-auth-19 (work in > progress), March 2012. >=20 3616,3621d3620 < [OASIS.saml-core-2.0-os] < Cantor, S., Kemp, J., Philpott, R., and E. Maler, < "Assertions and Protocol for the OASIS Security Assertion < Markup Language (SAML) V2.0", OASIS Standard saml-core- < 2.0-os, March 2005. <=20 3628,3633c3627,3630 < McGloin, Phil Hunt, and Anthony Nadalin. --- > McGloin, Phil Hunt, and Anthony Nadalin. The ABNF section was > drafted by Michael B. Jones. -----Original Message----- From: Eran Hammer [mailto:eran@hueniverse.com]=20 Sent: Thursday, May 31, 2012 12:35 PM To: Hannes Tschofenig Cc: Mike Jones; oauth@ietf.org WG Subject: RE: [OAUTH-WG] Error Encoding: Conclusion I'll first review the proposed text (as a WG member) and raise any issues r= emaining (if any). I will wait until the ABNF text is provided before publishing another versi= on. EH > -----Original Message----- > From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net] > Sent: Thursday, May 31, 2012 10:54 AM > To: Eran Hammer > Cc: Mike Jones; oauth@ietf.org WG; Hannes Tschofenig > Subject: Re: [OAUTH-WG] Error Encoding: Conclusion >=20 > Eran, could you publish a new draft version by Sunday with these=20 > changes incorporated? That should give the working group enough time=20 > to look at these few paragraphs. >=20 > In the meanwhile we are working on addressing the ABNF issue Sean=20 > raised and we will then go for another update. >=20 > Ciao > Hannes >=20 > On May 31, 2012, at 8:20 PM, Hannes Tschofenig wrote: >=20 > > Hi Mike, > > > > thank you for compiling the text. It looks good to me. I have not=20 > > seen > anyone from the working group screaming either. > > > > Eran, can you incorporate these changes into the next draft version? > > > > Ciao > > Hannes > > > > On May 30, 2012, at 2:10 AM, Mike Jones wrote: > > > >> I've made another set of updates to a copy of Core -26 to address=20 > >> the > questions raised by Eran and David below (attached). > >> > >> An unrelated change that you should probably pick up, Eran is=20 > >> adding this > to the section, so that the heading shows that the draft is a=20 > product of the "OAuth Working Group" rather than the "Network Working Gro= up": > >> Security > >> OAuth Working Group > >> > >> One change I didn't make, but that should be considered, is to=20 > >> delete the > reference to OASIS.saml-core-2.0-os, since it is used by no in=20 > the document. > >> > >> The new proposed text for Section 7.2 follows: > >> > >> 7.2. Error Response > >> > >> If a resource access request fails, the resource server SHOULD infor= m > >> the client of the error. While the specific error responses possibl= e > >> and methods for transmitting those errors when using any particular > >> access token type are beyond the scope of this specification, any > >> "error" code values defined for use with OAuth resource access > >> methods MUST be registered (following the procedures in > >> Section 11.4). > >> > >> Specifically, when the OAuth resource access method uses an "error" > >> result parameter to return an error code value that indicates the > >> resource access error encountered, then these error code values MUST > >> be registered. Values for these "error" codes MUST NOT include > >> characters outside the set %x20-21 / %x23-5B / %x5D-7E. When an > >> "error" code value is registered for use by an OAuth resource access > >> method, should that same code already be registered for use by > >> another OAuth resource access method or at a different OAuth error > >> usage location, then the meaning of that error code value in in the > >> new registration MUST be consistent with the its meaning in prior > >> registrations. > >> > >> The OAuth resource access error registration requirement applies onl= y > >> to "error" code values and not to other means of returning error > >> indications, including HTTP status codes, or other error-related > >> result parameters, such as "error_description", "error_uri", or othe= r > >> kinds of error status return methods that may be employed by the > >> resource access method. There is no requirement that OAuth resource > >> access methods employ an "error" parameter. > >> > >> Hopefully incorporating these changes will enable us to close the > remaining DISCUSS issues on both the Core and Bearer drafts. > >> > >> Thanks = all, > >> --=20 > >> Mike > >> > >> > >> From: Eran Hammer [mailto:eran@hueniverse.com] > >> Sent: Wednesday, May 23, 2012 11:45 PM > >> To: David Recordon; Mike Jones; Hannes Tschofenig > >> Cc: oauth@ietf.org WG > >> Subject: RE: [OAUTH-WG] Error Encoding: Conclusion > >> > >> With the exception of section 7.2, the changes look reasonable and=20 > >> will be > applied in the next revision. > >> > >> The new section 7.2 is confusion and does not explain the new registry= . > The section introduces a new requirement to register 'any error codes=20 > defined for use with OAuth resource access methods'. This requirement=20 > is too vague. > >> > >> I have no clue how to (for example) apply this text to the MAC draft. > Adding to David's list below: > >> > >> * Should the HTTP status codes used by the MAC spec as currently=20 > >> written > be registered (since no guidance is given to the use of an error paramete= r)? > >> * Does this introduce a requirement to add an error parameter? > >> * Does the parameter need to / should be called 'error'? > >> * What about future methods in which errors are not simply=20 > >> expressed in > the form of a fixes string? > >> > >> EH > >> > >> > >> From: David Recordon [mailto:recordond@gmail.com] > >> Sent: Wednesday, May 23, 2012 11:38 PM > >> To: Mike Jones; Hannes Tschofenig; Eran Hammer > >> Cc: oauth@ietf.org WG > >> Subject: Re: [OAUTH-WG] Error Encoding: Conclusion > >> > >> Honestly still trying to fully wrap my head around what's going on=20 > >> here > since it seems far more complex than the threads are alluding to. In=20 > any case, does Mike's text address what Eran brought up as needed in=20 > the thread Hannes referenced or is Eran wrong? > >> > >> The core spec currently provides full guidance and definition for=20 > >> error > extensibility. Extending the registry's scope means the need for=20 > non-trivial new text that: > >> > >> * explains the process of adding new errors for endpoints not=20 > >> defined by > this specification, > >> * finds a common ground for value restrictions beyond what is=20 > >> already > listed, > >> * guide authors of future HTTP authentication schemes meant for use > with OAuth (e.g. MAC) for their requirements for using the error=20 > registry, and > >> * address the very likely scenario of the same error code carrying > different meanings in different endpoints, or an extension that adds a=20 > location to a code already defined elsewhere - something very likely=20 > to happen if you cross the two very different domains (OAuth=20 > endpoints, Protected resource endpoints). This requires changing the=20 > entire structure of the registry to create separate records for each code= /location pair. > >> > >> Thanks, > >> --David > >> > >> On Wed, May 23, 2012 at 10:22 PM, Mike Jones > wrote: > >> Thanks Hannes. In the interest of hopefully completing the edits=20 > >> to > remove the DISCUSS issues for the Bearer and Core specs in the next=20 > few days so that we can send the docs to the RFC editors, I'd like to=20 > propose specific language for the Core spec to address both of the=20 > consensus call issue resolutions. After there's consensus on the=20 > specific text for Core, it will be easy for us to add a reference in=20 > Bearer to the language in Core for the error syntax restrictions and=20 > to use the OAuth errors registry. I'll do that in parallel with the disc= ussions on the proposed core language changes. > >> > >> > >> > >> A summary of the changes I made in response to the consensus call > conclusions are: > >> > >> * Add syntax restrictions for "error", "error_description", and > "error_uri" from Bearer to Core > >> > >> * Add section 7.2 about error responses from resource access re= quests > >> > >> * Add "resource access error response" to the category of OAuth > errors that can be registered > >> > >> > >> > >> Additional editorial changes that I made as I encountered issues in=20 > >> the > document were: > >> > >> * Updated out of date references, especially the draft-hardt-oa= uth-01 > reference, which contained an invalid link > >> > >> * Added Derek Atkins to the list of chairs > >> > >> * Added Yaron Goland's middle initial Y. (since he prefers to i= nclude it > in publications) > >> > >> * Replaced use of the deprecated element, which > prevented the spec from building with strict checking, with a=20 >
element in the section (which creates an appendix) > >> > >> > >> > >> To make it easy to incorporate these changes into the document and=20 > >> so > the proposed changes are unambiguous, I produced an edited version of=20 > Core -26 containing these changes. The xml, txt, and html versions=20 > are attached to facilitate review. Pertinent diffs from the .txt version= follow. > >> > >> > >> > >> Cheers, > >> > >> -- Mike > >> > >> > >> > >> 683c683,684 > >> > >> < notation of [RFC5234]. > >> > >> --- > >> > >>> notation of [RFC5234]. Additionally, the rule URI-Reference is > >> > >>> included from Uniform Resource Identifier (URI) [RFC3986]. > >> > >> 1441c1441,1442 > >> > >> < REQUIRED. A single error code from the following: > >> > >> --- > >> > >>> REQUIRED. A single ASCII [USASCII] error code from the > >> > >>> following: > >> > >> 1474a1475,1476 > >> > >>> Values for the "error" parameter MUST NOT include=20 > >>> characters > >> > >>> outside the set %x20-21 / %x23-5B / %x5D-7E. > >> > >> 1476c1478 > >> > >> < OPTIONAL. A human-readable UTF-8 encoded text providing > >> > >> --- > >> > >>> OPTIONAL. A human-readable ASCII [USASCII] text providing > >> > >> 1478a1481,1482 > >> > >>> Values for the "error_description" parameter MUST NOT=20 > >>> include > >> > >>> characters outside the set %x20-21 / %x23-5B / %x5D-7E. > >> > >> 1482a1487,1489 > >> > >>> Values for the "error_uri" parameter MUST conform to the=20 > >>> URI- > >> > >>> Reference syntax, and thus MUST NOT include characters=20 > >>> outside > >> > >>> the set %x21 / %x23-5B / %x5D-7E. > >> > >> 1840c1840,1841 > >> > >> < REQUIRED. A single error code from the following: > >> > >> --- > >> > >>> REQUIRED. A single ASCII [USASCII] error code from the > >> > >>> following: > >> > >> 1873a1874,1875 > >> > >>> Values for the "error" parameter MUST NOT include=20 > >>> characters > >> > >>> outside the set %x20-21 / %x23-5B / %x5D-7E. > >> > >> 1875c1877 > >> > >> < OPTIONAL. A human-readable UTF-8 encoded text providing > >> > >> --- > >> > >>> OPTIONAL. A human-readable ASCII [USASCII] text providing > >> > >> 1877a1880,1881 > >> > >>> Values for the "error_description" parameter MUST NOT=20 > >>> include > >> > >>> characters outside the set %x20-21 / %x23-5B / %x5D-7E. > >> > >> 1881a1886,1888 > >> > >>> Values for the "error_uri" parameter MUST conform to the=20 > >>> URI- > >> > >>> Reference syntax, and thus MUST NOT include characters=20 > >>> outside > >> > >>> the set %x21 / %x23-5B / %x5D-7E. > >> > >> < REQUIRED. A single error code from the following: > >> > >> --- > >> > >>> REQUIRED. A single ASCII [USASCII] error code from the > >> > >>> following: > >> > >> 2325a2326,2327 > >> > >>> Values for the "error" parameter MUST NOT include=20 > >>> characters > >> > >>> outside the set %x20-21 / %x23-5B / %x5D-7E. > >> > >> 2327c2329 > >> > >> < OPTIONAL. A human-readable UTF-8 encoded text providing > >> > >> --- > >> > >>> OPTIONAL. A human-readable ASCII [USASCII] text providing > >> > >> 2329a2332,2333 > >> > >>> Values for the "error_description" parameter MUST NOT=20 > >>> include > >> > >>> characters outside the set %x20-21 / %x23-5B / %x5D-7E. > >> > >> 2333a2338,2340 > >> > >>> Values for the "error_uri" parameter MUST conform to the=20 > >>> URI- > >> > >>> Reference syntax, and thus MUST NOT include characters=20 > >>> outside > >> > >>> the set %x21 / %x23-5B / %x5D-7E. > >> > >> 2450c2460,2468 > >> > >> < The method in which the client utilized the access token to > >> > >> --- > >> > >>> The method in which the client utilizes the access token to > >> > >> 2479c2489 > >> > >> < Authorization: Bearer 7Fjfp0ZBr1KtDRbnfVdmIw > >> > >> --- > >> > >>> Authorization: Bearer mF_9.B5f-4.1JqM > >> > >> 2503a2514,2533 > >> > >>> > >> > >>> 7.2. Error Response > >> > >>> > >> > >>> If a resource access request fails, the resource server SHOULD=20 > >>> inform > >> > >>> the client of the error. While the specific error responses=20 > >>> possible > >> > >>> and methods for transmitting those errors when using any=20 > >>> particular > >> > >>> access token type are beyond the scope of this specification,=20 > >>> any > >> > >>> error codes defined for use with OAuth resource access methods=20 > >>> MUST > >> > >>> be registered (following the procedures in Section 11.4). > >> > >>> > >> > >>> > >> > >> 2602,2603c2624,2626 > >> > >> < (Section 4.2.2.1), or the token error response (Section 5.2), suc= h > >> > >> < error codes MAY be defined. > >> > >> --- > >> > >>> (Section 4.2.2.1), the token error response (Section 5.2), or=20 > >>> the > >> > >>> resource access error response (Section 7.2), such error codes=20 > >>> MAY be > >> > >>> defined. > >> > >> 3444c3484,3485 > >> > >> < (Section 4.2.2.1), or token error response (Section 5.2). > >> > >> --- > >> > >>> (Section 4.2.2.1), token error response (Section 5.2), or=20 > >>> resource > >> > >>> access error response (Section 7.2). > >> > >> 3596a3554,3557 > >> > >>> [USASCII] American National Standards Institute, "Coded=20 > >>> Character > >> > >>> Set -- 7-bit American Standard Code for Information > >> > >>> Interchange", ANSI X3.4, 1986. > >> > >>> > >> > >> 3611,3612c3572,3573 > >> > >> < OAuth 2.0", draft-ietf-oauth-saml2-bearer-08 (work in > >> > >> < progress), August 2011. > >> > >> --- > >> > >>> OAuth 2.0", draft-ietf-oauth-saml2-bearer-12 (work in > >> > >>> progress), May 2012. > >> > >> 3616,3617c3577,3579 > >> > >> < Protocol: Bearer Tokens", draft-ietf-oauth-v2-bearer-0= 8 > >> > >> < (work in progress), July 2011. > >> > >> --- > >> > >>> Authorization Protocol: Bearer Tokens", > >> > >>> draft-ietf-oauth-v2-bearer-19 (work in progress), > >> > >>> April 2012. > >> > >> 3620,3623c3589,3591 > >> > >> < Hammer-Lahav, E., Barth, A., and B. Adida, "HTTP > >> > >> < Authentication: MAC Access Authentication", > >> > >> < draft-ietf-oauth-v2-http-mac-00 (work in progress), > >> > >> < May 2011. > >> > >> --- > >> > >>> Hammer-Lahav, E., "HTTP Authentication: MAC Access > >> > >>> Authentication", draft-ietf-oauth-v2-http-mac-01=20 > >>> (work in > >> > >>> progress), February 2012. > >> > >> 3626c3594 > >> > >> < Lodderstedt, T., McGloin, M., and P. Hunt, "OAuth 2.0 > >> > >> --- > >> > >>> McGloin, M., Hunt, P., and T. Lodderstedt, "OAuth 2.0 > >> > >> 3628,3629c3596,3597 > >> > >> < draft-ietf-oauth-v2-threatmodel-00 (work in progress), > >> > >> < July 2011. > >> > >> --- > >> > >>> draft-ietf-oauth-v2-threatmodel-02 (work in=20 > >>> progress), > >> > >>> February 2012. > >> > >> 3468,3546d3503 > >> > >> < Brian Eaton, Yaron Goland, Dick Hardt, and Allen Tom. > >> > >> 3639c3609,3639 > >> > >>> Brian Eaton, Yaron Y. Goland, Dick Hardt, and Allen Tom. > >> > >> 3468,3546d3503 > >> > >> < Yaron Goland, Brent Goldman, Kristoffer Gronowski, Justin Hart, > >> > >> 3644,3645c3644,3656 > >> > >>> Yaron Y. Goland, Brent Goldman, Kristoffer Gronowski, Justin=20 > >>> Hart, > >> > >> 3468,3546d3503 > >> > >> < This document was produced under the chairmanship of Blaine Cook, > >> > >> < Peter Saint-Andre, Hannes Tschofenig, and Barry Leiba. The area > >> > >> < directors included Lisa Dusseault, Peter Saint-Andre, and Stephen > >> > >> < Farrell. > >> > >> 3646a3658,3661 > >> > >>> This document was produced under the chairmanship of Blaine=20 > >>> Cook, > >> > >>> Peter Saint-Andre, Hannes Tschofenig, Barry Leiba, and Derek Atkins= . > >> > >>> The area directors included Lisa Dusseault, Peter Saint-Andre,=20 > >>> and > >> > >>> Stephen Farrell. > >> > >> > >> > >> -----Original Message----- > >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > Behalf Of Hannes Tschofenig > >> Sent: Wednesday, May 23, 2012 11:27 AM > >> To: oauth@ietf.org WG > >> Subject: [OAUTH-WG] Error Encoding: Conclusion > >> > >> > >> > >> Hi all, > >> > >> > >> > >> on May 10th we called for consensus on an open issue regarding the=20 > >> error > encoding. Here is the link to the call: > >> > >> http://www.ietf.org/mail-archive/web/oauth/current/msg08994.html > >> > >> > >> > >> Thank you all for the feedback. The conclusion of the consensus=20 > >> call was > to harmonize the encoding between the two specifications by=20 > incorporating the restrictions from the bearer specification into the=20 > base specification. The error encoding will go into the core=20 > specification and the bearer specification will reference it. > >> > >> > >> > >> Ciao > >> > >> Hannes & Derek > >> > >> > >> > >> _______________________________________________ > >> > >> OAuth mailing list > >> > >> OAuth@ietf.org > >> > >> https://www.ietf.org/mailman/listinfo/oauth > >> > >> > >> > >> > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > >> > >> > >> 2.txt> > > --_004_4E1F6AAD24975D4BA5B16804296739436652630DTK5EX14MBXC284r_ Content-Type: text/xml; name="draft-ietf-oauth-v2-26+mbj-3.xml" Content-Description: draft-ietf-oauth-v2-26+mbj-3.xml Content-Disposition: attachment; filename="draft-ietf-oauth-v2-26+mbj-3.xml"; size=188005; creation-date="Fri, 01 Jun 2012 18:27:27 GMT"; modification-date="Sat, 02 Jun 2012 06:15:53 GMT" Content-Transfer-Encoding: base64 PD94bWwgdmVyc2lvbj0nMS4wJyBlbmNvZGluZz0nVVRGLTgnID8+CjwhRE9DVFlQRSByZmMgU1lT VEVNICdyZmMyNjI5LmR0ZCc+Cjw/eG1sLXN0eWxlc2hlZXQgdHlwZT0ndGV4dC94c2wnIGhyZWY9 J3JmYzI2MjkueHNsdCcgPz4KCjxyZmMgY2F0ZWdvcnk9J3N0ZCcgaXByPSd0cnVzdDIwMDkwMicg b2Jzb2xldGVzPSc1ODQ5JyBkb2NOYW1lPSdkcmFmdC1pZXRmLW9hdXRoLXYyLTI3Jz4KICA8P3Jm YyBzdHJpY3Q9J3llcycgPz4KICA8P3JmYyB0b2M9J3llcycgPz4KICA8P3JmYyB0b2NkZXB0aD0n MycgPz4KICA8P3JmYyBzeW1yZWZzPSd5ZXMnID8+CiAgPD9yZmMgc29ydHJlZnM9J3llcycgPz4K ICA8P3JmYyBjb21wYWN0PSd5ZXMnID8+CiAgPD9yZmMgc3ViY29tcGFjdD0neWVzJyA/PgoKICAK ICA8ZnJvbnQ+CiAgICA8dGl0bGUgYWJicmV2PSdPQXV0aCAyLjAnPlRoZSBPQXV0aCAyLjAgQXV0 aG9yaXphdGlvbiBGcmFtZXdvcms8L3RpdGxlPgoKICAgIDxhdXRob3IgZnVsbG5hbWU9J0VyYW4g SGFtbWVyJyBzdXJuYW1lPSdIYW1tZXInIGluaXRpYWxzPSdFJyByb2xlPSdlZGl0b3InPgogICAg ICA8b3JnYW5pemF0aW9uPjwvb3JnYW5pemF0aW9uPgogICAgICA8YWRkcmVzcz4KICAgICAgICA8 ZW1haWw+ZXJhbkBodWVuaXZlcnNlLmNvbTwvZW1haWw+CiAgICAgICAgPHVyaT5odHRwOi8vaHVl bml2ZXJzZS5jb208L3VyaT4KICAgICAgPC9hZGRyZXNzPgogICAgPC9hdXRob3I+CiAgICA8YXV0 aG9yIGZ1bGxuYW1lPSdEYXZpZCBSZWNvcmRvbicgc3VybmFtZT0nUmVjb3Jkb24nIGluaXRpYWxz PSdEJz4KICAgICAgPG9yZ2FuaXphdGlvbj5GYWNlYm9vazwvb3JnYW5pemF0aW9uPgogICAgICA8 YWRkcmVzcz4KICAgICAgICA8ZW1haWw+ZHJAZmIuY29tPC9lbWFpbD4KICAgICAgICA8dXJpPmh0 dHA6Ly93d3cuZGF2aWRyZWNvcmRvbi5jb20vPC91cmk+CiAgICAgIDwvYWRkcmVzcz4KICAgIDwv YXV0aG9yPgogICAgPGF1dGhvciBmdWxsbmFtZT0nRGljayBIYXJkdCcgc3VybmFtZT0nSGFyZHQn IGluaXRpYWxzPSdEJz4KICAgICAgPG9yZ2FuaXphdGlvbj5NaWNyb3NvZnQ8L29yZ2FuaXphdGlv bj4KICAgICAgPGFkZHJlc3M+CiAgICAgICAgPGVtYWlsPmRpY2suaGFyZHRAZ21haWwuY29tPC9l bWFpbD4KICAgICAgICA8dXJpPmh0dHA6Ly9kaWNraGFyZHQub3JnLzwvdXJpPgogICAgICA8L2Fk ZHJlc3M+CiAgICA8L2F1dGhvcj4KCiAgICA8ZGF0ZSB5ZWFyPScyMDEyJyAvPgoKICAgIDxhcmVh PlNlY3VyaXR5PC9hcmVhPgogICAgPHdvcmtncm91cD5PQXV0aCBXb3JraW5nIEdyb3VwPC93b3Jr Z3JvdXA+CgogICAgPGFic3RyYWN0PgogICAgICA8dD4KICAgICAgICBUaGUgT0F1dGggMi4wIGF1 dGhvcml6YXRpb24gZnJhbWV3b3JrIGVuYWJsZXMgYSB0aGlyZC1wYXJ0eSBhcHBsaWNhdGlvbiB0 byBvYnRhaW4gbGltaXRlZAogICAgICAgIGFjY2VzcyB0byBhbiBIVFRQIHNlcnZpY2UsIGVpdGhl ciBvbiBiZWhhbGYgb2YgYSByZXNvdXJjZSBvd25lciBieSBvcmNoZXN0cmF0aW5nIGFuIGFwcHJv dmFsCiAgICAgICAgaW50ZXJhY3Rpb24gYmV0d2VlbiB0aGUgcmVzb3VyY2Ugb3duZXIgYW5kIHRo ZSBIVFRQIHNlcnZpY2UsIG9yIGJ5IGFsbG93aW5nIHRoZSB0aGlyZC1wYXJ0eQogICAgICAgIGFw cGxpY2F0aW9uIHRvIG9idGFpbiBhY2Nlc3Mgb24gaXRzIG93biBiZWhhbGYuIFRoaXMgc3BlY2lm aWNhdGlvbiByZXBsYWNlcyBhbmQgb2Jzb2xldGVzCiAgICAgICAgdGhlIE9BdXRoIDEuMCBwcm90 b2NvbCBkZXNjcmliZWQgaW4gUkZDIDU4NDkuCiAgICAgIDwvdD4KICAgIDwvYWJzdHJhY3Q+CiAg PC9mcm9udD4KCiAgPG1pZGRsZT4KCiAgICA8c2VjdGlvbiB0aXRsZT0nSW50cm9kdWN0aW9uJz4K ICAgICAgPHQ+CiAgICAgICAgSW4gdGhlIHRyYWRpdGlvbmFsIGNsaWVudC1zZXJ2ZXIgYXV0aGVu dGljYXRpb24gbW9kZWwsIHRoZSBjbGllbnQgcmVxdWVzdHMgYW4gYWNjZXNzCiAgICAgICAgcmVz dHJpY3RlZCByZXNvdXJjZSAocHJvdGVjdGVkIHJlc291cmNlKSBvbiB0aGUgc2VydmVyIGJ5IGF1 dGhlbnRpY2F0aW5nIHdpdGggdGhlIHNlcnZlcgogICAgICAgIHVzaW5nIHRoZSByZXNvdXJjZSBv d25lcidzIGNyZWRlbnRpYWxzLiBJbiBvcmRlciB0byBwcm92aWRlIHRoaXJkLXBhcnR5IGFwcGxp Y2F0aW9ucyBhY2Nlc3MKICAgICAgICB0byByZXN0cmljdGVkIHJlc291cmNlcywgdGhlIHJlc291 cmNlIG93bmVyIHNoYXJlcyBpdHMgY3JlZGVudGlhbHMgd2l0aCB0aGUgdGhpcmQtcGFydHkuCiAg ICAgICAgVGhpcyBjcmVhdGVzIHNldmVyYWwgcHJvYmxlbXMgYW5kIGxpbWl0YXRpb25zOgogICAg ICA8L3Q+CiAgICAgIDx0PgogICAgICAgIDxsaXN0IHN0eWxlPSdzeW1ib2xzJz4KICAgICAgICAg IDx0PgogICAgICAgICAgICBUaGlyZC1wYXJ0eSBhcHBsaWNhdGlvbnMgYXJlIHJlcXVpcmVkIHRv IHN0b3JlIHRoZSByZXNvdXJjZSBvd25lcidzIGNyZWRlbnRpYWxzCiAgICAgICAgICAgIGZvciBm dXR1cmUgdXNlLCB0eXBpY2FsbHkgYSBwYXNzd29yZCBpbiBjbGVhci10ZXh0LgogICAgICAgICAg PC90PgogICAgICAgICAgPHQ+CiAgICAgICAgICAgIFNlcnZlcnMgYXJlIHJlcXVpcmVkIHRvIHN1 cHBvcnQgcGFzc3dvcmQgYXV0aGVudGljYXRpb24sIGRlc3BpdGUgdGhlIHNlY3VyaXR5CiAgICAg ICAgICAgIHdlYWtuZXNzZXMgaW5oZXJlbnQgaW4gcGFzc3dvcmRzLgogICAgICAgICAgPC90Pgog ICAgICAgICAgPHQ+CiAgICAgICAgICAgIFRoaXJkLXBhcnR5IGFwcGxpY2F0aW9ucyBnYWluIG92 ZXJseSBicm9hZCBhY2Nlc3MgdG8gdGhlIHJlc291cmNlIG93bmVyJ3MgcHJvdGVjdGVkCiAgICAg ICAgICAgIHJlc291cmNlcywgbGVhdmluZyByZXNvdXJjZSBvd25lcnMgd2l0aG91dCBhbnkgYWJp bGl0eSB0byByZXN0cmljdCBkdXJhdGlvbiBvciBhY2Nlc3MKICAgICAgICAgICAgdG8gYSBsaW1p dGVkIHN1YnNldCBvZiByZXNvdXJjZXMuCiAgICAgICAgICA8L3Q+CiAgICAgICAgICA8dD4KICAg ICAgICAgICAgUmVzb3VyY2Ugb3duZXJzIGNhbm5vdCByZXZva2UgYWNjZXNzIHRvIGFuIGluZGl2 aWR1YWwgdGhpcmQtcGFydHkgd2l0aG91dCByZXZva2luZwogICAgICAgICAgICBhY2Nlc3MgdG8g YWxsIHRoaXJkLXBhcnRpZXMsIGFuZCBtdXN0IGRvIHNvIGJ5IGNoYW5naW5nIHRoZWlyIHBhc3N3 b3JkLgogICAgICAgICAgPC90PgogICAgICAgICAgPHQ+CiAgICAgICAgICAgIENvbXByb21pc2Ug b2YgYW55IHRoaXJkLXBhcnR5IGFwcGxpY2F0aW9uIHJlc3VsdHMgaW4gY29tcHJvbWlzZSBvZiB0 aGUgZW5kLXVzZXIncwogICAgICAgICAgICBwYXNzd29yZCBhbmQgYWxsIG9mIHRoZSBkYXRhIHBy b3RlY3RlZCBieSB0aGF0IHBhc3N3b3JkLgogICAgICAgICAgPC90PgogICAgICAgIDwvbGlzdD4K ICAgICAgPC90PgogICAgICA8dD4KICAgICAgICBPQXV0aCBhZGRyZXNzZXMgdGhlc2UgaXNzdWVz IGJ5IGludHJvZHVjaW5nIGFuIGF1dGhvcml6YXRpb24gbGF5ZXIgYW5kIHNlcGFyYXRpbmcgdGhl IHJvbGUKICAgICAgICBvZiB0aGUgY2xpZW50IGZyb20gdGhhdCBvZiB0aGUgcmVzb3VyY2Ugb3du ZXIuIEluIE9BdXRoLCB0aGUgY2xpZW50IHJlcXVlc3RzIGFjY2VzcyB0bwogICAgICAgIHJlc291 cmNlcyBjb250cm9sbGVkIGJ5IHRoZSByZXNvdXJjZSBvd25lciBhbmQgaG9zdGVkIGJ5IHRoZSBy ZXNvdXJjZSBzZXJ2ZXIsIGFuZCBpcyBpc3N1ZWQKICAgICAgICBhIGRpZmZlcmVudCBzZXQgb2Yg Y3JlZGVudGlhbHMgdGhhbiB0aG9zZSBvZiB0aGUgcmVzb3VyY2Ugb3duZXIuCiAgICAgIDwvdD4K ICAgICAgPHQ+CiAgICAgICAgSW5zdGVhZCBvZiB1c2luZyB0aGUgcmVzb3VyY2Ugb3duZXIncyBj cmVkZW50aWFscyB0byBhY2Nlc3MgcHJvdGVjdGVkIHJlc291cmNlcywgdGhlIGNsaWVudAogICAg ICAgIG9idGFpbnMgYW4gYWNjZXNzIHRva2VuIC0gYSBzdHJpbmcgZGVub3RpbmcgYSBzcGVjaWZp YyBzY29wZSwgbGlmZXRpbWUsIGFuZCBvdGhlciBhY2Nlc3MKICAgICAgICBhdHRyaWJ1dGVzLiBB Y2Nlc3MgdG9rZW5zIGFyZSBpc3N1ZWQgdG8gdGhpcmQtcGFydHkgY2xpZW50cyBieSBhbiBhdXRo b3JpemF0aW9uIHNlcnZlciB3aXRoCiAgICAgICAgdGhlIGFwcHJvdmFsIG9mIHRoZSByZXNvdXJj ZSBvd25lci4gVGhlIGNsaWVudCB1c2VzIHRoZSBhY2Nlc3MgdG9rZW4gdG8gYWNjZXNzIHRoZQog ICAgICAgIHByb3RlY3RlZCByZXNvdXJjZXMgaG9zdGVkIGJ5IHRoZSByZXNvdXJjZSBzZXJ2ZXIu CiAgICAgIDwvdD4KICAgICAgPHQ+CiAgICAgICAgRm9yIGV4YW1wbGUsIGFuIGVuZC11c2VyIChy ZXNvdXJjZSBvd25lcikgY2FuIGdyYW50IGEgcHJpbnRpbmcgc2VydmljZSAoY2xpZW50KSBhY2Nl c3MKICAgICAgICB0byBoZXIgcHJvdGVjdGVkIHBob3RvcyBzdG9yZWQgYXQgYSBwaG90byBzaGFy aW5nIHNlcnZpY2UgKHJlc291cmNlIHNlcnZlciksIHdpdGhvdXQKICAgICAgICBzaGFyaW5nIGhl ciB1c2VybmFtZSBhbmQgcGFzc3dvcmQgd2l0aCB0aGUgcHJpbnRpbmcgc2VydmljZS4gSW5zdGVh ZCwgc2hlIGF1dGhlbnRpY2F0ZXMKICAgICAgICBkaXJlY3RseSB3aXRoIGEgc2VydmVyIHRydXN0 ZWQgYnkgdGhlIHBob3RvIHNoYXJpbmcgc2VydmljZSAoYXV0aG9yaXphdGlvbiBzZXJ2ZXIpIHdo aWNoCiAgICAgICAgaXNzdWVzIHRoZSBwcmludGluZyBzZXJ2aWNlIGRlbGVnYXRpb24tc3BlY2lm aWMgY3JlZGVudGlhbHMgKGFjY2VzcyB0b2tlbikuCiAgICAgIDwvdD4KICAgICAgPHQ+CiAgICAg ICAgVGhpcyBzcGVjaWZpY2F0aW9uIGlzIGRlc2lnbmVkIGZvciB1c2Ugd2l0aCBIVFRQICg8eHJl ZiB0YXJnZXQ9J1JGQzI2MTYnIC8+KS4gVGhlIHVzZSBvZgogICAgICAgIE9BdXRoIG92ZXIgYW55 IG90aGVyIHByb3RvY29sIHRoYW4gSFRUUCBpcyBvdXQgb2Ygc2NvcGUuCiAgICAgIDwvdD4KICAg ICAgPHQ+CiAgICAgICAgVGhlIE9BdXRoIDEuMCBwcm90b2NvbCAoPHhyZWYgdGFyZ2V0PSdSRkM1 ODQ5JyAvPiksIHB1Ymxpc2hlZCBhcyBhbiBpbmZvcm1hdGlvbmFsIGRvY3VtZW50LAogICAgICAg IHdhcyB0aGUgcmVzdWx0IG9mIGEgc21hbGwgYWQtaG9jIGNvbW11bml0eSBlZmZvcnQuIFRoaXMg c3RhbmRhcmRzLXRyYWNrIHNwZWNpZmljYXRpb24gYnVpbGRzCiAgICAgICAgb24gdGhlIE9BdXRo IDEuMCBkZXBsb3ltZW50IGV4cGVyaWVuY2UsIGFzIHdlbGwgYXMgYWRkaXRpb25hbCB1c2UgY2Fz ZXMgYW5kIGV4dGVuc2liaWxpdHkKICAgICAgICByZXF1aXJlbWVudHMgZ2F0aGVyZWQgZnJvbSB0 aGUgd2lkZXIgSUVURiBjb21tdW5pdHkuIFRoZSBPQXV0aCAyLjAgcHJvdG9jb2wgaXMgbm90IGJh Y2t3YXJkCiAgICAgICAgY29tcGF0aWJsZSB3aXRoIE9BdXRoIDEuMC4gVGhlIHR3byB2ZXJzaW9u cyBtYXkgY28tZXhpc3Qgb24gdGhlIG5ldHdvcmsgYW5kIGltcGxlbWVudGF0aW9ucwogICAgICAg IG1heSBjaG9vc2UgdG8gc3VwcG9ydCBib3RoLiBIb3dldmVyLCBpdCBpcyB0aGUgaW50ZW50aW9u IG9mIHRoaXMgc3BlY2lmaWNhdGlvbiB0aGF0IG5ldwogICAgICAgIGltcGxlbWVudGF0aW9uIHN1 cHBvcnQgT0F1dGggMi4wIGFzIHNwZWNpZmllZCBpbiB0aGlzIGRvY3VtZW50LCBhbmQgdGhhdCBP QXV0aCAxLjAgaXMgdXNlZAogICAgICAgIG9ubHkgdG8gc3VwcG9ydCBleGlzdGluZyBkZXBsb3lt ZW50cy4gVGhlIE9BdXRoIDIuMCBwcm90b2NvbCBzaGFyZXMgdmVyeSBmZXcgaW1wbGVtZW50YXRp b24KICAgICAgICBkZXRhaWxzIHdpdGggdGhlIE9BdXRoIDEuMCBwcm90b2NvbC4gSW1wbGVtZW50 ZXJzIGZhbWlsaWFyIHdpdGggT0F1dGggMS4wIHNob3VsZCBhcHByb2FjaAogICAgICAgIHRoaXMg ZG9jdW1lbnQgd2l0aG91dCBhbnkgYXNzdW1wdGlvbnMgYXMgdG8gaXRzIHN0cnVjdHVyZSBhbmQg ZGV0YWlscy4KICAgICAgPC90PgoKICAgICAgPHNlY3Rpb24gdGl0bGU9J1JvbGVzJz4KICAgICAg ICA8dD4KICAgICAgICAgIE9BdXRoIGRlZmluZXMgZm91ciByb2xlczoKICAgICAgICA8L3Q+CiAg ICAgICAgPHQ+CiAgICAgICAgICA8bGlzdCBzdHlsZT0naGFuZ2luZyc+CiAgICAgICAgICAgIDx0 IGhhbmdUZXh0PSdyZXNvdXJjZSBvd25lcic+CiAgICAgICAgICAgICAgPHZzcGFjZSAvPgogICAg ICAgICAgICAgIEFuIGVudGl0eSBjYXBhYmxlIG9mIGdyYW50aW5nIGFjY2VzcyB0byBhIHByb3Rl Y3RlZCByZXNvdXJjZS4gV2hlbiB0aGUgcmVzb3VyY2Ugb3duZXIKICAgICAgICAgICAgICBpcyBh IHBlcnNvbiwgaXQgaXMgcmVmZXJyZWQgdG8gYXMgYW4gZW5kLXVzZXIuCiAgICAgICAgICAgIDwv dD4KICAgICAgICAgICAgPHQgaGFuZ1RleHQ9J3Jlc291cmNlIHNlcnZlcic+CiAgICAgICAgICAg ICAgPHZzcGFjZSAvPgogICAgICAgICAgICAgIFRoZSBzZXJ2ZXIgaG9zdGluZyB0aGUgcHJvdGVj dGVkIHJlc291cmNlcywgY2FwYWJsZSBvZiBhY2NlcHRpbmcgYW5kIHJlc3BvbmRpbmcgdG8KICAg ICAgICAgICAgICBwcm90ZWN0ZWQgcmVzb3VyY2UgcmVxdWVzdHMgdXNpbmcgYWNjZXNzIHRva2Vu cy4KICAgICAgICAgICAgPC90PgogICAgICAgICAgICA8dCBoYW5nVGV4dD0nY2xpZW50Jz4KICAg ICAgICAgICAgICA8dnNwYWNlIC8+CiAgICAgICAgICAgICAgQW4gYXBwbGljYXRpb24gbWFraW5n IHByb3RlY3RlZCByZXNvdXJjZSByZXF1ZXN0cyBvbiBiZWhhbGYgb2YgdGhlIHJlc291cmNlIG93 bmVyIGFuZAogICAgICAgICAgICAgIHdpdGggaXRzIGF1dGhvcml6YXRpb24uIFRoZSB0ZXJtIGNs aWVudCBkb2VzIG5vdCBpbXBseSBhbnkgcGFydGljdWxhciBpbXBsZW1lbnRhdGlvbgogICAgICAg ICAgICAgIGNoYXJhY3RlcmlzdGljcyAoZS5nLiB3aGV0aGVyIHRoZSBhcHBsaWNhdGlvbiBleGVj dXRlcyBvbiBhIHNlcnZlciwgYSBkZXNrdG9wLCBvcgogICAgICAgICAgICAgIG90aGVyIGRldmlj ZXMpLgogICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgIDx0IGhhbmdUZXh0PSdhdXRob3JpemF0 aW9uIHNlcnZlcic+CiAgICAgICAgICAgICAgPHZzcGFjZSAvPgogICAgICAgICAgICAgIFRoZSBz ZXJ2ZXIgaXNzdWluZyBhY2Nlc3MgdG9rZW5zIHRvIHRoZSBjbGllbnQgYWZ0ZXIgc3VjY2Vzc2Z1 bGx5IGF1dGhlbnRpY2F0aW5nIHRoZQogICAgICAgICAgICAgIHJlc291cmNlIG93bmVyIGFuZCBv YnRhaW5pbmcgYXV0aG9yaXphdGlvbi4KICAgICAgICAgICAgPC90PgogICAgICAgICAgPC9saXN0 PgogICAgICAgIDwvdD4KICAgICAgICA8dD4KICAgICAgICAgIFRoZSBpbnRlcmFjdGlvbiBiZXR3 ZWVuIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBhbmQgcmVzb3VyY2Ugc2VydmVyIGlzIGJleW9u ZCB0aGUgc2NvcGUKICAgICAgICAgIG9mIHRoaXMgc3BlY2lmaWNhdGlvbi4gVGhlIGF1dGhvcml6 YXRpb24gc2VydmVyIG1heSBiZSB0aGUgc2FtZSBzZXJ2ZXIgYXMgdGhlIHJlc291cmNlCiAgICAg ICAgICBzZXJ2ZXIgb3IgYSBzZXBhcmF0ZSBlbnRpdHkuIEEgc2luZ2xlIGF1dGhvcml6YXRpb24g c2VydmVyIG1heSBpc3N1ZSBhY2Nlc3MgdG9rZW5zCiAgICAgICAgICBhY2NlcHRlZCBieSBtdWx0 aXBsZSByZXNvdXJjZSBzZXJ2ZXJzLgogICAgICAgIDwvdD4KICAgICAgPC9zZWN0aW9uPgoKICAg ICAgPHNlY3Rpb24gdGl0bGU9J1Byb3RvY29sIEZsb3cnPgogICAgICAgIDxmaWd1cmUgdGl0bGU9 J0Fic3RyYWN0IFByb3RvY29sIEZsb3cnIGFuY2hvcj0nRmlndXJlLTEnPgogICAgICAgICAgPGFy dHdvcms+CiAgICAgICAgICAgIDwhW0NEQVRBWwogICstLS0tLS0tLSsgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLSsKICB8ICAgICAgICB8LS0oQSktIEF1dGhv cml6YXRpb24gUmVxdWVzdCAtPnwgICBSZXNvdXJjZSAgICB8CiAgfCAgICAgICAgfCAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB8ICAgICBPd25lciAgICAgfAogIHwgICAgICAgIHw8LShC KS0tIEF1dGhvcml6YXRpb24gR3JhbnQgLS0tfCAgICAgICAgICAgICAgIHwKICB8ICAgICAgICB8 ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0rCiAgfCAgICAg ICAgfAogIHwgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0t LS0tLS0tLSsKICB8ICAgICAgICB8LS0oQyktLSBBdXRob3JpemF0aW9uIEdyYW50IC0tPnwgQXV0 aG9yaXphdGlvbiB8CiAgfCBDbGllbnQgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8 ICAgICBTZXJ2ZXIgICAgfAogIHwgICAgICAgIHw8LShEKS0tLS0tIEFjY2VzcyBUb2tlbiAtLS0t LS0tfCAgICAgICAgICAgICAgIHwKICB8ICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICstLS0tLS0tLS0tLS0tLS0rCiAgfCAgICAgICAgfAogIHwgICAgICAgIHwgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLSsKICB8ICAgICAgICB8LS0o RSktLS0tLSBBY2Nlc3MgVG9rZW4gLS0tLS0tPnwgICAgUmVzb3VyY2UgICB8CiAgfCAgICAgICAg fCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICBTZXJ2ZXIgICAgfAogIHwgICAg ICAgIHw8LShGKS0tLSBQcm90ZWN0ZWQgUmVzb3VyY2UgLS0tfCAgICAgICAgICAgICAgIHwKICAr LS0tLS0tLS0rICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0r Cl1dPgogICAgICAgICAgPC9hcnR3b3JrPgogICAgICAgIDwvZmlndXJlPgogICAgICAgIDx0Pgog ICAgICAgICAgVGhlIGFic3RyYWN0IGZsb3cgaWxsdXN0cmF0ZWQgaW4gPHhyZWYgdGFyZ2V0PSdG aWd1cmUtMScgLz4gZGVzY3JpYmVzIHRoZSBpbnRlcmFjdGlvbgogICAgICAgICAgYmV0d2VlbiB0 aGUgZm91ciByb2xlcyBhbmQgaW5jbHVkZXMgdGhlIGZvbGxvd2luZyBzdGVwczoKICAgICAgICA8 L3Q+CiAgICAgICAgPHQ+CiAgICAgICAgICA8bGlzdCBzdHlsZT0nZm9ybWF0ICglQyknPgogICAg ICAgICAgICA8dD4KICAgICAgICAgICAgICBUaGUgY2xpZW50IHJlcXVlc3RzIGF1dGhvcml6YXRp b24gZnJvbSB0aGUgcmVzb3VyY2Ugb3duZXIuIFRoZSBhdXRob3JpemF0aW9uIHJlcXVlc3QKICAg ICAgICAgICAgICBjYW4gYmUgbWFkZSBkaXJlY3RseSB0byB0aGUgcmVzb3VyY2Ugb3duZXIgKGFz IHNob3duKSwgb3IgcHJlZmVyYWJseSBpbmRpcmVjdGx5IHZpYQogICAgICAgICAgICAgIHRoZSBh dXRob3JpemF0aW9uIHNlcnZlciBhcyBhbiBpbnRlcm1lZGlhcnkuCiAgICAgICAgICAgIDwvdD4K ICAgICAgICAgICAgPHQ+CiAgICAgICAgICAgICAgVGhlIGNsaWVudCByZWNlaXZlcyBhbiBhdXRo b3JpemF0aW9uIGdyYW50IHdoaWNoIGlzIGEgY3JlZGVudGlhbCByZXByZXNlbnRpbmcKICAgICAg ICAgICAgICB0aGUgcmVzb3VyY2Ugb3duZXIncyBhdXRob3JpemF0aW9uLCBleHByZXNzZWQgdXNp bmcgb25lIG9mIGZvdXIgZ3JhbnQgdHlwZXMgZGVmaW5lZAogICAgICAgICAgICAgIGluIHRoaXMg c3BlY2lmaWNhdGlvbiBvciB1c2luZyBhbiBleHRlbnNpb24gZ3JhbnQgdHlwZS4gVGhlIGF1dGhv cml6YXRpb24gZ3JhbnQgdHlwZQogICAgICAgICAgICAgIGRlcGVuZHMgb24gdGhlIG1ldGhvZCB1 c2VkIGJ5IHRoZSBjbGllbnQgdG8gcmVxdWVzdCBhdXRob3JpemF0aW9uIGFuZCB0aGUgdHlwZXMK ICAgICAgICAgICAgICBzdXBwb3J0ZWQgYnkgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLgogICAg ICAgICAgICA8L3Q+CiAgICAgICAgICAgIDx0PgogICAgICAgICAgICAgIFRoZSBjbGllbnQgcmVx dWVzdHMgYW4gYWNjZXNzIHRva2VuIGJ5IGF1dGhlbnRpY2F0aW5nIHdpdGggdGhlIGF1dGhvcml6 YXRpb24gc2VydmVyCiAgICAgICAgICAgICAgYW5kIHByZXNlbnRpbmcgdGhlIGF1dGhvcml6YXRp b24gZ3JhbnQuCiAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAgPHQ+CiAgICAgICAgICAgICAg VGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGF1dGhlbnRpY2F0ZXMgdGhlIGNsaWVudCBhbmQgdmFs aWRhdGVzIHRoZSBhdXRob3JpemF0aW9uCiAgICAgICAgICAgICAgZ3JhbnQsIGFuZCBpZiB2YWxp ZCBpc3N1ZXMgYW4gYWNjZXNzIHRva2VuLgogICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgIDx0 PgogICAgICAgICAgICAgIFRoZSBjbGllbnQgcmVxdWVzdHMgdGhlIHByb3RlY3RlZCByZXNvdXJj ZSBmcm9tIHRoZSByZXNvdXJjZSBzZXJ2ZXIgYW5kIGF1dGhlbnRpY2F0ZXMKICAgICAgICAgICAg ICBieSBwcmVzZW50aW5nIHRoZSBhY2Nlc3MgdG9rZW4uCiAgICAgICAgICAgIDwvdD4KICAgICAg ICAgICAgPHQ+CiAgICAgICAgICAgICAgVGhlIHJlc291cmNlIHNlcnZlciB2YWxpZGF0ZXMgdGhl IGFjY2VzcyB0b2tlbiwgYW5kIGlmIHZhbGlkLCBzZXJ2ZXMgdGhlIHJlcXVlc3QuCiAgICAgICAg ICAgIDwvdD4KICAgICAgICAgIDwvbGlzdD4KICAgICAgICA8L3Q+CiAgICAgICAgPHQ+CiAgICAg ICAgICBUaGUgcHJlZmVycmVkIG1ldGhvZCBmb3IgdGhlIGNsaWVudCB0byBvYnRhaW4gYW4gYXV0 aG9yaXphdGlvbiBncmFudCBmcm9tIHRoZSByZXNvdXJjZQogICAgICAgICAgb3duZXIgKGRlcGlj dGVkIGluIHN0ZXBzIChBKSBhbmQgKEIpKSBpcyB0byB1c2UgdGhlIGF1dGhvcml6YXRpb24gc2Vy dmVyIGFzIGFuIGludGVybWVkaWFyeQogICAgICAgICAgd2hpY2ggaXMgaWxsdXN0cmF0ZWQgaW4g PHhyZWYgdGFyZ2V0PSdGaWd1cmUtMycgLz4uCiAgICAgICAgPC90PgogICAgICA8L3NlY3Rpb24+ CgogICAgICA8c2VjdGlvbiB0aXRsZT0nQXV0aG9yaXphdGlvbiBHcmFudCc+CiAgICAgICAgPHQ+ CiAgICAgICAgICBBbiBhdXRob3JpemF0aW9uIGdyYW50IGlzIGEgY3JlZGVudGlhbCByZXByZXNl bnRpbmcgdGhlIHJlc291cmNlIG93bmVyJ3MgYXV0aG9yaXphdGlvbgogICAgICAgICAgKHRvIGFj Y2VzcyBpdHMgcHJvdGVjdGVkIHJlc291cmNlcykgdXNlZCBieSB0aGUgY2xpZW50IHRvIG9idGFp biBhbiBhY2Nlc3MgdG9rZW4uIFRoaXMKICAgICAgICAgIHNwZWNpZmljYXRpb24gZGVmaW5lcyBm b3VyIGdyYW50IHR5cGVzOiBhdXRob3JpemF0aW9uIGNvZGUsIGltcGxpY2l0LCByZXNvdXJjZSBv d25lcgogICAgICAgICAgcGFzc3dvcmQgY3JlZGVudGlhbHMsIGFuZCBjbGllbnQgY3JlZGVudGlh bHMsIGFzIHdlbGwgYXMgYW4gZXh0ZW5zaWJpbGl0eSBtZWNoYW5pc20gZm9yCiAgICAgICAgICBk ZWZpbmluZyBhZGRpdGlvbmFsIHR5cGVzLgogICAgICAgIDwvdD4KCiAgICAgICAgPHNlY3Rpb24g dGl0bGU9J0F1dGhvcml6YXRpb24gQ29kZSc+CiAgICAgICAgICA8dD4KICAgICAgICAgICAgVGhl IGF1dGhvcml6YXRpb24gY29kZSBpcyBvYnRhaW5lZCBieSB1c2luZyBhbiBhdXRob3JpemF0aW9u IHNlcnZlciBhcyBhbiBpbnRlcm1lZGlhcnkKICAgICAgICAgICAgYmV0d2VlbiB0aGUgY2xpZW50 IGFuZCByZXNvdXJjZSBvd25lci4gSW5zdGVhZCBvZiByZXF1ZXN0aW5nIGF1dGhvcml6YXRpb24g ZGlyZWN0bHkKICAgICAgICAgICAgZnJvbSB0aGUgcmVzb3VyY2Ugb3duZXIsIHRoZSBjbGllbnQg ZGlyZWN0cyB0aGUgcmVzb3VyY2Ugb3duZXIgdG8gYW4gYXV0aG9yaXphdGlvbgogICAgICAgICAg ICBzZXJ2ZXIgKHZpYSBpdHMgdXNlci1hZ2VudCBhcyBkZWZpbmVkIGluIDx4cmVmIHRhcmdldD0n UkZDMjYxNicgLz4pLCB3aGljaCBpbiB0dXJuCiAgICAgICAgICAgIGRpcmVjdHMgdGhlIHJlc291 cmNlIG93bmVyIGJhY2sgdG8gdGhlIGNsaWVudCB3aXRoIHRoZSBhdXRob3JpemF0aW9uIGNvZGUu CiAgICAgICAgICA8L3Q+CiAgICAgICAgICA8dD4KICAgICAgICAgICAgQmVmb3JlIGRpcmVjdGlu ZyB0aGUgcmVzb3VyY2Ugb3duZXIgYmFjayB0byB0aGUgY2xpZW50IHdpdGggdGhlIGF1dGhvcml6 YXRpb24gY29kZSwgdGhlCiAgICAgICAgICAgIGF1dGhvcml6YXRpb24gc2VydmVyIGF1dGhlbnRp Y2F0ZXMgdGhlIHJlc291cmNlIG93bmVyIGFuZCBvYnRhaW5zIGF1dGhvcml6YXRpb24uCiAgICAg ICAgICAgIEJlY2F1c2UgdGhlIHJlc291cmNlIG93bmVyIG9ubHkgYXV0aGVudGljYXRlcyB3aXRo IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciwgdGhlCiAgICAgICAgICAgIHJlc291cmNlIG93bmVy J3MgY3JlZGVudGlhbHMgYXJlIG5ldmVyIHNoYXJlZCB3aXRoIHRoZSBjbGllbnQuCiAgICAgICAg ICA8L3Q+CiAgICAgICAgICA8dD4KICAgICAgICAgICAgVGhlIGF1dGhvcml6YXRpb24gY29kZSBw cm92aWRlcyBhIGZldyBpbXBvcnRhbnQgc2VjdXJpdHkgYmVuZWZpdHMgc3VjaCBhcyB0aGUgYWJp bGl0eQogICAgICAgICAgICB0byBhdXRoZW50aWNhdGUgdGhlIGNsaWVudCwgYW5kIHRoZSB0cmFu c21pc3Npb24gb2YgdGhlIGFjY2VzcyB0b2tlbiBkaXJlY3RseSB0bwogICAgICAgICAgICB0aGUg Y2xpZW50IHdpdGhvdXQgcGFzc2luZyBpdCB0aHJvdWdoIHRoZSByZXNvdXJjZSBvd25lcidzIHVz ZXItYWdlbnQsIHBvdGVudGlhbGx5CiAgICAgICAgICAgIGV4cG9zaW5nIGl0IHRvIG90aGVycywg aW5jbHVkaW5nIHRoZSByZXNvdXJjZSBvd25lci4KICAgICAgICAgIDwvdD4KICAgICAgICA8L3Nl Y3Rpb24+CgogICAgICAgIDxzZWN0aW9uIHRpdGxlPSdJbXBsaWNpdCc+CiAgICAgICAgICA8dD4K ICAgICAgICAgICAgVGhlIGltcGxpY2l0IGdyYW50IGlzIGEgc2ltcGxpZmllZCBhdXRob3JpemF0 aW9uIGNvZGUgZmxvdyBvcHRpbWl6ZWQgZm9yIGNsaWVudHMKICAgICAgICAgICAgaW1wbGVtZW50 ZWQgaW4gYSBicm93c2VyIHVzaW5nIGEgc2NyaXB0aW5nIGxhbmd1YWdlIHN1Y2ggYXMgSmF2YVNj cmlwdC4gSW4gdGhlIGltcGxpY2l0CiAgICAgICAgICAgIGZsb3csIGluc3RlYWQgb2YgaXNzdWlu ZyB0aGUgY2xpZW50IGFuIGF1dGhvcml6YXRpb24gY29kZSwgdGhlIGNsaWVudCBpcyBpc3N1ZWQg YW4KICAgICAgICAgICAgYWNjZXNzIHRva2VuIGRpcmVjdGx5IChhcyB0aGUgcmVzdWx0IG9mIHRo ZSByZXNvdXJjZSBvd25lciBhdXRob3JpemF0aW9uKS4gVGhlIGdyYW50CiAgICAgICAgICAgIHR5 cGUgaXMgaW1wbGljaXQgYXMgbm8gaW50ZXJtZWRpYXRlIGNyZWRlbnRpYWxzIChzdWNoIGFzIGFu IGF1dGhvcml6YXRpb24gY29kZSkgYXJlCiAgICAgICAgICAgIGlzc3VlZCAoYW5kIGxhdGVyIHVz ZWQgdG8gb2J0YWluIGFuIGFjY2VzcyB0b2tlbikuCiAgICAgICAgICA8L3Q+CiAgICAgICAgICA8 dD4KICAgICAgICAgICAgV2hlbiBpc3N1aW5nIGFuIGFjY2VzcyB0b2tlbiBkdXJpbmcgdGhlIGlt cGxpY2l0IGdyYW50IGZsb3csIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlcgogICAgICAgICAgICBk b2VzIG5vdCBhdXRoZW50aWNhdGUgdGhlIGNsaWVudC4gSW4gc29tZSBjYXNlcywgdGhlIGNsaWVu dCBpZGVudGl0eSBjYW4gYmUgdmVyaWZpZWQKICAgICAgICAgICAgdmlhIHRoZSByZWRpcmVjdGlv biBVUkkgdXNlZCB0byBkZWxpdmVyIHRoZSBhY2Nlc3MgdG9rZW4gdG8gdGhlIGNsaWVudC4gVGhl IGFjY2VzcwogICAgICAgICAgICB0b2tlbiBtYXkgYmUgZXhwb3NlZCB0byB0aGUgcmVzb3VyY2Ug b3duZXIgb3Igb3RoZXIgYXBwbGljYXRpb25zIHdpdGggYWNjZXNzIHRvIHRoZQogICAgICAgICAg ICByZXNvdXJjZSBvd25lcidzIHVzZXItYWdlbnQuCiAgICAgICAgICA8L3Q+CiAgICAgICAgICA8 dD4KICAgICAgICAgICAgSW1wbGljaXQgZ3JhbnRzIGltcHJvdmUgdGhlIHJlc3BvbnNpdmVuZXNz IGFuZCBlZmZpY2llbmN5IG9mIHNvbWUgY2xpZW50cyAoc3VjaCBhcyBhCiAgICAgICAgICAgIGNs aWVudCBpbXBsZW1lbnRlZCBhcyBhbiBpbi1icm93c2VyIGFwcGxpY2F0aW9uKSBzaW5jZSBpdCBy ZWR1Y2VzIHRoZSBudW1iZXIgb2Ygcm91bmQKICAgICAgICAgICAgdHJpcHMgcmVxdWlyZWQgdG8g b2J0YWluIGFuIGFjY2VzcyB0b2tlbi4gSG93ZXZlciwgdGhpcyBjb252ZW5pZW5jZSBzaG91bGQg YmUgd2VpZ2hlZAogICAgICAgICAgICBhZ2FpbnN0IHRoZSBzZWN1cml0eSBpbXBsaWNhdGlvbnMg b2YgdXNpbmcgaW1wbGljaXQgZ3JhbnRzLCBlc3BlY2lhbGx5IHdoZW4gdGhlCiAgICAgICAgICAg IGF1dGhvcml6YXRpb24gY29kZSBncmFudCB0eXBlIGlzIGF2YWlsYWJsZS4KICAgICAgICAgIDwv dD4KICAgICAgICA8L3NlY3Rpb24+CgogICAgICAgIDxzZWN0aW9uIHRpdGxlPSJSZXNvdXJjZSBP d25lciBQYXNzd29yZCBDcmVkZW50aWFscyI+CiAgICAgICAgICA8dD4KICAgICAgICAgICAgVGhl IHJlc291cmNlIG93bmVyIHBhc3N3b3JkIGNyZWRlbnRpYWxzIChpLmUuIHVzZXJuYW1lIGFuZCBw YXNzd29yZCkgY2FuIGJlIHVzZWQKICAgICAgICAgICAgZGlyZWN0bHkgYXMgYW4gYXV0aG9yaXph dGlvbiBncmFudCB0byBvYnRhaW4gYW4gYWNjZXNzIHRva2VuLiBUaGUgY3JlZGVudGlhbHMgc2hv dWxkCiAgICAgICAgICAgIG9ubHkgYmUgdXNlZCB3aGVuIHRoZXJlIGlzIGEgaGlnaCBkZWdyZWUg b2YgdHJ1c3QgYmV0d2VlbiB0aGUgcmVzb3VyY2Ugb3duZXIgYW5kIHRoZQogICAgICAgICAgICBj bGllbnQgKGUuZy4gdGhlIGNsaWVudCBpcyBwYXJ0IG9mIHRoZSBkZXZpY2Ugb3BlcmF0aW5nIHN5 c3RlbSBvciBhIGhpZ2hseSBwcml2aWxlZ2VkCiAgICAgICAgICAgIGFwcGxpY2F0aW9uKSwgYW5k IHdoZW4gb3RoZXIgYXV0aG9yaXphdGlvbiBncmFudCB0eXBlcyBhcmUgbm90IGF2YWlsYWJsZSAo c3VjaCBhcyBhbgogICAgICAgICAgICBhdXRob3JpemF0aW9uIGNvZGUpLgogICAgICAgICAgPC90 PgogICAgICAgICAgPHQ+CiAgICAgICAgICAgIEV2ZW4gdGhvdWdoIHRoaXMgZ3JhbnQgdHlwZSBy ZXF1aXJlcyBkaXJlY3QgY2xpZW50IGFjY2VzcyB0byB0aGUgcmVzb3VyY2Ugb3duZXIKICAgICAg ICAgICAgY3JlZGVudGlhbHMsIHRoZSByZXNvdXJjZSBvd25lciBjcmVkZW50aWFscyBhcmUgdXNl ZCBmb3IgYSBzaW5nbGUgcmVxdWVzdCBhbmQgYXJlCiAgICAgICAgICAgIGV4Y2hhbmdlZCBmb3Ig YW4gYWNjZXNzIHRva2VuLiBUaGlzIGdyYW50IHR5cGUgY2FuIGVsaW1pbmF0ZSB0aGUgbmVlZCBm b3IgdGhlIGNsaWVudAogICAgICAgICAgICB0byBzdG9yZSB0aGUgcmVzb3VyY2Ugb3duZXIgY3Jl ZGVudGlhbHMgZm9yIGZ1dHVyZSB1c2UsIGJ5IGV4Y2hhbmdpbmcgdGhlIGNyZWRlbnRpYWxzCiAg ICAgICAgICAgIHdpdGggYSBsb25nLWxpdmVkIGFjY2VzcyB0b2tlbiBvciByZWZyZXNoIHRva2Vu LgogICAgICAgICAgPC90PgogICAgICAgIDwvc2VjdGlvbj4KCiAgICAgICAgPHNlY3Rpb24gdGl0 bGU9J0NsaWVudCBDcmVkZW50aWFscyc+CiAgICAgICAgICA8dD4KICAgICAgICAgICAgVGhlIGNs aWVudCBjcmVkZW50aWFscyAob3Igb3RoZXIgZm9ybXMgb2YgY2xpZW50IGF1dGhlbnRpY2F0aW9u KSBjYW4gYmUgdXNlZCBhcyBhbgogICAgICAgICAgICBhdXRob3JpemF0aW9uIGdyYW50IHdoZW4g dGhlIGF1dGhvcml6YXRpb24gc2NvcGUgaXMgbGltaXRlZCB0byB0aGUgcHJvdGVjdGVkIHJlc291 cmNlcwogICAgICAgICAgICB1bmRlciB0aGUgY29udHJvbCBvZiB0aGUgY2xpZW50LCBvciB0byBw cm90ZWN0ZWQgcmVzb3VyY2VzIHByZXZpb3VzbHkgYXJyYW5nZWQgd2l0aCB0aGUKICAgICAgICAg ICAgYXV0aG9yaXphdGlvbiBzZXJ2ZXIuIENsaWVudCBjcmVkZW50aWFscyBhcmUgdXNlZCBhcyBh biBhdXRob3JpemF0aW9uIGdyYW50IHR5cGljYWxseQogICAgICAgICAgICB3aGVuIHRoZSBjbGll bnQgaXMgYWN0aW5nIG9uIGl0cyBvd24gYmVoYWxmICh0aGUgY2xpZW50IGlzIGFsc28gdGhlIHJl c291cmNlIG93bmVyKSwgb3IKICAgICAgICAgICAgaXMgcmVxdWVzdGluZyBhY2Nlc3MgdG8gcHJv dGVjdGVkIHJlc291cmNlcyBiYXNlZCBvbiBhbiBhdXRob3JpemF0aW9uIHByZXZpb3VzbHkKICAg ICAgICAgICAgYXJyYW5nZWQgd2l0aCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIuCiAgICAgICAg ICA8L3Q+CiAgICAgICAgPC9zZWN0aW9uPgoKICAgICAgPC9zZWN0aW9uPgoKICAgICAgPHNlY3Rp b24gdGl0bGU9J0FjY2VzcyBUb2tlbic+CiAgICAgICAgPHQ+CiAgICAgICAgICBBY2Nlc3MgdG9r ZW5zIGFyZSBjcmVkZW50aWFscyB1c2VkIHRvIGFjY2VzcyBwcm90ZWN0ZWQgcmVzb3VyY2VzLiBB biBhY2Nlc3MgdG9rZW4gaXMgYQogICAgICAgICAgc3RyaW5nIHJlcHJlc2VudGluZyBhbiBhdXRo b3JpemF0aW9uIGlzc3VlZCB0byB0aGUgY2xpZW50LiBUaGUgc3RyaW5nIGlzIHVzdWFsbHkgb3Bh cXVlCiAgICAgICAgICB0byB0aGUgY2xpZW50LiBUb2tlbnMgcmVwcmVzZW50IHNwZWNpZmljIHNj b3BlcyBhbmQgZHVyYXRpb25zIG9mIGFjY2VzcywgZ3JhbnRlZCBieSB0aGUKICAgICAgICAgIHJl c291cmNlIG93bmVyLCBhbmQgZW5mb3JjZWQgYnkgdGhlIHJlc291cmNlIHNlcnZlciBhbmQgYXV0 aG9yaXphdGlvbiBzZXJ2ZXIuCiAgICAgICAgPC90PgogICAgICAgIDx0PgogICAgICAgICAgVGhl IHRva2VuIG1heSBkZW5vdGUgYW4gaWRlbnRpZmllciB1c2VkIHRvIHJldHJpZXZlIHRoZSBhdXRo b3JpemF0aW9uIGluZm9ybWF0aW9uLCBvcgogICAgICAgICAgc2VsZi1jb250YWluIHRoZSBhdXRo b3JpemF0aW9uIGluZm9ybWF0aW9uIGluIGEgdmVyaWZpYWJsZSBtYW5uZXIgKGkuZS4gYSB0b2tl biBzdHJpbmcKICAgICAgICAgIGNvbnNpc3Rpbmcgb2Ygc29tZSBkYXRhIGFuZCBhIHNpZ25hdHVy ZSkuIEFkZGl0aW9uYWwgYXV0aGVudGljYXRpb24gY3JlZGVudGlhbHMsIHdoaWNoCiAgICAgICAg ICBhcmUgYmV5b25kIHRoZSBzY29wZSBvZiB0aGlzIHNwZWNpZmljYXRpb24sIG1heSBiZSByZXF1 aXJlZCBpbiBvcmRlciBmb3IgdGhlIGNsaWVudCB0bwogICAgICAgICAgdXNlIGEgdG9rZW4uCiAg ICAgICAgPC90PgogICAgICAgIDx0PgogICAgICAgICAgVGhlIGFjY2VzcyB0b2tlbiBwcm92aWRl cyBhbiBhYnN0cmFjdGlvbiBsYXllciwgcmVwbGFjaW5nIGRpZmZlcmVudCBhdXRob3JpemF0aW9u CiAgICAgICAgICBjb25zdHJ1Y3RzIChlLmcuIHVzZXJuYW1lIGFuZCBwYXNzd29yZCkgd2l0aCBh IHNpbmdsZSB0b2tlbiB1bmRlcnN0b29kIGJ5IHRoZSByZXNvdXJjZQogICAgICAgICAgc2VydmVy LiBUaGlzIGFic3RyYWN0aW9uIGVuYWJsZXMgaXNzdWluZyBhY2Nlc3MgdG9rZW5zIG1vcmUgcmVz dHJpY3RpdmUgdGhhbiB0aGUKICAgICAgICAgIGF1dGhvcml6YXRpb24gZ3JhbnQgdXNlZCB0byBv YnRhaW4gdGhlbSwgYXMgd2VsbCBhcyByZW1vdmluZyB0aGUgcmVzb3VyY2Ugc2VydmVyJ3MgbmVl ZCB0bwogICAgICAgICAgdW5kZXJzdGFuZCBhIHdpZGUgcmFuZ2Ugb2YgYXV0aGVudGljYXRpb24g bWV0aG9kcy4KICAgICAgICA8L3Q+CiAgICAgICAgPHQ+CiAgICAgICAgICBBY2Nlc3MgdG9rZW5z IGNhbiBoYXZlIGRpZmZlcmVudCBmb3JtYXRzLCBzdHJ1Y3R1cmVzLCBhbmQgbWV0aG9kcyBvZiB1 dGlsaXphdGlvbiAoZS5nLgogICAgICAgICAgY3J5cHRvZ3JhcGhpYyBwcm9wZXJ0aWVzKSBiYXNl ZCBvbiB0aGUgcmVzb3VyY2Ugc2VydmVyIHNlY3VyaXR5IHJlcXVpcmVtZW50cy4gQWNjZXNzIHRv a2VuCiAgICAgICAgICBhdHRyaWJ1dGVzIGFuZCB0aGUgbWV0aG9kcyB1c2VkIHRvIGFjY2VzcyBw cm90ZWN0ZWQgcmVzb3VyY2VzIGFyZSBiZXlvbmQgdGhlIHNjb3BlIG9mIHRoaXMKICAgICAgICAg IHNwZWNpZmljYXRpb24gYW5kIGFyZSBkZWZpbmVkIGJ5IGNvbXBhbmlvbiBzcGVjaWZpY2F0aW9u cy4KICAgICAgICA8L3Q+CiAgICAgIDwvc2VjdGlvbj4KCiAgICAgIDxzZWN0aW9uIHRpdGxlPSdS ZWZyZXNoIFRva2VuJz4KICAgICAgICA8dD4KICAgICAgICAgIFJlZnJlc2ggdG9rZW5zIGFyZSBj cmVkZW50aWFscyB1c2VkIHRvIG9idGFpbiBhY2Nlc3MgdG9rZW5zLiBSZWZyZXNoIHRva2VucyBh cmUgaXNzdWVkIHRvCiAgICAgICAgICB0aGUgY2xpZW50IGJ5IHRoZSBhdXRob3JpemF0aW9uIHNl cnZlciBhbmQgYXJlIHVzZWQgdG8gb2J0YWluIGEgbmV3IGFjY2VzcyB0b2tlbiB3aGVuIHRoZQog ICAgICAgICAgY3VycmVudCBhY2Nlc3MgdG9rZW4gYmVjb21lcyBpbnZhbGlkIG9yIGV4cGlyZXMs IG9yIHRvIG9idGFpbiBhZGRpdGlvbmFsIGFjY2VzcyB0b2tlbnMKICAgICAgICAgIHdpdGggaWRl bnRpY2FsIG9yIG5hcnJvd2VyIHNjb3BlIChhY2Nlc3MgdG9rZW5zIG1heSBoYXZlIGEgc2hvcnRl ciBsaWZldGltZSBhbmQgZmV3ZXIKICAgICAgICAgIHBlcm1pc3Npb25zIHRoYW4gYXV0aG9yaXpl ZCBieSB0aGUgcmVzb3VyY2Ugb3duZXIpLiBJc3N1aW5nIGEgcmVmcmVzaCB0b2tlbiBpcyBvcHRp b25hbAogICAgICAgICAgYXQgdGhlIGRpc2NyZXRpb24gb2YgdGhlIGF1dGhvcml6YXRpb24gc2Vy dmVyLiBJZiB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgaXNzdWVzIGEKICAgICAgICAgIHJlZnJl c2ggdG9rZW4sIGl0IGlzIGluY2x1ZGVkIHdoZW4gaXNzdWluZyBhbiBhY2Nlc3MgdG9rZW4gKGku ZS4gc3RlcCAoRCkgaW4KICAgICAgICAgIDx4cmVmIHRhcmdldD0nRmlndXJlLTEnIC8+KS4KICAg ICAgICA8L3Q+CiAgICAgICAgPHQ+CiAgICAgICAgICBBIHJlZnJlc2ggdG9rZW4gaXMgYSBzdHJp bmcgcmVwcmVzZW50aW5nIHRoZSBhdXRob3JpemF0aW9uIGdyYW50ZWQgdG8gdGhlIGNsaWVudCBi eSB0aGUKICAgICAgICAgIHJlc291cmNlIG93bmVyLiBUaGUgc3RyaW5nIGlzIHVzdWFsbHkgb3Bh cXVlIHRvIHRoZSBjbGllbnQuIFRoZSB0b2tlbiBkZW5vdGVzIGFuCiAgICAgICAgICBpZGVudGlm aWVyIHVzZWQgdG8gcmV0cmlldmUgdGhlIGF1dGhvcml6YXRpb24gaW5mb3JtYXRpb24uIFVubGlr ZSBhY2Nlc3MgdG9rZW5zLCByZWZyZXNoCiAgICAgICAgICB0b2tlbnMgYXJlIGludGVuZGVkIGZv ciB1c2Ugb25seSB3aXRoIGF1dGhvcml6YXRpb24gc2VydmVycyBhbmQgYXJlIG5ldmVyIHNlbnQg dG8KICAgICAgICAgIHJlc291cmNlIHNlcnZlcnMuCiAgICAgICAgPC90PgogICAgICAgIDxmaWd1 cmUgdGl0bGU9J1JlZnJlc2hpbmcgYW4gRXhwaXJlZCBBY2Nlc3MgVG9rZW4nIGFuY2hvcj0nRmln dXJlLTInPgogICAgICAgICAgPGFydHdvcms+CiAgICAgICAgICAgIDwhW0NEQVRBWwogICstLS0t LS0tLSsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0t LS0tLS0tLSsKICB8ICAgICAgICB8LS0oQSktLS0tLS0tIEF1dGhvcml6YXRpb24gR3JhbnQgLS0t LS0tLS0tPnwgICAgICAgICAgICAgICB8CiAgfCAgICAgICAgfCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgfAogIHwgICAgICAgIHw8LShC KS0tLS0tLS0tLS0tIEFjY2VzcyBUb2tlbiAtLS0tLS0tLS0tLS0tfCAgICAgICAgICAgICAgIHwK ICB8ICAgICAgICB8ICAgICAgICAgICAgICAgJiBSZWZyZXNoIFRva2VuICAgICAgICAgICAgIHwg ICAgICAgICAgICAgICB8CiAgfCAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgfAogIHwgICAgICAgIHwgICAgICAgICAgICAg ICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0rICAgfCAgICAgICAgICAgICAgIHwKICB8ICAgICAg ICB8LS0oQyktLS0tIEFjY2VzcyBUb2tlbiAtLS0tPnwgICAgICAgICAgfCAgIHwgICAgICAgICAg ICAgICB8CiAgfCAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAg IHwgICB8ICAgICAgICAgICAgICAgfAogIHwgICAgICAgIHw8LShEKS0gUHJvdGVjdGVkIFJlc291 cmNlIC0tfCBSZXNvdXJjZSB8ICAgfCBBdXRob3JpemF0aW9uIHwKICB8IENsaWVudCB8ICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHwgIFNlcnZlciAgfCAgIHwgICAgIFNlcnZlciAgICB8CiAg fCAgICAgICAgfC0tKEUpLS0tLSBBY2Nlc3MgVG9rZW4gLS0tLT58ICAgICAgICAgIHwgICB8ICAg ICAgICAgICAgICAgfAogIHwgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAg ICAgICAgICB8ICAgfCAgICAgICAgICAgICAgIHwKICB8ICAgICAgICB8PC0oRiktIEludmFsaWQg VG9rZW4gRXJyb3IgLXwgICAgICAgICAgfCAgIHwgICAgICAgICAgICAgICB8CiAgfCAgICAgICAg fCAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLSsgICB8ICAgICAgICAgICAg ICAgfAogIHwgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgfCAgICAgICAgICAgICAgIHwKICB8ICAgICAgICB8LS0oRyktLS0tLS0tLS0tLSBSZWZyZXNo IFRva2VuIC0tLS0tLS0tLS0tPnwgICAgICAgICAgICAgICB8CiAgfCAgICAgICAgfCAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgfAogIHwg ICAgICAgIHw8LShIKS0tLS0tLS0tLS0tIEFjY2VzcyBUb2tlbiAtLS0tLS0tLS0tLS0tfCAgICAg ICAgICAgICAgIHwKICArLS0tLS0tLS0rICAgICAgICAgICAmIE9wdGlvbmFsIFJlZnJlc2ggVG9r ZW4gICAgICAgICstLS0tLS0tLS0tLS0tLS0rCl1dPgogICAgICAgICAgPC9hcnR3b3JrPgogICAg ICAgIDwvZmlndXJlPgogICAgICAgIDx0PgogICAgICAgICAgVGhlIGZsb3cgaWxsdXN0cmF0ZWQg aW4gPHhyZWYgdGFyZ2V0PSdGaWd1cmUtMicgLz4gaW5jbHVkZXMgdGhlIGZvbGxvd2luZyBzdGVw czoKICAgICAgICA8L3Q+CiAgICAgICAgPHQ+CiAgICAgICAgICA8bGlzdCBzdHlsZT0nZm9ybWF0 ICglQyknPgogICAgICAgICAgICA8dD4KICAgICAgICAgICAgICBUaGUgY2xpZW50IHJlcXVlc3Rz IGFuIGFjY2VzcyB0b2tlbiBieSBhdXRoZW50aWNhdGluZyB3aXRoIHRoZSBhdXRob3JpemF0aW9u IHNlcnZlciwKICAgICAgICAgICAgICBhbmQgcHJlc2VudGluZyBhbiBhdXRob3JpemF0aW9uIGdy YW50LgogICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgIDx0PgogICAgICAgICAgICAgIFRoZSBh dXRob3JpemF0aW9uIHNlcnZlciBhdXRoZW50aWNhdGVzIHRoZSBjbGllbnQgYW5kIHZhbGlkYXRl cyB0aGUgYXV0aG9yaXphdGlvbgogICAgICAgICAgICAgIGdyYW50LCBhbmQgaWYgdmFsaWQgaXNz dWVzIGFuIGFjY2VzcyB0b2tlbiBhbmQgYSByZWZyZXNoIHRva2VuLgogICAgICAgICAgICA8L3Q+ CiAgICAgICAgICAgIDx0PgogICAgICAgICAgICAgIFRoZSBjbGllbnQgbWFrZXMgYSBwcm90ZWN0 ZWQgcmVzb3VyY2UgcmVxdWVzdCB0byB0aGUgcmVzb3VyY2Ugc2VydmVyIGJ5IHByZXNlbnRpbmcK ICAgICAgICAgICAgICB0aGUgYWNjZXNzIHRva2VuLgogICAgICAgICAgICA8L3Q+CiAgICAgICAg ICAgIDx0PgogICAgICAgICAgICAgIFRoZSByZXNvdXJjZSBzZXJ2ZXIgdmFsaWRhdGVzIHRoZSBh Y2Nlc3MgdG9rZW4sIGFuZCBpZiB2YWxpZCwgc2VydmVzIHRoZSByZXF1ZXN0LgogICAgICAgICAg ICA8L3Q+CiAgICAgICAgICAgIDx0PgogICAgICAgICAgICAgIFN0ZXBzIChDKSBhbmQgKEQpIHJl cGVhdCB1bnRpbCB0aGUgYWNjZXNzIHRva2VuIGV4cGlyZXMuIElmIHRoZSBjbGllbnQga25vd3Mg dGhlCiAgICAgICAgICAgICAgYWNjZXNzIHRva2VuIGV4cGlyZWQsIGl0IHNraXBzIHRvIHN0ZXAg KEcpLCBvdGhlcndpc2UgaXQgbWFrZXMgYW5vdGhlciBwcm90ZWN0ZWQKICAgICAgICAgICAgICBy ZXNvdXJjZSByZXF1ZXN0LgogICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgIDx0PgogICAgICAg ICAgICAgIFNpbmNlIHRoZSBhY2Nlc3MgdG9rZW4gaXMgaW52YWxpZCwgdGhlIHJlc291cmNlIHNl cnZlciByZXR1cm5zIGFuIGludmFsaWQgdG9rZW4KICAgICAgICAgICAgICBlcnJvci4KICAgICAg ICAgICAgPC90PgogICAgICAgICAgICA8dD4KICAgICAgICAgICAgICBUaGUgY2xpZW50IHJlcXVl c3RzIGEgbmV3IGFjY2VzcyB0b2tlbiBieSBhdXRoZW50aWNhdGluZyB3aXRoIHRoZSBhdXRob3Jp emF0aW9uCiAgICAgICAgICAgICAgc2VydmVyIGFuZCBwcmVzZW50aW5nIHRoZSByZWZyZXNoIHRv a2VuLiBUaGUgY2xpZW50IGF1dGhlbnRpY2F0aW9uIHJlcXVpcmVtZW50cyBhcmUKICAgICAgICAg ICAgICBiYXNlZCBvbiB0aGUgY2xpZW50IHR5cGUgYW5kIG9uIHRoZSBhdXRob3JpemF0aW9uIHNl cnZlciBwb2xpY2llcy4KICAgICAgICAgICAgPC90PgogICAgICAgICAgICA8dD4KICAgICAgICAg ICAgICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYXV0aGVudGljYXRlcyB0aGUgY2xpZW50IGFu ZCB2YWxpZGF0ZXMgdGhlIHJlZnJlc2ggdG9rZW4sCiAgICAgICAgICAgICAgYW5kIGlmIHZhbGlk IGlzc3VlcyBhIG5ldyBhY2Nlc3MgdG9rZW4gKGFuZCBvcHRpb25hbGx5LCBhIG5ldyByZWZyZXNo IHRva2VuKS4KICAgICAgICAgICAgPC90PgogICAgICAgICAgPC9saXN0PgogICAgICAgIDwvdD4K ICAgICAgICA8dD4KICAgICAgICAgIFN0ZXBzIEMsIEQsIEUsIGFuZCBGIGFyZSBvdXRzaWRlIHRo ZSBzY29wZSBvZiB0aGlzIHNwZWNpZmljYXRpb24gYXMgZGVzY3JpYmVkIGluCiAgICAgICAgICA8 eHJlZiB0YXJnZXQ9J2FjY2Vzcy1yZXNvdXJjZScgLz4uCiAgICAgICAgPC90PgogICAgICA8L3Nl Y3Rpb24+CgogICAgICA8c2VjdGlvbiB0aXRsZT0nVExTIFZlcnNpb24nIGFuY2hvcj0ndGxzJz4K ICAgICAgICA8dD4KICAgICAgICAgIFdoZW5ldmVyIFRMUyBpcyB1c2VkIGJ5IHRoaXMgc3BlY2lm aWNhdGlvbiwgdGhlIGFwcHJvcHJpYXRlIHZlcnNpb24gKG9yIHZlcnNpb25zKSBvZgogICAgICAg ICAgVExTIHdpbGwgdmFyeSBvdmVyIHRpbWUsIGJhc2VkIG9uIHRoZSB3aWRlc3ByZWFkIGRlcGxv eW1lbnQgYW5kIGtub3duIHNlY3VyaXR5CiAgICAgICAgICB2dWxuZXJhYmlsaXRpZXMuIEF0IHRo ZSB0aW1lIG9mIHRoaXMgd3JpdGluZywgVExTIHZlcnNpb24gMS4yIDx4cmVmIHRhcmdldD0nUkZD NTI0NicgLz4KICAgICAgICAgIGlzIHRoZSBtb3N0IHJlY2VudCB2ZXJzaW9uLCBidXQgaGFzIGEg dmVyeSBsaW1pdGVkIGRlcGxveW1lbnQgYmFzZSBhbmQgbWlnaHQgbm90IGJlCiAgICAgICAgICBy ZWFkaWx5IGF2YWlsYWJsZSBmb3IgaW1wbGVtZW50YXRpb24uIFRMUyB2ZXJzaW9uIDEuMCA8eHJl ZiB0YXJnZXQ9J1JGQzIyNDYnIC8+IGlzIHRoZQogICAgICAgICAgbW9zdCB3aWRlbHkgZGVwbG95 ZWQgdmVyc2lvbiwgYW5kIHdpbGwgcHJvdmlkZSB0aGUgYnJvYWRlc3QgaW50ZXJvcGVyYWJpbGl0 eS4KICAgICAgICA8L3Q+CiAgICAgICAgPHQ+CiAgICAgICAgICBJbXBsZW1lbnRhdGlvbnMgTUFZ IGFsc28gc3VwcG9ydCBhZGRpdGlvbmFsIHRyYW5zcG9ydC1sYXllciBzZWN1cml0eSBtZWNoYW5p c21zCiAgICAgICAgICB0aGF0IG1lZXQgdGhlaXIgc2VjdXJpdHkgcmVxdWlyZW1lbnRzLgogICAg ICAgIDwvdD4KICAgICAgPC9zZWN0aW9uPgoKICAgICAgPHNlY3Rpb24gdGl0bGU9J0hUVFAgUmVk aXJlY3Rpb25zJz4KICAgICAgICA8dD4KICAgICAgICAgIFRoaXMgc3BlY2lmaWNhdGlvbiBtYWtl cyBleHRlbnNpdmUgdXNlIG9mIEhUVFAgcmVkaXJlY3Rpb25zLCBpbiB3aGljaCB0aGUgY2xpZW50 IG9yIHRoZQogICAgICAgICAgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgZGlyZWN0IHRoZSByZXNvdXJj ZSBvd25lcidzIHVzZXItYWdlbnQgdG8gYW5vdGhlciBkZXN0aW5hdGlvbi4gV2hpbGUKICAgICAg ICAgIHRoZSBleGFtcGxlcyBpbiB0aGlzIHNwZWNpZmljYXRpb24gc2hvdyB0aGUgdXNlIG9mIHRo ZSBIVFRQIDMwMiBzdGF0dXMgY29kZSwgYW55IG90aGVyCiAgICAgICAgICBtZXRob2QgYXZhaWxh YmxlIHZpYSB0aGUgdXNlci1hZ2VudCB0byBhY2NvbXBsaXNoIHRoaXMgcmVkaXJlY3Rpb24gaXMg YWxsb3dlZCBhbmQgaXMKICAgICAgICAgIGNvbnNpZGVyZWQgdG8gYmUgYW4gaW1wbGVtZW50YXRp b24gZGV0YWlsLgogICAgICAgIDwvdD4KICAgICAgPC9zZWN0aW9uPgoKICAgICAgPHNlY3Rpb24g dGl0bGU9J0ludGVyb3BlcmFiaWxpdHknPgogICAgICAgIDx0PgogICAgICAgICAgT0F1dGggMi4w IHByb3ZpZGVzIGEgcmljaCBhdXRob3JpemF0aW9uIGZyYW1ld29yayB3aXRoIHdlbGwtZGVmaW5l ZCBzZWN1cml0eSBwcm9wZXJ0aWVzLgogICAgICAgICAgSG93ZXZlciwgYXMgYSByaWNoIGFuZCBo aWdobHkgZXh0ZW5zaWJsZSBmcmFtZXdvcmsgd2l0aCBtYW55IG9wdGlvbmFsIGNvbXBvbmVudHMs IG9uIGl0cwogICAgICAgICAgb3duLCB0aGlzIHNwZWNpZmljYXRpb24gaXMgbGlrZWx5IHRvIHBy b2R1Y2UgYSB3aWRlIHJhbmdlIG9mIG5vbi1pbnRlcm9wZXJhYmxlCiAgICAgICAgICBpbXBsZW1l bnRhdGlvbnMuCiAgICAgICAgPC90PgogICAgICAgIDx0PgogICAgICAgICAgSW4gYWRkaXRpb24s IHRoaXMgc3BlY2lmaWNhdGlvbiBsZWF2ZXMgYSBmZXcgcmVxdWlyZWQgY29tcG9uZW50cyBwYXJ0 aWFsbHkgb3IgZnVsbHkKICAgICAgICAgIHVuZGVmaW5lZCAoZS5nLiBjbGllbnQgcmVnaXN0cmF0 aW9uLCBhdXRob3JpemF0aW9uIHNlcnZlciBjYXBhYmlsaXRpZXMsIGVuZHBvaW50CiAgICAgICAg ICBkaXNjb3ZlcnkpLiBXaXRob3V0IHRoZXNlIGNvbXBvbmVudHMsIGNsaWVudHMgbXVzdCBiZSBt YW51YWxseSBhbmQgc3BlY2lmaWNhbGx5CiAgICAgICAgICBjb25maWd1cmVkIGFnYWluc3QgYSBz cGVjaWZpYyBhdXRob3JpemF0aW9uIHNlcnZlciBhbmQgcmVzb3VyY2Ugc2VydmVyIGluIG9yZGVy IHRvCiAgICAgICAgICBpbnRlcm9wZXJhdGUuCiAgICAgICAgPC90PgogICAgICAgIDx0PgogICAg ICAgICAgVGhpcyBmcmFtZXdvcmsgd2FzIGRlc2lnbmVkIHdpdGggdGhlIGNsZWFyIGV4cGVjdGF0 aW9uIHRoYXQgZnV0dXJlIHdvcmsgd2lsbCBkZWZpbmUKICAgICAgICAgIHByZXNjcmlwdGl2ZSBw cm9maWxlcyBhbmQgZXh0ZW5zaW9ucyBuZWNlc3NhcnkgdG8gYWNoaWV2ZSBmdWxsIHdlYi1zY2Fs ZQogICAgICAgICAgaW50ZXJvcGVyYWJpbGl0eS4KICAgICAgICA8L3Q+CiAgICAgIDwvc2VjdGlv bj4KCiAgICAgIDxzZWN0aW9uIHRpdGxlPSdOb3RhdGlvbmFsIENvbnZlbnRpb25zJz4KICAgICAg ICA8dD4KICAgICAgICAgIFRoZSBrZXkgd29yZHMgIk1VU1QiLCAiTVVTVCBOT1QiLCAiUkVRVUlS RUQiLCAiU0hBTEwiLCAiU0hBTEwgTk9UIiwgIlNIT1VMRCIsICJTSE9VTEQKICAgICAgICAgIE5P VCIsICJSRUNPTU1FTkRFRCIsICJNQVkiLCBhbmQgIk9QVElPTkFMIiBpbiB0aGlzIHNwZWNpZmlj YXRpb24gYXJlIHRvIGJlIGludGVycHJldGVkIGFzCiAgICAgICAgICBkZXNjcmliZWQgaW4gPHhy ZWYgdGFyZ2V0PSdSRkMyMTE5JyAvPi4KICAgICAgICA8L3Q+CiAgICAgICAgPHQ+CiAgICAgICAg ICBUaGlzIHNwZWNpZmljYXRpb24gdXNlcyB0aGUgQXVnbWVudGVkIEJhY2t1cy1OYXVyIEZvcm0g KEFCTkYpIG5vdGF0aW9uIG9mCiAgICAgICAgICA8eHJlZiB0YXJnZXQ9J1JGQzUyMzQnIC8+LgoJ ICBBZGRpdGlvbmFsbHksIHRoZSBydWxlIFVSSS1SZWZlcmVuY2UgaXMgaW5jbHVkZWQgZnJvbQoJ ICBVbmlmb3JtIFJlc291cmNlIElkZW50aWZpZXIgKFVSSSkgPHhyZWYgdGFyZ2V0PSdSRkMzOTg2 JyAvPi4KICAgICAgICA8L3Q+CiAgICAgICAgPHQ+CiAgICAgICAgICBDZXJ0YWluIHNlY3VyaXR5 LXJlbGF0ZWQgdGVybXMgYXJlIHRvIGJlIHVuZGVyc3Rvb2QgaW4gdGhlIHNlbnNlIGRlZmluZWQg aW4KICAgICAgICAgIDx4cmVmIHRhcmdldD0nUkZDNDk0OScgLz4uIFRoZXNlIHRlcm1zIGluY2x1 ZGUsIGJ1dCBhcmUgbm90IGxpbWl0ZWQgdG8sICJhdHRhY2siLAogICAgICAgICAgImF1dGhlbnRp Y2F0aW9uIiwgImF1dGhvcml6YXRpb24iLCAiY2VydGlmaWNhdGUiLCAiY29uZmlkZW50aWFsaXR5 IiwgImNyZWRlbnRpYWwiLAogICAgICAgICAgImVuY3J5cHRpb24iLCAiaWRlbnRpdHkiLCAic2ln biIsICJzaWduYXR1cmUiLCAidHJ1c3QiLCAidmFsaWRhdGUiLCBhbmQgInZlcmlmeSIuCiAgICAg ICAgPC90PgogICAgICAgIDx0PgogICAgICAgICAgVW5sZXNzIG90aGVyd2lzZSBub3RlZCwgYWxs IHRoZSBwcm90b2NvbCBwYXJhbWV0ZXIgbmFtZXMgYW5kIHZhbHVlcyBhcmUgY2FzZSBzZW5zaXRp dmUuCiAgICAgICAgPC90PgogICAgICA8L3NlY3Rpb24+CgogICAgPC9zZWN0aW9uPgoKICAgIDxz ZWN0aW9uIHRpdGxlPSdDbGllbnQgUmVnaXN0cmF0aW9uJz4KICAgICAgPHQ+CiAgICAgICAgQmVm b3JlIGluaXRpYXRpbmcgdGhlIHByb3RvY29sLCB0aGUgY2xpZW50IHJlZ2lzdGVycyB3aXRoIHRo ZSBhdXRob3JpemF0aW9uIHNlcnZlci4gVGhlCiAgICAgICAgbWVhbnMgdGhyb3VnaCB3aGljaCB0 aGUgY2xpZW50IHJlZ2lzdGVycyB3aXRoIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBhcmUgYmV5 b25kIHRoZQogICAgICAgIHNjb3BlIG9mIHRoaXMgc3BlY2lmaWNhdGlvbiwgYnV0IHR5cGljYWxs eSBpbnZvbHZlIGVuZC11c2VyIGludGVyYWN0aW9uIHdpdGggYW4gSFRNTAogICAgICAgIHJlZ2lz dHJhdGlvbiBmb3JtLgogICAgICA8L3Q+CiAgICAgIDx0PgogICAgICAgIENsaWVudCByZWdpc3Ry YXRpb24gZG9lcyBub3QgcmVxdWlyZSBhIGRpcmVjdCBpbnRlcmFjdGlvbiBiZXR3ZWVuIHRoZSBj bGllbnQgYW5kIHRoZQogICAgICAgIGF1dGhvcml6YXRpb24gc2VydmVyLiBXaGVuIHN1cHBvcnRl ZCBieSB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIsIHJlZ2lzdHJhdGlvbiBjYW4gcmVseQogICAg ICAgIG9uIG90aGVyIG1lYW5zIGZvciBlc3RhYmxpc2hpbmcgdHJ1c3QgYW5kIG9idGFpbmluZyB0 aGUgcmVxdWlyZWQgY2xpZW50IHByb3BlcnRpZXMgKGUuZy4KICAgICAgICByZWRpcmVjdGlvbiBV UkksIGNsaWVudCB0eXBlKS4gRm9yIGV4YW1wbGUsIHJlZ2lzdHJhdGlvbiBjYW4gYmUgYWNjb21w bGlzaGVkIHVzaW5nIGEKICAgICAgICBzZWxmLWlzc3VlZCBvciB0aGlyZC1wYXJ0eS1pc3N1ZWQg YXNzZXJ0aW9uLCBvciBieSB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgcGVyZm9ybWluZwogICAg ICAgIGNsaWVudCBkaXNjb3ZlcnkgdXNpbmcgYSB0cnVzdGVkIGNoYW5uZWwuCiAgICAgIDwvdD4K ICAgICAgPHQ+CiAgICAgICAgV2hlbiByZWdpc3RlcmluZyBhIGNsaWVudCwgdGhlIGNsaWVudCBk ZXZlbG9wZXIgU0hBTEw6CiAgICAgIDwvdD4KICAgICAgPHQ+CiAgICAgICAgPGxpc3Qgc3R5bGU9 J3N5bWJvbHMnPgogICAgICAgICAgPHQ+CiAgICAgICAgICAgIHNwZWNpZnkgdGhlIGNsaWVudCB0 eXBlIGFzIGRlc2NyaWJlZCBpbiA8eHJlZiB0YXJnZXQ9J2NsaWVudC10eXBlcycgLz4sCiAgICAg ICAgICA8L3Q+CiAgICAgICAgICA8dD4KICAgICAgICAgICAgcHJvdmlkZSBpdHMgY2xpZW50IHJl ZGlyZWN0aW9uIFVSSXMgYXMgZGVzY3JpYmVkIGluCiAgICAgICAgICAgIDx4cmVmIHRhcmdldD0n cmVkaXJlY3QtdXJpJyAvPiwgYW5kCiAgICAgICAgICA8L3Q+CiAgICAgICAgICA8dD4KICAgICAg ICAgICAgaW5jbHVkZSBhbnkgb3RoZXIgaW5mb3JtYXRpb24gcmVxdWlyZWQgYnkgdGhlIGF1dGhv cml6YXRpb24gc2VydmVyIChlLmcuIGFwcGxpY2F0aW9uCiAgICAgICAgICAgIG5hbWUsIHdlYnNp dGUsIGRlc2NyaXB0aW9uLCBsb2dvIGltYWdlLCB0aGUgYWNjZXB0YW5jZSBvZiBsZWdhbCB0ZXJt cykuCiAgICAgICAgICA8L3Q+CiAgICAgICAgPC9saXN0PgogICAgICA8L3Q+CgogICAgICA8c2Vj dGlvbiB0aXRsZT0nQ2xpZW50IFR5cGVzJyBhbmNob3I9J2NsaWVudC10eXBlcyc+CiAgICAgICAg PHQ+CiAgICAgICAgICBPQXV0aCBkZWZpbmVzIHR3byBjbGllbnQgdHlwZXMsIGJhc2VkIG9uIHRo ZWlyIGFiaWxpdHkgdG8gYXV0aGVudGljYXRlIHNlY3VyZWx5IHdpdGggdGhlCiAgICAgICAgICBh dXRob3JpemF0aW9uIHNlcnZlciAoaS5lLiBhYmlsaXR5IHRvIG1haW50YWluIHRoZSBjb25maWRl bnRpYWxpdHkgb2YgdGhlaXIgY2xpZW50CiAgICAgICAgICBjcmVkZW50aWFscyk6CiAgICAgICAg PC90PgogICAgICAgIDx0PgogICAgICAgICAgPGxpc3Qgc3R5bGU9J2hhbmdpbmcnPgogICAgICAg ICAgICA8dCBoYW5nVGV4dD0nY29uZmlkZW50aWFsJz4KICAgICAgICAgICAgICA8dnNwYWNlIC8+ CiAgICAgICAgICAgICAgQ2xpZW50cyBjYXBhYmxlIG9mIG1haW50YWluaW5nIHRoZSBjb25maWRl bnRpYWxpdHkgb2YgdGhlaXIgY3JlZGVudGlhbHMgKGUuZy4KICAgICAgICAgICAgICBjbGllbnQg aW1wbGVtZW50ZWQgb24gYSBzZWN1cmUgc2VydmVyIHdpdGggcmVzdHJpY3RlZCBhY2Nlc3MgdG8g dGhlIGNsaWVudAogICAgICAgICAgICAgIGNyZWRlbnRpYWxzKSwgb3IgY2FwYWJsZSBvZiBzZWN1 cmUgY2xpZW50IGF1dGhlbnRpY2F0aW9uIHVzaW5nIG90aGVyIG1lYW5zLgogICAgICAgICAgICA8 L3Q+CiAgICAgICAgICAgIDx0IGhhbmdUZXh0PSdwdWJsaWMnPgogICAgICAgICAgICAgIDx2c3Bh Y2UgLz4KICAgICAgICAgICAgICBDbGllbnRzIGluY2FwYWJsZSBvZiBtYWludGFpbmluZyB0aGUg Y29uZmlkZW50aWFsaXR5IG9mIHRoZWlyIGNyZWRlbnRpYWxzIChlLmcuCiAgICAgICAgICAgICAg Y2xpZW50cyBleGVjdXRpbmcgb24gdGhlIGRldmljZSB1c2VkIGJ5IHRoZSByZXNvdXJjZSBvd25l ciBzdWNoIGFzIGFuIGluc3RhbGxlZAogICAgICAgICAgICAgIG5hdGl2ZSBhcHBsaWNhdGlvbiBv ciBhIHdlYiBicm93c2VyLWJhc2VkIGFwcGxpY2F0aW9uKSwgYW5kIGluY2FwYWJsZSBvZiBzZWN1 cmUKICAgICAgICAgICAgICBjbGllbnQgYXV0aGVudGljYXRpb24gdmlhIGFueSBvdGhlciBtZWFu cy4KICAgICAgICAgICAgPC90PgogICAgICAgICAgPC9saXN0PgogICAgICAgIDwvdD4KICAgICAg ICA8dD4KICAgICAgICAgIFRoZSBjbGllbnQgdHlwZSBkZXNpZ25hdGlvbiBpcyBiYXNlZCBvbiB0 aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIncyBkZWZpbml0aW9uIG9mIHNlY3VyZQogICAgICAgICAg YXV0aGVudGljYXRpb24gYW5kIGl0cyBhY2NlcHRhYmxlIGV4cG9zdXJlIGxldmVscyBvZiBjbGll bnQgY3JlZGVudGlhbHMuIFRoZQogICAgICAgICAgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgU0hPVUxE IE5PVCBtYWtlIGFzc3VtcHRpb25zIGFib3V0IHRoZSBjbGllbnQgdHlwZS4KICAgICAgICA8L3Q+ CiAgICAgICAgPHQ+CiAgICAgICAgICBBIGNsaWVudCBtYXkgYmUgaW1wbGVtZW50ZWQgYXMgYSBk aXN0cmlidXRlZCBzZXQgb2YgY29tcG9uZW50cywgZWFjaCB3aXRoIGEgZGlmZmVyZW50CiAgICAg ICAgICBjbGllbnQgdHlwZSBhbmQgc2VjdXJpdHkgY29udGV4dCAoZS5nLiBhIGRpc3RyaWJ1dGVk IGNsaWVudCB3aXRoIGJvdGggYSBjb25maWRlbnRpYWwKICAgICAgICAgIHNlcnZlci1iYXNlZCBj b21wb25lbnQgYW5kIGEgcHVibGljIGJyb3dzZXItYmFzZWQgY29tcG9uZW50KS4gSWYgdGhlIGF1 dGhvcml6YXRpb24gc2VydmVyCiAgICAgICAgICBkb2VzIG5vdCBwcm92aWRlIHN1cHBvcnQgZm9y IHN1Y2ggY2xpZW50cywgb3IgZG9lcyBub3QgcHJvdmlkZSBndWlkYW5jZSB3aXRoIHJlZ2FyZCB0 bwogICAgICAgICAgdGhlaXIgcmVnaXN0cmF0aW9uLCB0aGUgY2xpZW50IFNIT1VMRCByZWdpc3Rl ciBlYWNoIGNvbXBvbmVudCBhcyBhIHNlcGFyYXRlIGNsaWVudC4KICAgICAgICA8L3Q+CiAgICAg ICAgPHQ+CiAgICAgICAgICBUaGlzIHNwZWNpZmljYXRpb24gaGFzIGJlZW4gZGVzaWduZWQgYXJv dW5kIHRoZSBmb2xsb3dpbmcgY2xpZW50IHByb2ZpbGVzOgogICAgICAgIDwvdD4KICAgICAgICA8 dD4KICAgICAgICAgIDxsaXN0IHN0eWxlPSdoYW5naW5nJz4KICAgICAgICAgICAgPHQgaGFuZ1Rl eHQ9J3dlYiBhcHBsaWNhdGlvbic+CiAgICAgICAgICAgICAgPHZzcGFjZSAvPgogICAgICAgICAg ICAgIEEgd2ViIGFwcGxpY2F0aW9uIGlzIGEgY29uZmlkZW50aWFsIGNsaWVudCBydW5uaW5nIG9u IGEgd2ViIHNlcnZlci4gUmVzb3VyY2Ugb3duZXJzCiAgICAgICAgICAgICAgYWNjZXNzIHRoZSBj bGllbnQgdmlhIGFuIEhUTUwgdXNlciBpbnRlcmZhY2UgcmVuZGVyZWQgaW4gYSB1c2VyLWFnZW50 IG9uIHRoZSBkZXZpY2UKICAgICAgICAgICAgICB1c2VkIGJ5IHRoZSByZXNvdXJjZSBvd25lci4g VGhlIGNsaWVudCBjcmVkZW50aWFscyBhcyB3ZWxsIGFzIGFueSBhY2Nlc3MgdG9rZW4gaXNzdWVk CiAgICAgICAgICAgICAgdG8gdGhlIGNsaWVudCBhcmUgc3RvcmVkIG9uIHRoZSB3ZWIgc2VydmVy IGFuZCBhcmUgbm90IGV4cG9zZWQgdG8gb3IgYWNjZXNzaWJsZSBieQogICAgICAgICAgICAgIHRo ZSByZXNvdXJjZSBvd25lci4KICAgICAgICAgICAgPC90PgogICAgICAgICAgICA8dCBoYW5nVGV4 dD0ndXNlci1hZ2VudC1iYXNlZCBhcHBsaWNhdGlvbic+CiAgICAgICAgICAgICAgPHZzcGFjZSAv PgogICAgICAgICAgICAgIEEgdXNlci1hZ2VudC1iYXNlZCBhcHBsaWNhdGlvbiBpcyBhIHB1Ymxp YyBjbGllbnQgaW4gd2hpY2ggdGhlIGNsaWVudCBjb2RlIGlzCiAgICAgICAgICAgICAgZG93bmxv YWRlZCBmcm9tIGEgd2ViIHNlcnZlciBhbmQgZXhlY3V0ZXMgd2l0aGluIGEgdXNlci1hZ2VudCAo ZS5nLiB3ZWIgYnJvd3Nlcikgb24KICAgICAgICAgICAgICB0aGUgZGV2aWNlIHVzZWQgYnkgdGhl IHJlc291cmNlIG93bmVyLiBQcm90b2NvbCBkYXRhIGFuZCBjcmVkZW50aWFscyBhcmUgZWFzaWx5 CiAgICAgICAgICAgICAgYWNjZXNzaWJsZSAoYW5kIG9mdGVuIHZpc2libGUpIHRvIHRoZSByZXNv dXJjZSBvd25lci4gU2luY2Ugc3VjaCBhcHBsaWNhdGlvbnMgcmVzaWRlCiAgICAgICAgICAgICAg d2l0aGluIHRoZSB1c2VyLWFnZW50LCB0aGV5IGNhbiBtYWtlIHNlYW1sZXNzIHVzZSBvZiB0aGUg dXNlci1hZ2VudCBjYXBhYmlsaXRpZXMgd2hlbgogICAgICAgICAgICAgIHJlcXVlc3RpbmcgYXV0 aG9yaXphdGlvbi4KICAgICAgICAgICAgPC90PgogICAgICAgICAgICA8dCBoYW5nVGV4dD0nbmF0 aXZlIGFwcGxpY2F0aW9uJz4KICAgICAgICAgICAgICA8dnNwYWNlIC8+CiAgICAgICAgICAgICAg QSBuYXRpdmUgYXBwbGljYXRpb24gaXMgYSBwdWJsaWMgY2xpZW50IGluc3RhbGxlZCBhbmQgZXhl Y3V0ZWQgb24gdGhlIGRldmljZSB1c2VkIGJ5CiAgICAgICAgICAgICAgdGhlIHJlc291cmNlIG93 bmVyLiBQcm90b2NvbCBkYXRhIGFuZCBjcmVkZW50aWFscyBhcmUgYWNjZXNzaWJsZSB0byB0aGUg cmVzb3VyY2UKICAgICAgICAgICAgICBvd25lci4gSXQgaXMgYXNzdW1lZCB0aGF0IGFueSBjbGll bnQgYXV0aGVudGljYXRpb24gY3JlZGVudGlhbHMgaW5jbHVkZWQgaW4gdGhlCiAgICAgICAgICAg ICAgYXBwbGljYXRpb24gY2FuIGJlIGV4dHJhY3RlZC4gT24gdGhlIG90aGVyIGhhbmQsIGR5bmFt aWNhbGx5IGlzc3VlZCBjcmVkZW50aWFscyBzdWNoCiAgICAgICAgICAgICAgYXMgYWNjZXNzIHRv a2VucyBvciByZWZyZXNoIHRva2VucyBjYW4gcmVjZWl2ZSBhbiBhY2NlcHRhYmxlIGxldmVsIG9m IHByb3RlY3Rpb24uIEF0IGEKICAgICAgICAgICAgICBtaW5pbXVtLCB0aGVzZSBjcmVkZW50aWFs cyBhcmUgcHJvdGVjdGVkIGZyb20gaG9zdGlsZSBzZXJ2ZXJzIHdpdGggd2hpY2ggdGhlCiAgICAg ICAgICAgICAgYXBwbGljYXRpb24gbWF5IGludGVyYWN0IHdpdGguIE9uIHNvbWUgcGxhdGZvcm1z IHRoZXNlIGNyZWRlbnRpYWxzIG1pZ2h0IGJlIHByb3RlY3RlZAogICAgICAgICAgICAgIGZyb20g b3RoZXIgYXBwbGljYXRpb25zIHJlc2lkaW5nIG9uIHRoZSBzYW1lIGRldmljZS4KICAgICAgICAg ICAgPC90PgogICAgICAgICAgPC9saXN0PgogICAgICAgIDwvdD4KICAgICAgPC9zZWN0aW9uPgoK ICAgICAgPHNlY3Rpb24gdGl0bGU9J0NsaWVudCBJZGVudGlmaWVyJyBhbmNob3I9J2NsaWVudC1p ZGVudGlmaWVyJz4KICAgICAgICA8dD4KICAgICAgICAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZl ciBpc3N1ZXMgdGhlIHJlZ2lzdGVyZWQgY2xpZW50IGEgY2xpZW50IGlkZW50aWZpZXIgLSBhIHVu aXF1ZQogICAgICAgICAgc3RyaW5nIHJlcHJlc2VudGluZyB0aGUgcmVnaXN0cmF0aW9uIGluZm9y bWF0aW9uIHByb3ZpZGVkIGJ5IHRoZSBjbGllbnQuIFRoZSBjbGllbnQKICAgICAgICAgIGlkZW50 aWZpZXIgaXMgbm90IGEgc2VjcmV0OyBpdCBpcyBleHBvc2VkIHRvIHRoZSByZXNvdXJjZSBvd25l ciwgYW5kIE1VU1QgTk9UIGJlIHVzZWQKICAgICAgICAgIGFsb25lIGZvciBjbGllbnQgYXV0aGVu dGljYXRpb24uIFRoZSBjbGllbnQgaWRlbnRpZmllciBpcyB1bmlxdWUgdG8gdGhlIGF1dGhvcml6 YXRpb24KICAgICAgICAgIHNlcnZlci4KICAgICAgICA8L3Q+CiAgICAgICAgPHQ+CiAgICAgICAg ICBUaGUgY2xpZW50IGlkZW50aWZpZXIgc3RyaW5nIHNpemUgaXMgbGVmdCB1bmRlZmluZWQgYnkg dGhpcyBzcGVjaWZpY2F0aW9uLiBUaGUgY2xpZW50CiAgICAgICAgICBzaG91bGQgYXZvaWQgbWFr aW5nIGFzc3VtcHRpb25zIGFib3V0IHRoZSBpZGVudGlmaWVyIHNpemUuICBUaGUgYXV0aG9yaXph dGlvbiBzZXJ2ZXIKICAgICAgICAgIFNIT1VMRCBkb2N1bWVudCB0aGUgc2l6ZSBvZiBhbnkgaWRl bnRpZmllciBpdCBpc3N1ZXMuCiAgICAgICAgPC90PgogICAgICA8L3NlY3Rpb24+CgogICAgICA8 c2VjdGlvbiB0aXRsZT0nQ2xpZW50IEF1dGhlbnRpY2F0aW9uJyBhbmNob3I9J2NsaWVudC1hdXRo ZW50aWNhdGlvbic+CiAgICAgICAgPHQ+CiAgICAgICAgICBJZiB0aGUgY2xpZW50IHR5cGUgaXMg Y29uZmlkZW50aWFsLCB0aGUgY2xpZW50IGFuZCBhdXRob3JpemF0aW9uIHNlcnZlciBlc3RhYmxp c2ggYSBjbGllbnQKICAgICAgICAgIGF1dGhlbnRpY2F0aW9uIG1ldGhvZCBzdWl0YWJsZSBmb3Ig dGhlIHNlY3VyaXR5IHJlcXVpcmVtZW50cyBvZiB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIuCiAg ICAgICAgICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTUFZIGFjY2VwdCBhbnkgZm9ybSBvZiBj bGllbnQgYXV0aGVudGljYXRpb24gbWVldGluZyBpdHMKICAgICAgICAgIHNlY3VyaXR5IHJlcXVp cmVtZW50cy4KICAgICAgICA8L3Q+CiAgICAgICAgPHQ+CiAgICAgICAgICBDb25maWRlbnRpYWwg Y2xpZW50cyBhcmUgdHlwaWNhbGx5IGlzc3VlZCAob3IgZXN0YWJsaXNoKSBhIHNldCBvZiBjbGll bnQgY3JlZGVudGlhbHMgdXNlZCBmb3IKICAgICAgICAgIGF1dGhlbnRpY2F0aW5nIHdpdGggdGhl IGF1dGhvcml6YXRpb24gc2VydmVyIChlLmcuIHBhc3N3b3JkLCBwdWJsaWMvcHJpdmF0ZSBrZXkg cGFpcikuCiAgICAgICAgPC90PgogICAgICAgIDx0PgogICAgICAgICAgVGhlIGF1dGhvcml6YXRp b24gc2VydmVyIE1BWSBlc3RhYmxpc2ggYSBjbGllbnQgYXV0aGVudGljYXRpb24gbWV0aG9kIHdp dGggcHVibGljIGNsaWVudHMuCiAgICAgICAgICBIb3dldmVyLCB0aGUgYXV0aG9yaXphdGlvbiBz ZXJ2ZXIgTVVTVCBOT1QgcmVseSBvbiBwdWJsaWMgY2xpZW50IGF1dGhlbnRpY2F0aW9uIGZvciB0 aGUKICAgICAgICAgIHB1cnBvc2Ugb2YgaWRlbnRpZnlpbmcgdGhlIGNsaWVudC4KICAgICAgICA8 L3Q+CiAgICAgICAgPHQ+CiAgICAgICAgICBUaGUgY2xpZW50IE1VU1QgTk9UIHVzZSBtb3JlIHRo YW4gb25lIGF1dGhlbnRpY2F0aW9uIG1ldGhvZCBpbiBlYWNoIHJlcXVlc3QuCiAgICAgICAgPC90 PgoKICAgICAgICA8c2VjdGlvbiB0aXRsZT0nQ2xpZW50IFBhc3N3b3JkJyBhbmNob3I9ImNsaWVu dC1wYXNzd29yZCI+CiAgICAgICAgICA8dD4KICAgICAgICAgICAgQ2xpZW50cyBpbiBwb3NzZXNz aW9uIG9mIGEgY2xpZW50IHBhc3N3b3JkIE1BWSB1c2UgdGhlIEhUVFAgQmFzaWMgYXV0aGVudGlj YXRpb24gc2NoZW1lCiAgICAgICAgICAgIGFzIGRlZmluZWQgaW4gPHhyZWYgdGFyZ2V0PSdSRkMy NjE3JyAvPiB0byBhdXRoZW50aWNhdGUgd2l0aCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIuCiAg ICAgICAgICAgIFRoZSBjbGllbnQgaWRlbnRpZmllciBpcyB1c2VkIGFzIHRoZSB1c2VybmFtZSwg YW5kIHRoZSBjbGllbnQgcGFzc3dvcmQgaXMgdXNlZCBhcyB0aGUKICAgICAgICAgICAgcGFzc3dv cmQuIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBNVVNUIHN1cHBvcnQgdGhlIEhUVFAgQmFzaWMg YXV0aGVudGljYXRpb24gc2NoZW1lCiAgICAgICAgICAgIGZvciBhdXRoZW50aWNhdGluZyBjbGll bnRzIHdoaWNoIHdlcmUgaXNzdWVkIGEgY2xpZW50IHBhc3N3b3JkLgogICAgICAgICAgPC90Pgog ICAgICAgICAgPGZpZ3VyZT4KICAgICAgICAgICAgPHByZWFtYmxlPgogICAgICAgICAgICAgIEZv ciBleGFtcGxlIChleHRyYSBsaW5lIGJyZWFrcyBhcmUgZm9yIGRpc3BsYXkgcHVycG9zZXMgb25s eSk6CiAgICAgICAgICAgIDwvcHJlYW1ibGU+CiAgICAgICAgICAgIDxhcnR3b3JrPgogICAgICAg ICAgICAgIDwhW0NEQVRBWwogIEF1dGhvcml6YXRpb246IEJhc2ljIGN6WkNhR1JTYTNGME16bzNS bXBtY0RCYVFuSXhTM1JFVW1KdVpsWmtiVWwzCl1dPgogICAgICAgICAgICA8L2FydHdvcms+CiAg ICAgICAgICA8L2ZpZ3VyZT4KICAgICAgICAgIDx0PgogICAgICAgICAgICBBbHRlcm5hdGl2ZWx5 LCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTUFZIHN1cHBvcnQgaW5jbHVkaW5nIHRoZSBjbGll bnQgY3JlZGVudGlhbHMgaW4KICAgICAgICAgICAgdGhlIHJlcXVlc3QgYm9keSB1c2luZyB0aGUg Zm9sbG93aW5nIHBhcmFtZXRlcnM6CiAgICAgICAgICA8L3Q+CiAgICAgICAgICA8dD4KICAgICAg ICAgICAgPGxpc3Qgc3R5bGU9J2hhbmdpbmcnIGhhbmdJbmRlbnQ9JzYnPgogICAgICAgICAgICAg IDx0IGhhbmdUZXh0PSdjbGllbnRfaWQnPgogICAgICAgICAgICAgICAgPHZzcGFjZSAvPgogICAg ICAgICAgICAgICAgUkVRVUlSRUQuIFRoZSBjbGllbnQgaWRlbnRpZmllciBpc3N1ZWQgdG8gdGhl IGNsaWVudCBkdXJpbmcgdGhlIHJlZ2lzdHJhdGlvbiBwcm9jZXNzCiAgICAgICAgICAgICAgICBk ZXNjcmliZWQgYnkgPHhyZWYgdGFyZ2V0PSdjbGllbnQtaWRlbnRpZmllcicgLz4uCiAgICAgICAg ICAgICAgPC90PgogICAgICAgICAgICAgIDx0IGhhbmdUZXh0PSdjbGllbnRfc2VjcmV0Jz4KICAg ICAgICAgICAgICAgIDx2c3BhY2UgLz4KICAgICAgICAgICAgICAgIFJFUVVJUkVELiBUaGUgY2xp ZW50IHNlY3JldC4gVGhlIGNsaWVudCBNQVkgb21pdCB0aGUgcGFyYW1ldGVyIGlmIHRoZSBjbGll bnQgc2VjcmV0CiAgICAgICAgICAgICAgICBpcyBhbiBlbXB0eSBzdHJpbmcuCiAgICAgICAgICAg ICAgPC90PgogICAgICAgICAgICA8L2xpc3Q+CiAgICAgICAgICA8L3Q+CiAgICAgICAgICA8dD4K ICAgICAgICAgICAgSW5jbHVkaW5nIHRoZSBjbGllbnQgY3JlZGVudGlhbHMgaW4gdGhlIHJlcXVl c3QgYm9keSB1c2luZyB0aGUgdHdvIHBhcmFtZXRlcnMgaXMgTk9UCiAgICAgICAgICAgIFJFQ09N TUVOREVELCBhbmQgU0hPVUxEIGJlIGxpbWl0ZWQgdG8gY2xpZW50cyB1bmFibGUgdG8gZGlyZWN0 bHkgdXRpbGl6ZSB0aGUgSFRUUCBCYXNpYwogICAgICAgICAgICBhdXRoZW50aWNhdGlvbiBzY2hl bWUgKG9yIG90aGVyIHBhc3N3b3JkLWJhc2VkIEhUVFAgYXV0aGVudGljYXRpb24gc2NoZW1lcyku IFRoZQogICAgICAgICAgICBwYXJhbWV0ZXJzIGNhbiBvbmx5IGJlIHRyYW5zbWl0dGVkIGluIHRo ZSByZXF1ZXN0IGJvZHkgYW5kIE1VU1QgTk9UIGJlIGluY2x1ZGVkIGluIHRoZQogICAgICAgICAg ICByZXF1ZXN0IFVSSS4KICAgICAgICAgIDwvdD4KICAgICAgICAgIDxmaWd1cmU+CiAgICAgICAg ICAgIDxwcmVhbWJsZT4KICAgICAgICAgICAgICBGb3IgZXhhbXBsZSwgcmVxdWVzdGluZyB0byBy ZWZyZXNoIGFuIGFjY2VzcyB0b2tlbiAoPHhyZWYgdGFyZ2V0PSd0b2tlbi1yZWZyZXNoJyAvPikK ICAgICAgICAgICAgICB1c2luZyB0aGUgYm9keSBwYXJhbWV0ZXJzIChleHRyYSBsaW5lIGJyZWFr cyBhcmUgZm9yIGRpc3BsYXkgcHVycG9zZXMgb25seSk6CiAgICAgICAgICAgIDwvcHJlYW1ibGU+ CiAgICAgICAgICAgIDxhcnR3b3JrPgogICAgICAgICAgICAgIDwhW0NEQVRBWwogIFBPU1QgL3Rv a2VuIEhUVFAvMS4xCiAgSG9zdDogc2VydmVyLmV4YW1wbGUuY29tCiAgQ29udGVudC1UeXBlOiBh cHBsaWNhdGlvbi94LXd3dy1mb3JtLXVybGVuY29kZWQ7Y2hhcnNldD1VVEYtOAoKICBncmFudF90 eXBlPXJlZnJlc2hfdG9rZW4mcmVmcmVzaF90b2tlbj10R3p2M0pPa0YwWEc1UXgyVGxLV0lBCiAg JmNsaWVudF9pZD1zNkJoZFJrcXQzJmNsaWVudF9zZWNyZXQ9N0ZqZnAwWkJyMUt0RFJibmZWZG1J dwpdXT4KICAgICAgICAgICAgPC9hcnR3b3JrPgogICAgICAgICAgPC9maWd1cmU+CiAgICAgICAg ICA8dD4KICAgICAgICAgICAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIE1VU1QgcmVxdWlyZSB0 aGUgdXNlIG9mIFRMUyBhcyBkZXNjcmliZWQgaW4KICAgICAgICAgICAgPHhyZWYgdGFyZ2V0PSd0 bHMnIC8+IHdoZW4gc2VuZGluZyByZXF1ZXN0cyB1c2luZyBwYXNzd29yZCBhdXRoZW50aWNhdGlv bi4KICAgICAgICAgIDwvdD4KICAgICAgICAgIDx0PgogICAgICAgICAgICBTaW5jZSB0aGlzIGNs aWVudCBhdXRoZW50aWNhdGlvbiBtZXRob2QgaW52b2x2ZXMgYSBwYXNzd29yZCwgdGhlIGF1dGhv cml6YXRpb24gc2VydmVyCiAgICAgICAgICAgIE1VU1QgcHJvdGVjdCBhbnkgZW5kcG9pbnQgdXRp bGl6aW5nIGl0IGFnYWluc3QgYnJ1dGUgZm9yY2UgYXR0YWNrcy4KICAgICAgICAgIDwvdD4KICAg ICAgICA8L3NlY3Rpb24+CgogICAgICAgIDxzZWN0aW9uIHRpdGxlPSdPdGhlciBBdXRoZW50aWNh dGlvbiBNZXRob2RzJz4KICAgICAgICAgIDx0PgogICAgICAgICAgICBUaGUgYXV0aG9yaXphdGlv biBzZXJ2ZXIgTUFZIHN1cHBvcnQgYW55IHN1aXRhYmxlIEhUVFAgYXV0aGVudGljYXRpb24gc2No ZW1lIG1hdGNoaW5nCiAgICAgICAgICAgIGl0cyBzZWN1cml0eSByZXF1aXJlbWVudHMuIFdoZW4g dXNpbmcgb3RoZXIgYXV0aGVudGljYXRpb24gbWV0aG9kcywgdGhlIGF1dGhvcml6YXRpb24KICAg ICAgICAgICAgc2VydmVyIE1VU1QgZGVmaW5lIGEgbWFwcGluZyBiZXR3ZWVuIHRoZSBjbGllbnQg aWRlbnRpZmllciAocmVnaXN0cmF0aW9uIHJlY29yZCkgYW5kCiAgICAgICAgICAgIGF1dGhlbnRp Y2F0aW9uIHNjaGVtZS4KICAgICAgICAgIDwvdD4KICAgICAgICA8L3NlY3Rpb24+CgogICAgICA8 L3NlY3Rpb24+CgogICAgICA8c2VjdGlvbiB0aXRsZT0nVW5yZWdpc3RlcmVkIENsaWVudHMnPgog ICAgICAgIDx0PgogICAgICAgICAgVGhpcyBzcGVjaWZpY2F0aW9uIGRvZXMgbm90IGV4Y2x1ZGUg dGhlIHVzZSBvZiB1bnJlZ2lzdGVyZWQgY2xpZW50cy4gSG93ZXZlciwgdGhlIHVzZQogICAgICAg ICAgd2l0aCBzdWNoIGNsaWVudHMgaXMgYmV5b25kIHRoZSBzY29wZSBvZiB0aGlzIHNwZWNpZmlj YXRpb24sIGFuZCByZXF1aXJlcyBhZGRpdGlvbmFsCiAgICAgICAgICBzZWN1cml0eSBhbmFseXNp cyBhbmQgcmV2aWV3IG9mIGl0cyBpbnRlcm9wZXJhYmlsaXR5IGltcGFjdC4KICAgICAgICA8L3Q+ CiAgICAgIDwvc2VjdGlvbj4KICAgICAgCiAgICA8L3NlY3Rpb24+CgogICAgPHNlY3Rpb24gdGl0 bGU9J1Byb3RvY29sIEVuZHBvaW50cyc+CiAgICAgIDx0PgogICAgICAgIFRoZSBhdXRob3JpemF0 aW9uIHByb2Nlc3MgdXRpbGl6ZXMgdHdvIGF1dGhvcml6YXRpb24gc2VydmVyIGVuZHBvaW50cyAo SFRUUCByZXNvdXJjZXMpOgogICAgICA8L3Q+CiAgICAgIDx0PgogICAgICAgIDxsaXN0IHN0eWxl PSdzeW1ib2xzJz4KICAgICAgICAgIDx0PgogICAgICAgICAgICBBdXRob3JpemF0aW9uIGVuZHBv aW50IC0gdXNlZCBieSB0aGUgY2xpZW50IHRvIG9idGFpbiBhdXRob3JpemF0aW9uIGZyb20gdGhl IHJlc291cmNlCiAgICAgICAgICAgIG93bmVyIHZpYSB1c2VyLWFnZW50IHJlZGlyZWN0aW9uLgog ICAgICAgICAgPC90PgogICAgICAgICAgPHQ+CiAgICAgICAgICAgIFRva2VuIGVuZHBvaW50IC0g dXNlZCBieSB0aGUgY2xpZW50IHRvIGV4Y2hhbmdlIGFuIGF1dGhvcml6YXRpb24gZ3JhbnQgZm9y IGFuIGFjY2VzcwogICAgICAgICAgICB0b2tlbiwgdHlwaWNhbGx5IHdpdGggY2xpZW50IGF1dGhl bnRpY2F0aW9uLgogICAgICAgICAgPC90PgogICAgICAgIDwvbGlzdD4KICAgICAgPC90PgogICAg ICA8dD4KICAgICAgICBBcyB3ZWxsIGFzIG9uZSBjbGllbnQgZW5kcG9pbnQ6CiAgICAgIDwvdD4K ICAgICAgPHQ+CiAgICAgICAgPGxpc3Qgc3R5bGU9J3N5bWJvbHMnPgogICAgICAgICAgPHQ+CiAg ICAgICAgICAgIFJlZGlyZWN0aW9uIGVuZHBvaW50IC0gdXNlZCBieSB0aGUgYXV0aG9yaXphdGlv biBzZXJ2ZXIgdG8gcmV0dXJuIGF1dGhvcml6YXRpb24KICAgICAgICAgICAgY3JlZGVudGlhbHMg cmVzcG9uc2VzIHRvIHRoZSBjbGllbnQgdmlhIHRoZSByZXNvdXJjZSBvd25lciB1c2VyLWFnZW50 LgogICAgICAgICAgPC90PgogICAgICAgIDwvbGlzdD4KICAgICAgPC90PgogICAgICA8dD4KICAg ICAgICBOb3QgZXZlcnkgYXV0aG9yaXphdGlvbiBncmFudCB0eXBlIHV0aWxpemVzIGJvdGggZW5k cG9pbnRzLiBFeHRlbnNpb24gZ3JhbnQgdHlwZXMgTUFZCiAgICAgICAgZGVmaW5lIGFkZGl0aW9u YWwgZW5kcG9pbnRzIGFzIG5lZWRlZC4KICAgICAgPC90PgoKICAgICAgPHNlY3Rpb24gdGl0bGU9 J0F1dGhvcml6YXRpb24gRW5kcG9pbnQnPgogICAgICAgIDx0PgogICAgICAgICAgVGhlIGF1dGhv cml6YXRpb24gZW5kcG9pbnQgaXMgdXNlZCB0byBpbnRlcmFjdCB3aXRoIHRoZSByZXNvdXJjZSBv d25lciBhbmQgb2J0YWluCiAgICAgICAgICBhbiBhdXRob3JpemF0aW9uIGdyYW50LiBUaGUgYXV0 aG9yaXphdGlvbiBzZXJ2ZXIgTVVTVCBmaXJzdCB2ZXJpZnkgdGhlIGlkZW50aXR5IG9mIHRoZQog ICAgICAgICAgcmVzb3VyY2Ugb3duZXIuIFRoZSB3YXkgaW4gd2hpY2ggdGhlIGF1dGhvcml6YXRp b24gc2VydmVyIGF1dGhlbnRpY2F0ZXMgdGhlIHJlc291cmNlCiAgICAgICAgICBvd25lciAoZS5n LiB1c2VybmFtZSBhbmQgcGFzc3dvcmQgbG9naW4sIHNlc3Npb24gY29va2llcykgaXMgYmV5b25k IHRoZSBzY29wZSBvZiB0aGlzCiAgICAgICAgICBzcGVjaWZpY2F0aW9uLgogICAgICAgIDwvdD4K ICAgICAgICA8dD4KICAgICAgICAgIFRoZSBtZWFucyB0aHJvdWdoIHdoaWNoIHRoZSBjbGllbnQg b2J0YWlucyB0aGUgbG9jYXRpb24gb2YgdGhlIGF1dGhvcml6YXRpb24gZW5kcG9pbnQgYXJlCiAg ICAgICAgICBiZXlvbmQgdGhlIHNjb3BlIG9mIHRoaXMgc3BlY2lmaWNhdGlvbiwgYnV0IHRoZSBs b2NhdGlvbiBpcyB0eXBpY2FsbHkgcHJvdmlkZWQgaW4gdGhlCiAgICAgICAgICBzZXJ2aWNlIGRv Y3VtZW50YXRpb24uCiAgICAgICAgPC90PgogICAgICAgIDx0PgogICAgICAgICAgVGhlIGVuZHBv aW50IFVSSSBNQVkgaW5jbHVkZSBhbgogICAgICAgICAgPHNwYW54IHN0eWxlPSd2ZXJiJz5hcHBs aWNhdGlvbi94LXd3dy1mb3JtLXVybGVuY29kZWQ8L3NwYW54PiBmb3JtYXR0ZWQKICAgICAgICAg ICg8eHJlZiB0YXJnZXQ9J1czQy5SRUMtaHRtbDQwMS0xOTk5MTIyNCcgLz4pIHF1ZXJ5IGNvbXBv bmVudCAoPHhyZWYgdGFyZ2V0PSdSRkMzOTg2JyAvPgogICAgICAgICAgc2VjdGlvbiAzLjQpLCB3 aGljaCBNVVNUIGJlIHJldGFpbmVkIHdoZW4gYWRkaW5nIGFkZGl0aW9uYWwgcXVlcnkgcGFyYW1l dGVycy4gVGhlCiAgICAgICAgICBlbmRwb2ludCBVUkkgTVVTVCBOT1QgaW5jbHVkZSBhIGZyYWdt ZW50IGNvbXBvbmVudC4KICAgICAgICA8L3Q+CiAgICAgICAgPHQ+CiAgICAgICAgICBTaW5jZSBy ZXF1ZXN0cyB0byB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludCByZXN1bHQgaW4gdXNlciBhdXRo ZW50aWNhdGlvbiBhbmQgdGhlCiAgICAgICAgICB0cmFuc21pc3Npb24gb2YgY2xlYXItdGV4dCBj cmVkZW50aWFscyAoaW4gdGhlIEhUVFAgcmVzcG9uc2UpLCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2 ZXIKICAgICAgICAgIE1VU1QgcmVxdWlyZSB0aGUgdXNlIG9mIFRMUyBhcyBkZXNjcmliZWQgaW4g PHhyZWYgdGFyZ2V0PSd0bHMnIC8+IHdoZW4gc2VuZGluZyByZXF1ZXN0cwogICAgICAgICAgdG8g dGhlIGF1dGhvcml6YXRpb24gZW5kcG9pbnQuCiAgICAgICAgPC90PgogICAgICAgIDx0PgogICAg ICAgICAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIE1VU1Qgc3VwcG9ydCB0aGUgdXNlIG9mIHRo ZSBIVFRQIDxzcGFueCBzdHlsZT0ndmVyYic+R0VUPC9zcGFueD4KICAgICAgICAgIG1ldGhvZCA8 eHJlZiB0YXJnZXQ9J1JGQzI2MTYnIC8+IGZvciB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludCwg YW5kIE1BWSBzdXBwb3J0IHRoZSB1c2UKICAgICAgICAgIG9mIHRoZSA8c3Bhbnggc3R5bGU9J3Zl cmInPlBPU1Q8L3NwYW54PiBtZXRob2QgYXMgd2VsbC4KICAgICAgICA8L3Q+CiAgICAgICAgPHQ+ CiAgICAgICAgICBQYXJhbWV0ZXJzIHNlbnQgd2l0aG91dCBhIHZhbHVlIE1VU1QgYmUgdHJlYXRl ZCBhcyBpZiB0aGV5IHdlcmUgb21pdHRlZCBmcm9tIHRoZSByZXF1ZXN0LgogICAgICAgICAgVGhl IGF1dGhvcml6YXRpb24gc2VydmVyIE1VU1QgaWdub3JlIHVucmVjb2duaXplZCByZXF1ZXN0IHBh cmFtZXRlcnMuIFJlcXVlc3QgYW5kCiAgICAgICAgICByZXNwb25zZSBwYXJhbWV0ZXJzIE1VU1Qg Tk9UIGJlIGluY2x1ZGVkIG1vcmUgdGhhbiBvbmNlLgogICAgICAgIDwvdD4KCiAgICAgICAgPHNl Y3Rpb24gdGl0bGU9J1Jlc3BvbnNlIFR5cGUnIGFuY2hvcj0icmVzcG9uc2UtdHlwZSI+CiAgICAg ICAgICA8dD4KICAgICAgICAgICAgVGhlIGF1dGhvcml6YXRpb24gZW5kcG9pbnQgaXMgdXNlZCBi eSB0aGUgYXV0aG9yaXphdGlvbiBjb2RlIGdyYW50IHR5cGUgYW5kIGltcGxpY2l0CiAgICAgICAg ICAgIGdyYW50IHR5cGUgZmxvd3MuIFRoZSBjbGllbnQgaW5mb3JtcyB0aGUgYXV0aG9yaXphdGlv biBzZXJ2ZXIgb2YgdGhlIGRlc2lyZWQgZ3JhbnQKICAgICAgICAgICAgdHlwZSB1c2luZyB0aGUg Zm9sbG93aW5nIHBhcmFtZXRlcjoKICAgICAgICAgIDwvdD4KICAgICAgICAgIDx0PgogICAgICAg ICAgICA8bGlzdCBzdHlsZT0naGFuZ2luZycgaGFuZ0luZGVudD0nNic+CiAgICAgICAgICAgICAg PHQgaGFuZ1RleHQ9J3Jlc3BvbnNlX3R5cGUnPgogICAgICAgICAgICAgICAgPHZzcGFjZSAvPgog ICAgICAgICAgICAgICAgUkVRVUlSRUQuIFRoZSB2YWx1ZSBNVVNUIGJlIG9uZSBvZiA8c3Bhbngg c3R5bGU9J3ZlcmInPmNvZGU8L3NwYW54PiBmb3IgcmVxdWVzdGluZwogICAgICAgICAgICAgICAg YW4gYXV0aG9yaXphdGlvbiBjb2RlIGFzIGRlc2NyaWJlZCBieSA8eHJlZiB0YXJnZXQ9J2NvZGUt YXV0aHotcmVxJyAvPiwKICAgICAgICAgICAgICAgIDxzcGFueCBzdHlsZT0ndmVyYic+dG9rZW48 L3NwYW54PiBmb3IgcmVxdWVzdGluZyBhbiBhY2Nlc3MgdG9rZW4gKGltcGxpY2l0IGdyYW50KQog ICAgICAgICAgICAgICAgYXMgZGVzY3JpYmVkIGJ5IDx4cmVmIHRhcmdldD0naW1wbGljaXQtYXV0 aHotcmVxJyAvPiwgb3IgYSByZWdpc3RlcmVkIGV4dGVuc2lvbgogICAgICAgICAgICAgICAgdmFs dWUgYXMgZGVzY3JpYmVkIGJ5IDx4cmVmIHRhcmdldD0ncmVzcG9uc2UtdHlwZS1leHQnIC8+Lgog ICAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAgPC9saXN0PgogICAgICAgICAgPC90PgogICAg ICAgICAgPHQ+CiAgICAgICAgICAgIEV4dGVuc2lvbiByZXNwb25zZSB0eXBlcyBNQVkgY29udGFp biBhIHNwYWNlLWRlbGltaXRlZCAoJXgyMCkgbGlzdCBvZiB2YWx1ZXMsIHdoZXJlIHRoZQogICAg ICAgICAgICBvcmRlciBvZiB2YWx1ZXMgZG9lcyBub3QgbWF0dGVyIChlLmcuIHJlc3BvbnNlIHR5 cGUgPHNwYW54IHN0eWxlPSd2ZXJiJz5hIGI8L3NwYW54PiBpcwogICAgICAgICAgICB0aGUgc2Ft ZSBhcyA8c3Bhbnggc3R5bGU9J3ZlcmInPmIgYTwvc3Bhbng+KS4gVGhlIG1lYW5pbmcgb2Ygc3Vj aCBjb21wb3NpdGUgcmVzcG9uc2UKICAgICAgICAgICAgdHlwZXMgaXMgZGVmaW5lZCBieSB0aGVp ciByZXNwZWN0aXZlIHNwZWNpZmljYXRpb25zLgogICAgICAgICAgPC90PgogICAgICAgICAgPHQ+ CiAgICAgICAgICAgIElmIGFuIGF1dGhvcml6YXRpb24gcmVxdWVzdCBpcyBtaXNzaW5nIHRoZSA8 c3Bhbnggc3R5bGU9J3ZlcmInPnJlc3BvbnNlX3R5cGU8L3NwYW54PgogICAgICAgICAgICBwYXJh bWV0ZXIsIG9yIGlmIHRoZSByZXNwb25zZSB0eXBlIGlzIG5vdCB1bmRlcnN0b29kLCB0aGUgYXV0 aG9yaXphdGlvbiBzZXJ2ZXIgTVVTVAogICAgICAgICAgICByZXR1cm4gYW4gZXJyb3IgcmVzcG9u c2UgYXMgZGVzY3JpYmVkIGluIDx4cmVmIHRhcmdldD0nY29kZS1hdXRoei1lcnJvcicgLz4uCiAg ICAgICAgICA8L3Q+CiAgICAgICAgPC9zZWN0aW9uPgoKICAgICAgICA8c2VjdGlvbiB0aXRsZT0n UmVkaXJlY3Rpb24gRW5kcG9pbnQnIGFuY2hvcj0ncmVkaXJlY3QtdXJpJz4KICAgICAgICAgIDx0 PgogICAgICAgICAgICBBZnRlciBjb21wbGV0aW5nIGl0cyBpbnRlcmFjdGlvbiB3aXRoIHRoZSBy ZXNvdXJjZSBvd25lciwgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyCiAgICAgICAgICAgIGRpcmVj dHMgdGhlIHJlc291cmNlIG93bmVyJ3MgdXNlci1hZ2VudCBiYWNrIHRvIHRoZSBjbGllbnQuIFRo ZSBhdXRob3JpemF0aW9uIHNlcnZlcgogICAgICAgICAgICByZWRpcmVjdHMgdGhlIHVzZXItYWdl bnQgdG8gdGhlIGNsaWVudCdzIHJlZGlyZWN0aW9uIGVuZHBvaW50IHByZXZpb3VzbHkgZXN0YWJs aXNoZWQKICAgICAgICAgICAgd2l0aCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgZHVyaW5nIHRo ZSBjbGllbnQgcmVnaXN0cmF0aW9uIHByb2Nlc3Mgb3Igd2hlbiBtYWtpbmcKICAgICAgICAgICAg dGhlIGF1dGhvcml6YXRpb24gcmVxdWVzdC4KICAgICAgICAgIDwvdD4KICAgICAgICAgIDx0Pgog ICAgICAgICAgICBUaGUgcmVkaXJlY3Rpb24gZW5kcG9pbnQgVVJJIE1VU1QgYmUgYW4gYWJzb2x1 dGUgVVJJIGFzIGRlZmluZWQgYnkKICAgICAgICAgICAgPHhyZWYgdGFyZ2V0PSdSRkMzOTg2JyAv PiBzZWN0aW9uIDQuMy4gVGhlIGVuZHBvaW50IFVSSSBNQVkgaW5jbHVkZSBhbgogICAgICAgICAg ICA8c3Bhbnggc3R5bGU9J3ZlcmInPmFwcGxpY2F0aW9uL3gtd3d3LWZvcm0tdXJsZW5jb2RlZDwv c3Bhbng+IGZvcm1hdHRlZAogICAgICAgICAgICAoPHhyZWYgdGFyZ2V0PSdXM0MuUkVDLWh0bWw0 MDEtMTk5OTEyMjQnIC8+KSBxdWVyeSBjb21wb25lbnQgKDx4cmVmIHRhcmdldD0nUkZDMzk4Nicg Lz4KICAgICAgICAgICAgc2VjdGlvbiAzLjQpLCB3aGljaCBNVVNUIGJlIHJldGFpbmVkIHdoZW4g YWRkaW5nIGFkZGl0aW9uYWwgcXVlcnkgcGFyYW1ldGVycy4gVGhlCiAgICAgICAgICAgIGVuZHBv aW50IFVSSSBNVVNUIE5PVCBpbmNsdWRlIGEgZnJhZ21lbnQgY29tcG9uZW50LgogICAgICAgICAg PC90PgoKICAgICAgICAgIDxzZWN0aW9uIHRpdGxlPSdFbmRwb2ludCBSZXF1ZXN0IENvbmZpZGVu dGlhbGl0eSc+CiAgICAgICAgICAgIDx0PgogICAgICAgICAgICAgIFRoZSByZWRpcmVjdGlvbiBl bmRwb2ludCBTSE9VTEQgcmVxdWlyZSB0aGUgdXNlIG9mIFRMUyBhcyBkZXNjcmliZWQgaW4KICAg ICAgICAgICAgICA8eHJlZiB0YXJnZXQ9J3RscycgLz4gd2hlbiB0aGUgcmVxdWVzdGVkIHJlc3Bv bnNlIHR5cGUgaXMKICAgICAgICAgICAgICA8c3Bhbnggc3R5bGU9J3ZlcmInPmNvZGU8L3NwYW54 PiBvciA8c3Bhbnggc3R5bGU9J3ZlcmInPnRva2VuPC9zcGFueD4sIG9yCiAgICAgICAgICAgICAg d2hlbiB0aGUgcmVkaXJlY3Rpb24gcmVxdWVzdCB3aWxsIHJlc3VsdCBpbiB0aGUgdHJhbnNtaXNz aW9uIG9mIHNlbnNpdGl2ZSBjcmVkZW50aWFscwogICAgICAgICAgICAgIG92ZXIgYW4gb3BlbiBu ZXR3b3JrLiBUaGlzIHNwZWNpZmljYXRpb24gZG9lcyBub3QgbWFuZGF0ZSB0aGUgdXNlIG9mIFRM UyBiZWNhdXNlIGF0CiAgICAgICAgICAgICAgdGhlIHRpbWUgb2YgdGhpcyB3cml0aW5nLCByZXF1 aXJpbmcgY2xpZW50cyB0byBkZXBsb3kgVExTIGlzIGEgc2lnbmlmaWNhbnQgaHVyZGxlIGZvcgog ICAgICAgICAgICAgIG1hbnkgY2xpZW50IGRldmVsb3BlcnMuIElmIFRMUyBpcyBub3QgYXZhaWxh YmxlLCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgU0hPVUxEIHdhcm4KICAgICAgICAgICAgICB0 aGUgcmVzb3VyY2Ugb3duZXIgYWJvdXQgdGhlIGluc2VjdXJlIGVuZHBvaW50IHByaW9yIHRvIHJl ZGlyZWN0aW9uIChlLmcuIGRpc3BsYXkgYQogICAgICAgICAgICAgIG1lc3NhZ2UgZHVyaW5nIHRo ZSBhdXRob3JpemF0aW9uIHJlcXVlc3QpLgogICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgIDx0 PgogICAgICAgICAgICAgIExhY2sgb2YgdHJhbnNwb3J0LWxheWVyIHNlY3VyaXR5IGNhbiBoYXZl IGEgc2V2ZXJlIGltcGFjdCBvbiB0aGUgc2VjdXJpdHkgb2YgdGhlCiAgICAgICAgICAgICAgY2xp ZW50IGFuZCB0aGUgcHJvdGVjdGVkIHJlc291cmNlcyBpdCBpcyBhdXRob3JpemVkIHRvIGFjY2Vz cy4gVGhlIHVzZSBvZgogICAgICAgICAgICAgIHRyYW5zcG9ydC1sYXllciBzZWN1cml0eSBpcyBw YXJ0aWN1bGFybHkgY3JpdGljYWwgd2hlbiB0aGUgYXV0aG9yaXphdGlvbiBwcm9jZXNzIGlzCiAg ICAgICAgICAgICAgdXNlZCBhcyBhIGZvcm0gb2YgZGVsZWdhdGVkIGVuZC11c2VyIGF1dGhlbnRp Y2F0aW9uIGJ5IHRoZSBjbGllbnQgKGUuZy4gdGhpcmQtcGFydHkKICAgICAgICAgICAgICBzaWdu LWluIHNlcnZpY2UpLgogICAgICAgICAgICA8L3Q+CiAgICAgICAgICA8L3NlY3Rpb24+CgogICAg ICAgICAgPHNlY3Rpb24gdGl0bGU9J1JlZ2lzdHJhdGlvbiBSZXF1aXJlbWVudHMnPgogICAgICAg ICAgICA8dD4KICAgICAgICAgICAgICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVTVCByZXF1 aXJlIHRoZSBmb2xsb3dpbmcgY2xpZW50cyB0byByZWdpc3RlciB0aGVpcgogICAgICAgICAgICAg IHJlZGlyZWN0aW9uIGVuZHBvaW50OgogICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgIDx0Pgog ICAgICAgICAgICAgIDxsaXN0IHN0eWxlPSdzeW1ib2xzJz4KICAgICAgICAgICAgICAgIDx0Pgog ICAgICAgICAgICAgICAgICBQdWJsaWMgY2xpZW50cy4KICAgICAgICAgICAgICAgIDwvdD4KICAg ICAgICAgICAgICAgIDx0PgogICAgICAgICAgICAgICAgICBDb25maWRlbnRpYWwgY2xpZW50cyB1 dGlsaXppbmcgdGhlIGltcGxpY2l0IGdyYW50IHR5cGUuCiAgICAgICAgICAgICAgICA8L3Q+CiAg ICAgICAgICAgICAgPC9saXN0PgogICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgIDx0PgogICAg ICAgICAgICAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBTSE9VTEQgcmVxdWlyZSBhbGwgY2xp ZW50cyB0byByZWdpc3RlciB0aGVpciByZWRpcmVjdGlvbgogICAgICAgICAgICAgIGVuZHBvaW50 IHByaW9yIHRvIHV0aWxpemluZyB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludC4KICAgICAgICAg ICAgPC90PgogICAgICAgICAgICA8dD4KICAgICAgICAgICAgICBUaGUgYXV0aG9yaXphdGlvbiBz ZXJ2ZXIgU0hPVUxEIHJlcXVpcmUgdGhlIGNsaWVudCB0byBwcm92aWRlIHRoZSBjb21wbGV0ZQog ICAgICAgICAgICAgIHJlZGlyZWN0aW9uIFVSSSAodGhlIGNsaWVudCBNQVkgdXNlIHRoZSA8c3Bh bnggc3R5bGU9J3ZlcmInPnN0YXRlPC9zcGFueD4gcmVxdWVzdAogICAgICAgICAgICAgIHBhcmFt ZXRlciB0byBhY2hpZXZlIHBlci1yZXF1ZXN0IGN1c3RvbWl6YXRpb24pLiBJZiByZXF1aXJpbmcg dGhlIHJlZ2lzdHJhdGlvbiBvZgogICAgICAgICAgICAgIHRoZSBjb21wbGV0ZSByZWRpcmVjdGlv biBVUkkgaXMgbm90IHBvc3NpYmxlLCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgU0hPVUxEIHJl cXVpcmUKICAgICAgICAgICAgICB0aGUgcmVnaXN0cmF0aW9uIG9mIHRoZSBVUkkgc2NoZW1lLCBh dXRob3JpdHksIGFuZCBwYXRoIChhbGxvd2luZyB0aGUgY2xpZW50IHRvCiAgICAgICAgICAgICAg ZHluYW1pY2FsbHkgdmFyeSBvbmx5IHRoZSBxdWVyeSBjb21wb25lbnQgb2YgdGhlIHJlZGlyZWN0 aW9uIFVSSSB3aGVuIHJlcXVlc3RpbmcKICAgICAgICAgICAgICBhdXRob3JpemF0aW9uKS4KICAg ICAgICAgICAgPC90PgogICAgICAgICAgICA8dD4KICAgICAgICAgICAgICBUaGUgYXV0aG9yaXph dGlvbiBzZXJ2ZXIgTUFZIGFsbG93IHRoZSBjbGllbnQgdG8gcmVnaXN0ZXIgbXVsdGlwbGUgcmVk aXJlY3Rpb24KICAgICAgICAgICAgICBlbmRwb2ludHMuCiAgICAgICAgICAgIDwvdD4KICAgICAg ICAgICAgPHQ+CiAgICAgICAgICAgICAgTGFjayBvZiBhIHJlZGlyZWN0aW9uIFVSSSByZWdpc3Ry YXRpb24gcmVxdWlyZW1lbnQgY2FuIGVuYWJsZSBhbiBhdHRhY2tlciB0byB1c2UKICAgICAgICAg ICAgICB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludCBhcyBvcGVuIHJlZGlyZWN0b3IgYXMgZGVz Y3JpYmVkIGluCiAgICAgICAgICAgICAgPHhyZWYgdGFyZ2V0PSdvcGVuLXJlZGlyZWN0JyAvPi4K ICAgICAgICAgICAgPC90PgogICAgICAgICAgPC9zZWN0aW9uPgoKICAgICAgICAgIDxzZWN0aW9u IHRpdGxlPSdEeW5hbWljIENvbmZpZ3VyYXRpb24nPgogICAgICAgICAgICA8dD4KICAgICAgICAg ICAgICBJZiBtdWx0aXBsZSByZWRpcmVjdGlvbiBVUklzIGhhdmUgYmVlbiByZWdpc3RlcmVkLCBp ZiBvbmx5IHBhcnQgb2YgdGhlIHJlZGlyZWN0aW9uCiAgICAgICAgICAgICAgVVJJIGhhcyBiZWVu IHJlZ2lzdGVyZWQsIG9yIGlmIG5vIHJlZGlyZWN0aW9uIFVSSSBoYXMgYmVlbiByZWdpc3RlcmVk LCB0aGUgY2xpZW50CiAgICAgICAgICAgICAgTVVTVCBpbmNsdWRlIGEgcmVkaXJlY3Rpb24gVVJJ IHdpdGggdGhlIGF1dGhvcml6YXRpb24gcmVxdWVzdCB1c2luZyB0aGUKICAgICAgICAgICAgICA8 c3Bhbnggc3R5bGU9J3ZlcmInPnJlZGlyZWN0X3VyaTwvc3Bhbng+IHJlcXVlc3QgcGFyYW1ldGVy LgogICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgIDx0PgogICAgICAgICAgICAgIFdoZW4gYSBy ZWRpcmVjdGlvbiBVUkkgaXMgaW5jbHVkZWQgaW4gYW4gYXV0aG9yaXphdGlvbiByZXF1ZXN0LCB0 aGUgYXV0aG9yaXphdGlvbgogICAgICAgICAgICAgIHNlcnZlciBNVVNUIGNvbXBhcmUgYW5kIG1h dGNoIHRoZSB2YWx1ZSByZWNlaXZlZCBhZ2FpbnN0IGF0IGxlYXN0IG9uZSBvZiB0aGUKICAgICAg ICAgICAgICByZWdpc3RlcmVkIHJlZGlyZWN0aW9uIFVSSXMgKG9yIFVSSSBjb21wb25lbnRzKSBh cyBkZWZpbmVkIGluCiAgICAgICAgICAgICAgPHhyZWYgdGFyZ2V0PSdSRkMzOTg2JyAvPiBzZWN0 aW9uIDYsIGlmIGFueSByZWRpcmVjdGlvbiBVUklzIHdlcmUgcmVnaXN0ZXJlZC4KICAgICAgICAg ICAgICBJZiB0aGUgY2xpZW50IHJlZ2lzdHJhdGlvbiBpbmNsdWRlZCB0aGUgZnVsbCByZWRpcmVj dGlvbiBVUkksIHRoZSBhdXRob3JpemF0aW9uCiAgICAgICAgICAgICAgc2VydmVyIE1VU1QgY29t cGFyZSB0aGUgdHdvIFVSSXMgdXNpbmcgc2ltcGxlIHN0cmluZyBjb21wYXJpc29uIGFzIGRlZmlu ZWQKICAgICAgICAgICAgICBpbiA8eHJlZiB0YXJnZXQ9J1JGQzM5ODYnIC8+IHNlY3Rpb24gNi4y LjEuCiAgICAgICAgICAgIDwvdD4KICAgICAgICAgPC9zZWN0aW9uPgoKICAgICAgICAgIDxzZWN0 aW9uIHRpdGxlPSdJbnZhbGlkIEVuZHBvaW50Jz4KICAgICAgICAgICAgPHQ+CiAgICAgICAgICAg ICAgSWYgYW4gYXV0aG9yaXphdGlvbiByZXF1ZXN0IGZhaWxzIHZhbGlkYXRpb24gZHVlIHRvIGEg bWlzc2luZywgaW52YWxpZCwgb3IKICAgICAgICAgICAgICBtaXNtYXRjaGluZyByZWRpcmVjdGlv biBVUkksIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBTSE9VTEQgaW5mb3JtIHRoZSByZXNvdXJj ZQogICAgICAgICAgICAgIG93bmVyIG9mIHRoZSBlcnJvciwgYW5kIE1VU1QgTk9UIGF1dG9tYXRp Y2FsbHkgcmVkaXJlY3QgdGhlIHVzZXItYWdlbnQgdG8gdGhlIGludmFsaWQKICAgICAgICAgICAg ICByZWRpcmVjdGlvbiBVUkkuCiAgICAgICAgICAgIDwvdD4KICAgICAgICAgIDwvc2VjdGlvbj4K CiAgICAgICAgICA8c2VjdGlvbiB0aXRsZT0nRW5kcG9pbnQgQ29udGVudCc+CiAgICAgICAgICAg IDx0PgogICAgICAgICAgICAgIFRoZSByZWRpcmVjdGlvbiByZXF1ZXN0IHRvIHRoZSBjbGllbnQn cyBlbmRwb2ludCB0eXBpY2FsbHkgcmVzdWx0cyBpbiBhbiBIVE1MCiAgICAgICAgICAgICAgZG9j dW1lbnQgcmVzcG9uc2UsIHByb2Nlc3NlZCBieSB0aGUgdXNlci1hZ2VudC4gSWYgdGhlIEhUTUwg cmVzcG9uc2UgaXMgc2VydmVkCiAgICAgICAgICAgICAgZGlyZWN0bHkgYXMgdGhlIHJlc3VsdCBv ZiB0aGUgcmVkaXJlY3Rpb24gcmVxdWVzdCwgYW55IHNjcmlwdCBpbmNsdWRlZCBpbiB0aGUgSFRN TAogICAgICAgICAgICAgIGRvY3VtZW50IHdpbGwgZXhlY3V0ZSB3aXRoIGZ1bGwgYWNjZXNzIHRv IHRoZSByZWRpcmVjdGlvbiBVUkkgYW5kIHRoZSBjcmVkZW50aWFscyBpdAogICAgICAgICAgICAg IGNvbnRhaW5zLgogICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgIDx0PgogICAgICAgICAgICAg IFRoZSBjbGllbnQgU0hPVUxEIE5PVCBpbmNsdWRlIGFueSB0aGlyZC1wYXJ0eSBzY3JpcHRzIChl LmcuIHRoaXJkLXBhcnR5IGFuYWx5dGljcywKICAgICAgICAgICAgICBzb2NpYWwgcGx1Zy1pbnMs IGFkIG5ldHdvcmtzKSBpbiB0aGUgcmVkaXJlY3Rpb24gZW5kcG9pbnQgcmVzcG9uc2UuIEluc3Rl YWQsIGl0CiAgICAgICAgICAgICAgU0hPVUxEIGV4dHJhY3QgdGhlIGNyZWRlbnRpYWxzIGZyb20g dGhlIFVSSSBhbmQgcmVkaXJlY3QgdGhlIHVzZXItYWdlbnQgYWdhaW4gdG8KICAgICAgICAgICAg ICBhbm90aGVyIGVuZHBvaW50IHdpdGhvdXQgZXhwb3NpbmcgdGhlIGNyZWRlbnRpYWxzIChpbiB0 aGUgVVJJIG9yIGVsc2V3aGVyZSkuIElmCiAgICAgICAgICAgICAgdGhpcmQtcGFydHkgc2NyaXB0 cyBhcmUgaW5jbHVkZWQsIHRoZSBjbGllbnQgTVVTVCBlbnN1cmUgdGhhdCBpdHMgb3duIHNjcmlw dHMKICAgICAgICAgICAgICAodXNlZCB0byBleHRyYWN0IGFuZCByZW1vdmUgdGhlIGNyZWRlbnRp YWxzIGZyb20gdGhlIFVSSSkgd2lsbCBleGVjdXRlIGZpcnN0LgogICAgICAgICAgICA8L3Q+CiAg ICAgICAgICA8L3NlY3Rpb24+CiAgICAgICAgICAKICAgICAgICA8L3NlY3Rpb24+CgogICAgICA8 L3NlY3Rpb24+CgogICAgICA8c2VjdGlvbiB0aXRsZT0nVG9rZW4gRW5kcG9pbnQnPgogICAgICAg IDx0PgogICAgICAgICAgVGhlIHRva2VuIGVuZHBvaW50IGlzIHVzZWQgYnkgdGhlIGNsaWVudCB0 byBvYnRhaW4gYW4gYWNjZXNzIHRva2VuIGJ5IHByZXNlbnRpbmcgaXRzCiAgICAgICAgICBhdXRo b3JpemF0aW9uIGdyYW50IG9yIHJlZnJlc2ggdG9rZW4uIFRoZSB0b2tlbiBlbmRwb2ludCBpcyB1 c2VkIHdpdGggZXZlcnkgYXV0aG9yaXphdGlvbgogICAgICAgICAgZ3JhbnQgZXhjZXB0IGZvciB0 aGUgaW1wbGljaXQgZ3JhbnQgdHlwZSAoc2luY2UgYW4gYWNjZXNzIHRva2VuIGlzIGlzc3VlZCBk aXJlY3RseSkuCiAgICAgICAgPC90PgogICAgICAgIDx0PgogICAgICAgICAgVGhlIG1lYW5zIHRo cm91Z2ggd2hpY2ggdGhlIGNsaWVudCBvYnRhaW5zIHRoZSBsb2NhdGlvbiBvZiB0aGUgdG9rZW4g ZW5kcG9pbnQgYXJlCiAgICAgICAgICBiZXlvbmQgdGhlIHNjb3BlIG9mIHRoaXMgc3BlY2lmaWNh dGlvbiBidXQgaXMgdHlwaWNhbGx5IHByb3ZpZGVkIGluIHRoZSBzZXJ2aWNlCiAgICAgICAgICBk b2N1bWVudGF0aW9uLgogICAgICAgIDwvdD4KICAgICAgICA8dD4KICAgICAgICAgIFRoZSBlbmRw b2ludCBVUkkgTUFZIGluY2x1ZGUgYW4KICAgICAgICAgIDxzcGFueCBzdHlsZT0ndmVyYic+YXBw bGljYXRpb24veC13d3ctZm9ybS11cmxlbmNvZGVkPC9zcGFueD4gZm9ybWF0dGVkCiAgICAgICAg ICAoPHhyZWYgdGFyZ2V0PSdXM0MuUkVDLWh0bWw0MDEtMTk5OTEyMjQnIC8+KSBxdWVyeSBjb21w b25lbnQgKDx4cmVmIHRhcmdldD0nUkZDMzk4NicgLz4KICAgICAgICAgIHNlY3Rpb24gMy40KSwg d2hpY2ggTVVTVCBiZSByZXRhaW5lZCB3aGVuIGFkZGluZyBhZGRpdGlvbmFsIHF1ZXJ5IHBhcmFt ZXRlcnMuIFRoZQogICAgICAgICAgZW5kcG9pbnQgVVJJIE1VU1QgTk9UIGluY2x1ZGUgYSBmcmFn bWVudCBjb21wb25lbnQuCiAgICAgICAgPC90PgogICAgICAgIDx0PgogICAgICAgICAgU2luY2Ug cmVxdWVzdHMgdG8gdGhlIHRva2VuIGVuZHBvaW50IHJlc3VsdCBpbiB0aGUgdHJhbnNtaXNzaW9u IG9mIGNsZWFyLXRleHQgY3JlZGVudGlhbHMKICAgICAgICAgIChpbiB0aGUgSFRUUCByZXF1ZXN0 IGFuZCByZXNwb25zZSksIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBNVVNUIHJlcXVpcmUgdGhl IHVzZSBvZiBUTFMKICAgICAgICAgIGFzIGRlc2NyaWJlZCBpbiA8eHJlZiB0YXJnZXQ9J3Rscycg Lz4gd2hlbiBzZW5kaW5nIHJlcXVlc3RzIHRvIHRoZSB0b2tlbiBlbmRwb2ludC4KICAgICAgICA8 L3Q+CiAgICAgICAgPHQ+CiAgICAgICAgICBUaGUgY2xpZW50IE1VU1QgdXNlIHRoZSBIVFRQIDxz cGFueCBzdHlsZT0ndmVyYic+UE9TVDwvc3Bhbng+IG1ldGhvZCB3aGVuIG1ha2luZyBhY2Nlc3MK ICAgICAgICAgIHRva2VuIHJlcXVlc3RzLgogICAgICAgIDwvdD4KICAgICAgICA8dD4KICAgICAg ICAgIFBhcmFtZXRlcnMgc2VudCB3aXRob3V0IGEgdmFsdWUgTVVTVCBiZSB0cmVhdGVkIGFzIGlm IHRoZXkgd2VyZSBvbWl0dGVkIGZyb20gdGhlIHJlcXVlc3QuCiAgICAgICAgICBUaGUgYXV0aG9y aXphdGlvbiBzZXJ2ZXIgTVVTVCBpZ25vcmUgdW5yZWNvZ25pemVkIHJlcXVlc3QgcGFyYW1ldGVy cy4gUmVxdWVzdCBhbmQKICAgICAgICAgIHJlc3BvbnNlIHBhcmFtZXRlcnMgTVVTVCBOT1QgYmUg aW5jbHVkZWQgbW9yZSB0aGFuIG9uY2UuCiAgICAgICAgPC90PgoKICAgICAgICA8c2VjdGlvbiB0 aXRsZT0nQ2xpZW50IEF1dGhlbnRpY2F0aW9uJyBhbmNob3I9J3Rva2VuLWVuZHBvaW50LWF1dGgn PgogICAgICAgICAgPHQ+CiAgICAgICAgICAgIENvbmZpZGVudGlhbCBjbGllbnRzIG9yIG90aGVy IGNsaWVudHMgaXNzdWVkIGNsaWVudCBjcmVkZW50aWFscyBNVVNUIGF1dGhlbnRpY2F0ZSB3aXRo CiAgICAgICAgICAgIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBhcyBkZXNjcmliZWQgaW4gPHhy ZWYgdGFyZ2V0PSdjbGllbnQtYXV0aGVudGljYXRpb24nIC8+IHdoZW4KICAgICAgICAgICAgbWFr aW5nIHJlcXVlc3RzIHRvIHRoZSB0b2tlbiBlbmRwb2ludC4gQ2xpZW50IGF1dGhlbnRpY2F0aW9u IGlzIHVzZWQgZm9yOgogICAgICAgICAgPC90PgogICAgICAgICAgPHQ+CiAgICAgICAgICAgIDxs aXN0IHN0eWxlPSdzeW1ib2xzJz4KICAgICAgICAgICAgICA8dD4KICAgICAgICAgICAgICAgIEVu Zm9yY2luZyB0aGUgYmluZGluZyBvZiByZWZyZXNoIHRva2VucyBhbmQgYXV0aG9yaXphdGlvbiBj b2RlcyB0byB0aGUgY2xpZW50IHRoZXkKICAgICAgICAgICAgICAgIHdlcmUgaXNzdWVkIHRvLiBD bGllbnQgYXV0aGVudGljYXRpb24gaXMgY3JpdGljYWwgd2hlbiBhbiBhdXRob3JpemF0aW9uIGNv ZGUgaXMKICAgICAgICAgICAgICAgIHRyYW5zbWl0dGVkIHRvIHRoZSByZWRpcmVjdGlvbiBlbmRw b2ludCBvdmVyIGFuIGluc2VjdXJlIGNoYW5uZWwsIG9yIHdoZW4gdGhlCiAgICAgICAgICAgICAg ICByZWRpcmVjdGlvbiBVUkkgaGFzIG5vdCBiZWVuIHJlZ2lzdGVyZWQgaW4gZnVsbC4KICAgICAg ICAgICAgICA8L3Q+CiAgICAgICAgICAgICAgPHQ+CiAgICAgICAgICAgICAgICBSZWNvdmVyaW5n IGZyb20gYSBjb21wcm9taXNlZCBjbGllbnQgYnkgZGlzYWJsaW5nIHRoZSBjbGllbnQgb3IgY2hh bmdpbmcgaXRzCiAgICAgICAgICAgICAgICBjcmVkZW50aWFscywgdGh1cyBwcmV2ZW50aW5nIGFu IGF0dGFja2VyIGZyb20gYWJ1c2luZyBzdG9sZW4gcmVmcmVzaCB0b2tlbnMuIENoYW5naW5nCiAg ICAgICAgICAgICAgICBhIHNpbmdsZSBzZXQgb2YgY2xpZW50IGNyZWRlbnRpYWxzIGlzIHNpZ25p ZmljYW50bHkgZmFzdGVyIHRoYW4gcmV2b2tpbmcgYW4gZW50aXJlCiAgICAgICAgICAgICAgICBz ZXQgb2YgcmVmcmVzaCB0b2tlbnMuCiAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICAgIDx0 PgogICAgICAgICAgICAgICAgSW1wbGVtZW50aW5nIGF1dGhlbnRpY2F0aW9uIG1hbmFnZW1lbnQg YmVzdCBwcmFjdGljZXMgd2hpY2ggcmVxdWlyZSBwZXJpb2RpYwogICAgICAgICAgICAgICAgY3Jl ZGVudGlhbCByb3RhdGlvbi4gUm90YXRpb24gb2YgYW4gZW50aXJlIHNldCBvZiByZWZyZXNoIHRv a2VucyBjYW4gYmUKICAgICAgICAgICAgICAgIGNoYWxsZW5naW5nLCB3aGlsZSByb3RhdGlvbiBv ZiBhIHNpbmdsZSBzZXQgb2YgY2xpZW50IGNyZWRlbnRpYWxzIGlzIHNpZ25pZmljYW50bHkKICAg ICAgICAgICAgICAgIGVhc2llci4KICAgICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgIDwvbGlz dD4KICAgICAgICAgIDwvdD4KICAgICAgICAgIDx0PgogICAgICAgICAgICBBIHB1YmxpYyBjbGll bnQgdGhhdCB3YXMgbm90IGlzc3VlZCBhIGNsaWVudCBwYXNzd29yZCBNQVkgdXNlIHRoZQogICAg ICAgICAgICA8c3Bhbnggc3R5bGU9J3ZlcmInPmNsaWVudF9pZDwvc3Bhbng+IHJlcXVlc3QgcGFy YW1ldGVyIHRvIGlkZW50aWZ5IGl0c2VsZiB3aGVuIHNlbmRpbmcKICAgICAgICAgICAgcmVxdWVz dHMgdG8gdGhlIHRva2VuIGVuZHBvaW50IChlLmcuIGZvciB0aGUgcHVycG9zZSBvZiBwcm92aWRp bmcgZW5kLXVzZXIgY29udGV4dCwKICAgICAgICAgICAgY2xpZW50IHVzYWdlIHN0YXRpc3RpY3Mp LgogICAgICAgICAgPC90PgogICAgICAgIDwvc2VjdGlvbj4KCiAgICAgIDwvc2VjdGlvbj4KCiAg ICAgIDxzZWN0aW9uIHRpdGxlPSdBY2Nlc3MgVG9rZW4gU2NvcGUnIGFuY2hvcj0nc2NvcGUnPgog ICAgICAgIDx0PgogICAgICAgICAgVGhlIGF1dGhvcml6YXRpb24gYW5kIHRva2VuIGVuZHBvaW50 cyBhbGxvdyB0aGUgY2xpZW50IHRvIHNwZWNpZnkgdGhlIHNjb3BlIG9mIHRoZSBhY2Nlc3MKICAg ICAgICAgIHJlcXVlc3QgdXNpbmcgdGhlIDxzcGFueCBzdHlsZT0ndmVyYic+c2NvcGU8L3NwYW54 PiByZXF1ZXN0IHBhcmFtZXRlci4gSW4gdHVybiwgdGhlCiAgICAgICAgICBhdXRob3JpemF0aW9u IHNlcnZlciB1c2VzIHRoZSA8c3Bhbnggc3R5bGU9J3ZlcmInPnNjb3BlPC9zcGFueD4gcmVzcG9u c2UgcGFyYW1ldGVyIHRvCiAgICAgICAgICBpbmZvcm0gdGhlIGNsaWVudCBvZiB0aGUgc2NvcGUg b2YgdGhlIGFjY2VzcyB0b2tlbiBpc3N1ZWQuCiAgICAgICAgPC90PgogICAgICAgIDx0PgogICAg ICAgICAgVGhlIHZhbHVlIG9mIHRoZSBzY29wZSBwYXJhbWV0ZXIgaXMgZXhwcmVzc2VkIGFzIGEg bGlzdCBvZiBzcGFjZS1kZWxpbWl0ZWQsIGNhc2UKICAgICAgICAgIHNlbnNpdGl2ZSBzdHJpbmdz LiBUaGUgc3RyaW5ncyBhcmUgZGVmaW5lZCBieSB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIuIElm IHRoZSB2YWx1ZQogICAgICAgICAgY29udGFpbnMgbXVsdGlwbGUgc3BhY2UtZGVsaW1pdGVkIHN0 cmluZ3MsIHRoZWlyIG9yZGVyIGRvZXMgbm90IG1hdHRlciwgYW5kIGVhY2ggc3RyaW5nCiAgICAg ICAgICBhZGRzIGFuIGFkZGl0aW9uYWwgYWNjZXNzIHJhbmdlIHRvIHRoZSByZXF1ZXN0ZWQgc2Nv cGUuCiAgICAgICAgPC90PgogICAgICAgIDxmaWd1cmU+CiAgICAgICAgICA8YXJ0d29yaz4KICAg ICAgICAgICAgPCFbQ0RBVEFbCiAgc2NvcGUgICAgICAgPSBzY29wZS10b2tlbiAqKCBTUCBzY29w ZS10b2tlbiApCiAgc2NvcGUtdG9rZW4gPSAxKiggJXgyMSAvICV4MjMtNUIgLyAleDVELTdFICkK XV0+CiAgICAgICAgICA8L2FydHdvcms+CiAgICAgICAgPC9maWd1cmU+CiAgICAgICAgPHQ+CiAg ICAgICAgICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTUFZIGZ1bGx5IG9yIHBhcnRpYWxseSBp Z25vcmUgdGhlIHNjb3BlIHJlcXVlc3RlZCBieSB0aGUgY2xpZW50CiAgICAgICAgICBiYXNlZCBv biB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgcG9saWN5IG9yIHRoZSByZXNvdXJjZSBvd25lcidz IGluc3RydWN0aW9ucy4gSWYgdGhlCiAgICAgICAgICBpc3N1ZWQgYWNjZXNzIHRva2VuIHNjb3Bl IGlzIGRpZmZlcmVudCBmcm9tIHRoZSBvbmUgcmVxdWVzdGVkIGJ5IHRoZSBjbGllbnQsIHRoZQog ICAgICAgICAgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVTVCBpbmNsdWRlIHRoZSA8c3Bhbnggc3R5 bGU9J3ZlcmInPnNjb3BlPC9zcGFueD4gcmVzcG9uc2UKICAgICAgICAgIHBhcmFtZXRlciB0byBp bmZvcm0gdGhlIGNsaWVudCBvZiB0aGUgYWN0dWFsIHNjb3BlIGdyYW50ZWQuCiAgICAgICAgPC90 PgogICAgICAgIDx0PgogICAgICAgICAgSWYgdGhlIGNsaWVudCBvbWl0cyB0aGUgc2NvcGUgcGFy YW1ldGVyIHdoZW4gcmVxdWVzdGluZyBhdXRob3JpemF0aW9uLCB0aGUgYXV0aG9yaXphdGlvbgog ICAgICAgICAgc2VydmVyIE1VU1QgZWl0aGVyIHByb2Nlc3MgdGhlIHJlcXVlc3QgdXNpbmcgYSBw cmUtZGVmaW5lZCBkZWZhdWx0IHZhbHVlLCBvciBmYWlsIHRoZQogICAgICAgICAgcmVxdWVzdCBp bmRpY2F0aW5nIGFuIGludmFsaWQgc2NvcGUuIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBTSE9V TEQgZG9jdW1lbnQgaXRzIHNjb3BlCiAgICAgICAgICByZXF1aXJlbWVudHMgYW5kIGRlZmF1bHQg dmFsdWUgKGlmIGRlZmluZWQpLgogICAgICAgIDwvdD4KICAgICAgPC9zZWN0aW9uPgoKICAgIDwv c2VjdGlvbj4KCiAgICA8c2VjdGlvbiB0aXRsZT0nT2J0YWluaW5nIEF1dGhvcml6YXRpb24nPgog ICAgICA8dD4KICAgICAgICBUbyByZXF1ZXN0IGFuIGFjY2VzcyB0b2tlbiwgdGhlIGNsaWVudCBv YnRhaW5zIGF1dGhvcml6YXRpb24gZnJvbSB0aGUgcmVzb3VyY2Ugb3duZXIuIFRoZQogICAgICAg IGF1dGhvcml6YXRpb24gaXMgZXhwcmVzc2VkIGluIHRoZSBmb3JtIG9mIGFuIGF1dGhvcml6YXRp b24gZ3JhbnQgd2hpY2ggdGhlIGNsaWVudCB1c2VzIHRvCiAgICAgICAgcmVxdWVzdCB0aGUgYWNj ZXNzIHRva2VuLiBPQXV0aCBkZWZpbmVzIGZvdXIgZ3JhbnQgdHlwZXM6IGF1dGhvcml6YXRpb24g Y29kZSwgaW1wbGljaXQsCiAgICAgICAgcmVzb3VyY2Ugb3duZXIgcGFzc3dvcmQgY3JlZGVudGlh bHMsIGFuZCBjbGllbnQgY3JlZGVudGlhbHMuIEl0IGFsc28gcHJvdmlkZXMgYW4gZXh0ZW5zaW9u CiAgICAgICAgbWVjaGFuaXNtIGZvciBkZWZpbmluZyBhZGRpdGlvbmFsIGdyYW50IHR5cGVzLgog ICAgICA8L3Q+CgogICAgICA8c2VjdGlvbiB0aXRsZT0nQXV0aG9yaXphdGlvbiBDb2RlIEdyYW50 JyBhbmNob3I9J2dyYW50LWNvZGUnPgogICAgICAgIDx0PgogICAgICAgICAgVGhlIGF1dGhvcml6 YXRpb24gY29kZSBncmFudCB0eXBlIGlzIHVzZWQgdG8gb2J0YWluIGJvdGggYWNjZXNzIHRva2Vu cyBhbmQgcmVmcmVzaAogICAgICAgICAgdG9rZW5zIGFuZCBpcyBvcHRpbWl6ZWQgZm9yIGNvbmZp ZGVudGlhbCBjbGllbnRzLiBBcyBhIHJlZGlyZWN0aW9uLWJhc2VkIGZsb3csIHRoZSBjbGllbnQK ICAgICAgICAgIG11c3QgYmUgY2FwYWJsZSBvZiBpbnRlcmFjdGluZyB3aXRoIHRoZSByZXNvdXJj ZSBvd25lcidzIHVzZXItYWdlbnQgKHR5cGljYWxseSBhIHdlYgogICAgICAgICAgYnJvd3Nlcikg YW5kIGNhcGFibGUgb2YgcmVjZWl2aW5nIGluY29taW5nIHJlcXVlc3RzICh2aWEgcmVkaXJlY3Rp b24pIGZyb20gdGhlCiAgICAgICAgICBhdXRob3JpemF0aW9uIHNlcnZlci4KICAgICAgICA8L3Q+ CiAgICAgICAgPGZpZ3VyZSB0aXRsZT0nQXV0aG9yaXphdGlvbiBDb2RlIEZsb3cnIGFuY2hvcj0n RmlndXJlLTMnPgogICAgICAgICAgPGFydHdvcms+CiAgICAgICAgICAgIDwhW0NEQVRBWwogICst LS0tLS0tLS0tKwogIHwgcmVzb3VyY2UgfAogIHwgICBvd25lciAgfAogIHwgICAgICAgICAgfAog ICstLS0tLS0tLS0tKwogICAgICAgXgogICAgICAgfAogICAgICAoQikgICAgICAKICArLS0tLXwt LS0tLSsgICAgICAgICAgQ2xpZW50IElkZW50aWZpZXIgICAgICArLS0tLS0tLS0tLS0tLS0tKwog IHwgICAgICAgICAtKy0tLS0oQSktLSAmIFJlZGlyZWN0aW9uIFVSSSAtLS0tPnwgICAgICAgICAg ICAgICB8CiAgfCAgVXNlci0gICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCBB dXRob3JpemF0aW9uIHwKICB8ICBBZ2VudCAgLSstLS0tKEIpLS0gVXNlciBhdXRoZW50aWNhdGVz IC0tLT58ICAgICBTZXJ2ZXIgICAgfAogIHwgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHwgICAgICAgICAgICAgICB8CiAgfCAgICAgICAgIC0rLS0tLShDKS0tIEF1 dGhvcml6YXRpb24gQ29kZSAtLS08fCAgICAgICAgICAgICAgIHwKICArLXwtLS0tfC0tLSsgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tKwogICAgfCAgICB8 ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBeICAgICAgdgogICAoQSkg IChDKSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgfAogICAg fCAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgfAog ICAgXiAgICB2ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAg fAogICstLS0tLS0tLS0rICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAg ICAgfAogIHwgICAgICAgICB8Pi0tLShEKS0tIEF1dGhvcml6YXRpb24gQ29kZSAtLS0tLS0tLS0n ICAgICAgfAogIHwgIENsaWVudCB8ICAgICAgICAgICYgUmVkaXJlY3Rpb24gVVJJICAgICAgICAg ICAgICAgICAgfAogIHwgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgfAogIHwgICAgICAgICB8PC0tLShFKS0tLS0tIEFjY2VzcyBUb2tlbiAtLS0t LS0tLS0tLS0tLS0tLS0tJwogICstLS0tLS0tLS0rICAgICAgICh3LyBPcHRpb25hbCBSZWZyZXNo IFRva2VuKQpdXT4KICAgICAgICAgIDwvYXJ0d29yaz4KICAgICAgICAgIDxwb3N0YW1ibGU+CiAg ICAgICAgICAgIE5vdGU6IFRoZSBsaW5lcyBpbGx1c3RyYXRpbmcgc3RlcHMgQSwgQiwgYW5kIEMg YXJlIGJyb2tlbiBpbnRvIHR3byBwYXJ0cyBhcyB0aGV5IHBhc3MKICAgICAgICAgICAgdGhyb3Vn aCB0aGUgdXNlci1hZ2VudC4KICAgICAgICAgIDwvcG9zdGFtYmxlPgogICAgICAgIDwvZmlndXJl PgogICAgICAgIDx0PgogICAgICAgICAgVGhlIGZsb3cgaWxsdXN0cmF0ZWQgaW4gPHhyZWYgdGFy Z2V0PSdGaWd1cmUtMycgLz4gaW5jbHVkZXMgdGhlIGZvbGxvd2luZyBzdGVwczoKICAgICAgICA8 L3Q+CiAgICAgICAgPHQ+CiAgICAgICAgICA8bGlzdCBzdHlsZT0nZm9ybWF0ICglQyknPgogICAg ICAgICAgICA8dD4KICAgICAgICAgICAgICBUaGUgY2xpZW50IGluaXRpYXRlcyB0aGUgZmxvdyBi eSBkaXJlY3RpbmcgdGhlIHJlc291cmNlIG93bmVyJ3MgdXNlci1hZ2VudCB0byB0aGUKICAgICAg ICAgICAgICBhdXRob3JpemF0aW9uIGVuZHBvaW50LiBUaGUgY2xpZW50IGluY2x1ZGVzIGl0cyBj bGllbnQgaWRlbnRpZmllciwgcmVxdWVzdGVkCiAgICAgICAgICAgICAgc2NvcGUsIGxvY2FsIHN0 YXRlLCBhbmQgYSByZWRpcmVjdGlvbiBVUkkgdG8gd2hpY2ggdGhlIGF1dGhvcml6YXRpb24gc2Vy dmVyIHdpbGwgc2VuZAogICAgICAgICAgICAgIHRoZSB1c2VyLWFnZW50IGJhY2sgb25jZSBhY2Nl c3MgaXMgZ3JhbnRlZCAob3IgZGVuaWVkKS4KICAgICAgICAgICAgPC90PgogICAgICAgICAgICA8 dD4KICAgICAgICAgICAgICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYXV0aGVudGljYXRlcyB0 aGUgcmVzb3VyY2Ugb3duZXIgKHZpYSB0aGUgdXNlci1hZ2VudCkgYW5kCiAgICAgICAgICAgICAg ZXN0YWJsaXNoZXMgd2hldGhlciB0aGUgcmVzb3VyY2Ugb3duZXIgZ3JhbnRzIG9yIGRlbmllcyB0 aGUgY2xpZW50J3MgYWNjZXNzIHJlcXVlc3QuCiAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAg PHQ+CiAgICAgICAgICAgICAgQXNzdW1pbmcgdGhlIHJlc291cmNlIG93bmVyIGdyYW50cyBhY2Nl c3MsIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciByZWRpcmVjdHMgdGhlCiAgICAgICAgICAgICAg dXNlci1hZ2VudCBiYWNrIHRvIHRoZSBjbGllbnQgdXNpbmcgdGhlIHJlZGlyZWN0aW9uIFVSSSBw cm92aWRlZCBlYXJsaWVyIChpbiB0aGUKICAgICAgICAgICAgICByZXF1ZXN0IG9yIGR1cmluZyBj bGllbnQgcmVnaXN0cmF0aW9uKS4gVGhlIHJlZGlyZWN0aW9uIFVSSSBpbmNsdWRlcyBhbiBhdXRo b3JpemF0aW9uCiAgICAgICAgICAgICAgY29kZSBhbmQgYW55IGxvY2FsIHN0YXRlIHByb3ZpZGVk IGJ5IHRoZSBjbGllbnQgZWFybGllci4KICAgICAgICAgICAgPC90PgogICAgICAgICAgICA8dD4K ICAgICAgICAgICAgICBUaGUgY2xpZW50IHJlcXVlc3RzIGFuIGFjY2VzcyB0b2tlbiBmcm9tIHRo ZSBhdXRob3JpemF0aW9uIHNlcnZlcidzIHRva2VuIGVuZHBvaW50CiAgICAgICAgICAgICAgYnkg aW5jbHVkaW5nIHRoZSBhdXRob3JpemF0aW9uIGNvZGUgcmVjZWl2ZWQgaW4gdGhlIHByZXZpb3Vz IHN0ZXAuIFdoZW4gbWFraW5nIHRoZQogICAgICAgICAgICAgIHJlcXVlc3QsIHRoZSBjbGllbnQg YXV0aGVudGljYXRlcyB3aXRoIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlci4gVGhlIGNsaWVudCBp bmNsdWRlcwogICAgICAgICAgICAgIHRoZSByZWRpcmVjdGlvbiBVUkkgdXNlZCB0byBvYnRhaW4g dGhlIGF1dGhvcml6YXRpb24gY29kZSBmb3IgdmVyaWZpY2F0aW9uLgogICAgICAgICAgICA8L3Q+ CiAgICAgICAgICAgIDx0PgogICAgICAgICAgICAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBh dXRoZW50aWNhdGVzIHRoZSBjbGllbnQsIHZhbGlkYXRlcyB0aGUgYXV0aG9yaXphdGlvbiBjb2Rl LAogICAgICAgICAgICAgIGFuZCBlbnN1cmVzIHRoZSByZWRpcmVjdGlvbiBVUkkgcmVjZWl2ZWQg bWF0Y2hlcyB0aGUgVVJJIHVzZWQgdG8gcmVkaXJlY3QgdGhlIGNsaWVudAogICAgICAgICAgICAg IGluIHN0ZXAgKEMpLiBJZiB2YWxpZCwgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHJlc3BvbmRz IGJhY2sgd2l0aCBhbiBhY2Nlc3MgdG9rZW4KICAgICAgICAgICAgICBhbmQgb3B0aW9uYWxseSwg YSByZWZyZXNoIHRva2VuLgogICAgICAgICAgICA8L3Q+CiAgICAgICAgICA8L2xpc3Q+CiAgICAg ICAgPC90PgoKICAgICAgICA8c2VjdGlvbiB0aXRsZT0nQXV0aG9yaXphdGlvbiBSZXF1ZXN0JyBh bmNob3I9J2NvZGUtYXV0aHotcmVxJz4KICAgICAgICAgIDx0PgogICAgICAgICAgICBUaGUgY2xp ZW50IGNvbnN0cnVjdHMgdGhlIHJlcXVlc3QgVVJJIGJ5IGFkZGluZyB0aGUgZm9sbG93aW5nIHBh cmFtZXRlcnMgdG8gdGhlCiAgICAgICAgICAgIHF1ZXJ5IGNvbXBvbmVudCBvZiB0aGUgYXV0aG9y aXphdGlvbiBlbmRwb2ludCBVUkkgdXNpbmcgdGhlCiAgICAgICAgICAgIDxzcGFueCBzdHlsZT0n dmVyYic+YXBwbGljYXRpb24veC13d3ctZm9ybS11cmxlbmNvZGVkPC9zcGFueD4gZm9ybWF0IGFz IGRlZmluZWQgYnkKICAgICAgICAgICAgPHhyZWYgdGFyZ2V0PSdXM0MuUkVDLWh0bWw0MDEtMTk5 OTEyMjQnIC8+OgogICAgICAgICAgPC90PgogICAgICAgICAgPHQ+CiAgICAgICAgICAgIDxsaXN0 IHN0eWxlPSdoYW5naW5nJyBoYW5nSW5kZW50PSc2Jz4KICAgICAgICAgICAgICA8dCBoYW5nVGV4 dD0ncmVzcG9uc2VfdHlwZSc+CiAgICAgICAgICAgICAgICA8dnNwYWNlIC8+CiAgICAgICAgICAg ICAgICBSRVFVSVJFRC4gVmFsdWUgTVVTVCBiZSBzZXQgdG8gPHNwYW54IHN0eWxlPSd2ZXJiJz5j b2RlPC9zcGFueD4uCiAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICAgIDx0IGhhbmdUZXh0 PSdjbGllbnRfaWQnPgogICAgICAgICAgICAgICAgPHZzcGFjZSAvPgogICAgICAgICAgICAgICAg UkVRVUlSRUQuIFRoZSBjbGllbnQgaWRlbnRpZmllciBhcyBkZXNjcmliZWQgaW4KICAgICAgICAg ICAgICAgIDx4cmVmIHRhcmdldD0nY2xpZW50LWlkZW50aWZpZXInIC8+LgogICAgICAgICAgICAg IDwvdD4KICAgICAgICAgICAgICA8dCBoYW5nVGV4dD0ncmVkaXJlY3RfdXJpJz4KICAgICAgICAg ICAgICAgIDx2c3BhY2UgLz4KICAgICAgICAgICAgICAgIE9QVElPTkFMLiBBcyBkZXNjcmliZWQg aW4gPHhyZWYgdGFyZ2V0PSdyZWRpcmVjdC11cmknIC8+LgogICAgICAgICAgICAgIDwvdD4KICAg ICAgICAgICAgICA8dCBoYW5nVGV4dD0nc2NvcGUnPgogICAgICAgICAgICAgICAgPHZzcGFjZSAv PgogICAgICAgICAgICAgICAgT1BUSU9OQUwuIFRoZSBzY29wZSBvZiB0aGUgYWNjZXNzIHJlcXVl c3QgYXMgZGVzY3JpYmVkIGJ5IDx4cmVmIHRhcmdldD0nc2NvcGUnIC8+LgogICAgICAgICAgICAg IDwvdD4KICAgICAgICAgICAgICA8dCBoYW5nVGV4dD0nc3RhdGUnPgogICAgICAgICAgICAgICAg PHZzcGFjZSAvPgogICAgICAgICAgICAgICAgUkVDT01NRU5ERUQuIEFuIG9wYXF1ZSB2YWx1ZSB1 c2VkIGJ5IHRoZSBjbGllbnQgdG8gbWFpbnRhaW4gc3RhdGUgYmV0d2VlbiB0aGUgcmVxdWVzdAog ICAgICAgICAgICAgICAgYW5kIGNhbGxiYWNrLiBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgaW5j bHVkZXMgdGhpcyB2YWx1ZSB3aGVuIHJlZGlyZWN0aW5nIHRoZQogICAgICAgICAgICAgICAgdXNl ci1hZ2VudCBiYWNrIHRvIHRoZSBjbGllbnQuIFRoZSBwYXJhbWV0ZXIgU0hPVUxEIGJlIHVzZWQg Zm9yIHByZXZlbnRpbmcKICAgICAgICAgICAgICAgIGNyb3NzLXNpdGUgcmVxdWVzdCBmb3JnZXJ5 IGFzIGRlc2NyaWJlZCBpbiA8eHJlZiB0YXJnZXQ9J0NTUkYnIC8+LgogICAgICAgICAgICAgIDwv dD4KICAgICAgICAgICAgPC9saXN0PgogICAgICAgICAgPC90PgogICAgICAgICAgPHQ+CiAgICAg ICAgICAgIFRoZSBjbGllbnQgZGlyZWN0cyB0aGUgcmVzb3VyY2Ugb3duZXIgdG8gdGhlIGNvbnN0 cnVjdGVkIFVSSSB1c2luZyBhbiBIVFRQIHJlZGlyZWN0aW9uCiAgICAgICAgICAgIHJlc3BvbnNl LCBvciBieSBvdGhlciBtZWFucyBhdmFpbGFibGUgdG8gaXQgdmlhIHRoZSB1c2VyLWFnZW50Lgog ICAgICAgICAgPC90PgogICAgICAgICAgPGZpZ3VyZT4KICAgICAgICAgICAgPHByZWFtYmxlPgog ICAgICAgICAgICAgIEZvciBleGFtcGxlLCB0aGUgY2xpZW50IGRpcmVjdHMgdGhlIHVzZXItYWdl bnQgdG8gbWFrZSB0aGUgZm9sbG93aW5nIEhUVFAgcmVxdWVzdAogICAgICAgICAgICAgIHVzaW5n IFRMUyAoZXh0cmEgbGluZSBicmVha3MgYXJlIGZvciBkaXNwbGF5IHB1cnBvc2VzIG9ubHkpOgog ICAgICAgICAgICA8L3ByZWFtYmxlPgogICAgICAgICAgICA8YXJ0d29yaz4KICAgICAgICAgICAg ICA8IVtDREFUQVsKICBHRVQgL2F1dGhvcml6ZT9yZXNwb25zZV90eXBlPWNvZGUmY2xpZW50X2lk PXM2QmhkUmtxdDMmc3RhdGU9eHl6CiAgICAgICZyZWRpcmVjdF91cmk9aHR0cHMlM0ElMkYlMkZj bGllbnQlMkVleGFtcGxlJTJFY29tJTJGY2IgSFRUUC8xLjEKICBIb3N0OiBzZXJ2ZXIuZXhhbXBs ZS5jb20KXV0+CiAgICAgICAgICAgIDwvYXJ0d29yaz4KICAgICAgICAgIDwvZmlndXJlPgogICAg ICAgICAgPHQ+CiAgICAgICAgICAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciB2YWxpZGF0ZXMg dGhlIHJlcXVlc3QgdG8gZW5zdXJlIGFsbCByZXF1aXJlZCBwYXJhbWV0ZXJzIGFyZQogICAgICAg ICAgICBwcmVzZW50IGFuZCB2YWxpZC4gSWYgdGhlIHJlcXVlc3QgaXMgdmFsaWQsIHRoZSBhdXRo b3JpemF0aW9uIHNlcnZlciBhdXRoZW50aWNhdGVzIHRoZQogICAgICAgICAgICByZXNvdXJjZSBv d25lciBhbmQgb2J0YWlucyBhbiBhdXRob3JpemF0aW9uIGRlY2lzaW9uIChieSBhc2tpbmcgdGhl IHJlc291cmNlIG93bmVyIG9yCiAgICAgICAgICAgIGJ5IGVzdGFibGlzaGluZyBhcHByb3ZhbCB2 aWEgb3RoZXIgbWVhbnMpLgogICAgICAgICAgPC90PgogICAgICAgICAgPHQ+CiAgICAgICAgICAg IFdoZW4gYSBkZWNpc2lvbiBpcyBlc3RhYmxpc2hlZCwgdGhlIGF1dGhvcml6YXRpb24gc2VydmVy IGRpcmVjdHMgdGhlIHVzZXItYWdlbnQgdG8gdGhlCiAgICAgICAgICAgIHByb3ZpZGVkIGNsaWVu dCByZWRpcmVjdGlvbiBVUkkgdXNpbmcgYW4gSFRUUCByZWRpcmVjdGlvbiByZXNwb25zZSwgb3Ig Ynkgb3RoZXIgbWVhbnMKICAgICAgICAgICAgYXZhaWxhYmxlIHRvIGl0IHZpYSB0aGUgdXNlci1h Z2VudC4KICAgICAgICAgIDwvdD4KICAgICAgICA8L3NlY3Rpb24+CgogICAgICAgIDxzZWN0aW9u IHRpdGxlPSdBdXRob3JpemF0aW9uIFJlc3BvbnNlJyBhbmNob3I9ImNvZGUtYXV0aHotcmVzcCI+ CiAgICAgICAgICA8dD4KICAgICAgICAgICAgSWYgdGhlIHJlc291cmNlIG93bmVyIGdyYW50cyB0 aGUgYWNjZXNzIHJlcXVlc3QsIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBpc3N1ZXMgYW4KICAg ICAgICAgICAgYXV0aG9yaXphdGlvbiBjb2RlIGFuZCBkZWxpdmVycyBpdCB0byB0aGUgY2xpZW50 IGJ5IGFkZGluZyB0aGUgZm9sbG93aW5nIHBhcmFtZXRlcnMgdG8KICAgICAgICAgICAgdGhlIHF1 ZXJ5IGNvbXBvbmVudCBvZiB0aGUgcmVkaXJlY3Rpb24gVVJJIHVzaW5nIHRoZQogICAgICAgICAg ICA8c3Bhbnggc3R5bGU9J3ZlcmInPmFwcGxpY2F0aW9uL3gtd3d3LWZvcm0tdXJsZW5jb2RlZDwv c3Bhbng+IGZvcm1hdDoKICAgICAgICAgIDwvdD4KICAgICAgICAgIDx0PgogICAgICAgICAgICA8 bGlzdCBzdHlsZT0naGFuZ2luZycgaGFuZ0luZGVudD0nNic+CiAgICAgICAgICAgICAgPHQgaGFu Z1RleHQ9J2NvZGUnPgogICAgICAgICAgICAgICAgPHZzcGFjZSAvPgogICAgICAgICAgICAgICAg UkVRVUlSRUQuIFRoZSBhdXRob3JpemF0aW9uIGNvZGUgZ2VuZXJhdGVkIGJ5IHRoZSBhdXRob3Jp emF0aW9uIHNlcnZlci4gVGhlCiAgICAgICAgICAgICAgICBhdXRob3JpemF0aW9uIGNvZGUgTVVT VCBleHBpcmUgc2hvcnRseSBhZnRlciBpdCBpcyBpc3N1ZWQgdG8gbWl0aWdhdGUgdGhlIHJpc2sg b2YKICAgICAgICAgICAgICAgIGxlYWtzLiBBIG1heGltdW0gYXV0aG9yaXphdGlvbiBjb2RlIGxp ZmV0aW1lIG9mIDEwIG1pbnV0ZXMgaXMgUkVDT01NRU5ERUQuIFRoZQogICAgICAgICAgICAgICAg Y2xpZW50IE1VU1QgTk9UIHVzZSB0aGUgYXV0aG9yaXphdGlvbiBjb2RlIG1vcmUgdGhhbiBvbmNl LiBJZiBhbiBhdXRob3JpemF0aW9uIGNvZGUKICAgICAgICAgICAgICAgIGlzIHVzZWQgbW9yZSB0 aGFuIG9uY2UsIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBNVVNUIGRlbnkgdGhlIHJlcXVlc3Qg YW5kIFNIT1VMRAogICAgICAgICAgICAgICAgcmV2b2tlICh3aGVuIHBvc3NpYmxlKSBhbGwgdG9r ZW5zIHByZXZpb3VzbHkgaXNzdWVkIGJhc2VkIG9uIHRoYXQgYXV0aG9yaXphdGlvbgogICAgICAg ICAgICAgICAgY29kZS4gVGhlIGF1dGhvcml6YXRpb24gY29kZSBpcyBib3VuZCB0byB0aGUgY2xp ZW50IGlkZW50aWZpZXIgYW5kIHJlZGlyZWN0aW9uIFVSSS4KICAgICAgICAgICAgICA8L3Q+CiAg ICAgICAgICAgICAgPHQgaGFuZ1RleHQ9J3N0YXRlJz4KICAgICAgICAgICAgICAgIDx2c3BhY2Ug Lz4KICAgICAgICAgICAgICAgIFJFUVVJUkVEIGlmIHRoZSA8c3Bhbnggc3R5bGU9J3ZlcmInPnN0 YXRlPC9zcGFueD4gcGFyYW1ldGVyIHdhcyBwcmVzZW50IGluIHRoZQogICAgICAgICAgICAgICAg Y2xpZW50IGF1dGhvcml6YXRpb24gcmVxdWVzdC4gVGhlIGV4YWN0IHZhbHVlIHJlY2VpdmVkIGZy b20gdGhlIGNsaWVudC4KICAgICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgIDwvbGlzdD4KICAg ICAgICAgIDwvdD4KICAgICAgICAgIDxmaWd1cmU+CiAgICAgICAgICAgIDxwcmVhbWJsZT4KICAg ICAgICAgICAgICBGb3IgZXhhbXBsZSwgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHJlZGlyZWN0 cyB0aGUgdXNlci1hZ2VudCBieSBzZW5kaW5nIHRoZQogICAgICAgICAgICAgIGZvbGxvd2luZyBI VFRQIHJlc3BvbnNlOgogICAgICAgICAgICA8L3ByZWFtYmxlPgogICAgICAgICAgICA8YXJ0d29y az4KICAgICAgICAgICAgICA8IVtDREFUQVsKICBIVFRQLzEuMSAzMDIgRm91bmQKICBMb2NhdGlv bjogaHR0cHM6Ly9jbGllbnQuZXhhbXBsZS5jb20vY2I/Y29kZT1TcGx4bE9CZVpRUVliWVM2V3hT YklBCiAgICAgICAgICAgICZzdGF0ZT14eXoKXV0+CiAgICAgICAgICAgIDwvYXJ0d29yaz4KICAg ICAgICAgIDwvZmlndXJlPgogICAgICAgICAgPHQ+CiAgICAgICAgICAgIFRoZSBjbGllbnQgTVVT VCBpZ25vcmUgdW5yZWNvZ25pemVkIHJlc3BvbnNlIHBhcmFtZXRlcnMuIFRoZSBhdXRob3JpemF0 aW9uIGNvZGUKICAgICAgICAgICAgc3RyaW5nIHNpemUgaXMgbGVmdCB1bmRlZmluZWQgYnkgdGhp cyBzcGVjaWZpY2F0aW9uLiBUaGUgY2xpZW50IHNob3VsZCBhdm9pZCBtYWtpbmcKICAgICAgICAg ICAgYXNzdW1wdGlvbnMgYWJvdXQgY29kZSB2YWx1ZSBzaXplcy4gVGhlIGF1dGhvcml6YXRpb24g c2VydmVyIFNIT1VMRCBkb2N1bWVudCB0aGUgc2l6ZQogICAgICAgICAgICBvZiBhbnkgdmFsdWUg aXQgaXNzdWVzLgogICAgICAgICAgPC90PgoKICAgICAgICAgIDxzZWN0aW9uIHRpdGxlPSdFcnJv ciBSZXNwb25zZScgYW5jaG9yPSdjb2RlLWF1dGh6LWVycm9yJz4KICAgICAgICAgICAgPHQ+CiAg ICAgICAgICAgICAgSWYgdGhlIHJlcXVlc3QgZmFpbHMgZHVlIHRvIGEgbWlzc2luZywgaW52YWxp ZCwgb3IgbWlzbWF0Y2hpbmcgcmVkaXJlY3Rpb24gVVJJLCBvciBpZgogICAgICAgICAgICAgIHRo ZSBjbGllbnQgaWRlbnRpZmllciBpcyBtaXNzaW5nIG9yIGludmFsaWQsIHRoZSBhdXRob3JpemF0 aW9uIHNlcnZlciBTSE9VTEQgaW5mb3JtCiAgICAgICAgICAgICAgdGhlIHJlc291cmNlIG93bmVy IG9mIHRoZSBlcnJvciwgYW5kIE1VU1QgTk9UIGF1dG9tYXRpY2FsbHkgcmVkaXJlY3QgdGhlIHVz ZXItYWdlbnQKICAgICAgICAgICAgICB0byB0aGUgaW52YWxpZCByZWRpcmVjdGlvbiBVUkkuCiAg ICAgICAgICAgIDwvdD4KICAgICAgICAgICAgPHQ+CiAgICAgICAgICAgICAgSWYgdGhlIHJlc291 cmNlIG93bmVyIGRlbmllcyB0aGUgYWNjZXNzIHJlcXVlc3Qgb3IgaWYgdGhlIHJlcXVlc3QgZmFp bHMgZm9yIHJlYXNvbnMKICAgICAgICAgICAgICBvdGhlciB0aGFuIGEgbWlzc2luZyBvciBpbnZh bGlkIHJlZGlyZWN0aW9uIFVSSSwgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGluZm9ybXMgdGhl CiAgICAgICAgICAgICAgY2xpZW50IGJ5IGFkZGluZyB0aGUgZm9sbG93aW5nIHBhcmFtZXRlcnMg dG8gdGhlIHF1ZXJ5IGNvbXBvbmVudCBvZiB0aGUgcmVkaXJlY3Rpb24KICAgICAgICAgICAgICBV UkkgdXNpbmcgdGhlIDxzcGFueCBzdHlsZT0ndmVyYic+YXBwbGljYXRpb24veC13d3ctZm9ybS11 cmxlbmNvZGVkPC9zcGFueD4gZm9ybWF0OgogICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgIDx0 PgogICAgICAgICAgICAgIDxsaXN0IHN0eWxlPSdoYW5naW5nJyBoYW5nSW5kZW50PSc2Jz4KICAg ICAgICAgICAgICAgIDx0IGhhbmdUZXh0PSdlcnJvcic+CiAgICAgICAgICAgICAgICAgIDx2c3Bh Y2UgLz4KICAgICAgICAgICAgICAgICAgUkVRVUlSRUQuIEEgc2luZ2xlIEFTQ0lJIDx4cmVmIHRh cmdldD0iVVNBU0NJSSIgLz4gZXJyb3IgY29kZSBmcm9tIHRoZSBmb2xsb3dpbmc6CgogICAgICAg ICAgICAgICAgICA8bGlzdCBzdHlsZT0naGFuZ2luZycgaGFuZ0luZGVudD0nNic+CiAgICAgICAg ICAgICAgICAgICAgPHQgaGFuZ1RleHQ9J2ludmFsaWRfcmVxdWVzdCc+CiAgICAgICAgICAgICAg ICAgICAgICA8dnNwYWNlIC8+CiAgICAgICAgICAgICAgICAgICAgICBUaGUgcmVxdWVzdCBpcyBt aXNzaW5nIGEgcmVxdWlyZWQgcGFyYW1ldGVyLCBpbmNsdWRlcyBhbiBpbnZhbGlkCiAgICAgICAg ICAgICAgICAgICAgICBwYXJhbWV0ZXIgdmFsdWUsIGluY2x1ZGVzIGEgcGFyYW1ldGVyIG1vcmUg dGhhbiBvbmNlLCBvciBpcyBvdGhlcndpc2UKICAgICAgICAgICAgICAgICAgICAgIG1hbGZvcm1l ZC4KICAgICAgICAgICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgICAgICAgICAgPHQgaGFuZ1Rl eHQ9J3VuYXV0aG9yaXplZF9jbGllbnQnPgogICAgICAgICAgICAgICAgICAgICAgPHZzcGFjZSAv PgogICAgICAgICAgICAgICAgICAgICAgVGhlIGNsaWVudCBpcyBub3QgYXV0aG9yaXplZCB0byBy ZXF1ZXN0IGFuIGF1dGhvcml6YXRpb24gY29kZSB1c2luZyB0aGlzCiAgICAgICAgICAgICAgICAg ICAgICBtZXRob2QuCiAgICAgICAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICAgICAgICAg IDx0IGhhbmdUZXh0PSdhY2Nlc3NfZGVuaWVkJz4KICAgICAgICAgICAgICAgICAgICAgIDx2c3Bh Y2UgLz4KICAgICAgICAgICAgICAgICAgICAgIFRoZSByZXNvdXJjZSBvd25lciBvciBhdXRob3Jp emF0aW9uIHNlcnZlciBkZW5pZWQgdGhlIHJlcXVlc3QuCiAgICAgICAgICAgICAgICAgICAgPC90 PgogICAgICAgICAgICAgICAgICAgIDx0IGhhbmdUZXh0PSd1bnN1cHBvcnRlZF9yZXNwb25zZV90 eXBlJz4KICAgICAgICAgICAgICAgICAgICAgIDx2c3BhY2UgLz4KICAgICAgICAgICAgICAgICAg ICAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBkb2VzIG5vdCBzdXBwb3J0IG9idGFpbmluZyBh biBhdXRob3JpemF0aW9uIGNvZGUKICAgICAgICAgICAgICAgICAgICAgIHVzaW5nIHRoaXMgbWV0 aG9kLgogICAgICAgICAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAgICAgICAgICA8dCBoYW5n VGV4dD0naW52YWxpZF9zY29wZSc+CiAgICAgICAgICAgICAgICAgICAgICA8dnNwYWNlIC8+CiAg ICAgICAgICAgICAgICAgICAgICBUaGUgcmVxdWVzdGVkIHNjb3BlIGlzIGludmFsaWQsIHVua25v d24sIG9yIG1hbGZvcm1lZC4KICAgICAgICAgICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgICAg ICAgICAgPHQgaGFuZ1RleHQ9J3NlcnZlcl9lcnJvcic+CiAgICAgICAgICAgICAgICAgICAgICA8 dnNwYWNlIC8+CiAgICAgICAgICAgICAgICAgICAgICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIg ZW5jb3VudGVyZWQgYW4gdW5leHBlY3RlZCBjb25kaXRpb24gd2hpY2ggcHJldmVudGVkCiAgICAg ICAgICAgICAgICAgICAgICBpdCBmcm9tIGZ1bGZpbGxpbmcgdGhlIHJlcXVlc3QuCiAgICAgICAg ICAgICAgICAgICAgPC90PgogICAgICAgICAgICAgICAgICAgIDx0IGhhbmdUZXh0PSd0ZW1wb3Jh cmlseV91bmF2YWlsYWJsZSc+CiAgICAgICAgICAgICAgICAgICAgICA8dnNwYWNlIC8+CiAgICAg ICAgICAgICAgICAgICAgICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgaXMgY3VycmVudGx5IHVu YWJsZSB0byBoYW5kbGUgdGhlIHJlcXVlc3QgZHVlIHRvIGEKICAgICAgICAgICAgICAgICAgICAg IHRlbXBvcmFyeSBvdmVybG9hZGluZyBvciBtYWludGVuYW5jZSBvZiB0aGUgc2VydmVyLgogICAg ICAgICAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAgICAgICAgPC9saXN0PgoKCQkgIFZhbHVl cyBmb3IgdGhlIDxzcGFueCBzdHlsZT0ndmVyYic+ZXJyb3I8L3NwYW54PiBwYXJhbWV0ZXIgTVVT VCBOT1QgaW5jbHVkZQoJCSAgY2hhcmFjdGVycyBvdXRzaWRlIHRoZSBzZXQgJXgyMC0yMSAvICV4 MjMtNUIgLyAleDVELTdFLgogICAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICAgICAgPHQg aGFuZ1RleHQ9J2Vycm9yX2Rlc2NyaXB0aW9uJz4KICAgICAgICAgICAgICAgICAgPHZzcGFjZSAv PgogICAgICAgICAgICAgICAgICBPUFRJT05BTC4gQSBodW1hbi1yZWFkYWJsZSBBU0NJSSA8eHJl ZiB0YXJnZXQ9IlVTQVNDSUkiIC8+IHRleHQgcHJvdmlkaW5nIGFkZGl0aW9uYWwgaW5mb3JtYXRp b24sCiAgICAgICAgICAgICAgICAgIHVzZWQgdG8gYXNzaXN0IHRoZSBjbGllbnQgZGV2ZWxvcGVy IGluIHVuZGVyc3RhbmRpbmcgdGhlIGVycm9yIHRoYXQgb2NjdXJyZWQuCgkJICA8dnNwYWNlLz4K CQkgIFZhbHVlcyBmb3IgdGhlIDxzcGFueCBzdHlsZT0ndmVyYic+ZXJyb3JfZGVzY3JpcHRpb248 L3NwYW54PiBwYXJhbWV0ZXIgTVVTVCBOT1QgaW5jbHVkZQoJCSAgY2hhcmFjdGVycyBvdXRzaWRl IHRoZSBzZXQgJXgyMC0yMSAvICV4MjMtNUIgLyAleDVELTdFLgogICAgICAgICAgICAgICAgPC90 PgogICAgICAgICAgICAgICAgPHQgaGFuZ1RleHQ9J2Vycm9yX3VyaSc+CiAgICAgICAgICAgICAg ICAgIDx2c3BhY2UgLz4KICAgICAgICAgICAgICAgICAgT1BUSU9OQUwuIEEgVVJJIGlkZW50aWZ5 aW5nIGEgaHVtYW4tcmVhZGFibGUgd2ViIHBhZ2Ugd2l0aCBpbmZvcm1hdGlvbiBhYm91dCB0aGUK ICAgICAgICAgICAgICAgICAgZXJyb3IsIHVzZWQgdG8gcHJvdmlkZSB0aGUgY2xpZW50IGRldmVs b3BlciB3aXRoIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gYWJvdXQgdGhlCiAgICAgICAgICAgICAg ICAgIGVycm9yLgoJCSAgPHZzcGFjZS8+CgkJICBWYWx1ZXMgZm9yIHRoZSA8c3Bhbnggc3R5bGU9 J3ZlcmInPmVycm9yX3VyaTwvc3Bhbng+IHBhcmFtZXRlcgoJCSAgTVVTVCBjb25mb3JtIHRvIHRo ZSBVUkktUmVmZXJlbmNlIHN5bnRheCwgYW5kIHRodXMgTVVTVCBOT1QgaW5jbHVkZQoJCSAgY2hh cmFjdGVycyBvdXRzaWRlIHRoZSBzZXQgJXgyMSAvICV4MjMtNUIgLyAleDVELTdFLgogICAgICAg ICAgICAgICAgPC90PgogICAgICAgICAgICAgICAgPHQgaGFuZ1RleHQ9J3N0YXRlJz4KICAgICAg ICAgICAgICAgICAgPHZzcGFjZSAvPgogICAgICAgICAgICAgICAgICBSRVFVSVJFRCBpZiBhIDxz cGFueCBzdHlsZT0ndmVyYic+c3RhdGU8L3NwYW54PiBwYXJhbWV0ZXIgd2FzIHByZXNlbnQgaW4g dGhlCiAgICAgICAgICAgICAgICAgIGNsaWVudCBhdXRob3JpemF0aW9uIHJlcXVlc3QuIFRoZSBl eGFjdCB2YWx1ZSByZWNlaXZlZCBmcm9tIHRoZSBjbGllbnQuCiAgICAgICAgICAgICAgICA8L3Q+ CiAgICAgICAgICAgICAgPC9saXN0PgogICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgIDxmaWd1 cmU+CiAgICAgICAgICAgICAgPHByZWFtYmxlPgogICAgICAgICAgICAgICAgRm9yIGV4YW1wbGUs IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciByZWRpcmVjdHMgdGhlIHVzZXItYWdlbnQgYnkgc2Vu ZGluZyB0aGUKICAgICAgICAgICAgICAgIGZvbGxvd2luZyBIVFRQIHJlc3BvbnNlOgogICAgICAg ICAgICAgIDwvcHJlYW1ibGU+CiAgICAgICAgICAgICAgPGFydHdvcms+CiAgICAgICAgICAgICAg ICA8IVtDREFUQVsKICBIVFRQLzEuMSAzMDIgRm91bmQKICBMb2NhdGlvbjogaHR0cHM6Ly9jbGll bnQuZXhhbXBsZS5jb20vY2I/ZXJyb3I9YWNjZXNzX2RlbmllZCZzdGF0ZT14eXoKXV0+CiAgICAg ICAgICAgICAgPC9hcnR3b3JrPgogICAgICAgICAgICA8L2ZpZ3VyZT4KICAgICAgICAgIDwvc2Vj dGlvbj4KCiAgICAgICAgPC9zZWN0aW9uPgoKICAgICAgICA8c2VjdGlvbiB0aXRsZT0nQWNjZXNz IFRva2VuIFJlcXVlc3QnIGFuY2hvcj0idG9rZW4tcmVxIj4KICAgICAgICAgIDx0PgogICAgICAg ICAgICBUaGUgY2xpZW50IG1ha2VzIGEgcmVxdWVzdCB0byB0aGUgdG9rZW4gZW5kcG9pbnQgYnkg YWRkaW5nIHRoZSBmb2xsb3dpbmcgcGFyYW1ldGVycwogICAgICAgICAgICB1c2luZyB0aGUgPHNw YW54IHN0eWxlPSd2ZXJiJz5hcHBsaWNhdGlvbi94LXd3dy1mb3JtLXVybGVuY29kZWQ8L3NwYW54 PiBmb3JtYXQgaW4gdGhlCiAgICAgICAgICAgIEhUVFAgcmVxdWVzdCBlbnRpdHktYm9keToKICAg ICAgICAgIDwvdD4KICAgICAgICAgIDx0PgogICAgICAgICAgICA8bGlzdCBzdHlsZT0naGFuZ2lu ZycgaGFuZ0luZGVudD0nNic+CiAgICAgICAgICAgICAgPHQgaGFuZ1RleHQ9J2dyYW50X3R5cGUn PgogICAgICAgICAgICAgICAgPHZzcGFjZSAvPgogICAgICAgICAgICAgICAgUkVRVUlSRUQuIFZh bHVlIE1VU1QgYmUgc2V0IHRvIDxzcGFueCBzdHlsZT0ndmVyYic+YXV0aG9yaXphdGlvbl9jb2Rl PC9zcGFueD4uCiAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICAgIDx0IGhhbmdUZXh0PSdj b2RlJz4KICAgICAgICAgICAgICAgIDx2c3BhY2UgLz4KICAgICAgICAgICAgICAgIFJFUVVJUkVE LiBUaGUgYXV0aG9yaXphdGlvbiBjb2RlIHJlY2VpdmVkIGZyb20gdGhlIGF1dGhvcml6YXRpb24g c2VydmVyLgogICAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAgICA8dCBoYW5nVGV4dD0ncmVk aXJlY3RfdXJpJz4KICAgICAgICAgICAgICAgIDx2c3BhY2UgLz4KICAgICAgICAgICAgICAgIFJF UVVJUkVELCBpZiB0aGUgPHNwYW54IHN0eWxlPSd2ZXJiJz5yZWRpcmVjdF91cmk8L3NwYW54PiBw YXJhbWV0ZXIgd2FzIGluY2x1ZGVkIGluCiAgICAgICAgICAgICAgICB0aGUgYXV0aG9yaXphdGlv biByZXF1ZXN0IGFzIGRlc2NyaWJlZCBpbiA8eHJlZiB0YXJnZXQ9J2NvZGUtYXV0aHotcmVxJyAv PiwgYW5kCiAgICAgICAgICAgICAgICB0aGVpciB2YWx1ZXMgTVVTVCBiZSBpZGVudGljYWwuCiAg ICAgICAgICAgICAgPC90PgogICAgICAgICAgICA8L2xpc3Q+CiAgICAgICAgICA8L3Q+CiAgICAg ICAgICA8dD4KICAgICAgICAgICAgSWYgdGhlIGNsaWVudCB0eXBlIGlzIGNvbmZpZGVudGlhbCBv ciB0aGUgY2xpZW50IHdhcyBpc3N1ZWQgY2xpZW50IGNyZWRlbnRpYWxzIChvcgogICAgICAgICAg ICBhc3NpZ25lZCBvdGhlciBhdXRoZW50aWNhdGlvbiByZXF1aXJlbWVudHMpLCB0aGUgY2xpZW50 IE1VU1QgYXV0aGVudGljYXRlIHdpdGggdGhlCiAgICAgICAgICAgIGF1dGhvcml6YXRpb24gc2Vy dmVyIGFzIGRlc2NyaWJlZCBpbiA8eHJlZiB0YXJnZXQ9J3Rva2VuLWVuZHBvaW50LWF1dGgnIC8+ LgogICAgICAgICAgPC90PgogICAgICAgICAgPGZpZ3VyZT4KICAgICAgICAgICAgPHByZWFtYmxl PgogICAgICAgICAgICAgIEZvciBleGFtcGxlLCB0aGUgY2xpZW50IG1ha2VzIHRoZSBmb2xsb3dp bmcgSFRUUCByZXF1ZXN0IHVzaW5nIFRMUyAoZXh0cmEgbGluZSBicmVha3MKICAgICAgICAgICAg ICBhcmUgZm9yIGRpc3BsYXkgcHVycG9zZXMgb25seSk6CiAgICAgICAgICAgIDwvcHJlYW1ibGU+ CiAgICAgICAgICAgIDxhcnR3b3JrPgogICAgICAgICAgICAgIDwhW0NEQVRBWwogIFBPU1QgL3Rv a2VuIEhUVFAvMS4xCiAgSG9zdDogc2VydmVyLmV4YW1wbGUuY29tCiAgQXV0aG9yaXphdGlvbjog QmFzaWMgY3paQ2FHUlNhM0YwTXpwbldERm1RbUYwTTJKVwogIENvbnRlbnQtVHlwZTogYXBwbGlj YXRpb24veC13d3ctZm9ybS11cmxlbmNvZGVkO2NoYXJzZXQ9VVRGLTgKCiAgZ3JhbnRfdHlwZT1h dXRob3JpemF0aW9uX2NvZGUmY29kZT1TcGx4bE9CZVpRUVliWVM2V3hTYklBCiAgJnJlZGlyZWN0 X3VyaT1odHRwcyUzQSUyRiUyRmNsaWVudCUyRWV4YW1wbGUlMkVjb20lMkZjYgpdXT4KICAgICAg ICAgICAgPC9hcnR3b3JrPgogICAgICAgICAgPC9maWd1cmU+CiAgICAgICAgICA8dD4KICAgICAg ICAgICAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIE1VU1Q6CiAgICAgICAgICA8L3Q+CiAgICAg ICAgICA8dD4KICAgICAgICAgICAgPGxpc3Qgc3R5bGU9J3N5bWJvbHMnPgogICAgICAgICAgICAg IDx0PgogICAgICAgICAgICAgICAgcmVxdWlyZSBjbGllbnQgYXV0aGVudGljYXRpb24gZm9yIGNv bmZpZGVudGlhbCBjbGllbnRzIG9yIGZvciBhbnkgY2xpZW50IHRoYXQgd2FzCiAgICAgICAgICAg ICAgICBpc3N1ZWQgY2xpZW50IGNyZWRlbnRpYWxzIChvciB3aXRoIG90aGVyIGF1dGhlbnRpY2F0 aW9uIHJlcXVpcmVtZW50cyksCiAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICAgIDx0Pgog ICAgICAgICAgICAgICAgYXV0aGVudGljYXRlIHRoZSBjbGllbnQgaWYgY2xpZW50IGF1dGhlbnRp Y2F0aW9uIGlzIGluY2x1ZGVkIGFuZCBlbnN1cmUgdGhlCiAgICAgICAgICAgICAgICBhdXRob3Jp emF0aW9uIGNvZGUgd2FzIGlzc3VlZCB0byB0aGUgYXV0aGVudGljYXRlZCBjbGllbnQsCiAgICAg ICAgICAgICAgPC90PgogICAgICAgICAgICAgIDx0PgogICAgICAgICAgICAgICAgdmVyaWZ5IHRo YXQgdGhlIGF1dGhvcml6YXRpb24gY29kZSBpcyB2YWxpZCwgYW5kCiAgICAgICAgICAgICAgPC90 PgogICAgICAgICAgICAgIDx0PgogICAgICAgICAgICAgICAgZW5zdXJlIHRoYXQgdGhlIDxzcGFu eCBzdHlsZT0ndmVyYic+cmVkaXJlY3RfdXJpPC9zcGFueD4gcGFyYW1ldGVyIGlzIHByZXNlbnQg aWYKICAgICAgICAgICAgICAgIHRoZSA8c3Bhbnggc3R5bGU9J3ZlcmInPnJlZGlyZWN0X3VyaTwv c3Bhbng+IHBhcmFtZXRlciB3YXMgaW5jbHVkZWQgaW4gdGhlIGluaXRpYWwKICAgICAgICAgICAg ICAgIGF1dGhvcml6YXRpb24gcmVxdWVzdCBhcyBkZXNjcmliZWQgaW4gPHhyZWYgdGFyZ2V0PSdj b2RlLWF1dGh6LXJlcScgLz4sIGFuZCBpZgogICAgICAgICAgICAgICAgaW5jbHVkZWQgZW5zdXJl IHRoZWlyIHZhbHVlcyBhcmUgaWRlbnRpY2FsLgogICAgICAgICAgICAgIDwvdD4KICAgICAgICAg ICAgPC9saXN0PgogICAgICAgICAgPC90PgogICAgICAgIDwvc2VjdGlvbj4KCiAgICAgICAgPHNl Y3Rpb24gdGl0bGU9J0FjY2VzcyBUb2tlbiBSZXNwb25zZSc+CiAgICAgICAgICA8dD4KICAgICAg ICAgICAgSWYgdGhlIGFjY2VzcyB0b2tlbiByZXF1ZXN0IGlzIHZhbGlkIGFuZCBhdXRob3JpemVk LCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgaXNzdWVzIGFuCiAgICAgICAgICAgIGFjY2VzcyB0 b2tlbiBhbmQgb3B0aW9uYWwgcmVmcmVzaCB0b2tlbiBhcyBkZXNjcmliZWQgaW4gPHhyZWYgdGFy Z2V0PSd0b2tlbi1yZXNwb25zZScgLz4uCiAgICAgICAgICAgIElmIHRoZSByZXF1ZXN0IGNsaWVu dCBhdXRoZW50aWNhdGlvbiBmYWlsZWQgb3IgaXMgaW52YWxpZCwgdGhlIGF1dGhvcml6YXRpb24g c2VydmVyIHJldHVybnMKICAgICAgICAgICAgYW4gZXJyb3IgcmVzcG9uc2UgYXMgZGVzY3JpYmVk IGluIDx4cmVmIHRhcmdldD0ndG9rZW4tZXJyb3JzJyAvPi4KICAgICAgICAgIDwvdD4KICAgICAg ICAgIDxmaWd1cmU+CiAgICAgICAgICAgIDxwcmVhbWJsZT4KICAgICAgICAgICAgICBBbiBleGFt cGxlIHN1Y2Nlc3NmdWwgcmVzcG9uc2U6CiAgICAgICAgICAgIDwvcHJlYW1ibGU+CiAgICAgICAg ICAgIDxhcnR3b3JrPgogICAgICAgICAgICAgIDwhW0NEQVRBWwogIEhUVFAvMS4xIDIwMCBPSwog IENvbnRlbnQtVHlwZTogYXBwbGljYXRpb24vanNvbjtjaGFyc2V0PVVURi04CiAgQ2FjaGUtQ29u dHJvbDogbm8tc3RvcmUKICBQcmFnbWE6IG5vLWNhY2hlCgogIHsKICAgICJhY2Nlc3NfdG9rZW4i OiIyWW90bkZaRkVqcjF6Q3NpY01XcEFBIiwKICAgICJ0b2tlbl90eXBlIjoiZXhhbXBsZSIsCiAg ICAiZXhwaXJlc19pbiI6MzYwMCwKICAgICJyZWZyZXNoX3Rva2VuIjoidEd6djNKT2tGMFhHNVF4 MlRsS1dJQSIsCiAgICAiZXhhbXBsZV9wYXJhbWV0ZXIiOiJleGFtcGxlX3ZhbHVlIgogIH0KXV0+ CiAgICAgICAgICAgIDwvYXJ0d29yaz4KICAgICAgICAgIDwvZmlndXJlPgogICAgICAgIDwvc2Vj dGlvbj4KCiAgICAgIDwvc2VjdGlvbj4KCiAgICAgIDxzZWN0aW9uIHRpdGxlPSdJbXBsaWNpdCBH cmFudCcgYW5jaG9yPSdncmFudC1pbXBsaWNpdCc+CiAgICAgICAgPHQ+CiAgICAgICAgICBUaGUg aW1wbGljaXQgZ3JhbnQgdHlwZSBpcyB1c2VkIHRvIG9idGFpbiBhY2Nlc3MgdG9rZW5zIChpdCBk b2VzIG5vdCBzdXBwb3J0IHRoZSBpc3N1YW5jZQogICAgICAgICAgb2YgcmVmcmVzaCB0b2tlbnMp IGFuZCBpcyBvcHRpbWl6ZWQgZm9yIHB1YmxpYyBjbGllbnRzIGtub3duIHRvIG9wZXJhdGUgYSBw YXJ0aWN1bGFyCiAgICAgICAgICByZWRpcmVjdGlvbiBVUkkuIFRoZXNlIGNsaWVudHMgYXJlIHR5 cGljYWxseSBpbXBsZW1lbnRlZCBpbiBhIGJyb3dzZXIgdXNpbmcgYSBzY3JpcHRpbmcKICAgICAg ICAgIGxhbmd1YWdlIHN1Y2ggYXMgSmF2YVNjcmlwdC4KICAgICAgICA8L3Q+CiAgICAgICAgPHQ+ CiAgICAgICAgICBBcyBhIHJlZGlyZWN0aW9uLWJhc2VkIGZsb3csIHRoZSBjbGllbnQgbXVzdCBi ZSBjYXBhYmxlIG9mIGludGVyYWN0aW5nIHdpdGggdGhlCiAgICAgICAgICByZXNvdXJjZSBvd25l cidzIHVzZXItYWdlbnQgKHR5cGljYWxseSBhIHdlYiBicm93c2VyKSBhbmQgY2FwYWJsZSBvZiBy ZWNlaXZpbmcgaW5jb21pbmcKICAgICAgICAgIHJlcXVlc3RzICh2aWEgcmVkaXJlY3Rpb24pIGZy b20gdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLgogICAgICAgIDwvdD4KICAgICAgICA8dD4KICAg ICAgICAgIFVubGlrZSB0aGUgYXV0aG9yaXphdGlvbiBjb2RlIGdyYW50IHR5cGUgaW4gd2hpY2gg dGhlIGNsaWVudCBtYWtlcyBzZXBhcmF0ZSByZXF1ZXN0cyBmb3IKICAgICAgICAgIGF1dGhvcml6 YXRpb24gYW5kIGFjY2VzcyB0b2tlbiwgdGhlIGNsaWVudCByZWNlaXZlcyB0aGUgYWNjZXNzIHRv a2VuIGFzIHRoZSByZXN1bHQgb2YgdGhlCiAgICAgICAgICBhdXRob3JpemF0aW9uIHJlcXVlc3Qu CiAgICAgICAgPC90PgogICAgICAgIDx0PgogICAgICAgICAgVGhlIGltcGxpY2l0IGdyYW50IHR5 cGUgZG9lcyBub3QgaW5jbHVkZSBjbGllbnQgYXV0aGVudGljYXRpb24sIGFuZCByZWxpZXMgb24g dGhlCiAgICAgICAgICBwcmVzZW5jZSBvZiB0aGUgcmVzb3VyY2Ugb3duZXIgYW5kIHRoZSByZWdp c3RyYXRpb24gb2YgdGhlIHJlZGlyZWN0aW9uIFVSSS4gQmVjYXVzZSB0aGUKICAgICAgICAgIGFj Y2VzcyB0b2tlbiBpcyBlbmNvZGVkIGludG8gdGhlIHJlZGlyZWN0aW9uIFVSSSwgaXQgbWF5IGJl IGV4cG9zZWQgdG8gdGhlIHJlc291cmNlIG93bmVyCiAgICAgICAgICBhbmQgb3RoZXIgYXBwbGlj YXRpb25zIHJlc2lkaW5nIG9uIHRoZSBzYW1lIGRldmljZS4KICAgICAgICA8L3Q+CiAgICAgICAg PGZpZ3VyZSB0aXRsZT0nSW1wbGljaXQgR3JhbnQgRmxvdycgYW5jaG9yPSdGaWd1cmUtNCc+CiAg ICAgICAgICA8YXJ0d29yaz4KICAgICAgICAgICAgPCFbQ0RBVEFbCiAgKy0tLS0tLS0tLS0rCiAg fCBSZXNvdXJjZSB8CiAgfCAgT3duZXIgICB8CiAgfCAgICAgICAgICB8CiAgKy0tLS0tLS0tLS0r CiAgICAgICBeCiAgICAgICB8CiAgICAgIChCKSAgICAgIAogICstLS0tfC0tLS0tKyAgICAgICAg ICBDbGllbnQgSWRlbnRpZmllciAgICAgKy0tLS0tLS0tLS0tLS0tLSsKICB8ICAgICAgICAgLSst LS0tKEEpLS0gJiBSZWRpcmVjdGlvbiBVUkkgLS0tPnwgICAgICAgICAgICAgICB8CiAgfCAgVXNl ci0gICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IEF1dGhvcml6YXRpb24gfAog IHwgIEFnZW50ICAtfC0tLS0oQiktLSBVc2VyIGF1dGhlbnRpY2F0ZXMgLS0+fCAgICAgU2VydmVy ICAgIHwKICB8ICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAg ICAgICAgICAgICB8CiAgfCAgICAgICAgICB8PC0tLShDKS0tLSBSZWRpcmVjdGlvbiBVUkkgLS0t LTx8ICAgICAgICAgICAgICAgfAogIHwgICAgICAgICAgfCAgICAgICAgICB3aXRoIEFjY2VzcyBU b2tlbiAgICAgKy0tLS0tLS0tLS0tLS0tLSsKICB8ICAgICAgICAgIHwgICAgICAgICAgICBpbiBG cmFnbWVudAogIHwgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0t LS0tLS0tLS0tLS0tLSsKICB8ICAgICAgICAgIHwtLS0tKEQpLS0tIFJlZGlyZWN0aW9uIFVSSSAt LS0tPnwgICBXZWItSG9zdGVkICB8CiAgfCAgICAgICAgICB8ICAgICAgICAgIHdpdGhvdXQgRnJh Z21lbnQgICAgICB8ICAgICBDbGllbnQgICAgfAogIHwgICAgICAgICAgfCAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgfCAgICBSZXNvdXJjZSAgIHwKICB8ICAgICAoRikgIHw8LS0tKEUp LS0tLS0tLSBTY3JpcHQgLS0tLS0tLS0tPHwgICAgICAgICAgICAgICB8CiAgfCAgICAgICAgICB8 ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tKwogICstfC0t LS0tLS0tKwogICAgfCAgICB8ICAgIAogICAoQSkgIChHKSBBY2Nlc3MgVG9rZW4KICAgIHwgICAg fAogICAgXiAgICB2CiAgKy0tLS0tLS0tLSsKICB8ICAgICAgICAgfAogIHwgIENsaWVudCB8CiAg fCAgICAgICAgIHwKICArLS0tLS0tLS0tKwpdXT4KICAgICAgICAgIDwvYXJ0d29yaz4KICAgICAg ICAgIDxwb3N0YW1ibGU+CiAgICAgICAgICAgIE5vdGU6IFRoZSBsaW5lcyBpbGx1c3RyYXRpbmcg c3RlcHMgQSBhbmQgQiBhcmUgYnJva2VuIGludG8gdHdvIHBhcnRzIGFzIHRoZXkgcGFzcwogICAg ICAgICAgICB0aHJvdWdoIHRoZSB1c2VyLWFnZW50LgogICAgICAgICAgPC9wb3N0YW1ibGU+CiAg ICAgICAgPC9maWd1cmU+CiAgICAgICAgPHQ+CiAgICAgICAgICBUaGUgZmxvdyBpbGx1c3RyYXRl ZCBpbiA8eHJlZiB0YXJnZXQ9J0ZpZ3VyZS00JyAvPiBpbmNsdWRlcyB0aGUgZm9sbG93aW5nIHN0 ZXBzOgogICAgICAgIDwvdD4KICAgICAgICA8dD4KICAgICAgICAgIDxsaXN0IHN0eWxlPSdmb3Jt YXQgKCVDKSc+CiAgICAgICAgICAgIDx0PgogICAgICAgICAgICAgIFRoZSBjbGllbnQgaW5pdGlh dGVzIHRoZSBmbG93IGJ5IGRpcmVjdGluZyB0aGUgcmVzb3VyY2Ugb3duZXIncyB1c2VyLWFnZW50 IHRvIHRoZQogICAgICAgICAgICAgIGF1dGhvcml6YXRpb24gZW5kcG9pbnQuIFRoZSBjbGllbnQg aW5jbHVkZXMgaXRzIGNsaWVudCBpZGVudGlmaWVyLCByZXF1ZXN0ZWQKICAgICAgICAgICAgICBz Y29wZSwgbG9jYWwgc3RhdGUsIGFuZCBhIHJlZGlyZWN0aW9uIFVSSSB0byB3aGljaCB0aGUgYXV0 aG9yaXphdGlvbiBzZXJ2ZXIgd2lsbCBzZW5kCiAgICAgICAgICAgICAgdGhlIHVzZXItYWdlbnQg YmFjayBvbmNlIGFjY2VzcyBpcyBncmFudGVkIChvciBkZW5pZWQpLgogICAgICAgICAgICA8L3Q+ CiAgICAgICAgICAgIDx0PgogICAgICAgICAgICAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBh dXRoZW50aWNhdGVzIHRoZSByZXNvdXJjZSBvd25lciAodmlhIHRoZSB1c2VyLWFnZW50KSBhbmQK ICAgICAgICAgICAgICBlc3RhYmxpc2hlcyB3aGV0aGVyIHRoZSByZXNvdXJjZSBvd25lciBncmFu dHMgb3IgZGVuaWVzIHRoZSBjbGllbnQncyBhY2Nlc3MgcmVxdWVzdC4KICAgICAgICAgICAgPC90 PgogICAgICAgICAgICA8dD4KICAgICAgICAgICAgICBBc3N1bWluZyB0aGUgcmVzb3VyY2Ugb3du ZXIgZ3JhbnRzIGFjY2VzcywgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHJlZGlyZWN0cyB0aGUK ICAgICAgICAgICAgICB1c2VyLWFnZW50IGJhY2sgdG8gdGhlIGNsaWVudCB1c2luZyB0aGUgcmVk aXJlY3Rpb24gVVJJIHByb3ZpZGVkIGVhcmxpZXIuIFRoZQogICAgICAgICAgICAgIHJlZGlyZWN0 aW9uIFVSSSBpbmNsdWRlcyB0aGUgYWNjZXNzIHRva2VuIGluIHRoZSBVUkkgZnJhZ21lbnQuCiAg ICAgICAgICAgIDwvdD4KICAgICAgICAgICAgPHQ+CiAgICAgICAgICAgICAgVGhlIHVzZXItYWdl bnQgZm9sbG93cyB0aGUgcmVkaXJlY3Rpb24gaW5zdHJ1Y3Rpb25zIGJ5IG1ha2luZyBhIHJlcXVl c3QgdG8gdGhlCiAgICAgICAgICAgICAgd2ViLWhvc3RlZCBjbGllbnQgcmVzb3VyY2UgKHdoaWNo IGRvZXMgbm90IGluY2x1ZGUgdGhlIGZyYWdtZW50IHBlcgogICAgICAgICAgICAgIDx4cmVmIHRh cmdldD0nUkZDMjYxNicgLz4pLiBUaGUgdXNlci1hZ2VudCByZXRhaW5zIHRoZSBmcmFnbWVudCBp bmZvcm1hdGlvbiBsb2NhbGx5LgogICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgIDx0PgogICAg ICAgICAgICAgIFRoZSB3ZWItaG9zdGVkIGNsaWVudCByZXNvdXJjZSByZXR1cm5zIGEgd2ViIHBh Z2UgKHR5cGljYWxseSBhbiBIVE1MIGRvY3VtZW50IHdpdGggYW4KICAgICAgICAgICAgICBlbWJl ZGRlZCBzY3JpcHQpIGNhcGFibGUgb2YgYWNjZXNzaW5nIHRoZSBmdWxsIHJlZGlyZWN0aW9uIFVS SSBpbmNsdWRpbmcgdGhlIGZyYWdtZW50CiAgICAgICAgICAgICAgcmV0YWluZWQgYnkgdGhlIHVz ZXItYWdlbnQsIGFuZCBleHRyYWN0aW5nIHRoZSBhY2Nlc3MgdG9rZW4gKGFuZCBvdGhlciBwYXJh bWV0ZXJzKQogICAgICAgICAgICAgIGNvbnRhaW5lZCBpbiB0aGUgZnJhZ21lbnQuCiAgICAgICAg ICAgIDwvdD4KICAgICAgICAgICAgPHQ+CiAgICAgICAgICAgICAgVGhlIHVzZXItYWdlbnQgZXhl Y3V0ZXMgdGhlIHNjcmlwdCBwcm92aWRlZCBieSB0aGUgd2ViLWhvc3RlZCBjbGllbnQgcmVzb3Vy Y2UKICAgICAgICAgICAgICBsb2NhbGx5LCB3aGljaCBleHRyYWN0cyB0aGUgYWNjZXNzIHRva2Vu IGFuZCBwYXNzZXMgaXQgdG8gdGhlIGNsaWVudC4KICAgICAgICAgICAgPC90PgogICAgICAgICAg PC9saXN0PgogICAgICAgIDwvdD4KCiAgICAgICAgPHNlY3Rpb24gdGl0bGU9J0F1dGhvcml6YXRp b24gUmVxdWVzdCcgYW5jaG9yPSdpbXBsaWNpdC1hdXRoei1yZXEnPgogICAgICAgICAgPHQ+CiAg ICAgICAgICAgIFRoZSBjbGllbnQgY29uc3RydWN0cyB0aGUgcmVxdWVzdCBVUkkgYnkgYWRkaW5n IHRoZSBmb2xsb3dpbmcgcGFyYW1ldGVycyB0byB0aGUKICAgICAgICAgICAgcXVlcnkgY29tcG9u ZW50IG9mIHRoZSBhdXRob3JpemF0aW9uIGVuZHBvaW50IFVSSSB1c2luZyB0aGUKICAgICAgICAg ICAgPHNwYW54IHN0eWxlPSd2ZXJiJz5hcHBsaWNhdGlvbi94LXd3dy1mb3JtLXVybGVuY29kZWQ8 L3NwYW54PiBmb3JtYXQ6CiAgICAgICAgICA8L3Q+CiAgICAgICAgICA8dD4KICAgICAgICAgICAg PGxpc3Qgc3R5bGU9J2hhbmdpbmcnIGhhbmdJbmRlbnQ9JzYnPgogICAgICAgICAgICAgIDx0IGhh bmdUZXh0PSdyZXNwb25zZV90eXBlJz4KICAgICAgICAgICAgICAgIDx2c3BhY2UgLz4KICAgICAg ICAgICAgICAgIFJFUVVJUkVELiBWYWx1ZSBNVVNUIGJlIHNldCB0byA8c3Bhbnggc3R5bGU9J3Zl cmInPnRva2VuPC9zcGFueD4uCiAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICAgIDx0IGhh bmdUZXh0PSdjbGllbnRfaWQnPgogICAgICAgICAgICAgICAgPHZzcGFjZSAvPgogICAgICAgICAg ICAgICAgUkVRVUlSRUQuIFRoZSBjbGllbnQgaWRlbnRpZmllciBhcyBkZXNjcmliZWQgaW4KICAg ICAgICAgICAgICAgIDx4cmVmIHRhcmdldD0nY2xpZW50LWlkZW50aWZpZXInIC8+LgogICAgICAg ICAgICAgIDwvdD4KICAgICAgICAgICAgICA8dCBoYW5nVGV4dD0ncmVkaXJlY3RfdXJpJz4KICAg ICAgICAgICAgICAgIDx2c3BhY2UgLz4KICAgICAgICAgICAgICAgIE9QVElPTkFMLiBBcyBkZXNj cmliZWQgaW4gPHhyZWYgdGFyZ2V0PSdyZWRpcmVjdC11cmknIC8+LgogICAgICAgICAgICAgIDwv dD4KICAgICAgICAgICAgICA8dCBoYW5nVGV4dD0nc2NvcGUnPgogICAgICAgICAgICAgICAgPHZz cGFjZSAvPgogICAgICAgICAgICAgICAgT1BUSU9OQUwuIFRoZSBzY29wZSBvZiB0aGUgYWNjZXNz IHJlcXVlc3QgYXMgZGVzY3JpYmVkIGJ5IDx4cmVmIHRhcmdldD0nc2NvcGUnIC8+LgogICAgICAg ICAgICAgIDwvdD4KICAgICAgICAgICAgICA8dCBoYW5nVGV4dD0nc3RhdGUnPgogICAgICAgICAg ICAgICAgPHZzcGFjZSAvPgogICAgICAgICAgICAgICAgUkVDT01NRU5ERUQuIEFuIG9wYXF1ZSB2 YWx1ZSB1c2VkIGJ5IHRoZSBjbGllbnQgdG8gbWFpbnRhaW4gc3RhdGUgYmV0d2VlbiB0aGUgcmVx dWVzdAogICAgICAgICAgICAgICAgYW5kIGNhbGxiYWNrLiBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2 ZXIgaW5jbHVkZXMgdGhpcyB2YWx1ZSB3aGVuIHJlZGlyZWN0aW5nIHRoZQogICAgICAgICAgICAg ICAgdXNlci1hZ2VudCBiYWNrIHRvIHRoZSBjbGllbnQuIFRoZSBwYXJhbWV0ZXIgU0hPVUxEIGJl IHVzZWQgZm9yIHByZXZlbnRpbmcKICAgICAgICAgICAgICAgIGNyb3NzLXNpdGUgcmVxdWVzdCBm b3JnZXJ5IGFzIGRlc2NyaWJlZCBpbiA8eHJlZiB0YXJnZXQ9J0NTUkYnIC8+LgogICAgICAgICAg ICAgIDwvdD4KICAgICAgICAgICAgPC9saXN0PgogICAgICAgICAgPC90PgogICAgICAgICAgPHQ+ CiAgICAgICAgICAgIFRoZSBjbGllbnQgZGlyZWN0cyB0aGUgcmVzb3VyY2Ugb3duZXIgdG8gdGhl IGNvbnN0cnVjdGVkIFVSSSB1c2luZyBhbiBIVFRQIHJlZGlyZWN0aW9uCiAgICAgICAgICAgIHJl c3BvbnNlLCBvciBieSBvdGhlciBtZWFucyBhdmFpbGFibGUgdG8gaXQgdmlhIHRoZSB1c2VyLWFn ZW50LgogICAgICAgICAgPC90PgogICAgICAgICAgPGZpZ3VyZT4KICAgICAgICAgICAgPHByZWFt YmxlPgogICAgICAgICAgICAgIEZvciBleGFtcGxlLCB0aGUgY2xpZW50IGRpcmVjdHMgdGhlIHVz ZXItYWdlbnQgdG8gbWFrZSB0aGUgZm9sbG93aW5nIEhUVFAgcmVxdWVzdAogICAgICAgICAgICAg IHVzaW5nIFRMUyAoZXh0cmEgbGluZSBicmVha3MgYXJlIGZvciBkaXNwbGF5IHB1cnBvc2VzIG9u bHkpOgogICAgICAgICAgICA8L3ByZWFtYmxlPgogICAgICAgICAgICA8YXJ0d29yaz4KICAgICAg ICAgICAgICA8IVtDREFUQVsKICBHRVQgL2F1dGhvcml6ZT9yZXNwb25zZV90eXBlPXRva2VuJmNs aWVudF9pZD1zNkJoZFJrcXQzJnN0YXRlPXh5egogICAgICAmcmVkaXJlY3RfdXJpPWh0dHBzJTNB JTJGJTJGY2xpZW50JTJFZXhhbXBsZSUyRWNvbSUyRmNiIEhUVFAvMS4xCiAgSG9zdDogc2VydmVy LmV4YW1wbGUuY29tCl1dPgogICAgICAgICAgICA8L2FydHdvcms+CiAgICAgICAgICA8L2ZpZ3Vy ZT4KICAgICAgICAgIDx0PgogICAgICAgICAgICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgdmFs aWRhdGVzIHRoZSByZXF1ZXN0IHRvIGVuc3VyZSBhbGwgcmVxdWlyZWQgcGFyYW1ldGVycyBhcmUK ICAgICAgICAgICAgcHJlc2VudCBhbmQgdmFsaWQuIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBN VVNUIHZlcmlmeSB0aGF0IHRoZSByZWRpcmVjdGlvbiBVUkkgdG8gd2hpY2gKICAgICAgICAgICAg aXQgd2lsbCByZWRpcmVjdCB0aGUgYWNjZXNzIHRva2VuIG1hdGNoZXMgYSByZWRpcmVjdGlvbiBV UkkgcmVnaXN0ZXJlZCBieSB0aGUgY2xpZW50IGFzCiAgICAgICAgICAgIGRlc2NyaWJlZCBpbiA8 eHJlZiB0YXJnZXQ9J3JlZGlyZWN0LXVyaScgLz4uCiAgICAgICAgICA8L3Q+CiAgICAgICAgICA8 dD4KICAgICAgICAgICAgSWYgdGhlIHJlcXVlc3QgaXMgdmFsaWQsIHRoZSBhdXRob3JpemF0aW9u IHNlcnZlciBhdXRoZW50aWNhdGVzIHRoZSByZXNvdXJjZSBvd25lciBhbmQKICAgICAgICAgICAg b2J0YWlucyBhbiBhdXRob3JpemF0aW9uIGRlY2lzaW9uIChieSBhc2tpbmcgdGhlIHJlc291cmNl IG93bmVyIG9yIGJ5IGVzdGFibGlzaGluZwogICAgICAgICAgICBhcHByb3ZhbCB2aWEgb3RoZXIg bWVhbnMpLgogICAgICAgICAgPC90PgogICAgICAgICAgPHQ+CiAgICAgICAgICAgIFdoZW4gYSBk ZWNpc2lvbiBpcyBlc3RhYmxpc2hlZCwgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGRpcmVjdHMg dGhlIHVzZXItYWdlbnQgdG8gdGhlCiAgICAgICAgICAgIHByb3ZpZGVkIGNsaWVudCByZWRpcmVj dGlvbiBVUkkgdXNpbmcgYW4gSFRUUCByZWRpcmVjdGlvbiByZXNwb25zZSwgb3IgYnkgb3RoZXIg bWVhbnMKICAgICAgICAgICAgYXZhaWxhYmxlIHRvIGl0IHZpYSB0aGUgdXNlci1hZ2VudC4KICAg ICAgICAgIDwvdD4KICAgICAgICA8L3NlY3Rpb24+CgogICAgICAgIDxzZWN0aW9uIHRpdGxlPSdB Y2Nlc3MgVG9rZW4gUmVzcG9uc2UnIGFuY2hvcj0iaW1wbGljaXQtYXV0aHotcmVzcCI+CiAgICAg ICAgICA8dD4KICAgICAgICAgICAgSWYgdGhlIHJlc291cmNlIG93bmVyIGdyYW50cyB0aGUgYWNj ZXNzIHJlcXVlc3QsIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBpc3N1ZXMgYW4KICAgICAgICAg ICAgYWNjZXNzIHRva2VuIGFuZCBkZWxpdmVycyBpdCB0byB0aGUgY2xpZW50IGJ5IGFkZGluZyB0 aGUgZm9sbG93aW5nIHBhcmFtZXRlcnMgdG8KICAgICAgICAgICAgdGhlIGZyYWdtZW50IGNvbXBv bmVudCBvZiB0aGUgcmVkaXJlY3Rpb24gVVJJIHVzaW5nIHRoZQogICAgICAgICAgICA8c3Bhbngg c3R5bGU9J3ZlcmInPmFwcGxpY2F0aW9uL3gtd3d3LWZvcm0tdXJsZW5jb2RlZDwvc3Bhbng+IGZv cm1hdDoKICAgICAgICAgIDwvdD4KICAgICAgICAgIDx0PgogICAgICAgICAgICA8bGlzdCBzdHls ZT0naGFuZ2luZycgaGFuZ0luZGVudD0nNic+CiAgICAgICAgICAgICAgPHQgaGFuZ1RleHQ9J2Fj Y2Vzc190b2tlbic+CiAgICAgICAgICAgICAgICA8dnNwYWNlIC8+CiAgICAgICAgICAgICAgICBS RVFVSVJFRC4gVGhlIGFjY2VzcyB0b2tlbiBpc3N1ZWQgYnkgdGhlIGF1dGhvcml6YXRpb24gc2Vy dmVyLgogICAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAgICA8dCBoYW5nVGV4dD0ndG9rZW5f dHlwZSc+CiAgICAgICAgICAgICAgICA8dnNwYWNlIC8+CiAgICAgICAgICAgICAgICBSRVFVSVJF RC4gVGhlIHR5cGUgb2YgdGhlIHRva2VuIGlzc3VlZCBhcyBkZXNjcmliZWQgaW4KICAgICAgICAg ICAgICAgIDx4cmVmIHRhcmdldD0ndG9rZW4tdHlwZXMnIC8+LiBWYWx1ZSBpcyBjYXNlIGluc2Vu c2l0aXZlLgogICAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAgICA8dCBoYW5nVGV4dD0nZXhw aXJlc19pbic+CiAgICAgICAgICAgICAgICA8dnNwYWNlIC8+CiAgICAgICAgICAgICAgICBSRUNP TU1FTkRFRC4gVGhlIGxpZmV0aW1lIGluIHNlY29uZHMgb2YgdGhlIGFjY2VzcyB0b2tlbi4gRm9y IGV4YW1wbGUsIHRoZSB2YWx1ZQogICAgICAgICAgICAgICAgPHNwYW54IHN0eWxlPSd2ZXJiJz4z NjAwPC9zcGFueD4gZGVub3RlcyB0aGF0IHRoZSBhY2Nlc3MgdG9rZW4gd2lsbCBleHBpcmUgaW4g b25lCiAgICAgICAgICAgICAgICBob3VyIGZyb20gdGhlIHRpbWUgdGhlIHJlc3BvbnNlIHdhcyBn ZW5lcmF0ZWQuIElmIG9taXR0ZWQsIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlcgogICAgICAgICAg ICAgICAgU0hPVUxEIHByb3ZpZGUgdGhlIGV4cGlyYXRpb24gdGltZSB2aWEgb3RoZXIgbWVhbnMg b3IgZG9jdW1lbnQgdGhlIGRlZmF1bHQgdmFsdWUuCiAgICAgICAgICAgICAgPC90PgogICAgICAg ICAgICAgIDx0IGhhbmdUZXh0PSdzY29wZSc+CiAgICAgICAgICAgICAgICA8dnNwYWNlIC8+CiAg ICAgICAgICAgICAgICBPUFRJT05BTCwgaWYgaWRlbnRpY2FsIHRvIHRoZSBzY29wZSByZXF1ZXN0 ZWQgYnkgdGhlIGNsaWVudCwgb3RoZXJ3aXNlIFJFUVVJUkVELiBUaGUKICAgICAgICAgICAgICAg IHNjb3BlIG9mIHRoZSBhY2Nlc3MgdG9rZW4gYXMgZGVzY3JpYmVkIGJ5IDx4cmVmIHRhcmdldD0n c2NvcGUnIC8+LgogICAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAgICA8dCBoYW5nVGV4dD0n c3RhdGUnPgogICAgICAgICAgICAgICAgPHZzcGFjZSAvPgogICAgICAgICAgICAgICAgUkVRVUlS RUQgaWYgdGhlIDxzcGFueCBzdHlsZT0ndmVyYic+c3RhdGU8L3NwYW54PiBwYXJhbWV0ZXIgd2Fz IHByZXNlbnQgaW4gdGhlCiAgICAgICAgICAgICAgICBjbGllbnQgYXV0aG9yaXphdGlvbiByZXF1 ZXN0LiBUaGUgZXhhY3QgdmFsdWUgcmVjZWl2ZWQgZnJvbSB0aGUgY2xpZW50LgogICAgICAgICAg ICAgIDwvdD4KICAgICAgICAgICAgPC9saXN0PgogICAgICAgICAgPC90PgogICAgICAgICAgPHQ+ CiAgICAgICAgICAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBNVVNUIE5PVCBpc3N1ZSBhIHJl ZnJlc2ggdG9rZW4uCiAgICAgICAgICA8L3Q+CiAgICAgICAgICA8ZmlndXJlPgogICAgICAgICAg ICA8cHJlYW1ibGU+CiAgICAgICAgICAgICAgRm9yIGV4YW1wbGUsIHRoZSBhdXRob3JpemF0aW9u IHNlcnZlciByZWRpcmVjdHMgdGhlIHVzZXItYWdlbnQgYnkgc2VuZGluZyB0aGUKICAgICAgICAg ICAgICBmb2xsb3dpbmcgSFRUUCByZXNwb25zZSAoVVJJIGV4dHJhIGxpbmUgYnJlYWtzIGFyZSBm b3IgZGlzcGxheSBwdXJwb3NlcyBvbmx5KToKICAgICAgICAgICAgPC9wcmVhbWJsZT4KICAgICAg ICAgICAgPGFydHdvcms+CiAgICAgICAgICAgICAgPCFbQ0RBVEFbCiAgSFRUUC8xLjEgMzAyIEZv dW5kCiAgTG9jYXRpb246IGh0dHA6Ly9leGFtcGxlLmNvbS9jYiNhY2Nlc3NfdG9rZW49MllvdG5G WkZFanIxekNzaWNNV3BBQQogICAgICAgICAgICAmc3RhdGU9eHl6JnRva2VuX3R5cGU9ZXhhbXBs ZSZleHBpcmVzX2luPTM2MDAKXV0+CiAgICAgICAgICAgIDwvYXJ0d29yaz4KICAgICAgICAgICAg PHBvc3RhbWJsZT4KICAgICAgICAgICAgICBEZXZlbG9wZXJzIHNob3VsZCBub3RlIHRoYXQgc29t ZSB1c2VyLWFnZW50cyBkbyBub3Qgc3VwcG9ydCB0aGUgaW5jbHVzaW9uIG9mIGEKICAgICAgICAg ICAgICBmcmFnbWVudCBjb21wb25lbnQgaW4gdGhlIEhUVFAgPHNwYW54IHN0eWxlPSd2ZXJiJz5M b2NhdGlvbjwvc3Bhbng+IHJlc3BvbnNlIGhlYWRlcgogICAgICAgICAgICAgIGZpZWxkLiBTdWNo IGNsaWVudHMgd2lsbCByZXF1aXJlIHVzaW5nIG90aGVyIG1ldGhvZHMgZm9yIHJlZGlyZWN0aW5n IHRoZSBjbGllbnQgdGhhbgogICAgICAgICAgICAgIGEgM3h4IHJlZGlyZWN0aW9uIHJlc3BvbnNl LiBGb3IgZXhhbXBsZSwgcmV0dXJuaW5nIGFuIEhUTUwgcGFnZSB3aGljaCBpbmNsdWRlcyBhCiAg ICAgICAgICAgICAgJ2NvbnRpbnVlJyBidXR0b24gd2l0aCBhbiBhY3Rpb24gbGlua2VkIHRvIHRo ZSByZWRpcmVjdGlvbiBVUkkuCiAgICAgICAgICAgIDwvcG9zdGFtYmxlPgogICAgICAgICAgPC9m aWd1cmU+CiAgICAgICAgICA8dD4KICAgICAgICAgICAgVGhlIGNsaWVudCBNVVNUIGlnbm9yZSB1 bnJlY29nbml6ZWQgcmVzcG9uc2UgcGFyYW1ldGVycy4gVGhlIGFjY2VzcyB0b2tlbiBzdHJpbmcg c2l6ZQogICAgICAgICAgICBpcyBsZWZ0IHVuZGVmaW5lZCBieSB0aGlzIHNwZWNpZmljYXRpb24u IFRoZSBjbGllbnQgc2hvdWxkIGF2b2lkIG1ha2luZyBhc3N1bXB0aW9ucwogICAgICAgICAgICBh Ym91dCB2YWx1ZSBzaXplcy4gVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIFNIT1VMRCBkb2N1bWVu dCB0aGUgc2l6ZSBvZiBhbnkgdmFsdWUgaXQKICAgICAgICAgICAgaXNzdWVzLgogICAgICAgICAg PC90PgoKICAgICAgICAgIDxzZWN0aW9uIHRpdGxlPSdFcnJvciBSZXNwb25zZScgYW5jaG9yPSdp bXBsaWNpdC1hdXRoei1lcnJvcic+CiAgICAgICAgICAgIDx0PgogICAgICAgICAgICAgIElmIHRo ZSByZXF1ZXN0IGZhaWxzIGR1ZSB0byBhIG1pc3NpbmcsIGludmFsaWQsIG9yIG1pc21hdGNoaW5n IHJlZGlyZWN0aW9uIFVSSSwgb3IgaWYKICAgICAgICAgICAgICB0aGUgY2xpZW50IGlkZW50aWZp ZXIgaXMgbWlzc2luZyBvciBpbnZhbGlkLCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgU0hPVUxE IGluZm9ybQogICAgICAgICAgICAgIHRoZSByZXNvdXJjZSBvd25lciBvZiB0aGUgZXJyb3IsIGFu ZCBNVVNUIE5PVCBhdXRvbWF0aWNhbGx5IHJlZGlyZWN0IHRoZSB1c2VyLWFnZW50CiAgICAgICAg ICAgICAgdG8gdGhlIGludmFsaWQgcmVkaXJlY3Rpb24gVVJJLgogICAgICAgICAgICA8L3Q+CiAg ICAgICAgICAgIDx0PgogICAgICAgICAgICAgIElmIHRoZSByZXNvdXJjZSBvd25lciBkZW5pZXMg dGhlIGFjY2VzcyByZXF1ZXN0IG9yIGlmIHRoZSByZXF1ZXN0IGZhaWxzIGZvciByZWFzb25zCiAg ICAgICAgICAgICAgb3RoZXIgdGhhbiBhIG1pc3Npbmcgb3IgaW52YWxpZCByZWRpcmVjdGlvbiBV UkksIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBpbmZvcm1zIHRoZQogICAgICAgICAgICAgIGNs aWVudCBieSBhZGRpbmcgdGhlIGZvbGxvd2luZyBwYXJhbWV0ZXJzIHRvIHRoZSBmcmFnbWVudCBj b21wb25lbnQgb2YgdGhlCiAgICAgICAgICAgICAgcmVkaXJlY3Rpb24gVVJJIHVzaW5nIHRoZQog ICAgICAgICAgICAgIDxzcGFueCBzdHlsZT0ndmVyYic+YXBwbGljYXRpb24veC13d3ctZm9ybS11 cmxlbmNvZGVkPC9zcGFueD4gZm9ybWF0OgogICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgIDx0 PgogICAgICAgICAgICAgIDxsaXN0IHN0eWxlPSdoYW5naW5nJyBoYW5nSW5kZW50PSc2Jz4KICAg ICAgICAgICAgICAgIDx0IGhhbmdUZXh0PSdlcnJvcic+CiAgICAgICAgICAgICAgICAgIDx2c3Bh Y2UgLz4KICAgICAgICAgICAgICAgICAgUkVRVUlSRUQuIEEgc2luZ2xlIEFTQ0lJIDx4cmVmIHRh cmdldD0iVVNBU0NJSSIgLz4gZXJyb3IgY29kZSBmcm9tIHRoZSBmb2xsb3dpbmc6CgogICAgICAg ICAgICAgICAgICA8bGlzdCBzdHlsZT0naGFuZ2luZycgaGFuZ0luZGVudD0nNic+CiAgICAgICAg ICAgICAgICAgICAgPHQgaGFuZ1RleHQ9J2ludmFsaWRfcmVxdWVzdCc+CiAgICAgICAgICAgICAg ICAgICAgICA8dnNwYWNlIC8+CiAgICAgICAgICAgICAgICAgICAgICBUaGUgcmVxdWVzdCBpcyBt aXNzaW5nIGEgcmVxdWlyZWQgcGFyYW1ldGVyLCBpbmNsdWRlcyBhbiBpbnZhbGlkCiAgICAgICAg ICAgICAgICAgICAgICBwYXJhbWV0ZXIgdmFsdWUsIGluY2x1ZGVzIGEgcGFyYW1ldGVyIG1vcmUg dGhhbiBvbmNlLCBvciBpcyBvdGhlcndpc2UgbWFsZm9ybWVkLgogICAgICAgICAgICAgICAgICAg IDwvdD4KICAgICAgICAgICAgICAgICAgICA8dCBoYW5nVGV4dD0ndW5hdXRob3JpemVkX2NsaWVu dCc+CiAgICAgICAgICAgICAgICAgICAgICA8dnNwYWNlIC8+CiAgICAgICAgICAgICAgICAgICAg ICBUaGUgY2xpZW50IGlzIG5vdCBhdXRob3JpemVkIHRvIHJlcXVlc3QgYW4gYWNjZXNzIHRva2Vu IHVzaW5nIHRoaXMgbWV0aG9kLgogICAgICAgICAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAg ICAgICAgICA8dCBoYW5nVGV4dD0nYWNjZXNzX2RlbmllZCc+CiAgICAgICAgICAgICAgICAgICAg ICA8dnNwYWNlIC8+CiAgICAgICAgICAgICAgICAgICAgICBUaGUgcmVzb3VyY2Ugb3duZXIgb3Ig YXV0aG9yaXphdGlvbiBzZXJ2ZXIgZGVuaWVkIHRoZSByZXF1ZXN0LgogICAgICAgICAgICAgICAg ICAgIDwvdD4KICAgICAgICAgICAgICAgICAgICA8dCBoYW5nVGV4dD0ndW5zdXBwb3J0ZWRfcmVz cG9uc2VfdHlwZSc+CiAgICAgICAgICAgICAgICAgICAgICA8dnNwYWNlIC8+CiAgICAgICAgICAg ICAgICAgICAgICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgZG9lcyBub3Qgc3VwcG9ydCBvYnRh aW5pbmcgYW4gYWNjZXNzIHRva2VuIHVzaW5nCiAgICAgICAgICAgICAgICAgICAgICB0aGlzIG1l dGhvZC4KICAgICAgICAgICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgICAgICAgICAgPHQgaGFu Z1RleHQ9J2ludmFsaWRfc2NvcGUnPgogICAgICAgICAgICAgICAgICAgICAgPHZzcGFjZSAvPgog ICAgICAgICAgICAgICAgICAgICAgVGhlIHJlcXVlc3RlZCBzY29wZSBpcyBpbnZhbGlkLCB1bmtu b3duLCBvciBtYWxmb3JtZWQuCiAgICAgICAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICAg ICAgICAgIDx0IGhhbmdUZXh0PSdzZXJ2ZXJfZXJyb3InPgogICAgICAgICAgICAgICAgICAgICAg PHZzcGFjZSAvPgogICAgICAgICAgICAgICAgICAgICAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVy IGVuY291bnRlcmVkIGFuIHVuZXhwZWN0ZWQgY29uZGl0aW9uIHdoaWNoIHByZXZlbnRlZAogICAg ICAgICAgICAgICAgICAgICAgaXQgZnJvbSBmdWxmaWxsaW5nIHRoZSByZXF1ZXN0LgogICAgICAg ICAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAgICAgICAgICA8dCBoYW5nVGV4dD0ndGVtcG9y YXJpbHlfdW5hdmFpbGFibGUnPgogICAgICAgICAgICAgICAgICAgICAgPHZzcGFjZSAvPgogICAg ICAgICAgICAgICAgICAgICAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGlzIGN1cnJlbnRseSB1 bmFibGUgdG8gaGFuZGxlIHRoZSByZXF1ZXN0IGR1ZSB0byBhCiAgICAgICAgICAgICAgICAgICAg ICB0ZW1wb3Jhcnkgb3ZlcmxvYWRpbmcgb3IgbWFpbnRlbmFuY2Ugb2YgdGhlIHNlcnZlci4KICAg ICAgICAgICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgICAgICAgIDwvbGlzdD4KCgkJICBWYWx1 ZXMgZm9yIHRoZSA8c3Bhbnggc3R5bGU9J3ZlcmInPmVycm9yPC9zcGFueD4gcGFyYW1ldGVyIE1V U1QgTk9UIGluY2x1ZGUKCQkgIGNoYXJhY3RlcnMgb3V0c2lkZSB0aGUgc2V0ICV4MjAtMjEgLyAl eDIzLTVCIC8gJXg1RC03RS4KICAgICAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAgICAgIDx0 IGhhbmdUZXh0PSdlcnJvcl9kZXNjcmlwdGlvbic+CiAgICAgICAgICAgICAgICAgIDx2c3BhY2Ug Lz4KICAgICAgICAgICAgICAgICAgT1BUSU9OQUwuIEEgaHVtYW4tcmVhZGFibGUgQVNDSUkgPHhy ZWYgdGFyZ2V0PSJVU0FTQ0lJIiAvPiB0ZXh0IHByb3ZpZGluZyBhZGRpdGlvbmFsIGluZm9ybWF0 aW9uLAogICAgICAgICAgICAgICAgICB1c2VkIHRvIGFzc2lzdCB0aGUgY2xpZW50IGRldmVsb3Bl ciBpbiB1bmRlcnN0YW5kaW5nIHRoZSBlcnJvciB0aGF0IG9jY3VycmVkLgoJCSAgPHZzcGFjZS8+ CgkJICBWYWx1ZXMgZm9yIHRoZSA8c3Bhbnggc3R5bGU9J3ZlcmInPmVycm9yX2Rlc2NyaXB0aW9u PC9zcGFueD4gcGFyYW1ldGVyIE1VU1QgTk9UIGluY2x1ZGUKCQkgIGNoYXJhY3RlcnMgb3V0c2lk ZSB0aGUgc2V0ICV4MjAtMjEgLyAleDIzLTVCIC8gJXg1RC03RS4KICAgICAgICAgICAgICAgIDwv dD4KICAgICAgICAgICAgICAgIDx0IGhhbmdUZXh0PSdlcnJvcl91cmknPgogICAgICAgICAgICAg ICAgICA8dnNwYWNlIC8+CiAgICAgICAgICAgICAgICAgIE9QVElPTkFMLiBBIFVSSSBpZGVudGlm eWluZyBhIGh1bWFuLXJlYWRhYmxlIHdlYiBwYWdlIHdpdGggaW5mb3JtYXRpb24gYWJvdXQgdGhl CiAgICAgICAgICAgICAgICAgIGVycm9yLCB1c2VkIHRvIHByb3ZpZGUgdGhlIGNsaWVudCBkZXZl bG9wZXIgd2l0aCBhZGRpdGlvbmFsIGluZm9ybWF0aW9uIGFib3V0IHRoZQogICAgICAgICAgICAg ICAgICBlcnJvci4KCQkgIDx2c3BhY2UvPgoJCSAgVmFsdWVzIGZvciB0aGUgPHNwYW54IHN0eWxl PSd2ZXJiJz5lcnJvcl91cmk8L3NwYW54PiBwYXJhbWV0ZXIKCQkgIE1VU1QgY29uZm9ybSB0byB0 aGUgVVJJLVJlZmVyZW5jZSBzeW50YXgsIGFuZCB0aHVzIE1VU1QgTk9UIGluY2x1ZGUKCQkgIGNo YXJhY3RlcnMgb3V0c2lkZSB0aGUgc2V0ICV4MjEgLyAleDIzLTVCIC8gJXg1RC03RS4KICAgICAg ICAgICAgICAgIDwvdD4KICAgICAgICAgICAgICAgIDx0IGhhbmdUZXh0PSdzdGF0ZSc+CiAgICAg ICAgICAgICAgICAgIDx2c3BhY2UgLz4KICAgICAgICAgICAgICAgICAgUkVRVUlSRUQgaWYgYSA8 c3Bhbnggc3R5bGU9J3ZlcmInPnN0YXRlPC9zcGFueD4gcGFyYW1ldGVyIHdhcyBwcmVzZW50IGlu IHRoZQogICAgICAgICAgICAgICAgICBjbGllbnQgYXV0aG9yaXphdGlvbiByZXF1ZXN0LiBUaGUg ZXhhY3QgdmFsdWUgcmVjZWl2ZWQgZnJvbSB0aGUgY2xpZW50LgogICAgICAgICAgICAgICAgPC90 PgogICAgICAgICAgICAgIDwvbGlzdD4KICAgICAgICAgICAgPC90PgogICAgICAgICAgICA8Zmln dXJlPgogICAgICAgICAgICAgIDxwcmVhbWJsZT4KICAgICAgICAgICAgICAgIEZvciBleGFtcGxl LCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgcmVkaXJlY3RzIHRoZSB1c2VyLWFnZW50IGJ5IHNl bmRpbmcgdGhlCiAgICAgICAgICAgICAgICBmb2xsb3dpbmcgSFRUUCByZXNwb25zZToKICAgICAg ICAgICAgICA8L3ByZWFtYmxlPgogICAgICAgICAgICAgIDxhcnR3b3JrPgogICAgICAgICAgICAg ICAgPCFbQ0RBVEFbCiAgSFRUUC8xLjEgMzAyIEZvdW5kCiAgTG9jYXRpb246IGh0dHBzOi8vY2xp ZW50LmV4YW1wbGUuY29tL2NiI2Vycm9yPWFjY2Vzc19kZW5pZWQmc3RhdGU9eHl6Cl1dPgogICAg ICAgICAgICAgIDwvYXJ0d29yaz4KICAgICAgICAgICAgPC9maWd1cmU+CiAgICAgICAgICA8L3Nl Y3Rpb24+CgogICAgICAgIDwvc2VjdGlvbj4KCiAgICAgIDwvc2VjdGlvbj4KCiAgICAgIDxzZWN0 aW9uIHRpdGxlPSdSZXNvdXJjZSBPd25lciBQYXNzd29yZCBDcmVkZW50aWFscyBHcmFudCcgYW5j aG9yPSdncmFudC1wYXNzd29yZCc+CiAgICAgICAgPHQ+CiAgICAgICAgICBUaGUgcmVzb3VyY2Ug b3duZXIgcGFzc3dvcmQgY3JlZGVudGlhbHMgZ3JhbnQgdHlwZSBpcyBzdWl0YWJsZSBpbiBjYXNl cyB3aGVyZSB0aGUKICAgICAgICAgIHJlc291cmNlIG93bmVyIGhhcyBhIHRydXN0IHJlbGF0aW9u c2hpcCB3aXRoIHRoZSBjbGllbnQsIHN1Y2ggYXMgdGhlIGRldmljZSBvcGVyYXRpbmcKICAgICAg ICAgIHN5c3RlbSBvciBhIGhpZ2hseSBwcml2aWxlZ2VkIGFwcGxpY2F0aW9uLiBUaGUgYXV0aG9y aXphdGlvbiBzZXJ2ZXIgc2hvdWxkIHRha2Ugc3BlY2lhbAogICAgICAgICAgY2FyZSB3aGVuIGVu YWJsaW5nIHRoaXMgZ3JhbnQgdHlwZSwgYW5kIG9ubHkgYWxsb3cgaXQgd2hlbiBvdGhlciBmbG93 cyBhcmUgbm90IHZpYWJsZS4KICAgICAgICA8L3Q+CiAgICAgICAgPHQ+CiAgICAgICAgICBUaGUg Z3JhbnQgdHlwZSBpcyBzdWl0YWJsZSBmb3IgY2xpZW50cyBjYXBhYmxlIG9mIG9idGFpbmluZyB0 aGUgcmVzb3VyY2Ugb3duZXIncwogICAgICAgICAgY3JlZGVudGlhbHMgKHVzZXJuYW1lIGFuZCBw YXNzd29yZCwgdHlwaWNhbGx5IHVzaW5nIGFuIGludGVyYWN0aXZlIGZvcm0pLiBJdCBpcyBhbHNv IHVzZWQKICAgICAgICAgIHRvIG1pZ3JhdGUgZXhpc3RpbmcgY2xpZW50cyB1c2luZyBkaXJlY3Qg YXV0aGVudGljYXRpb24gc2NoZW1lcyBzdWNoIGFzIEhUVFAgQmFzaWMgb3IKICAgICAgICAgIERp Z2VzdCBhdXRoZW50aWNhdGlvbiB0byBPQXV0aCBieSBjb252ZXJ0aW5nIHRoZSBzdG9yZWQgY3Jl ZGVudGlhbHMgdG8gYW4gYWNjZXNzIHRva2VuLgogICAgICAgIDwvdD4KICAgICAgICA8ZmlndXJl IHRpdGxlPSdSZXNvdXJjZSBPd25lciBQYXNzd29yZCBDcmVkZW50aWFscyBGbG93JyBhbmNob3I9 J0ZpZ3VyZS01Jz4KICAgICAgICAgIDxhcnR3b3JrPgogICAgICAgICAgICA8IVtDREFUQVsKICAr LS0tLS0tLS0tLSsKICB8IFJlc291cmNlIHwKICB8ICBPd25lciAgIHwKICB8ICAgICAgICAgIHwK ICArLS0tLS0tLS0tLSsKICAgICAgIHYKICAgICAgIHwgICAgUmVzb3VyY2UgT3duZXIKICAgICAg KEEpIFBhc3N3b3JkIENyZWRlbnRpYWxzCiAgICAgICB8CiAgICAgICB2CiAgKy0tLS0tLS0tLSsg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLSsKICB8ICAg ICAgICAgfD4tLShCKS0tLS0gUmVzb3VyY2UgT3duZXIgLS0tLS0tLT58ICAgICAgICAgICAgICAg fAogIHwgICAgICAgICB8ICAgICAgICAgUGFzc3dvcmQgQ3JlZGVudGlhbHMgICAgIHwgQXV0aG9y aXphdGlvbiB8CiAgfCBDbGllbnQgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg fCAgICAgU2VydmVyICAgIHwKICB8ICAgICAgICAgfDwtLShDKS0tLS0gQWNjZXNzIFRva2VuIC0t LS0tLS0tLTx8ICAgICAgICAgICAgICAgfAogIHwgICAgICAgICB8ICAgICh3LyBPcHRpb25hbCBS ZWZyZXNoIFRva2VuKSAgIHwgICAgICAgICAgICAgICB8CiAgKy0tLS0tLS0tLSsgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLSsKXV0+CiAgICAgICAgICA8 L2FydHdvcms+CiAgICAgICAgPC9maWd1cmU+CiAgICAgICAgPHQ+CiAgICAgICAgICBUaGUgZmxv dyBpbGx1c3RyYXRlZCBpbiA8eHJlZiB0YXJnZXQ9J0ZpZ3VyZS01JyAvPiBpbmNsdWRlcyB0aGUg Zm9sbG93aW5nIHN0ZXBzOgogICAgICAgIDwvdD4KICAgICAgICA8dD4KICAgICAgICAgIDxsaXN0 IHN0eWxlPSdmb3JtYXQgKCVDKSc+CiAgICAgICAgICAgIDx0PgogICAgICAgICAgICAgIFRoZSBy ZXNvdXJjZSBvd25lciBwcm92aWRlcyB0aGUgY2xpZW50IHdpdGggaXRzIHVzZXJuYW1lIGFuZCBw YXNzd29yZC4KICAgICAgICAgICAgPC90PgogICAgICAgICAgICA8dD4KICAgICAgICAgICAgICBU aGUgY2xpZW50IHJlcXVlc3RzIGFuIGFjY2VzcyB0b2tlbiBmcm9tIHRoZSBhdXRob3JpemF0aW9u IHNlcnZlcidzIHRva2VuIGVuZHBvaW50IGJ5CiAgICAgICAgICAgICAgaW5jbHVkaW5nIHRoZSBj cmVkZW50aWFscyByZWNlaXZlZCBmcm9tIHRoZSByZXNvdXJjZSBvd25lci4gV2hlbiBtYWtpbmcg dGhlIHJlcXVlc3QsCiAgICAgICAgICAgICAgdGhlIGNsaWVudCBhdXRoZW50aWNhdGVzIHdpdGgg dGhlIGF1dGhvcml6YXRpb24gc2VydmVyLgogICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgIDx0 PgogICAgICAgICAgICAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBhdXRoZW50aWNhdGVzIHRo ZSBjbGllbnQgYW5kIHZhbGlkYXRlcyB0aGUgcmVzb3VyY2Ugb3duZXIKICAgICAgICAgICAgICBj cmVkZW50aWFscywgYW5kIGlmIHZhbGlkIGlzc3VlcyBhbiBhY2Nlc3MgdG9rZW4uCiAgICAgICAg ICAgIDwvdD4KICAgICAgICAgIDwvbGlzdD4KICAgICAgICA8L3Q+CgogICAgICAgIDxzZWN0aW9u IHRpdGxlPSdBdXRob3JpemF0aW9uIFJlcXVlc3QgYW5kIFJlc3BvbnNlJz4KICAgICAgICAgIDx0 PgogICAgICAgICAgICBUaGUgbWV0aG9kIHRocm91Z2ggd2hpY2ggdGhlIGNsaWVudCBvYnRhaW5z IHRoZSByZXNvdXJjZSBvd25lciBjcmVkZW50aWFscyBpcyBiZXlvbmQKICAgICAgICAgICAgdGhl IHNjb3BlIG9mIHRoaXMgc3BlY2lmaWNhdGlvbi4gVGhlIGNsaWVudCBNVVNUIGRpc2NhcmQgdGhl IGNyZWRlbnRpYWxzIG9uY2UgYW4gYWNjZXNzCiAgICAgICAgICAgIHRva2VuIGhhcyBiZWVuIG9i dGFpbmVkLgogICAgICAgICAgPC90PgogICAgICAgIDwvc2VjdGlvbj4KCiAgICAgICAgPHNlY3Rp b24gdGl0bGU9J0FjY2VzcyBUb2tlbiBSZXF1ZXN0JyBhbmNob3I9InBhc3N3b3JkLXRvay1yZXEi PgogICAgICAgICAgPHQ+CiAgICAgICAgICAgIFRoZSBjbGllbnQgbWFrZXMgYSByZXF1ZXN0IHRv IHRoZSB0b2tlbiBlbmRwb2ludCBieSBhZGRpbmcgdGhlIGZvbGxvd2luZyBwYXJhbWV0ZXJzCiAg ICAgICAgICAgIHVzaW5nIHRoZSA8c3Bhbnggc3R5bGU9J3ZlcmInPmFwcGxpY2F0aW9uL3gtd3d3 LWZvcm0tdXJsZW5jb2RlZDwvc3Bhbng+IGZvcm1hdCBpbiB0aGUKICAgICAgICAgICAgSFRUUCBy ZXF1ZXN0IGVudGl0eS1ib2R5OgogICAgICAgICAgPC90PgogICAgICAgICAgPHQ+CiAgICAgICAg ICAgIDxsaXN0IHN0eWxlPSdoYW5naW5nJyBoYW5nSW5kZW50PSc2Jz4KICAgICAgICAgICAgICA8 dCBoYW5nVGV4dD0nZ3JhbnRfdHlwZSc+CiAgICAgICAgICAgICAgICA8dnNwYWNlIC8+CiAgICAg ICAgICAgICAgICBSRVFVSVJFRC4gVmFsdWUgTVVTVCBiZSBzZXQgdG8gPHNwYW54IHN0eWxlPSd2 ZXJiJz5wYXNzd29yZDwvc3Bhbng+LgogICAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAgICA8 dCBoYW5nVGV4dD0ndXNlcm5hbWUnPgogICAgICAgICAgICAgICAgPHZzcGFjZSAvPgogICAgICAg ICAgICAgICAgUkVRVUlSRUQuIFRoZSByZXNvdXJjZSBvd25lciB1c2VybmFtZSwgZW5jb2RlZCBh cyBVVEYtOC4KICAgICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgICAgPHQgaGFuZ1RleHQ9J3Bh c3N3b3JkJz4KICAgICAgICAgICAgICAgIDx2c3BhY2UgLz4KICAgICAgICAgICAgICAgIFJFUVVJ UkVELiBUaGUgcmVzb3VyY2Ugb3duZXIgcGFzc3dvcmQsIGVuY29kZWQgYXMgVVRGLTguCiAgICAg ICAgICAgICAgPC90PgogICAgICAgICAgICAgIDx0IGhhbmdUZXh0PSdzY29wZSc+CiAgICAgICAg ICAgICAgICA8dnNwYWNlIC8+CiAgICAgICAgICAgICAgICBPUFRJT05BTC4gVGhlIHNjb3BlIG9m IHRoZSBhY2Nlc3MgcmVxdWVzdCBhcyBkZXNjcmliZWQgYnkgPHhyZWYgdGFyZ2V0PSdzY29wZScg Lz4uCiAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICA8L2xpc3Q+CiAgICAgICAgICA8L3Q+ CiAgICAgICAgICA8dD4KICAgICAgICAgICAgSWYgdGhlIGNsaWVudCB0eXBlIGlzIGNvbmZpZGVu dGlhbCBvciB0aGUgY2xpZW50IHdhcyBpc3N1ZWQgY2xpZW50IGNyZWRlbnRpYWxzIChvcgogICAg ICAgICAgICBhc3NpZ25lZCBvdGhlciBhdXRoZW50aWNhdGlvbiByZXF1aXJlbWVudHMpLCB0aGUg Y2xpZW50IE1VU1QgYXV0aGVudGljYXRlIHdpdGggdGhlCiAgICAgICAgICAgIGF1dGhvcml6YXRp b24gc2VydmVyIGFzIGRlc2NyaWJlZCBpbiA8eHJlZiB0YXJnZXQ9J3Rva2VuLWVuZHBvaW50LWF1 dGgnIC8+LgogICAgICAgICAgPC90PgogICAgICAgICAgPGZpZ3VyZT4KICAgICAgICAgICAgPHBy ZWFtYmxlPgogICAgICAgICAgICAgIEZvciBleGFtcGxlLCB0aGUgY2xpZW50IG1ha2VzIHRoZSBm b2xsb3dpbmcgSFRUUCByZXF1ZXN0IHVzaW5nIHRyYW5zcG9ydC1sYXllcgogICAgICAgICAgICAg IHNlY3VyaXR5IChleHRyYSBsaW5lIGJyZWFrcyBhcmUgZm9yIGRpc3BsYXkgcHVycG9zZXMgb25s eSk6CiAgICAgICAgICAgIDwvcHJlYW1ibGU+CiAgICAgICAgICAgIDxhcnR3b3JrPgogICAgICAg ICAgICAgIDwhW0NEQVRBWwogIFBPU1QgL3Rva2VuIEhUVFAvMS4xCiAgSG9zdDogc2VydmVyLmV4 YW1wbGUuY29tCiAgQXV0aG9yaXphdGlvbjogQmFzaWMgY3paQ2FHUlNhM0YwTXpwbldERm1RbUYw TTJKVwogIENvbnRlbnQtVHlwZTogYXBwbGljYXRpb24veC13d3ctZm9ybS11cmxlbmNvZGVkO2No YXJzZXQ9VVRGLTgKICAKICBncmFudF90eXBlPXBhc3N3b3JkJnVzZXJuYW1lPWpvaG5kb2UmcGFz c3dvcmQ9QTNkZGozdwpdXT4KICAgICAgICAgICAgPC9hcnR3b3JrPgogICAgICAgICAgPC9maWd1 cmU+CiAgICAgICAgICA8dD4KICAgICAgICAgICAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIE1V U1Q6CiAgICAgICAgICA8L3Q+CiAgICAgICAgICA8dD4KICAgICAgICAgICAgPGxpc3Qgc3R5bGU9 J3N5bWJvbHMnPgogICAgICAgICAgICAgIDx0PgogICAgICAgICAgICAgICAgcmVxdWlyZSBjbGll bnQgYXV0aGVudGljYXRpb24gZm9yIGNvbmZpZGVudGlhbCBjbGllbnRzIG9yIGZvciBhbnkgY2xp ZW50IHRoYXQgd2FzCiAgICAgICAgICAgICAgICBpc3N1ZWQgY2xpZW50IGNyZWRlbnRpYWxzIChv ciB3aXRoIG90aGVyIGF1dGhlbnRpY2F0aW9uIHJlcXVpcmVtZW50cyksCiAgICAgICAgICAgICAg PC90PgogICAgICAgICAgICAgIDx0PgogICAgICAgICAgICAgICAgYXV0aGVudGljYXRlIHRoZSBj bGllbnQgaWYgY2xpZW50IGF1dGhlbnRpY2F0aW9uIGlzIGluY2x1ZGVkLCBhbmQKICAgICAgICAg ICAgICA8L3Q+CiAgICAgICAgICAgICAgPHQ+CiAgICAgICAgICAgICAgICB2YWxpZGF0ZSB0aGUg cmVzb3VyY2Ugb3duZXIgcGFzc3dvcmQgY3JlZGVudGlhbHMgdXNpbmcgaXRzIGV4aXN0aW5nIHBh c3N3b3JkCiAgICAgICAgICAgICAgICB2YWxpZGF0aW9uIGFsZ29yaXRobS4KICAgICAgICAgICAg ICA8L3Q+CiAgICAgICAgICAgIDwvbGlzdD4KICAgICAgICAgIDwvdD4KICAgICAgICAgIDx0Pgog ICAgICAgICAgICBTaW5jZSB0aGlzIGFjY2VzcyB0b2tlbiByZXF1ZXN0IHV0aWxpemVzIHRoZSBy ZXNvdXJjZSBvd25lcidzIHBhc3N3b3JkLCB0aGUKICAgICAgICAgICAgYXV0aG9yaXphdGlvbiBz ZXJ2ZXIgTVVTVCBwcm90ZWN0IHRoZSBlbmRwb2ludCBhZ2FpbnN0IGJydXRlIGZvcmNlIGF0dGFj a3MgKGUuZy4gdXNpbmcKICAgICAgICAgICAgcmF0ZS1saW1pdGF0aW9uIG9yIGdlbmVyYXRpbmcg YWxlcnRzKS4KICAgICAgICAgIDwvdD4KICAgICAgICA8L3NlY3Rpb24+CgogICAgICAgIDxzZWN0 aW9uIHRpdGxlPSdBY2Nlc3MgVG9rZW4gUmVzcG9uc2UnPgogICAgICAgICAgPHQ+CiAgICAgICAg ICAgIElmIHRoZSBhY2Nlc3MgdG9rZW4gcmVxdWVzdCBpcyB2YWxpZCBhbmQgYXV0aG9yaXplZCwg dGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGlzc3VlcyBhbgogICAgICAgICAgICBhY2Nlc3MgdG9r ZW4gYW5kIG9wdGlvbmFsIHJlZnJlc2ggdG9rZW4gYXMgZGVzY3JpYmVkIGluIDx4cmVmIHRhcmdl dD0ndG9rZW4tcmVzcG9uc2UnIC8+LgogICAgICAgICAgICBJZiB0aGUgcmVxdWVzdCBmYWlsZWQg Y2xpZW50IGF1dGhlbnRpY2F0aW9uIG9yIGlzIGludmFsaWQsIHRoZSBhdXRob3JpemF0aW9uIHNl cnZlciByZXR1cm5zCiAgICAgICAgICAgIGFuIGVycm9yIHJlc3BvbnNlIGFzIGRlc2NyaWJlZCBp biA8eHJlZiB0YXJnZXQ9J3Rva2VuLWVycm9ycycgLz4uCiAgICAgICAgICA8L3Q+CiAgICAgICAg ICA8ZmlndXJlPgogICAgICAgICAgICA8cHJlYW1ibGU+CiAgICAgICAgICAgICAgQW4gZXhhbXBs ZSBzdWNjZXNzZnVsIHJlc3BvbnNlOgogICAgICAgICAgICA8L3ByZWFtYmxlPgogICAgICAgICAg ICA8YXJ0d29yaz4KICAgICAgICAgICAgICA8IVtDREFUQVsKICBIVFRQLzEuMSAyMDAgT0sKICBD b250ZW50LVR5cGU6IGFwcGxpY2F0aW9uL2pzb247Y2hhcnNldD1VVEYtOAogIENhY2hlLUNvbnRy b2w6IG5vLXN0b3JlCiAgUHJhZ21hOiBuby1jYWNoZQoKICB7CiAgICAiYWNjZXNzX3Rva2VuIjoi MllvdG5GWkZFanIxekNzaWNNV3BBQSIsCiAgICAidG9rZW5fdHlwZSI6ImV4YW1wbGUiLAogICAg ImV4cGlyZXNfaW4iOjM2MDAsCiAgICAicmVmcmVzaF90b2tlbiI6InRHenYzSk9rRjBYRzVReDJU bEtXSUEiLAogICAgImV4YW1wbGVfcGFyYW1ldGVyIjoiZXhhbXBsZV92YWx1ZSIKICB9Cl1dPgog ICAgICAgICAgICA8L2FydHdvcms+CiAgICAgICAgICA8L2ZpZ3VyZT4KICAgICAgICA8L3NlY3Rp b24+CgogICAgICA8L3NlY3Rpb24+CgogICAgICA8c2VjdGlvbiB0aXRsZT0nQ2xpZW50IENyZWRl bnRpYWxzIEdyYW50JyBhbmNob3I9J2dyYW50LWNsaWVudCc+CiAgICAgICAgPHQ+CiAgICAgICAg ICBUaGUgY2xpZW50IGNhbiByZXF1ZXN0IGFuIGFjY2VzcyB0b2tlbiB1c2luZyBvbmx5IGl0cyBj bGllbnQgY3JlZGVudGlhbHMgKG9yIG90aGVyCiAgICAgICAgICBzdXBwb3J0ZWQgbWVhbnMgb2Yg YXV0aGVudGljYXRpb24pIHdoZW4gdGhlIGNsaWVudCBpcyByZXF1ZXN0aW5nIGFjY2VzcyB0byB0 aGUKICAgICAgICAgIHByb3RlY3RlZCByZXNvdXJjZXMgdW5kZXIgaXRzIGNvbnRyb2wsIG9yIHRo b3NlIG9mIGFub3RoZXIgcmVzb3VyY2Ugb3duZXIgd2hpY2ggaGFzIGJlZW4KICAgICAgICAgIHBy ZXZpb3VzbHkgYXJyYW5nZWQgd2l0aCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgKHRoZSBtZXRo b2Qgb2Ygd2hpY2ggaXMgYmV5b25kIHRoZQogICAgICAgICAgc2NvcGUgb2YgdGhpcyBzcGVjaWZp Y2F0aW9uKS4KICAgICAgICA8L3Q+CiAgICAgICAgPHQ+CiAgICAgICAgICBUaGUgY2xpZW50IGNy ZWRlbnRpYWxzIGdyYW50IHR5cGUgTVVTVCBvbmx5IGJlIHVzZWQgYnkgY29uZmlkZW50aWFsIGNs aWVudHMuCiAgICAgICAgPC90PgogICAgICAgIDxmaWd1cmUgdGl0bGU9J0NsaWVudCBDcmVkZW50 aWFscyBGbG93JyBhbmNob3I9J0ZpZ3VyZS02Jz4KICAgICAgICAgIDxhcnR3b3JrPgogICAgICAg ICAgICA8IVtDREFUQVsKICArLS0tLS0tLS0tKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICArLS0tLS0tLS0tLS0tLS0tKwogIHwgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHwgICAgICAgICAgICAgICB8CiAgfCAgICAgICAgIHw+LS0oQSktIENsaWVu dCBBdXRoZW50aWNhdGlvbiAtLS0+fCBBdXRob3JpemF0aW9uIHwKICB8IENsaWVudCAgfCAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICBTZXJ2ZXIgICAgfAogIHwgICAgICAg ICB8PC0tKEIpLS0tLSBBY2Nlc3MgVG9rZW4gLS0tLS0tLS0tPHwgICAgICAgICAgICAgICB8CiAg fCAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAg ICAgIHwKICArLS0tLS0tLS0tKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0t LS0tLS0tLS0tLS0tKwpdXT4KICAgICAgICAgIDwvYXJ0d29yaz4KICAgICAgICA8L2ZpZ3VyZT4K ICAgICAgICA8dD4KICAgICAgICAgIFRoZSBmbG93IGlsbHVzdHJhdGVkIGluIDx4cmVmIHRhcmdl dD0nRmlndXJlLTYnIC8+IGluY2x1ZGVzIHRoZSBmb2xsb3dpbmcgc3RlcHM6CiAgICAgICAgPC90 PgogICAgICAgIDx0PgogICAgICAgICAgPGxpc3Qgc3R5bGU9J2Zvcm1hdCAoJUMpJz4KICAgICAg ICAgICAgPHQ+CiAgICAgICAgICAgICAgVGhlIGNsaWVudCBhdXRoZW50aWNhdGVzIHdpdGggdGhl IGF1dGhvcml6YXRpb24gc2VydmVyIGFuZCByZXF1ZXN0cyBhbiBhY2Nlc3MgdG9rZW4KICAgICAg ICAgICAgICBmcm9tIHRoZSB0b2tlbiBlbmRwb2ludC4KICAgICAgICAgICAgPC90PgogICAgICAg ICAgICA8dD4KICAgICAgICAgICAgICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYXV0aGVudGlj YXRlcyB0aGUgY2xpZW50LCBhbmQgaWYgdmFsaWQgaXNzdWVzIGFuIGFjY2VzcwogICAgICAgICAg ICAgIHRva2VuLgogICAgICAgICAgICA8L3Q+CiAgICAgICAgICA8L2xpc3Q+CiAgICAgICAgPC90 PgoKICAgICAgICA8c2VjdGlvbiB0aXRsZT0nQXV0aG9yaXphdGlvbiBSZXF1ZXN0IGFuZCBSZXNw b25zZScgYW5jaG9yPSJjbGllbnQtcmVxLXJlc3AiPgogICAgICAgICAgPHQ+CiAgICAgICAgICAg IFNpbmNlIHRoZSBjbGllbnQgYXV0aGVudGljYXRpb24gaXMgdXNlZCBhcyB0aGUgYXV0aG9yaXph dGlvbiBncmFudCwgbm8gYWRkaXRpb25hbAogICAgICAgICAgICBhdXRob3JpemF0aW9uIHJlcXVl c3QgaXMgbmVlZGVkLgogICAgICAgICAgPC90PgogICAgICAgIDwvc2VjdGlvbj4KCiAgICAgICAg PHNlY3Rpb24gdGl0bGU9J0FjY2VzcyBUb2tlbiBSZXF1ZXN0Jz4KICAgICAgICAgIDx0PgogICAg ICAgICAgICBUaGUgY2xpZW50IG1ha2VzIGEgcmVxdWVzdCB0byB0aGUgdG9rZW4gZW5kcG9pbnQg YnkgYWRkaW5nIHRoZSBmb2xsb3dpbmcgcGFyYW1ldGVycwogICAgICAgICAgICB1c2luZyB0aGUg PHNwYW54IHN0eWxlPSd2ZXJiJz5hcHBsaWNhdGlvbi94LXd3dy1mb3JtLXVybGVuY29kZWQ8L3Nw YW54PiBmb3JtYXQgaW4gdGhlCiAgICAgICAgICAgIEhUVFAgcmVxdWVzdCBlbnRpdHktYm9keToK ICAgICAgICAgIDwvdD4KICAgICAgICAgIDx0PgogICAgICAgICAgICA8bGlzdCBzdHlsZT0naGFu Z2luZycgaGFuZ0luZGVudD0nNic+CiAgICAgICAgICAgICAgPHQgaGFuZ1RleHQ9J2dyYW50X3R5 cGUnPgogICAgICAgICAgICAgICAgPHZzcGFjZSAvPgogICAgICAgICAgICAgICAgUkVRVUlSRUQu IFZhbHVlIE1VU1QgYmUgc2V0IHRvIDxzcGFueCBzdHlsZT0ndmVyYic+Y2xpZW50X2NyZWRlbnRp YWxzPC9zcGFueD4uCiAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICAgIDx0IGhhbmdUZXh0 PSdzY29wZSc+CiAgICAgICAgICAgICAgICA8dnNwYWNlIC8+CiAgICAgICAgICAgICAgICBPUFRJ T05BTC4gVGhlIHNjb3BlIG9mIHRoZSBhY2Nlc3MgcmVxdWVzdCBhcyBkZXNjcmliZWQgYnkgPHhy ZWYgdGFyZ2V0PSdzY29wZScgLz4uCiAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICA8L2xp c3Q+CiAgICAgICAgICA8L3Q+CiAgICAgICAgICA8dD4KICAgICAgICAgICAgVGhlIGNsaWVudCBN VVNUIGF1dGhlbnRpY2F0ZSB3aXRoIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBhcyBkZXNjcmli ZWQgaW4KICAgICAgICAgICAgPHhyZWYgdGFyZ2V0PSd0b2tlbi1lbmRwb2ludC1hdXRoJyAvPi4K ICAgICAgICAgIDwvdD4KICAgICAgICAgIDxmaWd1cmU+CiAgICAgICAgICAgIDxwcmVhbWJsZT4K ICAgICAgICAgICAgICBGb3IgZXhhbXBsZSwgdGhlIGNsaWVudCBtYWtlcyB0aGUgZm9sbG93aW5n IEhUVFAgcmVxdWVzdCB1c2luZyB0cmFuc3BvcnQtbGF5ZXIKICAgICAgICAgICAgICBzZWN1cml0 eSAoZXh0cmEgbGluZSBicmVha3MgYXJlIGZvciBkaXNwbGF5IHB1cnBvc2VzIG9ubHkpOgogICAg ICAgICAgICA8L3ByZWFtYmxlPgogICAgICAgICAgICA8YXJ0d29yaz4KICAgICAgICAgICAgICA8 IVtDREFUQVsKICBQT1NUIC90b2tlbiBIVFRQLzEuMQogIEhvc3Q6IHNlcnZlci5leGFtcGxlLmNv bQogIEF1dGhvcml6YXRpb246IEJhc2ljIGN6WkNhR1JTYTNGME16cG5XREZtUW1GME0ySlcKICBD b250ZW50LVR5cGU6IGFwcGxpY2F0aW9uL3gtd3d3LWZvcm0tdXJsZW5jb2RlZDtjaGFyc2V0PVVU Ri04CiAgCiAgZ3JhbnRfdHlwZT1jbGllbnRfY3JlZGVudGlhbHMKXV0+CiAgICAgICAgICAgIDwv YXJ0d29yaz4KICAgICAgICAgIDwvZmlndXJlPgogICAgICAgICAgPHQ+CiAgICAgICAgICAgIFRo ZSBhdXRob3JpemF0aW9uIHNlcnZlciBNVVNUIGF1dGhlbnRpY2F0ZSB0aGUgY2xpZW50LgogICAg ICAgICAgPC90PgogICAgICAgIDwvc2VjdGlvbj4KCiAgICAgICAgPHNlY3Rpb24gdGl0bGU9J0Fj Y2VzcyBUb2tlbiBSZXNwb25zZSc+CiAgICAgICAgICA8dD4KICAgICAgICAgICAgSWYgdGhlIGFj Y2VzcyB0b2tlbiByZXF1ZXN0IGlzIHZhbGlkIGFuZCBhdXRob3JpemVkLCB0aGUgYXV0aG9yaXph dGlvbiBzZXJ2ZXIgaXNzdWVzIGFuCiAgICAgICAgICAgIGFjY2VzcyB0b2tlbiBhcyBkZXNjcmli ZWQgaW4gPHhyZWYgdGFyZ2V0PSd0b2tlbi1yZXNwb25zZScgLz4uIEEgcmVmcmVzaCB0b2tlbiBT SE9VTEQKICAgICAgICAgICAgTk9UIGJlIGluY2x1ZGVkLiBJZiB0aGUgcmVxdWVzdCBmYWlsZWQg Y2xpZW50IGF1dGhlbnRpY2F0aW9uIG9yIGlzIGludmFsaWQsIHRoZQogICAgICAgICAgICBhdXRo b3JpemF0aW9uIHNlcnZlciByZXR1cm5zIGFuIGVycm9yIHJlc3BvbnNlIGFzIGRlc2NyaWJlZCBp bgogICAgICAgICAgICA8eHJlZiB0YXJnZXQ9J3Rva2VuLWVycm9ycycgLz4uCiAgICAgICAgICA8 L3Q+CiAgICAgICAgICA8ZmlndXJlPgogICAgICAgICAgICA8cHJlYW1ibGU+CiAgICAgICAgICAg ICAgQW4gZXhhbXBsZSBzdWNjZXNzZnVsIHJlc3BvbnNlOgogICAgICAgICAgICA8L3ByZWFtYmxl PgogICAgICAgICAgICA8YXJ0d29yaz4KICAgICAgICAgICAgICA8IVtDREFUQVsKICBIVFRQLzEu MSAyMDAgT0sKICBDb250ZW50LVR5cGU6IGFwcGxpY2F0aW9uL2pzb247Y2hhcnNldD1VVEYtOAog IENhY2hlLUNvbnRyb2w6IG5vLXN0b3JlCiAgUHJhZ21hOiBuby1jYWNoZQogIAogIHsKICAgICJh Y2Nlc3NfdG9rZW4iOiIyWW90bkZaRkVqcjF6Q3NpY01XcEFBIiwKICAgICJ0b2tlbl90eXBlIjoi ZXhhbXBsZSIsCiAgICAiZXhwaXJlc19pbiI6MzYwMCwKICAgICJleGFtcGxlX3BhcmFtZXRlciI6 ImV4YW1wbGVfdmFsdWUiCiAgfQpdXT4KICAgICAgICAgICAgPC9hcnR3b3JrPgogICAgICAgICAg PC9maWd1cmU+CiAgICAgICAgPC9zZWN0aW9uPgoKICAgICAgPC9zZWN0aW9uPgoKICAgICAgPHNl Y3Rpb24gdGl0bGU9J0V4dGVuc2lvbiBHcmFudHMnIGFuY2hvcj0iZXh0LWdyYW50Ij4KICAgICAg ICA8dD4KICAgICAgICAgIFRoZSBjbGllbnQgdXNlcyBhbiBleHRlbnNpb24gZ3JhbnQgdHlwZSBi eSBzcGVjaWZ5aW5nIHRoZSBncmFudCB0eXBlIHVzaW5nIGFuCiAgICAgICAgICBhYnNvbHV0ZSBV UkkgKGRlZmluZWQgYnkgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyKSBhcyB0aGUgdmFsdWUgb2Yg dGhlCiAgICAgICAgICA8c3Bhbnggc3R5bGU9J3ZlcmInPmdyYW50X3R5cGU8L3NwYW54PiBwYXJh bWV0ZXIgb2YgdGhlIHRva2VuIGVuZHBvaW50LCBhbmQgYnkKICAgICAgICAgIGFkZGluZyBhbnkg YWRkaXRpb25hbCBwYXJhbWV0ZXJzIG5lY2Vzc2FyeS4KICAgICAgICA8L3Q+CiAgICAgICAgPGZp Z3VyZT4KICAgICAgICAgIDxwcmVhbWJsZT4KICAgICAgICAgICAgRm9yIGV4YW1wbGUsIHRvIHJl cXVlc3QgYW4gYWNjZXNzIHRva2VuIHVzaW5nIGEgU0FNTCAyLjAgYXNzZXJ0aW9uIGdyYW50IHR5 cGUgYXMKICAgICAgICAgICAgZGVmaW5lZCBieSA8eHJlZiB0YXJnZXQ9J0ktRC5pZXRmLW9hdXRo LXNhbWwyLWJlYXJlcicgLz4sIHRoZSBjbGllbnQgbWFrZXMgdGhlCiAgICAgICAgICAgIGZvbGxv d2luZyBIVFRQIHJlcXVlc3QgdXNpbmcgVExTIChsaW5lIGJyZWFrcyBhcmUgZm9yIGRpc3BsYXkg cHVycG9zZXMgb25seSk6CiAgICAgICAgICA8L3ByZWFtYmxlPgogICAgICAgICAgPGFydHdvcms+ CiAgICAgICAgICAgIDwhW0NEQVRBWwogIFBPU1QgL3Rva2VuIEhUVFAvMS4xCiAgSG9zdDogc2Vy dmVyLmV4YW1wbGUuY29tCiAgQ29udGVudC1UeXBlOiBhcHBsaWNhdGlvbi94LXd3dy1mb3JtLXVy bGVuY29kZWQ7Y2hhcnNldD1VVEYtOAoKICBncmFudF90eXBlPXVybiUzQWlldGYlM0FwYXJhbXMl M0FvYXV0aCUzQWdyYW50LXR5cGUlM0FzYW1sMi0KICBiZWFyZXImYXNzZXJ0aW9uPVBFRnpjMlZ5 ZEdsdmJpQkpjM04xWlVsdWMzUmhiblE5SWpJd01URXRNRFUKICBbLi4ub21pdHRlZCBmb3IgYnJl dml0eS4uLl1hRzVUZEdGMFpXMWxiblEtUEM5QmMzTmxjblJwYjI0LQpdXT4KICAgICAgICAgIDwv YXJ0d29yaz4KICAgICAgICA8L2ZpZ3VyZT4KICAgICAgICA8dD4KICAgICAgICAgIElmIHRoZSBh Y2Nlc3MgdG9rZW4gcmVxdWVzdCBpcyB2YWxpZCBhbmQgYXV0aG9yaXplZCwgdGhlIGF1dGhvcml6 YXRpb24gc2VydmVyIGlzc3VlcyBhbgogICAgICAgICAgYWNjZXNzIHRva2VuIGFuZCBvcHRpb25h bCByZWZyZXNoIHRva2VuIGFzIGRlc2NyaWJlZCBpbiA8eHJlZiB0YXJnZXQ9J3Rva2VuLXJlc3Bv bnNlJyAvPi4KICAgICAgICAgIElmIHRoZSByZXF1ZXN0IGZhaWxlZCBjbGllbnQgYXV0aGVudGlj YXRpb24gb3IgaXMgaW52YWxpZCwgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHJldHVybnMKICAg ICAgICAgIGFuIGVycm9yIHJlc3BvbnNlIGFzIGRlc2NyaWJlZCBpbiA8eHJlZiB0YXJnZXQ9J3Rv a2VuLWVycm9ycycgLz4uCiAgICAgICAgPC90PgogICAgICA8L3NlY3Rpb24+CgogICAgPC9zZWN0 aW9uPgoKICAgIDxzZWN0aW9uIHRpdGxlPSdJc3N1aW5nIGFuIEFjY2VzcyBUb2tlbicgYW5jaG9y PSd0b2tlbi1pc3N1ZSc+CiAgICAgIDx0PgogICAgICAgIElmIHRoZSBhY2Nlc3MgdG9rZW4gcmVx dWVzdCBpcyB2YWxpZCBhbmQgYXV0aG9yaXplZCwgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGlz c3VlcyBhbgogICAgICAgIGFjY2VzcyB0b2tlbiBhbmQgb3B0aW9uYWwgcmVmcmVzaCB0b2tlbiBh cyBkZXNjcmliZWQgaW4gPHhyZWYgdGFyZ2V0PSd0b2tlbi1yZXNwb25zZScgLz4uCiAgICAgICAg SWYgdGhlIHJlcXVlc3QgZmFpbGVkIGNsaWVudCBhdXRoZW50aWNhdGlvbiBvciBpcyBpbnZhbGlk LCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgcmV0dXJucwogICAgICAgIGFuIGVycm9yIHJlc3Bv bnNlIGFzIGRlc2NyaWJlZCBpbiA8eHJlZiB0YXJnZXQ9J3Rva2VuLWVycm9ycycgLz4uCiAgICAg IDwvdD4KCiAgICAgIDxzZWN0aW9uIHRpdGxlPSdTdWNjZXNzZnVsIFJlc3BvbnNlJyBhbmNob3I9 J3Rva2VuLXJlc3BvbnNlJz4KICAgICAgICA8dD4KICAgICAgICAgIFRoZSBhdXRob3JpemF0aW9u IHNlcnZlciBpc3N1ZXMgYW4gYWNjZXNzIHRva2VuIGFuZCBvcHRpb25hbCByZWZyZXNoIHRva2Vu LCBhbmQKICAgICAgICAgIGNvbnN0cnVjdHMgdGhlIHJlc3BvbnNlIGJ5IGFkZGluZyB0aGUgZm9s bG93aW5nIHBhcmFtZXRlcnMgdG8gdGhlIGVudGl0eSBib2R5IG9mIHRoZSBIVFRQCiAgICAgICAg ICByZXNwb25zZSB3aXRoIGEgMjAwIChPSykgc3RhdHVzIGNvZGU6CiAgICAgICAgPC90PgogICAg ICAgIDx0PgogICAgICAgICAgPGxpc3Qgc3R5bGU9J2hhbmdpbmcnIGhhbmdJbmRlbnQ9JzYnPgog ICAgICAgICAgICA8dCBoYW5nVGV4dD0nYWNjZXNzX3Rva2VuJz4KICAgICAgICAgICAgICA8dnNw YWNlIC8+CiAgICAgICAgICAgICAgUkVRVUlSRUQuIFRoZSBhY2Nlc3MgdG9rZW4gaXNzdWVkIGJ5 IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlci4KICAgICAgICAgICAgPC90PgogICAgICAgICAgICA8 dCBoYW5nVGV4dD0ndG9rZW5fdHlwZSc+CiAgICAgICAgICAgICAgPHZzcGFjZSAvPgogICAgICAg ICAgICAgIFJFUVVJUkVELiBUaGUgdHlwZSBvZiB0aGUgdG9rZW4gaXNzdWVkIGFzIGRlc2NyaWJl ZCBpbiA8eHJlZiB0YXJnZXQ9J3Rva2VuLXR5cGVzJyAvPi4KICAgICAgICAgICAgICBWYWx1ZSBp cyBjYXNlIGluc2Vuc2l0aXZlLgogICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgIDx0IGhhbmdU ZXh0PSdleHBpcmVzX2luJz4KICAgICAgICAgICAgICA8dnNwYWNlIC8+CiAgICAgICAgICAgICAg UkVDT01NRU5ERUQuIFRoZSBsaWZldGltZSBpbiBzZWNvbmRzIG9mIHRoZSBhY2Nlc3MgdG9rZW4u IEZvciBleGFtcGxlLCB0aGUgdmFsdWUKICAgICAgICAgICAgICA8c3Bhbnggc3R5bGU9J3ZlcmIn PjM2MDA8L3NwYW54PiBkZW5vdGVzIHRoYXQgdGhlIGFjY2VzcyB0b2tlbiB3aWxsIGV4cGlyZSBp biBvbmUKICAgICAgICAgICAgICBob3VyIGZyb20gdGhlIHRpbWUgdGhlIHJlc3BvbnNlIHdhcyBn ZW5lcmF0ZWQuIElmIG9taXR0ZWQsIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlcgogICAgICAgICAg ICAgIFNIT1VMRCBwcm92aWRlIHRoZSBleHBpcmF0aW9uIHRpbWUgdmlhIG90aGVyIG1lYW5zIG9y IGRvY3VtZW50IHRoZSBkZWZhdWx0IHZhbHVlLgogICAgICAgICAgICA8L3Q+CiAgICAgICAgICAg IDx0IGhhbmdUZXh0PSdyZWZyZXNoX3Rva2VuJz4KICAgICAgICAgICAgICA8dnNwYWNlIC8+CiAg ICAgICAgICAgICAgT1BUSU9OQUwuIFRoZSByZWZyZXNoIHRva2VuIHdoaWNoIGNhbiBiZSB1c2Vk IHRvIG9idGFpbiBuZXcgYWNjZXNzIHRva2VucyB1c2luZyB0aGUKICAgICAgICAgICAgICBzYW1l IGF1dGhvcml6YXRpb24gZ3JhbnQgYXMgZGVzY3JpYmVkIGluIDx4cmVmIHRhcmdldD0ndG9rZW4t cmVmcmVzaCcgLz4uCiAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAgPHQgaGFuZ1RleHQ9J3Nj b3BlJz4KICAgICAgICAgICAgICA8dnNwYWNlIC8+CiAgICAgICAgICAgICAgT1BUSU9OQUwsIGlm IGlkZW50aWNhbCB0byB0aGUgc2NvcGUgcmVxdWVzdGVkIGJ5IHRoZSBjbGllbnQsIG90aGVyd2lz ZSBSRVFVSVJFRC4gVGhlCiAgICAgICAgICAgICAgc2NvcGUgb2YgdGhlIGFjY2VzcyB0b2tlbiBh cyBkZXNjcmliZWQgYnkgPHhyZWYgdGFyZ2V0PSdzY29wZScgLz4uCiAgICAgICAgICAgIDwvdD4K ICAgICAgICAgIDwvbGlzdD4KICAgICAgICA8L3Q+CiAgICAgICAgPHQ+CiAgICAgICAgICBUaGUg cGFyYW1ldGVycyBhcmUgaW5jbHVkZWQgaW4gdGhlIGVudGl0eSBib2R5IG9mIHRoZSBIVFRQIHJl c3BvbnNlIHVzaW5nIHRoZQogICAgICAgICAgPHNwYW54IHN0eWxlPSd2ZXJiJz5hcHBsaWNhdGlv bi9qc29uPC9zcGFueD4gbWVkaWEgdHlwZSBhcyBkZWZpbmVkIGJ5CiAgICAgICAgICA8eHJlZiB0 YXJnZXQ9J1JGQzQ2MjcnIC8+LiBUaGUgcGFyYW1ldGVycyBhcmUgc2VyaWFsaXplZCBpbnRvIGEg SlNPTiBzdHJ1Y3R1cmUgYnkKICAgICAgICAgIGFkZGluZyBlYWNoIHBhcmFtZXRlciBhdCB0aGUg aGlnaGVzdCBzdHJ1Y3R1cmUgbGV2ZWwuIFBhcmFtZXRlciBuYW1lcyBhbmQgc3RyaW5nIHZhbHVl cwogICAgICAgICAgYXJlIGluY2x1ZGVkIGFzIEpTT04gc3RyaW5ncy4gTnVtZXJpY2FsIHZhbHVl cyBhcmUgaW5jbHVkZWQgYXMgSlNPTiBudW1iZXJzLiBUaGUgb3JkZXIgb2YKICAgICAgICAgIHBh cmFtZXRlcnMgZG9lcyBub3QgbWF0dGVyIGFuZCBjYW4gdmFyeS4KICAgICAgICA8L3Q+CiAgICAg ICAgPHQ+CiAgICAgICAgICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVTVCBpbmNsdWRlIHRo ZSBIVFRQCiAgICAgICAgICA8c3Bhbnggc3R5bGU9J3ZlcmInPkNhY2hlLUNvbnRyb2w8L3NwYW54 PiByZXNwb25zZSBoZWFkZXIgZmllbGQgPHhyZWYgdGFyZ2V0PSdSRkMyNjE2JyAvPgogICAgICAg ICAgd2l0aCBhIHZhbHVlIG9mIDxzcGFueCBzdHlsZT0ndmVyYic+bm8tc3RvcmU8L3NwYW54PiBp biBhbnkgcmVzcG9uc2UgY29udGFpbmluZyB0b2tlbnMsCiAgICAgICAgICBjcmVkZW50aWFscywg b3Igb3RoZXIgc2Vuc2l0aXZlIGluZm9ybWF0aW9uLCBhcyB3ZWxsIGFzIHRoZQogICAgICAgICAg PHNwYW54IHN0eWxlPSd2ZXJiJz5QcmFnbWE8L3NwYW54PiByZXNwb25zZSBoZWFkZXIgZmllbGQg PHhyZWYgdGFyZ2V0PSdSRkMyNjE2JyAvPiB3aXRoIGEKICAgICAgICAgIHZhbHVlIG9mIDxzcGFu eCBzdHlsZT0ndmVyYic+bm8tY2FjaGU8L3NwYW54Pi4KICAgICAgICA8L3Q+CiAgICAgICAgPGZp Z3VyZT4KICAgICAgICAgIDxwcmVhbWJsZT4KICAgICAgICAgICAgRm9yIGV4YW1wbGU6CiAgICAg ICAgICA8L3ByZWFtYmxlPgogICAgICAgICAgPGFydHdvcms+CiAgICAgICAgICAgIDwhW0NEQVRB WwogIEhUVFAvMS4xIDIwMCBPSwogIENvbnRlbnQtVHlwZTogYXBwbGljYXRpb24vanNvbjtjaGFy c2V0PVVURi04CiAgQ2FjaGUtQ29udHJvbDogbm8tc3RvcmUKICBQcmFnbWE6IG5vLWNhY2hlCgog IHsKICAgICJhY2Nlc3NfdG9rZW4iOiIyWW90bkZaRkVqcjF6Q3NpY01XcEFBIiwKICAgICJ0b2tl bl90eXBlIjoiZXhhbXBsZSIsCiAgICAiZXhwaXJlc19pbiI6MzYwMCwKICAgICJyZWZyZXNoX3Rv a2VuIjoidEd6djNKT2tGMFhHNVF4MlRsS1dJQSIsCiAgICAiZXhhbXBsZV9wYXJhbWV0ZXIiOiJl eGFtcGxlX3ZhbHVlIgogIH0KXV0+CiAgICAgICAgICA8L2FydHdvcms+CiAgICAgICAgPC9maWd1 cmU+CiAgICAgICAgPHQ+CiAgICAgICAgICBUaGUgY2xpZW50IE1VU1QgaWdub3JlIHVucmVjb2du aXplZCB2YWx1ZSBuYW1lcyBpbiB0aGUgcmVzcG9uc2UuIFRoZSBzaXplcyBvZiB0b2tlbnMgYW5k CiAgICAgICAgICBvdGhlciB2YWx1ZXMgcmVjZWl2ZWQgZnJvbSB0aGUgYXV0aG9yaXphdGlvbiBz ZXJ2ZXIgYXJlIGxlZnQgdW5kZWZpbmVkLiBUaGUgY2xpZW50IHNob3VsZAogICAgICAgICAgYXZv aWQgbWFraW5nIGFzc3VtcHRpb25zIGFib3V0IHZhbHVlIHNpemVzLiBUaGUgYXV0aG9yaXphdGlv biBzZXJ2ZXIgU0hPVUxEIGRvY3VtZW50IHRoZQogICAgICAgICAgc2l6ZSBvZiBhbnkgdmFsdWUg aXQgaXNzdWVzLgogICAgICAgIDwvdD4KICAgICAgPC9zZWN0aW9uPgoKICAgICAgPHNlY3Rpb24g dGl0bGU9J0Vycm9yIFJlc3BvbnNlJyBhbmNob3I9J3Rva2VuLWVycm9ycyc+CiAgICAgICAgPHQ+ CiAgICAgICAgICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgcmVzcG9uZHMgd2l0aCBhbiBIVFRQ IDQwMCAoQmFkIFJlcXVlc3QpIHN0YXR1cyBjb2RlICh1bmxlc3MKICAgICAgICAgIHNwZWNpZmll ZCBvdGhlcndpc2UpIGFuZCBpbmNsdWRlcyB0aGUgZm9sbG93aW5nIHBhcmFtZXRlcnMgd2l0aCB0 aGUgcmVzcG9uc2U6CiAgICAgICAgPC90PgogICAgICAgIDx0PgogICAgICAgICAgPGxpc3Qgc3R5 bGU9J2hhbmdpbmcnIGhhbmdJbmRlbnQ9JzYnPgogICAgICAgICAgICA8dCBoYW5nVGV4dD0nZXJy b3InPgogICAgICAgICAgICAgIDx2c3BhY2UgLz4KICAgICAgICAgICAgICBSRVFVSVJFRC4gQSBz aW5nbGUgQVNDSUkgPHhyZWYgdGFyZ2V0PSJVU0FTQ0lJIiAvPiBlcnJvciBjb2RlIGZyb20gdGhl IGZvbGxvd2luZzoKCiAgICAgICAgICAgICAgPGxpc3Qgc3R5bGU9J2hhbmdpbmcnIGhhbmdJbmRl bnQ9JzYnPgogICAgICAgICAgICAgICAgPHQgaGFuZ1RleHQ9J2ludmFsaWRfcmVxdWVzdCc+CiAg ICAgICAgICAgICAgICAgIDx2c3BhY2UgLz4KICAgICAgICAgICAgICAgICAgVGhlIHJlcXVlc3Qg aXMgbWlzc2luZyBhIHJlcXVpcmVkIHBhcmFtZXRlciwgaW5jbHVkZXMgYW4gdW5zdXBwb3J0ZWQK ICAgICAgICAgICAgICAgICAgcGFyYW1ldGVyIHZhbHVlIChvdGhlciB0aGFuIGdyYW50IHR5cGUp LCByZXBlYXRzIGEgcGFyYW1ldGVyLCBpbmNsdWRlcyBtdWx0aXBsZQogICAgICAgICAgICAgICAg ICBjcmVkZW50aWFscywgdXRpbGl6ZXMgbW9yZSB0aGFuIG9uZSBtZWNoYW5pc20gZm9yIGF1dGhl bnRpY2F0aW5nIHRoZSBjbGllbnQsCiAgICAgICAgICAgICAgICAgIG9yIGlzIG90aGVyd2lzZSBt YWxmb3JtZWQuCiAgICAgICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgICAgICA8dCBoYW5nVGV4 dD0naW52YWxpZF9jbGllbnQnPgogICAgICAgICAgICAgICAgICA8dnNwYWNlIC8+CiAgICAgICAg ICAgICAgICAgIENsaWVudCBhdXRoZW50aWNhdGlvbiBmYWlsZWQgKGUuZy4gdW5rbm93biBjbGll bnQsIG5vIGNsaWVudCBhdXRoZW50aWNhdGlvbgogICAgICAgICAgICAgICAgICBpbmNsdWRlZCwg b3IgdW5zdXBwb3J0ZWQgYXV0aGVudGljYXRpb24gbWV0aG9kKS4gVGhlIGF1dGhvcml6YXRpb24g c2VydmVyIE1BWQogICAgICAgICAgICAgICAgICByZXR1cm4gYW4gSFRUUCA0MDEgKFVuYXV0aG9y aXplZCkgc3RhdHVzIGNvZGUgdG8gaW5kaWNhdGUgd2hpY2ggSFRUUAogICAgICAgICAgICAgICAg ICBhdXRoZW50aWNhdGlvbiBzY2hlbWVzIGFyZSBzdXBwb3J0ZWQuIElmIHRoZSBjbGllbnQgYXR0 ZW1wdGVkIHRvIGF1dGhlbnRpY2F0ZSB2aWEKICAgICAgICAgICAgICAgICAgdGhlIDxzcGFueCBz dHlsZT0ndmVyYic+QXV0aG9yaXphdGlvbjwvc3Bhbng+IHJlcXVlc3QgaGVhZGVyIGZpZWxkLAog ICAgICAgICAgICAgICAgICB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVTVCByZXNwb25kIHdp dGggYW4gSFRUUCA0MDEgKFVuYXV0aG9yaXplZCkgc3RhdHVzCiAgICAgICAgICAgICAgICAgIGNv ZGUsIGFuZCBpbmNsdWRlIHRoZSA8c3Bhbnggc3R5bGU9J3ZlcmInPldXVy1BdXRoZW50aWNhdGU8 L3NwYW54PiByZXNwb25zZQogICAgICAgICAgICAgICAgICBoZWFkZXIgZmllbGQgbWF0Y2hpbmcg dGhlIGF1dGhlbnRpY2F0aW9uIHNjaGVtZSB1c2VkIGJ5IHRoZSBjbGllbnQuCiAgICAgICAgICAg ICAgICA8L3Q+CiAgICAgICAgICAgICAgICA8dCBoYW5nVGV4dD0naW52YWxpZF9ncmFudCc+CiAg ICAgICAgICAgICAgICAgIDx2c3BhY2UgLz4KICAgICAgICAgICAgICAgICAgVGhlIHByb3ZpZGVk IGF1dGhvcml6YXRpb24gZ3JhbnQgKGUuZy4gYXV0aG9yaXphdGlvbiBjb2RlLCByZXNvdXJjZSBv d25lcgogICAgICAgICAgICAgICAgICBjcmVkZW50aWFscykgb3IgcmVmcmVzaCB0b2tlbiBpcyBp bnZhbGlkLCBleHBpcmVkLCByZXZva2VkLCBkb2VzIG5vdCBtYXRjaCB0aGUKICAgICAgICAgICAg ICAgICAgcmVkaXJlY3Rpb24gVVJJIHVzZWQgaW4gdGhlIGF1dGhvcml6YXRpb24gcmVxdWVzdCwg b3Igd2FzIGlzc3VlZCB0byBhbm90aGVyCiAgICAgICAgICAgICAgICAgIGNsaWVudC4KICAgICAg ICAgICAgICAgIDwvdD4KICAgICAgICAgICAgICAgIDx0IGhhbmdUZXh0PSd1bmF1dGhvcml6ZWRf Y2xpZW50Jz4KICAgICAgICAgICAgICAgICAgPHZzcGFjZSAvPgogICAgICAgICAgICAgICAgICBU aGUgYXV0aGVudGljYXRlZCBjbGllbnQgaXMgbm90IGF1dGhvcml6ZWQgdG8gdXNlIHRoaXMgYXV0 aG9yaXphdGlvbiBncmFudCB0eXBlLgogICAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICAg ICAgPHQgaGFuZ1RleHQ9J3Vuc3VwcG9ydGVkX2dyYW50X3R5cGUnPgogICAgICAgICAgICAgICAg ICA8dnNwYWNlIC8+CiAgICAgICAgICAgICAgICAgIFRoZSBhdXRob3JpemF0aW9uIGdyYW50IHR5 cGUgaXMgbm90IHN1cHBvcnRlZCBieSB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIuCiAgICAgICAg ICAgICAgICA8L3Q+CiAgICAgICAgICAgICAgICA8dCBoYW5nVGV4dD0naW52YWxpZF9zY29wZSc+ CiAgICAgICAgICAgICAgICAgIDx2c3BhY2UgLz4KICAgICAgICAgICAgICAgICAgVGhlIHJlcXVl c3RlZCBzY29wZSBpcyBpbnZhbGlkLCB1bmtub3duLCBtYWxmb3JtZWQsIG9yIGV4Y2VlZHMgdGhl IHNjb3BlIGdyYW50ZWQKICAgICAgICAgICAgICAgICAgYnkgdGhlIHJlc291cmNlIG93bmVyLgog ICAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICAgIDwvbGlzdD4KCgkgICAgICBWYWx1ZXMg Zm9yIHRoZSA8c3Bhbnggc3R5bGU9J3ZlcmInPmVycm9yPC9zcGFueD4gcGFyYW1ldGVyIE1VU1Qg Tk9UIGluY2x1ZGUKCSAgICAgIGNoYXJhY3RlcnMgb3V0c2lkZSB0aGUgc2V0ICV4MjAtMjEgLyAl eDIzLTVCIC8gJXg1RC03RS4KICAgICAgICAgICAgPC90PgogICAgICAgICAgICA8dCBoYW5nVGV4 dD0nZXJyb3JfZGVzY3JpcHRpb24nPgogICAgICAgICAgICAgIDx2c3BhY2UgLz4KICAgICAgICAg ICAgICBPUFRJT05BTC4gQSBodW1hbi1yZWFkYWJsZSBBU0NJSSA8eHJlZiB0YXJnZXQ9IlVTQVND SUkiIC8+IHRleHQgcHJvdmlkaW5nIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24sCiAgICAgICAgICAg ICAgdXNlZCB0byBhc3Npc3QgdGhlIGNsaWVudCBkZXZlbG9wZXIgaW4gdW5kZXJzdGFuZGluZyB0 aGUgZXJyb3IgdGhhdCBvY2N1cnJlZC4KCSAgICAgIDx2c3BhY2UvPgoJICAgICAgVmFsdWVzIGZv ciB0aGUgPHNwYW54IHN0eWxlPSd2ZXJiJz5lcnJvcl9kZXNjcmlwdGlvbjwvc3Bhbng+IHBhcmFt ZXRlciBNVVNUIE5PVCBpbmNsdWRlCgkgICAgICBjaGFyYWN0ZXJzIG91dHNpZGUgdGhlIHNldCAl eDIwLTIxIC8gJXgyMy01QiAvICV4NUQtN0UuCiAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAg PHQgaGFuZ1RleHQ9J2Vycm9yX3VyaSc+CiAgICAgICAgICAgICAgPHZzcGFjZSAvPgogICAgICAg ICAgICAgIE9QVElPTkFMLiBBIFVSSSBpZGVudGlmeWluZyBhIGh1bWFuLXJlYWRhYmxlIHdlYiBw YWdlIHdpdGggaW5mb3JtYXRpb24gYWJvdXQgdGhlCiAgICAgICAgICAgICAgZXJyb3IsIHVzZWQg dG8gcHJvdmlkZSB0aGUgY2xpZW50IGRldmVsb3BlciB3aXRoIGFkZGl0aW9uYWwgaW5mb3JtYXRp b24gYWJvdXQgdGhlCiAgICAgICAgICAgICAgZXJyb3IuCgkgICAgICA8dnNwYWNlLz4KCSAgICAg IFZhbHVlcyBmb3IgdGhlIDxzcGFueCBzdHlsZT0ndmVyYic+ZXJyb3JfdXJpPC9zcGFueD4gcGFy YW1ldGVyCgkgICAgICBNVVNUIGNvbmZvcm0gdG8gdGhlIFVSSS1SZWZlcmVuY2Ugc3ludGF4LCBh bmQgdGh1cyBNVVNUIE5PVCBpbmNsdWRlCgkgICAgICBjaGFyYWN0ZXJzIG91dHNpZGUgdGhlIHNl dCAleDIxIC8gJXgyMy01QiAvICV4NUQtN0UuCiAgICAgICAgICAgIDwvdD4KICAgICAgICAgIDwv bGlzdD4KICAgICAgICA8L3Q+CiAgICAgICAgPHQ+CiAgICAgICAgICBUaGUgcGFyYW1ldGVycyBh cmUgaW5jbHVkZWQgaW4gdGhlIGVudGl0eSBib2R5IG9mIHRoZSBIVFRQIHJlc3BvbnNlIHVzaW5n IHRoZQogICAgICAgICAgPHNwYW54IHN0eWxlPSd2ZXJiJz5hcHBsaWNhdGlvbi9qc29uPC9zcGFu eD4gbWVkaWEgdHlwZSBhcyBkZWZpbmVkIGJ5CiAgICAgICAgICA8eHJlZiB0YXJnZXQ9J1JGQzQ2 MjcnIC8+LiBUaGUgcGFyYW1ldGVycyBhcmUgc2VyaWFsaXplZCBpbnRvIGEgSlNPTiBzdHJ1Y3R1 cmUgYnkKICAgICAgICAgIGFkZGluZyBlYWNoIHBhcmFtZXRlciBhdCB0aGUgaGlnaGVzdCBzdHJ1 Y3R1cmUgbGV2ZWwuIFBhcmFtZXRlciBuYW1lcyBhbmQgc3RyaW5nIHZhbHVlcwogICAgICAgICAg YXJlIGluY2x1ZGVkIGFzIEpTT04gc3RyaW5ncy4gTnVtZXJpY2FsIHZhbHVlcyBhcmUgaW5jbHVk ZWQgYXMgSlNPTiBudW1iZXJzLiBUaGUgb3JkZXIgb2YKICAgICAgICAgIHBhcmFtZXRlcnMgZG9l cyBub3QgbWF0dGVyIGFuZCBjYW4gdmFyeS4KICAgICAgICA8L3Q+CiAgICAgICAgPGZpZ3VyZT4K ICAgICAgICAgIDxwcmVhbWJsZT4KICAgICAgICAgICAgRm9yIGV4YW1wbGU6CiAgICAgICAgICA8 L3ByZWFtYmxlPgogICAgICAgICAgPGFydHdvcms+CiAgICAgICAgICAgIDwhW0NEQVRBWwogIEhU VFAvMS4xIDQwMCBCYWQgUmVxdWVzdAogIENvbnRlbnQtVHlwZTogYXBwbGljYXRpb24vanNvbjtj aGFyc2V0PVVURi04CiAgQ2FjaGUtQ29udHJvbDogbm8tc3RvcmUKICBQcmFnbWE6IG5vLWNhY2hl CgogIHsKICAgICJlcnJvciI6ImludmFsaWRfcmVxdWVzdCIKICB9Cl1dPgogICAgICAgICAgPC9h cnR3b3JrPgogICAgICAgIDwvZmlndXJlPgogICAgICA8L3NlY3Rpb24+CgogICAgPC9zZWN0aW9u PgoKICAgIDxzZWN0aW9uIHRpdGxlPSdSZWZyZXNoaW5nIGFuIEFjY2VzcyBUb2tlbicgYW5jaG9y PSd0b2tlbi1yZWZyZXNoJz4KICAgICAgPHQ+CiAgICAgICAgSWYgdGhlIGF1dGhvcml6YXRpb24g c2VydmVyIGlzc3VlZCBhIHJlZnJlc2ggdG9rZW4gdG8gdGhlIGNsaWVudCwgdGhlIGNsaWVudCBt YWtlcyBhCiAgICAgICAgcmVmcmVzaCByZXF1ZXN0IHRvIHRoZSB0b2tlbiBlbmRwb2ludCBieSBh ZGRpbmcgdGhlIGZvbGxvd2luZyBwYXJhbWV0ZXJzIHVzaW5nIHRoZQogICAgICAgIDxzcGFueCBz dHlsZT0ndmVyYic+YXBwbGljYXRpb24veC13d3ctZm9ybS11cmxlbmNvZGVkPC9zcGFueD4gZm9y bWF0IGluIHRoZSBIVFRQIHJlcXVlc3QKICAgICAgICBlbnRpdHktYm9keToKICAgICAgPC90Pgog ICAgICA8dD4KICAgICAgICA8bGlzdCBzdHlsZT0naGFuZ2luZycgaGFuZ0luZGVudD0nNic+CiAg ICAgICAgICA8dCBoYW5nVGV4dD0nZ3JhbnRfdHlwZSc+CiAgICAgICAgICAgIDx2c3BhY2UgLz4K ICAgICAgICAgICAgUkVRVUlSRUQuIFZhbHVlIE1VU1QgYmUgc2V0IHRvIDxzcGFueCBzdHlsZT0n dmVyYic+cmVmcmVzaF90b2tlbjwvc3Bhbng+LgogICAgICAgICAgPC90PgogICAgICAgICAgPHQg aGFuZ1RleHQ9J3JlZnJlc2hfdG9rZW4nPgogICAgICAgICAgICA8dnNwYWNlIC8+CiAgICAgICAg ICAgIFJFUVVJUkVELiBUaGUgcmVmcmVzaCB0b2tlbiBpc3N1ZWQgdG8gdGhlIGNsaWVudC4KICAg ICAgICAgIDwvdD4KICAgICAgICAgIDx0IGhhbmdUZXh0PSdzY29wZSc+CiAgICAgICAgICAgIDx2 c3BhY2UgLz4KICAgICAgICAgICAgT1BUSU9OQUwuIFRoZSBzY29wZSBvZiB0aGUgYWNjZXNzIHJl cXVlc3QgYXMgZGVzY3JpYmVkIGJ5IDx4cmVmIHRhcmdldD0nc2NvcGUnIC8+LgogICAgICAgICAg ICBUaGUgcmVxdWVzdGVkIHNjb3BlIE1VU1QgTk9UIGluY2x1ZGUgYW55IHNjb3BlIG5vdCBvcmln aW5hbGx5IGdyYW50ZWQgYnkgdGhlIHJlc291cmNlCiAgICAgICAgICAgIG93bmVyLCBhbmQgaWYg b21pdHRlZCBpcyB0cmVhdGVkIGFzIGVxdWFsIHRvIHRoZSBzY29wZSBvcmlnaW5hbGx5IGdyYW50 ZWQgYnkgdGhlCiAgICAgICAgICAgIHJlc291cmNlIG93bmVyLgogICAgICAgICAgPC90PgogICAg ICAgIDwvbGlzdD4KICAgICAgPC90PgogICAgICA8dD4KICAgICAgICBCZWNhdXNlIHJlZnJlc2gg dG9rZW5zIGFyZSB0eXBpY2FsbHkgbG9uZy1sYXN0aW5nIGNyZWRlbnRpYWxzIHVzZWQgdG8gcmVx dWVzdCBhZGRpdGlvbmFsCiAgICAgICAgYWNjZXNzIHRva2VucywgdGhlIHJlZnJlc2ggdG9rZW4g aXMgYm91bmQgdG8gdGhlIGNsaWVudCB3aGljaCBpdCB3YXMgaXNzdWVkLiBJZiB0aGUgY2xpZW50 IHR5cGUKICAgICAgICBpcyBjb25maWRlbnRpYWwgb3IgdGhlIGNsaWVudCB3YXMgaXNzdWVkIGNs aWVudCBjcmVkZW50aWFscyAob3IgYXNzaWduZWQgb3RoZXIKICAgICAgICBhdXRoZW50aWNhdGlv biByZXF1aXJlbWVudHMpLCB0aGUgY2xpZW50IE1VU1QgYXV0aGVudGljYXRlIHdpdGggdGhlIGF1 dGhvcml6YXRpb24gc2VydmVyIGFzCiAgICAgICAgZGVzY3JpYmVkIGluIDx4cmVmIHRhcmdldD0n dG9rZW4tZW5kcG9pbnQtYXV0aCcgLz4uCiAgICAgIDwvdD4KICAgICAgPGZpZ3VyZT4KICAgICAg ICA8cHJlYW1ibGU+CiAgICAgICAgICBGb3IgZXhhbXBsZSwgdGhlIGNsaWVudCBtYWtlcyB0aGUg Zm9sbG93aW5nIEhUVFAgcmVxdWVzdCB1c2luZyB0cmFuc3BvcnQtbGF5ZXIKICAgICAgICAgIHNl Y3VyaXR5IChleHRyYSBsaW5lIGJyZWFrcyBhcmUgZm9yIGRpc3BsYXkgcHVycG9zZXMgb25seSk6 CiAgICAgICAgPC9wcmVhbWJsZT4KICAgICAgICA8YXJ0d29yaz4KICAgICAgICAgIDwhW0NEQVRB WwogIFBPU1QgL3Rva2VuIEhUVFAvMS4xCiAgSG9zdDogc2VydmVyLmV4YW1wbGUuY29tCiAgQXV0 aG9yaXphdGlvbjogQmFzaWMgY3paQ2FHUlNhM0YwTXpwbldERm1RbUYwTTJKVwogIENvbnRlbnQt VHlwZTogYXBwbGljYXRpb24veC13d3ctZm9ybS11cmxlbmNvZGVkO2NoYXJzZXQ9VVRGLTgKICAK ICBncmFudF90eXBlPXJlZnJlc2hfdG9rZW4mcmVmcmVzaF90b2tlbj10R3p2M0pPa0YwWEc1UXgy VGxLV0lBCl1dPgogICAgICAgIDwvYXJ0d29yaz4KICAgICAgPC9maWd1cmU+CiAgICAgIDx0Pgog ICAgICAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBNVVNUOgogICAgICA8L3Q+CiAgICAgIDx0 PgogICAgICAgIDxsaXN0IHN0eWxlPSdzeW1ib2xzJz4KICAgICAgICAgIDx0PgogICAgICAgICAg ICByZXF1aXJlIGNsaWVudCBhdXRoZW50aWNhdGlvbiBmb3IgY29uZmlkZW50aWFsIGNsaWVudHMg b3IgZm9yIGFueSBjbGllbnQgdGhhdCB3YXMKICAgICAgICAgICAgaXNzdWVkIGNsaWVudCBjcmVk ZW50aWFscyAob3Igd2l0aCBvdGhlciBhdXRoZW50aWNhdGlvbiByZXF1aXJlbWVudHMpLAogICAg ICAgICAgPC90PgogICAgICAgICAgPHQ+CiAgICAgICAgICAgIGF1dGhlbnRpY2F0ZSB0aGUgY2xp ZW50IGlmIGNsaWVudCBhdXRoZW50aWNhdGlvbiBpcyBpbmNsdWRlZCBhbmQgZW5zdXJlIHRoZQog ICAgICAgICAgICByZWZyZXNoIHRva2VuIHdhcyBpc3N1ZWQgdG8gdGhlIGF1dGhlbnRpY2F0ZWQg Y2xpZW50LCBhbmQKICAgICAgICAgIDwvdD4KICAgICAgICAgIDx0PgogICAgICAgICAgICB2YWxp ZGF0ZSB0aGUgcmVmcmVzaCB0b2tlbi4KICAgICAgICAgIDwvdD4KICAgICAgICA8L2xpc3Q+CiAg ICAgIDwvdD4KICAgICAgPHQ+CiAgICAgICAgSWYgdmFsaWQgYW5kIGF1dGhvcml6ZWQsIHRoZSBh dXRob3JpemF0aW9uIHNlcnZlciBpc3N1ZXMgYW4gYWNjZXNzIHRva2VuIGFzIGRlc2NyaWJlZCBp bgogICAgICAgIDx4cmVmIHRhcmdldD0ndG9rZW4tcmVzcG9uc2UnIC8+LiBJZiB0aGUgcmVxdWVz dCBmYWlsZWQgdmVyaWZpY2F0aW9uIG9yIGlzIGludmFsaWQsIHRoZQogICAgICAgIGF1dGhvcml6 YXRpb24gc2VydmVyIHJldHVybnMgYW4gZXJyb3IgcmVzcG9uc2UgYXMgZGVzY3JpYmVkIGluCiAg ICAgICAgPHhyZWYgdGFyZ2V0PSd0b2tlbi1lcnJvcnMnIC8+LgogICAgICA8L3Q+CiAgICAgIDx0 PgogICAgICAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBNQVkgaXNzdWUgYSBuZXcgcmVmcmVz aCB0b2tlbiwgaW4gd2hpY2ggY2FzZSB0aGUgY2xpZW50IE1VU1QKICAgICAgICBkaXNjYXJkIHRo ZSBvbGQgcmVmcmVzaCB0b2tlbiBhbmQgcmVwbGFjZSBpdCB3aXRoIHRoZSBuZXcgcmVmcmVzaCB0 b2tlbi4gVGhlIGF1dGhvcml6YXRpb24KICAgICAgICBzZXJ2ZXIgTUFZIHJldm9rZSB0aGUgb2xk IHJlZnJlc2ggdG9rZW4gYWZ0ZXIgaXNzdWluZyBhIG5ldyByZWZyZXNoIHRva2VuIHRvIHRoZSBj bGllbnQuIElmCiAgICAgICAgYSBuZXcgcmVmcmVzaCB0b2tlbiBpcyBpc3N1ZWQsIHRoZSByZWZy ZXNoIHRva2VuIHNjb3BlIE1VU1QgYmUgaWRlbnRpY2FsIHRvIHRoYXQgb2YgdGhlCiAgICAgICAg cmVmcmVzaCB0b2tlbiBpbmNsdWRlZCBieSB0aGUgY2xpZW50IGluIHRoZSByZXF1ZXN0LgogICAg ICA8L3Q+CiAgICA8L3NlY3Rpb24+CgogICAgPHNlY3Rpb24gdGl0bGU9J0FjY2Vzc2luZyBQcm90 ZWN0ZWQgUmVzb3VyY2VzJyBhbmNob3I9J2FjY2Vzcy1yZXNvdXJjZSc+CiAgICAgIDx0PgogICAg ICAgIFRoZSBjbGllbnQgYWNjZXNzZXMgcHJvdGVjdGVkIHJlc291cmNlcyBieSBwcmVzZW50aW5n IHRoZSBhY2Nlc3MgdG9rZW4gdG8gdGhlIHJlc291cmNlCiAgICAgICAgc2VydmVyLiBUaGUgcmVz b3VyY2Ugc2VydmVyIE1VU1QgdmFsaWRhdGUgdGhlIGFjY2VzcyB0b2tlbiBhbmQgZW5zdXJlIGl0 IGhhcyBub3QgZXhwaXJlZAogICAgICAgIGFuZCB0aGF0IGl0cyBzY29wZSBjb3ZlcnMgdGhlIHJl cXVlc3RlZCByZXNvdXJjZS4gVGhlIG1ldGhvZHMgdXNlZCBieSB0aGUgcmVzb3VyY2Ugc2VydmVy CiAgICAgICAgdG8gdmFsaWRhdGUgdGhlIGFjY2VzcyB0b2tlbiAoYXMgd2VsbCBhcyBhbnkgZXJy b3IgcmVzcG9uc2VzKSBhcmUgYmV5b25kIHRoZSBzY29wZSBvZiB0aGlzCiAgICAgICAgc3BlY2lm aWNhdGlvbiwgYnV0IGdlbmVyYWxseSBpbnZvbHZlIGFuIGludGVyYWN0aW9uIG9yIGNvb3JkaW5h dGlvbiBiZXR3ZWVuIHRoZSByZXNvdXJjZQogICAgICAgIHNlcnZlciBhbmQgdGhlIGF1dGhvcml6 YXRpb24gc2VydmVyLgogICAgICA8L3Q+CiAgICAgIDx0PgogICAgICAgIFRoZSBtZXRob2QgaW4g d2hpY2ggdGhlIGNsaWVudCB1dGlsaXplcyB0aGUgYWNjZXNzIHRva2VuIHRvIGF1dGhlbnRpY2F0 ZSB3aXRoIHRoZSByZXNvdXJjZQogICAgICAgIHNlcnZlciBkZXBlbmRzIG9uIHRoZSB0eXBlIG9m IGFjY2VzcyB0b2tlbiBpc3N1ZWQgYnkgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLiBUeXBpY2Fs bHksCiAgICAgICAgaXQgaW52b2x2ZXMgdXNpbmcgdGhlIEhUVFAgPHNwYW54IHN0eWxlPSd2ZXJi Jz5BdXRob3JpemF0aW9uPC9zcGFueD4gcmVxdWVzdCBoZWFkZXIgZmllbGQKICAgICAgICA8eHJl ZiB0YXJnZXQ9J1JGQzI2MTcnIC8+IHdpdGggYW4gYXV0aGVudGljYXRpb24gc2NoZW1lIGRlZmlu ZWQgYnkgdGhlIGFjY2VzcyB0b2tlbiB0eXBlCiAgICAgICAgc3BlY2lmaWNhdGlvbi4KICAgICAg PC90PgoKICAgICAgPHNlY3Rpb24gdGl0bGU9J0FjY2VzcyBUb2tlbiBUeXBlcycgYW5jaG9yPSd0 b2tlbi10eXBlcyc+CiAgICAgICAgPHQ+CiAgICAgICAgICBUaGUgYWNjZXNzIHRva2VuIHR5cGUg cHJvdmlkZXMgdGhlIGNsaWVudCB3aXRoIHRoZSBpbmZvcm1hdGlvbiByZXF1aXJlZCB0byBzdWNj ZXNzZnVsbHkKICAgICAgICAgIHV0aWxpemUgdGhlIGFjY2VzcyB0b2tlbiB0byBtYWtlIGEgcHJv dGVjdGVkIHJlc291cmNlIHJlcXVlc3QgKGFsb25nIHdpdGggdHlwZS1zcGVjaWZpYwogICAgICAg ICAgYXR0cmlidXRlcykuIFRoZSBjbGllbnQgTVVTVCBOT1QgdXNlIGFuIGFjY2VzcyB0b2tlbiBp ZiBpdCBkb2VzIG5vdCB1bmRlcnN0YW5kIHRoZSB0b2tlbgogICAgICAgICAgdHlwZS4KICAgICAg ICA8L3Q+CiAgICAgICAgPGZpZ3VyZT4KICAgICAgICAgIDxwcmVhbWJsZT4KICAgICAgICAgICAg Rm9yIGV4YW1wbGUsIHRoZSA8c3Bhbnggc3R5bGU9J3ZlcmInPmJlYXJlcjwvc3Bhbng+IHRva2Vu IHR5cGUgZGVmaW5lZCBpbgogICAgICAgICAgICA8eHJlZiB0YXJnZXQ9J0ktRC5pZXRmLW9hdXRo LXYyLWJlYXJlcicgLz4gaXMgdXRpbGl6ZWQgYnkgc2ltcGx5IGluY2x1ZGluZyB0aGUgYWNjZXNz CiAgICAgICAgICAgIHRva2VuIHN0cmluZyBpbiB0aGUgcmVxdWVzdDoKICAgICAgICAgIDwvcHJl YW1ibGU+CiAgICAgICAgICA8YXJ0d29yaz4KICAgICAgICAgICAgPCFbQ0RBVEFbCiAgR0VUIC9y ZXNvdXJjZS8xIEhUVFAvMS4xCiAgSG9zdDogZXhhbXBsZS5jb20KICBBdXRob3JpemF0aW9uOiBC ZWFyZXIgbUZfOS5CNWYtNC4xSnFNCl1dPgogICAgICAgICAgPC9hcnR3b3JrPgogICAgICAgIDwv ZmlndXJlPgogICAgICAgIDxmaWd1cmU+CiAgICAgICAgICA8cHJlYW1ibGU+CiAgICAgICAgICAg IHdoaWxlIHRoZSA8c3Bhbnggc3R5bGU9J3ZlcmInPm1hYzwvc3Bhbng+IHRva2VuIHR5cGUgZGVm aW5lZCBpbgogICAgICAgICAgICA8eHJlZiB0YXJnZXQ9J0ktRC5pZXRmLW9hdXRoLXYyLWh0dHAt bWFjJyAvPiBpcyB1dGlsaXplZCBieSBpc3N1aW5nIGEgTUFDIGtleQogICAgICAgICAgICB0b2dl dGhlciB3aXRoIHRoZSBhY2Nlc3MgdG9rZW4gd2hpY2ggaXMgdXNlZCB0byBzaWduIGNlcnRhaW4g Y29tcG9uZW50cyBvZiB0aGUgSFRUUAogICAgICAgICAgICByZXF1ZXN0czoKICAgICAgICAgIDwv cHJlYW1ibGU+CiAgICAgICAgICA8YXJ0d29yaz4KICAgICAgICAgICAgPCFbQ0RBVEFbCiAgR0VU IC9yZXNvdXJjZS8xIEhUVFAvMS4xCiAgSG9zdDogZXhhbXBsZS5jb20KICBBdXRob3JpemF0aW9u OiBNQUMgaWQ9Img0ODBkanM5M2hkOCIsCiAgICAgICAgICAgICAgICAgICAgIG5vbmNlPSIyNzQz MTI6ZGo4M2hzOXMiLAogICAgICAgICAgICAgICAgICAgICBtYWM9ImtEWnZkZGtuZHh2aEdSWFpo dnVEakVXaEdlRT0iCl1dPgogICAgICAgICAgPC9hcnR3b3JrPgogICAgICAgIDwvZmlndXJlPgog ICAgICAgIDx0PgogICAgICAgICAgVGhlIGFib3ZlIGV4YW1wbGVzIGFyZSBwcm92aWRlZCBmb3Ig aWxsdXN0cmF0aW9uIHB1cnBvc2VzIG9ubHkuIERldmVsb3BlcnMgYXJlIGFkdmlzZWQgdG8KICAg ICAgICAgIGNvbnN1bHQgdGhlIDx4cmVmIHRhcmdldD0nSS1ELmlldGYtb2F1dGgtdjItYmVhcmVy JyAvPiBhbmQKICAgICAgICAgIDx4cmVmIHRhcmdldD0nSS1ELmlldGYtb2F1dGgtdjItaHR0cC1t YWMnIC8+IHNwZWNpZmljYXRpb25zIGJlZm9yZSB1c2UuCiAgICAgICAgPC90PgogICAgICAgIDx0 PgogICAgICAgICAgRWFjaCBhY2Nlc3MgdG9rZW4gdHlwZSBkZWZpbml0aW9uIHNwZWNpZmllcyB0 aGUgYWRkaXRpb25hbCBhdHRyaWJ1dGVzIChpZiBhbnkpIHNlbnQgdG8KICAgICAgICAgIHRoZSBj bGllbnQgdG9nZXRoZXIgd2l0aCB0aGUgPHNwYW54IHN0eWxlPSd2ZXJiJz5hY2Nlc3NfdG9rZW48 L3NwYW54PiByZXNwb25zZSBwYXJhbWV0ZXIuCiAgICAgICAgICBJdCBhbHNvIGRlZmluZXMgdGhl IEhUVFAgYXV0aGVudGljYXRpb24gbWV0aG9kIHVzZWQgdG8gaW5jbHVkZSB0aGUgYWNjZXNzIHRv a2VuIHdoZW4KICAgICAgICAgIG1ha2luZyBhIHByb3RlY3RlZCByZXNvdXJjZSByZXF1ZXN0Lgog ICAgICAgIDwvdD4KICAgICAgPC9zZWN0aW9uPgoKICAgICAgPHNlY3Rpb24gdGl0bGU9J0Vycm9y IFJlc3BvbnNlJyBhbmNob3I9J3Jlc291cmNlLWVycm9ycyc+Cgk8dD4KCSAgSWYgYSByZXNvdXJj ZSBhY2Nlc3MgcmVxdWVzdCBmYWlscywgdGhlIHJlc291cmNlIHNlcnZlciBTSE9VTEQgaW5mb3Jt CgkgIHRoZSBjbGllbnQgb2YgdGhlIGVycm9yLiAgV2hpbGUgdGhlIHNwZWNpZmljIGVycm9yIHJl c3BvbnNlcyBwb3NzaWJsZQoJICBhbmQgbWV0aG9kcyBmb3IgdHJhbnNtaXR0aW5nIHRob3NlIGVy cm9ycyB3aGVuIHVzaW5nIGFueSBwYXJ0aWN1bGFyCgkgIGFjY2VzcyB0b2tlbiB0eXBlIGFyZSBi ZXlvbmQgdGhlIHNjb3BlIG9mIHRoaXMgc3BlY2lmaWNhdGlvbiwKCSAgYW55IDxzcGFueCBzdHls ZT0ndmVyYic+ZXJyb3I8L3NwYW54PiBjb2RlIHZhbHVlcyBkZWZpbmVkIGZvciB1c2Ugd2l0aAoJ ICBPQXV0aCByZXNvdXJjZSBhY2Nlc3MgbWV0aG9kcyBNVVNUIGJlIHJlZ2lzdGVyZWQKCSAgKGZv bGxvd2luZyB0aGUgcHJvY2VkdXJlcyBpbiA8eHJlZiB0YXJnZXQ9J2Vycm9yLXJlZ2lzdHJ5JyAv PikuCgk8L3Q+Cgk8dD4KCSAgU3BlY2lmaWNhbGx5LCB3aGVuIHRoZSBPQXV0aCByZXNvdXJjZSBh Y2Nlc3MgbWV0aG9kIHVzZXMgYW4KCSAgPHNwYW54IHN0eWxlPSd2ZXJiJz5lcnJvcjwvc3Bhbng+ IHJlc3VsdCBwYXJhbWV0ZXIgdG8gcmV0dXJuCgkgIGFuIGVycm9yIGNvZGUgdmFsdWUgdGhhdCBp bmRpY2F0ZXMgdGhlIHJlc291cmNlIGFjY2VzcyBlcnJvcgoJICBlbmNvdW50ZXJlZCwgdGhlbiB0 aGVzZSBlcnJvciBjb2RlIHZhbHVlcyBNVVNUIGJlIHJlZ2lzdGVyZWQuCgkgIFZhbHVlcyBmb3Ig dGhlc2UgPHNwYW54IHN0eWxlPSd2ZXJiJz5lcnJvcjwvc3Bhbng+IGNvZGVzIE1VU1QgTk9UIGlu Y2x1ZGUKCSAgY2hhcmFjdGVycyBvdXRzaWRlIHRoZSBzZXQgJXgyMC0yMSAvICV4MjMtNUIgLyAl eDVELTdFLgoJICBXaGVuIGFuICA8c3Bhbnggc3R5bGU9J3ZlcmInPmVycm9yPC9zcGFueD4gY29k ZSB2YWx1ZSBpcyByZWdpc3RlcmVkCgkgIGZvciB1c2UgYnkgYW4gT0F1dGggcmVzb3VyY2UgYWNj ZXNzIG1ldGhvZCwgc2hvdWxkIHRoYXQgc2FtZSBjb2RlIGFscmVhZHkKCSAgYmUgcmVnaXN0ZXJl ZCBmb3IgdXNlIGJ5IGFub3RoZXIgT0F1dGggcmVzb3VyY2UgYWNjZXNzIG1ldGhvZCBvciBhdAoJ ICBhIGRpZmZlcmVudCBPQXV0aCBlcnJvciB1c2FnZSBsb2NhdGlvbiwgdGhlbiB0aGUgbWVhbmlu ZyBvZiB0aGF0IGVycm9yIGNvZGUKCSAgdmFsdWUgaW4gaW4gdGhlIG5ldyByZWdpc3RyYXRpb24g TVVTVCBiZSBjb25zaXN0ZW50IHdpdGggdGhlIGl0cyBtZWFuaW5nCgkgIGluIHByaW9yIHJlZ2lz dHJhdGlvbnMuCgk8L3Q+Cgk8dD4KCSAgVGhlIE9BdXRoIHJlc291cmNlIGFjY2VzcyBlcnJvciBy ZWdpc3RyYXRpb24gcmVxdWlyZW1lbnQgYXBwbGllcyBvbmx5IHRvCgkgIDxzcGFueCBzdHlsZT0n dmVyYic+ZXJyb3I8L3NwYW54PiBjb2RlIHZhbHVlcyBhbmQgbm90IHRvIG90aGVyCgkgIG1lYW5z IG9mIHJldHVybmluZyBlcnJvciBpbmRpY2F0aW9ucywgaW5jbHVkaW5nIEhUVFAgc3RhdHVzIGNv ZGVzLAoJICBvciBvdGhlciBlcnJvci1yZWxhdGVkIHJlc3VsdCBwYXJhbWV0ZXJzLCBzdWNoIGFz CgkgIDxzcGFueCBzdHlsZT0ndmVyYic+ZXJyb3JfZGVzY3JpcHRpb248L3NwYW54PiwKCSAgPHNw YW54IHN0eWxlPSd2ZXJiJz5lcnJvcl91cmk8L3NwYW54Piwgb3Igb3RoZXIga2luZHMgb2YgZXJy b3IKCSAgc3RhdHVzIHJldHVybiBtZXRob2RzIHRoYXQgbWF5IGJlIGVtcGxveWVkIGJ5IHRoZSBy ZXNvdXJjZSBhY2Nlc3MgbWV0aG9kLgoJICBUaGVyZSBpcyBubyByZXF1aXJlbWVudCB0aGF0IE9B dXRoIHJlc291cmNlIGFjY2VzcyBtZXRob2RzCgkgIGVtcGxveSBhbiA8c3Bhbnggc3R5bGU9J3Zl cmInPmVycm9yPC9zcGFueD4gcGFyYW1ldGVyLgoJPC90PgogICAgICA8L3NlY3Rpb24+CgogICAg PC9zZWN0aW9uPgoKICAgIDxzZWN0aW9uIHRpdGxlPSdFeHRlbnNpYmlsaXR5JyBhbmNob3I9J2V4 dGVuc2lvbnMnPgoKICAgICAgPHNlY3Rpb24gdGl0bGU9J0RlZmluaW5nIEFjY2VzcyBUb2tlbiBU eXBlcycgYW5jaG9yPSduZXctdHlwZXMnPgogICAgICAgIDx0PgogICAgICAgICAgQWNjZXNzIHRv a2VuIHR5cGVzIGNhbiBiZSBkZWZpbmVkIGluIG9uZSBvZiB0d28gd2F5czogcmVnaXN0ZXJlZCBp biB0aGUgYWNjZXNzIHRva2VuIHR5cGUKICAgICAgICAgIHJlZ2lzdHJ5IChmb2xsb3dpbmcgdGhl IHByb2NlZHVyZXMgaW4gPHhyZWYgdGFyZ2V0PSd0eXBlLXJlZ2lzdHJ5JyAvPiksIG9yIGJ5IHVz aW5nIGEKICAgICAgICAgIHVuaXF1ZSBhYnNvbHV0ZSBVUkkgYXMgaXRzIG5hbWUuCiAgICAgICAg PC90PgogICAgICAgIDx0PgogICAgICAgICAgVHlwZXMgdXRpbGl6aW5nIGEgVVJJIG5hbWUgU0hP VUxEIGJlIGxpbWl0ZWQgdG8gdmVuZG9yLXNwZWNpZmljIGltcGxlbWVudGF0aW9ucyB0aGF0IGFy ZQogICAgICAgICAgbm90IGNvbW1vbmx5IGFwcGxpY2FibGUsIGFuZCBhcmUgc3BlY2lmaWMgdG8g dGhlIGltcGxlbWVudGF0aW9uIGRldGFpbHMgb2YgdGhlIHJlc291cmNlCiAgICAgICAgICBzZXJ2 ZXIgd2hlcmUgdGhleSBhcmUgdXNlZC4KICAgICAgICA8L3Q+CiAgICAgICAgPHQ+CiAgICAgICAg ICBBbGwgb3RoZXIgdHlwZXMgTVVTVCBiZSByZWdpc3RlcmVkLiBUeXBlIG5hbWVzIE1VU1QgY29u Zm9ybSB0byB0aGUgdHlwZS1uYW1lIEFCTkYuIElmIHRoZQogICAgICAgICAgdHlwZSBkZWZpbml0 aW9uIGluY2x1ZGVzIGEgbmV3IEhUVFAgYXV0aGVudGljYXRpb24gc2NoZW1lLCB0aGUgdHlwZSBu YW1lIFNIT1VMRCBiZQogICAgICAgICAgaWRlbnRpY2FsIHRvIHRoZSBIVFRQIGF1dGhlbnRpY2F0 aW9uIHNjaGVtZSBuYW1lIChhcyBkZWZpbmVkIGJ5IDx4cmVmIHRhcmdldD0nUkZDMjYxNycgLz4p LgogICAgICAgICAgVGhlIHRva2VuIHR5cGUgPHNwYW54IHN0eWxlPSd2ZXJiJz5leGFtcGxlPC9z cGFueD4gaXMgcmVzZXJ2ZWQgZm9yIHVzZSBpbiBleGFtcGxlcy4KICAgICAgICA8L3Q+CiAgICAg ICAgPGZpZ3VyZT4KICAgICAgICAgIDxhcnR3b3JrPgogICAgICAgICAgICA8IVtDREFUQVsKICB0 eXBlLW5hbWUgID0gMSpuYW1lLWNoYXIKICBuYW1lLWNoYXIgID0gIi0iIC8gIi4iIC8gIl8iIC8g RElHSVQgLyBBTFBIQQpdXT4KICAgICAgICAgIDwvYXJ0d29yaz4KICAgICAgICA8L2ZpZ3VyZT4K ICAgICAgPC9zZWN0aW9uPgoKICAgICAgPHNlY3Rpb24gdGl0bGU9J0RlZmluaW5nIE5ldyBFbmRw b2ludCBQYXJhbWV0ZXJzJyBhbmNob3I9ImVuZHBvaW50LXBhcmFtcyI+CiAgICAgICAgPHQ+CiAg ICAgICAgICBOZXcgcmVxdWVzdCBvciByZXNwb25zZSBwYXJhbWV0ZXJzIGZvciB1c2Ugd2l0aCB0 aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludCBvciB0aGUgdG9rZW4KICAgICAgICAgIGVuZHBvaW50 IGFyZSBkZWZpbmVkIGFuZCByZWdpc3RlcmVkIGluIHRoZSBwYXJhbWV0ZXJzIHJlZ2lzdHJ5IGZv bGxvd2luZyB0aGUgcHJvY2VkdXJlIGluCiAgICAgICAgICA8eHJlZiB0YXJnZXQ9J3BhcmFtZXRl cnMtcmVnaXN0cnknIC8+LgogICAgICAgIDwvdD4KICAgICAgICA8dD4KICAgICAgICAgIFBhcmFt ZXRlciBuYW1lcyBNVVNUIGNvbmZvcm0gdG8gdGhlIHBhcmFtLW5hbWUgQUJORiBhbmQgcGFyYW1l dGVyIHZhbHVlcyBzeW50YXggTVVTVCBiZQogICAgICAgICAgd2VsbC1kZWZpbmVkIChlLmcuLCB1 c2luZyBBQk5GLCBvciBhIHJlZmVyZW5jZSB0byB0aGUgc3ludGF4IG9mIGFuIGV4aXN0aW5nIHBh cmFtZXRlcikuCiAgICAgICAgPC90PgogICAgICAgIDxmaWd1cmU+CiAgICAgICAgICA8YXJ0d29y az4KICAgICAgICAgICAgPCFbQ0RBVEFbCiAgcGFyYW0tbmFtZSAgPSAxKm5hbWUtY2hhcgogIG5h bWUtY2hhciAgID0gIi0iIC8gIi4iIC8gIl8iIC8gRElHSVQgLyBBTFBIQQpdXT4KICAgICAgICAg IDwvYXJ0d29yaz4KICAgICAgICA8L2ZpZ3VyZT4KICAgICAgICA8dD4KICAgICAgICAgIFVucmVn aXN0ZXJlZCB2ZW5kb3Itc3BlY2lmaWMgcGFyYW1ldGVyIGV4dGVuc2lvbnMgdGhhdCBhcmUgbm90 IGNvbW1vbmx5IGFwcGxpY2FibGUsIGFuZAogICAgICAgICAgYXJlIHNwZWNpZmljIHRvIHRoZSBp bXBsZW1lbnRhdGlvbiBkZXRhaWxzIG9mIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciB3aGVyZSB0 aGV5IGFyZQogICAgICAgICAgdXNlZCBTSE9VTEQgdXRpbGl6ZSBhIHZlbmRvci1zcGVjaWZpYyBw cmVmaXggdGhhdCBpcyBub3QgbGlrZWx5IHRvIGNvbmZsaWN0IHdpdGggb3RoZXIKICAgICAgICAg IHJlZ2lzdGVyZWQgdmFsdWVzIChlLmcuIGJlZ2luIHdpdGggJ2NvbXBhbnluYW1lXycpLgogICAg ICAgIDwvdD4KICAgICAgPC9zZWN0aW9uPgoKICAgICAgPHNlY3Rpb24gdGl0bGU9J0RlZmluaW5n IE5ldyBBdXRob3JpemF0aW9uIEdyYW50IFR5cGVzJz4KICAgICAgICA8dD4KICAgICAgICAgIE5l dyBhdXRob3JpemF0aW9uIGdyYW50IHR5cGVzIGNhbiBiZSBkZWZpbmVkIGJ5IGFzc2lnbmluZyB0 aGVtIGEgdW5pcXVlIGFic29sdXRlIFVSSSBmb3IKICAgICAgICAgIHVzZSB3aXRoIHRoZSA8c3Bh bnggc3R5bGU9J3ZlcmInPmdyYW50X3R5cGU8L3NwYW54PiBwYXJhbWV0ZXIuIElmIHRoZSBleHRl bnNpb24gZ3JhbnQKICAgICAgICAgIHR5cGUgcmVxdWlyZXMgYWRkaXRpb25hbCB0b2tlbiBlbmRw b2ludCBwYXJhbWV0ZXJzLCB0aGV5IE1VU1QgYmUgcmVnaXN0ZXJlZCBpbiB0aGUgT0F1dGgKICAg ICAgICAgIHBhcmFtZXRlcnMgcmVnaXN0cnkgYXMgZGVzY3JpYmVkIGJ5IDx4cmVmIHRhcmdldD0n cGFyYW1ldGVycy1yZWdpc3RyeScgLz4uCiAgICAgICAgPC90PgogICAgICA8L3NlY3Rpb24+Cgog ICAgICA8c2VjdGlvbiB0aXRsZT0nRGVmaW5pbmcgTmV3IEF1dGhvcml6YXRpb24gRW5kcG9pbnQg UmVzcG9uc2UgVHlwZXMnIGFuY2hvcj0ncmVzcG9uc2UtdHlwZS1leHQnPgogICAgICAgIDx0Pgog ICAgICAgICAgTmV3IHJlc3BvbnNlIHR5cGVzIGZvciB1c2Ugd2l0aCB0aGUgYXV0aG9yaXphdGlv biBlbmRwb2ludCBhcmUgZGVmaW5lZCBhbmQgcmVnaXN0ZXJlZCBpbgogICAgICAgICAgdGhlIGF1 dGhvcml6YXRpb24gZW5kcG9pbnQgcmVzcG9uc2UgdHlwZSByZWdpc3RyeSBmb2xsb3dpbmcgdGhl IHByb2NlZHVyZSBpbgogICAgICAgICAgPHhyZWYgdGFyZ2V0PSdyZXNwb25zZS10eXBlLXJlZ2lz dHJ5JyAvPi4gUmVzcG9uc2UgdHlwZSBuYW1lcyBNVVNUIGNvbmZvcm0gdG8gdGhlCiAgICAgICAg ICByZXNwb25zZS10eXBlIEFCTkYuCiAgICAgICAgPC90PgogICAgICAgIDxmaWd1cmU+CiAgICAg ICAgICA8YXJ0d29yaz4KICAgICAgICAgICAgPCFbQ0RBVEFbCiAgcmVzcG9uc2UtdHlwZSAgPSBy ZXNwb25zZS1uYW1lICooIFNQIHJlc3BvbnNlLW5hbWUgKQogIHJlc3BvbnNlLW5hbWUgID0gMSpy ZXNwb25zZS1jaGFyCiAgcmVzcG9uc2UtY2hhciAgPSAiXyIgLyBESUdJVCAvIEFMUEhBCl1dPgog ICAgICAgICAgPC9hcnR3b3JrPgogICAgICAgIDwvZmlndXJlPgogICAgICAgIDx0PgogICAgICAg ICAgSWYgYSByZXNwb25zZSB0eXBlIGNvbnRhaW5zIG9uZSBvciBtb3JlIHNwYWNlIGNoYXJhY3Rl cnMgKCV4MjApLCBpdCBpcyBjb21wYXJlZCBhcyBhCiAgICAgICAgICBzcGFjZS1kZWxpbWl0ZWQg bGlzdCBvZiB2YWx1ZXMgaW4gd2hpY2ggdGhlIG9yZGVyIG9mIHZhbHVlcyBkb2VzIG5vdCBtYXR0 ZXIuIE9ubHkgb25lCiAgICAgICAgICBvcmRlciBvZiB2YWx1ZXMgY2FuIGJlIHJlZ2lzdGVyZWQs IHdoaWNoIGNvdmVycyBhbGwgb3RoZXIgYXJyYW5nZW1lbnRzIG9mIHRoZSBzYW1lIHNldCBvZgog ICAgICAgICAgdmFsdWVzLgogICAgICAgIDwvdD4KICAgICAgICA8dD4KICAgICAgICAgIEZvciBl eGFtcGxlLCB0aGUgcmVzcG9uc2UgdHlwZSA8c3Bhbnggc3R5bGU9J3ZlcmInPnRva2VuIGNvZGU8 L3NwYW54PiBpcyBsZWZ0IHVuZGVmaW5lZAogICAgICAgICAgYnkgdGhpcyBzcGVjaWZpY2F0aW9u LiBIb3dldmVyLCBhbiBleHRlbnNpb24gY2FuIGRlZmluZSBhbmQgcmVnaXN0ZXIgdGhlCiAgICAg ICAgICA8c3Bhbnggc3R5bGU9J3ZlcmInPnRva2VuIGNvZGU8L3NwYW54PiByZXNwb25zZSB0eXBl LiBPbmNlIHJlZ2lzdGVyZWQsIHRoZSBzYW1lCiAgICAgICAgICBjb21iaW5hdGlvbiBjYW5ub3Qg YmUgcmVnaXN0ZXJlZCBhcyA8c3Bhbnggc3R5bGU9J3ZlcmInPmNvZGUgdG9rZW48L3NwYW54Piwg YnV0IGJvdGgKICAgICAgICAgIHZhbHVlcyBjYW4gYmUgdXNlZCB0byBkZW5vdGUgdGhlIHNhbWUg cmVzcG9uc2UgdHlwZS4KICAgICAgICA8L3Q+CiAgICAgIDwvc2VjdGlvbj4KCiAgICAgIDxzZWN0 aW9uIHRpdGxlPSdEZWZpbmluZyBBZGRpdGlvbmFsIEVycm9yIENvZGVzJyBhbmNob3I9J25ldy1l cnJvcnMnPgogICAgICAgIDx0PgogICAgICAgICAgSW4gY2FzZXMgd2hlcmUgcHJvdG9jb2wgZXh0 ZW5zaW9ucyAoaS5lLiBhY2Nlc3MgdG9rZW4gdHlwZXMsIGV4dGVuc2lvbiBwYXJhbWV0ZXJzLCBv cgogICAgICAgICAgZXh0ZW5zaW9uIGdyYW50IHR5cGVzKSByZXF1aXJlIGFkZGl0aW9uYWwgZXJy b3IgY29kZXMgdG8gYmUgdXNlZCB3aXRoIHRoZSBhdXRob3JpemF0aW9uCiAgICAgICAgICBjb2Rl IGdyYW50IGVycm9yIHJlc3BvbnNlICg8eHJlZiB0YXJnZXQ9J2NvZGUtYXV0aHotZXJyb3InIC8+ KSwgdGhlIGltcGxpY2l0IGdyYW50IGVycm9yCiAgICAgICAgICByZXNwb25zZSAoPHhyZWYgdGFy Z2V0PSdpbXBsaWNpdC1hdXRoei1lcnJvcicgLz4pLCB0aGUgdG9rZW4gZXJyb3IgcmVzcG9uc2UK ICAgICAgICAgICg8eHJlZiB0YXJnZXQ9J3Rva2VuLWVycm9ycycgLz4pLAoJICBvciB0aGUgcmVz b3VyY2UgYWNjZXNzIGVycm9yIHJlc3BvbnNlICg8eHJlZiB0YXJnZXQ9J3Jlc291cmNlLWVycm9y cycgLz4pLAoJICBzdWNoIGVycm9yIGNvZGVzIE1BWSBiZSBkZWZpbmVkLgogICAgICAgIDwvdD4K ICAgICAgICA8dD4KICAgICAgICAgIEV4dGVuc2lvbiBlcnJvciBjb2RlcyBNVVNUIGJlIHJlZ2lz dGVyZWQgKGZvbGxvd2luZyB0aGUgcHJvY2VkdXJlcyBpbgogICAgICAgICAgPHhyZWYgdGFyZ2V0 PSdlcnJvci1yZWdpc3RyeScgLz4pIGlmIHRoZSBleHRlbnNpb24gdGhleSBhcmUgdXNlZCBpbiBj b25qdW5jdGlvbiB3aXRoIGlzCiAgICAgICAgICBhIHJlZ2lzdGVyZWQgYWNjZXNzIHRva2VuIHR5 cGUsIGEgcmVnaXN0ZXJlZCBlbmRwb2ludCBwYXJhbWV0ZXIsIG9yIGFuIGV4dGVuc2lvbiBncmFu dAogICAgICAgICAgdHlwZS4gRXJyb3IgY29kZXMgdXNlZCB3aXRoIHVucmVnaXN0ZXJlZCBleHRl bnNpb25zIE1BWSBiZSByZWdpc3RlcmVkLgogICAgICAgIDwvdD4KICAgICAgICA8dD4KICAgICAg ICAgIEVycm9yIGNvZGVzIE1VU1QgY29uZm9ybSB0byB0aGUgZXJyb3IgQUJORiwgYW5kIFNIT1VM RCBiZSBwcmVmaXhlZCBieSBhbiBpZGVudGlmeWluZwogICAgICAgICAgbmFtZSB3aGVuIHBvc3Np YmxlLiBGb3IgZXhhbXBsZSwgYW4gZXJyb3IgaWRlbnRpZnlpbmcgYW4gaW52YWxpZCB2YWx1ZSBz ZXQgdG8gdGhlCiAgICAgICAgICBleHRlbnNpb24gcGFyYW1ldGVyIDxzcGFueCBzdHlsZT0ndmVy Yic+ZXhhbXBsZTwvc3Bhbng+IFNIT1VMRCBiZSBuYW1lZAogICAgICAgICAgPHNwYW54IHN0eWxl PSd2ZXJiJz5leGFtcGxlX2ludmFsaWQ8L3NwYW54Pi4KICAgICAgICA8L3Q+CiAgICAgICAgPGZp Z3VyZT4KICAgICAgICAgIDxhcnR3b3JrPgogICAgICAgICAgICA8IVtDREFUQVsKICBlcnJvciAg ICAgID0gMSplcnJvci1jaGFyCiAgZXJyb3ItY2hhciA9ICV4MjAtMjEgLyAleDIzLTVCIC8gJXg1 RC03RQpdXT4KICAgICAgICAgIDwvYXJ0d29yaz4KICAgICAgICA8L2ZpZ3VyZT4KICAgICAgPC9z ZWN0aW9uPgoKICAgIDwvc2VjdGlvbj4KCiAgICA8c2VjdGlvbiB0aXRsZT0nTmF0aXZlIEFwcGxp Y2F0aW9ucyc+CiAgICAgIDx0PgogICAgICAgIE5hdGl2ZSBhcHBsaWNhdGlvbnMgYXJlIGNsaWVu dHMgaW5zdGFsbGVkIGFuZCBleGVjdXRlZCBvbiB0aGUgZGV2aWNlIHVzZWQgYnkgdGhlIHJlc291 cmNlCiAgICAgICAgb3duZXIgKGkuZS4gZGVza3RvcCBhcHBsaWNhdGlvbiwgbmF0aXZlIG1vYmls ZSBhcHBsaWNhdGlvbikuIE5hdGl2ZSBhcHBsaWNhdGlvbnMgcmVxdWlyZQogICAgICAgIHNwZWNp YWwgY29uc2lkZXJhdGlvbiByZWxhdGVkIHRvIHNlY3VyaXR5LCBwbGF0Zm9ybSBjYXBhYmlsaXRp ZXMsIGFuZCBvdmVyYWxsIGVuZC11c2VyCiAgICAgICAgZXhwZXJpZW5jZS4KICAgICAgPC90Pgog ICAgICA8dD4KICAgICAgICBUaGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludCByZXF1aXJlcyBpbnRl cmFjdGlvbiBiZXR3ZWVuIHRoZSBjbGllbnQgYW5kIHRoZSByZXNvdXJjZQogICAgICAgIG93bmVy J3MgdXNlci1hZ2VudC4gTmF0aXZlIGFwcGxpY2F0aW9ucyBjYW4gaW52b2tlIGFuIGV4dGVybmFs IHVzZXItYWdlbnQgb3IgZW1iZWQgYQogICAgICAgIHVzZXItYWdlbnQgd2l0aGluIHRoZSBhcHBs aWNhdGlvbi4gRm9yIGV4YW1wbGU6CiAgICAgIDwvdD4KICAgICAgPHQ+CiAgICAgICAgPGxpc3Qg c3R5bGU9J3N5bWJvbHMnPgogICAgICAgICAgPHQ+CiAgICAgICAgICAgIEV4dGVybmFsIHVzZXIt YWdlbnQgLSB0aGUgbmF0aXZlIGFwcGxpY2F0aW9uIGNhbiBjYXB0dXJlIHRoZSByZXNwb25zZSBm cm9tIHRoZQogICAgICAgICAgICBhdXRob3JpemF0aW9uIHNlcnZlciB1c2luZyBhIHJlZGlyZWN0 aW9uIFVSSSB3aXRoIGEgc2NoZW1lIHJlZ2lzdGVyZWQgd2l0aCB0aGUKICAgICAgICAgICAgb3Bl cmF0aW5nIHN5c3RlbSB0byBpbnZva2UgdGhlIGNsaWVudCBhcyB0aGUgaGFuZGxlciwgbWFudWFs IGNvcHktYW5kLXBhc3RlIG9mIHRoZQogICAgICAgICAgICBjcmVkZW50aWFscywgcnVubmluZyBh IGxvY2FsIHdlYiBzZXJ2ZXIsIGluc3RhbGxpbmcgYSB1c2VyLWFnZW50IGV4dGVuc2lvbiwgb3Ig YnkKICAgICAgICAgICAgcHJvdmlkaW5nIGEgcmVkaXJlY3Rpb24gVVJJIGlkZW50aWZ5aW5nIGEg c2VydmVyLWhvc3RlZCByZXNvdXJjZSB1bmRlciB0aGUgY2xpZW50J3MKICAgICAgICAgICAgY29u dHJvbCwgd2hpY2ggaW4gdHVybiBtYWtlcyB0aGUgcmVzcG9uc2UgYXZhaWxhYmxlIHRvIHRoZSBu YXRpdmUgYXBwbGljYXRpb24uCiAgICAgICAgICA8L3Q+CiAgICAgICAgICA8dD4KICAgICAgICAg ICAgRW1iZWRkZWQgdXNlci1hZ2VudCAtIHRoZSBuYXRpdmUgYXBwbGljYXRpb24gb2J0YWlucyB0 aGUgcmVzcG9uc2UgYnkgZGlyZWN0bHkKICAgICAgICAgICAgY29tbXVuaWNhdGluZyB3aXRoIHRo ZSBlbWJlZGRlZCB1c2VyLWFnZW50IGJ5IG1vbml0b3Jpbmcgc3RhdGUgY2hhbmdlcyBlbWl0dGVk IGR1cmluZwogICAgICAgICAgICB0aGUgcmVzb3VyY2UgbG9hZCwgb3IgYWNjZXNzaW5nIHRoZSB1 c2VyLWFnZW50J3MgY29va2llcyBzdG9yYWdlLgogICAgICAgICAgPC90PgogICAgICAgIDwvbGlz dD4KICAgICAgPC90PgogICAgICA8dD4KICAgICAgICBXaGVuIGNob29zaW5nIGJldHdlZW4gYW4g ZXh0ZXJuYWwgb3IgZW1iZWRkZWQgdXNlci1hZ2VudCwgZGV2ZWxvcGVycyBzaG91bGQgY29uc2lk ZXI6CiAgICAgIDwvdD4KICAgICAgPHQ+CiAgICAgICAgPGxpc3Qgc3R5bGU9J3N5bWJvbHMnPgog ICAgICAgICAgPHQ+CiAgICAgICAgICAgIEFuIEV4dGVybmFsIHVzZXItYWdlbnQgbWF5IGltcHJv dmUgY29tcGxldGlvbiByYXRlIGFzIHRoZSByZXNvdXJjZSBvd25lciBtYXkgYWxyZWFkeSBoYXZl CiAgICAgICAgICAgIGFuIGFjdGl2ZSBzZXNzaW9uIHdpdGggdGhlIGF1dGhvcml6YXRpb24gc2Vy dmVyIHJlbW92aW5nIHRoZSBuZWVkIHRvIHJlLWF1dGhlbnRpY2F0ZS4gSXQKICAgICAgICAgICAg cHJvdmlkZXMgYSBmYW1pbGlhciBlbmQtdXNlciBleHBlcmllbmNlIGFuZCBmdW5jdGlvbmFsaXR5 LiBUaGUgcmVzb3VyY2Ugb3duZXIgbWF5IGFsc28KICAgICAgICAgICAgcmVseSBvbiB1c2VyLWFn ZW50IGZlYXR1cmVzIG9yIGV4dGVuc2lvbnMgdG8gYXNzaXN0IHdpdGggYXV0aGVudGljYXRpb24g KGUuZy4gcGFzc3dvcmQKICAgICAgICAgICAgbWFuYWdlciwgMi1mYWN0b3IgZGV2aWNlIHJlYWRl cikuCiAgICAgICAgICA8L3Q+CiAgICAgICAgICA8dD4KICAgICAgICAgICAgQW4gZW1iZWRkZWQg dXNlci1hZ2VudCBtYXkgb2ZmZXIgaW1wcm92ZWQgdXNhYmlsaXR5LCBhcyBpdCByZW1vdmVzIHRo ZSBuZWVkIHRvIHN3aXRjaAogICAgICAgICAgICBjb250ZXh0IGFuZCBvcGVuIG5ldyB3aW5kb3dz LgogICAgICAgICAgPC90PgogICAgICAgICAgPHQ+CiAgICAgICAgICAgIEFuIGVtYmVkZGVkIHVz ZXItYWdlbnQgcG9zZXMgYSBzZWN1cml0eSBjaGFsbGVuZ2UgYmVjYXVzZSByZXNvdXJjZSBvd25l cnMgYXJlCiAgICAgICAgICAgIGF1dGhlbnRpY2F0aW5nIGluIGFuIHVuaWRlbnRpZmllZCB3aW5k b3cgd2l0aG91dCBhY2Nlc3MgdG8gdGhlIHZpc3VhbCBwcm90ZWN0aW9ucyBmb3VuZAogICAgICAg ICAgICBpbiBtb3N0IGV4dGVybmFsIHVzZXItYWdlbnRzLiBBbiBlbWJlZGRlZCB1c2VyLWFnZW50 IGVkdWNhdGVzIGVuZC11c2VycyB0byB0cnVzdAogICAgICAgICAgICB1bmlkZW50aWZpZWQgcmVx dWVzdHMgZm9yIGF1dGhlbnRpY2F0aW9uIChtYWtpbmcgcGhpc2hpbmcgYXR0YWNrcyBlYXNpZXIg dG8gZXhlY3V0ZSkuCiAgICAgICAgICA8L3Q+CiAgICAgICAgPC9saXN0PgogICAgICA8L3Q+CiAg ICAgIDx0PgogICAgICAgIFdoZW4gY2hvb3NpbmcgYmV0d2VlbiB0aGUgaW1wbGljaXQgZ3JhbnQg dHlwZSBhbmQgdGhlIGF1dGhvcml6YXRpb24gY29kZSBncmFudCB0eXBlLCB0aGUKICAgICAgICBm b2xsb3dpbmcgc2hvdWxkIGJlIGNvbnNpZGVyZWQ6CiAgICAgIDwvdD4KICAgICAgPHQ+CiAgICAg ICAgPGxpc3Qgc3R5bGU9J3N5bWJvbHMnPgogICAgICAgICAgPHQ+CiAgICAgICAgICAgIE5hdGl2 ZSBhcHBsaWNhdGlvbnMgdGhhdCB1c2UgdGhlIGF1dGhvcml6YXRpb24gY29kZSBncmFudCB0eXBl IFNIT1VMRCBkbyBzbyB3aXRob3V0CiAgICAgICAgICAgIHVzaW5nIGNsaWVudCBjcmVkZW50aWFs cywgZHVlIHRvIHRoZSBuYXRpdmUgYXBwbGljYXRpb24ncyBpbmFiaWxpdHkgdG8ga2VlcCBjbGll bnQKICAgICAgICAgICAgY3JlZGVudGlhbHMgY29uZmlkZW50aWFsLgogICAgICAgICAgPC90Pgog ICAgICAgICAgPHQ+CiAgICAgICAgICAgIFdoZW4gdXNpbmcgdGhlIGltcGxpY2l0IGdyYW50IHR5 cGUgZmxvdyBhIHJlZnJlc2ggdG9rZW4gaXMgbm90IHJldHVybmVkIHdoaWNoIHJlcXVpcmVzCiAg ICAgICAgICAgIHJlcGVhdGluZyB0aGUgYXV0aG9yaXphdGlvbiBwcm9jZXNzIG9uY2UgdGhlIGFj Y2VzcyB0b2tlbiBleHBpcmVzLgogICAgICAgICAgPC90PgogICAgICAgIDwvbGlzdD4KICAgICAg PC90PgogICAgPC9zZWN0aW9uPgoKICAgIDxzZWN0aW9uIHRpdGxlPSdTZWN1cml0eSBDb25zaWRl cmF0aW9ucyc+CiAgICAgIDx0PgogICAgICAgIEFzIGEgZmxleGlibGUgYW5kIGV4dGVuc2libGUg ZnJhbWV3b3JrLCBPQXV0aCdzIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGRlcGVuZCBvbiBtYW55 CiAgICAgICAgZmFjdG9ycy4gVGhlIGZvbGxvd2luZyBzZWN0aW9ucyBwcm92aWRlIGltcGxlbWVu dGVycyB3aXRoIHNlY3VyaXR5IGd1aWRlbGluZXMgZm9jdXNlZCBvbgogICAgICAgIHRoZSB0aHJl ZSBjbGllbnQgcHJvZmlsZXMgZGVzY3JpYmVkIGluIDx4cmVmIHRhcmdldD0nY2xpZW50LXR5cGVz JyAvPjogd2ViIGFwcGxpY2F0aW9uLAogICAgICAgIHVzZXItYWdlbnQtYmFzZWQgYXBwbGljYXRp b24sIGFuZCBuYXRpdmUgYXBwbGljYXRpb24uCiAgICAgIDwvdD4KICAgICAgPHQ+CiAgICAgICAg QSBjb21wcmVoZW5zaXZlIE9BdXRoIHNlY3VyaXR5IG1vZGVsIGFuZCBhbmFseXNpcywgYXMgd2Vs bCBhcyBiYWNrZ3JvdW5kIGZvciB0aGUgcHJvdG9jb2wKICAgICAgICBkZXNpZ24gaXMgcHJvdmlk ZWQgYnkgPHhyZWYgdGFyZ2V0PSdJLUQuaWV0Zi1vYXV0aC12Mi10aHJlYXRtb2RlbCcgLz4uCiAg ICAgIDwvdD4KCiAgICAgIDxzZWN0aW9uIHRpdGxlPSdDbGllbnQgQXV0aGVudGljYXRpb24nPgog ICAgICAgIDx0PgogICAgICAgICAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGVzdGFibGlzaGVz IGNsaWVudCBjcmVkZW50aWFscyB3aXRoIHdlYiBhcHBsaWNhdGlvbiBjbGllbnRzIGZvcgogICAg ICAgICAgdGhlIHB1cnBvc2Ugb2YgY2xpZW50IGF1dGhlbnRpY2F0aW9uLiBUaGUgYXV0aG9yaXph dGlvbiBzZXJ2ZXIgaXMgZW5jb3VyYWdlZCB0byBjb25zaWRlcgogICAgICAgICAgc3Ryb25nZXIg Y2xpZW50IGF1dGhlbnRpY2F0aW9uIG1lYW5zIHRoYW4gYSBjbGllbnQgcGFzc3dvcmQuIFdlYiBh cHBsaWNhdGlvbiBjbGllbnRzIE1VU1QKICAgICAgICAgIGVuc3VyZSBjb25maWRlbnRpYWxpdHkg b2YgY2xpZW50IHBhc3N3b3JkcyBhbmQgb3RoZXIgY2xpZW50IGNyZWRlbnRpYWxzLgogICAgICAg IDwvdD4KICAgICAgICA8dD4KICAgICAgICAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBNVVNU IE5PVCBpc3N1ZSBjbGllbnQgcGFzc3dvcmRzIG9yIG90aGVyIGNsaWVudCBjcmVkZW50aWFscyB0 bwogICAgICAgICAgbmF0aXZlIGFwcGxpY2F0aW9uIG9yIHVzZXItYWdlbnQtYmFzZWQgYXBwbGlj YXRpb24gY2xpZW50cyBmb3IgdGhlIHB1cnBvc2Ugb2YgY2xpZW50CiAgICAgICAgICBhdXRoZW50 aWNhdGlvbi4gVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIE1BWSBpc3N1ZSBhIGNsaWVudCBwYXNz d29yZCBvciBvdGhlciBjcmVkZW50aWFscwogICAgICAgICAgZm9yIGEgc3BlY2lmaWMgaW5zdGFs bGF0aW9uIG9mIGEgbmF0aXZlIGFwcGxpY2F0aW9uIGNsaWVudCBvbiBhIHNwZWNpZmljIGRldmlj ZS4KICAgICAgICA8L3Q+CiAgICAgICAgPHQ+CiAgICAgICAgICBXaGVuIGNsaWVudCBhdXRoZW50 aWNhdGlvbiBpcyBub3QgcG9zc2libGUsIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBTSE9VTEQg ZW1wbG95IG90aGVyCiAgICAgICAgICBtZWFucyB0byB2YWxpZGF0ZSB0aGUgY2xpZW50J3MgaWRl bnRpdHkuIEZvciBleGFtcGxlLCBieSByZXF1aXJpbmcgdGhlIHJlZ2lzdHJhdGlvbiBvZgogICAg ICAgICAgdGhlIGNsaWVudCByZWRpcmVjdGlvbiBVUkkgb3IgZW5saXN0aW5nIHRoZSByZXNvdXJj ZSBvd25lciB0byBjb25maXJtIGlkZW50aXR5LiBBIHZhbGlkCiAgICAgICAgICByZWRpcmVjdGlv biBVUkkgaXMgbm90IHN1ZmZpY2llbnQgdG8gdmVyaWZ5IHRoZSBjbGllbnQncyBpZGVudGl0eSB3 aGVuIGFza2luZyBmb3IKICAgICAgICAgIHJlc291cmNlIG93bmVyIGF1dGhvcml6YXRpb24sIGJ1 dCBjYW4gYmUgdXNlZCB0byBwcmV2ZW50IGRlbGl2ZXJpbmcgY3JlZGVudGlhbHMgdG8gYQogICAg ICAgICAgY291bnRlcmZlaXQgY2xpZW50IGFmdGVyIG9idGFpbmluZyByZXNvdXJjZSBvd25lciBh dXRob3JpemF0aW9uLgogICAgICAgIDwvdD4KICAgICAgICA8dD4KICAgICAgICAgIFRoZSBhdXRo b3JpemF0aW9uIHNlcnZlciBtdXN0IGNvbnNpZGVyIHRoZSBzZWN1cml0eSBpbXBsaWNhdGlvbnMg b2YgaW50ZXJhY3Rpbmcgd2l0aAogICAgICAgICAgdW5hdXRoZW50aWNhdGVkIGNsaWVudHMgYW5k IHRha2UgbWVhc3VyZXMgdG8gbGltaXQgdGhlIHBvdGVudGlhbCBleHBvc3VyZSBvZiBvdGhlcgog ICAgICAgICAgY3JlZGVudGlhbHMgKGUuZy4gcmVmcmVzaCB0b2tlbnMpIGlzc3VlZCB0byBzdWNo IGNsaWVudHMuCiAgICAgICAgPC90PgogICAgICA8L3NlY3Rpb24+CgogICAgICA8c2VjdGlvbiB0 aXRsZT0nQ2xpZW50IEltcGVyc29uYXRpb24nPgogICAgICAgIDx0PgogICAgICAgICAgQSBtYWxp Y2lvdXMgY2xpZW50IGNhbiBpbXBlcnNvbmF0ZSBhbm90aGVyIGNsaWVudCBhbmQgb2J0YWluIGFj Y2VzcyB0byBwcm90ZWN0ZWQKICAgICAgICAgIHJlc291cmNlcywgaWYgdGhlIGltcGVyc29uYXRl ZCBjbGllbnQgZmFpbHMgdG8sIG9yIGlzIHVuYWJsZSB0bywga2VlcCBpdHMgY2xpZW50CiAgICAg ICAgICBjcmVkZW50aWFscyBjb25maWRlbnRpYWwuCiAgICAgICAgPC90PgogICAgICAgIDx0Pgog ICAgICAgICAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIE1VU1QgYXV0aGVudGljYXRlIHRoZSBj bGllbnQgd2hlbmV2ZXIgcG9zc2libGUuIElmIHRoZQogICAgICAgICAgYXV0aG9yaXphdGlvbiBz ZXJ2ZXIgY2Fubm90IGF1dGhlbnRpY2F0ZSB0aGUgY2xpZW50IGR1ZSB0byB0aGUgY2xpZW50J3Mg bmF0dXJlLCB0aGUKICAgICAgICAgIGF1dGhvcml6YXRpb24gc2VydmVyIE1VU1QgcmVxdWlyZSB0 aGUgcmVnaXN0cmF0aW9uIG9mIGFueSByZWRpcmVjdGlvbiBVUkkgdXNlZCBmb3IKICAgICAgICAg IHJlY2VpdmluZyBhdXRob3JpemF0aW9uIHJlc3BvbnNlcywgYW5kIFNIT1VMRCB1dGlsaXplIG90 aGVyIG1lYW5zIHRvIHByb3RlY3QgcmVzb3VyY2UKICAgICAgICAgIG93bmVycyBmcm9tIHN1Y2gg cG90ZW50aWFsbHkgbWFsaWNpb3VzIGNsaWVudHMuIEZvciBleGFtcGxlLCB0aGUgYXV0aG9yaXph dGlvbiBzZXJ2ZXIKICAgICAgICAgIGNhbiBlbmdhZ2UgdGhlIHJlc291cmNlIG93bmVyIHRvIGFz c2lzdCBpbiBpZGVudGlmeWluZyB0aGUgY2xpZW50IGFuZCBpdHMgb3JpZ2luLgogICAgICAgIDwv dD4KICAgICAgICA8dD4KICAgICAgICAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBTSE9VTEQg ZW5mb3JjZSBleHBsaWNpdCByZXNvdXJjZSBvd25lciBhdXRoZW50aWNhdGlvbiBhbmQKICAgICAg ICAgIHByb3ZpZGUgdGhlIHJlc291cmNlIG93bmVyIHdpdGggaW5mb3JtYXRpb24gYWJvdXQgdGhl IGNsaWVudCBhbmQgdGhlIHJlcXVlc3RlZAogICAgICAgICAgYXV0aG9yaXphdGlvbiBzY29wZSBh bmQgbGlmZXRpbWUuIEl0IGlzIHVwIHRvIHRoZSByZXNvdXJjZSBvd25lciB0byByZXZpZXcgdGhl CiAgICAgICAgICBpbmZvcm1hdGlvbiBpbiB0aGUgY29udGV4dCBvZiB0aGUgY3VycmVudCBjbGll bnQsIGFuZCBhdXRob3JpemUgb3IgZGVueSB0aGUgcmVxdWVzdC4KICAgICAgICA8L3Q+CiAgICAg ICAgPHQ+CiAgICAgICAgICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgU0hPVUxEIE5PVCBwcm9j ZXNzIHJlcGVhdGVkIGF1dGhvcml6YXRpb24gcmVxdWVzdHMKICAgICAgICAgIGF1dG9tYXRpY2Fs bHkgKHdpdGhvdXQgYWN0aXZlIHJlc291cmNlIG93bmVyIGludGVyYWN0aW9uKSB3aXRob3V0IGF1 dGhlbnRpY2F0aW5nIHRoZQogICAgICAgICAgY2xpZW50IG9yIHJlbHlpbmcgb24gb3RoZXIgbWVh c3VyZXMgdG8gZW5zdXJlIHRoZSByZXBlYXRlZCByZXF1ZXN0IGNvbWVzIGZyb20gdGhlCiAgICAg ICAgICBvcmlnaW5hbCBjbGllbnQgYW5kIG5vdCBhbiBpbXBlcnNvbmF0b3IuCiAgICAgICAgPC90 PgogICAgICA8L3NlY3Rpb24+CgogICAgICA8c2VjdGlvbiB0aXRsZT0nQWNjZXNzIFRva2Vucyc+ CiAgICAgICAgPHQ+CiAgICAgICAgICBBY2Nlc3MgdG9rZW4gY3JlZGVudGlhbHMgKGFzIHdlbGwg YXMgYW55IGNvbmZpZGVudGlhbCBhY2Nlc3MgdG9rZW4gYXR0cmlidXRlcykgTVVTVCBiZQogICAg ICAgICAga2VwdCBjb25maWRlbnRpYWwgaW4gdHJhbnNpdCBhbmQgc3RvcmFnZSwgYW5kIG9ubHkg c2hhcmVkIGFtb25nIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciwKICAgICAgICAgIHRoZSByZXNv dXJjZSBzZXJ2ZXJzIHRoZSBhY2Nlc3MgdG9rZW4gaXMgdmFsaWQgZm9yLCBhbmQgdGhlIGNsaWVu dCB0byB3aG9tIHRoZSBhY2Nlc3MKICAgICAgICAgIHRva2VuIGlzIGlzc3VlZC4gQWNjZXNzIHRv a2VuIGNyZWRlbnRpYWxzIE1VU1Qgb25seSBiZSB0cmFuc21pdHRlZCB1c2luZyBUTFMgYXMgZGVz Y3JpYmVkCiAgICAgICAgICBpbiA8eHJlZiB0YXJnZXQ9J3RscycgLz4gd2l0aCBzZXJ2ZXIgYXV0 aGVudGljYXRpb24gYXMgZGVmaW5lZCBieQogICAgICAgICAgPHhyZWYgdGFyZ2V0PSdSRkMyODE4 JyAvPi4KICAgICAgICA8L3Q+CiAgICAgICAgPHQ+CiAgICAgICAgICBXaGVuIHVzaW5nIHRoZSBp bXBsaWNpdCBncmFudCB0eXBlLCB0aGUgYWNjZXNzIHRva2VuIGlzIHRyYW5zbWl0dGVkIGluIHRo ZSBVUkkgZnJhZ21lbnQsCiAgICAgICAgICB3aGljaCBjYW4gZXhwb3NlIGl0IHRvIHVuYXV0aG9y aXplZCBwYXJ0aWVzLgogICAgICAgIDwvdD4KICAgICAgICA8dD4KICAgICAgICAgIFRoZSBhdXRo b3JpemF0aW9uIHNlcnZlciBNVVNUIGVuc3VyZSB0aGF0IGFjY2VzcyB0b2tlbnMgY2Fubm90IGJl IGdlbmVyYXRlZCwgbW9kaWZpZWQsIG9yCiAgICAgICAgICBndWVzc2VkIHRvIHByb2R1Y2UgdmFs aWQgYWNjZXNzIHRva2VucyBieSB1bmF1dGhvcml6ZWQgcGFydGllcy4KICAgICAgICA8L3Q+CiAg ICAgICAgPHQ+CiAgICAgICAgICBUaGUgY2xpZW50IFNIT1VMRCByZXF1ZXN0IGFjY2VzcyB0b2tl bnMgd2l0aCB0aGUgbWluaW1hbCBzY29wZSBuZWNlc3NhcnkuIFRoZQogICAgICAgICAgYXV0aG9y aXphdGlvbiBzZXJ2ZXIgU0hPVUxEIHRha2UgdGhlIGNsaWVudCBpZGVudGl0eSBpbnRvIGFjY291 bnQgd2hlbiBjaG9vc2luZyBob3cKICAgICAgICAgIHRvIGhvbm9yIHRoZSByZXF1ZXN0ZWQgc2Nv cGUsIGFuZCBNQVkgaXNzdWUgYW4gYWNjZXNzIHRva2VuIHdpdGggYSBsZXNzIHJpZ2h0cyB0aGFu CiAgICAgICAgICByZXF1ZXN0ZWQuCiAgICAgICAgPC90PgogICAgICAgIDx0PgogICAgICAgICAg VGhpcyBzcGVjaWZpY2F0aW9uIGRvZXMgbm90IHByb3ZpZGUgYW55IG1ldGhvZHMgZm9yIHRoZSBy ZXNvdXJjZSBzZXJ2ZXIgdG8gZW5zdXJlIHRoYXQgYW4KICAgICAgICAgIGFjY2VzcyB0b2tlbiBw cmVzZW50ZWQgdG8gaXQgYnkgYSBnaXZlbiBjbGllbnQgd2FzIGlzc3VlZCB0byB0aGF0IGNsaWVu dCBieSB0aGUKICAgICAgICAgIGF1dGhvcml6YXRpb24gc2VydmVyLgogICAgICAgIDwvdD4KICAg ICAgPC9zZWN0aW9uPgoKICAgICAgPHNlY3Rpb24gdGl0bGU9J1JlZnJlc2ggVG9rZW5zJz4KICAg ICAgICA8dD4KICAgICAgICAgIEF1dGhvcml6YXRpb24gc2VydmVycyBNQVkgaXNzdWUgcmVmcmVz aCB0b2tlbnMgdG8gd2ViIGFwcGxpY2F0aW9uIGNsaWVudHMgYW5kIG5hdGl2ZQogICAgICAgICAg YXBwbGljYXRpb24gY2xpZW50cy4KICAgICAgICA8L3Q+CiAgICAgICAgPHQ+CiAgICAgICAgICBS ZWZyZXNoIHRva2VucyBNVVNUIGJlIGtlcHQgY29uZmlkZW50aWFsIGluIHRyYW5zaXQgYW5kIHN0 b3JhZ2UsIGFuZCBzaGFyZWQgb25seSBhbW9uZwogICAgICAgICAgdGhlIGF1dGhvcml6YXRpb24g c2VydmVyIGFuZCB0aGUgY2xpZW50IHRvIHdob20gdGhlIHJlZnJlc2ggdG9rZW5zIHdlcmUgaXNz dWVkLiBUaGUKICAgICAgICAgIGF1dGhvcml6YXRpb24gc2VydmVyIE1VU1QgbWFpbnRhaW4gdGhl IGJpbmRpbmcgYmV0d2VlbiBhIHJlZnJlc2ggdG9rZW4gYW5kIHRoZSBjbGllbnQgdG8KICAgICAg ICAgIHdob20gaXQgd2FzIGlzc3VlZC4gUmVmcmVzaCB0b2tlbnMgTVVTVCBvbmx5IGJlIHRyYW5z bWl0dGVkIHVzaW5nIFRMUyBhcyBkZXNjcmliZWQgaW4KICAgICAgICAgIDx4cmVmIHRhcmdldD0n dGxzJyAvPiB3aXRoIHNlcnZlciBhdXRoZW50aWNhdGlvbiBhcyBkZWZpbmVkIGJ5IDx4cmVmIHRh cmdldD0nUkZDMjgxOCcgLz4uCiAgICAgICAgPC90PgogICAgICAgIDx0PgogICAgICAgICAgVGhl IGF1dGhvcml6YXRpb24gc2VydmVyIE1VU1QgdmVyaWZ5IHRoZSBiaW5kaW5nIGJldHdlZW4gdGhl IHJlZnJlc2ggdG9rZW4gYW5kIGNsaWVudAogICAgICAgICAgaWRlbnRpdHkgd2hlbmV2ZXIgdGhl IGNsaWVudCBpZGVudGl0eSBjYW4gYmUgYXV0aGVudGljYXRlZC4gV2hlbiBjbGllbnQgYXV0aGVu dGljYXRpb24gaXMKICAgICAgICAgIG5vdCBwb3NzaWJsZSwgdGhlIGF1dGhvcml6YXRpb24gc2Vy dmVyIFNIT1VMRCBkZXBsb3kgb3RoZXIgbWVhbnMgdG8gZGV0ZWN0IHJlZnJlc2ggdG9rZW4KICAg ICAgICAgIGFidXNlLgogICAgICAgIDwvdD4KICAgICAgICA8dD4KICAgICAgICAgIEZvciBleGFt cGxlLCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgY291bGQgZW1wbG95IHJlZnJlc2ggdG9rZW4g cm90YXRpb24gaW4gd2hpY2ggYSBuZXcKICAgICAgICAgIHJlZnJlc2ggdG9rZW4gaXMgaXNzdWVk IHdpdGggZXZlcnkgYWNjZXNzIHRva2VuIHJlZnJlc2ggcmVzcG9uc2UuIFRoZSBwcmV2aW91cyBy ZWZyZXNoCiAgICAgICAgICB0b2tlbiBpcyBpbnZhbGlkYXRlZCBidXQgcmV0YWluZWQgYnkgdGhl IGF1dGhvcml6YXRpb24gc2VydmVyLiBJZiBhIHJlZnJlc2ggdG9rZW4gaXMKICAgICAgICAgIGNv bXByb21pc2VkIGFuZCBzdWJzZXF1ZW50bHkgdXNlZCBieSBib3RoIHRoZSBhdHRhY2tlciBhbmQg dGhlIGxlZ2l0aW1hdGUgY2xpZW50LCBvbmUgb2YKICAgICAgICAgIHRoZW0gd2lsbCBwcmVzZW50 IGFuIGludmFsaWRhdGVkIHJlZnJlc2ggdG9rZW4gd2hpY2ggd2lsbCBpbmZvcm0gdGhlIGF1dGhv cml6YXRpb24gc2VydmVyCiAgICAgICAgICBvZiB0aGUgYnJlYWNoLgogICAgICAgIDwvdD4KICAg ICAgICA8dD4KICAgICAgICAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBNVVNUIGVuc3VyZSB0 aGF0IHJlZnJlc2ggdG9rZW5zIGNhbm5vdCBiZSBnZW5lcmF0ZWQsIG1vZGlmaWVkLAogICAgICAg ICAgb3IgZ3Vlc3NlZCB0byBwcm9kdWNlIHZhbGlkIHJlZnJlc2ggdG9rZW5zIGJ5IHVuYXV0aG9y aXplZCBwYXJ0aWVzLgogICAgICAgIDwvdD4KICAgICAgPC9zZWN0aW9uPgoKICAgICAgPHNlY3Rp b24gdGl0bGU9J0F1dGhvcml6YXRpb24gQ29kZXMnPgogICAgICAgIDx0PgogICAgICAgICAgVGhl IHRyYW5zbWlzc2lvbiBvZiBhdXRob3JpemF0aW9uIGNvZGVzIFNIT1VMRCBiZSBtYWRlIG92ZXIg YSBzZWN1cmUgY2hhbm5lbCwgYW5kIHRoZQogICAgICAgICAgY2xpZW50IFNIT1VMRCByZXF1aXJl IHRoZSB1c2Ugb2YgVExTIHdpdGggaXRzIHJlZGlyZWN0aW9uIFVSSSBpZiB0aGUgVVJJIGlkZW50 aWZpZXMgYQogICAgICAgICAgbmV0d29yayByZXNvdXJjZS4gU2luY2UgYXV0aG9yaXphdGlvbiBj b2RlcyBhcmUgdHJhbnNtaXR0ZWQgdmlhIHVzZXItYWdlbnQgcmVkaXJlY3Rpb25zLAogICAgICAg ICAgdGhleSBjb3VsZCBwb3RlbnRpYWxseSBiZSBkaXNjbG9zZWQgdGhyb3VnaCB1c2VyLWFnZW50 IGhpc3RvcnkgYW5kIEhUVFAgcmVmZXJyZXIgaGVhZGVycy4KICAgICAgICA8L3Q+CiAgICAgICAg PHQ+CiAgICAgICAgICBBdXRob3JpemF0aW9uIGNvZGVzIG9wZXJhdGUgYXMgcGxhaW50ZXh0IGJl YXJlciBjcmVkZW50aWFscywgdXNlZCB0byB2ZXJpZnkgdGhhdCB0aGUKICAgICAgICAgIHJlc291 cmNlIG93bmVyIHdobyBncmFudGVkIGF1dGhvcml6YXRpb24gYXQgdGhlIGF1dGhvcml6YXRpb24g c2VydmVyIGlzIHRoZSBzYW1lCiAgICAgICAgICByZXNvdXJjZSBvd25lciByZXR1cm5pbmcgdG8g dGhlIGNsaWVudCB0byBjb21wbGV0ZSB0aGUgcHJvY2Vzcy4gVGhlcmVmb3JlLCBpZiB0aGUgY2xp ZW50CiAgICAgICAgICByZWxpZXMgb24gdGhlIGF1dGhvcml6YXRpb24gY29kZSBmb3IgaXRzIG93 biByZXNvdXJjZSBvd25lciBhdXRoZW50aWNhdGlvbiwgdGhlIGNsaWVudAogICAgICAgICAgcmVk aXJlY3Rpb24gZW5kcG9pbnQgTVVTVCByZXF1aXJlIHRoZSB1c2Ugb2YgVExTLgogICAgICAgIDwv dD4KICAgICAgICA8dD4KICAgICAgICAgIEF1dGhvcml6YXRpb24gY29kZXMgTVVTVCBiZSBzaG9y dCBsaXZlZCBhbmQgc2luZ2xlIHVzZS4gSWYgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyCiAgICAg ICAgICBvYnNlcnZlcyBtdWx0aXBsZSBhdHRlbXB0cyB0byBleGNoYW5nZSBhbiBhdXRob3JpemF0 aW9uIGNvZGUgZm9yIGFuIGFjY2VzcyB0b2tlbiwgdGhlCiAgICAgICAgICBhdXRob3JpemF0aW9u IHNlcnZlciBTSE9VTEQgYXR0ZW1wdCB0byByZXZva2UgYWxsIGFjY2VzcyB0b2tlbnMgYWxyZWFk eSBncmFudGVkIGJhc2VkIG9uCiAgICAgICAgICB0aGUgY29tcHJvbWlzZWQgYXV0aG9yaXphdGlv biBjb2RlLgogICAgICAgIDwvdD4KICAgICAgICA8dD4KICAgICAgICAgIElmIHRoZSBjbGllbnQg Y2FuIGJlIGF1dGhlbnRpY2F0ZWQsIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlcnMgTVVTVCBhdXRo ZW50aWNhdGUgdGhlCiAgICAgICAgICBjbGllbnQgYW5kIGVuc3VyZSB0aGF0IHRoZSBhdXRob3Jp emF0aW9uIGNvZGUgd2FzIGlzc3VlZCB0byB0aGUgc2FtZSBjbGllbnQuCiAgICAgICAgPC90Pgog ICAgICA8L3NlY3Rpb24+CgogICAgICA8c2VjdGlvbiB0aXRsZT0nQXV0aG9yaXphdGlvbiBDb2Rl IFJlZGlyZWN0aW9uIFVSSSBNYW5pcHVsYXRpb24nPgogICAgICAgIDx0PgogICAgICAgICAgV2hl biByZXF1ZXN0aW5nIGF1dGhvcml6YXRpb24gdXNpbmcgdGhlIGF1dGhvcml6YXRpb24gY29kZSBn cmFudCB0eXBlLCB0aGUgY2xpZW50IGNhbgogICAgICAgICAgc3BlY2lmeSBhIHJlZGlyZWN0aW9u IFVSSSB2aWEgdGhlIDxzcGFueCBzdHlsZT0ndmVyYic+cmVkaXJlY3RfdXJpPC9zcGFueD4gcGFy YW1ldGVyLgogICAgICAgICAgSWYgYW4gYXR0YWNrZXIgY2FuIG1hbmlwdWxhdGUgdGhlIHZhbHVl IG9mIHRoZSByZWRpcmVjdGlvbiBVUkksIGl0IGNhbiBjYXVzZSB0aGUKICAgICAgICAgIGF1dGhv cml6YXRpb24gc2VydmVyIHRvIHJlZGlyZWN0IHRoZSByZXNvdXJjZSBvd25lciB1c2VyLWFnZW50 IHRvIGEgVVJJIHVuZGVyIHRoZSBjb250cm9sCiAgICAgICAgICBvZiB0aGUgYXR0YWNrZXIgd2l0 aCB0aGUgYXV0aG9yaXphdGlvbiBjb2RlLgogICAgICAgIDwvdD4KICAgICAgICA8dD4KICAgICAg ICAgIEFuIGF0dGFja2VyIGNhbiBjcmVhdGUgYW4gYWNjb3VudCBhdCBhIGxlZ2l0aW1hdGUgY2xp ZW50IGFuZCBpbml0aWF0ZSB0aGUgYXV0aG9yaXphdGlvbgogICAgICAgICAgZmxvdy4gV2hlbiB0 aGUgYXR0YWNrZXIncyB1c2VyLWFnZW50IGlzIHNlbnQgdG8gdGhlIGF1dGhvcml6YXRpb24gc2Vy dmVyIHRvIGdyYW50IGFjY2VzcywKICAgICAgICAgIHRoZSBhdHRhY2tlciBncmFicyB0aGUgYXV0 aG9yaXphdGlvbiBVUkkgcHJvdmlkZWQgYnkgdGhlIGxlZ2l0aW1hdGUgY2xpZW50LCBhbmQgcmVw bGFjZXMKICAgICAgICAgIHRoZSBjbGllbnQncyByZWRpcmVjdGlvbiBVUkkgd2l0aCBhIFVSSSB1 bmRlciB0aGUgY29udHJvbCBvZiB0aGUgYXR0YWNrZXIuIFRoZSBhdHRhY2tlcgogICAgICAgICAg dGhlbiB0cmlja3MgdGhlIHZpY3RpbSBpbnRvIGZvbGxvd2luZyB0aGUgbWFuaXB1bGF0ZWQgbGlu ayB0byBhdXRob3JpemUgYWNjZXNzIHRvIHRoZQogICAgICAgICAgbGVnaXRpbWF0ZSBjbGllbnQu CiAgICAgICAgPC90PgogICAgICAgIDx0PgogICAgICAgICAgT25jZSBhdCB0aGUgYXV0aG9yaXph dGlvbiBzZXJ2ZXIsIHRoZSB2aWN0aW0gaXMgcHJvbXB0ZWQgd2l0aCBhIG5vcm1hbCwgdmFsaWQg cmVxdWVzdCBvbgogICAgICAgICAgYmVoYWxmIG9mIGEgbGVnaXRpbWF0ZSBhbmQgdHJ1c3RlZCBj bGllbnQsIGFuZCBhdXRob3JpemVzIHRoZSByZXF1ZXN0LiBUaGUgdmljdGltIGlzCiAgICAgICAg ICB0aGVuIHJlZGlyZWN0ZWQgdG8gYW4gZW5kcG9pbnQgdW5kZXIgdGhlIGNvbnRyb2wgb2YgdGhl IGF0dGFja2VyIHdpdGggdGhlIGF1dGhvcml6YXRpb24KICAgICAgICAgIGNvZGUuIFRoZSBhdHRh Y2tlciBjb21wbGV0ZXMgdGhlIGF1dGhvcml6YXRpb24gZmxvdyBieSBzZW5kaW5nIHRoZSBhdXRo b3JpemF0aW9uIGNvZGUgdG8KICAgICAgICAgIHRoZSBjbGllbnQgdXNpbmcgdGhlIG9yaWdpbmFs IHJlZGlyZWN0aW9uIFVSSSBwcm92aWRlZCBieSB0aGUgY2xpZW50LiBUaGUgY2xpZW50CiAgICAg ICAgICBleGNoYW5nZXMgdGhlIGF1dGhvcml6YXRpb24gY29kZSB3aXRoIGFuIGFjY2VzcyB0b2tl biBhbmQgbGlua3MgaXQgdG8gdGhlIGF0dGFja2VyJ3MKICAgICAgICAgIGNsaWVudCBhY2NvdW50 IHdoaWNoIGNhbiBub3cgZ2FpbiBhY2Nlc3MgdG8gdGhlIHByb3RlY3RlZCByZXNvdXJjZXMgYXV0 aG9yaXplZCBieSB0aGUKICAgICAgICAgIHZpY3RpbSAodmlhIHRoZSBjbGllbnQpLgogICAgICAg IDwvdD4KICAgICAgICA8dD4KICAgICAgICAgIEluIG9yZGVyIHRvIHByZXZlbnQgc3VjaCBhbiBh dHRhY2ssIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBNVVNUIGVuc3VyZSB0aGF0IHRoZQogICAg ICAgICAgcmVkaXJlY3Rpb24gVVJJIHVzZWQgdG8gb2J0YWluIHRoZSBhdXRob3JpemF0aW9uIGNv ZGUgaXMgaWRlbnRpY2FsIHRvIHRoZSByZWRpcmVjdGlvbiBVUkkKICAgICAgICAgIHByb3ZpZGVk IHdoZW4gZXhjaGFuZ2luZyB0aGUgYXV0aG9yaXphdGlvbiBjb2RlIGZvciBhbiBhY2Nlc3MgdG9r ZW4uIFRoZSBhdXRob3JpemF0aW9uCiAgICAgICAgICBzZXJ2ZXIgTVVTVCByZXF1aXJlIHB1Ymxp YyBjbGllbnRzIGFuZCBTSE9VTEQgcmVxdWlyZSBjb25maWRlbnRpYWwgY2xpZW50cyB0byByZWdp c3RlcgogICAgICAgICAgdGhlaXIgcmVkaXJlY3Rpb24gVVJJcy4gSWYgYSByZWRpcmVjdGlvbiBV UkkgaXMgcHJvdmlkZWQgaW4gdGhlIHJlcXVlc3QsIHRoZQogICAgICAgICAgYXV0aG9yaXphdGlv biBzZXJ2ZXIgTVVTVCB2YWxpZGF0ZSBpdCBhZ2FpbnN0IHRoZSByZWdpc3RlcmVkIHZhbHVlLgog ICAgICAgIDwvdD4KICAgICAgPC9zZWN0aW9uPgoKICAgICAgPHNlY3Rpb24gdGl0bGU9J1Jlc291 cmNlIE93bmVyIFBhc3N3b3JkIENyZWRlbnRpYWxzJz4KICAgICAgICA8dD4KICAgICAgICAgIFRo ZSByZXNvdXJjZSBvd25lciBwYXNzd29yZCBjcmVkZW50aWFscyBncmFudCB0eXBlIGlzIG9mdGVu IHVzZWQgZm9yIGxlZ2FjeSBvciBtaWdyYXRpb24KICAgICAgICAgIHJlYXNvbnMuIEl0IHJlZHVj ZXMgdGhlIG92ZXJhbGwgcmlzayBvZiBzdG9yaW5nIHVzZXJuYW1lIGFuZCBwYXNzd29yZCBieSB0 aGUgY2xpZW50LCBidXQKICAgICAgICAgIGRvZXMgbm90IGVsaW1pbmF0ZSB0aGUgbmVlZCB0byBl eHBvc2UgaGlnaGx5IHByaXZpbGVnZWQgY3JlZGVudGlhbHMgdG8gdGhlIGNsaWVudC4KICAgICAg ICA8L3Q+CiAgICAgICAgPHQ+CiAgICAgICAgICBUaGlzIGdyYW50IHR5cGUgY2FycmllcyBhIGhp Z2hlciByaXNrIHRoYW4gb3RoZXIgZ3JhbnQgdHlwZXMgYmVjYXVzZSBpdCBtYWludGFpbnMgdGhl CiAgICAgICAgICBwYXNzd29yZCBhbnRpLXBhdHRlcm4gdGhpcyBwcm90b2NvbCBzZWVrcyB0byBh dm9pZC4gVGhlIGNsaWVudCBjb3VsZCBhYnVzZSB0aGUgcGFzc3dvcmQKICAgICAgICAgIG9yIHRo ZSBwYXNzd29yZCBjb3VsZCB1bmludGVudGlvbmFsbHkgYmUgZGlzY2xvc2VkIHRvIGFuIGF0dGFj a2VyIChlLmcuIHZpYSBsb2cgZmlsZXMgb3IKICAgICAgICAgIG90aGVyIHJlY29yZHMga2VwdCBi eSB0aGUgY2xpZW50KS4KICAgICAgICA8L3Q+CiAgICAgICAgPHQ+CiAgICAgICAgICBBZGRpdGlv bmFsbHksIGJlY2F1c2UgdGhlIHJlc291cmNlIG93bmVyIGRvZXMgbm90IGhhdmUgY29udHJvbCBv dmVyIHRoZSBhdXRob3JpemF0aW9uCiAgICAgICAgICBwcm9jZXNzICh0aGUgcmVzb3VyY2Ugb3du ZXIgaW52b2x2ZW1lbnQgZW5kcyB3aGVuIGl0IGhhbmRzIG92ZXIgaXRzIGNyZWRlbnRpYWxzIHRv IHRoZQogICAgICAgICAgY2xpZW50KSwgdGhlIGNsaWVudCBjYW4gb2J0YWluIGFjY2VzcyB0b2tl bnMgd2l0aCBhIGJyb2FkZXIgc2NvcGUgdGhhbiBkZXNpcmVkIGJ5IHRoZQogICAgICAgICAgcmVz b3VyY2Ugb3duZXIuIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBzaG91bGQgY29uc2lkZXIgdGhl IHNjb3BlIGFuZCBsaWZldGltZSBvZgogICAgICAgICAgYWNjZXNzIHRva2VucyBpc3N1ZWQgdmlh IHRoaXMgZ3JhbnQgdHlwZS4KICAgICAgICA8L3Q+CiAgICAgICAgPHQ+CiAgICAgICAgICBUaGUg YXV0aG9yaXphdGlvbiBzZXJ2ZXIgYW5kIGNsaWVudCBTSE9VTEQgbWluaW1pemUgdXNlIG9mIHRo aXMgZ3JhbnQgdHlwZSBhbmQgdXRpbGl6ZQogICAgICAgICAgb3RoZXIgZ3JhbnQgdHlwZXMgd2hl bmV2ZXIgcG9zc2libGUuCiAgICAgICAgPC90PgogICAgICA8L3NlY3Rpb24+CgogICAgICA8c2Vj dGlvbiB0aXRsZT0nUmVxdWVzdCBDb25maWRlbnRpYWxpdHknPgogICAgICAgIDx0PgogICAgICAg ICAgQWNjZXNzIHRva2VucywgcmVmcmVzaCB0b2tlbnMsIHJlc291cmNlIG93bmVyIHBhc3N3b3Jk cywgYW5kIGNsaWVudCBjcmVkZW50aWFscyBNVVNUIE5PVAogICAgICAgICAgYmUgdHJhbnNtaXR0 ZWQgaW4gdGhlIGNsZWFyLiBBdXRob3JpemF0aW9uIGNvZGVzIFNIT1VMRCBOT1QgYmUgdHJhbnNt aXR0ZWQgaW4gdGhlIGNsZWFyLgogICAgICAgIDwvdD4KICAgICAgICA8dD4KICAgICAgICAgIFRo ZSA8c3Bhbnggc3R5bGU9J3ZlcmInPnN0YXRlPC9zcGFueD4gYW5kIDxzcGFueCBzdHlsZT0ndmVy Yic+c2NvcGU8L3NwYW54PiBwYXJhbWV0ZXJzCiAgICAgICAgICBTSE9VTEQgTk9UIGluY2x1ZGUg c2Vuc2l0aXZlIGNsaWVudCBvciByZXNvdXJjZSBvd25lciBpbmZvcm1hdGlvbiBpbiBwbGFpbiB0 ZXh0IGFzIHRoZXkKICAgICAgICAgIGNhbiBiZSB0cmFuc21pdHRlZCBvdmVyIGluc2VjdXJlIGNo YW5uZWxzIG9yIHN0b3JlZCBpbnNlY3VyZWx5LgogICAgICAgIDwvdD4KICAgICAgPC9zZWN0aW9u PgoKICAgICAgPHNlY3Rpb24gdGl0bGU9J0VuZHBvaW50cyBBdXRoZW50aWNpdHknPgogICAgICAg IDx0PgogICAgICAgICAgSW4gb3JkZXIgdG8gcHJldmVudCBtYW4taW4tdGhlLW1pZGRsZSBhdHRh Y2tzLCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVTVCByZXF1aXJlIHRoZQogICAgICAgICAg dXNlIG9mIFRMUyB3aXRoIHNlcnZlciBhdXRoZW50aWNhdGlvbiBhcyBkZWZpbmVkIGJ5IDx4cmVm IHRhcmdldD0nUkZDMjgxOCcgLz4gZm9yCiAgICAgICAgICBhbnkgcmVxdWVzdCBzZW50IHRvIHRo ZSBhdXRob3JpemF0aW9uIGFuZCB0b2tlbiBlbmRwb2ludHMuIFRoZSBjbGllbnQgTVVTVCB2YWxp ZGF0ZSB0aGUKICAgICAgICAgIGF1dGhvcml6YXRpb24gc2VydmVyJ3MgVExTIGNlcnRpZmljYXRl IGFzIGRlZmluZWQgYnkgPHhyZWYgdGFyZ2V0PSdSRkM2MTI1JyAvPiwgYW5kIGluCiAgICAgICAg ICBhY2NvcmRhbmNlIHdpdGggaXRzIHJlcXVpcmVtZW50cyBmb3Igc2VydmVyIGlkZW50aXR5IGF1 dGhlbnRpY2F0aW9uLgogICAgICAgIDwvdD4KICAgICAgPC9zZWN0aW9uPgoKICAgICAgPHNlY3Rp b24gdGl0bGU9J0NyZWRlbnRpYWxzIEd1ZXNzaW5nIEF0dGFja3MnIGFuY2hvcj0nYW50aHJvcHkn PgogICAgICAgIDx0PgogICAgICAgICAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIE1VU1QgcHJl dmVudCBhdHRhY2tlcnMgZnJvbSBndWVzc2luZyBhY2Nlc3MgdG9rZW5zLAogICAgICAgICAgYXV0 aG9yaXphdGlvbiBjb2RlcywgcmVmcmVzaCB0b2tlbnMsIHJlc291cmNlIG93bmVyIHBhc3N3b3Jk cywgYW5kIGNsaWVudCBjcmVkZW50aWFscy4KICAgICAgICA8L3Q+CiAgICAgICAgPHQ+CiAgICAg ICAgICBUaGUgcHJvYmFiaWxpdHkgb2YgYW4gYXR0YWNrZXIgZ3Vlc3NpbmcgZ2VuZXJhdGVkIHRv a2VucyAoYW5kIG90aGVyIGNyZWRlbnRpYWxzIG5vdAogICAgICAgICAgaW50ZW5kZWQgZm9yIGhh bmRsaW5nIGJ5IGVuZC11c2VycykgTVVTVCBiZSBsZXNzIHRoYW4gb3IgZXF1YWwgdG8gMl4oLTEy OCkgYW5kIFNIT1VMRCBiZQogICAgICAgICAgbGVzcyB0aGFuIG9yIGVxdWFsIHRvIDJeKC0xNjAp LgogICAgICAgIDwvdD4KICAgICAgICA8dD4KICAgICAgICAgIFRoZSBhdXRob3JpemF0aW9uIHNl cnZlciBNVVNUIHV0aWxpemUgb3RoZXIgbWVhbnMgdG8gcHJvdGVjdCBjcmVkZW50aWFscyBpbnRl bmRlZCBmb3IKICAgICAgICAgIGVuZC11c2VyIHVzYWdlLgogICAgICAgIDwvdD4KICAgICAgPC9z ZWN0aW9uPgoKICAgICAgPHNlY3Rpb24gdGl0bGU9J1BoaXNoaW5nIEF0dGFja3MnPgogICAgICAg IDx0PgogICAgICAgICAgV2lkZSBkZXBsb3ltZW50IG9mIHRoaXMgYW5kIHNpbWlsYXIgcHJvdG9j b2xzIG1heSBjYXVzZSBlbmQtdXNlcnMgdG8gYmVjb21lIGludXJlZAogICAgICAgICAgdG8gdGhl IHByYWN0aWNlIG9mIGJlaW5nIHJlZGlyZWN0ZWQgdG8gd2Vic2l0ZXMgd2hlcmUgdGhleSBhcmUg YXNrZWQgdG8gZW50ZXIgdGhlaXIKICAgICAgICAgIHBhc3N3b3Jkcy4gSWYgZW5kLXVzZXJzIGFy ZSBub3QgY2FyZWZ1bCB0byB2ZXJpZnkgdGhlIGF1dGhlbnRpY2l0eSBvZiB0aGVzZSB3ZWJzaXRl cwogICAgICAgICAgYmVmb3JlIGVudGVyaW5nIHRoZWlyIGNyZWRlbnRpYWxzLCBpdCB3aWxsIGJl IHBvc3NpYmxlIGZvciBhdHRhY2tlcnMgdG8gZXhwbG9pdCB0aGlzCiAgICAgICAgICBwcmFjdGlj ZSB0byBzdGVhbCByZXNvdXJjZSBvd25lcnMnIHBhc3N3b3Jkcy4KICAgICAgICA8L3Q+CiAgICAg ICAgPHQ+CiAgICAgICAgICBTZXJ2aWNlIHByb3ZpZGVycyBzaG91bGQgYXR0ZW1wdCB0byBlZHVj YXRlIGVuZC11c2VycyBhYm91dCB0aGUgcmlza3MgcGhpc2hpbmcgYXR0YWNrcwogICAgICAgICAg cG9zZSwgYW5kIHNob3VsZCBwcm92aWRlIG1lY2hhbmlzbXMgdGhhdCBtYWtlIGl0IGVhc3kgZm9y IGVuZC11c2VycyB0byBjb25maXJtIHRoZQogICAgICAgICAgYXV0aGVudGljaXR5IG9mIHRoZWly IHNpdGVzLiBDbGllbnQgZGV2ZWxvcGVycyBzaG91bGQgY29uc2lkZXIgdGhlIHNlY3VyaXR5IGlt cGxpY2F0aW9ucwogICAgICAgICAgb2YgaG93IHRoZXkgaW50ZXJhY3Qgd2l0aCB0aGUgdXNlci1h Z2VudCAoZS5nLiwgZXh0ZXJuYWwsIGVtYmVkZGVkKSwgYW5kIHRoZSBhYmlsaXR5IG9mCiAgICAg ICAgICB0aGUgZW5kLXVzZXIgdG8gdmVyaWZ5IHRoZSBhdXRoZW50aWNpdHkgb2YgdGhlIGF1dGhv cml6YXRpb24gc2VydmVyLgogICAgICAgIDwvdD4KICAgICAgICA8dD4KICAgICAgICAgIFRvIHJl ZHVjZSB0aGUgcmlzayBvZiBwaGlzaGluZyBhdHRhY2tzLCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2 ZXJzIE1VU1QgcmVxdWlyZSB0aGUgdXNlIG9mCiAgICAgICAgICBUTFMgb24gZXZlcnkgZW5kcG9p bnQgdXNlZCBmb3IgZW5kLXVzZXIgaW50ZXJhY3Rpb24uCiAgICAgICAgPC90PgogICAgICA8L3Nl Y3Rpb24+CgogICAgICA8c2VjdGlvbiB0aXRsZT0nQ3Jvc3MtU2l0ZSBSZXF1ZXN0IEZvcmdlcnkn IGFuY2hvcj0nQ1NSRic+CiAgICAgICAgPHQ+CiAgICAgICAgICBDcm9zcy1zaXRlIHJlcXVlc3Qg Zm9yZ2VyeSAoQ1NSRikgaXMgYW4gZXhwbG9pdCBpbiB3aGljaCBhbiBhdHRhY2tlciBjYXVzZXMg dGhlCiAgICAgICAgICB1c2VyLWFnZW50IG9mIGEgdmljdGltIGVuZC11c2VyIHRvIGZvbGxvdyBh IG1hbGljaW91cyBVUkkgKGUuZy4gcHJvdmlkZWQgdG8gdGhlCiAgICAgICAgICB1c2VyLWFnZW50 IGFzIGEgbWlzbGVhZGluZyBsaW5rLCBpbWFnZSwgb3IgcmVkaXJlY3Rpb24pIHRvIGEgdHJ1c3Rp bmcgc2VydmVyICh1c3VhbGx5CiAgICAgICAgICBlc3RhYmxpc2hlZCB2aWEgdGhlIHByZXNlbmNl IG9mIGEgdmFsaWQgc2Vzc2lvbiBjb29raWUpLgogICAgICAgIDwvdD4KICAgICAgICA8dD4KICAg ICAgICAgIEEgQ1NSRiBhdHRhY2sgYWdhaW5zdCB0aGUgY2xpZW50J3MgcmVkaXJlY3Rpb24gVVJJ IGFsbG93cyBhbiBhdHRhY2tlciB0byBpbmplY3QgdGhlaXIgb3duCiAgICAgICAgICBhdXRob3Jp emF0aW9uIGNvZGUgb3IgYWNjZXNzIHRva2VuLCB3aGljaCBjYW4gcmVzdWx0IGluIHRoZSBjbGll bnQgdXNpbmcgYW4gYWNjZXNzIHRva2VuCiAgICAgICAgICBhc3NvY2lhdGVkIHdpdGggdGhlIGF0 dGFja2VyJ3MgcHJvdGVjdGVkIHJlc291cmNlcyByYXRoZXIgdGhhbiB0aGUgdmljdGltJ3MgKGUu Zy4gc2F2ZQogICAgICAgICAgdGhlIHZpY3RpbSdzIGJhbmsgYWNjb3VudCBpbmZvcm1hdGlvbiB0 byBhIHByb3RlY3RlZCByZXNvdXJjZSBjb250cm9sbGVkIGJ5IHRoZQogICAgICAgICAgYXR0YWNr ZXIpLgogICAgICAgIDwvdD4KICAgICAgICA8dD4KICAgICAgICAgIFRoZSBjbGllbnQgTVVTVCBp bXBsZW1lbnQgQ1NSRiBwcm90ZWN0aW9uIGZvciBpdHMgcmVkaXJlY3Rpb24gVVJJLiBUaGlzIGlz IHR5cGljYWxseQogICAgICAgICAgYWNjb21wbGlzaGVkIGJ5IHJlcXVpcmluZyBhbnkgcmVxdWVz dCBzZW50IHRvIHRoZSByZWRpcmVjdGlvbiBVUkkgZW5kcG9pbnQgdG8gaW5jbHVkZSBhCiAgICAg ICAgICB2YWx1ZSB0aGF0IGJpbmRzIHRoZSByZXF1ZXN0IHRvIHRoZSB1c2VyLWFnZW50J3MgYXV0 aGVudGljYXRlZCBzdGF0ZSAoZS5nLiBhIGhhc2ggb2YgdGhlCiAgICAgICAgICBzZXNzaW9uIGNv b2tpZSB1c2VkIHRvIGF1dGhlbnRpY2F0ZSB0aGUgdXNlci1hZ2VudCkuIFRoZSBjbGllbnQgU0hP VUxEIHV0aWxpemUgdGhlCiAgICAgICAgICA8c3Bhbnggc3R5bGU9J3ZlcmInPnN0YXRlPC9zcGFu eD4gcmVxdWVzdCBwYXJhbWV0ZXIgdG8gZGVsaXZlciB0aGlzIHZhbHVlIHRvIHRoZQogICAgICAg ICAgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgd2hlbiBtYWtpbmcgYW4gYXV0aG9yaXphdGlvbiByZXF1 ZXN0LgogICAgICAgIDwvdD4KICAgICAgICA8dD4KICAgICAgICAgIE9uY2UgYXV0aG9yaXphdGlv biBoYXMgYmVlbiBvYnRhaW5lZCBmcm9tIHRoZSBlbmQtdXNlciwgdGhlIGF1dGhvcml6YXRpb24g c2VydmVyCiAgICAgICAgICByZWRpcmVjdHMgdGhlIGVuZC11c2VyJ3MgdXNlci1hZ2VudCBiYWNr IHRvIHRoZSBjbGllbnQgd2l0aCB0aGUgcmVxdWlyZWQgYmluZGluZyB2YWx1ZQogICAgICAgICAg Y29udGFpbmVkIGluIHRoZSA8c3Bhbnggc3R5bGU9J3ZlcmInPnN0YXRlPC9zcGFueD4gcGFyYW1l dGVyLiBUaGUgYmluZGluZyB2YWx1ZSBlbmFibGVzCiAgICAgICAgICB0aGUgY2xpZW50IHRvIHZl cmlmeSB0aGUgdmFsaWRpdHkgb2YgdGhlIHJlcXVlc3QgYnkgbWF0Y2hpbmcgdGhlIGJpbmRpbmcg dmFsdWUgdG8gdGhlCiAgICAgICAgICB1c2VyLWFnZW50J3MgYXV0aGVudGljYXRlZCBzdGF0ZS4g VGhlIGJpbmRpbmcgdmFsdWUgdXNlZCBmb3IgQ1NSRiBwcm90ZWN0aW9uIE1VU1QgY29udGFpbgog ICAgICAgICAgYSBub24tZ3Vlc3NhYmxlIHZhbHVlIChhcyBkZXNjcmliZWQgaW4gPHhyZWYgdGFy Z2V0PSdhbnRocm9weScgLz4pLCBhbmQgdGhlIHVzZXItYWdlbnQncwogICAgICAgICAgYXV0aGVu dGljYXRlZCBzdGF0ZSAoZS5nLiBzZXNzaW9uIGNvb2tpZSwgSFRNTDUgbG9jYWwgc3RvcmFnZSkg TVVTVCBiZSBrZXB0IGluIGEgbG9jYXRpb24KICAgICAgICAgIGFjY2Vzc2libGUgb25seSB0byB0 aGUgY2xpZW50IGFuZCB0aGUgdXNlci1hZ2VudCAoaS5lLiwgcHJvdGVjdGVkIGJ5IHNhbWUtb3Jp Z2luIHBvbGljeSkuCiAgICAgICAgPC90PgogICAgICAgIDx0PgogICAgICAgICAgQSBDU1JGIGF0 dGFjayBhZ2FpbnN0IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlcidzIGF1dGhvcml6YXRpb24gZW5k cG9pbnQgY2FuIHJlc3VsdCBpbiBhbgogICAgICAgICAgYXR0YWNrZXIgb2J0YWluaW5nIGVuZC11 c2VyIGF1dGhvcml6YXRpb24gZm9yIGEgbWFsaWNpb3VzIGNsaWVudCB3aXRob3V0IGludm9sdmlu ZyBvcgogICAgICAgICAgYWxlcnRpbmcgdGhlIGVuZC11c2VyLgogICAgICAgIDwvdD4KICAgICAg ICA8dD4KICAgICAgICAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBNVVNUIGltcGxlbWVudCBD U1JGIHByb3RlY3Rpb24gZm9yIGl0cyBhdXRob3JpemF0aW9uIGVuZHBvaW50LAogICAgICAgICAg YW5kIGVuc3VyZSB0aGF0IGEgbWFsaWNpb3VzIGNsaWVudCBjYW5ub3Qgb2J0YWluIGF1dGhvcml6 YXRpb24gd2l0aG91dCB0aGUgYXdhcmVuZXNzIGFuZAogICAgICAgICAgZXhwbGljaXQgY29uc2Vu dCBvZiB0aGUgcmVzb3VyY2Ugb3duZXIuCiAgICAgICAgPC90PgogICAgICA8L3NlY3Rpb24+Cgog ICAgICA8c2VjdGlvbiB0aXRsZT0nQ2xpY2tqYWNraW5nJz4KICAgICAgICA8dD4KICAgICAgICAg IEluIGEgY2xpY2tqYWNraW5nIGF0dGFjaywgYW4gYXR0YWNrZXIgcmVnaXN0ZXJzIGEgbGVnaXRp bWF0ZSBjbGllbnQgYW5kIHRoZW4gY29uc3RydWN0cyBhCiAgICAgICAgICBtYWxpY2lvdXMgc2l0 ZSBpbiB3aGljaCBpdCBsb2FkcyB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIncyBhdXRob3JpemF0 aW9uIGVuZHBvaW50IHdlYgogICAgICAgICAgcGFnZSBpbiBhIHRyYW5zcGFyZW50IGlmcmFtZSBv dmVybGFpZCBvbiB0b3Agb2YgYSBzZXQgb2YgZHVtbXkgYnV0dG9ucyB3aGljaCBhcmUKICAgICAg ICAgIGNhcmVmdWxseSBjb25zdHJ1Y3RlZCB0byBiZSBwbGFjZWQgZGlyZWN0bHkgdW5kZXIgaW1w b3J0YW50IGJ1dHRvbnMgb24gdGhlIGF1dGhvcml6YXRpb24KICAgICAgICAgIHBhZ2UuIFdoZW4g YW4gZW5kLXVzZXIgY2xpY2tzIGEgbWlzbGVhZGluZyB2aXNpYmxlIGJ1dHRvbiwgdGhlIGVuZC11 c2VyIGlzIGFjdHVhbGx5CiAgICAgICAgICBjbGlja2luZyBhbiBpbnZpc2libGUgYnV0dG9uIG9u IHRoZSBhdXRob3JpemF0aW9uIHBhZ2UgKHN1Y2ggYXMgYW4gIkF1dGhvcml6ZSIgYnV0dG9uKS4K ICAgICAgICAgIFRoaXMgYWxsb3dzIGFuIGF0dGFja2VyIHRvIHRyaWNrIGEgcmVzb3VyY2Ugb3du ZXIgaW50byBncmFudGluZyBpdHMgY2xpZW50IGFjY2VzcyB3aXRob3V0CiAgICAgICAgICB0aGVp ciBrbm93bGVkZ2UuCiAgICAgICAgPC90PgogICAgICAgIDx0PgogICAgICAgICAgVG8gcHJldmVu dCB0aGlzIGZvcm0gb2YgYXR0YWNrLCBuYXRpdmUgYXBwbGljYXRpb25zIFNIT1VMRCB1c2UgZXh0 ZXJuYWwgYnJvd3NlcnMgaW5zdGVhZAogICAgICAgICAgb2YgZW1iZWRkaW5nIGJyb3dzZXJzIHdp dGhpbiB0aGUgYXBwbGljYXRpb24gd2hlbiByZXF1ZXN0aW5nIGVuZC11c2VyIGF1dGhvcml6YXRp b24uIEZvcgogICAgICAgICAgbW9zdCBuZXdlciBicm93c2VycywgYXZvaWRhbmNlIG9mIGlmcmFt ZXMgY2FuIGJlIGVuZm9yY2VkIGJ5IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlcgogICAgICAgICAg dXNpbmcgdGhlIChub24tc3RhbmRhcmQpIDxzcGFueCBzdHlsZT0ndmVyYic+eC1mcmFtZS1vcHRp b25zPC9zcGFueD4gaGVhZGVyLiBUaGlzIGhlYWRlcgogICAgICAgICAgY2FuIGhhdmUgdHdvIHZh bHVlcywgPHNwYW54IHN0eWxlPSd2ZXJiJz5kZW55PC9zcGFueD4gYW5kCiAgICAgICAgICA8c3Bh bnggc3R5bGU9J3ZlcmInPnNhbWVvcmlnaW48L3NwYW54Piwgd2hpY2ggd2lsbCBibG9jayBhbnkg ZnJhbWluZywgb3IgZnJhbWluZyBieSBzaXRlcwogICAgICAgICAgd2l0aCBhIGRpZmZlcmVudCBv cmlnaW4sIHJlc3BlY3RpdmVseS4gRm9yIG9sZGVyIGJyb3dzZXJzLCBKYXZhU2NyaXB0IGZyYW1l YnVzdGluZwogICAgICAgICAgdGVjaG5pcXVlcyBjYW4gYmUgdXNlZCBidXQgbWF5IG5vdCBiZSBl ZmZlY3RpdmUgaW4gYWxsIGJyb3dzZXJzLgogICAgICAgIDwvdD4KICAgICAgPC9zZWN0aW9uPgoK ICAgICAgPHNlY3Rpb24gdGl0bGU9J0NvZGUgSW5qZWN0aW9uIGFuZCBJbnB1dCBWYWxpZGF0aW9u Jz4KICAgICAgICA8dD4KICAgICAgICAgIEEgY29kZSBpbmplY3Rpb24gYXR0YWNrIG9jY3VycyB3 aGVuIGFuIGlucHV0IG9yIG90aGVyd2lzZSBleHRlcm5hbCB2YXJpYWJsZSBpcyB1c2VkIGJ5IGFu CiAgICAgICAgICBhcHBsaWNhdGlvbiB1bnNhbml0aXplZCBhbmQgY2F1c2VzIG1vZGlmaWNhdGlv biB0byB0aGUgYXBwbGljYXRpb24gbG9naWMuIFRoaXMgbWF5IGFsbG93CiAgICAgICAgICBhbiBh dHRhY2tlciB0byBnYWluIGFjY2VzcyB0byB0aGUgYXBwbGljYXRpb24gZGV2aWNlIG9yIGl0cyBk YXRhLCBjYXVzZSBkZW5pYWwgb2YKICAgICAgICAgIHNlcnZpY2UsIG9yIGEgd2lkZSByYW5nZSBv ZiBtYWxpY2lvdXMgc2lkZS1lZmZlY3RzLgogICAgICAgIDwvdD4KICAgICAgICA8dD4KICAgICAg ICAgIFRoZSBBdXRob3JpemF0aW9uIHNlcnZlciBhbmQgY2xpZW50IE1VU1Qgc2FuaXRpemUgKGFu ZCB2YWxpZGF0ZSB3aGVuIHBvc3NpYmxlKSBhbnkgdmFsdWUKICAgICAgICAgIHJlY2VpdmVkLCBp biBwYXJ0aWN1bGFyLCB0aGUgdmFsdWUgb2YgdGhlIDxzcGFueCBzdHlsZT0ndmVyYic+c3RhdGU8 L3NwYW54PiBhbmQKICAgICAgICAgIDxzcGFueCBzdHlsZT0ndmVyYic+cmVkaXJlY3RfdXJpPC9z cGFueD4gcGFyYW1ldGVycy4KICAgICAgICA8L3Q+CiAgICAgIDwvc2VjdGlvbj4KCiAgICAgIDxz ZWN0aW9uIHRpdGxlPSdPcGVuIFJlZGlyZWN0b3JzJyBhbmNob3I9J29wZW4tcmVkaXJlY3QnPgog ICAgICAgIDx0PgogICAgICAgICAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGF1dGhvcml6YXRp b24gZW5kcG9pbnQgYW5kIHRoZSBjbGllbnQgcmVkaXJlY3Rpb24gZW5kcG9pbnQgY2FuCiAgICAg ICAgICBiZSBpbXByb3Blcmx5IGNvbmZpZ3VyZWQgYW5kIG9wZXJhdGUgYXMgb3BlbiByZWRpcmVj dG9ycy4gQW4gb3BlbiByZWRpcmVjdG9yIGlzIGFuCiAgICAgICAgICBlbmRwb2ludCB1c2luZyBh IHBhcmFtZXRlciB0byBhdXRvbWF0aWNhbGx5IHJlZGlyZWN0IGEgdXNlci1hZ2VudCB0byB0aGUg bG9jYXRpb24KICAgICAgICAgIHNwZWNpZmllZCBieSB0aGUgcGFyYW1ldGVyIHZhbHVlIHdpdGhv dXQgYW55IHZhbGlkYXRpb24uCiAgICAgICAgPC90PgogICAgICAgIDx0PgogICAgICAgICAgT3Bl biByZWRpcmVjdG9ycyBjYW4gYmUgdXNlZCBpbiBwaGlzaGluZyBhdHRhY2tzLCBvciBieSBhbiBh dHRhY2tlciB0byBnZXQgZW5kLXVzZXJzIHRvCiAgICAgICAgICB2aXNpdCBtYWxpY2lvdXMgc2l0 ZXMgYnkgbWFraW5nIHRoZSBVUkkncyBhdXRob3JpdHkgbG9vayBsaWtlIGEgZmFtaWxpYXIgYW5k IHRydXN0ZWQKICAgICAgICAgIGRlc3RpbmF0aW9uLiBJbiBhZGRpdGlvbiwgaWYgdGhlIGF1dGhv cml6YXRpb24gc2VydmVyIGFsbG93cyB0aGUgY2xpZW50IHRvIHJlZ2lzdGVyIG9ubHkKICAgICAg ICAgIHBhcnQgb2YgdGhlIHJlZGlyZWN0aW9uIFVSSSwgYW4gYXR0YWNrZXIgY2FuIHVzZSBhbiBv cGVuIHJlZGlyZWN0b3Igb3BlcmF0ZWQgYnkgdGhlCiAgICAgICAgICBjbGllbnQgdG8gY29uc3Ry dWN0IGEgcmVkaXJlY3Rpb24gVVJJIHRoYXQgd2lsbCBwYXNzIHRoZSBhdXRob3JpemF0aW9uIHNl cnZlciB2YWxpZGF0aW9uCiAgICAgICAgICBidXQgd2lsbCBzZW5kIHRoZSBhdXRob3JpemF0aW9u IGNvZGUgb3IgYWNjZXNzIHRva2VuIHRvIGFuIGVuZHBvaW50IHVuZGVyIHRoZSBjb250cm9sIG9m CiAgICAgICAgICB0aGUgYXR0YWNrZXIuCiAgICAgICAgPC90PgogICAgICA8L3NlY3Rpb24+Cgog ICAgPC9zZWN0aW9uPgoKICAgIDxzZWN0aW9uIHRpdGxlPSdJQU5BIENvbnNpZGVyYXRpb25zJz4K CiAgICAgIDxzZWN0aW9uIHRpdGxlPSdUaGUgT0F1dGggQWNjZXNzIFRva2VuIFR5cGUgUmVnaXN0 cnknIGFuY2hvcj0ndHlwZS1yZWdpc3RyeSc+CiAgICAgICAgPHQ+CiAgICAgICAgICBUaGlzIHNw ZWNpZmljYXRpb24gZXN0YWJsaXNoZXMgdGhlIE9BdXRoIGFjY2VzcyB0b2tlbiB0eXBlIHJlZ2lz dHJ5LgogICAgICAgIDwvdD4KICAgICAgICA8dD4KICAgICAgICAgIEFjY2VzcyB0b2tlbiB0eXBl cyBhcmUgcmVnaXN0ZXJlZCB3aXRoIGEgU3BlY2lmaWNhdGlvbiBSZXF1aXJlZAogICAgICAgICAg KDx4cmVmIHRhcmdldD0nUkZDNTIyNicgLz4pIGFmdGVyIGEgdHdvIHdlZWsgcmV2aWV3IHBlcmlv ZCBvbiB0aGUgW1RCRF1AaWV0Zi5vcmcgbWFpbGluZwogICAgICAgICAgbGlzdCwgb24gdGhlIGFk dmljZSBvZiBvbmUgb3IgbW9yZSBEZXNpZ25hdGVkIEV4cGVydHMuIEhvd2V2ZXIsIHRvIGFsbG93 IGZvciB0aGUKICAgICAgICAgIGFsbG9jYXRpb24gb2YgdmFsdWVzIHByaW9yIHRvIHB1YmxpY2F0 aW9uLCB0aGUgRGVzaWduYXRlZCBFeHBlcnQocykgbWF5IGFwcHJvdmUKICAgICAgICAgIHJlZ2lz dHJhdGlvbiBvbmNlIHRoZXkgYXJlIHNhdGlzZmllZCB0aGF0IHN1Y2ggYSBzcGVjaWZpY2F0aW9u IHdpbGwgYmUgcHVibGlzaGVkLgogICAgICAgIDwvdD4KICAgICAgICA8dD4KICAgICAgICAgIFJl Z2lzdHJhdGlvbiByZXF1ZXN0cyBtdXN0IGJlIHNlbnQgdG8gdGhlIFtUQkRdQGlldGYub3JnIG1h aWxpbmcgbGlzdCBmb3IgcmV2aWV3IGFuZAogICAgICAgICAgY29tbWVudCwgd2l0aCBhbiBhcHBy b3ByaWF0ZSBzdWJqZWN0IChlLmcuLCAiUmVxdWVzdCBmb3IgYWNjZXNzIHRva2VuIHR5cGU6IGV4 YW1wbGUiKS4KICAgICAgICAgIFtbIE5vdGUgdG8gUkZDLUVESVRPUjogVGhlIG5hbWUgb2YgdGhl IG1haWxpbmcgbGlzdCBzaG91bGQgYmUgZGV0ZXJtaW5lZCBpbiBjb25zdWx0YXRpb24KICAgICAg ICAgIHdpdGggdGhlIElFU0cgYW5kIElBTkEuIFN1Z2dlc3RlZCBuYW1lOiBvYXV0aC1leHQtcmV2 aWV3LiBdXQogICAgICAgIDwvdD4KICAgICAgICA8dD4KICAgICAgICAgIFdpdGhpbiB0aGUgcmV2 aWV3IHBlcmlvZCwgdGhlIERlc2lnbmF0ZWQgRXhwZXJ0KHMpIHdpbGwgZWl0aGVyIGFwcHJvdmUg b3IKICAgICAgICAgIGRlbnkgdGhlIHJlZ2lzdHJhdGlvbiByZXF1ZXN0LCBjb21tdW5pY2F0aW5n IHRoaXMgZGVjaXNpb24gdG8gdGhlIHJldmlldyBsaXN0IGFuZCBJQU5BLgogICAgICAgICAgRGVu aWFscyBzaG91bGQgaW5jbHVkZSBhbiBleHBsYW5hdGlvbiBhbmQsIGlmIGFwcGxpY2FibGUsIHN1 Z2dlc3Rpb25zIGFzIHRvIGhvdyB0byBtYWtlCiAgICAgICAgICB0aGUgcmVxdWVzdCBzdWNjZXNz ZnVsLgogICAgICAgIDwvdD4KICAgICAgICA8dD4KICAgICAgICAgIElBTkEgbXVzdCBvbmx5IGFj Y2VwdCByZWdpc3RyeSB1cGRhdGVzIGZyb20gdGhlIERlc2lnbmF0ZWQgRXhwZXJ0KHMpLCBhbmQg c2hvdWxkIGRpcmVjdAogICAgICAgICAgYWxsIHJlcXVlc3RzIGZvciByZWdpc3RyYXRpb24gdG8g dGhlIHJldmlldyBtYWlsaW5nIGxpc3QuCiAgICAgICAgPC90PgoKICAgICAgICA8c2VjdGlvbiB0 aXRsZT0nUmVnaXN0cmF0aW9uIFRlbXBsYXRlJz4KICAgICAgICAgIDx0PgogICAgICAgICAgICA8 bGlzdCBzdHlsZT0naGFuZ2luZyc+CiAgICAgICAgICAgICAgPHQgaGFuZ1RleHQ9J1R5cGUgbmFt ZTonPgogICAgICAgICAgICAgICAgPHZzcGFjZSAvPgogICAgICAgICAgICAgICAgVGhlIG5hbWUg cmVxdWVzdGVkIChlLmcuLCAiZXhhbXBsZSIpLgogICAgICAgICAgICAgIDwvdD4KICAgICAgICAg ICAgICA8dCBoYW5nVGV4dD0nQWRkaXRpb25hbCBUb2tlbiBFbmRwb2ludCBSZXNwb25zZSBQYXJh bWV0ZXJzOic+CiAgICAgICAgICAgICAgICA8dnNwYWNlIC8+CiAgICAgICAgICAgICAgICBBZGRp dGlvbmFsIHJlc3BvbnNlIHBhcmFtZXRlcnMgcmV0dXJuZWQgdG9nZXRoZXIgd2l0aCB0aGUKICAg ICAgICAgICAgICAgIDxzcGFueCBzdHlsZT0ndmVyYic+YWNjZXNzX3Rva2VuPC9zcGFueD4gcGFy YW1ldGVyLiBOZXcgcGFyYW1ldGVycyBNVVNUIGJlCiAgICAgICAgICAgICAgICBzZXBhcmF0ZWx5 IHJlZ2lzdGVyZWQgaW4gdGhlIE9BdXRoIHBhcmFtZXRlcnMgcmVnaXN0cnkgYXMgZGVzY3JpYmVk IGJ5CiAgICAgICAgICAgICAgICA8eHJlZiB0YXJnZXQ9J3BhcmFtZXRlcnMtcmVnaXN0cnknIC8+ LgogICAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAgICA8dCBoYW5nVGV4dD0nSFRUUCBBdXRo ZW50aWNhdGlvbiBTY2hlbWUocyk6Jz4KICAgICAgICAgICAgICAgIDx2c3BhY2UgLz4KICAgICAg ICAgICAgICAgIFRoZSBIVFRQIGF1dGhlbnRpY2F0aW9uIHNjaGVtZSBuYW1lKHMpLCBpZiBhbnks IHVzZWQgdG8gYXV0aGVudGljYXRlIHByb3RlY3RlZAogICAgICAgICAgICAgICAgcmVzb3VyY2Vz IHJlcXVlc3RzIHVzaW5nIGFjY2VzcyB0b2tlbnMgb2YgdGhpcyB0eXBlLgogICAgICAgICAgICAg IDwvdD4KICAgICAgICAgICAgICA8dCBoYW5nVGV4dD0nQ2hhbmdlIGNvbnRyb2xsZXI6Jz4KICAg ICAgICAgICAgICAgIDx2c3BhY2UgLz4KICAgICAgICAgICAgICAgIEZvciBzdGFuZGFyZHMtdHJh Y2sgUkZDcywgc3RhdGUgIklFVEYiLiBGb3Igb3RoZXJzLCBnaXZlIHRoZSBuYW1lIG9mIHRoZQog ICAgICAgICAgICAgICAgcmVzcG9uc2libGUgcGFydHkuIE90aGVyIGRldGFpbHMgKGUuZy4sIHBv c3RhbCBhZGRyZXNzLCBlLW1haWwgYWRkcmVzcywgaG9tZSBwYWdlCiAgICAgICAgICAgICAgICBV UkkpIG1heSBhbHNvIGJlIGluY2x1ZGVkLgogICAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAg ICA8dCBoYW5nVGV4dD0nU3BlY2lmaWNhdGlvbiBkb2N1bWVudChzKTonPgogICAgICAgICAgICAg ICAgPHZzcGFjZSAvPgogICAgICAgICAgICAgICAgUmVmZXJlbmNlIHRvIHRoZSBkb2N1bWVudCB0 aGF0IHNwZWNpZmllcyB0aGUgcGFyYW1ldGVyLCBwcmVmZXJhYmx5IGluY2x1ZGluZyBhIFVSSSB0 aGF0CiAgICAgICAgICAgICAgICBjYW4gYmUgdXNlZCB0byByZXRyaWV2ZSBhIGNvcHkgb2YgdGhl IGRvY3VtZW50LiBBbiBpbmRpY2F0aW9uIG9mIHRoZSByZWxldmFudAogICAgICAgICAgICAgICAg c2VjdGlvbnMgbWF5IGFsc28gYmUgaW5jbHVkZWQsIGJ1dCBpcyBub3QgcmVxdWlyZWQuCiAgICAg ICAgICAgICAgPC90PgogICAgICAgICAgICA8L2xpc3Q+CiAgICAgICAgICA8L3Q+CiAgICAgICAg PC9zZWN0aW9uPgoKICAgICAgPC9zZWN0aW9uPgoKICAgICAgPHNlY3Rpb24gdGl0bGU9J1RoZSBP QXV0aCBQYXJhbWV0ZXJzIFJlZ2lzdHJ5JyBhbmNob3I9J3BhcmFtZXRlcnMtcmVnaXN0cnknPgog ICAgICAgIDx0PgogICAgICAgICAgVGhpcyBzcGVjaWZpY2F0aW9uIGVzdGFibGlzaGVzIHRoZSBP QXV0aCBwYXJhbWV0ZXJzIHJlZ2lzdHJ5LgogICAgICAgIDwvdD4KICAgICAgICA8dD4KICAgICAg ICAgIEFkZGl0aW9uYWwgcGFyYW1ldGVycyBmb3IgaW5jbHVzaW9uIGluIHRoZSBhdXRob3JpemF0 aW9uIGVuZHBvaW50IHJlcXVlc3QsIHRoZQogICAgICAgICAgYXV0aG9yaXphdGlvbiBlbmRwb2lu dCByZXNwb25zZSwgdGhlIHRva2VuIGVuZHBvaW50IHJlcXVlc3QsIG9yIHRoZSB0b2tlbiBlbmRw b2ludAogICAgICAgICAgcmVzcG9uc2UgYXJlIHJlZ2lzdGVyZWQgd2l0aCBhIFNwZWNpZmljYXRp b24gUmVxdWlyZWQKICAgICAgICAgICg8eHJlZiB0YXJnZXQ9J1JGQzUyMjYnIC8+KSBhZnRlciBh IHR3byB3ZWVrIHJldmlldyBwZXJpb2Qgb24gdGhlIFtUQkRdQGlldGYub3JnIG1haWxpbmcKICAg ICAgICAgIGxpc3QsIG9uIHRoZSBhZHZpY2Ugb2Ygb25lIG9yIG1vcmUgRGVzaWduYXRlZCBFeHBl cnRzLiBIb3dldmVyLCB0byBhbGxvdyBmb3IgdGhlCiAgICAgICAgICBhbGxvY2F0aW9uIG9mIHZh bHVlcyBwcmlvciB0byBwdWJsaWNhdGlvbiwgdGhlIERlc2lnbmF0ZWQgRXhwZXJ0KHMpIG1heSBh cHByb3ZlCiAgICAgICAgICByZWdpc3RyYXRpb24gb25jZSB0aGV5IGFyZSBzYXRpc2ZpZWQgdGhh dCBzdWNoIGEgc3BlY2lmaWNhdGlvbiB3aWxsIGJlIHB1Ymxpc2hlZC4KICAgICAgICA8L3Q+CiAg ICAgICAgPHQ+CiAgICAgICAgICBSZWdpc3RyYXRpb24gcmVxdWVzdHMgbXVzdCBiZSBzZW50IHRv IHRoZSBbVEJEXUBpZXRmLm9yZyBtYWlsaW5nIGxpc3QgZm9yIHJldmlldyBhbmQKICAgICAgICAg IGNvbW1lbnQsIHdpdGggYW4gYXBwcm9wcmlhdGUgc3ViamVjdCAoZS5nLiwgIlJlcXVlc3QgZm9y IHBhcmFtZXRlcjogZXhhbXBsZSIpLgogICAgICAgICAgW1sgTm90ZSB0byBSRkMtRURJVE9SOiBU aGUgbmFtZSBvZiB0aGUgbWFpbGluZyBsaXN0IHNob3VsZCBiZSBkZXRlcm1pbmVkIGluIGNvbnN1 bHRhdGlvbgogICAgICAgICAgd2l0aCB0aGUgSUVTRyBhbmQgSUFOQS4gU3VnZ2VzdGVkIG5hbWU6 IG9hdXRoLWV4dC1yZXZpZXcuIF1dCiAgICAgICAgPC90PgogICAgICAgIDx0PgogICAgICAgICAg V2l0aGluIHRoZSByZXZpZXcgcGVyaW9kLCB0aGUgRGVzaWduYXRlZCBFeHBlcnQocykgd2lsbCBl aXRoZXIgYXBwcm92ZSBvcgogICAgICAgICAgZGVueSB0aGUgcmVnaXN0cmF0aW9uIHJlcXVlc3Qs IGNvbW11bmljYXRpbmcgdGhpcyBkZWNpc2lvbiB0byB0aGUgcmV2aWV3IGxpc3QgYW5kIElBTkEu CiAgICAgICAgICBEZW5pYWxzIHNob3VsZCBpbmNsdWRlIGFuIGV4cGxhbmF0aW9uIGFuZCwgaWYg YXBwbGljYWJsZSwgc3VnZ2VzdGlvbnMgYXMgdG8gaG93IHRvIG1ha2UKICAgICAgICAgIHRoZSBy ZXF1ZXN0IHN1Y2Nlc3NmdWwuCiAgICAgICAgPC90PgogICAgICAgIDx0PgogICAgICAgICAgSUFO QSBtdXN0IG9ubHkgYWNjZXB0IHJlZ2lzdHJ5IHVwZGF0ZXMgZnJvbSB0aGUgRGVzaWduYXRlZCBF eHBlcnQocyksIGFuZCBzaG91bGQgZGlyZWN0CiAgICAgICAgICBhbGwgcmVxdWVzdHMgZm9yIHJl Z2lzdHJhdGlvbiB0byB0aGUgcmV2aWV3IG1haWxpbmcgbGlzdC4KICAgICAgICA8L3Q+CgogICAg ICAgIDxzZWN0aW9uIHRpdGxlPSdSZWdpc3RyYXRpb24gVGVtcGxhdGUnPgogICAgICAgICAgPHQ+ CiAgICAgICAgICAgIDxsaXN0IHN0eWxlPSdoYW5naW5nJz4KICAgICAgICAgICAgICA8dCBoYW5n VGV4dD0nUGFyYW1ldGVyIG5hbWU6Jz4KICAgICAgICAgICAgICAgIDx2c3BhY2UgLz4KICAgICAg ICAgICAgICAgIFRoZSBuYW1lIHJlcXVlc3RlZCAoZS5nLiwgImV4YW1wbGUiKS4KICAgICAgICAg ICAgICA8L3Q+CiAgICAgICAgICAgICAgPHQgaGFuZ1RleHQ9J1BhcmFtZXRlciB1c2FnZSBsb2Nh dGlvbjonPgogICAgICAgICAgICAgICAgPHZzcGFjZSAvPgogICAgICAgICAgICAgICAgVGhlIGxv Y2F0aW9uKHMpIHdoZXJlIHBhcmFtZXRlciBjYW4gYmUgdXNlZC4gVGhlIHBvc3NpYmxlIGxvY2F0 aW9ucyBhcmU6CiAgICAgICAgICAgICAgICBhdXRob3JpemF0aW9uIHJlcXVlc3QsIGF1dGhvcml6 YXRpb24gcmVzcG9uc2UsIHRva2VuIHJlcXVlc3QsIG9yIHRva2VuIHJlc3BvbnNlLgogICAgICAg ICAgICAgIDwvdD4KICAgICAgICAgICAgICA8dCBoYW5nVGV4dD0nQ2hhbmdlIGNvbnRyb2xsZXI6 Jz4KICAgICAgICAgICAgICAgIDx2c3BhY2UgLz4KICAgICAgICAgICAgICAgIEZvciBzdGFuZGFy ZHMtdHJhY2sgUkZDcywgc3RhdGUgIklFVEYiLiBGb3Igb3RoZXJzLCBnaXZlIHRoZSBuYW1lIG9m IHRoZQogICAgICAgICAgICAgICAgcmVzcG9uc2libGUgcGFydHkuIE90aGVyIGRldGFpbHMgKGUu Zy4sIHBvc3RhbCBhZGRyZXNzLCBlLW1haWwgYWRkcmVzcywgaG9tZSBwYWdlCiAgICAgICAgICAg ICAgICBVUkkpIG1heSBhbHNvIGJlIGluY2x1ZGVkLgogICAgICAgICAgICAgIDwvdD4KICAgICAg ICAgICAgICA8dCBoYW5nVGV4dD0nU3BlY2lmaWNhdGlvbiBkb2N1bWVudChzKTonPgogICAgICAg ICAgICAgICAgPHZzcGFjZSAvPgogICAgICAgICAgICAgICAgUmVmZXJlbmNlIHRvIHRoZSBkb2N1 bWVudCB0aGF0IHNwZWNpZmllcyB0aGUgcGFyYW1ldGVyLCBwcmVmZXJhYmx5IGluY2x1ZGluZyBh IFVSSSB0aGF0CiAgICAgICAgICAgICAgICBjYW4gYmUgdXNlZCB0byByZXRyaWV2ZSBhIGNvcHkg b2YgdGhlIGRvY3VtZW50LiBBbiBpbmRpY2F0aW9uIG9mIHRoZSByZWxldmFudAogICAgICAgICAg ICAgICAgc2VjdGlvbnMgbWF5IGFsc28gYmUgaW5jbHVkZWQsIGJ1dCBpcyBub3QgcmVxdWlyZWQu CiAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICA8L2xpc3Q+CiAgICAgICAgICA8L3Q+CiAg ICAgICAgPC9zZWN0aW9uPgoKICAgICAgICA8c2VjdGlvbiB0aXRsZT0nSW5pdGlhbCBSZWdpc3Ry eSBDb250ZW50cyc+CiAgICAgICAgICA8dD4KICAgICAgICAgICAgVGhlIE9BdXRoIFBhcmFtZXRl cnMgUmVnaXN0cnkncyBpbml0aWFsIGNvbnRlbnRzIGFyZToKICAgICAgICAgIDwvdD4KICAgICAg ICAgIDx0PgogICAgICAgICAgICA8bGlzdCBzdHlsZT0nc3ltYm9scyc+CiAgICAgICAgICAgICAg PHQ+CiAgICAgICAgICAgICAgICBQYXJhbWV0ZXIgbmFtZTogY2xpZW50X2lkCiAgICAgICAgICAg ICAgPC90PgogICAgICAgICAgICAgIDx0PgogICAgICAgICAgICAgICAgUGFyYW1ldGVyIHVzYWdl IGxvY2F0aW9uOiBhdXRob3JpemF0aW9uIHJlcXVlc3QsIHRva2VuIHJlcXVlc3QKICAgICAgICAg ICAgICA8L3Q+CiAgICAgICAgICAgICAgPHQ+CiAgICAgICAgICAgICAgICBDaGFuZ2UgY29udHJv bGxlcjogSUVURgogICAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAgICA8dD4KICAgICAgICAg ICAgICAgIFNwZWNpZmljYXRpb24gZG9jdW1lbnQocyk6IFtbIHRoaXMgZG9jdW1lbnQgXV0KICAg ICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgIDwvbGlzdD4KICAgICAgICAgIDwvdD4KICAgICAg ICAgIDx0PgogICAgICAgICAgICA8bGlzdCBzdHlsZT0nc3ltYm9scyc+CiAgICAgICAgICAgICAg PHQ+CiAgICAgICAgICAgICAgICBQYXJhbWV0ZXIgbmFtZTogY2xpZW50X3NlY3JldAogICAgICAg ICAgICAgIDwvdD4KICAgICAgICAgICAgICA8dD4KICAgICAgICAgICAgICAgIFBhcmFtZXRlciB1 c2FnZSBsb2NhdGlvbjogdG9rZW4gcmVxdWVzdAogICAgICAgICAgICAgIDwvdD4KICAgICAgICAg ICAgICA8dD4KICAgICAgICAgICAgICAgIENoYW5nZSBjb250cm9sbGVyOiBJRVRGCiAgICAgICAg ICAgICAgPC90PgogICAgICAgICAgICAgIDx0PgogICAgICAgICAgICAgICAgU3BlY2lmaWNhdGlv biBkb2N1bWVudChzKTogW1sgdGhpcyBkb2N1bWVudCBdXQogICAgICAgICAgICAgIDwvdD4KICAg ICAgICAgICAgPC9saXN0PgogICAgICAgICAgPC90PgogICAgICAgICAgPHQ+CiAgICAgICAgICAg IDxsaXN0IHN0eWxlPSdzeW1ib2xzJz4KICAgICAgICAgICAgICA8dD4KICAgICAgICAgICAgICAg IFBhcmFtZXRlciBuYW1lOiByZXNwb25zZV90eXBlCiAgICAgICAgICAgICAgPC90PgogICAgICAg ICAgICAgIDx0PgogICAgICAgICAgICAgICAgUGFyYW1ldGVyIHVzYWdlIGxvY2F0aW9uOiBhdXRo b3JpemF0aW9uIHJlcXVlc3QKICAgICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgICAgPHQ+CiAg ICAgICAgICAgICAgICBDaGFuZ2UgY29udHJvbGxlcjogSUVURgogICAgICAgICAgICAgIDwvdD4K ICAgICAgICAgICAgICA8dD4KICAgICAgICAgICAgICAgIFNwZWNpZmljYXRpb24gZG9jdW1lbnQo cyk6IFtbIHRoaXMgZG9jdW1lbnQgXV0KICAgICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgIDwv bGlzdD4KICAgICAgICAgIDwvdD4KICAgICAgICAgIDx0PgogICAgICAgICAgICA8bGlzdCBzdHls ZT0nc3ltYm9scyc+CiAgICAgICAgICAgICAgPHQ+CiAgICAgICAgICAgICAgICBQYXJhbWV0ZXIg bmFtZTogcmVkaXJlY3RfdXJpCiAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICAgIDx0Pgog ICAgICAgICAgICAgICAgUGFyYW1ldGVyIHVzYWdlIGxvY2F0aW9uOiBhdXRob3JpemF0aW9uIHJl cXVlc3QsIHRva2VuIHJlcXVlc3QKICAgICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgICAgPHQ+ CiAgICAgICAgICAgICAgICBDaGFuZ2UgY29udHJvbGxlcjogSUVURgogICAgICAgICAgICAgIDwv dD4KICAgICAgICAgICAgICA8dD4KICAgICAgICAgICAgICAgIFNwZWNpZmljYXRpb24gZG9jdW1l bnQocyk6IFtbIHRoaXMgZG9jdW1lbnQgXV0KICAgICAgICAgICAgICA8L3Q+CiAgICAgICAgICAg IDwvbGlzdD4KICAgICAgICAgIDwvdD4KICAgICAgICAgIDx0PgogICAgICAgICAgICA8bGlzdCBz dHlsZT0nc3ltYm9scyc+CiAgICAgICAgICAgICAgPHQ+CiAgICAgICAgICAgICAgICBQYXJhbWV0 ZXIgbmFtZTogc2NvcGUKICAgICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgICAgPHQ+CiAgICAg ICAgICAgICAgICBQYXJhbWV0ZXIgdXNhZ2UgbG9jYXRpb246IGF1dGhvcml6YXRpb24gcmVxdWVz dCwgYXV0aG9yaXphdGlvbiByZXNwb25zZSwgdG9rZW4KICAgICAgICAgICAgICAgIHJlcXVlc3Qs IHRva2VuIHJlc3BvbnNlCiAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICAgIDx0PgogICAg ICAgICAgICAgICAgQ2hhbmdlIGNvbnRyb2xsZXI6IElFVEYKICAgICAgICAgICAgICA8L3Q+CiAg ICAgICAgICAgICAgPHQ+CiAgICAgICAgICAgICAgICBTcGVjaWZpY2F0aW9uIGRvY3VtZW50KHMp OiBbWyB0aGlzIGRvY3VtZW50IF1dCiAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICA8L2xp c3Q+CiAgICAgICAgICA8L3Q+CiAgICAgICAgICA8dD4KICAgICAgICAgICAgPGxpc3Qgc3R5bGU9 J3N5bWJvbHMnPgogICAgICAgICAgICAgIDx0PgogICAgICAgICAgICAgICAgUGFyYW1ldGVyIG5h bWU6IHN0YXRlCiAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICAgIDx0PgogICAgICAgICAg ICAgICAgUGFyYW1ldGVyIHVzYWdlIGxvY2F0aW9uOiBhdXRob3JpemF0aW9uIHJlcXVlc3QsIGF1 dGhvcml6YXRpb24gcmVzcG9uc2UKICAgICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgICAgPHQ+ CiAgICAgICAgICAgICAgICBDaGFuZ2UgY29udHJvbGxlcjogSUVURgogICAgICAgICAgICAgIDwv dD4KICAgICAgICAgICAgICA8dD4KICAgICAgICAgICAgICAgIFNwZWNpZmljYXRpb24gZG9jdW1l bnQocyk6IFtbIHRoaXMgZG9jdW1lbnQgXV0KICAgICAgICAgICAgICA8L3Q+CiAgICAgICAgICAg IDwvbGlzdD4KICAgICAgICAgIDwvdD4KICAgICAgICAgIDx0PgogICAgICAgICAgICA8bGlzdCBz dHlsZT0nc3ltYm9scyc+CiAgICAgICAgICAgICAgPHQ+CiAgICAgICAgICAgICAgICBQYXJhbWV0 ZXIgbmFtZTogY29kZQogICAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAgICA8dD4KICAgICAg ICAgICAgICAgIFBhcmFtZXRlciB1c2FnZSBsb2NhdGlvbjogYXV0aG9yaXphdGlvbiByZXNwb25z ZSwgdG9rZW4gcmVxdWVzdAogICAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAgICA8dD4KICAg ICAgICAgICAgICAgIENoYW5nZSBjb250cm9sbGVyOiBJRVRGCiAgICAgICAgICAgICAgPC90Pgog ICAgICAgICAgICAgIDx0PgogICAgICAgICAgICAgICAgU3BlY2lmaWNhdGlvbiBkb2N1bWVudChz KTogW1sgdGhpcyBkb2N1bWVudCBdXQogICAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAgPC9s aXN0PgogICAgICAgICAgPC90PgogICAgICAgICAgPHQ+CiAgICAgICAgICAgIDxsaXN0IHN0eWxl PSdzeW1ib2xzJz4KICAgICAgICAgICAgICA8dD4KICAgICAgICAgICAgICAgIFBhcmFtZXRlciBu YW1lOiBlcnJvcl9kZXNjcmlwdGlvbgogICAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAgICA8 dD4KICAgICAgICAgICAgICAgIFBhcmFtZXRlciB1c2FnZSBsb2NhdGlvbjogYXV0aG9yaXphdGlv biByZXNwb25zZSwgdG9rZW4gcmVzcG9uc2UKICAgICAgICAgICAgICA8L3Q+CiAgICAgICAgICAg ICAgPHQ+CiAgICAgICAgICAgICAgICBDaGFuZ2UgY29udHJvbGxlcjogSUVURgogICAgICAgICAg ICAgIDwvdD4KICAgICAgICAgICAgICA8dD4KICAgICAgICAgICAgICAgIFNwZWNpZmljYXRpb24g ZG9jdW1lbnQocyk6IFtbIHRoaXMgZG9jdW1lbnQgXV0KICAgICAgICAgICAgICA8L3Q+CiAgICAg ICAgICAgIDwvbGlzdD4KICAgICAgICAgIDwvdD4KICAgICAgICAgIDx0PgogICAgICAgICAgICA8 bGlzdCBzdHlsZT0nc3ltYm9scyc+CiAgICAgICAgICAgICAgPHQ+CiAgICAgICAgICAgICAgICBQ YXJhbWV0ZXIgbmFtZTogZXJyb3JfdXJpCiAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICAg IDx0PgogICAgICAgICAgICAgICAgUGFyYW1ldGVyIHVzYWdlIGxvY2F0aW9uOiBhdXRob3JpemF0 aW9uIHJlc3BvbnNlLCB0b2tlbiByZXNwb25zZQogICAgICAgICAgICAgIDwvdD4KICAgICAgICAg ICAgICA8dD4KICAgICAgICAgICAgICAgIENoYW5nZSBjb250cm9sbGVyOiBJRVRGCiAgICAgICAg ICAgICAgPC90PgogICAgICAgICAgICAgIDx0PgogICAgICAgICAgICAgICAgU3BlY2lmaWNhdGlv biBkb2N1bWVudChzKTogW1sgdGhpcyBkb2N1bWVudCBdXQogICAgICAgICAgICAgIDwvdD4KICAg ICAgICAgICAgPC9saXN0PgogICAgICAgICAgPC90PgogICAgICAgICAgPHQ+CiAgICAgICAgICAg IDxsaXN0IHN0eWxlPSdzeW1ib2xzJz4KICAgICAgICAgICAgICA8dD4KICAgICAgICAgICAgICAg IFBhcmFtZXRlciBuYW1lOiBncmFudF90eXBlCiAgICAgICAgICAgICAgPC90PgogICAgICAgICAg ICAgIDx0PgogICAgICAgICAgICAgICAgUGFyYW1ldGVyIHVzYWdlIGxvY2F0aW9uOiB0b2tlbiBy ZXF1ZXN0CiAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICAgIDx0PgogICAgICAgICAgICAg ICAgQ2hhbmdlIGNvbnRyb2xsZXI6IElFVEYKICAgICAgICAgICAgICA8L3Q+CiAgICAgICAgICAg ICAgPHQ+CiAgICAgICAgICAgICAgICBTcGVjaWZpY2F0aW9uIGRvY3VtZW50KHMpOiBbWyB0aGlz IGRvY3VtZW50IF1dCiAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICA8L2xpc3Q+CiAgICAg ICAgICA8L3Q+CiAgICAgICAgICA8dD4KICAgICAgICAgICAgPGxpc3Qgc3R5bGU9J3N5bWJvbHMn PgogICAgICAgICAgICAgIDx0PgogICAgICAgICAgICAgICAgUGFyYW1ldGVyIG5hbWU6IGFjY2Vz c190b2tlbgogICAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAgICA8dD4KICAgICAgICAgICAg ICAgIFBhcmFtZXRlciB1c2FnZSBsb2NhdGlvbjogYXV0aG9yaXphdGlvbiByZXNwb25zZSwgdG9r ZW4gcmVzcG9uc2UKICAgICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgICAgPHQ+CiAgICAgICAg ICAgICAgICBDaGFuZ2UgY29udHJvbGxlcjogSUVURgogICAgICAgICAgICAgIDwvdD4KICAgICAg ICAgICAgICA8dD4KICAgICAgICAgICAgICAgIFNwZWNpZmljYXRpb24gZG9jdW1lbnQocyk6IFtb IHRoaXMgZG9jdW1lbnQgXV0KICAgICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgIDwvbGlzdD4K ICAgICAgICAgIDwvdD4KICAgICAgICAgIDx0PgogICAgICAgICAgICA8bGlzdCBzdHlsZT0nc3lt Ym9scyc+CiAgICAgICAgICAgICAgPHQ+CiAgICAgICAgICAgICAgICBQYXJhbWV0ZXIgbmFtZTog dG9rZW5fdHlwZQogICAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAgICA8dD4KICAgICAgICAg ICAgICAgIFBhcmFtZXRlciB1c2FnZSBsb2NhdGlvbjogYXV0aG9yaXphdGlvbiByZXNwb25zZSwg dG9rZW4gcmVzcG9uc2UKICAgICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgICAgPHQ+CiAgICAg ICAgICAgICAgICBDaGFuZ2UgY29udHJvbGxlcjogSUVURgogICAgICAgICAgICAgIDwvdD4KICAg ICAgICAgICAgICA8dD4KICAgICAgICAgICAgICAgIFNwZWNpZmljYXRpb24gZG9jdW1lbnQocyk6 IFtbIHRoaXMgZG9jdW1lbnQgXV0KICAgICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgIDwvbGlz dD4KICAgICAgICAgIDwvdD4KICAgICAgICAgIDx0PgogICAgICAgICAgICA8bGlzdCBzdHlsZT0n c3ltYm9scyc+CiAgICAgICAgICAgICAgPHQ+CiAgICAgICAgICAgICAgICBQYXJhbWV0ZXIgbmFt ZTogZXhwaXJlc19pbgogICAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAgICA8dD4KICAgICAg ICAgICAgICAgIFBhcmFtZXRlciB1c2FnZSBsb2NhdGlvbjogYXV0aG9yaXphdGlvbiByZXNwb25z ZSwgdG9rZW4gcmVzcG9uc2UKICAgICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgICAgPHQ+CiAg ICAgICAgICAgICAgICBDaGFuZ2UgY29udHJvbGxlcjogSUVURgogICAgICAgICAgICAgIDwvdD4K ICAgICAgICAgICAgICA8dD4KICAgICAgICAgICAgICAgIFNwZWNpZmljYXRpb24gZG9jdW1lbnQo cyk6IFtbIHRoaXMgZG9jdW1lbnQgXV0KICAgICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgIDwv bGlzdD4KICAgICAgICAgIDwvdD4KICAgICAgICAgIDx0PgogICAgICAgICAgICA8bGlzdCBzdHls ZT0nc3ltYm9scyc+CiAgICAgICAgICAgICAgPHQ+CiAgICAgICAgICAgICAgICBQYXJhbWV0ZXIg bmFtZTogdXNlcm5hbWUKICAgICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgICAgPHQ+CiAgICAg ICAgICAgICAgICBQYXJhbWV0ZXIgdXNhZ2UgbG9jYXRpb246IHRva2VuIHJlcXVlc3QKICAgICAg ICAgICAgICA8L3Q+CiAgICAgICAgICAgICAgPHQ+CiAgICAgICAgICAgICAgICBDaGFuZ2UgY29u dHJvbGxlcjogSUVURgogICAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAgICA8dD4KICAgICAg ICAgICAgICAgIFNwZWNpZmljYXRpb24gZG9jdW1lbnQocyk6IFtbIHRoaXMgZG9jdW1lbnQgXV0K ICAgICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgIDwvbGlzdD4KICAgICAgICAgIDwvdD4KICAg ICAgICAgIDx0PgogICAgICAgICAgICA8bGlzdCBzdHlsZT0nc3ltYm9scyc+CiAgICAgICAgICAg ICAgPHQ+CiAgICAgICAgICAgICAgICBQYXJhbWV0ZXIgbmFtZTogcGFzc3dvcmQKICAgICAgICAg ICAgICA8L3Q+CiAgICAgICAgICAgICAgPHQ+CiAgICAgICAgICAgICAgICBQYXJhbWV0ZXIgdXNh Z2UgbG9jYXRpb246IHRva2VuIHJlcXVlc3QKICAgICAgICAgICAgICA8L3Q+CiAgICAgICAgICAg ICAgPHQ+CiAgICAgICAgICAgICAgICBDaGFuZ2UgY29udHJvbGxlcjogSUVURgogICAgICAgICAg ICAgIDwvdD4KICAgICAgICAgICAgICA8dD4KICAgICAgICAgICAgICAgIFNwZWNpZmljYXRpb24g ZG9jdW1lbnQocyk6IFtbIHRoaXMgZG9jdW1lbnQgXV0KICAgICAgICAgICAgICA8L3Q+CiAgICAg ICAgICAgIDwvbGlzdD4KICAgICAgICAgIDwvdD4KICAgICAgICAgIDx0PgogICAgICAgICAgICA8 bGlzdCBzdHlsZT0nc3ltYm9scyc+CiAgICAgICAgICAgICAgPHQ+CiAgICAgICAgICAgICAgICBQ YXJhbWV0ZXIgbmFtZTogcmVmcmVzaF90b2tlbgogICAgICAgICAgICAgIDwvdD4KICAgICAgICAg ICAgICA8dD4KICAgICAgICAgICAgICAgIFBhcmFtZXRlciB1c2FnZSBsb2NhdGlvbjogdG9rZW4g cmVxdWVzdCwgdG9rZW4gcmVzcG9uc2UKICAgICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgICAg PHQ+CiAgICAgICAgICAgICAgICBDaGFuZ2UgY29udHJvbGxlcjogSUVURgogICAgICAgICAgICAg IDwvdD4KICAgICAgICAgICAgICA8dD4KICAgICAgICAgICAgICAgIFNwZWNpZmljYXRpb24gZG9j dW1lbnQocyk6IFtbIHRoaXMgZG9jdW1lbnQgXV0KICAgICAgICAgICAgICA8L3Q+CiAgICAgICAg ICAgIDwvbGlzdD4KICAgICAgICAgIDwvdD4KICAgICAgICA8L3NlY3Rpb24+CgogICAgICA8L3Nl Y3Rpb24+CgogICAgICA8c2VjdGlvbiB0aXRsZT0nVGhlIE9BdXRoIEF1dGhvcml6YXRpb24gRW5k cG9pbnQgUmVzcG9uc2UgVHlwZSBSZWdpc3RyeScgYW5jaG9yPSdyZXNwb25zZS10eXBlLXJlZ2lz dHJ5Jz4KICAgICAgICA8dD4KICAgICAgICAgIFRoaXMgc3BlY2lmaWNhdGlvbiBlc3RhYmxpc2hl cyB0aGUgT0F1dGggYXV0aG9yaXphdGlvbiBlbmRwb2ludCByZXNwb25zZSB0eXBlIHJlZ2lzdHJ5 LgogICAgICAgIDwvdD4KICAgICAgICA8dD4KICAgICAgICAgICAgQWRkaXRpb25hbCByZXNwb25z ZSB0eXBlIGZvciB1c2Ugd2l0aCB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludCBhcmUgcmVnaXN0 ZXJlZCB3aXRoIGEKICAgICAgICAgICAgU3BlY2lmaWNhdGlvbiBSZXF1aXJlZCAoPHhyZWYgdGFy Z2V0PSdSRkM1MjI2JyAvPikgYWZ0ZXIgYSB0d28gd2VlayByZXZpZXcgcGVyaW9kIG9uCiAgICAg ICAgICAgIHRoZSBbVEJEXUBpZXRmLm9yZyBtYWlsaW5nIGxpc3QsIG9uIHRoZSBhZHZpY2Ugb2Yg b25lIG9yIG1vcmUgRGVzaWduYXRlZCBFeHBlcnRzLgogICAgICAgICAgICBIb3dldmVyLCB0byBh bGxvdyBmb3IgdGhlIGFsbG9jYXRpb24gb2YgdmFsdWVzIHByaW9yIHRvIHB1YmxpY2F0aW9uLCB0 aGUgRGVzaWduYXRlZAogICAgICAgICAgICBFeHBlcnQocykgbWF5IGFwcHJvdmUgcmVnaXN0cmF0 aW9uIG9uY2UgdGhleSBhcmUgc2F0aXNmaWVkIHRoYXQgc3VjaCBhIHNwZWNpZmljYXRpb24KICAg ICAgICAgICAgd2lsbCBiZSBwdWJsaXNoZWQuCiAgICAgICAgICA8L3Q+CiAgICAgICAgICA8dD4K ICAgICAgICAgICAgUmVnaXN0cmF0aW9uIHJlcXVlc3RzIG11c3QgYmUgc2VudCB0byB0aGUgW1RC RF1AaWV0Zi5vcmcgbWFpbGluZyBsaXN0IGZvciByZXZpZXcgYW5kCiAgICAgICAgICAgIGNvbW1l bnQsIHdpdGggYW4gYXBwcm9wcmlhdGUgc3ViamVjdCAoZS5nLiwgIlJlcXVlc3QgZm9yIHJlc3Bv bnNlIHR5cGU6IGV4YW1wbGUiKS4KICAgICAgICAgICAgW1sgTm90ZSB0byBSRkMtRURJVE9SOiBU aGUgbmFtZSBvZiB0aGUgbWFpbGluZyBsaXN0IHNob3VsZCBiZSBkZXRlcm1pbmVkIGluIGNvbnN1 bHRhdGlvbgogICAgICAgICAgICB3aXRoIHRoZSBJRVNHIGFuZCBJQU5BLiBTdWdnZXN0ZWQgbmFt ZTogb2F1dGgtZXh0LXJldmlldy4gXV0KICAgICAgICAgIDwvdD4KICAgICAgICAgIDx0PgogICAg ICAgICAgICBXaXRoaW4gdGhlIHJldmlldyBwZXJpb2QsIHRoZSBEZXNpZ25hdGVkIEV4cGVydChz KSB3aWxsIGVpdGhlciBhcHByb3ZlIG9yCiAgICAgICAgICAgIGRlbnkgdGhlIHJlZ2lzdHJhdGlv biByZXF1ZXN0LCBjb21tdW5pY2F0aW5nIHRoaXMgZGVjaXNpb24gdG8gdGhlIHJldmlldyBsaXN0 IGFuZCBJQU5BLgogICAgICAgICAgICBEZW5pYWxzIHNob3VsZCBpbmNsdWRlIGFuIGV4cGxhbmF0 aW9uIGFuZCwgaWYgYXBwbGljYWJsZSwgc3VnZ2VzdGlvbnMgYXMgdG8gaG93IHRvIG1ha2UKICAg ICAgICAgICAgdGhlIHJlcXVlc3Qgc3VjY2Vzc2Z1bC4KICAgICAgICAgIDwvdD4KICAgICAgICAg IDx0PgogICAgICAgICAgICBJQU5BIG11c3Qgb25seSBhY2NlcHQgcmVnaXN0cnkgdXBkYXRlcyBm cm9tIHRoZSBEZXNpZ25hdGVkIEV4cGVydChzKSwgYW5kIHNob3VsZCBkaXJlY3QKICAgICAgICAg ICAgYWxsIHJlcXVlc3RzIGZvciByZWdpc3RyYXRpb24gdG8gdGhlIHJldmlldyBtYWlsaW5nIGxp c3QuCiAgICAgICAgICA8L3Q+CgoKICAgICAgICAgIDxzZWN0aW9uIHRpdGxlPSdSZWdpc3RyYXRp b24gVGVtcGxhdGUnPgogICAgICAgICAgPHQ+CiAgICAgICAgICAgIDxsaXN0IHN0eWxlPSdoYW5n aW5nJz4KICAgICAgICAgICAgICA8dCBoYW5nVGV4dD0nUmVzcG9uc2UgdHlwZSBuYW1lOic+CiAg ICAgICAgICAgICAgICA8dnNwYWNlIC8+CiAgICAgICAgICAgICAgICBUaGUgbmFtZSByZXF1ZXN0 ZWQgKGUuZy4sICJleGFtcGxlIikuCiAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICAgIDx0 IGhhbmdUZXh0PSdDaGFuZ2UgY29udHJvbGxlcjonPgogICAgICAgICAgICAgICAgPHZzcGFjZSAv PgogICAgICAgICAgICAgICAgRm9yIHN0YW5kYXJkcy10cmFjayBSRkNzLCBzdGF0ZSAiSUVURiIu IEZvciBvdGhlcnMsIGdpdmUgdGhlIG5hbWUgb2YgdGhlCiAgICAgICAgICAgICAgICByZXNwb25z aWJsZSBwYXJ0eS4gT3RoZXIgZGV0YWlscyAoZS5nLiwgcG9zdGFsIGFkZHJlc3MsIGUtbWFpbCBh ZGRyZXNzLCBob21lIHBhZ2UKICAgICAgICAgICAgICAgIFVSSSkgbWF5IGFsc28gYmUgaW5jbHVk ZWQuCiAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICAgIDx0IGhhbmdUZXh0PSdTcGVjaWZp Y2F0aW9uIGRvY3VtZW50KHMpOic+CiAgICAgICAgICAgICAgICA8dnNwYWNlIC8+CiAgICAgICAg ICAgICAgICBSZWZlcmVuY2UgdG8gdGhlIGRvY3VtZW50IHRoYXQgc3BlY2lmaWVzIHRoZSB0eXBl LCBwcmVmZXJhYmx5IGluY2x1ZGluZyBhIFVSSSB0aGF0CiAgICAgICAgICAgICAgICBjYW4gYmUg dXNlZCB0byByZXRyaWV2ZSBhIGNvcHkgb2YgdGhlIGRvY3VtZW50LiBBbiBpbmRpY2F0aW9uIG9m IHRoZSByZWxldmFudAogICAgICAgICAgICAgICAgc2VjdGlvbnMgbWF5IGFsc28gYmUgaW5jbHVk ZWQsIGJ1dCBpcyBub3QgcmVxdWlyZWQuCiAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICA8 L2xpc3Q+CiAgICAgICAgICA8L3Q+CiAgICAgICAgPC9zZWN0aW9uPgoKICAgICAgICA8c2VjdGlv biB0aXRsZT0nSW5pdGlhbCBSZWdpc3RyeSBDb250ZW50cyc+CiAgICAgICAgICA8dD4KICAgICAg ICAgICAgVGhlIE9BdXRoIEF1dGhvcml6YXRpb24gRW5kcG9pbnQgUmVzcG9uc2UgVHlwZSBSZWdp c3RyeSdzIGluaXRpYWwgY29udGVudHMgYXJlOgogICAgICAgICAgPC90PgogICAgICAgICAgPHQ+ CiAgICAgICAgICAgIDxsaXN0IHN0eWxlPSdzeW1ib2xzJz4KICAgICAgICAgICAgICA8dD4KICAg ICAgICAgICAgICAgIFJlc3BvbnNlIHR5cGUgbmFtZTogY29kZQogICAgICAgICAgICAgIDwvdD4K ICAgICAgICAgICAgICA8dD4KICAgICAgICAgICAgICAgIENoYW5nZSBjb250cm9sbGVyOiBJRVRG CiAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICAgIDx0PgogICAgICAgICAgICAgICAgU3Bl Y2lmaWNhdGlvbiBkb2N1bWVudChzKTogW1sgdGhpcyBkb2N1bWVudCBdXQogICAgICAgICAgICAg IDwvdD4KICAgICAgICAgICAgPC9saXN0PgogICAgICAgICAgPC90PgogICAgICAgICAgPHQ+CiAg ICAgICAgICAgIDxsaXN0IHN0eWxlPSdzeW1ib2xzJz4KICAgICAgICAgICAgICA8dD4KICAgICAg ICAgICAgICAgIFJlc3BvbnNlIHR5cGUgbmFtZTogdG9rZW4KICAgICAgICAgICAgICA8L3Q+CiAg ICAgICAgICAgICAgPHQ+CiAgICAgICAgICAgICAgICBDaGFuZ2UgY29udHJvbGxlcjogSUVURgog ICAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAgICA8dD4KICAgICAgICAgICAgICAgIFNwZWNp ZmljYXRpb24gZG9jdW1lbnQocyk6IFtbIHRoaXMgZG9jdW1lbnQgXV0KICAgICAgICAgICAgICA8 L3Q+CiAgICAgICAgICAgIDwvbGlzdD4KICAgICAgICAgIDwvdD4KICAgICAgICA8L3NlY3Rpb24+ CgogICAgICA8L3NlY3Rpb24+CgogICAgICA8c2VjdGlvbiB0aXRsZT0nVGhlIE9BdXRoIEV4dGVu c2lvbnMgRXJyb3IgUmVnaXN0cnknIGFuY2hvcj0nZXJyb3ItcmVnaXN0cnknPgogICAgICAgIDx0 PgogICAgICAgICAgVGhpcyBzcGVjaWZpY2F0aW9uIGVzdGFibGlzaGVzIHRoZSBPQXV0aCBleHRl bnNpb25zIGVycm9yIHJlZ2lzdHJ5LgogICAgICAgIDwvdD4KICAgICAgICA8dD4KICAgICAgICAg IEFkZGl0aW9uYWwgZXJyb3IgY29kZXMgdXNlZCB0b2dldGhlciB3aXRoIG90aGVyIHByb3RvY29s IGV4dGVuc2lvbnMgKGkuZS4gZXh0ZW5zaW9uIGdyYW50CiAgICAgICAgICB0eXBlcywgYWNjZXNz IHRva2VuIHR5cGVzLCBvciBleHRlbnNpb24gcGFyYW1ldGVycykgYXJlIHJlZ2lzdGVyZWQgd2l0 aCBhIFNwZWNpZmljYXRpb24KICAgICAgICAgIFJlcXVpcmVkICg8eHJlZiB0YXJnZXQ9J1JGQzUy MjYnIC8+KSBhZnRlciBhIHR3byB3ZWVrIHJldmlldyBwZXJpb2Qgb24gdGhlCiAgICAgICAgICBb VEJEXUBpZXRmLm9yZyBtYWlsaW5nIGxpc3QsIG9uIHRoZSBhZHZpY2Ugb2Ygb25lIG9yIG1vcmUg RGVzaWduYXRlZCBFeHBlcnRzLiBIb3dldmVyLCB0bwogICAgICAgICAgYWxsb3cgZm9yIHRoZSBh bGxvY2F0aW9uIG9mIHZhbHVlcyBwcmlvciB0byBwdWJsaWNhdGlvbiwgdGhlIERlc2lnbmF0ZWQg RXhwZXJ0KHMpIG1heQogICAgICAgICAgYXBwcm92ZSByZWdpc3RyYXRpb24gb25jZSB0aGV5IGFy ZSBzYXRpc2ZpZWQgdGhhdCBzdWNoIGEgc3BlY2lmaWNhdGlvbiB3aWxsIGJlIHB1Ymxpc2hlZC4K ICAgICAgICA8L3Q+CiAgICAgICAgPHQ+CiAgICAgICAgICBSZWdpc3RyYXRpb24gcmVxdWVzdHMg bXVzdCBiZSBzZW50IHRvIHRoZSBbVEJEXUBpZXRmLm9yZyBtYWlsaW5nIGxpc3QgZm9yIHJldmll dyBhbmQKICAgICAgICAgIGNvbW1lbnQsIHdpdGggYW4gYXBwcm9wcmlhdGUgc3ViamVjdCAoZS5n LiwgIlJlcXVlc3QgZm9yIGVycm9yIGNvZGU6IGV4YW1wbGUiKS4KICAgICAgICAgIFtbIE5vdGUg dG8gUkZDLUVESVRPUjogVGhlIG5hbWUgb2YgdGhlIG1haWxpbmcgbGlzdCBzaG91bGQgYmUgZGV0 ZXJtaW5lZCBpbiBjb25zdWx0YXRpb24KICAgICAgICAgIHdpdGggdGhlIElFU0cgYW5kIElBTkEu IFN1Z2dlc3RlZCBuYW1lOiBvYXV0aC1leHQtcmV2aWV3LiBdXQogICAgICAgIDwvdD4KICAgICAg ICA8dD4KICAgICAgICAgIFdpdGhpbiB0aGUgcmV2aWV3IHBlcmlvZCwgdGhlIERlc2lnbmF0ZWQg RXhwZXJ0KHMpIHdpbGwgZWl0aGVyIGFwcHJvdmUgb3IKICAgICAgICAgIGRlbnkgdGhlIHJlZ2lz dHJhdGlvbiByZXF1ZXN0LCBjb21tdW5pY2F0aW5nIHRoaXMgZGVjaXNpb24gdG8gdGhlIHJldmll dyBsaXN0IGFuZCBJQU5BLgogICAgICAgICAgRGVuaWFscyBzaG91bGQgaW5jbHVkZSBhbiBleHBs YW5hdGlvbiBhbmQsIGlmIGFwcGxpY2FibGUsIHN1Z2dlc3Rpb25zIGFzIHRvIGhvdyB0byBtYWtl CiAgICAgICAgICB0aGUgcmVxdWVzdCBzdWNjZXNzZnVsLgogICAgICAgIDwvdD4KICAgICAgICA8 dD4KICAgICAgICAgIElBTkEgbXVzdCBvbmx5IGFjY2VwdCByZWdpc3RyeSB1cGRhdGVzIGZyb20g dGhlIERlc2lnbmF0ZWQgRXhwZXJ0KHMpLCBhbmQgc2hvdWxkIGRpcmVjdAogICAgICAgICAgYWxs IHJlcXVlc3RzIGZvciByZWdpc3RyYXRpb24gdG8gdGhlIHJldmlldyBtYWlsaW5nIGxpc3QuCiAg ICAgICAgPC90PgoKCiAgICAgICAgPHNlY3Rpb24gdGl0bGU9J1JlZ2lzdHJhdGlvbiBUZW1wbGF0 ZSc+CiAgICAgICAgICA8dD4KICAgICAgICAgICAgPGxpc3Qgc3R5bGU9J2hhbmdpbmcnPgogICAg ICAgICAgICAgIDx0IGhhbmdUZXh0PSdFcnJvciBuYW1lOic+CiAgICAgICAgICAgICAgICA8dnNw YWNlIC8+CiAgICAgICAgICAgICAgICBUaGUgbmFtZSByZXF1ZXN0ZWQgKGUuZy4sICJleGFtcGxl IikuCiAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICAgIDx0IGhhbmdUZXh0PSdFcnJvciB1 c2FnZSBsb2NhdGlvbjonPgogICAgICAgICAgICAgICAgPHZzcGFjZSAvPgogICAgICAgICAgICAg ICAgVGhlIGxvY2F0aW9uKHMpIHdoZXJlIHRoZSBlcnJvciBjYW4gYmUgdXNlZC4gVGhlIHBvc3Np YmxlIGxvY2F0aW9ucyBhcmU6CiAgICAgICAgICAgICAgICBhdXRob3JpemF0aW9uIGNvZGUgZ3Jh bnQgZXJyb3IgcmVzcG9uc2UgKDx4cmVmIHRhcmdldD0nY29kZS1hdXRoei1lcnJvcicgLz4pLAog ICAgICAgICAgICAgICAgaW1wbGljaXQgZ3JhbnQgZXJyb3IgcmVzcG9uc2UgKDx4cmVmIHRhcmdl dD0naW1wbGljaXQtYXV0aHotZXJyb3InIC8+KSwKCQl0b2tlbiBlcnJvciByZXNwb25zZSAoPHhy ZWYgdGFyZ2V0PSd0b2tlbi1lcnJvcnMnIC8+KSwgb3IKCQlyZXNvdXJjZSBhY2Nlc3MgZXJyb3Ig cmVzcG9uc2UgKDx4cmVmIHRhcmdldD0ncmVzb3VyY2UtZXJyb3JzJyAvPikuCiAgICAgICAgICAg ICAgPC90PgogICAgICAgICAgICAgIDx0IGhhbmdUZXh0PSdSZWxhdGVkIHByb3RvY29sIGV4dGVu c2lvbjonPgogICAgICAgICAgICAgICAgPHZzcGFjZSAvPgogICAgICAgICAgICAgICAgVGhlIG5h bWUgb2YgdGhlIGV4dGVuc2lvbiBncmFudCB0eXBlLCBhY2Nlc3MgdG9rZW4gdHlwZSwgb3IgZXh0 ZW5zaW9uIHBhcmFtZXRlciwKICAgICAgICAgICAgICAgIHRoZSBlcnJvciBjb2RlIGlzIHVzZWQg aW4gY29uanVuY3Rpb24gd2l0aC4KICAgICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgICAgPHQg aGFuZ1RleHQ9J0NoYW5nZSBjb250cm9sbGVyOic+CiAgICAgICAgICAgICAgICA8dnNwYWNlIC8+ CiAgICAgICAgICAgICAgICBGb3Igc3RhbmRhcmRzLXRyYWNrIFJGQ3MsIHN0YXRlICJJRVRGIi4g Rm9yIG90aGVycywgZ2l2ZSB0aGUgbmFtZSBvZiB0aGUKICAgICAgICAgICAgICAgIHJlc3BvbnNp YmxlIHBhcnR5LiBPdGhlciBkZXRhaWxzIChlLmcuLCBwb3N0YWwgYWRkcmVzcywgZS1tYWlsIGFk ZHJlc3MsIGhvbWUgcGFnZQogICAgICAgICAgICAgICAgVVJJKSBtYXkgYWxzbyBiZSBpbmNsdWRl ZC4KICAgICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgICAgPHQgaGFuZ1RleHQ9J1NwZWNpZmlj YXRpb24gZG9jdW1lbnQocyk6Jz4KICAgICAgICAgICAgICAgIDx2c3BhY2UgLz4KICAgICAgICAg ICAgICAgIFJlZmVyZW5jZSB0byB0aGUgZG9jdW1lbnQgdGhhdCBzcGVjaWZpZXMgdGhlIGVycm9y IGNvZGUsIHByZWZlcmFibHkgaW5jbHVkaW5nIGEgVVJJCiAgICAgICAgICAgICAgICB0aGF0IGNh biBiZSB1c2VkIHRvIHJldHJpZXZlIGEgY29weSBvZiB0aGUgZG9jdW1lbnQuIEFuIGluZGljYXRp b24gb2YgdGhlIHJlbGV2YW50CiAgICAgICAgICAgICAgICBzZWN0aW9ucyBtYXkgYWxzbyBiZSBp bmNsdWRlZCwgYnV0IGlzIG5vdCByZXF1aXJlZC4KICAgICAgICAgICAgICA8L3Q+CiAgICAgICAg ICAgIDwvbGlzdD4KICAgICAgICAgIDwvdD4KICAgICAgICA8L3NlY3Rpb24+CgogICAgICA8L3Nl Y3Rpb24+CgogICAgPC9zZWN0aW9uPgoKICA8L21pZGRsZT4KCiAgPGJhY2s+CgogICAgPHJlZmVy ZW5jZXMgdGl0bGU9J05vcm1hdGl2ZSBSZWZlcmVuY2VzJz4KCiAgICAgIDw/cmZjIGluY2x1ZGU9 J2h0dHA6Ly94bWwucmVzb3VyY2Uub3JnL3B1YmxpYy9yZmMvYmlieG1sL3JlZmVyZW5jZS5SRkMu MjExOS54bWwnID8+CiAgICAgIDw/cmZjIGluY2x1ZGU9J2h0dHA6Ly94bWwucmVzb3VyY2Uub3Jn L3B1YmxpYy9yZmMvYmlieG1sL3JlZmVyZW5jZS5SRkMuMjI0Ni54bWwnID8+CiAgICAgIDw/cmZj IGluY2x1ZGU9J2h0dHA6Ly94bWwucmVzb3VyY2Uub3JnL3B1YmxpYy9yZmMvYmlieG1sL3JlZmVy ZW5jZS5SRkMuMjYxNi54bWwnID8+CiAgICAgIDw/cmZjIGluY2x1ZGU9J2h0dHA6Ly94bWwucmVz b3VyY2Uub3JnL3B1YmxpYy9yZmMvYmlieG1sL3JlZmVyZW5jZS5SRkMuMjYxNy54bWwnID8+CiAg ICAgIDw/cmZjIGluY2x1ZGU9J2h0dHA6Ly94bWwucmVzb3VyY2Uub3JnL3B1YmxpYy9yZmMvYmli eG1sL3JlZmVyZW5jZS5SRkMuMjgxOC54bWwnID8+CiAgICAgIDw/cmZjIGluY2x1ZGU9J2h0dHA6 Ly94bWwucmVzb3VyY2Uub3JnL3B1YmxpYy9yZmMvYmlieG1sL3JlZmVyZW5jZS5SRkMuMzk4Ni54 bWwnID8+CiAgICAgIDw/cmZjIGluY2x1ZGU9J2h0dHA6Ly94bWwucmVzb3VyY2Uub3JnL3B1Ymxp Yy9yZmMvYmlieG1sL3JlZmVyZW5jZS5SRkMuNDYyNy54bWwnID8+CiAgICAgIDw/cmZjIGluY2x1 ZGU9J2h0dHA6Ly94bWwucmVzb3VyY2Uub3JnL3B1YmxpYy9yZmMvYmlieG1sL3JlZmVyZW5jZS5S RkMuNDk0OS54bWwnID8+CiAgICAgIDw/cmZjIGluY2x1ZGU9J2h0dHA6Ly94bWwucmVzb3VyY2Uu b3JnL3B1YmxpYy9yZmMvYmlieG1sL3JlZmVyZW5jZS5SRkMuNTIyNi54bWwnID8+CiAgICAgIDw/ cmZjIGluY2x1ZGU9J2h0dHA6Ly94bWwucmVzb3VyY2Uub3JnL3B1YmxpYy9yZmMvYmlieG1sL3Jl ZmVyZW5jZS5SRkMuNTIzNC54bWwnID8+CiAgICAgIDw/cmZjIGluY2x1ZGU9J2h0dHA6Ly94bWwu cmVzb3VyY2Uub3JnL3B1YmxpYy9yZmMvYmlieG1sL3JlZmVyZW5jZS5SRkMuNTI0Ni54bWwnID8+ CiAgICAgIDw/cmZjIGluY2x1ZGU9J2h0dHA6Ly94bWwucmVzb3VyY2Uub3JnL3B1YmxpYy9yZmMv YmlieG1sL3JlZmVyZW5jZS5SRkMuNjEyNS54bWwnID8+CiAgICAgIDw/cmZjIGluY2x1ZGU9J2h0 dHA6Ly94bWwucmVzb3VyY2Uub3JnL3B1YmxpYy9yZmMvYmlieG1sNC9yZWZlcmVuY2UuVzNDLlJF Qy1odG1sNDAxLTE5OTkxMjI0LnhtbCcgPz4KCiAgICAgIDxyZWZlcmVuY2UgYW5jaG9yPSJVU0FT Q0lJIj4KCTxmcm9udD4KCSAgPHRpdGxlPkNvZGVkIENoYXJhY3RlciBTZXQgLS0gNy1iaXQgQW1l cmljYW4gU3RhbmRhcmQgQ29kZSBmb3IgSW5mb3JtYXRpb24gSW50ZXJjaGFuZ2U8L3RpdGxlPgoJ ICA8YXV0aG9yPgoJICAgIDxvcmdhbml6YXRpb24+QW1lcmljYW4gTmF0aW9uYWwgU3RhbmRhcmRz IEluc3RpdHV0ZTwvb3JnYW5pemF0aW9uPgoJICA8L2F1dGhvcj4KCSAgPGRhdGUgeWVhcj0iMTk4 NiIvPgoJPC9mcm9udD4KCTxzZXJpZXNJbmZvIG5hbWU9IkFOU0kiIHZhbHVlPSJYMy40Ii8+CiAg ICAgIDwvcmVmZXJlbmNlPgoKICAgIDwvcmVmZXJlbmNlcz4KCiAgICA8cmVmZXJlbmNlcyB0aXRs ZT0nSW5mb3JtYXRpdmUgUmVmZXJlbmNlcyc+CgogICAgICA8P3JmYyBpbmNsdWRlPSdodHRwOi8v eG1sLnJlc291cmNlLm9yZy9wdWJsaWMvcmZjL2JpYnhtbC9yZWZlcmVuY2UuUkZDLjU4NDkueG1s JyA/PgogICAgICA8P3JmYyBpbmNsdWRlPSdodHRwOi8veG1sLnJlc291cmNlLm9yZy9wdWJsaWMv cmZjL2JpYnhtbDMvcmVmZXJlbmNlLkktRC5kcmFmdC1pZXRmLW9hdXRoLXYyLWJlYXJlci0xOS54 bWwnID8+CiAgICAgIDw/cmZjIGluY2x1ZGU9J2h0dHA6Ly94bWwucmVzb3VyY2Uub3JnL3B1Ymxp Yy9yZmMvYmlieG1sMy9yZWZlcmVuY2UuSS1ELmRyYWZ0LWlldGYtb2F1dGgtc2FtbDItYmVhcmVy LTEyLnhtbCcgPz4KICAgICAgPD9yZmMgaW5jbHVkZT0naHR0cDovL3htbC5yZXNvdXJjZS5vcmcv cHVibGljL3JmYy9iaWJ4bWwzL3JlZmVyZW5jZS5JLUQuZHJhZnQtaWV0Zi1vYXV0aC12Mi1odHRw LW1hYy0wMS54bWwnID8+CiAgICAgIDw/cmZjIGluY2x1ZGU9J2h0dHA6Ly94bWwucmVzb3VyY2Uu b3JnL3B1YmxpYy9yZmMvYmlieG1sMy9yZWZlcmVuY2UuSS1ELmRyYWZ0LWlldGYtb2F1dGgtdjIt dGhyZWF0bW9kZWwtMDIueG1sJyA/PgoKICAgICAgPD9yZmMgaW5jbHVkZT0naHR0cDovL3htbC5y ZXNvdXJjZS5vcmcvcHVibGljL3JmYy9iaWJ4bWwzL3JlZmVyZW5jZS5JLUQuZHJhZnQtaWV0Zi1o dHRwYmlzLXA3LWF1dGgtMTkueG1sJz8+CgogICAgICA8cmVmZXJlbmNlIGFuY2hvcj0iSS1ELmRy YWZ0LWhhcmR0LW9hdXRoLTAxIj4KICAgICAgICA8ZnJvbnQ+CiAgICAgICAgICA8dGl0bGU+T0F1 dGggV2ViIFJlc291cmNlIEF1dGhvcml6YXRpb24gUHJvZmlsZXM8L3RpdGxlPgogICAgICAgICAg PGF1dGhvciBpbml0aWFscz0iRCIgc3VybmFtZT0iSGFyZHQiIGZ1bGxuYW1lPSJEaWNrIEhhcmR0 IiByb2xlPSJlZGl0b3IiIC8+CiAgICAgICAgICA8YXV0aG9yIGluaXRpYWxzPSJBIiBzdXJuYW1l PSJUb20iIGZ1bGxuYW1lPSJBbGxlbiBUb20iIC8+CiAgICAgICAgICA8YXV0aG9yIGluaXRpYWxz PSJCIiBzdXJuYW1lPSJFYXRvbiIgZnVsbG5hbWU9IkJyaWFuIEVhdG9uIiAvPgogICAgICAgICAg PGF1dGhvciBpbml0aWFscz0iWSIgc3VybmFtZT0iR29sYW5kIiBmdWxsbmFtZT0iWWFyb24gR29s YW5kIiAvPgogICAgICAgICAgPGRhdGUgbW9udGg9IkphbnVhcnkiIGRheT0iMTUiIHllYXI9IjIw MTAiIC8+CiAgICAgICAgPC9mcm9udD4KICAgICAgICA8Zm9ybWF0IHRhcmdldD0iaHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaGFyZHQtb2F1dGgtMDEiIHR5cGU9IkhUTUwiIC8+CiAg ICAgIDwvcmVmZXJlbmNlPgoKICAgIDwvcmVmZXJlbmNlcz4KCiAgICA8c2VjdGlvbiB0aXRsZT0i QXVnbWVudGVkIEJhY2t1cy1OYXVyIEZvcm0gKEFCTkYpIFN5bnRheCI+CiAgICAgIDx0PgoJVGhp cyBzZWN0aW9uIHByb3ZpZGVzIEF1Z21lbnRlZCBCYWNrdXMtTmF1ciBGb3JtIChBQk5GKSBzeW50 YXgKCWRlc2NyaXB0aW9ucyBmb3IgdGhlIGVsZW1lbnRzIGRlZmluZWQgaW4gdGhpcyBzcGVjaWZp Y2F0aW9uCgl1c2luZyB0aGUgbm90YXRpb24gb2YgPHhyZWYgdGFyZ2V0PSdSRkM1MjM0JyAvPi4K CUVsZW1lbnRzIGFyZSBwcmVzZW50ZWQgaW4gdGhlIG9yZGVyIGZpcnN0IGRlZmluZWQuCiAgICAg IDwvdD4KCQogICAgICA8ZmlndXJlPgoJPHByZWFtYmxlPgoJICBTb21lIG9mIHRoZSBkZWZpbml0 aW9ucyB0aGF0IGZvbGxvdyB1c2UgdGhlCgkgIDxzcGFueCBzdHlsZT0ndmVyYic+dW5yZXNlcnZl ZDwvc3Bhbng+IGFuZAoJICA8c3Bhbnggc3R5bGU9J3ZlcmInPlVSSTwvc3Bhbng+CgkgIGRlZmlu aXRpb25zIGZyb20gPHhyZWYgdGFyZ2V0PSJSRkMzOTg2Ii8+LCB3aGljaCBhcmU6Cgk8L3ByZWFt YmxlPgoJPGFydHdvcms+PCFbQ0RBVEFbCnVucmVzZXJ2ZWQgPSBBTFBIQSAvIERJR0lUIC8gIi0i IC8gIi4iIC8gIl8iIC8gIn4iClVSSSAgICAgICAgPSBzY2hlbWUgIjoiIGhpZXItcGFydCBbICI/ IiBxdWVyeSBdIFsgIiMiIGZyYWdtZW50IF0KXV0+PC9hcnR3b3JrPgogICAgICA8L2ZpZ3VyZT4K CiAgICAgIDxmaWd1cmU+Cgk8cHJlYW1ibGU+CgkgIFNvbWUgb2YgdGhlIGRlZmluaXRpb25zIHRo YXQgZm9sbG93IHVzZSB0aGUKCSAgPHNwYW54IHN0eWxlPSd2ZXJiJz5iNjR0b2tlbjwvc3Bhbng+ IHN5bnRheCBiZWxvdywgd2hpY2ggbWF0Y2hlcyB0aGUKCSAgPHNwYW54IHN0eWxlPSd2ZXJiJz5i NjR0b2tlbjwvc3Bhbng+IHN5bnRheCBkZWZpbmVkIGJ5CgkgIEhUVFAvMS4xLCBQYXJ0IDcgPHhy ZWYgdGFyZ2V0PSdJLUQuaWV0Zi1odHRwYmlzLXA3LWF1dGgnIC8+OgoJPC9wcmVhbWJsZT4KCTxh cnR3b3JrPjwhW0NEQVRBWwpiNjR0b2tlbiAgID0gMSooIEFMUEhBIC8gRElHSVQgLwogICAgICAg ICAgICAgICAgICItIiAvICIuIiAvICJfIiAvICJ+IiAvICIrIiAvICIvIiApICoiPSIgCl1dPjwv YXJ0d29yaz4KICAgICAgPC9maWd1cmU+CgogICAgICA8c2VjdGlvbiB0aXRsZT0nImNsaWVudF9p ZCIgU3ludGF4Jz4KCgk8ZmlndXJlPgoJICA8cHJlYW1ibGU+CgkgICAgVGhlIDxzcGFueCBzdHls ZT0ndmVyYic+Y2xpZW50X2lkPC9zcGFueD4gZWxlbWVudCBpcyBkZWZpbmVkIGluCgkgICAgPHhy ZWYgdGFyZ2V0PSJjbGllbnQtcGFzc3dvcmQiLz46CgkgIDwvcHJlYW1ibGU+CgkgIDxhcnR3b3Jr PjwhW0NEQVRBWwpjbGllbnQtaWQgICAgID0gKjxURVhUIGV4Y2x1ZGluZyAiOiI+Cl1dPjwvYXJ0 d29yaz4KCTwvZmlndXJlPgoJPHQ+CgkgIChUaGlzIG1hdGNoZXMgdGhlIDxzcGFueCBzdHlsZT0n dmVyYic+dXNlcmlkPC9zcGFueD4gZGVmaW5pdGlvbiBpbiB0aGUKCSAgSFRUUCBCYXNpYyBBdXRo ZW50aWNhdGlvbiBTY2hlbWUgPHhyZWYgdGFyZ2V0PSdSRkMyNjE3Jy8+LikKCTwvdD4KICAgICAg PC9zZWN0aW9uPgoKICAgICAgPHNlY3Rpb24gdGl0bGU9JyJjbGllbnRfc2VjcmV0IiBTeW50YXgn PgoKCTxmaWd1cmU+CgkgIDxwcmVhbWJsZT4KCSAgICBUaGUgPHNwYW54IHN0eWxlPSd2ZXJiJz5j bGllbnRfc2VjcmV0PC9zcGFueD4gZWxlbWVudCBpcyBkZWZpbmVkIGluCgkgICAgPHhyZWYgdGFy Z2V0PSJjbGllbnQtcGFzc3dvcmQiLz46CgkgIDwvcHJlYW1ibGU+CgkgIDxhcnR3b3JrPjwhW0NE QVRBWwpjbGllbnQtc2VjcmV0ID0gKlRFWFQKXV0+PC9hcnR3b3JrPgoJPC9maWd1cmU+Cgk8dD4K CSAgKFRoaXMgbWF0Y2hlcyB0aGUgPHNwYW54IHN0eWxlPSd2ZXJiJz5wYXNzd29yZDwvc3Bhbng+ IGRlZmluaXRpb24gaW4gdGhlCgkgIEhUVFAgQmFzaWMgQXV0aGVudGljYXRpb24gU2NoZW1lIDx4 cmVmIHRhcmdldD0nUkZDMjYxNycvPi4pCgk8L3Q+CiAgICAgIDwvc2VjdGlvbj4KCiAgICAgIDxz ZWN0aW9uIHRpdGxlPScicmVzcG9uc2VfdHlwZSIgU3ludGF4Jz4KCgk8ZmlndXJlPgoJICA8cHJl YW1ibGU+CgkgICAgVGhlIDxzcGFueCBzdHlsZT0ndmVyYic+cmVzcG9uc2VfdHlwZTwvc3Bhbng+ IGVsZW1lbnQgaXMgZGVmaW5lZCBpbgoJICAgIDx4cmVmIHRhcmdldD0icmVzcG9uc2UtdHlwZSIv PiBhbmQKCSAgICA8eHJlZiB0YXJnZXQ9InJlc3BvbnNlLXR5cGUtZXh0Ii8+OgoJICA8L3ByZWFt YmxlPgoJICA8YXJ0d29yaz48IVtDREFUQVsKcmVzcG9uc2UtdHlwZSA9IHJlc3BvbnNlLW5hbWUg KiggU1AgcmVzcG9uc2UtbmFtZSApCnJlc3BvbnNlLW5hbWUgPSAxKnJlc3BvbnNlLWNoYXIKcmVz cG9uc2UtY2hhciA9ICJfIiAvIERJR0lUIC8gQUxQSEEKXV0+PC9hcnR3b3JrPgoJPC9maWd1cmU+ CiAgICAgIDwvc2VjdGlvbj4KCiAgICAgIDxzZWN0aW9uIHRpdGxlPScic2NvcGUiIFN5bnRheCc+ CgoJPGZpZ3VyZT4KCSAgPHByZWFtYmxlPgoJICAgIFRoZSA8c3Bhbnggc3R5bGU9J3ZlcmInPnNj b3BlPC9zcGFueD4gZWxlbWVudCBpcyBkZWZpbmVkIGluCgkgICAgPHhyZWYgdGFyZ2V0PSJzY29w ZSIvPjoKCSAgPC9wcmVhbWJsZT4KCSAgPGFydHdvcms+PCFbQ0RBVEFbCnNjb3BlICAgICAgID0g c2NvcGUtdG9rZW4gKiggU1Agc2NvcGUtdG9rZW4gKQpzY29wZS10b2tlbiA9IDEqKCAleDIxIC8g JXgyMy01QiAvICV4NUQtN0UgKQpdXT48L2FydHdvcms+Cgk8L2ZpZ3VyZT4KICAgICAgPC9zZWN0 aW9uPgoKICAgICAgPHNlY3Rpb24gdGl0bGU9JyJzdGF0ZSIgU3ludGF4Jz4KCgk8ZmlndXJlPgoJ ICA8cHJlYW1ibGU+CgkgICAgVGhlIDxzcGFueCBzdHlsZT0ndmVyYic+c3RhdGU8L3NwYW54PiBl bGVtZW50IGlzIGRlZmluZWQgaW4KCSAgICA8eHJlZiB0YXJnZXQ9ImNvZGUtYXV0aHotcmVxIi8+ LAoJICAgIDx4cmVmIHRhcmdldD0iY29kZS1hdXRoei1yZXNwIi8+LAoJICAgIDx4cmVmIHRhcmdl dD0iY29kZS1hdXRoei1lcnJvciIvPiwKCSAgICA8eHJlZiB0YXJnZXQ9ImltcGxpY2l0LWF1dGh6 LXJlcSIvPiwKCSAgICA8eHJlZiB0YXJnZXQ9ImltcGxpY2l0LWF1dGh6LXJlc3AiLz4sIGFuZAoJ ICAgIDx4cmVmIHRhcmdldD0iaW1wbGljaXQtYXV0aHotZXJyb3IiLz46CgkgIDwvcHJlYW1ibGU+ CgkgIDxhcnR3b3JrPjwhW0NEQVRBWwpzdGF0ZSAgICAgID0gMSp1bnJlc2VydmVkCl1dPjwvYXJ0 d29yaz4KCTwvZmlndXJlPgogICAgICA8L3NlY3Rpb24+CgogICAgICA8c2VjdGlvbiB0aXRsZT0n InJlZGlyZWN0X3VyaSIgU3ludGF4Jz4KCgk8ZmlndXJlPgoJICA8cHJlYW1ibGU+CgkgICAgVGhl IDxzcGFueCBzdHlsZT0ndmVyYic+cmVkaXJlY3RfdXJpPC9zcGFueD4gZWxlbWVudCBpcyBkZWZp bmVkIGluCgkgICAgPHhyZWYgdGFyZ2V0PSJjb2RlLWF1dGh6LXJlcSIvPiwKCSAgICA8eHJlZiB0 YXJnZXQ9InRva2VuLXJlcSIvPiwgYW5kCgkgICAgPHhyZWYgdGFyZ2V0PSJpbXBsaWNpdC1hdXRo ei1yZXEiLz46CgkgIDwvcHJlYW1ibGU+CgkgIDxhcnR3b3JrPjwhW0NEQVRBWwpyZWRpcmVjdC11 cmkgICAgICA9IFVSSQpdXT48L2FydHdvcms+Cgk8L2ZpZ3VyZT4KICAgICAgPC9zZWN0aW9uPgoK ICAgICAgPHNlY3Rpb24gdGl0bGU9JyJlcnJvciIgU3ludGF4Jz4KCgk8ZmlndXJlPgoJICA8cHJl YW1ibGU+CgkgICAgVGhlIDxzcGFueCBzdHlsZT0ndmVyYic+ZXJyb3I8L3NwYW54PiBlbGVtZW50 IGlzIGRlZmluZWQgaW4KCSAgICA8eHJlZiB0YXJnZXQ9ImNvZGUtYXV0aHotZXJyb3IiLz4sCgkg ICAgPHhyZWYgdGFyZ2V0PSdpbXBsaWNpdC1hdXRoei1lcnJvcicvPiwKCSAgICA8eHJlZiB0YXJn ZXQ9J3Rva2VuLWVycm9ycycvPiwKCSAgICA8eHJlZiB0YXJnZXQ9J3Jlc291cmNlLWVycm9ycycv PiwgYW5kCgkgICAgPHhyZWYgdGFyZ2V0PSJuZXctZXJyb3JzIi8+OgoJICA8L3ByZWFtYmxlPgoJ ICA8YXJ0d29yaz48IVtDREFUQVsKZXJyb3IgICAgICAgICAgICAgPSAxKmVycm9yLWNoYXIKZXJy b3ItY2hhciAgICAgICAgPSAleDIwLTIxIC8gJXgyMy01QiAvICV4NUQtN0UKXV0+PC9hcnR3b3Jr PgoJPC9maWd1cmU+CiAgICAgIDwvc2VjdGlvbj4KCiAgICAgIDxzZWN0aW9uIHRpdGxlPSciZXJy b3JfZGVzY3JpcHRpb24iIFN5bnRheCc+CgoJPGZpZ3VyZT4KCSAgPHByZWFtYmxlPgoJICAgIFRo ZSA8c3Bhbnggc3R5bGU9J3ZlcmInPmVycm9yX2Rlc2NyaXB0aW9uPC9zcGFueD4gZWxlbWVudCBp cyBkZWZpbmVkIGluCgkgICAgPHhyZWYgdGFyZ2V0PSJjb2RlLWF1dGh6LWVycm9yIi8+LAoJICAg IDx4cmVmIHRhcmdldD0naW1wbGljaXQtYXV0aHotZXJyb3InLz4sCgkgICAgPHhyZWYgdGFyZ2V0 PSd0b2tlbi1lcnJvcnMnLz4sIGFuZAoJICAgIDx4cmVmIHRhcmdldD0ncmVzb3VyY2UtZXJyb3Jz Jy8+OgoJICA8L3ByZWFtYmxlPgoJICA8YXJ0d29yaz48IVtDREFUQVsKZXJyb3ItZGVzY3JpcHRp b24gPSAxKmVycm9yLWNoYXIKZXJyb3ItY2hhciAgICAgICAgPSAleDIwLTIxIC8gJXgyMy01QiAv ICV4NUQtN0UKXV0+PC9hcnR3b3JrPgoJPC9maWd1cmU+CiAgICAgIDwvc2VjdGlvbj4KCiAgICAg IDxzZWN0aW9uIHRpdGxlPSciZXJyb3JfdXJpIiBTeW50YXgnPgoKCTxmaWd1cmU+CgkgIDxwcmVh bWJsZT4KCSAgICBUaGUgPHNwYW54IHN0eWxlPSd2ZXJiJz5lcnJvcl91cmk8L3NwYW54PiBlbGVt ZW50IGlzIGRlZmluZWQgaW4KCSAgICA8eHJlZiB0YXJnZXQ9ImNvZGUtYXV0aHotZXJyb3IiLz4s CgkgICAgPHhyZWYgdGFyZ2V0PSdpbXBsaWNpdC1hdXRoei1lcnJvcicvPiwKCSAgICA8eHJlZiB0 YXJnZXQ9J3Rva2VuLWVycm9ycycvPiwgYW5kCgkgICAgPHhyZWYgdGFyZ2V0PSdyZXNvdXJjZS1l cnJvcnMnLz46CgkgIDwvcHJlYW1ibGU+CgkgIDxhcnR3b3JrPjwhW0NEQVRBWwplcnJvci11cmkg ICAgICAgICA9IFVSSQpdXT48L2FydHdvcms+Cgk8L2ZpZ3VyZT4KICAgICAgPC9zZWN0aW9uPgoK ICAgICAgPHNlY3Rpb24gdGl0bGU9JyJncmFudF90eXBlIiBTeW50YXgnPgoKCTxmaWd1cmU+Cgkg IDxwcmVhbWJsZT4KCSAgICBUaGUgPHNwYW54IHN0eWxlPSd2ZXJiJz5ncmFudF90eXBlPC9zcGFu eD4gZWxlbWVudCBpcyBkZWZpbmVkIGluCgkgICAgPHhyZWYgdGFyZ2V0PSJ0b2tlbi1yZXEiLz4s CgkgICAgPHhyZWYgdGFyZ2V0PSdwYXNzd29yZC10b2stcmVxJy8+LAoJICAgIDx4cmVmIHRhcmdl dD0nY2xpZW50LXJlcS1yZXNwJy8+LAoJICAgIDx4cmVmIHRhcmdldD0idG9rZW4tcmVmcmVzaCIv PiwgYW5kCgkgICAgPHhyZWYgdGFyZ2V0PSdleHQtZ3JhbnQnLz46CgkgIDwvcHJlYW1ibGU+Cgkg IDxhcnR3b3JrPjwhW0NEQVRBWwpncmFudC10eXBlID0gZ3JhbnQtbmFtZSAvIFVSSQpncmFudC1u YW1lID0gMSpuYW1lLWNoYXIKbmFtZS1jaGFyICA9ICItIiAvICIuIiAvICJfIiAvIERJR0lUIC8g QUxQSEEKXV0+PC9hcnR3b3JrPgoJPC9maWd1cmU+CiAgICAgIDwvc2VjdGlvbj4KCiAgICAgIDxz ZWN0aW9uIHRpdGxlPSciY29kZSIgU3ludGF4Jz4KCgk8ZmlndXJlPgoJICA8cHJlYW1ibGU+Cgkg ICAgVGhlIDxzcGFueCBzdHlsZT0ndmVyYic+Y29kZTwvc3Bhbng+IGVsZW1lbnQgaXMgZGVmaW5l ZCBpbgoJICAgIDx4cmVmIHRhcmdldD0idG9rZW4tcmVxIi8+OgoJICA8L3ByZWFtYmxlPgoJICA8 YXJ0d29yaz48IVtDREFUQVsKY29kZSAgICAgICA9IDEqdW5yZXNlcnZlZApdXT48L2FydHdvcms+ Cgk8L2ZpZ3VyZT4KICAgICAgPC9zZWN0aW9uPgoKICAgICAgPHNlY3Rpb24gdGl0bGU9JyJhY2Nl c3NfdG9rZW4iIFN5bnRheCc+CgoJPGZpZ3VyZT4KCSAgPHByZWFtYmxlPgoJICAgIFRoZSA8c3Bh bnggc3R5bGU9J3ZlcmInPmFjY2Vzc190b2tlbjwvc3Bhbng+IGVsZW1lbnQgaXMgZGVmaW5lZCBp bgoJICAgIDx4cmVmIHRhcmdldD0iaW1wbGljaXQtYXV0aHotcmVzcCIvPiBhbmQKCSAgICA8eHJl ZiB0YXJnZXQ9InRva2VuLXJlc3BvbnNlIi8+OgoJICA8L3ByZWFtYmxlPgoJICA8YXJ0d29yaz48 IVtDREFUQVsKYWNjZXNzLXRva2VuID0gYjY0dG9rZW4KXV0+PC9hcnR3b3JrPgoJPC9maWd1cmU+ CiAgICAgIDwvc2VjdGlvbj4KCiAgICAgIDxzZWN0aW9uIHRpdGxlPScidG9rZW5fdHlwZSIgU3lu dGF4Jz4KCgk8ZmlndXJlPgoJICA8cHJlYW1ibGU+CgkgICAgVGhlIDxzcGFueCBzdHlsZT0ndmVy Yic+dG9rZW5fdHlwZTwvc3Bhbng+IGVsZW1lbnQgaXMgZGVmaW5lZCBpbgoJICAgIDx4cmVmIHRh cmdldD0iaW1wbGljaXQtYXV0aHotcmVzcCIvPiwKCSAgICA8eHJlZiB0YXJnZXQ9InRva2VuLXJl c3BvbnNlIi8+LCBhbmQKCSAgICA8eHJlZiB0YXJnZXQ9Im5ldy10eXBlcyIvPjoKCSAgPC9wcmVh bWJsZT4KCSAgPGFydHdvcms+PCFbQ0RBVEFbCnRva2VuLXR5cGUgPSB0eXBlLW5hbWUgLyBVUkkK dHlwZS1uYW1lICA9IDEqbmFtZS1jaGFyCm5hbWUtY2hhciAgPSAiLSIgLyAiLiIgLyAiXyIgLyBE SUdJVCAvIEFMUEhBCl1dPjwvYXJ0d29yaz4KCTwvZmlndXJlPgogICAgICA8L3NlY3Rpb24+Cgog ICAgICA8c2VjdGlvbiB0aXRsZT0nImV4cGlyZXNfaW4iIFN5bnRheCc+CgoJPGZpZ3VyZT4KCSAg PHByZWFtYmxlPgoJICAgIFRoZSA8c3Bhbnggc3R5bGU9J3ZlcmInPmV4cGlyZXNfaW48L3NwYW54 PiBlbGVtZW50IGlzIGRlZmluZWQgaW4KCSAgICA8eHJlZiB0YXJnZXQ9ImltcGxpY2l0LWF1dGh6 LXJlc3AiLz4gYW5kCgkgICAgPHhyZWYgdGFyZ2V0PSJ0b2tlbi1yZXNwb25zZSIvPjoKCSAgPC9w cmVhbWJsZT4KCSAgPGFydHdvcms+PCFbQ0RBVEFbCmV4cGlyZXMtaW4gPSAxKkRJR0lUCl1dPjwv YXJ0d29yaz4KCTwvZmlndXJlPgogICAgICA8L3NlY3Rpb24+CgogICAgICA8c2VjdGlvbiB0aXRs ZT0nInVzZXJuYW1lIiBTeW50YXgnPgoKCTxmaWd1cmU+CgkgIDxwcmVhbWJsZT4KCSAgICBUaGUg PHNwYW54IHN0eWxlPSd2ZXJiJz51c2VybmFtZTwvc3Bhbng+IGVsZW1lbnQgaXMgZGVmaW5lZCBp bgoJICAgIDx4cmVmIHRhcmdldD0icGFzc3dvcmQtdG9rLXJlcSIvPjoKCSAgPC9wcmVhbWJsZT4K CSAgPGFydHdvcms+PCFbQ0RBVEFbCnVzZXJuYW1lID0gKjxURVhUIGV4Y2x1ZGluZyAiOiI+Cl1d PjwvYXJ0d29yaz4KCTwvZmlndXJlPgoJPHQ+CgkgIChUaGlzIG1hdGNoZXMgdGhlIDxzcGFueCBz dHlsZT0ndmVyYic+dXNlcmlkPC9zcGFueD4gZGVmaW5pdGlvbiBpbiB0aGUKCSAgSFRUUCBCYXNp YyBBdXRoZW50aWNhdGlvbiBTY2hlbWUgPHhyZWYgdGFyZ2V0PSdSRkMyNjE3Jy8+LikKCTwvdD4K ICAgICAgPC9zZWN0aW9uPgoKICAgICAgPHNlY3Rpb24gdGl0bGU9JyJwYXNzd29yZCIgU3ludGF4 Jz4KCgk8ZmlndXJlPgoJICA8cHJlYW1ibGU+CgkgICAgVGhlIDxzcGFueCBzdHlsZT0ndmVyYic+ cGFzc3dvcmQ8L3NwYW54PiBlbGVtZW50IGlzIGRlZmluZWQgaW4KCSAgICA8eHJlZiB0YXJnZXQ9 InBhc3N3b3JkLXRvay1yZXEiLz46CgkgIDwvcHJlYW1ibGU+CgkgIDxhcnR3b3JrPjwhW0NEQVRB WwpwYXNzd29yZCA9ICpURVhUCl1dPjwvYXJ0d29yaz4KCTwvZmlndXJlPgoJPHQ+CgkgIChUaGlz IG1hdGNoZXMgdGhlIDxzcGFueCBzdHlsZT0ndmVyYic+cGFzc3dvcmQ8L3NwYW54PiBkZWZpbml0 aW9uIGluIHRoZQoJICBIVFRQIEJhc2ljIEF1dGhlbnRpY2F0aW9uIFNjaGVtZSA8eHJlZiB0YXJn ZXQ9J1JGQzI2MTcnLz4uKQoJPC90PgogICAgICA8L3NlY3Rpb24+CgogICAgICA8c2VjdGlvbiB0 aXRsZT0nInJlZnJlc2hfdG9rZW4iIFN5bnRheCc+CgoJPGZpZ3VyZT4KCSAgPHByZWFtYmxlPgoJ ICAgIFRoZSA8c3Bhbnggc3R5bGU9J3ZlcmInPnJlZnJlc2hfdG9rZW48L3NwYW54PiBlbGVtZW50 IGlzIGRlZmluZWQgaW4KCSAgICA8eHJlZiB0YXJnZXQ9InRva2VuLXJlc3BvbnNlIi8+IGFuZAoJ ICAgIDx4cmVmIHRhcmdldD0idG9rZW4tcmVmcmVzaCIvPjoKCSAgPC9wcmVhbWJsZT4KCSAgPGFy dHdvcms+PCFbQ0RBVEFbCnJlZnJlc2gtdG9rZW4gPSBiNjR0b2tlbgpdXT48L2FydHdvcms+Cgk8 L2ZpZ3VyZT4KICAgICAgPC9zZWN0aW9uPgoKICAgICAgPHNlY3Rpb24gdGl0bGU9J0VuZHBvaW50 IFBhcmFtZXRlciBTeW50YXgnPgoKCTxmaWd1cmU+CgkgIDxwcmVhbWJsZT4KCSAgICBUaGUgc3lu dGF4IGZvciBuZXcgZW5kcG9pbnQgcGFyYW1ldGVycyBpcyBkZWZpbmVkIGluCgkgICAgPHhyZWYg dGFyZ2V0PSJlbmRwb2ludC1wYXJhbXMiLz46CgkgIDwvcHJlYW1ibGU+CgkgIDxhcnR3b3JrPjwh W0NEQVRBWwpwYXJhbS1uYW1lID0gMSpuYW1lLWNoYXIKbmFtZS1jaGFyICA9ICItIiAvICIuIiAv ICJfIiAvIERJR0lUIC8gQUxQSEEKXV0+PC9hcnR3b3JrPgoJPC9maWd1cmU+CiAgICAgIDwvc2Vj dGlvbj4KCiAgICA8L3NlY3Rpb24+CgogICAgPHNlY3Rpb24gdGl0bGU9J0Fja25vd2xlZGdlbWVu dHMnPgogICAgICA8dD4KICAgICAgICBUaGUgaW5pdGlhbCBPQXV0aCAyLjAgcHJvdG9jb2wgc3Bl Y2lmaWNhdGlvbiB3YXMgZWRpdGVkIGJ5IERhdmlkIFJlY29yZG9uLCBiYXNlZCBvbiB0d28KICAg ICAgICBwcmV2aW91cyBwdWJsaWNhdGlvbnM6IHRoZSBPQXV0aCAxLjAgY29tbXVuaXR5IHNwZWNp ZmljYXRpb24gPHhyZWYgdGFyZ2V0PSdSRkM1ODQ5JyAvPiwgYW5kCiAgICAgICAgT0F1dGggV1JB UCAoT0F1dGggV2ViIFJlc291cmNlIEF1dGhvcml6YXRpb24gUHJvZmlsZXMpCiAgICAgICAgPHhy ZWYgdGFyZ2V0PSdJLUQuZHJhZnQtaGFyZHQtb2F1dGgtMDEnIC8+LiBUaGUgU2VjdXJpdHkgQ29u c2lkZXJhdGlvbnMgc2VjdGlvbiB3YXMgZHJhZnRlZAogICAgICAgIGJ5IFRvcnN0ZW4gTG9kZGVy c3RlZHQsIE1hcmsgTWNHbG9pbiwgUGhpbCBIdW50LCBhbmQgQW50aG9ueSBOYWRhbGluLgoJVGhl IEFCTkYgc2VjdGlvbiB3YXMgZHJhZnRlZCBieSBNaWNoYWVsIEIuIEpvbmVzLgogICAgICA8L3Q+ CiAgICAgIDx0PgogICAgICAgIFRoZSBPQXV0aCAxLjAgY29tbXVuaXR5IHNwZWNpZmljYXRpb24g d2FzIGVkaXRlZCBieSBFcmFuIEhhbW1lciBhbmQgYXV0aG9yZWQgYnkKICAgICAgICBNYXJrIEF0 d29vZCwgRGlyayBCYWxmYW56LCBEYXJyZW4gQm91bmRzLCBSaWNoYXJkIE0uIENvbmxhbiwgQmxh aW5lIENvb2ssIExlYWggQ3VsdmVyLAogICAgICAgIEJyZW5vIGRlIE1lZGVpcm9zLCBCcmlhbiBF YXRvbiwgS2VsbGFuIEVsbGlvdHQtTWNDcmVhLCBMYXJyeSBIYWxmZiwgRXJhbiBIYW1tZXIsCiAg ICAgICAgQmVuIExhdXJpZSwgQ2hyaXMgTWVzc2luYSwgSm9obiBQYW56ZXIsIFNhbSBRdWlnbGV5 LCBEYXZpZCBSZWNvcmRvbiwgRXJhbiBTYW5kbGVyLAogICAgICAgIEpvbmF0aGFuIFNlcmdlbnQs IFRvZGQgU2llbGluZywgQnJpYW4gU2xlc2luc2t5LCBhbmQgQW5keSBTbWl0aC4KICAgICAgPC90 PgogICAgICA8dD4KICAgICAgICBUaGUgT0F1dGggV1JBUCBzcGVjaWZpY2F0aW9uIHdhcyBlZGl0 ZWQgYnkgRGljayBIYXJkdCBhbmQgYXV0aG9yZWQgYnkgQnJpYW4gRWF0b24sCiAgICAgICAgWWFy b24gWS4gR29sYW5kLCBEaWNrIEhhcmR0LCBhbmQgQWxsZW4gVG9tLgogICAgICA8L3Q+CiAgICAg IDx0PgogICAgICAgIFRoaXMgc3BlY2lmaWNhdGlvbiBpcyB0aGUgd29yayBvZiB0aGUgT0F1dGgg V29ya2luZyBHcm91cCB3aGljaCBpbmNsdWRlcyBkb3plbnMgb2YgYWN0aXZlCiAgICAgICAgYW5k IGRlZGljYXRlZCBwYXJ0aWNpcGFudHMuIEluIHBhcnRpY3VsYXIsIHRoZSBmb2xsb3dpbmcgaW5k aXZpZHVhbHMgY29udHJpYnV0ZWQgaWRlYXMsCiAgICAgICAgZmVlZGJhY2ssIGFuZCB3b3JkaW5n IHdoaWNoIHNoYXBlZCBhbmQgZm9ybWVkIHRoZSBmaW5hbCBzcGVjaWZpY2F0aW9uOgogICAgICA8 L3Q+CiAgICAgIDx0PgogICAgICAgIE1pY2hhZWwgQWRhbXMsIEFtYW5kYSBBbmdhbmVzLCBBbmRy ZXcgQXJub3R0LCBEaXJrIEJhbGZhbnosIEFpZGVuIEJlbGwsIEJyaWFuIENhbXBiZWxsLAogICAg ICAgIFNjb3R0IENhbnRvciwgTWFyY29zIENhY2VyZXMsIEJsYWluZSBDb29rLCBSb2dlciBDcmV3 LCBCcmlhbiBFYXRvbiwgV2VzbGV5IEVkZHksIExlYWggQ3VsdmVyLAogICAgICAgIEJpbGwgZGUg aE9yYSwgQW5kcmUgRGVNYXJyZSwgQnJpYW4gRWF0b24sIFdvbHRlciBFbGRlcmluZywgQnJpYW4g RWxsaW4sIElnb3IgRmF5bmJlcmcsCiAgICAgICAgR2VvcmdlIEZsZXRjaGVyLCBUaW0gRnJlZW1h biwgTHVjYSBGcm9zaW5pLCBFdmFuIEdpbGJlcnQsIFlhcm9uIFkuIEdvbGFuZCwgQnJlbnQgR29s ZG1hbiwKICAgICAgICBLcmlzdG9mZmVyIEdyb25vd3NraSwgSnVzdGluIEhhcnQsIERpY2sgSGFy ZHQsIENyYWlnIEhlYXRoLCBQaGlsIEh1bnQsIE1pY2hhZWwgQi4gSm9uZXMsCiAgICAgICAgVGVy cnkgSm9uZXMsIEpvaG4gS2VtcCwgTWFyayBLZW50LCBSYWZmaSBLcmlrb3JpYW4sIENoYXNlbiBM ZSBIYXJhLCBSYXNtdXMgTGVyZG9yZiwKICAgICAgICBUb3JzdGVuIExvZGRlcnN0ZWR0LCBIdWkt TGFuIEx1LCBDYXNleSBMdWNhcywgUGF1bCBNYWRzZW4sIEFsYXN0YWlyIE1haXIsIEV2ZSBNYWxl ciwKICAgICAgICBKYW1lcyBNYW5nZXIsIE1hcmsgTWNHbG9pbiwgTGF1cmVuY2UgTWlhbywgV2ls bGlhbSBNaWxscywgQ2h1Y2sgTW9ydGltb3JlLCBBbnRob255IE5hZGFsaW4sCiAgICAgICAgSnVs aWFuIFJlc2Noa2UsIEp1c3RpbiBSaWNoZXIsIFBldGVyIFNhaW50LUFuZHJlLCBOYXQgU2FraW11 cmEsIFJvYiBTYXlyZSwKICAgICAgICBNYXJpdXMgU2N1cnRlc2N1LCBOYWl0aWsgU2hhaCwgTHVr ZSBTaGVwYXJkLCBWbGFkIFNrdm9ydHNvdiwgSnVzdGluIFNtaXRoLCBIYWliaW4gU29uZywKICAg ICAgICBOaXYgU3RlaW5nYXJ0ZW4sIENocmlzdGlhbiBTdHVibmVyLCBKZXJlbXkgU3VyaWVsLCBQ YXVsIFRhcmphbiwgQ2hyaXN0b3BoZXIgVGhvbWFzLAogICAgICAgIEhlbnJ5IFMuIFRob21wc29u LCBBbGxlbiBUb20sIEZyYW5rbGluIFRzZSwgTmljayBXYWxrZXIsIFNoYW5lIFdlZWRlbiwgYW5k IFNreWxhciBXb29kd2FyZC4KICAgICAgPC90PgogICAgICA8dD4KICAgICAgICBUaGlzIGRvY3Vt ZW50IHdhcyBwcm9kdWNlZCB1bmRlciB0aGUgY2hhaXJtYW5zaGlwIG9mIEJsYWluZSBDb29rLCBQ ZXRlciBTYWludC1BbmRyZSwKICAgICAgICBIYW5uZXMgVHNjaG9mZW5pZywgQmFycnkgTGVpYmEs IGFuZCBEZXJlayBBdGtpbnMuIFRoZSBhcmVhIGRpcmVjdG9ycyBpbmNsdWRlZCBMaXNhIER1c3Nl YXVsdCwKICAgICAgICBQZXRlciBTYWludC1BbmRyZSwgYW5kIFN0ZXBoZW4gRmFycmVsbC4KICAg ICAgPC90PgogICAgPC9zZWN0aW9uPgoKICAgIDxzZWN0aW9uIHRpdGxlPSJFZGl0b3IncyBOb3Rl cyI+CiAgICAgIDx0PgogICAgICAgIFdoaWxlIG1hbnkgcGVvcGxlIGNvbnRyaWJ1dGVkIHRvIHRo aXMgc3BlY2lmaWNhdGlvbiB0aHJvdWdob3V0IGl0cyBsb25nIGpvdXJuZXksIHRoZSBlZGl0b3IK ICAgICAgICB3b3VsZCBsaWtlIHRvIGFja25vd2xlZGdlIGFuZCB0aGFuayBhIGZldyBpbmRpdmlk dWFscyBmb3IgdGhlaXIgb3V0c3RhbmRpbmcgYW5kIGludmFsdWFibGUKICAgICAgICBlZmZvcnRz IGxlYWRpbmcgdXAgdG8gdGhlIHB1YmxpY2F0aW9uIG9mIHRoaXMgc3BlY2lmaWNhdGlvbi4KICAg ICAgPC90PgogICAgICA8dD4KICAgICAgICBEYXZpZCBSZWNvcmRvbiBmb3IgY29udGludW91c2x5 IGJlaW5nIG9uZSBvZiBPQXV0aCdzIG1vc3QgdmFsdWFibGUgYXNzZXRzLCBicmluZ2luZwogICAg ICAgIHByYWdtYXRpc20gYW5kIHVyZ2VuY3kgdG8gdGhlIHdvcmssIGFuZCBoZWxwaW5nIHNoYXBl IGl0IGZyb20gaXRzIHZlcnkgYmVnaW5uaW5nLCBhcyB3ZWxsCiAgICAgICAgYXMgYmVpbmcgb25l IG9mIHRoZSBiZXN0IGNvbGxhYm9yYXRvcnMgSSBoYWQgdGhlIHBsZWFzdXJlIG9mIHdvcmtpbmcg d2l0aC4KICAgICAgPC90PgogICAgICA8dD4KICAgICAgICBKYW1lcyBNYW5nZXIgZm9yIGhpcyBj cmVhdGl2ZSBpZGVhcyBhbmQgYWx3YXlzIGluc2lnaHRmdWwgZmVlZGJhY2suIEJyaWFuIENhbXBi ZWxsLAogICAgICAgIFRvcnN0ZW4gTG9kZGVyc3RlZHQsIENodWNrIE1vcnRpbW9yZSwgSnVzdGlu IFJpY2hlciwgTWFyaXVzIFNjdXJ0ZXNjdSwgYW5kIEx1a2UgU2hlcGFyZCBmb3IKICAgICAgICB0 aGVpciBjb250aW51ZWQgcGFydGljaXBhdGlvbiBhbmQgdmFsdWFibGUgZmVlZGJhY2suCiAgICAg IDwvdD4KICAgICAgPHQ+CiAgICAgICAgU3BlY2lhbCB0aGFua3MgZ29lcyB0byBNaWtlIEN1cnRp cyBhbmQgWWFob28hIGZvciB0aGVpciB1bmNvbmRpdGlvbmFsIHN1cHBvcnQgb2YgdGhpcyB3b3Jr CiAgICAgICAgZm9yIG92ZXIgdGhyZWUgeWVhcnMuCiAgICAgIDwvdD4KICAgIDwvc2VjdGlvbj4K CiAgPC9iYWNrPgoKPC9yZmM+Cg== --_004_4E1F6AAD24975D4BA5B16804296739436652630DTK5EX14MBXC284r_ Content-Type: text/plain; name="draft-ietf-oauth-v2-26+mbj-3.txt" Content-Description: draft-ietf-oauth-v2-26+mbj-3.txt Content-Disposition: attachment; filename="draft-ietf-oauth-v2-26+mbj-3.txt"; size=159611; creation-date="Sat, 02 Jun 2012 06:31:41 GMT"; modification-date="Sat, 02 Jun 2012 06:31:41 GMT" Content-Transfer-Encoding: base64 CgoKT0F1dGggV29ya2luZyBHcm91cCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIEUuIEhhbW1lciwgRWQuCkludGVybmV0LURyYWZ0Ck9ic29sZXRlczogNTg0OSAoaWYgYXBw cm92ZWQpICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBELiBSZWNvcmRvbgpJbnRlbmRl ZCBzdGF0dXM6IFN0YW5kYXJkcyBUcmFjayAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg RmFjZWJvb2sKRXhwaXJlczogRGVjZW1iZXIgNCwgMjAxMiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIEQuIEhhcmR0CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE1pY3Jvc29mdAogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBKdW5lIDIsIDIwMTIK CgogICAgICAgICAgICAgICAgIFRoZSBPQXV0aCAyLjAgQXV0aG9yaXphdGlvbiBGcmFtZXdvcmsK ICAgICAgICAgICAgICAgICAgICAgICAgIGRyYWZ0LWlldGYtb2F1dGgtdjItMjcKCkFic3RyYWN0 CgogICBUaGUgT0F1dGggMi4wIGF1dGhvcml6YXRpb24gZnJhbWV3b3JrIGVuYWJsZXMgYSB0aGly ZC1wYXJ0eQogICBhcHBsaWNhdGlvbiB0byBvYnRhaW4gbGltaXRlZCBhY2Nlc3MgdG8gYW4gSFRU UCBzZXJ2aWNlLCBlaXRoZXIgb24KICAgYmVoYWxmIG9mIGEgcmVzb3VyY2Ugb3duZXIgYnkgb3Jj aGVzdHJhdGluZyBhbiBhcHByb3ZhbCBpbnRlcmFjdGlvbgogICBiZXR3ZWVuIHRoZSByZXNvdXJj ZSBvd25lciBhbmQgdGhlIEhUVFAgc2VydmljZSwgb3IgYnkgYWxsb3dpbmcgdGhlCiAgIHRoaXJk LXBhcnR5IGFwcGxpY2F0aW9uIHRvIG9idGFpbiBhY2Nlc3Mgb24gaXRzIG93biBiZWhhbGYuICBU aGlzCiAgIHNwZWNpZmljYXRpb24gcmVwbGFjZXMgYW5kIG9ic29sZXRlcyB0aGUgT0F1dGggMS4w IHByb3RvY29sIGRlc2NyaWJlZAogICBpbiBSRkMgNTg0OS4KClN0YXR1cyBvZiB0aGlzIE1lbW8K CiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgaXMgc3VibWl0dGVkIGluIGZ1bGwgY29uZm9ybWFuY2Ug d2l0aCB0aGUKICAgcHJvdmlzaW9ucyBvZiBCQ1AgNzggYW5kIEJDUCA3OS4KCiAgIEludGVybmV0 LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5n CiAgIFRhc2sgRm9yY2UgKElFVEYpLiAgTm90ZSB0aGF0IG90aGVyIGdyb3VwcyBtYXkgYWxzbyBk aXN0cmlidXRlCiAgIHdvcmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LURyYWZ0cy4gIFRoZSBs aXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtCiAgIERyYWZ0cyBpcyBhdCBodHRwOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZHJhZnRzL2N1cnJlbnQvLgoKICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFm dCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzCiAgIGFuZCBtYXkg YmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMgYXQg YW55CiAgIHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMg YXMgcmVmZXJlbmNlCiAgIG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3 b3JrIGluIHByb2dyZXNzLiIKCiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgd2lsbCBleHBpcmUgb24g RGVjZW1iZXIgNCwgMjAxMi4KCkNvcHlyaWdodCBOb3RpY2UKCiAgIENvcHlyaWdodCAoYykgMjAx MiBJRVRGIFRydXN0IGFuZCB0aGUgcGVyc29ucyBpZGVudGlmaWVkIGFzIHRoZQogICBkb2N1bWVu dCBhdXRob3JzLiAgQWxsIHJpZ2h0cyByZXNlcnZlZC4KCiAgIFRoaXMgZG9jdW1lbnQgaXMgc3Vi amVjdCB0byBCQ1AgNzggYW5kIHRoZSBJRVRGIFRydXN0J3MgTGVnYWwKICAgUHJvdmlzaW9ucyBS ZWxhdGluZyB0byBJRVRGIERvY3VtZW50cwogICAoaHR0cDovL3RydXN0ZWUuaWV0Zi5vcmcvbGlj ZW5zZS1pbmZvKSBpbiBlZmZlY3Qgb24gdGhlIGRhdGUgb2YKICAgcHVibGljYXRpb24gb2YgdGhp cyBkb2N1bWVudC4gIFBsZWFzZSByZXZpZXcgdGhlc2UgZG9jdW1lbnRzCgoKCkhhbW1lciwgZXQg YWwuICAgICAgICAgIEV4cGlyZXMgRGVjZW1iZXIgNCwgMjAxMiAgICAgICAgICAgICAgICBbUGFn ZSAxXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgT0F1dGggMi4wICAgICAgICAg ICAgICAgICAgICAgIEp1bmUgMjAxMgoKCiAgIGNhcmVmdWxseSwgYXMgdGhleSBkZXNjcmliZSB5 b3VyIHJpZ2h0cyBhbmQgcmVzdHJpY3Rpb25zIHdpdGggcmVzcGVjdAogICB0byB0aGlzIGRvY3Vt ZW50LiAgQ29kZSBDb21wb25lbnRzIGV4dHJhY3RlZCBmcm9tIHRoaXMgZG9jdW1lbnQgbXVzdAog ICBpbmNsdWRlIFNpbXBsaWZpZWQgQlNEIExpY2Vuc2UgdGV4dCBhcyBkZXNjcmliZWQgaW4gU2Vj dGlvbiA0LmUgb2YKICAgdGhlIFRydXN0IExlZ2FsIFByb3Zpc2lvbnMgYW5kIGFyZSBwcm92aWRl ZCB3aXRob3V0IHdhcnJhbnR5IGFzCiAgIGRlc2NyaWJlZCBpbiB0aGUgU2ltcGxpZmllZCBCU0Qg TGljZW5zZS4KCgpUYWJsZSBvZiBDb250ZW50cwoKICAgMS4gIEludHJvZHVjdGlvbiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA1CiAgICAgMS4xLiAg IFJvbGVzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAgNgogICAgIDEuMi4gICBQcm90b2NvbCBGbG93IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gIDcKICAgICAxLjMuICAgQXV0aG9yaXphdGlvbiBHcmFudCAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA4CiAgICAgICAxLjMuMS4gIEF1dGhv cml6YXRpb24gQ29kZSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgOAogICAg ICAgMS4zLjIuICBJbXBsaWNpdCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gIDgKICAgICAgIDEuMy4zLiAgUmVzb3VyY2UgT3duZXIgUGFzc3dvcmQgQ3JlZGVu dGlhbHMgIC4gLiAuIC4gLiAuIC4gLiAuICA5CiAgICAgICAxLjMuNC4gIENsaWVudCBDcmVkZW50 aWFscyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgOQogICAgIDEuNC4gICBB Y2Nlc3MgVG9rZW4gIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g IDkKICAgICAxLjUuICAgUmVmcmVzaCBUb2tlbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIDEwCiAgICAgMS42LiAgIFRMUyBWZXJzaW9uIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMgogICAgIDEuNy4gICBIVFRQIFJlZGly ZWN0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTIKICAgICAx LjguICAgSW50ZXJvcGVyYWJpbGl0eSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIDEyCiAgICAgMS45LiAgIE5vdGF0aW9uYWwgQ29udmVudGlvbnMgIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMwogICAyLiAgQ2xpZW50IFJlZ2lzdHJhdGlvbiAgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTMKICAgICAyLjEuICAgQ2xp ZW50IFR5cGVzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE0 CiAgICAgMi4yLiAgIENsaWVudCBJZGVudGlmaWVyIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAxNQogICAgIDIuMy4gICBDbGllbnQgQXV0aGVudGljYXRpb24gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTUKICAgICAgIDIuMy4xLiAgQ2xpZW50IFBh c3N3b3JkICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE2CiAgICAgICAy LjMuMi4gIE90aGVyIEF1dGhlbnRpY2F0aW9uIE1ldGhvZHMgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAxNwogICAgIDIuNC4gICBVbnJlZ2lzdGVyZWQgQ2xpZW50cyAgLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gMTcKICAgMy4gIFByb3RvY29sIEVuZHBvaW50cyAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE3CiAgICAgMy4xLiAgIEF1dGhv cml6YXRpb24gRW5kcG9pbnQgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNwog ICAgICAgMy4xLjEuICBSZXNwb25zZSBUeXBlICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gMTgKICAgICAgIDMuMS4yLiAgUmVkaXJlY3Rpb24gRW5kcG9pbnQgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE5CiAgICAgMy4yLiAgIFRva2VuIEVuZHBvaW50 ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAyMQogICAgICAgMy4y LjEuICBDbGllbnQgQXV0aGVudGljYXRpb24gIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gMjEKICAgICAzLjMuICAgQWNjZXNzIFRva2VuIFNjb3BlICAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIDIyCiAgIDQuICBPYnRhaW5pbmcgQXV0aG9yaXphdGlvbiAgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAyMwogICAgIDQuMS4gICBBdXRob3Jp emF0aW9uIENvZGUgR3JhbnQgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjMKICAg ICAgIDQuMS4xLiAgQXV0aG9yaXphdGlvbiBSZXF1ZXN0ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIDI0CiAgICAgICA0LjEuMi4gIEF1dGhvcml6YXRpb24gUmVzcG9uc2UgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAyNQogICAgICAgNC4xLjMuICBBY2Nlc3MgVG9rZW4g UmVxdWVzdCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjcKICAgICAgIDQuMS40 LiAgQWNjZXNzIFRva2VuIFJlc3BvbnNlICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IDI4CiAgICAgNC4yLiAgIEltcGxpY2l0IEdyYW50ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAyOQogICAgICAgNC4yLjEuICBBdXRob3JpemF0aW9uIFJlcXVlc3Qg IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMzEKICAgICAgIDQuMi4yLiAgQWNjZXNz IFRva2VuIFJlc3BvbnNlICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDMyCiAgICAg NC4zLiAgIFJlc291cmNlIE93bmVyIFBhc3N3b3JkIENyZWRlbnRpYWxzIEdyYW50IC4gLiAuIC4g LiAuIC4gLiAzNQogICAgICAgNC4zLjEuICBBdXRob3JpemF0aW9uIFJlcXVlc3QgYW5kIFJlc3Bv bnNlIC4gLiAuIC4gLiAuIC4gLiAuIC4gMzYKCgoKSGFtbWVyLCBldCBhbC4gICAgICAgICAgRXhw aXJlcyBEZWNlbWJlciA0LCAyMDEyICAgICAgICAgICAgICAgIFtQYWdlIDJdCgwKSW50ZXJuZXQt RHJhZnQgICAgICAgICAgICAgICAgICBPQXV0aCAyLjAgICAgICAgICAgICAgICAgICAgICAgSnVu ZSAyMDEyCgoKICAgICAgIDQuMy4yLiAgQWNjZXNzIFRva2VuIFJlcXVlc3QgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIDM2CiAgICAgICA0LjMuMy4gIEFjY2VzcyBUb2tlbiBSZXNw b25zZSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAzNwogICAgIDQuNC4gICBDbGll bnQgQ3JlZGVudGlhbHMgR3JhbnQgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMzcK ICAgICAgIDQuNC4xLiAgQXV0aG9yaXphdGlvbiBSZXF1ZXN0IGFuZCBSZXNwb25zZSAuIC4gLiAu IC4gLiAuIC4gLiAuIDM4CiAgICAgICA0LjQuMi4gIEFjY2VzcyBUb2tlbiBSZXF1ZXN0IC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAzOAogICAgICAgNC40LjMuICBBY2Nlc3MgVG9r ZW4gUmVzcG9uc2UgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMzkKICAgICA0LjUu ICAgRXh0ZW5zaW9uIEdyYW50cyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIDM5CiAgIDUuICBJc3N1aW5nIGFuIEFjY2VzcyBUb2tlbiAgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiA0MAogICAgIDUuMS4gICBTdWNjZXNzZnVsIFJlc3BvbnNlIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNDAKICAgICA1LjIuICAgRXJyb3Ig UmVzcG9uc2UgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDQxCiAg IDYuICBSZWZyZXNoaW5nIGFuIEFjY2VzcyBUb2tlbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiA0MwogICA3LiAgQWNjZXNzaW5nIFByb3RlY3RlZCBSZXNvdXJjZXMgIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNDQKICAgICA3LjEuICAgQWNjZXNzIFRva2VuIFR5 cGVzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDQ1CiAgICAgNy4yLiAg IEVycm9yIFJlc3BvbnNlICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiA0NgogICA4LiAgRXh0ZW5zaWJpbGl0eSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gNDYKICAgICA4LjEuICAgRGVmaW5pbmcgQWNjZXNzIFRva2VuIFR5 cGVzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDQ2CiAgICAgOC4yLiAgIERlZmluaW5n IE5ldyBFbmRwb2ludCBQYXJhbWV0ZXJzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA0NwogICAg IDguMy4gICBEZWZpbmluZyBOZXcgQXV0aG9yaXphdGlvbiBHcmFudCBUeXBlcyAgLiAuIC4gLiAu IC4gLiAuIC4gNDcKICAgICA4LjQuICAgRGVmaW5pbmcgTmV3IEF1dGhvcml6YXRpb24gRW5kcG9p bnQgUmVzcG9uc2UgVHlwZXMgIC4gLiAuIDQ3CiAgICAgOC41LiAgIERlZmluaW5nIEFkZGl0aW9u YWwgRXJyb3IgQ29kZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA0OAogICA5LiAgTmF0aXZl IEFwcGxpY2F0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g NDgKICAgMTAuIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIDUwCiAgICAgMTAuMS4gIENsaWVudCBBdXRoZW50aWNhdGlvbiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA1MAogICAgIDEwLjIuICBDbGllbnQgSW1w ZXJzb25hdGlvbiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNTAKICAgICAx MC4zLiAgQWNjZXNzIFRva2VucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIDUxCiAgICAgMTAuNC4gIFJlZnJlc2ggVG9rZW5zICAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA1MgogICAgIDEwLjUuICBBdXRob3JpemF0aW9uIENvZGVz IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNTIKICAgICAxMC42LiAgQXV0 aG9yaXphdGlvbiBDb2RlIFJlZGlyZWN0aW9uIFVSSSBNYW5pcHVsYXRpb24gLiAuIC4gLiAuIDUz CiAgICAgMTAuNy4gIFJlc291cmNlIE93bmVyIFBhc3N3b3JkIENyZWRlbnRpYWxzIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiA1NAogICAgIDEwLjguICBSZXF1ZXN0IENvbmZpZGVudGlhbGl0eSAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNTQKICAgICAxMC45LiAgRW5kcG9pbnRzIEF1 dGhlbnRpY2l0eSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDU0CiAgICAgMTAu MTAuIENyZWRlbnRpYWxzIEd1ZXNzaW5nIEF0dGFja3MgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiA1NAogICAgIDEwLjExLiBQaGlzaGluZyBBdHRhY2tzICAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gNTUKICAgICAxMC4xMi4gQ3Jvc3MtU2l0ZSBSZXF1ZXN0IEZv cmdlcnkgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDU1CiAgICAgMTAuMTMuIENsaWNr amFja2luZyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA1Ngog ICAgIDEwLjE0LiBDb2RlIEluamVjdGlvbiBhbmQgSW5wdXQgVmFsaWRhdGlvbiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gNTcKICAgICAxMC4xNS4gT3BlbiBSZWRpcmVjdG9ycyAgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDU3CiAgIDExLiBJQU5BIENvbnNpZGVyYXRpb25z ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA1NwogICAgIDExLjEu ICBUaGUgT0F1dGggQWNjZXNzIFRva2VuIFR5cGUgUmVnaXN0cnkgIC4gLiAuIC4gLiAuIC4gLiAu IC4gNTcKICAgICAgIDExLjEuMS4gUmVnaXN0cmF0aW9uIFRlbXBsYXRlICAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIDU4CiAgICAgMTEuMi4gIFRoZSBPQXV0aCBQYXJhbWV0ZXJzIFJl Z2lzdHJ5IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA1OAogICAgICAgMTEuMi4xLiBSZWdp c3RyYXRpb24gVGVtcGxhdGUgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNTkKICAg ICAgIDExLjIuMi4gSW5pdGlhbCBSZWdpc3RyeSBDb250ZW50cyAgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIDU5CiAgICAgMTEuMy4gIFRoZSBPQXV0aCBBdXRob3JpemF0aW9uIEVuZHBvaW50 IFJlc3BvbnNlIFR5cGUKICAgICAgICAgICAgUmVnaXN0cnkgIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDYxCiAgICAgICAxMS4zLjEuIFJlZ2lzdHJhdGlv biBUZW1wbGF0ZSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA2MgogICAgICAgMTEu My4yLiBJbml0aWFsIFJlZ2lzdHJ5IENvbnRlbnRzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gNjIKICAgICAxMS40LiAgVGhlIE9BdXRoIEV4dGVuc2lvbnMgRXJyb3IgUmVnaXN0cnkgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIDYyCgoKCkhhbW1lciwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMg RGVjZW1iZXIgNCwgMjAxMiAgICAgICAgICAgICAgICBbUGFnZSAzXQoMCkludGVybmV0LURyYWZ0 ICAgICAgICAgICAgICAgICAgT0F1dGggMi4wICAgICAgICAgICAgICAgICAgICAgIEp1bmUgMjAx MgoKCiAgICAgICAxMS40LjEuIFJlZ2lzdHJhdGlvbiBUZW1wbGF0ZSAgLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiA2MwogICAxMi4gUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNjMKICAgICAxMi4xLiAgTm9ybWF0aXZl IFJlZmVyZW5jZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDYzCiAgICAg MTIuMi4gIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiA2NQogICBBcHBlbmRpeCBBLiAgQXVnbWVudGVkIEJhY2t1cy1OYXVyIEZvcm0gKEFC TkYpIFN5bnRheCAgLiAuIC4gLiAuIC4gNjUKICAgICBBLjEuICAgImNsaWVudF9pZCIgU3ludGF4 ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDY2CiAgICAgQS4yLiAgICJj bGllbnRfc2VjcmV0IiBTeW50YXggIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA2 NgogICAgIEEuMy4gICAicmVzcG9uc2VfdHlwZSIgU3ludGF4ICAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gNjYKICAgICBBLjQuICAgInNjb3BlIiBTeW50YXggIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDY2CiAgICAgQS41LiAgICJzdGF0ZSIgU3lu dGF4ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA2NwogICAgIEEu Ni4gICAicmVkaXJlY3RfdXJpIiBTeW50YXggLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gNjcKICAgICBBLjcuICAgImVycm9yIiBTeW50YXggIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIDY3CiAgICAgQS44LiAgICJlcnJvcl9kZXNjcmlwdGlvbiIg U3ludGF4ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA2NwogICAgIEEuOS4gICAiZXJy b3JfdXJpIiBTeW50YXggIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNjcK ICAgICBBLjEwLiAgImdyYW50X3R5cGUiIFN5bnRheCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIDY3CiAgICAgQS4xMS4gICJjb2RlIiBTeW50YXggLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA2OAogICAgIEEuMTIuICAiYWNjZXNzX3Rva2Vu IiBTeW50YXggLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNjgKICAgICBBLjEz LiAgInRva2VuX3R5cGUiIFN5bnRheCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIDY4CiAgICAgQS4xNC4gICJleHBpcmVzX2luIiBTeW50YXggLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiA2OAogICAgIEEuMTUuICAidXNlcm5hbWUiIFN5bnRheCAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNjgKICAgICBBLjE2LiAgInBhc3N3 b3JkIiBTeW50YXggLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDY4CiAg ICAgQS4xNy4gICJyZWZyZXNoX3Rva2VuIiBTeW50YXggIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiA2OQogICAgIEEuMTguICBFbmRwb2ludCBQYXJhbWV0ZXIgU3ludGF4IC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNjkKICAgQXBwZW5kaXggQi4gIEFja25vd2xlZGdl bWVudHMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDY5CiAgIEFwcGVuZGl4 IEMuICBFZGl0b3IncyBOb3RlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiA3MAogICBBdXRob3JzJyBBZGRyZXNzZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gNzAKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCkhhbW1lciwgZXQg YWwuICAgICAgICAgIEV4cGlyZXMgRGVjZW1iZXIgNCwgMjAxMiAgICAgICAgICAgICAgICBbUGFn ZSA0XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgT0F1dGggMi4wICAgICAgICAg ICAgICAgICAgICAgIEp1bmUgMjAxMgoKCjEuICBJbnRyb2R1Y3Rpb24KCiAgIEluIHRoZSB0cmFk aXRpb25hbCBjbGllbnQtc2VydmVyIGF1dGhlbnRpY2F0aW9uIG1vZGVsLCB0aGUgY2xpZW50CiAg IHJlcXVlc3RzIGFuIGFjY2VzcyByZXN0cmljdGVkIHJlc291cmNlIChwcm90ZWN0ZWQgcmVzb3Vy Y2UpIG9uIHRoZQogICBzZXJ2ZXIgYnkgYXV0aGVudGljYXRpbmcgd2l0aCB0aGUgc2VydmVyIHVz aW5nIHRoZSByZXNvdXJjZSBvd25lcidzCiAgIGNyZWRlbnRpYWxzLiAgSW4gb3JkZXIgdG8gcHJv dmlkZSB0aGlyZC1wYXJ0eSBhcHBsaWNhdGlvbnMgYWNjZXNzIHRvCiAgIHJlc3RyaWN0ZWQgcmVz b3VyY2VzLCB0aGUgcmVzb3VyY2Ugb3duZXIgc2hhcmVzIGl0cyBjcmVkZW50aWFscyB3aXRoCiAg IHRoZSB0aGlyZC1wYXJ0eS4gIFRoaXMgY3JlYXRlcyBzZXZlcmFsIHByb2JsZW1zIGFuZCBsaW1p dGF0aW9uczoKCiAgIG8gIFRoaXJkLXBhcnR5IGFwcGxpY2F0aW9ucyBhcmUgcmVxdWlyZWQgdG8g c3RvcmUgdGhlIHJlc291cmNlCiAgICAgIG93bmVyJ3MgY3JlZGVudGlhbHMgZm9yIGZ1dHVyZSB1 c2UsIHR5cGljYWxseSBhIHBhc3N3b3JkIGluIGNsZWFyLQogICAgICB0ZXh0LgogICBvICBTZXJ2 ZXJzIGFyZSByZXF1aXJlZCB0byBzdXBwb3J0IHBhc3N3b3JkIGF1dGhlbnRpY2F0aW9uLCBkZXNw aXRlCiAgICAgIHRoZSBzZWN1cml0eSB3ZWFrbmVzc2VzIGluaGVyZW50IGluIHBhc3N3b3Jkcy4K ICAgbyAgVGhpcmQtcGFydHkgYXBwbGljYXRpb25zIGdhaW4gb3Zlcmx5IGJyb2FkIGFjY2VzcyB0 byB0aGUgcmVzb3VyY2UKICAgICAgb3duZXIncyBwcm90ZWN0ZWQgcmVzb3VyY2VzLCBsZWF2aW5n IHJlc291cmNlIG93bmVycyB3aXRob3V0IGFueQogICAgICBhYmlsaXR5IHRvIHJlc3RyaWN0IGR1 cmF0aW9uIG9yIGFjY2VzcyB0byBhIGxpbWl0ZWQgc3Vic2V0IG9mCiAgICAgIHJlc291cmNlcy4K ICAgbyAgUmVzb3VyY2Ugb3duZXJzIGNhbm5vdCByZXZva2UgYWNjZXNzIHRvIGFuIGluZGl2aWR1 YWwgdGhpcmQtcGFydHkKICAgICAgd2l0aG91dCByZXZva2luZyBhY2Nlc3MgdG8gYWxsIHRoaXJk LXBhcnRpZXMsIGFuZCBtdXN0IGRvIHNvIGJ5CiAgICAgIGNoYW5naW5nIHRoZWlyIHBhc3N3b3Jk LgogICBvICBDb21wcm9taXNlIG9mIGFueSB0aGlyZC1wYXJ0eSBhcHBsaWNhdGlvbiByZXN1bHRz IGluIGNvbXByb21pc2Ugb2YKICAgICAgdGhlIGVuZC11c2VyJ3MgcGFzc3dvcmQgYW5kIGFsbCBv ZiB0aGUgZGF0YSBwcm90ZWN0ZWQgYnkgdGhhdAogICAgICBwYXNzd29yZC4KCiAgIE9BdXRoIGFk ZHJlc3NlcyB0aGVzZSBpc3N1ZXMgYnkgaW50cm9kdWNpbmcgYW4gYXV0aG9yaXphdGlvbiBsYXll cgogICBhbmQgc2VwYXJhdGluZyB0aGUgcm9sZSBvZiB0aGUgY2xpZW50IGZyb20gdGhhdCBvZiB0 aGUgcmVzb3VyY2UKICAgb3duZXIuICBJbiBPQXV0aCwgdGhlIGNsaWVudCByZXF1ZXN0cyBhY2Nl c3MgdG8gcmVzb3VyY2VzIGNvbnRyb2xsZWQKICAgYnkgdGhlIHJlc291cmNlIG93bmVyIGFuZCBo b3N0ZWQgYnkgdGhlIHJlc291cmNlIHNlcnZlciwgYW5kIGlzCiAgIGlzc3VlZCBhIGRpZmZlcmVu dCBzZXQgb2YgY3JlZGVudGlhbHMgdGhhbiB0aG9zZSBvZiB0aGUgcmVzb3VyY2UKICAgb3duZXIu CgogICBJbnN0ZWFkIG9mIHVzaW5nIHRoZSByZXNvdXJjZSBvd25lcidzIGNyZWRlbnRpYWxzIHRv IGFjY2VzcyBwcm90ZWN0ZWQKICAgcmVzb3VyY2VzLCB0aGUgY2xpZW50IG9idGFpbnMgYW4gYWNj ZXNzIHRva2VuIC0gYSBzdHJpbmcgZGVub3RpbmcgYQogICBzcGVjaWZpYyBzY29wZSwgbGlmZXRp bWUsIGFuZCBvdGhlciBhY2Nlc3MgYXR0cmlidXRlcy4gIEFjY2VzcyB0b2tlbnMKICAgYXJlIGlz c3VlZCB0byB0aGlyZC1wYXJ0eSBjbGllbnRzIGJ5IGFuIGF1dGhvcml6YXRpb24gc2VydmVyIHdp dGggdGhlCiAgIGFwcHJvdmFsIG9mIHRoZSByZXNvdXJjZSBvd25lci4gIFRoZSBjbGllbnQgdXNl cyB0aGUgYWNjZXNzIHRva2VuIHRvCiAgIGFjY2VzcyB0aGUgcHJvdGVjdGVkIHJlc291cmNlcyBo b3N0ZWQgYnkgdGhlIHJlc291cmNlIHNlcnZlci4KCiAgIEZvciBleGFtcGxlLCBhbiBlbmQtdXNl ciAocmVzb3VyY2Ugb3duZXIpIGNhbiBncmFudCBhIHByaW50aW5nCiAgIHNlcnZpY2UgKGNsaWVu dCkgYWNjZXNzIHRvIGhlciBwcm90ZWN0ZWQgcGhvdG9zIHN0b3JlZCBhdCBhIHBob3RvCiAgIHNo YXJpbmcgc2VydmljZSAocmVzb3VyY2Ugc2VydmVyKSwgd2l0aG91dCBzaGFyaW5nIGhlciB1c2Vy bmFtZSBhbmQKICAgcGFzc3dvcmQgd2l0aCB0aGUgcHJpbnRpbmcgc2VydmljZS4gIEluc3RlYWQs IHNoZSBhdXRoZW50aWNhdGVzCiAgIGRpcmVjdGx5IHdpdGggYSBzZXJ2ZXIgdHJ1c3RlZCBieSB0 aGUgcGhvdG8gc2hhcmluZyBzZXJ2aWNlCiAgIChhdXRob3JpemF0aW9uIHNlcnZlcikgd2hpY2gg aXNzdWVzIHRoZSBwcmludGluZyBzZXJ2aWNlIGRlbGVnYXRpb24tCiAgIHNwZWNpZmljIGNyZWRl bnRpYWxzIChhY2Nlc3MgdG9rZW4pLgoKICAgVGhpcyBzcGVjaWZpY2F0aW9uIGlzIGRlc2lnbmVk IGZvciB1c2Ugd2l0aCBIVFRQIChbUkZDMjYxNl0pLiAgVGhlCgoKCkhhbW1lciwgZXQgYWwuICAg ICAgICAgIEV4cGlyZXMgRGVjZW1iZXIgNCwgMjAxMiAgICAgICAgICAgICAgICBbUGFnZSA1XQoM CkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgT0F1dGggMi4wICAgICAgICAgICAgICAg ICAgICAgIEp1bmUgMjAxMgoKCiAgIHVzZSBvZiBPQXV0aCBvdmVyIGFueSBvdGhlciBwcm90b2Nv bCB0aGFuIEhUVFAgaXMgb3V0IG9mIHNjb3BlLgoKICAgVGhlIE9BdXRoIDEuMCBwcm90b2NvbCAo W1JGQzU4NDldKSwgcHVibGlzaGVkIGFzIGFuIGluZm9ybWF0aW9uYWwKICAgZG9jdW1lbnQsIHdh cyB0aGUgcmVzdWx0IG9mIGEgc21hbGwgYWQtaG9jIGNvbW11bml0eSBlZmZvcnQuICBUaGlzCiAg IHN0YW5kYXJkcy10cmFjayBzcGVjaWZpY2F0aW9uIGJ1aWxkcyBvbiB0aGUgT0F1dGggMS4wIGRl cGxveW1lbnQKICAgZXhwZXJpZW5jZSwgYXMgd2VsbCBhcyBhZGRpdGlvbmFsIHVzZSBjYXNlcyBh bmQgZXh0ZW5zaWJpbGl0eQogICByZXF1aXJlbWVudHMgZ2F0aGVyZWQgZnJvbSB0aGUgd2lkZXIg SUVURiBjb21tdW5pdHkuICBUaGUgT0F1dGggMi4wCiAgIHByb3RvY29sIGlzIG5vdCBiYWNrd2Fy ZCBjb21wYXRpYmxlIHdpdGggT0F1dGggMS4wLiAgVGhlIHR3byB2ZXJzaW9ucwogICBtYXkgY28t ZXhpc3Qgb24gdGhlIG5ldHdvcmsgYW5kIGltcGxlbWVudGF0aW9ucyBtYXkgY2hvb3NlIHRvIHN1 cHBvcnQKICAgYm90aC4gIEhvd2V2ZXIsIGl0IGlzIHRoZSBpbnRlbnRpb24gb2YgdGhpcyBzcGVj aWZpY2F0aW9uIHRoYXQgbmV3CiAgIGltcGxlbWVudGF0aW9uIHN1cHBvcnQgT0F1dGggMi4wIGFz IHNwZWNpZmllZCBpbiB0aGlzIGRvY3VtZW50LCBhbmQKICAgdGhhdCBPQXV0aCAxLjAgaXMgdXNl ZCBvbmx5IHRvIHN1cHBvcnQgZXhpc3RpbmcgZGVwbG95bWVudHMuICBUaGUKICAgT0F1dGggMi4w IHByb3RvY29sIHNoYXJlcyB2ZXJ5IGZldyBpbXBsZW1lbnRhdGlvbiBkZXRhaWxzIHdpdGggdGhl CiAgIE9BdXRoIDEuMCBwcm90b2NvbC4gIEltcGxlbWVudGVycyBmYW1pbGlhciB3aXRoIE9BdXRo IDEuMCBzaG91bGQKICAgYXBwcm9hY2ggdGhpcyBkb2N1bWVudCB3aXRob3V0IGFueSBhc3N1bXB0 aW9ucyBhcyB0byBpdHMgc3RydWN0dXJlCiAgIGFuZCBkZXRhaWxzLgoKMS4xLiAgUm9sZXMKCiAg IE9BdXRoIGRlZmluZXMgZm91ciByb2xlczoKCiAgIHJlc291cmNlIG93bmVyCiAgICAgIEFuIGVu dGl0eSBjYXBhYmxlIG9mIGdyYW50aW5nIGFjY2VzcyB0byBhIHByb3RlY3RlZCByZXNvdXJjZS4K ICAgICAgV2hlbiB0aGUgcmVzb3VyY2Ugb3duZXIgaXMgYSBwZXJzb24sIGl0IGlzIHJlZmVycmVk IHRvIGFzIGFuIGVuZC0KICAgICAgdXNlci4KICAgcmVzb3VyY2Ugc2VydmVyCiAgICAgIFRoZSBz ZXJ2ZXIgaG9zdGluZyB0aGUgcHJvdGVjdGVkIHJlc291cmNlcywgY2FwYWJsZSBvZiBhY2NlcHRp bmcKICAgICAgYW5kIHJlc3BvbmRpbmcgdG8gcHJvdGVjdGVkIHJlc291cmNlIHJlcXVlc3RzIHVz aW5nIGFjY2VzcyB0b2tlbnMuCiAgIGNsaWVudAogICAgICBBbiBhcHBsaWNhdGlvbiBtYWtpbmcg cHJvdGVjdGVkIHJlc291cmNlIHJlcXVlc3RzIG9uIGJlaGFsZiBvZiB0aGUKICAgICAgcmVzb3Vy Y2Ugb3duZXIgYW5kIHdpdGggaXRzIGF1dGhvcml6YXRpb24uICBUaGUgdGVybSBjbGllbnQgZG9l cwogICAgICBub3QgaW1wbHkgYW55IHBhcnRpY3VsYXIgaW1wbGVtZW50YXRpb24gY2hhcmFjdGVy aXN0aWNzIChlLmcuCiAgICAgIHdoZXRoZXIgdGhlIGFwcGxpY2F0aW9uIGV4ZWN1dGVzIG9uIGEg c2VydmVyLCBhIGRlc2t0b3AsIG9yIG90aGVyCiAgICAgIGRldmljZXMpLgogICBhdXRob3JpemF0 aW9uIHNlcnZlcgogICAgICBUaGUgc2VydmVyIGlzc3VpbmcgYWNjZXNzIHRva2VucyB0byB0aGUg Y2xpZW50IGFmdGVyIHN1Y2Nlc3NmdWxseQogICAgICBhdXRoZW50aWNhdGluZyB0aGUgcmVzb3Vy Y2Ugb3duZXIgYW5kIG9idGFpbmluZyBhdXRob3JpemF0aW9uLgoKICAgVGhlIGludGVyYWN0aW9u IGJldHdlZW4gdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGFuZCByZXNvdXJjZSBzZXJ2ZXIKICAg aXMgYmV5b25kIHRoZSBzY29wZSBvZiB0aGlzIHNwZWNpZmljYXRpb24uICBUaGUgYXV0aG9yaXph dGlvbiBzZXJ2ZXIKICAgbWF5IGJlIHRoZSBzYW1lIHNlcnZlciBhcyB0aGUgcmVzb3VyY2Ugc2Vy dmVyIG9yIGEgc2VwYXJhdGUgZW50aXR5LgogICBBIHNpbmdsZSBhdXRob3JpemF0aW9uIHNlcnZl ciBtYXkgaXNzdWUgYWNjZXNzIHRva2VucyBhY2NlcHRlZCBieQogICBtdWx0aXBsZSByZXNvdXJj ZSBzZXJ2ZXJzLgoKCgoKCgoKCkhhbW1lciwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgRGVjZW1i ZXIgNCwgMjAxMiAgICAgICAgICAgICAgICBbUGFnZSA2XQoMCkludGVybmV0LURyYWZ0ICAgICAg ICAgICAgICAgICAgT0F1dGggMi4wICAgICAgICAgICAgICAgICAgICAgIEp1bmUgMjAxMgoKCjEu Mi4gIFByb3RvY29sIEZsb3cKCgogICAgICstLS0tLS0tLSsgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLSsKICAgICB8ICAgICAgICB8LS0oQSktIEF1dGhvcml6 YXRpb24gUmVxdWVzdCAtPnwgICBSZXNvdXJjZSAgICB8CiAgICAgfCAgICAgICAgfCAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB8ICAgICBPd25lciAgICAgfAogICAgIHwgICAgICAgIHw8 LShCKS0tIEF1dGhvcml6YXRpb24gR3JhbnQgLS0tfCAgICAgICAgICAgICAgIHwKICAgICB8ICAg ICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0rCiAg ICAgfCAgICAgICAgfAogICAgIHwgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgKy0tLS0tLS0tLS0tLS0tLSsKICAgICB8ICAgICAgICB8LS0oQyktLSBBdXRob3JpemF0aW9u IEdyYW50IC0tPnwgQXV0aG9yaXphdGlvbiB8CiAgICAgfCBDbGllbnQgfCAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICB8ICAgICBTZXJ2ZXIgICAgfAogICAgIHwgICAgICAgIHw8LShEKS0t LS0tIEFjY2VzcyBUb2tlbiAtLS0tLS0tfCAgICAgICAgICAgICAgIHwKICAgICB8ICAgICAgICB8 ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0rCiAgICAgfCAg ICAgICAgfAogICAgIHwgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0t LS0tLS0tLS0tLS0tLSsKICAgICB8ICAgICAgICB8LS0oRSktLS0tLSBBY2Nlc3MgVG9rZW4gLS0t LS0tPnwgICAgUmVzb3VyY2UgICB8CiAgICAgfCAgICAgICAgfCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB8ICAgICBTZXJ2ZXIgICAgfAogICAgIHwgICAgICAgIHw8LShGKS0tLSBQcm90 ZWN0ZWQgUmVzb3VyY2UgLS0tfCAgICAgICAgICAgICAgIHwKICAgICArLS0tLS0tLS0rICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0rCgoKICAgICAgICAgICAg ICAgICAgICAgRmlndXJlIDE6IEFic3RyYWN0IFByb3RvY29sIEZsb3cKCiAgIFRoZSBhYnN0cmFj dCBmbG93IGlsbHVzdHJhdGVkIGluIEZpZ3VyZSAxIGRlc2NyaWJlcyB0aGUgaW50ZXJhY3Rpb24K ICAgYmV0d2VlbiB0aGUgZm91ciByb2xlcyBhbmQgaW5jbHVkZXMgdGhlIGZvbGxvd2luZyBzdGVw czoKCiAgIChBKSAgVGhlIGNsaWVudCByZXF1ZXN0cyBhdXRob3JpemF0aW9uIGZyb20gdGhlIHJl c291cmNlIG93bmVyLiAgVGhlCiAgICAgICAgYXV0aG9yaXphdGlvbiByZXF1ZXN0IGNhbiBiZSBt YWRlIGRpcmVjdGx5IHRvIHRoZSByZXNvdXJjZSBvd25lcgogICAgICAgIChhcyBzaG93biksIG9y IHByZWZlcmFibHkgaW5kaXJlY3RseSB2aWEgdGhlIGF1dGhvcml6YXRpb24KICAgICAgICBzZXJ2 ZXIgYXMgYW4gaW50ZXJtZWRpYXJ5LgogICAoQikgIFRoZSBjbGllbnQgcmVjZWl2ZXMgYW4gYXV0 aG9yaXphdGlvbiBncmFudCB3aGljaCBpcyBhIGNyZWRlbnRpYWwKICAgICAgICByZXByZXNlbnRp bmcgdGhlIHJlc291cmNlIG93bmVyJ3MgYXV0aG9yaXphdGlvbiwgZXhwcmVzc2VkIHVzaW5nCiAg ICAgICAgb25lIG9mIGZvdXIgZ3JhbnQgdHlwZXMgZGVmaW5lZCBpbiB0aGlzIHNwZWNpZmljYXRp b24gb3IgdXNpbmcKICAgICAgICBhbiBleHRlbnNpb24gZ3JhbnQgdHlwZS4gIFRoZSBhdXRob3Jp emF0aW9uIGdyYW50IHR5cGUgZGVwZW5kcwogICAgICAgIG9uIHRoZSBtZXRob2QgdXNlZCBieSB0 aGUgY2xpZW50IHRvIHJlcXVlc3QgYXV0aG9yaXphdGlvbiBhbmQKICAgICAgICB0aGUgdHlwZXMg c3VwcG9ydGVkIGJ5IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlci4KICAgKEMpICBUaGUgY2xpZW50 IHJlcXVlc3RzIGFuIGFjY2VzcyB0b2tlbiBieSBhdXRoZW50aWNhdGluZyB3aXRoIHRoZQogICAg ICAgIGF1dGhvcml6YXRpb24gc2VydmVyIGFuZCBwcmVzZW50aW5nIHRoZSBhdXRob3JpemF0aW9u IGdyYW50LgogICAoRCkgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBhdXRoZW50aWNhdGVzIHRo ZSBjbGllbnQgYW5kIHZhbGlkYXRlcwogICAgICAgIHRoZSBhdXRob3JpemF0aW9uIGdyYW50LCBh bmQgaWYgdmFsaWQgaXNzdWVzIGFuIGFjY2VzcyB0b2tlbi4KICAgKEUpICBUaGUgY2xpZW50IHJl cXVlc3RzIHRoZSBwcm90ZWN0ZWQgcmVzb3VyY2UgZnJvbSB0aGUgcmVzb3VyY2UKICAgICAgICBz ZXJ2ZXIgYW5kIGF1dGhlbnRpY2F0ZXMgYnkgcHJlc2VudGluZyB0aGUgYWNjZXNzIHRva2VuLgog ICAoRikgIFRoZSByZXNvdXJjZSBzZXJ2ZXIgdmFsaWRhdGVzIHRoZSBhY2Nlc3MgdG9rZW4sIGFu ZCBpZiB2YWxpZCwKICAgICAgICBzZXJ2ZXMgdGhlIHJlcXVlc3QuCgogICBUaGUgcHJlZmVycmVk IG1ldGhvZCBmb3IgdGhlIGNsaWVudCB0byBvYnRhaW4gYW4gYXV0aG9yaXphdGlvbiBncmFudAog ICBmcm9tIHRoZSByZXNvdXJjZSBvd25lciAoZGVwaWN0ZWQgaW4gc3RlcHMgKEEpIGFuZCAoQikp IGlzIHRvIHVzZSB0aGUKCgoKSGFtbWVyLCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBEZWNlbWJl ciA0LCAyMDEyICAgICAgICAgICAgICAgIFtQYWdlIDddCgwKSW50ZXJuZXQtRHJhZnQgICAgICAg ICAgICAgICAgICBPQXV0aCAyLjAgICAgICAgICAgICAgICAgICAgICAgSnVuZSAyMDEyCgoKICAg YXV0aG9yaXphdGlvbiBzZXJ2ZXIgYXMgYW4gaW50ZXJtZWRpYXJ5IHdoaWNoIGlzIGlsbHVzdHJh dGVkIGluCiAgIEZpZ3VyZSAzLgoKMS4zLiAgQXV0aG9yaXphdGlvbiBHcmFudAoKICAgQW4gYXV0 aG9yaXphdGlvbiBncmFudCBpcyBhIGNyZWRlbnRpYWwgcmVwcmVzZW50aW5nIHRoZSByZXNvdXJj ZQogICBvd25lcidzIGF1dGhvcml6YXRpb24gKHRvIGFjY2VzcyBpdHMgcHJvdGVjdGVkIHJlc291 cmNlcykgdXNlZCBieSB0aGUKICAgY2xpZW50IHRvIG9idGFpbiBhbiBhY2Nlc3MgdG9rZW4uICBU aGlzIHNwZWNpZmljYXRpb24gZGVmaW5lcyBmb3VyCiAgIGdyYW50IHR5cGVzOiBhdXRob3JpemF0 aW9uIGNvZGUsIGltcGxpY2l0LCByZXNvdXJjZSBvd25lciBwYXNzd29yZAogICBjcmVkZW50aWFs cywgYW5kIGNsaWVudCBjcmVkZW50aWFscywgYXMgd2VsbCBhcyBhbiBleHRlbnNpYmlsaXR5CiAg IG1lY2hhbmlzbSBmb3IgZGVmaW5pbmcgYWRkaXRpb25hbCB0eXBlcy4KCjEuMy4xLiAgQXV0aG9y aXphdGlvbiBDb2RlCgogICBUaGUgYXV0aG9yaXphdGlvbiBjb2RlIGlzIG9idGFpbmVkIGJ5IHVz aW5nIGFuIGF1dGhvcml6YXRpb24gc2VydmVyCiAgIGFzIGFuIGludGVybWVkaWFyeSBiZXR3ZWVu IHRoZSBjbGllbnQgYW5kIHJlc291cmNlIG93bmVyLiAgSW5zdGVhZCBvZgogICByZXF1ZXN0aW5n IGF1dGhvcml6YXRpb24gZGlyZWN0bHkgZnJvbSB0aGUgcmVzb3VyY2Ugb3duZXIsIHRoZSBjbGll bnQKICAgZGlyZWN0cyB0aGUgcmVzb3VyY2Ugb3duZXIgdG8gYW4gYXV0aG9yaXphdGlvbiBzZXJ2 ZXIgKHZpYSBpdHMgdXNlci0KICAgYWdlbnQgYXMgZGVmaW5lZCBpbiBbUkZDMjYxNl0pLCB3aGlj aCBpbiB0dXJuIGRpcmVjdHMgdGhlIHJlc291cmNlCiAgIG93bmVyIGJhY2sgdG8gdGhlIGNsaWVu dCB3aXRoIHRoZSBhdXRob3JpemF0aW9uIGNvZGUuCgogICBCZWZvcmUgZGlyZWN0aW5nIHRoZSBy ZXNvdXJjZSBvd25lciBiYWNrIHRvIHRoZSBjbGllbnQgd2l0aCB0aGUKICAgYXV0aG9yaXphdGlv biBjb2RlLCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYXV0aGVudGljYXRlcyB0aGUKICAgcmVz b3VyY2Ugb3duZXIgYW5kIG9idGFpbnMgYXV0aG9yaXphdGlvbi4gIEJlY2F1c2UgdGhlIHJlc291 cmNlIG93bmVyCiAgIG9ubHkgYXV0aGVudGljYXRlcyB3aXRoIHRoZSBhdXRob3JpemF0aW9uIHNl cnZlciwgdGhlIHJlc291cmNlCiAgIG93bmVyJ3MgY3JlZGVudGlhbHMgYXJlIG5ldmVyIHNoYXJl ZCB3aXRoIHRoZSBjbGllbnQuCgogICBUaGUgYXV0aG9yaXphdGlvbiBjb2RlIHByb3ZpZGVzIGEg ZmV3IGltcG9ydGFudCBzZWN1cml0eSBiZW5lZml0cwogICBzdWNoIGFzIHRoZSBhYmlsaXR5IHRv IGF1dGhlbnRpY2F0ZSB0aGUgY2xpZW50LCBhbmQgdGhlIHRyYW5zbWlzc2lvbgogICBvZiB0aGUg YWNjZXNzIHRva2VuIGRpcmVjdGx5IHRvIHRoZSBjbGllbnQgd2l0aG91dCBwYXNzaW5nIGl0IHRo cm91Z2gKICAgdGhlIHJlc291cmNlIG93bmVyJ3MgdXNlci1hZ2VudCwgcG90ZW50aWFsbHkgZXhw b3NpbmcgaXQgdG8gb3RoZXJzLAogICBpbmNsdWRpbmcgdGhlIHJlc291cmNlIG93bmVyLgoKMS4z LjIuICBJbXBsaWNpdAoKICAgVGhlIGltcGxpY2l0IGdyYW50IGlzIGEgc2ltcGxpZmllZCBhdXRo b3JpemF0aW9uIGNvZGUgZmxvdyBvcHRpbWl6ZWQKICAgZm9yIGNsaWVudHMgaW1wbGVtZW50ZWQg aW4gYSBicm93c2VyIHVzaW5nIGEgc2NyaXB0aW5nIGxhbmd1YWdlIHN1Y2gKICAgYXMgSmF2YVNj cmlwdC4gIEluIHRoZSBpbXBsaWNpdCBmbG93LCBpbnN0ZWFkIG9mIGlzc3VpbmcgdGhlIGNsaWVu dAogICBhbiBhdXRob3JpemF0aW9uIGNvZGUsIHRoZSBjbGllbnQgaXMgaXNzdWVkIGFuIGFjY2Vz cyB0b2tlbiBkaXJlY3RseQogICAoYXMgdGhlIHJlc3VsdCBvZiB0aGUgcmVzb3VyY2Ugb3duZXIg YXV0aG9yaXphdGlvbikuICBUaGUgZ3JhbnQgdHlwZQogICBpcyBpbXBsaWNpdCBhcyBubyBpbnRl cm1lZGlhdGUgY3JlZGVudGlhbHMgKHN1Y2ggYXMgYW4gYXV0aG9yaXphdGlvbgogICBjb2RlKSBh cmUgaXNzdWVkIChhbmQgbGF0ZXIgdXNlZCB0byBvYnRhaW4gYW4gYWNjZXNzIHRva2VuKS4KCiAg IFdoZW4gaXNzdWluZyBhbiBhY2Nlc3MgdG9rZW4gZHVyaW5nIHRoZSBpbXBsaWNpdCBncmFudCBm bG93LCB0aGUKICAgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgZG9lcyBub3QgYXV0aGVudGljYXRlIHRo ZSBjbGllbnQuICBJbiBzb21lCiAgIGNhc2VzLCB0aGUgY2xpZW50IGlkZW50aXR5IGNhbiBiZSB2 ZXJpZmllZCB2aWEgdGhlIHJlZGlyZWN0aW9uIFVSSQogICB1c2VkIHRvIGRlbGl2ZXIgdGhlIGFj Y2VzcyB0b2tlbiB0byB0aGUgY2xpZW50LiAgVGhlIGFjY2VzcyB0b2tlbiBtYXkKICAgYmUgZXhw b3NlZCB0byB0aGUgcmVzb3VyY2Ugb3duZXIgb3Igb3RoZXIgYXBwbGljYXRpb25zIHdpdGggYWNj ZXNzIHRvCgoKCkhhbW1lciwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgRGVjZW1iZXIgNCwgMjAx MiAgICAgICAgICAgICAgICBbUGFnZSA4XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAg ICAgT0F1dGggMi4wICAgICAgICAgICAgICAgICAgICAgIEp1bmUgMjAxMgoKCiAgIHRoZSByZXNv dXJjZSBvd25lcidzIHVzZXItYWdlbnQuCgogICBJbXBsaWNpdCBncmFudHMgaW1wcm92ZSB0aGUg cmVzcG9uc2l2ZW5lc3MgYW5kIGVmZmljaWVuY3kgb2Ygc29tZQogICBjbGllbnRzIChzdWNoIGFz IGEgY2xpZW50IGltcGxlbWVudGVkIGFzIGFuIGluLWJyb3dzZXIgYXBwbGljYXRpb24pCiAgIHNp bmNlIGl0IHJlZHVjZXMgdGhlIG51bWJlciBvZiByb3VuZCB0cmlwcyByZXF1aXJlZCB0byBvYnRh aW4gYW4KICAgYWNjZXNzIHRva2VuLiAgSG93ZXZlciwgdGhpcyBjb252ZW5pZW5jZSBzaG91bGQg YmUgd2VpZ2hlZCBhZ2FpbnN0CiAgIHRoZSBzZWN1cml0eSBpbXBsaWNhdGlvbnMgb2YgdXNpbmcg aW1wbGljaXQgZ3JhbnRzLCBlc3BlY2lhbGx5IHdoZW4KICAgdGhlIGF1dGhvcml6YXRpb24gY29k ZSBncmFudCB0eXBlIGlzIGF2YWlsYWJsZS4KCjEuMy4zLiAgUmVzb3VyY2UgT3duZXIgUGFzc3dv cmQgQ3JlZGVudGlhbHMKCiAgIFRoZSByZXNvdXJjZSBvd25lciBwYXNzd29yZCBjcmVkZW50aWFs cyAoaS5lLiB1c2VybmFtZSBhbmQgcGFzc3dvcmQpCiAgIGNhbiBiZSB1c2VkIGRpcmVjdGx5IGFz IGFuIGF1dGhvcml6YXRpb24gZ3JhbnQgdG8gb2J0YWluIGFuIGFjY2VzcwogICB0b2tlbi4gIFRo ZSBjcmVkZW50aWFscyBzaG91bGQgb25seSBiZSB1c2VkIHdoZW4gdGhlcmUgaXMgYSBoaWdoCiAg IGRlZ3JlZSBvZiB0cnVzdCBiZXR3ZWVuIHRoZSByZXNvdXJjZSBvd25lciBhbmQgdGhlIGNsaWVu dCAoZS5nLiB0aGUKICAgY2xpZW50IGlzIHBhcnQgb2YgdGhlIGRldmljZSBvcGVyYXRpbmcgc3lz dGVtIG9yIGEgaGlnaGx5IHByaXZpbGVnZWQKICAgYXBwbGljYXRpb24pLCBhbmQgd2hlbiBvdGhl ciBhdXRob3JpemF0aW9uIGdyYW50IHR5cGVzIGFyZSBub3QKICAgYXZhaWxhYmxlIChzdWNoIGFz IGFuIGF1dGhvcml6YXRpb24gY29kZSkuCgogICBFdmVuIHRob3VnaCB0aGlzIGdyYW50IHR5cGUg cmVxdWlyZXMgZGlyZWN0IGNsaWVudCBhY2Nlc3MgdG8gdGhlCiAgIHJlc291cmNlIG93bmVyIGNy ZWRlbnRpYWxzLCB0aGUgcmVzb3VyY2Ugb3duZXIgY3JlZGVudGlhbHMgYXJlIHVzZWQKICAgZm9y IGEgc2luZ2xlIHJlcXVlc3QgYW5kIGFyZSBleGNoYW5nZWQgZm9yIGFuIGFjY2VzcyB0b2tlbi4g IFRoaXMKICAgZ3JhbnQgdHlwZSBjYW4gZWxpbWluYXRlIHRoZSBuZWVkIGZvciB0aGUgY2xpZW50 IHRvIHN0b3JlIHRoZQogICByZXNvdXJjZSBvd25lciBjcmVkZW50aWFscyBmb3IgZnV0dXJlIHVz ZSwgYnkgZXhjaGFuZ2luZyB0aGUKICAgY3JlZGVudGlhbHMgd2l0aCBhIGxvbmctbGl2ZWQgYWNj ZXNzIHRva2VuIG9yIHJlZnJlc2ggdG9rZW4uCgoxLjMuNC4gIENsaWVudCBDcmVkZW50aWFscwoK ICAgVGhlIGNsaWVudCBjcmVkZW50aWFscyAob3Igb3RoZXIgZm9ybXMgb2YgY2xpZW50IGF1dGhl bnRpY2F0aW9uKSBjYW4KICAgYmUgdXNlZCBhcyBhbiBhdXRob3JpemF0aW9uIGdyYW50IHdoZW4g dGhlIGF1dGhvcml6YXRpb24gc2NvcGUgaXMKICAgbGltaXRlZCB0byB0aGUgcHJvdGVjdGVkIHJl c291cmNlcyB1bmRlciB0aGUgY29udHJvbCBvZiB0aGUgY2xpZW50LAogICBvciB0byBwcm90ZWN0 ZWQgcmVzb3VyY2VzIHByZXZpb3VzbHkgYXJyYW5nZWQgd2l0aCB0aGUgYXV0aG9yaXphdGlvbgog ICBzZXJ2ZXIuICBDbGllbnQgY3JlZGVudGlhbHMgYXJlIHVzZWQgYXMgYW4gYXV0aG9yaXphdGlv biBncmFudAogICB0eXBpY2FsbHkgd2hlbiB0aGUgY2xpZW50IGlzIGFjdGluZyBvbiBpdHMgb3du IGJlaGFsZiAodGhlIGNsaWVudCBpcwogICBhbHNvIHRoZSByZXNvdXJjZSBvd25lciksIG9yIGlz IHJlcXVlc3RpbmcgYWNjZXNzIHRvIHByb3RlY3RlZAogICByZXNvdXJjZXMgYmFzZWQgb24gYW4g YXV0aG9yaXphdGlvbiBwcmV2aW91c2x5IGFycmFuZ2VkIHdpdGggdGhlCiAgIGF1dGhvcml6YXRp b24gc2VydmVyLgoKMS40LiAgQWNjZXNzIFRva2VuCgogICBBY2Nlc3MgdG9rZW5zIGFyZSBjcmVk ZW50aWFscyB1c2VkIHRvIGFjY2VzcyBwcm90ZWN0ZWQgcmVzb3VyY2VzLiAgQW4KICAgYWNjZXNz IHRva2VuIGlzIGEgc3RyaW5nIHJlcHJlc2VudGluZyBhbiBhdXRob3JpemF0aW9uIGlzc3VlZCB0 byB0aGUKICAgY2xpZW50LiAgVGhlIHN0cmluZyBpcyB1c3VhbGx5IG9wYXF1ZSB0byB0aGUgY2xp ZW50LiAgVG9rZW5zCiAgIHJlcHJlc2VudCBzcGVjaWZpYyBzY29wZXMgYW5kIGR1cmF0aW9ucyBv ZiBhY2Nlc3MsIGdyYW50ZWQgYnkgdGhlCiAgIHJlc291cmNlIG93bmVyLCBhbmQgZW5mb3JjZWQg YnkgdGhlIHJlc291cmNlIHNlcnZlciBhbmQgYXV0aG9yaXphdGlvbgogICBzZXJ2ZXIuCgogICBU aGUgdG9rZW4gbWF5IGRlbm90ZSBhbiBpZGVudGlmaWVyIHVzZWQgdG8gcmV0cmlldmUgdGhlIGF1 dGhvcml6YXRpb24KCgoKSGFtbWVyLCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBEZWNlbWJlciA0 LCAyMDEyICAgICAgICAgICAgICAgIFtQYWdlIDldCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAg ICAgICAgICBPQXV0aCAyLjAgICAgICAgICAgICAgICAgICAgICAgSnVuZSAyMDEyCgoKICAgaW5m b3JtYXRpb24sIG9yIHNlbGYtY29udGFpbiB0aGUgYXV0aG9yaXphdGlvbiBpbmZvcm1hdGlvbiBp biBhCiAgIHZlcmlmaWFibGUgbWFubmVyIChpLmUuIGEgdG9rZW4gc3RyaW5nIGNvbnNpc3Rpbmcg b2Ygc29tZSBkYXRhIGFuZCBhCiAgIHNpZ25hdHVyZSkuICBBZGRpdGlvbmFsIGF1dGhlbnRpY2F0 aW9uIGNyZWRlbnRpYWxzLCB3aGljaCBhcmUgYmV5b25kCiAgIHRoZSBzY29wZSBvZiB0aGlzIHNw ZWNpZmljYXRpb24sIG1heSBiZSByZXF1aXJlZCBpbiBvcmRlciBmb3IgdGhlCiAgIGNsaWVudCB0 byB1c2UgYSB0b2tlbi4KCiAgIFRoZSBhY2Nlc3MgdG9rZW4gcHJvdmlkZXMgYW4gYWJzdHJhY3Rp b24gbGF5ZXIsIHJlcGxhY2luZyBkaWZmZXJlbnQKICAgYXV0aG9yaXphdGlvbiBjb25zdHJ1Y3Rz IChlLmcuIHVzZXJuYW1lIGFuZCBwYXNzd29yZCkgd2l0aCBhIHNpbmdsZQogICB0b2tlbiB1bmRl cnN0b29kIGJ5IHRoZSByZXNvdXJjZSBzZXJ2ZXIuICBUaGlzIGFic3RyYWN0aW9uIGVuYWJsZXMK ICAgaXNzdWluZyBhY2Nlc3MgdG9rZW5zIG1vcmUgcmVzdHJpY3RpdmUgdGhhbiB0aGUgYXV0aG9y aXphdGlvbiBncmFudAogICB1c2VkIHRvIG9idGFpbiB0aGVtLCBhcyB3ZWxsIGFzIHJlbW92aW5n IHRoZSByZXNvdXJjZSBzZXJ2ZXIncyBuZWVkCiAgIHRvIHVuZGVyc3RhbmQgYSB3aWRlIHJhbmdl IG9mIGF1dGhlbnRpY2F0aW9uIG1ldGhvZHMuCgogICBBY2Nlc3MgdG9rZW5zIGNhbiBoYXZlIGRp ZmZlcmVudCBmb3JtYXRzLCBzdHJ1Y3R1cmVzLCBhbmQgbWV0aG9kcyBvZgogICB1dGlsaXphdGlv biAoZS5nLiBjcnlwdG9ncmFwaGljIHByb3BlcnRpZXMpIGJhc2VkIG9uIHRoZSByZXNvdXJjZQog ICBzZXJ2ZXIgc2VjdXJpdHkgcmVxdWlyZW1lbnRzLiAgQWNjZXNzIHRva2VuIGF0dHJpYnV0ZXMg YW5kIHRoZQogICBtZXRob2RzIHVzZWQgdG8gYWNjZXNzIHByb3RlY3RlZCByZXNvdXJjZXMgYXJl IGJleW9uZCB0aGUgc2NvcGUgb2YKICAgdGhpcyBzcGVjaWZpY2F0aW9uIGFuZCBhcmUgZGVmaW5l ZCBieSBjb21wYW5pb24gc3BlY2lmaWNhdGlvbnMuCgoxLjUuICBSZWZyZXNoIFRva2VuCgogICBS ZWZyZXNoIHRva2VucyBhcmUgY3JlZGVudGlhbHMgdXNlZCB0byBvYnRhaW4gYWNjZXNzIHRva2Vu cy4gIFJlZnJlc2gKICAgdG9rZW5zIGFyZSBpc3N1ZWQgdG8gdGhlIGNsaWVudCBieSB0aGUgYXV0 aG9yaXphdGlvbiBzZXJ2ZXIgYW5kIGFyZQogICB1c2VkIHRvIG9idGFpbiBhIG5ldyBhY2Nlc3Mg dG9rZW4gd2hlbiB0aGUgY3VycmVudCBhY2Nlc3MgdG9rZW4KICAgYmVjb21lcyBpbnZhbGlkIG9y IGV4cGlyZXMsIG9yIHRvIG9idGFpbiBhZGRpdGlvbmFsIGFjY2VzcyB0b2tlbnMKICAgd2l0aCBp ZGVudGljYWwgb3IgbmFycm93ZXIgc2NvcGUgKGFjY2VzcyB0b2tlbnMgbWF5IGhhdmUgYSBzaG9y dGVyCiAgIGxpZmV0aW1lIGFuZCBmZXdlciBwZXJtaXNzaW9ucyB0aGFuIGF1dGhvcml6ZWQgYnkg dGhlIHJlc291cmNlCiAgIG93bmVyKS4gIElzc3VpbmcgYSByZWZyZXNoIHRva2VuIGlzIG9wdGlv bmFsIGF0IHRoZSBkaXNjcmV0aW9uIG9mIHRoZQogICBhdXRob3JpemF0aW9uIHNlcnZlci4gIElm IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBpc3N1ZXMgYSByZWZyZXNoCiAgIHRva2VuLCBpdCBp cyBpbmNsdWRlZCB3aGVuIGlzc3VpbmcgYW4gYWNjZXNzIHRva2VuIChpLmUuIHN0ZXAgKEQpIGlu CiAgIEZpZ3VyZSAxKS4KCiAgIEEgcmVmcmVzaCB0b2tlbiBpcyBhIHN0cmluZyByZXByZXNlbnRp bmcgdGhlIGF1dGhvcml6YXRpb24gZ3JhbnRlZCB0bwogICB0aGUgY2xpZW50IGJ5IHRoZSByZXNv dXJjZSBvd25lci4gIFRoZSBzdHJpbmcgaXMgdXN1YWxseSBvcGFxdWUgdG8KICAgdGhlIGNsaWVu dC4gIFRoZSB0b2tlbiBkZW5vdGVzIGFuIGlkZW50aWZpZXIgdXNlZCB0byByZXRyaWV2ZSB0aGUK ICAgYXV0aG9yaXphdGlvbiBpbmZvcm1hdGlvbi4gIFVubGlrZSBhY2Nlc3MgdG9rZW5zLCByZWZy ZXNoIHRva2VucyBhcmUKICAgaW50ZW5kZWQgZm9yIHVzZSBvbmx5IHdpdGggYXV0aG9yaXphdGlv biBzZXJ2ZXJzIGFuZCBhcmUgbmV2ZXIgc2VudAogICB0byByZXNvdXJjZSBzZXJ2ZXJzLgoKCgoK CgoKCgoKCgoKSGFtbWVyLCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBEZWNlbWJlciA0LCAyMDEy ICAgICAgICAgICAgICAgW1BhZ2UgMTBdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAg ICBPQXV0aCAyLjAgICAgICAgICAgICAgICAgICAgICAgSnVuZSAyMDEyCgoKICArLS0tLS0tLS0r ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0t LS0rCiAgfCAgICAgICAgfC0tKEEpLS0tLS0tLSBBdXRob3JpemF0aW9uIEdyYW50IC0tLS0tLS0t LT58ICAgICAgICAgICAgICAgfAogIHwgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgIHwKICB8ICAgICAgICB8PC0oQiktLS0t LS0tLS0tLSBBY2Nlc3MgVG9rZW4gLS0tLS0tLS0tLS0tLXwgICAgICAgICAgICAgICB8CiAgfCAg ICAgICAgfCAgICAgICAgICAgICAgICYgUmVmcmVzaCBUb2tlbiAgICAgICAgICAgICB8ICAgICAg ICAgICAgICAgfAogIHwgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfCAgICAgICAgICAgICAgIHwKICB8ICAgICAgICB8ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICstLS0tLS0tLS0tKyAgIHwgICAgICAgICAgICAgICB8CiAgfCAgICAgICAgfC0t KEMpLS0tLSBBY2Nlc3MgVG9rZW4gLS0tLT58ICAgICAgICAgIHwgICB8ICAgICAgICAgICAgICAg fAogIHwgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICB8ICAg fCAgICAgICAgICAgICAgIHwKICB8ICAgICAgICB8PC0oRCktIFByb3RlY3RlZCBSZXNvdXJjZSAt LXwgUmVzb3VyY2UgfCAgIHwgQXV0aG9yaXphdGlvbiB8CiAgfCBDbGllbnQgfCAgICAgICAgICAg ICAgICAgICAgICAgICAgICB8ICBTZXJ2ZXIgIHwgICB8ICAgICBTZXJ2ZXIgICAgfAogIHwgICAg ICAgIHwtLShFKS0tLS0gQWNjZXNzIFRva2VuIC0tLS0+fCAgICAgICAgICB8ICAgfCAgICAgICAg ICAgICAgIHwKICB8ICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAg ICAgfCAgIHwgICAgICAgICAgICAgICB8CiAgfCAgICAgICAgfDwtKEYpLSBJbnZhbGlkIFRva2Vu IEVycm9yIC18ICAgICAgICAgIHwgICB8ICAgICAgICAgICAgICAgfAogIHwgICAgICAgIHwgICAg ICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0rICAgfCAgICAgICAgICAgICAgIHwK ICB8ICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwg ICAgICAgICAgICAgICB8CiAgfCAgICAgICAgfC0tKEcpLS0tLS0tLS0tLS0gUmVmcmVzaCBUb2tl biAtLS0tLS0tLS0tLT58ICAgICAgICAgICAgICAgfAogIHwgICAgICAgIHwgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgIHwKICB8ICAgICAg ICB8PC0oSCktLS0tLS0tLS0tLSBBY2Nlc3MgVG9rZW4gLS0tLS0tLS0tLS0tLXwgICAgICAgICAg ICAgICB8CiAgKy0tLS0tLS0tKyAgICAgICAgICAgJiBPcHRpb25hbCBSZWZyZXNoIFRva2VuICAg ICAgICArLS0tLS0tLS0tLS0tLS0tKwoKCiAgICAgICAgICAgICAgIEZpZ3VyZSAyOiBSZWZyZXNo aW5nIGFuIEV4cGlyZWQgQWNjZXNzIFRva2VuCgogICBUaGUgZmxvdyBpbGx1c3RyYXRlZCBpbiBG aWd1cmUgMiBpbmNsdWRlcyB0aGUgZm9sbG93aW5nIHN0ZXBzOgoKICAgKEEpICBUaGUgY2xpZW50 IHJlcXVlc3RzIGFuIGFjY2VzcyB0b2tlbiBieSBhdXRoZW50aWNhdGluZyB3aXRoIHRoZQogICAg ICAgIGF1dGhvcml6YXRpb24gc2VydmVyLCBhbmQgcHJlc2VudGluZyBhbiBhdXRob3JpemF0aW9u IGdyYW50LgogICAoQikgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBhdXRoZW50aWNhdGVzIHRo ZSBjbGllbnQgYW5kIHZhbGlkYXRlcwogICAgICAgIHRoZSBhdXRob3JpemF0aW9uIGdyYW50LCBh bmQgaWYgdmFsaWQgaXNzdWVzIGFuIGFjY2VzcyB0b2tlbiBhbmQKICAgICAgICBhIHJlZnJlc2gg dG9rZW4uCiAgIChDKSAgVGhlIGNsaWVudCBtYWtlcyBhIHByb3RlY3RlZCByZXNvdXJjZSByZXF1 ZXN0IHRvIHRoZSByZXNvdXJjZQogICAgICAgIHNlcnZlciBieSBwcmVzZW50aW5nIHRoZSBhY2Nl c3MgdG9rZW4uCiAgIChEKSAgVGhlIHJlc291cmNlIHNlcnZlciB2YWxpZGF0ZXMgdGhlIGFjY2Vz cyB0b2tlbiwgYW5kIGlmIHZhbGlkLAogICAgICAgIHNlcnZlcyB0aGUgcmVxdWVzdC4KICAgKEUp ICBTdGVwcyAoQykgYW5kIChEKSByZXBlYXQgdW50aWwgdGhlIGFjY2VzcyB0b2tlbiBleHBpcmVz LiAgSWYgdGhlCiAgICAgICAgY2xpZW50IGtub3dzIHRoZSBhY2Nlc3MgdG9rZW4gZXhwaXJlZCwg aXQgc2tpcHMgdG8gc3RlcCAoRyksCiAgICAgICAgb3RoZXJ3aXNlIGl0IG1ha2VzIGFub3RoZXIg cHJvdGVjdGVkIHJlc291cmNlIHJlcXVlc3QuCiAgIChGKSAgU2luY2UgdGhlIGFjY2VzcyB0b2tl biBpcyBpbnZhbGlkLCB0aGUgcmVzb3VyY2Ugc2VydmVyIHJldHVybnMKICAgICAgICBhbiBpbnZh bGlkIHRva2VuIGVycm9yLgogICAoRykgIFRoZSBjbGllbnQgcmVxdWVzdHMgYSBuZXcgYWNjZXNz IHRva2VuIGJ5IGF1dGhlbnRpY2F0aW5nIHdpdGgKICAgICAgICB0aGUgYXV0aG9yaXphdGlvbiBz ZXJ2ZXIgYW5kIHByZXNlbnRpbmcgdGhlIHJlZnJlc2ggdG9rZW4uICBUaGUKICAgICAgICBjbGll bnQgYXV0aGVudGljYXRpb24gcmVxdWlyZW1lbnRzIGFyZSBiYXNlZCBvbiB0aGUgY2xpZW50IHR5 cGUKICAgICAgICBhbmQgb24gdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHBvbGljaWVzLgoKCgoK CgoKSGFtbWVyLCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBEZWNlbWJlciA0LCAyMDEyICAgICAg ICAgICAgICAgW1BhZ2UgMTFdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICBPQXV0 aCAyLjAgICAgICAgICAgICAgICAgICAgICAgSnVuZSAyMDEyCgoKICAgKEgpICBUaGUgYXV0aG9y aXphdGlvbiBzZXJ2ZXIgYXV0aGVudGljYXRlcyB0aGUgY2xpZW50IGFuZCB2YWxpZGF0ZXMKICAg ICAgICB0aGUgcmVmcmVzaCB0b2tlbiwgYW5kIGlmIHZhbGlkIGlzc3VlcyBhIG5ldyBhY2Nlc3Mg dG9rZW4gKGFuZAogICAgICAgIG9wdGlvbmFsbHksIGEgbmV3IHJlZnJlc2ggdG9rZW4pLgoKICAg U3RlcHMgQywgRCwgRSwgYW5kIEYgYXJlIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgc3BlY2lm aWNhdGlvbiBhcwogICBkZXNjcmliZWQgaW4gU2VjdGlvbiA3LgoKMS42LiAgVExTIFZlcnNpb24K CiAgIFdoZW5ldmVyIFRMUyBpcyB1c2VkIGJ5IHRoaXMgc3BlY2lmaWNhdGlvbiwgdGhlIGFwcHJv cHJpYXRlIHZlcnNpb24KICAgKG9yIHZlcnNpb25zKSBvZiBUTFMgd2lsbCB2YXJ5IG92ZXIgdGlt ZSwgYmFzZWQgb24gdGhlIHdpZGVzcHJlYWQKICAgZGVwbG95bWVudCBhbmQga25vd24gc2VjdXJp dHkgdnVsbmVyYWJpbGl0aWVzLiAgQXQgdGhlIHRpbWUgb2YgdGhpcwogICB3cml0aW5nLCBUTFMg dmVyc2lvbiAxLjIgW1JGQzUyNDZdIGlzIHRoZSBtb3N0IHJlY2VudCB2ZXJzaW9uLCBidXQKICAg aGFzIGEgdmVyeSBsaW1pdGVkIGRlcGxveW1lbnQgYmFzZSBhbmQgbWlnaHQgbm90IGJlIHJlYWRp bHkgYXZhaWxhYmxlCiAgIGZvciBpbXBsZW1lbnRhdGlvbi4gIFRMUyB2ZXJzaW9uIDEuMCBbUkZD MjI0Nl0gaXMgdGhlIG1vc3Qgd2lkZWx5CiAgIGRlcGxveWVkIHZlcnNpb24sIGFuZCB3aWxsIHBy b3ZpZGUgdGhlIGJyb2FkZXN0IGludGVyb3BlcmFiaWxpdHkuCgogICBJbXBsZW1lbnRhdGlvbnMg TUFZIGFsc28gc3VwcG9ydCBhZGRpdGlvbmFsIHRyYW5zcG9ydC1sYXllciBzZWN1cml0eQogICBt ZWNoYW5pc21zIHRoYXQgbWVldCB0aGVpciBzZWN1cml0eSByZXF1aXJlbWVudHMuCgoxLjcuICBI VFRQIFJlZGlyZWN0aW9ucwoKICAgVGhpcyBzcGVjaWZpY2F0aW9uIG1ha2VzIGV4dGVuc2l2ZSB1 c2Ugb2YgSFRUUCByZWRpcmVjdGlvbnMsIGluIHdoaWNoCiAgIHRoZSBjbGllbnQgb3IgdGhlIGF1 dGhvcml6YXRpb24gc2VydmVyIGRpcmVjdCB0aGUgcmVzb3VyY2Ugb3duZXIncwogICB1c2VyLWFn ZW50IHRvIGFub3RoZXIgZGVzdGluYXRpb24uICBXaGlsZSB0aGUgZXhhbXBsZXMgaW4gdGhpcwog ICBzcGVjaWZpY2F0aW9uIHNob3cgdGhlIHVzZSBvZiB0aGUgSFRUUCAzMDIgc3RhdHVzIGNvZGUs IGFueSBvdGhlcgogICBtZXRob2QgYXZhaWxhYmxlIHZpYSB0aGUgdXNlci1hZ2VudCB0byBhY2Nv bXBsaXNoIHRoaXMgcmVkaXJlY3Rpb24gaXMKICAgYWxsb3dlZCBhbmQgaXMgY29uc2lkZXJlZCB0 byBiZSBhbiBpbXBsZW1lbnRhdGlvbiBkZXRhaWwuCgoxLjguICBJbnRlcm9wZXJhYmlsaXR5Cgog ICBPQXV0aCAyLjAgcHJvdmlkZXMgYSByaWNoIGF1dGhvcml6YXRpb24gZnJhbWV3b3JrIHdpdGgg d2VsbC1kZWZpbmVkCiAgIHNlY3VyaXR5IHByb3BlcnRpZXMuICBIb3dldmVyLCBhcyBhIHJpY2gg YW5kIGhpZ2hseSBleHRlbnNpYmxlCiAgIGZyYW1ld29yayB3aXRoIG1hbnkgb3B0aW9uYWwgY29t cG9uZW50cywgb24gaXRzIG93biwgdGhpcwogICBzcGVjaWZpY2F0aW9uIGlzIGxpa2VseSB0byBw cm9kdWNlIGEgd2lkZSByYW5nZSBvZiBub24taW50ZXJvcGVyYWJsZQogICBpbXBsZW1lbnRhdGlv bnMuCgogICBJbiBhZGRpdGlvbiwgdGhpcyBzcGVjaWZpY2F0aW9uIGxlYXZlcyBhIGZldyByZXF1 aXJlZCBjb21wb25lbnRzCiAgIHBhcnRpYWxseSBvciBmdWxseSB1bmRlZmluZWQgKGUuZy4gY2xp ZW50IHJlZ2lzdHJhdGlvbiwgYXV0aG9yaXphdGlvbgogICBzZXJ2ZXIgY2FwYWJpbGl0aWVzLCBl bmRwb2ludCBkaXNjb3ZlcnkpLiAgV2l0aG91dCB0aGVzZSBjb21wb25lbnRzLAogICBjbGllbnRz IG11c3QgYmUgbWFudWFsbHkgYW5kIHNwZWNpZmljYWxseSBjb25maWd1cmVkIGFnYWluc3QgYQog ICBzcGVjaWZpYyBhdXRob3JpemF0aW9uIHNlcnZlciBhbmQgcmVzb3VyY2Ugc2VydmVyIGluIG9y ZGVyIHRvCiAgIGludGVyb3BlcmF0ZS4KCiAgIFRoaXMgZnJhbWV3b3JrIHdhcyBkZXNpZ25lZCB3 aXRoIHRoZSBjbGVhciBleHBlY3RhdGlvbiB0aGF0IGZ1dHVyZQogICB3b3JrIHdpbGwgZGVmaW5l IHByZXNjcmlwdGl2ZSBwcm9maWxlcyBhbmQgZXh0ZW5zaW9ucyBuZWNlc3NhcnkgdG8KICAgYWNo aWV2ZSBmdWxsIHdlYi1zY2FsZSBpbnRlcm9wZXJhYmlsaXR5LgoKCgoKSGFtbWVyLCBldCBhbC4g ICAgICAgICAgRXhwaXJlcyBEZWNlbWJlciA0LCAyMDEyICAgICAgICAgICAgICAgW1BhZ2UgMTJd CgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICBPQXV0aCAyLjAgICAgICAgICAgICAg ICAgICAgICAgSnVuZSAyMDEyCgoKMS45LiAgTm90YXRpb25hbCBDb252ZW50aW9ucwoKICAgVGhl IGtleSB3b3JkcyAiTVVTVCIsICJNVVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFM TCBOT1QiLAogICAiU0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAiTUFZIiwg YW5kICJPUFRJT05BTCIgaW4gdGhpcwogICBzcGVjaWZpY2F0aW9uIGFyZSB0byBiZSBpbnRlcnBy ZXRlZCBhcyBkZXNjcmliZWQgaW4gW1JGQzIxMTldLgoKICAgVGhpcyBzcGVjaWZpY2F0aW9uIHVz ZXMgdGhlIEF1Z21lbnRlZCBCYWNrdXMtTmF1ciBGb3JtIChBQk5GKQogICBub3RhdGlvbiBvZiBb UkZDNTIzNF0uICBBZGRpdGlvbmFsbHksIHRoZSBydWxlIFVSSS1SZWZlcmVuY2UgaXMKICAgaW5j bHVkZWQgZnJvbSBVbmlmb3JtIFJlc291cmNlIElkZW50aWZpZXIgKFVSSSkgW1JGQzM5ODZdLgoK ICAgQ2VydGFpbiBzZWN1cml0eS1yZWxhdGVkIHRlcm1zIGFyZSB0byBiZSB1bmRlcnN0b29kIGlu IHRoZSBzZW5zZQogICBkZWZpbmVkIGluIFtSRkM0OTQ5XS4gIFRoZXNlIHRlcm1zIGluY2x1ZGUs IGJ1dCBhcmUgbm90IGxpbWl0ZWQgdG8sCiAgICJhdHRhY2siLCAiYXV0aGVudGljYXRpb24iLCAi YXV0aG9yaXphdGlvbiIsICJjZXJ0aWZpY2F0ZSIsCiAgICJjb25maWRlbnRpYWxpdHkiLCAiY3Jl ZGVudGlhbCIsICJlbmNyeXB0aW9uIiwgImlkZW50aXR5IiwgInNpZ24iLAogICAic2lnbmF0dXJl IiwgInRydXN0IiwgInZhbGlkYXRlIiwgYW5kICJ2ZXJpZnkiLgoKICAgVW5sZXNzIG90aGVyd2lz ZSBub3RlZCwgYWxsIHRoZSBwcm90b2NvbCBwYXJhbWV0ZXIgbmFtZXMgYW5kIHZhbHVlcwogICBh cmUgY2FzZSBzZW5zaXRpdmUuCgoKMi4gIENsaWVudCBSZWdpc3RyYXRpb24KCiAgIEJlZm9yZSBp bml0aWF0aW5nIHRoZSBwcm90b2NvbCwgdGhlIGNsaWVudCByZWdpc3RlcnMgd2l0aCB0aGUKICAg YXV0aG9yaXphdGlvbiBzZXJ2ZXIuICBUaGUgbWVhbnMgdGhyb3VnaCB3aGljaCB0aGUgY2xpZW50 IHJlZ2lzdGVycwogICB3aXRoIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBhcmUgYmV5b25kIHRo ZSBzY29wZSBvZiB0aGlzCiAgIHNwZWNpZmljYXRpb24sIGJ1dCB0eXBpY2FsbHkgaW52b2x2ZSBl bmQtdXNlciBpbnRlcmFjdGlvbiB3aXRoIGFuCiAgIEhUTUwgcmVnaXN0cmF0aW9uIGZvcm0uCgog ICBDbGllbnQgcmVnaXN0cmF0aW9uIGRvZXMgbm90IHJlcXVpcmUgYSBkaXJlY3QgaW50ZXJhY3Rp b24gYmV0d2VlbiB0aGUKICAgY2xpZW50IGFuZCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIuICBX aGVuIHN1cHBvcnRlZCBieSB0aGUKICAgYXV0aG9yaXphdGlvbiBzZXJ2ZXIsIHJlZ2lzdHJhdGlv biBjYW4gcmVseSBvbiBvdGhlciBtZWFucyBmb3IKICAgZXN0YWJsaXNoaW5nIHRydXN0IGFuZCBv YnRhaW5pbmcgdGhlIHJlcXVpcmVkIGNsaWVudCBwcm9wZXJ0aWVzIChlLmcuCiAgIHJlZGlyZWN0 aW9uIFVSSSwgY2xpZW50IHR5cGUpLiAgRm9yIGV4YW1wbGUsIHJlZ2lzdHJhdGlvbiBjYW4gYmUK ICAgYWNjb21wbGlzaGVkIHVzaW5nIGEgc2VsZi1pc3N1ZWQgb3IgdGhpcmQtcGFydHktaXNzdWVk IGFzc2VydGlvbiwgb3IKICAgYnkgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHBlcmZvcm1pbmcg Y2xpZW50IGRpc2NvdmVyeSB1c2luZyBhCiAgIHRydXN0ZWQgY2hhbm5lbC4KCiAgIFdoZW4gcmVn aXN0ZXJpbmcgYSBjbGllbnQsIHRoZSBjbGllbnQgZGV2ZWxvcGVyIFNIQUxMOgoKICAgbyAgc3Bl Y2lmeSB0aGUgY2xpZW50IHR5cGUgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gMi4xLAogICBvICBw cm92aWRlIGl0cyBjbGllbnQgcmVkaXJlY3Rpb24gVVJJcyBhcyBkZXNjcmliZWQgaW4gU2VjdGlv biAzLjEuMiwKICAgICAgYW5kCiAgIG8gIGluY2x1ZGUgYW55IG90aGVyIGluZm9ybWF0aW9uIHJl cXVpcmVkIGJ5IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlcgogICAgICAoZS5nLiBhcHBsaWNhdGlv biBuYW1lLCB3ZWJzaXRlLCBkZXNjcmlwdGlvbiwgbG9nbyBpbWFnZSwgdGhlCiAgICAgIGFjY2Vw dGFuY2Ugb2YgbGVnYWwgdGVybXMpLgoKCgoKCgpIYW1tZXIsIGV0IGFsLiAgICAgICAgICBFeHBp cmVzIERlY2VtYmVyIDQsIDIwMTIgICAgICAgICAgICAgICBbUGFnZSAxM10KDApJbnRlcm5ldC1E cmFmdCAgICAgICAgICAgICAgICAgIE9BdXRoIDIuMCAgICAgICAgICAgICAgICAgICAgICBKdW5l IDIwMTIKCgoyLjEuICBDbGllbnQgVHlwZXMKCiAgIE9BdXRoIGRlZmluZXMgdHdvIGNsaWVudCB0 eXBlcywgYmFzZWQgb24gdGhlaXIgYWJpbGl0eSB0bwogICBhdXRoZW50aWNhdGUgc2VjdXJlbHkg d2l0aCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgKGkuZS4gYWJpbGl0eSB0bwogICBtYWludGFp biB0aGUgY29uZmlkZW50aWFsaXR5IG9mIHRoZWlyIGNsaWVudCBjcmVkZW50aWFscyk6CgogICBj b25maWRlbnRpYWwKICAgICAgQ2xpZW50cyBjYXBhYmxlIG9mIG1haW50YWluaW5nIHRoZSBjb25m aWRlbnRpYWxpdHkgb2YgdGhlaXIKICAgICAgY3JlZGVudGlhbHMgKGUuZy4gY2xpZW50IGltcGxl bWVudGVkIG9uIGEgc2VjdXJlIHNlcnZlciB3aXRoCiAgICAgIHJlc3RyaWN0ZWQgYWNjZXNzIHRv IHRoZSBjbGllbnQgY3JlZGVudGlhbHMpLCBvciBjYXBhYmxlIG9mIHNlY3VyZQogICAgICBjbGll bnQgYXV0aGVudGljYXRpb24gdXNpbmcgb3RoZXIgbWVhbnMuCiAgIHB1YmxpYwogICAgICBDbGll bnRzIGluY2FwYWJsZSBvZiBtYWludGFpbmluZyB0aGUgY29uZmlkZW50aWFsaXR5IG9mIHRoZWly CiAgICAgIGNyZWRlbnRpYWxzIChlLmcuIGNsaWVudHMgZXhlY3V0aW5nIG9uIHRoZSBkZXZpY2Ug dXNlZCBieSB0aGUKICAgICAgcmVzb3VyY2Ugb3duZXIgc3VjaCBhcyBhbiBpbnN0YWxsZWQgbmF0 aXZlIGFwcGxpY2F0aW9uIG9yIGEgd2ViCiAgICAgIGJyb3dzZXItYmFzZWQgYXBwbGljYXRpb24p LCBhbmQgaW5jYXBhYmxlIG9mIHNlY3VyZSBjbGllbnQKICAgICAgYXV0aGVudGljYXRpb24gdmlh IGFueSBvdGhlciBtZWFucy4KCiAgIFRoZSBjbGllbnQgdHlwZSBkZXNpZ25hdGlvbiBpcyBiYXNl ZCBvbiB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIncwogICBkZWZpbml0aW9uIG9mIHNlY3VyZSBh dXRoZW50aWNhdGlvbiBhbmQgaXRzIGFjY2VwdGFibGUgZXhwb3N1cmUKICAgbGV2ZWxzIG9mIGNs aWVudCBjcmVkZW50aWFscy4gIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBTSE9VTEQgTk9UCiAg IG1ha2UgYXNzdW1wdGlvbnMgYWJvdXQgdGhlIGNsaWVudCB0eXBlLgoKICAgQSBjbGllbnQgbWF5 IGJlIGltcGxlbWVudGVkIGFzIGEgZGlzdHJpYnV0ZWQgc2V0IG9mIGNvbXBvbmVudHMsIGVhY2gK ICAgd2l0aCBhIGRpZmZlcmVudCBjbGllbnQgdHlwZSBhbmQgc2VjdXJpdHkgY29udGV4dCAoZS5n LiBhIGRpc3RyaWJ1dGVkCiAgIGNsaWVudCB3aXRoIGJvdGggYSBjb25maWRlbnRpYWwgc2VydmVy LWJhc2VkIGNvbXBvbmVudCBhbmQgYSBwdWJsaWMKICAgYnJvd3Nlci1iYXNlZCBjb21wb25lbnQp LiAgSWYgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGRvZXMgbm90CiAgIHByb3ZpZGUgc3VwcG9y dCBmb3Igc3VjaCBjbGllbnRzLCBvciBkb2VzIG5vdCBwcm92aWRlIGd1aWRhbmNlIHdpdGgKICAg cmVnYXJkIHRvIHRoZWlyIHJlZ2lzdHJhdGlvbiwgdGhlIGNsaWVudCBTSE9VTEQgcmVnaXN0ZXIg ZWFjaAogICBjb21wb25lbnQgYXMgYSBzZXBhcmF0ZSBjbGllbnQuCgogICBUaGlzIHNwZWNpZmlj YXRpb24gaGFzIGJlZW4gZGVzaWduZWQgYXJvdW5kIHRoZSBmb2xsb3dpbmcgY2xpZW50CiAgIHBy b2ZpbGVzOgoKICAgd2ViIGFwcGxpY2F0aW9uCiAgICAgIEEgd2ViIGFwcGxpY2F0aW9uIGlzIGEg Y29uZmlkZW50aWFsIGNsaWVudCBydW5uaW5nIG9uIGEgd2ViCiAgICAgIHNlcnZlci4gIFJlc291 cmNlIG93bmVycyBhY2Nlc3MgdGhlIGNsaWVudCB2aWEgYW4gSFRNTCB1c2VyCiAgICAgIGludGVy ZmFjZSByZW5kZXJlZCBpbiBhIHVzZXItYWdlbnQgb24gdGhlIGRldmljZSB1c2VkIGJ5IHRoZQog ICAgICByZXNvdXJjZSBvd25lci4gIFRoZSBjbGllbnQgY3JlZGVudGlhbHMgYXMgd2VsbCBhcyBh bnkgYWNjZXNzCiAgICAgIHRva2VuIGlzc3VlZCB0byB0aGUgY2xpZW50IGFyZSBzdG9yZWQgb24g dGhlIHdlYiBzZXJ2ZXIgYW5kIGFyZQogICAgICBub3QgZXhwb3NlZCB0byBvciBhY2Nlc3NpYmxl IGJ5IHRoZSByZXNvdXJjZSBvd25lci4KICAgdXNlci1hZ2VudC1iYXNlZCBhcHBsaWNhdGlvbgog ICAgICBBIHVzZXItYWdlbnQtYmFzZWQgYXBwbGljYXRpb24gaXMgYSBwdWJsaWMgY2xpZW50IGlu IHdoaWNoIHRoZQogICAgICBjbGllbnQgY29kZSBpcyBkb3dubG9hZGVkIGZyb20gYSB3ZWIgc2Vy dmVyIGFuZCBleGVjdXRlcyB3aXRoaW4gYQogICAgICB1c2VyLWFnZW50IChlLmcuIHdlYiBicm93 c2VyKSBvbiB0aGUgZGV2aWNlIHVzZWQgYnkgdGhlIHJlc291cmNlCiAgICAgIG93bmVyLiAgUHJv dG9jb2wgZGF0YSBhbmQgY3JlZGVudGlhbHMgYXJlIGVhc2lseSBhY2Nlc3NpYmxlIChhbmQKICAg ICAgb2Z0ZW4gdmlzaWJsZSkgdG8gdGhlIHJlc291cmNlIG93bmVyLiAgU2luY2Ugc3VjaCBhcHBs aWNhdGlvbnMKICAgICAgcmVzaWRlIHdpdGhpbiB0aGUgdXNlci1hZ2VudCwgdGhleSBjYW4gbWFr ZSBzZWFtbGVzcyB1c2Ugb2YgdGhlCgoKCkhhbW1lciwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMg RGVjZW1iZXIgNCwgMjAxMiAgICAgICAgICAgICAgIFtQYWdlIDE0XQoMCkludGVybmV0LURyYWZ0 ICAgICAgICAgICAgICAgICAgT0F1dGggMi4wICAgICAgICAgICAgICAgICAgICAgIEp1bmUgMjAx MgoKCiAgICAgIHVzZXItYWdlbnQgY2FwYWJpbGl0aWVzIHdoZW4gcmVxdWVzdGluZyBhdXRob3Jp emF0aW9uLgogICBuYXRpdmUgYXBwbGljYXRpb24KICAgICAgQSBuYXRpdmUgYXBwbGljYXRpb24g aXMgYSBwdWJsaWMgY2xpZW50IGluc3RhbGxlZCBhbmQgZXhlY3V0ZWQgb24KICAgICAgdGhlIGRl dmljZSB1c2VkIGJ5IHRoZSByZXNvdXJjZSBvd25lci4gIFByb3RvY29sIGRhdGEgYW5kCiAgICAg IGNyZWRlbnRpYWxzIGFyZSBhY2Nlc3NpYmxlIHRvIHRoZSByZXNvdXJjZSBvd25lci4gIEl0IGlz IGFzc3VtZWQKICAgICAgdGhhdCBhbnkgY2xpZW50IGF1dGhlbnRpY2F0aW9uIGNyZWRlbnRpYWxz IGluY2x1ZGVkIGluIHRoZQogICAgICBhcHBsaWNhdGlvbiBjYW4gYmUgZXh0cmFjdGVkLiAgT24g dGhlIG90aGVyIGhhbmQsIGR5bmFtaWNhbGx5CiAgICAgIGlzc3VlZCBjcmVkZW50aWFscyBzdWNo IGFzIGFjY2VzcyB0b2tlbnMgb3IgcmVmcmVzaCB0b2tlbnMgY2FuCiAgICAgIHJlY2VpdmUgYW4g YWNjZXB0YWJsZSBsZXZlbCBvZiBwcm90ZWN0aW9uLiAgQXQgYSBtaW5pbXVtLCB0aGVzZQogICAg ICBjcmVkZW50aWFscyBhcmUgcHJvdGVjdGVkIGZyb20gaG9zdGlsZSBzZXJ2ZXJzIHdpdGggd2hp Y2ggdGhlCiAgICAgIGFwcGxpY2F0aW9uIG1heSBpbnRlcmFjdCB3aXRoLiAgT24gc29tZSBwbGF0 Zm9ybXMgdGhlc2UKICAgICAgY3JlZGVudGlhbHMgbWlnaHQgYmUgcHJvdGVjdGVkIGZyb20gb3Ro ZXIgYXBwbGljYXRpb25zIHJlc2lkaW5nIG9uCiAgICAgIHRoZSBzYW1lIGRldmljZS4KCjIuMi4g IENsaWVudCBJZGVudGlmaWVyCgogICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgaXNzdWVzIHRo ZSByZWdpc3RlcmVkIGNsaWVudCBhIGNsaWVudAogICBpZGVudGlmaWVyIC0gYSB1bmlxdWUgc3Ry aW5nIHJlcHJlc2VudGluZyB0aGUgcmVnaXN0cmF0aW9uCiAgIGluZm9ybWF0aW9uIHByb3ZpZGVk IGJ5IHRoZSBjbGllbnQuICBUaGUgY2xpZW50IGlkZW50aWZpZXIgaXMgbm90IGEKICAgc2VjcmV0 OyBpdCBpcyBleHBvc2VkIHRvIHRoZSByZXNvdXJjZSBvd25lciwgYW5kIE1VU1QgTk9UIGJlIHVz ZWQKICAgYWxvbmUgZm9yIGNsaWVudCBhdXRoZW50aWNhdGlvbi4gIFRoZSBjbGllbnQgaWRlbnRp ZmllciBpcyB1bmlxdWUgdG8KICAgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLgoKICAgVGhlIGNs aWVudCBpZGVudGlmaWVyIHN0cmluZyBzaXplIGlzIGxlZnQgdW5kZWZpbmVkIGJ5IHRoaXMKICAg c3BlY2lmaWNhdGlvbi4gIFRoZSBjbGllbnQgc2hvdWxkIGF2b2lkIG1ha2luZyBhc3N1bXB0aW9u cyBhYm91dCB0aGUKICAgaWRlbnRpZmllciBzaXplLiAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVy IFNIT1VMRCBkb2N1bWVudCB0aGUgc2l6ZQogICBvZiBhbnkgaWRlbnRpZmllciBpdCBpc3N1ZXMu CgoyLjMuICBDbGllbnQgQXV0aGVudGljYXRpb24KCiAgIElmIHRoZSBjbGllbnQgdHlwZSBpcyBj b25maWRlbnRpYWwsIHRoZSBjbGllbnQgYW5kIGF1dGhvcml6YXRpb24KICAgc2VydmVyIGVzdGFi bGlzaCBhIGNsaWVudCBhdXRoZW50aWNhdGlvbiBtZXRob2Qgc3VpdGFibGUgZm9yIHRoZQogICBz ZWN1cml0eSByZXF1aXJlbWVudHMgb2YgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLiAgVGhlIGF1 dGhvcml6YXRpb24KICAgc2VydmVyIE1BWSBhY2NlcHQgYW55IGZvcm0gb2YgY2xpZW50IGF1dGhl bnRpY2F0aW9uIG1lZXRpbmcgaXRzCiAgIHNlY3VyaXR5IHJlcXVpcmVtZW50cy4KCiAgIENvbmZp ZGVudGlhbCBjbGllbnRzIGFyZSB0eXBpY2FsbHkgaXNzdWVkIChvciBlc3RhYmxpc2gpIGEgc2V0 IG9mCiAgIGNsaWVudCBjcmVkZW50aWFscyB1c2VkIGZvciBhdXRoZW50aWNhdGluZyB3aXRoIHRo ZSBhdXRob3JpemF0aW9uCiAgIHNlcnZlciAoZS5nLiBwYXNzd29yZCwgcHVibGljL3ByaXZhdGUg a2V5IHBhaXIpLgoKICAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIE1BWSBlc3RhYmxpc2ggYSBj bGllbnQgYXV0aGVudGljYXRpb24gbWV0aG9kCiAgIHdpdGggcHVibGljIGNsaWVudHMuICBIb3dl dmVyLCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVTVCBOT1QgcmVseQogICBvbiBwdWJsaWMg Y2xpZW50IGF1dGhlbnRpY2F0aW9uIGZvciB0aGUgcHVycG9zZSBvZiBpZGVudGlmeWluZyB0aGUK ICAgY2xpZW50LgoKICAgVGhlIGNsaWVudCBNVVNUIE5PVCB1c2UgbW9yZSB0aGFuIG9uZSBhdXRo ZW50aWNhdGlvbiBtZXRob2QgaW4gZWFjaAogICByZXF1ZXN0LgoKCgoKSGFtbWVyLCBldCBhbC4g ICAgICAgICAgRXhwaXJlcyBEZWNlbWJlciA0LCAyMDEyICAgICAgICAgICAgICAgW1BhZ2UgMTVd CgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICBPQXV0aCAyLjAgICAgICAgICAgICAg ICAgICAgICAgSnVuZSAyMDEyCgoKMi4zLjEuICBDbGllbnQgUGFzc3dvcmQKCiAgIENsaWVudHMg aW4gcG9zc2Vzc2lvbiBvZiBhIGNsaWVudCBwYXNzd29yZCBNQVkgdXNlIHRoZSBIVFRQIEJhc2lj CiAgIGF1dGhlbnRpY2F0aW9uIHNjaGVtZSBhcyBkZWZpbmVkIGluIFtSRkMyNjE3XSB0byBhdXRo ZW50aWNhdGUgd2l0aAogICB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIuICBUaGUgY2xpZW50IGlk ZW50aWZpZXIgaXMgdXNlZCBhcyB0aGUKICAgdXNlcm5hbWUsIGFuZCB0aGUgY2xpZW50IHBhc3N3 b3JkIGlzIHVzZWQgYXMgdGhlIHBhc3N3b3JkLiAgVGhlCiAgIGF1dGhvcml6YXRpb24gc2VydmVy IE1VU1Qgc3VwcG9ydCB0aGUgSFRUUCBCYXNpYyBhdXRoZW50aWNhdGlvbgogICBzY2hlbWUgZm9y IGF1dGhlbnRpY2F0aW5nIGNsaWVudHMgd2hpY2ggd2VyZSBpc3N1ZWQgYSBjbGllbnQKICAgcGFz c3dvcmQuCgogICBGb3IgZXhhbXBsZSAoZXh0cmEgbGluZSBicmVha3MgYXJlIGZvciBkaXNwbGF5 IHB1cnBvc2VzIG9ubHkpOgoKCiAgICAgQXV0aG9yaXphdGlvbjogQmFzaWMgY3paQ2FHUlNhM0Yw TXpvM1JtcG1jREJhUW5JeFMzUkVVbUp1Wmxaa2JVbDMKCgogICBBbHRlcm5hdGl2ZWx5LCB0aGUg YXV0aG9yaXphdGlvbiBzZXJ2ZXIgTUFZIHN1cHBvcnQgaW5jbHVkaW5nIHRoZQogICBjbGllbnQg Y3JlZGVudGlhbHMgaW4gdGhlIHJlcXVlc3QgYm9keSB1c2luZyB0aGUgZm9sbG93aW5nCiAgIHBh cmFtZXRlcnM6CgogICBjbGllbnRfaWQKICAgICAgICAgUkVRVUlSRUQuICBUaGUgY2xpZW50IGlk ZW50aWZpZXIgaXNzdWVkIHRvIHRoZSBjbGllbnQgZHVyaW5nCiAgICAgICAgIHRoZSByZWdpc3Ry YXRpb24gcHJvY2VzcyBkZXNjcmliZWQgYnkgU2VjdGlvbiAyLjIuCiAgIGNsaWVudF9zZWNyZXQK ICAgICAgICAgUkVRVUlSRUQuICBUaGUgY2xpZW50IHNlY3JldC4gIFRoZSBjbGllbnQgTUFZIG9t aXQgdGhlCiAgICAgICAgIHBhcmFtZXRlciBpZiB0aGUgY2xpZW50IHNlY3JldCBpcyBhbiBlbXB0 eSBzdHJpbmcuCgogICBJbmNsdWRpbmcgdGhlIGNsaWVudCBjcmVkZW50aWFscyBpbiB0aGUgcmVx dWVzdCBib2R5IHVzaW5nIHRoZSB0d28KICAgcGFyYW1ldGVycyBpcyBOT1QgUkVDT01NRU5ERUQs IGFuZCBTSE9VTEQgYmUgbGltaXRlZCB0byBjbGllbnRzCiAgIHVuYWJsZSB0byBkaXJlY3RseSB1 dGlsaXplIHRoZSBIVFRQIEJhc2ljIGF1dGhlbnRpY2F0aW9uIHNjaGVtZSAob3IKICAgb3RoZXIg cGFzc3dvcmQtYmFzZWQgSFRUUCBhdXRoZW50aWNhdGlvbiBzY2hlbWVzKS4gIFRoZSBwYXJhbWV0 ZXJzCiAgIGNhbiBvbmx5IGJlIHRyYW5zbWl0dGVkIGluIHRoZSByZXF1ZXN0IGJvZHkgYW5kIE1V U1QgTk9UIGJlIGluY2x1ZGVkCiAgIGluIHRoZSByZXF1ZXN0IFVSSS4KCiAgIEZvciBleGFtcGxl LCByZXF1ZXN0aW5nIHRvIHJlZnJlc2ggYW4gYWNjZXNzIHRva2VuIChTZWN0aW9uIDYpIHVzaW5n CiAgIHRoZSBib2R5IHBhcmFtZXRlcnMgKGV4dHJhIGxpbmUgYnJlYWtzIGFyZSBmb3IgZGlzcGxh eSBwdXJwb3NlcwogICBvbmx5KToKCgogICAgIFBPU1QgL3Rva2VuIEhUVFAvMS4xCiAgICAgSG9z dDogc2VydmVyLmV4YW1wbGUuY29tCiAgICAgQ29udGVudC1UeXBlOiBhcHBsaWNhdGlvbi94LXd3 dy1mb3JtLXVybGVuY29kZWQ7Y2hhcnNldD1VVEYtOAoKICAgICBncmFudF90eXBlPXJlZnJlc2hf dG9rZW4mcmVmcmVzaF90b2tlbj10R3p2M0pPa0YwWEc1UXgyVGxLV0lBCiAgICAgJmNsaWVudF9p ZD1zNkJoZFJrcXQzJmNsaWVudF9zZWNyZXQ9N0ZqZnAwWkJyMUt0RFJibmZWZG1JdwoKCiAgIFRo ZSBhdXRob3JpemF0aW9uIHNlcnZlciBNVVNUIHJlcXVpcmUgdGhlIHVzZSBvZiBUTFMgYXMgZGVz Y3JpYmVkIGluCgoKCkhhbW1lciwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgRGVjZW1iZXIgNCwg MjAxMiAgICAgICAgICAgICAgIFtQYWdlIDE2XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAg ICAgICAgT0F1dGggMi4wICAgICAgICAgICAgICAgICAgICAgIEp1bmUgMjAxMgoKCiAgIFNlY3Rp b24gMS42IHdoZW4gc2VuZGluZyByZXF1ZXN0cyB1c2luZyBwYXNzd29yZCBhdXRoZW50aWNhdGlv bi4KCiAgIFNpbmNlIHRoaXMgY2xpZW50IGF1dGhlbnRpY2F0aW9uIG1ldGhvZCBpbnZvbHZlcyBh IHBhc3N3b3JkLCB0aGUKICAgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVTVCBwcm90ZWN0IGFueSBl bmRwb2ludCB1dGlsaXppbmcgaXQgYWdhaW5zdAogICBicnV0ZSBmb3JjZSBhdHRhY2tzLgoKMi4z LjIuICBPdGhlciBBdXRoZW50aWNhdGlvbiBNZXRob2RzCgogICBUaGUgYXV0aG9yaXphdGlvbiBz ZXJ2ZXIgTUFZIHN1cHBvcnQgYW55IHN1aXRhYmxlIEhUVFAgYXV0aGVudGljYXRpb24KICAgc2No ZW1lIG1hdGNoaW5nIGl0cyBzZWN1cml0eSByZXF1aXJlbWVudHMuICBXaGVuIHVzaW5nIG90aGVy CiAgIGF1dGhlbnRpY2F0aW9uIG1ldGhvZHMsIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBNVVNU IGRlZmluZSBhCiAgIG1hcHBpbmcgYmV0d2VlbiB0aGUgY2xpZW50IGlkZW50aWZpZXIgKHJlZ2lz dHJhdGlvbiByZWNvcmQpIGFuZAogICBhdXRoZW50aWNhdGlvbiBzY2hlbWUuCgoyLjQuICBVbnJl Z2lzdGVyZWQgQ2xpZW50cwoKICAgVGhpcyBzcGVjaWZpY2F0aW9uIGRvZXMgbm90IGV4Y2x1ZGUg dGhlIHVzZSBvZiB1bnJlZ2lzdGVyZWQgY2xpZW50cy4KICAgSG93ZXZlciwgdGhlIHVzZSB3aXRo IHN1Y2ggY2xpZW50cyBpcyBiZXlvbmQgdGhlIHNjb3BlIG9mIHRoaXMKICAgc3BlY2lmaWNhdGlv biwgYW5kIHJlcXVpcmVzIGFkZGl0aW9uYWwgc2VjdXJpdHkgYW5hbHlzaXMgYW5kIHJldmlldwog ICBvZiBpdHMgaW50ZXJvcGVyYWJpbGl0eSBpbXBhY3QuCgoKMy4gIFByb3RvY29sIEVuZHBvaW50 cwoKICAgVGhlIGF1dGhvcml6YXRpb24gcHJvY2VzcyB1dGlsaXplcyB0d28gYXV0aG9yaXphdGlv biBzZXJ2ZXIgZW5kcG9pbnRzCiAgIChIVFRQIHJlc291cmNlcyk6CgogICBvICBBdXRob3JpemF0 aW9uIGVuZHBvaW50IC0gdXNlZCBieSB0aGUgY2xpZW50IHRvIG9idGFpbgogICAgICBhdXRob3Jp emF0aW9uIGZyb20gdGhlIHJlc291cmNlIG93bmVyIHZpYSB1c2VyLWFnZW50IHJlZGlyZWN0aW9u LgogICBvICBUb2tlbiBlbmRwb2ludCAtIHVzZWQgYnkgdGhlIGNsaWVudCB0byBleGNoYW5nZSBh biBhdXRob3JpemF0aW9uCiAgICAgIGdyYW50IGZvciBhbiBhY2Nlc3MgdG9rZW4sIHR5cGljYWxs eSB3aXRoIGNsaWVudCBhdXRoZW50aWNhdGlvbi4KCiAgIEFzIHdlbGwgYXMgb25lIGNsaWVudCBl bmRwb2ludDoKCiAgIG8gIFJlZGlyZWN0aW9uIGVuZHBvaW50IC0gdXNlZCBieSB0aGUgYXV0aG9y aXphdGlvbiBzZXJ2ZXIgdG8gcmV0dXJuCiAgICAgIGF1dGhvcml6YXRpb24gY3JlZGVudGlhbHMg cmVzcG9uc2VzIHRvIHRoZSBjbGllbnQgdmlhIHRoZSByZXNvdXJjZQogICAgICBvd25lciB1c2Vy LWFnZW50LgoKICAgTm90IGV2ZXJ5IGF1dGhvcml6YXRpb24gZ3JhbnQgdHlwZSB1dGlsaXplcyBi b3RoIGVuZHBvaW50cy4KICAgRXh0ZW5zaW9uIGdyYW50IHR5cGVzIE1BWSBkZWZpbmUgYWRkaXRp b25hbCBlbmRwb2ludHMgYXMgbmVlZGVkLgoKMy4xLiAgQXV0aG9yaXphdGlvbiBFbmRwb2ludAoK ICAgVGhlIGF1dGhvcml6YXRpb24gZW5kcG9pbnQgaXMgdXNlZCB0byBpbnRlcmFjdCB3aXRoIHRo ZSByZXNvdXJjZQogICBvd25lciBhbmQgb2J0YWluIGFuIGF1dGhvcml6YXRpb24gZ3JhbnQuICBU aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIKICAgTVVTVCBmaXJzdCB2ZXJpZnkgdGhlIGlkZW50aXR5 IG9mIHRoZSByZXNvdXJjZSBvd25lci4gIFRoZSB3YXkgaW4KICAgd2hpY2ggdGhlIGF1dGhvcml6 YXRpb24gc2VydmVyIGF1dGhlbnRpY2F0ZXMgdGhlIHJlc291cmNlIG93bmVyIChlLmcuCiAgIHVz ZXJuYW1lIGFuZCBwYXNzd29yZCBsb2dpbiwgc2Vzc2lvbiBjb29raWVzKSBpcyBiZXlvbmQgdGhl IHNjb3BlIG9mCgoKCkhhbW1lciwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgRGVjZW1iZXIgNCwg MjAxMiAgICAgICAgICAgICAgIFtQYWdlIDE3XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAg ICAgICAgT0F1dGggMi4wICAgICAgICAgICAgICAgICAgICAgIEp1bmUgMjAxMgoKCiAgIHRoaXMg c3BlY2lmaWNhdGlvbi4KCiAgIFRoZSBtZWFucyB0aHJvdWdoIHdoaWNoIHRoZSBjbGllbnQgb2J0 YWlucyB0aGUgbG9jYXRpb24gb2YgdGhlCiAgIGF1dGhvcml6YXRpb24gZW5kcG9pbnQgYXJlIGJl eW9uZCB0aGUgc2NvcGUgb2YgdGhpcyBzcGVjaWZpY2F0aW9uLAogICBidXQgdGhlIGxvY2F0aW9u IGlzIHR5cGljYWxseSBwcm92aWRlZCBpbiB0aGUgc2VydmljZSBkb2N1bWVudGF0aW9uLgoKICAg VGhlIGVuZHBvaW50IFVSSSBNQVkgaW5jbHVkZSBhbiAiYXBwbGljYXRpb24veC13d3ctZm9ybS11 cmxlbmNvZGVkIgogICBmb3JtYXR0ZWQgKFtXM0MuUkVDLWh0bWw0MDEtMTk5OTEyMjRdKSBxdWVy eSBjb21wb25lbnQgKFtSRkMzOTg2XQogICBzZWN0aW9uIDMuNCksIHdoaWNoIE1VU1QgYmUgcmV0 YWluZWQgd2hlbiBhZGRpbmcgYWRkaXRpb25hbCBxdWVyeQogICBwYXJhbWV0ZXJzLiAgVGhlIGVu ZHBvaW50IFVSSSBNVVNUIE5PVCBpbmNsdWRlIGEgZnJhZ21lbnQgY29tcG9uZW50LgoKICAgU2lu Y2UgcmVxdWVzdHMgdG8gdGhlIGF1dGhvcml6YXRpb24gZW5kcG9pbnQgcmVzdWx0IGluIHVzZXIK ICAgYXV0aGVudGljYXRpb24gYW5kIHRoZSB0cmFuc21pc3Npb24gb2YgY2xlYXItdGV4dCBjcmVk ZW50aWFscyAoaW4gdGhlCiAgIEhUVFAgcmVzcG9uc2UpLCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2 ZXIgTVVTVCByZXF1aXJlIHRoZSB1c2Ugb2YgVExTCiAgIGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9u IDEuNiB3aGVuIHNlbmRpbmcgcmVxdWVzdHMgdG8gdGhlCiAgIGF1dGhvcml6YXRpb24gZW5kcG9p bnQuCgogICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVTVCBzdXBwb3J0IHRoZSB1c2Ugb2Yg dGhlIEhUVFAgIkdFVCIKICAgbWV0aG9kIFtSRkMyNjE2XSBmb3IgdGhlIGF1dGhvcml6YXRpb24g ZW5kcG9pbnQsIGFuZCBNQVkgc3VwcG9ydCB0aGUKICAgdXNlIG9mIHRoZSAiUE9TVCIgbWV0aG9k IGFzIHdlbGwuCgogICBQYXJhbWV0ZXJzIHNlbnQgd2l0aG91dCBhIHZhbHVlIE1VU1QgYmUgdHJl YXRlZCBhcyBpZiB0aGV5IHdlcmUKICAgb21pdHRlZCBmcm9tIHRoZSByZXF1ZXN0LiAgVGhlIGF1 dGhvcml6YXRpb24gc2VydmVyIE1VU1QgaWdub3JlCiAgIHVucmVjb2duaXplZCByZXF1ZXN0IHBh cmFtZXRlcnMuICBSZXF1ZXN0IGFuZCByZXNwb25zZSBwYXJhbWV0ZXJzCiAgIE1VU1QgTk9UIGJl IGluY2x1ZGVkIG1vcmUgdGhhbiBvbmNlLgoKMy4xLjEuICBSZXNwb25zZSBUeXBlCgogICBUaGUg YXV0aG9yaXphdGlvbiBlbmRwb2ludCBpcyB1c2VkIGJ5IHRoZSBhdXRob3JpemF0aW9uIGNvZGUg Z3JhbnQKICAgdHlwZSBhbmQgaW1wbGljaXQgZ3JhbnQgdHlwZSBmbG93cy4gIFRoZSBjbGllbnQg aW5mb3JtcyB0aGUKICAgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgb2YgdGhlIGRlc2lyZWQgZ3JhbnQg dHlwZSB1c2luZyB0aGUgZm9sbG93aW5nCiAgIHBhcmFtZXRlcjoKCiAgIHJlc3BvbnNlX3R5cGUK ICAgICAgICAgUkVRVUlSRUQuICBUaGUgdmFsdWUgTVVTVCBiZSBvbmUgb2YgImNvZGUiIGZvciBy ZXF1ZXN0aW5nIGFuCiAgICAgICAgIGF1dGhvcml6YXRpb24gY29kZSBhcyBkZXNjcmliZWQgYnkg U2VjdGlvbiA0LjEuMSwgInRva2VuIiBmb3IKICAgICAgICAgcmVxdWVzdGluZyBhbiBhY2Nlc3Mg dG9rZW4gKGltcGxpY2l0IGdyYW50KSBhcyBkZXNjcmliZWQgYnkKICAgICAgICAgU2VjdGlvbiA0 LjIuMSwgb3IgYSByZWdpc3RlcmVkIGV4dGVuc2lvbiB2YWx1ZSBhcyBkZXNjcmliZWQgYnkKICAg ICAgICAgU2VjdGlvbiA4LjQuCgogICBFeHRlbnNpb24gcmVzcG9uc2UgdHlwZXMgTUFZIGNvbnRh aW4gYSBzcGFjZS1kZWxpbWl0ZWQgKCV4MjApIGxpc3Qgb2YKICAgdmFsdWVzLCB3aGVyZSB0aGUg b3JkZXIgb2YgdmFsdWVzIGRvZXMgbm90IG1hdHRlciAoZS5nLiByZXNwb25zZSB0eXBlCiAgICJh IGIiIGlzIHRoZSBzYW1lIGFzICJiIGEiKS4gIFRoZSBtZWFuaW5nIG9mIHN1Y2ggY29tcG9zaXRl IHJlc3BvbnNlCiAgIHR5cGVzIGlzIGRlZmluZWQgYnkgdGhlaXIgcmVzcGVjdGl2ZSBzcGVjaWZp Y2F0aW9ucy4KCiAgIElmIGFuIGF1dGhvcml6YXRpb24gcmVxdWVzdCBpcyBtaXNzaW5nIHRoZSAi cmVzcG9uc2VfdHlwZSIgcGFyYW1ldGVyLAogICBvciBpZiB0aGUgcmVzcG9uc2UgdHlwZSBpcyBu b3QgdW5kZXJzdG9vZCwgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyCiAgIE1VU1QgcmV0dXJuIGFu IGVycm9yIHJlc3BvbnNlIGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDQuMS4yLjEuCgoKCkhhbW1l ciwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgRGVjZW1iZXIgNCwgMjAxMiAgICAgICAgICAgICAg IFtQYWdlIDE4XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgT0F1dGggMi4wICAg ICAgICAgICAgICAgICAgICAgIEp1bmUgMjAxMgoKCjMuMS4yLiAgUmVkaXJlY3Rpb24gRW5kcG9p bnQKCiAgIEFmdGVyIGNvbXBsZXRpbmcgaXRzIGludGVyYWN0aW9uIHdpdGggdGhlIHJlc291cmNl IG93bmVyLCB0aGUKICAgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgZGlyZWN0cyB0aGUgcmVzb3VyY2Ug b3duZXIncyB1c2VyLWFnZW50IGJhY2sgdG8KICAgdGhlIGNsaWVudC4gIFRoZSBhdXRob3JpemF0 aW9uIHNlcnZlciByZWRpcmVjdHMgdGhlIHVzZXItYWdlbnQgdG8gdGhlCiAgIGNsaWVudCdzIHJl ZGlyZWN0aW9uIGVuZHBvaW50IHByZXZpb3VzbHkgZXN0YWJsaXNoZWQgd2l0aCB0aGUKICAgYXV0 aG9yaXphdGlvbiBzZXJ2ZXIgZHVyaW5nIHRoZSBjbGllbnQgcmVnaXN0cmF0aW9uIHByb2Nlc3Mg b3Igd2hlbgogICBtYWtpbmcgdGhlIGF1dGhvcml6YXRpb24gcmVxdWVzdC4KCiAgIFRoZSByZWRp cmVjdGlvbiBlbmRwb2ludCBVUkkgTVVTVCBiZSBhbiBhYnNvbHV0ZSBVUkkgYXMgZGVmaW5lZCBi eQogICBbUkZDMzk4Nl0gc2VjdGlvbiA0LjMuICBUaGUgZW5kcG9pbnQgVVJJIE1BWSBpbmNsdWRl IGFuCiAgICJhcHBsaWNhdGlvbi94LXd3dy1mb3JtLXVybGVuY29kZWQiIGZvcm1hdHRlZAogICAo W1czQy5SRUMtaHRtbDQwMS0xOTk5MTIyNF0pIHF1ZXJ5IGNvbXBvbmVudCAoW1JGQzM5ODZdIHNl Y3Rpb24gMy40KSwKICAgd2hpY2ggTVVTVCBiZSByZXRhaW5lZCB3aGVuIGFkZGluZyBhZGRpdGlv bmFsIHF1ZXJ5IHBhcmFtZXRlcnMuICBUaGUKICAgZW5kcG9pbnQgVVJJIE1VU1QgTk9UIGluY2x1 ZGUgYSBmcmFnbWVudCBjb21wb25lbnQuCgozLjEuMi4xLiAgRW5kcG9pbnQgUmVxdWVzdCBDb25m aWRlbnRpYWxpdHkKCiAgIFRoZSByZWRpcmVjdGlvbiBlbmRwb2ludCBTSE9VTEQgcmVxdWlyZSB0 aGUgdXNlIG9mIFRMUyBhcyBkZXNjcmliZWQKICAgaW4gU2VjdGlvbiAxLjYgd2hlbiB0aGUgcmVx dWVzdGVkIHJlc3BvbnNlIHR5cGUgaXMgImNvZGUiIG9yICJ0b2tlbiIsCiAgIG9yIHdoZW4gdGhl IHJlZGlyZWN0aW9uIHJlcXVlc3Qgd2lsbCByZXN1bHQgaW4gdGhlIHRyYW5zbWlzc2lvbiBvZgog ICBzZW5zaXRpdmUgY3JlZGVudGlhbHMgb3ZlciBhbiBvcGVuIG5ldHdvcmsuICBUaGlzIHNwZWNp ZmljYXRpb24gZG9lcwogICBub3QgbWFuZGF0ZSB0aGUgdXNlIG9mIFRMUyBiZWNhdXNlIGF0IHRo ZSB0aW1lIG9mIHRoaXMgd3JpdGluZywKICAgcmVxdWlyaW5nIGNsaWVudHMgdG8gZGVwbG95IFRM UyBpcyBhIHNpZ25pZmljYW50IGh1cmRsZSBmb3IgbWFueQogICBjbGllbnQgZGV2ZWxvcGVycy4g IElmIFRMUyBpcyBub3QgYXZhaWxhYmxlLCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIKICAgU0hP VUxEIHdhcm4gdGhlIHJlc291cmNlIG93bmVyIGFib3V0IHRoZSBpbnNlY3VyZSBlbmRwb2ludCBw cmlvciB0bwogICByZWRpcmVjdGlvbiAoZS5nLiBkaXNwbGF5IGEgbWVzc2FnZSBkdXJpbmcgdGhl IGF1dGhvcml6YXRpb24KICAgcmVxdWVzdCkuCgogICBMYWNrIG9mIHRyYW5zcG9ydC1sYXllciBz ZWN1cml0eSBjYW4gaGF2ZSBhIHNldmVyZSBpbXBhY3Qgb24gdGhlCiAgIHNlY3VyaXR5IG9mIHRo ZSBjbGllbnQgYW5kIHRoZSBwcm90ZWN0ZWQgcmVzb3VyY2VzIGl0IGlzIGF1dGhvcml6ZWQKICAg dG8gYWNjZXNzLiAgVGhlIHVzZSBvZiB0cmFuc3BvcnQtbGF5ZXIgc2VjdXJpdHkgaXMgcGFydGlj dWxhcmx5CiAgIGNyaXRpY2FsIHdoZW4gdGhlIGF1dGhvcml6YXRpb24gcHJvY2VzcyBpcyB1c2Vk IGFzIGEgZm9ybSBvZgogICBkZWxlZ2F0ZWQgZW5kLXVzZXIgYXV0aGVudGljYXRpb24gYnkgdGhl IGNsaWVudCAoZS5nLiB0aGlyZC1wYXJ0eQogICBzaWduLWluIHNlcnZpY2UpLgoKMy4xLjIuMi4g IFJlZ2lzdHJhdGlvbiBSZXF1aXJlbWVudHMKCiAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBN VVNUIHJlcXVpcmUgdGhlIGZvbGxvd2luZyBjbGllbnRzIHRvCiAgIHJlZ2lzdGVyIHRoZWlyIHJl ZGlyZWN0aW9uIGVuZHBvaW50OgoKICAgbyAgUHVibGljIGNsaWVudHMuCiAgIG8gIENvbmZpZGVu dGlhbCBjbGllbnRzIHV0aWxpemluZyB0aGUgaW1wbGljaXQgZ3JhbnQgdHlwZS4KCiAgIFRoZSBh dXRob3JpemF0aW9uIHNlcnZlciBTSE9VTEQgcmVxdWlyZSBhbGwgY2xpZW50cyB0byByZWdpc3Rl ciB0aGVpcgogICByZWRpcmVjdGlvbiBlbmRwb2ludCBwcmlvciB0byB1dGlsaXppbmcgdGhlIGF1 dGhvcml6YXRpb24gZW5kcG9pbnQuCgogICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgU0hPVUxE IHJlcXVpcmUgdGhlIGNsaWVudCB0byBwcm92aWRlIHRoZQoKCgpIYW1tZXIsIGV0IGFsLiAgICAg ICAgICBFeHBpcmVzIERlY2VtYmVyIDQsIDIwMTIgICAgICAgICAgICAgICBbUGFnZSAxOV0KDApJ bnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgIE9BdXRoIDIuMCAgICAgICAgICAgICAgICAg ICAgICBKdW5lIDIwMTIKCgogICBjb21wbGV0ZSByZWRpcmVjdGlvbiBVUkkgKHRoZSBjbGllbnQg TUFZIHVzZSB0aGUgInN0YXRlIiByZXF1ZXN0CiAgIHBhcmFtZXRlciB0byBhY2hpZXZlIHBlci1y ZXF1ZXN0IGN1c3RvbWl6YXRpb24pLiAgSWYgcmVxdWlyaW5nIHRoZQogICByZWdpc3RyYXRpb24g b2YgdGhlIGNvbXBsZXRlIHJlZGlyZWN0aW9uIFVSSSBpcyBub3QgcG9zc2libGUsIHRoZQogICBh dXRob3JpemF0aW9uIHNlcnZlciBTSE9VTEQgcmVxdWlyZSB0aGUgcmVnaXN0cmF0aW9uIG9mIHRo ZSBVUkkKICAgc2NoZW1lLCBhdXRob3JpdHksIGFuZCBwYXRoIChhbGxvd2luZyB0aGUgY2xpZW50 IHRvIGR5bmFtaWNhbGx5IHZhcnkKICAgb25seSB0aGUgcXVlcnkgY29tcG9uZW50IG9mIHRoZSBy ZWRpcmVjdGlvbiBVUkkgd2hlbiByZXF1ZXN0aW5nCiAgIGF1dGhvcml6YXRpb24pLgoKICAgVGhl IGF1dGhvcml6YXRpb24gc2VydmVyIE1BWSBhbGxvdyB0aGUgY2xpZW50IHRvIHJlZ2lzdGVyIG11 bHRpcGxlCiAgIHJlZGlyZWN0aW9uIGVuZHBvaW50cy4KCiAgIExhY2sgb2YgYSByZWRpcmVjdGlv biBVUkkgcmVnaXN0cmF0aW9uIHJlcXVpcmVtZW50IGNhbiBlbmFibGUgYW4KICAgYXR0YWNrZXIg dG8gdXNlIHRoZSBhdXRob3JpemF0aW9uIGVuZHBvaW50IGFzIG9wZW4gcmVkaXJlY3RvciBhcwog ICBkZXNjcmliZWQgaW4gU2VjdGlvbiAxMC4xNS4KCjMuMS4yLjMuICBEeW5hbWljIENvbmZpZ3Vy YXRpb24KCiAgIElmIG11bHRpcGxlIHJlZGlyZWN0aW9uIFVSSXMgaGF2ZSBiZWVuIHJlZ2lzdGVy ZWQsIGlmIG9ubHkgcGFydCBvZgogICB0aGUgcmVkaXJlY3Rpb24gVVJJIGhhcyBiZWVuIHJlZ2lz dGVyZWQsIG9yIGlmIG5vIHJlZGlyZWN0aW9uIFVSSSBoYXMKICAgYmVlbiByZWdpc3RlcmVkLCB0 aGUgY2xpZW50IE1VU1QgaW5jbHVkZSBhIHJlZGlyZWN0aW9uIFVSSSB3aXRoIHRoZQogICBhdXRo b3JpemF0aW9uIHJlcXVlc3QgdXNpbmcgdGhlICJyZWRpcmVjdF91cmkiIHJlcXVlc3QgcGFyYW1l dGVyLgoKICAgV2hlbiBhIHJlZGlyZWN0aW9uIFVSSSBpcyBpbmNsdWRlZCBpbiBhbiBhdXRob3Jp emF0aW9uIHJlcXVlc3QsIHRoZQogICBhdXRob3JpemF0aW9uIHNlcnZlciBNVVNUIGNvbXBhcmUg YW5kIG1hdGNoIHRoZSB2YWx1ZSByZWNlaXZlZAogICBhZ2FpbnN0IGF0IGxlYXN0IG9uZSBvZiB0 aGUgcmVnaXN0ZXJlZCByZWRpcmVjdGlvbiBVUklzIChvciBVUkkKICAgY29tcG9uZW50cykgYXMg ZGVmaW5lZCBpbiBbUkZDMzk4Nl0gc2VjdGlvbiA2LCBpZiBhbnkgcmVkaXJlY3Rpb24KICAgVVJJ cyB3ZXJlIHJlZ2lzdGVyZWQuICBJZiB0aGUgY2xpZW50IHJlZ2lzdHJhdGlvbiBpbmNsdWRlZCB0 aGUgZnVsbAogICByZWRpcmVjdGlvbiBVUkksIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBNVVNU IGNvbXBhcmUgdGhlIHR3byBVUklzCiAgIHVzaW5nIHNpbXBsZSBzdHJpbmcgY29tcGFyaXNvbiBh cyBkZWZpbmVkIGluIFtSRkMzOTg2XSBzZWN0aW9uIDYuMi4xLgoKMy4xLjIuNC4gIEludmFsaWQg RW5kcG9pbnQKCiAgIElmIGFuIGF1dGhvcml6YXRpb24gcmVxdWVzdCBmYWlscyB2YWxpZGF0aW9u IGR1ZSB0byBhIG1pc3NpbmcsCiAgIGludmFsaWQsIG9yIG1pc21hdGNoaW5nIHJlZGlyZWN0aW9u IFVSSSwgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyCiAgIFNIT1VMRCBpbmZvcm0gdGhlIHJlc291 cmNlIG93bmVyIG9mIHRoZSBlcnJvciwgYW5kIE1VU1QgTk9UCiAgIGF1dG9tYXRpY2FsbHkgcmVk aXJlY3QgdGhlIHVzZXItYWdlbnQgdG8gdGhlIGludmFsaWQgcmVkaXJlY3Rpb24gVVJJLgoKMy4x LjIuNS4gIEVuZHBvaW50IENvbnRlbnQKCiAgIFRoZSByZWRpcmVjdGlvbiByZXF1ZXN0IHRvIHRo ZSBjbGllbnQncyBlbmRwb2ludCB0eXBpY2FsbHkgcmVzdWx0cyBpbgogICBhbiBIVE1MIGRvY3Vt ZW50IHJlc3BvbnNlLCBwcm9jZXNzZWQgYnkgdGhlIHVzZXItYWdlbnQuICBJZiB0aGUgSFRNTAog ICByZXNwb25zZSBpcyBzZXJ2ZWQgZGlyZWN0bHkgYXMgdGhlIHJlc3VsdCBvZiB0aGUgcmVkaXJl Y3Rpb24gcmVxdWVzdCwKICAgYW55IHNjcmlwdCBpbmNsdWRlZCBpbiB0aGUgSFRNTCBkb2N1bWVu dCB3aWxsIGV4ZWN1dGUgd2l0aCBmdWxsCiAgIGFjY2VzcyB0byB0aGUgcmVkaXJlY3Rpb24gVVJJ IGFuZCB0aGUgY3JlZGVudGlhbHMgaXQgY29udGFpbnMuCgogICBUaGUgY2xpZW50IFNIT1VMRCBO T1QgaW5jbHVkZSBhbnkgdGhpcmQtcGFydHkgc2NyaXB0cyAoZS5nLiB0aGlyZC0KICAgcGFydHkg YW5hbHl0aWNzLCBzb2NpYWwgcGx1Zy1pbnMsIGFkIG5ldHdvcmtzKSBpbiB0aGUgcmVkaXJlY3Rp b24KICAgZW5kcG9pbnQgcmVzcG9uc2UuICBJbnN0ZWFkLCBpdCBTSE9VTEQgZXh0cmFjdCB0aGUg Y3JlZGVudGlhbHMgZnJvbQoKCgpIYW1tZXIsIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIERlY2Vt YmVyIDQsIDIwMTIgICAgICAgICAgICAgICBbUGFnZSAyMF0KDApJbnRlcm5ldC1EcmFmdCAgICAg ICAgICAgICAgICAgIE9BdXRoIDIuMCAgICAgICAgICAgICAgICAgICAgICBKdW5lIDIwMTIKCgog ICB0aGUgVVJJIGFuZCByZWRpcmVjdCB0aGUgdXNlci1hZ2VudCBhZ2FpbiB0byBhbm90aGVyIGVu ZHBvaW50IHdpdGhvdXQKICAgZXhwb3NpbmcgdGhlIGNyZWRlbnRpYWxzIChpbiB0aGUgVVJJIG9y IGVsc2V3aGVyZSkuICBJZiB0aGlyZC1wYXJ0eQogICBzY3JpcHRzIGFyZSBpbmNsdWRlZCwgdGhl IGNsaWVudCBNVVNUIGVuc3VyZSB0aGF0IGl0cyBvd24gc2NyaXB0cwogICAodXNlZCB0byBleHRy YWN0IGFuZCByZW1vdmUgdGhlIGNyZWRlbnRpYWxzIGZyb20gdGhlIFVSSSkgd2lsbAogICBleGVj dXRlIGZpcnN0LgoKMy4yLiAgVG9rZW4gRW5kcG9pbnQKCiAgIFRoZSB0b2tlbiBlbmRwb2ludCBp cyB1c2VkIGJ5IHRoZSBjbGllbnQgdG8gb2J0YWluIGFuIGFjY2VzcyB0b2tlbiBieQogICBwcmVz ZW50aW5nIGl0cyBhdXRob3JpemF0aW9uIGdyYW50IG9yIHJlZnJlc2ggdG9rZW4uICBUaGUgdG9r ZW4KICAgZW5kcG9pbnQgaXMgdXNlZCB3aXRoIGV2ZXJ5IGF1dGhvcml6YXRpb24gZ3JhbnQgZXhj ZXB0IGZvciB0aGUKICAgaW1wbGljaXQgZ3JhbnQgdHlwZSAoc2luY2UgYW4gYWNjZXNzIHRva2Vu IGlzIGlzc3VlZCBkaXJlY3RseSkuCgogICBUaGUgbWVhbnMgdGhyb3VnaCB3aGljaCB0aGUgY2xp ZW50IG9idGFpbnMgdGhlIGxvY2F0aW9uIG9mIHRoZSB0b2tlbgogICBlbmRwb2ludCBhcmUgYmV5 b25kIHRoZSBzY29wZSBvZiB0aGlzIHNwZWNpZmljYXRpb24gYnV0IGlzIHR5cGljYWxseQogICBw cm92aWRlZCBpbiB0aGUgc2VydmljZSBkb2N1bWVudGF0aW9uLgoKICAgVGhlIGVuZHBvaW50IFVS SSBNQVkgaW5jbHVkZSBhbiAiYXBwbGljYXRpb24veC13d3ctZm9ybS11cmxlbmNvZGVkIgogICBm b3JtYXR0ZWQgKFtXM0MuUkVDLWh0bWw0MDEtMTk5OTEyMjRdKSBxdWVyeSBjb21wb25lbnQgKFtS RkMzOTg2XQogICBzZWN0aW9uIDMuNCksIHdoaWNoIE1VU1QgYmUgcmV0YWluZWQgd2hlbiBhZGRp bmcgYWRkaXRpb25hbCBxdWVyeQogICBwYXJhbWV0ZXJzLiAgVGhlIGVuZHBvaW50IFVSSSBNVVNU IE5PVCBpbmNsdWRlIGEgZnJhZ21lbnQgY29tcG9uZW50LgoKICAgU2luY2UgcmVxdWVzdHMgdG8g dGhlIHRva2VuIGVuZHBvaW50IHJlc3VsdCBpbiB0aGUgdHJhbnNtaXNzaW9uIG9mCiAgIGNsZWFy LXRleHQgY3JlZGVudGlhbHMgKGluIHRoZSBIVFRQIHJlcXVlc3QgYW5kIHJlc3BvbnNlKSwgdGhl CiAgIGF1dGhvcml6YXRpb24gc2VydmVyIE1VU1QgcmVxdWlyZSB0aGUgdXNlIG9mIFRMUyBhcyBk ZXNjcmliZWQgaW4KICAgU2VjdGlvbiAxLjYgd2hlbiBzZW5kaW5nIHJlcXVlc3RzIHRvIHRoZSB0 b2tlbiBlbmRwb2ludC4KCiAgIFRoZSBjbGllbnQgTVVTVCB1c2UgdGhlIEhUVFAgIlBPU1QiIG1l dGhvZCB3aGVuIG1ha2luZyBhY2Nlc3MgdG9rZW4KICAgcmVxdWVzdHMuCgogICBQYXJhbWV0ZXJz IHNlbnQgd2l0aG91dCBhIHZhbHVlIE1VU1QgYmUgdHJlYXRlZCBhcyBpZiB0aGV5IHdlcmUKICAg b21pdHRlZCBmcm9tIHRoZSByZXF1ZXN0LiAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIE1VU1Qg aWdub3JlCiAgIHVucmVjb2duaXplZCByZXF1ZXN0IHBhcmFtZXRlcnMuICBSZXF1ZXN0IGFuZCBy ZXNwb25zZSBwYXJhbWV0ZXJzCiAgIE1VU1QgTk9UIGJlIGluY2x1ZGVkIG1vcmUgdGhhbiBvbmNl LgoKMy4yLjEuICBDbGllbnQgQXV0aGVudGljYXRpb24KCiAgIENvbmZpZGVudGlhbCBjbGllbnRz IG9yIG90aGVyIGNsaWVudHMgaXNzdWVkIGNsaWVudCBjcmVkZW50aWFscyBNVVNUCiAgIGF1dGhl bnRpY2F0ZSB3aXRoIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBhcyBkZXNjcmliZWQgaW4KICAg U2VjdGlvbiAyLjMgd2hlbiBtYWtpbmcgcmVxdWVzdHMgdG8gdGhlIHRva2VuIGVuZHBvaW50LiAg Q2xpZW50CiAgIGF1dGhlbnRpY2F0aW9uIGlzIHVzZWQgZm9yOgoKICAgbyAgRW5mb3JjaW5nIHRo ZSBiaW5kaW5nIG9mIHJlZnJlc2ggdG9rZW5zIGFuZCBhdXRob3JpemF0aW9uIGNvZGVzIHRvCiAg ICAgIHRoZSBjbGllbnQgdGhleSB3ZXJlIGlzc3VlZCB0by4gIENsaWVudCBhdXRoZW50aWNhdGlv biBpcyBjcml0aWNhbAogICAgICB3aGVuIGFuIGF1dGhvcml6YXRpb24gY29kZSBpcyB0cmFuc21p dHRlZCB0byB0aGUgcmVkaXJlY3Rpb24KICAgICAgZW5kcG9pbnQgb3ZlciBhbiBpbnNlY3VyZSBj aGFubmVsLCBvciB3aGVuIHRoZSByZWRpcmVjdGlvbiBVUkkgaGFzCiAgICAgIG5vdCBiZWVuIHJl Z2lzdGVyZWQgaW4gZnVsbC4KCgoKCkhhbW1lciwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgRGVj ZW1iZXIgNCwgMjAxMiAgICAgICAgICAgICAgIFtQYWdlIDIxXQoMCkludGVybmV0LURyYWZ0ICAg ICAgICAgICAgICAgICAgT0F1dGggMi4wICAgICAgICAgICAgICAgICAgICAgIEp1bmUgMjAxMgoK CiAgIG8gIFJlY292ZXJpbmcgZnJvbSBhIGNvbXByb21pc2VkIGNsaWVudCBieSBkaXNhYmxpbmcg dGhlIGNsaWVudCBvcgogICAgICBjaGFuZ2luZyBpdHMgY3JlZGVudGlhbHMsIHRodXMgcHJldmVu dGluZyBhbiBhdHRhY2tlciBmcm9tIGFidXNpbmcKICAgICAgc3RvbGVuIHJlZnJlc2ggdG9rZW5z LiAgQ2hhbmdpbmcgYSBzaW5nbGUgc2V0IG9mIGNsaWVudAogICAgICBjcmVkZW50aWFscyBpcyBz aWduaWZpY2FudGx5IGZhc3RlciB0aGFuIHJldm9raW5nIGFuIGVudGlyZSBzZXQgb2YKICAgICAg cmVmcmVzaCB0b2tlbnMuCiAgIG8gIEltcGxlbWVudGluZyBhdXRoZW50aWNhdGlvbiBtYW5hZ2Vt ZW50IGJlc3QgcHJhY3RpY2VzIHdoaWNoCiAgICAgIHJlcXVpcmUgcGVyaW9kaWMgY3JlZGVudGlh bCByb3RhdGlvbi4gIFJvdGF0aW9uIG9mIGFuIGVudGlyZSBzZXQKICAgICAgb2YgcmVmcmVzaCB0 b2tlbnMgY2FuIGJlIGNoYWxsZW5naW5nLCB3aGlsZSByb3RhdGlvbiBvZiBhIHNpbmdsZQogICAg ICBzZXQgb2YgY2xpZW50IGNyZWRlbnRpYWxzIGlzIHNpZ25pZmljYW50bHkgZWFzaWVyLgoKICAg QSBwdWJsaWMgY2xpZW50IHRoYXQgd2FzIG5vdCBpc3N1ZWQgYSBjbGllbnQgcGFzc3dvcmQgTUFZ IHVzZSB0aGUKICAgImNsaWVudF9pZCIgcmVxdWVzdCBwYXJhbWV0ZXIgdG8gaWRlbnRpZnkgaXRz ZWxmIHdoZW4gc2VuZGluZwogICByZXF1ZXN0cyB0byB0aGUgdG9rZW4gZW5kcG9pbnQgKGUuZy4g Zm9yIHRoZSBwdXJwb3NlIG9mIHByb3ZpZGluZwogICBlbmQtdXNlciBjb250ZXh0LCBjbGllbnQg dXNhZ2Ugc3RhdGlzdGljcykuCgozLjMuICBBY2Nlc3MgVG9rZW4gU2NvcGUKCiAgIFRoZSBhdXRo b3JpemF0aW9uIGFuZCB0b2tlbiBlbmRwb2ludHMgYWxsb3cgdGhlIGNsaWVudCB0byBzcGVjaWZ5 IHRoZQogICBzY29wZSBvZiB0aGUgYWNjZXNzIHJlcXVlc3QgdXNpbmcgdGhlICJzY29wZSIgcmVx dWVzdCBwYXJhbWV0ZXIuICBJbgogICB0dXJuLCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgdXNl cyB0aGUgInNjb3BlIiByZXNwb25zZSBwYXJhbWV0ZXIgdG8KICAgaW5mb3JtIHRoZSBjbGllbnQg b2YgdGhlIHNjb3BlIG9mIHRoZSBhY2Nlc3MgdG9rZW4gaXNzdWVkLgoKICAgVGhlIHZhbHVlIG9m IHRoZSBzY29wZSBwYXJhbWV0ZXIgaXMgZXhwcmVzc2VkIGFzIGEgbGlzdCBvZiBzcGFjZS0KICAg ZGVsaW1pdGVkLCBjYXNlIHNlbnNpdGl2ZSBzdHJpbmdzLiAgVGhlIHN0cmluZ3MgYXJlIGRlZmlu ZWQgYnkgdGhlCiAgIGF1dGhvcml6YXRpb24gc2VydmVyLiAgSWYgdGhlIHZhbHVlIGNvbnRhaW5z IG11bHRpcGxlIHNwYWNlLWRlbGltaXRlZAogICBzdHJpbmdzLCB0aGVpciBvcmRlciBkb2VzIG5v dCBtYXR0ZXIsIGFuZCBlYWNoIHN0cmluZyBhZGRzIGFuCiAgIGFkZGl0aW9uYWwgYWNjZXNzIHJh bmdlIHRvIHRoZSByZXF1ZXN0ZWQgc2NvcGUuCgoKICAgICBzY29wZSAgICAgICA9IHNjb3BlLXRv a2VuICooIFNQIHNjb3BlLXRva2VuICkKICAgICBzY29wZS10b2tlbiA9IDEqKCAleDIxIC8gJXgy My01QiAvICV4NUQtN0UgKQoKCiAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBNQVkgZnVsbHkg b3IgcGFydGlhbGx5IGlnbm9yZSB0aGUgc2NvcGUKICAgcmVxdWVzdGVkIGJ5IHRoZSBjbGllbnQg YmFzZWQgb24gdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHBvbGljeSBvcgogICB0aGUgcmVzb3Vy Y2Ugb3duZXIncyBpbnN0cnVjdGlvbnMuICBJZiB0aGUgaXNzdWVkIGFjY2VzcyB0b2tlbiBzY29w ZQogICBpcyBkaWZmZXJlbnQgZnJvbSB0aGUgb25lIHJlcXVlc3RlZCBieSB0aGUgY2xpZW50LCB0 aGUgYXV0aG9yaXphdGlvbgogICBzZXJ2ZXIgTVVTVCBpbmNsdWRlIHRoZSAic2NvcGUiIHJlc3Bv bnNlIHBhcmFtZXRlciB0byBpbmZvcm0gdGhlCiAgIGNsaWVudCBvZiB0aGUgYWN0dWFsIHNjb3Bl IGdyYW50ZWQuCgogICBJZiB0aGUgY2xpZW50IG9taXRzIHRoZSBzY29wZSBwYXJhbWV0ZXIgd2hl biByZXF1ZXN0aW5nCiAgIGF1dGhvcml6YXRpb24sIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBN VVNUIGVpdGhlciBwcm9jZXNzIHRoZQogICByZXF1ZXN0IHVzaW5nIGEgcHJlLWRlZmluZWQgZGVm YXVsdCB2YWx1ZSwgb3IgZmFpbCB0aGUgcmVxdWVzdAogICBpbmRpY2F0aW5nIGFuIGludmFsaWQg c2NvcGUuICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgU0hPVUxECiAgIGRvY3VtZW50IGl0cyBz Y29wZSByZXF1aXJlbWVudHMgYW5kIGRlZmF1bHQgdmFsdWUgKGlmIGRlZmluZWQpLgoKCgoKCgpI YW1tZXIsIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIERlY2VtYmVyIDQsIDIwMTIgICAgICAgICAg ICAgICBbUGFnZSAyMl0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgIE9BdXRoIDIu MCAgICAgICAgICAgICAgICAgICAgICBKdW5lIDIwMTIKCgo0LiAgT2J0YWluaW5nIEF1dGhvcml6 YXRpb24KCiAgIFRvIHJlcXVlc3QgYW4gYWNjZXNzIHRva2VuLCB0aGUgY2xpZW50IG9idGFpbnMg YXV0aG9yaXphdGlvbiBmcm9tIHRoZQogICByZXNvdXJjZSBvd25lci4gIFRoZSBhdXRob3JpemF0 aW9uIGlzIGV4cHJlc3NlZCBpbiB0aGUgZm9ybSBvZiBhbgogICBhdXRob3JpemF0aW9uIGdyYW50 IHdoaWNoIHRoZSBjbGllbnQgdXNlcyB0byByZXF1ZXN0IHRoZSBhY2Nlc3MKICAgdG9rZW4uICBP QXV0aCBkZWZpbmVzIGZvdXIgZ3JhbnQgdHlwZXM6IGF1dGhvcml6YXRpb24gY29kZSwgaW1wbGlj aXQsCiAgIHJlc291cmNlIG93bmVyIHBhc3N3b3JkIGNyZWRlbnRpYWxzLCBhbmQgY2xpZW50IGNy ZWRlbnRpYWxzLiAgSXQgYWxzbwogICBwcm92aWRlcyBhbiBleHRlbnNpb24gbWVjaGFuaXNtIGZv ciBkZWZpbmluZyBhZGRpdGlvbmFsIGdyYW50IHR5cGVzLgoKNC4xLiAgQXV0aG9yaXphdGlvbiBD b2RlIEdyYW50CgogICBUaGUgYXV0aG9yaXphdGlvbiBjb2RlIGdyYW50IHR5cGUgaXMgdXNlZCB0 byBvYnRhaW4gYm90aCBhY2Nlc3MKICAgdG9rZW5zIGFuZCByZWZyZXNoIHRva2VucyBhbmQgaXMg b3B0aW1pemVkIGZvciBjb25maWRlbnRpYWwgY2xpZW50cy4KICAgQXMgYSByZWRpcmVjdGlvbi1i YXNlZCBmbG93LCB0aGUgY2xpZW50IG11c3QgYmUgY2FwYWJsZSBvZgogICBpbnRlcmFjdGluZyB3 aXRoIHRoZSByZXNvdXJjZSBvd25lcidzIHVzZXItYWdlbnQgKHR5cGljYWxseSBhIHdlYgogICBi cm93c2VyKSBhbmQgY2FwYWJsZSBvZiByZWNlaXZpbmcgaW5jb21pbmcgcmVxdWVzdHMgKHZpYSBy ZWRpcmVjdGlvbikKICAgZnJvbSB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIuCgoKICAgICArLS0t LS0tLS0tLSsKICAgICB8IHJlc291cmNlIHwKICAgICB8ICAgb3duZXIgIHwKICAgICB8ICAgICAg ICAgIHwKICAgICArLS0tLS0tLS0tLSsKICAgICAgICAgIF4KICAgICAgICAgIHwKICAgICAgICAg KEIpCiAgICAgKy0tLS18LS0tLS0rICAgICAgICAgIENsaWVudCBJZGVudGlmaWVyICAgICAgKy0t LS0tLS0tLS0tLS0tLSsKICAgICB8ICAgICAgICAgLSstLS0tKEEpLS0gJiBSZWRpcmVjdGlvbiBV UkkgLS0tLT58ICAgICAgICAgICAgICAgfAogICAgIHwgIFVzZXItICAgfCAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHwgQXV0aG9yaXphdGlvbiB8CiAgICAgfCAgQWdlbnQgIC0rLS0t LShCKS0tIFVzZXIgYXV0aGVudGljYXRlcyAtLS0+fCAgICAgU2VydmVyICAgIHwKICAgICB8ICAg ICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAg fAogICAgIHwgICAgICAgICAtKy0tLS0oQyktLSBBdXRob3JpemF0aW9uIENvZGUgLS0tPHwgICAg ICAgICAgICAgICB8CiAgICAgKy18LS0tLXwtLS0rICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgKy0tLS0tLS0tLS0tLS0tLSsKICAgICAgIHwgICAgfCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgXiAgICAgIHYKICAgICAgKEEpICAoQykgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgIHwKICAgICAgIHwgICAgfCAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgIHwKICAgICAgIF4gICAgdiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgIHwKICAgICArLS0t LS0tLS0tKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgIHwKICAg ICB8ICAgICAgICAgfD4tLS0oRCktLSBBdXRob3JpemF0aW9uIENvZGUgLS0tLS0tLS0tJyAgICAg IHwKICAgICB8ICBDbGllbnQgfCAgICAgICAgICAmIFJlZGlyZWN0aW9uIFVSSSAgICAgICAgICAg ICAgICAgIHwKICAgICB8ICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHwKICAgICB8ICAgICAgICAgfDwtLS0oRSktLS0tLSBBY2Nlc3MgVG9rZW4g LS0tLS0tLS0tLS0tLS0tLS0tLScKICAgICArLS0tLS0tLS0tKyAgICAgICAody8gT3B0aW9uYWwg UmVmcmVzaCBUb2tlbikKCgogICBOb3RlOiBUaGUgbGluZXMgaWxsdXN0cmF0aW5nIHN0ZXBzIEEs IEIsIGFuZCBDIGFyZSBicm9rZW4gaW50byB0d28KICAgcGFydHMgYXMgdGhleSBwYXNzIHRocm91 Z2ggdGhlIHVzZXItYWdlbnQuCgoKCkhhbW1lciwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgRGVj ZW1iZXIgNCwgMjAxMiAgICAgICAgICAgICAgIFtQYWdlIDIzXQoMCkludGVybmV0LURyYWZ0ICAg ICAgICAgICAgICAgICAgT0F1dGggMi4wICAgICAgICAgICAgICAgICAgICAgIEp1bmUgMjAxMgoK CiAgICAgICAgICAgICAgICAgICAgIEZpZ3VyZSAzOiBBdXRob3JpemF0aW9uIENvZGUgRmxvdwoK ICAgVGhlIGZsb3cgaWxsdXN0cmF0ZWQgaW4gRmlndXJlIDMgaW5jbHVkZXMgdGhlIGZvbGxvd2lu ZyBzdGVwczoKCiAgIChBKSAgVGhlIGNsaWVudCBpbml0aWF0ZXMgdGhlIGZsb3cgYnkgZGlyZWN0 aW5nIHRoZSByZXNvdXJjZSBvd25lcidzCiAgICAgICAgdXNlci1hZ2VudCB0byB0aGUgYXV0aG9y aXphdGlvbiBlbmRwb2ludC4gIFRoZSBjbGllbnQgaW5jbHVkZXMKICAgICAgICBpdHMgY2xpZW50 IGlkZW50aWZpZXIsIHJlcXVlc3RlZCBzY29wZSwgbG9jYWwgc3RhdGUsIGFuZCBhCiAgICAgICAg cmVkaXJlY3Rpb24gVVJJIHRvIHdoaWNoIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciB3aWxsIHNl bmQgdGhlCiAgICAgICAgdXNlci1hZ2VudCBiYWNrIG9uY2UgYWNjZXNzIGlzIGdyYW50ZWQgKG9y IGRlbmllZCkuCiAgIChCKSAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGF1dGhlbnRpY2F0ZXMg dGhlIHJlc291cmNlIG93bmVyICh2aWEKICAgICAgICB0aGUgdXNlci1hZ2VudCkgYW5kIGVzdGFi bGlzaGVzIHdoZXRoZXIgdGhlIHJlc291cmNlIG93bmVyCiAgICAgICAgZ3JhbnRzIG9yIGRlbmll cyB0aGUgY2xpZW50J3MgYWNjZXNzIHJlcXVlc3QuCiAgIChDKSAgQXNzdW1pbmcgdGhlIHJlc291 cmNlIG93bmVyIGdyYW50cyBhY2Nlc3MsIHRoZSBhdXRob3JpemF0aW9uCiAgICAgICAgc2VydmVy IHJlZGlyZWN0cyB0aGUgdXNlci1hZ2VudCBiYWNrIHRvIHRoZSBjbGllbnQgdXNpbmcgdGhlCiAg ICAgICAgcmVkaXJlY3Rpb24gVVJJIHByb3ZpZGVkIGVhcmxpZXIgKGluIHRoZSByZXF1ZXN0IG9y IGR1cmluZwogICAgICAgIGNsaWVudCByZWdpc3RyYXRpb24pLiAgVGhlIHJlZGlyZWN0aW9uIFVS SSBpbmNsdWRlcyBhbgogICAgICAgIGF1dGhvcml6YXRpb24gY29kZSBhbmQgYW55IGxvY2FsIHN0 YXRlIHByb3ZpZGVkIGJ5IHRoZSBjbGllbnQKICAgICAgICBlYXJsaWVyLgogICAoRCkgIFRoZSBj bGllbnQgcmVxdWVzdHMgYW4gYWNjZXNzIHRva2VuIGZyb20gdGhlIGF1dGhvcml6YXRpb24KICAg ICAgICBzZXJ2ZXIncyB0b2tlbiBlbmRwb2ludCBieSBpbmNsdWRpbmcgdGhlIGF1dGhvcml6YXRp b24gY29kZQogICAgICAgIHJlY2VpdmVkIGluIHRoZSBwcmV2aW91cyBzdGVwLiAgV2hlbiBtYWtp bmcgdGhlIHJlcXVlc3QsIHRoZQogICAgICAgIGNsaWVudCBhdXRoZW50aWNhdGVzIHdpdGggdGhl IGF1dGhvcml6YXRpb24gc2VydmVyLiAgVGhlIGNsaWVudAogICAgICAgIGluY2x1ZGVzIHRoZSBy ZWRpcmVjdGlvbiBVUkkgdXNlZCB0byBvYnRhaW4gdGhlIGF1dGhvcml6YXRpb24KICAgICAgICBj b2RlIGZvciB2ZXJpZmljYXRpb24uCiAgIChFKSAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGF1 dGhlbnRpY2F0ZXMgdGhlIGNsaWVudCwgdmFsaWRhdGVzIHRoZQogICAgICAgIGF1dGhvcml6YXRp b24gY29kZSwgYW5kIGVuc3VyZXMgdGhlIHJlZGlyZWN0aW9uIFVSSSByZWNlaXZlZAogICAgICAg IG1hdGNoZXMgdGhlIFVSSSB1c2VkIHRvIHJlZGlyZWN0IHRoZSBjbGllbnQgaW4gc3RlcCAoQyku ICBJZgogICAgICAgIHZhbGlkLCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgcmVzcG9uZHMgYmFj ayB3aXRoIGFuIGFjY2VzcwogICAgICAgIHRva2VuIGFuZCBvcHRpb25hbGx5LCBhIHJlZnJlc2gg dG9rZW4uCgo0LjEuMS4gIEF1dGhvcml6YXRpb24gUmVxdWVzdAoKICAgVGhlIGNsaWVudCBjb25z dHJ1Y3RzIHRoZSByZXF1ZXN0IFVSSSBieSBhZGRpbmcgdGhlIGZvbGxvd2luZwogICBwYXJhbWV0 ZXJzIHRvIHRoZSBxdWVyeSBjb21wb25lbnQgb2YgdGhlIGF1dGhvcml6YXRpb24gZW5kcG9pbnQg VVJJCiAgIHVzaW5nIHRoZSAiYXBwbGljYXRpb24veC13d3ctZm9ybS11cmxlbmNvZGVkIiBmb3Jt YXQgYXMgZGVmaW5lZCBieQogICBbVzNDLlJFQy1odG1sNDAxLTE5OTkxMjI0XToKCiAgIHJlc3Bv bnNlX3R5cGUKICAgICAgICAgUkVRVUlSRUQuICBWYWx1ZSBNVVNUIGJlIHNldCB0byAiY29kZSIu CiAgIGNsaWVudF9pZAogICAgICAgICBSRVFVSVJFRC4gIFRoZSBjbGllbnQgaWRlbnRpZmllciBh cyBkZXNjcmliZWQgaW4gU2VjdGlvbiAyLjIuCiAgIHJlZGlyZWN0X3VyaQogICAgICAgICBPUFRJ T05BTC4gIEFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDMuMS4yLgogICBzY29wZQogICAgICAgICBP UFRJT05BTC4gIFRoZSBzY29wZSBvZiB0aGUgYWNjZXNzIHJlcXVlc3QgYXMgZGVzY3JpYmVkIGJ5 CiAgICAgICAgIFNlY3Rpb24gMy4zLgoKCgoKCkhhbW1lciwgZXQgYWwuICAgICAgICAgIEV4cGly ZXMgRGVjZW1iZXIgNCwgMjAxMiAgICAgICAgICAgICAgIFtQYWdlIDI0XQoMCkludGVybmV0LURy YWZ0ICAgICAgICAgICAgICAgICAgT0F1dGggMi4wICAgICAgICAgICAgICAgICAgICAgIEp1bmUg MjAxMgoKCiAgIHN0YXRlCiAgICAgICAgIFJFQ09NTUVOREVELiAgQW4gb3BhcXVlIHZhbHVlIHVz ZWQgYnkgdGhlIGNsaWVudCB0byBtYWludGFpbgogICAgICAgICBzdGF0ZSBiZXR3ZWVuIHRoZSBy ZXF1ZXN0IGFuZCBjYWxsYmFjay4gIFRoZSBhdXRob3JpemF0aW9uCiAgICAgICAgIHNlcnZlciBp bmNsdWRlcyB0aGlzIHZhbHVlIHdoZW4gcmVkaXJlY3RpbmcgdGhlIHVzZXItYWdlbnQgYmFjawog ICAgICAgICB0byB0aGUgY2xpZW50LiAgVGhlIHBhcmFtZXRlciBTSE9VTEQgYmUgdXNlZCBmb3Ig cHJldmVudGluZwogICAgICAgICBjcm9zcy1zaXRlIHJlcXVlc3QgZm9yZ2VyeSBhcyBkZXNjcmli ZWQgaW4gU2VjdGlvbiAxMC4xMi4KCiAgIFRoZSBjbGllbnQgZGlyZWN0cyB0aGUgcmVzb3VyY2Ug b3duZXIgdG8gdGhlIGNvbnN0cnVjdGVkIFVSSSB1c2luZyBhbgogICBIVFRQIHJlZGlyZWN0aW9u IHJlc3BvbnNlLCBvciBieSBvdGhlciBtZWFucyBhdmFpbGFibGUgdG8gaXQgdmlhIHRoZQogICB1 c2VyLWFnZW50LgoKICAgRm9yIGV4YW1wbGUsIHRoZSBjbGllbnQgZGlyZWN0cyB0aGUgdXNlci1h Z2VudCB0byBtYWtlIHRoZSBmb2xsb3dpbmcKICAgSFRUUCByZXF1ZXN0IHVzaW5nIFRMUyAoZXh0 cmEgbGluZSBicmVha3MgYXJlIGZvciBkaXNwbGF5IHB1cnBvc2VzCiAgIG9ubHkpOgoKCiAgICBH RVQgL2F1dGhvcml6ZT9yZXNwb25zZV90eXBlPWNvZGUmY2xpZW50X2lkPXM2QmhkUmtxdDMmc3Rh dGU9eHl6CiAgICAgICAgJnJlZGlyZWN0X3VyaT1odHRwcyUzQSUyRiUyRmNsaWVudCUyRWV4YW1w bGUlMkVjb20lMkZjYiBIVFRQLzEuMQogICAgSG9zdDogc2VydmVyLmV4YW1wbGUuY29tCgoKICAg VGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHZhbGlkYXRlcyB0aGUgcmVxdWVzdCB0byBlbnN1cmUg YWxsIHJlcXVpcmVkCiAgIHBhcmFtZXRlcnMgYXJlIHByZXNlbnQgYW5kIHZhbGlkLiAgSWYgdGhl IHJlcXVlc3QgaXMgdmFsaWQsIHRoZQogICBhdXRob3JpemF0aW9uIHNlcnZlciBhdXRoZW50aWNh dGVzIHRoZSByZXNvdXJjZSBvd25lciBhbmQgb2J0YWlucyBhbgogICBhdXRob3JpemF0aW9uIGRl Y2lzaW9uIChieSBhc2tpbmcgdGhlIHJlc291cmNlIG93bmVyIG9yIGJ5CiAgIGVzdGFibGlzaGlu ZyBhcHByb3ZhbCB2aWEgb3RoZXIgbWVhbnMpLgoKICAgV2hlbiBhIGRlY2lzaW9uIGlzIGVzdGFi bGlzaGVkLCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgZGlyZWN0cyB0aGUKICAgdXNlci1hZ2Vu dCB0byB0aGUgcHJvdmlkZWQgY2xpZW50IHJlZGlyZWN0aW9uIFVSSSB1c2luZyBhbiBIVFRQCiAg IHJlZGlyZWN0aW9uIHJlc3BvbnNlLCBvciBieSBvdGhlciBtZWFucyBhdmFpbGFibGUgdG8gaXQg dmlhIHRoZSB1c2VyLQogICBhZ2VudC4KCjQuMS4yLiAgQXV0aG9yaXphdGlvbiBSZXNwb25zZQoK ICAgSWYgdGhlIHJlc291cmNlIG93bmVyIGdyYW50cyB0aGUgYWNjZXNzIHJlcXVlc3QsIHRoZSBh dXRob3JpemF0aW9uCiAgIHNlcnZlciBpc3N1ZXMgYW4gYXV0aG9yaXphdGlvbiBjb2RlIGFuZCBk ZWxpdmVycyBpdCB0byB0aGUgY2xpZW50IGJ5CiAgIGFkZGluZyB0aGUgZm9sbG93aW5nIHBhcmFt ZXRlcnMgdG8gdGhlIHF1ZXJ5IGNvbXBvbmVudCBvZiB0aGUKICAgcmVkaXJlY3Rpb24gVVJJIHVz aW5nIHRoZSAiYXBwbGljYXRpb24veC13d3ctZm9ybS11cmxlbmNvZGVkIiBmb3JtYXQ6CgogICBj b2RlCiAgICAgICAgIFJFUVVJUkVELiAgVGhlIGF1dGhvcml6YXRpb24gY29kZSBnZW5lcmF0ZWQg YnkgdGhlCiAgICAgICAgIGF1dGhvcml6YXRpb24gc2VydmVyLiAgVGhlIGF1dGhvcml6YXRpb24g Y29kZSBNVVNUIGV4cGlyZQogICAgICAgICBzaG9ydGx5IGFmdGVyIGl0IGlzIGlzc3VlZCB0byBt aXRpZ2F0ZSB0aGUgcmlzayBvZiBsZWFrcy4gIEEKICAgICAgICAgbWF4aW11bSBhdXRob3JpemF0 aW9uIGNvZGUgbGlmZXRpbWUgb2YgMTAgbWludXRlcyBpcwogICAgICAgICBSRUNPTU1FTkRFRC4g IFRoZSBjbGllbnQgTVVTVCBOT1QgdXNlIHRoZSBhdXRob3JpemF0aW9uIGNvZGUKICAgICAgICAg bW9yZSB0aGFuIG9uY2UuICBJZiBhbiBhdXRob3JpemF0aW9uIGNvZGUgaXMgdXNlZCBtb3JlIHRo YW4KICAgICAgICAgb25jZSwgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIE1VU1QgZGVueSB0aGUg cmVxdWVzdCBhbmQgU0hPVUxECiAgICAgICAgIHJldm9rZSAod2hlbiBwb3NzaWJsZSkgYWxsIHRv a2VucyBwcmV2aW91c2x5IGlzc3VlZCBiYXNlZCBvbgoKCgpIYW1tZXIsIGV0IGFsLiAgICAgICAg ICBFeHBpcmVzIERlY2VtYmVyIDQsIDIwMTIgICAgICAgICAgICAgICBbUGFnZSAyNV0KDApJbnRl cm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgIE9BdXRoIDIuMCAgICAgICAgICAgICAgICAgICAg ICBKdW5lIDIwMTIKCgogICAgICAgICB0aGF0IGF1dGhvcml6YXRpb24gY29kZS4gIFRoZSBhdXRo b3JpemF0aW9uIGNvZGUgaXMgYm91bmQgdG8KICAgICAgICAgdGhlIGNsaWVudCBpZGVudGlmaWVy IGFuZCByZWRpcmVjdGlvbiBVUkkuCiAgIHN0YXRlCiAgICAgICAgIFJFUVVJUkVEIGlmIHRoZSAi c3RhdGUiIHBhcmFtZXRlciB3YXMgcHJlc2VudCBpbiB0aGUgY2xpZW50CiAgICAgICAgIGF1dGhv cml6YXRpb24gcmVxdWVzdC4gIFRoZSBleGFjdCB2YWx1ZSByZWNlaXZlZCBmcm9tIHRoZQogICAg ICAgICBjbGllbnQuCgogICBGb3IgZXhhbXBsZSwgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHJl ZGlyZWN0cyB0aGUgdXNlci1hZ2VudCBieQogICBzZW5kaW5nIHRoZSBmb2xsb3dpbmcgSFRUUCBy ZXNwb25zZToKCgogICAgIEhUVFAvMS4xIDMwMiBGb3VuZAogICAgIExvY2F0aW9uOiBodHRwczov L2NsaWVudC5leGFtcGxlLmNvbS9jYj9jb2RlPVNwbHhsT0JlWlFRWWJZUzZXeFNiSUEKICAgICAg ICAgICAgICAgJnN0YXRlPXh5egoKCiAgIFRoZSBjbGllbnQgTVVTVCBpZ25vcmUgdW5yZWNvZ25p emVkIHJlc3BvbnNlIHBhcmFtZXRlcnMuICBUaGUKICAgYXV0aG9yaXphdGlvbiBjb2RlIHN0cmlu ZyBzaXplIGlzIGxlZnQgdW5kZWZpbmVkIGJ5IHRoaXMKICAgc3BlY2lmaWNhdGlvbi4gIFRoZSBj bGllbnQgc2hvdWxkIGF2b2lkIG1ha2luZyBhc3N1bXB0aW9ucyBhYm91dCBjb2RlCiAgIHZhbHVl IHNpemVzLiAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIFNIT1VMRCBkb2N1bWVudCB0aGUgc2l6 ZSBvZgogICBhbnkgdmFsdWUgaXQgaXNzdWVzLgoKNC4xLjIuMS4gIEVycm9yIFJlc3BvbnNlCgog ICBJZiB0aGUgcmVxdWVzdCBmYWlscyBkdWUgdG8gYSBtaXNzaW5nLCBpbnZhbGlkLCBvciBtaXNt YXRjaGluZwogICByZWRpcmVjdGlvbiBVUkksIG9yIGlmIHRoZSBjbGllbnQgaWRlbnRpZmllciBp cyBtaXNzaW5nIG9yIGludmFsaWQsCiAgIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBTSE9VTEQg aW5mb3JtIHRoZSByZXNvdXJjZSBvd25lciBvZiB0aGUKICAgZXJyb3IsIGFuZCBNVVNUIE5PVCBh dXRvbWF0aWNhbGx5IHJlZGlyZWN0IHRoZSB1c2VyLWFnZW50IHRvIHRoZQogICBpbnZhbGlkIHJl ZGlyZWN0aW9uIFVSSS4KCiAgIElmIHRoZSByZXNvdXJjZSBvd25lciBkZW5pZXMgdGhlIGFjY2Vz cyByZXF1ZXN0IG9yIGlmIHRoZSByZXF1ZXN0CiAgIGZhaWxzIGZvciByZWFzb25zIG90aGVyIHRo YW4gYSBtaXNzaW5nIG9yIGludmFsaWQgcmVkaXJlY3Rpb24gVVJJLAogICB0aGUgYXV0aG9yaXph dGlvbiBzZXJ2ZXIgaW5mb3JtcyB0aGUgY2xpZW50IGJ5IGFkZGluZyB0aGUgZm9sbG93aW5nCiAg IHBhcmFtZXRlcnMgdG8gdGhlIHF1ZXJ5IGNvbXBvbmVudCBvZiB0aGUgcmVkaXJlY3Rpb24gVVJJ IHVzaW5nIHRoZQogICAiYXBwbGljYXRpb24veC13d3ctZm9ybS11cmxlbmNvZGVkIiBmb3JtYXQ6 CgogICBlcnJvcgogICAgICAgICBSRVFVSVJFRC4gIEEgc2luZ2xlIEFTQ0lJIFtVU0FTQ0lJXSBl cnJvciBjb2RlIGZyb20gdGhlCiAgICAgICAgIGZvbGxvd2luZzoKICAgICAgICAgaW52YWxpZF9y ZXF1ZXN0CiAgICAgICAgICAgICAgIFRoZSByZXF1ZXN0IGlzIG1pc3NpbmcgYSByZXF1aXJlZCBw YXJhbWV0ZXIsIGluY2x1ZGVzIGFuCiAgICAgICAgICAgICAgIGludmFsaWQgcGFyYW1ldGVyIHZh bHVlLCBpbmNsdWRlcyBhIHBhcmFtZXRlciBtb3JlIHRoYW4KICAgICAgICAgICAgICAgb25jZSwg b3IgaXMgb3RoZXJ3aXNlIG1hbGZvcm1lZC4KICAgICAgICAgdW5hdXRob3JpemVkX2NsaWVudAog ICAgICAgICAgICAgICBUaGUgY2xpZW50IGlzIG5vdCBhdXRob3JpemVkIHRvIHJlcXVlc3QgYW4g YXV0aG9yaXphdGlvbgogICAgICAgICAgICAgICBjb2RlIHVzaW5nIHRoaXMgbWV0aG9kLgoKCgoK CkhhbW1lciwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgRGVjZW1iZXIgNCwgMjAxMiAgICAgICAg ICAgICAgIFtQYWdlIDI2XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgT0F1dGgg Mi4wICAgICAgICAgICAgICAgICAgICAgIEp1bmUgMjAxMgoKCiAgICAgICAgIGFjY2Vzc19kZW5p ZWQKICAgICAgICAgICAgICAgVGhlIHJlc291cmNlIG93bmVyIG9yIGF1dGhvcml6YXRpb24gc2Vy dmVyIGRlbmllZCB0aGUKICAgICAgICAgICAgICAgcmVxdWVzdC4KICAgICAgICAgdW5zdXBwb3J0 ZWRfcmVzcG9uc2VfdHlwZQogICAgICAgICAgICAgICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIg ZG9lcyBub3Qgc3VwcG9ydCBvYnRhaW5pbmcgYW4KICAgICAgICAgICAgICAgYXV0aG9yaXphdGlv biBjb2RlIHVzaW5nIHRoaXMgbWV0aG9kLgogICAgICAgICBpbnZhbGlkX3Njb3BlCiAgICAgICAg ICAgICAgIFRoZSByZXF1ZXN0ZWQgc2NvcGUgaXMgaW52YWxpZCwgdW5rbm93biwgb3IgbWFsZm9y bWVkLgogICAgICAgICBzZXJ2ZXJfZXJyb3IKICAgICAgICAgICAgICAgVGhlIGF1dGhvcml6YXRp b24gc2VydmVyIGVuY291bnRlcmVkIGFuIHVuZXhwZWN0ZWQKICAgICAgICAgICAgICAgY29uZGl0 aW9uIHdoaWNoIHByZXZlbnRlZCBpdCBmcm9tIGZ1bGZpbGxpbmcgdGhlIHJlcXVlc3QuCiAgICAg ICAgIHRlbXBvcmFyaWx5X3VuYXZhaWxhYmxlCiAgICAgICAgICAgICAgIFRoZSBhdXRob3JpemF0 aW9uIHNlcnZlciBpcyBjdXJyZW50bHkgdW5hYmxlIHRvIGhhbmRsZQogICAgICAgICAgICAgICB0 aGUgcmVxdWVzdCBkdWUgdG8gYSB0ZW1wb3Jhcnkgb3ZlcmxvYWRpbmcgb3IgbWFpbnRlbmFuY2UK ICAgICAgICAgICAgICAgb2YgdGhlIHNlcnZlci4KICAgICAgICAgVmFsdWVzIGZvciB0aGUgImVy cm9yIiBwYXJhbWV0ZXIgTVVTVCBOT1QgaW5jbHVkZSBjaGFyYWN0ZXJzCiAgICAgICAgIG91dHNp ZGUgdGhlIHNldCAleDIwLTIxIC8gJXgyMy01QiAvICV4NUQtN0UuCiAgIGVycm9yX2Rlc2NyaXB0 aW9uCiAgICAgICAgIE9QVElPTkFMLiAgQSBodW1hbi1yZWFkYWJsZSBBU0NJSSBbVVNBU0NJSV0g dGV4dCBwcm92aWRpbmcKICAgICAgICAgYWRkaXRpb25hbCBpbmZvcm1hdGlvbiwgdXNlZCB0byBh c3Npc3QgdGhlIGNsaWVudCBkZXZlbG9wZXIgaW4KICAgICAgICAgdW5kZXJzdGFuZGluZyB0aGUg ZXJyb3IgdGhhdCBvY2N1cnJlZC4KICAgICAgICAgVmFsdWVzIGZvciB0aGUgImVycm9yX2Rlc2Ny aXB0aW9uIiBwYXJhbWV0ZXIgTVVTVCBOT1QgaW5jbHVkZQogICAgICAgICBjaGFyYWN0ZXJzIG91 dHNpZGUgdGhlIHNldCAleDIwLTIxIC8gJXgyMy01QiAvICV4NUQtN0UuCiAgIGVycm9yX3VyaQog ICAgICAgICBPUFRJT05BTC4gIEEgVVJJIGlkZW50aWZ5aW5nIGEgaHVtYW4tcmVhZGFibGUgd2Vi IHBhZ2Ugd2l0aAogICAgICAgICBpbmZvcm1hdGlvbiBhYm91dCB0aGUgZXJyb3IsIHVzZWQgdG8g cHJvdmlkZSB0aGUgY2xpZW50CiAgICAgICAgIGRldmVsb3BlciB3aXRoIGFkZGl0aW9uYWwgaW5m b3JtYXRpb24gYWJvdXQgdGhlIGVycm9yLgogICAgICAgICBWYWx1ZXMgZm9yIHRoZSAiZXJyb3Jf dXJpIiBwYXJhbWV0ZXIgTVVTVCBjb25mb3JtIHRvIHRoZSBVUkktCiAgICAgICAgIFJlZmVyZW5j ZSBzeW50YXgsIGFuZCB0aHVzIE1VU1QgTk9UIGluY2x1ZGUgY2hhcmFjdGVycyBvdXRzaWRlCiAg ICAgICAgIHRoZSBzZXQgJXgyMSAvICV4MjMtNUIgLyAleDVELTdFLgogICBzdGF0ZQogICAgICAg ICBSRVFVSVJFRCBpZiBhICJzdGF0ZSIgcGFyYW1ldGVyIHdhcyBwcmVzZW50IGluIHRoZSBjbGll bnQKICAgICAgICAgYXV0aG9yaXphdGlvbiByZXF1ZXN0LiAgVGhlIGV4YWN0IHZhbHVlIHJlY2Vp dmVkIGZyb20gdGhlCiAgICAgICAgIGNsaWVudC4KCiAgIEZvciBleGFtcGxlLCB0aGUgYXV0aG9y aXphdGlvbiBzZXJ2ZXIgcmVkaXJlY3RzIHRoZSB1c2VyLWFnZW50IGJ5CiAgIHNlbmRpbmcgdGhl IGZvbGxvd2luZyBIVFRQIHJlc3BvbnNlOgoKCiAgIEhUVFAvMS4xIDMwMiBGb3VuZAogICBMb2Nh dGlvbjogaHR0cHM6Ly9jbGllbnQuZXhhbXBsZS5jb20vY2I/ZXJyb3I9YWNjZXNzX2RlbmllZCZz dGF0ZT14eXoKCgo0LjEuMy4gIEFjY2VzcyBUb2tlbiBSZXF1ZXN0CgogICBUaGUgY2xpZW50IG1h a2VzIGEgcmVxdWVzdCB0byB0aGUgdG9rZW4gZW5kcG9pbnQgYnkgYWRkaW5nIHRoZQogICBmb2xs b3dpbmcgcGFyYW1ldGVycyB1c2luZyB0aGUgImFwcGxpY2F0aW9uL3gtd3d3LWZvcm0tdXJsZW5j b2RlZCIKICAgZm9ybWF0IGluIHRoZSBIVFRQIHJlcXVlc3QgZW50aXR5LWJvZHk6CgoKCkhhbW1l ciwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgRGVjZW1iZXIgNCwgMjAxMiAgICAgICAgICAgICAg IFtQYWdlIDI3XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgT0F1dGggMi4wICAg ICAgICAgICAgICAgICAgICAgIEp1bmUgMjAxMgoKCiAgIGdyYW50X3R5cGUKICAgICAgICAgUkVR VUlSRUQuICBWYWx1ZSBNVVNUIGJlIHNldCB0byAiYXV0aG9yaXphdGlvbl9jb2RlIi4KICAgY29k ZQogICAgICAgICBSRVFVSVJFRC4gIFRoZSBhdXRob3JpemF0aW9uIGNvZGUgcmVjZWl2ZWQgZnJv bSB0aGUKICAgICAgICAgYXV0aG9yaXphdGlvbiBzZXJ2ZXIuCiAgIHJlZGlyZWN0X3VyaQogICAg ICAgICBSRVFVSVJFRCwgaWYgdGhlICJyZWRpcmVjdF91cmkiIHBhcmFtZXRlciB3YXMgaW5jbHVk ZWQgaW4gdGhlCiAgICAgICAgIGF1dGhvcml6YXRpb24gcmVxdWVzdCBhcyBkZXNjcmliZWQgaW4g U2VjdGlvbiA0LjEuMSwgYW5kIHRoZWlyCiAgICAgICAgIHZhbHVlcyBNVVNUIGJlIGlkZW50aWNh bC4KCiAgIElmIHRoZSBjbGllbnQgdHlwZSBpcyBjb25maWRlbnRpYWwgb3IgdGhlIGNsaWVudCB3 YXMgaXNzdWVkIGNsaWVudAogICBjcmVkZW50aWFscyAob3IgYXNzaWduZWQgb3RoZXIgYXV0aGVu dGljYXRpb24gcmVxdWlyZW1lbnRzKSwgdGhlCiAgIGNsaWVudCBNVVNUIGF1dGhlbnRpY2F0ZSB3 aXRoIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBhcyBkZXNjcmliZWQKICAgaW4gU2VjdGlvbiAz LjIuMS4KCiAgIEZvciBleGFtcGxlLCB0aGUgY2xpZW50IG1ha2VzIHRoZSBmb2xsb3dpbmcgSFRU UCByZXF1ZXN0IHVzaW5nIFRMUwogICAoZXh0cmEgbGluZSBicmVha3MgYXJlIGZvciBkaXNwbGF5 IHB1cnBvc2VzIG9ubHkpOgoKCiAgICAgUE9TVCAvdG9rZW4gSFRUUC8xLjEKICAgICBIb3N0OiBz ZXJ2ZXIuZXhhbXBsZS5jb20KICAgICBBdXRob3JpemF0aW9uOiBCYXNpYyBjelpDYUdSU2EzRjBN enBuV0RGbVFtRjBNMkpXCiAgICAgQ29udGVudC1UeXBlOiBhcHBsaWNhdGlvbi94LXd3dy1mb3Jt LXVybGVuY29kZWQ7Y2hhcnNldD1VVEYtOAoKICAgICBncmFudF90eXBlPWF1dGhvcml6YXRpb25f Y29kZSZjb2RlPVNwbHhsT0JlWlFRWWJZUzZXeFNiSUEKICAgICAmcmVkaXJlY3RfdXJpPWh0dHBz JTNBJTJGJTJGY2xpZW50JTJFZXhhbXBsZSUyRWNvbSUyRmNiCgoKICAgVGhlIGF1dGhvcml6YXRp b24gc2VydmVyIE1VU1Q6CgogICBvICByZXF1aXJlIGNsaWVudCBhdXRoZW50aWNhdGlvbiBmb3Ig Y29uZmlkZW50aWFsIGNsaWVudHMgb3IgZm9yIGFueQogICAgICBjbGllbnQgdGhhdCB3YXMgaXNz dWVkIGNsaWVudCBjcmVkZW50aWFscyAob3Igd2l0aCBvdGhlcgogICAgICBhdXRoZW50aWNhdGlv biByZXF1aXJlbWVudHMpLAogICBvICBhdXRoZW50aWNhdGUgdGhlIGNsaWVudCBpZiBjbGllbnQg YXV0aGVudGljYXRpb24gaXMgaW5jbHVkZWQgYW5kCiAgICAgIGVuc3VyZSB0aGUgYXV0aG9yaXph dGlvbiBjb2RlIHdhcyBpc3N1ZWQgdG8gdGhlIGF1dGhlbnRpY2F0ZWQKICAgICAgY2xpZW50LAog ICBvICB2ZXJpZnkgdGhhdCB0aGUgYXV0aG9yaXphdGlvbiBjb2RlIGlzIHZhbGlkLCBhbmQKICAg byAgZW5zdXJlIHRoYXQgdGhlICJyZWRpcmVjdF91cmkiIHBhcmFtZXRlciBpcyBwcmVzZW50IGlm IHRoZQogICAgICAicmVkaXJlY3RfdXJpIiBwYXJhbWV0ZXIgd2FzIGluY2x1ZGVkIGluIHRoZSBp bml0aWFsIGF1dGhvcml6YXRpb24KICAgICAgcmVxdWVzdCBhcyBkZXNjcmliZWQgaW4gU2VjdGlv biA0LjEuMSwgYW5kIGlmIGluY2x1ZGVkIGVuc3VyZQogICAgICB0aGVpciB2YWx1ZXMgYXJlIGlk ZW50aWNhbC4KCjQuMS40LiAgQWNjZXNzIFRva2VuIFJlc3BvbnNlCgogICBJZiB0aGUgYWNjZXNz IHRva2VuIHJlcXVlc3QgaXMgdmFsaWQgYW5kIGF1dGhvcml6ZWQsIHRoZQogICBhdXRob3JpemF0 aW9uIHNlcnZlciBpc3N1ZXMgYW4gYWNjZXNzIHRva2VuIGFuZCBvcHRpb25hbCByZWZyZXNoCiAg IHRva2VuIGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDUuMS4gIElmIHRoZSByZXF1ZXN0IGNsaWVu dAogICBhdXRoZW50aWNhdGlvbiBmYWlsZWQgb3IgaXMgaW52YWxpZCwgdGhlIGF1dGhvcml6YXRp b24gc2VydmVyIHJldHVybnMKCgoKSGFtbWVyLCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBEZWNl bWJlciA0LCAyMDEyICAgICAgICAgICAgICAgW1BhZ2UgMjhdCgwKSW50ZXJuZXQtRHJhZnQgICAg ICAgICAgICAgICAgICBPQXV0aCAyLjAgICAgICAgICAgICAgICAgICAgICAgSnVuZSAyMDEyCgoK ICAgYW4gZXJyb3IgcmVzcG9uc2UgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gNS4yLgoKICAgQW4g ZXhhbXBsZSBzdWNjZXNzZnVsIHJlc3BvbnNlOgoKCiAgICAgSFRUUC8xLjEgMjAwIE9LCiAgICAg Q29udGVudC1UeXBlOiBhcHBsaWNhdGlvbi9qc29uO2NoYXJzZXQ9VVRGLTgKICAgICBDYWNoZS1D b250cm9sOiBuby1zdG9yZQogICAgIFByYWdtYTogbm8tY2FjaGUKCiAgICAgewogICAgICAgImFj Y2Vzc190b2tlbiI6IjJZb3RuRlpGRWpyMXpDc2ljTVdwQUEiLAogICAgICAgInRva2VuX3R5cGUi OiJleGFtcGxlIiwKICAgICAgICJleHBpcmVzX2luIjozNjAwLAogICAgICAgInJlZnJlc2hfdG9r ZW4iOiJ0R3p2M0pPa0YwWEc1UXgyVGxLV0lBIiwKICAgICAgICJleGFtcGxlX3BhcmFtZXRlciI6 ImV4YW1wbGVfdmFsdWUiCiAgICAgfQoKCjQuMi4gIEltcGxpY2l0IEdyYW50CgogICBUaGUgaW1w bGljaXQgZ3JhbnQgdHlwZSBpcyB1c2VkIHRvIG9idGFpbiBhY2Nlc3MgdG9rZW5zIChpdCBkb2Vz IG5vdAogICBzdXBwb3J0IHRoZSBpc3N1YW5jZSBvZiByZWZyZXNoIHRva2VucykgYW5kIGlzIG9w dGltaXplZCBmb3IgcHVibGljCiAgIGNsaWVudHMga25vd24gdG8gb3BlcmF0ZSBhIHBhcnRpY3Vs YXIgcmVkaXJlY3Rpb24gVVJJLiAgVGhlc2UgY2xpZW50cwogICBhcmUgdHlwaWNhbGx5IGltcGxl bWVudGVkIGluIGEgYnJvd3NlciB1c2luZyBhIHNjcmlwdGluZyBsYW5ndWFnZQogICBzdWNoIGFz IEphdmFTY3JpcHQuCgogICBBcyBhIHJlZGlyZWN0aW9uLWJhc2VkIGZsb3csIHRoZSBjbGllbnQg bXVzdCBiZSBjYXBhYmxlIG9mCiAgIGludGVyYWN0aW5nIHdpdGggdGhlIHJlc291cmNlIG93bmVy J3MgdXNlci1hZ2VudCAodHlwaWNhbGx5IGEgd2ViCiAgIGJyb3dzZXIpIGFuZCBjYXBhYmxlIG9m IHJlY2VpdmluZyBpbmNvbWluZyByZXF1ZXN0cyAodmlhIHJlZGlyZWN0aW9uKQogICBmcm9tIHRo ZSBhdXRob3JpemF0aW9uIHNlcnZlci4KCiAgIFVubGlrZSB0aGUgYXV0aG9yaXphdGlvbiBjb2Rl IGdyYW50IHR5cGUgaW4gd2hpY2ggdGhlIGNsaWVudCBtYWtlcwogICBzZXBhcmF0ZSByZXF1ZXN0 cyBmb3IgYXV0aG9yaXphdGlvbiBhbmQgYWNjZXNzIHRva2VuLCB0aGUgY2xpZW50CiAgIHJlY2Vp dmVzIHRoZSBhY2Nlc3MgdG9rZW4gYXMgdGhlIHJlc3VsdCBvZiB0aGUgYXV0aG9yaXphdGlvbiBy ZXF1ZXN0LgoKICAgVGhlIGltcGxpY2l0IGdyYW50IHR5cGUgZG9lcyBub3QgaW5jbHVkZSBjbGll bnQgYXV0aGVudGljYXRpb24sIGFuZAogICByZWxpZXMgb24gdGhlIHByZXNlbmNlIG9mIHRoZSBy ZXNvdXJjZSBvd25lciBhbmQgdGhlIHJlZ2lzdHJhdGlvbiBvZgogICB0aGUgcmVkaXJlY3Rpb24g VVJJLiAgQmVjYXVzZSB0aGUgYWNjZXNzIHRva2VuIGlzIGVuY29kZWQgaW50byB0aGUKICAgcmVk aXJlY3Rpb24gVVJJLCBpdCBtYXkgYmUgZXhwb3NlZCB0byB0aGUgcmVzb3VyY2Ugb3duZXIgYW5k IG90aGVyCiAgIGFwcGxpY2F0aW9ucyByZXNpZGluZyBvbiB0aGUgc2FtZSBkZXZpY2UuCgoKCgoK CgoKCgpIYW1tZXIsIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIERlY2VtYmVyIDQsIDIwMTIgICAg ICAgICAgICAgICBbUGFnZSAyOV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgIE9B dXRoIDIuMCAgICAgICAgICAgICAgICAgICAgICBKdW5lIDIwMTIKCgogICAgICstLS0tLS0tLS0t KwogICAgIHwgUmVzb3VyY2UgfAogICAgIHwgIE93bmVyICAgfAogICAgIHwgICAgICAgICAgfAog ICAgICstLS0tLS0tLS0tKwogICAgICAgICAgXgogICAgICAgICAgfAogICAgICAgICAoQikKICAg ICArLS0tLXwtLS0tLSsgICAgICAgICAgQ2xpZW50IElkZW50aWZpZXIgICAgICstLS0tLS0tLS0t LS0tLS0rCiAgICAgfCAgICAgICAgIC0rLS0tLShBKS0tICYgUmVkaXJlY3Rpb24gVVJJIC0tLT58 ICAgICAgICAgICAgICAgfAogICAgIHwgIFVzZXItICAgfCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfCBBdXRob3JpemF0aW9uIHwKICAgICB8ICBBZ2VudCAgLXwtLS0tKEIpLS0gVXNl ciBhdXRoZW50aWNhdGVzIC0tPnwgICAgIFNlcnZlciAgICB8CiAgICAgfCAgICAgICAgICB8ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgfAogICAgIHwgICAg ICAgICAgfDwtLS0oQyktLS0gUmVkaXJlY3Rpb24gVVJJIC0tLS08fCAgICAgICAgICAgICAgIHwK ICAgICB8ICAgICAgICAgIHwgICAgICAgICAgd2l0aCBBY2Nlc3MgVG9rZW4gICAgICstLS0tLS0t LS0tLS0tLS0rCiAgICAgfCAgICAgICAgICB8ICAgICAgICAgICAgaW4gRnJhZ21lbnQKICAgICB8 ICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0t LS0rCiAgICAgfCAgICAgICAgICB8LS0tLShEKS0tLSBSZWRpcmVjdGlvbiBVUkkgLS0tLT58ICAg V2ViLUhvc3RlZCAgfAogICAgIHwgICAgICAgICAgfCAgICAgICAgICB3aXRob3V0IEZyYWdtZW50 ICAgICAgfCAgICAgQ2xpZW50ICAgIHwKICAgICB8ICAgICAgICAgIHwgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHwgICAgUmVzb3VyY2UgICB8CiAgICAgfCAgICAgKEYpICB8PC0tLShF KS0tLS0tLS0gU2NyaXB0IC0tLS0tLS0tLTx8ICAgICAgICAgICAgICAgfAogICAgIHwgICAgICAg ICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLSsKICAg ICArLXwtLS0tLS0tLSsKICAgICAgIHwgICAgfAogICAgICAoQSkgIChHKSBBY2Nlc3MgVG9rZW4K ICAgICAgIHwgICAgfAogICAgICAgXiAgICB2CiAgICAgKy0tLS0tLS0tLSsKICAgICB8ICAgICAg ICAgfAogICAgIHwgIENsaWVudCB8CiAgICAgfCAgICAgICAgIHwKICAgICArLS0tLS0tLS0tKwoK CiAgIE5vdGU6IFRoZSBsaW5lcyBpbGx1c3RyYXRpbmcgc3RlcHMgQSBhbmQgQiBhcmUgYnJva2Vu IGludG8gdHdvIHBhcnRzCiAgIGFzIHRoZXkgcGFzcyB0aHJvdWdoIHRoZSB1c2VyLWFnZW50LgoK ICAgICAgICAgICAgICAgICAgICAgICBGaWd1cmUgNDogSW1wbGljaXQgR3JhbnQgRmxvdwoKICAg VGhlIGZsb3cgaWxsdXN0cmF0ZWQgaW4gRmlndXJlIDQgaW5jbHVkZXMgdGhlIGZvbGxvd2luZyBz dGVwczoKCiAgIChBKSAgVGhlIGNsaWVudCBpbml0aWF0ZXMgdGhlIGZsb3cgYnkgZGlyZWN0aW5n IHRoZSByZXNvdXJjZSBvd25lcidzCiAgICAgICAgdXNlci1hZ2VudCB0byB0aGUgYXV0aG9yaXph dGlvbiBlbmRwb2ludC4gIFRoZSBjbGllbnQgaW5jbHVkZXMKICAgICAgICBpdHMgY2xpZW50IGlk ZW50aWZpZXIsIHJlcXVlc3RlZCBzY29wZSwgbG9jYWwgc3RhdGUsIGFuZCBhCiAgICAgICAgcmVk aXJlY3Rpb24gVVJJIHRvIHdoaWNoIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciB3aWxsIHNlbmQg dGhlCiAgICAgICAgdXNlci1hZ2VudCBiYWNrIG9uY2UgYWNjZXNzIGlzIGdyYW50ZWQgKG9yIGRl bmllZCkuCgoKCgoKSGFtbWVyLCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBEZWNlbWJlciA0LCAy MDEyICAgICAgICAgICAgICAgW1BhZ2UgMzBdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAg ICAgICBPQXV0aCAyLjAgICAgICAgICAgICAgICAgICAgICAgSnVuZSAyMDEyCgoKICAgKEIpICBU aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYXV0aGVudGljYXRlcyB0aGUgcmVzb3VyY2Ugb3duZXIg KHZpYQogICAgICAgIHRoZSB1c2VyLWFnZW50KSBhbmQgZXN0YWJsaXNoZXMgd2hldGhlciB0aGUg cmVzb3VyY2Ugb3duZXIKICAgICAgICBncmFudHMgb3IgZGVuaWVzIHRoZSBjbGllbnQncyBhY2Nl c3MgcmVxdWVzdC4KICAgKEMpICBBc3N1bWluZyB0aGUgcmVzb3VyY2Ugb3duZXIgZ3JhbnRzIGFj Y2VzcywgdGhlIGF1dGhvcml6YXRpb24KICAgICAgICBzZXJ2ZXIgcmVkaXJlY3RzIHRoZSB1c2Vy LWFnZW50IGJhY2sgdG8gdGhlIGNsaWVudCB1c2luZyB0aGUKICAgICAgICByZWRpcmVjdGlvbiBV UkkgcHJvdmlkZWQgZWFybGllci4gIFRoZSByZWRpcmVjdGlvbiBVUkkgaW5jbHVkZXMKICAgICAg ICB0aGUgYWNjZXNzIHRva2VuIGluIHRoZSBVUkkgZnJhZ21lbnQuCiAgIChEKSAgVGhlIHVzZXIt YWdlbnQgZm9sbG93cyB0aGUgcmVkaXJlY3Rpb24gaW5zdHJ1Y3Rpb25zIGJ5IG1ha2luZyBhCiAg ICAgICAgcmVxdWVzdCB0byB0aGUgd2ViLWhvc3RlZCBjbGllbnQgcmVzb3VyY2UgKHdoaWNoIGRv ZXMgbm90CiAgICAgICAgaW5jbHVkZSB0aGUgZnJhZ21lbnQgcGVyIFtSRkMyNjE2XSkuICBUaGUg dXNlci1hZ2VudCByZXRhaW5zIHRoZQogICAgICAgIGZyYWdtZW50IGluZm9ybWF0aW9uIGxvY2Fs bHkuCiAgIChFKSAgVGhlIHdlYi1ob3N0ZWQgY2xpZW50IHJlc291cmNlIHJldHVybnMgYSB3ZWIg cGFnZSAodHlwaWNhbGx5IGFuCiAgICAgICAgSFRNTCBkb2N1bWVudCB3aXRoIGFuIGVtYmVkZGVk IHNjcmlwdCkgY2FwYWJsZSBvZiBhY2Nlc3NpbmcgdGhlCiAgICAgICAgZnVsbCByZWRpcmVjdGlv biBVUkkgaW5jbHVkaW5nIHRoZSBmcmFnbWVudCByZXRhaW5lZCBieSB0aGUKICAgICAgICB1c2Vy LWFnZW50LCBhbmQgZXh0cmFjdGluZyB0aGUgYWNjZXNzIHRva2VuIChhbmQgb3RoZXIKICAgICAg ICBwYXJhbWV0ZXJzKSBjb250YWluZWQgaW4gdGhlIGZyYWdtZW50LgogICAoRikgIFRoZSB1c2Vy LWFnZW50IGV4ZWN1dGVzIHRoZSBzY3JpcHQgcHJvdmlkZWQgYnkgdGhlIHdlYi1ob3N0ZWQKICAg ICAgICBjbGllbnQgcmVzb3VyY2UgbG9jYWxseSwgd2hpY2ggZXh0cmFjdHMgdGhlIGFjY2VzcyB0 b2tlbiBhbmQKICAgICAgICBwYXNzZXMgaXQgdG8gdGhlIGNsaWVudC4KCjQuMi4xLiAgQXV0aG9y aXphdGlvbiBSZXF1ZXN0CgogICBUaGUgY2xpZW50IGNvbnN0cnVjdHMgdGhlIHJlcXVlc3QgVVJJ IGJ5IGFkZGluZyB0aGUgZm9sbG93aW5nCiAgIHBhcmFtZXRlcnMgdG8gdGhlIHF1ZXJ5IGNvbXBv bmVudCBvZiB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludCBVUkkKICAgdXNpbmcgdGhlICJhcHBs aWNhdGlvbi94LXd3dy1mb3JtLXVybGVuY29kZWQiIGZvcm1hdDoKCiAgIHJlc3BvbnNlX3R5cGUK ICAgICAgICAgUkVRVUlSRUQuICBWYWx1ZSBNVVNUIGJlIHNldCB0byAidG9rZW4iLgogICBjbGll bnRfaWQKICAgICAgICAgUkVRVUlSRUQuICBUaGUgY2xpZW50IGlkZW50aWZpZXIgYXMgZGVzY3Jp YmVkIGluIFNlY3Rpb24gMi4yLgogICByZWRpcmVjdF91cmkKICAgICAgICAgT1BUSU9OQUwuICBB cyBkZXNjcmliZWQgaW4gU2VjdGlvbiAzLjEuMi4KICAgc2NvcGUKICAgICAgICAgT1BUSU9OQUwu ICBUaGUgc2NvcGUgb2YgdGhlIGFjY2VzcyByZXF1ZXN0IGFzIGRlc2NyaWJlZCBieQogICAgICAg ICBTZWN0aW9uIDMuMy4KICAgc3RhdGUKICAgICAgICAgUkVDT01NRU5ERUQuICBBbiBvcGFxdWUg dmFsdWUgdXNlZCBieSB0aGUgY2xpZW50IHRvIG1haW50YWluCiAgICAgICAgIHN0YXRlIGJldHdl ZW4gdGhlIHJlcXVlc3QgYW5kIGNhbGxiYWNrLiAgVGhlIGF1dGhvcml6YXRpb24KICAgICAgICAg c2VydmVyIGluY2x1ZGVzIHRoaXMgdmFsdWUgd2hlbiByZWRpcmVjdGluZyB0aGUgdXNlci1hZ2Vu dCBiYWNrCiAgICAgICAgIHRvIHRoZSBjbGllbnQuICBUaGUgcGFyYW1ldGVyIFNIT1VMRCBiZSB1 c2VkIGZvciBwcmV2ZW50aW5nCiAgICAgICAgIGNyb3NzLXNpdGUgcmVxdWVzdCBmb3JnZXJ5IGFz IGRlc2NyaWJlZCBpbiBTZWN0aW9uIDEwLjEyLgoKICAgVGhlIGNsaWVudCBkaXJlY3RzIHRoZSBy ZXNvdXJjZSBvd25lciB0byB0aGUgY29uc3RydWN0ZWQgVVJJIHVzaW5nIGFuCiAgIEhUVFAgcmVk aXJlY3Rpb24gcmVzcG9uc2UsIG9yIGJ5IG90aGVyIG1lYW5zIGF2YWlsYWJsZSB0byBpdCB2aWEg dGhlCiAgIHVzZXItYWdlbnQuCgoKCgoKCkhhbW1lciwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMg RGVjZW1iZXIgNCwgMjAxMiAgICAgICAgICAgICAgIFtQYWdlIDMxXQoMCkludGVybmV0LURyYWZ0 ICAgICAgICAgICAgICAgICAgT0F1dGggMi4wICAgICAgICAgICAgICAgICAgICAgIEp1bmUgMjAx MgoKCiAgIEZvciBleGFtcGxlLCB0aGUgY2xpZW50IGRpcmVjdHMgdGhlIHVzZXItYWdlbnQgdG8g bWFrZSB0aGUgZm9sbG93aW5nCiAgIEhUVFAgcmVxdWVzdCB1c2luZyBUTFMgKGV4dHJhIGxpbmUg YnJlYWtzIGFyZSBmb3IgZGlzcGxheSBwdXJwb3NlcwogICBvbmx5KToKCgogICAgR0VUIC9hdXRo b3JpemU/cmVzcG9uc2VfdHlwZT10b2tlbiZjbGllbnRfaWQ9czZCaGRSa3F0MyZzdGF0ZT14eXoK ICAgICAgICAmcmVkaXJlY3RfdXJpPWh0dHBzJTNBJTJGJTJGY2xpZW50JTJFZXhhbXBsZSUyRWNv bSUyRmNiIEhUVFAvMS4xCiAgICBIb3N0OiBzZXJ2ZXIuZXhhbXBsZS5jb20KCgogICBUaGUgYXV0 aG9yaXphdGlvbiBzZXJ2ZXIgdmFsaWRhdGVzIHRoZSByZXF1ZXN0IHRvIGVuc3VyZSBhbGwgcmVx dWlyZWQKICAgcGFyYW1ldGVycyBhcmUgcHJlc2VudCBhbmQgdmFsaWQuICBUaGUgYXV0aG9yaXph dGlvbiBzZXJ2ZXIgTVVTVAogICB2ZXJpZnkgdGhhdCB0aGUgcmVkaXJlY3Rpb24gVVJJIHRvIHdo aWNoIGl0IHdpbGwgcmVkaXJlY3QgdGhlIGFjY2VzcwogICB0b2tlbiBtYXRjaGVzIGEgcmVkaXJl Y3Rpb24gVVJJIHJlZ2lzdGVyZWQgYnkgdGhlIGNsaWVudCBhcyBkZXNjcmliZWQKICAgaW4gU2Vj dGlvbiAzLjEuMi4KCiAgIElmIHRoZSByZXF1ZXN0IGlzIHZhbGlkLCB0aGUgYXV0aG9yaXphdGlv biBzZXJ2ZXIgYXV0aGVudGljYXRlcyB0aGUKICAgcmVzb3VyY2Ugb3duZXIgYW5kIG9idGFpbnMg YW4gYXV0aG9yaXphdGlvbiBkZWNpc2lvbiAoYnkgYXNraW5nIHRoZQogICByZXNvdXJjZSBvd25l ciBvciBieSBlc3RhYmxpc2hpbmcgYXBwcm92YWwgdmlhIG90aGVyIG1lYW5zKS4KCiAgIFdoZW4g YSBkZWNpc2lvbiBpcyBlc3RhYmxpc2hlZCwgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGRpcmVj dHMgdGhlCiAgIHVzZXItYWdlbnQgdG8gdGhlIHByb3ZpZGVkIGNsaWVudCByZWRpcmVjdGlvbiBV UkkgdXNpbmcgYW4gSFRUUAogICByZWRpcmVjdGlvbiByZXNwb25zZSwgb3IgYnkgb3RoZXIgbWVh bnMgYXZhaWxhYmxlIHRvIGl0IHZpYSB0aGUgdXNlci0KICAgYWdlbnQuCgo0LjIuMi4gIEFjY2Vz cyBUb2tlbiBSZXNwb25zZQoKICAgSWYgdGhlIHJlc291cmNlIG93bmVyIGdyYW50cyB0aGUgYWNj ZXNzIHJlcXVlc3QsIHRoZSBhdXRob3JpemF0aW9uCiAgIHNlcnZlciBpc3N1ZXMgYW4gYWNjZXNz IHRva2VuIGFuZCBkZWxpdmVycyBpdCB0byB0aGUgY2xpZW50IGJ5IGFkZGluZwogICB0aGUgZm9s bG93aW5nIHBhcmFtZXRlcnMgdG8gdGhlIGZyYWdtZW50IGNvbXBvbmVudCBvZiB0aGUgcmVkaXJl Y3Rpb24KICAgVVJJIHVzaW5nIHRoZSAiYXBwbGljYXRpb24veC13d3ctZm9ybS11cmxlbmNvZGVk IiBmb3JtYXQ6CgogICBhY2Nlc3NfdG9rZW4KICAgICAgICAgUkVRVUlSRUQuICBUaGUgYWNjZXNz IHRva2VuIGlzc3VlZCBieSB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIuCiAgIHRva2VuX3R5cGUK ICAgICAgICAgUkVRVUlSRUQuICBUaGUgdHlwZSBvZiB0aGUgdG9rZW4gaXNzdWVkIGFzIGRlc2Ny aWJlZCBpbgogICAgICAgICBTZWN0aW9uIDcuMS4gIFZhbHVlIGlzIGNhc2UgaW5zZW5zaXRpdmUu CiAgIGV4cGlyZXNfaW4KICAgICAgICAgUkVDT01NRU5ERUQuICBUaGUgbGlmZXRpbWUgaW4gc2Vj b25kcyBvZiB0aGUgYWNjZXNzIHRva2VuLiAgRm9yCiAgICAgICAgIGV4YW1wbGUsIHRoZSB2YWx1 ZSAiMzYwMCIgZGVub3RlcyB0aGF0IHRoZSBhY2Nlc3MgdG9rZW4gd2lsbAogICAgICAgICBleHBp cmUgaW4gb25lIGhvdXIgZnJvbSB0aGUgdGltZSB0aGUgcmVzcG9uc2Ugd2FzIGdlbmVyYXRlZC4K ICAgICAgICAgSWYgb21pdHRlZCwgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIFNIT1VMRCBwcm92 aWRlIHRoZQogICAgICAgICBleHBpcmF0aW9uIHRpbWUgdmlhIG90aGVyIG1lYW5zIG9yIGRvY3Vt ZW50IHRoZSBkZWZhdWx0IHZhbHVlLgogICBzY29wZQogICAgICAgICBPUFRJT05BTCwgaWYgaWRl bnRpY2FsIHRvIHRoZSBzY29wZSByZXF1ZXN0ZWQgYnkgdGhlIGNsaWVudCwKICAgICAgICAgb3Ro ZXJ3aXNlIFJFUVVJUkVELiAgVGhlIHNjb3BlIG9mIHRoZSBhY2Nlc3MgdG9rZW4gYXMgZGVzY3Jp YmVkCiAgICAgICAgIGJ5IFNlY3Rpb24gMy4zLgoKCgoKSGFtbWVyLCBldCBhbC4gICAgICAgICAg RXhwaXJlcyBEZWNlbWJlciA0LCAyMDEyICAgICAgICAgICAgICAgW1BhZ2UgMzJdCgwKSW50ZXJu ZXQtRHJhZnQgICAgICAgICAgICAgICAgICBPQXV0aCAyLjAgICAgICAgICAgICAgICAgICAgICAg SnVuZSAyMDEyCgoKICAgc3RhdGUKICAgICAgICAgUkVRVUlSRUQgaWYgdGhlICJzdGF0ZSIgcGFy YW1ldGVyIHdhcyBwcmVzZW50IGluIHRoZSBjbGllbnQKICAgICAgICAgYXV0aG9yaXphdGlvbiBy ZXF1ZXN0LiAgVGhlIGV4YWN0IHZhbHVlIHJlY2VpdmVkIGZyb20gdGhlCiAgICAgICAgIGNsaWVu dC4KCiAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBNVVNUIE5PVCBpc3N1ZSBhIHJlZnJlc2gg dG9rZW4uCgogICBGb3IgZXhhbXBsZSwgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHJlZGlyZWN0 cyB0aGUgdXNlci1hZ2VudCBieQogICBzZW5kaW5nIHRoZSBmb2xsb3dpbmcgSFRUUCByZXNwb25z ZSAoVVJJIGV4dHJhIGxpbmUgYnJlYWtzIGFyZSBmb3IKICAgZGlzcGxheSBwdXJwb3NlcyBvbmx5 KToKCgogICAgIEhUVFAvMS4xIDMwMiBGb3VuZAogICAgIExvY2F0aW9uOiBodHRwOi8vZXhhbXBs ZS5jb20vY2IjYWNjZXNzX3Rva2VuPTJZb3RuRlpGRWpyMXpDc2ljTVdwQUEKICAgICAgICAgICAg ICAgJnN0YXRlPXh5eiZ0b2tlbl90eXBlPWV4YW1wbGUmZXhwaXJlc19pbj0zNjAwCgoKICAgRGV2 ZWxvcGVycyBzaG91bGQgbm90ZSB0aGF0IHNvbWUgdXNlci1hZ2VudHMgZG8gbm90IHN1cHBvcnQg dGhlCiAgIGluY2x1c2lvbiBvZiBhIGZyYWdtZW50IGNvbXBvbmVudCBpbiB0aGUgSFRUUCAiTG9j YXRpb24iIHJlc3BvbnNlCiAgIGhlYWRlciBmaWVsZC4gIFN1Y2ggY2xpZW50cyB3aWxsIHJlcXVp cmUgdXNpbmcgb3RoZXIgbWV0aG9kcyBmb3IKICAgcmVkaXJlY3RpbmcgdGhlIGNsaWVudCB0aGFu IGEgM3h4IHJlZGlyZWN0aW9uIHJlc3BvbnNlLiAgRm9yIGV4YW1wbGUsCiAgIHJldHVybmluZyBh biBIVE1MIHBhZ2Ugd2hpY2ggaW5jbHVkZXMgYSAnY29udGludWUnIGJ1dHRvbiB3aXRoIGFuCiAg IGFjdGlvbiBsaW5rZWQgdG8gdGhlIHJlZGlyZWN0aW9uIFVSSS4KCiAgIFRoZSBjbGllbnQgTVVT VCBpZ25vcmUgdW5yZWNvZ25pemVkIHJlc3BvbnNlIHBhcmFtZXRlcnMuICBUaGUgYWNjZXNzCiAg IHRva2VuIHN0cmluZyBzaXplIGlzIGxlZnQgdW5kZWZpbmVkIGJ5IHRoaXMgc3BlY2lmaWNhdGlv bi4gIFRoZQogICBjbGllbnQgc2hvdWxkIGF2b2lkIG1ha2luZyBhc3N1bXB0aW9ucyBhYm91dCB2 YWx1ZSBzaXplcy4gIFRoZQogICBhdXRob3JpemF0aW9uIHNlcnZlciBTSE9VTEQgZG9jdW1lbnQg dGhlIHNpemUgb2YgYW55IHZhbHVlIGl0IGlzc3Vlcy4KCjQuMi4yLjEuICBFcnJvciBSZXNwb25z ZQoKICAgSWYgdGhlIHJlcXVlc3QgZmFpbHMgZHVlIHRvIGEgbWlzc2luZywgaW52YWxpZCwgb3Ig bWlzbWF0Y2hpbmcKICAgcmVkaXJlY3Rpb24gVVJJLCBvciBpZiB0aGUgY2xpZW50IGlkZW50aWZp ZXIgaXMgbWlzc2luZyBvciBpbnZhbGlkLAogICB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgU0hP VUxEIGluZm9ybSB0aGUgcmVzb3VyY2Ugb3duZXIgb2YgdGhlCiAgIGVycm9yLCBhbmQgTVVTVCBO T1QgYXV0b21hdGljYWxseSByZWRpcmVjdCB0aGUgdXNlci1hZ2VudCB0byB0aGUKICAgaW52YWxp ZCByZWRpcmVjdGlvbiBVUkkuCgogICBJZiB0aGUgcmVzb3VyY2Ugb3duZXIgZGVuaWVzIHRoZSBh Y2Nlc3MgcmVxdWVzdCBvciBpZiB0aGUgcmVxdWVzdAogICBmYWlscyBmb3IgcmVhc29ucyBvdGhl ciB0aGFuIGEgbWlzc2luZyBvciBpbnZhbGlkIHJlZGlyZWN0aW9uIFVSSSwKICAgdGhlIGF1dGhv cml6YXRpb24gc2VydmVyIGluZm9ybXMgdGhlIGNsaWVudCBieSBhZGRpbmcgdGhlIGZvbGxvd2lu ZwogICBwYXJhbWV0ZXJzIHRvIHRoZSBmcmFnbWVudCBjb21wb25lbnQgb2YgdGhlIHJlZGlyZWN0 aW9uIFVSSSB1c2luZyB0aGUKICAgImFwcGxpY2F0aW9uL3gtd3d3LWZvcm0tdXJsZW5jb2RlZCIg Zm9ybWF0OgoKICAgZXJyb3IKICAgICAgICAgUkVRVUlSRUQuICBBIHNpbmdsZSBBU0NJSSBbVVNB U0NJSV0gZXJyb3IgY29kZSBmcm9tIHRoZQogICAgICAgICBmb2xsb3dpbmc6CgoKCgoKSGFtbWVy LCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBEZWNlbWJlciA0LCAyMDEyICAgICAgICAgICAgICAg W1BhZ2UgMzNdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICBPQXV0aCAyLjAgICAg ICAgICAgICAgICAgICAgICAgSnVuZSAyMDEyCgoKICAgICAgICAgaW52YWxpZF9yZXF1ZXN0CiAg ICAgICAgICAgICAgIFRoZSByZXF1ZXN0IGlzIG1pc3NpbmcgYSByZXF1aXJlZCBwYXJhbWV0ZXIs IGluY2x1ZGVzIGFuCiAgICAgICAgICAgICAgIGludmFsaWQgcGFyYW1ldGVyIHZhbHVlLCBpbmNs dWRlcyBhIHBhcmFtZXRlciBtb3JlIHRoYW4KICAgICAgICAgICAgICAgb25jZSwgb3IgaXMgb3Ro ZXJ3aXNlIG1hbGZvcm1lZC4KICAgICAgICAgdW5hdXRob3JpemVkX2NsaWVudAogICAgICAgICAg ICAgICBUaGUgY2xpZW50IGlzIG5vdCBhdXRob3JpemVkIHRvIHJlcXVlc3QgYW4gYWNjZXNzIHRv a2VuCiAgICAgICAgICAgICAgIHVzaW5nIHRoaXMgbWV0aG9kLgogICAgICAgICBhY2Nlc3NfZGVu aWVkCiAgICAgICAgICAgICAgIFRoZSByZXNvdXJjZSBvd25lciBvciBhdXRob3JpemF0aW9uIHNl cnZlciBkZW5pZWQgdGhlCiAgICAgICAgICAgICAgIHJlcXVlc3QuCiAgICAgICAgIHVuc3VwcG9y dGVkX3Jlc3BvbnNlX3R5cGUKICAgICAgICAgICAgICAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVy IGRvZXMgbm90IHN1cHBvcnQgb2J0YWluaW5nIGFuCiAgICAgICAgICAgICAgIGFjY2VzcyB0b2tl biB1c2luZyB0aGlzIG1ldGhvZC4KICAgICAgICAgaW52YWxpZF9zY29wZQogICAgICAgICAgICAg ICBUaGUgcmVxdWVzdGVkIHNjb3BlIGlzIGludmFsaWQsIHVua25vd24sIG9yIG1hbGZvcm1lZC4K ICAgICAgICAgc2VydmVyX2Vycm9yCiAgICAgICAgICAgICAgIFRoZSBhdXRob3JpemF0aW9uIHNl cnZlciBlbmNvdW50ZXJlZCBhbiB1bmV4cGVjdGVkCiAgICAgICAgICAgICAgIGNvbmRpdGlvbiB3 aGljaCBwcmV2ZW50ZWQgaXQgZnJvbSBmdWxmaWxsaW5nIHRoZSByZXF1ZXN0LgogICAgICAgICB0 ZW1wb3JhcmlseV91bmF2YWlsYWJsZQogICAgICAgICAgICAgICBUaGUgYXV0aG9yaXphdGlvbiBz ZXJ2ZXIgaXMgY3VycmVudGx5IHVuYWJsZSB0byBoYW5kbGUKICAgICAgICAgICAgICAgdGhlIHJl cXVlc3QgZHVlIHRvIGEgdGVtcG9yYXJ5IG92ZXJsb2FkaW5nIG9yIG1haW50ZW5hbmNlCiAgICAg ICAgICAgICAgIG9mIHRoZSBzZXJ2ZXIuCiAgICAgICAgIFZhbHVlcyBmb3IgdGhlICJlcnJvciIg cGFyYW1ldGVyIE1VU1QgTk9UIGluY2x1ZGUgY2hhcmFjdGVycwogICAgICAgICBvdXRzaWRlIHRo ZSBzZXQgJXgyMC0yMSAvICV4MjMtNUIgLyAleDVELTdFLgogICBlcnJvcl9kZXNjcmlwdGlvbgog ICAgICAgICBPUFRJT05BTC4gIEEgaHVtYW4tcmVhZGFibGUgQVNDSUkgW1VTQVNDSUldIHRleHQg cHJvdmlkaW5nCiAgICAgICAgIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24sIHVzZWQgdG8gYXNzaXN0 IHRoZSBjbGllbnQgZGV2ZWxvcGVyIGluCiAgICAgICAgIHVuZGVyc3RhbmRpbmcgdGhlIGVycm9y IHRoYXQgb2NjdXJyZWQuCiAgICAgICAgIFZhbHVlcyBmb3IgdGhlICJlcnJvcl9kZXNjcmlwdGlv biIgcGFyYW1ldGVyIE1VU1QgTk9UIGluY2x1ZGUKICAgICAgICAgY2hhcmFjdGVycyBvdXRzaWRl IHRoZSBzZXQgJXgyMC0yMSAvICV4MjMtNUIgLyAleDVELTdFLgogICBlcnJvcl91cmkKICAgICAg ICAgT1BUSU9OQUwuICBBIFVSSSBpZGVudGlmeWluZyBhIGh1bWFuLXJlYWRhYmxlIHdlYiBwYWdl IHdpdGgKICAgICAgICAgaW5mb3JtYXRpb24gYWJvdXQgdGhlIGVycm9yLCB1c2VkIHRvIHByb3Zp ZGUgdGhlIGNsaWVudAogICAgICAgICBkZXZlbG9wZXIgd2l0aCBhZGRpdGlvbmFsIGluZm9ybWF0 aW9uIGFib3V0IHRoZSBlcnJvci4KICAgICAgICAgVmFsdWVzIGZvciB0aGUgImVycm9yX3VyaSIg cGFyYW1ldGVyIE1VU1QgY29uZm9ybSB0byB0aGUgVVJJLQogICAgICAgICBSZWZlcmVuY2Ugc3lu dGF4LCBhbmQgdGh1cyBNVVNUIE5PVCBpbmNsdWRlIGNoYXJhY3RlcnMgb3V0c2lkZQogICAgICAg ICB0aGUgc2V0ICV4MjEgLyAleDIzLTVCIC8gJXg1RC03RS4KICAgc3RhdGUKICAgICAgICAgUkVR VUlSRUQgaWYgYSAic3RhdGUiIHBhcmFtZXRlciB3YXMgcHJlc2VudCBpbiB0aGUgY2xpZW50CiAg ICAgICAgIGF1dGhvcml6YXRpb24gcmVxdWVzdC4gIFRoZSBleGFjdCB2YWx1ZSByZWNlaXZlZCBm cm9tIHRoZQogICAgICAgICBjbGllbnQuCgogICBGb3IgZXhhbXBsZSwgdGhlIGF1dGhvcml6YXRp b24gc2VydmVyIHJlZGlyZWN0cyB0aGUgdXNlci1hZ2VudCBieQogICBzZW5kaW5nIHRoZSBmb2xs b3dpbmcgSFRUUCByZXNwb25zZToKCgogICBIVFRQLzEuMSAzMDIgRm91bmQKICAgTG9jYXRpb246 IGh0dHBzOi8vY2xpZW50LmV4YW1wbGUuY29tL2NiI2Vycm9yPWFjY2Vzc19kZW5pZWQmc3RhdGU9 eHl6CgoKCkhhbW1lciwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgRGVjZW1iZXIgNCwgMjAxMiAg ICAgICAgICAgICAgIFtQYWdlIDM0XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAg T0F1dGggMi4wICAgICAgICAgICAgICAgICAgICAgIEp1bmUgMjAxMgoKCjQuMy4gIFJlc291cmNl IE93bmVyIFBhc3N3b3JkIENyZWRlbnRpYWxzIEdyYW50CgogICBUaGUgcmVzb3VyY2Ugb3duZXIg cGFzc3dvcmQgY3JlZGVudGlhbHMgZ3JhbnQgdHlwZSBpcyBzdWl0YWJsZSBpbgogICBjYXNlcyB3 aGVyZSB0aGUgcmVzb3VyY2Ugb3duZXIgaGFzIGEgdHJ1c3QgcmVsYXRpb25zaGlwIHdpdGggdGhl CiAgIGNsaWVudCwgc3VjaCBhcyB0aGUgZGV2aWNlIG9wZXJhdGluZyBzeXN0ZW0gb3IgYSBoaWdo bHkgcHJpdmlsZWdlZAogICBhcHBsaWNhdGlvbi4gIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBz aG91bGQgdGFrZSBzcGVjaWFsIGNhcmUgd2hlbgogICBlbmFibGluZyB0aGlzIGdyYW50IHR5cGUs IGFuZCBvbmx5IGFsbG93IGl0IHdoZW4gb3RoZXIgZmxvd3MgYXJlIG5vdAogICB2aWFibGUuCgog ICBUaGUgZ3JhbnQgdHlwZSBpcyBzdWl0YWJsZSBmb3IgY2xpZW50cyBjYXBhYmxlIG9mIG9idGFp bmluZyB0aGUKICAgcmVzb3VyY2Ugb3duZXIncyBjcmVkZW50aWFscyAodXNlcm5hbWUgYW5kIHBh c3N3b3JkLCB0eXBpY2FsbHkgdXNpbmcKICAgYW4gaW50ZXJhY3RpdmUgZm9ybSkuICBJdCBpcyBh bHNvIHVzZWQgdG8gbWlncmF0ZSBleGlzdGluZyBjbGllbnRzCiAgIHVzaW5nIGRpcmVjdCBhdXRo ZW50aWNhdGlvbiBzY2hlbWVzIHN1Y2ggYXMgSFRUUCBCYXNpYyBvciBEaWdlc3QKICAgYXV0aGVu dGljYXRpb24gdG8gT0F1dGggYnkgY29udmVydGluZyB0aGUgc3RvcmVkIGNyZWRlbnRpYWxzIHRv IGFuCiAgIGFjY2VzcyB0b2tlbi4KCgogICAgICstLS0tLS0tLS0tKwogICAgIHwgUmVzb3VyY2Ug fAogICAgIHwgIE93bmVyICAgfAogICAgIHwgICAgICAgICAgfAogICAgICstLS0tLS0tLS0tKwog ICAgICAgICAgdgogICAgICAgICAgfCAgICBSZXNvdXJjZSBPd25lcgogICAgICAgICAoQSkgUGFz c3dvcmQgQ3JlZGVudGlhbHMKICAgICAgICAgIHwKICAgICAgICAgIHYKICAgICArLS0tLS0tLS0t KyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tKwogICAg IHwgICAgICAgICB8Pi0tKEIpLS0tLSBSZXNvdXJjZSBPd25lciAtLS0tLS0tPnwgICAgICAgICAg ICAgICB8CiAgICAgfCAgICAgICAgIHwgICAgICAgICBQYXNzd29yZCBDcmVkZW50aWFscyAgICAg fCBBdXRob3JpemF0aW9uIHwKICAgICB8IENsaWVudCAgfCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB8ICAgICBTZXJ2ZXIgICAgfAogICAgIHwgICAgICAgICB8PC0tKEMpLS0tLSBB Y2Nlc3MgVG9rZW4gLS0tLS0tLS0tPHwgICAgICAgICAgICAgICB8CiAgICAgfCAgICAgICAgIHwg ICAgKHcvIE9wdGlvbmFsIFJlZnJlc2ggVG9rZW4pICAgfCAgICAgICAgICAgICAgIHwKICAgICAr LS0tLS0tLS0tKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0t LS0tKwoKCiAgICAgICAgICAgIEZpZ3VyZSA1OiBSZXNvdXJjZSBPd25lciBQYXNzd29yZCBDcmVk ZW50aWFscyBGbG93CgogICBUaGUgZmxvdyBpbGx1c3RyYXRlZCBpbiBGaWd1cmUgNSBpbmNsdWRl cyB0aGUgZm9sbG93aW5nIHN0ZXBzOgoKICAgKEEpICBUaGUgcmVzb3VyY2Ugb3duZXIgcHJvdmlk ZXMgdGhlIGNsaWVudCB3aXRoIGl0cyB1c2VybmFtZSBhbmQKICAgICAgICBwYXNzd29yZC4KICAg KEIpICBUaGUgY2xpZW50IHJlcXVlc3RzIGFuIGFjY2VzcyB0b2tlbiBmcm9tIHRoZSBhdXRob3Jp emF0aW9uCiAgICAgICAgc2VydmVyJ3MgdG9rZW4gZW5kcG9pbnQgYnkgaW5jbHVkaW5nIHRoZSBj cmVkZW50aWFscyByZWNlaXZlZAogICAgICAgIGZyb20gdGhlIHJlc291cmNlIG93bmVyLiAgV2hl biBtYWtpbmcgdGhlIHJlcXVlc3QsIHRoZSBjbGllbnQKICAgICAgICBhdXRoZW50aWNhdGVzIHdp dGggdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLgoKCgoKCkhhbW1lciwgZXQgYWwuICAgICAgICAg IEV4cGlyZXMgRGVjZW1iZXIgNCwgMjAxMiAgICAgICAgICAgICAgIFtQYWdlIDM1XQoMCkludGVy bmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgT0F1dGggMi4wICAgICAgICAgICAgICAgICAgICAg IEp1bmUgMjAxMgoKCiAgIChDKSAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGF1dGhlbnRpY2F0 ZXMgdGhlIGNsaWVudCBhbmQgdmFsaWRhdGVzCiAgICAgICAgdGhlIHJlc291cmNlIG93bmVyIGNy ZWRlbnRpYWxzLCBhbmQgaWYgdmFsaWQgaXNzdWVzIGFuIGFjY2VzcwogICAgICAgIHRva2VuLgoK NC4zLjEuICBBdXRob3JpemF0aW9uIFJlcXVlc3QgYW5kIFJlc3BvbnNlCgogICBUaGUgbWV0aG9k IHRocm91Z2ggd2hpY2ggdGhlIGNsaWVudCBvYnRhaW5zIHRoZSByZXNvdXJjZSBvd25lcgogICBj cmVkZW50aWFscyBpcyBiZXlvbmQgdGhlIHNjb3BlIG9mIHRoaXMgc3BlY2lmaWNhdGlvbi4gIFRo ZSBjbGllbnQKICAgTVVTVCBkaXNjYXJkIHRoZSBjcmVkZW50aWFscyBvbmNlIGFuIGFjY2VzcyB0 b2tlbiBoYXMgYmVlbiBvYnRhaW5lZC4KCjQuMy4yLiAgQWNjZXNzIFRva2VuIFJlcXVlc3QKCiAg IFRoZSBjbGllbnQgbWFrZXMgYSByZXF1ZXN0IHRvIHRoZSB0b2tlbiBlbmRwb2ludCBieSBhZGRp bmcgdGhlCiAgIGZvbGxvd2luZyBwYXJhbWV0ZXJzIHVzaW5nIHRoZSAiYXBwbGljYXRpb24veC13 d3ctZm9ybS11cmxlbmNvZGVkIgogICBmb3JtYXQgaW4gdGhlIEhUVFAgcmVxdWVzdCBlbnRpdHkt Ym9keToKCiAgIGdyYW50X3R5cGUKICAgICAgICAgUkVRVUlSRUQuICBWYWx1ZSBNVVNUIGJlIHNl dCB0byAicGFzc3dvcmQiLgogICB1c2VybmFtZQogICAgICAgICBSRVFVSVJFRC4gIFRoZSByZXNv dXJjZSBvd25lciB1c2VybmFtZSwgZW5jb2RlZCBhcyBVVEYtOC4KICAgcGFzc3dvcmQKICAgICAg ICAgUkVRVUlSRUQuICBUaGUgcmVzb3VyY2Ugb3duZXIgcGFzc3dvcmQsIGVuY29kZWQgYXMgVVRG LTguCiAgIHNjb3BlCiAgICAgICAgIE9QVElPTkFMLiAgVGhlIHNjb3BlIG9mIHRoZSBhY2Nlc3Mg cmVxdWVzdCBhcyBkZXNjcmliZWQgYnkKICAgICAgICAgU2VjdGlvbiAzLjMuCgogICBJZiB0aGUg Y2xpZW50IHR5cGUgaXMgY29uZmlkZW50aWFsIG9yIHRoZSBjbGllbnQgd2FzIGlzc3VlZCBjbGll bnQKICAgY3JlZGVudGlhbHMgKG9yIGFzc2lnbmVkIG90aGVyIGF1dGhlbnRpY2F0aW9uIHJlcXVp cmVtZW50cyksIHRoZQogICBjbGllbnQgTVVTVCBhdXRoZW50aWNhdGUgd2l0aCB0aGUgYXV0aG9y aXphdGlvbiBzZXJ2ZXIgYXMgZGVzY3JpYmVkCiAgIGluIFNlY3Rpb24gMy4yLjEuCgogICBGb3Ig ZXhhbXBsZSwgdGhlIGNsaWVudCBtYWtlcyB0aGUgZm9sbG93aW5nIEhUVFAgcmVxdWVzdCB1c2lu ZwogICB0cmFuc3BvcnQtbGF5ZXIgc2VjdXJpdHkgKGV4dHJhIGxpbmUgYnJlYWtzIGFyZSBmb3Ig ZGlzcGxheSBwdXJwb3NlcwogICBvbmx5KToKCgogICAgIFBPU1QgL3Rva2VuIEhUVFAvMS4xCiAg ICAgSG9zdDogc2VydmVyLmV4YW1wbGUuY29tCiAgICAgQXV0aG9yaXphdGlvbjogQmFzaWMgY3pa Q2FHUlNhM0YwTXpwbldERm1RbUYwTTJKVwogICAgIENvbnRlbnQtVHlwZTogYXBwbGljYXRpb24v eC13d3ctZm9ybS11cmxlbmNvZGVkO2NoYXJzZXQ9VVRGLTgKCiAgICAgZ3JhbnRfdHlwZT1wYXNz d29yZCZ1c2VybmFtZT1qb2huZG9lJnBhc3N3b3JkPUEzZGRqM3cKCgogICBUaGUgYXV0aG9yaXph dGlvbiBzZXJ2ZXIgTVVTVDoKCgoKCgoKSGFtbWVyLCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBE ZWNlbWJlciA0LCAyMDEyICAgICAgICAgICAgICAgW1BhZ2UgMzZdCgwKSW50ZXJuZXQtRHJhZnQg ICAgICAgICAgICAgICAgICBPQXV0aCAyLjAgICAgICAgICAgICAgICAgICAgICAgSnVuZSAyMDEy CgoKICAgbyAgcmVxdWlyZSBjbGllbnQgYXV0aGVudGljYXRpb24gZm9yIGNvbmZpZGVudGlhbCBj bGllbnRzIG9yIGZvciBhbnkKICAgICAgY2xpZW50IHRoYXQgd2FzIGlzc3VlZCBjbGllbnQgY3Jl ZGVudGlhbHMgKG9yIHdpdGggb3RoZXIKICAgICAgYXV0aGVudGljYXRpb24gcmVxdWlyZW1lbnRz KSwKICAgbyAgYXV0aGVudGljYXRlIHRoZSBjbGllbnQgaWYgY2xpZW50IGF1dGhlbnRpY2F0aW9u IGlzIGluY2x1ZGVkLCBhbmQKICAgbyAgdmFsaWRhdGUgdGhlIHJlc291cmNlIG93bmVyIHBhc3N3 b3JkIGNyZWRlbnRpYWxzIHVzaW5nIGl0cwogICAgICBleGlzdGluZyBwYXNzd29yZCB2YWxpZGF0 aW9uIGFsZ29yaXRobS4KCiAgIFNpbmNlIHRoaXMgYWNjZXNzIHRva2VuIHJlcXVlc3QgdXRpbGl6 ZXMgdGhlIHJlc291cmNlIG93bmVyJ3MKICAgcGFzc3dvcmQsIHRoZSBhdXRob3JpemF0aW9uIHNl cnZlciBNVVNUIHByb3RlY3QgdGhlIGVuZHBvaW50IGFnYWluc3QKICAgYnJ1dGUgZm9yY2UgYXR0 YWNrcyAoZS5nLiB1c2luZyByYXRlLWxpbWl0YXRpb24gb3IgZ2VuZXJhdGluZwogICBhbGVydHMp LgoKNC4zLjMuICBBY2Nlc3MgVG9rZW4gUmVzcG9uc2UKCiAgIElmIHRoZSBhY2Nlc3MgdG9rZW4g cmVxdWVzdCBpcyB2YWxpZCBhbmQgYXV0aG9yaXplZCwgdGhlCiAgIGF1dGhvcml6YXRpb24gc2Vy dmVyIGlzc3VlcyBhbiBhY2Nlc3MgdG9rZW4gYW5kIG9wdGlvbmFsIHJlZnJlc2gKICAgdG9rZW4g YXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gNS4xLiAgSWYgdGhlIHJlcXVlc3QgZmFpbGVkIGNsaWVu dAogICBhdXRoZW50aWNhdGlvbiBvciBpcyBpbnZhbGlkLCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2 ZXIgcmV0dXJucyBhbgogICBlcnJvciByZXNwb25zZSBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiA1 LjIuCgogICBBbiBleGFtcGxlIHN1Y2Nlc3NmdWwgcmVzcG9uc2U6CgoKICAgICBIVFRQLzEuMSAy MDAgT0sKICAgICBDb250ZW50LVR5cGU6IGFwcGxpY2F0aW9uL2pzb247Y2hhcnNldD1VVEYtOAog ICAgIENhY2hlLUNvbnRyb2w6IG5vLXN0b3JlCiAgICAgUHJhZ21hOiBuby1jYWNoZQoKICAgICB7 CiAgICAgICAiYWNjZXNzX3Rva2VuIjoiMllvdG5GWkZFanIxekNzaWNNV3BBQSIsCiAgICAgICAi dG9rZW5fdHlwZSI6ImV4YW1wbGUiLAogICAgICAgImV4cGlyZXNfaW4iOjM2MDAsCiAgICAgICAi cmVmcmVzaF90b2tlbiI6InRHenYzSk9rRjBYRzVReDJUbEtXSUEiLAogICAgICAgImV4YW1wbGVf cGFyYW1ldGVyIjoiZXhhbXBsZV92YWx1ZSIKICAgICB9CgoKNC40LiAgQ2xpZW50IENyZWRlbnRp YWxzIEdyYW50CgogICBUaGUgY2xpZW50IGNhbiByZXF1ZXN0IGFuIGFjY2VzcyB0b2tlbiB1c2lu ZyBvbmx5IGl0cyBjbGllbnQKICAgY3JlZGVudGlhbHMgKG9yIG90aGVyIHN1cHBvcnRlZCBtZWFu cyBvZiBhdXRoZW50aWNhdGlvbikgd2hlbiB0aGUKICAgY2xpZW50IGlzIHJlcXVlc3RpbmcgYWNj ZXNzIHRvIHRoZSBwcm90ZWN0ZWQgcmVzb3VyY2VzIHVuZGVyIGl0cwogICBjb250cm9sLCBvciB0 aG9zZSBvZiBhbm90aGVyIHJlc291cmNlIG93bmVyIHdoaWNoIGhhcyBiZWVuIHByZXZpb3VzbHkK ICAgYXJyYW5nZWQgd2l0aCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgKHRoZSBtZXRob2Qgb2Yg d2hpY2ggaXMgYmV5b25kCiAgIHRoZSBzY29wZSBvZiB0aGlzIHNwZWNpZmljYXRpb24pLgoKICAg VGhlIGNsaWVudCBjcmVkZW50aWFscyBncmFudCB0eXBlIE1VU1Qgb25seSBiZSB1c2VkIGJ5IGNv bmZpZGVudGlhbAogICBjbGllbnRzLgoKCgpIYW1tZXIsIGV0IGFsLiAgICAgICAgICBFeHBpcmVz IERlY2VtYmVyIDQsIDIwMTIgICAgICAgICAgICAgICBbUGFnZSAzN10KDApJbnRlcm5ldC1EcmFm dCAgICAgICAgICAgICAgICAgIE9BdXRoIDIuMCAgICAgICAgICAgICAgICAgICAgICBKdW5lIDIw MTIKCgogICAgICstLS0tLS0tLS0rICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICst LS0tLS0tLS0tLS0tLS0rCiAgICAgfCAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfCAgICAgICAgICAgICAgIHwKICAgICB8ICAgICAgICAgfD4tLShBKS0gQ2xpZW50 IEF1dGhlbnRpY2F0aW9uIC0tLT58IEF1dGhvcml6YXRpb24gfAogICAgIHwgQ2xpZW50ICB8ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgIFNlcnZlciAgICB8CiAgICAgfCAg ICAgICAgIHw8LS0oQiktLS0tIEFjY2VzcyBUb2tlbiAtLS0tLS0tLS08fCAgICAgICAgICAgICAg IHwKICAgICB8ICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAg ICAgICAgICAgICAgfAogICAgICstLS0tLS0tLS0rICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICstLS0tLS0tLS0tLS0tLS0rCgoKICAgICAgICAgICAgICAgICAgICAgRmlndXJlIDY6 IENsaWVudCBDcmVkZW50aWFscyBGbG93CgogICBUaGUgZmxvdyBpbGx1c3RyYXRlZCBpbiBGaWd1 cmUgNiBpbmNsdWRlcyB0aGUgZm9sbG93aW5nIHN0ZXBzOgoKICAgKEEpICBUaGUgY2xpZW50IGF1 dGhlbnRpY2F0ZXMgd2l0aCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYW5kCiAgICAgICAgcmVx dWVzdHMgYW4gYWNjZXNzIHRva2VuIGZyb20gdGhlIHRva2VuIGVuZHBvaW50LgogICAoQikgIFRo ZSBhdXRob3JpemF0aW9uIHNlcnZlciBhdXRoZW50aWNhdGVzIHRoZSBjbGllbnQsIGFuZCBpZiB2 YWxpZAogICAgICAgIGlzc3VlcyBhbiBhY2Nlc3MgdG9rZW4uCgo0LjQuMS4gIEF1dGhvcml6YXRp b24gUmVxdWVzdCBhbmQgUmVzcG9uc2UKCiAgIFNpbmNlIHRoZSBjbGllbnQgYXV0aGVudGljYXRp b24gaXMgdXNlZCBhcyB0aGUgYXV0aG9yaXphdGlvbiBncmFudCwKICAgbm8gYWRkaXRpb25hbCBh dXRob3JpemF0aW9uIHJlcXVlc3QgaXMgbmVlZGVkLgoKNC40LjIuICBBY2Nlc3MgVG9rZW4gUmVx dWVzdAoKICAgVGhlIGNsaWVudCBtYWtlcyBhIHJlcXVlc3QgdG8gdGhlIHRva2VuIGVuZHBvaW50 IGJ5IGFkZGluZyB0aGUKICAgZm9sbG93aW5nIHBhcmFtZXRlcnMgdXNpbmcgdGhlICJhcHBsaWNh dGlvbi94LXd3dy1mb3JtLXVybGVuY29kZWQiCiAgIGZvcm1hdCBpbiB0aGUgSFRUUCByZXF1ZXN0 IGVudGl0eS1ib2R5OgoKICAgZ3JhbnRfdHlwZQogICAgICAgICBSRVFVSVJFRC4gIFZhbHVlIE1V U1QgYmUgc2V0IHRvICJjbGllbnRfY3JlZGVudGlhbHMiLgogICBzY29wZQogICAgICAgICBPUFRJ T05BTC4gIFRoZSBzY29wZSBvZiB0aGUgYWNjZXNzIHJlcXVlc3QgYXMgZGVzY3JpYmVkIGJ5CiAg ICAgICAgIFNlY3Rpb24gMy4zLgoKICAgVGhlIGNsaWVudCBNVVNUIGF1dGhlbnRpY2F0ZSB3aXRo IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBhcwogICBkZXNjcmliZWQgaW4gU2VjdGlvbiAzLjIu MS4KCiAgIEZvciBleGFtcGxlLCB0aGUgY2xpZW50IG1ha2VzIHRoZSBmb2xsb3dpbmcgSFRUUCBy ZXF1ZXN0IHVzaW5nCiAgIHRyYW5zcG9ydC1sYXllciBzZWN1cml0eSAoZXh0cmEgbGluZSBicmVh a3MgYXJlIGZvciBkaXNwbGF5IHB1cnBvc2VzCiAgIG9ubHkpOgoKCiAgICAgUE9TVCAvdG9rZW4g SFRUUC8xLjEKICAgICBIb3N0OiBzZXJ2ZXIuZXhhbXBsZS5jb20KICAgICBBdXRob3JpemF0aW9u OiBCYXNpYyBjelpDYUdSU2EzRjBNenBuV0RGbVFtRjBNMkpXCiAgICAgQ29udGVudC1UeXBlOiBh cHBsaWNhdGlvbi94LXd3dy1mb3JtLXVybGVuY29kZWQ7Y2hhcnNldD1VVEYtOAoKCgoKSGFtbWVy LCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBEZWNlbWJlciA0LCAyMDEyICAgICAgICAgICAgICAg W1BhZ2UgMzhdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICBPQXV0aCAyLjAgICAg ICAgICAgICAgICAgICAgICAgSnVuZSAyMDEyCgoKICAgICBncmFudF90eXBlPWNsaWVudF9jcmVk ZW50aWFscwoKCiAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBNVVNUIGF1dGhlbnRpY2F0ZSB0 aGUgY2xpZW50LgoKNC40LjMuICBBY2Nlc3MgVG9rZW4gUmVzcG9uc2UKCiAgIElmIHRoZSBhY2Nl c3MgdG9rZW4gcmVxdWVzdCBpcyB2YWxpZCBhbmQgYXV0aG9yaXplZCwgdGhlCiAgIGF1dGhvcml6 YXRpb24gc2VydmVyIGlzc3VlcyBhbiBhY2Nlc3MgdG9rZW4gYXMgZGVzY3JpYmVkIGluCiAgIFNl Y3Rpb24gNS4xLiAgQSByZWZyZXNoIHRva2VuIFNIT1VMRCBOT1QgYmUgaW5jbHVkZWQuICBJZiB0 aGUgcmVxdWVzdAogICBmYWlsZWQgY2xpZW50IGF1dGhlbnRpY2F0aW9uIG9yIGlzIGludmFsaWQs IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlcgogICByZXR1cm5zIGFuIGVycm9yIHJlc3BvbnNlIGFz IGRlc2NyaWJlZCBpbiBTZWN0aW9uIDUuMi4KCiAgIEFuIGV4YW1wbGUgc3VjY2Vzc2Z1bCByZXNw b25zZToKCgogICAgIEhUVFAvMS4xIDIwMCBPSwogICAgIENvbnRlbnQtVHlwZTogYXBwbGljYXRp b24vanNvbjtjaGFyc2V0PVVURi04CiAgICAgQ2FjaGUtQ29udHJvbDogbm8tc3RvcmUKICAgICBQ cmFnbWE6IG5vLWNhY2hlCgogICAgIHsKICAgICAgICJhY2Nlc3NfdG9rZW4iOiIyWW90bkZaRkVq cjF6Q3NpY01XcEFBIiwKICAgICAgICJ0b2tlbl90eXBlIjoiZXhhbXBsZSIsCiAgICAgICAiZXhw aXJlc19pbiI6MzYwMCwKICAgICAgICJleGFtcGxlX3BhcmFtZXRlciI6ImV4YW1wbGVfdmFsdWUi CiAgICAgfQoKCjQuNS4gIEV4dGVuc2lvbiBHcmFudHMKCiAgIFRoZSBjbGllbnQgdXNlcyBhbiBl eHRlbnNpb24gZ3JhbnQgdHlwZSBieSBzcGVjaWZ5aW5nIHRoZSBncmFudCB0eXBlCiAgIHVzaW5n IGFuIGFic29sdXRlIFVSSSAoZGVmaW5lZCBieSB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIpIGFz IHRoZQogICB2YWx1ZSBvZiB0aGUgImdyYW50X3R5cGUiIHBhcmFtZXRlciBvZiB0aGUgdG9rZW4g ZW5kcG9pbnQsIGFuZCBieQogICBhZGRpbmcgYW55IGFkZGl0aW9uYWwgcGFyYW1ldGVycyBuZWNl c3NhcnkuCgogICBGb3IgZXhhbXBsZSwgdG8gcmVxdWVzdCBhbiBhY2Nlc3MgdG9rZW4gdXNpbmcg YSBTQU1MIDIuMCBhc3NlcnRpb24KICAgZ3JhbnQgdHlwZSBhcyBkZWZpbmVkIGJ5IFtJLUQuaWV0 Zi1vYXV0aC1zYW1sMi1iZWFyZXJdLCB0aGUgY2xpZW50CiAgIG1ha2VzIHRoZSBmb2xsb3dpbmcg SFRUUCByZXF1ZXN0IHVzaW5nIFRMUyAobGluZSBicmVha3MgYXJlIGZvcgogICBkaXNwbGF5IHB1 cnBvc2VzIG9ubHkpOgoKCiAgICAgUE9TVCAvdG9rZW4gSFRUUC8xLjEKICAgICBIb3N0OiBzZXJ2 ZXIuZXhhbXBsZS5jb20KICAgICBDb250ZW50LVR5cGU6IGFwcGxpY2F0aW9uL3gtd3d3LWZvcm0t dXJsZW5jb2RlZDtjaGFyc2V0PVVURi04CgogICAgIGdyYW50X3R5cGU9dXJuJTNBaWV0ZiUzQXBh cmFtcyUzQW9hdXRoJTNBZ3JhbnQtdHlwZSUzQXNhbWwyLQogICAgIGJlYXJlciZhc3NlcnRpb249 UEVGemMyVnlkR2x2YmlCSmMzTjFaVWx1YzNSaGJuUTlJakl3TVRFdE1EVQoKCgpIYW1tZXIsIGV0 IGFsLiAgICAgICAgICBFeHBpcmVzIERlY2VtYmVyIDQsIDIwMTIgICAgICAgICAgICAgICBbUGFn ZSAzOV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgIE9BdXRoIDIuMCAgICAgICAg ICAgICAgICAgICAgICBKdW5lIDIwMTIKCgogICAgIFsuLi5vbWl0dGVkIGZvciBicmV2aXR5Li4u XWFHNVRkR0YwWlcxbGJuUS1QQzlCYzNObGNuUnBiMjQtCgoKICAgSWYgdGhlIGFjY2VzcyB0b2tl biByZXF1ZXN0IGlzIHZhbGlkIGFuZCBhdXRob3JpemVkLCB0aGUKICAgYXV0aG9yaXphdGlvbiBz ZXJ2ZXIgaXNzdWVzIGFuIGFjY2VzcyB0b2tlbiBhbmQgb3B0aW9uYWwgcmVmcmVzaAogICB0b2tl biBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiA1LjEuICBJZiB0aGUgcmVxdWVzdCBmYWlsZWQgY2xp ZW50CiAgIGF1dGhlbnRpY2F0aW9uIG9yIGlzIGludmFsaWQsIHRoZSBhdXRob3JpemF0aW9uIHNl cnZlciByZXR1cm5zIGFuCiAgIGVycm9yIHJlc3BvbnNlIGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9u IDUuMi4KCgo1LiAgSXNzdWluZyBhbiBBY2Nlc3MgVG9rZW4KCiAgIElmIHRoZSBhY2Nlc3MgdG9r ZW4gcmVxdWVzdCBpcyB2YWxpZCBhbmQgYXV0aG9yaXplZCwgdGhlCiAgIGF1dGhvcml6YXRpb24g c2VydmVyIGlzc3VlcyBhbiBhY2Nlc3MgdG9rZW4gYW5kIG9wdGlvbmFsIHJlZnJlc2gKICAgdG9r ZW4gYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gNS4xLiAgSWYgdGhlIHJlcXVlc3QgZmFpbGVkIGNs aWVudAogICBhdXRoZW50aWNhdGlvbiBvciBpcyBpbnZhbGlkLCB0aGUgYXV0aG9yaXphdGlvbiBz ZXJ2ZXIgcmV0dXJucyBhbgogICBlcnJvciByZXNwb25zZSBhcyBkZXNjcmliZWQgaW4gU2VjdGlv biA1LjIuCgo1LjEuICBTdWNjZXNzZnVsIFJlc3BvbnNlCgogICBUaGUgYXV0aG9yaXphdGlvbiBz ZXJ2ZXIgaXNzdWVzIGFuIGFjY2VzcyB0b2tlbiBhbmQgb3B0aW9uYWwgcmVmcmVzaAogICB0b2tl biwgYW5kIGNvbnN0cnVjdHMgdGhlIHJlc3BvbnNlIGJ5IGFkZGluZyB0aGUgZm9sbG93aW5nIHBh cmFtZXRlcnMKICAgdG8gdGhlIGVudGl0eSBib2R5IG9mIHRoZSBIVFRQIHJlc3BvbnNlIHdpdGgg YSAyMDAgKE9LKSBzdGF0dXMgY29kZToKCiAgIGFjY2Vzc190b2tlbgogICAgICAgICBSRVFVSVJF RC4gIFRoZSBhY2Nlc3MgdG9rZW4gaXNzdWVkIGJ5IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlci4K ICAgdG9rZW5fdHlwZQogICAgICAgICBSRVFVSVJFRC4gIFRoZSB0eXBlIG9mIHRoZSB0b2tlbiBp c3N1ZWQgYXMgZGVzY3JpYmVkIGluCiAgICAgICAgIFNlY3Rpb24gNy4xLiAgVmFsdWUgaXMgY2Fz ZSBpbnNlbnNpdGl2ZS4KICAgZXhwaXJlc19pbgogICAgICAgICBSRUNPTU1FTkRFRC4gIFRoZSBs aWZldGltZSBpbiBzZWNvbmRzIG9mIHRoZSBhY2Nlc3MgdG9rZW4uICBGb3IKICAgICAgICAgZXhh bXBsZSwgdGhlIHZhbHVlICIzNjAwIiBkZW5vdGVzIHRoYXQgdGhlIGFjY2VzcyB0b2tlbiB3aWxs CiAgICAgICAgIGV4cGlyZSBpbiBvbmUgaG91ciBmcm9tIHRoZSB0aW1lIHRoZSByZXNwb25zZSB3 YXMgZ2VuZXJhdGVkLgogICAgICAgICBJZiBvbWl0dGVkLCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2 ZXIgU0hPVUxEIHByb3ZpZGUgdGhlCiAgICAgICAgIGV4cGlyYXRpb24gdGltZSB2aWEgb3RoZXIg bWVhbnMgb3IgZG9jdW1lbnQgdGhlIGRlZmF1bHQgdmFsdWUuCiAgIHJlZnJlc2hfdG9rZW4KICAg ICAgICAgT1BUSU9OQUwuICBUaGUgcmVmcmVzaCB0b2tlbiB3aGljaCBjYW4gYmUgdXNlZCB0byBv YnRhaW4gbmV3CiAgICAgICAgIGFjY2VzcyB0b2tlbnMgdXNpbmcgdGhlIHNhbWUgYXV0aG9yaXph dGlvbiBncmFudCBhcyBkZXNjcmliZWQKICAgICAgICAgaW4gU2VjdGlvbiA2LgogICBzY29wZQog ICAgICAgICBPUFRJT05BTCwgaWYgaWRlbnRpY2FsIHRvIHRoZSBzY29wZSByZXF1ZXN0ZWQgYnkg dGhlIGNsaWVudCwKICAgICAgICAgb3RoZXJ3aXNlIFJFUVVJUkVELiAgVGhlIHNjb3BlIG9mIHRo ZSBhY2Nlc3MgdG9rZW4gYXMgZGVzY3JpYmVkCiAgICAgICAgIGJ5IFNlY3Rpb24gMy4zLgoKICAg VGhlIHBhcmFtZXRlcnMgYXJlIGluY2x1ZGVkIGluIHRoZSBlbnRpdHkgYm9keSBvZiB0aGUgSFRU UCByZXNwb25zZQogICB1c2luZyB0aGUgImFwcGxpY2F0aW9uL2pzb24iIG1lZGlhIHR5cGUgYXMg ZGVmaW5lZCBieSBbUkZDNDYyN10uICBUaGUKICAgcGFyYW1ldGVycyBhcmUgc2VyaWFsaXplZCBp bnRvIGEgSlNPTiBzdHJ1Y3R1cmUgYnkgYWRkaW5nIGVhY2gKICAgcGFyYW1ldGVyIGF0IHRoZSBo aWdoZXN0IHN0cnVjdHVyZSBsZXZlbC4gIFBhcmFtZXRlciBuYW1lcyBhbmQgc3RyaW5nCgoKCkhh bW1lciwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgRGVjZW1iZXIgNCwgMjAxMiAgICAgICAgICAg ICAgIFtQYWdlIDQwXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgT0F1dGggMi4w ICAgICAgICAgICAgICAgICAgICAgIEp1bmUgMjAxMgoKCiAgIHZhbHVlcyBhcmUgaW5jbHVkZWQg YXMgSlNPTiBzdHJpbmdzLiAgTnVtZXJpY2FsIHZhbHVlcyBhcmUgaW5jbHVkZWQKICAgYXMgSlNP TiBudW1iZXJzLiAgVGhlIG9yZGVyIG9mIHBhcmFtZXRlcnMgZG9lcyBub3QgbWF0dGVyIGFuZCBj YW4KICAgdmFyeS4KCiAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBNVVNUIGluY2x1ZGUgdGhl IEhUVFAgIkNhY2hlLUNvbnRyb2wiCiAgIHJlc3BvbnNlIGhlYWRlciBmaWVsZCBbUkZDMjYxNl0g d2l0aCBhIHZhbHVlIG9mICJuby1zdG9yZSIgaW4gYW55CiAgIHJlc3BvbnNlIGNvbnRhaW5pbmcg dG9rZW5zLCBjcmVkZW50aWFscywgb3Igb3RoZXIgc2Vuc2l0aXZlCiAgIGluZm9ybWF0aW9uLCBh cyB3ZWxsIGFzIHRoZSAiUHJhZ21hIiByZXNwb25zZSBoZWFkZXIgZmllbGQgW1JGQzI2MTZdCiAg IHdpdGggYSB2YWx1ZSBvZiAibm8tY2FjaGUiLgoKICAgRm9yIGV4YW1wbGU6CgoKICAgICBIVFRQ LzEuMSAyMDAgT0sKICAgICBDb250ZW50LVR5cGU6IGFwcGxpY2F0aW9uL2pzb247Y2hhcnNldD1V VEYtOAogICAgIENhY2hlLUNvbnRyb2w6IG5vLXN0b3JlCiAgICAgUHJhZ21hOiBuby1jYWNoZQoK ICAgICB7CiAgICAgICAiYWNjZXNzX3Rva2VuIjoiMllvdG5GWkZFanIxekNzaWNNV3BBQSIsCiAg ICAgICAidG9rZW5fdHlwZSI6ImV4YW1wbGUiLAogICAgICAgImV4cGlyZXNfaW4iOjM2MDAsCiAg ICAgICAicmVmcmVzaF90b2tlbiI6InRHenYzSk9rRjBYRzVReDJUbEtXSUEiLAogICAgICAgImV4 YW1wbGVfcGFyYW1ldGVyIjoiZXhhbXBsZV92YWx1ZSIKICAgICB9CgoKICAgVGhlIGNsaWVudCBN VVNUIGlnbm9yZSB1bnJlY29nbml6ZWQgdmFsdWUgbmFtZXMgaW4gdGhlIHJlc3BvbnNlLiAgVGhl CiAgIHNpemVzIG9mIHRva2VucyBhbmQgb3RoZXIgdmFsdWVzIHJlY2VpdmVkIGZyb20gdGhlIGF1 dGhvcml6YXRpb24KICAgc2VydmVyIGFyZSBsZWZ0IHVuZGVmaW5lZC4gIFRoZSBjbGllbnQgc2hv dWxkIGF2b2lkIG1ha2luZwogICBhc3N1bXB0aW9ucyBhYm91dCB2YWx1ZSBzaXplcy4gIFRoZSBh dXRob3JpemF0aW9uIHNlcnZlciBTSE9VTEQKICAgZG9jdW1lbnQgdGhlIHNpemUgb2YgYW55IHZh bHVlIGl0IGlzc3Vlcy4KCjUuMi4gIEVycm9yIFJlc3BvbnNlCgogICBUaGUgYXV0aG9yaXphdGlv biBzZXJ2ZXIgcmVzcG9uZHMgd2l0aCBhbiBIVFRQIDQwMCAoQmFkIFJlcXVlc3QpCiAgIHN0YXR1 cyBjb2RlICh1bmxlc3Mgc3BlY2lmaWVkIG90aGVyd2lzZSkgYW5kIGluY2x1ZGVzIHRoZSBmb2xs b3dpbmcKICAgcGFyYW1ldGVycyB3aXRoIHRoZSByZXNwb25zZToKCiAgIGVycm9yCiAgICAgICAg IFJFUVVJUkVELiAgQSBzaW5nbGUgQVNDSUkgW1VTQVNDSUldIGVycm9yIGNvZGUgZnJvbSB0aGUK ICAgICAgICAgZm9sbG93aW5nOgogICAgICAgICBpbnZhbGlkX3JlcXVlc3QKICAgICAgICAgICAg ICAgVGhlIHJlcXVlc3QgaXMgbWlzc2luZyBhIHJlcXVpcmVkIHBhcmFtZXRlciwgaW5jbHVkZXMg YW4KICAgICAgICAgICAgICAgdW5zdXBwb3J0ZWQgcGFyYW1ldGVyIHZhbHVlIChvdGhlciB0aGFu IGdyYW50IHR5cGUpLAogICAgICAgICAgICAgICByZXBlYXRzIGEgcGFyYW1ldGVyLCBpbmNsdWRl cyBtdWx0aXBsZSBjcmVkZW50aWFscywKICAgICAgICAgICAgICAgdXRpbGl6ZXMgbW9yZSB0aGFu IG9uZSBtZWNoYW5pc20gZm9yIGF1dGhlbnRpY2F0aW5nIHRoZQogICAgICAgICAgICAgICBjbGll bnQsIG9yIGlzIG90aGVyd2lzZSBtYWxmb3JtZWQuCgoKCkhhbW1lciwgZXQgYWwuICAgICAgICAg IEV4cGlyZXMgRGVjZW1iZXIgNCwgMjAxMiAgICAgICAgICAgICAgIFtQYWdlIDQxXQoMCkludGVy bmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgT0F1dGggMi4wICAgICAgICAgICAgICAgICAgICAg IEp1bmUgMjAxMgoKCiAgICAgICAgIGludmFsaWRfY2xpZW50CiAgICAgICAgICAgICAgIENsaWVu dCBhdXRoZW50aWNhdGlvbiBmYWlsZWQgKGUuZy4gdW5rbm93biBjbGllbnQsIG5vCiAgICAgICAg ICAgICAgIGNsaWVudCBhdXRoZW50aWNhdGlvbiBpbmNsdWRlZCwgb3IgdW5zdXBwb3J0ZWQKICAg ICAgICAgICAgICAgYXV0aGVudGljYXRpb24gbWV0aG9kKS4gIFRoZSBhdXRob3JpemF0aW9uIHNl cnZlciBNQVkKICAgICAgICAgICAgICAgcmV0dXJuIGFuIEhUVFAgNDAxIChVbmF1dGhvcml6ZWQp IHN0YXR1cyBjb2RlIHRvIGluZGljYXRlCiAgICAgICAgICAgICAgIHdoaWNoIEhUVFAgYXV0aGVu dGljYXRpb24gc2NoZW1lcyBhcmUgc3VwcG9ydGVkLiAgSWYgdGhlCiAgICAgICAgICAgICAgIGNs aWVudCBhdHRlbXB0ZWQgdG8gYXV0aGVudGljYXRlIHZpYSB0aGUgIkF1dGhvcml6YXRpb24iCiAg ICAgICAgICAgICAgIHJlcXVlc3QgaGVhZGVyIGZpZWxkLCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2 ZXIgTVVTVAogICAgICAgICAgICAgICByZXNwb25kIHdpdGggYW4gSFRUUCA0MDEgKFVuYXV0aG9y aXplZCkgc3RhdHVzIGNvZGUsIGFuZAogICAgICAgICAgICAgICBpbmNsdWRlIHRoZSAiV1dXLUF1 dGhlbnRpY2F0ZSIgcmVzcG9uc2UgaGVhZGVyIGZpZWxkCiAgICAgICAgICAgICAgIG1hdGNoaW5n IHRoZSBhdXRoZW50aWNhdGlvbiBzY2hlbWUgdXNlZCBieSB0aGUgY2xpZW50LgogICAgICAgICBp bnZhbGlkX2dyYW50CiAgICAgICAgICAgICAgIFRoZSBwcm92aWRlZCBhdXRob3JpemF0aW9uIGdy YW50IChlLmcuIGF1dGhvcml6YXRpb24KICAgICAgICAgICAgICAgY29kZSwgcmVzb3VyY2Ugb3du ZXIgY3JlZGVudGlhbHMpIG9yIHJlZnJlc2ggdG9rZW4gaXMKICAgICAgICAgICAgICAgaW52YWxp ZCwgZXhwaXJlZCwgcmV2b2tlZCwgZG9lcyBub3QgbWF0Y2ggdGhlIHJlZGlyZWN0aW9uCiAgICAg ICAgICAgICAgIFVSSSB1c2VkIGluIHRoZSBhdXRob3JpemF0aW9uIHJlcXVlc3QsIG9yIHdhcyBp c3N1ZWQgdG8KICAgICAgICAgICAgICAgYW5vdGhlciBjbGllbnQuCiAgICAgICAgIHVuYXV0aG9y aXplZF9jbGllbnQKICAgICAgICAgICAgICAgVGhlIGF1dGhlbnRpY2F0ZWQgY2xpZW50IGlzIG5v dCBhdXRob3JpemVkIHRvIHVzZSB0aGlzCiAgICAgICAgICAgICAgIGF1dGhvcml6YXRpb24gZ3Jh bnQgdHlwZS4KICAgICAgICAgdW5zdXBwb3J0ZWRfZ3JhbnRfdHlwZQogICAgICAgICAgICAgICBU aGUgYXV0aG9yaXphdGlvbiBncmFudCB0eXBlIGlzIG5vdCBzdXBwb3J0ZWQgYnkgdGhlCiAgICAg ICAgICAgICAgIGF1dGhvcml6YXRpb24gc2VydmVyLgogICAgICAgICBpbnZhbGlkX3Njb3BlCiAg ICAgICAgICAgICAgIFRoZSByZXF1ZXN0ZWQgc2NvcGUgaXMgaW52YWxpZCwgdW5rbm93biwgbWFs Zm9ybWVkLCBvcgogICAgICAgICAgICAgICBleGNlZWRzIHRoZSBzY29wZSBncmFudGVkIGJ5IHRo ZSByZXNvdXJjZSBvd25lci4KICAgICAgICAgVmFsdWVzIGZvciB0aGUgImVycm9yIiBwYXJhbWV0 ZXIgTVVTVCBOT1QgaW5jbHVkZSBjaGFyYWN0ZXJzCiAgICAgICAgIG91dHNpZGUgdGhlIHNldCAl eDIwLTIxIC8gJXgyMy01QiAvICV4NUQtN0UuCiAgIGVycm9yX2Rlc2NyaXB0aW9uCiAgICAgICAg IE9QVElPTkFMLiAgQSBodW1hbi1yZWFkYWJsZSBBU0NJSSBbVVNBU0NJSV0gdGV4dCBwcm92aWRp bmcKICAgICAgICAgYWRkaXRpb25hbCBpbmZvcm1hdGlvbiwgdXNlZCB0byBhc3Npc3QgdGhlIGNs aWVudCBkZXZlbG9wZXIgaW4KICAgICAgICAgdW5kZXJzdGFuZGluZyB0aGUgZXJyb3IgdGhhdCBv Y2N1cnJlZC4KICAgICAgICAgVmFsdWVzIGZvciB0aGUgImVycm9yX2Rlc2NyaXB0aW9uIiBwYXJh bWV0ZXIgTVVTVCBOT1QgaW5jbHVkZQogICAgICAgICBjaGFyYWN0ZXJzIG91dHNpZGUgdGhlIHNl dCAleDIwLTIxIC8gJXgyMy01QiAvICV4NUQtN0UuCiAgIGVycm9yX3VyaQogICAgICAgICBPUFRJ T05BTC4gIEEgVVJJIGlkZW50aWZ5aW5nIGEgaHVtYW4tcmVhZGFibGUgd2ViIHBhZ2Ugd2l0aAog ICAgICAgICBpbmZvcm1hdGlvbiBhYm91dCB0aGUgZXJyb3IsIHVzZWQgdG8gcHJvdmlkZSB0aGUg Y2xpZW50CiAgICAgICAgIGRldmVsb3BlciB3aXRoIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gYWJv dXQgdGhlIGVycm9yLgogICAgICAgICBWYWx1ZXMgZm9yIHRoZSAiZXJyb3JfdXJpIiBwYXJhbWV0 ZXIgTVVTVCBjb25mb3JtIHRvIHRoZSBVUkktCiAgICAgICAgIFJlZmVyZW5jZSBzeW50YXgsIGFu ZCB0aHVzIE1VU1QgTk9UIGluY2x1ZGUgY2hhcmFjdGVycyBvdXRzaWRlCiAgICAgICAgIHRoZSBz ZXQgJXgyMSAvICV4MjMtNUIgLyAleDVELTdFLgoKICAgVGhlIHBhcmFtZXRlcnMgYXJlIGluY2x1 ZGVkIGluIHRoZSBlbnRpdHkgYm9keSBvZiB0aGUgSFRUUCByZXNwb25zZQogICB1c2luZyB0aGUg ImFwcGxpY2F0aW9uL2pzb24iIG1lZGlhIHR5cGUgYXMgZGVmaW5lZCBieSBbUkZDNDYyN10uICBU aGUKICAgcGFyYW1ldGVycyBhcmUgc2VyaWFsaXplZCBpbnRvIGEgSlNPTiBzdHJ1Y3R1cmUgYnkg YWRkaW5nIGVhY2gKICAgcGFyYW1ldGVyIGF0IHRoZSBoaWdoZXN0IHN0cnVjdHVyZSBsZXZlbC4g IFBhcmFtZXRlciBuYW1lcyBhbmQgc3RyaW5nCiAgIHZhbHVlcyBhcmUgaW5jbHVkZWQgYXMgSlNP TiBzdHJpbmdzLiAgTnVtZXJpY2FsIHZhbHVlcyBhcmUgaW5jbHVkZWQKICAgYXMgSlNPTiBudW1i ZXJzLiAgVGhlIG9yZGVyIG9mIHBhcmFtZXRlcnMgZG9lcyBub3QgbWF0dGVyIGFuZCBjYW4KCgoK SGFtbWVyLCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBEZWNlbWJlciA0LCAyMDEyICAgICAgICAg ICAgICAgW1BhZ2UgNDJdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICBPQXV0aCAy LjAgICAgICAgICAgICAgICAgICAgICAgSnVuZSAyMDEyCgoKICAgdmFyeS4KCiAgIEZvciBleGFt cGxlOgoKCiAgICAgSFRUUC8xLjEgNDAwIEJhZCBSZXF1ZXN0CiAgICAgQ29udGVudC1UeXBlOiBh cHBsaWNhdGlvbi9qc29uO2NoYXJzZXQ9VVRGLTgKICAgICBDYWNoZS1Db250cm9sOiBuby1zdG9y ZQogICAgIFByYWdtYTogbm8tY2FjaGUKCiAgICAgewogICAgICAgImVycm9yIjoiaW52YWxpZF9y ZXF1ZXN0IgogICAgIH0KCgoKNi4gIFJlZnJlc2hpbmcgYW4gQWNjZXNzIFRva2VuCgogICBJZiB0 aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgaXNzdWVkIGEgcmVmcmVzaCB0b2tlbiB0byB0aGUgY2xp ZW50LCB0aGUKICAgY2xpZW50IG1ha2VzIGEgcmVmcmVzaCByZXF1ZXN0IHRvIHRoZSB0b2tlbiBl bmRwb2ludCBieSBhZGRpbmcgdGhlCiAgIGZvbGxvd2luZyBwYXJhbWV0ZXJzIHVzaW5nIHRoZSAi YXBwbGljYXRpb24veC13d3ctZm9ybS11cmxlbmNvZGVkIgogICBmb3JtYXQgaW4gdGhlIEhUVFAg cmVxdWVzdCBlbnRpdHktYm9keToKCiAgIGdyYW50X3R5cGUKICAgICAgICAgUkVRVUlSRUQuICBW YWx1ZSBNVVNUIGJlIHNldCB0byAicmVmcmVzaF90b2tlbiIuCiAgIHJlZnJlc2hfdG9rZW4KICAg ICAgICAgUkVRVUlSRUQuICBUaGUgcmVmcmVzaCB0b2tlbiBpc3N1ZWQgdG8gdGhlIGNsaWVudC4K ICAgc2NvcGUKICAgICAgICAgT1BUSU9OQUwuICBUaGUgc2NvcGUgb2YgdGhlIGFjY2VzcyByZXF1 ZXN0IGFzIGRlc2NyaWJlZCBieQogICAgICAgICBTZWN0aW9uIDMuMy4gIFRoZSByZXF1ZXN0ZWQg c2NvcGUgTVVTVCBOT1QgaW5jbHVkZSBhbnkgc2NvcGUKICAgICAgICAgbm90IG9yaWdpbmFsbHkg Z3JhbnRlZCBieSB0aGUgcmVzb3VyY2Ugb3duZXIsIGFuZCBpZiBvbWl0dGVkIGlzCiAgICAgICAg IHRyZWF0ZWQgYXMgZXF1YWwgdG8gdGhlIHNjb3BlIG9yaWdpbmFsbHkgZ3JhbnRlZCBieSB0aGUK ICAgICAgICAgcmVzb3VyY2Ugb3duZXIuCgogICBCZWNhdXNlIHJlZnJlc2ggdG9rZW5zIGFyZSB0 eXBpY2FsbHkgbG9uZy1sYXN0aW5nIGNyZWRlbnRpYWxzIHVzZWQgdG8KICAgcmVxdWVzdCBhZGRp dGlvbmFsIGFjY2VzcyB0b2tlbnMsIHRoZSByZWZyZXNoIHRva2VuIGlzIGJvdW5kIHRvIHRoZQog ICBjbGllbnQgd2hpY2ggaXQgd2FzIGlzc3VlZC4gIElmIHRoZSBjbGllbnQgdHlwZSBpcyBjb25m aWRlbnRpYWwgb3IKICAgdGhlIGNsaWVudCB3YXMgaXNzdWVkIGNsaWVudCBjcmVkZW50aWFscyAo b3IgYXNzaWduZWQgb3RoZXIKICAgYXV0aGVudGljYXRpb24gcmVxdWlyZW1lbnRzKSwgdGhlIGNs aWVudCBNVVNUIGF1dGhlbnRpY2F0ZSB3aXRoIHRoZQogICBhdXRob3JpemF0aW9uIHNlcnZlciBh cyBkZXNjcmliZWQgaW4gU2VjdGlvbiAzLjIuMS4KCgoKCgoKCgoKCgpIYW1tZXIsIGV0IGFsLiAg ICAgICAgICBFeHBpcmVzIERlY2VtYmVyIDQsIDIwMTIgICAgICAgICAgICAgICBbUGFnZSA0M10K DApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgIE9BdXRoIDIuMCAgICAgICAgICAgICAg ICAgICAgICBKdW5lIDIwMTIKCgogICBGb3IgZXhhbXBsZSwgdGhlIGNsaWVudCBtYWtlcyB0aGUg Zm9sbG93aW5nIEhUVFAgcmVxdWVzdCB1c2luZwogICB0cmFuc3BvcnQtbGF5ZXIgc2VjdXJpdHkg KGV4dHJhIGxpbmUgYnJlYWtzIGFyZSBmb3IgZGlzcGxheSBwdXJwb3NlcwogICBvbmx5KToKCgog ICAgIFBPU1QgL3Rva2VuIEhUVFAvMS4xCiAgICAgSG9zdDogc2VydmVyLmV4YW1wbGUuY29tCiAg ICAgQXV0aG9yaXphdGlvbjogQmFzaWMgY3paQ2FHUlNhM0YwTXpwbldERm1RbUYwTTJKVwogICAg IENvbnRlbnQtVHlwZTogYXBwbGljYXRpb24veC13d3ctZm9ybS11cmxlbmNvZGVkO2NoYXJzZXQ9 VVRGLTgKCiAgICAgZ3JhbnRfdHlwZT1yZWZyZXNoX3Rva2VuJnJlZnJlc2hfdG9rZW49dEd6djNK T2tGMFhHNVF4MlRsS1dJQQoKCiAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBNVVNUOgoKICAg byAgcmVxdWlyZSBjbGllbnQgYXV0aGVudGljYXRpb24gZm9yIGNvbmZpZGVudGlhbCBjbGllbnRz IG9yIGZvciBhbnkKICAgICAgY2xpZW50IHRoYXQgd2FzIGlzc3VlZCBjbGllbnQgY3JlZGVudGlh bHMgKG9yIHdpdGggb3RoZXIKICAgICAgYXV0aGVudGljYXRpb24gcmVxdWlyZW1lbnRzKSwKICAg byAgYXV0aGVudGljYXRlIHRoZSBjbGllbnQgaWYgY2xpZW50IGF1dGhlbnRpY2F0aW9uIGlzIGlu Y2x1ZGVkIGFuZAogICAgICBlbnN1cmUgdGhlIHJlZnJlc2ggdG9rZW4gd2FzIGlzc3VlZCB0byB0 aGUgYXV0aGVudGljYXRlZCBjbGllbnQsCiAgICAgIGFuZAogICBvICB2YWxpZGF0ZSB0aGUgcmVm cmVzaCB0b2tlbi4KCiAgIElmIHZhbGlkIGFuZCBhdXRob3JpemVkLCB0aGUgYXV0aG9yaXphdGlv biBzZXJ2ZXIgaXNzdWVzIGFuIGFjY2VzcwogICB0b2tlbiBhcyBkZXNjcmliZWQgaW4gU2VjdGlv biA1LjEuICBJZiB0aGUgcmVxdWVzdCBmYWlsZWQKICAgdmVyaWZpY2F0aW9uIG9yIGlzIGludmFs aWQsIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciByZXR1cm5zIGFuIGVycm9yCiAgIHJlc3BvbnNl IGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDUuMi4KCiAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZl ciBNQVkgaXNzdWUgYSBuZXcgcmVmcmVzaCB0b2tlbiwgaW4gd2hpY2ggY2FzZQogICB0aGUgY2xp ZW50IE1VU1QgZGlzY2FyZCB0aGUgb2xkIHJlZnJlc2ggdG9rZW4gYW5kIHJlcGxhY2UgaXQgd2l0 aCB0aGUKICAgbmV3IHJlZnJlc2ggdG9rZW4uICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTUFZ IHJldm9rZSB0aGUgb2xkCiAgIHJlZnJlc2ggdG9rZW4gYWZ0ZXIgaXNzdWluZyBhIG5ldyByZWZy ZXNoIHRva2VuIHRvIHRoZSBjbGllbnQuICBJZiBhCiAgIG5ldyByZWZyZXNoIHRva2VuIGlzIGlz c3VlZCwgdGhlIHJlZnJlc2ggdG9rZW4gc2NvcGUgTVVTVCBiZQogICBpZGVudGljYWwgdG8gdGhh dCBvZiB0aGUgcmVmcmVzaCB0b2tlbiBpbmNsdWRlZCBieSB0aGUgY2xpZW50IGluIHRoZQogICBy ZXF1ZXN0LgoKCjcuICBBY2Nlc3NpbmcgUHJvdGVjdGVkIFJlc291cmNlcwoKICAgVGhlIGNsaWVu dCBhY2Nlc3NlcyBwcm90ZWN0ZWQgcmVzb3VyY2VzIGJ5IHByZXNlbnRpbmcgdGhlIGFjY2Vzcwog ICB0b2tlbiB0byB0aGUgcmVzb3VyY2Ugc2VydmVyLiAgVGhlIHJlc291cmNlIHNlcnZlciBNVVNU IHZhbGlkYXRlIHRoZQogICBhY2Nlc3MgdG9rZW4gYW5kIGVuc3VyZSBpdCBoYXMgbm90IGV4cGly ZWQgYW5kIHRoYXQgaXRzIHNjb3BlIGNvdmVycwogICB0aGUgcmVxdWVzdGVkIHJlc291cmNlLiAg VGhlIG1ldGhvZHMgdXNlZCBieSB0aGUgcmVzb3VyY2Ugc2VydmVyIHRvCiAgIHZhbGlkYXRlIHRo ZSBhY2Nlc3MgdG9rZW4gKGFzIHdlbGwgYXMgYW55IGVycm9yIHJlc3BvbnNlcykgYXJlIGJleW9u ZAogICB0aGUgc2NvcGUgb2YgdGhpcyBzcGVjaWZpY2F0aW9uLCBidXQgZ2VuZXJhbGx5IGludm9s dmUgYW4gaW50ZXJhY3Rpb24KICAgb3IgY29vcmRpbmF0aW9uIGJldHdlZW4gdGhlIHJlc291cmNl IHNlcnZlciBhbmQgdGhlIGF1dGhvcml6YXRpb24KICAgc2VydmVyLgoKCgoKSGFtbWVyLCBldCBh bC4gICAgICAgICAgRXhwaXJlcyBEZWNlbWJlciA0LCAyMDEyICAgICAgICAgICAgICAgW1BhZ2Ug NDRdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICBPQXV0aCAyLjAgICAgICAgICAg ICAgICAgICAgICAgSnVuZSAyMDEyCgoKICAgVGhlIG1ldGhvZCBpbiB3aGljaCB0aGUgY2xpZW50 IHV0aWxpemVzIHRoZSBhY2Nlc3MgdG9rZW4gdG8KICAgYXV0aGVudGljYXRlIHdpdGggdGhlIHJl c291cmNlIHNlcnZlciBkZXBlbmRzIG9uIHRoZSB0eXBlIG9mIGFjY2VzcwogICB0b2tlbiBpc3N1 ZWQgYnkgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLiAgVHlwaWNhbGx5LCBpdCBpbnZvbHZlcwog ICB1c2luZyB0aGUgSFRUUCAiQXV0aG9yaXphdGlvbiIgcmVxdWVzdCBoZWFkZXIgZmllbGQgW1JG QzI2MTddIHdpdGggYW4KICAgYXV0aGVudGljYXRpb24gc2NoZW1lIGRlZmluZWQgYnkgdGhlIGFj Y2VzcyB0b2tlbiB0eXBlIHNwZWNpZmljYXRpb24uCgo3LjEuICBBY2Nlc3MgVG9rZW4gVHlwZXMK CiAgIFRoZSBhY2Nlc3MgdG9rZW4gdHlwZSBwcm92aWRlcyB0aGUgY2xpZW50IHdpdGggdGhlIGlu Zm9ybWF0aW9uCiAgIHJlcXVpcmVkIHRvIHN1Y2Nlc3NmdWxseSB1dGlsaXplIHRoZSBhY2Nlc3Mg dG9rZW4gdG8gbWFrZSBhIHByb3RlY3RlZAogICByZXNvdXJjZSByZXF1ZXN0IChhbG9uZyB3aXRo IHR5cGUtc3BlY2lmaWMgYXR0cmlidXRlcykuICBUaGUgY2xpZW50CiAgIE1VU1QgTk9UIHVzZSBh biBhY2Nlc3MgdG9rZW4gaWYgaXQgZG9lcyBub3QgdW5kZXJzdGFuZCB0aGUgdG9rZW4KICAgdHlw ZS4KCiAgIEZvciBleGFtcGxlLCB0aGUgImJlYXJlciIgdG9rZW4gdHlwZSBkZWZpbmVkIGluCiAg IFtJLUQuaWV0Zi1vYXV0aC12Mi1iZWFyZXJdIGlzIHV0aWxpemVkIGJ5IHNpbXBseSBpbmNsdWRp bmcgdGhlIGFjY2VzcwogICB0b2tlbiBzdHJpbmcgaW4gdGhlIHJlcXVlc3Q6CgoKICAgICBHRVQg L3Jlc291cmNlLzEgSFRUUC8xLjEKICAgICBIb3N0OiBleGFtcGxlLmNvbQogICAgIEF1dGhvcml6 YXRpb246IEJlYXJlciBtRl85LkI1Zi00LjFKcU0KCgogICB3aGlsZSB0aGUgIm1hYyIgdG9rZW4g dHlwZSBkZWZpbmVkIGluIFtJLUQuaWV0Zi1vYXV0aC12Mi1odHRwLW1hY10gaXMKICAgdXRpbGl6 ZWQgYnkgaXNzdWluZyBhIE1BQyBrZXkgdG9nZXRoZXIgd2l0aCB0aGUgYWNjZXNzIHRva2VuIHdo aWNoIGlzCiAgIHVzZWQgdG8gc2lnbiBjZXJ0YWluIGNvbXBvbmVudHMgb2YgdGhlIEhUVFAgcmVx dWVzdHM6CgoKICAgICBHRVQgL3Jlc291cmNlLzEgSFRUUC8xLjEKICAgICBIb3N0OiBleGFtcGxl LmNvbQogICAgIEF1dGhvcml6YXRpb246IE1BQyBpZD0iaDQ4MGRqczkzaGQ4IiwKICAgICAgICAg ICAgICAgICAgICAgICAgbm9uY2U9IjI3NDMxMjpkajgzaHM5cyIsCiAgICAgICAgICAgICAgICAg ICAgICAgIG1hYz0ia0RadmRka25keHZoR1JYWmh2dURqRVdoR2VFPSIKCgogICBUaGUgYWJvdmUg ZXhhbXBsZXMgYXJlIHByb3ZpZGVkIGZvciBpbGx1c3RyYXRpb24gcHVycG9zZXMgb25seS4KICAg RGV2ZWxvcGVycyBhcmUgYWR2aXNlZCB0byBjb25zdWx0IHRoZSBbSS1ELmlldGYtb2F1dGgtdjIt YmVhcmVyXSBhbmQKICAgW0ktRC5pZXRmLW9hdXRoLXYyLWh0dHAtbWFjXSBzcGVjaWZpY2F0aW9u cyBiZWZvcmUgdXNlLgoKICAgRWFjaCBhY2Nlc3MgdG9rZW4gdHlwZSBkZWZpbml0aW9uIHNwZWNp ZmllcyB0aGUgYWRkaXRpb25hbCBhdHRyaWJ1dGVzCiAgIChpZiBhbnkpIHNlbnQgdG8gdGhlIGNs aWVudCB0b2dldGhlciB3aXRoIHRoZSAiYWNjZXNzX3Rva2VuIiByZXNwb25zZQogICBwYXJhbWV0 ZXIuICBJdCBhbHNvIGRlZmluZXMgdGhlIEhUVFAgYXV0aGVudGljYXRpb24gbWV0aG9kIHVzZWQg dG8KICAgaW5jbHVkZSB0aGUgYWNjZXNzIHRva2VuIHdoZW4gbWFraW5nIGEgcHJvdGVjdGVkIHJl c291cmNlIHJlcXVlc3QuCgoKCgoKCgpIYW1tZXIsIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIERl Y2VtYmVyIDQsIDIwMTIgICAgICAgICAgICAgICBbUGFnZSA0NV0KDApJbnRlcm5ldC1EcmFmdCAg ICAgICAgICAgICAgICAgIE9BdXRoIDIuMCAgICAgICAgICAgICAgICAgICAgICBKdW5lIDIwMTIK Cgo3LjIuICBFcnJvciBSZXNwb25zZQoKICAgSWYgYSByZXNvdXJjZSBhY2Nlc3MgcmVxdWVzdCBm YWlscywgdGhlIHJlc291cmNlIHNlcnZlciBTSE9VTEQgaW5mb3JtCiAgIHRoZSBjbGllbnQgb2Yg dGhlIGVycm9yLiAgV2hpbGUgdGhlIHNwZWNpZmljIGVycm9yIHJlc3BvbnNlcyBwb3NzaWJsZQog ICBhbmQgbWV0aG9kcyBmb3IgdHJhbnNtaXR0aW5nIHRob3NlIGVycm9ycyB3aGVuIHVzaW5nIGFu eSBwYXJ0aWN1bGFyCiAgIGFjY2VzcyB0b2tlbiB0eXBlIGFyZSBiZXlvbmQgdGhlIHNjb3BlIG9m IHRoaXMgc3BlY2lmaWNhdGlvbiwgYW55CiAgICJlcnJvciIgY29kZSB2YWx1ZXMgZGVmaW5lZCBm b3IgdXNlIHdpdGggT0F1dGggcmVzb3VyY2UgYWNjZXNzCiAgIG1ldGhvZHMgTVVTVCBiZSByZWdp c3RlcmVkIChmb2xsb3dpbmcgdGhlIHByb2NlZHVyZXMgaW4KICAgU2VjdGlvbiAxMS40KS4KCiAg IFNwZWNpZmljYWxseSwgd2hlbiB0aGUgT0F1dGggcmVzb3VyY2UgYWNjZXNzIG1ldGhvZCB1c2Vz IGFuICJlcnJvciIKICAgcmVzdWx0IHBhcmFtZXRlciB0byByZXR1cm4gYW4gZXJyb3IgY29kZSB2 YWx1ZSB0aGF0IGluZGljYXRlcyB0aGUKICAgcmVzb3VyY2UgYWNjZXNzIGVycm9yIGVuY291bnRl cmVkLCB0aGVuIHRoZXNlIGVycm9yIGNvZGUgdmFsdWVzIE1VU1QKICAgYmUgcmVnaXN0ZXJlZC4g IFZhbHVlcyBmb3IgdGhlc2UgImVycm9yIiBjb2RlcyBNVVNUIE5PVCBpbmNsdWRlCiAgIGNoYXJh Y3RlcnMgb3V0c2lkZSB0aGUgc2V0ICV4MjAtMjEgLyAleDIzLTVCIC8gJXg1RC03RS4gV2hlbiBh bgogICAiZXJyb3IiIGNvZGUgdmFsdWUgaXMgcmVnaXN0ZXJlZCBmb3IgdXNlIGJ5IGFuIE9BdXRo IHJlc291cmNlIGFjY2VzcwogICBtZXRob2QsIHNob3VsZCB0aGF0IHNhbWUgY29kZSBhbHJlYWR5 IGJlIHJlZ2lzdGVyZWQgZm9yIHVzZSBieQogICBhbm90aGVyIE9BdXRoIHJlc291cmNlIGFjY2Vz cyBtZXRob2Qgb3IgYXQgYSBkaWZmZXJlbnQgT0F1dGggZXJyb3IKICAgdXNhZ2UgbG9jYXRpb24s IHRoZW4gdGhlIG1lYW5pbmcgb2YgdGhhdCBlcnJvciBjb2RlIHZhbHVlIGluIGluIHRoZQogICBu ZXcgcmVnaXN0cmF0aW9uIE1VU1QgYmUgY29uc2lzdGVudCB3aXRoIHRoZSBpdHMgbWVhbmluZyBp biBwcmlvcgogICByZWdpc3RyYXRpb25zLgoKICAgVGhlIE9BdXRoIHJlc291cmNlIGFjY2VzcyBl cnJvciByZWdpc3RyYXRpb24gcmVxdWlyZW1lbnQgYXBwbGllcyBvbmx5CiAgIHRvICJlcnJvciIg Y29kZSB2YWx1ZXMgYW5kIG5vdCB0byBvdGhlciBtZWFucyBvZiByZXR1cm5pbmcgZXJyb3IKICAg aW5kaWNhdGlvbnMsIGluY2x1ZGluZyBIVFRQIHN0YXR1cyBjb2Rlcywgb3Igb3RoZXIgZXJyb3It cmVsYXRlZAogICByZXN1bHQgcGFyYW1ldGVycywgc3VjaCBhcyAiZXJyb3JfZGVzY3JpcHRpb24i LCAiZXJyb3JfdXJpIiwgb3Igb3RoZXIKICAga2luZHMgb2YgZXJyb3Igc3RhdHVzIHJldHVybiBt ZXRob2RzIHRoYXQgbWF5IGJlIGVtcGxveWVkIGJ5IHRoZQogICByZXNvdXJjZSBhY2Nlc3MgbWV0 aG9kLiAgVGhlcmUgaXMgbm8gcmVxdWlyZW1lbnQgdGhhdCBPQXV0aCByZXNvdXJjZQogICBhY2Nl c3MgbWV0aG9kcyBlbXBsb3kgYW4gImVycm9yIiBwYXJhbWV0ZXIuCgoKOC4gIEV4dGVuc2liaWxp dHkKCjguMS4gIERlZmluaW5nIEFjY2VzcyBUb2tlbiBUeXBlcwoKICAgQWNjZXNzIHRva2VuIHR5 cGVzIGNhbiBiZSBkZWZpbmVkIGluIG9uZSBvZiB0d28gd2F5czogcmVnaXN0ZXJlZCBpbgogICB0 aGUgYWNjZXNzIHRva2VuIHR5cGUgcmVnaXN0cnkgKGZvbGxvd2luZyB0aGUgcHJvY2VkdXJlcyBp bgogICBTZWN0aW9uIDExLjEpLCBvciBieSB1c2luZyBhIHVuaXF1ZSBhYnNvbHV0ZSBVUkkgYXMg aXRzIG5hbWUuCgogICBUeXBlcyB1dGlsaXppbmcgYSBVUkkgbmFtZSBTSE9VTEQgYmUgbGltaXRl ZCB0byB2ZW5kb3Itc3BlY2lmaWMKICAgaW1wbGVtZW50YXRpb25zIHRoYXQgYXJlIG5vdCBjb21t b25seSBhcHBsaWNhYmxlLCBhbmQgYXJlIHNwZWNpZmljIHRvCiAgIHRoZSBpbXBsZW1lbnRhdGlv biBkZXRhaWxzIG9mIHRoZSByZXNvdXJjZSBzZXJ2ZXIgd2hlcmUgdGhleSBhcmUKICAgdXNlZC4K CiAgIEFsbCBvdGhlciB0eXBlcyBNVVNUIGJlIHJlZ2lzdGVyZWQuICBUeXBlIG5hbWVzIE1VU1Qg Y29uZm9ybSB0byB0aGUKICAgdHlwZS1uYW1lIEFCTkYuICBJZiB0aGUgdHlwZSBkZWZpbml0aW9u IGluY2x1ZGVzIGEgbmV3IEhUVFAKICAgYXV0aGVudGljYXRpb24gc2NoZW1lLCB0aGUgdHlwZSBu YW1lIFNIT1VMRCBiZSBpZGVudGljYWwgdG8gdGhlIEhUVFAKICAgYXV0aGVudGljYXRpb24gc2No ZW1lIG5hbWUgKGFzIGRlZmluZWQgYnkgW1JGQzI2MTddKS4gIFRoZSB0b2tlbiB0eXBlCgoKCkhh bW1lciwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgRGVjZW1iZXIgNCwgMjAxMiAgICAgICAgICAg ICAgIFtQYWdlIDQ2XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgT0F1dGggMi4w ICAgICAgICAgICAgICAgICAgICAgIEp1bmUgMjAxMgoKCiAgICJleGFtcGxlIiBpcyByZXNlcnZl ZCBmb3IgdXNlIGluIGV4YW1wbGVzLgoKCiAgICAgdHlwZS1uYW1lICA9IDEqbmFtZS1jaGFyCiAg ICAgbmFtZS1jaGFyICA9ICItIiAvICIuIiAvICJfIiAvIERJR0lUIC8gQUxQSEEKCgo4LjIuICBE ZWZpbmluZyBOZXcgRW5kcG9pbnQgUGFyYW1ldGVycwoKICAgTmV3IHJlcXVlc3Qgb3IgcmVzcG9u c2UgcGFyYW1ldGVycyBmb3IgdXNlIHdpdGggdGhlIGF1dGhvcml6YXRpb24KICAgZW5kcG9pbnQg b3IgdGhlIHRva2VuIGVuZHBvaW50IGFyZSBkZWZpbmVkIGFuZCByZWdpc3RlcmVkIGluIHRoZQog ICBwYXJhbWV0ZXJzIHJlZ2lzdHJ5IGZvbGxvd2luZyB0aGUgcHJvY2VkdXJlIGluIFNlY3Rpb24g MTEuMi4KCiAgIFBhcmFtZXRlciBuYW1lcyBNVVNUIGNvbmZvcm0gdG8gdGhlIHBhcmFtLW5hbWUg QUJORiBhbmQgcGFyYW1ldGVyCiAgIHZhbHVlcyBzeW50YXggTVVTVCBiZSB3ZWxsLWRlZmluZWQg KGUuZy4sIHVzaW5nIEFCTkYsIG9yIGEgcmVmZXJlbmNlCiAgIHRvIHRoZSBzeW50YXggb2YgYW4g ZXhpc3RpbmcgcGFyYW1ldGVyKS4KCgogICAgIHBhcmFtLW5hbWUgID0gMSpuYW1lLWNoYXIKICAg ICBuYW1lLWNoYXIgICA9ICItIiAvICIuIiAvICJfIiAvIERJR0lUIC8gQUxQSEEKCgogICBVbnJl Z2lzdGVyZWQgdmVuZG9yLXNwZWNpZmljIHBhcmFtZXRlciBleHRlbnNpb25zIHRoYXQgYXJlIG5v dAogICBjb21tb25seSBhcHBsaWNhYmxlLCBhbmQgYXJlIHNwZWNpZmljIHRvIHRoZSBpbXBsZW1l bnRhdGlvbiBkZXRhaWxzCiAgIG9mIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciB3aGVyZSB0aGV5 IGFyZSB1c2VkIFNIT1VMRCB1dGlsaXplIGEKICAgdmVuZG9yLXNwZWNpZmljIHByZWZpeCB0aGF0 IGlzIG5vdCBsaWtlbHkgdG8gY29uZmxpY3Qgd2l0aCBvdGhlcgogICByZWdpc3RlcmVkIHZhbHVl cyAoZS5nLiBiZWdpbiB3aXRoICdjb21wYW55bmFtZV8nKS4KCjguMy4gIERlZmluaW5nIE5ldyBB dXRob3JpemF0aW9uIEdyYW50IFR5cGVzCgogICBOZXcgYXV0aG9yaXphdGlvbiBncmFudCB0eXBl cyBjYW4gYmUgZGVmaW5lZCBieSBhc3NpZ25pbmcgdGhlbSBhCiAgIHVuaXF1ZSBhYnNvbHV0ZSBV UkkgZm9yIHVzZSB3aXRoIHRoZSAiZ3JhbnRfdHlwZSIgcGFyYW1ldGVyLiAgSWYgdGhlCiAgIGV4 dGVuc2lvbiBncmFudCB0eXBlIHJlcXVpcmVzIGFkZGl0aW9uYWwgdG9rZW4gZW5kcG9pbnQgcGFy YW1ldGVycywKICAgdGhleSBNVVNUIGJlIHJlZ2lzdGVyZWQgaW4gdGhlIE9BdXRoIHBhcmFtZXRl cnMgcmVnaXN0cnkgYXMgZGVzY3JpYmVkCiAgIGJ5IFNlY3Rpb24gMTEuMi4KCjguNC4gIERlZmlu aW5nIE5ldyBBdXRob3JpemF0aW9uIEVuZHBvaW50IFJlc3BvbnNlIFR5cGVzCgogICBOZXcgcmVz cG9uc2UgdHlwZXMgZm9yIHVzZSB3aXRoIHRoZSBhdXRob3JpemF0aW9uIGVuZHBvaW50IGFyZQog ICBkZWZpbmVkIGFuZCByZWdpc3RlcmVkIGluIHRoZSBhdXRob3JpemF0aW9uIGVuZHBvaW50IHJl c3BvbnNlIHR5cGUKICAgcmVnaXN0cnkgZm9sbG93aW5nIHRoZSBwcm9jZWR1cmUgaW4gU2VjdGlv biAxMS4zLiAgUmVzcG9uc2UgdHlwZQogICBuYW1lcyBNVVNUIGNvbmZvcm0gdG8gdGhlIHJlc3Bv bnNlLXR5cGUgQUJORi4KCgogICAgIHJlc3BvbnNlLXR5cGUgID0gcmVzcG9uc2UtbmFtZSAqKCBT UCByZXNwb25zZS1uYW1lICkKICAgICByZXNwb25zZS1uYW1lICA9IDEqcmVzcG9uc2UtY2hhcgog ICAgIHJlc3BvbnNlLWNoYXIgID0gIl8iIC8gRElHSVQgLyBBTFBIQQoKCgoKSGFtbWVyLCBldCBh bC4gICAgICAgICAgRXhwaXJlcyBEZWNlbWJlciA0LCAyMDEyICAgICAgICAgICAgICAgW1BhZ2Ug NDddCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICBPQXV0aCAyLjAgICAgICAgICAg ICAgICAgICAgICAgSnVuZSAyMDEyCgoKICAgSWYgYSByZXNwb25zZSB0eXBlIGNvbnRhaW5zIG9u ZSBvciBtb3JlIHNwYWNlIGNoYXJhY3RlcnMgKCV4MjApLCBpdAogICBpcyBjb21wYXJlZCBhcyBh IHNwYWNlLWRlbGltaXRlZCBsaXN0IG9mIHZhbHVlcyBpbiB3aGljaCB0aGUgb3JkZXIgb2YKICAg dmFsdWVzIGRvZXMgbm90IG1hdHRlci4gIE9ubHkgb25lIG9yZGVyIG9mIHZhbHVlcyBjYW4gYmUg cmVnaXN0ZXJlZCwKICAgd2hpY2ggY292ZXJzIGFsbCBvdGhlciBhcnJhbmdlbWVudHMgb2YgdGhl IHNhbWUgc2V0IG9mIHZhbHVlcy4KCiAgIEZvciBleGFtcGxlLCB0aGUgcmVzcG9uc2UgdHlwZSAi dG9rZW4gY29kZSIgaXMgbGVmdCB1bmRlZmluZWQgYnkgdGhpcwogICBzcGVjaWZpY2F0aW9uLiAg SG93ZXZlciwgYW4gZXh0ZW5zaW9uIGNhbiBkZWZpbmUgYW5kIHJlZ2lzdGVyIHRoZQogICAidG9r ZW4gY29kZSIgcmVzcG9uc2UgdHlwZS4gIE9uY2UgcmVnaXN0ZXJlZCwgdGhlIHNhbWUgY29tYmlu YXRpb24KICAgY2Fubm90IGJlIHJlZ2lzdGVyZWQgYXMgImNvZGUgdG9rZW4iLCBidXQgYm90aCB2 YWx1ZXMgY2FuIGJlIHVzZWQgdG8KICAgZGVub3RlIHRoZSBzYW1lIHJlc3BvbnNlIHR5cGUuCgo4 LjUuICBEZWZpbmluZyBBZGRpdGlvbmFsIEVycm9yIENvZGVzCgogICBJbiBjYXNlcyB3aGVyZSBw cm90b2NvbCBleHRlbnNpb25zIChpLmUuIGFjY2VzcyB0b2tlbiB0eXBlcywKICAgZXh0ZW5zaW9u IHBhcmFtZXRlcnMsIG9yIGV4dGVuc2lvbiBncmFudCB0eXBlcykgcmVxdWlyZSBhZGRpdGlvbmFs CiAgIGVycm9yIGNvZGVzIHRvIGJlIHVzZWQgd2l0aCB0aGUgYXV0aG9yaXphdGlvbiBjb2RlIGdy YW50IGVycm9yCiAgIHJlc3BvbnNlIChTZWN0aW9uIDQuMS4yLjEpLCB0aGUgaW1wbGljaXQgZ3Jh bnQgZXJyb3IgcmVzcG9uc2UKICAgKFNlY3Rpb24gNC4yLjIuMSksIHRoZSB0b2tlbiBlcnJvciBy ZXNwb25zZSAoU2VjdGlvbiA1LjIpLCBvciB0aGUKICAgcmVzb3VyY2UgYWNjZXNzIGVycm9yIHJl c3BvbnNlIChTZWN0aW9uIDcuMiksIHN1Y2ggZXJyb3IgY29kZXMgTUFZIGJlCiAgIGRlZmluZWQu CgogICBFeHRlbnNpb24gZXJyb3IgY29kZXMgTVVTVCBiZSByZWdpc3RlcmVkIChmb2xsb3dpbmcg dGhlIHByb2NlZHVyZXMgaW4KICAgU2VjdGlvbiAxMS40KSBpZiB0aGUgZXh0ZW5zaW9uIHRoZXkg YXJlIHVzZWQgaW4gY29uanVuY3Rpb24gd2l0aCBpcyBhCiAgIHJlZ2lzdGVyZWQgYWNjZXNzIHRv a2VuIHR5cGUsIGEgcmVnaXN0ZXJlZCBlbmRwb2ludCBwYXJhbWV0ZXIsIG9yIGFuCiAgIGV4dGVu c2lvbiBncmFudCB0eXBlLiAgRXJyb3IgY29kZXMgdXNlZCB3aXRoIHVucmVnaXN0ZXJlZCBleHRl bnNpb25zCiAgIE1BWSBiZSByZWdpc3RlcmVkLgoKICAgRXJyb3IgY29kZXMgTVVTVCBjb25mb3Jt IHRvIHRoZSBlcnJvciBBQk5GLCBhbmQgU0hPVUxEIGJlIHByZWZpeGVkIGJ5CiAgIGFuIGlkZW50 aWZ5aW5nIG5hbWUgd2hlbiBwb3NzaWJsZS4gIEZvciBleGFtcGxlLCBhbiBlcnJvciBpZGVudGlm eWluZwogICBhbiBpbnZhbGlkIHZhbHVlIHNldCB0byB0aGUgZXh0ZW5zaW9uIHBhcmFtZXRlciAi ZXhhbXBsZSIgU0hPVUxEIGJlCiAgIG5hbWVkICJleGFtcGxlX2ludmFsaWQiLgoKCiAgICAgZXJy b3IgICAgICA9IDEqZXJyb3ItY2hhcgogICAgIGVycm9yLWNoYXIgPSAleDIwLTIxIC8gJXgyMy01 QiAvICV4NUQtN0UKCgoKOS4gIE5hdGl2ZSBBcHBsaWNhdGlvbnMKCiAgIE5hdGl2ZSBhcHBsaWNh dGlvbnMgYXJlIGNsaWVudHMgaW5zdGFsbGVkIGFuZCBleGVjdXRlZCBvbiB0aGUgZGV2aWNlCiAg IHVzZWQgYnkgdGhlIHJlc291cmNlIG93bmVyIChpLmUuIGRlc2t0b3AgYXBwbGljYXRpb24sIG5h dGl2ZSBtb2JpbGUKICAgYXBwbGljYXRpb24pLiAgTmF0aXZlIGFwcGxpY2F0aW9ucyByZXF1aXJl IHNwZWNpYWwgY29uc2lkZXJhdGlvbgogICByZWxhdGVkIHRvIHNlY3VyaXR5LCBwbGF0Zm9ybSBj YXBhYmlsaXRpZXMsIGFuZCBvdmVyYWxsIGVuZC11c2VyCiAgIGV4cGVyaWVuY2UuCgogICBUaGUg YXV0aG9yaXphdGlvbiBlbmRwb2ludCByZXF1aXJlcyBpbnRlcmFjdGlvbiBiZXR3ZWVuIHRoZSBj bGllbnQKICAgYW5kIHRoZSByZXNvdXJjZSBvd25lcidzIHVzZXItYWdlbnQuICBOYXRpdmUgYXBw bGljYXRpb25zIGNhbiBpbnZva2UKCgoKSGFtbWVyLCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBE ZWNlbWJlciA0LCAyMDEyICAgICAgICAgICAgICAgW1BhZ2UgNDhdCgwKSW50ZXJuZXQtRHJhZnQg ICAgICAgICAgICAgICAgICBPQXV0aCAyLjAgICAgICAgICAgICAgICAgICAgICAgSnVuZSAyMDEy CgoKICAgYW4gZXh0ZXJuYWwgdXNlci1hZ2VudCBvciBlbWJlZCBhIHVzZXItYWdlbnQgd2l0aGlu IHRoZSBhcHBsaWNhdGlvbi4KICAgRm9yIGV4YW1wbGU6CgogICBvICBFeHRlcm5hbCB1c2VyLWFn ZW50IC0gdGhlIG5hdGl2ZSBhcHBsaWNhdGlvbiBjYW4gY2FwdHVyZSB0aGUKICAgICAgcmVzcG9u c2UgZnJvbSB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgdXNpbmcgYSByZWRpcmVjdGlvbiBVUkkK ICAgICAgd2l0aCBhIHNjaGVtZSByZWdpc3RlcmVkIHdpdGggdGhlIG9wZXJhdGluZyBzeXN0ZW0g dG8gaW52b2tlIHRoZQogICAgICBjbGllbnQgYXMgdGhlIGhhbmRsZXIsIG1hbnVhbCBjb3B5LWFu ZC1wYXN0ZSBvZiB0aGUgY3JlZGVudGlhbHMsCiAgICAgIHJ1bm5pbmcgYSBsb2NhbCB3ZWIgc2Vy dmVyLCBpbnN0YWxsaW5nIGEgdXNlci1hZ2VudCBleHRlbnNpb24sIG9yCiAgICAgIGJ5IHByb3Zp ZGluZyBhIHJlZGlyZWN0aW9uIFVSSSBpZGVudGlmeWluZyBhIHNlcnZlci1ob3N0ZWQKICAgICAg cmVzb3VyY2UgdW5kZXIgdGhlIGNsaWVudCdzIGNvbnRyb2wsIHdoaWNoIGluIHR1cm4gbWFrZXMg dGhlCiAgICAgIHJlc3BvbnNlIGF2YWlsYWJsZSB0byB0aGUgbmF0aXZlIGFwcGxpY2F0aW9uLgog ICBvICBFbWJlZGRlZCB1c2VyLWFnZW50IC0gdGhlIG5hdGl2ZSBhcHBsaWNhdGlvbiBvYnRhaW5z IHRoZSByZXNwb25zZQogICAgICBieSBkaXJlY3RseSBjb21tdW5pY2F0aW5nIHdpdGggdGhlIGVt YmVkZGVkIHVzZXItYWdlbnQgYnkKICAgICAgbW9uaXRvcmluZyBzdGF0ZSBjaGFuZ2VzIGVtaXR0 ZWQgZHVyaW5nIHRoZSByZXNvdXJjZSBsb2FkLCBvcgogICAgICBhY2Nlc3NpbmcgdGhlIHVzZXIt YWdlbnQncyBjb29raWVzIHN0b3JhZ2UuCgogICBXaGVuIGNob29zaW5nIGJldHdlZW4gYW4gZXh0 ZXJuYWwgb3IgZW1iZWRkZWQgdXNlci1hZ2VudCwgZGV2ZWxvcGVycwogICBzaG91bGQgY29uc2lk ZXI6CgogICBvICBBbiBFeHRlcm5hbCB1c2VyLWFnZW50IG1heSBpbXByb3ZlIGNvbXBsZXRpb24g cmF0ZSBhcyB0aGUgcmVzb3VyY2UKICAgICAgb3duZXIgbWF5IGFscmVhZHkgaGF2ZSBhbiBhY3Rp dmUgc2Vzc2lvbiB3aXRoIHRoZSBhdXRob3JpemF0aW9uCiAgICAgIHNlcnZlciByZW1vdmluZyB0 aGUgbmVlZCB0byByZS1hdXRoZW50aWNhdGUuICBJdCBwcm92aWRlcyBhCiAgICAgIGZhbWlsaWFy IGVuZC11c2VyIGV4cGVyaWVuY2UgYW5kIGZ1bmN0aW9uYWxpdHkuICBUaGUgcmVzb3VyY2UKICAg ICAgb3duZXIgbWF5IGFsc28gcmVseSBvbiB1c2VyLWFnZW50IGZlYXR1cmVzIG9yIGV4dGVuc2lv bnMgdG8gYXNzaXN0CiAgICAgIHdpdGggYXV0aGVudGljYXRpb24gKGUuZy4gcGFzc3dvcmQgbWFu YWdlciwgMi1mYWN0b3IgZGV2aWNlCiAgICAgIHJlYWRlcikuCiAgIG8gIEFuIGVtYmVkZGVkIHVz ZXItYWdlbnQgbWF5IG9mZmVyIGltcHJvdmVkIHVzYWJpbGl0eSwgYXMgaXQgcmVtb3ZlcwogICAg ICB0aGUgbmVlZCB0byBzd2l0Y2ggY29udGV4dCBhbmQgb3BlbiBuZXcgd2luZG93cy4KICAgbyAg QW4gZW1iZWRkZWQgdXNlci1hZ2VudCBwb3NlcyBhIHNlY3VyaXR5IGNoYWxsZW5nZSBiZWNhdXNl IHJlc291cmNlCiAgICAgIG93bmVycyBhcmUgYXV0aGVudGljYXRpbmcgaW4gYW4gdW5pZGVudGlm aWVkIHdpbmRvdyB3aXRob3V0IGFjY2VzcwogICAgICB0byB0aGUgdmlzdWFsIHByb3RlY3Rpb25z IGZvdW5kIGluIG1vc3QgZXh0ZXJuYWwgdXNlci1hZ2VudHMuICBBbgogICAgICBlbWJlZGRlZCB1 c2VyLWFnZW50IGVkdWNhdGVzIGVuZC11c2VycyB0byB0cnVzdCB1bmlkZW50aWZpZWQKICAgICAg cmVxdWVzdHMgZm9yIGF1dGhlbnRpY2F0aW9uIChtYWtpbmcgcGhpc2hpbmcgYXR0YWNrcyBlYXNp ZXIgdG8KICAgICAgZXhlY3V0ZSkuCgogICBXaGVuIGNob29zaW5nIGJldHdlZW4gdGhlIGltcGxp Y2l0IGdyYW50IHR5cGUgYW5kIHRoZSBhdXRob3JpemF0aW9uCiAgIGNvZGUgZ3JhbnQgdHlwZSwg dGhlIGZvbGxvd2luZyBzaG91bGQgYmUgY29uc2lkZXJlZDoKCiAgIG8gIE5hdGl2ZSBhcHBsaWNh dGlvbnMgdGhhdCB1c2UgdGhlIGF1dGhvcml6YXRpb24gY29kZSBncmFudCB0eXBlCiAgICAgIFNI T1VMRCBkbyBzbyB3aXRob3V0IHVzaW5nIGNsaWVudCBjcmVkZW50aWFscywgZHVlIHRvIHRoZSBu YXRpdmUKICAgICAgYXBwbGljYXRpb24ncyBpbmFiaWxpdHkgdG8ga2VlcCBjbGllbnQgY3JlZGVu dGlhbHMgY29uZmlkZW50aWFsLgogICBvICBXaGVuIHVzaW5nIHRoZSBpbXBsaWNpdCBncmFudCB0 eXBlIGZsb3cgYSByZWZyZXNoIHRva2VuIGlzIG5vdAogICAgICByZXR1cm5lZCB3aGljaCByZXF1 aXJlcyByZXBlYXRpbmcgdGhlIGF1dGhvcml6YXRpb24gcHJvY2VzcyBvbmNlCiAgICAgIHRoZSBh Y2Nlc3MgdG9rZW4gZXhwaXJlcy4KCgoKCgoKCkhhbW1lciwgZXQgYWwuICAgICAgICAgIEV4cGly ZXMgRGVjZW1iZXIgNCwgMjAxMiAgICAgICAgICAgICAgIFtQYWdlIDQ5XQoMCkludGVybmV0LURy YWZ0ICAgICAgICAgICAgICAgICAgT0F1dGggMi4wICAgICAgICAgICAgICAgICAgICAgIEp1bmUg MjAxMgoKCjEwLiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMKCiAgIEFzIGEgZmxleGlibGUgYW5k IGV4dGVuc2libGUgZnJhbWV3b3JrLCBPQXV0aCdzIHNlY3VyaXR5CiAgIGNvbnNpZGVyYXRpb25z IGRlcGVuZCBvbiBtYW55IGZhY3RvcnMuICBUaGUgZm9sbG93aW5nIHNlY3Rpb25zCiAgIHByb3Zp ZGUgaW1wbGVtZW50ZXJzIHdpdGggc2VjdXJpdHkgZ3VpZGVsaW5lcyBmb2N1c2VkIG9uIHRoZSB0 aHJlZQogICBjbGllbnQgcHJvZmlsZXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gMi4xOiB3ZWIgYXBw bGljYXRpb24sIHVzZXItCiAgIGFnZW50LWJhc2VkIGFwcGxpY2F0aW9uLCBhbmQgbmF0aXZlIGFw cGxpY2F0aW9uLgoKICAgQSBjb21wcmVoZW5zaXZlIE9BdXRoIHNlY3VyaXR5IG1vZGVsIGFuZCBh bmFseXNpcywgYXMgd2VsbCBhcwogICBiYWNrZ3JvdW5kIGZvciB0aGUgcHJvdG9jb2wgZGVzaWdu IGlzIHByb3ZpZGVkIGJ5CiAgIFtJLUQuaWV0Zi1vYXV0aC12Mi10aHJlYXRtb2RlbF0uCgoxMC4x LiAgQ2xpZW50IEF1dGhlbnRpY2F0aW9uCgogICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgZXN0 YWJsaXNoZXMgY2xpZW50IGNyZWRlbnRpYWxzIHdpdGggd2ViCiAgIGFwcGxpY2F0aW9uIGNsaWVu dHMgZm9yIHRoZSBwdXJwb3NlIG9mIGNsaWVudCBhdXRoZW50aWNhdGlvbi4gIFRoZQogICBhdXRo b3JpemF0aW9uIHNlcnZlciBpcyBlbmNvdXJhZ2VkIHRvIGNvbnNpZGVyIHN0cm9uZ2VyIGNsaWVu dAogICBhdXRoZW50aWNhdGlvbiBtZWFucyB0aGFuIGEgY2xpZW50IHBhc3N3b3JkLiAgV2ViIGFw cGxpY2F0aW9uIGNsaWVudHMKICAgTVVTVCBlbnN1cmUgY29uZmlkZW50aWFsaXR5IG9mIGNsaWVu dCBwYXNzd29yZHMgYW5kIG90aGVyIGNsaWVudAogICBjcmVkZW50aWFscy4KCiAgIFRoZSBhdXRo b3JpemF0aW9uIHNlcnZlciBNVVNUIE5PVCBpc3N1ZSBjbGllbnQgcGFzc3dvcmRzIG9yIG90aGVy CiAgIGNsaWVudCBjcmVkZW50aWFscyB0byBuYXRpdmUgYXBwbGljYXRpb24gb3IgdXNlci1hZ2Vu dC1iYXNlZAogICBhcHBsaWNhdGlvbiBjbGllbnRzIGZvciB0aGUgcHVycG9zZSBvZiBjbGllbnQg YXV0aGVudGljYXRpb24uICBUaGUKICAgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTUFZIGlzc3VlIGEg Y2xpZW50IHBhc3N3b3JkIG9yIG90aGVyIGNyZWRlbnRpYWxzCiAgIGZvciBhIHNwZWNpZmljIGlu c3RhbGxhdGlvbiBvZiBhIG5hdGl2ZSBhcHBsaWNhdGlvbiBjbGllbnQgb24gYQogICBzcGVjaWZp YyBkZXZpY2UuCgogICBXaGVuIGNsaWVudCBhdXRoZW50aWNhdGlvbiBpcyBub3QgcG9zc2libGUs IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlcgogICBTSE9VTEQgZW1wbG95IG90aGVyIG1lYW5zIHRv IHZhbGlkYXRlIHRoZSBjbGllbnQncyBpZGVudGl0eS4gIEZvcgogICBleGFtcGxlLCBieSByZXF1 aXJpbmcgdGhlIHJlZ2lzdHJhdGlvbiBvZiB0aGUgY2xpZW50IHJlZGlyZWN0aW9uIFVSSQogICBv ciBlbmxpc3RpbmcgdGhlIHJlc291cmNlIG93bmVyIHRvIGNvbmZpcm0gaWRlbnRpdHkuICBBIHZh bGlkCiAgIHJlZGlyZWN0aW9uIFVSSSBpcyBub3Qgc3VmZmljaWVudCB0byB2ZXJpZnkgdGhlIGNs aWVudCdzIGlkZW50aXR5CiAgIHdoZW4gYXNraW5nIGZvciByZXNvdXJjZSBvd25lciBhdXRob3Jp emF0aW9uLCBidXQgY2FuIGJlIHVzZWQgdG8KICAgcHJldmVudCBkZWxpdmVyaW5nIGNyZWRlbnRp YWxzIHRvIGEgY291bnRlcmZlaXQgY2xpZW50IGFmdGVyCiAgIG9idGFpbmluZyByZXNvdXJjZSBv d25lciBhdXRob3JpemF0aW9uLgoKICAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIG11c3QgY29u c2lkZXIgdGhlIHNlY3VyaXR5IGltcGxpY2F0aW9ucyBvZgogICBpbnRlcmFjdGluZyB3aXRoIHVu YXV0aGVudGljYXRlZCBjbGllbnRzIGFuZCB0YWtlIG1lYXN1cmVzIHRvIGxpbWl0CiAgIHRoZSBw b3RlbnRpYWwgZXhwb3N1cmUgb2Ygb3RoZXIgY3JlZGVudGlhbHMgKGUuZy4gcmVmcmVzaCB0b2tl bnMpCiAgIGlzc3VlZCB0byBzdWNoIGNsaWVudHMuCgoxMC4yLiAgQ2xpZW50IEltcGVyc29uYXRp b24KCiAgIEEgbWFsaWNpb3VzIGNsaWVudCBjYW4gaW1wZXJzb25hdGUgYW5vdGhlciBjbGllbnQg YW5kIG9idGFpbiBhY2Nlc3MKICAgdG8gcHJvdGVjdGVkIHJlc291cmNlcywgaWYgdGhlIGltcGVy c29uYXRlZCBjbGllbnQgZmFpbHMgdG8sIG9yIGlzCiAgIHVuYWJsZSB0bywga2VlcCBpdHMgY2xp ZW50IGNyZWRlbnRpYWxzIGNvbmZpZGVudGlhbC4KCgoKCkhhbW1lciwgZXQgYWwuICAgICAgICAg IEV4cGlyZXMgRGVjZW1iZXIgNCwgMjAxMiAgICAgICAgICAgICAgIFtQYWdlIDUwXQoMCkludGVy bmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgT0F1dGggMi4wICAgICAgICAgICAgICAgICAgICAg IEp1bmUgMjAxMgoKCiAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBNVVNUIGF1dGhlbnRpY2F0 ZSB0aGUgY2xpZW50IHdoZW5ldmVyCiAgIHBvc3NpYmxlLiAgSWYgdGhlIGF1dGhvcml6YXRpb24g c2VydmVyIGNhbm5vdCBhdXRoZW50aWNhdGUgdGhlIGNsaWVudAogICBkdWUgdG8gdGhlIGNsaWVu dCdzIG5hdHVyZSwgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIE1VU1QgcmVxdWlyZSB0aGUKICAg cmVnaXN0cmF0aW9uIG9mIGFueSByZWRpcmVjdGlvbiBVUkkgdXNlZCBmb3IgcmVjZWl2aW5nIGF1 dGhvcml6YXRpb24KICAgcmVzcG9uc2VzLCBhbmQgU0hPVUxEIHV0aWxpemUgb3RoZXIgbWVhbnMg dG8gcHJvdGVjdCByZXNvdXJjZSBvd25lcnMKICAgZnJvbSBzdWNoIHBvdGVudGlhbGx5IG1hbGlj aW91cyBjbGllbnRzLiAgRm9yIGV4YW1wbGUsIHRoZQogICBhdXRob3JpemF0aW9uIHNlcnZlciBj YW4gZW5nYWdlIHRoZSByZXNvdXJjZSBvd25lciB0byBhc3Npc3QgaW4KICAgaWRlbnRpZnlpbmcg dGhlIGNsaWVudCBhbmQgaXRzIG9yaWdpbi4KCiAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBT SE9VTEQgZW5mb3JjZSBleHBsaWNpdCByZXNvdXJjZSBvd25lcgogICBhdXRoZW50aWNhdGlvbiBh bmQgcHJvdmlkZSB0aGUgcmVzb3VyY2Ugb3duZXIgd2l0aCBpbmZvcm1hdGlvbiBhYm91dAogICB0 aGUgY2xpZW50IGFuZCB0aGUgcmVxdWVzdGVkIGF1dGhvcml6YXRpb24gc2NvcGUgYW5kIGxpZmV0 aW1lLiAgSXQgaXMKICAgdXAgdG8gdGhlIHJlc291cmNlIG93bmVyIHRvIHJldmlldyB0aGUgaW5m b3JtYXRpb24gaW4gdGhlIGNvbnRleHQgb2YKICAgdGhlIGN1cnJlbnQgY2xpZW50LCBhbmQgYXV0 aG9yaXplIG9yIGRlbnkgdGhlIHJlcXVlc3QuCgogICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIg U0hPVUxEIE5PVCBwcm9jZXNzIHJlcGVhdGVkIGF1dGhvcml6YXRpb24KICAgcmVxdWVzdHMgYXV0 b21hdGljYWxseSAod2l0aG91dCBhY3RpdmUgcmVzb3VyY2Ugb3duZXIgaW50ZXJhY3Rpb24pCiAg IHdpdGhvdXQgYXV0aGVudGljYXRpbmcgdGhlIGNsaWVudCBvciByZWx5aW5nIG9uIG90aGVyIG1l YXN1cmVzIHRvCiAgIGVuc3VyZSB0aGUgcmVwZWF0ZWQgcmVxdWVzdCBjb21lcyBmcm9tIHRoZSBv cmlnaW5hbCBjbGllbnQgYW5kIG5vdCBhbgogICBpbXBlcnNvbmF0b3IuCgoxMC4zLiAgQWNjZXNz IFRva2VucwoKICAgQWNjZXNzIHRva2VuIGNyZWRlbnRpYWxzIChhcyB3ZWxsIGFzIGFueSBjb25m aWRlbnRpYWwgYWNjZXNzIHRva2VuCiAgIGF0dHJpYnV0ZXMpIE1VU1QgYmUga2VwdCBjb25maWRl bnRpYWwgaW4gdHJhbnNpdCBhbmQgc3RvcmFnZSwgYW5kCiAgIG9ubHkgc2hhcmVkIGFtb25nIHRo ZSBhdXRob3JpemF0aW9uIHNlcnZlciwgdGhlIHJlc291cmNlIHNlcnZlcnMgdGhlCiAgIGFjY2Vz cyB0b2tlbiBpcyB2YWxpZCBmb3IsIGFuZCB0aGUgY2xpZW50IHRvIHdob20gdGhlIGFjY2VzcyB0 b2tlbiBpcwogICBpc3N1ZWQuICBBY2Nlc3MgdG9rZW4gY3JlZGVudGlhbHMgTVVTVCBvbmx5IGJl IHRyYW5zbWl0dGVkIHVzaW5nIFRMUwogICBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiAxLjYgd2l0 aCBzZXJ2ZXIgYXV0aGVudGljYXRpb24gYXMgZGVmaW5lZCBieQogICBbUkZDMjgxOF0uCgogICBX aGVuIHVzaW5nIHRoZSBpbXBsaWNpdCBncmFudCB0eXBlLCB0aGUgYWNjZXNzIHRva2VuIGlzIHRy YW5zbWl0dGVkCiAgIGluIHRoZSBVUkkgZnJhZ21lbnQsIHdoaWNoIGNhbiBleHBvc2UgaXQgdG8g dW5hdXRob3JpemVkIHBhcnRpZXMuCgogICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVTVCBl bnN1cmUgdGhhdCBhY2Nlc3MgdG9rZW5zIGNhbm5vdCBiZQogICBnZW5lcmF0ZWQsIG1vZGlmaWVk LCBvciBndWVzc2VkIHRvIHByb2R1Y2UgdmFsaWQgYWNjZXNzIHRva2VucyBieQogICB1bmF1dGhv cml6ZWQgcGFydGllcy4KCiAgIFRoZSBjbGllbnQgU0hPVUxEIHJlcXVlc3QgYWNjZXNzIHRva2Vu cyB3aXRoIHRoZSBtaW5pbWFsIHNjb3BlCiAgIG5lY2Vzc2FyeS4gIFRoZSBhdXRob3JpemF0aW9u IHNlcnZlciBTSE9VTEQgdGFrZSB0aGUgY2xpZW50IGlkZW50aXR5CiAgIGludG8gYWNjb3VudCB3 aGVuIGNob29zaW5nIGhvdyB0byBob25vciB0aGUgcmVxdWVzdGVkIHNjb3BlLCBhbmQgTUFZCiAg IGlzc3VlIGFuIGFjY2VzcyB0b2tlbiB3aXRoIGEgbGVzcyByaWdodHMgdGhhbiByZXF1ZXN0ZWQu CgogICBUaGlzIHNwZWNpZmljYXRpb24gZG9lcyBub3QgcHJvdmlkZSBhbnkgbWV0aG9kcyBmb3Ig dGhlIHJlc291cmNlCiAgIHNlcnZlciB0byBlbnN1cmUgdGhhdCBhbiBhY2Nlc3MgdG9rZW4gcHJl c2VudGVkIHRvIGl0IGJ5IGEgZ2l2ZW4KICAgY2xpZW50IHdhcyBpc3N1ZWQgdG8gdGhhdCBjbGll bnQgYnkgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLgoKCgoKCkhhbW1lciwgZXQgYWwuICAgICAg ICAgIEV4cGlyZXMgRGVjZW1iZXIgNCwgMjAxMiAgICAgICAgICAgICAgIFtQYWdlIDUxXQoMCklu dGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgT0F1dGggMi4wICAgICAgICAgICAgICAgICAg ICAgIEp1bmUgMjAxMgoKCjEwLjQuICBSZWZyZXNoIFRva2VucwoKICAgQXV0aG9yaXphdGlvbiBz ZXJ2ZXJzIE1BWSBpc3N1ZSByZWZyZXNoIHRva2VucyB0byB3ZWIgYXBwbGljYXRpb24KICAgY2xp ZW50cyBhbmQgbmF0aXZlIGFwcGxpY2F0aW9uIGNsaWVudHMuCgogICBSZWZyZXNoIHRva2VucyBN VVNUIGJlIGtlcHQgY29uZmlkZW50aWFsIGluIHRyYW5zaXQgYW5kIHN0b3JhZ2UsIGFuZAogICBz aGFyZWQgb25seSBhbW9uZyB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYW5kIHRoZSBjbGllbnQg dG8gd2hvbSB0aGUKICAgcmVmcmVzaCB0b2tlbnMgd2VyZSBpc3N1ZWQuICBUaGUgYXV0aG9yaXph dGlvbiBzZXJ2ZXIgTVVTVCBtYWludGFpbgogICB0aGUgYmluZGluZyBiZXR3ZWVuIGEgcmVmcmVz aCB0b2tlbiBhbmQgdGhlIGNsaWVudCB0byB3aG9tIGl0IHdhcwogICBpc3N1ZWQuICBSZWZyZXNo IHRva2VucyBNVVNUIG9ubHkgYmUgdHJhbnNtaXR0ZWQgdXNpbmcgVExTIGFzCiAgIGRlc2NyaWJl ZCBpbiBTZWN0aW9uIDEuNiB3aXRoIHNlcnZlciBhdXRoZW50aWNhdGlvbiBhcyBkZWZpbmVkIGJ5 CiAgIFtSRkMyODE4XS4KCiAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBNVVNUIHZlcmlmeSB0 aGUgYmluZGluZyBiZXR3ZWVuIHRoZSByZWZyZXNoCiAgIHRva2VuIGFuZCBjbGllbnQgaWRlbnRp dHkgd2hlbmV2ZXIgdGhlIGNsaWVudCBpZGVudGl0eSBjYW4gYmUKICAgYXV0aGVudGljYXRlZC4g IFdoZW4gY2xpZW50IGF1dGhlbnRpY2F0aW9uIGlzIG5vdCBwb3NzaWJsZSwgdGhlCiAgIGF1dGhv cml6YXRpb24gc2VydmVyIFNIT1VMRCBkZXBsb3kgb3RoZXIgbWVhbnMgdG8gZGV0ZWN0IHJlZnJl c2gKICAgdG9rZW4gYWJ1c2UuCgogICBGb3IgZXhhbXBsZSwgdGhlIGF1dGhvcml6YXRpb24gc2Vy dmVyIGNvdWxkIGVtcGxveSByZWZyZXNoIHRva2VuCiAgIHJvdGF0aW9uIGluIHdoaWNoIGEgbmV3 IHJlZnJlc2ggdG9rZW4gaXMgaXNzdWVkIHdpdGggZXZlcnkgYWNjZXNzCiAgIHRva2VuIHJlZnJl c2ggcmVzcG9uc2UuICBUaGUgcHJldmlvdXMgcmVmcmVzaCB0b2tlbiBpcyBpbnZhbGlkYXRlZAog ICBidXQgcmV0YWluZWQgYnkgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLiAgSWYgYSByZWZyZXNo IHRva2VuIGlzCiAgIGNvbXByb21pc2VkIGFuZCBzdWJzZXF1ZW50bHkgdXNlZCBieSBib3RoIHRo ZSBhdHRhY2tlciBhbmQgdGhlCiAgIGxlZ2l0aW1hdGUgY2xpZW50LCBvbmUgb2YgdGhlbSB3aWxs IHByZXNlbnQgYW4gaW52YWxpZGF0ZWQgcmVmcmVzaAogICB0b2tlbiB3aGljaCB3aWxsIGluZm9y bSB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgb2YgdGhlIGJyZWFjaC4KCiAgIFRoZSBhdXRob3Jp emF0aW9uIHNlcnZlciBNVVNUIGVuc3VyZSB0aGF0IHJlZnJlc2ggdG9rZW5zIGNhbm5vdCBiZQog ICBnZW5lcmF0ZWQsIG1vZGlmaWVkLCBvciBndWVzc2VkIHRvIHByb2R1Y2UgdmFsaWQgcmVmcmVz aCB0b2tlbnMgYnkKICAgdW5hdXRob3JpemVkIHBhcnRpZXMuCgoxMC41LiAgQXV0aG9yaXphdGlv biBDb2RlcwoKICAgVGhlIHRyYW5zbWlzc2lvbiBvZiBhdXRob3JpemF0aW9uIGNvZGVzIFNIT1VM RCBiZSBtYWRlIG92ZXIgYSBzZWN1cmUKICAgY2hhbm5lbCwgYW5kIHRoZSBjbGllbnQgU0hPVUxE IHJlcXVpcmUgdGhlIHVzZSBvZiBUTFMgd2l0aCBpdHMKICAgcmVkaXJlY3Rpb24gVVJJIGlmIHRo ZSBVUkkgaWRlbnRpZmllcyBhIG5ldHdvcmsgcmVzb3VyY2UuICBTaW5jZQogICBhdXRob3JpemF0 aW9uIGNvZGVzIGFyZSB0cmFuc21pdHRlZCB2aWEgdXNlci1hZ2VudCByZWRpcmVjdGlvbnMsIHRo ZXkKICAgY291bGQgcG90ZW50aWFsbHkgYmUgZGlzY2xvc2VkIHRocm91Z2ggdXNlci1hZ2VudCBo aXN0b3J5IGFuZCBIVFRQCiAgIHJlZmVycmVyIGhlYWRlcnMuCgogICBBdXRob3JpemF0aW9uIGNv ZGVzIG9wZXJhdGUgYXMgcGxhaW50ZXh0IGJlYXJlciBjcmVkZW50aWFscywgdXNlZCB0bwogICB2 ZXJpZnkgdGhhdCB0aGUgcmVzb3VyY2Ugb3duZXIgd2hvIGdyYW50ZWQgYXV0aG9yaXphdGlvbiBh dCB0aGUKICAgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgaXMgdGhlIHNhbWUgcmVzb3VyY2Ugb3duZXIg cmV0dXJuaW5nIHRvIHRoZQogICBjbGllbnQgdG8gY29tcGxldGUgdGhlIHByb2Nlc3MuICBUaGVy ZWZvcmUsIGlmIHRoZSBjbGllbnQgcmVsaWVzIG9uCiAgIHRoZSBhdXRob3JpemF0aW9uIGNvZGUg Zm9yIGl0cyBvd24gcmVzb3VyY2Ugb3duZXIgYXV0aGVudGljYXRpb24sIHRoZQogICBjbGllbnQg cmVkaXJlY3Rpb24gZW5kcG9pbnQgTVVTVCByZXF1aXJlIHRoZSB1c2Ugb2YgVExTLgoKICAgQXV0 aG9yaXphdGlvbiBjb2RlcyBNVVNUIGJlIHNob3J0IGxpdmVkIGFuZCBzaW5nbGUgdXNlLiAgSWYg dGhlCgoKCkhhbW1lciwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgRGVjZW1iZXIgNCwgMjAxMiAg ICAgICAgICAgICAgIFtQYWdlIDUyXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAg T0F1dGggMi4wICAgICAgICAgICAgICAgICAgICAgIEp1bmUgMjAxMgoKCiAgIGF1dGhvcml6YXRp b24gc2VydmVyIG9ic2VydmVzIG11bHRpcGxlIGF0dGVtcHRzIHRvIGV4Y2hhbmdlIGFuCiAgIGF1 dGhvcml6YXRpb24gY29kZSBmb3IgYW4gYWNjZXNzIHRva2VuLCB0aGUgYXV0aG9yaXphdGlvbiBz ZXJ2ZXIKICAgU0hPVUxEIGF0dGVtcHQgdG8gcmV2b2tlIGFsbCBhY2Nlc3MgdG9rZW5zIGFscmVh ZHkgZ3JhbnRlZCBiYXNlZCBvbgogICB0aGUgY29tcHJvbWlzZWQgYXV0aG9yaXphdGlvbiBjb2Rl LgoKICAgSWYgdGhlIGNsaWVudCBjYW4gYmUgYXV0aGVudGljYXRlZCwgdGhlIGF1dGhvcml6YXRp b24gc2VydmVycyBNVVNUCiAgIGF1dGhlbnRpY2F0ZSB0aGUgY2xpZW50IGFuZCBlbnN1cmUgdGhh dCB0aGUgYXV0aG9yaXphdGlvbiBjb2RlIHdhcwogICBpc3N1ZWQgdG8gdGhlIHNhbWUgY2xpZW50 LgoKMTAuNi4gIEF1dGhvcml6YXRpb24gQ29kZSBSZWRpcmVjdGlvbiBVUkkgTWFuaXB1bGF0aW9u CgogICBXaGVuIHJlcXVlc3RpbmcgYXV0aG9yaXphdGlvbiB1c2luZyB0aGUgYXV0aG9yaXphdGlv biBjb2RlIGdyYW50CiAgIHR5cGUsIHRoZSBjbGllbnQgY2FuIHNwZWNpZnkgYSByZWRpcmVjdGlv biBVUkkgdmlhIHRoZSAicmVkaXJlY3RfdXJpIgogICBwYXJhbWV0ZXIuICBJZiBhbiBhdHRhY2tl ciBjYW4gbWFuaXB1bGF0ZSB0aGUgdmFsdWUgb2YgdGhlCiAgIHJlZGlyZWN0aW9uIFVSSSwgaXQg Y2FuIGNhdXNlIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciB0byByZWRpcmVjdAogICB0aGUgcmVz b3VyY2Ugb3duZXIgdXNlci1hZ2VudCB0byBhIFVSSSB1bmRlciB0aGUgY29udHJvbCBvZiB0aGUK ICAgYXR0YWNrZXIgd2l0aCB0aGUgYXV0aG9yaXphdGlvbiBjb2RlLgoKICAgQW4gYXR0YWNrZXIg Y2FuIGNyZWF0ZSBhbiBhY2NvdW50IGF0IGEgbGVnaXRpbWF0ZSBjbGllbnQgYW5kIGluaXRpYXRl CiAgIHRoZSBhdXRob3JpemF0aW9uIGZsb3cuICBXaGVuIHRoZSBhdHRhY2tlcidzIHVzZXItYWdl bnQgaXMgc2VudCB0bwogICB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgdG8gZ3JhbnQgYWNjZXNz LCB0aGUgYXR0YWNrZXIgZ3JhYnMgdGhlCiAgIGF1dGhvcml6YXRpb24gVVJJIHByb3ZpZGVkIGJ5 IHRoZSBsZWdpdGltYXRlIGNsaWVudCwgYW5kIHJlcGxhY2VzIHRoZQogICBjbGllbnQncyByZWRp cmVjdGlvbiBVUkkgd2l0aCBhIFVSSSB1bmRlciB0aGUgY29udHJvbCBvZiB0aGUKICAgYXR0YWNr ZXIuICBUaGUgYXR0YWNrZXIgdGhlbiB0cmlja3MgdGhlIHZpY3RpbSBpbnRvIGZvbGxvd2luZyB0 aGUKICAgbWFuaXB1bGF0ZWQgbGluayB0byBhdXRob3JpemUgYWNjZXNzIHRvIHRoZSBsZWdpdGlt YXRlIGNsaWVudC4KCiAgIE9uY2UgYXQgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLCB0aGUgdmlj dGltIGlzIHByb21wdGVkIHdpdGggYQogICBub3JtYWwsIHZhbGlkIHJlcXVlc3Qgb24gYmVoYWxm IG9mIGEgbGVnaXRpbWF0ZSBhbmQgdHJ1c3RlZCBjbGllbnQsCiAgIGFuZCBhdXRob3JpemVzIHRo ZSByZXF1ZXN0LiAgVGhlIHZpY3RpbSBpcyB0aGVuIHJlZGlyZWN0ZWQgdG8gYW4KICAgZW5kcG9p bnQgdW5kZXIgdGhlIGNvbnRyb2wgb2YgdGhlIGF0dGFja2VyIHdpdGggdGhlIGF1dGhvcml6YXRp b24KICAgY29kZS4gIFRoZSBhdHRhY2tlciBjb21wbGV0ZXMgdGhlIGF1dGhvcml6YXRpb24gZmxv dyBieSBzZW5kaW5nIHRoZQogICBhdXRob3JpemF0aW9uIGNvZGUgdG8gdGhlIGNsaWVudCB1c2lu ZyB0aGUgb3JpZ2luYWwgcmVkaXJlY3Rpb24gVVJJCiAgIHByb3ZpZGVkIGJ5IHRoZSBjbGllbnQu ICBUaGUgY2xpZW50IGV4Y2hhbmdlcyB0aGUgYXV0aG9yaXphdGlvbiBjb2RlCiAgIHdpdGggYW4g YWNjZXNzIHRva2VuIGFuZCBsaW5rcyBpdCB0byB0aGUgYXR0YWNrZXIncyBjbGllbnQgYWNjb3Vu dAogICB3aGljaCBjYW4gbm93IGdhaW4gYWNjZXNzIHRvIHRoZSBwcm90ZWN0ZWQgcmVzb3VyY2Vz IGF1dGhvcml6ZWQgYnkKICAgdGhlIHZpY3RpbSAodmlhIHRoZSBjbGllbnQpLgoKICAgSW4gb3Jk ZXIgdG8gcHJldmVudCBzdWNoIGFuIGF0dGFjaywgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIE1V U1QKICAgZW5zdXJlIHRoYXQgdGhlIHJlZGlyZWN0aW9uIFVSSSB1c2VkIHRvIG9idGFpbiB0aGUg YXV0aG9yaXphdGlvbiBjb2RlCiAgIGlzIGlkZW50aWNhbCB0byB0aGUgcmVkaXJlY3Rpb24gVVJJ IHByb3ZpZGVkIHdoZW4gZXhjaGFuZ2luZyB0aGUKICAgYXV0aG9yaXphdGlvbiBjb2RlIGZvciBh biBhY2Nlc3MgdG9rZW4uICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIKICAgTVVTVCByZXF1aXJl IHB1YmxpYyBjbGllbnRzIGFuZCBTSE9VTEQgcmVxdWlyZSBjb25maWRlbnRpYWwgY2xpZW50cwog ICB0byByZWdpc3RlciB0aGVpciByZWRpcmVjdGlvbiBVUklzLiAgSWYgYSByZWRpcmVjdGlvbiBV UkkgaXMgcHJvdmlkZWQKICAgaW4gdGhlIHJlcXVlc3QsIHRoZSBhdXRob3JpemF0aW9uIHNlcnZl ciBNVVNUIHZhbGlkYXRlIGl0IGFnYWluc3QgdGhlCiAgIHJlZ2lzdGVyZWQgdmFsdWUuCgoKCgoK CkhhbW1lciwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgRGVjZW1iZXIgNCwgMjAxMiAgICAgICAg ICAgICAgIFtQYWdlIDUzXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgT0F1dGgg Mi4wICAgICAgICAgICAgICAgICAgICAgIEp1bmUgMjAxMgoKCjEwLjcuICBSZXNvdXJjZSBPd25l ciBQYXNzd29yZCBDcmVkZW50aWFscwoKICAgVGhlIHJlc291cmNlIG93bmVyIHBhc3N3b3JkIGNy ZWRlbnRpYWxzIGdyYW50IHR5cGUgaXMgb2Z0ZW4gdXNlZCBmb3IKICAgbGVnYWN5IG9yIG1pZ3Jh dGlvbiByZWFzb25zLiAgSXQgcmVkdWNlcyB0aGUgb3ZlcmFsbCByaXNrIG9mIHN0b3JpbmcKICAg dXNlcm5hbWUgYW5kIHBhc3N3b3JkIGJ5IHRoZSBjbGllbnQsIGJ1dCBkb2VzIG5vdCBlbGltaW5h dGUgdGhlIG5lZWQKICAgdG8gZXhwb3NlIGhpZ2hseSBwcml2aWxlZ2VkIGNyZWRlbnRpYWxzIHRv IHRoZSBjbGllbnQuCgogICBUaGlzIGdyYW50IHR5cGUgY2FycmllcyBhIGhpZ2hlciByaXNrIHRo YW4gb3RoZXIgZ3JhbnQgdHlwZXMgYmVjYXVzZQogICBpdCBtYWludGFpbnMgdGhlIHBhc3N3b3Jk IGFudGktcGF0dGVybiB0aGlzIHByb3RvY29sIHNlZWtzIHRvIGF2b2lkLgogICBUaGUgY2xpZW50 IGNvdWxkIGFidXNlIHRoZSBwYXNzd29yZCBvciB0aGUgcGFzc3dvcmQgY291bGQKICAgdW5pbnRl bnRpb25hbGx5IGJlIGRpc2Nsb3NlZCB0byBhbiBhdHRhY2tlciAoZS5nLiB2aWEgbG9nIGZpbGVz IG9yCiAgIG90aGVyIHJlY29yZHMga2VwdCBieSB0aGUgY2xpZW50KS4KCiAgIEFkZGl0aW9uYWxs eSwgYmVjYXVzZSB0aGUgcmVzb3VyY2Ugb3duZXIgZG9lcyBub3QgaGF2ZSBjb250cm9sIG92ZXIK ICAgdGhlIGF1dGhvcml6YXRpb24gcHJvY2VzcyAodGhlIHJlc291cmNlIG93bmVyIGludm9sdmVt ZW50IGVuZHMgd2hlbgogICBpdCBoYW5kcyBvdmVyIGl0cyBjcmVkZW50aWFscyB0byB0aGUgY2xp ZW50KSwgdGhlIGNsaWVudCBjYW4gb2J0YWluCiAgIGFjY2VzcyB0b2tlbnMgd2l0aCBhIGJyb2Fk ZXIgc2NvcGUgdGhhbiBkZXNpcmVkIGJ5IHRoZSByZXNvdXJjZQogICBvd25lci4gIFRoZSBhdXRo b3JpemF0aW9uIHNlcnZlciBzaG91bGQgY29uc2lkZXIgdGhlIHNjb3BlIGFuZAogICBsaWZldGlt ZSBvZiBhY2Nlc3MgdG9rZW5zIGlzc3VlZCB2aWEgdGhpcyBncmFudCB0eXBlLgoKICAgVGhlIGF1 dGhvcml6YXRpb24gc2VydmVyIGFuZCBjbGllbnQgU0hPVUxEIG1pbmltaXplIHVzZSBvZiB0aGlz IGdyYW50CiAgIHR5cGUgYW5kIHV0aWxpemUgb3RoZXIgZ3JhbnQgdHlwZXMgd2hlbmV2ZXIgcG9z c2libGUuCgoxMC44LiAgUmVxdWVzdCBDb25maWRlbnRpYWxpdHkKCiAgIEFjY2VzcyB0b2tlbnMs IHJlZnJlc2ggdG9rZW5zLCByZXNvdXJjZSBvd25lciBwYXNzd29yZHMsIGFuZCBjbGllbnQKICAg Y3JlZGVudGlhbHMgTVVTVCBOT1QgYmUgdHJhbnNtaXR0ZWQgaW4gdGhlIGNsZWFyLiAgQXV0aG9y aXphdGlvbgogICBjb2RlcyBTSE9VTEQgTk9UIGJlIHRyYW5zbWl0dGVkIGluIHRoZSBjbGVhci4K CiAgIFRoZSAic3RhdGUiIGFuZCAic2NvcGUiIHBhcmFtZXRlcnMgU0hPVUxEIE5PVCBpbmNsdWRl IHNlbnNpdGl2ZQogICBjbGllbnQgb3IgcmVzb3VyY2Ugb3duZXIgaW5mb3JtYXRpb24gaW4gcGxh aW4gdGV4dCBhcyB0aGV5IGNhbiBiZQogICB0cmFuc21pdHRlZCBvdmVyIGluc2VjdXJlIGNoYW5u ZWxzIG9yIHN0b3JlZCBpbnNlY3VyZWx5LgoKMTAuOS4gIEVuZHBvaW50cyBBdXRoZW50aWNpdHkK CiAgIEluIG9yZGVyIHRvIHByZXZlbnQgbWFuLWluLXRoZS1taWRkbGUgYXR0YWNrcywgdGhlIGF1 dGhvcml6YXRpb24KICAgc2VydmVyIE1VU1QgcmVxdWlyZSB0aGUgdXNlIG9mIFRMUyB3aXRoIHNl cnZlciBhdXRoZW50aWNhdGlvbiBhcwogICBkZWZpbmVkIGJ5IFtSRkMyODE4XSBmb3IgYW55IHJl cXVlc3Qgc2VudCB0byB0aGUgYXV0aG9yaXphdGlvbiBhbmQKICAgdG9rZW4gZW5kcG9pbnRzLiAg VGhlIGNsaWVudCBNVVNUIHZhbGlkYXRlIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlcidzCiAgIFRM UyBjZXJ0aWZpY2F0ZSBhcyBkZWZpbmVkIGJ5IFtSRkM2MTI1XSwgYW5kIGluIGFjY29yZGFuY2Ug d2l0aCBpdHMKICAgcmVxdWlyZW1lbnRzIGZvciBzZXJ2ZXIgaWRlbnRpdHkgYXV0aGVudGljYXRp b24uCgoxMC4xMC4gIENyZWRlbnRpYWxzIEd1ZXNzaW5nIEF0dGFja3MKCiAgIFRoZSBhdXRob3Jp emF0aW9uIHNlcnZlciBNVVNUIHByZXZlbnQgYXR0YWNrZXJzIGZyb20gZ3Vlc3NpbmcgYWNjZXNz CiAgIHRva2VucywgYXV0aG9yaXphdGlvbiBjb2RlcywgcmVmcmVzaCB0b2tlbnMsIHJlc291cmNl IG93bmVyCiAgIHBhc3N3b3JkcywgYW5kIGNsaWVudCBjcmVkZW50aWFscy4KCgoKCkhhbW1lciwg ZXQgYWwuICAgICAgICAgIEV4cGlyZXMgRGVjZW1iZXIgNCwgMjAxMiAgICAgICAgICAgICAgIFtQ YWdlIDU0XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgT0F1dGggMi4wICAgICAg ICAgICAgICAgICAgICAgIEp1bmUgMjAxMgoKCiAgIFRoZSBwcm9iYWJpbGl0eSBvZiBhbiBhdHRh Y2tlciBndWVzc2luZyBnZW5lcmF0ZWQgdG9rZW5zIChhbmQgb3RoZXIKICAgY3JlZGVudGlhbHMg bm90IGludGVuZGVkIGZvciBoYW5kbGluZyBieSBlbmQtdXNlcnMpIE1VU1QgYmUgbGVzcyB0aGFu CiAgIG9yIGVxdWFsIHRvIDJeKC0xMjgpIGFuZCBTSE9VTEQgYmUgbGVzcyB0aGFuIG9yIGVxdWFs IHRvIDJeKC0xNjApLgoKICAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIE1VU1QgdXRpbGl6ZSBv dGhlciBtZWFucyB0byBwcm90ZWN0CiAgIGNyZWRlbnRpYWxzIGludGVuZGVkIGZvciBlbmQtdXNl ciB1c2FnZS4KCjEwLjExLiAgUGhpc2hpbmcgQXR0YWNrcwoKICAgV2lkZSBkZXBsb3ltZW50IG9m IHRoaXMgYW5kIHNpbWlsYXIgcHJvdG9jb2xzIG1heSBjYXVzZSBlbmQtdXNlcnMgdG8KICAgYmVj b21lIGludXJlZCB0byB0aGUgcHJhY3RpY2Ugb2YgYmVpbmcgcmVkaXJlY3RlZCB0byB3ZWJzaXRl cyB3aGVyZQogICB0aGV5IGFyZSBhc2tlZCB0byBlbnRlciB0aGVpciBwYXNzd29yZHMuICBJZiBl bmQtdXNlcnMgYXJlIG5vdAogICBjYXJlZnVsIHRvIHZlcmlmeSB0aGUgYXV0aGVudGljaXR5IG9m IHRoZXNlIHdlYnNpdGVzIGJlZm9yZSBlbnRlcmluZwogICB0aGVpciBjcmVkZW50aWFscywgaXQg d2lsbCBiZSBwb3NzaWJsZSBmb3IgYXR0YWNrZXJzIHRvIGV4cGxvaXQgdGhpcwogICBwcmFjdGlj ZSB0byBzdGVhbCByZXNvdXJjZSBvd25lcnMnIHBhc3N3b3Jkcy4KCiAgIFNlcnZpY2UgcHJvdmlk ZXJzIHNob3VsZCBhdHRlbXB0IHRvIGVkdWNhdGUgZW5kLXVzZXJzIGFib3V0IHRoZSByaXNrcwog ICBwaGlzaGluZyBhdHRhY2tzIHBvc2UsIGFuZCBzaG91bGQgcHJvdmlkZSBtZWNoYW5pc21zIHRo YXQgbWFrZSBpdAogICBlYXN5IGZvciBlbmQtdXNlcnMgdG8gY29uZmlybSB0aGUgYXV0aGVudGlj aXR5IG9mIHRoZWlyIHNpdGVzLgogICBDbGllbnQgZGV2ZWxvcGVycyBzaG91bGQgY29uc2lkZXIg dGhlIHNlY3VyaXR5IGltcGxpY2F0aW9ucyBvZiBob3cKICAgdGhleSBpbnRlcmFjdCB3aXRoIHRo ZSB1c2VyLWFnZW50IChlLmcuLCBleHRlcm5hbCwgZW1iZWRkZWQpLCBhbmQgdGhlCiAgIGFiaWxp dHkgb2YgdGhlIGVuZC11c2VyIHRvIHZlcmlmeSB0aGUgYXV0aGVudGljaXR5IG9mIHRoZQogICBh dXRob3JpemF0aW9uIHNlcnZlci4KCiAgIFRvIHJlZHVjZSB0aGUgcmlzayBvZiBwaGlzaGluZyBh dHRhY2tzLCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXJzCiAgIE1VU1QgcmVxdWlyZSB0aGUgdXNl IG9mIFRMUyBvbiBldmVyeSBlbmRwb2ludCB1c2VkIGZvciBlbmQtdXNlcgogICBpbnRlcmFjdGlv bi4KCjEwLjEyLiAgQ3Jvc3MtU2l0ZSBSZXF1ZXN0IEZvcmdlcnkKCiAgIENyb3NzLXNpdGUgcmVx dWVzdCBmb3JnZXJ5IChDU1JGKSBpcyBhbiBleHBsb2l0IGluIHdoaWNoIGFuIGF0dGFja2VyCiAg IGNhdXNlcyB0aGUgdXNlci1hZ2VudCBvZiBhIHZpY3RpbSBlbmQtdXNlciB0byBmb2xsb3cgYSBt YWxpY2lvdXMgVVJJCiAgIChlLmcuIHByb3ZpZGVkIHRvIHRoZSB1c2VyLWFnZW50IGFzIGEgbWlz bGVhZGluZyBsaW5rLCBpbWFnZSwgb3IKICAgcmVkaXJlY3Rpb24pIHRvIGEgdHJ1c3Rpbmcgc2Vy dmVyICh1c3VhbGx5IGVzdGFibGlzaGVkIHZpYSB0aGUKICAgcHJlc2VuY2Ugb2YgYSB2YWxpZCBz ZXNzaW9uIGNvb2tpZSkuCgogICBBIENTUkYgYXR0YWNrIGFnYWluc3QgdGhlIGNsaWVudCdzIHJl ZGlyZWN0aW9uIFVSSSBhbGxvd3MgYW4gYXR0YWNrZXIKICAgdG8gaW5qZWN0IHRoZWlyIG93biBh dXRob3JpemF0aW9uIGNvZGUgb3IgYWNjZXNzIHRva2VuLCB3aGljaCBjYW4KICAgcmVzdWx0IGlu IHRoZSBjbGllbnQgdXNpbmcgYW4gYWNjZXNzIHRva2VuIGFzc29jaWF0ZWQgd2l0aCB0aGUKICAg YXR0YWNrZXIncyBwcm90ZWN0ZWQgcmVzb3VyY2VzIHJhdGhlciB0aGFuIHRoZSB2aWN0aW0ncyAo ZS5nLiBzYXZlCiAgIHRoZSB2aWN0aW0ncyBiYW5rIGFjY291bnQgaW5mb3JtYXRpb24gdG8gYSBw cm90ZWN0ZWQgcmVzb3VyY2UKICAgY29udHJvbGxlZCBieSB0aGUgYXR0YWNrZXIpLgoKICAgVGhl IGNsaWVudCBNVVNUIGltcGxlbWVudCBDU1JGIHByb3RlY3Rpb24gZm9yIGl0cyByZWRpcmVjdGlv biBVUkkuCiAgIFRoaXMgaXMgdHlwaWNhbGx5IGFjY29tcGxpc2hlZCBieSByZXF1aXJpbmcgYW55 IHJlcXVlc3Qgc2VudCB0byB0aGUKICAgcmVkaXJlY3Rpb24gVVJJIGVuZHBvaW50IHRvIGluY2x1 ZGUgYSB2YWx1ZSB0aGF0IGJpbmRzIHRoZSByZXF1ZXN0IHRvCiAgIHRoZSB1c2VyLWFnZW50J3Mg YXV0aGVudGljYXRlZCBzdGF0ZSAoZS5nLiBhIGhhc2ggb2YgdGhlIHNlc3Npb24KICAgY29va2ll IHVzZWQgdG8gYXV0aGVudGljYXRlIHRoZSB1c2VyLWFnZW50KS4gIFRoZSBjbGllbnQgU0hPVUxE CgoKCkhhbW1lciwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgRGVjZW1iZXIgNCwgMjAxMiAgICAg ICAgICAgICAgIFtQYWdlIDU1XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgT0F1 dGggMi4wICAgICAgICAgICAgICAgICAgICAgIEp1bmUgMjAxMgoKCiAgIHV0aWxpemUgdGhlICJz dGF0ZSIgcmVxdWVzdCBwYXJhbWV0ZXIgdG8gZGVsaXZlciB0aGlzIHZhbHVlIHRvIHRoZQogICBh dXRob3JpemF0aW9uIHNlcnZlciB3aGVuIG1ha2luZyBhbiBhdXRob3JpemF0aW9uIHJlcXVlc3Qu CgogICBPbmNlIGF1dGhvcml6YXRpb24gaGFzIGJlZW4gb2J0YWluZWQgZnJvbSB0aGUgZW5kLXVz ZXIsIHRoZQogICBhdXRob3JpemF0aW9uIHNlcnZlciByZWRpcmVjdHMgdGhlIGVuZC11c2VyJ3Mg dXNlci1hZ2VudCBiYWNrIHRvIHRoZQogICBjbGllbnQgd2l0aCB0aGUgcmVxdWlyZWQgYmluZGlu ZyB2YWx1ZSBjb250YWluZWQgaW4gdGhlICJzdGF0ZSIKICAgcGFyYW1ldGVyLiAgVGhlIGJpbmRp bmcgdmFsdWUgZW5hYmxlcyB0aGUgY2xpZW50IHRvIHZlcmlmeSB0aGUKICAgdmFsaWRpdHkgb2Yg dGhlIHJlcXVlc3QgYnkgbWF0Y2hpbmcgdGhlIGJpbmRpbmcgdmFsdWUgdG8gdGhlIHVzZXItCiAg IGFnZW50J3MgYXV0aGVudGljYXRlZCBzdGF0ZS4gIFRoZSBiaW5kaW5nIHZhbHVlIHVzZWQgZm9y IENTUkYKICAgcHJvdGVjdGlvbiBNVVNUIGNvbnRhaW4gYSBub24tZ3Vlc3NhYmxlIHZhbHVlIChh cyBkZXNjcmliZWQgaW4KICAgU2VjdGlvbiAxMC4xMCksIGFuZCB0aGUgdXNlci1hZ2VudCdzIGF1 dGhlbnRpY2F0ZWQgc3RhdGUgKGUuZy4KICAgc2Vzc2lvbiBjb29raWUsIEhUTUw1IGxvY2FsIHN0 b3JhZ2UpIE1VU1QgYmUga2VwdCBpbiBhIGxvY2F0aW9uCiAgIGFjY2Vzc2libGUgb25seSB0byB0 aGUgY2xpZW50IGFuZCB0aGUgdXNlci1hZ2VudCAoaS5lLiwgcHJvdGVjdGVkIGJ5CiAgIHNhbWUt b3JpZ2luIHBvbGljeSkuCgogICBBIENTUkYgYXR0YWNrIGFnYWluc3QgdGhlIGF1dGhvcml6YXRp b24gc2VydmVyJ3MgYXV0aG9yaXphdGlvbgogICBlbmRwb2ludCBjYW4gcmVzdWx0IGluIGFuIGF0 dGFja2VyIG9idGFpbmluZyBlbmQtdXNlciBhdXRob3JpemF0aW9uCiAgIGZvciBhIG1hbGljaW91 cyBjbGllbnQgd2l0aG91dCBpbnZvbHZpbmcgb3IgYWxlcnRpbmcgdGhlIGVuZC11c2VyLgoKICAg VGhlIGF1dGhvcml6YXRpb24gc2VydmVyIE1VU1QgaW1wbGVtZW50IENTUkYgcHJvdGVjdGlvbiBm b3IgaXRzCiAgIGF1dGhvcml6YXRpb24gZW5kcG9pbnQsIGFuZCBlbnN1cmUgdGhhdCBhIG1hbGlj aW91cyBjbGllbnQgY2Fubm90CiAgIG9idGFpbiBhdXRob3JpemF0aW9uIHdpdGhvdXQgdGhlIGF3 YXJlbmVzcyBhbmQgZXhwbGljaXQgY29uc2VudCBvZgogICB0aGUgcmVzb3VyY2Ugb3duZXIuCgox MC4xMy4gIENsaWNramFja2luZwoKICAgSW4gYSBjbGlja2phY2tpbmcgYXR0YWNrLCBhbiBhdHRh Y2tlciByZWdpc3RlcnMgYSBsZWdpdGltYXRlIGNsaWVudAogICBhbmQgdGhlbiBjb25zdHJ1Y3Rz IGEgbWFsaWNpb3VzIHNpdGUgaW4gd2hpY2ggaXQgbG9hZHMgdGhlCiAgIGF1dGhvcml6YXRpb24g c2VydmVyJ3MgYXV0aG9yaXphdGlvbiBlbmRwb2ludCB3ZWIgcGFnZSBpbiBhCiAgIHRyYW5zcGFy ZW50IGlmcmFtZSBvdmVybGFpZCBvbiB0b3Agb2YgYSBzZXQgb2YgZHVtbXkgYnV0dG9ucyB3aGlj aAogICBhcmUgY2FyZWZ1bGx5IGNvbnN0cnVjdGVkIHRvIGJlIHBsYWNlZCBkaXJlY3RseSB1bmRl ciBpbXBvcnRhbnQKICAgYnV0dG9ucyBvbiB0aGUgYXV0aG9yaXphdGlvbiBwYWdlLiAgV2hlbiBh biBlbmQtdXNlciBjbGlja3MgYQogICBtaXNsZWFkaW5nIHZpc2libGUgYnV0dG9uLCB0aGUgZW5k LXVzZXIgaXMgYWN0dWFsbHkgY2xpY2tpbmcgYW4KICAgaW52aXNpYmxlIGJ1dHRvbiBvbiB0aGUg YXV0aG9yaXphdGlvbiBwYWdlIChzdWNoIGFzIGFuICJBdXRob3JpemUiCiAgIGJ1dHRvbikuICBU aGlzIGFsbG93cyBhbiBhdHRhY2tlciB0byB0cmljayBhIHJlc291cmNlIG93bmVyIGludG8KICAg Z3JhbnRpbmcgaXRzIGNsaWVudCBhY2Nlc3Mgd2l0aG91dCB0aGVpciBrbm93bGVkZ2UuCgogICBU byBwcmV2ZW50IHRoaXMgZm9ybSBvZiBhdHRhY2ssIG5hdGl2ZSBhcHBsaWNhdGlvbnMgU0hPVUxE IHVzZQogICBleHRlcm5hbCBicm93c2VycyBpbnN0ZWFkIG9mIGVtYmVkZGluZyBicm93c2VycyB3 aXRoaW4gdGhlCiAgIGFwcGxpY2F0aW9uIHdoZW4gcmVxdWVzdGluZyBlbmQtdXNlciBhdXRob3Jp emF0aW9uLiAgRm9yIG1vc3QgbmV3ZXIKICAgYnJvd3NlcnMsIGF2b2lkYW5jZSBvZiBpZnJhbWVz IGNhbiBiZSBlbmZvcmNlZCBieSB0aGUgYXV0aG9yaXphdGlvbgogICBzZXJ2ZXIgdXNpbmcgdGhl IChub24tc3RhbmRhcmQpICJ4LWZyYW1lLW9wdGlvbnMiIGhlYWRlci4gIFRoaXMKICAgaGVhZGVy IGNhbiBoYXZlIHR3byB2YWx1ZXMsICJkZW55IiBhbmQgInNhbWVvcmlnaW4iLCB3aGljaCB3aWxs IGJsb2NrCiAgIGFueSBmcmFtaW5nLCBvciBmcmFtaW5nIGJ5IHNpdGVzIHdpdGggYSBkaWZmZXJl bnQgb3JpZ2luLAogICByZXNwZWN0aXZlbHkuICBGb3Igb2xkZXIgYnJvd3NlcnMsIEphdmFTY3Jp cHQgZnJhbWVidXN0aW5nIHRlY2huaXF1ZXMKICAgY2FuIGJlIHVzZWQgYnV0IG1heSBub3QgYmUg ZWZmZWN0aXZlIGluIGFsbCBicm93c2Vycy4KCgoKCgpIYW1tZXIsIGV0IGFsLiAgICAgICAgICBF eHBpcmVzIERlY2VtYmVyIDQsIDIwMTIgICAgICAgICAgICAgICBbUGFnZSA1Nl0KDApJbnRlcm5l dC1EcmFmdCAgICAgICAgICAgICAgICAgIE9BdXRoIDIuMCAgICAgICAgICAgICAgICAgICAgICBK dW5lIDIwMTIKCgoxMC4xNC4gIENvZGUgSW5qZWN0aW9uIGFuZCBJbnB1dCBWYWxpZGF0aW9uCgog ICBBIGNvZGUgaW5qZWN0aW9uIGF0dGFjayBvY2N1cnMgd2hlbiBhbiBpbnB1dCBvciBvdGhlcndp c2UgZXh0ZXJuYWwKICAgdmFyaWFibGUgaXMgdXNlZCBieSBhbiBhcHBsaWNhdGlvbiB1bnNhbml0 aXplZCBhbmQgY2F1c2VzCiAgIG1vZGlmaWNhdGlvbiB0byB0aGUgYXBwbGljYXRpb24gbG9naWMu ICBUaGlzIG1heSBhbGxvdyBhbiBhdHRhY2tlciB0bwogICBnYWluIGFjY2VzcyB0byB0aGUgYXBw bGljYXRpb24gZGV2aWNlIG9yIGl0cyBkYXRhLCBjYXVzZSBkZW5pYWwgb2YKICAgc2VydmljZSwg b3IgYSB3aWRlIHJhbmdlIG9mIG1hbGljaW91cyBzaWRlLWVmZmVjdHMuCgogICBUaGUgQXV0aG9y aXphdGlvbiBzZXJ2ZXIgYW5kIGNsaWVudCBNVVNUIHNhbml0aXplIChhbmQgdmFsaWRhdGUgd2hl bgogICBwb3NzaWJsZSkgYW55IHZhbHVlIHJlY2VpdmVkLCBpbiBwYXJ0aWN1bGFyLCB0aGUgdmFs dWUgb2YgdGhlICJzdGF0ZSIKICAgYW5kICJyZWRpcmVjdF91cmkiIHBhcmFtZXRlcnMuCgoxMC4x NS4gIE9wZW4gUmVkaXJlY3RvcnMKCiAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBhdXRob3Jp emF0aW9uIGVuZHBvaW50IGFuZCB0aGUgY2xpZW50CiAgIHJlZGlyZWN0aW9uIGVuZHBvaW50IGNh biBiZSBpbXByb3Blcmx5IGNvbmZpZ3VyZWQgYW5kIG9wZXJhdGUgYXMgb3BlbgogICByZWRpcmVj dG9ycy4gIEFuIG9wZW4gcmVkaXJlY3RvciBpcyBhbiBlbmRwb2ludCB1c2luZyBhIHBhcmFtZXRl ciB0bwogICBhdXRvbWF0aWNhbGx5IHJlZGlyZWN0IGEgdXNlci1hZ2VudCB0byB0aGUgbG9jYXRp b24gc3BlY2lmaWVkIGJ5IHRoZQogICBwYXJhbWV0ZXIgdmFsdWUgd2l0aG91dCBhbnkgdmFsaWRh dGlvbi4KCiAgIE9wZW4gcmVkaXJlY3RvcnMgY2FuIGJlIHVzZWQgaW4gcGhpc2hpbmcgYXR0YWNr cywgb3IgYnkgYW4gYXR0YWNrZXIKICAgdG8gZ2V0IGVuZC11c2VycyB0byB2aXNpdCBtYWxpY2lv dXMgc2l0ZXMgYnkgbWFraW5nIHRoZSBVUkkncwogICBhdXRob3JpdHkgbG9vayBsaWtlIGEgZmFt aWxpYXIgYW5kIHRydXN0ZWQgZGVzdGluYXRpb24uICBJbiBhZGRpdGlvbiwKICAgaWYgdGhlIGF1 dGhvcml6YXRpb24gc2VydmVyIGFsbG93cyB0aGUgY2xpZW50IHRvIHJlZ2lzdGVyIG9ubHkgcGFy dAogICBvZiB0aGUgcmVkaXJlY3Rpb24gVVJJLCBhbiBhdHRhY2tlciBjYW4gdXNlIGFuIG9wZW4g cmVkaXJlY3RvcgogICBvcGVyYXRlZCBieSB0aGUgY2xpZW50IHRvIGNvbnN0cnVjdCBhIHJlZGly ZWN0aW9uIFVSSSB0aGF0IHdpbGwgcGFzcwogICB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgdmFs aWRhdGlvbiBidXQgd2lsbCBzZW5kIHRoZSBhdXRob3JpemF0aW9uCiAgIGNvZGUgb3IgYWNjZXNz IHRva2VuIHRvIGFuIGVuZHBvaW50IHVuZGVyIHRoZSBjb250cm9sIG9mIHRoZQogICBhdHRhY2tl ci4KCgoxMS4gIElBTkEgQ29uc2lkZXJhdGlvbnMKCjExLjEuICBUaGUgT0F1dGggQWNjZXNzIFRv a2VuIFR5cGUgUmVnaXN0cnkKCiAgIFRoaXMgc3BlY2lmaWNhdGlvbiBlc3RhYmxpc2hlcyB0aGUg T0F1dGggYWNjZXNzIHRva2VuIHR5cGUgcmVnaXN0cnkuCgogICBBY2Nlc3MgdG9rZW4gdHlwZXMg YXJlIHJlZ2lzdGVyZWQgd2l0aCBhIFNwZWNpZmljYXRpb24gUmVxdWlyZWQKICAgKFtSRkM1MjI2 XSkgYWZ0ZXIgYSB0d28gd2VlayByZXZpZXcgcGVyaW9kIG9uIHRoZSBbVEJEXUBpZXRmLm9yZwog ICBtYWlsaW5nIGxpc3QsIG9uIHRoZSBhZHZpY2Ugb2Ygb25lIG9yIG1vcmUgRGVzaWduYXRlZCBF eHBlcnRzLgogICBIb3dldmVyLCB0byBhbGxvdyBmb3IgdGhlIGFsbG9jYXRpb24gb2YgdmFsdWVz IHByaW9yIHRvIHB1YmxpY2F0aW9uLAogICB0aGUgRGVzaWduYXRlZCBFeHBlcnQocykgbWF5IGFw cHJvdmUgcmVnaXN0cmF0aW9uIG9uY2UgdGhleSBhcmUKICAgc2F0aXNmaWVkIHRoYXQgc3VjaCBh IHNwZWNpZmljYXRpb24gd2lsbCBiZSBwdWJsaXNoZWQuCgogICBSZWdpc3RyYXRpb24gcmVxdWVz dHMgbXVzdCBiZSBzZW50IHRvIHRoZSBbVEJEXUBpZXRmLm9yZyBtYWlsaW5nIGxpc3QKICAgZm9y IHJldmlldyBhbmQgY29tbWVudCwgd2l0aCBhbiBhcHByb3ByaWF0ZSBzdWJqZWN0IChlLmcuLCAi UmVxdWVzdAogICBmb3IgYWNjZXNzIHRva2VuIHR5cGU6IGV4YW1wbGUiKS4gW1sgTm90ZSB0byBS RkMtRURJVE9SOiBUaGUgbmFtZSBvZgogICB0aGUgbWFpbGluZyBsaXN0IHNob3VsZCBiZSBkZXRl cm1pbmVkIGluIGNvbnN1bHRhdGlvbiB3aXRoIHRoZSBJRVNHCgoKCkhhbW1lciwgZXQgYWwuICAg ICAgICAgIEV4cGlyZXMgRGVjZW1iZXIgNCwgMjAxMiAgICAgICAgICAgICAgIFtQYWdlIDU3XQoM CkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgT0F1dGggMi4wICAgICAgICAgICAgICAg ICAgICAgIEp1bmUgMjAxMgoKCiAgIGFuZCBJQU5BLiAgU3VnZ2VzdGVkIG5hbWU6IG9hdXRoLWV4 dC1yZXZpZXcuIF1dCgogICBXaXRoaW4gdGhlIHJldmlldyBwZXJpb2QsIHRoZSBEZXNpZ25hdGVk IEV4cGVydChzKSB3aWxsIGVpdGhlcgogICBhcHByb3ZlIG9yIGRlbnkgdGhlIHJlZ2lzdHJhdGlv biByZXF1ZXN0LCBjb21tdW5pY2F0aW5nIHRoaXMgZGVjaXNpb24KICAgdG8gdGhlIHJldmlldyBs aXN0IGFuZCBJQU5BLiAgRGVuaWFscyBzaG91bGQgaW5jbHVkZSBhbiBleHBsYW5hdGlvbgogICBh bmQsIGlmIGFwcGxpY2FibGUsIHN1Z2dlc3Rpb25zIGFzIHRvIGhvdyB0byBtYWtlIHRoZSByZXF1 ZXN0CiAgIHN1Y2Nlc3NmdWwuCgogICBJQU5BIG11c3Qgb25seSBhY2NlcHQgcmVnaXN0cnkgdXBk YXRlcyBmcm9tIHRoZSBEZXNpZ25hdGVkIEV4cGVydChzKSwKICAgYW5kIHNob3VsZCBkaXJlY3Qg YWxsIHJlcXVlc3RzIGZvciByZWdpc3RyYXRpb24gdG8gdGhlIHJldmlldyBtYWlsaW5nCiAgIGxp c3QuCgoxMS4xLjEuICBSZWdpc3RyYXRpb24gVGVtcGxhdGUKCiAgIFR5cGUgbmFtZToKICAgICAg VGhlIG5hbWUgcmVxdWVzdGVkIChlLmcuLCAiZXhhbXBsZSIpLgogICBBZGRpdGlvbmFsIFRva2Vu IEVuZHBvaW50IFJlc3BvbnNlIFBhcmFtZXRlcnM6CiAgICAgIEFkZGl0aW9uYWwgcmVzcG9uc2Ug cGFyYW1ldGVycyByZXR1cm5lZCB0b2dldGhlciB3aXRoIHRoZQogICAgICAiYWNjZXNzX3Rva2Vu IiBwYXJhbWV0ZXIuICBOZXcgcGFyYW1ldGVycyBNVVNUIGJlIHNlcGFyYXRlbHkKICAgICAgcmVn aXN0ZXJlZCBpbiB0aGUgT0F1dGggcGFyYW1ldGVycyByZWdpc3RyeSBhcyBkZXNjcmliZWQgYnkK ICAgICAgU2VjdGlvbiAxMS4yLgogICBIVFRQIEF1dGhlbnRpY2F0aW9uIFNjaGVtZShzKToKICAg ICAgVGhlIEhUVFAgYXV0aGVudGljYXRpb24gc2NoZW1lIG5hbWUocyksIGlmIGFueSwgdXNlZCB0 bwogICAgICBhdXRoZW50aWNhdGUgcHJvdGVjdGVkIHJlc291cmNlcyByZXF1ZXN0cyB1c2luZyBh Y2Nlc3MgdG9rZW5zIG9mCiAgICAgIHRoaXMgdHlwZS4KICAgQ2hhbmdlIGNvbnRyb2xsZXI6CiAg ICAgIEZvciBzdGFuZGFyZHMtdHJhY2sgUkZDcywgc3RhdGUgIklFVEYiLiAgRm9yIG90aGVycywg Z2l2ZSB0aGUgbmFtZQogICAgICBvZiB0aGUgcmVzcG9uc2libGUgcGFydHkuICBPdGhlciBkZXRh aWxzIChlLmcuLCBwb3N0YWwgYWRkcmVzcywKICAgICAgZS1tYWlsIGFkZHJlc3MsIGhvbWUgcGFn ZSBVUkkpIG1heSBhbHNvIGJlIGluY2x1ZGVkLgogICBTcGVjaWZpY2F0aW9uIGRvY3VtZW50KHMp OgogICAgICBSZWZlcmVuY2UgdG8gdGhlIGRvY3VtZW50IHRoYXQgc3BlY2lmaWVzIHRoZSBwYXJh bWV0ZXIsIHByZWZlcmFibHkKICAgICAgaW5jbHVkaW5nIGEgVVJJIHRoYXQgY2FuIGJlIHVzZWQg dG8gcmV0cmlldmUgYSBjb3B5IG9mIHRoZQogICAgICBkb2N1bWVudC4gIEFuIGluZGljYXRpb24g b2YgdGhlIHJlbGV2YW50IHNlY3Rpb25zIG1heSBhbHNvIGJlCiAgICAgIGluY2x1ZGVkLCBidXQg aXMgbm90IHJlcXVpcmVkLgoKMTEuMi4gIFRoZSBPQXV0aCBQYXJhbWV0ZXJzIFJlZ2lzdHJ5Cgog ICBUaGlzIHNwZWNpZmljYXRpb24gZXN0YWJsaXNoZXMgdGhlIE9BdXRoIHBhcmFtZXRlcnMgcmVn aXN0cnkuCgogICBBZGRpdGlvbmFsIHBhcmFtZXRlcnMgZm9yIGluY2x1c2lvbiBpbiB0aGUgYXV0 aG9yaXphdGlvbiBlbmRwb2ludAogICByZXF1ZXN0LCB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2lu dCByZXNwb25zZSwgdGhlIHRva2VuIGVuZHBvaW50CiAgIHJlcXVlc3QsIG9yIHRoZSB0b2tlbiBl bmRwb2ludCByZXNwb25zZSBhcmUgcmVnaXN0ZXJlZCB3aXRoIGEKICAgU3BlY2lmaWNhdGlvbiBS ZXF1aXJlZCAoW1JGQzUyMjZdKSBhZnRlciBhIHR3byB3ZWVrIHJldmlldyBwZXJpb2Qgb24KICAg dGhlIFtUQkRdQGlldGYub3JnIG1haWxpbmcgbGlzdCwgb24gdGhlIGFkdmljZSBvZiBvbmUgb3Ig bW9yZQogICBEZXNpZ25hdGVkIEV4cGVydHMuICBIb3dldmVyLCB0byBhbGxvdyBmb3IgdGhlIGFs bG9jYXRpb24gb2YgdmFsdWVzCiAgIHByaW9yIHRvIHB1YmxpY2F0aW9uLCB0aGUgRGVzaWduYXRl ZCBFeHBlcnQocykgbWF5IGFwcHJvdmUKICAgcmVnaXN0cmF0aW9uIG9uY2UgdGhleSBhcmUgc2F0 aXNmaWVkIHRoYXQgc3VjaCBhIHNwZWNpZmljYXRpb24gd2lsbAogICBiZSBwdWJsaXNoZWQuCgoK CkhhbW1lciwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgRGVjZW1iZXIgNCwgMjAxMiAgICAgICAg ICAgICAgIFtQYWdlIDU4XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgT0F1dGgg Mi4wICAgICAgICAgICAgICAgICAgICAgIEp1bmUgMjAxMgoKCiAgIFJlZ2lzdHJhdGlvbiByZXF1 ZXN0cyBtdXN0IGJlIHNlbnQgdG8gdGhlIFtUQkRdQGlldGYub3JnIG1haWxpbmcgbGlzdAogICBm b3IgcmV2aWV3IGFuZCBjb21tZW50LCB3aXRoIGFuIGFwcHJvcHJpYXRlIHN1YmplY3QgKGUuZy4s ICJSZXF1ZXN0CiAgIGZvciBwYXJhbWV0ZXI6IGV4YW1wbGUiKS4gW1sgTm90ZSB0byBSRkMtRURJ VE9SOiBUaGUgbmFtZSBvZiB0aGUKICAgbWFpbGluZyBsaXN0IHNob3VsZCBiZSBkZXRlcm1pbmVk IGluIGNvbnN1bHRhdGlvbiB3aXRoIHRoZSBJRVNHIGFuZAogICBJQU5BLiAgU3VnZ2VzdGVkIG5h bWU6IG9hdXRoLWV4dC1yZXZpZXcuIF1dCgogICBXaXRoaW4gdGhlIHJldmlldyBwZXJpb2QsIHRo ZSBEZXNpZ25hdGVkIEV4cGVydChzKSB3aWxsIGVpdGhlcgogICBhcHByb3ZlIG9yIGRlbnkgdGhl IHJlZ2lzdHJhdGlvbiByZXF1ZXN0LCBjb21tdW5pY2F0aW5nIHRoaXMgZGVjaXNpb24KICAgdG8g dGhlIHJldmlldyBsaXN0IGFuZCBJQU5BLiAgRGVuaWFscyBzaG91bGQgaW5jbHVkZSBhbiBleHBs YW5hdGlvbgogICBhbmQsIGlmIGFwcGxpY2FibGUsIHN1Z2dlc3Rpb25zIGFzIHRvIGhvdyB0byBt YWtlIHRoZSByZXF1ZXN0CiAgIHN1Y2Nlc3NmdWwuCgogICBJQU5BIG11c3Qgb25seSBhY2NlcHQg cmVnaXN0cnkgdXBkYXRlcyBmcm9tIHRoZSBEZXNpZ25hdGVkIEV4cGVydChzKSwKICAgYW5kIHNo b3VsZCBkaXJlY3QgYWxsIHJlcXVlc3RzIGZvciByZWdpc3RyYXRpb24gdG8gdGhlIHJldmlldyBt YWlsaW5nCiAgIGxpc3QuCgoxMS4yLjEuICBSZWdpc3RyYXRpb24gVGVtcGxhdGUKCiAgIFBhcmFt ZXRlciBuYW1lOgogICAgICBUaGUgbmFtZSByZXF1ZXN0ZWQgKGUuZy4sICJleGFtcGxlIikuCiAg IFBhcmFtZXRlciB1c2FnZSBsb2NhdGlvbjoKICAgICAgVGhlIGxvY2F0aW9uKHMpIHdoZXJlIHBh cmFtZXRlciBjYW4gYmUgdXNlZC4gIFRoZSBwb3NzaWJsZQogICAgICBsb2NhdGlvbnMgYXJlOiBh dXRob3JpemF0aW9uIHJlcXVlc3QsIGF1dGhvcml6YXRpb24gcmVzcG9uc2UsCiAgICAgIHRva2Vu IHJlcXVlc3QsIG9yIHRva2VuIHJlc3BvbnNlLgogICBDaGFuZ2UgY29udHJvbGxlcjoKICAgICAg Rm9yIHN0YW5kYXJkcy10cmFjayBSRkNzLCBzdGF0ZSAiSUVURiIuICBGb3Igb3RoZXJzLCBnaXZl IHRoZSBuYW1lCiAgICAgIG9mIHRoZSByZXNwb25zaWJsZSBwYXJ0eS4gIE90aGVyIGRldGFpbHMg KGUuZy4sIHBvc3RhbCBhZGRyZXNzLAogICAgICBlLW1haWwgYWRkcmVzcywgaG9tZSBwYWdlIFVS SSkgbWF5IGFsc28gYmUgaW5jbHVkZWQuCiAgIFNwZWNpZmljYXRpb24gZG9jdW1lbnQocyk6CiAg ICAgIFJlZmVyZW5jZSB0byB0aGUgZG9jdW1lbnQgdGhhdCBzcGVjaWZpZXMgdGhlIHBhcmFtZXRl ciwgcHJlZmVyYWJseQogICAgICBpbmNsdWRpbmcgYSBVUkkgdGhhdCBjYW4gYmUgdXNlZCB0byBy ZXRyaWV2ZSBhIGNvcHkgb2YgdGhlCiAgICAgIGRvY3VtZW50LiAgQW4gaW5kaWNhdGlvbiBvZiB0 aGUgcmVsZXZhbnQgc2VjdGlvbnMgbWF5IGFsc28gYmUKICAgICAgaW5jbHVkZWQsIGJ1dCBpcyBu b3QgcmVxdWlyZWQuCgoxMS4yLjIuICBJbml0aWFsIFJlZ2lzdHJ5IENvbnRlbnRzCgogICBUaGUg T0F1dGggUGFyYW1ldGVycyBSZWdpc3RyeSdzIGluaXRpYWwgY29udGVudHMgYXJlOgoKICAgbyAg UGFyYW1ldGVyIG5hbWU6IGNsaWVudF9pZAogICBvICBQYXJhbWV0ZXIgdXNhZ2UgbG9jYXRpb246 IGF1dGhvcml6YXRpb24gcmVxdWVzdCwgdG9rZW4gcmVxdWVzdAogICBvICBDaGFuZ2UgY29udHJv bGxlcjogSUVURgogICBvICBTcGVjaWZpY2F0aW9uIGRvY3VtZW50KHMpOiBbWyB0aGlzIGRvY3Vt ZW50IF1dCgogICBvICBQYXJhbWV0ZXIgbmFtZTogY2xpZW50X3NlY3JldAogICBvICBQYXJhbWV0 ZXIgdXNhZ2UgbG9jYXRpb246IHRva2VuIHJlcXVlc3QKICAgbyAgQ2hhbmdlIGNvbnRyb2xsZXI6 IElFVEYKCgoKCgpIYW1tZXIsIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIERlY2VtYmVyIDQsIDIw MTIgICAgICAgICAgICAgICBbUGFnZSA1OV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAg ICAgIE9BdXRoIDIuMCAgICAgICAgICAgICAgICAgICAgICBKdW5lIDIwMTIKCgogICBvICBTcGVj aWZpY2F0aW9uIGRvY3VtZW50KHMpOiBbWyB0aGlzIGRvY3VtZW50IF1dCgogICBvICBQYXJhbWV0 ZXIgbmFtZTogcmVzcG9uc2VfdHlwZQogICBvICBQYXJhbWV0ZXIgdXNhZ2UgbG9jYXRpb246IGF1 dGhvcml6YXRpb24gcmVxdWVzdAogICBvICBDaGFuZ2UgY29udHJvbGxlcjogSUVURgogICBvICBT cGVjaWZpY2F0aW9uIGRvY3VtZW50KHMpOiBbWyB0aGlzIGRvY3VtZW50IF1dCgogICBvICBQYXJh bWV0ZXIgbmFtZTogcmVkaXJlY3RfdXJpCiAgIG8gIFBhcmFtZXRlciB1c2FnZSBsb2NhdGlvbjog YXV0aG9yaXphdGlvbiByZXF1ZXN0LCB0b2tlbiByZXF1ZXN0CiAgIG8gIENoYW5nZSBjb250cm9s bGVyOiBJRVRGCiAgIG8gIFNwZWNpZmljYXRpb24gZG9jdW1lbnQocyk6IFtbIHRoaXMgZG9jdW1l bnQgXV0KCiAgIG8gIFBhcmFtZXRlciBuYW1lOiBzY29wZQogICBvICBQYXJhbWV0ZXIgdXNhZ2Ug bG9jYXRpb246IGF1dGhvcml6YXRpb24gcmVxdWVzdCwgYXV0aG9yaXphdGlvbgogICAgICByZXNw b25zZSwgdG9rZW4gcmVxdWVzdCwgdG9rZW4gcmVzcG9uc2UKICAgbyAgQ2hhbmdlIGNvbnRyb2xs ZXI6IElFVEYKICAgbyAgU3BlY2lmaWNhdGlvbiBkb2N1bWVudChzKTogW1sgdGhpcyBkb2N1bWVu dCBdXQoKICAgbyAgUGFyYW1ldGVyIG5hbWU6IHN0YXRlCiAgIG8gIFBhcmFtZXRlciB1c2FnZSBs b2NhdGlvbjogYXV0aG9yaXphdGlvbiByZXF1ZXN0LCBhdXRob3JpemF0aW9uCiAgICAgIHJlc3Bv bnNlCiAgIG8gIENoYW5nZSBjb250cm9sbGVyOiBJRVRGCiAgIG8gIFNwZWNpZmljYXRpb24gZG9j dW1lbnQocyk6IFtbIHRoaXMgZG9jdW1lbnQgXV0KCiAgIG8gIFBhcmFtZXRlciBuYW1lOiBjb2Rl CiAgIG8gIFBhcmFtZXRlciB1c2FnZSBsb2NhdGlvbjogYXV0aG9yaXphdGlvbiByZXNwb25zZSwg dG9rZW4gcmVxdWVzdAogICBvICBDaGFuZ2UgY29udHJvbGxlcjogSUVURgogICBvICBTcGVjaWZp Y2F0aW9uIGRvY3VtZW50KHMpOiBbWyB0aGlzIGRvY3VtZW50IF1dCgogICBvICBQYXJhbWV0ZXIg bmFtZTogZXJyb3JfZGVzY3JpcHRpb24KICAgbyAgUGFyYW1ldGVyIHVzYWdlIGxvY2F0aW9uOiBh dXRob3JpemF0aW9uIHJlc3BvbnNlLCB0b2tlbiByZXNwb25zZQogICBvICBDaGFuZ2UgY29udHJv bGxlcjogSUVURgogICBvICBTcGVjaWZpY2F0aW9uIGRvY3VtZW50KHMpOiBbWyB0aGlzIGRvY3Vt ZW50IF1dCgogICBvICBQYXJhbWV0ZXIgbmFtZTogZXJyb3JfdXJpCiAgIG8gIFBhcmFtZXRlciB1 c2FnZSBsb2NhdGlvbjogYXV0aG9yaXphdGlvbiByZXNwb25zZSwgdG9rZW4gcmVzcG9uc2UKICAg byAgQ2hhbmdlIGNvbnRyb2xsZXI6IElFVEYKICAgbyAgU3BlY2lmaWNhdGlvbiBkb2N1bWVudChz KTogW1sgdGhpcyBkb2N1bWVudCBdXQoKICAgbyAgUGFyYW1ldGVyIG5hbWU6IGdyYW50X3R5cGUK ICAgbyAgUGFyYW1ldGVyIHVzYWdlIGxvY2F0aW9uOiB0b2tlbiByZXF1ZXN0CiAgIG8gIENoYW5n ZSBjb250cm9sbGVyOiBJRVRGCiAgIG8gIFNwZWNpZmljYXRpb24gZG9jdW1lbnQocyk6IFtbIHRo aXMgZG9jdW1lbnQgXV0KCiAgIG8gIFBhcmFtZXRlciBuYW1lOiBhY2Nlc3NfdG9rZW4KICAgbyAg UGFyYW1ldGVyIHVzYWdlIGxvY2F0aW9uOiBhdXRob3JpemF0aW9uIHJlc3BvbnNlLCB0b2tlbiBy ZXNwb25zZQoKCgoKCkhhbW1lciwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgRGVjZW1iZXIgNCwg MjAxMiAgICAgICAgICAgICAgIFtQYWdlIDYwXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAg ICAgICAgT0F1dGggMi4wICAgICAgICAgICAgICAgICAgICAgIEp1bmUgMjAxMgoKCiAgIG8gIENo YW5nZSBjb250cm9sbGVyOiBJRVRGCiAgIG8gIFNwZWNpZmljYXRpb24gZG9jdW1lbnQocyk6IFtb IHRoaXMgZG9jdW1lbnQgXV0KCiAgIG8gIFBhcmFtZXRlciBuYW1lOiB0b2tlbl90eXBlCiAgIG8g IFBhcmFtZXRlciB1c2FnZSBsb2NhdGlvbjogYXV0aG9yaXphdGlvbiByZXNwb25zZSwgdG9rZW4g cmVzcG9uc2UKICAgbyAgQ2hhbmdlIGNvbnRyb2xsZXI6IElFVEYKICAgbyAgU3BlY2lmaWNhdGlv biBkb2N1bWVudChzKTogW1sgdGhpcyBkb2N1bWVudCBdXQoKICAgbyAgUGFyYW1ldGVyIG5hbWU6 IGV4cGlyZXNfaW4KICAgbyAgUGFyYW1ldGVyIHVzYWdlIGxvY2F0aW9uOiBhdXRob3JpemF0aW9u IHJlc3BvbnNlLCB0b2tlbiByZXNwb25zZQogICBvICBDaGFuZ2UgY29udHJvbGxlcjogSUVURgog ICBvICBTcGVjaWZpY2F0aW9uIGRvY3VtZW50KHMpOiBbWyB0aGlzIGRvY3VtZW50IF1dCgogICBv ICBQYXJhbWV0ZXIgbmFtZTogdXNlcm5hbWUKICAgbyAgUGFyYW1ldGVyIHVzYWdlIGxvY2F0aW9u OiB0b2tlbiByZXF1ZXN0CiAgIG8gIENoYW5nZSBjb250cm9sbGVyOiBJRVRGCiAgIG8gIFNwZWNp ZmljYXRpb24gZG9jdW1lbnQocyk6IFtbIHRoaXMgZG9jdW1lbnQgXV0KCiAgIG8gIFBhcmFtZXRl ciBuYW1lOiBwYXNzd29yZAogICBvICBQYXJhbWV0ZXIgdXNhZ2UgbG9jYXRpb246IHRva2VuIHJl cXVlc3QKICAgbyAgQ2hhbmdlIGNvbnRyb2xsZXI6IElFVEYKICAgbyAgU3BlY2lmaWNhdGlvbiBk b2N1bWVudChzKTogW1sgdGhpcyBkb2N1bWVudCBdXQoKICAgbyAgUGFyYW1ldGVyIG5hbWU6IHJl ZnJlc2hfdG9rZW4KICAgbyAgUGFyYW1ldGVyIHVzYWdlIGxvY2F0aW9uOiB0b2tlbiByZXF1ZXN0 LCB0b2tlbiByZXNwb25zZQogICBvICBDaGFuZ2UgY29udHJvbGxlcjogSUVURgogICBvICBTcGVj aWZpY2F0aW9uIGRvY3VtZW50KHMpOiBbWyB0aGlzIGRvY3VtZW50IF1dCgoxMS4zLiAgVGhlIE9B dXRoIEF1dGhvcml6YXRpb24gRW5kcG9pbnQgUmVzcG9uc2UgVHlwZSBSZWdpc3RyeQoKICAgVGhp cyBzcGVjaWZpY2F0aW9uIGVzdGFibGlzaGVzIHRoZSBPQXV0aCBhdXRob3JpemF0aW9uIGVuZHBv aW50CiAgIHJlc3BvbnNlIHR5cGUgcmVnaXN0cnkuCgogICBBZGRpdGlvbmFsIHJlc3BvbnNlIHR5 cGUgZm9yIHVzZSB3aXRoIHRoZSBhdXRob3JpemF0aW9uIGVuZHBvaW50IGFyZQogICByZWdpc3Rl cmVkIHdpdGggYSBTcGVjaWZpY2F0aW9uIFJlcXVpcmVkIChbUkZDNTIyNl0pIGFmdGVyIGEgdHdv IHdlZWsKICAgcmV2aWV3IHBlcmlvZCBvbiB0aGUgW1RCRF1AaWV0Zi5vcmcgbWFpbGluZyBsaXN0 LCBvbiB0aGUgYWR2aWNlIG9mCiAgIG9uZSBvciBtb3JlIERlc2lnbmF0ZWQgRXhwZXJ0cy4gIEhv d2V2ZXIsIHRvIGFsbG93IGZvciB0aGUgYWxsb2NhdGlvbgogICBvZiB2YWx1ZXMgcHJpb3IgdG8g cHVibGljYXRpb24sIHRoZSBEZXNpZ25hdGVkIEV4cGVydChzKSBtYXkgYXBwcm92ZQogICByZWdp c3RyYXRpb24gb25jZSB0aGV5IGFyZSBzYXRpc2ZpZWQgdGhhdCBzdWNoIGEgc3BlY2lmaWNhdGlv biB3aWxsCiAgIGJlIHB1Ymxpc2hlZC4KCiAgIFJlZ2lzdHJhdGlvbiByZXF1ZXN0cyBtdXN0IGJl IHNlbnQgdG8gdGhlIFtUQkRdQGlldGYub3JnIG1haWxpbmcgbGlzdAogICBmb3IgcmV2aWV3IGFu ZCBjb21tZW50LCB3aXRoIGFuIGFwcHJvcHJpYXRlIHN1YmplY3QgKGUuZy4sICJSZXF1ZXN0CiAg IGZvciByZXNwb25zZSB0eXBlOiBleGFtcGxlIikuIFtbIE5vdGUgdG8gUkZDLUVESVRPUjogVGhl IG5hbWUgb2YgdGhlCiAgIG1haWxpbmcgbGlzdCBzaG91bGQgYmUgZGV0ZXJtaW5lZCBpbiBjb25z dWx0YXRpb24gd2l0aCB0aGUgSUVTRyBhbmQKICAgSUFOQS4gIFN1Z2dlc3RlZCBuYW1lOiBvYXV0 aC1leHQtcmV2aWV3LiBdXQoKICAgV2l0aGluIHRoZSByZXZpZXcgcGVyaW9kLCB0aGUgRGVzaWdu YXRlZCBFeHBlcnQocykgd2lsbCBlaXRoZXIKCgoKSGFtbWVyLCBldCBhbC4gICAgICAgICAgRXhw aXJlcyBEZWNlbWJlciA0LCAyMDEyICAgICAgICAgICAgICAgW1BhZ2UgNjFdCgwKSW50ZXJuZXQt RHJhZnQgICAgICAgICAgICAgICAgICBPQXV0aCAyLjAgICAgICAgICAgICAgICAgICAgICAgSnVu ZSAyMDEyCgoKICAgYXBwcm92ZSBvciBkZW55IHRoZSByZWdpc3RyYXRpb24gcmVxdWVzdCwgY29t bXVuaWNhdGluZyB0aGlzIGRlY2lzaW9uCiAgIHRvIHRoZSByZXZpZXcgbGlzdCBhbmQgSUFOQS4g IERlbmlhbHMgc2hvdWxkIGluY2x1ZGUgYW4gZXhwbGFuYXRpb24KICAgYW5kLCBpZiBhcHBsaWNh YmxlLCBzdWdnZXN0aW9ucyBhcyB0byBob3cgdG8gbWFrZSB0aGUgcmVxdWVzdAogICBzdWNjZXNz ZnVsLgoKICAgSUFOQSBtdXN0IG9ubHkgYWNjZXB0IHJlZ2lzdHJ5IHVwZGF0ZXMgZnJvbSB0aGUg RGVzaWduYXRlZCBFeHBlcnQocyksCiAgIGFuZCBzaG91bGQgZGlyZWN0IGFsbCByZXF1ZXN0cyBm b3IgcmVnaXN0cmF0aW9uIHRvIHRoZSByZXZpZXcgbWFpbGluZwogICBsaXN0LgoKMTEuMy4xLiAg UmVnaXN0cmF0aW9uIFRlbXBsYXRlCgogICBSZXNwb25zZSB0eXBlIG5hbWU6CiAgICAgIFRoZSBu YW1lIHJlcXVlc3RlZCAoZS5nLiwgImV4YW1wbGUiKS4KICAgQ2hhbmdlIGNvbnRyb2xsZXI6CiAg ICAgIEZvciBzdGFuZGFyZHMtdHJhY2sgUkZDcywgc3RhdGUgIklFVEYiLiAgRm9yIG90aGVycywg Z2l2ZSB0aGUgbmFtZQogICAgICBvZiB0aGUgcmVzcG9uc2libGUgcGFydHkuICBPdGhlciBkZXRh aWxzIChlLmcuLCBwb3N0YWwgYWRkcmVzcywKICAgICAgZS1tYWlsIGFkZHJlc3MsIGhvbWUgcGFn ZSBVUkkpIG1heSBhbHNvIGJlIGluY2x1ZGVkLgogICBTcGVjaWZpY2F0aW9uIGRvY3VtZW50KHMp OgogICAgICBSZWZlcmVuY2UgdG8gdGhlIGRvY3VtZW50IHRoYXQgc3BlY2lmaWVzIHRoZSB0eXBl LCBwcmVmZXJhYmx5CiAgICAgIGluY2x1ZGluZyBhIFVSSSB0aGF0IGNhbiBiZSB1c2VkIHRvIHJl dHJpZXZlIGEgY29weSBvZiB0aGUKICAgICAgZG9jdW1lbnQuICBBbiBpbmRpY2F0aW9uIG9mIHRo ZSByZWxldmFudCBzZWN0aW9ucyBtYXkgYWxzbyBiZQogICAgICBpbmNsdWRlZCwgYnV0IGlzIG5v dCByZXF1aXJlZC4KCjExLjMuMi4gIEluaXRpYWwgUmVnaXN0cnkgQ29udGVudHMKCiAgIFRoZSBP QXV0aCBBdXRob3JpemF0aW9uIEVuZHBvaW50IFJlc3BvbnNlIFR5cGUgUmVnaXN0cnkncyBpbml0 aWFsCiAgIGNvbnRlbnRzIGFyZToKCiAgIG8gIFJlc3BvbnNlIHR5cGUgbmFtZTogY29kZQogICBv ICBDaGFuZ2UgY29udHJvbGxlcjogSUVURgogICBvICBTcGVjaWZpY2F0aW9uIGRvY3VtZW50KHMp OiBbWyB0aGlzIGRvY3VtZW50IF1dCgogICBvICBSZXNwb25zZSB0eXBlIG5hbWU6IHRva2VuCiAg IG8gIENoYW5nZSBjb250cm9sbGVyOiBJRVRGCiAgIG8gIFNwZWNpZmljYXRpb24gZG9jdW1lbnQo cyk6IFtbIHRoaXMgZG9jdW1lbnQgXV0KCjExLjQuICBUaGUgT0F1dGggRXh0ZW5zaW9ucyBFcnJv ciBSZWdpc3RyeQoKICAgVGhpcyBzcGVjaWZpY2F0aW9uIGVzdGFibGlzaGVzIHRoZSBPQXV0aCBl eHRlbnNpb25zIGVycm9yIHJlZ2lzdHJ5LgoKICAgQWRkaXRpb25hbCBlcnJvciBjb2RlcyB1c2Vk IHRvZ2V0aGVyIHdpdGggb3RoZXIgcHJvdG9jb2wgZXh0ZW5zaW9ucwogICAoaS5lLiBleHRlbnNp b24gZ3JhbnQgdHlwZXMsIGFjY2VzcyB0b2tlbiB0eXBlcywgb3IgZXh0ZW5zaW9uCiAgIHBhcmFt ZXRlcnMpIGFyZSByZWdpc3RlcmVkIHdpdGggYSBTcGVjaWZpY2F0aW9uIFJlcXVpcmVkIChbUkZD NTIyNl0pCiAgIGFmdGVyIGEgdHdvIHdlZWsgcmV2aWV3IHBlcmlvZCBvbiB0aGUgW1RCRF1AaWV0 Zi5vcmcgbWFpbGluZyBsaXN0LCBvbgogICB0aGUgYWR2aWNlIG9mIG9uZSBvciBtb3JlIERlc2ln bmF0ZWQgRXhwZXJ0cy4gIEhvd2V2ZXIsIHRvIGFsbG93IGZvcgogICB0aGUgYWxsb2NhdGlvbiBv ZiB2YWx1ZXMgcHJpb3IgdG8gcHVibGljYXRpb24sIHRoZSBEZXNpZ25hdGVkCiAgIEV4cGVydChz KSBtYXkgYXBwcm92ZSByZWdpc3RyYXRpb24gb25jZSB0aGV5IGFyZSBzYXRpc2ZpZWQgdGhhdCBz dWNoCiAgIGEgc3BlY2lmaWNhdGlvbiB3aWxsIGJlIHB1Ymxpc2hlZC4KCgoKSGFtbWVyLCBldCBh bC4gICAgICAgICAgRXhwaXJlcyBEZWNlbWJlciA0LCAyMDEyICAgICAgICAgICAgICAgW1BhZ2Ug NjJdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICBPQXV0aCAyLjAgICAgICAgICAg ICAgICAgICAgICAgSnVuZSAyMDEyCgoKICAgUmVnaXN0cmF0aW9uIHJlcXVlc3RzIG11c3QgYmUg c2VudCB0byB0aGUgW1RCRF1AaWV0Zi5vcmcgbWFpbGluZyBsaXN0CiAgIGZvciByZXZpZXcgYW5k IGNvbW1lbnQsIHdpdGggYW4gYXBwcm9wcmlhdGUgc3ViamVjdCAoZS5nLiwgIlJlcXVlc3QKICAg Zm9yIGVycm9yIGNvZGU6IGV4YW1wbGUiKS4gW1sgTm90ZSB0byBSRkMtRURJVE9SOiBUaGUgbmFt ZSBvZiB0aGUKICAgbWFpbGluZyBsaXN0IHNob3VsZCBiZSBkZXRlcm1pbmVkIGluIGNvbnN1bHRh dGlvbiB3aXRoIHRoZSBJRVNHIGFuZAogICBJQU5BLiAgU3VnZ2VzdGVkIG5hbWU6IG9hdXRoLWV4 dC1yZXZpZXcuIF1dCgogICBXaXRoaW4gdGhlIHJldmlldyBwZXJpb2QsIHRoZSBEZXNpZ25hdGVk IEV4cGVydChzKSB3aWxsIGVpdGhlcgogICBhcHByb3ZlIG9yIGRlbnkgdGhlIHJlZ2lzdHJhdGlv biByZXF1ZXN0LCBjb21tdW5pY2F0aW5nIHRoaXMgZGVjaXNpb24KICAgdG8gdGhlIHJldmlldyBs aXN0IGFuZCBJQU5BLiAgRGVuaWFscyBzaG91bGQgaW5jbHVkZSBhbiBleHBsYW5hdGlvbgogICBh bmQsIGlmIGFwcGxpY2FibGUsIHN1Z2dlc3Rpb25zIGFzIHRvIGhvdyB0byBtYWtlIHRoZSByZXF1 ZXN0CiAgIHN1Y2Nlc3NmdWwuCgogICBJQU5BIG11c3Qgb25seSBhY2NlcHQgcmVnaXN0cnkgdXBk YXRlcyBmcm9tIHRoZSBEZXNpZ25hdGVkIEV4cGVydChzKSwKICAgYW5kIHNob3VsZCBkaXJlY3Qg YWxsIHJlcXVlc3RzIGZvciByZWdpc3RyYXRpb24gdG8gdGhlIHJldmlldyBtYWlsaW5nCiAgIGxp c3QuCgoxMS40LjEuICBSZWdpc3RyYXRpb24gVGVtcGxhdGUKCiAgIEVycm9yIG5hbWU6CiAgICAg IFRoZSBuYW1lIHJlcXVlc3RlZCAoZS5nLiwgImV4YW1wbGUiKS4KICAgRXJyb3IgdXNhZ2UgbG9j YXRpb246CiAgICAgIFRoZSBsb2NhdGlvbihzKSB3aGVyZSB0aGUgZXJyb3IgY2FuIGJlIHVzZWQu ICBUaGUgcG9zc2libGUKICAgICAgbG9jYXRpb25zIGFyZTogYXV0aG9yaXphdGlvbiBjb2RlIGdy YW50IGVycm9yIHJlc3BvbnNlCiAgICAgIChTZWN0aW9uIDQuMS4yLjEpLCBpbXBsaWNpdCBncmFu dCBlcnJvciByZXNwb25zZQogICAgICAoU2VjdGlvbiA0LjIuMi4xKSwgdG9rZW4gZXJyb3IgcmVz cG9uc2UgKFNlY3Rpb24gNS4yKSwgb3IgcmVzb3VyY2UKICAgICAgYWNjZXNzIGVycm9yIHJlc3Bv bnNlIChTZWN0aW9uIDcuMikuCiAgIFJlbGF0ZWQgcHJvdG9jb2wgZXh0ZW5zaW9uOgogICAgICBU aGUgbmFtZSBvZiB0aGUgZXh0ZW5zaW9uIGdyYW50IHR5cGUsIGFjY2VzcyB0b2tlbiB0eXBlLCBv cgogICAgICBleHRlbnNpb24gcGFyYW1ldGVyLCB0aGUgZXJyb3IgY29kZSBpcyB1c2VkIGluIGNv bmp1bmN0aW9uIHdpdGguCiAgIENoYW5nZSBjb250cm9sbGVyOgogICAgICBGb3Igc3RhbmRhcmRz LXRyYWNrIFJGQ3MsIHN0YXRlICJJRVRGIi4gIEZvciBvdGhlcnMsIGdpdmUgdGhlIG5hbWUKICAg ICAgb2YgdGhlIHJlc3BvbnNpYmxlIHBhcnR5LiAgT3RoZXIgZGV0YWlscyAoZS5nLiwgcG9zdGFs IGFkZHJlc3MsCiAgICAgIGUtbWFpbCBhZGRyZXNzLCBob21lIHBhZ2UgVVJJKSBtYXkgYWxzbyBi ZSBpbmNsdWRlZC4KICAgU3BlY2lmaWNhdGlvbiBkb2N1bWVudChzKToKICAgICAgUmVmZXJlbmNl IHRvIHRoZSBkb2N1bWVudCB0aGF0IHNwZWNpZmllcyB0aGUgZXJyb3IgY29kZSwKICAgICAgcHJl ZmVyYWJseSBpbmNsdWRpbmcgYSBVUkkgdGhhdCBjYW4gYmUgdXNlZCB0byByZXRyaWV2ZSBhIGNv cHkgb2YKICAgICAgdGhlIGRvY3VtZW50LiAgQW4gaW5kaWNhdGlvbiBvZiB0aGUgcmVsZXZhbnQg c2VjdGlvbnMgbWF5IGFsc28gYmUKICAgICAgaW5jbHVkZWQsIGJ1dCBpcyBub3QgcmVxdWlyZWQu CgoKMTIuICBSZWZlcmVuY2VzCgoxMi4xLiAgTm9ybWF0aXZlIFJlZmVyZW5jZXMKCiAgIFtSRkMy MTE5XSAgQnJhZG5lciwgUy4sICJLZXkgd29yZHMgZm9yIHVzZSBpbiBSRkNzIHRvIEluZGljYXRl CiAgICAgICAgICAgICAgUmVxdWlyZW1lbnQgTGV2ZWxzIiwgQkNQIDE0LCBSRkMgMjExOSwgTWFy Y2ggMTk5Ny4KCiAgIFtSRkMyMjQ2XSAgRGllcmtzLCBULiBhbmQgQy4gQWxsZW4sICJUaGUgVExT IFByb3RvY29sIFZlcnNpb24gMS4wIiwKCgoKSGFtbWVyLCBldCBhbC4gICAgICAgICAgRXhwaXJl cyBEZWNlbWJlciA0LCAyMDEyICAgICAgICAgICAgICAgW1BhZ2UgNjNdCgwKSW50ZXJuZXQtRHJh ZnQgICAgICAgICAgICAgICAgICBPQXV0aCAyLjAgICAgICAgICAgICAgICAgICAgICAgSnVuZSAy MDEyCgoKICAgICAgICAgICAgICBSRkMgMjI0NiwgSmFudWFyeSAxOTk5LgoKICAgW1JGQzI2MTZd ICBGaWVsZGluZywgUi4sIEdldHR5cywgSi4sIE1vZ3VsLCBKLiwgRnJ5c3R5aywgSC4sCiAgICAg ICAgICAgICAgTWFzaW50ZXIsIEwuLCBMZWFjaCwgUC4sIGFuZCBULiBCZXJuZXJzLUxlZSwgIkh5 cGVydGV4dAogICAgICAgICAgICAgIFRyYW5zZmVyIFByb3RvY29sIC0tIEhUVFAvMS4xIiwgUkZD IDI2MTYsIEp1bmUgMTk5OS4KCiAgIFtSRkMyNjE3XSAgRnJhbmtzLCBKLiwgSGFsbGFtLUJha2Vy LCBQLiwgSG9zdGV0bGVyLCBKLiwgTGF3cmVuY2UsIFMuLAogICAgICAgICAgICAgIExlYWNoLCBQ LiwgTHVvdG9uZW4sIEEuLCBhbmQgTC4gU3Rld2FydCwgIkhUVFAKICAgICAgICAgICAgICBBdXRo ZW50aWNhdGlvbjogQmFzaWMgYW5kIERpZ2VzdCBBY2Nlc3MgQXV0aGVudGljYXRpb24iLAogICAg ICAgICAgICAgIFJGQyAyNjE3LCBKdW5lIDE5OTkuCgogICBbUkZDMjgxOF0gIFJlc2NvcmxhLCBF LiwgIkhUVFAgT3ZlciBUTFMiLCBSRkMgMjgxOCwgTWF5IDIwMDAuCgogICBbUkZDMzk4Nl0gIEJl cm5lcnMtTGVlLCBULiwgRmllbGRpbmcsIFIuLCBhbmQgTC4gTWFzaW50ZXIsICJVbmlmb3JtCiAg ICAgICAgICAgICAgUmVzb3VyY2UgSWRlbnRpZmllciAoVVJJKTogR2VuZXJpYyBTeW50YXgiLCBT VEQgNjYsCiAgICAgICAgICAgICAgUkZDIDM5ODYsIEphbnVhcnkgMjAwNS4KCiAgIFtSRkM0NjI3 XSAgQ3JvY2tmb3JkLCBELiwgIlRoZSBhcHBsaWNhdGlvbi9qc29uIE1lZGlhIFR5cGUgZm9yCiAg ICAgICAgICAgICAgSmF2YVNjcmlwdCBPYmplY3QgTm90YXRpb24gKEpTT04pIiwgUkZDIDQ2Mjcs IEp1bHkgMjAwNi4KCiAgIFtSRkM0OTQ5XSAgU2hpcmV5LCBSLiwgIkludGVybmV0IFNlY3VyaXR5 IEdsb3NzYXJ5LCBWZXJzaW9uIDIiLAogICAgICAgICAgICAgIFJGQyA0OTQ5LCBBdWd1c3QgMjAw Ny4KCiAgIFtSRkM1MjI2XSAgTmFydGVuLCBULiBhbmQgSC4gQWx2ZXN0cmFuZCwgIkd1aWRlbGlu ZXMgZm9yIFdyaXRpbmcgYW4KICAgICAgICAgICAgICBJQU5BIENvbnNpZGVyYXRpb25zIFNlY3Rp b24gaW4gUkZDcyIsIEJDUCAyNiwgUkZDIDUyMjYsCiAgICAgICAgICAgICAgTWF5IDIwMDguCgog ICBbUkZDNTIzNF0gIENyb2NrZXIsIEQuIGFuZCBQLiBPdmVyZWxsLCAiQXVnbWVudGVkIEJORiBm b3IgU3ludGF4CiAgICAgICAgICAgICAgU3BlY2lmaWNhdGlvbnM6IEFCTkYiLCBTVEQgNjgsIFJG QyA1MjM0LCBKYW51YXJ5IDIwMDguCgogICBbUkZDNTI0Nl0gIERpZXJrcywgVC4gYW5kIEUuIFJl c2NvcmxhLCAiVGhlIFRyYW5zcG9ydCBMYXllciBTZWN1cml0eQogICAgICAgICAgICAgIChUTFMp IFByb3RvY29sIFZlcnNpb24gMS4yIiwgUkZDIDUyNDYsIEF1Z3VzdCAyMDA4LgoKICAgW1JGQzYx MjVdICBTYWludC1BbmRyZSwgUC4gYW5kIEouIEhvZGdlcywgIlJlcHJlc2VudGF0aW9uIGFuZAog ICAgICAgICAgICAgIFZlcmlmaWNhdGlvbiBvZiBEb21haW4tQmFzZWQgQXBwbGljYXRpb24gU2Vy dmljZSBJZGVudGl0eQogICAgICAgICAgICAgIHdpdGhpbiBJbnRlcm5ldCBQdWJsaWMgS2V5IElu ZnJhc3RydWN0dXJlIFVzaW5nIFguNTA5CiAgICAgICAgICAgICAgKFBLSVgpIENlcnRpZmljYXRl cyBpbiB0aGUgQ29udGV4dCBvZiBUcmFuc3BvcnQgTGF5ZXIKICAgICAgICAgICAgICBTZWN1cml0 eSAoVExTKSIsIFJGQyA2MTI1LCBNYXJjaCAyMDExLgoKICAgW1VTQVNDSUldICBBbWVyaWNhbiBO YXRpb25hbCBTdGFuZGFyZHMgSW5zdGl0dXRlLCAiQ29kZWQgQ2hhcmFjdGVyCiAgICAgICAgICAg ICAgU2V0IC0tIDctYml0IEFtZXJpY2FuIFN0YW5kYXJkIENvZGUgZm9yIEluZm9ybWF0aW9uCiAg ICAgICAgICAgICAgSW50ZXJjaGFuZ2UiLCBBTlNJIFgzLjQsIDE5ODYuCgogICBbVzNDLlJFQy1o dG1sNDAxLTE5OTkxMjI0XQogICAgICAgICAgICAgIEhvcnMsIEEuLCBSYWdnZXR0LCBELiwgYW5k IEkuIEphY29icywgIkhUTUwgNC4wMQogICAgICAgICAgICAgIFNwZWNpZmljYXRpb24iLCBXb3Js ZCBXaWRlIFdlYiBDb25zb3J0aXVtCiAgICAgICAgICAgICAgUmVjb21tZW5kYXRpb24gUkVDLWh0 bWw0MDEtMTk5OTEyMjQsIERlY2VtYmVyIDE5OTksCiAgICAgICAgICAgICAgPGh0dHA6Ly93d3cu dzMub3JnL1RSLzE5OTkvUkVDLWh0bWw0MDEtMTk5OTEyMjQ+LgoKCgpIYW1tZXIsIGV0IGFsLiAg ICAgICAgICBFeHBpcmVzIERlY2VtYmVyIDQsIDIwMTIgICAgICAgICAgICAgICBbUGFnZSA2NF0K DApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgIE9BdXRoIDIuMCAgICAgICAgICAgICAg ICAgICAgICBKdW5lIDIwMTIKCgoxMi4yLiAgSW5mb3JtYXRpdmUgUmVmZXJlbmNlcwoKICAgW0kt RC5kcmFmdC1oYXJkdC1vYXV0aC0wMV0KICAgICAgICAgICAgICBIYXJkdCwgRC4sIEVkLiwgVG9t LCBBLiwgRWF0b24sIEIuLCBhbmQgWS4gR29sYW5kLCAiT0F1dGgKICAgICAgICAgICAgICBXZWIg UmVzb3VyY2UgQXV0aG9yaXphdGlvbiBQcm9maWxlcyIsIEphbnVhcnkgMjAxMC4KCiAgIFtJLUQu aWV0Zi1odHRwYmlzLXA3LWF1dGhdCiAgICAgICAgICAgICAgRmllbGRpbmcsIFIuLCBMYWZvbiwg WS4sIGFuZCBKLiBSZXNjaGtlLCAiSFRUUC8xLjEsIHBhcnQKICAgICAgICAgICAgICA3OiBBdXRo ZW50aWNhdGlvbiIsIGRyYWZ0LWlldGYtaHR0cGJpcy1wNy1hdXRoLTE5ICh3b3JrIGluCiAgICAg ICAgICAgICAgcHJvZ3Jlc3MpLCBNYXJjaCAyMDEyLgoKICAgW0ktRC5pZXRmLW9hdXRoLXNhbWwy LWJlYXJlcl0KICAgICAgICAgICAgICBNb3J0aW1vcmUsIEMuLCAiU0FNTCAyLjAgQmVhcmVyIEFz c2VydGlvbiBQcm9maWxlcyBmb3IKICAgICAgICAgICAgICBPQXV0aCAyLjAiLCBkcmFmdC1pZXRm LW9hdXRoLXNhbWwyLWJlYXJlci0xMiAod29yayBpbgogICAgICAgICAgICAgIHByb2dyZXNzKSwg TWF5IDIwMTIuCgogICBbSS1ELmlldGYtb2F1dGgtdjItYmVhcmVyXQogICAgICAgICAgICAgIEpv bmVzLCBNLiwgSGFyZHQsIEQuLCBhbmQgRC4gUmVjb3Jkb24sICJUaGUgT0F1dGggMi4wCiAgICAg ICAgICAgICAgQXV0aG9yaXphdGlvbiBQcm90b2NvbDogQmVhcmVyIFRva2VucyIsCiAgICAgICAg ICAgICAgZHJhZnQtaWV0Zi1vYXV0aC12Mi1iZWFyZXItMTkgKHdvcmsgaW4gcHJvZ3Jlc3MpLAog ICAgICAgICAgICAgIEFwcmlsIDIwMTIuCgogICBbSS1ELmlldGYtb2F1dGgtdjItaHR0cC1tYWNd CiAgICAgICAgICAgICAgSGFtbWVyLUxhaGF2LCBFLiwgIkhUVFAgQXV0aGVudGljYXRpb246IE1B QyBBY2Nlc3MKICAgICAgICAgICAgICBBdXRoZW50aWNhdGlvbiIsIGRyYWZ0LWlldGYtb2F1dGgt djItaHR0cC1tYWMtMDEgKHdvcmsgaW4KICAgICAgICAgICAgICBwcm9ncmVzcyksIEZlYnJ1YXJ5 IDIwMTIuCgogICBbSS1ELmlldGYtb2F1dGgtdjItdGhyZWF0bW9kZWxdCiAgICAgICAgICAgICAg TWNHbG9pbiwgTS4sIEh1bnQsIFAuLCBhbmQgVC4gTG9kZGVyc3RlZHQsICJPQXV0aCAyLjAKICAg ICAgICAgICAgICBUaHJlYXQgTW9kZWwgYW5kIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIiwKICAg ICAgICAgICAgICBkcmFmdC1pZXRmLW9hdXRoLXYyLXRocmVhdG1vZGVsLTAyICh3b3JrIGluIHBy b2dyZXNzKSwKICAgICAgICAgICAgICBGZWJydWFyeSAyMDEyLgoKICAgW1JGQzU4NDldICBIYW1t ZXItTGFoYXYsIEUuLCAiVGhlIE9BdXRoIDEuMCBQcm90b2NvbCIsIFJGQyA1ODQ5LAogICAgICAg ICAgICAgIEFwcmlsIDIwMTAuCgoKQXBwZW5kaXggQS4gIEF1Z21lbnRlZCBCYWNrdXMtTmF1ciBG b3JtIChBQk5GKSBTeW50YXgKCiAgIFRoaXMgc2VjdGlvbiBwcm92aWRlcyBBdWdtZW50ZWQgQmFj a3VzLU5hdXIgRm9ybSAoQUJORikgc3ludGF4CiAgIGRlc2NyaXB0aW9ucyBmb3IgdGhlIGVsZW1l bnRzIGRlZmluZWQgaW4gdGhpcyBzcGVjaWZpY2F0aW9uIHVzaW5nIHRoZQogICBub3RhdGlvbiBv ZiBbUkZDNTIzNF0uICBFbGVtZW50cyBhcmUgcHJlc2VudGVkIGluIHRoZSBvcmRlciBmaXJzdAog ICBkZWZpbmVkLgoKICAgU29tZSBvZiB0aGUgZGVmaW5pdGlvbnMgdGhhdCBmb2xsb3cgdXNlIHRo ZSAidW5yZXNlcnZlZCIgYW5kICJVUkkiCiAgIGRlZmluaXRpb25zIGZyb20gW1JGQzM5ODZdLCB3 aGljaCBhcmU6CgogICB1bnJlc2VydmVkID0gQUxQSEEgLyBESUdJVCAvICItIiAvICIuIiAvICJf IiAvICJ+IgoKCgpIYW1tZXIsIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIERlY2VtYmVyIDQsIDIw MTIgICAgICAgICAgICAgICBbUGFnZSA2NV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAg ICAgIE9BdXRoIDIuMCAgICAgICAgICAgICAgICAgICAgICBKdW5lIDIwMTIKCgogICBVUkkgICAg ICAgID0gc2NoZW1lICI6IiBoaWVyLXBhcnQgWyAiPyIgcXVlcnkgXSBbICIjIiBmcmFnbWVudCBd CgogICBTb21lIG9mIHRoZSBkZWZpbml0aW9ucyB0aGF0IGZvbGxvdyB1c2UgdGhlICJiNjR0b2tl biIgc3ludGF4IGJlbG93LAogICB3aGljaCBtYXRjaGVzIHRoZSAiYjY0dG9rZW4iIHN5bnRheCBk ZWZpbmVkIGJ5IEhUVFAvMS4xLCBQYXJ0IDcKICAgW0ktRC5pZXRmLWh0dHBiaXMtcDctYXV0aF06 CgogICBiNjR0b2tlbiAgID0gMSooIEFMUEhBIC8gRElHSVQgLwogICAgICAgICAgICAgICAgICAg ICItIiAvICIuIiAvICJfIiAvICJ+IiAvICIrIiAvICIvIiApICoiPSIKCkEuMS4gICJjbGllbnRf aWQiIFN5bnRheAoKICAgVGhlICJjbGllbnRfaWQiIGVsZW1lbnQgaXMgZGVmaW5lZCBpbiBTZWN0 aW9uIDIuMy4xOgoKICAgY2xpZW50LWlkICAgICA9ICo8VEVYVCBleGNsdWRpbmcgIjoiPgoKICAg KFRoaXMgbWF0Y2hlcyB0aGUgInVzZXJpZCIgZGVmaW5pdGlvbiBpbiB0aGUgSFRUUCBCYXNpYwog ICBBdXRoZW50aWNhdGlvbiBTY2hlbWUgW1JGQzI2MTddLikKCkEuMi4gICJjbGllbnRfc2VjcmV0 IiBTeW50YXgKCiAgIFRoZSAiY2xpZW50X3NlY3JldCIgZWxlbWVudCBpcyBkZWZpbmVkIGluIFNl Y3Rpb24gMi4zLjE6CgogICBjbGllbnQtc2VjcmV0ID0gKlRFWFQKCiAgIChUaGlzIG1hdGNoZXMg dGhlICJwYXNzd29yZCIgZGVmaW5pdGlvbiBpbiB0aGUgSFRUUCBCYXNpYwogICBBdXRoZW50aWNh dGlvbiBTY2hlbWUgW1JGQzI2MTddLikKCkEuMy4gICJyZXNwb25zZV90eXBlIiBTeW50YXgKCiAg IFRoZSAicmVzcG9uc2VfdHlwZSIgZWxlbWVudCBpcyBkZWZpbmVkIGluIFNlY3Rpb24gMy4xLjEg YW5kCiAgIFNlY3Rpb24gOC40OgoKICAgcmVzcG9uc2UtdHlwZSA9IHJlc3BvbnNlLW5hbWUgKigg U1AgcmVzcG9uc2UtbmFtZSApCiAgIHJlc3BvbnNlLW5hbWUgPSAxKnJlc3BvbnNlLWNoYXIKICAg cmVzcG9uc2UtY2hhciA9ICJfIiAvIERJR0lUIC8gQUxQSEEKCkEuNC4gICJzY29wZSIgU3ludGF4 CgogICBUaGUgInNjb3BlIiBlbGVtZW50IGlzIGRlZmluZWQgaW4gU2VjdGlvbiAzLjM6CgogICBz Y29wZSAgICAgICA9IHNjb3BlLXRva2VuICooIFNQIHNjb3BlLXRva2VuICkKICAgc2NvcGUtdG9r ZW4gPSAxKiggJXgyMSAvICV4MjMtNUIgLyAleDVELTdFICkKCgoKCgoKCgoKSGFtbWVyLCBldCBh bC4gICAgICAgICAgRXhwaXJlcyBEZWNlbWJlciA0LCAyMDEyICAgICAgICAgICAgICAgW1BhZ2Ug NjZdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICBPQXV0aCAyLjAgICAgICAgICAg ICAgICAgICAgICAgSnVuZSAyMDEyCgoKQS41LiAgInN0YXRlIiBTeW50YXgKCiAgIFRoZSAic3Rh dGUiIGVsZW1lbnQgaXMgZGVmaW5lZCBpbiBTZWN0aW9uIDQuMS4xLCBTZWN0aW9uIDQuMS4yLAog ICBTZWN0aW9uIDQuMS4yLjEsIFNlY3Rpb24gNC4yLjEsIFNlY3Rpb24gNC4yLjIsIGFuZCBTZWN0 aW9uIDQuMi4yLjE6CgogICBzdGF0ZSAgICAgID0gMSp1bnJlc2VydmVkCgpBLjYuICAicmVkaXJl Y3RfdXJpIiBTeW50YXgKCiAgIFRoZSAicmVkaXJlY3RfdXJpIiBlbGVtZW50IGlzIGRlZmluZWQg aW4gU2VjdGlvbiA0LjEuMSwKICAgU2VjdGlvbiA0LjEuMywgYW5kIFNlY3Rpb24gNC4yLjE6Cgog ICByZWRpcmVjdC11cmkgICAgICA9IFVSSQoKQS43LiAgImVycm9yIiBTeW50YXgKCiAgIFRoZSAi ZXJyb3IiIGVsZW1lbnQgaXMgZGVmaW5lZCBpbiBTZWN0aW9uIDQuMS4yLjEsIFNlY3Rpb24gNC4y LjIuMSwKICAgU2VjdGlvbiA1LjIsIFNlY3Rpb24gNy4yLCBhbmQgU2VjdGlvbiA4LjU6CgogICBl cnJvciAgICAgICAgICAgICA9IDEqZXJyb3ItY2hhcgogICBlcnJvci1jaGFyICAgICAgICA9ICV4 MjAtMjEgLyAleDIzLTVCIC8gJXg1RC03RQoKQS44LiAgImVycm9yX2Rlc2NyaXB0aW9uIiBTeW50 YXgKCiAgIFRoZSAiZXJyb3JfZGVzY3JpcHRpb24iIGVsZW1lbnQgaXMgZGVmaW5lZCBpbiBTZWN0 aW9uIDQuMS4yLjEsCiAgIFNlY3Rpb24gNC4yLjIuMSwgU2VjdGlvbiA1LjIsIGFuZCBTZWN0aW9u IDcuMjoKCiAgIGVycm9yLWRlc2NyaXB0aW9uID0gMSplcnJvci1jaGFyCiAgIGVycm9yLWNoYXIg ICAgICAgID0gJXgyMC0yMSAvICV4MjMtNUIgLyAleDVELTdFCgpBLjkuICAiZXJyb3JfdXJpIiBT eW50YXgKCiAgIFRoZSAiZXJyb3JfdXJpIiBlbGVtZW50IGlzIGRlZmluZWQgaW4gU2VjdGlvbiA0 LjEuMi4xLAogICBTZWN0aW9uIDQuMi4yLjEsIFNlY3Rpb24gNS4yLCBhbmQgU2VjdGlvbiA3LjI6 CgogICBlcnJvci11cmkgICAgICAgICA9IFVSSQoKQS4xMC4gICJncmFudF90eXBlIiBTeW50YXgK CiAgIFRoZSAiZ3JhbnRfdHlwZSIgZWxlbWVudCBpcyBkZWZpbmVkIGluIFNlY3Rpb24gNC4xLjMs IFNlY3Rpb24gNC4zLjIsCiAgIFNlY3Rpb24gNC40LjEsIFNlY3Rpb24gNiwgYW5kIFNlY3Rpb24g NC41OgoKICAgZ3JhbnQtdHlwZSA9IGdyYW50LW5hbWUgLyBVUkkKICAgZ3JhbnQtbmFtZSA9IDEq bmFtZS1jaGFyCiAgIG5hbWUtY2hhciAgPSAiLSIgLyAiLiIgLyAiXyIgLyBESUdJVCAvIEFMUEhB CgoKCgoKCkhhbW1lciwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgRGVjZW1iZXIgNCwgMjAxMiAg ICAgICAgICAgICAgIFtQYWdlIDY3XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAg T0F1dGggMi4wICAgICAgICAgICAgICAgICAgICAgIEp1bmUgMjAxMgoKCkEuMTEuICAiY29kZSIg U3ludGF4CgogICBUaGUgImNvZGUiIGVsZW1lbnQgaXMgZGVmaW5lZCBpbiBTZWN0aW9uIDQuMS4z OgoKICAgY29kZSAgICAgICA9IDEqdW5yZXNlcnZlZAoKQS4xMi4gICJhY2Nlc3NfdG9rZW4iIFN5 bnRheAoKICAgVGhlICJhY2Nlc3NfdG9rZW4iIGVsZW1lbnQgaXMgZGVmaW5lZCBpbiBTZWN0aW9u IDQuMi4yIGFuZAogICBTZWN0aW9uIDUuMToKCiAgIGFjY2Vzcy10b2tlbiA9IGI2NHRva2VuCgpB LjEzLiAgInRva2VuX3R5cGUiIFN5bnRheAoKICAgVGhlICJ0b2tlbl90eXBlIiBlbGVtZW50IGlz IGRlZmluZWQgaW4gU2VjdGlvbiA0LjIuMiwgU2VjdGlvbiA1LjEsCiAgIGFuZCBTZWN0aW9uIDgu MToKCiAgIHRva2VuLXR5cGUgPSB0eXBlLW5hbWUgLyBVUkkKICAgdHlwZS1uYW1lICA9IDEqbmFt ZS1jaGFyCiAgIG5hbWUtY2hhciAgPSAiLSIgLyAiLiIgLyAiXyIgLyBESUdJVCAvIEFMUEhBCgpB LjE0LiAgImV4cGlyZXNfaW4iIFN5bnRheAoKICAgVGhlICJleHBpcmVzX2luIiBlbGVtZW50IGlz IGRlZmluZWQgaW4gU2VjdGlvbiA0LjIuMiBhbmQgU2VjdGlvbiA1LjE6CgogICBleHBpcmVzLWlu ID0gMSpESUdJVAoKQS4xNS4gICJ1c2VybmFtZSIgU3ludGF4CgogICBUaGUgInVzZXJuYW1lIiBl bGVtZW50IGlzIGRlZmluZWQgaW4gU2VjdGlvbiA0LjMuMjoKCiAgIHVzZXJuYW1lID0gKjxURVhU IGV4Y2x1ZGluZyAiOiI+CgogICAoVGhpcyBtYXRjaGVzIHRoZSAidXNlcmlkIiBkZWZpbml0aW9u IGluIHRoZSBIVFRQIEJhc2ljCiAgIEF1dGhlbnRpY2F0aW9uIFNjaGVtZSBbUkZDMjYxN10uKQoK QS4xNi4gICJwYXNzd29yZCIgU3ludGF4CgogICBUaGUgInBhc3N3b3JkIiBlbGVtZW50IGlzIGRl ZmluZWQgaW4gU2VjdGlvbiA0LjMuMjoKCiAgIHBhc3N3b3JkID0gKlRFWFQKCiAgIChUaGlzIG1h dGNoZXMgdGhlICJwYXNzd29yZCIgZGVmaW5pdGlvbiBpbiB0aGUgSFRUUCBCYXNpYwogICBBdXRo ZW50aWNhdGlvbiBTY2hlbWUgW1JGQzI2MTddLikKCgoKCgoKSGFtbWVyLCBldCBhbC4gICAgICAg ICAgRXhwaXJlcyBEZWNlbWJlciA0LCAyMDEyICAgICAgICAgICAgICAgW1BhZ2UgNjhdCgwKSW50 ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICBPQXV0aCAyLjAgICAgICAgICAgICAgICAgICAg ICAgSnVuZSAyMDEyCgoKQS4xNy4gICJyZWZyZXNoX3Rva2VuIiBTeW50YXgKCiAgIFRoZSAicmVm cmVzaF90b2tlbiIgZWxlbWVudCBpcyBkZWZpbmVkIGluIFNlY3Rpb24gNS4xIGFuZCBTZWN0aW9u IDY6CgogICByZWZyZXNoLXRva2VuID0gYjY0dG9rZW4KCkEuMTguICBFbmRwb2ludCBQYXJhbWV0 ZXIgU3ludGF4CgogICBUaGUgc3ludGF4IGZvciBuZXcgZW5kcG9pbnQgcGFyYW1ldGVycyBpcyBk ZWZpbmVkIGluIFNlY3Rpb24gOC4yOgoKICAgcGFyYW0tbmFtZSA9IDEqbmFtZS1jaGFyCiAgIG5h bWUtY2hhciAgPSAiLSIgLyAiLiIgLyAiXyIgLyBESUdJVCAvIEFMUEhBCgoKQXBwZW5kaXggQi4g IEFja25vd2xlZGdlbWVudHMKCiAgIFRoZSBpbml0aWFsIE9BdXRoIDIuMCBwcm90b2NvbCBzcGVj aWZpY2F0aW9uIHdhcyBlZGl0ZWQgYnkgRGF2aWQKICAgUmVjb3Jkb24sIGJhc2VkIG9uIHR3byBw cmV2aW91cyBwdWJsaWNhdGlvbnM6IHRoZSBPQXV0aCAxLjAgY29tbXVuaXR5CiAgIHNwZWNpZmlj YXRpb24gW1JGQzU4NDldLCBhbmQgT0F1dGggV1JBUCAoT0F1dGggV2ViIFJlc291cmNlCiAgIEF1 dGhvcml6YXRpb24gUHJvZmlsZXMpIFtJLUQuZHJhZnQtaGFyZHQtb2F1dGgtMDFdLiAgVGhlIFNl Y3VyaXR5CiAgIENvbnNpZGVyYXRpb25zIHNlY3Rpb24gd2FzIGRyYWZ0ZWQgYnkgVG9yc3RlbiBM b2RkZXJzdGVkdCwgTWFyawogICBNY0dsb2luLCBQaGlsIEh1bnQsIGFuZCBBbnRob255IE5hZGFs aW4uICBUaGUgQUJORiBzZWN0aW9uIHdhcwogICBkcmFmdGVkIGJ5IE1pY2hhZWwgQi4gSm9uZXMu CgogICBUaGUgT0F1dGggMS4wIGNvbW11bml0eSBzcGVjaWZpY2F0aW9uIHdhcyBlZGl0ZWQgYnkg RXJhbiBIYW1tZXIgYW5kCiAgIGF1dGhvcmVkIGJ5IE1hcmsgQXR3b29kLCBEaXJrIEJhbGZhbnos IERhcnJlbiBCb3VuZHMsIFJpY2hhcmQgTS4KICAgQ29ubGFuLCBCbGFpbmUgQ29vaywgTGVhaCBD dWx2ZXIsIEJyZW5vIGRlIE1lZGVpcm9zLCBCcmlhbiBFYXRvbiwKICAgS2VsbGFuIEVsbGlvdHQt TWNDcmVhLCBMYXJyeSBIYWxmZiwgRXJhbiBIYW1tZXIsIEJlbiBMYXVyaWUsIENocmlzCiAgIE1l c3NpbmEsIEpvaG4gUGFuemVyLCBTYW0gUXVpZ2xleSwgRGF2aWQgUmVjb3Jkb24sIEVyYW4gU2Fu ZGxlciwKICAgSm9uYXRoYW4gU2VyZ2VudCwgVG9kZCBTaWVsaW5nLCBCcmlhbiBTbGVzaW5za3ks IGFuZCBBbmR5IFNtaXRoLgoKICAgVGhlIE9BdXRoIFdSQVAgc3BlY2lmaWNhdGlvbiB3YXMgZWRp dGVkIGJ5IERpY2sgSGFyZHQgYW5kIGF1dGhvcmVkIGJ5CiAgIEJyaWFuIEVhdG9uLCBZYXJvbiBZ LiBHb2xhbmQsIERpY2sgSGFyZHQsIGFuZCBBbGxlbiBUb20uCgogICBUaGlzIHNwZWNpZmljYXRp b24gaXMgdGhlIHdvcmsgb2YgdGhlIE9BdXRoIFdvcmtpbmcgR3JvdXAgd2hpY2gKICAgaW5jbHVk ZXMgZG96ZW5zIG9mIGFjdGl2ZSBhbmQgZGVkaWNhdGVkIHBhcnRpY2lwYW50cy4gIEluIHBhcnRp Y3VsYXIsCiAgIHRoZSBmb2xsb3dpbmcgaW5kaXZpZHVhbHMgY29udHJpYnV0ZWQgaWRlYXMsIGZl ZWRiYWNrLCBhbmQgd29yZGluZwogICB3aGljaCBzaGFwZWQgYW5kIGZvcm1lZCB0aGUgZmluYWwg c3BlY2lmaWNhdGlvbjoKCiAgIE1pY2hhZWwgQWRhbXMsIEFtYW5kYSBBbmdhbmVzLCBBbmRyZXcg QXJub3R0LCBEaXJrIEJhbGZhbnosIEFpZGVuCiAgIEJlbGwsIEJyaWFuIENhbXBiZWxsLCBTY290 dCBDYW50b3IsIE1hcmNvcyBDYWNlcmVzLCBCbGFpbmUgQ29vaywKICAgUm9nZXIgQ3JldywgQnJp YW4gRWF0b24sIFdlc2xleSBFZGR5LCBMZWFoIEN1bHZlciwgQmlsbCBkZSBoT3JhLAogICBBbmRy ZSBEZU1hcnJlLCBCcmlhbiBFYXRvbiwgV29sdGVyIEVsZGVyaW5nLCBCcmlhbiBFbGxpbiwgSWdv cgogICBGYXluYmVyZywgR2VvcmdlIEZsZXRjaGVyLCBUaW0gRnJlZW1hbiwgTHVjYSBGcm9zaW5p LCBFdmFuIEdpbGJlcnQsCiAgIFlhcm9uIFkuIEdvbGFuZCwgQnJlbnQgR29sZG1hbiwgS3Jpc3Rv ZmZlciBHcm9ub3dza2ksIEp1c3RpbiBIYXJ0LAogICBEaWNrIEhhcmR0LCBDcmFpZyBIZWF0aCwg UGhpbCBIdW50LCBNaWNoYWVsIEIuIEpvbmVzLCBUZXJyeSBKb25lcywKICAgSm9obiBLZW1wLCBN YXJrIEtlbnQsIFJhZmZpIEtyaWtvcmlhbiwgQ2hhc2VuIExlIEhhcmEsIFJhc211cwogICBMZXJk b3JmLCBUb3JzdGVuIExvZGRlcnN0ZWR0LCBIdWktTGFuIEx1LCBDYXNleSBMdWNhcywgUGF1bCBN YWRzZW4sCgoKCkhhbW1lciwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgRGVjZW1iZXIgNCwgMjAx MiAgICAgICAgICAgICAgIFtQYWdlIDY5XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAg ICAgT0F1dGggMi4wICAgICAgICAgICAgICAgICAgICAgIEp1bmUgMjAxMgoKCiAgIEFsYXN0YWly IE1haXIsIEV2ZSBNYWxlciwgSmFtZXMgTWFuZ2VyLCBNYXJrIE1jR2xvaW4sIExhdXJlbmNlIE1p YW8sCiAgIFdpbGxpYW0gTWlsbHMsIENodWNrIE1vcnRpbW9yZSwgQW50aG9ueSBOYWRhbGluLCBK dWxpYW4gUmVzY2hrZSwKICAgSnVzdGluIFJpY2hlciwgUGV0ZXIgU2FpbnQtQW5kcmUsIE5hdCBT YWtpbXVyYSwgUm9iIFNheXJlLCBNYXJpdXMKICAgU2N1cnRlc2N1LCBOYWl0aWsgU2hhaCwgTHVr ZSBTaGVwYXJkLCBWbGFkIFNrdm9ydHNvdiwgSnVzdGluIFNtaXRoLAogICBIYWliaW4gU29uZywg Tml2IFN0ZWluZ2FydGVuLCBDaHJpc3RpYW4gU3R1Ym5lciwgSmVyZW15IFN1cmllbCwgUGF1bAog ICBUYXJqYW4sIENocmlzdG9waGVyIFRob21hcywgSGVucnkgUy4gVGhvbXBzb24sIEFsbGVuIFRv bSwgRnJhbmtsaW4KICAgVHNlLCBOaWNrIFdhbGtlciwgU2hhbmUgV2VlZGVuLCBhbmQgU2t5bGFy IFdvb2R3YXJkLgoKICAgVGhpcyBkb2N1bWVudCB3YXMgcHJvZHVjZWQgdW5kZXIgdGhlIGNoYWly bWFuc2hpcCBvZiBCbGFpbmUgQ29vaywKICAgUGV0ZXIgU2FpbnQtQW5kcmUsIEhhbm5lcyBUc2No b2ZlbmlnLCBCYXJyeSBMZWliYSwgYW5kIERlcmVrIEF0a2lucy4KICAgVGhlIGFyZWEgZGlyZWN0 b3JzIGluY2x1ZGVkIExpc2EgRHVzc2VhdWx0LCBQZXRlciBTYWludC1BbmRyZSwgYW5kCiAgIFN0 ZXBoZW4gRmFycmVsbC4KCgpBcHBlbmRpeCBDLiAgRWRpdG9yJ3MgTm90ZXMKCiAgIFdoaWxlIG1h bnkgcGVvcGxlIGNvbnRyaWJ1dGVkIHRvIHRoaXMgc3BlY2lmaWNhdGlvbiB0aHJvdWdob3V0IGl0 cwogICBsb25nIGpvdXJuZXksIHRoZSBlZGl0b3Igd291bGQgbGlrZSB0byBhY2tub3dsZWRnZSBh bmQgdGhhbmsgYSBmZXcKICAgaW5kaXZpZHVhbHMgZm9yIHRoZWlyIG91dHN0YW5kaW5nIGFuZCBp bnZhbHVhYmxlIGVmZm9ydHMgbGVhZGluZyB1cAogICB0byB0aGUgcHVibGljYXRpb24gb2YgdGhp cyBzcGVjaWZpY2F0aW9uLgoKICAgRGF2aWQgUmVjb3Jkb24gZm9yIGNvbnRpbnVvdXNseSBiZWlu ZyBvbmUgb2YgT0F1dGgncyBtb3N0IHZhbHVhYmxlCiAgIGFzc2V0cywgYnJpbmdpbmcgcHJhZ21h dGlzbSBhbmQgdXJnZW5jeSB0byB0aGUgd29yaywgYW5kIGhlbHBpbmcKICAgc2hhcGUgaXQgZnJv bSBpdHMgdmVyeSBiZWdpbm5pbmcsIGFzIHdlbGwgYXMgYmVpbmcgb25lIG9mIHRoZSBiZXN0CiAg IGNvbGxhYm9yYXRvcnMgSSBoYWQgdGhlIHBsZWFzdXJlIG9mIHdvcmtpbmcgd2l0aC4KCiAgIEph bWVzIE1hbmdlciBmb3IgaGlzIGNyZWF0aXZlIGlkZWFzIGFuZCBhbHdheXMgaW5zaWdodGZ1bCBm ZWVkYmFjay4KICAgQnJpYW4gQ2FtcGJlbGwsIFRvcnN0ZW4gTG9kZGVyc3RlZHQsIENodWNrIE1v cnRpbW9yZSwgSnVzdGluIFJpY2hlciwKICAgTWFyaXVzIFNjdXJ0ZXNjdSwgYW5kIEx1a2UgU2hl cGFyZCBmb3IgdGhlaXIgY29udGludWVkIHBhcnRpY2lwYXRpb24KICAgYW5kIHZhbHVhYmxlIGZl ZWRiYWNrLgoKICAgU3BlY2lhbCB0aGFua3MgZ29lcyB0byBNaWtlIEN1cnRpcyBhbmQgWWFob28h IGZvciB0aGVpciB1bmNvbmRpdGlvbmFsCiAgIHN1cHBvcnQgb2YgdGhpcyB3b3JrIGZvciBvdmVy IHRocmVlIHllYXJzLgoKCkF1dGhvcnMnIEFkZHJlc3NlcwoKICAgRXJhbiBIYW1tZXIgKGVkaXRv cikKCiAgIEVtYWlsOiBlcmFuQGh1ZW5pdmVyc2UuY29tCiAgIFVSSTogICBodHRwOi8vaHVlbml2 ZXJzZS5jb20KCgoKCgoKCgoKCkhhbW1lciwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgRGVjZW1i ZXIgNCwgMjAxMiAgICAgICAgICAgICAgIFtQYWdlIDcwXQoMCkludGVybmV0LURyYWZ0ICAgICAg ICAgICAgICAgICAgT0F1dGggMi4wICAgICAgICAgICAgICAgICAgICAgIEp1bmUgMjAxMgoKCiAg IERhdmlkIFJlY29yZG9uCiAgIEZhY2Vib29rCgogICBFbWFpbDogZHJAZmIuY29tCiAgIFVSSTog ICBodHRwOi8vd3d3LmRhdmlkcmVjb3Jkb24uY29tLwoKCiAgIERpY2sgSGFyZHQKICAgTWljcm9z b2Z0CgogICBFbWFpbDogZGljay5oYXJkdEBnbWFpbC5jb20KICAgVVJJOiAgIGh0dHA6Ly9kaWNr aGFyZHQub3JnLwoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgpIYW1tZXIs IGV0IGFsLiAgICAgICAgICBFeHBpcmVzIERlY2VtYmVyIDQsIDIwMTIgICAgICAgICAgICAgICBb UGFnZSA3MV0KDAo= --_004_4E1F6AAD24975D4BA5B16804296739436652630DTK5EX14MBXC284r_ Content-Type: text/html; name="draft-ietf-oauth-v2-26+mbj-3.html" Content-Description: draft-ietf-oauth-v2-26+mbj-3.html Content-Disposition: attachment; filename="draft-ietf-oauth-v2-26+mbj-3.html"; size=255936; creation-date="Sat, 02 Jun 2012 06:32:13 GMT"; modification-date="Sat, 02 Jun 2012 06:32:13 GMT" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMDEgVHJhbnNpdGlvbmFs Ly9FTiIgImh0dHA6Ly93d3cudzMub3JnL1RSL2h0bWw0L2xvb3NlLmR0ZCI+CjxodG1sIGxhbmc9 ImVuIj48aGVhZD48dGl0bGU+VGhlIE9BdXRoIDIuMCBBdXRob3JpemF0aW9uIEZyYW1ld29yazwv dGl0bGU+CjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9odG1s OyBjaGFyc2V0PXV0Zi04Ij4KPG1ldGEgbmFtZT0iZGVzY3JpcHRpb24iIGNvbnRlbnQ9IlRoZSBP QXV0aCAyLjAgQXV0aG9yaXphdGlvbiBGcmFtZXdvcmsiPgo8bWV0YSBuYW1lPSJnZW5lcmF0b3Ii IGNvbnRlbnQ9InhtbDJyZmMgdjEuMzYgKGh0dHA6Ly94bWwucmVzb3VyY2Uub3JnLykiPgo8c3R5 bGUgdHlwZT0ndGV4dC9jc3MnPjwhLS0KICAgICAgICBib2R5IHsKICAgICAgICAgICAgICAgIGZv bnQtZmFtaWx5OiB2ZXJkYW5hLCBjaGFyY29hbCwgaGVsdmV0aWNhLCBhcmlhbCwgc2Fucy1zZXJp ZjsKICAgICAgICAgICAgICAgIGZvbnQtc2l6ZTogc21hbGw7IGNvbG9yOiAjMDAwOyBiYWNrZ3Jv dW5kLWNvbG9yOiAjRkZGOwogICAgICAgICAgICAgICAgbWFyZ2luOiAyZW07CiAgICAgICAgfQog ICAgICAgIGgxLCBoMiwgaDMsIGg0LCBoNSwgaDYgewogICAgICAgICAgICAgICAgZm9udC1mYW1p bHk6IGhlbHZldGljYSwgbW9uYWNvLCAiTVMgU2FucyBTZXJpZiIsIGFyaWFsLCBzYW5zLXNlcmlm OwogICAgICAgICAgICAgICAgZm9udC13ZWlnaHQ6IGJvbGQ7IGZvbnQtc3R5bGU6IG5vcm1hbDsK ICAgICAgICB9CiAgICAgICAgaDEgeyBjb2xvcjogIzkwMDsgYmFja2dyb3VuZC1jb2xvcjogdHJh bnNwYXJlbnQ7IHRleHQtYWxpZ246IHJpZ2h0OyB9CiAgICAgICAgaDMgeyBjb2xvcjogIzMzMzsg YmFja2dyb3VuZC1jb2xvcjogdHJhbnNwYXJlbnQ7IH0KCiAgICAgICAgdGQuUkZDYnVnIHsKICAg ICAgICAgICAgICAgIGZvbnQtc2l6ZTogeC1zbWFsbDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOwog ICAgICAgICAgICAgICAgd2lkdGg6IDMwcHg7IGhlaWdodDogMzBweDsgcGFkZGluZy10b3A6IDJw eDsKICAgICAgICAgICAgICAgIHRleHQtYWxpZ246IGp1c3RpZnk7IHZlcnRpY2FsLWFsaWduOiBt aWRkbGU7CiAgICAgICAgICAgICAgICBiYWNrZ3JvdW5kLWNvbG9yOiAjMDAwOwogICAgICAgIH0K ICAgICAgICB0ZC5SRkNidWcgc3Bhbi5SRkMgewogICAgICAgICAgICAgICAgZm9udC1mYW1pbHk6 IG1vbmFjbywgY2hhcmNvYWwsIGdlbmV2YSwgIk1TIFNhbnMgU2VyaWYiLCBoZWx2ZXRpY2EsIHZl cmRhbmEsIHNhbnMtc2VyaWY7CiAgICAgICAgICAgICAgICBmb250LXdlaWdodDogYm9sZDsgY29s b3I6ICM2NjY7CiAgICAgICAgfQogICAgICAgIHRkLlJGQ2J1ZyBzcGFuLmhvdFRleHQgewogICAg ICAgICAgICAgICAgZm9udC1mYW1pbHk6IGNoYXJjb2FsLCBtb25hY28sIGdlbmV2YSwgIk1TIFNh bnMgU2VyaWYiLCBoZWx2ZXRpY2EsIHZlcmRhbmEsIHNhbnMtc2VyaWY7CiAgICAgICAgICAgICAg ICBmb250LXdlaWdodDogbm9ybWFsOyB0ZXh0LWFsaWduOiBjZW50ZXI7IGNvbG9yOiAjRkZGOwog ICAgICAgIH0KCiAgICAgICAgdGFibGUuVE9DYnVnIHsgd2lkdGg6IDMwcHg7IGhlaWdodDogMTVw eDsgfQogICAgICAgIHRkLlRPQ2J1ZyB7CiAgICAgICAgICAgICAgICB0ZXh0LWFsaWduOiBjZW50 ZXI7IHdpZHRoOiAzMHB4OyBoZWlnaHQ6IDE1cHg7CiAgICAgICAgICAgICAgICBjb2xvcjogI0ZG RjsgYmFja2dyb3VuZC1jb2xvcjogIzkwMDsKICAgICAgICB9CiAgICAgICAgdGQuVE9DYnVnIGEg ewogICAgICAgICAgICAgICAgZm9udC1mYW1pbHk6IG1vbmFjbywgY2hhcmNvYWwsIGdlbmV2YSwg Ik1TIFNhbnMgU2VyaWYiLCBoZWx2ZXRpY2EsIHNhbnMtc2VyaWY7CiAgICAgICAgICAgICAgICBm b250LXdlaWdodDogYm9sZDsgZm9udC1zaXplOiB4LXNtYWxsOyB0ZXh0LWRlY29yYXRpb246IG5v bmU7CiAgICAgICAgICAgICAgICBjb2xvcjogI0ZGRjsgYmFja2dyb3VuZC1jb2xvcjogdHJhbnNw YXJlbnQ7CiAgICAgICAgfQoKICAgICAgICB0ZC5oZWFkZXIgewogICAgICAgICAgICAgICAgZm9u dC1mYW1pbHk6IGFyaWFsLCBoZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogeC1zbWFs bDsKICAgICAgICAgICAgICAgIHZlcnRpY2FsLWFsaWduOiB0b3A7IHdpZHRoOiAzMyU7CiAgICAg ICAgICAgICAgICBjb2xvcjogI0ZGRjsgYmFja2dyb3VuZC1jb2xvcjogIzY2NjsKICAgICAgICB9 CiAgICAgICAgdGQuYXV0aG9yIHsgZm9udC13ZWlnaHQ6IGJvbGQ7IGZvbnQtc2l6ZTogeC1zbWFs bDsgbWFyZ2luLWxlZnQ6IDRlbTsgfQogICAgICAgIHRkLmF1dGhvci10ZXh0IHsgZm9udC1zaXpl OiB4LXNtYWxsOyB9CgogICAgICAgIC8qIGluZm8gY29kZSBmcm9tIFNhbnRhS2xhdXNzIGF0IGh0 dHA6Ly93d3cubWFkYWJvdXRzdHlsZS5jb20vdG9vbHRpcDIuaHRtbCAqLwogICAgICAgIGEuaW5m byB7CiAgICAgICAgICAgICAgICAvKiBUaGlzIGlzIHRoZSBrZXkuICovCiAgICAgICAgICAgICAg ICBwb3NpdGlvbjogcmVsYXRpdmU7CiAgICAgICAgICAgICAgICB6LWluZGV4OiAyNDsKICAgICAg ICAgICAgICAgIHRleHQtZGVjb3JhdGlvbjogbm9uZTsKICAgICAgICB9CiAgICAgICAgYS5pbmZv OmhvdmVyIHsKICAgICAgICAgICAgICAgIHotaW5kZXg6IDI1OwogICAgICAgICAgICAgICAgY29s b3I6ICNGRkY7IGJhY2tncm91bmQtY29sb3I6ICM5MDA7CiAgICAgICAgfQogICAgICAgIGEuaW5m byBzcGFuIHsgZGlzcGxheTogbm9uZTsgfQogICAgICAgIGEuaW5mbzpob3ZlciBzcGFuLmluZm8g ewogICAgICAgICAgICAgICAgLyogVGhlIHNwYW4gd2lsbCBkaXNwbGF5IGp1c3Qgb24gOmhvdmVy IHN0YXRlLiAqLwogICAgICAgICAgICAgICAgZGlzcGxheTogYmxvY2s7CiAgICAgICAgICAgICAg ICBwb3NpdGlvbjogYWJzb2x1dGU7CiAgICAgICAgICAgICAgICBmb250LXNpemU6IHNtYWxsZXI7 CiAgICAgICAgICAgICAgICB0b3A6IDJlbTsgbGVmdDogLTVlbTsgd2lkdGg6IDE1ZW07CiAgICAg ICAgICAgICAgICBwYWRkaW5nOiAycHg7IGJvcmRlcjogMXB4IHNvbGlkICMzMzM7CiAgICAgICAg ICAgICAgICBjb2xvcjogIzkwMDsgYmFja2dyb3VuZC1jb2xvcjogI0VFRTsKICAgICAgICAgICAg ICAgIHRleHQtYWxpZ246IGxlZnQ7CiAgICAgICAgfQoKICAgICAgICBhIHsgZm9udC13ZWlnaHQ6 IGJvbGQ7IH0KICAgICAgICBhOmxpbmsgICAgeyBjb2xvcjogIzkwMDsgYmFja2dyb3VuZC1jb2xv cjogdHJhbnNwYXJlbnQ7IH0KICAgICAgICBhOnZpc2l0ZWQgeyBjb2xvcjogIzYzMzsgYmFja2dy b3VuZC1jb2xvcjogdHJhbnNwYXJlbnQ7IH0KICAgICAgICBhOmFjdGl2ZSAgeyBjb2xvcjogIzYz MzsgYmFja2dyb3VuZC1jb2xvcjogdHJhbnNwYXJlbnQ7IH0KCiAgICAgICAgcCB7IG1hcmdpbi1s ZWZ0OiAyZW07IG1hcmdpbi1yaWdodDogMmVtOyB9CiAgICAgICAgcC5jb3B5cmlnaHQgeyBmb250 LXNpemU6IHgtc21hbGw7IH0KICAgICAgICBwLnRvYyB7IGZvbnQtc2l6ZTogc21hbGw7IGZvbnQt d2VpZ2h0OiBib2xkOyBtYXJnaW4tbGVmdDogM2VtOyB9CiAgICAgICAgdGFibGUudG9jIHsgbWFy Z2luOiAwIDAgMCAzZW07IHBhZGRpbmc6IDA7IGJvcmRlcjogMDsgdmVydGljYWwtYWxpZ246IHRl eHQtdG9wOyB9CiAgICAgICAgdGQudG9jIHsgZm9udC1zaXplOiBzbWFsbDsgZm9udC13ZWlnaHQ6 IGJvbGQ7IHZlcnRpY2FsLWFsaWduOiB0ZXh0LXRvcDsgfQoKICAgICAgICBvbC50ZXh0IHsgbWFy Z2luLWxlZnQ6IDJlbTsgbWFyZ2luLXJpZ2h0OiAyZW07IH0KICAgICAgICB1bC50ZXh0IHsgbWFy Z2luLWxlZnQ6IDJlbTsgbWFyZ2luLXJpZ2h0OiAyZW07IH0KICAgICAgICBsaSAgICAgIHsgbWFy Z2luLWxlZnQ6IDNlbTsgfQoKICAgICAgICAvKiBSRkMtMjYyOSA8c3Bhbng+cyBhbmQgPGFydHdv cms+cy4gKi8KICAgICAgICBlbSAgICAgeyBmb250LXN0eWxlOiBpdGFsaWM7IH0KICAgICAgICBz dHJvbmcgeyBmb250LXdlaWdodDogYm9sZDsgfQogICAgICAgIGRmbiAgICB7IGZvbnQtd2VpZ2h0 OiBib2xkOyBmb250LXN0eWxlOiBub3JtYWw7IH0KICAgICAgICBjaXRlICAgeyBmb250LXdlaWdo dDogbm9ybWFsOyBmb250LXN0eWxlOiBub3JtYWw7IH0KICAgICAgICB0dCAgICAgeyBjb2xvcjog IzAzNjsgfQogICAgICAgIHR0LCBwcmUsIHByZSBkZm4sIHByZSBlbSwgcHJlIGNpdGUsIHByZSBz cGFuIHsKICAgICAgICAgICAgICAgIGZvbnQtZmFtaWx5OiAiQ291cmllciBOZXciLCBDb3VyaWVy LCBtb25vc3BhY2U7IGZvbnQtc2l6ZTogc21hbGw7CiAgICAgICAgfQogICAgICAgIHByZSB7CiAg ICAgICAgICAgICAgICB0ZXh0LWFsaWduOiBsZWZ0OyBwYWRkaW5nOiA0cHg7CiAgICAgICAgICAg ICAgICBjb2xvcjogIzAwMDsgYmFja2dyb3VuZC1jb2xvcjogI0NDQzsKICAgICAgICB9CiAgICAg ICAgcHJlIGRmbiAgeyBjb2xvcjogIzkwMDsgfQogICAgICAgIHByZSBlbSAgIHsgY29sb3I6ICM2 NkY7IGJhY2tncm91bmQtY29sb3I6ICNGRkM7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IH0KICAgICAg ICBwcmUgLmtleSB7IGNvbG9yOiAjMzNDOyBmb250LXdlaWdodDogYm9sZDsgfQogICAgICAgIHBy ZSAuaWQgIHsgY29sb3I6ICM5MDA7IH0KICAgICAgICBwcmUgLnN0ciB7IGNvbG9yOiAjMDAwOyBi YWNrZ3JvdW5kLWNvbG9yOiAjQ0ZGOyB9CiAgICAgICAgcHJlIC52YWwgeyBjb2xvcjogIzA2Njsg fQogICAgICAgIHByZSAucmVwIHsgY29sb3I6ICM5MDk7IH0KICAgICAgICBwcmUgLm90aCB7IGNv bG9yOiAjMDAwOyBiYWNrZ3JvdW5kLWNvbG9yOiAjRkNGOyB9CiAgICAgICAgcHJlIC5lcnIgeyBi YWNrZ3JvdW5kLWNvbG9yOiAjRkNDOyB9CgogICAgICAgIC8qIFJGQy0yNjI5IDx0ZXh0dGFibGU+ cy4gKi8KICAgICAgICB0YWJsZS5hbGwsIHRhYmxlLmZ1bGwsIHRhYmxlLmhlYWRlcnMsIHRhYmxl Lm5vbmUgewogICAgICAgICAgICAgICAgZm9udC1zaXplOiBzbWFsbDsgdGV4dC1hbGlnbjogY2Vu dGVyOyBib3JkZXItd2lkdGg6IDJweDsKICAgICAgICAgICAgICAgIHZlcnRpY2FsLWFsaWduOiB0 b3A7IGJvcmRlci1jb2xsYXBzZTogY29sbGFwc2U7CiAgICAgICAgfQogICAgICAgIHRhYmxlLmFs bCwgdGFibGUuZnVsbCB7IGJvcmRlci1zdHlsZTogc29saWQ7IGJvcmRlci1jb2xvcjogYmxhY2s7 IH0KICAgICAgICB0YWJsZS5oZWFkZXJzLCB0YWJsZS5ub25lIHsgYm9yZGVyLXN0eWxlOiBub25l OyB9CiAgICAgICAgdGggewogICAgICAgICAgICAgICAgZm9udC13ZWlnaHQ6IGJvbGQ7IGJvcmRl ci1jb2xvcjogYmxhY2s7CiAgICAgICAgICAgICAgICBib3JkZXItd2lkdGg6IDJweCAycHggM3B4 IDJweDsKICAgICAgICB9CiAgICAgICAgdGFibGUuYWxsIHRoLCB0YWJsZS5mdWxsIHRoIHsgYm9y ZGVyLXN0eWxlOiBzb2xpZDsgfQogICAgICAgIHRhYmxlLmhlYWRlcnMgdGggeyBib3JkZXItc3R5 bGU6IG5vbmUgbm9uZSBzb2xpZCBub25lOyB9CiAgICAgICAgdGFibGUubm9uZSB0aCB7IGJvcmRl ci1zdHlsZTogbm9uZTsgfQogICAgICAgIHRhYmxlLmFsbCB0ZCB7CiAgICAgICAgICAgICAgICBi b3JkZXItc3R5bGU6IHNvbGlkOyBib3JkZXItY29sb3I6ICMzMzM7CiAgICAgICAgICAgICAgICBi b3JkZXItd2lkdGg6IDFweCAycHg7CiAgICAgICAgfQogICAgICAgIHRhYmxlLmZ1bGwgdGQsIHRh YmxlLmhlYWRlcnMgdGQsIHRhYmxlLm5vbmUgdGQgeyBib3JkZXItc3R5bGU6IG5vbmU7IH0KCiAg ICAgICAgaHIgeyBoZWlnaHQ6IDFweDsgfQogICAgICAgIGhyLmluc2VydCB7CiAgICAgICAgICAg ICAgICB3aWR0aDogODAlOyBib3JkZXItc3R5bGU6IG5vbmU7IGJvcmRlci13aWR0aDogMDsKICAg ICAgICAgICAgICAgIGNvbG9yOiAjQ0NDOyBiYWNrZ3JvdW5kLWNvbG9yOiAjQ0NDOwogICAgICAg IH0KLS0+PC9zdHlsZT4KPC9oZWFkPgo8Ym9keT4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2Vs bHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQi Pjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9h PjwvdGQ+PC90cj48L3RhYmxlPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiB3aWR0aD0iNjYlIiBi b3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMCI+PHRyPjx0ZD48dGFibGUg c3VtbWFyeT0ibGF5b3V0IiB3aWR0aD0iMTAwJSIgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMiIg Y2VsbHNwYWNpbmc9IjEiPgo8dHI+PHRkIGNsYXNzPSJoZWFkZXIiPk9BdXRoIFdvcmtpbmcgR3Jv dXA8L3RkPjx0ZCBjbGFzcz0iaGVhZGVyIj5FLiBIYW1tZXIsIEVkLjwvdGQ+PC90cj4KPHRyPjx0 ZCBjbGFzcz0iaGVhZGVyIj5JbnRlcm5ldC1EcmFmdDwvdGQ+PHRkIGNsYXNzPSJoZWFkZXIiPiZu YnNwOzwvdGQ+PC90cj4KPHRyPjx0ZCBjbGFzcz0iaGVhZGVyIj5PYnNvbGV0ZXM6IDxhIGhyZWY9 J2h0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzU4NDknPjU4NDk8L2E+IChpZiZuYnNwO2Fw cHJvdmVkKTwvdGQ+PHRkIGNsYXNzPSJoZWFkZXIiPkQuIFJlY29yZG9uPC90ZD48L3RyPgo8dHI+ PHRkIGNsYXNzPSJoZWFkZXIiPkludGVuZGVkIHN0YXR1czogU3RhbmRhcmRzIFRyYWNrPC90ZD48 dGQgY2xhc3M9ImhlYWRlciI+RmFjZWJvb2s8L3RkPjwvdHI+Cjx0cj48dGQgY2xhc3M9ImhlYWRl ciI+RXhwaXJlczogRGVjZW1iZXIgNCwgMjAxMjwvdGQ+PHRkIGNsYXNzPSJoZWFkZXIiPkQuIEhh cmR0PC90ZD48L3RyPgo8dHI+PHRkIGNsYXNzPSJoZWFkZXIiPiZuYnNwOzwvdGQ+PHRkIGNsYXNz PSJoZWFkZXIiPk1pY3Jvc29mdDwvdGQ+PC90cj4KPHRyPjx0ZCBjbGFzcz0iaGVhZGVyIj4mbmJz cDs8L3RkPjx0ZCBjbGFzcz0iaGVhZGVyIj5KdW5lIDIsIDIwMTI8L3RkPjwvdHI+CjwvdGFibGU+ PC90ZD48L3RyPjwvdGFibGU+CjxoMT48YnIgLz5UaGUgT0F1dGggMi4wIEF1dGhvcml6YXRpb24g RnJhbWV3b3JrPGJyIC8+ZHJhZnQtaWV0Zi1vYXV0aC12Mi0yNzwvaDE+Cgo8aDM+QWJzdHJhY3Q8 L2gzPgoKPHA+CiAgICAgICAgVGhlIE9BdXRoIDIuMCBhdXRob3JpemF0aW9uIGZyYW1ld29yayBl bmFibGVzIGEgdGhpcmQtcGFydHkgYXBwbGljYXRpb24gdG8gb2J0YWluIGxpbWl0ZWQKICAgICAg ICBhY2Nlc3MgdG8gYW4gSFRUUCBzZXJ2aWNlLCBlaXRoZXIgb24gYmVoYWxmIG9mIGEgcmVzb3Vy Y2Ugb3duZXIgYnkgb3JjaGVzdHJhdGluZyBhbiBhcHByb3ZhbAogICAgICAgIGludGVyYWN0aW9u IGJldHdlZW4gdGhlIHJlc291cmNlIG93bmVyIGFuZCB0aGUgSFRUUCBzZXJ2aWNlLCBvciBieSBh bGxvd2luZyB0aGUgdGhpcmQtcGFydHkKICAgICAgICBhcHBsaWNhdGlvbiB0byBvYnRhaW4gYWNj ZXNzIG9uIGl0cyBvd24gYmVoYWxmLiBUaGlzIHNwZWNpZmljYXRpb24gcmVwbGFjZXMgYW5kIG9i c29sZXRlcwogICAgICAgIHRoZSBPQXV0aCAxLjAgcHJvdG9jb2wgZGVzY3JpYmVkIGluIFJGQyA1 ODQ5LgogICAgICAKPC9wPgo8aDM+U3RhdHVzIG9mIHRoaXMgTWVtbzwvaDM+CjxwPgpUaGlzIElu dGVybmV0LURyYWZ0IGlzIHN1Ym1pdHRlZCAgaW4gZnVsbApjb25mb3JtYW5jZSB3aXRoIHRoZSBw cm92aXNpb25zIG9mIEJDUCZuYnNwOzc4IGFuZCBCQ1AmbmJzcDs3OS48L3A+CjxwPgpJbnRlcm5l dC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmlu ZwpUYXNrIEZvcmNlIChJRVRGKS4gIE5vdGUgdGhhdCBvdGhlciBncm91cHMgbWF5IGFsc28gZGlz dHJpYnV0ZQp3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC1EcmFmdHMuICBUaGUgbGlzdCBv ZiBjdXJyZW50CkludGVybmV0LURyYWZ0cyBpcyBhdCBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZHJhZnRzL2N1cnJlbnQvLjwvcD4KPHA+CkludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9j dW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRocwphbmQgbWF5IGJlIHVwZGF0 ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueSB0aW1l LgpJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNl IG1hdGVyaWFsIG9yIHRvIGNpdGUKdGhlbSBvdGhlciB0aGFuIGFzICZsZHF1bzt3b3JrIGluIHBy b2dyZXNzLiZyZHF1bzs8L3A+CjxwPgpUaGlzIEludGVybmV0LURyYWZ0IHdpbGwgZXhwaXJlIG9u IERlY2VtYmVyIDQsIDIwMTIuPC9wPgoKPGgzPkNvcHlyaWdodCBOb3RpY2U8L2gzPgo8cD4KQ29w eXJpZ2h0IChjKSAyMDEyIElFVEYgVHJ1c3QgYW5kIHRoZSBwZXJzb25zIGlkZW50aWZpZWQgYXMg dGhlCmRvY3VtZW50IGF1dGhvcnMuICBBbGwgcmlnaHRzIHJlc2VydmVkLjwvcD4KPHA+ClRoaXMg ZG9jdW1lbnQgaXMgc3ViamVjdCB0byBCQ1AgNzggYW5kIHRoZSBJRVRGIFRydXN0J3MgTGVnYWwK UHJvdmlzaW9ucyBSZWxhdGluZyB0byBJRVRGIERvY3VtZW50cwooaHR0cDovL3RydXN0ZWUuaWV0 Zi5vcmcvbGljZW5zZS1pbmZvKSBpbiBlZmZlY3Qgb24gdGhlIGRhdGUgb2YKcHVibGljYXRpb24g b2YgdGhpcyBkb2N1bWVudC4gIFBsZWFzZSByZXZpZXcgdGhlc2UgZG9jdW1lbnRzCmNhcmVmdWxs eSwgYXMgdGhleSBkZXNjcmliZSB5b3VyIHJpZ2h0cyBhbmQgcmVzdHJpY3Rpb25zIHdpdGggcmVz cGVjdAp0byB0aGlzIGRvY3VtZW50LiBDb2RlIENvbXBvbmVudHMgZXh0cmFjdGVkIGZyb20gdGhp cyBkb2N1bWVudCBtdXN0CmluY2x1ZGUgU2ltcGxpZmllZCBCU0QgTGljZW5zZSB0ZXh0IGFzIGRl c2NyaWJlZCBpbiBTZWN0aW9uIDQuZSBvZgp0aGUgVHJ1c3QgTGVnYWwgUHJvdmlzaW9ucyBhbmQg YXJlIHByb3ZpZGVkIHdpdGhvdXQgd2FycmFudHkgYXMKZGVzY3JpYmVkIGluIHRoZSBTaW1wbGlm aWVkIEJTRCBMaWNlbnNlLjwvcD4KPGEgbmFtZT0idG9jIj48L2E+PGJyIC8+PGhyIC8+CjxoMz5U YWJsZSBvZiBDb250ZW50czwvaDM+CjxwIGNsYXNzPSJ0b2MiPgo8YSBocmVmPSIjYW5jaG9yMSI+ MS48L2E+Jm5ic3A7CkludHJvZHVjdGlvbjxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8 YSBocmVmPSIjYW5jaG9yMiI+MS4xLjwvYT4mbmJzcDsKUm9sZXM8YnIgLz4KJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI2FuY2hvcjMiPjEuMi48L2E+Jm5ic3A7ClByb3RvY29sIEZs b3c8YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI2FuY2hvcjQiPjEuMy48 L2E+Jm5ic3A7CkF1dGhvcml6YXRpb24gR3JhbnQ8YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI2FuY2hvcjUiPjEuMy4xLjwvYT4m bmJzcDsKQXV0aG9yaXphdGlvbiBDb2RlPGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNhbmNob3I2Ij4xLjMuMi48L2E+Jm5ic3A7 CkltcGxpY2l0PGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOzxhIGhyZWY9IiNhbmNob3I3Ij4xLjMuMy48L2E+Jm5ic3A7ClJlc291cmNlIE93bmVy IFBhc3N3b3JkIENyZWRlbnRpYWxzPGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNhbmNob3I4Ij4xLjMuNC48L2E+Jm5ic3A7CkNs aWVudCBDcmVkZW50aWFsczxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIj YW5jaG9yOSI+MS40LjwvYT4mbmJzcDsKQWNjZXNzIFRva2VuPGJyIC8+CiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOzxhIGhyZWY9IiNhbmNob3IxMCI+MS41LjwvYT4mbmJzcDsKUmVmcmVzaCBUb2tl bjxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjdGxzIj4xLjYuPC9hPiZu YnNwOwpUTFMgVmVyc2lvbjxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIj YW5jaG9yMTEiPjEuNy48L2E+Jm5ic3A7CkhUVFAgUmVkaXJlY3Rpb25zPGJyIC8+CiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNhbmNob3IxMiI+MS44LjwvYT4mbmJzcDsKSW50ZXJv cGVyYWJpbGl0eTxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjYW5jaG9y MTMiPjEuOS48L2E+Jm5ic3A7Ck5vdGF0aW9uYWwgQ29udmVudGlvbnM8YnIgLz4KPGEgaHJlZj0i I2FuY2hvcjE0Ij4yLjwvYT4mbmJzcDsKQ2xpZW50IFJlZ2lzdHJhdGlvbjxiciAvPgombmJzcDsm bmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjY2xpZW50LXR5cGVzIj4yLjEuPC9hPiZuYnNwOwpD bGllbnQgVHlwZXM8YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI2NsaWVu dC1pZGVudGlmaWVyIj4yLjIuPC9hPiZuYnNwOwpDbGllbnQgSWRlbnRpZmllcjxiciAvPgombmJz cDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjY2xpZW50LWF1dGhlbnRpY2F0aW9uIj4yLjMu PC9hPiZuYnNwOwpDbGllbnQgQXV0aGVudGljYXRpb248YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI2NsaWVudC1wYXNzd29yZCI+ Mi4zLjEuPC9hPiZuYnNwOwpDbGllbnQgUGFzc3dvcmQ8YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI2FuY2hvcjE1Ij4yLjMuMi48 L2E+Jm5ic3A7Ck90aGVyIEF1dGhlbnRpY2F0aW9uIE1ldGhvZHM8YnIgLz4KJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI2FuY2hvcjE2Ij4yLjQuPC9hPiZuYnNwOwpVbnJlZ2lzdGVy ZWQgQ2xpZW50czxiciAvPgo8YSBocmVmPSIjYW5jaG9yMTciPjMuPC9hPiZuYnNwOwpQcm90b2Nv bCBFbmRwb2ludHM8YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI2FuY2hv cjE4Ij4zLjEuPC9hPiZuYnNwOwpBdXRob3JpemF0aW9uIEVuZHBvaW50PGJyIC8+CiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNyZXNwb25z ZS10eXBlIj4zLjEuMS48L2E+Jm5ic3A7ClJlc3BvbnNlIFR5cGU8YnIgLz4KJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI3JlZGlyZWN0LXVy aSI+My4xLjIuPC9hPiZuYnNwOwpSZWRpcmVjdGlvbiBFbmRwb2ludDxiciAvPgombmJzcDsmbmJz cDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjYW5jaG9yMjQiPjMuMi48L2E+Jm5ic3A7ClRva2VuIEVu ZHBvaW50PGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOzxhIGhyZWY9IiN0b2tlbi1lbmRwb2ludC1hdXRoIj4zLjIuMS48L2E+Jm5ic3A7CkNsaWVu dCBBdXRoZW50aWNhdGlvbjxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIj c2NvcGUiPjMuMy48L2E+Jm5ic3A7CkFjY2VzcyBUb2tlbiBTY29wZTxiciAvPgo8YSBocmVmPSIj YW5jaG9yMjUiPjQuPC9hPiZuYnNwOwpPYnRhaW5pbmcgQXV0aG9yaXphdGlvbjxiciAvPgombmJz cDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjZ3JhbnQtY29kZSI+NC4xLjwvYT4mbmJzcDsK QXV0aG9yaXphdGlvbiBDb2RlIEdyYW50PGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNjb2RlLWF1dGh6LXJlcSI+NC4xLjEuPC9h PiZuYnNwOwpBdXRob3JpemF0aW9uIFJlcXVlc3Q8YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI2NvZGUtYXV0aHotcmVzcCI+NC4x LjIuPC9hPiZuYnNwOwpBdXRob3JpemF0aW9uIFJlc3BvbnNlPGJyIC8+CiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiN0b2tlbi1yZXEiPjQu MS4zLjwvYT4mbmJzcDsKQWNjZXNzIFRva2VuIFJlcXVlc3Q8YnIgLz4KJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI2FuY2hvcjI2Ij40LjEu NC48L2E+Jm5ic3A7CkFjY2VzcyBUb2tlbiBSZXNwb25zZTxiciAvPgombmJzcDsmbmJzcDsmbmJz cDsmbmJzcDs8YSBocmVmPSIjZ3JhbnQtaW1wbGljaXQiPjQuMi48L2E+Jm5ic3A7CkltcGxpY2l0 IEdyYW50PGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOzxhIGhyZWY9IiNpbXBsaWNpdC1hdXRoei1yZXEiPjQuMi4xLjwvYT4mbmJzcDsKQXV0aG9y aXphdGlvbiBSZXF1ZXN0PGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNpbXBsaWNpdC1hdXRoei1yZXNwIj40LjIuMi48L2E+Jm5i c3A7CkFjY2VzcyBUb2tlbiBSZXNwb25zZTxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8 YSBocmVmPSIjZ3JhbnQtcGFzc3dvcmQiPjQuMy48L2E+Jm5ic3A7ClJlc291cmNlIE93bmVyIFBh c3N3b3JkIENyZWRlbnRpYWxzIEdyYW50PGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNhbmNob3IyNyI+NC4zLjEuPC9hPiZuYnNw OwpBdXRob3JpemF0aW9uIFJlcXVlc3QgYW5kIFJlc3BvbnNlPGJyIC8+CiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNwYXNzd29yZC10b2st cmVxIj40LjMuMi48L2E+Jm5ic3A7CkFjY2VzcyBUb2tlbiBSZXF1ZXN0PGJyIC8+CiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNhbmNob3Iy OCI+NC4zLjMuPC9hPiZuYnNwOwpBY2Nlc3MgVG9rZW4gUmVzcG9uc2U8YnIgLz4KJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI2dyYW50LWNsaWVudCI+NC40LjwvYT4mbmJzcDsKQ2xp ZW50IENyZWRlbnRpYWxzIEdyYW50PGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNjbGllbnQtcmVxLXJlc3AiPjQuNC4xLjwvYT4m bmJzcDsKQXV0aG9yaXphdGlvbiBSZXF1ZXN0IGFuZCBSZXNwb25zZTxiciAvPgombmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjYW5jaG9yMjki PjQuNC4yLjwvYT4mbmJzcDsKQWNjZXNzIFRva2VuIFJlcXVlc3Q8YnIgLz4KJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI2FuY2hvcjMwIj40 LjQuMy48L2E+Jm5ic3A7CkFjY2VzcyBUb2tlbiBSZXNwb25zZTxiciAvPgombmJzcDsmbmJzcDsm bmJzcDsmbmJzcDs8YSBocmVmPSIjZXh0LWdyYW50Ij40LjUuPC9hPiZuYnNwOwpFeHRlbnNpb24g R3JhbnRzPGJyIC8+CjxhIGhyZWY9IiN0b2tlbi1pc3N1ZSI+NS48L2E+Jm5ic3A7Cklzc3Vpbmcg YW4gQWNjZXNzIFRva2VuPGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiN0 b2tlbi1yZXNwb25zZSI+NS4xLjwvYT4mbmJzcDsKU3VjY2Vzc2Z1bCBSZXNwb25zZTxiciAvPgom bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjdG9rZW4tZXJyb3JzIj41LjIuPC9hPiZu YnNwOwpFcnJvciBSZXNwb25zZTxiciAvPgo8YSBocmVmPSIjdG9rZW4tcmVmcmVzaCI+Ni48L2E+ Jm5ic3A7ClJlZnJlc2hpbmcgYW4gQWNjZXNzIFRva2VuPGJyIC8+CjxhIGhyZWY9IiNhY2Nlc3Mt cmVzb3VyY2UiPjcuPC9hPiZuYnNwOwpBY2Nlc3NpbmcgUHJvdGVjdGVkIFJlc291cmNlczxiciAv PgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjdG9rZW4tdHlwZXMiPjcuMS48L2E+ Jm5ic3A7CkFjY2VzcyBUb2tlbiBUeXBlczxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8 YSBocmVmPSIjcmVzb3VyY2UtZXJyb3JzIj43LjIuPC9hPiZuYnNwOwpFcnJvciBSZXNwb25zZTxi ciAvPgo8YSBocmVmPSIjZXh0ZW5zaW9ucyI+OC48L2E+Jm5ic3A7CkV4dGVuc2liaWxpdHk8YnIg Lz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI25ldy10eXBlcyI+OC4xLjwvYT4m bmJzcDsKRGVmaW5pbmcgQWNjZXNzIFRva2VuIFR5cGVzPGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOzxhIGhyZWY9IiNlbmRwb2ludC1wYXJhbXMiPjguMi48L2E+Jm5ic3A7CkRlZmluaW5n IE5ldyBFbmRwb2ludCBQYXJhbWV0ZXJzPGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxh IGhyZWY9IiNhbmNob3IzMSI+OC4zLjwvYT4mbmJzcDsKRGVmaW5pbmcgTmV3IEF1dGhvcml6YXRp b24gR3JhbnQgVHlwZXM8YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI3Jl c3BvbnNlLXR5cGUtZXh0Ij44LjQuPC9hPiZuYnNwOwpEZWZpbmluZyBOZXcgQXV0aG9yaXphdGlv biBFbmRwb2ludCBSZXNwb25zZSBUeXBlczxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8 YSBocmVmPSIjbmV3LWVycm9ycyI+OC41LjwvYT4mbmJzcDsKRGVmaW5pbmcgQWRkaXRpb25hbCBF cnJvciBDb2RlczxiciAvPgo8YSBocmVmPSIjYW5jaG9yMzIiPjkuPC9hPiZuYnNwOwpOYXRpdmUg QXBwbGljYXRpb25zPGJyIC8+CjxhIGhyZWY9IiNhbmNob3IzMyI+MTAuPC9hPiZuYnNwOwpTZWN1 cml0eSBDb25zaWRlcmF0aW9uczxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVm PSIjYW5jaG9yMzQiPjEwLjEuPC9hPiZuYnNwOwpDbGllbnQgQXV0aGVudGljYXRpb248YnIgLz4K Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI2FuY2hvcjM1Ij4xMC4yLjwvYT4mbmJz cDsKQ2xpZW50IEltcGVyc29uYXRpb248YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEg aHJlZj0iI2FuY2hvcjM2Ij4xMC4zLjwvYT4mbmJzcDsKQWNjZXNzIFRva2VuczxiciAvPgombmJz cDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjYW5jaG9yMzciPjEwLjQuPC9hPiZuYnNwOwpS ZWZyZXNoIFRva2VuczxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjYW5j aG9yMzgiPjEwLjUuPC9hPiZuYnNwOwpBdXRob3JpemF0aW9uIENvZGVzPGJyIC8+CiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNhbmNob3IzOSI+MTAuNi48L2E+Jm5ic3A7CkF1dGhv cml6YXRpb24gQ29kZSBSZWRpcmVjdGlvbiBVUkkgTWFuaXB1bGF0aW9uPGJyIC8+CiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNhbmNob3I0MCI+MTAuNy48L2E+Jm5ic3A7ClJlc291 cmNlIE93bmVyIFBhc3N3b3JkIENyZWRlbnRpYWxzPGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOzxhIGhyZWY9IiNhbmNob3I0MSI+MTAuOC48L2E+Jm5ic3A7ClJlcXVlc3QgQ29uZmlkZW50 aWFsaXR5PGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNhbmNob3I0MiI+ MTAuOS48L2E+Jm5ic3A7CkVuZHBvaW50cyBBdXRoZW50aWNpdHk8YnIgLz4KJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI2FudGhyb3B5Ij4xMC4xMC48L2E+Jm5ic3A7CkNyZWRlbnRp YWxzIEd1ZXNzaW5nIEF0dGFja3M8YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJl Zj0iI2FuY2hvcjQzIj4xMC4xMS48L2E+Jm5ic3A7ClBoaXNoaW5nIEF0dGFja3M8YnIgLz4KJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI0NTUkYiPjEwLjEyLjwvYT4mbmJzcDsKQ3Jv c3MtU2l0ZSBSZXF1ZXN0IEZvcmdlcnk8YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEg aHJlZj0iI2FuY2hvcjQ0Ij4xMC4xMy48L2E+Jm5ic3A7CkNsaWNramFja2luZzxiciAvPgombmJz cDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjYW5jaG9yNDUiPjEwLjE0LjwvYT4mbmJzcDsK Q29kZSBJbmplY3Rpb24gYW5kIElucHV0IFZhbGlkYXRpb248YnIgLz4KJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7PGEgaHJlZj0iI29wZW4tcmVkaXJlY3QiPjEwLjE1LjwvYT4mbmJzcDsKT3BlbiBS ZWRpcmVjdG9yczxiciAvPgo8YSBocmVmPSIjYW5jaG9yNDYiPjExLjwvYT4mbmJzcDsKSUFOQSBD b25zaWRlcmF0aW9uczxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjdHlw ZS1yZWdpc3RyeSI+MTEuMS48L2E+Jm5ic3A7ClRoZSBPQXV0aCBBY2Nlc3MgVG9rZW4gVHlwZSBS ZWdpc3RyeTxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDs8YSBocmVmPSIjYW5jaG9yNDciPjExLjEuMS48L2E+Jm5ic3A7ClJlZ2lzdHJhdGlvbiBU ZW1wbGF0ZTxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjcGFyYW1ldGVy cy1yZWdpc3RyeSI+MTEuMi48L2E+Jm5ic3A7ClRoZSBPQXV0aCBQYXJhbWV0ZXJzIFJlZ2lzdHJ5 PGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxh IGhyZWY9IiNhbmNob3I0OCI+MTEuMi4xLjwvYT4mbmJzcDsKUmVnaXN0cmF0aW9uIFRlbXBsYXRl PGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxh IGhyZWY9IiNhbmNob3I0OSI+MTEuMi4yLjwvYT4mbmJzcDsKSW5pdGlhbCBSZWdpc3RyeSBDb250 ZW50czxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjcmVzcG9uc2UtdHlw ZS1yZWdpc3RyeSI+MTEuMy48L2E+Jm5ic3A7ClRoZSBPQXV0aCBBdXRob3JpemF0aW9uIEVuZHBv aW50IFJlc3BvbnNlIFR5cGUgUmVnaXN0cnk8YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI2FuY2hvcjUwIj4xMS4zLjEuPC9hPiZu YnNwOwpSZWdpc3RyYXRpb24gVGVtcGxhdGU8YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI2FuY2hvcjUxIj4xMS4zLjIuPC9hPiZu YnNwOwpJbml0aWFsIFJlZ2lzdHJ5IENvbnRlbnRzPGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOzxhIGhyZWY9IiNlcnJvci1yZWdpc3RyeSI+MTEuNC48L2E+Jm5ic3A7ClRoZSBPQXV0aCBF eHRlbnNpb25zIEVycm9yIFJlZ2lzdHJ5PGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNhbmNob3I1MiI+MTEuNC4xLjwvYT4mbmJz cDsKUmVnaXN0cmF0aW9uIFRlbXBsYXRlPGJyIC8+CjxhIGhyZWY9IiNyZmMucmVmZXJlbmNlczEi PjEyLjwvYT4mbmJzcDsKUmVmZXJlbmNlczxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8 YSBocmVmPSIjcmZjLnJlZmVyZW5jZXMxIj4xMi4xLjwvYT4mbmJzcDsKTm9ybWF0aXZlIFJlZmVy ZW5jZXM8YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI3JmYy5yZWZlcmVu Y2VzMiI+MTIuMi48L2E+Jm5ic3A7CkluZm9ybWF0aXZlIFJlZmVyZW5jZXM8YnIgLz4KPGEgaHJl Zj0iI2FuY2hvcjU1Ij5BcHBlbmRpeCZuYnNwO0EuPC9hPiZuYnNwOwpBdWdtZW50ZWQgQmFja3Vz LU5hdXIgRm9ybSAoQUJORikgU3ludGF4PGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxh IGhyZWY9IiNhbmNob3I1NiI+QS4xLjwvYT4mbmJzcDsKImNsaWVudF9pZCIgU3ludGF4PGJyIC8+ CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNhbmNob3I1NyI+QS4yLjwvYT4mbmJz cDsKImNsaWVudF9zZWNyZXQiIFN5bnRheDxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8 YSBocmVmPSIjYW5jaG9yNTgiPkEuMy48L2E+Jm5ic3A7CiJyZXNwb25zZV90eXBlIiBTeW50YXg8 YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI2FuY2hvcjU5Ij5BLjQuPC9h PiZuYnNwOwoic2NvcGUiIFN5bnRheDxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBo cmVmPSIjYW5jaG9yNjAiPkEuNS48L2E+Jm5ic3A7CiJzdGF0ZSIgU3ludGF4PGJyIC8+CiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNhbmNob3I2MSI+QS42LjwvYT4mbmJzcDsKInJl ZGlyZWN0X3VyaSIgU3ludGF4PGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9 IiNhbmNob3I2MiI+QS43LjwvYT4mbmJzcDsKImVycm9yIiBTeW50YXg8YnIgLz4KJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI2FuY2hvcjYzIj5BLjguPC9hPiZuYnNwOwoiZXJyb3Jf ZGVzY3JpcHRpb24iIFN5bnRheDxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVm PSIjYW5jaG9yNjQiPkEuOS48L2E+Jm5ic3A7CiJlcnJvcl91cmkiIFN5bnRheDxiciAvPgombmJz cDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjYW5jaG9yNjUiPkEuMTAuPC9hPiZuYnNwOwoi Z3JhbnRfdHlwZSIgU3ludGF4PGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9 IiNhbmNob3I2NiI+QS4xMS48L2E+Jm5ic3A7CiJjb2RlIiBTeW50YXg8YnIgLz4KJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI2FuY2hvcjY3Ij5BLjEyLjwvYT4mbmJzcDsKImFjY2Vz c190b2tlbiIgU3ludGF4PGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNh bmNob3I2OCI+QS4xMy48L2E+Jm5ic3A7CiJ0b2tlbl90eXBlIiBTeW50YXg8YnIgLz4KJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI2FuY2hvcjY5Ij5BLjE0LjwvYT4mbmJzcDsKImV4 cGlyZXNfaW4iIFN5bnRheDxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIj YW5jaG9yNzAiPkEuMTUuPC9hPiZuYnNwOwoidXNlcm5hbWUiIFN5bnRheDxiciAvPgombmJzcDsm bmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjYW5jaG9yNzEiPkEuMTYuPC9hPiZuYnNwOwoicGFz c3dvcmQiIFN5bnRheDxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjYW5j aG9yNzIiPkEuMTcuPC9hPiZuYnNwOwoicmVmcmVzaF90b2tlbiIgU3ludGF4PGJyIC8+CiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNhbmNob3I3MyI+QS4xOC48L2E+Jm5ic3A7CkVu ZHBvaW50IFBhcmFtZXRlciBTeW50YXg8YnIgLz4KPGEgaHJlZj0iI2FuY2hvcjc0Ij5BcHBlbmRp eCZuYnNwO0IuPC9hPiZuYnNwOwpBY2tub3dsZWRnZW1lbnRzPGJyIC8+CjxhIGhyZWY9IiNhbmNo b3I3NSI+QXBwZW5kaXgmbmJzcDtDLjwvYT4mbmJzcDsKRWRpdG9yJ3MgTm90ZXM8YnIgLz4KPGEg aHJlZj0iI3JmYy5hdXRob3JzIj4mIzE2Nzs8L2E+Jm5ic3A7CkF1dGhvcnMnIEFkZHJlc3Nlczxi ciAvPgo8L3A+CjxiciBjbGVhcj0iYWxsIiAvPgoKPGEgbmFtZT0iYW5jaG9yMSI+PC9hPjxiciAv PjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNp bmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVn Ij48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+Cjxh IG5hbWU9InJmYy5zZWN0aW9uLjEiPjwvYT48aDM+MS4mbmJzcDsKSW50cm9kdWN0aW9uPC9oMz4K CjxwPgogICAgICAgIEluIHRoZSB0cmFkaXRpb25hbCBjbGllbnQtc2VydmVyIGF1dGhlbnRpY2F0 aW9uIG1vZGVsLCB0aGUgY2xpZW50IHJlcXVlc3RzIGFuIGFjY2VzcwogICAgICAgIHJlc3RyaWN0 ZWQgcmVzb3VyY2UgKHByb3RlY3RlZCByZXNvdXJjZSkgb24gdGhlIHNlcnZlciBieSBhdXRoZW50 aWNhdGluZyB3aXRoIHRoZSBzZXJ2ZXIKICAgICAgICB1c2luZyB0aGUgcmVzb3VyY2Ugb3duZXIn cyBjcmVkZW50aWFscy4gSW4gb3JkZXIgdG8gcHJvdmlkZSB0aGlyZC1wYXJ0eSBhcHBsaWNhdGlv bnMgYWNjZXNzCiAgICAgICAgdG8gcmVzdHJpY3RlZCByZXNvdXJjZXMsIHRoZSByZXNvdXJjZSBv d25lciBzaGFyZXMgaXRzIGNyZWRlbnRpYWxzIHdpdGggdGhlIHRoaXJkLXBhcnR5LgogICAgICAg IFRoaXMgY3JlYXRlcyBzZXZlcmFsIHByb2JsZW1zIGFuZCBsaW1pdGF0aW9uczoKICAgICAgCjwv cD4KPHA+CiAgICAgICAgPC9wPgo8dWwgY2xhc3M9InRleHQiPgo8bGk+CiAgICAgICAgICAgIFRo aXJkLXBhcnR5IGFwcGxpY2F0aW9ucyBhcmUgcmVxdWlyZWQgdG8gc3RvcmUgdGhlIHJlc291cmNl IG93bmVyJ3MgY3JlZGVudGlhbHMKICAgICAgICAgICAgZm9yIGZ1dHVyZSB1c2UsIHR5cGljYWxs eSBhIHBhc3N3b3JkIGluIGNsZWFyLXRleHQuCiAgICAgICAgICAKPC9saT4KPGxpPgogICAgICAg ICAgICBTZXJ2ZXJzIGFyZSByZXF1aXJlZCB0byBzdXBwb3J0IHBhc3N3b3JkIGF1dGhlbnRpY2F0 aW9uLCBkZXNwaXRlIHRoZSBzZWN1cml0eQogICAgICAgICAgICB3ZWFrbmVzc2VzIGluaGVyZW50 IGluIHBhc3N3b3Jkcy4KICAgICAgICAgIAo8L2xpPgo8bGk+CiAgICAgICAgICAgIFRoaXJkLXBh cnR5IGFwcGxpY2F0aW9ucyBnYWluIG92ZXJseSBicm9hZCBhY2Nlc3MgdG8gdGhlIHJlc291cmNl IG93bmVyJ3MgcHJvdGVjdGVkCiAgICAgICAgICAgIHJlc291cmNlcywgbGVhdmluZyByZXNvdXJj ZSBvd25lcnMgd2l0aG91dCBhbnkgYWJpbGl0eSB0byByZXN0cmljdCBkdXJhdGlvbiBvciBhY2Nl c3MKICAgICAgICAgICAgdG8gYSBsaW1pdGVkIHN1YnNldCBvZiByZXNvdXJjZXMuCiAgICAgICAg ICAKPC9saT4KPGxpPgogICAgICAgICAgICBSZXNvdXJjZSBvd25lcnMgY2Fubm90IHJldm9rZSBh Y2Nlc3MgdG8gYW4gaW5kaXZpZHVhbCB0aGlyZC1wYXJ0eSB3aXRob3V0IHJldm9raW5nCiAgICAg ICAgICAgIGFjY2VzcyB0byBhbGwgdGhpcmQtcGFydGllcywgYW5kIG11c3QgZG8gc28gYnkgY2hh bmdpbmcgdGhlaXIgcGFzc3dvcmQuCiAgICAgICAgICAKPC9saT4KPGxpPgogICAgICAgICAgICBD b21wcm9taXNlIG9mIGFueSB0aGlyZC1wYXJ0eSBhcHBsaWNhdGlvbiByZXN1bHRzIGluIGNvbXBy b21pc2Ugb2YgdGhlIGVuZC11c2VyJ3MKICAgICAgICAgICAgcGFzc3dvcmQgYW5kIGFsbCBvZiB0 aGUgZGF0YSBwcm90ZWN0ZWQgYnkgdGhhdCBwYXNzd29yZC4KICAgICAgICAgIAo8L2xpPgo8L3Vs PjxwPgogICAgICAKPC9wPgo8cD4KICAgICAgICBPQXV0aCBhZGRyZXNzZXMgdGhlc2UgaXNzdWVz IGJ5IGludHJvZHVjaW5nIGFuIGF1dGhvcml6YXRpb24gbGF5ZXIgYW5kIHNlcGFyYXRpbmcgdGhl IHJvbGUKICAgICAgICBvZiB0aGUgY2xpZW50IGZyb20gdGhhdCBvZiB0aGUgcmVzb3VyY2Ugb3du ZXIuIEluIE9BdXRoLCB0aGUgY2xpZW50IHJlcXVlc3RzIGFjY2VzcyB0bwogICAgICAgIHJlc291 cmNlcyBjb250cm9sbGVkIGJ5IHRoZSByZXNvdXJjZSBvd25lciBhbmQgaG9zdGVkIGJ5IHRoZSBy ZXNvdXJjZSBzZXJ2ZXIsIGFuZCBpcyBpc3N1ZWQKICAgICAgICBhIGRpZmZlcmVudCBzZXQgb2Yg Y3JlZGVudGlhbHMgdGhhbiB0aG9zZSBvZiB0aGUgcmVzb3VyY2Ugb3duZXIuCiAgICAgIAo8L3A+ CjxwPgogICAgICAgIEluc3RlYWQgb2YgdXNpbmcgdGhlIHJlc291cmNlIG93bmVyJ3MgY3JlZGVu dGlhbHMgdG8gYWNjZXNzIHByb3RlY3RlZCByZXNvdXJjZXMsIHRoZSBjbGllbnQKICAgICAgICBv YnRhaW5zIGFuIGFjY2VzcyB0b2tlbiAtIGEgc3RyaW5nIGRlbm90aW5nIGEgc3BlY2lmaWMgc2Nv cGUsIGxpZmV0aW1lLCBhbmQgb3RoZXIgYWNjZXNzCiAgICAgICAgYXR0cmlidXRlcy4gQWNjZXNz IHRva2VucyBhcmUgaXNzdWVkIHRvIHRoaXJkLXBhcnR5IGNsaWVudHMgYnkgYW4gYXV0aG9yaXph dGlvbiBzZXJ2ZXIgd2l0aAogICAgICAgIHRoZSBhcHByb3ZhbCBvZiB0aGUgcmVzb3VyY2Ugb3du ZXIuIFRoZSBjbGllbnQgdXNlcyB0aGUgYWNjZXNzIHRva2VuIHRvIGFjY2VzcyB0aGUKICAgICAg ICBwcm90ZWN0ZWQgcmVzb3VyY2VzIGhvc3RlZCBieSB0aGUgcmVzb3VyY2Ugc2VydmVyLgogICAg ICAKPC9wPgo8cD4KICAgICAgICBGb3IgZXhhbXBsZSwgYW4gZW5kLXVzZXIgKHJlc291cmNlIG93 bmVyKSBjYW4gZ3JhbnQgYSBwcmludGluZyBzZXJ2aWNlIChjbGllbnQpIGFjY2VzcwogICAgICAg IHRvIGhlciBwcm90ZWN0ZWQgcGhvdG9zIHN0b3JlZCBhdCBhIHBob3RvIHNoYXJpbmcgc2Vydmlj ZSAocmVzb3VyY2Ugc2VydmVyKSwgd2l0aG91dAogICAgICAgIHNoYXJpbmcgaGVyIHVzZXJuYW1l IGFuZCBwYXNzd29yZCB3aXRoIHRoZSBwcmludGluZyBzZXJ2aWNlLiBJbnN0ZWFkLCBzaGUgYXV0 aGVudGljYXRlcwogICAgICAgIGRpcmVjdGx5IHdpdGggYSBzZXJ2ZXIgdHJ1c3RlZCBieSB0aGUg cGhvdG8gc2hhcmluZyBzZXJ2aWNlIChhdXRob3JpemF0aW9uIHNlcnZlcikgd2hpY2gKICAgICAg ICBpc3N1ZXMgdGhlIHByaW50aW5nIHNlcnZpY2UgZGVsZWdhdGlvbi1zcGVjaWZpYyBjcmVkZW50 aWFscyAoYWNjZXNzIHRva2VuKS4KICAgICAgCjwvcD4KPHA+CiAgICAgICAgVGhpcyBzcGVjaWZp Y2F0aW9uIGlzIGRlc2lnbmVkIGZvciB1c2Ugd2l0aCBIVFRQICg8YSBjbGFzcz0naW5mbycgaHJl Zj0nI1JGQzI2MTYnPltSRkMyNjE2XTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5G aWVsZGluZywgUi4sIEdldHR5cywgSi4sIE1vZ3VsLCBKLiwgRnJ5c3R5aywgSC4sIE1hc2ludGVy LCBMLiwgTGVhY2gsIFAuLCBhbmQgVC4gQmVybmVycy1MZWUsICZsZHF1bztIeXBlcnRleHQgVHJh bnNmZXIgUHJvdG9jb2wgLS0gSFRUUC8xLjEsJnJkcXVvOyBKdW5lJm5ic3A7MTk5OS48L3NwYW4+ PHNwYW4+KTwvc3Bhbj48L2E+KS4gVGhlIHVzZSBvZgogICAgICAgIE9BdXRoIG92ZXIgYW55IG90 aGVyIHByb3RvY29sIHRoYW4gSFRUUCBpcyBvdXQgb2Ygc2NvcGUuCiAgICAgIAo8L3A+CjxwPgog ICAgICAgIFRoZSBPQXV0aCAxLjAgcHJvdG9jb2wgKDxhIGNsYXNzPSdpbmZvJyBocmVmPScjUkZD NTg0OSc+W1JGQzU4NDldPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkhhbW1lci1M YWhhdiwgRS4sICZsZHF1bztUaGUgT0F1dGggMS4wIFByb3RvY29sLCZyZHF1bzsgQXByaWwmbmJz cDsyMDEwLjwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4pLCBwdWJsaXNoZWQgYXMgYW4gaW5mb3Jt YXRpb25hbCBkb2N1bWVudCwKICAgICAgICB3YXMgdGhlIHJlc3VsdCBvZiBhIHNtYWxsIGFkLWhv YyBjb21tdW5pdHkgZWZmb3J0LiBUaGlzIHN0YW5kYXJkcy10cmFjayBzcGVjaWZpY2F0aW9uIGJ1 aWxkcwogICAgICAgIG9uIHRoZSBPQXV0aCAxLjAgZGVwbG95bWVudCBleHBlcmllbmNlLCBhcyB3 ZWxsIGFzIGFkZGl0aW9uYWwgdXNlIGNhc2VzIGFuZCBleHRlbnNpYmlsaXR5CiAgICAgICAgcmVx dWlyZW1lbnRzIGdhdGhlcmVkIGZyb20gdGhlIHdpZGVyIElFVEYgY29tbXVuaXR5LiBUaGUgT0F1 dGggMi4wIHByb3RvY29sIGlzIG5vdCBiYWNrd2FyZAogICAgICAgIGNvbXBhdGlibGUgd2l0aCBP QXV0aCAxLjAuIFRoZSB0d28gdmVyc2lvbnMgbWF5IGNvLWV4aXN0IG9uIHRoZSBuZXR3b3JrIGFu ZCBpbXBsZW1lbnRhdGlvbnMKICAgICAgICBtYXkgY2hvb3NlIHRvIHN1cHBvcnQgYm90aC4gSG93 ZXZlciwgaXQgaXMgdGhlIGludGVudGlvbiBvZiB0aGlzIHNwZWNpZmljYXRpb24gdGhhdCBuZXcK ICAgICAgICBpbXBsZW1lbnRhdGlvbiBzdXBwb3J0IE9BdXRoIDIuMCBhcyBzcGVjaWZpZWQgaW4g dGhpcyBkb2N1bWVudCwgYW5kIHRoYXQgT0F1dGggMS4wIGlzIHVzZWQKICAgICAgICBvbmx5IHRv IHN1cHBvcnQgZXhpc3RpbmcgZGVwbG95bWVudHMuIFRoZSBPQXV0aCAyLjAgcHJvdG9jb2wgc2hh cmVzIHZlcnkgZmV3IGltcGxlbWVudGF0aW9uCiAgICAgICAgZGV0YWlscyB3aXRoIHRoZSBPQXV0 aCAxLjAgcHJvdG9jb2wuIEltcGxlbWVudGVycyBmYW1pbGlhciB3aXRoIE9BdXRoIDEuMCBzaG91 bGQgYXBwcm9hY2gKICAgICAgICB0aGlzIGRvY3VtZW50IHdpdGhvdXQgYW55IGFzc3VtcHRpb25z IGFzIHRvIGl0cyBzdHJ1Y3R1cmUgYW5kIGRldGFpbHMuCiAgICAgIAo8L3A+CjxhIG5hbWU9ImFu Y2hvcjIiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRp bmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48 dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+ PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi4xLjEiPjwvYT48aDM+MS4xLiZuYnNw OwpSb2xlczwvaDM+Cgo8cD4KICAgICAgICAgIE9BdXRoIGRlZmluZXMgZm91ciByb2xlczoKICAg ICAgICAKPC9wPgo8cD4KICAgICAgICAgIDwvcD4KPGJsb2NrcXVvdGUgY2xhc3M9InRleHQiPjxk bD4KPGR0PnJlc291cmNlIG93bmVyPC9kdD4KPGRkPgogICAgICAgICAgICAgIAogICAgICAgICAg ICAgIEFuIGVudGl0eSBjYXBhYmxlIG9mIGdyYW50aW5nIGFjY2VzcyB0byBhIHByb3RlY3RlZCBy ZXNvdXJjZS4gV2hlbiB0aGUgcmVzb3VyY2Ugb3duZXIKICAgICAgICAgICAgICBpcyBhIHBlcnNv biwgaXQgaXMgcmVmZXJyZWQgdG8gYXMgYW4gZW5kLXVzZXIuCiAgICAgICAgICAgIAo8L2RkPgo8 ZHQ+cmVzb3VyY2Ugc2VydmVyPC9kdD4KPGRkPgogICAgICAgICAgICAgIAogICAgICAgICAgICAg IFRoZSBzZXJ2ZXIgaG9zdGluZyB0aGUgcHJvdGVjdGVkIHJlc291cmNlcywgY2FwYWJsZSBvZiBh Y2NlcHRpbmcgYW5kIHJlc3BvbmRpbmcgdG8KICAgICAgICAgICAgICBwcm90ZWN0ZWQgcmVzb3Vy Y2UgcmVxdWVzdHMgdXNpbmcgYWNjZXNzIHRva2Vucy4KICAgICAgICAgICAgCjwvZGQ+CjxkdD5j bGllbnQ8L2R0Pgo8ZGQ+CiAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgQW4gYXBwbGljYXRp b24gbWFraW5nIHByb3RlY3RlZCByZXNvdXJjZSByZXF1ZXN0cyBvbiBiZWhhbGYgb2YgdGhlIHJl c291cmNlIG93bmVyIGFuZAogICAgICAgICAgICAgIHdpdGggaXRzIGF1dGhvcml6YXRpb24uIFRo ZSB0ZXJtIGNsaWVudCBkb2VzIG5vdCBpbXBseSBhbnkgcGFydGljdWxhciBpbXBsZW1lbnRhdGlv bgogICAgICAgICAgICAgIGNoYXJhY3RlcmlzdGljcyAoZS5nLiB3aGV0aGVyIHRoZSBhcHBsaWNh dGlvbiBleGVjdXRlcyBvbiBhIHNlcnZlciwgYSBkZXNrdG9wLCBvcgogICAgICAgICAgICAgIG90 aGVyIGRldmljZXMpLgogICAgICAgICAgICAKPC9kZD4KPGR0PmF1dGhvcml6YXRpb24gc2VydmVy PC9kdD4KPGRkPgogICAgICAgICAgICAgIAogICAgICAgICAgICAgIFRoZSBzZXJ2ZXIgaXNzdWlu ZyBhY2Nlc3MgdG9rZW5zIHRvIHRoZSBjbGllbnQgYWZ0ZXIgc3VjY2Vzc2Z1bGx5IGF1dGhlbnRp Y2F0aW5nIHRoZQogICAgICAgICAgICAgIHJlc291cmNlIG93bmVyIGFuZCBvYnRhaW5pbmcgYXV0 aG9yaXphdGlvbi4KICAgICAgICAgICAgCjwvZGQ+CjwvZGw+PC9ibG9ja3F1b3RlPjxwPgogICAg ICAgIAo8L3A+CjxwPgogICAgICAgICAgVGhlIGludGVyYWN0aW9uIGJldHdlZW4gdGhlIGF1dGhv cml6YXRpb24gc2VydmVyIGFuZCByZXNvdXJjZSBzZXJ2ZXIgaXMgYmV5b25kIHRoZSBzY29wZQog ICAgICAgICAgb2YgdGhpcyBzcGVjaWZpY2F0aW9uLiBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIg bWF5IGJlIHRoZSBzYW1lIHNlcnZlciBhcyB0aGUgcmVzb3VyY2UKICAgICAgICAgIHNlcnZlciBv ciBhIHNlcGFyYXRlIGVudGl0eS4gQSBzaW5nbGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgbWF5IGlz c3VlIGFjY2VzcyB0b2tlbnMKICAgICAgICAgIGFjY2VwdGVkIGJ5IG11bHRpcGxlIHJlc291cmNl IHNlcnZlcnMuCiAgICAgICAgCjwvcD4KPGEgbmFtZT0iYW5jaG9yMyI+PC9hPjxiciAvPjxociAv Pgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIi IGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBo cmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9 InJmYy5zZWN0aW9uLjEuMiI+PC9hPjxoMz4xLjIuJm5ic3A7ClByb3RvY29sIEZsb3c8L2gzPgo8 YnIgLz48aHIgY2xhc3M9Imluc2VydCIgLz4KPGEgbmFtZT0iRmlndXJlLTEiPjwvYT4KPGRpdiBz dHlsZT0nZGlzcGxheTogdGFibGU7IHdpZHRoOiAwOyBtYXJnaW4tbGVmdDogM2VtOyBtYXJnaW4t cmlnaHQ6IGF1dG8nPjxwcmU+CgogICstLS0tLS0tLSsgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgKy0tLS0tLS0tLS0tLS0tLSsKICB8ICAgICAgICB8LS0oQSktIEF1dGhvcml6YXRpb24g UmVxdWVzdCAtJmd0O3wgICBSZXNvdXJjZSAgICB8CiAgfCAgICAgICAgfCAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICB8ICAgICBPd25lciAgICAgfAogIHwgICAgICAgIHwmbHQ7LShCKS0t IEF1dGhvcml6YXRpb24gR3JhbnQgLS0tfCAgICAgICAgICAgICAgIHwKICB8ICAgICAgICB8ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0rCiAgfCAgICAgICAg fAogIHwgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0t LS0tLSsKICB8ICAgICAgICB8LS0oQyktLSBBdXRob3JpemF0aW9uIEdyYW50IC0tJmd0O3wgQXV0 aG9yaXphdGlvbiB8CiAgfCBDbGllbnQgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8 ICAgICBTZXJ2ZXIgICAgfAogIHwgICAgICAgIHwmbHQ7LShEKS0tLS0tIEFjY2VzcyBUb2tlbiAt LS0tLS0tfCAgICAgICAgICAgICAgIHwKICB8ICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0rCiAgfCAgICAgICAgfAogIHwgICAgICAgIHwgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLSsKICB8ICAgICAgICB8 LS0oRSktLS0tLSBBY2Nlc3MgVG9rZW4gLS0tLS0tJmd0O3wgICAgUmVzb3VyY2UgICB8CiAgfCAg ICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICBTZXJ2ZXIgICAgfAog IHwgICAgICAgIHwmbHQ7LShGKS0tLSBQcm90ZWN0ZWQgUmVzb3VyY2UgLS0tfCAgICAgICAgICAg ICAgIHwKICArLS0tLS0tLS0rICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0t LS0tLS0tLS0rCgo8L3ByZT48L2Rpdj48dGFibGUgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIg Y2VsbHNwYWNpbmc9IjIiIGFsaWduPSJjZW50ZXIiPjx0cj48dGQgYWxpZ249ImNlbnRlciI+PGZv bnQgZmFjZT0ibW9uYWNvLCBNUyBTYW5zIFNlcmlmIiBzaXplPSIxIj48Yj4mbmJzcDtGaWd1cmUm bmJzcDsxOiBBYnN0cmFjdCBQcm90b2NvbCBGbG93Jm5ic3A7PC9iPjwvZm9udD48YnIgLz48L3Rk PjwvdHI+PC90YWJsZT48aHIgY2xhc3M9Imluc2VydCIgLz4KCjxwPgogICAgICAgICAgVGhlIGFi c3RyYWN0IGZsb3cgaWxsdXN0cmF0ZWQgaW4gPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNGaWd1cmUt MSc+RmlndXJlJm5ic3A7MTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5BYnN0cmFj dCBQcm90b2NvbCBGbG93PC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPiBkZXNjcmliZXMgdGhlIGlu dGVyYWN0aW9uCiAgICAgICAgICBiZXR3ZWVuIHRoZSBmb3VyIHJvbGVzIGFuZCBpbmNsdWRlcyB0 aGUgZm9sbG93aW5nIHN0ZXBzOgogICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgPC9wPgo8Ymxv Y2txdW90ZSBjbGFzcz0idGV4dCI+PGRsPgo8ZHQ+KEEpPC9kdD4KPGRkPgogICAgICAgICAgICAg IFRoZSBjbGllbnQgcmVxdWVzdHMgYXV0aG9yaXphdGlvbiBmcm9tIHRoZSByZXNvdXJjZSBvd25l ci4gVGhlIGF1dGhvcml6YXRpb24gcmVxdWVzdAogICAgICAgICAgICAgIGNhbiBiZSBtYWRlIGRp cmVjdGx5IHRvIHRoZSByZXNvdXJjZSBvd25lciAoYXMgc2hvd24pLCBvciBwcmVmZXJhYmx5IGlu ZGlyZWN0bHkgdmlhCiAgICAgICAgICAgICAgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGFzIGFu IGludGVybWVkaWFyeS4KICAgICAgICAgICAgCjwvZGQ+CjxkdD4oQik8L2R0Pgo8ZGQ+CiAgICAg ICAgICAgICAgVGhlIGNsaWVudCByZWNlaXZlcyBhbiBhdXRob3JpemF0aW9uIGdyYW50IHdoaWNo IGlzIGEgY3JlZGVudGlhbCByZXByZXNlbnRpbmcKICAgICAgICAgICAgICB0aGUgcmVzb3VyY2Ug b3duZXIncyBhdXRob3JpemF0aW9uLCBleHByZXNzZWQgdXNpbmcgb25lIG9mIGZvdXIgZ3JhbnQg dHlwZXMgZGVmaW5lZAogICAgICAgICAgICAgIGluIHRoaXMgc3BlY2lmaWNhdGlvbiBvciB1c2lu ZyBhbiBleHRlbnNpb24gZ3JhbnQgdHlwZS4gVGhlIGF1dGhvcml6YXRpb24gZ3JhbnQgdHlwZQog ICAgICAgICAgICAgIGRlcGVuZHMgb24gdGhlIG1ldGhvZCB1c2VkIGJ5IHRoZSBjbGllbnQgdG8g cmVxdWVzdCBhdXRob3JpemF0aW9uIGFuZCB0aGUgdHlwZXMKICAgICAgICAgICAgICBzdXBwb3J0 ZWQgYnkgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLgogICAgICAgICAgICAKPC9kZD4KPGR0PihD KTwvZHQ+CjxkZD4KICAgICAgICAgICAgICBUaGUgY2xpZW50IHJlcXVlc3RzIGFuIGFjY2VzcyB0 b2tlbiBieSBhdXRoZW50aWNhdGluZyB3aXRoIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlcgogICAg ICAgICAgICAgIGFuZCBwcmVzZW50aW5nIHRoZSBhdXRob3JpemF0aW9uIGdyYW50LgogICAgICAg ICAgICAKPC9kZD4KPGR0PihEKTwvZHQ+CjxkZD4KICAgICAgICAgICAgICBUaGUgYXV0aG9yaXph dGlvbiBzZXJ2ZXIgYXV0aGVudGljYXRlcyB0aGUgY2xpZW50IGFuZCB2YWxpZGF0ZXMgdGhlIGF1 dGhvcml6YXRpb24KICAgICAgICAgICAgICBncmFudCwgYW5kIGlmIHZhbGlkIGlzc3VlcyBhbiBh Y2Nlc3MgdG9rZW4uCiAgICAgICAgICAgIAo8L2RkPgo8ZHQ+KEUpPC9kdD4KPGRkPgogICAgICAg ICAgICAgIFRoZSBjbGllbnQgcmVxdWVzdHMgdGhlIHByb3RlY3RlZCByZXNvdXJjZSBmcm9tIHRo ZSByZXNvdXJjZSBzZXJ2ZXIgYW5kIGF1dGhlbnRpY2F0ZXMKICAgICAgICAgICAgICBieSBwcmVz ZW50aW5nIHRoZSBhY2Nlc3MgdG9rZW4uCiAgICAgICAgICAgIAo8L2RkPgo8ZHQ+KEYpPC9kdD4K PGRkPgogICAgICAgICAgICAgIFRoZSByZXNvdXJjZSBzZXJ2ZXIgdmFsaWRhdGVzIHRoZSBhY2Nl c3MgdG9rZW4sIGFuZCBpZiB2YWxpZCwgc2VydmVzIHRoZSByZXF1ZXN0LgogICAgICAgICAgICAK PC9kZD4KPC9kbD48L2Jsb2NrcXVvdGU+PHA+CiAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICBU aGUgcHJlZmVycmVkIG1ldGhvZCBmb3IgdGhlIGNsaWVudCB0byBvYnRhaW4gYW4gYXV0aG9yaXph dGlvbiBncmFudCBmcm9tIHRoZSByZXNvdXJjZQogICAgICAgICAgb3duZXIgKGRlcGljdGVkIGlu IHN0ZXBzIChBKSBhbmQgKEIpKSBpcyB0byB1c2UgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGFz IGFuIGludGVybWVkaWFyeQogICAgICAgICAgd2hpY2ggaXMgaWxsdXN0cmF0ZWQgaW4gPGEgY2xh c3M9J2luZm8nIGhyZWY9JyNGaWd1cmUtMyc+RmlndXJlJm5ic3A7MzxzcGFuPiAoPC9zcGFuPjxz cGFuIGNsYXNzPSdpbmZvJz5BdXRob3JpemF0aW9uIENvZGUgRmxvdzwvc3Bhbj48c3Bhbj4pPC9z cGFuPjwvYT4uCiAgICAgICAgCjwvcD4KPGEgbmFtZT0iYW5jaG9yNCI+PC9hPjxiciAvPjxociAv Pgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIi IGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBo cmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9 InJmYy5zZWN0aW9uLjEuMyI+PC9hPjxoMz4xLjMuJm5ic3A7CkF1dGhvcml6YXRpb24gR3JhbnQ8 L2gzPgoKPHA+CiAgICAgICAgICBBbiBhdXRob3JpemF0aW9uIGdyYW50IGlzIGEgY3JlZGVudGlh bCByZXByZXNlbnRpbmcgdGhlIHJlc291cmNlIG93bmVyJ3MgYXV0aG9yaXphdGlvbgogICAgICAg ICAgKHRvIGFjY2VzcyBpdHMgcHJvdGVjdGVkIHJlc291cmNlcykgdXNlZCBieSB0aGUgY2xpZW50 IHRvIG9idGFpbiBhbiBhY2Nlc3MgdG9rZW4uIFRoaXMKICAgICAgICAgIHNwZWNpZmljYXRpb24g ZGVmaW5lcyBmb3VyIGdyYW50IHR5cGVzOiBhdXRob3JpemF0aW9uIGNvZGUsIGltcGxpY2l0LCBy ZXNvdXJjZSBvd25lcgogICAgICAgICAgcGFzc3dvcmQgY3JlZGVudGlhbHMsIGFuZCBjbGllbnQg Y3JlZGVudGlhbHMsIGFzIHdlbGwgYXMgYW4gZXh0ZW5zaWJpbGl0eSBtZWNoYW5pc20gZm9yCiAg ICAgICAgICBkZWZpbmluZyBhZGRpdGlvbmFsIHR5cGVzLgogICAgICAgIAo8L3A+CjxhIG5hbWU9 ImFuY2hvcjUiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBh ZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0 cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwv dGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi4xLjMuMSI+PC9hPjxoMz4xLjMu MS4mbmJzcDsKQXV0aG9yaXphdGlvbiBDb2RlPC9oMz4KCjxwPgogICAgICAgICAgICBUaGUgYXV0 aG9yaXphdGlvbiBjb2RlIGlzIG9idGFpbmVkIGJ5IHVzaW5nIGFuIGF1dGhvcml6YXRpb24gc2Vy dmVyIGFzIGFuIGludGVybWVkaWFyeQogICAgICAgICAgICBiZXR3ZWVuIHRoZSBjbGllbnQgYW5k IHJlc291cmNlIG93bmVyLiBJbnN0ZWFkIG9mIHJlcXVlc3RpbmcgYXV0aG9yaXphdGlvbiBkaXJl Y3RseQogICAgICAgICAgICBmcm9tIHRoZSByZXNvdXJjZSBvd25lciwgdGhlIGNsaWVudCBkaXJl Y3RzIHRoZSByZXNvdXJjZSBvd25lciB0byBhbiBhdXRob3JpemF0aW9uCiAgICAgICAgICAgIHNl cnZlciAodmlhIGl0cyB1c2VyLWFnZW50IGFzIGRlZmluZWQgaW4gPGEgY2xhc3M9J2luZm8nIGhy ZWY9JyNSRkMyNjE2Jz5bUkZDMjYxNl08c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+ RmllbGRpbmcsIFIuLCBHZXR0eXMsIEouLCBNb2d1bCwgSi4sIEZyeXN0eWssIEguLCBNYXNpbnRl ciwgTC4sIExlYWNoLCBQLiwgYW5kIFQuIEJlcm5lcnMtTGVlLCAmbGRxdW87SHlwZXJ0ZXh0IFRy YW5zZmVyIFByb3RvY29sIC0tIEhUVFAvMS4xLCZyZHF1bzsgSnVuZSZuYnNwOzE5OTkuPC9zcGFu PjxzcGFuPik8L3NwYW4+PC9hPiksIHdoaWNoIGluIHR1cm4KICAgICAgICAgICAgZGlyZWN0cyB0 aGUgcmVzb3VyY2Ugb3duZXIgYmFjayB0byB0aGUgY2xpZW50IHdpdGggdGhlIGF1dGhvcml6YXRp b24gY29kZS4KICAgICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgICBCZWZvcmUgZGlyZWN0aW5n IHRoZSByZXNvdXJjZSBvd25lciBiYWNrIHRvIHRoZSBjbGllbnQgd2l0aCB0aGUgYXV0aG9yaXph dGlvbiBjb2RlLCB0aGUKICAgICAgICAgICAgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYXV0aGVudGlj YXRlcyB0aGUgcmVzb3VyY2Ugb3duZXIgYW5kIG9idGFpbnMgYXV0aG9yaXphdGlvbi4KICAgICAg ICAgICAgQmVjYXVzZSB0aGUgcmVzb3VyY2Ugb3duZXIgb25seSBhdXRoZW50aWNhdGVzIHdpdGgg dGhlIGF1dGhvcml6YXRpb24gc2VydmVyLCB0aGUKICAgICAgICAgICAgcmVzb3VyY2Ugb3duZXIn cyBjcmVkZW50aWFscyBhcmUgbmV2ZXIgc2hhcmVkIHdpdGggdGhlIGNsaWVudC4KICAgICAgICAg IAo8L3A+CjxwPgogICAgICAgICAgICBUaGUgYXV0aG9yaXphdGlvbiBjb2RlIHByb3ZpZGVzIGEg ZmV3IGltcG9ydGFudCBzZWN1cml0eSBiZW5lZml0cyBzdWNoIGFzIHRoZSBhYmlsaXR5CiAgICAg ICAgICAgIHRvIGF1dGhlbnRpY2F0ZSB0aGUgY2xpZW50LCBhbmQgdGhlIHRyYW5zbWlzc2lvbiBv ZiB0aGUgYWNjZXNzIHRva2VuIGRpcmVjdGx5IHRvCiAgICAgICAgICAgIHRoZSBjbGllbnQgd2l0 aG91dCBwYXNzaW5nIGl0IHRocm91Z2ggdGhlIHJlc291cmNlIG93bmVyJ3MgdXNlci1hZ2VudCwg cG90ZW50aWFsbHkKICAgICAgICAgICAgZXhwb3NpbmcgaXQgdG8gb3RoZXJzLCBpbmNsdWRpbmcg dGhlIHJlc291cmNlIG93bmVyLgogICAgICAgICAgCjwvcD4KPGEgbmFtZT0iYW5jaG9yNiI+PC9h PjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2Vs bHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0i VE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFi bGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLjEuMy4yIj48L2E+PGgzPjEuMy4yLiZuYnNwOwpJbXBs aWNpdDwvaDM+Cgo8cD4KICAgICAgICAgICAgVGhlIGltcGxpY2l0IGdyYW50IGlzIGEgc2ltcGxp ZmllZCBhdXRob3JpemF0aW9uIGNvZGUgZmxvdyBvcHRpbWl6ZWQgZm9yIGNsaWVudHMKICAgICAg ICAgICAgaW1wbGVtZW50ZWQgaW4gYSBicm93c2VyIHVzaW5nIGEgc2NyaXB0aW5nIGxhbmd1YWdl IHN1Y2ggYXMgSmF2YVNjcmlwdC4gSW4gdGhlIGltcGxpY2l0CiAgICAgICAgICAgIGZsb3csIGlu c3RlYWQgb2YgaXNzdWluZyB0aGUgY2xpZW50IGFuIGF1dGhvcml6YXRpb24gY29kZSwgdGhlIGNs aWVudCBpcyBpc3N1ZWQgYW4KICAgICAgICAgICAgYWNjZXNzIHRva2VuIGRpcmVjdGx5IChhcyB0 aGUgcmVzdWx0IG9mIHRoZSByZXNvdXJjZSBvd25lciBhdXRob3JpemF0aW9uKS4gVGhlIGdyYW50 CiAgICAgICAgICAgIHR5cGUgaXMgaW1wbGljaXQgYXMgbm8gaW50ZXJtZWRpYXRlIGNyZWRlbnRp YWxzIChzdWNoIGFzIGFuIGF1dGhvcml6YXRpb24gY29kZSkgYXJlCiAgICAgICAgICAgIGlzc3Vl ZCAoYW5kIGxhdGVyIHVzZWQgdG8gb2J0YWluIGFuIGFjY2VzcyB0b2tlbikuCiAgICAgICAgICAK PC9wPgo8cD4KICAgICAgICAgICAgV2hlbiBpc3N1aW5nIGFuIGFjY2VzcyB0b2tlbiBkdXJpbmcg dGhlIGltcGxpY2l0IGdyYW50IGZsb3csIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlcgogICAgICAg ICAgICBkb2VzIG5vdCBhdXRoZW50aWNhdGUgdGhlIGNsaWVudC4gSW4gc29tZSBjYXNlcywgdGhl IGNsaWVudCBpZGVudGl0eSBjYW4gYmUgdmVyaWZpZWQKICAgICAgICAgICAgdmlhIHRoZSByZWRp cmVjdGlvbiBVUkkgdXNlZCB0byBkZWxpdmVyIHRoZSBhY2Nlc3MgdG9rZW4gdG8gdGhlIGNsaWVu dC4gVGhlIGFjY2VzcwogICAgICAgICAgICB0b2tlbiBtYXkgYmUgZXhwb3NlZCB0byB0aGUgcmVz b3VyY2Ugb3duZXIgb3Igb3RoZXIgYXBwbGljYXRpb25zIHdpdGggYWNjZXNzIHRvIHRoZQogICAg ICAgICAgICByZXNvdXJjZSBvd25lcidzIHVzZXItYWdlbnQuCiAgICAgICAgICAKPC9wPgo8cD4K ICAgICAgICAgICAgSW1wbGljaXQgZ3JhbnRzIGltcHJvdmUgdGhlIHJlc3BvbnNpdmVuZXNzIGFu ZCBlZmZpY2llbmN5IG9mIHNvbWUgY2xpZW50cyAoc3VjaCBhcyBhCiAgICAgICAgICAgIGNsaWVu dCBpbXBsZW1lbnRlZCBhcyBhbiBpbi1icm93c2VyIGFwcGxpY2F0aW9uKSBzaW5jZSBpdCByZWR1 Y2VzIHRoZSBudW1iZXIgb2Ygcm91bmQKICAgICAgICAgICAgdHJpcHMgcmVxdWlyZWQgdG8gb2J0 YWluIGFuIGFjY2VzcyB0b2tlbi4gSG93ZXZlciwgdGhpcyBjb252ZW5pZW5jZSBzaG91bGQgYmUg d2VpZ2hlZAogICAgICAgICAgICBhZ2FpbnN0IHRoZSBzZWN1cml0eSBpbXBsaWNhdGlvbnMgb2Yg dXNpbmcgaW1wbGljaXQgZ3JhbnRzLCBlc3BlY2lhbGx5IHdoZW4gdGhlCiAgICAgICAgICAgIGF1 dGhvcml6YXRpb24gY29kZSBncmFudCB0eXBlIGlzIGF2YWlsYWJsZS4KICAgICAgICAgIAo8L3A+ CjxhIG5hbWU9ImFuY2hvcjciPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91 dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0i cmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5i c3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi4xLjMuMyI+PC9h PjxoMz4xLjMuMy4mbmJzcDsKUmVzb3VyY2UgT3duZXIgUGFzc3dvcmQgQ3JlZGVudGlhbHM8L2gz PgoKPHA+CiAgICAgICAgICAgIFRoZSByZXNvdXJjZSBvd25lciBwYXNzd29yZCBjcmVkZW50aWFs cyAoaS5lLiB1c2VybmFtZSBhbmQgcGFzc3dvcmQpIGNhbiBiZSB1c2VkCiAgICAgICAgICAgIGRp cmVjdGx5IGFzIGFuIGF1dGhvcml6YXRpb24gZ3JhbnQgdG8gb2J0YWluIGFuIGFjY2VzcyB0b2tl bi4gVGhlIGNyZWRlbnRpYWxzIHNob3VsZAogICAgICAgICAgICBvbmx5IGJlIHVzZWQgd2hlbiB0 aGVyZSBpcyBhIGhpZ2ggZGVncmVlIG9mIHRydXN0IGJldHdlZW4gdGhlIHJlc291cmNlIG93bmVy IGFuZCB0aGUKICAgICAgICAgICAgY2xpZW50IChlLmcuIHRoZSBjbGllbnQgaXMgcGFydCBvZiB0 aGUgZGV2aWNlIG9wZXJhdGluZyBzeXN0ZW0gb3IgYSBoaWdobHkgcHJpdmlsZWdlZAogICAgICAg ICAgICBhcHBsaWNhdGlvbiksIGFuZCB3aGVuIG90aGVyIGF1dGhvcml6YXRpb24gZ3JhbnQgdHlw ZXMgYXJlIG5vdCBhdmFpbGFibGUgKHN1Y2ggYXMgYW4KICAgICAgICAgICAgYXV0aG9yaXphdGlv biBjb2RlKS4KICAgICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgICBFdmVuIHRob3VnaCB0aGlz IGdyYW50IHR5cGUgcmVxdWlyZXMgZGlyZWN0IGNsaWVudCBhY2Nlc3MgdG8gdGhlIHJlc291cmNl IG93bmVyCiAgICAgICAgICAgIGNyZWRlbnRpYWxzLCB0aGUgcmVzb3VyY2Ugb3duZXIgY3JlZGVu dGlhbHMgYXJlIHVzZWQgZm9yIGEgc2luZ2xlIHJlcXVlc3QgYW5kIGFyZQogICAgICAgICAgICBl eGNoYW5nZWQgZm9yIGFuIGFjY2VzcyB0b2tlbi4gVGhpcyBncmFudCB0eXBlIGNhbiBlbGltaW5h dGUgdGhlIG5lZWQgZm9yIHRoZSBjbGllbnQKICAgICAgICAgICAgdG8gc3RvcmUgdGhlIHJlc291 cmNlIG93bmVyIGNyZWRlbnRpYWxzIGZvciBmdXR1cmUgdXNlLCBieSBleGNoYW5naW5nIHRoZSBj cmVkZW50aWFscwogICAgICAgICAgICB3aXRoIGEgbG9uZy1saXZlZCBhY2Nlc3MgdG9rZW4gb3Ig cmVmcmVzaCB0b2tlbi4KICAgICAgICAgIAo8L3A+CjxhIG5hbWU9ImFuY2hvcjgiPjwvYT48YnIg Lz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFj aW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1 ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8 YSBuYW1lPSJyZmMuc2VjdGlvbi4xLjMuNCI+PC9hPjxoMz4xLjMuNC4mbmJzcDsKQ2xpZW50IENy ZWRlbnRpYWxzPC9oMz4KCjxwPgogICAgICAgICAgICBUaGUgY2xpZW50IGNyZWRlbnRpYWxzIChv ciBvdGhlciBmb3JtcyBvZiBjbGllbnQgYXV0aGVudGljYXRpb24pIGNhbiBiZSB1c2VkIGFzIGFu CiAgICAgICAgICAgIGF1dGhvcml6YXRpb24gZ3JhbnQgd2hlbiB0aGUgYXV0aG9yaXphdGlvbiBz Y29wZSBpcyBsaW1pdGVkIHRvIHRoZSBwcm90ZWN0ZWQgcmVzb3VyY2VzCiAgICAgICAgICAgIHVu ZGVyIHRoZSBjb250cm9sIG9mIHRoZSBjbGllbnQsIG9yIHRvIHByb3RlY3RlZCByZXNvdXJjZXMg cHJldmlvdXNseSBhcnJhbmdlZCB3aXRoIHRoZQogICAgICAgICAgICBhdXRob3JpemF0aW9uIHNl cnZlci4gQ2xpZW50IGNyZWRlbnRpYWxzIGFyZSB1c2VkIGFzIGFuIGF1dGhvcml6YXRpb24gZ3Jh bnQgdHlwaWNhbGx5CiAgICAgICAgICAgIHdoZW4gdGhlIGNsaWVudCBpcyBhY3Rpbmcgb24gaXRz IG93biBiZWhhbGYgKHRoZSBjbGllbnQgaXMgYWxzbyB0aGUgcmVzb3VyY2Ugb3duZXIpLCBvcgog ICAgICAgICAgICBpcyByZXF1ZXN0aW5nIGFjY2VzcyB0byBwcm90ZWN0ZWQgcmVzb3VyY2VzIGJh c2VkIG9uIGFuIGF1dGhvcml6YXRpb24gcHJldmlvdXNseQogICAgICAgICAgICBhcnJhbmdlZCB3 aXRoIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlci4KICAgICAgICAgIAo8L3A+CjxhIG5hbWU9ImFu Y2hvcjkiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRp bmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48 dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+ PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi4xLjQiPjwvYT48aDM+MS40LiZuYnNw OwpBY2Nlc3MgVG9rZW48L2gzPgoKPHA+CiAgICAgICAgICBBY2Nlc3MgdG9rZW5zIGFyZSBjcmVk ZW50aWFscyB1c2VkIHRvIGFjY2VzcyBwcm90ZWN0ZWQgcmVzb3VyY2VzLiBBbiBhY2Nlc3MgdG9r ZW4gaXMgYQogICAgICAgICAgc3RyaW5nIHJlcHJlc2VudGluZyBhbiBhdXRob3JpemF0aW9uIGlz c3VlZCB0byB0aGUgY2xpZW50LiBUaGUgc3RyaW5nIGlzIHVzdWFsbHkgb3BhcXVlCiAgICAgICAg ICB0byB0aGUgY2xpZW50LiBUb2tlbnMgcmVwcmVzZW50IHNwZWNpZmljIHNjb3BlcyBhbmQgZHVy YXRpb25zIG9mIGFjY2VzcywgZ3JhbnRlZCBieSB0aGUKICAgICAgICAgIHJlc291cmNlIG93bmVy LCBhbmQgZW5mb3JjZWQgYnkgdGhlIHJlc291cmNlIHNlcnZlciBhbmQgYXV0aG9yaXphdGlvbiBz ZXJ2ZXIuCiAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICBUaGUgdG9rZW4gbWF5IGRlbm90ZSBh biBpZGVudGlmaWVyIHVzZWQgdG8gcmV0cmlldmUgdGhlIGF1dGhvcml6YXRpb24gaW5mb3JtYXRp b24sIG9yCiAgICAgICAgICBzZWxmLWNvbnRhaW4gdGhlIGF1dGhvcml6YXRpb24gaW5mb3JtYXRp b24gaW4gYSB2ZXJpZmlhYmxlIG1hbm5lciAoaS5lLiBhIHRva2VuIHN0cmluZwogICAgICAgICAg Y29uc2lzdGluZyBvZiBzb21lIGRhdGEgYW5kIGEgc2lnbmF0dXJlKS4gQWRkaXRpb25hbCBhdXRo ZW50aWNhdGlvbiBjcmVkZW50aWFscywgd2hpY2gKICAgICAgICAgIGFyZSBiZXlvbmQgdGhlIHNj b3BlIG9mIHRoaXMgc3BlY2lmaWNhdGlvbiwgbWF5IGJlIHJlcXVpcmVkIGluIG9yZGVyIGZvciB0 aGUgY2xpZW50IHRvCiAgICAgICAgICB1c2UgYSB0b2tlbi4KICAgICAgICAKPC9wPgo8cD4KICAg ICAgICAgIFRoZSBhY2Nlc3MgdG9rZW4gcHJvdmlkZXMgYW4gYWJzdHJhY3Rpb24gbGF5ZXIsIHJl cGxhY2luZyBkaWZmZXJlbnQgYXV0aG9yaXphdGlvbgogICAgICAgICAgY29uc3RydWN0cyAoZS5n LiB1c2VybmFtZSBhbmQgcGFzc3dvcmQpIHdpdGggYSBzaW5nbGUgdG9rZW4gdW5kZXJzdG9vZCBi eSB0aGUgcmVzb3VyY2UKICAgICAgICAgIHNlcnZlci4gVGhpcyBhYnN0cmFjdGlvbiBlbmFibGVz IGlzc3VpbmcgYWNjZXNzIHRva2VucyBtb3JlIHJlc3RyaWN0aXZlIHRoYW4gdGhlCiAgICAgICAg ICBhdXRob3JpemF0aW9uIGdyYW50IHVzZWQgdG8gb2J0YWluIHRoZW0sIGFzIHdlbGwgYXMgcmVt b3ZpbmcgdGhlIHJlc291cmNlIHNlcnZlcidzIG5lZWQgdG8KICAgICAgICAgIHVuZGVyc3RhbmQg YSB3aWRlIHJhbmdlIG9mIGF1dGhlbnRpY2F0aW9uIG1ldGhvZHMuCiAgICAgICAgCjwvcD4KPHA+ CiAgICAgICAgICBBY2Nlc3MgdG9rZW5zIGNhbiBoYXZlIGRpZmZlcmVudCBmb3JtYXRzLCBzdHJ1 Y3R1cmVzLCBhbmQgbWV0aG9kcyBvZiB1dGlsaXphdGlvbiAoZS5nLgogICAgICAgICAgY3J5cHRv Z3JhcGhpYyBwcm9wZXJ0aWVzKSBiYXNlZCBvbiB0aGUgcmVzb3VyY2Ugc2VydmVyIHNlY3VyaXR5 IHJlcXVpcmVtZW50cy4gQWNjZXNzIHRva2VuCiAgICAgICAgICBhdHRyaWJ1dGVzIGFuZCB0aGUg bWV0aG9kcyB1c2VkIHRvIGFjY2VzcyBwcm90ZWN0ZWQgcmVzb3VyY2VzIGFyZSBiZXlvbmQgdGhl IHNjb3BlIG9mIHRoaXMKICAgICAgICAgIHNwZWNpZmljYXRpb24gYW5kIGFyZSBkZWZpbmVkIGJ5 IGNvbXBhbmlvbiBzcGVjaWZpY2F0aW9ucy4KICAgICAgICAKPC9wPgo8YSBuYW1lPSJhbmNob3Ix MCI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0i MCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBj bGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3Ry PjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLjEuNSI+PC9hPjxoMz4xLjUuJm5ic3A7ClJl ZnJlc2ggVG9rZW48L2gzPgoKPHA+CiAgICAgICAgICBSZWZyZXNoIHRva2VucyBhcmUgY3JlZGVu dGlhbHMgdXNlZCB0byBvYnRhaW4gYWNjZXNzIHRva2Vucy4gUmVmcmVzaCB0b2tlbnMgYXJlIGlz c3VlZCB0bwogICAgICAgICAgdGhlIGNsaWVudCBieSB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIg YW5kIGFyZSB1c2VkIHRvIG9idGFpbiBhIG5ldyBhY2Nlc3MgdG9rZW4gd2hlbiB0aGUKICAgICAg ICAgIGN1cnJlbnQgYWNjZXNzIHRva2VuIGJlY29tZXMgaW52YWxpZCBvciBleHBpcmVzLCBvciB0 byBvYnRhaW4gYWRkaXRpb25hbCBhY2Nlc3MgdG9rZW5zCiAgICAgICAgICB3aXRoIGlkZW50aWNh bCBvciBuYXJyb3dlciBzY29wZSAoYWNjZXNzIHRva2VucyBtYXkgaGF2ZSBhIHNob3J0ZXIgbGlm ZXRpbWUgYW5kIGZld2VyCiAgICAgICAgICBwZXJtaXNzaW9ucyB0aGFuIGF1dGhvcml6ZWQgYnkg dGhlIHJlc291cmNlIG93bmVyKS4gSXNzdWluZyBhIHJlZnJlc2ggdG9rZW4gaXMgb3B0aW9uYWwK ICAgICAgICAgIGF0IHRoZSBkaXNjcmV0aW9uIG9mIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlci4g SWYgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGlzc3VlcyBhCiAgICAgICAgICByZWZyZXNoIHRv a2VuLCBpdCBpcyBpbmNsdWRlZCB3aGVuIGlzc3VpbmcgYW4gYWNjZXNzIHRva2VuIChpLmUuIHN0 ZXAgKEQpIGluCiAgICAgICAgICA8YSBjbGFzcz0naW5mbycgaHJlZj0nI0ZpZ3VyZS0xJz5GaWd1 cmUmbmJzcDsxPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkFic3RyYWN0IFByb3Rv Y29sIEZsb3c8L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+KS4KICAgICAgICAKPC9wPgo8cD4KICAg ICAgICAgIEEgcmVmcmVzaCB0b2tlbiBpcyBhIHN0cmluZyByZXByZXNlbnRpbmcgdGhlIGF1dGhv cml6YXRpb24gZ3JhbnRlZCB0byB0aGUgY2xpZW50IGJ5IHRoZQogICAgICAgICAgcmVzb3VyY2Ug b3duZXIuIFRoZSBzdHJpbmcgaXMgdXN1YWxseSBvcGFxdWUgdG8gdGhlIGNsaWVudC4gVGhlIHRv a2VuIGRlbm90ZXMgYW4KICAgICAgICAgIGlkZW50aWZpZXIgdXNlZCB0byByZXRyaWV2ZSB0aGUg YXV0aG9yaXphdGlvbiBpbmZvcm1hdGlvbi4gVW5saWtlIGFjY2VzcyB0b2tlbnMsIHJlZnJlc2gK ICAgICAgICAgIHRva2VucyBhcmUgaW50ZW5kZWQgZm9yIHVzZSBvbmx5IHdpdGggYXV0aG9yaXph dGlvbiBzZXJ2ZXJzIGFuZCBhcmUgbmV2ZXIgc2VudCB0bwogICAgICAgICAgcmVzb3VyY2Ugc2Vy dmVycy4KICAgICAgICAKPC9wPjxiciAvPjxociBjbGFzcz0iaW5zZXJ0IiAvPgo8YSBuYW1lPSJG aWd1cmUtMiI+PC9hPgo8ZGl2IHN0eWxlPSdkaXNwbGF5OiB0YWJsZTsgd2lkdGg6IDA7IG1hcmdp bi1sZWZ0OiAzZW07IG1hcmdpbi1yaWdodDogYXV0byc+PHByZT4KCiAgKy0tLS0tLS0tKyAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tKwog IHwgICAgICAgIHwtLShBKS0tLS0tLS0gQXV0aG9yaXphdGlvbiBHcmFudCAtLS0tLS0tLS0mZ3Q7 fCAgICAgICAgICAgICAgIHwKICB8ICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICB8CiAgfCAgICAgICAgfCZsdDstKEIpLS0t LS0tLS0tLS0gQWNjZXNzIFRva2VuIC0tLS0tLS0tLS0tLS18ICAgICAgICAgICAgICAgfAogIHwg ICAgICAgIHwgICAgICAgICAgICAgICAmYW1wOyBSZWZyZXNoIFRva2VuICAgICAgICAgICAgIHwg ICAgICAgICAgICAgICB8CiAgfCAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgfAogIHwgICAgICAgIHwgICAgICAgICAgICAg ICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0rICAgfCAgICAgICAgICAgICAgIHwKICB8ICAgICAg ICB8LS0oQyktLS0tIEFjY2VzcyBUb2tlbiAtLS0tJmd0O3wgICAgICAgICAgfCAgIHwgICAgICAg ICAgICAgICB8CiAgfCAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAg ICAgIHwgICB8ICAgICAgICAgICAgICAgfAogIHwgICAgICAgIHwmbHQ7LShEKS0gUHJvdGVjdGVk IFJlc291cmNlIC0tfCBSZXNvdXJjZSB8ICAgfCBBdXRob3JpemF0aW9uIHwKICB8IENsaWVudCB8 ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgIFNlcnZlciAgfCAgIHwgICAgIFNlcnZlciAg ICB8CiAgfCAgICAgICAgfC0tKEUpLS0tLSBBY2Nlc3MgVG9rZW4gLS0tLSZndDt8ICAgICAgICAg IHwgICB8ICAgICAgICAgICAgICAgfAogIHwgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAg ICAgICAgfCAgICAgICAgICB8ICAgfCAgICAgICAgICAgICAgIHwKICB8ICAgICAgICB8Jmx0Oy0o RiktIEludmFsaWQgVG9rZW4gRXJyb3IgLXwgICAgICAgICAgfCAgIHwgICAgICAgICAgICAgICB8 CiAgfCAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLSsgICB8 ICAgICAgICAgICAgICAgfAogIHwgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgIHwKICB8ICAgICAgICB8LS0oRyktLS0tLS0t LS0tLSBSZWZyZXNoIFRva2VuIC0tLS0tLS0tLS0tJmd0O3wgICAgICAgICAgICAgICB8CiAgfCAg ICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAg ICAgICAgICAgfAogIHwgICAgICAgIHwmbHQ7LShIKS0tLS0tLS0tLS0tIEFjY2VzcyBUb2tlbiAt LS0tLS0tLS0tLS0tfCAgICAgICAgICAgICAgIHwKICArLS0tLS0tLS0rICAgICAgICAgICAmYW1w OyBPcHRpb25hbCBSZWZyZXNoIFRva2VuICAgICAgICArLS0tLS0tLS0tLS0tLS0tKwoKPC9wcmU+ PC9kaXY+PHRhYmxlIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBh bGlnbj0iY2VudGVyIj48dHI+PHRkIGFsaWduPSJjZW50ZXIiPjxmb250IGZhY2U9Im1vbmFjbywg TVMgU2FucyBTZXJpZiIgc2l6ZT0iMSI+PGI+Jm5ic3A7RmlndXJlJm5ic3A7MjogUmVmcmVzaGlu ZyBhbiBFeHBpcmVkIEFjY2VzcyBUb2tlbiZuYnNwOzwvYj48L2ZvbnQ+PGJyIC8+PC90ZD48L3Ry PjwvdGFibGU+PGhyIGNsYXNzPSJpbnNlcnQiIC8+Cgo8cD4KICAgICAgICAgIFRoZSBmbG93IGls bHVzdHJhdGVkIGluIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjRmlndXJlLTInPkZpZ3VyZSZuYnNw OzI8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+UmVmcmVzaGluZyBhbiBFeHBpcmVk IEFjY2VzcyBUb2tlbjwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4gaW5jbHVkZXMgdGhlIGZvbGxv d2luZyBzdGVwczoKICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgIDwvcD4KPGJsb2NrcXVvdGUg Y2xhc3M9InRleHQiPjxkbD4KPGR0PihBKTwvZHQ+CjxkZD4KICAgICAgICAgICAgICBUaGUgY2xp ZW50IHJlcXVlc3RzIGFuIGFjY2VzcyB0b2tlbiBieSBhdXRoZW50aWNhdGluZyB3aXRoIHRoZSBh dXRob3JpemF0aW9uIHNlcnZlciwKICAgICAgICAgICAgICBhbmQgcHJlc2VudGluZyBhbiBhdXRo b3JpemF0aW9uIGdyYW50LgogICAgICAgICAgICAKPC9kZD4KPGR0PihCKTwvZHQ+CjxkZD4KICAg ICAgICAgICAgICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYXV0aGVudGljYXRlcyB0aGUgY2xp ZW50IGFuZCB2YWxpZGF0ZXMgdGhlIGF1dGhvcml6YXRpb24KICAgICAgICAgICAgICBncmFudCwg YW5kIGlmIHZhbGlkIGlzc3VlcyBhbiBhY2Nlc3MgdG9rZW4gYW5kIGEgcmVmcmVzaCB0b2tlbi4K ICAgICAgICAgICAgCjwvZGQ+CjxkdD4oQyk8L2R0Pgo8ZGQ+CiAgICAgICAgICAgICAgVGhlIGNs aWVudCBtYWtlcyBhIHByb3RlY3RlZCByZXNvdXJjZSByZXF1ZXN0IHRvIHRoZSByZXNvdXJjZSBz ZXJ2ZXIgYnkgcHJlc2VudGluZwogICAgICAgICAgICAgIHRoZSBhY2Nlc3MgdG9rZW4uCiAgICAg ICAgICAgIAo8L2RkPgo8ZHQ+KEQpPC9kdD4KPGRkPgogICAgICAgICAgICAgIFRoZSByZXNvdXJj ZSBzZXJ2ZXIgdmFsaWRhdGVzIHRoZSBhY2Nlc3MgdG9rZW4sIGFuZCBpZiB2YWxpZCwgc2VydmVz IHRoZSByZXF1ZXN0LgogICAgICAgICAgICAKPC9kZD4KPGR0PihFKTwvZHQ+CjxkZD4KICAgICAg ICAgICAgICBTdGVwcyAoQykgYW5kIChEKSByZXBlYXQgdW50aWwgdGhlIGFjY2VzcyB0b2tlbiBl eHBpcmVzLiBJZiB0aGUgY2xpZW50IGtub3dzIHRoZQogICAgICAgICAgICAgIGFjY2VzcyB0b2tl biBleHBpcmVkLCBpdCBza2lwcyB0byBzdGVwIChHKSwgb3RoZXJ3aXNlIGl0IG1ha2VzIGFub3Ro ZXIgcHJvdGVjdGVkCiAgICAgICAgICAgICAgcmVzb3VyY2UgcmVxdWVzdC4KICAgICAgICAgICAg CjwvZGQ+CjxkdD4oRik8L2R0Pgo8ZGQ+CiAgICAgICAgICAgICAgU2luY2UgdGhlIGFjY2VzcyB0 b2tlbiBpcyBpbnZhbGlkLCB0aGUgcmVzb3VyY2Ugc2VydmVyIHJldHVybnMgYW4gaW52YWxpZCB0 b2tlbgogICAgICAgICAgICAgIGVycm9yLgogICAgICAgICAgICAKPC9kZD4KPGR0PihHKTwvZHQ+ CjxkZD4KICAgICAgICAgICAgICBUaGUgY2xpZW50IHJlcXVlc3RzIGEgbmV3IGFjY2VzcyB0b2tl biBieSBhdXRoZW50aWNhdGluZyB3aXRoIHRoZSBhdXRob3JpemF0aW9uCiAgICAgICAgICAgICAg c2VydmVyIGFuZCBwcmVzZW50aW5nIHRoZSByZWZyZXNoIHRva2VuLiBUaGUgY2xpZW50IGF1dGhl bnRpY2F0aW9uIHJlcXVpcmVtZW50cyBhcmUKICAgICAgICAgICAgICBiYXNlZCBvbiB0aGUgY2xp ZW50IHR5cGUgYW5kIG9uIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBwb2xpY2llcy4KICAgICAg ICAgICAgCjwvZGQ+CjxkdD4oSCk8L2R0Pgo8ZGQ+CiAgICAgICAgICAgICAgVGhlIGF1dGhvcml6 YXRpb24gc2VydmVyIGF1dGhlbnRpY2F0ZXMgdGhlIGNsaWVudCBhbmQgdmFsaWRhdGVzIHRoZSBy ZWZyZXNoIHRva2VuLAogICAgICAgICAgICAgIGFuZCBpZiB2YWxpZCBpc3N1ZXMgYSBuZXcgYWNj ZXNzIHRva2VuIChhbmQgb3B0aW9uYWxseSwgYSBuZXcgcmVmcmVzaCB0b2tlbikuCiAgICAgICAg ICAgIAo8L2RkPgo8L2RsPjwvYmxvY2txdW90ZT48cD4KICAgICAgICAKPC9wPgo8cD4KICAgICAg ICAgIFN0ZXBzIEMsIEQsIEUsIGFuZCBGIGFyZSBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIHNw ZWNpZmljYXRpb24gYXMgZGVzY3JpYmVkIGluCiAgICAgICAgICA8YSBjbGFzcz0naW5mbycgaHJl Zj0nI2FjY2Vzcy1yZXNvdXJjZSc+U2VjdGlvbiZuYnNwOzc8c3Bhbj4gKDwvc3Bhbj48c3BhbiBj bGFzcz0naW5mbyc+QWNjZXNzaW5nIFByb3RlY3RlZCBSZXNvdXJjZXM8L3NwYW4+PHNwYW4+KTwv c3Bhbj48L2E+LgogICAgICAgIAo8L3A+CjxhIG5hbWU9InRscyI+PC9hPjxiciAvPjxociAvPgo8 dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNs YXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVm PSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJm Yy5zZWN0aW9uLjEuNiI+PC9hPjxoMz4xLjYuJm5ic3A7ClRMUyBWZXJzaW9uPC9oMz4KCjxwPgog ICAgICAgICAgV2hlbmV2ZXIgVExTIGlzIHVzZWQgYnkgdGhpcyBzcGVjaWZpY2F0aW9uLCB0aGUg YXBwcm9wcmlhdGUgdmVyc2lvbiAob3IgdmVyc2lvbnMpIG9mCiAgICAgICAgICBUTFMgd2lsbCB2 YXJ5IG92ZXIgdGltZSwgYmFzZWQgb24gdGhlIHdpZGVzcHJlYWQgZGVwbG95bWVudCBhbmQga25v d24gc2VjdXJpdHkKICAgICAgICAgIHZ1bG5lcmFiaWxpdGllcy4gQXQgdGhlIHRpbWUgb2YgdGhp cyB3cml0aW5nLCBUTFMgdmVyc2lvbiAxLjIgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNSRkM1MjQ2 Jz5bUkZDNTI0Nl08c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+RGllcmtzLCBULiBh bmQgRS4gUmVzY29ybGEsICZsZHF1bztUaGUgVHJhbnNwb3J0IExheWVyIFNlY3VyaXR5IChUTFMp IFByb3RvY29sIFZlcnNpb24gMS4yLCZyZHF1bzsgQXVndXN0Jm5ic3A7MjAwOC48L3NwYW4+PHNw YW4+KTwvc3Bhbj48L2E+CiAgICAgICAgICBpcyB0aGUgbW9zdCByZWNlbnQgdmVyc2lvbiwgYnV0 IGhhcyBhIHZlcnkgbGltaXRlZCBkZXBsb3ltZW50IGJhc2UgYW5kIG1pZ2h0IG5vdCBiZQogICAg ICAgICAgcmVhZGlseSBhdmFpbGFibGUgZm9yIGltcGxlbWVudGF0aW9uLiBUTFMgdmVyc2lvbiAx LjAgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNSRkMyMjQ2Jz5bUkZDMjI0Nl08c3Bhbj4gKDwvc3Bh bj48c3BhbiBjbGFzcz0naW5mbyc+RGllcmtzLCBULiBhbmQgQy4gQWxsZW4sICZsZHF1bztUaGUg VExTIFByb3RvY29sIFZlcnNpb24gMS4wLCZyZHF1bzsgSmFudWFyeSZuYnNwOzE5OTkuPC9zcGFu PjxzcGFuPik8L3NwYW4+PC9hPiBpcyB0aGUKICAgICAgICAgIG1vc3Qgd2lkZWx5IGRlcGxveWVk IHZlcnNpb24sIGFuZCB3aWxsIHByb3ZpZGUgdGhlIGJyb2FkZXN0IGludGVyb3BlcmFiaWxpdHku CiAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICBJbXBsZW1lbnRhdGlvbnMgTUFZIGFsc28gc3Vw cG9ydCBhZGRpdGlvbmFsIHRyYW5zcG9ydC1sYXllciBzZWN1cml0eSBtZWNoYW5pc21zCiAgICAg ICAgICB0aGF0IG1lZXQgdGhlaXIgc2VjdXJpdHkgcmVxdWlyZW1lbnRzLgogICAgICAgIAo8L3A+ CjxhIG5hbWU9ImFuY2hvcjExIj48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlv dXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249 InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZu YnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uMS43Ij48L2E+ PGgzPjEuNy4mbmJzcDsKSFRUUCBSZWRpcmVjdGlvbnM8L2gzPgoKPHA+CiAgICAgICAgICBUaGlz IHNwZWNpZmljYXRpb24gbWFrZXMgZXh0ZW5zaXZlIHVzZSBvZiBIVFRQIHJlZGlyZWN0aW9ucywg aW4gd2hpY2ggdGhlIGNsaWVudCBvciB0aGUKICAgICAgICAgIGF1dGhvcml6YXRpb24gc2VydmVy IGRpcmVjdCB0aGUgcmVzb3VyY2Ugb3duZXIncyB1c2VyLWFnZW50IHRvIGFub3RoZXIgZGVzdGlu YXRpb24uIFdoaWxlCiAgICAgICAgICB0aGUgZXhhbXBsZXMgaW4gdGhpcyBzcGVjaWZpY2F0aW9u IHNob3cgdGhlIHVzZSBvZiB0aGUgSFRUUCAzMDIgc3RhdHVzIGNvZGUsIGFueSBvdGhlcgogICAg ICAgICAgbWV0aG9kIGF2YWlsYWJsZSB2aWEgdGhlIHVzZXItYWdlbnQgdG8gYWNjb21wbGlzaCB0 aGlzIHJlZGlyZWN0aW9uIGlzIGFsbG93ZWQgYW5kIGlzCiAgICAgICAgICBjb25zaWRlcmVkIHRv IGJlIGFuIGltcGxlbWVudGF0aW9uIGRldGFpbC4KICAgICAgICAKPC9wPgo8YSBuYW1lPSJhbmNo b3IxMiI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGlu Zz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0 ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48 L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLjEuOCI+PC9hPjxoMz4xLjguJm5ic3A7 CkludGVyb3BlcmFiaWxpdHk8L2gzPgoKPHA+CiAgICAgICAgICBPQXV0aCAyLjAgcHJvdmlkZXMg YSByaWNoIGF1dGhvcml6YXRpb24gZnJhbWV3b3JrIHdpdGggd2VsbC1kZWZpbmVkIHNlY3VyaXR5 IHByb3BlcnRpZXMuCiAgICAgICAgICBIb3dldmVyLCBhcyBhIHJpY2ggYW5kIGhpZ2hseSBleHRl bnNpYmxlIGZyYW1ld29yayB3aXRoIG1hbnkgb3B0aW9uYWwgY29tcG9uZW50cywgb24gaXRzCiAg ICAgICAgICBvd24sIHRoaXMgc3BlY2lmaWNhdGlvbiBpcyBsaWtlbHkgdG8gcHJvZHVjZSBhIHdp ZGUgcmFuZ2Ugb2Ygbm9uLWludGVyb3BlcmFibGUKICAgICAgICAgIGltcGxlbWVudGF0aW9ucy4K ICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgIEluIGFkZGl0aW9uLCB0aGlzIHNwZWNpZmljYXRp b24gbGVhdmVzIGEgZmV3IHJlcXVpcmVkIGNvbXBvbmVudHMgcGFydGlhbGx5IG9yIGZ1bGx5CiAg ICAgICAgICB1bmRlZmluZWQgKGUuZy4gY2xpZW50IHJlZ2lzdHJhdGlvbiwgYXV0aG9yaXphdGlv biBzZXJ2ZXIgY2FwYWJpbGl0aWVzLCBlbmRwb2ludAogICAgICAgICAgZGlzY292ZXJ5KS4gV2l0 aG91dCB0aGVzZSBjb21wb25lbnRzLCBjbGllbnRzIG11c3QgYmUgbWFudWFsbHkgYW5kIHNwZWNp ZmljYWxseQogICAgICAgICAgY29uZmlndXJlZCBhZ2FpbnN0IGEgc3BlY2lmaWMgYXV0aG9yaXph dGlvbiBzZXJ2ZXIgYW5kIHJlc291cmNlIHNlcnZlciBpbiBvcmRlciB0bwogICAgICAgICAgaW50 ZXJvcGVyYXRlLgogICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgVGhpcyBmcmFtZXdvcmsgd2Fz IGRlc2lnbmVkIHdpdGggdGhlIGNsZWFyIGV4cGVjdGF0aW9uIHRoYXQgZnV0dXJlIHdvcmsgd2ls bCBkZWZpbmUKICAgICAgICAgIHByZXNjcmlwdGl2ZSBwcm9maWxlcyBhbmQgZXh0ZW5zaW9ucyBu ZWNlc3NhcnkgdG8gYWNoaWV2ZSBmdWxsIHdlYi1zY2FsZQogICAgICAgICAgaW50ZXJvcGVyYWJp bGl0eS4KICAgICAgICAKPC9wPgo8YSBuYW1lPSJhbmNob3IxMyI+PC9hPjxiciAvPjxociAvPgo8 dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNs YXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVm PSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJm Yy5zZWN0aW9uLjEuOSI+PC9hPjxoMz4xLjkuJm5ic3A7Ck5vdGF0aW9uYWwgQ29udmVudGlvbnM8 L2gzPgoKPHA+CiAgICAgICAgICBUaGUga2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJF UVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxMIE5PVCIsICJTSE9VTEQiLCAiU0hPVUxECiAgICAgICAg ICBOT1QiLCAiUkVDT01NRU5ERUQiLCAiTUFZIiwgYW5kICJPUFRJT05BTCIgaW4gdGhpcyBzcGVj aWZpY2F0aW9uIGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcwogICAgICAgICAgZGVzY3JpYmVkIGlu IDxhIGNsYXNzPSdpbmZvJyBocmVmPScjUkZDMjExOSc+W1JGQzIxMTldPHNwYW4+ICg8L3NwYW4+ PHNwYW4gY2xhc3M9J2luZm8nPkJyYWRuZXIsIFMuLCAmbGRxdW87S2V5IHdvcmRzIGZvciB1c2Ug aW4gUkZDcyB0byBJbmRpY2F0ZSBSZXF1aXJlbWVudCBMZXZlbHMsJnJkcXVvOyBNYXJjaCZuYnNw OzE5OTcuPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPi4KICAgICAgICAKPC9wPgo8cD4KICAgICAg ICAgIFRoaXMgc3BlY2lmaWNhdGlvbiB1c2VzIHRoZSBBdWdtZW50ZWQgQmFja3VzLU5hdXIgRm9y bSAoQUJORikgbm90YXRpb24gb2YKICAgICAgICAgIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjUkZD NTIzNCc+W1JGQzUyMzRdPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkNyb2NrZXIs IEQuIGFuZCBQLiBPdmVyZWxsLCAmbGRxdW87QXVnbWVudGVkIEJORiBmb3IgU3ludGF4IFNwZWNp ZmljYXRpb25zOiBBQk5GLCZyZHF1bzsgSmFudWFyeSZuYnNwOzIwMDguPC9zcGFuPjxzcGFuPik8 L3NwYW4+PC9hPi4KCSAgQWRkaXRpb25hbGx5LCB0aGUgcnVsZSBVUkktUmVmZXJlbmNlIGlzIGlu Y2x1ZGVkIGZyb20KCSAgVW5pZm9ybSBSZXNvdXJjZSBJZGVudGlmaWVyIChVUkkpIDxhIGNsYXNz PSdpbmZvJyBocmVmPScjUkZDMzk4Nic+W1JGQzM5ODZdPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xh c3M9J2luZm8nPkJlcm5lcnMtTGVlLCBULiwgRmllbGRpbmcsIFIuLCBhbmQgTC4gTWFzaW50ZXIs ICZsZHF1bztVbmlmb3JtIFJlc291cmNlIElkZW50aWZpZXIgKFVSSSk6IEdlbmVyaWMgU3ludGF4 LCZyZHF1bzsgSmFudWFyeSZuYnNwOzIwMDUuPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPi4KICAg ICAgICAKPC9wPgo8cD4KICAgICAgICAgIENlcnRhaW4gc2VjdXJpdHktcmVsYXRlZCB0ZXJtcyBh cmUgdG8gYmUgdW5kZXJzdG9vZCBpbiB0aGUgc2Vuc2UgZGVmaW5lZCBpbgogICAgICAgICAgPGEg Y2xhc3M9J2luZm8nIGhyZWY9JyNSRkM0OTQ5Jz5bUkZDNDk0OV08c3Bhbj4gKDwvc3Bhbj48c3Bh biBjbGFzcz0naW5mbyc+U2hpcmV5LCBSLiwgJmxkcXVvO0ludGVybmV0IFNlY3VyaXR5IEdsb3Nz YXJ5LCBWZXJzaW9uIDIsJnJkcXVvOyBBdWd1c3QmbmJzcDsyMDA3Ljwvc3Bhbj48c3Bhbj4pPC9z cGFuPjwvYT4uIFRoZXNlIHRlcm1zIGluY2x1ZGUsIGJ1dCBhcmUgbm90IGxpbWl0ZWQgdG8sICJh dHRhY2siLAogICAgICAgICAgImF1dGhlbnRpY2F0aW9uIiwgImF1dGhvcml6YXRpb24iLCAiY2Vy dGlmaWNhdGUiLCAiY29uZmlkZW50aWFsaXR5IiwgImNyZWRlbnRpYWwiLAogICAgICAgICAgImVu Y3J5cHRpb24iLCAiaWRlbnRpdHkiLCAic2lnbiIsICJzaWduYXR1cmUiLCAidHJ1c3QiLCAidmFs aWRhdGUiLCBhbmQgInZlcmlmeSIuCiAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICBVbmxlc3Mg b3RoZXJ3aXNlIG5vdGVkLCBhbGwgdGhlIHByb3RvY29sIHBhcmFtZXRlciBuYW1lcyBhbmQgdmFs dWVzIGFyZSBjYXNlIHNlbnNpdGl2ZS4KICAgICAgICAKPC9wPgo8YSBuYW1lPSJhbmNob3IxNCI+ PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIg Y2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFz cz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwv dGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLjIiPjwvYT48aDM+Mi4mbmJzcDsKQ2xpZW50IFJl Z2lzdHJhdGlvbjwvaDM+Cgo8cD4KICAgICAgICBCZWZvcmUgaW5pdGlhdGluZyB0aGUgcHJvdG9j b2wsIHRoZSBjbGllbnQgcmVnaXN0ZXJzIHdpdGggdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLiBU aGUKICAgICAgICBtZWFucyB0aHJvdWdoIHdoaWNoIHRoZSBjbGllbnQgcmVnaXN0ZXJzIHdpdGgg dGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGFyZSBiZXlvbmQgdGhlCiAgICAgICAgc2NvcGUgb2Yg dGhpcyBzcGVjaWZpY2F0aW9uLCBidXQgdHlwaWNhbGx5IGludm9sdmUgZW5kLXVzZXIgaW50ZXJh Y3Rpb24gd2l0aCBhbiBIVE1MCiAgICAgICAgcmVnaXN0cmF0aW9uIGZvcm0uCiAgICAgIAo8L3A+ CjxwPgogICAgICAgIENsaWVudCByZWdpc3RyYXRpb24gZG9lcyBub3QgcmVxdWlyZSBhIGRpcmVj dCBpbnRlcmFjdGlvbiBiZXR3ZWVuIHRoZSBjbGllbnQgYW5kIHRoZQogICAgICAgIGF1dGhvcml6 YXRpb24gc2VydmVyLiBXaGVuIHN1cHBvcnRlZCBieSB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIs IHJlZ2lzdHJhdGlvbiBjYW4gcmVseQogICAgICAgIG9uIG90aGVyIG1lYW5zIGZvciBlc3RhYmxp c2hpbmcgdHJ1c3QgYW5kIG9idGFpbmluZyB0aGUgcmVxdWlyZWQgY2xpZW50IHByb3BlcnRpZXMg KGUuZy4KICAgICAgICByZWRpcmVjdGlvbiBVUkksIGNsaWVudCB0eXBlKS4gRm9yIGV4YW1wbGUs IHJlZ2lzdHJhdGlvbiBjYW4gYmUgYWNjb21wbGlzaGVkIHVzaW5nIGEKICAgICAgICBzZWxmLWlz c3VlZCBvciB0aGlyZC1wYXJ0eS1pc3N1ZWQgYXNzZXJ0aW9uLCBvciBieSB0aGUgYXV0aG9yaXph dGlvbiBzZXJ2ZXIgcGVyZm9ybWluZwogICAgICAgIGNsaWVudCBkaXNjb3ZlcnkgdXNpbmcgYSB0 cnVzdGVkIGNoYW5uZWwuCiAgICAgIAo8L3A+CjxwPgogICAgICAgIFdoZW4gcmVnaXN0ZXJpbmcg YSBjbGllbnQsIHRoZSBjbGllbnQgZGV2ZWxvcGVyIFNIQUxMOgogICAgICAKPC9wPgo8cD4KICAg ICAgICA8L3A+Cjx1bCBjbGFzcz0idGV4dCI+CjxsaT4KICAgICAgICAgICAgc3BlY2lmeSB0aGUg Y2xpZW50IHR5cGUgYXMgZGVzY3JpYmVkIGluIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjY2xpZW50 LXR5cGVzJz5TZWN0aW9uJm5ic3A7Mi4xPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8n PkNsaWVudCBUeXBlczwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4sCiAgICAgICAgICAKPC9saT4K PGxpPgogICAgICAgICAgICBwcm92aWRlIGl0cyBjbGllbnQgcmVkaXJlY3Rpb24gVVJJcyBhcyBk ZXNjcmliZWQgaW4KICAgICAgICAgICAgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNyZWRpcmVjdC11 cmknPlNlY3Rpb24mbmJzcDszLjEuMjxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5S ZWRpcmVjdGlvbiBFbmRwb2ludDwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4sIGFuZAogICAgICAg ICAgCjwvbGk+CjxsaT4KICAgICAgICAgICAgaW5jbHVkZSBhbnkgb3RoZXIgaW5mb3JtYXRpb24g cmVxdWlyZWQgYnkgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIChlLmcuIGFwcGxpY2F0aW9uCiAg ICAgICAgICAgIG5hbWUsIHdlYnNpdGUsIGRlc2NyaXB0aW9uLCBsb2dvIGltYWdlLCB0aGUgYWNj ZXB0YW5jZSBvZiBsZWdhbCB0ZXJtcykuCiAgICAgICAgICAKPC9saT4KPC91bD48cD4KICAgICAg CjwvcD4KPGEgbmFtZT0iY2xpZW50LXR5cGVzIj48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1t YXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1 ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZu YnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24u Mi4xIj48L2E+PGgzPjIuMS4mbmJzcDsKQ2xpZW50IFR5cGVzPC9oMz4KCjxwPgogICAgICAgICAg T0F1dGggZGVmaW5lcyB0d28gY2xpZW50IHR5cGVzLCBiYXNlZCBvbiB0aGVpciBhYmlsaXR5IHRv IGF1dGhlbnRpY2F0ZSBzZWN1cmVseSB3aXRoIHRoZQogICAgICAgICAgYXV0aG9yaXphdGlvbiBz ZXJ2ZXIgKGkuZS4gYWJpbGl0eSB0byBtYWludGFpbiB0aGUgY29uZmlkZW50aWFsaXR5IG9mIHRo ZWlyIGNsaWVudAogICAgICAgICAgY3JlZGVudGlhbHMpOgogICAgICAgIAo8L3A+CjxwPgogICAg ICAgICAgPC9wPgo8YmxvY2txdW90ZSBjbGFzcz0idGV4dCI+PGRsPgo8ZHQ+Y29uZmlkZW50aWFs PC9kdD4KPGRkPgogICAgICAgICAgICAgIAogICAgICAgICAgICAgIENsaWVudHMgY2FwYWJsZSBv ZiBtYWludGFpbmluZyB0aGUgY29uZmlkZW50aWFsaXR5IG9mIHRoZWlyIGNyZWRlbnRpYWxzIChl LmcuCiAgICAgICAgICAgICAgY2xpZW50IGltcGxlbWVudGVkIG9uIGEgc2VjdXJlIHNlcnZlciB3 aXRoIHJlc3RyaWN0ZWQgYWNjZXNzIHRvIHRoZSBjbGllbnQKICAgICAgICAgICAgICBjcmVkZW50 aWFscyksIG9yIGNhcGFibGUgb2Ygc2VjdXJlIGNsaWVudCBhdXRoZW50aWNhdGlvbiB1c2luZyBv dGhlciBtZWFucy4KICAgICAgICAgICAgCjwvZGQ+CjxkdD5wdWJsaWM8L2R0Pgo8ZGQ+CiAgICAg ICAgICAgICAgCiAgICAgICAgICAgICAgQ2xpZW50cyBpbmNhcGFibGUgb2YgbWFpbnRhaW5pbmcg dGhlIGNvbmZpZGVudGlhbGl0eSBvZiB0aGVpciBjcmVkZW50aWFscyAoZS5nLgogICAgICAgICAg ICAgIGNsaWVudHMgZXhlY3V0aW5nIG9uIHRoZSBkZXZpY2UgdXNlZCBieSB0aGUgcmVzb3VyY2Ug b3duZXIgc3VjaCBhcyBhbiBpbnN0YWxsZWQKICAgICAgICAgICAgICBuYXRpdmUgYXBwbGljYXRp b24gb3IgYSB3ZWIgYnJvd3Nlci1iYXNlZCBhcHBsaWNhdGlvbiksIGFuZCBpbmNhcGFibGUgb2Yg c2VjdXJlCiAgICAgICAgICAgICAgY2xpZW50IGF1dGhlbnRpY2F0aW9uIHZpYSBhbnkgb3RoZXIg bWVhbnMuCiAgICAgICAgICAgIAo8L2RkPgo8L2RsPjwvYmxvY2txdW90ZT48cD4KICAgICAgICAK PC9wPgo8cD4KICAgICAgICAgIFRoZSBjbGllbnQgdHlwZSBkZXNpZ25hdGlvbiBpcyBiYXNlZCBv biB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIncyBkZWZpbml0aW9uIG9mIHNlY3VyZQogICAgICAg ICAgYXV0aGVudGljYXRpb24gYW5kIGl0cyBhY2NlcHRhYmxlIGV4cG9zdXJlIGxldmVscyBvZiBj bGllbnQgY3JlZGVudGlhbHMuIFRoZQogICAgICAgICAgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgU0hP VUxEIE5PVCBtYWtlIGFzc3VtcHRpb25zIGFib3V0IHRoZSBjbGllbnQgdHlwZS4KICAgICAgICAK PC9wPgo8cD4KICAgICAgICAgIEEgY2xpZW50IG1heSBiZSBpbXBsZW1lbnRlZCBhcyBhIGRpc3Ry aWJ1dGVkIHNldCBvZiBjb21wb25lbnRzLCBlYWNoIHdpdGggYSBkaWZmZXJlbnQKICAgICAgICAg IGNsaWVudCB0eXBlIGFuZCBzZWN1cml0eSBjb250ZXh0IChlLmcuIGEgZGlzdHJpYnV0ZWQgY2xp ZW50IHdpdGggYm90aCBhIGNvbmZpZGVudGlhbAogICAgICAgICAgc2VydmVyLWJhc2VkIGNvbXBv bmVudCBhbmQgYSBwdWJsaWMgYnJvd3Nlci1iYXNlZCBjb21wb25lbnQpLiBJZiB0aGUgYXV0aG9y aXphdGlvbiBzZXJ2ZXIKICAgICAgICAgIGRvZXMgbm90IHByb3ZpZGUgc3VwcG9ydCBmb3Igc3Vj aCBjbGllbnRzLCBvciBkb2VzIG5vdCBwcm92aWRlIGd1aWRhbmNlIHdpdGggcmVnYXJkIHRvCiAg ICAgICAgICB0aGVpciByZWdpc3RyYXRpb24sIHRoZSBjbGllbnQgU0hPVUxEIHJlZ2lzdGVyIGVh Y2ggY29tcG9uZW50IGFzIGEgc2VwYXJhdGUgY2xpZW50LgogICAgICAgIAo8L3A+CjxwPgogICAg ICAgICAgVGhpcyBzcGVjaWZpY2F0aW9uIGhhcyBiZWVuIGRlc2lnbmVkIGFyb3VuZCB0aGUgZm9s bG93aW5nIGNsaWVudCBwcm9maWxlczoKICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgIDwvcD4K PGJsb2NrcXVvdGUgY2xhc3M9InRleHQiPjxkbD4KPGR0PndlYiBhcHBsaWNhdGlvbjwvZHQ+Cjxk ZD4KICAgICAgICAgICAgICAKICAgICAgICAgICAgICBBIHdlYiBhcHBsaWNhdGlvbiBpcyBhIGNv bmZpZGVudGlhbCBjbGllbnQgcnVubmluZyBvbiBhIHdlYiBzZXJ2ZXIuIFJlc291cmNlIG93bmVy cwogICAgICAgICAgICAgIGFjY2VzcyB0aGUgY2xpZW50IHZpYSBhbiBIVE1MIHVzZXIgaW50ZXJm YWNlIHJlbmRlcmVkIGluIGEgdXNlci1hZ2VudCBvbiB0aGUgZGV2aWNlCiAgICAgICAgICAgICAg dXNlZCBieSB0aGUgcmVzb3VyY2Ugb3duZXIuIFRoZSBjbGllbnQgY3JlZGVudGlhbHMgYXMgd2Vs bCBhcyBhbnkgYWNjZXNzIHRva2VuIGlzc3VlZAogICAgICAgICAgICAgIHRvIHRoZSBjbGllbnQg YXJlIHN0b3JlZCBvbiB0aGUgd2ViIHNlcnZlciBhbmQgYXJlIG5vdCBleHBvc2VkIHRvIG9yIGFj Y2Vzc2libGUgYnkKICAgICAgICAgICAgICB0aGUgcmVzb3VyY2Ugb3duZXIuCiAgICAgICAgICAg IAo8L2RkPgo8ZHQ+dXNlci1hZ2VudC1iYXNlZCBhcHBsaWNhdGlvbjwvZHQ+CjxkZD4KICAgICAg ICAgICAgICAKICAgICAgICAgICAgICBBIHVzZXItYWdlbnQtYmFzZWQgYXBwbGljYXRpb24gaXMg YSBwdWJsaWMgY2xpZW50IGluIHdoaWNoIHRoZSBjbGllbnQgY29kZSBpcwogICAgICAgICAgICAg IGRvd25sb2FkZWQgZnJvbSBhIHdlYiBzZXJ2ZXIgYW5kIGV4ZWN1dGVzIHdpdGhpbiBhIHVzZXIt YWdlbnQgKGUuZy4gd2ViIGJyb3dzZXIpIG9uCiAgICAgICAgICAgICAgdGhlIGRldmljZSB1c2Vk IGJ5IHRoZSByZXNvdXJjZSBvd25lci4gUHJvdG9jb2wgZGF0YSBhbmQgY3JlZGVudGlhbHMgYXJl IGVhc2lseQogICAgICAgICAgICAgIGFjY2Vzc2libGUgKGFuZCBvZnRlbiB2aXNpYmxlKSB0byB0 aGUgcmVzb3VyY2Ugb3duZXIuIFNpbmNlIHN1Y2ggYXBwbGljYXRpb25zIHJlc2lkZQogICAgICAg ICAgICAgIHdpdGhpbiB0aGUgdXNlci1hZ2VudCwgdGhleSBjYW4gbWFrZSBzZWFtbGVzcyB1c2Ug b2YgdGhlIHVzZXItYWdlbnQgY2FwYWJpbGl0aWVzIHdoZW4KICAgICAgICAgICAgICByZXF1ZXN0 aW5nIGF1dGhvcml6YXRpb24uCiAgICAgICAgICAgIAo8L2RkPgo8ZHQ+bmF0aXZlIGFwcGxpY2F0 aW9uPC9kdD4KPGRkPgogICAgICAgICAgICAgIAogICAgICAgICAgICAgIEEgbmF0aXZlIGFwcGxp Y2F0aW9uIGlzIGEgcHVibGljIGNsaWVudCBpbnN0YWxsZWQgYW5kIGV4ZWN1dGVkIG9uIHRoZSBk ZXZpY2UgdXNlZCBieQogICAgICAgICAgICAgIHRoZSByZXNvdXJjZSBvd25lci4gUHJvdG9jb2wg ZGF0YSBhbmQgY3JlZGVudGlhbHMgYXJlIGFjY2Vzc2libGUgdG8gdGhlIHJlc291cmNlCiAgICAg ICAgICAgICAgb3duZXIuIEl0IGlzIGFzc3VtZWQgdGhhdCBhbnkgY2xpZW50IGF1dGhlbnRpY2F0 aW9uIGNyZWRlbnRpYWxzIGluY2x1ZGVkIGluIHRoZQogICAgICAgICAgICAgIGFwcGxpY2F0aW9u IGNhbiBiZSBleHRyYWN0ZWQuIE9uIHRoZSBvdGhlciBoYW5kLCBkeW5hbWljYWxseSBpc3N1ZWQg Y3JlZGVudGlhbHMgc3VjaAogICAgICAgICAgICAgIGFzIGFjY2VzcyB0b2tlbnMgb3IgcmVmcmVz aCB0b2tlbnMgY2FuIHJlY2VpdmUgYW4gYWNjZXB0YWJsZSBsZXZlbCBvZiBwcm90ZWN0aW9uLiBB dCBhCiAgICAgICAgICAgICAgbWluaW11bSwgdGhlc2UgY3JlZGVudGlhbHMgYXJlIHByb3RlY3Rl ZCBmcm9tIGhvc3RpbGUgc2VydmVycyB3aXRoIHdoaWNoIHRoZQogICAgICAgICAgICAgIGFwcGxp Y2F0aW9uIG1heSBpbnRlcmFjdCB3aXRoLiBPbiBzb21lIHBsYXRmb3JtcyB0aGVzZSBjcmVkZW50 aWFscyBtaWdodCBiZSBwcm90ZWN0ZWQKICAgICAgICAgICAgICBmcm9tIG90aGVyIGFwcGxpY2F0 aW9ucyByZXNpZGluZyBvbiB0aGUgc2FtZSBkZXZpY2UuCiAgICAgICAgICAgIAo8L2RkPgo8L2Rs PjwvYmxvY2txdW90ZT48cD4KICAgICAgICAKPC9wPgo8YSBuYW1lPSJjbGllbnQtaWRlbnRpZmll ciI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0i MCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBj bGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3Ry PjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLjIuMiI+PC9hPjxoMz4yLjIuJm5ic3A7CkNs aWVudCBJZGVudGlmaWVyPC9oMz4KCjxwPgogICAgICAgICAgVGhlIGF1dGhvcml6YXRpb24gc2Vy dmVyIGlzc3VlcyB0aGUgcmVnaXN0ZXJlZCBjbGllbnQgYSBjbGllbnQgaWRlbnRpZmllciAtIGEg dW5pcXVlCiAgICAgICAgICBzdHJpbmcgcmVwcmVzZW50aW5nIHRoZSByZWdpc3RyYXRpb24gaW5m b3JtYXRpb24gcHJvdmlkZWQgYnkgdGhlIGNsaWVudC4gVGhlIGNsaWVudAogICAgICAgICAgaWRl bnRpZmllciBpcyBub3QgYSBzZWNyZXQ7IGl0IGlzIGV4cG9zZWQgdG8gdGhlIHJlc291cmNlIG93 bmVyLCBhbmQgTVVTVCBOT1QgYmUgdXNlZAogICAgICAgICAgYWxvbmUgZm9yIGNsaWVudCBhdXRo ZW50aWNhdGlvbi4gVGhlIGNsaWVudCBpZGVudGlmaWVyIGlzIHVuaXF1ZSB0byB0aGUgYXV0aG9y aXphdGlvbgogICAgICAgICAgc2VydmVyLgogICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgVGhl IGNsaWVudCBpZGVudGlmaWVyIHN0cmluZyBzaXplIGlzIGxlZnQgdW5kZWZpbmVkIGJ5IHRoaXMg c3BlY2lmaWNhdGlvbi4gVGhlIGNsaWVudAogICAgICAgICAgc2hvdWxkIGF2b2lkIG1ha2luZyBh c3N1bXB0aW9ucyBhYm91dCB0aGUgaWRlbnRpZmllciBzaXplLiAgVGhlIGF1dGhvcml6YXRpb24g c2VydmVyCiAgICAgICAgICBTSE9VTEQgZG9jdW1lbnQgdGhlIHNpemUgb2YgYW55IGlkZW50aWZp ZXIgaXQgaXNzdWVzLgogICAgICAgIAo8L3A+CjxhIG5hbWU9ImNsaWVudC1hdXRoZW50aWNhdGlv biI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0i MCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBj bGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3Ry PjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLjIuMyI+PC9hPjxoMz4yLjMuJm5ic3A7CkNs aWVudCBBdXRoZW50aWNhdGlvbjwvaDM+Cgo8cD4KICAgICAgICAgIElmIHRoZSBjbGllbnQgdHlw ZSBpcyBjb25maWRlbnRpYWwsIHRoZSBjbGllbnQgYW5kIGF1dGhvcml6YXRpb24gc2VydmVyIGVz dGFibGlzaCBhIGNsaWVudAogICAgICAgICAgYXV0aGVudGljYXRpb24gbWV0aG9kIHN1aXRhYmxl IGZvciB0aGUgc2VjdXJpdHkgcmVxdWlyZW1lbnRzIG9mIHRoZSBhdXRob3JpemF0aW9uIHNlcnZl ci4KICAgICAgICAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBNQVkgYWNjZXB0IGFueSBmb3Jt IG9mIGNsaWVudCBhdXRoZW50aWNhdGlvbiBtZWV0aW5nIGl0cwogICAgICAgICAgc2VjdXJpdHkg cmVxdWlyZW1lbnRzLgogICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgQ29uZmlkZW50aWFsIGNs aWVudHMgYXJlIHR5cGljYWxseSBpc3N1ZWQgKG9yIGVzdGFibGlzaCkgYSBzZXQgb2YgY2xpZW50 IGNyZWRlbnRpYWxzIHVzZWQgZm9yCiAgICAgICAgICBhdXRoZW50aWNhdGluZyB3aXRoIHRoZSBh dXRob3JpemF0aW9uIHNlcnZlciAoZS5nLiBwYXNzd29yZCwgcHVibGljL3ByaXZhdGUga2V5IHBh aXIpLgogICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVy IE1BWSBlc3RhYmxpc2ggYSBjbGllbnQgYXV0aGVudGljYXRpb24gbWV0aG9kIHdpdGggcHVibGlj IGNsaWVudHMuCiAgICAgICAgICBIb3dldmVyLCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVT VCBOT1QgcmVseSBvbiBwdWJsaWMgY2xpZW50IGF1dGhlbnRpY2F0aW9uIGZvciB0aGUKICAgICAg ICAgIHB1cnBvc2Ugb2YgaWRlbnRpZnlpbmcgdGhlIGNsaWVudC4KICAgICAgICAKPC9wPgo8cD4K ICAgICAgICAgIFRoZSBjbGllbnQgTVVTVCBOT1QgdXNlIG1vcmUgdGhhbiBvbmUgYXV0aGVudGlj YXRpb24gbWV0aG9kIGluIGVhY2ggcmVxdWVzdC4KICAgICAgICAKPC9wPgo8YSBuYW1lPSJjbGll bnQtcGFzc3dvcmQiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2Vs bHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQi Pjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9h PjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi4yLjMuMSI+PC9hPjxoMz4y LjMuMS4mbmJzcDsKQ2xpZW50IFBhc3N3b3JkPC9oMz4KCjxwPgogICAgICAgICAgICBDbGllbnRz IGluIHBvc3Nlc3Npb24gb2YgYSBjbGllbnQgcGFzc3dvcmQgTUFZIHVzZSB0aGUgSFRUUCBCYXNp YyBhdXRoZW50aWNhdGlvbiBzY2hlbWUKICAgICAgICAgICAgYXMgZGVmaW5lZCBpbiA8YSBjbGFz cz0naW5mbycgaHJlZj0nI1JGQzI2MTcnPltSRkMyNjE3XTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNs YXNzPSdpbmZvJz5GcmFua3MsIEouLCBIYWxsYW0tQmFrZXIsIFAuLCBIb3N0ZXRsZXIsIEouLCBM YXdyZW5jZSwgUy4sIExlYWNoLCBQLiwgTHVvdG9uZW4sIEEuLCBhbmQgTC4gU3Rld2FydCwgJmxk cXVvO0hUVFAgQXV0aGVudGljYXRpb246IEJhc2ljIGFuZCBEaWdlc3QgQWNjZXNzIEF1dGhlbnRp Y2F0aW9uLCZyZHF1bzsgSnVuZSZuYnNwOzE5OTkuPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPiB0 byBhdXRoZW50aWNhdGUgd2l0aCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIuCiAgICAgICAgICAg IFRoZSBjbGllbnQgaWRlbnRpZmllciBpcyB1c2VkIGFzIHRoZSB1c2VybmFtZSwgYW5kIHRoZSBj bGllbnQgcGFzc3dvcmQgaXMgdXNlZCBhcyB0aGUKICAgICAgICAgICAgcGFzc3dvcmQuIFRoZSBh dXRob3JpemF0aW9uIHNlcnZlciBNVVNUIHN1cHBvcnQgdGhlIEhUVFAgQmFzaWMgYXV0aGVudGlj YXRpb24gc2NoZW1lCiAgICAgICAgICAgIGZvciBhdXRoZW50aWNhdGluZyBjbGllbnRzIHdoaWNo IHdlcmUgaXNzdWVkIGEgY2xpZW50IHBhc3N3b3JkLgogICAgICAgICAgCjwvcD4KPHA+CiAgICAg ICAgICAgICAgRm9yIGV4YW1wbGUgKGV4dHJhIGxpbmUgYnJlYWtzIGFyZSBmb3IgZGlzcGxheSBw dXJwb3NlcyBvbmx5KToKICAgICAgICAgICAgCjwvcD48ZGl2IHN0eWxlPSdkaXNwbGF5OiB0YWJs ZTsgd2lkdGg6IDA7IG1hcmdpbi1sZWZ0OiAzZW07IG1hcmdpbi1yaWdodDogYXV0byc+PHByZT4K CiAgQXV0aG9yaXphdGlvbjogQmFzaWMgY3paQ2FHUlNhM0YwTXpvM1JtcG1jREJhUW5JeFMzUkVV bUp1Wmxaa2JVbDMKCjwvcHJlPjwvZGl2Pgo8cD4KICAgICAgICAgICAgQWx0ZXJuYXRpdmVseSwg dGhlIGF1dGhvcml6YXRpb24gc2VydmVyIE1BWSBzdXBwb3J0IGluY2x1ZGluZyB0aGUgY2xpZW50 IGNyZWRlbnRpYWxzIGluCiAgICAgICAgICAgIHRoZSByZXF1ZXN0IGJvZHkgdXNpbmcgdGhlIGZv bGxvd2luZyBwYXJhbWV0ZXJzOgogICAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICAgIDwvcD4K PGJsb2NrcXVvdGUgY2xhc3M9InRleHQiPjxkbD4KPGR0PmNsaWVudF9pZDwvZHQ+CjxkZD4KICAg ICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgUkVRVUlSRUQuIFRoZSBjbGllbnQgaWRlbnRp ZmllciBpc3N1ZWQgdG8gdGhlIGNsaWVudCBkdXJpbmcgdGhlIHJlZ2lzdHJhdGlvbiBwcm9jZXNz CiAgICAgICAgICAgICAgICBkZXNjcmliZWQgYnkgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNjbGll bnQtaWRlbnRpZmllcic+U2VjdGlvbiZuYnNwOzIuMjxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNz PSdpbmZvJz5DbGllbnQgSWRlbnRpZmllcjwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4uCiAgICAg ICAgICAgICAgCjwvZGQ+CjxkdD5jbGllbnRfc2VjcmV0PC9kdD4KPGRkPgogICAgICAgICAgICAg ICAgCiAgICAgICAgICAgICAgICBSRVFVSVJFRC4gVGhlIGNsaWVudCBzZWNyZXQuIFRoZSBjbGll bnQgTUFZIG9taXQgdGhlIHBhcmFtZXRlciBpZiB0aGUgY2xpZW50IHNlY3JldAogICAgICAgICAg ICAgICAgaXMgYW4gZW1wdHkgc3RyaW5nLgogICAgICAgICAgICAgIAo8L2RkPgo8L2RsPjwvYmxv Y2txdW90ZT48cD4KICAgICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgICBJbmNsdWRpbmcgdGhl IGNsaWVudCBjcmVkZW50aWFscyBpbiB0aGUgcmVxdWVzdCBib2R5IHVzaW5nIHRoZSB0d28gcGFy YW1ldGVycyBpcyBOT1QKICAgICAgICAgICAgUkVDT01NRU5ERUQsIGFuZCBTSE9VTEQgYmUgbGlt aXRlZCB0byBjbGllbnRzIHVuYWJsZSB0byBkaXJlY3RseSB1dGlsaXplIHRoZSBIVFRQIEJhc2lj CiAgICAgICAgICAgIGF1dGhlbnRpY2F0aW9uIHNjaGVtZSAob3Igb3RoZXIgcGFzc3dvcmQtYmFz ZWQgSFRUUCBhdXRoZW50aWNhdGlvbiBzY2hlbWVzKS4gVGhlCiAgICAgICAgICAgIHBhcmFtZXRl cnMgY2FuIG9ubHkgYmUgdHJhbnNtaXR0ZWQgaW4gdGhlIHJlcXVlc3QgYm9keSBhbmQgTVVTVCBO T1QgYmUgaW5jbHVkZWQgaW4gdGhlCiAgICAgICAgICAgIHJlcXVlc3QgVVJJLgogICAgICAgICAg CjwvcD4KPHA+CiAgICAgICAgICAgICAgRm9yIGV4YW1wbGUsIHJlcXVlc3RpbmcgdG8gcmVmcmVz aCBhbiBhY2Nlc3MgdG9rZW4gKDxhIGNsYXNzPSdpbmZvJyBocmVmPScjdG9rZW4tcmVmcmVzaCc+ U2VjdGlvbiZuYnNwOzY8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+UmVmcmVzaGlu ZyBhbiBBY2Nlc3MgVG9rZW48L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+KQogICAgICAgICAgICAg IHVzaW5nIHRoZSBib2R5IHBhcmFtZXRlcnMgKGV4dHJhIGxpbmUgYnJlYWtzIGFyZSBmb3IgZGlz cGxheSBwdXJwb3NlcyBvbmx5KToKICAgICAgICAgICAgCjwvcD48ZGl2IHN0eWxlPSdkaXNwbGF5 OiB0YWJsZTsgd2lkdGg6IDA7IG1hcmdpbi1sZWZ0OiAzZW07IG1hcmdpbi1yaWdodDogYXV0byc+ PHByZT4KCiAgUE9TVCAvdG9rZW4gSFRUUC8xLjEKICBIb3N0OiBzZXJ2ZXIuZXhhbXBsZS5jb20K ICBDb250ZW50LVR5cGU6IGFwcGxpY2F0aW9uL3gtd3d3LWZvcm0tdXJsZW5jb2RlZDtjaGFyc2V0 PVVURi04CgogIGdyYW50X3R5cGU9cmVmcmVzaF90b2tlbiZhbXA7cmVmcmVzaF90b2tlbj10R3p2 M0pPa0YwWEc1UXgyVGxLV0lBCiAgJmFtcDtjbGllbnRfaWQ9czZCaGRSa3F0MyZhbXA7Y2xpZW50 X3NlY3JldD03RmpmcDBaQnIxS3REUmJuZlZkbUl3Cgo8L3ByZT48L2Rpdj4KPHA+CiAgICAgICAg ICAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBNVVNUIHJlcXVpcmUgdGhlIHVzZSBvZiBUTFMg YXMgZGVzY3JpYmVkIGluCiAgICAgICAgICAgIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjdGxzJz5T ZWN0aW9uJm5ic3A7MS42PHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPlRMUyBWZXJz aW9uPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPiB3aGVuIHNlbmRpbmcgcmVxdWVzdHMgdXNpbmcg cGFzc3dvcmQgYXV0aGVudGljYXRpb24uCiAgICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgICAg U2luY2UgdGhpcyBjbGllbnQgYXV0aGVudGljYXRpb24gbWV0aG9kIGludm9sdmVzIGEgcGFzc3dv cmQsIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlcgogICAgICAgICAgICBNVVNUIHByb3RlY3QgYW55 IGVuZHBvaW50IHV0aWxpemluZyBpdCBhZ2FpbnN0IGJydXRlIGZvcmNlIGF0dGFja3MuCiAgICAg ICAgICAKPC9wPgo8YSBuYW1lPSJhbmNob3IxNSI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3Vt bWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0Ni dWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4m bmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9u LjIuMy4yIj48L2E+PGgzPjIuMy4yLiZuYnNwOwpPdGhlciBBdXRoZW50aWNhdGlvbiBNZXRob2Rz PC9oMz4KCjxwPgogICAgICAgICAgICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTUFZIHN1cHBv cnQgYW55IHN1aXRhYmxlIEhUVFAgYXV0aGVudGljYXRpb24gc2NoZW1lIG1hdGNoaW5nCiAgICAg ICAgICAgIGl0cyBzZWN1cml0eSByZXF1aXJlbWVudHMuIFdoZW4gdXNpbmcgb3RoZXIgYXV0aGVu dGljYXRpb24gbWV0aG9kcywgdGhlIGF1dGhvcml6YXRpb24KICAgICAgICAgICAgc2VydmVyIE1V U1QgZGVmaW5lIGEgbWFwcGluZyBiZXR3ZWVuIHRoZSBjbGllbnQgaWRlbnRpZmllciAocmVnaXN0 cmF0aW9uIHJlY29yZCkgYW5kCiAgICAgICAgICAgIGF1dGhlbnRpY2F0aW9uIHNjaGVtZS4KICAg ICAgICAgIAo8L3A+CjxhIG5hbWU9ImFuY2hvcjE2Ij48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBz dW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRP Q2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2Mi PiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rp b24uMi40Ij48L2E+PGgzPjIuNC4mbmJzcDsKVW5yZWdpc3RlcmVkIENsaWVudHM8L2gzPgoKPHA+ CiAgICAgICAgICBUaGlzIHNwZWNpZmljYXRpb24gZG9lcyBub3QgZXhjbHVkZSB0aGUgdXNlIG9m IHVucmVnaXN0ZXJlZCBjbGllbnRzLiBIb3dldmVyLCB0aGUgdXNlCiAgICAgICAgICB3aXRoIHN1 Y2ggY2xpZW50cyBpcyBiZXlvbmQgdGhlIHNjb3BlIG9mIHRoaXMgc3BlY2lmaWNhdGlvbiwgYW5k IHJlcXVpcmVzIGFkZGl0aW9uYWwKICAgICAgICAgIHNlY3VyaXR5IGFuYWx5c2lzIGFuZCByZXZp ZXcgb2YgaXRzIGludGVyb3BlcmFiaWxpdHkgaW1wYWN0LgogICAgICAgIAo8L3A+CjxhIG5hbWU9 ImFuY2hvcjE3Ij48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxw YWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48 dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48 L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uMyI+PC9hPjxoMz4zLiZuYnNw OwpQcm90b2NvbCBFbmRwb2ludHM8L2gzPgoKPHA+CiAgICAgICAgVGhlIGF1dGhvcml6YXRpb24g cHJvY2VzcyB1dGlsaXplcyB0d28gYXV0aG9yaXphdGlvbiBzZXJ2ZXIgZW5kcG9pbnRzIChIVFRQ IHJlc291cmNlcyk6CiAgICAgIAo8L3A+CjxwPgogICAgICAgIDwvcD4KPHVsIGNsYXNzPSJ0ZXh0 Ij4KPGxpPgogICAgICAgICAgICBBdXRob3JpemF0aW9uIGVuZHBvaW50IC0gdXNlZCBieSB0aGUg Y2xpZW50IHRvIG9idGFpbiBhdXRob3JpemF0aW9uIGZyb20gdGhlIHJlc291cmNlCiAgICAgICAg ICAgIG93bmVyIHZpYSB1c2VyLWFnZW50IHJlZGlyZWN0aW9uLgogICAgICAgICAgCjwvbGk+Cjxs aT4KICAgICAgICAgICAgVG9rZW4gZW5kcG9pbnQgLSB1c2VkIGJ5IHRoZSBjbGllbnQgdG8gZXhj aGFuZ2UgYW4gYXV0aG9yaXphdGlvbiBncmFudCBmb3IgYW4gYWNjZXNzCiAgICAgICAgICAgIHRv a2VuLCB0eXBpY2FsbHkgd2l0aCBjbGllbnQgYXV0aGVudGljYXRpb24uCiAgICAgICAgICAKPC9s aT4KPC91bD48cD4KICAgICAgCjwvcD4KPHA+CiAgICAgICAgQXMgd2VsbCBhcyBvbmUgY2xpZW50 IGVuZHBvaW50OgogICAgICAKPC9wPgo8cD4KICAgICAgICA8L3A+Cjx1bCBjbGFzcz0idGV4dCI+ CjxsaT4KICAgICAgICAgICAgUmVkaXJlY3Rpb24gZW5kcG9pbnQgLSB1c2VkIGJ5IHRoZSBhdXRo b3JpemF0aW9uIHNlcnZlciB0byByZXR1cm4gYXV0aG9yaXphdGlvbgogICAgICAgICAgICBjcmVk ZW50aWFscyByZXNwb25zZXMgdG8gdGhlIGNsaWVudCB2aWEgdGhlIHJlc291cmNlIG93bmVyIHVz ZXItYWdlbnQuCiAgICAgICAgICAKPC9saT4KPC91bD48cD4KICAgICAgCjwvcD4KPHA+CiAgICAg ICAgTm90IGV2ZXJ5IGF1dGhvcml6YXRpb24gZ3JhbnQgdHlwZSB1dGlsaXplcyBib3RoIGVuZHBv aW50cy4gRXh0ZW5zaW9uIGdyYW50IHR5cGVzIE1BWQogICAgICAgIGRlZmluZSBhZGRpdGlvbmFs IGVuZHBvaW50cyBhcyBuZWVkZWQuCiAgICAgIAo8L3A+CjxhIG5hbWU9ImFuY2hvcjE4Ij48L2E+ PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxs c3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJU T0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJs ZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uMy4xIj48L2E+PGgzPjMuMS4mbmJzcDsKQXV0aG9yaXph dGlvbiBFbmRwb2ludDwvaDM+Cgo8cD4KICAgICAgICAgIFRoZSBhdXRob3JpemF0aW9uIGVuZHBv aW50IGlzIHVzZWQgdG8gaW50ZXJhY3Qgd2l0aCB0aGUgcmVzb3VyY2Ugb3duZXIgYW5kIG9idGFp bgogICAgICAgICAgYW4gYXV0aG9yaXphdGlvbiBncmFudC4gVGhlIGF1dGhvcml6YXRpb24gc2Vy dmVyIE1VU1QgZmlyc3QgdmVyaWZ5IHRoZSBpZGVudGl0eSBvZiB0aGUKICAgICAgICAgIHJlc291 cmNlIG93bmVyLiBUaGUgd2F5IGluIHdoaWNoIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBhdXRo ZW50aWNhdGVzIHRoZSByZXNvdXJjZQogICAgICAgICAgb3duZXIgKGUuZy4gdXNlcm5hbWUgYW5k IHBhc3N3b3JkIGxvZ2luLCBzZXNzaW9uIGNvb2tpZXMpIGlzIGJleW9uZCB0aGUgc2NvcGUgb2Yg dGhpcwogICAgICAgICAgc3BlY2lmaWNhdGlvbi4KICAgICAgICAKPC9wPgo8cD4KICAgICAgICAg IFRoZSBtZWFucyB0aHJvdWdoIHdoaWNoIHRoZSBjbGllbnQgb2J0YWlucyB0aGUgbG9jYXRpb24g b2YgdGhlIGF1dGhvcml6YXRpb24gZW5kcG9pbnQgYXJlCiAgICAgICAgICBiZXlvbmQgdGhlIHNj b3BlIG9mIHRoaXMgc3BlY2lmaWNhdGlvbiwgYnV0IHRoZSBsb2NhdGlvbiBpcyB0eXBpY2FsbHkg cHJvdmlkZWQgaW4gdGhlCiAgICAgICAgICBzZXJ2aWNlIGRvY3VtZW50YXRpb24uCiAgICAgICAg CjwvcD4KPHA+CiAgICAgICAgICBUaGUgZW5kcG9pbnQgVVJJIE1BWSBpbmNsdWRlIGFuCiAgICAg ICAgICA8dHQ+YXBwbGljYXRpb24veC13d3ctZm9ybS11cmxlbmNvZGVkPC90dD4gZm9ybWF0dGVk CiAgICAgICAgICAoPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNXM0MuUkVDLWh0bWw0MDEtMTk5OTEy MjQnPltXM0MuUkVDJiM4MjA5O2h0bWw0MDEmIzgyMDk7MTk5OTEyMjRdPHNwYW4+ICg8L3NwYW4+ PHNwYW4gY2xhc3M9J2luZm8nPkhvcnMsIEEuLCBSYWdnZXR0LCBELiwgYW5kIEkuIEphY29icywg JmxkcXVvO0hUTUwgNC4wMSBTcGVjaWZpY2F0aW9uLCZyZHF1bzsgRGVjZW1iZXImbmJzcDsxOTk5 Ljwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4pIHF1ZXJ5IGNvbXBvbmVudCAoPGEgY2xhc3M9J2lu Zm8nIGhyZWY9JyNSRkMzOTg2Jz5bUkZDMzk4Nl08c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0n aW5mbyc+QmVybmVycy1MZWUsIFQuLCBGaWVsZGluZywgUi4sIGFuZCBMLiBNYXNpbnRlciwgJmxk cXVvO1VuaWZvcm0gUmVzb3VyY2UgSWRlbnRpZmllciAoVVJJKTogR2VuZXJpYyBTeW50YXgsJnJk cXVvOyBKYW51YXJ5Jm5ic3A7MjAwNS48L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+CiAgICAgICAg ICBzZWN0aW9uIDMuNCksIHdoaWNoIE1VU1QgYmUgcmV0YWluZWQgd2hlbiBhZGRpbmcgYWRkaXRp b25hbCBxdWVyeSBwYXJhbWV0ZXJzLiBUaGUKICAgICAgICAgIGVuZHBvaW50IFVSSSBNVVNUIE5P VCBpbmNsdWRlIGEgZnJhZ21lbnQgY29tcG9uZW50LgogICAgICAgIAo8L3A+CjxwPgogICAgICAg ICAgU2luY2UgcmVxdWVzdHMgdG8gdGhlIGF1dGhvcml6YXRpb24gZW5kcG9pbnQgcmVzdWx0IGlu IHVzZXIgYXV0aGVudGljYXRpb24gYW5kIHRoZQogICAgICAgICAgdHJhbnNtaXNzaW9uIG9mIGNs ZWFyLXRleHQgY3JlZGVudGlhbHMgKGluIHRoZSBIVFRQIHJlc3BvbnNlKSwgdGhlIGF1dGhvcml6 YXRpb24gc2VydmVyCiAgICAgICAgICBNVVNUIHJlcXVpcmUgdGhlIHVzZSBvZiBUTFMgYXMgZGVz Y3JpYmVkIGluIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjdGxzJz5TZWN0aW9uJm5ic3A7MS42PHNw YW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPlRMUyBWZXJzaW9uPC9zcGFuPjxzcGFuPik8 L3NwYW4+PC9hPiB3aGVuIHNlbmRpbmcgcmVxdWVzdHMKICAgICAgICAgIHRvIHRoZSBhdXRob3Jp emF0aW9uIGVuZHBvaW50LgogICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgVGhlIGF1dGhvcml6 YXRpb24gc2VydmVyIE1VU1Qgc3VwcG9ydCB0aGUgdXNlIG9mIHRoZSBIVFRQIDx0dD5HRVQ8L3R0 PgogICAgICAgICAgbWV0aG9kIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjUkZDMjYxNic+W1JGQzI2 MTZdPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkZpZWxkaW5nLCBSLiwgR2V0dHlz LCBKLiwgTW9ndWwsIEouLCBGcnlzdHlrLCBILiwgTWFzaW50ZXIsIEwuLCBMZWFjaCwgUC4sIGFu ZCBULiBCZXJuZXJzLUxlZSwgJmxkcXVvO0h5cGVydGV4dCBUcmFuc2ZlciBQcm90b2NvbCAtLSBI VFRQLzEuMSwmcmRxdW87IEp1bmUmbmJzcDsxOTk5Ljwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4g Zm9yIHRoZSBhdXRob3JpemF0aW9uIGVuZHBvaW50LCBhbmQgTUFZIHN1cHBvcnQgdGhlIHVzZQog ICAgICAgICAgb2YgdGhlIDx0dD5QT1NUPC90dD4gbWV0aG9kIGFzIHdlbGwuCiAgICAgICAgCjwv cD4KPHA+CiAgICAgICAgICBQYXJhbWV0ZXJzIHNlbnQgd2l0aG91dCBhIHZhbHVlIE1VU1QgYmUg dHJlYXRlZCBhcyBpZiB0aGV5IHdlcmUgb21pdHRlZCBmcm9tIHRoZSByZXF1ZXN0LgogICAgICAg ICAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIE1VU1QgaWdub3JlIHVucmVjb2duaXplZCByZXF1 ZXN0IHBhcmFtZXRlcnMuIFJlcXVlc3QgYW5kCiAgICAgICAgICByZXNwb25zZSBwYXJhbWV0ZXJz IE1VU1QgTk9UIGJlIGluY2x1ZGVkIG1vcmUgdGhhbiBvbmNlLgogICAgICAgIAo8L3A+CjxhIG5h bWU9InJlc3BvbnNlLXR5cGUiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91 dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0i cmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5i c3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi4zLjEuMSI+PC9h PjxoMz4zLjEuMS4mbmJzcDsKUmVzcG9uc2UgVHlwZTwvaDM+Cgo8cD4KICAgICAgICAgICAgVGhl IGF1dGhvcml6YXRpb24gZW5kcG9pbnQgaXMgdXNlZCBieSB0aGUgYXV0aG9yaXphdGlvbiBjb2Rl IGdyYW50IHR5cGUgYW5kIGltcGxpY2l0CiAgICAgICAgICAgIGdyYW50IHR5cGUgZmxvd3MuIFRo ZSBjbGllbnQgaW5mb3JtcyB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgb2YgdGhlIGRlc2lyZWQg Z3JhbnQKICAgICAgICAgICAgdHlwZSB1c2luZyB0aGUgZm9sbG93aW5nIHBhcmFtZXRlcjoKICAg ICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgICA8L3A+CjxibG9ja3F1b3RlIGNsYXNzPSJ0ZXh0 Ij48ZGw+CjxkdD5yZXNwb25zZV90eXBlPC9kdD4KPGRkPgogICAgICAgICAgICAgICAgCiAgICAg ICAgICAgICAgICBSRVFVSVJFRC4gVGhlIHZhbHVlIE1VU1QgYmUgb25lIG9mIDx0dD5jb2RlPC90 dD4gZm9yIHJlcXVlc3RpbmcKICAgICAgICAgICAgICAgIGFuIGF1dGhvcml6YXRpb24gY29kZSBh cyBkZXNjcmliZWQgYnkgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNjb2RlLWF1dGh6LXJlcSc+U2Vj dGlvbiZuYnNwOzQuMS4xPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkF1dGhvcml6 YXRpb24gUmVxdWVzdDwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4sCiAgICAgICAgICAgICAgICA8 dHQ+dG9rZW48L3R0PiBmb3IgcmVxdWVzdGluZyBhbiBhY2Nlc3MgdG9rZW4gKGltcGxpY2l0IGdy YW50KQogICAgICAgICAgICAgICAgYXMgZGVzY3JpYmVkIGJ5IDxhIGNsYXNzPSdpbmZvJyBocmVm PScjaW1wbGljaXQtYXV0aHotcmVxJz5TZWN0aW9uJm5ic3A7NC4yLjE8c3Bhbj4gKDwvc3Bhbj48 c3BhbiBjbGFzcz0naW5mbyc+QXV0aG9yaXphdGlvbiBSZXF1ZXN0PC9zcGFuPjxzcGFuPik8L3Nw YW4+PC9hPiwgb3IgYSByZWdpc3RlcmVkIGV4dGVuc2lvbgogICAgICAgICAgICAgICAgdmFsdWUg YXMgZGVzY3JpYmVkIGJ5IDxhIGNsYXNzPSdpbmZvJyBocmVmPScjcmVzcG9uc2UtdHlwZS1leHQn PlNlY3Rpb24mbmJzcDs4LjQ8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+RGVmaW5p bmcgTmV3IEF1dGhvcml6YXRpb24gRW5kcG9pbnQgUmVzcG9uc2UgVHlwZXM8L3NwYW4+PHNwYW4+ KTwvc3Bhbj48L2E+LgogICAgICAgICAgICAgIAo8L2RkPgo8L2RsPjwvYmxvY2txdW90ZT48cD4K ICAgICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgICBFeHRlbnNpb24gcmVzcG9uc2UgdHlwZXMg TUFZIGNvbnRhaW4gYSBzcGFjZS1kZWxpbWl0ZWQgKCV4MjApIGxpc3Qgb2YgdmFsdWVzLCB3aGVy ZSB0aGUKICAgICAgICAgICAgb3JkZXIgb2YgdmFsdWVzIGRvZXMgbm90IG1hdHRlciAoZS5nLiBy ZXNwb25zZSB0eXBlIDx0dD5hIGI8L3R0PiBpcwogICAgICAgICAgICB0aGUgc2FtZSBhcyA8dHQ+ YiBhPC90dD4pLiBUaGUgbWVhbmluZyBvZiBzdWNoIGNvbXBvc2l0ZSByZXNwb25zZQogICAgICAg ICAgICB0eXBlcyBpcyBkZWZpbmVkIGJ5IHRoZWlyIHJlc3BlY3RpdmUgc3BlY2lmaWNhdGlvbnMu CiAgICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgICAgSWYgYW4gYXV0aG9yaXphdGlvbiByZXF1 ZXN0IGlzIG1pc3NpbmcgdGhlIDx0dD5yZXNwb25zZV90eXBlPC90dD4KICAgICAgICAgICAgcGFy YW1ldGVyLCBvciBpZiB0aGUgcmVzcG9uc2UgdHlwZSBpcyBub3QgdW5kZXJzdG9vZCwgdGhlIGF1 dGhvcml6YXRpb24gc2VydmVyIE1VU1QKICAgICAgICAgICAgcmV0dXJuIGFuIGVycm9yIHJlc3Bv bnNlIGFzIGRlc2NyaWJlZCBpbiA8YSBjbGFzcz0naW5mbycgaHJlZj0nI2NvZGUtYXV0aHotZXJy b3InPlNlY3Rpb24mbmJzcDs0LjEuMi4xPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8n PkVycm9yIFJlc3BvbnNlPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPi4KICAgICAgICAgIAo8L3A+ CjxhIG5hbWU9InJlZGlyZWN0LXVyaSI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0i bGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFs aWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtU T0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLjMuMS4y Ij48L2E+PGgzPjMuMS4yLiZuYnNwOwpSZWRpcmVjdGlvbiBFbmRwb2ludDwvaDM+Cgo8cD4KICAg ICAgICAgICAgQWZ0ZXIgY29tcGxldGluZyBpdHMgaW50ZXJhY3Rpb24gd2l0aCB0aGUgcmVzb3Vy Y2Ugb3duZXIsIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlcgogICAgICAgICAgICBkaXJlY3RzIHRo ZSByZXNvdXJjZSBvd25lcidzIHVzZXItYWdlbnQgYmFjayB0byB0aGUgY2xpZW50LiBUaGUgYXV0 aG9yaXphdGlvbiBzZXJ2ZXIKICAgICAgICAgICAgcmVkaXJlY3RzIHRoZSB1c2VyLWFnZW50IHRv IHRoZSBjbGllbnQncyByZWRpcmVjdGlvbiBlbmRwb2ludCBwcmV2aW91c2x5IGVzdGFibGlzaGVk CiAgICAgICAgICAgIHdpdGggdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGR1cmluZyB0aGUgY2xp ZW50IHJlZ2lzdHJhdGlvbiBwcm9jZXNzIG9yIHdoZW4gbWFraW5nCiAgICAgICAgICAgIHRoZSBh dXRob3JpemF0aW9uIHJlcXVlc3QuCiAgICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgICAgVGhl IHJlZGlyZWN0aW9uIGVuZHBvaW50IFVSSSBNVVNUIGJlIGFuIGFic29sdXRlIFVSSSBhcyBkZWZp bmVkIGJ5CiAgICAgICAgICAgIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjUkZDMzk4Nic+W1JGQzM5 ODZdPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkJlcm5lcnMtTGVlLCBULiwgRmll bGRpbmcsIFIuLCBhbmQgTC4gTWFzaW50ZXIsICZsZHF1bztVbmlmb3JtIFJlc291cmNlIElkZW50 aWZpZXIgKFVSSSk6IEdlbmVyaWMgU3ludGF4LCZyZHF1bzsgSmFudWFyeSZuYnNwOzIwMDUuPC9z cGFuPjxzcGFuPik8L3NwYW4+PC9hPiBzZWN0aW9uIDQuMy4gVGhlIGVuZHBvaW50IFVSSSBNQVkg aW5jbHVkZSBhbgogICAgICAgICAgICA8dHQ+YXBwbGljYXRpb24veC13d3ctZm9ybS11cmxlbmNv ZGVkPC90dD4gZm9ybWF0dGVkCiAgICAgICAgICAgICg8YSBjbGFzcz0naW5mbycgaHJlZj0nI1cz Qy5SRUMtaHRtbDQwMS0xOTk5MTIyNCc+W1czQy5SRUMmIzgyMDk7aHRtbDQwMSYjODIwOTsxOTk5 MTIyNF08c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+SG9ycywgQS4sIFJhZ2dldHQs IEQuLCBhbmQgSS4gSmFjb2JzLCAmbGRxdW87SFRNTCA0LjAxIFNwZWNpZmljYXRpb24sJnJkcXVv OyBEZWNlbWJlciZuYnNwOzE5OTkuPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPikgcXVlcnkgY29t cG9uZW50ICg8YSBjbGFzcz0naW5mbycgaHJlZj0nI1JGQzM5ODYnPltSRkMzOTg2XTxzcGFuPiAo PC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5CZXJuZXJzLUxlZSwgVC4sIEZpZWxkaW5nLCBSLiwg YW5kIEwuIE1hc2ludGVyLCAmbGRxdW87VW5pZm9ybSBSZXNvdXJjZSBJZGVudGlmaWVyIChVUkkp OiBHZW5lcmljIFN5bnRheCwmcmRxdW87IEphbnVhcnkmbmJzcDsyMDA1Ljwvc3Bhbj48c3Bhbj4p PC9zcGFuPjwvYT4KICAgICAgICAgICAgc2VjdGlvbiAzLjQpLCB3aGljaCBNVVNUIGJlIHJldGFp bmVkIHdoZW4gYWRkaW5nIGFkZGl0aW9uYWwgcXVlcnkgcGFyYW1ldGVycy4gVGhlCiAgICAgICAg ICAgIGVuZHBvaW50IFVSSSBNVVNUIE5PVCBpbmNsdWRlIGEgZnJhZ21lbnQgY29tcG9uZW50Lgog ICAgICAgICAgCjwvcD4KPGEgbmFtZT0iYW5jaG9yMTkiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxl IHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0i VE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3Rv YyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2Vj dGlvbi4zLjEuMi4xIj48L2E+PGgzPjMuMS4yLjEuJm5ic3A7CkVuZHBvaW50IFJlcXVlc3QgQ29u ZmlkZW50aWFsaXR5PC9oMz4KCjxwPgogICAgICAgICAgICAgIFRoZSByZWRpcmVjdGlvbiBlbmRw b2ludCBTSE9VTEQgcmVxdWlyZSB0aGUgdXNlIG9mIFRMUyBhcyBkZXNjcmliZWQgaW4KICAgICAg ICAgICAgICA8YSBjbGFzcz0naW5mbycgaHJlZj0nI3Rscyc+U2VjdGlvbiZuYnNwOzEuNjxzcGFu PiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5UTFMgVmVyc2lvbjwvc3Bhbj48c3Bhbj4pPC9z cGFuPjwvYT4gd2hlbiB0aGUgcmVxdWVzdGVkIHJlc3BvbnNlIHR5cGUgaXMKICAgICAgICAgICAg ICA8dHQ+Y29kZTwvdHQ+IG9yIDx0dD50b2tlbjwvdHQ+LCBvcgogICAgICAgICAgICAgIHdoZW4g dGhlIHJlZGlyZWN0aW9uIHJlcXVlc3Qgd2lsbCByZXN1bHQgaW4gdGhlIHRyYW5zbWlzc2lvbiBv ZiBzZW5zaXRpdmUgY3JlZGVudGlhbHMKICAgICAgICAgICAgICBvdmVyIGFuIG9wZW4gbmV0d29y ay4gVGhpcyBzcGVjaWZpY2F0aW9uIGRvZXMgbm90IG1hbmRhdGUgdGhlIHVzZSBvZiBUTFMgYmVj YXVzZSBhdAogICAgICAgICAgICAgIHRoZSB0aW1lIG9mIHRoaXMgd3JpdGluZywgcmVxdWlyaW5n IGNsaWVudHMgdG8gZGVwbG95IFRMUyBpcyBhIHNpZ25pZmljYW50IGh1cmRsZSBmb3IKICAgICAg ICAgICAgICBtYW55IGNsaWVudCBkZXZlbG9wZXJzLiBJZiBUTFMgaXMgbm90IGF2YWlsYWJsZSwg dGhlIGF1dGhvcml6YXRpb24gc2VydmVyIFNIT1VMRCB3YXJuCiAgICAgICAgICAgICAgdGhlIHJl c291cmNlIG93bmVyIGFib3V0IHRoZSBpbnNlY3VyZSBlbmRwb2ludCBwcmlvciB0byByZWRpcmVj dGlvbiAoZS5nLiBkaXNwbGF5IGEKICAgICAgICAgICAgICBtZXNzYWdlIGR1cmluZyB0aGUgYXV0 aG9yaXphdGlvbiByZXF1ZXN0KS4KICAgICAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICAgICAg TGFjayBvZiB0cmFuc3BvcnQtbGF5ZXIgc2VjdXJpdHkgY2FuIGhhdmUgYSBzZXZlcmUgaW1wYWN0 IG9uIHRoZSBzZWN1cml0eSBvZiB0aGUKICAgICAgICAgICAgICBjbGllbnQgYW5kIHRoZSBwcm90 ZWN0ZWQgcmVzb3VyY2VzIGl0IGlzIGF1dGhvcml6ZWQgdG8gYWNjZXNzLiBUaGUgdXNlIG9mCiAg ICAgICAgICAgICAgdHJhbnNwb3J0LWxheWVyIHNlY3VyaXR5IGlzIHBhcnRpY3VsYXJseSBjcml0 aWNhbCB3aGVuIHRoZSBhdXRob3JpemF0aW9uIHByb2Nlc3MgaXMKICAgICAgICAgICAgICB1c2Vk IGFzIGEgZm9ybSBvZiBkZWxlZ2F0ZWQgZW5kLXVzZXIgYXV0aGVudGljYXRpb24gYnkgdGhlIGNs aWVudCAoZS5nLiB0aGlyZC1wYXJ0eQogICAgICAgICAgICAgIHNpZ24taW4gc2VydmljZSkuCiAg ICAgICAgICAgIAo8L3A+CjxhIG5hbWU9ImFuY2hvcjIwIj48L2E+PGJyIC8+PGhyIC8+Cjx0YWJs ZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9 IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0 b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNl Y3Rpb24uMy4xLjIuMiI+PC9hPjxoMz4zLjEuMi4yLiZuYnNwOwpSZWdpc3RyYXRpb24gUmVxdWly ZW1lbnRzPC9oMz4KCjxwPgogICAgICAgICAgICAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBN VVNUIHJlcXVpcmUgdGhlIGZvbGxvd2luZyBjbGllbnRzIHRvIHJlZ2lzdGVyIHRoZWlyCiAgICAg ICAgICAgICAgcmVkaXJlY3Rpb24gZW5kcG9pbnQ6CiAgICAgICAgICAgIAo8L3A+CjxwPgogICAg ICAgICAgICAgIDwvcD4KPHVsIGNsYXNzPSJ0ZXh0Ij4KPGxpPgogICAgICAgICAgICAgICAgICBQ dWJsaWMgY2xpZW50cy4KICAgICAgICAgICAgICAgIAo8L2xpPgo8bGk+CiAgICAgICAgICAgICAg ICAgIENvbmZpZGVudGlhbCBjbGllbnRzIHV0aWxpemluZyB0aGUgaW1wbGljaXQgZ3JhbnQgdHlw ZS4KICAgICAgICAgICAgICAgIAo8L2xpPgo8L3VsPjxwPgogICAgICAgICAgICAKPC9wPgo8cD4K ICAgICAgICAgICAgICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgU0hPVUxEIHJlcXVpcmUgYWxs IGNsaWVudHMgdG8gcmVnaXN0ZXIgdGhlaXIgcmVkaXJlY3Rpb24KICAgICAgICAgICAgICBlbmRw b2ludCBwcmlvciB0byB1dGlsaXppbmcgdGhlIGF1dGhvcml6YXRpb24gZW5kcG9pbnQuCiAgICAg ICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgICAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBT SE9VTEQgcmVxdWlyZSB0aGUgY2xpZW50IHRvIHByb3ZpZGUgdGhlIGNvbXBsZXRlCiAgICAgICAg ICAgICAgcmVkaXJlY3Rpb24gVVJJICh0aGUgY2xpZW50IE1BWSB1c2UgdGhlIDx0dD5zdGF0ZTwv dHQ+IHJlcXVlc3QKICAgICAgICAgICAgICBwYXJhbWV0ZXIgdG8gYWNoaWV2ZSBwZXItcmVxdWVz dCBjdXN0b21pemF0aW9uKS4gSWYgcmVxdWlyaW5nIHRoZSByZWdpc3RyYXRpb24gb2YKICAgICAg ICAgICAgICB0aGUgY29tcGxldGUgcmVkaXJlY3Rpb24gVVJJIGlzIG5vdCBwb3NzaWJsZSwgdGhl IGF1dGhvcml6YXRpb24gc2VydmVyIFNIT1VMRCByZXF1aXJlCiAgICAgICAgICAgICAgdGhlIHJl Z2lzdHJhdGlvbiBvZiB0aGUgVVJJIHNjaGVtZSwgYXV0aG9yaXR5LCBhbmQgcGF0aCAoYWxsb3dp bmcgdGhlIGNsaWVudCB0bwogICAgICAgICAgICAgIGR5bmFtaWNhbGx5IHZhcnkgb25seSB0aGUg cXVlcnkgY29tcG9uZW50IG9mIHRoZSByZWRpcmVjdGlvbiBVUkkgd2hlbiByZXF1ZXN0aW5nCiAg ICAgICAgICAgICAgYXV0aG9yaXphdGlvbikuCiAgICAgICAgICAgIAo8L3A+CjxwPgogICAgICAg ICAgICAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBNQVkgYWxsb3cgdGhlIGNsaWVudCB0byBy ZWdpc3RlciBtdWx0aXBsZSByZWRpcmVjdGlvbgogICAgICAgICAgICAgIGVuZHBvaW50cy4KICAg ICAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICAgICAgTGFjayBvZiBhIHJlZGlyZWN0aW9uIFVS SSByZWdpc3RyYXRpb24gcmVxdWlyZW1lbnQgY2FuIGVuYWJsZSBhbiBhdHRhY2tlciB0byB1c2UK ICAgICAgICAgICAgICB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludCBhcyBvcGVuIHJlZGlyZWN0 b3IgYXMgZGVzY3JpYmVkIGluCiAgICAgICAgICAgICAgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNv cGVuLXJlZGlyZWN0Jz5TZWN0aW9uJm5ic3A7MTAuMTU8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFz cz0naW5mbyc+T3BlbiBSZWRpcmVjdG9yczwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4uCiAgICAg ICAgICAgIAo8L3A+CjxhIG5hbWU9ImFuY2hvcjIxIj48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBz dW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRP Q2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2Mi PiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rp b24uMy4xLjIuMyI+PC9hPjxoMz4zLjEuMi4zLiZuYnNwOwpEeW5hbWljIENvbmZpZ3VyYXRpb248 L2gzPgoKPHA+CiAgICAgICAgICAgICAgSWYgbXVsdGlwbGUgcmVkaXJlY3Rpb24gVVJJcyBoYXZl IGJlZW4gcmVnaXN0ZXJlZCwgaWYgb25seSBwYXJ0IG9mIHRoZSByZWRpcmVjdGlvbgogICAgICAg ICAgICAgIFVSSSBoYXMgYmVlbiByZWdpc3RlcmVkLCBvciBpZiBubyByZWRpcmVjdGlvbiBVUkkg aGFzIGJlZW4gcmVnaXN0ZXJlZCwgdGhlIGNsaWVudAogICAgICAgICAgICAgIE1VU1QgaW5jbHVk ZSBhIHJlZGlyZWN0aW9uIFVSSSB3aXRoIHRoZSBhdXRob3JpemF0aW9uIHJlcXVlc3QgdXNpbmcg dGhlCiAgICAgICAgICAgICAgPHR0PnJlZGlyZWN0X3VyaTwvdHQ+IHJlcXVlc3QgcGFyYW1ldGVy LgogICAgICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgICAgICBXaGVuIGEgcmVkaXJlY3Rpb24g VVJJIGlzIGluY2x1ZGVkIGluIGFuIGF1dGhvcml6YXRpb24gcmVxdWVzdCwgdGhlIGF1dGhvcml6 YXRpb24KICAgICAgICAgICAgICBzZXJ2ZXIgTVVTVCBjb21wYXJlIGFuZCBtYXRjaCB0aGUgdmFs dWUgcmVjZWl2ZWQgYWdhaW5zdCBhdCBsZWFzdCBvbmUgb2YgdGhlCiAgICAgICAgICAgICAgcmVn aXN0ZXJlZCByZWRpcmVjdGlvbiBVUklzIChvciBVUkkgY29tcG9uZW50cykgYXMgZGVmaW5lZCBp bgogICAgICAgICAgICAgIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjUkZDMzk4Nic+W1JGQzM5ODZd PHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkJlcm5lcnMtTGVlLCBULiwgRmllbGRp bmcsIFIuLCBhbmQgTC4gTWFzaW50ZXIsICZsZHF1bztVbmlmb3JtIFJlc291cmNlIElkZW50aWZp ZXIgKFVSSSk6IEdlbmVyaWMgU3ludGF4LCZyZHF1bzsgSmFudWFyeSZuYnNwOzIwMDUuPC9zcGFu PjxzcGFuPik8L3NwYW4+PC9hPiBzZWN0aW9uIDYsIGlmIGFueSByZWRpcmVjdGlvbiBVUklzIHdl cmUgcmVnaXN0ZXJlZC4KICAgICAgICAgICAgICBJZiB0aGUgY2xpZW50IHJlZ2lzdHJhdGlvbiBp bmNsdWRlZCB0aGUgZnVsbCByZWRpcmVjdGlvbiBVUkksIHRoZSBhdXRob3JpemF0aW9uCiAgICAg ICAgICAgICAgc2VydmVyIE1VU1QgY29tcGFyZSB0aGUgdHdvIFVSSXMgdXNpbmcgc2ltcGxlIHN0 cmluZyBjb21wYXJpc29uIGFzIGRlZmluZWQKICAgICAgICAgICAgICBpbiA8YSBjbGFzcz0naW5m bycgaHJlZj0nI1JGQzM5ODYnPltSRkMzOTg2XTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdp bmZvJz5CZXJuZXJzLUxlZSwgVC4sIEZpZWxkaW5nLCBSLiwgYW5kIEwuIE1hc2ludGVyLCAmbGRx dW87VW5pZm9ybSBSZXNvdXJjZSBJZGVudGlmaWVyIChVUkkpOiBHZW5lcmljIFN5bnRheCwmcmRx dW87IEphbnVhcnkmbmJzcDsyMDA1Ljwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4gc2VjdGlvbiA2 LjIuMS4KICAgICAgICAgICAgCjwvcD4KPGEgbmFtZT0iYW5jaG9yMjIiPjwvYT48YnIgLz48aHIg Lz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIy IiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEg aHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1l PSJyZmMuc2VjdGlvbi4zLjEuMi40Ij48L2E+PGgzPjMuMS4yLjQuJm5ic3A7CkludmFsaWQgRW5k cG9pbnQ8L2gzPgoKPHA+CiAgICAgICAgICAgICAgSWYgYW4gYXV0aG9yaXphdGlvbiByZXF1ZXN0 IGZhaWxzIHZhbGlkYXRpb24gZHVlIHRvIGEgbWlzc2luZywgaW52YWxpZCwgb3IKICAgICAgICAg ICAgICBtaXNtYXRjaGluZyByZWRpcmVjdGlvbiBVUkksIHRoZSBhdXRob3JpemF0aW9uIHNlcnZl ciBTSE9VTEQgaW5mb3JtIHRoZSByZXNvdXJjZQogICAgICAgICAgICAgIG93bmVyIG9mIHRoZSBl cnJvciwgYW5kIE1VU1QgTk9UIGF1dG9tYXRpY2FsbHkgcmVkaXJlY3QgdGhlIHVzZXItYWdlbnQg dG8gdGhlIGludmFsaWQKICAgICAgICAgICAgICByZWRpcmVjdGlvbiBVUkkuCiAgICAgICAgICAg IAo8L3A+CjxhIG5hbWU9ImFuY2hvcjIzIj48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5 PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIg YWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNw O1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uMy4x LjIuNSI+PC9hPjxoMz4zLjEuMi41LiZuYnNwOwpFbmRwb2ludCBDb250ZW50PC9oMz4KCjxwPgog ICAgICAgICAgICAgIFRoZSByZWRpcmVjdGlvbiByZXF1ZXN0IHRvIHRoZSBjbGllbnQncyBlbmRw b2ludCB0eXBpY2FsbHkgcmVzdWx0cyBpbiBhbiBIVE1MCiAgICAgICAgICAgICAgZG9jdW1lbnQg cmVzcG9uc2UsIHByb2Nlc3NlZCBieSB0aGUgdXNlci1hZ2VudC4gSWYgdGhlIEhUTUwgcmVzcG9u c2UgaXMgc2VydmVkCiAgICAgICAgICAgICAgZGlyZWN0bHkgYXMgdGhlIHJlc3VsdCBvZiB0aGUg cmVkaXJlY3Rpb24gcmVxdWVzdCwgYW55IHNjcmlwdCBpbmNsdWRlZCBpbiB0aGUgSFRNTAogICAg ICAgICAgICAgIGRvY3VtZW50IHdpbGwgZXhlY3V0ZSB3aXRoIGZ1bGwgYWNjZXNzIHRvIHRoZSBy ZWRpcmVjdGlvbiBVUkkgYW5kIHRoZSBjcmVkZW50aWFscyBpdAogICAgICAgICAgICAgIGNvbnRh aW5zLgogICAgICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgICAgICBUaGUgY2xpZW50IFNIT1VM RCBOT1QgaW5jbHVkZSBhbnkgdGhpcmQtcGFydHkgc2NyaXB0cyAoZS5nLiB0aGlyZC1wYXJ0eSBh bmFseXRpY3MsCiAgICAgICAgICAgICAgc29jaWFsIHBsdWctaW5zLCBhZCBuZXR3b3JrcykgaW4g dGhlIHJlZGlyZWN0aW9uIGVuZHBvaW50IHJlc3BvbnNlLiBJbnN0ZWFkLCBpdAogICAgICAgICAg ICAgIFNIT1VMRCBleHRyYWN0IHRoZSBjcmVkZW50aWFscyBmcm9tIHRoZSBVUkkgYW5kIHJlZGly ZWN0IHRoZSB1c2VyLWFnZW50IGFnYWluIHRvCiAgICAgICAgICAgICAgYW5vdGhlciBlbmRwb2lu dCB3aXRob3V0IGV4cG9zaW5nIHRoZSBjcmVkZW50aWFscyAoaW4gdGhlIFVSSSBvciBlbHNld2hl cmUpLiBJZgogICAgICAgICAgICAgIHRoaXJkLXBhcnR5IHNjcmlwdHMgYXJlIGluY2x1ZGVkLCB0 aGUgY2xpZW50IE1VU1QgZW5zdXJlIHRoYXQgaXRzIG93biBzY3JpcHRzCiAgICAgICAgICAgICAg KHVzZWQgdG8gZXh0cmFjdCBhbmQgcmVtb3ZlIHRoZSBjcmVkZW50aWFscyBmcm9tIHRoZSBVUkkp IHdpbGwgZXhlY3V0ZSBmaXJzdC4KICAgICAgICAgICAgCjwvcD4KPGEgbmFtZT0iYW5jaG9yMjQi PjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAi IGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xh c3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48 L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi4zLjIiPjwvYT48aDM+My4yLiZuYnNwOwpUb2tl biBFbmRwb2ludDwvaDM+Cgo8cD4KICAgICAgICAgIFRoZSB0b2tlbiBlbmRwb2ludCBpcyB1c2Vk IGJ5IHRoZSBjbGllbnQgdG8gb2J0YWluIGFuIGFjY2VzcyB0b2tlbiBieSBwcmVzZW50aW5nIGl0 cwogICAgICAgICAgYXV0aG9yaXphdGlvbiBncmFudCBvciByZWZyZXNoIHRva2VuLiBUaGUgdG9r ZW4gZW5kcG9pbnQgaXMgdXNlZCB3aXRoIGV2ZXJ5IGF1dGhvcml6YXRpb24KICAgICAgICAgIGdy YW50IGV4Y2VwdCBmb3IgdGhlIGltcGxpY2l0IGdyYW50IHR5cGUgKHNpbmNlIGFuIGFjY2VzcyB0 b2tlbiBpcyBpc3N1ZWQgZGlyZWN0bHkpLgogICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgVGhl IG1lYW5zIHRocm91Z2ggd2hpY2ggdGhlIGNsaWVudCBvYnRhaW5zIHRoZSBsb2NhdGlvbiBvZiB0 aGUgdG9rZW4gZW5kcG9pbnQgYXJlCiAgICAgICAgICBiZXlvbmQgdGhlIHNjb3BlIG9mIHRoaXMg c3BlY2lmaWNhdGlvbiBidXQgaXMgdHlwaWNhbGx5IHByb3ZpZGVkIGluIHRoZSBzZXJ2aWNlCiAg ICAgICAgICBkb2N1bWVudGF0aW9uLgogICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgVGhlIGVu ZHBvaW50IFVSSSBNQVkgaW5jbHVkZSBhbgogICAgICAgICAgPHR0PmFwcGxpY2F0aW9uL3gtd3d3 LWZvcm0tdXJsZW5jb2RlZDwvdHQ+IGZvcm1hdHRlZAogICAgICAgICAgKDxhIGNsYXNzPSdpbmZv JyBocmVmPScjVzNDLlJFQy1odG1sNDAxLTE5OTkxMjI0Jz5bVzNDLlJFQyYjODIwOTtodG1sNDAx JiM4MjA5OzE5OTkxMjI0XTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5Ib3JzLCBB LiwgUmFnZ2V0dCwgRC4sIGFuZCBJLiBKYWNvYnMsICZsZHF1bztIVE1MIDQuMDEgU3BlY2lmaWNh dGlvbiwmcmRxdW87IERlY2VtYmVyJm5ic3A7MTk5OS48L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+ KSBxdWVyeSBjb21wb25lbnQgKDxhIGNsYXNzPSdpbmZvJyBocmVmPScjUkZDMzk4Nic+W1JGQzM5 ODZdPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkJlcm5lcnMtTGVlLCBULiwgRmll bGRpbmcsIFIuLCBhbmQgTC4gTWFzaW50ZXIsICZsZHF1bztVbmlmb3JtIFJlc291cmNlIElkZW50 aWZpZXIgKFVSSSk6IEdlbmVyaWMgU3ludGF4LCZyZHF1bzsgSmFudWFyeSZuYnNwOzIwMDUuPC9z cGFuPjxzcGFuPik8L3NwYW4+PC9hPgogICAgICAgICAgc2VjdGlvbiAzLjQpLCB3aGljaCBNVVNU IGJlIHJldGFpbmVkIHdoZW4gYWRkaW5nIGFkZGl0aW9uYWwgcXVlcnkgcGFyYW1ldGVycy4gVGhl CiAgICAgICAgICBlbmRwb2ludCBVUkkgTVVTVCBOT1QgaW5jbHVkZSBhIGZyYWdtZW50IGNvbXBv bmVudC4KICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgIFNpbmNlIHJlcXVlc3RzIHRvIHRoZSB0 b2tlbiBlbmRwb2ludCByZXN1bHQgaW4gdGhlIHRyYW5zbWlzc2lvbiBvZiBjbGVhci10ZXh0IGNy ZWRlbnRpYWxzCiAgICAgICAgICAoaW4gdGhlIEhUVFAgcmVxdWVzdCBhbmQgcmVzcG9uc2UpLCB0 aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVTVCByZXF1aXJlIHRoZSB1c2Ugb2YgVExTCiAgICAg ICAgICBhcyBkZXNjcmliZWQgaW4gPGEgY2xhc3M9J2luZm8nIGhyZWY9JyN0bHMnPlNlY3Rpb24m bmJzcDsxLjY8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+VExTIFZlcnNpb248L3Nw YW4+PHNwYW4+KTwvc3Bhbj48L2E+IHdoZW4gc2VuZGluZyByZXF1ZXN0cyB0byB0aGUgdG9rZW4g ZW5kcG9pbnQuCiAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICBUaGUgY2xpZW50IE1VU1QgdXNl IHRoZSBIVFRQIDx0dD5QT1NUPC90dD4gbWV0aG9kIHdoZW4gbWFraW5nIGFjY2VzcwogICAgICAg ICAgdG9rZW4gcmVxdWVzdHMuCiAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICBQYXJhbWV0ZXJz IHNlbnQgd2l0aG91dCBhIHZhbHVlIE1VU1QgYmUgdHJlYXRlZCBhcyBpZiB0aGV5IHdlcmUgb21p dHRlZCBmcm9tIHRoZSByZXF1ZXN0LgogICAgICAgICAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVy IE1VU1QgaWdub3JlIHVucmVjb2duaXplZCByZXF1ZXN0IHBhcmFtZXRlcnMuIFJlcXVlc3QgYW5k CiAgICAgICAgICByZXNwb25zZSBwYXJhbWV0ZXJzIE1VU1QgTk9UIGJlIGluY2x1ZGVkIG1vcmUg dGhhbiBvbmNlLgogICAgICAgIAo8L3A+CjxhIG5hbWU9InRva2VuLWVuZHBvaW50LWF1dGgiPjwv YT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNl bGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9 IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3Rh YmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi4zLjIuMSI+PC9hPjxoMz4zLjIuMS4mbmJzcDsKQ2xp ZW50IEF1dGhlbnRpY2F0aW9uPC9oMz4KCjxwPgogICAgICAgICAgICBDb25maWRlbnRpYWwgY2xp ZW50cyBvciBvdGhlciBjbGllbnRzIGlzc3VlZCBjbGllbnQgY3JlZGVudGlhbHMgTVVTVCBhdXRo ZW50aWNhdGUgd2l0aAogICAgICAgICAgICB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYXMgZGVz Y3JpYmVkIGluIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjY2xpZW50LWF1dGhlbnRpY2F0aW9uJz5T ZWN0aW9uJm5ic3A7Mi4zPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkNsaWVudCBB dXRoZW50aWNhdGlvbjwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4gd2hlbgogICAgICAgICAgICBt YWtpbmcgcmVxdWVzdHMgdG8gdGhlIHRva2VuIGVuZHBvaW50LiBDbGllbnQgYXV0aGVudGljYXRp b24gaXMgdXNlZCBmb3I6CiAgICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgICAgPC9wPgo8dWwg Y2xhc3M9InRleHQiPgo8bGk+CiAgICAgICAgICAgICAgICBFbmZvcmNpbmcgdGhlIGJpbmRpbmcg b2YgcmVmcmVzaCB0b2tlbnMgYW5kIGF1dGhvcml6YXRpb24gY29kZXMgdG8gdGhlIGNsaWVudCB0 aGV5CiAgICAgICAgICAgICAgICB3ZXJlIGlzc3VlZCB0by4gQ2xpZW50IGF1dGhlbnRpY2F0aW9u IGlzIGNyaXRpY2FsIHdoZW4gYW4gYXV0aG9yaXphdGlvbiBjb2RlIGlzCiAgICAgICAgICAgICAg ICB0cmFuc21pdHRlZCB0byB0aGUgcmVkaXJlY3Rpb24gZW5kcG9pbnQgb3ZlciBhbiBpbnNlY3Vy ZSBjaGFubmVsLCBvciB3aGVuIHRoZQogICAgICAgICAgICAgICAgcmVkaXJlY3Rpb24gVVJJIGhh cyBub3QgYmVlbiByZWdpc3RlcmVkIGluIGZ1bGwuCiAgICAgICAgICAgICAgCjwvbGk+CjxsaT4K ICAgICAgICAgICAgICAgIFJlY292ZXJpbmcgZnJvbSBhIGNvbXByb21pc2VkIGNsaWVudCBieSBk aXNhYmxpbmcgdGhlIGNsaWVudCBvciBjaGFuZ2luZyBpdHMKICAgICAgICAgICAgICAgIGNyZWRl bnRpYWxzLCB0aHVzIHByZXZlbnRpbmcgYW4gYXR0YWNrZXIgZnJvbSBhYnVzaW5nIHN0b2xlbiBy ZWZyZXNoIHRva2Vucy4gQ2hhbmdpbmcKICAgICAgICAgICAgICAgIGEgc2luZ2xlIHNldCBvZiBj bGllbnQgY3JlZGVudGlhbHMgaXMgc2lnbmlmaWNhbnRseSBmYXN0ZXIgdGhhbiByZXZva2luZyBh biBlbnRpcmUKICAgICAgICAgICAgICAgIHNldCBvZiByZWZyZXNoIHRva2Vucy4KICAgICAgICAg ICAgICAKPC9saT4KPGxpPgogICAgICAgICAgICAgICAgSW1wbGVtZW50aW5nIGF1dGhlbnRpY2F0 aW9uIG1hbmFnZW1lbnQgYmVzdCBwcmFjdGljZXMgd2hpY2ggcmVxdWlyZSBwZXJpb2RpYwogICAg ICAgICAgICAgICAgY3JlZGVudGlhbCByb3RhdGlvbi4gUm90YXRpb24gb2YgYW4gZW50aXJlIHNl dCBvZiByZWZyZXNoIHRva2VucyBjYW4gYmUKICAgICAgICAgICAgICAgIGNoYWxsZW5naW5nLCB3 aGlsZSByb3RhdGlvbiBvZiBhIHNpbmdsZSBzZXQgb2YgY2xpZW50IGNyZWRlbnRpYWxzIGlzIHNp Z25pZmljYW50bHkKICAgICAgICAgICAgICAgIGVhc2llci4KICAgICAgICAgICAgICAKPC9saT4K PC91bD48cD4KICAgICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgICBBIHB1YmxpYyBjbGllbnQg dGhhdCB3YXMgbm90IGlzc3VlZCBhIGNsaWVudCBwYXNzd29yZCBNQVkgdXNlIHRoZQogICAgICAg ICAgICA8dHQ+Y2xpZW50X2lkPC90dD4gcmVxdWVzdCBwYXJhbWV0ZXIgdG8gaWRlbnRpZnkgaXRz ZWxmIHdoZW4gc2VuZGluZwogICAgICAgICAgICByZXF1ZXN0cyB0byB0aGUgdG9rZW4gZW5kcG9p bnQgKGUuZy4gZm9yIHRoZSBwdXJwb3NlIG9mIHByb3ZpZGluZyBlbmQtdXNlciBjb250ZXh0LAog ICAgICAgICAgICBjbGllbnQgdXNhZ2Ugc3RhdGlzdGljcykuCiAgICAgICAgICAKPC9wPgo8YSBu YW1lPSJzY29wZSI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxs cGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+ PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+ PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLjMuMyI+PC9hPjxoMz4zLjMu Jm5ic3A7CkFjY2VzcyBUb2tlbiBTY29wZTwvaDM+Cgo8cD4KICAgICAgICAgIFRoZSBhdXRob3Jp emF0aW9uIGFuZCB0b2tlbiBlbmRwb2ludHMgYWxsb3cgdGhlIGNsaWVudCB0byBzcGVjaWZ5IHRo ZSBzY29wZSBvZiB0aGUgYWNjZXNzCiAgICAgICAgICByZXF1ZXN0IHVzaW5nIHRoZSA8dHQ+c2Nv cGU8L3R0PiByZXF1ZXN0IHBhcmFtZXRlci4gSW4gdHVybiwgdGhlCiAgICAgICAgICBhdXRob3Jp emF0aW9uIHNlcnZlciB1c2VzIHRoZSA8dHQ+c2NvcGU8L3R0PiByZXNwb25zZSBwYXJhbWV0ZXIg dG8KICAgICAgICAgIGluZm9ybSB0aGUgY2xpZW50IG9mIHRoZSBzY29wZSBvZiB0aGUgYWNjZXNz IHRva2VuIGlzc3VlZC4KICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgIFRoZSB2YWx1ZSBvZiB0 aGUgc2NvcGUgcGFyYW1ldGVyIGlzIGV4cHJlc3NlZCBhcyBhIGxpc3Qgb2Ygc3BhY2UtZGVsaW1p dGVkLCBjYXNlCiAgICAgICAgICBzZW5zaXRpdmUgc3RyaW5ncy4gVGhlIHN0cmluZ3MgYXJlIGRl ZmluZWQgYnkgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLiBJZiB0aGUgdmFsdWUKICAgICAgICAg IGNvbnRhaW5zIG11bHRpcGxlIHNwYWNlLWRlbGltaXRlZCBzdHJpbmdzLCB0aGVpciBvcmRlciBk b2VzIG5vdCBtYXR0ZXIsIGFuZCBlYWNoIHN0cmluZwogICAgICAgICAgYWRkcyBhbiBhZGRpdGlv bmFsIGFjY2VzcyByYW5nZSB0byB0aGUgcmVxdWVzdGVkIHNjb3BlLgogICAgICAgIAo8L3A+PGRp diBzdHlsZT0nZGlzcGxheTogdGFibGU7IHdpZHRoOiAwOyBtYXJnaW4tbGVmdDogM2VtOyBtYXJn aW4tcmlnaHQ6IGF1dG8nPjxwcmU+CgogIHNjb3BlICAgICAgID0gc2NvcGUtdG9rZW4gKiggU1Ag c2NvcGUtdG9rZW4gKQogIHNjb3BlLXRva2VuID0gMSooICV4MjEgLyAleDIzLTVCIC8gJXg1RC03 RSApCgo8L3ByZT48L2Rpdj4KPHA+CiAgICAgICAgICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIg TUFZIGZ1bGx5IG9yIHBhcnRpYWxseSBpZ25vcmUgdGhlIHNjb3BlIHJlcXVlc3RlZCBieSB0aGUg Y2xpZW50CiAgICAgICAgICBiYXNlZCBvbiB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgcG9saWN5 IG9yIHRoZSByZXNvdXJjZSBvd25lcidzIGluc3RydWN0aW9ucy4gSWYgdGhlCiAgICAgICAgICBp c3N1ZWQgYWNjZXNzIHRva2VuIHNjb3BlIGlzIGRpZmZlcmVudCBmcm9tIHRoZSBvbmUgcmVxdWVz dGVkIGJ5IHRoZSBjbGllbnQsIHRoZQogICAgICAgICAgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVT VCBpbmNsdWRlIHRoZSA8dHQ+c2NvcGU8L3R0PiByZXNwb25zZQogICAgICAgICAgcGFyYW1ldGVy IHRvIGluZm9ybSB0aGUgY2xpZW50IG9mIHRoZSBhY3R1YWwgc2NvcGUgZ3JhbnRlZC4KICAgICAg ICAKPC9wPgo8cD4KICAgICAgICAgIElmIHRoZSBjbGllbnQgb21pdHMgdGhlIHNjb3BlIHBhcmFt ZXRlciB3aGVuIHJlcXVlc3RpbmcgYXV0aG9yaXphdGlvbiwgdGhlIGF1dGhvcml6YXRpb24KICAg ICAgICAgIHNlcnZlciBNVVNUIGVpdGhlciBwcm9jZXNzIHRoZSByZXF1ZXN0IHVzaW5nIGEgcHJl LWRlZmluZWQgZGVmYXVsdCB2YWx1ZSwgb3IgZmFpbCB0aGUKICAgICAgICAgIHJlcXVlc3QgaW5k aWNhdGluZyBhbiBpbnZhbGlkIHNjb3BlLiBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgU0hPVUxE IGRvY3VtZW50IGl0cyBzY29wZQogICAgICAgICAgcmVxdWlyZW1lbnRzIGFuZCBkZWZhdWx0IHZh bHVlIChpZiBkZWZpbmVkKS4KICAgICAgICAKPC9wPgo8YSBuYW1lPSJhbmNob3IyNSI+PC9hPjxi ciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNw YWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9D YnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+ CjxhIG5hbWU9InJmYy5zZWN0aW9uLjQiPjwvYT48aDM+NC4mbmJzcDsKT2J0YWluaW5nIEF1dGhv cml6YXRpb248L2gzPgoKPHA+CiAgICAgICAgVG8gcmVxdWVzdCBhbiBhY2Nlc3MgdG9rZW4sIHRo ZSBjbGllbnQgb2J0YWlucyBhdXRob3JpemF0aW9uIGZyb20gdGhlIHJlc291cmNlIG93bmVyLiBU aGUKICAgICAgICBhdXRob3JpemF0aW9uIGlzIGV4cHJlc3NlZCBpbiB0aGUgZm9ybSBvZiBhbiBh dXRob3JpemF0aW9uIGdyYW50IHdoaWNoIHRoZSBjbGllbnQgdXNlcyB0bwogICAgICAgIHJlcXVl c3QgdGhlIGFjY2VzcyB0b2tlbi4gT0F1dGggZGVmaW5lcyBmb3VyIGdyYW50IHR5cGVzOiBhdXRo b3JpemF0aW9uIGNvZGUsIGltcGxpY2l0LAogICAgICAgIHJlc291cmNlIG93bmVyIHBhc3N3b3Jk IGNyZWRlbnRpYWxzLCBhbmQgY2xpZW50IGNyZWRlbnRpYWxzLiBJdCBhbHNvIHByb3ZpZGVzIGFu IGV4dGVuc2lvbgogICAgICAgIG1lY2hhbmlzbSBmb3IgZGVmaW5pbmcgYWRkaXRpb25hbCBncmFu dCB0eXBlcy4KICAgICAgCjwvcD4KPGEgbmFtZT0iZ3JhbnQtY29kZSI+PC9hPjxiciAvPjxociAv Pgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIi IGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBo cmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9 InJmYy5zZWN0aW9uLjQuMSI+PC9hPjxoMz40LjEuJm5ic3A7CkF1dGhvcml6YXRpb24gQ29kZSBH cmFudDwvaDM+Cgo8cD4KICAgICAgICAgIFRoZSBhdXRob3JpemF0aW9uIGNvZGUgZ3JhbnQgdHlw ZSBpcyB1c2VkIHRvIG9idGFpbiBib3RoIGFjY2VzcyB0b2tlbnMgYW5kIHJlZnJlc2gKICAgICAg ICAgIHRva2VucyBhbmQgaXMgb3B0aW1pemVkIGZvciBjb25maWRlbnRpYWwgY2xpZW50cy4gQXMg YSByZWRpcmVjdGlvbi1iYXNlZCBmbG93LCB0aGUgY2xpZW50CiAgICAgICAgICBtdXN0IGJlIGNh cGFibGUgb2YgaW50ZXJhY3Rpbmcgd2l0aCB0aGUgcmVzb3VyY2Ugb3duZXIncyB1c2VyLWFnZW50 ICh0eXBpY2FsbHkgYSB3ZWIKICAgICAgICAgIGJyb3dzZXIpIGFuZCBjYXBhYmxlIG9mIHJlY2Vp dmluZyBpbmNvbWluZyByZXF1ZXN0cyAodmlhIHJlZGlyZWN0aW9uKSBmcm9tIHRoZQogICAgICAg ICAgYXV0aG9yaXphdGlvbiBzZXJ2ZXIuCiAgICAgICAgCjwvcD48YnIgLz48aHIgY2xhc3M9Imlu c2VydCIgLz4KPGEgbmFtZT0iRmlndXJlLTMiPjwvYT4KPGRpdiBzdHlsZT0nZGlzcGxheTogdGFi bGU7IHdpZHRoOiAwOyBtYXJnaW4tbGVmdDogM2VtOyBtYXJnaW4tcmlnaHQ6IGF1dG8nPjxwcmU+ CgogICstLS0tLS0tLS0tKwogIHwgcmVzb3VyY2UgfAogIHwgICBvd25lciAgfAogIHwgICAgICAg ICAgfAogICstLS0tLS0tLS0tKwogICAgICAgXgogICAgICAgfAogICAgICAoQikKICArLS0tLXwt LS0tLSsgICAgICAgICAgQ2xpZW50IElkZW50aWZpZXIgICAgICArLS0tLS0tLS0tLS0tLS0tKwog IHwgICAgICAgICAtKy0tLS0oQSktLSAmYW1wOyBSZWRpcmVjdGlvbiBVUkkgLS0tLSZndDt8ICAg ICAgICAgICAgICAgfAogIHwgIFVzZXItICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHwgQXV0aG9yaXphdGlvbiB8CiAgfCAgQWdlbnQgIC0rLS0tLShCKS0tIFVzZXIgYXV0aGVu dGljYXRlcyAtLS0mZ3Q7fCAgICAgU2VydmVyICAgIHwKICB8ICAgICAgICAgIHwgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgfAogIHwgICAgICAgICAtKy0t LS0oQyktLSBBdXRob3JpemF0aW9uIENvZGUgLS0tJmx0O3wgICAgICAgICAgICAgICB8CiAgKy18 LS0tLXwtLS0rICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0t LSsKICAgIHwgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXiAg ICAgIHYKICAgKEEpICAoQykgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg fCAgICAgIHwKICAgIHwgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgfCAgICAgIHwKICAgIF4gICAgdiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgfCAgICAgIHwKICArLS0tLS0tLS0tKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfCAgICAgIHwKICB8ICAgICAgICAgfCZndDstLS0oRCktLSBBdXRob3JpemF0aW9u IENvZGUgLS0tLS0tLS0tJyAgICAgIHwKICB8ICBDbGllbnQgfCAgICAgICAgICAmYW1wOyBSZWRp cmVjdGlvbiBVUkkgICAgICAgICAgICAgICAgICB8CiAgfCAgICAgICAgIHwgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgfCAgICAgICAgIHwmbHQ7LS0tKEUp LS0tLS0gQWNjZXNzIFRva2VuIC0tLS0tLS0tLS0tLS0tLS0tLS0nCiAgKy0tLS0tLS0tLSsgICAg ICAgKHcvIE9wdGlvbmFsIFJlZnJlc2ggVG9rZW4pCgo8L3ByZT48L2Rpdj4KPHA+CiAgICAgICAg ICAgIE5vdGU6IFRoZSBsaW5lcyBpbGx1c3RyYXRpbmcgc3RlcHMgQSwgQiwgYW5kIEMgYXJlIGJy b2tlbiBpbnRvIHR3byBwYXJ0cyBhcyB0aGV5IHBhc3MKICAgICAgICAgICAgdGhyb3VnaCB0aGUg dXNlci1hZ2VudC4KICAgICAgICAgIAo8L3A+PHRhYmxlIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9 IjAiIGNlbGxzcGFjaW5nPSIyIiBhbGlnbj0iY2VudGVyIj48dHI+PHRkIGFsaWduPSJjZW50ZXIi Pjxmb250IGZhY2U9Im1vbmFjbywgTVMgU2FucyBTZXJpZiIgc2l6ZT0iMSI+PGI+Jm5ic3A7Rmln dXJlJm5ic3A7MzogQXV0aG9yaXphdGlvbiBDb2RlIEZsb3cmbmJzcDs8L2I+PC9mb250PjxiciAv PjwvdGQ+PC90cj48L3RhYmxlPjxociBjbGFzcz0iaW5zZXJ0IiAvPgoKPHA+CiAgICAgICAgICBU aGUgZmxvdyBpbGx1c3RyYXRlZCBpbiA8YSBjbGFzcz0naW5mbycgaHJlZj0nI0ZpZ3VyZS0zJz5G aWd1cmUmbmJzcDszPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkF1dGhvcml6YXRp b24gQ29kZSBGbG93PC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPiBpbmNsdWRlcyB0aGUgZm9sbG93 aW5nIHN0ZXBzOgogICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgPC9wPgo8YmxvY2txdW90ZSBj bGFzcz0idGV4dCI+PGRsPgo8ZHQ+KEEpPC9kdD4KPGRkPgogICAgICAgICAgICAgIFRoZSBjbGll bnQgaW5pdGlhdGVzIHRoZSBmbG93IGJ5IGRpcmVjdGluZyB0aGUgcmVzb3VyY2Ugb3duZXIncyB1 c2VyLWFnZW50IHRvIHRoZQogICAgICAgICAgICAgIGF1dGhvcml6YXRpb24gZW5kcG9pbnQuIFRo ZSBjbGllbnQgaW5jbHVkZXMgaXRzIGNsaWVudCBpZGVudGlmaWVyLCByZXF1ZXN0ZWQKICAgICAg ICAgICAgICBzY29wZSwgbG9jYWwgc3RhdGUsIGFuZCBhIHJlZGlyZWN0aW9uIFVSSSB0byB3aGlj aCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgd2lsbCBzZW5kCiAgICAgICAgICAgICAgdGhlIHVz ZXItYWdlbnQgYmFjayBvbmNlIGFjY2VzcyBpcyBncmFudGVkIChvciBkZW5pZWQpLgogICAgICAg ICAgICAKPC9kZD4KPGR0PihCKTwvZHQ+CjxkZD4KICAgICAgICAgICAgICBUaGUgYXV0aG9yaXph dGlvbiBzZXJ2ZXIgYXV0aGVudGljYXRlcyB0aGUgcmVzb3VyY2Ugb3duZXIgKHZpYSB0aGUgdXNl ci1hZ2VudCkgYW5kCiAgICAgICAgICAgICAgZXN0YWJsaXNoZXMgd2hldGhlciB0aGUgcmVzb3Vy Y2Ugb3duZXIgZ3JhbnRzIG9yIGRlbmllcyB0aGUgY2xpZW50J3MgYWNjZXNzIHJlcXVlc3QuCiAg ICAgICAgICAgIAo8L2RkPgo8ZHQ+KEMpPC9kdD4KPGRkPgogICAgICAgICAgICAgIEFzc3VtaW5n IHRoZSByZXNvdXJjZSBvd25lciBncmFudHMgYWNjZXNzLCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2 ZXIgcmVkaXJlY3RzIHRoZQogICAgICAgICAgICAgIHVzZXItYWdlbnQgYmFjayB0byB0aGUgY2xp ZW50IHVzaW5nIHRoZSByZWRpcmVjdGlvbiBVUkkgcHJvdmlkZWQgZWFybGllciAoaW4gdGhlCiAg ICAgICAgICAgICAgcmVxdWVzdCBvciBkdXJpbmcgY2xpZW50IHJlZ2lzdHJhdGlvbikuIFRoZSBy ZWRpcmVjdGlvbiBVUkkgaW5jbHVkZXMgYW4gYXV0aG9yaXphdGlvbgogICAgICAgICAgICAgIGNv ZGUgYW5kIGFueSBsb2NhbCBzdGF0ZSBwcm92aWRlZCBieSB0aGUgY2xpZW50IGVhcmxpZXIuCiAg ICAgICAgICAgIAo8L2RkPgo8ZHQ+KEQpPC9kdD4KPGRkPgogICAgICAgICAgICAgIFRoZSBjbGll bnQgcmVxdWVzdHMgYW4gYWNjZXNzIHRva2VuIGZyb20gdGhlIGF1dGhvcml6YXRpb24gc2VydmVy J3MgdG9rZW4gZW5kcG9pbnQKICAgICAgICAgICAgICBieSBpbmNsdWRpbmcgdGhlIGF1dGhvcml6 YXRpb24gY29kZSByZWNlaXZlZCBpbiB0aGUgcHJldmlvdXMgc3RlcC4gV2hlbiBtYWtpbmcgdGhl CiAgICAgICAgICAgICAgcmVxdWVzdCwgdGhlIGNsaWVudCBhdXRoZW50aWNhdGVzIHdpdGggdGhl IGF1dGhvcml6YXRpb24gc2VydmVyLiBUaGUgY2xpZW50IGluY2x1ZGVzCiAgICAgICAgICAgICAg dGhlIHJlZGlyZWN0aW9uIFVSSSB1c2VkIHRvIG9idGFpbiB0aGUgYXV0aG9yaXphdGlvbiBjb2Rl IGZvciB2ZXJpZmljYXRpb24uCiAgICAgICAgICAgIAo8L2RkPgo8ZHQ+KEUpPC9kdD4KPGRkPgog ICAgICAgICAgICAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBhdXRoZW50aWNhdGVzIHRoZSBj bGllbnQsIHZhbGlkYXRlcyB0aGUgYXV0aG9yaXphdGlvbiBjb2RlLAogICAgICAgICAgICAgIGFu ZCBlbnN1cmVzIHRoZSByZWRpcmVjdGlvbiBVUkkgcmVjZWl2ZWQgbWF0Y2hlcyB0aGUgVVJJIHVz ZWQgdG8gcmVkaXJlY3QgdGhlIGNsaWVudAogICAgICAgICAgICAgIGluIHN0ZXAgKEMpLiBJZiB2 YWxpZCwgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHJlc3BvbmRzIGJhY2sgd2l0aCBhbiBhY2Nl c3MgdG9rZW4KICAgICAgICAgICAgICBhbmQgb3B0aW9uYWxseSwgYSByZWZyZXNoIHRva2VuLgog ICAgICAgICAgICAKPC9kZD4KPC9kbD48L2Jsb2NrcXVvdGU+PHA+CiAgICAgICAgCjwvcD4KPGEg bmFtZT0iY29kZS1hdXRoei1yZXEiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9Imxh eW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGln bj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9D Jm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi40LjEuMSI+ PC9hPjxoMz40LjEuMS4mbmJzcDsKQXV0aG9yaXphdGlvbiBSZXF1ZXN0PC9oMz4KCjxwPgogICAg ICAgICAgICBUaGUgY2xpZW50IGNvbnN0cnVjdHMgdGhlIHJlcXVlc3QgVVJJIGJ5IGFkZGluZyB0 aGUgZm9sbG93aW5nIHBhcmFtZXRlcnMgdG8gdGhlCiAgICAgICAgICAgIHF1ZXJ5IGNvbXBvbmVu dCBvZiB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludCBVUkkgdXNpbmcgdGhlCiAgICAgICAgICAg IDx0dD5hcHBsaWNhdGlvbi94LXd3dy1mb3JtLXVybGVuY29kZWQ8L3R0PiBmb3JtYXQgYXMgZGVm aW5lZCBieQogICAgICAgICAgICA8YSBjbGFzcz0naW5mbycgaHJlZj0nI1czQy5SRUMtaHRtbDQw MS0xOTk5MTIyNCc+W1czQy5SRUMmIzgyMDk7aHRtbDQwMSYjODIwOTsxOTk5MTIyNF08c3Bhbj4g KDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+SG9ycywgQS4sIFJhZ2dldHQsIEQuLCBhbmQgSS4g SmFjb2JzLCAmbGRxdW87SFRNTCA0LjAxIFNwZWNpZmljYXRpb24sJnJkcXVvOyBEZWNlbWJlciZu YnNwOzE5OTkuPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPjoKICAgICAgICAgIAo8L3A+CjxwPgog ICAgICAgICAgICA8L3A+CjxibG9ja3F1b3RlIGNsYXNzPSJ0ZXh0Ij48ZGw+CjxkdD5yZXNwb25z ZV90eXBlPC9kdD4KPGRkPgogICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICBSRVFVSVJF RC4gVmFsdWUgTVVTVCBiZSBzZXQgdG8gPHR0PmNvZGU8L3R0Pi4KICAgICAgICAgICAgICAKPC9k ZD4KPGR0PmNsaWVudF9pZDwvZHQ+CjxkZD4KICAgICAgICAgICAgICAgIAogICAgICAgICAgICAg ICAgUkVRVUlSRUQuIFRoZSBjbGllbnQgaWRlbnRpZmllciBhcyBkZXNjcmliZWQgaW4KICAgICAg ICAgICAgICAgIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjY2xpZW50LWlkZW50aWZpZXInPlNlY3Rp b24mbmJzcDsyLjI8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+Q2xpZW50IElkZW50 aWZpZXI8L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+LgogICAgICAgICAgICAgIAo8L2RkPgo8ZHQ+ cmVkaXJlY3RfdXJpPC9kdD4KPGRkPgogICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICBP UFRJT05BTC4gQXMgZGVzY3JpYmVkIGluIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjcmVkaXJlY3Qt dXJpJz5TZWN0aW9uJm5ic3A7My4xLjI8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+ UmVkaXJlY3Rpb24gRW5kcG9pbnQ8L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+LgogICAgICAgICAg ICAgIAo8L2RkPgo8ZHQ+c2NvcGU8L2R0Pgo8ZGQ+CiAgICAgICAgICAgICAgICAKICAgICAgICAg ICAgICAgIE9QVElPTkFMLiBUaGUgc2NvcGUgb2YgdGhlIGFjY2VzcyByZXF1ZXN0IGFzIGRlc2Ny aWJlZCBieSA8YSBjbGFzcz0naW5mbycgaHJlZj0nI3Njb3BlJz5TZWN0aW9uJm5ic3A7My4zPHNw YW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkFjY2VzcyBUb2tlbiBTY29wZTwvc3Bhbj48 c3Bhbj4pPC9zcGFuPjwvYT4uCiAgICAgICAgICAgICAgCjwvZGQ+CjxkdD5zdGF0ZTwvZHQ+Cjxk ZD4KICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgUkVDT01NRU5ERUQuIEFuIG9wYXF1 ZSB2YWx1ZSB1c2VkIGJ5IHRoZSBjbGllbnQgdG8gbWFpbnRhaW4gc3RhdGUgYmV0d2VlbiB0aGUg cmVxdWVzdAogICAgICAgICAgICAgICAgYW5kIGNhbGxiYWNrLiBUaGUgYXV0aG9yaXphdGlvbiBz ZXJ2ZXIgaW5jbHVkZXMgdGhpcyB2YWx1ZSB3aGVuIHJlZGlyZWN0aW5nIHRoZQogICAgICAgICAg ICAgICAgdXNlci1hZ2VudCBiYWNrIHRvIHRoZSBjbGllbnQuIFRoZSBwYXJhbWV0ZXIgU0hPVUxE IGJlIHVzZWQgZm9yIHByZXZlbnRpbmcKICAgICAgICAgICAgICAgIGNyb3NzLXNpdGUgcmVxdWVz dCBmb3JnZXJ5IGFzIGRlc2NyaWJlZCBpbiA8YSBjbGFzcz0naW5mbycgaHJlZj0nI0NTUkYnPlNl Y3Rpb24mbmJzcDsxMC4xMjxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5Dcm9zcy1T aXRlIFJlcXVlc3QgRm9yZ2VyeTwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4uCiAgICAgICAgICAg ICAgCjwvZGQ+CjwvZGw+PC9ibG9ja3F1b3RlPjxwPgogICAgICAgICAgCjwvcD4KPHA+CiAgICAg ICAgICAgIFRoZSBjbGllbnQgZGlyZWN0cyB0aGUgcmVzb3VyY2Ugb3duZXIgdG8gdGhlIGNvbnN0 cnVjdGVkIFVSSSB1c2luZyBhbiBIVFRQIHJlZGlyZWN0aW9uCiAgICAgICAgICAgIHJlc3BvbnNl LCBvciBieSBvdGhlciBtZWFucyBhdmFpbGFibGUgdG8gaXQgdmlhIHRoZSB1c2VyLWFnZW50Lgog ICAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICAgICAgRm9yIGV4YW1wbGUsIHRoZSBjbGllbnQg ZGlyZWN0cyB0aGUgdXNlci1hZ2VudCB0byBtYWtlIHRoZSBmb2xsb3dpbmcgSFRUUCByZXF1ZXN0 CiAgICAgICAgICAgICAgdXNpbmcgVExTIChleHRyYSBsaW5lIGJyZWFrcyBhcmUgZm9yIGRpc3Bs YXkgcHVycG9zZXMgb25seSk6CiAgICAgICAgICAgIAo8L3A+PGRpdiBzdHlsZT0nZGlzcGxheTog dGFibGU7IHdpZHRoOiAwOyBtYXJnaW4tbGVmdDogM2VtOyBtYXJnaW4tcmlnaHQ6IGF1dG8nPjxw cmU+CgogIEdFVCAvYXV0aG9yaXplP3Jlc3BvbnNlX3R5cGU9Y29kZSZhbXA7Y2xpZW50X2lkPXM2 QmhkUmtxdDMmYW1wO3N0YXRlPXh5egogICAgICAmYW1wO3JlZGlyZWN0X3VyaT1odHRwcyUzQSUy RiUyRmNsaWVudCUyRWV4YW1wbGUlMkVjb20lMkZjYiBIVFRQLzEuMQogIEhvc3Q6IHNlcnZlci5l eGFtcGxlLmNvbQoKPC9wcmU+PC9kaXY+CjxwPgogICAgICAgICAgICBUaGUgYXV0aG9yaXphdGlv biBzZXJ2ZXIgdmFsaWRhdGVzIHRoZSByZXF1ZXN0IHRvIGVuc3VyZSBhbGwgcmVxdWlyZWQgcGFy YW1ldGVycyBhcmUKICAgICAgICAgICAgcHJlc2VudCBhbmQgdmFsaWQuIElmIHRoZSByZXF1ZXN0 IGlzIHZhbGlkLCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYXV0aGVudGljYXRlcyB0aGUKICAg ICAgICAgICAgcmVzb3VyY2Ugb3duZXIgYW5kIG9idGFpbnMgYW4gYXV0aG9yaXphdGlvbiBkZWNp c2lvbiAoYnkgYXNraW5nIHRoZSByZXNvdXJjZSBvd25lciBvcgogICAgICAgICAgICBieSBlc3Rh Ymxpc2hpbmcgYXBwcm92YWwgdmlhIG90aGVyIG1lYW5zKS4KICAgICAgICAgIAo8L3A+CjxwPgog ICAgICAgICAgICBXaGVuIGEgZGVjaXNpb24gaXMgZXN0YWJsaXNoZWQsIHRoZSBhdXRob3JpemF0 aW9uIHNlcnZlciBkaXJlY3RzIHRoZSB1c2VyLWFnZW50IHRvIHRoZQogICAgICAgICAgICBwcm92 aWRlZCBjbGllbnQgcmVkaXJlY3Rpb24gVVJJIHVzaW5nIGFuIEhUVFAgcmVkaXJlY3Rpb24gcmVz cG9uc2UsIG9yIGJ5IG90aGVyIG1lYW5zCiAgICAgICAgICAgIGF2YWlsYWJsZSB0byBpdCB2aWEg dGhlIHVzZXItYWdlbnQuCiAgICAgICAgICAKPC9wPgo8YSBuYW1lPSJjb2RlLWF1dGh6LXJlc3Ai PjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAi IGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xh c3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48 L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi40LjEuMiI+PC9hPjxoMz40LjEuMi4mbmJzcDsK QXV0aG9yaXphdGlvbiBSZXNwb25zZTwvaDM+Cgo8cD4KICAgICAgICAgICAgSWYgdGhlIHJlc291 cmNlIG93bmVyIGdyYW50cyB0aGUgYWNjZXNzIHJlcXVlc3QsIHRoZSBhdXRob3JpemF0aW9uIHNl cnZlciBpc3N1ZXMgYW4KICAgICAgICAgICAgYXV0aG9yaXphdGlvbiBjb2RlIGFuZCBkZWxpdmVy cyBpdCB0byB0aGUgY2xpZW50IGJ5IGFkZGluZyB0aGUgZm9sbG93aW5nIHBhcmFtZXRlcnMgdG8K ICAgICAgICAgICAgdGhlIHF1ZXJ5IGNvbXBvbmVudCBvZiB0aGUgcmVkaXJlY3Rpb24gVVJJIHVz aW5nIHRoZQogICAgICAgICAgICA8dHQ+YXBwbGljYXRpb24veC13d3ctZm9ybS11cmxlbmNvZGVk PC90dD4gZm9ybWF0OgogICAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICAgIDwvcD4KPGJsb2Nr cXVvdGUgY2xhc3M9InRleHQiPjxkbD4KPGR0PmNvZGU8L2R0Pgo8ZGQ+CiAgICAgICAgICAgICAg ICAKICAgICAgICAgICAgICAgIFJFUVVJUkVELiBUaGUgYXV0aG9yaXphdGlvbiBjb2RlIGdlbmVy YXRlZCBieSB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIuIFRoZQogICAgICAgICAgICAgICAgYXV0 aG9yaXphdGlvbiBjb2RlIE1VU1QgZXhwaXJlIHNob3J0bHkgYWZ0ZXIgaXQgaXMgaXNzdWVkIHRv IG1pdGlnYXRlIHRoZSByaXNrIG9mCiAgICAgICAgICAgICAgICBsZWFrcy4gQSBtYXhpbXVtIGF1 dGhvcml6YXRpb24gY29kZSBsaWZldGltZSBvZiAxMCBtaW51dGVzIGlzIFJFQ09NTUVOREVELiBU aGUKICAgICAgICAgICAgICAgIGNsaWVudCBNVVNUIE5PVCB1c2UgdGhlIGF1dGhvcml6YXRpb24g Y29kZSBtb3JlIHRoYW4gb25jZS4gSWYgYW4gYXV0aG9yaXphdGlvbiBjb2RlCiAgICAgICAgICAg ICAgICBpcyB1c2VkIG1vcmUgdGhhbiBvbmNlLCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVT VCBkZW55IHRoZSByZXF1ZXN0IGFuZCBTSE9VTEQKICAgICAgICAgICAgICAgIHJldm9rZSAod2hl biBwb3NzaWJsZSkgYWxsIHRva2VucyBwcmV2aW91c2x5IGlzc3VlZCBiYXNlZCBvbiB0aGF0IGF1 dGhvcml6YXRpb24KICAgICAgICAgICAgICAgIGNvZGUuIFRoZSBhdXRob3JpemF0aW9uIGNvZGUg aXMgYm91bmQgdG8gdGhlIGNsaWVudCBpZGVudGlmaWVyIGFuZCByZWRpcmVjdGlvbiBVUkkuCiAg ICAgICAgICAgICAgCjwvZGQ+CjxkdD5zdGF0ZTwvZHQ+CjxkZD4KICAgICAgICAgICAgICAgIAog ICAgICAgICAgICAgICAgUkVRVUlSRUQgaWYgdGhlIDx0dD5zdGF0ZTwvdHQ+IHBhcmFtZXRlciB3 YXMgcHJlc2VudCBpbiB0aGUKICAgICAgICAgICAgICAgIGNsaWVudCBhdXRob3JpemF0aW9uIHJl cXVlc3QuIFRoZSBleGFjdCB2YWx1ZSByZWNlaXZlZCBmcm9tIHRoZSBjbGllbnQuCiAgICAgICAg ICAgICAgCjwvZGQ+CjwvZGw+PC9ibG9ja3F1b3RlPjxwPgogICAgICAgICAgCjwvcD4KPHA+CiAg ICAgICAgICAgICAgRm9yIGV4YW1wbGUsIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciByZWRpcmVj dHMgdGhlIHVzZXItYWdlbnQgYnkgc2VuZGluZyB0aGUKICAgICAgICAgICAgICBmb2xsb3dpbmcg SFRUUCByZXNwb25zZToKICAgICAgICAgICAgCjwvcD48ZGl2IHN0eWxlPSdkaXNwbGF5OiB0YWJs ZTsgd2lkdGg6IDA7IG1hcmdpbi1sZWZ0OiAzZW07IG1hcmdpbi1yaWdodDogYXV0byc+PHByZT4K CiAgSFRUUC8xLjEgMzAyIEZvdW5kCiAgTG9jYXRpb246IGh0dHBzOi8vY2xpZW50LmV4YW1wbGUu Y29tL2NiP2NvZGU9U3BseGxPQmVaUVFZYllTNld4U2JJQQogICAgICAgICAgICAmYW1wO3N0YXRl PXh5egoKPC9wcmU+PC9kaXY+CjxwPgogICAgICAgICAgICBUaGUgY2xpZW50IE1VU1QgaWdub3Jl IHVucmVjb2duaXplZCByZXNwb25zZSBwYXJhbWV0ZXJzLiBUaGUgYXV0aG9yaXphdGlvbiBjb2Rl CiAgICAgICAgICAgIHN0cmluZyBzaXplIGlzIGxlZnQgdW5kZWZpbmVkIGJ5IHRoaXMgc3BlY2lm aWNhdGlvbi4gVGhlIGNsaWVudCBzaG91bGQgYXZvaWQgbWFraW5nCiAgICAgICAgICAgIGFzc3Vt cHRpb25zIGFib3V0IGNvZGUgdmFsdWUgc2l6ZXMuIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBT SE9VTEQgZG9jdW1lbnQgdGhlIHNpemUKICAgICAgICAgICAgb2YgYW55IHZhbHVlIGl0IGlzc3Vl cy4KICAgICAgICAgIAo8L3A+CjxhIG5hbWU9ImNvZGUtYXV0aHotZXJyb3IiPjwvYT48YnIgLz48 aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5n PSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+ PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBu YW1lPSJyZmMuc2VjdGlvbi40LjEuMi4xIj48L2E+PGgzPjQuMS4yLjEuJm5ic3A7CkVycm9yIFJl c3BvbnNlPC9oMz4KCjxwPgogICAgICAgICAgICAgIElmIHRoZSByZXF1ZXN0IGZhaWxzIGR1ZSB0 byBhIG1pc3NpbmcsIGludmFsaWQsIG9yIG1pc21hdGNoaW5nIHJlZGlyZWN0aW9uIFVSSSwgb3Ig aWYKICAgICAgICAgICAgICB0aGUgY2xpZW50IGlkZW50aWZpZXIgaXMgbWlzc2luZyBvciBpbnZh bGlkLCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgU0hPVUxEIGluZm9ybQogICAgICAgICAgICAg IHRoZSByZXNvdXJjZSBvd25lciBvZiB0aGUgZXJyb3IsIGFuZCBNVVNUIE5PVCBhdXRvbWF0aWNh bGx5IHJlZGlyZWN0IHRoZSB1c2VyLWFnZW50CiAgICAgICAgICAgICAgdG8gdGhlIGludmFsaWQg cmVkaXJlY3Rpb24gVVJJLgogICAgICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgICAgICBJZiB0 aGUgcmVzb3VyY2Ugb3duZXIgZGVuaWVzIHRoZSBhY2Nlc3MgcmVxdWVzdCBvciBpZiB0aGUgcmVx dWVzdCBmYWlscyBmb3IgcmVhc29ucwogICAgICAgICAgICAgIG90aGVyIHRoYW4gYSBtaXNzaW5n IG9yIGludmFsaWQgcmVkaXJlY3Rpb24gVVJJLCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgaW5m b3JtcyB0aGUKICAgICAgICAgICAgICBjbGllbnQgYnkgYWRkaW5nIHRoZSBmb2xsb3dpbmcgcGFy YW1ldGVycyB0byB0aGUgcXVlcnkgY29tcG9uZW50IG9mIHRoZSByZWRpcmVjdGlvbgogICAgICAg ICAgICAgIFVSSSB1c2luZyB0aGUgPHR0PmFwcGxpY2F0aW9uL3gtd3d3LWZvcm0tdXJsZW5jb2Rl ZDwvdHQ+IGZvcm1hdDoKICAgICAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICAgICAgPC9wPgo8 YmxvY2txdW90ZSBjbGFzcz0idGV4dCI+PGRsPgo8ZHQ+ZXJyb3I8L2R0Pgo8ZGQ+CiAgICAgICAg ICAgICAgICAgIAogICAgICAgICAgICAgICAgICBSRVFVSVJFRC4gQSBzaW5nbGUgQVNDSUkgPGEg Y2xhc3M9J2luZm8nIGhyZWY9JyNVU0FTQ0lJJz5bVVNBU0NJSV08c3Bhbj4gKDwvc3Bhbj48c3Bh biBjbGFzcz0naW5mbyc+QW1lcmljYW4gTmF0aW9uYWwgU3RhbmRhcmRzIEluc3RpdHV0ZSwgJmxk cXVvO0NvZGVkIENoYXJhY3RlciBTZXQgLS0gNy1iaXQgQW1lcmljYW4gU3RhbmRhcmQgQ29kZSBm b3IgSW5mb3JtYXRpb24gSW50ZXJjaGFuZ2UsJnJkcXVvOyAxOTg2Ljwvc3Bhbj48c3Bhbj4pPC9z cGFuPjwvYT4gZXJyb3IgY29kZSBmcm9tIHRoZSBmb2xsb3dpbmc6CgogICAgICAgICAgICAgICAg ICAKPGJsb2NrcXVvdGUgY2xhc3M9InRleHQiPjxkbD4KPGR0PmludmFsaWRfcmVxdWVzdDwvZHQ+ CjxkZD4KICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgVGhlIHJl cXVlc3QgaXMgbWlzc2luZyBhIHJlcXVpcmVkIHBhcmFtZXRlciwgaW5jbHVkZXMgYW4gaW52YWxp ZAogICAgICAgICAgICAgICAgICAgICAgcGFyYW1ldGVyIHZhbHVlLCBpbmNsdWRlcyBhIHBhcmFt ZXRlciBtb3JlIHRoYW4gb25jZSwgb3IgaXMgb3RoZXJ3aXNlCiAgICAgICAgICAgICAgICAgICAg ICBtYWxmb3JtZWQuCiAgICAgICAgICAgICAgICAgICAgCjwvZGQ+CjxkdD51bmF1dGhvcml6ZWRf Y2xpZW50PC9kdD4KPGRkPgogICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAg ICAgICBUaGUgY2xpZW50IGlzIG5vdCBhdXRob3JpemVkIHRvIHJlcXVlc3QgYW4gYXV0aG9yaXph dGlvbiBjb2RlIHVzaW5nIHRoaXMKICAgICAgICAgICAgICAgICAgICAgIG1ldGhvZC4KICAgICAg ICAgICAgICAgICAgICAKPC9kZD4KPGR0PmFjY2Vzc19kZW5pZWQ8L2R0Pgo8ZGQ+CiAgICAgICAg ICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgIFRoZSByZXNvdXJjZSBvd25lciBv ciBhdXRob3JpemF0aW9uIHNlcnZlciBkZW5pZWQgdGhlIHJlcXVlc3QuCiAgICAgICAgICAgICAg ICAgICAgCjwvZGQ+CjxkdD51bnN1cHBvcnRlZF9yZXNwb25zZV90eXBlPC9kdD4KPGRkPgogICAg ICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICBUaGUgYXV0aG9yaXphdGlv biBzZXJ2ZXIgZG9lcyBub3Qgc3VwcG9ydCBvYnRhaW5pbmcgYW4gYXV0aG9yaXphdGlvbiBjb2Rl CiAgICAgICAgICAgICAgICAgICAgICB1c2luZyB0aGlzIG1ldGhvZC4KICAgICAgICAgICAgICAg ICAgICAKPC9kZD4KPGR0PmludmFsaWRfc2NvcGU8L2R0Pgo8ZGQ+CiAgICAgICAgICAgICAgICAg ICAgICAKICAgICAgICAgICAgICAgICAgICAgIFRoZSByZXF1ZXN0ZWQgc2NvcGUgaXMgaW52YWxp ZCwgdW5rbm93biwgb3IgbWFsZm9ybWVkLgogICAgICAgICAgICAgICAgICAgIAo8L2RkPgo8ZHQ+ c2VydmVyX2Vycm9yPC9kdD4KPGRkPgogICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAg ICAgICAgICAgICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgZW5jb3VudGVyZWQgYW4gdW5leHBl Y3RlZCBjb25kaXRpb24gd2hpY2ggcHJldmVudGVkCiAgICAgICAgICAgICAgICAgICAgICBpdCBm cm9tIGZ1bGZpbGxpbmcgdGhlIHJlcXVlc3QuCiAgICAgICAgICAgICAgICAgICAgCjwvZGQ+Cjxk dD50ZW1wb3JhcmlseV91bmF2YWlsYWJsZTwvZHQ+CjxkZD4KICAgICAgICAgICAgICAgICAgICAg IAogICAgICAgICAgICAgICAgICAgICAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGlzIGN1cnJl bnRseSB1bmFibGUgdG8gaGFuZGxlIHRoZSByZXF1ZXN0IGR1ZSB0byBhCiAgICAgICAgICAgICAg ICAgICAgICB0ZW1wb3Jhcnkgb3ZlcmxvYWRpbmcgb3IgbWFpbnRlbmFuY2Ugb2YgdGhlIHNlcnZl ci4KICAgICAgICAgICAgICAgICAgICAKPC9kZD4KPC9kbD48L2Jsb2NrcXVvdGU+CgoJCSAgVmFs dWVzIGZvciB0aGUgPHR0PmVycm9yPC90dD4gcGFyYW1ldGVyIE1VU1QgTk9UIGluY2x1ZGUKCQkg IGNoYXJhY3RlcnMgb3V0c2lkZSB0aGUgc2V0ICV4MjAtMjEgLyAleDIzLTVCIC8gJXg1RC03RS4K ICAgICAgICAgICAgICAgIAo8L2RkPgo8ZHQ+ZXJyb3JfZGVzY3JpcHRpb248L2R0Pgo8ZGQ+CiAg ICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICBPUFRJT05BTC4gQSBodW1hbi1yZWFk YWJsZSBBU0NJSSA8YSBjbGFzcz0naW5mbycgaHJlZj0nI1VTQVNDSUknPltVU0FTQ0lJXTxzcGFu PiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5BbWVyaWNhbiBOYXRpb25hbCBTdGFuZGFyZHMg SW5zdGl0dXRlLCAmbGRxdW87Q29kZWQgQ2hhcmFjdGVyIFNldCAtLSA3LWJpdCBBbWVyaWNhbiBT dGFuZGFyZCBDb2RlIGZvciBJbmZvcm1hdGlvbiBJbnRlcmNoYW5nZSwmcmRxdW87IDE5ODYuPC9z cGFuPjxzcGFuPik8L3NwYW4+PC9hPiB0ZXh0IHByb3ZpZGluZyBhZGRpdGlvbmFsIGluZm9ybWF0 aW9uLAogICAgICAgICAgICAgICAgICB1c2VkIHRvIGFzc2lzdCB0aGUgY2xpZW50IGRldmVsb3Bl ciBpbiB1bmRlcnN0YW5kaW5nIHRoZSBlcnJvciB0aGF0IG9jY3VycmVkLgoJCSAgPGJyIC8+CgoJ CSAgVmFsdWVzIGZvciB0aGUgPHR0PmVycm9yX2Rlc2NyaXB0aW9uPC90dD4gcGFyYW1ldGVyIE1V U1QgTk9UIGluY2x1ZGUKCQkgIGNoYXJhY3RlcnMgb3V0c2lkZSB0aGUgc2V0ICV4MjAtMjEgLyAl eDIzLTVCIC8gJXg1RC03RS4KICAgICAgICAgICAgICAgIAo8L2RkPgo8ZHQ+ZXJyb3JfdXJpPC9k dD4KPGRkPgogICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgT1BUSU9OQUwuIEEg VVJJIGlkZW50aWZ5aW5nIGEgaHVtYW4tcmVhZGFibGUgd2ViIHBhZ2Ugd2l0aCBpbmZvcm1hdGlv biBhYm91dCB0aGUKICAgICAgICAgICAgICAgICAgZXJyb3IsIHVzZWQgdG8gcHJvdmlkZSB0aGUg Y2xpZW50IGRldmVsb3BlciB3aXRoIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gYWJvdXQgdGhlCiAg ICAgICAgICAgICAgICAgIGVycm9yLgoJCSAgPGJyIC8+CgoJCSAgVmFsdWVzIGZvciB0aGUgPHR0 PmVycm9yX3VyaTwvdHQ+IHBhcmFtZXRlcgoJCSAgTVVTVCBjb25mb3JtIHRvIHRoZSBVUkktUmVm ZXJlbmNlIHN5bnRheCwgYW5kIHRodXMgTVVTVCBOT1QgaW5jbHVkZQoJCSAgY2hhcmFjdGVycyBv dXRzaWRlIHRoZSBzZXQgJXgyMSAvICV4MjMtNUIgLyAleDVELTdFLgogICAgICAgICAgICAgICAg CjwvZGQ+CjxkdD5zdGF0ZTwvZHQ+CjxkZD4KICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAg ICAgICAgIFJFUVVJUkVEIGlmIGEgPHR0PnN0YXRlPC90dD4gcGFyYW1ldGVyIHdhcyBwcmVzZW50 IGluIHRoZQogICAgICAgICAgICAgICAgICBjbGllbnQgYXV0aG9yaXphdGlvbiByZXF1ZXN0LiBU aGUgZXhhY3QgdmFsdWUgcmVjZWl2ZWQgZnJvbSB0aGUgY2xpZW50LgogICAgICAgICAgICAgICAg CjwvZGQ+CjwvZGw+PC9ibG9ja3F1b3RlPjxwPgogICAgICAgICAgICAKPC9wPgo8cD4KICAgICAg ICAgICAgICAgIEZvciBleGFtcGxlLCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgcmVkaXJlY3Rz IHRoZSB1c2VyLWFnZW50IGJ5IHNlbmRpbmcgdGhlCiAgICAgICAgICAgICAgICBmb2xsb3dpbmcg SFRUUCByZXNwb25zZToKICAgICAgICAgICAgICAKPC9wPjxkaXYgc3R5bGU9J2Rpc3BsYXk6IHRh YmxlOyB3aWR0aDogMDsgbWFyZ2luLWxlZnQ6IDNlbTsgbWFyZ2luLXJpZ2h0OiBhdXRvJz48cHJl PgoKICBIVFRQLzEuMSAzMDIgRm91bmQKICBMb2NhdGlvbjogaHR0cHM6Ly9jbGllbnQuZXhhbXBs ZS5jb20vY2I/ZXJyb3I9YWNjZXNzX2RlbmllZCZhbXA7c3RhdGU9eHl6Cgo8L3ByZT48L2Rpdj4K PGEgbmFtZT0idG9rZW4tcmVxIj48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlv dXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249 InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZu YnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uNC4xLjMiPjwv YT48aDM+NC4xLjMuJm5ic3A7CkFjY2VzcyBUb2tlbiBSZXF1ZXN0PC9oMz4KCjxwPgogICAgICAg ICAgICBUaGUgY2xpZW50IG1ha2VzIGEgcmVxdWVzdCB0byB0aGUgdG9rZW4gZW5kcG9pbnQgYnkg YWRkaW5nIHRoZSBmb2xsb3dpbmcgcGFyYW1ldGVycwogICAgICAgICAgICB1c2luZyB0aGUgPHR0 PmFwcGxpY2F0aW9uL3gtd3d3LWZvcm0tdXJsZW5jb2RlZDwvdHQ+IGZvcm1hdCBpbiB0aGUKICAg ICAgICAgICAgSFRUUCByZXF1ZXN0IGVudGl0eS1ib2R5OgogICAgICAgICAgCjwvcD4KPHA+CiAg ICAgICAgICAgIDwvcD4KPGJsb2NrcXVvdGUgY2xhc3M9InRleHQiPjxkbD4KPGR0PmdyYW50X3R5 cGU8L2R0Pgo8ZGQ+CiAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgIFJFUVVJUkVELiBW YWx1ZSBNVVNUIGJlIHNldCB0byA8dHQ+YXV0aG9yaXphdGlvbl9jb2RlPC90dD4uCiAgICAgICAg ICAgICAgCjwvZGQ+CjxkdD5jb2RlPC9kdD4KPGRkPgogICAgICAgICAgICAgICAgCiAgICAgICAg ICAgICAgICBSRVFVSVJFRC4gVGhlIGF1dGhvcml6YXRpb24gY29kZSByZWNlaXZlZCBmcm9tIHRo ZSBhdXRob3JpemF0aW9uIHNlcnZlci4KICAgICAgICAgICAgICAKPC9kZD4KPGR0PnJlZGlyZWN0 X3VyaTwvZHQ+CjxkZD4KICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgUkVRVUlSRUQs IGlmIHRoZSA8dHQ+cmVkaXJlY3RfdXJpPC90dD4gcGFyYW1ldGVyIHdhcyBpbmNsdWRlZCBpbgog ICAgICAgICAgICAgICAgdGhlIGF1dGhvcml6YXRpb24gcmVxdWVzdCBhcyBkZXNjcmliZWQgaW4g PGEgY2xhc3M9J2luZm8nIGhyZWY9JyNjb2RlLWF1dGh6LXJlcSc+U2VjdGlvbiZuYnNwOzQuMS4x PHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkF1dGhvcml6YXRpb24gUmVxdWVzdDwv c3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4sIGFuZAogICAgICAgICAgICAgICAgdGhlaXIgdmFsdWVz IE1VU1QgYmUgaWRlbnRpY2FsLgogICAgICAgICAgICAgIAo8L2RkPgo8L2RsPjwvYmxvY2txdW90 ZT48cD4KICAgICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgICBJZiB0aGUgY2xpZW50IHR5cGUg aXMgY29uZmlkZW50aWFsIG9yIHRoZSBjbGllbnQgd2FzIGlzc3VlZCBjbGllbnQgY3JlZGVudGlh bHMgKG9yCiAgICAgICAgICAgIGFzc2lnbmVkIG90aGVyIGF1dGhlbnRpY2F0aW9uIHJlcXVpcmVt ZW50cyksIHRoZSBjbGllbnQgTVVTVCBhdXRoZW50aWNhdGUgd2l0aCB0aGUKICAgICAgICAgICAg YXV0aG9yaXphdGlvbiBzZXJ2ZXIgYXMgZGVzY3JpYmVkIGluIDxhIGNsYXNzPSdpbmZvJyBocmVm PScjdG9rZW4tZW5kcG9pbnQtYXV0aCc+U2VjdGlvbiZuYnNwOzMuMi4xPHNwYW4+ICg8L3NwYW4+ PHNwYW4gY2xhc3M9J2luZm8nPkNsaWVudCBBdXRoZW50aWNhdGlvbjwvc3Bhbj48c3Bhbj4pPC9z cGFuPjwvYT4uCiAgICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgICAgICBGb3IgZXhhbXBsZSwg dGhlIGNsaWVudCBtYWtlcyB0aGUgZm9sbG93aW5nIEhUVFAgcmVxdWVzdCB1c2luZyBUTFMgKGV4 dHJhIGxpbmUgYnJlYWtzCiAgICAgICAgICAgICAgYXJlIGZvciBkaXNwbGF5IHB1cnBvc2VzIG9u bHkpOgogICAgICAgICAgICAKPC9wPjxkaXYgc3R5bGU9J2Rpc3BsYXk6IHRhYmxlOyB3aWR0aDog MDsgbWFyZ2luLWxlZnQ6IDNlbTsgbWFyZ2luLXJpZ2h0OiBhdXRvJz48cHJlPgoKICBQT1NUIC90 b2tlbiBIVFRQLzEuMQogIEhvc3Q6IHNlcnZlci5leGFtcGxlLmNvbQogIEF1dGhvcml6YXRpb246 IEJhc2ljIGN6WkNhR1JTYTNGME16cG5XREZtUW1GME0ySlcKICBDb250ZW50LVR5cGU6IGFwcGxp Y2F0aW9uL3gtd3d3LWZvcm0tdXJsZW5jb2RlZDtjaGFyc2V0PVVURi04CgogIGdyYW50X3R5cGU9 YXV0aG9yaXphdGlvbl9jb2RlJmFtcDtjb2RlPVNwbHhsT0JlWlFRWWJZUzZXeFNiSUEKICAmYW1w O3JlZGlyZWN0X3VyaT1odHRwcyUzQSUyRiUyRmNsaWVudCUyRWV4YW1wbGUlMkVjb20lMkZjYgoK PC9wcmU+PC9kaXY+CjxwPgogICAgICAgICAgICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVT VDoKICAgICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgICA8L3A+Cjx1bCBjbGFzcz0idGV4dCI+ CjxsaT4KICAgICAgICAgICAgICAgIHJlcXVpcmUgY2xpZW50IGF1dGhlbnRpY2F0aW9uIGZvciBj b25maWRlbnRpYWwgY2xpZW50cyBvciBmb3IgYW55IGNsaWVudCB0aGF0IHdhcwogICAgICAgICAg ICAgICAgaXNzdWVkIGNsaWVudCBjcmVkZW50aWFscyAob3Igd2l0aCBvdGhlciBhdXRoZW50aWNh dGlvbiByZXF1aXJlbWVudHMpLAogICAgICAgICAgICAgIAo8L2xpPgo8bGk+CiAgICAgICAgICAg ICAgICBhdXRoZW50aWNhdGUgdGhlIGNsaWVudCBpZiBjbGllbnQgYXV0aGVudGljYXRpb24gaXMg aW5jbHVkZWQgYW5kIGVuc3VyZSB0aGUKICAgICAgICAgICAgICAgIGF1dGhvcml6YXRpb24gY29k ZSB3YXMgaXNzdWVkIHRvIHRoZSBhdXRoZW50aWNhdGVkIGNsaWVudCwKICAgICAgICAgICAgICAK PC9saT4KPGxpPgogICAgICAgICAgICAgICAgdmVyaWZ5IHRoYXQgdGhlIGF1dGhvcml6YXRpb24g Y29kZSBpcyB2YWxpZCwgYW5kCiAgICAgICAgICAgICAgCjwvbGk+CjxsaT4KICAgICAgICAgICAg ICAgIGVuc3VyZSB0aGF0IHRoZSA8dHQ+cmVkaXJlY3RfdXJpPC90dD4gcGFyYW1ldGVyIGlzIHBy ZXNlbnQgaWYKICAgICAgICAgICAgICAgIHRoZSA8dHQ+cmVkaXJlY3RfdXJpPC90dD4gcGFyYW1l dGVyIHdhcyBpbmNsdWRlZCBpbiB0aGUgaW5pdGlhbAogICAgICAgICAgICAgICAgYXV0aG9yaXph dGlvbiByZXF1ZXN0IGFzIGRlc2NyaWJlZCBpbiA8YSBjbGFzcz0naW5mbycgaHJlZj0nI2NvZGUt YXV0aHotcmVxJz5TZWN0aW9uJm5ic3A7NC4xLjE8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0n aW5mbyc+QXV0aG9yaXphdGlvbiBSZXF1ZXN0PC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPiwgYW5k IGlmCiAgICAgICAgICAgICAgICBpbmNsdWRlZCBlbnN1cmUgdGhlaXIgdmFsdWVzIGFyZSBpZGVu dGljYWwuCiAgICAgICAgICAgICAgCjwvbGk+CjwvdWw+PHA+CiAgICAgICAgICAKPC9wPgo8YSBu YW1lPSJhbmNob3IyNiI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBj ZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdo dCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8 L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLjQuMS40Ij48L2E+PGgz PjQuMS40LiZuYnNwOwpBY2Nlc3MgVG9rZW4gUmVzcG9uc2U8L2gzPgoKPHA+CiAgICAgICAgICAg IElmIHRoZSBhY2Nlc3MgdG9rZW4gcmVxdWVzdCBpcyB2YWxpZCBhbmQgYXV0aG9yaXplZCwgdGhl IGF1dGhvcml6YXRpb24gc2VydmVyIGlzc3VlcyBhbgogICAgICAgICAgICBhY2Nlc3MgdG9rZW4g YW5kIG9wdGlvbmFsIHJlZnJlc2ggdG9rZW4gYXMgZGVzY3JpYmVkIGluIDxhIGNsYXNzPSdpbmZv JyBocmVmPScjdG9rZW4tcmVzcG9uc2UnPlNlY3Rpb24mbmJzcDs1LjE8c3Bhbj4gKDwvc3Bhbj48 c3BhbiBjbGFzcz0naW5mbyc+U3VjY2Vzc2Z1bCBSZXNwb25zZTwvc3Bhbj48c3Bhbj4pPC9zcGFu PjwvYT4uCiAgICAgICAgICAgIElmIHRoZSByZXF1ZXN0IGNsaWVudCBhdXRoZW50aWNhdGlvbiBm YWlsZWQgb3IgaXMgaW52YWxpZCwgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHJldHVybnMKICAg ICAgICAgICAgYW4gZXJyb3IgcmVzcG9uc2UgYXMgZGVzY3JpYmVkIGluIDxhIGNsYXNzPSdpbmZv JyBocmVmPScjdG9rZW4tZXJyb3JzJz5TZWN0aW9uJm5ic3A7NS4yPHNwYW4+ICg8L3NwYW4+PHNw YW4gY2xhc3M9J2luZm8nPkVycm9yIFJlc3BvbnNlPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPi4K ICAgICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgICAgIEFuIGV4YW1wbGUgc3VjY2Vzc2Z1bCBy ZXNwb25zZToKICAgICAgICAgICAgCjwvcD48ZGl2IHN0eWxlPSdkaXNwbGF5OiB0YWJsZTsgd2lk dGg6IDA7IG1hcmdpbi1sZWZ0OiAzZW07IG1hcmdpbi1yaWdodDogYXV0byc+PHByZT4KCiAgSFRU UC8xLjEgMjAwIE9LCiAgQ29udGVudC1UeXBlOiBhcHBsaWNhdGlvbi9qc29uO2NoYXJzZXQ9VVRG LTgKICBDYWNoZS1Db250cm9sOiBuby1zdG9yZQogIFByYWdtYTogbm8tY2FjaGUKCiAgewogICAg ImFjY2Vzc190b2tlbiI6IjJZb3RuRlpGRWpyMXpDc2ljTVdwQUEiLAogICAgInRva2VuX3R5cGUi OiJleGFtcGxlIiwKICAgICJleHBpcmVzX2luIjozNjAwLAogICAgInJlZnJlc2hfdG9rZW4iOiJ0 R3p2M0pPa0YwWEc1UXgyVGxLV0lBIiwKICAgICJleGFtcGxlX3BhcmFtZXRlciI6ImV4YW1wbGVf dmFsdWUiCiAgfQoKPC9wcmU+PC9kaXY+CjxhIG5hbWU9ImdyYW50LWltcGxpY2l0Ij48L2E+PGJy IC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3Bh Y2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0Ni dWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4K PGEgbmFtZT0icmZjLnNlY3Rpb24uNC4yIj48L2E+PGgzPjQuMi4mbmJzcDsKSW1wbGljaXQgR3Jh bnQ8L2gzPgoKPHA+CiAgICAgICAgICBUaGUgaW1wbGljaXQgZ3JhbnQgdHlwZSBpcyB1c2VkIHRv IG9idGFpbiBhY2Nlc3MgdG9rZW5zIChpdCBkb2VzIG5vdCBzdXBwb3J0IHRoZSBpc3N1YW5jZQog ICAgICAgICAgb2YgcmVmcmVzaCB0b2tlbnMpIGFuZCBpcyBvcHRpbWl6ZWQgZm9yIHB1YmxpYyBj bGllbnRzIGtub3duIHRvIG9wZXJhdGUgYSBwYXJ0aWN1bGFyCiAgICAgICAgICByZWRpcmVjdGlv biBVUkkuIFRoZXNlIGNsaWVudHMgYXJlIHR5cGljYWxseSBpbXBsZW1lbnRlZCBpbiBhIGJyb3dz ZXIgdXNpbmcgYSBzY3JpcHRpbmcKICAgICAgICAgIGxhbmd1YWdlIHN1Y2ggYXMgSmF2YVNjcmlw dC4KICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgIEFzIGEgcmVkaXJlY3Rpb24tYmFzZWQgZmxv dywgdGhlIGNsaWVudCBtdXN0IGJlIGNhcGFibGUgb2YgaW50ZXJhY3Rpbmcgd2l0aCB0aGUKICAg ICAgICAgIHJlc291cmNlIG93bmVyJ3MgdXNlci1hZ2VudCAodHlwaWNhbGx5IGEgd2ViIGJyb3dz ZXIpIGFuZCBjYXBhYmxlIG9mIHJlY2VpdmluZyBpbmNvbWluZwogICAgICAgICAgcmVxdWVzdHMg KHZpYSByZWRpcmVjdGlvbikgZnJvbSB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIuCiAgICAgICAg CjwvcD4KPHA+CiAgICAgICAgICBVbmxpa2UgdGhlIGF1dGhvcml6YXRpb24gY29kZSBncmFudCB0 eXBlIGluIHdoaWNoIHRoZSBjbGllbnQgbWFrZXMgc2VwYXJhdGUgcmVxdWVzdHMgZm9yCiAgICAg ICAgICBhdXRob3JpemF0aW9uIGFuZCBhY2Nlc3MgdG9rZW4sIHRoZSBjbGllbnQgcmVjZWl2ZXMg dGhlIGFjY2VzcyB0b2tlbiBhcyB0aGUgcmVzdWx0IG9mIHRoZQogICAgICAgICAgYXV0aG9yaXph dGlvbiByZXF1ZXN0LgogICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgVGhlIGltcGxpY2l0IGdy YW50IHR5cGUgZG9lcyBub3QgaW5jbHVkZSBjbGllbnQgYXV0aGVudGljYXRpb24sIGFuZCByZWxp ZXMgb24gdGhlCiAgICAgICAgICBwcmVzZW5jZSBvZiB0aGUgcmVzb3VyY2Ugb3duZXIgYW5kIHRo ZSByZWdpc3RyYXRpb24gb2YgdGhlIHJlZGlyZWN0aW9uIFVSSS4gQmVjYXVzZSB0aGUKICAgICAg ICAgIGFjY2VzcyB0b2tlbiBpcyBlbmNvZGVkIGludG8gdGhlIHJlZGlyZWN0aW9uIFVSSSwgaXQg bWF5IGJlIGV4cG9zZWQgdG8gdGhlIHJlc291cmNlIG93bmVyCiAgICAgICAgICBhbmQgb3RoZXIg YXBwbGljYXRpb25zIHJlc2lkaW5nIG9uIHRoZSBzYW1lIGRldmljZS4KICAgICAgICAKPC9wPjxi ciAvPjxociBjbGFzcz0iaW5zZXJ0IiAvPgo8YSBuYW1lPSJGaWd1cmUtNCI+PC9hPgo8ZGl2IHN0 eWxlPSdkaXNwbGF5OiB0YWJsZTsgd2lkdGg6IDA7IG1hcmdpbi1sZWZ0OiAzZW07IG1hcmdpbi1y aWdodDogYXV0byc+PHByZT4KCiAgKy0tLS0tLS0tLS0rCiAgfCBSZXNvdXJjZSB8CiAgfCAgT3du ZXIgICB8CiAgfCAgICAgICAgICB8CiAgKy0tLS0tLS0tLS0rCiAgICAgICBeCiAgICAgICB8CiAg ICAgIChCKQogICstLS0tfC0tLS0tKyAgICAgICAgICBDbGllbnQgSWRlbnRpZmllciAgICAgKy0t LS0tLS0tLS0tLS0tLSsKICB8ICAgICAgICAgLSstLS0tKEEpLS0gJmFtcDsgUmVkaXJlY3Rpb24g VVJJIC0tLSZndDt8ICAgICAgICAgICAgICAgfAogIHwgIFVzZXItICAgfCAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgfCBBdXRob3JpemF0aW9uIHwKICB8ICBBZ2VudCAgLXwtLS0tKEIp LS0gVXNlciBhdXRoZW50aWNhdGVzIC0tJmd0O3wgICAgIFNlcnZlciAgICB8CiAgfCAgICAgICAg ICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgfAogIHwg ICAgICAgICAgfCZsdDstLS0oQyktLS0gUmVkaXJlY3Rpb24gVVJJIC0tLS0mbHQ7fCAgICAgICAg ICAgICAgIHwKICB8ICAgICAgICAgIHwgICAgICAgICAgd2l0aCBBY2Nlc3MgVG9rZW4gICAgICst LS0tLS0tLS0tLS0tLS0rCiAgfCAgICAgICAgICB8ICAgICAgICAgICAgaW4gRnJhZ21lbnQKICB8 ICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0t LS0rCiAgfCAgICAgICAgICB8LS0tLShEKS0tLSBSZWRpcmVjdGlvbiBVUkkgLS0tLSZndDt8ICAg V2ViLUhvc3RlZCAgfAogIHwgICAgICAgICAgfCAgICAgICAgICB3aXRob3V0IEZyYWdtZW50ICAg ICAgfCAgICAgQ2xpZW50ICAgIHwKICB8ICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHwgICAgUmVzb3VyY2UgICB8CiAgfCAgICAgKEYpICB8Jmx0Oy0tLShFKS0tLS0t LS0gU2NyaXB0IC0tLS0tLS0tLSZsdDt8ICAgICAgICAgICAgICAgfAogIHwgICAgICAgICAgfCAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLSsKICArLXwtLS0t LS0tLSsKICAgIHwgICAgfAogICAoQSkgIChHKSBBY2Nlc3MgVG9rZW4KICAgIHwgICAgfAogICAg XiAgICB2CiAgKy0tLS0tLS0tLSsKICB8ICAgICAgICAgfAogIHwgIENsaWVudCB8CiAgfCAgICAg ICAgIHwKICArLS0tLS0tLS0tKwoKPC9wcmU+PC9kaXY+CjxwPgogICAgICAgICAgICBOb3RlOiBU aGUgbGluZXMgaWxsdXN0cmF0aW5nIHN0ZXBzIEEgYW5kIEIgYXJlIGJyb2tlbiBpbnRvIHR3byBw YXJ0cyBhcyB0aGV5IHBhc3MKICAgICAgICAgICAgdGhyb3VnaCB0aGUgdXNlci1hZ2VudC4KICAg ICAgICAgIAo8L3A+PHRhYmxlIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5n PSIyIiBhbGlnbj0iY2VudGVyIj48dHI+PHRkIGFsaWduPSJjZW50ZXIiPjxmb250IGZhY2U9Im1v bmFjbywgTVMgU2FucyBTZXJpZiIgc2l6ZT0iMSI+PGI+Jm5ic3A7RmlndXJlJm5ic3A7NDogSW1w bGljaXQgR3JhbnQgRmxvdyZuYnNwOzwvYj48L2ZvbnQ+PGJyIC8+PC90ZD48L3RyPjwvdGFibGU+ PGhyIGNsYXNzPSJpbnNlcnQiIC8+Cgo8cD4KICAgICAgICAgIFRoZSBmbG93IGlsbHVzdHJhdGVk IGluIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjRmlndXJlLTQnPkZpZ3VyZSZuYnNwOzQ8c3Bhbj4g KDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+SW1wbGljaXQgR3JhbnQgRmxvdzwvc3Bhbj48c3Bh bj4pPC9zcGFuPjwvYT4gaW5jbHVkZXMgdGhlIGZvbGxvd2luZyBzdGVwczoKICAgICAgICAKPC9w Pgo8cD4KICAgICAgICAgIDwvcD4KPGJsb2NrcXVvdGUgY2xhc3M9InRleHQiPjxkbD4KPGR0PihB KTwvZHQ+CjxkZD4KICAgICAgICAgICAgICBUaGUgY2xpZW50IGluaXRpYXRlcyB0aGUgZmxvdyBi eSBkaXJlY3RpbmcgdGhlIHJlc291cmNlIG93bmVyJ3MgdXNlci1hZ2VudCB0byB0aGUKICAgICAg ICAgICAgICBhdXRob3JpemF0aW9uIGVuZHBvaW50LiBUaGUgY2xpZW50IGluY2x1ZGVzIGl0cyBj bGllbnQgaWRlbnRpZmllciwgcmVxdWVzdGVkCiAgICAgICAgICAgICAgc2NvcGUsIGxvY2FsIHN0 YXRlLCBhbmQgYSByZWRpcmVjdGlvbiBVUkkgdG8gd2hpY2ggdGhlIGF1dGhvcml6YXRpb24gc2Vy dmVyIHdpbGwgc2VuZAogICAgICAgICAgICAgIHRoZSB1c2VyLWFnZW50IGJhY2sgb25jZSBhY2Nl c3MgaXMgZ3JhbnRlZCAob3IgZGVuaWVkKS4KICAgICAgICAgICAgCjwvZGQ+CjxkdD4oQik8L2R0 Pgo8ZGQ+CiAgICAgICAgICAgICAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGF1dGhlbnRpY2F0 ZXMgdGhlIHJlc291cmNlIG93bmVyICh2aWEgdGhlIHVzZXItYWdlbnQpIGFuZAogICAgICAgICAg ICAgIGVzdGFibGlzaGVzIHdoZXRoZXIgdGhlIHJlc291cmNlIG93bmVyIGdyYW50cyBvciBkZW5p ZXMgdGhlIGNsaWVudCdzIGFjY2VzcyByZXF1ZXN0LgogICAgICAgICAgICAKPC9kZD4KPGR0PihD KTwvZHQ+CjxkZD4KICAgICAgICAgICAgICBBc3N1bWluZyB0aGUgcmVzb3VyY2Ugb3duZXIgZ3Jh bnRzIGFjY2VzcywgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHJlZGlyZWN0cyB0aGUKICAgICAg ICAgICAgICB1c2VyLWFnZW50IGJhY2sgdG8gdGhlIGNsaWVudCB1c2luZyB0aGUgcmVkaXJlY3Rp b24gVVJJIHByb3ZpZGVkIGVhcmxpZXIuIFRoZQogICAgICAgICAgICAgIHJlZGlyZWN0aW9uIFVS SSBpbmNsdWRlcyB0aGUgYWNjZXNzIHRva2VuIGluIHRoZSBVUkkgZnJhZ21lbnQuCiAgICAgICAg ICAgIAo8L2RkPgo8ZHQ+KEQpPC9kdD4KPGRkPgogICAgICAgICAgICAgIFRoZSB1c2VyLWFnZW50 IGZvbGxvd3MgdGhlIHJlZGlyZWN0aW9uIGluc3RydWN0aW9ucyBieSBtYWtpbmcgYSByZXF1ZXN0 IHRvIHRoZQogICAgICAgICAgICAgIHdlYi1ob3N0ZWQgY2xpZW50IHJlc291cmNlICh3aGljaCBk b2VzIG5vdCBpbmNsdWRlIHRoZSBmcmFnbWVudCBwZXIKICAgICAgICAgICAgICA8YSBjbGFzcz0n aW5mbycgaHJlZj0nI1JGQzI2MTYnPltSRkMyNjE2XTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNz PSdpbmZvJz5GaWVsZGluZywgUi4sIEdldHR5cywgSi4sIE1vZ3VsLCBKLiwgRnJ5c3R5aywgSC4s IE1hc2ludGVyLCBMLiwgTGVhY2gsIFAuLCBhbmQgVC4gQmVybmVycy1MZWUsICZsZHF1bztIeXBl cnRleHQgVHJhbnNmZXIgUHJvdG9jb2wgLS0gSFRUUC8xLjEsJnJkcXVvOyBKdW5lJm5ic3A7MTk5 OS48L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+KS4gVGhlIHVzZXItYWdlbnQgcmV0YWlucyB0aGUg ZnJhZ21lbnQgaW5mb3JtYXRpb24gbG9jYWxseS4KICAgICAgICAgICAgCjwvZGQ+CjxkdD4oRSk8 L2R0Pgo8ZGQ+CiAgICAgICAgICAgICAgVGhlIHdlYi1ob3N0ZWQgY2xpZW50IHJlc291cmNlIHJl dHVybnMgYSB3ZWIgcGFnZSAodHlwaWNhbGx5IGFuIEhUTUwgZG9jdW1lbnQgd2l0aCBhbgogICAg ICAgICAgICAgIGVtYmVkZGVkIHNjcmlwdCkgY2FwYWJsZSBvZiBhY2Nlc3NpbmcgdGhlIGZ1bGwg cmVkaXJlY3Rpb24gVVJJIGluY2x1ZGluZyB0aGUgZnJhZ21lbnQKICAgICAgICAgICAgICByZXRh aW5lZCBieSB0aGUgdXNlci1hZ2VudCwgYW5kIGV4dHJhY3RpbmcgdGhlIGFjY2VzcyB0b2tlbiAo YW5kIG90aGVyIHBhcmFtZXRlcnMpCiAgICAgICAgICAgICAgY29udGFpbmVkIGluIHRoZSBmcmFn bWVudC4KICAgICAgICAgICAgCjwvZGQ+CjxkdD4oRik8L2R0Pgo8ZGQ+CiAgICAgICAgICAgICAg VGhlIHVzZXItYWdlbnQgZXhlY3V0ZXMgdGhlIHNjcmlwdCBwcm92aWRlZCBieSB0aGUgd2ViLWhv c3RlZCBjbGllbnQgcmVzb3VyY2UKICAgICAgICAgICAgICBsb2NhbGx5LCB3aGljaCBleHRyYWN0 cyB0aGUgYWNjZXNzIHRva2VuIGFuZCBwYXNzZXMgaXQgdG8gdGhlIGNsaWVudC4KICAgICAgICAg ICAgCjwvZGQ+CjwvZGw+PC9ibG9ja3F1b3RlPjxwPgogICAgICAgIAo8L3A+CjxhIG5hbWU9Imlt cGxpY2l0LWF1dGh6LXJlcSI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0 IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJy aWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJz cDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLjQuMi4xIj48L2E+ PGgzPjQuMi4xLiZuYnNwOwpBdXRob3JpemF0aW9uIFJlcXVlc3Q8L2gzPgoKPHA+CiAgICAgICAg ICAgIFRoZSBjbGllbnQgY29uc3RydWN0cyB0aGUgcmVxdWVzdCBVUkkgYnkgYWRkaW5nIHRoZSBm b2xsb3dpbmcgcGFyYW1ldGVycyB0byB0aGUKICAgICAgICAgICAgcXVlcnkgY29tcG9uZW50IG9m IHRoZSBhdXRob3JpemF0aW9uIGVuZHBvaW50IFVSSSB1c2luZyB0aGUKICAgICAgICAgICAgPHR0 PmFwcGxpY2F0aW9uL3gtd3d3LWZvcm0tdXJsZW5jb2RlZDwvdHQ+IGZvcm1hdDoKICAgICAgICAg IAo8L3A+CjxwPgogICAgICAgICAgICA8L3A+CjxibG9ja3F1b3RlIGNsYXNzPSJ0ZXh0Ij48ZGw+ CjxkdD5yZXNwb25zZV90eXBlPC9kdD4KPGRkPgogICAgICAgICAgICAgICAgCiAgICAgICAgICAg ICAgICBSRVFVSVJFRC4gVmFsdWUgTVVTVCBiZSBzZXQgdG8gPHR0PnRva2VuPC90dD4uCiAgICAg ICAgICAgICAgCjwvZGQ+CjxkdD5jbGllbnRfaWQ8L2R0Pgo8ZGQ+CiAgICAgICAgICAgICAgICAK ICAgICAgICAgICAgICAgIFJFUVVJUkVELiBUaGUgY2xpZW50IGlkZW50aWZpZXIgYXMgZGVzY3Jp YmVkIGluCiAgICAgICAgICAgICAgICA8YSBjbGFzcz0naW5mbycgaHJlZj0nI2NsaWVudC1pZGVu dGlmaWVyJz5TZWN0aW9uJm5ic3A7Mi4yPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8n PkNsaWVudCBJZGVudGlmaWVyPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPi4KICAgICAgICAgICAg ICAKPC9kZD4KPGR0PnJlZGlyZWN0X3VyaTwvZHQ+CjxkZD4KICAgICAgICAgICAgICAgIAogICAg ICAgICAgICAgICAgT1BUSU9OQUwuIEFzIGRlc2NyaWJlZCBpbiA8YSBjbGFzcz0naW5mbycgaHJl Zj0nI3JlZGlyZWN0LXVyaSc+U2VjdGlvbiZuYnNwOzMuMS4yPHNwYW4+ICg8L3NwYW4+PHNwYW4g Y2xhc3M9J2luZm8nPlJlZGlyZWN0aW9uIEVuZHBvaW50PC9zcGFuPjxzcGFuPik8L3NwYW4+PC9h Pi4KICAgICAgICAgICAgICAKPC9kZD4KPGR0PnNjb3BlPC9kdD4KPGRkPgogICAgICAgICAgICAg ICAgCiAgICAgICAgICAgICAgICBPUFRJT05BTC4gVGhlIHNjb3BlIG9mIHRoZSBhY2Nlc3MgcmVx dWVzdCBhcyBkZXNjcmliZWQgYnkgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNzY29wZSc+U2VjdGlv biZuYnNwOzMuMzxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5BY2Nlc3MgVG9rZW4g U2NvcGU8L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+LgogICAgICAgICAgICAgIAo8L2RkPgo8ZHQ+ c3RhdGU8L2R0Pgo8ZGQ+CiAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgIFJFQ09NTUVO REVELiBBbiBvcGFxdWUgdmFsdWUgdXNlZCBieSB0aGUgY2xpZW50IHRvIG1haW50YWluIHN0YXRl IGJldHdlZW4gdGhlIHJlcXVlc3QKICAgICAgICAgICAgICAgIGFuZCBjYWxsYmFjay4gVGhlIGF1 dGhvcml6YXRpb24gc2VydmVyIGluY2x1ZGVzIHRoaXMgdmFsdWUgd2hlbiByZWRpcmVjdGluZyB0 aGUKICAgICAgICAgICAgICAgIHVzZXItYWdlbnQgYmFjayB0byB0aGUgY2xpZW50LiBUaGUgcGFy YW1ldGVyIFNIT1VMRCBiZSB1c2VkIGZvciBwcmV2ZW50aW5nCiAgICAgICAgICAgICAgICBjcm9z cy1zaXRlIHJlcXVlc3QgZm9yZ2VyeSBhcyBkZXNjcmliZWQgaW4gPGEgY2xhc3M9J2luZm8nIGhy ZWY9JyNDU1JGJz5TZWN0aW9uJm5ic3A7MTAuMTI8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0n aW5mbyc+Q3Jvc3MtU2l0ZSBSZXF1ZXN0IEZvcmdlcnk8L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+ LgogICAgICAgICAgICAgIAo8L2RkPgo8L2RsPjwvYmxvY2txdW90ZT48cD4KICAgICAgICAgIAo8 L3A+CjxwPgogICAgICAgICAgICBUaGUgY2xpZW50IGRpcmVjdHMgdGhlIHJlc291cmNlIG93bmVy IHRvIHRoZSBjb25zdHJ1Y3RlZCBVUkkgdXNpbmcgYW4gSFRUUCByZWRpcmVjdGlvbgogICAgICAg ICAgICByZXNwb25zZSwgb3IgYnkgb3RoZXIgbWVhbnMgYXZhaWxhYmxlIHRvIGl0IHZpYSB0aGUg dXNlci1hZ2VudC4KICAgICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgICAgIEZvciBleGFtcGxl LCB0aGUgY2xpZW50IGRpcmVjdHMgdGhlIHVzZXItYWdlbnQgdG8gbWFrZSB0aGUgZm9sbG93aW5n IEhUVFAgcmVxdWVzdAogICAgICAgICAgICAgIHVzaW5nIFRMUyAoZXh0cmEgbGluZSBicmVha3Mg YXJlIGZvciBkaXNwbGF5IHB1cnBvc2VzIG9ubHkpOgogICAgICAgICAgICAKPC9wPjxkaXYgc3R5 bGU9J2Rpc3BsYXk6IHRhYmxlOyB3aWR0aDogMDsgbWFyZ2luLWxlZnQ6IDNlbTsgbWFyZ2luLXJp Z2h0OiBhdXRvJz48cHJlPgoKICBHRVQgL2F1dGhvcml6ZT9yZXNwb25zZV90eXBlPXRva2VuJmFt cDtjbGllbnRfaWQ9czZCaGRSa3F0MyZhbXA7c3RhdGU9eHl6CiAgICAgICZhbXA7cmVkaXJlY3Rf dXJpPWh0dHBzJTNBJTJGJTJGY2xpZW50JTJFZXhhbXBsZSUyRWNvbSUyRmNiIEhUVFAvMS4xCiAg SG9zdDogc2VydmVyLmV4YW1wbGUuY29tCgo8L3ByZT48L2Rpdj4KPHA+CiAgICAgICAgICAgIFRo ZSBhdXRob3JpemF0aW9uIHNlcnZlciB2YWxpZGF0ZXMgdGhlIHJlcXVlc3QgdG8gZW5zdXJlIGFs bCByZXF1aXJlZCBwYXJhbWV0ZXJzIGFyZQogICAgICAgICAgICBwcmVzZW50IGFuZCB2YWxpZC4g VGhlIGF1dGhvcml6YXRpb24gc2VydmVyIE1VU1QgdmVyaWZ5IHRoYXQgdGhlIHJlZGlyZWN0aW9u IFVSSSB0byB3aGljaAogICAgICAgICAgICBpdCB3aWxsIHJlZGlyZWN0IHRoZSBhY2Nlc3MgdG9r ZW4gbWF0Y2hlcyBhIHJlZGlyZWN0aW9uIFVSSSByZWdpc3RlcmVkIGJ5IHRoZSBjbGllbnQgYXMK ICAgICAgICAgICAgZGVzY3JpYmVkIGluIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjcmVkaXJlY3Qt dXJpJz5TZWN0aW9uJm5ic3A7My4xLjI8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+ UmVkaXJlY3Rpb24gRW5kcG9pbnQ8L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+LgogICAgICAgICAg CjwvcD4KPHA+CiAgICAgICAgICAgIElmIHRoZSByZXF1ZXN0IGlzIHZhbGlkLCB0aGUgYXV0aG9y aXphdGlvbiBzZXJ2ZXIgYXV0aGVudGljYXRlcyB0aGUgcmVzb3VyY2Ugb3duZXIgYW5kCiAgICAg ICAgICAgIG9idGFpbnMgYW4gYXV0aG9yaXphdGlvbiBkZWNpc2lvbiAoYnkgYXNraW5nIHRoZSBy ZXNvdXJjZSBvd25lciBvciBieSBlc3RhYmxpc2hpbmcKICAgICAgICAgICAgYXBwcm92YWwgdmlh IG90aGVyIG1lYW5zKS4KICAgICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgICBXaGVuIGEgZGVj aXNpb24gaXMgZXN0YWJsaXNoZWQsIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBkaXJlY3RzIHRo ZSB1c2VyLWFnZW50IHRvIHRoZQogICAgICAgICAgICBwcm92aWRlZCBjbGllbnQgcmVkaXJlY3Rp b24gVVJJIHVzaW5nIGFuIEhUVFAgcmVkaXJlY3Rpb24gcmVzcG9uc2UsIG9yIGJ5IG90aGVyIG1l YW5zCiAgICAgICAgICAgIGF2YWlsYWJsZSB0byBpdCB2aWEgdGhlIHVzZXItYWdlbnQuCiAgICAg ICAgICAKPC9wPgo8YSBuYW1lPSJpbXBsaWNpdC1hdXRoei1yZXNwIj48L2E+PGJyIC8+PGhyIC8+ Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIg Y2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhy ZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0i cmZjLnNlY3Rpb24uNC4yLjIiPjwvYT48aDM+NC4yLjIuJm5ic3A7CkFjY2VzcyBUb2tlbiBSZXNw b25zZTwvaDM+Cgo8cD4KICAgICAgICAgICAgSWYgdGhlIHJlc291cmNlIG93bmVyIGdyYW50cyB0 aGUgYWNjZXNzIHJlcXVlc3QsIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBpc3N1ZXMgYW4KICAg ICAgICAgICAgYWNjZXNzIHRva2VuIGFuZCBkZWxpdmVycyBpdCB0byB0aGUgY2xpZW50IGJ5IGFk ZGluZyB0aGUgZm9sbG93aW5nIHBhcmFtZXRlcnMgdG8KICAgICAgICAgICAgdGhlIGZyYWdtZW50 IGNvbXBvbmVudCBvZiB0aGUgcmVkaXJlY3Rpb24gVVJJIHVzaW5nIHRoZQogICAgICAgICAgICA8 dHQ+YXBwbGljYXRpb24veC13d3ctZm9ybS11cmxlbmNvZGVkPC90dD4gZm9ybWF0OgogICAgICAg ICAgCjwvcD4KPHA+CiAgICAgICAgICAgIDwvcD4KPGJsb2NrcXVvdGUgY2xhc3M9InRleHQiPjxk bD4KPGR0PmFjY2Vzc190b2tlbjwvZHQ+CjxkZD4KICAgICAgICAgICAgICAgIAogICAgICAgICAg ICAgICAgUkVRVUlSRUQuIFRoZSBhY2Nlc3MgdG9rZW4gaXNzdWVkIGJ5IHRoZSBhdXRob3JpemF0 aW9uIHNlcnZlci4KICAgICAgICAgICAgICAKPC9kZD4KPGR0PnRva2VuX3R5cGU8L2R0Pgo8ZGQ+ CiAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgIFJFUVVJUkVELiBUaGUgdHlwZSBvZiB0 aGUgdG9rZW4gaXNzdWVkIGFzIGRlc2NyaWJlZCBpbgogICAgICAgICAgICAgICAgPGEgY2xhc3M9 J2luZm8nIGhyZWY9JyN0b2tlbi10eXBlcyc+U2VjdGlvbiZuYnNwOzcuMTxzcGFuPiAoPC9zcGFu PjxzcGFuIGNsYXNzPSdpbmZvJz5BY2Nlc3MgVG9rZW4gVHlwZXM8L3NwYW4+PHNwYW4+KTwvc3Bh bj48L2E+LiBWYWx1ZSBpcyBjYXNlIGluc2Vuc2l0aXZlLgogICAgICAgICAgICAgIAo8L2RkPgo8 ZHQ+ZXhwaXJlc19pbjwvZHQ+CjxkZD4KICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAg UkVDT01NRU5ERUQuIFRoZSBsaWZldGltZSBpbiBzZWNvbmRzIG9mIHRoZSBhY2Nlc3MgdG9rZW4u IEZvciBleGFtcGxlLCB0aGUgdmFsdWUKICAgICAgICAgICAgICAgIDx0dD4zNjAwPC90dD4gZGVu b3RlcyB0aGF0IHRoZSBhY2Nlc3MgdG9rZW4gd2lsbCBleHBpcmUgaW4gb25lCiAgICAgICAgICAg ICAgICBob3VyIGZyb20gdGhlIHRpbWUgdGhlIHJlc3BvbnNlIHdhcyBnZW5lcmF0ZWQuIElmIG9t aXR0ZWQsIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlcgogICAgICAgICAgICAgICAgU0hPVUxEIHBy b3ZpZGUgdGhlIGV4cGlyYXRpb24gdGltZSB2aWEgb3RoZXIgbWVhbnMgb3IgZG9jdW1lbnQgdGhl IGRlZmF1bHQgdmFsdWUuCiAgICAgICAgICAgICAgCjwvZGQ+CjxkdD5zY29wZTwvZHQ+CjxkZD4K ICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgT1BUSU9OQUwsIGlmIGlkZW50aWNhbCB0 byB0aGUgc2NvcGUgcmVxdWVzdGVkIGJ5IHRoZSBjbGllbnQsIG90aGVyd2lzZSBSRVFVSVJFRC4g VGhlCiAgICAgICAgICAgICAgICBzY29wZSBvZiB0aGUgYWNjZXNzIHRva2VuIGFzIGRlc2NyaWJl ZCBieSA8YSBjbGFzcz0naW5mbycgaHJlZj0nI3Njb3BlJz5TZWN0aW9uJm5ic3A7My4zPHNwYW4+ ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkFjY2VzcyBUb2tlbiBTY29wZTwvc3Bhbj48c3Bh bj4pPC9zcGFuPjwvYT4uCiAgICAgICAgICAgICAgCjwvZGQ+CjxkdD5zdGF0ZTwvZHQ+CjxkZD4K ICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgUkVRVUlSRUQgaWYgdGhlIDx0dD5zdGF0 ZTwvdHQ+IHBhcmFtZXRlciB3YXMgcHJlc2VudCBpbiB0aGUKICAgICAgICAgICAgICAgIGNsaWVu dCBhdXRob3JpemF0aW9uIHJlcXVlc3QuIFRoZSBleGFjdCB2YWx1ZSByZWNlaXZlZCBmcm9tIHRo ZSBjbGllbnQuCiAgICAgICAgICAgICAgCjwvZGQ+CjwvZGw+PC9ibG9ja3F1b3RlPjxwPgogICAg ICAgICAgCjwvcD4KPHA+CiAgICAgICAgICAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBNVVNU IE5PVCBpc3N1ZSBhIHJlZnJlc2ggdG9rZW4uCiAgICAgICAgICAKPC9wPgo8cD4KICAgICAgICAg ICAgICBGb3IgZXhhbXBsZSwgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHJlZGlyZWN0cyB0aGUg dXNlci1hZ2VudCBieSBzZW5kaW5nIHRoZQogICAgICAgICAgICAgIGZvbGxvd2luZyBIVFRQIHJl c3BvbnNlIChVUkkgZXh0cmEgbGluZSBicmVha3MgYXJlIGZvciBkaXNwbGF5IHB1cnBvc2VzIG9u bHkpOgogICAgICAgICAgICAKPC9wPjxkaXYgc3R5bGU9J2Rpc3BsYXk6IHRhYmxlOyB3aWR0aDog MDsgbWFyZ2luLWxlZnQ6IDNlbTsgbWFyZ2luLXJpZ2h0OiBhdXRvJz48cHJlPgoKICBIVFRQLzEu MSAzMDIgRm91bmQKICBMb2NhdGlvbjogaHR0cDovL2V4YW1wbGUuY29tL2NiI2FjY2Vzc190b2tl bj0yWW90bkZaRkVqcjF6Q3NpY01XcEFBCiAgICAgICAgICAgICZhbXA7c3RhdGU9eHl6JmFtcDt0 b2tlbl90eXBlPWV4YW1wbGUmYW1wO2V4cGlyZXNfaW49MzYwMAoKPC9wcmU+PC9kaXY+CjxwPgog ICAgICAgICAgICAgIERldmVsb3BlcnMgc2hvdWxkIG5vdGUgdGhhdCBzb21lIHVzZXItYWdlbnRz IGRvIG5vdCBzdXBwb3J0IHRoZSBpbmNsdXNpb24gb2YgYQogICAgICAgICAgICAgIGZyYWdtZW50 IGNvbXBvbmVudCBpbiB0aGUgSFRUUCA8dHQ+TG9jYXRpb248L3R0PiByZXNwb25zZSBoZWFkZXIK ICAgICAgICAgICAgICBmaWVsZC4gU3VjaCBjbGllbnRzIHdpbGwgcmVxdWlyZSB1c2luZyBvdGhl ciBtZXRob2RzIGZvciByZWRpcmVjdGluZyB0aGUgY2xpZW50IHRoYW4KICAgICAgICAgICAgICBh IDN4eCByZWRpcmVjdGlvbiByZXNwb25zZS4gRm9yIGV4YW1wbGUsIHJldHVybmluZyBhbiBIVE1M IHBhZ2Ugd2hpY2ggaW5jbHVkZXMgYQogICAgICAgICAgICAgICdjb250aW51ZScgYnV0dG9uIHdp dGggYW4gYWN0aW9uIGxpbmtlZCB0byB0aGUgcmVkaXJlY3Rpb24gVVJJLgogICAgICAgICAgICAK PC9wPgo8cD4KICAgICAgICAgICAgVGhlIGNsaWVudCBNVVNUIGlnbm9yZSB1bnJlY29nbml6ZWQg cmVzcG9uc2UgcGFyYW1ldGVycy4gVGhlIGFjY2VzcyB0b2tlbiBzdHJpbmcgc2l6ZQogICAgICAg ICAgICBpcyBsZWZ0IHVuZGVmaW5lZCBieSB0aGlzIHNwZWNpZmljYXRpb24uIFRoZSBjbGllbnQg c2hvdWxkIGF2b2lkIG1ha2luZyBhc3N1bXB0aW9ucwogICAgICAgICAgICBhYm91dCB2YWx1ZSBz aXplcy4gVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIFNIT1VMRCBkb2N1bWVudCB0aGUgc2l6ZSBv ZiBhbnkgdmFsdWUgaXQKICAgICAgICAgICAgaXNzdWVzLgogICAgICAgICAgCjwvcD4KPGEgbmFt ZT0iaW1wbGljaXQtYXV0aHotZXJyb3IiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9 ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBh bGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7 VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi40LjIu Mi4xIj48L2E+PGgzPjQuMi4yLjEuJm5ic3A7CkVycm9yIFJlc3BvbnNlPC9oMz4KCjxwPgogICAg ICAgICAgICAgIElmIHRoZSByZXF1ZXN0IGZhaWxzIGR1ZSB0byBhIG1pc3NpbmcsIGludmFsaWQs IG9yIG1pc21hdGNoaW5nIHJlZGlyZWN0aW9uIFVSSSwgb3IgaWYKICAgICAgICAgICAgICB0aGUg Y2xpZW50IGlkZW50aWZpZXIgaXMgbWlzc2luZyBvciBpbnZhbGlkLCB0aGUgYXV0aG9yaXphdGlv biBzZXJ2ZXIgU0hPVUxEIGluZm9ybQogICAgICAgICAgICAgIHRoZSByZXNvdXJjZSBvd25lciBv ZiB0aGUgZXJyb3IsIGFuZCBNVVNUIE5PVCBhdXRvbWF0aWNhbGx5IHJlZGlyZWN0IHRoZSB1c2Vy LWFnZW50CiAgICAgICAgICAgICAgdG8gdGhlIGludmFsaWQgcmVkaXJlY3Rpb24gVVJJLgogICAg ICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgICAgICBJZiB0aGUgcmVzb3VyY2Ugb3duZXIgZGVu aWVzIHRoZSBhY2Nlc3MgcmVxdWVzdCBvciBpZiB0aGUgcmVxdWVzdCBmYWlscyBmb3IgcmVhc29u cwogICAgICAgICAgICAgIG90aGVyIHRoYW4gYSBtaXNzaW5nIG9yIGludmFsaWQgcmVkaXJlY3Rp b24gVVJJLCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgaW5mb3JtcyB0aGUKICAgICAgICAgICAg ICBjbGllbnQgYnkgYWRkaW5nIHRoZSBmb2xsb3dpbmcgcGFyYW1ldGVycyB0byB0aGUgZnJhZ21l bnQgY29tcG9uZW50IG9mIHRoZQogICAgICAgICAgICAgIHJlZGlyZWN0aW9uIFVSSSB1c2luZyB0 aGUKICAgICAgICAgICAgICA8dHQ+YXBwbGljYXRpb24veC13d3ctZm9ybS11cmxlbmNvZGVkPC90 dD4gZm9ybWF0OgogICAgICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgICAgICA8L3A+CjxibG9j a3F1b3RlIGNsYXNzPSJ0ZXh0Ij48ZGw+CjxkdD5lcnJvcjwvZHQ+CjxkZD4KICAgICAgICAgICAg ICAgICAgCiAgICAgICAgICAgICAgICAgIFJFUVVJUkVELiBBIHNpbmdsZSBBU0NJSSA8YSBjbGFz cz0naW5mbycgaHJlZj0nI1VTQVNDSUknPltVU0FTQ0lJXTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNs YXNzPSdpbmZvJz5BbWVyaWNhbiBOYXRpb25hbCBTdGFuZGFyZHMgSW5zdGl0dXRlLCAmbGRxdW87 Q29kZWQgQ2hhcmFjdGVyIFNldCAtLSA3LWJpdCBBbWVyaWNhbiBTdGFuZGFyZCBDb2RlIGZvciBJ bmZvcm1hdGlvbiBJbnRlcmNoYW5nZSwmcmRxdW87IDE5ODYuPC9zcGFuPjxzcGFuPik8L3NwYW4+ PC9hPiBlcnJvciBjb2RlIGZyb20gdGhlIGZvbGxvd2luZzoKCiAgICAgICAgICAgICAgICAgIAo8 YmxvY2txdW90ZSBjbGFzcz0idGV4dCI+PGRsPgo8ZHQ+aW52YWxpZF9yZXF1ZXN0PC9kdD4KPGRk PgogICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICBUaGUgcmVxdWVz dCBpcyBtaXNzaW5nIGEgcmVxdWlyZWQgcGFyYW1ldGVyLCBpbmNsdWRlcyBhbiBpbnZhbGlkCiAg ICAgICAgICAgICAgICAgICAgICBwYXJhbWV0ZXIgdmFsdWUsIGluY2x1ZGVzIGEgcGFyYW1ldGVy IG1vcmUgdGhhbiBvbmNlLCBvciBpcyBvdGhlcndpc2UgbWFsZm9ybWVkLgogICAgICAgICAgICAg ICAgICAgIAo8L2RkPgo8ZHQ+dW5hdXRob3JpemVkX2NsaWVudDwvZHQ+CjxkZD4KICAgICAgICAg ICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgVGhlIGNsaWVudCBpcyBub3QgYXV0 aG9yaXplZCB0byByZXF1ZXN0IGFuIGFjY2VzcyB0b2tlbiB1c2luZyB0aGlzIG1ldGhvZC4KICAg ICAgICAgICAgICAgICAgICAKPC9kZD4KPGR0PmFjY2Vzc19kZW5pZWQ8L2R0Pgo8ZGQ+CiAgICAg ICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgIFRoZSByZXNvdXJjZSBvd25l ciBvciBhdXRob3JpemF0aW9uIHNlcnZlciBkZW5pZWQgdGhlIHJlcXVlc3QuCiAgICAgICAgICAg ICAgICAgICAgCjwvZGQ+CjxkdD51bnN1cHBvcnRlZF9yZXNwb25zZV90eXBlPC9kdD4KPGRkPgog ICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICBUaGUgYXV0aG9yaXph dGlvbiBzZXJ2ZXIgZG9lcyBub3Qgc3VwcG9ydCBvYnRhaW5pbmcgYW4gYWNjZXNzIHRva2VuIHVz aW5nCiAgICAgICAgICAgICAgICAgICAgICB0aGlzIG1ldGhvZC4KICAgICAgICAgICAgICAgICAg ICAKPC9kZD4KPGR0PmludmFsaWRfc2NvcGU8L2R0Pgo8ZGQ+CiAgICAgICAgICAgICAgICAgICAg ICAKICAgICAgICAgICAgICAgICAgICAgIFRoZSByZXF1ZXN0ZWQgc2NvcGUgaXMgaW52YWxpZCwg dW5rbm93biwgb3IgbWFsZm9ybWVkLgogICAgICAgICAgICAgICAgICAgIAo8L2RkPgo8ZHQ+c2Vy dmVyX2Vycm9yPC9kdD4KPGRkPgogICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAg ICAgICAgICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgZW5jb3VudGVyZWQgYW4gdW5leHBlY3Rl ZCBjb25kaXRpb24gd2hpY2ggcHJldmVudGVkCiAgICAgICAgICAgICAgICAgICAgICBpdCBmcm9t IGZ1bGZpbGxpbmcgdGhlIHJlcXVlc3QuCiAgICAgICAgICAgICAgICAgICAgCjwvZGQ+CjxkdD50 ZW1wb3JhcmlseV91bmF2YWlsYWJsZTwvZHQ+CjxkZD4KICAgICAgICAgICAgICAgICAgICAgIAog ICAgICAgICAgICAgICAgICAgICAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGlzIGN1cnJlbnRs eSB1bmFibGUgdG8gaGFuZGxlIHRoZSByZXF1ZXN0IGR1ZSB0byBhCiAgICAgICAgICAgICAgICAg ICAgICB0ZW1wb3Jhcnkgb3ZlcmxvYWRpbmcgb3IgbWFpbnRlbmFuY2Ugb2YgdGhlIHNlcnZlci4K ICAgICAgICAgICAgICAgICAgICAKPC9kZD4KPC9kbD48L2Jsb2NrcXVvdGU+CgoJCSAgVmFsdWVz IGZvciB0aGUgPHR0PmVycm9yPC90dD4gcGFyYW1ldGVyIE1VU1QgTk9UIGluY2x1ZGUKCQkgIGNo YXJhY3RlcnMgb3V0c2lkZSB0aGUgc2V0ICV4MjAtMjEgLyAleDIzLTVCIC8gJXg1RC03RS4KICAg ICAgICAgICAgICAgIAo8L2RkPgo8ZHQ+ZXJyb3JfZGVzY3JpcHRpb248L2R0Pgo8ZGQ+CiAgICAg ICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICBPUFRJT05BTC4gQSBodW1hbi1yZWFkYWJs ZSBBU0NJSSA8YSBjbGFzcz0naW5mbycgaHJlZj0nI1VTQVNDSUknPltVU0FTQ0lJXTxzcGFuPiAo PC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5BbWVyaWNhbiBOYXRpb25hbCBTdGFuZGFyZHMgSW5z dGl0dXRlLCAmbGRxdW87Q29kZWQgQ2hhcmFjdGVyIFNldCAtLSA3LWJpdCBBbWVyaWNhbiBTdGFu ZGFyZCBDb2RlIGZvciBJbmZvcm1hdGlvbiBJbnRlcmNoYW5nZSwmcmRxdW87IDE5ODYuPC9zcGFu PjxzcGFuPik8L3NwYW4+PC9hPiB0ZXh0IHByb3ZpZGluZyBhZGRpdGlvbmFsIGluZm9ybWF0aW9u LAogICAgICAgICAgICAgICAgICB1c2VkIHRvIGFzc2lzdCB0aGUgY2xpZW50IGRldmVsb3BlciBp biB1bmRlcnN0YW5kaW5nIHRoZSBlcnJvciB0aGF0IG9jY3VycmVkLgoJCSAgPGJyIC8+CgoJCSAg VmFsdWVzIGZvciB0aGUgPHR0PmVycm9yX2Rlc2NyaXB0aW9uPC90dD4gcGFyYW1ldGVyIE1VU1Qg Tk9UIGluY2x1ZGUKCQkgIGNoYXJhY3RlcnMgb3V0c2lkZSB0aGUgc2V0ICV4MjAtMjEgLyAleDIz LTVCIC8gJXg1RC03RS4KICAgICAgICAgICAgICAgIAo8L2RkPgo8ZHQ+ZXJyb3JfdXJpPC9kdD4K PGRkPgogICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgT1BUSU9OQUwuIEEgVVJJ IGlkZW50aWZ5aW5nIGEgaHVtYW4tcmVhZGFibGUgd2ViIHBhZ2Ugd2l0aCBpbmZvcm1hdGlvbiBh Ym91dCB0aGUKICAgICAgICAgICAgICAgICAgZXJyb3IsIHVzZWQgdG8gcHJvdmlkZSB0aGUgY2xp ZW50IGRldmVsb3BlciB3aXRoIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gYWJvdXQgdGhlCiAgICAg ICAgICAgICAgICAgIGVycm9yLgoJCSAgPGJyIC8+CgoJCSAgVmFsdWVzIGZvciB0aGUgPHR0PmVy cm9yX3VyaTwvdHQ+IHBhcmFtZXRlcgoJCSAgTVVTVCBjb25mb3JtIHRvIHRoZSBVUkktUmVmZXJl bmNlIHN5bnRheCwgYW5kIHRodXMgTVVTVCBOT1QgaW5jbHVkZQoJCSAgY2hhcmFjdGVycyBvdXRz aWRlIHRoZSBzZXQgJXgyMSAvICV4MjMtNUIgLyAleDVELTdFLgogICAgICAgICAgICAgICAgCjwv ZGQ+CjxkdD5zdGF0ZTwvZHQ+CjxkZD4KICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAg ICAgIFJFUVVJUkVEIGlmIGEgPHR0PnN0YXRlPC90dD4gcGFyYW1ldGVyIHdhcyBwcmVzZW50IGlu IHRoZQogICAgICAgICAgICAgICAgICBjbGllbnQgYXV0aG9yaXphdGlvbiByZXF1ZXN0LiBUaGUg ZXhhY3QgdmFsdWUgcmVjZWl2ZWQgZnJvbSB0aGUgY2xpZW50LgogICAgICAgICAgICAgICAgCjwv ZGQ+CjwvZGw+PC9ibG9ja3F1b3RlPjxwPgogICAgICAgICAgICAKPC9wPgo8cD4KICAgICAgICAg ICAgICAgIEZvciBleGFtcGxlLCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgcmVkaXJlY3RzIHRo ZSB1c2VyLWFnZW50IGJ5IHNlbmRpbmcgdGhlCiAgICAgICAgICAgICAgICBmb2xsb3dpbmcgSFRU UCByZXNwb25zZToKICAgICAgICAgICAgICAKPC9wPjxkaXYgc3R5bGU9J2Rpc3BsYXk6IHRhYmxl OyB3aWR0aDogMDsgbWFyZ2luLWxlZnQ6IDNlbTsgbWFyZ2luLXJpZ2h0OiBhdXRvJz48cHJlPgoK ICBIVFRQLzEuMSAzMDIgRm91bmQKICBMb2NhdGlvbjogaHR0cHM6Ly9jbGllbnQuZXhhbXBsZS5j b20vY2IjZXJyb3I9YWNjZXNzX2RlbmllZCZhbXA7c3RhdGU9eHl6Cgo8L3ByZT48L2Rpdj4KPGEg bmFtZT0iZ3JhbnQtcGFzc3dvcmQiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9Imxh eW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGln bj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9D Jm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi40LjMiPjwv YT48aDM+NC4zLiZuYnNwOwpSZXNvdXJjZSBPd25lciBQYXNzd29yZCBDcmVkZW50aWFscyBHcmFu dDwvaDM+Cgo8cD4KICAgICAgICAgIFRoZSByZXNvdXJjZSBvd25lciBwYXNzd29yZCBjcmVkZW50 aWFscyBncmFudCB0eXBlIGlzIHN1aXRhYmxlIGluIGNhc2VzIHdoZXJlIHRoZQogICAgICAgICAg cmVzb3VyY2Ugb3duZXIgaGFzIGEgdHJ1c3QgcmVsYXRpb25zaGlwIHdpdGggdGhlIGNsaWVudCwg c3VjaCBhcyB0aGUgZGV2aWNlIG9wZXJhdGluZwogICAgICAgICAgc3lzdGVtIG9yIGEgaGlnaGx5 IHByaXZpbGVnZWQgYXBwbGljYXRpb24uIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBzaG91bGQg dGFrZSBzcGVjaWFsCiAgICAgICAgICBjYXJlIHdoZW4gZW5hYmxpbmcgdGhpcyBncmFudCB0eXBl LCBhbmQgb25seSBhbGxvdyBpdCB3aGVuIG90aGVyIGZsb3dzIGFyZSBub3QgdmlhYmxlLgogICAg ICAgIAo8L3A+CjxwPgogICAgICAgICAgVGhlIGdyYW50IHR5cGUgaXMgc3VpdGFibGUgZm9yIGNs aWVudHMgY2FwYWJsZSBvZiBvYnRhaW5pbmcgdGhlIHJlc291cmNlIG93bmVyJ3MKICAgICAgICAg IGNyZWRlbnRpYWxzICh1c2VybmFtZSBhbmQgcGFzc3dvcmQsIHR5cGljYWxseSB1c2luZyBhbiBp bnRlcmFjdGl2ZSBmb3JtKS4gSXQgaXMgYWxzbyB1c2VkCiAgICAgICAgICB0byBtaWdyYXRlIGV4 aXN0aW5nIGNsaWVudHMgdXNpbmcgZGlyZWN0IGF1dGhlbnRpY2F0aW9uIHNjaGVtZXMgc3VjaCBh cyBIVFRQIEJhc2ljIG9yCiAgICAgICAgICBEaWdlc3QgYXV0aGVudGljYXRpb24gdG8gT0F1dGgg YnkgY29udmVydGluZyB0aGUgc3RvcmVkIGNyZWRlbnRpYWxzIHRvIGFuIGFjY2VzcyB0b2tlbi4K ICAgICAgICAKPC9wPjxiciAvPjxociBjbGFzcz0iaW5zZXJ0IiAvPgo8YSBuYW1lPSJGaWd1cmUt NSI+PC9hPgo8ZGl2IHN0eWxlPSdkaXNwbGF5OiB0YWJsZTsgd2lkdGg6IDA7IG1hcmdpbi1sZWZ0 OiAzZW07IG1hcmdpbi1yaWdodDogYXV0byc+PHByZT4KCiAgKy0tLS0tLS0tLS0rCiAgfCBSZXNv dXJjZSB8CiAgfCAgT3duZXIgICB8CiAgfCAgICAgICAgICB8CiAgKy0tLS0tLS0tLS0rCiAgICAg ICB2CiAgICAgICB8ICAgIFJlc291cmNlIE93bmVyCiAgICAgIChBKSBQYXNzd29yZCBDcmVkZW50 aWFscwogICAgICAgfAogICAgICAgdgogICstLS0tLS0tLS0rICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0rCiAgfCAgICAgICAgIHwmZ3Q7LS0oQiktLS0t IFJlc291cmNlIE93bmVyIC0tLS0tLS0mZ3Q7fCAgICAgICAgICAgICAgIHwKICB8ICAgICAgICAg fCAgICAgICAgIFBhc3N3b3JkIENyZWRlbnRpYWxzICAgICB8IEF1dGhvcml6YXRpb24gfAogIHwg Q2xpZW50ICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgIFNlcnZlciAg ICB8CiAgfCAgICAgICAgIHwmbHQ7LS0oQyktLS0tIEFjY2VzcyBUb2tlbiAtLS0tLS0tLS0mbHQ7 fCAgICAgICAgICAgICAgIHwKICB8ICAgICAgICAgfCAgICAody8gT3B0aW9uYWwgUmVmcmVzaCBU b2tlbikgICB8ICAgICAgICAgICAgICAgfAogICstLS0tLS0tLS0rICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0rCgo8L3ByZT48L2Rpdj48dGFibGUgYm9y ZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGFsaWduPSJjZW50ZXIiPjx0 cj48dGQgYWxpZ249ImNlbnRlciI+PGZvbnQgZmFjZT0ibW9uYWNvLCBNUyBTYW5zIFNlcmlmIiBz aXplPSIxIj48Yj4mbmJzcDtGaWd1cmUmbmJzcDs1OiBSZXNvdXJjZSBPd25lciBQYXNzd29yZCBD cmVkZW50aWFscyBGbG93Jm5ic3A7PC9iPjwvZm9udD48YnIgLz48L3RkPjwvdHI+PC90YWJsZT48 aHIgY2xhc3M9Imluc2VydCIgLz4KCjxwPgogICAgICAgICAgVGhlIGZsb3cgaWxsdXN0cmF0ZWQg aW4gPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNGaWd1cmUtNSc+RmlndXJlJm5ic3A7NTxzcGFuPiAo PC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5SZXNvdXJjZSBPd25lciBQYXNzd29yZCBDcmVkZW50 aWFscyBGbG93PC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPiBpbmNsdWRlcyB0aGUgZm9sbG93aW5n IHN0ZXBzOgogICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgPC9wPgo8YmxvY2txdW90ZSBjbGFz cz0idGV4dCI+PGRsPgo8ZHQ+KEEpPC9kdD4KPGRkPgogICAgICAgICAgICAgIFRoZSByZXNvdXJj ZSBvd25lciBwcm92aWRlcyB0aGUgY2xpZW50IHdpdGggaXRzIHVzZXJuYW1lIGFuZCBwYXNzd29y ZC4KICAgICAgICAgICAgCjwvZGQ+CjxkdD4oQik8L2R0Pgo8ZGQ+CiAgICAgICAgICAgICAgVGhl IGNsaWVudCByZXF1ZXN0cyBhbiBhY2Nlc3MgdG9rZW4gZnJvbSB0aGUgYXV0aG9yaXphdGlvbiBz ZXJ2ZXIncyB0b2tlbiBlbmRwb2ludCBieQogICAgICAgICAgICAgIGluY2x1ZGluZyB0aGUgY3Jl ZGVudGlhbHMgcmVjZWl2ZWQgZnJvbSB0aGUgcmVzb3VyY2Ugb3duZXIuIFdoZW4gbWFraW5nIHRo ZSByZXF1ZXN0LAogICAgICAgICAgICAgIHRoZSBjbGllbnQgYXV0aGVudGljYXRlcyB3aXRoIHRo ZSBhdXRob3JpemF0aW9uIHNlcnZlci4KICAgICAgICAgICAgCjwvZGQ+CjxkdD4oQyk8L2R0Pgo8 ZGQ+CiAgICAgICAgICAgICAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGF1dGhlbnRpY2F0ZXMg dGhlIGNsaWVudCBhbmQgdmFsaWRhdGVzIHRoZSByZXNvdXJjZSBvd25lcgogICAgICAgICAgICAg IGNyZWRlbnRpYWxzLCBhbmQgaWYgdmFsaWQgaXNzdWVzIGFuIGFjY2VzcyB0b2tlbi4KICAgICAg ICAgICAgCjwvZGQ+CjwvZGw+PC9ibG9ja3F1b3RlPjxwPgogICAgICAgIAo8L3A+CjxhIG5hbWU9 ImFuY2hvcjI3Ij48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxw YWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48 dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48 L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uNC4zLjEiPjwvYT48aDM+NC4z LjEuJm5ic3A7CkF1dGhvcml6YXRpb24gUmVxdWVzdCBhbmQgUmVzcG9uc2U8L2gzPgoKPHA+CiAg ICAgICAgICAgIFRoZSBtZXRob2QgdGhyb3VnaCB3aGljaCB0aGUgY2xpZW50IG9idGFpbnMgdGhl IHJlc291cmNlIG93bmVyIGNyZWRlbnRpYWxzIGlzIGJleW9uZAogICAgICAgICAgICB0aGUgc2Nv cGUgb2YgdGhpcyBzcGVjaWZpY2F0aW9uLiBUaGUgY2xpZW50IE1VU1QgZGlzY2FyZCB0aGUgY3Jl ZGVudGlhbHMgb25jZSBhbiBhY2Nlc3MKICAgICAgICAgICAgdG9rZW4gaGFzIGJlZW4gb2J0YWlu ZWQuCiAgICAgICAgICAKPC9wPgo8YSBuYW1lPSJwYXNzd29yZC10b2stcmVxIj48L2E+PGJyIC8+ PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2lu Zz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWci PjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEg bmFtZT0icmZjLnNlY3Rpb24uNC4zLjIiPjwvYT48aDM+NC4zLjIuJm5ic3A7CkFjY2VzcyBUb2tl biBSZXF1ZXN0PC9oMz4KCjxwPgogICAgICAgICAgICBUaGUgY2xpZW50IG1ha2VzIGEgcmVxdWVz dCB0byB0aGUgdG9rZW4gZW5kcG9pbnQgYnkgYWRkaW5nIHRoZSBmb2xsb3dpbmcgcGFyYW1ldGVy cwogICAgICAgICAgICB1c2luZyB0aGUgPHR0PmFwcGxpY2F0aW9uL3gtd3d3LWZvcm0tdXJsZW5j b2RlZDwvdHQ+IGZvcm1hdCBpbiB0aGUKICAgICAgICAgICAgSFRUUCByZXF1ZXN0IGVudGl0eS1i b2R5OgogICAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICAgIDwvcD4KPGJsb2NrcXVvdGUgY2xh c3M9InRleHQiPjxkbD4KPGR0PmdyYW50X3R5cGU8L2R0Pgo8ZGQ+CiAgICAgICAgICAgICAgICAK ICAgICAgICAgICAgICAgIFJFUVVJUkVELiBWYWx1ZSBNVVNUIGJlIHNldCB0byA8dHQ+cGFzc3dv cmQ8L3R0Pi4KICAgICAgICAgICAgICAKPC9kZD4KPGR0PnVzZXJuYW1lPC9kdD4KPGRkPgogICAg ICAgICAgICAgICAgCiAgICAgICAgICAgICAgICBSRVFVSVJFRC4gVGhlIHJlc291cmNlIG93bmVy IHVzZXJuYW1lLCBlbmNvZGVkIGFzIFVURi04LgogICAgICAgICAgICAgIAo8L2RkPgo8ZHQ+cGFz c3dvcmQ8L2R0Pgo8ZGQ+CiAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgIFJFUVVJUkVE LiBUaGUgcmVzb3VyY2Ugb3duZXIgcGFzc3dvcmQsIGVuY29kZWQgYXMgVVRGLTguCiAgICAgICAg ICAgICAgCjwvZGQ+CjxkdD5zY29wZTwvZHQ+CjxkZD4KICAgICAgICAgICAgICAgIAogICAgICAg ICAgICAgICAgT1BUSU9OQUwuIFRoZSBzY29wZSBvZiB0aGUgYWNjZXNzIHJlcXVlc3QgYXMgZGVz Y3JpYmVkIGJ5IDxhIGNsYXNzPSdpbmZvJyBocmVmPScjc2NvcGUnPlNlY3Rpb24mbmJzcDszLjM8 c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+QWNjZXNzIFRva2VuIFNjb3BlPC9zcGFu PjxzcGFuPik8L3NwYW4+PC9hPi4KICAgICAgICAgICAgICAKPC9kZD4KPC9kbD48L2Jsb2NrcXVv dGU+PHA+CiAgICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgICAgSWYgdGhlIGNsaWVudCB0eXBl IGlzIGNvbmZpZGVudGlhbCBvciB0aGUgY2xpZW50IHdhcyBpc3N1ZWQgY2xpZW50IGNyZWRlbnRp YWxzIChvcgogICAgICAgICAgICBhc3NpZ25lZCBvdGhlciBhdXRoZW50aWNhdGlvbiByZXF1aXJl bWVudHMpLCB0aGUgY2xpZW50IE1VU1QgYXV0aGVudGljYXRlIHdpdGggdGhlCiAgICAgICAgICAg IGF1dGhvcml6YXRpb24gc2VydmVyIGFzIGRlc2NyaWJlZCBpbiA8YSBjbGFzcz0naW5mbycgaHJl Zj0nI3Rva2VuLWVuZHBvaW50LWF1dGgnPlNlY3Rpb24mbmJzcDszLjIuMTxzcGFuPiAoPC9zcGFu PjxzcGFuIGNsYXNzPSdpbmZvJz5DbGllbnQgQXV0aGVudGljYXRpb248L3NwYW4+PHNwYW4+KTwv c3Bhbj48L2E+LgogICAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICAgICAgRm9yIGV4YW1wbGUs IHRoZSBjbGllbnQgbWFrZXMgdGhlIGZvbGxvd2luZyBIVFRQIHJlcXVlc3QgdXNpbmcgdHJhbnNw b3J0LWxheWVyCiAgICAgICAgICAgICAgc2VjdXJpdHkgKGV4dHJhIGxpbmUgYnJlYWtzIGFyZSBm b3IgZGlzcGxheSBwdXJwb3NlcyBvbmx5KToKICAgICAgICAgICAgCjwvcD48ZGl2IHN0eWxlPSdk aXNwbGF5OiB0YWJsZTsgd2lkdGg6IDA7IG1hcmdpbi1sZWZ0OiAzZW07IG1hcmdpbi1yaWdodDog YXV0byc+PHByZT4KCiAgUE9TVCAvdG9rZW4gSFRUUC8xLjEKICBIb3N0OiBzZXJ2ZXIuZXhhbXBs ZS5jb20KICBBdXRob3JpemF0aW9uOiBCYXNpYyBjelpDYUdSU2EzRjBNenBuV0RGbVFtRjBNMkpX CiAgQ29udGVudC1UeXBlOiBhcHBsaWNhdGlvbi94LXd3dy1mb3JtLXVybGVuY29kZWQ7Y2hhcnNl dD1VVEYtOAoKICBncmFudF90eXBlPXBhc3N3b3JkJmFtcDt1c2VybmFtZT1qb2huZG9lJmFtcDtw YXNzd29yZD1BM2RkajN3Cgo8L3ByZT48L2Rpdj4KPHA+CiAgICAgICAgICAgIFRoZSBhdXRob3Jp emF0aW9uIHNlcnZlciBNVVNUOgogICAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICAgIDwvcD4K PHVsIGNsYXNzPSJ0ZXh0Ij4KPGxpPgogICAgICAgICAgICAgICAgcmVxdWlyZSBjbGllbnQgYXV0 aGVudGljYXRpb24gZm9yIGNvbmZpZGVudGlhbCBjbGllbnRzIG9yIGZvciBhbnkgY2xpZW50IHRo YXQgd2FzCiAgICAgICAgICAgICAgICBpc3N1ZWQgY2xpZW50IGNyZWRlbnRpYWxzIChvciB3aXRo IG90aGVyIGF1dGhlbnRpY2F0aW9uIHJlcXVpcmVtZW50cyksCiAgICAgICAgICAgICAgCjwvbGk+ CjxsaT4KICAgICAgICAgICAgICAgIGF1dGhlbnRpY2F0ZSB0aGUgY2xpZW50IGlmIGNsaWVudCBh dXRoZW50aWNhdGlvbiBpcyBpbmNsdWRlZCwgYW5kCiAgICAgICAgICAgICAgCjwvbGk+CjxsaT4K ICAgICAgICAgICAgICAgIHZhbGlkYXRlIHRoZSByZXNvdXJjZSBvd25lciBwYXNzd29yZCBjcmVk ZW50aWFscyB1c2luZyBpdHMgZXhpc3RpbmcgcGFzc3dvcmQKICAgICAgICAgICAgICAgIHZhbGlk YXRpb24gYWxnb3JpdGhtLgogICAgICAgICAgICAgIAo8L2xpPgo8L3VsPjxwPgogICAgICAgICAg CjwvcD4KPHA+CiAgICAgICAgICAgIFNpbmNlIHRoaXMgYWNjZXNzIHRva2VuIHJlcXVlc3QgdXRp bGl6ZXMgdGhlIHJlc291cmNlIG93bmVyJ3MgcGFzc3dvcmQsIHRoZQogICAgICAgICAgICBhdXRo b3JpemF0aW9uIHNlcnZlciBNVVNUIHByb3RlY3QgdGhlIGVuZHBvaW50IGFnYWluc3QgYnJ1dGUg Zm9yY2UgYXR0YWNrcyAoZS5nLiB1c2luZwogICAgICAgICAgICByYXRlLWxpbWl0YXRpb24gb3Ig Z2VuZXJhdGluZyBhbGVydHMpLgogICAgICAgICAgCjwvcD4KPGEgbmFtZT0iYW5jaG9yMjgiPjwv YT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNl bGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9 IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3Rh YmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi40LjMuMyI+PC9hPjxoMz40LjMuMy4mbmJzcDsKQWNj ZXNzIFRva2VuIFJlc3BvbnNlPC9oMz4KCjxwPgogICAgICAgICAgICBJZiB0aGUgYWNjZXNzIHRv a2VuIHJlcXVlc3QgaXMgdmFsaWQgYW5kIGF1dGhvcml6ZWQsIHRoZSBhdXRob3JpemF0aW9uIHNl cnZlciBpc3N1ZXMgYW4KICAgICAgICAgICAgYWNjZXNzIHRva2VuIGFuZCBvcHRpb25hbCByZWZy ZXNoIHRva2VuIGFzIGRlc2NyaWJlZCBpbiA8YSBjbGFzcz0naW5mbycgaHJlZj0nI3Rva2VuLXJl c3BvbnNlJz5TZWN0aW9uJm5ic3A7NS4xPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8n PlN1Y2Nlc3NmdWwgUmVzcG9uc2U8L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+LgogICAgICAgICAg ICBJZiB0aGUgcmVxdWVzdCBmYWlsZWQgY2xpZW50IGF1dGhlbnRpY2F0aW9uIG9yIGlzIGludmFs aWQsIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciByZXR1cm5zCiAgICAgICAgICAgIGFuIGVycm9y IHJlc3BvbnNlIGFzIGRlc2NyaWJlZCBpbiA8YSBjbGFzcz0naW5mbycgaHJlZj0nI3Rva2VuLWVy cm9ycyc+U2VjdGlvbiZuYnNwOzUuMjxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5F cnJvciBSZXNwb25zZTwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4uCiAgICAgICAgICAKPC9wPgo8 cD4KICAgICAgICAgICAgICBBbiBleGFtcGxlIHN1Y2Nlc3NmdWwgcmVzcG9uc2U6CiAgICAgICAg ICAgIAo8L3A+PGRpdiBzdHlsZT0nZGlzcGxheTogdGFibGU7IHdpZHRoOiAwOyBtYXJnaW4tbGVm dDogM2VtOyBtYXJnaW4tcmlnaHQ6IGF1dG8nPjxwcmU+CgogIEhUVFAvMS4xIDIwMCBPSwogIENv bnRlbnQtVHlwZTogYXBwbGljYXRpb24vanNvbjtjaGFyc2V0PVVURi04CiAgQ2FjaGUtQ29udHJv bDogbm8tc3RvcmUKICBQcmFnbWE6IG5vLWNhY2hlCgogIHsKICAgICJhY2Nlc3NfdG9rZW4iOiIy WW90bkZaRkVqcjF6Q3NpY01XcEFBIiwKICAgICJ0b2tlbl90eXBlIjoiZXhhbXBsZSIsCiAgICAi ZXhwaXJlc19pbiI6MzYwMCwKICAgICJyZWZyZXNoX3Rva2VuIjoidEd6djNKT2tGMFhHNVF4MlRs S1dJQSIsCiAgICAiZXhhbXBsZV9wYXJhbWV0ZXIiOiJleGFtcGxlX3ZhbHVlIgogIH0KCjwvcHJl PjwvZGl2Pgo8YSBuYW1lPSJncmFudC1jbGllbnQiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1 bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9D YnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+ Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlv bi40LjQiPjwvYT48aDM+NC40LiZuYnNwOwpDbGllbnQgQ3JlZGVudGlhbHMgR3JhbnQ8L2gzPgoK PHA+CiAgICAgICAgICBUaGUgY2xpZW50IGNhbiByZXF1ZXN0IGFuIGFjY2VzcyB0b2tlbiB1c2lu ZyBvbmx5IGl0cyBjbGllbnQgY3JlZGVudGlhbHMgKG9yIG90aGVyCiAgICAgICAgICBzdXBwb3J0 ZWQgbWVhbnMgb2YgYXV0aGVudGljYXRpb24pIHdoZW4gdGhlIGNsaWVudCBpcyByZXF1ZXN0aW5n IGFjY2VzcyB0byB0aGUKICAgICAgICAgIHByb3RlY3RlZCByZXNvdXJjZXMgdW5kZXIgaXRzIGNv bnRyb2wsIG9yIHRob3NlIG9mIGFub3RoZXIgcmVzb3VyY2Ugb3duZXIgd2hpY2ggaGFzIGJlZW4K ICAgICAgICAgIHByZXZpb3VzbHkgYXJyYW5nZWQgd2l0aCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2 ZXIgKHRoZSBtZXRob2Qgb2Ygd2hpY2ggaXMgYmV5b25kIHRoZQogICAgICAgICAgc2NvcGUgb2Yg dGhpcyBzcGVjaWZpY2F0aW9uKS4KICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgIFRoZSBjbGll bnQgY3JlZGVudGlhbHMgZ3JhbnQgdHlwZSBNVVNUIG9ubHkgYmUgdXNlZCBieSBjb25maWRlbnRp YWwgY2xpZW50cy4KICAgICAgICAKPC9wPjxiciAvPjxociBjbGFzcz0iaW5zZXJ0IiAvPgo8YSBu YW1lPSJGaWd1cmUtNiI+PC9hPgo8ZGl2IHN0eWxlPSdkaXNwbGF5OiB0YWJsZTsgd2lkdGg6IDA7 IG1hcmdpbi1sZWZ0OiAzZW07IG1hcmdpbi1yaWdodDogYXV0byc+PHByZT4KCiAgKy0tLS0tLS0t LSsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLSsKICB8 ICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAg ICAgfAogIHwgICAgICAgICB8Jmd0Oy0tKEEpLSBDbGllbnQgQXV0aGVudGljYXRpb24gLS0tJmd0 O3wgQXV0aG9yaXphdGlvbiB8CiAgfCBDbGllbnQgIHwgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfCAgICAgU2VydmVyICAgIHwKICB8ICAgICAgICAgfCZsdDstLShCKS0tLS0gQWNj ZXNzIFRva2VuIC0tLS0tLS0tLSZsdDt8ICAgICAgICAgICAgICAgfAogIHwgICAgICAgICB8ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICB8CiAgKy0tLS0t LS0tLSsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLSsK CjwvcHJlPjwvZGl2Pjx0YWJsZSBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2lu Zz0iMiIgYWxpZ249ImNlbnRlciI+PHRyPjx0ZCBhbGlnbj0iY2VudGVyIj48Zm9udCBmYWNlPSJt b25hY28sIE1TIFNhbnMgU2VyaWYiIHNpemU9IjEiPjxiPiZuYnNwO0ZpZ3VyZSZuYnNwOzY6IENs aWVudCBDcmVkZW50aWFscyBGbG93Jm5ic3A7PC9iPjwvZm9udD48YnIgLz48L3RkPjwvdHI+PC90 YWJsZT48aHIgY2xhc3M9Imluc2VydCIgLz4KCjxwPgogICAgICAgICAgVGhlIGZsb3cgaWxsdXN0 cmF0ZWQgaW4gPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNGaWd1cmUtNic+RmlndXJlJm5ic3A7Njxz cGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5DbGllbnQgQ3JlZGVudGlhbHMgRmxvdzwv c3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4gaW5jbHVkZXMgdGhlIGZvbGxvd2luZyBzdGVwczoKICAg ICAgICAKPC9wPgo8cD4KICAgICAgICAgIDwvcD4KPGJsb2NrcXVvdGUgY2xhc3M9InRleHQiPjxk bD4KPGR0PihBKTwvZHQ+CjxkZD4KICAgICAgICAgICAgICBUaGUgY2xpZW50IGF1dGhlbnRpY2F0 ZXMgd2l0aCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYW5kIHJlcXVlc3RzIGFuIGFjY2VzcyB0 b2tlbgogICAgICAgICAgICAgIGZyb20gdGhlIHRva2VuIGVuZHBvaW50LgogICAgICAgICAgICAK PC9kZD4KPGR0PihCKTwvZHQ+CjxkZD4KICAgICAgICAgICAgICBUaGUgYXV0aG9yaXphdGlvbiBz ZXJ2ZXIgYXV0aGVudGljYXRlcyB0aGUgY2xpZW50LCBhbmQgaWYgdmFsaWQgaXNzdWVzIGFuIGFj Y2VzcwogICAgICAgICAgICAgIHRva2VuLgogICAgICAgICAgICAKPC9kZD4KPC9kbD48L2Jsb2Nr cXVvdGU+PHA+CiAgICAgICAgCjwvcD4KPGEgbmFtZT0iY2xpZW50LXJlcS1yZXNwIj48L2E+PGJy IC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3Bh Y2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0Ni dWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4K PGEgbmFtZT0icmZjLnNlY3Rpb24uNC40LjEiPjwvYT48aDM+NC40LjEuJm5ic3A7CkF1dGhvcml6 YXRpb24gUmVxdWVzdCBhbmQgUmVzcG9uc2U8L2gzPgoKPHA+CiAgICAgICAgICAgIFNpbmNlIHRo ZSBjbGllbnQgYXV0aGVudGljYXRpb24gaXMgdXNlZCBhcyB0aGUgYXV0aG9yaXphdGlvbiBncmFu dCwgbm8gYWRkaXRpb25hbAogICAgICAgICAgICBhdXRob3JpemF0aW9uIHJlcXVlc3QgaXMgbmVl ZGVkLgogICAgICAgICAgCjwvcD4KPGEgbmFtZT0iYW5jaG9yMjkiPjwvYT48YnIgLz48aHIgLz4K PHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBj bGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJl Zj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJy ZmMuc2VjdGlvbi40LjQuMiI+PC9hPjxoMz40LjQuMi4mbmJzcDsKQWNjZXNzIFRva2VuIFJlcXVl c3Q8L2gzPgoKPHA+CiAgICAgICAgICAgIFRoZSBjbGllbnQgbWFrZXMgYSByZXF1ZXN0IHRvIHRo ZSB0b2tlbiBlbmRwb2ludCBieSBhZGRpbmcgdGhlIGZvbGxvd2luZyBwYXJhbWV0ZXJzCiAgICAg ICAgICAgIHVzaW5nIHRoZSA8dHQ+YXBwbGljYXRpb24veC13d3ctZm9ybS11cmxlbmNvZGVkPC90 dD4gZm9ybWF0IGluIHRoZQogICAgICAgICAgICBIVFRQIHJlcXVlc3QgZW50aXR5LWJvZHk6CiAg ICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgICAgPC9wPgo8YmxvY2txdW90ZSBjbGFzcz0idGV4 dCI+PGRsPgo8ZHQ+Z3JhbnRfdHlwZTwvZHQ+CjxkZD4KICAgICAgICAgICAgICAgIAogICAgICAg ICAgICAgICAgUkVRVUlSRUQuIFZhbHVlIE1VU1QgYmUgc2V0IHRvIDx0dD5jbGllbnRfY3JlZGVu dGlhbHM8L3R0Pi4KICAgICAgICAgICAgICAKPC9kZD4KPGR0PnNjb3BlPC9kdD4KPGRkPgogICAg ICAgICAgICAgICAgCiAgICAgICAgICAgICAgICBPUFRJT05BTC4gVGhlIHNjb3BlIG9mIHRoZSBh Y2Nlc3MgcmVxdWVzdCBhcyBkZXNjcmliZWQgYnkgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNzY29w ZSc+U2VjdGlvbiZuYnNwOzMuMzxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5BY2Nl c3MgVG9rZW4gU2NvcGU8L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+LgogICAgICAgICAgICAgIAo8 L2RkPgo8L2RsPjwvYmxvY2txdW90ZT48cD4KICAgICAgICAgIAo8L3A+CjxwPgogICAgICAgICAg ICBUaGUgY2xpZW50IE1VU1QgYXV0aGVudGljYXRlIHdpdGggdGhlIGF1dGhvcml6YXRpb24gc2Vy dmVyIGFzIGRlc2NyaWJlZCBpbgogICAgICAgICAgICA8YSBjbGFzcz0naW5mbycgaHJlZj0nI3Rv a2VuLWVuZHBvaW50LWF1dGgnPlNlY3Rpb24mbmJzcDszLjIuMTxzcGFuPiAoPC9zcGFuPjxzcGFu IGNsYXNzPSdpbmZvJz5DbGllbnQgQXV0aGVudGljYXRpb248L3NwYW4+PHNwYW4+KTwvc3Bhbj48 L2E+LgogICAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICAgICAgRm9yIGV4YW1wbGUsIHRoZSBj bGllbnQgbWFrZXMgdGhlIGZvbGxvd2luZyBIVFRQIHJlcXVlc3QgdXNpbmcgdHJhbnNwb3J0LWxh eWVyCiAgICAgICAgICAgICAgc2VjdXJpdHkgKGV4dHJhIGxpbmUgYnJlYWtzIGFyZSBmb3IgZGlz cGxheSBwdXJwb3NlcyBvbmx5KToKICAgICAgICAgICAgCjwvcD48ZGl2IHN0eWxlPSdkaXNwbGF5 OiB0YWJsZTsgd2lkdGg6IDA7IG1hcmdpbi1sZWZ0OiAzZW07IG1hcmdpbi1yaWdodDogYXV0byc+ PHByZT4KCiAgUE9TVCAvdG9rZW4gSFRUUC8xLjEKICBIb3N0OiBzZXJ2ZXIuZXhhbXBsZS5jb20K ICBBdXRob3JpemF0aW9uOiBCYXNpYyBjelpDYUdSU2EzRjBNenBuV0RGbVFtRjBNMkpXCiAgQ29u dGVudC1UeXBlOiBhcHBsaWNhdGlvbi94LXd3dy1mb3JtLXVybGVuY29kZWQ7Y2hhcnNldD1VVEYt OAoKICBncmFudF90eXBlPWNsaWVudF9jcmVkZW50aWFscwoKPC9wcmU+PC9kaXY+CjxwPgogICAg ICAgICAgICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVTVCBhdXRoZW50aWNhdGUgdGhlIGNs aWVudC4KICAgICAgICAgIAo8L3A+CjxhIG5hbWU9ImFuY2hvcjMwIj48L2E+PGJyIC8+PGhyIC8+ Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIg Y2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhy ZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0i cmZjLnNlY3Rpb24uNC40LjMiPjwvYT48aDM+NC40LjMuJm5ic3A7CkFjY2VzcyBUb2tlbiBSZXNw b25zZTwvaDM+Cgo8cD4KICAgICAgICAgICAgSWYgdGhlIGFjY2VzcyB0b2tlbiByZXF1ZXN0IGlz IHZhbGlkIGFuZCBhdXRob3JpemVkLCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgaXNzdWVzIGFu CiAgICAgICAgICAgIGFjY2VzcyB0b2tlbiBhcyBkZXNjcmliZWQgaW4gPGEgY2xhc3M9J2luZm8n IGhyZWY9JyN0b2tlbi1yZXNwb25zZSc+U2VjdGlvbiZuYnNwOzUuMTxzcGFuPiAoPC9zcGFuPjxz cGFuIGNsYXNzPSdpbmZvJz5TdWNjZXNzZnVsIFJlc3BvbnNlPC9zcGFuPjxzcGFuPik8L3NwYW4+ PC9hPi4gQSByZWZyZXNoIHRva2VuIFNIT1VMRAogICAgICAgICAgICBOT1QgYmUgaW5jbHVkZWQu IElmIHRoZSByZXF1ZXN0IGZhaWxlZCBjbGllbnQgYXV0aGVudGljYXRpb24gb3IgaXMgaW52YWxp ZCwgdGhlCiAgICAgICAgICAgIGF1dGhvcml6YXRpb24gc2VydmVyIHJldHVybnMgYW4gZXJyb3Ig cmVzcG9uc2UgYXMgZGVzY3JpYmVkIGluCiAgICAgICAgICAgIDxhIGNsYXNzPSdpbmZvJyBocmVm PScjdG9rZW4tZXJyb3JzJz5TZWN0aW9uJm5ic3A7NS4yPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xh c3M9J2luZm8nPkVycm9yIFJlc3BvbnNlPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPi4KICAgICAg ICAgIAo8L3A+CjxwPgogICAgICAgICAgICAgIEFuIGV4YW1wbGUgc3VjY2Vzc2Z1bCByZXNwb25z ZToKICAgICAgICAgICAgCjwvcD48ZGl2IHN0eWxlPSdkaXNwbGF5OiB0YWJsZTsgd2lkdGg6IDA7 IG1hcmdpbi1sZWZ0OiAzZW07IG1hcmdpbi1yaWdodDogYXV0byc+PHByZT4KCiAgSFRUUC8xLjEg MjAwIE9LCiAgQ29udGVudC1UeXBlOiBhcHBsaWNhdGlvbi9qc29uO2NoYXJzZXQ9VVRGLTgKICBD YWNoZS1Db250cm9sOiBuby1zdG9yZQogIFByYWdtYTogbm8tY2FjaGUKCiAgewogICAgImFjY2Vz c190b2tlbiI6IjJZb3RuRlpGRWpyMXpDc2ljTVdwQUEiLAogICAgInRva2VuX3R5cGUiOiJleGFt cGxlIiwKICAgICJleHBpcmVzX2luIjozNjAwLAogICAgImV4YW1wbGVfcGFyYW1ldGVyIjoiZXhh bXBsZV92YWx1ZSIKICB9Cgo8L3ByZT48L2Rpdj4KPGEgbmFtZT0iZXh0LWdyYW50Ij48L2E+PGJy IC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3Bh Y2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0Ni dWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4K PGEgbmFtZT0icmZjLnNlY3Rpb24uNC41Ij48L2E+PGgzPjQuNS4mbmJzcDsKRXh0ZW5zaW9uIEdy YW50czwvaDM+Cgo8cD4KICAgICAgICAgIFRoZSBjbGllbnQgdXNlcyBhbiBleHRlbnNpb24gZ3Jh bnQgdHlwZSBieSBzcGVjaWZ5aW5nIHRoZSBncmFudCB0eXBlIHVzaW5nIGFuCiAgICAgICAgICBh YnNvbHV0ZSBVUkkgKGRlZmluZWQgYnkgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyKSBhcyB0aGUg dmFsdWUgb2YgdGhlCiAgICAgICAgICA8dHQ+Z3JhbnRfdHlwZTwvdHQ+IHBhcmFtZXRlciBvZiB0 aGUgdG9rZW4gZW5kcG9pbnQsIGFuZCBieQogICAgICAgICAgYWRkaW5nIGFueSBhZGRpdGlvbmFs IHBhcmFtZXRlcnMgbmVjZXNzYXJ5LgogICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgICBGb3Ig ZXhhbXBsZSwgdG8gcmVxdWVzdCBhbiBhY2Nlc3MgdG9rZW4gdXNpbmcgYSBTQU1MIDIuMCBhc3Nl cnRpb24gZ3JhbnQgdHlwZSBhcwogICAgICAgICAgICBkZWZpbmVkIGJ5IDxhIGNsYXNzPSdpbmZv JyBocmVmPScjSS1ELmlldGYtb2F1dGgtc2FtbDItYmVhcmVyJz5bSSYjODIwOTtELmlldGYmIzgy MDk7b2F1dGgmIzgyMDk7c2FtbDImIzgyMDk7YmVhcmVyXTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNs YXNzPSdpbmZvJz5Nb3J0aW1vcmUsIEMuLCAmbGRxdW87U0FNTCAyLjAgQmVhcmVyIEFzc2VydGlv biBQcm9maWxlcyBmb3IgT0F1dGggMi4wLCZyZHF1bzsgTWF5Jm5ic3A7MjAxMi48L3NwYW4+PHNw YW4+KTwvc3Bhbj48L2E+LCB0aGUgY2xpZW50IG1ha2VzIHRoZQogICAgICAgICAgICBmb2xsb3dp bmcgSFRUUCByZXF1ZXN0IHVzaW5nIFRMUyAobGluZSBicmVha3MgYXJlIGZvciBkaXNwbGF5IHB1 cnBvc2VzIG9ubHkpOgogICAgICAgICAgCjwvcD48ZGl2IHN0eWxlPSdkaXNwbGF5OiB0YWJsZTsg d2lkdGg6IDA7IG1hcmdpbi1sZWZ0OiAzZW07IG1hcmdpbi1yaWdodDogYXV0byc+PHByZT4KCiAg UE9TVCAvdG9rZW4gSFRUUC8xLjEKICBIb3N0OiBzZXJ2ZXIuZXhhbXBsZS5jb20KICBDb250ZW50 LVR5cGU6IGFwcGxpY2F0aW9uL3gtd3d3LWZvcm0tdXJsZW5jb2RlZDtjaGFyc2V0PVVURi04Cgog IGdyYW50X3R5cGU9dXJuJTNBaWV0ZiUzQXBhcmFtcyUzQW9hdXRoJTNBZ3JhbnQtdHlwZSUzQXNh bWwyLQogIGJlYXJlciZhbXA7YXNzZXJ0aW9uPVBFRnpjMlZ5ZEdsdmJpQkpjM04xWlVsdWMzUmhi blE5SWpJd01URXRNRFUKICBbLi4ub21pdHRlZCBmb3IgYnJldml0eS4uLl1hRzVUZEdGMFpXMWxi blEtUEM5QmMzTmxjblJwYjI0LQoKPC9wcmU+PC9kaXY+CjxwPgogICAgICAgICAgSWYgdGhlIGFj Y2VzcyB0b2tlbiByZXF1ZXN0IGlzIHZhbGlkIGFuZCBhdXRob3JpemVkLCB0aGUgYXV0aG9yaXph dGlvbiBzZXJ2ZXIgaXNzdWVzIGFuCiAgICAgICAgICBhY2Nlc3MgdG9rZW4gYW5kIG9wdGlvbmFs IHJlZnJlc2ggdG9rZW4gYXMgZGVzY3JpYmVkIGluIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjdG9r ZW4tcmVzcG9uc2UnPlNlY3Rpb24mbmJzcDs1LjE8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0n aW5mbyc+U3VjY2Vzc2Z1bCBSZXNwb25zZTwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4uCiAgICAg ICAgICBJZiB0aGUgcmVxdWVzdCBmYWlsZWQgY2xpZW50IGF1dGhlbnRpY2F0aW9uIG9yIGlzIGlu dmFsaWQsIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciByZXR1cm5zCiAgICAgICAgICBhbiBlcnJv ciByZXNwb25zZSBhcyBkZXNjcmliZWQgaW4gPGEgY2xhc3M9J2luZm8nIGhyZWY9JyN0b2tlbi1l cnJvcnMnPlNlY3Rpb24mbmJzcDs1LjI8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+ RXJyb3IgUmVzcG9uc2U8L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+LgogICAgICAgIAo8L3A+Cjxh IG5hbWU9InRva2VuLWlzc3VlIj48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlv dXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249 InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZu YnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uNSI+PC9hPjxo Mz41LiZuYnNwOwpJc3N1aW5nIGFuIEFjY2VzcyBUb2tlbjwvaDM+Cgo8cD4KICAgICAgICBJZiB0 aGUgYWNjZXNzIHRva2VuIHJlcXVlc3QgaXMgdmFsaWQgYW5kIGF1dGhvcml6ZWQsIHRoZSBhdXRo b3JpemF0aW9uIHNlcnZlciBpc3N1ZXMgYW4KICAgICAgICBhY2Nlc3MgdG9rZW4gYW5kIG9wdGlv bmFsIHJlZnJlc2ggdG9rZW4gYXMgZGVzY3JpYmVkIGluIDxhIGNsYXNzPSdpbmZvJyBocmVmPScj dG9rZW4tcmVzcG9uc2UnPlNlY3Rpb24mbmJzcDs1LjE8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFz cz0naW5mbyc+U3VjY2Vzc2Z1bCBSZXNwb25zZTwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4uCiAg ICAgICAgSWYgdGhlIHJlcXVlc3QgZmFpbGVkIGNsaWVudCBhdXRoZW50aWNhdGlvbiBvciBpcyBp bnZhbGlkLCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgcmV0dXJucwogICAgICAgIGFuIGVycm9y IHJlc3BvbnNlIGFzIGRlc2NyaWJlZCBpbiA8YSBjbGFzcz0naW5mbycgaHJlZj0nI3Rva2VuLWVy cm9ycyc+U2VjdGlvbiZuYnNwOzUuMjxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5F cnJvciBSZXNwb25zZTwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4uCiAgICAgIAo8L3A+CjxhIG5h bWU9InRva2VuLXJlc3BvbnNlIj48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlv dXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249 InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZu YnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uNS4xIj48L2E+ PGgzPjUuMS4mbmJzcDsKU3VjY2Vzc2Z1bCBSZXNwb25zZTwvaDM+Cgo8cD4KICAgICAgICAgIFRo ZSBhdXRob3JpemF0aW9uIHNlcnZlciBpc3N1ZXMgYW4gYWNjZXNzIHRva2VuIGFuZCBvcHRpb25h bCByZWZyZXNoIHRva2VuLCBhbmQKICAgICAgICAgIGNvbnN0cnVjdHMgdGhlIHJlc3BvbnNlIGJ5 IGFkZGluZyB0aGUgZm9sbG93aW5nIHBhcmFtZXRlcnMgdG8gdGhlIGVudGl0eSBib2R5IG9mIHRo ZSBIVFRQCiAgICAgICAgICByZXNwb25zZSB3aXRoIGEgMjAwIChPSykgc3RhdHVzIGNvZGU6CiAg ICAgICAgCjwvcD4KPHA+CiAgICAgICAgICA8L3A+CjxibG9ja3F1b3RlIGNsYXNzPSJ0ZXh0Ij48 ZGw+CjxkdD5hY2Nlc3NfdG9rZW48L2R0Pgo8ZGQ+CiAgICAgICAgICAgICAgCiAgICAgICAgICAg ICAgUkVRVUlSRUQuIFRoZSBhY2Nlc3MgdG9rZW4gaXNzdWVkIGJ5IHRoZSBhdXRob3JpemF0aW9u IHNlcnZlci4KICAgICAgICAgICAgCjwvZGQ+CjxkdD50b2tlbl90eXBlPC9kdD4KPGRkPgogICAg ICAgICAgICAgIAogICAgICAgICAgICAgIFJFUVVJUkVELiBUaGUgdHlwZSBvZiB0aGUgdG9rZW4g aXNzdWVkIGFzIGRlc2NyaWJlZCBpbiA8YSBjbGFzcz0naW5mbycgaHJlZj0nI3Rva2VuLXR5cGVz Jz5TZWN0aW9uJm5ic3A7Ny4xPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkFjY2Vz cyBUb2tlbiBUeXBlczwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4uCiAgICAgICAgICAgICAgVmFs dWUgaXMgY2FzZSBpbnNlbnNpdGl2ZS4KICAgICAgICAgICAgCjwvZGQ+CjxkdD5leHBpcmVzX2lu PC9kdD4KPGRkPgogICAgICAgICAgICAgIAogICAgICAgICAgICAgIFJFQ09NTUVOREVELiBUaGUg bGlmZXRpbWUgaW4gc2Vjb25kcyBvZiB0aGUgYWNjZXNzIHRva2VuLiBGb3IgZXhhbXBsZSwgdGhl IHZhbHVlCiAgICAgICAgICAgICAgPHR0PjM2MDA8L3R0PiBkZW5vdGVzIHRoYXQgdGhlIGFjY2Vz cyB0b2tlbiB3aWxsIGV4cGlyZSBpbiBvbmUKICAgICAgICAgICAgICBob3VyIGZyb20gdGhlIHRp bWUgdGhlIHJlc3BvbnNlIHdhcyBnZW5lcmF0ZWQuIElmIG9taXR0ZWQsIHRoZSBhdXRob3JpemF0 aW9uIHNlcnZlcgogICAgICAgICAgICAgIFNIT1VMRCBwcm92aWRlIHRoZSBleHBpcmF0aW9uIHRp bWUgdmlhIG90aGVyIG1lYW5zIG9yIGRvY3VtZW50IHRoZSBkZWZhdWx0IHZhbHVlLgogICAgICAg ICAgICAKPC9kZD4KPGR0PnJlZnJlc2hfdG9rZW48L2R0Pgo8ZGQ+CiAgICAgICAgICAgICAgCiAg ICAgICAgICAgICAgT1BUSU9OQUwuIFRoZSByZWZyZXNoIHRva2VuIHdoaWNoIGNhbiBiZSB1c2Vk IHRvIG9idGFpbiBuZXcgYWNjZXNzIHRva2VucyB1c2luZyB0aGUKICAgICAgICAgICAgICBzYW1l IGF1dGhvcml6YXRpb24gZ3JhbnQgYXMgZGVzY3JpYmVkIGluIDxhIGNsYXNzPSdpbmZvJyBocmVm PScjdG9rZW4tcmVmcmVzaCc+U2VjdGlvbiZuYnNwOzY8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFz cz0naW5mbyc+UmVmcmVzaGluZyBhbiBBY2Nlc3MgVG9rZW48L3NwYW4+PHNwYW4+KTwvc3Bhbj48 L2E+LgogICAgICAgICAgICAKPC9kZD4KPGR0PnNjb3BlPC9kdD4KPGRkPgogICAgICAgICAgICAg IAogICAgICAgICAgICAgIE9QVElPTkFMLCBpZiBpZGVudGljYWwgdG8gdGhlIHNjb3BlIHJlcXVl c3RlZCBieSB0aGUgY2xpZW50LCBvdGhlcndpc2UgUkVRVUlSRUQuIFRoZQogICAgICAgICAgICAg IHNjb3BlIG9mIHRoZSBhY2Nlc3MgdG9rZW4gYXMgZGVzY3JpYmVkIGJ5IDxhIGNsYXNzPSdpbmZv JyBocmVmPScjc2NvcGUnPlNlY3Rpb24mbmJzcDszLjM8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFz cz0naW5mbyc+QWNjZXNzIFRva2VuIFNjb3BlPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPi4KICAg ICAgICAgICAgCjwvZGQ+CjwvZGw+PC9ibG9ja3F1b3RlPjxwPgogICAgICAgIAo8L3A+CjxwPgog ICAgICAgICAgVGhlIHBhcmFtZXRlcnMgYXJlIGluY2x1ZGVkIGluIHRoZSBlbnRpdHkgYm9keSBv ZiB0aGUgSFRUUCByZXNwb25zZSB1c2luZyB0aGUKICAgICAgICAgIDx0dD5hcHBsaWNhdGlvbi9q c29uPC90dD4gbWVkaWEgdHlwZSBhcyBkZWZpbmVkIGJ5CiAgICAgICAgICA8YSBjbGFzcz0naW5m bycgaHJlZj0nI1JGQzQ2MjcnPltSRkM0NjI3XTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdp bmZvJz5Dcm9ja2ZvcmQsIEQuLCAmbGRxdW87VGhlIGFwcGxpY2F0aW9uL2pzb24gTWVkaWEgVHlw ZSBmb3IgSmF2YVNjcmlwdCBPYmplY3QgTm90YXRpb24gKEpTT04pLCZyZHF1bzsgSnVseSZuYnNw OzIwMDYuPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPi4gVGhlIHBhcmFtZXRlcnMgYXJlIHNlcmlh bGl6ZWQgaW50byBhIEpTT04gc3RydWN0dXJlIGJ5CiAgICAgICAgICBhZGRpbmcgZWFjaCBwYXJh bWV0ZXIgYXQgdGhlIGhpZ2hlc3Qgc3RydWN0dXJlIGxldmVsLiBQYXJhbWV0ZXIgbmFtZXMgYW5k IHN0cmluZyB2YWx1ZXMKICAgICAgICAgIGFyZSBpbmNsdWRlZCBhcyBKU09OIHN0cmluZ3MuIE51 bWVyaWNhbCB2YWx1ZXMgYXJlIGluY2x1ZGVkIGFzIEpTT04gbnVtYmVycy4gVGhlIG9yZGVyIG9m CiAgICAgICAgICBwYXJhbWV0ZXJzIGRvZXMgbm90IG1hdHRlciBhbmQgY2FuIHZhcnkuCiAgICAg ICAgCjwvcD4KPHA+CiAgICAgICAgICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVTVCBpbmNs dWRlIHRoZSBIVFRQCiAgICAgICAgICA8dHQ+Q2FjaGUtQ29udHJvbDwvdHQ+IHJlc3BvbnNlIGhl YWRlciBmaWVsZCA8YSBjbGFzcz0naW5mbycgaHJlZj0nI1JGQzI2MTYnPltSRkMyNjE2XTxzcGFu PiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5GaWVsZGluZywgUi4sIEdldHR5cywgSi4sIE1v Z3VsLCBKLiwgRnJ5c3R5aywgSC4sIE1hc2ludGVyLCBMLiwgTGVhY2gsIFAuLCBhbmQgVC4gQmVy bmVycy1MZWUsICZsZHF1bztIeXBlcnRleHQgVHJhbnNmZXIgUHJvdG9jb2wgLS0gSFRUUC8xLjEs JnJkcXVvOyBKdW5lJm5ic3A7MTk5OS48L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+CiAgICAgICAg ICB3aXRoIGEgdmFsdWUgb2YgPHR0Pm5vLXN0b3JlPC90dD4gaW4gYW55IHJlc3BvbnNlIGNvbnRh aW5pbmcgdG9rZW5zLAogICAgICAgICAgY3JlZGVudGlhbHMsIG9yIG90aGVyIHNlbnNpdGl2ZSBp bmZvcm1hdGlvbiwgYXMgd2VsbCBhcyB0aGUKICAgICAgICAgIDx0dD5QcmFnbWE8L3R0PiByZXNw b25zZSBoZWFkZXIgZmllbGQgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNSRkMyNjE2Jz5bUkZDMjYx Nl08c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+RmllbGRpbmcsIFIuLCBHZXR0eXMs IEouLCBNb2d1bCwgSi4sIEZyeXN0eWssIEguLCBNYXNpbnRlciwgTC4sIExlYWNoLCBQLiwgYW5k IFQuIEJlcm5lcnMtTGVlLCAmbGRxdW87SHlwZXJ0ZXh0IFRyYW5zZmVyIFByb3RvY29sIC0tIEhU VFAvMS4xLCZyZHF1bzsgSnVuZSZuYnNwOzE5OTkuPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPiB3 aXRoIGEKICAgICAgICAgIHZhbHVlIG9mIDx0dD5uby1jYWNoZTwvdHQ+LgogICAgICAgIAo8L3A+ CjxwPgogICAgICAgICAgICBGb3IgZXhhbXBsZToKICAgICAgICAgIAo8L3A+PGRpdiBzdHlsZT0n ZGlzcGxheTogdGFibGU7IHdpZHRoOiAwOyBtYXJnaW4tbGVmdDogM2VtOyBtYXJnaW4tcmlnaHQ6 IGF1dG8nPjxwcmU+CgogIEhUVFAvMS4xIDIwMCBPSwogIENvbnRlbnQtVHlwZTogYXBwbGljYXRp b24vanNvbjtjaGFyc2V0PVVURi04CiAgQ2FjaGUtQ29udHJvbDogbm8tc3RvcmUKICBQcmFnbWE6 IG5vLWNhY2hlCgogIHsKICAgICJhY2Nlc3NfdG9rZW4iOiIyWW90bkZaRkVqcjF6Q3NpY01XcEFB IiwKICAgICJ0b2tlbl90eXBlIjoiZXhhbXBsZSIsCiAgICAiZXhwaXJlc19pbiI6MzYwMCwKICAg ICJyZWZyZXNoX3Rva2VuIjoidEd6djNKT2tGMFhHNVF4MlRsS1dJQSIsCiAgICAiZXhhbXBsZV9w YXJhbWV0ZXIiOiJleGFtcGxlX3ZhbHVlIgogIH0KCjwvcHJlPjwvZGl2Pgo8cD4KICAgICAgICAg IFRoZSBjbGllbnQgTVVTVCBpZ25vcmUgdW5yZWNvZ25pemVkIHZhbHVlIG5hbWVzIGluIHRoZSBy ZXNwb25zZS4gVGhlIHNpemVzIG9mIHRva2VucyBhbmQKICAgICAgICAgIG90aGVyIHZhbHVlcyBy ZWNlaXZlZCBmcm9tIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBhcmUgbGVmdCB1bmRlZmluZWQu IFRoZSBjbGllbnQgc2hvdWxkCiAgICAgICAgICBhdm9pZCBtYWtpbmcgYXNzdW1wdGlvbnMgYWJv dXQgdmFsdWUgc2l6ZXMuIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBTSE9VTEQgZG9jdW1lbnQg dGhlCiAgICAgICAgICBzaXplIG9mIGFueSB2YWx1ZSBpdCBpc3N1ZXMuCiAgICAgICAgCjwvcD4K PGEgbmFtZT0idG9rZW4tZXJyb3JzIj48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJs YXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxp Z249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RP QyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uNS4yIj48 L2E+PGgzPjUuMi4mbmJzcDsKRXJyb3IgUmVzcG9uc2U8L2gzPgoKPHA+CiAgICAgICAgICBUaGUg YXV0aG9yaXphdGlvbiBzZXJ2ZXIgcmVzcG9uZHMgd2l0aCBhbiBIVFRQIDQwMCAoQmFkIFJlcXVl c3QpIHN0YXR1cyBjb2RlICh1bmxlc3MKICAgICAgICAgIHNwZWNpZmllZCBvdGhlcndpc2UpIGFu ZCBpbmNsdWRlcyB0aGUgZm9sbG93aW5nIHBhcmFtZXRlcnMgd2l0aCB0aGUgcmVzcG9uc2U6CiAg ICAgICAgCjwvcD4KPHA+CiAgICAgICAgICA8L3A+CjxibG9ja3F1b3RlIGNsYXNzPSJ0ZXh0Ij48 ZGw+CjxkdD5lcnJvcjwvZHQ+CjxkZD4KICAgICAgICAgICAgICAKICAgICAgICAgICAgICBSRVFV SVJFRC4gQSBzaW5nbGUgQVNDSUkgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNVU0FTQ0lJJz5bVVNB U0NJSV08c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+QW1lcmljYW4gTmF0aW9uYWwg U3RhbmRhcmRzIEluc3RpdHV0ZSwgJmxkcXVvO0NvZGVkIENoYXJhY3RlciBTZXQgLS0gNy1iaXQg QW1lcmljYW4gU3RhbmRhcmQgQ29kZSBmb3IgSW5mb3JtYXRpb24gSW50ZXJjaGFuZ2UsJnJkcXVv OyAxOTg2Ljwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4gZXJyb3IgY29kZSBmcm9tIHRoZSBmb2xs b3dpbmc6CgogICAgICAgICAgICAgIAo8YmxvY2txdW90ZSBjbGFzcz0idGV4dCI+PGRsPgo8ZHQ+ aW52YWxpZF9yZXF1ZXN0PC9kdD4KPGRkPgogICAgICAgICAgICAgICAgICAKICAgICAgICAgICAg ICAgICAgVGhlIHJlcXVlc3QgaXMgbWlzc2luZyBhIHJlcXVpcmVkIHBhcmFtZXRlciwgaW5jbHVk ZXMgYW4gdW5zdXBwb3J0ZWQKICAgICAgICAgICAgICAgICAgcGFyYW1ldGVyIHZhbHVlIChvdGhl ciB0aGFuIGdyYW50IHR5cGUpLCByZXBlYXRzIGEgcGFyYW1ldGVyLCBpbmNsdWRlcyBtdWx0aXBs ZQogICAgICAgICAgICAgICAgICBjcmVkZW50aWFscywgdXRpbGl6ZXMgbW9yZSB0aGFuIG9uZSBt ZWNoYW5pc20gZm9yIGF1dGhlbnRpY2F0aW5nIHRoZSBjbGllbnQsCiAgICAgICAgICAgICAgICAg IG9yIGlzIG90aGVyd2lzZSBtYWxmb3JtZWQuCiAgICAgICAgICAgICAgICAKPC9kZD4KPGR0Pmlu dmFsaWRfY2xpZW50PC9kdD4KPGRkPgogICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAg ICAgQ2xpZW50IGF1dGhlbnRpY2F0aW9uIGZhaWxlZCAoZS5nLiB1bmtub3duIGNsaWVudCwgbm8g Y2xpZW50IGF1dGhlbnRpY2F0aW9uCiAgICAgICAgICAgICAgICAgIGluY2x1ZGVkLCBvciB1bnN1 cHBvcnRlZCBhdXRoZW50aWNhdGlvbiBtZXRob2QpLiBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIg TUFZCiAgICAgICAgICAgICAgICAgIHJldHVybiBhbiBIVFRQIDQwMSAoVW5hdXRob3JpemVkKSBz dGF0dXMgY29kZSB0byBpbmRpY2F0ZSB3aGljaCBIVFRQCiAgICAgICAgICAgICAgICAgIGF1dGhl bnRpY2F0aW9uIHNjaGVtZXMgYXJlIHN1cHBvcnRlZC4gSWYgdGhlIGNsaWVudCBhdHRlbXB0ZWQg dG8gYXV0aGVudGljYXRlIHZpYQogICAgICAgICAgICAgICAgICB0aGUgPHR0PkF1dGhvcml6YXRp b248L3R0PiByZXF1ZXN0IGhlYWRlciBmaWVsZCwKICAgICAgICAgICAgICAgICAgdGhlIGF1dGhv cml6YXRpb24gc2VydmVyIE1VU1QgcmVzcG9uZCB3aXRoIGFuIEhUVFAgNDAxIChVbmF1dGhvcml6 ZWQpIHN0YXR1cwogICAgICAgICAgICAgICAgICBjb2RlLCBhbmQgaW5jbHVkZSB0aGUgPHR0PldX Vy1BdXRoZW50aWNhdGU8L3R0PiByZXNwb25zZQogICAgICAgICAgICAgICAgICBoZWFkZXIgZmll bGQgbWF0Y2hpbmcgdGhlIGF1dGhlbnRpY2F0aW9uIHNjaGVtZSB1c2VkIGJ5IHRoZSBjbGllbnQu CiAgICAgICAgICAgICAgICAKPC9kZD4KPGR0PmludmFsaWRfZ3JhbnQ8L2R0Pgo8ZGQ+CiAgICAg ICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICBUaGUgcHJvdmlkZWQgYXV0aG9yaXphdGlv biBncmFudCAoZS5nLiBhdXRob3JpemF0aW9uIGNvZGUsIHJlc291cmNlIG93bmVyCiAgICAgICAg ICAgICAgICAgIGNyZWRlbnRpYWxzKSBvciByZWZyZXNoIHRva2VuIGlzIGludmFsaWQsIGV4cGly ZWQsIHJldm9rZWQsIGRvZXMgbm90IG1hdGNoIHRoZQogICAgICAgICAgICAgICAgICByZWRpcmVj dGlvbiBVUkkgdXNlZCBpbiB0aGUgYXV0aG9yaXphdGlvbiByZXF1ZXN0LCBvciB3YXMgaXNzdWVk IHRvIGFub3RoZXIKICAgICAgICAgICAgICAgICAgY2xpZW50LgogICAgICAgICAgICAgICAgCjwv ZGQ+CjxkdD51bmF1dGhvcml6ZWRfY2xpZW50PC9kdD4KPGRkPgogICAgICAgICAgICAgICAgICAK ICAgICAgICAgICAgICAgICAgVGhlIGF1dGhlbnRpY2F0ZWQgY2xpZW50IGlzIG5vdCBhdXRob3Jp emVkIHRvIHVzZSB0aGlzIGF1dGhvcml6YXRpb24gZ3JhbnQgdHlwZS4KICAgICAgICAgICAgICAg IAo8L2RkPgo8ZHQ+dW5zdXBwb3J0ZWRfZ3JhbnRfdHlwZTwvZHQ+CjxkZD4KICAgICAgICAgICAg ICAgICAgCiAgICAgICAgICAgICAgICAgIFRoZSBhdXRob3JpemF0aW9uIGdyYW50IHR5cGUgaXMg bm90IHN1cHBvcnRlZCBieSB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIuCiAgICAgICAgICAgICAg ICAKPC9kZD4KPGR0PmludmFsaWRfc2NvcGU8L2R0Pgo8ZGQ+CiAgICAgICAgICAgICAgICAgIAog ICAgICAgICAgICAgICAgICBUaGUgcmVxdWVzdGVkIHNjb3BlIGlzIGludmFsaWQsIHVua25vd24s IG1hbGZvcm1lZCwgb3IgZXhjZWVkcyB0aGUgc2NvcGUgZ3JhbnRlZAogICAgICAgICAgICAgICAg ICBieSB0aGUgcmVzb3VyY2Ugb3duZXIuCiAgICAgICAgICAgICAgICAKPC9kZD4KPC9kbD48L2Js b2NrcXVvdGU+CgoJICAgICAgVmFsdWVzIGZvciB0aGUgPHR0PmVycm9yPC90dD4gcGFyYW1ldGVy IE1VU1QgTk9UIGluY2x1ZGUKCSAgICAgIGNoYXJhY3RlcnMgb3V0c2lkZSB0aGUgc2V0ICV4MjAt MjEgLyAleDIzLTVCIC8gJXg1RC03RS4KICAgICAgICAgICAgCjwvZGQ+CjxkdD5lcnJvcl9kZXNj cmlwdGlvbjwvZHQ+CjxkZD4KICAgICAgICAgICAgICAKICAgICAgICAgICAgICBPUFRJT05BTC4g QSBodW1hbi1yZWFkYWJsZSBBU0NJSSA8YSBjbGFzcz0naW5mbycgaHJlZj0nI1VTQVNDSUknPltV U0FTQ0lJXTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5BbWVyaWNhbiBOYXRpb25h bCBTdGFuZGFyZHMgSW5zdGl0dXRlLCAmbGRxdW87Q29kZWQgQ2hhcmFjdGVyIFNldCAtLSA3LWJp dCBBbWVyaWNhbiBTdGFuZGFyZCBDb2RlIGZvciBJbmZvcm1hdGlvbiBJbnRlcmNoYW5nZSwmcmRx dW87IDE5ODYuPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPiB0ZXh0IHByb3ZpZGluZyBhZGRpdGlv bmFsIGluZm9ybWF0aW9uLAogICAgICAgICAgICAgIHVzZWQgdG8gYXNzaXN0IHRoZSBjbGllbnQg ZGV2ZWxvcGVyIGluIHVuZGVyc3RhbmRpbmcgdGhlIGVycm9yIHRoYXQgb2NjdXJyZWQuCgkgICAg ICA8YnIgLz4KCgkgICAgICBWYWx1ZXMgZm9yIHRoZSA8dHQ+ZXJyb3JfZGVzY3JpcHRpb248L3R0 PiBwYXJhbWV0ZXIgTVVTVCBOT1QgaW5jbHVkZQoJICAgICAgY2hhcmFjdGVycyBvdXRzaWRlIHRo ZSBzZXQgJXgyMC0yMSAvICV4MjMtNUIgLyAleDVELTdFLgogICAgICAgICAgICAKPC9kZD4KPGR0 PmVycm9yX3VyaTwvZHQ+CjxkZD4KICAgICAgICAgICAgICAKICAgICAgICAgICAgICBPUFRJT05B TC4gQSBVUkkgaWRlbnRpZnlpbmcgYSBodW1hbi1yZWFkYWJsZSB3ZWIgcGFnZSB3aXRoIGluZm9y bWF0aW9uIGFib3V0IHRoZQogICAgICAgICAgICAgIGVycm9yLCB1c2VkIHRvIHByb3ZpZGUgdGhl IGNsaWVudCBkZXZlbG9wZXIgd2l0aCBhZGRpdGlvbmFsIGluZm9ybWF0aW9uIGFib3V0IHRoZQog ICAgICAgICAgICAgIGVycm9yLgoJICAgICAgPGJyIC8+CgoJICAgICAgVmFsdWVzIGZvciB0aGUg PHR0PmVycm9yX3VyaTwvdHQ+IHBhcmFtZXRlcgoJICAgICAgTVVTVCBjb25mb3JtIHRvIHRoZSBV UkktUmVmZXJlbmNlIHN5bnRheCwgYW5kIHRodXMgTVVTVCBOT1QgaW5jbHVkZQoJICAgICAgY2hh cmFjdGVycyBvdXRzaWRlIHRoZSBzZXQgJXgyMSAvICV4MjMtNUIgLyAleDVELTdFLgogICAgICAg ICAgICAKPC9kZD4KPC9kbD48L2Jsb2NrcXVvdGU+PHA+CiAgICAgICAgCjwvcD4KPHA+CiAgICAg ICAgICBUaGUgcGFyYW1ldGVycyBhcmUgaW5jbHVkZWQgaW4gdGhlIGVudGl0eSBib2R5IG9mIHRo ZSBIVFRQIHJlc3BvbnNlIHVzaW5nIHRoZQogICAgICAgICAgPHR0PmFwcGxpY2F0aW9uL2pzb248 L3R0PiBtZWRpYSB0eXBlIGFzIGRlZmluZWQgYnkKICAgICAgICAgIDxhIGNsYXNzPSdpbmZvJyBo cmVmPScjUkZDNDYyNyc+W1JGQzQ2MjddPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8n PkNyb2NrZm9yZCwgRC4sICZsZHF1bztUaGUgYXBwbGljYXRpb24vanNvbiBNZWRpYSBUeXBlIGZv ciBKYXZhU2NyaXB0IE9iamVjdCBOb3RhdGlvbiAoSlNPTiksJnJkcXVvOyBKdWx5Jm5ic3A7MjAw Ni48L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+LiBUaGUgcGFyYW1ldGVycyBhcmUgc2VyaWFsaXpl ZCBpbnRvIGEgSlNPTiBzdHJ1Y3R1cmUgYnkKICAgICAgICAgIGFkZGluZyBlYWNoIHBhcmFtZXRl ciBhdCB0aGUgaGlnaGVzdCBzdHJ1Y3R1cmUgbGV2ZWwuIFBhcmFtZXRlciBuYW1lcyBhbmQgc3Ry aW5nIHZhbHVlcwogICAgICAgICAgYXJlIGluY2x1ZGVkIGFzIEpTT04gc3RyaW5ncy4gTnVtZXJp Y2FsIHZhbHVlcyBhcmUgaW5jbHVkZWQgYXMgSlNPTiBudW1iZXJzLiBUaGUgb3JkZXIgb2YKICAg ICAgICAgIHBhcmFtZXRlcnMgZG9lcyBub3QgbWF0dGVyIGFuZCBjYW4gdmFyeS4KICAgICAgICAK PC9wPgo8cD4KICAgICAgICAgICAgRm9yIGV4YW1wbGU6CiAgICAgICAgICAKPC9wPjxkaXYgc3R5 bGU9J2Rpc3BsYXk6IHRhYmxlOyB3aWR0aDogMDsgbWFyZ2luLWxlZnQ6IDNlbTsgbWFyZ2luLXJp Z2h0OiBhdXRvJz48cHJlPgoKICBIVFRQLzEuMSA0MDAgQmFkIFJlcXVlc3QKICBDb250ZW50LVR5 cGU6IGFwcGxpY2F0aW9uL2pzb247Y2hhcnNldD1VVEYtOAogIENhY2hlLUNvbnRyb2w6IG5vLXN0 b3JlCiAgUHJhZ21hOiBuby1jYWNoZQoKICB7CiAgICAiZXJyb3IiOiJpbnZhbGlkX3JlcXVlc3Qi CiAgfQoKPC9wcmU+PC9kaXY+CjxhIG5hbWU9InRva2VuLXJlZnJlc2giPjwvYT48YnIgLz48aHIg Lz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIy IiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEg aHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1l PSJyZmMuc2VjdGlvbi42Ij48L2E+PGgzPjYuJm5ic3A7ClJlZnJlc2hpbmcgYW4gQWNjZXNzIFRv a2VuPC9oMz4KCjxwPgogICAgICAgIElmIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBpc3N1ZWQg YSByZWZyZXNoIHRva2VuIHRvIHRoZSBjbGllbnQsIHRoZSBjbGllbnQgbWFrZXMgYQogICAgICAg IHJlZnJlc2ggcmVxdWVzdCB0byB0aGUgdG9rZW4gZW5kcG9pbnQgYnkgYWRkaW5nIHRoZSBmb2xs b3dpbmcgcGFyYW1ldGVycyB1c2luZyB0aGUKICAgICAgICA8dHQ+YXBwbGljYXRpb24veC13d3ct Zm9ybS11cmxlbmNvZGVkPC90dD4gZm9ybWF0IGluIHRoZSBIVFRQIHJlcXVlc3QKICAgICAgICBl bnRpdHktYm9keToKICAgICAgCjwvcD4KPHA+CiAgICAgICAgPC9wPgo8YmxvY2txdW90ZSBjbGFz cz0idGV4dCI+PGRsPgo8ZHQ+Z3JhbnRfdHlwZTwvZHQ+CjxkZD4KICAgICAgICAgICAgCiAgICAg ICAgICAgIFJFUVVJUkVELiBWYWx1ZSBNVVNUIGJlIHNldCB0byA8dHQ+cmVmcmVzaF90b2tlbjwv dHQ+LgogICAgICAgICAgCjwvZGQ+CjxkdD5yZWZyZXNoX3Rva2VuPC9kdD4KPGRkPgogICAgICAg ICAgICAKICAgICAgICAgICAgUkVRVUlSRUQuIFRoZSByZWZyZXNoIHRva2VuIGlzc3VlZCB0byB0 aGUgY2xpZW50LgogICAgICAgICAgCjwvZGQ+CjxkdD5zY29wZTwvZHQ+CjxkZD4KICAgICAgICAg ICAgCiAgICAgICAgICAgIE9QVElPTkFMLiBUaGUgc2NvcGUgb2YgdGhlIGFjY2VzcyByZXF1ZXN0 IGFzIGRlc2NyaWJlZCBieSA8YSBjbGFzcz0naW5mbycgaHJlZj0nI3Njb3BlJz5TZWN0aW9uJm5i c3A7My4zPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkFjY2VzcyBUb2tlbiBTY29w ZTwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4uCiAgICAgICAgICAgIFRoZSByZXF1ZXN0ZWQgc2Nv cGUgTVVTVCBOT1QgaW5jbHVkZSBhbnkgc2NvcGUgbm90IG9yaWdpbmFsbHkgZ3JhbnRlZCBieSB0 aGUgcmVzb3VyY2UKICAgICAgICAgICAgb3duZXIsIGFuZCBpZiBvbWl0dGVkIGlzIHRyZWF0ZWQg YXMgZXF1YWwgdG8gdGhlIHNjb3BlIG9yaWdpbmFsbHkgZ3JhbnRlZCBieSB0aGUKICAgICAgICAg ICAgcmVzb3VyY2Ugb3duZXIuCiAgICAgICAgICAKPC9kZD4KPC9kbD48L2Jsb2NrcXVvdGU+PHA+ CiAgICAgIAo8L3A+CjxwPgogICAgICAgIEJlY2F1c2UgcmVmcmVzaCB0b2tlbnMgYXJlIHR5cGlj YWxseSBsb25nLWxhc3RpbmcgY3JlZGVudGlhbHMgdXNlZCB0byByZXF1ZXN0IGFkZGl0aW9uYWwK ICAgICAgICBhY2Nlc3MgdG9rZW5zLCB0aGUgcmVmcmVzaCB0b2tlbiBpcyBib3VuZCB0byB0aGUg Y2xpZW50IHdoaWNoIGl0IHdhcyBpc3N1ZWQuIElmIHRoZSBjbGllbnQgdHlwZQogICAgICAgIGlz IGNvbmZpZGVudGlhbCBvciB0aGUgY2xpZW50IHdhcyBpc3N1ZWQgY2xpZW50IGNyZWRlbnRpYWxz IChvciBhc3NpZ25lZCBvdGhlcgogICAgICAgIGF1dGhlbnRpY2F0aW9uIHJlcXVpcmVtZW50cyks IHRoZSBjbGllbnQgTVVTVCBhdXRoZW50aWNhdGUgd2l0aCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2 ZXIgYXMKICAgICAgICBkZXNjcmliZWQgaW4gPGEgY2xhc3M9J2luZm8nIGhyZWY9JyN0b2tlbi1l bmRwb2ludC1hdXRoJz5TZWN0aW9uJm5ic3A7My4yLjE8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFz cz0naW5mbyc+Q2xpZW50IEF1dGhlbnRpY2F0aW9uPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPi4K ICAgICAgCjwvcD4KPHA+CiAgICAgICAgICBGb3IgZXhhbXBsZSwgdGhlIGNsaWVudCBtYWtlcyB0 aGUgZm9sbG93aW5nIEhUVFAgcmVxdWVzdCB1c2luZyB0cmFuc3BvcnQtbGF5ZXIKICAgICAgICAg IHNlY3VyaXR5IChleHRyYSBsaW5lIGJyZWFrcyBhcmUgZm9yIGRpc3BsYXkgcHVycG9zZXMgb25s eSk6CiAgICAgICAgCjwvcD48ZGl2IHN0eWxlPSdkaXNwbGF5OiB0YWJsZTsgd2lkdGg6IDA7IG1h cmdpbi1sZWZ0OiAzZW07IG1hcmdpbi1yaWdodDogYXV0byc+PHByZT4KCiAgUE9TVCAvdG9rZW4g SFRUUC8xLjEKICBIb3N0OiBzZXJ2ZXIuZXhhbXBsZS5jb20KICBBdXRob3JpemF0aW9uOiBCYXNp YyBjelpDYUdSU2EzRjBNenBuV0RGbVFtRjBNMkpXCiAgQ29udGVudC1UeXBlOiBhcHBsaWNhdGlv bi94LXd3dy1mb3JtLXVybGVuY29kZWQ7Y2hhcnNldD1VVEYtOAoKICBncmFudF90eXBlPXJlZnJl c2hfdG9rZW4mYW1wO3JlZnJlc2hfdG9rZW49dEd6djNKT2tGMFhHNVF4MlRsS1dJQQoKPC9wcmU+ PC9kaXY+CjxwPgogICAgICAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBNVVNUOgogICAgICAK PC9wPgo8cD4KICAgICAgICA8L3A+Cjx1bCBjbGFzcz0idGV4dCI+CjxsaT4KICAgICAgICAgICAg cmVxdWlyZSBjbGllbnQgYXV0aGVudGljYXRpb24gZm9yIGNvbmZpZGVudGlhbCBjbGllbnRzIG9y IGZvciBhbnkgY2xpZW50IHRoYXQgd2FzCiAgICAgICAgICAgIGlzc3VlZCBjbGllbnQgY3JlZGVu dGlhbHMgKG9yIHdpdGggb3RoZXIgYXV0aGVudGljYXRpb24gcmVxdWlyZW1lbnRzKSwKICAgICAg ICAgIAo8L2xpPgo8bGk+CiAgICAgICAgICAgIGF1dGhlbnRpY2F0ZSB0aGUgY2xpZW50IGlmIGNs aWVudCBhdXRoZW50aWNhdGlvbiBpcyBpbmNsdWRlZCBhbmQgZW5zdXJlIHRoZQogICAgICAgICAg ICByZWZyZXNoIHRva2VuIHdhcyBpc3N1ZWQgdG8gdGhlIGF1dGhlbnRpY2F0ZWQgY2xpZW50LCBh bmQKICAgICAgICAgIAo8L2xpPgo8bGk+CiAgICAgICAgICAgIHZhbGlkYXRlIHRoZSByZWZyZXNo IHRva2VuLgogICAgICAgICAgCjwvbGk+CjwvdWw+PHA+CiAgICAgIAo8L3A+CjxwPgogICAgICAg IElmIHZhbGlkIGFuZCBhdXRob3JpemVkLCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgaXNzdWVz IGFuIGFjY2VzcyB0b2tlbiBhcyBkZXNjcmliZWQgaW4KICAgICAgICA8YSBjbGFzcz0naW5mbycg aHJlZj0nI3Rva2VuLXJlc3BvbnNlJz5TZWN0aW9uJm5ic3A7NS4xPHNwYW4+ICg8L3NwYW4+PHNw YW4gY2xhc3M9J2luZm8nPlN1Y2Nlc3NmdWwgUmVzcG9uc2U8L3NwYW4+PHNwYW4+KTwvc3Bhbj48 L2E+LiBJZiB0aGUgcmVxdWVzdCBmYWlsZWQgdmVyaWZpY2F0aW9uIG9yIGlzIGludmFsaWQsIHRo ZQogICAgICAgIGF1dGhvcml6YXRpb24gc2VydmVyIHJldHVybnMgYW4gZXJyb3IgcmVzcG9uc2Ug YXMgZGVzY3JpYmVkIGluCiAgICAgICAgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyN0b2tlbi1lcnJv cnMnPlNlY3Rpb24mbmJzcDs1LjI8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+RXJy b3IgUmVzcG9uc2U8L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+LgogICAgICAKPC9wPgo8cD4KICAg ICAgICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTUFZIGlzc3VlIGEgbmV3IHJlZnJlc2ggdG9r ZW4sIGluIHdoaWNoIGNhc2UgdGhlIGNsaWVudCBNVVNUCiAgICAgICAgZGlzY2FyZCB0aGUgb2xk IHJlZnJlc2ggdG9rZW4gYW5kIHJlcGxhY2UgaXQgd2l0aCB0aGUgbmV3IHJlZnJlc2ggdG9rZW4u IFRoZSBhdXRob3JpemF0aW9uCiAgICAgICAgc2VydmVyIE1BWSByZXZva2UgdGhlIG9sZCByZWZy ZXNoIHRva2VuIGFmdGVyIGlzc3VpbmcgYSBuZXcgcmVmcmVzaCB0b2tlbiB0byB0aGUgY2xpZW50 LiBJZgogICAgICAgIGEgbmV3IHJlZnJlc2ggdG9rZW4gaXMgaXNzdWVkLCB0aGUgcmVmcmVzaCB0 b2tlbiBzY29wZSBNVVNUIGJlIGlkZW50aWNhbCB0byB0aGF0IG9mIHRoZQogICAgICAgIHJlZnJl c2ggdG9rZW4gaW5jbHVkZWQgYnkgdGhlIGNsaWVudCBpbiB0aGUgcmVxdWVzdC4KICAgICAgCjwv cD4KPGEgbmFtZT0iYWNjZXNzLXJlc291cmNlIj48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1t YXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1 ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZu YnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24u NyI+PC9hPjxoMz43LiZuYnNwOwpBY2Nlc3NpbmcgUHJvdGVjdGVkIFJlc291cmNlczwvaDM+Cgo8 cD4KICAgICAgICBUaGUgY2xpZW50IGFjY2Vzc2VzIHByb3RlY3RlZCByZXNvdXJjZXMgYnkgcHJl c2VudGluZyB0aGUgYWNjZXNzIHRva2VuIHRvIHRoZSByZXNvdXJjZQogICAgICAgIHNlcnZlci4g VGhlIHJlc291cmNlIHNlcnZlciBNVVNUIHZhbGlkYXRlIHRoZSBhY2Nlc3MgdG9rZW4gYW5kIGVu c3VyZSBpdCBoYXMgbm90IGV4cGlyZWQKICAgICAgICBhbmQgdGhhdCBpdHMgc2NvcGUgY292ZXJz IHRoZSByZXF1ZXN0ZWQgcmVzb3VyY2UuIFRoZSBtZXRob2RzIHVzZWQgYnkgdGhlIHJlc291cmNl IHNlcnZlcgogICAgICAgIHRvIHZhbGlkYXRlIHRoZSBhY2Nlc3MgdG9rZW4gKGFzIHdlbGwgYXMg YW55IGVycm9yIHJlc3BvbnNlcykgYXJlIGJleW9uZCB0aGUgc2NvcGUgb2YgdGhpcwogICAgICAg IHNwZWNpZmljYXRpb24sIGJ1dCBnZW5lcmFsbHkgaW52b2x2ZSBhbiBpbnRlcmFjdGlvbiBvciBj b29yZGluYXRpb24gYmV0d2VlbiB0aGUgcmVzb3VyY2UKICAgICAgICBzZXJ2ZXIgYW5kIHRoZSBh dXRob3JpemF0aW9uIHNlcnZlci4KICAgICAgCjwvcD4KPHA+CiAgICAgICAgVGhlIG1ldGhvZCBp biB3aGljaCB0aGUgY2xpZW50IHV0aWxpemVzIHRoZSBhY2Nlc3MgdG9rZW4gdG8gYXV0aGVudGlj YXRlIHdpdGggdGhlIHJlc291cmNlCiAgICAgICAgc2VydmVyIGRlcGVuZHMgb24gdGhlIHR5cGUg b2YgYWNjZXNzIHRva2VuIGlzc3VlZCBieSB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIuIFR5cGlj YWxseSwKICAgICAgICBpdCBpbnZvbHZlcyB1c2luZyB0aGUgSFRUUCA8dHQ+QXV0aG9yaXphdGlv bjwvdHQ+IHJlcXVlc3QgaGVhZGVyIGZpZWxkCiAgICAgICAgPGEgY2xhc3M9J2luZm8nIGhyZWY9 JyNSRkMyNjE3Jz5bUkZDMjYxN108c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+RnJh bmtzLCBKLiwgSGFsbGFtLUJha2VyLCBQLiwgSG9zdGV0bGVyLCBKLiwgTGF3cmVuY2UsIFMuLCBM ZWFjaCwgUC4sIEx1b3RvbmVuLCBBLiwgYW5kIEwuIFN0ZXdhcnQsICZsZHF1bztIVFRQIEF1dGhl bnRpY2F0aW9uOiBCYXNpYyBhbmQgRGlnZXN0IEFjY2VzcyBBdXRoZW50aWNhdGlvbiwmcmRxdW87 IEp1bmUmbmJzcDsxOTk5Ljwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4gd2l0aCBhbiBhdXRoZW50 aWNhdGlvbiBzY2hlbWUgZGVmaW5lZCBieSB0aGUgYWNjZXNzIHRva2VuIHR5cGUKICAgICAgICBz cGVjaWZpY2F0aW9uLgogICAgICAKPC9wPgo8YSBuYW1lPSJ0b2tlbi10eXBlcyI+PC9hPjxiciAv PjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNp bmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVn Ij48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+Cjxh IG5hbWU9InJmYy5zZWN0aW9uLjcuMSI+PC9hPjxoMz43LjEuJm5ic3A7CkFjY2VzcyBUb2tlbiBU eXBlczwvaDM+Cgo8cD4KICAgICAgICAgIFRoZSBhY2Nlc3MgdG9rZW4gdHlwZSBwcm92aWRlcyB0 aGUgY2xpZW50IHdpdGggdGhlIGluZm9ybWF0aW9uIHJlcXVpcmVkIHRvIHN1Y2Nlc3NmdWxseQog ICAgICAgICAgdXRpbGl6ZSB0aGUgYWNjZXNzIHRva2VuIHRvIG1ha2UgYSBwcm90ZWN0ZWQgcmVz b3VyY2UgcmVxdWVzdCAoYWxvbmcgd2l0aCB0eXBlLXNwZWNpZmljCiAgICAgICAgICBhdHRyaWJ1 dGVzKS4gVGhlIGNsaWVudCBNVVNUIE5PVCB1c2UgYW4gYWNjZXNzIHRva2VuIGlmIGl0IGRvZXMg bm90IHVuZGVyc3RhbmQgdGhlIHRva2VuCiAgICAgICAgICB0eXBlLgogICAgICAgIAo8L3A+Cjxw PgogICAgICAgICAgICBGb3IgZXhhbXBsZSwgdGhlIDx0dD5iZWFyZXI8L3R0PiB0b2tlbiB0eXBl IGRlZmluZWQgaW4KICAgICAgICAgICAgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNJLUQuaWV0Zi1v YXV0aC12Mi1iZWFyZXInPltJJiM4MjA5O0QuaWV0ZiYjODIwOTtvYXV0aCYjODIwOTt2MiYjODIw OTtiZWFyZXJdPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkpvbmVzLCBNLiwgSGFy ZHQsIEQuLCBhbmQgRC4gUmVjb3Jkb24sICZsZHF1bztUaGUgT0F1dGggMi4wIEF1dGhvcml6YXRp b24gUHJvdG9jb2w6IEJlYXJlciBUb2tlbnMsJnJkcXVvOyBBcHJpbCZuYnNwOzIwMTIuPC9zcGFu PjxzcGFuPik8L3NwYW4+PC9hPiBpcyB1dGlsaXplZCBieSBzaW1wbHkgaW5jbHVkaW5nIHRoZSBh Y2Nlc3MKICAgICAgICAgICAgdG9rZW4gc3RyaW5nIGluIHRoZSByZXF1ZXN0OgogICAgICAgICAg CjwvcD48ZGl2IHN0eWxlPSdkaXNwbGF5OiB0YWJsZTsgd2lkdGg6IDA7IG1hcmdpbi1sZWZ0OiAz ZW07IG1hcmdpbi1yaWdodDogYXV0byc+PHByZT4KCiAgR0VUIC9yZXNvdXJjZS8xIEhUVFAvMS4x CiAgSG9zdDogZXhhbXBsZS5jb20KICBBdXRob3JpemF0aW9uOiBCZWFyZXIgbUZfOS5CNWYtNC4x SnFNCgo8L3ByZT48L2Rpdj4KPHA+CiAgICAgICAgICAgIHdoaWxlIHRoZSA8dHQ+bWFjPC90dD4g dG9rZW4gdHlwZSBkZWZpbmVkIGluCiAgICAgICAgICAgIDxhIGNsYXNzPSdpbmZvJyBocmVmPScj SS1ELmlldGYtb2F1dGgtdjItaHR0cC1tYWMnPltJJiM4MjA5O0QuaWV0ZiYjODIwOTtvYXV0aCYj ODIwOTt2MiYjODIwOTtodHRwJiM4MjA5O21hY108c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0n aW5mbyc+SGFtbWVyLUxhaGF2LCBFLiwgJmxkcXVvO0hUVFAgQXV0aGVudGljYXRpb246IE1BQyBB Y2Nlc3MgQXV0aGVudGljYXRpb24sJnJkcXVvOyBGZWJydWFyeSZuYnNwOzIwMTIuPC9zcGFuPjxz cGFuPik8L3NwYW4+PC9hPiBpcyB1dGlsaXplZCBieSBpc3N1aW5nIGEgTUFDIGtleQogICAgICAg ICAgICB0b2dldGhlciB3aXRoIHRoZSBhY2Nlc3MgdG9rZW4gd2hpY2ggaXMgdXNlZCB0byBzaWdu IGNlcnRhaW4gY29tcG9uZW50cyBvZiB0aGUgSFRUUAogICAgICAgICAgICByZXF1ZXN0czoKICAg ICAgICAgIAo8L3A+PGRpdiBzdHlsZT0nZGlzcGxheTogdGFibGU7IHdpZHRoOiAwOyBtYXJnaW4t bGVmdDogM2VtOyBtYXJnaW4tcmlnaHQ6IGF1dG8nPjxwcmU+CgogIEdFVCAvcmVzb3VyY2UvMSBI VFRQLzEuMQogIEhvc3Q6IGV4YW1wbGUuY29tCiAgQXV0aG9yaXphdGlvbjogTUFDIGlkPSJoNDgw ZGpzOTNoZDgiLAogICAgICAgICAgICAgICAgICAgICBub25jZT0iMjc0MzEyOmRqODNoczlzIiwK ICAgICAgICAgICAgICAgICAgICAgbWFjPSJrRFp2ZGRrbmR4dmhHUlhaaHZ1RGpFV2hHZUU9IgoK PC9wcmU+PC9kaXY+CjxwPgogICAgICAgICAgVGhlIGFib3ZlIGV4YW1wbGVzIGFyZSBwcm92aWRl ZCBmb3IgaWxsdXN0cmF0aW9uIHB1cnBvc2VzIG9ubHkuIERldmVsb3BlcnMgYXJlIGFkdmlzZWQg dG8KICAgICAgICAgIGNvbnN1bHQgdGhlIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjSS1ELmlldGYt b2F1dGgtdjItYmVhcmVyJz5bSSYjODIwOTtELmlldGYmIzgyMDk7b2F1dGgmIzgyMDk7djImIzgy MDk7YmVhcmVyXTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5Kb25lcywgTS4sIEhh cmR0LCBELiwgYW5kIEQuIFJlY29yZG9uLCAmbGRxdW87VGhlIE9BdXRoIDIuMCBBdXRob3JpemF0 aW9uIFByb3RvY29sOiBCZWFyZXIgVG9rZW5zLCZyZHF1bzsgQXByaWwmbmJzcDsyMDEyLjwvc3Bh bj48c3Bhbj4pPC9zcGFuPjwvYT4gYW5kCiAgICAgICAgICA8YSBjbGFzcz0naW5mbycgaHJlZj0n I0ktRC5pZXRmLW9hdXRoLXYyLWh0dHAtbWFjJz5bSSYjODIwOTtELmlldGYmIzgyMDk7b2F1dGgm IzgyMDk7djImIzgyMDk7aHR0cCYjODIwOTttYWNdPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9 J2luZm8nPkhhbW1lci1MYWhhdiwgRS4sICZsZHF1bztIVFRQIEF1dGhlbnRpY2F0aW9uOiBNQUMg QWNjZXNzIEF1dGhlbnRpY2F0aW9uLCZyZHF1bzsgRmVicnVhcnkmbmJzcDsyMDEyLjwvc3Bhbj48 c3Bhbj4pPC9zcGFuPjwvYT4gc3BlY2lmaWNhdGlvbnMgYmVmb3JlIHVzZS4KICAgICAgICAKPC9w Pgo8cD4KICAgICAgICAgIEVhY2ggYWNjZXNzIHRva2VuIHR5cGUgZGVmaW5pdGlvbiBzcGVjaWZp ZXMgdGhlIGFkZGl0aW9uYWwgYXR0cmlidXRlcyAoaWYgYW55KSBzZW50IHRvCiAgICAgICAgICB0 aGUgY2xpZW50IHRvZ2V0aGVyIHdpdGggdGhlIDx0dD5hY2Nlc3NfdG9rZW48L3R0PiByZXNwb25z ZSBwYXJhbWV0ZXIuCiAgICAgICAgICBJdCBhbHNvIGRlZmluZXMgdGhlIEhUVFAgYXV0aGVudGlj YXRpb24gbWV0aG9kIHVzZWQgdG8gaW5jbHVkZSB0aGUgYWNjZXNzIHRva2VuIHdoZW4KICAgICAg ICAgIG1ha2luZyBhIHByb3RlY3RlZCByZXNvdXJjZSByZXF1ZXN0LgogICAgICAgIAo8L3A+Cjxh IG5hbWU9InJlc291cmNlLWVycm9ycyI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0i bGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFs aWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtU T0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLjcuMiI+ PC9hPjxoMz43LjIuJm5ic3A7CkVycm9yIFJlc3BvbnNlPC9oMz4KCjxwPgoJICBJZiBhIHJlc291 cmNlIGFjY2VzcyByZXF1ZXN0IGZhaWxzLCB0aGUgcmVzb3VyY2Ugc2VydmVyIFNIT1VMRCBpbmZv cm0KCSAgdGhlIGNsaWVudCBvZiB0aGUgZXJyb3IuICBXaGlsZSB0aGUgc3BlY2lmaWMgZXJyb3Ig cmVzcG9uc2VzIHBvc3NpYmxlCgkgIGFuZCBtZXRob2RzIGZvciB0cmFuc21pdHRpbmcgdGhvc2Ug ZXJyb3JzIHdoZW4gdXNpbmcgYW55IHBhcnRpY3VsYXIKCSAgYWNjZXNzIHRva2VuIHR5cGUgYXJl IGJleW9uZCB0aGUgc2NvcGUgb2YgdGhpcyBzcGVjaWZpY2F0aW9uLAoJICBhbnkgPHR0PmVycm9y PC90dD4gY29kZSB2YWx1ZXMgZGVmaW5lZCBmb3IgdXNlIHdpdGgKCSAgT0F1dGggcmVzb3VyY2Ug YWNjZXNzIG1ldGhvZHMgTVVTVCBiZSByZWdpc3RlcmVkCgkgIChmb2xsb3dpbmcgdGhlIHByb2Nl ZHVyZXMgaW4gPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNlcnJvci1yZWdpc3RyeSc+U2VjdGlvbiZu YnNwOzExLjQ8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+VGhlIE9BdXRoIEV4dGVu c2lvbnMgRXJyb3IgUmVnaXN0cnk8L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+KS4KCQo8L3A+Cjxw PgoJICBTcGVjaWZpY2FsbHksIHdoZW4gdGhlIE9BdXRoIHJlc291cmNlIGFjY2VzcyBtZXRob2Qg dXNlcyBhbgoJICA8dHQ+ZXJyb3I8L3R0PiByZXN1bHQgcGFyYW1ldGVyIHRvIHJldHVybgoJICBh biBlcnJvciBjb2RlIHZhbHVlIHRoYXQgaW5kaWNhdGVzIHRoZSByZXNvdXJjZSBhY2Nlc3MgZXJy b3IKCSAgZW5jb3VudGVyZWQsIHRoZW4gdGhlc2UgZXJyb3IgY29kZSB2YWx1ZXMgTVVTVCBiZSBy ZWdpc3RlcmVkLgoJICBWYWx1ZXMgZm9yIHRoZXNlIDx0dD5lcnJvcjwvdHQ+IGNvZGVzIE1VU1Qg Tk9UIGluY2x1ZGUKCSAgY2hhcmFjdGVycyBvdXRzaWRlIHRoZSBzZXQgJXgyMC0yMSAvICV4MjMt NUIgLyAleDVELTdFLgoJICBXaGVuIGFuICA8dHQ+ZXJyb3I8L3R0PiBjb2RlIHZhbHVlIGlzIHJl Z2lzdGVyZWQKCSAgZm9yIHVzZSBieSBhbiBPQXV0aCByZXNvdXJjZSBhY2Nlc3MgbWV0aG9kLCBz aG91bGQgdGhhdCBzYW1lIGNvZGUgYWxyZWFkeQoJICBiZSByZWdpc3RlcmVkIGZvciB1c2UgYnkg YW5vdGhlciBPQXV0aCByZXNvdXJjZSBhY2Nlc3MgbWV0aG9kIG9yIGF0CgkgIGEgZGlmZmVyZW50 IE9BdXRoIGVycm9yIHVzYWdlIGxvY2F0aW9uLCB0aGVuIHRoZSBtZWFuaW5nIG9mIHRoYXQgZXJy b3IgY29kZQoJICB2YWx1ZSBpbiBpbiB0aGUgbmV3IHJlZ2lzdHJhdGlvbiBNVVNUIGJlIGNvbnNp c3RlbnQgd2l0aCB0aGUgaXRzIG1lYW5pbmcKCSAgaW4gcHJpb3IgcmVnaXN0cmF0aW9ucy4KCQo8 L3A+CjxwPgoJICBUaGUgT0F1dGggcmVzb3VyY2UgYWNjZXNzIGVycm9yIHJlZ2lzdHJhdGlvbiBy ZXF1aXJlbWVudCBhcHBsaWVzIG9ubHkgdG8KCSAgPHR0PmVycm9yPC90dD4gY29kZSB2YWx1ZXMg YW5kIG5vdCB0byBvdGhlcgoJICBtZWFucyBvZiByZXR1cm5pbmcgZXJyb3IgaW5kaWNhdGlvbnMs IGluY2x1ZGluZyBIVFRQIHN0YXR1cyBjb2RlcywKCSAgb3Igb3RoZXIgZXJyb3ItcmVsYXRlZCBy ZXN1bHQgcGFyYW1ldGVycywgc3VjaCBhcwoJICA8dHQ+ZXJyb3JfZGVzY3JpcHRpb248L3R0PiwK CSAgPHR0PmVycm9yX3VyaTwvdHQ+LCBvciBvdGhlciBraW5kcyBvZiBlcnJvcgoJICBzdGF0dXMg cmV0dXJuIG1ldGhvZHMgdGhhdCBtYXkgYmUgZW1wbG95ZWQgYnkgdGhlIHJlc291cmNlIGFjY2Vz cyBtZXRob2QuCgkgIFRoZXJlIGlzIG5vIHJlcXVpcmVtZW50IHRoYXQgT0F1dGggcmVzb3VyY2Ug YWNjZXNzIG1ldGhvZHMKCSAgZW1wbG95IGFuIDx0dD5lcnJvcjwvdHQ+IHBhcmFtZXRlci4KCQo8 L3A+CjxhIG5hbWU9ImV4dGVuc2lvbnMiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9 ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBh bGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7 VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi44Ij48 L2E+PGgzPjguJm5ic3A7CkV4dGVuc2liaWxpdHk8L2gzPgoKPGEgbmFtZT0ibmV3LXR5cGVzIj48 L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBj ZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNz PSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90 YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uOC4xIj48L2E+PGgzPjguMS4mbmJzcDsKRGVmaW5p bmcgQWNjZXNzIFRva2VuIFR5cGVzPC9oMz4KCjxwPgogICAgICAgICAgQWNjZXNzIHRva2VuIHR5 cGVzIGNhbiBiZSBkZWZpbmVkIGluIG9uZSBvZiB0d28gd2F5czogcmVnaXN0ZXJlZCBpbiB0aGUg YWNjZXNzIHRva2VuIHR5cGUKICAgICAgICAgIHJlZ2lzdHJ5IChmb2xsb3dpbmcgdGhlIHByb2Nl ZHVyZXMgaW4gPGEgY2xhc3M9J2luZm8nIGhyZWY9JyN0eXBlLXJlZ2lzdHJ5Jz5TZWN0aW9uJm5i c3A7MTEuMTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5UaGUgT0F1dGggQWNjZXNz IFRva2VuIFR5cGUgUmVnaXN0cnk8L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+KSwgb3IgYnkgdXNp bmcgYQogICAgICAgICAgdW5pcXVlIGFic29sdXRlIFVSSSBhcyBpdHMgbmFtZS4KICAgICAgICAK PC9wPgo8cD4KICAgICAgICAgIFR5cGVzIHV0aWxpemluZyBhIFVSSSBuYW1lIFNIT1VMRCBiZSBs aW1pdGVkIHRvIHZlbmRvci1zcGVjaWZpYyBpbXBsZW1lbnRhdGlvbnMgdGhhdCBhcmUKICAgICAg ICAgIG5vdCBjb21tb25seSBhcHBsaWNhYmxlLCBhbmQgYXJlIHNwZWNpZmljIHRvIHRoZSBpbXBs ZW1lbnRhdGlvbiBkZXRhaWxzIG9mIHRoZSByZXNvdXJjZQogICAgICAgICAgc2VydmVyIHdoZXJl IHRoZXkgYXJlIHVzZWQuCiAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICBBbGwgb3RoZXIgdHlw ZXMgTVVTVCBiZSByZWdpc3RlcmVkLiBUeXBlIG5hbWVzIE1VU1QgY29uZm9ybSB0byB0aGUgdHlw ZS1uYW1lIEFCTkYuIElmIHRoZQogICAgICAgICAgdHlwZSBkZWZpbml0aW9uIGluY2x1ZGVzIGEg bmV3IEhUVFAgYXV0aGVudGljYXRpb24gc2NoZW1lLCB0aGUgdHlwZSBuYW1lIFNIT1VMRCBiZQog ICAgICAgICAgaWRlbnRpY2FsIHRvIHRoZSBIVFRQIGF1dGhlbnRpY2F0aW9uIHNjaGVtZSBuYW1l IChhcyBkZWZpbmVkIGJ5IDxhIGNsYXNzPSdpbmZvJyBocmVmPScjUkZDMjYxNyc+W1JGQzI2MTdd PHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkZyYW5rcywgSi4sIEhhbGxhbS1CYWtl ciwgUC4sIEhvc3RldGxlciwgSi4sIExhd3JlbmNlLCBTLiwgTGVhY2gsIFAuLCBMdW90b25lbiwg QS4sIGFuZCBMLiBTdGV3YXJ0LCAmbGRxdW87SFRUUCBBdXRoZW50aWNhdGlvbjogQmFzaWMgYW5k IERpZ2VzdCBBY2Nlc3MgQXV0aGVudGljYXRpb24sJnJkcXVvOyBKdW5lJm5ic3A7MTk5OS48L3Nw YW4+PHNwYW4+KTwvc3Bhbj48L2E+KS4KICAgICAgICAgIFRoZSB0b2tlbiB0eXBlIDx0dD5leGFt cGxlPC90dD4gaXMgcmVzZXJ2ZWQgZm9yIHVzZSBpbiBleGFtcGxlcy4KICAgICAgICAKPC9wPjxk aXYgc3R5bGU9J2Rpc3BsYXk6IHRhYmxlOyB3aWR0aDogMDsgbWFyZ2luLWxlZnQ6IDNlbTsgbWFy Z2luLXJpZ2h0OiBhdXRvJz48cHJlPgoKICB0eXBlLW5hbWUgID0gMSpuYW1lLWNoYXIKICBuYW1l LWNoYXIgID0gIi0iIC8gIi4iIC8gIl8iIC8gRElHSVQgLyBBTFBIQQoKPC9wcmU+PC9kaXY+Cjxh IG5hbWU9ImVuZHBvaW50LXBhcmFtcyI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0i bGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFs aWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtU T0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLjguMiI+ PC9hPjxoMz44LjIuJm5ic3A7CkRlZmluaW5nIE5ldyBFbmRwb2ludCBQYXJhbWV0ZXJzPC9oMz4K CjxwPgogICAgICAgICAgTmV3IHJlcXVlc3Qgb3IgcmVzcG9uc2UgcGFyYW1ldGVycyBmb3IgdXNl IHdpdGggdGhlIGF1dGhvcml6YXRpb24gZW5kcG9pbnQgb3IgdGhlIHRva2VuCiAgICAgICAgICBl bmRwb2ludCBhcmUgZGVmaW5lZCBhbmQgcmVnaXN0ZXJlZCBpbiB0aGUgcGFyYW1ldGVycyByZWdp c3RyeSBmb2xsb3dpbmcgdGhlIHByb2NlZHVyZSBpbgogICAgICAgICAgPGEgY2xhc3M9J2luZm8n IGhyZWY9JyNwYXJhbWV0ZXJzLXJlZ2lzdHJ5Jz5TZWN0aW9uJm5ic3A7MTEuMjxzcGFuPiAoPC9z cGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5UaGUgT0F1dGggUGFyYW1ldGVycyBSZWdpc3RyeTwvc3Bh bj48c3Bhbj4pPC9zcGFuPjwvYT4uCiAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICBQYXJhbWV0 ZXIgbmFtZXMgTVVTVCBjb25mb3JtIHRvIHRoZSBwYXJhbS1uYW1lIEFCTkYgYW5kIHBhcmFtZXRl ciB2YWx1ZXMgc3ludGF4IE1VU1QgYmUKICAgICAgICAgIHdlbGwtZGVmaW5lZCAoZS5nLiwgdXNp bmcgQUJORiwgb3IgYSByZWZlcmVuY2UgdG8gdGhlIHN5bnRheCBvZiBhbiBleGlzdGluZyBwYXJh bWV0ZXIpLgogICAgICAgIAo8L3A+PGRpdiBzdHlsZT0nZGlzcGxheTogdGFibGU7IHdpZHRoOiAw OyBtYXJnaW4tbGVmdDogM2VtOyBtYXJnaW4tcmlnaHQ6IGF1dG8nPjxwcmU+CgogIHBhcmFtLW5h bWUgID0gMSpuYW1lLWNoYXIKICBuYW1lLWNoYXIgICA9ICItIiAvICIuIiAvICJfIiAvIERJR0lU IC8gQUxQSEEKCjwvcHJlPjwvZGl2Pgo8cD4KICAgICAgICAgIFVucmVnaXN0ZXJlZCB2ZW5kb3It c3BlY2lmaWMgcGFyYW1ldGVyIGV4dGVuc2lvbnMgdGhhdCBhcmUgbm90IGNvbW1vbmx5IGFwcGxp Y2FibGUsIGFuZAogICAgICAgICAgYXJlIHNwZWNpZmljIHRvIHRoZSBpbXBsZW1lbnRhdGlvbiBk ZXRhaWxzIG9mIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciB3aGVyZSB0aGV5IGFyZQogICAgICAg ICAgdXNlZCBTSE9VTEQgdXRpbGl6ZSBhIHZlbmRvci1zcGVjaWZpYyBwcmVmaXggdGhhdCBpcyBu b3QgbGlrZWx5IHRvIGNvbmZsaWN0IHdpdGggb3RoZXIKICAgICAgICAgIHJlZ2lzdGVyZWQgdmFs dWVzIChlLmcuIGJlZ2luIHdpdGggJ2NvbXBhbnluYW1lXycpLgogICAgICAgIAo8L3A+CjxhIG5h bWU9ImFuY2hvcjMxIj48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNl bGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0 Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwv YT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uOC4zIj48L2E+PGgzPjgu My4mbmJzcDsKRGVmaW5pbmcgTmV3IEF1dGhvcml6YXRpb24gR3JhbnQgVHlwZXM8L2gzPgoKPHA+ CiAgICAgICAgICBOZXcgYXV0aG9yaXphdGlvbiBncmFudCB0eXBlcyBjYW4gYmUgZGVmaW5lZCBi eSBhc3NpZ25pbmcgdGhlbSBhIHVuaXF1ZSBhYnNvbHV0ZSBVUkkgZm9yCiAgICAgICAgICB1c2Ug d2l0aCB0aGUgPHR0PmdyYW50X3R5cGU8L3R0PiBwYXJhbWV0ZXIuIElmIHRoZSBleHRlbnNpb24g Z3JhbnQKICAgICAgICAgIHR5cGUgcmVxdWlyZXMgYWRkaXRpb25hbCB0b2tlbiBlbmRwb2ludCBw YXJhbWV0ZXJzLCB0aGV5IE1VU1QgYmUgcmVnaXN0ZXJlZCBpbiB0aGUgT0F1dGgKICAgICAgICAg IHBhcmFtZXRlcnMgcmVnaXN0cnkgYXMgZGVzY3JpYmVkIGJ5IDxhIGNsYXNzPSdpbmZvJyBocmVm PScjcGFyYW1ldGVycy1yZWdpc3RyeSc+U2VjdGlvbiZuYnNwOzExLjI8c3Bhbj4gKDwvc3Bhbj48 c3BhbiBjbGFzcz0naW5mbyc+VGhlIE9BdXRoIFBhcmFtZXRlcnMgUmVnaXN0cnk8L3NwYW4+PHNw YW4+KTwvc3Bhbj48L2E+LgogICAgICAgIAo8L3A+CjxhIG5hbWU9InJlc3BvbnNlLXR5cGUtZXh0 Ij48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIw IiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNs YXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+ PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uOC40Ij48L2E+PGgzPjguNC4mbmJzcDsKRGVm aW5pbmcgTmV3IEF1dGhvcml6YXRpb24gRW5kcG9pbnQgUmVzcG9uc2UgVHlwZXM8L2gzPgoKPHA+ CiAgICAgICAgICBOZXcgcmVzcG9uc2UgdHlwZXMgZm9yIHVzZSB3aXRoIHRoZSBhdXRob3JpemF0 aW9uIGVuZHBvaW50IGFyZSBkZWZpbmVkIGFuZCByZWdpc3RlcmVkIGluCiAgICAgICAgICB0aGUg YXV0aG9yaXphdGlvbiBlbmRwb2ludCByZXNwb25zZSB0eXBlIHJlZ2lzdHJ5IGZvbGxvd2luZyB0 aGUgcHJvY2VkdXJlIGluCiAgICAgICAgICA8YSBjbGFzcz0naW5mbycgaHJlZj0nI3Jlc3BvbnNl LXR5cGUtcmVnaXN0cnknPlNlY3Rpb24mbmJzcDsxMS4zPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xh c3M9J2luZm8nPlRoZSBPQXV0aCBBdXRob3JpemF0aW9uIEVuZHBvaW50IFJlc3BvbnNlIFR5cGUg UmVnaXN0cnk8L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+LiBSZXNwb25zZSB0eXBlIG5hbWVzIE1V U1QgY29uZm9ybSB0byB0aGUKICAgICAgICAgIHJlc3BvbnNlLXR5cGUgQUJORi4KICAgICAgICAK PC9wPjxkaXYgc3R5bGU9J2Rpc3BsYXk6IHRhYmxlOyB3aWR0aDogMDsgbWFyZ2luLWxlZnQ6IDNl bTsgbWFyZ2luLXJpZ2h0OiBhdXRvJz48cHJlPgoKICByZXNwb25zZS10eXBlICA9IHJlc3BvbnNl LW5hbWUgKiggU1AgcmVzcG9uc2UtbmFtZSApCiAgcmVzcG9uc2UtbmFtZSAgPSAxKnJlc3BvbnNl LWNoYXIKICByZXNwb25zZS1jaGFyICA9ICJfIiAvIERJR0lUIC8gQUxQSEEKCjwvcHJlPjwvZGl2 Pgo8cD4KICAgICAgICAgIElmIGEgcmVzcG9uc2UgdHlwZSBjb250YWlucyBvbmUgb3IgbW9yZSBz cGFjZSBjaGFyYWN0ZXJzICgleDIwKSwgaXQgaXMgY29tcGFyZWQgYXMgYQogICAgICAgICAgc3Bh Y2UtZGVsaW1pdGVkIGxpc3Qgb2YgdmFsdWVzIGluIHdoaWNoIHRoZSBvcmRlciBvZiB2YWx1ZXMg ZG9lcyBub3QgbWF0dGVyLiBPbmx5IG9uZQogICAgICAgICAgb3JkZXIgb2YgdmFsdWVzIGNhbiBi ZSByZWdpc3RlcmVkLCB3aGljaCBjb3ZlcnMgYWxsIG90aGVyIGFycmFuZ2VtZW50cyBvZiB0aGUg c2FtZSBzZXQgb2YKICAgICAgICAgIHZhbHVlcy4KICAgICAgICAKPC9wPgo8cD4KICAgICAgICAg IEZvciBleGFtcGxlLCB0aGUgcmVzcG9uc2UgdHlwZSA8dHQ+dG9rZW4gY29kZTwvdHQ+IGlzIGxl ZnQgdW5kZWZpbmVkCiAgICAgICAgICBieSB0aGlzIHNwZWNpZmljYXRpb24uIEhvd2V2ZXIsIGFu IGV4dGVuc2lvbiBjYW4gZGVmaW5lIGFuZCByZWdpc3RlciB0aGUKICAgICAgICAgIDx0dD50b2tl biBjb2RlPC90dD4gcmVzcG9uc2UgdHlwZS4gT25jZSByZWdpc3RlcmVkLCB0aGUgc2FtZQogICAg ICAgICAgY29tYmluYXRpb24gY2Fubm90IGJlIHJlZ2lzdGVyZWQgYXMgPHR0PmNvZGUgdG9rZW48 L3R0PiwgYnV0IGJvdGgKICAgICAgICAgIHZhbHVlcyBjYW4gYmUgdXNlZCB0byBkZW5vdGUgdGhl IHNhbWUgcmVzcG9uc2UgdHlwZS4KICAgICAgICAKPC9wPgo8YSBuYW1lPSJuZXctZXJyb3JzIj48 L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBj ZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNz PSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90 YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uOC41Ij48L2E+PGgzPjguNS4mbmJzcDsKRGVmaW5p bmcgQWRkaXRpb25hbCBFcnJvciBDb2RlczwvaDM+Cgo8cD4KICAgICAgICAgIEluIGNhc2VzIHdo ZXJlIHByb3RvY29sIGV4dGVuc2lvbnMgKGkuZS4gYWNjZXNzIHRva2VuIHR5cGVzLCBleHRlbnNp b24gcGFyYW1ldGVycywgb3IKICAgICAgICAgIGV4dGVuc2lvbiBncmFudCB0eXBlcykgcmVxdWly ZSBhZGRpdGlvbmFsIGVycm9yIGNvZGVzIHRvIGJlIHVzZWQgd2l0aCB0aGUgYXV0aG9yaXphdGlv bgogICAgICAgICAgY29kZSBncmFudCBlcnJvciByZXNwb25zZSAoPGEgY2xhc3M9J2luZm8nIGhy ZWY9JyNjb2RlLWF1dGh6LWVycm9yJz5TZWN0aW9uJm5ic3A7NC4xLjIuMTxzcGFuPiAoPC9zcGFu PjxzcGFuIGNsYXNzPSdpbmZvJz5FcnJvciBSZXNwb25zZTwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwv YT4pLCB0aGUgaW1wbGljaXQgZ3JhbnQgZXJyb3IKICAgICAgICAgIHJlc3BvbnNlICg8YSBjbGFz cz0naW5mbycgaHJlZj0nI2ltcGxpY2l0LWF1dGh6LWVycm9yJz5TZWN0aW9uJm5ic3A7NC4yLjIu MTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5FcnJvciBSZXNwb25zZTwvc3Bhbj48 c3Bhbj4pPC9zcGFuPjwvYT4pLCB0aGUgdG9rZW4gZXJyb3IgcmVzcG9uc2UKICAgICAgICAgICg8 YSBjbGFzcz0naW5mbycgaHJlZj0nI3Rva2VuLWVycm9ycyc+U2VjdGlvbiZuYnNwOzUuMjxzcGFu PiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5FcnJvciBSZXNwb25zZTwvc3Bhbj48c3Bhbj4p PC9zcGFuPjwvYT4pLAoJICBvciB0aGUgcmVzb3VyY2UgYWNjZXNzIGVycm9yIHJlc3BvbnNlICg8 YSBjbGFzcz0naW5mbycgaHJlZj0nI3Jlc291cmNlLWVycm9ycyc+U2VjdGlvbiZuYnNwOzcuMjxz cGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5FcnJvciBSZXNwb25zZTwvc3Bhbj48c3Bh bj4pPC9zcGFuPjwvYT4pLAoJICBzdWNoIGVycm9yIGNvZGVzIE1BWSBiZSBkZWZpbmVkLgogICAg ICAgIAo8L3A+CjxwPgogICAgICAgICAgRXh0ZW5zaW9uIGVycm9yIGNvZGVzIE1VU1QgYmUgcmVn aXN0ZXJlZCAoZm9sbG93aW5nIHRoZSBwcm9jZWR1cmVzIGluCiAgICAgICAgICA8YSBjbGFzcz0n aW5mbycgaHJlZj0nI2Vycm9yLXJlZ2lzdHJ5Jz5TZWN0aW9uJm5ic3A7MTEuNDxzcGFuPiAoPC9z cGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5UaGUgT0F1dGggRXh0ZW5zaW9ucyBFcnJvciBSZWdpc3Ry eTwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4pIGlmIHRoZSBleHRlbnNpb24gdGhleSBhcmUgdXNl ZCBpbiBjb25qdW5jdGlvbiB3aXRoIGlzCiAgICAgICAgICBhIHJlZ2lzdGVyZWQgYWNjZXNzIHRv a2VuIHR5cGUsIGEgcmVnaXN0ZXJlZCBlbmRwb2ludCBwYXJhbWV0ZXIsIG9yIGFuIGV4dGVuc2lv biBncmFudAogICAgICAgICAgdHlwZS4gRXJyb3IgY29kZXMgdXNlZCB3aXRoIHVucmVnaXN0ZXJl ZCBleHRlbnNpb25zIE1BWSBiZSByZWdpc3RlcmVkLgogICAgICAgIAo8L3A+CjxwPgogICAgICAg ICAgRXJyb3IgY29kZXMgTVVTVCBjb25mb3JtIHRvIHRoZSBlcnJvciBBQk5GLCBhbmQgU0hPVUxE IGJlIHByZWZpeGVkIGJ5IGFuIGlkZW50aWZ5aW5nCiAgICAgICAgICBuYW1lIHdoZW4gcG9zc2li bGUuIEZvciBleGFtcGxlLCBhbiBlcnJvciBpZGVudGlmeWluZyBhbiBpbnZhbGlkIHZhbHVlIHNl dCB0byB0aGUKICAgICAgICAgIGV4dGVuc2lvbiBwYXJhbWV0ZXIgPHR0PmV4YW1wbGU8L3R0PiBT SE9VTEQgYmUgbmFtZWQKICAgICAgICAgIDx0dD5leGFtcGxlX2ludmFsaWQ8L3R0Pi4KICAgICAg ICAKPC9wPjxkaXYgc3R5bGU9J2Rpc3BsYXk6IHRhYmxlOyB3aWR0aDogMDsgbWFyZ2luLWxlZnQ6 IDNlbTsgbWFyZ2luLXJpZ2h0OiBhdXRvJz48cHJlPgoKICBlcnJvciAgICAgID0gMSplcnJvci1j aGFyCiAgZXJyb3ItY2hhciA9ICV4MjAtMjEgLyAleDIzLTVCIC8gJXg1RC03RQoKPC9wcmU+PC9k aXY+CjxhIG5hbWU9ImFuY2hvcjMyIj48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJs YXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxp Z249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RP QyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uOSI+PC9h PjxoMz45LiZuYnNwOwpOYXRpdmUgQXBwbGljYXRpb25zPC9oMz4KCjxwPgogICAgICAgIE5hdGl2 ZSBhcHBsaWNhdGlvbnMgYXJlIGNsaWVudHMgaW5zdGFsbGVkIGFuZCBleGVjdXRlZCBvbiB0aGUg ZGV2aWNlIHVzZWQgYnkgdGhlIHJlc291cmNlCiAgICAgICAgb3duZXIgKGkuZS4gZGVza3RvcCBh cHBsaWNhdGlvbiwgbmF0aXZlIG1vYmlsZSBhcHBsaWNhdGlvbikuIE5hdGl2ZSBhcHBsaWNhdGlv bnMgcmVxdWlyZQogICAgICAgIHNwZWNpYWwgY29uc2lkZXJhdGlvbiByZWxhdGVkIHRvIHNlY3Vy aXR5LCBwbGF0Zm9ybSBjYXBhYmlsaXRpZXMsIGFuZCBvdmVyYWxsIGVuZC11c2VyCiAgICAgICAg ZXhwZXJpZW5jZS4KICAgICAgCjwvcD4KPHA+CiAgICAgICAgVGhlIGF1dGhvcml6YXRpb24gZW5k cG9pbnQgcmVxdWlyZXMgaW50ZXJhY3Rpb24gYmV0d2VlbiB0aGUgY2xpZW50IGFuZCB0aGUgcmVz b3VyY2UKICAgICAgICBvd25lcidzIHVzZXItYWdlbnQuIE5hdGl2ZSBhcHBsaWNhdGlvbnMgY2Fu IGludm9rZSBhbiBleHRlcm5hbCB1c2VyLWFnZW50IG9yIGVtYmVkIGEKICAgICAgICB1c2VyLWFn ZW50IHdpdGhpbiB0aGUgYXBwbGljYXRpb24uIEZvciBleGFtcGxlOgogICAgICAKPC9wPgo8cD4K ICAgICAgICA8L3A+Cjx1bCBjbGFzcz0idGV4dCI+CjxsaT4KICAgICAgICAgICAgRXh0ZXJuYWwg dXNlci1hZ2VudCAtIHRoZSBuYXRpdmUgYXBwbGljYXRpb24gY2FuIGNhcHR1cmUgdGhlIHJlc3Bv bnNlIGZyb20gdGhlCiAgICAgICAgICAgIGF1dGhvcml6YXRpb24gc2VydmVyIHVzaW5nIGEgcmVk aXJlY3Rpb24gVVJJIHdpdGggYSBzY2hlbWUgcmVnaXN0ZXJlZCB3aXRoIHRoZQogICAgICAgICAg ICBvcGVyYXRpbmcgc3lzdGVtIHRvIGludm9rZSB0aGUgY2xpZW50IGFzIHRoZSBoYW5kbGVyLCBt YW51YWwgY29weS1hbmQtcGFzdGUgb2YgdGhlCiAgICAgICAgICAgIGNyZWRlbnRpYWxzLCBydW5u aW5nIGEgbG9jYWwgd2ViIHNlcnZlciwgaW5zdGFsbGluZyBhIHVzZXItYWdlbnQgZXh0ZW5zaW9u LCBvciBieQogICAgICAgICAgICBwcm92aWRpbmcgYSByZWRpcmVjdGlvbiBVUkkgaWRlbnRpZnlp bmcgYSBzZXJ2ZXItaG9zdGVkIHJlc291cmNlIHVuZGVyIHRoZSBjbGllbnQncwogICAgICAgICAg ICBjb250cm9sLCB3aGljaCBpbiB0dXJuIG1ha2VzIHRoZSByZXNwb25zZSBhdmFpbGFibGUgdG8g dGhlIG5hdGl2ZSBhcHBsaWNhdGlvbi4KICAgICAgICAgIAo8L2xpPgo8bGk+CiAgICAgICAgICAg IEVtYmVkZGVkIHVzZXItYWdlbnQgLSB0aGUgbmF0aXZlIGFwcGxpY2F0aW9uIG9idGFpbnMgdGhl IHJlc3BvbnNlIGJ5IGRpcmVjdGx5CiAgICAgICAgICAgIGNvbW11bmljYXRpbmcgd2l0aCB0aGUg ZW1iZWRkZWQgdXNlci1hZ2VudCBieSBtb25pdG9yaW5nIHN0YXRlIGNoYW5nZXMgZW1pdHRlZCBk dXJpbmcKICAgICAgICAgICAgdGhlIHJlc291cmNlIGxvYWQsIG9yIGFjY2Vzc2luZyB0aGUgdXNl ci1hZ2VudCdzIGNvb2tpZXMgc3RvcmFnZS4KICAgICAgICAgIAo8L2xpPgo8L3VsPjxwPgogICAg ICAKPC9wPgo8cD4KICAgICAgICBXaGVuIGNob29zaW5nIGJldHdlZW4gYW4gZXh0ZXJuYWwgb3Ig ZW1iZWRkZWQgdXNlci1hZ2VudCwgZGV2ZWxvcGVycyBzaG91bGQgY29uc2lkZXI6CiAgICAgIAo8 L3A+CjxwPgogICAgICAgIDwvcD4KPHVsIGNsYXNzPSJ0ZXh0Ij4KPGxpPgogICAgICAgICAgICBB biBFeHRlcm5hbCB1c2VyLWFnZW50IG1heSBpbXByb3ZlIGNvbXBsZXRpb24gcmF0ZSBhcyB0aGUg cmVzb3VyY2Ugb3duZXIgbWF5IGFscmVhZHkgaGF2ZQogICAgICAgICAgICBhbiBhY3RpdmUgc2Vz c2lvbiB3aXRoIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciByZW1vdmluZyB0aGUgbmVlZCB0byBy ZS1hdXRoZW50aWNhdGUuIEl0CiAgICAgICAgICAgIHByb3ZpZGVzIGEgZmFtaWxpYXIgZW5kLXVz ZXIgZXhwZXJpZW5jZSBhbmQgZnVuY3Rpb25hbGl0eS4gVGhlIHJlc291cmNlIG93bmVyIG1heSBh bHNvCiAgICAgICAgICAgIHJlbHkgb24gdXNlci1hZ2VudCBmZWF0dXJlcyBvciBleHRlbnNpb25z IHRvIGFzc2lzdCB3aXRoIGF1dGhlbnRpY2F0aW9uIChlLmcuIHBhc3N3b3JkCiAgICAgICAgICAg IG1hbmFnZXIsIDItZmFjdG9yIGRldmljZSByZWFkZXIpLgogICAgICAgICAgCjwvbGk+CjxsaT4K ICAgICAgICAgICAgQW4gZW1iZWRkZWQgdXNlci1hZ2VudCBtYXkgb2ZmZXIgaW1wcm92ZWQgdXNh YmlsaXR5LCBhcyBpdCByZW1vdmVzIHRoZSBuZWVkIHRvIHN3aXRjaAogICAgICAgICAgICBjb250 ZXh0IGFuZCBvcGVuIG5ldyB3aW5kb3dzLgogICAgICAgICAgCjwvbGk+CjxsaT4KICAgICAgICAg ICAgQW4gZW1iZWRkZWQgdXNlci1hZ2VudCBwb3NlcyBhIHNlY3VyaXR5IGNoYWxsZW5nZSBiZWNh dXNlIHJlc291cmNlIG93bmVycyBhcmUKICAgICAgICAgICAgYXV0aGVudGljYXRpbmcgaW4gYW4g dW5pZGVudGlmaWVkIHdpbmRvdyB3aXRob3V0IGFjY2VzcyB0byB0aGUgdmlzdWFsIHByb3RlY3Rp b25zIGZvdW5kCiAgICAgICAgICAgIGluIG1vc3QgZXh0ZXJuYWwgdXNlci1hZ2VudHMuIEFuIGVt YmVkZGVkIHVzZXItYWdlbnQgZWR1Y2F0ZXMgZW5kLXVzZXJzIHRvIHRydXN0CiAgICAgICAgICAg IHVuaWRlbnRpZmllZCByZXF1ZXN0cyBmb3IgYXV0aGVudGljYXRpb24gKG1ha2luZyBwaGlzaGlu ZyBhdHRhY2tzIGVhc2llciB0byBleGVjdXRlKS4KICAgICAgICAgIAo8L2xpPgo8L3VsPjxwPgog ICAgICAKPC9wPgo8cD4KICAgICAgICBXaGVuIGNob29zaW5nIGJldHdlZW4gdGhlIGltcGxpY2l0 IGdyYW50IHR5cGUgYW5kIHRoZSBhdXRob3JpemF0aW9uIGNvZGUgZ3JhbnQgdHlwZSwgdGhlCiAg ICAgICAgZm9sbG93aW5nIHNob3VsZCBiZSBjb25zaWRlcmVkOgogICAgICAKPC9wPgo8cD4KICAg ICAgICA8L3A+Cjx1bCBjbGFzcz0idGV4dCI+CjxsaT4KICAgICAgICAgICAgTmF0aXZlIGFwcGxp Y2F0aW9ucyB0aGF0IHVzZSB0aGUgYXV0aG9yaXphdGlvbiBjb2RlIGdyYW50IHR5cGUgU0hPVUxE IGRvIHNvIHdpdGhvdXQKICAgICAgICAgICAgdXNpbmcgY2xpZW50IGNyZWRlbnRpYWxzLCBkdWUg dG8gdGhlIG5hdGl2ZSBhcHBsaWNhdGlvbidzIGluYWJpbGl0eSB0byBrZWVwIGNsaWVudAogICAg ICAgICAgICBjcmVkZW50aWFscyBjb25maWRlbnRpYWwuCiAgICAgICAgICAKPC9saT4KPGxpPgog ICAgICAgICAgICBXaGVuIHVzaW5nIHRoZSBpbXBsaWNpdCBncmFudCB0eXBlIGZsb3cgYSByZWZy ZXNoIHRva2VuIGlzIG5vdCByZXR1cm5lZCB3aGljaCByZXF1aXJlcwogICAgICAgICAgICByZXBl YXRpbmcgdGhlIGF1dGhvcml6YXRpb24gcHJvY2VzcyBvbmNlIHRoZSBhY2Nlc3MgdG9rZW4gZXhw aXJlcy4KICAgICAgICAgIAo8L2xpPgo8L3VsPjxwPgogICAgICAKPC9wPgo8YSBuYW1lPSJhbmNo b3IzMyI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGlu Zz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0 ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48 L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLjEwIj48L2E+PGgzPjEwLiZuYnNwOwpT ZWN1cml0eSBDb25zaWRlcmF0aW9uczwvaDM+Cgo8cD4KICAgICAgICBBcyBhIGZsZXhpYmxlIGFu ZCBleHRlbnNpYmxlIGZyYW1ld29yaywgT0F1dGgncyBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBk ZXBlbmQgb24gbWFueQogICAgICAgIGZhY3RvcnMuIFRoZSBmb2xsb3dpbmcgc2VjdGlvbnMgcHJv dmlkZSBpbXBsZW1lbnRlcnMgd2l0aCBzZWN1cml0eSBndWlkZWxpbmVzIGZvY3VzZWQgb24KICAg ICAgICB0aGUgdGhyZWUgY2xpZW50IHByb2ZpbGVzIGRlc2NyaWJlZCBpbiA8YSBjbGFzcz0naW5m bycgaHJlZj0nI2NsaWVudC10eXBlcyc+U2VjdGlvbiZuYnNwOzIuMTxzcGFuPiAoPC9zcGFuPjxz cGFuIGNsYXNzPSdpbmZvJz5DbGllbnQgVHlwZXM8L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+OiB3 ZWIgYXBwbGljYXRpb24sCiAgICAgICAgdXNlci1hZ2VudC1iYXNlZCBhcHBsaWNhdGlvbiwgYW5k IG5hdGl2ZSBhcHBsaWNhdGlvbi4KICAgICAgCjwvcD4KPHA+CiAgICAgICAgQSBjb21wcmVoZW5z aXZlIE9BdXRoIHNlY3VyaXR5IG1vZGVsIGFuZCBhbmFseXNpcywgYXMgd2VsbCBhcyBiYWNrZ3Jv dW5kIGZvciB0aGUgcHJvdG9jb2wKICAgICAgICBkZXNpZ24gaXMgcHJvdmlkZWQgYnkgPGEgY2xh c3M9J2luZm8nIGhyZWY9JyNJLUQuaWV0Zi1vYXV0aC12Mi10aHJlYXRtb2RlbCc+W0kmIzgyMDk7 RC5pZXRmJiM4MjA5O29hdXRoJiM4MjA5O3YyJiM4MjA5O3RocmVhdG1vZGVsXTxzcGFuPiAoPC9z cGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5NY0dsb2luLCBNLiwgSHVudCwgUC4sIGFuZCBULiBMb2Rk ZXJzdGVkdCwgJmxkcXVvO09BdXRoIDIuMCBUaHJlYXQgTW9kZWwgYW5kIFNlY3VyaXR5IENvbnNp ZGVyYXRpb25zLCZyZHF1bzsgRmVicnVhcnkmbmJzcDsyMDEyLjwvc3Bhbj48c3Bhbj4pPC9zcGFu PjwvYT4uCiAgICAgIAo8L3A+CjxhIG5hbWU9ImFuY2hvcjM0Ij48L2E+PGJyIC8+PGhyIC8+Cjx0 YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xh c3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9 IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZj LnNlY3Rpb24uMTAuMSI+PC9hPjxoMz4xMC4xLiZuYnNwOwpDbGllbnQgQXV0aGVudGljYXRpb248 L2gzPgoKPHA+CiAgICAgICAgICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgZXN0YWJsaXNoZXMg Y2xpZW50IGNyZWRlbnRpYWxzIHdpdGggd2ViIGFwcGxpY2F0aW9uIGNsaWVudHMgZm9yCiAgICAg ICAgICB0aGUgcHVycG9zZSBvZiBjbGllbnQgYXV0aGVudGljYXRpb24uIFRoZSBhdXRob3JpemF0 aW9uIHNlcnZlciBpcyBlbmNvdXJhZ2VkIHRvIGNvbnNpZGVyCiAgICAgICAgICBzdHJvbmdlciBj bGllbnQgYXV0aGVudGljYXRpb24gbWVhbnMgdGhhbiBhIGNsaWVudCBwYXNzd29yZC4gV2ViIGFw cGxpY2F0aW9uIGNsaWVudHMgTVVTVAogICAgICAgICAgZW5zdXJlIGNvbmZpZGVudGlhbGl0eSBv ZiBjbGllbnQgcGFzc3dvcmRzIGFuZCBvdGhlciBjbGllbnQgY3JlZGVudGlhbHMuCiAgICAgICAg CjwvcD4KPHA+CiAgICAgICAgICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVTVCBOT1QgaXNz dWUgY2xpZW50IHBhc3N3b3JkcyBvciBvdGhlciBjbGllbnQgY3JlZGVudGlhbHMgdG8KICAgICAg ICAgIG5hdGl2ZSBhcHBsaWNhdGlvbiBvciB1c2VyLWFnZW50LWJhc2VkIGFwcGxpY2F0aW9uIGNs aWVudHMgZm9yIHRoZSBwdXJwb3NlIG9mIGNsaWVudAogICAgICAgICAgYXV0aGVudGljYXRpb24u IFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBNQVkgaXNzdWUgYSBjbGllbnQgcGFzc3dvcmQgb3Ig b3RoZXIgY3JlZGVudGlhbHMKICAgICAgICAgIGZvciBhIHNwZWNpZmljIGluc3RhbGxhdGlvbiBv ZiBhIG5hdGl2ZSBhcHBsaWNhdGlvbiBjbGllbnQgb24gYSBzcGVjaWZpYyBkZXZpY2UuCiAgICAg ICAgCjwvcD4KPHA+CiAgICAgICAgICBXaGVuIGNsaWVudCBhdXRoZW50aWNhdGlvbiBpcyBub3Qg cG9zc2libGUsIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBTSE9VTEQgZW1wbG95IG90aGVyCiAg ICAgICAgICBtZWFucyB0byB2YWxpZGF0ZSB0aGUgY2xpZW50J3MgaWRlbnRpdHkuIEZvciBleGFt cGxlLCBieSByZXF1aXJpbmcgdGhlIHJlZ2lzdHJhdGlvbiBvZgogICAgICAgICAgdGhlIGNsaWVu dCByZWRpcmVjdGlvbiBVUkkgb3IgZW5saXN0aW5nIHRoZSByZXNvdXJjZSBvd25lciB0byBjb25m aXJtIGlkZW50aXR5LiBBIHZhbGlkCiAgICAgICAgICByZWRpcmVjdGlvbiBVUkkgaXMgbm90IHN1 ZmZpY2llbnQgdG8gdmVyaWZ5IHRoZSBjbGllbnQncyBpZGVudGl0eSB3aGVuIGFza2luZyBmb3IK ICAgICAgICAgIHJlc291cmNlIG93bmVyIGF1dGhvcml6YXRpb24sIGJ1dCBjYW4gYmUgdXNlZCB0 byBwcmV2ZW50IGRlbGl2ZXJpbmcgY3JlZGVudGlhbHMgdG8gYQogICAgICAgICAgY291bnRlcmZl aXQgY2xpZW50IGFmdGVyIG9idGFpbmluZyByZXNvdXJjZSBvd25lciBhdXRob3JpemF0aW9uLgog ICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIG11c3Qg Y29uc2lkZXIgdGhlIHNlY3VyaXR5IGltcGxpY2F0aW9ucyBvZiBpbnRlcmFjdGluZyB3aXRoCiAg ICAgICAgICB1bmF1dGhlbnRpY2F0ZWQgY2xpZW50cyBhbmQgdGFrZSBtZWFzdXJlcyB0byBsaW1p dCB0aGUgcG90ZW50aWFsIGV4cG9zdXJlIG9mIG90aGVyCiAgICAgICAgICBjcmVkZW50aWFscyAo ZS5nLiByZWZyZXNoIHRva2VucykgaXNzdWVkIHRvIHN1Y2ggY2xpZW50cy4KICAgICAgICAKPC9w Pgo8YSBuYW1lPSJhbmNob3IzNSI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5 b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWdu PSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0Mm bmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLjEwLjIiPjwv YT48aDM+MTAuMi4mbmJzcDsKQ2xpZW50IEltcGVyc29uYXRpb248L2gzPgoKPHA+CiAgICAgICAg ICBBIG1hbGljaW91cyBjbGllbnQgY2FuIGltcGVyc29uYXRlIGFub3RoZXIgY2xpZW50IGFuZCBv YnRhaW4gYWNjZXNzIHRvIHByb3RlY3RlZAogICAgICAgICAgcmVzb3VyY2VzLCBpZiB0aGUgaW1w ZXJzb25hdGVkIGNsaWVudCBmYWlscyB0bywgb3IgaXMgdW5hYmxlIHRvLCBrZWVwIGl0cyBjbGll bnQKICAgICAgICAgIGNyZWRlbnRpYWxzIGNvbmZpZGVudGlhbC4KICAgICAgICAKPC9wPgo8cD4K ICAgICAgICAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBNVVNUIGF1dGhlbnRpY2F0ZSB0aGUg Y2xpZW50IHdoZW5ldmVyIHBvc3NpYmxlLiBJZiB0aGUKICAgICAgICAgIGF1dGhvcml6YXRpb24g c2VydmVyIGNhbm5vdCBhdXRoZW50aWNhdGUgdGhlIGNsaWVudCBkdWUgdG8gdGhlIGNsaWVudCdz IG5hdHVyZSwgdGhlCiAgICAgICAgICBhdXRob3JpemF0aW9uIHNlcnZlciBNVVNUIHJlcXVpcmUg dGhlIHJlZ2lzdHJhdGlvbiBvZiBhbnkgcmVkaXJlY3Rpb24gVVJJIHVzZWQgZm9yCiAgICAgICAg ICByZWNlaXZpbmcgYXV0aG9yaXphdGlvbiByZXNwb25zZXMsIGFuZCBTSE9VTEQgdXRpbGl6ZSBv dGhlciBtZWFucyB0byBwcm90ZWN0IHJlc291cmNlCiAgICAgICAgICBvd25lcnMgZnJvbSBzdWNo IHBvdGVudGlhbGx5IG1hbGljaW91cyBjbGllbnRzLiBGb3IgZXhhbXBsZSwgdGhlIGF1dGhvcml6 YXRpb24gc2VydmVyCiAgICAgICAgICBjYW4gZW5nYWdlIHRoZSByZXNvdXJjZSBvd25lciB0byBh c3Npc3QgaW4gaWRlbnRpZnlpbmcgdGhlIGNsaWVudCBhbmQgaXRzIG9yaWdpbi4KICAgICAgICAK PC9wPgo8cD4KICAgICAgICAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBTSE9VTEQgZW5mb3Jj ZSBleHBsaWNpdCByZXNvdXJjZSBvd25lciBhdXRoZW50aWNhdGlvbiBhbmQKICAgICAgICAgIHBy b3ZpZGUgdGhlIHJlc291cmNlIG93bmVyIHdpdGggaW5mb3JtYXRpb24gYWJvdXQgdGhlIGNsaWVu dCBhbmQgdGhlIHJlcXVlc3RlZAogICAgICAgICAgYXV0aG9yaXphdGlvbiBzY29wZSBhbmQgbGlm ZXRpbWUuIEl0IGlzIHVwIHRvIHRoZSByZXNvdXJjZSBvd25lciB0byByZXZpZXcgdGhlCiAgICAg ICAgICBpbmZvcm1hdGlvbiBpbiB0aGUgY29udGV4dCBvZiB0aGUgY3VycmVudCBjbGllbnQsIGFu ZCBhdXRob3JpemUgb3IgZGVueSB0aGUgcmVxdWVzdC4KICAgICAgICAKPC9wPgo8cD4KICAgICAg ICAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBTSE9VTEQgTk9UIHByb2Nlc3MgcmVwZWF0ZWQg YXV0aG9yaXphdGlvbiByZXF1ZXN0cwogICAgICAgICAgYXV0b21hdGljYWxseSAod2l0aG91dCBh Y3RpdmUgcmVzb3VyY2Ugb3duZXIgaW50ZXJhY3Rpb24pIHdpdGhvdXQgYXV0aGVudGljYXRpbmcg dGhlCiAgICAgICAgICBjbGllbnQgb3IgcmVseWluZyBvbiBvdGhlciBtZWFzdXJlcyB0byBlbnN1 cmUgdGhlIHJlcGVhdGVkIHJlcXVlc3QgY29tZXMgZnJvbSB0aGUKICAgICAgICAgIG9yaWdpbmFs IGNsaWVudCBhbmQgbm90IGFuIGltcGVyc29uYXRvci4KICAgICAgICAKPC9wPgo8YSBuYW1lPSJh bmNob3IzNiI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFk ZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRy Pjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90 ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLjEwLjMiPjwvYT48aDM+MTAuMy4m bmJzcDsKQWNjZXNzIFRva2VuczwvaDM+Cgo8cD4KICAgICAgICAgIEFjY2VzcyB0b2tlbiBjcmVk ZW50aWFscyAoYXMgd2VsbCBhcyBhbnkgY29uZmlkZW50aWFsIGFjY2VzcyB0b2tlbiBhdHRyaWJ1 dGVzKSBNVVNUIGJlCiAgICAgICAgICBrZXB0IGNvbmZpZGVudGlhbCBpbiB0cmFuc2l0IGFuZCBz dG9yYWdlLCBhbmQgb25seSBzaGFyZWQgYW1vbmcgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLAog ICAgICAgICAgdGhlIHJlc291cmNlIHNlcnZlcnMgdGhlIGFjY2VzcyB0b2tlbiBpcyB2YWxpZCBm b3IsIGFuZCB0aGUgY2xpZW50IHRvIHdob20gdGhlIGFjY2VzcwogICAgICAgICAgdG9rZW4gaXMg aXNzdWVkLiBBY2Nlc3MgdG9rZW4gY3JlZGVudGlhbHMgTVVTVCBvbmx5IGJlIHRyYW5zbWl0dGVk IHVzaW5nIFRMUyBhcyBkZXNjcmliZWQKICAgICAgICAgIGluIDxhIGNsYXNzPSdpbmZvJyBocmVm PScjdGxzJz5TZWN0aW9uJm5ic3A7MS42PHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8n PlRMUyBWZXJzaW9uPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPiB3aXRoIHNlcnZlciBhdXRoZW50 aWNhdGlvbiBhcyBkZWZpbmVkIGJ5CiAgICAgICAgICA8YSBjbGFzcz0naW5mbycgaHJlZj0nI1JG QzI4MTgnPltSRkMyODE4XTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5SZXNjb3Js YSwgRS4sICZsZHF1bztIVFRQIE92ZXIgVExTLCZyZHF1bzsgTWF5Jm5ic3A7MjAwMC48L3NwYW4+ PHNwYW4+KTwvc3Bhbj48L2E+LgogICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgV2hlbiB1c2lu ZyB0aGUgaW1wbGljaXQgZ3JhbnQgdHlwZSwgdGhlIGFjY2VzcyB0b2tlbiBpcyB0cmFuc21pdHRl ZCBpbiB0aGUgVVJJIGZyYWdtZW50LAogICAgICAgICAgd2hpY2ggY2FuIGV4cG9zZSBpdCB0byB1 bmF1dGhvcml6ZWQgcGFydGllcy4KICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgIFRoZSBhdXRo b3JpemF0aW9uIHNlcnZlciBNVVNUIGVuc3VyZSB0aGF0IGFjY2VzcyB0b2tlbnMgY2Fubm90IGJl IGdlbmVyYXRlZCwgbW9kaWZpZWQsIG9yCiAgICAgICAgICBndWVzc2VkIHRvIHByb2R1Y2UgdmFs aWQgYWNjZXNzIHRva2VucyBieSB1bmF1dGhvcml6ZWQgcGFydGllcy4KICAgICAgICAKPC9wPgo8 cD4KICAgICAgICAgIFRoZSBjbGllbnQgU0hPVUxEIHJlcXVlc3QgYWNjZXNzIHRva2VucyB3aXRo IHRoZSBtaW5pbWFsIHNjb3BlIG5lY2Vzc2FyeS4gVGhlCiAgICAgICAgICBhdXRob3JpemF0aW9u IHNlcnZlciBTSE9VTEQgdGFrZSB0aGUgY2xpZW50IGlkZW50aXR5IGludG8gYWNjb3VudCB3aGVu IGNob29zaW5nIGhvdwogICAgICAgICAgdG8gaG9ub3IgdGhlIHJlcXVlc3RlZCBzY29wZSwgYW5k IE1BWSBpc3N1ZSBhbiBhY2Nlc3MgdG9rZW4gd2l0aCBhIGxlc3MgcmlnaHRzIHRoYW4KICAgICAg ICAgIHJlcXVlc3RlZC4KICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgIFRoaXMgc3BlY2lmaWNh dGlvbiBkb2VzIG5vdCBwcm92aWRlIGFueSBtZXRob2RzIGZvciB0aGUgcmVzb3VyY2Ugc2VydmVy IHRvIGVuc3VyZSB0aGF0IGFuCiAgICAgICAgICBhY2Nlc3MgdG9rZW4gcHJlc2VudGVkIHRvIGl0 IGJ5IGEgZ2l2ZW4gY2xpZW50IHdhcyBpc3N1ZWQgdG8gdGhhdCBjbGllbnQgYnkgdGhlCiAgICAg ICAgICBhdXRob3JpemF0aW9uIHNlcnZlci4KICAgICAgICAKPC9wPgo8YSBuYW1lPSJhbmNob3Iz NyI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0i MCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBj bGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3Ry PjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLjEwLjQiPjwvYT48aDM+MTAuNC4mbmJzcDsK UmVmcmVzaCBUb2tlbnM8L2gzPgoKPHA+CiAgICAgICAgICBBdXRob3JpemF0aW9uIHNlcnZlcnMg TUFZIGlzc3VlIHJlZnJlc2ggdG9rZW5zIHRvIHdlYiBhcHBsaWNhdGlvbiBjbGllbnRzIGFuZCBu YXRpdmUKICAgICAgICAgIGFwcGxpY2F0aW9uIGNsaWVudHMuCiAgICAgICAgCjwvcD4KPHA+CiAg ICAgICAgICBSZWZyZXNoIHRva2VucyBNVVNUIGJlIGtlcHQgY29uZmlkZW50aWFsIGluIHRyYW5z aXQgYW5kIHN0b3JhZ2UsIGFuZCBzaGFyZWQgb25seSBhbW9uZwogICAgICAgICAgdGhlIGF1dGhv cml6YXRpb24gc2VydmVyIGFuZCB0aGUgY2xpZW50IHRvIHdob20gdGhlIHJlZnJlc2ggdG9rZW5z IHdlcmUgaXNzdWVkLiBUaGUKICAgICAgICAgIGF1dGhvcml6YXRpb24gc2VydmVyIE1VU1QgbWFp bnRhaW4gdGhlIGJpbmRpbmcgYmV0d2VlbiBhIHJlZnJlc2ggdG9rZW4gYW5kIHRoZSBjbGllbnQg dG8KICAgICAgICAgIHdob20gaXQgd2FzIGlzc3VlZC4gUmVmcmVzaCB0b2tlbnMgTVVTVCBvbmx5 IGJlIHRyYW5zbWl0dGVkIHVzaW5nIFRMUyBhcyBkZXNjcmliZWQgaW4KICAgICAgICAgIDxhIGNs YXNzPSdpbmZvJyBocmVmPScjdGxzJz5TZWN0aW9uJm5ic3A7MS42PHNwYW4+ICg8L3NwYW4+PHNw YW4gY2xhc3M9J2luZm8nPlRMUyBWZXJzaW9uPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPiB3aXRo IHNlcnZlciBhdXRoZW50aWNhdGlvbiBhcyBkZWZpbmVkIGJ5IDxhIGNsYXNzPSdpbmZvJyBocmVm PScjUkZDMjgxOCc+W1JGQzI4MThdPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPlJl c2NvcmxhLCBFLiwgJmxkcXVvO0hUVFAgT3ZlciBUTFMsJnJkcXVvOyBNYXkmbmJzcDsyMDAwLjwv c3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4uCiAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICBUaGUg YXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVTVCB2ZXJpZnkgdGhlIGJpbmRpbmcgYmV0d2VlbiB0aGUg cmVmcmVzaCB0b2tlbiBhbmQgY2xpZW50CiAgICAgICAgICBpZGVudGl0eSB3aGVuZXZlciB0aGUg Y2xpZW50IGlkZW50aXR5IGNhbiBiZSBhdXRoZW50aWNhdGVkLiBXaGVuIGNsaWVudCBhdXRoZW50 aWNhdGlvbiBpcwogICAgICAgICAgbm90IHBvc3NpYmxlLCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2 ZXIgU0hPVUxEIGRlcGxveSBvdGhlciBtZWFucyB0byBkZXRlY3QgcmVmcmVzaCB0b2tlbgogICAg ICAgICAgYWJ1c2UuCiAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICBGb3IgZXhhbXBsZSwgdGhl IGF1dGhvcml6YXRpb24gc2VydmVyIGNvdWxkIGVtcGxveSByZWZyZXNoIHRva2VuIHJvdGF0aW9u IGluIHdoaWNoIGEgbmV3CiAgICAgICAgICByZWZyZXNoIHRva2VuIGlzIGlzc3VlZCB3aXRoIGV2 ZXJ5IGFjY2VzcyB0b2tlbiByZWZyZXNoIHJlc3BvbnNlLiBUaGUgcHJldmlvdXMgcmVmcmVzaAog ICAgICAgICAgdG9rZW4gaXMgaW52YWxpZGF0ZWQgYnV0IHJldGFpbmVkIGJ5IHRoZSBhdXRob3Jp emF0aW9uIHNlcnZlci4gSWYgYSByZWZyZXNoIHRva2VuIGlzCiAgICAgICAgICBjb21wcm9taXNl ZCBhbmQgc3Vic2VxdWVudGx5IHVzZWQgYnkgYm90aCB0aGUgYXR0YWNrZXIgYW5kIHRoZSBsZWdp dGltYXRlIGNsaWVudCwgb25lIG9mCiAgICAgICAgICB0aGVtIHdpbGwgcHJlc2VudCBhbiBpbnZh bGlkYXRlZCByZWZyZXNoIHRva2VuIHdoaWNoIHdpbGwgaW5mb3JtIHRoZSBhdXRob3JpemF0aW9u IHNlcnZlcgogICAgICAgICAgb2YgdGhlIGJyZWFjaC4KICAgICAgICAKPC9wPgo8cD4KICAgICAg ICAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBNVVNUIGVuc3VyZSB0aGF0IHJlZnJlc2ggdG9r ZW5zIGNhbm5vdCBiZSBnZW5lcmF0ZWQsIG1vZGlmaWVkLAogICAgICAgICAgb3IgZ3Vlc3NlZCB0 byBwcm9kdWNlIHZhbGlkIHJlZnJlc2ggdG9rZW5zIGJ5IHVuYXV0aG9yaXplZCBwYXJ0aWVzLgog ICAgICAgIAo8L3A+CjxhIG5hbWU9ImFuY2hvcjM4Ij48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBz dW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRP Q2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2Mi PiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rp b24uMTAuNSI+PC9hPjxoMz4xMC41LiZuYnNwOwpBdXRob3JpemF0aW9uIENvZGVzPC9oMz4KCjxw PgogICAgICAgICAgVGhlIHRyYW5zbWlzc2lvbiBvZiBhdXRob3JpemF0aW9uIGNvZGVzIFNIT1VM RCBiZSBtYWRlIG92ZXIgYSBzZWN1cmUgY2hhbm5lbCwgYW5kIHRoZQogICAgICAgICAgY2xpZW50 IFNIT1VMRCByZXF1aXJlIHRoZSB1c2Ugb2YgVExTIHdpdGggaXRzIHJlZGlyZWN0aW9uIFVSSSBp ZiB0aGUgVVJJIGlkZW50aWZpZXMgYQogICAgICAgICAgbmV0d29yayByZXNvdXJjZS4gU2luY2Ug YXV0aG9yaXphdGlvbiBjb2RlcyBhcmUgdHJhbnNtaXR0ZWQgdmlhIHVzZXItYWdlbnQgcmVkaXJl Y3Rpb25zLAogICAgICAgICAgdGhleSBjb3VsZCBwb3RlbnRpYWxseSBiZSBkaXNjbG9zZWQgdGhy b3VnaCB1c2VyLWFnZW50IGhpc3RvcnkgYW5kIEhUVFAgcmVmZXJyZXIgaGVhZGVycy4KICAgICAg ICAKPC9wPgo8cD4KICAgICAgICAgIEF1dGhvcml6YXRpb24gY29kZXMgb3BlcmF0ZSBhcyBwbGFp bnRleHQgYmVhcmVyIGNyZWRlbnRpYWxzLCB1c2VkIHRvIHZlcmlmeSB0aGF0IHRoZQogICAgICAg ICAgcmVzb3VyY2Ugb3duZXIgd2hvIGdyYW50ZWQgYXV0aG9yaXphdGlvbiBhdCB0aGUgYXV0aG9y aXphdGlvbiBzZXJ2ZXIgaXMgdGhlIHNhbWUKICAgICAgICAgIHJlc291cmNlIG93bmVyIHJldHVy bmluZyB0byB0aGUgY2xpZW50IHRvIGNvbXBsZXRlIHRoZSBwcm9jZXNzLiBUaGVyZWZvcmUsIGlm IHRoZSBjbGllbnQKICAgICAgICAgIHJlbGllcyBvbiB0aGUgYXV0aG9yaXphdGlvbiBjb2RlIGZv ciBpdHMgb3duIHJlc291cmNlIG93bmVyIGF1dGhlbnRpY2F0aW9uLCB0aGUgY2xpZW50CiAgICAg ICAgICByZWRpcmVjdGlvbiBlbmRwb2ludCBNVVNUIHJlcXVpcmUgdGhlIHVzZSBvZiBUTFMuCiAg ICAgICAgCjwvcD4KPHA+CiAgICAgICAgICBBdXRob3JpemF0aW9uIGNvZGVzIE1VU1QgYmUgc2hv cnQgbGl2ZWQgYW5kIHNpbmdsZSB1c2UuIElmIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlcgogICAg ICAgICAgb2JzZXJ2ZXMgbXVsdGlwbGUgYXR0ZW1wdHMgdG8gZXhjaGFuZ2UgYW4gYXV0aG9yaXph dGlvbiBjb2RlIGZvciBhbiBhY2Nlc3MgdG9rZW4sIHRoZQogICAgICAgICAgYXV0aG9yaXphdGlv biBzZXJ2ZXIgU0hPVUxEIGF0dGVtcHQgdG8gcmV2b2tlIGFsbCBhY2Nlc3MgdG9rZW5zIGFscmVh ZHkgZ3JhbnRlZCBiYXNlZCBvbgogICAgICAgICAgdGhlIGNvbXByb21pc2VkIGF1dGhvcml6YXRp b24gY29kZS4KICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgIElmIHRoZSBjbGllbnQgY2FuIGJl IGF1dGhlbnRpY2F0ZWQsIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlcnMgTVVTVCBhdXRoZW50aWNh dGUgdGhlCiAgICAgICAgICBjbGllbnQgYW5kIGVuc3VyZSB0aGF0IHRoZSBhdXRob3JpemF0aW9u IGNvZGUgd2FzIGlzc3VlZCB0byB0aGUgc2FtZSBjbGllbnQuCiAgICAgICAgCjwvcD4KPGEgbmFt ZT0iYW5jaG9yMzkiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2Vs bHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQi Pjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9h PjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi4xMC42Ij48L2E+PGgzPjEw LjYuJm5ic3A7CkF1dGhvcml6YXRpb24gQ29kZSBSZWRpcmVjdGlvbiBVUkkgTWFuaXB1bGF0aW9u PC9oMz4KCjxwPgogICAgICAgICAgV2hlbiByZXF1ZXN0aW5nIGF1dGhvcml6YXRpb24gdXNpbmcg dGhlIGF1dGhvcml6YXRpb24gY29kZSBncmFudCB0eXBlLCB0aGUgY2xpZW50IGNhbgogICAgICAg ICAgc3BlY2lmeSBhIHJlZGlyZWN0aW9uIFVSSSB2aWEgdGhlIDx0dD5yZWRpcmVjdF91cmk8L3R0 PiBwYXJhbWV0ZXIuCiAgICAgICAgICBJZiBhbiBhdHRhY2tlciBjYW4gbWFuaXB1bGF0ZSB0aGUg dmFsdWUgb2YgdGhlIHJlZGlyZWN0aW9uIFVSSSwgaXQgY2FuIGNhdXNlIHRoZQogICAgICAgICAg YXV0aG9yaXphdGlvbiBzZXJ2ZXIgdG8gcmVkaXJlY3QgdGhlIHJlc291cmNlIG93bmVyIHVzZXIt YWdlbnQgdG8gYSBVUkkgdW5kZXIgdGhlIGNvbnRyb2wKICAgICAgICAgIG9mIHRoZSBhdHRhY2tl ciB3aXRoIHRoZSBhdXRob3JpemF0aW9uIGNvZGUuCiAgICAgICAgCjwvcD4KPHA+CiAgICAgICAg ICBBbiBhdHRhY2tlciBjYW4gY3JlYXRlIGFuIGFjY291bnQgYXQgYSBsZWdpdGltYXRlIGNsaWVu dCBhbmQgaW5pdGlhdGUgdGhlIGF1dGhvcml6YXRpb24KICAgICAgICAgIGZsb3cuIFdoZW4gdGhl IGF0dGFja2VyJ3MgdXNlci1hZ2VudCBpcyBzZW50IHRvIHRoZSBhdXRob3JpemF0aW9uIHNlcnZl ciB0byBncmFudCBhY2Nlc3MsCiAgICAgICAgICB0aGUgYXR0YWNrZXIgZ3JhYnMgdGhlIGF1dGhv cml6YXRpb24gVVJJIHByb3ZpZGVkIGJ5IHRoZSBsZWdpdGltYXRlIGNsaWVudCwgYW5kIHJlcGxh Y2VzCiAgICAgICAgICB0aGUgY2xpZW50J3MgcmVkaXJlY3Rpb24gVVJJIHdpdGggYSBVUkkgdW5k ZXIgdGhlIGNvbnRyb2wgb2YgdGhlIGF0dGFja2VyLiBUaGUgYXR0YWNrZXIKICAgICAgICAgIHRo ZW4gdHJpY2tzIHRoZSB2aWN0aW0gaW50byBmb2xsb3dpbmcgdGhlIG1hbmlwdWxhdGVkIGxpbmsg dG8gYXV0aG9yaXplIGFjY2VzcyB0byB0aGUKICAgICAgICAgIGxlZ2l0aW1hdGUgY2xpZW50Lgog ICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgT25jZSBhdCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2 ZXIsIHRoZSB2aWN0aW0gaXMgcHJvbXB0ZWQgd2l0aCBhIG5vcm1hbCwgdmFsaWQgcmVxdWVzdCBv bgogICAgICAgICAgYmVoYWxmIG9mIGEgbGVnaXRpbWF0ZSBhbmQgdHJ1c3RlZCBjbGllbnQsIGFu ZCBhdXRob3JpemVzIHRoZSByZXF1ZXN0LiBUaGUgdmljdGltIGlzCiAgICAgICAgICB0aGVuIHJl ZGlyZWN0ZWQgdG8gYW4gZW5kcG9pbnQgdW5kZXIgdGhlIGNvbnRyb2wgb2YgdGhlIGF0dGFja2Vy IHdpdGggdGhlIGF1dGhvcml6YXRpb24KICAgICAgICAgIGNvZGUuIFRoZSBhdHRhY2tlciBjb21w bGV0ZXMgdGhlIGF1dGhvcml6YXRpb24gZmxvdyBieSBzZW5kaW5nIHRoZSBhdXRob3JpemF0aW9u IGNvZGUgdG8KICAgICAgICAgIHRoZSBjbGllbnQgdXNpbmcgdGhlIG9yaWdpbmFsIHJlZGlyZWN0 aW9uIFVSSSBwcm92aWRlZCBieSB0aGUgY2xpZW50LiBUaGUgY2xpZW50CiAgICAgICAgICBleGNo YW5nZXMgdGhlIGF1dGhvcml6YXRpb24gY29kZSB3aXRoIGFuIGFjY2VzcyB0b2tlbiBhbmQgbGlu a3MgaXQgdG8gdGhlIGF0dGFja2VyJ3MKICAgICAgICAgIGNsaWVudCBhY2NvdW50IHdoaWNoIGNh biBub3cgZ2FpbiBhY2Nlc3MgdG8gdGhlIHByb3RlY3RlZCByZXNvdXJjZXMgYXV0aG9yaXplZCBi eSB0aGUKICAgICAgICAgIHZpY3RpbSAodmlhIHRoZSBjbGllbnQpLgogICAgICAgIAo8L3A+Cjxw PgogICAgICAgICAgSW4gb3JkZXIgdG8gcHJldmVudCBzdWNoIGFuIGF0dGFjaywgdGhlIGF1dGhv cml6YXRpb24gc2VydmVyIE1VU1QgZW5zdXJlIHRoYXQgdGhlCiAgICAgICAgICByZWRpcmVjdGlv biBVUkkgdXNlZCB0byBvYnRhaW4gdGhlIGF1dGhvcml6YXRpb24gY29kZSBpcyBpZGVudGljYWwg dG8gdGhlIHJlZGlyZWN0aW9uIFVSSQogICAgICAgICAgcHJvdmlkZWQgd2hlbiBleGNoYW5naW5n IHRoZSBhdXRob3JpemF0aW9uIGNvZGUgZm9yIGFuIGFjY2VzcyB0b2tlbi4gVGhlIGF1dGhvcml6 YXRpb24KICAgICAgICAgIHNlcnZlciBNVVNUIHJlcXVpcmUgcHVibGljIGNsaWVudHMgYW5kIFNI T1VMRCByZXF1aXJlIGNvbmZpZGVudGlhbCBjbGllbnRzIHRvIHJlZ2lzdGVyCiAgICAgICAgICB0 aGVpciByZWRpcmVjdGlvbiBVUklzLiBJZiBhIHJlZGlyZWN0aW9uIFVSSSBpcyBwcm92aWRlZCBp biB0aGUgcmVxdWVzdCwgdGhlCiAgICAgICAgICBhdXRob3JpemF0aW9uIHNlcnZlciBNVVNUIHZh bGlkYXRlIGl0IGFnYWluc3QgdGhlIHJlZ2lzdGVyZWQgdmFsdWUuCiAgICAgICAgCjwvcD4KPGEg bmFtZT0iYW5jaG9yNDAiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIg Y2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmln aHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7 PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi4xMC43Ij48L2E+PGgz PjEwLjcuJm5ic3A7ClJlc291cmNlIE93bmVyIFBhc3N3b3JkIENyZWRlbnRpYWxzPC9oMz4KCjxw PgogICAgICAgICAgVGhlIHJlc291cmNlIG93bmVyIHBhc3N3b3JkIGNyZWRlbnRpYWxzIGdyYW50 IHR5cGUgaXMgb2Z0ZW4gdXNlZCBmb3IgbGVnYWN5IG9yIG1pZ3JhdGlvbgogICAgICAgICAgcmVh c29ucy4gSXQgcmVkdWNlcyB0aGUgb3ZlcmFsbCByaXNrIG9mIHN0b3JpbmcgdXNlcm5hbWUgYW5k IHBhc3N3b3JkIGJ5IHRoZSBjbGllbnQsIGJ1dAogICAgICAgICAgZG9lcyBub3QgZWxpbWluYXRl IHRoZSBuZWVkIHRvIGV4cG9zZSBoaWdobHkgcHJpdmlsZWdlZCBjcmVkZW50aWFscyB0byB0aGUg Y2xpZW50LgogICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgVGhpcyBncmFudCB0eXBlIGNhcnJp ZXMgYSBoaWdoZXIgcmlzayB0aGFuIG90aGVyIGdyYW50IHR5cGVzIGJlY2F1c2UgaXQgbWFpbnRh aW5zIHRoZQogICAgICAgICAgcGFzc3dvcmQgYW50aS1wYXR0ZXJuIHRoaXMgcHJvdG9jb2wgc2Vl a3MgdG8gYXZvaWQuIFRoZSBjbGllbnQgY291bGQgYWJ1c2UgdGhlIHBhc3N3b3JkCiAgICAgICAg ICBvciB0aGUgcGFzc3dvcmQgY291bGQgdW5pbnRlbnRpb25hbGx5IGJlIGRpc2Nsb3NlZCB0byBh biBhdHRhY2tlciAoZS5nLiB2aWEgbG9nIGZpbGVzIG9yCiAgICAgICAgICBvdGhlciByZWNvcmRz IGtlcHQgYnkgdGhlIGNsaWVudCkuCiAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICBBZGRpdGlv bmFsbHksIGJlY2F1c2UgdGhlIHJlc291cmNlIG93bmVyIGRvZXMgbm90IGhhdmUgY29udHJvbCBv dmVyIHRoZSBhdXRob3JpemF0aW9uCiAgICAgICAgICBwcm9jZXNzICh0aGUgcmVzb3VyY2Ugb3du ZXIgaW52b2x2ZW1lbnQgZW5kcyB3aGVuIGl0IGhhbmRzIG92ZXIgaXRzIGNyZWRlbnRpYWxzIHRv IHRoZQogICAgICAgICAgY2xpZW50KSwgdGhlIGNsaWVudCBjYW4gb2J0YWluIGFjY2VzcyB0b2tl bnMgd2l0aCBhIGJyb2FkZXIgc2NvcGUgdGhhbiBkZXNpcmVkIGJ5IHRoZQogICAgICAgICAgcmVz b3VyY2Ugb3duZXIuIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBzaG91bGQgY29uc2lkZXIgdGhl IHNjb3BlIGFuZCBsaWZldGltZSBvZgogICAgICAgICAgYWNjZXNzIHRva2VucyBpc3N1ZWQgdmlh IHRoaXMgZ3JhbnQgdHlwZS4KICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgIFRoZSBhdXRob3Jp emF0aW9uIHNlcnZlciBhbmQgY2xpZW50IFNIT1VMRCBtaW5pbWl6ZSB1c2Ugb2YgdGhpcyBncmFu dCB0eXBlIGFuZCB1dGlsaXplCiAgICAgICAgICBvdGhlciBncmFudCB0eXBlcyB3aGVuZXZlciBw b3NzaWJsZS4KICAgICAgICAKPC9wPgo8YSBuYW1lPSJhbmNob3I0MSI+PC9hPjxiciAvPjxociAv Pgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIi IGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBo cmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9 InJmYy5zZWN0aW9uLjEwLjgiPjwvYT48aDM+MTAuOC4mbmJzcDsKUmVxdWVzdCBDb25maWRlbnRp YWxpdHk8L2gzPgoKPHA+CiAgICAgICAgICBBY2Nlc3MgdG9rZW5zLCByZWZyZXNoIHRva2Vucywg cmVzb3VyY2Ugb3duZXIgcGFzc3dvcmRzLCBhbmQgY2xpZW50IGNyZWRlbnRpYWxzIE1VU1QgTk9U CiAgICAgICAgICBiZSB0cmFuc21pdHRlZCBpbiB0aGUgY2xlYXIuIEF1dGhvcml6YXRpb24gY29k ZXMgU0hPVUxEIE5PVCBiZSB0cmFuc21pdHRlZCBpbiB0aGUgY2xlYXIuCiAgICAgICAgCjwvcD4K PHA+CiAgICAgICAgICBUaGUgPHR0PnN0YXRlPC90dD4gYW5kIDx0dD5zY29wZTwvdHQ+IHBhcmFt ZXRlcnMKICAgICAgICAgIFNIT1VMRCBOT1QgaW5jbHVkZSBzZW5zaXRpdmUgY2xpZW50IG9yIHJl c291cmNlIG93bmVyIGluZm9ybWF0aW9uIGluIHBsYWluIHRleHQgYXMgdGhleQogICAgICAgICAg Y2FuIGJlIHRyYW5zbWl0dGVkIG92ZXIgaW5zZWN1cmUgY2hhbm5lbHMgb3Igc3RvcmVkIGluc2Vj dXJlbHkuCiAgICAgICAgCjwvcD4KPGEgbmFtZT0iYW5jaG9yNDIiPjwvYT48YnIgLz48aHIgLz4K PHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBj bGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJl Zj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJy ZmMuc2VjdGlvbi4xMC45Ij48L2E+PGgzPjEwLjkuJm5ic3A7CkVuZHBvaW50cyBBdXRoZW50aWNp dHk8L2gzPgoKPHA+CiAgICAgICAgICBJbiBvcmRlciB0byBwcmV2ZW50IG1hbi1pbi10aGUtbWlk ZGxlIGF0dGFja3MsIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBNVVNUIHJlcXVpcmUgdGhlCiAg ICAgICAgICB1c2Ugb2YgVExTIHdpdGggc2VydmVyIGF1dGhlbnRpY2F0aW9uIGFzIGRlZmluZWQg YnkgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNSRkMyODE4Jz5bUkZDMjgxOF08c3Bhbj4gKDwvc3Bh bj48c3BhbiBjbGFzcz0naW5mbyc+UmVzY29ybGEsIEUuLCAmbGRxdW87SFRUUCBPdmVyIFRMUywm cmRxdW87IE1heSZuYnNwOzIwMDAuPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPiBmb3IKICAgICAg ICAgIGFueSByZXF1ZXN0IHNlbnQgdG8gdGhlIGF1dGhvcml6YXRpb24gYW5kIHRva2VuIGVuZHBv aW50cy4gVGhlIGNsaWVudCBNVVNUIHZhbGlkYXRlIHRoZQogICAgICAgICAgYXV0aG9yaXphdGlv biBzZXJ2ZXIncyBUTFMgY2VydGlmaWNhdGUgYXMgZGVmaW5lZCBieSA8YSBjbGFzcz0naW5mbycg aHJlZj0nI1JGQzYxMjUnPltSRkM2MTI1XTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZv Jz5TYWludC1BbmRyZSwgUC4gYW5kIEouIEhvZGdlcywgJmxkcXVvO1JlcHJlc2VudGF0aW9uIGFu ZCBWZXJpZmljYXRpb24gb2YgRG9tYWluLUJhc2VkIEFwcGxpY2F0aW9uIFNlcnZpY2UgSWRlbnRp dHkgd2l0aGluIEludGVybmV0IFB1YmxpYyBLZXkgSW5mcmFzdHJ1Y3R1cmUgVXNpbmcgWC41MDkg KFBLSVgpIENlcnRpZmljYXRlcyBpbiB0aGUgQ29udGV4dCBvZiBUcmFuc3BvcnQgTGF5ZXIgU2Vj dXJpdHkgKFRMUyksJnJkcXVvOyBNYXJjaCZuYnNwOzIwMTEuPC9zcGFuPjxzcGFuPik8L3NwYW4+ PC9hPiwgYW5kIGluCiAgICAgICAgICBhY2NvcmRhbmNlIHdpdGggaXRzIHJlcXVpcmVtZW50cyBm b3Igc2VydmVyIGlkZW50aXR5IGF1dGhlbnRpY2F0aW9uLgogICAgICAgIAo8L3A+CjxhIG5hbWU9 ImFudGhyb3B5Ij48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxw YWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48 dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48 L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uMTAuMTAiPjwvYT48aDM+MTAu MTAuJm5ic3A7CkNyZWRlbnRpYWxzIEd1ZXNzaW5nIEF0dGFja3M8L2gzPgoKPHA+CiAgICAgICAg ICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVTVCBwcmV2ZW50IGF0dGFja2VycyBmcm9tIGd1 ZXNzaW5nIGFjY2VzcyB0b2tlbnMsCiAgICAgICAgICBhdXRob3JpemF0aW9uIGNvZGVzLCByZWZy ZXNoIHRva2VucywgcmVzb3VyY2Ugb3duZXIgcGFzc3dvcmRzLCBhbmQgY2xpZW50IGNyZWRlbnRp YWxzLgogICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgVGhlIHByb2JhYmlsaXR5IG9mIGFuIGF0 dGFja2VyIGd1ZXNzaW5nIGdlbmVyYXRlZCB0b2tlbnMgKGFuZCBvdGhlciBjcmVkZW50aWFscyBu b3QKICAgICAgICAgIGludGVuZGVkIGZvciBoYW5kbGluZyBieSBlbmQtdXNlcnMpIE1VU1QgYmUg bGVzcyB0aGFuIG9yIGVxdWFsIHRvIDJeKC0xMjgpIGFuZCBTSE9VTEQgYmUKICAgICAgICAgIGxl c3MgdGhhbiBvciBlcXVhbCB0byAyXigtMTYwKS4KICAgICAgICAKPC9wPgo8cD4KICAgICAgICAg IFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBNVVNUIHV0aWxpemUgb3RoZXIgbWVhbnMgdG8gcHJv dGVjdCBjcmVkZW50aWFscyBpbnRlbmRlZCBmb3IKICAgICAgICAgIGVuZC11c2VyIHVzYWdlLgog ICAgICAgIAo8L3A+CjxhIG5hbWU9ImFuY2hvcjQzIj48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBz dW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRP Q2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2Mi PiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rp b24uMTAuMTEiPjwvYT48aDM+MTAuMTEuJm5ic3A7ClBoaXNoaW5nIEF0dGFja3M8L2gzPgoKPHA+ CiAgICAgICAgICBXaWRlIGRlcGxveW1lbnQgb2YgdGhpcyBhbmQgc2ltaWxhciBwcm90b2NvbHMg bWF5IGNhdXNlIGVuZC11c2VycyB0byBiZWNvbWUgaW51cmVkCiAgICAgICAgICB0byB0aGUgcHJh Y3RpY2Ugb2YgYmVpbmcgcmVkaXJlY3RlZCB0byB3ZWJzaXRlcyB3aGVyZSB0aGV5IGFyZSBhc2tl ZCB0byBlbnRlciB0aGVpcgogICAgICAgICAgcGFzc3dvcmRzLiBJZiBlbmQtdXNlcnMgYXJlIG5v dCBjYXJlZnVsIHRvIHZlcmlmeSB0aGUgYXV0aGVudGljaXR5IG9mIHRoZXNlIHdlYnNpdGVzCiAg ICAgICAgICBiZWZvcmUgZW50ZXJpbmcgdGhlaXIgY3JlZGVudGlhbHMsIGl0IHdpbGwgYmUgcG9z c2libGUgZm9yIGF0dGFja2VycyB0byBleHBsb2l0IHRoaXMKICAgICAgICAgIHByYWN0aWNlIHRv IHN0ZWFsIHJlc291cmNlIG93bmVycycgcGFzc3dvcmRzLgogICAgICAgIAo8L3A+CjxwPgogICAg ICAgICAgU2VydmljZSBwcm92aWRlcnMgc2hvdWxkIGF0dGVtcHQgdG8gZWR1Y2F0ZSBlbmQtdXNl cnMgYWJvdXQgdGhlIHJpc2tzIHBoaXNoaW5nIGF0dGFja3MKICAgICAgICAgIHBvc2UsIGFuZCBz aG91bGQgcHJvdmlkZSBtZWNoYW5pc21zIHRoYXQgbWFrZSBpdCBlYXN5IGZvciBlbmQtdXNlcnMg dG8gY29uZmlybSB0aGUKICAgICAgICAgIGF1dGhlbnRpY2l0eSBvZiB0aGVpciBzaXRlcy4gQ2xp ZW50IGRldmVsb3BlcnMgc2hvdWxkIGNvbnNpZGVyIHRoZSBzZWN1cml0eSBpbXBsaWNhdGlvbnMK ICAgICAgICAgIG9mIGhvdyB0aGV5IGludGVyYWN0IHdpdGggdGhlIHVzZXItYWdlbnQgKGUuZy4s IGV4dGVybmFsLCBlbWJlZGRlZCksIGFuZCB0aGUgYWJpbGl0eSBvZgogICAgICAgICAgdGhlIGVu ZC11c2VyIHRvIHZlcmlmeSB0aGUgYXV0aGVudGljaXR5IG9mIHRoZSBhdXRob3JpemF0aW9uIHNl cnZlci4KICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgIFRvIHJlZHVjZSB0aGUgcmlzayBvZiBw aGlzaGluZyBhdHRhY2tzLCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXJzIE1VU1QgcmVxdWlyZSB0 aGUgdXNlIG9mCiAgICAgICAgICBUTFMgb24gZXZlcnkgZW5kcG9pbnQgdXNlZCBmb3IgZW5kLXVz ZXIgaW50ZXJhY3Rpb24uCiAgICAgICAgCjwvcD4KPGEgbmFtZT0iQ1NSRiI+PC9hPjxiciAvPjxo ciAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9 IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48 YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5h bWU9InJmYy5zZWN0aW9uLjEwLjEyIj48L2E+PGgzPjEwLjEyLiZuYnNwOwpDcm9zcy1TaXRlIFJl cXVlc3QgRm9yZ2VyeTwvaDM+Cgo8cD4KICAgICAgICAgIENyb3NzLXNpdGUgcmVxdWVzdCBmb3Jn ZXJ5IChDU1JGKSBpcyBhbiBleHBsb2l0IGluIHdoaWNoIGFuIGF0dGFja2VyIGNhdXNlcyB0aGUK ICAgICAgICAgIHVzZXItYWdlbnQgb2YgYSB2aWN0aW0gZW5kLXVzZXIgdG8gZm9sbG93IGEgbWFs aWNpb3VzIFVSSSAoZS5nLiBwcm92aWRlZCB0byB0aGUKICAgICAgICAgIHVzZXItYWdlbnQgYXMg YSBtaXNsZWFkaW5nIGxpbmssIGltYWdlLCBvciByZWRpcmVjdGlvbikgdG8gYSB0cnVzdGluZyBz ZXJ2ZXIgKHVzdWFsbHkKICAgICAgICAgIGVzdGFibGlzaGVkIHZpYSB0aGUgcHJlc2VuY2Ugb2Yg YSB2YWxpZCBzZXNzaW9uIGNvb2tpZSkuCiAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICBBIENT UkYgYXR0YWNrIGFnYWluc3QgdGhlIGNsaWVudCdzIHJlZGlyZWN0aW9uIFVSSSBhbGxvd3MgYW4g YXR0YWNrZXIgdG8gaW5qZWN0IHRoZWlyIG93bgogICAgICAgICAgYXV0aG9yaXphdGlvbiBjb2Rl IG9yIGFjY2VzcyB0b2tlbiwgd2hpY2ggY2FuIHJlc3VsdCBpbiB0aGUgY2xpZW50IHVzaW5nIGFu IGFjY2VzcyB0b2tlbgogICAgICAgICAgYXNzb2NpYXRlZCB3aXRoIHRoZSBhdHRhY2tlcidzIHBy b3RlY3RlZCByZXNvdXJjZXMgcmF0aGVyIHRoYW4gdGhlIHZpY3RpbSdzIChlLmcuIHNhdmUKICAg ICAgICAgIHRoZSB2aWN0aW0ncyBiYW5rIGFjY291bnQgaW5mb3JtYXRpb24gdG8gYSBwcm90ZWN0 ZWQgcmVzb3VyY2UgY29udHJvbGxlZCBieSB0aGUKICAgICAgICAgIGF0dGFja2VyKS4KICAgICAg ICAKPC9wPgo8cD4KICAgICAgICAgIFRoZSBjbGllbnQgTVVTVCBpbXBsZW1lbnQgQ1NSRiBwcm90 ZWN0aW9uIGZvciBpdHMgcmVkaXJlY3Rpb24gVVJJLiBUaGlzIGlzIHR5cGljYWxseQogICAgICAg ICAgYWNjb21wbGlzaGVkIGJ5IHJlcXVpcmluZyBhbnkgcmVxdWVzdCBzZW50IHRvIHRoZSByZWRp cmVjdGlvbiBVUkkgZW5kcG9pbnQgdG8gaW5jbHVkZSBhCiAgICAgICAgICB2YWx1ZSB0aGF0IGJp bmRzIHRoZSByZXF1ZXN0IHRvIHRoZSB1c2VyLWFnZW50J3MgYXV0aGVudGljYXRlZCBzdGF0ZSAo ZS5nLiBhIGhhc2ggb2YgdGhlCiAgICAgICAgICBzZXNzaW9uIGNvb2tpZSB1c2VkIHRvIGF1dGhl bnRpY2F0ZSB0aGUgdXNlci1hZ2VudCkuIFRoZSBjbGllbnQgU0hPVUxEIHV0aWxpemUgdGhlCiAg ICAgICAgICA8dHQ+c3RhdGU8L3R0PiByZXF1ZXN0IHBhcmFtZXRlciB0byBkZWxpdmVyIHRoaXMg dmFsdWUgdG8gdGhlCiAgICAgICAgICBhdXRob3JpemF0aW9uIHNlcnZlciB3aGVuIG1ha2luZyBh biBhdXRob3JpemF0aW9uIHJlcXVlc3QuCiAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICBPbmNl IGF1dGhvcml6YXRpb24gaGFzIGJlZW4gb2J0YWluZWQgZnJvbSB0aGUgZW5kLXVzZXIsIHRoZSBh dXRob3JpemF0aW9uIHNlcnZlcgogICAgICAgICAgcmVkaXJlY3RzIHRoZSBlbmQtdXNlcidzIHVz ZXItYWdlbnQgYmFjayB0byB0aGUgY2xpZW50IHdpdGggdGhlIHJlcXVpcmVkIGJpbmRpbmcgdmFs dWUKICAgICAgICAgIGNvbnRhaW5lZCBpbiB0aGUgPHR0PnN0YXRlPC90dD4gcGFyYW1ldGVyLiBU aGUgYmluZGluZyB2YWx1ZSBlbmFibGVzCiAgICAgICAgICB0aGUgY2xpZW50IHRvIHZlcmlmeSB0 aGUgdmFsaWRpdHkgb2YgdGhlIHJlcXVlc3QgYnkgbWF0Y2hpbmcgdGhlIGJpbmRpbmcgdmFsdWUg dG8gdGhlCiAgICAgICAgICB1c2VyLWFnZW50J3MgYXV0aGVudGljYXRlZCBzdGF0ZS4gVGhlIGJp bmRpbmcgdmFsdWUgdXNlZCBmb3IgQ1NSRiBwcm90ZWN0aW9uIE1VU1QgY29udGFpbgogICAgICAg ICAgYSBub24tZ3Vlc3NhYmxlIHZhbHVlIChhcyBkZXNjcmliZWQgaW4gPGEgY2xhc3M9J2luZm8n IGhyZWY9JyNhbnRocm9weSc+U2VjdGlvbiZuYnNwOzEwLjEwPHNwYW4+ICg8L3NwYW4+PHNwYW4g Y2xhc3M9J2luZm8nPkNyZWRlbnRpYWxzIEd1ZXNzaW5nIEF0dGFja3M8L3NwYW4+PHNwYW4+KTwv c3Bhbj48L2E+KSwgYW5kIHRoZSB1c2VyLWFnZW50J3MKICAgICAgICAgIGF1dGhlbnRpY2F0ZWQg c3RhdGUgKGUuZy4gc2Vzc2lvbiBjb29raWUsIEhUTUw1IGxvY2FsIHN0b3JhZ2UpIE1VU1QgYmUg a2VwdCBpbiBhIGxvY2F0aW9uCiAgICAgICAgICBhY2Nlc3NpYmxlIG9ubHkgdG8gdGhlIGNsaWVu dCBhbmQgdGhlIHVzZXItYWdlbnQgKGkuZS4sIHByb3RlY3RlZCBieSBzYW1lLW9yaWdpbiBwb2xp Y3kpLgogICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgQSBDU1JGIGF0dGFjayBhZ2FpbnN0IHRo ZSBhdXRob3JpemF0aW9uIHNlcnZlcidzIGF1dGhvcml6YXRpb24gZW5kcG9pbnQgY2FuIHJlc3Vs dCBpbiBhbgogICAgICAgICAgYXR0YWNrZXIgb2J0YWluaW5nIGVuZC11c2VyIGF1dGhvcml6YXRp b24gZm9yIGEgbWFsaWNpb3VzIGNsaWVudCB3aXRob3V0IGludm9sdmluZyBvcgogICAgICAgICAg YWxlcnRpbmcgdGhlIGVuZC11c2VyLgogICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgVGhlIGF1 dGhvcml6YXRpb24gc2VydmVyIE1VU1QgaW1wbGVtZW50IENTUkYgcHJvdGVjdGlvbiBmb3IgaXRz IGF1dGhvcml6YXRpb24gZW5kcG9pbnQsCiAgICAgICAgICBhbmQgZW5zdXJlIHRoYXQgYSBtYWxp Y2lvdXMgY2xpZW50IGNhbm5vdCBvYnRhaW4gYXV0aG9yaXphdGlvbiB3aXRob3V0IHRoZSBhd2Fy ZW5lc3MgYW5kCiAgICAgICAgICBleHBsaWNpdCBjb25zZW50IG9mIHRoZSByZXNvdXJjZSBvd25l ci4KICAgICAgICAKPC9wPgo8YSBuYW1lPSJhbmNob3I0NCI+PC9hPjxiciAvPjxociAvPgo8dGFi bGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNz PSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIj dG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5z ZWN0aW9uLjEwLjEzIj48L2E+PGgzPjEwLjEzLiZuYnNwOwpDbGlja2phY2tpbmc8L2gzPgoKPHA+ CiAgICAgICAgICBJbiBhIGNsaWNramFja2luZyBhdHRhY2ssIGFuIGF0dGFja2VyIHJlZ2lzdGVy cyBhIGxlZ2l0aW1hdGUgY2xpZW50IGFuZCB0aGVuIGNvbnN0cnVjdHMgYQogICAgICAgICAgbWFs aWNpb3VzIHNpdGUgaW4gd2hpY2ggaXQgbG9hZHMgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyJ3Mg YXV0aG9yaXphdGlvbiBlbmRwb2ludCB3ZWIKICAgICAgICAgIHBhZ2UgaW4gYSB0cmFuc3BhcmVu dCBpZnJhbWUgb3ZlcmxhaWQgb24gdG9wIG9mIGEgc2V0IG9mIGR1bW15IGJ1dHRvbnMgd2hpY2gg YXJlCiAgICAgICAgICBjYXJlZnVsbHkgY29uc3RydWN0ZWQgdG8gYmUgcGxhY2VkIGRpcmVjdGx5 IHVuZGVyIGltcG9ydGFudCBidXR0b25zIG9uIHRoZSBhdXRob3JpemF0aW9uCiAgICAgICAgICBw YWdlLiBXaGVuIGFuIGVuZC11c2VyIGNsaWNrcyBhIG1pc2xlYWRpbmcgdmlzaWJsZSBidXR0b24s IHRoZSBlbmQtdXNlciBpcyBhY3R1YWxseQogICAgICAgICAgY2xpY2tpbmcgYW4gaW52aXNpYmxl IGJ1dHRvbiBvbiB0aGUgYXV0aG9yaXphdGlvbiBwYWdlIChzdWNoIGFzIGFuICJBdXRob3JpemUi IGJ1dHRvbikuCiAgICAgICAgICBUaGlzIGFsbG93cyBhbiBhdHRhY2tlciB0byB0cmljayBhIHJl c291cmNlIG93bmVyIGludG8gZ3JhbnRpbmcgaXRzIGNsaWVudCBhY2Nlc3Mgd2l0aG91dAogICAg ICAgICAgdGhlaXIga25vd2xlZGdlLgogICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgVG8gcHJl dmVudCB0aGlzIGZvcm0gb2YgYXR0YWNrLCBuYXRpdmUgYXBwbGljYXRpb25zIFNIT1VMRCB1c2Ug ZXh0ZXJuYWwgYnJvd3NlcnMgaW5zdGVhZAogICAgICAgICAgb2YgZW1iZWRkaW5nIGJyb3dzZXJz IHdpdGhpbiB0aGUgYXBwbGljYXRpb24gd2hlbiByZXF1ZXN0aW5nIGVuZC11c2VyIGF1dGhvcml6 YXRpb24uIEZvcgogICAgICAgICAgbW9zdCBuZXdlciBicm93c2VycywgYXZvaWRhbmNlIG9mIGlm cmFtZXMgY2FuIGJlIGVuZm9yY2VkIGJ5IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlcgogICAgICAg ICAgdXNpbmcgdGhlIChub24tc3RhbmRhcmQpIDx0dD54LWZyYW1lLW9wdGlvbnM8L3R0PiBoZWFk ZXIuIFRoaXMgaGVhZGVyCiAgICAgICAgICBjYW4gaGF2ZSB0d28gdmFsdWVzLCA8dHQ+ZGVueTwv dHQ+IGFuZAogICAgICAgICAgPHR0PnNhbWVvcmlnaW48L3R0Piwgd2hpY2ggd2lsbCBibG9jayBh bnkgZnJhbWluZywgb3IgZnJhbWluZyBieSBzaXRlcwogICAgICAgICAgd2l0aCBhIGRpZmZlcmVu dCBvcmlnaW4sIHJlc3BlY3RpdmVseS4gRm9yIG9sZGVyIGJyb3dzZXJzLCBKYXZhU2NyaXB0IGZy YW1lYnVzdGluZwogICAgICAgICAgdGVjaG5pcXVlcyBjYW4gYmUgdXNlZCBidXQgbWF5IG5vdCBi ZSBlZmZlY3RpdmUgaW4gYWxsIGJyb3dzZXJzLgogICAgICAgIAo8L3A+CjxhIG5hbWU9ImFuY2hv cjQ1Ij48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5n PSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRk IGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwv dHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uMTAuMTQiPjwvYT48aDM+MTAuMTQuJm5i c3A7CkNvZGUgSW5qZWN0aW9uIGFuZCBJbnB1dCBWYWxpZGF0aW9uPC9oMz4KCjxwPgogICAgICAg ICAgQSBjb2RlIGluamVjdGlvbiBhdHRhY2sgb2NjdXJzIHdoZW4gYW4gaW5wdXQgb3Igb3RoZXJ3 aXNlIGV4dGVybmFsIHZhcmlhYmxlIGlzIHVzZWQgYnkgYW4KICAgICAgICAgIGFwcGxpY2F0aW9u IHVuc2FuaXRpemVkIGFuZCBjYXVzZXMgbW9kaWZpY2F0aW9uIHRvIHRoZSBhcHBsaWNhdGlvbiBs b2dpYy4gVGhpcyBtYXkgYWxsb3cKICAgICAgICAgIGFuIGF0dGFja2VyIHRvIGdhaW4gYWNjZXNz IHRvIHRoZSBhcHBsaWNhdGlvbiBkZXZpY2Ugb3IgaXRzIGRhdGEsIGNhdXNlIGRlbmlhbCBvZgog ICAgICAgICAgc2VydmljZSwgb3IgYSB3aWRlIHJhbmdlIG9mIG1hbGljaW91cyBzaWRlLWVmZmVj dHMuCiAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICBUaGUgQXV0aG9yaXphdGlvbiBzZXJ2ZXIg YW5kIGNsaWVudCBNVVNUIHNhbml0aXplIChhbmQgdmFsaWRhdGUgd2hlbiBwb3NzaWJsZSkgYW55 IHZhbHVlCiAgICAgICAgICByZWNlaXZlZCwgaW4gcGFydGljdWxhciwgdGhlIHZhbHVlIG9mIHRo ZSA8dHQ+c3RhdGU8L3R0PiBhbmQKICAgICAgICAgIDx0dD5yZWRpcmVjdF91cmk8L3R0PiBwYXJh bWV0ZXJzLgogICAgICAgIAo8L3A+CjxhIG5hbWU9Im9wZW4tcmVkaXJlY3QiPjwvYT48YnIgLz48 aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5n PSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+ PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBu YW1lPSJyZmMuc2VjdGlvbi4xMC4xNSI+PC9hPjxoMz4xMC4xNS4mbmJzcDsKT3BlbiBSZWRpcmVj dG9yczwvaDM+Cgo8cD4KICAgICAgICAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBhdXRob3Jp emF0aW9uIGVuZHBvaW50IGFuZCB0aGUgY2xpZW50IHJlZGlyZWN0aW9uIGVuZHBvaW50IGNhbgog ICAgICAgICAgYmUgaW1wcm9wZXJseSBjb25maWd1cmVkIGFuZCBvcGVyYXRlIGFzIG9wZW4gcmVk aXJlY3RvcnMuIEFuIG9wZW4gcmVkaXJlY3RvciBpcyBhbgogICAgICAgICAgZW5kcG9pbnQgdXNp bmcgYSBwYXJhbWV0ZXIgdG8gYXV0b21hdGljYWxseSByZWRpcmVjdCBhIHVzZXItYWdlbnQgdG8g dGhlIGxvY2F0aW9uCiAgICAgICAgICBzcGVjaWZpZWQgYnkgdGhlIHBhcmFtZXRlciB2YWx1ZSB3 aXRob3V0IGFueSB2YWxpZGF0aW9uLgogICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgT3BlbiBy ZWRpcmVjdG9ycyBjYW4gYmUgdXNlZCBpbiBwaGlzaGluZyBhdHRhY2tzLCBvciBieSBhbiBhdHRh Y2tlciB0byBnZXQgZW5kLXVzZXJzIHRvCiAgICAgICAgICB2aXNpdCBtYWxpY2lvdXMgc2l0ZXMg YnkgbWFraW5nIHRoZSBVUkkncyBhdXRob3JpdHkgbG9vayBsaWtlIGEgZmFtaWxpYXIgYW5kIHRy dXN0ZWQKICAgICAgICAgIGRlc3RpbmF0aW9uLiBJbiBhZGRpdGlvbiwgaWYgdGhlIGF1dGhvcml6 YXRpb24gc2VydmVyIGFsbG93cyB0aGUgY2xpZW50IHRvIHJlZ2lzdGVyIG9ubHkKICAgICAgICAg IHBhcnQgb2YgdGhlIHJlZGlyZWN0aW9uIFVSSSwgYW4gYXR0YWNrZXIgY2FuIHVzZSBhbiBvcGVu IHJlZGlyZWN0b3Igb3BlcmF0ZWQgYnkgdGhlCiAgICAgICAgICBjbGllbnQgdG8gY29uc3RydWN0 IGEgcmVkaXJlY3Rpb24gVVJJIHRoYXQgd2lsbCBwYXNzIHRoZSBhdXRob3JpemF0aW9uIHNlcnZl ciB2YWxpZGF0aW9uCiAgICAgICAgICBidXQgd2lsbCBzZW5kIHRoZSBhdXRob3JpemF0aW9uIGNv ZGUgb3IgYWNjZXNzIHRva2VuIHRvIGFuIGVuZHBvaW50IHVuZGVyIHRoZSBjb250cm9sIG9mCiAg ICAgICAgICB0aGUgYXR0YWNrZXIuCiAgICAgICAgCjwvcD4KPGEgbmFtZT0iYW5jaG9yNDYiPjwv YT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNl bGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9 IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3Rh YmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi4xMSI+PC9hPjxoMz4xMS4mbmJzcDsKSUFOQSBDb25z aWRlcmF0aW9uczwvaDM+Cgo8YSBuYW1lPSJ0eXBlLXJlZ2lzdHJ5Ij48L2E+PGJyIC8+PGhyIC8+ Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIg Y2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhy ZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0i cmZjLnNlY3Rpb24uMTEuMSI+PC9hPjxoMz4xMS4xLiZuYnNwOwpUaGUgT0F1dGggQWNjZXNzIFRv a2VuIFR5cGUgUmVnaXN0cnk8L2gzPgoKPHA+CiAgICAgICAgICBUaGlzIHNwZWNpZmljYXRpb24g ZXN0YWJsaXNoZXMgdGhlIE9BdXRoIGFjY2VzcyB0b2tlbiB0eXBlIHJlZ2lzdHJ5LgogICAgICAg IAo8L3A+CjxwPgogICAgICAgICAgQWNjZXNzIHRva2VuIHR5cGVzIGFyZSByZWdpc3RlcmVkIHdp dGggYSBTcGVjaWZpY2F0aW9uIFJlcXVpcmVkCiAgICAgICAgICAoPGEgY2xhc3M9J2luZm8nIGhy ZWY9JyNSRkM1MjI2Jz5bUkZDNTIyNl08c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+ TmFydGVuLCBULiBhbmQgSC4gQWx2ZXN0cmFuZCwgJmxkcXVvO0d1aWRlbGluZXMgZm9yIFdyaXRp bmcgYW4gSUFOQSBDb25zaWRlcmF0aW9ucyBTZWN0aW9uIGluIFJGQ3MsJnJkcXVvOyBNYXkmbmJz cDsyMDA4Ljwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4pIGFmdGVyIGEgdHdvIHdlZWsgcmV2aWV3 IHBlcmlvZCBvbiB0aGUgW1RCRF1AaWV0Zi5vcmcgbWFpbGluZwogICAgICAgICAgbGlzdCwgb24g dGhlIGFkdmljZSBvZiBvbmUgb3IgbW9yZSBEZXNpZ25hdGVkIEV4cGVydHMuIEhvd2V2ZXIsIHRv IGFsbG93IGZvciB0aGUKICAgICAgICAgIGFsbG9jYXRpb24gb2YgdmFsdWVzIHByaW9yIHRvIHB1 YmxpY2F0aW9uLCB0aGUgRGVzaWduYXRlZCBFeHBlcnQocykgbWF5IGFwcHJvdmUKICAgICAgICAg IHJlZ2lzdHJhdGlvbiBvbmNlIHRoZXkgYXJlIHNhdGlzZmllZCB0aGF0IHN1Y2ggYSBzcGVjaWZp Y2F0aW9uIHdpbGwgYmUgcHVibGlzaGVkLgogICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgUmVn aXN0cmF0aW9uIHJlcXVlc3RzIG11c3QgYmUgc2VudCB0byB0aGUgW1RCRF1AaWV0Zi5vcmcgbWFp bGluZyBsaXN0IGZvciByZXZpZXcgYW5kCiAgICAgICAgICBjb21tZW50LCB3aXRoIGFuIGFwcHJv cHJpYXRlIHN1YmplY3QgKGUuZy4sICJSZXF1ZXN0IGZvciBhY2Nlc3MgdG9rZW4gdHlwZTogZXhh bXBsZSIpLgogICAgICAgICAgW1sgTm90ZSB0byBSRkMtRURJVE9SOiBUaGUgbmFtZSBvZiB0aGUg bWFpbGluZyBsaXN0IHNob3VsZCBiZSBkZXRlcm1pbmVkIGluIGNvbnN1bHRhdGlvbgogICAgICAg ICAgd2l0aCB0aGUgSUVTRyBhbmQgSUFOQS4gU3VnZ2VzdGVkIG5hbWU6IG9hdXRoLWV4dC1yZXZp ZXcuIF1dCiAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICBXaXRoaW4gdGhlIHJldmlldyBwZXJp b2QsIHRoZSBEZXNpZ25hdGVkIEV4cGVydChzKSB3aWxsIGVpdGhlciBhcHByb3ZlIG9yCiAgICAg ICAgICBkZW55IHRoZSByZWdpc3RyYXRpb24gcmVxdWVzdCwgY29tbXVuaWNhdGluZyB0aGlzIGRl Y2lzaW9uIHRvIHRoZSByZXZpZXcgbGlzdCBhbmQgSUFOQS4KICAgICAgICAgIERlbmlhbHMgc2hv dWxkIGluY2x1ZGUgYW4gZXhwbGFuYXRpb24gYW5kLCBpZiBhcHBsaWNhYmxlLCBzdWdnZXN0aW9u cyBhcyB0byBob3cgdG8gbWFrZQogICAgICAgICAgdGhlIHJlcXVlc3Qgc3VjY2Vzc2Z1bC4KICAg ICAgICAKPC9wPgo8cD4KICAgICAgICAgIElBTkEgbXVzdCBvbmx5IGFjY2VwdCByZWdpc3RyeSB1 cGRhdGVzIGZyb20gdGhlIERlc2lnbmF0ZWQgRXhwZXJ0KHMpLCBhbmQgc2hvdWxkIGRpcmVjdAog ICAgICAgICAgYWxsIHJlcXVlc3RzIGZvciByZWdpc3RyYXRpb24gdG8gdGhlIHJldmlldyBtYWls aW5nIGxpc3QuCiAgICAgICAgCjwvcD4KPGEgbmFtZT0iYW5jaG9yNDciPjwvYT48YnIgLz48aHIg Lz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIy IiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEg aHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1l PSJyZmMuc2VjdGlvbi4xMS4xLjEiPjwvYT48aDM+MTEuMS4xLiZuYnNwOwpSZWdpc3RyYXRpb24g VGVtcGxhdGU8L2gzPgoKPHA+CiAgICAgICAgICAgIDwvcD4KPGJsb2NrcXVvdGUgY2xhc3M9InRl eHQiPjxkbD4KPGR0PlR5cGUgbmFtZTo8L2R0Pgo8ZGQ+CiAgICAgICAgICAgICAgICAKICAgICAg ICAgICAgICAgIFRoZSBuYW1lIHJlcXVlc3RlZCAoZS5nLiwgImV4YW1wbGUiKS4KICAgICAgICAg ICAgICAKPC9kZD4KPGR0PkFkZGl0aW9uYWwgVG9rZW4gRW5kcG9pbnQgUmVzcG9uc2UgUGFyYW1l dGVyczo8L2R0Pgo8ZGQ+CiAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgIEFkZGl0aW9u YWwgcmVzcG9uc2UgcGFyYW1ldGVycyByZXR1cm5lZCB0b2dldGhlciB3aXRoIHRoZQogICAgICAg ICAgICAgICAgPHR0PmFjY2Vzc190b2tlbjwvdHQ+IHBhcmFtZXRlci4gTmV3IHBhcmFtZXRlcnMg TVVTVCBiZQogICAgICAgICAgICAgICAgc2VwYXJhdGVseSByZWdpc3RlcmVkIGluIHRoZSBPQXV0 aCBwYXJhbWV0ZXJzIHJlZ2lzdHJ5IGFzIGRlc2NyaWJlZCBieQogICAgICAgICAgICAgICAgPGEg Y2xhc3M9J2luZm8nIGhyZWY9JyNwYXJhbWV0ZXJzLXJlZ2lzdHJ5Jz5TZWN0aW9uJm5ic3A7MTEu MjxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5UaGUgT0F1dGggUGFyYW1ldGVycyBS ZWdpc3RyeTwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4uCiAgICAgICAgICAgICAgCjwvZGQ+Cjxk dD5IVFRQIEF1dGhlbnRpY2F0aW9uIFNjaGVtZShzKTo8L2R0Pgo8ZGQ+CiAgICAgICAgICAgICAg ICAKICAgICAgICAgICAgICAgIFRoZSBIVFRQIGF1dGhlbnRpY2F0aW9uIHNjaGVtZSBuYW1lKHMp LCBpZiBhbnksIHVzZWQgdG8gYXV0aGVudGljYXRlIHByb3RlY3RlZAogICAgICAgICAgICAgICAg cmVzb3VyY2VzIHJlcXVlc3RzIHVzaW5nIGFjY2VzcyB0b2tlbnMgb2YgdGhpcyB0eXBlLgogICAg ICAgICAgICAgIAo8L2RkPgo8ZHQ+Q2hhbmdlIGNvbnRyb2xsZXI6PC9kdD4KPGRkPgogICAgICAg ICAgICAgICAgCiAgICAgICAgICAgICAgICBGb3Igc3RhbmRhcmRzLXRyYWNrIFJGQ3MsIHN0YXRl ICJJRVRGIi4gRm9yIG90aGVycywgZ2l2ZSB0aGUgbmFtZSBvZiB0aGUKICAgICAgICAgICAgICAg IHJlc3BvbnNpYmxlIHBhcnR5LiBPdGhlciBkZXRhaWxzIChlLmcuLCBwb3N0YWwgYWRkcmVzcywg ZS1tYWlsIGFkZHJlc3MsIGhvbWUgcGFnZQogICAgICAgICAgICAgICAgVVJJKSBtYXkgYWxzbyBi ZSBpbmNsdWRlZC4KICAgICAgICAgICAgICAKPC9kZD4KPGR0PlNwZWNpZmljYXRpb24gZG9jdW1l bnQocyk6PC9kdD4KPGRkPgogICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICBSZWZlcmVu Y2UgdG8gdGhlIGRvY3VtZW50IHRoYXQgc3BlY2lmaWVzIHRoZSBwYXJhbWV0ZXIsIHByZWZlcmFi bHkgaW5jbHVkaW5nIGEgVVJJIHRoYXQKICAgICAgICAgICAgICAgIGNhbiBiZSB1c2VkIHRvIHJl dHJpZXZlIGEgY29weSBvZiB0aGUgZG9jdW1lbnQuIEFuIGluZGljYXRpb24gb2YgdGhlIHJlbGV2 YW50CiAgICAgICAgICAgICAgICBzZWN0aW9ucyBtYXkgYWxzbyBiZSBpbmNsdWRlZCwgYnV0IGlz IG5vdCByZXF1aXJlZC4KICAgICAgICAgICAgICAKPC9kZD4KPC9kbD48L2Jsb2NrcXVvdGU+PHA+ CiAgICAgICAgICAKPC9wPgo8YSBuYW1lPSJwYXJhbWV0ZXJzLXJlZ2lzdHJ5Ij48L2E+PGJyIC8+ PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2lu Zz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWci PjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEg bmFtZT0icmZjLnNlY3Rpb24uMTEuMiI+PC9hPjxoMz4xMS4yLiZuYnNwOwpUaGUgT0F1dGggUGFy YW1ldGVycyBSZWdpc3RyeTwvaDM+Cgo8cD4KICAgICAgICAgIFRoaXMgc3BlY2lmaWNhdGlvbiBl c3RhYmxpc2hlcyB0aGUgT0F1dGggcGFyYW1ldGVycyByZWdpc3RyeS4KICAgICAgICAKPC9wPgo8 cD4KICAgICAgICAgIEFkZGl0aW9uYWwgcGFyYW1ldGVycyBmb3IgaW5jbHVzaW9uIGluIHRoZSBh dXRob3JpemF0aW9uIGVuZHBvaW50IHJlcXVlc3QsIHRoZQogICAgICAgICAgYXV0aG9yaXphdGlv biBlbmRwb2ludCByZXNwb25zZSwgdGhlIHRva2VuIGVuZHBvaW50IHJlcXVlc3QsIG9yIHRoZSB0 b2tlbiBlbmRwb2ludAogICAgICAgICAgcmVzcG9uc2UgYXJlIHJlZ2lzdGVyZWQgd2l0aCBhIFNw ZWNpZmljYXRpb24gUmVxdWlyZWQKICAgICAgICAgICg8YSBjbGFzcz0naW5mbycgaHJlZj0nI1JG QzUyMjYnPltSRkM1MjI2XTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5OYXJ0ZW4s IFQuIGFuZCBILiBBbHZlc3RyYW5kLCAmbGRxdW87R3VpZGVsaW5lcyBmb3IgV3JpdGluZyBhbiBJ QU5BIENvbnNpZGVyYXRpb25zIFNlY3Rpb24gaW4gUkZDcywmcmRxdW87IE1heSZuYnNwOzIwMDgu PC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPikgYWZ0ZXIgYSB0d28gd2VlayByZXZpZXcgcGVyaW9k IG9uIHRoZSBbVEJEXUBpZXRmLm9yZyBtYWlsaW5nCiAgICAgICAgICBsaXN0LCBvbiB0aGUgYWR2 aWNlIG9mIG9uZSBvciBtb3JlIERlc2lnbmF0ZWQgRXhwZXJ0cy4gSG93ZXZlciwgdG8gYWxsb3cg Zm9yIHRoZQogICAgICAgICAgYWxsb2NhdGlvbiBvZiB2YWx1ZXMgcHJpb3IgdG8gcHVibGljYXRp b24sIHRoZSBEZXNpZ25hdGVkIEV4cGVydChzKSBtYXkgYXBwcm92ZQogICAgICAgICAgcmVnaXN0 cmF0aW9uIG9uY2UgdGhleSBhcmUgc2F0aXNmaWVkIHRoYXQgc3VjaCBhIHNwZWNpZmljYXRpb24g d2lsbCBiZSBwdWJsaXNoZWQuCiAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICBSZWdpc3RyYXRp b24gcmVxdWVzdHMgbXVzdCBiZSBzZW50IHRvIHRoZSBbVEJEXUBpZXRmLm9yZyBtYWlsaW5nIGxp c3QgZm9yIHJldmlldyBhbmQKICAgICAgICAgIGNvbW1lbnQsIHdpdGggYW4gYXBwcm9wcmlhdGUg c3ViamVjdCAoZS5nLiwgIlJlcXVlc3QgZm9yIHBhcmFtZXRlcjogZXhhbXBsZSIpLgogICAgICAg ICAgW1sgTm90ZSB0byBSRkMtRURJVE9SOiBUaGUgbmFtZSBvZiB0aGUgbWFpbGluZyBsaXN0IHNo b3VsZCBiZSBkZXRlcm1pbmVkIGluIGNvbnN1bHRhdGlvbgogICAgICAgICAgd2l0aCB0aGUgSUVT RyBhbmQgSUFOQS4gU3VnZ2VzdGVkIG5hbWU6IG9hdXRoLWV4dC1yZXZpZXcuIF1dCiAgICAgICAg CjwvcD4KPHA+CiAgICAgICAgICBXaXRoaW4gdGhlIHJldmlldyBwZXJpb2QsIHRoZSBEZXNpZ25h dGVkIEV4cGVydChzKSB3aWxsIGVpdGhlciBhcHByb3ZlIG9yCiAgICAgICAgICBkZW55IHRoZSBy ZWdpc3RyYXRpb24gcmVxdWVzdCwgY29tbXVuaWNhdGluZyB0aGlzIGRlY2lzaW9uIHRvIHRoZSBy ZXZpZXcgbGlzdCBhbmQgSUFOQS4KICAgICAgICAgIERlbmlhbHMgc2hvdWxkIGluY2x1ZGUgYW4g ZXhwbGFuYXRpb24gYW5kLCBpZiBhcHBsaWNhYmxlLCBzdWdnZXN0aW9ucyBhcyB0byBob3cgdG8g bWFrZQogICAgICAgICAgdGhlIHJlcXVlc3Qgc3VjY2Vzc2Z1bC4KICAgICAgICAKPC9wPgo8cD4K ICAgICAgICAgIElBTkEgbXVzdCBvbmx5IGFjY2VwdCByZWdpc3RyeSB1cGRhdGVzIGZyb20gdGhl IERlc2lnbmF0ZWQgRXhwZXJ0KHMpLCBhbmQgc2hvdWxkIGRpcmVjdAogICAgICAgICAgYWxsIHJl cXVlc3RzIGZvciByZWdpc3RyYXRpb24gdG8gdGhlIHJldmlldyBtYWlsaW5nIGxpc3QuCiAgICAg ICAgCjwvcD4KPGEgbmFtZT0iYW5jaG9yNDgiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1h cnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVn IiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5i c3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi4x MS4yLjEiPjwvYT48aDM+MTEuMi4xLiZuYnNwOwpSZWdpc3RyYXRpb24gVGVtcGxhdGU8L2gzPgoK PHA+CiAgICAgICAgICAgIDwvcD4KPGJsb2NrcXVvdGUgY2xhc3M9InRleHQiPjxkbD4KPGR0PlBh cmFtZXRlciBuYW1lOjwvZHQ+CjxkZD4KICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAg VGhlIG5hbWUgcmVxdWVzdGVkIChlLmcuLCAiZXhhbXBsZSIpLgogICAgICAgICAgICAgIAo8L2Rk Pgo8ZHQ+UGFyYW1ldGVyIHVzYWdlIGxvY2F0aW9uOjwvZHQ+CjxkZD4KICAgICAgICAgICAgICAg IAogICAgICAgICAgICAgICAgVGhlIGxvY2F0aW9uKHMpIHdoZXJlIHBhcmFtZXRlciBjYW4gYmUg dXNlZC4gVGhlIHBvc3NpYmxlIGxvY2F0aW9ucyBhcmU6CiAgICAgICAgICAgICAgICBhdXRob3Jp emF0aW9uIHJlcXVlc3QsIGF1dGhvcml6YXRpb24gcmVzcG9uc2UsIHRva2VuIHJlcXVlc3QsIG9y IHRva2VuIHJlc3BvbnNlLgogICAgICAgICAgICAgIAo8L2RkPgo8ZHQ+Q2hhbmdlIGNvbnRyb2xs ZXI6PC9kdD4KPGRkPgogICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICBGb3Igc3RhbmRh cmRzLXRyYWNrIFJGQ3MsIHN0YXRlICJJRVRGIi4gRm9yIG90aGVycywgZ2l2ZSB0aGUgbmFtZSBv ZiB0aGUKICAgICAgICAgICAgICAgIHJlc3BvbnNpYmxlIHBhcnR5LiBPdGhlciBkZXRhaWxzIChl LmcuLCBwb3N0YWwgYWRkcmVzcywgZS1tYWlsIGFkZHJlc3MsIGhvbWUgcGFnZQogICAgICAgICAg ICAgICAgVVJJKSBtYXkgYWxzbyBiZSBpbmNsdWRlZC4KICAgICAgICAgICAgICAKPC9kZD4KPGR0 PlNwZWNpZmljYXRpb24gZG9jdW1lbnQocyk6PC9kdD4KPGRkPgogICAgICAgICAgICAgICAgCiAg ICAgICAgICAgICAgICBSZWZlcmVuY2UgdG8gdGhlIGRvY3VtZW50IHRoYXQgc3BlY2lmaWVzIHRo ZSBwYXJhbWV0ZXIsIHByZWZlcmFibHkgaW5jbHVkaW5nIGEgVVJJIHRoYXQKICAgICAgICAgICAg ICAgIGNhbiBiZSB1c2VkIHRvIHJldHJpZXZlIGEgY29weSBvZiB0aGUgZG9jdW1lbnQuIEFuIGlu ZGljYXRpb24gb2YgdGhlIHJlbGV2YW50CiAgICAgICAgICAgICAgICBzZWN0aW9ucyBtYXkgYWxz byBiZSBpbmNsdWRlZCwgYnV0IGlzIG5vdCByZXF1aXJlZC4KICAgICAgICAgICAgICAKPC9kZD4K PC9kbD48L2Jsb2NrcXVvdGU+PHA+CiAgICAgICAgICAKPC9wPgo8YSBuYW1lPSJhbmNob3I0OSI+ PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIg Y2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFz cz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwv dGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLjExLjIuMiI+PC9hPjxoMz4xMS4yLjIuJm5ic3A7 CkluaXRpYWwgUmVnaXN0cnkgQ29udGVudHM8L2gzPgoKPHA+CiAgICAgICAgICAgIFRoZSBPQXV0 aCBQYXJhbWV0ZXJzIFJlZ2lzdHJ5J3MgaW5pdGlhbCBjb250ZW50cyBhcmU6CiAgICAgICAgICAK PC9wPgo8cD4KICAgICAgICAgICAgPC9wPgo8dWwgY2xhc3M9InRleHQiPgo8bGk+CiAgICAgICAg ICAgICAgICBQYXJhbWV0ZXIgbmFtZTogY2xpZW50X2lkCiAgICAgICAgICAgICAgCjwvbGk+Cjxs aT4KICAgICAgICAgICAgICAgIFBhcmFtZXRlciB1c2FnZSBsb2NhdGlvbjogYXV0aG9yaXphdGlv biByZXF1ZXN0LCB0b2tlbiByZXF1ZXN0CiAgICAgICAgICAgICAgCjwvbGk+CjxsaT4KICAgICAg ICAgICAgICAgIENoYW5nZSBjb250cm9sbGVyOiBJRVRGCiAgICAgICAgICAgICAgCjwvbGk+Cjxs aT4KICAgICAgICAgICAgICAgIFNwZWNpZmljYXRpb24gZG9jdW1lbnQocyk6IFtbIHRoaXMgZG9j dW1lbnQgXV0KICAgICAgICAgICAgICAKPC9saT4KPC91bD48cD4KICAgICAgICAgIAo8L3A+Cjxw PgogICAgICAgICAgICA8L3A+Cjx1bCBjbGFzcz0idGV4dCI+CjxsaT4KICAgICAgICAgICAgICAg IFBhcmFtZXRlciBuYW1lOiBjbGllbnRfc2VjcmV0CiAgICAgICAgICAgICAgCjwvbGk+CjxsaT4K ICAgICAgICAgICAgICAgIFBhcmFtZXRlciB1c2FnZSBsb2NhdGlvbjogdG9rZW4gcmVxdWVzdAog ICAgICAgICAgICAgIAo8L2xpPgo8bGk+CiAgICAgICAgICAgICAgICBDaGFuZ2UgY29udHJvbGxl cjogSUVURgogICAgICAgICAgICAgIAo8L2xpPgo8bGk+CiAgICAgICAgICAgICAgICBTcGVjaWZp Y2F0aW9uIGRvY3VtZW50KHMpOiBbWyB0aGlzIGRvY3VtZW50IF1dCiAgICAgICAgICAgICAgCjwv bGk+CjwvdWw+PHA+CiAgICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgICAgPC9wPgo8dWwgY2xh c3M9InRleHQiPgo8bGk+CiAgICAgICAgICAgICAgICBQYXJhbWV0ZXIgbmFtZTogcmVzcG9uc2Vf dHlwZQogICAgICAgICAgICAgIAo8L2xpPgo8bGk+CiAgICAgICAgICAgICAgICBQYXJhbWV0ZXIg dXNhZ2UgbG9jYXRpb246IGF1dGhvcml6YXRpb24gcmVxdWVzdAogICAgICAgICAgICAgIAo8L2xp Pgo8bGk+CiAgICAgICAgICAgICAgICBDaGFuZ2UgY29udHJvbGxlcjogSUVURgogICAgICAgICAg ICAgIAo8L2xpPgo8bGk+CiAgICAgICAgICAgICAgICBTcGVjaWZpY2F0aW9uIGRvY3VtZW50KHMp OiBbWyB0aGlzIGRvY3VtZW50IF1dCiAgICAgICAgICAgICAgCjwvbGk+CjwvdWw+PHA+CiAgICAg ICAgICAKPC9wPgo8cD4KICAgICAgICAgICAgPC9wPgo8dWwgY2xhc3M9InRleHQiPgo8bGk+CiAg ICAgICAgICAgICAgICBQYXJhbWV0ZXIgbmFtZTogcmVkaXJlY3RfdXJpCiAgICAgICAgICAgICAg CjwvbGk+CjxsaT4KICAgICAgICAgICAgICAgIFBhcmFtZXRlciB1c2FnZSBsb2NhdGlvbjogYXV0 aG9yaXphdGlvbiByZXF1ZXN0LCB0b2tlbiByZXF1ZXN0CiAgICAgICAgICAgICAgCjwvbGk+Cjxs aT4KICAgICAgICAgICAgICAgIENoYW5nZSBjb250cm9sbGVyOiBJRVRGCiAgICAgICAgICAgICAg CjwvbGk+CjxsaT4KICAgICAgICAgICAgICAgIFNwZWNpZmljYXRpb24gZG9jdW1lbnQocyk6IFtb IHRoaXMgZG9jdW1lbnQgXV0KICAgICAgICAgICAgICAKPC9saT4KPC91bD48cD4KICAgICAgICAg IAo8L3A+CjxwPgogICAgICAgICAgICA8L3A+Cjx1bCBjbGFzcz0idGV4dCI+CjxsaT4KICAgICAg ICAgICAgICAgIFBhcmFtZXRlciBuYW1lOiBzY29wZQogICAgICAgICAgICAgIAo8L2xpPgo8bGk+ CiAgICAgICAgICAgICAgICBQYXJhbWV0ZXIgdXNhZ2UgbG9jYXRpb246IGF1dGhvcml6YXRpb24g cmVxdWVzdCwgYXV0aG9yaXphdGlvbiByZXNwb25zZSwgdG9rZW4KICAgICAgICAgICAgICAgIHJl cXVlc3QsIHRva2VuIHJlc3BvbnNlCiAgICAgICAgICAgICAgCjwvbGk+CjxsaT4KICAgICAgICAg ICAgICAgIENoYW5nZSBjb250cm9sbGVyOiBJRVRGCiAgICAgICAgICAgICAgCjwvbGk+CjxsaT4K ICAgICAgICAgICAgICAgIFNwZWNpZmljYXRpb24gZG9jdW1lbnQocyk6IFtbIHRoaXMgZG9jdW1l bnQgXV0KICAgICAgICAgICAgICAKPC9saT4KPC91bD48cD4KICAgICAgICAgIAo8L3A+CjxwPgog ICAgICAgICAgICA8L3A+Cjx1bCBjbGFzcz0idGV4dCI+CjxsaT4KICAgICAgICAgICAgICAgIFBh cmFtZXRlciBuYW1lOiBzdGF0ZQogICAgICAgICAgICAgIAo8L2xpPgo8bGk+CiAgICAgICAgICAg ICAgICBQYXJhbWV0ZXIgdXNhZ2UgbG9jYXRpb246IGF1dGhvcml6YXRpb24gcmVxdWVzdCwgYXV0 aG9yaXphdGlvbiByZXNwb25zZQogICAgICAgICAgICAgIAo8L2xpPgo8bGk+CiAgICAgICAgICAg ICAgICBDaGFuZ2UgY29udHJvbGxlcjogSUVURgogICAgICAgICAgICAgIAo8L2xpPgo8bGk+CiAg ICAgICAgICAgICAgICBTcGVjaWZpY2F0aW9uIGRvY3VtZW50KHMpOiBbWyB0aGlzIGRvY3VtZW50 IF1dCiAgICAgICAgICAgICAgCjwvbGk+CjwvdWw+PHA+CiAgICAgICAgICAKPC9wPgo8cD4KICAg ICAgICAgICAgPC9wPgo8dWwgY2xhc3M9InRleHQiPgo8bGk+CiAgICAgICAgICAgICAgICBQYXJh bWV0ZXIgbmFtZTogY29kZQogICAgICAgICAgICAgIAo8L2xpPgo8bGk+CiAgICAgICAgICAgICAg ICBQYXJhbWV0ZXIgdXNhZ2UgbG9jYXRpb246IGF1dGhvcml6YXRpb24gcmVzcG9uc2UsIHRva2Vu IHJlcXVlc3QKICAgICAgICAgICAgICAKPC9saT4KPGxpPgogICAgICAgICAgICAgICAgQ2hhbmdl IGNvbnRyb2xsZXI6IElFVEYKICAgICAgICAgICAgICAKPC9saT4KPGxpPgogICAgICAgICAgICAg ICAgU3BlY2lmaWNhdGlvbiBkb2N1bWVudChzKTogW1sgdGhpcyBkb2N1bWVudCBdXQogICAgICAg ICAgICAgIAo8L2xpPgo8L3VsPjxwPgogICAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICAgIDwv cD4KPHVsIGNsYXNzPSJ0ZXh0Ij4KPGxpPgogICAgICAgICAgICAgICAgUGFyYW1ldGVyIG5hbWU6 IGVycm9yX2Rlc2NyaXB0aW9uCiAgICAgICAgICAgICAgCjwvbGk+CjxsaT4KICAgICAgICAgICAg ICAgIFBhcmFtZXRlciB1c2FnZSBsb2NhdGlvbjogYXV0aG9yaXphdGlvbiByZXNwb25zZSwgdG9r ZW4gcmVzcG9uc2UKICAgICAgICAgICAgICAKPC9saT4KPGxpPgogICAgICAgICAgICAgICAgQ2hh bmdlIGNvbnRyb2xsZXI6IElFVEYKICAgICAgICAgICAgICAKPC9saT4KPGxpPgogICAgICAgICAg ICAgICAgU3BlY2lmaWNhdGlvbiBkb2N1bWVudChzKTogW1sgdGhpcyBkb2N1bWVudCBdXQogICAg ICAgICAgICAgIAo8L2xpPgo8L3VsPjxwPgogICAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICAg IDwvcD4KPHVsIGNsYXNzPSJ0ZXh0Ij4KPGxpPgogICAgICAgICAgICAgICAgUGFyYW1ldGVyIG5h bWU6IGVycm9yX3VyaQogICAgICAgICAgICAgIAo8L2xpPgo8bGk+CiAgICAgICAgICAgICAgICBQ YXJhbWV0ZXIgdXNhZ2UgbG9jYXRpb246IGF1dGhvcml6YXRpb24gcmVzcG9uc2UsIHRva2VuIHJl c3BvbnNlCiAgICAgICAgICAgICAgCjwvbGk+CjxsaT4KICAgICAgICAgICAgICAgIENoYW5nZSBj b250cm9sbGVyOiBJRVRGCiAgICAgICAgICAgICAgCjwvbGk+CjxsaT4KICAgICAgICAgICAgICAg IFNwZWNpZmljYXRpb24gZG9jdW1lbnQocyk6IFtbIHRoaXMgZG9jdW1lbnQgXV0KICAgICAgICAg ICAgICAKPC9saT4KPC91bD48cD4KICAgICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgICA8L3A+ Cjx1bCBjbGFzcz0idGV4dCI+CjxsaT4KICAgICAgICAgICAgICAgIFBhcmFtZXRlciBuYW1lOiBn cmFudF90eXBlCiAgICAgICAgICAgICAgCjwvbGk+CjxsaT4KICAgICAgICAgICAgICAgIFBhcmFt ZXRlciB1c2FnZSBsb2NhdGlvbjogdG9rZW4gcmVxdWVzdAogICAgICAgICAgICAgIAo8L2xpPgo8 bGk+CiAgICAgICAgICAgICAgICBDaGFuZ2UgY29udHJvbGxlcjogSUVURgogICAgICAgICAgICAg IAo8L2xpPgo8bGk+CiAgICAgICAgICAgICAgICBTcGVjaWZpY2F0aW9uIGRvY3VtZW50KHMpOiBb WyB0aGlzIGRvY3VtZW50IF1dCiAgICAgICAgICAgICAgCjwvbGk+CjwvdWw+PHA+CiAgICAgICAg ICAKPC9wPgo8cD4KICAgICAgICAgICAgPC9wPgo8dWwgY2xhc3M9InRleHQiPgo8bGk+CiAgICAg ICAgICAgICAgICBQYXJhbWV0ZXIgbmFtZTogYWNjZXNzX3Rva2VuCiAgICAgICAgICAgICAgCjwv bGk+CjxsaT4KICAgICAgICAgICAgICAgIFBhcmFtZXRlciB1c2FnZSBsb2NhdGlvbjogYXV0aG9y aXphdGlvbiByZXNwb25zZSwgdG9rZW4gcmVzcG9uc2UKICAgICAgICAgICAgICAKPC9saT4KPGxp PgogICAgICAgICAgICAgICAgQ2hhbmdlIGNvbnRyb2xsZXI6IElFVEYKICAgICAgICAgICAgICAK PC9saT4KPGxpPgogICAgICAgICAgICAgICAgU3BlY2lmaWNhdGlvbiBkb2N1bWVudChzKTogW1sg dGhpcyBkb2N1bWVudCBdXQogICAgICAgICAgICAgIAo8L2xpPgo8L3VsPjxwPgogICAgICAgICAg CjwvcD4KPHA+CiAgICAgICAgICAgIDwvcD4KPHVsIGNsYXNzPSJ0ZXh0Ij4KPGxpPgogICAgICAg ICAgICAgICAgUGFyYW1ldGVyIG5hbWU6IHRva2VuX3R5cGUKICAgICAgICAgICAgICAKPC9saT4K PGxpPgogICAgICAgICAgICAgICAgUGFyYW1ldGVyIHVzYWdlIGxvY2F0aW9uOiBhdXRob3JpemF0 aW9uIHJlc3BvbnNlLCB0b2tlbiByZXNwb25zZQogICAgICAgICAgICAgIAo8L2xpPgo8bGk+CiAg ICAgICAgICAgICAgICBDaGFuZ2UgY29udHJvbGxlcjogSUVURgogICAgICAgICAgICAgIAo8L2xp Pgo8bGk+CiAgICAgICAgICAgICAgICBTcGVjaWZpY2F0aW9uIGRvY3VtZW50KHMpOiBbWyB0aGlz IGRvY3VtZW50IF1dCiAgICAgICAgICAgICAgCjwvbGk+CjwvdWw+PHA+CiAgICAgICAgICAKPC9w Pgo8cD4KICAgICAgICAgICAgPC9wPgo8dWwgY2xhc3M9InRleHQiPgo8bGk+CiAgICAgICAgICAg ICAgICBQYXJhbWV0ZXIgbmFtZTogZXhwaXJlc19pbgogICAgICAgICAgICAgIAo8L2xpPgo8bGk+ CiAgICAgICAgICAgICAgICBQYXJhbWV0ZXIgdXNhZ2UgbG9jYXRpb246IGF1dGhvcml6YXRpb24g cmVzcG9uc2UsIHRva2VuIHJlc3BvbnNlCiAgICAgICAgICAgICAgCjwvbGk+CjxsaT4KICAgICAg ICAgICAgICAgIENoYW5nZSBjb250cm9sbGVyOiBJRVRGCiAgICAgICAgICAgICAgCjwvbGk+Cjxs aT4KICAgICAgICAgICAgICAgIFNwZWNpZmljYXRpb24gZG9jdW1lbnQocyk6IFtbIHRoaXMgZG9j dW1lbnQgXV0KICAgICAgICAgICAgICAKPC9saT4KPC91bD48cD4KICAgICAgICAgIAo8L3A+Cjxw PgogICAgICAgICAgICA8L3A+Cjx1bCBjbGFzcz0idGV4dCI+CjxsaT4KICAgICAgICAgICAgICAg IFBhcmFtZXRlciBuYW1lOiB1c2VybmFtZQogICAgICAgICAgICAgIAo8L2xpPgo8bGk+CiAgICAg ICAgICAgICAgICBQYXJhbWV0ZXIgdXNhZ2UgbG9jYXRpb246IHRva2VuIHJlcXVlc3QKICAgICAg ICAgICAgICAKPC9saT4KPGxpPgogICAgICAgICAgICAgICAgQ2hhbmdlIGNvbnRyb2xsZXI6IElF VEYKICAgICAgICAgICAgICAKPC9saT4KPGxpPgogICAgICAgICAgICAgICAgU3BlY2lmaWNhdGlv biBkb2N1bWVudChzKTogW1sgdGhpcyBkb2N1bWVudCBdXQogICAgICAgICAgICAgIAo8L2xpPgo8 L3VsPjxwPgogICAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICAgIDwvcD4KPHVsIGNsYXNzPSJ0 ZXh0Ij4KPGxpPgogICAgICAgICAgICAgICAgUGFyYW1ldGVyIG5hbWU6IHBhc3N3b3JkCiAgICAg ICAgICAgICAgCjwvbGk+CjxsaT4KICAgICAgICAgICAgICAgIFBhcmFtZXRlciB1c2FnZSBsb2Nh dGlvbjogdG9rZW4gcmVxdWVzdAogICAgICAgICAgICAgIAo8L2xpPgo8bGk+CiAgICAgICAgICAg ICAgICBDaGFuZ2UgY29udHJvbGxlcjogSUVURgogICAgICAgICAgICAgIAo8L2xpPgo8bGk+CiAg ICAgICAgICAgICAgICBTcGVjaWZpY2F0aW9uIGRvY3VtZW50KHMpOiBbWyB0aGlzIGRvY3VtZW50 IF1dCiAgICAgICAgICAgICAgCjwvbGk+CjwvdWw+PHA+CiAgICAgICAgICAKPC9wPgo8cD4KICAg ICAgICAgICAgPC9wPgo8dWwgY2xhc3M9InRleHQiPgo8bGk+CiAgICAgICAgICAgICAgICBQYXJh bWV0ZXIgbmFtZTogcmVmcmVzaF90b2tlbgogICAgICAgICAgICAgIAo8L2xpPgo8bGk+CiAgICAg ICAgICAgICAgICBQYXJhbWV0ZXIgdXNhZ2UgbG9jYXRpb246IHRva2VuIHJlcXVlc3QsIHRva2Vu IHJlc3BvbnNlCiAgICAgICAgICAgICAgCjwvbGk+CjxsaT4KICAgICAgICAgICAgICAgIENoYW5n ZSBjb250cm9sbGVyOiBJRVRGCiAgICAgICAgICAgICAgCjwvbGk+CjxsaT4KICAgICAgICAgICAg ICAgIFNwZWNpZmljYXRpb24gZG9jdW1lbnQocyk6IFtbIHRoaXMgZG9jdW1lbnQgXV0KICAgICAg ICAgICAgICAKPC9saT4KPC91bD48cD4KICAgICAgICAgIAo8L3A+CjxhIG5hbWU9InJlc3BvbnNl LXR5cGUtcmVnaXN0cnkiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIg Y2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmln aHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7 PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi4xMS4zIj48L2E+PGgz PjExLjMuJm5ic3A7ClRoZSBPQXV0aCBBdXRob3JpemF0aW9uIEVuZHBvaW50IFJlc3BvbnNlIFR5 cGUgUmVnaXN0cnk8L2gzPgoKPHA+CiAgICAgICAgICBUaGlzIHNwZWNpZmljYXRpb24gZXN0YWJs aXNoZXMgdGhlIE9BdXRoIGF1dGhvcml6YXRpb24gZW5kcG9pbnQgcmVzcG9uc2UgdHlwZSByZWdp c3RyeS4KICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgICAgQWRkaXRpb25hbCByZXNwb25zZSB0 eXBlIGZvciB1c2Ugd2l0aCB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludCBhcmUgcmVnaXN0ZXJl ZCB3aXRoIGEKICAgICAgICAgICAgU3BlY2lmaWNhdGlvbiBSZXF1aXJlZCAoPGEgY2xhc3M9J2lu Zm8nIGhyZWY9JyNSRkM1MjI2Jz5bUkZDNTIyNl08c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0n aW5mbyc+TmFydGVuLCBULiBhbmQgSC4gQWx2ZXN0cmFuZCwgJmxkcXVvO0d1aWRlbGluZXMgZm9y IFdyaXRpbmcgYW4gSUFOQSBDb25zaWRlcmF0aW9ucyBTZWN0aW9uIGluIFJGQ3MsJnJkcXVvOyBN YXkmbmJzcDsyMDA4Ljwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4pIGFmdGVyIGEgdHdvIHdlZWsg cmV2aWV3IHBlcmlvZCBvbgogICAgICAgICAgICB0aGUgW1RCRF1AaWV0Zi5vcmcgbWFpbGluZyBs aXN0LCBvbiB0aGUgYWR2aWNlIG9mIG9uZSBvciBtb3JlIERlc2lnbmF0ZWQgRXhwZXJ0cy4KICAg ICAgICAgICAgSG93ZXZlciwgdG8gYWxsb3cgZm9yIHRoZSBhbGxvY2F0aW9uIG9mIHZhbHVlcyBw cmlvciB0byBwdWJsaWNhdGlvbiwgdGhlIERlc2lnbmF0ZWQKICAgICAgICAgICAgRXhwZXJ0KHMp IG1heSBhcHByb3ZlIHJlZ2lzdHJhdGlvbiBvbmNlIHRoZXkgYXJlIHNhdGlzZmllZCB0aGF0IHN1 Y2ggYSBzcGVjaWZpY2F0aW9uCiAgICAgICAgICAgIHdpbGwgYmUgcHVibGlzaGVkLgogICAgICAg ICAgCjwvcD4KPHA+CiAgICAgICAgICAgIFJlZ2lzdHJhdGlvbiByZXF1ZXN0cyBtdXN0IGJlIHNl bnQgdG8gdGhlIFtUQkRdQGlldGYub3JnIG1haWxpbmcgbGlzdCBmb3IgcmV2aWV3IGFuZAogICAg ICAgICAgICBjb21tZW50LCB3aXRoIGFuIGFwcHJvcHJpYXRlIHN1YmplY3QgKGUuZy4sICJSZXF1 ZXN0IGZvciByZXNwb25zZSB0eXBlOiBleGFtcGxlIikuCiAgICAgICAgICAgIFtbIE5vdGUgdG8g UkZDLUVESVRPUjogVGhlIG5hbWUgb2YgdGhlIG1haWxpbmcgbGlzdCBzaG91bGQgYmUgZGV0ZXJt aW5lZCBpbiBjb25zdWx0YXRpb24KICAgICAgICAgICAgd2l0aCB0aGUgSUVTRyBhbmQgSUFOQS4g U3VnZ2VzdGVkIG5hbWU6IG9hdXRoLWV4dC1yZXZpZXcuIF1dCiAgICAgICAgICAKPC9wPgo8cD4K ICAgICAgICAgICAgV2l0aGluIHRoZSByZXZpZXcgcGVyaW9kLCB0aGUgRGVzaWduYXRlZCBFeHBl cnQocykgd2lsbCBlaXRoZXIgYXBwcm92ZSBvcgogICAgICAgICAgICBkZW55IHRoZSByZWdpc3Ry YXRpb24gcmVxdWVzdCwgY29tbXVuaWNhdGluZyB0aGlzIGRlY2lzaW9uIHRvIHRoZSByZXZpZXcg bGlzdCBhbmQgSUFOQS4KICAgICAgICAgICAgRGVuaWFscyBzaG91bGQgaW5jbHVkZSBhbiBleHBs YW5hdGlvbiBhbmQsIGlmIGFwcGxpY2FibGUsIHN1Z2dlc3Rpb25zIGFzIHRvIGhvdyB0byBtYWtl CiAgICAgICAgICAgIHRoZSByZXF1ZXN0IHN1Y2Nlc3NmdWwuCiAgICAgICAgICAKPC9wPgo8cD4K ICAgICAgICAgICAgSUFOQSBtdXN0IG9ubHkgYWNjZXB0IHJlZ2lzdHJ5IHVwZGF0ZXMgZnJvbSB0 aGUgRGVzaWduYXRlZCBFeHBlcnQocyksIGFuZCBzaG91bGQgZGlyZWN0CiAgICAgICAgICAgIGFs bCByZXF1ZXN0cyBmb3IgcmVnaXN0cmF0aW9uIHRvIHRoZSByZXZpZXcgbWFpbGluZyBsaXN0Lgog ICAgICAgICAgCjwvcD4KPGEgbmFtZT0iYW5jaG9yNTAiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxl IHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0i VE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3Rv YyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2Vj dGlvbi4xMS4zLjEiPjwvYT48aDM+MTEuMy4xLiZuYnNwOwpSZWdpc3RyYXRpb24gVGVtcGxhdGU8 L2gzPgoKPHA+CiAgICAgICAgICAgIDwvcD4KPGJsb2NrcXVvdGUgY2xhc3M9InRleHQiPjxkbD4K PGR0PlJlc3BvbnNlIHR5cGUgbmFtZTo8L2R0Pgo8ZGQ+CiAgICAgICAgICAgICAgICAKICAgICAg ICAgICAgICAgIFRoZSBuYW1lIHJlcXVlc3RlZCAoZS5nLiwgImV4YW1wbGUiKS4KICAgICAgICAg ICAgICAKPC9kZD4KPGR0PkNoYW5nZSBjb250cm9sbGVyOjwvZHQ+CjxkZD4KICAgICAgICAgICAg ICAgIAogICAgICAgICAgICAgICAgRm9yIHN0YW5kYXJkcy10cmFjayBSRkNzLCBzdGF0ZSAiSUVU RiIuIEZvciBvdGhlcnMsIGdpdmUgdGhlIG5hbWUgb2YgdGhlCiAgICAgICAgICAgICAgICByZXNw b25zaWJsZSBwYXJ0eS4gT3RoZXIgZGV0YWlscyAoZS5nLiwgcG9zdGFsIGFkZHJlc3MsIGUtbWFp bCBhZGRyZXNzLCBob21lIHBhZ2UKICAgICAgICAgICAgICAgIFVSSSkgbWF5IGFsc28gYmUgaW5j bHVkZWQuCiAgICAgICAgICAgICAgCjwvZGQ+CjxkdD5TcGVjaWZpY2F0aW9uIGRvY3VtZW50KHMp OjwvZHQ+CjxkZD4KICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgUmVmZXJlbmNlIHRv IHRoZSBkb2N1bWVudCB0aGF0IHNwZWNpZmllcyB0aGUgdHlwZSwgcHJlZmVyYWJseSBpbmNsdWRp bmcgYSBVUkkgdGhhdAogICAgICAgICAgICAgICAgY2FuIGJlIHVzZWQgdG8gcmV0cmlldmUgYSBj b3B5IG9mIHRoZSBkb2N1bWVudC4gQW4gaW5kaWNhdGlvbiBvZiB0aGUgcmVsZXZhbnQKICAgICAg ICAgICAgICAgIHNlY3Rpb25zIG1heSBhbHNvIGJlIGluY2x1ZGVkLCBidXQgaXMgbm90IHJlcXVp cmVkLgogICAgICAgICAgICAgIAo8L2RkPgo8L2RsPjwvYmxvY2txdW90ZT48cD4KICAgICAgICAg IAo8L3A+CjxhIG5hbWU9ImFuY2hvcjUxIj48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5 PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIg YWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNw O1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uMTEu My4yIj48L2E+PGgzPjExLjMuMi4mbmJzcDsKSW5pdGlhbCBSZWdpc3RyeSBDb250ZW50czwvaDM+ Cgo8cD4KICAgICAgICAgICAgVGhlIE9BdXRoIEF1dGhvcml6YXRpb24gRW5kcG9pbnQgUmVzcG9u c2UgVHlwZSBSZWdpc3RyeSdzIGluaXRpYWwgY29udGVudHMgYXJlOgogICAgICAgICAgCjwvcD4K PHA+CiAgICAgICAgICAgIDwvcD4KPHVsIGNsYXNzPSJ0ZXh0Ij4KPGxpPgogICAgICAgICAgICAg ICAgUmVzcG9uc2UgdHlwZSBuYW1lOiBjb2RlCiAgICAgICAgICAgICAgCjwvbGk+CjxsaT4KICAg ICAgICAgICAgICAgIENoYW5nZSBjb250cm9sbGVyOiBJRVRGCiAgICAgICAgICAgICAgCjwvbGk+ CjxsaT4KICAgICAgICAgICAgICAgIFNwZWNpZmljYXRpb24gZG9jdW1lbnQocyk6IFtbIHRoaXMg ZG9jdW1lbnQgXV0KICAgICAgICAgICAgICAKPC9saT4KPC91bD48cD4KICAgICAgICAgIAo8L3A+ CjxwPgogICAgICAgICAgICA8L3A+Cjx1bCBjbGFzcz0idGV4dCI+CjxsaT4KICAgICAgICAgICAg ICAgIFJlc3BvbnNlIHR5cGUgbmFtZTogdG9rZW4KICAgICAgICAgICAgICAKPC9saT4KPGxpPgog ICAgICAgICAgICAgICAgQ2hhbmdlIGNvbnRyb2xsZXI6IElFVEYKICAgICAgICAgICAgICAKPC9s aT4KPGxpPgogICAgICAgICAgICAgICAgU3BlY2lmaWNhdGlvbiBkb2N1bWVudChzKTogW1sgdGhp cyBkb2N1bWVudCBdXQogICAgICAgICAgICAgIAo8L2xpPgo8L3VsPjxwPgogICAgICAgICAgCjwv cD4KPGEgbmFtZT0iZXJyb3ItcmVnaXN0cnkiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1h cnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVn IiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5i c3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi4x MS40Ij48L2E+PGgzPjExLjQuJm5ic3A7ClRoZSBPQXV0aCBFeHRlbnNpb25zIEVycm9yIFJlZ2lz dHJ5PC9oMz4KCjxwPgogICAgICAgICAgVGhpcyBzcGVjaWZpY2F0aW9uIGVzdGFibGlzaGVzIHRo ZSBPQXV0aCBleHRlbnNpb25zIGVycm9yIHJlZ2lzdHJ5LgogICAgICAgIAo8L3A+CjxwPgogICAg ICAgICAgQWRkaXRpb25hbCBlcnJvciBjb2RlcyB1c2VkIHRvZ2V0aGVyIHdpdGggb3RoZXIgcHJv dG9jb2wgZXh0ZW5zaW9ucyAoaS5lLiBleHRlbnNpb24gZ3JhbnQKICAgICAgICAgIHR5cGVzLCBh Y2Nlc3MgdG9rZW4gdHlwZXMsIG9yIGV4dGVuc2lvbiBwYXJhbWV0ZXJzKSBhcmUgcmVnaXN0ZXJl ZCB3aXRoIGEgU3BlY2lmaWNhdGlvbgogICAgICAgICAgUmVxdWlyZWQgKDxhIGNsYXNzPSdpbmZv JyBocmVmPScjUkZDNTIyNic+W1JGQzUyMjZdPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2lu Zm8nPk5hcnRlbiwgVC4gYW5kIEguIEFsdmVzdHJhbmQsICZsZHF1bztHdWlkZWxpbmVzIGZvciBX cml0aW5nIGFuIElBTkEgQ29uc2lkZXJhdGlvbnMgU2VjdGlvbiBpbiBSRkNzLCZyZHF1bzsgTWF5 Jm5ic3A7MjAwOC48L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+KSBhZnRlciBhIHR3byB3ZWVrIHJl dmlldyBwZXJpb2Qgb24gdGhlCiAgICAgICAgICBbVEJEXUBpZXRmLm9yZyBtYWlsaW5nIGxpc3Qs IG9uIHRoZSBhZHZpY2Ugb2Ygb25lIG9yIG1vcmUgRGVzaWduYXRlZCBFeHBlcnRzLiBIb3dldmVy LCB0bwogICAgICAgICAgYWxsb3cgZm9yIHRoZSBhbGxvY2F0aW9uIG9mIHZhbHVlcyBwcmlvciB0 byBwdWJsaWNhdGlvbiwgdGhlIERlc2lnbmF0ZWQgRXhwZXJ0KHMpIG1heQogICAgICAgICAgYXBw cm92ZSByZWdpc3RyYXRpb24gb25jZSB0aGV5IGFyZSBzYXRpc2ZpZWQgdGhhdCBzdWNoIGEgc3Bl Y2lmaWNhdGlvbiB3aWxsIGJlIHB1Ymxpc2hlZC4KICAgICAgICAKPC9wPgo8cD4KICAgICAgICAg IFJlZ2lzdHJhdGlvbiByZXF1ZXN0cyBtdXN0IGJlIHNlbnQgdG8gdGhlIFtUQkRdQGlldGYub3Jn IG1haWxpbmcgbGlzdCBmb3IgcmV2aWV3IGFuZAogICAgICAgICAgY29tbWVudCwgd2l0aCBhbiBh cHByb3ByaWF0ZSBzdWJqZWN0IChlLmcuLCAiUmVxdWVzdCBmb3IgZXJyb3IgY29kZTogZXhhbXBs ZSIpLgogICAgICAgICAgW1sgTm90ZSB0byBSRkMtRURJVE9SOiBUaGUgbmFtZSBvZiB0aGUgbWFp bGluZyBsaXN0IHNob3VsZCBiZSBkZXRlcm1pbmVkIGluIGNvbnN1bHRhdGlvbgogICAgICAgICAg d2l0aCB0aGUgSUVTRyBhbmQgSUFOQS4gU3VnZ2VzdGVkIG5hbWU6IG9hdXRoLWV4dC1yZXZpZXcu IF1dCiAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICBXaXRoaW4gdGhlIHJldmlldyBwZXJpb2Qs IHRoZSBEZXNpZ25hdGVkIEV4cGVydChzKSB3aWxsIGVpdGhlciBhcHByb3ZlIG9yCiAgICAgICAg ICBkZW55IHRoZSByZWdpc3RyYXRpb24gcmVxdWVzdCwgY29tbXVuaWNhdGluZyB0aGlzIGRlY2lz aW9uIHRvIHRoZSByZXZpZXcgbGlzdCBhbmQgSUFOQS4KICAgICAgICAgIERlbmlhbHMgc2hvdWxk IGluY2x1ZGUgYW4gZXhwbGFuYXRpb24gYW5kLCBpZiBhcHBsaWNhYmxlLCBzdWdnZXN0aW9ucyBh cyB0byBob3cgdG8gbWFrZQogICAgICAgICAgdGhlIHJlcXVlc3Qgc3VjY2Vzc2Z1bC4KICAgICAg ICAKPC9wPgo8cD4KICAgICAgICAgIElBTkEgbXVzdCBvbmx5IGFjY2VwdCByZWdpc3RyeSB1cGRh dGVzIGZyb20gdGhlIERlc2lnbmF0ZWQgRXhwZXJ0KHMpLCBhbmQgc2hvdWxkIGRpcmVjdAogICAg ICAgICAgYWxsIHJlcXVlc3RzIGZvciByZWdpc3RyYXRpb24gdG8gdGhlIHJldmlldyBtYWlsaW5n IGxpc3QuCiAgICAgICAgCjwvcD4KPGEgbmFtZT0iYW5jaG9yNTIiPjwvYT48YnIgLz48aHIgLz4K PHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBj bGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJl Zj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJy ZmMuc2VjdGlvbi4xMS40LjEiPjwvYT48aDM+MTEuNC4xLiZuYnNwOwpSZWdpc3RyYXRpb24gVGVt cGxhdGU8L2gzPgoKPHA+CiAgICAgICAgICAgIDwvcD4KPGJsb2NrcXVvdGUgY2xhc3M9InRleHQi PjxkbD4KPGR0PkVycm9yIG5hbWU6PC9kdD4KPGRkPgogICAgICAgICAgICAgICAgCiAgICAgICAg ICAgICAgICBUaGUgbmFtZSByZXF1ZXN0ZWQgKGUuZy4sICJleGFtcGxlIikuCiAgICAgICAgICAg ICAgCjwvZGQ+CjxkdD5FcnJvciB1c2FnZSBsb2NhdGlvbjo8L2R0Pgo8ZGQ+CiAgICAgICAgICAg ICAgICAKICAgICAgICAgICAgICAgIFRoZSBsb2NhdGlvbihzKSB3aGVyZSB0aGUgZXJyb3IgY2Fu IGJlIHVzZWQuIFRoZSBwb3NzaWJsZSBsb2NhdGlvbnMgYXJlOgogICAgICAgICAgICAgICAgYXV0 aG9yaXphdGlvbiBjb2RlIGdyYW50IGVycm9yIHJlc3BvbnNlICg8YSBjbGFzcz0naW5mbycgaHJl Zj0nI2NvZGUtYXV0aHotZXJyb3InPlNlY3Rpb24mbmJzcDs0LjEuMi4xPHNwYW4+ICg8L3NwYW4+ PHNwYW4gY2xhc3M9J2luZm8nPkVycm9yIFJlc3BvbnNlPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9h PiksCiAgICAgICAgICAgICAgICBpbXBsaWNpdCBncmFudCBlcnJvciByZXNwb25zZSAoPGEgY2xh c3M9J2luZm8nIGhyZWY9JyNpbXBsaWNpdC1hdXRoei1lcnJvcic+U2VjdGlvbiZuYnNwOzQuMi4y LjE8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+RXJyb3IgUmVzcG9uc2U8L3NwYW4+ PHNwYW4+KTwvc3Bhbj48L2E+KSwKCQl0b2tlbiBlcnJvciByZXNwb25zZSAoPGEgY2xhc3M9J2lu Zm8nIGhyZWY9JyN0b2tlbi1lcnJvcnMnPlNlY3Rpb24mbmJzcDs1LjI8c3Bhbj4gKDwvc3Bhbj48 c3BhbiBjbGFzcz0naW5mbyc+RXJyb3IgUmVzcG9uc2U8L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+ KSwgb3IKCQlyZXNvdXJjZSBhY2Nlc3MgZXJyb3IgcmVzcG9uc2UgKDxhIGNsYXNzPSdpbmZvJyBo cmVmPScjcmVzb3VyY2UtZXJyb3JzJz5TZWN0aW9uJm5ic3A7Ny4yPHNwYW4+ICg8L3NwYW4+PHNw YW4gY2xhc3M9J2luZm8nPkVycm9yIFJlc3BvbnNlPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPiku CiAgICAgICAgICAgICAgCjwvZGQ+CjxkdD5SZWxhdGVkIHByb3RvY29sIGV4dGVuc2lvbjo8L2R0 Pgo8ZGQ+CiAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgIFRoZSBuYW1lIG9mIHRoZSBl eHRlbnNpb24gZ3JhbnQgdHlwZSwgYWNjZXNzIHRva2VuIHR5cGUsIG9yIGV4dGVuc2lvbiBwYXJh bWV0ZXIsCiAgICAgICAgICAgICAgICB0aGUgZXJyb3IgY29kZSBpcyB1c2VkIGluIGNvbmp1bmN0 aW9uIHdpdGguCiAgICAgICAgICAgICAgCjwvZGQ+CjxkdD5DaGFuZ2UgY29udHJvbGxlcjo8L2R0 Pgo8ZGQ+CiAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgIEZvciBzdGFuZGFyZHMtdHJh Y2sgUkZDcywgc3RhdGUgIklFVEYiLiBGb3Igb3RoZXJzLCBnaXZlIHRoZSBuYW1lIG9mIHRoZQog ICAgICAgICAgICAgICAgcmVzcG9uc2libGUgcGFydHkuIE90aGVyIGRldGFpbHMgKGUuZy4sIHBv c3RhbCBhZGRyZXNzLCBlLW1haWwgYWRkcmVzcywgaG9tZSBwYWdlCiAgICAgICAgICAgICAgICBV UkkpIG1heSBhbHNvIGJlIGluY2x1ZGVkLgogICAgICAgICAgICAgIAo8L2RkPgo8ZHQ+U3BlY2lm aWNhdGlvbiBkb2N1bWVudChzKTo8L2R0Pgo8ZGQ+CiAgICAgICAgICAgICAgICAKICAgICAgICAg ICAgICAgIFJlZmVyZW5jZSB0byB0aGUgZG9jdW1lbnQgdGhhdCBzcGVjaWZpZXMgdGhlIGVycm9y IGNvZGUsIHByZWZlcmFibHkgaW5jbHVkaW5nIGEgVVJJCiAgICAgICAgICAgICAgICB0aGF0IGNh biBiZSB1c2VkIHRvIHJldHJpZXZlIGEgY29weSBvZiB0aGUgZG9jdW1lbnQuIEFuIGluZGljYXRp b24gb2YgdGhlIHJlbGV2YW50CiAgICAgICAgICAgICAgICBzZWN0aW9ucyBtYXkgYWxzbyBiZSBp bmNsdWRlZCwgYnV0IGlzIG5vdCByZXF1aXJlZC4KICAgICAgICAgICAgICAKPC9kZD4KPC9kbD48 L2Jsb2NrcXVvdGU+PHA+CiAgICAgICAgICAKPC9wPgo8YSBuYW1lPSJyZmMucmVmZXJlbmNlcyI+ PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIg Y2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFz cz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwv dGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLjEyIj48L2E+PGgzPjEyLiZuYnNwOwpSZWZlcmVu Y2VzPC9oMz4KCjxhIG5hbWU9InJmYy5yZWZlcmVuY2VzMSI+PC9hPjxiciAvPjxociAvPgo8dGFi bGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNz PSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIj dG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxoMz4xMi4xLiZuYnNw O05vcm1hdGl2ZSBSZWZlcmVuY2VzPC9oMz4KPHRhYmxlIHdpZHRoPSI5OSUiIGJvcmRlcj0iMCI+ Cjx0cj48dGQgY2xhc3M9ImF1dGhvci10ZXh0IiB2YWxpZ249InRvcCI+PGEgbmFtZT0iUkZDMjEx OSI+W1JGQzIxMTldPC9hPjwvdGQ+Cjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPjxhIGhyZWY9Im1h aWx0bzpzb2JAaGFydmFyZC5lZHUiPkJyYWRuZXIsIFMuPC9hPiwgJmxkcXVvOzxhIGhyZWY9Imh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzIxMTkiPktleSB3b3JkcyBmb3IgdXNlIGluIFJG Q3MgdG8gSW5kaWNhdGUgUmVxdWlyZW1lbnQgTGV2ZWxzPC9hPiwmcmRxdW87IEJDUCZuYnNwOzE0 LCBSRkMmbmJzcDsyMTE5LCBNYXJjaCZuYnNwOzE5OTcgKDxhIGhyZWY9Imh0dHA6Ly93d3cucmZj LWVkaXRvci5vcmcvcmZjL3JmYzIxMTkudHh0Ij5UWFQ8L2E+LCA8YSBocmVmPSJodHRwOi8veG1s LnJlc291cmNlLm9yZy9wdWJsaWMvcmZjL2h0bWwvcmZjMjExOS5odG1sIj5IVE1MPC9hPiwgPGEg aHJlZj0iaHR0cDovL3htbC5yZXNvdXJjZS5vcmcvcHVibGljL3JmYy94bWwvcmZjMjExOS54bWwi PlhNTDwvYT4pLjwvdGQ+PC90cj4KPHRyPjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiIHZhbGlnbj0i dG9wIj48YSBuYW1lPSJSRkMyMjQ2Ij5bUkZDMjI0Nl08L2E+PC90ZD4KPHRkIGNsYXNzPSJhdXRo b3ItdGV4dCI+PGEgaHJlZj0ibWFpbHRvOnRkaWVya3NAY2VydGljb20uY29tIj5EaWVya3MsIFQu PC9hPiBhbmQgPGEgaHJlZj0ibWFpbHRvOmNhbGxlbkBjZXJ0aWNvbS5jb20iPkMuIEFsbGVuPC9h PiwgJmxkcXVvOzxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzIyNDYiPlRo ZSBUTFMgUHJvdG9jb2wgVmVyc2lvbiAxLjA8L2E+LCZyZHF1bzsgUkZDJm5ic3A7MjI0NiwgSmFu dWFyeSZuYnNwOzE5OTkgKDxhIGhyZWY9Imh0dHA6Ly93d3cucmZjLWVkaXRvci5vcmcvcmZjL3Jm YzIyNDYudHh0Ij5UWFQ8L2E+KS48L3RkPjwvdHI+Cjx0cj48dGQgY2xhc3M9ImF1dGhvci10ZXh0 IiB2YWxpZ249InRvcCI+PGEgbmFtZT0iUkZDMjYxNiI+W1JGQzI2MTZdPC9hPjwvdGQ+Cjx0ZCBj bGFzcz0iYXV0aG9yLXRleHQiPjxhIGhyZWY9Im1haWx0bzpmaWVsZGluZ0BpY3MudWNpLmVkdSI+ RmllbGRpbmcsIFIuPC9hPiwgPGEgaHJlZj0ibWFpbHRvOmpnQHczLm9yZyI+R2V0dHlzLCBKLjwv YT4sIDxhIGhyZWY9Im1haWx0bzptb2d1bEB3cmwuZGVjLmNvbSI+TW9ndWwsIEouPC9hPiwgPGEg aHJlZj0ibWFpbHRvOmZyeXN0eWtAdzMub3JnIj5GcnlzdHlrLCBILjwvYT4sIDxhIGhyZWY9Im1h aWx0bzptYXNpbnRlckBwYXJjLnhlcm94LmNvbSI+TWFzaW50ZXIsIEwuPC9hPiwgPGEgaHJlZj0i bWFpbHRvOnBhdWxsZUBtaWNyb3NvZnQuY29tIj5MZWFjaCwgUC48L2E+LCBhbmQgPGEgaHJlZj0i bWFpbHRvOnRpbWJsQHczLm9yZyI+VC4gQmVybmVycy1MZWU8L2E+LCAmbGRxdW87PGEgaHJlZj0i aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMjYxNiI+SHlwZXJ0ZXh0IFRyYW5zZmVyIFBy b3RvY29sIC0tIEhUVFAvMS4xPC9hPiwmcmRxdW87IFJGQyZuYnNwOzI2MTYsIEp1bmUmbmJzcDsx OTk5ICg8YSBocmVmPSJodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL3JmYy9yZmMyNjE2LnR4dCI+ VFhUPC9hPiwgPGEgaHJlZj0iaHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9yZmMvcmZjMjYxNi5w cyI+UFM8L2E+LCA8YSBocmVmPSJodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL3JmYy9yZmMyNjE2 LnBkZiI+UERGPC9hPiwgPGEgaHJlZj0iaHR0cDovL3htbC5yZXNvdXJjZS5vcmcvcHVibGljL3Jm Yy9odG1sL3JmYzI2MTYuaHRtbCI+SFRNTDwvYT4sIDxhIGhyZWY9Imh0dHA6Ly94bWwucmVzb3Vy Y2Uub3JnL3B1YmxpYy9yZmMveG1sL3JmYzI2MTYueG1sIj5YTUw8L2E+KS48L3RkPjwvdHI+Cjx0 cj48dGQgY2xhc3M9ImF1dGhvci10ZXh0IiB2YWxpZ249InRvcCI+PGEgbmFtZT0iUkZDMjYxNyI+ W1JGQzI2MTddPC9hPjwvdGQ+Cjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPjxhIGhyZWY9Im1haWx0 bzpqb2huQG1hdGgubnd1LmVkdSI+RnJhbmtzLCBKLjwvYT4sIDxhIGhyZWY9Im1haWx0bzpwYmFr ZXJAdmVyaXNpZ24uY29tIj5IYWxsYW0tQmFrZXIsIFAuPC9hPiwgPGEgaHJlZj0ibWFpbHRvOmpl ZmZAQWJpU291cmNlLmNvbSI+SG9zdGV0bGVyLCBKLjwvYT4sIDxhIGhyZWY9Im1haWx0bzpsYXdy ZW5jZUBhZ3JhbmF0LmNvbSI+TGF3cmVuY2UsIFMuPC9hPiwgPGEgaHJlZj0ibWFpbHRvOnBhdWxs ZUBtaWNyb3NvZnQuY29tIj5MZWFjaCwgUC48L2E+LCBMdW90b25lbiwgQS4sIGFuZCA8YSBocmVm PSJtYWlsdG86c3Rld2FydEBPcGVuTWFya2V0LmNvbSI+TC4gU3Rld2FydDwvYT4sICZsZHF1bzs8 YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmMyNjE3Ij5IVFRQIEF1dGhlbnRp Y2F0aW9uOiBCYXNpYyBhbmQgRGlnZXN0IEFjY2VzcyBBdXRoZW50aWNhdGlvbjwvYT4sJnJkcXVv OyBSRkMmbmJzcDsyNjE3LCBKdW5lJm5ic3A7MTk5OSAoPGEgaHJlZj0iaHR0cDovL3d3dy5yZmMt ZWRpdG9yLm9yZy9yZmMvcmZjMjYxNy50eHQiPlRYVDwvYT4sIDxhIGhyZWY9Imh0dHA6Ly94bWwu cmVzb3VyY2Uub3JnL3B1YmxpYy9yZmMvaHRtbC9yZmMyNjE3Lmh0bWwiPkhUTUw8L2E+LCA8YSBo cmVmPSJodHRwOi8veG1sLnJlc291cmNlLm9yZy9wdWJsaWMvcmZjL3htbC9yZmMyNjE3LnhtbCI+ WE1MPC9hPikuPC90ZD48L3RyPgo8dHI+PHRkIGNsYXNzPSJhdXRob3ItdGV4dCIgdmFsaWduPSJ0 b3AiPjxhIG5hbWU9IlJGQzI4MTgiPltSRkMyODE4XTwvYT48L3RkPgo8dGQgY2xhc3M9ImF1dGhv ci10ZXh0Ij5SZXNjb3JsYSwgRS4sICZsZHF1bzs8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9yZmMyODE4Ij5IVFRQIE92ZXIgVExTPC9hPiwmcmRxdW87IFJGQyZuYnNwOzI4MTgs IE1heSZuYnNwOzIwMDAgKDxhIGhyZWY9Imh0dHA6Ly93d3cucmZjLWVkaXRvci5vcmcvcmZjL3Jm YzI4MTgudHh0Ij5UWFQ8L2E+KS48L3RkPjwvdHI+Cjx0cj48dGQgY2xhc3M9ImF1dGhvci10ZXh0 IiB2YWxpZ249InRvcCI+PGEgbmFtZT0iUkZDMzk4NiI+W1JGQzM5ODZdPC9hPjwvdGQ+Cjx0ZCBj bGFzcz0iYXV0aG9yLXRleHQiPjxhIGhyZWY9Im1haWx0bzp0aW1ibEB3My5vcmciPkJlcm5lcnMt TGVlLCBULjwvYT4sIDxhIGhyZWY9Im1haWx0bzpmaWVsZGluZ0BnYml2LmNvbSI+RmllbGRpbmcs IFIuPC9hPiwgYW5kIDxhIGhyZWY9Im1haWx0bzpMTU1AYWNtLm9yZyI+TC4gTWFzaW50ZXI8L2E+ LCAmbGRxdW87PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMzk4NiI+VW5p Zm9ybSBSZXNvdXJjZSBJZGVudGlmaWVyIChVUkkpOiBHZW5lcmljIFN5bnRheDwvYT4sJnJkcXVv OyBTVEQmbmJzcDs2NiwgUkZDJm5ic3A7Mzk4NiwgSmFudWFyeSZuYnNwOzIwMDUgKDxhIGhyZWY9 Imh0dHA6Ly93d3cucmZjLWVkaXRvci5vcmcvcmZjL3JmYzM5ODYudHh0Ij5UWFQ8L2E+LCA8YSBo cmVmPSJodHRwOi8veG1sLnJlc291cmNlLm9yZy9wdWJsaWMvcmZjL2h0bWwvcmZjMzk4Ni5odG1s Ij5IVE1MPC9hPiwgPGEgaHJlZj0iaHR0cDovL3htbC5yZXNvdXJjZS5vcmcvcHVibGljL3JmYy94 bWwvcmZjMzk4Ni54bWwiPlhNTDwvYT4pLjwvdGQ+PC90cj4KPHRyPjx0ZCBjbGFzcz0iYXV0aG9y LXRleHQiIHZhbGlnbj0idG9wIj48YSBuYW1lPSJSRkM0NjI3Ij5bUkZDNDYyN108L2E+PC90ZD4K PHRkIGNsYXNzPSJhdXRob3ItdGV4dCI+Q3JvY2tmb3JkLCBELiwgJmxkcXVvOzxhIGhyZWY9Imh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzQ2MjciPlRoZSBhcHBsaWNhdGlvbi9qc29uIE1l ZGlhIFR5cGUgZm9yIEphdmFTY3JpcHQgT2JqZWN0IE5vdGF0aW9uIChKU09OKTwvYT4sJnJkcXVv OyBSRkMmbmJzcDs0NjI3LCBKdWx5Jm5ic3A7MjAwNiAoPGEgaHJlZj0iaHR0cDovL3d3dy5yZmMt ZWRpdG9yLm9yZy9yZmMvcmZjNDYyNy50eHQiPlRYVDwvYT4pLjwvdGQ+PC90cj4KPHRyPjx0ZCBj bGFzcz0iYXV0aG9yLXRleHQiIHZhbGlnbj0idG9wIj48YSBuYW1lPSJSRkM0OTQ5Ij5bUkZDNDk0 OV08L2E+PC90ZD4KPHRkIGNsYXNzPSJhdXRob3ItdGV4dCI+U2hpcmV5LCBSLiwgJmxkcXVvOzxh IGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzQ5NDkiPkludGVybmV0IFNlY3Vy aXR5IEdsb3NzYXJ5LCBWZXJzaW9uIDI8L2E+LCZyZHF1bzsgUkZDJm5ic3A7NDk0OSwgQXVndXN0 Jm5ic3A7MjAwNyAoPGEgaHJlZj0iaHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9yZmMvcmZjNDk0 OS50eHQiPlRYVDwvYT4pLjwvdGQ+PC90cj4KPHRyPjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiIHZh bGlnbj0idG9wIj48YSBuYW1lPSJSRkM1MjI2Ij5bUkZDNTIyNl08L2E+PC90ZD4KPHRkIGNsYXNz PSJhdXRob3ItdGV4dCI+TmFydGVuLCBULiBhbmQgSC4gQWx2ZXN0cmFuZCwgJmxkcXVvOzxhIGhy ZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzUyMjYiPkd1aWRlbGluZXMgZm9yIFdy aXRpbmcgYW4gSUFOQSBDb25zaWRlcmF0aW9ucyBTZWN0aW9uIGluIFJGQ3M8L2E+LCZyZHF1bzsg QkNQJm5ic3A7MjYsIFJGQyZuYnNwOzUyMjYsIE1heSZuYnNwOzIwMDggKDxhIGhyZWY9Imh0dHA6 Ly93d3cucmZjLWVkaXRvci5vcmcvcmZjL3JmYzUyMjYudHh0Ij5UWFQ8L2E+KS48L3RkPjwvdHI+ Cjx0cj48dGQgY2xhc3M9ImF1dGhvci10ZXh0IiB2YWxpZ249InRvcCI+PGEgbmFtZT0iUkZDNTIz NCI+W1JGQzUyMzRdPC9hPjwvdGQ+Cjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPkNyb2NrZXIsIEQu IGFuZCBQLiBPdmVyZWxsLCAmbGRxdW87PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvcmZjNTIzNCI+QXVnbWVudGVkIEJORiBmb3IgU3ludGF4IFNwZWNpZmljYXRpb25zOiBBQk5G PC9hPiwmcmRxdW87IFNURCZuYnNwOzY4LCBSRkMmbmJzcDs1MjM0LCBKYW51YXJ5Jm5ic3A7MjAw OCAoPGEgaHJlZj0iaHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9yZmMvcmZjNTIzNC50eHQiPlRY VDwvYT4pLjwvdGQ+PC90cj4KPHRyPjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiIHZhbGlnbj0idG9w Ij48YSBuYW1lPSJSRkM1MjQ2Ij5bUkZDNTI0Nl08L2E+PC90ZD4KPHRkIGNsYXNzPSJhdXRob3It dGV4dCI+RGllcmtzLCBULiBhbmQgRS4gUmVzY29ybGEsICZsZHF1bzs8YSBocmVmPSJodHRwOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1MjQ2Ij5UaGUgVHJhbnNwb3J0IExheWVyIFNlY3VyaXR5 IChUTFMpIFByb3RvY29sIFZlcnNpb24gMS4yPC9hPiwmcmRxdW87IFJGQyZuYnNwOzUyNDYsIEF1 Z3VzdCZuYnNwOzIwMDggKDxhIGhyZWY9Imh0dHA6Ly93d3cucmZjLWVkaXRvci5vcmcvcmZjL3Jm YzUyNDYudHh0Ij5UWFQ8L2E+KS48L3RkPjwvdHI+Cjx0cj48dGQgY2xhc3M9ImF1dGhvci10ZXh0 IiB2YWxpZ249InRvcCI+PGEgbmFtZT0iUkZDNjEyNSI+W1JGQzYxMjVdPC9hPjwvdGQ+Cjx0ZCBj bGFzcz0iYXV0aG9yLXRleHQiPlNhaW50LUFuZHJlLCBQLiBhbmQgSi4gSG9kZ2VzLCAmbGRxdW87 PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjEyNSI+UmVwcmVzZW50YXRp b24gYW5kIFZlcmlmaWNhdGlvbiBvZiBEb21haW4tQmFzZWQgQXBwbGljYXRpb24gU2VydmljZSBJ ZGVudGl0eSB3aXRoaW4gSW50ZXJuZXQgUHVibGljIEtleSBJbmZyYXN0cnVjdHVyZSBVc2luZyBY LjUwOSAoUEtJWCkgQ2VydGlmaWNhdGVzIGluIHRoZSBDb250ZXh0IG9mIFRyYW5zcG9ydCBMYXll ciBTZWN1cml0eSAoVExTKTwvYT4sJnJkcXVvOyBSRkMmbmJzcDs2MTI1LCBNYXJjaCZuYnNwOzIw MTEgKDxhIGhyZWY9Imh0dHA6Ly93d3cucmZjLWVkaXRvci5vcmcvcmZjL3JmYzYxMjUudHh0Ij5U WFQ8L2E+KS48L3RkPjwvdHI+Cjx0cj48dGQgY2xhc3M9ImF1dGhvci10ZXh0IiB2YWxpZ249InRv cCI+PGEgbmFtZT0iVVNBU0NJSSI+W1VTQVNDSUldPC9hPjwvdGQ+Cjx0ZCBjbGFzcz0iYXV0aG9y LXRleHQiPkFtZXJpY2FuIE5hdGlvbmFsIFN0YW5kYXJkcyBJbnN0aXR1dGUsICZsZHF1bztDb2Rl ZCBDaGFyYWN0ZXIgU2V0IC0tIDctYml0IEFtZXJpY2FuIFN0YW5kYXJkIENvZGUgZm9yIEluZm9y bWF0aW9uIEludGVyY2hhbmdlLCZyZHF1bzsgQU5TSSZuYnNwO1gzLjQsIDE5ODYuPC90ZD48L3Ry Pgo8dHI+PHRkIGNsYXNzPSJhdXRob3ItdGV4dCIgdmFsaWduPSJ0b3AiPjxhIG5hbWU9IlczQy5S RUMtaHRtbDQwMS0xOTk5MTIyNCI+W1czQy5SRUMtaHRtbDQwMS0xOTk5MTIyNF08L2E+PC90ZD4K PHRkIGNsYXNzPSJhdXRob3ItdGV4dCI+SG9ycywgQS4sIFJhZ2dldHQsIEQuLCBhbmQgSS4gSmFj b2JzLCAmbGRxdW87PGEgaHJlZj0iaHR0cDovL3d3dy53My5vcmcvVFIvMTk5OS9SRUMtaHRtbDQw MS0xOTk5MTIyNCI+SFRNTCA0LjAxIFNwZWNpZmljYXRpb248L2E+LCZyZHF1bzsgV29ybGQgV2lk ZSBXZWIgQ29uc29ydGl1bSBSZWNvbW1lbmRhdGlvbiZuYnNwO1JFQy1odG1sNDAxLTE5OTkxMjI0 LCBEZWNlbWJlciZuYnNwOzE5OTkgKDxhIGhyZWY9Imh0dHA6Ly93d3cudzMub3JnL1RSLzE5OTkv UkVDLWh0bWw0MDEtMTk5OTEyMjQiPkhUTUw8L2E+KS48L3RkPjwvdHI+CjwvdGFibGU+Cgo8YSBu YW1lPSJyZmMucmVmZXJlbmNlczIiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9Imxh eW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGln bj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9D Jm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8aDM+MTIuMi4mbmJzcDtJbmZvcm1hdGl2ZSBS ZWZlcmVuY2VzPC9oMz4KPHRhYmxlIHdpZHRoPSI5OSUiIGJvcmRlcj0iMCI+Cjx0cj48dGQgY2xh c3M9ImF1dGhvci10ZXh0IiB2YWxpZ249InRvcCI+PGEgbmFtZT0iSS1ELmRyYWZ0LWhhcmR0LW9h dXRoLTAxIj5bSS1ELmRyYWZ0LWhhcmR0LW9hdXRoLTAxXTwvYT48L3RkPgo8dGQgY2xhc3M9ImF1 dGhvci10ZXh0Ij5IYXJkdCwgRC4sIEVkLiwgVG9tLCBBLiwgRWF0b24sIEIuLCBhbmQgWS4gR29s YW5kLCAmbGRxdW87PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaGFy ZHQtb2F1dGgtMDEiPk9BdXRoIFdlYiBSZXNvdXJjZSBBdXRob3JpemF0aW9uIFByb2ZpbGVzPC9h PiwmcmRxdW87IEphbnVhcnkmbmJzcDsyMDEwLjwvdGQ+PC90cj4KPHRyPjx0ZCBjbGFzcz0iYXV0 aG9yLXRleHQiIHZhbGlnbj0idG9wIj48YSBuYW1lPSJJLUQuaWV0Zi1odHRwYmlzLXA3LWF1dGgi PltJLUQuaWV0Zi1odHRwYmlzLXA3LWF1dGhdPC9hPjwvdGQ+Cjx0ZCBjbGFzcz0iYXV0aG9yLXRl eHQiPkZpZWxkaW5nLCBSLiwgTGFmb24sIFkuLCBhbmQgSi4gUmVzY2hrZSwgJmxkcXVvOzxhIGhy ZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtaHR0cGJpcy1wNy1hdXRo LTE5Ij5IVFRQLzEuMSwgcGFydCA3OiBBdXRoZW50aWNhdGlvbjwvYT4sJnJkcXVvOyBkcmFmdC1p ZXRmLWh0dHBiaXMtcDctYXV0aC0xOSAod29yayBpbiBwcm9ncmVzcyksIE1hcmNoJm5ic3A7MjAx MiAoPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0 Zi1odHRwYmlzLXA3LWF1dGgtMTkudHh0Ij5UWFQ8L2E+KS48L3RkPjwvdHI+Cjx0cj48dGQgY2xh c3M9ImF1dGhvci10ZXh0IiB2YWxpZ249InRvcCI+PGEgbmFtZT0iSS1ELmlldGYtb2F1dGgtc2Ft bDItYmVhcmVyIj5bSS1ELmlldGYtb2F1dGgtc2FtbDItYmVhcmVyXTwvYT48L3RkPgo8dGQgY2xh c3M9ImF1dGhvci10ZXh0Ij5Nb3J0aW1vcmUsIEMuLCAmbGRxdW87PGEgaHJlZj0iaHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1zYW1sMi1iZWFyZXItMTIiPlNBTUwg Mi4wIEJlYXJlciBBc3NlcnRpb24gUHJvZmlsZXMgZm9yIE9BdXRoIDIuMDwvYT4sJnJkcXVvOyBk cmFmdC1pZXRmLW9hdXRoLXNhbWwyLWJlYXJlci0xMiAod29yayBpbiBwcm9ncmVzcyksIE1heSZu YnNwOzIwMTIgKDxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2Ry YWZ0LWlldGYtb2F1dGgtc2FtbDItYmVhcmVyLTEyLnR4dCI+VFhUPC9hPikuPC90ZD48L3RyPgo8 dHI+PHRkIGNsYXNzPSJhdXRob3ItdGV4dCIgdmFsaWduPSJ0b3AiPjxhIG5hbWU9IkktRC5pZXRm LW9hdXRoLXYyLWJlYXJlciI+W0ktRC5pZXRmLW9hdXRoLXYyLWJlYXJlcl08L2E+PC90ZD4KPHRk IGNsYXNzPSJhdXRob3ItdGV4dCI+Sm9uZXMsIE0uLCBIYXJkdCwgRC4sIGFuZCBELiBSZWNvcmRv biwgJmxkcXVvOzxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt b2F1dGgtdjItYmVhcmVyLTE5Ij5UaGUgT0F1dGggMi4wIEF1dGhvcml6YXRpb24gUHJvdG9jb2w6 IEJlYXJlciBUb2tlbnM8L2E+LCZyZHF1bzsgZHJhZnQtaWV0Zi1vYXV0aC12Mi1iZWFyZXItMTkg KHdvcmsgaW4gcHJvZ3Jlc3MpLCBBcHJpbCZuYnNwOzIwMTIgKDxhIGhyZWY9Imh0dHA6Ly93d3cu aWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtb2F1dGgtdjItYmVhcmVyLTE5LnR4 dCI+VFhUPC9hPiwgPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMv ZHJhZnQtaWV0Zi1vYXV0aC12Mi1iZWFyZXItMTkucGRmIj5QREY8L2E+KS48L3RkPjwvdHI+Cjx0 cj48dGQgY2xhc3M9ImF1dGhvci10ZXh0IiB2YWxpZ249InRvcCI+PGEgbmFtZT0iSS1ELmlldGYt b2F1dGgtdjItaHR0cC1tYWMiPltJLUQuaWV0Zi1vYXV0aC12Mi1odHRwLW1hY108L2E+PC90ZD4K PHRkIGNsYXNzPSJhdXRob3ItdGV4dCI+SGFtbWVyLUxhaGF2LCBFLiwgJmxkcXVvOzxhIGhyZWY9 Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtdjItaHR0cC1tYWMt MDEiPkhUVFAgQXV0aGVudGljYXRpb246IE1BQyBBY2Nlc3MgQXV0aGVudGljYXRpb248L2E+LCZy ZHF1bzsgZHJhZnQtaWV0Zi1vYXV0aC12Mi1odHRwLW1hYy0wMSAod29yayBpbiBwcm9ncmVzcyks IEZlYnJ1YXJ5Jm5ic3A7MjAxMiAoPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5l dC1kcmFmdHMvZHJhZnQtaWV0Zi1vYXV0aC12Mi1odHRwLW1hYy0wMS50eHQiPlRYVDwvYT4sIDxh IGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtb2F1 dGgtdjItaHR0cC1tYWMtMDEucGRmIj5QREY8L2E+KS48L3RkPjwvdHI+Cjx0cj48dGQgY2xhc3M9 ImF1dGhvci10ZXh0IiB2YWxpZ249InRvcCI+PGEgbmFtZT0iSS1ELmlldGYtb2F1dGgtdjItdGhy ZWF0bW9kZWwiPltJLUQuaWV0Zi1vYXV0aC12Mi10aHJlYXRtb2RlbF08L2E+PC90ZD4KPHRkIGNs YXNzPSJhdXRob3ItdGV4dCI+TWNHbG9pbiwgTS4sIEh1bnQsIFAuLCBhbmQgVC4gTG9kZGVyc3Rl ZHQsICZsZHF1bzs8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm LW9hdXRoLXYyLXRocmVhdG1vZGVsLTAyIj5PQXV0aCAyLjAgVGhyZWF0IE1vZGVsIGFuZCBTZWN1 cml0eSBDb25zaWRlcmF0aW9uczwvYT4sJnJkcXVvOyBkcmFmdC1pZXRmLW9hdXRoLXYyLXRocmVh dG1vZGVsLTAyICh3b3JrIGluIHByb2dyZXNzKSwgRmVicnVhcnkmbmJzcDsyMDEyICg8YSBocmVm PSJodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLW9hdXRoLXYy LXRocmVhdG1vZGVsLTAyLnR4dCI+VFhUPC9hPikuPC90ZD48L3RyPgo8dHI+PHRkIGNsYXNzPSJh dXRob3ItdGV4dCIgdmFsaWduPSJ0b3AiPjxhIG5hbWU9IlJGQzU4NDkiPltSRkM1ODQ5XTwvYT48 L3RkPgo8dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij5IYW1tZXItTGFoYXYsIEUuLCAmbGRxdW87PGEg aHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTg0OSI+VGhlIE9BdXRoIDEuMCBQ cm90b2NvbDwvYT4sJnJkcXVvOyBSRkMmbmJzcDs1ODQ5LCBBcHJpbCZuYnNwOzIwMTAgKDxhIGhy ZWY9Imh0dHA6Ly93d3cucmZjLWVkaXRvci5vcmcvcmZjL3JmYzU4NDkudHh0Ij5UWFQ8L2E+KS48 L3RkPjwvdHI+CjwvdGFibGU+Cgo8YSBuYW1lPSJhbmNob3I1NSI+PC9hPjxiciAvPjxociAvPgo8 dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNs YXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVm PSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJm Yy5zZWN0aW9uLkEiPjwvYT48aDM+QXBwZW5kaXggQS4mbmJzcDsKQXVnbWVudGVkIEJhY2t1cy1O YXVyIEZvcm0gKEFCTkYpIFN5bnRheDwvaDM+Cgo8cD4KCVRoaXMgc2VjdGlvbiBwcm92aWRlcyBB dWdtZW50ZWQgQmFja3VzLU5hdXIgRm9ybSAoQUJORikgc3ludGF4CglkZXNjcmlwdGlvbnMgZm9y IHRoZSBlbGVtZW50cyBkZWZpbmVkIGluIHRoaXMgc3BlY2lmaWNhdGlvbgoJdXNpbmcgdGhlIG5v dGF0aW9uIG9mIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjUkZDNTIzNCc+W1JGQzUyMzRdPHNwYW4+ ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkNyb2NrZXIsIEQuIGFuZCBQLiBPdmVyZWxsLCAm bGRxdW87QXVnbWVudGVkIEJORiBmb3IgU3ludGF4IFNwZWNpZmljYXRpb25zOiBBQk5GLCZyZHF1 bzsgSmFudWFyeSZuYnNwOzIwMDguPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPi4KCUVsZW1lbnRz IGFyZSBwcmVzZW50ZWQgaW4gdGhlIG9yZGVyIGZpcnN0IGRlZmluZWQuCiAgICAgIAo8L3A+Cjxw PgoJICBTb21lIG9mIHRoZSBkZWZpbml0aW9ucyB0aGF0IGZvbGxvdyB1c2UgdGhlCgkgIDx0dD51 bnJlc2VydmVkPC90dD4gYW5kCgkgIDx0dD5VUkk8L3R0PgoJICBkZWZpbml0aW9ucyBmcm9tIDxh IGNsYXNzPSdpbmZvJyBocmVmPScjUkZDMzk4Nic+W1JGQzM5ODZdPHNwYW4+ICg8L3NwYW4+PHNw YW4gY2xhc3M9J2luZm8nPkJlcm5lcnMtTGVlLCBULiwgRmllbGRpbmcsIFIuLCBhbmQgTC4gTWFz aW50ZXIsICZsZHF1bztVbmlmb3JtIFJlc291cmNlIElkZW50aWZpZXIgKFVSSSk6IEdlbmVyaWMg U3ludGF4LCZyZHF1bzsgSmFudWFyeSZuYnNwOzIwMDUuPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9h Piwgd2hpY2ggYXJlOgoJCjwvcD48ZGl2IHN0eWxlPSdkaXNwbGF5OiB0YWJsZTsgd2lkdGg6IDA7 IG1hcmdpbi1sZWZ0OiAzZW07IG1hcmdpbi1yaWdodDogYXV0byc+PHByZT4KdW5yZXNlcnZlZCA9 IEFMUEhBIC8gRElHSVQgLyAiLSIgLyAiLiIgLyAiXyIgLyAifiIKVVJJICAgICAgICA9IHNjaGVt ZSAiOiIgaGllci1wYXJ0IFsgIj8iIHF1ZXJ5IF0gWyAiIyIgZnJhZ21lbnQgXQo8L3ByZT48L2Rp dj4KPHA+CgkgIFNvbWUgb2YgdGhlIGRlZmluaXRpb25zIHRoYXQgZm9sbG93IHVzZSB0aGUKCSAg PHR0PmI2NHRva2VuPC90dD4gc3ludGF4IGJlbG93LCB3aGljaCBtYXRjaGVzIHRoZQoJICA8dHQ+ YjY0dG9rZW48L3R0PiBzeW50YXggZGVmaW5lZCBieQoJICBIVFRQLzEuMSwgUGFydCA3IDxhIGNs YXNzPSdpbmZvJyBocmVmPScjSS1ELmlldGYtaHR0cGJpcy1wNy1hdXRoJz5bSSYjODIwOTtELmll dGYmIzgyMDk7aHR0cGJpcyYjODIwOTtwNyYjODIwOTthdXRoXTxzcGFuPiAoPC9zcGFuPjxzcGFu IGNsYXNzPSdpbmZvJz5GaWVsZGluZywgUi4sIExhZm9uLCBZLiwgYW5kIEouIFJlc2Noa2UsICZs ZHF1bztIVFRQLzEuMSwgcGFydCA3OiBBdXRoZW50aWNhdGlvbiwmcmRxdW87IE1hcmNoJm5ic3A7 MjAxMi48L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+OgoJCjwvcD48ZGl2IHN0eWxlPSdkaXNwbGF5 OiB0YWJsZTsgd2lkdGg6IDA7IG1hcmdpbi1sZWZ0OiAzZW07IG1hcmdpbi1yaWdodDogYXV0byc+ PHByZT4KYjY0dG9rZW4gICA9IDEqKCBBTFBIQSAvIERJR0lUIC8KICAgICAgICAgICAgICAgICAi LSIgLyAiLiIgLyAiXyIgLyAifiIgLyAiKyIgLyAiLyIgKSAqIj0iCjwvcHJlPjwvZGl2Pgo8YSBu YW1lPSJhbmNob3I1NiI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBj ZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdo dCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8 L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLkEuMSI+PC9hPjxoMz5B LjEuJm5ic3A7CiJjbGllbnRfaWQiIFN5bnRheDwvaDM+Cgo8cD4KCSAgICBUaGUgPHR0PmNsaWVu dF9pZDwvdHQ+IGVsZW1lbnQgaXMgZGVmaW5lZCBpbgoJICAgIDxhIGNsYXNzPSdpbmZvJyBocmVm PScjY2xpZW50LXBhc3N3b3JkJz5TZWN0aW9uJm5ic3A7Mi4zLjE8c3Bhbj4gKDwvc3Bhbj48c3Bh biBjbGFzcz0naW5mbyc+Q2xpZW50IFBhc3N3b3JkPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPjoK CSAgCjwvcD48ZGl2IHN0eWxlPSdkaXNwbGF5OiB0YWJsZTsgd2lkdGg6IDA7IG1hcmdpbi1sZWZ0 OiAzZW07IG1hcmdpbi1yaWdodDogYXV0byc+PHByZT4KY2xpZW50LWlkICAgICA9ICombHQ7VEVY VCBleGNsdWRpbmcgIjoiJmd0Owo8L3ByZT48L2Rpdj4KPHA+CgkgIChUaGlzIG1hdGNoZXMgdGhl IDx0dD51c2VyaWQ8L3R0PiBkZWZpbml0aW9uIGluIHRoZQoJICBIVFRQIEJhc2ljIEF1dGhlbnRp Y2F0aW9uIFNjaGVtZSA8YSBjbGFzcz0naW5mbycgaHJlZj0nI1JGQzI2MTcnPltSRkMyNjE3XTxz cGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5GcmFua3MsIEouLCBIYWxsYW0tQmFrZXIs IFAuLCBIb3N0ZXRsZXIsIEouLCBMYXdyZW5jZSwgUy4sIExlYWNoLCBQLiwgTHVvdG9uZW4sIEEu LCBhbmQgTC4gU3Rld2FydCwgJmxkcXVvO0hUVFAgQXV0aGVudGljYXRpb246IEJhc2ljIGFuZCBE aWdlc3QgQWNjZXNzIEF1dGhlbnRpY2F0aW9uLCZyZHF1bzsgSnVuZSZuYnNwOzE5OTkuPC9zcGFu PjxzcGFuPik8L3NwYW4+PC9hPi4pCgkKPC9wPgo8YSBuYW1lPSJhbmNob3I1NyI+PC9hPjxiciAv PjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNp bmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVn Ij48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+Cjxh IG5hbWU9InJmYy5zZWN0aW9uLkEuMiI+PC9hPjxoMz5BLjIuJm5ic3A7CiJjbGllbnRfc2VjcmV0 IiBTeW50YXg8L2gzPgoKPHA+CgkgICAgVGhlIDx0dD5jbGllbnRfc2VjcmV0PC90dD4gZWxlbWVu dCBpcyBkZWZpbmVkIGluCgkgICAgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNjbGllbnQtcGFzc3dv cmQnPlNlY3Rpb24mbmJzcDsyLjMuMTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5D bGllbnQgUGFzc3dvcmQ8L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+OgoJICAKPC9wPjxkaXYgc3R5 bGU9J2Rpc3BsYXk6IHRhYmxlOyB3aWR0aDogMDsgbWFyZ2luLWxlZnQ6IDNlbTsgbWFyZ2luLXJp Z2h0OiBhdXRvJz48cHJlPgpjbGllbnQtc2VjcmV0ID0gKlRFWFQKPC9wcmU+PC9kaXY+CjxwPgoJ ICAoVGhpcyBtYXRjaGVzIHRoZSA8dHQ+cGFzc3dvcmQ8L3R0PiBkZWZpbml0aW9uIGluIHRoZQoJ ICBIVFRQIEJhc2ljIEF1dGhlbnRpY2F0aW9uIFNjaGVtZSA8YSBjbGFzcz0naW5mbycgaHJlZj0n I1JGQzI2MTcnPltSRkMyNjE3XTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5GcmFu a3MsIEouLCBIYWxsYW0tQmFrZXIsIFAuLCBIb3N0ZXRsZXIsIEouLCBMYXdyZW5jZSwgUy4sIExl YWNoLCBQLiwgTHVvdG9uZW4sIEEuLCBhbmQgTC4gU3Rld2FydCwgJmxkcXVvO0hUVFAgQXV0aGVu dGljYXRpb246IEJhc2ljIGFuZCBEaWdlc3QgQWNjZXNzIEF1dGhlbnRpY2F0aW9uLCZyZHF1bzsg SnVuZSZuYnNwOzE5OTkuPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPi4pCgkKPC9wPgo8YSBuYW1l PSJhbmNob3I1OCI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxs cGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+ PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+ PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLkEuMyI+PC9hPjxoMz5BLjMu Jm5ic3A7CiJyZXNwb25zZV90eXBlIiBTeW50YXg8L2gzPgoKPHA+CgkgICAgVGhlIDx0dD5yZXNw b25zZV90eXBlPC90dD4gZWxlbWVudCBpcyBkZWZpbmVkIGluCgkgICAgPGEgY2xhc3M9J2luZm8n IGhyZWY9JyNyZXNwb25zZS10eXBlJz5TZWN0aW9uJm5ic3A7My4xLjE8c3Bhbj4gKDwvc3Bhbj48 c3BhbiBjbGFzcz0naW5mbyc+UmVzcG9uc2UgVHlwZTwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4g YW5kCgkgICAgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNyZXNwb25zZS10eXBlLWV4dCc+U2VjdGlv biZuYnNwOzguNDxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5EZWZpbmluZyBOZXcg QXV0aG9yaXphdGlvbiBFbmRwb2ludCBSZXNwb25zZSBUeXBlczwvc3Bhbj48c3Bhbj4pPC9zcGFu PjwvYT46CgkgIAo8L3A+PGRpdiBzdHlsZT0nZGlzcGxheTogdGFibGU7IHdpZHRoOiAwOyBtYXJn aW4tbGVmdDogM2VtOyBtYXJnaW4tcmlnaHQ6IGF1dG8nPjxwcmU+CnJlc3BvbnNlLXR5cGUgPSBy ZXNwb25zZS1uYW1lICooIFNQIHJlc3BvbnNlLW5hbWUgKQpyZXNwb25zZS1uYW1lID0gMSpyZXNw b25zZS1jaGFyCnJlc3BvbnNlLWNoYXIgPSAiXyIgLyBESUdJVCAvIEFMUEhBCjwvcHJlPjwvZGl2 Pgo8YSBuYW1lPSJhbmNob3I1OSI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5 b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWdu PSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0Mm bmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLkEuNCI+PC9h PjxoMz5BLjQuJm5ic3A7CiJzY29wZSIgU3ludGF4PC9oMz4KCjxwPgoJICAgIFRoZSA8dHQ+c2Nv cGU8L3R0PiBlbGVtZW50IGlzIGRlZmluZWQgaW4KCSAgICA8YSBjbGFzcz0naW5mbycgaHJlZj0n I3Njb3BlJz5TZWN0aW9uJm5ic3A7My4zPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8n PkFjY2VzcyBUb2tlbiBTY29wZTwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT46CgkgIAo8L3A+PGRp diBzdHlsZT0nZGlzcGxheTogdGFibGU7IHdpZHRoOiAwOyBtYXJnaW4tbGVmdDogM2VtOyBtYXJn aW4tcmlnaHQ6IGF1dG8nPjxwcmU+CnNjb3BlICAgICAgID0gc2NvcGUtdG9rZW4gKiggU1Agc2Nv cGUtdG9rZW4gKQpzY29wZS10b2tlbiA9IDEqKCAleDIxIC8gJXgyMy01QiAvICV4NUQtN0UgKQo8 L3ByZT48L2Rpdj4KPGEgbmFtZT0iYW5jaG9yNjAiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1 bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9D YnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+ Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlv bi5BLjUiPjwvYT48aDM+QS41LiZuYnNwOwoic3RhdGUiIFN5bnRheDwvaDM+Cgo8cD4KCSAgICBU aGUgPHR0PnN0YXRlPC90dD4gZWxlbWVudCBpcyBkZWZpbmVkIGluCgkgICAgPGEgY2xhc3M9J2lu Zm8nIGhyZWY9JyNjb2RlLWF1dGh6LXJlcSc+U2VjdGlvbiZuYnNwOzQuMS4xPHNwYW4+ICg8L3Nw YW4+PHNwYW4gY2xhc3M9J2luZm8nPkF1dGhvcml6YXRpb24gUmVxdWVzdDwvc3Bhbj48c3Bhbj4p PC9zcGFuPjwvYT4sCgkgICAgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNjb2RlLWF1dGh6LXJlc3An PlNlY3Rpb24mbmJzcDs0LjEuMjxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5BdXRo b3JpemF0aW9uIFJlc3BvbnNlPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPiwKCSAgICA8YSBjbGFz cz0naW5mbycgaHJlZj0nI2NvZGUtYXV0aHotZXJyb3InPlNlY3Rpb24mbmJzcDs0LjEuMi4xPHNw YW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkVycm9yIFJlc3BvbnNlPC9zcGFuPjxzcGFu Pik8L3NwYW4+PC9hPiwKCSAgICA8YSBjbGFzcz0naW5mbycgaHJlZj0nI2ltcGxpY2l0LWF1dGh6 LXJlcSc+U2VjdGlvbiZuYnNwOzQuMi4xPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8n PkF1dGhvcml6YXRpb24gUmVxdWVzdDwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4sCgkgICAgPGEg Y2xhc3M9J2luZm8nIGhyZWY9JyNpbXBsaWNpdC1hdXRoei1yZXNwJz5TZWN0aW9uJm5ic3A7NC4y LjI8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+QWNjZXNzIFRva2VuIFJlc3BvbnNl PC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPiwgYW5kCgkgICAgPGEgY2xhc3M9J2luZm8nIGhyZWY9 JyNpbXBsaWNpdC1hdXRoei1lcnJvcic+U2VjdGlvbiZuYnNwOzQuMi4yLjE8c3Bhbj4gKDwvc3Bh bj48c3BhbiBjbGFzcz0naW5mbyc+RXJyb3IgUmVzcG9uc2U8L3NwYW4+PHNwYW4+KTwvc3Bhbj48 L2E+OgoJICAKPC9wPjxkaXYgc3R5bGU9J2Rpc3BsYXk6IHRhYmxlOyB3aWR0aDogMDsgbWFyZ2lu LWxlZnQ6IDNlbTsgbWFyZ2luLXJpZ2h0OiBhdXRvJz48cHJlPgpzdGF0ZSAgICAgID0gMSp1bnJl c2VydmVkCjwvcHJlPjwvZGl2Pgo8YSBuYW1lPSJhbmNob3I2MSI+PC9hPjxiciAvPjxociAvPgo8 dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNs YXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVm PSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJm Yy5zZWN0aW9uLkEuNiI+PC9hPjxoMz5BLjYuJm5ic3A7CiJyZWRpcmVjdF91cmkiIFN5bnRheDwv aDM+Cgo8cD4KCSAgICBUaGUgPHR0PnJlZGlyZWN0X3VyaTwvdHQ+IGVsZW1lbnQgaXMgZGVmaW5l ZCBpbgoJICAgIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjY29kZS1hdXRoei1yZXEnPlNlY3Rpb24m bmJzcDs0LjEuMTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5BdXRob3JpemF0aW9u IFJlcXVlc3Q8L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+LAoJICAgIDxhIGNsYXNzPSdpbmZvJyBo cmVmPScjdG9rZW4tcmVxJz5TZWN0aW9uJm5ic3A7NC4xLjM8c3Bhbj4gKDwvc3Bhbj48c3BhbiBj bGFzcz0naW5mbyc+QWNjZXNzIFRva2VuIFJlcXVlc3Q8L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+ LCBhbmQKCSAgICA8YSBjbGFzcz0naW5mbycgaHJlZj0nI2ltcGxpY2l0LWF1dGh6LXJlcSc+U2Vj dGlvbiZuYnNwOzQuMi4xPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkF1dGhvcml6 YXRpb24gUmVxdWVzdDwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT46CgkgIAo8L3A+PGRpdiBzdHls ZT0nZGlzcGxheTogdGFibGU7IHdpZHRoOiAwOyBtYXJnaW4tbGVmdDogM2VtOyBtYXJnaW4tcmln aHQ6IGF1dG8nPjxwcmU+CnJlZGlyZWN0LXVyaSAgICAgID0gVVJJCjwvcHJlPjwvZGl2Pgo8YSBu YW1lPSJhbmNob3I2MiI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBj ZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdo dCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8 L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLkEuNyI+PC9hPjxoMz5B LjcuJm5ic3A7CiJlcnJvciIgU3ludGF4PC9oMz4KCjxwPgoJICAgIFRoZSA8dHQ+ZXJyb3I8L3R0 PiBlbGVtZW50IGlzIGRlZmluZWQgaW4KCSAgICA8YSBjbGFzcz0naW5mbycgaHJlZj0nI2NvZGUt YXV0aHotZXJyb3InPlNlY3Rpb24mbmJzcDs0LjEuMi4xPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xh c3M9J2luZm8nPkVycm9yIFJlc3BvbnNlPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPiwKCSAgICA8 YSBjbGFzcz0naW5mbycgaHJlZj0nI2ltcGxpY2l0LWF1dGh6LWVycm9yJz5TZWN0aW9uJm5ic3A7 NC4yLjIuMTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5FcnJvciBSZXNwb25zZTwv c3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4sCgkgICAgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyN0b2tl bi1lcnJvcnMnPlNlY3Rpb24mbmJzcDs1LjI8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5m byc+RXJyb3IgUmVzcG9uc2U8L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+LAoJICAgIDxhIGNsYXNz PSdpbmZvJyBocmVmPScjcmVzb3VyY2UtZXJyb3JzJz5TZWN0aW9uJm5ic3A7Ny4yPHNwYW4+ICg8 L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkVycm9yIFJlc3BvbnNlPC9zcGFuPjxzcGFuPik8L3Nw YW4+PC9hPiwgYW5kCgkgICAgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNuZXctZXJyb3JzJz5TZWN0 aW9uJm5ic3A7OC41PHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkRlZmluaW5nIEFk ZGl0aW9uYWwgRXJyb3IgQ29kZXM8L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+OgoJICAKPC9wPjxk aXYgc3R5bGU9J2Rpc3BsYXk6IHRhYmxlOyB3aWR0aDogMDsgbWFyZ2luLWxlZnQ6IDNlbTsgbWFy Z2luLXJpZ2h0OiBhdXRvJz48cHJlPgplcnJvciAgICAgICAgICAgICA9IDEqZXJyb3ItY2hhcgpl cnJvci1jaGFyICAgICAgICA9ICV4MjAtMjEgLyAleDIzLTVCIC8gJXg1RC03RQo8L3ByZT48L2Rp dj4KPGEgbmFtZT0iYW5jaG9yNjMiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9Imxh eW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGln bj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9D Jm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi5BLjgiPjwv YT48aDM+QS44LiZuYnNwOwoiZXJyb3JfZGVzY3JpcHRpb24iIFN5bnRheDwvaDM+Cgo8cD4KCSAg ICBUaGUgPHR0PmVycm9yX2Rlc2NyaXB0aW9uPC90dD4gZWxlbWVudCBpcyBkZWZpbmVkIGluCgkg ICAgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNjb2RlLWF1dGh6LWVycm9yJz5TZWN0aW9uJm5ic3A7 NC4xLjIuMTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5FcnJvciBSZXNwb25zZTwv c3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4sCgkgICAgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNpbXBs aWNpdC1hdXRoei1lcnJvcic+U2VjdGlvbiZuYnNwOzQuMi4yLjE8c3Bhbj4gKDwvc3Bhbj48c3Bh biBjbGFzcz0naW5mbyc+RXJyb3IgUmVzcG9uc2U8L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+LAoJ ICAgIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjdG9rZW4tZXJyb3JzJz5TZWN0aW9uJm5ic3A7NS4y PHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkVycm9yIFJlc3BvbnNlPC9zcGFuPjxz cGFuPik8L3NwYW4+PC9hPiwgYW5kCgkgICAgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNyZXNvdXJj ZS1lcnJvcnMnPlNlY3Rpb24mbmJzcDs3LjI8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5m byc+RXJyb3IgUmVzcG9uc2U8L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+OgoJICAKPC9wPjxkaXYg c3R5bGU9J2Rpc3BsYXk6IHRhYmxlOyB3aWR0aDogMDsgbWFyZ2luLWxlZnQ6IDNlbTsgbWFyZ2lu LXJpZ2h0OiBhdXRvJz48cHJlPgplcnJvci1kZXNjcmlwdGlvbiA9IDEqZXJyb3ItY2hhcgplcnJv ci1jaGFyICAgICAgICA9ICV4MjAtMjEgLyAleDIzLTVCIC8gJXg1RC03RQo8L3ByZT48L2Rpdj4K PGEgbmFtZT0iYW5jaG9yNjQiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91 dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0i cmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5i c3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi5BLjkiPjwvYT48 aDM+QS45LiZuYnNwOwoiZXJyb3JfdXJpIiBTeW50YXg8L2gzPgoKPHA+CgkgICAgVGhlIDx0dD5l cnJvcl91cmk8L3R0PiBlbGVtZW50IGlzIGRlZmluZWQgaW4KCSAgICA8YSBjbGFzcz0naW5mbycg aHJlZj0nI2NvZGUtYXV0aHotZXJyb3InPlNlY3Rpb24mbmJzcDs0LjEuMi4xPHNwYW4+ICg8L3Nw YW4+PHNwYW4gY2xhc3M9J2luZm8nPkVycm9yIFJlc3BvbnNlPC9zcGFuPjxzcGFuPik8L3NwYW4+ PC9hPiwKCSAgICA8YSBjbGFzcz0naW5mbycgaHJlZj0nI2ltcGxpY2l0LWF1dGh6LWVycm9yJz5T ZWN0aW9uJm5ic3A7NC4yLjIuMTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5FcnJv ciBSZXNwb25zZTwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4sCgkgICAgPGEgY2xhc3M9J2luZm8n IGhyZWY9JyN0b2tlbi1lcnJvcnMnPlNlY3Rpb24mbmJzcDs1LjI8c3Bhbj4gKDwvc3Bhbj48c3Bh biBjbGFzcz0naW5mbyc+RXJyb3IgUmVzcG9uc2U8L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+LCBh bmQKCSAgICA8YSBjbGFzcz0naW5mbycgaHJlZj0nI3Jlc291cmNlLWVycm9ycyc+U2VjdGlvbiZu YnNwOzcuMjxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5FcnJvciBSZXNwb25zZTwv c3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT46CgkgIAo8L3A+PGRpdiBzdHlsZT0nZGlzcGxheTogdGFi bGU7IHdpZHRoOiAwOyBtYXJnaW4tbGVmdDogM2VtOyBtYXJnaW4tcmlnaHQ6IGF1dG8nPjxwcmU+ CmVycm9yLXVyaSAgICAgICAgID0gVVJJCjwvcHJlPjwvZGl2Pgo8YSBuYW1lPSJhbmNob3I2NSI+ PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIg Y2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFz cz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwv dGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLkEuMTAiPjwvYT48aDM+QS4xMC4mbmJzcDsKImdy YW50X3R5cGUiIFN5bnRheDwvaDM+Cgo8cD4KCSAgICBUaGUgPHR0PmdyYW50X3R5cGU8L3R0PiBl bGVtZW50IGlzIGRlZmluZWQgaW4KCSAgICA8YSBjbGFzcz0naW5mbycgaHJlZj0nI3Rva2VuLXJl cSc+U2VjdGlvbiZuYnNwOzQuMS4zPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkFj Y2VzcyBUb2tlbiBSZXF1ZXN0PC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPiwKCSAgICA8YSBjbGFz cz0naW5mbycgaHJlZj0nI3Bhc3N3b3JkLXRvay1yZXEnPlNlY3Rpb24mbmJzcDs0LjMuMjxzcGFu PiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5BY2Nlc3MgVG9rZW4gUmVxdWVzdDwvc3Bhbj48 c3Bhbj4pPC9zcGFuPjwvYT4sCgkgICAgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNjbGllbnQtcmVx LXJlc3AnPlNlY3Rpb24mbmJzcDs0LjQuMTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZv Jz5BdXRob3JpemF0aW9uIFJlcXVlc3QgYW5kIFJlc3BvbnNlPC9zcGFuPjxzcGFuPik8L3NwYW4+ PC9hPiwKCSAgICA8YSBjbGFzcz0naW5mbycgaHJlZj0nI3Rva2VuLXJlZnJlc2gnPlNlY3Rpb24m bmJzcDs2PHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPlJlZnJlc2hpbmcgYW4gQWNj ZXNzIFRva2VuPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPiwgYW5kCgkgICAgPGEgY2xhc3M9J2lu Zm8nIGhyZWY9JyNleHQtZ3JhbnQnPlNlY3Rpb24mbmJzcDs0LjU8c3Bhbj4gKDwvc3Bhbj48c3Bh biBjbGFzcz0naW5mbyc+RXh0ZW5zaW9uIEdyYW50czwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT46 CgkgIAo8L3A+PGRpdiBzdHlsZT0nZGlzcGxheTogdGFibGU7IHdpZHRoOiAwOyBtYXJnaW4tbGVm dDogM2VtOyBtYXJnaW4tcmlnaHQ6IGF1dG8nPjxwcmU+CmdyYW50LXR5cGUgPSBncmFudC1uYW1l IC8gVVJJCmdyYW50LW5hbWUgPSAxKm5hbWUtY2hhcgpuYW1lLWNoYXIgID0gIi0iIC8gIi4iIC8g Il8iIC8gRElHSVQgLyBBTFBIQQo8L3ByZT48L2Rpdj4KPGEgbmFtZT0iYW5jaG9yNjYiPjwvYT48 YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxz cGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRP Q2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxl Pgo8YSBuYW1lPSJyZmMuc2VjdGlvbi5BLjExIj48L2E+PGgzPkEuMTEuJm5ic3A7CiJjb2RlIiBT eW50YXg8L2gzPgoKPHA+CgkgICAgVGhlIDx0dD5jb2RlPC90dD4gZWxlbWVudCBpcyBkZWZpbmVk IGluCgkgICAgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyN0b2tlbi1yZXEnPlNlY3Rpb24mbmJzcDs0 LjEuMzxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5BY2Nlc3MgVG9rZW4gUmVxdWVz dDwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT46CgkgIAo8L3A+PGRpdiBzdHlsZT0nZGlzcGxheTog dGFibGU7IHdpZHRoOiAwOyBtYXJnaW4tbGVmdDogM2VtOyBtYXJnaW4tcmlnaHQ6IGF1dG8nPjxw cmU+CmNvZGUgICAgICAgPSAxKnVucmVzZXJ2ZWQKPC9wcmU+PC9kaXY+CjxhIG5hbWU9ImFuY2hv cjY3Ij48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5n PSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRk IGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwv dHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uQS4xMiI+PC9hPjxoMz5BLjEyLiZuYnNw OwoiYWNjZXNzX3Rva2VuIiBTeW50YXg8L2gzPgoKPHA+CgkgICAgVGhlIDx0dD5hY2Nlc3NfdG9r ZW48L3R0PiBlbGVtZW50IGlzIGRlZmluZWQgaW4KCSAgICA8YSBjbGFzcz0naW5mbycgaHJlZj0n I2ltcGxpY2l0LWF1dGh6LXJlc3AnPlNlY3Rpb24mbmJzcDs0LjIuMjxzcGFuPiAoPC9zcGFuPjxz cGFuIGNsYXNzPSdpbmZvJz5BY2Nlc3MgVG9rZW4gUmVzcG9uc2U8L3NwYW4+PHNwYW4+KTwvc3Bh bj48L2E+IGFuZAoJICAgIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjdG9rZW4tcmVzcG9uc2UnPlNl Y3Rpb24mbmJzcDs1LjE8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+U3VjY2Vzc2Z1 bCBSZXNwb25zZTwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT46CgkgIAo8L3A+PGRpdiBzdHlsZT0n ZGlzcGxheTogdGFibGU7IHdpZHRoOiAwOyBtYXJnaW4tbGVmdDogM2VtOyBtYXJnaW4tcmlnaHQ6 IGF1dG8nPjxwcmU+CmFjY2Vzcy10b2tlbiA9IGI2NHRva2VuCjwvcHJlPjwvZGl2Pgo8YSBuYW1l PSJhbmNob3I2OCI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxs cGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+ PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+ PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLkEuMTMiPjwvYT48aDM+QS4x My4mbmJzcDsKInRva2VuX3R5cGUiIFN5bnRheDwvaDM+Cgo8cD4KCSAgICBUaGUgPHR0PnRva2Vu X3R5cGU8L3R0PiBlbGVtZW50IGlzIGRlZmluZWQgaW4KCSAgICA8YSBjbGFzcz0naW5mbycgaHJl Zj0nI2ltcGxpY2l0LWF1dGh6LXJlc3AnPlNlY3Rpb24mbmJzcDs0LjIuMjxzcGFuPiAoPC9zcGFu PjxzcGFuIGNsYXNzPSdpbmZvJz5BY2Nlc3MgVG9rZW4gUmVzcG9uc2U8L3NwYW4+PHNwYW4+KTwv c3Bhbj48L2E+LAoJICAgIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjdG9rZW4tcmVzcG9uc2UnPlNl Y3Rpb24mbmJzcDs1LjE8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+U3VjY2Vzc2Z1 bCBSZXNwb25zZTwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4sIGFuZAoJICAgIDxhIGNsYXNzPSdp bmZvJyBocmVmPScjbmV3LXR5cGVzJz5TZWN0aW9uJm5ic3A7OC4xPHNwYW4+ICg8L3NwYW4+PHNw YW4gY2xhc3M9J2luZm8nPkRlZmluaW5nIEFjY2VzcyBUb2tlbiBUeXBlczwvc3Bhbj48c3Bhbj4p PC9zcGFuPjwvYT46CgkgIAo8L3A+PGRpdiBzdHlsZT0nZGlzcGxheTogdGFibGU7IHdpZHRoOiAw OyBtYXJnaW4tbGVmdDogM2VtOyBtYXJnaW4tcmlnaHQ6IGF1dG8nPjxwcmU+CnRva2VuLXR5cGUg PSB0eXBlLW5hbWUgLyBVUkkKdHlwZS1uYW1lICA9IDEqbmFtZS1jaGFyCm5hbWUtY2hhciAgPSAi LSIgLyAiLiIgLyAiXyIgLyBESUdJVCAvIEFMUEhBCjwvcHJlPjwvZGl2Pgo8YSBuYW1lPSJhbmNo b3I2OSI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGlu Zz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0 ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48 L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLkEuMTQiPjwvYT48aDM+QS4xNC4mbmJz cDsKImV4cGlyZXNfaW4iIFN5bnRheDwvaDM+Cgo8cD4KCSAgICBUaGUgPHR0PmV4cGlyZXNfaW48 L3R0PiBlbGVtZW50IGlzIGRlZmluZWQgaW4KCSAgICA8YSBjbGFzcz0naW5mbycgaHJlZj0nI2lt cGxpY2l0LWF1dGh6LXJlc3AnPlNlY3Rpb24mbmJzcDs0LjIuMjxzcGFuPiAoPC9zcGFuPjxzcGFu IGNsYXNzPSdpbmZvJz5BY2Nlc3MgVG9rZW4gUmVzcG9uc2U8L3NwYW4+PHNwYW4+KTwvc3Bhbj48 L2E+IGFuZAoJICAgIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjdG9rZW4tcmVzcG9uc2UnPlNlY3Rp b24mbmJzcDs1LjE8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+U3VjY2Vzc2Z1bCBS ZXNwb25zZTwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT46CgkgIAo8L3A+PGRpdiBzdHlsZT0nZGlz cGxheTogdGFibGU7IHdpZHRoOiAwOyBtYXJnaW4tbGVmdDogM2VtOyBtYXJnaW4tcmlnaHQ6IGF1 dG8nPjxwcmU+CmV4cGlyZXMtaW4gPSAxKkRJR0lUCjwvcHJlPjwvZGl2Pgo8YSBuYW1lPSJhbmNo b3I3MCI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGlu Zz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0 ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48 L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLkEuMTUiPjwvYT48aDM+QS4xNS4mbmJz cDsKInVzZXJuYW1lIiBTeW50YXg8L2gzPgoKPHA+CgkgICAgVGhlIDx0dD51c2VybmFtZTwvdHQ+ IGVsZW1lbnQgaXMgZGVmaW5lZCBpbgoJICAgIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjcGFzc3dv cmQtdG9rLXJlcSc+U2VjdGlvbiZuYnNwOzQuMy4yPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9 J2luZm8nPkFjY2VzcyBUb2tlbiBSZXF1ZXN0PC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPjoKCSAg CjwvcD48ZGl2IHN0eWxlPSdkaXNwbGF5OiB0YWJsZTsgd2lkdGg6IDA7IG1hcmdpbi1sZWZ0OiAz ZW07IG1hcmdpbi1yaWdodDogYXV0byc+PHByZT4KdXNlcm5hbWUgPSAqJmx0O1RFWFQgZXhjbHVk aW5nICI6IiZndDsKPC9wcmU+PC9kaXY+CjxwPgoJICAoVGhpcyBtYXRjaGVzIHRoZSA8dHQ+dXNl cmlkPC90dD4gZGVmaW5pdGlvbiBpbiB0aGUKCSAgSFRUUCBCYXNpYyBBdXRoZW50aWNhdGlvbiBT Y2hlbWUgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNSRkMyNjE3Jz5bUkZDMjYxN108c3Bhbj4gKDwv c3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+RnJhbmtzLCBKLiwgSGFsbGFtLUJha2VyLCBQLiwgSG9z dGV0bGVyLCBKLiwgTGF3cmVuY2UsIFMuLCBMZWFjaCwgUC4sIEx1b3RvbmVuLCBBLiwgYW5kIEwu IFN0ZXdhcnQsICZsZHF1bztIVFRQIEF1dGhlbnRpY2F0aW9uOiBCYXNpYyBhbmQgRGlnZXN0IEFj Y2VzcyBBdXRoZW50aWNhdGlvbiwmcmRxdW87IEp1bmUmbmJzcDsxOTk5Ljwvc3Bhbj48c3Bhbj4p PC9zcGFuPjwvYT4uKQoJCjwvcD4KPGEgbmFtZT0iYW5jaG9yNzEiPjwvYT48YnIgLz48aHIgLz4K PHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBj bGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJl Zj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJy ZmMuc2VjdGlvbi5BLjE2Ij48L2E+PGgzPkEuMTYuJm5ic3A7CiJwYXNzd29yZCIgU3ludGF4PC9o Mz4KCjxwPgoJICAgIFRoZSA8dHQ+cGFzc3dvcmQ8L3R0PiBlbGVtZW50IGlzIGRlZmluZWQgaW4K CSAgICA8YSBjbGFzcz0naW5mbycgaHJlZj0nI3Bhc3N3b3JkLXRvay1yZXEnPlNlY3Rpb24mbmJz cDs0LjMuMjxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5BY2Nlc3MgVG9rZW4gUmVx dWVzdDwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT46CgkgIAo8L3A+PGRpdiBzdHlsZT0nZGlzcGxh eTogdGFibGU7IHdpZHRoOiAwOyBtYXJnaW4tbGVmdDogM2VtOyBtYXJnaW4tcmlnaHQ6IGF1dG8n PjxwcmU+CnBhc3N3b3JkID0gKlRFWFQKPC9wcmU+PC9kaXY+CjxwPgoJICAoVGhpcyBtYXRjaGVz IHRoZSA8dHQ+cGFzc3dvcmQ8L3R0PiBkZWZpbml0aW9uIGluIHRoZQoJICBIVFRQIEJhc2ljIEF1 dGhlbnRpY2F0aW9uIFNjaGVtZSA8YSBjbGFzcz0naW5mbycgaHJlZj0nI1JGQzI2MTcnPltSRkMy NjE3XTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5GcmFua3MsIEouLCBIYWxsYW0t QmFrZXIsIFAuLCBIb3N0ZXRsZXIsIEouLCBMYXdyZW5jZSwgUy4sIExlYWNoLCBQLiwgTHVvdG9u ZW4sIEEuLCBhbmQgTC4gU3Rld2FydCwgJmxkcXVvO0hUVFAgQXV0aGVudGljYXRpb246IEJhc2lj IGFuZCBEaWdlc3QgQWNjZXNzIEF1dGhlbnRpY2F0aW9uLCZyZHF1bzsgSnVuZSZuYnNwOzE5OTku PC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPi4pCgkKPC9wPgo8YSBuYW1lPSJhbmNob3I3MiI+PC9h PjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2Vs bHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0i VE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFi bGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLkEuMTciPjwvYT48aDM+QS4xNy4mbmJzcDsKInJlZnJl c2hfdG9rZW4iIFN5bnRheDwvaDM+Cgo8cD4KCSAgICBUaGUgPHR0PnJlZnJlc2hfdG9rZW48L3R0 PiBlbGVtZW50IGlzIGRlZmluZWQgaW4KCSAgICA8YSBjbGFzcz0naW5mbycgaHJlZj0nI3Rva2Vu LXJlc3BvbnNlJz5TZWN0aW9uJm5ic3A7NS4xPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2lu Zm8nPlN1Y2Nlc3NmdWwgUmVzcG9uc2U8L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+IGFuZAoJICAg IDxhIGNsYXNzPSdpbmZvJyBocmVmPScjdG9rZW4tcmVmcmVzaCc+U2VjdGlvbiZuYnNwOzY8c3Bh bj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+UmVmcmVzaGluZyBhbiBBY2Nlc3MgVG9rZW48 L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+OgoJICAKPC9wPjxkaXYgc3R5bGU9J2Rpc3BsYXk6IHRh YmxlOyB3aWR0aDogMDsgbWFyZ2luLWxlZnQ6IDNlbTsgbWFyZ2luLXJpZ2h0OiBhdXRvJz48cHJl PgpyZWZyZXNoLXRva2VuID0gYjY0dG9rZW4KPC9wcmU+PC9kaXY+CjxhIG5hbWU9ImFuY2hvcjcz Ij48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIw IiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNs YXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+ PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uQS4xOCI+PC9hPjxoMz5BLjE4LiZuYnNwOwpF bmRwb2ludCBQYXJhbWV0ZXIgU3ludGF4PC9oMz4KCjxwPgoJICAgIFRoZSBzeW50YXggZm9yIG5l dyBlbmRwb2ludCBwYXJhbWV0ZXJzIGlzIGRlZmluZWQgaW4KCSAgICA8YSBjbGFzcz0naW5mbycg aHJlZj0nI2VuZHBvaW50LXBhcmFtcyc+U2VjdGlvbiZuYnNwOzguMjxzcGFuPiAoPC9zcGFuPjxz cGFuIGNsYXNzPSdpbmZvJz5EZWZpbmluZyBOZXcgRW5kcG9pbnQgUGFyYW1ldGVyczwvc3Bhbj48 c3Bhbj4pPC9zcGFuPjwvYT46CgkgIAo8L3A+PGRpdiBzdHlsZT0nZGlzcGxheTogdGFibGU7IHdp ZHRoOiAwOyBtYXJnaW4tbGVmdDogM2VtOyBtYXJnaW4tcmlnaHQ6IGF1dG8nPjxwcmU+CnBhcmFt LW5hbWUgPSAxKm5hbWUtY2hhcgpuYW1lLWNoYXIgID0gIi0iIC8gIi4iIC8gIl8iIC8gRElHSVQg LyBBTFBIQQo8L3ByZT48L2Rpdj4KPGEgbmFtZT0iYW5jaG9yNzQiPjwvYT48YnIgLz48aHIgLz4K PHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBj bGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJl Zj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJy ZmMuc2VjdGlvbi5CIj48L2E+PGgzPkFwcGVuZGl4IEIuJm5ic3A7CkFja25vd2xlZGdlbWVudHM8 L2gzPgoKPHA+CiAgICAgICAgVGhlIGluaXRpYWwgT0F1dGggMi4wIHByb3RvY29sIHNwZWNpZmlj YXRpb24gd2FzIGVkaXRlZCBieSBEYXZpZCBSZWNvcmRvbiwgYmFzZWQgb24gdHdvCiAgICAgICAg cHJldmlvdXMgcHVibGljYXRpb25zOiB0aGUgT0F1dGggMS4wIGNvbW11bml0eSBzcGVjaWZpY2F0 aW9uIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjUkZDNTg0OSc+W1JGQzU4NDldPHNwYW4+ICg8L3Nw YW4+PHNwYW4gY2xhc3M9J2luZm8nPkhhbW1lci1MYWhhdiwgRS4sICZsZHF1bztUaGUgT0F1dGgg MS4wIFByb3RvY29sLCZyZHF1bzsgQXByaWwmbmJzcDsyMDEwLjwvc3Bhbj48c3Bhbj4pPC9zcGFu PjwvYT4sIGFuZAogICAgICAgIE9BdXRoIFdSQVAgKE9BdXRoIFdlYiBSZXNvdXJjZSBBdXRob3Jp emF0aW9uIFByb2ZpbGVzKQogICAgICAgIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjSS1ELmRyYWZ0 LWhhcmR0LW9hdXRoLTAxJz5bSSYjODIwOTtELmRyYWZ0JiM4MjA5O2hhcmR0JiM4MjA5O29hdXRo JiM4MjA5OzAxXTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5IYXJkdCwgRC4sIEVk LiwgVG9tLCBBLiwgRWF0b24sIEIuLCBhbmQgWS4gR29sYW5kLCAmbGRxdW87T0F1dGggV2ViIFJl c291cmNlIEF1dGhvcml6YXRpb24gUHJvZmlsZXMsJnJkcXVvOyBKYW51YXJ5Jm5ic3A7MjAxMC48 L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+LiBUaGUgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgc2Vj dGlvbiB3YXMgZHJhZnRlZAogICAgICAgIGJ5IFRvcnN0ZW4gTG9kZGVyc3RlZHQsIE1hcmsgTWNH bG9pbiwgUGhpbCBIdW50LCBhbmQgQW50aG9ueSBOYWRhbGluLgoJVGhlIEFCTkYgc2VjdGlvbiB3 YXMgZHJhZnRlZCBieSBNaWNoYWVsIEIuIEpvbmVzLgogICAgICAKPC9wPgo8cD4KICAgICAgICBU aGUgT0F1dGggMS4wIGNvbW11bml0eSBzcGVjaWZpY2F0aW9uIHdhcyBlZGl0ZWQgYnkgRXJhbiBI YW1tZXIgYW5kIGF1dGhvcmVkIGJ5CiAgICAgICAgTWFyayBBdHdvb2QsIERpcmsgQmFsZmFueiwg RGFycmVuIEJvdW5kcywgUmljaGFyZCBNLiBDb25sYW4sIEJsYWluZSBDb29rLCBMZWFoIEN1bHZl ciwKICAgICAgICBCcmVubyBkZSBNZWRlaXJvcywgQnJpYW4gRWF0b24sIEtlbGxhbiBFbGxpb3R0 LU1jQ3JlYSwgTGFycnkgSGFsZmYsIEVyYW4gSGFtbWVyLAogICAgICAgIEJlbiBMYXVyaWUsIENo cmlzIE1lc3NpbmEsIEpvaG4gUGFuemVyLCBTYW0gUXVpZ2xleSwgRGF2aWQgUmVjb3Jkb24sIEVy YW4gU2FuZGxlciwKICAgICAgICBKb25hdGhhbiBTZXJnZW50LCBUb2RkIFNpZWxpbmcsIEJyaWFu IFNsZXNpbnNreSwgYW5kIEFuZHkgU21pdGguCiAgICAgIAo8L3A+CjxwPgogICAgICAgIFRoZSBP QXV0aCBXUkFQIHNwZWNpZmljYXRpb24gd2FzIGVkaXRlZCBieSBEaWNrIEhhcmR0IGFuZCBhdXRo b3JlZCBieSBCcmlhbiBFYXRvbiwKICAgICAgICBZYXJvbiBZLiBHb2xhbmQsIERpY2sgSGFyZHQs IGFuZCBBbGxlbiBUb20uCiAgICAgIAo8L3A+CjxwPgogICAgICAgIFRoaXMgc3BlY2lmaWNhdGlv biBpcyB0aGUgd29yayBvZiB0aGUgT0F1dGggV29ya2luZyBHcm91cCB3aGljaCBpbmNsdWRlcyBk b3plbnMgb2YgYWN0aXZlCiAgICAgICAgYW5kIGRlZGljYXRlZCBwYXJ0aWNpcGFudHMuIEluIHBh cnRpY3VsYXIsIHRoZSBmb2xsb3dpbmcgaW5kaXZpZHVhbHMgY29udHJpYnV0ZWQgaWRlYXMsCiAg ICAgICAgZmVlZGJhY2ssIGFuZCB3b3JkaW5nIHdoaWNoIHNoYXBlZCBhbmQgZm9ybWVkIHRoZSBm aW5hbCBzcGVjaWZpY2F0aW9uOgogICAgICAKPC9wPgo8cD4KICAgICAgICBNaWNoYWVsIEFkYW1z LCBBbWFuZGEgQW5nYW5lcywgQW5kcmV3IEFybm90dCwgRGlyayBCYWxmYW56LCBBaWRlbiBCZWxs LCBCcmlhbiBDYW1wYmVsbCwKICAgICAgICBTY290dCBDYW50b3IsIE1hcmNvcyBDYWNlcmVzLCBC bGFpbmUgQ29vaywgUm9nZXIgQ3JldywgQnJpYW4gRWF0b24sIFdlc2xleSBFZGR5LCBMZWFoIEN1 bHZlciwKICAgICAgICBCaWxsIGRlIGhPcmEsIEFuZHJlIERlTWFycmUsIEJyaWFuIEVhdG9uLCBX b2x0ZXIgRWxkZXJpbmcsIEJyaWFuIEVsbGluLCBJZ29yIEZheW5iZXJnLAogICAgICAgIEdlb3Jn ZSBGbGV0Y2hlciwgVGltIEZyZWVtYW4sIEx1Y2EgRnJvc2luaSwgRXZhbiBHaWxiZXJ0LCBZYXJv biBZLiBHb2xhbmQsIEJyZW50IEdvbGRtYW4sCiAgICAgICAgS3Jpc3RvZmZlciBHcm9ub3dza2ks IEp1c3RpbiBIYXJ0LCBEaWNrIEhhcmR0LCBDcmFpZyBIZWF0aCwgUGhpbCBIdW50LCBNaWNoYWVs IEIuIEpvbmVzLAogICAgICAgIFRlcnJ5IEpvbmVzLCBKb2huIEtlbXAsIE1hcmsgS2VudCwgUmFm ZmkgS3Jpa29yaWFuLCBDaGFzZW4gTGUgSGFyYSwgUmFzbXVzIExlcmRvcmYsCiAgICAgICAgVG9y c3RlbiBMb2RkZXJzdGVkdCwgSHVpLUxhbiBMdSwgQ2FzZXkgTHVjYXMsIFBhdWwgTWFkc2VuLCBB bGFzdGFpciBNYWlyLCBFdmUgTWFsZXIsCiAgICAgICAgSmFtZXMgTWFuZ2VyLCBNYXJrIE1jR2xv aW4sIExhdXJlbmNlIE1pYW8sIFdpbGxpYW0gTWlsbHMsIENodWNrIE1vcnRpbW9yZSwgQW50aG9u eSBOYWRhbGluLAogICAgICAgIEp1bGlhbiBSZXNjaGtlLCBKdXN0aW4gUmljaGVyLCBQZXRlciBT YWludC1BbmRyZSwgTmF0IFNha2ltdXJhLCBSb2IgU2F5cmUsCiAgICAgICAgTWFyaXVzIFNjdXJ0 ZXNjdSwgTmFpdGlrIFNoYWgsIEx1a2UgU2hlcGFyZCwgVmxhZCBTa3ZvcnRzb3YsIEp1c3RpbiBT bWl0aCwgSGFpYmluIFNvbmcsCiAgICAgICAgTml2IFN0ZWluZ2FydGVuLCBDaHJpc3RpYW4gU3R1 Ym5lciwgSmVyZW15IFN1cmllbCwgUGF1bCBUYXJqYW4sIENocmlzdG9waGVyIFRob21hcywKICAg ICAgICBIZW5yeSBTLiBUaG9tcHNvbiwgQWxsZW4gVG9tLCBGcmFua2xpbiBUc2UsIE5pY2sgV2Fs a2VyLCBTaGFuZSBXZWVkZW4sIGFuZCBTa3lsYXIgV29vZHdhcmQuCiAgICAgIAo8L3A+CjxwPgog ICAgICAgIFRoaXMgZG9jdW1lbnQgd2FzIHByb2R1Y2VkIHVuZGVyIHRoZSBjaGFpcm1hbnNoaXAg b2YgQmxhaW5lIENvb2ssIFBldGVyIFNhaW50LUFuZHJlLAogICAgICAgIEhhbm5lcyBUc2Nob2Zl bmlnLCBCYXJyeSBMZWliYSwgYW5kIERlcmVrIEF0a2lucy4gVGhlIGFyZWEgZGlyZWN0b3JzIGlu Y2x1ZGVkIExpc2EgRHVzc2VhdWx0LAogICAgICAgIFBldGVyIFNhaW50LUFuZHJlLCBhbmQgU3Rl cGhlbiBGYXJyZWxsLgogICAgICAKPC9wPgo8YSBuYW1lPSJhbmNob3I3NSI+PC9hPjxiciAvPjxo ciAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9 IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48 YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5h bWU9InJmYy5zZWN0aW9uLkMiPjwvYT48aDM+QXBwZW5kaXggQy4mbmJzcDsKRWRpdG9yJ3MgTm90 ZXM8L2gzPgoKPHA+CiAgICAgICAgV2hpbGUgbWFueSBwZW9wbGUgY29udHJpYnV0ZWQgdG8gdGhp cyBzcGVjaWZpY2F0aW9uIHRocm91Z2hvdXQgaXRzIGxvbmcgam91cm5leSwgdGhlIGVkaXRvcgog ICAgICAgIHdvdWxkIGxpa2UgdG8gYWNrbm93bGVkZ2UgYW5kIHRoYW5rIGEgZmV3IGluZGl2aWR1 YWxzIGZvciB0aGVpciBvdXRzdGFuZGluZyBhbmQgaW52YWx1YWJsZQogICAgICAgIGVmZm9ydHMg bGVhZGluZyB1cCB0byB0aGUgcHVibGljYXRpb24gb2YgdGhpcyBzcGVjaWZpY2F0aW9uLgogICAg ICAKPC9wPgo8cD4KICAgICAgICBEYXZpZCBSZWNvcmRvbiBmb3IgY29udGludW91c2x5IGJlaW5n IG9uZSBvZiBPQXV0aCdzIG1vc3QgdmFsdWFibGUgYXNzZXRzLCBicmluZ2luZwogICAgICAgIHBy YWdtYXRpc20gYW5kIHVyZ2VuY3kgdG8gdGhlIHdvcmssIGFuZCBoZWxwaW5nIHNoYXBlIGl0IGZy b20gaXRzIHZlcnkgYmVnaW5uaW5nLCBhcyB3ZWxsCiAgICAgICAgYXMgYmVpbmcgb25lIG9mIHRo ZSBiZXN0IGNvbGxhYm9yYXRvcnMgSSBoYWQgdGhlIHBsZWFzdXJlIG9mIHdvcmtpbmcgd2l0aC4K ICAgICAgCjwvcD4KPHA+CiAgICAgICAgSmFtZXMgTWFuZ2VyIGZvciBoaXMgY3JlYXRpdmUgaWRl YXMgYW5kIGFsd2F5cyBpbnNpZ2h0ZnVsIGZlZWRiYWNrLiBCcmlhbiBDYW1wYmVsbCwKICAgICAg ICBUb3JzdGVuIExvZGRlcnN0ZWR0LCBDaHVjayBNb3J0aW1vcmUsIEp1c3RpbiBSaWNoZXIsIE1h cml1cyBTY3VydGVzY3UsIGFuZCBMdWtlIFNoZXBhcmQgZm9yCiAgICAgICAgdGhlaXIgY29udGlu dWVkIHBhcnRpY2lwYXRpb24gYW5kIHZhbHVhYmxlIGZlZWRiYWNrLgogICAgICAKPC9wPgo8cD4K ICAgICAgICBTcGVjaWFsIHRoYW5rcyBnb2VzIHRvIE1pa2UgQ3VydGlzIGFuZCBZYWhvbyEgZm9y IHRoZWlyIHVuY29uZGl0aW9uYWwgc3VwcG9ydCBvZiB0aGlzIHdvcmsKICAgICAgICBmb3Igb3Zl ciB0aHJlZSB5ZWFycy4KICAgICAgCjwvcD4KPGEgbmFtZT0icmZjLmF1dGhvcnMiPjwvYT48YnIg Lz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFj aW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1 ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8 aDM+QXV0aG9ycycgQWRkcmVzc2VzPC9oMz4KPHRhYmxlIHdpZHRoPSI5OSUiIGJvcmRlcj0iMCIg Y2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIwIj4KPHRyPjx0ZCBjbGFzcz0iYXV0aG9yLXRl eHQiPiZuYnNwOzwvdGQ+Cjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPkVyYW4gSGFtbWVyIChlZGl0 b3IpPC90ZD48L3RyPgo8dHI+PHRkIGNsYXNzPSJhdXRob3IiIGFsaWduPSJyaWdodCI+RW1haWw6 Jm5ic3A7PC90ZD4KPHRkIGNsYXNzPSJhdXRob3ItdGV4dCI+PGEgaHJlZj0ibWFpbHRvOmVyYW5A aHVlbml2ZXJzZS5jb20iPmVyYW5AaHVlbml2ZXJzZS5jb208L2E+PC90ZD48L3RyPgo8dHI+PHRk IGNsYXNzPSJhdXRob3IiIGFsaWduPSJyaWdodCI+VVJJOiZuYnNwOzwvdGQ+Cjx0ZCBjbGFzcz0i YXV0aG9yLXRleHQiPjxhIGhyZWY9Imh0dHA6Ly9odWVuaXZlcnNlLmNvbSI+aHR0cDovL2h1ZW5p dmVyc2UuY29tPC9hPjwvdGQ+PC90cj4KPHRyIGNlbGxwYWRkaW5nPSIzIj48dGQ+Jm5ic3A7PC90 ZD48dGQ+Jm5ic3A7PC90ZD48L3RyPgo8dHI+PHRkIGNsYXNzPSJhdXRob3ItdGV4dCI+Jm5ic3A7 PC90ZD4KPHRkIGNsYXNzPSJhdXRob3ItdGV4dCI+RGF2aWQgUmVjb3Jkb248L3RkPjwvdHI+Cjx0 cj48dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij4mbmJzcDs8L3RkPgo8dGQgY2xhc3M9ImF1dGhvci10 ZXh0Ij5GYWNlYm9vazwvdGQ+PC90cj4KPHRyPjx0ZCBjbGFzcz0iYXV0aG9yIiBhbGlnbj0icmln aHQiPkVtYWlsOiZuYnNwOzwvdGQ+Cjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPjxhIGhyZWY9Im1h aWx0bzpkckBmYi5jb20iPmRyQGZiLmNvbTwvYT48L3RkPjwvdHI+Cjx0cj48dGQgY2xhc3M9ImF1 dGhvciIgYWxpZ249InJpZ2h0Ij5VUkk6Jm5ic3A7PC90ZD4KPHRkIGNsYXNzPSJhdXRob3ItdGV4 dCI+PGEgaHJlZj0iaHR0cDovL3d3dy5kYXZpZHJlY29yZG9uLmNvbS8iPmh0dHA6Ly93d3cuZGF2 aWRyZWNvcmRvbi5jb20vPC9hPjwvdGQ+PC90cj4KPHRyIGNlbGxwYWRkaW5nPSIzIj48dGQ+Jm5i c3A7PC90ZD48dGQ+Jm5ic3A7PC90ZD48L3RyPgo8dHI+PHRkIGNsYXNzPSJhdXRob3ItdGV4dCI+ Jm5ic3A7PC90ZD4KPHRkIGNsYXNzPSJhdXRob3ItdGV4dCI+RGljayBIYXJkdDwvdGQ+PC90cj4K PHRyPjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPiZuYnNwOzwvdGQ+Cjx0ZCBjbGFzcz0iYXV0aG9y LXRleHQiPk1pY3Jvc29mdDwvdGQ+PC90cj4KPHRyPjx0ZCBjbGFzcz0iYXV0aG9yIiBhbGlnbj0i cmlnaHQiPkVtYWlsOiZuYnNwOzwvdGQ+Cjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPjxhIGhyZWY9 Im1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbSI+ZGljay5oYXJkdEBnbWFpbC5jb208L2E+PC90 ZD48L3RyPgo8dHI+PHRkIGNsYXNzPSJhdXRob3IiIGFsaWduPSJyaWdodCI+VVJJOiZuYnNwOzwv dGQ+Cjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPjxhIGhyZWY9Imh0dHA6Ly9kaWNraGFyZHQub3Jn LyI+aHR0cDovL2RpY2toYXJkdC5vcmcvPC9hPjwvdGQ+PC90cj4KPC90YWJsZT4KPC9ib2R5Pjwv aHRtbD4K --_004_4E1F6AAD24975D4BA5B16804296739436652630DTK5EX14MBXC284r_-- From Michael.Jones@microsoft.com Sat Jun 2 01:10:36 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4164421F8A80 for ; Sat, 2 Jun 2012 01:10:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.67 X-Spam-Level: X-Spam-Status: No, score=-3.67 tagged_above=-999 required=5 tests=[AWL=-0.072, 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 YIpWvDhz+PWF for ; Sat, 2 Jun 2012 01:10:28 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe003.messaging.microsoft.com [216.32.181.183]) by ietfa.amsl.com (Postfix) with ESMTP id 43B9321F8A82 for ; Sat, 2 Jun 2012 01:10:28 -0700 (PDT) Received: from mail262-ch1-R.bigfish.com (10.43.68.241) by CH1EHSOBE012.bigfish.com (10.43.70.62) with Microsoft SMTP Server id 14.1.225.23; Sat, 2 Jun 2012 08:09:54 +0000 Received: from mail262-ch1 (localhost [127.0.0.1]) by mail262-ch1-R.bigfish.com (Postfix) with ESMTP id 699521C001AF; Sat, 2 Jun 2012 08:09:54 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -16 X-BigFish: VS-16(zzc85fhcacW4015Izz1202hzz8275bh8275dhz2fh2a8h668h839hd25hf0ah) Received-SPF: pass (mail262-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail262-ch1 (localhost.localdomain [127.0.0.1]) by mail262-ch1 (MessageSwitch) id 1338624592694240_22740; Sat, 2 Jun 2012 08:09:52 +0000 (UTC) Received: from CH1EHSMHS007.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.231]) by mail262-ch1.bigfish.com (Postfix) with ESMTP id A7BD71A80048; Sat, 2 Jun 2012 08:09:52 +0000 (UTC) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS007.bigfish.com (10.43.70.7) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 2 Jun 2012 08:09:52 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.189]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.02.0298.005; Sat, 2 Jun 2012 08:10:24 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: ABNF elements for suggested WG review Thread-Index: Ac1Alx0u1VneJZSBR8aFxCHOlLRpzQ== Date: Sat, 2 Jun 2012 08:10:23 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436652634C@TK5EX14MBXC284.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.33] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436652634CTK5EX14MBXC284r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: [OAUTH-WG] ABNF elements for suggested WG review X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 08:10:36 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436652634CTK5EX14MBXC284r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear working group, It turns out that writing an ABNF for the Core spec pointed out that the sy= ntax of a number of the OAuth protocol elements had not been previously def= ined. (Thanks, Sean, for having us do this!) I took a stab at specifying = appropriate ABNF values for each of the protocol elements, but I would requ= est that the working group actively review the choices in my proposed draft= . For instance, I chose to use the same syntax definitions for username and p= assword and client_id and client_secret as HTTP Basic used for userid and p= assword. Other choices were possible, such as perhaps limiting client_id a= nd possibly username values to use "unreserved" characters, rather than all= owing all characters other than ":" (as HTTP Basic did with userid). Please particularly review the syntax definitions for these elements, as I = had to make choices that went beyond the current specs to provide unambiguo= us syntax definitions: client_id client_secret state code access_token username password refresh_token The full proposed ABNF section follows. -- Mike Appendix A. Augmented Backus-Naur Form (ABNF) Syntax This section provides Augmented Backus-Naur Form (ABNF) syntax descriptions for the elements defined in this specification using the notation of [RFC5234]. Elements are presented in the order first defined. Some of the definitions that follow use the "unreserved" and "URI" definitions from [RFC3986], which are: unreserved =3D ALPHA / DIGIT / "-" / "." / "_" / "~" URI =3D scheme ":" hier-part [ "?" query ] [ "#" fragment ] Some of the definitions that follow use the "b64token" syntax below, which matches the "b64token" syntax defined by HTTP/1.1, Part 7 [I-D.ietf-httpbis-p7-auth]: b64token =3D 1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" ) *"=3D" A.1. "client_id" Syntax The "client_id" element is defined in Section 2.3.1: client-id =3D * (This matches the "userid" definition in the HTTP Basic Authentication Scheme [RFC2617].) A.2. "client_secret" Syntax The "client_secret" element is defined in Section 2.3.1: client-secret =3D *TEXT (This matches the "password" definition in the HTTP Basic Authentication Scheme [RFC2617].) A.3. "response_type" Syntax The "response_type" element is defined in Section 3.1.1 and Section 8.4: response-type =3D response-name *( SP response-name ) response-name =3D 1*response-char response-char =3D "_" / DIGIT / ALPHA A.4. "scope" Syntax The "scope" element is defined in Section 3.3: scope =3D scope-token *( SP scope-token ) scope-token =3D 1*( %x21 / %x23-5B / %x5D-7E ) A.5. "state" Syntax The "state" element is defined in Section 4.1.1, Section 4.1.2, Section 4.1.2.1, Section 4.2.1, Section 4.2.2, and Section 4.2.2.1: state =3D 1*unreserved A.6. "redirect_uri" Syntax The "redirect_uri" element is defined in Section 4.1.1, Section 4.1.3, and Section 4.2.1: redirect-uri =3D URI A.7. "error" Syntax The "error" element is defined in Section 4.1.2.1, Section 4.2.2.1, Section 5.2, Section 7.2, and Section 8.5: error =3D 1*error-char error-char =3D %x20-21 / %x23-5B / %x5D-7E A.8. "error_description" Syntax The "error_description" element is defined in Section 4.1.2.1, Section 4.2.2.1, Section 5.2, and Section 7.2: error-description =3D 1*error-char error-char =3D %x20-21 / %x23-5B / %x5D-7E A.9. "error_uri" Syntax The "error_uri" element is defined in Section 4.1.2.1, Section 4.2.2.1, Section 5.2, and Section 7.2: error-uri =3D URI A.10. "grant_type" Syntax The "grant_type" element is defined in Section 4.1.3, Section 4.3.2, Section 4.4.1, Section 6, and Section 4.5: grant-type =3D grant-name / URI grant-name =3D 1*name-char name-char =3D "-" / "." / "_" / DIGIT / ALPHA A.11. "code" Syntax The "code" element is defined in Section 4.1.3: code =3D 1*unreserved A.12. "access_token" Syntax The "access_token" element is defined in Section 4.2.2 and Section 5.1: access-token =3D b64token A.13. "token_type" Syntax The "token_type" element is defined in Section 4.2.2, Section 5.1, and Section 8.1: token-type =3D type-name / URI type-name =3D 1*name-char name-char =3D "-" / "." / "_" / DIGIT / ALPHA A.14. "expires_in" Syntax The "expires_in" element is defined in Section 4.2.2 and Section 5.1: expires-in =3D 1*DIGIT A.15. "username" Syntax The "username" element is defined in Section 4.3.2: username =3D * (This matches the "userid" definition in the HTTP Basic Authentication Scheme [RFC2617].) A.16. "password" Syntax The "password" element is defined in Section 4.3.2: password =3D *TEXT (This matches the "password" definition in the HTTP Basic Authentication Scheme [RFC2617].) A.17. "refresh_token" Syntax The "refresh_token" element is defined in Section 5.1 and Section 6: refresh-token =3D b64token A.18. Endpoint Parameter Syntax The syntax for new endpoint parameters is defined in Section 8.2: param-name =3D 1*name-char name-char =3D "-" / "." / "_" / DIGIT / ALPHA --_000_4E1F6AAD24975D4BA5B16804296739436652634CTK5EX14MBXC284r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear working group,

 

It turns out that writing an ABNF for the Core spec = pointed out that the syntax of a number of the OAuth protocol elements had = not been previously defined.  (Thanks, Sean, for having us do this!)&n= bsp; I took a stab at specifying appropriate ABNF values for each of the protocol elements, but I would request that th= e working group actively review the choices in my proposed draft.

 

For instance, I chose to use the same syntax definit= ions for username and password and client_id and client_secret as HTTP Basi= c used for userid and password.  Other choices were possible, such as = perhaps limiting client_id and possibly username values to use “unreserved” characters, rather than al= lowing all characters other than “:” (as HTTP Basic did with us= erid).

 

Please particularly review the syntax definitions fo= r these elements, as I had to make choices that went beyond the current spe= cs to provide unambiguous syntax definitions:

        &nbs= p;      client_id

        &nbs= p;      client_secret

        &nbs= p;      state

        &nbs= p;      code

        &nbs= p;      access_token

        &nbs= p;      username

        &nbs= p;      password

        &nbs= p;      refresh_token

 

The full proposed ABNF section follows.

 

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

 

Appendix A.  Augmented Backus-Naur Form (ABNF) Syntax=

 

   This section provides Augmented Backus-Naur F= orm (ABNF) syntax

   descriptions for the elements defined in this= specification using the

   notation of [RFC5234].  Elements are pre= sented in the order first

   defined.

 

   Some of the definitions that follow use the &= quot;unreserved" and "URI"

   definitions from [RFC3986], which are:

 

   unreserved =3D ALPHA / DIGIT / "-" = / "." / "_" / "~"

   URI       = =3D scheme ":" hier-part [ "?" query ] [ "#"= fragment ]

 

   Some of the definitions that follow use the &= quot;b64token" syntax below,

   which matches the "b64token" syntax= defined by HTTP/1.1, Part 7

   [I-D.ietf-httpbis-p7-auth]:=

 

   b64token   =3D 1*( ALPHA / DIGIT /<= o:p>

         &nbs= p;          "-" / &q= uot;." / "_" / "~" / "+" / "/&q= uot; ) *"=3D"

 

A.1.  "client_id" Syntax<= /p>

 

   The "client_id" element is defined = in Section 2.3.1:

 

   client-id     =3D *<TE= XT excluding ":">

 

   (This matches the "userid" definiti= on in the HTTP Basic

   Authentication Scheme [RFC2617].)<= /span>

 

A.2.  "client_secret" Syntax

 

   The "client_secret" element is defi= ned in Section 2.3.1:

 

   client-secret =3D *TEXT

 

   (This matches the "password" defini= tion in the HTTP Basic

   Authentication Scheme [RFC2617].)<= /span>

 

A.3.  "response_type" Syntax

 

   The "response_type" element is defi= ned in Section 3.1.1 and

   Section 8.4:

 

   response-type =3D response-name *( SP respons= e-name )

   response-name =3D 1*response-char<= /span>

   response-char =3D "_" / DIGIT / ALP= HA

 

A.4.  "scope" Syntax

 

   The "scope" element is defined in S= ection 3.3:

 

   scope       =3D= scope-token *( SP scope-token )

   scope-token =3D 1*( %x21 / %x23-5B / %x5D-7E = )

 

A.5.  "state" Syntax

 

   The "state" element is defined in S= ection 4.1.1, Section 4.1.2,

   Section 4.1.2.1, Section 4.2.1, Section 4.2.2= , and Section 4.2.2.1:

 

   state      =3D 1*unr= eserved

 

A.6.  "redirect_uri" Syntax

 

   The "redirect_uri" element is defin= ed in Section 4.1.1,

   Section 4.1.3, and Section 4.2.1:<= /span>

 

   redirect-uri      = =3D URI

 

A.7.  "error" Syntax

 

   The "error" element is defined in S= ection 4.1.2.1, Section 4.2.2.1,

   Section 5.2, Section 7.2, and Section 8.5:

 

   error      &nbs= p;      =3D 1*error-char

   error-char      = ;  =3D %x20-21 / %x23-5B / %x5D-7E

 

A.8.  "error_description" Syntax=

 

   The "error_description" element is = defined in Section 4.1.2.1,

   Section 4.2.2.1, Section 5.2, and Section 7.2= :

 

   error-description =3D 1*error-char=

   error-char      = ;  =3D %x20-21 / %x23-5B / %x5D-7E

 

A.9.  "error_uri" Syntax<= /p>

 

   The "error_uri" element is defined = in Section 4.1.2.1,

   Section 4.2.2.1, Section 5.2, and Section 7.2= :

 

   error-uri      =    =3D URI

 

A.10.  "grant_type" Syntax

 

   The "grant_type" element is defined= in Section 4.1.3, Section 4.3.2,

   Section 4.4.1, Section 6, and Section 4.5:

 

   grant-type =3D grant-name / URI

   grant-name =3D 1*name-char<= /p>

   name-char  =3D "-" / ".&q= uot; / "_" / DIGIT / ALPHA

 

A.11.  "code" Syntax

 

   The "code" element is defined in Se= ction 4.1.3:

 

   code       =3D = 1*unreserved

 

A.12.  "access_token" Syntax

 

   The "access_token" element is defin= ed in Section 4.2.2 and

   Section 5.1:

 

   access-token =3D b64token

 

A.13.  "token_type" Syntax

 

   The "token_type" element is defined= in Section 4.2.2, Section 5.1,

   and Section 8.1:

 

   token-type =3D type-name / URI

   type-name  =3D 1*name-char

   name-char  =3D "-" / ".&q= uot; / "_" / DIGIT / ALPHA

 

A.14.  "expires_in" Syntax

 

   The "expires_in" element is defined= in Section 4.2.2 and Section 5.1:

 

   expires-in =3D 1*DIGIT

 

A.15.  "username" Syntax<= /p>

 

   The "username" element is defined i= n Section 4.3.2:

 

   username =3D *<TEXT excluding ":"= ;>

 

   (This matches the "userid" definiti= on in the HTTP Basic

   Authentication Scheme [RFC2617].)<= /span>

 

A.16.  "password" Syntax<= /p>

 

   The "password" element is defined i= n Section 4.3.2:

 

   password =3D *TEXT

 

   (This matches the "password" defini= tion in the HTTP Basic

   Authentication Scheme [RFC2617].)<= /span>

 

A.17.  "refresh_token" Syntax

 

   The "refresh_token" element is defi= ned in Section 5.1 and Section 6:

 

   refresh-token =3D b64token<= /p>

 

A.18.  Endpoint Parameter Syntax

 

   The syntax for new endpoint parameters is def= ined in Section 8.2:

 

   param-name =3D 1*name-char<= /p>

   name-char  =3D "-" / ".&q= uot; / "_" / DIGIT / ALPHA

 

 

--_000_4E1F6AAD24975D4BA5B16804296739436652634CTK5EX14MBXC284r_-- From ve7jtb@ve7jtb.com Sat Jun 2 05:22:03 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C466621F8860 for ; Sat, 2 Jun 2012 05:22:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.243 X-Spam-Level: X-Spam-Status: No, score=-0.243 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 yWXWiHsstVEq for ; Sat, 2 Jun 2012 05:22:03 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3C93621F885B for ; Sat, 2 Jun 2012 05:22:03 -0700 (PDT) Received: by ggnc4 with SMTP id c4so2604090ggn.31 for ; Sat, 02 Jun 2012 05:22:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to :x-gm-message-state; bh=TxrPwgolugguDbdRv2RaMEDKnjT1ft4K7a8QC4e6UYw=; b=pnA73fk600ZMlH0udLIN4/24holVsjZr4MzvcyxF3cT/0lILjk7ThsAupY02Ll9JT/ bWhHvNCa8WKgeqwhXqFJel7fTybioSG/RCUvL7NIsxP4b1+s5BGZAz9RWZ4l3lrQHvqs eCJGotTws62EsB07FAM3usqOETeoUov/st9d5i8GlV4glepLnWvgEEowo/DviDg7bR6E lPFzioL+N1CdZRfZD4My12TCIAQVig4pOCmJ5W9V0mlOpgVAlr1wsQfRptWuA+U/TgcI dbBfIutLEyc4DbwaI3i9MjqeKnr/tqarsCu3KdOcPkYhs3+xKELHFEGFlEqEXO40bs5V pIig== Received: by 10.236.173.232 with SMTP id v68mr1308899yhl.97.1338639722798; Sat, 02 Jun 2012 05:22:02 -0700 (PDT) Received: from [10.113.144.81] ([201.220.233.203]) by mx.google.com with ESMTPS id z42sm16715649yhd.1.2012.06.02.05.21.59 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 02 Jun 2012 05:22:00 -0700 (PDT) References: <09CE58C6-9409-4E28-B4CA-DC76C37B898E@gmx.net> In-Reply-To: <09CE58C6-9409-4E28-B4CA-DC76C37B898E@gmx.net> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2C7672DF-0F2F-4E87-B8C3-D3352C213E66; protocol="application/pkcs7-signature" Message-Id: X-Mailer: iPhone Mail (9B206) From: John Bradley Date: Sat, 2 Jun 2012 07:21:57 -0500 To: Hannes Tschofenig X-Gm-Message-State: ALoCoQnu/1ESguLSsJ9628nfRiVc6ixsrqcovjN4nLLyKbijmWhgz3O9n7EJctdLSNk9d/eOupag Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Meeting slot for the Vancouver IETF meeting requested X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jun 2012 12:22:03 -0000 --Apple-Mail-2C7672DF-0F2F-4E87-B8C3-D3352C213E66 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I am attending.=20 John B.=20 Sent from my iPhone On 2012-06-02, at 2:46 AM, Hannes Tschofenig wro= te: > Hi all,=20 >=20 > I have requested a 2,5 hour slot for the upcoming meeting.=20 >=20 > While the next meeting is still a bit away it is nevertheless useful to he= ar=20 > * whether you plan to attend the next meeting, and=20 > * whether you want to present something.=20 >=20 > I could imagine that these documents will be discussed: > * draft-ietf-oauth-dyn-reg > * draft-ietf-oauth-json-web-token > * draft-ietf-oauth-jwt-bearer > * draft-ietf-oauth-revocation > * draft-ietf-oauth-use-cases >=20 > To the draft authors of these docuemnts: Please think about the open issue= s and drop a mail to the list so that we make some progress already before t= he face-to-face meeting.=20 >=20 > I am assume that the following documents do not require any discussion tim= e at the upcoming IETF meeting anymore: > * draft-ietf-oauth-assertions > * draft-ietf-oauth-saml2-bearer > * draft-ietf-oauth-urn-sub-ns > * draft-ietf-oauth-v2 > * draft-ietf-oauth-v2-bearer >=20 > Ciao > Hannes >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-2C7672DF-0F2F-4E87-B8C3-D3352C213E66 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIVvjCCBjQw 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/d1WwqI26kFo5k7686AmpUMIIHyTCCBbGgAwIBAgIBATANBgkqhkiG9w0B AQUFADB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlm aWNhdGlvbiBBdXRob3JpdHkwHhcNMDYwOTE3MTk0NjM2WhcNMzYwOTE3MTk0NjM2WjB9MQswCQYD VQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwg Q2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRo b3JpdHkwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDBiNsJvGxGfHiflXu1M5DycmLW wTYgIiRezul38kMKogZkpMyONvg45iPwbm2xPN1yo4UcodM9tDMr0y+v/uqwQVlntsQGfQqedIXW eUyAN3rfOQVSWff0G0ZDpNKFhdLDcfN1YjS6LIp/Ho/u7TTQEceWzVI9ujPW3U3eCztKS5/CJi/6 tRYccjV3yjxd5srhJosaNnZcAdt0FCX+7bWgiA/deMotHweXMAEtcnn6RtYTKqi5pquDSR3l8u/d 5AGOGAqPY1MWhWKpDhk6zLVmpsJrdAfkK+F2PrRt2PZE4XNiHzvEvqBTViVsUQn3qqvKv3b9bZvz ndu/PWa8DFaqr5hIlTpL36dYUNk4dalb6kMMAv+Z6+hsTXBbKWWc3apdzK8BMewM69KN6Oqce+Zu 9ydmDBpI125C4z/eIT574Q1w+2OqqGwaVLRcJXrJosmLFqa7LH4XXgVNWG4SHQHuEhANxjJ/GP/8 9PrNbpHoNkm+Gkhpi8KWTRoSsmkXwQqQ1vp5Iki/untp+HDH+no32NgN0nZPV/+Qt+OR0t3vwmC3 Zzrd/qqc8NSLf3Iizsafl7b4r4qgEKjZ+xjGtrVcUjyJthkqcwEKDwOzEmDyei+B26Nu/yYwl/WL 3YlXtq09s68rxbd2AvCl1iuahhQqcvbjM4xdCUsT37uMdBNSSwIDAQABo4ICUjCCAk4wDAYDVR0T BAUwAwEB/zALBgNVHQ8EBAMCAa4wHQYDVR0OBBYEFE4L7xqkQFulF2mHMMo0aEPQQa7yMGQGA1Ud HwRdMFswLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwuY3JsMCugKaAn hiVodHRwOi8vY3JsLnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwuY3JsMIIBXQYDVR0gBIIBVDCCAVAw ggFMBgsrBgEEAYG1NwEBATCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9y Zy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50ZXJt ZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQgQ29tbWVyY2lhbCAoU3RhcnRDb20p IEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBM aW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGlj eSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZI AYb4QgEBBAQDAgAHMDgGCWCGSAGG+EIBDQQrFilTdGFydENvbSBGcmVlIFNTTCBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTANBgkqhkiG9w0BAQUFAAOCAgEAFmyZ9GYMNPXQhV59CuzaEE44HF7fpiUF S5Eyweg78T3dRAlbB0mKKctmArexmvclmAk8jhvh3TaHK0u7aNM5Zj2gJsfyOZEdUauCe37Vzlrk 4gNXcGmXCPleWKYK34wGmkUWFjgKXlf2Ysd6AgXmvB618p70qSmD+LIU424oh0TDkBreOKk8rENN ZEXO3SipXPJzewT4F+irsfMuXGRuczE6Eri8sxHkfY+BUZo7jYn0TZNmezwD7dOaHZrzZVD1oNB1 ny+v8OqCQ5j4aZyJecRDjkZy42Q2Eq/3JR44iZB3fsNrarnDy0RLrHiQi+fHLB5LEUTINFInzQpd n4XBidUaePKVEFMy3YCEZnXZtWgo+2EuvoSoOMCZEoalHmdkrQYuL6lwhceWD3yJZfWOQ1QOq92l gDmUYMA0yZZwLKMS9R9Ie70cfmu3nZD0Ijuu+PwqyvqCUqDvr0tVk+vBtfAii6w0TiYiBKGHLHVK t+V9E9e4DGTANtLJL4YSjCMJwRuCO3NJo2pXh5Tl1njFmUNj403gdy3hZZlyaQQaRwnmDwFWJPsf vw55qVguucQJAX6Vum0ABj6y6koQOdjQK/W/7HW/lwLFCRsI3FU34oH7N4RDYiDK51ZLZer+bMEk kyShNOsF/5oirpt9P/FlUQqmMGqz9IgcgA38corog14xggNsMIIDaAIBATCBkzCBjDELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENl cnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRl cm1lZGlhdGUgQ2xpZW50IENBAgIeXDAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjA2MDIxMjIyMDBaMCMGCSqGSIb3DQEJBDEWBBSuee2Z D1xVDwCjwJql6u0/WlmNhzCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQG A1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBD bGllbnQgQ0ECAh5cMIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDANBgkqhkiG9w0BAQEFAASCAQAAy5Z5QOrnVVE4YFg+svvHR4J+ihEKz73kxWHg qJ+kcOPirSdl+9+Lktzwwv6NbrFY4O/usz5I1bEyZQiAAeyRHzcbwEl7gED2JYVLSlKOLqJ+GAtl ZQgV7dQ7mY7sS9SvCCE/09RI1KzjuRjsfdHacN9t/uPX7VWcBgIOvh2wdZgCZ00stg6SQMIUifQI 8P1oNy9wfAROrms8bCYaV6FuMC5b1OK4Wz6y3ETei/k8bjFKoYN32uAgvZplL5jsFa2cQx3FjuHm QlWDB5q9bq5fSByAK5Brq0pE4i64xGQdwbEhmoo3uoREjlNK3cc+9q7r4g5LRJF6kpTFti/GuzUs AAAAAAAA --Apple-Mail-2C7672DF-0F2F-4E87-B8C3-D3352C213E66-- From wmills@yahoo-inc.com Sat Jun 2 08:45:11 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 775B021F84CD for ; Sat, 2 Jun 2012 08:45:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.598 X-Spam-Level: X-Spam-Status: No, score=-17.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R-c5qSVMQLi1 for ; Sat, 2 Jun 2012 08:45:10 -0700 (PDT) Received: from nm3-vm1.bullet.mail.ac4.yahoo.com (nm3-vm1.bullet.mail.ac4.yahoo.com [98.139.53.205]) by ietfa.amsl.com (Postfix) with SMTP id 8C21821F84B6 for ; Sat, 2 Jun 2012 08:45:10 -0700 (PDT) Received: from [98.139.52.188] by nm3.bullet.mail.ac4.yahoo.com with NNFMP; 02 Jun 2012 15:45:07 -0000 Received: from [98.139.52.152] by tm1.bullet.mail.ac4.yahoo.com with NNFMP; 02 Jun 2012 15:45:07 -0000 Received: from [127.0.0.1] by omp1035.mail.ac4.yahoo.com with NNFMP; 02 Jun 2012 15:45:07 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 602434.96389.bm@omp1035.mail.ac4.yahoo.com Received: (qmail 87691 invoked by uid 60001); 2 Jun 2012 15:45:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1338651906; bh=2MFIEOLnMQyokkT9DZS5eziP8A/7pijiceie50Z/IOw=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=FtzU47EViGK3wL4vZNCIh+eAxGS3rZ0JJ8UTGEsTOdu2MEkr8HRy3O516MF0Dn6mkks4HsMlUHBGciqZSi7SFPz/ZuTGPmQoecQHXfp1jGHndgGOGk0Wy4KaMDzLNozcqjU/W9gUlMSc+wZTx7yVqjzWEM/y9oj4k+fEH3JJMaE= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=G/Rh07O/lRD2ACUCqI7adAYAyxEMJpNQ31vdJoB0pHh5I6y3fvJTwvon9CC/PrkEU3sGx8Q5Q+OBvRms/tX6ROKUdfr5TR9yzLeNiQCgNf9UPq7i0h6bzvXui+OTwMIAUEjOG/vf2JG04R7dMFID5w+xwYjUnkvbbk+Y1E5lHhc=; X-YMail-OSG: bQZhJoMVM1nfBLtjxYE2B90ZScYb7Z2T4iVmuVCvJGz.pPh PyK.KLtq7lksHmepLGfgmY8KftpES.YXJPY6APox6UoPrzG8q.2tdodrD.uX NljdatpfjJaRMzEoH8PJRjkQAQn_oH_T0b1i2fjUO85E1S2wVIgeG2B8IDhw sE8yMSAVKyKcI.9acb9kZ5WhXo4cMD3eyS_gogi08eolPW08i2MmCouGFqx. m1FjrfKN1ocDyrP3JJ3UBgMo8sklRrG9AzifE8BsQ1aj07L6jao5.rQpqGke HWY5xwRavmI15Yp.6ecRghKL1kZ4YPqmp855jcRXtwzBbMMYSj8GCMjAheU2 6GgXeTN4DDCANzTtg0z03i.rNwmRPi4RejknRzfgZqcVVaX8NOlnfHHvyqoL j4tI2i_A0urNm_UwNW.gVHnSOCO4- Received: from [99.31.212.42] by web31807.mail.mud.yahoo.com via HTTP; Sat, 02 Jun 2012 08:45:06 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.118.349524 References: <09CE58C6-9409-4E28-B4CA-DC76C37B898E@gmx.net> Message-ID: <1338651906.78886.YahooMailNeo@web31807.mail.mud.yahoo.com> Date: Sat, 2 Jun 2012 08:45:06 -0700 (PDT) From: William Mills To: Hannes Tschofenig , "oauth@ietf.org WG" In-Reply-To: <09CE58C6-9409-4E28-B4CA-DC76C37B898E@gmx.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-125733401-1259767998-1338651906=:78886" Subject: Re: [OAUTH-WG] Meeting slot for the Vancouver IETF meeting requested X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jun 2012 15:45:11 -0000 ---125733401-1259767998-1338651906=:78886 Content-Type: text/plain; charset=us-ascii I will not be attending in person, but will probably attend by conference call. -bill >________________________________ > From: Hannes Tschofenig >To: "oauth@ietf.org WG" >Sent: Saturday, June 2, 2012 12:46 AM >Subject: [OAUTH-WG] Meeting slot for the Vancouver IETF meeting requested > >Hi all, > >I have requested a 2,5 hour slot for the upcoming meeting. > >While the next meeting is still a bit away it is nevertheless useful to hear >* whether you plan to attend the next meeting, and >* whether you want to present something. > >I could imagine that these documents will be discussed: >* draft-ietf-oauth-dyn-reg >* draft-ietf-oauth-json-web-token >* draft-ietf-oauth-jwt-bearer >* draft-ietf-oauth-revocation >* draft-ietf-oauth-use-cases > >To the draft authors of these docuemnts: Please think about the open issues and drop a mail to the list so that we make some progress already before the face-to-face meeting. > >I am assume that the following documents do not require any discussion time at the upcoming IETF meeting anymore: >* draft-ietf-oauth-assertions >* draft-ietf-oauth-saml2-bearer >* draft-ietf-oauth-urn-sub-ns >* draft-ietf-oauth-v2 >* draft-ietf-oauth-v2-bearer > >Ciao >Hannes > >_______________________________________________ >OAuth mailing list >OAuth@ietf.org >https://www.ietf.org/mailman/listinfo/oauth > > > ---125733401-1259767998-1338651906=:78886 Content-Type: text/html; charset=us-ascii
I will not be attending in person, but will probably attend by conference call.

-bill

From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
To: "oauth@ietf.org WG" <oauth@ietf.org>
Sent: Saturday, June 2, 2012 12:46 AM
Subject: [OAUTH-WG] Meeting slot for the Vancouver IETF meeting requested

Hi all,

I have requested a 2,5 hour slot for the upcoming meeting.

While the next meeting is still a bit away it is nevertheless useful to hear
* whether you plan to attend the next meeting, and
* whether you want to present something.

I could imagine that these documents will be discussed:
* draft-ietf-oauth-dyn-reg
* draft-ietf-oauth-json-web-token
* draft-ietf-oauth-jwt-bearer
* draft-ietf-oauth-revocation
* draft-ietf-oauth-use-cases

To the draft authors of these docuemnts: Please think about the open issues and drop a mail to the list so that we make some progress already before the face-to-face meeting.

I am assume that the following documents do not require any discussion time at the upcoming IETF meeting anymore:
* draft-ietf-oauth-assertions
* draft-ietf-oauth-saml2-bearer
* draft-ietf-oauth-urn-sub-ns
* draft-ietf-oauth-v2
* draft-ietf-oauth-v2-bearer

Ciao
Hannes

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


---125733401-1259767998-1338651906=:78886-- From wmills@yahoo-inc.com Sat Jun 2 08:53:02 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8096D21F856C for ; Sat, 2 Jun 2012 08:53:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gDrhe6PCSZ4M for ; Sat, 2 Jun 2012 08:53:01 -0700 (PDT) Received: from nm8-vm0.bullet.mail.ac4.yahoo.com (nm8-vm0.bullet.mail.ac4.yahoo.com [98.139.52.230]) by ietfa.amsl.com (Postfix) with SMTP id 59AF421F8564 for ; Sat, 2 Jun 2012 08:53:01 -0700 (PDT) Received: from [98.139.52.195] by nm8.bullet.mail.ac4.yahoo.com with NNFMP; 02 Jun 2012 15:52:57 -0000 Received: from [98.139.52.147] by tm8.bullet.mail.ac4.yahoo.com with NNFMP; 02 Jun 2012 15:52:57 -0000 Received: from [127.0.0.1] by omp1030.mail.ac4.yahoo.com with NNFMP; 02 Jun 2012 15:52:57 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 461337.41051.bm@omp1030.mail.ac4.yahoo.com Received: (qmail 83586 invoked by uid 60001); 2 Jun 2012 15:52:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1338652376; bh=cHM8Hy+NWNZUnhE6qSPbNlrZogDey5GLZ9kWO1uprnQ=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Aim+qH7jCLIMU06sCBpzSuadtcYFhtjVu2Kn4yPr/my21vBbfVC1McouGLZuyY4JJc3uxBFlNSDYBRUuzBAKNG2ict3lbc34N5cGGO7ggKNzG7lDbM+JgwWePPv/3U8k+1r8cbTB36qsoL8JEoezZ5/dk+h0+LK+CI4ZMeJNbhI= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=q8NoTAwhhfes1WXdDUt8PUl5wMUCXplP8JzFFhW5YARZvGFixuPLwH7DK/PDZCK+8KtbOaTEo1stxXZWrsMZzhf/lZPICQd9jEGuoSv7MHe3pOgl8SFid7WnRNn8fcbDwfdSnNGChezI/HLNq9W7xt4uBEP19xyyWEdTy84nFtQ=; X-YMail-OSG: X67TGksVM1nyuAGrDIg06iHpVFHXa3HhLIAPOIxe5wabmMF tv5iTe.iTSS0OXi19hbyM1J4obrq4NS5MaJ1kKfQ6W157.dxOMOgLklG6tPB M.K.Kqi_Ook0nVKgp8CY.2G8Vfv2nFegTwdmnvJOLfHUhrR1WKofNo_NfeTv pTxhpqemzTEDP8Xh_DGTOlWjG6mEVBEqUyXBzFLiY1k31Wchz_USIRbzxYKy 5KRmO3SFqVKp1Hix6eLdGVn5MMR0AXUbjhK7uCbiDpaN8c60NFBQsvNN2Lgz tk6f.IWlFNksG7wq60tBQ4PCGNccttvrNSuKfrzW9TeVhZ8yowEwwcD8MHiJ XiTwf42fNItXF0FwCzFMv1FAOAtMPTznTr8JWOvUEfJ3bR_fnvAaXbKFdEdB WRK314REqfQn0sXM2oMW_5qEcpV_wrBPZSrZmo8EBO6.Q7cipzKGFz1jpucS EY7WuiVvDHBgSm_LnQiJUnXjfgg-- Received: from [99.31.212.42] by web31808.mail.mud.yahoo.com via HTTP; Sat, 02 Jun 2012 08:52:56 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.118.349524 References: <4E1F6AAD24975D4BA5B16804296739436652634C@TK5EX14MBXC284.redmond.corp.microsoft.com> Message-ID: <1338652376.77581.YahooMailNeo@web31808.mail.mud.yahoo.com> Date: Sat, 2 Jun 2012 08:52:56 -0700 (PDT) From: William Mills To: Mike Jones , "oauth@ietf.org" In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436652634C@TK5EX14MBXC284.redmond.corp.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [OAUTH-WG] ABNF elements for suggested WG review X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jun 2012 15:53:02 -0000 =0A=0AWe've definitely needed full ABNF, this is good.=C2=A0 I don't like t= he habit of multiple definitions for the same character sets though.=C2=A0 = Things like "%x21 / %x23-5B / %x5D-7E" should be named once and re-used.=0A= =0A=0A=0A=0A>________________________________=0A> From: Mike Jones =0A>To: "oauth@ietf.org" =0A>Sent: Sa= turday, June 2, 2012 1:10 AM=0A>Subject: [OAUTH-WG] ABNF elements for sugge= sted WG review=0A> =0A>=0A> =0A>Dear working group,=0A>=C2=A0=0A>It turns o= ut that writing an ABNF for the Core spec pointed out that the syntax of a = number of the OAuth protocol elements had not been previously defined.=C2= =A0 (Thanks, Sean, for having us do this!)=C2=A0 I took a stab at specifyin= g appropriate ABNF values for each of the protocol elements, but I would re= quest that the working group actively review the choices in my proposed dra= ft.=0A>=C2=A0=0A>For instance, I chose to use the same syntax definitions f= or username and password and client_id and client_secret as HTTP Basic used= for userid and password.=C2=A0 Other choices were possible, such as perhap= s limiting client_id and possibly username values to use =E2=80=9Cunreserve= d=E2=80=9D characters, rather than allowing all characters other than =E2= =80=9C:=E2=80=9D (as HTTP Basic did with userid).=0A>=C2=A0=0A>Please parti= cularly review the syntax definitions for these elements, as I had to make = choices that went beyond the current specs to provide unambiguous syntax de= finitions:=0A>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 client_id=0A>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 client_secret=0A>=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= state=0A>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 code=0A>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 access_token=0A>=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 username= =0A>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 password=0A>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 refresh_token=0A>=C2=A0=0A>The full= proposed ABNF section follows.=0A>=C2=A0=0A>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 -- Mike=0A>=C2=A0=0A>Appendix A.=C2=A0 Augmented B= ackus-Naur Form (ABNF) Syntax=0A>=C2=A0=0A>=C2=A0=C2=A0 This section provid= es Augmented Backus-Naur Form (ABNF) syntax=0A>=C2=A0=C2=A0 descriptions fo= r the elements defined in this specification using the=0A>=C2=A0=C2=A0 nota= tion of [RFC5234].=C2=A0 Elements are presented in the order first=0A>=C2= =A0=C2=A0 defined.=0A>=C2=A0=0A>=C2=A0=C2=A0 Some of the definitions that f= ollow use the "unreserved" and "URI"=0A>=C2=A0=C2=A0 definitions from [RFC3= 986], which are:=0A>=C2=A0=0A>=C2=A0=C2=A0 unreserved =3D ALPHA / DIGIT / "= -" / "." / "_" / "~"=0A>=C2=A0=C2=A0 URI=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 =3D scheme ":" hier-part [ "?" query ] [ "#" fragment ]=0A>=C2=A0= =0A>=C2=A0=C2=A0 Some of the definitions that follow use the "b64token" syn= tax below,=0A>=C2=A0=C2=A0 which matches the "b64token" syntax defined by H= TTP/1.1, Part 7=0A>=C2=A0=C2=A0 [I-D.ietf-httpbis-p7-auth]:=0A>=C2=A0=0A>= =C2=A0=C2=A0 b64token=C2=A0=C2=A0 =3D 1*( ALPHA / DIGIT /=0A>=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 "-" / "." / "_" / "~" / "+" / "/" ) *"=3D"=0A>= =C2=A0=0A>A.1.=C2=A0 "client_id" Syntax=0A>=C2=A0=0A>=C2=A0=C2=A0 The "clie= nt_id" element is defined in Section 2.3.1:=0A>=C2=A0=0A>=C2=A0=C2=A0 clien= t-id=C2=A0=C2=A0=C2=A0=C2=A0 =3D *=0A>=C2=A0=0A>=C2=A0= =C2=A0 (This matches the "userid" definition in the HTTP Basic=0A>=C2=A0=C2= =A0 Authentication Scheme [RFC2617].)=0A>=C2=A0=0A>A.2.=C2=A0 "client_secre= t" Syntax=0A>=C2=A0=0A>=C2=A0=C2=A0 The "client_secret" element is defined = in Section 2.3.1:=0A>=C2=A0=0A>=C2=A0=C2=A0 client-secret =3D *TEXT=0A>=C2= =A0=0A>=C2=A0=C2=A0 (This matches the "password" definition in the HTTP Bas= ic=0A>=C2=A0=C2=A0 Authentication Scheme [RFC2617].)=0A>=C2=A0=0A>A.3.=C2= =A0 "response_type" Syntax=0A>=C2=A0=0A>=C2=A0=C2=A0 The "response_type" el= ement is defined in Section 3.1.1 and=0A>=C2=A0=C2=A0 Section 8.4:=0A>=C2= =A0=0A>=C2=A0=C2=A0 response-type =3D response-name *( SP response-name )= =0A>=C2=A0=C2=A0 response-name =3D 1*response-char=0A>=C2=A0=C2=A0 response= -char =3D "_" / DIGIT / ALPHA=0A>=C2=A0=0A>A.4.=C2=A0 "scope" Syntax=0A>=C2= =A0=0A>=C2=A0=C2=A0 The "scope" element is defined in Section 3.3:=0A>=C2= =A0=0A>=C2=A0=C2=A0 scope=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D scope-tok= en *( SP scope-token )=0A>=C2=A0=C2=A0 scope-token =3D 1*( %x21 / %x23-5B /= %x5D-7E )=0A>=C2=A0=0A>A.5.=C2=A0 "state" Syntax=0A>=C2=A0=0A>=C2=A0=C2=A0= The "state" element is defined in Section 4.1.1, Section 4.1.2,=0A>=C2=A0= =C2=A0 Section 4.1.2.1, Section 4.2.1, Section 4.2.2, and Section 4.2.2.1:= =0A>=C2=A0=0A>=C2=A0=C2=A0 state=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D 1*unrese= rved=0A>=C2=A0=0A>A.6.=C2=A0 "redirect_uri" Syntax=0A>=C2=A0=0A>=C2=A0=C2= =A0 The "redirect_uri" element is defined in Section 4.1.1,=0A>=C2=A0=C2=A0= Section 4.1.3, and Section 4.2.1:=0A>=C2=A0=0A>=C2=A0=C2=A0 redirect-uri= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D URI=0A>=C2=A0=0A>A.7.=C2=A0 "error" Synt= ax=0A>=C2=A0=0A>=C2=A0=C2=A0 The "error" element is defined in Section 4.1.= 2.1, Section 4.2.2.1,=0A>=C2=A0=C2=A0 Section 5.2, Section 7.2, and Section= 8.5:=0A>=C2=A0=0A>=C2=A0=C2=A0 error=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D 1*error-char=0A>=C2=A0=C2=A0 error= -char=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D %x20-21 / %x23-5B / %x5= D-7E=0A>=C2=A0=0A>A.8.=C2=A0 "error_description" Syntax=0A>=C2=A0=0A>=C2=A0= =C2=A0 The "error_description" element is defined in Section 4.1.2.1,=0A>= =C2=A0=C2=A0 Section 4.2.2.1, Section 5.2, and Section 7.2:=0A>=C2=A0=0A>= =C2=A0=C2=A0 error-description =3D 1*error-char=0A>=C2=A0=C2=A0 error-char= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D %x20-21 / %x23-5B / %x5D-7E= =0A>=C2=A0=0A>A.9.=C2=A0 "error_uri" Syntax=0A>=C2=A0=0A>=C2=A0=C2=A0 The "= error_uri" element is defined in Section 4.1.2.1,=0A>=C2=A0=C2=A0 Section 4= .2.2.1, Section 5.2, and Section 7.2:=0A>=C2=A0=0A>=C2=A0=C2=A0 error-uri= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D URI=0A>=C2=A0=0A>A.10.= =C2=A0 "grant_type" Syntax=0A>=C2=A0=0A>=C2=A0=C2=A0 The "grant_type" eleme= nt is defined in Section 4.1.3, Section 4.3.2,=0A>=C2=A0=C2=A0 Section 4.4.= 1, Section 6, and Section 4.5:=0A>=C2=A0=0A>=C2=A0=C2=A0 grant-type =3D gra= nt-name / URI=0A>=C2=A0=C2=A0 grant-name =3D 1*name-char=0A>=C2=A0=C2=A0 na= me-char=C2=A0 =3D "-" / "." / "_" / DIGIT / ALPHA=0A>=C2=A0=0A>A.11.=C2=A0 = "code" Syntax=0A>=C2=A0=0A>=C2=A0=C2=A0 The "code" element is defined in Se= ction 4.1.3:=0A>=C2=A0=0A>=C2=A0=C2=A0 code=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 =3D 1*unreserved=0A>=C2=A0=0A>A.12.=C2=A0 "access_token" Syntax=0A>= =C2=A0=0A>=C2=A0=C2=A0 The "access_token" element is defined in Section 4.2= .2 and=0A>=C2=A0=C2=A0 Section 5.1:=0A>=C2=A0=0A>=C2=A0=C2=A0 access-token = =3D b64token=0A>=C2=A0=0A>A.13.=C2=A0 "token_type" Syntax=0A>=C2=A0=0A>=C2= =A0=C2=A0 The "token_type" element is defined in Section 4.2.2, Section 5.1= ,=0A>=C2=A0=C2=A0 and Section 8.1:=0A>=C2=A0=0A>=C2=A0=C2=A0 token-type =3D= type-name / URI=0A>=C2=A0=C2=A0 type-name=C2=A0 =3D 1*name-char=0A>=C2=A0= =C2=A0 name-char=C2=A0 =3D "-" / "." / "_" / DIGIT / ALPHA=0A>=C2=A0=0A>A.1= 4.=C2=A0 "expires_in" Syntax=0A>=C2=A0=0A>=C2=A0=C2=A0 The "expires_in" ele= ment is defined in Section 4.2.2 and Section 5.1:=0A>=C2=A0=0A>=C2=A0=C2=A0= expires-in =3D 1*DIGIT=0A>=C2=A0=0A>A.15.=C2=A0 "username" Syntax=0A>=C2= =A0=0A>=C2=A0=C2=A0 The "username" element is defined in Section 4.3.2:=0A>= =C2=A0=0A>=C2=A0=C2=A0 username =3D *=0A>=C2=A0=0A>=C2= =A0=C2=A0 (This matches the "userid" definition in the HTTP Basic=0A>=C2=A0= =C2=A0 Authentication Scheme [RFC2617].)=0A>=C2=A0=0A>A.16.=C2=A0 "password= " Syntax=0A>=C2=A0=0A>=C2=A0=C2=A0 The "password" element is defined in Sec= tion 4.3.2:=0A>=C2=A0=0A>=C2=A0=C2=A0 password =3D *TEXT=0A>=C2=A0=0A>=C2= =A0=C2=A0 (This matches the "password" definition in the HTTP Basic=0A>=C2= =A0=C2=A0 Authentication Scheme [RFC2617].)=0A>=C2=A0=0A>A.17.=C2=A0 "refre= sh_token" Syntax=0A>=C2=A0=0A>=C2=A0=C2=A0 The "refresh_token" element is d= efined in Section 5.1 and Section 6:=0A>=C2=A0=0A>=C2=A0=C2=A0 refresh-toke= n =3D b64token=0A>=C2=A0=0A>A.18.=C2=A0 Endpoint Parameter Syntax=0A>=C2=A0= =0A>=C2=A0=C2=A0 The syntax for new endpoint parameters is defined in Secti= on 8.2:=0A>=C2=A0=0A>=C2=A0=C2=A0 param-name =3D 1*name-char=0A>=C2=A0=C2= =A0 name-char=C2=A0 =3D "-" / "." / "_" / DIGIT / ALPHA=0A>=C2=A0=0A>=C2=A0= =0A>_______________________________________________=0A>OAuth mailing list= =0A>OAuth@ietf.org=0A>https://www.ietf.org/mailman/listinfo/oauth=0A>=0A>= =0A> From julian.reschke@gmx.de Sat Jun 2 10:55:21 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 172AD21F8616 for ; Sat, 2 Jun 2012 10:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.882 X-Spam-Level: X-Spam-Status: No, score=-104.882 tagged_above=-999 required=5 tests=[AWL=-2.283, 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 eVhiSxi-JgVA for ; Sat, 2 Jun 2012 10:55:20 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 0DD4321F860E for ; Sat, 2 Jun 2012 10:55:19 -0700 (PDT) Received: (qmail invoked by alias); 02 Jun 2012 17:55:18 -0000 Received: from p54BB2834.dip.t-dialin.net (EHLO [192.168.178.36]) [84.187.40.52] by mail.gmx.net (mp004) with SMTP; 02 Jun 2012 19:55:18 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/VistjnZ3Vbv9r7wwhwlh1oCuBWEsIk5wKd1l6jc CPJqS6mKFC0OoH Message-ID: <4FCA5384.3060306@gmx.de> Date: Sat, 02 Jun 2012 19:55:16 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Mike Jones References: <4E1F6AAD24975D4BA5B16804296739436652634C@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436652634C@TK5EX14MBXC284.redmond.corp.microsoft.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] ABNF elements for suggested WG review X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 17:55:21 -0000 On 2012-06-02 10:10, Mike Jones wrote: > Dear working group, > > It turns out that writing an ABNF for the Core spec pointed out that the > syntax of a number of the OAuth protocol elements had not been > previously defined. (Thanks, Sean, for having us do this!) I took a stab > at specifying appropriate ABNF values for each of the protocol elements, > but I would request that the working group actively review the choices > in my proposed draft. > > For instance, I chose to use the same syntax definitions for username > and password and client_id and client_secret as HTTP Basic used for > userid and password. Other choices were possible, such as perhaps > limiting client_id and possibly username values to use “unreserved” > characters, rather than allowing all characters other than “:” (as HTTP > Basic did with userid). > > Please particularly review the syntax definitions for these elements, as > I had to make choices that went beyond the current specs to provide > unambiguous syntax definitions: > > client_id > > client_secret > > state > > code > > access_token > > username > > password > > refresh_token > > The full proposed ABNF section follows. > > -- Mike > > Appendix A. Augmented Backus-Naur Form (ABNF) Syntax > > This section provides Augmented Backus-Naur Form (ABNF) syntax > > descriptions for the elements defined in this specification using the > > notation of [RFC5234]. Elements are presented in the order first > > defined. > > Some of the definitions that follow use the "unreserved" and "URI" > > definitions from [RFC3986], which are: > > unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" > > URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ] > > Some of the definitions that follow use the "b64token" syntax below, > > which matches the "b64token" syntax defined by HTTP/1.1, Part 7 > > [I-D.ietf-httpbis-p7-auth]: > > b64token = 1*( ALPHA / DIGIT / > > "-" / "." / "_" / "~" / "+" / "/" ) *"=" > > A.1. "client_id" Syntax > > The "client_id" element is defined in Section 2.3.1: > > client-id = * > > (This matches the "userid" definition in the HTTP Basic > > Authentication Scheme [RFC2617].) TEXT is defined in RFC 2616 as TEXT = and OCTET = So what character encoding do you use? Possible answers are "it depends", "ISO-8859-1", and "UTF-8". The same comment applies to everything else using TEXT.. > A.6. "redirect_uri" Syntax > > The "redirect_uri" element is defined in Section 4.1.1, > > Section 4.1.3, and Section 4.2.1: > > redirect-uri = URI Are you sure that this is not a URI-reference??? > ... Best regards, Julian From barryleiba.mailing.lists@gmail.com Sat Jun 2 15:39:57 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C863B21F8452 for ; Sat, 2 Jun 2012 15:39:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103 X-Spam-Level: X-Spam-Status: No, score=-103 tagged_above=-999 required=5 tests=[AWL=-0.023, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ob97DKJ-EByR for ; Sat, 2 Jun 2012 15:39:57 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0585721F8450 for ; Sat, 2 Jun 2012 15:39:56 -0700 (PDT) Received: by lagv3 with SMTP id v3so2444978lag.31 for ; Sat, 02 Jun 2012 15:39:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Hmln9ZB/8MhNAt2CIYHsp4ML/4gXpeW1KRQQiGmunJQ=; b=KacUSBJV3TrxLwxnt9agwp0b0BcjEHxqi+WOVIII2b9mAEmFCapb5q4QAVdVZ7wmkC AzgBeAcGcvbXE+02nuYN07c8rRIxUU6Bl34KI7L68mnTfpYAGUYAptYVeI662oG3woBJ 3dUDQWV9FyXCvR7xs6orf2UQ00eI7ehpkaYCPNN/LTUaG4VYeIw2a4VmYycr5zBkkyZm DVPoK6+9VetRMN/F5bE+kxi3pph8B8dWaIA33iFqXYh7L/Qg8+E1OIfne8bu1Rg+hrER oQ2aNgQk6T/sKvnpxx0ATwKsYI7SrsboxspvlJSxq75Ot7JdL+aZWXozkaQF8CIV0kqe oPdw== MIME-Version: 1.0 Received: by 10.152.111.200 with SMTP id ik8mr7575606lab.15.1338676795971; Sat, 02 Jun 2012 15:39:55 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.48.104 with HTTP; Sat, 2 Jun 2012 15:39:55 -0700 (PDT) In-Reply-To: <1338652376.77581.YahooMailNeo@web31808.mail.mud.yahoo.com> References: <4E1F6AAD24975D4BA5B16804296739436652634C@TK5EX14MBXC284.redmond.corp.microsoft.com> <1338652376.77581.YahooMailNeo@web31808.mail.mud.yahoo.com> Date: Sat, 2 Jun 2012 18:39:55 -0400 X-Google-Sender-Auth: 7c2Xy6iAT6M7gaqkdbs5Km5ZfII Message-ID: From: Barry Leiba To: William Mills Content-Type: text/plain; charset=ISO-8859-1 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] ABNF elements for suggested WG review X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 22:39:57 -0000 > Things like "%x21 / %x23-5B / %x5D-7E" should be named once and re-used. An excellent suggestion, and one I hope is adopted. Barry From Michael.Jones@microsoft.com Sat Jun 2 19:03:07 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5F6811E807F for ; Sat, 2 Jun 2012 19:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.668 X-Spam-Level: X-Spam-Status: No, score=-3.668 tagged_above=-999 required=5 tests=[AWL=-0.069, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b1RWX9jzlHhV for ; Sat, 2 Jun 2012 19:03:07 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe002.messaging.microsoft.com [216.32.181.182]) by ietfa.amsl.com (Postfix) with ESMTP id DDF8D11E8073 for ; Sat, 2 Jun 2012 19:03:06 -0700 (PDT) Received: from mail152-ch1-R.bigfish.com (10.43.68.244) by CH1EHSOBE012.bigfish.com (10.43.70.62) with Microsoft SMTP Server id 14.1.225.23; Sun, 3 Jun 2012 02:02:31 +0000 Received: from mail152-ch1 (localhost [127.0.0.1]) by mail152-ch1-R.bigfish.com (Postfix) with ESMTP id 0784F4401DC; Sun, 3 Jun 2012 02:02:31 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -26 X-BigFish: VS-26(zz9371I542Mzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839h944hd25hf0ah) Received-SPF: pass (mail152-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC103.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail152-ch1 (localhost.localdomain [127.0.0.1]) by mail152-ch1 (MessageSwitch) id 1338688948876099_632; Sun, 3 Jun 2012 02:02:28 +0000 (UTC) Received: from CH1EHSMHS016.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.254]) by mail152-ch1.bigfish.com (Postfix) with ESMTP id D40942E0044; Sun, 3 Jun 2012 02:02:28 +0000 (UTC) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS016.bigfish.com (10.43.70.16) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sun, 3 Jun 2012 02:02:28 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.189]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.02.0298.005; Sun, 3 Jun 2012 02:03:02 +0000 From: Mike Jones To: Barry Leiba , William Mills Thread-Topic: [OAUTH-WG] ABNF elements for suggested WG review Thread-Index: Ac1Alx0u1VneJZSBR8aFxCHOlLRpzQAQKmMAAA42t4AABxIM4A== Date: Sun, 3 Jun 2012 02:03:01 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366526E81@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739436652634C@TK5EX14MBXC284.redmond.corp.microsoft.com> <1338652376.77581.YahooMailNeo@web31808.mail.mud.yahoo.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] ABNF elements for suggested WG review X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 02:03:07 -0000 Yep - on my to-do list. I'll publish an updated version after giving peopl= e a few days to discuss. Cheers, -- Mike -----Original Message----- From: barryleiba.mailing.lists@gmail.com [mailto:barryleiba.mailing.lists@g= mail.com] On Behalf Of Barry Leiba Sent: Saturday, June 02, 2012 3:40 PM To: William Mills Cc: Mike Jones; oauth@ietf.org Subject: Re: [OAUTH-WG] ABNF elements for suggested WG review > Things like "%x21 / %x23-5B / %x5D-7E" should be named once and re-used. An excellent suggestion, and one I hope is adopted. Barry From phil.hunt@oracle.com Sat Jun 2 23:13:45 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A4DD21F84B6 for ; Sat, 2 Jun 2012 23:13:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.901 X-Spam-Level: X-Spam-Status: No, score=-9.901 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 Qgg6JJ7t-AJI for ; Sat, 2 Jun 2012 23:13:44 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id 9A21221F84B4 for ; Sat, 2 Jun 2012 23:13:44 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q536DfjA021713 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 3 Jun 2012 06:13:42 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 q536DeVd010462 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 3 Jun 2012 06:13:41 GMT Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q536DeoG028842; Sun, 3 Jun 2012 01:13:40 -0500 Received: from [192.168.1.125] (/24.87.212.4) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 02 Jun 2012 23:13:40 -0700 References: <09CE58C6-9409-4E28-B4CA-DC76C37B898E@gmx.net> In-Reply-To: <09CE58C6-9409-4E28-B4CA-DC76C37B898E@gmx.net> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (9B206) From: Phil Hunt Date: Sat, 2 Jun 2012 23:16:13 -0700 To: Hannes Tschofenig X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Meeting slot for the Vancouver IETF meeting requested X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jun 2012 06:13:45 -0000 I am attending.=20 Phil On 2012-06-02, at 0:46, Hannes Tschofenig wrote:= > Hi all,=20 >=20 > I have requested a 2,5 hour slot for the upcoming meeting.=20 >=20 > While the next meeting is still a bit away it is nevertheless useful to he= ar=20 > * whether you plan to attend the next meeting, and=20 > * whether you want to present something.=20 >=20 > I could imagine that these documents will be discussed: > * draft-ietf-oauth-dyn-reg > * draft-ietf-oauth-json-web-token > * draft-ietf-oauth-jwt-bearer > * draft-ietf-oauth-revocation > * draft-ietf-oauth-use-cases >=20 > To the draft authors of these docuemnts: Please think about the open issue= s and drop a mail to the list so that we make some progress already before t= he face-to-face meeting.=20 >=20 > I am assume that the following documents do not require any discussion tim= e at the upcoming IETF meeting anymore: > * draft-ietf-oauth-assertions > * draft-ietf-oauth-saml2-bearer > * draft-ietf-oauth-urn-sub-ns > * draft-ietf-oauth-v2 > * draft-ietf-oauth-v2-bearer >=20 > Ciao > Hannes >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From torsten@lodderstedt.net Sun Jun 3 00:57:30 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11F8821F85D6 for ; Sun, 3 Jun 2012 00:57:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.649 X-Spam-Level: X-Spam-Status: No, score=-0.649 tagged_above=-999 required=5 tests=[AWL=-1.600, BAYES_50=0.001, HELO_EQ_DE=0.35, J_CHICKENPOX_52=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 V9h3jC3mAyS5 for ; Sun, 3 Jun 2012 00:57:28 -0700 (PDT) Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.99]) by ietfa.amsl.com (Postfix) with ESMTP id 8AD9121F85D3 for ; Sun, 3 Jun 2012 00:57:27 -0700 (PDT) Received: from [91.2.74.159] (helo=[192.168.71.36]) by smtprelay05.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1Sb5gj-00014d-7K; Sun, 03 Jun 2012 09:57:25 +0200 Message-ID: <4FCB18E4.3070707@lodderstedt.net> Date: Sun, 03 Jun 2012 09:57:24 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Stephen Farrell References: <4FC3C53E.8020704@cs.tcd.ie> In-Reply-To: <4FC3C53E.8020704@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-threatmodel-05 X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 07:57:30 -0000 Hi Stephen, thank you very much for your review. Having scanned through your comments, I think the document would definitely benefit from incorporating them into a new revision. We will start working on it now, but I can't tell you how long it will take (due to daytime job load). best regards, Torsten. Am 28.05.2012 20:34, schrieb Stephen Farrell: > > Hi all, > > I've gotten the publication request for oauth-threatmodel > so here's my AD review of -05. > > Its quite a read (and a good one) but I've a bunch of > questions. Some of these will need fixing I suspect > but a lot are ok to fix later after IETF LC, depending > on whether the authors want to re-spin it before then > or not. But I'd like to at least see reactions to the > questions before I start IETF LC. > > Although there are many many nits and typos, those > don't actually make the document unreadable so > though I'd prefer to see 'em fixed now, I'm ok with > that happening later if its a problem to get it > all done now. > > If you want to argue for going ahead with IETF LC > now please do so, but I suspect that this might need > a revised ID to fix at least a couple of the points > raised below. If nobody does argue to go ahead now, > I'll mark it as revised ID needed, but first let's > see what the answers are to the questions. > > Cheers, > S. > > > (1) s/RFC1750/RFC4086/ is needed as noted in the write-up. > > (2) You don't say anything about the probability of > occurrence of the various threats. I realise that you > can't be precise but it seems wrong to say nothing. Would > it be worth at least saying that that's not done here and > that readers of this document need to do their own risk > analysis including that aspect? > > (3) Many deployments will use TLS accelerators. That > means that TLS isn't fully e2e, and that opens up some > (mainly) insider attacks or attacks that can be launched > from within a compromised DMZ, but from outside the server > applications. Does that need a mention somewhere? (I've > seen systems like that deployed and a lot could go wrong > from the inside, so I think this is a real threat.) > > (4) Could you use just one of "client identity" or "client > identifier" consistently? I'd much prefer the latter, > which has also been the outcome of various discussions on > this topic elsewhere. For example you say "revocation of > such an identity" at the end of p13, and that's a > potential rathole, better to say "revocation of the rights > associated with a client identifier" or similar I think. > And similar changes throughout. > > (5) 4.4.2.2: Here you recommend native applications should > use an embedded browser, but earlier you said that was a > bad idea. I think you need to be consistent or else > provide more about when its ok to embed and when its not. > Did I misread it or does that need a change? > > (6) 4.4.3.1: This calls for "obfuscation" of passwords in > logs. I think you ought be stronger there and call for > strong encryption of passwords wherever they are stored, > be that logs or DBs or whatever. Would'nt that be reasonable? > > (7) 4.6.4: 1st countermeasure: I don't think you mean > address here (in the sense of an IP address, which is what > that means) but rather the domain name or FQDN or URL. In > any case, you need to say what is meant clearly. (Also in > 5.1.5.6 and elsewhere when you use the term "address".) > > (8) 4.6.6: You say to use Cache-Control, but don't say > how. Is more needed really? Maybe there's a good document > you could reference for that? (I'm not suggesting you add > a lecture on caching btw:-) > > (9) 5.1.1: needs a reference to RFC 5246 (and better to > just say TLS and not say SSL, at least for me :-) > > (10) 5.1.1: needs a reference to whatever you mean by > "VPN" since there are many types of VPN. I assume you mean > an IPsec VPN? But even if not, saying more would be good. > > (11) 5.1.2: needs a reference to RFC 5280 and/or RFC 6125 > and/or RFC 2818. Bascially, you need to say how this is > done (by reference). > > (12) 5.1.4.1: Isn't there some good reference you can give > here? (Having said that, I'd have to go look myself, but > I'd maybe start with owasp or sans.) > > (13) 5.1.4.2.2: if p(collision) should be<=2^(-160) then > what's the point of saying it ought be<= 2^(-128)? Also > if sha-1 were perfect, then the 160 bits output would > really have a collision probability of about 2^(-80) with > many many tokens, but not 2^(-160). I think you need > to fix something there. Perhaps you're really saying that > all high-entropy secrets should be>=128 bits long and > constructed with a good (P)RNG? If so, saying so more > clearly would be better. Not everyone will get the > collision probability way of saying that even when its > properly stated. (This text is also repeated, be better if > you just said this once I think.) > > (14) 5.1.5.2: what is a "reasonable duration" - I don't > think its ok to say that but nothing else. Can't you give > some "reasonable" examples based on current usage? > > (15) 5.1.5.5: needs a reference to SAML assertions with > the current text. > > (16) 5.2.2.3: this describes a refresh token rotation > scheme that I don't recall being discussed on the list, so > this is just to check that that rotation scheme, as > described, doesn't ring any alarms bells for the WG. If > not, that's fine. And if it was discussed on the list and > I've forgotten, then sorry about that:-) > > (17) 5.2.2.5: Using IMEI's like this has privacy > implications that I think you ought call out. A single > sentence and a reference to something that says "be > careful about privacy here" would be fine I'd say. (And > you need a reference for "IMEI" and to expand the term.) > > (18) 5.2.2.6: needs a reference for X-FRAME-OPTION. > There's a websec draft about that I think. > > (19) 5.2.3.4: what do you mean when you say "for different > deployments of a client"? That could be one secret per > install or one secret for all customers of a mobile > operator and those are radically different. I think you > need to be clear and hope you mean the former. That's > almost cleared up in the 3rd paragraph of the section but > I wanted to just check. Not sure "deployment" is the best > term there really - what's wrong with "installation"? > > (many:-) nits and typos: > > 2.3.1: maybe explain "handle-based design" or give a > reference? (Or maybe just a forward ref to 3.1?) > > 2.3.3: It might be worth re-iterating that the term > "client" in oauth is used differently, e.g. by copying a > bit of text from the base spec. I can see folks being > confused by this otherwise. > > 3.1: "is digitally signed" - do you mean it has data > integrity and origin authentication? If MACs are commonly > used (or maybe authenticated encryption), and not > necessarily signatures, then saying that would be better. > > 3.1.2: typo: s/this mechanisms/this mechanism/ > > 3.1.2: maybe s/Expires_In/expires_in/ to match the case in > the base spec? I think it'd be better not to capitalise > this in case it finds its way into someone's code. You > could also use "Expires In" in the title and then say that > its "expires_in" in the protocol. Might be worth doing > something generic to call out when you're talking about > specific things from the protocol, e.g. use a convention > like ``expires_in'' or "expires_in" consistently and say > that in the intro. > > 3.4: typo: s/the later/the latter/ > > 3.4: bullet item 1 isn't really a reason for anything but > a downside of doing this, at least as written. Maybe this > needs to be tweaked? > > 3.6: expand CSRF on 1st use and maybe give a reference > CSRF is expanded in 4.4.1.8 which is a good bit later, > and also in 4.4.2.5 which could presumably be > shortened a bit by removing the repetition. > > 3.7: typo: s/collage associated request/collate associated > requests/ > > 3.7: Maybe give a pointer to the definition of "native > application" in the base spec (Its section 9 of that.) > 2nd last para of p13 would be a good place for that. > > section 4: maybe s/Security Threat Model/Threat Model/ > in the section title - what other kind of threat > model is there? > > section 4: I wondered how we know the threat model > is "comprehensive"? Perhaps "detailed" is better? > > 4.2.1: typo: s/Users/users/g unless you mean something > special? > > 4.2.2: typo: s/a understandable/an understandable/ > > 4.2.2: "...based on who the client is." is unclear > and not gramatically nice:-) "...based on the client > identifier." would seem better. > > 4.3.1: typo? s/on transit/in transit/ Or did you > mean something else? and s/may attempts/may attempt/ > > 4.3.3: maybe s/Revelation/Disclosure/ to be a tad > less biblical:-) > > 4.3.3: typo? 1st countermeasure reads oddly and > refers to a different place than other references > to TLS - is that correct? > > 4.3.3: digest auth is nearly the same as sending > credentials over the wire, TLS client auth based > on certificates would be a better example, even > if its not often done. > > 4.3.4: 4.3.2 points to 5.1.4.1.2 but this doesn't. > Maybe it ought to? > > 4.3.6: typo s/an authorization servers/an authorization > server/ > > 4.3.6: 4.3.5 refers to 5.1.4.2.2 wrt entropy. Is there > a reason to not do that here too? > > 4.4: typo? s/tokens endpoint/token endpoint/ ? > > 4.4.1.1: typo: s/by different ways/in different ways/ > > 4.4.1.1: typo-fix-typo? HTTP has a "Referer" header field, > but you fixed their typo here - might be better to live > with the bad spelling, in which case > s/referrer/referer/g;-) > > 4.4.1.1: Is there no better way to reference these > OASIS docs? More importantly, is there no better (more > stable) reference than thomasgross.net for the > PDF you reference? Tidying this up would be good. > > 4.4.1.1 and elsewhere: a few times you say "such as > TLS or SSL," I think it'd be better to just say TLS > there and do it consistently everwhere. In other > places (e.g. 4.4.1.5) you say "HTTPS" - again that'd > be better done consistently. > > 4.4.1.1: typo: s/redeem a authorization code/redeem > an authorizatio code/ > > 4.4.1.4: "counterfeit a valid client" reads oddly, > do you mean "pretend to be a valid client"? If so, > I think that'd be clearer. > > 4.4.1.4: "and to prevent unauthorized access to > them" - I think you might add "via the oauth > protocol" there since the AS isn't responsible for > all possible ways of preventing unauthorized access. > > 4.4.1.4: typo: s/not neccesserily indicates/doesn't > necessarily indicate/ > > 4.4.1.4: typo: s/user should be explained the purpose/ > something better/ :-) > > 4.4.1.4: expand/define CAPTCHA on 1st use. Give a > reference for this too. Especially since you also > have 5.1.4.2.5, which is maybe the best place for > the reference. > > 4.4.1.4: isn't a PIN code another user authentiation? > Seems like a bad example of automatic authentication, > since it isn't automatic if the user has to enter a > PIN. > > 4.4.1.6: Is Facebook a trademark? Maybe better to not > use that if so? > > 4.4.1.7: typo: s/achieve that goal/achieves that goal/ > > 4.4.1.7: typo: s/victims resources/victim's resources/ > > 4.4.1.7: typo: s/The attackers gains/The attacker gains/ > > 4.4.1.7: typo: s/then the target web site/rather than > the target web site/ > > 4.4.1.7: "session fixation" could do with a reference > or definition, and that might be better earlier in > this section and not just in the countermeasures > part. > > 4.4.1.7: typo: s/kind of attacks/kind of attack/ > > 4.4.1.8: typo: s/not follow untrusted/to not follow > untrusted/ > > 4.4.1.9: maybe add a reference for "iframe"? And > you say "iFrames" later, better to be consistent. > > 4.4.1.9: 1st countermeasure - do you mean end-user > authorization here or end-user authentication? And > would it be better to say "system browser" or > something rather than "external browser"? (I forget > what phrase you used for that earlier but there > was something bettter:-) > > 4.4.1.9: "javascript framebusting" really needs > a reference > > 4.4.1.10: typo: s/the victims resources/the victim's > resources/ > > 4.4.1.10: typo: s/or split the/or splits the/ > > 4.4.1.10: "corresponding form post requests" isn't > clear to me - does that need rephrasing or is it > just me? > > 4.4.1.10: this is the first mention of cookies, which > I found surprising, but that's all;-) > > 4.4.1.10: the 2nd "ways to achieve this" bullet is > a bit unclear - which "It" and whose browser? I > think this could be clearer. > > 4.4.1.10: typo: s/as native app/as a native application/ > > 4.4.1.10: what does "assume" the threat mean? > > 4.4.1.10: typo: s/an user interaction/a user interaction/ > > 4.4.1.10: typo: s/CAPTCAs, or/CAPTCHAs/ or else get > rid of the "or" from the last bullet > > 4.4.1.10: typo: s/send out of bound/sent out of band/ > > 4.4.1.10: typo: s/instance message/instant message/ > > 4.4.1.11: typo? s/directing user(s) browser/directing > the user's browser/ ? > > 4.4.1.11: I don't get the explanation here. Are you > assuming (but not saying) that generating non-trivial > entropy is a slow process? (e.g. /dev/random blocking?) > Its also not clear what "pool" you mean? This probably > needs a bit of tweaking. > > 4.4.1.12: semicomplete.com may not be a sufficiently > stable reference - can't you find a better one? > > 4.4.1.12: typo: s/Defenses such rate limiting/Defenses > such as rate limiting/ > > 4.4.1.12: typo: s/an anonymizing systems/an anonymizing > system/ > > 4.4.1.12: nicest typo yet! s/annoying system/anonymizing > system/ :-) > > 4.4.1.12: typo? maybe s/iframe/iFrame/ again? > > 4.4.1.12: 1st reference to "the CSRF token" here? That > might warrant a reference of some sort? (Maybe to > a later section?) > > 4.4.1.12: Facebook again. > > 4.4.1.12: Signing the code seems like a bit of a hack. Do > you really want to recommend this here? I suspect it'd end > up different if you actually tried it out aiming for an > interoperable solution. I'd suggest deleting this, or > maybe make it less specific, e.g. saying if origin > authentication for authorization codes could be validated > by clients, then that'd be a countermeasure, but that > there's no current spec for that. (And doing that might > just move the DoS to somewhere else depending how you > did it.) > > 4.4.2: typo: s/and It cannot/and it cannot/ > > 4.4.2.1: Is the countermeasure here TLS? If so, better to > say so. > > 4.4.2.2: requests aren't cached are they but rather > responses? > > 4.4.2.3: typo: s/An malicious/A malicious/ > > 4.4.2.3: The reference back to 4.4.1.4 isn't very > clear since a lot of the countermeasures there > mention authentication. It'd be better to explicitly > list things here or else if you stick with the > backwards reference to be more explicit about whic > exactly apply. > > 4.4.2.5: Is this entirely identical to 4.4.1.8? That > doesn't seem right. If it is, then say so explicitly. > If not, then say what's different. > > 4.4.3: 1st mention of username/password anti-pattern, > so you could add a reference > > 4.4.3: Be good to metion here that passwords are often > used for>1 service, so this anti-pattern risks whatever > else is accessible with that credential or an > algorithmically derivable equivalent (e.g. > joe@example.com/pwd might easily allow someone to guess > that the same pwd is used for joe.user@example.net) and > then another countermeasure is to educate users to > not use the same pwd for multiple services (hard as > that is to really do;-) > > 4.4.3.4: again digest auth isn't a good example > here, but client certs are. > > 4.4.3.6: What does "Abandon on grant type..." mean? > If you mean "don't do this" then say that more > clearly. > > 4.6.2: typo: s/transport security measure/transport > security measures/ or maybe just say TLS > > 4.6.2: typo: s/nounces/nonces/ > > 4.6.3: 1st countermeasure: maybe s/difficult/infeasible/ > I don't see why "difficult" guessing is hard enough? > > 4.6.4: typo: s/a valid access tokens/a valid access token/ > > 4.6.4: Do you mean the IP address in the 2nd > countermeasure? I'm not sure, esp. given the above. > > 4.6.4: typo: s/miss the capabilities/lack the capability/ > > 4.6.6: reference to 2616 is broken > > 4.6.6: Should you reference httpbis drafts? Just asking, I > can see arguments for referencing just 2616 or just > httpbis or both, given that this'll be read for hopefully > a while after httpbis is done. > > 4.6.7: referrer vs. referer again > > 4.6.7: What is an appropriat logging configuration? Can > you give a reference maybe or is it really that well > known? > > 4.6.7: Reloading the target page again? Are you really > recommending that? > > 5.1: typo: s/consideratios/considerations/ > > 5.1.3: I think you should note the email notifications > can be a phishing vector so don't make your emails > such that lookalike phish messages can easily be > derived from them. > > 5.1.3: Don't you need to say something about getting > email notifications delivered and not treated as spam? > Maybe you could recommend dkim here or other ways to > get better delivery. (Not sure myself, probably best > to ask someone who operates like this so see if there's > stuff to be said.) > > 5.1.4.1.3: typo: s/not store credential/not store > credentials/ > > 5.1.4.1.4: salted hashes don't prevent offline > dictionary attacks, they just increase the workload > > 5.1.5.1.4: would it be worthwhile recommending that > different client credentials be used in development > or integration mode vs. when operational? I've seen > a bunch of times when programmers were given "live" > API keys when that could've been avoided. > > 5.1.4.1.5: I don't get this. If it was only that > easy:-) I think you need to say which private keys > are used here and for what for this section to be > useful. > > 5.1.4.2.1: I think you could note that complex password > policies can also increase the liklihood that users > re-use passwords or write them down or store them > somewhere not so good, if e.g. the entropy required > over all the user's passwords (dozens usually) is > too great for long-term memory. > > 5.1.5.1: typo: s/Basis of/The basis of/ > > 5.1.5.1: typo: s/sensible service/sensitive service/ > (2nd best typo:-) > > 5.1.5.3: typo: s/preciser/more precise/ > > 5.1.5.3: typo: s/refreshments/refreshes/ > > 5.1.5.4: 2nd bullet is not a threat but a goal > > 5.1.5.4: typo: s/redeem a/redeem an/ > > 5.1.5.5: what is a "rough" server? Do you mean rogue? > > 5.5.5.6: I think you need to clarify what "address" > means here too. > > 5.1.5.9: please clarify if you mean digitally signed > (asymmetric) or also include MACing here > > 5.1.5.10: typo: s/Self-contained/Self-contained tokens/ > > 5.1.5.10: s/privacy/confidentiality/ ? > > 5.1.5.10: this (typically, I'd guess) requires sharing > symmetric keys between server nodes, so you should > say that as its a bunch of work. > > 5.1.5.11: I don't get why you want to repeat this > text (and its error:-) better to refer back to > the earlier section I think. > > 5.1.5.12: Another place where a SAML reference would > be needed. > > 5.1.6: 2nd bullet is not a "measure" but a goal. If > you had something in mind, it doesn't come out from > that text. > > 5.2.2.2: You say the binding should be protected, but > don't say how. I think you ought. > > 5.2.3: typo: s/sub-sequent/subsequent/ but maybe > better to delete the word > > 5.2.3: 2nd bullet - "trustworthiness" has gotta > be the wrong word there, what did you mean? > > 5.2.3: typo: s/statics/statistics/ > > 5.2.3: typo: s/support achieve objectives/achieve these > objectives/ ? > > 5.2.3: typo: s/by hand of an administrator/something > better/ > > 5.2.3.1: "prevents...overestimating" seems wrong, I think > you mean it reduces the probability of mistakenly treating > a useless authentication as a good one. (The point is > that servers don't "overestimate," only people do that.) > > 5.2.3.1: "cannot be entirely protected" seems like > understatement - the reality is any such secret will > leak out from anything that's any way successful. It > only protects stuff that *nobody* cares about. > > 5.2.3.1: typo: s/trust on/trust/ But I'd rephrase it > to not use the terms "trust" nor "identity" and then > it'd be better I think. > > 5.2.3.2: typo? s/The authorization may/The authrozation > server may/ ? Not sure what "issue a cliend id" means > either. (Same in 5.2.3.3) > > 5.2.3.4: typo: s/A authorization server/An authorization > server/ > > 5.2.3.5: what are "validated properties"? > > 5.2.3.5: what is the 1st bullet list on p57? there's > no introductory text? > > 5.2.3.5: the "it" in "it only works" in the last > paragraph isn't clear - which "it" do you mean? > > 5.2.3.5: saying discovery "gets involved" seems > wrong - do you mean "is used"? And what is the > "that" in "that's no longer feasible"? > > 5.2.3.6: typo: s/be unintentionally for/unintentionally > affect/? > > 5.2.3.7: typo: s/to distribute client_secret/to > distribute a client_secret/ > > 5.2.4.1: Is a "security certificate" a public key > certificate? If so, saying that is better. > > 5.2.4.1: the references to 5.7.2.x are wrong and > look like you're missing some xref's in the xml > maybe > > 5.2.4.2: you said "address" again, so the usual > question arises :-) > > 5.2.4.3: typo: s/in all situation/in situations/ > (not sure "all" is right so suggest deleting it) > > 5.2.4.4: again, be good to say how to protect > the binding > > 5.2.4.5: as for 5.2.4.4 say how binding is done > > 5.3.1: typo: s/a associated/an associated/ > > 5.3.1: "entirely protected" is (again:-) understatement > see above for a suggestion > > 5.3.1: what does "trust on the client's identity" mean? > Its not clear anyway > > 5.3.3: typo: s/operation systems/operating systems/ > (enrire 2nd& 3rd paras could do with re-phrasing) > > 5.3.4: typo: s/their level/the level/ > > 5.3.5: this is too terse - is it really finished? I'd > say there's a sentence or two missing. > > 5.4.2: what does it mean to "encourage resource > servers" to do something? I guess you mean to encourage > the people deploying those to pick resource servers > with that capability and to turn that on. > > 5.4.2: not sure if everyone will know what a > "distinguished name" is, maybe add a reference to > rfc 5280? > > 5.4.2: token-bound secrets would be used to MAC > the request and not to sign, be better to make that > clear even if you still call that "signing" here > (its not really, if we're being pedantic) > > 5.4.2: typo: s/This mechanisms/This mechanism/ > > 5.4.2 and 5.4.3: I forget - where are the protocol > mechanisms for this defined? Can you give a reference > or say that its future stuff if there aren't any > good ones? > > 5.5: typo: s/capable to validate/capable of validating/ > > 8.1: Is the base spec really normative? I'd say you're > fine with that as informative too. > > 8.2: there are a bunch of references missing as per > the questions above > > 8.2: is there no better (more stable) reference than > portablecontacts.net? > > > > > > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From torsten@lodderstedt.net Sun Jun 3 09:09:53 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3380221F84FF for ; Sun, 3 Jun 2012 09:09:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.449 X-Spam-Level: X-Spam-Status: No, score=-1.449 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ck8aJM1fupuc for ; Sun, 3 Jun 2012 09:09:52 -0700 (PDT) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.32]) by ietfa.amsl.com (Postfix) with ESMTP id 84A1421F84B3 for ; Sun, 3 Jun 2012 09:09:52 -0700 (PDT) Received: from [91.2.74.159] (helo=[192.168.71.36]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1SbDNG-00021Q-CF; Sun, 03 Jun 2012 18:09:50 +0200 Message-ID: <4FCB8C4D.3090703@lodderstedt.net> Date: Sun, 03 Jun 2012 18:09:49 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Hannes Tschofenig References: <09CE58C6-9409-4E28-B4CA-DC76C37B898E@gmx.net> In-Reply-To: <09CE58C6-9409-4E28-B4CA-DC76C37B898E@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Meeting slot for the Vancouver IETF meeting requested X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jun 2012 16:09:53 -0000 I plan to attend. regards, Torsten. Am 02.06.2012 09:46, schrieb Hannes Tschofenig: > Hi all, > > I have requested a 2,5 hour slot for the upcoming meeting. > > While the next meeting is still a bit away it is nevertheless useful to hear > * whether you plan to attend the next meeting, and > * whether you want to present something. > > I could imagine that these documents will be discussed: > * draft-ietf-oauth-dyn-reg > * draft-ietf-oauth-json-web-token > * draft-ietf-oauth-jwt-bearer > * draft-ietf-oauth-revocation > * draft-ietf-oauth-use-cases > > To the draft authors of these docuemnts: Please think about the open issues and drop a mail to the list so that we make some progress already before the face-to-face meeting. > > I am assume that the following documents do not require any discussion time at the upcoming IETF meeting anymore: > * draft-ietf-oauth-assertions > * draft-ietf-oauth-saml2-bearer > * draft-ietf-oauth-urn-sub-ns > * draft-ietf-oauth-v2 > * draft-ietf-oauth-v2-bearer > > Ciao > Hannes > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From stephen.farrell@cs.tcd.ie Sun Jun 3 10:01:46 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E8AD21F84F0 for ; Sun, 3 Jun 2012 10:01:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.66 X-Spam-Level: X-Spam-Status: No, score=-102.66 tagged_above=-999 required=5 tests=[AWL=-0.661, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Btpb4py5Qcoo for ; Sun, 3 Jun 2012 10:01:44 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 4FBBF21F8449 for ; Sun, 3 Jun 2012 10:01:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 86B5A1714F8; Sun, 3 Jun 2012 18:01:41 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1338742899; bh=sukXUBYdDBjlF9 8ZGqn2pGDA5i+CQreD+ZHbUkfcDuQ=; b=g4xtTJiKMWjjcxSX63pn9RrUDOiSCr XTiHxtgJlzLfHsnB3Q3F9HKVpniMAZh64I4eGJHg8Hob7vWKNe5c/AYAjZm9eyNk dJggRGOjhpPnyP0mJDqkDSYlnZOnBxOa8PeQBXPvZMvyRoqCmBPiEO1vPQmJA/KD zN2as7k4KvZgmtPBiQ2W5tDkanrEk76O57KIAB1m+S6MLVcfW/Z6lNEXHxzvmBtd xsPTYjNJVDSqX2T5giCrTxJAVfuvvUFTjnz6uggjkuB3G4SmjnjxOEHN2TWv1ZD0 qlC06v+f129G8xoFoZ3vQsvF2rkVB6LDHsG3Fqo/HvuK0eCsJVJCXq9w== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id kvrNHQXauUeQ; Sun, 3 Jun 2012 18:01:39 +0100 (IST) Received: from [10.87.48.8] (unknown [86.42.19.2]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 7DF941714E4; Sun, 3 Jun 2012 18:01:37 +0100 (IST) Message-ID: <4FCB9871.3010804@cs.tcd.ie> Date: Sun, 03 Jun 2012 18:01:37 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Torsten Lodderstedt References: <4FC3C53E.8020704@cs.tcd.ie> <4FCB18E4.3070707@lodderstedt.net> In-Reply-To: <4FCB18E4.3070707@lodderstedt.net> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-threatmodel-05 X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 17:01:46 -0000 On 06/03/2012 08:57 AM, Torsten Lodderstedt wrote: > Hi Stephen, > > thank you very much for your review. Having scanned through your > comments, I think the document would definitely benefit from > incorporating them into a new revision. We will start working on it now, > but I can't tell you how long it will take (due to daytime job load). Sure. With 3 authors and most of the comments only needing trivial fixes, I'd hope that's not too long a job. (Or, if it is, maybe ask the chairs to try find more help.) Cheers, S. > > best regards, > Torsten. > > Am 28.05.2012 20:34, schrieb Stephen Farrell: >> >> Hi all, >> >> I've gotten the publication request for oauth-threatmodel >> so here's my AD review of -05. >> >> Its quite a read (and a good one) but I've a bunch of >> questions. Some of these will need fixing I suspect >> but a lot are ok to fix later after IETF LC, depending >> on whether the authors want to re-spin it before then >> or not. But I'd like to at least see reactions to the >> questions before I start IETF LC. >> >> Although there are many many nits and typos, those >> don't actually make the document unreadable so >> though I'd prefer to see 'em fixed now, I'm ok with >> that happening later if its a problem to get it >> all done now. >> >> If you want to argue for going ahead with IETF LC >> now please do so, but I suspect that this might need >> a revised ID to fix at least a couple of the points >> raised below. If nobody does argue to go ahead now, >> I'll mark it as revised ID needed, but first let's >> see what the answers are to the questions. >> >> Cheers, >> S. >> >> >> (1) s/RFC1750/RFC4086/ is needed as noted in the write-up. >> >> (2) You don't say anything about the probability of >> occurrence of the various threats. I realise that you >> can't be precise but it seems wrong to say nothing. Would >> it be worth at least saying that that's not done here and >> that readers of this document need to do their own risk >> analysis including that aspect? >> >> (3) Many deployments will use TLS accelerators. That >> means that TLS isn't fully e2e, and that opens up some >> (mainly) insider attacks or attacks that can be launched >> from within a compromised DMZ, but from outside the server >> applications. Does that need a mention somewhere? (I've >> seen systems like that deployed and a lot could go wrong >> from the inside, so I think this is a real threat.) >> >> (4) Could you use just one of "client identity" or "client >> identifier" consistently? I'd much prefer the latter, >> which has also been the outcome of various discussions on >> this topic elsewhere. For example you say "revocation of >> such an identity" at the end of p13, and that's a >> potential rathole, better to say "revocation of the rights >> associated with a client identifier" or similar I think. >> And similar changes throughout. >> >> (5) 4.4.2.2: Here you recommend native applications should >> use an embedded browser, but earlier you said that was a >> bad idea. I think you need to be consistent or else >> provide more about when its ok to embed and when its not. >> Did I misread it or does that need a change? >> >> (6) 4.4.3.1: This calls for "obfuscation" of passwords in >> logs. I think you ought be stronger there and call for >> strong encryption of passwords wherever they are stored, >> be that logs or DBs or whatever. Would'nt that be reasonable? >> >> (7) 4.6.4: 1st countermeasure: I don't think you mean >> address here (in the sense of an IP address, which is what >> that means) but rather the domain name or FQDN or URL. In >> any case, you need to say what is meant clearly. (Also in >> 5.1.5.6 and elsewhere when you use the term "address".) >> >> (8) 4.6.6: You say to use Cache-Control, but don't say >> how. Is more needed really? Maybe there's a good document >> you could reference for that? (I'm not suggesting you add >> a lecture on caching btw:-) >> >> (9) 5.1.1: needs a reference to RFC 5246 (and better to >> just say TLS and not say SSL, at least for me :-) >> >> (10) 5.1.1: needs a reference to whatever you mean by >> "VPN" since there are many types of VPN. I assume you mean >> an IPsec VPN? But even if not, saying more would be good. >> >> (11) 5.1.2: needs a reference to RFC 5280 and/or RFC 6125 >> and/or RFC 2818. Bascially, you need to say how this is >> done (by reference). >> >> (12) 5.1.4.1: Isn't there some good reference you can give >> here? (Having said that, I'd have to go look myself, but >> I'd maybe start with owasp or sans.) >> >> (13) 5.1.4.2.2: if p(collision) should be<=2^(-160) then >> what's the point of saying it ought be<= 2^(-128)? Also >> if sha-1 were perfect, then the 160 bits output would >> really have a collision probability of about 2^(-80) with >> many many tokens, but not 2^(-160). I think you need >> to fix something there. Perhaps you're really saying that >> all high-entropy secrets should be>=128 bits long and >> constructed with a good (P)RNG? If so, saying so more >> clearly would be better. Not everyone will get the >> collision probability way of saying that even when its >> properly stated. (This text is also repeated, be better if >> you just said this once I think.) >> >> (14) 5.1.5.2: what is a "reasonable duration" - I don't >> think its ok to say that but nothing else. Can't you give >> some "reasonable" examples based on current usage? >> >> (15) 5.1.5.5: needs a reference to SAML assertions with >> the current text. >> >> (16) 5.2.2.3: this describes a refresh token rotation >> scheme that I don't recall being discussed on the list, so >> this is just to check that that rotation scheme, as >> described, doesn't ring any alarms bells for the WG. If >> not, that's fine. And if it was discussed on the list and >> I've forgotten, then sorry about that:-) >> >> (17) 5.2.2.5: Using IMEI's like this has privacy >> implications that I think you ought call out. A single >> sentence and a reference to something that says "be >> careful about privacy here" would be fine I'd say. (And >> you need a reference for "IMEI" and to expand the term.) >> >> (18) 5.2.2.6: needs a reference for X-FRAME-OPTION. >> There's a websec draft about that I think. >> >> (19) 5.2.3.4: what do you mean when you say "for different >> deployments of a client"? That could be one secret per >> install or one secret for all customers of a mobile >> operator and those are radically different. I think you >> need to be clear and hope you mean the former. That's >> almost cleared up in the 3rd paragraph of the section but >> I wanted to just check. Not sure "deployment" is the best >> term there really - what's wrong with "installation"? >> >> (many:-) nits and typos: >> >> 2.3.1: maybe explain "handle-based design" or give a >> reference? (Or maybe just a forward ref to 3.1?) >> >> 2.3.3: It might be worth re-iterating that the term >> "client" in oauth is used differently, e.g. by copying a >> bit of text from the base spec. I can see folks being >> confused by this otherwise. >> >> 3.1: "is digitally signed" - do you mean it has data >> integrity and origin authentication? If MACs are commonly >> used (or maybe authenticated encryption), and not >> necessarily signatures, then saying that would be better. >> >> 3.1.2: typo: s/this mechanisms/this mechanism/ >> >> 3.1.2: maybe s/Expires_In/expires_in/ to match the case in >> the base spec? I think it'd be better not to capitalise >> this in case it finds its way into someone's code. You >> could also use "Expires In" in the title and then say that >> its "expires_in" in the protocol. Might be worth doing >> something generic to call out when you're talking about >> specific things from the protocol, e.g. use a convention >> like ``expires_in'' or "expires_in" consistently and say >> that in the intro. >> >> 3.4: typo: s/the later/the latter/ >> >> 3.4: bullet item 1 isn't really a reason for anything but >> a downside of doing this, at least as written. Maybe this >> needs to be tweaked? >> >> 3.6: expand CSRF on 1st use and maybe give a reference >> CSRF is expanded in 4.4.1.8 which is a good bit later, >> and also in 4.4.2.5 which could presumably be >> shortened a bit by removing the repetition. >> >> 3.7: typo: s/collage associated request/collate associated >> requests/ >> >> 3.7: Maybe give a pointer to the definition of "native >> application" in the base spec (Its section 9 of that.) >> 2nd last para of p13 would be a good place for that. >> >> section 4: maybe s/Security Threat Model/Threat Model/ >> in the section title - what other kind of threat >> model is there? >> >> section 4: I wondered how we know the threat model >> is "comprehensive"? Perhaps "detailed" is better? >> >> 4.2.1: typo: s/Users/users/g unless you mean something >> special? >> >> 4.2.2: typo: s/a understandable/an understandable/ >> >> 4.2.2: "...based on who the client is." is unclear >> and not gramatically nice:-) "...based on the client >> identifier." would seem better. >> >> 4.3.1: typo? s/on transit/in transit/ Or did you >> mean something else? and s/may attempts/may attempt/ >> >> 4.3.3: maybe s/Revelation/Disclosure/ to be a tad >> less biblical:-) >> >> 4.3.3: typo? 1st countermeasure reads oddly and >> refers to a different place than other references >> to TLS - is that correct? >> >> 4.3.3: digest auth is nearly the same as sending >> credentials over the wire, TLS client auth based >> on certificates would be a better example, even >> if its not often done. >> >> 4.3.4: 4.3.2 points to 5.1.4.1.2 but this doesn't. >> Maybe it ought to? >> >> 4.3.6: typo s/an authorization servers/an authorization >> server/ >> >> 4.3.6: 4.3.5 refers to 5.1.4.2.2 wrt entropy. Is there >> a reason to not do that here too? >> >> 4.4: typo? s/tokens endpoint/token endpoint/ ? >> >> 4.4.1.1: typo: s/by different ways/in different ways/ >> >> 4.4.1.1: typo-fix-typo? HTTP has a "Referer" header field, >> but you fixed their typo here - might be better to live >> with the bad spelling, in which case >> s/referrer/referer/g;-) >> >> 4.4.1.1: Is there no better way to reference these >> OASIS docs? More importantly, is there no better (more >> stable) reference than thomasgross.net for the >> PDF you reference? Tidying this up would be good. >> >> 4.4.1.1 and elsewhere: a few times you say "such as >> TLS or SSL," I think it'd be better to just say TLS >> there and do it consistently everwhere. In other >> places (e.g. 4.4.1.5) you say "HTTPS" - again that'd >> be better done consistently. >> >> 4.4.1.1: typo: s/redeem a authorization code/redeem >> an authorizatio code/ >> >> 4.4.1.4: "counterfeit a valid client" reads oddly, >> do you mean "pretend to be a valid client"? If so, >> I think that'd be clearer. >> >> 4.4.1.4: "and to prevent unauthorized access to >> them" - I think you might add "via the oauth >> protocol" there since the AS isn't responsible for >> all possible ways of preventing unauthorized access. >> >> 4.4.1.4: typo: s/not neccesserily indicates/doesn't >> necessarily indicate/ >> >> 4.4.1.4: typo: s/user should be explained the purpose/ >> something better/ :-) >> >> 4.4.1.4: expand/define CAPTCHA on 1st use. Give a >> reference for this too. Especially since you also >> have 5.1.4.2.5, which is maybe the best place for >> the reference. >> >> 4.4.1.4: isn't a PIN code another user authentiation? >> Seems like a bad example of automatic authentication, >> since it isn't automatic if the user has to enter a >> PIN. >> >> 4.4.1.6: Is Facebook a trademark? Maybe better to not >> use that if so? >> >> 4.4.1.7: typo: s/achieve that goal/achieves that goal/ >> >> 4.4.1.7: typo: s/victims resources/victim's resources/ >> >> 4.4.1.7: typo: s/The attackers gains/The attacker gains/ >> >> 4.4.1.7: typo: s/then the target web site/rather than >> the target web site/ >> >> 4.4.1.7: "session fixation" could do with a reference >> or definition, and that might be better earlier in >> this section and not just in the countermeasures >> part. >> >> 4.4.1.7: typo: s/kind of attacks/kind of attack/ >> >> 4.4.1.8: typo: s/not follow untrusted/to not follow >> untrusted/ >> >> 4.4.1.9: maybe add a reference for "iframe"? And >> you say "iFrames" later, better to be consistent. >> >> 4.4.1.9: 1st countermeasure - do you mean end-user >> authorization here or end-user authentication? And >> would it be better to say "system browser" or >> something rather than "external browser"? (I forget >> what phrase you used for that earlier but there >> was something bettter:-) >> >> 4.4.1.9: "javascript framebusting" really needs >> a reference >> >> 4.4.1.10: typo: s/the victims resources/the victim's >> resources/ >> >> 4.4.1.10: typo: s/or split the/or splits the/ >> >> 4.4.1.10: "corresponding form post requests" isn't >> clear to me - does that need rephrasing or is it >> just me? >> >> 4.4.1.10: this is the first mention of cookies, which >> I found surprising, but that's all;-) >> >> 4.4.1.10: the 2nd "ways to achieve this" bullet is >> a bit unclear - which "It" and whose browser? I >> think this could be clearer. >> >> 4.4.1.10: typo: s/as native app/as a native application/ >> >> 4.4.1.10: what does "assume" the threat mean? >> >> 4.4.1.10: typo: s/an user interaction/a user interaction/ >> >> 4.4.1.10: typo: s/CAPTCAs, or/CAPTCHAs/ or else get >> rid of the "or" from the last bullet >> >> 4.4.1.10: typo: s/send out of bound/sent out of band/ >> >> 4.4.1.10: typo: s/instance message/instant message/ >> >> 4.4.1.11: typo? s/directing user(s) browser/directing >> the user's browser/ ? >> >> 4.4.1.11: I don't get the explanation here. Are you >> assuming (but not saying) that generating non-trivial >> entropy is a slow process? (e.g. /dev/random blocking?) >> Its also not clear what "pool" you mean? This probably >> needs a bit of tweaking. >> >> 4.4.1.12: semicomplete.com may not be a sufficiently >> stable reference - can't you find a better one? >> >> 4.4.1.12: typo: s/Defenses such rate limiting/Defenses >> such as rate limiting/ >> >> 4.4.1.12: typo: s/an anonymizing systems/an anonymizing >> system/ >> >> 4.4.1.12: nicest typo yet! s/annoying system/anonymizing >> system/ :-) >> >> 4.4.1.12: typo? maybe s/iframe/iFrame/ again? >> >> 4.4.1.12: 1st reference to "the CSRF token" here? That >> might warrant a reference of some sort? (Maybe to >> a later section?) >> >> 4.4.1.12: Facebook again. >> >> 4.4.1.12: Signing the code seems like a bit of a hack. Do >> you really want to recommend this here? I suspect it'd end >> up different if you actually tried it out aiming for an >> interoperable solution. I'd suggest deleting this, or >> maybe make it less specific, e.g. saying if origin >> authentication for authorization codes could be validated >> by clients, then that'd be a countermeasure, but that >> there's no current spec for that. (And doing that might >> just move the DoS to somewhere else depending how you >> did it.) >> >> 4.4.2: typo: s/and It cannot/and it cannot/ >> >> 4.4.2.1: Is the countermeasure here TLS? If so, better to >> say so. >> >> 4.4.2.2: requests aren't cached are they but rather >> responses? >> >> 4.4.2.3: typo: s/An malicious/A malicious/ >> >> 4.4.2.3: The reference back to 4.4.1.4 isn't very >> clear since a lot of the countermeasures there >> mention authentication. It'd be better to explicitly >> list things here or else if you stick with the >> backwards reference to be more explicit about whic >> exactly apply. >> >> 4.4.2.5: Is this entirely identical to 4.4.1.8? That >> doesn't seem right. If it is, then say so explicitly. >> If not, then say what's different. >> >> 4.4.3: 1st mention of username/password anti-pattern, >> so you could add a reference >> >> 4.4.3: Be good to metion here that passwords are often >> used for>1 service, so this anti-pattern risks whatever >> else is accessible with that credential or an >> algorithmically derivable equivalent (e.g. >> joe@example.com/pwd might easily allow someone to guess >> that the same pwd is used for joe.user@example.net) and >> then another countermeasure is to educate users to >> not use the same pwd for multiple services (hard as >> that is to really do;-) >> >> 4.4.3.4: again digest auth isn't a good example >> here, but client certs are. >> >> 4.4.3.6: What does "Abandon on grant type..." mean? >> If you mean "don't do this" then say that more >> clearly. >> >> 4.6.2: typo: s/transport security measure/transport >> security measures/ or maybe just say TLS >> >> 4.6.2: typo: s/nounces/nonces/ >> >> 4.6.3: 1st countermeasure: maybe s/difficult/infeasible/ >> I don't see why "difficult" guessing is hard enough? >> >> 4.6.4: typo: s/a valid access tokens/a valid access token/ >> >> 4.6.4: Do you mean the IP address in the 2nd >> countermeasure? I'm not sure, esp. given the above. >> >> 4.6.4: typo: s/miss the capabilities/lack the capability/ >> >> 4.6.6: reference to 2616 is broken >> >> 4.6.6: Should you reference httpbis drafts? Just asking, I >> can see arguments for referencing just 2616 or just >> httpbis or both, given that this'll be read for hopefully >> a while after httpbis is done. >> >> 4.6.7: referrer vs. referer again >> >> 4.6.7: What is an appropriat logging configuration? Can >> you give a reference maybe or is it really that well >> known? >> >> 4.6.7: Reloading the target page again? Are you really >> recommending that? >> >> 5.1: typo: s/consideratios/considerations/ >> >> 5.1.3: I think you should note the email notifications >> can be a phishing vector so don't make your emails >> such that lookalike phish messages can easily be >> derived from them. >> >> 5.1.3: Don't you need to say something about getting >> email notifications delivered and not treated as spam? >> Maybe you could recommend dkim here or other ways to >> get better delivery. (Not sure myself, probably best >> to ask someone who operates like this so see if there's >> stuff to be said.) >> >> 5.1.4.1.3: typo: s/not store credential/not store >> credentials/ >> >> 5.1.4.1.4: salted hashes don't prevent offline >> dictionary attacks, they just increase the workload >> >> 5.1.5.1.4: would it be worthwhile recommending that >> different client credentials be used in development >> or integration mode vs. when operational? I've seen >> a bunch of times when programmers were given "live" >> API keys when that could've been avoided. >> >> 5.1.4.1.5: I don't get this. If it was only that >> easy:-) I think you need to say which private keys >> are used here and for what for this section to be >> useful. >> >> 5.1.4.2.1: I think you could note that complex password >> policies can also increase the liklihood that users >> re-use passwords or write them down or store them >> somewhere not so good, if e.g. the entropy required >> over all the user's passwords (dozens usually) is >> too great for long-term memory. >> >> 5.1.5.1: typo: s/Basis of/The basis of/ >> >> 5.1.5.1: typo: s/sensible service/sensitive service/ >> (2nd best typo:-) >> >> 5.1.5.3: typo: s/preciser/more precise/ >> >> 5.1.5.3: typo: s/refreshments/refreshes/ >> >> 5.1.5.4: 2nd bullet is not a threat but a goal >> >> 5.1.5.4: typo: s/redeem a/redeem an/ >> >> 5.1.5.5: what is a "rough" server? Do you mean rogue? >> >> 5.5.5.6: I think you need to clarify what "address" >> means here too. >> >> 5.1.5.9: please clarify if you mean digitally signed >> (asymmetric) or also include MACing here >> >> 5.1.5.10: typo: s/Self-contained/Self-contained tokens/ >> >> 5.1.5.10: s/privacy/confidentiality/ ? >> >> 5.1.5.10: this (typically, I'd guess) requires sharing >> symmetric keys between server nodes, so you should >> say that as its a bunch of work. >> >> 5.1.5.11: I don't get why you want to repeat this >> text (and its error:-) better to refer back to >> the earlier section I think. >> >> 5.1.5.12: Another place where a SAML reference would >> be needed. >> >> 5.1.6: 2nd bullet is not a "measure" but a goal. If >> you had something in mind, it doesn't come out from >> that text. >> >> 5.2.2.2: You say the binding should be protected, but >> don't say how. I think you ought. >> >> 5.2.3: typo: s/sub-sequent/subsequent/ but maybe >> better to delete the word >> >> 5.2.3: 2nd bullet - "trustworthiness" has gotta >> be the wrong word there, what did you mean? >> >> 5.2.3: typo: s/statics/statistics/ >> >> 5.2.3: typo: s/support achieve objectives/achieve these >> objectives/ ? >> >> 5.2.3: typo: s/by hand of an administrator/something >> better/ >> >> 5.2.3.1: "prevents...overestimating" seems wrong, I think >> you mean it reduces the probability of mistakenly treating >> a useless authentication as a good one. (The point is >> that servers don't "overestimate," only people do that.) >> >> 5.2.3.1: "cannot be entirely protected" seems like >> understatement - the reality is any such secret will >> leak out from anything that's any way successful. It >> only protects stuff that *nobody* cares about. >> >> 5.2.3.1: typo: s/trust on/trust/ But I'd rephrase it >> to not use the terms "trust" nor "identity" and then >> it'd be better I think. >> >> 5.2.3.2: typo? s/The authorization may/The authrozation >> server may/ ? Not sure what "issue a cliend id" means >> either. (Same in 5.2.3.3) >> >> 5.2.3.4: typo: s/A authorization server/An authorization >> server/ >> >> 5.2.3.5: what are "validated properties"? >> >> 5.2.3.5: what is the 1st bullet list on p57? there's >> no introductory text? >> >> 5.2.3.5: the "it" in "it only works" in the last >> paragraph isn't clear - which "it" do you mean? >> >> 5.2.3.5: saying discovery "gets involved" seems >> wrong - do you mean "is used"? And what is the >> "that" in "that's no longer feasible"? >> >> 5.2.3.6: typo: s/be unintentionally for/unintentionally >> affect/? >> >> 5.2.3.7: typo: s/to distribute client_secret/to >> distribute a client_secret/ >> >> 5.2.4.1: Is a "security certificate" a public key >> certificate? If so, saying that is better. >> >> 5.2.4.1: the references to 5.7.2.x are wrong and >> look like you're missing some xref's in the xml >> maybe >> >> 5.2.4.2: you said "address" again, so the usual >> question arises :-) >> >> 5.2.4.3: typo: s/in all situation/in situations/ >> (not sure "all" is right so suggest deleting it) >> >> 5.2.4.4: again, be good to say how to protect >> the binding >> >> 5.2.4.5: as for 5.2.4.4 say how binding is done >> >> 5.3.1: typo: s/a associated/an associated/ >> >> 5.3.1: "entirely protected" is (again:-) understatement >> see above for a suggestion >> >> 5.3.1: what does "trust on the client's identity" mean? >> Its not clear anyway >> >> 5.3.3: typo: s/operation systems/operating systems/ >> (enrire 2nd& 3rd paras could do with re-phrasing) >> >> 5.3.4: typo: s/their level/the level/ >> >> 5.3.5: this is too terse - is it really finished? I'd >> say there's a sentence or two missing. >> >> 5.4.2: what does it mean to "encourage resource >> servers" to do something? I guess you mean to encourage >> the people deploying those to pick resource servers >> with that capability and to turn that on. >> >> 5.4.2: not sure if everyone will know what a >> "distinguished name" is, maybe add a reference to >> rfc 5280? >> >> 5.4.2: token-bound secrets would be used to MAC >> the request and not to sign, be better to make that >> clear even if you still call that "signing" here >> (its not really, if we're being pedantic) >> >> 5.4.2: typo: s/This mechanisms/This mechanism/ >> >> 5.4.2 and 5.4.3: I forget - where are the protocol >> mechanisms for this defined? Can you give a reference >> or say that its future stuff if there aren't any >> good ones? >> >> 5.5: typo: s/capable to validate/capable of validating/ >> >> 8.1: Is the base spec really normative? I'd say you're >> fine with that as informative too. >> >> 8.2: there are a bunch of references missing as per >> the questions above >> >> 8.2: is there no better (more stable) reference than >> portablecontacts.net? >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > From bcampbell@pingidentity.com Mon Jun 4 11:17:08 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A8E711E80A5 for ; Mon, 4 Jun 2012 11:17:08 -0700 (PDT) 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=[AWL=-0.001, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=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 yn+Ol9eKGZAO for ; Mon, 4 Jun 2012 11:17:06 -0700 (PDT) Received: from na3sys009aog111.obsmtp.com (na3sys009aog111.obsmtp.com [74.125.149.205]) by ietfa.amsl.com (Postfix) with ESMTP id 15C9711E809F for ; Mon, 4 Jun 2012 11:17:05 -0700 (PDT) Received: from mail-qc0-f173.google.com ([209.85.216.173]) (using TLSv1) by na3sys009aob111.postini.com ([74.125.148.12]) with SMTP ID DSNKT8z7oeTE9GAr01EZ0E7uGcX8LN4agp6j@postini.com; Mon, 04 Jun 2012 11:17:06 PDT Received: by qcsc20 with SMTP id c20so2702456qcs.4 for ; Mon, 04 Jun 2012 11:17:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=1v9xIKWm8yZ+JMHWdYnBK3fzU49affWJQvFlifNApS8=; b=XMpohhtkJ12Aly7UHE372j3Z0ngYZ57ZmpxOJ+To8b8IdEGrXxJft9vfssjzC7k643 Pfn+vwXtgoZQrzmGinVPQZCXVQw5ET4pq8TAmBAyIdEJNNVpLifViJbYxgbmmtH0TeaL 2ejKJItqngJgge/IlUJqqz8hh4qR4NLSStxEy5iqqOSrbPv65It4MRSAsiiYwmTr5gPt 79QVI11J/If7mVdXa1pwoU8Jw2AgD6hDOJQfcsrhQ9BMP3PgQuumGhbDapoVE8PCXcal 1hXFHPwBlmG/4ILs+BhVfZzMdE1HPyn5UEVaU1YudosublIzi7BfoEtgs7GBkimfe/0g c0OA== Received: by 10.224.211.4 with SMTP id gm4mr13948955qab.98.1338833824531; Mon, 04 Jun 2012 11:17:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.226.140 with HTTP; Mon, 4 Jun 2012 11:16:34 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436652634C@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739436652634C@TK5EX14MBXC284.redmond.corp.microsoft.com> From: Brian Campbell Date: Mon, 4 Jun 2012 12:16:34 -0600 Message-ID: To: Mike Jones Content-Type: multipart/alternative; boundary=20cf300fad0d86435704c1a98a65 X-Gm-Message-State: ALoCoQl47LS75MI2SKhZWmSvKl6Hc/pVJ9EFeFweuzzasDzmzfgD6m5j+eP3HDqLWNNC6XUTHtOn Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] ABNF elements for suggested WG review X-BeenThere: oauth@ietf.org X-Mailman-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, 04 Jun 2012 18:17:08 -0000 --20cf300fad0d86435704c1a98a65 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Although what Nat is doing in this post is a little off topic, note that he does have an https URL as a client id which would be disallowed by the ABNF in A.1 below. Excluding ":" in client id definition makes sense when you consider that client ids will often be used as a userid in HTTP Basic but is that too restrictive in general? On Sat, Jun 2, 2012 at 2:10 AM, Mike Jones wro= te: > Dear working group,**** > > ** ** > > It turns out that writing an ABNF for the Core spec pointed out that the > syntax of a number of the OAuth protocol elements had not been previously > defined. (Thanks, Sean, for having us do this!) I took a stab at > specifying appropriate ABNF values for each of the protocol elements, but= I > would request that the working group actively review the choices in my > proposed draft.**** > > ** ** > > For instance, I chose to use the same syntax definitions for username and > password and client_id and client_secret as HTTP Basic used for userid an= d > password. Other choices were possible, such as perhaps limiting client_i= d > and possibly username values to use =93unreserved=94 characters, rather t= han > allowing all characters other than =93:=94 (as HTTP Basic did with userid= ).*** > * > > ** ** > > Please particularly review the syntax definitions for these elements, as = I > had to make choices that went beyond the current specs to provide > unambiguous syntax definitions:**** > > client_id**** > > client_secret**** > > state**** > > code**** > > access_token**** > > username**** > > password**** > > refresh_token**** > > ** ** > > The full proposed ABNF section follows.**** > > ** ** > > -- Mike**** > > ** ** > > Appendix A. Augmented Backus-Naur Form (ABNF) Syntax**** > > ** ** > > This section provides Augmented Backus-Naur Form (ABNF) syntax**** > > descriptions for the elements defined in this specification using the*= * > ** > > notation of [RFC5234]. Elements are presented in the order first**** > > defined.**** > > ** ** > > Some of the definitions that follow use the "unreserved" and "URI"**** > > definitions from [RFC3986], which are:**** > > ** ** > > unreserved =3D ALPHA / DIGIT / "-" / "." / "_" / "~"**** > > URI =3D scheme ":" hier-part [ "?" query ] [ "#" fragment ]**** > > ** ** > > Some of the definitions that follow use the "b64token" syntax below,**= * > * > > which matches the "b64token" syntax defined by HTTP/1.1, Part 7**** > > [I-D.ietf-httpbis-p7-auth]:**** > > ** ** > > b64token =3D 1*( ALPHA / DIGIT /**** > > "-" / "." / "_" / "~" / "+" / "/" ) *"=3D"**** > > ** ** > > A.1. "client_id" Syntax**** > > ** ** > > The "client_id" element is defined in Section 2.3.1:**** > > ** ** > > client-id =3D ***** > > ** ** > > (This matches the "userid" definition in the HTTP Basic**** > > Authentication Scheme [RFC2617].)**** > > ** ** > > A.2. "client_secret" Syntax**** > > ** ** > > The "client_secret" element is defined in Section 2.3.1:**** > > ** ** > > client-secret =3D *TEXT**** > > ** ** > > (This matches the "password" definition in the HTTP Basic**** > > Authentication Scheme [RFC2617].)**** > > ** ** > > A.3. "response_type" Syntax**** > > ** ** > > The "response_type" element is defined in Section 3.1.1 and**** > > Section 8.4:**** > > ** ** > > response-type =3D response-name *( SP response-name )**** > > response-name =3D 1*response-char**** > > response-char =3D "_" / DIGIT / ALPHA**** > > ** ** > > A.4. "scope" Syntax**** > > ** ** > > The "scope" element is defined in Section 3.3:**** > > ** ** > > scope =3D scope-token *( SP scope-token )**** > > scope-token =3D 1*( %x21 / %x23-5B / %x5D-7E )**** > > ** ** > > A.5. "state" Syntax**** > > ** ** > > The "state" element is defined in Section 4.1.1, Section 4.1.2,**** > > Section 4.1.2.1, Section 4.2.1, Section 4.2.2, and Section 4.2.2.1:***= * > > ** ** > > state =3D 1*unreserved**** > > ** ** > > A.6. "redirect_uri" Syntax**** > > ** ** > > The "redirect_uri" element is defined in Section 4.1.1,**** > > Section 4.1.3, and Section 4.2.1:**** > > ** ** > > redirect-uri =3D URI**** > > ** ** > > A.7. "error" Syntax**** > > ** ** > > The "error" element is defined in Section 4.1.2.1, Section 4.2.2.1,***= * > > Section 5.2, Section 7.2, and Section 8.5:**** > > ** ** > > error =3D 1*error-char**** > > error-char =3D %x20-21 / %x23-5B / %x5D-7E**** > > ** ** > > A.8. "error_description" Syntax**** > > ** ** > > The "error_description" element is defined in Section 4.1.2.1,**** > > Section 4.2.2.1, Section 5.2, and Section 7.2:**** > > ** ** > > error-description =3D 1*error-char**** > > error-char =3D %x20-21 / %x23-5B / %x5D-7E**** > > ** ** > > A.9. "error_uri" Syntax**** > > ** ** > > The "error_uri" element is defined in Section 4.1.2.1,**** > > Section 4.2.2.1, Section 5.2, and Section 7.2:**** > > ** ** > > error-uri =3D URI**** > > ** ** > > A.10. "grant_type" Syntax**** > > ** ** > > The "grant_type" element is defined in Section 4.1.3, Section 4.3.2,**= * > * > > Section 4.4.1, Section 6, and Section 4.5:**** > > ** ** > > grant-type =3D grant-name / URI**** > > grant-name =3D 1*name-char**** > > name-char =3D "-" / "." / "_" / DIGIT / ALPHA**** > > ** ** > > A.11. "code" Syntax**** > > ** ** > > The "code" element is defined in Section 4.1.3:**** > > ** ** > > code =3D 1*unreserved**** > > ** ** > > A.12. "access_token" Syntax**** > > ** ** > > The "access_token" element is defined in Section 4.2.2 and**** > > Section 5.1:**** > > ** ** > > access-token =3D b64token**** > > ** ** > > A.13. "token_type" Syntax**** > > ** ** > > The "token_type" element is defined in Section 4.2.2, Section 5.1,**** > > and Section 8.1:**** > > ** ** > > token-type =3D type-name / URI**** > > type-name =3D 1*name-char**** > > name-char =3D "-" / "." / "_" / DIGIT / ALPHA**** > > ** ** > > A.14. "expires_in" Syntax**** > > ** ** > > The "expires_in" element is defined in Section 4.2.2 and Section 5.1:*= * > ** > > ** ** > > expires-in =3D 1*DIGIT**** > > ** ** > > A.15. "username" Syntax**** > > ** ** > > The "username" element is defined in Section 4.3.2:**** > > ** ** > > username =3D ***** > > ** ** > > (This matches the "userid" definition in the HTTP Basic**** > > Authentication Scheme [RFC2617].)**** > > ** ** > > A.16. "password" Syntax**** > > ** ** > > The "password" element is defined in Section 4.3.2:**** > > ** ** > > password =3D *TEXT**** > > ** ** > > (This matches the "password" definition in the HTTP Basic**** > > Authentication Scheme [RFC2617].)**** > > ** ** > > A.17. "refresh_token" Syntax**** > > ** ** > > The "refresh_token" element is defined in Section 5.1 and Section 6:**= * > * > > ** ** > > refresh-token =3D b64token**** > > ** ** > > A.18. Endpoint Parameter Syntax**** > > ** ** > > The syntax for new endpoint parameters is defined in Section 8.2:**** > > ** ** > > param-name =3D 1*name-char**** > > name-char =3D "-" / "." / "_" / DIGIT / ALPHA**** > > ** ** > > ** ** > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --20cf300fad0d86435704c1a98a65 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Although what Nat is doing in this post is a little off topic, note that he= does have an https URL as a client id which would be disallowed by the ABN= F in A.1 below. Excluding ":" in client id definition makes sens= e when you consider that client ids will often be used as a userid in HTTP = Basic but is that too restrictive in general?

On Sat, Jun 2, 2012 at 2:10 AM, Mike Jones <= span dir=3D"ltr"><Michael.Jones@microsoft.com> wrote:

Dear working group,

=A0

It turns out that writing an ABNF for the Core spec = pointed out that the syntax of a number of the OAuth protocol elements had = not been previously defined.=A0 (Thanks, Sean, for having us do this!)=A0 I= took a stab at specifying appropriate ABNF values for each of the protocol elements, but I would request that th= e working group actively review the choices in my proposed draft.=

=A0

For instance, I chose to use the same syntax definit= ions for username and password and client_id and client_secret as HTTP Basi= c used for userid and password.=A0 Other choices were possible, such as per= haps limiting client_id and possibly username values to use =93unreserved=94 characters, rather than allowing a= ll characters other than =93:=94 (as HTTP Basic did with userid).=

=A0

Please particularly review the syntax definitions fo= r these elements, as I had to make choices that went beyond the current spe= cs to provide unambiguous syntax definitions:

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 client_id=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 client_se= cret

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 state<= /u>

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 code

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 access_to= ken

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 username<= u>

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 password<= u>

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 refresh_t= oken

=A0

The full proposed ABNF section follows.

=A0

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

Appendix A.=A0 Augmented Backus-Naur Form (ABNF) Syntax=

=A0

=A0=A0 This section provides Augmented Backus-Naur Form (A= BNF) syntax

=A0=A0 descriptions for the elements defined in this speci= fication using the

=A0=A0 notation of [RFC5234].=A0 Elements are presented in= the order first

=A0=A0 defined.

=A0

=A0=A0 Some of the definitions that follow use the "u= nreserved" and "URI"

=A0=A0 definitions from [RFC3986], which are:

=A0

=A0=A0 unreserved =3D ALPHA / DIGIT / "-" / &quo= t;." / "_" / "~"

=A0=A0 URI=A0=A0=A0=A0=A0=A0=A0 =3D scheme ":" h= ier-part [ "?" query ] [ "#" fragment ]

=A0

=A0=A0 Some of the definitions that follow use the "b= 64token" syntax below,

=A0=A0 which matches the "b64token" syntax defin= ed by HTTP/1.1, Part 7

=A0=A0 [I-D.ietf-httpbis-p7-auth]:

=A0

=A0=A0 b64token=A0=A0 =3D 1*( ALPHA / DIGIT /

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = "-" / "." / "_" / "~" / "+&quo= t; / "/" ) *"=3D"

=A0

A.1.=A0 "client_id" Syntax<= /p>

=A0

=A0=A0 The "client_id" element is defined in Sec= tion 2.3.1:

=A0

=A0=A0 client-id=A0=A0=A0=A0 =3D *<TEXT excluding "= ;:">

=A0

=A0=A0 (This matches the "userid" definition in = the HTTP Basic

=A0=A0 Authentication Scheme [RFC2617].)

=A0

A.2.=A0 "client_secret" Syntax

=A0

=A0=A0 The "client_secret" element is defined in= Section 2.3.1:

=A0

=A0=A0 client-secret =3D *TEXT

=A0

=A0=A0 (This matches the "password" definition i= n the HTTP Basic

=A0=A0 Authentication Scheme [RFC2617].)

=A0

A.3.=A0 "response_type" Syntax

=A0

=A0=A0 The "response_type" element is defined in= Section 3.1.1 and

=A0=A0 Section 8.4:

=A0

=A0=A0 response-type =3D response-name *( SP response-name= )

=A0=A0 response-name =3D 1*response-char

=A0=A0 response-char =3D "_" / DIGIT / ALPHA<= /u>

=A0

A.4.=A0 "scope" Syntax

=A0

=A0=A0 The "scope" element is defined in Section= 3.3:

=A0

=A0=A0 scope=A0=A0=A0=A0=A0=A0 =3D scope-token *( SP scope= -token )

=A0=A0 scope-token =3D 1*( %x21 / %x23-5B / %x5D-7E )

=A0

A.5.=A0 "state" Syntax

=A0

=A0=A0 The "state" element is defined in Section= 4.1.1, Section 4.1.2,

=A0=A0 Section 4.1.2.1, Section 4.2.1, Section 4.2.2, and = Section 4.2.2.1:=

=A0

=A0=A0 state=A0=A0=A0=A0=A0 =3D 1*unreserved=

=A0

A.6.=A0 "redirect_uri" Syntax

=A0

=A0=A0 The "redirect_uri" element is defined in = Section 4.1.1,

=A0=A0 Section 4.1.3, and Section 4.2.1:

=A0

=A0=A0 redirect-uri=A0=A0=A0=A0=A0 =3D URI

=A0

A.7.=A0 "error" Syntax

=A0

=A0=A0 The "error" element is defined in Section= 4.1.2.1, Section 4.2.2.1,

=A0=A0 Section 5.2, Section 7.2, and Section 8.5:

=A0

=A0=A0 error=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 1*err= or-char

=A0=A0 error-char=A0=A0=A0=A0=A0=A0=A0 =3D %x20-21 / %x23-= 5B / %x5D-7E

=A0

A.8.=A0 "error_description" Syntax=

=A0

=A0=A0 The "error_description" element is define= d in Section 4.1.2.1,

=A0=A0 Section 4.2.2.1, Section 5.2, and Section 7.2:

=A0

=A0=A0 error-description =3D 1*error-char

=A0=A0 error-char=A0=A0=A0=A0=A0=A0=A0 =3D %x20-21 / %x23-= 5B / %x5D-7E

=A0

A.9.=A0 "error_uri" Syntax<= /p>

=A0

=A0=A0 The "error_uri" element is defined in Sec= tion 4.1.2.1,

=A0=A0 Section 4.2.2.1, Section 5.2, and Section 7.2:

=A0

=A0=A0 error-uri=A0=A0=A0=A0=A0=A0=A0=A0 =3D URI=

=A0

A.10.=A0 "grant_type" Syntax

=A0

=A0=A0 The "grant_type" element is defined in Se= ction 4.1.3, Section 4.3.2,

=A0=A0 Section 4.4.1, Section 6, and Section 4.5:

=A0

=A0=A0 grant-type =3D grant-name / URI

=A0=A0 grant-name =3D 1*name-char

=A0=A0 name-char=A0 =3D "-" / "." / &q= uot;_" / DIGIT / ALPHA

=A0

A.11.=A0 "code" Syntax

=A0

=A0=A0 The "code" element is defined in Section = 4.1.3:

=A0

=A0=A0 code=A0=A0=A0=A0=A0=A0 =3D 1*unreserved

=A0

A.12.=A0 "access_token" Syntax

=A0

=A0=A0 The "access_token" element is defined in = Section 4.2.2 and

=A0=A0 Section 5.1:

=A0

=A0=A0 access-token =3D b64token

=A0

A.13.=A0 "token_type" Syntax

=A0

=A0=A0 The "token_type" element is defined in Se= ction 4.2.2, Section 5.1,

=A0=A0 and Section 8.1:

=A0

=A0=A0 token-type =3D type-name / URI=

=A0=A0 type-name=A0 =3D 1*name-char

=A0=A0 name-char=A0 =3D "-" / "." / &q= uot;_" / DIGIT / ALPHA

=A0

A.14.=A0 "expires_in" Syntax

=A0

=A0=A0 The "expires_in" element is defined in Se= ction 4.2.2 and Section 5.1:

=A0

=A0=A0 expires-in =3D 1*DIGIT

=A0

A.15.=A0 "username" Syntax<= /p>

=A0

=A0=A0 The "username" element is defined in Sect= ion 4.3.2:

=A0

=A0=A0 username =3D *<TEXT excluding ":"><= u>

=A0

=A0=A0 (This matches the "userid" definition in = the HTTP Basic

=A0=A0 Authentication Scheme [RFC2617].)

=A0

A.16.=A0 "password" Syntax<= /p>

=A0

=A0=A0 The "password" element is defined in Sect= ion 4.3.2:

=A0

=A0=A0 password =3D *TEXT

=A0

=A0=A0 (This matches the "password" definition i= n the HTTP Basic

=A0=A0 Authentication Scheme [RFC2617].)

=A0

A.17.=A0 "refresh_token" Syntax

=A0

=A0=A0 The "refresh_token" element is defined in= Section 5.1 and Section 6:

=A0

=A0=A0 refresh-token =3D b64token

=A0

A.18.=A0 Endpoint Parameter Syntax

=A0

=A0=A0 The syntax for new endpoint parameters is defined i= n Section 8.2:

=A0

=A0=A0 param-name =3D 1*name-char

=A0=A0 name-char=A0 =3D "-" / "." / &q= uot;_" / DIGIT / ALPHA

=A0

=A0


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


--20cf300fad0d86435704c1a98a65-- From eran@hueniverse.com Mon Jun 4 12:16:48 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 240DA11E80C2 for ; Mon, 4 Jun 2012 12:16:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 kHd-XPJbtvdP for ; Mon, 4 Jun 2012 12:16:44 -0700 (PDT) Received: from p3plex2out03.prod.phx3.secureserver.net (p3plex2out03.prod.phx3.secureserver.net [184.168.131.16]) by ietfa.amsl.com (Postfix) with ESMTP id B3D7111E80BC for ; Mon, 4 Jun 2012 12:16:44 -0700 (PDT) Received: from P3PWEX2HT002.ex2.secureserver.net ([184.168.131.10]) by p3plex2out03.prod.phx3.secureserver.net with bizsmtp id JKGj1j0090Dcg9U01KGjsT; Mon, 04 Jun 2012 12:16:43 -0700 Received: from P3PWEX2MB008.ex2.secureserver.net ([169.254.8.66]) by P3PWEX2HT002.ex2.secureserver.net ([184.168.131.10]) with mapi id 14.02.0247.003; Mon, 4 Jun 2012 12:16:43 -0700 From: Eran Hammer To: Mike Jones , "oauth@ietf.org" Thread-Topic: ABNF elements for suggested WG review Thread-Index: Ac1Alx0u1VneJZSBR8aFxCHOlLRpzQB70KSw Date: Mon, 4 Jun 2012 19:16:42 +0000 Message-ID: <0CBAEB56DDB3A140BA8E8C124C04ECA20105F565@P3PWEX2MB008.ex2.secureserver.net> References: <4E1F6AAD24975D4BA5B16804296739436652634C@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436652634C@TK5EX14MBXC284.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.74.213.174] Content-Type: multipart/alternative; boundary="_000_0CBAEB56DDB3A140BA8E8C124C04ECA20105F565P3PWEX2MB008ex2_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] ABNF elements for suggested WG review X-BeenThere: oauth@ietf.org X-Mailman-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, 04 Jun 2012 19:16:48 -0000 --_000_0CBAEB56DDB3A140BA8E8C124C04ECA20105F565P3PWEX2MB008ex2_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The ABNF must reflect the existing draft, not invent new restrictions. The = only field we had consensus for applying new restrictions on is error (and = the related ones from bearer). That's it. Please have the proposed ABNF ref= lect the unrestricted nature of all values not explicitly defined otherwise= . EH From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of M= ike Jones Sent: Saturday, June 02, 2012 1:10 AM To: oauth@ietf.org Subject: [OAUTH-WG] ABNF elements for suggested WG review Dear working group, It turns out that writing an ABNF for the Core spec pointed out that the sy= ntax of a number of the OAuth protocol elements had not been previously def= ined. (Thanks, Sean, for having us do this!) I took a stab at specifying = appropriate ABNF values for each of the protocol elements, but I would requ= est that the working group actively review the choices in my proposed draft= . For instance, I chose to use the same syntax definitions for username and p= assword and client_id and client_secret as HTTP Basic used for userid and p= assword. Other choices were possible, such as perhaps limiting client_id a= nd possibly username values to use "unreserved" characters, rather than all= owing all characters other than ":" (as HTTP Basic did with userid). Please particularly review the syntax definitions for these elements, as I = had to make choices that went beyond the current specs to provide unambiguo= us syntax definitions: client_id client_secret state code access_token username password refresh_token The full proposed ABNF section follows. -- Mike Appendix A. Augmented Backus-Naur Form (ABNF) Syntax This section provides Augmented Backus-Naur Form (ABNF) syntax descriptions for the elements defined in this specification using the notation of [RFC5234]. Elements are presented in the order first defined. Some of the definitions that follow use the "unreserved" and "URI" definitions from [RFC3986], which are: unreserved =3D ALPHA / DIGIT / "-" / "." / "_" / "~" URI =3D scheme ":" hier-part [ "?" query ] [ "#" fragment ] Some of the definitions that follow use the "b64token" syntax below, which matches the "b64token" syntax defined by HTTP/1.1, Part 7 [I-D.ietf-httpbis-p7-auth]: b64token =3D 1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" ) *"=3D" A.1. "client_id" Syntax The "client_id" element is defined in Section 2.3.1: client-id =3D * (This matches the "userid" definition in the HTTP Basic Authentication Scheme [RFC2617].) A.2. "client_secret" Syntax The "client_secret" element is defined in Section 2.3.1: client-secret =3D *TEXT (This matches the "password" definition in the HTTP Basic Authentication Scheme [RFC2617].) A.3. "response_type" Syntax The "response_type" element is defined in Section 3.1.1 and Section 8.4: response-type =3D response-name *( SP response-name ) response-name =3D 1*response-char response-char =3D "_" / DIGIT / ALPHA A.4. "scope" Syntax The "scope" element is defined in Section 3.3: scope =3D scope-token *( SP scope-token ) scope-token =3D 1*( %x21 / %x23-5B / %x5D-7E ) A.5. "state" Syntax The "state" element is defined in Section 4.1.1, Section 4.1.2, Section 4.1.2.1, Section 4.2.1, Section 4.2.2, and Section 4.2.2.1: state =3D 1*unreserved A.6. "redirect_uri" Syntax The "redirect_uri" element is defined in Section 4.1.1, Section 4.1.3, and Section 4.2.1: redirect-uri =3D URI A.7. "error" Syntax The "error" element is defined in Section 4.1.2.1, Section 4.2.2.1, Section 5.2, Section 7.2, and Section 8.5: error =3D 1*error-char error-char =3D %x20-21 / %x23-5B / %x5D-7E A.8. "error_description" Syntax The "error_description" element is defined in Section 4.1.2.1, Section 4.2.2.1, Section 5.2, and Section 7.2: error-description =3D 1*error-char error-char =3D %x20-21 / %x23-5B / %x5D-7E A.9. "error_uri" Syntax The "error_uri" element is defined in Section 4.1.2.1, Section 4.2.2.1, Section 5.2, and Section 7.2: error-uri =3D URI A.10. "grant_type" Syntax The "grant_type" element is defined in Section 4.1.3, Section 4.3.2, Section 4.4.1, Section 6, and Section 4.5: grant-type =3D grant-name / URI grant-name =3D 1*name-char name-char =3D "-" / "." / "_" / DIGIT / ALPHA A.11. "code" Syntax The "code" element is defined in Section 4.1.3: code =3D 1*unreserved A.12. "access_token" Syntax The "access_token" element is defined in Section 4.2.2 and Section 5.1: access-token =3D b64token A.13. "token_type" Syntax The "token_type" element is defined in Section 4.2.2, Section 5.1, and Section 8.1: token-type =3D type-name / URI type-name =3D 1*name-char name-char =3D "-" / "." / "_" / DIGIT / ALPHA A.14. "expires_in" Syntax The "expires_in" element is defined in Section 4.2.2 and Section 5.1: expires-in =3D 1*DIGIT A.15. "username" Syntax The "username" element is defined in Section 4.3.2: username =3D * (This matches the "userid" definition in the HTTP Basic Authentication Scheme [RFC2617].) A.16. "password" Syntax The "password" element is defined in Section 4.3.2: password =3D *TEXT (This matches the "password" definition in the HTTP Basic Authentication Scheme [RFC2617].) A.17. "refresh_token" Syntax The "refresh_token" element is defined in Section 5.1 and Section 6: refresh-token =3D b64token A.18. Endpoint Parameter Syntax The syntax for new endpoint parameters is defined in Section 8.2: param-name =3D 1*name-char name-char =3D "-" / "." / "_" / DIGIT / ALPHA --_000_0CBAEB56DDB3A140BA8E8C124C04ECA20105F565P3PWEX2MB008ex2_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The ABNF must reflect = the existing draft, not invent new restrictions. The only field we had cons= ensus for applying new restrictions on is error (and the related ones from = bearer). That’s it. Please have the proposed ABNF reflect the unrestricted nature of all values not explicitly= defined otherwise.

 

EH

 

From: oauth-bo= unces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Saturday, June 02, 2012 1:10 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] ABNF elements for suggested WG review=

 

Dear working group,

 

It turns out that writing an ABNF for the Core spec = pointed out that the syntax of a number of the OAuth protocol elements had = not been previously defined.  (Thanks, Sean, for having us do this!)&n= bsp; I took a stab at specifying appropriate ABNF values for each of the protocol elements, but I would request that th= e working group actively review the choices in my proposed draft.

 

For instance, I chose to use the same syntax definit= ions for username and password and client_id and client_secret as HTTP Basi= c used for userid and password.  Other choices were possible, such as = perhaps limiting client_id and possibly username values to use “unreserved” characters, rather than al= lowing all characters other than “:” (as HTTP Basic did with us= erid).

 

Please particularly review the syntax definitions fo= r these elements, as I had to make choices that went beyond the current spe= cs to provide unambiguous syntax definitions:

        &nbs= p;      client_id

        &nbs= p;      client_secret

        &nbs= p;      state

        &nbs= p;      code

        &nbs= p;      access_token

        &nbs= p;      username

        &nbs= p;      password

        &nbs= p;      refresh_token

 

The full proposed ABNF section follows.

 

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

 

Appendix A.  Augmented Backus-Naur Form (ABNF) Syntax=

 

   This section provides Augmented Backus-Naur F= orm (ABNF) syntax

   descriptions for the elements defined in this= specification using the

   notation of [RFC5234].  Elements are pre= sented in the order first

   defined.

 

   Some of the definitions that follow use the &= quot;unreserved" and "URI"

   definitions from [RFC3986], which are:

 

   unreserved =3D ALPHA / DIGIT / "-" = / "." / "_" / "~"

   URI       = =3D scheme ":" hier-part [ "?" query ] [ "#"= fragment ]

 

   Some of the definitions that follow use the &= quot;b64token" syntax below,

   which matches the "b64token" syntax= defined by HTTP/1.1, Part 7

   [I-D.ietf-httpbis-p7-auth]:=

 

   b64token   =3D 1*( ALPHA / DIGIT /<= o:p>

         &nbs= p;          "-" / &q= uot;." / "_" / "~" / "+" / "/&q= uot; ) *"=3D"

 

A.1.  "client_id" Syntax<= /p>

 

   The "client_id" element is defined = in Section 2.3.1:

 

   client-id     =3D *<TE= XT excluding ":">

 

   (This matches the "userid" definiti= on in the HTTP Basic

   Authentication Scheme [RFC2617].)<= /span>

 

A.2.  "client_secret" Syntax

 

   The "client_secret" element is defi= ned in Section 2.3.1:

 

   client-secret =3D *TEXT

 

   (This matches the "password" defini= tion in the HTTP Basic

   Authentication Scheme [RFC2617].)<= /span>

 

A.3.  "response_type" Syntax

 

   The "response_type" element is defi= ned in Section 3.1.1 and

   Section 8.4:

 

   response-type =3D response-name *( SP respons= e-name )

   response-name =3D 1*response-char<= /span>

   response-char =3D "_" / DIGIT / ALP= HA

 

A.4.  "scope" Syntax

 

   The "scope" element is defined in S= ection 3.3:

 

   scope       =3D= scope-token *( SP scope-token )

   scope-token =3D 1*( %x21 / %x23-5B / %x5D-7E = )

 

A.5.  "state" Syntax

 

   The "state" element is defined in S= ection 4.1.1, Section 4.1.2,

   Section 4.1.2.1, Section 4.2.1, Section 4.2.2= , and Section 4.2.2.1:

 

   state      =3D 1*unr= eserved

 

A.6.  "redirect_uri" Syntax

 

   The "redirect_uri" element is defin= ed in Section 4.1.1,

   Section 4.1.3, and Section 4.2.1:<= /span>

 

   redirect-uri      = =3D URI

 

A.7.  "error" Syntax

 

   The "error" element is defined in S= ection 4.1.2.1, Section 4.2.2.1,

   Section 5.2, Section 7.2, and Section 8.5:

 

   error      &nbs= p;      =3D 1*error-char

   error-char      = ;  =3D %x20-21 / %x23-5B / %x5D-7E

 

A.8.  "error_description" Syntax=

 

   The "error_description" element is = defined in Section 4.1.2.1,

   Section 4.2.2.1, Section 5.2, and Section 7.2= :

 

   error-description =3D 1*error-char=

   error-char      = ;  =3D %x20-21 / %x23-5B / %x5D-7E

 

A.9.  "error_uri" Syntax<= /p>

 

   The "error_uri" element is defined = in Section 4.1.2.1,

   Section 4.2.2.1, Section 5.2, and Section 7.2= :

 

   error-uri      =    =3D URI

 

A.10.  "grant_type" Syntax

 

   The "grant_type" element is defined= in Section 4.1.3, Section 4.3.2,

   Section 4.4.1, Section 6, and Section 4.5:

 

   grant-type =3D grant-name / URI

   grant-name =3D 1*name-char<= /p>

   name-char  =3D "-" / ".&q= uot; / "_" / DIGIT / ALPHA

 

A.11.  "code" Syntax

 

   The "code" element is defined in Se= ction 4.1.3:

 

   code       =3D = 1*unreserved

 

A.12.  "access_token" Syntax

 

   The "access_token" element is defin= ed in Section 4.2.2 and

   Section 5.1:

 

   access-token =3D b64token

 

A.13.  "token_type" Syntax

 

   The "token_type" element is defined= in Section 4.2.2, Section 5.1,

   and Section 8.1:

 

   token-type =3D type-name / URI

   type-name  =3D 1*name-char

   name-char  =3D "-" / ".&q= uot; / "_" / DIGIT / ALPHA

 

A.14.  "expires_in" Syntax

 

   The "expires_in" element is defined= in Section 4.2.2 and Section 5.1:

 

   expires-in =3D 1*DIGIT

 

A.15.  "username" Syntax<= /p>

 

   The "username" element is defined i= n Section 4.3.2:

 

   username =3D *<TEXT excluding ":"= ;>

 

   (This matches the "userid" definiti= on in the HTTP Basic

   Authentication Scheme [RFC2617].)<= /span>

 

A.16.  "password" Syntax<= /p>

 

   The "password" element is defined i= n Section 4.3.2:

 

   password =3D *TEXT

 

   (This matches the "password" defini= tion in the HTTP Basic

   Authentication Scheme [RFC2617].)<= /span>

 

A.17.  "refresh_token" Syntax

 

   The "refresh_token" element is defi= ned in Section 5.1 and Section 6:

 

   refresh-token =3D b64token<= /p>

 

A.18.  Endpoint Parameter Syntax

 

   The syntax for new endpoint parameters is def= ined in Section 8.2:

 

   param-name =3D 1*name-char<= /p>

   name-char  =3D "-" / ".&q= uot; / "_" / DIGIT / ALPHA

 

 

--_000_0CBAEB56DDB3A140BA8E8C124C04ECA20105F565P3PWEX2MB008ex2_-- From jricher@mitre.org Mon Jun 4 12:32:54 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B43C311E80E8 for ; Mon, 4 Jun 2012 12:32:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 4c-O47297vUO for ; Mon, 4 Jun 2012 12:32:52 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 9188711E80CD for ; Mon, 4 Jun 2012 12:32:51 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 0276F21B154F for ; Mon, 4 Jun 2012 15:32:49 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id BAC6821B1531 for ; Mon, 4 Jun 2012 15:32:48 -0400 (EDT) Received: from [129.83.50.12] (129.83.31.51) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server (TLS) id 14.2.283.3; Mon, 4 Jun 2012 15:32:48 -0400 Message-ID: <4FCD0D5C.4020304@mitre.org> Date: Mon, 4 Jun 2012 15:32:44 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: References: <4E1F6AAD24975D4BA5B16804296739436652634C@TK5EX14MBXC284.redmond.corp.microsoft.com> <0CBAEB56DDB3A140BA8E8C124C04ECA20105F565@P3PWEX2MB008.ex2.secureserver.net> In-Reply-To: <0CBAEB56DDB3A140BA8E8C124C04ECA20105F565@P3PWEX2MB008.ex2.secureserver.net> Content-Type: multipart/alternative; boundary="------------010903020802070605060602" X-Originating-IP: [129.83.31.51] Subject: Re: [OAUTH-WG] ABNF elements for suggested WG review X-BeenThere: oauth@ietf.org X-Mailman-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, 04 Jun 2012 19:32:54 -0000 --------------010903020802070605060602 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Agreed with Eran, there shouldn't be restrictions on most of these fields. Though it should address Julian's request of how do you define encoding on these fields explicitly. -- Justin On 06/04/2012 03:16 PM, Eran Hammer wrote: > > The ABNF must reflect the existing draft, not invent new restrictions. > The only field we had consensus for applying new restrictions on is > error (and the related ones from bearer). That's it. Please have the > proposed ABNF reflect the unrestricted nature of all values not > explicitly defined otherwise. > > EH > > *From:*oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On > Behalf Of *Mike Jones > *Sent:* Saturday, June 02, 2012 1:10 AM > *To:* oauth@ietf.org > *Subject:* [OAUTH-WG] ABNF elements for suggested WG review > > Dear working group, > > It turns out that writing an ABNF for the Core spec pointed out that > the syntax of a number of the OAuth protocol elements had not been > previously defined. (Thanks, Sean, for having us do this!) I took a > stab at specifying appropriate ABNF values for each of the protocol > elements, but I would request that the working group actively review > the choices in my proposed draft. > > For instance, I chose to use the same syntax definitions for username > and password and client_id and client_secret as HTTP Basic used for > userid and password. Other choices were possible, such as perhaps > limiting client_id and possibly username values to use "unreserved" > characters, rather than allowing all characters other than ":" (as > HTTP Basic did with userid). > > Please particularly review the syntax definitions for these elements, > as I had to make choices that went beyond the current specs to provide > unambiguous syntax definitions: > > client_id > > client_secret > > state > > code > > access_token > > username > > password > > refresh_token > > The full proposed ABNF section follows. > > -- Mike > > Appendix A. Augmented Backus-Naur Form (ABNF) Syntax > > This section provides Augmented Backus-Naur Form (ABNF) syntax > > descriptions for the elements defined in this specification using the > > notation of [RFC5234]. Elements are presented in the order first > > defined. > > Some of the definitions that follow use the "unreserved" and "URI" > > definitions from [RFC3986], which are: > > unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" > > URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ] > > Some of the definitions that follow use the "b64token" syntax below, > > which matches the "b64token" syntax defined by HTTP/1.1, Part 7 > > [I-D.ietf-httpbis-p7-auth]: > > b64token = 1*( ALPHA / DIGIT / > > "-" / "." / "_" / "~" / "+" / "/" ) *"=" > > A.1. "client_id" Syntax > > The "client_id" element is defined in Section 2.3.1: > > client-id = * > > (This matches the "userid" definition in the HTTP Basic > > Authentication Scheme [RFC2617].) > > A.2. "client_secret" Syntax > > The "client_secret" element is defined in Section 2.3.1: > > client-secret = *TEXT > > (This matches the "password" definition in the HTTP Basic > > Authentication Scheme [RFC2617].) > > A.3. "response_type" Syntax > > The "response_type" element is defined in Section 3.1.1 and > > Section 8.4: > > response-type = response-name *( SP response-name ) > > response-name = 1*response-char > > response-char = "_" / DIGIT / ALPHA > > A.4. "scope" Syntax > > The "scope" element is defined in Section 3.3: > > scope = scope-token *( SP scope-token ) > > scope-token = 1*( %x21 / %x23-5B / %x5D-7E ) > > A.5. "state" Syntax > > The "state" element is defined in Section 4.1.1, Section 4.1.2, > > Section 4.1.2.1, Section 4.2.1, Section 4.2.2, and Section 4.2.2.1: > > state = 1*unreserved > > A.6. "redirect_uri" Syntax > > The "redirect_uri" element is defined in Section 4.1.1, > > Section 4.1.3, and Section 4.2.1: > > redirect-uri = URI > > A.7. "error" Syntax > > The "error" element is defined in Section 4.1.2.1, Section 4.2.2.1, > > Section 5.2, Section 7.2, and Section 8.5: > > error = 1*error-char > > error-char = %x20-21 / %x23-5B / %x5D-7E > > A.8. "error_description" Syntax > > The "error_description" element is defined in Section 4.1.2.1, > > Section 4.2.2.1, Section 5.2, and Section 7.2: > > error-description = 1*error-char > > error-char = %x20-21 / %x23-5B / %x5D-7E > > A.9. "error_uri" Syntax > > The "error_uri" element is defined in Section 4.1.2.1, > > Section 4.2.2.1, Section 5.2, and Section 7.2: > > error-uri = URI > > A.10. "grant_type" Syntax > > The "grant_type" element is defined in Section 4.1.3, Section 4.3.2, > > Section 4.4.1, Section 6, and Section 4.5: > > grant-type = grant-name / URI > > grant-name = 1*name-char > > name-char = "-" / "." / "_" / DIGIT / ALPHA > > A.11. "code" Syntax > > The "code" element is defined in Section 4.1.3: > > code = 1*unreserved > > A.12. "access_token" Syntax > > The "access_token" element is defined in Section 4.2.2 and > > Section 5.1: > > access-token = b64token > > A.13. "token_type" Syntax > > The "token_type" element is defined in Section 4.2.2, Section 5.1, > > and Section 8.1: > > token-type = type-name / URI > > type-name = 1*name-char > > name-char = "-" / "." / "_" / DIGIT / ALPHA > > A.14. "expires_in" Syntax > > The "expires_in" element is defined in Section 4.2.2 and Section 5.1: > > expires-in = 1*DIGIT > > A.15. "username" Syntax > > The "username" element is defined in Section 4.3.2: > > username = * > > (This matches the "userid" definition in the HTTP Basic > > Authentication Scheme [RFC2617].) > > A.16. "password" Syntax > > The "password" element is defined in Section 4.3.2: > > password = *TEXT > > (This matches the "password" definition in the HTTP Basic > > Authentication Scheme [RFC2617].) > > A.17. "refresh_token" Syntax > > The "refresh_token" element is defined in Section 5.1 and Section 6: > > refresh-token = b64token > > A.18. Endpoint Parameter Syntax > > The syntax for new endpoint parameters is defined in Section 8.2: > > param-name = 1*name-char > > name-char = "-" / "." / "_" / DIGIT / ALPHA > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------010903020802070605060602 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Agreed with Eran, there shouldn't be restrictions on most of these fields. Though it should address Julian's request of how do you define encoding on these fields explicitly.

 -- Justin

On 06/04/2012 03:16 PM, Eran Hammer wrote:

The ABNF must reflect the existing draft, not invent new restrictions. The only field we had consensus for applying new restrictions on is error (and the related ones from bearer). That’s it. Please have the proposed ABNF reflect the unrestricted nature of all values not explicitly defined otherwise.

 

EH

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Saturday, June 02, 2012 1:10 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] ABNF elements for suggested WG review

 

Dear working group,

 

It turns out that writing an ABNF for the Core spec pointed out that the syntax of a number of the OAuth protocol elements had not been previously defined.  (Thanks, Sean, for having us do this!)  I took a stab at specifying appropriate ABNF values for each of the protocol elements, but I would request that the working group actively review the choices in my proposed draft.

 

For instance, I chose to use the same syntax definitions for username and password and client_id and client_secret as HTTP Basic used for userid and password.  Other choices were possible, such as perhaps limiting client_id and possibly username values to use “unreserved” characters, rather than allowing all characters other than “:” (as HTTP Basic did with userid).

 

Please particularly review the syntax definitions for these elements, as I had to make choices that went beyond the current specs to provide unambiguous syntax definitions:

               client_id

               client_secret

               state

               code

               access_token

               username

               password

               refresh_token

 

The full proposed ABNF section follows.

 

                                                            -- Mike

 

Appendix A.  Augmented Backus-Naur Form (ABNF) Syntax

 

   This section provides Augmented Backus-Naur Form (ABNF) syntax

   descriptions for the elements defined in this specification using the

   notation of [RFC5234].  Elements are presented in the order first

   defined.

 

   Some of the definitions that follow use the "unreserved" and "URI"

   definitions from [RFC3986], which are:

 

   unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"

   URI        = scheme ":" hier-part [ "?" query ] [ "#" fragment ]

 

   Some of the definitions that follow use the "b64token" syntax below,

   which matches the "b64token" syntax defined by HTTP/1.1, Part 7

   [I-D.ietf-httpbis-p7-auth]:

 

   b64token   = 1*( ALPHA / DIGIT /

                    "-" / "." / "_" / "~" / "+" / "/" ) *"="

 

A.1.  "client_id" Syntax

 

   The "client_id" element is defined in Section 2.3.1:

 

   client-id     = *<TEXT excluding ":">

 

   (This matches the "userid" definition in the HTTP Basic

   Authentication Scheme [RFC2617].)

 

A.2.  "client_secret" Syntax

 

   The "client_secret" element is defined in Section 2.3.1:

 

   client-secret = *TEXT

 

   (This matches the "password" definition in the HTTP Basic

   Authentication Scheme [RFC2617].)

 

A.3.  "response_type" Syntax

 

   The "response_type" element is defined in Section 3.1.1 and

   Section 8.4:

 

   response-type = response-name *( SP response-name )

   response-name = 1*response-char

   response-char = "_" / DIGIT / ALPHA

 

A.4.  "scope" Syntax

 

   The "scope" element is defined in Section 3.3:

 

   scope       = scope-token *( SP scope-token )

   scope-token = 1*( %x21 / %x23-5B / %x5D-7E )

 

A.5.  "state" Syntax

 

   The "state" element is defined in Section 4.1.1, Section 4.1.2,

   Section 4.1.2.1, Section 4.2.1, Section 4.2.2, and Section 4.2.2.1:

 

   state      = 1*unreserved

 

A.6.  "redirect_uri" Syntax

 

   The "redirect_uri" element is defined in Section 4.1.1,

   Section 4.1.3, and Section 4.2.1:

 

   redirect-uri      = URI

 

A.7.  "error" Syntax

 

   The "error" element is defined in Section 4.1.2.1, Section 4.2.2.1,

   Section 5.2, Section 7.2, and Section 8.5:

 

   error             = 1*error-char

   error-char        = %x20-21 / %x23-5B / %x5D-7E

 

A.8.  "error_description" Syntax

 

   The "error_description" element is defined in Section 4.1.2.1,

   Section 4.2.2.1, Section 5.2, and Section 7.2:

 

   error-description = 1*error-char

   error-char        = %x20-21 / %x23-5B / %x5D-7E

 

A.9.  "error_uri" Syntax

 

   The "error_uri" element is defined in Section 4.1.2.1,

   Section 4.2.2.1, Section 5.2, and Section 7.2:

 

   error-uri         = URI

 

A.10.  "grant_type" Syntax

 

   The "grant_type" element is defined in Section 4.1.3, Section 4.3.2,

   Section 4.4.1, Section 6, and Section 4.5:

 

   grant-type = grant-name / URI

   grant-name = 1*name-char

   name-char  = "-" / "." / "_" / DIGIT / ALPHA

 

A.11.  "code" Syntax

 

   The "code" element is defined in Section 4.1.3:

 

   code       = 1*unreserved

 

A.12.  "access_token" Syntax

 

   The "access_token" element is defined in Section 4.2.2 and

   Section 5.1:

 

   access-token = b64token

 

A.13.  "token_type" Syntax

 

   The "token_type" element is defined in Section 4.2.2, Section 5.1,

   and Section 8.1:

 

   token-type = type-name / URI

   type-name  = 1*name-char

   name-char  = "-" / "." / "_" / DIGIT / ALPHA

 

A.14.  "expires_in" Syntax

 

   The "expires_in" element is defined in Section 4.2.2 and Section 5.1:

 

   expires-in = 1*DIGIT

 

A.15.  "username" Syntax

 

   The "username" element is defined in Section 4.3.2:

 

   username = *<TEXT excluding ":">

 

   (This matches the "userid" definition in the HTTP Basic

   Authentication Scheme [RFC2617].)

 

A.16.  "password" Syntax

 

   The "password" element is defined in Section 4.3.2:

 

   password = *TEXT

 

   (This matches the "password" definition in the HTTP Basic

   Authentication Scheme [RFC2617].)

 

A.17.  "refresh_token" Syntax

 

   The "refresh_token" element is defined in Section 5.1 and Section 6:

 

   refresh-token = b64token

 

A.18.  Endpoint Parameter Syntax

 

   The syntax for new endpoint parameters is defined in Section 8.2:

 

   param-name = 1*name-char

   name-char  = "-" / "." / "_" / DIGIT / ALPHA

 

 



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

--------------010903020802070605060602-- From bcampbell@pingidentity.com Mon Jun 4 13:10:36 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA9DE11E80C5 for ; Mon, 4 Jun 2012 13:10:36 -0700 (PDT) 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 pKk9jrYc+DiE for ; Mon, 4 Jun 2012 13:10:35 -0700 (PDT) Received: from na3sys009aog113.obsmtp.com (na3sys009aog113.obsmtp.com [74.125.149.209]) by ietfa.amsl.com (Postfix) with ESMTP id 5A8CC11E80BA for ; Mon, 4 Jun 2012 13:10:28 -0700 (PDT) Received: from mail-qa0-f48.google.com ([209.85.216.48]) (using TLSv1) by na3sys009aob113.postini.com ([74.125.148.12]) with SMTP ID DSNKT80WMWofxs0z9bzPdBu/6xfW/uSSfSRK@postini.com; Mon, 04 Jun 2012 13:10:34 PDT Received: by qady23 with SMTP id y23so2438744qad.7 for ; Mon, 04 Jun 2012 13:10:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=FgbhKglZ7Okg1r+Yp+AhAoteLGU6jyF283jlS2Ryk9E=; b=lX4S7/l6FC9y/A4Tbp+vrrPy6EHdkenNMeXrE+uLywF5HIzrsOUwo4K1EhaTJFKOYz f9gMfJPmLQJ4162Iqk6IMObxn80zu1hqDNgiZjZcy1wRXcDsoatht/dLHmgpC819pkAl WD39HK1bO8pJKrlCbFCnke1NQrR6NHeDUr8ltuCBxGwRvd4M5HI8a6RqrYVFhvfOjjDW XyfSEnU3aHTur/rkdhZ9cNYjNI/gAOv3UQVoMpKQE0Z+yZtIC+6J/BeDJ+/N8DIycC3g ymii9WeTmSbKGeWhkrBaqQIEnqrXLRwhxzzruiQUM8T/PCBVtvfqNDrfPSc8MGA9l5R0 MVMQ== Received: by 10.224.217.67 with SMTP id hl3mr14478517qab.75.1338840621486; Mon, 04 Jun 2012 13:10:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.226.140 with HTTP; Mon, 4 Jun 2012 13:09:51 -0700 (PDT) In-Reply-To: <999913AB42CC9341B05A99BBF358718D017BA762@FIESEXC035.nsn-intra.net> References: <999913AB42CC9341B05A99BBF358718D017BA762@FIESEXC035.nsn-intra.net> From: Brian Campbell Date: Mon, 4 Jun 2012 14:09:51 -0600 Message-ID: To: "Tschofenig, Hannes (NSN - FI/Espoo)" Content-Type: multipart/alternative; boundary=20cf300fb275a7941604c1ab1f86 X-Gm-Message-State: ALoCoQlkPkjVgWSezTzzrsJykIFozJBZhVuwknPmO6nSpBf/Eji1lWen5hjcZvgld5pJEyHyL4w9 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] More draft-ietf-oauth-assertions-03 comments X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 20:10:36 -0000 --20cf300fb275a7941604c1ab1f86 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Again thanks for the comments and questions Hannes and apologies for the delayed response on this one. I've tried to address your comments inline below. Some new questions were raised too. On Fri, May 25, 2012 at 1:22 AM, Tschofenig, Hannes (NSN - FI/Espoo) < hannes.tschofenig@nsn.com> wrote: > ** > > Here a few minor comments: > > The specification does not provide a lot of hints for the client when an > error occurs. For example, Section 4.1.1 only says =93invalid_client=94 i= s > something goes wrong with the assertion processing in case of client > authentication. The same is true for the authorization grant error > response in Section 4.2.1. > > What about errors like? > > =B7 Assertion was not fresh =96 replay detected (based on the asser= tion > ID) > > =B7 Issuer unknown or not trusted > > =B7 Assertion couldn=92t be parsed > > =B7 The assertion format is unknown > > =B7 Signature covering the assertion couldn=92t be verified > > =B7 Audience does not match > > =B7 Assertion expired (based on =91expired at=92 element) > > =B7 Missing mandatory elements in the assertion > T intent was to utilize the "error_description" field to provide such information (at the discretion of the AS). =A74.1.1 and =A74.2.1 have the text, 'The authorization server MAY include additional information regarding the reasons the assertion was considered invalid using the "error_description" or "error_uri" parameters.' The use of "invalid_client" and "invalid_grant" error codes in this document are consistent with their definition and usage in the OAuth Framework spec and the description is available to provide more detailed troubleshooting information. I didn't want to attempt to iterate all possible error conditions and register them as OAuth error codes nor did I feel there would be value in doing so. There may also be AS implementations/deployments that, for security reasons, don't want to provide such detailed information on error conditions. There are a lot of =93SHOULDs=94 in the specification and I was wondering = why > this has to be the case. > I believe that in general that is largely because this document is an abstract meta specification that attempts to provide guidance and common functionality to the concrete specs that will derive from it (currently the SAML and JWT profiles are the only ones) without dictating too much. > Typically, there has to be a good reason why there is a SHOULD rather tha= n > a MUST or at least an explanation in case there are different processing > alternatives. > > For example, Section 5.2 says: > > =93When the client is acting on behalf of itself, the > > Principal SHOULD be the "client_id". > > =93 > > When the client is acting on his own behalf then it would be good to say > in what cases the principal element does not contain the client_id. In > general, it seems that the client_id and the principal are pretty much th= e > same thing (the fields just appear twice). > The same issue regarding the =93SHOULD=94 shows up in other places as well= , > such as with the issuer in the same section: =93If an assertion is > self-asserted, the > > Issuer SHOULD be the "client_id".=94 > In some cases these entities may be identified by means other than their OAuth specific identifier and I believe part of the intent in these SHOULDs is to allow for that while having some other kind of association between that identifier and the client id. And also leaving this meta spec as somewhat general. Perhaps the wording around those items could be improved however. What about something like this, for example, "If an assertion is self-issued, the Issuer MUST unambiguously identify the client to the AS and MAY be the 'client_id'."? > Again same section: =93The Audience SHOULD be the URL of the Authorizati= on > > Server's Token Endpoint.=94 > > In case it is not an URL what else should it be? When can this other case > happen? > The audience can be used as a restriction of where there assertion is intended to be sent (which is the URL case) but also as an indication of whom it was sent to (which is case that might have a more abstract value identifying the AS). If you look in the SAML Profile, for example, you'll see a lot of wording trying to account for different possibilities of how the Audience is represented in how it talks about the SAML AudienceRestriction element and the Recipient attribute. > You also write: =93The assertion MUST contain an Issuer.=94 > > That=92s great but what is the relationship if the assertion already > contains an issuer as part of the signature that covers the party that si= gned > the assertion (which is the case in SAML). Do they have to match? > I'm not sure I understand this exactly? The intent is to say that whatever the token/assertion is, it needs to have a field/element/claim that says who "issued" it. In SAML there is the Issuer element which is covered by the signature but is not part of the signature. The same is true of JWT but it's a claim named "iss". > Section 6.3 and Section 6.4 say: > > =93 > > o The grant_type HTTP request parameter MUST indicate the assertion > > format. > > =93 > > Is this correct? Shouldn=92t it be rather > > =93 > > o The "client_assertion_type" HTTP parameter MUST identify the > > assertion format. > > =93 > > > The "client acting on behalf of" cases are done by using an assertion as an authorization grant so the use of "grant_type" in 6.3 and 6.4 is correct. > Difference between Section 6.3 and 6.3: anonymous user or not > > These two sections are identical with one exception: the content of the > principal element. > > Wouldn=92t it make sense to merge the two cases and then to indicate that > the content of the principal element varies? > Yes, that probably would make sense as well as shorten up the draft a bit. I'll work on it. > In Section 6.2 you write: > > When a client is accessing resources on behalf of itself, it SHOULD > > do so in a manner analogous to the Client Credentials flow defined in > > *Section 4.4*of OAuth 2.0 [ > *I-D.ietf-oauth-v2* > ]. > > Use =93Client Credentials Grant flow=94 instead of =93Client Credentials= flow=94 > I've made that change in my local copy of the xml source. At what point in this process can I or should I post a new revision? > In Section 6.3 you write: > > =93 > > When a client is accessing resources on behalf of a user, it SHOULD > > be treated as using an assertion as an Authorization Grant according > > to *Section 4.2*. > > > =93 > > This is a confusing sentence. I believe what you are trying to say is tha= t > the description in Section 4.2 MUST be followed. > > Agree that the sentence is confusing and could be worded better. But I don't necessarily want to say MUST as the core framework spec allows for the "on behalf of" case using the client credentials grant. How about, "When a client is accessing resources on behalf of a user, it SHOULD use an assertion as an Authorization Grant according to Section 4.2."? > > > IANA consideration section: This section is essentially the communication > you have with IANA to request values to be added to existing registries. = It > helps them to be specific about what information you want to get added to > what registry. > > For example, Section 8.1 registers an additional parameter called =93 > assertion=94. It would be useful to just say that this is a new entry to = the > =93OAuth Parameters Registry=94 established in Section 11.2 of [ > I-D.ietf-oauth-v2 > ]. > Other than not using the actual section number, doesn't it basically say that already? > As a minor nit here The parameter usage location indicates =93client > authentication, token request=94. Client authentication is not a valid > location per Section 11.2.1. > > The same comment applies to Section 8.2 and Section 8.3. > I've removed the "client authentication" from the param usage location bullet of each of those three sections. > Ciao > > Hannes > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --20cf300fb275a7941604c1ab1f86 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Again thanks for the comments and questions Hannes and apologies for the de= layed response on this one.=A0 I've tried to address your comments inli= ne below. Some new questions were raised too.


On Fri, May 25, 2012 at 1:22 AM, Tschofe= nig, Hannes (NSN - FI/Espoo) <hannes.tschofenig@nsn.com> wrote:

Here a few minor= comments:

The specification does not provide a lot of hints = for the client when an error occurs. For example, Section 4.1.1 only says =93<= span lang=3D"en-us">invalid_client=94 is something goes wrong with the assertion proce= ssing in case of client authentication. = The same is true for the authorization grant error r= esponse in Section 4.2.1.

What about error= s like?

=B7=A0=A0=A0=A0=A0=A0 Assertion was not fresh =96 rep= lay detected (based on the assertion ID)

=B7=A0=A0=A0=A0=A0=A0 <= font face=3D"Calibri">Issuer unknown or not trusted

=B7=A0=A0=A0=A0=A0=A0 <= font face=3D"Calibri">Assertion couldn=92t be parsed

=B7=A0=A0=A0=A0=A0=A0 <= font face=3D"Calibri">The assertion format is unknown

=B7=A0=A0=A0=A0=A0=A0 <= font face=3D"Calibri">Signature covering the assertion couldn= =92t be verified

=B7=A0=A0=A0=A0=A0=A0 Audience does not match

=B7=A0=A0=A0=A0=A0=A0 <= font face=3D"Calibri">Assertion expired (based on =91expired at=92= element)<= /span>

=B7=A0=A0=A0=A0=A0=A0 <= font face=3D"Calibri">Missing mandatory elements in the assertion


T intent was to=20 utilize the "error_description" field to provide such information= (at=20 the discretion of the AS).=A0 =A74.1.1 and =A74.2.1 have the text, 'The= =20 authorization server MAY include additional information regarding the reasons the assertion was considered invalid using the "error_description" or "erro= r_uri" parameters.' The use of "invalid_client" and "invalid= _grant" error=20 codes in this document are consistent with their definition and usage in the OAuth Framework spec and the description is available to provide=20 more detailed troubleshooting information. I didn't want to attempt to= =20 iterate all possible error conditions and register them as OAuth error=20 codes nor did I feel there would be value in doing so. There may also be AS implementations/deployments that, for security reasons, don't want= =20 to provide such detailed information on error conditions.


=

There are a lot = of =93SHOULDs=94= in the specification and I was wondering why this has to be the case= .


I believe that in general that is largely becau= se this document is an abstract meta specification that attempts to provide= guidance and common functionality to the concrete specs that will derive f= rom it (currently the SAML and JWT profiles are the only ones) without dict= ating too much.
=A0

Typically, there has to be= a good reason why there is a SHOULD rather than a MUST or at least an expl= anation in case there are different processing alternatives. =

For example, Sec= tion 5.2 says:

=93When the client is acting on behalf of itself, the

=A0=A0=A0=A0= =A0 Principal SHOULD be the "client_id".

=93

When the client is acting on his ow= n behalf then it would be good to say in what cases the principal element d= oes not contain the client_id. In general, it seems that the client_id and = the principal are pretty much the same thing (the fields just appear twice).

The same issue r= egarding the= =93SHOULD=94<= /span> shows up in other places as well, such as w= ith the issuer in the same section: =93If an assertion is self-asserted, the

=A0=A0=A0=A0= =A0 Issuer SHOULD be the "client_id".=94


In some cases these entities may be identified = by means other than their OAuth specific identifier and I believe part of t= he intent in these SHOULDs is to allow for that while having some other kin= d of association between that identifier and the client id. And also leavin= g this meta spec as somewhat general.

Perhaps the wording around those items could be improved however.=A0 Wh= at about something like this, for example, "If an assertion is self-is= sued, the Issuer MUST unambiguously identify the client to the AS and MAY b= e the 'client_id'."?
=A0

Again same section: =93The Audience SHOULD be the URL of the = Authorization

=A0=A0=A0=A0= =A0 Server's Token Endpoint.=94

In case it is not an URL what else = should it be? When can this other case happen?


The audience can be used as a restriction of where there assertion= is intended to be sent (which is the URL case) but also as an indication o= f whom it was sent to (which is case that might have a more abstract value = identifying the AS).=A0 If you look in the SAML Profile, for example, you&#= 39;ll see a lot of wording trying to account for different possibilities of= how the Audience is represented in how it talks about the SAML AudienceRes= triction element and the Recipient attribute.

You also write: =93The assertion MUST contain an Issuer.=94 =

That=92<= /span>s great but what is the r= elationship if the assertion already contains an issuer as part of the sign= ature that covers the party that signed the assertion (which is the case in SAML). Do they have to match?


I'm not sure I understand this exactly?=A0 = The intent is to say that whatever the token/assertion is, it needs to have= a field/element/claim that says who "issued" it.=A0 In SAML ther= e is the Issuer element which is covered by the signature but is not part o= f the signature. The same is true of JWT but it's a claim named "i= ss".
=A0

Section 6.3 and Section 6.= 4 say:

=93

=A0=A0 o=A0 The grant_type HTTP request parameter MUST ind= icate the assertion

=A0=A0=A0=A0= =A0 format.

=93

Is this correct?= Shouldn=92t it be rather <= /span>

=93

=A0=A0 o=A0 The "client_assertion_type" HTTP par= ameter MUST identify the

=A0=A0=A0=A0= =A0 assertion format.

=93

=A0


The "client acting on behalf of" cases are done by using a= n assertion as an authorization grant so the use of "grant_type" = in 6.3 and 6.4 is correct.
=A0

Difference betwe= en Section 6.3 and 6.3: anonymous user or not

These two sectio= ns are identical with one exception: the content of the principal element.

Wouldn=92t it make sense to merge the two cases an= d then to indicate that the content of the principal element varies?=


Yes, that probably would make sense as well as = shorten up the draft a bit.=A0 I'll work on it.
=A0

In Section 6.2 y= ou write:

When a client is accessing resources on behalf of itself, = it SHOULD

=A0=A0 do so= in a manner analogous to the Client Credentials flow defined in

=A0=A0 <= font color=3D"#0000FF" face=3D"Courier New">Section 4.4 of OAuth 2.0 [I-D.ietf= -oauth-v2].

Use=A0 =93Client Credentials Grant flow=94 instead of =93Client Credentials flow=94


I've made that change in my local copy of t= he xml source. At what point in this process can I or should I post a new r= evision?

=A0

In Section 6.3 y= ou write:

=93

When a client is accessing resources on behalf of a user, = it SHOULD

=A0=A0 be tr= eated as using an assertion as an Authorization Grant according

=A0=A0 to <= u>Section 4.2.

=93

This is a confus= ing sentence. I believe what you are trying to say is that the description = in Section 4.2 MUST be followed.

Agree that the sentence is confu= sing and could be worded better. But I don't necessarily want to say MU= ST as the core framework spec allows for the "on behalf of" case = using the client credentials grant.

How about, "When a client is accessing resources on behalf of a us= er, it SHOULD use an assertion as an Authorization Grant according to Secti= on 4.2."?
=A0
=A0

IANA considerati= on section: This section is essentially the communication you have with IAN= A to request values to be added to existing registries. It helps them to be specific about w= hat information you want to get added to what registry.

For exa= mple, Section 8.1 registers an additional parameter called =93assertion<= /span>=94. It would be useful to just say that this is a new entry to the= =93OAuth Parameters Registry<= span lang=3D"en-us">=94<= /font> established in Section 11.2 of [I-D.ietf-oauth-v2].


Other than not using the actual section number,= doesn't it basically say that already?
=A0

As a minor nit h= ere The parameter usage location indicates =93client authentication, tok= en request=94. Client authentication is not a valid location per Section= 11.2.1.

The same comment= applies to Section 8.2 and Section 8.3.


I've removed the "client authentication" from the = param usage location bullet of each of those three sections.

=A0

Ciao

Hannes


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


--20cf300fb275a7941604c1ab1f86-- From eve@xmlgrrl.com Mon Jun 4 14:14:56 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4ADA11E80DF for ; Mon, 4 Jun 2012 14:14:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.293 X-Spam-Level: X-Spam-Status: No, score=-1.293 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_DOMAIN_NOVOWEL=0.5, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YUXCBORM-QUy for ; Mon, 4 Jun 2012 14:14:56 -0700 (PDT) Received: from promanage-inc.com (eliasisrael.com [50.47.36.5]) by ietfa.amsl.com (Postfix) with ESMTP id 41DE411E807F for ; Mon, 4 Jun 2012 14:14:55 -0700 (PDT) Received: from [192.168.168.185] ([192.168.168.185]) (authenticated bits=0) by promanage-inc.com (8.14.4/8.14.4) with ESMTP id q54LEpPW025529 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 4 Jun 2012 14:14:52 -0700 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Eve Maler In-Reply-To: <4FCB8C4D.3090703@lodderstedt.net> Date: Mon, 4 Jun 2012 14:14:51 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <09CE58C6-9409-4E28-B4CA-DC76C37B898E@gmx.net> <4FCB8C4D.3090703@lodderstedt.net> To: Torsten Lodderstedt X-Mailer: Apple Mail (2.1278) Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Meeting slot for the Vancouver IETF meeting requested X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 21:14:56 -0000 I hope to attend in person. Once we know the meeting time slot, I'll be = able to confirm one way or the other. Eve On 3 Jun 2012, at 9:09 AM, Torsten Lodderstedt wrote: > I plan to attend. >=20 > regards, > Torsten. >=20 > Am 02.06.2012 09:46, schrieb Hannes Tschofenig: >> Hi all, >>=20 >> I have requested a 2,5 hour slot for the upcoming meeting. >>=20 >> While the next meeting is still a bit away it is nevertheless useful = to hear >> * whether you plan to attend the next meeting, and >> * whether you want to present something. >>=20 >> I could imagine that these documents will be discussed: >> * draft-ietf-oauth-dyn-reg >> * draft-ietf-oauth-json-web-token >> * draft-ietf-oauth-jwt-bearer >> * draft-ietf-oauth-revocation >> * draft-ietf-oauth-use-cases >>=20 >> To the draft authors of these docuemnts: Please think about the open = issues and drop a mail to the list so that we make some progress already = before the face-to-face meeting. >>=20 >> I am assume that the following documents do not require any = discussion time at the upcoming IETF meeting anymore: >> * draft-ietf-oauth-assertions >> * draft-ietf-oauth-saml2-bearer >> * draft-ietf-oauth-urn-sub-ns >> * draft-ietf-oauth-v2 >> * draft-ietf-oauth-v2-bearer >>=20 >> Ciao >> Hannes >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl From Michael.Jones@microsoft.com Mon Jun 4 14:57:31 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ED9921F86CF for ; Mon, 4 Jun 2012 14:57:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.662 X-Spam-Level: X-Spam-Status: No, score=-3.662 tagged_above=-999 required=5 tests=[AWL=-0.065, BAYES_00=-2.599, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=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 BiwJQ8n4xAAQ for ; Mon, 4 Jun 2012 14:57:27 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe004.messaging.microsoft.com [216.32.181.184]) by ietfa.amsl.com (Postfix) with ESMTP id 2589021F86D8 for ; Mon, 4 Jun 2012 14:57:27 -0700 (PDT) Received: from mail252-ch1-R.bigfish.com (10.43.68.244) by CH1EHSOBE012.bigfish.com (10.43.70.62) with Microsoft SMTP Server id 14.1.225.23; Mon, 4 Jun 2012 21:56:46 +0000 Received: from mail252-ch1 (localhost [127.0.0.1]) by mail252-ch1-R.bigfish.com (Postfix) with ESMTP id 02E081740178; Mon, 4 Jun 2012 21:56:46 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -40 X-BigFish: VS-40(zz9371Ic85fhcacW98dK4015Izz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25hf0ah) Received-SPF: pass (mail252-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail252-ch1 (localhost.localdomain [127.0.0.1]) by mail252-ch1 (MessageSwitch) id 1338847002874972_32359; Mon, 4 Jun 2012 21:56:42 +0000 (UTC) Received: from CH1EHSMHS017.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.226]) by mail252-ch1.bigfish.com (Postfix) with ESMTP id C98E0172007F; Mon, 4 Jun 2012 21:56:42 +0000 (UTC) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS017.bigfish.com (10.43.70.17) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 4 Jun 2012 21:56:42 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.189]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.02.0298.005; Mon, 4 Jun 2012 21:56:15 +0000 From: Mike Jones To: Brian Campbell Thread-Topic: [OAUTH-WG] ABNF elements for suggested WG review Thread-Index: Ac1Alx0u1VneJZSBR8aFxCHOlLRpzQB5w8cAAAejF+A= Date: Mon, 4 Jun 2012 21:56:15 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366529104@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739436652634C@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.19] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394366529104TK5EX14MBXC284r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] ABNF elements for suggested WG review X-BeenThere: oauth@ietf.org X-Mailman-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, 04 Jun 2012 21:57:31 -0000 --_000_4E1F6AAD24975D4BA5B168042967394366529104TK5EX14MBXC284r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Brian, I don't think I followed your message completely. What it is that Nat wrot= e that you were referring to? Thanks, -- Mike From: Brian Campbell [mailto:bcampbell@pingidentity.com] Sent: Monday, June 04, 2012 11:17 AM To: Mike Jones Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] ABNF elements for suggested WG review Although what Nat is doing in this post is a little off topic, note that he= does have an https URL as a client id which would be disallowed by the ABN= F in A.1 below. Excluding ":" in client id definition makes sense when you = consider that client ids will often be used as a userid in HTTP Basic but i= s that too restrictive in general? On Sat, Jun 2, 2012 at 2:10 AM, Mike Jones > wrote: Dear working group, It turns out that writing an ABNF for the Core spec pointed out that the sy= ntax of a number of the OAuth protocol elements had not been previously def= ined. (Thanks, Sean, for having us do this!) I took a stab at specifying = appropriate ABNF values for each of the protocol elements, but I would requ= est that the working group actively review the choices in my proposed draft= . For instance, I chose to use the same syntax definitions for username and p= assword and client_id and client_secret as HTTP Basic used for userid and p= assword. Other choices were possible, such as perhaps limiting client_id a= nd possibly username values to use "unreserved" characters, rather than all= owing all characters other than ":" (as HTTP Basic did with userid). Please particularly review the syntax definitions for these elements, as I = had to make choices that went beyond the current specs to provide unambiguo= us syntax definitions: client_id client_secret state code access_token username password refresh_token The full proposed ABNF section follows. -- Mike Appendix A. Augmented Backus-Naur Form (ABNF) Syntax This section provides Augmented Backus-Naur Form (ABNF) syntax descriptions for the elements defined in this specification using the notation of [RFC5234]. Elements are presented in the order first defined. Some of the definitions that follow use the "unreserved" and "URI" definitions from [RFC3986], which are: unreserved =3D ALPHA / DIGIT / "-" / "." / "_" / "~" URI =3D scheme ":" hier-part [ "?" query ] [ "#" fragment ] Some of the definitions that follow use the "b64token" syntax below, which matches the "b64token" syntax defined by HTTP/1.1, Part 7 [I-D.ietf-httpbis-p7-auth]: b64token =3D 1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" ) *"=3D" A.1. "client_id" Syntax The "client_id" element is defined in Section 2.3.1: client-id =3D * (This matches the "userid" definition in the HTTP Basic Authentication Scheme [RFC2617].) A.2. "client_secret" Syntax The "client_secret" element is defined in Section 2.3.1: client-secret =3D *TEXT (This matches the "password" definition in the HTTP Basic Authentication Scheme [RFC2617].) A.3. "response_type" Syntax The "response_type" element is defined in Section 3.1.1 and Section 8.4: response-type =3D response-name *( SP response-name ) response-name =3D 1*response-char response-char =3D "_" / DIGIT / ALPHA A.4. "scope" Syntax The "scope" element is defined in Section 3.3: scope =3D scope-token *( SP scope-token ) scope-token =3D 1*( %x21 / %x23-5B / %x5D-7E ) A.5. "state" Syntax The "state" element is defined in Section 4.1.1, Section 4.1.2, Section 4.1.2.1, Section 4.2.1, Section 4.2.2, and Section 4.2.2.1: state =3D 1*unreserved A.6. "redirect_uri" Syntax The "redirect_uri" element is defined in Section 4.1.1, Section 4.1.3, and Section 4.2.1: redirect-uri =3D URI A.7. "error" Syntax The "error" element is defined in Section 4.1.2.1, Section 4.2.2.1, Section 5.2, Section 7.2, and Section 8.5: error =3D 1*error-char error-char =3D %x20-21 / %x23-5B / %x5D-7E A.8. "error_description" Syntax The "error_description" element is defined in Section 4.1.2.1, Section 4.2.2.1, Section 5.2, and Section 7.2: error-description =3D 1*error-char error-char =3D %x20-21 / %x23-5B / %x5D-7E A.9. "error_uri" Syntax The "error_uri" element is defined in Section 4.1.2.1, Section 4.2.2.1, Section 5.2, and Section 7.2: error-uri =3D URI A.10. "grant_type" Syntax The "grant_type" element is defined in Section 4.1.3, Section 4.3.2, Section 4.4.1, Section 6, and Section 4.5: grant-type =3D grant-name / URI grant-name =3D 1*name-char name-char =3D "-" / "." / "_" / DIGIT / ALPHA A.11. "code" Syntax The "code" element is defined in Section 4.1.3: code =3D 1*unreserved A.12. "access_token" Syntax The "access_token" element is defined in Section 4.2.2 and Section 5.1: access-token =3D b64token A.13. "token_type" Syntax The "token_type" element is defined in Section 4.2.2, Section 5.1, and Section 8.1: token-type =3D type-name / URI type-name =3D 1*name-char name-char =3D "-" / "." / "_" / DIGIT / ALPHA A.14. "expires_in" Syntax The "expires_in" element is defined in Section 4.2.2 and Section 5.1: expires-in =3D 1*DIGIT A.15. "username" Syntax The "username" element is defined in Section 4.3.2: username =3D * (This matches the "userid" definition in the HTTP Basic Authentication Scheme [RFC2617].) A.16. "password" Syntax The "password" element is defined in Section 4.3.2: password =3D *TEXT (This matches the "password" definition in the HTTP Basic Authentication Scheme [RFC2617].) A.17. "refresh_token" Syntax The "refresh_token" element is defined in Section 5.1 and Section 6: refresh-token =3D b64token A.18. Endpoint Parameter Syntax The syntax for new endpoint parameters is defined in Section 8.2: param-name =3D 1*name-char name-char =3D "-" / "." / "_" / DIGIT / ALPHA _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_4E1F6AAD24975D4BA5B168042967394366529104TK5EX14MBXC284r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Brian,

 <= /p>

I don’t think I fol= lowed your message completely.  What it is that Nat wrote that you wer= e referring to?

 <= /p>

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;         Thanks,

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

 <= /p>

From: Brian Ca= mpbell [mailto:bcampbell@pingidentity.com]
Sent: Monday, June 04, 2012 11:17 AM
To: Mike Jones
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] ABNF elements for suggested WG review

 

Although what Nat is = doing in this post is a little off topic, note that he does have an https U= RL as a client id which would be disallowed by the ABNF in A.1 below. Exclu= ding ":" in client id definition makes sense when you consider that client ids will often be used as a userid in = HTTP Basic but is that too restrictive in general?

On Sat, Jun 2, 2012 at 2:10 AM, Mike Jones <Michael.Jones@m= icrosoft.com> wrote:

Dear working group,

 

It turns out that writing an ABNF for the Core spec pointed out th= at the syntax of a number of the OAuth protocol elements had not been previ= ously defined.  (Thanks, Sean, for having us do this!)  I took a stab at specifying appropriate ABNF values for= each of the protocol elements, but I would request that the working group = actively review the choices in my proposed draft.

 

For instance, I chose to use the same syntax definitions for usern= ame and password and client_id and client_secret as HTTP Basic used for use= rid and password.  Other choices were possible, such as perhaps limiting client_id and possibly username values = to use “unreserved” characters, rather than allowing all charac= ters other than “:” (as HTTP Basic did with userid).=

 

Please particularly review the syntax definitions for these elemen= ts, as I had to make choices that went beyond the current specs to provide = unambiguous syntax definitions:

           =     client_id

           =     client_secret

           =     state

           =     code

           =     access_token

           =     username

           =     password

           =     refresh_token

 

The full proposed ABNF section follows.

 

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

 

Appendix A.  Augmented Backus-Naur Form (ABNF) Syntax

 

   This section provides Augmented Backus-Naur Form (ABNF) syn= tax

   descriptions for the elements defined in this specification= using the

   notation of [RFC5234].  Elements are presented in the = order first

   defined.

 

   Some of the definitions that follow use the "unreserve= d" and "URI"

   definitions from [RFC3986], which are:

 

   unreserved =3D ALPHA / DIGIT / "-" / "."= ; / "_" / "~"

   URI        =3D scheme &q= uot;:" hier-part [ "?" query ] [ "#" fragment ]

 

   Some of the definitions that follow use the "b64token&= quot; syntax below,

   which matches the "b64token" syntax defined by HT= TP/1.1, Part 7

   [I-D.ietf-httpbis-p7-auth]:

 

   b64token   =3D 1*( ALPHA / DIGIT /

            =         "-" / "." / = "_" / "~" / "+" / "/" ) *"= =3D"

 

A.1.  "client_id" Syntax

 

   The "client_id" element is defined in Section 2.3= .1:

 

   client-id     =3D *<TEXT excluding &= quot;:">

 

   (This matches the "userid" definition in the HTTP= Basic

   Authentication Scheme [RFC2617].)

 

A.2.  "client_secret" Syntax

 

   The "client_secret" element is defined in Section= 2.3.1:

 

   client-secret =3D *TEXT

 

   (This matches the "password" definition in the HT= TP Basic

   Authentication Scheme [RFC2617].)

 

A.3.  "response_type" Syntax

 

   The "response_type" element is defined in Section= 3.1.1 and

   Section 8.4:

 

   response-type =3D response-name *( SP response-name )

   response-name =3D 1*response-char

   response-char =3D "_" / DIGIT / ALPHA=

 

A.4.  "scope" Syntax

 

   The "scope" element is defined in Section 3.3:

 

   scope       =3D scope-token *= ( SP scope-token )

   scope-token =3D 1*( %x21 / %x23-5B / %x5D-7E )<= /o:p>

 

A.5.  "state" Syntax

 

   The "state" element is defined in Section 4.1.1, = Section 4.1.2,

   Section 4.1.2.1, Section 4.2.1, Section 4.2.2, and Section 4.2.2.1:=

 

   state      =3D 1*unreserved=

 

A.6.  "redirect_uri" Syntax

 

   The "redirect_uri" element is defined in Section = 4.1.1,

   Section 4.1.3, and Section 4.2.1:

 

   redirect-uri      =3D URI

 

A.7.  "error" Syntax

 

   The "error" element is defined in Section 4.1.2.1= , Section 4.2.2.1,

   Section 5.2, Section 7.2, and Section 8.5:

 

   error         =     =3D 1*error-char

   error-char        =3D %x= 20-21 / %x23-5B / %x5D-7E

 

A.8.  "error_description" Syntax

 

   The "error_description" element is defined in Sec= tion 4.1.2.1,

   Section 4.2.2.1, Section 5.2, and Section 7.2:<= /o:p>

 

   error-description =3D 1*error-char

   error-char        =3D %x= 20-21 / %x23-5B / %x5D-7E

 

A.9.  "error_uri" Syntax

 

   The "error_uri" element is defined in Section 4.1= .2.1,

   Section 4.2.2.1, Section 5.2, and Section 7.2:<= /o:p>

 

   error-uri         = =3D URI

 

A.10.  "grant_type" Syntax

 

   The "grant_type" element is defined in Section 4.= 1.3, Section 4.3.2,

   Section 4.4.1, Section 6, and Section 4.5:

 

   grant-type =3D grant-name / URI

   grant-name =3D 1*name-char

   name-char  =3D "-" / "." / "_= " / DIGIT / ALPHA

 

A.11.  "code" Syntax

 

   The "code" element is defined in Section 4.1.3:

 

   code       =3D 1*unreserved

 

A.12.  "access_token" Syntax

 

   The "access_token" element is defined in Section = 4.2.2 and

   Section 5.1:

 

   access-token =3D b64token

 

A.13.  "token_type" Syntax

 

   The "token_type" element is defined in Section 4.= 2.2, Section 5.1,

   and Section 8.1:

 

   token-type =3D type-name / URI

   type-name  =3D 1*name-char

   name-char  =3D "-" / "." / "_= " / DIGIT / ALPHA

 

A.14.  "expires_in" Syntax

 

   The "expires_in" element is defined in Section 4.= 2.2 and Section 5.1:

 

   expires-in =3D 1*DIGIT

 

A.15.  "username" Syntax

 

   The "username" element is defined in Section 4.3.= 2:

 

   username =3D *<TEXT excluding ":">

 

   (This matches the "userid" definition in the HTTP= Basic

   Authentication Scheme [RFC2617].)

 

A.16.  "password" Syntax

 

   The "password" element is defined in Section 4.3.= 2:

 

   password =3D *TEXT

 

   (This matches the "password" definition in the HT= TP Basic

   Authentication Scheme [RFC2617].)

 

A.17.  "refresh_token" Syntax

 

   The "refresh_token" element is defined in Section= 5.1 and Section 6:

 

   refresh-token =3D b64token

 

A.18.  Endpoint Parameter Syntax

 

   The syntax for new endpoint parameters is defined in Sectio= n 8.2:

 

   param-name =3D 1*name-char

   name-char  =3D "-" / "." / "_= " / DIGIT / ALPHA

 

 


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

 

--_000_4E1F6AAD24975D4BA5B168042967394366529104TK5EX14MBXC284r_-- From Michael.Jones@microsoft.com Mon Jun 4 15:04:51 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C533B21F8697 for ; Mon, 4 Jun 2012 15:04:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.661 X-Spam-Level: X-Spam-Status: No, score=-3.661 tagged_above=-999 required=5 tests=[AWL=-0.062, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4mmdn6E4+AA5 for ; Mon, 4 Jun 2012 15:04:51 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe001.messaging.microsoft.com [216.32.180.11]) by ietfa.amsl.com (Postfix) with ESMTP id CA8FD21F852D for ; Mon, 4 Jun 2012 15:04:50 -0700 (PDT) Received: from mail244-va3-R.bigfish.com (10.7.14.247) by VA3EHSOBE002.bigfish.com (10.7.40.22) with Microsoft SMTP Server id 14.1.225.23; Mon, 4 Jun 2012 22:04:10 +0000 Received: from mail244-va3 (localhost [127.0.0.1]) by mail244-va3-R.bigfish.com (Postfix) with ESMTP id C6760340086; Mon, 4 Jun 2012 22:04:09 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -52 X-BigFish: VS-52(zz9371I936eI542M1432NcacW98dK4015Izz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25hf0ah) Received-SPF: pass (mail244-va3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC103.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail244-va3 (localhost.localdomain [127.0.0.1]) by mail244-va3 (MessageSwitch) id 1338847448173381_12286; Mon, 4 Jun 2012 22:04:08 +0000 (UTC) Received: from VA3EHSMHS006.bigfish.com (unknown [10.7.14.245]) by mail244-va3.bigfish.com (Postfix) with ESMTP id 28089D40045; Mon, 4 Jun 2012 22:04:08 +0000 (UTC) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS006.bigfish.com (10.7.99.16) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 4 Jun 2012 22:04:07 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.189]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.02.0298.005; Mon, 4 Jun 2012 22:03:52 +0000 From: Mike Jones To: Julian Reschke Thread-Topic: [OAUTH-WG] ABNF elements for suggested WG review Thread-Index: Ac1Alx0u1VneJZSBR8aFxCHOlLRpzQAUcCIAAGu2zeA= Date: Mon, 4 Jun 2012 22:03:52 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943665291A3@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739436652634C@TK5EX14MBXC284.redmond.corp.microsoft.com> <4FCA5384.3060306@gmx.de> In-Reply-To: <4FCA5384.3060306@gmx.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] ABNF elements for suggested WG review X-BeenThere: oauth@ietf.org X-Mailman-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, 04 Jun 2012 22:04:51 -0000 RFC 2616 contains this restriction for the contents of TEXT fields: Words of *TEXT MAY contain characters from character sets other than ISO-8859-1 [22] only when encoded according to the rules of RFC 2047 [14]. Therefore, I believe that for the elements using TEXT, the encoding must be= specified as ISO-8859-1, since they are not always used in contexts where = MIME encoding rules can be specified. Yes, I believe you're correct that "URI" should be "URI-reference". I'll make both of these changes. Thanks, -- Mike -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de]=20 Sent: Saturday, June 02, 2012 10:55 AM To: Mike Jones Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] ABNF elements for suggested WG review On 2012-06-02 10:10, Mike Jones wrote: > Dear working group, > > It turns out that writing an ABNF for the Core spec pointed out that=20 > the syntax of a number of the OAuth protocol elements had not been=20 > previously defined. (Thanks, Sean, for having us do this!) I took a=20 > stab at specifying appropriate ABNF values for each of the protocol=20 > elements, but I would request that the working group actively review=20 > the choices in my proposed draft. > > For instance, I chose to use the same syntax definitions for username=20 > and password and client_id and client_secret as HTTP Basic used for=20 > userid and password. Other choices were possible, such as perhaps=20 > limiting client_id and possibly username values to use "unreserved" > characters, rather than allowing all characters other than ":" (as=20 > HTTP Basic did with userid). > > Please particularly review the syntax definitions for these elements,=20 > as I had to make choices that went beyond the current specs to provide=20 > unambiguous syntax definitions: > > client_id > > client_secret > > state > > code > > access_token > > username > > password > > refresh_token > > The full proposed ABNF section follows. > > -- Mike > > Appendix A. Augmented Backus-Naur Form (ABNF) Syntax > > This section provides Augmented Backus-Naur Form (ABNF) syntax > > descriptions for the elements defined in this specification using the > > notation of [RFC5234]. Elements are presented in the order first > > defined. > > Some of the definitions that follow use the "unreserved" and "URI" > > definitions from [RFC3986], which are: > > unreserved =3D ALPHA / DIGIT / "-" / "." / "_" / "~" > > URI =3D scheme ":" hier-part [ "?" query ] [ "#" fragment ] > > Some of the definitions that follow use the "b64token" syntax below, > > which matches the "b64token" syntax defined by HTTP/1.1, Part 7 > > [I-D.ietf-httpbis-p7-auth]: > > b64token =3D 1*( ALPHA / DIGIT / > > "-" / "." / "_" / "~" / "+" / "/" ) *"=3D" > > A.1. "client_id" Syntax > > The "client_id" element is defined in Section 2.3.1: > > client-id =3D * > > (This matches the "userid" definition in the HTTP Basic > > Authentication Scheme [RFC2617].) TEXT is defined in RFC 2616 as TEXT =3D and OCTET =3D So what character encoding do you use? Possible answers are "it depends", "= ISO-8859-1", and "UTF-8". The same comment applies to everything else using TEXT.. > A.6. "redirect_uri" Syntax > > The "redirect_uri" element is defined in Section 4.1.1, > > Section 4.1.3, and Section 4.2.1: > > redirect-uri =3D URI Are you sure that this is not a URI-reference??? > ... Best regards, Julian From bcampbell@pingidentity.com Mon Jun 4 15:04:53 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3747A21F852D for ; Mon, 4 Jun 2012 15:04:53 -0700 (PDT) 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=[AWL=-0.001, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=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 tX0SKQXkwNan for ; Mon, 4 Jun 2012 15:04:51 -0700 (PDT) Received: from na3sys009aog138.obsmtp.com (na3sys009aog138.obsmtp.com [74.125.149.19]) by ietfa.amsl.com (Postfix) with ESMTP id BEC7D21F850F for ; Mon, 4 Jun 2012 15:04:50 -0700 (PDT) Received: from mail-qa0-f53.google.com ([209.85.216.53]) (using TLSv1) by na3sys009aob138.postini.com ([74.125.148.12]) with SMTP ID DSNKT80xAUk5DKtnKe82Bslv1kLf725H+oci@postini.com; Mon, 04 Jun 2012 15:04:50 PDT Received: by qadz32 with SMTP id z32so2355855qad.12 for ; Mon, 04 Jun 2012 15:04:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=OplJOoPUxpLBCGK36WxNWui9O+F0yl+Lupbj7nthswA=; b=I58ZwdBX5TLOw7kD4bneHZxaxxOZ6D32IcBErLn8Fj4rJhBy4aSa040u630i9yefhH cwKAiRsVo3hNegrEeXRURl/7Xvvv1UNqVdHHI3ukIiX95FrNzZ6vNKNcFW6dhHBSnX25 G9SziqFhP+DzJO+9wjeo7Cp9Dcxh5SwJr6JZH2FSjKgc+oDsF8EoojaRWhB5oX6uebFq ubFFyul6+akhgqMvn5rzWQyOTqvbE3Yy+7HCsGSSJ0ZHrSSocVaMmB6ao6JhQJoiyvuK 8sCNLq3V/+It+IfrDoWb5+AhUfm84gRDF+iTpMAkznndMnXQMbKQwD8BdZxtq7J44kBP hwJg== Received: by 10.224.201.136 with SMTP id fa8mr14821023qab.20.1338847488479; Mon, 04 Jun 2012 15:04:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.226.140 with HTTP; Mon, 4 Jun 2012 15:04:15 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366529104@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739436652634C@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B168042967394366529104@TK5EX14MBXC284.redmond.corp.microsoft.com> From: Brian Campbell Date: Mon, 4 Jun 2012 16:04:15 -0600 Message-ID: To: Mike Jones Content-Type: multipart/alternative; boundary=20cf300fafe5f5904704c1acb80c X-Gm-Message-State: ALoCoQm5jfXuHy8mLs7pX8r1K1Mz4Eq/DsIazsG2AGF9eOCM4My1Pou44XMauksJS68CPfj8Rc/v Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] ABNF elements for suggested WG review X-BeenThere: oauth@ietf.org X-Mailman-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, 04 Jun 2012 22:04:53 -0000 --20cf300fafe5f5904704c1acb80c Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Wow, sorry. I had a link ready to past into that message but apparently I never actually did it. My mistake. http://nat.sakimura.org/2012/04/15/openid-connect-idp-on-iphone/ is the post I'd intended to link where Nat was talking about an OpenID Connect IdP on iPhone. In the JSON in part 1 he's got, "client_id": "https://example.com/", which, if I understand correctly, wouldn't be a legal client id per the proposed ABNF? On Mon, Jun 4, 2012 at 3:56 PM, Mike Jones wro= te: > Hi Brian,**** > > ** ** > > I don=92t think I followed your message completely. What it is that Nat > wrote that you were referring to?**** > > ** ** > > Thanks,**= * > * > > -- Mike**= * > * > > ** ** > > *From:* Brian Campbell [mailto:bcampbell@pingidentity.com] > *Sent:* Monday, June 04, 2012 11:17 AM > *To:* Mike Jones > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] ABNF elements for suggested WG review**** > > ** ** > > Although what Nat is doing in this post is a little off topic, note that > he does have an https URL as a client id which would be disallowed by the > ABNF in A.1 below. Excluding ":" in client id definition makes sense when > you consider that client ids will often be used as a userid in HTTP Basic > but is that too restrictive in general?**** > > On Sat, Jun 2, 2012 at 2:10 AM, Mike Jones > wrote:**** > > Dear working group,**** > > **** > > It turns out that writing an ABNF for the Core spec pointed out that the > syntax of a number of the OAuth protocol elements had not been previously > defined. (Thanks, Sean, for having us do this!) I took a stab at > specifying appropriate ABNF values for each of the protocol elements, but= I > would request that the working group actively review the choices in my > proposed draft.**** > > **** > > For instance, I chose to use the same syntax definitions for username and > password and client_id and client_secret as HTTP Basic used for userid an= d > password. Other choices were possible, such as perhaps limiting client_i= d > and possibly username values to use =93unreserved=94 characters, rather t= han > allowing all characters other than =93:=94 (as HTTP Basic did with userid= ).*** > * > > **** > > Please particularly review the syntax definitions for these elements, as = I > had to make choices that went beyond the current specs to provide > unambiguous syntax definitions:**** > > client_id**** > > client_secret**** > > state**** > > code**** > > access_token**** > > username**** > > password**** > > refresh_token**** > > **** > > The full proposed ABNF section follows.**** > > **** > > -- Mike**** > > **** > > Appendix A. Augmented Backus-Naur Form (ABNF) Syntax**** > > **** > > This section provides Augmented Backus-Naur Form (ABNF) syntax**** > > descriptions for the elements defined in this specification using the*= * > ** > > notation of [RFC5234]. Elements are presented in the order first**** > > defined.**** > > **** > > Some of the definitions that follow use the "unreserved" and "URI"**** > > definitions from [RFC3986], which are:**** > > **** > > unreserved =3D ALPHA / DIGIT / "-" / "." / "_" / "~"**** > > URI =3D scheme ":" hier-part [ "?" query ] [ "#" fragment ]**** > > **** > > Some of the definitions that follow use the "b64token" syntax below,**= * > * > > which matches the "b64token" syntax defined by HTTP/1.1, Part 7**** > > [I-D.ietf-httpbis-p7-auth]:**** > > **** > > b64token =3D 1*( ALPHA / DIGIT /**** > > "-" / "." / "_" / "~" / "+" / "/" ) *"=3D"**** > > **** > > A.1. "client_id" Syntax**** > > **** > > The "client_id" element is defined in Section 2.3.1:**** > > **** > > client-id =3D ***** > > **** > > (This matches the "userid" definition in the HTTP Basic**** > > Authentication Scheme [RFC2617].)**** > > **** > > A.2. "client_secret" Syntax**** > > **** > > The "client_secret" element is defined in Section 2.3.1:**** > > **** > > client-secret =3D *TEXT**** > > **** > > (This matches the "password" definition in the HTTP Basic**** > > Authentication Scheme [RFC2617].)**** > > **** > > A.3. "response_type" Syntax**** > > **** > > The "response_type" element is defined in Section 3.1.1 and**** > > Section 8.4:**** > > **** > > response-type =3D response-name *( SP response-name )**** > > response-name =3D 1*response-char**** > > response-char =3D "_" / DIGIT / ALPHA**** > > **** > > A.4. "scope" Syntax**** > > **** > > The "scope" element is defined in Section 3.3:**** > > **** > > scope =3D scope-token *( SP scope-token )**** > > scope-token =3D 1*( %x21 / %x23-5B / %x5D-7E )**** > > **** > > A.5. "state" Syntax**** > > **** > > The "state" element is defined in Section 4.1.1, Section 4.1.2,**** > > Section 4.1.2.1, Section 4.2.1, Section 4.2.2, and Section 4.2.2.1:***= * > > **** > > state =3D 1*unreserved**** > > **** > > A.6. "redirect_uri" Syntax**** > > **** > > The "redirect_uri" element is defined in Section 4.1.1,**** > > Section 4.1.3, and Section 4.2.1:**** > > **** > > redirect-uri =3D URI**** > > **** > > A.7. "error" Syntax**** > > **** > > The "error" element is defined in Section 4.1.2.1, Section 4.2.2.1,***= * > > Section 5.2, Section 7.2, and Section 8.5:**** > > **** > > error =3D 1*error-char**** > > error-char =3D %x20-21 / %x23-5B / %x5D-7E**** > > **** > > A.8. "error_description" Syntax**** > > **** > > The "error_description" element is defined in Section 4.1.2.1,**** > > Section 4.2.2.1, Section 5.2, and Section 7.2:**** > > **** > > error-description =3D 1*error-char**** > > error-char =3D %x20-21 / %x23-5B / %x5D-7E**** > > **** > > A.9. "error_uri" Syntax**** > > **** > > The "error_uri" element is defined in Section 4.1.2.1,**** > > Section 4.2.2.1, Section 5.2, and Section 7.2:**** > > **** > > error-uri =3D URI**** > > **** > > A.10. "grant_type" Syntax**** > > **** > > The "grant_type" element is defined in Section 4.1.3, Section 4.3.2,**= * > * > > Section 4.4.1, Section 6, and Section 4.5:**** > > **** > > grant-type =3D grant-name / URI**** > > grant-name =3D 1*name-char**** > > name-char =3D "-" / "." / "_" / DIGIT / ALPHA**** > > **** > > A.11. "code" Syntax**** > > **** > > The "code" element is defined in Section 4.1.3:**** > > **** > > code =3D 1*unreserved**** > > **** > > A.12. "access_token" Syntax**** > > **** > > The "access_token" element is defined in Section 4.2.2 and**** > > Section 5.1:**** > > **** > > access-token =3D b64token**** > > **** > > A.13. "token_type" Syntax**** > > **** > > The "token_type" element is defined in Section 4.2.2, Section 5.1,**** > > and Section 8.1:**** > > **** > > token-type =3D type-name / URI**** > > type-name =3D 1*name-char**** > > name-char =3D "-" / "." / "_" / DIGIT / ALPHA**** > > **** > > A.14. "expires_in" Syntax**** > > **** > > The "expires_in" element is defined in Section 4.2.2 and Section 5.1:*= * > ** > > **** > > expires-in =3D 1*DIGIT**** > > **** > > A.15. "username" Syntax**** > > **** > > The "username" element is defined in Section 4.3.2:**** > > **** > > username =3D ***** > > **** > > (This matches the "userid" definition in the HTTP Basic**** > > Authentication Scheme [RFC2617].)**** > > **** > > A.16. "password" Syntax**** > > **** > > The "password" element is defined in Section 4.3.2:**** > > **** > > password =3D *TEXT**** > > **** > > (This matches the "password" definition in the HTTP Basic**** > > Authentication Scheme [RFC2617].)**** > > **** > > A.17. "refresh_token" Syntax**** > > **** > > The "refresh_token" element is defined in Section 5.1 and Section 6:**= * > * > > **** > > refresh-token =3D b64token**** > > **** > > A.18. Endpoint Parameter Syntax**** > > **** > > The syntax for new endpoint parameters is defined in Section 8.2:**** > > **** > > param-name =3D 1*name-char**** > > name-char =3D "-" / "." / "_" / DIGIT / ALPHA**** > > **** > > **** > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth**** > > ** ** > --20cf300fafe5f5904704c1acb80c Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Wow, sorry. I had a link ready to past into that message but apparently I n= ever actually did it. My mistake.

http://nat.sakimura.org/2012/04/= 15/openid-connect-idp-on-iphone/ is the post I'd intended to link w= here Nat was talking about an OpenID Connect IdP on iPhone. In the JSON in = part 1 he's got,
=A0
=A0 "client_id": "ht= tps://example.com/",

which, if I understand correctly, wou= ldn't be a legal client id per the proposed ABNF?

On Mon, Jun 4, 2012 at 3:56 PM, Mike Jones <Michael.Jones@micros= oft.com> wrote:

Hi Brian,

=A0<= /p>

I don=92t think I followe= d your message completely.=A0 What it is that Nat wrote that you were refer= ring to?

=A0<= /p>

=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 Thanks,

=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=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<= /p>

From: Brian Ca= mpbell [mailto:bcampbell@pingidentity.com]
Sent: Monday, June 04, 2012 11:17 AM
To: Mike Jones
Cc: oauth@ietf.o= rg
Subject: Re: [OAUTH-WG] ABNF elements for suggested WG review=

=A0

Although what Nat is = doing in this post is a little off topic, note that he does have an https U= RL as a client id which would be disallowed by the ABNF in A.1 below. Exclu= ding ":" in client id definition makes sense when you consider that client ids will often be used as a userid in = HTTP Basic but is that too restrictive in general?

On Sat, Jun 2, 2012 at 2:10 AM, Mike Jones <Michael.Jones@m= icrosoft.com> wrote:

Dear working group,

=A0

It turns out that writing an ABNF for the Core spec = pointed out that the syntax of a number of the OAuth protocol elements had = not been previously defined.=A0 (Thanks, Sean, for having us do this!)=A0 I took a stab at specifying appropriate ABNF values for ea= ch of the protocol elements, but I would request that the working group act= ively review the choices in my proposed draft.

=A0

For instance, I chose to use the same syntax definit= ions for username and password and client_id and client_secret as HTTP Basi= c used for userid and password.=A0 Other choices were possible, such as perhaps limiting client_id and possibly username values = to use =93unreserved=94 characters, rather than allowing all characters oth= er than =93:=94 (as HTTP Basic did with userid).

=A0

Please particularly review the syntax definitions fo= r these elements, as I had to make choices that went beyond the current spe= cs to provide unambiguous syntax definitions:

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 client_id=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 client_se= cret

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 state<= /u>

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 code

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 access_to= ken

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 username<= u>

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 password<= u>

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 refresh_t= oken

=A0

The full proposed ABNF section follows.

=A0

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

Appendix A.=A0 Augmented Backus-Naur Form (ABNF) Syntax

=A0

=A0=A0 This section provides Augmented Backus-Naur Form (A= BNF) syntax

=A0=A0 descriptions for the elements defined in this speci= fication using the

=A0=A0 notation of [RFC5234].=A0 Elements are presented in= the order first

=A0=A0 defined.

=A0

=A0=A0 Some of the definitions that follow use the "u= nreserved" and "URI"

=A0=A0 definitions from [RFC3986], which are:

=A0

=A0=A0 unreserved =3D ALPHA / DIGIT / "-" / &quo= t;." / "_" / "~"

=A0=A0 URI=A0=A0=A0=A0=A0=A0=A0 =3D scheme ":" h= ier-part [ "?" query ] [ "#" fragment ]

=A0

=A0=A0 Some of the definitions that follow use the "b= 64token" syntax below,

=A0=A0 which matches the "b64token" syntax defin= ed by HTTP/1.1, Part 7

=A0=A0 [I-D.ietf-httpbis-p7-auth]:

=A0

=A0=A0 b64token=A0=A0 =3D 1*( ALPHA / DIGIT /

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = "-" / "." / "_" / "~" / "+&quo= t; / "/" ) *"=3D"

=A0

A.1.=A0 "client_id" Syntax<= /p>

=A0

=A0=A0 The "client_id" element is defined in Sec= tion 2.3.1:

=A0

=A0=A0 client-id=A0=A0=A0=A0 =3D *<TEXT excluding "= ;:">

=A0

=A0=A0 (This matches the "userid" definition in = the HTTP Basic

=A0=A0 Authentication Scheme [RFC2617].)<= /u>

=A0

A.2.=A0 "client_secret" Syntax<= /u>

=A0

=A0=A0 The "client_secret" element is defined in= Section 2.3.1:

=A0

=A0=A0 client-secret =3D *TEXT

=A0

=A0=A0 (This matches the "password" definition i= n the HTTP Basic

=A0=A0 Authentication Scheme [RFC2617].)<= /u>

=A0

A.3.=A0 "response_type" Syntax<= /u>

=A0

=A0=A0 The "response_type" element is defined in= Section 3.1.1 and

=A0=A0 Section 8.4:

=A0

=A0=A0 response-type =3D response-name *( SP response-name= )

=A0=A0 response-name =3D 1*response-char<= /u>

=A0=A0 response-char =3D "_" / DIGIT / ALPHA

=A0

A.4.=A0 "scope" Syntax

=A0

=A0=A0 The "scope" element is defined in Section= 3.3:

=A0

=A0=A0 scope=A0=A0=A0=A0=A0=A0 =3D scope-token *( SP scope= -token )

=A0=A0 scope-token =3D 1*( %x21 / %x23-5B / %x5D-7E )

=A0

A.5.=A0 "state" Syntax

=A0

=A0=A0 The "state" element is defined in Section= 4.1.1, Section 4.1.2,

=A0=A0 Section 4.1.2.1, Section 4.2.1, Section 4.2.2, and = Section 4.2.2.1:<= /u>

=A0

=A0=A0 state=A0=A0=A0=A0=A0 =3D 1*unreserved=

=A0

A.6.=A0 "redirect_uri" Syntax

=A0

=A0=A0 The "redirect_uri" element is defined in = Section 4.1.1,

=A0=A0 Section 4.1.3, and Section 4.2.1:<= /u>

=A0

=A0=A0 redirect-uri=A0=A0=A0=A0=A0 =3D URI

=A0

A.7.=A0 "error" Syntax

=A0

=A0=A0 The "error" element is defined in Section= 4.1.2.1, Section 4.2.2.1,

=A0=A0 Section 5.2, Section 7.2, and Section 8.5:

=A0

=A0=A0 error=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D 1*err= or-char

=A0=A0 error-char=A0=A0=A0=A0=A0=A0=A0 =3D %x20-21 / %x23-= 5B / %x5D-7E

=A0

A.8.=A0 "error_description" Syntax=

=A0

=A0=A0 The "error_description" element is define= d in Section 4.1.2.1,

=A0=A0 Section 4.2.2.1, Section 5.2, and Section 7.2:

=A0

=A0=A0 error-description =3D 1*error-char=

=A0=A0 error-char=A0=A0=A0=A0=A0=A0=A0 =3D %x20-21 / %x23-= 5B / %x5D-7E

=A0

A.9.=A0 "error_uri" Syntax<= /p>

=A0

=A0=A0 The "error_uri" element is defined in Sec= tion 4.1.2.1,

=A0=A0 Section 4.2.2.1, Section 5.2, and Section 7.2:

=A0

=A0=A0 error-uri=A0=A0=A0=A0=A0=A0=A0=A0 =3D URI=

=A0

A.10.=A0 "grant_type" Syntax

=A0

=A0=A0 The "grant_type" element is defined in Se= ction 4.1.3, Section 4.3.2,

=A0=A0 Section 4.4.1, Section 6, and Section 4.5:

=A0

=A0=A0 grant-type =3D grant-name / URI

=A0=A0 grant-name =3D 1*name-char

=A0=A0 name-char=A0 =3D "-" / "." / &q= uot;_" / DIGIT / ALPHA

=A0

A.11.=A0 "code" Syntax

=A0

=A0=A0 The "code" element is defined in Section = 4.1.3:

=A0

=A0=A0 code=A0=A0=A0=A0=A0=A0 =3D 1*unreserved

=A0

A.12.=A0 "access_token" Syntax<= /u>

=A0

=A0=A0 The "access_token" element is defined in = Section 4.2.2 and

=A0=A0 Section 5.1:

=A0

=A0=A0 access-token =3D b64token

=A0

A.13.=A0 "token_type" Syntax

=A0

=A0=A0 The "token_type" element is defined in Se= ction 4.2.2, Section 5.1,

=A0=A0 and Section 8.1:

=A0

=A0=A0 token-type =3D type-name / URI=

=A0=A0 type-name=A0 =3D 1*name-char

=A0=A0 name-char=A0 =3D "-" / "." / &q= uot;_" / DIGIT / ALPHA

=A0

A.14.=A0 "expires_in" Syntax

=A0

=A0=A0 The "expires_in" element is defined in Se= ction 4.2.2 and Section 5.1:

=A0

=A0=A0 expires-in =3D 1*DIGIT

=A0

A.15.=A0 "username" Syntax<= /p>

=A0

=A0=A0 The "username" element is defined in Sect= ion 4.3.2:

=A0

=A0=A0 username =3D *<TEXT excluding ":"><= /span>

=A0

=A0=A0 (This matches the "userid" definition in = the HTTP Basic

=A0=A0 Authentication Scheme [RFC2617].)<= /u>

=A0

A.16.=A0 "password" Syntax<= /p>

=A0

=A0=A0 The "password" element is defined in Sect= ion 4.3.2:

=A0

=A0=A0 password =3D *TEXT

=A0

=A0=A0 (This matches the "password" definition i= n the HTTP Basic

=A0=A0 Authentication Scheme [RFC2617].)<= /u>

=A0

A.17.=A0 "refresh_token" Syntax=

=A0

=A0=A0 The "refresh_token" element is defined in= Section 5.1 and Section 6:

=A0

=A0=A0 refresh-token =3D b64token

=A0

A.18.=A0 Endpoint Parameter Syntax

=A0

=A0=A0 The syntax for new endpoint parameters is defined i= n Section 8.2:

=A0

=A0=A0 param-name =3D 1*name-char

=A0=A0 name-char=A0 =3D "-" / "." / &q= uot;_" / DIGIT / ALPHA

=A0

=A0


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

=A0


--20cf300fafe5f5904704c1acb80c-- From Michael.Jones@microsoft.com Mon Jun 4 15:11:29 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8569221F8589 for ; Mon, 4 Jun 2012 15:11:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.658 X-Spam-Level: X-Spam-Status: No, score=-3.658 tagged_above=-999 required=5 tests=[AWL=-0.060, 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 zXtz6X4-JHdV for ; Mon, 4 Jun 2012 15:11:25 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe003.messaging.microsoft.com [213.199.154.206]) by ietfa.amsl.com (Postfix) with ESMTP id 267B921F854D for ; Mon, 4 Jun 2012 15:11:24 -0700 (PDT) Received: from mail76-am1-R.bigfish.com (10.3.201.231) by AM1EHSOBE001.bigfish.com (10.3.204.21) with Microsoft SMTP Server id 14.1.225.23; Mon, 4 Jun 2012 22:10:43 +0000 Received: from mail76-am1 (localhost [127.0.0.1]) by mail76-am1-R.bigfish.com (Postfix) with ESMTP id 09041C02EF; Mon, 4 Jun 2012 22:10:43 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -37 X-BigFish: VS-37(zz9371Ic85fhcacW4015Izz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25hf0ah) Received-SPF: pass (mail76-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail76-am1 (localhost.localdomain [127.0.0.1]) by mail76-am1 (MessageSwitch) id 1338847841186915_23954; Mon, 4 Jun 2012 22:10:41 +0000 (UTC) Received: from AM1EHSMHS008.bigfish.com (unknown [10.3.201.245]) by mail76-am1.bigfish.com (Postfix) with ESMTP id 2B0BD2E0044; Mon, 4 Jun 2012 22:10:41 +0000 (UTC) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS008.bigfish.com (10.3.207.108) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 4 Jun 2012 22:10:40 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.189]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.02.0298.005; Mon, 4 Jun 2012 22:10:39 +0000 From: Mike Jones To: Eran Hammer , "oauth@ietf.org" Thread-Topic: ABNF elements for suggested WG review Thread-Index: Ac1Alx0u1VneJZSBR8aFxCHOlLRpzQB70KSwAAOx8eA= Date: Mon, 4 Jun 2012 22:10:38 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366529249@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739436652634C@TK5EX14MBXC284.redmond.corp.microsoft.com> <0CBAEB56DDB3A140BA8E8C124C04ECA20105F565@P3PWEX2MB008.ex2.secureserver.net> In-Reply-To: <0CBAEB56DDB3A140BA8E8C124C04ECA20105F565@P3PWEX2MB008.ex2.secureserver.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.19] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394366529249TK5EX14MBXC284r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [OAUTH-WG] ABNF elements for suggested WG review X-BeenThere: oauth@ietf.org X-Mailman-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, 04 Jun 2012 22:11:29 -0000 --_000_4E1F6AAD24975D4BA5B168042967394366529249TK5EX14MBXC284r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The main point of my message was to point out that the working group has no= t discussed the syntax for some the elements identified. I'm glad that it = now is. Actually, the draft already contains or implies syntax restrictions for mor= e fields than you listed, Eran. Let me tackle each field individually and = provide rationale for the choice made and solicit working group input on th= ose where I believe there are open issues. We already had syntax restrictions in place for error, error_description, e= rror_uri, scope, and response_type so I won't discuss those further. The spec already included a syntax for token_type, and the ABNF doesn't dev= iate from it. The grant_type element is logically the same kind of object = as token_type, so it makes sense to use the same syntax. I don't see a case for having expires_in contain anything but 1*DIGIT, so I= don't see that as being controversial. For redirect_uri, since it is a URI, I believe that URI-reference makes sen= se. For username and password, the spec mandates that they be used with HTTP Ba= sic, thus implicitly restricting their legal values. (Per my earlier respo= nse to Julian, RFC 2616 effectively limits these characters to be the ISO-8= 859-1 characters other than control characters but including LWS characters= .) HTTP Basic further restricts the username field to not contain a colon = (':'). In short, I believe that the OAuth core already implicitly contains= the specified character set restrictions. Since client_id and client_secret are parallel to username and password, it= would be inconsistent to use different character set restrictions for them= . (On the other hand, Brian Campbell referenced a case where a client_id m= ight be a URL, in which case colon would be required. That seems like a re= asonable usage, so the syntax restriction on client_id probably needs to be= relaxed. WG thoughts on the correct syntax? Should it just be TEXT?) That leaves state, code, access_token, and refresh_token as the remaining e= lements that genuinely need working group discussion. The ABNF currently r= estricts these to character sets that don't require encodings. Should it, = or like client_id, should we likely expand the sets? If so, is TEXT with I= SO-8859-1 encoding the right ABNF definition for them, given that they can = all be used in contexts where MIME encodings aren't specified? Thanks all, -- Mike From: Eran Hammer [mailto:eran@hueniverse.com] Sent: Monday, June 04, 2012 12:17 PM To: Mike Jones; oauth@ietf.org Subject: RE: ABNF elements for suggested WG review The ABNF must reflect the existing draft, not invent new restrictions. The = only field we had consensus for applying new restrictions on is error (and = the related ones from bearer). That's it. Please have the proposed ABNF ref= lect the unrestricted nature of all values not explicitly defined otherwise= . EH From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Mike = Jones Sent: Saturday, June 02, 2012 1:10 AM To: oauth@ietf.org Subject: [OAUTH-WG] ABNF elements for suggested WG review Dear working group, It turns out that writing an ABNF for the Core spec pointed out that the sy= ntax of a number of the OAuth protocol elements had not been previously def= ined. (Thanks, Sean, for having us do this!) I took a stab at specifying = appropriate ABNF values for each of the protocol elements, but I would requ= est that the working group actively review the choices in my proposed draft= . For instance, I chose to use the same syntax definitions for username and p= assword and client_id and client_secret as HTTP Basic used for userid and p= assword. Other choices were possible, such as perhaps limiting client_id a= nd possibly username values to use "unreserved" characters, rather than all= owing all characters other than ":" (as HTTP Basic did with userid). Please particularly review the syntax definitions for these elements, as I = had to make choices that went beyond the current specs to provide unambiguo= us syntax definitions: client_id client_secret state code access_token username password refresh_token The full proposed ABNF section follows. -- Mike Appendix A. Augmented Backus-Naur Form (ABNF) Syntax This section provides Augmented Backus-Naur Form (ABNF) syntax descriptions for the elements defined in this specification using the notation of [RFC5234]. Elements are presented in the order first defined. Some of the definitions that follow use the "unreserved" and "URI" definitions from [RFC3986], which are: unreserved =3D ALPHA / DIGIT / "-" / "." / "_" / "~" URI =3D scheme ":" hier-part [ "?" query ] [ "#" fragment ] Some of the definitions that follow use the "b64token" syntax below, which matches the "b64token" syntax defined by HTTP/1.1, Part 7 [I-D.ietf-httpbis-p7-auth]: b64token =3D 1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" ) *"=3D" A.1. "client_id" Syntax The "client_id" element is defined in Section 2.3.1: client-id =3D * (This matches the "userid" definition in the HTTP Basic Authentication Scheme [RFC2617].) A.2. "client_secret" Syntax The "client_secret" element is defined in Section 2.3.1: client-secret =3D *TEXT (This matches the "password" definition in the HTTP Basic Authentication Scheme [RFC2617].) A.3. "response_type" Syntax The "response_type" element is defined in Section 3.1.1 and Section 8.4: response-type =3D response-name *( SP response-name ) response-name =3D 1*response-char response-char =3D "_" / DIGIT / ALPHA A.4. "scope" Syntax The "scope" element is defined in Section 3.3: scope =3D scope-token *( SP scope-token ) scope-token =3D 1*( %x21 / %x23-5B / %x5D-7E ) A.5. "state" Syntax The "state" element is defined in Section 4.1.1, Section 4.1.2, Section 4.1.2.1, Section 4.2.1, Section 4.2.2, and Section 4.2.2.1: state =3D 1*unreserved A.6. "redirect_uri" Syntax The "redirect_uri" element is defined in Section 4.1.1, Section 4.1.3, and Section 4.2.1: redirect-uri =3D URI A.7. "error" Syntax The "error" element is defined in Section 4.1.2.1, Section 4.2.2.1, Section 5.2, Section 7.2, and Section 8.5: error =3D 1*error-char error-char =3D %x20-21 / %x23-5B / %x5D-7E A.8. "error_description" Syntax The "error_description" element is defined in Section 4.1.2.1, Section 4.2.2.1, Section 5.2, and Section 7.2: error-description =3D 1*error-char error-char =3D %x20-21 / %x23-5B / %x5D-7E A.9. "error_uri" Syntax The "error_uri" element is defined in Section 4.1.2.1, Section 4.2.2.1, Section 5.2, and Section 7.2: error-uri =3D URI A.10. "grant_type" Syntax The "grant_type" element is defined in Section 4.1.3, Section 4.3.2, Section 4.4.1, Section 6, and Section 4.5: grant-type =3D grant-name / URI grant-name =3D 1*name-char name-char =3D "-" / "." / "_" / DIGIT / ALPHA A.11. "code" Syntax The "code" element is defined in Section 4.1.3: code =3D 1*unreserved A.12. "access_token" Syntax The "access_token" element is defined in Section 4.2.2 and Section 5.1: access-token =3D b64token A.13. "token_type" Syntax The "token_type" element is defined in Section 4.2.2, Section 5.1, and Section 8.1: token-type =3D type-name / URI type-name =3D 1*name-char name-char =3D "-" / "." / "_" / DIGIT / ALPHA A.14. "expires_in" Syntax The "expires_in" element is defined in Section 4.2.2 and Section 5.1: expires-in =3D 1*DIGIT A.15. "username" Syntax The "username" element is defined in Section 4.3.2: username =3D * (This matches the "userid" definition in the HTTP Basic Authentication Scheme [RFC2617].) A.16. "password" Syntax The "password" element is defined in Section 4.3.2: password =3D *TEXT (This matches the "password" definition in the HTTP Basic Authentication Scheme [RFC2617].) A.17. "refresh_token" Syntax The "refresh_token" element is defined in Section 5.1 and Section 6: refresh-token =3D b64token A.18. Endpoint Parameter Syntax The syntax for new endpoint parameters is defined in Section 8.2: param-name =3D 1*name-char name-char =3D "-" / "." / "_" / DIGIT / ALPHA --_000_4E1F6AAD24975D4BA5B168042967394366529249TK5EX14MBXC284r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The main point of my m= essage was to point out that the working group has not discussed the syntax= for some the elements identified.  I’m glad that it now is.

 

Actually, the draft al= ready contains or implies syntax restrictions for more fields than you list= ed, Eran.  Let me tackle each field individually and provide rationale= for the choice made and solicit working group input on those where I believe there are open issues.

 

We already had syntax = restrictions in place for error, error_description, error_uri, scope, and= response_type so I won’t discuss those further.

 

The spec already inclu= ded a syntax for token_type, and the ABNF doesn’t deviate from it.  The grant_type element is logically the same kind of object as token_type,= so it makes sense to use the same syntax.

 

I don’t see a ca= se for having expires_in contain anything but 1*DIGIT, so I don’t see that as b= eing controversial.

 

For redirect_uri, since it is a URI, I believe that URI-reference makes sense.<= /span>

 

For username an= d password, the spec mandates that they be used with HTTP Basic, thu= s implicitly restricting their legal values.  (Per my earlier response= to Julian, RFC 2616 effectively limits these characters to be the ISO-8859-1 characters other than control characters b= ut including LWS characters.)  HTTP Basic further restricts the userna= me field to not contain a colon (‘:’).  In short, I believ= e that the OAuth core already implicitly contains the specified character set restrictions.

 

Since client_id= and client_secret are parallel to username and password, it would b= e inconsistent to use different character set restrictions for them.  = (On the other hand, Brian Campbell referenced a case where a client_id might be a URL, in which case colon would be requ= ired.  That seems like a reasonable usage, so the syntax restriction o= n client_id probably needs to be relaxed.  WG thoughts on the correct = syntax?  Should it just be TEXT?)

 

That leaves state, code, access_token, and refresh_token as the remaining elements tha= t genuinely need working group discussion.  The ABNF currently restric= ts these to character sets that don’t require encodings.  Should= it, or like client_id, should we likely expand the sets?  If so, is TEXT with ISO-8859-1 encoding the right ABNF def= inition for them, given that they can all be used in contexts where MIME en= codings aren’t specified?

 

   &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;          Thanks all,

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

 

From: Eran Ham= mer [mailto:eran@hueniverse.com]
Sent: Monday, June 04, 2012 12:17 PM
To: Mike Jones; oauth@ietf.org
Subject: RE: ABNF elements for suggested WG review=

 

The ABNF must reflect = the existing draft, not invent new restrictions. The only field we had cons= ensus for applying new restrictions on is error (and the related ones from = bearer). That’s it. Please have the proposed ABNF reflect the unrestricted nature of all values not explicitly= defined otherwise.

 

EH

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Saturday, June 02, 2012 1:10 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] ABNF elements for suggested WG review=

 

Dear working group,

 

It turns out that writing an ABNF for the Core spec = pointed out that the syntax of a number of the OAuth protocol elements had = not been previously defined.  (Thanks, Sean, for having us do this!)&n= bsp; I took a stab at specifying appropriate ABNF values for each of the protocol elements, but I would request that th= e working group actively review the choices in my proposed draft.

 

For instance, I chose to use the same syntax definit= ions for username and password and client_id and client_secret as HTTP Basi= c used for userid and password.  Other choices were possible, such as = perhaps limiting client_id and possibly username values to use “unreserved” characters, rather than al= lowing all characters other than “:” (as HTTP Basic did with us= erid).

 

Please particularly review the syntax definitions fo= r these elements, as I had to make choices that went beyond the current spe= cs to provide unambiguous syntax definitions:

        &nbs= p;      client_id

        &nbs= p;      client_secret

        &nbs= p;      state

        &nbs= p;      code

        &nbs= p;      access_token

        &nbs= p;      username

        &nbs= p;      password

        &nbs= p;      refresh_token

 

The full proposed ABNF section follows.

 

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

 

Appendix A.  Augmented Backus-Naur Form (ABNF) Syntax=

 

   This section provides Augmented Backus-Naur F= orm (ABNF) syntax

   descriptions for the elements defined in this= specification using the

   notation of [RFC5234].  Elements are pre= sented in the order first

   defined.

 

   Some of the definitions that follow use the &= quot;unreserved" and "URI"

   definitions from [RFC3986], which are:

 

   unreserved =3D ALPHA / DIGIT / "-" = / "." / "_" / "~"

   URI       = =3D scheme ":" hier-part [ "?" query ] [ "#"= fragment ]

 

   Some of the definitions that follow use the &= quot;b64token" syntax below,

   which matches the "b64token" syntax= defined by HTTP/1.1, Part 7

   [I-D.ietf-httpbis-p7-auth]:=

 

   b64token   =3D 1*( ALPHA / DIGIT /<= o:p>

         &nbs= p;          "-" / &q= uot;." / "_" / "~" / "+" / "/&q= uot; ) *"=3D"

 

A.1.  "client_id" Syntax<= /p>

 

   The "client_id" element is defined = in Section 2.3.1:

 

   client-id     =3D *<TE= XT excluding ":">

 

   (This matches the "userid" definiti= on in the HTTP Basic

   Authentication Scheme [RFC2617].)<= /span>

 

A.2.  "client_secret" Syntax

 

   The "client_secret" element is defi= ned in Section 2.3.1:

 

   client-secret =3D *TEXT

 

   (This matches the "password" defini= tion in the HTTP Basic

   Authentication Scheme [RFC2617].)<= /span>

 

A.3.  "response_type" Syntax

 

   The "response_type" element is defi= ned in Section 3.1.1 and

   Section 8.4:

 

   response-type =3D response-name *( SP respons= e-name )

   response-name =3D 1*response-char<= /span>

   response-char =3D "_" / DIGIT / ALP= HA

 

A.4.  "scope" Syntax

 

   The "scope" element is defined in S= ection 3.3:

 

   scope       =3D= scope-token *( SP scope-token )

   scope-token =3D 1*( %x21 / %x23-5B / %x5D-7E = )

 

A.5.  "state" Syntax

 

   The "state" element is defined in S= ection 4.1.1, Section 4.1.2,

   Section 4.1.2.1, Section 4.2.1, Section 4.2.2= , and Section 4.2.2.1:

 

   state      =3D 1*unr= eserved

 

A.6.  "redirect_uri" Syntax

 

   The "redirect_uri" element is defin= ed in Section 4.1.1,

   Section 4.1.3, and Section 4.2.1:<= /span>

 

   redirect-uri      = =3D URI

 

A.7.  "error" Syntax

 

   The "error" element is defined in S= ection 4.1.2.1, Section 4.2.2.1,

   Section 5.2, Section 7.2, and Section 8.5:

 

   error      &nbs= p;      =3D 1*error-char

   error-char      = ;  =3D %x20-21 / %x23-5B / %x5D-7E

 

A.8.  "error_description" Syntax=

 

   The "error_description" element is = defined in Section 4.1.2.1,

   Section 4.2.2.1, Section 5.2, and Section 7.2= :

 

   error-description =3D 1*error-char=

   error-char      = ;  =3D %x20-21 / %x23-5B / %x5D-7E

 

A.9.  "error_uri" Syntax<= /p>

 

   The "error_uri" element is defined = in Section 4.1.2.1,

   Section 4.2.2.1, Section 5.2, and Section 7.2= :

 

   error-uri      =    =3D URI

 

A.10.  "grant_type" Syntax

 

   The "grant_type" element is defined= in Section 4.1.3, Section 4.3.2,

   Section 4.4.1, Section 6, and Section 4.5:

 

   grant-type =3D grant-name / URI

   grant-name =3D 1*name-char<= /p>

   name-char  =3D "-" / ".&q= uot; / "_" / DIGIT / ALPHA

 

A.11.  "code" Syntax

 

   The "code" element is defined in Se= ction 4.1.3:

 

   code       =3D = 1*unreserved

 

A.12.  "access_token" Syntax

 

   The "access_token" element is defin= ed in Section 4.2.2 and

   Section 5.1:

 

   access-token =3D b64token

 

A.13.  "token_type" Syntax

 

   The "token_type" element is defined= in Section 4.2.2, Section 5.1,

   and Section 8.1:

 

   token-type =3D type-name / URI

   type-name  =3D 1*name-char

   name-char  =3D "-" / ".&q= uot; / "_" / DIGIT / ALPHA

 

A.14.  "expires_in" Syntax

 

   The "expires_in" element is defined= in Section 4.2.2 and Section 5.1:

 

   expires-in =3D 1*DIGIT

 

A.15.  "username" Syntax<= /p>

 

   The "username" element is defined i= n Section 4.3.2:

 

   username =3D *<TEXT excluding ":"= ;>

 

   (This matches the "userid" definiti= on in the HTTP Basic

   Authentication Scheme [RFC2617].)<= /span>

 

A.16.  "password" Syntax<= /p>

 

   The "password" element is defined i= n Section 4.3.2:

 

   password =3D *TEXT

 

   (This matches the "password" defini= tion in the HTTP Basic

   Authentication Scheme [RFC2617].)<= /span>

 

A.17.  "refresh_token" Syntax

 

   The "refresh_token" element is defi= ned in Section 5.1 and Section 6:

 

   refresh-token =3D b64token<= /p>

 

A.18.  Endpoint Parameter Syntax

 

   The syntax for new endpoint parameters is def= ined in Section 8.2:

 

   param-name =3D 1*name-char<= /p>

   name-char  =3D "-" / ".&q= uot; / "_" / DIGIT / ALPHA

 

 

--_000_4E1F6AAD24975D4BA5B168042967394366529249TK5EX14MBXC284r_-- From Michael.Jones@microsoft.com Mon Jun 4 15:13:26 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33BA621F871C for ; Mon, 4 Jun 2012 15:13:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.157 X-Spam-Level: X-Spam-Status: No, score=-5.157 tagged_above=-999 required=5 tests=[AWL=1.442, 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 VdtPB8LkBx-e for ; Mon, 4 Jun 2012 15:13:25 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe002.messaging.microsoft.com [65.55.88.12]) by ietfa.amsl.com (Postfix) with ESMTP id 7D9C921F870E for ; Mon, 4 Jun 2012 15:13:25 -0700 (PDT) Received: from mail23-tx2-R.bigfish.com (10.9.14.235) by TX2EHSOBE005.bigfish.com (10.9.40.25) with Microsoft SMTP Server id 14.1.225.23; Mon, 4 Jun 2012 22:12:45 +0000 Received: from mail23-tx2 (localhost [127.0.0.1]) by mail23-tx2-R.bigfish.com (Postfix) with ESMTP id CBDAA60228; Mon, 4 Jun 2012 22:12:44 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -27 X-BigFish: VS-27(zz9371I14ffI542Mzz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25hf0ah) Received-SPF: pass (mail23-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC103.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail23-tx2 (localhost.localdomain [127.0.0.1]) by mail23-tx2 (MessageSwitch) id 133884796322919_3333; Mon, 4 Jun 2012 22:12:43 +0000 (UTC) Received: from TX2EHSMHS039.bigfish.com (unknown [10.9.14.238]) by mail23-tx2.bigfish.com (Postfix) with ESMTP id 02DB318004A; Mon, 4 Jun 2012 22:12:43 +0000 (UTC) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS039.bigfish.com (10.9.99.139) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 4 Jun 2012 22:12:42 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.189]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.02.0298.005; Mon, 4 Jun 2012 22:12:24 +0000 From: Mike Jones To: Hannes Tschofenig , "oauth@ietf.org WG" Thread-Topic: [OAUTH-WG] Meeting slot for the Vancouver IETF meeting requested Thread-Index: AQHNQJPQNMAQIgZ/gke413DmiJD+qZbqvNHw Date: Mon, 4 Jun 2012 22:12:24 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366529295@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <09CE58C6-9409-4E28-B4CA-DC76C37B898E@gmx.net> In-Reply-To: <09CE58C6-9409-4E28-B4CA-DC76C37B898E@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [OAUTH-WG] Meeting slot for the Vancouver IETF meeting requested X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 22:13:26 -0000 I'll be there in person and available to present. I'll work with the chair= s on what presentations they'd like me to give or participate in. -- Mike -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of H= annes Tschofenig Sent: Saturday, June 02, 2012 12:46 AM To: oauth@ietf.org WG Subject: [OAUTH-WG] Meeting slot for the Vancouver IETF meeting requested Hi all,=20 I have requested a 2,5 hour slot for the upcoming meeting.=20 While the next meeting is still a bit away it is nevertheless useful to hea= r=20 * whether you plan to attend the next meeting, and=20 * whether you want to present something.=20 I could imagine that these documents will be discussed: * draft-ietf-oauth-dyn-reg * draft-ietf-oauth-json-web-token * draft-ietf-oauth-jwt-bearer * draft-ietf-oauth-revocation * draft-ietf-oauth-use-cases To the draft authors of these docuemnts: Please think about the open issues= and drop a mail to the list so that we make some progress already before t= he face-to-face meeting.=20 I am assume that the following documents do not require any discussion time= at the upcoming IETF meeting anymore: * draft-ietf-oauth-assertions * draft-ietf-oauth-saml2-bearer * draft-ietf-oauth-urn-sub-ns * draft-ietf-oauth-v2 * draft-ietf-oauth-v2-bearer Ciao Hannes _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From wmills@yahoo-inc.com Mon Jun 4 15:24:49 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2587221F85F4 for ; Mon, 4 Jun 2012 15:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.115 X-Spam-Level: X-Spam-Status: No, score=-17.115 tagged_above=-999 required=5 tests=[AWL=0.483, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9utjYl8+AUci for ; Mon, 4 Jun 2012 15:24:47 -0700 (PDT) Received: from nm3-vm0.bullet.mail.sp2.yahoo.com (nm3-vm0.bullet.mail.sp2.yahoo.com [98.139.90.230]) by ietfa.amsl.com (Postfix) with SMTP id 586C421F83EF for ; Mon, 4 Jun 2012 15:24:46 -0700 (PDT) Received: from [72.30.22.93] by nm3.bullet.mail.sp2.yahoo.com with NNFMP; 04 Jun 2012 22:24:42 -0000 Received: from [98.139.91.11] by tm15.bullet.mail.sp2.yahoo.com with NNFMP; 04 Jun 2012 22:24:42 -0000 Received: from [127.0.0.1] by omp1011.mail.sp2.yahoo.com with NNFMP; 04 Jun 2012 22:24:42 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 496704.54164.bm@omp1011.mail.sp2.yahoo.com Received: (qmail 92194 invoked by uid 60001); 4 Jun 2012 22:24:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1338848681; bh=59uBfzKuOzf9cfm1UUHYQwINEuBdLMTZGJA265G1bMQ=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=dRWW9BoQEW0Q/i24WgtQwwU8jP7ZogKi7R0guRHBjJZU72u+W0oaiz13mPjpsLkJJAKymHzU8Q3LbwwLXA3rIG2jCwC+axm+P54siT06/YpqjE7Mf5e0WcItWoXlrP7LKRSDj2A7z3UWmMiEL6rfm8rWAcOEAk2BHAvaezSSweE= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=PlllXR7po4ySTqUkULBeagm4zrZCXzZYi3vAr077zgt01skba+d/n0mkpL6Yi/JzEjlCbAHqcqWG+BW9qujDXQhv85uiJkYbgZ4Xh4tGkxsIWb9GQBKQ2Je/9aWNxcrhhpcodzP7+F4XV1ie/a3vYxgJ/HMXz55YBdGq5O+AzAo=; X-YMail-OSG: iKflZBsVM1lIemnKUd12a3YeLGZQcJFkk2CzrGKZNRl6N1b JMsGSqtC_bRxtmswVHX_Qn7pD2ADeH69WPW6XVAf6igOXdGuE.xJlxO1fuWF mg0ibHQeEw9C54mlsOf6Wy0TcszNgJWY44QUfmL480iFAYI4UHhJB8DLFIIk rZp0XrPyf56H6xGW2kMaAi57P4M10SGCS_ZIqbffVAjHw6QoD2aNZ2f_tBEx yScdUIaIyHxxOgB_T3EH_RSUHbzLMFpxZXYPkWrHukNlOwyghAtYUIzHM_B3 vxl5tdeWmriW_96xKesDVovZvw189ZraAC_y8aOtz3kyJBAUkNAmjCc80HoZ RpaHUDlA2P8n7Xi80ZQazVn.cmuWx5mHmmuPuuUlyhPKv0S4F2.zcTEMDdpi ewRSPUIy2MiitWqUiawWt1ejmJnZSvcRdJ8m5.62p3kldAgQ_vZXokCmUa16 BVakbn0jC8J7kQfMr0o4e60mxTlov8uUf_Jp7j9F7lCe7k9fv Received: from [209.131.62.115] by web31803.mail.mud.yahoo.com via HTTP; Mon, 04 Jun 2012 15:24:41 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.118.349524 References: <4E1F6AAD24975D4BA5B16804296739436652634C@TK5EX14MBXC284.redmond.corp.microsoft.com> <0CBAEB56DDB3A140BA8E8C124C04ECA20105F565@P3PWEX2MB008.ex2.secureserver.net> <4E1F6AAD24975D4BA5B168042967394366529249@TK5EX14MBXC284.redmond.corp.microsoft.com> Message-ID: <1338848681.63031.YahooMailNeo@web31803.mail.mud.yahoo.com> Date: Mon, 4 Jun 2012 15:24:41 -0700 (PDT) From: William Mills To: Mike Jones , Eran Hammer , "oauth@ietf.org" In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366529249@TK5EX14MBXC284.redmond.corp.microsoft.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1502656925-624483912-1338848681=:63031" Subject: Re: [OAUTH-WG] ABNF elements for suggested WG review X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 22:24:49 -0000 --1502656925-624483912-1338848681=:63031 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Do we want to make expires_in not have zeroes?=C2=A0 Or am I being to OCD o= n this?=0A=0A-bill=0A=0A=0A=0A=0A>________________________________=0A> From= : Mike Jones =0A>To: Eran Hammer ; "oauth@ietf.org" =0A>Sent: Monday, June 4, 2012 = 3:10 PM=0A>Subject: Re: [OAUTH-WG] ABNF elements for suggested WG review=0A= > =0A>=0A> =0A>The main point of my message was to point out that the worki= ng group has not discussed the syntax for some the elements identified.=C2= =A0 I=E2=80=99m glad that it now is.=0A>=C2=A0=0A>Actually, the draft alrea= dy contains or implies syntax restrictions for more fields than you listed,= Eran. =C2=A0Let me tackle each field individually and provide rationale fo= r the choice made and solicit working group input on those where I believe = there are open issues.=0A>=C2=A0=0A>We already had syntax restrictions in p= lace for error, error_description, error_uri, scope, and response_type so I= won=E2=80=99t discuss those further.=0A>=C2=A0=0A>The spec already include= d a syntax for token_type, and the ABNF doesn=E2=80=99t deviate from it.=C2= =A0 The grant_type element is logically the same kind of object as token_ty= pe, so it makes sense to use the same syntax.=0A>=C2=A0=0A>I don=E2=80=99t = see a case for having expires_in contain anything but 1*DIGIT, so I don=E2= =80=99t see that as being controversial.=0A>=C2=A0=0A>For redirect_uri, sin= ce it is a URI, I believe that URI-reference makes sense.=0A>=C2=A0=0A>For = username and password, the spec mandates that they be used with HTTP Basic,= thus implicitly restricting their legal values.=C2=A0 (Per my earlier resp= onse to Julian, RFC 2616 effectively limits these characters to be the ISO-= 8859-1 characters other than control characters but including LWS character= s.)=C2=A0 HTTP Basic further restricts the username field to not contain a = colon (=E2=80=98:=E2=80=99).=C2=A0 In short, I believe that the OAuth core = already implicitly contains the specified character set restrictions.=0A>= =C2=A0=0A>Since client_id and client_secret are parallel to username and pa= ssword, it would be inconsistent to use different character set restriction= s for them.=C2=A0 (On the other hand, Brian Campbell referenced a case wher= e a client_id might be a URL, in which case colon would be required.=C2=A0 = That seems like a reasonable usage, so the syntax restriction on client_id = probably needs to be relaxed.=C2=A0 WG thoughts on the correct syntax?=C2= =A0 Should it just be TEXT?)=0A>=C2=A0=0A>That leaves state, code, access_t= oken, and refresh_token as the remaining elements that genuinely need worki= ng group discussion.=C2=A0 The ABNF currently restricts these to character = sets that don=E2=80=99t require encodings.=C2=A0 Should it, or like client_= id, should we likely expand the sets?=C2=A0 If so, is TEXT with ISO-8859-1 = encoding the right ABNF definition for them, given that they can all be use= d in contexts where MIME encodings aren=E2=80=99t specified?=0A>=C2=A0=0A>= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Thanks all,=0A>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 -- Mike=0A>=C2=A0=0A>From:Eran Hammer [mailto:eran= @hueniverse.com] =0A>Sent: Monday, June 04, 2012 12:17 PM=0A>To: Mike Jones= ; oauth@ietf.org=0A>Subject: RE: ABNF elements for suggested WG review=0A>= =C2=A0=0A>The ABNF must reflect the existing draft, not invent new restrict= ions. The only field we had consensus for applying new restrictions on is e= rror (and the related ones from bearer). That=E2=80=99s it. Please have the= proposed ABNF reflect the unrestricted nature of all values not explicitly= defined otherwise.=0A>=C2=A0=0A>EH=0A>=C2=A0=0A>From:oauth-bounces@ietf.or= g [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones=0A>Sent: Saturday= , June 02, 2012 1:10 AM=0A>To: oauth@ietf.org=0A>Subject: [OAUTH-WG] ABNF e= lements for suggested WG review=0A>=C2=A0=0A>Dear working group,=0A>=C2=A0= =0A>It turns out that writing an ABNF for the Core spec pointed out that th= e syntax of a number of the OAuth protocol elements had not been previously= defined.=C2=A0 (Thanks, Sean, for having us do this!)=C2=A0 I took a stab = at specifying appropriate ABNF values for each of the protocol elements, bu= t I would request that the working group actively review the choices in my = proposed draft.=0A>=C2=A0=0A>For instance, I chose to use the same syntax d= efinitions for username and password and client_id and client_secret as HTT= P Basic used for userid and password.=C2=A0 Other choices were possible, su= ch as perhaps limiting client_id and possibly username values to use =E2=80= =9Cunreserved=E2=80=9D characters, rather than allowing all characters othe= r than =E2=80=9C:=E2=80=9D (as HTTP Basic did with userid).=0A>=C2=A0=0A>Pl= ease particularly review the syntax definitions for these elements, as I ha= d to make choices that went beyond the current specs to provide unambiguous= syntax definitions:=0A>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 client_id=0A>=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 client_secret=0A>= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 state=0A>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 code=0A>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 access_token=0A>=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= username=0A>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 password=0A>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 refresh_token=0A>=C2=A0=0A= >The full proposed ABNF section follows.=0A>=C2=A0=0A>=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike=0A>=C2=A0=0A>Appendix A.=C2=A0 Au= gmented Backus-Naur Form (ABNF) Syntax=0A>=C2=A0=0A>=C2=A0=C2=A0 This secti= on provides Augmented Backus-Naur Form (ABNF) syntax=0A>=C2=A0=C2=A0 descri= ptions for the elements defined in this specification using the=0A>=C2=A0= =C2=A0 notation of [RFC5234].=C2=A0 Elements are presented in the order fir= st=0A>=C2=A0=C2=A0 defined.=0A>=C2=A0=0A>=C2=A0=C2=A0 Some of the definitio= ns that follow use the "unreserved" and "URI"=0A>=C2=A0=C2=A0 definitions f= rom [RFC3986], which are:=0A>=C2=A0=0A>=C2=A0=C2=A0 unreserved =3D ALPHA / = DIGIT / "-" / "." / "_" / "~"=0A>=C2=A0=C2=A0 URI=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 =3D scheme ":" hier-part [ "?" query ] [ "#" fragment ]= =0A>=C2=A0=0A>=C2=A0=C2=A0 Some of the definitions that follow use the "b64= token" syntax below,=0A>=C2=A0=C2=A0 which matches the "b64token" syntax de= fined by HTTP/1.1, Part 7=0A>=C2=A0=C2=A0 [I-D.ietf-httpbis-p7-auth]:=0A>= =C2=A0=0A>=C2=A0=C2=A0 b64token=C2=A0=C2=A0 =3D 1*( ALPHA / DIGIT /=0A>=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "-" / "." / "_" / "~" / "+" / "/" ) *"= =3D"=0A>=C2=A0=0A>A.1.=C2=A0 "client_id" Syntax=0A>=C2=A0=0A>=C2=A0=C2=A0 T= he "client_id" element is defined in Section 2.3.1:=0A>=C2=A0=0A>=C2=A0=C2= =A0 client-id=C2=A0=C2=A0=C2=A0=C2=A0 =3D *=0A>=C2=A0= =0A>=C2=A0=C2=A0 (This matches the "userid" definition in the HTTP Basic=0A= >=C2=A0=C2=A0 Authentication Scheme [RFC2617].)=0A>=C2=A0=0A>A.2.=C2=A0 "cl= ient_secret" Syntax=0A>=C2=A0=0A>=C2=A0=C2=A0 The "client_secret" element i= s defined in Section 2.3.1:=0A>=C2=A0=0A>=C2=A0=C2=A0 client-secret =3D *TE= XT=0A>=C2=A0=0A>=C2=A0=C2=A0 (This matches the "password" definition in the= HTTP Basic=0A>=C2=A0=C2=A0 Authentication Scheme [RFC2617].)=0A>=C2=A0=0A>= A.3.=C2=A0 "response_type" Syntax=0A>=C2=A0=0A>=C2=A0=C2=A0 The "response_t= ype" element is defined in Section 3.1.1 and=0A>=C2=A0=C2=A0 Section 8.4:= =0A>=C2=A0=0A>=C2=A0=C2=A0 response-type =3D response-name *( SP response-n= ame )=0A>=C2=A0=C2=A0 response-name =3D 1*response-char=0A>=C2=A0=C2=A0 res= ponse-char =3D "_" / DIGIT / ALPHA=0A>=C2=A0=0A>A.4.=C2=A0 "scope" Syntax= =0A>=C2=A0=0A>=C2=A0=C2=A0 The "scope" element is defined in Section 3.3:= =0A>=C2=A0=0A>=C2=A0=C2=A0 scope=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D sc= ope-token *( SP scope-token )=0A>=C2=A0=C2=A0 scope-token =3D 1*( %x21 / %x= 23-5B / %x5D-7E )=0A>=C2=A0=0A>A.5.=C2=A0 "state" Syntax=0A>=C2=A0=0A>=C2= =A0=C2=A0 The "state" element is defined in Section 4.1.1, Section 4.1.2,= =0A>=C2=A0=C2=A0 Section 4.1.2.1, Section 4.2.1, Section 4.2.2, and Section= 4.2.2.1:=0A>=C2=A0=0A>=C2=A0=C2=A0 state=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D= 1*unreserved=0A>=C2=A0=0A>A.6.=C2=A0 "redirect_uri" Syntax=0A>=C2=A0=0A>= =C2=A0=C2=A0 The "redirect_uri" element is defined in Section 4.1.1,=0A>=C2= =A0=C2=A0 Section 4.1.3, and Section 4.2.1:=0A>=C2=A0=0A>=C2=A0=C2=A0 redir= ect-uri=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D URI=0A>=C2=A0=0A>A.7.=C2=A0 "erro= r" Syntax=0A>=C2=A0=0A>=C2=A0=C2=A0 The "error" element is defined in Secti= on 4.1.2.1, Section 4.2.2.1,=0A>=C2=A0=C2=A0 Section 5.2, Section 7.2, and = Section 8.5:=0A>=C2=A0=0A>=C2=A0=C2=A0 error=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D 1*error-char=0A>=C2=A0=C2=A0= error-char=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D %x20-21 / %x23-5B= / %x5D-7E=0A>=C2=A0=0A>A.8.=C2=A0 "error_description" Syntax=0A>=C2=A0=0A>= =C2=A0=C2=A0 The "error_description" element is defined in Section 4.1.2.1,= =0A>=C2=A0=C2=A0 Section 4.2.2.1, Section 5.2, and Section 7.2:=0A>=C2=A0= =0A>=C2=A0=C2=A0 error-description =3D 1*error-char=0A>=C2=A0=C2=A0 error-c= har=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D %x20-21 / %x23-5B / %x5D-= 7E=0A>=C2=A0=0A>A.9.=C2=A0 "error_uri" Syntax=0A>=C2=A0=0A>=C2=A0=C2=A0 The= "error_uri" element is defined in Section 4.1.2.1,=0A>=C2=A0=C2=A0 Section= 4.2.2.1, Section 5.2, and Section 7.2:=0A>=C2=A0=0A>=C2=A0=C2=A0 error-uri= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D URI=0A>=C2=A0=0A>A.10.= =C2=A0 "grant_type" Syntax=0A>=C2=A0=0A>=C2=A0=C2=A0 The "grant_type" eleme= nt is defined in Section 4.1.3, Section 4.3.2,=0A>=C2=A0=C2=A0 Section 4.4.= 1, Section 6, and Section 4.5:=0A>=C2=A0=0A>=C2=A0=C2=A0 grant-type =3D gra= nt-name / URI=0A>=C2=A0=C2=A0 grant-name =3D 1*name-char=0A>=C2=A0=C2=A0 na= me-char=C2=A0 =3D "-" / "." / "_" / DIGIT / ALPHA=0A>=C2=A0=0A>A.11.=C2=A0 = "code" Syntax=0A>=C2=A0=0A>=C2=A0=C2=A0 The "code" element is defined in Se= ction 4.1.3:=0A>=C2=A0=0A>=C2=A0=C2=A0 code=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 =3D 1*unreserved=0A>=C2=A0=0A>A.12.=C2=A0 "access_token" Syntax=0A>= =C2=A0=0A>=C2=A0=C2=A0 The "access_token" element is defined in Section 4.2= .2 and=0A>=C2=A0=C2=A0 Section 5.1:=0A>=C2=A0=0A>=C2=A0=C2=A0 access-token = =3D b64token=0A>=C2=A0=0A>A.13.=C2=A0 "token_type" Syntax=0A>=C2=A0=0A>=C2= =A0=C2=A0 The "token_type" element is defined in Section 4.2.2, Section 5.1= ,=0A>=C2=A0=C2=A0 and Section 8.1:=0A>=C2=A0=0A>=C2=A0=C2=A0 token-type =3D= type-name / URI=0A>=C2=A0=C2=A0 type-name=C2=A0 =3D 1*name-char=0A>=C2=A0= =C2=A0 name-char=C2=A0 =3D "-" / "." / "_" / DIGIT / ALPHA=0A>=C2=A0=0A>A.1= 4.=C2=A0 "expires_in" Syntax=0A>=C2=A0=0A>=C2=A0=C2=A0 The "expires_in" ele= ment is defined in Section 4.2.2 and Section 5.1:=0A>=C2=A0=0A>=C2=A0=C2=A0= expires-in =3D 1*DIGIT=0A>=C2=A0=0A>A.15.=C2=A0 "username" Syntax=0A>=C2= =A0=0A>=C2=A0=C2=A0 The "username" element is defined in Section 4.3.2:=0A>= =C2=A0=0A>=C2=A0=C2=A0 username =3D *=0A>=C2=A0=0A>=C2= =A0=C2=A0 (This matches the "userid" definition in the HTTP Basic=0A>=C2=A0= =C2=A0 Authentication Scheme [RFC2617].)=0A>=C2=A0=0A>A.16.=C2=A0 "password= " Syntax=0A>=C2=A0=0A>=C2=A0=C2=A0 The "password" element is defined in Sec= tion 4.3.2:=0A>=C2=A0=0A>=C2=A0=C2=A0 password =3D *TEXT=0A>=C2=A0=0A>=C2= =A0=C2=A0 (This matches the "password" definition in the HTTP Basic=0A>=C2= =A0=C2=A0 Authentication Scheme [RFC2617].)=0A>=C2=A0=0A>A.17.=C2=A0 "refre= sh_token" Syntax=0A>=C2=A0=0A>=C2=A0=C2=A0 The "refresh_token" element is d= efined in Section 5.1 and Section 6:=0A>=C2=A0=0A>=C2=A0=C2=A0 refresh-toke= n =3D b64token=0A>=C2=A0=0A>A.18.=C2=A0 Endpoint Parameter Syntax=0A>=C2=A0= =0A>=C2=A0=C2=A0 The syntax for new endpoint parameters is defined in Secti= on 8.2:=0A>=C2=A0=0A>=C2=A0=C2=A0 param-name =3D 1*name-char=0A>=C2=A0=C2= =A0 name-char=C2=A0 =3D "-" / "." / "_" / DIGIT / ALPHA=0A>=C2=A0=0A>=C2=A0= =0A>_______________________________________________=0A>OAuth mailing list= =0A>OAuth@ietf.org=0A>https://www.ietf.org/mailman/listinfo/oauth=0A>=0A>= =0A> --1502656925-624483912-1338848681=:63031 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Do we want to make expires_in not have zeroes?  Or am I being to OCD= on this?

-bill

From: Mike J= ones <Michael.Jones@microsoft.com>
To: Eran Hammer <eran@hueniverse.com>; "oauth@ietf= .org" <oauth@ietf.org>
Sen= t: Monday, June 4, 2012 3:10 PM
Sub= ject: Re: [OAUTH-WG] ABNF elements for suggested WG review
<= /font>

=0A
=0A=0A =0A =0A=0A=0A
=0A
= =0A
The = main point of my message was to point out that the working group has not di= scussed the syntax for some the elements identified.  I=E2=80=99m glad= that it now is.
=0A
 
=0A
Actually, the draft already cont= ains or implies syntax restrictions for more fields than you listed, Eran. =  Let me tackle each field individually and provide rationale for the c= hoice made and solicit working=0A group input on those where I believe ther= e are open issues.
=0A
 
=0A
We already had syntax restrict= ions in place for=0Aerror, error_description, error_uri, scope, and response_type so I won=E2=80=99t discuss those = further.
=0A
 
=0A
The spec already included a syntax for= =0Atoken_type, and the ABNF doesn=E2=80=99t deviate from it.  T= he grant_type element is logically the same kind of object as token_= type, so it makes sense to use the same syntax.
=0A
  =0A
= I don=E2=80=99t see a case for having =0Aexpires_in contain anything= but 1*DIGIT, so I don=E2=80=99t see that as being controversial. =0A
=  
=0A
For redirect_uri, since it is a URI, I believe that= URI-reference makes sense.
=0A
 
=0A
For username a= nd password, the spec mandates that they be used with HTTP Basic, th= us implicitly restricting their legal values.  (Per my earlier respons= e to Julian, RFC 2616 effectively limits these=0A characters to be the ISO-= 8859-1 characters other than control characters but including LWS character= s.)  HTTP Basic further restricts the username field to not contain a = colon (=E2=80=98:=E2=80=99).  In short, I believe that the OAuth core = already implicitly contains the=0A specified character set restrictions.
=0A
 
=0A
Since client_id and client_secret are= parallel to username and password, it would be inconsistent to use differe= nt character set restrictions for them.  (On the other hand, Brian Cam= pbell referenced=0A a case where a client_id might be a URL, in which case = colon would be required.  That seems like a reasonable usage, so the s= yntax restriction on client_id probably needs to be relaxed.  WG thoug= hts on the correct syntax?  Should it just be TEXT?)
=0A<= div class=3D"yiv955161859MsoNormal">  <= /span>
=0A
That leaves state, code,=0Aaccess_token, and = refresh_token as the remaining elements that genuinely need working = group discussion.  The ABNF currently restricts these to character set= s that don=E2=80=99t require encodings.  Should it, or like client_id,= should we likely expand=0A the sets?  If so, is TEXT with ISO-8859-1 = encoding the right ABNF definition for them, given that they can all be use= d in contexts where MIME encodings aren=E2=80=99t specified?
= =0A
&nb= sp;
=0A
          &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;   Thanks all,
=0A
      &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;       -- Mike
=0A
  =0A
=0A
=0A
From: Eran Hammer [mailto:eran@hueniverse.com]=0A
=0ASent: Monday, = June 04, 2012 12:17 PM
=0ATo: Mike Jones; oauth@ietf.org
=0ASubject: RE: ABNF elements for suggested WG review
=0A=0A
=0A
 
=0A
The ABNF must= reflect the existing draft, not invent new restrictions. The only field we= had consensus for applying new restrictions on is error (and the related o= nes from bearer). That=E2=80=99s it. Please have the=0A proposed ABNF refle= ct the unrestricted nature of all values not explicitly defined otherwise.<= /span>
=0A
 
=0A
EH
=0A
 
=0A
=0A=0A
=0A
From:=0Aoauth-bounces@ietf.org =0A[mailto:oauth-bo= unces@ietf.org] On Behalf Of Mike Jones
=0ASent: Satur= day, June 02, 2012 1:10 AM
=0ATo: oau= th@ietf.org
=0ASubject: [OAUTH-WG] ABNF elements for suggeste= d WG review
=0A
=0A
=0A
 
=0A
Dear working = group,
=0A
 
=0A
It turns out that writing an ABNF for the C= ore spec pointed out that the syntax of a number of the OAuth protocol elem= ents had not been previously defined.  (Thanks, Sean, for having us do= this!)  I took a stab at specifying appropriate=0A ABNF values for ea= ch of the protocol elements, but I would request that the working group act= ively review the choices in my proposed draft.
=0A
 
=0A
For= instance, I chose to use the same syntax definitions for username and pass= word and client_id and client_secret as HTTP Basic used for userid and pass= word.  Other choices were possible, such as perhaps limiting client_id= and possibly=0A username values to use =E2=80=9Cunreserved=E2=80=9D charac= ters, rather than allowing all characters other than =E2=80=9C:=E2=80=9D (a= s HTTP Basic did with userid).
=0A
 
=0A
Please particularly= review the syntax definitions for these elements, as I had to make choices= that went beyond the current specs to provide unambiguous syntax definitio= ns:
=0A
    &= nbsp;          client_id
= =0A
     &nbs= p;         client_secret
=0A<= div class=3D"yiv955161859MsoNormal">      &nb= sp;        state
=0A
        &nbs= p;      code
=0A
           =     access_token
=0A
            =    username
=0A
 &= nbsp;           &nbs= p; password
=0A
   = ;            refresh= _token
=0A
 
=0A
The full proposed ABNF section follows. =0A
 
=0A
         = ;            &n= bsp;            = ;            &n= bsp;            = ; -- Mike
=0A
 
=0AAppend= ix A.  Augmented Backus-Naur Form (ABNF) Syntax
=0A
 
=0A
   This section provides Augmented Backus-Naur Form (AB= NF) syntax
=0A
   descriptions for the elements defined i= n this specification using the
=0A
   notation of [RFC523= 4].  Elements are presented in the order first
=0A
  = ; defined.
=0A
 
=0A
   Some of the definit= ions that follow use the "unreserved" and "URI"
=0A
   d= efinitions from [RFC3986], which are:
=0A
 
=0A<= div class=3D"yiv955161859MsoNormal"> = ;  unreserved =3D ALPHA / DIGIT / "-" / "." / "_" / "~"
= =0A
&= nbsp;  URI        =3D scheme ":" hi= er-part [ "?" query ] [ "#" fragment ]
=0A
 
=0A=
&nbs= p;  Some of the definitions that follow use the "b64token" syntax belo= w,
=0A
   which matches the "b64token" syntax defined by = HTTP/1.1, Part 7
=0A
   [I-D.ietf-httpbis-p7-auth]:
=0A
 
=0A
   b64token   =3D 1*( ALPHA = / DIGIT /
=0A
        &nbs= p;           "-" / "." / = "_" / "~" / "+" / "/" ) *"=3D"
=0A
 
=0A
A.1.  "= client_id" Syntax
=0A
 
=0A
   The "client_= id" element is defined in Section 2.3.1:
=0A
 
= =0A
&= nbsp;  client-id     =3D *<TEXT excluding ":"&g= t;
=0A
 
=0A
   (This matches the "userid" = definition in the HTTP Basic
=0A
   Authentication Scheme= [RFC2617].)
=0A
 
=0A
A.2.  "client_secret" Syn= tax
=0A
 
=0A
   The "client_secret" elemen= t is defined in Section 2.3.1:
=0A
 
=0A
  = client-secret =3D *TEXT
=0A
 
=0A
   (This= matches the "password" definition in the HTTP Basic
=0A
 &nbs= p; Authentication Scheme [RFC2617].)
=0A
 
=0AA.3.&n= bsp; "response_type" Syntax
=0A
 
=0A
   T= he "response_type" element is defined in Section 3.1.1 and
=0A=
&nbs= p;  Section 8.4:
=0A
=  
=0A
   response= -type =3D response-name *( SP response-name )
=0A
   resp= onse-name =3D 1*response-char
=0A
   response-char =3D "_= " / DIGIT / ALPHA
=0A
 
=0A
A.4.  "scope" Syntax=
=0A
 
=0A
<= span style=3D"font-size:10.0pt;">   The "scope" element is define= d in Section 3.3:
=0A
 
=0A
   scope &= nbsp;     =3D scope-token *( SP scope-token ) =0A
   scope-token =3D 1*( %x21 / %x23-5B / %x5D-7E )
= =0A
=  
=0A
A.5.  "state" Syntax
=0A
  =0A
   The "state" element is defined in Section 4.1.1, Section 4.= 1.2,
=0A
   Section 4.1.2.1, Section 4.2.1, Section 4.2.2= , and Section 4.2.2.1:
=0A
 
=0A
   state&n= bsp;     =3D 1*unreserved
=0A
  =0A
A.6.  "redirect_uri" Syntax
=0A
 
=0A &= nbsp; The "redirect_uri" element is defined in Section 4.1.1,
= =0A
&= nbsp;  Section 4.1.3, and Section 4.2.1:
=0A
  =0A
   redirect-uri      =3D URI =0A
 
=0A
A.7.  "error" Syntax
=0A
 
=0A
   The "error" element is defined in Section 4.1.2.1, Sect= ion 4.2.2.1,
=0A
   Section 5.2, Section 7.2, and Section= 8.5:
=0A
 
=0A
   error   &= nbsp;         =3D 1*error-char
=0A
   error-char        = =3D %x20-21 / %x23-5B / %x5D-7E
=0A
 
=0A
A.8.  = "error_description" Syntax
=0A
 
=0A
   T= he "error_description" element is defined in Section 4.1.2.1,
= =0A
&= nbsp;  Section 4.2.2.1, Section 5.2, and Section 7.2:
=0A=
&nb= sp;
=0A
   error-description =3D 1*error-char =0A
   error-char        =3D %x20= -21 / %x23-5B / %x5D-7E
=0A
 
=0A
A.9.  "error_u= ri" Syntax
=0A
 
=0A
   The "error_uri" ele= ment is defined in Section 4.1.2.1,
=0A
   Section 4.2.2.= 1, Section 5.2, and Section 7.2:
=0A
 
=0A
 &nbs= p; error-uri         =3D URI=
=0A
 
=0A
A.10.  "grant_type" Syntax
=0A<= div class=3D"yiv955161859MsoNormal"> &nbs= p;
=0A
   The "grant_type" element is defined in Section = 4.1.3, Section 4.3.2,
=0A
=    Section 4.4.1, Section 6, an= d Section 4.5:
=0A
 
=0A
   grant-type =3D = grant-name / URI
=0A
   grant-name =3D 1*name-char=
=0A
   name-char  =3D "-" / "." / "_" / DIGIT / ALPHA
=0A
 
=0A
A.11.  "code" Syntax
=0A
 
=0A
   The "code" element is defined in Section 4.1.3:
=0A
 
=0A
   code     = ;  =3D 1*unreserved
=0A
 
=0A
A.12.  "acces= s_token" Syntax
=0A
 
=0A
   The "access_to= ken" element is defined in Section 4.2.2 and
=0A
   Secti= on 5.1:
=0A
 
=0A
   access-token =3D b64to= ken
=0A
 
=0A
A.13.  "token_type" Syntax<= /div> =0A
 
=0A
   The "token_type" element is defined i= n Section 4.2.2, Section 5.1,
=0A
   and Section 8.1:
=0A
 
=0A
   token-type =3D type-name / URI
=0A
   type-name  =3D 1*name-char
=0A &n= bsp; name-char  =3D "-" / "." / "_" / DIGIT / ALPHA
=0A  = ;
=0A
A.14.  "expires_in" Syntax
=0A
  =0A
   The "expires_in" element is defined in Section 4.2.2 and Se= ction 5.1:
=0A
 
=0A
   expires-in =3D 1*DI= GIT
=0A
 
=0A
A.15.  "username" Syntax =0A
 
=0A
   The "username" element is defined in Se= ction 4.3.2:
=0A
 
=0A
   username =3D *<= ;TEXT excluding ":">
=0A
 
=0A
   (This = matches the "userid" definition in the HTTP Basic
=0A
   = Authentication Scheme [RFC2617].)
=0A
 
=0A
A.16.&nbs= p; "password" Syntax
=0A
<= span style=3D"font-size:10.0pt;">  
=0A
   The "pass= word" element is defined in Section 4.3.2:
=0A
 
= =0A
=    password =3D *TEXT
=0A
 
=0A
  = ; (This matches the "password" definition in the HTTP Basic
= =0A
&= nbsp;  Authentication Scheme [RFC2617].)
=0A
  =0A
A.17.  "refresh_token" Syntax
=0A
 
=0A<= div class=3D"yiv955161859MsoNormal"> = ;  The "refresh_token" element is defined in Section 5.1 and Section 6= :
=0A
 
=0A
=    refresh-token =3D b64token
=0A
 
=0A
A.18.  Endpoint Parameter Syntax=
=0A
 
=0A
   The syntax for new endpoint paramete= rs is defined in Section 8.2:
=0A
 
=0A
   = param-name =3D 1*name-char
=0A
   name-char  =3D "-"= / "." / "_" / DIGIT / ALPHA
=0A
 
=0A
 
=0A
=0A
=0A
=0A=0A<= /div>
_______________________________________________
OAuth mailing l= ist
= OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--1502656925-624483912-1338848681=:63031-- From julian.reschke@gmx.de Mon Jun 4 15:36:49 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13A2521F86CE for ; Mon, 4 Jun 2012 15:36:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.932 X-Spam-Level: X-Spam-Status: No, score=-103.932 tagged_above=-999 required=5 tests=[AWL=-1.333, 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 oCd1up1EcEZ4 for ; Mon, 4 Jun 2012 15:36:48 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 14CD421F86C9 for ; Mon, 4 Jun 2012 15:36:47 -0700 (PDT) Received: (qmail invoked by alias); 04 Jun 2012 22:36:46 -0000 Received: from p5DD94B3A.dip.t-dialin.net (EHLO [192.168.178.36]) [93.217.75.58] by mail.gmx.net (mp071) with SMTP; 05 Jun 2012 00:36:46 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18fArsQ9aAfXoUZmDtRKitHfyQTGsdvDMtReZHx8P qlwywOx/lRvO1M Message-ID: <4FCD387C.3010700@gmx.de> Date: Tue, 05 Jun 2012 00:36:44 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Mike Jones References: <4E1F6AAD24975D4BA5B16804296739436652634C@TK5EX14MBXC284.redmond.corp.microsoft.com> <4FCA5384.3060306@gmx.de> <4E1F6AAD24975D4BA5B1680429673943665291A3@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943665291A3@TK5EX14MBXC284.redmond.corp.microsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] ABNF elements for suggested WG review X-BeenThere: oauth@ietf.org X-Mailman-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, 04 Jun 2012 22:36:49 -0000 On 2012-06-05 00:03, Mike Jones wrote: > RFC 2616 contains this restriction for the contents of TEXT fields: > > Words of *TEXT MAY contain characters from character sets other than > ISO-8859-1 [22] only when encoded according to the rules of > RFC 2047 [14]. TEXT is gone in httpbis. > Therefore, I believe that for the elements using TEXT, the encoding must be specified as ISO-8859-1, since they are not always used in contexts where MIME encoding rules can be specified. Again, the TEXT rule was only applicable while talking about octets-on-the-wire. It wasn't used to define sequences of characters. You will have to consider where the ABNF is used. Defining new protocol elements that are constrained to ISO-8859-1 definitively will be a problem. And anyway, it's gone from the spec. > ... Best regards, Julian From Michael.Jones@microsoft.com Mon Jun 4 15:41:27 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BA2811E80CF for ; Mon, 4 Jun 2012 15:41:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.702 X-Spam-Level: X-Spam-Status: No, score=-3.702 tagged_above=-999 required=5 tests=[AWL=-0.103, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ycbhNGjCoVQa for ; Mon, 4 Jun 2012 15:41:26 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe002.messaging.microsoft.com [216.32.181.182]) by ietfa.amsl.com (Postfix) with ESMTP id 7793D11E80C4 for ; Mon, 4 Jun 2012 15:41:26 -0700 (PDT) Received: from mail222-ch1-R.bigfish.com (10.43.68.246) by CH1EHSOBE013.bigfish.com (10.43.70.63) with Microsoft SMTP Server id 14.1.225.23; Mon, 4 Jun 2012 22:40:45 +0000 Received: from mail222-ch1 (localhost [127.0.0.1]) by mail222-ch1-R.bigfish.com (Postfix) with ESMTP id ADC791C01F0; Mon, 4 Jun 2012 22:40:45 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -38 X-BigFish: VS-38(zz9371I936eI146fI542M1432N98dK4015Izz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25hf0ah) Received-SPF: pass (mail222-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail222-ch1 (localhost.localdomain [127.0.0.1]) by mail222-ch1 (MessageSwitch) id 1338849643848010_17617; Mon, 4 Jun 2012 22:40:43 +0000 (UTC) Received: from CH1EHSMHS027.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.242]) by mail222-ch1.bigfish.com (Postfix) with ESMTP id CDD38220047; Mon, 4 Jun 2012 22:40:43 +0000 (UTC) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS027.bigfish.com (10.43.70.27) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 4 Jun 2012 22:40:43 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.189]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.02.0298.005; Mon, 4 Jun 2012 22:40:51 +0000 From: Mike Jones To: Julian Reschke Thread-Topic: [OAUTH-WG] ABNF elements for suggested WG review Thread-Index: Ac1Alx0u1VneJZSBR8aFxCHOlLRpzQAUcCIAAGu2zeAAArLqAAAABMhA Date: Mon, 4 Jun 2012 22:40:51 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366529436@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739436652634C@TK5EX14MBXC284.redmond.corp.microsoft.com> <4FCA5384.3060306@gmx.de> <4E1F6AAD24975D4BA5B1680429673943665291A3@TK5EX14MBXC284.redmond.corp.microsoft.com> <4FCD387C.3010700@gmx.de> In-Reply-To: <4FCD387C.3010700@gmx.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] ABNF elements for suggested WG review X-BeenThere: oauth@ietf.org X-Mailman-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, 04 Jun 2012 22:41:27 -0000 OAuth Core doesn't use HTTPbis. Many of these parameters are often used as= URI query parameters, so whatever encodings are specified must work there.= What syntax and encodings would you suggest for the OAuth Core parameters= that need to work with HTTP Basic as specified in RFC 2617? Other suggestions are welcome as well. Thanks, -- Mike -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de]=20 Sent: Monday, June 04, 2012 3:37 PM To: Mike Jones Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] ABNF elements for suggested WG review On 2012-06-05 00:03, Mike Jones wrote: > RFC 2616 contains this restriction for the contents of TEXT fields: > > Words of *TEXT MAY contain characters from character sets other than > ISO-8859-1 [22] only when encoded according to the rules of > RFC 2047 [14]. TEXT is gone in httpbis. > Therefore, I believe that for the elements using TEXT, the encoding must = be specified as ISO-8859-1, since they are not always used in contexts wher= e MIME encoding rules can be specified. Again, the TEXT rule was only applicable while talking about octets-on-the-= wire. It wasn't used to define sequences of characters.=20 You will have to consider where the ABNF is used. Defining new protocol ele= ments that are constrained to ISO-8859-1 definitively will be a problem. And anyway, it's gone from the spec. > ... Best regards, Julian From julian.reschke@gmx.de Mon Jun 4 15:42:22 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9167A11E8111 for ; Mon, 4 Jun 2012 15:42:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.799 X-Spam-Level: X-Spam-Status: No, score=-103.799 tagged_above=-999 required=5 tests=[AWL=-1.200, 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 6aiTqxgfYxUT for ; Mon, 4 Jun 2012 15:42:22 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 9579C11E80D1 for ; Mon, 4 Jun 2012 15:42:21 -0700 (PDT) Received: (qmail invoked by alias); 04 Jun 2012 22:42:20 -0000 Received: from p5DD94B3A.dip.t-dialin.net (EHLO [192.168.178.36]) [93.217.75.58] by mail.gmx.net (mp028) with SMTP; 05 Jun 2012 00:42:20 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18rllscG9UrAoz1itRnpNNdmKRC2w/cXitH0rfOKy vwFzYZ8hGYMOA8 Message-ID: <4FCD39CA.1040508@gmx.de> Date: Tue, 05 Jun 2012 00:42:18 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Mike Jones References: <4E1F6AAD24975D4BA5B16804296739436652634C@TK5EX14MBXC284.redmond.corp.microsoft.com> <0CBAEB56DDB3A140BA8E8C124C04ECA20105F565@P3PWEX2MB008.ex2.secureserver.net> <4E1F6AAD24975D4BA5B168042967394366529249@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366529249@TK5EX14MBXC284.redmond.corp.microsoft.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] ABNF elements for suggested WG review X-BeenThere: oauth@ietf.org X-Mailman-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, 04 Jun 2012 22:42:22 -0000 On 2012-06-05 00:10, Mike Jones wrote: > The main point of my message was to point out that the working group has > not discussed the syntax for some the elements identified. I’m glad that > it now is. > > Actually, the draft already contains or implies syntax restrictions for > more fields than you listed, Eran. Let me tackle each field individually > and provide rationale for the choice made and solicit working group > input on those where I believe there are open issues. > > We already had syntax restrictions in place for *error*, > *error_description*, *error_uri*, *scope*, and *response_type* so I > won’t discuss those further. > > The spec already included a syntax for *token_type*, and the ABNF > doesn’t deviate from it. The *grant_type* element is logically the same > kind of object as token_type, so it makes sense to use the same syntax. > > I don’t see a case for having *expires_in* contain anything but 1*DIGIT, > so I don’t see that as being controversial. > > For *redirect_uri*, since it is a URI, I believe that URI-reference > makes sense. > > For *username* and *password*, the spec mandates that they be used with > HTTP Basic, thus implicitly restricting their legal values. (Per my > earlier response to Julian, RFC 2616 effectively limits these characters > to be the ISO-8859-1 characters other than control characters but > including LWS characters.) HTTP Basic further restricts the username > field to not contain a colon (‘:’). In short, I believe that the OAuth > core already implicitly contains the specified character set restrictions. RFC 2617 is very vague on this, and implementations disagree. > Since *client_id* and *client_secret* are parallel to username and > password, it would be inconsistent to use different character set > restrictions for them. (On the other hand, Brian Campbell referenced a > case where a client_id might be a URL, in which case colon would be > required. That seems like a reasonable usage, so the syntax restriction > on client_id probably needs to be relaxed. WG thoughts on the correct > syntax? Should it just be TEXT?) No, please forget about TEXT. It's gone from HTTP- If you define new protocol elements, either restrict them to US-ASCII, or find a way to encode all of Unicode. Restricting to ISO-8859-1 is a non-starter. Best regards, Julian From stpeter@stpeter.im Mon Jun 4 15:43:25 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AA8611E811A for ; Mon, 4 Jun 2012 15:43:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.839 X-Spam-Level: X-Spam-Status: No, score=-102.839 tagged_above=-999 required=5 tests=[AWL=-0.240, 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 FqrXL70kfv9O for ; Mon, 4 Jun 2012 15:43:24 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 6B9EB11E80C4 for ; Mon, 4 Jun 2012 15:43:24 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E6DB5400A4; Mon, 4 Jun 2012 17:00:06 -0600 (MDT) Message-ID: <4FCD3A09.2080209@stpeter.im> Date: Mon, 04 Jun 2012 16:43:21 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Julian Reschke References: <4E1F6AAD24975D4BA5B16804296739436652634C@TK5EX14MBXC284.redmond.corp.microsoft.com> <0CBAEB56DDB3A140BA8E8C124C04ECA20105F565@P3PWEX2MB008.ex2.secureserver.net> <4E1F6AAD24975D4BA5B168042967394366529249@TK5EX14MBXC284.redmond.corp.microsoft.com> <4FCD39CA.1040508@gmx.de> In-Reply-To: <4FCD39CA.1040508@gmx.de> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] ABNF elements for suggested WG review X-BeenThere: oauth@ietf.org X-Mailman-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, 04 Jun 2012 22:43:25 -0000 On 6/4/12 4:42 PM, Julian Reschke wrote: > On 2012-06-05 00:10, Mike Jones wrote: > >> Since *client_id* and *client_secret* are parallel to username and >> password, it would be inconsistent to use different character set >> restrictions for them. (On the other hand, Brian Campbell referenced a >> case where a client_id might be a URL, in which case colon would be >> required. That seems like a reasonable usage, so the syntax restriction >> on client_id probably needs to be relaxed. WG thoughts on the correct >> syntax? Should it just be TEXT?) > > No, please forget about TEXT. It's gone from HTTP- > > If you define new protocol elements, either restrict them to US-ASCII, > or find a way to encode all of Unicode. Restricting to ISO-8859-1 is a > non-starter. +1 to that. Peter -- Peter Saint-Andre https://stpeter.im/ From Michael.Jones@microsoft.com Mon Jun 4 15:46:42 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DFDA11E812E for ; Mon, 4 Jun 2012 15:46:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.699 X-Spam-Level: X-Spam-Status: No, score=-3.699 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rjbCQ8w9+KFS for ; Mon, 4 Jun 2012 15:46:41 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe003.messaging.microsoft.com [216.32.181.183]) by ietfa.amsl.com (Postfix) with ESMTP id 0B87311E812D for ; Mon, 4 Jun 2012 15:46:41 -0700 (PDT) Received: from mail179-ch1-R.bigfish.com (10.43.68.249) by CH1EHSOBE014.bigfish.com (10.43.70.64) with Microsoft SMTP Server id 14.1.225.23; Mon, 4 Jun 2012 22:46:00 +0000 Received: from mail179-ch1 (localhost [127.0.0.1]) by mail179-ch1-R.bigfish.com (Postfix) with ESMTP id D5EE022023D; Mon, 4 Jun 2012 22:45:59 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -38 X-BigFish: VS-38(zzbb2dI9371I936eI542M1432N98dK4015Izz1202hzz1033IL8275dhz2fh2a8h668h839h93fhd25hf0ah) Received-SPF: pass (mail179-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC103.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail179-ch1 (localhost.localdomain [127.0.0.1]) by mail179-ch1 (MessageSwitch) id 1338849958933936_7399; Mon, 4 Jun 2012 22:45:58 +0000 (UTC) Received: from CH1EHSMHS013.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.237]) by mail179-ch1.bigfish.com (Postfix) with ESMTP id D8A6D40048; Mon, 4 Jun 2012 22:45:58 +0000 (UTC) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS013.bigfish.com (10.43.70.13) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 4 Jun 2012 22:45:58 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.189]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.02.0298.005; Mon, 4 Jun 2012 22:46:30 +0000 From: Mike Jones To: Peter Saint-Andre , Julian Reschke Thread-Topic: [OAUTH-WG] ABNF elements for suggested WG review Thread-Index: Ac1Alx0u1VneJZSBR8aFxCHOlLRpzQB70KSwAAOx8eAAA4kJAAAACWOAAAADZVA= Date: Mon, 4 Jun 2012 22:46:29 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366529508@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739436652634C@TK5EX14MBXC284.redmond.corp.microsoft.com> <0CBAEB56DDB3A140BA8E8C124C04ECA20105F565@P3PWEX2MB008.ex2.secureserver.net> <4E1F6AAD24975D4BA5B168042967394366529249@TK5EX14MBXC284.redmond.corp.microsoft.com> <4FCD39CA.1040508@gmx.de> <4FCD3A09.2080209@stpeter.im> In-Reply-To: <4FCD3A09.2080209@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.19] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] ABNF elements for suggested WG review X-BeenThere: oauth@ietf.org X-Mailman-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, 04 Jun 2012 22:46:42 -0000 SXMgdGhlcmUgYW4gZXhpc3RpbmcgQUJORiBlbGVtZW50IGFscmVhZHkgZGVmaW5lZCB0aGF0IGJv dGggb2YgeW91IHdvdWxkIHN1Z2dlc3QgdGhhdCB3ZSB1c2UgaW5zdGVhZCBvZiBURVhUPyAgRm9y IGluc3RhbmNlLCBpcyB0aGVyZSBvbmUgdGhhdCBhbGxvd3MgYWxsIHByaW50YWJsZSBhbmQgaG9y aXpvbnRhbCB3aGl0ZXNwYWNlIEFTQ0lJIGNoYXJhY3RlcnM/ICBBbmQgb25lIHRoYXQgYWxsb3dz IGFsbCBwcmludGFibGUgYW5kIGhvcml6b250YWwgd2hpdGVzcGFjZSBVbmljb2RlIGNoYXJhY3Rl cnM/DQoNCkV4cGVydCBhZHZpY2UgZXhwbGljaXRseSBzb2xpY2l0ZWQuIDotKSAgSSdkIGxpa2Ug dXMgbm90IHRvIGJyZWFrIG5ldyBncm91bmQgaGVyZS4uLg0KDQoJCQkJVGhhbmtzLA0KCQkJCS0t IE1pa2UNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFBldGVyIFNhaW50LUFu ZHJlIFttYWlsdG86c3RwZXRlckBzdHBldGVyLmltXSANClNlbnQ6IE1vbmRheSwgSnVuZSAwNCwg MjAxMiAzOjQzIFBNDQpUbzogSnVsaWFuIFJlc2Noa2UNCkNjOiBNaWtlIEpvbmVzOyBvYXV0aEBp ZXRmLm9yZw0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gQUJORiBlbGVtZW50cyBmb3Igc3VnZ2Vz dGVkIFdHIHJldmlldw0KDQpPbiA2LzQvMTIgNDo0MiBQTSwgSnVsaWFuIFJlc2Noa2Ugd3JvdGU6 DQo+IE9uIDIwMTItMDYtMDUgMDA6MTAsIE1pa2UgSm9uZXMgd3JvdGU6DQo+DQo+PiBTaW5jZSAq Y2xpZW50X2lkKiBhbmQgKmNsaWVudF9zZWNyZXQqIGFyZSBwYXJhbGxlbCB0byB1c2VybmFtZSBh bmQgDQo+PiBwYXNzd29yZCwgaXQgd291bGQgYmUgaW5jb25zaXN0ZW50IHRvIHVzZSBkaWZmZXJl bnQgY2hhcmFjdGVyIHNldCANCj4+IHJlc3RyaWN0aW9ucyBmb3IgdGhlbS4gKE9uIHRoZSBvdGhl ciBoYW5kLCBCcmlhbiBDYW1wYmVsbCByZWZlcmVuY2VkIA0KPj4gYSBjYXNlIHdoZXJlIGEgY2xp ZW50X2lkIG1pZ2h0IGJlIGEgVVJMLCBpbiB3aGljaCBjYXNlIGNvbG9uIHdvdWxkIGJlIA0KPj4g cmVxdWlyZWQuIFRoYXQgc2VlbXMgbGlrZSBhIHJlYXNvbmFibGUgdXNhZ2UsIHNvIHRoZSBzeW50 YXggDQo+PiByZXN0cmljdGlvbiBvbiBjbGllbnRfaWQgcHJvYmFibHkgbmVlZHMgdG8gYmUgcmVs YXhlZC4gV0cgdGhvdWdodHMgb24gDQo+PiB0aGUgY29ycmVjdCBzeW50YXg/IFNob3VsZCBpdCBq dXN0IGJlIFRFWFQ/KQ0KPiANCj4gTm8sIHBsZWFzZSBmb3JnZXQgYWJvdXQgVEVYVC4gSXQncyBn b25lIGZyb20gSFRUUC0NCj4gDQo+IElmIHlvdSBkZWZpbmUgbmV3IHByb3RvY29sIGVsZW1lbnRz LCBlaXRoZXIgcmVzdHJpY3QgdGhlbSB0byBVUy1BU0NJSSwgDQo+IG9yIGZpbmQgYSB3YXkgdG8g ZW5jb2RlIGFsbCBvZiBVbmljb2RlLiBSZXN0cmljdGluZyB0byBJU08tODg1OS0xIGlzIGEgDQo+ IG5vbi1zdGFydGVyLg0KDQorMSB0byB0aGF0Lg0KDQpQZXRlcg0KDQotLQ0KUGV0ZXIgU2FpbnQt QW5kcmUNCmh0dHBzOi8vc3RwZXRlci5pbS8NCg0KDQoNCg== From julian.reschke@gmx.de Mon Jun 4 15:49:20 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE30411E80FA for ; Mon, 4 Jun 2012 15:49:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.69 X-Spam-Level: X-Spam-Status: No, score=-103.69 tagged_above=-999 required=5 tests=[AWL=-1.091, 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 7rztTuoLyWxU for ; Mon, 4 Jun 2012 15:49:19 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id B4E7E11E80D1 for ; Mon, 4 Jun 2012 15:49:18 -0700 (PDT) Received: (qmail invoked by alias); 04 Jun 2012 22:49:17 -0000 Received: from p5DD94B3A.dip.t-dialin.net (EHLO [192.168.178.36]) [93.217.75.58] by mail.gmx.net (mp072) with SMTP; 05 Jun 2012 00:49:17 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/8Drdc8Df8Tu6aZ6CPa2D68fgfnxeG2rcsIMmUMI 51DDgWyhgG5yhR Message-ID: <4FCD3B6C.4040204@gmx.de> Date: Tue, 05 Jun 2012 00:49:16 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Mike Jones References: <4E1F6AAD24975D4BA5B16804296739436652634C@TK5EX14MBXC284.redmond.corp.microsoft.com> <4FCA5384.3060306@gmx.de> <4E1F6AAD24975D4BA5B1680429673943665291A3@TK5EX14MBXC284.redmond.corp.microsoft.com> <4FCD387C.3010700@gmx.de> <4E1F6AAD24975D4BA5B168042967394366529436@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366529436@TK5EX14MBXC284.redmond.corp.microsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] ABNF elements for suggested WG review X-BeenThere: oauth@ietf.org X-Mailman-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, 04 Jun 2012 22:49:20 -0000 On 2012-06-05 00:40, Mike Jones wrote: > OAuth Core doesn't use HTTPbis. Many of these parameters are often used as URI query parameters, so whatever encodings are specified must work there. What syntax and encodings would you suggest for the OAuth Core parameters that need to work with HTTP Basic as specified in RFC 2617? > > Other suggestions are welcome as well. URI query parameters are all US-ASCII by definition. The interesting question is whether you define something abstract (and then describe the mapping to protocol elements) or not. In the first case, you need to define in terms of *code points*, not *octets*, and then specify the encoding into, for instance, URI query parameters (such as: UTF-8-encode then percent-escape). It's unfortunate that HTTP Basic is broken with respect to I18N, please don't add new stuff to this mess (-> ). Best regards, Julian From julian.reschke@gmx.de Tue Jun 5 00:15:54 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3482B21F86E5 for ; Tue, 5 Jun 2012 00:15:54 -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=[AWL=-1.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 9YXHPWdKlr3K for ; Tue, 5 Jun 2012 00:15:53 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 6E16421F8692 for ; Tue, 5 Jun 2012 00:15:52 -0700 (PDT) Received: (qmail invoked by alias); 05 Jun 2012 07:15:50 -0000 Received: from p5DD94B3A.dip.t-dialin.net (EHLO [192.168.178.36]) [93.217.75.58] by mail.gmx.net (mp001) with SMTP; 05 Jun 2012 09:15:50 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/VxgFkvQTVHkoD8bGaCJk6RUQbm8BP53Kg9mT46k SoRnyJ9oBg7MHL Message-ID: <4FCDB224.7040905@gmx.de> Date: Tue, 05 Jun 2012 09:15:48 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Mike Jones References: <4E1F6AAD24975D4BA5B16804296739436652634C@TK5EX14MBXC284.redmond.corp.microsoft.com> <0CBAEB56DDB3A140BA8E8C124C04ECA20105F565@P3PWEX2MB008.ex2.secureserver.net> <4E1F6AAD24975D4BA5B168042967394366529249@TK5EX14MBXC284.redmond.corp.microsoft.com> <4FCD39CA.1040508@gmx.de> <4FCD3A09.2080209@stpeter.im> <4E1F6AAD24975D4BA5B168042967394366529508@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366529508@TK5EX14MBXC284.redmond.corp.microsoft.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] ABNF elements for suggested WG review X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 07:15:54 -0000 On 2012-06-05 00:46, Mike Jones wrote: > Is there an existing ABNF element already defined that both of you would suggest that we use instead of TEXT? For instance, is there one that allows all printable and horizontal whitespace ASCII characters? And one that allows all printable and horizontal whitespace Unicode characters? RFC 5234 defines VCHAR (). For code-point-based ABNF productions, you may want to look at . > Expert advice explicitly solicited. :-) I'd like us not to break new ground here... > > Thanks, > -- Mike Best regards, Julian From zachary.zeltsan@alcatel-lucent.com Tue Jun 5 02:04:48 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91BF921F85A1 for ; Tue, 5 Jun 2012 02:04:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CPefOPax-OpX for ; Tue, 5 Jun 2012 02:04:48 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id D8CC421F8595 for ; Tue, 5 Jun 2012 02:04:47 -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 q5594ik7007806 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 5 Jun 2012 04:04:45 -0500 (CDT) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q5594iVd000524 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 5 Jun 2012 04:04:44 -0500 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.127]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Tue, 5 Jun 2012 04:04:44 -0500 From: "Zeltsan, Zachary (Zachary)" To: "'hannes.tschofenig@gmx.net'" , "'oauth@ietf.org'" Date: Tue, 5 Jun 2012 04:04:43 -0500 Thread-Topic: [OAUTH-WG] Meeting slot for the Vancouver IETF meeting requested Thread-Index: Ac1Ak85YqBcKQFO0RCS2tjeGdJ06VACZnDtB Message-ID: <5710F82C0E73B04FA559560098BF95B129E96F30E4@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> In-Reply-To: <09CE58C6-9409-4E28-B4CA-DC76C37B898E@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: Re: [OAUTH-WG] Meeting slot for the Vancouver IETF meeting requested X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 09:04:48 -0000 Hannes, I plan to attend the meeting and present on the status of the draft draft-i= etf-oauth-use-cases. Zachary ----- Original Message ----- From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net] Sent: Saturday, June 02, 2012 02:46 AM=0A= To: oauth@ietf.org WG Subject: [OAUTH-WG] Meeting slot for the Vancouver IETF meeting requested Hi all,=20 I have requested a 2,5 hour slot for the upcoming meeting.=20 While the next meeting is still a bit away it is nevertheless useful to hea= r=20 * whether you plan to attend the next meeting, and=20 * whether you want to present something.=20 I could imagine that these documents will be discussed: * draft-ietf-oauth-dyn-reg * draft-ietf-oauth-json-web-token * draft-ietf-oauth-jwt-bearer * draft-ietf-oauth-revocation * draft-ietf-oauth-use-cases To the draft authors of these docuemnts: Please think about the open issues= and drop a mail to the list so that we make some progress already before t= he face-to-face meeting.=20 I am assume that the following documents do not require any discussion time= at the upcoming IETF meeting anymore: * draft-ietf-oauth-assertions * draft-ietf-oauth-saml2-bearer * draft-ietf-oauth-urn-sub-ns * draft-ietf-oauth-v2 * draft-ietf-oauth-v2-bearer Ciao Hannes _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From wmills@yahoo-inc.com Tue Jun 5 08:34:20 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12AE721F8679 for ; Tue, 5 Jun 2012 08:34:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.598 X-Spam-Level: X-Spam-Status: No, score=-17.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rI7+sQiDgfeb for ; Tue, 5 Jun 2012 08:34:19 -0700 (PDT) Received: from nm16.bullet.mail.ac4.yahoo.com (nm16.bullet.mail.ac4.yahoo.com [98.139.52.213]) by ietfa.amsl.com (Postfix) with SMTP id D41B821F866A for ; Tue, 5 Jun 2012 08:34:18 -0700 (PDT) Received: from [98.139.52.189] by nm16.bullet.mail.ac4.yahoo.com with NNFMP; 05 Jun 2012 15:34:15 -0000 Received: from [98.139.52.177] by tm2.bullet.mail.ac4.yahoo.com with NNFMP; 05 Jun 2012 15:34:15 -0000 Received: from [127.0.0.1] by omp1060.mail.ac4.yahoo.com with NNFMP; 05 Jun 2012 15:34:15 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 840145.35547.bm@omp1060.mail.ac4.yahoo.com Received: (qmail 17064 invoked by uid 60001); 5 Jun 2012 15:34:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1338910455; bh=wAtNVVG546JA3S5dxeaYwOl40qMuB7Pn2OfvnICrgSU=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=hBEvg1etJYj1niNA+9ezsC6uDrVK7i0Q1c49GsAOOtWgZB8tdwadL4ih/C+opJxmi1UB6tYJthax+LMt6tllpOiid+u2F/kJwM6qypxK9nrHd4LjFGbsPcJ99+OkRpIGKuFaWJFMS90gz9tAmeup0ukdS6hjjiwb0NL4IKE/0Ww= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=qz+8Wu99wohdj4QJNuerpXyC45E3KDd/JFngB6XUH+4/9VdnplrGlXNzJBeJm5L/l25swLp6b1Xz0uCFw711IUvqNLuNPMFq3ywSXBcn00/5Xc91FxDB3KHD/QMade3G8dBQMLCE3chDThCyF/fHxNYXtEYj4FtK/xBBmDvrCjM=; X-YMail-OSG: Dxh3q1QVM1myk48BKbB0BH5EMIkf_z6vgGIFgrY6ZnSv2Aa X1zIGN.Rwk5rxuI4BvreUERJrPGcWnpVWw0JevHsKNbbSuj43YnhUdheDWAp m5D72_qtFdvOayVhoALgYYcvvMgw23.Kj.VumAhtMphHgHaQkcQ58XUH_05Z IKv13K4CD8M0qoUEzoR4o44nrCTEsmR8NIj7kR9cSKwJN_Xc.heuO__dKBTn HF3vHl5lp4c3WS5onDVXc5Pt61bNSxQDRBf_AwklAmXG4qb7G1kNL9PSqLHw L11poFrtoha8jeZ4LScyWfhF97mlQbs3U.v7Ix0YPrjgxnOXnxtXTi3imgQ8 qvPC5U_VS326YpqtUNmCcS0waDxan4Jx442mMDf_JT08RoF28lwPoSBLV60K bLxnpJ6hYmP2EQ6NETe9QSjOPpBKkzcYx849wYDRFJ0eBBKqSbXBOOzbZe3o rV02.CG3PnKA1GgbGVpn6tV4jMjGB6BJw4HoQp1zPviMwKhxUn26sfKYNl90 - Received: from [99.31.212.42] by web31816.mail.mud.yahoo.com via HTTP; Tue, 05 Jun 2012 08:34:15 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.118.349524 References: <4E1F6AAD24975D4BA5B16804296739436652634C@TK5EX14MBXC284.redmond.corp.microsoft.com> <0CBAEB56DDB3A140BA8E8C124C04ECA20105F565@P3PWEX2MB008.ex2.secureserver.net> <4E1F6AAD24975D4BA5B168042967394366529249@TK5EX14MBXC284.redmond.corp.microsoft.com> <4FCD39CA.1040508@gmx.de> <4FCD3A09.2080209@stpeter.im> <4E1F6AAD24975D4BA5B168042967394366529508@TK5EX14MBXC284.redmond.corp.microsoft.com> <4FCDB224.7040905@gmx.de> Message-ID: <1338910455.11437.YahooMailNeo@web31816.mail.mud.yahoo.com> Date: Tue, 5 Jun 2012 08:34:15 -0700 (PDT) From: William Mills To: Julian Reschke , Mike Jones In-Reply-To: <4FCDB224.7040905@gmx.de> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1238014912-1084611965-1338910455=:11437" Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] ABNF elements for suggested WG review X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 15:34:20 -0000 ---1238014912-1084611965-1338910455=:11437 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable wrong link for 5234...=A0 http://tools.ietf.org/html/rfc5234=0A=0A=0A=0A=0A= >________________________________=0A> From: Julian Reschke =0A>To: Mike Jones =0A>Cc: "oauth@ietf= .org" =0A>Sent: Tuesday, June 5, 2012 12:15 AM=0A>Subject:= Re: [OAUTH-WG] ABNF elements for suggested WG review=0A> =0A>On 2012-06-05= 00:46, Mike Jones wrote:=0A>> Is there an existing ABNF element already de= fined that both of you would suggest that we use instead of TEXT?=A0 For in= stance, is there one that allows all printable and horizontal whitespace AS= CII characters?=A0 And one that allows all printable and horizontal whitesp= ace Unicode characters?=0A>=0A>RFC 5234 defines VCHAR ().=0A>=0A>For code-po= int-based ABNF productions, you may want to look at .=0A>=0A>=0A>> Expert advice exp= licitly solicited. :-)=A0 I'd like us not to break new ground here...=0A>> = =0A>> =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 Thanks,=0A>> =A0=A0=A0 =A0=A0= =A0 =A0=A0=A0 =A0=A0=A0 -- Mike=0A>=0A>Best regards, Julian=0A>____________= ___________________________________=0A>OAuth mailing list=0A>OAuth@ietf.org= =0A>https://www.ietf.org/mailman/listinfo/oauth=0A>=0A>=0A> ---1238014912-1084611965-1338910455=:11437 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
wrong link for 5234...  http://tools.ietf.org/html/rfc5234

From: Julian Resc= hke <julian.reschke@gmx.de>
To: Mike Jones <Michael.Jones@microsoft.com>
Cc: "oauth@ietf.org" <oauth@iet= f.org>
Sent: Tuesd= ay, June 5, 2012 12:15 AM
Subject: Re:= [OAUTH-WG] ABNF elements for suggested WG review

= =0AOn 2012-06-05 00:46, Mike Jones wrote:
> Is there an existing ABNF= element already defined that both of you would suggest that we use instead= of TEXT?  For instance, is there one that allows all printable and ho= rizontal whitespace ASCII characters?  And one that allows all printab= le and horizontal whitespace Unicode characters?

RFC 5234 defines VC= HAR (<http://greenbytes.de/tech/webdav/draft= -reschke-basicauth-enc-latest.html>).

For code-point-based AB= NF productions, you may want to look at <http://gree= nbytes.de/tech/webdav/rfc5323.html#rfc.section.5.15.1>.


&= gt; Expert advice explicitly solicited. :-)  I'd like us not to break = new ground here...
>
>                 Thanks,
>     &= nbsp;           -- Mike

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


---1238014912-1084611965-1338910455=:11437-- From torsten@lodderstedt.net Thu Jun 7 08:40:58 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADBBA21F8811 for ; Thu, 7 Jun 2012 08:40:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.716 X-Spam-Level: X-Spam-Status: No, score=-1.716 tagged_above=-999 required=5 tests=[AWL=0.533, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id caFiwiaoDLuL for ; Thu, 7 Jun 2012 08:40:57 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.18.43]) by ietfa.amsl.com (Postfix) with ESMTP id 33FD621F87F4 for ; Thu, 7 Jun 2012 08:40:56 -0700 (PDT) Received: from [91.2.74.15] (helo=[192.168.71.36]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1ScepS-0001qS-KS; Thu, 07 Jun 2012 17:40:54 +0200 Message-ID: <4FD0CB80.4050601@lodderstedt.net> Date: Thu, 07 Jun 2012 17:40:48 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Michiel de Jong References: <20120527084150.26400.88469.idtracker@ietfa.amsl.com> <4FC226AD.10102@lodderstedt.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 15:40:58 -0000 Hi Michiel, I'm fine with both suggestions (also mentioning CORS or not mentioning JSONP). What do my co-authors and other WG members think? regards, Torsten. Am 29.05.2012 14:10, schrieb Michiel de Jong: > Hi Torsten, > > No, it should indeed work fine with CORS. CORS is supported by IE8+, > FF, Chrome, Safari and Opera12+ (with limited error handling and > limited verb support in IE8 and IE9, but with POST you should be safe > afaik). > > Note that if you want to support this in combination with implicit > grant flow (unhosted html5 apps), then you need CORS. > > Which made me wonder why you are mentioning JSONP at all? Mentioning > JSONP as a 'MAY' but not mentioning CORS could send people in the > wrong direction IMO. So I would rename the section 'JSONP' to 'CORS > and JSONP', or in general, 'Cross-Origin support', and then start with > a sentence like: > > "The revokation end-point SHOULD support CORS if it is aimed at use in > combination with the implicit-grant flow. For other flows, it is still > recommended(?) to support CORS. In addition, for interop with legacy > user-agents, it MAY offer JSONP. Clients should be aware that when > relying on JSONP, the revokation end-point MAY ;) inject malicious > code into the client." > > You can tell i don't speak spec lingo, but i hope i'm sort of getting > my point across, that IMO, CORS is better here than JSONP. > > Or: simply not mention JSONP at all. Would that be an option? > > > Cheers, > Michiel > > On Sun, May 27, 2012 at 3:05 PM, Torsten Lodderstedt > wrote: >> Hi Michiel, >> >> shouldn't the revocation POST request work fine with CORS? Or is there >> something we need to specify in order to make it work? >> >> best regards, >> Torsten. >> >> Am 27.05.2012 13:20, schrieb Michiel de Jong: >> >>> awesome! just that - first thing that catches the eye right when you >>> skim the table of contents is: >>> >>> why did you use JSONP instead of its CORS? You can read more about CORS >>> here: >>> >>> http://enable-cors.org/ >>> >>> http://en.wikipedia.org/wiki/Cross-origin_resource_sharing#CORS_relationship_to_JSONP >>> >>> On Sun, May 27, 2012 at 10:41 AM, 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 : Token Revocation >>>> Author(s) : Torsten Lodderstedt >>>> Stefanie Dronia >>>> Marius Scurtescu >>>> Filename : draft-ietf-oauth-revocation-00.txt >>>> Pages : 6 >>>> Date : 2012-05-26 >>>> >>>> This draft proposes an additional endpoint for OAuth authorization >>>> servers for revoking tokens. >>>> >>>> >>>> >>>> A URL for this Internet-Draft is: >>>> http://www.ietf.org/internet-drafts/draft-ietf-oauth-revocation-00.txt >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>> >>>> This Internet-Draft can be retrieved at: >>>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-oauth-revocation-00.txt >>>> >>>> The IETF datatracker page for this Internet-Draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-revocation/ >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth From Michael.Jones@microsoft.com Thu Jun 7 08:49:59 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED4CA21F84D0 for ; Thu, 7 Jun 2012 08:49:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.196 X-Spam-Level: X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[AWL=1.403, 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 J5VItna691LI for ; Thu, 7 Jun 2012 08:49:59 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe003.messaging.microsoft.com [65.55.88.13]) by ietfa.amsl.com (Postfix) with ESMTP id C391B21F865A for ; Thu, 7 Jun 2012 08:49:49 -0700 (PDT) Received: from mail215-tx2-R.bigfish.com (10.9.14.235) by TX2EHSOBE003.bigfish.com (10.9.40.23) with Microsoft SMTP Server id 14.1.225.23; Thu, 7 Jun 2012 15:49:01 +0000 Received: from mail215-tx2 (localhost [127.0.0.1]) by mail215-tx2-R.bigfish.com (Postfix) with ESMTP id 4FBEF8C01C2; Thu, 7 Jun 2012 15:49:01 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -43 X-BigFish: VS-43(zz9371I601O936eI542M1432N98dKzz1202hzz8275ch1033IL8275dhz2fh2a8h668h839h944hd25hf0ah) Received-SPF: pass (mail215-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail215-tx2 (localhost.localdomain [127.0.0.1]) by mail215-tx2 (MessageSwitch) id 1339084139126199_15499; Thu, 7 Jun 2012 15:48:59 +0000 (UTC) Received: from TX2EHSMHS023.bigfish.com (unknown [10.9.14.239]) by mail215-tx2.bigfish.com (Postfix) with ESMTP id 1C7CFC40045; Thu, 7 Jun 2012 15:48:59 +0000 (UTC) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS023.bigfish.com (10.9.99.123) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 7 Jun 2012 15:48:57 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.189]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.02.0309.003; Thu, 7 Jun 2012 15:49:25 +0000 From: Mike Jones To: Torsten Lodderstedt , Michiel de Jong Thread-Topic: [OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-00.txt Thread-Index: AQHNO+SUU4ZQmRPonkm9jNGdReQ8JpbdfYmAgAAdjYCAAxU7gIAOX7cAgAACYhA= Date: Thu, 7 Jun 2012 15:49:25 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436652D742@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <20120527084150.26400.88469.idtracker@ietfa.amsl.com> <4FC226AD.10102@lodderstedt.net> <4FD0CB80.4050601@lodderstedt.net> In-Reply-To: <4FD0CB80.4050601@lodderstedt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.35] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 15:50:00 -0000 Fine with me -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of T= orsten Lodderstedt Sent: Thursday, June 07, 2012 8:41 AM To: Michiel de Jong Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-00.txt Hi Michiel, I'm fine with both suggestions (also mentioning CORS or not mentioning JSON= P). What do my co-authors and other WG members think? regards, Torsten. Am 29.05.2012 14:10, schrieb Michiel de Jong: > Hi Torsten, > > No, it should indeed work fine with CORS. CORS is supported by IE8+,=20 > FF, Chrome, Safari and Opera12+ (with limited error handling and=20 > limited verb support in IE8 and IE9, but with POST you should be safe=20 > afaik). > > Note that if you want to support this in combination with implicit=20 > grant flow (unhosted html5 apps), then you need CORS. > > Which made me wonder why you are mentioning JSONP at all? Mentioning=20 > JSONP as a 'MAY' but not mentioning CORS could send people in the=20 > wrong direction IMO. So I would rename the section 'JSONP' to 'CORS=20 > and JSONP', or in general, 'Cross-Origin support', and then start with=20 > a sentence like: > > "The revokation end-point SHOULD support CORS if it is aimed at use in=20 > combination with the implicit-grant flow. For other flows, it is still > recommended(?) to support CORS. In addition, for interop with legacy=20 > user-agents, it MAY offer JSONP. Clients should be aware that when=20 > relying on JSONP, the revokation end-point MAY ;) inject malicious=20 > code into the client." > > You can tell i don't speak spec lingo, but i hope i'm sort of getting=20 > my point across, that IMO, CORS is better here than JSONP. > > Or: simply not mention JSONP at all. Would that be an option? > > > Cheers, > Michiel > > On Sun, May 27, 2012 at 3:05 PM, Torsten Lodderstedt=20 > wrote: >> Hi Michiel, >> >> shouldn't the revocation POST request work fine with CORS? Or is=20 >> there something we need to specify in order to make it work? >> >> best regards, >> Torsten. >> >> Am 27.05.2012 13:20, schrieb Michiel de Jong: >> >>> awesome! just that - first thing that catches the eye right when you=20 >>> skim the table of contents is: >>> >>> why did you use JSONP instead of its CORS? You can read more about=20 >>> CORS >>> here: >>> >>> http://enable-cors.org/ >>> >>> http://en.wikipedia.org/wiki/Cross-origin_resource_sharing#CORS_rela >>> tionship_to_JSONP >>> >>> On Sun, May 27, 2012 at 10:41 AM, wrote: >>>> A New Internet-Draft is available from the on-line Internet-Drafts=20 >>>> directories. This draft is a work item of the Web Authorization=20 >>>> Protocol Working Group of the IETF. >>>> >>>> Title : Token Revocation >>>> Author(s) : Torsten Lodderstedt >>>> Stefanie Dronia >>>> Marius Scurtescu >>>> Filename : draft-ietf-oauth-revocation-00.txt >>>> Pages : 6 >>>> Date : 2012-05-26 >>>> >>>> This draft proposes an additional endpoint for OAuth authorization >>>> servers for revoking tokens. >>>> >>>> >>>> >>>> A URL for this Internet-Draft is: >>>> http://www.ietf.org/internet-drafts/draft-ietf-oauth-revocation-00. >>>> txt >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>> >>>> This Internet-Draft can be retrieved at: >>>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-oauth-revocation-00.t >>>> xt >>>> >>>> The IETF datatracker page for this Internet-Draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-revocation/ >>>> >>>> _______________________________________________ >>>> OAuth mailing 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 sDronia@gmx.de Thu Jun 7 16:31:30 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 996D621F85A0 for ; Thu, 7 Jun 2012 16:31:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJDFEjcE8WCJ for ; Thu, 7 Jun 2012 16:31:29 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id DC7AD21F859B for ; Thu, 7 Jun 2012 16:31:28 -0700 (PDT) Received: (qmail 32518 invoked by uid 0); 7 Jun 2012 23:31:27 -0000 Received: from 203.96.121.170 by www045.gmx.net with HTTP; Fri, 08 Jun 2012 01:31:26 +0200 (CEST) Content-Type: text/plain; charset="utf-8" Date: Fri, 08 Jun 2012 01:31:26 +0200 From: "Stefanie Dronia" In-Reply-To: <4FD0CB80.4050601@lodderstedt.net> Message-ID: <20120607233126.72840@gmx.net> MIME-Version: 1.0 References: <20120527084150.26400.88469.idtracker@ietfa.amsl.com> <4FC226AD.10102@lodderstedt.net> <4FD0CB80.4050601@lodderstedt.net> To: Torsten Lodderstedt , michiel@unhosted.org X-Authenticated: #3259608 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Priority: 3 X-Provags-ID: V01U2FsdGVkX1/7OWdwhU779d1sAZf6OXlH3/dB9En6s1LMwwNBB/ 2r0zwlQ07tvYYFC+hkdXcsshEGR65DHIIZvw== Content-Transfer-Encoding: 8bit X-GMX-UID: mVyjbxB9eSEqTLnfWnQhY6h+IGRvb4CN Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 23:31:30 -0000 Hi, I would prefer to keep the section general as Michiel suggested. Name it 'Cross-Origin support' and list CORS ans JSONP as examples. Could it be possible that other methods for Cross-origin support might come up in future? They would not be excluded than. - Stefanie -------- Original-Nachricht -------- > Datum: Thu, 07 Jun 2012 17:40:48 +0200 > Von: Torsten Lodderstedt > An: Michiel de Jong > CC: oauth@ietf.org, Marius Scurtescu , Stefanie Dronia > Betreff: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-00.txt > Hi Michiel, > > I'm fine with both suggestions (also mentioning CORS or not mentioning > JSONP). What do my co-authors and other WG members think? > > regards, > Torsten. > > Am 29.05.2012 14:10, schrieb Michiel de Jong: > > Hi Torsten, > > > > No, it should indeed work fine with CORS. CORS is supported by IE8+, > > FF, Chrome, Safari and Opera12+ (with limited error handling and > > limited verb support in IE8 and IE9, but with POST you should be safe > > afaik). > > > > Note that if you want to support this in combination with implicit > > grant flow (unhosted html5 apps), then you need CORS. > > > > Which made me wonder why you are mentioning JSONP at all? Mentioning > > JSONP as a 'MAY' but not mentioning CORS could send people in the > > wrong direction IMO. So I would rename the section 'JSONP' to 'CORS > > and JSONP', or in general, 'Cross-Origin support', and then start with > > a sentence like: > > > > "The revokation end-point SHOULD support CORS if it is aimed at use in > > combination with the implicit-grant flow. For other flows, it is still > > recommended(?) to support CORS. In addition, for interop with legacy > > user-agents, it MAY offer JSONP. Clients should be aware that when > > relying on JSONP, the revokation end-point MAY ;) inject malicious > > code into the client." > > > > You can tell i don't speak spec lingo, but i hope i'm sort of getting > > my point across, that IMO, CORS is better here than JSONP. > > > > Or: simply not mention JSONP at all. Would that be an option? > > > > > > Cheers, > > Michiel > > > > On Sun, May 27, 2012 at 3:05 PM, Torsten Lodderstedt > > wrote: > >> Hi Michiel, > >> > >> shouldn't the revocation POST request work fine with CORS? Or is there > >> something we need to specify in order to make it work? > >> > >> best regards, > >> Torsten. > >> > >> Am 27.05.2012 13:20, schrieb Michiel de Jong: > >> > >>> awesome! just that - first thing that catches the eye right when you > >>> skim the table of contents is: > >>> > >>> why did you use JSONP instead of its CORS? You can read more about > CORS > >>> here: > >>> > >>> http://enable-cors.org/ > >>> > >>> > http://en.wikipedia.org/wiki/Cross-origin_resource_sharing#CORS_relationship_to_JSONP > >>> > >>> On Sun, May 27, 2012 at 10:41 AM, 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 : Token Revocation > >>>> Author(s) : Torsten Lodderstedt > >>>> Stefanie Dronia > >>>> Marius Scurtescu > >>>> Filename : draft-ietf-oauth-revocation-00.txt > >>>> Pages : 6 > >>>> Date : 2012-05-26 > >>>> > >>>> This draft proposes an additional endpoint for OAuth authorization > >>>> servers for revoking tokens. > >>>> > >>>> > >>>> > >>>> A URL for this Internet-Draft is: > >>>> > http://www.ietf.org/internet-drafts/draft-ietf-oauth-revocation-00.txt > >>>> > >>>> Internet-Drafts are also available by anonymous FTP at: > >>>> ftp://ftp.ietf.org/internet-drafts/ > >>>> > >>>> This Internet-Draft can be retrieved at: > >>>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-oauth-revocation-00.txt > >>>> > >>>> The IETF datatracker page for this Internet-Draft is: > >>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-revocation/ > >>>> > >>>> _______________________________________________ > >>>> OAuth mailing list > >>>> OAuth@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/oauth > >>> _______________________________________________ > >>> OAuth mailing list > >>> OAuth@ietf.org > >>> https://www.ietf.org/mailman/listinfo/oauth -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de From Michael.Jones@microsoft.com Fri Jun 8 00:56:25 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5202C21F88A7 for ; Fri, 8 Jun 2012 00:56:25 -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 2C25EIVcteLU for ; Fri, 8 Jun 2012 00:56:24 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe005.messaging.microsoft.com [213.199.154.143]) by ietfa.amsl.com (Postfix) with ESMTP id D7A0421F8683 for ; Fri, 8 Jun 2012 00:56:17 -0700 (PDT) Received: from mail90-db3-R.bigfish.com (10.3.81.226) by DB3EHSOBE001.bigfish.com (10.3.84.21) with Microsoft SMTP Server id 14.1.225.23; Fri, 8 Jun 2012 07:55:26 +0000 Received: from mail90-db3 (localhost [127.0.0.1]) by mail90-db3-R.bigfish.com (Postfix) with ESMTP id D6D6930034C for ; Fri, 8 Jun 2012 07:55:26 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -1 X-BigFish: VS-1(zzc85fh1432Izz1202hzz8275bh8275dhz2fh2a8h668h839hd25hf0ah34h) Received-SPF: pass (mail90-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC107.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail90-db3 (localhost.localdomain [127.0.0.1]) by mail90-db3 (MessageSwitch) id 1339142124894787_3589; Fri, 8 Jun 2012 07:55:24 +0000 (UTC) Received: from DB3EHSMHS010.bigfish.com (unknown [10.3.81.232]) by mail90-db3.bigfish.com (Postfix) with ESMTP id CD5682E0049 for ; Fri, 8 Jun 2012 07:55:24 +0000 (UTC) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS010.bigfish.com (10.3.87.110) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 8 Jun 2012 07:55:20 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.189]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.02.0309.003; Fri, 8 Jun 2012 07:56:04 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: Draft OAuth Core spec changes updating proposed ABNF Thread-Index: Ac1FTBJ4eiGFCwuHR/W9+ZRF59FRZA== Date: Fri, 8 Jun 2012 07:56:04 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436652EBF0@TK5EX14MBXC284.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="_006_4E1F6AAD24975D4BA5B16804296739436652EBF0TK5EX14MBXC284r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: [OAUTH-WG] Draft OAuth Core spec changes updating proposed ABNF X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 07:56:25 -0000 --_006_4E1F6AAD24975D4BA5B16804296739436652EBF0TK5EX14MBXC284r_ Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436652EBF0TK5EX14MBXC284r_" --_000_4E1F6AAD24975D4BA5B16804296739436652EBF0TK5EX14MBXC284r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The attached proposed edits to the Core spec update the ABNF to remove the = character set restrictions that working group participants had objected to,= and to define common syntax elements, where appropriate. After working gr= oup review, I believe that these changes are ready to be checked in for dra= ft 27 after being merged with whatever other changes Eran has made. Source, .txt, and .html versions are attached. Diffs for the consequential= changes since my previous set of proposed changes follow. -- Mike 3632,3633c3632,3633 > Some of the definitions that follow use these common definitions: > > VSCHAR =3D %20-7E > NQCHAR =3D %x21 / %x23-5B / %x5D-7E > NQSCHAR =3D %x20-21 / %x23-5B / %x5D-7E 3657c3654 < client-id =3D * --- > client-id =3D *VSCHAR 3666c3663 < client-secret =3D *TEXT --- > client-secret =3D *VSCHAR 3685c3682 < scope-token =3D 1*( %x21 / %x23-5B / %x5D-7E ) --- > scope-token =3D 1*NQCHAR 3686c3684 < state =3D 1*unreserved --- > state =3D 1*VSCHAR 3712c3705 < redirect-uri =3D URI --- > redirect-uri =3D URI-reference 3719,3720c3712 < error =3D 1*error-char < error-char =3D %x20-21 / %x23-5B / %x5D-7E --- > error =3D 1*NQSCHAR 3727,3728c3719 < error-description =3D 1*error-char < error-char =3D %x20-21 / %x23-5B / %x5D-7E --- > error-description =3D 1*NQSCHAR 3735c3726 < error-uri =3D URI --- > error-uri =3D URI-reference 3742c3733 < grant-type =3D grant-name / URI --- > grant-type =3D grant-name / URI-reference 3747c3741 < code =3D 1*unreserved --- > code =3D 1*VSCHAR 3767c3761 < access-token =3D b64token --- > access-token =3D 1*VSCHAR 3774c3768 < token-type =3D type-name / URI --- > token-type =3D type-name / URI-reference 3788c3782 < username =3D * --- > username =3D *( %x20-39 / %x3B-7E ) 3797c3792 < password =3D *TEXT --- > password =3D *VSCHAR 3801c3797 < refresh-token =3D b64token --- > refresh-token =3D 1*VSCHAR --_000_4E1F6AAD24975D4BA5B16804296739436652EBF0TK5EX14MBXC284r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The attached proposed edits to the Core spec update = the ABNF to remove the character set restrictions that working group partic= ipants had objected to, and to define common syntax elements, where appropr= iate.  After working group review, I believe that these changes are ready to be checked in for draft 27 after= being merged with whatever other changes Eran has made.

 

Source, .txt, and .html versions are attached. = Diffs for the consequential changes since my previous set of proposed chan= ges follow.

 

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

 

3632,3633c3632,3633

>    Some of the definitions that = follow use these common definitions:

> 

>    VSCHAR    = ; =3D %20-7E

>    NQCHAR    = ; =3D %x21 / %x23-5B / %x5D-7E

>    NQSCHAR    =3D= %x20-21 / %x23-5B / %x5D-7E

3657c3654

<    client-id   &n= bsp; =3D *<TEXT excluding ":">

---

>    client-id   &n= bsp; =3D *VSCHAR

3666c3663

<    client-secret =3D *TEXT<= /o:p>

---

>    client-secret =3D *VSCHAR

3685c3682

<    scope-token =3D 1*( %x21 / %x= 23-5B / %x5D-7E )

---

>    scope-token =3D 1*NQCHAR=

3686c3684

<    state    =   =3D 1*unreserved

---

>    state    =   =3D 1*VSCHAR

3712c3705

<    redirect-uri   = ;   =3D URI

---

>    redirect-uri   = ;   =3D URI-reference

3719,3720c3712

<    error    =          =3D 1*error-char

<    error-char   &= nbsp;    =3D %x20-21 / %x23-5B / %x5D-7E

---

>    error    =          =3D 1*NQSCHAR

3727,3728c3719

<    error-description =3D 1*error= -char

<    error-char   &= nbsp;    =3D %x20-21 / %x23-5B / %x5D-7E

---

>    error-description =3D 1*NQSCH= AR

3735c3726

<    error-uri   &n= bsp;     =3D URI

---

>    error-uri   &n= bsp;     =3D URI-reference

3742c3733

<    grant-type =3D grant-name / U= RI

---

>    grant-type =3D grant-name / U= RI-reference

3747c3741

<    code    &= nbsp;  =3D 1*unreserved

---

>    code    &= nbsp;  =3D 1*VSCHAR

3767c3761

<    access-token =3D b64token

---

>    access-token =3D 1*VSCHAR

3774c3768

<    token-type =3D type-name / UR= I

---

>    token-type =3D type-name / UR= I-reference

3788c3782

<    username =3D *<TEXT exclud= ing ":">

---

>    username =3D *( %x20-39 / %x3= B-7E )

3797c3792

<    password =3D *TEXT=

---

>    password =3D *VSCHAR

3801c3797

<    refresh-token =3D b64token

---

>    refresh-token =3D 1*VSCHAR

--_000_4E1F6AAD24975D4BA5B16804296739436652EBF0TK5EX14MBXC284r_-- --_006_4E1F6AAD24975D4BA5B16804296739436652EBF0TK5EX14MBXC284r_ Content-Type: text/xml; name="draft-ietf-oauth-v2-26+mbj-4.xml" Content-Description: draft-ietf-oauth-v2-26+mbj-4.xml Content-Disposition: attachment; filename="draft-ietf-oauth-v2-26+mbj-4.xml"; size=187571; creation-date="Tue, 05 Jun 2012 00:37:15 GMT"; modification-date="Fri, 08 Jun 2012 07:45:52 GMT" Content-Transfer-Encoding: base64 PD94bWwgdmVyc2lvbj0nMS4wJyBlbmNvZGluZz0nVVRGLTgnID8+CjwhRE9DVFlQRSByZmMgU1lT VEVNICdyZmMyNjI5LmR0ZCc+Cjw/eG1sLXN0eWxlc2hlZXQgdHlwZT0ndGV4dC94c2wnIGhyZWY9 J3JmYzI2MjkueHNsdCcgPz4KCjxyZmMgY2F0ZWdvcnk9J3N0ZCcgaXByPSd0cnVzdDIwMDkwMicg b2Jzb2xldGVzPSc1ODQ5JyBkb2NOYW1lPSdkcmFmdC1pZXRmLW9hdXRoLXYyLTI3Jz4KICA8P3Jm YyBzdHJpY3Q9J3llcycgPz4KICA8P3JmYyB0b2M9J3llcycgPz4KICA8P3JmYyB0b2NkZXB0aD0n MycgPz4KICA8P3JmYyBzeW1yZWZzPSd5ZXMnID8+CiAgPD9yZmMgc29ydHJlZnM9J3llcycgPz4K ICA8P3JmYyBjb21wYWN0PSd5ZXMnID8+CiAgPD9yZmMgc3ViY29tcGFjdD0neWVzJyA/PgoKICAK ICA8ZnJvbnQ+CiAgICA8dGl0bGUgYWJicmV2PSdPQXV0aCAyLjAnPlRoZSBPQXV0aCAyLjAgQXV0 aG9yaXphdGlvbiBGcmFtZXdvcms8L3RpdGxlPgoKICAgIDxhdXRob3IgZnVsbG5hbWU9J0VyYW4g SGFtbWVyJyBzdXJuYW1lPSdIYW1tZXInIGluaXRpYWxzPSdFJyByb2xlPSdlZGl0b3InPgogICAg ICA8b3JnYW5pemF0aW9uPjwvb3JnYW5pemF0aW9uPgogICAgICA8YWRkcmVzcz4KICAgICAgICA8 ZW1haWw+ZXJhbkBodWVuaXZlcnNlLmNvbTwvZW1haWw+CiAgICAgICAgPHVyaT5odHRwOi8vaHVl bml2ZXJzZS5jb208L3VyaT4KICAgICAgPC9hZGRyZXNzPgogICAgPC9hdXRob3I+CiAgICA8YXV0 aG9yIGZ1bGxuYW1lPSdEYXZpZCBSZWNvcmRvbicgc3VybmFtZT0nUmVjb3Jkb24nIGluaXRpYWxz PSdEJz4KICAgICAgPG9yZ2FuaXphdGlvbj5GYWNlYm9vazwvb3JnYW5pemF0aW9uPgogICAgICA8 YWRkcmVzcz4KICAgICAgICA8ZW1haWw+ZHJAZmIuY29tPC9lbWFpbD4KICAgICAgICA8dXJpPmh0 dHA6Ly93d3cuZGF2aWRyZWNvcmRvbi5jb20vPC91cmk+CiAgICAgIDwvYWRkcmVzcz4KICAgIDwv YXV0aG9yPgogICAgPGF1dGhvciBmdWxsbmFtZT0nRGljayBIYXJkdCcgc3VybmFtZT0nSGFyZHQn IGluaXRpYWxzPSdEJz4KICAgICAgPG9yZ2FuaXphdGlvbj5NaWNyb3NvZnQ8L29yZ2FuaXphdGlv bj4KICAgICAgPGFkZHJlc3M+CiAgICAgICAgPGVtYWlsPmRpY2suaGFyZHRAZ21haWwuY29tPC9l bWFpbD4KICAgICAgICA8dXJpPmh0dHA6Ly9kaWNraGFyZHQub3JnLzwvdXJpPgogICAgICA8L2Fk ZHJlc3M+CiAgICA8L2F1dGhvcj4KCiAgICA8ZGF0ZSB5ZWFyPScyMDEyJyAvPgoKICAgIDxhcmVh PlNlY3VyaXR5PC9hcmVhPgogICAgPHdvcmtncm91cD5PQXV0aCBXb3JraW5nIEdyb3VwPC93b3Jr Z3JvdXA+CgogICAgPGFic3RyYWN0PgogICAgICA8dD4KICAgICAgICBUaGUgT0F1dGggMi4wIGF1 dGhvcml6YXRpb24gZnJhbWV3b3JrIGVuYWJsZXMgYSB0aGlyZC1wYXJ0eSBhcHBsaWNhdGlvbiB0 byBvYnRhaW4gbGltaXRlZAogICAgICAgIGFjY2VzcyB0byBhbiBIVFRQIHNlcnZpY2UsIGVpdGhl ciBvbiBiZWhhbGYgb2YgYSByZXNvdXJjZSBvd25lciBieSBvcmNoZXN0cmF0aW5nIGFuIGFwcHJv dmFsCiAgICAgICAgaW50ZXJhY3Rpb24gYmV0d2VlbiB0aGUgcmVzb3VyY2Ugb3duZXIgYW5kIHRo ZSBIVFRQIHNlcnZpY2UsIG9yIGJ5IGFsbG93aW5nIHRoZSB0aGlyZC1wYXJ0eQogICAgICAgIGFw cGxpY2F0aW9uIHRvIG9idGFpbiBhY2Nlc3Mgb24gaXRzIG93biBiZWhhbGYuIFRoaXMgc3BlY2lm aWNhdGlvbiByZXBsYWNlcyBhbmQgb2Jzb2xldGVzCiAgICAgICAgdGhlIE9BdXRoIDEuMCBwcm90 b2NvbCBkZXNjcmliZWQgaW4gUkZDIDU4NDkuCiAgICAgIDwvdD4KICAgIDwvYWJzdHJhY3Q+CiAg PC9mcm9udD4KCiAgPG1pZGRsZT4KCiAgICA8c2VjdGlvbiB0aXRsZT0nSW50cm9kdWN0aW9uJz4K ICAgICAgPHQ+CiAgICAgICAgSW4gdGhlIHRyYWRpdGlvbmFsIGNsaWVudC1zZXJ2ZXIgYXV0aGVu dGljYXRpb24gbW9kZWwsIHRoZSBjbGllbnQgcmVxdWVzdHMgYW4gYWNjZXNzCiAgICAgICAgcmVz dHJpY3RlZCByZXNvdXJjZSAocHJvdGVjdGVkIHJlc291cmNlKSBvbiB0aGUgc2VydmVyIGJ5IGF1 dGhlbnRpY2F0aW5nIHdpdGggdGhlIHNlcnZlcgogICAgICAgIHVzaW5nIHRoZSByZXNvdXJjZSBv d25lcidzIGNyZWRlbnRpYWxzLiBJbiBvcmRlciB0byBwcm92aWRlIHRoaXJkLXBhcnR5IGFwcGxp Y2F0aW9ucyBhY2Nlc3MKICAgICAgICB0byByZXN0cmljdGVkIHJlc291cmNlcywgdGhlIHJlc291 cmNlIG93bmVyIHNoYXJlcyBpdHMgY3JlZGVudGlhbHMgd2l0aCB0aGUgdGhpcmQtcGFydHkuCiAg ICAgICAgVGhpcyBjcmVhdGVzIHNldmVyYWwgcHJvYmxlbXMgYW5kIGxpbWl0YXRpb25zOgogICAg ICA8L3Q+CiAgICAgIDx0PgogICAgICAgIDxsaXN0IHN0eWxlPSdzeW1ib2xzJz4KICAgICAgICAg IDx0PgogICAgICAgICAgICBUaGlyZC1wYXJ0eSBhcHBsaWNhdGlvbnMgYXJlIHJlcXVpcmVkIHRv IHN0b3JlIHRoZSByZXNvdXJjZSBvd25lcidzIGNyZWRlbnRpYWxzCiAgICAgICAgICAgIGZvciBm dXR1cmUgdXNlLCB0eXBpY2FsbHkgYSBwYXNzd29yZCBpbiBjbGVhci10ZXh0LgogICAgICAgICAg PC90PgogICAgICAgICAgPHQ+CiAgICAgICAgICAgIFNlcnZlcnMgYXJlIHJlcXVpcmVkIHRvIHN1 cHBvcnQgcGFzc3dvcmQgYXV0aGVudGljYXRpb24sIGRlc3BpdGUgdGhlIHNlY3VyaXR5CiAgICAg ICAgICAgIHdlYWtuZXNzZXMgaW5oZXJlbnQgaW4gcGFzc3dvcmRzLgogICAgICAgICAgPC90Pgog ICAgICAgICAgPHQ+CiAgICAgICAgICAgIFRoaXJkLXBhcnR5IGFwcGxpY2F0aW9ucyBnYWluIG92 ZXJseSBicm9hZCBhY2Nlc3MgdG8gdGhlIHJlc291cmNlIG93bmVyJ3MgcHJvdGVjdGVkCiAgICAg ICAgICAgIHJlc291cmNlcywgbGVhdmluZyByZXNvdXJjZSBvd25lcnMgd2l0aG91dCBhbnkgYWJp bGl0eSB0byByZXN0cmljdCBkdXJhdGlvbiBvciBhY2Nlc3MKICAgICAgICAgICAgdG8gYSBsaW1p dGVkIHN1YnNldCBvZiByZXNvdXJjZXMuCiAgICAgICAgICA8L3Q+CiAgICAgICAgICA8dD4KICAg ICAgICAgICAgUmVzb3VyY2Ugb3duZXJzIGNhbm5vdCByZXZva2UgYWNjZXNzIHRvIGFuIGluZGl2 aWR1YWwgdGhpcmQtcGFydHkgd2l0aG91dCByZXZva2luZwogICAgICAgICAgICBhY2Nlc3MgdG8g YWxsIHRoaXJkLXBhcnRpZXMsIGFuZCBtdXN0IGRvIHNvIGJ5IGNoYW5naW5nIHRoZWlyIHBhc3N3 b3JkLgogICAgICAgICAgPC90PgogICAgICAgICAgPHQ+CiAgICAgICAgICAgIENvbXByb21pc2Ug b2YgYW55IHRoaXJkLXBhcnR5IGFwcGxpY2F0aW9uIHJlc3VsdHMgaW4gY29tcHJvbWlzZSBvZiB0 aGUgZW5kLXVzZXIncwogICAgICAgICAgICBwYXNzd29yZCBhbmQgYWxsIG9mIHRoZSBkYXRhIHBy b3RlY3RlZCBieSB0aGF0IHBhc3N3b3JkLgogICAgICAgICAgPC90PgogICAgICAgIDwvbGlzdD4K ICAgICAgPC90PgogICAgICA8dD4KICAgICAgICBPQXV0aCBhZGRyZXNzZXMgdGhlc2UgaXNzdWVz IGJ5IGludHJvZHVjaW5nIGFuIGF1dGhvcml6YXRpb24gbGF5ZXIgYW5kIHNlcGFyYXRpbmcgdGhl IHJvbGUKICAgICAgICBvZiB0aGUgY2xpZW50IGZyb20gdGhhdCBvZiB0aGUgcmVzb3VyY2Ugb3du ZXIuIEluIE9BdXRoLCB0aGUgY2xpZW50IHJlcXVlc3RzIGFjY2VzcyB0bwogICAgICAgIHJlc291 cmNlcyBjb250cm9sbGVkIGJ5IHRoZSByZXNvdXJjZSBvd25lciBhbmQgaG9zdGVkIGJ5IHRoZSBy ZXNvdXJjZSBzZXJ2ZXIsIGFuZCBpcyBpc3N1ZWQKICAgICAgICBhIGRpZmZlcmVudCBzZXQgb2Yg Y3JlZGVudGlhbHMgdGhhbiB0aG9zZSBvZiB0aGUgcmVzb3VyY2Ugb3duZXIuCiAgICAgIDwvdD4K ICAgICAgPHQ+CiAgICAgICAgSW5zdGVhZCBvZiB1c2luZyB0aGUgcmVzb3VyY2Ugb3duZXIncyBj cmVkZW50aWFscyB0byBhY2Nlc3MgcHJvdGVjdGVkIHJlc291cmNlcywgdGhlIGNsaWVudAogICAg ICAgIG9idGFpbnMgYW4gYWNjZXNzIHRva2VuIC0gYSBzdHJpbmcgZGVub3RpbmcgYSBzcGVjaWZp YyBzY29wZSwgbGlmZXRpbWUsIGFuZCBvdGhlciBhY2Nlc3MKICAgICAgICBhdHRyaWJ1dGVzLiBB Y2Nlc3MgdG9rZW5zIGFyZSBpc3N1ZWQgdG8gdGhpcmQtcGFydHkgY2xpZW50cyBieSBhbiBhdXRo b3JpemF0aW9uIHNlcnZlciB3aXRoCiAgICAgICAgdGhlIGFwcHJvdmFsIG9mIHRoZSByZXNvdXJj ZSBvd25lci4gVGhlIGNsaWVudCB1c2VzIHRoZSBhY2Nlc3MgdG9rZW4gdG8gYWNjZXNzIHRoZQog ICAgICAgIHByb3RlY3RlZCByZXNvdXJjZXMgaG9zdGVkIGJ5IHRoZSByZXNvdXJjZSBzZXJ2ZXIu CiAgICAgIDwvdD4KICAgICAgPHQ+CiAgICAgICAgRm9yIGV4YW1wbGUsIGFuIGVuZC11c2VyIChy ZXNvdXJjZSBvd25lcikgY2FuIGdyYW50IGEgcHJpbnRpbmcgc2VydmljZSAoY2xpZW50KSBhY2Nl c3MKICAgICAgICB0byBoZXIgcHJvdGVjdGVkIHBob3RvcyBzdG9yZWQgYXQgYSBwaG90byBzaGFy aW5nIHNlcnZpY2UgKHJlc291cmNlIHNlcnZlciksIHdpdGhvdXQKICAgICAgICBzaGFyaW5nIGhl ciB1c2VybmFtZSBhbmQgcGFzc3dvcmQgd2l0aCB0aGUgcHJpbnRpbmcgc2VydmljZS4gSW5zdGVh ZCwgc2hlIGF1dGhlbnRpY2F0ZXMKICAgICAgICBkaXJlY3RseSB3aXRoIGEgc2VydmVyIHRydXN0 ZWQgYnkgdGhlIHBob3RvIHNoYXJpbmcgc2VydmljZSAoYXV0aG9yaXphdGlvbiBzZXJ2ZXIpIHdo aWNoCiAgICAgICAgaXNzdWVzIHRoZSBwcmludGluZyBzZXJ2aWNlIGRlbGVnYXRpb24tc3BlY2lm aWMgY3JlZGVudGlhbHMgKGFjY2VzcyB0b2tlbikuCiAgICAgIDwvdD4KICAgICAgPHQ+CiAgICAg ICAgVGhpcyBzcGVjaWZpY2F0aW9uIGlzIGRlc2lnbmVkIGZvciB1c2Ugd2l0aCBIVFRQICg8eHJl ZiB0YXJnZXQ9J1JGQzI2MTYnIC8+KS4gVGhlIHVzZSBvZgogICAgICAgIE9BdXRoIG92ZXIgYW55 IG90aGVyIHByb3RvY29sIHRoYW4gSFRUUCBpcyBvdXQgb2Ygc2NvcGUuCiAgICAgIDwvdD4KICAg ICAgPHQ+CiAgICAgICAgVGhlIE9BdXRoIDEuMCBwcm90b2NvbCAoPHhyZWYgdGFyZ2V0PSdSRkM1 ODQ5JyAvPiksIHB1Ymxpc2hlZCBhcyBhbiBpbmZvcm1hdGlvbmFsIGRvY3VtZW50LAogICAgICAg IHdhcyB0aGUgcmVzdWx0IG9mIGEgc21hbGwgYWQtaG9jIGNvbW11bml0eSBlZmZvcnQuIFRoaXMg c3RhbmRhcmRzLXRyYWNrIHNwZWNpZmljYXRpb24gYnVpbGRzCiAgICAgICAgb24gdGhlIE9BdXRo IDEuMCBkZXBsb3ltZW50IGV4cGVyaWVuY2UsIGFzIHdlbGwgYXMgYWRkaXRpb25hbCB1c2UgY2Fz ZXMgYW5kIGV4dGVuc2liaWxpdHkKICAgICAgICByZXF1aXJlbWVudHMgZ2F0aGVyZWQgZnJvbSB0 aGUgd2lkZXIgSUVURiBjb21tdW5pdHkuIFRoZSBPQXV0aCAyLjAgcHJvdG9jb2wgaXMgbm90IGJh Y2t3YXJkCiAgICAgICAgY29tcGF0aWJsZSB3aXRoIE9BdXRoIDEuMC4gVGhlIHR3byB2ZXJzaW9u cyBtYXkgY28tZXhpc3Qgb24gdGhlIG5ldHdvcmsgYW5kIGltcGxlbWVudGF0aW9ucwogICAgICAg IG1heSBjaG9vc2UgdG8gc3VwcG9ydCBib3RoLiBIb3dldmVyLCBpdCBpcyB0aGUgaW50ZW50aW9u IG9mIHRoaXMgc3BlY2lmaWNhdGlvbiB0aGF0IG5ldwogICAgICAgIGltcGxlbWVudGF0aW9uIHN1 cHBvcnQgT0F1dGggMi4wIGFzIHNwZWNpZmllZCBpbiB0aGlzIGRvY3VtZW50LCBhbmQgdGhhdCBP QXV0aCAxLjAgaXMgdXNlZAogICAgICAgIG9ubHkgdG8gc3VwcG9ydCBleGlzdGluZyBkZXBsb3lt ZW50cy4gVGhlIE9BdXRoIDIuMCBwcm90b2NvbCBzaGFyZXMgdmVyeSBmZXcgaW1wbGVtZW50YXRp b24KICAgICAgICBkZXRhaWxzIHdpdGggdGhlIE9BdXRoIDEuMCBwcm90b2NvbC4gSW1wbGVtZW50 ZXJzIGZhbWlsaWFyIHdpdGggT0F1dGggMS4wIHNob3VsZCBhcHByb2FjaAogICAgICAgIHRoaXMg ZG9jdW1lbnQgd2l0aG91dCBhbnkgYXNzdW1wdGlvbnMgYXMgdG8gaXRzIHN0cnVjdHVyZSBhbmQg ZGV0YWlscy4KICAgICAgPC90PgoKICAgICAgPHNlY3Rpb24gdGl0bGU9J1JvbGVzJz4KICAgICAg ICA8dD4KICAgICAgICAgIE9BdXRoIGRlZmluZXMgZm91ciByb2xlczoKICAgICAgICA8L3Q+CiAg ICAgICAgPHQ+CiAgICAgICAgICA8bGlzdCBzdHlsZT0naGFuZ2luZyc+CiAgICAgICAgICAgIDx0 IGhhbmdUZXh0PSdyZXNvdXJjZSBvd25lcic+CiAgICAgICAgICAgICAgPHZzcGFjZSAvPgogICAg ICAgICAgICAgIEFuIGVudGl0eSBjYXBhYmxlIG9mIGdyYW50aW5nIGFjY2VzcyB0byBhIHByb3Rl Y3RlZCByZXNvdXJjZS4gV2hlbiB0aGUgcmVzb3VyY2Ugb3duZXIKICAgICAgICAgICAgICBpcyBh IHBlcnNvbiwgaXQgaXMgcmVmZXJyZWQgdG8gYXMgYW4gZW5kLXVzZXIuCiAgICAgICAgICAgIDwv dD4KICAgICAgICAgICAgPHQgaGFuZ1RleHQ9J3Jlc291cmNlIHNlcnZlcic+CiAgICAgICAgICAg ICAgPHZzcGFjZSAvPgogICAgICAgICAgICAgIFRoZSBzZXJ2ZXIgaG9zdGluZyB0aGUgcHJvdGVj dGVkIHJlc291cmNlcywgY2FwYWJsZSBvZiBhY2NlcHRpbmcgYW5kIHJlc3BvbmRpbmcgdG8KICAg ICAgICAgICAgICBwcm90ZWN0ZWQgcmVzb3VyY2UgcmVxdWVzdHMgdXNpbmcgYWNjZXNzIHRva2Vu cy4KICAgICAgICAgICAgPC90PgogICAgICAgICAgICA8dCBoYW5nVGV4dD0nY2xpZW50Jz4KICAg ICAgICAgICAgICA8dnNwYWNlIC8+CiAgICAgICAgICAgICAgQW4gYXBwbGljYXRpb24gbWFraW5n IHByb3RlY3RlZCByZXNvdXJjZSByZXF1ZXN0cyBvbiBiZWhhbGYgb2YgdGhlIHJlc291cmNlIG93 bmVyIGFuZAogICAgICAgICAgICAgIHdpdGggaXRzIGF1dGhvcml6YXRpb24uIFRoZSB0ZXJtIGNs aWVudCBkb2VzIG5vdCBpbXBseSBhbnkgcGFydGljdWxhciBpbXBsZW1lbnRhdGlvbgogICAgICAg ICAgICAgIGNoYXJhY3RlcmlzdGljcyAoZS5nLiB3aGV0aGVyIHRoZSBhcHBsaWNhdGlvbiBleGVj dXRlcyBvbiBhIHNlcnZlciwgYSBkZXNrdG9wLCBvcgogICAgICAgICAgICAgIG90aGVyIGRldmlj ZXMpLgogICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgIDx0IGhhbmdUZXh0PSdhdXRob3JpemF0 aW9uIHNlcnZlcic+CiAgICAgICAgICAgICAgPHZzcGFjZSAvPgogICAgICAgICAgICAgIFRoZSBz ZXJ2ZXIgaXNzdWluZyBhY2Nlc3MgdG9rZW5zIHRvIHRoZSBjbGllbnQgYWZ0ZXIgc3VjY2Vzc2Z1 bGx5IGF1dGhlbnRpY2F0aW5nIHRoZQogICAgICAgICAgICAgIHJlc291cmNlIG93bmVyIGFuZCBv YnRhaW5pbmcgYXV0aG9yaXphdGlvbi4KICAgICAgICAgICAgPC90PgogICAgICAgICAgPC9saXN0 PgogICAgICAgIDwvdD4KICAgICAgICA8dD4KICAgICAgICAgIFRoZSBpbnRlcmFjdGlvbiBiZXR3 ZWVuIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBhbmQgcmVzb3VyY2Ugc2VydmVyIGlzIGJleW9u ZCB0aGUgc2NvcGUKICAgICAgICAgIG9mIHRoaXMgc3BlY2lmaWNhdGlvbi4gVGhlIGF1dGhvcml6 YXRpb24gc2VydmVyIG1heSBiZSB0aGUgc2FtZSBzZXJ2ZXIgYXMgdGhlIHJlc291cmNlCiAgICAg ICAgICBzZXJ2ZXIgb3IgYSBzZXBhcmF0ZSBlbnRpdHkuIEEgc2luZ2xlIGF1dGhvcml6YXRpb24g c2VydmVyIG1heSBpc3N1ZSBhY2Nlc3MgdG9rZW5zCiAgICAgICAgICBhY2NlcHRlZCBieSBtdWx0 aXBsZSByZXNvdXJjZSBzZXJ2ZXJzLgogICAgICAgIDwvdD4KICAgICAgPC9zZWN0aW9uPgoKICAg ICAgPHNlY3Rpb24gdGl0bGU9J1Byb3RvY29sIEZsb3cnPgogICAgICAgIDxmaWd1cmUgdGl0bGU9 J0Fic3RyYWN0IFByb3RvY29sIEZsb3cnIGFuY2hvcj0nRmlndXJlLTEnPgogICAgICAgICAgPGFy dHdvcms+CiAgICAgICAgICAgIDwhW0NEQVRBWwogICstLS0tLS0tLSsgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLSsKICB8ICAgICAgICB8LS0oQSktIEF1dGhv cml6YXRpb24gUmVxdWVzdCAtPnwgICBSZXNvdXJjZSAgICB8CiAgfCAgICAgICAgfCAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB8ICAgICBPd25lciAgICAgfAogIHwgICAgICAgIHw8LShC KS0tIEF1dGhvcml6YXRpb24gR3JhbnQgLS0tfCAgICAgICAgICAgICAgIHwKICB8ICAgICAgICB8 ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0rCiAgfCAgICAg ICAgfAogIHwgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0t LS0tLS0tLSsKICB8ICAgICAgICB8LS0oQyktLSBBdXRob3JpemF0aW9uIEdyYW50IC0tPnwgQXV0 aG9yaXphdGlvbiB8CiAgfCBDbGllbnQgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8 ICAgICBTZXJ2ZXIgICAgfAogIHwgICAgICAgIHw8LShEKS0tLS0tIEFjY2VzcyBUb2tlbiAtLS0t LS0tfCAgICAgICAgICAgICAgIHwKICB8ICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICstLS0tLS0tLS0tLS0tLS0rCiAgfCAgICAgICAgfAogIHwgICAgICAgIHwgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLSsKICB8ICAgICAgICB8LS0o RSktLS0tLSBBY2Nlc3MgVG9rZW4gLS0tLS0tPnwgICAgUmVzb3VyY2UgICB8CiAgfCAgICAgICAg fCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICBTZXJ2ZXIgICAgfAogIHwgICAg ICAgIHw8LShGKS0tLSBQcm90ZWN0ZWQgUmVzb3VyY2UgLS0tfCAgICAgICAgICAgICAgIHwKICAr LS0tLS0tLS0rICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0r Cl1dPgogICAgICAgICAgPC9hcnR3b3JrPgogICAgICAgIDwvZmlndXJlPgogICAgICAgIDx0Pgog ICAgICAgICAgVGhlIGFic3RyYWN0IGZsb3cgaWxsdXN0cmF0ZWQgaW4gPHhyZWYgdGFyZ2V0PSdG aWd1cmUtMScgLz4gZGVzY3JpYmVzIHRoZSBpbnRlcmFjdGlvbgogICAgICAgICAgYmV0d2VlbiB0 aGUgZm91ciByb2xlcyBhbmQgaW5jbHVkZXMgdGhlIGZvbGxvd2luZyBzdGVwczoKICAgICAgICA8 L3Q+CiAgICAgICAgPHQ+CiAgICAgICAgICA8bGlzdCBzdHlsZT0nZm9ybWF0ICglQyknPgogICAg ICAgICAgICA8dD4KICAgICAgICAgICAgICBUaGUgY2xpZW50IHJlcXVlc3RzIGF1dGhvcml6YXRp b24gZnJvbSB0aGUgcmVzb3VyY2Ugb3duZXIuIFRoZSBhdXRob3JpemF0aW9uIHJlcXVlc3QKICAg ICAgICAgICAgICBjYW4gYmUgbWFkZSBkaXJlY3RseSB0byB0aGUgcmVzb3VyY2Ugb3duZXIgKGFz IHNob3duKSwgb3IgcHJlZmVyYWJseSBpbmRpcmVjdGx5IHZpYQogICAgICAgICAgICAgIHRoZSBh dXRob3JpemF0aW9uIHNlcnZlciBhcyBhbiBpbnRlcm1lZGlhcnkuCiAgICAgICAgICAgIDwvdD4K ICAgICAgICAgICAgPHQ+CiAgICAgICAgICAgICAgVGhlIGNsaWVudCByZWNlaXZlcyBhbiBhdXRo b3JpemF0aW9uIGdyYW50IHdoaWNoIGlzIGEgY3JlZGVudGlhbCByZXByZXNlbnRpbmcKICAgICAg ICAgICAgICB0aGUgcmVzb3VyY2Ugb3duZXIncyBhdXRob3JpemF0aW9uLCBleHByZXNzZWQgdXNp bmcgb25lIG9mIGZvdXIgZ3JhbnQgdHlwZXMgZGVmaW5lZAogICAgICAgICAgICAgIGluIHRoaXMg c3BlY2lmaWNhdGlvbiBvciB1c2luZyBhbiBleHRlbnNpb24gZ3JhbnQgdHlwZS4gVGhlIGF1dGhv cml6YXRpb24gZ3JhbnQgdHlwZQogICAgICAgICAgICAgIGRlcGVuZHMgb24gdGhlIG1ldGhvZCB1 c2VkIGJ5IHRoZSBjbGllbnQgdG8gcmVxdWVzdCBhdXRob3JpemF0aW9uIGFuZCB0aGUgdHlwZXMK ICAgICAgICAgICAgICBzdXBwb3J0ZWQgYnkgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLgogICAg ICAgICAgICA8L3Q+CiAgICAgICAgICAgIDx0PgogICAgICAgICAgICAgIFRoZSBjbGllbnQgcmVx dWVzdHMgYW4gYWNjZXNzIHRva2VuIGJ5IGF1dGhlbnRpY2F0aW5nIHdpdGggdGhlIGF1dGhvcml6 YXRpb24gc2VydmVyCiAgICAgICAgICAgICAgYW5kIHByZXNlbnRpbmcgdGhlIGF1dGhvcml6YXRp b24gZ3JhbnQuCiAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAgPHQ+CiAgICAgICAgICAgICAg VGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGF1dGhlbnRpY2F0ZXMgdGhlIGNsaWVudCBhbmQgdmFs aWRhdGVzIHRoZSBhdXRob3JpemF0aW9uCiAgICAgICAgICAgICAgZ3JhbnQsIGFuZCBpZiB2YWxp ZCBpc3N1ZXMgYW4gYWNjZXNzIHRva2VuLgogICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgIDx0 PgogICAgICAgICAgICAgIFRoZSBjbGllbnQgcmVxdWVzdHMgdGhlIHByb3RlY3RlZCByZXNvdXJj ZSBmcm9tIHRoZSByZXNvdXJjZSBzZXJ2ZXIgYW5kIGF1dGhlbnRpY2F0ZXMKICAgICAgICAgICAg ICBieSBwcmVzZW50aW5nIHRoZSBhY2Nlc3MgdG9rZW4uCiAgICAgICAgICAgIDwvdD4KICAgICAg ICAgICAgPHQ+CiAgICAgICAgICAgICAgVGhlIHJlc291cmNlIHNlcnZlciB2YWxpZGF0ZXMgdGhl IGFjY2VzcyB0b2tlbiwgYW5kIGlmIHZhbGlkLCBzZXJ2ZXMgdGhlIHJlcXVlc3QuCiAgICAgICAg ICAgIDwvdD4KICAgICAgICAgIDwvbGlzdD4KICAgICAgICA8L3Q+CiAgICAgICAgPHQ+CiAgICAg ICAgICBUaGUgcHJlZmVycmVkIG1ldGhvZCBmb3IgdGhlIGNsaWVudCB0byBvYnRhaW4gYW4gYXV0 aG9yaXphdGlvbiBncmFudCBmcm9tIHRoZSByZXNvdXJjZQogICAgICAgICAgb3duZXIgKGRlcGlj dGVkIGluIHN0ZXBzIChBKSBhbmQgKEIpKSBpcyB0byB1c2UgdGhlIGF1dGhvcml6YXRpb24gc2Vy dmVyIGFzIGFuIGludGVybWVkaWFyeQogICAgICAgICAgd2hpY2ggaXMgaWxsdXN0cmF0ZWQgaW4g PHhyZWYgdGFyZ2V0PSdGaWd1cmUtMycgLz4uCiAgICAgICAgPC90PgogICAgICA8L3NlY3Rpb24+ CgogICAgICA8c2VjdGlvbiB0aXRsZT0nQXV0aG9yaXphdGlvbiBHcmFudCc+CiAgICAgICAgPHQ+ CiAgICAgICAgICBBbiBhdXRob3JpemF0aW9uIGdyYW50IGlzIGEgY3JlZGVudGlhbCByZXByZXNl bnRpbmcgdGhlIHJlc291cmNlIG93bmVyJ3MgYXV0aG9yaXphdGlvbgogICAgICAgICAgKHRvIGFj Y2VzcyBpdHMgcHJvdGVjdGVkIHJlc291cmNlcykgdXNlZCBieSB0aGUgY2xpZW50IHRvIG9idGFp biBhbiBhY2Nlc3MgdG9rZW4uIFRoaXMKICAgICAgICAgIHNwZWNpZmljYXRpb24gZGVmaW5lcyBm b3VyIGdyYW50IHR5cGVzOiBhdXRob3JpemF0aW9uIGNvZGUsIGltcGxpY2l0LCByZXNvdXJjZSBv d25lcgogICAgICAgICAgcGFzc3dvcmQgY3JlZGVudGlhbHMsIGFuZCBjbGllbnQgY3JlZGVudGlh bHMsIGFzIHdlbGwgYXMgYW4gZXh0ZW5zaWJpbGl0eSBtZWNoYW5pc20gZm9yCiAgICAgICAgICBk ZWZpbmluZyBhZGRpdGlvbmFsIHR5cGVzLgogICAgICAgIDwvdD4KCiAgICAgICAgPHNlY3Rpb24g dGl0bGU9J0F1dGhvcml6YXRpb24gQ29kZSc+CiAgICAgICAgICA8dD4KICAgICAgICAgICAgVGhl IGF1dGhvcml6YXRpb24gY29kZSBpcyBvYnRhaW5lZCBieSB1c2luZyBhbiBhdXRob3JpemF0aW9u IHNlcnZlciBhcyBhbiBpbnRlcm1lZGlhcnkKICAgICAgICAgICAgYmV0d2VlbiB0aGUgY2xpZW50 IGFuZCByZXNvdXJjZSBvd25lci4gSW5zdGVhZCBvZiByZXF1ZXN0aW5nIGF1dGhvcml6YXRpb24g ZGlyZWN0bHkKICAgICAgICAgICAgZnJvbSB0aGUgcmVzb3VyY2Ugb3duZXIsIHRoZSBjbGllbnQg ZGlyZWN0cyB0aGUgcmVzb3VyY2Ugb3duZXIgdG8gYW4gYXV0aG9yaXphdGlvbgogICAgICAgICAg ICBzZXJ2ZXIgKHZpYSBpdHMgdXNlci1hZ2VudCBhcyBkZWZpbmVkIGluIDx4cmVmIHRhcmdldD0n UkZDMjYxNicgLz4pLCB3aGljaCBpbiB0dXJuCiAgICAgICAgICAgIGRpcmVjdHMgdGhlIHJlc291 cmNlIG93bmVyIGJhY2sgdG8gdGhlIGNsaWVudCB3aXRoIHRoZSBhdXRob3JpemF0aW9uIGNvZGUu CiAgICAgICAgICA8L3Q+CiAgICAgICAgICA8dD4KICAgICAgICAgICAgQmVmb3JlIGRpcmVjdGlu ZyB0aGUgcmVzb3VyY2Ugb3duZXIgYmFjayB0byB0aGUgY2xpZW50IHdpdGggdGhlIGF1dGhvcml6 YXRpb24gY29kZSwgdGhlCiAgICAgICAgICAgIGF1dGhvcml6YXRpb24gc2VydmVyIGF1dGhlbnRp Y2F0ZXMgdGhlIHJlc291cmNlIG93bmVyIGFuZCBvYnRhaW5zIGF1dGhvcml6YXRpb24uCiAgICAg ICAgICAgIEJlY2F1c2UgdGhlIHJlc291cmNlIG93bmVyIG9ubHkgYXV0aGVudGljYXRlcyB3aXRo IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciwgdGhlCiAgICAgICAgICAgIHJlc291cmNlIG93bmVy J3MgY3JlZGVudGlhbHMgYXJlIG5ldmVyIHNoYXJlZCB3aXRoIHRoZSBjbGllbnQuCiAgICAgICAg ICA8L3Q+CiAgICAgICAgICA8dD4KICAgICAgICAgICAgVGhlIGF1dGhvcml6YXRpb24gY29kZSBw cm92aWRlcyBhIGZldyBpbXBvcnRhbnQgc2VjdXJpdHkgYmVuZWZpdHMgc3VjaCBhcyB0aGUgYWJp bGl0eQogICAgICAgICAgICB0byBhdXRoZW50aWNhdGUgdGhlIGNsaWVudCwgYW5kIHRoZSB0cmFu c21pc3Npb24gb2YgdGhlIGFjY2VzcyB0b2tlbiBkaXJlY3RseSB0bwogICAgICAgICAgICB0aGUg Y2xpZW50IHdpdGhvdXQgcGFzc2luZyBpdCB0aHJvdWdoIHRoZSByZXNvdXJjZSBvd25lcidzIHVz ZXItYWdlbnQsIHBvdGVudGlhbGx5CiAgICAgICAgICAgIGV4cG9zaW5nIGl0IHRvIG90aGVycywg aW5jbHVkaW5nIHRoZSByZXNvdXJjZSBvd25lci4KICAgICAgICAgIDwvdD4KICAgICAgICA8L3Nl Y3Rpb24+CgogICAgICAgIDxzZWN0aW9uIHRpdGxlPSdJbXBsaWNpdCc+CiAgICAgICAgICA8dD4K ICAgICAgICAgICAgVGhlIGltcGxpY2l0IGdyYW50IGlzIGEgc2ltcGxpZmllZCBhdXRob3JpemF0 aW9uIGNvZGUgZmxvdyBvcHRpbWl6ZWQgZm9yIGNsaWVudHMKICAgICAgICAgICAgaW1wbGVtZW50 ZWQgaW4gYSBicm93c2VyIHVzaW5nIGEgc2NyaXB0aW5nIGxhbmd1YWdlIHN1Y2ggYXMgSmF2YVNj cmlwdC4gSW4gdGhlIGltcGxpY2l0CiAgICAgICAgICAgIGZsb3csIGluc3RlYWQgb2YgaXNzdWlu ZyB0aGUgY2xpZW50IGFuIGF1dGhvcml6YXRpb24gY29kZSwgdGhlIGNsaWVudCBpcyBpc3N1ZWQg YW4KICAgICAgICAgICAgYWNjZXNzIHRva2VuIGRpcmVjdGx5IChhcyB0aGUgcmVzdWx0IG9mIHRo ZSByZXNvdXJjZSBvd25lciBhdXRob3JpemF0aW9uKS4gVGhlIGdyYW50CiAgICAgICAgICAgIHR5 cGUgaXMgaW1wbGljaXQgYXMgbm8gaW50ZXJtZWRpYXRlIGNyZWRlbnRpYWxzIChzdWNoIGFzIGFu IGF1dGhvcml6YXRpb24gY29kZSkgYXJlCiAgICAgICAgICAgIGlzc3VlZCAoYW5kIGxhdGVyIHVz ZWQgdG8gb2J0YWluIGFuIGFjY2VzcyB0b2tlbikuCiAgICAgICAgICA8L3Q+CiAgICAgICAgICA8 dD4KICAgICAgICAgICAgV2hlbiBpc3N1aW5nIGFuIGFjY2VzcyB0b2tlbiBkdXJpbmcgdGhlIGlt cGxpY2l0IGdyYW50IGZsb3csIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlcgogICAgICAgICAgICBk b2VzIG5vdCBhdXRoZW50aWNhdGUgdGhlIGNsaWVudC4gSW4gc29tZSBjYXNlcywgdGhlIGNsaWVu dCBpZGVudGl0eSBjYW4gYmUgdmVyaWZpZWQKICAgICAgICAgICAgdmlhIHRoZSByZWRpcmVjdGlv biBVUkkgdXNlZCB0byBkZWxpdmVyIHRoZSBhY2Nlc3MgdG9rZW4gdG8gdGhlIGNsaWVudC4gVGhl IGFjY2VzcwogICAgICAgICAgICB0b2tlbiBtYXkgYmUgZXhwb3NlZCB0byB0aGUgcmVzb3VyY2Ug b3duZXIgb3Igb3RoZXIgYXBwbGljYXRpb25zIHdpdGggYWNjZXNzIHRvIHRoZQogICAgICAgICAg ICByZXNvdXJjZSBvd25lcidzIHVzZXItYWdlbnQuCiAgICAgICAgICA8L3Q+CiAgICAgICAgICA8 dD4KICAgICAgICAgICAgSW1wbGljaXQgZ3JhbnRzIGltcHJvdmUgdGhlIHJlc3BvbnNpdmVuZXNz IGFuZCBlZmZpY2llbmN5IG9mIHNvbWUgY2xpZW50cyAoc3VjaCBhcyBhCiAgICAgICAgICAgIGNs aWVudCBpbXBsZW1lbnRlZCBhcyBhbiBpbi1icm93c2VyIGFwcGxpY2F0aW9uKSBzaW5jZSBpdCBy ZWR1Y2VzIHRoZSBudW1iZXIgb2Ygcm91bmQKICAgICAgICAgICAgdHJpcHMgcmVxdWlyZWQgdG8g b2J0YWluIGFuIGFjY2VzcyB0b2tlbi4gSG93ZXZlciwgdGhpcyBjb252ZW5pZW5jZSBzaG91bGQg YmUgd2VpZ2hlZAogICAgICAgICAgICBhZ2FpbnN0IHRoZSBzZWN1cml0eSBpbXBsaWNhdGlvbnMg b2YgdXNpbmcgaW1wbGljaXQgZ3JhbnRzLCBlc3BlY2lhbGx5IHdoZW4gdGhlCiAgICAgICAgICAg IGF1dGhvcml6YXRpb24gY29kZSBncmFudCB0eXBlIGlzIGF2YWlsYWJsZS4KICAgICAgICAgIDwv dD4KICAgICAgICA8L3NlY3Rpb24+CgogICAgICAgIDxzZWN0aW9uIHRpdGxlPSJSZXNvdXJjZSBP d25lciBQYXNzd29yZCBDcmVkZW50aWFscyI+CiAgICAgICAgICA8dD4KICAgICAgICAgICAgVGhl IHJlc291cmNlIG93bmVyIHBhc3N3b3JkIGNyZWRlbnRpYWxzIChpLmUuIHVzZXJuYW1lIGFuZCBw YXNzd29yZCkgY2FuIGJlIHVzZWQKICAgICAgICAgICAgZGlyZWN0bHkgYXMgYW4gYXV0aG9yaXph dGlvbiBncmFudCB0byBvYnRhaW4gYW4gYWNjZXNzIHRva2VuLiBUaGUgY3JlZGVudGlhbHMgc2hv dWxkCiAgICAgICAgICAgIG9ubHkgYmUgdXNlZCB3aGVuIHRoZXJlIGlzIGEgaGlnaCBkZWdyZWUg b2YgdHJ1c3QgYmV0d2VlbiB0aGUgcmVzb3VyY2Ugb3duZXIgYW5kIHRoZQogICAgICAgICAgICBj bGllbnQgKGUuZy4gdGhlIGNsaWVudCBpcyBwYXJ0IG9mIHRoZSBkZXZpY2Ugb3BlcmF0aW5nIHN5 c3RlbSBvciBhIGhpZ2hseSBwcml2aWxlZ2VkCiAgICAgICAgICAgIGFwcGxpY2F0aW9uKSwgYW5k IHdoZW4gb3RoZXIgYXV0aG9yaXphdGlvbiBncmFudCB0eXBlcyBhcmUgbm90IGF2YWlsYWJsZSAo c3VjaCBhcyBhbgogICAgICAgICAgICBhdXRob3JpemF0aW9uIGNvZGUpLgogICAgICAgICAgPC90 PgogICAgICAgICAgPHQ+CiAgICAgICAgICAgIEV2ZW4gdGhvdWdoIHRoaXMgZ3JhbnQgdHlwZSBy ZXF1aXJlcyBkaXJlY3QgY2xpZW50IGFjY2VzcyB0byB0aGUgcmVzb3VyY2Ugb3duZXIKICAgICAg ICAgICAgY3JlZGVudGlhbHMsIHRoZSByZXNvdXJjZSBvd25lciBjcmVkZW50aWFscyBhcmUgdXNl ZCBmb3IgYSBzaW5nbGUgcmVxdWVzdCBhbmQgYXJlCiAgICAgICAgICAgIGV4Y2hhbmdlZCBmb3Ig YW4gYWNjZXNzIHRva2VuLiBUaGlzIGdyYW50IHR5cGUgY2FuIGVsaW1pbmF0ZSB0aGUgbmVlZCBm b3IgdGhlIGNsaWVudAogICAgICAgICAgICB0byBzdG9yZSB0aGUgcmVzb3VyY2Ugb3duZXIgY3Jl ZGVudGlhbHMgZm9yIGZ1dHVyZSB1c2UsIGJ5IGV4Y2hhbmdpbmcgdGhlIGNyZWRlbnRpYWxzCiAg ICAgICAgICAgIHdpdGggYSBsb25nLWxpdmVkIGFjY2VzcyB0b2tlbiBvciByZWZyZXNoIHRva2Vu LgogICAgICAgICAgPC90PgogICAgICAgIDwvc2VjdGlvbj4KCiAgICAgICAgPHNlY3Rpb24gdGl0 bGU9J0NsaWVudCBDcmVkZW50aWFscyc+CiAgICAgICAgICA8dD4KICAgICAgICAgICAgVGhlIGNs aWVudCBjcmVkZW50aWFscyAob3Igb3RoZXIgZm9ybXMgb2YgY2xpZW50IGF1dGhlbnRpY2F0aW9u KSBjYW4gYmUgdXNlZCBhcyBhbgogICAgICAgICAgICBhdXRob3JpemF0aW9uIGdyYW50IHdoZW4g dGhlIGF1dGhvcml6YXRpb24gc2NvcGUgaXMgbGltaXRlZCB0byB0aGUgcHJvdGVjdGVkIHJlc291 cmNlcwogICAgICAgICAgICB1bmRlciB0aGUgY29udHJvbCBvZiB0aGUgY2xpZW50LCBvciB0byBw cm90ZWN0ZWQgcmVzb3VyY2VzIHByZXZpb3VzbHkgYXJyYW5nZWQgd2l0aCB0aGUKICAgICAgICAg ICAgYXV0aG9yaXphdGlvbiBzZXJ2ZXIuIENsaWVudCBjcmVkZW50aWFscyBhcmUgdXNlZCBhcyBh biBhdXRob3JpemF0aW9uIGdyYW50IHR5cGljYWxseQogICAgICAgICAgICB3aGVuIHRoZSBjbGll bnQgaXMgYWN0aW5nIG9uIGl0cyBvd24gYmVoYWxmICh0aGUgY2xpZW50IGlzIGFsc28gdGhlIHJl c291cmNlIG93bmVyKSwgb3IKICAgICAgICAgICAgaXMgcmVxdWVzdGluZyBhY2Nlc3MgdG8gcHJv dGVjdGVkIHJlc291cmNlcyBiYXNlZCBvbiBhbiBhdXRob3JpemF0aW9uIHByZXZpb3VzbHkKICAg ICAgICAgICAgYXJyYW5nZWQgd2l0aCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIuCiAgICAgICAg ICA8L3Q+CiAgICAgICAgPC9zZWN0aW9uPgoKICAgICAgPC9zZWN0aW9uPgoKICAgICAgPHNlY3Rp b24gdGl0bGU9J0FjY2VzcyBUb2tlbic+CiAgICAgICAgPHQ+CiAgICAgICAgICBBY2Nlc3MgdG9r ZW5zIGFyZSBjcmVkZW50aWFscyB1c2VkIHRvIGFjY2VzcyBwcm90ZWN0ZWQgcmVzb3VyY2VzLiBB biBhY2Nlc3MgdG9rZW4gaXMgYQogICAgICAgICAgc3RyaW5nIHJlcHJlc2VudGluZyBhbiBhdXRo b3JpemF0aW9uIGlzc3VlZCB0byB0aGUgY2xpZW50LiBUaGUgc3RyaW5nIGlzIHVzdWFsbHkgb3Bh cXVlCiAgICAgICAgICB0byB0aGUgY2xpZW50LiBUb2tlbnMgcmVwcmVzZW50IHNwZWNpZmljIHNj b3BlcyBhbmQgZHVyYXRpb25zIG9mIGFjY2VzcywgZ3JhbnRlZCBieSB0aGUKICAgICAgICAgIHJl c291cmNlIG93bmVyLCBhbmQgZW5mb3JjZWQgYnkgdGhlIHJlc291cmNlIHNlcnZlciBhbmQgYXV0 aG9yaXphdGlvbiBzZXJ2ZXIuCiAgICAgICAgPC90PgogICAgICAgIDx0PgogICAgICAgICAgVGhl IHRva2VuIG1heSBkZW5vdGUgYW4gaWRlbnRpZmllciB1c2VkIHRvIHJldHJpZXZlIHRoZSBhdXRo b3JpemF0aW9uIGluZm9ybWF0aW9uLCBvcgogICAgICAgICAgc2VsZi1jb250YWluIHRoZSBhdXRo b3JpemF0aW9uIGluZm9ybWF0aW9uIGluIGEgdmVyaWZpYWJsZSBtYW5uZXIgKGkuZS4gYSB0b2tl biBzdHJpbmcKICAgICAgICAgIGNvbnNpc3Rpbmcgb2Ygc29tZSBkYXRhIGFuZCBhIHNpZ25hdHVy ZSkuIEFkZGl0aW9uYWwgYXV0aGVudGljYXRpb24gY3JlZGVudGlhbHMsIHdoaWNoCiAgICAgICAg ICBhcmUgYmV5b25kIHRoZSBzY29wZSBvZiB0aGlzIHNwZWNpZmljYXRpb24sIG1heSBiZSByZXF1 aXJlZCBpbiBvcmRlciBmb3IgdGhlIGNsaWVudCB0bwogICAgICAgICAgdXNlIGEgdG9rZW4uCiAg ICAgICAgPC90PgogICAgICAgIDx0PgogICAgICAgICAgVGhlIGFjY2VzcyB0b2tlbiBwcm92aWRl cyBhbiBhYnN0cmFjdGlvbiBsYXllciwgcmVwbGFjaW5nIGRpZmZlcmVudCBhdXRob3JpemF0aW9u CiAgICAgICAgICBjb25zdHJ1Y3RzIChlLmcuIHVzZXJuYW1lIGFuZCBwYXNzd29yZCkgd2l0aCBh IHNpbmdsZSB0b2tlbiB1bmRlcnN0b29kIGJ5IHRoZSByZXNvdXJjZQogICAgICAgICAgc2VydmVy LiBUaGlzIGFic3RyYWN0aW9uIGVuYWJsZXMgaXNzdWluZyBhY2Nlc3MgdG9rZW5zIG1vcmUgcmVz dHJpY3RpdmUgdGhhbiB0aGUKICAgICAgICAgIGF1dGhvcml6YXRpb24gZ3JhbnQgdXNlZCB0byBv YnRhaW4gdGhlbSwgYXMgd2VsbCBhcyByZW1vdmluZyB0aGUgcmVzb3VyY2Ugc2VydmVyJ3MgbmVl ZCB0bwogICAgICAgICAgdW5kZXJzdGFuZCBhIHdpZGUgcmFuZ2Ugb2YgYXV0aGVudGljYXRpb24g bWV0aG9kcy4KICAgICAgICA8L3Q+CiAgICAgICAgPHQ+CiAgICAgICAgICBBY2Nlc3MgdG9rZW5z IGNhbiBoYXZlIGRpZmZlcmVudCBmb3JtYXRzLCBzdHJ1Y3R1cmVzLCBhbmQgbWV0aG9kcyBvZiB1 dGlsaXphdGlvbiAoZS5nLgogICAgICAgICAgY3J5cHRvZ3JhcGhpYyBwcm9wZXJ0aWVzKSBiYXNl ZCBvbiB0aGUgcmVzb3VyY2Ugc2VydmVyIHNlY3VyaXR5IHJlcXVpcmVtZW50cy4gQWNjZXNzIHRv a2VuCiAgICAgICAgICBhdHRyaWJ1dGVzIGFuZCB0aGUgbWV0aG9kcyB1c2VkIHRvIGFjY2VzcyBw cm90ZWN0ZWQgcmVzb3VyY2VzIGFyZSBiZXlvbmQgdGhlIHNjb3BlIG9mIHRoaXMKICAgICAgICAg IHNwZWNpZmljYXRpb24gYW5kIGFyZSBkZWZpbmVkIGJ5IGNvbXBhbmlvbiBzcGVjaWZpY2F0aW9u cy4KICAgICAgICA8L3Q+CiAgICAgIDwvc2VjdGlvbj4KCiAgICAgIDxzZWN0aW9uIHRpdGxlPSdS ZWZyZXNoIFRva2VuJz4KICAgICAgICA8dD4KICAgICAgICAgIFJlZnJlc2ggdG9rZW5zIGFyZSBj cmVkZW50aWFscyB1c2VkIHRvIG9idGFpbiBhY2Nlc3MgdG9rZW5zLiBSZWZyZXNoIHRva2VucyBh cmUgaXNzdWVkIHRvCiAgICAgICAgICB0aGUgY2xpZW50IGJ5IHRoZSBhdXRob3JpemF0aW9uIHNl cnZlciBhbmQgYXJlIHVzZWQgdG8gb2J0YWluIGEgbmV3IGFjY2VzcyB0b2tlbiB3aGVuIHRoZQog ICAgICAgICAgY3VycmVudCBhY2Nlc3MgdG9rZW4gYmVjb21lcyBpbnZhbGlkIG9yIGV4cGlyZXMs IG9yIHRvIG9idGFpbiBhZGRpdGlvbmFsIGFjY2VzcyB0b2tlbnMKICAgICAgICAgIHdpdGggaWRl bnRpY2FsIG9yIG5hcnJvd2VyIHNjb3BlIChhY2Nlc3MgdG9rZW5zIG1heSBoYXZlIGEgc2hvcnRl ciBsaWZldGltZSBhbmQgZmV3ZXIKICAgICAgICAgIHBlcm1pc3Npb25zIHRoYW4gYXV0aG9yaXpl ZCBieSB0aGUgcmVzb3VyY2Ugb3duZXIpLiBJc3N1aW5nIGEgcmVmcmVzaCB0b2tlbiBpcyBvcHRp b25hbAogICAgICAgICAgYXQgdGhlIGRpc2NyZXRpb24gb2YgdGhlIGF1dGhvcml6YXRpb24gc2Vy dmVyLiBJZiB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgaXNzdWVzIGEKICAgICAgICAgIHJlZnJl c2ggdG9rZW4sIGl0IGlzIGluY2x1ZGVkIHdoZW4gaXNzdWluZyBhbiBhY2Nlc3MgdG9rZW4gKGku ZS4gc3RlcCAoRCkgaW4KICAgICAgICAgIDx4cmVmIHRhcmdldD0nRmlndXJlLTEnIC8+KS4KICAg ICAgICA8L3Q+CiAgICAgICAgPHQ+CiAgICAgICAgICBBIHJlZnJlc2ggdG9rZW4gaXMgYSBzdHJp bmcgcmVwcmVzZW50aW5nIHRoZSBhdXRob3JpemF0aW9uIGdyYW50ZWQgdG8gdGhlIGNsaWVudCBi eSB0aGUKICAgICAgICAgIHJlc291cmNlIG93bmVyLiBUaGUgc3RyaW5nIGlzIHVzdWFsbHkgb3Bh cXVlIHRvIHRoZSBjbGllbnQuIFRoZSB0b2tlbiBkZW5vdGVzIGFuCiAgICAgICAgICBpZGVudGlm aWVyIHVzZWQgdG8gcmV0cmlldmUgdGhlIGF1dGhvcml6YXRpb24gaW5mb3JtYXRpb24uIFVubGlr ZSBhY2Nlc3MgdG9rZW5zLCByZWZyZXNoCiAgICAgICAgICB0b2tlbnMgYXJlIGludGVuZGVkIGZv ciB1c2Ugb25seSB3aXRoIGF1dGhvcml6YXRpb24gc2VydmVycyBhbmQgYXJlIG5ldmVyIHNlbnQg dG8KICAgICAgICAgIHJlc291cmNlIHNlcnZlcnMuCiAgICAgICAgPC90PgogICAgICAgIDxmaWd1 cmUgdGl0bGU9J1JlZnJlc2hpbmcgYW4gRXhwaXJlZCBBY2Nlc3MgVG9rZW4nIGFuY2hvcj0nRmln dXJlLTInPgogICAgICAgICAgPGFydHdvcms+CiAgICAgICAgICAgIDwhW0NEQVRBWwogICstLS0t LS0tLSsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0t LS0tLS0tLSsKICB8ICAgICAgICB8LS0oQSktLS0tLS0tIEF1dGhvcml6YXRpb24gR3JhbnQgLS0t LS0tLS0tPnwgICAgICAgICAgICAgICB8CiAgfCAgICAgICAgfCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgfAogIHwgICAgICAgIHw8LShC KS0tLS0tLS0tLS0tIEFjY2VzcyBUb2tlbiAtLS0tLS0tLS0tLS0tfCAgICAgICAgICAgICAgIHwK ICB8ICAgICAgICB8ICAgICAgICAgICAgICAgJiBSZWZyZXNoIFRva2VuICAgICAgICAgICAgIHwg ICAgICAgICAgICAgICB8CiAgfCAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgfAogIHwgICAgICAgIHwgICAgICAgICAgICAg ICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0rICAgfCAgICAgICAgICAgICAgIHwKICB8ICAgICAg ICB8LS0oQyktLS0tIEFjY2VzcyBUb2tlbiAtLS0tPnwgICAgICAgICAgfCAgIHwgICAgICAgICAg ICAgICB8CiAgfCAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAg IHwgICB8ICAgICAgICAgICAgICAgfAogIHwgICAgICAgIHw8LShEKS0gUHJvdGVjdGVkIFJlc291 cmNlIC0tfCBSZXNvdXJjZSB8ICAgfCBBdXRob3JpemF0aW9uIHwKICB8IENsaWVudCB8ICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHwgIFNlcnZlciAgfCAgIHwgICAgIFNlcnZlciAgICB8CiAg fCAgICAgICAgfC0tKEUpLS0tLSBBY2Nlc3MgVG9rZW4gLS0tLT58ICAgICAgICAgIHwgICB8ICAg ICAgICAgICAgICAgfAogIHwgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAg ICAgICAgICB8ICAgfCAgICAgICAgICAgICAgIHwKICB8ICAgICAgICB8PC0oRiktIEludmFsaWQg VG9rZW4gRXJyb3IgLXwgICAgICAgICAgfCAgIHwgICAgICAgICAgICAgICB8CiAgfCAgICAgICAg fCAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLSsgICB8ICAgICAgICAgICAg ICAgfAogIHwgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgfCAgICAgICAgICAgICAgIHwKICB8ICAgICAgICB8LS0oRyktLS0tLS0tLS0tLSBSZWZyZXNo IFRva2VuIC0tLS0tLS0tLS0tPnwgICAgICAgICAgICAgICB8CiAgfCAgICAgICAgfCAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgfAogIHwg ICAgICAgIHw8LShIKS0tLS0tLS0tLS0tIEFjY2VzcyBUb2tlbiAtLS0tLS0tLS0tLS0tfCAgICAg ICAgICAgICAgIHwKICArLS0tLS0tLS0rICAgICAgICAgICAmIE9wdGlvbmFsIFJlZnJlc2ggVG9r ZW4gICAgICAgICstLS0tLS0tLS0tLS0tLS0rCl1dPgogICAgICAgICAgPC9hcnR3b3JrPgogICAg ICAgIDwvZmlndXJlPgogICAgICAgIDx0PgogICAgICAgICAgVGhlIGZsb3cgaWxsdXN0cmF0ZWQg aW4gPHhyZWYgdGFyZ2V0PSdGaWd1cmUtMicgLz4gaW5jbHVkZXMgdGhlIGZvbGxvd2luZyBzdGVw czoKICAgICAgICA8L3Q+CiAgICAgICAgPHQ+CiAgICAgICAgICA8bGlzdCBzdHlsZT0nZm9ybWF0 ICglQyknPgogICAgICAgICAgICA8dD4KICAgICAgICAgICAgICBUaGUgY2xpZW50IHJlcXVlc3Rz IGFuIGFjY2VzcyB0b2tlbiBieSBhdXRoZW50aWNhdGluZyB3aXRoIHRoZSBhdXRob3JpemF0aW9u IHNlcnZlciwKICAgICAgICAgICAgICBhbmQgcHJlc2VudGluZyBhbiBhdXRob3JpemF0aW9uIGdy YW50LgogICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgIDx0PgogICAgICAgICAgICAgIFRoZSBh dXRob3JpemF0aW9uIHNlcnZlciBhdXRoZW50aWNhdGVzIHRoZSBjbGllbnQgYW5kIHZhbGlkYXRl cyB0aGUgYXV0aG9yaXphdGlvbgogICAgICAgICAgICAgIGdyYW50LCBhbmQgaWYgdmFsaWQgaXNz dWVzIGFuIGFjY2VzcyB0b2tlbiBhbmQgYSByZWZyZXNoIHRva2VuLgogICAgICAgICAgICA8L3Q+ CiAgICAgICAgICAgIDx0PgogICAgICAgICAgICAgIFRoZSBjbGllbnQgbWFrZXMgYSBwcm90ZWN0 ZWQgcmVzb3VyY2UgcmVxdWVzdCB0byB0aGUgcmVzb3VyY2Ugc2VydmVyIGJ5IHByZXNlbnRpbmcK ICAgICAgICAgICAgICB0aGUgYWNjZXNzIHRva2VuLgogICAgICAgICAgICA8L3Q+CiAgICAgICAg ICAgIDx0PgogICAgICAgICAgICAgIFRoZSByZXNvdXJjZSBzZXJ2ZXIgdmFsaWRhdGVzIHRoZSBh Y2Nlc3MgdG9rZW4sIGFuZCBpZiB2YWxpZCwgc2VydmVzIHRoZSByZXF1ZXN0LgogICAgICAgICAg ICA8L3Q+CiAgICAgICAgICAgIDx0PgogICAgICAgICAgICAgIFN0ZXBzIChDKSBhbmQgKEQpIHJl cGVhdCB1bnRpbCB0aGUgYWNjZXNzIHRva2VuIGV4cGlyZXMuIElmIHRoZSBjbGllbnQga25vd3Mg dGhlCiAgICAgICAgICAgICAgYWNjZXNzIHRva2VuIGV4cGlyZWQsIGl0IHNraXBzIHRvIHN0ZXAg KEcpLCBvdGhlcndpc2UgaXQgbWFrZXMgYW5vdGhlciBwcm90ZWN0ZWQKICAgICAgICAgICAgICBy ZXNvdXJjZSByZXF1ZXN0LgogICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgIDx0PgogICAgICAg ICAgICAgIFNpbmNlIHRoZSBhY2Nlc3MgdG9rZW4gaXMgaW52YWxpZCwgdGhlIHJlc291cmNlIHNl cnZlciByZXR1cm5zIGFuIGludmFsaWQgdG9rZW4KICAgICAgICAgICAgICBlcnJvci4KICAgICAg ICAgICAgPC90PgogICAgICAgICAgICA8dD4KICAgICAgICAgICAgICBUaGUgY2xpZW50IHJlcXVl c3RzIGEgbmV3IGFjY2VzcyB0b2tlbiBieSBhdXRoZW50aWNhdGluZyB3aXRoIHRoZSBhdXRob3Jp emF0aW9uCiAgICAgICAgICAgICAgc2VydmVyIGFuZCBwcmVzZW50aW5nIHRoZSByZWZyZXNoIHRv a2VuLiBUaGUgY2xpZW50IGF1dGhlbnRpY2F0aW9uIHJlcXVpcmVtZW50cyBhcmUKICAgICAgICAg ICAgICBiYXNlZCBvbiB0aGUgY2xpZW50IHR5cGUgYW5kIG9uIHRoZSBhdXRob3JpemF0aW9uIHNl cnZlciBwb2xpY2llcy4KICAgICAgICAgICAgPC90PgogICAgICAgICAgICA8dD4KICAgICAgICAg ICAgICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYXV0aGVudGljYXRlcyB0aGUgY2xpZW50IGFu ZCB2YWxpZGF0ZXMgdGhlIHJlZnJlc2ggdG9rZW4sCiAgICAgICAgICAgICAgYW5kIGlmIHZhbGlk IGlzc3VlcyBhIG5ldyBhY2Nlc3MgdG9rZW4gKGFuZCBvcHRpb25hbGx5LCBhIG5ldyByZWZyZXNo IHRva2VuKS4KICAgICAgICAgICAgPC90PgogICAgICAgICAgPC9saXN0PgogICAgICAgIDwvdD4K ICAgICAgICA8dD4KICAgICAgICAgIFN0ZXBzIEMsIEQsIEUsIGFuZCBGIGFyZSBvdXRzaWRlIHRo ZSBzY29wZSBvZiB0aGlzIHNwZWNpZmljYXRpb24gYXMgZGVzY3JpYmVkIGluCiAgICAgICAgICA8 eHJlZiB0YXJnZXQ9J2FjY2Vzcy1yZXNvdXJjZScgLz4uCiAgICAgICAgPC90PgogICAgICA8L3Nl Y3Rpb24+CgogICAgICA8c2VjdGlvbiB0aXRsZT0nVExTIFZlcnNpb24nIGFuY2hvcj0ndGxzJz4K ICAgICAgICA8dD4KICAgICAgICAgIFdoZW5ldmVyIFRMUyBpcyB1c2VkIGJ5IHRoaXMgc3BlY2lm aWNhdGlvbiwgdGhlIGFwcHJvcHJpYXRlIHZlcnNpb24gKG9yIHZlcnNpb25zKSBvZgogICAgICAg ICAgVExTIHdpbGwgdmFyeSBvdmVyIHRpbWUsIGJhc2VkIG9uIHRoZSB3aWRlc3ByZWFkIGRlcGxv eW1lbnQgYW5kIGtub3duIHNlY3VyaXR5CiAgICAgICAgICB2dWxuZXJhYmlsaXRpZXMuIEF0IHRo ZSB0aW1lIG9mIHRoaXMgd3JpdGluZywgVExTIHZlcnNpb24gMS4yIDx4cmVmIHRhcmdldD0nUkZD NTI0NicgLz4KICAgICAgICAgIGlzIHRoZSBtb3N0IHJlY2VudCB2ZXJzaW9uLCBidXQgaGFzIGEg dmVyeSBsaW1pdGVkIGRlcGxveW1lbnQgYmFzZSBhbmQgbWlnaHQgbm90IGJlCiAgICAgICAgICBy ZWFkaWx5IGF2YWlsYWJsZSBmb3IgaW1wbGVtZW50YXRpb24uIFRMUyB2ZXJzaW9uIDEuMCA8eHJl ZiB0YXJnZXQ9J1JGQzIyNDYnIC8+IGlzIHRoZQogICAgICAgICAgbW9zdCB3aWRlbHkgZGVwbG95 ZWQgdmVyc2lvbiwgYW5kIHdpbGwgcHJvdmlkZSB0aGUgYnJvYWRlc3QgaW50ZXJvcGVyYWJpbGl0 eS4KICAgICAgICA8L3Q+CiAgICAgICAgPHQ+CiAgICAgICAgICBJbXBsZW1lbnRhdGlvbnMgTUFZ IGFsc28gc3VwcG9ydCBhZGRpdGlvbmFsIHRyYW5zcG9ydC1sYXllciBzZWN1cml0eSBtZWNoYW5p c21zCiAgICAgICAgICB0aGF0IG1lZXQgdGhlaXIgc2VjdXJpdHkgcmVxdWlyZW1lbnRzLgogICAg ICAgIDwvdD4KICAgICAgPC9zZWN0aW9uPgoKICAgICAgPHNlY3Rpb24gdGl0bGU9J0hUVFAgUmVk aXJlY3Rpb25zJz4KICAgICAgICA8dD4KICAgICAgICAgIFRoaXMgc3BlY2lmaWNhdGlvbiBtYWtl cyBleHRlbnNpdmUgdXNlIG9mIEhUVFAgcmVkaXJlY3Rpb25zLCBpbiB3aGljaCB0aGUgY2xpZW50 IG9yIHRoZQogICAgICAgICAgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgZGlyZWN0IHRoZSByZXNvdXJj ZSBvd25lcidzIHVzZXItYWdlbnQgdG8gYW5vdGhlciBkZXN0aW5hdGlvbi4gV2hpbGUKICAgICAg ICAgIHRoZSBleGFtcGxlcyBpbiB0aGlzIHNwZWNpZmljYXRpb24gc2hvdyB0aGUgdXNlIG9mIHRo ZSBIVFRQIDMwMiBzdGF0dXMgY29kZSwgYW55IG90aGVyCiAgICAgICAgICBtZXRob2QgYXZhaWxh YmxlIHZpYSB0aGUgdXNlci1hZ2VudCB0byBhY2NvbXBsaXNoIHRoaXMgcmVkaXJlY3Rpb24gaXMg YWxsb3dlZCBhbmQgaXMKICAgICAgICAgIGNvbnNpZGVyZWQgdG8gYmUgYW4gaW1wbGVtZW50YXRp b24gZGV0YWlsLgogICAgICAgIDwvdD4KICAgICAgPC9zZWN0aW9uPgoKICAgICAgPHNlY3Rpb24g dGl0bGU9J0ludGVyb3BlcmFiaWxpdHknPgogICAgICAgIDx0PgogICAgICAgICAgT0F1dGggMi4w IHByb3ZpZGVzIGEgcmljaCBhdXRob3JpemF0aW9uIGZyYW1ld29yayB3aXRoIHdlbGwtZGVmaW5l ZCBzZWN1cml0eSBwcm9wZXJ0aWVzLgogICAgICAgICAgSG93ZXZlciwgYXMgYSByaWNoIGFuZCBo aWdobHkgZXh0ZW5zaWJsZSBmcmFtZXdvcmsgd2l0aCBtYW55IG9wdGlvbmFsIGNvbXBvbmVudHMs IG9uIGl0cwogICAgICAgICAgb3duLCB0aGlzIHNwZWNpZmljYXRpb24gaXMgbGlrZWx5IHRvIHBy b2R1Y2UgYSB3aWRlIHJhbmdlIG9mIG5vbi1pbnRlcm9wZXJhYmxlCiAgICAgICAgICBpbXBsZW1l bnRhdGlvbnMuCiAgICAgICAgPC90PgogICAgICAgIDx0PgogICAgICAgICAgSW4gYWRkaXRpb24s IHRoaXMgc3BlY2lmaWNhdGlvbiBsZWF2ZXMgYSBmZXcgcmVxdWlyZWQgY29tcG9uZW50cyBwYXJ0 aWFsbHkgb3IgZnVsbHkKICAgICAgICAgIHVuZGVmaW5lZCAoZS5nLiBjbGllbnQgcmVnaXN0cmF0 aW9uLCBhdXRob3JpemF0aW9uIHNlcnZlciBjYXBhYmlsaXRpZXMsIGVuZHBvaW50CiAgICAgICAg ICBkaXNjb3ZlcnkpLiBXaXRob3V0IHRoZXNlIGNvbXBvbmVudHMsIGNsaWVudHMgbXVzdCBiZSBt YW51YWxseSBhbmQgc3BlY2lmaWNhbGx5CiAgICAgICAgICBjb25maWd1cmVkIGFnYWluc3QgYSBz cGVjaWZpYyBhdXRob3JpemF0aW9uIHNlcnZlciBhbmQgcmVzb3VyY2Ugc2VydmVyIGluIG9yZGVy IHRvCiAgICAgICAgICBpbnRlcm9wZXJhdGUuCiAgICAgICAgPC90PgogICAgICAgIDx0PgogICAg ICAgICAgVGhpcyBmcmFtZXdvcmsgd2FzIGRlc2lnbmVkIHdpdGggdGhlIGNsZWFyIGV4cGVjdGF0 aW9uIHRoYXQgZnV0dXJlIHdvcmsgd2lsbCBkZWZpbmUKICAgICAgICAgIHByZXNjcmlwdGl2ZSBw cm9maWxlcyBhbmQgZXh0ZW5zaW9ucyBuZWNlc3NhcnkgdG8gYWNoaWV2ZSBmdWxsIHdlYi1zY2Fs ZQogICAgICAgICAgaW50ZXJvcGVyYWJpbGl0eS4KICAgICAgICA8L3Q+CiAgICAgIDwvc2VjdGlv bj4KCiAgICAgIDxzZWN0aW9uIHRpdGxlPSdOb3RhdGlvbmFsIENvbnZlbnRpb25zJz4KICAgICAg ICA8dD4KICAgICAgICAgIFRoZSBrZXkgd29yZHMgIk1VU1QiLCAiTVVTVCBOT1QiLCAiUkVRVUlS RUQiLCAiU0hBTEwiLCAiU0hBTEwgTk9UIiwgIlNIT1VMRCIsICJTSE9VTEQKICAgICAgICAgIE5P VCIsICJSRUNPTU1FTkRFRCIsICJNQVkiLCBhbmQgIk9QVElPTkFMIiBpbiB0aGlzIHNwZWNpZmlj YXRpb24gYXJlIHRvIGJlIGludGVycHJldGVkIGFzCiAgICAgICAgICBkZXNjcmliZWQgaW4gPHhy ZWYgdGFyZ2V0PSdSRkMyMTE5JyAvPi4KICAgICAgICA8L3Q+CiAgICAgICAgPHQ+CiAgICAgICAg ICBUaGlzIHNwZWNpZmljYXRpb24gdXNlcyB0aGUgQXVnbWVudGVkIEJhY2t1cy1OYXVyIEZvcm0g KEFCTkYpIG5vdGF0aW9uIG9mCiAgICAgICAgICA8eHJlZiB0YXJnZXQ9J1JGQzUyMzQnIC8+LgoJ ICBBZGRpdGlvbmFsbHksIHRoZSBydWxlIFVSSS1SZWZlcmVuY2UgaXMgaW5jbHVkZWQgZnJvbQoJ ICBVbmlmb3JtIFJlc291cmNlIElkZW50aWZpZXIgKFVSSSkgPHhyZWYgdGFyZ2V0PSdSRkMzOTg2 JyAvPi4KICAgICAgICA8L3Q+CiAgICAgICAgPHQ+CiAgICAgICAgICBDZXJ0YWluIHNlY3VyaXR5 LXJlbGF0ZWQgdGVybXMgYXJlIHRvIGJlIHVuZGVyc3Rvb2QgaW4gdGhlIHNlbnNlIGRlZmluZWQg aW4KICAgICAgICAgIDx4cmVmIHRhcmdldD0nUkZDNDk0OScgLz4uIFRoZXNlIHRlcm1zIGluY2x1 ZGUsIGJ1dCBhcmUgbm90IGxpbWl0ZWQgdG8sICJhdHRhY2siLAogICAgICAgICAgImF1dGhlbnRp Y2F0aW9uIiwgImF1dGhvcml6YXRpb24iLCAiY2VydGlmaWNhdGUiLCAiY29uZmlkZW50aWFsaXR5 IiwgImNyZWRlbnRpYWwiLAogICAgICAgICAgImVuY3J5cHRpb24iLCAiaWRlbnRpdHkiLCAic2ln biIsICJzaWduYXR1cmUiLCAidHJ1c3QiLCAidmFsaWRhdGUiLCBhbmQgInZlcmlmeSIuCiAgICAg ICAgPC90PgogICAgICAgIDx0PgogICAgICAgICAgVW5sZXNzIG90aGVyd2lzZSBub3RlZCwgYWxs IHRoZSBwcm90b2NvbCBwYXJhbWV0ZXIgbmFtZXMgYW5kIHZhbHVlcyBhcmUgY2FzZSBzZW5zaXRp dmUuCiAgICAgICAgPC90PgogICAgICA8L3NlY3Rpb24+CgogICAgPC9zZWN0aW9uPgoKICAgIDxz ZWN0aW9uIHRpdGxlPSdDbGllbnQgUmVnaXN0cmF0aW9uJz4KICAgICAgPHQ+CiAgICAgICAgQmVm b3JlIGluaXRpYXRpbmcgdGhlIHByb3RvY29sLCB0aGUgY2xpZW50IHJlZ2lzdGVycyB3aXRoIHRo ZSBhdXRob3JpemF0aW9uIHNlcnZlci4gVGhlCiAgICAgICAgbWVhbnMgdGhyb3VnaCB3aGljaCB0 aGUgY2xpZW50IHJlZ2lzdGVycyB3aXRoIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBhcmUgYmV5 b25kIHRoZQogICAgICAgIHNjb3BlIG9mIHRoaXMgc3BlY2lmaWNhdGlvbiwgYnV0IHR5cGljYWxs eSBpbnZvbHZlIGVuZC11c2VyIGludGVyYWN0aW9uIHdpdGggYW4gSFRNTAogICAgICAgIHJlZ2lz dHJhdGlvbiBmb3JtLgogICAgICA8L3Q+CiAgICAgIDx0PgogICAgICAgIENsaWVudCByZWdpc3Ry YXRpb24gZG9lcyBub3QgcmVxdWlyZSBhIGRpcmVjdCBpbnRlcmFjdGlvbiBiZXR3ZWVuIHRoZSBj bGllbnQgYW5kIHRoZQogICAgICAgIGF1dGhvcml6YXRpb24gc2VydmVyLiBXaGVuIHN1cHBvcnRl ZCBieSB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIsIHJlZ2lzdHJhdGlvbiBjYW4gcmVseQogICAg ICAgIG9uIG90aGVyIG1lYW5zIGZvciBlc3RhYmxpc2hpbmcgdHJ1c3QgYW5kIG9idGFpbmluZyB0 aGUgcmVxdWlyZWQgY2xpZW50IHByb3BlcnRpZXMgKGUuZy4KICAgICAgICByZWRpcmVjdGlvbiBV UkksIGNsaWVudCB0eXBlKS4gRm9yIGV4YW1wbGUsIHJlZ2lzdHJhdGlvbiBjYW4gYmUgYWNjb21w bGlzaGVkIHVzaW5nIGEKICAgICAgICBzZWxmLWlzc3VlZCBvciB0aGlyZC1wYXJ0eS1pc3N1ZWQg YXNzZXJ0aW9uLCBvciBieSB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgcGVyZm9ybWluZwogICAg ICAgIGNsaWVudCBkaXNjb3ZlcnkgdXNpbmcgYSB0cnVzdGVkIGNoYW5uZWwuCiAgICAgIDwvdD4K ICAgICAgPHQ+CiAgICAgICAgV2hlbiByZWdpc3RlcmluZyBhIGNsaWVudCwgdGhlIGNsaWVudCBk ZXZlbG9wZXIgU0hBTEw6CiAgICAgIDwvdD4KICAgICAgPHQ+CiAgICAgICAgPGxpc3Qgc3R5bGU9 J3N5bWJvbHMnPgogICAgICAgICAgPHQ+CiAgICAgICAgICAgIHNwZWNpZnkgdGhlIGNsaWVudCB0 eXBlIGFzIGRlc2NyaWJlZCBpbiA8eHJlZiB0YXJnZXQ9J2NsaWVudC10eXBlcycgLz4sCiAgICAg ICAgICA8L3Q+CiAgICAgICAgICA8dD4KICAgICAgICAgICAgcHJvdmlkZSBpdHMgY2xpZW50IHJl ZGlyZWN0aW9uIFVSSXMgYXMgZGVzY3JpYmVkIGluCiAgICAgICAgICAgIDx4cmVmIHRhcmdldD0n cmVkaXJlY3QtdXJpJyAvPiwgYW5kCiAgICAgICAgICA8L3Q+CiAgICAgICAgICA8dD4KICAgICAg ICAgICAgaW5jbHVkZSBhbnkgb3RoZXIgaW5mb3JtYXRpb24gcmVxdWlyZWQgYnkgdGhlIGF1dGhv cml6YXRpb24gc2VydmVyIChlLmcuIGFwcGxpY2F0aW9uCiAgICAgICAgICAgIG5hbWUsIHdlYnNp dGUsIGRlc2NyaXB0aW9uLCBsb2dvIGltYWdlLCB0aGUgYWNjZXB0YW5jZSBvZiBsZWdhbCB0ZXJt cykuCiAgICAgICAgICA8L3Q+CiAgICAgICAgPC9saXN0PgogICAgICA8L3Q+CgogICAgICA8c2Vj dGlvbiB0aXRsZT0nQ2xpZW50IFR5cGVzJyBhbmNob3I9J2NsaWVudC10eXBlcyc+CiAgICAgICAg PHQ+CiAgICAgICAgICBPQXV0aCBkZWZpbmVzIHR3byBjbGllbnQgdHlwZXMsIGJhc2VkIG9uIHRo ZWlyIGFiaWxpdHkgdG8gYXV0aGVudGljYXRlIHNlY3VyZWx5IHdpdGggdGhlCiAgICAgICAgICBh dXRob3JpemF0aW9uIHNlcnZlciAoaS5lLiBhYmlsaXR5IHRvIG1haW50YWluIHRoZSBjb25maWRl bnRpYWxpdHkgb2YgdGhlaXIgY2xpZW50CiAgICAgICAgICBjcmVkZW50aWFscyk6CiAgICAgICAg PC90PgogICAgICAgIDx0PgogICAgICAgICAgPGxpc3Qgc3R5bGU9J2hhbmdpbmcnPgogICAgICAg ICAgICA8dCBoYW5nVGV4dD0nY29uZmlkZW50aWFsJz4KICAgICAgICAgICAgICA8dnNwYWNlIC8+ CiAgICAgICAgICAgICAgQ2xpZW50cyBjYXBhYmxlIG9mIG1haW50YWluaW5nIHRoZSBjb25maWRl bnRpYWxpdHkgb2YgdGhlaXIgY3JlZGVudGlhbHMgKGUuZy4KICAgICAgICAgICAgICBjbGllbnQg aW1wbGVtZW50ZWQgb24gYSBzZWN1cmUgc2VydmVyIHdpdGggcmVzdHJpY3RlZCBhY2Nlc3MgdG8g dGhlIGNsaWVudAogICAgICAgICAgICAgIGNyZWRlbnRpYWxzKSwgb3IgY2FwYWJsZSBvZiBzZWN1 cmUgY2xpZW50IGF1dGhlbnRpY2F0aW9uIHVzaW5nIG90aGVyIG1lYW5zLgogICAgICAgICAgICA8 L3Q+CiAgICAgICAgICAgIDx0IGhhbmdUZXh0PSdwdWJsaWMnPgogICAgICAgICAgICAgIDx2c3Bh Y2UgLz4KICAgICAgICAgICAgICBDbGllbnRzIGluY2FwYWJsZSBvZiBtYWludGFpbmluZyB0aGUg Y29uZmlkZW50aWFsaXR5IG9mIHRoZWlyIGNyZWRlbnRpYWxzIChlLmcuCiAgICAgICAgICAgICAg Y2xpZW50cyBleGVjdXRpbmcgb24gdGhlIGRldmljZSB1c2VkIGJ5IHRoZSByZXNvdXJjZSBvd25l ciBzdWNoIGFzIGFuIGluc3RhbGxlZAogICAgICAgICAgICAgIG5hdGl2ZSBhcHBsaWNhdGlvbiBv ciBhIHdlYiBicm93c2VyLWJhc2VkIGFwcGxpY2F0aW9uKSwgYW5kIGluY2FwYWJsZSBvZiBzZWN1 cmUKICAgICAgICAgICAgICBjbGllbnQgYXV0aGVudGljYXRpb24gdmlhIGFueSBvdGhlciBtZWFu cy4KICAgICAgICAgICAgPC90PgogICAgICAgICAgPC9saXN0PgogICAgICAgIDwvdD4KICAgICAg ICA8dD4KICAgICAgICAgIFRoZSBjbGllbnQgdHlwZSBkZXNpZ25hdGlvbiBpcyBiYXNlZCBvbiB0 aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIncyBkZWZpbml0aW9uIG9mIHNlY3VyZQogICAgICAgICAg YXV0aGVudGljYXRpb24gYW5kIGl0cyBhY2NlcHRhYmxlIGV4cG9zdXJlIGxldmVscyBvZiBjbGll bnQgY3JlZGVudGlhbHMuIFRoZQogICAgICAgICAgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgU0hPVUxE IE5PVCBtYWtlIGFzc3VtcHRpb25zIGFib3V0IHRoZSBjbGllbnQgdHlwZS4KICAgICAgICA8L3Q+ CiAgICAgICAgPHQ+CiAgICAgICAgICBBIGNsaWVudCBtYXkgYmUgaW1wbGVtZW50ZWQgYXMgYSBk aXN0cmlidXRlZCBzZXQgb2YgY29tcG9uZW50cywgZWFjaCB3aXRoIGEgZGlmZmVyZW50CiAgICAg ICAgICBjbGllbnQgdHlwZSBhbmQgc2VjdXJpdHkgY29udGV4dCAoZS5nLiBhIGRpc3RyaWJ1dGVk IGNsaWVudCB3aXRoIGJvdGggYSBjb25maWRlbnRpYWwKICAgICAgICAgIHNlcnZlci1iYXNlZCBj b21wb25lbnQgYW5kIGEgcHVibGljIGJyb3dzZXItYmFzZWQgY29tcG9uZW50KS4gSWYgdGhlIGF1 dGhvcml6YXRpb24gc2VydmVyCiAgICAgICAgICBkb2VzIG5vdCBwcm92aWRlIHN1cHBvcnQgZm9y IHN1Y2ggY2xpZW50cywgb3IgZG9lcyBub3QgcHJvdmlkZSBndWlkYW5jZSB3aXRoIHJlZ2FyZCB0 bwogICAgICAgICAgdGhlaXIgcmVnaXN0cmF0aW9uLCB0aGUgY2xpZW50IFNIT1VMRCByZWdpc3Rl ciBlYWNoIGNvbXBvbmVudCBhcyBhIHNlcGFyYXRlIGNsaWVudC4KICAgICAgICA8L3Q+CiAgICAg ICAgPHQ+CiAgICAgICAgICBUaGlzIHNwZWNpZmljYXRpb24gaGFzIGJlZW4gZGVzaWduZWQgYXJv dW5kIHRoZSBmb2xsb3dpbmcgY2xpZW50IHByb2ZpbGVzOgogICAgICAgIDwvdD4KICAgICAgICA8 dD4KICAgICAgICAgIDxsaXN0IHN0eWxlPSdoYW5naW5nJz4KICAgICAgICAgICAgPHQgaGFuZ1Rl eHQ9J3dlYiBhcHBsaWNhdGlvbic+CiAgICAgICAgICAgICAgPHZzcGFjZSAvPgogICAgICAgICAg ICAgIEEgd2ViIGFwcGxpY2F0aW9uIGlzIGEgY29uZmlkZW50aWFsIGNsaWVudCBydW5uaW5nIG9u IGEgd2ViIHNlcnZlci4gUmVzb3VyY2Ugb3duZXJzCiAgICAgICAgICAgICAgYWNjZXNzIHRoZSBj bGllbnQgdmlhIGFuIEhUTUwgdXNlciBpbnRlcmZhY2UgcmVuZGVyZWQgaW4gYSB1c2VyLWFnZW50 IG9uIHRoZSBkZXZpY2UKICAgICAgICAgICAgICB1c2VkIGJ5IHRoZSByZXNvdXJjZSBvd25lci4g VGhlIGNsaWVudCBjcmVkZW50aWFscyBhcyB3ZWxsIGFzIGFueSBhY2Nlc3MgdG9rZW4gaXNzdWVk CiAgICAgICAgICAgICAgdG8gdGhlIGNsaWVudCBhcmUgc3RvcmVkIG9uIHRoZSB3ZWIgc2VydmVy IGFuZCBhcmUgbm90IGV4cG9zZWQgdG8gb3IgYWNjZXNzaWJsZSBieQogICAgICAgICAgICAgIHRo ZSByZXNvdXJjZSBvd25lci4KICAgICAgICAgICAgPC90PgogICAgICAgICAgICA8dCBoYW5nVGV4 dD0ndXNlci1hZ2VudC1iYXNlZCBhcHBsaWNhdGlvbic+CiAgICAgICAgICAgICAgPHZzcGFjZSAv PgogICAgICAgICAgICAgIEEgdXNlci1hZ2VudC1iYXNlZCBhcHBsaWNhdGlvbiBpcyBhIHB1Ymxp YyBjbGllbnQgaW4gd2hpY2ggdGhlIGNsaWVudCBjb2RlIGlzCiAgICAgICAgICAgICAgZG93bmxv YWRlZCBmcm9tIGEgd2ViIHNlcnZlciBhbmQgZXhlY3V0ZXMgd2l0aGluIGEgdXNlci1hZ2VudCAo ZS5nLiB3ZWIgYnJvd3Nlcikgb24KICAgICAgICAgICAgICB0aGUgZGV2aWNlIHVzZWQgYnkgdGhl IHJlc291cmNlIG93bmVyLiBQcm90b2NvbCBkYXRhIGFuZCBjcmVkZW50aWFscyBhcmUgZWFzaWx5 CiAgICAgICAgICAgICAgYWNjZXNzaWJsZSAoYW5kIG9mdGVuIHZpc2libGUpIHRvIHRoZSByZXNv dXJjZSBvd25lci4gU2luY2Ugc3VjaCBhcHBsaWNhdGlvbnMgcmVzaWRlCiAgICAgICAgICAgICAg d2l0aGluIHRoZSB1c2VyLWFnZW50LCB0aGV5IGNhbiBtYWtlIHNlYW1sZXNzIHVzZSBvZiB0aGUg dXNlci1hZ2VudCBjYXBhYmlsaXRpZXMgd2hlbgogICAgICAgICAgICAgIHJlcXVlc3RpbmcgYXV0 aG9yaXphdGlvbi4KICAgICAgICAgICAgPC90PgogICAgICAgICAgICA8dCBoYW5nVGV4dD0nbmF0 aXZlIGFwcGxpY2F0aW9uJz4KICAgICAgICAgICAgICA8dnNwYWNlIC8+CiAgICAgICAgICAgICAg QSBuYXRpdmUgYXBwbGljYXRpb24gaXMgYSBwdWJsaWMgY2xpZW50IGluc3RhbGxlZCBhbmQgZXhl Y3V0ZWQgb24gdGhlIGRldmljZSB1c2VkIGJ5CiAgICAgICAgICAgICAgdGhlIHJlc291cmNlIG93 bmVyLiBQcm90b2NvbCBkYXRhIGFuZCBjcmVkZW50aWFscyBhcmUgYWNjZXNzaWJsZSB0byB0aGUg cmVzb3VyY2UKICAgICAgICAgICAgICBvd25lci4gSXQgaXMgYXNzdW1lZCB0aGF0IGFueSBjbGll bnQgYXV0aGVudGljYXRpb24gY3JlZGVudGlhbHMgaW5jbHVkZWQgaW4gdGhlCiAgICAgICAgICAg ICAgYXBwbGljYXRpb24gY2FuIGJlIGV4dHJhY3RlZC4gT24gdGhlIG90aGVyIGhhbmQsIGR5bmFt aWNhbGx5IGlzc3VlZCBjcmVkZW50aWFscyBzdWNoCiAgICAgICAgICAgICAgYXMgYWNjZXNzIHRv a2VucyBvciByZWZyZXNoIHRva2VucyBjYW4gcmVjZWl2ZSBhbiBhY2NlcHRhYmxlIGxldmVsIG9m IHByb3RlY3Rpb24uIEF0IGEKICAgICAgICAgICAgICBtaW5pbXVtLCB0aGVzZSBjcmVkZW50aWFs cyBhcmUgcHJvdGVjdGVkIGZyb20gaG9zdGlsZSBzZXJ2ZXJzIHdpdGggd2hpY2ggdGhlCiAgICAg ICAgICAgICAgYXBwbGljYXRpb24gbWF5IGludGVyYWN0IHdpdGguIE9uIHNvbWUgcGxhdGZvcm1z IHRoZXNlIGNyZWRlbnRpYWxzIG1pZ2h0IGJlIHByb3RlY3RlZAogICAgICAgICAgICAgIGZyb20g b3RoZXIgYXBwbGljYXRpb25zIHJlc2lkaW5nIG9uIHRoZSBzYW1lIGRldmljZS4KICAgICAgICAg ICAgPC90PgogICAgICAgICAgPC9saXN0PgogICAgICAgIDwvdD4KICAgICAgPC9zZWN0aW9uPgoK ICAgICAgPHNlY3Rpb24gdGl0bGU9J0NsaWVudCBJZGVudGlmaWVyJyBhbmNob3I9J2NsaWVudC1p ZGVudGlmaWVyJz4KICAgICAgICA8dD4KICAgICAgICAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZl ciBpc3N1ZXMgdGhlIHJlZ2lzdGVyZWQgY2xpZW50IGEgY2xpZW50IGlkZW50aWZpZXIgLSBhIHVu aXF1ZQogICAgICAgICAgc3RyaW5nIHJlcHJlc2VudGluZyB0aGUgcmVnaXN0cmF0aW9uIGluZm9y bWF0aW9uIHByb3ZpZGVkIGJ5IHRoZSBjbGllbnQuIFRoZSBjbGllbnQKICAgICAgICAgIGlkZW50 aWZpZXIgaXMgbm90IGEgc2VjcmV0OyBpdCBpcyBleHBvc2VkIHRvIHRoZSByZXNvdXJjZSBvd25l ciwgYW5kIE1VU1QgTk9UIGJlIHVzZWQKICAgICAgICAgIGFsb25lIGZvciBjbGllbnQgYXV0aGVu dGljYXRpb24uIFRoZSBjbGllbnQgaWRlbnRpZmllciBpcyB1bmlxdWUgdG8gdGhlIGF1dGhvcml6 YXRpb24KICAgICAgICAgIHNlcnZlci4KICAgICAgICA8L3Q+CiAgICAgICAgPHQ+CiAgICAgICAg ICBUaGUgY2xpZW50IGlkZW50aWZpZXIgc3RyaW5nIHNpemUgaXMgbGVmdCB1bmRlZmluZWQgYnkg dGhpcyBzcGVjaWZpY2F0aW9uLiBUaGUgY2xpZW50CiAgICAgICAgICBzaG91bGQgYXZvaWQgbWFr aW5nIGFzc3VtcHRpb25zIGFib3V0IHRoZSBpZGVudGlmaWVyIHNpemUuICBUaGUgYXV0aG9yaXph dGlvbiBzZXJ2ZXIKICAgICAgICAgIFNIT1VMRCBkb2N1bWVudCB0aGUgc2l6ZSBvZiBhbnkgaWRl bnRpZmllciBpdCBpc3N1ZXMuCiAgICAgICAgPC90PgogICAgICA8L3NlY3Rpb24+CgogICAgICA8 c2VjdGlvbiB0aXRsZT0nQ2xpZW50IEF1dGhlbnRpY2F0aW9uJyBhbmNob3I9J2NsaWVudC1hdXRo ZW50aWNhdGlvbic+CiAgICAgICAgPHQ+CiAgICAgICAgICBJZiB0aGUgY2xpZW50IHR5cGUgaXMg Y29uZmlkZW50aWFsLCB0aGUgY2xpZW50IGFuZCBhdXRob3JpemF0aW9uIHNlcnZlciBlc3RhYmxp c2ggYSBjbGllbnQKICAgICAgICAgIGF1dGhlbnRpY2F0aW9uIG1ldGhvZCBzdWl0YWJsZSBmb3Ig dGhlIHNlY3VyaXR5IHJlcXVpcmVtZW50cyBvZiB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIuCiAg ICAgICAgICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTUFZIGFjY2VwdCBhbnkgZm9ybSBvZiBj bGllbnQgYXV0aGVudGljYXRpb24gbWVldGluZyBpdHMKICAgICAgICAgIHNlY3VyaXR5IHJlcXVp cmVtZW50cy4KICAgICAgICA8L3Q+CiAgICAgICAgPHQ+CiAgICAgICAgICBDb25maWRlbnRpYWwg Y2xpZW50cyBhcmUgdHlwaWNhbGx5IGlzc3VlZCAob3IgZXN0YWJsaXNoKSBhIHNldCBvZiBjbGll bnQgY3JlZGVudGlhbHMgdXNlZCBmb3IKICAgICAgICAgIGF1dGhlbnRpY2F0aW5nIHdpdGggdGhl IGF1dGhvcml6YXRpb24gc2VydmVyIChlLmcuIHBhc3N3b3JkLCBwdWJsaWMvcHJpdmF0ZSBrZXkg cGFpcikuCiAgICAgICAgPC90PgogICAgICAgIDx0PgogICAgICAgICAgVGhlIGF1dGhvcml6YXRp b24gc2VydmVyIE1BWSBlc3RhYmxpc2ggYSBjbGllbnQgYXV0aGVudGljYXRpb24gbWV0aG9kIHdp dGggcHVibGljIGNsaWVudHMuCiAgICAgICAgICBIb3dldmVyLCB0aGUgYXV0aG9yaXphdGlvbiBz ZXJ2ZXIgTVVTVCBOT1QgcmVseSBvbiBwdWJsaWMgY2xpZW50IGF1dGhlbnRpY2F0aW9uIGZvciB0 aGUKICAgICAgICAgIHB1cnBvc2Ugb2YgaWRlbnRpZnlpbmcgdGhlIGNsaWVudC4KICAgICAgICA8 L3Q+CiAgICAgICAgPHQ+CiAgICAgICAgICBUaGUgY2xpZW50IE1VU1QgTk9UIHVzZSBtb3JlIHRo YW4gb25lIGF1dGhlbnRpY2F0aW9uIG1ldGhvZCBpbiBlYWNoIHJlcXVlc3QuCiAgICAgICAgPC90 PgoKICAgICAgICA8c2VjdGlvbiB0aXRsZT0nQ2xpZW50IFBhc3N3b3JkJyBhbmNob3I9ImNsaWVu dC1wYXNzd29yZCI+CiAgICAgICAgICA8dD4KICAgICAgICAgICAgQ2xpZW50cyBpbiBwb3NzZXNz aW9uIG9mIGEgY2xpZW50IHBhc3N3b3JkIE1BWSB1c2UgdGhlIEhUVFAgQmFzaWMgYXV0aGVudGlj YXRpb24gc2NoZW1lCiAgICAgICAgICAgIGFzIGRlZmluZWQgaW4gPHhyZWYgdGFyZ2V0PSdSRkMy NjE3JyAvPiB0byBhdXRoZW50aWNhdGUgd2l0aCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIuCiAg ICAgICAgICAgIFRoZSBjbGllbnQgaWRlbnRpZmllciBpcyB1c2VkIGFzIHRoZSB1c2VybmFtZSwg YW5kIHRoZSBjbGllbnQgcGFzc3dvcmQgaXMgdXNlZCBhcyB0aGUKICAgICAgICAgICAgcGFzc3dv cmQuIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBNVVNUIHN1cHBvcnQgdGhlIEhUVFAgQmFzaWMg YXV0aGVudGljYXRpb24gc2NoZW1lCiAgICAgICAgICAgIGZvciBhdXRoZW50aWNhdGluZyBjbGll bnRzIHdoaWNoIHdlcmUgaXNzdWVkIGEgY2xpZW50IHBhc3N3b3JkLgogICAgICAgICAgPC90Pgog ICAgICAgICAgPGZpZ3VyZT4KICAgICAgICAgICAgPHByZWFtYmxlPgogICAgICAgICAgICAgIEZv ciBleGFtcGxlIChleHRyYSBsaW5lIGJyZWFrcyBhcmUgZm9yIGRpc3BsYXkgcHVycG9zZXMgb25s eSk6CiAgICAgICAgICAgIDwvcHJlYW1ibGU+CiAgICAgICAgICAgIDxhcnR3b3JrPgogICAgICAg ICAgICAgIDwhW0NEQVRBWwogIEF1dGhvcml6YXRpb246IEJhc2ljIGN6WkNhR1JTYTNGME16bzNS bXBtY0RCYVFuSXhTM1JFVW1KdVpsWmtiVWwzCl1dPgogICAgICAgICAgICA8L2FydHdvcms+CiAg ICAgICAgICA8L2ZpZ3VyZT4KICAgICAgICAgIDx0PgogICAgICAgICAgICBBbHRlcm5hdGl2ZWx5 LCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTUFZIHN1cHBvcnQgaW5jbHVkaW5nIHRoZSBjbGll bnQgY3JlZGVudGlhbHMgaW4KICAgICAgICAgICAgdGhlIHJlcXVlc3QgYm9keSB1c2luZyB0aGUg Zm9sbG93aW5nIHBhcmFtZXRlcnM6CiAgICAgICAgICA8L3Q+CiAgICAgICAgICA8dD4KICAgICAg ICAgICAgPGxpc3Qgc3R5bGU9J2hhbmdpbmcnIGhhbmdJbmRlbnQ9JzYnPgogICAgICAgICAgICAg IDx0IGhhbmdUZXh0PSdjbGllbnRfaWQnPgogICAgICAgICAgICAgICAgPHZzcGFjZSAvPgogICAg ICAgICAgICAgICAgUkVRVUlSRUQuIFRoZSBjbGllbnQgaWRlbnRpZmllciBpc3N1ZWQgdG8gdGhl IGNsaWVudCBkdXJpbmcgdGhlIHJlZ2lzdHJhdGlvbiBwcm9jZXNzCiAgICAgICAgICAgICAgICBk ZXNjcmliZWQgYnkgPHhyZWYgdGFyZ2V0PSdjbGllbnQtaWRlbnRpZmllcicgLz4uCiAgICAgICAg ICAgICAgPC90PgogICAgICAgICAgICAgIDx0IGhhbmdUZXh0PSdjbGllbnRfc2VjcmV0Jz4KICAg ICAgICAgICAgICAgIDx2c3BhY2UgLz4KICAgICAgICAgICAgICAgIFJFUVVJUkVELiBUaGUgY2xp ZW50IHNlY3JldC4gVGhlIGNsaWVudCBNQVkgb21pdCB0aGUgcGFyYW1ldGVyIGlmIHRoZSBjbGll bnQgc2VjcmV0CiAgICAgICAgICAgICAgICBpcyBhbiBlbXB0eSBzdHJpbmcuCiAgICAgICAgICAg ICAgPC90PgogICAgICAgICAgICA8L2xpc3Q+CiAgICAgICAgICA8L3Q+CiAgICAgICAgICA8dD4K ICAgICAgICAgICAgSW5jbHVkaW5nIHRoZSBjbGllbnQgY3JlZGVudGlhbHMgaW4gdGhlIHJlcXVl c3QgYm9keSB1c2luZyB0aGUgdHdvIHBhcmFtZXRlcnMgaXMgTk9UCiAgICAgICAgICAgIFJFQ09N TUVOREVELCBhbmQgU0hPVUxEIGJlIGxpbWl0ZWQgdG8gY2xpZW50cyB1bmFibGUgdG8gZGlyZWN0 bHkgdXRpbGl6ZSB0aGUgSFRUUCBCYXNpYwogICAgICAgICAgICBhdXRoZW50aWNhdGlvbiBzY2hl bWUgKG9yIG90aGVyIHBhc3N3b3JkLWJhc2VkIEhUVFAgYXV0aGVudGljYXRpb24gc2NoZW1lcyku IFRoZQogICAgICAgICAgICBwYXJhbWV0ZXJzIGNhbiBvbmx5IGJlIHRyYW5zbWl0dGVkIGluIHRo ZSByZXF1ZXN0IGJvZHkgYW5kIE1VU1QgTk9UIGJlIGluY2x1ZGVkIGluIHRoZQogICAgICAgICAg ICByZXF1ZXN0IFVSSS4KICAgICAgICAgIDwvdD4KICAgICAgICAgIDxmaWd1cmU+CiAgICAgICAg ICAgIDxwcmVhbWJsZT4KICAgICAgICAgICAgICBGb3IgZXhhbXBsZSwgcmVxdWVzdGluZyB0byBy ZWZyZXNoIGFuIGFjY2VzcyB0b2tlbiAoPHhyZWYgdGFyZ2V0PSd0b2tlbi1yZWZyZXNoJyAvPikK ICAgICAgICAgICAgICB1c2luZyB0aGUgYm9keSBwYXJhbWV0ZXJzIChleHRyYSBsaW5lIGJyZWFr cyBhcmUgZm9yIGRpc3BsYXkgcHVycG9zZXMgb25seSk6CiAgICAgICAgICAgIDwvcHJlYW1ibGU+ CiAgICAgICAgICAgIDxhcnR3b3JrPgogICAgICAgICAgICAgIDwhW0NEQVRBWwogIFBPU1QgL3Rv a2VuIEhUVFAvMS4xCiAgSG9zdDogc2VydmVyLmV4YW1wbGUuY29tCiAgQ29udGVudC1UeXBlOiBh cHBsaWNhdGlvbi94LXd3dy1mb3JtLXVybGVuY29kZWQ7Y2hhcnNldD1VVEYtOAoKICBncmFudF90 eXBlPXJlZnJlc2hfdG9rZW4mcmVmcmVzaF90b2tlbj10R3p2M0pPa0YwWEc1UXgyVGxLV0lBCiAg JmNsaWVudF9pZD1zNkJoZFJrcXQzJmNsaWVudF9zZWNyZXQ9N0ZqZnAwWkJyMUt0RFJibmZWZG1J dwpdXT4KICAgICAgICAgICAgPC9hcnR3b3JrPgogICAgICAgICAgPC9maWd1cmU+CiAgICAgICAg ICA8dD4KICAgICAgICAgICAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIE1VU1QgcmVxdWlyZSB0 aGUgdXNlIG9mIFRMUyBhcyBkZXNjcmliZWQgaW4KICAgICAgICAgICAgPHhyZWYgdGFyZ2V0PSd0 bHMnIC8+IHdoZW4gc2VuZGluZyByZXF1ZXN0cyB1c2luZyBwYXNzd29yZCBhdXRoZW50aWNhdGlv bi4KICAgICAgICAgIDwvdD4KICAgICAgICAgIDx0PgogICAgICAgICAgICBTaW5jZSB0aGlzIGNs aWVudCBhdXRoZW50aWNhdGlvbiBtZXRob2QgaW52b2x2ZXMgYSBwYXNzd29yZCwgdGhlIGF1dGhv cml6YXRpb24gc2VydmVyCiAgICAgICAgICAgIE1VU1QgcHJvdGVjdCBhbnkgZW5kcG9pbnQgdXRp bGl6aW5nIGl0IGFnYWluc3QgYnJ1dGUgZm9yY2UgYXR0YWNrcy4KICAgICAgICAgIDwvdD4KICAg ICAgICA8L3NlY3Rpb24+CgogICAgICAgIDxzZWN0aW9uIHRpdGxlPSdPdGhlciBBdXRoZW50aWNh dGlvbiBNZXRob2RzJz4KICAgICAgICAgIDx0PgogICAgICAgICAgICBUaGUgYXV0aG9yaXphdGlv biBzZXJ2ZXIgTUFZIHN1cHBvcnQgYW55IHN1aXRhYmxlIEhUVFAgYXV0aGVudGljYXRpb24gc2No ZW1lIG1hdGNoaW5nCiAgICAgICAgICAgIGl0cyBzZWN1cml0eSByZXF1aXJlbWVudHMuIFdoZW4g dXNpbmcgb3RoZXIgYXV0aGVudGljYXRpb24gbWV0aG9kcywgdGhlIGF1dGhvcml6YXRpb24KICAg ICAgICAgICAgc2VydmVyIE1VU1QgZGVmaW5lIGEgbWFwcGluZyBiZXR3ZWVuIHRoZSBjbGllbnQg aWRlbnRpZmllciAocmVnaXN0cmF0aW9uIHJlY29yZCkgYW5kCiAgICAgICAgICAgIGF1dGhlbnRp Y2F0aW9uIHNjaGVtZS4KICAgICAgICAgIDwvdD4KICAgICAgICA8L3NlY3Rpb24+CgogICAgICA8 L3NlY3Rpb24+CgogICAgICA8c2VjdGlvbiB0aXRsZT0nVW5yZWdpc3RlcmVkIENsaWVudHMnPgog ICAgICAgIDx0PgogICAgICAgICAgVGhpcyBzcGVjaWZpY2F0aW9uIGRvZXMgbm90IGV4Y2x1ZGUg dGhlIHVzZSBvZiB1bnJlZ2lzdGVyZWQgY2xpZW50cy4gSG93ZXZlciwgdGhlIHVzZQogICAgICAg ICAgd2l0aCBzdWNoIGNsaWVudHMgaXMgYmV5b25kIHRoZSBzY29wZSBvZiB0aGlzIHNwZWNpZmlj YXRpb24sIGFuZCByZXF1aXJlcyBhZGRpdGlvbmFsCiAgICAgICAgICBzZWN1cml0eSBhbmFseXNp cyBhbmQgcmV2aWV3IG9mIGl0cyBpbnRlcm9wZXJhYmlsaXR5IGltcGFjdC4KICAgICAgICA8L3Q+ CiAgICAgIDwvc2VjdGlvbj4KICAgICAgCiAgICA8L3NlY3Rpb24+CgogICAgPHNlY3Rpb24gdGl0 bGU9J1Byb3RvY29sIEVuZHBvaW50cyc+CiAgICAgIDx0PgogICAgICAgIFRoZSBhdXRob3JpemF0 aW9uIHByb2Nlc3MgdXRpbGl6ZXMgdHdvIGF1dGhvcml6YXRpb24gc2VydmVyIGVuZHBvaW50cyAo SFRUUCByZXNvdXJjZXMpOgogICAgICA8L3Q+CiAgICAgIDx0PgogICAgICAgIDxsaXN0IHN0eWxl PSdzeW1ib2xzJz4KICAgICAgICAgIDx0PgogICAgICAgICAgICBBdXRob3JpemF0aW9uIGVuZHBv aW50IC0gdXNlZCBieSB0aGUgY2xpZW50IHRvIG9idGFpbiBhdXRob3JpemF0aW9uIGZyb20gdGhl IHJlc291cmNlCiAgICAgICAgICAgIG93bmVyIHZpYSB1c2VyLWFnZW50IHJlZGlyZWN0aW9uLgog ICAgICAgICAgPC90PgogICAgICAgICAgPHQ+CiAgICAgICAgICAgIFRva2VuIGVuZHBvaW50IC0g dXNlZCBieSB0aGUgY2xpZW50IHRvIGV4Y2hhbmdlIGFuIGF1dGhvcml6YXRpb24gZ3JhbnQgZm9y IGFuIGFjY2VzcwogICAgICAgICAgICB0b2tlbiwgdHlwaWNhbGx5IHdpdGggY2xpZW50IGF1dGhl bnRpY2F0aW9uLgogICAgICAgICAgPC90PgogICAgICAgIDwvbGlzdD4KICAgICAgPC90PgogICAg ICA8dD4KICAgICAgICBBcyB3ZWxsIGFzIG9uZSBjbGllbnQgZW5kcG9pbnQ6CiAgICAgIDwvdD4K ICAgICAgPHQ+CiAgICAgICAgPGxpc3Qgc3R5bGU9J3N5bWJvbHMnPgogICAgICAgICAgPHQ+CiAg ICAgICAgICAgIFJlZGlyZWN0aW9uIGVuZHBvaW50IC0gdXNlZCBieSB0aGUgYXV0aG9yaXphdGlv biBzZXJ2ZXIgdG8gcmV0dXJuIGF1dGhvcml6YXRpb24KICAgICAgICAgICAgY3JlZGVudGlhbHMg cmVzcG9uc2VzIHRvIHRoZSBjbGllbnQgdmlhIHRoZSByZXNvdXJjZSBvd25lciB1c2VyLWFnZW50 LgogICAgICAgICAgPC90PgogICAgICAgIDwvbGlzdD4KICAgICAgPC90PgogICAgICA8dD4KICAg ICAgICBOb3QgZXZlcnkgYXV0aG9yaXphdGlvbiBncmFudCB0eXBlIHV0aWxpemVzIGJvdGggZW5k cG9pbnRzLiBFeHRlbnNpb24gZ3JhbnQgdHlwZXMgTUFZCiAgICAgICAgZGVmaW5lIGFkZGl0aW9u YWwgZW5kcG9pbnRzIGFzIG5lZWRlZC4KICAgICAgPC90PgoKICAgICAgPHNlY3Rpb24gdGl0bGU9 J0F1dGhvcml6YXRpb24gRW5kcG9pbnQnPgogICAgICAgIDx0PgogICAgICAgICAgVGhlIGF1dGhv cml6YXRpb24gZW5kcG9pbnQgaXMgdXNlZCB0byBpbnRlcmFjdCB3aXRoIHRoZSByZXNvdXJjZSBv d25lciBhbmQgb2J0YWluCiAgICAgICAgICBhbiBhdXRob3JpemF0aW9uIGdyYW50LiBUaGUgYXV0 aG9yaXphdGlvbiBzZXJ2ZXIgTVVTVCBmaXJzdCB2ZXJpZnkgdGhlIGlkZW50aXR5IG9mIHRoZQog ICAgICAgICAgcmVzb3VyY2Ugb3duZXIuIFRoZSB3YXkgaW4gd2hpY2ggdGhlIGF1dGhvcml6YXRp b24gc2VydmVyIGF1dGhlbnRpY2F0ZXMgdGhlIHJlc291cmNlCiAgICAgICAgICBvd25lciAoZS5n LiB1c2VybmFtZSBhbmQgcGFzc3dvcmQgbG9naW4sIHNlc3Npb24gY29va2llcykgaXMgYmV5b25k IHRoZSBzY29wZSBvZiB0aGlzCiAgICAgICAgICBzcGVjaWZpY2F0aW9uLgogICAgICAgIDwvdD4K ICAgICAgICA8dD4KICAgICAgICAgIFRoZSBtZWFucyB0aHJvdWdoIHdoaWNoIHRoZSBjbGllbnQg b2J0YWlucyB0aGUgbG9jYXRpb24gb2YgdGhlIGF1dGhvcml6YXRpb24gZW5kcG9pbnQgYXJlCiAg ICAgICAgICBiZXlvbmQgdGhlIHNjb3BlIG9mIHRoaXMgc3BlY2lmaWNhdGlvbiwgYnV0IHRoZSBs b2NhdGlvbiBpcyB0eXBpY2FsbHkgcHJvdmlkZWQgaW4gdGhlCiAgICAgICAgICBzZXJ2aWNlIGRv Y3VtZW50YXRpb24uCiAgICAgICAgPC90PgogICAgICAgIDx0PgogICAgICAgICAgVGhlIGVuZHBv aW50IFVSSSBNQVkgaW5jbHVkZSBhbgogICAgICAgICAgPHNwYW54IHN0eWxlPSd2ZXJiJz5hcHBs aWNhdGlvbi94LXd3dy1mb3JtLXVybGVuY29kZWQ8L3NwYW54PiBmb3JtYXR0ZWQKICAgICAgICAg ICg8eHJlZiB0YXJnZXQ9J1czQy5SRUMtaHRtbDQwMS0xOTk5MTIyNCcgLz4pIHF1ZXJ5IGNvbXBv bmVudCAoPHhyZWYgdGFyZ2V0PSdSRkMzOTg2JyAvPgogICAgICAgICAgc2VjdGlvbiAzLjQpLCB3 aGljaCBNVVNUIGJlIHJldGFpbmVkIHdoZW4gYWRkaW5nIGFkZGl0aW9uYWwgcXVlcnkgcGFyYW1l dGVycy4gVGhlCiAgICAgICAgICBlbmRwb2ludCBVUkkgTVVTVCBOT1QgaW5jbHVkZSBhIGZyYWdt ZW50IGNvbXBvbmVudC4KICAgICAgICA8L3Q+CiAgICAgICAgPHQ+CiAgICAgICAgICBTaW5jZSBy ZXF1ZXN0cyB0byB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludCByZXN1bHQgaW4gdXNlciBhdXRo ZW50aWNhdGlvbiBhbmQgdGhlCiAgICAgICAgICB0cmFuc21pc3Npb24gb2YgY2xlYXItdGV4dCBj cmVkZW50aWFscyAoaW4gdGhlIEhUVFAgcmVzcG9uc2UpLCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2 ZXIKICAgICAgICAgIE1VU1QgcmVxdWlyZSB0aGUgdXNlIG9mIFRMUyBhcyBkZXNjcmliZWQgaW4g PHhyZWYgdGFyZ2V0PSd0bHMnIC8+IHdoZW4gc2VuZGluZyByZXF1ZXN0cwogICAgICAgICAgdG8g dGhlIGF1dGhvcml6YXRpb24gZW5kcG9pbnQuCiAgICAgICAgPC90PgogICAgICAgIDx0PgogICAg ICAgICAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIE1VU1Qgc3VwcG9ydCB0aGUgdXNlIG9mIHRo ZSBIVFRQIDxzcGFueCBzdHlsZT0ndmVyYic+R0VUPC9zcGFueD4KICAgICAgICAgIG1ldGhvZCA8 eHJlZiB0YXJnZXQ9J1JGQzI2MTYnIC8+IGZvciB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludCwg YW5kIE1BWSBzdXBwb3J0IHRoZSB1c2UKICAgICAgICAgIG9mIHRoZSA8c3Bhbnggc3R5bGU9J3Zl cmInPlBPU1Q8L3NwYW54PiBtZXRob2QgYXMgd2VsbC4KICAgICAgICA8L3Q+CiAgICAgICAgPHQ+ CiAgICAgICAgICBQYXJhbWV0ZXJzIHNlbnQgd2l0aG91dCBhIHZhbHVlIE1VU1QgYmUgdHJlYXRl ZCBhcyBpZiB0aGV5IHdlcmUgb21pdHRlZCBmcm9tIHRoZSByZXF1ZXN0LgogICAgICAgICAgVGhl IGF1dGhvcml6YXRpb24gc2VydmVyIE1VU1QgaWdub3JlIHVucmVjb2duaXplZCByZXF1ZXN0IHBh cmFtZXRlcnMuIFJlcXVlc3QgYW5kCiAgICAgICAgICByZXNwb25zZSBwYXJhbWV0ZXJzIE1VU1Qg Tk9UIGJlIGluY2x1ZGVkIG1vcmUgdGhhbiBvbmNlLgogICAgICAgIDwvdD4KCiAgICAgICAgPHNl Y3Rpb24gdGl0bGU9J1Jlc3BvbnNlIFR5cGUnIGFuY2hvcj0icmVzcG9uc2UtdHlwZSI+CiAgICAg ICAgICA8dD4KICAgICAgICAgICAgVGhlIGF1dGhvcml6YXRpb24gZW5kcG9pbnQgaXMgdXNlZCBi eSB0aGUgYXV0aG9yaXphdGlvbiBjb2RlIGdyYW50IHR5cGUgYW5kIGltcGxpY2l0CiAgICAgICAg ICAgIGdyYW50IHR5cGUgZmxvd3MuIFRoZSBjbGllbnQgaW5mb3JtcyB0aGUgYXV0aG9yaXphdGlv biBzZXJ2ZXIgb2YgdGhlIGRlc2lyZWQgZ3JhbnQKICAgICAgICAgICAgdHlwZSB1c2luZyB0aGUg Zm9sbG93aW5nIHBhcmFtZXRlcjoKICAgICAgICAgIDwvdD4KICAgICAgICAgIDx0PgogICAgICAg ICAgICA8bGlzdCBzdHlsZT0naGFuZ2luZycgaGFuZ0luZGVudD0nNic+CiAgICAgICAgICAgICAg PHQgaGFuZ1RleHQ9J3Jlc3BvbnNlX3R5cGUnPgogICAgICAgICAgICAgICAgPHZzcGFjZSAvPgog ICAgICAgICAgICAgICAgUkVRVUlSRUQuIFRoZSB2YWx1ZSBNVVNUIGJlIG9uZSBvZiA8c3Bhbngg c3R5bGU9J3ZlcmInPmNvZGU8L3NwYW54PiBmb3IgcmVxdWVzdGluZwogICAgICAgICAgICAgICAg YW4gYXV0aG9yaXphdGlvbiBjb2RlIGFzIGRlc2NyaWJlZCBieSA8eHJlZiB0YXJnZXQ9J2NvZGUt YXV0aHotcmVxJyAvPiwKICAgICAgICAgICAgICAgIDxzcGFueCBzdHlsZT0ndmVyYic+dG9rZW48 L3NwYW54PiBmb3IgcmVxdWVzdGluZyBhbiBhY2Nlc3MgdG9rZW4gKGltcGxpY2l0IGdyYW50KQog ICAgICAgICAgICAgICAgYXMgZGVzY3JpYmVkIGJ5IDx4cmVmIHRhcmdldD0naW1wbGljaXQtYXV0 aHotcmVxJyAvPiwgb3IgYSByZWdpc3RlcmVkIGV4dGVuc2lvbgogICAgICAgICAgICAgICAgdmFs dWUgYXMgZGVzY3JpYmVkIGJ5IDx4cmVmIHRhcmdldD0ncmVzcG9uc2UtdHlwZS1leHQnIC8+Lgog ICAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAgPC9saXN0PgogICAgICAgICAgPC90PgogICAg ICAgICAgPHQ+CiAgICAgICAgICAgIEV4dGVuc2lvbiByZXNwb25zZSB0eXBlcyBNQVkgY29udGFp biBhIHNwYWNlLWRlbGltaXRlZCAoJXgyMCkgbGlzdCBvZiB2YWx1ZXMsIHdoZXJlIHRoZQogICAg ICAgICAgICBvcmRlciBvZiB2YWx1ZXMgZG9lcyBub3QgbWF0dGVyIChlLmcuIHJlc3BvbnNlIHR5 cGUgPHNwYW54IHN0eWxlPSd2ZXJiJz5hIGI8L3NwYW54PiBpcwogICAgICAgICAgICB0aGUgc2Ft ZSBhcyA8c3Bhbnggc3R5bGU9J3ZlcmInPmIgYTwvc3Bhbng+KS4gVGhlIG1lYW5pbmcgb2Ygc3Vj aCBjb21wb3NpdGUgcmVzcG9uc2UKICAgICAgICAgICAgdHlwZXMgaXMgZGVmaW5lZCBieSB0aGVp ciByZXNwZWN0aXZlIHNwZWNpZmljYXRpb25zLgogICAgICAgICAgPC90PgogICAgICAgICAgPHQ+ CiAgICAgICAgICAgIElmIGFuIGF1dGhvcml6YXRpb24gcmVxdWVzdCBpcyBtaXNzaW5nIHRoZSA8 c3Bhbnggc3R5bGU9J3ZlcmInPnJlc3BvbnNlX3R5cGU8L3NwYW54PgogICAgICAgICAgICBwYXJh bWV0ZXIsIG9yIGlmIHRoZSByZXNwb25zZSB0eXBlIGlzIG5vdCB1bmRlcnN0b29kLCB0aGUgYXV0 aG9yaXphdGlvbiBzZXJ2ZXIgTVVTVAogICAgICAgICAgICByZXR1cm4gYW4gZXJyb3IgcmVzcG9u c2UgYXMgZGVzY3JpYmVkIGluIDx4cmVmIHRhcmdldD0nY29kZS1hdXRoei1lcnJvcicgLz4uCiAg ICAgICAgICA8L3Q+CiAgICAgICAgPC9zZWN0aW9uPgoKICAgICAgICA8c2VjdGlvbiB0aXRsZT0n UmVkaXJlY3Rpb24gRW5kcG9pbnQnIGFuY2hvcj0ncmVkaXJlY3QtdXJpJz4KICAgICAgICAgIDx0 PgogICAgICAgICAgICBBZnRlciBjb21wbGV0aW5nIGl0cyBpbnRlcmFjdGlvbiB3aXRoIHRoZSBy ZXNvdXJjZSBvd25lciwgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyCiAgICAgICAgICAgIGRpcmVj dHMgdGhlIHJlc291cmNlIG93bmVyJ3MgdXNlci1hZ2VudCBiYWNrIHRvIHRoZSBjbGllbnQuIFRo ZSBhdXRob3JpemF0aW9uIHNlcnZlcgogICAgICAgICAgICByZWRpcmVjdHMgdGhlIHVzZXItYWdl bnQgdG8gdGhlIGNsaWVudCdzIHJlZGlyZWN0aW9uIGVuZHBvaW50IHByZXZpb3VzbHkgZXN0YWJs aXNoZWQKICAgICAgICAgICAgd2l0aCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgZHVyaW5nIHRo ZSBjbGllbnQgcmVnaXN0cmF0aW9uIHByb2Nlc3Mgb3Igd2hlbiBtYWtpbmcKICAgICAgICAgICAg dGhlIGF1dGhvcml6YXRpb24gcmVxdWVzdC4KICAgICAgICAgIDwvdD4KICAgICAgICAgIDx0Pgog ICAgICAgICAgICBUaGUgcmVkaXJlY3Rpb24gZW5kcG9pbnQgVVJJIE1VU1QgYmUgYW4gYWJzb2x1 dGUgVVJJIGFzIGRlZmluZWQgYnkKICAgICAgICAgICAgPHhyZWYgdGFyZ2V0PSdSRkMzOTg2JyAv PiBzZWN0aW9uIDQuMy4gVGhlIGVuZHBvaW50IFVSSSBNQVkgaW5jbHVkZSBhbgogICAgICAgICAg ICA8c3Bhbnggc3R5bGU9J3ZlcmInPmFwcGxpY2F0aW9uL3gtd3d3LWZvcm0tdXJsZW5jb2RlZDwv c3Bhbng+IGZvcm1hdHRlZAogICAgICAgICAgICAoPHhyZWYgdGFyZ2V0PSdXM0MuUkVDLWh0bWw0 MDEtMTk5OTEyMjQnIC8+KSBxdWVyeSBjb21wb25lbnQgKDx4cmVmIHRhcmdldD0nUkZDMzk4Nicg Lz4KICAgICAgICAgICAgc2VjdGlvbiAzLjQpLCB3aGljaCBNVVNUIGJlIHJldGFpbmVkIHdoZW4g YWRkaW5nIGFkZGl0aW9uYWwgcXVlcnkgcGFyYW1ldGVycy4gVGhlCiAgICAgICAgICAgIGVuZHBv aW50IFVSSSBNVVNUIE5PVCBpbmNsdWRlIGEgZnJhZ21lbnQgY29tcG9uZW50LgogICAgICAgICAg PC90PgoKICAgICAgICAgIDxzZWN0aW9uIHRpdGxlPSdFbmRwb2ludCBSZXF1ZXN0IENvbmZpZGVu dGlhbGl0eSc+CiAgICAgICAgICAgIDx0PgogICAgICAgICAgICAgIFRoZSByZWRpcmVjdGlvbiBl bmRwb2ludCBTSE9VTEQgcmVxdWlyZSB0aGUgdXNlIG9mIFRMUyBhcyBkZXNjcmliZWQgaW4KICAg ICAgICAgICAgICA8eHJlZiB0YXJnZXQ9J3RscycgLz4gd2hlbiB0aGUgcmVxdWVzdGVkIHJlc3Bv bnNlIHR5cGUgaXMKICAgICAgICAgICAgICA8c3Bhbnggc3R5bGU9J3ZlcmInPmNvZGU8L3NwYW54 PiBvciA8c3Bhbnggc3R5bGU9J3ZlcmInPnRva2VuPC9zcGFueD4sIG9yCiAgICAgICAgICAgICAg d2hlbiB0aGUgcmVkaXJlY3Rpb24gcmVxdWVzdCB3aWxsIHJlc3VsdCBpbiB0aGUgdHJhbnNtaXNz aW9uIG9mIHNlbnNpdGl2ZSBjcmVkZW50aWFscwogICAgICAgICAgICAgIG92ZXIgYW4gb3BlbiBu ZXR3b3JrLiBUaGlzIHNwZWNpZmljYXRpb24gZG9lcyBub3QgbWFuZGF0ZSB0aGUgdXNlIG9mIFRM UyBiZWNhdXNlIGF0CiAgICAgICAgICAgICAgdGhlIHRpbWUgb2YgdGhpcyB3cml0aW5nLCByZXF1 aXJpbmcgY2xpZW50cyB0byBkZXBsb3kgVExTIGlzIGEgc2lnbmlmaWNhbnQgaHVyZGxlIGZvcgog ICAgICAgICAgICAgIG1hbnkgY2xpZW50IGRldmVsb3BlcnMuIElmIFRMUyBpcyBub3QgYXZhaWxh YmxlLCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgU0hPVUxEIHdhcm4KICAgICAgICAgICAgICB0 aGUgcmVzb3VyY2Ugb3duZXIgYWJvdXQgdGhlIGluc2VjdXJlIGVuZHBvaW50IHByaW9yIHRvIHJl ZGlyZWN0aW9uIChlLmcuIGRpc3BsYXkgYQogICAgICAgICAgICAgIG1lc3NhZ2UgZHVyaW5nIHRo ZSBhdXRob3JpemF0aW9uIHJlcXVlc3QpLgogICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgIDx0 PgogICAgICAgICAgICAgIExhY2sgb2YgdHJhbnNwb3J0LWxheWVyIHNlY3VyaXR5IGNhbiBoYXZl IGEgc2V2ZXJlIGltcGFjdCBvbiB0aGUgc2VjdXJpdHkgb2YgdGhlCiAgICAgICAgICAgICAgY2xp ZW50IGFuZCB0aGUgcHJvdGVjdGVkIHJlc291cmNlcyBpdCBpcyBhdXRob3JpemVkIHRvIGFjY2Vz cy4gVGhlIHVzZSBvZgogICAgICAgICAgICAgIHRyYW5zcG9ydC1sYXllciBzZWN1cml0eSBpcyBw YXJ0aWN1bGFybHkgY3JpdGljYWwgd2hlbiB0aGUgYXV0aG9yaXphdGlvbiBwcm9jZXNzIGlzCiAg ICAgICAgICAgICAgdXNlZCBhcyBhIGZvcm0gb2YgZGVsZWdhdGVkIGVuZC11c2VyIGF1dGhlbnRp Y2F0aW9uIGJ5IHRoZSBjbGllbnQgKGUuZy4gdGhpcmQtcGFydHkKICAgICAgICAgICAgICBzaWdu LWluIHNlcnZpY2UpLgogICAgICAgICAgICA8L3Q+CiAgICAgICAgICA8L3NlY3Rpb24+CgogICAg ICAgICAgPHNlY3Rpb24gdGl0bGU9J1JlZ2lzdHJhdGlvbiBSZXF1aXJlbWVudHMnPgogICAgICAg ICAgICA8dD4KICAgICAgICAgICAgICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVTVCByZXF1 aXJlIHRoZSBmb2xsb3dpbmcgY2xpZW50cyB0byByZWdpc3RlciB0aGVpcgogICAgICAgICAgICAg IHJlZGlyZWN0aW9uIGVuZHBvaW50OgogICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgIDx0Pgog ICAgICAgICAgICAgIDxsaXN0IHN0eWxlPSdzeW1ib2xzJz4KICAgICAgICAgICAgICAgIDx0Pgog ICAgICAgICAgICAgICAgICBQdWJsaWMgY2xpZW50cy4KICAgICAgICAgICAgICAgIDwvdD4KICAg ICAgICAgICAgICAgIDx0PgogICAgICAgICAgICAgICAgICBDb25maWRlbnRpYWwgY2xpZW50cyB1 dGlsaXppbmcgdGhlIGltcGxpY2l0IGdyYW50IHR5cGUuCiAgICAgICAgICAgICAgICA8L3Q+CiAg ICAgICAgICAgICAgPC9saXN0PgogICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgIDx0PgogICAg ICAgICAgICAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBTSE9VTEQgcmVxdWlyZSBhbGwgY2xp ZW50cyB0byByZWdpc3RlciB0aGVpciByZWRpcmVjdGlvbgogICAgICAgICAgICAgIGVuZHBvaW50 IHByaW9yIHRvIHV0aWxpemluZyB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludC4KICAgICAgICAg ICAgPC90PgogICAgICAgICAgICA8dD4KICAgICAgICAgICAgICBUaGUgYXV0aG9yaXphdGlvbiBz ZXJ2ZXIgU0hPVUxEIHJlcXVpcmUgdGhlIGNsaWVudCB0byBwcm92aWRlIHRoZSBjb21wbGV0ZQog ICAgICAgICAgICAgIHJlZGlyZWN0aW9uIFVSSSAodGhlIGNsaWVudCBNQVkgdXNlIHRoZSA8c3Bh bnggc3R5bGU9J3ZlcmInPnN0YXRlPC9zcGFueD4gcmVxdWVzdAogICAgICAgICAgICAgIHBhcmFt ZXRlciB0byBhY2hpZXZlIHBlci1yZXF1ZXN0IGN1c3RvbWl6YXRpb24pLiBJZiByZXF1aXJpbmcg dGhlIHJlZ2lzdHJhdGlvbiBvZgogICAgICAgICAgICAgIHRoZSBjb21wbGV0ZSByZWRpcmVjdGlv biBVUkkgaXMgbm90IHBvc3NpYmxlLCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgU0hPVUxEIHJl cXVpcmUKICAgICAgICAgICAgICB0aGUgcmVnaXN0cmF0aW9uIG9mIHRoZSBVUkkgc2NoZW1lLCBh dXRob3JpdHksIGFuZCBwYXRoIChhbGxvd2luZyB0aGUgY2xpZW50IHRvCiAgICAgICAgICAgICAg ZHluYW1pY2FsbHkgdmFyeSBvbmx5IHRoZSBxdWVyeSBjb21wb25lbnQgb2YgdGhlIHJlZGlyZWN0 aW9uIFVSSSB3aGVuIHJlcXVlc3RpbmcKICAgICAgICAgICAgICBhdXRob3JpemF0aW9uKS4KICAg ICAgICAgICAgPC90PgogICAgICAgICAgICA8dD4KICAgICAgICAgICAgICBUaGUgYXV0aG9yaXph dGlvbiBzZXJ2ZXIgTUFZIGFsbG93IHRoZSBjbGllbnQgdG8gcmVnaXN0ZXIgbXVsdGlwbGUgcmVk aXJlY3Rpb24KICAgICAgICAgICAgICBlbmRwb2ludHMuCiAgICAgICAgICAgIDwvdD4KICAgICAg ICAgICAgPHQ+CiAgICAgICAgICAgICAgTGFjayBvZiBhIHJlZGlyZWN0aW9uIFVSSSByZWdpc3Ry YXRpb24gcmVxdWlyZW1lbnQgY2FuIGVuYWJsZSBhbiBhdHRhY2tlciB0byB1c2UKICAgICAgICAg ICAgICB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludCBhcyBvcGVuIHJlZGlyZWN0b3IgYXMgZGVz Y3JpYmVkIGluCiAgICAgICAgICAgICAgPHhyZWYgdGFyZ2V0PSdvcGVuLXJlZGlyZWN0JyAvPi4K ICAgICAgICAgICAgPC90PgogICAgICAgICAgPC9zZWN0aW9uPgoKICAgICAgICAgIDxzZWN0aW9u IHRpdGxlPSdEeW5hbWljIENvbmZpZ3VyYXRpb24nPgogICAgICAgICAgICA8dD4KICAgICAgICAg ICAgICBJZiBtdWx0aXBsZSByZWRpcmVjdGlvbiBVUklzIGhhdmUgYmVlbiByZWdpc3RlcmVkLCBp ZiBvbmx5IHBhcnQgb2YgdGhlIHJlZGlyZWN0aW9uCiAgICAgICAgICAgICAgVVJJIGhhcyBiZWVu IHJlZ2lzdGVyZWQsIG9yIGlmIG5vIHJlZGlyZWN0aW9uIFVSSSBoYXMgYmVlbiByZWdpc3RlcmVk LCB0aGUgY2xpZW50CiAgICAgICAgICAgICAgTVVTVCBpbmNsdWRlIGEgcmVkaXJlY3Rpb24gVVJJ IHdpdGggdGhlIGF1dGhvcml6YXRpb24gcmVxdWVzdCB1c2luZyB0aGUKICAgICAgICAgICAgICA8 c3Bhbnggc3R5bGU9J3ZlcmInPnJlZGlyZWN0X3VyaTwvc3Bhbng+IHJlcXVlc3QgcGFyYW1ldGVy LgogICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgIDx0PgogICAgICAgICAgICAgIFdoZW4gYSBy ZWRpcmVjdGlvbiBVUkkgaXMgaW5jbHVkZWQgaW4gYW4gYXV0aG9yaXphdGlvbiByZXF1ZXN0LCB0 aGUgYXV0aG9yaXphdGlvbgogICAgICAgICAgICAgIHNlcnZlciBNVVNUIGNvbXBhcmUgYW5kIG1h dGNoIHRoZSB2YWx1ZSByZWNlaXZlZCBhZ2FpbnN0IGF0IGxlYXN0IG9uZSBvZiB0aGUKICAgICAg ICAgICAgICByZWdpc3RlcmVkIHJlZGlyZWN0aW9uIFVSSXMgKG9yIFVSSSBjb21wb25lbnRzKSBh cyBkZWZpbmVkIGluCiAgICAgICAgICAgICAgPHhyZWYgdGFyZ2V0PSdSRkMzOTg2JyAvPiBzZWN0 aW9uIDYsIGlmIGFueSByZWRpcmVjdGlvbiBVUklzIHdlcmUgcmVnaXN0ZXJlZC4KICAgICAgICAg ICAgICBJZiB0aGUgY2xpZW50IHJlZ2lzdHJhdGlvbiBpbmNsdWRlZCB0aGUgZnVsbCByZWRpcmVj dGlvbiBVUkksIHRoZSBhdXRob3JpemF0aW9uCiAgICAgICAgICAgICAgc2VydmVyIE1VU1QgY29t cGFyZSB0aGUgdHdvIFVSSXMgdXNpbmcgc2ltcGxlIHN0cmluZyBjb21wYXJpc29uIGFzIGRlZmlu ZWQKICAgICAgICAgICAgICBpbiA8eHJlZiB0YXJnZXQ9J1JGQzM5ODYnIC8+IHNlY3Rpb24gNi4y LjEuCiAgICAgICAgICAgIDwvdD4KICAgICAgICAgPC9zZWN0aW9uPgoKICAgICAgICAgIDxzZWN0 aW9uIHRpdGxlPSdJbnZhbGlkIEVuZHBvaW50Jz4KICAgICAgICAgICAgPHQ+CiAgICAgICAgICAg ICAgSWYgYW4gYXV0aG9yaXphdGlvbiByZXF1ZXN0IGZhaWxzIHZhbGlkYXRpb24gZHVlIHRvIGEg bWlzc2luZywgaW52YWxpZCwgb3IKICAgICAgICAgICAgICBtaXNtYXRjaGluZyByZWRpcmVjdGlv biBVUkksIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBTSE9VTEQgaW5mb3JtIHRoZSByZXNvdXJj ZQogICAgICAgICAgICAgIG93bmVyIG9mIHRoZSBlcnJvciwgYW5kIE1VU1QgTk9UIGF1dG9tYXRp Y2FsbHkgcmVkaXJlY3QgdGhlIHVzZXItYWdlbnQgdG8gdGhlIGludmFsaWQKICAgICAgICAgICAg ICByZWRpcmVjdGlvbiBVUkkuCiAgICAgICAgICAgIDwvdD4KICAgICAgICAgIDwvc2VjdGlvbj4K CiAgICAgICAgICA8c2VjdGlvbiB0aXRsZT0nRW5kcG9pbnQgQ29udGVudCc+CiAgICAgICAgICAg IDx0PgogICAgICAgICAgICAgIFRoZSByZWRpcmVjdGlvbiByZXF1ZXN0IHRvIHRoZSBjbGllbnQn cyBlbmRwb2ludCB0eXBpY2FsbHkgcmVzdWx0cyBpbiBhbiBIVE1MCiAgICAgICAgICAgICAgZG9j dW1lbnQgcmVzcG9uc2UsIHByb2Nlc3NlZCBieSB0aGUgdXNlci1hZ2VudC4gSWYgdGhlIEhUTUwg cmVzcG9uc2UgaXMgc2VydmVkCiAgICAgICAgICAgICAgZGlyZWN0bHkgYXMgdGhlIHJlc3VsdCBv ZiB0aGUgcmVkaXJlY3Rpb24gcmVxdWVzdCwgYW55IHNjcmlwdCBpbmNsdWRlZCBpbiB0aGUgSFRN TAogICAgICAgICAgICAgIGRvY3VtZW50IHdpbGwgZXhlY3V0ZSB3aXRoIGZ1bGwgYWNjZXNzIHRv IHRoZSByZWRpcmVjdGlvbiBVUkkgYW5kIHRoZSBjcmVkZW50aWFscyBpdAogICAgICAgICAgICAg IGNvbnRhaW5zLgogICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgIDx0PgogICAgICAgICAgICAg IFRoZSBjbGllbnQgU0hPVUxEIE5PVCBpbmNsdWRlIGFueSB0aGlyZC1wYXJ0eSBzY3JpcHRzIChl LmcuIHRoaXJkLXBhcnR5IGFuYWx5dGljcywKICAgICAgICAgICAgICBzb2NpYWwgcGx1Zy1pbnMs IGFkIG5ldHdvcmtzKSBpbiB0aGUgcmVkaXJlY3Rpb24gZW5kcG9pbnQgcmVzcG9uc2UuIEluc3Rl YWQsIGl0CiAgICAgICAgICAgICAgU0hPVUxEIGV4dHJhY3QgdGhlIGNyZWRlbnRpYWxzIGZyb20g dGhlIFVSSSBhbmQgcmVkaXJlY3QgdGhlIHVzZXItYWdlbnQgYWdhaW4gdG8KICAgICAgICAgICAg ICBhbm90aGVyIGVuZHBvaW50IHdpdGhvdXQgZXhwb3NpbmcgdGhlIGNyZWRlbnRpYWxzIChpbiB0 aGUgVVJJIG9yIGVsc2V3aGVyZSkuIElmCiAgICAgICAgICAgICAgdGhpcmQtcGFydHkgc2NyaXB0 cyBhcmUgaW5jbHVkZWQsIHRoZSBjbGllbnQgTVVTVCBlbnN1cmUgdGhhdCBpdHMgb3duIHNjcmlw dHMKICAgICAgICAgICAgICAodXNlZCB0byBleHRyYWN0IGFuZCByZW1vdmUgdGhlIGNyZWRlbnRp YWxzIGZyb20gdGhlIFVSSSkgd2lsbCBleGVjdXRlIGZpcnN0LgogICAgICAgICAgICA8L3Q+CiAg ICAgICAgICA8L3NlY3Rpb24+CiAgICAgICAgICAKICAgICAgICA8L3NlY3Rpb24+CgogICAgICA8 L3NlY3Rpb24+CgogICAgICA8c2VjdGlvbiB0aXRsZT0nVG9rZW4gRW5kcG9pbnQnPgogICAgICAg IDx0PgogICAgICAgICAgVGhlIHRva2VuIGVuZHBvaW50IGlzIHVzZWQgYnkgdGhlIGNsaWVudCB0 byBvYnRhaW4gYW4gYWNjZXNzIHRva2VuIGJ5IHByZXNlbnRpbmcgaXRzCiAgICAgICAgICBhdXRo b3JpemF0aW9uIGdyYW50IG9yIHJlZnJlc2ggdG9rZW4uIFRoZSB0b2tlbiBlbmRwb2ludCBpcyB1 c2VkIHdpdGggZXZlcnkgYXV0aG9yaXphdGlvbgogICAgICAgICAgZ3JhbnQgZXhjZXB0IGZvciB0 aGUgaW1wbGljaXQgZ3JhbnQgdHlwZSAoc2luY2UgYW4gYWNjZXNzIHRva2VuIGlzIGlzc3VlZCBk aXJlY3RseSkuCiAgICAgICAgPC90PgogICAgICAgIDx0PgogICAgICAgICAgVGhlIG1lYW5zIHRo cm91Z2ggd2hpY2ggdGhlIGNsaWVudCBvYnRhaW5zIHRoZSBsb2NhdGlvbiBvZiB0aGUgdG9rZW4g ZW5kcG9pbnQgYXJlCiAgICAgICAgICBiZXlvbmQgdGhlIHNjb3BlIG9mIHRoaXMgc3BlY2lmaWNh dGlvbiBidXQgaXMgdHlwaWNhbGx5IHByb3ZpZGVkIGluIHRoZSBzZXJ2aWNlCiAgICAgICAgICBk b2N1bWVudGF0aW9uLgogICAgICAgIDwvdD4KICAgICAgICA8dD4KICAgICAgICAgIFRoZSBlbmRw b2ludCBVUkkgTUFZIGluY2x1ZGUgYW4KICAgICAgICAgIDxzcGFueCBzdHlsZT0ndmVyYic+YXBw bGljYXRpb24veC13d3ctZm9ybS11cmxlbmNvZGVkPC9zcGFueD4gZm9ybWF0dGVkCiAgICAgICAg ICAoPHhyZWYgdGFyZ2V0PSdXM0MuUkVDLWh0bWw0MDEtMTk5OTEyMjQnIC8+KSBxdWVyeSBjb21w b25lbnQgKDx4cmVmIHRhcmdldD0nUkZDMzk4NicgLz4KICAgICAgICAgIHNlY3Rpb24gMy40KSwg d2hpY2ggTVVTVCBiZSByZXRhaW5lZCB3aGVuIGFkZGluZyBhZGRpdGlvbmFsIHF1ZXJ5IHBhcmFt ZXRlcnMuIFRoZQogICAgICAgICAgZW5kcG9pbnQgVVJJIE1VU1QgTk9UIGluY2x1ZGUgYSBmcmFn bWVudCBjb21wb25lbnQuCiAgICAgICAgPC90PgogICAgICAgIDx0PgogICAgICAgICAgU2luY2Ug cmVxdWVzdHMgdG8gdGhlIHRva2VuIGVuZHBvaW50IHJlc3VsdCBpbiB0aGUgdHJhbnNtaXNzaW9u IG9mIGNsZWFyLXRleHQgY3JlZGVudGlhbHMKICAgICAgICAgIChpbiB0aGUgSFRUUCByZXF1ZXN0 IGFuZCByZXNwb25zZSksIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBNVVNUIHJlcXVpcmUgdGhl IHVzZSBvZiBUTFMKICAgICAgICAgIGFzIGRlc2NyaWJlZCBpbiA8eHJlZiB0YXJnZXQ9J3Rscycg Lz4gd2hlbiBzZW5kaW5nIHJlcXVlc3RzIHRvIHRoZSB0b2tlbiBlbmRwb2ludC4KICAgICAgICA8 L3Q+CiAgICAgICAgPHQ+CiAgICAgICAgICBUaGUgY2xpZW50IE1VU1QgdXNlIHRoZSBIVFRQIDxz cGFueCBzdHlsZT0ndmVyYic+UE9TVDwvc3Bhbng+IG1ldGhvZCB3aGVuIG1ha2luZyBhY2Nlc3MK ICAgICAgICAgIHRva2VuIHJlcXVlc3RzLgogICAgICAgIDwvdD4KICAgICAgICA8dD4KICAgICAg ICAgIFBhcmFtZXRlcnMgc2VudCB3aXRob3V0IGEgdmFsdWUgTVVTVCBiZSB0cmVhdGVkIGFzIGlm IHRoZXkgd2VyZSBvbWl0dGVkIGZyb20gdGhlIHJlcXVlc3QuCiAgICAgICAgICBUaGUgYXV0aG9y aXphdGlvbiBzZXJ2ZXIgTVVTVCBpZ25vcmUgdW5yZWNvZ25pemVkIHJlcXVlc3QgcGFyYW1ldGVy cy4gUmVxdWVzdCBhbmQKICAgICAgICAgIHJlc3BvbnNlIHBhcmFtZXRlcnMgTVVTVCBOT1QgYmUg aW5jbHVkZWQgbW9yZSB0aGFuIG9uY2UuCiAgICAgICAgPC90PgoKICAgICAgICA8c2VjdGlvbiB0 aXRsZT0nQ2xpZW50IEF1dGhlbnRpY2F0aW9uJyBhbmNob3I9J3Rva2VuLWVuZHBvaW50LWF1dGgn PgogICAgICAgICAgPHQ+CiAgICAgICAgICAgIENvbmZpZGVudGlhbCBjbGllbnRzIG9yIG90aGVy IGNsaWVudHMgaXNzdWVkIGNsaWVudCBjcmVkZW50aWFscyBNVVNUIGF1dGhlbnRpY2F0ZSB3aXRo CiAgICAgICAgICAgIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBhcyBkZXNjcmliZWQgaW4gPHhy ZWYgdGFyZ2V0PSdjbGllbnQtYXV0aGVudGljYXRpb24nIC8+IHdoZW4KICAgICAgICAgICAgbWFr aW5nIHJlcXVlc3RzIHRvIHRoZSB0b2tlbiBlbmRwb2ludC4gQ2xpZW50IGF1dGhlbnRpY2F0aW9u IGlzIHVzZWQgZm9yOgogICAgICAgICAgPC90PgogICAgICAgICAgPHQ+CiAgICAgICAgICAgIDxs aXN0IHN0eWxlPSdzeW1ib2xzJz4KICAgICAgICAgICAgICA8dD4KICAgICAgICAgICAgICAgIEVu Zm9yY2luZyB0aGUgYmluZGluZyBvZiByZWZyZXNoIHRva2VucyBhbmQgYXV0aG9yaXphdGlvbiBj b2RlcyB0byB0aGUgY2xpZW50IHRoZXkKICAgICAgICAgICAgICAgIHdlcmUgaXNzdWVkIHRvLiBD bGllbnQgYXV0aGVudGljYXRpb24gaXMgY3JpdGljYWwgd2hlbiBhbiBhdXRob3JpemF0aW9uIGNv ZGUgaXMKICAgICAgICAgICAgICAgIHRyYW5zbWl0dGVkIHRvIHRoZSByZWRpcmVjdGlvbiBlbmRw b2ludCBvdmVyIGFuIGluc2VjdXJlIGNoYW5uZWwsIG9yIHdoZW4gdGhlCiAgICAgICAgICAgICAg ICByZWRpcmVjdGlvbiBVUkkgaGFzIG5vdCBiZWVuIHJlZ2lzdGVyZWQgaW4gZnVsbC4KICAgICAg ICAgICAgICA8L3Q+CiAgICAgICAgICAgICAgPHQ+CiAgICAgICAgICAgICAgICBSZWNvdmVyaW5n IGZyb20gYSBjb21wcm9taXNlZCBjbGllbnQgYnkgZGlzYWJsaW5nIHRoZSBjbGllbnQgb3IgY2hh bmdpbmcgaXRzCiAgICAgICAgICAgICAgICBjcmVkZW50aWFscywgdGh1cyBwcmV2ZW50aW5nIGFu IGF0dGFja2VyIGZyb20gYWJ1c2luZyBzdG9sZW4gcmVmcmVzaCB0b2tlbnMuIENoYW5naW5nCiAg ICAgICAgICAgICAgICBhIHNpbmdsZSBzZXQgb2YgY2xpZW50IGNyZWRlbnRpYWxzIGlzIHNpZ25p ZmljYW50bHkgZmFzdGVyIHRoYW4gcmV2b2tpbmcgYW4gZW50aXJlCiAgICAgICAgICAgICAgICBz ZXQgb2YgcmVmcmVzaCB0b2tlbnMuCiAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICAgIDx0 PgogICAgICAgICAgICAgICAgSW1wbGVtZW50aW5nIGF1dGhlbnRpY2F0aW9uIG1hbmFnZW1lbnQg YmVzdCBwcmFjdGljZXMgd2hpY2ggcmVxdWlyZSBwZXJpb2RpYwogICAgICAgICAgICAgICAgY3Jl ZGVudGlhbCByb3RhdGlvbi4gUm90YXRpb24gb2YgYW4gZW50aXJlIHNldCBvZiByZWZyZXNoIHRv a2VucyBjYW4gYmUKICAgICAgICAgICAgICAgIGNoYWxsZW5naW5nLCB3aGlsZSByb3RhdGlvbiBv ZiBhIHNpbmdsZSBzZXQgb2YgY2xpZW50IGNyZWRlbnRpYWxzIGlzIHNpZ25pZmljYW50bHkKICAg ICAgICAgICAgICAgIGVhc2llci4KICAgICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgIDwvbGlz dD4KICAgICAgICAgIDwvdD4KICAgICAgICAgIDx0PgogICAgICAgICAgICBBIHB1YmxpYyBjbGll bnQgdGhhdCB3YXMgbm90IGlzc3VlZCBhIGNsaWVudCBwYXNzd29yZCBNQVkgdXNlIHRoZQogICAg ICAgICAgICA8c3Bhbnggc3R5bGU9J3ZlcmInPmNsaWVudF9pZDwvc3Bhbng+IHJlcXVlc3QgcGFy YW1ldGVyIHRvIGlkZW50aWZ5IGl0c2VsZiB3aGVuIHNlbmRpbmcKICAgICAgICAgICAgcmVxdWVz dHMgdG8gdGhlIHRva2VuIGVuZHBvaW50IChlLmcuIGZvciB0aGUgcHVycG9zZSBvZiBwcm92aWRp bmcgZW5kLXVzZXIgY29udGV4dCwKICAgICAgICAgICAgY2xpZW50IHVzYWdlIHN0YXRpc3RpY3Mp LgogICAgICAgICAgPC90PgogICAgICAgIDwvc2VjdGlvbj4KCiAgICAgIDwvc2VjdGlvbj4KCiAg ICAgIDxzZWN0aW9uIHRpdGxlPSdBY2Nlc3MgVG9rZW4gU2NvcGUnIGFuY2hvcj0nc2NvcGUnPgog ICAgICAgIDx0PgogICAgICAgICAgVGhlIGF1dGhvcml6YXRpb24gYW5kIHRva2VuIGVuZHBvaW50 cyBhbGxvdyB0aGUgY2xpZW50IHRvIHNwZWNpZnkgdGhlIHNjb3BlIG9mIHRoZSBhY2Nlc3MKICAg ICAgICAgIHJlcXVlc3QgdXNpbmcgdGhlIDxzcGFueCBzdHlsZT0ndmVyYic+c2NvcGU8L3NwYW54 PiByZXF1ZXN0IHBhcmFtZXRlci4gSW4gdHVybiwgdGhlCiAgICAgICAgICBhdXRob3JpemF0aW9u IHNlcnZlciB1c2VzIHRoZSA8c3Bhbnggc3R5bGU9J3ZlcmInPnNjb3BlPC9zcGFueD4gcmVzcG9u c2UgcGFyYW1ldGVyIHRvCiAgICAgICAgICBpbmZvcm0gdGhlIGNsaWVudCBvZiB0aGUgc2NvcGUg b2YgdGhlIGFjY2VzcyB0b2tlbiBpc3N1ZWQuCiAgICAgICAgPC90PgogICAgICAgIDx0PgogICAg ICAgICAgVGhlIHZhbHVlIG9mIHRoZSBzY29wZSBwYXJhbWV0ZXIgaXMgZXhwcmVzc2VkIGFzIGEg bGlzdCBvZiBzcGFjZS1kZWxpbWl0ZWQsIGNhc2UKICAgICAgICAgIHNlbnNpdGl2ZSBzdHJpbmdz LiBUaGUgc3RyaW5ncyBhcmUgZGVmaW5lZCBieSB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIuIElm IHRoZSB2YWx1ZQogICAgICAgICAgY29udGFpbnMgbXVsdGlwbGUgc3BhY2UtZGVsaW1pdGVkIHN0 cmluZ3MsIHRoZWlyIG9yZGVyIGRvZXMgbm90IG1hdHRlciwgYW5kIGVhY2ggc3RyaW5nCiAgICAg ICAgICBhZGRzIGFuIGFkZGl0aW9uYWwgYWNjZXNzIHJhbmdlIHRvIHRoZSByZXF1ZXN0ZWQgc2Nv cGUuCiAgICAgICAgPC90PgogICAgICAgIDxmaWd1cmU+CiAgICAgICAgICA8YXJ0d29yaz4KICAg ICAgICAgICAgPCFbQ0RBVEFbCiAgc2NvcGUgICAgICAgPSBzY29wZS10b2tlbiAqKCBTUCBzY29w ZS10b2tlbiApCiAgc2NvcGUtdG9rZW4gPSAxKiggJXgyMSAvICV4MjMtNUIgLyAleDVELTdFICkK XV0+CiAgICAgICAgICA8L2FydHdvcms+CiAgICAgICAgPC9maWd1cmU+CiAgICAgICAgPHQ+CiAg ICAgICAgICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTUFZIGZ1bGx5IG9yIHBhcnRpYWxseSBp Z25vcmUgdGhlIHNjb3BlIHJlcXVlc3RlZCBieSB0aGUgY2xpZW50CiAgICAgICAgICBiYXNlZCBv biB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgcG9saWN5IG9yIHRoZSByZXNvdXJjZSBvd25lcidz IGluc3RydWN0aW9ucy4gSWYgdGhlCiAgICAgICAgICBpc3N1ZWQgYWNjZXNzIHRva2VuIHNjb3Bl IGlzIGRpZmZlcmVudCBmcm9tIHRoZSBvbmUgcmVxdWVzdGVkIGJ5IHRoZSBjbGllbnQsIHRoZQog ICAgICAgICAgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVTVCBpbmNsdWRlIHRoZSA8c3Bhbnggc3R5 bGU9J3ZlcmInPnNjb3BlPC9zcGFueD4gcmVzcG9uc2UKICAgICAgICAgIHBhcmFtZXRlciB0byBp bmZvcm0gdGhlIGNsaWVudCBvZiB0aGUgYWN0dWFsIHNjb3BlIGdyYW50ZWQuCiAgICAgICAgPC90 PgogICAgICAgIDx0PgogICAgICAgICAgSWYgdGhlIGNsaWVudCBvbWl0cyB0aGUgc2NvcGUgcGFy YW1ldGVyIHdoZW4gcmVxdWVzdGluZyBhdXRob3JpemF0aW9uLCB0aGUgYXV0aG9yaXphdGlvbgog ICAgICAgICAgc2VydmVyIE1VU1QgZWl0aGVyIHByb2Nlc3MgdGhlIHJlcXVlc3QgdXNpbmcgYSBw cmUtZGVmaW5lZCBkZWZhdWx0IHZhbHVlLCBvciBmYWlsIHRoZQogICAgICAgICAgcmVxdWVzdCBp bmRpY2F0aW5nIGFuIGludmFsaWQgc2NvcGUuIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBTSE9V TEQgZG9jdW1lbnQgaXRzIHNjb3BlCiAgICAgICAgICByZXF1aXJlbWVudHMgYW5kIGRlZmF1bHQg dmFsdWUgKGlmIGRlZmluZWQpLgogICAgICAgIDwvdD4KICAgICAgPC9zZWN0aW9uPgoKICAgIDwv c2VjdGlvbj4KCiAgICA8c2VjdGlvbiB0aXRsZT0nT2J0YWluaW5nIEF1dGhvcml6YXRpb24nPgog ICAgICA8dD4KICAgICAgICBUbyByZXF1ZXN0IGFuIGFjY2VzcyB0b2tlbiwgdGhlIGNsaWVudCBv YnRhaW5zIGF1dGhvcml6YXRpb24gZnJvbSB0aGUgcmVzb3VyY2Ugb3duZXIuIFRoZQogICAgICAg IGF1dGhvcml6YXRpb24gaXMgZXhwcmVzc2VkIGluIHRoZSBmb3JtIG9mIGFuIGF1dGhvcml6YXRp b24gZ3JhbnQgd2hpY2ggdGhlIGNsaWVudCB1c2VzIHRvCiAgICAgICAgcmVxdWVzdCB0aGUgYWNj ZXNzIHRva2VuLiBPQXV0aCBkZWZpbmVzIGZvdXIgZ3JhbnQgdHlwZXM6IGF1dGhvcml6YXRpb24g Y29kZSwgaW1wbGljaXQsCiAgICAgICAgcmVzb3VyY2Ugb3duZXIgcGFzc3dvcmQgY3JlZGVudGlh bHMsIGFuZCBjbGllbnQgY3JlZGVudGlhbHMuIEl0IGFsc28gcHJvdmlkZXMgYW4gZXh0ZW5zaW9u CiAgICAgICAgbWVjaGFuaXNtIGZvciBkZWZpbmluZyBhZGRpdGlvbmFsIGdyYW50IHR5cGVzLgog ICAgICA8L3Q+CgogICAgICA8c2VjdGlvbiB0aXRsZT0nQXV0aG9yaXphdGlvbiBDb2RlIEdyYW50 JyBhbmNob3I9J2dyYW50LWNvZGUnPgogICAgICAgIDx0PgogICAgICAgICAgVGhlIGF1dGhvcml6 YXRpb24gY29kZSBncmFudCB0eXBlIGlzIHVzZWQgdG8gb2J0YWluIGJvdGggYWNjZXNzIHRva2Vu cyBhbmQgcmVmcmVzaAogICAgICAgICAgdG9rZW5zIGFuZCBpcyBvcHRpbWl6ZWQgZm9yIGNvbmZp ZGVudGlhbCBjbGllbnRzLiBBcyBhIHJlZGlyZWN0aW9uLWJhc2VkIGZsb3csIHRoZSBjbGllbnQK ICAgICAgICAgIG11c3QgYmUgY2FwYWJsZSBvZiBpbnRlcmFjdGluZyB3aXRoIHRoZSByZXNvdXJj ZSBvd25lcidzIHVzZXItYWdlbnQgKHR5cGljYWxseSBhIHdlYgogICAgICAgICAgYnJvd3Nlcikg YW5kIGNhcGFibGUgb2YgcmVjZWl2aW5nIGluY29taW5nIHJlcXVlc3RzICh2aWEgcmVkaXJlY3Rp b24pIGZyb20gdGhlCiAgICAgICAgICBhdXRob3JpemF0aW9uIHNlcnZlci4KICAgICAgICA8L3Q+ CiAgICAgICAgPGZpZ3VyZSB0aXRsZT0nQXV0aG9yaXphdGlvbiBDb2RlIEZsb3cnIGFuY2hvcj0n RmlndXJlLTMnPgogICAgICAgICAgPGFydHdvcms+CiAgICAgICAgICAgIDwhW0NEQVRBWwogICst LS0tLS0tLS0tKwogIHwgcmVzb3VyY2UgfAogIHwgICBvd25lciAgfAogIHwgICAgICAgICAgfAog ICstLS0tLS0tLS0tKwogICAgICAgXgogICAgICAgfAogICAgICAoQikgICAgICAKICArLS0tLXwt LS0tLSsgICAgICAgICAgQ2xpZW50IElkZW50aWZpZXIgICAgICArLS0tLS0tLS0tLS0tLS0tKwog IHwgICAgICAgICAtKy0tLS0oQSktLSAmIFJlZGlyZWN0aW9uIFVSSSAtLS0tPnwgICAgICAgICAg ICAgICB8CiAgfCAgVXNlci0gICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCBB dXRob3JpemF0aW9uIHwKICB8ICBBZ2VudCAgLSstLS0tKEIpLS0gVXNlciBhdXRoZW50aWNhdGVz IC0tLT58ICAgICBTZXJ2ZXIgICAgfAogIHwgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHwgICAgICAgICAgICAgICB8CiAgfCAgICAgICAgIC0rLS0tLShDKS0tIEF1 dGhvcml6YXRpb24gQ29kZSAtLS08fCAgICAgICAgICAgICAgIHwKICArLXwtLS0tfC0tLSsgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tKwogICAgfCAgICB8 ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBeICAgICAgdgogICAoQSkg IChDKSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgfAogICAg fCAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgfAog ICAgXiAgICB2ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAg fAogICstLS0tLS0tLS0rICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAg ICAgfAogIHwgICAgICAgICB8Pi0tLShEKS0tIEF1dGhvcml6YXRpb24gQ29kZSAtLS0tLS0tLS0n ICAgICAgfAogIHwgIENsaWVudCB8ICAgICAgICAgICYgUmVkaXJlY3Rpb24gVVJJICAgICAgICAg ICAgICAgICAgfAogIHwgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgfAogIHwgICAgICAgICB8PC0tLShFKS0tLS0tIEFjY2VzcyBUb2tlbiAtLS0t LS0tLS0tLS0tLS0tLS0tJwogICstLS0tLS0tLS0rICAgICAgICh3LyBPcHRpb25hbCBSZWZyZXNo IFRva2VuKQpdXT4KICAgICAgICAgIDwvYXJ0d29yaz4KICAgICAgICAgIDxwb3N0YW1ibGU+CiAg ICAgICAgICAgIE5vdGU6IFRoZSBsaW5lcyBpbGx1c3RyYXRpbmcgc3RlcHMgQSwgQiwgYW5kIEMg YXJlIGJyb2tlbiBpbnRvIHR3byBwYXJ0cyBhcyB0aGV5IHBhc3MKICAgICAgICAgICAgdGhyb3Vn aCB0aGUgdXNlci1hZ2VudC4KICAgICAgICAgIDwvcG9zdGFtYmxlPgogICAgICAgIDwvZmlndXJl PgogICAgICAgIDx0PgogICAgICAgICAgVGhlIGZsb3cgaWxsdXN0cmF0ZWQgaW4gPHhyZWYgdGFy Z2V0PSdGaWd1cmUtMycgLz4gaW5jbHVkZXMgdGhlIGZvbGxvd2luZyBzdGVwczoKICAgICAgICA8 L3Q+CiAgICAgICAgPHQ+CiAgICAgICAgICA8bGlzdCBzdHlsZT0nZm9ybWF0ICglQyknPgogICAg ICAgICAgICA8dD4KICAgICAgICAgICAgICBUaGUgY2xpZW50IGluaXRpYXRlcyB0aGUgZmxvdyBi eSBkaXJlY3RpbmcgdGhlIHJlc291cmNlIG93bmVyJ3MgdXNlci1hZ2VudCB0byB0aGUKICAgICAg ICAgICAgICBhdXRob3JpemF0aW9uIGVuZHBvaW50LiBUaGUgY2xpZW50IGluY2x1ZGVzIGl0cyBj bGllbnQgaWRlbnRpZmllciwgcmVxdWVzdGVkCiAgICAgICAgICAgICAgc2NvcGUsIGxvY2FsIHN0 YXRlLCBhbmQgYSByZWRpcmVjdGlvbiBVUkkgdG8gd2hpY2ggdGhlIGF1dGhvcml6YXRpb24gc2Vy dmVyIHdpbGwgc2VuZAogICAgICAgICAgICAgIHRoZSB1c2VyLWFnZW50IGJhY2sgb25jZSBhY2Nl c3MgaXMgZ3JhbnRlZCAob3IgZGVuaWVkKS4KICAgICAgICAgICAgPC90PgogICAgICAgICAgICA8 dD4KICAgICAgICAgICAgICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYXV0aGVudGljYXRlcyB0 aGUgcmVzb3VyY2Ugb3duZXIgKHZpYSB0aGUgdXNlci1hZ2VudCkgYW5kCiAgICAgICAgICAgICAg ZXN0YWJsaXNoZXMgd2hldGhlciB0aGUgcmVzb3VyY2Ugb3duZXIgZ3JhbnRzIG9yIGRlbmllcyB0 aGUgY2xpZW50J3MgYWNjZXNzIHJlcXVlc3QuCiAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAg PHQ+CiAgICAgICAgICAgICAgQXNzdW1pbmcgdGhlIHJlc291cmNlIG93bmVyIGdyYW50cyBhY2Nl c3MsIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciByZWRpcmVjdHMgdGhlCiAgICAgICAgICAgICAg dXNlci1hZ2VudCBiYWNrIHRvIHRoZSBjbGllbnQgdXNpbmcgdGhlIHJlZGlyZWN0aW9uIFVSSSBw cm92aWRlZCBlYXJsaWVyIChpbiB0aGUKICAgICAgICAgICAgICByZXF1ZXN0IG9yIGR1cmluZyBj bGllbnQgcmVnaXN0cmF0aW9uKS4gVGhlIHJlZGlyZWN0aW9uIFVSSSBpbmNsdWRlcyBhbiBhdXRo b3JpemF0aW9uCiAgICAgICAgICAgICAgY29kZSBhbmQgYW55IGxvY2FsIHN0YXRlIHByb3ZpZGVk IGJ5IHRoZSBjbGllbnQgZWFybGllci4KICAgICAgICAgICAgPC90PgogICAgICAgICAgICA8dD4K ICAgICAgICAgICAgICBUaGUgY2xpZW50IHJlcXVlc3RzIGFuIGFjY2VzcyB0b2tlbiBmcm9tIHRo ZSBhdXRob3JpemF0aW9uIHNlcnZlcidzIHRva2VuIGVuZHBvaW50CiAgICAgICAgICAgICAgYnkg aW5jbHVkaW5nIHRoZSBhdXRob3JpemF0aW9uIGNvZGUgcmVjZWl2ZWQgaW4gdGhlIHByZXZpb3Vz IHN0ZXAuIFdoZW4gbWFraW5nIHRoZQogICAgICAgICAgICAgIHJlcXVlc3QsIHRoZSBjbGllbnQg YXV0aGVudGljYXRlcyB3aXRoIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlci4gVGhlIGNsaWVudCBp bmNsdWRlcwogICAgICAgICAgICAgIHRoZSByZWRpcmVjdGlvbiBVUkkgdXNlZCB0byBvYnRhaW4g dGhlIGF1dGhvcml6YXRpb24gY29kZSBmb3IgdmVyaWZpY2F0aW9uLgogICAgICAgICAgICA8L3Q+ CiAgICAgICAgICAgIDx0PgogICAgICAgICAgICAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBh dXRoZW50aWNhdGVzIHRoZSBjbGllbnQsIHZhbGlkYXRlcyB0aGUgYXV0aG9yaXphdGlvbiBjb2Rl LAogICAgICAgICAgICAgIGFuZCBlbnN1cmVzIHRoZSByZWRpcmVjdGlvbiBVUkkgcmVjZWl2ZWQg bWF0Y2hlcyB0aGUgVVJJIHVzZWQgdG8gcmVkaXJlY3QgdGhlIGNsaWVudAogICAgICAgICAgICAg IGluIHN0ZXAgKEMpLiBJZiB2YWxpZCwgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHJlc3BvbmRz IGJhY2sgd2l0aCBhbiBhY2Nlc3MgdG9rZW4KICAgICAgICAgICAgICBhbmQgb3B0aW9uYWxseSwg YSByZWZyZXNoIHRva2VuLgogICAgICAgICAgICA8L3Q+CiAgICAgICAgICA8L2xpc3Q+CiAgICAg ICAgPC90PgoKICAgICAgICA8c2VjdGlvbiB0aXRsZT0nQXV0aG9yaXphdGlvbiBSZXF1ZXN0JyBh bmNob3I9J2NvZGUtYXV0aHotcmVxJz4KICAgICAgICAgIDx0PgogICAgICAgICAgICBUaGUgY2xp ZW50IGNvbnN0cnVjdHMgdGhlIHJlcXVlc3QgVVJJIGJ5IGFkZGluZyB0aGUgZm9sbG93aW5nIHBh cmFtZXRlcnMgdG8gdGhlCiAgICAgICAgICAgIHF1ZXJ5IGNvbXBvbmVudCBvZiB0aGUgYXV0aG9y aXphdGlvbiBlbmRwb2ludCBVUkkgdXNpbmcgdGhlCiAgICAgICAgICAgIDxzcGFueCBzdHlsZT0n dmVyYic+YXBwbGljYXRpb24veC13d3ctZm9ybS11cmxlbmNvZGVkPC9zcGFueD4gZm9ybWF0IGFz IGRlZmluZWQgYnkKICAgICAgICAgICAgPHhyZWYgdGFyZ2V0PSdXM0MuUkVDLWh0bWw0MDEtMTk5 OTEyMjQnIC8+OgogICAgICAgICAgPC90PgogICAgICAgICAgPHQ+CiAgICAgICAgICAgIDxsaXN0 IHN0eWxlPSdoYW5naW5nJyBoYW5nSW5kZW50PSc2Jz4KICAgICAgICAgICAgICA8dCBoYW5nVGV4 dD0ncmVzcG9uc2VfdHlwZSc+CiAgICAgICAgICAgICAgICA8dnNwYWNlIC8+CiAgICAgICAgICAg ICAgICBSRVFVSVJFRC4gVmFsdWUgTVVTVCBiZSBzZXQgdG8gPHNwYW54IHN0eWxlPSd2ZXJiJz5j b2RlPC9zcGFueD4uCiAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICAgIDx0IGhhbmdUZXh0 PSdjbGllbnRfaWQnPgogICAgICAgICAgICAgICAgPHZzcGFjZSAvPgogICAgICAgICAgICAgICAg UkVRVUlSRUQuIFRoZSBjbGllbnQgaWRlbnRpZmllciBhcyBkZXNjcmliZWQgaW4KICAgICAgICAg ICAgICAgIDx4cmVmIHRhcmdldD0nY2xpZW50LWlkZW50aWZpZXInIC8+LgogICAgICAgICAgICAg IDwvdD4KICAgICAgICAgICAgICA8dCBoYW5nVGV4dD0ncmVkaXJlY3RfdXJpJz4KICAgICAgICAg ICAgICAgIDx2c3BhY2UgLz4KICAgICAgICAgICAgICAgIE9QVElPTkFMLiBBcyBkZXNjcmliZWQg aW4gPHhyZWYgdGFyZ2V0PSdyZWRpcmVjdC11cmknIC8+LgogICAgICAgICAgICAgIDwvdD4KICAg ICAgICAgICAgICA8dCBoYW5nVGV4dD0nc2NvcGUnPgogICAgICAgICAgICAgICAgPHZzcGFjZSAv PgogICAgICAgICAgICAgICAgT1BUSU9OQUwuIFRoZSBzY29wZSBvZiB0aGUgYWNjZXNzIHJlcXVl c3QgYXMgZGVzY3JpYmVkIGJ5IDx4cmVmIHRhcmdldD0nc2NvcGUnIC8+LgogICAgICAgICAgICAg IDwvdD4KICAgICAgICAgICAgICA8dCBoYW5nVGV4dD0nc3RhdGUnPgogICAgICAgICAgICAgICAg PHZzcGFjZSAvPgogICAgICAgICAgICAgICAgUkVDT01NRU5ERUQuIEFuIG9wYXF1ZSB2YWx1ZSB1 c2VkIGJ5IHRoZSBjbGllbnQgdG8gbWFpbnRhaW4gc3RhdGUgYmV0d2VlbiB0aGUgcmVxdWVzdAog ICAgICAgICAgICAgICAgYW5kIGNhbGxiYWNrLiBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgaW5j bHVkZXMgdGhpcyB2YWx1ZSB3aGVuIHJlZGlyZWN0aW5nIHRoZQogICAgICAgICAgICAgICAgdXNl ci1hZ2VudCBiYWNrIHRvIHRoZSBjbGllbnQuIFRoZSBwYXJhbWV0ZXIgU0hPVUxEIGJlIHVzZWQg Zm9yIHByZXZlbnRpbmcKICAgICAgICAgICAgICAgIGNyb3NzLXNpdGUgcmVxdWVzdCBmb3JnZXJ5 IGFzIGRlc2NyaWJlZCBpbiA8eHJlZiB0YXJnZXQ9J0NTUkYnIC8+LgogICAgICAgICAgICAgIDwv dD4KICAgICAgICAgICAgPC9saXN0PgogICAgICAgICAgPC90PgogICAgICAgICAgPHQ+CiAgICAg ICAgICAgIFRoZSBjbGllbnQgZGlyZWN0cyB0aGUgcmVzb3VyY2Ugb3duZXIgdG8gdGhlIGNvbnN0 cnVjdGVkIFVSSSB1c2luZyBhbiBIVFRQIHJlZGlyZWN0aW9uCiAgICAgICAgICAgIHJlc3BvbnNl LCBvciBieSBvdGhlciBtZWFucyBhdmFpbGFibGUgdG8gaXQgdmlhIHRoZSB1c2VyLWFnZW50Lgog ICAgICAgICAgPC90PgogICAgICAgICAgPGZpZ3VyZT4KICAgICAgICAgICAgPHByZWFtYmxlPgog ICAgICAgICAgICAgIEZvciBleGFtcGxlLCB0aGUgY2xpZW50IGRpcmVjdHMgdGhlIHVzZXItYWdl bnQgdG8gbWFrZSB0aGUgZm9sbG93aW5nIEhUVFAgcmVxdWVzdAogICAgICAgICAgICAgIHVzaW5n IFRMUyAoZXh0cmEgbGluZSBicmVha3MgYXJlIGZvciBkaXNwbGF5IHB1cnBvc2VzIG9ubHkpOgog ICAgICAgICAgICA8L3ByZWFtYmxlPgogICAgICAgICAgICA8YXJ0d29yaz4KICAgICAgICAgICAg ICA8IVtDREFUQVsKICBHRVQgL2F1dGhvcml6ZT9yZXNwb25zZV90eXBlPWNvZGUmY2xpZW50X2lk PXM2QmhkUmtxdDMmc3RhdGU9eHl6CiAgICAgICZyZWRpcmVjdF91cmk9aHR0cHMlM0ElMkYlMkZj bGllbnQlMkVleGFtcGxlJTJFY29tJTJGY2IgSFRUUC8xLjEKICBIb3N0OiBzZXJ2ZXIuZXhhbXBs ZS5jb20KXV0+CiAgICAgICAgICAgIDwvYXJ0d29yaz4KICAgICAgICAgIDwvZmlndXJlPgogICAg ICAgICAgPHQ+CiAgICAgICAgICAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciB2YWxpZGF0ZXMg dGhlIHJlcXVlc3QgdG8gZW5zdXJlIGFsbCByZXF1aXJlZCBwYXJhbWV0ZXJzIGFyZQogICAgICAg ICAgICBwcmVzZW50IGFuZCB2YWxpZC4gSWYgdGhlIHJlcXVlc3QgaXMgdmFsaWQsIHRoZSBhdXRo b3JpemF0aW9uIHNlcnZlciBhdXRoZW50aWNhdGVzIHRoZQogICAgICAgICAgICByZXNvdXJjZSBv d25lciBhbmQgb2J0YWlucyBhbiBhdXRob3JpemF0aW9uIGRlY2lzaW9uIChieSBhc2tpbmcgdGhl IHJlc291cmNlIG93bmVyIG9yCiAgICAgICAgICAgIGJ5IGVzdGFibGlzaGluZyBhcHByb3ZhbCB2 aWEgb3RoZXIgbWVhbnMpLgogICAgICAgICAgPC90PgogICAgICAgICAgPHQ+CiAgICAgICAgICAg IFdoZW4gYSBkZWNpc2lvbiBpcyBlc3RhYmxpc2hlZCwgdGhlIGF1dGhvcml6YXRpb24gc2VydmVy IGRpcmVjdHMgdGhlIHVzZXItYWdlbnQgdG8gdGhlCiAgICAgICAgICAgIHByb3ZpZGVkIGNsaWVu dCByZWRpcmVjdGlvbiBVUkkgdXNpbmcgYW4gSFRUUCByZWRpcmVjdGlvbiByZXNwb25zZSwgb3Ig Ynkgb3RoZXIgbWVhbnMKICAgICAgICAgICAgYXZhaWxhYmxlIHRvIGl0IHZpYSB0aGUgdXNlci1h Z2VudC4KICAgICAgICAgIDwvdD4KICAgICAgICA8L3NlY3Rpb24+CgogICAgICAgIDxzZWN0aW9u IHRpdGxlPSdBdXRob3JpemF0aW9uIFJlc3BvbnNlJyBhbmNob3I9ImNvZGUtYXV0aHotcmVzcCI+ CiAgICAgICAgICA8dD4KICAgICAgICAgICAgSWYgdGhlIHJlc291cmNlIG93bmVyIGdyYW50cyB0 aGUgYWNjZXNzIHJlcXVlc3QsIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBpc3N1ZXMgYW4KICAg ICAgICAgICAgYXV0aG9yaXphdGlvbiBjb2RlIGFuZCBkZWxpdmVycyBpdCB0byB0aGUgY2xpZW50 IGJ5IGFkZGluZyB0aGUgZm9sbG93aW5nIHBhcmFtZXRlcnMgdG8KICAgICAgICAgICAgdGhlIHF1 ZXJ5IGNvbXBvbmVudCBvZiB0aGUgcmVkaXJlY3Rpb24gVVJJIHVzaW5nIHRoZQogICAgICAgICAg ICA8c3Bhbnggc3R5bGU9J3ZlcmInPmFwcGxpY2F0aW9uL3gtd3d3LWZvcm0tdXJsZW5jb2RlZDwv c3Bhbng+IGZvcm1hdDoKICAgICAgICAgIDwvdD4KICAgICAgICAgIDx0PgogICAgICAgICAgICA8 bGlzdCBzdHlsZT0naGFuZ2luZycgaGFuZ0luZGVudD0nNic+CiAgICAgICAgICAgICAgPHQgaGFu Z1RleHQ9J2NvZGUnPgogICAgICAgICAgICAgICAgPHZzcGFjZSAvPgogICAgICAgICAgICAgICAg UkVRVUlSRUQuIFRoZSBhdXRob3JpemF0aW9uIGNvZGUgZ2VuZXJhdGVkIGJ5IHRoZSBhdXRob3Jp emF0aW9uIHNlcnZlci4gVGhlCiAgICAgICAgICAgICAgICBhdXRob3JpemF0aW9uIGNvZGUgTVVT VCBleHBpcmUgc2hvcnRseSBhZnRlciBpdCBpcyBpc3N1ZWQgdG8gbWl0aWdhdGUgdGhlIHJpc2sg b2YKICAgICAgICAgICAgICAgIGxlYWtzLiBBIG1heGltdW0gYXV0aG9yaXphdGlvbiBjb2RlIGxp ZmV0aW1lIG9mIDEwIG1pbnV0ZXMgaXMgUkVDT01NRU5ERUQuIFRoZQogICAgICAgICAgICAgICAg Y2xpZW50IE1VU1QgTk9UIHVzZSB0aGUgYXV0aG9yaXphdGlvbiBjb2RlIG1vcmUgdGhhbiBvbmNl LiBJZiBhbiBhdXRob3JpemF0aW9uIGNvZGUKICAgICAgICAgICAgICAgIGlzIHVzZWQgbW9yZSB0 aGFuIG9uY2UsIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBNVVNUIGRlbnkgdGhlIHJlcXVlc3Qg YW5kIFNIT1VMRAogICAgICAgICAgICAgICAgcmV2b2tlICh3aGVuIHBvc3NpYmxlKSBhbGwgdG9r ZW5zIHByZXZpb3VzbHkgaXNzdWVkIGJhc2VkIG9uIHRoYXQgYXV0aG9yaXphdGlvbgogICAgICAg ICAgICAgICAgY29kZS4gVGhlIGF1dGhvcml6YXRpb24gY29kZSBpcyBib3VuZCB0byB0aGUgY2xp ZW50IGlkZW50aWZpZXIgYW5kIHJlZGlyZWN0aW9uIFVSSS4KICAgICAgICAgICAgICA8L3Q+CiAg ICAgICAgICAgICAgPHQgaGFuZ1RleHQ9J3N0YXRlJz4KICAgICAgICAgICAgICAgIDx2c3BhY2Ug Lz4KICAgICAgICAgICAgICAgIFJFUVVJUkVEIGlmIHRoZSA8c3Bhbnggc3R5bGU9J3ZlcmInPnN0 YXRlPC9zcGFueD4gcGFyYW1ldGVyIHdhcyBwcmVzZW50IGluIHRoZQogICAgICAgICAgICAgICAg Y2xpZW50IGF1dGhvcml6YXRpb24gcmVxdWVzdC4gVGhlIGV4YWN0IHZhbHVlIHJlY2VpdmVkIGZy b20gdGhlIGNsaWVudC4KICAgICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgIDwvbGlzdD4KICAg ICAgICAgIDwvdD4KICAgICAgICAgIDxmaWd1cmU+CiAgICAgICAgICAgIDxwcmVhbWJsZT4KICAg ICAgICAgICAgICBGb3IgZXhhbXBsZSwgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHJlZGlyZWN0 cyB0aGUgdXNlci1hZ2VudCBieSBzZW5kaW5nIHRoZQogICAgICAgICAgICAgIGZvbGxvd2luZyBI VFRQIHJlc3BvbnNlOgogICAgICAgICAgICA8L3ByZWFtYmxlPgogICAgICAgICAgICA8YXJ0d29y az4KICAgICAgICAgICAgICA8IVtDREFUQVsKICBIVFRQLzEuMSAzMDIgRm91bmQKICBMb2NhdGlv bjogaHR0cHM6Ly9jbGllbnQuZXhhbXBsZS5jb20vY2I/Y29kZT1TcGx4bE9CZVpRUVliWVM2V3hT YklBCiAgICAgICAgICAgICZzdGF0ZT14eXoKXV0+CiAgICAgICAgICAgIDwvYXJ0d29yaz4KICAg ICAgICAgIDwvZmlndXJlPgogICAgICAgICAgPHQ+CiAgICAgICAgICAgIFRoZSBjbGllbnQgTVVT VCBpZ25vcmUgdW5yZWNvZ25pemVkIHJlc3BvbnNlIHBhcmFtZXRlcnMuIFRoZSBhdXRob3JpemF0 aW9uIGNvZGUKICAgICAgICAgICAgc3RyaW5nIHNpemUgaXMgbGVmdCB1bmRlZmluZWQgYnkgdGhp cyBzcGVjaWZpY2F0aW9uLiBUaGUgY2xpZW50IHNob3VsZCBhdm9pZCBtYWtpbmcKICAgICAgICAg ICAgYXNzdW1wdGlvbnMgYWJvdXQgY29kZSB2YWx1ZSBzaXplcy4gVGhlIGF1dGhvcml6YXRpb24g c2VydmVyIFNIT1VMRCBkb2N1bWVudCB0aGUgc2l6ZQogICAgICAgICAgICBvZiBhbnkgdmFsdWUg aXQgaXNzdWVzLgogICAgICAgICAgPC90PgoKICAgICAgICAgIDxzZWN0aW9uIHRpdGxlPSdFcnJv ciBSZXNwb25zZScgYW5jaG9yPSdjb2RlLWF1dGh6LWVycm9yJz4KICAgICAgICAgICAgPHQ+CiAg ICAgICAgICAgICAgSWYgdGhlIHJlcXVlc3QgZmFpbHMgZHVlIHRvIGEgbWlzc2luZywgaW52YWxp ZCwgb3IgbWlzbWF0Y2hpbmcgcmVkaXJlY3Rpb24gVVJJLCBvciBpZgogICAgICAgICAgICAgIHRo ZSBjbGllbnQgaWRlbnRpZmllciBpcyBtaXNzaW5nIG9yIGludmFsaWQsIHRoZSBhdXRob3JpemF0 aW9uIHNlcnZlciBTSE9VTEQgaW5mb3JtCiAgICAgICAgICAgICAgdGhlIHJlc291cmNlIG93bmVy IG9mIHRoZSBlcnJvciwgYW5kIE1VU1QgTk9UIGF1dG9tYXRpY2FsbHkgcmVkaXJlY3QgdGhlIHVz ZXItYWdlbnQKICAgICAgICAgICAgICB0byB0aGUgaW52YWxpZCByZWRpcmVjdGlvbiBVUkkuCiAg ICAgICAgICAgIDwvdD4KICAgICAgICAgICAgPHQ+CiAgICAgICAgICAgICAgSWYgdGhlIHJlc291 cmNlIG93bmVyIGRlbmllcyB0aGUgYWNjZXNzIHJlcXVlc3Qgb3IgaWYgdGhlIHJlcXVlc3QgZmFp bHMgZm9yIHJlYXNvbnMKICAgICAgICAgICAgICBvdGhlciB0aGFuIGEgbWlzc2luZyBvciBpbnZh bGlkIHJlZGlyZWN0aW9uIFVSSSwgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGluZm9ybXMgdGhl CiAgICAgICAgICAgICAgY2xpZW50IGJ5IGFkZGluZyB0aGUgZm9sbG93aW5nIHBhcmFtZXRlcnMg dG8gdGhlIHF1ZXJ5IGNvbXBvbmVudCBvZiB0aGUgcmVkaXJlY3Rpb24KICAgICAgICAgICAgICBV UkkgdXNpbmcgdGhlIDxzcGFueCBzdHlsZT0ndmVyYic+YXBwbGljYXRpb24veC13d3ctZm9ybS11 cmxlbmNvZGVkPC9zcGFueD4gZm9ybWF0OgogICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgIDx0 PgogICAgICAgICAgICAgIDxsaXN0IHN0eWxlPSdoYW5naW5nJyBoYW5nSW5kZW50PSc2Jz4KICAg ICAgICAgICAgICAgIDx0IGhhbmdUZXh0PSdlcnJvcic+CiAgICAgICAgICAgICAgICAgIDx2c3Bh Y2UgLz4KICAgICAgICAgICAgICAgICAgUkVRVUlSRUQuIEEgc2luZ2xlIEFTQ0lJIDx4cmVmIHRh cmdldD0iVVNBU0NJSSIgLz4gZXJyb3IgY29kZSBmcm9tIHRoZSBmb2xsb3dpbmc6CgogICAgICAg ICAgICAgICAgICA8bGlzdCBzdHlsZT0naGFuZ2luZycgaGFuZ0luZGVudD0nNic+CiAgICAgICAg ICAgICAgICAgICAgPHQgaGFuZ1RleHQ9J2ludmFsaWRfcmVxdWVzdCc+CiAgICAgICAgICAgICAg ICAgICAgICA8dnNwYWNlIC8+CiAgICAgICAgICAgICAgICAgICAgICBUaGUgcmVxdWVzdCBpcyBt aXNzaW5nIGEgcmVxdWlyZWQgcGFyYW1ldGVyLCBpbmNsdWRlcyBhbiBpbnZhbGlkCiAgICAgICAg ICAgICAgICAgICAgICBwYXJhbWV0ZXIgdmFsdWUsIGluY2x1ZGVzIGEgcGFyYW1ldGVyIG1vcmUg dGhhbiBvbmNlLCBvciBpcyBvdGhlcndpc2UKICAgICAgICAgICAgICAgICAgICAgIG1hbGZvcm1l ZC4KICAgICAgICAgICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgICAgICAgICAgPHQgaGFuZ1Rl eHQ9J3VuYXV0aG9yaXplZF9jbGllbnQnPgogICAgICAgICAgICAgICAgICAgICAgPHZzcGFjZSAv PgogICAgICAgICAgICAgICAgICAgICAgVGhlIGNsaWVudCBpcyBub3QgYXV0aG9yaXplZCB0byBy ZXF1ZXN0IGFuIGF1dGhvcml6YXRpb24gY29kZSB1c2luZyB0aGlzCiAgICAgICAgICAgICAgICAg ICAgICBtZXRob2QuCiAgICAgICAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICAgICAgICAg IDx0IGhhbmdUZXh0PSdhY2Nlc3NfZGVuaWVkJz4KICAgICAgICAgICAgICAgICAgICAgIDx2c3Bh Y2UgLz4KICAgICAgICAgICAgICAgICAgICAgIFRoZSByZXNvdXJjZSBvd25lciBvciBhdXRob3Jp emF0aW9uIHNlcnZlciBkZW5pZWQgdGhlIHJlcXVlc3QuCiAgICAgICAgICAgICAgICAgICAgPC90 PgogICAgICAgICAgICAgICAgICAgIDx0IGhhbmdUZXh0PSd1bnN1cHBvcnRlZF9yZXNwb25zZV90 eXBlJz4KICAgICAgICAgICAgICAgICAgICAgIDx2c3BhY2UgLz4KICAgICAgICAgICAgICAgICAg ICAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBkb2VzIG5vdCBzdXBwb3J0IG9idGFpbmluZyBh biBhdXRob3JpemF0aW9uIGNvZGUKICAgICAgICAgICAgICAgICAgICAgIHVzaW5nIHRoaXMgbWV0 aG9kLgogICAgICAgICAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAgICAgICAgICA8dCBoYW5n VGV4dD0naW52YWxpZF9zY29wZSc+CiAgICAgICAgICAgICAgICAgICAgICA8dnNwYWNlIC8+CiAg ICAgICAgICAgICAgICAgICAgICBUaGUgcmVxdWVzdGVkIHNjb3BlIGlzIGludmFsaWQsIHVua25v d24sIG9yIG1hbGZvcm1lZC4KICAgICAgICAgICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgICAg ICAgICAgPHQgaGFuZ1RleHQ9J3NlcnZlcl9lcnJvcic+CiAgICAgICAgICAgICAgICAgICAgICA8 dnNwYWNlIC8+CiAgICAgICAgICAgICAgICAgICAgICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIg ZW5jb3VudGVyZWQgYW4gdW5leHBlY3RlZCBjb25kaXRpb24gd2hpY2ggcHJldmVudGVkCiAgICAg ICAgICAgICAgICAgICAgICBpdCBmcm9tIGZ1bGZpbGxpbmcgdGhlIHJlcXVlc3QuCiAgICAgICAg ICAgICAgICAgICAgPC90PgogICAgICAgICAgICAgICAgICAgIDx0IGhhbmdUZXh0PSd0ZW1wb3Jh cmlseV91bmF2YWlsYWJsZSc+CiAgICAgICAgICAgICAgICAgICAgICA8dnNwYWNlIC8+CiAgICAg ICAgICAgICAgICAgICAgICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgaXMgY3VycmVudGx5IHVu YWJsZSB0byBoYW5kbGUgdGhlIHJlcXVlc3QgZHVlIHRvIGEKICAgICAgICAgICAgICAgICAgICAg IHRlbXBvcmFyeSBvdmVybG9hZGluZyBvciBtYWludGVuYW5jZSBvZiB0aGUgc2VydmVyLgogICAg ICAgICAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAgICAgICAgPC9saXN0PgoKCQkgIFZhbHVl cyBmb3IgdGhlIDxzcGFueCBzdHlsZT0ndmVyYic+ZXJyb3I8L3NwYW54PiBwYXJhbWV0ZXIgTVVT VCBOT1QgaW5jbHVkZQoJCSAgY2hhcmFjdGVycyBvdXRzaWRlIHRoZSBzZXQgJXgyMC0yMSAvICV4 MjMtNUIgLyAleDVELTdFLgogICAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICAgICAgPHQg aGFuZ1RleHQ9J2Vycm9yX2Rlc2NyaXB0aW9uJz4KICAgICAgICAgICAgICAgICAgPHZzcGFjZSAv PgogICAgICAgICAgICAgICAgICBPUFRJT05BTC4gQSBodW1hbi1yZWFkYWJsZSBBU0NJSSA8eHJl ZiB0YXJnZXQ9IlVTQVNDSUkiIC8+IHRleHQgcHJvdmlkaW5nIGFkZGl0aW9uYWwgaW5mb3JtYXRp b24sCiAgICAgICAgICAgICAgICAgIHVzZWQgdG8gYXNzaXN0IHRoZSBjbGllbnQgZGV2ZWxvcGVy IGluIHVuZGVyc3RhbmRpbmcgdGhlIGVycm9yIHRoYXQgb2NjdXJyZWQuCgkJICA8dnNwYWNlLz4K CQkgIFZhbHVlcyBmb3IgdGhlIDxzcGFueCBzdHlsZT0ndmVyYic+ZXJyb3JfZGVzY3JpcHRpb248 L3NwYW54PiBwYXJhbWV0ZXIgTVVTVCBOT1QgaW5jbHVkZQoJCSAgY2hhcmFjdGVycyBvdXRzaWRl IHRoZSBzZXQgJXgyMC0yMSAvICV4MjMtNUIgLyAleDVELTdFLgogICAgICAgICAgICAgICAgPC90 PgogICAgICAgICAgICAgICAgPHQgaGFuZ1RleHQ9J2Vycm9yX3VyaSc+CiAgICAgICAgICAgICAg ICAgIDx2c3BhY2UgLz4KICAgICAgICAgICAgICAgICAgT1BUSU9OQUwuIEEgVVJJIGlkZW50aWZ5 aW5nIGEgaHVtYW4tcmVhZGFibGUgd2ViIHBhZ2Ugd2l0aCBpbmZvcm1hdGlvbiBhYm91dCB0aGUK ICAgICAgICAgICAgICAgICAgZXJyb3IsIHVzZWQgdG8gcHJvdmlkZSB0aGUgY2xpZW50IGRldmVs b3BlciB3aXRoIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gYWJvdXQgdGhlCiAgICAgICAgICAgICAg ICAgIGVycm9yLgoJCSAgPHZzcGFjZS8+CgkJICBWYWx1ZXMgZm9yIHRoZSA8c3Bhbnggc3R5bGU9 J3ZlcmInPmVycm9yX3VyaTwvc3Bhbng+IHBhcmFtZXRlcgoJCSAgTVVTVCBjb25mb3JtIHRvIHRo ZSBVUkktUmVmZXJlbmNlIHN5bnRheCwgYW5kIHRodXMgTVVTVCBOT1QgaW5jbHVkZQoJCSAgY2hh cmFjdGVycyBvdXRzaWRlIHRoZSBzZXQgJXgyMSAvICV4MjMtNUIgLyAleDVELTdFLgogICAgICAg ICAgICAgICAgPC90PgogICAgICAgICAgICAgICAgPHQgaGFuZ1RleHQ9J3N0YXRlJz4KICAgICAg ICAgICAgICAgICAgPHZzcGFjZSAvPgogICAgICAgICAgICAgICAgICBSRVFVSVJFRCBpZiBhIDxz cGFueCBzdHlsZT0ndmVyYic+c3RhdGU8L3NwYW54PiBwYXJhbWV0ZXIgd2FzIHByZXNlbnQgaW4g dGhlCiAgICAgICAgICAgICAgICAgIGNsaWVudCBhdXRob3JpemF0aW9uIHJlcXVlc3QuIFRoZSBl eGFjdCB2YWx1ZSByZWNlaXZlZCBmcm9tIHRoZSBjbGllbnQuCiAgICAgICAgICAgICAgICA8L3Q+ CiAgICAgICAgICAgICAgPC9saXN0PgogICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgIDxmaWd1 cmU+CiAgICAgICAgICAgICAgPHByZWFtYmxlPgogICAgICAgICAgICAgICAgRm9yIGV4YW1wbGUs IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciByZWRpcmVjdHMgdGhlIHVzZXItYWdlbnQgYnkgc2Vu ZGluZyB0aGUKICAgICAgICAgICAgICAgIGZvbGxvd2luZyBIVFRQIHJlc3BvbnNlOgogICAgICAg ICAgICAgIDwvcHJlYW1ibGU+CiAgICAgICAgICAgICAgPGFydHdvcms+CiAgICAgICAgICAgICAg ICA8IVtDREFUQVsKICBIVFRQLzEuMSAzMDIgRm91bmQKICBMb2NhdGlvbjogaHR0cHM6Ly9jbGll bnQuZXhhbXBsZS5jb20vY2I/ZXJyb3I9YWNjZXNzX2RlbmllZCZzdGF0ZT14eXoKXV0+CiAgICAg ICAgICAgICAgPC9hcnR3b3JrPgogICAgICAgICAgICA8L2ZpZ3VyZT4KICAgICAgICAgIDwvc2Vj dGlvbj4KCiAgICAgICAgPC9zZWN0aW9uPgoKICAgICAgICA8c2VjdGlvbiB0aXRsZT0nQWNjZXNz IFRva2VuIFJlcXVlc3QnIGFuY2hvcj0idG9rZW4tcmVxIj4KICAgICAgICAgIDx0PgogICAgICAg ICAgICBUaGUgY2xpZW50IG1ha2VzIGEgcmVxdWVzdCB0byB0aGUgdG9rZW4gZW5kcG9pbnQgYnkg YWRkaW5nIHRoZSBmb2xsb3dpbmcgcGFyYW1ldGVycwogICAgICAgICAgICB1c2luZyB0aGUgPHNw YW54IHN0eWxlPSd2ZXJiJz5hcHBsaWNhdGlvbi94LXd3dy1mb3JtLXVybGVuY29kZWQ8L3NwYW54 PiBmb3JtYXQgaW4gdGhlCiAgICAgICAgICAgIEhUVFAgcmVxdWVzdCBlbnRpdHktYm9keToKICAg ICAgICAgIDwvdD4KICAgICAgICAgIDx0PgogICAgICAgICAgICA8bGlzdCBzdHlsZT0naGFuZ2lu ZycgaGFuZ0luZGVudD0nNic+CiAgICAgICAgICAgICAgPHQgaGFuZ1RleHQ9J2dyYW50X3R5cGUn PgogICAgICAgICAgICAgICAgPHZzcGFjZSAvPgogICAgICAgICAgICAgICAgUkVRVUlSRUQuIFZh bHVlIE1VU1QgYmUgc2V0IHRvIDxzcGFueCBzdHlsZT0ndmVyYic+YXV0aG9yaXphdGlvbl9jb2Rl PC9zcGFueD4uCiAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICAgIDx0IGhhbmdUZXh0PSdj b2RlJz4KICAgICAgICAgICAgICAgIDx2c3BhY2UgLz4KICAgICAgICAgICAgICAgIFJFUVVJUkVE LiBUaGUgYXV0aG9yaXphdGlvbiBjb2RlIHJlY2VpdmVkIGZyb20gdGhlIGF1dGhvcml6YXRpb24g c2VydmVyLgogICAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAgICA8dCBoYW5nVGV4dD0ncmVk aXJlY3RfdXJpJz4KICAgICAgICAgICAgICAgIDx2c3BhY2UgLz4KICAgICAgICAgICAgICAgIFJF UVVJUkVELCBpZiB0aGUgPHNwYW54IHN0eWxlPSd2ZXJiJz5yZWRpcmVjdF91cmk8L3NwYW54PiBw YXJhbWV0ZXIgd2FzIGluY2x1ZGVkIGluCiAgICAgICAgICAgICAgICB0aGUgYXV0aG9yaXphdGlv biByZXF1ZXN0IGFzIGRlc2NyaWJlZCBpbiA8eHJlZiB0YXJnZXQ9J2NvZGUtYXV0aHotcmVxJyAv PiwgYW5kCiAgICAgICAgICAgICAgICB0aGVpciB2YWx1ZXMgTVVTVCBiZSBpZGVudGljYWwuCiAg ICAgICAgICAgICAgPC90PgogICAgICAgICAgICA8L2xpc3Q+CiAgICAgICAgICA8L3Q+CiAgICAg ICAgICA8dD4KICAgICAgICAgICAgSWYgdGhlIGNsaWVudCB0eXBlIGlzIGNvbmZpZGVudGlhbCBv ciB0aGUgY2xpZW50IHdhcyBpc3N1ZWQgY2xpZW50IGNyZWRlbnRpYWxzIChvcgogICAgICAgICAg ICBhc3NpZ25lZCBvdGhlciBhdXRoZW50aWNhdGlvbiByZXF1aXJlbWVudHMpLCB0aGUgY2xpZW50 IE1VU1QgYXV0aGVudGljYXRlIHdpdGggdGhlCiAgICAgICAgICAgIGF1dGhvcml6YXRpb24gc2Vy dmVyIGFzIGRlc2NyaWJlZCBpbiA8eHJlZiB0YXJnZXQ9J3Rva2VuLWVuZHBvaW50LWF1dGgnIC8+ LgogICAgICAgICAgPC90PgogICAgICAgICAgPGZpZ3VyZT4KICAgICAgICAgICAgPHByZWFtYmxl PgogICAgICAgICAgICAgIEZvciBleGFtcGxlLCB0aGUgY2xpZW50IG1ha2VzIHRoZSBmb2xsb3dp bmcgSFRUUCByZXF1ZXN0IHVzaW5nIFRMUyAoZXh0cmEgbGluZSBicmVha3MKICAgICAgICAgICAg ICBhcmUgZm9yIGRpc3BsYXkgcHVycG9zZXMgb25seSk6CiAgICAgICAgICAgIDwvcHJlYW1ibGU+ CiAgICAgICAgICAgIDxhcnR3b3JrPgogICAgICAgICAgICAgIDwhW0NEQVRBWwogIFBPU1QgL3Rv a2VuIEhUVFAvMS4xCiAgSG9zdDogc2VydmVyLmV4YW1wbGUuY29tCiAgQXV0aG9yaXphdGlvbjog QmFzaWMgY3paQ2FHUlNhM0YwTXpwbldERm1RbUYwTTJKVwogIENvbnRlbnQtVHlwZTogYXBwbGlj YXRpb24veC13d3ctZm9ybS11cmxlbmNvZGVkO2NoYXJzZXQ9VVRGLTgKCiAgZ3JhbnRfdHlwZT1h dXRob3JpemF0aW9uX2NvZGUmY29kZT1TcGx4bE9CZVpRUVliWVM2V3hTYklBCiAgJnJlZGlyZWN0 X3VyaT1odHRwcyUzQSUyRiUyRmNsaWVudCUyRWV4YW1wbGUlMkVjb20lMkZjYgpdXT4KICAgICAg ICAgICAgPC9hcnR3b3JrPgogICAgICAgICAgPC9maWd1cmU+CiAgICAgICAgICA8dD4KICAgICAg ICAgICAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIE1VU1Q6CiAgICAgICAgICA8L3Q+CiAgICAg ICAgICA8dD4KICAgICAgICAgICAgPGxpc3Qgc3R5bGU9J3N5bWJvbHMnPgogICAgICAgICAgICAg IDx0PgogICAgICAgICAgICAgICAgcmVxdWlyZSBjbGllbnQgYXV0aGVudGljYXRpb24gZm9yIGNv bmZpZGVudGlhbCBjbGllbnRzIG9yIGZvciBhbnkgY2xpZW50IHRoYXQgd2FzCiAgICAgICAgICAg ICAgICBpc3N1ZWQgY2xpZW50IGNyZWRlbnRpYWxzIChvciB3aXRoIG90aGVyIGF1dGhlbnRpY2F0 aW9uIHJlcXVpcmVtZW50cyksCiAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICAgIDx0Pgog ICAgICAgICAgICAgICAgYXV0aGVudGljYXRlIHRoZSBjbGllbnQgaWYgY2xpZW50IGF1dGhlbnRp Y2F0aW9uIGlzIGluY2x1ZGVkIGFuZCBlbnN1cmUgdGhlCiAgICAgICAgICAgICAgICBhdXRob3Jp emF0aW9uIGNvZGUgd2FzIGlzc3VlZCB0byB0aGUgYXV0aGVudGljYXRlZCBjbGllbnQsCiAgICAg ICAgICAgICAgPC90PgogICAgICAgICAgICAgIDx0PgogICAgICAgICAgICAgICAgdmVyaWZ5IHRo YXQgdGhlIGF1dGhvcml6YXRpb24gY29kZSBpcyB2YWxpZCwgYW5kCiAgICAgICAgICAgICAgPC90 PgogICAgICAgICAgICAgIDx0PgogICAgICAgICAgICAgICAgZW5zdXJlIHRoYXQgdGhlIDxzcGFu eCBzdHlsZT0ndmVyYic+cmVkaXJlY3RfdXJpPC9zcGFueD4gcGFyYW1ldGVyIGlzIHByZXNlbnQg aWYKICAgICAgICAgICAgICAgIHRoZSA8c3Bhbnggc3R5bGU9J3ZlcmInPnJlZGlyZWN0X3VyaTwv c3Bhbng+IHBhcmFtZXRlciB3YXMgaW5jbHVkZWQgaW4gdGhlIGluaXRpYWwKICAgICAgICAgICAg ICAgIGF1dGhvcml6YXRpb24gcmVxdWVzdCBhcyBkZXNjcmliZWQgaW4gPHhyZWYgdGFyZ2V0PSdj b2RlLWF1dGh6LXJlcScgLz4sIGFuZCBpZgogICAgICAgICAgICAgICAgaW5jbHVkZWQgZW5zdXJl IHRoZWlyIHZhbHVlcyBhcmUgaWRlbnRpY2FsLgogICAgICAgICAgICAgIDwvdD4KICAgICAgICAg ICAgPC9saXN0PgogICAgICAgICAgPC90PgogICAgICAgIDwvc2VjdGlvbj4KCiAgICAgICAgPHNl Y3Rpb24gdGl0bGU9J0FjY2VzcyBUb2tlbiBSZXNwb25zZSc+CiAgICAgICAgICA8dD4KICAgICAg ICAgICAgSWYgdGhlIGFjY2VzcyB0b2tlbiByZXF1ZXN0IGlzIHZhbGlkIGFuZCBhdXRob3JpemVk LCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgaXNzdWVzIGFuCiAgICAgICAgICAgIGFjY2VzcyB0 b2tlbiBhbmQgb3B0aW9uYWwgcmVmcmVzaCB0b2tlbiBhcyBkZXNjcmliZWQgaW4gPHhyZWYgdGFy Z2V0PSd0b2tlbi1yZXNwb25zZScgLz4uCiAgICAgICAgICAgIElmIHRoZSByZXF1ZXN0IGNsaWVu dCBhdXRoZW50aWNhdGlvbiBmYWlsZWQgb3IgaXMgaW52YWxpZCwgdGhlIGF1dGhvcml6YXRpb24g c2VydmVyIHJldHVybnMKICAgICAgICAgICAgYW4gZXJyb3IgcmVzcG9uc2UgYXMgZGVzY3JpYmVk IGluIDx4cmVmIHRhcmdldD0ndG9rZW4tZXJyb3JzJyAvPi4KICAgICAgICAgIDwvdD4KICAgICAg ICAgIDxmaWd1cmU+CiAgICAgICAgICAgIDxwcmVhbWJsZT4KICAgICAgICAgICAgICBBbiBleGFt cGxlIHN1Y2Nlc3NmdWwgcmVzcG9uc2U6CiAgICAgICAgICAgIDwvcHJlYW1ibGU+CiAgICAgICAg ICAgIDxhcnR3b3JrPgogICAgICAgICAgICAgIDwhW0NEQVRBWwogIEhUVFAvMS4xIDIwMCBPSwog IENvbnRlbnQtVHlwZTogYXBwbGljYXRpb24vanNvbjtjaGFyc2V0PVVURi04CiAgQ2FjaGUtQ29u dHJvbDogbm8tc3RvcmUKICBQcmFnbWE6IG5vLWNhY2hlCgogIHsKICAgICJhY2Nlc3NfdG9rZW4i OiIyWW90bkZaRkVqcjF6Q3NpY01XcEFBIiwKICAgICJ0b2tlbl90eXBlIjoiZXhhbXBsZSIsCiAg ICAiZXhwaXJlc19pbiI6MzYwMCwKICAgICJyZWZyZXNoX3Rva2VuIjoidEd6djNKT2tGMFhHNVF4 MlRsS1dJQSIsCiAgICAiZXhhbXBsZV9wYXJhbWV0ZXIiOiJleGFtcGxlX3ZhbHVlIgogIH0KXV0+ CiAgICAgICAgICAgIDwvYXJ0d29yaz4KICAgICAgICAgIDwvZmlndXJlPgogICAgICAgIDwvc2Vj dGlvbj4KCiAgICAgIDwvc2VjdGlvbj4KCiAgICAgIDxzZWN0aW9uIHRpdGxlPSdJbXBsaWNpdCBH cmFudCcgYW5jaG9yPSdncmFudC1pbXBsaWNpdCc+CiAgICAgICAgPHQ+CiAgICAgICAgICBUaGUg aW1wbGljaXQgZ3JhbnQgdHlwZSBpcyB1c2VkIHRvIG9idGFpbiBhY2Nlc3MgdG9rZW5zIChpdCBk b2VzIG5vdCBzdXBwb3J0IHRoZSBpc3N1YW5jZQogICAgICAgICAgb2YgcmVmcmVzaCB0b2tlbnMp IGFuZCBpcyBvcHRpbWl6ZWQgZm9yIHB1YmxpYyBjbGllbnRzIGtub3duIHRvIG9wZXJhdGUgYSBw YXJ0aWN1bGFyCiAgICAgICAgICByZWRpcmVjdGlvbiBVUkkuIFRoZXNlIGNsaWVudHMgYXJlIHR5 cGljYWxseSBpbXBsZW1lbnRlZCBpbiBhIGJyb3dzZXIgdXNpbmcgYSBzY3JpcHRpbmcKICAgICAg ICAgIGxhbmd1YWdlIHN1Y2ggYXMgSmF2YVNjcmlwdC4KICAgICAgICA8L3Q+CiAgICAgICAgPHQ+ CiAgICAgICAgICBBcyBhIHJlZGlyZWN0aW9uLWJhc2VkIGZsb3csIHRoZSBjbGllbnQgbXVzdCBi ZSBjYXBhYmxlIG9mIGludGVyYWN0aW5nIHdpdGggdGhlCiAgICAgICAgICByZXNvdXJjZSBvd25l cidzIHVzZXItYWdlbnQgKHR5cGljYWxseSBhIHdlYiBicm93c2VyKSBhbmQgY2FwYWJsZSBvZiBy ZWNlaXZpbmcgaW5jb21pbmcKICAgICAgICAgIHJlcXVlc3RzICh2aWEgcmVkaXJlY3Rpb24pIGZy b20gdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLgogICAgICAgIDwvdD4KICAgICAgICA8dD4KICAg ICAgICAgIFVubGlrZSB0aGUgYXV0aG9yaXphdGlvbiBjb2RlIGdyYW50IHR5cGUgaW4gd2hpY2gg dGhlIGNsaWVudCBtYWtlcyBzZXBhcmF0ZSByZXF1ZXN0cyBmb3IKICAgICAgICAgIGF1dGhvcml6 YXRpb24gYW5kIGFjY2VzcyB0b2tlbiwgdGhlIGNsaWVudCByZWNlaXZlcyB0aGUgYWNjZXNzIHRv a2VuIGFzIHRoZSByZXN1bHQgb2YgdGhlCiAgICAgICAgICBhdXRob3JpemF0aW9uIHJlcXVlc3Qu CiAgICAgICAgPC90PgogICAgICAgIDx0PgogICAgICAgICAgVGhlIGltcGxpY2l0IGdyYW50IHR5 cGUgZG9lcyBub3QgaW5jbHVkZSBjbGllbnQgYXV0aGVudGljYXRpb24sIGFuZCByZWxpZXMgb24g dGhlCiAgICAgICAgICBwcmVzZW5jZSBvZiB0aGUgcmVzb3VyY2Ugb3duZXIgYW5kIHRoZSByZWdp c3RyYXRpb24gb2YgdGhlIHJlZGlyZWN0aW9uIFVSSS4gQmVjYXVzZSB0aGUKICAgICAgICAgIGFj Y2VzcyB0b2tlbiBpcyBlbmNvZGVkIGludG8gdGhlIHJlZGlyZWN0aW9uIFVSSSwgaXQgbWF5IGJl IGV4cG9zZWQgdG8gdGhlIHJlc291cmNlIG93bmVyCiAgICAgICAgICBhbmQgb3RoZXIgYXBwbGlj YXRpb25zIHJlc2lkaW5nIG9uIHRoZSBzYW1lIGRldmljZS4KICAgICAgICA8L3Q+CiAgICAgICAg PGZpZ3VyZSB0aXRsZT0nSW1wbGljaXQgR3JhbnQgRmxvdycgYW5jaG9yPSdGaWd1cmUtNCc+CiAg ICAgICAgICA8YXJ0d29yaz4KICAgICAgICAgICAgPCFbQ0RBVEFbCiAgKy0tLS0tLS0tLS0rCiAg fCBSZXNvdXJjZSB8CiAgfCAgT3duZXIgICB8CiAgfCAgICAgICAgICB8CiAgKy0tLS0tLS0tLS0r CiAgICAgICBeCiAgICAgICB8CiAgICAgIChCKSAgICAgIAogICstLS0tfC0tLS0tKyAgICAgICAg ICBDbGllbnQgSWRlbnRpZmllciAgICAgKy0tLS0tLS0tLS0tLS0tLSsKICB8ICAgICAgICAgLSst LS0tKEEpLS0gJiBSZWRpcmVjdGlvbiBVUkkgLS0tPnwgICAgICAgICAgICAgICB8CiAgfCAgVXNl ci0gICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IEF1dGhvcml6YXRpb24gfAog IHwgIEFnZW50ICAtfC0tLS0oQiktLSBVc2VyIGF1dGhlbnRpY2F0ZXMgLS0+fCAgICAgU2VydmVy ICAgIHwKICB8ICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAg ICAgICAgICAgICB8CiAgfCAgICAgICAgICB8PC0tLShDKS0tLSBSZWRpcmVjdGlvbiBVUkkgLS0t LTx8ICAgICAgICAgICAgICAgfAogIHwgICAgICAgICAgfCAgICAgICAgICB3aXRoIEFjY2VzcyBU b2tlbiAgICAgKy0tLS0tLS0tLS0tLS0tLSsKICB8ICAgICAgICAgIHwgICAgICAgICAgICBpbiBG cmFnbWVudAogIHwgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0t LS0tLS0tLS0tLS0tLSsKICB8ICAgICAgICAgIHwtLS0tKEQpLS0tIFJlZGlyZWN0aW9uIFVSSSAt LS0tPnwgICBXZWItSG9zdGVkICB8CiAgfCAgICAgICAgICB8ICAgICAgICAgIHdpdGhvdXQgRnJh Z21lbnQgICAgICB8ICAgICBDbGllbnQgICAgfAogIHwgICAgICAgICAgfCAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgfCAgICBSZXNvdXJjZSAgIHwKICB8ICAgICAoRikgIHw8LS0tKEUp LS0tLS0tLSBTY3JpcHQgLS0tLS0tLS0tPHwgICAgICAgICAgICAgICB8CiAgfCAgICAgICAgICB8 ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tKwogICstfC0t LS0tLS0tKwogICAgfCAgICB8ICAgIAogICAoQSkgIChHKSBBY2Nlc3MgVG9rZW4KICAgIHwgICAg fAogICAgXiAgICB2CiAgKy0tLS0tLS0tLSsKICB8ICAgICAgICAgfAogIHwgIENsaWVudCB8CiAg fCAgICAgICAgIHwKICArLS0tLS0tLS0tKwpdXT4KICAgICAgICAgIDwvYXJ0d29yaz4KICAgICAg ICAgIDxwb3N0YW1ibGU+CiAgICAgICAgICAgIE5vdGU6IFRoZSBsaW5lcyBpbGx1c3RyYXRpbmcg c3RlcHMgQSBhbmQgQiBhcmUgYnJva2VuIGludG8gdHdvIHBhcnRzIGFzIHRoZXkgcGFzcwogICAg ICAgICAgICB0aHJvdWdoIHRoZSB1c2VyLWFnZW50LgogICAgICAgICAgPC9wb3N0YW1ibGU+CiAg ICAgICAgPC9maWd1cmU+CiAgICAgICAgPHQ+CiAgICAgICAgICBUaGUgZmxvdyBpbGx1c3RyYXRl ZCBpbiA8eHJlZiB0YXJnZXQ9J0ZpZ3VyZS00JyAvPiBpbmNsdWRlcyB0aGUgZm9sbG93aW5nIHN0 ZXBzOgogICAgICAgIDwvdD4KICAgICAgICA8dD4KICAgICAgICAgIDxsaXN0IHN0eWxlPSdmb3Jt YXQgKCVDKSc+CiAgICAgICAgICAgIDx0PgogICAgICAgICAgICAgIFRoZSBjbGllbnQgaW5pdGlh dGVzIHRoZSBmbG93IGJ5IGRpcmVjdGluZyB0aGUgcmVzb3VyY2Ugb3duZXIncyB1c2VyLWFnZW50 IHRvIHRoZQogICAgICAgICAgICAgIGF1dGhvcml6YXRpb24gZW5kcG9pbnQuIFRoZSBjbGllbnQg aW5jbHVkZXMgaXRzIGNsaWVudCBpZGVudGlmaWVyLCByZXF1ZXN0ZWQKICAgICAgICAgICAgICBz Y29wZSwgbG9jYWwgc3RhdGUsIGFuZCBhIHJlZGlyZWN0aW9uIFVSSSB0byB3aGljaCB0aGUgYXV0 aG9yaXphdGlvbiBzZXJ2ZXIgd2lsbCBzZW5kCiAgICAgICAgICAgICAgdGhlIHVzZXItYWdlbnQg YmFjayBvbmNlIGFjY2VzcyBpcyBncmFudGVkIChvciBkZW5pZWQpLgogICAgICAgICAgICA8L3Q+ CiAgICAgICAgICAgIDx0PgogICAgICAgICAgICAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBh dXRoZW50aWNhdGVzIHRoZSByZXNvdXJjZSBvd25lciAodmlhIHRoZSB1c2VyLWFnZW50KSBhbmQK ICAgICAgICAgICAgICBlc3RhYmxpc2hlcyB3aGV0aGVyIHRoZSByZXNvdXJjZSBvd25lciBncmFu dHMgb3IgZGVuaWVzIHRoZSBjbGllbnQncyBhY2Nlc3MgcmVxdWVzdC4KICAgICAgICAgICAgPC90 PgogICAgICAgICAgICA8dD4KICAgICAgICAgICAgICBBc3N1bWluZyB0aGUgcmVzb3VyY2Ugb3du ZXIgZ3JhbnRzIGFjY2VzcywgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHJlZGlyZWN0cyB0aGUK ICAgICAgICAgICAgICB1c2VyLWFnZW50IGJhY2sgdG8gdGhlIGNsaWVudCB1c2luZyB0aGUgcmVk aXJlY3Rpb24gVVJJIHByb3ZpZGVkIGVhcmxpZXIuIFRoZQogICAgICAgICAgICAgIHJlZGlyZWN0 aW9uIFVSSSBpbmNsdWRlcyB0aGUgYWNjZXNzIHRva2VuIGluIHRoZSBVUkkgZnJhZ21lbnQuCiAg ICAgICAgICAgIDwvdD4KICAgICAgICAgICAgPHQ+CiAgICAgICAgICAgICAgVGhlIHVzZXItYWdl bnQgZm9sbG93cyB0aGUgcmVkaXJlY3Rpb24gaW5zdHJ1Y3Rpb25zIGJ5IG1ha2luZyBhIHJlcXVl c3QgdG8gdGhlCiAgICAgICAgICAgICAgd2ViLWhvc3RlZCBjbGllbnQgcmVzb3VyY2UgKHdoaWNo IGRvZXMgbm90IGluY2x1ZGUgdGhlIGZyYWdtZW50IHBlcgogICAgICAgICAgICAgIDx4cmVmIHRh cmdldD0nUkZDMjYxNicgLz4pLiBUaGUgdXNlci1hZ2VudCByZXRhaW5zIHRoZSBmcmFnbWVudCBp bmZvcm1hdGlvbiBsb2NhbGx5LgogICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgIDx0PgogICAg ICAgICAgICAgIFRoZSB3ZWItaG9zdGVkIGNsaWVudCByZXNvdXJjZSByZXR1cm5zIGEgd2ViIHBh Z2UgKHR5cGljYWxseSBhbiBIVE1MIGRvY3VtZW50IHdpdGggYW4KICAgICAgICAgICAgICBlbWJl ZGRlZCBzY3JpcHQpIGNhcGFibGUgb2YgYWNjZXNzaW5nIHRoZSBmdWxsIHJlZGlyZWN0aW9uIFVS SSBpbmNsdWRpbmcgdGhlIGZyYWdtZW50CiAgICAgICAgICAgICAgcmV0YWluZWQgYnkgdGhlIHVz ZXItYWdlbnQsIGFuZCBleHRyYWN0aW5nIHRoZSBhY2Nlc3MgdG9rZW4gKGFuZCBvdGhlciBwYXJh bWV0ZXJzKQogICAgICAgICAgICAgIGNvbnRhaW5lZCBpbiB0aGUgZnJhZ21lbnQuCiAgICAgICAg ICAgIDwvdD4KICAgICAgICAgICAgPHQ+CiAgICAgICAgICAgICAgVGhlIHVzZXItYWdlbnQgZXhl Y3V0ZXMgdGhlIHNjcmlwdCBwcm92aWRlZCBieSB0aGUgd2ViLWhvc3RlZCBjbGllbnQgcmVzb3Vy Y2UKICAgICAgICAgICAgICBsb2NhbGx5LCB3aGljaCBleHRyYWN0cyB0aGUgYWNjZXNzIHRva2Vu IGFuZCBwYXNzZXMgaXQgdG8gdGhlIGNsaWVudC4KICAgICAgICAgICAgPC90PgogICAgICAgICAg PC9saXN0PgogICAgICAgIDwvdD4KCiAgICAgICAgPHNlY3Rpb24gdGl0bGU9J0F1dGhvcml6YXRp b24gUmVxdWVzdCcgYW5jaG9yPSdpbXBsaWNpdC1hdXRoei1yZXEnPgogICAgICAgICAgPHQ+CiAg ICAgICAgICAgIFRoZSBjbGllbnQgY29uc3RydWN0cyB0aGUgcmVxdWVzdCBVUkkgYnkgYWRkaW5n IHRoZSBmb2xsb3dpbmcgcGFyYW1ldGVycyB0byB0aGUKICAgICAgICAgICAgcXVlcnkgY29tcG9u ZW50IG9mIHRoZSBhdXRob3JpemF0aW9uIGVuZHBvaW50IFVSSSB1c2luZyB0aGUKICAgICAgICAg ICAgPHNwYW54IHN0eWxlPSd2ZXJiJz5hcHBsaWNhdGlvbi94LXd3dy1mb3JtLXVybGVuY29kZWQ8 L3NwYW54PiBmb3JtYXQ6CiAgICAgICAgICA8L3Q+CiAgICAgICAgICA8dD4KICAgICAgICAgICAg PGxpc3Qgc3R5bGU9J2hhbmdpbmcnIGhhbmdJbmRlbnQ9JzYnPgogICAgICAgICAgICAgIDx0IGhh bmdUZXh0PSdyZXNwb25zZV90eXBlJz4KICAgICAgICAgICAgICAgIDx2c3BhY2UgLz4KICAgICAg ICAgICAgICAgIFJFUVVJUkVELiBWYWx1ZSBNVVNUIGJlIHNldCB0byA8c3Bhbnggc3R5bGU9J3Zl cmInPnRva2VuPC9zcGFueD4uCiAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICAgIDx0IGhh bmdUZXh0PSdjbGllbnRfaWQnPgogICAgICAgICAgICAgICAgPHZzcGFjZSAvPgogICAgICAgICAg ICAgICAgUkVRVUlSRUQuIFRoZSBjbGllbnQgaWRlbnRpZmllciBhcyBkZXNjcmliZWQgaW4KICAg ICAgICAgICAgICAgIDx4cmVmIHRhcmdldD0nY2xpZW50LWlkZW50aWZpZXInIC8+LgogICAgICAg ICAgICAgIDwvdD4KICAgICAgICAgICAgICA8dCBoYW5nVGV4dD0ncmVkaXJlY3RfdXJpJz4KICAg ICAgICAgICAgICAgIDx2c3BhY2UgLz4KICAgICAgICAgICAgICAgIE9QVElPTkFMLiBBcyBkZXNj cmliZWQgaW4gPHhyZWYgdGFyZ2V0PSdyZWRpcmVjdC11cmknIC8+LgogICAgICAgICAgICAgIDwv dD4KICAgICAgICAgICAgICA8dCBoYW5nVGV4dD0nc2NvcGUnPgogICAgICAgICAgICAgICAgPHZz cGFjZSAvPgogICAgICAgICAgICAgICAgT1BUSU9OQUwuIFRoZSBzY29wZSBvZiB0aGUgYWNjZXNz IHJlcXVlc3QgYXMgZGVzY3JpYmVkIGJ5IDx4cmVmIHRhcmdldD0nc2NvcGUnIC8+LgogICAgICAg ICAgICAgIDwvdD4KICAgICAgICAgICAgICA8dCBoYW5nVGV4dD0nc3RhdGUnPgogICAgICAgICAg ICAgICAgPHZzcGFjZSAvPgogICAgICAgICAgICAgICAgUkVDT01NRU5ERUQuIEFuIG9wYXF1ZSB2 YWx1ZSB1c2VkIGJ5IHRoZSBjbGllbnQgdG8gbWFpbnRhaW4gc3RhdGUgYmV0d2VlbiB0aGUgcmVx dWVzdAogICAgICAgICAgICAgICAgYW5kIGNhbGxiYWNrLiBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2 ZXIgaW5jbHVkZXMgdGhpcyB2YWx1ZSB3aGVuIHJlZGlyZWN0aW5nIHRoZQogICAgICAgICAgICAg ICAgdXNlci1hZ2VudCBiYWNrIHRvIHRoZSBjbGllbnQuIFRoZSBwYXJhbWV0ZXIgU0hPVUxEIGJl IHVzZWQgZm9yIHByZXZlbnRpbmcKICAgICAgICAgICAgICAgIGNyb3NzLXNpdGUgcmVxdWVzdCBm b3JnZXJ5IGFzIGRlc2NyaWJlZCBpbiA8eHJlZiB0YXJnZXQ9J0NTUkYnIC8+LgogICAgICAgICAg ICAgIDwvdD4KICAgICAgICAgICAgPC9saXN0PgogICAgICAgICAgPC90PgogICAgICAgICAgPHQ+ CiAgICAgICAgICAgIFRoZSBjbGllbnQgZGlyZWN0cyB0aGUgcmVzb3VyY2Ugb3duZXIgdG8gdGhl IGNvbnN0cnVjdGVkIFVSSSB1c2luZyBhbiBIVFRQIHJlZGlyZWN0aW9uCiAgICAgICAgICAgIHJl c3BvbnNlLCBvciBieSBvdGhlciBtZWFucyBhdmFpbGFibGUgdG8gaXQgdmlhIHRoZSB1c2VyLWFn ZW50LgogICAgICAgICAgPC90PgogICAgICAgICAgPGZpZ3VyZT4KICAgICAgICAgICAgPHByZWFt YmxlPgogICAgICAgICAgICAgIEZvciBleGFtcGxlLCB0aGUgY2xpZW50IGRpcmVjdHMgdGhlIHVz ZXItYWdlbnQgdG8gbWFrZSB0aGUgZm9sbG93aW5nIEhUVFAgcmVxdWVzdAogICAgICAgICAgICAg IHVzaW5nIFRMUyAoZXh0cmEgbGluZSBicmVha3MgYXJlIGZvciBkaXNwbGF5IHB1cnBvc2VzIG9u bHkpOgogICAgICAgICAgICA8L3ByZWFtYmxlPgogICAgICAgICAgICA8YXJ0d29yaz4KICAgICAg ICAgICAgICA8IVtDREFUQVsKICBHRVQgL2F1dGhvcml6ZT9yZXNwb25zZV90eXBlPXRva2VuJmNs aWVudF9pZD1zNkJoZFJrcXQzJnN0YXRlPXh5egogICAgICAmcmVkaXJlY3RfdXJpPWh0dHBzJTNB JTJGJTJGY2xpZW50JTJFZXhhbXBsZSUyRWNvbSUyRmNiIEhUVFAvMS4xCiAgSG9zdDogc2VydmVy LmV4YW1wbGUuY29tCl1dPgogICAgICAgICAgICA8L2FydHdvcms+CiAgICAgICAgICA8L2ZpZ3Vy ZT4KICAgICAgICAgIDx0PgogICAgICAgICAgICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgdmFs aWRhdGVzIHRoZSByZXF1ZXN0IHRvIGVuc3VyZSBhbGwgcmVxdWlyZWQgcGFyYW1ldGVycyBhcmUK ICAgICAgICAgICAgcHJlc2VudCBhbmQgdmFsaWQuIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBN VVNUIHZlcmlmeSB0aGF0IHRoZSByZWRpcmVjdGlvbiBVUkkgdG8gd2hpY2gKICAgICAgICAgICAg aXQgd2lsbCByZWRpcmVjdCB0aGUgYWNjZXNzIHRva2VuIG1hdGNoZXMgYSByZWRpcmVjdGlvbiBV UkkgcmVnaXN0ZXJlZCBieSB0aGUgY2xpZW50IGFzCiAgICAgICAgICAgIGRlc2NyaWJlZCBpbiA8 eHJlZiB0YXJnZXQ9J3JlZGlyZWN0LXVyaScgLz4uCiAgICAgICAgICA8L3Q+CiAgICAgICAgICA8 dD4KICAgICAgICAgICAgSWYgdGhlIHJlcXVlc3QgaXMgdmFsaWQsIHRoZSBhdXRob3JpemF0aW9u IHNlcnZlciBhdXRoZW50aWNhdGVzIHRoZSByZXNvdXJjZSBvd25lciBhbmQKICAgICAgICAgICAg b2J0YWlucyBhbiBhdXRob3JpemF0aW9uIGRlY2lzaW9uIChieSBhc2tpbmcgdGhlIHJlc291cmNl IG93bmVyIG9yIGJ5IGVzdGFibGlzaGluZwogICAgICAgICAgICBhcHByb3ZhbCB2aWEgb3RoZXIg bWVhbnMpLgogICAgICAgICAgPC90PgogICAgICAgICAgPHQ+CiAgICAgICAgICAgIFdoZW4gYSBk ZWNpc2lvbiBpcyBlc3RhYmxpc2hlZCwgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGRpcmVjdHMg dGhlIHVzZXItYWdlbnQgdG8gdGhlCiAgICAgICAgICAgIHByb3ZpZGVkIGNsaWVudCByZWRpcmVj dGlvbiBVUkkgdXNpbmcgYW4gSFRUUCByZWRpcmVjdGlvbiByZXNwb25zZSwgb3IgYnkgb3RoZXIg bWVhbnMKICAgICAgICAgICAgYXZhaWxhYmxlIHRvIGl0IHZpYSB0aGUgdXNlci1hZ2VudC4KICAg ICAgICAgIDwvdD4KICAgICAgICA8L3NlY3Rpb24+CgogICAgICAgIDxzZWN0aW9uIHRpdGxlPSdB Y2Nlc3MgVG9rZW4gUmVzcG9uc2UnIGFuY2hvcj0iaW1wbGljaXQtYXV0aHotcmVzcCI+CiAgICAg ICAgICA8dD4KICAgICAgICAgICAgSWYgdGhlIHJlc291cmNlIG93bmVyIGdyYW50cyB0aGUgYWNj ZXNzIHJlcXVlc3QsIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBpc3N1ZXMgYW4KICAgICAgICAg ICAgYWNjZXNzIHRva2VuIGFuZCBkZWxpdmVycyBpdCB0byB0aGUgY2xpZW50IGJ5IGFkZGluZyB0 aGUgZm9sbG93aW5nIHBhcmFtZXRlcnMgdG8KICAgICAgICAgICAgdGhlIGZyYWdtZW50IGNvbXBv bmVudCBvZiB0aGUgcmVkaXJlY3Rpb24gVVJJIHVzaW5nIHRoZQogICAgICAgICAgICA8c3Bhbngg c3R5bGU9J3ZlcmInPmFwcGxpY2F0aW9uL3gtd3d3LWZvcm0tdXJsZW5jb2RlZDwvc3Bhbng+IGZv cm1hdDoKICAgICAgICAgIDwvdD4KICAgICAgICAgIDx0PgogICAgICAgICAgICA8bGlzdCBzdHls ZT0naGFuZ2luZycgaGFuZ0luZGVudD0nNic+CiAgICAgICAgICAgICAgPHQgaGFuZ1RleHQ9J2Fj Y2Vzc190b2tlbic+CiAgICAgICAgICAgICAgICA8dnNwYWNlIC8+CiAgICAgICAgICAgICAgICBS RVFVSVJFRC4gVGhlIGFjY2VzcyB0b2tlbiBpc3N1ZWQgYnkgdGhlIGF1dGhvcml6YXRpb24gc2Vy dmVyLgogICAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAgICA8dCBoYW5nVGV4dD0ndG9rZW5f dHlwZSc+CiAgICAgICAgICAgICAgICA8dnNwYWNlIC8+CiAgICAgICAgICAgICAgICBSRVFVSVJF RC4gVGhlIHR5cGUgb2YgdGhlIHRva2VuIGlzc3VlZCBhcyBkZXNjcmliZWQgaW4KICAgICAgICAg ICAgICAgIDx4cmVmIHRhcmdldD0ndG9rZW4tdHlwZXMnIC8+LiBWYWx1ZSBpcyBjYXNlIGluc2Vu c2l0aXZlLgogICAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAgICA8dCBoYW5nVGV4dD0nZXhw aXJlc19pbic+CiAgICAgICAgICAgICAgICA8dnNwYWNlIC8+CiAgICAgICAgICAgICAgICBSRUNP TU1FTkRFRC4gVGhlIGxpZmV0aW1lIGluIHNlY29uZHMgb2YgdGhlIGFjY2VzcyB0b2tlbi4gRm9y IGV4YW1wbGUsIHRoZSB2YWx1ZQogICAgICAgICAgICAgICAgPHNwYW54IHN0eWxlPSd2ZXJiJz4z NjAwPC9zcGFueD4gZGVub3RlcyB0aGF0IHRoZSBhY2Nlc3MgdG9rZW4gd2lsbCBleHBpcmUgaW4g b25lCiAgICAgICAgICAgICAgICBob3VyIGZyb20gdGhlIHRpbWUgdGhlIHJlc3BvbnNlIHdhcyBn ZW5lcmF0ZWQuIElmIG9taXR0ZWQsIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlcgogICAgICAgICAg ICAgICAgU0hPVUxEIHByb3ZpZGUgdGhlIGV4cGlyYXRpb24gdGltZSB2aWEgb3RoZXIgbWVhbnMg b3IgZG9jdW1lbnQgdGhlIGRlZmF1bHQgdmFsdWUuCiAgICAgICAgICAgICAgPC90PgogICAgICAg ICAgICAgIDx0IGhhbmdUZXh0PSdzY29wZSc+CiAgICAgICAgICAgICAgICA8dnNwYWNlIC8+CiAg ICAgICAgICAgICAgICBPUFRJT05BTCwgaWYgaWRlbnRpY2FsIHRvIHRoZSBzY29wZSByZXF1ZXN0 ZWQgYnkgdGhlIGNsaWVudCwgb3RoZXJ3aXNlIFJFUVVJUkVELiBUaGUKICAgICAgICAgICAgICAg IHNjb3BlIG9mIHRoZSBhY2Nlc3MgdG9rZW4gYXMgZGVzY3JpYmVkIGJ5IDx4cmVmIHRhcmdldD0n c2NvcGUnIC8+LgogICAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAgICA8dCBoYW5nVGV4dD0n c3RhdGUnPgogICAgICAgICAgICAgICAgPHZzcGFjZSAvPgogICAgICAgICAgICAgICAgUkVRVUlS RUQgaWYgdGhlIDxzcGFueCBzdHlsZT0ndmVyYic+c3RhdGU8L3NwYW54PiBwYXJhbWV0ZXIgd2Fz IHByZXNlbnQgaW4gdGhlCiAgICAgICAgICAgICAgICBjbGllbnQgYXV0aG9yaXphdGlvbiByZXF1 ZXN0LiBUaGUgZXhhY3QgdmFsdWUgcmVjZWl2ZWQgZnJvbSB0aGUgY2xpZW50LgogICAgICAgICAg ICAgIDwvdD4KICAgICAgICAgICAgPC9saXN0PgogICAgICAgICAgPC90PgogICAgICAgICAgPHQ+ CiAgICAgICAgICAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBNVVNUIE5PVCBpc3N1ZSBhIHJl ZnJlc2ggdG9rZW4uCiAgICAgICAgICA8L3Q+CiAgICAgICAgICA8ZmlndXJlPgogICAgICAgICAg ICA8cHJlYW1ibGU+CiAgICAgICAgICAgICAgRm9yIGV4YW1wbGUsIHRoZSBhdXRob3JpemF0aW9u IHNlcnZlciByZWRpcmVjdHMgdGhlIHVzZXItYWdlbnQgYnkgc2VuZGluZyB0aGUKICAgICAgICAg ICAgICBmb2xsb3dpbmcgSFRUUCByZXNwb25zZSAoVVJJIGV4dHJhIGxpbmUgYnJlYWtzIGFyZSBm b3IgZGlzcGxheSBwdXJwb3NlcyBvbmx5KToKICAgICAgICAgICAgPC9wcmVhbWJsZT4KICAgICAg ICAgICAgPGFydHdvcms+CiAgICAgICAgICAgICAgPCFbQ0RBVEFbCiAgSFRUUC8xLjEgMzAyIEZv dW5kCiAgTG9jYXRpb246IGh0dHA6Ly9leGFtcGxlLmNvbS9jYiNhY2Nlc3NfdG9rZW49MllvdG5G WkZFanIxekNzaWNNV3BBQQogICAgICAgICAgICAmc3RhdGU9eHl6JnRva2VuX3R5cGU9ZXhhbXBs ZSZleHBpcmVzX2luPTM2MDAKXV0+CiAgICAgICAgICAgIDwvYXJ0d29yaz4KICAgICAgICAgICAg PHBvc3RhbWJsZT4KICAgICAgICAgICAgICBEZXZlbG9wZXJzIHNob3VsZCBub3RlIHRoYXQgc29t ZSB1c2VyLWFnZW50cyBkbyBub3Qgc3VwcG9ydCB0aGUgaW5jbHVzaW9uIG9mIGEKICAgICAgICAg ICAgICBmcmFnbWVudCBjb21wb25lbnQgaW4gdGhlIEhUVFAgPHNwYW54IHN0eWxlPSd2ZXJiJz5M b2NhdGlvbjwvc3Bhbng+IHJlc3BvbnNlIGhlYWRlcgogICAgICAgICAgICAgIGZpZWxkLiBTdWNo IGNsaWVudHMgd2lsbCByZXF1aXJlIHVzaW5nIG90aGVyIG1ldGhvZHMgZm9yIHJlZGlyZWN0aW5n IHRoZSBjbGllbnQgdGhhbgogICAgICAgICAgICAgIGEgM3h4IHJlZGlyZWN0aW9uIHJlc3BvbnNl LiBGb3IgZXhhbXBsZSwgcmV0dXJuaW5nIGFuIEhUTUwgcGFnZSB3aGljaCBpbmNsdWRlcyBhCiAg ICAgICAgICAgICAgJ2NvbnRpbnVlJyBidXR0b24gd2l0aCBhbiBhY3Rpb24gbGlua2VkIHRvIHRo ZSByZWRpcmVjdGlvbiBVUkkuCiAgICAgICAgICAgIDwvcG9zdGFtYmxlPgogICAgICAgICAgPC9m aWd1cmU+CiAgICAgICAgICA8dD4KICAgICAgICAgICAgVGhlIGNsaWVudCBNVVNUIGlnbm9yZSB1 bnJlY29nbml6ZWQgcmVzcG9uc2UgcGFyYW1ldGVycy4gVGhlIGFjY2VzcyB0b2tlbiBzdHJpbmcg c2l6ZQogICAgICAgICAgICBpcyBsZWZ0IHVuZGVmaW5lZCBieSB0aGlzIHNwZWNpZmljYXRpb24u IFRoZSBjbGllbnQgc2hvdWxkIGF2b2lkIG1ha2luZyBhc3N1bXB0aW9ucwogICAgICAgICAgICBh Ym91dCB2YWx1ZSBzaXplcy4gVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIFNIT1VMRCBkb2N1bWVu dCB0aGUgc2l6ZSBvZiBhbnkgdmFsdWUgaXQKICAgICAgICAgICAgaXNzdWVzLgogICAgICAgICAg PC90PgoKICAgICAgICAgIDxzZWN0aW9uIHRpdGxlPSdFcnJvciBSZXNwb25zZScgYW5jaG9yPSdp bXBsaWNpdC1hdXRoei1lcnJvcic+CiAgICAgICAgICAgIDx0PgogICAgICAgICAgICAgIElmIHRo ZSByZXF1ZXN0IGZhaWxzIGR1ZSB0byBhIG1pc3NpbmcsIGludmFsaWQsIG9yIG1pc21hdGNoaW5n IHJlZGlyZWN0aW9uIFVSSSwgb3IgaWYKICAgICAgICAgICAgICB0aGUgY2xpZW50IGlkZW50aWZp ZXIgaXMgbWlzc2luZyBvciBpbnZhbGlkLCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgU0hPVUxE IGluZm9ybQogICAgICAgICAgICAgIHRoZSByZXNvdXJjZSBvd25lciBvZiB0aGUgZXJyb3IsIGFu ZCBNVVNUIE5PVCBhdXRvbWF0aWNhbGx5IHJlZGlyZWN0IHRoZSB1c2VyLWFnZW50CiAgICAgICAg ICAgICAgdG8gdGhlIGludmFsaWQgcmVkaXJlY3Rpb24gVVJJLgogICAgICAgICAgICA8L3Q+CiAg ICAgICAgICAgIDx0PgogICAgICAgICAgICAgIElmIHRoZSByZXNvdXJjZSBvd25lciBkZW5pZXMg dGhlIGFjY2VzcyByZXF1ZXN0IG9yIGlmIHRoZSByZXF1ZXN0IGZhaWxzIGZvciByZWFzb25zCiAg ICAgICAgICAgICAgb3RoZXIgdGhhbiBhIG1pc3Npbmcgb3IgaW52YWxpZCByZWRpcmVjdGlvbiBV UkksIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBpbmZvcm1zIHRoZQogICAgICAgICAgICAgIGNs aWVudCBieSBhZGRpbmcgdGhlIGZvbGxvd2luZyBwYXJhbWV0ZXJzIHRvIHRoZSBmcmFnbWVudCBj b21wb25lbnQgb2YgdGhlCiAgICAgICAgICAgICAgcmVkaXJlY3Rpb24gVVJJIHVzaW5nIHRoZQog ICAgICAgICAgICAgIDxzcGFueCBzdHlsZT0ndmVyYic+YXBwbGljYXRpb24veC13d3ctZm9ybS11 cmxlbmNvZGVkPC9zcGFueD4gZm9ybWF0OgogICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgIDx0 PgogICAgICAgICAgICAgIDxsaXN0IHN0eWxlPSdoYW5naW5nJyBoYW5nSW5kZW50PSc2Jz4KICAg ICAgICAgICAgICAgIDx0IGhhbmdUZXh0PSdlcnJvcic+CiAgICAgICAgICAgICAgICAgIDx2c3Bh Y2UgLz4KICAgICAgICAgICAgICAgICAgUkVRVUlSRUQuIEEgc2luZ2xlIEFTQ0lJIDx4cmVmIHRh cmdldD0iVVNBU0NJSSIgLz4gZXJyb3IgY29kZSBmcm9tIHRoZSBmb2xsb3dpbmc6CgogICAgICAg ICAgICAgICAgICA8bGlzdCBzdHlsZT0naGFuZ2luZycgaGFuZ0luZGVudD0nNic+CiAgICAgICAg ICAgICAgICAgICAgPHQgaGFuZ1RleHQ9J2ludmFsaWRfcmVxdWVzdCc+CiAgICAgICAgICAgICAg ICAgICAgICA8dnNwYWNlIC8+CiAgICAgICAgICAgICAgICAgICAgICBUaGUgcmVxdWVzdCBpcyBt aXNzaW5nIGEgcmVxdWlyZWQgcGFyYW1ldGVyLCBpbmNsdWRlcyBhbiBpbnZhbGlkCiAgICAgICAg ICAgICAgICAgICAgICBwYXJhbWV0ZXIgdmFsdWUsIGluY2x1ZGVzIGEgcGFyYW1ldGVyIG1vcmUg dGhhbiBvbmNlLCBvciBpcyBvdGhlcndpc2UgbWFsZm9ybWVkLgogICAgICAgICAgICAgICAgICAg IDwvdD4KICAgICAgICAgICAgICAgICAgICA8dCBoYW5nVGV4dD0ndW5hdXRob3JpemVkX2NsaWVu dCc+CiAgICAgICAgICAgICAgICAgICAgICA8dnNwYWNlIC8+CiAgICAgICAgICAgICAgICAgICAg ICBUaGUgY2xpZW50IGlzIG5vdCBhdXRob3JpemVkIHRvIHJlcXVlc3QgYW4gYWNjZXNzIHRva2Vu IHVzaW5nIHRoaXMgbWV0aG9kLgogICAgICAgICAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAg ICAgICAgICA8dCBoYW5nVGV4dD0nYWNjZXNzX2RlbmllZCc+CiAgICAgICAgICAgICAgICAgICAg ICA8dnNwYWNlIC8+CiAgICAgICAgICAgICAgICAgICAgICBUaGUgcmVzb3VyY2Ugb3duZXIgb3Ig YXV0aG9yaXphdGlvbiBzZXJ2ZXIgZGVuaWVkIHRoZSByZXF1ZXN0LgogICAgICAgICAgICAgICAg ICAgIDwvdD4KICAgICAgICAgICAgICAgICAgICA8dCBoYW5nVGV4dD0ndW5zdXBwb3J0ZWRfcmVz cG9uc2VfdHlwZSc+CiAgICAgICAgICAgICAgICAgICAgICA8dnNwYWNlIC8+CiAgICAgICAgICAg ICAgICAgICAgICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgZG9lcyBub3Qgc3VwcG9ydCBvYnRh aW5pbmcgYW4gYWNjZXNzIHRva2VuIHVzaW5nCiAgICAgICAgICAgICAgICAgICAgICB0aGlzIG1l dGhvZC4KICAgICAgICAgICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgICAgICAgICAgPHQgaGFu Z1RleHQ9J2ludmFsaWRfc2NvcGUnPgogICAgICAgICAgICAgICAgICAgICAgPHZzcGFjZSAvPgog ICAgICAgICAgICAgICAgICAgICAgVGhlIHJlcXVlc3RlZCBzY29wZSBpcyBpbnZhbGlkLCB1bmtu b3duLCBvciBtYWxmb3JtZWQuCiAgICAgICAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICAg ICAgICAgIDx0IGhhbmdUZXh0PSdzZXJ2ZXJfZXJyb3InPgogICAgICAgICAgICAgICAgICAgICAg PHZzcGFjZSAvPgogICAgICAgICAgICAgICAgICAgICAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVy IGVuY291bnRlcmVkIGFuIHVuZXhwZWN0ZWQgY29uZGl0aW9uIHdoaWNoIHByZXZlbnRlZAogICAg ICAgICAgICAgICAgICAgICAgaXQgZnJvbSBmdWxmaWxsaW5nIHRoZSByZXF1ZXN0LgogICAgICAg ICAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAgICAgICAgICA8dCBoYW5nVGV4dD0ndGVtcG9y YXJpbHlfdW5hdmFpbGFibGUnPgogICAgICAgICAgICAgICAgICAgICAgPHZzcGFjZSAvPgogICAg ICAgICAgICAgICAgICAgICAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGlzIGN1cnJlbnRseSB1 bmFibGUgdG8gaGFuZGxlIHRoZSByZXF1ZXN0IGR1ZSB0byBhCiAgICAgICAgICAgICAgICAgICAg ICB0ZW1wb3Jhcnkgb3ZlcmxvYWRpbmcgb3IgbWFpbnRlbmFuY2Ugb2YgdGhlIHNlcnZlci4KICAg ICAgICAgICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgICAgICAgIDwvbGlzdD4KCgkJICBWYWx1 ZXMgZm9yIHRoZSA8c3Bhbnggc3R5bGU9J3ZlcmInPmVycm9yPC9zcGFueD4gcGFyYW1ldGVyIE1V U1QgTk9UIGluY2x1ZGUKCQkgIGNoYXJhY3RlcnMgb3V0c2lkZSB0aGUgc2V0ICV4MjAtMjEgLyAl eDIzLTVCIC8gJXg1RC03RS4KICAgICAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAgICAgIDx0 IGhhbmdUZXh0PSdlcnJvcl9kZXNjcmlwdGlvbic+CiAgICAgICAgICAgICAgICAgIDx2c3BhY2Ug Lz4KICAgICAgICAgICAgICAgICAgT1BUSU9OQUwuIEEgaHVtYW4tcmVhZGFibGUgQVNDSUkgPHhy ZWYgdGFyZ2V0PSJVU0FTQ0lJIiAvPiB0ZXh0IHByb3ZpZGluZyBhZGRpdGlvbmFsIGluZm9ybWF0 aW9uLAogICAgICAgICAgICAgICAgICB1c2VkIHRvIGFzc2lzdCB0aGUgY2xpZW50IGRldmVsb3Bl ciBpbiB1bmRlcnN0YW5kaW5nIHRoZSBlcnJvciB0aGF0IG9jY3VycmVkLgoJCSAgPHZzcGFjZS8+ CgkJICBWYWx1ZXMgZm9yIHRoZSA8c3Bhbnggc3R5bGU9J3ZlcmInPmVycm9yX2Rlc2NyaXB0aW9u PC9zcGFueD4gcGFyYW1ldGVyIE1VU1QgTk9UIGluY2x1ZGUKCQkgIGNoYXJhY3RlcnMgb3V0c2lk ZSB0aGUgc2V0ICV4MjAtMjEgLyAleDIzLTVCIC8gJXg1RC03RS4KICAgICAgICAgICAgICAgIDwv dD4KICAgICAgICAgICAgICAgIDx0IGhhbmdUZXh0PSdlcnJvcl91cmknPgogICAgICAgICAgICAg ICAgICA8dnNwYWNlIC8+CiAgICAgICAgICAgICAgICAgIE9QVElPTkFMLiBBIFVSSSBpZGVudGlm eWluZyBhIGh1bWFuLXJlYWRhYmxlIHdlYiBwYWdlIHdpdGggaW5mb3JtYXRpb24gYWJvdXQgdGhl CiAgICAgICAgICAgICAgICAgIGVycm9yLCB1c2VkIHRvIHByb3ZpZGUgdGhlIGNsaWVudCBkZXZl bG9wZXIgd2l0aCBhZGRpdGlvbmFsIGluZm9ybWF0aW9uIGFib3V0IHRoZQogICAgICAgICAgICAg ICAgICBlcnJvci4KCQkgIDx2c3BhY2UvPgoJCSAgVmFsdWVzIGZvciB0aGUgPHNwYW54IHN0eWxl PSd2ZXJiJz5lcnJvcl91cmk8L3NwYW54PiBwYXJhbWV0ZXIKCQkgIE1VU1QgY29uZm9ybSB0byB0 aGUgVVJJLVJlZmVyZW5jZSBzeW50YXgsIGFuZCB0aHVzIE1VU1QgTk9UIGluY2x1ZGUKCQkgIGNo YXJhY3RlcnMgb3V0c2lkZSB0aGUgc2V0ICV4MjEgLyAleDIzLTVCIC8gJXg1RC03RS4KICAgICAg ICAgICAgICAgIDwvdD4KICAgICAgICAgICAgICAgIDx0IGhhbmdUZXh0PSdzdGF0ZSc+CiAgICAg ICAgICAgICAgICAgIDx2c3BhY2UgLz4KICAgICAgICAgICAgICAgICAgUkVRVUlSRUQgaWYgYSA8 c3Bhbnggc3R5bGU9J3ZlcmInPnN0YXRlPC9zcGFueD4gcGFyYW1ldGVyIHdhcyBwcmVzZW50IGlu IHRoZQogICAgICAgICAgICAgICAgICBjbGllbnQgYXV0aG9yaXphdGlvbiByZXF1ZXN0LiBUaGUg ZXhhY3QgdmFsdWUgcmVjZWl2ZWQgZnJvbSB0aGUgY2xpZW50LgogICAgICAgICAgICAgICAgPC90 PgogICAgICAgICAgICAgIDwvbGlzdD4KICAgICAgICAgICAgPC90PgogICAgICAgICAgICA8Zmln dXJlPgogICAgICAgICAgICAgIDxwcmVhbWJsZT4KICAgICAgICAgICAgICAgIEZvciBleGFtcGxl LCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgcmVkaXJlY3RzIHRoZSB1c2VyLWFnZW50IGJ5IHNl bmRpbmcgdGhlCiAgICAgICAgICAgICAgICBmb2xsb3dpbmcgSFRUUCByZXNwb25zZToKICAgICAg ICAgICAgICA8L3ByZWFtYmxlPgogICAgICAgICAgICAgIDxhcnR3b3JrPgogICAgICAgICAgICAg ICAgPCFbQ0RBVEFbCiAgSFRUUC8xLjEgMzAyIEZvdW5kCiAgTG9jYXRpb246IGh0dHBzOi8vY2xp ZW50LmV4YW1wbGUuY29tL2NiI2Vycm9yPWFjY2Vzc19kZW5pZWQmc3RhdGU9eHl6Cl1dPgogICAg ICAgICAgICAgIDwvYXJ0d29yaz4KICAgICAgICAgICAgPC9maWd1cmU+CiAgICAgICAgICA8L3Nl Y3Rpb24+CgogICAgICAgIDwvc2VjdGlvbj4KCiAgICAgIDwvc2VjdGlvbj4KCiAgICAgIDxzZWN0 aW9uIHRpdGxlPSdSZXNvdXJjZSBPd25lciBQYXNzd29yZCBDcmVkZW50aWFscyBHcmFudCcgYW5j aG9yPSdncmFudC1wYXNzd29yZCc+CiAgICAgICAgPHQ+CiAgICAgICAgICBUaGUgcmVzb3VyY2Ug b3duZXIgcGFzc3dvcmQgY3JlZGVudGlhbHMgZ3JhbnQgdHlwZSBpcyBzdWl0YWJsZSBpbiBjYXNl cyB3aGVyZSB0aGUKICAgICAgICAgIHJlc291cmNlIG93bmVyIGhhcyBhIHRydXN0IHJlbGF0aW9u c2hpcCB3aXRoIHRoZSBjbGllbnQsIHN1Y2ggYXMgdGhlIGRldmljZSBvcGVyYXRpbmcKICAgICAg ICAgIHN5c3RlbSBvciBhIGhpZ2hseSBwcml2aWxlZ2VkIGFwcGxpY2F0aW9uLiBUaGUgYXV0aG9y aXphdGlvbiBzZXJ2ZXIgc2hvdWxkIHRha2Ugc3BlY2lhbAogICAgICAgICAgY2FyZSB3aGVuIGVu YWJsaW5nIHRoaXMgZ3JhbnQgdHlwZSwgYW5kIG9ubHkgYWxsb3cgaXQgd2hlbiBvdGhlciBmbG93 cyBhcmUgbm90IHZpYWJsZS4KICAgICAgICA8L3Q+CiAgICAgICAgPHQ+CiAgICAgICAgICBUaGUg Z3JhbnQgdHlwZSBpcyBzdWl0YWJsZSBmb3IgY2xpZW50cyBjYXBhYmxlIG9mIG9idGFpbmluZyB0 aGUgcmVzb3VyY2Ugb3duZXIncwogICAgICAgICAgY3JlZGVudGlhbHMgKHVzZXJuYW1lIGFuZCBw YXNzd29yZCwgdHlwaWNhbGx5IHVzaW5nIGFuIGludGVyYWN0aXZlIGZvcm0pLiBJdCBpcyBhbHNv IHVzZWQKICAgICAgICAgIHRvIG1pZ3JhdGUgZXhpc3RpbmcgY2xpZW50cyB1c2luZyBkaXJlY3Qg YXV0aGVudGljYXRpb24gc2NoZW1lcyBzdWNoIGFzIEhUVFAgQmFzaWMgb3IKICAgICAgICAgIERp Z2VzdCBhdXRoZW50aWNhdGlvbiB0byBPQXV0aCBieSBjb252ZXJ0aW5nIHRoZSBzdG9yZWQgY3Jl ZGVudGlhbHMgdG8gYW4gYWNjZXNzIHRva2VuLgogICAgICAgIDwvdD4KICAgICAgICA8ZmlndXJl IHRpdGxlPSdSZXNvdXJjZSBPd25lciBQYXNzd29yZCBDcmVkZW50aWFscyBGbG93JyBhbmNob3I9 J0ZpZ3VyZS01Jz4KICAgICAgICAgIDxhcnR3b3JrPgogICAgICAgICAgICA8IVtDREFUQVsKICAr LS0tLS0tLS0tLSsKICB8IFJlc291cmNlIHwKICB8ICBPd25lciAgIHwKICB8ICAgICAgICAgIHwK ICArLS0tLS0tLS0tLSsKICAgICAgIHYKICAgICAgIHwgICAgUmVzb3VyY2UgT3duZXIKICAgICAg KEEpIFBhc3N3b3JkIENyZWRlbnRpYWxzCiAgICAgICB8CiAgICAgICB2CiAgKy0tLS0tLS0tLSsg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLSsKICB8ICAg ICAgICAgfD4tLShCKS0tLS0gUmVzb3VyY2UgT3duZXIgLS0tLS0tLT58ICAgICAgICAgICAgICAg fAogIHwgICAgICAgICB8ICAgICAgICAgUGFzc3dvcmQgQ3JlZGVudGlhbHMgICAgIHwgQXV0aG9y aXphdGlvbiB8CiAgfCBDbGllbnQgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg fCAgICAgU2VydmVyICAgIHwKICB8ICAgICAgICAgfDwtLShDKS0tLS0gQWNjZXNzIFRva2VuIC0t LS0tLS0tLTx8ICAgICAgICAgICAgICAgfAogIHwgICAgICAgICB8ICAgICh3LyBPcHRpb25hbCBS ZWZyZXNoIFRva2VuKSAgIHwgICAgICAgICAgICAgICB8CiAgKy0tLS0tLS0tLSsgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLSsKXV0+CiAgICAgICAgICA8 L2FydHdvcms+CiAgICAgICAgPC9maWd1cmU+CiAgICAgICAgPHQ+CiAgICAgICAgICBUaGUgZmxv dyBpbGx1c3RyYXRlZCBpbiA8eHJlZiB0YXJnZXQ9J0ZpZ3VyZS01JyAvPiBpbmNsdWRlcyB0aGUg Zm9sbG93aW5nIHN0ZXBzOgogICAgICAgIDwvdD4KICAgICAgICA8dD4KICAgICAgICAgIDxsaXN0 IHN0eWxlPSdmb3JtYXQgKCVDKSc+CiAgICAgICAgICAgIDx0PgogICAgICAgICAgICAgIFRoZSBy ZXNvdXJjZSBvd25lciBwcm92aWRlcyB0aGUgY2xpZW50IHdpdGggaXRzIHVzZXJuYW1lIGFuZCBw YXNzd29yZC4KICAgICAgICAgICAgPC90PgogICAgICAgICAgICA8dD4KICAgICAgICAgICAgICBU aGUgY2xpZW50IHJlcXVlc3RzIGFuIGFjY2VzcyB0b2tlbiBmcm9tIHRoZSBhdXRob3JpemF0aW9u IHNlcnZlcidzIHRva2VuIGVuZHBvaW50IGJ5CiAgICAgICAgICAgICAgaW5jbHVkaW5nIHRoZSBj cmVkZW50aWFscyByZWNlaXZlZCBmcm9tIHRoZSByZXNvdXJjZSBvd25lci4gV2hlbiBtYWtpbmcg dGhlIHJlcXVlc3QsCiAgICAgICAgICAgICAgdGhlIGNsaWVudCBhdXRoZW50aWNhdGVzIHdpdGgg dGhlIGF1dGhvcml6YXRpb24gc2VydmVyLgogICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgIDx0 PgogICAgICAgICAgICAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBhdXRoZW50aWNhdGVzIHRo ZSBjbGllbnQgYW5kIHZhbGlkYXRlcyB0aGUgcmVzb3VyY2Ugb3duZXIKICAgICAgICAgICAgICBj cmVkZW50aWFscywgYW5kIGlmIHZhbGlkIGlzc3VlcyBhbiBhY2Nlc3MgdG9rZW4uCiAgICAgICAg ICAgIDwvdD4KICAgICAgICAgIDwvbGlzdD4KICAgICAgICA8L3Q+CgogICAgICAgIDxzZWN0aW9u IHRpdGxlPSdBdXRob3JpemF0aW9uIFJlcXVlc3QgYW5kIFJlc3BvbnNlJz4KICAgICAgICAgIDx0 PgogICAgICAgICAgICBUaGUgbWV0aG9kIHRocm91Z2ggd2hpY2ggdGhlIGNsaWVudCBvYnRhaW5z IHRoZSByZXNvdXJjZSBvd25lciBjcmVkZW50aWFscyBpcyBiZXlvbmQKICAgICAgICAgICAgdGhl IHNjb3BlIG9mIHRoaXMgc3BlY2lmaWNhdGlvbi4gVGhlIGNsaWVudCBNVVNUIGRpc2NhcmQgdGhl IGNyZWRlbnRpYWxzIG9uY2UgYW4gYWNjZXNzCiAgICAgICAgICAgIHRva2VuIGhhcyBiZWVuIG9i dGFpbmVkLgogICAgICAgICAgPC90PgogICAgICAgIDwvc2VjdGlvbj4KCiAgICAgICAgPHNlY3Rp b24gdGl0bGU9J0FjY2VzcyBUb2tlbiBSZXF1ZXN0JyBhbmNob3I9InBhc3N3b3JkLXRvay1yZXEi PgogICAgICAgICAgPHQ+CiAgICAgICAgICAgIFRoZSBjbGllbnQgbWFrZXMgYSByZXF1ZXN0IHRv IHRoZSB0b2tlbiBlbmRwb2ludCBieSBhZGRpbmcgdGhlIGZvbGxvd2luZyBwYXJhbWV0ZXJzCiAg ICAgICAgICAgIHVzaW5nIHRoZSA8c3Bhbnggc3R5bGU9J3ZlcmInPmFwcGxpY2F0aW9uL3gtd3d3 LWZvcm0tdXJsZW5jb2RlZDwvc3Bhbng+IGZvcm1hdCBpbiB0aGUKICAgICAgICAgICAgSFRUUCBy ZXF1ZXN0IGVudGl0eS1ib2R5OgogICAgICAgICAgPC90PgogICAgICAgICAgPHQ+CiAgICAgICAg ICAgIDxsaXN0IHN0eWxlPSdoYW5naW5nJyBoYW5nSW5kZW50PSc2Jz4KICAgICAgICAgICAgICA8 dCBoYW5nVGV4dD0nZ3JhbnRfdHlwZSc+CiAgICAgICAgICAgICAgICA8dnNwYWNlIC8+CiAgICAg ICAgICAgICAgICBSRVFVSVJFRC4gVmFsdWUgTVVTVCBiZSBzZXQgdG8gPHNwYW54IHN0eWxlPSd2 ZXJiJz5wYXNzd29yZDwvc3Bhbng+LgogICAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAgICA8 dCBoYW5nVGV4dD0ndXNlcm5hbWUnPgogICAgICAgICAgICAgICAgPHZzcGFjZSAvPgogICAgICAg ICAgICAgICAgUkVRVUlSRUQuIFRoZSByZXNvdXJjZSBvd25lciB1c2VybmFtZSwgZW5jb2RlZCBh cyBVVEYtOC4KICAgICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgICAgPHQgaGFuZ1RleHQ9J3Bh c3N3b3JkJz4KICAgICAgICAgICAgICAgIDx2c3BhY2UgLz4KICAgICAgICAgICAgICAgIFJFUVVJ UkVELiBUaGUgcmVzb3VyY2Ugb3duZXIgcGFzc3dvcmQsIGVuY29kZWQgYXMgVVRGLTguCiAgICAg ICAgICAgICAgPC90PgogICAgICAgICAgICAgIDx0IGhhbmdUZXh0PSdzY29wZSc+CiAgICAgICAg ICAgICAgICA8dnNwYWNlIC8+CiAgICAgICAgICAgICAgICBPUFRJT05BTC4gVGhlIHNjb3BlIG9m IHRoZSBhY2Nlc3MgcmVxdWVzdCBhcyBkZXNjcmliZWQgYnkgPHhyZWYgdGFyZ2V0PSdzY29wZScg Lz4uCiAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICA8L2xpc3Q+CiAgICAgICAgICA8L3Q+ CiAgICAgICAgICA8dD4KICAgICAgICAgICAgSWYgdGhlIGNsaWVudCB0eXBlIGlzIGNvbmZpZGVu dGlhbCBvciB0aGUgY2xpZW50IHdhcyBpc3N1ZWQgY2xpZW50IGNyZWRlbnRpYWxzIChvcgogICAg ICAgICAgICBhc3NpZ25lZCBvdGhlciBhdXRoZW50aWNhdGlvbiByZXF1aXJlbWVudHMpLCB0aGUg Y2xpZW50IE1VU1QgYXV0aGVudGljYXRlIHdpdGggdGhlCiAgICAgICAgICAgIGF1dGhvcml6YXRp b24gc2VydmVyIGFzIGRlc2NyaWJlZCBpbiA8eHJlZiB0YXJnZXQ9J3Rva2VuLWVuZHBvaW50LWF1 dGgnIC8+LgogICAgICAgICAgPC90PgogICAgICAgICAgPGZpZ3VyZT4KICAgICAgICAgICAgPHBy ZWFtYmxlPgogICAgICAgICAgICAgIEZvciBleGFtcGxlLCB0aGUgY2xpZW50IG1ha2VzIHRoZSBm b2xsb3dpbmcgSFRUUCByZXF1ZXN0IHVzaW5nIHRyYW5zcG9ydC1sYXllcgogICAgICAgICAgICAg IHNlY3VyaXR5IChleHRyYSBsaW5lIGJyZWFrcyBhcmUgZm9yIGRpc3BsYXkgcHVycG9zZXMgb25s eSk6CiAgICAgICAgICAgIDwvcHJlYW1ibGU+CiAgICAgICAgICAgIDxhcnR3b3JrPgogICAgICAg ICAgICAgIDwhW0NEQVRBWwogIFBPU1QgL3Rva2VuIEhUVFAvMS4xCiAgSG9zdDogc2VydmVyLmV4 YW1wbGUuY29tCiAgQXV0aG9yaXphdGlvbjogQmFzaWMgY3paQ2FHUlNhM0YwTXpwbldERm1RbUYw TTJKVwogIENvbnRlbnQtVHlwZTogYXBwbGljYXRpb24veC13d3ctZm9ybS11cmxlbmNvZGVkO2No YXJzZXQ9VVRGLTgKICAKICBncmFudF90eXBlPXBhc3N3b3JkJnVzZXJuYW1lPWpvaG5kb2UmcGFz c3dvcmQ9QTNkZGozdwpdXT4KICAgICAgICAgICAgPC9hcnR3b3JrPgogICAgICAgICAgPC9maWd1 cmU+CiAgICAgICAgICA8dD4KICAgICAgICAgICAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIE1V U1Q6CiAgICAgICAgICA8L3Q+CiAgICAgICAgICA8dD4KICAgICAgICAgICAgPGxpc3Qgc3R5bGU9 J3N5bWJvbHMnPgogICAgICAgICAgICAgIDx0PgogICAgICAgICAgICAgICAgcmVxdWlyZSBjbGll bnQgYXV0aGVudGljYXRpb24gZm9yIGNvbmZpZGVudGlhbCBjbGllbnRzIG9yIGZvciBhbnkgY2xp ZW50IHRoYXQgd2FzCiAgICAgICAgICAgICAgICBpc3N1ZWQgY2xpZW50IGNyZWRlbnRpYWxzIChv ciB3aXRoIG90aGVyIGF1dGhlbnRpY2F0aW9uIHJlcXVpcmVtZW50cyksCiAgICAgICAgICAgICAg PC90PgogICAgICAgICAgICAgIDx0PgogICAgICAgICAgICAgICAgYXV0aGVudGljYXRlIHRoZSBj bGllbnQgaWYgY2xpZW50IGF1dGhlbnRpY2F0aW9uIGlzIGluY2x1ZGVkLCBhbmQKICAgICAgICAg ICAgICA8L3Q+CiAgICAgICAgICAgICAgPHQ+CiAgICAgICAgICAgICAgICB2YWxpZGF0ZSB0aGUg cmVzb3VyY2Ugb3duZXIgcGFzc3dvcmQgY3JlZGVudGlhbHMgdXNpbmcgaXRzIGV4aXN0aW5nIHBh c3N3b3JkCiAgICAgICAgICAgICAgICB2YWxpZGF0aW9uIGFsZ29yaXRobS4KICAgICAgICAgICAg ICA8L3Q+CiAgICAgICAgICAgIDwvbGlzdD4KICAgICAgICAgIDwvdD4KICAgICAgICAgIDx0Pgog ICAgICAgICAgICBTaW5jZSB0aGlzIGFjY2VzcyB0b2tlbiByZXF1ZXN0IHV0aWxpemVzIHRoZSBy ZXNvdXJjZSBvd25lcidzIHBhc3N3b3JkLCB0aGUKICAgICAgICAgICAgYXV0aG9yaXphdGlvbiBz ZXJ2ZXIgTVVTVCBwcm90ZWN0IHRoZSBlbmRwb2ludCBhZ2FpbnN0IGJydXRlIGZvcmNlIGF0dGFj a3MgKGUuZy4gdXNpbmcKICAgICAgICAgICAgcmF0ZS1saW1pdGF0aW9uIG9yIGdlbmVyYXRpbmcg YWxlcnRzKS4KICAgICAgICAgIDwvdD4KICAgICAgICA8L3NlY3Rpb24+CgogICAgICAgIDxzZWN0 aW9uIHRpdGxlPSdBY2Nlc3MgVG9rZW4gUmVzcG9uc2UnPgogICAgICAgICAgPHQ+CiAgICAgICAg ICAgIElmIHRoZSBhY2Nlc3MgdG9rZW4gcmVxdWVzdCBpcyB2YWxpZCBhbmQgYXV0aG9yaXplZCwg dGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGlzc3VlcyBhbgogICAgICAgICAgICBhY2Nlc3MgdG9r ZW4gYW5kIG9wdGlvbmFsIHJlZnJlc2ggdG9rZW4gYXMgZGVzY3JpYmVkIGluIDx4cmVmIHRhcmdl dD0ndG9rZW4tcmVzcG9uc2UnIC8+LgogICAgICAgICAgICBJZiB0aGUgcmVxdWVzdCBmYWlsZWQg Y2xpZW50IGF1dGhlbnRpY2F0aW9uIG9yIGlzIGludmFsaWQsIHRoZSBhdXRob3JpemF0aW9uIHNl cnZlciByZXR1cm5zCiAgICAgICAgICAgIGFuIGVycm9yIHJlc3BvbnNlIGFzIGRlc2NyaWJlZCBp biA8eHJlZiB0YXJnZXQ9J3Rva2VuLWVycm9ycycgLz4uCiAgICAgICAgICA8L3Q+CiAgICAgICAg ICA8ZmlndXJlPgogICAgICAgICAgICA8cHJlYW1ibGU+CiAgICAgICAgICAgICAgQW4gZXhhbXBs ZSBzdWNjZXNzZnVsIHJlc3BvbnNlOgogICAgICAgICAgICA8L3ByZWFtYmxlPgogICAgICAgICAg ICA8YXJ0d29yaz4KICAgICAgICAgICAgICA8IVtDREFUQVsKICBIVFRQLzEuMSAyMDAgT0sKICBD b250ZW50LVR5cGU6IGFwcGxpY2F0aW9uL2pzb247Y2hhcnNldD1VVEYtOAogIENhY2hlLUNvbnRy b2w6IG5vLXN0b3JlCiAgUHJhZ21hOiBuby1jYWNoZQoKICB7CiAgICAiYWNjZXNzX3Rva2VuIjoi MllvdG5GWkZFanIxekNzaWNNV3BBQSIsCiAgICAidG9rZW5fdHlwZSI6ImV4YW1wbGUiLAogICAg ImV4cGlyZXNfaW4iOjM2MDAsCiAgICAicmVmcmVzaF90b2tlbiI6InRHenYzSk9rRjBYRzVReDJU bEtXSUEiLAogICAgImV4YW1wbGVfcGFyYW1ldGVyIjoiZXhhbXBsZV92YWx1ZSIKICB9Cl1dPgog ICAgICAgICAgICA8L2FydHdvcms+CiAgICAgICAgICA8L2ZpZ3VyZT4KICAgICAgICA8L3NlY3Rp b24+CgogICAgICA8L3NlY3Rpb24+CgogICAgICA8c2VjdGlvbiB0aXRsZT0nQ2xpZW50IENyZWRl bnRpYWxzIEdyYW50JyBhbmNob3I9J2dyYW50LWNsaWVudCc+CiAgICAgICAgPHQ+CiAgICAgICAg ICBUaGUgY2xpZW50IGNhbiByZXF1ZXN0IGFuIGFjY2VzcyB0b2tlbiB1c2luZyBvbmx5IGl0cyBj bGllbnQgY3JlZGVudGlhbHMgKG9yIG90aGVyCiAgICAgICAgICBzdXBwb3J0ZWQgbWVhbnMgb2Yg YXV0aGVudGljYXRpb24pIHdoZW4gdGhlIGNsaWVudCBpcyByZXF1ZXN0aW5nIGFjY2VzcyB0byB0 aGUKICAgICAgICAgIHByb3RlY3RlZCByZXNvdXJjZXMgdW5kZXIgaXRzIGNvbnRyb2wsIG9yIHRo b3NlIG9mIGFub3RoZXIgcmVzb3VyY2Ugb3duZXIgd2hpY2ggaGFzIGJlZW4KICAgICAgICAgIHBy ZXZpb3VzbHkgYXJyYW5nZWQgd2l0aCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgKHRoZSBtZXRo b2Qgb2Ygd2hpY2ggaXMgYmV5b25kIHRoZQogICAgICAgICAgc2NvcGUgb2YgdGhpcyBzcGVjaWZp Y2F0aW9uKS4KICAgICAgICA8L3Q+CiAgICAgICAgPHQ+CiAgICAgICAgICBUaGUgY2xpZW50IGNy ZWRlbnRpYWxzIGdyYW50IHR5cGUgTVVTVCBvbmx5IGJlIHVzZWQgYnkgY29uZmlkZW50aWFsIGNs aWVudHMuCiAgICAgICAgPC90PgogICAgICAgIDxmaWd1cmUgdGl0bGU9J0NsaWVudCBDcmVkZW50 aWFscyBGbG93JyBhbmNob3I9J0ZpZ3VyZS02Jz4KICAgICAgICAgIDxhcnR3b3JrPgogICAgICAg ICAgICA8IVtDREFUQVsKICArLS0tLS0tLS0tKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICArLS0tLS0tLS0tLS0tLS0tKwogIHwgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHwgICAgICAgICAgICAgICB8CiAgfCAgICAgICAgIHw+LS0oQSktIENsaWVu dCBBdXRoZW50aWNhdGlvbiAtLS0+fCBBdXRob3JpemF0aW9uIHwKICB8IENsaWVudCAgfCAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICBTZXJ2ZXIgICAgfAogIHwgICAgICAg ICB8PC0tKEIpLS0tLSBBY2Nlc3MgVG9rZW4gLS0tLS0tLS0tPHwgICAgICAgICAgICAgICB8CiAg fCAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAg ICAgIHwKICArLS0tLS0tLS0tKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0t LS0tLS0tLS0tLS0tKwpdXT4KICAgICAgICAgIDwvYXJ0d29yaz4KICAgICAgICA8L2ZpZ3VyZT4K ICAgICAgICA8dD4KICAgICAgICAgIFRoZSBmbG93IGlsbHVzdHJhdGVkIGluIDx4cmVmIHRhcmdl dD0nRmlndXJlLTYnIC8+IGluY2x1ZGVzIHRoZSBmb2xsb3dpbmcgc3RlcHM6CiAgICAgICAgPC90 PgogICAgICAgIDx0PgogICAgICAgICAgPGxpc3Qgc3R5bGU9J2Zvcm1hdCAoJUMpJz4KICAgICAg ICAgICAgPHQ+CiAgICAgICAgICAgICAgVGhlIGNsaWVudCBhdXRoZW50aWNhdGVzIHdpdGggdGhl IGF1dGhvcml6YXRpb24gc2VydmVyIGFuZCByZXF1ZXN0cyBhbiBhY2Nlc3MgdG9rZW4KICAgICAg ICAgICAgICBmcm9tIHRoZSB0b2tlbiBlbmRwb2ludC4KICAgICAgICAgICAgPC90PgogICAgICAg ICAgICA8dD4KICAgICAgICAgICAgICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYXV0aGVudGlj YXRlcyB0aGUgY2xpZW50LCBhbmQgaWYgdmFsaWQgaXNzdWVzIGFuIGFjY2VzcwogICAgICAgICAg ICAgIHRva2VuLgogICAgICAgICAgICA8L3Q+CiAgICAgICAgICA8L2xpc3Q+CiAgICAgICAgPC90 PgoKICAgICAgICA8c2VjdGlvbiB0aXRsZT0nQXV0aG9yaXphdGlvbiBSZXF1ZXN0IGFuZCBSZXNw b25zZSc+CiAgICAgICAgICA8dD4KICAgICAgICAgICAgU2luY2UgdGhlIGNsaWVudCBhdXRoZW50 aWNhdGlvbiBpcyB1c2VkIGFzIHRoZSBhdXRob3JpemF0aW9uIGdyYW50LCBubyBhZGRpdGlvbmFs CiAgICAgICAgICAgIGF1dGhvcml6YXRpb24gcmVxdWVzdCBpcyBuZWVkZWQuCiAgICAgICAgICA8 L3Q+CiAgICAgICAgPC9zZWN0aW9uPgoKICAgICAgICA8c2VjdGlvbiB0aXRsZT0nQWNjZXNzIFRv a2VuIFJlcXVlc3QnIGFuY2hvcj0iY2xpZW50LXJlcSI+CiAgICAgICAgICA8dD4KICAgICAgICAg ICAgVGhlIGNsaWVudCBtYWtlcyBhIHJlcXVlc3QgdG8gdGhlIHRva2VuIGVuZHBvaW50IGJ5IGFk ZGluZyB0aGUgZm9sbG93aW5nIHBhcmFtZXRlcnMKICAgICAgICAgICAgdXNpbmcgdGhlIDxzcGFu eCBzdHlsZT0ndmVyYic+YXBwbGljYXRpb24veC13d3ctZm9ybS11cmxlbmNvZGVkPC9zcGFueD4g Zm9ybWF0IGluIHRoZQogICAgICAgICAgICBIVFRQIHJlcXVlc3QgZW50aXR5LWJvZHk6CiAgICAg ICAgICA8L3Q+CiAgICAgICAgICA8dD4KICAgICAgICAgICAgPGxpc3Qgc3R5bGU9J2hhbmdpbmcn IGhhbmdJbmRlbnQ9JzYnPgogICAgICAgICAgICAgIDx0IGhhbmdUZXh0PSdncmFudF90eXBlJz4K ICAgICAgICAgICAgICAgIDx2c3BhY2UgLz4KICAgICAgICAgICAgICAgIFJFUVVJUkVELiBWYWx1 ZSBNVVNUIGJlIHNldCB0byA8c3Bhbnggc3R5bGU9J3ZlcmInPmNsaWVudF9jcmVkZW50aWFsczwv c3Bhbng+LgogICAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAgICA8dCBoYW5nVGV4dD0nc2Nv cGUnPgogICAgICAgICAgICAgICAgPHZzcGFjZSAvPgogICAgICAgICAgICAgICAgT1BUSU9OQUwu IFRoZSBzY29wZSBvZiB0aGUgYWNjZXNzIHJlcXVlc3QgYXMgZGVzY3JpYmVkIGJ5IDx4cmVmIHRh cmdldD0nc2NvcGUnIC8+LgogICAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAgPC9saXN0Pgog ICAgICAgICAgPC90PgogICAgICAgICAgPHQ+CiAgICAgICAgICAgIFRoZSBjbGllbnQgTVVTVCBh dXRoZW50aWNhdGUgd2l0aCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYXMgZGVzY3JpYmVkIGlu CiAgICAgICAgICAgIDx4cmVmIHRhcmdldD0ndG9rZW4tZW5kcG9pbnQtYXV0aCcgLz4uCiAgICAg ICAgICA8L3Q+CiAgICAgICAgICA8ZmlndXJlPgogICAgICAgICAgICA8cHJlYW1ibGU+CiAgICAg ICAgICAgICAgRm9yIGV4YW1wbGUsIHRoZSBjbGllbnQgbWFrZXMgdGhlIGZvbGxvd2luZyBIVFRQ IHJlcXVlc3QgdXNpbmcgdHJhbnNwb3J0LWxheWVyCiAgICAgICAgICAgICAgc2VjdXJpdHkgKGV4 dHJhIGxpbmUgYnJlYWtzIGFyZSBmb3IgZGlzcGxheSBwdXJwb3NlcyBvbmx5KToKICAgICAgICAg ICAgPC9wcmVhbWJsZT4KICAgICAgICAgICAgPGFydHdvcms+CiAgICAgICAgICAgICAgPCFbQ0RB VEFbCiAgUE9TVCAvdG9rZW4gSFRUUC8xLjEKICBIb3N0OiBzZXJ2ZXIuZXhhbXBsZS5jb20KICBB dXRob3JpemF0aW9uOiBCYXNpYyBjelpDYUdSU2EzRjBNenBuV0RGbVFtRjBNMkpXCiAgQ29udGVu dC1UeXBlOiBhcHBsaWNhdGlvbi94LXd3dy1mb3JtLXVybGVuY29kZWQ7Y2hhcnNldD1VVEYtOAog IAogIGdyYW50X3R5cGU9Y2xpZW50X2NyZWRlbnRpYWxzCl1dPgogICAgICAgICAgICA8L2FydHdv cms+CiAgICAgICAgICA8L2ZpZ3VyZT4KICAgICAgICAgIDx0PgogICAgICAgICAgICBUaGUgYXV0 aG9yaXphdGlvbiBzZXJ2ZXIgTVVTVCBhdXRoZW50aWNhdGUgdGhlIGNsaWVudC4KICAgICAgICAg IDwvdD4KICAgICAgICA8L3NlY3Rpb24+CgogICAgICAgIDxzZWN0aW9uIHRpdGxlPSdBY2Nlc3Mg VG9rZW4gUmVzcG9uc2UnPgogICAgICAgICAgPHQ+CiAgICAgICAgICAgIElmIHRoZSBhY2Nlc3Mg dG9rZW4gcmVxdWVzdCBpcyB2YWxpZCBhbmQgYXV0aG9yaXplZCwgdGhlIGF1dGhvcml6YXRpb24g c2VydmVyIGlzc3VlcyBhbgogICAgICAgICAgICBhY2Nlc3MgdG9rZW4gYXMgZGVzY3JpYmVkIGlu IDx4cmVmIHRhcmdldD0ndG9rZW4tcmVzcG9uc2UnIC8+LiBBIHJlZnJlc2ggdG9rZW4gU0hPVUxE CiAgICAgICAgICAgIE5PVCBiZSBpbmNsdWRlZC4gSWYgdGhlIHJlcXVlc3QgZmFpbGVkIGNsaWVu dCBhdXRoZW50aWNhdGlvbiBvciBpcyBpbnZhbGlkLCB0aGUKICAgICAgICAgICAgYXV0aG9yaXph dGlvbiBzZXJ2ZXIgcmV0dXJucyBhbiBlcnJvciByZXNwb25zZSBhcyBkZXNjcmliZWQgaW4KICAg ICAgICAgICAgPHhyZWYgdGFyZ2V0PSd0b2tlbi1lcnJvcnMnIC8+LgogICAgICAgICAgPC90Pgog ICAgICAgICAgPGZpZ3VyZT4KICAgICAgICAgICAgPHByZWFtYmxlPgogICAgICAgICAgICAgIEFu IGV4YW1wbGUgc3VjY2Vzc2Z1bCByZXNwb25zZToKICAgICAgICAgICAgPC9wcmVhbWJsZT4KICAg ICAgICAgICAgPGFydHdvcms+CiAgICAgICAgICAgICAgPCFbQ0RBVEFbCiAgSFRUUC8xLjEgMjAw IE9LCiAgQ29udGVudC1UeXBlOiBhcHBsaWNhdGlvbi9qc29uO2NoYXJzZXQ9VVRGLTgKICBDYWNo ZS1Db250cm9sOiBuby1zdG9yZQogIFByYWdtYTogbm8tY2FjaGUKICAKICB7CiAgICAiYWNjZXNz X3Rva2VuIjoiMllvdG5GWkZFanIxekNzaWNNV3BBQSIsCiAgICAidG9rZW5fdHlwZSI6ImV4YW1w bGUiLAogICAgImV4cGlyZXNfaW4iOjM2MDAsCiAgICAiZXhhbXBsZV9wYXJhbWV0ZXIiOiJleGFt cGxlX3ZhbHVlIgogIH0KXV0+CiAgICAgICAgICAgIDwvYXJ0d29yaz4KICAgICAgICAgIDwvZmln dXJlPgogICAgICAgIDwvc2VjdGlvbj4KCiAgICAgIDwvc2VjdGlvbj4KCiAgICAgIDxzZWN0aW9u IHRpdGxlPSdFeHRlbnNpb24gR3JhbnRzJyBhbmNob3I9ImV4dC1ncmFudCI+CiAgICAgICAgPHQ+ CiAgICAgICAgICBUaGUgY2xpZW50IHVzZXMgYW4gZXh0ZW5zaW9uIGdyYW50IHR5cGUgYnkgc3Bl Y2lmeWluZyB0aGUgZ3JhbnQgdHlwZSB1c2luZyBhbgogICAgICAgICAgYWJzb2x1dGUgVVJJIChk ZWZpbmVkIGJ5IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlcikgYXMgdGhlIHZhbHVlIG9mIHRoZQog ICAgICAgICAgPHNwYW54IHN0eWxlPSd2ZXJiJz5ncmFudF90eXBlPC9zcGFueD4gcGFyYW1ldGVy IG9mIHRoZSB0b2tlbiBlbmRwb2ludCwgYW5kIGJ5CiAgICAgICAgICBhZGRpbmcgYW55IGFkZGl0 aW9uYWwgcGFyYW1ldGVycyBuZWNlc3NhcnkuCiAgICAgICAgPC90PgogICAgICAgIDxmaWd1cmU+ CiAgICAgICAgICA8cHJlYW1ibGU+CiAgICAgICAgICAgIEZvciBleGFtcGxlLCB0byByZXF1ZXN0 IGFuIGFjY2VzcyB0b2tlbiB1c2luZyBhIFNBTUwgMi4wIGFzc2VydGlvbiBncmFudCB0eXBlIGFz CiAgICAgICAgICAgIGRlZmluZWQgYnkgPHhyZWYgdGFyZ2V0PSdJLUQuaWV0Zi1vYXV0aC1zYW1s Mi1iZWFyZXInIC8+LCB0aGUgY2xpZW50IG1ha2VzIHRoZQogICAgICAgICAgICBmb2xsb3dpbmcg SFRUUCByZXF1ZXN0IHVzaW5nIFRMUyAobGluZSBicmVha3MgYXJlIGZvciBkaXNwbGF5IHB1cnBv c2VzIG9ubHkpOgogICAgICAgICAgPC9wcmVhbWJsZT4KICAgICAgICAgIDxhcnR3b3JrPgogICAg ICAgICAgICA8IVtDREFUQVsKICBQT1NUIC90b2tlbiBIVFRQLzEuMQogIEhvc3Q6IHNlcnZlci5l eGFtcGxlLmNvbQogIENvbnRlbnQtVHlwZTogYXBwbGljYXRpb24veC13d3ctZm9ybS11cmxlbmNv ZGVkO2NoYXJzZXQ9VVRGLTgKCiAgZ3JhbnRfdHlwZT11cm4lM0FpZXRmJTNBcGFyYW1zJTNBb2F1 dGglM0FncmFudC10eXBlJTNBc2FtbDItCiAgYmVhcmVyJmFzc2VydGlvbj1QRUZ6YzJWeWRHbHZi aUJKYzNOMVpVbHVjM1JoYm5ROUlqSXdNVEV0TURVCiAgWy4uLm9taXR0ZWQgZm9yIGJyZXZpdHku Li5dYUc1VGRHRjBaVzFsYm5RLVBDOUJjM05sY25ScGIyNC0KXV0+CiAgICAgICAgICA8L2FydHdv cms+CiAgICAgICAgPC9maWd1cmU+CiAgICAgICAgPHQ+CiAgICAgICAgICBJZiB0aGUgYWNjZXNz IHRva2VuIHJlcXVlc3QgaXMgdmFsaWQgYW5kIGF1dGhvcml6ZWQsIHRoZSBhdXRob3JpemF0aW9u IHNlcnZlciBpc3N1ZXMgYW4KICAgICAgICAgIGFjY2VzcyB0b2tlbiBhbmQgb3B0aW9uYWwgcmVm cmVzaCB0b2tlbiBhcyBkZXNjcmliZWQgaW4gPHhyZWYgdGFyZ2V0PSd0b2tlbi1yZXNwb25zZScg Lz4uCiAgICAgICAgICBJZiB0aGUgcmVxdWVzdCBmYWlsZWQgY2xpZW50IGF1dGhlbnRpY2F0aW9u IG9yIGlzIGludmFsaWQsIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciByZXR1cm5zCiAgICAgICAg ICBhbiBlcnJvciByZXNwb25zZSBhcyBkZXNjcmliZWQgaW4gPHhyZWYgdGFyZ2V0PSd0b2tlbi1l cnJvcnMnIC8+LgogICAgICAgIDwvdD4KICAgICAgPC9zZWN0aW9uPgoKICAgIDwvc2VjdGlvbj4K CiAgICA8c2VjdGlvbiB0aXRsZT0nSXNzdWluZyBhbiBBY2Nlc3MgVG9rZW4nIGFuY2hvcj0ndG9r ZW4taXNzdWUnPgogICAgICA8dD4KICAgICAgICBJZiB0aGUgYWNjZXNzIHRva2VuIHJlcXVlc3Qg aXMgdmFsaWQgYW5kIGF1dGhvcml6ZWQsIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBpc3N1ZXMg YW4KICAgICAgICBhY2Nlc3MgdG9rZW4gYW5kIG9wdGlvbmFsIHJlZnJlc2ggdG9rZW4gYXMgZGVz Y3JpYmVkIGluIDx4cmVmIHRhcmdldD0ndG9rZW4tcmVzcG9uc2UnIC8+LgogICAgICAgIElmIHRo ZSByZXF1ZXN0IGZhaWxlZCBjbGllbnQgYXV0aGVudGljYXRpb24gb3IgaXMgaW52YWxpZCwgdGhl IGF1dGhvcml6YXRpb24gc2VydmVyIHJldHVybnMKICAgICAgICBhbiBlcnJvciByZXNwb25zZSBh cyBkZXNjcmliZWQgaW4gPHhyZWYgdGFyZ2V0PSd0b2tlbi1lcnJvcnMnIC8+LgogICAgICA8L3Q+ CgogICAgICA8c2VjdGlvbiB0aXRsZT0nU3VjY2Vzc2Z1bCBSZXNwb25zZScgYW5jaG9yPSd0b2tl bi1yZXNwb25zZSc+CiAgICAgICAgPHQ+CiAgICAgICAgICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2 ZXIgaXNzdWVzIGFuIGFjY2VzcyB0b2tlbiBhbmQgb3B0aW9uYWwgcmVmcmVzaCB0b2tlbiwgYW5k CiAgICAgICAgICBjb25zdHJ1Y3RzIHRoZSByZXNwb25zZSBieSBhZGRpbmcgdGhlIGZvbGxvd2lu ZyBwYXJhbWV0ZXJzIHRvIHRoZSBlbnRpdHkgYm9keSBvZiB0aGUgSFRUUAogICAgICAgICAgcmVz cG9uc2Ugd2l0aCBhIDIwMCAoT0spIHN0YXR1cyBjb2RlOgogICAgICAgIDwvdD4KICAgICAgICA8 dD4KICAgICAgICAgIDxsaXN0IHN0eWxlPSdoYW5naW5nJyBoYW5nSW5kZW50PSc2Jz4KICAgICAg ICAgICAgPHQgaGFuZ1RleHQ9J2FjY2Vzc190b2tlbic+CiAgICAgICAgICAgICAgPHZzcGFjZSAv PgogICAgICAgICAgICAgIFJFUVVJUkVELiBUaGUgYWNjZXNzIHRva2VuIGlzc3VlZCBieSB0aGUg YXV0aG9yaXphdGlvbiBzZXJ2ZXIuCiAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAgPHQgaGFu Z1RleHQ9J3Rva2VuX3R5cGUnPgogICAgICAgICAgICAgIDx2c3BhY2UgLz4KICAgICAgICAgICAg ICBSRVFVSVJFRC4gVGhlIHR5cGUgb2YgdGhlIHRva2VuIGlzc3VlZCBhcyBkZXNjcmliZWQgaW4g PHhyZWYgdGFyZ2V0PSd0b2tlbi10eXBlcycgLz4uCiAgICAgICAgICAgICAgVmFsdWUgaXMgY2Fz ZSBpbnNlbnNpdGl2ZS4KICAgICAgICAgICAgPC90PgogICAgICAgICAgICA8dCBoYW5nVGV4dD0n ZXhwaXJlc19pbic+CiAgICAgICAgICAgICAgPHZzcGFjZSAvPgogICAgICAgICAgICAgIFJFQ09N TUVOREVELiBUaGUgbGlmZXRpbWUgaW4gc2Vjb25kcyBvZiB0aGUgYWNjZXNzIHRva2VuLiBGb3Ig ZXhhbXBsZSwgdGhlIHZhbHVlCiAgICAgICAgICAgICAgPHNwYW54IHN0eWxlPSd2ZXJiJz4zNjAw PC9zcGFueD4gZGVub3RlcyB0aGF0IHRoZSBhY2Nlc3MgdG9rZW4gd2lsbCBleHBpcmUgaW4gb25l CiAgICAgICAgICAgICAgaG91ciBmcm9tIHRoZSB0aW1lIHRoZSByZXNwb25zZSB3YXMgZ2VuZXJh dGVkLiBJZiBvbWl0dGVkLCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIKICAgICAgICAgICAgICBT SE9VTEQgcHJvdmlkZSB0aGUgZXhwaXJhdGlvbiB0aW1lIHZpYSBvdGhlciBtZWFucyBvciBkb2N1 bWVudCB0aGUgZGVmYXVsdCB2YWx1ZS4KICAgICAgICAgICAgPC90PgogICAgICAgICAgICA8dCBo YW5nVGV4dD0ncmVmcmVzaF90b2tlbic+CiAgICAgICAgICAgICAgPHZzcGFjZSAvPgogICAgICAg ICAgICAgIE9QVElPTkFMLiBUaGUgcmVmcmVzaCB0b2tlbiB3aGljaCBjYW4gYmUgdXNlZCB0byBv YnRhaW4gbmV3IGFjY2VzcyB0b2tlbnMgdXNpbmcgdGhlCiAgICAgICAgICAgICAgc2FtZSBhdXRo b3JpemF0aW9uIGdyYW50IGFzIGRlc2NyaWJlZCBpbiA8eHJlZiB0YXJnZXQ9J3Rva2VuLXJlZnJl c2gnIC8+LgogICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgIDx0IGhhbmdUZXh0PSdzY29wZSc+ CiAgICAgICAgICAgICAgPHZzcGFjZSAvPgogICAgICAgICAgICAgIE9QVElPTkFMLCBpZiBpZGVu dGljYWwgdG8gdGhlIHNjb3BlIHJlcXVlc3RlZCBieSB0aGUgY2xpZW50LCBvdGhlcndpc2UgUkVR VUlSRUQuIFRoZQogICAgICAgICAgICAgIHNjb3BlIG9mIHRoZSBhY2Nlc3MgdG9rZW4gYXMgZGVz Y3JpYmVkIGJ5IDx4cmVmIHRhcmdldD0nc2NvcGUnIC8+LgogICAgICAgICAgICA8L3Q+CiAgICAg ICAgICA8L2xpc3Q+CiAgICAgICAgPC90PgogICAgICAgIDx0PgogICAgICAgICAgVGhlIHBhcmFt ZXRlcnMgYXJlIGluY2x1ZGVkIGluIHRoZSBlbnRpdHkgYm9keSBvZiB0aGUgSFRUUCByZXNwb25z ZSB1c2luZyB0aGUKICAgICAgICAgIDxzcGFueCBzdHlsZT0ndmVyYic+YXBwbGljYXRpb24vanNv bjwvc3Bhbng+IG1lZGlhIHR5cGUgYXMgZGVmaW5lZCBieQogICAgICAgICAgPHhyZWYgdGFyZ2V0 PSdSRkM0NjI3JyAvPi4gVGhlIHBhcmFtZXRlcnMgYXJlIHNlcmlhbGl6ZWQgaW50byBhIEpTT04g c3RydWN0dXJlIGJ5CiAgICAgICAgICBhZGRpbmcgZWFjaCBwYXJhbWV0ZXIgYXQgdGhlIGhpZ2hl c3Qgc3RydWN0dXJlIGxldmVsLiBQYXJhbWV0ZXIgbmFtZXMgYW5kIHN0cmluZyB2YWx1ZXMKICAg ICAgICAgIGFyZSBpbmNsdWRlZCBhcyBKU09OIHN0cmluZ3MuIE51bWVyaWNhbCB2YWx1ZXMgYXJl IGluY2x1ZGVkIGFzIEpTT04gbnVtYmVycy4gVGhlIG9yZGVyIG9mCiAgICAgICAgICBwYXJhbWV0 ZXJzIGRvZXMgbm90IG1hdHRlciBhbmQgY2FuIHZhcnkuCiAgICAgICAgPC90PgogICAgICAgIDx0 PgogICAgICAgICAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIE1VU1QgaW5jbHVkZSB0aGUgSFRU UAogICAgICAgICAgPHNwYW54IHN0eWxlPSd2ZXJiJz5DYWNoZS1Db250cm9sPC9zcGFueD4gcmVz cG9uc2UgaGVhZGVyIGZpZWxkIDx4cmVmIHRhcmdldD0nUkZDMjYxNicgLz4KICAgICAgICAgIHdp dGggYSB2YWx1ZSBvZiA8c3Bhbnggc3R5bGU9J3ZlcmInPm5vLXN0b3JlPC9zcGFueD4gaW4gYW55 IHJlc3BvbnNlIGNvbnRhaW5pbmcgdG9rZW5zLAogICAgICAgICAgY3JlZGVudGlhbHMsIG9yIG90 aGVyIHNlbnNpdGl2ZSBpbmZvcm1hdGlvbiwgYXMgd2VsbCBhcyB0aGUKICAgICAgICAgIDxzcGFu eCBzdHlsZT0ndmVyYic+UHJhZ21hPC9zcGFueD4gcmVzcG9uc2UgaGVhZGVyIGZpZWxkIDx4cmVm IHRhcmdldD0nUkZDMjYxNicgLz4gd2l0aCBhCiAgICAgICAgICB2YWx1ZSBvZiA8c3Bhbnggc3R5 bGU9J3ZlcmInPm5vLWNhY2hlPC9zcGFueD4uCiAgICAgICAgPC90PgogICAgICAgIDxmaWd1cmU+ CiAgICAgICAgICA8cHJlYW1ibGU+CiAgICAgICAgICAgIEZvciBleGFtcGxlOgogICAgICAgICAg PC9wcmVhbWJsZT4KICAgICAgICAgIDxhcnR3b3JrPgogICAgICAgICAgICA8IVtDREFUQVsKICBI VFRQLzEuMSAyMDAgT0sKICBDb250ZW50LVR5cGU6IGFwcGxpY2F0aW9uL2pzb247Y2hhcnNldD1V VEYtOAogIENhY2hlLUNvbnRyb2w6IG5vLXN0b3JlCiAgUHJhZ21hOiBuby1jYWNoZQoKICB7CiAg ICAiYWNjZXNzX3Rva2VuIjoiMllvdG5GWkZFanIxekNzaWNNV3BBQSIsCiAgICAidG9rZW5fdHlw ZSI6ImV4YW1wbGUiLAogICAgImV4cGlyZXNfaW4iOjM2MDAsCiAgICAicmVmcmVzaF90b2tlbiI6 InRHenYzSk9rRjBYRzVReDJUbEtXSUEiLAogICAgImV4YW1wbGVfcGFyYW1ldGVyIjoiZXhhbXBs ZV92YWx1ZSIKICB9Cl1dPgogICAgICAgICAgPC9hcnR3b3JrPgogICAgICAgIDwvZmlndXJlPgog ICAgICAgIDx0PgogICAgICAgICAgVGhlIGNsaWVudCBNVVNUIGlnbm9yZSB1bnJlY29nbml6ZWQg dmFsdWUgbmFtZXMgaW4gdGhlIHJlc3BvbnNlLiBUaGUgc2l6ZXMgb2YgdG9rZW5zIGFuZAogICAg ICAgICAgb3RoZXIgdmFsdWVzIHJlY2VpdmVkIGZyb20gdGhlIGF1dGhvcml6YXRpb24gc2VydmVy IGFyZSBsZWZ0IHVuZGVmaW5lZC4gVGhlIGNsaWVudCBzaG91bGQKICAgICAgICAgIGF2b2lkIG1h a2luZyBhc3N1bXB0aW9ucyBhYm91dCB2YWx1ZSBzaXplcy4gVGhlIGF1dGhvcml6YXRpb24gc2Vy dmVyIFNIT1VMRCBkb2N1bWVudCB0aGUKICAgICAgICAgIHNpemUgb2YgYW55IHZhbHVlIGl0IGlz c3Vlcy4KICAgICAgICA8L3Q+CiAgICAgIDwvc2VjdGlvbj4KCiAgICAgIDxzZWN0aW9uIHRpdGxl PSdFcnJvciBSZXNwb25zZScgYW5jaG9yPSd0b2tlbi1lcnJvcnMnPgogICAgICAgIDx0PgogICAg ICAgICAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHJlc3BvbmRzIHdpdGggYW4gSFRUUCA0MDAg KEJhZCBSZXF1ZXN0KSBzdGF0dXMgY29kZSAodW5sZXNzCiAgICAgICAgICBzcGVjaWZpZWQgb3Ro ZXJ3aXNlKSBhbmQgaW5jbHVkZXMgdGhlIGZvbGxvd2luZyBwYXJhbWV0ZXJzIHdpdGggdGhlIHJl c3BvbnNlOgogICAgICAgIDwvdD4KICAgICAgICA8dD4KICAgICAgICAgIDxsaXN0IHN0eWxlPSdo YW5naW5nJyBoYW5nSW5kZW50PSc2Jz4KICAgICAgICAgICAgPHQgaGFuZ1RleHQ9J2Vycm9yJz4K ICAgICAgICAgICAgICA8dnNwYWNlIC8+CiAgICAgICAgICAgICAgUkVRVUlSRUQuIEEgc2luZ2xl IEFTQ0lJIDx4cmVmIHRhcmdldD0iVVNBU0NJSSIgLz4gZXJyb3IgY29kZSBmcm9tIHRoZSBmb2xs b3dpbmc6CgogICAgICAgICAgICAgIDxsaXN0IHN0eWxlPSdoYW5naW5nJyBoYW5nSW5kZW50PSc2 Jz4KICAgICAgICAgICAgICAgIDx0IGhhbmdUZXh0PSdpbnZhbGlkX3JlcXVlc3QnPgogICAgICAg ICAgICAgICAgICA8dnNwYWNlIC8+CiAgICAgICAgICAgICAgICAgIFRoZSByZXF1ZXN0IGlzIG1p c3NpbmcgYSByZXF1aXJlZCBwYXJhbWV0ZXIsIGluY2x1ZGVzIGFuIHVuc3VwcG9ydGVkCiAgICAg ICAgICAgICAgICAgIHBhcmFtZXRlciB2YWx1ZSAob3RoZXIgdGhhbiBncmFudCB0eXBlKSwgcmVw ZWF0cyBhIHBhcmFtZXRlciwgaW5jbHVkZXMgbXVsdGlwbGUKICAgICAgICAgICAgICAgICAgY3Jl ZGVudGlhbHMsIHV0aWxpemVzIG1vcmUgdGhhbiBvbmUgbWVjaGFuaXNtIGZvciBhdXRoZW50aWNh dGluZyB0aGUgY2xpZW50LAogICAgICAgICAgICAgICAgICBvciBpcyBvdGhlcndpc2UgbWFsZm9y bWVkLgogICAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICAgICAgPHQgaGFuZ1RleHQ9J2lu dmFsaWRfY2xpZW50Jz4KICAgICAgICAgICAgICAgICAgPHZzcGFjZSAvPgogICAgICAgICAgICAg ICAgICBDbGllbnQgYXV0aGVudGljYXRpb24gZmFpbGVkIChlLmcuIHVua25vd24gY2xpZW50LCBu byBjbGllbnQgYXV0aGVudGljYXRpb24KICAgICAgICAgICAgICAgICAgaW5jbHVkZWQsIG9yIHVu c3VwcG9ydGVkIGF1dGhlbnRpY2F0aW9uIG1ldGhvZCkuIFRoZSBhdXRob3JpemF0aW9uIHNlcnZl ciBNQVkKICAgICAgICAgICAgICAgICAgcmV0dXJuIGFuIEhUVFAgNDAxIChVbmF1dGhvcml6ZWQp IHN0YXR1cyBjb2RlIHRvIGluZGljYXRlIHdoaWNoIEhUVFAKICAgICAgICAgICAgICAgICAgYXV0 aGVudGljYXRpb24gc2NoZW1lcyBhcmUgc3VwcG9ydGVkLiBJZiB0aGUgY2xpZW50IGF0dGVtcHRl ZCB0byBhdXRoZW50aWNhdGUgdmlhCiAgICAgICAgICAgICAgICAgIHRoZSA8c3Bhbnggc3R5bGU9 J3ZlcmInPkF1dGhvcml6YXRpb248L3NwYW54PiByZXF1ZXN0IGhlYWRlciBmaWVsZCwKICAgICAg ICAgICAgICAgICAgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIE1VU1QgcmVzcG9uZCB3aXRoIGFu IEhUVFAgNDAxIChVbmF1dGhvcml6ZWQpIHN0YXR1cwogICAgICAgICAgICAgICAgICBjb2RlLCBh bmQgaW5jbHVkZSB0aGUgPHNwYW54IHN0eWxlPSd2ZXJiJz5XV1ctQXV0aGVudGljYXRlPC9zcGFu eD4gcmVzcG9uc2UKICAgICAgICAgICAgICAgICAgaGVhZGVyIGZpZWxkIG1hdGNoaW5nIHRoZSBh dXRoZW50aWNhdGlvbiBzY2hlbWUgdXNlZCBieSB0aGUgY2xpZW50LgogICAgICAgICAgICAgICAg PC90PgogICAgICAgICAgICAgICAgPHQgaGFuZ1RleHQ9J2ludmFsaWRfZ3JhbnQnPgogICAgICAg ICAgICAgICAgICA8dnNwYWNlIC8+CiAgICAgICAgICAgICAgICAgIFRoZSBwcm92aWRlZCBhdXRo b3JpemF0aW9uIGdyYW50IChlLmcuIGF1dGhvcml6YXRpb24gY29kZSwgcmVzb3VyY2Ugb3duZXIK ICAgICAgICAgICAgICAgICAgY3JlZGVudGlhbHMpIG9yIHJlZnJlc2ggdG9rZW4gaXMgaW52YWxp ZCwgZXhwaXJlZCwgcmV2b2tlZCwgZG9lcyBub3QgbWF0Y2ggdGhlCiAgICAgICAgICAgICAgICAg IHJlZGlyZWN0aW9uIFVSSSB1c2VkIGluIHRoZSBhdXRob3JpemF0aW9uIHJlcXVlc3QsIG9yIHdh cyBpc3N1ZWQgdG8gYW5vdGhlcgogICAgICAgICAgICAgICAgICBjbGllbnQuCiAgICAgICAgICAg ICAgICA8L3Q+CiAgICAgICAgICAgICAgICA8dCBoYW5nVGV4dD0ndW5hdXRob3JpemVkX2NsaWVu dCc+CiAgICAgICAgICAgICAgICAgIDx2c3BhY2UgLz4KICAgICAgICAgICAgICAgICAgVGhlIGF1 dGhlbnRpY2F0ZWQgY2xpZW50IGlzIG5vdCBhdXRob3JpemVkIHRvIHVzZSB0aGlzIGF1dGhvcml6 YXRpb24gZ3JhbnQgdHlwZS4KICAgICAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAgICAgIDx0 IGhhbmdUZXh0PSd1bnN1cHBvcnRlZF9ncmFudF90eXBlJz4KICAgICAgICAgICAgICAgICAgPHZz cGFjZSAvPgogICAgICAgICAgICAgICAgICBUaGUgYXV0aG9yaXphdGlvbiBncmFudCB0eXBlIGlz IG5vdCBzdXBwb3J0ZWQgYnkgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLgogICAgICAgICAgICAg ICAgPC90PgogICAgICAgICAgICAgICAgPHQgaGFuZ1RleHQ9J2ludmFsaWRfc2NvcGUnPgogICAg ICAgICAgICAgICAgICA8dnNwYWNlIC8+CiAgICAgICAgICAgICAgICAgIFRoZSByZXF1ZXN0ZWQg c2NvcGUgaXMgaW52YWxpZCwgdW5rbm93biwgbWFsZm9ybWVkLCBvciBleGNlZWRzIHRoZSBzY29w ZSBncmFudGVkCiAgICAgICAgICAgICAgICAgIGJ5IHRoZSByZXNvdXJjZSBvd25lci4KICAgICAg ICAgICAgICAgIDwvdD4KICAgICAgICAgICAgICA8L2xpc3Q+CgoJICAgICAgVmFsdWVzIGZvciB0 aGUgPHNwYW54IHN0eWxlPSd2ZXJiJz5lcnJvcjwvc3Bhbng+IHBhcmFtZXRlciBNVVNUIE5PVCBp bmNsdWRlCgkgICAgICBjaGFyYWN0ZXJzIG91dHNpZGUgdGhlIHNldCAleDIwLTIxIC8gJXgyMy01 QiAvICV4NUQtN0UuCiAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAgPHQgaGFuZ1RleHQ9J2Vy cm9yX2Rlc2NyaXB0aW9uJz4KICAgICAgICAgICAgICA8dnNwYWNlIC8+CiAgICAgICAgICAgICAg T1BUSU9OQUwuIEEgaHVtYW4tcmVhZGFibGUgQVNDSUkgPHhyZWYgdGFyZ2V0PSJVU0FTQ0lJIiAv PiB0ZXh0IHByb3ZpZGluZyBhZGRpdGlvbmFsIGluZm9ybWF0aW9uLAogICAgICAgICAgICAgIHVz ZWQgdG8gYXNzaXN0IHRoZSBjbGllbnQgZGV2ZWxvcGVyIGluIHVuZGVyc3RhbmRpbmcgdGhlIGVy cm9yIHRoYXQgb2NjdXJyZWQuCgkgICAgICA8dnNwYWNlLz4KCSAgICAgIFZhbHVlcyBmb3IgdGhl IDxzcGFueCBzdHlsZT0ndmVyYic+ZXJyb3JfZGVzY3JpcHRpb248L3NwYW54PiBwYXJhbWV0ZXIg TVVTVCBOT1QgaW5jbHVkZQoJICAgICAgY2hhcmFjdGVycyBvdXRzaWRlIHRoZSBzZXQgJXgyMC0y MSAvICV4MjMtNUIgLyAleDVELTdFLgogICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgIDx0IGhh bmdUZXh0PSdlcnJvcl91cmknPgogICAgICAgICAgICAgIDx2c3BhY2UgLz4KICAgICAgICAgICAg ICBPUFRJT05BTC4gQSBVUkkgaWRlbnRpZnlpbmcgYSBodW1hbi1yZWFkYWJsZSB3ZWIgcGFnZSB3 aXRoIGluZm9ybWF0aW9uIGFib3V0IHRoZQogICAgICAgICAgICAgIGVycm9yLCB1c2VkIHRvIHBy b3ZpZGUgdGhlIGNsaWVudCBkZXZlbG9wZXIgd2l0aCBhZGRpdGlvbmFsIGluZm9ybWF0aW9uIGFi b3V0IHRoZQogICAgICAgICAgICAgIGVycm9yLgoJICAgICAgPHZzcGFjZS8+CgkgICAgICBWYWx1 ZXMgZm9yIHRoZSA8c3Bhbnggc3R5bGU9J3ZlcmInPmVycm9yX3VyaTwvc3Bhbng+IHBhcmFtZXRl cgoJICAgICAgTVVTVCBjb25mb3JtIHRvIHRoZSBVUkktUmVmZXJlbmNlIHN5bnRheCwgYW5kIHRo dXMgTVVTVCBOT1QgaW5jbHVkZQoJICAgICAgY2hhcmFjdGVycyBvdXRzaWRlIHRoZSBzZXQgJXgy MSAvICV4MjMtNUIgLyAleDVELTdFLgogICAgICAgICAgICA8L3Q+CiAgICAgICAgICA8L2xpc3Q+ CiAgICAgICAgPC90PgogICAgICAgIDx0PgogICAgICAgICAgVGhlIHBhcmFtZXRlcnMgYXJlIGlu Y2x1ZGVkIGluIHRoZSBlbnRpdHkgYm9keSBvZiB0aGUgSFRUUCByZXNwb25zZSB1c2luZyB0aGUK ICAgICAgICAgIDxzcGFueCBzdHlsZT0ndmVyYic+YXBwbGljYXRpb24vanNvbjwvc3Bhbng+IG1l ZGlhIHR5cGUgYXMgZGVmaW5lZCBieQogICAgICAgICAgPHhyZWYgdGFyZ2V0PSdSRkM0NjI3JyAv Pi4gVGhlIHBhcmFtZXRlcnMgYXJlIHNlcmlhbGl6ZWQgaW50byBhIEpTT04gc3RydWN0dXJlIGJ5 CiAgICAgICAgICBhZGRpbmcgZWFjaCBwYXJhbWV0ZXIgYXQgdGhlIGhpZ2hlc3Qgc3RydWN0dXJl IGxldmVsLiBQYXJhbWV0ZXIgbmFtZXMgYW5kIHN0cmluZyB2YWx1ZXMKICAgICAgICAgIGFyZSBp bmNsdWRlZCBhcyBKU09OIHN0cmluZ3MuIE51bWVyaWNhbCB2YWx1ZXMgYXJlIGluY2x1ZGVkIGFz IEpTT04gbnVtYmVycy4gVGhlIG9yZGVyIG9mCiAgICAgICAgICBwYXJhbWV0ZXJzIGRvZXMgbm90 IG1hdHRlciBhbmQgY2FuIHZhcnkuCiAgICAgICAgPC90PgogICAgICAgIDxmaWd1cmU+CiAgICAg ICAgICA8cHJlYW1ibGU+CiAgICAgICAgICAgIEZvciBleGFtcGxlOgogICAgICAgICAgPC9wcmVh bWJsZT4KICAgICAgICAgIDxhcnR3b3JrPgogICAgICAgICAgICA8IVtDREFUQVsKICBIVFRQLzEu MSA0MDAgQmFkIFJlcXVlc3QKICBDb250ZW50LVR5cGU6IGFwcGxpY2F0aW9uL2pzb247Y2hhcnNl dD1VVEYtOAogIENhY2hlLUNvbnRyb2w6IG5vLXN0b3JlCiAgUHJhZ21hOiBuby1jYWNoZQoKICB7 CiAgICAiZXJyb3IiOiJpbnZhbGlkX3JlcXVlc3QiCiAgfQpdXT4KICAgICAgICAgIDwvYXJ0d29y az4KICAgICAgICA8L2ZpZ3VyZT4KICAgICAgPC9zZWN0aW9uPgoKICAgIDwvc2VjdGlvbj4KCiAg ICA8c2VjdGlvbiB0aXRsZT0nUmVmcmVzaGluZyBhbiBBY2Nlc3MgVG9rZW4nIGFuY2hvcj0ndG9r ZW4tcmVmcmVzaCc+CiAgICAgIDx0PgogICAgICAgIElmIHRoZSBhdXRob3JpemF0aW9uIHNlcnZl ciBpc3N1ZWQgYSByZWZyZXNoIHRva2VuIHRvIHRoZSBjbGllbnQsIHRoZSBjbGllbnQgbWFrZXMg YQogICAgICAgIHJlZnJlc2ggcmVxdWVzdCB0byB0aGUgdG9rZW4gZW5kcG9pbnQgYnkgYWRkaW5n IHRoZSBmb2xsb3dpbmcgcGFyYW1ldGVycyB1c2luZyB0aGUKICAgICAgICA8c3Bhbnggc3R5bGU9 J3ZlcmInPmFwcGxpY2F0aW9uL3gtd3d3LWZvcm0tdXJsZW5jb2RlZDwvc3Bhbng+IGZvcm1hdCBp biB0aGUgSFRUUCByZXF1ZXN0CiAgICAgICAgZW50aXR5LWJvZHk6CiAgICAgIDwvdD4KICAgICAg PHQ+CiAgICAgICAgPGxpc3Qgc3R5bGU9J2hhbmdpbmcnIGhhbmdJbmRlbnQ9JzYnPgogICAgICAg ICAgPHQgaGFuZ1RleHQ9J2dyYW50X3R5cGUnPgogICAgICAgICAgICA8dnNwYWNlIC8+CiAgICAg ICAgICAgIFJFUVVJUkVELiBWYWx1ZSBNVVNUIGJlIHNldCB0byA8c3Bhbnggc3R5bGU9J3ZlcmIn PnJlZnJlc2hfdG9rZW48L3NwYW54Pi4KICAgICAgICAgIDwvdD4KICAgICAgICAgIDx0IGhhbmdU ZXh0PSdyZWZyZXNoX3Rva2VuJz4KICAgICAgICAgICAgPHZzcGFjZSAvPgogICAgICAgICAgICBS RVFVSVJFRC4gVGhlIHJlZnJlc2ggdG9rZW4gaXNzdWVkIHRvIHRoZSBjbGllbnQuCiAgICAgICAg ICA8L3Q+CiAgICAgICAgICA8dCBoYW5nVGV4dD0nc2NvcGUnPgogICAgICAgICAgICA8dnNwYWNl IC8+CiAgICAgICAgICAgIE9QVElPTkFMLiBUaGUgc2NvcGUgb2YgdGhlIGFjY2VzcyByZXF1ZXN0 IGFzIGRlc2NyaWJlZCBieSA8eHJlZiB0YXJnZXQ9J3Njb3BlJyAvPi4KICAgICAgICAgICAgVGhl IHJlcXVlc3RlZCBzY29wZSBNVVNUIE5PVCBpbmNsdWRlIGFueSBzY29wZSBub3Qgb3JpZ2luYWxs eSBncmFudGVkIGJ5IHRoZSByZXNvdXJjZQogICAgICAgICAgICBvd25lciwgYW5kIGlmIG9taXR0 ZWQgaXMgdHJlYXRlZCBhcyBlcXVhbCB0byB0aGUgc2NvcGUgb3JpZ2luYWxseSBncmFudGVkIGJ5 IHRoZQogICAgICAgICAgICByZXNvdXJjZSBvd25lci4KICAgICAgICAgIDwvdD4KICAgICAgICA8 L2xpc3Q+CiAgICAgIDwvdD4KICAgICAgPHQ+CiAgICAgICAgQmVjYXVzZSByZWZyZXNoIHRva2Vu cyBhcmUgdHlwaWNhbGx5IGxvbmctbGFzdGluZyBjcmVkZW50aWFscyB1c2VkIHRvIHJlcXVlc3Qg YWRkaXRpb25hbAogICAgICAgIGFjY2VzcyB0b2tlbnMsIHRoZSByZWZyZXNoIHRva2VuIGlzIGJv dW5kIHRvIHRoZSBjbGllbnQgd2hpY2ggaXQgd2FzIGlzc3VlZC4gSWYgdGhlIGNsaWVudCB0eXBl CiAgICAgICAgaXMgY29uZmlkZW50aWFsIG9yIHRoZSBjbGllbnQgd2FzIGlzc3VlZCBjbGllbnQg Y3JlZGVudGlhbHMgKG9yIGFzc2lnbmVkIG90aGVyCiAgICAgICAgYXV0aGVudGljYXRpb24gcmVx dWlyZW1lbnRzKSwgdGhlIGNsaWVudCBNVVNUIGF1dGhlbnRpY2F0ZSB3aXRoIHRoZSBhdXRob3Jp emF0aW9uIHNlcnZlciBhcwogICAgICAgIGRlc2NyaWJlZCBpbiA8eHJlZiB0YXJnZXQ9J3Rva2Vu LWVuZHBvaW50LWF1dGgnIC8+LgogICAgICA8L3Q+CiAgICAgIDxmaWd1cmU+CiAgICAgICAgPHBy ZWFtYmxlPgogICAgICAgICAgRm9yIGV4YW1wbGUsIHRoZSBjbGllbnQgbWFrZXMgdGhlIGZvbGxv d2luZyBIVFRQIHJlcXVlc3QgdXNpbmcgdHJhbnNwb3J0LWxheWVyCiAgICAgICAgICBzZWN1cml0 eSAoZXh0cmEgbGluZSBicmVha3MgYXJlIGZvciBkaXNwbGF5IHB1cnBvc2VzIG9ubHkpOgogICAg ICAgIDwvcHJlYW1ibGU+CiAgICAgICAgPGFydHdvcms+CiAgICAgICAgICA8IVtDREFUQVsKICBQ T1NUIC90b2tlbiBIVFRQLzEuMQogIEhvc3Q6IHNlcnZlci5leGFtcGxlLmNvbQogIEF1dGhvcml6 YXRpb246IEJhc2ljIGN6WkNhR1JTYTNGME16cG5XREZtUW1GME0ySlcKICBDb250ZW50LVR5cGU6 IGFwcGxpY2F0aW9uL3gtd3d3LWZvcm0tdXJsZW5jb2RlZDtjaGFyc2V0PVVURi04CiAgCiAgZ3Jh bnRfdHlwZT1yZWZyZXNoX3Rva2VuJnJlZnJlc2hfdG9rZW49dEd6djNKT2tGMFhHNVF4MlRsS1dJ QQpdXT4KICAgICAgICA8L2FydHdvcms+CiAgICAgIDwvZmlndXJlPgogICAgICA8dD4KICAgICAg ICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVTVDoKICAgICAgPC90PgogICAgICA8dD4KICAg ICAgICA8bGlzdCBzdHlsZT0nc3ltYm9scyc+CiAgICAgICAgICA8dD4KICAgICAgICAgICAgcmVx dWlyZSBjbGllbnQgYXV0aGVudGljYXRpb24gZm9yIGNvbmZpZGVudGlhbCBjbGllbnRzIG9yIGZv ciBhbnkgY2xpZW50IHRoYXQgd2FzCiAgICAgICAgICAgIGlzc3VlZCBjbGllbnQgY3JlZGVudGlh bHMgKG9yIHdpdGggb3RoZXIgYXV0aGVudGljYXRpb24gcmVxdWlyZW1lbnRzKSwKICAgICAgICAg IDwvdD4KICAgICAgICAgIDx0PgogICAgICAgICAgICBhdXRoZW50aWNhdGUgdGhlIGNsaWVudCBp ZiBjbGllbnQgYXV0aGVudGljYXRpb24gaXMgaW5jbHVkZWQgYW5kIGVuc3VyZSB0aGUKICAgICAg ICAgICAgcmVmcmVzaCB0b2tlbiB3YXMgaXNzdWVkIHRvIHRoZSBhdXRoZW50aWNhdGVkIGNsaWVu dCwgYW5kCiAgICAgICAgICA8L3Q+CiAgICAgICAgICA8dD4KICAgICAgICAgICAgdmFsaWRhdGUg dGhlIHJlZnJlc2ggdG9rZW4uCiAgICAgICAgICA8L3Q+CiAgICAgICAgPC9saXN0PgogICAgICA8 L3Q+CiAgICAgIDx0PgogICAgICAgIElmIHZhbGlkIGFuZCBhdXRob3JpemVkLCB0aGUgYXV0aG9y aXphdGlvbiBzZXJ2ZXIgaXNzdWVzIGFuIGFjY2VzcyB0b2tlbiBhcyBkZXNjcmliZWQgaW4KICAg ICAgICA8eHJlZiB0YXJnZXQ9J3Rva2VuLXJlc3BvbnNlJyAvPi4gSWYgdGhlIHJlcXVlc3QgZmFp bGVkIHZlcmlmaWNhdGlvbiBvciBpcyBpbnZhbGlkLCB0aGUKICAgICAgICBhdXRob3JpemF0aW9u IHNlcnZlciByZXR1cm5zIGFuIGVycm9yIHJlc3BvbnNlIGFzIGRlc2NyaWJlZCBpbgogICAgICAg IDx4cmVmIHRhcmdldD0ndG9rZW4tZXJyb3JzJyAvPi4KICAgICAgPC90PgogICAgICA8dD4KICAg ICAgICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTUFZIGlzc3VlIGEgbmV3IHJlZnJlc2ggdG9r ZW4sIGluIHdoaWNoIGNhc2UgdGhlIGNsaWVudCBNVVNUCiAgICAgICAgZGlzY2FyZCB0aGUgb2xk IHJlZnJlc2ggdG9rZW4gYW5kIHJlcGxhY2UgaXQgd2l0aCB0aGUgbmV3IHJlZnJlc2ggdG9rZW4u IFRoZSBhdXRob3JpemF0aW9uCiAgICAgICAgc2VydmVyIE1BWSByZXZva2UgdGhlIG9sZCByZWZy ZXNoIHRva2VuIGFmdGVyIGlzc3VpbmcgYSBuZXcgcmVmcmVzaCB0b2tlbiB0byB0aGUgY2xpZW50 LiBJZgogICAgICAgIGEgbmV3IHJlZnJlc2ggdG9rZW4gaXMgaXNzdWVkLCB0aGUgcmVmcmVzaCB0 b2tlbiBzY29wZSBNVVNUIGJlIGlkZW50aWNhbCB0byB0aGF0IG9mIHRoZQogICAgICAgIHJlZnJl c2ggdG9rZW4gaW5jbHVkZWQgYnkgdGhlIGNsaWVudCBpbiB0aGUgcmVxdWVzdC4KICAgICAgPC90 PgogICAgPC9zZWN0aW9uPgoKICAgIDxzZWN0aW9uIHRpdGxlPSdBY2Nlc3NpbmcgUHJvdGVjdGVk IFJlc291cmNlcycgYW5jaG9yPSdhY2Nlc3MtcmVzb3VyY2UnPgogICAgICA8dD4KICAgICAgICBU aGUgY2xpZW50IGFjY2Vzc2VzIHByb3RlY3RlZCByZXNvdXJjZXMgYnkgcHJlc2VudGluZyB0aGUg YWNjZXNzIHRva2VuIHRvIHRoZSByZXNvdXJjZQogICAgICAgIHNlcnZlci4gVGhlIHJlc291cmNl IHNlcnZlciBNVVNUIHZhbGlkYXRlIHRoZSBhY2Nlc3MgdG9rZW4gYW5kIGVuc3VyZSBpdCBoYXMg bm90IGV4cGlyZWQKICAgICAgICBhbmQgdGhhdCBpdHMgc2NvcGUgY292ZXJzIHRoZSByZXF1ZXN0 ZWQgcmVzb3VyY2UuIFRoZSBtZXRob2RzIHVzZWQgYnkgdGhlIHJlc291cmNlIHNlcnZlcgogICAg ICAgIHRvIHZhbGlkYXRlIHRoZSBhY2Nlc3MgdG9rZW4gKGFzIHdlbGwgYXMgYW55IGVycm9yIHJl c3BvbnNlcykgYXJlIGJleW9uZCB0aGUgc2NvcGUgb2YgdGhpcwogICAgICAgIHNwZWNpZmljYXRp b24sIGJ1dCBnZW5lcmFsbHkgaW52b2x2ZSBhbiBpbnRlcmFjdGlvbiBvciBjb29yZGluYXRpb24g YmV0d2VlbiB0aGUgcmVzb3VyY2UKICAgICAgICBzZXJ2ZXIgYW5kIHRoZSBhdXRob3JpemF0aW9u IHNlcnZlci4KICAgICAgPC90PgogICAgICA8dD4KICAgICAgICBUaGUgbWV0aG9kIGluIHdoaWNo IHRoZSBjbGllbnQgdXRpbGl6ZXMgdGhlIGFjY2VzcyB0b2tlbiB0byBhdXRoZW50aWNhdGUgd2l0 aCB0aGUgcmVzb3VyY2UKICAgICAgICBzZXJ2ZXIgZGVwZW5kcyBvbiB0aGUgdHlwZSBvZiBhY2Nl c3MgdG9rZW4gaXNzdWVkIGJ5IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlci4gVHlwaWNhbGx5LAog ICAgICAgIGl0IGludm9sdmVzIHVzaW5nIHRoZSBIVFRQIDxzcGFueCBzdHlsZT0ndmVyYic+QXV0 aG9yaXphdGlvbjwvc3Bhbng+IHJlcXVlc3QgaGVhZGVyIGZpZWxkCiAgICAgICAgPHhyZWYgdGFy Z2V0PSdSRkMyNjE3JyAvPiB3aXRoIGFuIGF1dGhlbnRpY2F0aW9uIHNjaGVtZSBkZWZpbmVkIGJ5 IHRoZSBhY2Nlc3MgdG9rZW4gdHlwZQogICAgICAgIHNwZWNpZmljYXRpb24uCiAgICAgIDwvdD4K CiAgICAgIDxzZWN0aW9uIHRpdGxlPSdBY2Nlc3MgVG9rZW4gVHlwZXMnIGFuY2hvcj0ndG9rZW4t dHlwZXMnPgogICAgICAgIDx0PgogICAgICAgICAgVGhlIGFjY2VzcyB0b2tlbiB0eXBlIHByb3Zp ZGVzIHRoZSBjbGllbnQgd2l0aCB0aGUgaW5mb3JtYXRpb24gcmVxdWlyZWQgdG8gc3VjY2Vzc2Z1 bGx5CiAgICAgICAgICB1dGlsaXplIHRoZSBhY2Nlc3MgdG9rZW4gdG8gbWFrZSBhIHByb3RlY3Rl ZCByZXNvdXJjZSByZXF1ZXN0IChhbG9uZyB3aXRoIHR5cGUtc3BlY2lmaWMKICAgICAgICAgIGF0 dHJpYnV0ZXMpLiBUaGUgY2xpZW50IE1VU1QgTk9UIHVzZSBhbiBhY2Nlc3MgdG9rZW4gaWYgaXQg ZG9lcyBub3QgdW5kZXJzdGFuZCB0aGUgdG9rZW4KICAgICAgICAgIHR5cGUuCiAgICAgICAgPC90 PgogICAgICAgIDxmaWd1cmU+CiAgICAgICAgICA8cHJlYW1ibGU+CiAgICAgICAgICAgIEZvciBl eGFtcGxlLCB0aGUgPHNwYW54IHN0eWxlPSd2ZXJiJz5iZWFyZXI8L3NwYW54PiB0b2tlbiB0eXBl IGRlZmluZWQgaW4KICAgICAgICAgICAgPHhyZWYgdGFyZ2V0PSdJLUQuaWV0Zi1vYXV0aC12Mi1i ZWFyZXInIC8+IGlzIHV0aWxpemVkIGJ5IHNpbXBseSBpbmNsdWRpbmcgdGhlIGFjY2VzcwogICAg ICAgICAgICB0b2tlbiBzdHJpbmcgaW4gdGhlIHJlcXVlc3Q6CiAgICAgICAgICA8L3ByZWFtYmxl PgogICAgICAgICAgPGFydHdvcms+CiAgICAgICAgICAgIDwhW0NEQVRBWwogIEdFVCAvcmVzb3Vy Y2UvMSBIVFRQLzEuMQogIEhvc3Q6IGV4YW1wbGUuY29tCiAgQXV0aG9yaXphdGlvbjogQmVhcmVy IG1GXzkuQjVmLTQuMUpxTQpdXT4KICAgICAgICAgIDwvYXJ0d29yaz4KICAgICAgICA8L2ZpZ3Vy ZT4KICAgICAgICA8ZmlndXJlPgogICAgICAgICAgPHByZWFtYmxlPgogICAgICAgICAgICB3aGls ZSB0aGUgPHNwYW54IHN0eWxlPSd2ZXJiJz5tYWM8L3NwYW54PiB0b2tlbiB0eXBlIGRlZmluZWQg aW4KICAgICAgICAgICAgPHhyZWYgdGFyZ2V0PSdJLUQuaWV0Zi1vYXV0aC12Mi1odHRwLW1hYycg Lz4gaXMgdXRpbGl6ZWQgYnkgaXNzdWluZyBhIE1BQyBrZXkKICAgICAgICAgICAgdG9nZXRoZXIg d2l0aCB0aGUgYWNjZXNzIHRva2VuIHdoaWNoIGlzIHVzZWQgdG8gc2lnbiBjZXJ0YWluIGNvbXBv bmVudHMgb2YgdGhlIEhUVFAKICAgICAgICAgICAgcmVxdWVzdHM6CiAgICAgICAgICA8L3ByZWFt YmxlPgogICAgICAgICAgPGFydHdvcms+CiAgICAgICAgICAgIDwhW0NEQVRBWwogIEdFVCAvcmVz b3VyY2UvMSBIVFRQLzEuMQogIEhvc3Q6IGV4YW1wbGUuY29tCiAgQXV0aG9yaXphdGlvbjogTUFD IGlkPSJoNDgwZGpzOTNoZDgiLAogICAgICAgICAgICAgICAgICAgICBub25jZT0iMjc0MzEyOmRq ODNoczlzIiwKICAgICAgICAgICAgICAgICAgICAgbWFjPSJrRFp2ZGRrbmR4dmhHUlhaaHZ1RGpF V2hHZUU9IgpdXT4KICAgICAgICAgIDwvYXJ0d29yaz4KICAgICAgICA8L2ZpZ3VyZT4KICAgICAg ICA8dD4KICAgICAgICAgIFRoZSBhYm92ZSBleGFtcGxlcyBhcmUgcHJvdmlkZWQgZm9yIGlsbHVz dHJhdGlvbiBwdXJwb3NlcyBvbmx5LiBEZXZlbG9wZXJzIGFyZSBhZHZpc2VkIHRvCiAgICAgICAg ICBjb25zdWx0IHRoZSA8eHJlZiB0YXJnZXQ9J0ktRC5pZXRmLW9hdXRoLXYyLWJlYXJlcicgLz4g YW5kCiAgICAgICAgICA8eHJlZiB0YXJnZXQ9J0ktRC5pZXRmLW9hdXRoLXYyLWh0dHAtbWFjJyAv PiBzcGVjaWZpY2F0aW9ucyBiZWZvcmUgdXNlLgogICAgICAgIDwvdD4KICAgICAgICA8dD4KICAg ICAgICAgIEVhY2ggYWNjZXNzIHRva2VuIHR5cGUgZGVmaW5pdGlvbiBzcGVjaWZpZXMgdGhlIGFk ZGl0aW9uYWwgYXR0cmlidXRlcyAoaWYgYW55KSBzZW50IHRvCiAgICAgICAgICB0aGUgY2xpZW50 IHRvZ2V0aGVyIHdpdGggdGhlIDxzcGFueCBzdHlsZT0ndmVyYic+YWNjZXNzX3Rva2VuPC9zcGFu eD4gcmVzcG9uc2UgcGFyYW1ldGVyLgogICAgICAgICAgSXQgYWxzbyBkZWZpbmVzIHRoZSBIVFRQ IGF1dGhlbnRpY2F0aW9uIG1ldGhvZCB1c2VkIHRvIGluY2x1ZGUgdGhlIGFjY2VzcyB0b2tlbiB3 aGVuCiAgICAgICAgICBtYWtpbmcgYSBwcm90ZWN0ZWQgcmVzb3VyY2UgcmVxdWVzdC4KICAgICAg ICA8L3Q+CiAgICAgIDwvc2VjdGlvbj4KCiAgICAgIDxzZWN0aW9uIHRpdGxlPSdFcnJvciBSZXNw b25zZScgYW5jaG9yPSdyZXNvdXJjZS1lcnJvcnMnPgoJPHQ+CgkgIElmIGEgcmVzb3VyY2UgYWNj ZXNzIHJlcXVlc3QgZmFpbHMsIHRoZSByZXNvdXJjZSBzZXJ2ZXIgU0hPVUxEIGluZm9ybQoJICB0 aGUgY2xpZW50IG9mIHRoZSBlcnJvci4gIFdoaWxlIHRoZSBzcGVjaWZpYyBlcnJvciByZXNwb25z ZXMgcG9zc2libGUKCSAgYW5kIG1ldGhvZHMgZm9yIHRyYW5zbWl0dGluZyB0aG9zZSBlcnJvcnMg d2hlbiB1c2luZyBhbnkgcGFydGljdWxhcgoJICBhY2Nlc3MgdG9rZW4gdHlwZSBhcmUgYmV5b25k IHRoZSBzY29wZSBvZiB0aGlzIHNwZWNpZmljYXRpb24sCgkgIGFueSA8c3Bhbnggc3R5bGU9J3Zl cmInPmVycm9yPC9zcGFueD4gY29kZSB2YWx1ZXMgZGVmaW5lZCBmb3IgdXNlIHdpdGgKCSAgT0F1 dGggcmVzb3VyY2UgYWNjZXNzIG1ldGhvZHMgTVVTVCBiZSByZWdpc3RlcmVkCgkgIChmb2xsb3dp bmcgdGhlIHByb2NlZHVyZXMgaW4gPHhyZWYgdGFyZ2V0PSdlcnJvci1yZWdpc3RyeScgLz4pLgoJ PC90PgoJPHQ+CgkgIFNwZWNpZmljYWxseSwgd2hlbiB0aGUgT0F1dGggcmVzb3VyY2UgYWNjZXNz IG1ldGhvZCB1c2VzIGFuCgkgIDxzcGFueCBzdHlsZT0ndmVyYic+ZXJyb3I8L3NwYW54PiByZXN1 bHQgcGFyYW1ldGVyIHRvIHJldHVybgoJICBhbiBlcnJvciBjb2RlIHZhbHVlIHRoYXQgaW5kaWNh dGVzIHRoZSByZXNvdXJjZSBhY2Nlc3MgZXJyb3IKCSAgZW5jb3VudGVyZWQsIHRoZW4gdGhlc2Ug ZXJyb3IgY29kZSB2YWx1ZXMgTVVTVCBiZSByZWdpc3RlcmVkLgoJICBWYWx1ZXMgZm9yIHRoZXNl IDxzcGFueCBzdHlsZT0ndmVyYic+ZXJyb3I8L3NwYW54PiBjb2RlcyBNVVNUIE5PVCBpbmNsdWRl CgkgIGNoYXJhY3RlcnMgb3V0c2lkZSB0aGUgc2V0ICV4MjAtMjEgLyAleDIzLTVCIC8gJXg1RC03 RS4KCSAgV2hlbiBhbiAgPHNwYW54IHN0eWxlPSd2ZXJiJz5lcnJvcjwvc3Bhbng+IGNvZGUgdmFs dWUgaXMgcmVnaXN0ZXJlZAoJICBmb3IgdXNlIGJ5IGFuIE9BdXRoIHJlc291cmNlIGFjY2VzcyBt ZXRob2QsIHNob3VsZCB0aGF0IHNhbWUgY29kZSBhbHJlYWR5CgkgIGJlIHJlZ2lzdGVyZWQgZm9y IHVzZSBieSBhbm90aGVyIE9BdXRoIHJlc291cmNlIGFjY2VzcyBtZXRob2Qgb3IgYXQKCSAgYSBk aWZmZXJlbnQgT0F1dGggZXJyb3IgdXNhZ2UgbG9jYXRpb24sIHRoZW4gdGhlIG1lYW5pbmcgb2Yg dGhhdCBlcnJvciBjb2RlCgkgIHZhbHVlIGluIGluIHRoZSBuZXcgcmVnaXN0cmF0aW9uIE1VU1Qg YmUgY29uc2lzdGVudCB3aXRoIHRoZSBpdHMgbWVhbmluZwoJICBpbiBwcmlvciByZWdpc3RyYXRp b25zLgoJPC90PgoJPHQ+CgkgIFRoZSBPQXV0aCByZXNvdXJjZSBhY2Nlc3MgZXJyb3IgcmVnaXN0 cmF0aW9uIHJlcXVpcmVtZW50IGFwcGxpZXMgb25seSB0bwoJICA8c3Bhbnggc3R5bGU9J3ZlcmIn PmVycm9yPC9zcGFueD4gY29kZSB2YWx1ZXMgYW5kIG5vdCB0byBvdGhlcgoJICBtZWFucyBvZiBy ZXR1cm5pbmcgZXJyb3IgaW5kaWNhdGlvbnMsIGluY2x1ZGluZyBIVFRQIHN0YXR1cyBjb2RlcywK CSAgb3Igb3RoZXIgZXJyb3ItcmVsYXRlZCByZXN1bHQgcGFyYW1ldGVycywgc3VjaCBhcwoJICA8 c3Bhbnggc3R5bGU9J3ZlcmInPmVycm9yX2Rlc2NyaXB0aW9uPC9zcGFueD4sCgkgIDxzcGFueCBz dHlsZT0ndmVyYic+ZXJyb3JfdXJpPC9zcGFueD4sIG9yIG90aGVyIGtpbmRzIG9mIGVycm9yCgkg IHN0YXR1cyByZXR1cm4gbWV0aG9kcyB0aGF0IG1heSBiZSBlbXBsb3llZCBieSB0aGUgcmVzb3Vy Y2UgYWNjZXNzIG1ldGhvZC4KCSAgVGhlcmUgaXMgbm8gcmVxdWlyZW1lbnQgdGhhdCBPQXV0aCBy ZXNvdXJjZSBhY2Nlc3MgbWV0aG9kcwoJICBlbXBsb3kgYW4gPHNwYW54IHN0eWxlPSd2ZXJiJz5l cnJvcjwvc3Bhbng+IHBhcmFtZXRlci4KCTwvdD4KICAgICAgPC9zZWN0aW9uPgoKICAgIDwvc2Vj dGlvbj4KCiAgICA8c2VjdGlvbiB0aXRsZT0nRXh0ZW5zaWJpbGl0eScgYW5jaG9yPSdleHRlbnNp b25zJz4KCiAgICAgIDxzZWN0aW9uIHRpdGxlPSdEZWZpbmluZyBBY2Nlc3MgVG9rZW4gVHlwZXMn IGFuY2hvcj0nbmV3LXR5cGVzJz4KICAgICAgICA8dD4KICAgICAgICAgIEFjY2VzcyB0b2tlbiB0 eXBlcyBjYW4gYmUgZGVmaW5lZCBpbiBvbmUgb2YgdHdvIHdheXM6IHJlZ2lzdGVyZWQgaW4gdGhl IGFjY2VzcyB0b2tlbiB0eXBlCiAgICAgICAgICByZWdpc3RyeSAoZm9sbG93aW5nIHRoZSBwcm9j ZWR1cmVzIGluIDx4cmVmIHRhcmdldD0ndHlwZS1yZWdpc3RyeScgLz4pLCBvciBieSB1c2luZyBh CiAgICAgICAgICB1bmlxdWUgYWJzb2x1dGUgVVJJIGFzIGl0cyBuYW1lLgogICAgICAgIDwvdD4K ICAgICAgICA8dD4KICAgICAgICAgIFR5cGVzIHV0aWxpemluZyBhIFVSSSBuYW1lIFNIT1VMRCBi ZSBsaW1pdGVkIHRvIHZlbmRvci1zcGVjaWZpYyBpbXBsZW1lbnRhdGlvbnMgdGhhdCBhcmUKICAg ICAgICAgIG5vdCBjb21tb25seSBhcHBsaWNhYmxlLCBhbmQgYXJlIHNwZWNpZmljIHRvIHRoZSBp bXBsZW1lbnRhdGlvbiBkZXRhaWxzIG9mIHRoZSByZXNvdXJjZQogICAgICAgICAgc2VydmVyIHdo ZXJlIHRoZXkgYXJlIHVzZWQuCiAgICAgICAgPC90PgogICAgICAgIDx0PgogICAgICAgICAgQWxs IG90aGVyIHR5cGVzIE1VU1QgYmUgcmVnaXN0ZXJlZC4gVHlwZSBuYW1lcyBNVVNUIGNvbmZvcm0g dG8gdGhlIHR5cGUtbmFtZSBBQk5GLiBJZiB0aGUKICAgICAgICAgIHR5cGUgZGVmaW5pdGlvbiBp bmNsdWRlcyBhIG5ldyBIVFRQIGF1dGhlbnRpY2F0aW9uIHNjaGVtZSwgdGhlIHR5cGUgbmFtZSBT SE9VTEQgYmUKICAgICAgICAgIGlkZW50aWNhbCB0byB0aGUgSFRUUCBhdXRoZW50aWNhdGlvbiBz Y2hlbWUgbmFtZSAoYXMgZGVmaW5lZCBieSA8eHJlZiB0YXJnZXQ9J1JGQzI2MTcnIC8+KS4KICAg ICAgICAgIFRoZSB0b2tlbiB0eXBlIDxzcGFueCBzdHlsZT0ndmVyYic+ZXhhbXBsZTwvc3Bhbng+ IGlzIHJlc2VydmVkIGZvciB1c2UgaW4gZXhhbXBsZXMuCiAgICAgICAgPC90PgogICAgICAgIDxm aWd1cmU+CiAgICAgICAgICA8YXJ0d29yaz4KICAgICAgICAgICAgPCFbQ0RBVEFbCiAgdHlwZS1u YW1lICA9IDEqbmFtZS1jaGFyCiAgbmFtZS1jaGFyICA9ICItIiAvICIuIiAvICJfIiAvIERJR0lU IC8gQUxQSEEKXV0+CiAgICAgICAgICA8L2FydHdvcms+CiAgICAgICAgPC9maWd1cmU+CiAgICAg IDwvc2VjdGlvbj4KCiAgICAgIDxzZWN0aW9uIHRpdGxlPSdEZWZpbmluZyBOZXcgRW5kcG9pbnQg UGFyYW1ldGVycycgYW5jaG9yPSJlbmRwb2ludC1wYXJhbXMiPgogICAgICAgIDx0PgogICAgICAg ICAgTmV3IHJlcXVlc3Qgb3IgcmVzcG9uc2UgcGFyYW1ldGVycyBmb3IgdXNlIHdpdGggdGhlIGF1 dGhvcml6YXRpb24gZW5kcG9pbnQgb3IgdGhlIHRva2VuCiAgICAgICAgICBlbmRwb2ludCBhcmUg ZGVmaW5lZCBhbmQgcmVnaXN0ZXJlZCBpbiB0aGUgcGFyYW1ldGVycyByZWdpc3RyeSBmb2xsb3dp bmcgdGhlIHByb2NlZHVyZSBpbgogICAgICAgICAgPHhyZWYgdGFyZ2V0PSdwYXJhbWV0ZXJzLXJl Z2lzdHJ5JyAvPi4KICAgICAgICA8L3Q+CiAgICAgICAgPHQ+CiAgICAgICAgICBQYXJhbWV0ZXIg bmFtZXMgTVVTVCBjb25mb3JtIHRvIHRoZSBwYXJhbS1uYW1lIEFCTkYgYW5kIHBhcmFtZXRlciB2 YWx1ZXMgc3ludGF4IE1VU1QgYmUKICAgICAgICAgIHdlbGwtZGVmaW5lZCAoZS5nLiwgdXNpbmcg QUJORiwgb3IgYSByZWZlcmVuY2UgdG8gdGhlIHN5bnRheCBvZiBhbiBleGlzdGluZyBwYXJhbWV0 ZXIpLgogICAgICAgIDwvdD4KICAgICAgICA8ZmlndXJlPgogICAgICAgICAgPGFydHdvcms+CiAg ICAgICAgICAgIDwhW0NEQVRBWwogIHBhcmFtLW5hbWUgID0gMSpuYW1lLWNoYXIKICBuYW1lLWNo YXIgICA9ICItIiAvICIuIiAvICJfIiAvIERJR0lUIC8gQUxQSEEKXV0+CiAgICAgICAgICA8L2Fy dHdvcms+CiAgICAgICAgPC9maWd1cmU+CiAgICAgICAgPHQ+CiAgICAgICAgICBVbnJlZ2lzdGVy ZWQgdmVuZG9yLXNwZWNpZmljIHBhcmFtZXRlciBleHRlbnNpb25zIHRoYXQgYXJlIG5vdCBjb21t b25seSBhcHBsaWNhYmxlLCBhbmQKICAgICAgICAgIGFyZSBzcGVjaWZpYyB0byB0aGUgaW1wbGVt ZW50YXRpb24gZGV0YWlscyBvZiB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgd2hlcmUgdGhleSBh cmUKICAgICAgICAgIHVzZWQgU0hPVUxEIHV0aWxpemUgYSB2ZW5kb3Itc3BlY2lmaWMgcHJlZml4 IHRoYXQgaXMgbm90IGxpa2VseSB0byBjb25mbGljdCB3aXRoIG90aGVyCiAgICAgICAgICByZWdp c3RlcmVkIHZhbHVlcyAoZS5nLiBiZWdpbiB3aXRoICdjb21wYW55bmFtZV8nKS4KICAgICAgICA8 L3Q+CiAgICAgIDwvc2VjdGlvbj4KCiAgICAgIDxzZWN0aW9uIHRpdGxlPSdEZWZpbmluZyBOZXcg QXV0aG9yaXphdGlvbiBHcmFudCBUeXBlcyc+CiAgICAgICAgPHQ+CiAgICAgICAgICBOZXcgYXV0 aG9yaXphdGlvbiBncmFudCB0eXBlcyBjYW4gYmUgZGVmaW5lZCBieSBhc3NpZ25pbmcgdGhlbSBh IHVuaXF1ZSBhYnNvbHV0ZSBVUkkgZm9yCiAgICAgICAgICB1c2Ugd2l0aCB0aGUgPHNwYW54IHN0 eWxlPSd2ZXJiJz5ncmFudF90eXBlPC9zcGFueD4gcGFyYW1ldGVyLiBJZiB0aGUgZXh0ZW5zaW9u IGdyYW50CiAgICAgICAgICB0eXBlIHJlcXVpcmVzIGFkZGl0aW9uYWwgdG9rZW4gZW5kcG9pbnQg cGFyYW1ldGVycywgdGhleSBNVVNUIGJlIHJlZ2lzdGVyZWQgaW4gdGhlIE9BdXRoCiAgICAgICAg ICBwYXJhbWV0ZXJzIHJlZ2lzdHJ5IGFzIGRlc2NyaWJlZCBieSA8eHJlZiB0YXJnZXQ9J3BhcmFt ZXRlcnMtcmVnaXN0cnknIC8+LgogICAgICAgIDwvdD4KICAgICAgPC9zZWN0aW9uPgoKICAgICAg PHNlY3Rpb24gdGl0bGU9J0RlZmluaW5nIE5ldyBBdXRob3JpemF0aW9uIEVuZHBvaW50IFJlc3Bv bnNlIFR5cGVzJyBhbmNob3I9J3Jlc3BvbnNlLXR5cGUtZXh0Jz4KICAgICAgICA8dD4KICAgICAg ICAgIE5ldyByZXNwb25zZSB0eXBlcyBmb3IgdXNlIHdpdGggdGhlIGF1dGhvcml6YXRpb24gZW5k cG9pbnQgYXJlIGRlZmluZWQgYW5kIHJlZ2lzdGVyZWQgaW4KICAgICAgICAgIHRoZSBhdXRob3Jp emF0aW9uIGVuZHBvaW50IHJlc3BvbnNlIHR5cGUgcmVnaXN0cnkgZm9sbG93aW5nIHRoZSBwcm9j ZWR1cmUgaW4KICAgICAgICAgIDx4cmVmIHRhcmdldD0ncmVzcG9uc2UtdHlwZS1yZWdpc3RyeScg Lz4uIFJlc3BvbnNlIHR5cGUgbmFtZXMgTVVTVCBjb25mb3JtIHRvIHRoZQogICAgICAgICAgcmVz cG9uc2UtdHlwZSBBQk5GLgogICAgICAgIDwvdD4KICAgICAgICA8ZmlndXJlPgogICAgICAgICAg PGFydHdvcms+CiAgICAgICAgICAgIDwhW0NEQVRBWwogIHJlc3BvbnNlLXR5cGUgID0gcmVzcG9u c2UtbmFtZSAqKCBTUCByZXNwb25zZS1uYW1lICkKICByZXNwb25zZS1uYW1lICA9IDEqcmVzcG9u c2UtY2hhcgogIHJlc3BvbnNlLWNoYXIgID0gIl8iIC8gRElHSVQgLyBBTFBIQQpdXT4KICAgICAg ICAgIDwvYXJ0d29yaz4KICAgICAgICA8L2ZpZ3VyZT4KICAgICAgICA8dD4KICAgICAgICAgIElm IGEgcmVzcG9uc2UgdHlwZSBjb250YWlucyBvbmUgb3IgbW9yZSBzcGFjZSBjaGFyYWN0ZXJzICgl eDIwKSwgaXQgaXMgY29tcGFyZWQgYXMgYQogICAgICAgICAgc3BhY2UtZGVsaW1pdGVkIGxpc3Qg b2YgdmFsdWVzIGluIHdoaWNoIHRoZSBvcmRlciBvZiB2YWx1ZXMgZG9lcyBub3QgbWF0dGVyLiBP bmx5IG9uZQogICAgICAgICAgb3JkZXIgb2YgdmFsdWVzIGNhbiBiZSByZWdpc3RlcmVkLCB3aGlj aCBjb3ZlcnMgYWxsIG90aGVyIGFycmFuZ2VtZW50cyBvZiB0aGUgc2FtZSBzZXQgb2YKICAgICAg ICAgIHZhbHVlcy4KICAgICAgICA8L3Q+CiAgICAgICAgPHQ+CiAgICAgICAgICBGb3IgZXhhbXBs ZSwgdGhlIHJlc3BvbnNlIHR5cGUgPHNwYW54IHN0eWxlPSd2ZXJiJz50b2tlbiBjb2RlPC9zcGFu eD4gaXMgbGVmdCB1bmRlZmluZWQKICAgICAgICAgIGJ5IHRoaXMgc3BlY2lmaWNhdGlvbi4gSG93 ZXZlciwgYW4gZXh0ZW5zaW9uIGNhbiBkZWZpbmUgYW5kIHJlZ2lzdGVyIHRoZQogICAgICAgICAg PHNwYW54IHN0eWxlPSd2ZXJiJz50b2tlbiBjb2RlPC9zcGFueD4gcmVzcG9uc2UgdHlwZS4gT25j ZSByZWdpc3RlcmVkLCB0aGUgc2FtZQogICAgICAgICAgY29tYmluYXRpb24gY2Fubm90IGJlIHJl Z2lzdGVyZWQgYXMgPHNwYW54IHN0eWxlPSd2ZXJiJz5jb2RlIHRva2VuPC9zcGFueD4sIGJ1dCBi b3RoCiAgICAgICAgICB2YWx1ZXMgY2FuIGJlIHVzZWQgdG8gZGVub3RlIHRoZSBzYW1lIHJlc3Bv bnNlIHR5cGUuCiAgICAgICAgPC90PgogICAgICA8L3NlY3Rpb24+CgogICAgICA8c2VjdGlvbiB0 aXRsZT0nRGVmaW5pbmcgQWRkaXRpb25hbCBFcnJvciBDb2RlcycgYW5jaG9yPSduZXctZXJyb3Jz Jz4KICAgICAgICA8dD4KICAgICAgICAgIEluIGNhc2VzIHdoZXJlIHByb3RvY29sIGV4dGVuc2lv bnMgKGkuZS4gYWNjZXNzIHRva2VuIHR5cGVzLCBleHRlbnNpb24gcGFyYW1ldGVycywgb3IKICAg ICAgICAgIGV4dGVuc2lvbiBncmFudCB0eXBlcykgcmVxdWlyZSBhZGRpdGlvbmFsIGVycm9yIGNv ZGVzIHRvIGJlIHVzZWQgd2l0aCB0aGUgYXV0aG9yaXphdGlvbgogICAgICAgICAgY29kZSBncmFu dCBlcnJvciByZXNwb25zZSAoPHhyZWYgdGFyZ2V0PSdjb2RlLWF1dGh6LWVycm9yJyAvPiksIHRo ZSBpbXBsaWNpdCBncmFudCBlcnJvcgogICAgICAgICAgcmVzcG9uc2UgKDx4cmVmIHRhcmdldD0n aW1wbGljaXQtYXV0aHotZXJyb3InIC8+KSwgdGhlIHRva2VuIGVycm9yIHJlc3BvbnNlCiAgICAg ICAgICAoPHhyZWYgdGFyZ2V0PSd0b2tlbi1lcnJvcnMnIC8+KSwKCSAgb3IgdGhlIHJlc291cmNl IGFjY2VzcyBlcnJvciByZXNwb25zZSAoPHhyZWYgdGFyZ2V0PSdyZXNvdXJjZS1lcnJvcnMnIC8+ KSwKCSAgc3VjaCBlcnJvciBjb2RlcyBNQVkgYmUgZGVmaW5lZC4KICAgICAgICA8L3Q+CiAgICAg ICAgPHQ+CiAgICAgICAgICBFeHRlbnNpb24gZXJyb3IgY29kZXMgTVVTVCBiZSByZWdpc3RlcmVk IChmb2xsb3dpbmcgdGhlIHByb2NlZHVyZXMgaW4KICAgICAgICAgIDx4cmVmIHRhcmdldD0nZXJy b3ItcmVnaXN0cnknIC8+KSBpZiB0aGUgZXh0ZW5zaW9uIHRoZXkgYXJlIHVzZWQgaW4gY29uanVu Y3Rpb24gd2l0aCBpcwogICAgICAgICAgYSByZWdpc3RlcmVkIGFjY2VzcyB0b2tlbiB0eXBlLCBh IHJlZ2lzdGVyZWQgZW5kcG9pbnQgcGFyYW1ldGVyLCBvciBhbiBleHRlbnNpb24gZ3JhbnQKICAg ICAgICAgIHR5cGUuIEVycm9yIGNvZGVzIHVzZWQgd2l0aCB1bnJlZ2lzdGVyZWQgZXh0ZW5zaW9u cyBNQVkgYmUgcmVnaXN0ZXJlZC4KICAgICAgICA8L3Q+CiAgICAgICAgPHQ+CiAgICAgICAgICBF cnJvciBjb2RlcyBNVVNUIGNvbmZvcm0gdG8gdGhlIGVycm9yIEFCTkYsIGFuZCBTSE9VTEQgYmUg cHJlZml4ZWQgYnkgYW4gaWRlbnRpZnlpbmcKICAgICAgICAgIG5hbWUgd2hlbiBwb3NzaWJsZS4g Rm9yIGV4YW1wbGUsIGFuIGVycm9yIGlkZW50aWZ5aW5nIGFuIGludmFsaWQgdmFsdWUgc2V0IHRv IHRoZQogICAgICAgICAgZXh0ZW5zaW9uIHBhcmFtZXRlciA8c3Bhbnggc3R5bGU9J3ZlcmInPmV4 YW1wbGU8L3NwYW54PiBTSE9VTEQgYmUgbmFtZWQKICAgICAgICAgIDxzcGFueCBzdHlsZT0ndmVy Yic+ZXhhbXBsZV9pbnZhbGlkPC9zcGFueD4uCiAgICAgICAgPC90PgogICAgICAgIDxmaWd1cmU+ CiAgICAgICAgICA8YXJ0d29yaz4KICAgICAgICAgICAgPCFbQ0RBVEFbCiAgZXJyb3IgICAgICA9 IDEqZXJyb3ItY2hhcgogIGVycm9yLWNoYXIgPSAleDIwLTIxIC8gJXgyMy01QiAvICV4NUQtN0UK XV0+CiAgICAgICAgICA8L2FydHdvcms+CiAgICAgICAgPC9maWd1cmU+CiAgICAgIDwvc2VjdGlv bj4KCiAgICA8L3NlY3Rpb24+CgogICAgPHNlY3Rpb24gdGl0bGU9J05hdGl2ZSBBcHBsaWNhdGlv bnMnPgogICAgICA8dD4KICAgICAgICBOYXRpdmUgYXBwbGljYXRpb25zIGFyZSBjbGllbnRzIGlu c3RhbGxlZCBhbmQgZXhlY3V0ZWQgb24gdGhlIGRldmljZSB1c2VkIGJ5IHRoZSByZXNvdXJjZQog ICAgICAgIG93bmVyIChpLmUuIGRlc2t0b3AgYXBwbGljYXRpb24sIG5hdGl2ZSBtb2JpbGUgYXBw bGljYXRpb24pLiBOYXRpdmUgYXBwbGljYXRpb25zIHJlcXVpcmUKICAgICAgICBzcGVjaWFsIGNv bnNpZGVyYXRpb24gcmVsYXRlZCB0byBzZWN1cml0eSwgcGxhdGZvcm0gY2FwYWJpbGl0aWVzLCBh bmQgb3ZlcmFsbCBlbmQtdXNlcgogICAgICAgIGV4cGVyaWVuY2UuCiAgICAgIDwvdD4KICAgICAg PHQ+CiAgICAgICAgVGhlIGF1dGhvcml6YXRpb24gZW5kcG9pbnQgcmVxdWlyZXMgaW50ZXJhY3Rp b24gYmV0d2VlbiB0aGUgY2xpZW50IGFuZCB0aGUgcmVzb3VyY2UKICAgICAgICBvd25lcidzIHVz ZXItYWdlbnQuIE5hdGl2ZSBhcHBsaWNhdGlvbnMgY2FuIGludm9rZSBhbiBleHRlcm5hbCB1c2Vy LWFnZW50IG9yIGVtYmVkIGEKICAgICAgICB1c2VyLWFnZW50IHdpdGhpbiB0aGUgYXBwbGljYXRp b24uIEZvciBleGFtcGxlOgogICAgICA8L3Q+CiAgICAgIDx0PgogICAgICAgIDxsaXN0IHN0eWxl PSdzeW1ib2xzJz4KICAgICAgICAgIDx0PgogICAgICAgICAgICBFeHRlcm5hbCB1c2VyLWFnZW50 IC0gdGhlIG5hdGl2ZSBhcHBsaWNhdGlvbiBjYW4gY2FwdHVyZSB0aGUgcmVzcG9uc2UgZnJvbSB0 aGUKICAgICAgICAgICAgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgdXNpbmcgYSByZWRpcmVjdGlvbiBV Ukkgd2l0aCBhIHNjaGVtZSByZWdpc3RlcmVkIHdpdGggdGhlCiAgICAgICAgICAgIG9wZXJhdGlu ZyBzeXN0ZW0gdG8gaW52b2tlIHRoZSBjbGllbnQgYXMgdGhlIGhhbmRsZXIsIG1hbnVhbCBjb3B5 LWFuZC1wYXN0ZSBvZiB0aGUKICAgICAgICAgICAgY3JlZGVudGlhbHMsIHJ1bm5pbmcgYSBsb2Nh bCB3ZWIgc2VydmVyLCBpbnN0YWxsaW5nIGEgdXNlci1hZ2VudCBleHRlbnNpb24sIG9yIGJ5CiAg ICAgICAgICAgIHByb3ZpZGluZyBhIHJlZGlyZWN0aW9uIFVSSSBpZGVudGlmeWluZyBhIHNlcnZl ci1ob3N0ZWQgcmVzb3VyY2UgdW5kZXIgdGhlIGNsaWVudCdzCiAgICAgICAgICAgIGNvbnRyb2ws IHdoaWNoIGluIHR1cm4gbWFrZXMgdGhlIHJlc3BvbnNlIGF2YWlsYWJsZSB0byB0aGUgbmF0aXZl IGFwcGxpY2F0aW9uLgogICAgICAgICAgPC90PgogICAgICAgICAgPHQ+CiAgICAgICAgICAgIEVt YmVkZGVkIHVzZXItYWdlbnQgLSB0aGUgbmF0aXZlIGFwcGxpY2F0aW9uIG9idGFpbnMgdGhlIHJl c3BvbnNlIGJ5IGRpcmVjdGx5CiAgICAgICAgICAgIGNvbW11bmljYXRpbmcgd2l0aCB0aGUgZW1i ZWRkZWQgdXNlci1hZ2VudCBieSBtb25pdG9yaW5nIHN0YXRlIGNoYW5nZXMgZW1pdHRlZCBkdXJp bmcKICAgICAgICAgICAgdGhlIHJlc291cmNlIGxvYWQsIG9yIGFjY2Vzc2luZyB0aGUgdXNlci1h Z2VudCdzIGNvb2tpZXMgc3RvcmFnZS4KICAgICAgICAgIDwvdD4KICAgICAgICA8L2xpc3Q+CiAg ICAgIDwvdD4KICAgICAgPHQ+CiAgICAgICAgV2hlbiBjaG9vc2luZyBiZXR3ZWVuIGFuIGV4dGVy bmFsIG9yIGVtYmVkZGVkIHVzZXItYWdlbnQsIGRldmVsb3BlcnMgc2hvdWxkIGNvbnNpZGVyOgog ICAgICA8L3Q+CiAgICAgIDx0PgogICAgICAgIDxsaXN0IHN0eWxlPSdzeW1ib2xzJz4KICAgICAg ICAgIDx0PgogICAgICAgICAgICBBbiBFeHRlcm5hbCB1c2VyLWFnZW50IG1heSBpbXByb3ZlIGNv bXBsZXRpb24gcmF0ZSBhcyB0aGUgcmVzb3VyY2Ugb3duZXIgbWF5IGFscmVhZHkgaGF2ZQogICAg ICAgICAgICBhbiBhY3RpdmUgc2Vzc2lvbiB3aXRoIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBy ZW1vdmluZyB0aGUgbmVlZCB0byByZS1hdXRoZW50aWNhdGUuIEl0CiAgICAgICAgICAgIHByb3Zp ZGVzIGEgZmFtaWxpYXIgZW5kLXVzZXIgZXhwZXJpZW5jZSBhbmQgZnVuY3Rpb25hbGl0eS4gVGhl IHJlc291cmNlIG93bmVyIG1heSBhbHNvCiAgICAgICAgICAgIHJlbHkgb24gdXNlci1hZ2VudCBm ZWF0dXJlcyBvciBleHRlbnNpb25zIHRvIGFzc2lzdCB3aXRoIGF1dGhlbnRpY2F0aW9uIChlLmcu IHBhc3N3b3JkCiAgICAgICAgICAgIG1hbmFnZXIsIDItZmFjdG9yIGRldmljZSByZWFkZXIpLgog ICAgICAgICAgPC90PgogICAgICAgICAgPHQ+CiAgICAgICAgICAgIEFuIGVtYmVkZGVkIHVzZXIt YWdlbnQgbWF5IG9mZmVyIGltcHJvdmVkIHVzYWJpbGl0eSwgYXMgaXQgcmVtb3ZlcyB0aGUgbmVl ZCB0byBzd2l0Y2gKICAgICAgICAgICAgY29udGV4dCBhbmQgb3BlbiBuZXcgd2luZG93cy4KICAg ICAgICAgIDwvdD4KICAgICAgICAgIDx0PgogICAgICAgICAgICBBbiBlbWJlZGRlZCB1c2VyLWFn ZW50IHBvc2VzIGEgc2VjdXJpdHkgY2hhbGxlbmdlIGJlY2F1c2UgcmVzb3VyY2Ugb3duZXJzIGFy ZQogICAgICAgICAgICBhdXRoZW50aWNhdGluZyBpbiBhbiB1bmlkZW50aWZpZWQgd2luZG93IHdp dGhvdXQgYWNjZXNzIHRvIHRoZSB2aXN1YWwgcHJvdGVjdGlvbnMgZm91bmQKICAgICAgICAgICAg aW4gbW9zdCBleHRlcm5hbCB1c2VyLWFnZW50cy4gQW4gZW1iZWRkZWQgdXNlci1hZ2VudCBlZHVj YXRlcyBlbmQtdXNlcnMgdG8gdHJ1c3QKICAgICAgICAgICAgdW5pZGVudGlmaWVkIHJlcXVlc3Rz IGZvciBhdXRoZW50aWNhdGlvbiAobWFraW5nIHBoaXNoaW5nIGF0dGFja3MgZWFzaWVyIHRvIGV4 ZWN1dGUpLgogICAgICAgICAgPC90PgogICAgICAgIDwvbGlzdD4KICAgICAgPC90PgogICAgICA8 dD4KICAgICAgICBXaGVuIGNob29zaW5nIGJldHdlZW4gdGhlIGltcGxpY2l0IGdyYW50IHR5cGUg YW5kIHRoZSBhdXRob3JpemF0aW9uIGNvZGUgZ3JhbnQgdHlwZSwgdGhlCiAgICAgICAgZm9sbG93 aW5nIHNob3VsZCBiZSBjb25zaWRlcmVkOgogICAgICA8L3Q+CiAgICAgIDx0PgogICAgICAgIDxs aXN0IHN0eWxlPSdzeW1ib2xzJz4KICAgICAgICAgIDx0PgogICAgICAgICAgICBOYXRpdmUgYXBw bGljYXRpb25zIHRoYXQgdXNlIHRoZSBhdXRob3JpemF0aW9uIGNvZGUgZ3JhbnQgdHlwZSBTSE9V TEQgZG8gc28gd2l0aG91dAogICAgICAgICAgICB1c2luZyBjbGllbnQgY3JlZGVudGlhbHMsIGR1 ZSB0byB0aGUgbmF0aXZlIGFwcGxpY2F0aW9uJ3MgaW5hYmlsaXR5IHRvIGtlZXAgY2xpZW50CiAg ICAgICAgICAgIGNyZWRlbnRpYWxzIGNvbmZpZGVudGlhbC4KICAgICAgICAgIDwvdD4KICAgICAg ICAgIDx0PgogICAgICAgICAgICBXaGVuIHVzaW5nIHRoZSBpbXBsaWNpdCBncmFudCB0eXBlIGZs b3cgYSByZWZyZXNoIHRva2VuIGlzIG5vdCByZXR1cm5lZCB3aGljaCByZXF1aXJlcwogICAgICAg ICAgICByZXBlYXRpbmcgdGhlIGF1dGhvcml6YXRpb24gcHJvY2VzcyBvbmNlIHRoZSBhY2Nlc3Mg dG9rZW4gZXhwaXJlcy4KICAgICAgICAgIDwvdD4KICAgICAgICA8L2xpc3Q+CiAgICAgIDwvdD4K ICAgIDwvc2VjdGlvbj4KCiAgICA8c2VjdGlvbiB0aXRsZT0nU2VjdXJpdHkgQ29uc2lkZXJhdGlv bnMnPgogICAgICA8dD4KICAgICAgICBBcyBhIGZsZXhpYmxlIGFuZCBleHRlbnNpYmxlIGZyYW1l d29yaywgT0F1dGgncyBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBkZXBlbmQgb24gbWFueQogICAg ICAgIGZhY3RvcnMuIFRoZSBmb2xsb3dpbmcgc2VjdGlvbnMgcHJvdmlkZSBpbXBsZW1lbnRlcnMg d2l0aCBzZWN1cml0eSBndWlkZWxpbmVzIGZvY3VzZWQgb24KICAgICAgICB0aGUgdGhyZWUgY2xp ZW50IHByb2ZpbGVzIGRlc2NyaWJlZCBpbiA8eHJlZiB0YXJnZXQ9J2NsaWVudC10eXBlcycgLz46 IHdlYiBhcHBsaWNhdGlvbiwKICAgICAgICB1c2VyLWFnZW50LWJhc2VkIGFwcGxpY2F0aW9uLCBh bmQgbmF0aXZlIGFwcGxpY2F0aW9uLgogICAgICA8L3Q+CiAgICAgIDx0PgogICAgICAgIEEgY29t cHJlaGVuc2l2ZSBPQXV0aCBzZWN1cml0eSBtb2RlbCBhbmQgYW5hbHlzaXMsIGFzIHdlbGwgYXMg YmFja2dyb3VuZCBmb3IgdGhlIHByb3RvY29sCiAgICAgICAgZGVzaWduIGlzIHByb3ZpZGVkIGJ5 IDx4cmVmIHRhcmdldD0nSS1ELmlldGYtb2F1dGgtdjItdGhyZWF0bW9kZWwnIC8+LgogICAgICA8 L3Q+CgogICAgICA8c2VjdGlvbiB0aXRsZT0nQ2xpZW50IEF1dGhlbnRpY2F0aW9uJz4KICAgICAg ICA8dD4KICAgICAgICAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBlc3RhYmxpc2hlcyBjbGll bnQgY3JlZGVudGlhbHMgd2l0aCB3ZWIgYXBwbGljYXRpb24gY2xpZW50cyBmb3IKICAgICAgICAg IHRoZSBwdXJwb3NlIG9mIGNsaWVudCBhdXRoZW50aWNhdGlvbi4gVGhlIGF1dGhvcml6YXRpb24g c2VydmVyIGlzIGVuY291cmFnZWQgdG8gY29uc2lkZXIKICAgICAgICAgIHN0cm9uZ2VyIGNsaWVu dCBhdXRoZW50aWNhdGlvbiBtZWFucyB0aGFuIGEgY2xpZW50IHBhc3N3b3JkLiBXZWIgYXBwbGlj YXRpb24gY2xpZW50cyBNVVNUCiAgICAgICAgICBlbnN1cmUgY29uZmlkZW50aWFsaXR5IG9mIGNs aWVudCBwYXNzd29yZHMgYW5kIG90aGVyIGNsaWVudCBjcmVkZW50aWFscy4KICAgICAgICA8L3Q+ CiAgICAgICAgPHQ+CiAgICAgICAgICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVTVCBOT1Qg aXNzdWUgY2xpZW50IHBhc3N3b3JkcyBvciBvdGhlciBjbGllbnQgY3JlZGVudGlhbHMgdG8KICAg ICAgICAgIG5hdGl2ZSBhcHBsaWNhdGlvbiBvciB1c2VyLWFnZW50LWJhc2VkIGFwcGxpY2F0aW9u IGNsaWVudHMgZm9yIHRoZSBwdXJwb3NlIG9mIGNsaWVudAogICAgICAgICAgYXV0aGVudGljYXRp b24uIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBNQVkgaXNzdWUgYSBjbGllbnQgcGFzc3dvcmQg b3Igb3RoZXIgY3JlZGVudGlhbHMKICAgICAgICAgIGZvciBhIHNwZWNpZmljIGluc3RhbGxhdGlv biBvZiBhIG5hdGl2ZSBhcHBsaWNhdGlvbiBjbGllbnQgb24gYSBzcGVjaWZpYyBkZXZpY2UuCiAg ICAgICAgPC90PgogICAgICAgIDx0PgogICAgICAgICAgV2hlbiBjbGllbnQgYXV0aGVudGljYXRp b24gaXMgbm90IHBvc3NpYmxlLCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgU0hPVUxEIGVtcGxv eSBvdGhlcgogICAgICAgICAgbWVhbnMgdG8gdmFsaWRhdGUgdGhlIGNsaWVudCdzIGlkZW50aXR5 LiBGb3IgZXhhbXBsZSwgYnkgcmVxdWlyaW5nIHRoZSByZWdpc3RyYXRpb24gb2YKICAgICAgICAg IHRoZSBjbGllbnQgcmVkaXJlY3Rpb24gVVJJIG9yIGVubGlzdGluZyB0aGUgcmVzb3VyY2Ugb3du ZXIgdG8gY29uZmlybSBpZGVudGl0eS4gQSB2YWxpZAogICAgICAgICAgcmVkaXJlY3Rpb24gVVJJ IGlzIG5vdCBzdWZmaWNpZW50IHRvIHZlcmlmeSB0aGUgY2xpZW50J3MgaWRlbnRpdHkgd2hlbiBh c2tpbmcgZm9yCiAgICAgICAgICByZXNvdXJjZSBvd25lciBhdXRob3JpemF0aW9uLCBidXQgY2Fu IGJlIHVzZWQgdG8gcHJldmVudCBkZWxpdmVyaW5nIGNyZWRlbnRpYWxzIHRvIGEKICAgICAgICAg IGNvdW50ZXJmZWl0IGNsaWVudCBhZnRlciBvYnRhaW5pbmcgcmVzb3VyY2Ugb3duZXIgYXV0aG9y aXphdGlvbi4KICAgICAgICA8L3Q+CiAgICAgICAgPHQ+CiAgICAgICAgICBUaGUgYXV0aG9yaXph dGlvbiBzZXJ2ZXIgbXVzdCBjb25zaWRlciB0aGUgc2VjdXJpdHkgaW1wbGljYXRpb25zIG9mIGlu dGVyYWN0aW5nIHdpdGgKICAgICAgICAgIHVuYXV0aGVudGljYXRlZCBjbGllbnRzIGFuZCB0YWtl IG1lYXN1cmVzIHRvIGxpbWl0IHRoZSBwb3RlbnRpYWwgZXhwb3N1cmUgb2Ygb3RoZXIKICAgICAg ICAgIGNyZWRlbnRpYWxzIChlLmcuIHJlZnJlc2ggdG9rZW5zKSBpc3N1ZWQgdG8gc3VjaCBjbGll bnRzLgogICAgICAgIDwvdD4KICAgICAgPC9zZWN0aW9uPgoKICAgICAgPHNlY3Rpb24gdGl0bGU9 J0NsaWVudCBJbXBlcnNvbmF0aW9uJz4KICAgICAgICA8dD4KICAgICAgICAgIEEgbWFsaWNpb3Vz IGNsaWVudCBjYW4gaW1wZXJzb25hdGUgYW5vdGhlciBjbGllbnQgYW5kIG9idGFpbiBhY2Nlc3Mg dG8gcHJvdGVjdGVkCiAgICAgICAgICByZXNvdXJjZXMsIGlmIHRoZSBpbXBlcnNvbmF0ZWQgY2xp ZW50IGZhaWxzIHRvLCBvciBpcyB1bmFibGUgdG8sIGtlZXAgaXRzIGNsaWVudAogICAgICAgICAg Y3JlZGVudGlhbHMgY29uZmlkZW50aWFsLgogICAgICAgIDwvdD4KICAgICAgICA8dD4KICAgICAg ICAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBNVVNUIGF1dGhlbnRpY2F0ZSB0aGUgY2xpZW50 IHdoZW5ldmVyIHBvc3NpYmxlLiBJZiB0aGUKICAgICAgICAgIGF1dGhvcml6YXRpb24gc2VydmVy IGNhbm5vdCBhdXRoZW50aWNhdGUgdGhlIGNsaWVudCBkdWUgdG8gdGhlIGNsaWVudCdzIG5hdHVy ZSwgdGhlCiAgICAgICAgICBhdXRob3JpemF0aW9uIHNlcnZlciBNVVNUIHJlcXVpcmUgdGhlIHJl Z2lzdHJhdGlvbiBvZiBhbnkgcmVkaXJlY3Rpb24gVVJJIHVzZWQgZm9yCiAgICAgICAgICByZWNl aXZpbmcgYXV0aG9yaXphdGlvbiByZXNwb25zZXMsIGFuZCBTSE9VTEQgdXRpbGl6ZSBvdGhlciBt ZWFucyB0byBwcm90ZWN0IHJlc291cmNlCiAgICAgICAgICBvd25lcnMgZnJvbSBzdWNoIHBvdGVu dGlhbGx5IG1hbGljaW91cyBjbGllbnRzLiBGb3IgZXhhbXBsZSwgdGhlIGF1dGhvcml6YXRpb24g c2VydmVyCiAgICAgICAgICBjYW4gZW5nYWdlIHRoZSByZXNvdXJjZSBvd25lciB0byBhc3Npc3Qg aW4gaWRlbnRpZnlpbmcgdGhlIGNsaWVudCBhbmQgaXRzIG9yaWdpbi4KICAgICAgICA8L3Q+CiAg ICAgICAgPHQ+CiAgICAgICAgICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgU0hPVUxEIGVuZm9y Y2UgZXhwbGljaXQgcmVzb3VyY2Ugb3duZXIgYXV0aGVudGljYXRpb24gYW5kCiAgICAgICAgICBw cm92aWRlIHRoZSByZXNvdXJjZSBvd25lciB3aXRoIGluZm9ybWF0aW9uIGFib3V0IHRoZSBjbGll bnQgYW5kIHRoZSByZXF1ZXN0ZWQKICAgICAgICAgIGF1dGhvcml6YXRpb24gc2NvcGUgYW5kIGxp ZmV0aW1lLiBJdCBpcyB1cCB0byB0aGUgcmVzb3VyY2Ugb3duZXIgdG8gcmV2aWV3IHRoZQogICAg ICAgICAgaW5mb3JtYXRpb24gaW4gdGhlIGNvbnRleHQgb2YgdGhlIGN1cnJlbnQgY2xpZW50LCBh bmQgYXV0aG9yaXplIG9yIGRlbnkgdGhlIHJlcXVlc3QuCiAgICAgICAgPC90PgogICAgICAgIDx0 PgogICAgICAgICAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIFNIT1VMRCBOT1QgcHJvY2VzcyBy ZXBlYXRlZCBhdXRob3JpemF0aW9uIHJlcXVlc3RzCiAgICAgICAgICBhdXRvbWF0aWNhbGx5ICh3 aXRob3V0IGFjdGl2ZSByZXNvdXJjZSBvd25lciBpbnRlcmFjdGlvbikgd2l0aG91dCBhdXRoZW50 aWNhdGluZyB0aGUKICAgICAgICAgIGNsaWVudCBvciByZWx5aW5nIG9uIG90aGVyIG1lYXN1cmVz IHRvIGVuc3VyZSB0aGUgcmVwZWF0ZWQgcmVxdWVzdCBjb21lcyBmcm9tIHRoZQogICAgICAgICAg b3JpZ2luYWwgY2xpZW50IGFuZCBub3QgYW4gaW1wZXJzb25hdG9yLgogICAgICAgIDwvdD4KICAg ICAgPC9zZWN0aW9uPgoKICAgICAgPHNlY3Rpb24gdGl0bGU9J0FjY2VzcyBUb2tlbnMnPgogICAg ICAgIDx0PgogICAgICAgICAgQWNjZXNzIHRva2VuIGNyZWRlbnRpYWxzIChhcyB3ZWxsIGFzIGFu eSBjb25maWRlbnRpYWwgYWNjZXNzIHRva2VuIGF0dHJpYnV0ZXMpIE1VU1QgYmUKICAgICAgICAg IGtlcHQgY29uZmlkZW50aWFsIGluIHRyYW5zaXQgYW5kIHN0b3JhZ2UsIGFuZCBvbmx5IHNoYXJl ZCBhbW9uZyB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIsCiAgICAgICAgICB0aGUgcmVzb3VyY2Ug c2VydmVycyB0aGUgYWNjZXNzIHRva2VuIGlzIHZhbGlkIGZvciwgYW5kIHRoZSBjbGllbnQgdG8g d2hvbSB0aGUgYWNjZXNzCiAgICAgICAgICB0b2tlbiBpcyBpc3N1ZWQuIEFjY2VzcyB0b2tlbiBj cmVkZW50aWFscyBNVVNUIG9ubHkgYmUgdHJhbnNtaXR0ZWQgdXNpbmcgVExTIGFzIGRlc2NyaWJl ZAogICAgICAgICAgaW4gPHhyZWYgdGFyZ2V0PSd0bHMnIC8+IHdpdGggc2VydmVyIGF1dGhlbnRp Y2F0aW9uIGFzIGRlZmluZWQgYnkKICAgICAgICAgIDx4cmVmIHRhcmdldD0nUkZDMjgxOCcgLz4u CiAgICAgICAgPC90PgogICAgICAgIDx0PgogICAgICAgICAgV2hlbiB1c2luZyB0aGUgaW1wbGlj aXQgZ3JhbnQgdHlwZSwgdGhlIGFjY2VzcyB0b2tlbiBpcyB0cmFuc21pdHRlZCBpbiB0aGUgVVJJ IGZyYWdtZW50LAogICAgICAgICAgd2hpY2ggY2FuIGV4cG9zZSBpdCB0byB1bmF1dGhvcml6ZWQg cGFydGllcy4KICAgICAgICA8L3Q+CiAgICAgICAgPHQ+CiAgICAgICAgICBUaGUgYXV0aG9yaXph dGlvbiBzZXJ2ZXIgTVVTVCBlbnN1cmUgdGhhdCBhY2Nlc3MgdG9rZW5zIGNhbm5vdCBiZSBnZW5l cmF0ZWQsIG1vZGlmaWVkLCBvcgogICAgICAgICAgZ3Vlc3NlZCB0byBwcm9kdWNlIHZhbGlkIGFj Y2VzcyB0b2tlbnMgYnkgdW5hdXRob3JpemVkIHBhcnRpZXMuCiAgICAgICAgPC90PgogICAgICAg IDx0PgogICAgICAgICAgVGhlIGNsaWVudCBTSE9VTEQgcmVxdWVzdCBhY2Nlc3MgdG9rZW5zIHdp dGggdGhlIG1pbmltYWwgc2NvcGUgbmVjZXNzYXJ5LiBUaGUKICAgICAgICAgIGF1dGhvcml6YXRp b24gc2VydmVyIFNIT1VMRCB0YWtlIHRoZSBjbGllbnQgaWRlbnRpdHkgaW50byBhY2NvdW50IHdo ZW4gY2hvb3NpbmcgaG93CiAgICAgICAgICB0byBob25vciB0aGUgcmVxdWVzdGVkIHNjb3BlLCBh bmQgTUFZIGlzc3VlIGFuIGFjY2VzcyB0b2tlbiB3aXRoIGEgbGVzcyByaWdodHMgdGhhbgogICAg ICAgICAgcmVxdWVzdGVkLgogICAgICAgIDwvdD4KICAgICAgICA8dD4KICAgICAgICAgIFRoaXMg c3BlY2lmaWNhdGlvbiBkb2VzIG5vdCBwcm92aWRlIGFueSBtZXRob2RzIGZvciB0aGUgcmVzb3Vy Y2Ugc2VydmVyIHRvIGVuc3VyZSB0aGF0IGFuCiAgICAgICAgICBhY2Nlc3MgdG9rZW4gcHJlc2Vu dGVkIHRvIGl0IGJ5IGEgZ2l2ZW4gY2xpZW50IHdhcyBpc3N1ZWQgdG8gdGhhdCBjbGllbnQgYnkg dGhlCiAgICAgICAgICBhdXRob3JpemF0aW9uIHNlcnZlci4KICAgICAgICA8L3Q+CiAgICAgIDwv c2VjdGlvbj4KCiAgICAgIDxzZWN0aW9uIHRpdGxlPSdSZWZyZXNoIFRva2Vucyc+CiAgICAgICAg PHQ+CiAgICAgICAgICBBdXRob3JpemF0aW9uIHNlcnZlcnMgTUFZIGlzc3VlIHJlZnJlc2ggdG9r ZW5zIHRvIHdlYiBhcHBsaWNhdGlvbiBjbGllbnRzIGFuZCBuYXRpdmUKICAgICAgICAgIGFwcGxp Y2F0aW9uIGNsaWVudHMuCiAgICAgICAgPC90PgogICAgICAgIDx0PgogICAgICAgICAgUmVmcmVz aCB0b2tlbnMgTVVTVCBiZSBrZXB0IGNvbmZpZGVudGlhbCBpbiB0cmFuc2l0IGFuZCBzdG9yYWdl LCBhbmQgc2hhcmVkIG9ubHkgYW1vbmcKICAgICAgICAgIHRoZSBhdXRob3JpemF0aW9uIHNlcnZl ciBhbmQgdGhlIGNsaWVudCB0byB3aG9tIHRoZSByZWZyZXNoIHRva2VucyB3ZXJlIGlzc3VlZC4g VGhlCiAgICAgICAgICBhdXRob3JpemF0aW9uIHNlcnZlciBNVVNUIG1haW50YWluIHRoZSBiaW5k aW5nIGJldHdlZW4gYSByZWZyZXNoIHRva2VuIGFuZCB0aGUgY2xpZW50IHRvCiAgICAgICAgICB3 aG9tIGl0IHdhcyBpc3N1ZWQuIFJlZnJlc2ggdG9rZW5zIE1VU1Qgb25seSBiZSB0cmFuc21pdHRl ZCB1c2luZyBUTFMgYXMgZGVzY3JpYmVkIGluCiAgICAgICAgICA8eHJlZiB0YXJnZXQ9J3Rscycg Lz4gd2l0aCBzZXJ2ZXIgYXV0aGVudGljYXRpb24gYXMgZGVmaW5lZCBieSA8eHJlZiB0YXJnZXQ9 J1JGQzI4MTgnIC8+LgogICAgICAgIDwvdD4KICAgICAgICA8dD4KICAgICAgICAgIFRoZSBhdXRo b3JpemF0aW9uIHNlcnZlciBNVVNUIHZlcmlmeSB0aGUgYmluZGluZyBiZXR3ZWVuIHRoZSByZWZy ZXNoIHRva2VuIGFuZCBjbGllbnQKICAgICAgICAgIGlkZW50aXR5IHdoZW5ldmVyIHRoZSBjbGll bnQgaWRlbnRpdHkgY2FuIGJlIGF1dGhlbnRpY2F0ZWQuIFdoZW4gY2xpZW50IGF1dGhlbnRpY2F0 aW9uIGlzCiAgICAgICAgICBub3QgcG9zc2libGUsIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBT SE9VTEQgZGVwbG95IG90aGVyIG1lYW5zIHRvIGRldGVjdCByZWZyZXNoIHRva2VuCiAgICAgICAg ICBhYnVzZS4KICAgICAgICA8L3Q+CiAgICAgICAgPHQ+CiAgICAgICAgICBGb3IgZXhhbXBsZSwg dGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGNvdWxkIGVtcGxveSByZWZyZXNoIHRva2VuIHJvdGF0 aW9uIGluIHdoaWNoIGEgbmV3CiAgICAgICAgICByZWZyZXNoIHRva2VuIGlzIGlzc3VlZCB3aXRo IGV2ZXJ5IGFjY2VzcyB0b2tlbiByZWZyZXNoIHJlc3BvbnNlLiBUaGUgcHJldmlvdXMgcmVmcmVz aAogICAgICAgICAgdG9rZW4gaXMgaW52YWxpZGF0ZWQgYnV0IHJldGFpbmVkIGJ5IHRoZSBhdXRo b3JpemF0aW9uIHNlcnZlci4gSWYgYSByZWZyZXNoIHRva2VuIGlzCiAgICAgICAgICBjb21wcm9t aXNlZCBhbmQgc3Vic2VxdWVudGx5IHVzZWQgYnkgYm90aCB0aGUgYXR0YWNrZXIgYW5kIHRoZSBs ZWdpdGltYXRlIGNsaWVudCwgb25lIG9mCiAgICAgICAgICB0aGVtIHdpbGwgcHJlc2VudCBhbiBp bnZhbGlkYXRlZCByZWZyZXNoIHRva2VuIHdoaWNoIHdpbGwgaW5mb3JtIHRoZSBhdXRob3JpemF0 aW9uIHNlcnZlcgogICAgICAgICAgb2YgdGhlIGJyZWFjaC4KICAgICAgICA8L3Q+CiAgICAgICAg PHQ+CiAgICAgICAgICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVTVCBlbnN1cmUgdGhhdCBy ZWZyZXNoIHRva2VucyBjYW5ub3QgYmUgZ2VuZXJhdGVkLCBtb2RpZmllZCwKICAgICAgICAgIG9y IGd1ZXNzZWQgdG8gcHJvZHVjZSB2YWxpZCByZWZyZXNoIHRva2VucyBieSB1bmF1dGhvcml6ZWQg cGFydGllcy4KICAgICAgICA8L3Q+CiAgICAgIDwvc2VjdGlvbj4KCiAgICAgIDxzZWN0aW9uIHRp dGxlPSdBdXRob3JpemF0aW9uIENvZGVzJz4KICAgICAgICA8dD4KICAgICAgICAgIFRoZSB0cmFu c21pc3Npb24gb2YgYXV0aG9yaXphdGlvbiBjb2RlcyBTSE9VTEQgYmUgbWFkZSBvdmVyIGEgc2Vj dXJlIGNoYW5uZWwsIGFuZCB0aGUKICAgICAgICAgIGNsaWVudCBTSE9VTEQgcmVxdWlyZSB0aGUg dXNlIG9mIFRMUyB3aXRoIGl0cyByZWRpcmVjdGlvbiBVUkkgaWYgdGhlIFVSSSBpZGVudGlmaWVz IGEKICAgICAgICAgIG5ldHdvcmsgcmVzb3VyY2UuIFNpbmNlIGF1dGhvcml6YXRpb24gY29kZXMg YXJlIHRyYW5zbWl0dGVkIHZpYSB1c2VyLWFnZW50IHJlZGlyZWN0aW9ucywKICAgICAgICAgIHRo ZXkgY291bGQgcG90ZW50aWFsbHkgYmUgZGlzY2xvc2VkIHRocm91Z2ggdXNlci1hZ2VudCBoaXN0 b3J5IGFuZCBIVFRQIHJlZmVycmVyIGhlYWRlcnMuCiAgICAgICAgPC90PgogICAgICAgIDx0Pgog ICAgICAgICAgQXV0aG9yaXphdGlvbiBjb2RlcyBvcGVyYXRlIGFzIHBsYWludGV4dCBiZWFyZXIg Y3JlZGVudGlhbHMsIHVzZWQgdG8gdmVyaWZ5IHRoYXQgdGhlCiAgICAgICAgICByZXNvdXJjZSBv d25lciB3aG8gZ3JhbnRlZCBhdXRob3JpemF0aW9uIGF0IHRoZSBhdXRob3JpemF0aW9uIHNlcnZl ciBpcyB0aGUgc2FtZQogICAgICAgICAgcmVzb3VyY2Ugb3duZXIgcmV0dXJuaW5nIHRvIHRoZSBj bGllbnQgdG8gY29tcGxldGUgdGhlIHByb2Nlc3MuIFRoZXJlZm9yZSwgaWYgdGhlIGNsaWVudAog ICAgICAgICAgcmVsaWVzIG9uIHRoZSBhdXRob3JpemF0aW9uIGNvZGUgZm9yIGl0cyBvd24gcmVz b3VyY2Ugb3duZXIgYXV0aGVudGljYXRpb24sIHRoZSBjbGllbnQKICAgICAgICAgIHJlZGlyZWN0 aW9uIGVuZHBvaW50IE1VU1QgcmVxdWlyZSB0aGUgdXNlIG9mIFRMUy4KICAgICAgICA8L3Q+CiAg ICAgICAgPHQ+CiAgICAgICAgICBBdXRob3JpemF0aW9uIGNvZGVzIE1VU1QgYmUgc2hvcnQgbGl2 ZWQgYW5kIHNpbmdsZSB1c2UuIElmIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlcgogICAgICAgICAg b2JzZXJ2ZXMgbXVsdGlwbGUgYXR0ZW1wdHMgdG8gZXhjaGFuZ2UgYW4gYXV0aG9yaXphdGlvbiBj b2RlIGZvciBhbiBhY2Nlc3MgdG9rZW4sIHRoZQogICAgICAgICAgYXV0aG9yaXphdGlvbiBzZXJ2 ZXIgU0hPVUxEIGF0dGVtcHQgdG8gcmV2b2tlIGFsbCBhY2Nlc3MgdG9rZW5zIGFscmVhZHkgZ3Jh bnRlZCBiYXNlZCBvbgogICAgICAgICAgdGhlIGNvbXByb21pc2VkIGF1dGhvcml6YXRpb24gY29k ZS4KICAgICAgICA8L3Q+CiAgICAgICAgPHQ+CiAgICAgICAgICBJZiB0aGUgY2xpZW50IGNhbiBi ZSBhdXRoZW50aWNhdGVkLCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXJzIE1VU1QgYXV0aGVudGlj YXRlIHRoZQogICAgICAgICAgY2xpZW50IGFuZCBlbnN1cmUgdGhhdCB0aGUgYXV0aG9yaXphdGlv biBjb2RlIHdhcyBpc3N1ZWQgdG8gdGhlIHNhbWUgY2xpZW50LgogICAgICAgIDwvdD4KICAgICAg PC9zZWN0aW9uPgoKICAgICAgPHNlY3Rpb24gdGl0bGU9J0F1dGhvcml6YXRpb24gQ29kZSBSZWRp cmVjdGlvbiBVUkkgTWFuaXB1bGF0aW9uJz4KICAgICAgICA8dD4KICAgICAgICAgIFdoZW4gcmVx dWVzdGluZyBhdXRob3JpemF0aW9uIHVzaW5nIHRoZSBhdXRob3JpemF0aW9uIGNvZGUgZ3JhbnQg dHlwZSwgdGhlIGNsaWVudCBjYW4KICAgICAgICAgIHNwZWNpZnkgYSByZWRpcmVjdGlvbiBVUkkg dmlhIHRoZSA8c3Bhbnggc3R5bGU9J3ZlcmInPnJlZGlyZWN0X3VyaTwvc3Bhbng+IHBhcmFtZXRl ci4KICAgICAgICAgIElmIGFuIGF0dGFja2VyIGNhbiBtYW5pcHVsYXRlIHRoZSB2YWx1ZSBvZiB0 aGUgcmVkaXJlY3Rpb24gVVJJLCBpdCBjYW4gY2F1c2UgdGhlCiAgICAgICAgICBhdXRob3JpemF0 aW9uIHNlcnZlciB0byByZWRpcmVjdCB0aGUgcmVzb3VyY2Ugb3duZXIgdXNlci1hZ2VudCB0byBh IFVSSSB1bmRlciB0aGUgY29udHJvbAogICAgICAgICAgb2YgdGhlIGF0dGFja2VyIHdpdGggdGhl IGF1dGhvcml6YXRpb24gY29kZS4KICAgICAgICA8L3Q+CiAgICAgICAgPHQ+CiAgICAgICAgICBB biBhdHRhY2tlciBjYW4gY3JlYXRlIGFuIGFjY291bnQgYXQgYSBsZWdpdGltYXRlIGNsaWVudCBh bmQgaW5pdGlhdGUgdGhlIGF1dGhvcml6YXRpb24KICAgICAgICAgIGZsb3cuIFdoZW4gdGhlIGF0 dGFja2VyJ3MgdXNlci1hZ2VudCBpcyBzZW50IHRvIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciB0 byBncmFudCBhY2Nlc3MsCiAgICAgICAgICB0aGUgYXR0YWNrZXIgZ3JhYnMgdGhlIGF1dGhvcml6 YXRpb24gVVJJIHByb3ZpZGVkIGJ5IHRoZSBsZWdpdGltYXRlIGNsaWVudCwgYW5kIHJlcGxhY2Vz CiAgICAgICAgICB0aGUgY2xpZW50J3MgcmVkaXJlY3Rpb24gVVJJIHdpdGggYSBVUkkgdW5kZXIg dGhlIGNvbnRyb2wgb2YgdGhlIGF0dGFja2VyLiBUaGUgYXR0YWNrZXIKICAgICAgICAgIHRoZW4g dHJpY2tzIHRoZSB2aWN0aW0gaW50byBmb2xsb3dpbmcgdGhlIG1hbmlwdWxhdGVkIGxpbmsgdG8g YXV0aG9yaXplIGFjY2VzcyB0byB0aGUKICAgICAgICAgIGxlZ2l0aW1hdGUgY2xpZW50LgogICAg ICAgIDwvdD4KICAgICAgICA8dD4KICAgICAgICAgIE9uY2UgYXQgdGhlIGF1dGhvcml6YXRpb24g c2VydmVyLCB0aGUgdmljdGltIGlzIHByb21wdGVkIHdpdGggYSBub3JtYWwsIHZhbGlkIHJlcXVl c3Qgb24KICAgICAgICAgIGJlaGFsZiBvZiBhIGxlZ2l0aW1hdGUgYW5kIHRydXN0ZWQgY2xpZW50 LCBhbmQgYXV0aG9yaXplcyB0aGUgcmVxdWVzdC4gVGhlIHZpY3RpbSBpcwogICAgICAgICAgdGhl biByZWRpcmVjdGVkIHRvIGFuIGVuZHBvaW50IHVuZGVyIHRoZSBjb250cm9sIG9mIHRoZSBhdHRh Y2tlciB3aXRoIHRoZSBhdXRob3JpemF0aW9uCiAgICAgICAgICBjb2RlLiBUaGUgYXR0YWNrZXIg Y29tcGxldGVzIHRoZSBhdXRob3JpemF0aW9uIGZsb3cgYnkgc2VuZGluZyB0aGUgYXV0aG9yaXph dGlvbiBjb2RlIHRvCiAgICAgICAgICB0aGUgY2xpZW50IHVzaW5nIHRoZSBvcmlnaW5hbCByZWRp cmVjdGlvbiBVUkkgcHJvdmlkZWQgYnkgdGhlIGNsaWVudC4gVGhlIGNsaWVudAogICAgICAgICAg ZXhjaGFuZ2VzIHRoZSBhdXRob3JpemF0aW9uIGNvZGUgd2l0aCBhbiBhY2Nlc3MgdG9rZW4gYW5k IGxpbmtzIGl0IHRvIHRoZSBhdHRhY2tlcidzCiAgICAgICAgICBjbGllbnQgYWNjb3VudCB3aGlj aCBjYW4gbm93IGdhaW4gYWNjZXNzIHRvIHRoZSBwcm90ZWN0ZWQgcmVzb3VyY2VzIGF1dGhvcml6 ZWQgYnkgdGhlCiAgICAgICAgICB2aWN0aW0gKHZpYSB0aGUgY2xpZW50KS4KICAgICAgICA8L3Q+ CiAgICAgICAgPHQ+CiAgICAgICAgICBJbiBvcmRlciB0byBwcmV2ZW50IHN1Y2ggYW4gYXR0YWNr LCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVTVCBlbnN1cmUgdGhhdCB0aGUKICAgICAgICAg IHJlZGlyZWN0aW9uIFVSSSB1c2VkIHRvIG9idGFpbiB0aGUgYXV0aG9yaXphdGlvbiBjb2RlIGlz IGlkZW50aWNhbCB0byB0aGUgcmVkaXJlY3Rpb24gVVJJCiAgICAgICAgICBwcm92aWRlZCB3aGVu IGV4Y2hhbmdpbmcgdGhlIGF1dGhvcml6YXRpb24gY29kZSBmb3IgYW4gYWNjZXNzIHRva2VuLiBU aGUgYXV0aG9yaXphdGlvbgogICAgICAgICAgc2VydmVyIE1VU1QgcmVxdWlyZSBwdWJsaWMgY2xp ZW50cyBhbmQgU0hPVUxEIHJlcXVpcmUgY29uZmlkZW50aWFsIGNsaWVudHMgdG8gcmVnaXN0ZXIK ICAgICAgICAgIHRoZWlyIHJlZGlyZWN0aW9uIFVSSXMuIElmIGEgcmVkaXJlY3Rpb24gVVJJIGlz IHByb3ZpZGVkIGluIHRoZSByZXF1ZXN0LCB0aGUKICAgICAgICAgIGF1dGhvcml6YXRpb24gc2Vy dmVyIE1VU1QgdmFsaWRhdGUgaXQgYWdhaW5zdCB0aGUgcmVnaXN0ZXJlZCB2YWx1ZS4KICAgICAg ICA8L3Q+CiAgICAgIDwvc2VjdGlvbj4KCiAgICAgIDxzZWN0aW9uIHRpdGxlPSdSZXNvdXJjZSBP d25lciBQYXNzd29yZCBDcmVkZW50aWFscyc+CiAgICAgICAgPHQ+CiAgICAgICAgICBUaGUgcmVz b3VyY2Ugb3duZXIgcGFzc3dvcmQgY3JlZGVudGlhbHMgZ3JhbnQgdHlwZSBpcyBvZnRlbiB1c2Vk IGZvciBsZWdhY3kgb3IgbWlncmF0aW9uCiAgICAgICAgICByZWFzb25zLiBJdCByZWR1Y2VzIHRo ZSBvdmVyYWxsIHJpc2sgb2Ygc3RvcmluZyB1c2VybmFtZSBhbmQgcGFzc3dvcmQgYnkgdGhlIGNs aWVudCwgYnV0CiAgICAgICAgICBkb2VzIG5vdCBlbGltaW5hdGUgdGhlIG5lZWQgdG8gZXhwb3Nl IGhpZ2hseSBwcml2aWxlZ2VkIGNyZWRlbnRpYWxzIHRvIHRoZSBjbGllbnQuCiAgICAgICAgPC90 PgogICAgICAgIDx0PgogICAgICAgICAgVGhpcyBncmFudCB0eXBlIGNhcnJpZXMgYSBoaWdoZXIg cmlzayB0aGFuIG90aGVyIGdyYW50IHR5cGVzIGJlY2F1c2UgaXQgbWFpbnRhaW5zIHRoZQogICAg ICAgICAgcGFzc3dvcmQgYW50aS1wYXR0ZXJuIHRoaXMgcHJvdG9jb2wgc2Vla3MgdG8gYXZvaWQu IFRoZSBjbGllbnQgY291bGQgYWJ1c2UgdGhlIHBhc3N3b3JkCiAgICAgICAgICBvciB0aGUgcGFz c3dvcmQgY291bGQgdW5pbnRlbnRpb25hbGx5IGJlIGRpc2Nsb3NlZCB0byBhbiBhdHRhY2tlciAo ZS5nLiB2aWEgbG9nIGZpbGVzIG9yCiAgICAgICAgICBvdGhlciByZWNvcmRzIGtlcHQgYnkgdGhl IGNsaWVudCkuCiAgICAgICAgPC90PgogICAgICAgIDx0PgogICAgICAgICAgQWRkaXRpb25hbGx5 LCBiZWNhdXNlIHRoZSByZXNvdXJjZSBvd25lciBkb2VzIG5vdCBoYXZlIGNvbnRyb2wgb3ZlciB0 aGUgYXV0aG9yaXphdGlvbgogICAgICAgICAgcHJvY2VzcyAodGhlIHJlc291cmNlIG93bmVyIGlu dm9sdmVtZW50IGVuZHMgd2hlbiBpdCBoYW5kcyBvdmVyIGl0cyBjcmVkZW50aWFscyB0byB0aGUK ICAgICAgICAgIGNsaWVudCksIHRoZSBjbGllbnQgY2FuIG9idGFpbiBhY2Nlc3MgdG9rZW5zIHdp dGggYSBicm9hZGVyIHNjb3BlIHRoYW4gZGVzaXJlZCBieSB0aGUKICAgICAgICAgIHJlc291cmNl IG93bmVyLiBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgc2hvdWxkIGNvbnNpZGVyIHRoZSBzY29w ZSBhbmQgbGlmZXRpbWUgb2YKICAgICAgICAgIGFjY2VzcyB0b2tlbnMgaXNzdWVkIHZpYSB0aGlz IGdyYW50IHR5cGUuCiAgICAgICAgPC90PgogICAgICAgIDx0PgogICAgICAgICAgVGhlIGF1dGhv cml6YXRpb24gc2VydmVyIGFuZCBjbGllbnQgU0hPVUxEIG1pbmltaXplIHVzZSBvZiB0aGlzIGdy YW50IHR5cGUgYW5kIHV0aWxpemUKICAgICAgICAgIG90aGVyIGdyYW50IHR5cGVzIHdoZW5ldmVy IHBvc3NpYmxlLgogICAgICAgIDwvdD4KICAgICAgPC9zZWN0aW9uPgoKICAgICAgPHNlY3Rpb24g dGl0bGU9J1JlcXVlc3QgQ29uZmlkZW50aWFsaXR5Jz4KICAgICAgICA8dD4KICAgICAgICAgIEFj Y2VzcyB0b2tlbnMsIHJlZnJlc2ggdG9rZW5zLCByZXNvdXJjZSBvd25lciBwYXNzd29yZHMsIGFu ZCBjbGllbnQgY3JlZGVudGlhbHMgTVVTVCBOT1QKICAgICAgICAgIGJlIHRyYW5zbWl0dGVkIGlu IHRoZSBjbGVhci4gQXV0aG9yaXphdGlvbiBjb2RlcyBTSE9VTEQgTk9UIGJlIHRyYW5zbWl0dGVk IGluIHRoZSBjbGVhci4KICAgICAgICA8L3Q+CiAgICAgICAgPHQ+CiAgICAgICAgICBUaGUgPHNw YW54IHN0eWxlPSd2ZXJiJz5zdGF0ZTwvc3Bhbng+IGFuZCA8c3Bhbnggc3R5bGU9J3ZlcmInPnNj b3BlPC9zcGFueD4gcGFyYW1ldGVycwogICAgICAgICAgU0hPVUxEIE5PVCBpbmNsdWRlIHNlbnNp dGl2ZSBjbGllbnQgb3IgcmVzb3VyY2Ugb3duZXIgaW5mb3JtYXRpb24gaW4gcGxhaW4gdGV4dCBh cyB0aGV5CiAgICAgICAgICBjYW4gYmUgdHJhbnNtaXR0ZWQgb3ZlciBpbnNlY3VyZSBjaGFubmVs cyBvciBzdG9yZWQgaW5zZWN1cmVseS4KICAgICAgICA8L3Q+CiAgICAgIDwvc2VjdGlvbj4KCiAg ICAgIDxzZWN0aW9uIHRpdGxlPSdFbmRwb2ludHMgQXV0aGVudGljaXR5Jz4KICAgICAgICA8dD4K ICAgICAgICAgIEluIG9yZGVyIHRvIHByZXZlbnQgbWFuLWluLXRoZS1taWRkbGUgYXR0YWNrcywg dGhlIGF1dGhvcml6YXRpb24gc2VydmVyIE1VU1QgcmVxdWlyZSB0aGUKICAgICAgICAgIHVzZSBv ZiBUTFMgd2l0aCBzZXJ2ZXIgYXV0aGVudGljYXRpb24gYXMgZGVmaW5lZCBieSA8eHJlZiB0YXJn ZXQ9J1JGQzI4MTgnIC8+IGZvcgogICAgICAgICAgYW55IHJlcXVlc3Qgc2VudCB0byB0aGUgYXV0 aG9yaXphdGlvbiBhbmQgdG9rZW4gZW5kcG9pbnRzLiBUaGUgY2xpZW50IE1VU1QgdmFsaWRhdGUg dGhlCiAgICAgICAgICBhdXRob3JpemF0aW9uIHNlcnZlcidzIFRMUyBjZXJ0aWZpY2F0ZSBhcyBk ZWZpbmVkIGJ5IDx4cmVmIHRhcmdldD0nUkZDNjEyNScgLz4sIGFuZCBpbgogICAgICAgICAgYWNj b3JkYW5jZSB3aXRoIGl0cyByZXF1aXJlbWVudHMgZm9yIHNlcnZlciBpZGVudGl0eSBhdXRoZW50 aWNhdGlvbi4KICAgICAgICA8L3Q+CiAgICAgIDwvc2VjdGlvbj4KCiAgICAgIDxzZWN0aW9uIHRp dGxlPSdDcmVkZW50aWFscyBHdWVzc2luZyBBdHRhY2tzJyBhbmNob3I9J2FudGhyb3B5Jz4KICAg ICAgICA8dD4KICAgICAgICAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBNVVNUIHByZXZlbnQg YXR0YWNrZXJzIGZyb20gZ3Vlc3NpbmcgYWNjZXNzIHRva2VucywKICAgICAgICAgIGF1dGhvcml6 YXRpb24gY29kZXMsIHJlZnJlc2ggdG9rZW5zLCByZXNvdXJjZSBvd25lciBwYXNzd29yZHMsIGFu ZCBjbGllbnQgY3JlZGVudGlhbHMuCiAgICAgICAgPC90PgogICAgICAgIDx0PgogICAgICAgICAg VGhlIHByb2JhYmlsaXR5IG9mIGFuIGF0dGFja2VyIGd1ZXNzaW5nIGdlbmVyYXRlZCB0b2tlbnMg KGFuZCBvdGhlciBjcmVkZW50aWFscyBub3QKICAgICAgICAgIGludGVuZGVkIGZvciBoYW5kbGlu ZyBieSBlbmQtdXNlcnMpIE1VU1QgYmUgbGVzcyB0aGFuIG9yIGVxdWFsIHRvIDJeKC0xMjgpIGFu ZCBTSE9VTEQgYmUKICAgICAgICAgIGxlc3MgdGhhbiBvciBlcXVhbCB0byAyXigtMTYwKS4KICAg ICAgICA8L3Q+CiAgICAgICAgPHQ+CiAgICAgICAgICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIg TVVTVCB1dGlsaXplIG90aGVyIG1lYW5zIHRvIHByb3RlY3QgY3JlZGVudGlhbHMgaW50ZW5kZWQg Zm9yCiAgICAgICAgICBlbmQtdXNlciB1c2FnZS4KICAgICAgICA8L3Q+CiAgICAgIDwvc2VjdGlv bj4KCiAgICAgIDxzZWN0aW9uIHRpdGxlPSdQaGlzaGluZyBBdHRhY2tzJz4KICAgICAgICA8dD4K ICAgICAgICAgIFdpZGUgZGVwbG95bWVudCBvZiB0aGlzIGFuZCBzaW1pbGFyIHByb3RvY29scyBt YXkgY2F1c2UgZW5kLXVzZXJzIHRvIGJlY29tZSBpbnVyZWQKICAgICAgICAgIHRvIHRoZSBwcmFj dGljZSBvZiBiZWluZyByZWRpcmVjdGVkIHRvIHdlYnNpdGVzIHdoZXJlIHRoZXkgYXJlIGFza2Vk IHRvIGVudGVyIHRoZWlyCiAgICAgICAgICBwYXNzd29yZHMuIElmIGVuZC11c2VycyBhcmUgbm90 IGNhcmVmdWwgdG8gdmVyaWZ5IHRoZSBhdXRoZW50aWNpdHkgb2YgdGhlc2Ugd2Vic2l0ZXMKICAg ICAgICAgIGJlZm9yZSBlbnRlcmluZyB0aGVpciBjcmVkZW50aWFscywgaXQgd2lsbCBiZSBwb3Nz aWJsZSBmb3IgYXR0YWNrZXJzIHRvIGV4cGxvaXQgdGhpcwogICAgICAgICAgcHJhY3RpY2UgdG8g c3RlYWwgcmVzb3VyY2Ugb3duZXJzJyBwYXNzd29yZHMuCiAgICAgICAgPC90PgogICAgICAgIDx0 PgogICAgICAgICAgU2VydmljZSBwcm92aWRlcnMgc2hvdWxkIGF0dGVtcHQgdG8gZWR1Y2F0ZSBl bmQtdXNlcnMgYWJvdXQgdGhlIHJpc2tzIHBoaXNoaW5nIGF0dGFja3MKICAgICAgICAgIHBvc2Us IGFuZCBzaG91bGQgcHJvdmlkZSBtZWNoYW5pc21zIHRoYXQgbWFrZSBpdCBlYXN5IGZvciBlbmQt dXNlcnMgdG8gY29uZmlybSB0aGUKICAgICAgICAgIGF1dGhlbnRpY2l0eSBvZiB0aGVpciBzaXRl cy4gQ2xpZW50IGRldmVsb3BlcnMgc2hvdWxkIGNvbnNpZGVyIHRoZSBzZWN1cml0eSBpbXBsaWNh dGlvbnMKICAgICAgICAgIG9mIGhvdyB0aGV5IGludGVyYWN0IHdpdGggdGhlIHVzZXItYWdlbnQg KGUuZy4sIGV4dGVybmFsLCBlbWJlZGRlZCksIGFuZCB0aGUgYWJpbGl0eSBvZgogICAgICAgICAg dGhlIGVuZC11c2VyIHRvIHZlcmlmeSB0aGUgYXV0aGVudGljaXR5IG9mIHRoZSBhdXRob3JpemF0 aW9uIHNlcnZlci4KICAgICAgICA8L3Q+CiAgICAgICAgPHQ+CiAgICAgICAgICBUbyByZWR1Y2Ug dGhlIHJpc2sgb2YgcGhpc2hpbmcgYXR0YWNrcywgdGhlIGF1dGhvcml6YXRpb24gc2VydmVycyBN VVNUIHJlcXVpcmUgdGhlIHVzZSBvZgogICAgICAgICAgVExTIG9uIGV2ZXJ5IGVuZHBvaW50IHVz ZWQgZm9yIGVuZC11c2VyIGludGVyYWN0aW9uLgogICAgICAgIDwvdD4KICAgICAgPC9zZWN0aW9u PgoKICAgICAgPHNlY3Rpb24gdGl0bGU9J0Nyb3NzLVNpdGUgUmVxdWVzdCBGb3JnZXJ5JyBhbmNo b3I9J0NTUkYnPgogICAgICAgIDx0PgogICAgICAgICAgQ3Jvc3Mtc2l0ZSByZXF1ZXN0IGZvcmdl cnkgKENTUkYpIGlzIGFuIGV4cGxvaXQgaW4gd2hpY2ggYW4gYXR0YWNrZXIgY2F1c2VzIHRoZQog ICAgICAgICAgdXNlci1hZ2VudCBvZiBhIHZpY3RpbSBlbmQtdXNlciB0byBmb2xsb3cgYSBtYWxp Y2lvdXMgVVJJIChlLmcuIHByb3ZpZGVkIHRvIHRoZQogICAgICAgICAgdXNlci1hZ2VudCBhcyBh IG1pc2xlYWRpbmcgbGluaywgaW1hZ2UsIG9yIHJlZGlyZWN0aW9uKSB0byBhIHRydXN0aW5nIHNl cnZlciAodXN1YWxseQogICAgICAgICAgZXN0YWJsaXNoZWQgdmlhIHRoZSBwcmVzZW5jZSBvZiBh IHZhbGlkIHNlc3Npb24gY29va2llKS4KICAgICAgICA8L3Q+CiAgICAgICAgPHQ+CiAgICAgICAg ICBBIENTUkYgYXR0YWNrIGFnYWluc3QgdGhlIGNsaWVudCdzIHJlZGlyZWN0aW9uIFVSSSBhbGxv d3MgYW4gYXR0YWNrZXIgdG8gaW5qZWN0IHRoZWlyIG93bgogICAgICAgICAgYXV0aG9yaXphdGlv biBjb2RlIG9yIGFjY2VzcyB0b2tlbiwgd2hpY2ggY2FuIHJlc3VsdCBpbiB0aGUgY2xpZW50IHVz aW5nIGFuIGFjY2VzcyB0b2tlbgogICAgICAgICAgYXNzb2NpYXRlZCB3aXRoIHRoZSBhdHRhY2tl cidzIHByb3RlY3RlZCByZXNvdXJjZXMgcmF0aGVyIHRoYW4gdGhlIHZpY3RpbSdzIChlLmcuIHNh dmUKICAgICAgICAgIHRoZSB2aWN0aW0ncyBiYW5rIGFjY291bnQgaW5mb3JtYXRpb24gdG8gYSBw cm90ZWN0ZWQgcmVzb3VyY2UgY29udHJvbGxlZCBieSB0aGUKICAgICAgICAgIGF0dGFja2VyKS4K ICAgICAgICA8L3Q+CiAgICAgICAgPHQ+CiAgICAgICAgICBUaGUgY2xpZW50IE1VU1QgaW1wbGVt ZW50IENTUkYgcHJvdGVjdGlvbiBmb3IgaXRzIHJlZGlyZWN0aW9uIFVSSS4gVGhpcyBpcyB0eXBp Y2FsbHkKICAgICAgICAgIGFjY29tcGxpc2hlZCBieSByZXF1aXJpbmcgYW55IHJlcXVlc3Qgc2Vu dCB0byB0aGUgcmVkaXJlY3Rpb24gVVJJIGVuZHBvaW50IHRvIGluY2x1ZGUgYQogICAgICAgICAg dmFsdWUgdGhhdCBiaW5kcyB0aGUgcmVxdWVzdCB0byB0aGUgdXNlci1hZ2VudCdzIGF1dGhlbnRp Y2F0ZWQgc3RhdGUgKGUuZy4gYSBoYXNoIG9mIHRoZQogICAgICAgICAgc2Vzc2lvbiBjb29raWUg dXNlZCB0byBhdXRoZW50aWNhdGUgdGhlIHVzZXItYWdlbnQpLiBUaGUgY2xpZW50IFNIT1VMRCB1 dGlsaXplIHRoZQogICAgICAgICAgPHNwYW54IHN0eWxlPSd2ZXJiJz5zdGF0ZTwvc3Bhbng+IHJl cXVlc3QgcGFyYW1ldGVyIHRvIGRlbGl2ZXIgdGhpcyB2YWx1ZSB0byB0aGUKICAgICAgICAgIGF1 dGhvcml6YXRpb24gc2VydmVyIHdoZW4gbWFraW5nIGFuIGF1dGhvcml6YXRpb24gcmVxdWVzdC4K ICAgICAgICA8L3Q+CiAgICAgICAgPHQ+CiAgICAgICAgICBPbmNlIGF1dGhvcml6YXRpb24gaGFz IGJlZW4gb2J0YWluZWQgZnJvbSB0aGUgZW5kLXVzZXIsIHRoZSBhdXRob3JpemF0aW9uIHNlcnZl cgogICAgICAgICAgcmVkaXJlY3RzIHRoZSBlbmQtdXNlcidzIHVzZXItYWdlbnQgYmFjayB0byB0 aGUgY2xpZW50IHdpdGggdGhlIHJlcXVpcmVkIGJpbmRpbmcgdmFsdWUKICAgICAgICAgIGNvbnRh aW5lZCBpbiB0aGUgPHNwYW54IHN0eWxlPSd2ZXJiJz5zdGF0ZTwvc3Bhbng+IHBhcmFtZXRlci4g VGhlIGJpbmRpbmcgdmFsdWUgZW5hYmxlcwogICAgICAgICAgdGhlIGNsaWVudCB0byB2ZXJpZnkg dGhlIHZhbGlkaXR5IG9mIHRoZSByZXF1ZXN0IGJ5IG1hdGNoaW5nIHRoZSBiaW5kaW5nIHZhbHVl IHRvIHRoZQogICAgICAgICAgdXNlci1hZ2VudCdzIGF1dGhlbnRpY2F0ZWQgc3RhdGUuIFRoZSBi aW5kaW5nIHZhbHVlIHVzZWQgZm9yIENTUkYgcHJvdGVjdGlvbiBNVVNUIGNvbnRhaW4KICAgICAg ICAgIGEgbm9uLWd1ZXNzYWJsZSB2YWx1ZSAoYXMgZGVzY3JpYmVkIGluIDx4cmVmIHRhcmdldD0n YW50aHJvcHknIC8+KSwgYW5kIHRoZSB1c2VyLWFnZW50J3MKICAgICAgICAgIGF1dGhlbnRpY2F0 ZWQgc3RhdGUgKGUuZy4gc2Vzc2lvbiBjb29raWUsIEhUTUw1IGxvY2FsIHN0b3JhZ2UpIE1VU1Qg YmUga2VwdCBpbiBhIGxvY2F0aW9uCiAgICAgICAgICBhY2Nlc3NpYmxlIG9ubHkgdG8gdGhlIGNs aWVudCBhbmQgdGhlIHVzZXItYWdlbnQgKGkuZS4sIHByb3RlY3RlZCBieSBzYW1lLW9yaWdpbiBw b2xpY3kpLgogICAgICAgIDwvdD4KICAgICAgICA8dD4KICAgICAgICAgIEEgQ1NSRiBhdHRhY2sg YWdhaW5zdCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIncyBhdXRob3JpemF0aW9uIGVuZHBvaW50 IGNhbiByZXN1bHQgaW4gYW4KICAgICAgICAgIGF0dGFja2VyIG9idGFpbmluZyBlbmQtdXNlciBh dXRob3JpemF0aW9uIGZvciBhIG1hbGljaW91cyBjbGllbnQgd2l0aG91dCBpbnZvbHZpbmcgb3IK ICAgICAgICAgIGFsZXJ0aW5nIHRoZSBlbmQtdXNlci4KICAgICAgICA8L3Q+CiAgICAgICAgPHQ+ CiAgICAgICAgICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVTVCBpbXBsZW1lbnQgQ1NSRiBw cm90ZWN0aW9uIGZvciBpdHMgYXV0aG9yaXphdGlvbiBlbmRwb2ludCwKICAgICAgICAgIGFuZCBl bnN1cmUgdGhhdCBhIG1hbGljaW91cyBjbGllbnQgY2Fubm90IG9idGFpbiBhdXRob3JpemF0aW9u IHdpdGhvdXQgdGhlIGF3YXJlbmVzcyBhbmQKICAgICAgICAgIGV4cGxpY2l0IGNvbnNlbnQgb2Yg dGhlIHJlc291cmNlIG93bmVyLgogICAgICAgIDwvdD4KICAgICAgPC9zZWN0aW9uPgoKICAgICAg PHNlY3Rpb24gdGl0bGU9J0NsaWNramFja2luZyc+CiAgICAgICAgPHQ+CiAgICAgICAgICBJbiBh IGNsaWNramFja2luZyBhdHRhY2ssIGFuIGF0dGFja2VyIHJlZ2lzdGVycyBhIGxlZ2l0aW1hdGUg Y2xpZW50IGFuZCB0aGVuIGNvbnN0cnVjdHMgYQogICAgICAgICAgbWFsaWNpb3VzIHNpdGUgaW4g d2hpY2ggaXQgbG9hZHMgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyJ3MgYXV0aG9yaXphdGlvbiBl bmRwb2ludCB3ZWIKICAgICAgICAgIHBhZ2UgaW4gYSB0cmFuc3BhcmVudCBpZnJhbWUgb3Zlcmxh aWQgb24gdG9wIG9mIGEgc2V0IG9mIGR1bW15IGJ1dHRvbnMgd2hpY2ggYXJlCiAgICAgICAgICBj YXJlZnVsbHkgY29uc3RydWN0ZWQgdG8gYmUgcGxhY2VkIGRpcmVjdGx5IHVuZGVyIGltcG9ydGFu dCBidXR0b25zIG9uIHRoZSBhdXRob3JpemF0aW9uCiAgICAgICAgICBwYWdlLiBXaGVuIGFuIGVu ZC11c2VyIGNsaWNrcyBhIG1pc2xlYWRpbmcgdmlzaWJsZSBidXR0b24sIHRoZSBlbmQtdXNlciBp cyBhY3R1YWxseQogICAgICAgICAgY2xpY2tpbmcgYW4gaW52aXNpYmxlIGJ1dHRvbiBvbiB0aGUg YXV0aG9yaXphdGlvbiBwYWdlIChzdWNoIGFzIGFuICJBdXRob3JpemUiIGJ1dHRvbikuCiAgICAg ICAgICBUaGlzIGFsbG93cyBhbiBhdHRhY2tlciB0byB0cmljayBhIHJlc291cmNlIG93bmVyIGlu dG8gZ3JhbnRpbmcgaXRzIGNsaWVudCBhY2Nlc3Mgd2l0aG91dAogICAgICAgICAgdGhlaXIga25v d2xlZGdlLgogICAgICAgIDwvdD4KICAgICAgICA8dD4KICAgICAgICAgIFRvIHByZXZlbnQgdGhp cyBmb3JtIG9mIGF0dGFjaywgbmF0aXZlIGFwcGxpY2F0aW9ucyBTSE9VTEQgdXNlIGV4dGVybmFs IGJyb3dzZXJzIGluc3RlYWQKICAgICAgICAgIG9mIGVtYmVkZGluZyBicm93c2VycyB3aXRoaW4g dGhlIGFwcGxpY2F0aW9uIHdoZW4gcmVxdWVzdGluZyBlbmQtdXNlciBhdXRob3JpemF0aW9uLiBG b3IKICAgICAgICAgIG1vc3QgbmV3ZXIgYnJvd3NlcnMsIGF2b2lkYW5jZSBvZiBpZnJhbWVzIGNh biBiZSBlbmZvcmNlZCBieSB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIKICAgICAgICAgIHVzaW5n IHRoZSAobm9uLXN0YW5kYXJkKSA8c3Bhbnggc3R5bGU9J3ZlcmInPngtZnJhbWUtb3B0aW9uczwv c3Bhbng+IGhlYWRlci4gVGhpcyBoZWFkZXIKICAgICAgICAgIGNhbiBoYXZlIHR3byB2YWx1ZXMs IDxzcGFueCBzdHlsZT0ndmVyYic+ZGVueTwvc3Bhbng+IGFuZAogICAgICAgICAgPHNwYW54IHN0 eWxlPSd2ZXJiJz5zYW1lb3JpZ2luPC9zcGFueD4sIHdoaWNoIHdpbGwgYmxvY2sgYW55IGZyYW1p bmcsIG9yIGZyYW1pbmcgYnkgc2l0ZXMKICAgICAgICAgIHdpdGggYSBkaWZmZXJlbnQgb3JpZ2lu LCByZXNwZWN0aXZlbHkuIEZvciBvbGRlciBicm93c2VycywgSmF2YVNjcmlwdCBmcmFtZWJ1c3Rp bmcKICAgICAgICAgIHRlY2huaXF1ZXMgY2FuIGJlIHVzZWQgYnV0IG1heSBub3QgYmUgZWZmZWN0 aXZlIGluIGFsbCBicm93c2Vycy4KICAgICAgICA8L3Q+CiAgICAgIDwvc2VjdGlvbj4KCiAgICAg IDxzZWN0aW9uIHRpdGxlPSdDb2RlIEluamVjdGlvbiBhbmQgSW5wdXQgVmFsaWRhdGlvbic+CiAg ICAgICAgPHQ+CiAgICAgICAgICBBIGNvZGUgaW5qZWN0aW9uIGF0dGFjayBvY2N1cnMgd2hlbiBh biBpbnB1dCBvciBvdGhlcndpc2UgZXh0ZXJuYWwgdmFyaWFibGUgaXMgdXNlZCBieSBhbgogICAg ICAgICAgYXBwbGljYXRpb24gdW5zYW5pdGl6ZWQgYW5kIGNhdXNlcyBtb2RpZmljYXRpb24gdG8g dGhlIGFwcGxpY2F0aW9uIGxvZ2ljLiBUaGlzIG1heSBhbGxvdwogICAgICAgICAgYW4gYXR0YWNr ZXIgdG8gZ2FpbiBhY2Nlc3MgdG8gdGhlIGFwcGxpY2F0aW9uIGRldmljZSBvciBpdHMgZGF0YSwg Y2F1c2UgZGVuaWFsIG9mCiAgICAgICAgICBzZXJ2aWNlLCBvciBhIHdpZGUgcmFuZ2Ugb2YgbWFs aWNpb3VzIHNpZGUtZWZmZWN0cy4KICAgICAgICA8L3Q+CiAgICAgICAgPHQ+CiAgICAgICAgICBU aGUgQXV0aG9yaXphdGlvbiBzZXJ2ZXIgYW5kIGNsaWVudCBNVVNUIHNhbml0aXplIChhbmQgdmFs aWRhdGUgd2hlbiBwb3NzaWJsZSkgYW55IHZhbHVlCiAgICAgICAgICByZWNlaXZlZCwgaW4gcGFy dGljdWxhciwgdGhlIHZhbHVlIG9mIHRoZSA8c3Bhbnggc3R5bGU9J3ZlcmInPnN0YXRlPC9zcGFu eD4gYW5kCiAgICAgICAgICA8c3Bhbnggc3R5bGU9J3ZlcmInPnJlZGlyZWN0X3VyaTwvc3Bhbng+ IHBhcmFtZXRlcnMuCiAgICAgICAgPC90PgogICAgICA8L3NlY3Rpb24+CgogICAgICA8c2VjdGlv biB0aXRsZT0nT3BlbiBSZWRpcmVjdG9ycycgYW5jaG9yPSdvcGVuLXJlZGlyZWN0Jz4KICAgICAg ICA8dD4KICAgICAgICAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBhdXRob3JpemF0aW9uIGVu ZHBvaW50IGFuZCB0aGUgY2xpZW50IHJlZGlyZWN0aW9uIGVuZHBvaW50IGNhbgogICAgICAgICAg YmUgaW1wcm9wZXJseSBjb25maWd1cmVkIGFuZCBvcGVyYXRlIGFzIG9wZW4gcmVkaXJlY3RvcnMu IEFuIG9wZW4gcmVkaXJlY3RvciBpcyBhbgogICAgICAgICAgZW5kcG9pbnQgdXNpbmcgYSBwYXJh bWV0ZXIgdG8gYXV0b21hdGljYWxseSByZWRpcmVjdCBhIHVzZXItYWdlbnQgdG8gdGhlIGxvY2F0 aW9uCiAgICAgICAgICBzcGVjaWZpZWQgYnkgdGhlIHBhcmFtZXRlciB2YWx1ZSB3aXRob3V0IGFu eSB2YWxpZGF0aW9uLgogICAgICAgIDwvdD4KICAgICAgICA8dD4KICAgICAgICAgIE9wZW4gcmVk aXJlY3RvcnMgY2FuIGJlIHVzZWQgaW4gcGhpc2hpbmcgYXR0YWNrcywgb3IgYnkgYW4gYXR0YWNr ZXIgdG8gZ2V0IGVuZC11c2VycyB0bwogICAgICAgICAgdmlzaXQgbWFsaWNpb3VzIHNpdGVzIGJ5 IG1ha2luZyB0aGUgVVJJJ3MgYXV0aG9yaXR5IGxvb2sgbGlrZSBhIGZhbWlsaWFyIGFuZCB0cnVz dGVkCiAgICAgICAgICBkZXN0aW5hdGlvbi4gSW4gYWRkaXRpb24sIGlmIHRoZSBhdXRob3JpemF0 aW9uIHNlcnZlciBhbGxvd3MgdGhlIGNsaWVudCB0byByZWdpc3RlciBvbmx5CiAgICAgICAgICBw YXJ0IG9mIHRoZSByZWRpcmVjdGlvbiBVUkksIGFuIGF0dGFja2VyIGNhbiB1c2UgYW4gb3BlbiBy ZWRpcmVjdG9yIG9wZXJhdGVkIGJ5IHRoZQogICAgICAgICAgY2xpZW50IHRvIGNvbnN0cnVjdCBh IHJlZGlyZWN0aW9uIFVSSSB0aGF0IHdpbGwgcGFzcyB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIg dmFsaWRhdGlvbgogICAgICAgICAgYnV0IHdpbGwgc2VuZCB0aGUgYXV0aG9yaXphdGlvbiBjb2Rl IG9yIGFjY2VzcyB0b2tlbiB0byBhbiBlbmRwb2ludCB1bmRlciB0aGUgY29udHJvbCBvZgogICAg ICAgICAgdGhlIGF0dGFja2VyLgogICAgICAgIDwvdD4KICAgICAgPC9zZWN0aW9uPgoKICAgIDwv c2VjdGlvbj4KCiAgICA8c2VjdGlvbiB0aXRsZT0nSUFOQSBDb25zaWRlcmF0aW9ucyc+CgogICAg ICA8c2VjdGlvbiB0aXRsZT0nVGhlIE9BdXRoIEFjY2VzcyBUb2tlbiBUeXBlIFJlZ2lzdHJ5JyBh bmNob3I9J3R5cGUtcmVnaXN0cnknPgogICAgICAgIDx0PgogICAgICAgICAgVGhpcyBzcGVjaWZp Y2F0aW9uIGVzdGFibGlzaGVzIHRoZSBPQXV0aCBhY2Nlc3MgdG9rZW4gdHlwZSByZWdpc3RyeS4K ICAgICAgICA8L3Q+CiAgICAgICAgPHQ+CiAgICAgICAgICBBY2Nlc3MgdG9rZW4gdHlwZXMgYXJl IHJlZ2lzdGVyZWQgd2l0aCBhIFNwZWNpZmljYXRpb24gUmVxdWlyZWQKICAgICAgICAgICg8eHJl ZiB0YXJnZXQ9J1JGQzUyMjYnIC8+KSBhZnRlciBhIHR3byB3ZWVrIHJldmlldyBwZXJpb2Qgb24g dGhlIFtUQkRdQGlldGYub3JnIG1haWxpbmcKICAgICAgICAgIGxpc3QsIG9uIHRoZSBhZHZpY2Ug b2Ygb25lIG9yIG1vcmUgRGVzaWduYXRlZCBFeHBlcnRzLiBIb3dldmVyLCB0byBhbGxvdyBmb3Ig dGhlCiAgICAgICAgICBhbGxvY2F0aW9uIG9mIHZhbHVlcyBwcmlvciB0byBwdWJsaWNhdGlvbiwg dGhlIERlc2lnbmF0ZWQgRXhwZXJ0KHMpIG1heSBhcHByb3ZlCiAgICAgICAgICByZWdpc3RyYXRp b24gb25jZSB0aGV5IGFyZSBzYXRpc2ZpZWQgdGhhdCBzdWNoIGEgc3BlY2lmaWNhdGlvbiB3aWxs IGJlIHB1Ymxpc2hlZC4KICAgICAgICA8L3Q+CiAgICAgICAgPHQ+CiAgICAgICAgICBSZWdpc3Ry YXRpb24gcmVxdWVzdHMgbXVzdCBiZSBzZW50IHRvIHRoZSBbVEJEXUBpZXRmLm9yZyBtYWlsaW5n IGxpc3QgZm9yIHJldmlldyBhbmQKICAgICAgICAgIGNvbW1lbnQsIHdpdGggYW4gYXBwcm9wcmlh dGUgc3ViamVjdCAoZS5nLiwgIlJlcXVlc3QgZm9yIGFjY2VzcyB0b2tlbiB0eXBlOiBleGFtcGxl IikuCiAgICAgICAgICBbWyBOb3RlIHRvIFJGQy1FRElUT1I6IFRoZSBuYW1lIG9mIHRoZSBtYWls aW5nIGxpc3Qgc2hvdWxkIGJlIGRldGVybWluZWQgaW4gY29uc3VsdGF0aW9uCiAgICAgICAgICB3 aXRoIHRoZSBJRVNHIGFuZCBJQU5BLiBTdWdnZXN0ZWQgbmFtZTogb2F1dGgtZXh0LXJldmlldy4g XV0KICAgICAgICA8L3Q+CiAgICAgICAgPHQ+CiAgICAgICAgICBXaXRoaW4gdGhlIHJldmlldyBw ZXJpb2QsIHRoZSBEZXNpZ25hdGVkIEV4cGVydChzKSB3aWxsIGVpdGhlciBhcHByb3ZlIG9yCiAg ICAgICAgICBkZW55IHRoZSByZWdpc3RyYXRpb24gcmVxdWVzdCwgY29tbXVuaWNhdGluZyB0aGlz IGRlY2lzaW9uIHRvIHRoZSByZXZpZXcgbGlzdCBhbmQgSUFOQS4KICAgICAgICAgIERlbmlhbHMg c2hvdWxkIGluY2x1ZGUgYW4gZXhwbGFuYXRpb24gYW5kLCBpZiBhcHBsaWNhYmxlLCBzdWdnZXN0 aW9ucyBhcyB0byBob3cgdG8gbWFrZQogICAgICAgICAgdGhlIHJlcXVlc3Qgc3VjY2Vzc2Z1bC4K ICAgICAgICA8L3Q+CiAgICAgICAgPHQ+CiAgICAgICAgICBJQU5BIG11c3Qgb25seSBhY2NlcHQg cmVnaXN0cnkgdXBkYXRlcyBmcm9tIHRoZSBEZXNpZ25hdGVkIEV4cGVydChzKSwgYW5kIHNob3Vs ZCBkaXJlY3QKICAgICAgICAgIGFsbCByZXF1ZXN0cyBmb3IgcmVnaXN0cmF0aW9uIHRvIHRoZSBy ZXZpZXcgbWFpbGluZyBsaXN0LgogICAgICAgIDwvdD4KCiAgICAgICAgPHNlY3Rpb24gdGl0bGU9 J1JlZ2lzdHJhdGlvbiBUZW1wbGF0ZSc+CiAgICAgICAgICA8dD4KICAgICAgICAgICAgPGxpc3Qg c3R5bGU9J2hhbmdpbmcnPgogICAgICAgICAgICAgIDx0IGhhbmdUZXh0PSdUeXBlIG5hbWU6Jz4K ICAgICAgICAgICAgICAgIDx2c3BhY2UgLz4KICAgICAgICAgICAgICAgIFRoZSBuYW1lIHJlcXVl c3RlZCAoZS5nLiwgImV4YW1wbGUiKS4KICAgICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgICAg PHQgaGFuZ1RleHQ9J0FkZGl0aW9uYWwgVG9rZW4gRW5kcG9pbnQgUmVzcG9uc2UgUGFyYW1ldGVy czonPgogICAgICAgICAgICAgICAgPHZzcGFjZSAvPgogICAgICAgICAgICAgICAgQWRkaXRpb25h bCByZXNwb25zZSBwYXJhbWV0ZXJzIHJldHVybmVkIHRvZ2V0aGVyIHdpdGggdGhlCiAgICAgICAg ICAgICAgICA8c3Bhbnggc3R5bGU9J3ZlcmInPmFjY2Vzc190b2tlbjwvc3Bhbng+IHBhcmFtZXRl ci4gTmV3IHBhcmFtZXRlcnMgTVVTVCBiZQogICAgICAgICAgICAgICAgc2VwYXJhdGVseSByZWdp c3RlcmVkIGluIHRoZSBPQXV0aCBwYXJhbWV0ZXJzIHJlZ2lzdHJ5IGFzIGRlc2NyaWJlZCBieQog ICAgICAgICAgICAgICAgPHhyZWYgdGFyZ2V0PSdwYXJhbWV0ZXJzLXJlZ2lzdHJ5JyAvPi4KICAg ICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgICAgPHQgaGFuZ1RleHQ9J0hUVFAgQXV0aGVudGlj YXRpb24gU2NoZW1lKHMpOic+CiAgICAgICAgICAgICAgICA8dnNwYWNlIC8+CiAgICAgICAgICAg ICAgICBUaGUgSFRUUCBhdXRoZW50aWNhdGlvbiBzY2hlbWUgbmFtZShzKSwgaWYgYW55LCB1c2Vk IHRvIGF1dGhlbnRpY2F0ZSBwcm90ZWN0ZWQKICAgICAgICAgICAgICAgIHJlc291cmNlcyByZXF1 ZXN0cyB1c2luZyBhY2Nlc3MgdG9rZW5zIG9mIHRoaXMgdHlwZS4KICAgICAgICAgICAgICA8L3Q+ CiAgICAgICAgICAgICAgPHQgaGFuZ1RleHQ9J0NoYW5nZSBjb250cm9sbGVyOic+CiAgICAgICAg ICAgICAgICA8dnNwYWNlIC8+CiAgICAgICAgICAgICAgICBGb3Igc3RhbmRhcmRzLXRyYWNrIFJG Q3MsIHN0YXRlICJJRVRGIi4gRm9yIG90aGVycywgZ2l2ZSB0aGUgbmFtZSBvZiB0aGUKICAgICAg ICAgICAgICAgIHJlc3BvbnNpYmxlIHBhcnR5LiBPdGhlciBkZXRhaWxzIChlLmcuLCBwb3N0YWwg YWRkcmVzcywgZS1tYWlsIGFkZHJlc3MsIGhvbWUgcGFnZQogICAgICAgICAgICAgICAgVVJJKSBt YXkgYWxzbyBiZSBpbmNsdWRlZC4KICAgICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgICAgPHQg aGFuZ1RleHQ9J1NwZWNpZmljYXRpb24gZG9jdW1lbnQocyk6Jz4KICAgICAgICAgICAgICAgIDx2 c3BhY2UgLz4KICAgICAgICAgICAgICAgIFJlZmVyZW5jZSB0byB0aGUgZG9jdW1lbnQgdGhhdCBz cGVjaWZpZXMgdGhlIHBhcmFtZXRlciwgcHJlZmVyYWJseSBpbmNsdWRpbmcgYSBVUkkgdGhhdAog ICAgICAgICAgICAgICAgY2FuIGJlIHVzZWQgdG8gcmV0cmlldmUgYSBjb3B5IG9mIHRoZSBkb2N1 bWVudC4gQW4gaW5kaWNhdGlvbiBvZiB0aGUgcmVsZXZhbnQKICAgICAgICAgICAgICAgIHNlY3Rp b25zIG1heSBhbHNvIGJlIGluY2x1ZGVkLCBidXQgaXMgbm90IHJlcXVpcmVkLgogICAgICAgICAg ICAgIDwvdD4KICAgICAgICAgICAgPC9saXN0PgogICAgICAgICAgPC90PgogICAgICAgIDwvc2Vj dGlvbj4KCiAgICAgIDwvc2VjdGlvbj4KCiAgICAgIDxzZWN0aW9uIHRpdGxlPSdUaGUgT0F1dGgg UGFyYW1ldGVycyBSZWdpc3RyeScgYW5jaG9yPSdwYXJhbWV0ZXJzLXJlZ2lzdHJ5Jz4KICAgICAg ICA8dD4KICAgICAgICAgIFRoaXMgc3BlY2lmaWNhdGlvbiBlc3RhYmxpc2hlcyB0aGUgT0F1dGgg cGFyYW1ldGVycyByZWdpc3RyeS4KICAgICAgICA8L3Q+CiAgICAgICAgPHQ+CiAgICAgICAgICBB ZGRpdGlvbmFsIHBhcmFtZXRlcnMgZm9yIGluY2x1c2lvbiBpbiB0aGUgYXV0aG9yaXphdGlvbiBl bmRwb2ludCByZXF1ZXN0LCB0aGUKICAgICAgICAgIGF1dGhvcml6YXRpb24gZW5kcG9pbnQgcmVz cG9uc2UsIHRoZSB0b2tlbiBlbmRwb2ludCByZXF1ZXN0LCBvciB0aGUgdG9rZW4gZW5kcG9pbnQK ICAgICAgICAgIHJlc3BvbnNlIGFyZSByZWdpc3RlcmVkIHdpdGggYSBTcGVjaWZpY2F0aW9uIFJl cXVpcmVkCiAgICAgICAgICAoPHhyZWYgdGFyZ2V0PSdSRkM1MjI2JyAvPikgYWZ0ZXIgYSB0d28g d2VlayByZXZpZXcgcGVyaW9kIG9uIHRoZSBbVEJEXUBpZXRmLm9yZyBtYWlsaW5nCiAgICAgICAg ICBsaXN0LCBvbiB0aGUgYWR2aWNlIG9mIG9uZSBvciBtb3JlIERlc2lnbmF0ZWQgRXhwZXJ0cy4g SG93ZXZlciwgdG8gYWxsb3cgZm9yIHRoZQogICAgICAgICAgYWxsb2NhdGlvbiBvZiB2YWx1ZXMg cHJpb3IgdG8gcHVibGljYXRpb24sIHRoZSBEZXNpZ25hdGVkIEV4cGVydChzKSBtYXkgYXBwcm92 ZQogICAgICAgICAgcmVnaXN0cmF0aW9uIG9uY2UgdGhleSBhcmUgc2F0aXNmaWVkIHRoYXQgc3Vj aCBhIHNwZWNpZmljYXRpb24gd2lsbCBiZSBwdWJsaXNoZWQuCiAgICAgICAgPC90PgogICAgICAg IDx0PgogICAgICAgICAgUmVnaXN0cmF0aW9uIHJlcXVlc3RzIG11c3QgYmUgc2VudCB0byB0aGUg W1RCRF1AaWV0Zi5vcmcgbWFpbGluZyBsaXN0IGZvciByZXZpZXcgYW5kCiAgICAgICAgICBjb21t ZW50LCB3aXRoIGFuIGFwcHJvcHJpYXRlIHN1YmplY3QgKGUuZy4sICJSZXF1ZXN0IGZvciBwYXJh bWV0ZXI6IGV4YW1wbGUiKS4KICAgICAgICAgIFtbIE5vdGUgdG8gUkZDLUVESVRPUjogVGhlIG5h bWUgb2YgdGhlIG1haWxpbmcgbGlzdCBzaG91bGQgYmUgZGV0ZXJtaW5lZCBpbiBjb25zdWx0YXRp b24KICAgICAgICAgIHdpdGggdGhlIElFU0cgYW5kIElBTkEuIFN1Z2dlc3RlZCBuYW1lOiBvYXV0 aC1leHQtcmV2aWV3LiBdXQogICAgICAgIDwvdD4KICAgICAgICA8dD4KICAgICAgICAgIFdpdGhp biB0aGUgcmV2aWV3IHBlcmlvZCwgdGhlIERlc2lnbmF0ZWQgRXhwZXJ0KHMpIHdpbGwgZWl0aGVy IGFwcHJvdmUgb3IKICAgICAgICAgIGRlbnkgdGhlIHJlZ2lzdHJhdGlvbiByZXF1ZXN0LCBjb21t dW5pY2F0aW5nIHRoaXMgZGVjaXNpb24gdG8gdGhlIHJldmlldyBsaXN0IGFuZCBJQU5BLgogICAg ICAgICAgRGVuaWFscyBzaG91bGQgaW5jbHVkZSBhbiBleHBsYW5hdGlvbiBhbmQsIGlmIGFwcGxp Y2FibGUsIHN1Z2dlc3Rpb25zIGFzIHRvIGhvdyB0byBtYWtlCiAgICAgICAgICB0aGUgcmVxdWVz dCBzdWNjZXNzZnVsLgogICAgICAgIDwvdD4KICAgICAgICA8dD4KICAgICAgICAgIElBTkEgbXVz dCBvbmx5IGFjY2VwdCByZWdpc3RyeSB1cGRhdGVzIGZyb20gdGhlIERlc2lnbmF0ZWQgRXhwZXJ0 KHMpLCBhbmQgc2hvdWxkIGRpcmVjdAogICAgICAgICAgYWxsIHJlcXVlc3RzIGZvciByZWdpc3Ry YXRpb24gdG8gdGhlIHJldmlldyBtYWlsaW5nIGxpc3QuCiAgICAgICAgPC90PgoKICAgICAgICA8 c2VjdGlvbiB0aXRsZT0nUmVnaXN0cmF0aW9uIFRlbXBsYXRlJz4KICAgICAgICAgIDx0PgogICAg ICAgICAgICA8bGlzdCBzdHlsZT0naGFuZ2luZyc+CiAgICAgICAgICAgICAgPHQgaGFuZ1RleHQ9 J1BhcmFtZXRlciBuYW1lOic+CiAgICAgICAgICAgICAgICA8dnNwYWNlIC8+CiAgICAgICAgICAg ICAgICBUaGUgbmFtZSByZXF1ZXN0ZWQgKGUuZy4sICJleGFtcGxlIikuCiAgICAgICAgICAgICAg PC90PgogICAgICAgICAgICAgIDx0IGhhbmdUZXh0PSdQYXJhbWV0ZXIgdXNhZ2UgbG9jYXRpb246 Jz4KICAgICAgICAgICAgICAgIDx2c3BhY2UgLz4KICAgICAgICAgICAgICAgIFRoZSBsb2NhdGlv bihzKSB3aGVyZSBwYXJhbWV0ZXIgY2FuIGJlIHVzZWQuIFRoZSBwb3NzaWJsZSBsb2NhdGlvbnMg YXJlOgogICAgICAgICAgICAgICAgYXV0aG9yaXphdGlvbiByZXF1ZXN0LCBhdXRob3JpemF0aW9u IHJlc3BvbnNlLCB0b2tlbiByZXF1ZXN0LCBvciB0b2tlbiByZXNwb25zZS4KICAgICAgICAgICAg ICA8L3Q+CiAgICAgICAgICAgICAgPHQgaGFuZ1RleHQ9J0NoYW5nZSBjb250cm9sbGVyOic+CiAg ICAgICAgICAgICAgICA8dnNwYWNlIC8+CiAgICAgICAgICAgICAgICBGb3Igc3RhbmRhcmRzLXRy YWNrIFJGQ3MsIHN0YXRlICJJRVRGIi4gRm9yIG90aGVycywgZ2l2ZSB0aGUgbmFtZSBvZiB0aGUK ICAgICAgICAgICAgICAgIHJlc3BvbnNpYmxlIHBhcnR5LiBPdGhlciBkZXRhaWxzIChlLmcuLCBw b3N0YWwgYWRkcmVzcywgZS1tYWlsIGFkZHJlc3MsIGhvbWUgcGFnZQogICAgICAgICAgICAgICAg VVJJKSBtYXkgYWxzbyBiZSBpbmNsdWRlZC4KICAgICAgICAgICAgICA8L3Q+CiAgICAgICAgICAg ICAgPHQgaGFuZ1RleHQ9J1NwZWNpZmljYXRpb24gZG9jdW1lbnQocyk6Jz4KICAgICAgICAgICAg ICAgIDx2c3BhY2UgLz4KICAgICAgICAgICAgICAgIFJlZmVyZW5jZSB0byB0aGUgZG9jdW1lbnQg dGhhdCBzcGVjaWZpZXMgdGhlIHBhcmFtZXRlciwgcHJlZmVyYWJseSBpbmNsdWRpbmcgYSBVUkkg dGhhdAogICAgICAgICAgICAgICAgY2FuIGJlIHVzZWQgdG8gcmV0cmlldmUgYSBjb3B5IG9mIHRo ZSBkb2N1bWVudC4gQW4gaW5kaWNhdGlvbiBvZiB0aGUgcmVsZXZhbnQKICAgICAgICAgICAgICAg IHNlY3Rpb25zIG1heSBhbHNvIGJlIGluY2x1ZGVkLCBidXQgaXMgbm90IHJlcXVpcmVkLgogICAg ICAgICAgICAgIDwvdD4KICAgICAgICAgICAgPC9saXN0PgogICAgICAgICAgPC90PgogICAgICAg IDwvc2VjdGlvbj4KCiAgICAgICAgPHNlY3Rpb24gdGl0bGU9J0luaXRpYWwgUmVnaXN0cnkgQ29u dGVudHMnPgogICAgICAgICAgPHQ+CiAgICAgICAgICAgIFRoZSBPQXV0aCBQYXJhbWV0ZXJzIFJl Z2lzdHJ5J3MgaW5pdGlhbCBjb250ZW50cyBhcmU6CiAgICAgICAgICA8L3Q+CiAgICAgICAgICA8 dD4KICAgICAgICAgICAgPGxpc3Qgc3R5bGU9J3N5bWJvbHMnPgogICAgICAgICAgICAgIDx0Pgog ICAgICAgICAgICAgICAgUGFyYW1ldGVyIG5hbWU6IGNsaWVudF9pZAogICAgICAgICAgICAgIDwv dD4KICAgICAgICAgICAgICA8dD4KICAgICAgICAgICAgICAgIFBhcmFtZXRlciB1c2FnZSBsb2Nh dGlvbjogYXV0aG9yaXphdGlvbiByZXF1ZXN0LCB0b2tlbiByZXF1ZXN0CiAgICAgICAgICAgICAg PC90PgogICAgICAgICAgICAgIDx0PgogICAgICAgICAgICAgICAgQ2hhbmdlIGNvbnRyb2xsZXI6 IElFVEYKICAgICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgICAgPHQ+CiAgICAgICAgICAgICAg ICBTcGVjaWZpY2F0aW9uIGRvY3VtZW50KHMpOiBbWyB0aGlzIGRvY3VtZW50IF1dCiAgICAgICAg ICAgICAgPC90PgogICAgICAgICAgICA8L2xpc3Q+CiAgICAgICAgICA8L3Q+CiAgICAgICAgICA8 dD4KICAgICAgICAgICAgPGxpc3Qgc3R5bGU9J3N5bWJvbHMnPgogICAgICAgICAgICAgIDx0Pgog ICAgICAgICAgICAgICAgUGFyYW1ldGVyIG5hbWU6IGNsaWVudF9zZWNyZXQKICAgICAgICAgICAg ICA8L3Q+CiAgICAgICAgICAgICAgPHQ+CiAgICAgICAgICAgICAgICBQYXJhbWV0ZXIgdXNhZ2Ug bG9jYXRpb246IHRva2VuIHJlcXVlc3QKICAgICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgICAg PHQ+CiAgICAgICAgICAgICAgICBDaGFuZ2UgY29udHJvbGxlcjogSUVURgogICAgICAgICAgICAg IDwvdD4KICAgICAgICAgICAgICA8dD4KICAgICAgICAgICAgICAgIFNwZWNpZmljYXRpb24gZG9j dW1lbnQocyk6IFtbIHRoaXMgZG9jdW1lbnQgXV0KICAgICAgICAgICAgICA8L3Q+CiAgICAgICAg ICAgIDwvbGlzdD4KICAgICAgICAgIDwvdD4KICAgICAgICAgIDx0PgogICAgICAgICAgICA8bGlz dCBzdHlsZT0nc3ltYm9scyc+CiAgICAgICAgICAgICAgPHQ+CiAgICAgICAgICAgICAgICBQYXJh bWV0ZXIgbmFtZTogcmVzcG9uc2VfdHlwZQogICAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAg ICA8dD4KICAgICAgICAgICAgICAgIFBhcmFtZXRlciB1c2FnZSBsb2NhdGlvbjogYXV0aG9yaXph dGlvbiByZXF1ZXN0CiAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICAgIDx0PgogICAgICAg ICAgICAgICAgQ2hhbmdlIGNvbnRyb2xsZXI6IElFVEYKICAgICAgICAgICAgICA8L3Q+CiAgICAg ICAgICAgICAgPHQ+CiAgICAgICAgICAgICAgICBTcGVjaWZpY2F0aW9uIGRvY3VtZW50KHMpOiBb WyB0aGlzIGRvY3VtZW50IF1dCiAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICA8L2xpc3Q+ CiAgICAgICAgICA8L3Q+CiAgICAgICAgICA8dD4KICAgICAgICAgICAgPGxpc3Qgc3R5bGU9J3N5 bWJvbHMnPgogICAgICAgICAgICAgIDx0PgogICAgICAgICAgICAgICAgUGFyYW1ldGVyIG5hbWU6 IHJlZGlyZWN0X3VyaQogICAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAgICA8dD4KICAgICAg ICAgICAgICAgIFBhcmFtZXRlciB1c2FnZSBsb2NhdGlvbjogYXV0aG9yaXphdGlvbiByZXF1ZXN0 LCB0b2tlbiByZXF1ZXN0CiAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICAgIDx0PgogICAg ICAgICAgICAgICAgQ2hhbmdlIGNvbnRyb2xsZXI6IElFVEYKICAgICAgICAgICAgICA8L3Q+CiAg ICAgICAgICAgICAgPHQ+CiAgICAgICAgICAgICAgICBTcGVjaWZpY2F0aW9uIGRvY3VtZW50KHMp OiBbWyB0aGlzIGRvY3VtZW50IF1dCiAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICA8L2xp c3Q+CiAgICAgICAgICA8L3Q+CiAgICAgICAgICA8dD4KICAgICAgICAgICAgPGxpc3Qgc3R5bGU9 J3N5bWJvbHMnPgogICAgICAgICAgICAgIDx0PgogICAgICAgICAgICAgICAgUGFyYW1ldGVyIG5h bWU6IHNjb3BlCiAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICAgIDx0PgogICAgICAgICAg ICAgICAgUGFyYW1ldGVyIHVzYWdlIGxvY2F0aW9uOiBhdXRob3JpemF0aW9uIHJlcXVlc3QsIGF1 dGhvcml6YXRpb24gcmVzcG9uc2UsIHRva2VuCiAgICAgICAgICAgICAgICByZXF1ZXN0LCB0b2tl biByZXNwb25zZQogICAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAgICA8dD4KICAgICAgICAg ICAgICAgIENoYW5nZSBjb250cm9sbGVyOiBJRVRGCiAgICAgICAgICAgICAgPC90PgogICAgICAg ICAgICAgIDx0PgogICAgICAgICAgICAgICAgU3BlY2lmaWNhdGlvbiBkb2N1bWVudChzKTogW1sg dGhpcyBkb2N1bWVudCBdXQogICAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAgPC9saXN0Pgog ICAgICAgICAgPC90PgogICAgICAgICAgPHQ+CiAgICAgICAgICAgIDxsaXN0IHN0eWxlPSdzeW1i b2xzJz4KICAgICAgICAgICAgICA8dD4KICAgICAgICAgICAgICAgIFBhcmFtZXRlciBuYW1lOiBz dGF0ZQogICAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAgICA8dD4KICAgICAgICAgICAgICAg IFBhcmFtZXRlciB1c2FnZSBsb2NhdGlvbjogYXV0aG9yaXphdGlvbiByZXF1ZXN0LCBhdXRob3Jp emF0aW9uIHJlc3BvbnNlCiAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICAgIDx0PgogICAg ICAgICAgICAgICAgQ2hhbmdlIGNvbnRyb2xsZXI6IElFVEYKICAgICAgICAgICAgICA8L3Q+CiAg ICAgICAgICAgICAgPHQ+CiAgICAgICAgICAgICAgICBTcGVjaWZpY2F0aW9uIGRvY3VtZW50KHMp OiBbWyB0aGlzIGRvY3VtZW50IF1dCiAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICA8L2xp c3Q+CiAgICAgICAgICA8L3Q+CiAgICAgICAgICA8dD4KICAgICAgICAgICAgPGxpc3Qgc3R5bGU9 J3N5bWJvbHMnPgogICAgICAgICAgICAgIDx0PgogICAgICAgICAgICAgICAgUGFyYW1ldGVyIG5h bWU6IGNvZGUKICAgICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgICAgPHQ+CiAgICAgICAgICAg ICAgICBQYXJhbWV0ZXIgdXNhZ2UgbG9jYXRpb246IGF1dGhvcml6YXRpb24gcmVzcG9uc2UsIHRv a2VuIHJlcXVlc3QKICAgICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgICAgPHQ+CiAgICAgICAg ICAgICAgICBDaGFuZ2UgY29udHJvbGxlcjogSUVURgogICAgICAgICAgICAgIDwvdD4KICAgICAg ICAgICAgICA8dD4KICAgICAgICAgICAgICAgIFNwZWNpZmljYXRpb24gZG9jdW1lbnQocyk6IFtb IHRoaXMgZG9jdW1lbnQgXV0KICAgICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgIDwvbGlzdD4K ICAgICAgICAgIDwvdD4KICAgICAgICAgIDx0PgogICAgICAgICAgICA8bGlzdCBzdHlsZT0nc3lt Ym9scyc+CiAgICAgICAgICAgICAgPHQ+CiAgICAgICAgICAgICAgICBQYXJhbWV0ZXIgbmFtZTog ZXJyb3JfZGVzY3JpcHRpb24KICAgICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgICAgPHQ+CiAg ICAgICAgICAgICAgICBQYXJhbWV0ZXIgdXNhZ2UgbG9jYXRpb246IGF1dGhvcml6YXRpb24gcmVz cG9uc2UsIHRva2VuIHJlc3BvbnNlCiAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICAgIDx0 PgogICAgICAgICAgICAgICAgQ2hhbmdlIGNvbnRyb2xsZXI6IElFVEYKICAgICAgICAgICAgICA8 L3Q+CiAgICAgICAgICAgICAgPHQ+CiAgICAgICAgICAgICAgICBTcGVjaWZpY2F0aW9uIGRvY3Vt ZW50KHMpOiBbWyB0aGlzIGRvY3VtZW50IF1dCiAgICAgICAgICAgICAgPC90PgogICAgICAgICAg ICA8L2xpc3Q+CiAgICAgICAgICA8L3Q+CiAgICAgICAgICA8dD4KICAgICAgICAgICAgPGxpc3Qg c3R5bGU9J3N5bWJvbHMnPgogICAgICAgICAgICAgIDx0PgogICAgICAgICAgICAgICAgUGFyYW1l dGVyIG5hbWU6IGVycm9yX3VyaQogICAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAgICA8dD4K ICAgICAgICAgICAgICAgIFBhcmFtZXRlciB1c2FnZSBsb2NhdGlvbjogYXV0aG9yaXphdGlvbiBy ZXNwb25zZSwgdG9rZW4gcmVzcG9uc2UKICAgICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgICAg PHQ+CiAgICAgICAgICAgICAgICBDaGFuZ2UgY29udHJvbGxlcjogSUVURgogICAgICAgICAgICAg IDwvdD4KICAgICAgICAgICAgICA8dD4KICAgICAgICAgICAgICAgIFNwZWNpZmljYXRpb24gZG9j dW1lbnQocyk6IFtbIHRoaXMgZG9jdW1lbnQgXV0KICAgICAgICAgICAgICA8L3Q+CiAgICAgICAg ICAgIDwvbGlzdD4KICAgICAgICAgIDwvdD4KICAgICAgICAgIDx0PgogICAgICAgICAgICA8bGlz dCBzdHlsZT0nc3ltYm9scyc+CiAgICAgICAgICAgICAgPHQ+CiAgICAgICAgICAgICAgICBQYXJh bWV0ZXIgbmFtZTogZ3JhbnRfdHlwZQogICAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAgICA8 dD4KICAgICAgICAgICAgICAgIFBhcmFtZXRlciB1c2FnZSBsb2NhdGlvbjogdG9rZW4gcmVxdWVz dAogICAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAgICA8dD4KICAgICAgICAgICAgICAgIENo YW5nZSBjb250cm9sbGVyOiBJRVRGCiAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICAgIDx0 PgogICAgICAgICAgICAgICAgU3BlY2lmaWNhdGlvbiBkb2N1bWVudChzKTogW1sgdGhpcyBkb2N1 bWVudCBdXQogICAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAgPC9saXN0PgogICAgICAgICAg PC90PgogICAgICAgICAgPHQ+CiAgICAgICAgICAgIDxsaXN0IHN0eWxlPSdzeW1ib2xzJz4KICAg ICAgICAgICAgICA8dD4KICAgICAgICAgICAgICAgIFBhcmFtZXRlciBuYW1lOiBhY2Nlc3NfdG9r ZW4KICAgICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgICAgPHQ+CiAgICAgICAgICAgICAgICBQ YXJhbWV0ZXIgdXNhZ2UgbG9jYXRpb246IGF1dGhvcml6YXRpb24gcmVzcG9uc2UsIHRva2VuIHJl c3BvbnNlCiAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICAgIDx0PgogICAgICAgICAgICAg ICAgQ2hhbmdlIGNvbnRyb2xsZXI6IElFVEYKICAgICAgICAgICAgICA8L3Q+CiAgICAgICAgICAg ICAgPHQ+CiAgICAgICAgICAgICAgICBTcGVjaWZpY2F0aW9uIGRvY3VtZW50KHMpOiBbWyB0aGlz IGRvY3VtZW50IF1dCiAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICA8L2xpc3Q+CiAgICAg ICAgICA8L3Q+CiAgICAgICAgICA8dD4KICAgICAgICAgICAgPGxpc3Qgc3R5bGU9J3N5bWJvbHMn PgogICAgICAgICAgICAgIDx0PgogICAgICAgICAgICAgICAgUGFyYW1ldGVyIG5hbWU6IHRva2Vu X3R5cGUKICAgICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgICAgPHQ+CiAgICAgICAgICAgICAg ICBQYXJhbWV0ZXIgdXNhZ2UgbG9jYXRpb246IGF1dGhvcml6YXRpb24gcmVzcG9uc2UsIHRva2Vu IHJlc3BvbnNlCiAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICAgIDx0PgogICAgICAgICAg ICAgICAgQ2hhbmdlIGNvbnRyb2xsZXI6IElFVEYKICAgICAgICAgICAgICA8L3Q+CiAgICAgICAg ICAgICAgPHQ+CiAgICAgICAgICAgICAgICBTcGVjaWZpY2F0aW9uIGRvY3VtZW50KHMpOiBbWyB0 aGlzIGRvY3VtZW50IF1dCiAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICA8L2xpc3Q+CiAg ICAgICAgICA8L3Q+CiAgICAgICAgICA8dD4KICAgICAgICAgICAgPGxpc3Qgc3R5bGU9J3N5bWJv bHMnPgogICAgICAgICAgICAgIDx0PgogICAgICAgICAgICAgICAgUGFyYW1ldGVyIG5hbWU6IGV4 cGlyZXNfaW4KICAgICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgICAgPHQ+CiAgICAgICAgICAg ICAgICBQYXJhbWV0ZXIgdXNhZ2UgbG9jYXRpb246IGF1dGhvcml6YXRpb24gcmVzcG9uc2UsIHRv a2VuIHJlc3BvbnNlCiAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICAgIDx0PgogICAgICAg ICAgICAgICAgQ2hhbmdlIGNvbnRyb2xsZXI6IElFVEYKICAgICAgICAgICAgICA8L3Q+CiAgICAg ICAgICAgICAgPHQ+CiAgICAgICAgICAgICAgICBTcGVjaWZpY2F0aW9uIGRvY3VtZW50KHMpOiBb WyB0aGlzIGRvY3VtZW50IF1dCiAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICA8L2xpc3Q+ CiAgICAgICAgICA8L3Q+CiAgICAgICAgICA8dD4KICAgICAgICAgICAgPGxpc3Qgc3R5bGU9J3N5 bWJvbHMnPgogICAgICAgICAgICAgIDx0PgogICAgICAgICAgICAgICAgUGFyYW1ldGVyIG5hbWU6 IHVzZXJuYW1lCiAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICAgIDx0PgogICAgICAgICAg ICAgICAgUGFyYW1ldGVyIHVzYWdlIGxvY2F0aW9uOiB0b2tlbiByZXF1ZXN0CiAgICAgICAgICAg ICAgPC90PgogICAgICAgICAgICAgIDx0PgogICAgICAgICAgICAgICAgQ2hhbmdlIGNvbnRyb2xs ZXI6IElFVEYKICAgICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgICAgPHQ+CiAgICAgICAgICAg ICAgICBTcGVjaWZpY2F0aW9uIGRvY3VtZW50KHMpOiBbWyB0aGlzIGRvY3VtZW50IF1dCiAgICAg ICAgICAgICAgPC90PgogICAgICAgICAgICA8L2xpc3Q+CiAgICAgICAgICA8L3Q+CiAgICAgICAg ICA8dD4KICAgICAgICAgICAgPGxpc3Qgc3R5bGU9J3N5bWJvbHMnPgogICAgICAgICAgICAgIDx0 PgogICAgICAgICAgICAgICAgUGFyYW1ldGVyIG5hbWU6IHBhc3N3b3JkCiAgICAgICAgICAgICAg PC90PgogICAgICAgICAgICAgIDx0PgogICAgICAgICAgICAgICAgUGFyYW1ldGVyIHVzYWdlIGxv Y2F0aW9uOiB0b2tlbiByZXF1ZXN0CiAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICAgIDx0 PgogICAgICAgICAgICAgICAgQ2hhbmdlIGNvbnRyb2xsZXI6IElFVEYKICAgICAgICAgICAgICA8 L3Q+CiAgICAgICAgICAgICAgPHQ+CiAgICAgICAgICAgICAgICBTcGVjaWZpY2F0aW9uIGRvY3Vt ZW50KHMpOiBbWyB0aGlzIGRvY3VtZW50IF1dCiAgICAgICAgICAgICAgPC90PgogICAgICAgICAg ICA8L2xpc3Q+CiAgICAgICAgICA8L3Q+CiAgICAgICAgICA8dD4KICAgICAgICAgICAgPGxpc3Qg c3R5bGU9J3N5bWJvbHMnPgogICAgICAgICAgICAgIDx0PgogICAgICAgICAgICAgICAgUGFyYW1l dGVyIG5hbWU6IHJlZnJlc2hfdG9rZW4KICAgICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgICAg PHQ+CiAgICAgICAgICAgICAgICBQYXJhbWV0ZXIgdXNhZ2UgbG9jYXRpb246IHRva2VuIHJlcXVl c3QsIHRva2VuIHJlc3BvbnNlCiAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICAgIDx0Pgog ICAgICAgICAgICAgICAgQ2hhbmdlIGNvbnRyb2xsZXI6IElFVEYKICAgICAgICAgICAgICA8L3Q+ CiAgICAgICAgICAgICAgPHQ+CiAgICAgICAgICAgICAgICBTcGVjaWZpY2F0aW9uIGRvY3VtZW50 KHMpOiBbWyB0aGlzIGRvY3VtZW50IF1dCiAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICA8 L2xpc3Q+CiAgICAgICAgICA8L3Q+CiAgICAgICAgPC9zZWN0aW9uPgoKICAgICAgPC9zZWN0aW9u PgoKICAgICAgPHNlY3Rpb24gdGl0bGU9J1RoZSBPQXV0aCBBdXRob3JpemF0aW9uIEVuZHBvaW50 IFJlc3BvbnNlIFR5cGUgUmVnaXN0cnknIGFuY2hvcj0ncmVzcG9uc2UtdHlwZS1yZWdpc3RyeSc+ CiAgICAgICAgPHQ+CiAgICAgICAgICBUaGlzIHNwZWNpZmljYXRpb24gZXN0YWJsaXNoZXMgdGhl IE9BdXRoIGF1dGhvcml6YXRpb24gZW5kcG9pbnQgcmVzcG9uc2UgdHlwZSByZWdpc3RyeS4KICAg ICAgICA8L3Q+CiAgICAgICAgPHQ+CiAgICAgICAgICAgIEFkZGl0aW9uYWwgcmVzcG9uc2UgdHlw ZSBmb3IgdXNlIHdpdGggdGhlIGF1dGhvcml6YXRpb24gZW5kcG9pbnQgYXJlIHJlZ2lzdGVyZWQg d2l0aCBhCiAgICAgICAgICAgIFNwZWNpZmljYXRpb24gUmVxdWlyZWQgKDx4cmVmIHRhcmdldD0n UkZDNTIyNicgLz4pIGFmdGVyIGEgdHdvIHdlZWsgcmV2aWV3IHBlcmlvZCBvbgogICAgICAgICAg ICB0aGUgW1RCRF1AaWV0Zi5vcmcgbWFpbGluZyBsaXN0LCBvbiB0aGUgYWR2aWNlIG9mIG9uZSBv ciBtb3JlIERlc2lnbmF0ZWQgRXhwZXJ0cy4KICAgICAgICAgICAgSG93ZXZlciwgdG8gYWxsb3cg Zm9yIHRoZSBhbGxvY2F0aW9uIG9mIHZhbHVlcyBwcmlvciB0byBwdWJsaWNhdGlvbiwgdGhlIERl c2lnbmF0ZWQKICAgICAgICAgICAgRXhwZXJ0KHMpIG1heSBhcHByb3ZlIHJlZ2lzdHJhdGlvbiBv bmNlIHRoZXkgYXJlIHNhdGlzZmllZCB0aGF0IHN1Y2ggYSBzcGVjaWZpY2F0aW9uCiAgICAgICAg ICAgIHdpbGwgYmUgcHVibGlzaGVkLgogICAgICAgICAgPC90PgogICAgICAgICAgPHQ+CiAgICAg ICAgICAgIFJlZ2lzdHJhdGlvbiByZXF1ZXN0cyBtdXN0IGJlIHNlbnQgdG8gdGhlIFtUQkRdQGll dGYub3JnIG1haWxpbmcgbGlzdCBmb3IgcmV2aWV3IGFuZAogICAgICAgICAgICBjb21tZW50LCB3 aXRoIGFuIGFwcHJvcHJpYXRlIHN1YmplY3QgKGUuZy4sICJSZXF1ZXN0IGZvciByZXNwb25zZSB0 eXBlOiBleGFtcGxlIikuCiAgICAgICAgICAgIFtbIE5vdGUgdG8gUkZDLUVESVRPUjogVGhlIG5h bWUgb2YgdGhlIG1haWxpbmcgbGlzdCBzaG91bGQgYmUgZGV0ZXJtaW5lZCBpbiBjb25zdWx0YXRp b24KICAgICAgICAgICAgd2l0aCB0aGUgSUVTRyBhbmQgSUFOQS4gU3VnZ2VzdGVkIG5hbWU6IG9h dXRoLWV4dC1yZXZpZXcuIF1dCiAgICAgICAgICA8L3Q+CiAgICAgICAgICA8dD4KICAgICAgICAg ICAgV2l0aGluIHRoZSByZXZpZXcgcGVyaW9kLCB0aGUgRGVzaWduYXRlZCBFeHBlcnQocykgd2ls bCBlaXRoZXIgYXBwcm92ZSBvcgogICAgICAgICAgICBkZW55IHRoZSByZWdpc3RyYXRpb24gcmVx dWVzdCwgY29tbXVuaWNhdGluZyB0aGlzIGRlY2lzaW9uIHRvIHRoZSByZXZpZXcgbGlzdCBhbmQg SUFOQS4KICAgICAgICAgICAgRGVuaWFscyBzaG91bGQgaW5jbHVkZSBhbiBleHBsYW5hdGlvbiBh bmQsIGlmIGFwcGxpY2FibGUsIHN1Z2dlc3Rpb25zIGFzIHRvIGhvdyB0byBtYWtlCiAgICAgICAg ICAgIHRoZSByZXF1ZXN0IHN1Y2Nlc3NmdWwuCiAgICAgICAgICA8L3Q+CiAgICAgICAgICA8dD4K ICAgICAgICAgICAgSUFOQSBtdXN0IG9ubHkgYWNjZXB0IHJlZ2lzdHJ5IHVwZGF0ZXMgZnJvbSB0 aGUgRGVzaWduYXRlZCBFeHBlcnQocyksIGFuZCBzaG91bGQgZGlyZWN0CiAgICAgICAgICAgIGFs bCByZXF1ZXN0cyBmb3IgcmVnaXN0cmF0aW9uIHRvIHRoZSByZXZpZXcgbWFpbGluZyBsaXN0Lgog ICAgICAgICAgPC90PgoKCiAgICAgICAgICA8c2VjdGlvbiB0aXRsZT0nUmVnaXN0cmF0aW9uIFRl bXBsYXRlJz4KICAgICAgICAgIDx0PgogICAgICAgICAgICA8bGlzdCBzdHlsZT0naGFuZ2luZyc+ CiAgICAgICAgICAgICAgPHQgaGFuZ1RleHQ9J1Jlc3BvbnNlIHR5cGUgbmFtZTonPgogICAgICAg ICAgICAgICAgPHZzcGFjZSAvPgogICAgICAgICAgICAgICAgVGhlIG5hbWUgcmVxdWVzdGVkIChl LmcuLCAiZXhhbXBsZSIpLgogICAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAgICA8dCBoYW5n VGV4dD0nQ2hhbmdlIGNvbnRyb2xsZXI6Jz4KICAgICAgICAgICAgICAgIDx2c3BhY2UgLz4KICAg ICAgICAgICAgICAgIEZvciBzdGFuZGFyZHMtdHJhY2sgUkZDcywgc3RhdGUgIklFVEYiLiBGb3Ig b3RoZXJzLCBnaXZlIHRoZSBuYW1lIG9mIHRoZQogICAgICAgICAgICAgICAgcmVzcG9uc2libGUg cGFydHkuIE90aGVyIGRldGFpbHMgKGUuZy4sIHBvc3RhbCBhZGRyZXNzLCBlLW1haWwgYWRkcmVz cywgaG9tZSBwYWdlCiAgICAgICAgICAgICAgICBVUkkpIG1heSBhbHNvIGJlIGluY2x1ZGVkLgog ICAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAgICA8dCBoYW5nVGV4dD0nU3BlY2lmaWNhdGlv biBkb2N1bWVudChzKTonPgogICAgICAgICAgICAgICAgPHZzcGFjZSAvPgogICAgICAgICAgICAg ICAgUmVmZXJlbmNlIHRvIHRoZSBkb2N1bWVudCB0aGF0IHNwZWNpZmllcyB0aGUgdHlwZSwgcHJl ZmVyYWJseSBpbmNsdWRpbmcgYSBVUkkgdGhhdAogICAgICAgICAgICAgICAgY2FuIGJlIHVzZWQg dG8gcmV0cmlldmUgYSBjb3B5IG9mIHRoZSBkb2N1bWVudC4gQW4gaW5kaWNhdGlvbiBvZiB0aGUg cmVsZXZhbnQKICAgICAgICAgICAgICAgIHNlY3Rpb25zIG1heSBhbHNvIGJlIGluY2x1ZGVkLCBi dXQgaXMgbm90IHJlcXVpcmVkLgogICAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAgPC9saXN0 PgogICAgICAgICAgPC90PgogICAgICAgIDwvc2VjdGlvbj4KCiAgICAgICAgPHNlY3Rpb24gdGl0 bGU9J0luaXRpYWwgUmVnaXN0cnkgQ29udGVudHMnPgogICAgICAgICAgPHQ+CiAgICAgICAgICAg IFRoZSBPQXV0aCBBdXRob3JpemF0aW9uIEVuZHBvaW50IFJlc3BvbnNlIFR5cGUgUmVnaXN0cnkn cyBpbml0aWFsIGNvbnRlbnRzIGFyZToKICAgICAgICAgIDwvdD4KICAgICAgICAgIDx0PgogICAg ICAgICAgICA8bGlzdCBzdHlsZT0nc3ltYm9scyc+CiAgICAgICAgICAgICAgPHQ+CiAgICAgICAg ICAgICAgICBSZXNwb25zZSB0eXBlIG5hbWU6IGNvZGUKICAgICAgICAgICAgICA8L3Q+CiAgICAg ICAgICAgICAgPHQ+CiAgICAgICAgICAgICAgICBDaGFuZ2UgY29udHJvbGxlcjogSUVURgogICAg ICAgICAgICAgIDwvdD4KICAgICAgICAgICAgICA8dD4KICAgICAgICAgICAgICAgIFNwZWNpZmlj YXRpb24gZG9jdW1lbnQocyk6IFtbIHRoaXMgZG9jdW1lbnQgXV0KICAgICAgICAgICAgICA8L3Q+ CiAgICAgICAgICAgIDwvbGlzdD4KICAgICAgICAgIDwvdD4KICAgICAgICAgIDx0PgogICAgICAg ICAgICA8bGlzdCBzdHlsZT0nc3ltYm9scyc+CiAgICAgICAgICAgICAgPHQ+CiAgICAgICAgICAg ICAgICBSZXNwb25zZSB0eXBlIG5hbWU6IHRva2VuCiAgICAgICAgICAgICAgPC90PgogICAgICAg ICAgICAgIDx0PgogICAgICAgICAgICAgICAgQ2hhbmdlIGNvbnRyb2xsZXI6IElFVEYKICAgICAg ICAgICAgICA8L3Q+CiAgICAgICAgICAgICAgPHQ+CiAgICAgICAgICAgICAgICBTcGVjaWZpY2F0 aW9uIGRvY3VtZW50KHMpOiBbWyB0aGlzIGRvY3VtZW50IF1dCiAgICAgICAgICAgICAgPC90Pgog ICAgICAgICAgICA8L2xpc3Q+CiAgICAgICAgICA8L3Q+CiAgICAgICAgPC9zZWN0aW9uPgoKICAg ICAgPC9zZWN0aW9uPgoKICAgICAgPHNlY3Rpb24gdGl0bGU9J1RoZSBPQXV0aCBFeHRlbnNpb25z IEVycm9yIFJlZ2lzdHJ5JyBhbmNob3I9J2Vycm9yLXJlZ2lzdHJ5Jz4KICAgICAgICA8dD4KICAg ICAgICAgIFRoaXMgc3BlY2lmaWNhdGlvbiBlc3RhYmxpc2hlcyB0aGUgT0F1dGggZXh0ZW5zaW9u cyBlcnJvciByZWdpc3RyeS4KICAgICAgICA8L3Q+CiAgICAgICAgPHQ+CiAgICAgICAgICBBZGRp dGlvbmFsIGVycm9yIGNvZGVzIHVzZWQgdG9nZXRoZXIgd2l0aCBvdGhlciBwcm90b2NvbCBleHRl bnNpb25zIChpLmUuIGV4dGVuc2lvbiBncmFudAogICAgICAgICAgdHlwZXMsIGFjY2VzcyB0b2tl biB0eXBlcywgb3IgZXh0ZW5zaW9uIHBhcmFtZXRlcnMpIGFyZSByZWdpc3RlcmVkIHdpdGggYSBT cGVjaWZpY2F0aW9uCiAgICAgICAgICBSZXF1aXJlZCAoPHhyZWYgdGFyZ2V0PSdSRkM1MjI2JyAv PikgYWZ0ZXIgYSB0d28gd2VlayByZXZpZXcgcGVyaW9kIG9uIHRoZQogICAgICAgICAgW1RCRF1A aWV0Zi5vcmcgbWFpbGluZyBsaXN0LCBvbiB0aGUgYWR2aWNlIG9mIG9uZSBvciBtb3JlIERlc2ln bmF0ZWQgRXhwZXJ0cy4gSG93ZXZlciwgdG8KICAgICAgICAgIGFsbG93IGZvciB0aGUgYWxsb2Nh dGlvbiBvZiB2YWx1ZXMgcHJpb3IgdG8gcHVibGljYXRpb24sIHRoZSBEZXNpZ25hdGVkIEV4cGVy dChzKSBtYXkKICAgICAgICAgIGFwcHJvdmUgcmVnaXN0cmF0aW9uIG9uY2UgdGhleSBhcmUgc2F0 aXNmaWVkIHRoYXQgc3VjaCBhIHNwZWNpZmljYXRpb24gd2lsbCBiZSBwdWJsaXNoZWQuCiAgICAg ICAgPC90PgogICAgICAgIDx0PgogICAgICAgICAgUmVnaXN0cmF0aW9uIHJlcXVlc3RzIG11c3Qg YmUgc2VudCB0byB0aGUgW1RCRF1AaWV0Zi5vcmcgbWFpbGluZyBsaXN0IGZvciByZXZpZXcgYW5k CiAgICAgICAgICBjb21tZW50LCB3aXRoIGFuIGFwcHJvcHJpYXRlIHN1YmplY3QgKGUuZy4sICJS ZXF1ZXN0IGZvciBlcnJvciBjb2RlOiBleGFtcGxlIikuCiAgICAgICAgICBbWyBOb3RlIHRvIFJG Qy1FRElUT1I6IFRoZSBuYW1lIG9mIHRoZSBtYWlsaW5nIGxpc3Qgc2hvdWxkIGJlIGRldGVybWlu ZWQgaW4gY29uc3VsdGF0aW9uCiAgICAgICAgICB3aXRoIHRoZSBJRVNHIGFuZCBJQU5BLiBTdWdn ZXN0ZWQgbmFtZTogb2F1dGgtZXh0LXJldmlldy4gXV0KICAgICAgICA8L3Q+CiAgICAgICAgPHQ+ CiAgICAgICAgICBXaXRoaW4gdGhlIHJldmlldyBwZXJpb2QsIHRoZSBEZXNpZ25hdGVkIEV4cGVy dChzKSB3aWxsIGVpdGhlciBhcHByb3ZlIG9yCiAgICAgICAgICBkZW55IHRoZSByZWdpc3RyYXRp b24gcmVxdWVzdCwgY29tbXVuaWNhdGluZyB0aGlzIGRlY2lzaW9uIHRvIHRoZSByZXZpZXcgbGlz dCBhbmQgSUFOQS4KICAgICAgICAgIERlbmlhbHMgc2hvdWxkIGluY2x1ZGUgYW4gZXhwbGFuYXRp b24gYW5kLCBpZiBhcHBsaWNhYmxlLCBzdWdnZXN0aW9ucyBhcyB0byBob3cgdG8gbWFrZQogICAg ICAgICAgdGhlIHJlcXVlc3Qgc3VjY2Vzc2Z1bC4KICAgICAgICA8L3Q+CiAgICAgICAgPHQ+CiAg ICAgICAgICBJQU5BIG11c3Qgb25seSBhY2NlcHQgcmVnaXN0cnkgdXBkYXRlcyBmcm9tIHRoZSBE ZXNpZ25hdGVkIEV4cGVydChzKSwgYW5kIHNob3VsZCBkaXJlY3QKICAgICAgICAgIGFsbCByZXF1 ZXN0cyBmb3IgcmVnaXN0cmF0aW9uIHRvIHRoZSByZXZpZXcgbWFpbGluZyBsaXN0LgogICAgICAg IDwvdD4KCgogICAgICAgIDxzZWN0aW9uIHRpdGxlPSdSZWdpc3RyYXRpb24gVGVtcGxhdGUnPgog ICAgICAgICAgPHQ+CiAgICAgICAgICAgIDxsaXN0IHN0eWxlPSdoYW5naW5nJz4KICAgICAgICAg ICAgICA8dCBoYW5nVGV4dD0nRXJyb3IgbmFtZTonPgogICAgICAgICAgICAgICAgPHZzcGFjZSAv PgogICAgICAgICAgICAgICAgVGhlIG5hbWUgcmVxdWVzdGVkIChlLmcuLCAiZXhhbXBsZSIpLgog ICAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAgICA8dCBoYW5nVGV4dD0nRXJyb3IgdXNhZ2Ug bG9jYXRpb246Jz4KICAgICAgICAgICAgICAgIDx2c3BhY2UgLz4KICAgICAgICAgICAgICAgIFRo ZSBsb2NhdGlvbihzKSB3aGVyZSB0aGUgZXJyb3IgY2FuIGJlIHVzZWQuIFRoZSBwb3NzaWJsZSBs b2NhdGlvbnMgYXJlOgogICAgICAgICAgICAgICAgYXV0aG9yaXphdGlvbiBjb2RlIGdyYW50IGVy cm9yIHJlc3BvbnNlICg8eHJlZiB0YXJnZXQ9J2NvZGUtYXV0aHotZXJyb3InIC8+KSwKICAgICAg ICAgICAgICAgIGltcGxpY2l0IGdyYW50IGVycm9yIHJlc3BvbnNlICg8eHJlZiB0YXJnZXQ9J2lt cGxpY2l0LWF1dGh6LWVycm9yJyAvPiksCgkJdG9rZW4gZXJyb3IgcmVzcG9uc2UgKDx4cmVmIHRh cmdldD0ndG9rZW4tZXJyb3JzJyAvPiksIG9yCgkJcmVzb3VyY2UgYWNjZXNzIGVycm9yIHJlc3Bv bnNlICg8eHJlZiB0YXJnZXQ9J3Jlc291cmNlLWVycm9ycycgLz4pLgogICAgICAgICAgICAgIDwv dD4KICAgICAgICAgICAgICA8dCBoYW5nVGV4dD0nUmVsYXRlZCBwcm90b2NvbCBleHRlbnNpb246 Jz4KICAgICAgICAgICAgICAgIDx2c3BhY2UgLz4KICAgICAgICAgICAgICAgIFRoZSBuYW1lIG9m IHRoZSBleHRlbnNpb24gZ3JhbnQgdHlwZSwgYWNjZXNzIHRva2VuIHR5cGUsIG9yIGV4dGVuc2lv biBwYXJhbWV0ZXIsCiAgICAgICAgICAgICAgICB0aGUgZXJyb3IgY29kZSBpcyB1c2VkIGluIGNv bmp1bmN0aW9uIHdpdGguCiAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICAgIDx0IGhhbmdU ZXh0PSdDaGFuZ2UgY29udHJvbGxlcjonPgogICAgICAgICAgICAgICAgPHZzcGFjZSAvPgogICAg ICAgICAgICAgICAgRm9yIHN0YW5kYXJkcy10cmFjayBSRkNzLCBzdGF0ZSAiSUVURiIuIEZvciBv dGhlcnMsIGdpdmUgdGhlIG5hbWUgb2YgdGhlCiAgICAgICAgICAgICAgICByZXNwb25zaWJsZSBw YXJ0eS4gT3RoZXIgZGV0YWlscyAoZS5nLiwgcG9zdGFsIGFkZHJlc3MsIGUtbWFpbCBhZGRyZXNz LCBob21lIHBhZ2UKICAgICAgICAgICAgICAgIFVSSSkgbWF5IGFsc28gYmUgaW5jbHVkZWQuCiAg ICAgICAgICAgICAgPC90PgogICAgICAgICAgICAgIDx0IGhhbmdUZXh0PSdTcGVjaWZpY2F0aW9u IGRvY3VtZW50KHMpOic+CiAgICAgICAgICAgICAgICA8dnNwYWNlIC8+CiAgICAgICAgICAgICAg ICBSZWZlcmVuY2UgdG8gdGhlIGRvY3VtZW50IHRoYXQgc3BlY2lmaWVzIHRoZSBlcnJvciBjb2Rl LCBwcmVmZXJhYmx5IGluY2x1ZGluZyBhIFVSSQogICAgICAgICAgICAgICAgdGhhdCBjYW4gYmUg dXNlZCB0byByZXRyaWV2ZSBhIGNvcHkgb2YgdGhlIGRvY3VtZW50LiBBbiBpbmRpY2F0aW9uIG9m IHRoZSByZWxldmFudAogICAgICAgICAgICAgICAgc2VjdGlvbnMgbWF5IGFsc28gYmUgaW5jbHVk ZWQsIGJ1dCBpcyBub3QgcmVxdWlyZWQuCiAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICA8 L2xpc3Q+CiAgICAgICAgICA8L3Q+CiAgICAgICAgPC9zZWN0aW9uPgoKICAgICAgPC9zZWN0aW9u PgoKICAgIDwvc2VjdGlvbj4KCiAgPC9taWRkbGU+CgogIDxiYWNrPgoKICAgIDxyZWZlcmVuY2Vz IHRpdGxlPSdOb3JtYXRpdmUgUmVmZXJlbmNlcyc+CgogICAgICA8P3JmYyBpbmNsdWRlPSdodHRw Oi8veG1sLnJlc291cmNlLm9yZy9wdWJsaWMvcmZjL2JpYnhtbC9yZWZlcmVuY2UuUkZDLjIxMTku eG1sJyA/PgogICAgICA8P3JmYyBpbmNsdWRlPSdodHRwOi8veG1sLnJlc291cmNlLm9yZy9wdWJs aWMvcmZjL2JpYnhtbC9yZWZlcmVuY2UuUkZDLjIyNDYueG1sJyA/PgogICAgICA8P3JmYyBpbmNs dWRlPSdodHRwOi8veG1sLnJlc291cmNlLm9yZy9wdWJsaWMvcmZjL2JpYnhtbC9yZWZlcmVuY2Uu UkZDLjI2MTYueG1sJyA/PgogICAgICA8P3JmYyBpbmNsdWRlPSdodHRwOi8veG1sLnJlc291cmNl Lm9yZy9wdWJsaWMvcmZjL2JpYnhtbC9yZWZlcmVuY2UuUkZDLjI2MTcueG1sJyA/PgogICAgICA8 P3JmYyBpbmNsdWRlPSdodHRwOi8veG1sLnJlc291cmNlLm9yZy9wdWJsaWMvcmZjL2JpYnhtbC9y ZWZlcmVuY2UuUkZDLjI4MTgueG1sJyA/PgogICAgICA8P3JmYyBpbmNsdWRlPSdodHRwOi8veG1s LnJlc291cmNlLm9yZy9wdWJsaWMvcmZjL2JpYnhtbC9yZWZlcmVuY2UuUkZDLjM5ODYueG1sJyA/ PgogICAgICA8P3JmYyBpbmNsdWRlPSdodHRwOi8veG1sLnJlc291cmNlLm9yZy9wdWJsaWMvcmZj L2JpYnhtbC9yZWZlcmVuY2UuUkZDLjQ2MjcueG1sJyA/PgogICAgICA8P3JmYyBpbmNsdWRlPSdo dHRwOi8veG1sLnJlc291cmNlLm9yZy9wdWJsaWMvcmZjL2JpYnhtbC9yZWZlcmVuY2UuUkZDLjQ5 NDkueG1sJyA/PgogICAgICA8P3JmYyBpbmNsdWRlPSdodHRwOi8veG1sLnJlc291cmNlLm9yZy9w dWJsaWMvcmZjL2JpYnhtbC9yZWZlcmVuY2UuUkZDLjUyMjYueG1sJyA/PgogICAgICA8P3JmYyBp bmNsdWRlPSdodHRwOi8veG1sLnJlc291cmNlLm9yZy9wdWJsaWMvcmZjL2JpYnhtbC9yZWZlcmVu Y2UuUkZDLjUyMzQueG1sJyA/PgogICAgICA8P3JmYyBpbmNsdWRlPSdodHRwOi8veG1sLnJlc291 cmNlLm9yZy9wdWJsaWMvcmZjL2JpYnhtbC9yZWZlcmVuY2UuUkZDLjUyNDYueG1sJyA/PgogICAg ICA8P3JmYyBpbmNsdWRlPSdodHRwOi8veG1sLnJlc291cmNlLm9yZy9wdWJsaWMvcmZjL2JpYnht bC9yZWZlcmVuY2UuUkZDLjYxMjUueG1sJyA/PgogICAgICA8P3JmYyBpbmNsdWRlPSdodHRwOi8v eG1sLnJlc291cmNlLm9yZy9wdWJsaWMvcmZjL2JpYnhtbDQvcmVmZXJlbmNlLlczQy5SRUMtaHRt bDQwMS0xOTk5MTIyNC54bWwnID8+CgogICAgICA8cmVmZXJlbmNlIGFuY2hvcj0iVVNBU0NJSSI+ Cgk8ZnJvbnQ+CgkgIDx0aXRsZT5Db2RlZCBDaGFyYWN0ZXIgU2V0IC0tIDctYml0IEFtZXJpY2Fu IFN0YW5kYXJkIENvZGUgZm9yIEluZm9ybWF0aW9uIEludGVyY2hhbmdlPC90aXRsZT4KCSAgPGF1 dGhvcj4KCSAgICA8b3JnYW5pemF0aW9uPkFtZXJpY2FuIE5hdGlvbmFsIFN0YW5kYXJkcyBJbnN0 aXR1dGU8L29yZ2FuaXphdGlvbj4KCSAgPC9hdXRob3I+CgkgIDxkYXRlIHllYXI9IjE5ODYiLz4K CTwvZnJvbnQ+Cgk8c2VyaWVzSW5mbyBuYW1lPSJBTlNJIiB2YWx1ZT0iWDMuNCIvPgogICAgICA8 L3JlZmVyZW5jZT4KCiAgICA8L3JlZmVyZW5jZXM+CgogICAgPHJlZmVyZW5jZXMgdGl0bGU9J0lu Zm9ybWF0aXZlIFJlZmVyZW5jZXMnPgoKICAgICAgPD9yZmMgaW5jbHVkZT0naHR0cDovL3htbC5y ZXNvdXJjZS5vcmcvcHVibGljL3JmYy9iaWJ4bWwvcmVmZXJlbmNlLlJGQy41ODQ5LnhtbCcgPz4K ICAgICAgPD9yZmMgaW5jbHVkZT0naHR0cDovL3htbC5yZXNvdXJjZS5vcmcvcHVibGljL3JmYy9i aWJ4bWwzL3JlZmVyZW5jZS5JLUQuZHJhZnQtaWV0Zi1vYXV0aC12Mi1iZWFyZXItMTkueG1sJyA/ PgogICAgICA8P3JmYyBpbmNsdWRlPSdodHRwOi8veG1sLnJlc291cmNlLm9yZy9wdWJsaWMvcmZj L2JpYnhtbDMvcmVmZXJlbmNlLkktRC5kcmFmdC1pZXRmLW9hdXRoLXNhbWwyLWJlYXJlci0xMi54 bWwnID8+CiAgICAgIDw/cmZjIGluY2x1ZGU9J2h0dHA6Ly94bWwucmVzb3VyY2Uub3JnL3B1Ymxp Yy9yZmMvYmlieG1sMy9yZWZlcmVuY2UuSS1ELmRyYWZ0LWlldGYtb2F1dGgtdjItaHR0cC1tYWMt MDEueG1sJyA/PgogICAgICA8P3JmYyBpbmNsdWRlPSdodHRwOi8veG1sLnJlc291cmNlLm9yZy9w dWJsaWMvcmZjL2JpYnhtbDMvcmVmZXJlbmNlLkktRC5kcmFmdC1pZXRmLW9hdXRoLXYyLXRocmVh dG1vZGVsLTAyLnhtbCcgPz4KCiAgICAgIDw/cmZjIGluY2x1ZGU9J2h0dHA6Ly94bWwucmVzb3Vy Y2Uub3JnL3B1YmxpYy9yZmMvYmlieG1sMy9yZWZlcmVuY2UuSS1ELmRyYWZ0LWlldGYtaHR0cGJp cy1wNy1hdXRoLTE5LnhtbCc/PgoKICAgICAgPHJlZmVyZW5jZSBhbmNob3I9IkktRC5kcmFmdC1o YXJkdC1vYXV0aC0wMSI+CiAgICAgICAgPGZyb250PgogICAgICAgICAgPHRpdGxlPk9BdXRoIFdl YiBSZXNvdXJjZSBBdXRob3JpemF0aW9uIFByb2ZpbGVzPC90aXRsZT4KICAgICAgICAgIDxhdXRo b3IgaW5pdGlhbHM9IkQiIHN1cm5hbWU9IkhhcmR0IiBmdWxsbmFtZT0iRGljayBIYXJkdCIgcm9s ZT0iZWRpdG9yIiAvPgogICAgICAgICAgPGF1dGhvciBpbml0aWFscz0iQSIgc3VybmFtZT0iVG9t IiBmdWxsbmFtZT0iQWxsZW4gVG9tIiAvPgogICAgICAgICAgPGF1dGhvciBpbml0aWFscz0iQiIg c3VybmFtZT0iRWF0b24iIGZ1bGxuYW1lPSJCcmlhbiBFYXRvbiIgLz4KICAgICAgICAgIDxhdXRo b3IgaW5pdGlhbHM9IlkiIHN1cm5hbWU9IkdvbGFuZCIgZnVsbG5hbWU9Illhcm9uIEdvbGFuZCIg Lz4KICAgICAgICAgIDxkYXRlIG1vbnRoPSJKYW51YXJ5IiBkYXk9IjE1IiB5ZWFyPSIyMDEwIiAv PgogICAgICAgIDwvZnJvbnQ+CiAgICAgICAgPGZvcm1hdCB0YXJnZXQ9Imh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWhhcmR0LW9hdXRoLTAxIiB0eXBlPSJIVE1MIiAvPgogICAgICA8 L3JlZmVyZW5jZT4KCiAgICA8L3JlZmVyZW5jZXM+CgogICAgPHNlY3Rpb24gdGl0bGU9IkF1Z21l bnRlZCBCYWNrdXMtTmF1ciBGb3JtIChBQk5GKSBTeW50YXgiPgogICAgICA8dD4KCVRoaXMgc2Vj dGlvbiBwcm92aWRlcyBBdWdtZW50ZWQgQmFja3VzLU5hdXIgRm9ybSAoQUJORikgc3ludGF4Cglk ZXNjcmlwdGlvbnMgZm9yIHRoZSBlbGVtZW50cyBkZWZpbmVkIGluIHRoaXMgc3BlY2lmaWNhdGlv bgoJdXNpbmcgdGhlIG5vdGF0aW9uIG9mIDx4cmVmIHRhcmdldD0nUkZDNTIzNCcgLz4uCglFbGVt ZW50cyBhcmUgcHJlc2VudGVkIGluIHRoZSBvcmRlciBmaXJzdCBkZWZpbmVkLgogICAgICA8L3Q+ CiAgICAgIDx0PgoJU29tZSBvZiB0aGUgZGVmaW5pdGlvbnMgdGhhdCBmb2xsb3cgdXNlIHRoZQoJ PHNwYW54IHN0eWxlPSd2ZXJiJz5VUkktcmVmZXJlbmNlPC9zcGFueD4KCWRlZmluaXRpb24gZnJv bSA8eHJlZiB0YXJnZXQ9IlJGQzM5ODYiLz4uCiAgICAgIDwvdD4KCiAgICAgIDxmaWd1cmU+Cgk8 cHJlYW1ibGU+CgkgIFNvbWUgb2YgdGhlIGRlZmluaXRpb25zIHRoYXQgZm9sbG93IHVzZSB0aGVz ZSBjb21tb24gZGVmaW5pdGlvbnM6Cgk8L3ByZWFtYmxlPgoJPGFydHdvcms+PCFbQ0RBVEFbClZT Q0hBUiAgICAgPSAlMjAtN0UKTlFDSEFSICAgICA9ICV4MjEgLyAleDIzLTVCIC8gJXg1RC03RQpO UVNDSEFSICAgID0gJXgyMC0yMSAvICV4MjMtNUIgLyAleDVELTdFCl1dPjwvYXJ0d29yaz4KICAg ICAgPC9maWd1cmU+CgogICAgICA8c2VjdGlvbiB0aXRsZT0nImNsaWVudF9pZCIgU3ludGF4Jz4K Cgk8ZmlndXJlPgoJICA8cHJlYW1ibGU+CgkgICAgVGhlIDxzcGFueCBzdHlsZT0ndmVyYic+Y2xp ZW50X2lkPC9zcGFueD4gZWxlbWVudCBpcyBkZWZpbmVkIGluCgkgICAgPHhyZWYgdGFyZ2V0PSJj bGllbnQtcGFzc3dvcmQiLz46CgkgIDwvcHJlYW1ibGU+CgkgIDxhcnR3b3JrPjwhW0NEQVRBWwpj bGllbnQtaWQgICAgID0gKlZTQ0hBUgpdXT48L2FydHdvcms+Cgk8L2ZpZ3VyZT4KCTx0PgoJICAo VGhpcyBtYXRjaGVzIHRoZSA8c3Bhbnggc3R5bGU9J3ZlcmInPnVzZXJpZDwvc3Bhbng+IGRlZmlu aXRpb24gaW4gdGhlCgkgIEhUVFAgQmFzaWMgQXV0aGVudGljYXRpb24gU2NoZW1lIDx4cmVmIHRh cmdldD0nUkZDMjYxNycvPi4pCgk8L3Q+CiAgICAgIDwvc2VjdGlvbj4KCiAgICAgIDxzZWN0aW9u IHRpdGxlPSciY2xpZW50X3NlY3JldCIgU3ludGF4Jz4KCgk8ZmlndXJlPgoJICA8cHJlYW1ibGU+ CgkgICAgVGhlIDxzcGFueCBzdHlsZT0ndmVyYic+Y2xpZW50X3NlY3JldDwvc3Bhbng+IGVsZW1l bnQgaXMgZGVmaW5lZCBpbgoJICAgIDx4cmVmIHRhcmdldD0iY2xpZW50LXBhc3N3b3JkIi8+OgoJ ICA8L3ByZWFtYmxlPgoJICA8YXJ0d29yaz48IVtDREFUQVsKY2xpZW50LXNlY3JldCA9ICpWU0NI QVIKXV0+PC9hcnR3b3JrPgoJPC9maWd1cmU+Cgk8dD4KCSAgKFRoaXMgbWF0Y2hlcyB0aGUgPHNw YW54IHN0eWxlPSd2ZXJiJz5wYXNzd29yZDwvc3Bhbng+IGRlZmluaXRpb24gaW4gdGhlCgkgIEhU VFAgQmFzaWMgQXV0aGVudGljYXRpb24gU2NoZW1lIDx4cmVmIHRhcmdldD0nUkZDMjYxNycvPi4p Cgk8L3Q+CiAgICAgIDwvc2VjdGlvbj4KCiAgICAgIDxzZWN0aW9uIHRpdGxlPScicmVzcG9uc2Vf dHlwZSIgU3ludGF4Jz4KCgk8ZmlndXJlPgoJICA8cHJlYW1ibGU+CgkgICAgVGhlIDxzcGFueCBz dHlsZT0ndmVyYic+cmVzcG9uc2VfdHlwZTwvc3Bhbng+IGVsZW1lbnQgaXMgZGVmaW5lZCBpbgoJ ICAgIDx4cmVmIHRhcmdldD0icmVzcG9uc2UtdHlwZSIvPiBhbmQKCSAgICA8eHJlZiB0YXJnZXQ9 InJlc3BvbnNlLXR5cGUtZXh0Ii8+OgoJICA8L3ByZWFtYmxlPgoJICA8YXJ0d29yaz48IVtDREFU QVsKcmVzcG9uc2UtdHlwZSA9IHJlc3BvbnNlLW5hbWUgKiggU1AgcmVzcG9uc2UtbmFtZSApCnJl c3BvbnNlLW5hbWUgPSAxKnJlc3BvbnNlLWNoYXIKcmVzcG9uc2UtY2hhciA9ICJfIiAvIERJR0lU IC8gQUxQSEEKXV0+PC9hcnR3b3JrPgoJPC9maWd1cmU+CiAgICAgIDwvc2VjdGlvbj4KCiAgICAg IDxzZWN0aW9uIHRpdGxlPScic2NvcGUiIFN5bnRheCc+CgoJPGZpZ3VyZT4KCSAgPHByZWFtYmxl PgoJICAgIFRoZSA8c3Bhbnggc3R5bGU9J3ZlcmInPnNjb3BlPC9zcGFueD4gZWxlbWVudCBpcyBk ZWZpbmVkIGluCgkgICAgPHhyZWYgdGFyZ2V0PSJzY29wZSIvPjoKCSAgPC9wcmVhbWJsZT4KCSAg PGFydHdvcms+PCFbQ0RBVEFbCnNjb3BlICAgICAgID0gc2NvcGUtdG9rZW4gKiggU1Agc2NvcGUt dG9rZW4gKQpzY29wZS10b2tlbiA9IDEqTlFDSEFSCl1dPjwvYXJ0d29yaz4KCTwvZmlndXJlPgog ICAgICA8L3NlY3Rpb24+CgogICAgICA8c2VjdGlvbiB0aXRsZT0nInN0YXRlIiBTeW50YXgnPgoK CTxmaWd1cmU+CgkgIDxwcmVhbWJsZT4KCSAgICBUaGUgPHNwYW54IHN0eWxlPSd2ZXJiJz5zdGF0 ZTwvc3Bhbng+IGVsZW1lbnQgaXMgZGVmaW5lZCBpbgoJICAgIDx4cmVmIHRhcmdldD0iY29kZS1h dXRoei1yZXEiLz4sCgkgICAgPHhyZWYgdGFyZ2V0PSJjb2RlLWF1dGh6LXJlc3AiLz4sCgkgICAg PHhyZWYgdGFyZ2V0PSJjb2RlLWF1dGh6LWVycm9yIi8+LAoJICAgIDx4cmVmIHRhcmdldD0iaW1w bGljaXQtYXV0aHotcmVxIi8+LAoJICAgIDx4cmVmIHRhcmdldD0iaW1wbGljaXQtYXV0aHotcmVz cCIvPiwgYW5kCgkgICAgPHhyZWYgdGFyZ2V0PSJpbXBsaWNpdC1hdXRoei1lcnJvciIvPjoKCSAg PC9wcmVhbWJsZT4KCSAgPGFydHdvcms+PCFbQ0RBVEFbCnN0YXRlICAgICAgPSAxKlZTQ0hBUgpd XT48L2FydHdvcms+Cgk8L2ZpZ3VyZT4KICAgICAgPC9zZWN0aW9uPgoKICAgICAgPHNlY3Rpb24g dGl0bGU9JyJyZWRpcmVjdF91cmkiIFN5bnRheCc+CgoJPGZpZ3VyZT4KCSAgPHByZWFtYmxlPgoJ ICAgIFRoZSA8c3Bhbnggc3R5bGU9J3ZlcmInPnJlZGlyZWN0X3VyaTwvc3Bhbng+IGVsZW1lbnQg aXMgZGVmaW5lZCBpbgoJICAgIDx4cmVmIHRhcmdldD0iY29kZS1hdXRoei1yZXEiLz4sCgkgICAg PHhyZWYgdGFyZ2V0PSJ0b2tlbi1yZXEiLz4sIGFuZAoJICAgIDx4cmVmIHRhcmdldD0iaW1wbGlj aXQtYXV0aHotcmVxIi8+OgoJICA8L3ByZWFtYmxlPgoJICA8YXJ0d29yaz48IVtDREFUQVsKcmVk aXJlY3QtdXJpICAgICAgPSBVUkktcmVmZXJlbmNlCl1dPjwvYXJ0d29yaz4KCTwvZmlndXJlPgog ICAgICA8L3NlY3Rpb24+CgogICAgICA8c2VjdGlvbiB0aXRsZT0nImVycm9yIiBTeW50YXgnPgoK CTxmaWd1cmU+CgkgIDxwcmVhbWJsZT4KCSAgICBUaGUgPHNwYW54IHN0eWxlPSd2ZXJiJz5lcnJv cjwvc3Bhbng+IGVsZW1lbnQgaXMgZGVmaW5lZCBpbgoJICAgIDx4cmVmIHRhcmdldD0iY29kZS1h dXRoei1lcnJvciIvPiwKCSAgICA8eHJlZiB0YXJnZXQ9J2ltcGxpY2l0LWF1dGh6LWVycm9yJy8+ LAoJICAgIDx4cmVmIHRhcmdldD0ndG9rZW4tZXJyb3JzJy8+LAoJICAgIDx4cmVmIHRhcmdldD0n cmVzb3VyY2UtZXJyb3JzJy8+LCBhbmQKCSAgICA8eHJlZiB0YXJnZXQ9Im5ldy1lcnJvcnMiLz46 CgkgIDwvcHJlYW1ibGU+CgkgIDxhcnR3b3JrPjwhW0NEQVRBWwplcnJvciAgICAgICAgICAgICA9 IDEqTlFTQ0hBUgpdXT48L2FydHdvcms+Cgk8L2ZpZ3VyZT4KICAgICAgPC9zZWN0aW9uPgoKICAg ICAgPHNlY3Rpb24gdGl0bGU9JyJlcnJvcl9kZXNjcmlwdGlvbiIgU3ludGF4Jz4KCgk8ZmlndXJl PgoJICA8cHJlYW1ibGU+CgkgICAgVGhlIDxzcGFueCBzdHlsZT0ndmVyYic+ZXJyb3JfZGVzY3Jp cHRpb248L3NwYW54PiBlbGVtZW50IGlzIGRlZmluZWQgaW4KCSAgICA8eHJlZiB0YXJnZXQ9ImNv ZGUtYXV0aHotZXJyb3IiLz4sCgkgICAgPHhyZWYgdGFyZ2V0PSdpbXBsaWNpdC1hdXRoei1lcnJv cicvPiwKCSAgICA8eHJlZiB0YXJnZXQ9J3Rva2VuLWVycm9ycycvPiwgYW5kCgkgICAgPHhyZWYg dGFyZ2V0PSdyZXNvdXJjZS1lcnJvcnMnLz46CgkgIDwvcHJlYW1ibGU+CgkgIDxhcnR3b3JrPjwh W0NEQVRBWwplcnJvci1kZXNjcmlwdGlvbiA9IDEqTlFTQ0hBUgpdXT48L2FydHdvcms+Cgk8L2Zp Z3VyZT4KICAgICAgPC9zZWN0aW9uPgoKICAgICAgPHNlY3Rpb24gdGl0bGU9JyJlcnJvcl91cmki IFN5bnRheCc+CgoJPGZpZ3VyZT4KCSAgPHByZWFtYmxlPgoJICAgIFRoZSA8c3Bhbnggc3R5bGU9 J3ZlcmInPmVycm9yX3VyaTwvc3Bhbng+IGVsZW1lbnQgaXMgZGVmaW5lZCBpbgoJICAgIDx4cmVm IHRhcmdldD0iY29kZS1hdXRoei1lcnJvciIvPiwKCSAgICA8eHJlZiB0YXJnZXQ9J2ltcGxpY2l0 LWF1dGh6LWVycm9yJy8+LAoJICAgIDx4cmVmIHRhcmdldD0ndG9rZW4tZXJyb3JzJy8+LCBhbmQK CSAgICA8eHJlZiB0YXJnZXQ9J3Jlc291cmNlLWVycm9ycycvPjoKCSAgPC9wcmVhbWJsZT4KCSAg PGFydHdvcms+PCFbQ0RBVEFbCmVycm9yLXVyaSAgICAgICAgID0gVVJJLXJlZmVyZW5jZQpdXT48 L2FydHdvcms+Cgk8L2ZpZ3VyZT4KICAgICAgPC9zZWN0aW9uPgoKICAgICAgPHNlY3Rpb24gdGl0 bGU9JyJncmFudF90eXBlIiBTeW50YXgnPgoKCTxmaWd1cmU+CgkgIDxwcmVhbWJsZT4KCSAgICBU aGUgPHNwYW54IHN0eWxlPSd2ZXJiJz5ncmFudF90eXBlPC9zcGFueD4gZWxlbWVudCBpcyBkZWZp bmVkIGluCgkgICAgPHhyZWYgdGFyZ2V0PSJ0b2tlbi1yZXEiLz4sCgkgICAgPHhyZWYgdGFyZ2V0 PSdwYXNzd29yZC10b2stcmVxJy8+LAoJICAgIDx4cmVmIHRhcmdldD0nY2xpZW50LXJlcScvPiwK CSAgICA8eHJlZiB0YXJnZXQ9InRva2VuLXJlZnJlc2giLz4sIGFuZAoJICAgIDx4cmVmIHRhcmdl dD0nZXh0LWdyYW50Jy8+OgoJICA8L3ByZWFtYmxlPgoJICA8YXJ0d29yaz48IVtDREFUQVsKZ3Jh bnQtdHlwZSA9IGdyYW50LW5hbWUgLyBVUkktcmVmZXJlbmNlCmdyYW50LW5hbWUgPSAxKm5hbWUt Y2hhcgpuYW1lLWNoYXIgID0gIi0iIC8gIi4iIC8gIl8iIC8gRElHSVQgLyBBTFBIQQpdXT48L2Fy dHdvcms+Cgk8L2ZpZ3VyZT4KICAgICAgPC9zZWN0aW9uPgoKICAgICAgPHNlY3Rpb24gdGl0bGU9 JyJjb2RlIiBTeW50YXgnPgoKCTxmaWd1cmU+CgkgIDxwcmVhbWJsZT4KCSAgICBUaGUgPHNwYW54 IHN0eWxlPSd2ZXJiJz5jb2RlPC9zcGFueD4gZWxlbWVudCBpcyBkZWZpbmVkIGluCgkgICAgPHhy ZWYgdGFyZ2V0PSJ0b2tlbi1yZXEiLz46CgkgIDwvcHJlYW1ibGU+CgkgIDxhcnR3b3JrPjwhW0NE QVRBWwpjb2RlICAgICAgID0gMSpWU0NIQVIKXV0+PC9hcnR3b3JrPgoJPC9maWd1cmU+CiAgICAg IDwvc2VjdGlvbj4KCiAgICAgIDxzZWN0aW9uIHRpdGxlPSciYWNjZXNzX3Rva2VuIiBTeW50YXgn PgoKCTxmaWd1cmU+CgkgIDxwcmVhbWJsZT4KCSAgICBUaGUgPHNwYW54IHN0eWxlPSd2ZXJiJz5h Y2Nlc3NfdG9rZW48L3NwYW54PiBlbGVtZW50IGlzIGRlZmluZWQgaW4KCSAgICA8eHJlZiB0YXJn ZXQ9ImltcGxpY2l0LWF1dGh6LXJlc3AiLz4gYW5kCgkgICAgPHhyZWYgdGFyZ2V0PSJ0b2tlbi1y ZXNwb25zZSIvPjoKCSAgPC9wcmVhbWJsZT4KCSAgPGFydHdvcms+PCFbQ0RBVEFbCmFjY2Vzcy10 b2tlbiA9IDEqVlNDSEFSCl1dPjwvYXJ0d29yaz4KCTwvZmlndXJlPgogICAgICA8L3NlY3Rpb24+ CgogICAgICA8c2VjdGlvbiB0aXRsZT0nInRva2VuX3R5cGUiIFN5bnRheCc+CgoJPGZpZ3VyZT4K CSAgPHByZWFtYmxlPgoJICAgIFRoZSA8c3Bhbnggc3R5bGU9J3ZlcmInPnRva2VuX3R5cGU8L3Nw YW54PiBlbGVtZW50IGlzIGRlZmluZWQgaW4KCSAgICA8eHJlZiB0YXJnZXQ9ImltcGxpY2l0LWF1 dGh6LXJlc3AiLz4sCgkgICAgPHhyZWYgdGFyZ2V0PSJ0b2tlbi1yZXNwb25zZSIvPiwgYW5kCgkg ICAgPHhyZWYgdGFyZ2V0PSJuZXctdHlwZXMiLz46CgkgIDwvcHJlYW1ibGU+CgkgIDxhcnR3b3Jr PjwhW0NEQVRBWwp0b2tlbi10eXBlID0gdHlwZS1uYW1lIC8gVVJJLXJlZmVyZW5jZQp0eXBlLW5h bWUgID0gMSpuYW1lLWNoYXIKbmFtZS1jaGFyICA9ICItIiAvICIuIiAvICJfIiAvIERJR0lUIC8g QUxQSEEKXV0+PC9hcnR3b3JrPgoJPC9maWd1cmU+CiAgICAgIDwvc2VjdGlvbj4KCiAgICAgIDxz ZWN0aW9uIHRpdGxlPSciZXhwaXJlc19pbiIgU3ludGF4Jz4KCgk8ZmlndXJlPgoJICA8cHJlYW1i bGU+CgkgICAgVGhlIDxzcGFueCBzdHlsZT0ndmVyYic+ZXhwaXJlc19pbjwvc3Bhbng+IGVsZW1l bnQgaXMgZGVmaW5lZCBpbgoJICAgIDx4cmVmIHRhcmdldD0iaW1wbGljaXQtYXV0aHotcmVzcCIv PiBhbmQKCSAgICA8eHJlZiB0YXJnZXQ9InRva2VuLXJlc3BvbnNlIi8+OgoJICA8L3ByZWFtYmxl PgoJICA8YXJ0d29yaz48IVtDREFUQVsKZXhwaXJlcy1pbiA9IDEqRElHSVQKXV0+PC9hcnR3b3Jr PgoJPC9maWd1cmU+CiAgICAgIDwvc2VjdGlvbj4KCiAgICAgIDxzZWN0aW9uIHRpdGxlPScidXNl cm5hbWUiIFN5bnRheCc+CgoJPGZpZ3VyZT4KCSAgPHByZWFtYmxlPgoJICAgIFRoZSA8c3Bhbngg c3R5bGU9J3ZlcmInPnVzZXJuYW1lPC9zcGFueD4gZWxlbWVudCBpcyBkZWZpbmVkIGluCgkgICAg PHhyZWYgdGFyZ2V0PSJwYXNzd29yZC10b2stcmVxIi8+OgoJICA8L3ByZWFtYmxlPgoJICA8YXJ0 d29yaz48IVtDREFUQVsKdXNlcm5hbWUgPSAqKCAleDIwLTM5IC8gJXgzQi03RSApCl1dPjwvYXJ0 d29yaz4KCTwvZmlndXJlPgoJPHQ+CgkgIChUaGlzIGFsbG93ZWQgY2hhcmFjdGVyIHNldCBpcyBW U0NIQVIgZXhjbHVkaW5nICI6Ii4KCSAgVGhpcyBpcyBjb21wYXRpYmxlIHdpdGggdGhlIDxzcGFu eCBzdHlsZT0ndmVyYic+dXNlcmlkPC9zcGFueD4KCSAgZGVmaW5pdGlvbiBpbiB0aGUKCSAgSFRU UCBCYXNpYyBBdXRoZW50aWNhdGlvbiBTY2hlbWUgPHhyZWYgdGFyZ2V0PSdSRkMyNjE3Jy8+LikK CTwvdD4KICAgICAgPC9zZWN0aW9uPgoKICAgICAgPHNlY3Rpb24gdGl0bGU9JyJwYXNzd29yZCIg U3ludGF4Jz4KCgk8ZmlndXJlPgoJICA8cHJlYW1ibGU+CgkgICAgVGhlIDxzcGFueCBzdHlsZT0n dmVyYic+cGFzc3dvcmQ8L3NwYW54PiBlbGVtZW50IGlzIGRlZmluZWQgaW4KCSAgICA8eHJlZiB0 YXJnZXQ9InBhc3N3b3JkLXRvay1yZXEiLz46CgkgIDwvcHJlYW1ibGU+CgkgIDxhcnR3b3JrPjwh W0NEQVRBWwpwYXNzd29yZCA9ICpWU0NIQVIKXV0+PC9hcnR3b3JrPgoJPC9maWd1cmU+Cgk8dD4K CSAgKFRoaXMgbWF0Y2hlcyB0aGUgPHNwYW54IHN0eWxlPSd2ZXJiJz5wYXNzd29yZDwvc3Bhbng+ IGRlZmluaXRpb24gaW4gdGhlCgkgIEhUVFAgQmFzaWMgQXV0aGVudGljYXRpb24gU2NoZW1lIDx4 cmVmIHRhcmdldD0nUkZDMjYxNycvPi4pCgk8L3Q+CiAgICAgIDwvc2VjdGlvbj4KCiAgICAgIDxz ZWN0aW9uIHRpdGxlPScicmVmcmVzaF90b2tlbiIgU3ludGF4Jz4KCgk8ZmlndXJlPgoJICA8cHJl YW1ibGU+CgkgICAgVGhlIDxzcGFueCBzdHlsZT0ndmVyYic+cmVmcmVzaF90b2tlbjwvc3Bhbng+ IGVsZW1lbnQgaXMgZGVmaW5lZCBpbgoJICAgIDx4cmVmIHRhcmdldD0idG9rZW4tcmVzcG9uc2Ui Lz4gYW5kCgkgICAgPHhyZWYgdGFyZ2V0PSJ0b2tlbi1yZWZyZXNoIi8+OgoJICA8L3ByZWFtYmxl PgoJICA8YXJ0d29yaz48IVtDREFUQVsKcmVmcmVzaC10b2tlbiA9IDEqVlNDSEFSCl1dPjwvYXJ0 d29yaz4KCTwvZmlndXJlPgogICAgICA8L3NlY3Rpb24+CgogICAgICA8c2VjdGlvbiB0aXRsZT0n RW5kcG9pbnQgUGFyYW1ldGVyIFN5bnRheCc+CgoJPGZpZ3VyZT4KCSAgPHByZWFtYmxlPgoJICAg IFRoZSBzeW50YXggZm9yIG5ldyBlbmRwb2ludCBwYXJhbWV0ZXJzIGlzIGRlZmluZWQgaW4KCSAg ICA8eHJlZiB0YXJnZXQ9ImVuZHBvaW50LXBhcmFtcyIvPjoKCSAgPC9wcmVhbWJsZT4KCSAgPGFy dHdvcms+PCFbQ0RBVEFbCnBhcmFtLW5hbWUgPSAxKm5hbWUtY2hhcgpuYW1lLWNoYXIgID0gIi0i IC8gIi4iIC8gIl8iIC8gRElHSVQgLyBBTFBIQQpdXT48L2FydHdvcms+Cgk8L2ZpZ3VyZT4KICAg ICAgPC9zZWN0aW9uPgoKICAgIDwvc2VjdGlvbj4KCiAgICA8c2VjdGlvbiB0aXRsZT0nQWNrbm93 bGVkZ2VtZW50cyc+CiAgICAgIDx0PgogICAgICAgIFRoZSBpbml0aWFsIE9BdXRoIDIuMCBwcm90 b2NvbCBzcGVjaWZpY2F0aW9uIHdhcyBlZGl0ZWQgYnkgRGF2aWQgUmVjb3Jkb24sIGJhc2VkIG9u IHR3bwogICAgICAgIHByZXZpb3VzIHB1YmxpY2F0aW9uczogdGhlIE9BdXRoIDEuMCBjb21tdW5p dHkgc3BlY2lmaWNhdGlvbiA8eHJlZiB0YXJnZXQ9J1JGQzU4NDknIC8+LCBhbmQKICAgICAgICBP QXV0aCBXUkFQIChPQXV0aCBXZWIgUmVzb3VyY2UgQXV0aG9yaXphdGlvbiBQcm9maWxlcykKICAg ICAgICA8eHJlZiB0YXJnZXQ9J0ktRC5kcmFmdC1oYXJkdC1vYXV0aC0wMScgLz4uIFRoZSBTZWN1 cml0eSBDb25zaWRlcmF0aW9ucyBzZWN0aW9uIHdhcyBkcmFmdGVkCiAgICAgICAgYnkgVG9yc3Rl biBMb2RkZXJzdGVkdCwgTWFyayBNY0dsb2luLCBQaGlsIEh1bnQsIGFuZCBBbnRob255IE5hZGFs aW4uCglUaGUgQUJORiBzZWN0aW9uIHdhcyBkcmFmdGVkIGJ5IE1pY2hhZWwgQi4gSm9uZXMuCiAg ICAgIDwvdD4KICAgICAgPHQ+CiAgICAgICAgVGhlIE9BdXRoIDEuMCBjb21tdW5pdHkgc3BlY2lm aWNhdGlvbiB3YXMgZWRpdGVkIGJ5IEVyYW4gSGFtbWVyIGFuZCBhdXRob3JlZCBieQogICAgICAg IE1hcmsgQXR3b29kLCBEaXJrIEJhbGZhbnosIERhcnJlbiBCb3VuZHMsIFJpY2hhcmQgTS4gQ29u bGFuLCBCbGFpbmUgQ29vaywgTGVhaCBDdWx2ZXIsCiAgICAgICAgQnJlbm8gZGUgTWVkZWlyb3Ms IEJyaWFuIEVhdG9uLCBLZWxsYW4gRWxsaW90dC1NY0NyZWEsIExhcnJ5IEhhbGZmLCBFcmFuIEhh bW1lciwKICAgICAgICBCZW4gTGF1cmllLCBDaHJpcyBNZXNzaW5hLCBKb2huIFBhbnplciwgU2Ft IFF1aWdsZXksIERhdmlkIFJlY29yZG9uLCBFcmFuIFNhbmRsZXIsCiAgICAgICAgSm9uYXRoYW4g U2VyZ2VudCwgVG9kZCBTaWVsaW5nLCBCcmlhbiBTbGVzaW5za3ksIGFuZCBBbmR5IFNtaXRoLgog ICAgICA8L3Q+CiAgICAgIDx0PgogICAgICAgIFRoZSBPQXV0aCBXUkFQIHNwZWNpZmljYXRpb24g d2FzIGVkaXRlZCBieSBEaWNrIEhhcmR0IGFuZCBhdXRob3JlZCBieSBCcmlhbiBFYXRvbiwKICAg ICAgICBZYXJvbiBZLiBHb2xhbmQsIERpY2sgSGFyZHQsIGFuZCBBbGxlbiBUb20uCiAgICAgIDwv dD4KICAgICAgPHQ+CiAgICAgICAgVGhpcyBzcGVjaWZpY2F0aW9uIGlzIHRoZSB3b3JrIG9mIHRo ZSBPQXV0aCBXb3JraW5nIEdyb3VwIHdoaWNoIGluY2x1ZGVzIGRvemVucyBvZiBhY3RpdmUKICAg ICAgICBhbmQgZGVkaWNhdGVkIHBhcnRpY2lwYW50cy4gSW4gcGFydGljdWxhciwgdGhlIGZvbGxv d2luZyBpbmRpdmlkdWFscyBjb250cmlidXRlZCBpZGVhcywKICAgICAgICBmZWVkYmFjaywgYW5k IHdvcmRpbmcgd2hpY2ggc2hhcGVkIGFuZCBmb3JtZWQgdGhlIGZpbmFsIHNwZWNpZmljYXRpb246 CiAgICAgIDwvdD4KICAgICAgPHQ+CiAgICAgICAgTWljaGFlbCBBZGFtcywgQW1hbmRhIEFuZ2Fu ZXMsIEFuZHJldyBBcm5vdHQsIERpcmsgQmFsZmFueiwgQWlkZW4gQmVsbCwgSm9obiBCcmFkbGV5 LCBCcmlhbiBDYW1wYmVsbCwKICAgICAgICBTY290dCBDYW50b3IsIE1hcmNvcyBDYWNlcmVzLCBC bGFpbmUgQ29vaywgUm9nZXIgQ3JldywgQnJpYW4gRWF0b24sIFdlc2xleSBFZGR5LCBMZWFoIEN1 bHZlciwKICAgICAgICBCaWxsIGRlIGhPcmEsIEFuZHJlIERlTWFycmUsIEJyaWFuIEVhdG9uLCBX b2x0ZXIgRWxkZXJpbmcsIEJyaWFuIEVsbGluLCBJZ29yIEZheW5iZXJnLAogICAgICAgIEdlb3Jn ZSBGbGV0Y2hlciwgVGltIEZyZWVtYW4sIEx1Y2EgRnJvc2luaSwgRXZhbiBHaWxiZXJ0LCBZYXJv biBZLiBHb2xhbmQsIEJyZW50IEdvbGRtYW4sCiAgICAgICAgS3Jpc3RvZmZlciBHcm9ub3dza2ks IEp1c3RpbiBIYXJ0LCBEaWNrIEhhcmR0LCBDcmFpZyBIZWF0aCwgUGhpbCBIdW50LCBNaWNoYWVs IEIuIEpvbmVzLAogICAgICAgIFRlcnJ5IEpvbmVzLCBKb2huIEtlbXAsIE1hcmsgS2VudCwgUmFm ZmkgS3Jpa29yaWFuLCBDaGFzZW4gTGUgSGFyYSwgUmFzbXVzIExlcmRvcmYsCiAgICAgICAgVG9y c3RlbiBMb2RkZXJzdGVkdCwgSHVpLUxhbiBMdSwgQ2FzZXkgTHVjYXMsIFBhdWwgTWFkc2VuLCBB bGFzdGFpciBNYWlyLCBFdmUgTWFsZXIsCiAgICAgICAgSmFtZXMgTWFuZ2VyLCBNYXJrIE1jR2xv aW4sIExhdXJlbmNlIE1pYW8sIFdpbGxpYW0gTWlsbHMsIENodWNrIE1vcnRpbW9yZSwgQW50aG9u eSBOYWRhbGluLAogICAgICAgIEp1bGlhbiBSZXNjaGtlLCBKdXN0aW4gUmljaGVyLCBQZXRlciBT YWludC1BbmRyZSwgTmF0IFNha2ltdXJhLCBSb2IgU2F5cmUsCiAgICAgICAgTWFyaXVzIFNjdXJ0 ZXNjdSwgTmFpdGlrIFNoYWgsIEx1a2UgU2hlcGFyZCwgVmxhZCBTa3ZvcnRzb3YsIEp1c3RpbiBT bWl0aCwgSGFpYmluIFNvbmcsCiAgICAgICAgTml2IFN0ZWluZ2FydGVuLCBDaHJpc3RpYW4gU3R1 Ym5lciwgSmVyZW15IFN1cmllbCwgUGF1bCBUYXJqYW4sIENocmlzdG9waGVyIFRob21hcywKICAg ICAgICBIZW5yeSBTLiBUaG9tcHNvbiwgQWxsZW4gVG9tLCBGcmFua2xpbiBUc2UsIE5pY2sgV2Fs a2VyLCBTaGFuZSBXZWVkZW4sIGFuZCBTa3lsYXIgV29vZHdhcmQuCiAgICAgIDwvdD4KICAgICAg PHQ+CiAgICAgICAgVGhpcyBkb2N1bWVudCB3YXMgcHJvZHVjZWQgdW5kZXIgdGhlIGNoYWlybWFu c2hpcCBvZiBCbGFpbmUgQ29vaywgUGV0ZXIgU2FpbnQtQW5kcmUsCiAgICAgICAgSGFubmVzIFRz Y2hvZmVuaWcsIEJhcnJ5IExlaWJhLCBhbmQgRGVyZWsgQXRraW5zLiBUaGUgYXJlYSBkaXJlY3Rv cnMgaW5jbHVkZWQgTGlzYSBEdXNzZWF1bHQsCiAgICAgICAgUGV0ZXIgU2FpbnQtQW5kcmUsIGFu ZCBTdGVwaGVuIEZhcnJlbGwuCiAgICAgIDwvdD4KICAgIDwvc2VjdGlvbj4KCiAgICA8c2VjdGlv biB0aXRsZT0iRWRpdG9yJ3MgTm90ZXMiPgogICAgICA8dD4KICAgICAgICBXaGlsZSBtYW55IHBl b3BsZSBjb250cmlidXRlZCB0byB0aGlzIHNwZWNpZmljYXRpb24gdGhyb3VnaG91dCBpdHMgbG9u ZyBqb3VybmV5LCB0aGUgZWRpdG9yCiAgICAgICAgd291bGQgbGlrZSB0byBhY2tub3dsZWRnZSBh bmQgdGhhbmsgYSBmZXcgaW5kaXZpZHVhbHMgZm9yIHRoZWlyIG91dHN0YW5kaW5nIGFuZCBpbnZh bHVhYmxlCiAgICAgICAgZWZmb3J0cyBsZWFkaW5nIHVwIHRvIHRoZSBwdWJsaWNhdGlvbiBvZiB0 aGlzIHNwZWNpZmljYXRpb24uCiAgICAgIDwvdD4KICAgICAgPHQ+CiAgICAgICAgRGF2aWQgUmVj b3Jkb24gZm9yIGNvbnRpbnVvdXNseSBiZWluZyBvbmUgb2YgT0F1dGgncyBtb3N0IHZhbHVhYmxl IGFzc2V0cywgYnJpbmdpbmcKICAgICAgICBwcmFnbWF0aXNtIGFuZCB1cmdlbmN5IHRvIHRoZSB3 b3JrLCBhbmQgaGVscGluZyBzaGFwZSBpdCBmcm9tIGl0cyB2ZXJ5IGJlZ2lubmluZywgYXMgd2Vs bAogICAgICAgIGFzIGJlaW5nIG9uZSBvZiB0aGUgYmVzdCBjb2xsYWJvcmF0b3JzIEkgaGFkIHRo ZSBwbGVhc3VyZSBvZiB3b3JraW5nIHdpdGguCiAgICAgIDwvdD4KICAgICAgPHQ+CiAgICAgICAg SmFtZXMgTWFuZ2VyIGZvciBoaXMgY3JlYXRpdmUgaWRlYXMgYW5kIGFsd2F5cyBpbnNpZ2h0ZnVs IGZlZWRiYWNrLiBCcmlhbiBDYW1wYmVsbCwKICAgICAgICBUb3JzdGVuIExvZGRlcnN0ZWR0LCBD aHVjayBNb3J0aW1vcmUsIEp1c3RpbiBSaWNoZXIsIE1hcml1cyBTY3VydGVzY3UsIGFuZCBMdWtl IFNoZXBhcmQgZm9yCiAgICAgICAgdGhlaXIgY29udGludWVkIHBhcnRpY2lwYXRpb24gYW5kIHZh bHVhYmxlIGZlZWRiYWNrLgogICAgICA8L3Q+CiAgICAgIDx0PgogICAgICAgIFNwZWNpYWwgdGhh bmtzIGdvZXMgdG8gTWlrZSBDdXJ0aXMgYW5kIFlhaG9vISBmb3IgdGhlaXIgdW5jb25kaXRpb25h bCBzdXBwb3J0IG9mIHRoaXMgd29yawogICAgICAgIGZvciBvdmVyIHRocmVlIHllYXJzLgogICAg ICA8L3Q+CiAgICA8L3NlY3Rpb24+CgogIDwvYmFjaz4KCjwvcmZjPgo= --_006_4E1F6AAD24975D4BA5B16804296739436652EBF0TK5EX14MBXC284r_ Content-Type: text/plain; name="draft-ietf-oauth-v2-26+mbj-4.txt" Content-Description: draft-ietf-oauth-v2-26+mbj-4.txt Content-Disposition: attachment; filename="draft-ietf-oauth-v2-26+mbj-4.txt"; size=159359; creation-date="Fri, 08 Jun 2012 07:47:03 GMT"; modification-date="Fri, 08 Jun 2012 07:47:03 GMT" Content-Transfer-Encoding: base64 CgoKT0F1dGggV29ya2luZyBHcm91cCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIEUuIEhhbW1lciwgRWQuCkludGVybmV0LURyYWZ0Ck9ic29sZXRlczogNTg0OSAoaWYgYXBw cm92ZWQpICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBELiBSZWNvcmRvbgpJbnRlbmRl ZCBzdGF0dXM6IFN0YW5kYXJkcyBUcmFjayAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg RmFjZWJvb2sKRXhwaXJlczogRGVjZW1iZXIgMTAsIDIwMTIgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIEQuIEhhcmR0CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE1pY3Jvc29mdAogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBKdW5lIDgsIDIwMTIK CgogICAgICAgICAgICAgICAgIFRoZSBPQXV0aCAyLjAgQXV0aG9yaXphdGlvbiBGcmFtZXdvcmsK ICAgICAgICAgICAgICAgICAgICAgICAgIGRyYWZ0LWlldGYtb2F1dGgtdjItMjcKCkFic3RyYWN0 CgogICBUaGUgT0F1dGggMi4wIGF1dGhvcml6YXRpb24gZnJhbWV3b3JrIGVuYWJsZXMgYSB0aGly ZC1wYXJ0eQogICBhcHBsaWNhdGlvbiB0byBvYnRhaW4gbGltaXRlZCBhY2Nlc3MgdG8gYW4gSFRU UCBzZXJ2aWNlLCBlaXRoZXIgb24KICAgYmVoYWxmIG9mIGEgcmVzb3VyY2Ugb3duZXIgYnkgb3Jj aGVzdHJhdGluZyBhbiBhcHByb3ZhbCBpbnRlcmFjdGlvbgogICBiZXR3ZWVuIHRoZSByZXNvdXJj ZSBvd25lciBhbmQgdGhlIEhUVFAgc2VydmljZSwgb3IgYnkgYWxsb3dpbmcgdGhlCiAgIHRoaXJk LXBhcnR5IGFwcGxpY2F0aW9uIHRvIG9idGFpbiBhY2Nlc3Mgb24gaXRzIG93biBiZWhhbGYuICBU aGlzCiAgIHNwZWNpZmljYXRpb24gcmVwbGFjZXMgYW5kIG9ic29sZXRlcyB0aGUgT0F1dGggMS4w IHByb3RvY29sIGRlc2NyaWJlZAogICBpbiBSRkMgNTg0OS4KClN0YXR1cyBvZiB0aGlzIE1lbW8K CiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgaXMgc3VibWl0dGVkIGluIGZ1bGwgY29uZm9ybWFuY2Ug d2l0aCB0aGUKICAgcHJvdmlzaW9ucyBvZiBCQ1AgNzggYW5kIEJDUCA3OS4KCiAgIEludGVybmV0 LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5n CiAgIFRhc2sgRm9yY2UgKElFVEYpLiAgTm90ZSB0aGF0IG90aGVyIGdyb3VwcyBtYXkgYWxzbyBk aXN0cmlidXRlCiAgIHdvcmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LURyYWZ0cy4gIFRoZSBs aXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtCiAgIERyYWZ0cyBpcyBhdCBodHRwOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZHJhZnRzL2N1cnJlbnQvLgoKICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFm dCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzCiAgIGFuZCBtYXkg YmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMgYXQg YW55CiAgIHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMg YXMgcmVmZXJlbmNlCiAgIG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3 b3JrIGluIHByb2dyZXNzLiIKCiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgd2lsbCBleHBpcmUgb24g RGVjZW1iZXIgMTAsIDIwMTIuCgpDb3B5cmlnaHQgTm90aWNlCgogICBDb3B5cmlnaHQgKGMpIDIw MTIgSUVURiBUcnVzdCBhbmQgdGhlIHBlcnNvbnMgaWRlbnRpZmllZCBhcyB0aGUKICAgZG9jdW1l bnQgYXV0aG9ycy4gIEFsbCByaWdodHMgcmVzZXJ2ZWQuCgogICBUaGlzIGRvY3VtZW50IGlzIHN1 YmplY3QgdG8gQkNQIDc4IGFuZCB0aGUgSUVURiBUcnVzdCdzIExlZ2FsCiAgIFByb3Zpc2lvbnMg UmVsYXRpbmcgdG8gSUVURiBEb2N1bWVudHMKICAgKGh0dHA6Ly90cnVzdGVlLmlldGYub3JnL2xp Y2Vuc2UtaW5mbykgaW4gZWZmZWN0IG9uIHRoZSBkYXRlIG9mCiAgIHB1YmxpY2F0aW9uIG9mIHRo aXMgZG9jdW1lbnQuICBQbGVhc2UgcmV2aWV3IHRoZXNlIGRvY3VtZW50cwoKCgpIYW1tZXIsIGV0 IGFsLiAgICAgICAgICBFeHBpcmVzIERlY2VtYmVyIDEwLCAyMDEyICAgICAgICAgICAgICAgW1Bh Z2UgMV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgIE9BdXRoIDIuMCAgICAgICAg ICAgICAgICAgICAgICBKdW5lIDIwMTIKCgogICBjYXJlZnVsbHksIGFzIHRoZXkgZGVzY3JpYmUg eW91ciByaWdodHMgYW5kIHJlc3RyaWN0aW9ucyB3aXRoIHJlc3BlY3QKICAgdG8gdGhpcyBkb2N1 bWVudC4gIENvZGUgQ29tcG9uZW50cyBleHRyYWN0ZWQgZnJvbSB0aGlzIGRvY3VtZW50IG11c3QK ICAgaW5jbHVkZSBTaW1wbGlmaWVkIEJTRCBMaWNlbnNlIHRleHQgYXMgZGVzY3JpYmVkIGluIFNl Y3Rpb24gNC5lIG9mCiAgIHRoZSBUcnVzdCBMZWdhbCBQcm92aXNpb25zIGFuZCBhcmUgcHJvdmlk ZWQgd2l0aG91dCB3YXJyYW50eSBhcwogICBkZXNjcmliZWQgaW4gdGhlIFNpbXBsaWZpZWQgQlNE IExpY2Vuc2UuCgoKVGFibGUgb2YgQ29udGVudHMKCiAgIDEuICBJbnRyb2R1Y3Rpb24gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNQogICAgIDEuMS4g ICBSb2xlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gIDYKICAgICAxLjIuICAgUHJvdG9jb2wgRmxvdyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuICA3CiAgICAgMS4zLiAgIEF1dGhvcml6YXRpb24gR3JhbnQgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgOAogICAgICAgMS4zLjEuICBBdXRo b3JpemF0aW9uIENvZGUgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDgKICAg ICAgIDEuMy4yLiAgSW1wbGljaXQgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuICA4CiAgICAgICAxLjMuMy4gIFJlc291cmNlIE93bmVyIFBhc3N3b3JkIENyZWRl bnRpYWxzICAuIC4gLiAuIC4gLiAuIC4gLiAgOQogICAgICAgMS4zLjQuICBDbGllbnQgQ3JlZGVu dGlhbHMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDkKICAgICAxLjQuICAg QWNjZXNzIFRva2VuICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu ICA5CiAgICAgMS41LiAgIFJlZnJlc2ggVG9rZW4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAxMAogICAgIDEuNi4gICBUTFMgVmVyc2lvbiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTIKICAgICAxLjcuICAgSFRUUCBSZWRp cmVjdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEyCiAgICAg MS44LiAgIEludGVyb3BlcmFiaWxpdHkgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAxMgogICAgIDEuOS4gICBOb3RhdGlvbmFsIENvbnZlbnRpb25zICAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTMKICAgMi4gIENsaWVudCBSZWdpc3RyYXRpb24gIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEzCiAgICAgMi4xLiAgIENs aWVudCBUeXBlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAx NAogICAgIDIuMi4gICBDbGllbnQgSWRlbnRpZmllciAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gMTUKICAgICAyLjMuICAgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE1CiAgICAgICAyLjMuMS4gIENsaWVudCBQ YXNzd29yZCAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNgogICAgICAg Mi4zLjIuICBPdGhlciBBdXRoZW50aWNhdGlvbiBNZXRob2RzIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gMTcKICAgICAyLjQuICAgVW5yZWdpc3RlcmVkIENsaWVudHMgIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE3CiAgIDMuICBQcm90b2NvbCBFbmRwb2ludHMgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNwogICAgIDMuMS4gICBBdXRo b3JpemF0aW9uIEVuZHBvaW50ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTcK ICAgICAgIDMuMS4xLiAgUmVzcG9uc2UgVHlwZSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIDE4CiAgICAgICAzLjEuMi4gIFJlZGlyZWN0aW9uIEVuZHBvaW50IC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxOQogICAgIDMuMi4gICBUb2tlbiBFbmRwb2lu dCAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjEKICAgICAgIDMu Mi4xLiAgQ2xpZW50IEF1dGhlbnRpY2F0aW9uICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIDIxCiAgICAgMy4zLiAgIEFjY2VzcyBUb2tlbiBTY29wZSAgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAyMgogICA0LiAgT2J0YWluaW5nIEF1dGhvcml6YXRpb24gIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjMKICAgICA0LjEuICAgQXV0aG9y aXphdGlvbiBDb2RlIEdyYW50ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDIzCiAg ICAgICA0LjEuMS4gIEF1dGhvcml6YXRpb24gUmVxdWVzdCAgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAyNAogICAgICAgNC4xLjIuICBBdXRob3JpemF0aW9uIFJlc3BvbnNlIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjUKICAgICAgIDQuMS4zLiAgQWNjZXNzIFRva2Vu IFJlcXVlc3QgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDI3CiAgICAgICA0LjEu NC4gIEFjY2VzcyBUb2tlbiBSZXNwb25zZSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAyOAogICAgIDQuMi4gICBJbXBsaWNpdCBHcmFudCAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gMjkKICAgICAgIDQuMi4xLiAgQXV0aG9yaXphdGlvbiBSZXF1ZXN0 ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDMxCiAgICAgICA0LjIuMi4gIEFjY2Vz cyBUb2tlbiBSZXNwb25zZSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAzMgogICAg IDQuMy4gICBSZXNvdXJjZSBPd25lciBQYXNzd29yZCBDcmVkZW50aWFscyBHcmFudCAuIC4gLiAu IC4gLiAuIC4gMzUKICAgICAgIDQuMy4xLiAgQXV0aG9yaXphdGlvbiBSZXF1ZXN0IGFuZCBSZXNw b25zZSAuIC4gLiAuIC4gLiAuIC4gLiAuIDM2CgoKCkhhbW1lciwgZXQgYWwuICAgICAgICAgIEV4 cGlyZXMgRGVjZW1iZXIgMTAsIDIwMTIgICAgICAgICAgICAgICBbUGFnZSAyXQoMCkludGVybmV0 LURyYWZ0ICAgICAgICAgICAgICAgICAgT0F1dGggMi4wICAgICAgICAgICAgICAgICAgICAgIEp1 bmUgMjAxMgoKCiAgICAgICA0LjMuMi4gIEFjY2VzcyBUb2tlbiBSZXF1ZXN0IC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAzNgogICAgICAgNC4zLjMuICBBY2Nlc3MgVG9rZW4gUmVz cG9uc2UgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMzcKICAgICA0LjQuICAgQ2xp ZW50IENyZWRlbnRpYWxzIEdyYW50ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDM3 CiAgICAgICA0LjQuMS4gIEF1dGhvcml6YXRpb24gUmVxdWVzdCBhbmQgUmVzcG9uc2UgLiAuIC4g LiAuIC4gLiAuIC4gLiAzOAogICAgICAgNC40LjIuICBBY2Nlc3MgVG9rZW4gUmVxdWVzdCAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMzgKICAgICAgIDQuNC4zLiAgQWNjZXNzIFRv a2VuIFJlc3BvbnNlICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDM5CiAgICAgNC41 LiAgIEV4dGVuc2lvbiBHcmFudHMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAzOQogICA1LiAgSXNzdWluZyBhbiBBY2Nlc3MgVG9rZW4gIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gNDAKICAgICA1LjEuICAgU3VjY2Vzc2Z1bCBSZXNwb25zZSAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDQwCiAgICAgNS4yLiAgIEVycm9y IFJlc3BvbnNlICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA0MQog ICA2LiAgUmVmcmVzaGluZyBhbiBBY2Nlc3MgVG9rZW4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gNDMKICAgNy4gIEFjY2Vzc2luZyBQcm90ZWN0ZWQgUmVzb3VyY2VzICAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDQ0CiAgICAgNy4xLiAgIEFjY2VzcyBUb2tlbiBU eXBlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA0NQogICAgIDcuMi4g ICBFcnJvciBSZXNwb25zZSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gNDYKICAgOC4gIEV4dGVuc2liaWxpdHkgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIDQ2CiAgICAgOC4xLiAgIERlZmluaW5nIEFjY2VzcyBUb2tlbiBU eXBlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA0NgogICAgIDguMi4gICBEZWZpbmlu ZyBOZXcgRW5kcG9pbnQgUGFyYW1ldGVycyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNDcKICAg ICA4LjMuICAgRGVmaW5pbmcgTmV3IEF1dGhvcml6YXRpb24gR3JhbnQgVHlwZXMgIC4gLiAuIC4g LiAuIC4gLiAuIDQ3CiAgICAgOC40LiAgIERlZmluaW5nIE5ldyBBdXRob3JpemF0aW9uIEVuZHBv aW50IFJlc3BvbnNlIFR5cGVzICAuIC4gLiA0NwogICAgIDguNS4gICBEZWZpbmluZyBBZGRpdGlv bmFsIEVycm9yIENvZGVzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNDgKICAgOS4gIE5hdGl2 ZSBBcHBsaWNhdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IDQ4CiAgIDEwLiBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiA1MAogICAgIDEwLjEuICBDbGllbnQgQXV0aGVudGljYXRpb24gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNTAKICAgICAxMC4yLiAgQ2xpZW50IElt cGVyc29uYXRpb24gIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDUwCiAgICAg MTAuMy4gIEFjY2VzcyBUb2tlbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiA1MQogICAgIDEwLjQuICBSZWZyZXNoIFRva2VucyAgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNTIKICAgICAxMC41LiAgQXV0aG9yaXphdGlvbiBDb2Rl cyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDUyCiAgICAgMTAuNi4gIEF1 dGhvcml6YXRpb24gQ29kZSBSZWRpcmVjdGlvbiBVUkkgTWFuaXB1bGF0aW9uIC4gLiAuIC4gLiA1 MwogICAgIDEwLjcuICBSZXNvdXJjZSBPd25lciBQYXNzd29yZCBDcmVkZW50aWFscyAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gNTQKICAgICAxMC44LiAgUmVxdWVzdCBDb25maWRlbnRpYWxpdHkgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDU0CiAgICAgMTAuOS4gIEVuZHBvaW50cyBB dXRoZW50aWNpdHkgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA1NAogICAgIDEw LjEwLiBDcmVkZW50aWFscyBHdWVzc2luZyBBdHRhY2tzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gNTQKICAgICAxMC4xMS4gUGhpc2hpbmcgQXR0YWNrcyAgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIDU1CiAgICAgMTAuMTIuIENyb3NzLVNpdGUgUmVxdWVzdCBG b3JnZXJ5ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA1NQogICAgIDEwLjEzLiBDbGlj a2phY2tpbmcgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNTYK ICAgICAxMC4xNC4gQ29kZSBJbmplY3Rpb24gYW5kIElucHV0IFZhbGlkYXRpb24gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIDU3CiAgICAgMTAuMTUuIE9wZW4gUmVkaXJlY3RvcnMgIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA1NwogICAxMS4gSUFOQSBDb25zaWRlcmF0aW9u cyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNTcKICAgICAxMS4x LiAgVGhlIE9BdXRoIEFjY2VzcyBUb2tlbiBUeXBlIFJlZ2lzdHJ5ICAuIC4gLiAuIC4gLiAuIC4g LiAuIDU3CiAgICAgICAxMS4xLjEuIFJlZ2lzdHJhdGlvbiBUZW1wbGF0ZSAgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiA1OAogICAgIDExLjIuICBUaGUgT0F1dGggUGFyYW1ldGVycyBS ZWdpc3RyeSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNTgKICAgICAgIDExLjIuMS4gUmVn aXN0cmF0aW9uIFRlbXBsYXRlICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDU5CiAg ICAgICAxMS4yLjIuIEluaXRpYWwgUmVnaXN0cnkgQ29udGVudHMgIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiA1OQogICAgIDExLjMuICBUaGUgT0F1dGggQXV0aG9yaXphdGlvbiBFbmRwb2lu dCBSZXNwb25zZSBUeXBlCiAgICAgICAgICAgIFJlZ2lzdHJ5ICAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA2MQogICAgICAgMTEuMy4xLiBSZWdpc3RyYXRp b24gVGVtcGxhdGUgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNjIKICAgICAgIDEx LjMuMi4gSW5pdGlhbCBSZWdpc3RyeSBDb250ZW50cyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIDYyCiAgICAgMTEuNC4gIFRoZSBPQXV0aCBFeHRlbnNpb25zIEVycm9yIFJlZ2lzdHJ5IC4g LiAuIC4gLiAuIC4gLiAuIC4gLiA2MgoKCgpIYW1tZXIsIGV0IGFsLiAgICAgICAgICBFeHBpcmVz IERlY2VtYmVyIDEwLCAyMDEyICAgICAgICAgICAgICAgW1BhZ2UgM10KDApJbnRlcm5ldC1EcmFm dCAgICAgICAgICAgICAgICAgIE9BdXRoIDIuMCAgICAgICAgICAgICAgICAgICAgICBKdW5lIDIw MTIKCgogICAgICAgMTEuNC4xLiBSZWdpc3RyYXRpb24gVGVtcGxhdGUgIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gNjMKICAgMTIuIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDYzCiAgICAgMTIuMS4gIE5vcm1hdGl2 ZSBSZWZlcmVuY2VzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA2MwogICAg IDEyLjIuICBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gNjUKICAgQXBwZW5kaXggQS4gIEF1Z21lbnRlZCBCYWNrdXMtTmF1ciBGb3JtIChB Qk5GKSBTeW50YXggIC4gLiAuIC4gLiAuIDY1CiAgICAgQS4xLiAgICJjbGllbnRfaWQiIFN5bnRh eCAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA2NgogICAgIEEuMi4gICAi Y2xpZW50X3NlY3JldCIgU3ludGF4ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g NjYKICAgICBBLjMuICAgInJlc3BvbnNlX3R5cGUiIFN5bnRheCAgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIDY2CiAgICAgQS40LiAgICJzY29wZSIgU3ludGF4ICAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA2NgogICAgIEEuNS4gICAic3RhdGUiIFN5 bnRheCAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNjYKICAgICBB LjYuICAgInJlZGlyZWN0X3VyaSIgU3ludGF4IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIDY3CiAgICAgQS43LiAgICJlcnJvciIgU3ludGF4ICAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA2NwogICAgIEEuOC4gICAiZXJyb3JfZGVzY3JpcHRpb24i IFN5bnRheCAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNjcKICAgICBBLjkuICAgImVy cm9yX3VyaSIgU3ludGF4ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDY3 CiAgICAgQS4xMC4gICJncmFudF90eXBlIiBTeW50YXggLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiA2NwogICAgIEEuMTEuICAiY29kZSIgU3ludGF4IC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNjcKICAgICBBLjEyLiAgImFjY2Vzc190b2tl biIgU3ludGF4IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDY4CiAgICAgQS4x My4gICJ0b2tlbl90eXBlIiBTeW50YXggLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiA2OAogICAgIEEuMTQuICAiZXhwaXJlc19pbiIgU3ludGF4IC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gNjgKICAgICBBLjE1LiAgInVzZXJuYW1lIiBTeW50YXggLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDY4CiAgICAgQS4xNi4gICJwYXNz d29yZCIgU3ludGF4IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA2OAog ICAgIEEuMTcuICAicmVmcmVzaF90b2tlbiIgU3ludGF4ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gNjgKICAgICBBLjE4LiAgRW5kcG9pbnQgUGFyYW1ldGVyIFN5bnRheCAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDY5CiAgIEFwcGVuZGl4IEIuICBBY2tub3dsZWRn ZW1lbnRzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA2OQogICBBcHBlbmRp eCBDLiAgRWRpdG9yJ3MgTm90ZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gNzAKICAgQXV0aG9ycycgQWRkcmVzc2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIDcwCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgpIYW1tZXIsIGV0 IGFsLiAgICAgICAgICBFeHBpcmVzIERlY2VtYmVyIDEwLCAyMDEyICAgICAgICAgICAgICAgW1Bh Z2UgNF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgIE9BdXRoIDIuMCAgICAgICAg ICAgICAgICAgICAgICBKdW5lIDIwMTIKCgoxLiAgSW50cm9kdWN0aW9uCgogICBJbiB0aGUgdHJh ZGl0aW9uYWwgY2xpZW50LXNlcnZlciBhdXRoZW50aWNhdGlvbiBtb2RlbCwgdGhlIGNsaWVudAog ICByZXF1ZXN0cyBhbiBhY2Nlc3MgcmVzdHJpY3RlZCByZXNvdXJjZSAocHJvdGVjdGVkIHJlc291 cmNlKSBvbiB0aGUKICAgc2VydmVyIGJ5IGF1dGhlbnRpY2F0aW5nIHdpdGggdGhlIHNlcnZlciB1 c2luZyB0aGUgcmVzb3VyY2Ugb3duZXIncwogICBjcmVkZW50aWFscy4gIEluIG9yZGVyIHRvIHBy b3ZpZGUgdGhpcmQtcGFydHkgYXBwbGljYXRpb25zIGFjY2VzcyB0bwogICByZXN0cmljdGVkIHJl c291cmNlcywgdGhlIHJlc291cmNlIG93bmVyIHNoYXJlcyBpdHMgY3JlZGVudGlhbHMgd2l0aAog ICB0aGUgdGhpcmQtcGFydHkuICBUaGlzIGNyZWF0ZXMgc2V2ZXJhbCBwcm9ibGVtcyBhbmQgbGlt aXRhdGlvbnM6CgogICBvICBUaGlyZC1wYXJ0eSBhcHBsaWNhdGlvbnMgYXJlIHJlcXVpcmVkIHRv IHN0b3JlIHRoZSByZXNvdXJjZQogICAgICBvd25lcidzIGNyZWRlbnRpYWxzIGZvciBmdXR1cmUg dXNlLCB0eXBpY2FsbHkgYSBwYXNzd29yZCBpbiBjbGVhci0KICAgICAgdGV4dC4KICAgbyAgU2Vy dmVycyBhcmUgcmVxdWlyZWQgdG8gc3VwcG9ydCBwYXNzd29yZCBhdXRoZW50aWNhdGlvbiwgZGVz cGl0ZQogICAgICB0aGUgc2VjdXJpdHkgd2Vha25lc3NlcyBpbmhlcmVudCBpbiBwYXNzd29yZHMu CiAgIG8gIFRoaXJkLXBhcnR5IGFwcGxpY2F0aW9ucyBnYWluIG92ZXJseSBicm9hZCBhY2Nlc3Mg dG8gdGhlIHJlc291cmNlCiAgICAgIG93bmVyJ3MgcHJvdGVjdGVkIHJlc291cmNlcywgbGVhdmlu ZyByZXNvdXJjZSBvd25lcnMgd2l0aG91dCBhbnkKICAgICAgYWJpbGl0eSB0byByZXN0cmljdCBk dXJhdGlvbiBvciBhY2Nlc3MgdG8gYSBsaW1pdGVkIHN1YnNldCBvZgogICAgICByZXNvdXJjZXMu CiAgIG8gIFJlc291cmNlIG93bmVycyBjYW5ub3QgcmV2b2tlIGFjY2VzcyB0byBhbiBpbmRpdmlk dWFsIHRoaXJkLXBhcnR5CiAgICAgIHdpdGhvdXQgcmV2b2tpbmcgYWNjZXNzIHRvIGFsbCB0aGly ZC1wYXJ0aWVzLCBhbmQgbXVzdCBkbyBzbyBieQogICAgICBjaGFuZ2luZyB0aGVpciBwYXNzd29y ZC4KICAgbyAgQ29tcHJvbWlzZSBvZiBhbnkgdGhpcmQtcGFydHkgYXBwbGljYXRpb24gcmVzdWx0 cyBpbiBjb21wcm9taXNlIG9mCiAgICAgIHRoZSBlbmQtdXNlcidzIHBhc3N3b3JkIGFuZCBhbGwg b2YgdGhlIGRhdGEgcHJvdGVjdGVkIGJ5IHRoYXQKICAgICAgcGFzc3dvcmQuCgogICBPQXV0aCBh ZGRyZXNzZXMgdGhlc2UgaXNzdWVzIGJ5IGludHJvZHVjaW5nIGFuIGF1dGhvcml6YXRpb24gbGF5 ZXIKICAgYW5kIHNlcGFyYXRpbmcgdGhlIHJvbGUgb2YgdGhlIGNsaWVudCBmcm9tIHRoYXQgb2Yg dGhlIHJlc291cmNlCiAgIG93bmVyLiAgSW4gT0F1dGgsIHRoZSBjbGllbnQgcmVxdWVzdHMgYWNj ZXNzIHRvIHJlc291cmNlcyBjb250cm9sbGVkCiAgIGJ5IHRoZSByZXNvdXJjZSBvd25lciBhbmQg aG9zdGVkIGJ5IHRoZSByZXNvdXJjZSBzZXJ2ZXIsIGFuZCBpcwogICBpc3N1ZWQgYSBkaWZmZXJl bnQgc2V0IG9mIGNyZWRlbnRpYWxzIHRoYW4gdGhvc2Ugb2YgdGhlIHJlc291cmNlCiAgIG93bmVy LgoKICAgSW5zdGVhZCBvZiB1c2luZyB0aGUgcmVzb3VyY2Ugb3duZXIncyBjcmVkZW50aWFscyB0 byBhY2Nlc3MgcHJvdGVjdGVkCiAgIHJlc291cmNlcywgdGhlIGNsaWVudCBvYnRhaW5zIGFuIGFj Y2VzcyB0b2tlbiAtIGEgc3RyaW5nIGRlbm90aW5nIGEKICAgc3BlY2lmaWMgc2NvcGUsIGxpZmV0 aW1lLCBhbmQgb3RoZXIgYWNjZXNzIGF0dHJpYnV0ZXMuICBBY2Nlc3MgdG9rZW5zCiAgIGFyZSBp c3N1ZWQgdG8gdGhpcmQtcGFydHkgY2xpZW50cyBieSBhbiBhdXRob3JpemF0aW9uIHNlcnZlciB3 aXRoIHRoZQogICBhcHByb3ZhbCBvZiB0aGUgcmVzb3VyY2Ugb3duZXIuICBUaGUgY2xpZW50IHVz ZXMgdGhlIGFjY2VzcyB0b2tlbiB0bwogICBhY2Nlc3MgdGhlIHByb3RlY3RlZCByZXNvdXJjZXMg aG9zdGVkIGJ5IHRoZSByZXNvdXJjZSBzZXJ2ZXIuCgogICBGb3IgZXhhbXBsZSwgYW4gZW5kLXVz ZXIgKHJlc291cmNlIG93bmVyKSBjYW4gZ3JhbnQgYSBwcmludGluZwogICBzZXJ2aWNlIChjbGll bnQpIGFjY2VzcyB0byBoZXIgcHJvdGVjdGVkIHBob3RvcyBzdG9yZWQgYXQgYSBwaG90bwogICBz aGFyaW5nIHNlcnZpY2UgKHJlc291cmNlIHNlcnZlciksIHdpdGhvdXQgc2hhcmluZyBoZXIgdXNl cm5hbWUgYW5kCiAgIHBhc3N3b3JkIHdpdGggdGhlIHByaW50aW5nIHNlcnZpY2UuICBJbnN0ZWFk LCBzaGUgYXV0aGVudGljYXRlcwogICBkaXJlY3RseSB3aXRoIGEgc2VydmVyIHRydXN0ZWQgYnkg dGhlIHBob3RvIHNoYXJpbmcgc2VydmljZQogICAoYXV0aG9yaXphdGlvbiBzZXJ2ZXIpIHdoaWNo IGlzc3VlcyB0aGUgcHJpbnRpbmcgc2VydmljZSBkZWxlZ2F0aW9uLQogICBzcGVjaWZpYyBjcmVk ZW50aWFscyAoYWNjZXNzIHRva2VuKS4KCiAgIFRoaXMgc3BlY2lmaWNhdGlvbiBpcyBkZXNpZ25l ZCBmb3IgdXNlIHdpdGggSFRUUCAoW1JGQzI2MTZdKS4gIFRoZQoKCgpIYW1tZXIsIGV0IGFsLiAg ICAgICAgICBFeHBpcmVzIERlY2VtYmVyIDEwLCAyMDEyICAgICAgICAgICAgICAgW1BhZ2UgNV0K DApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgIE9BdXRoIDIuMCAgICAgICAgICAgICAg ICAgICAgICBKdW5lIDIwMTIKCgogICB1c2Ugb2YgT0F1dGggb3ZlciBhbnkgb3RoZXIgcHJvdG9j b2wgdGhhbiBIVFRQIGlzIG91dCBvZiBzY29wZS4KCiAgIFRoZSBPQXV0aCAxLjAgcHJvdG9jb2wg KFtSRkM1ODQ5XSksIHB1Ymxpc2hlZCBhcyBhbiBpbmZvcm1hdGlvbmFsCiAgIGRvY3VtZW50LCB3 YXMgdGhlIHJlc3VsdCBvZiBhIHNtYWxsIGFkLWhvYyBjb21tdW5pdHkgZWZmb3J0LiAgVGhpcwog ICBzdGFuZGFyZHMtdHJhY2sgc3BlY2lmaWNhdGlvbiBidWlsZHMgb24gdGhlIE9BdXRoIDEuMCBk ZXBsb3ltZW50CiAgIGV4cGVyaWVuY2UsIGFzIHdlbGwgYXMgYWRkaXRpb25hbCB1c2UgY2FzZXMg YW5kIGV4dGVuc2liaWxpdHkKICAgcmVxdWlyZW1lbnRzIGdhdGhlcmVkIGZyb20gdGhlIHdpZGVy IElFVEYgY29tbXVuaXR5LiAgVGhlIE9BdXRoIDIuMAogICBwcm90b2NvbCBpcyBub3QgYmFja3dh cmQgY29tcGF0aWJsZSB3aXRoIE9BdXRoIDEuMC4gIFRoZSB0d28gdmVyc2lvbnMKICAgbWF5IGNv LWV4aXN0IG9uIHRoZSBuZXR3b3JrIGFuZCBpbXBsZW1lbnRhdGlvbnMgbWF5IGNob29zZSB0byBz dXBwb3J0CiAgIGJvdGguICBIb3dldmVyLCBpdCBpcyB0aGUgaW50ZW50aW9uIG9mIHRoaXMgc3Bl Y2lmaWNhdGlvbiB0aGF0IG5ldwogICBpbXBsZW1lbnRhdGlvbiBzdXBwb3J0IE9BdXRoIDIuMCBh cyBzcGVjaWZpZWQgaW4gdGhpcyBkb2N1bWVudCwgYW5kCiAgIHRoYXQgT0F1dGggMS4wIGlzIHVz ZWQgb25seSB0byBzdXBwb3J0IGV4aXN0aW5nIGRlcGxveW1lbnRzLiAgVGhlCiAgIE9BdXRoIDIu MCBwcm90b2NvbCBzaGFyZXMgdmVyeSBmZXcgaW1wbGVtZW50YXRpb24gZGV0YWlscyB3aXRoIHRo ZQogICBPQXV0aCAxLjAgcHJvdG9jb2wuICBJbXBsZW1lbnRlcnMgZmFtaWxpYXIgd2l0aCBPQXV0 aCAxLjAgc2hvdWxkCiAgIGFwcHJvYWNoIHRoaXMgZG9jdW1lbnQgd2l0aG91dCBhbnkgYXNzdW1w dGlvbnMgYXMgdG8gaXRzIHN0cnVjdHVyZQogICBhbmQgZGV0YWlscy4KCjEuMS4gIFJvbGVzCgog ICBPQXV0aCBkZWZpbmVzIGZvdXIgcm9sZXM6CgogICByZXNvdXJjZSBvd25lcgogICAgICBBbiBl bnRpdHkgY2FwYWJsZSBvZiBncmFudGluZyBhY2Nlc3MgdG8gYSBwcm90ZWN0ZWQgcmVzb3VyY2Uu CiAgICAgIFdoZW4gdGhlIHJlc291cmNlIG93bmVyIGlzIGEgcGVyc29uLCBpdCBpcyByZWZlcnJl ZCB0byBhcyBhbiBlbmQtCiAgICAgIHVzZXIuCiAgIHJlc291cmNlIHNlcnZlcgogICAgICBUaGUg c2VydmVyIGhvc3RpbmcgdGhlIHByb3RlY3RlZCByZXNvdXJjZXMsIGNhcGFibGUgb2YgYWNjZXB0 aW5nCiAgICAgIGFuZCByZXNwb25kaW5nIHRvIHByb3RlY3RlZCByZXNvdXJjZSByZXF1ZXN0cyB1 c2luZyBhY2Nlc3MgdG9rZW5zLgogICBjbGllbnQKICAgICAgQW4gYXBwbGljYXRpb24gbWFraW5n IHByb3RlY3RlZCByZXNvdXJjZSByZXF1ZXN0cyBvbiBiZWhhbGYgb2YgdGhlCiAgICAgIHJlc291 cmNlIG93bmVyIGFuZCB3aXRoIGl0cyBhdXRob3JpemF0aW9uLiAgVGhlIHRlcm0gY2xpZW50IGRv ZXMKICAgICAgbm90IGltcGx5IGFueSBwYXJ0aWN1bGFyIGltcGxlbWVudGF0aW9uIGNoYXJhY3Rl cmlzdGljcyAoZS5nLgogICAgICB3aGV0aGVyIHRoZSBhcHBsaWNhdGlvbiBleGVjdXRlcyBvbiBh IHNlcnZlciwgYSBkZXNrdG9wLCBvciBvdGhlcgogICAgICBkZXZpY2VzKS4KICAgYXV0aG9yaXph dGlvbiBzZXJ2ZXIKICAgICAgVGhlIHNlcnZlciBpc3N1aW5nIGFjY2VzcyB0b2tlbnMgdG8gdGhl IGNsaWVudCBhZnRlciBzdWNjZXNzZnVsbHkKICAgICAgYXV0aGVudGljYXRpbmcgdGhlIHJlc291 cmNlIG93bmVyIGFuZCBvYnRhaW5pbmcgYXV0aG9yaXphdGlvbi4KCiAgIFRoZSBpbnRlcmFjdGlv biBiZXR3ZWVuIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBhbmQgcmVzb3VyY2Ugc2VydmVyCiAg IGlzIGJleW9uZCB0aGUgc2NvcGUgb2YgdGhpcyBzcGVjaWZpY2F0aW9uLiAgVGhlIGF1dGhvcml6 YXRpb24gc2VydmVyCiAgIG1heSBiZSB0aGUgc2FtZSBzZXJ2ZXIgYXMgdGhlIHJlc291cmNlIHNl cnZlciBvciBhIHNlcGFyYXRlIGVudGl0eS4KICAgQSBzaW5nbGUgYXV0aG9yaXphdGlvbiBzZXJ2 ZXIgbWF5IGlzc3VlIGFjY2VzcyB0b2tlbnMgYWNjZXB0ZWQgYnkKICAgbXVsdGlwbGUgcmVzb3Vy Y2Ugc2VydmVycy4KCgoKCgoKCgpIYW1tZXIsIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIERlY2Vt YmVyIDEwLCAyMDEyICAgICAgICAgICAgICAgW1BhZ2UgNl0KDApJbnRlcm5ldC1EcmFmdCAgICAg ICAgICAgICAgICAgIE9BdXRoIDIuMCAgICAgICAgICAgICAgICAgICAgICBKdW5lIDIwMTIKCgox LjIuICBQcm90b2NvbCBGbG93CgoKICAgICArLS0tLS0tLS0rICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0rCiAgICAgfCAgICAgICAgfC0tKEEpLSBBdXRob3Jp emF0aW9uIFJlcXVlc3QgLT58ICAgUmVzb3VyY2UgICAgfAogICAgIHwgICAgICAgIHwgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgT3duZXIgICAgIHwKICAgICB8ICAgICAgICB8 PC0oQiktLSBBdXRob3JpemF0aW9uIEdyYW50IC0tLXwgICAgICAgICAgICAgICB8CiAgICAgfCAg ICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tKwog ICAgIHwgICAgICAgIHwKICAgICB8ICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICstLS0tLS0tLS0tLS0tLS0rCiAgICAgfCAgICAgICAgfC0tKEMpLS0gQXV0aG9yaXphdGlv biBHcmFudCAtLT58IEF1dGhvcml6YXRpb24gfAogICAgIHwgQ2xpZW50IHwgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgfCAgICAgU2VydmVyICAgIHwKICAgICB8ICAgICAgICB8PC0oRCkt LS0tLSBBY2Nlc3MgVG9rZW4gLS0tLS0tLXwgICAgICAgICAgICAgICB8CiAgICAgfCAgICAgICAg fCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tKwogICAgIHwg ICAgICAgIHwKICAgICB8ICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICst LS0tLS0tLS0tLS0tLS0rCiAgICAgfCAgICAgICAgfC0tKEUpLS0tLS0gQWNjZXNzIFRva2VuIC0t LS0tLT58ICAgIFJlc291cmNlICAgfAogICAgIHwgICAgICAgIHwgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgfCAgICAgU2VydmVyICAgIHwKICAgICB8ICAgICAgICB8PC0oRiktLS0gUHJv dGVjdGVkIFJlc291cmNlIC0tLXwgICAgICAgICAgICAgICB8CiAgICAgKy0tLS0tLS0tKyAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tKwoKCiAgICAgICAgICAg ICAgICAgICAgIEZpZ3VyZSAxOiBBYnN0cmFjdCBQcm90b2NvbCBGbG93CgogICBUaGUgYWJzdHJh Y3QgZmxvdyBpbGx1c3RyYXRlZCBpbiBGaWd1cmUgMSBkZXNjcmliZXMgdGhlIGludGVyYWN0aW9u CiAgIGJldHdlZW4gdGhlIGZvdXIgcm9sZXMgYW5kIGluY2x1ZGVzIHRoZSBmb2xsb3dpbmcgc3Rl cHM6CgogICAoQSkgIFRoZSBjbGllbnQgcmVxdWVzdHMgYXV0aG9yaXphdGlvbiBmcm9tIHRoZSBy ZXNvdXJjZSBvd25lci4gIFRoZQogICAgICAgIGF1dGhvcml6YXRpb24gcmVxdWVzdCBjYW4gYmUg bWFkZSBkaXJlY3RseSB0byB0aGUgcmVzb3VyY2Ugb3duZXIKICAgICAgICAoYXMgc2hvd24pLCBv ciBwcmVmZXJhYmx5IGluZGlyZWN0bHkgdmlhIHRoZSBhdXRob3JpemF0aW9uCiAgICAgICAgc2Vy dmVyIGFzIGFuIGludGVybWVkaWFyeS4KICAgKEIpICBUaGUgY2xpZW50IHJlY2VpdmVzIGFuIGF1 dGhvcml6YXRpb24gZ3JhbnQgd2hpY2ggaXMgYSBjcmVkZW50aWFsCiAgICAgICAgcmVwcmVzZW50 aW5nIHRoZSByZXNvdXJjZSBvd25lcidzIGF1dGhvcml6YXRpb24sIGV4cHJlc3NlZCB1c2luZwog ICAgICAgIG9uZSBvZiBmb3VyIGdyYW50IHR5cGVzIGRlZmluZWQgaW4gdGhpcyBzcGVjaWZpY2F0 aW9uIG9yIHVzaW5nCiAgICAgICAgYW4gZXh0ZW5zaW9uIGdyYW50IHR5cGUuICBUaGUgYXV0aG9y aXphdGlvbiBncmFudCB0eXBlIGRlcGVuZHMKICAgICAgICBvbiB0aGUgbWV0aG9kIHVzZWQgYnkg dGhlIGNsaWVudCB0byByZXF1ZXN0IGF1dGhvcml6YXRpb24gYW5kCiAgICAgICAgdGhlIHR5cGVz IHN1cHBvcnRlZCBieSB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIuCiAgIChDKSAgVGhlIGNsaWVu dCByZXF1ZXN0cyBhbiBhY2Nlc3MgdG9rZW4gYnkgYXV0aGVudGljYXRpbmcgd2l0aCB0aGUKICAg ICAgICBhdXRob3JpemF0aW9uIHNlcnZlciBhbmQgcHJlc2VudGluZyB0aGUgYXV0aG9yaXphdGlv biBncmFudC4KICAgKEQpICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYXV0aGVudGljYXRlcyB0 aGUgY2xpZW50IGFuZCB2YWxpZGF0ZXMKICAgICAgICB0aGUgYXV0aG9yaXphdGlvbiBncmFudCwg YW5kIGlmIHZhbGlkIGlzc3VlcyBhbiBhY2Nlc3MgdG9rZW4uCiAgIChFKSAgVGhlIGNsaWVudCBy ZXF1ZXN0cyB0aGUgcHJvdGVjdGVkIHJlc291cmNlIGZyb20gdGhlIHJlc291cmNlCiAgICAgICAg c2VydmVyIGFuZCBhdXRoZW50aWNhdGVzIGJ5IHByZXNlbnRpbmcgdGhlIGFjY2VzcyB0b2tlbi4K ICAgKEYpICBUaGUgcmVzb3VyY2Ugc2VydmVyIHZhbGlkYXRlcyB0aGUgYWNjZXNzIHRva2VuLCBh bmQgaWYgdmFsaWQsCiAgICAgICAgc2VydmVzIHRoZSByZXF1ZXN0LgoKICAgVGhlIHByZWZlcnJl ZCBtZXRob2QgZm9yIHRoZSBjbGllbnQgdG8gb2J0YWluIGFuIGF1dGhvcml6YXRpb24gZ3JhbnQK ICAgZnJvbSB0aGUgcmVzb3VyY2Ugb3duZXIgKGRlcGljdGVkIGluIHN0ZXBzIChBKSBhbmQgKEIp KSBpcyB0byB1c2UgdGhlCgoKCkhhbW1lciwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgRGVjZW1i ZXIgMTAsIDIwMTIgICAgICAgICAgICAgICBbUGFnZSA3XQoMCkludGVybmV0LURyYWZ0ICAgICAg ICAgICAgICAgICAgT0F1dGggMi4wICAgICAgICAgICAgICAgICAgICAgIEp1bmUgMjAxMgoKCiAg IGF1dGhvcml6YXRpb24gc2VydmVyIGFzIGFuIGludGVybWVkaWFyeSB3aGljaCBpcyBpbGx1c3Ry YXRlZCBpbgogICBGaWd1cmUgMy4KCjEuMy4gIEF1dGhvcml6YXRpb24gR3JhbnQKCiAgIEFuIGF1 dGhvcml6YXRpb24gZ3JhbnQgaXMgYSBjcmVkZW50aWFsIHJlcHJlc2VudGluZyB0aGUgcmVzb3Vy Y2UKICAgb3duZXIncyBhdXRob3JpemF0aW9uICh0byBhY2Nlc3MgaXRzIHByb3RlY3RlZCByZXNv dXJjZXMpIHVzZWQgYnkgdGhlCiAgIGNsaWVudCB0byBvYnRhaW4gYW4gYWNjZXNzIHRva2VuLiAg VGhpcyBzcGVjaWZpY2F0aW9uIGRlZmluZXMgZm91cgogICBncmFudCB0eXBlczogYXV0aG9yaXph dGlvbiBjb2RlLCBpbXBsaWNpdCwgcmVzb3VyY2Ugb3duZXIgcGFzc3dvcmQKICAgY3JlZGVudGlh bHMsIGFuZCBjbGllbnQgY3JlZGVudGlhbHMsIGFzIHdlbGwgYXMgYW4gZXh0ZW5zaWJpbGl0eQog ICBtZWNoYW5pc20gZm9yIGRlZmluaW5nIGFkZGl0aW9uYWwgdHlwZXMuCgoxLjMuMS4gIEF1dGhv cml6YXRpb24gQ29kZQoKICAgVGhlIGF1dGhvcml6YXRpb24gY29kZSBpcyBvYnRhaW5lZCBieSB1 c2luZyBhbiBhdXRob3JpemF0aW9uIHNlcnZlcgogICBhcyBhbiBpbnRlcm1lZGlhcnkgYmV0d2Vl biB0aGUgY2xpZW50IGFuZCByZXNvdXJjZSBvd25lci4gIEluc3RlYWQgb2YKICAgcmVxdWVzdGlu ZyBhdXRob3JpemF0aW9uIGRpcmVjdGx5IGZyb20gdGhlIHJlc291cmNlIG93bmVyLCB0aGUgY2xp ZW50CiAgIGRpcmVjdHMgdGhlIHJlc291cmNlIG93bmVyIHRvIGFuIGF1dGhvcml6YXRpb24gc2Vy dmVyICh2aWEgaXRzIHVzZXItCiAgIGFnZW50IGFzIGRlZmluZWQgaW4gW1JGQzI2MTZdKSwgd2hp Y2ggaW4gdHVybiBkaXJlY3RzIHRoZSByZXNvdXJjZQogICBvd25lciBiYWNrIHRvIHRoZSBjbGll bnQgd2l0aCB0aGUgYXV0aG9yaXphdGlvbiBjb2RlLgoKICAgQmVmb3JlIGRpcmVjdGluZyB0aGUg cmVzb3VyY2Ugb3duZXIgYmFjayB0byB0aGUgY2xpZW50IHdpdGggdGhlCiAgIGF1dGhvcml6YXRp b24gY29kZSwgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGF1dGhlbnRpY2F0ZXMgdGhlCiAgIHJl c291cmNlIG93bmVyIGFuZCBvYnRhaW5zIGF1dGhvcml6YXRpb24uICBCZWNhdXNlIHRoZSByZXNv dXJjZSBvd25lcgogICBvbmx5IGF1dGhlbnRpY2F0ZXMgd2l0aCB0aGUgYXV0aG9yaXphdGlvbiBz ZXJ2ZXIsIHRoZSByZXNvdXJjZQogICBvd25lcidzIGNyZWRlbnRpYWxzIGFyZSBuZXZlciBzaGFy ZWQgd2l0aCB0aGUgY2xpZW50LgoKICAgVGhlIGF1dGhvcml6YXRpb24gY29kZSBwcm92aWRlcyBh IGZldyBpbXBvcnRhbnQgc2VjdXJpdHkgYmVuZWZpdHMKICAgc3VjaCBhcyB0aGUgYWJpbGl0eSB0 byBhdXRoZW50aWNhdGUgdGhlIGNsaWVudCwgYW5kIHRoZSB0cmFuc21pc3Npb24KICAgb2YgdGhl IGFjY2VzcyB0b2tlbiBkaXJlY3RseSB0byB0aGUgY2xpZW50IHdpdGhvdXQgcGFzc2luZyBpdCB0 aHJvdWdoCiAgIHRoZSByZXNvdXJjZSBvd25lcidzIHVzZXItYWdlbnQsIHBvdGVudGlhbGx5IGV4 cG9zaW5nIGl0IHRvIG90aGVycywKICAgaW5jbHVkaW5nIHRoZSByZXNvdXJjZSBvd25lci4KCjEu My4yLiAgSW1wbGljaXQKCiAgIFRoZSBpbXBsaWNpdCBncmFudCBpcyBhIHNpbXBsaWZpZWQgYXV0 aG9yaXphdGlvbiBjb2RlIGZsb3cgb3B0aW1pemVkCiAgIGZvciBjbGllbnRzIGltcGxlbWVudGVk IGluIGEgYnJvd3NlciB1c2luZyBhIHNjcmlwdGluZyBsYW5ndWFnZSBzdWNoCiAgIGFzIEphdmFT Y3JpcHQuICBJbiB0aGUgaW1wbGljaXQgZmxvdywgaW5zdGVhZCBvZiBpc3N1aW5nIHRoZSBjbGll bnQKICAgYW4gYXV0aG9yaXphdGlvbiBjb2RlLCB0aGUgY2xpZW50IGlzIGlzc3VlZCBhbiBhY2Nl c3MgdG9rZW4gZGlyZWN0bHkKICAgKGFzIHRoZSByZXN1bHQgb2YgdGhlIHJlc291cmNlIG93bmVy IGF1dGhvcml6YXRpb24pLiAgVGhlIGdyYW50IHR5cGUKICAgaXMgaW1wbGljaXQgYXMgbm8gaW50 ZXJtZWRpYXRlIGNyZWRlbnRpYWxzIChzdWNoIGFzIGFuIGF1dGhvcml6YXRpb24KICAgY29kZSkg YXJlIGlzc3VlZCAoYW5kIGxhdGVyIHVzZWQgdG8gb2J0YWluIGFuIGFjY2VzcyB0b2tlbikuCgog ICBXaGVuIGlzc3VpbmcgYW4gYWNjZXNzIHRva2VuIGR1cmluZyB0aGUgaW1wbGljaXQgZ3JhbnQg ZmxvdywgdGhlCiAgIGF1dGhvcml6YXRpb24gc2VydmVyIGRvZXMgbm90IGF1dGhlbnRpY2F0ZSB0 aGUgY2xpZW50LiAgSW4gc29tZQogICBjYXNlcywgdGhlIGNsaWVudCBpZGVudGl0eSBjYW4gYmUg dmVyaWZpZWQgdmlhIHRoZSByZWRpcmVjdGlvbiBVUkkKICAgdXNlZCB0byBkZWxpdmVyIHRoZSBh Y2Nlc3MgdG9rZW4gdG8gdGhlIGNsaWVudC4gIFRoZSBhY2Nlc3MgdG9rZW4gbWF5CiAgIGJlIGV4 cG9zZWQgdG8gdGhlIHJlc291cmNlIG93bmVyIG9yIG90aGVyIGFwcGxpY2F0aW9ucyB3aXRoIGFj Y2VzcyB0bwoKCgpIYW1tZXIsIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIERlY2VtYmVyIDEwLCAy MDEyICAgICAgICAgICAgICAgW1BhZ2UgOF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAg ICAgIE9BdXRoIDIuMCAgICAgICAgICAgICAgICAgICAgICBKdW5lIDIwMTIKCgogICB0aGUgcmVz b3VyY2Ugb3duZXIncyB1c2VyLWFnZW50LgoKICAgSW1wbGljaXQgZ3JhbnRzIGltcHJvdmUgdGhl IHJlc3BvbnNpdmVuZXNzIGFuZCBlZmZpY2llbmN5IG9mIHNvbWUKICAgY2xpZW50cyAoc3VjaCBh cyBhIGNsaWVudCBpbXBsZW1lbnRlZCBhcyBhbiBpbi1icm93c2VyIGFwcGxpY2F0aW9uKQogICBz aW5jZSBpdCByZWR1Y2VzIHRoZSBudW1iZXIgb2Ygcm91bmQgdHJpcHMgcmVxdWlyZWQgdG8gb2J0 YWluIGFuCiAgIGFjY2VzcyB0b2tlbi4gIEhvd2V2ZXIsIHRoaXMgY29udmVuaWVuY2Ugc2hvdWxk IGJlIHdlaWdoZWQgYWdhaW5zdAogICB0aGUgc2VjdXJpdHkgaW1wbGljYXRpb25zIG9mIHVzaW5n IGltcGxpY2l0IGdyYW50cywgZXNwZWNpYWxseSB3aGVuCiAgIHRoZSBhdXRob3JpemF0aW9uIGNv ZGUgZ3JhbnQgdHlwZSBpcyBhdmFpbGFibGUuCgoxLjMuMy4gIFJlc291cmNlIE93bmVyIFBhc3N3 b3JkIENyZWRlbnRpYWxzCgogICBUaGUgcmVzb3VyY2Ugb3duZXIgcGFzc3dvcmQgY3JlZGVudGlh bHMgKGkuZS4gdXNlcm5hbWUgYW5kIHBhc3N3b3JkKQogICBjYW4gYmUgdXNlZCBkaXJlY3RseSBh cyBhbiBhdXRob3JpemF0aW9uIGdyYW50IHRvIG9idGFpbiBhbiBhY2Nlc3MKICAgdG9rZW4uICBU aGUgY3JlZGVudGlhbHMgc2hvdWxkIG9ubHkgYmUgdXNlZCB3aGVuIHRoZXJlIGlzIGEgaGlnaAog ICBkZWdyZWUgb2YgdHJ1c3QgYmV0d2VlbiB0aGUgcmVzb3VyY2Ugb3duZXIgYW5kIHRoZSBjbGll bnQgKGUuZy4gdGhlCiAgIGNsaWVudCBpcyBwYXJ0IG9mIHRoZSBkZXZpY2Ugb3BlcmF0aW5nIHN5 c3RlbSBvciBhIGhpZ2hseSBwcml2aWxlZ2VkCiAgIGFwcGxpY2F0aW9uKSwgYW5kIHdoZW4gb3Ro ZXIgYXV0aG9yaXphdGlvbiBncmFudCB0eXBlcyBhcmUgbm90CiAgIGF2YWlsYWJsZSAoc3VjaCBh cyBhbiBhdXRob3JpemF0aW9uIGNvZGUpLgoKICAgRXZlbiB0aG91Z2ggdGhpcyBncmFudCB0eXBl IHJlcXVpcmVzIGRpcmVjdCBjbGllbnQgYWNjZXNzIHRvIHRoZQogICByZXNvdXJjZSBvd25lciBj cmVkZW50aWFscywgdGhlIHJlc291cmNlIG93bmVyIGNyZWRlbnRpYWxzIGFyZSB1c2VkCiAgIGZv ciBhIHNpbmdsZSByZXF1ZXN0IGFuZCBhcmUgZXhjaGFuZ2VkIGZvciBhbiBhY2Nlc3MgdG9rZW4u ICBUaGlzCiAgIGdyYW50IHR5cGUgY2FuIGVsaW1pbmF0ZSB0aGUgbmVlZCBmb3IgdGhlIGNsaWVu dCB0byBzdG9yZSB0aGUKICAgcmVzb3VyY2Ugb3duZXIgY3JlZGVudGlhbHMgZm9yIGZ1dHVyZSB1 c2UsIGJ5IGV4Y2hhbmdpbmcgdGhlCiAgIGNyZWRlbnRpYWxzIHdpdGggYSBsb25nLWxpdmVkIGFj Y2VzcyB0b2tlbiBvciByZWZyZXNoIHRva2VuLgoKMS4zLjQuICBDbGllbnQgQ3JlZGVudGlhbHMK CiAgIFRoZSBjbGllbnQgY3JlZGVudGlhbHMgKG9yIG90aGVyIGZvcm1zIG9mIGNsaWVudCBhdXRo ZW50aWNhdGlvbikgY2FuCiAgIGJlIHVzZWQgYXMgYW4gYXV0aG9yaXphdGlvbiBncmFudCB3aGVu IHRoZSBhdXRob3JpemF0aW9uIHNjb3BlIGlzCiAgIGxpbWl0ZWQgdG8gdGhlIHByb3RlY3RlZCBy ZXNvdXJjZXMgdW5kZXIgdGhlIGNvbnRyb2wgb2YgdGhlIGNsaWVudCwKICAgb3IgdG8gcHJvdGVj dGVkIHJlc291cmNlcyBwcmV2aW91c2x5IGFycmFuZ2VkIHdpdGggdGhlIGF1dGhvcml6YXRpb24K ICAgc2VydmVyLiAgQ2xpZW50IGNyZWRlbnRpYWxzIGFyZSB1c2VkIGFzIGFuIGF1dGhvcml6YXRp b24gZ3JhbnQKICAgdHlwaWNhbGx5IHdoZW4gdGhlIGNsaWVudCBpcyBhY3Rpbmcgb24gaXRzIG93 biBiZWhhbGYgKHRoZSBjbGllbnQgaXMKICAgYWxzbyB0aGUgcmVzb3VyY2Ugb3duZXIpLCBvciBp cyByZXF1ZXN0aW5nIGFjY2VzcyB0byBwcm90ZWN0ZWQKICAgcmVzb3VyY2VzIGJhc2VkIG9uIGFu IGF1dGhvcml6YXRpb24gcHJldmlvdXNseSBhcnJhbmdlZCB3aXRoIHRoZQogICBhdXRob3JpemF0 aW9uIHNlcnZlci4KCjEuNC4gIEFjY2VzcyBUb2tlbgoKICAgQWNjZXNzIHRva2VucyBhcmUgY3Jl ZGVudGlhbHMgdXNlZCB0byBhY2Nlc3MgcHJvdGVjdGVkIHJlc291cmNlcy4gIEFuCiAgIGFjY2Vz cyB0b2tlbiBpcyBhIHN0cmluZyByZXByZXNlbnRpbmcgYW4gYXV0aG9yaXphdGlvbiBpc3N1ZWQg dG8gdGhlCiAgIGNsaWVudC4gIFRoZSBzdHJpbmcgaXMgdXN1YWxseSBvcGFxdWUgdG8gdGhlIGNs aWVudC4gIFRva2VucwogICByZXByZXNlbnQgc3BlY2lmaWMgc2NvcGVzIGFuZCBkdXJhdGlvbnMg b2YgYWNjZXNzLCBncmFudGVkIGJ5IHRoZQogICByZXNvdXJjZSBvd25lciwgYW5kIGVuZm9yY2Vk IGJ5IHRoZSByZXNvdXJjZSBzZXJ2ZXIgYW5kIGF1dGhvcml6YXRpb24KICAgc2VydmVyLgoKICAg VGhlIHRva2VuIG1heSBkZW5vdGUgYW4gaWRlbnRpZmllciB1c2VkIHRvIHJldHJpZXZlIHRoZSBh dXRob3JpemF0aW9uCgoKCkhhbW1lciwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgRGVjZW1iZXIg MTAsIDIwMTIgICAgICAgICAgICAgICBbUGFnZSA5XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAg ICAgICAgICAgT0F1dGggMi4wICAgICAgICAgICAgICAgICAgICAgIEp1bmUgMjAxMgoKCiAgIGlu Zm9ybWF0aW9uLCBvciBzZWxmLWNvbnRhaW4gdGhlIGF1dGhvcml6YXRpb24gaW5mb3JtYXRpb24g aW4gYQogICB2ZXJpZmlhYmxlIG1hbm5lciAoaS5lLiBhIHRva2VuIHN0cmluZyBjb25zaXN0aW5n IG9mIHNvbWUgZGF0YSBhbmQgYQogICBzaWduYXR1cmUpLiAgQWRkaXRpb25hbCBhdXRoZW50aWNh dGlvbiBjcmVkZW50aWFscywgd2hpY2ggYXJlIGJleW9uZAogICB0aGUgc2NvcGUgb2YgdGhpcyBz cGVjaWZpY2F0aW9uLCBtYXkgYmUgcmVxdWlyZWQgaW4gb3JkZXIgZm9yIHRoZQogICBjbGllbnQg dG8gdXNlIGEgdG9rZW4uCgogICBUaGUgYWNjZXNzIHRva2VuIHByb3ZpZGVzIGFuIGFic3RyYWN0 aW9uIGxheWVyLCByZXBsYWNpbmcgZGlmZmVyZW50CiAgIGF1dGhvcml6YXRpb24gY29uc3RydWN0 cyAoZS5nLiB1c2VybmFtZSBhbmQgcGFzc3dvcmQpIHdpdGggYSBzaW5nbGUKICAgdG9rZW4gdW5k ZXJzdG9vZCBieSB0aGUgcmVzb3VyY2Ugc2VydmVyLiAgVGhpcyBhYnN0cmFjdGlvbiBlbmFibGVz CiAgIGlzc3VpbmcgYWNjZXNzIHRva2VucyBtb3JlIHJlc3RyaWN0aXZlIHRoYW4gdGhlIGF1dGhv cml6YXRpb24gZ3JhbnQKICAgdXNlZCB0byBvYnRhaW4gdGhlbSwgYXMgd2VsbCBhcyByZW1vdmlu ZyB0aGUgcmVzb3VyY2Ugc2VydmVyJ3MgbmVlZAogICB0byB1bmRlcnN0YW5kIGEgd2lkZSByYW5n ZSBvZiBhdXRoZW50aWNhdGlvbiBtZXRob2RzLgoKICAgQWNjZXNzIHRva2VucyBjYW4gaGF2ZSBk aWZmZXJlbnQgZm9ybWF0cywgc3RydWN0dXJlcywgYW5kIG1ldGhvZHMgb2YKICAgdXRpbGl6YXRp b24gKGUuZy4gY3J5cHRvZ3JhcGhpYyBwcm9wZXJ0aWVzKSBiYXNlZCBvbiB0aGUgcmVzb3VyY2UK ICAgc2VydmVyIHNlY3VyaXR5IHJlcXVpcmVtZW50cy4gIEFjY2VzcyB0b2tlbiBhdHRyaWJ1dGVz IGFuZCB0aGUKICAgbWV0aG9kcyB1c2VkIHRvIGFjY2VzcyBwcm90ZWN0ZWQgcmVzb3VyY2VzIGFy ZSBiZXlvbmQgdGhlIHNjb3BlIG9mCiAgIHRoaXMgc3BlY2lmaWNhdGlvbiBhbmQgYXJlIGRlZmlu ZWQgYnkgY29tcGFuaW9uIHNwZWNpZmljYXRpb25zLgoKMS41LiAgUmVmcmVzaCBUb2tlbgoKICAg UmVmcmVzaCB0b2tlbnMgYXJlIGNyZWRlbnRpYWxzIHVzZWQgdG8gb2J0YWluIGFjY2VzcyB0b2tl bnMuICBSZWZyZXNoCiAgIHRva2VucyBhcmUgaXNzdWVkIHRvIHRoZSBjbGllbnQgYnkgdGhlIGF1 dGhvcml6YXRpb24gc2VydmVyIGFuZCBhcmUKICAgdXNlZCB0byBvYnRhaW4gYSBuZXcgYWNjZXNz IHRva2VuIHdoZW4gdGhlIGN1cnJlbnQgYWNjZXNzIHRva2VuCiAgIGJlY29tZXMgaW52YWxpZCBv ciBleHBpcmVzLCBvciB0byBvYnRhaW4gYWRkaXRpb25hbCBhY2Nlc3MgdG9rZW5zCiAgIHdpdGgg aWRlbnRpY2FsIG9yIG5hcnJvd2VyIHNjb3BlIChhY2Nlc3MgdG9rZW5zIG1heSBoYXZlIGEgc2hv cnRlcgogICBsaWZldGltZSBhbmQgZmV3ZXIgcGVybWlzc2lvbnMgdGhhbiBhdXRob3JpemVkIGJ5 IHRoZSByZXNvdXJjZQogICBvd25lcikuICBJc3N1aW5nIGEgcmVmcmVzaCB0b2tlbiBpcyBvcHRp b25hbCBhdCB0aGUgZGlzY3JldGlvbiBvZiB0aGUKICAgYXV0aG9yaXphdGlvbiBzZXJ2ZXIuICBJ ZiB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgaXNzdWVzIGEgcmVmcmVzaAogICB0b2tlbiwgaXQg aXMgaW5jbHVkZWQgd2hlbiBpc3N1aW5nIGFuIGFjY2VzcyB0b2tlbiAoaS5lLiBzdGVwIChEKSBp bgogICBGaWd1cmUgMSkuCgogICBBIHJlZnJlc2ggdG9rZW4gaXMgYSBzdHJpbmcgcmVwcmVzZW50 aW5nIHRoZSBhdXRob3JpemF0aW9uIGdyYW50ZWQgdG8KICAgdGhlIGNsaWVudCBieSB0aGUgcmVz b3VyY2Ugb3duZXIuICBUaGUgc3RyaW5nIGlzIHVzdWFsbHkgb3BhcXVlIHRvCiAgIHRoZSBjbGll bnQuICBUaGUgdG9rZW4gZGVub3RlcyBhbiBpZGVudGlmaWVyIHVzZWQgdG8gcmV0cmlldmUgdGhl CiAgIGF1dGhvcml6YXRpb24gaW5mb3JtYXRpb24uICBVbmxpa2UgYWNjZXNzIHRva2VucywgcmVm cmVzaCB0b2tlbnMgYXJlCiAgIGludGVuZGVkIGZvciB1c2Ugb25seSB3aXRoIGF1dGhvcml6YXRp b24gc2VydmVycyBhbmQgYXJlIG5ldmVyIHNlbnQKICAgdG8gcmVzb3VyY2Ugc2VydmVycy4KCgoK CgoKCgoKCgoKCkhhbW1lciwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgRGVjZW1iZXIgMTAsIDIw MTIgICAgICAgICAgICAgIFtQYWdlIDEwXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAg ICAgT0F1dGggMi4wICAgICAgICAgICAgICAgICAgICAgIEp1bmUgMjAxMgoKCiAgKy0tLS0tLS0t KyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0t LS0tKwogIHwgICAgICAgIHwtLShBKS0tLS0tLS0gQXV0aG9yaXphdGlvbiBHcmFudCAtLS0tLS0t LS0+fCAgICAgICAgICAgICAgIHwKICB8ICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICB8CiAgfCAgICAgICAgfDwtKEIpLS0t LS0tLS0tLS0gQWNjZXNzIFRva2VuIC0tLS0tLS0tLS0tLS18ICAgICAgICAgICAgICAgfAogIHwg ICAgICAgIHwgICAgICAgICAgICAgICAmIFJlZnJlc2ggVG9rZW4gICAgICAgICAgICAgfCAgICAg ICAgICAgICAgIHwKICB8ICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHwgICAgICAgICAgICAgICB8CiAgfCAgICAgICAgfCAgICAgICAgICAgICAgICAg ICAgICAgICAgICArLS0tLS0tLS0tLSsgICB8ICAgICAgICAgICAgICAgfAogIHwgICAgICAgIHwt LShDKS0tLS0gQWNjZXNzIFRva2VuIC0tLS0+fCAgICAgICAgICB8ICAgfCAgICAgICAgICAgICAg IHwKICB8ICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgfCAg IHwgICAgICAgICAgICAgICB8CiAgfCAgICAgICAgfDwtKEQpLSBQcm90ZWN0ZWQgUmVzb3VyY2Ug LS18IFJlc291cmNlIHwgICB8IEF1dGhvcml6YXRpb24gfAogIHwgQ2xpZW50IHwgICAgICAgICAg ICAgICAgICAgICAgICAgICAgfCAgU2VydmVyICB8ICAgfCAgICAgU2VydmVyICAgIHwKICB8ICAg ICAgICB8LS0oRSktLS0tIEFjY2VzcyBUb2tlbiAtLS0tPnwgICAgICAgICAgfCAgIHwgICAgICAg ICAgICAgICB8CiAgfCAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAg ICAgIHwgICB8ICAgICAgICAgICAgICAgfAogIHwgICAgICAgIHw8LShGKS0gSW52YWxpZCBUb2tl biBFcnJvciAtfCAgICAgICAgICB8ICAgfCAgICAgICAgICAgICAgIHwKICB8ICAgICAgICB8ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tKyAgIHwgICAgICAgICAgICAgICB8 CiAgfCAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8 ICAgICAgICAgICAgICAgfAogIHwgICAgICAgIHwtLShHKS0tLS0tLS0tLS0tIFJlZnJlc2ggVG9r ZW4gLS0tLS0tLS0tLS0+fCAgICAgICAgICAgICAgIHwKICB8ICAgICAgICB8ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICB8CiAgfCAgICAg ICAgfDwtKEgpLS0tLS0tLS0tLS0gQWNjZXNzIFRva2VuIC0tLS0tLS0tLS0tLS18ICAgICAgICAg ICAgICAgfAogICstLS0tLS0tLSsgICAgICAgICAgICYgT3B0aW9uYWwgUmVmcmVzaCBUb2tlbiAg ICAgICAgKy0tLS0tLS0tLS0tLS0tLSsKCgogICAgICAgICAgICAgICBGaWd1cmUgMjogUmVmcmVz aGluZyBhbiBFeHBpcmVkIEFjY2VzcyBUb2tlbgoKICAgVGhlIGZsb3cgaWxsdXN0cmF0ZWQgaW4g RmlndXJlIDIgaW5jbHVkZXMgdGhlIGZvbGxvd2luZyBzdGVwczoKCiAgIChBKSAgVGhlIGNsaWVu dCByZXF1ZXN0cyBhbiBhY2Nlc3MgdG9rZW4gYnkgYXV0aGVudGljYXRpbmcgd2l0aCB0aGUKICAg ICAgICBhdXRob3JpemF0aW9uIHNlcnZlciwgYW5kIHByZXNlbnRpbmcgYW4gYXV0aG9yaXphdGlv biBncmFudC4KICAgKEIpICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYXV0aGVudGljYXRlcyB0 aGUgY2xpZW50IGFuZCB2YWxpZGF0ZXMKICAgICAgICB0aGUgYXV0aG9yaXphdGlvbiBncmFudCwg YW5kIGlmIHZhbGlkIGlzc3VlcyBhbiBhY2Nlc3MgdG9rZW4gYW5kCiAgICAgICAgYSByZWZyZXNo IHRva2VuLgogICAoQykgIFRoZSBjbGllbnQgbWFrZXMgYSBwcm90ZWN0ZWQgcmVzb3VyY2UgcmVx dWVzdCB0byB0aGUgcmVzb3VyY2UKICAgICAgICBzZXJ2ZXIgYnkgcHJlc2VudGluZyB0aGUgYWNj ZXNzIHRva2VuLgogICAoRCkgIFRoZSByZXNvdXJjZSBzZXJ2ZXIgdmFsaWRhdGVzIHRoZSBhY2Nl c3MgdG9rZW4sIGFuZCBpZiB2YWxpZCwKICAgICAgICBzZXJ2ZXMgdGhlIHJlcXVlc3QuCiAgIChF KSAgU3RlcHMgKEMpIGFuZCAoRCkgcmVwZWF0IHVudGlsIHRoZSBhY2Nlc3MgdG9rZW4gZXhwaXJl cy4gIElmIHRoZQogICAgICAgIGNsaWVudCBrbm93cyB0aGUgYWNjZXNzIHRva2VuIGV4cGlyZWQs IGl0IHNraXBzIHRvIHN0ZXAgKEcpLAogICAgICAgIG90aGVyd2lzZSBpdCBtYWtlcyBhbm90aGVy IHByb3RlY3RlZCByZXNvdXJjZSByZXF1ZXN0LgogICAoRikgIFNpbmNlIHRoZSBhY2Nlc3MgdG9r ZW4gaXMgaW52YWxpZCwgdGhlIHJlc291cmNlIHNlcnZlciByZXR1cm5zCiAgICAgICAgYW4gaW52 YWxpZCB0b2tlbiBlcnJvci4KICAgKEcpICBUaGUgY2xpZW50IHJlcXVlc3RzIGEgbmV3IGFjY2Vz cyB0b2tlbiBieSBhdXRoZW50aWNhdGluZyB3aXRoCiAgICAgICAgdGhlIGF1dGhvcml6YXRpb24g c2VydmVyIGFuZCBwcmVzZW50aW5nIHRoZSByZWZyZXNoIHRva2VuLiAgVGhlCiAgICAgICAgY2xp ZW50IGF1dGhlbnRpY2F0aW9uIHJlcXVpcmVtZW50cyBhcmUgYmFzZWQgb24gdGhlIGNsaWVudCB0 eXBlCiAgICAgICAgYW5kIG9uIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBwb2xpY2llcy4KCgoK CgoKCkhhbW1lciwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgRGVjZW1iZXIgMTAsIDIwMTIgICAg ICAgICAgICAgIFtQYWdlIDExXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgT0F1 dGggMi4wICAgICAgICAgICAgICAgICAgICAgIEp1bmUgMjAxMgoKCiAgIChIKSAgVGhlIGF1dGhv cml6YXRpb24gc2VydmVyIGF1dGhlbnRpY2F0ZXMgdGhlIGNsaWVudCBhbmQgdmFsaWRhdGVzCiAg ICAgICAgdGhlIHJlZnJlc2ggdG9rZW4sIGFuZCBpZiB2YWxpZCBpc3N1ZXMgYSBuZXcgYWNjZXNz IHRva2VuIChhbmQKICAgICAgICBvcHRpb25hbGx5LCBhIG5ldyByZWZyZXNoIHRva2VuKS4KCiAg IFN0ZXBzIEMsIEQsIEUsIGFuZCBGIGFyZSBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIHNwZWNp ZmljYXRpb24gYXMKICAgZGVzY3JpYmVkIGluIFNlY3Rpb24gNy4KCjEuNi4gIFRMUyBWZXJzaW9u CgogICBXaGVuZXZlciBUTFMgaXMgdXNlZCBieSB0aGlzIHNwZWNpZmljYXRpb24sIHRoZSBhcHBy b3ByaWF0ZSB2ZXJzaW9uCiAgIChvciB2ZXJzaW9ucykgb2YgVExTIHdpbGwgdmFyeSBvdmVyIHRp bWUsIGJhc2VkIG9uIHRoZSB3aWRlc3ByZWFkCiAgIGRlcGxveW1lbnQgYW5kIGtub3duIHNlY3Vy aXR5IHZ1bG5lcmFiaWxpdGllcy4gIEF0IHRoZSB0aW1lIG9mIHRoaXMKICAgd3JpdGluZywgVExT IHZlcnNpb24gMS4yIFtSRkM1MjQ2XSBpcyB0aGUgbW9zdCByZWNlbnQgdmVyc2lvbiwgYnV0CiAg IGhhcyBhIHZlcnkgbGltaXRlZCBkZXBsb3ltZW50IGJhc2UgYW5kIG1pZ2h0IG5vdCBiZSByZWFk aWx5IGF2YWlsYWJsZQogICBmb3IgaW1wbGVtZW50YXRpb24uICBUTFMgdmVyc2lvbiAxLjAgW1JG QzIyNDZdIGlzIHRoZSBtb3N0IHdpZGVseQogICBkZXBsb3llZCB2ZXJzaW9uLCBhbmQgd2lsbCBw cm92aWRlIHRoZSBicm9hZGVzdCBpbnRlcm9wZXJhYmlsaXR5LgoKICAgSW1wbGVtZW50YXRpb25z IE1BWSBhbHNvIHN1cHBvcnQgYWRkaXRpb25hbCB0cmFuc3BvcnQtbGF5ZXIgc2VjdXJpdHkKICAg bWVjaGFuaXNtcyB0aGF0IG1lZXQgdGhlaXIgc2VjdXJpdHkgcmVxdWlyZW1lbnRzLgoKMS43LiAg SFRUUCBSZWRpcmVjdGlvbnMKCiAgIFRoaXMgc3BlY2lmaWNhdGlvbiBtYWtlcyBleHRlbnNpdmUg dXNlIG9mIEhUVFAgcmVkaXJlY3Rpb25zLCBpbiB3aGljaAogICB0aGUgY2xpZW50IG9yIHRoZSBh dXRob3JpemF0aW9uIHNlcnZlciBkaXJlY3QgdGhlIHJlc291cmNlIG93bmVyJ3MKICAgdXNlci1h Z2VudCB0byBhbm90aGVyIGRlc3RpbmF0aW9uLiAgV2hpbGUgdGhlIGV4YW1wbGVzIGluIHRoaXMK ICAgc3BlY2lmaWNhdGlvbiBzaG93IHRoZSB1c2Ugb2YgdGhlIEhUVFAgMzAyIHN0YXR1cyBjb2Rl LCBhbnkgb3RoZXIKICAgbWV0aG9kIGF2YWlsYWJsZSB2aWEgdGhlIHVzZXItYWdlbnQgdG8gYWNj b21wbGlzaCB0aGlzIHJlZGlyZWN0aW9uIGlzCiAgIGFsbG93ZWQgYW5kIGlzIGNvbnNpZGVyZWQg dG8gYmUgYW4gaW1wbGVtZW50YXRpb24gZGV0YWlsLgoKMS44LiAgSW50ZXJvcGVyYWJpbGl0eQoK ICAgT0F1dGggMi4wIHByb3ZpZGVzIGEgcmljaCBhdXRob3JpemF0aW9uIGZyYW1ld29yayB3aXRo IHdlbGwtZGVmaW5lZAogICBzZWN1cml0eSBwcm9wZXJ0aWVzLiAgSG93ZXZlciwgYXMgYSByaWNo IGFuZCBoaWdobHkgZXh0ZW5zaWJsZQogICBmcmFtZXdvcmsgd2l0aCBtYW55IG9wdGlvbmFsIGNv bXBvbmVudHMsIG9uIGl0cyBvd24sIHRoaXMKICAgc3BlY2lmaWNhdGlvbiBpcyBsaWtlbHkgdG8g cHJvZHVjZSBhIHdpZGUgcmFuZ2Ugb2Ygbm9uLWludGVyb3BlcmFibGUKICAgaW1wbGVtZW50YXRp b25zLgoKICAgSW4gYWRkaXRpb24sIHRoaXMgc3BlY2lmaWNhdGlvbiBsZWF2ZXMgYSBmZXcgcmVx dWlyZWQgY29tcG9uZW50cwogICBwYXJ0aWFsbHkgb3IgZnVsbHkgdW5kZWZpbmVkIChlLmcuIGNs aWVudCByZWdpc3RyYXRpb24sIGF1dGhvcml6YXRpb24KICAgc2VydmVyIGNhcGFiaWxpdGllcywg ZW5kcG9pbnQgZGlzY292ZXJ5KS4gIFdpdGhvdXQgdGhlc2UgY29tcG9uZW50cywKICAgY2xpZW50 cyBtdXN0IGJlIG1hbnVhbGx5IGFuZCBzcGVjaWZpY2FsbHkgY29uZmlndXJlZCBhZ2FpbnN0IGEK ICAgc3BlY2lmaWMgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYW5kIHJlc291cmNlIHNlcnZlciBpbiBv cmRlciB0bwogICBpbnRlcm9wZXJhdGUuCgogICBUaGlzIGZyYW1ld29yayB3YXMgZGVzaWduZWQg d2l0aCB0aGUgY2xlYXIgZXhwZWN0YXRpb24gdGhhdCBmdXR1cmUKICAgd29yayB3aWxsIGRlZmlu ZSBwcmVzY3JpcHRpdmUgcHJvZmlsZXMgYW5kIGV4dGVuc2lvbnMgbmVjZXNzYXJ5IHRvCiAgIGFj aGlldmUgZnVsbCB3ZWItc2NhbGUgaW50ZXJvcGVyYWJpbGl0eS4KCgoKCkhhbW1lciwgZXQgYWwu ICAgICAgICAgIEV4cGlyZXMgRGVjZW1iZXIgMTAsIDIwMTIgICAgICAgICAgICAgIFtQYWdlIDEy XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgT0F1dGggMi4wICAgICAgICAgICAg ICAgICAgICAgIEp1bmUgMjAxMgoKCjEuOS4gIE5vdGF0aW9uYWwgQ29udmVudGlvbnMKCiAgIFRo ZSBrZXkgd29yZHMgIk1VU1QiLCAiTVVTVCBOT1QiLCAiUkVRVUlSRUQiLCAiU0hBTEwiLCAiU0hB TEwgTk9UIiwKICAgIlNIT1VMRCIsICJTSE9VTEQgTk9UIiwgIlJFQ09NTUVOREVEIiwgIk1BWSIs IGFuZCAiT1BUSU9OQUwiIGluIHRoaXMKICAgc3BlY2lmaWNhdGlvbiBhcmUgdG8gYmUgaW50ZXJw cmV0ZWQgYXMgZGVzY3JpYmVkIGluIFtSRkMyMTE5XS4KCiAgIFRoaXMgc3BlY2lmaWNhdGlvbiB1 c2VzIHRoZSBBdWdtZW50ZWQgQmFja3VzLU5hdXIgRm9ybSAoQUJORikKICAgbm90YXRpb24gb2Yg W1JGQzUyMzRdLiAgQWRkaXRpb25hbGx5LCB0aGUgcnVsZSBVUkktUmVmZXJlbmNlIGlzCiAgIGlu Y2x1ZGVkIGZyb20gVW5pZm9ybSBSZXNvdXJjZSBJZGVudGlmaWVyIChVUkkpIFtSRkMzOTg2XS4K CiAgIENlcnRhaW4gc2VjdXJpdHktcmVsYXRlZCB0ZXJtcyBhcmUgdG8gYmUgdW5kZXJzdG9vZCBp biB0aGUgc2Vuc2UKICAgZGVmaW5lZCBpbiBbUkZDNDk0OV0uICBUaGVzZSB0ZXJtcyBpbmNsdWRl LCBidXQgYXJlIG5vdCBsaW1pdGVkIHRvLAogICAiYXR0YWNrIiwgImF1dGhlbnRpY2F0aW9uIiwg ImF1dGhvcml6YXRpb24iLCAiY2VydGlmaWNhdGUiLAogICAiY29uZmlkZW50aWFsaXR5IiwgImNy ZWRlbnRpYWwiLCAiZW5jcnlwdGlvbiIsICJpZGVudGl0eSIsICJzaWduIiwKICAgInNpZ25hdHVy ZSIsICJ0cnVzdCIsICJ2YWxpZGF0ZSIsIGFuZCAidmVyaWZ5Ii4KCiAgIFVubGVzcyBvdGhlcndp c2Ugbm90ZWQsIGFsbCB0aGUgcHJvdG9jb2wgcGFyYW1ldGVyIG5hbWVzIGFuZCB2YWx1ZXMKICAg YXJlIGNhc2Ugc2Vuc2l0aXZlLgoKCjIuICBDbGllbnQgUmVnaXN0cmF0aW9uCgogICBCZWZvcmUg aW5pdGlhdGluZyB0aGUgcHJvdG9jb2wsIHRoZSBjbGllbnQgcmVnaXN0ZXJzIHdpdGggdGhlCiAg IGF1dGhvcml6YXRpb24gc2VydmVyLiAgVGhlIG1lYW5zIHRocm91Z2ggd2hpY2ggdGhlIGNsaWVu dCByZWdpc3RlcnMKICAgd2l0aCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYXJlIGJleW9uZCB0 aGUgc2NvcGUgb2YgdGhpcwogICBzcGVjaWZpY2F0aW9uLCBidXQgdHlwaWNhbGx5IGludm9sdmUg ZW5kLXVzZXIgaW50ZXJhY3Rpb24gd2l0aCBhbgogICBIVE1MIHJlZ2lzdHJhdGlvbiBmb3JtLgoK ICAgQ2xpZW50IHJlZ2lzdHJhdGlvbiBkb2VzIG5vdCByZXF1aXJlIGEgZGlyZWN0IGludGVyYWN0 aW9uIGJldHdlZW4gdGhlCiAgIGNsaWVudCBhbmQgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLiAg V2hlbiBzdXBwb3J0ZWQgYnkgdGhlCiAgIGF1dGhvcml6YXRpb24gc2VydmVyLCByZWdpc3RyYXRp b24gY2FuIHJlbHkgb24gb3RoZXIgbWVhbnMgZm9yCiAgIGVzdGFibGlzaGluZyB0cnVzdCBhbmQg b2J0YWluaW5nIHRoZSByZXF1aXJlZCBjbGllbnQgcHJvcGVydGllcyAoZS5nLgogICByZWRpcmVj dGlvbiBVUkksIGNsaWVudCB0eXBlKS4gIEZvciBleGFtcGxlLCByZWdpc3RyYXRpb24gY2FuIGJl CiAgIGFjY29tcGxpc2hlZCB1c2luZyBhIHNlbGYtaXNzdWVkIG9yIHRoaXJkLXBhcnR5LWlzc3Vl ZCBhc3NlcnRpb24sIG9yCiAgIGJ5IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBwZXJmb3JtaW5n IGNsaWVudCBkaXNjb3ZlcnkgdXNpbmcgYQogICB0cnVzdGVkIGNoYW5uZWwuCgogICBXaGVuIHJl Z2lzdGVyaW5nIGEgY2xpZW50LCB0aGUgY2xpZW50IGRldmVsb3BlciBTSEFMTDoKCiAgIG8gIHNw ZWNpZnkgdGhlIGNsaWVudCB0eXBlIGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDIuMSwKICAgbyAg cHJvdmlkZSBpdHMgY2xpZW50IHJlZGlyZWN0aW9uIFVSSXMgYXMgZGVzY3JpYmVkIGluIFNlY3Rp b24gMy4xLjIsCiAgICAgIGFuZAogICBvICBpbmNsdWRlIGFueSBvdGhlciBpbmZvcm1hdGlvbiBy ZXF1aXJlZCBieSB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIKICAgICAgKGUuZy4gYXBwbGljYXRp b24gbmFtZSwgd2Vic2l0ZSwgZGVzY3JpcHRpb24sIGxvZ28gaW1hZ2UsIHRoZQogICAgICBhY2Nl cHRhbmNlIG9mIGxlZ2FsIHRlcm1zKS4KCgoKCgoKSGFtbWVyLCBldCBhbC4gICAgICAgICAgRXhw aXJlcyBEZWNlbWJlciAxMCwgMjAxMiAgICAgICAgICAgICAgW1BhZ2UgMTNdCgwKSW50ZXJuZXQt RHJhZnQgICAgICAgICAgICAgICAgICBPQXV0aCAyLjAgICAgICAgICAgICAgICAgICAgICAgSnVu ZSAyMDEyCgoKMi4xLiAgQ2xpZW50IFR5cGVzCgogICBPQXV0aCBkZWZpbmVzIHR3byBjbGllbnQg dHlwZXMsIGJhc2VkIG9uIHRoZWlyIGFiaWxpdHkgdG8KICAgYXV0aGVudGljYXRlIHNlY3VyZWx5 IHdpdGggdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIChpLmUuIGFiaWxpdHkgdG8KICAgbWFpbnRh aW4gdGhlIGNvbmZpZGVudGlhbGl0eSBvZiB0aGVpciBjbGllbnQgY3JlZGVudGlhbHMpOgoKICAg Y29uZmlkZW50aWFsCiAgICAgIENsaWVudHMgY2FwYWJsZSBvZiBtYWludGFpbmluZyB0aGUgY29u ZmlkZW50aWFsaXR5IG9mIHRoZWlyCiAgICAgIGNyZWRlbnRpYWxzIChlLmcuIGNsaWVudCBpbXBs ZW1lbnRlZCBvbiBhIHNlY3VyZSBzZXJ2ZXIgd2l0aAogICAgICByZXN0cmljdGVkIGFjY2VzcyB0 byB0aGUgY2xpZW50IGNyZWRlbnRpYWxzKSwgb3IgY2FwYWJsZSBvZiBzZWN1cmUKICAgICAgY2xp ZW50IGF1dGhlbnRpY2F0aW9uIHVzaW5nIG90aGVyIG1lYW5zLgogICBwdWJsaWMKICAgICAgQ2xp ZW50cyBpbmNhcGFibGUgb2YgbWFpbnRhaW5pbmcgdGhlIGNvbmZpZGVudGlhbGl0eSBvZiB0aGVp cgogICAgICBjcmVkZW50aWFscyAoZS5nLiBjbGllbnRzIGV4ZWN1dGluZyBvbiB0aGUgZGV2aWNl IHVzZWQgYnkgdGhlCiAgICAgIHJlc291cmNlIG93bmVyIHN1Y2ggYXMgYW4gaW5zdGFsbGVkIG5h dGl2ZSBhcHBsaWNhdGlvbiBvciBhIHdlYgogICAgICBicm93c2VyLWJhc2VkIGFwcGxpY2F0aW9u KSwgYW5kIGluY2FwYWJsZSBvZiBzZWN1cmUgY2xpZW50CiAgICAgIGF1dGhlbnRpY2F0aW9uIHZp YSBhbnkgb3RoZXIgbWVhbnMuCgogICBUaGUgY2xpZW50IHR5cGUgZGVzaWduYXRpb24gaXMgYmFz ZWQgb24gdGhlIGF1dGhvcml6YXRpb24gc2VydmVyJ3MKICAgZGVmaW5pdGlvbiBvZiBzZWN1cmUg YXV0aGVudGljYXRpb24gYW5kIGl0cyBhY2NlcHRhYmxlIGV4cG9zdXJlCiAgIGxldmVscyBvZiBj bGllbnQgY3JlZGVudGlhbHMuICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgU0hPVUxEIE5PVAog ICBtYWtlIGFzc3VtcHRpb25zIGFib3V0IHRoZSBjbGllbnQgdHlwZS4KCiAgIEEgY2xpZW50IG1h eSBiZSBpbXBsZW1lbnRlZCBhcyBhIGRpc3RyaWJ1dGVkIHNldCBvZiBjb21wb25lbnRzLCBlYWNo CiAgIHdpdGggYSBkaWZmZXJlbnQgY2xpZW50IHR5cGUgYW5kIHNlY3VyaXR5IGNvbnRleHQgKGUu Zy4gYSBkaXN0cmlidXRlZAogICBjbGllbnQgd2l0aCBib3RoIGEgY29uZmlkZW50aWFsIHNlcnZl ci1iYXNlZCBjb21wb25lbnQgYW5kIGEgcHVibGljCiAgIGJyb3dzZXItYmFzZWQgY29tcG9uZW50 KS4gIElmIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBkb2VzIG5vdAogICBwcm92aWRlIHN1cHBv cnQgZm9yIHN1Y2ggY2xpZW50cywgb3IgZG9lcyBub3QgcHJvdmlkZSBndWlkYW5jZSB3aXRoCiAg IHJlZ2FyZCB0byB0aGVpciByZWdpc3RyYXRpb24sIHRoZSBjbGllbnQgU0hPVUxEIHJlZ2lzdGVy IGVhY2gKICAgY29tcG9uZW50IGFzIGEgc2VwYXJhdGUgY2xpZW50LgoKICAgVGhpcyBzcGVjaWZp Y2F0aW9uIGhhcyBiZWVuIGRlc2lnbmVkIGFyb3VuZCB0aGUgZm9sbG93aW5nIGNsaWVudAogICBw cm9maWxlczoKCiAgIHdlYiBhcHBsaWNhdGlvbgogICAgICBBIHdlYiBhcHBsaWNhdGlvbiBpcyBh IGNvbmZpZGVudGlhbCBjbGllbnQgcnVubmluZyBvbiBhIHdlYgogICAgICBzZXJ2ZXIuICBSZXNv dXJjZSBvd25lcnMgYWNjZXNzIHRoZSBjbGllbnQgdmlhIGFuIEhUTUwgdXNlcgogICAgICBpbnRl cmZhY2UgcmVuZGVyZWQgaW4gYSB1c2VyLWFnZW50IG9uIHRoZSBkZXZpY2UgdXNlZCBieSB0aGUK ICAgICAgcmVzb3VyY2Ugb3duZXIuICBUaGUgY2xpZW50IGNyZWRlbnRpYWxzIGFzIHdlbGwgYXMg YW55IGFjY2VzcwogICAgICB0b2tlbiBpc3N1ZWQgdG8gdGhlIGNsaWVudCBhcmUgc3RvcmVkIG9u IHRoZSB3ZWIgc2VydmVyIGFuZCBhcmUKICAgICAgbm90IGV4cG9zZWQgdG8gb3IgYWNjZXNzaWJs ZSBieSB0aGUgcmVzb3VyY2Ugb3duZXIuCiAgIHVzZXItYWdlbnQtYmFzZWQgYXBwbGljYXRpb24K ICAgICAgQSB1c2VyLWFnZW50LWJhc2VkIGFwcGxpY2F0aW9uIGlzIGEgcHVibGljIGNsaWVudCBp biB3aGljaCB0aGUKICAgICAgY2xpZW50IGNvZGUgaXMgZG93bmxvYWRlZCBmcm9tIGEgd2ViIHNl cnZlciBhbmQgZXhlY3V0ZXMgd2l0aGluIGEKICAgICAgdXNlci1hZ2VudCAoZS5nLiB3ZWIgYnJv d3Nlcikgb24gdGhlIGRldmljZSB1c2VkIGJ5IHRoZSByZXNvdXJjZQogICAgICBvd25lci4gIFBy b3RvY29sIGRhdGEgYW5kIGNyZWRlbnRpYWxzIGFyZSBlYXNpbHkgYWNjZXNzaWJsZSAoYW5kCiAg ICAgIG9mdGVuIHZpc2libGUpIHRvIHRoZSByZXNvdXJjZSBvd25lci4gIFNpbmNlIHN1Y2ggYXBw bGljYXRpb25zCiAgICAgIHJlc2lkZSB3aXRoaW4gdGhlIHVzZXItYWdlbnQsIHRoZXkgY2FuIG1h a2Ugc2VhbWxlc3MgdXNlIG9mIHRoZQoKCgpIYW1tZXIsIGV0IGFsLiAgICAgICAgICBFeHBpcmVz IERlY2VtYmVyIDEwLCAyMDEyICAgICAgICAgICAgICBbUGFnZSAxNF0KDApJbnRlcm5ldC1EcmFm dCAgICAgICAgICAgICAgICAgIE9BdXRoIDIuMCAgICAgICAgICAgICAgICAgICAgICBKdW5lIDIw MTIKCgogICAgICB1c2VyLWFnZW50IGNhcGFiaWxpdGllcyB3aGVuIHJlcXVlc3RpbmcgYXV0aG9y aXphdGlvbi4KICAgbmF0aXZlIGFwcGxpY2F0aW9uCiAgICAgIEEgbmF0aXZlIGFwcGxpY2F0aW9u IGlzIGEgcHVibGljIGNsaWVudCBpbnN0YWxsZWQgYW5kIGV4ZWN1dGVkIG9uCiAgICAgIHRoZSBk ZXZpY2UgdXNlZCBieSB0aGUgcmVzb3VyY2Ugb3duZXIuICBQcm90b2NvbCBkYXRhIGFuZAogICAg ICBjcmVkZW50aWFscyBhcmUgYWNjZXNzaWJsZSB0byB0aGUgcmVzb3VyY2Ugb3duZXIuICBJdCBp cyBhc3N1bWVkCiAgICAgIHRoYXQgYW55IGNsaWVudCBhdXRoZW50aWNhdGlvbiBjcmVkZW50aWFs cyBpbmNsdWRlZCBpbiB0aGUKICAgICAgYXBwbGljYXRpb24gY2FuIGJlIGV4dHJhY3RlZC4gIE9u IHRoZSBvdGhlciBoYW5kLCBkeW5hbWljYWxseQogICAgICBpc3N1ZWQgY3JlZGVudGlhbHMgc3Vj aCBhcyBhY2Nlc3MgdG9rZW5zIG9yIHJlZnJlc2ggdG9rZW5zIGNhbgogICAgICByZWNlaXZlIGFu IGFjY2VwdGFibGUgbGV2ZWwgb2YgcHJvdGVjdGlvbi4gIEF0IGEgbWluaW11bSwgdGhlc2UKICAg ICAgY3JlZGVudGlhbHMgYXJlIHByb3RlY3RlZCBmcm9tIGhvc3RpbGUgc2VydmVycyB3aXRoIHdo aWNoIHRoZQogICAgICBhcHBsaWNhdGlvbiBtYXkgaW50ZXJhY3Qgd2l0aC4gIE9uIHNvbWUgcGxh dGZvcm1zIHRoZXNlCiAgICAgIGNyZWRlbnRpYWxzIG1pZ2h0IGJlIHByb3RlY3RlZCBmcm9tIG90 aGVyIGFwcGxpY2F0aW9ucyByZXNpZGluZyBvbgogICAgICB0aGUgc2FtZSBkZXZpY2UuCgoyLjIu ICBDbGllbnQgSWRlbnRpZmllcgoKICAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGlzc3VlcyB0 aGUgcmVnaXN0ZXJlZCBjbGllbnQgYSBjbGllbnQKICAgaWRlbnRpZmllciAtIGEgdW5pcXVlIHN0 cmluZyByZXByZXNlbnRpbmcgdGhlIHJlZ2lzdHJhdGlvbgogICBpbmZvcm1hdGlvbiBwcm92aWRl ZCBieSB0aGUgY2xpZW50LiAgVGhlIGNsaWVudCBpZGVudGlmaWVyIGlzIG5vdCBhCiAgIHNlY3Jl dDsgaXQgaXMgZXhwb3NlZCB0byB0aGUgcmVzb3VyY2Ugb3duZXIsIGFuZCBNVVNUIE5PVCBiZSB1 c2VkCiAgIGFsb25lIGZvciBjbGllbnQgYXV0aGVudGljYXRpb24uICBUaGUgY2xpZW50IGlkZW50 aWZpZXIgaXMgdW5pcXVlIHRvCiAgIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlci4KCiAgIFRoZSBj bGllbnQgaWRlbnRpZmllciBzdHJpbmcgc2l6ZSBpcyBsZWZ0IHVuZGVmaW5lZCBieSB0aGlzCiAg IHNwZWNpZmljYXRpb24uICBUaGUgY2xpZW50IHNob3VsZCBhdm9pZCBtYWtpbmcgYXNzdW1wdGlv bnMgYWJvdXQgdGhlCiAgIGlkZW50aWZpZXIgc2l6ZS4gIFRoZSBhdXRob3JpemF0aW9uIHNlcnZl ciBTSE9VTEQgZG9jdW1lbnQgdGhlIHNpemUKICAgb2YgYW55IGlkZW50aWZpZXIgaXQgaXNzdWVz LgoKMi4zLiAgQ2xpZW50IEF1dGhlbnRpY2F0aW9uCgogICBJZiB0aGUgY2xpZW50IHR5cGUgaXMg Y29uZmlkZW50aWFsLCB0aGUgY2xpZW50IGFuZCBhdXRob3JpemF0aW9uCiAgIHNlcnZlciBlc3Rh Ymxpc2ggYSBjbGllbnQgYXV0aGVudGljYXRpb24gbWV0aG9kIHN1aXRhYmxlIGZvciB0aGUKICAg c2VjdXJpdHkgcmVxdWlyZW1lbnRzIG9mIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlci4gIFRoZSBh dXRob3JpemF0aW9uCiAgIHNlcnZlciBNQVkgYWNjZXB0IGFueSBmb3JtIG9mIGNsaWVudCBhdXRo ZW50aWNhdGlvbiBtZWV0aW5nIGl0cwogICBzZWN1cml0eSByZXF1aXJlbWVudHMuCgogICBDb25m aWRlbnRpYWwgY2xpZW50cyBhcmUgdHlwaWNhbGx5IGlzc3VlZCAob3IgZXN0YWJsaXNoKSBhIHNl dCBvZgogICBjbGllbnQgY3JlZGVudGlhbHMgdXNlZCBmb3IgYXV0aGVudGljYXRpbmcgd2l0aCB0 aGUgYXV0aG9yaXphdGlvbgogICBzZXJ2ZXIgKGUuZy4gcGFzc3dvcmQsIHB1YmxpYy9wcml2YXRl IGtleSBwYWlyKS4KCiAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBNQVkgZXN0YWJsaXNoIGEg Y2xpZW50IGF1dGhlbnRpY2F0aW9uIG1ldGhvZAogICB3aXRoIHB1YmxpYyBjbGllbnRzLiAgSG93 ZXZlciwgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIE1VU1QgTk9UIHJlbHkKICAgb24gcHVibGlj IGNsaWVudCBhdXRoZW50aWNhdGlvbiBmb3IgdGhlIHB1cnBvc2Ugb2YgaWRlbnRpZnlpbmcgdGhl CiAgIGNsaWVudC4KCiAgIFRoZSBjbGllbnQgTVVTVCBOT1QgdXNlIG1vcmUgdGhhbiBvbmUgYXV0 aGVudGljYXRpb24gbWV0aG9kIGluIGVhY2gKICAgcmVxdWVzdC4KCgoKCkhhbW1lciwgZXQgYWwu ICAgICAgICAgIEV4cGlyZXMgRGVjZW1iZXIgMTAsIDIwMTIgICAgICAgICAgICAgIFtQYWdlIDE1 XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgT0F1dGggMi4wICAgICAgICAgICAg ICAgICAgICAgIEp1bmUgMjAxMgoKCjIuMy4xLiAgQ2xpZW50IFBhc3N3b3JkCgogICBDbGllbnRz IGluIHBvc3Nlc3Npb24gb2YgYSBjbGllbnQgcGFzc3dvcmQgTUFZIHVzZSB0aGUgSFRUUCBCYXNp YwogICBhdXRoZW50aWNhdGlvbiBzY2hlbWUgYXMgZGVmaW5lZCBpbiBbUkZDMjYxN10gdG8gYXV0 aGVudGljYXRlIHdpdGgKICAgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLiAgVGhlIGNsaWVudCBp ZGVudGlmaWVyIGlzIHVzZWQgYXMgdGhlCiAgIHVzZXJuYW1lLCBhbmQgdGhlIGNsaWVudCBwYXNz d29yZCBpcyB1c2VkIGFzIHRoZSBwYXNzd29yZC4gIFRoZQogICBhdXRob3JpemF0aW9uIHNlcnZl ciBNVVNUIHN1cHBvcnQgdGhlIEhUVFAgQmFzaWMgYXV0aGVudGljYXRpb24KICAgc2NoZW1lIGZv ciBhdXRoZW50aWNhdGluZyBjbGllbnRzIHdoaWNoIHdlcmUgaXNzdWVkIGEgY2xpZW50CiAgIHBh c3N3b3JkLgoKICAgRm9yIGV4YW1wbGUgKGV4dHJhIGxpbmUgYnJlYWtzIGFyZSBmb3IgZGlzcGxh eSBwdXJwb3NlcyBvbmx5KToKCgogICAgIEF1dGhvcml6YXRpb246IEJhc2ljIGN6WkNhR1JTYTNG ME16bzNSbXBtY0RCYVFuSXhTM1JFVW1KdVpsWmtiVWwzCgoKICAgQWx0ZXJuYXRpdmVseSwgdGhl IGF1dGhvcml6YXRpb24gc2VydmVyIE1BWSBzdXBwb3J0IGluY2x1ZGluZyB0aGUKICAgY2xpZW50 IGNyZWRlbnRpYWxzIGluIHRoZSByZXF1ZXN0IGJvZHkgdXNpbmcgdGhlIGZvbGxvd2luZwogICBw YXJhbWV0ZXJzOgoKICAgY2xpZW50X2lkCiAgICAgICAgIFJFUVVJUkVELiAgVGhlIGNsaWVudCBp ZGVudGlmaWVyIGlzc3VlZCB0byB0aGUgY2xpZW50IGR1cmluZwogICAgICAgICB0aGUgcmVnaXN0 cmF0aW9uIHByb2Nlc3MgZGVzY3JpYmVkIGJ5IFNlY3Rpb24gMi4yLgogICBjbGllbnRfc2VjcmV0 CiAgICAgICAgIFJFUVVJUkVELiAgVGhlIGNsaWVudCBzZWNyZXQuICBUaGUgY2xpZW50IE1BWSBv bWl0IHRoZQogICAgICAgICBwYXJhbWV0ZXIgaWYgdGhlIGNsaWVudCBzZWNyZXQgaXMgYW4gZW1w dHkgc3RyaW5nLgoKICAgSW5jbHVkaW5nIHRoZSBjbGllbnQgY3JlZGVudGlhbHMgaW4gdGhlIHJl cXVlc3QgYm9keSB1c2luZyB0aGUgdHdvCiAgIHBhcmFtZXRlcnMgaXMgTk9UIFJFQ09NTUVOREVE LCBhbmQgU0hPVUxEIGJlIGxpbWl0ZWQgdG8gY2xpZW50cwogICB1bmFibGUgdG8gZGlyZWN0bHkg dXRpbGl6ZSB0aGUgSFRUUCBCYXNpYyBhdXRoZW50aWNhdGlvbiBzY2hlbWUgKG9yCiAgIG90aGVy IHBhc3N3b3JkLWJhc2VkIEhUVFAgYXV0aGVudGljYXRpb24gc2NoZW1lcykuICBUaGUgcGFyYW1l dGVycwogICBjYW4gb25seSBiZSB0cmFuc21pdHRlZCBpbiB0aGUgcmVxdWVzdCBib2R5IGFuZCBN VVNUIE5PVCBiZSBpbmNsdWRlZAogICBpbiB0aGUgcmVxdWVzdCBVUkkuCgogICBGb3IgZXhhbXBs ZSwgcmVxdWVzdGluZyB0byByZWZyZXNoIGFuIGFjY2VzcyB0b2tlbiAoU2VjdGlvbiA2KSB1c2lu ZwogICB0aGUgYm9keSBwYXJhbWV0ZXJzIChleHRyYSBsaW5lIGJyZWFrcyBhcmUgZm9yIGRpc3Bs YXkgcHVycG9zZXMKICAgb25seSk6CgoKICAgICBQT1NUIC90b2tlbiBIVFRQLzEuMQogICAgIEhv c3Q6IHNlcnZlci5leGFtcGxlLmNvbQogICAgIENvbnRlbnQtVHlwZTogYXBwbGljYXRpb24veC13 d3ctZm9ybS11cmxlbmNvZGVkO2NoYXJzZXQ9VVRGLTgKCiAgICAgZ3JhbnRfdHlwZT1yZWZyZXNo X3Rva2VuJnJlZnJlc2hfdG9rZW49dEd6djNKT2tGMFhHNVF4MlRsS1dJQQogICAgICZjbGllbnRf aWQ9czZCaGRSa3F0MyZjbGllbnRfc2VjcmV0PTdGamZwMFpCcjFLdERSYm5mVmRtSXcKCgogICBU aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVTVCByZXF1aXJlIHRoZSB1c2Ugb2YgVExTIGFzIGRl c2NyaWJlZCBpbgoKCgpIYW1tZXIsIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIERlY2VtYmVyIDEw LCAyMDEyICAgICAgICAgICAgICBbUGFnZSAxNl0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAg ICAgICAgIE9BdXRoIDIuMCAgICAgICAgICAgICAgICAgICAgICBKdW5lIDIwMTIKCgogICBTZWN0 aW9uIDEuNiB3aGVuIHNlbmRpbmcgcmVxdWVzdHMgdXNpbmcgcGFzc3dvcmQgYXV0aGVudGljYXRp b24uCgogICBTaW5jZSB0aGlzIGNsaWVudCBhdXRoZW50aWNhdGlvbiBtZXRob2QgaW52b2x2ZXMg YSBwYXNzd29yZCwgdGhlCiAgIGF1dGhvcml6YXRpb24gc2VydmVyIE1VU1QgcHJvdGVjdCBhbnkg ZW5kcG9pbnQgdXRpbGl6aW5nIGl0IGFnYWluc3QKICAgYnJ1dGUgZm9yY2UgYXR0YWNrcy4KCjIu My4yLiAgT3RoZXIgQXV0aGVudGljYXRpb24gTWV0aG9kcwoKICAgVGhlIGF1dGhvcml6YXRpb24g c2VydmVyIE1BWSBzdXBwb3J0IGFueSBzdWl0YWJsZSBIVFRQIGF1dGhlbnRpY2F0aW9uCiAgIHNj aGVtZSBtYXRjaGluZyBpdHMgc2VjdXJpdHkgcmVxdWlyZW1lbnRzLiAgV2hlbiB1c2luZyBvdGhl cgogICBhdXRoZW50aWNhdGlvbiBtZXRob2RzLCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVT VCBkZWZpbmUgYQogICBtYXBwaW5nIGJldHdlZW4gdGhlIGNsaWVudCBpZGVudGlmaWVyIChyZWdp c3RyYXRpb24gcmVjb3JkKSBhbmQKICAgYXV0aGVudGljYXRpb24gc2NoZW1lLgoKMi40LiAgVW5y ZWdpc3RlcmVkIENsaWVudHMKCiAgIFRoaXMgc3BlY2lmaWNhdGlvbiBkb2VzIG5vdCBleGNsdWRl IHRoZSB1c2Ugb2YgdW5yZWdpc3RlcmVkIGNsaWVudHMuCiAgIEhvd2V2ZXIsIHRoZSB1c2Ugd2l0 aCBzdWNoIGNsaWVudHMgaXMgYmV5b25kIHRoZSBzY29wZSBvZiB0aGlzCiAgIHNwZWNpZmljYXRp b24sIGFuZCByZXF1aXJlcyBhZGRpdGlvbmFsIHNlY3VyaXR5IGFuYWx5c2lzIGFuZCByZXZpZXcK ICAgb2YgaXRzIGludGVyb3BlcmFiaWxpdHkgaW1wYWN0LgoKCjMuICBQcm90b2NvbCBFbmRwb2lu dHMKCiAgIFRoZSBhdXRob3JpemF0aW9uIHByb2Nlc3MgdXRpbGl6ZXMgdHdvIGF1dGhvcml6YXRp b24gc2VydmVyIGVuZHBvaW50cwogICAoSFRUUCByZXNvdXJjZXMpOgoKICAgbyAgQXV0aG9yaXph dGlvbiBlbmRwb2ludCAtIHVzZWQgYnkgdGhlIGNsaWVudCB0byBvYnRhaW4KICAgICAgYXV0aG9y aXphdGlvbiBmcm9tIHRoZSByZXNvdXJjZSBvd25lciB2aWEgdXNlci1hZ2VudCByZWRpcmVjdGlv bi4KICAgbyAgVG9rZW4gZW5kcG9pbnQgLSB1c2VkIGJ5IHRoZSBjbGllbnQgdG8gZXhjaGFuZ2Ug YW4gYXV0aG9yaXphdGlvbgogICAgICBncmFudCBmb3IgYW4gYWNjZXNzIHRva2VuLCB0eXBpY2Fs bHkgd2l0aCBjbGllbnQgYXV0aGVudGljYXRpb24uCgogICBBcyB3ZWxsIGFzIG9uZSBjbGllbnQg ZW5kcG9pbnQ6CgogICBvICBSZWRpcmVjdGlvbiBlbmRwb2ludCAtIHVzZWQgYnkgdGhlIGF1dGhv cml6YXRpb24gc2VydmVyIHRvIHJldHVybgogICAgICBhdXRob3JpemF0aW9uIGNyZWRlbnRpYWxz IHJlc3BvbnNlcyB0byB0aGUgY2xpZW50IHZpYSB0aGUgcmVzb3VyY2UKICAgICAgb3duZXIgdXNl ci1hZ2VudC4KCiAgIE5vdCBldmVyeSBhdXRob3JpemF0aW9uIGdyYW50IHR5cGUgdXRpbGl6ZXMg Ym90aCBlbmRwb2ludHMuCiAgIEV4dGVuc2lvbiBncmFudCB0eXBlcyBNQVkgZGVmaW5lIGFkZGl0 aW9uYWwgZW5kcG9pbnRzIGFzIG5lZWRlZC4KCjMuMS4gIEF1dGhvcml6YXRpb24gRW5kcG9pbnQK CiAgIFRoZSBhdXRob3JpemF0aW9uIGVuZHBvaW50IGlzIHVzZWQgdG8gaW50ZXJhY3Qgd2l0aCB0 aGUgcmVzb3VyY2UKICAgb3duZXIgYW5kIG9idGFpbiBhbiBhdXRob3JpemF0aW9uIGdyYW50LiAg VGhlIGF1dGhvcml6YXRpb24gc2VydmVyCiAgIE1VU1QgZmlyc3QgdmVyaWZ5IHRoZSBpZGVudGl0 eSBvZiB0aGUgcmVzb3VyY2Ugb3duZXIuICBUaGUgd2F5IGluCiAgIHdoaWNoIHRoZSBhdXRob3Jp emF0aW9uIHNlcnZlciBhdXRoZW50aWNhdGVzIHRoZSByZXNvdXJjZSBvd25lciAoZS5nLgogICB1 c2VybmFtZSBhbmQgcGFzc3dvcmQgbG9naW4sIHNlc3Npb24gY29va2llcykgaXMgYmV5b25kIHRo ZSBzY29wZSBvZgoKCgpIYW1tZXIsIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIERlY2VtYmVyIDEw LCAyMDEyICAgICAgICAgICAgICBbUGFnZSAxN10KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAg ICAgICAgIE9BdXRoIDIuMCAgICAgICAgICAgICAgICAgICAgICBKdW5lIDIwMTIKCgogICB0aGlz IHNwZWNpZmljYXRpb24uCgogICBUaGUgbWVhbnMgdGhyb3VnaCB3aGljaCB0aGUgY2xpZW50IG9i dGFpbnMgdGhlIGxvY2F0aW9uIG9mIHRoZQogICBhdXRob3JpemF0aW9uIGVuZHBvaW50IGFyZSBi ZXlvbmQgdGhlIHNjb3BlIG9mIHRoaXMgc3BlY2lmaWNhdGlvbiwKICAgYnV0IHRoZSBsb2NhdGlv biBpcyB0eXBpY2FsbHkgcHJvdmlkZWQgaW4gdGhlIHNlcnZpY2UgZG9jdW1lbnRhdGlvbi4KCiAg IFRoZSBlbmRwb2ludCBVUkkgTUFZIGluY2x1ZGUgYW4gImFwcGxpY2F0aW9uL3gtd3d3LWZvcm0t dXJsZW5jb2RlZCIKICAgZm9ybWF0dGVkIChbVzNDLlJFQy1odG1sNDAxLTE5OTkxMjI0XSkgcXVl cnkgY29tcG9uZW50IChbUkZDMzk4Nl0KICAgc2VjdGlvbiAzLjQpLCB3aGljaCBNVVNUIGJlIHJl dGFpbmVkIHdoZW4gYWRkaW5nIGFkZGl0aW9uYWwgcXVlcnkKICAgcGFyYW1ldGVycy4gIFRoZSBl bmRwb2ludCBVUkkgTVVTVCBOT1QgaW5jbHVkZSBhIGZyYWdtZW50IGNvbXBvbmVudC4KCiAgIFNp bmNlIHJlcXVlc3RzIHRvIHRoZSBhdXRob3JpemF0aW9uIGVuZHBvaW50IHJlc3VsdCBpbiB1c2Vy CiAgIGF1dGhlbnRpY2F0aW9uIGFuZCB0aGUgdHJhbnNtaXNzaW9uIG9mIGNsZWFyLXRleHQgY3Jl ZGVudGlhbHMgKGluIHRoZQogICBIVFRQIHJlc3BvbnNlKSwgdGhlIGF1dGhvcml6YXRpb24gc2Vy dmVyIE1VU1QgcmVxdWlyZSB0aGUgdXNlIG9mIFRMUwogICBhcyBkZXNjcmliZWQgaW4gU2VjdGlv biAxLjYgd2hlbiBzZW5kaW5nIHJlcXVlc3RzIHRvIHRoZQogICBhdXRob3JpemF0aW9uIGVuZHBv aW50LgoKICAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIE1VU1Qgc3VwcG9ydCB0aGUgdXNlIG9m IHRoZSBIVFRQICJHRVQiCiAgIG1ldGhvZCBbUkZDMjYxNl0gZm9yIHRoZSBhdXRob3JpemF0aW9u IGVuZHBvaW50LCBhbmQgTUFZIHN1cHBvcnQgdGhlCiAgIHVzZSBvZiB0aGUgIlBPU1QiIG1ldGhv ZCBhcyB3ZWxsLgoKICAgUGFyYW1ldGVycyBzZW50IHdpdGhvdXQgYSB2YWx1ZSBNVVNUIGJlIHRy ZWF0ZWQgYXMgaWYgdGhleSB3ZXJlCiAgIG9taXR0ZWQgZnJvbSB0aGUgcmVxdWVzdC4gIFRoZSBh dXRob3JpemF0aW9uIHNlcnZlciBNVVNUIGlnbm9yZQogICB1bnJlY29nbml6ZWQgcmVxdWVzdCBw YXJhbWV0ZXJzLiAgUmVxdWVzdCBhbmQgcmVzcG9uc2UgcGFyYW1ldGVycwogICBNVVNUIE5PVCBi ZSBpbmNsdWRlZCBtb3JlIHRoYW4gb25jZS4KCjMuMS4xLiAgUmVzcG9uc2UgVHlwZQoKICAgVGhl IGF1dGhvcml6YXRpb24gZW5kcG9pbnQgaXMgdXNlZCBieSB0aGUgYXV0aG9yaXphdGlvbiBjb2Rl IGdyYW50CiAgIHR5cGUgYW5kIGltcGxpY2l0IGdyYW50IHR5cGUgZmxvd3MuICBUaGUgY2xpZW50 IGluZm9ybXMgdGhlCiAgIGF1dGhvcml6YXRpb24gc2VydmVyIG9mIHRoZSBkZXNpcmVkIGdyYW50 IHR5cGUgdXNpbmcgdGhlIGZvbGxvd2luZwogICBwYXJhbWV0ZXI6CgogICByZXNwb25zZV90eXBl CiAgICAgICAgIFJFUVVJUkVELiAgVGhlIHZhbHVlIE1VU1QgYmUgb25lIG9mICJjb2RlIiBmb3Ig cmVxdWVzdGluZyBhbgogICAgICAgICBhdXRob3JpemF0aW9uIGNvZGUgYXMgZGVzY3JpYmVkIGJ5 IFNlY3Rpb24gNC4xLjEsICJ0b2tlbiIgZm9yCiAgICAgICAgIHJlcXVlc3RpbmcgYW4gYWNjZXNz IHRva2VuIChpbXBsaWNpdCBncmFudCkgYXMgZGVzY3JpYmVkIGJ5CiAgICAgICAgIFNlY3Rpb24g NC4yLjEsIG9yIGEgcmVnaXN0ZXJlZCBleHRlbnNpb24gdmFsdWUgYXMgZGVzY3JpYmVkIGJ5CiAg ICAgICAgIFNlY3Rpb24gOC40LgoKICAgRXh0ZW5zaW9uIHJlc3BvbnNlIHR5cGVzIE1BWSBjb250 YWluIGEgc3BhY2UtZGVsaW1pdGVkICgleDIwKSBsaXN0IG9mCiAgIHZhbHVlcywgd2hlcmUgdGhl IG9yZGVyIG9mIHZhbHVlcyBkb2VzIG5vdCBtYXR0ZXIgKGUuZy4gcmVzcG9uc2UgdHlwZQogICAi YSBiIiBpcyB0aGUgc2FtZSBhcyAiYiBhIikuICBUaGUgbWVhbmluZyBvZiBzdWNoIGNvbXBvc2l0 ZSByZXNwb25zZQogICB0eXBlcyBpcyBkZWZpbmVkIGJ5IHRoZWlyIHJlc3BlY3RpdmUgc3BlY2lm aWNhdGlvbnMuCgogICBJZiBhbiBhdXRob3JpemF0aW9uIHJlcXVlc3QgaXMgbWlzc2luZyB0aGUg InJlc3BvbnNlX3R5cGUiIHBhcmFtZXRlciwKICAgb3IgaWYgdGhlIHJlc3BvbnNlIHR5cGUgaXMg bm90IHVuZGVyc3Rvb2QsIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlcgogICBNVVNUIHJldHVybiBh biBlcnJvciByZXNwb25zZSBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiA0LjEuMi4xLgoKCgpIYW1t ZXIsIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIERlY2VtYmVyIDEwLCAyMDEyICAgICAgICAgICAg ICBbUGFnZSAxOF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgIE9BdXRoIDIuMCAg ICAgICAgICAgICAgICAgICAgICBKdW5lIDIwMTIKCgozLjEuMi4gIFJlZGlyZWN0aW9uIEVuZHBv aW50CgogICBBZnRlciBjb21wbGV0aW5nIGl0cyBpbnRlcmFjdGlvbiB3aXRoIHRoZSByZXNvdXJj ZSBvd25lciwgdGhlCiAgIGF1dGhvcml6YXRpb24gc2VydmVyIGRpcmVjdHMgdGhlIHJlc291cmNl IG93bmVyJ3MgdXNlci1hZ2VudCBiYWNrIHRvCiAgIHRoZSBjbGllbnQuICBUaGUgYXV0aG9yaXph dGlvbiBzZXJ2ZXIgcmVkaXJlY3RzIHRoZSB1c2VyLWFnZW50IHRvIHRoZQogICBjbGllbnQncyBy ZWRpcmVjdGlvbiBlbmRwb2ludCBwcmV2aW91c2x5IGVzdGFibGlzaGVkIHdpdGggdGhlCiAgIGF1 dGhvcml6YXRpb24gc2VydmVyIGR1cmluZyB0aGUgY2xpZW50IHJlZ2lzdHJhdGlvbiBwcm9jZXNz IG9yIHdoZW4KICAgbWFraW5nIHRoZSBhdXRob3JpemF0aW9uIHJlcXVlc3QuCgogICBUaGUgcmVk aXJlY3Rpb24gZW5kcG9pbnQgVVJJIE1VU1QgYmUgYW4gYWJzb2x1dGUgVVJJIGFzIGRlZmluZWQg YnkKICAgW1JGQzM5ODZdIHNlY3Rpb24gNC4zLiAgVGhlIGVuZHBvaW50IFVSSSBNQVkgaW5jbHVk ZSBhbgogICAiYXBwbGljYXRpb24veC13d3ctZm9ybS11cmxlbmNvZGVkIiBmb3JtYXR0ZWQKICAg KFtXM0MuUkVDLWh0bWw0MDEtMTk5OTEyMjRdKSBxdWVyeSBjb21wb25lbnQgKFtSRkMzOTg2XSBz ZWN0aW9uIDMuNCksCiAgIHdoaWNoIE1VU1QgYmUgcmV0YWluZWQgd2hlbiBhZGRpbmcgYWRkaXRp b25hbCBxdWVyeSBwYXJhbWV0ZXJzLiAgVGhlCiAgIGVuZHBvaW50IFVSSSBNVVNUIE5PVCBpbmNs dWRlIGEgZnJhZ21lbnQgY29tcG9uZW50LgoKMy4xLjIuMS4gIEVuZHBvaW50IFJlcXVlc3QgQ29u ZmlkZW50aWFsaXR5CgogICBUaGUgcmVkaXJlY3Rpb24gZW5kcG9pbnQgU0hPVUxEIHJlcXVpcmUg dGhlIHVzZSBvZiBUTFMgYXMgZGVzY3JpYmVkCiAgIGluIFNlY3Rpb24gMS42IHdoZW4gdGhlIHJl cXVlc3RlZCByZXNwb25zZSB0eXBlIGlzICJjb2RlIiBvciAidG9rZW4iLAogICBvciB3aGVuIHRo ZSByZWRpcmVjdGlvbiByZXF1ZXN0IHdpbGwgcmVzdWx0IGluIHRoZSB0cmFuc21pc3Npb24gb2YK ICAgc2Vuc2l0aXZlIGNyZWRlbnRpYWxzIG92ZXIgYW4gb3BlbiBuZXR3b3JrLiAgVGhpcyBzcGVj aWZpY2F0aW9uIGRvZXMKICAgbm90IG1hbmRhdGUgdGhlIHVzZSBvZiBUTFMgYmVjYXVzZSBhdCB0 aGUgdGltZSBvZiB0aGlzIHdyaXRpbmcsCiAgIHJlcXVpcmluZyBjbGllbnRzIHRvIGRlcGxveSBU TFMgaXMgYSBzaWduaWZpY2FudCBodXJkbGUgZm9yIG1hbnkKICAgY2xpZW50IGRldmVsb3BlcnMu ICBJZiBUTFMgaXMgbm90IGF2YWlsYWJsZSwgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyCiAgIFNI T1VMRCB3YXJuIHRoZSByZXNvdXJjZSBvd25lciBhYm91dCB0aGUgaW5zZWN1cmUgZW5kcG9pbnQg cHJpb3IgdG8KICAgcmVkaXJlY3Rpb24gKGUuZy4gZGlzcGxheSBhIG1lc3NhZ2UgZHVyaW5nIHRo ZSBhdXRob3JpemF0aW9uCiAgIHJlcXVlc3QpLgoKICAgTGFjayBvZiB0cmFuc3BvcnQtbGF5ZXIg c2VjdXJpdHkgY2FuIGhhdmUgYSBzZXZlcmUgaW1wYWN0IG9uIHRoZQogICBzZWN1cml0eSBvZiB0 aGUgY2xpZW50IGFuZCB0aGUgcHJvdGVjdGVkIHJlc291cmNlcyBpdCBpcyBhdXRob3JpemVkCiAg IHRvIGFjY2Vzcy4gIFRoZSB1c2Ugb2YgdHJhbnNwb3J0LWxheWVyIHNlY3VyaXR5IGlzIHBhcnRp Y3VsYXJseQogICBjcml0aWNhbCB3aGVuIHRoZSBhdXRob3JpemF0aW9uIHByb2Nlc3MgaXMgdXNl ZCBhcyBhIGZvcm0gb2YKICAgZGVsZWdhdGVkIGVuZC11c2VyIGF1dGhlbnRpY2F0aW9uIGJ5IHRo ZSBjbGllbnQgKGUuZy4gdGhpcmQtcGFydHkKICAgc2lnbi1pbiBzZXJ2aWNlKS4KCjMuMS4yLjIu ICBSZWdpc3RyYXRpb24gUmVxdWlyZW1lbnRzCgogICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIg TVVTVCByZXF1aXJlIHRoZSBmb2xsb3dpbmcgY2xpZW50cyB0bwogICByZWdpc3RlciB0aGVpciBy ZWRpcmVjdGlvbiBlbmRwb2ludDoKCiAgIG8gIFB1YmxpYyBjbGllbnRzLgogICBvICBDb25maWRl bnRpYWwgY2xpZW50cyB1dGlsaXppbmcgdGhlIGltcGxpY2l0IGdyYW50IHR5cGUuCgogICBUaGUg YXV0aG9yaXphdGlvbiBzZXJ2ZXIgU0hPVUxEIHJlcXVpcmUgYWxsIGNsaWVudHMgdG8gcmVnaXN0 ZXIgdGhlaXIKICAgcmVkaXJlY3Rpb24gZW5kcG9pbnQgcHJpb3IgdG8gdXRpbGl6aW5nIHRoZSBh dXRob3JpemF0aW9uIGVuZHBvaW50LgoKICAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIFNIT1VM RCByZXF1aXJlIHRoZSBjbGllbnQgdG8gcHJvdmlkZSB0aGUKCgoKSGFtbWVyLCBldCBhbC4gICAg ICAgICAgRXhwaXJlcyBEZWNlbWJlciAxMCwgMjAxMiAgICAgICAgICAgICAgW1BhZ2UgMTldCgwK SW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICBPQXV0aCAyLjAgICAgICAgICAgICAgICAg ICAgICAgSnVuZSAyMDEyCgoKICAgY29tcGxldGUgcmVkaXJlY3Rpb24gVVJJICh0aGUgY2xpZW50 IE1BWSB1c2UgdGhlICJzdGF0ZSIgcmVxdWVzdAogICBwYXJhbWV0ZXIgdG8gYWNoaWV2ZSBwZXIt cmVxdWVzdCBjdXN0b21pemF0aW9uKS4gIElmIHJlcXVpcmluZyB0aGUKICAgcmVnaXN0cmF0aW9u IG9mIHRoZSBjb21wbGV0ZSByZWRpcmVjdGlvbiBVUkkgaXMgbm90IHBvc3NpYmxlLCB0aGUKICAg YXV0aG9yaXphdGlvbiBzZXJ2ZXIgU0hPVUxEIHJlcXVpcmUgdGhlIHJlZ2lzdHJhdGlvbiBvZiB0 aGUgVVJJCiAgIHNjaGVtZSwgYXV0aG9yaXR5LCBhbmQgcGF0aCAoYWxsb3dpbmcgdGhlIGNsaWVu dCB0byBkeW5hbWljYWxseSB2YXJ5CiAgIG9ubHkgdGhlIHF1ZXJ5IGNvbXBvbmVudCBvZiB0aGUg cmVkaXJlY3Rpb24gVVJJIHdoZW4gcmVxdWVzdGluZwogICBhdXRob3JpemF0aW9uKS4KCiAgIFRo ZSBhdXRob3JpemF0aW9uIHNlcnZlciBNQVkgYWxsb3cgdGhlIGNsaWVudCB0byByZWdpc3RlciBt dWx0aXBsZQogICByZWRpcmVjdGlvbiBlbmRwb2ludHMuCgogICBMYWNrIG9mIGEgcmVkaXJlY3Rp b24gVVJJIHJlZ2lzdHJhdGlvbiByZXF1aXJlbWVudCBjYW4gZW5hYmxlIGFuCiAgIGF0dGFja2Vy IHRvIHVzZSB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludCBhcyBvcGVuIHJlZGlyZWN0b3IgYXMK ICAgZGVzY3JpYmVkIGluIFNlY3Rpb24gMTAuMTUuCgozLjEuMi4zLiAgRHluYW1pYyBDb25maWd1 cmF0aW9uCgogICBJZiBtdWx0aXBsZSByZWRpcmVjdGlvbiBVUklzIGhhdmUgYmVlbiByZWdpc3Rl cmVkLCBpZiBvbmx5IHBhcnQgb2YKICAgdGhlIHJlZGlyZWN0aW9uIFVSSSBoYXMgYmVlbiByZWdp c3RlcmVkLCBvciBpZiBubyByZWRpcmVjdGlvbiBVUkkgaGFzCiAgIGJlZW4gcmVnaXN0ZXJlZCwg dGhlIGNsaWVudCBNVVNUIGluY2x1ZGUgYSByZWRpcmVjdGlvbiBVUkkgd2l0aCB0aGUKICAgYXV0 aG9yaXphdGlvbiByZXF1ZXN0IHVzaW5nIHRoZSAicmVkaXJlY3RfdXJpIiByZXF1ZXN0IHBhcmFt ZXRlci4KCiAgIFdoZW4gYSByZWRpcmVjdGlvbiBVUkkgaXMgaW5jbHVkZWQgaW4gYW4gYXV0aG9y aXphdGlvbiByZXF1ZXN0LCB0aGUKICAgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVTVCBjb21wYXJl IGFuZCBtYXRjaCB0aGUgdmFsdWUgcmVjZWl2ZWQKICAgYWdhaW5zdCBhdCBsZWFzdCBvbmUgb2Yg dGhlIHJlZ2lzdGVyZWQgcmVkaXJlY3Rpb24gVVJJcyAob3IgVVJJCiAgIGNvbXBvbmVudHMpIGFz IGRlZmluZWQgaW4gW1JGQzM5ODZdIHNlY3Rpb24gNiwgaWYgYW55IHJlZGlyZWN0aW9uCiAgIFVS SXMgd2VyZSByZWdpc3RlcmVkLiAgSWYgdGhlIGNsaWVudCByZWdpc3RyYXRpb24gaW5jbHVkZWQg dGhlIGZ1bGwKICAgcmVkaXJlY3Rpb24gVVJJLCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVT VCBjb21wYXJlIHRoZSB0d28gVVJJcwogICB1c2luZyBzaW1wbGUgc3RyaW5nIGNvbXBhcmlzb24g YXMgZGVmaW5lZCBpbiBbUkZDMzk4Nl0gc2VjdGlvbiA2LjIuMS4KCjMuMS4yLjQuICBJbnZhbGlk IEVuZHBvaW50CgogICBJZiBhbiBhdXRob3JpemF0aW9uIHJlcXVlc3QgZmFpbHMgdmFsaWRhdGlv biBkdWUgdG8gYSBtaXNzaW5nLAogICBpbnZhbGlkLCBvciBtaXNtYXRjaGluZyByZWRpcmVjdGlv biBVUkksIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlcgogICBTSE9VTEQgaW5mb3JtIHRoZSByZXNv dXJjZSBvd25lciBvZiB0aGUgZXJyb3IsIGFuZCBNVVNUIE5PVAogICBhdXRvbWF0aWNhbGx5IHJl ZGlyZWN0IHRoZSB1c2VyLWFnZW50IHRvIHRoZSBpbnZhbGlkIHJlZGlyZWN0aW9uIFVSSS4KCjMu MS4yLjUuICBFbmRwb2ludCBDb250ZW50CgogICBUaGUgcmVkaXJlY3Rpb24gcmVxdWVzdCB0byB0 aGUgY2xpZW50J3MgZW5kcG9pbnQgdHlwaWNhbGx5IHJlc3VsdHMgaW4KICAgYW4gSFRNTCBkb2N1 bWVudCByZXNwb25zZSwgcHJvY2Vzc2VkIGJ5IHRoZSB1c2VyLWFnZW50LiAgSWYgdGhlIEhUTUwK ICAgcmVzcG9uc2UgaXMgc2VydmVkIGRpcmVjdGx5IGFzIHRoZSByZXN1bHQgb2YgdGhlIHJlZGly ZWN0aW9uIHJlcXVlc3QsCiAgIGFueSBzY3JpcHQgaW5jbHVkZWQgaW4gdGhlIEhUTUwgZG9jdW1l bnQgd2lsbCBleGVjdXRlIHdpdGggZnVsbAogICBhY2Nlc3MgdG8gdGhlIHJlZGlyZWN0aW9uIFVS SSBhbmQgdGhlIGNyZWRlbnRpYWxzIGl0IGNvbnRhaW5zLgoKICAgVGhlIGNsaWVudCBTSE9VTEQg Tk9UIGluY2x1ZGUgYW55IHRoaXJkLXBhcnR5IHNjcmlwdHMgKGUuZy4gdGhpcmQtCiAgIHBhcnR5 IGFuYWx5dGljcywgc29jaWFsIHBsdWctaW5zLCBhZCBuZXR3b3JrcykgaW4gdGhlIHJlZGlyZWN0 aW9uCiAgIGVuZHBvaW50IHJlc3BvbnNlLiAgSW5zdGVhZCwgaXQgU0hPVUxEIGV4dHJhY3QgdGhl IGNyZWRlbnRpYWxzIGZyb20KCgoKSGFtbWVyLCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBEZWNl bWJlciAxMCwgMjAxMiAgICAgICAgICAgICAgW1BhZ2UgMjBdCgwKSW50ZXJuZXQtRHJhZnQgICAg ICAgICAgICAgICAgICBPQXV0aCAyLjAgICAgICAgICAgICAgICAgICAgICAgSnVuZSAyMDEyCgoK ICAgdGhlIFVSSSBhbmQgcmVkaXJlY3QgdGhlIHVzZXItYWdlbnQgYWdhaW4gdG8gYW5vdGhlciBl bmRwb2ludCB3aXRob3V0CiAgIGV4cG9zaW5nIHRoZSBjcmVkZW50aWFscyAoaW4gdGhlIFVSSSBv ciBlbHNld2hlcmUpLiAgSWYgdGhpcmQtcGFydHkKICAgc2NyaXB0cyBhcmUgaW5jbHVkZWQsIHRo ZSBjbGllbnQgTVVTVCBlbnN1cmUgdGhhdCBpdHMgb3duIHNjcmlwdHMKICAgKHVzZWQgdG8gZXh0 cmFjdCBhbmQgcmVtb3ZlIHRoZSBjcmVkZW50aWFscyBmcm9tIHRoZSBVUkkpIHdpbGwKICAgZXhl Y3V0ZSBmaXJzdC4KCjMuMi4gIFRva2VuIEVuZHBvaW50CgogICBUaGUgdG9rZW4gZW5kcG9pbnQg aXMgdXNlZCBieSB0aGUgY2xpZW50IHRvIG9idGFpbiBhbiBhY2Nlc3MgdG9rZW4gYnkKICAgcHJl c2VudGluZyBpdHMgYXV0aG9yaXphdGlvbiBncmFudCBvciByZWZyZXNoIHRva2VuLiAgVGhlIHRv a2VuCiAgIGVuZHBvaW50IGlzIHVzZWQgd2l0aCBldmVyeSBhdXRob3JpemF0aW9uIGdyYW50IGV4 Y2VwdCBmb3IgdGhlCiAgIGltcGxpY2l0IGdyYW50IHR5cGUgKHNpbmNlIGFuIGFjY2VzcyB0b2tl biBpcyBpc3N1ZWQgZGlyZWN0bHkpLgoKICAgVGhlIG1lYW5zIHRocm91Z2ggd2hpY2ggdGhlIGNs aWVudCBvYnRhaW5zIHRoZSBsb2NhdGlvbiBvZiB0aGUgdG9rZW4KICAgZW5kcG9pbnQgYXJlIGJl eW9uZCB0aGUgc2NvcGUgb2YgdGhpcyBzcGVjaWZpY2F0aW9uIGJ1dCBpcyB0eXBpY2FsbHkKICAg cHJvdmlkZWQgaW4gdGhlIHNlcnZpY2UgZG9jdW1lbnRhdGlvbi4KCiAgIFRoZSBlbmRwb2ludCBV UkkgTUFZIGluY2x1ZGUgYW4gImFwcGxpY2F0aW9uL3gtd3d3LWZvcm0tdXJsZW5jb2RlZCIKICAg Zm9ybWF0dGVkIChbVzNDLlJFQy1odG1sNDAxLTE5OTkxMjI0XSkgcXVlcnkgY29tcG9uZW50IChb UkZDMzk4Nl0KICAgc2VjdGlvbiAzLjQpLCB3aGljaCBNVVNUIGJlIHJldGFpbmVkIHdoZW4gYWRk aW5nIGFkZGl0aW9uYWwgcXVlcnkKICAgcGFyYW1ldGVycy4gIFRoZSBlbmRwb2ludCBVUkkgTVVT VCBOT1QgaW5jbHVkZSBhIGZyYWdtZW50IGNvbXBvbmVudC4KCiAgIFNpbmNlIHJlcXVlc3RzIHRv IHRoZSB0b2tlbiBlbmRwb2ludCByZXN1bHQgaW4gdGhlIHRyYW5zbWlzc2lvbiBvZgogICBjbGVh ci10ZXh0IGNyZWRlbnRpYWxzIChpbiB0aGUgSFRUUCByZXF1ZXN0IGFuZCByZXNwb25zZSksIHRo ZQogICBhdXRob3JpemF0aW9uIHNlcnZlciBNVVNUIHJlcXVpcmUgdGhlIHVzZSBvZiBUTFMgYXMg ZGVzY3JpYmVkIGluCiAgIFNlY3Rpb24gMS42IHdoZW4gc2VuZGluZyByZXF1ZXN0cyB0byB0aGUg dG9rZW4gZW5kcG9pbnQuCgogICBUaGUgY2xpZW50IE1VU1QgdXNlIHRoZSBIVFRQICJQT1NUIiBt ZXRob2Qgd2hlbiBtYWtpbmcgYWNjZXNzIHRva2VuCiAgIHJlcXVlc3RzLgoKICAgUGFyYW1ldGVy cyBzZW50IHdpdGhvdXQgYSB2YWx1ZSBNVVNUIGJlIHRyZWF0ZWQgYXMgaWYgdGhleSB3ZXJlCiAg IG9taXR0ZWQgZnJvbSB0aGUgcmVxdWVzdC4gIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBNVVNU IGlnbm9yZQogICB1bnJlY29nbml6ZWQgcmVxdWVzdCBwYXJhbWV0ZXJzLiAgUmVxdWVzdCBhbmQg cmVzcG9uc2UgcGFyYW1ldGVycwogICBNVVNUIE5PVCBiZSBpbmNsdWRlZCBtb3JlIHRoYW4gb25j ZS4KCjMuMi4xLiAgQ2xpZW50IEF1dGhlbnRpY2F0aW9uCgogICBDb25maWRlbnRpYWwgY2xpZW50 cyBvciBvdGhlciBjbGllbnRzIGlzc3VlZCBjbGllbnQgY3JlZGVudGlhbHMgTVVTVAogICBhdXRo ZW50aWNhdGUgd2l0aCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYXMgZGVzY3JpYmVkIGluCiAg IFNlY3Rpb24gMi4zIHdoZW4gbWFraW5nIHJlcXVlc3RzIHRvIHRoZSB0b2tlbiBlbmRwb2ludC4g IENsaWVudAogICBhdXRoZW50aWNhdGlvbiBpcyB1c2VkIGZvcjoKCiAgIG8gIEVuZm9yY2luZyB0 aGUgYmluZGluZyBvZiByZWZyZXNoIHRva2VucyBhbmQgYXV0aG9yaXphdGlvbiBjb2RlcyB0bwog ICAgICB0aGUgY2xpZW50IHRoZXkgd2VyZSBpc3N1ZWQgdG8uICBDbGllbnQgYXV0aGVudGljYXRp b24gaXMgY3JpdGljYWwKICAgICAgd2hlbiBhbiBhdXRob3JpemF0aW9uIGNvZGUgaXMgdHJhbnNt aXR0ZWQgdG8gdGhlIHJlZGlyZWN0aW9uCiAgICAgIGVuZHBvaW50IG92ZXIgYW4gaW5zZWN1cmUg Y2hhbm5lbCwgb3Igd2hlbiB0aGUgcmVkaXJlY3Rpb24gVVJJIGhhcwogICAgICBub3QgYmVlbiBy ZWdpc3RlcmVkIGluIGZ1bGwuCgoKCgpIYW1tZXIsIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIERl Y2VtYmVyIDEwLCAyMDEyICAgICAgICAgICAgICBbUGFnZSAyMV0KDApJbnRlcm5ldC1EcmFmdCAg ICAgICAgICAgICAgICAgIE9BdXRoIDIuMCAgICAgICAgICAgICAgICAgICAgICBKdW5lIDIwMTIK CgogICBvICBSZWNvdmVyaW5nIGZyb20gYSBjb21wcm9taXNlZCBjbGllbnQgYnkgZGlzYWJsaW5n IHRoZSBjbGllbnQgb3IKICAgICAgY2hhbmdpbmcgaXRzIGNyZWRlbnRpYWxzLCB0aHVzIHByZXZl bnRpbmcgYW4gYXR0YWNrZXIgZnJvbSBhYnVzaW5nCiAgICAgIHN0b2xlbiByZWZyZXNoIHRva2Vu cy4gIENoYW5naW5nIGEgc2luZ2xlIHNldCBvZiBjbGllbnQKICAgICAgY3JlZGVudGlhbHMgaXMg c2lnbmlmaWNhbnRseSBmYXN0ZXIgdGhhbiByZXZva2luZyBhbiBlbnRpcmUgc2V0IG9mCiAgICAg IHJlZnJlc2ggdG9rZW5zLgogICBvICBJbXBsZW1lbnRpbmcgYXV0aGVudGljYXRpb24gbWFuYWdl bWVudCBiZXN0IHByYWN0aWNlcyB3aGljaAogICAgICByZXF1aXJlIHBlcmlvZGljIGNyZWRlbnRp YWwgcm90YXRpb24uICBSb3RhdGlvbiBvZiBhbiBlbnRpcmUgc2V0CiAgICAgIG9mIHJlZnJlc2gg dG9rZW5zIGNhbiBiZSBjaGFsbGVuZ2luZywgd2hpbGUgcm90YXRpb24gb2YgYSBzaW5nbGUKICAg ICAgc2V0IG9mIGNsaWVudCBjcmVkZW50aWFscyBpcyBzaWduaWZpY2FudGx5IGVhc2llci4KCiAg IEEgcHVibGljIGNsaWVudCB0aGF0IHdhcyBub3QgaXNzdWVkIGEgY2xpZW50IHBhc3N3b3JkIE1B WSB1c2UgdGhlCiAgICJjbGllbnRfaWQiIHJlcXVlc3QgcGFyYW1ldGVyIHRvIGlkZW50aWZ5IGl0 c2VsZiB3aGVuIHNlbmRpbmcKICAgcmVxdWVzdHMgdG8gdGhlIHRva2VuIGVuZHBvaW50IChlLmcu IGZvciB0aGUgcHVycG9zZSBvZiBwcm92aWRpbmcKICAgZW5kLXVzZXIgY29udGV4dCwgY2xpZW50 IHVzYWdlIHN0YXRpc3RpY3MpLgoKMy4zLiAgQWNjZXNzIFRva2VuIFNjb3BlCgogICBUaGUgYXV0 aG9yaXphdGlvbiBhbmQgdG9rZW4gZW5kcG9pbnRzIGFsbG93IHRoZSBjbGllbnQgdG8gc3BlY2lm eSB0aGUKICAgc2NvcGUgb2YgdGhlIGFjY2VzcyByZXF1ZXN0IHVzaW5nIHRoZSAic2NvcGUiIHJl cXVlc3QgcGFyYW1ldGVyLiAgSW4KICAgdHVybiwgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHVz ZXMgdGhlICJzY29wZSIgcmVzcG9uc2UgcGFyYW1ldGVyIHRvCiAgIGluZm9ybSB0aGUgY2xpZW50 IG9mIHRoZSBzY29wZSBvZiB0aGUgYWNjZXNzIHRva2VuIGlzc3VlZC4KCiAgIFRoZSB2YWx1ZSBv ZiB0aGUgc2NvcGUgcGFyYW1ldGVyIGlzIGV4cHJlc3NlZCBhcyBhIGxpc3Qgb2Ygc3BhY2UtCiAg IGRlbGltaXRlZCwgY2FzZSBzZW5zaXRpdmUgc3RyaW5ncy4gIFRoZSBzdHJpbmdzIGFyZSBkZWZp bmVkIGJ5IHRoZQogICBhdXRob3JpemF0aW9uIHNlcnZlci4gIElmIHRoZSB2YWx1ZSBjb250YWlu cyBtdWx0aXBsZSBzcGFjZS1kZWxpbWl0ZWQKICAgc3RyaW5ncywgdGhlaXIgb3JkZXIgZG9lcyBu b3QgbWF0dGVyLCBhbmQgZWFjaCBzdHJpbmcgYWRkcyBhbgogICBhZGRpdGlvbmFsIGFjY2VzcyBy YW5nZSB0byB0aGUgcmVxdWVzdGVkIHNjb3BlLgoKCiAgICAgc2NvcGUgICAgICAgPSBzY29wZS10 b2tlbiAqKCBTUCBzY29wZS10b2tlbiApCiAgICAgc2NvcGUtdG9rZW4gPSAxKiggJXgyMSAvICV4 MjMtNUIgLyAleDVELTdFICkKCgogICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTUFZIGZ1bGx5 IG9yIHBhcnRpYWxseSBpZ25vcmUgdGhlIHNjb3BlCiAgIHJlcXVlc3RlZCBieSB0aGUgY2xpZW50 IGJhc2VkIG9uIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBwb2xpY3kgb3IKICAgdGhlIHJlc291 cmNlIG93bmVyJ3MgaW5zdHJ1Y3Rpb25zLiAgSWYgdGhlIGlzc3VlZCBhY2Nlc3MgdG9rZW4gc2Nv cGUKICAgaXMgZGlmZmVyZW50IGZyb20gdGhlIG9uZSByZXF1ZXN0ZWQgYnkgdGhlIGNsaWVudCwg dGhlIGF1dGhvcml6YXRpb24KICAgc2VydmVyIE1VU1QgaW5jbHVkZSB0aGUgInNjb3BlIiByZXNw b25zZSBwYXJhbWV0ZXIgdG8gaW5mb3JtIHRoZQogICBjbGllbnQgb2YgdGhlIGFjdHVhbCBzY29w ZSBncmFudGVkLgoKICAgSWYgdGhlIGNsaWVudCBvbWl0cyB0aGUgc2NvcGUgcGFyYW1ldGVyIHdo ZW4gcmVxdWVzdGluZwogICBhdXRob3JpemF0aW9uLCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIg TVVTVCBlaXRoZXIgcHJvY2VzcyB0aGUKICAgcmVxdWVzdCB1c2luZyBhIHByZS1kZWZpbmVkIGRl ZmF1bHQgdmFsdWUsIG9yIGZhaWwgdGhlIHJlcXVlc3QKICAgaW5kaWNhdGluZyBhbiBpbnZhbGlk IHNjb3BlLiAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIFNIT1VMRAogICBkb2N1bWVudCBpdHMg c2NvcGUgcmVxdWlyZW1lbnRzIGFuZCBkZWZhdWx0IHZhbHVlIChpZiBkZWZpbmVkKS4KCgoKCgoK SGFtbWVyLCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBEZWNlbWJlciAxMCwgMjAxMiAgICAgICAg ICAgICAgW1BhZ2UgMjJdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICBPQXV0aCAy LjAgICAgICAgICAgICAgICAgICAgICAgSnVuZSAyMDEyCgoKNC4gIE9idGFpbmluZyBBdXRob3Jp emF0aW9uCgogICBUbyByZXF1ZXN0IGFuIGFjY2VzcyB0b2tlbiwgdGhlIGNsaWVudCBvYnRhaW5z IGF1dGhvcml6YXRpb24gZnJvbSB0aGUKICAgcmVzb3VyY2Ugb3duZXIuICBUaGUgYXV0aG9yaXph dGlvbiBpcyBleHByZXNzZWQgaW4gdGhlIGZvcm0gb2YgYW4KICAgYXV0aG9yaXphdGlvbiBncmFu dCB3aGljaCB0aGUgY2xpZW50IHVzZXMgdG8gcmVxdWVzdCB0aGUgYWNjZXNzCiAgIHRva2VuLiAg T0F1dGggZGVmaW5lcyBmb3VyIGdyYW50IHR5cGVzOiBhdXRob3JpemF0aW9uIGNvZGUsIGltcGxp Y2l0LAogICByZXNvdXJjZSBvd25lciBwYXNzd29yZCBjcmVkZW50aWFscywgYW5kIGNsaWVudCBj cmVkZW50aWFscy4gIEl0IGFsc28KICAgcHJvdmlkZXMgYW4gZXh0ZW5zaW9uIG1lY2hhbmlzbSBm b3IgZGVmaW5pbmcgYWRkaXRpb25hbCBncmFudCB0eXBlcy4KCjQuMS4gIEF1dGhvcml6YXRpb24g Q29kZSBHcmFudAoKICAgVGhlIGF1dGhvcml6YXRpb24gY29kZSBncmFudCB0eXBlIGlzIHVzZWQg dG8gb2J0YWluIGJvdGggYWNjZXNzCiAgIHRva2VucyBhbmQgcmVmcmVzaCB0b2tlbnMgYW5kIGlz IG9wdGltaXplZCBmb3IgY29uZmlkZW50aWFsIGNsaWVudHMuCiAgIEFzIGEgcmVkaXJlY3Rpb24t YmFzZWQgZmxvdywgdGhlIGNsaWVudCBtdXN0IGJlIGNhcGFibGUgb2YKICAgaW50ZXJhY3Rpbmcg d2l0aCB0aGUgcmVzb3VyY2Ugb3duZXIncyB1c2VyLWFnZW50ICh0eXBpY2FsbHkgYSB3ZWIKICAg YnJvd3NlcikgYW5kIGNhcGFibGUgb2YgcmVjZWl2aW5nIGluY29taW5nIHJlcXVlc3RzICh2aWEg cmVkaXJlY3Rpb24pCiAgIGZyb20gdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLgoKCiAgICAgKy0t LS0tLS0tLS0rCiAgICAgfCByZXNvdXJjZSB8CiAgICAgfCAgIG93bmVyICB8CiAgICAgfCAgICAg ICAgICB8CiAgICAgKy0tLS0tLS0tLS0rCiAgICAgICAgICBeCiAgICAgICAgICB8CiAgICAgICAg IChCKQogICAgICstLS0tfC0tLS0tKyAgICAgICAgICBDbGllbnQgSWRlbnRpZmllciAgICAgICst LS0tLS0tLS0tLS0tLS0rCiAgICAgfCAgICAgICAgIC0rLS0tLShBKS0tICYgUmVkaXJlY3Rpb24g VVJJIC0tLS0+fCAgICAgICAgICAgICAgIHwKICAgICB8ICBVc2VyLSAgIHwgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICB8IEF1dGhvcml6YXRpb24gfAogICAgIHwgIEFnZW50ICAtKy0t LS0oQiktLSBVc2VyIGF1dGhlbnRpY2F0ZXMgLS0tPnwgICAgIFNlcnZlciAgICB8CiAgICAgfCAg ICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAg IHwKICAgICB8ICAgICAgICAgLSstLS0tKEMpLS0gQXV0aG9yaXphdGlvbiBDb2RlIC0tLTx8ICAg ICAgICAgICAgICAgfAogICAgICstfC0tLS18LS0tKyAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICstLS0tLS0tLS0tLS0tLS0rCiAgICAgICB8ICAgIHwgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIF4gICAgICB2CiAgICAgIChBKSAgKEMpICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICB8CiAgICAgICB8ICAgIHwgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICB8CiAgICAgICBeICAgIHYg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICB8CiAgICAgKy0t LS0tLS0tLSsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICB8CiAg ICAgfCAgICAgICAgIHw+LS0tKEQpLS0gQXV0aG9yaXphdGlvbiBDb2RlIC0tLS0tLS0tLScgICAg ICB8CiAgICAgfCAgQ2xpZW50IHwgICAgICAgICAgJiBSZWRpcmVjdGlvbiBVUkkgICAgICAgICAg ICAgICAgICB8CiAgICAgfCAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICB8CiAgICAgfCAgICAgICAgIHw8LS0tKEUpLS0tLS0gQWNjZXNzIFRva2Vu IC0tLS0tLS0tLS0tLS0tLS0tLS0nCiAgICAgKy0tLS0tLS0tLSsgICAgICAgKHcvIE9wdGlvbmFs IFJlZnJlc2ggVG9rZW4pCgoKICAgTm90ZTogVGhlIGxpbmVzIGlsbHVzdHJhdGluZyBzdGVwcyBB LCBCLCBhbmQgQyBhcmUgYnJva2VuIGludG8gdHdvCiAgIHBhcnRzIGFzIHRoZXkgcGFzcyB0aHJv dWdoIHRoZSB1c2VyLWFnZW50LgoKCgpIYW1tZXIsIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIERl Y2VtYmVyIDEwLCAyMDEyICAgICAgICAgICAgICBbUGFnZSAyM10KDApJbnRlcm5ldC1EcmFmdCAg ICAgICAgICAgICAgICAgIE9BdXRoIDIuMCAgICAgICAgICAgICAgICAgICAgICBKdW5lIDIwMTIK CgogICAgICAgICAgICAgICAgICAgICBGaWd1cmUgMzogQXV0aG9yaXphdGlvbiBDb2RlIEZsb3cK CiAgIFRoZSBmbG93IGlsbHVzdHJhdGVkIGluIEZpZ3VyZSAzIGluY2x1ZGVzIHRoZSBmb2xsb3dp bmcgc3RlcHM6CgogICAoQSkgIFRoZSBjbGllbnQgaW5pdGlhdGVzIHRoZSBmbG93IGJ5IGRpcmVj dGluZyB0aGUgcmVzb3VyY2Ugb3duZXIncwogICAgICAgIHVzZXItYWdlbnQgdG8gdGhlIGF1dGhv cml6YXRpb24gZW5kcG9pbnQuICBUaGUgY2xpZW50IGluY2x1ZGVzCiAgICAgICAgaXRzIGNsaWVu dCBpZGVudGlmaWVyLCByZXF1ZXN0ZWQgc2NvcGUsIGxvY2FsIHN0YXRlLCBhbmQgYQogICAgICAg IHJlZGlyZWN0aW9uIFVSSSB0byB3aGljaCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgd2lsbCBz ZW5kIHRoZQogICAgICAgIHVzZXItYWdlbnQgYmFjayBvbmNlIGFjY2VzcyBpcyBncmFudGVkIChv ciBkZW5pZWQpLgogICAoQikgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBhdXRoZW50aWNhdGVz IHRoZSByZXNvdXJjZSBvd25lciAodmlhCiAgICAgICAgdGhlIHVzZXItYWdlbnQpIGFuZCBlc3Rh Ymxpc2hlcyB3aGV0aGVyIHRoZSByZXNvdXJjZSBvd25lcgogICAgICAgIGdyYW50cyBvciBkZW5p ZXMgdGhlIGNsaWVudCdzIGFjY2VzcyByZXF1ZXN0LgogICAoQykgIEFzc3VtaW5nIHRoZSByZXNv dXJjZSBvd25lciBncmFudHMgYWNjZXNzLCB0aGUgYXV0aG9yaXphdGlvbgogICAgICAgIHNlcnZl ciByZWRpcmVjdHMgdGhlIHVzZXItYWdlbnQgYmFjayB0byB0aGUgY2xpZW50IHVzaW5nIHRoZQog ICAgICAgIHJlZGlyZWN0aW9uIFVSSSBwcm92aWRlZCBlYXJsaWVyIChpbiB0aGUgcmVxdWVzdCBv ciBkdXJpbmcKICAgICAgICBjbGllbnQgcmVnaXN0cmF0aW9uKS4gIFRoZSByZWRpcmVjdGlvbiBV UkkgaW5jbHVkZXMgYW4KICAgICAgICBhdXRob3JpemF0aW9uIGNvZGUgYW5kIGFueSBsb2NhbCBz dGF0ZSBwcm92aWRlZCBieSB0aGUgY2xpZW50CiAgICAgICAgZWFybGllci4KICAgKEQpICBUaGUg Y2xpZW50IHJlcXVlc3RzIGFuIGFjY2VzcyB0b2tlbiBmcm9tIHRoZSBhdXRob3JpemF0aW9uCiAg ICAgICAgc2VydmVyJ3MgdG9rZW4gZW5kcG9pbnQgYnkgaW5jbHVkaW5nIHRoZSBhdXRob3JpemF0 aW9uIGNvZGUKICAgICAgICByZWNlaXZlZCBpbiB0aGUgcHJldmlvdXMgc3RlcC4gIFdoZW4gbWFr aW5nIHRoZSByZXF1ZXN0LCB0aGUKICAgICAgICBjbGllbnQgYXV0aGVudGljYXRlcyB3aXRoIHRo ZSBhdXRob3JpemF0aW9uIHNlcnZlci4gIFRoZSBjbGllbnQKICAgICAgICBpbmNsdWRlcyB0aGUg cmVkaXJlY3Rpb24gVVJJIHVzZWQgdG8gb2J0YWluIHRoZSBhdXRob3JpemF0aW9uCiAgICAgICAg Y29kZSBmb3IgdmVyaWZpY2F0aW9uLgogICAoRSkgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBh dXRoZW50aWNhdGVzIHRoZSBjbGllbnQsIHZhbGlkYXRlcyB0aGUKICAgICAgICBhdXRob3JpemF0 aW9uIGNvZGUsIGFuZCBlbnN1cmVzIHRoZSByZWRpcmVjdGlvbiBVUkkgcmVjZWl2ZWQKICAgICAg ICBtYXRjaGVzIHRoZSBVUkkgdXNlZCB0byByZWRpcmVjdCB0aGUgY2xpZW50IGluIHN0ZXAgKEMp LiAgSWYKICAgICAgICB2YWxpZCwgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHJlc3BvbmRzIGJh Y2sgd2l0aCBhbiBhY2Nlc3MKICAgICAgICB0b2tlbiBhbmQgb3B0aW9uYWxseSwgYSByZWZyZXNo IHRva2VuLgoKNC4xLjEuICBBdXRob3JpemF0aW9uIFJlcXVlc3QKCiAgIFRoZSBjbGllbnQgY29u c3RydWN0cyB0aGUgcmVxdWVzdCBVUkkgYnkgYWRkaW5nIHRoZSBmb2xsb3dpbmcKICAgcGFyYW1l dGVycyB0byB0aGUgcXVlcnkgY29tcG9uZW50IG9mIHRoZSBhdXRob3JpemF0aW9uIGVuZHBvaW50 IFVSSQogICB1c2luZyB0aGUgImFwcGxpY2F0aW9uL3gtd3d3LWZvcm0tdXJsZW5jb2RlZCIgZm9y bWF0IGFzIGRlZmluZWQgYnkKICAgW1czQy5SRUMtaHRtbDQwMS0xOTk5MTIyNF06CgogICByZXNw b25zZV90eXBlCiAgICAgICAgIFJFUVVJUkVELiAgVmFsdWUgTVVTVCBiZSBzZXQgdG8gImNvZGUi LgogICBjbGllbnRfaWQKICAgICAgICAgUkVRVUlSRUQuICBUaGUgY2xpZW50IGlkZW50aWZpZXIg YXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gMi4yLgogICByZWRpcmVjdF91cmkKICAgICAgICAgT1BU SU9OQUwuICBBcyBkZXNjcmliZWQgaW4gU2VjdGlvbiAzLjEuMi4KICAgc2NvcGUKICAgICAgICAg T1BUSU9OQUwuICBUaGUgc2NvcGUgb2YgdGhlIGFjY2VzcyByZXF1ZXN0IGFzIGRlc2NyaWJlZCBi eQogICAgICAgICBTZWN0aW9uIDMuMy4KCgoKCgpIYW1tZXIsIGV0IGFsLiAgICAgICAgICBFeHBp cmVzIERlY2VtYmVyIDEwLCAyMDEyICAgICAgICAgICAgICBbUGFnZSAyNF0KDApJbnRlcm5ldC1E cmFmdCAgICAgICAgICAgICAgICAgIE9BdXRoIDIuMCAgICAgICAgICAgICAgICAgICAgICBKdW5l IDIwMTIKCgogICBzdGF0ZQogICAgICAgICBSRUNPTU1FTkRFRC4gIEFuIG9wYXF1ZSB2YWx1ZSB1 c2VkIGJ5IHRoZSBjbGllbnQgdG8gbWFpbnRhaW4KICAgICAgICAgc3RhdGUgYmV0d2VlbiB0aGUg cmVxdWVzdCBhbmQgY2FsbGJhY2suICBUaGUgYXV0aG9yaXphdGlvbgogICAgICAgICBzZXJ2ZXIg aW5jbHVkZXMgdGhpcyB2YWx1ZSB3aGVuIHJlZGlyZWN0aW5nIHRoZSB1c2VyLWFnZW50IGJhY2sK ICAgICAgICAgdG8gdGhlIGNsaWVudC4gIFRoZSBwYXJhbWV0ZXIgU0hPVUxEIGJlIHVzZWQgZm9y IHByZXZlbnRpbmcKICAgICAgICAgY3Jvc3Mtc2l0ZSByZXF1ZXN0IGZvcmdlcnkgYXMgZGVzY3Jp YmVkIGluIFNlY3Rpb24gMTAuMTIuCgogICBUaGUgY2xpZW50IGRpcmVjdHMgdGhlIHJlc291cmNl IG93bmVyIHRvIHRoZSBjb25zdHJ1Y3RlZCBVUkkgdXNpbmcgYW4KICAgSFRUUCByZWRpcmVjdGlv biByZXNwb25zZSwgb3IgYnkgb3RoZXIgbWVhbnMgYXZhaWxhYmxlIHRvIGl0IHZpYSB0aGUKICAg dXNlci1hZ2VudC4KCiAgIEZvciBleGFtcGxlLCB0aGUgY2xpZW50IGRpcmVjdHMgdGhlIHVzZXIt YWdlbnQgdG8gbWFrZSB0aGUgZm9sbG93aW5nCiAgIEhUVFAgcmVxdWVzdCB1c2luZyBUTFMgKGV4 dHJhIGxpbmUgYnJlYWtzIGFyZSBmb3IgZGlzcGxheSBwdXJwb3NlcwogICBvbmx5KToKCgogICAg R0VUIC9hdXRob3JpemU/cmVzcG9uc2VfdHlwZT1jb2RlJmNsaWVudF9pZD1zNkJoZFJrcXQzJnN0 YXRlPXh5egogICAgICAgICZyZWRpcmVjdF91cmk9aHR0cHMlM0ElMkYlMkZjbGllbnQlMkVleGFt cGxlJTJFY29tJTJGY2IgSFRUUC8xLjEKICAgIEhvc3Q6IHNlcnZlci5leGFtcGxlLmNvbQoKCiAg IFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciB2YWxpZGF0ZXMgdGhlIHJlcXVlc3QgdG8gZW5zdXJl IGFsbCByZXF1aXJlZAogICBwYXJhbWV0ZXJzIGFyZSBwcmVzZW50IGFuZCB2YWxpZC4gIElmIHRo ZSByZXF1ZXN0IGlzIHZhbGlkLCB0aGUKICAgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYXV0aGVudGlj YXRlcyB0aGUgcmVzb3VyY2Ugb3duZXIgYW5kIG9idGFpbnMgYW4KICAgYXV0aG9yaXphdGlvbiBk ZWNpc2lvbiAoYnkgYXNraW5nIHRoZSByZXNvdXJjZSBvd25lciBvciBieQogICBlc3RhYmxpc2hp bmcgYXBwcm92YWwgdmlhIG90aGVyIG1lYW5zKS4KCiAgIFdoZW4gYSBkZWNpc2lvbiBpcyBlc3Rh Ymxpc2hlZCwgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGRpcmVjdHMgdGhlCiAgIHVzZXItYWdl bnQgdG8gdGhlIHByb3ZpZGVkIGNsaWVudCByZWRpcmVjdGlvbiBVUkkgdXNpbmcgYW4gSFRUUAog ICByZWRpcmVjdGlvbiByZXNwb25zZSwgb3IgYnkgb3RoZXIgbWVhbnMgYXZhaWxhYmxlIHRvIGl0 IHZpYSB0aGUgdXNlci0KICAgYWdlbnQuCgo0LjEuMi4gIEF1dGhvcml6YXRpb24gUmVzcG9uc2UK CiAgIElmIHRoZSByZXNvdXJjZSBvd25lciBncmFudHMgdGhlIGFjY2VzcyByZXF1ZXN0LCB0aGUg YXV0aG9yaXphdGlvbgogICBzZXJ2ZXIgaXNzdWVzIGFuIGF1dGhvcml6YXRpb24gY29kZSBhbmQg ZGVsaXZlcnMgaXQgdG8gdGhlIGNsaWVudCBieQogICBhZGRpbmcgdGhlIGZvbGxvd2luZyBwYXJh bWV0ZXJzIHRvIHRoZSBxdWVyeSBjb21wb25lbnQgb2YgdGhlCiAgIHJlZGlyZWN0aW9uIFVSSSB1 c2luZyB0aGUgImFwcGxpY2F0aW9uL3gtd3d3LWZvcm0tdXJsZW5jb2RlZCIgZm9ybWF0OgoKICAg Y29kZQogICAgICAgICBSRVFVSVJFRC4gIFRoZSBhdXRob3JpemF0aW9uIGNvZGUgZ2VuZXJhdGVk IGJ5IHRoZQogICAgICAgICBhdXRob3JpemF0aW9uIHNlcnZlci4gIFRoZSBhdXRob3JpemF0aW9u IGNvZGUgTVVTVCBleHBpcmUKICAgICAgICAgc2hvcnRseSBhZnRlciBpdCBpcyBpc3N1ZWQgdG8g bWl0aWdhdGUgdGhlIHJpc2sgb2YgbGVha3MuICBBCiAgICAgICAgIG1heGltdW0gYXV0aG9yaXph dGlvbiBjb2RlIGxpZmV0aW1lIG9mIDEwIG1pbnV0ZXMgaXMKICAgICAgICAgUkVDT01NRU5ERUQu ICBUaGUgY2xpZW50IE1VU1QgTk9UIHVzZSB0aGUgYXV0aG9yaXphdGlvbiBjb2RlCiAgICAgICAg IG1vcmUgdGhhbiBvbmNlLiAgSWYgYW4gYXV0aG9yaXphdGlvbiBjb2RlIGlzIHVzZWQgbW9yZSB0 aGFuCiAgICAgICAgIG9uY2UsIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBNVVNUIGRlbnkgdGhl IHJlcXVlc3QgYW5kIFNIT1VMRAogICAgICAgICByZXZva2UgKHdoZW4gcG9zc2libGUpIGFsbCB0 b2tlbnMgcHJldmlvdXNseSBpc3N1ZWQgYmFzZWQgb24KCgoKSGFtbWVyLCBldCBhbC4gICAgICAg ICAgRXhwaXJlcyBEZWNlbWJlciAxMCwgMjAxMiAgICAgICAgICAgICAgW1BhZ2UgMjVdCgwKSW50 ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICBPQXV0aCAyLjAgICAgICAgICAgICAgICAgICAg ICAgSnVuZSAyMDEyCgoKICAgICAgICAgdGhhdCBhdXRob3JpemF0aW9uIGNvZGUuICBUaGUgYXV0 aG9yaXphdGlvbiBjb2RlIGlzIGJvdW5kIHRvCiAgICAgICAgIHRoZSBjbGllbnQgaWRlbnRpZmll ciBhbmQgcmVkaXJlY3Rpb24gVVJJLgogICBzdGF0ZQogICAgICAgICBSRVFVSVJFRCBpZiB0aGUg InN0YXRlIiBwYXJhbWV0ZXIgd2FzIHByZXNlbnQgaW4gdGhlIGNsaWVudAogICAgICAgICBhdXRo b3JpemF0aW9uIHJlcXVlc3QuICBUaGUgZXhhY3QgdmFsdWUgcmVjZWl2ZWQgZnJvbSB0aGUKICAg ICAgICAgY2xpZW50LgoKICAgRm9yIGV4YW1wbGUsIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBy ZWRpcmVjdHMgdGhlIHVzZXItYWdlbnQgYnkKICAgc2VuZGluZyB0aGUgZm9sbG93aW5nIEhUVFAg cmVzcG9uc2U6CgoKICAgICBIVFRQLzEuMSAzMDIgRm91bmQKICAgICBMb2NhdGlvbjogaHR0cHM6 Ly9jbGllbnQuZXhhbXBsZS5jb20vY2I/Y29kZT1TcGx4bE9CZVpRUVliWVM2V3hTYklBCiAgICAg ICAgICAgICAgICZzdGF0ZT14eXoKCgogICBUaGUgY2xpZW50IE1VU1QgaWdub3JlIHVucmVjb2du aXplZCByZXNwb25zZSBwYXJhbWV0ZXJzLiAgVGhlCiAgIGF1dGhvcml6YXRpb24gY29kZSBzdHJp bmcgc2l6ZSBpcyBsZWZ0IHVuZGVmaW5lZCBieSB0aGlzCiAgIHNwZWNpZmljYXRpb24uICBUaGUg Y2xpZW50IHNob3VsZCBhdm9pZCBtYWtpbmcgYXNzdW1wdGlvbnMgYWJvdXQgY29kZQogICB2YWx1 ZSBzaXplcy4gIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBTSE9VTEQgZG9jdW1lbnQgdGhlIHNp emUgb2YKICAgYW55IHZhbHVlIGl0IGlzc3Vlcy4KCjQuMS4yLjEuICBFcnJvciBSZXNwb25zZQoK ICAgSWYgdGhlIHJlcXVlc3QgZmFpbHMgZHVlIHRvIGEgbWlzc2luZywgaW52YWxpZCwgb3IgbWlz bWF0Y2hpbmcKICAgcmVkaXJlY3Rpb24gVVJJLCBvciBpZiB0aGUgY2xpZW50IGlkZW50aWZpZXIg aXMgbWlzc2luZyBvciBpbnZhbGlkLAogICB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgU0hPVUxE IGluZm9ybSB0aGUgcmVzb3VyY2Ugb3duZXIgb2YgdGhlCiAgIGVycm9yLCBhbmQgTVVTVCBOT1Qg YXV0b21hdGljYWxseSByZWRpcmVjdCB0aGUgdXNlci1hZ2VudCB0byB0aGUKICAgaW52YWxpZCBy ZWRpcmVjdGlvbiBVUkkuCgogICBJZiB0aGUgcmVzb3VyY2Ugb3duZXIgZGVuaWVzIHRoZSBhY2Nl c3MgcmVxdWVzdCBvciBpZiB0aGUgcmVxdWVzdAogICBmYWlscyBmb3IgcmVhc29ucyBvdGhlciB0 aGFuIGEgbWlzc2luZyBvciBpbnZhbGlkIHJlZGlyZWN0aW9uIFVSSSwKICAgdGhlIGF1dGhvcml6 YXRpb24gc2VydmVyIGluZm9ybXMgdGhlIGNsaWVudCBieSBhZGRpbmcgdGhlIGZvbGxvd2luZwog ICBwYXJhbWV0ZXJzIHRvIHRoZSBxdWVyeSBjb21wb25lbnQgb2YgdGhlIHJlZGlyZWN0aW9uIFVS SSB1c2luZyB0aGUKICAgImFwcGxpY2F0aW9uL3gtd3d3LWZvcm0tdXJsZW5jb2RlZCIgZm9ybWF0 OgoKICAgZXJyb3IKICAgICAgICAgUkVRVUlSRUQuICBBIHNpbmdsZSBBU0NJSSBbVVNBU0NJSV0g ZXJyb3IgY29kZSBmcm9tIHRoZQogICAgICAgICBmb2xsb3dpbmc6CiAgICAgICAgIGludmFsaWRf cmVxdWVzdAogICAgICAgICAgICAgICBUaGUgcmVxdWVzdCBpcyBtaXNzaW5nIGEgcmVxdWlyZWQg cGFyYW1ldGVyLCBpbmNsdWRlcyBhbgogICAgICAgICAgICAgICBpbnZhbGlkIHBhcmFtZXRlciB2 YWx1ZSwgaW5jbHVkZXMgYSBwYXJhbWV0ZXIgbW9yZSB0aGFuCiAgICAgICAgICAgICAgIG9uY2Us IG9yIGlzIG90aGVyd2lzZSBtYWxmb3JtZWQuCiAgICAgICAgIHVuYXV0aG9yaXplZF9jbGllbnQK ICAgICAgICAgICAgICAgVGhlIGNsaWVudCBpcyBub3QgYXV0aG9yaXplZCB0byByZXF1ZXN0IGFu IGF1dGhvcml6YXRpb24KICAgICAgICAgICAgICAgY29kZSB1c2luZyB0aGlzIG1ldGhvZC4KCgoK CgpIYW1tZXIsIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIERlY2VtYmVyIDEwLCAyMDEyICAgICAg ICAgICAgICBbUGFnZSAyNl0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgIE9BdXRo IDIuMCAgICAgICAgICAgICAgICAgICAgICBKdW5lIDIwMTIKCgogICAgICAgICBhY2Nlc3NfZGVu aWVkCiAgICAgICAgICAgICAgIFRoZSByZXNvdXJjZSBvd25lciBvciBhdXRob3JpemF0aW9uIHNl cnZlciBkZW5pZWQgdGhlCiAgICAgICAgICAgICAgIHJlcXVlc3QuCiAgICAgICAgIHVuc3VwcG9y dGVkX3Jlc3BvbnNlX3R5cGUKICAgICAgICAgICAgICAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVy IGRvZXMgbm90IHN1cHBvcnQgb2J0YWluaW5nIGFuCiAgICAgICAgICAgICAgIGF1dGhvcml6YXRp b24gY29kZSB1c2luZyB0aGlzIG1ldGhvZC4KICAgICAgICAgaW52YWxpZF9zY29wZQogICAgICAg ICAgICAgICBUaGUgcmVxdWVzdGVkIHNjb3BlIGlzIGludmFsaWQsIHVua25vd24sIG9yIG1hbGZv cm1lZC4KICAgICAgICAgc2VydmVyX2Vycm9yCiAgICAgICAgICAgICAgIFRoZSBhdXRob3JpemF0 aW9uIHNlcnZlciBlbmNvdW50ZXJlZCBhbiB1bmV4cGVjdGVkCiAgICAgICAgICAgICAgIGNvbmRp dGlvbiB3aGljaCBwcmV2ZW50ZWQgaXQgZnJvbSBmdWxmaWxsaW5nIHRoZSByZXF1ZXN0LgogICAg ICAgICB0ZW1wb3JhcmlseV91bmF2YWlsYWJsZQogICAgICAgICAgICAgICBUaGUgYXV0aG9yaXph dGlvbiBzZXJ2ZXIgaXMgY3VycmVudGx5IHVuYWJsZSB0byBoYW5kbGUKICAgICAgICAgICAgICAg dGhlIHJlcXVlc3QgZHVlIHRvIGEgdGVtcG9yYXJ5IG92ZXJsb2FkaW5nIG9yIG1haW50ZW5hbmNl CiAgICAgICAgICAgICAgIG9mIHRoZSBzZXJ2ZXIuCiAgICAgICAgIFZhbHVlcyBmb3IgdGhlICJl cnJvciIgcGFyYW1ldGVyIE1VU1QgTk9UIGluY2x1ZGUgY2hhcmFjdGVycwogICAgICAgICBvdXRz aWRlIHRoZSBzZXQgJXgyMC0yMSAvICV4MjMtNUIgLyAleDVELTdFLgogICBlcnJvcl9kZXNjcmlw dGlvbgogICAgICAgICBPUFRJT05BTC4gIEEgaHVtYW4tcmVhZGFibGUgQVNDSUkgW1VTQVNDSUld IHRleHQgcHJvdmlkaW5nCiAgICAgICAgIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24sIHVzZWQgdG8g YXNzaXN0IHRoZSBjbGllbnQgZGV2ZWxvcGVyIGluCiAgICAgICAgIHVuZGVyc3RhbmRpbmcgdGhl IGVycm9yIHRoYXQgb2NjdXJyZWQuCiAgICAgICAgIFZhbHVlcyBmb3IgdGhlICJlcnJvcl9kZXNj cmlwdGlvbiIgcGFyYW1ldGVyIE1VU1QgTk9UIGluY2x1ZGUKICAgICAgICAgY2hhcmFjdGVycyBv dXRzaWRlIHRoZSBzZXQgJXgyMC0yMSAvICV4MjMtNUIgLyAleDVELTdFLgogICBlcnJvcl91cmkK ICAgICAgICAgT1BUSU9OQUwuICBBIFVSSSBpZGVudGlmeWluZyBhIGh1bWFuLXJlYWRhYmxlIHdl YiBwYWdlIHdpdGgKICAgICAgICAgaW5mb3JtYXRpb24gYWJvdXQgdGhlIGVycm9yLCB1c2VkIHRv IHByb3ZpZGUgdGhlIGNsaWVudAogICAgICAgICBkZXZlbG9wZXIgd2l0aCBhZGRpdGlvbmFsIGlu Zm9ybWF0aW9uIGFib3V0IHRoZSBlcnJvci4KICAgICAgICAgVmFsdWVzIGZvciB0aGUgImVycm9y X3VyaSIgcGFyYW1ldGVyIE1VU1QgY29uZm9ybSB0byB0aGUgVVJJLQogICAgICAgICBSZWZlcmVu Y2Ugc3ludGF4LCBhbmQgdGh1cyBNVVNUIE5PVCBpbmNsdWRlIGNoYXJhY3RlcnMgb3V0c2lkZQog ICAgICAgICB0aGUgc2V0ICV4MjEgLyAleDIzLTVCIC8gJXg1RC03RS4KICAgc3RhdGUKICAgICAg ICAgUkVRVUlSRUQgaWYgYSAic3RhdGUiIHBhcmFtZXRlciB3YXMgcHJlc2VudCBpbiB0aGUgY2xp ZW50CiAgICAgICAgIGF1dGhvcml6YXRpb24gcmVxdWVzdC4gIFRoZSBleGFjdCB2YWx1ZSByZWNl aXZlZCBmcm9tIHRoZQogICAgICAgICBjbGllbnQuCgogICBGb3IgZXhhbXBsZSwgdGhlIGF1dGhv cml6YXRpb24gc2VydmVyIHJlZGlyZWN0cyB0aGUgdXNlci1hZ2VudCBieQogICBzZW5kaW5nIHRo ZSBmb2xsb3dpbmcgSFRUUCByZXNwb25zZToKCgogICBIVFRQLzEuMSAzMDIgRm91bmQKICAgTG9j YXRpb246IGh0dHBzOi8vY2xpZW50LmV4YW1wbGUuY29tL2NiP2Vycm9yPWFjY2Vzc19kZW5pZWQm c3RhdGU9eHl6CgoKNC4xLjMuICBBY2Nlc3MgVG9rZW4gUmVxdWVzdAoKICAgVGhlIGNsaWVudCBt YWtlcyBhIHJlcXVlc3QgdG8gdGhlIHRva2VuIGVuZHBvaW50IGJ5IGFkZGluZyB0aGUKICAgZm9s bG93aW5nIHBhcmFtZXRlcnMgdXNpbmcgdGhlICJhcHBsaWNhdGlvbi94LXd3dy1mb3JtLXVybGVu Y29kZWQiCiAgIGZvcm1hdCBpbiB0aGUgSFRUUCByZXF1ZXN0IGVudGl0eS1ib2R5OgoKCgpIYW1t ZXIsIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIERlY2VtYmVyIDEwLCAyMDEyICAgICAgICAgICAg ICBbUGFnZSAyN10KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgIE9BdXRoIDIuMCAg ICAgICAgICAgICAgICAgICAgICBKdW5lIDIwMTIKCgogICBncmFudF90eXBlCiAgICAgICAgIFJF UVVJUkVELiAgVmFsdWUgTVVTVCBiZSBzZXQgdG8gImF1dGhvcml6YXRpb25fY29kZSIuCiAgIGNv ZGUKICAgICAgICAgUkVRVUlSRUQuICBUaGUgYXV0aG9yaXphdGlvbiBjb2RlIHJlY2VpdmVkIGZy b20gdGhlCiAgICAgICAgIGF1dGhvcml6YXRpb24gc2VydmVyLgogICByZWRpcmVjdF91cmkKICAg ICAgICAgUkVRVUlSRUQsIGlmIHRoZSAicmVkaXJlY3RfdXJpIiBwYXJhbWV0ZXIgd2FzIGluY2x1 ZGVkIGluIHRoZQogICAgICAgICBhdXRob3JpemF0aW9uIHJlcXVlc3QgYXMgZGVzY3JpYmVkIGlu IFNlY3Rpb24gNC4xLjEsIGFuZCB0aGVpcgogICAgICAgICB2YWx1ZXMgTVVTVCBiZSBpZGVudGlj YWwuCgogICBJZiB0aGUgY2xpZW50IHR5cGUgaXMgY29uZmlkZW50aWFsIG9yIHRoZSBjbGllbnQg d2FzIGlzc3VlZCBjbGllbnQKICAgY3JlZGVudGlhbHMgKG9yIGFzc2lnbmVkIG90aGVyIGF1dGhl bnRpY2F0aW9uIHJlcXVpcmVtZW50cyksIHRoZQogICBjbGllbnQgTVVTVCBhdXRoZW50aWNhdGUg d2l0aCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYXMgZGVzY3JpYmVkCiAgIGluIFNlY3Rpb24g My4yLjEuCgogICBGb3IgZXhhbXBsZSwgdGhlIGNsaWVudCBtYWtlcyB0aGUgZm9sbG93aW5nIEhU VFAgcmVxdWVzdCB1c2luZyBUTFMKICAgKGV4dHJhIGxpbmUgYnJlYWtzIGFyZSBmb3IgZGlzcGxh eSBwdXJwb3NlcyBvbmx5KToKCgogICAgIFBPU1QgL3Rva2VuIEhUVFAvMS4xCiAgICAgSG9zdDog c2VydmVyLmV4YW1wbGUuY29tCiAgICAgQXV0aG9yaXphdGlvbjogQmFzaWMgY3paQ2FHUlNhM0Yw TXpwbldERm1RbUYwTTJKVwogICAgIENvbnRlbnQtVHlwZTogYXBwbGljYXRpb24veC13d3ctZm9y bS11cmxlbmNvZGVkO2NoYXJzZXQ9VVRGLTgKCiAgICAgZ3JhbnRfdHlwZT1hdXRob3JpemF0aW9u X2NvZGUmY29kZT1TcGx4bE9CZVpRUVliWVM2V3hTYklBCiAgICAgJnJlZGlyZWN0X3VyaT1odHRw cyUzQSUyRiUyRmNsaWVudCUyRWV4YW1wbGUlMkVjb20lMkZjYgoKCiAgIFRoZSBhdXRob3JpemF0 aW9uIHNlcnZlciBNVVNUOgoKICAgbyAgcmVxdWlyZSBjbGllbnQgYXV0aGVudGljYXRpb24gZm9y IGNvbmZpZGVudGlhbCBjbGllbnRzIG9yIGZvciBhbnkKICAgICAgY2xpZW50IHRoYXQgd2FzIGlz c3VlZCBjbGllbnQgY3JlZGVudGlhbHMgKG9yIHdpdGggb3RoZXIKICAgICAgYXV0aGVudGljYXRp b24gcmVxdWlyZW1lbnRzKSwKICAgbyAgYXV0aGVudGljYXRlIHRoZSBjbGllbnQgaWYgY2xpZW50 IGF1dGhlbnRpY2F0aW9uIGlzIGluY2x1ZGVkIGFuZAogICAgICBlbnN1cmUgdGhlIGF1dGhvcml6 YXRpb24gY29kZSB3YXMgaXNzdWVkIHRvIHRoZSBhdXRoZW50aWNhdGVkCiAgICAgIGNsaWVudCwK ICAgbyAgdmVyaWZ5IHRoYXQgdGhlIGF1dGhvcml6YXRpb24gY29kZSBpcyB2YWxpZCwgYW5kCiAg IG8gIGVuc3VyZSB0aGF0IHRoZSAicmVkaXJlY3RfdXJpIiBwYXJhbWV0ZXIgaXMgcHJlc2VudCBp ZiB0aGUKICAgICAgInJlZGlyZWN0X3VyaSIgcGFyYW1ldGVyIHdhcyBpbmNsdWRlZCBpbiB0aGUg aW5pdGlhbCBhdXRob3JpemF0aW9uCiAgICAgIHJlcXVlc3QgYXMgZGVzY3JpYmVkIGluIFNlY3Rp b24gNC4xLjEsIGFuZCBpZiBpbmNsdWRlZCBlbnN1cmUKICAgICAgdGhlaXIgdmFsdWVzIGFyZSBp ZGVudGljYWwuCgo0LjEuNC4gIEFjY2VzcyBUb2tlbiBSZXNwb25zZQoKICAgSWYgdGhlIGFjY2Vz cyB0b2tlbiByZXF1ZXN0IGlzIHZhbGlkIGFuZCBhdXRob3JpemVkLCB0aGUKICAgYXV0aG9yaXph dGlvbiBzZXJ2ZXIgaXNzdWVzIGFuIGFjY2VzcyB0b2tlbiBhbmQgb3B0aW9uYWwgcmVmcmVzaAog ICB0b2tlbiBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiA1LjEuICBJZiB0aGUgcmVxdWVzdCBjbGll bnQKICAgYXV0aGVudGljYXRpb24gZmFpbGVkIG9yIGlzIGludmFsaWQsIHRoZSBhdXRob3JpemF0 aW9uIHNlcnZlciByZXR1cm5zCgoKCkhhbW1lciwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgRGVj ZW1iZXIgMTAsIDIwMTIgICAgICAgICAgICAgIFtQYWdlIDI4XQoMCkludGVybmV0LURyYWZ0ICAg ICAgICAgICAgICAgICAgT0F1dGggMi4wICAgICAgICAgICAgICAgICAgICAgIEp1bmUgMjAxMgoK CiAgIGFuIGVycm9yIHJlc3BvbnNlIGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDUuMi4KCiAgIEFu IGV4YW1wbGUgc3VjY2Vzc2Z1bCByZXNwb25zZToKCgogICAgIEhUVFAvMS4xIDIwMCBPSwogICAg IENvbnRlbnQtVHlwZTogYXBwbGljYXRpb24vanNvbjtjaGFyc2V0PVVURi04CiAgICAgQ2FjaGUt Q29udHJvbDogbm8tc3RvcmUKICAgICBQcmFnbWE6IG5vLWNhY2hlCgogICAgIHsKICAgICAgICJh Y2Nlc3NfdG9rZW4iOiIyWW90bkZaRkVqcjF6Q3NpY01XcEFBIiwKICAgICAgICJ0b2tlbl90eXBl IjoiZXhhbXBsZSIsCiAgICAgICAiZXhwaXJlc19pbiI6MzYwMCwKICAgICAgICJyZWZyZXNoX3Rv a2VuIjoidEd6djNKT2tGMFhHNVF4MlRsS1dJQSIsCiAgICAgICAiZXhhbXBsZV9wYXJhbWV0ZXIi OiJleGFtcGxlX3ZhbHVlIgogICAgIH0KCgo0LjIuICBJbXBsaWNpdCBHcmFudAoKICAgVGhlIGlt cGxpY2l0IGdyYW50IHR5cGUgaXMgdXNlZCB0byBvYnRhaW4gYWNjZXNzIHRva2VucyAoaXQgZG9l cyBub3QKICAgc3VwcG9ydCB0aGUgaXNzdWFuY2Ugb2YgcmVmcmVzaCB0b2tlbnMpIGFuZCBpcyBv cHRpbWl6ZWQgZm9yIHB1YmxpYwogICBjbGllbnRzIGtub3duIHRvIG9wZXJhdGUgYSBwYXJ0aWN1 bGFyIHJlZGlyZWN0aW9uIFVSSS4gIFRoZXNlIGNsaWVudHMKICAgYXJlIHR5cGljYWxseSBpbXBs ZW1lbnRlZCBpbiBhIGJyb3dzZXIgdXNpbmcgYSBzY3JpcHRpbmcgbGFuZ3VhZ2UKICAgc3VjaCBh cyBKYXZhU2NyaXB0LgoKICAgQXMgYSByZWRpcmVjdGlvbi1iYXNlZCBmbG93LCB0aGUgY2xpZW50 IG11c3QgYmUgY2FwYWJsZSBvZgogICBpbnRlcmFjdGluZyB3aXRoIHRoZSByZXNvdXJjZSBvd25l cidzIHVzZXItYWdlbnQgKHR5cGljYWxseSBhIHdlYgogICBicm93c2VyKSBhbmQgY2FwYWJsZSBv ZiByZWNlaXZpbmcgaW5jb21pbmcgcmVxdWVzdHMgKHZpYSByZWRpcmVjdGlvbikKICAgZnJvbSB0 aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIuCgogICBVbmxpa2UgdGhlIGF1dGhvcml6YXRpb24gY29k ZSBncmFudCB0eXBlIGluIHdoaWNoIHRoZSBjbGllbnQgbWFrZXMKICAgc2VwYXJhdGUgcmVxdWVz dHMgZm9yIGF1dGhvcml6YXRpb24gYW5kIGFjY2VzcyB0b2tlbiwgdGhlIGNsaWVudAogICByZWNl aXZlcyB0aGUgYWNjZXNzIHRva2VuIGFzIHRoZSByZXN1bHQgb2YgdGhlIGF1dGhvcml6YXRpb24g cmVxdWVzdC4KCiAgIFRoZSBpbXBsaWNpdCBncmFudCB0eXBlIGRvZXMgbm90IGluY2x1ZGUgY2xp ZW50IGF1dGhlbnRpY2F0aW9uLCBhbmQKICAgcmVsaWVzIG9uIHRoZSBwcmVzZW5jZSBvZiB0aGUg cmVzb3VyY2Ugb3duZXIgYW5kIHRoZSByZWdpc3RyYXRpb24gb2YKICAgdGhlIHJlZGlyZWN0aW9u IFVSSS4gIEJlY2F1c2UgdGhlIGFjY2VzcyB0b2tlbiBpcyBlbmNvZGVkIGludG8gdGhlCiAgIHJl ZGlyZWN0aW9uIFVSSSwgaXQgbWF5IGJlIGV4cG9zZWQgdG8gdGhlIHJlc291cmNlIG93bmVyIGFu ZCBvdGhlcgogICBhcHBsaWNhdGlvbnMgcmVzaWRpbmcgb24gdGhlIHNhbWUgZGV2aWNlLgoKCgoK CgoKCgoKSGFtbWVyLCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBEZWNlbWJlciAxMCwgMjAxMiAg ICAgICAgICAgICAgW1BhZ2UgMjldCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICBP QXV0aCAyLjAgICAgICAgICAgICAgICAgICAgICAgSnVuZSAyMDEyCgoKICAgICArLS0tLS0tLS0t LSsKICAgICB8IFJlc291cmNlIHwKICAgICB8ICBPd25lciAgIHwKICAgICB8ICAgICAgICAgIHwK ICAgICArLS0tLS0tLS0tLSsKICAgICAgICAgIF4KICAgICAgICAgIHwKICAgICAgICAgKEIpCiAg ICAgKy0tLS18LS0tLS0rICAgICAgICAgIENsaWVudCBJZGVudGlmaWVyICAgICArLS0tLS0tLS0t LS0tLS0tKwogICAgIHwgICAgICAgICAtKy0tLS0oQSktLSAmIFJlZGlyZWN0aW9uIFVSSSAtLS0+ fCAgICAgICAgICAgICAgIHwKICAgICB8ICBVc2VyLSAgIHwgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHwgQXV0aG9yaXphdGlvbiB8CiAgICAgfCAgQWdlbnQgIC18LS0tLShCKS0tIFVz ZXIgYXV0aGVudGljYXRlcyAtLT58ICAgICBTZXJ2ZXIgICAgfAogICAgIHwgICAgICAgICAgfCAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgIHwKICAgICB8ICAg ICAgICAgIHw8LS0tKEMpLS0tIFJlZGlyZWN0aW9uIFVSSSAtLS0tPHwgICAgICAgICAgICAgICB8 CiAgICAgfCAgICAgICAgICB8ICAgICAgICAgIHdpdGggQWNjZXNzIFRva2VuICAgICArLS0tLS0t LS0tLS0tLS0tKwogICAgIHwgICAgICAgICAgfCAgICAgICAgICAgIGluIEZyYWdtZW50CiAgICAg fCAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0t LS0tKwogICAgIHwgICAgICAgICAgfC0tLS0oRCktLS0gUmVkaXJlY3Rpb24gVVJJIC0tLS0+fCAg IFdlYi1Ib3N0ZWQgIHwKICAgICB8ICAgICAgICAgIHwgICAgICAgICAgd2l0aG91dCBGcmFnbWVu dCAgICAgIHwgICAgIENsaWVudCAgICB8CiAgICAgfCAgICAgICAgICB8ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICB8ICAgIFJlc291cmNlICAgfAogICAgIHwgICAgIChGKSAgfDwtLS0o RSktLS0tLS0tIFNjcmlwdCAtLS0tLS0tLS08fCAgICAgICAgICAgICAgIHwKICAgICB8ICAgICAg ICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0rCiAg ICAgKy18LS0tLS0tLS0rCiAgICAgICB8ICAgIHwKICAgICAgKEEpICAoRykgQWNjZXNzIFRva2Vu CiAgICAgICB8ICAgIHwKICAgICAgIF4gICAgdgogICAgICstLS0tLS0tLS0rCiAgICAgfCAgICAg ICAgIHwKICAgICB8ICBDbGllbnQgfAogICAgIHwgICAgICAgICB8CiAgICAgKy0tLS0tLS0tLSsK CgogICBOb3RlOiBUaGUgbGluZXMgaWxsdXN0cmF0aW5nIHN0ZXBzIEEgYW5kIEIgYXJlIGJyb2tl biBpbnRvIHR3byBwYXJ0cwogICBhcyB0aGV5IHBhc3MgdGhyb3VnaCB0aGUgdXNlci1hZ2VudC4K CiAgICAgICAgICAgICAgICAgICAgICAgRmlndXJlIDQ6IEltcGxpY2l0IEdyYW50IEZsb3cKCiAg IFRoZSBmbG93IGlsbHVzdHJhdGVkIGluIEZpZ3VyZSA0IGluY2x1ZGVzIHRoZSBmb2xsb3dpbmcg c3RlcHM6CgogICAoQSkgIFRoZSBjbGllbnQgaW5pdGlhdGVzIHRoZSBmbG93IGJ5IGRpcmVjdGlu ZyB0aGUgcmVzb3VyY2Ugb3duZXIncwogICAgICAgIHVzZXItYWdlbnQgdG8gdGhlIGF1dGhvcml6 YXRpb24gZW5kcG9pbnQuICBUaGUgY2xpZW50IGluY2x1ZGVzCiAgICAgICAgaXRzIGNsaWVudCBp ZGVudGlmaWVyLCByZXF1ZXN0ZWQgc2NvcGUsIGxvY2FsIHN0YXRlLCBhbmQgYQogICAgICAgIHJl ZGlyZWN0aW9uIFVSSSB0byB3aGljaCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgd2lsbCBzZW5k IHRoZQogICAgICAgIHVzZXItYWdlbnQgYmFjayBvbmNlIGFjY2VzcyBpcyBncmFudGVkIChvciBk ZW5pZWQpLgoKCgoKCkhhbW1lciwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgRGVjZW1iZXIgMTAs IDIwMTIgICAgICAgICAgICAgIFtQYWdlIDMwXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAg ICAgICAgT0F1dGggMi4wICAgICAgICAgICAgICAgICAgICAgIEp1bmUgMjAxMgoKCiAgIChCKSAg VGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGF1dGhlbnRpY2F0ZXMgdGhlIHJlc291cmNlIG93bmVy ICh2aWEKICAgICAgICB0aGUgdXNlci1hZ2VudCkgYW5kIGVzdGFibGlzaGVzIHdoZXRoZXIgdGhl IHJlc291cmNlIG93bmVyCiAgICAgICAgZ3JhbnRzIG9yIGRlbmllcyB0aGUgY2xpZW50J3MgYWNj ZXNzIHJlcXVlc3QuCiAgIChDKSAgQXNzdW1pbmcgdGhlIHJlc291cmNlIG93bmVyIGdyYW50cyBh Y2Nlc3MsIHRoZSBhdXRob3JpemF0aW9uCiAgICAgICAgc2VydmVyIHJlZGlyZWN0cyB0aGUgdXNl ci1hZ2VudCBiYWNrIHRvIHRoZSBjbGllbnQgdXNpbmcgdGhlCiAgICAgICAgcmVkaXJlY3Rpb24g VVJJIHByb3ZpZGVkIGVhcmxpZXIuICBUaGUgcmVkaXJlY3Rpb24gVVJJIGluY2x1ZGVzCiAgICAg ICAgdGhlIGFjY2VzcyB0b2tlbiBpbiB0aGUgVVJJIGZyYWdtZW50LgogICAoRCkgIFRoZSB1c2Vy LWFnZW50IGZvbGxvd3MgdGhlIHJlZGlyZWN0aW9uIGluc3RydWN0aW9ucyBieSBtYWtpbmcgYQog ICAgICAgIHJlcXVlc3QgdG8gdGhlIHdlYi1ob3N0ZWQgY2xpZW50IHJlc291cmNlICh3aGljaCBk b2VzIG5vdAogICAgICAgIGluY2x1ZGUgdGhlIGZyYWdtZW50IHBlciBbUkZDMjYxNl0pLiAgVGhl IHVzZXItYWdlbnQgcmV0YWlucyB0aGUKICAgICAgICBmcmFnbWVudCBpbmZvcm1hdGlvbiBsb2Nh bGx5LgogICAoRSkgIFRoZSB3ZWItaG9zdGVkIGNsaWVudCByZXNvdXJjZSByZXR1cm5zIGEgd2Vi IHBhZ2UgKHR5cGljYWxseSBhbgogICAgICAgIEhUTUwgZG9jdW1lbnQgd2l0aCBhbiBlbWJlZGRl ZCBzY3JpcHQpIGNhcGFibGUgb2YgYWNjZXNzaW5nIHRoZQogICAgICAgIGZ1bGwgcmVkaXJlY3Rp b24gVVJJIGluY2x1ZGluZyB0aGUgZnJhZ21lbnQgcmV0YWluZWQgYnkgdGhlCiAgICAgICAgdXNl ci1hZ2VudCwgYW5kIGV4dHJhY3RpbmcgdGhlIGFjY2VzcyB0b2tlbiAoYW5kIG90aGVyCiAgICAg ICAgcGFyYW1ldGVycykgY29udGFpbmVkIGluIHRoZSBmcmFnbWVudC4KICAgKEYpICBUaGUgdXNl ci1hZ2VudCBleGVjdXRlcyB0aGUgc2NyaXB0IHByb3ZpZGVkIGJ5IHRoZSB3ZWItaG9zdGVkCiAg ICAgICAgY2xpZW50IHJlc291cmNlIGxvY2FsbHksIHdoaWNoIGV4dHJhY3RzIHRoZSBhY2Nlc3Mg dG9rZW4gYW5kCiAgICAgICAgcGFzc2VzIGl0IHRvIHRoZSBjbGllbnQuCgo0LjIuMS4gIEF1dGhv cml6YXRpb24gUmVxdWVzdAoKICAgVGhlIGNsaWVudCBjb25zdHJ1Y3RzIHRoZSByZXF1ZXN0IFVS SSBieSBhZGRpbmcgdGhlIGZvbGxvd2luZwogICBwYXJhbWV0ZXJzIHRvIHRoZSBxdWVyeSBjb21w b25lbnQgb2YgdGhlIGF1dGhvcml6YXRpb24gZW5kcG9pbnQgVVJJCiAgIHVzaW5nIHRoZSAiYXBw bGljYXRpb24veC13d3ctZm9ybS11cmxlbmNvZGVkIiBmb3JtYXQ6CgogICByZXNwb25zZV90eXBl CiAgICAgICAgIFJFUVVJUkVELiAgVmFsdWUgTVVTVCBiZSBzZXQgdG8gInRva2VuIi4KICAgY2xp ZW50X2lkCiAgICAgICAgIFJFUVVJUkVELiAgVGhlIGNsaWVudCBpZGVudGlmaWVyIGFzIGRlc2Ny aWJlZCBpbiBTZWN0aW9uIDIuMi4KICAgcmVkaXJlY3RfdXJpCiAgICAgICAgIE9QVElPTkFMLiAg QXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gMy4xLjIuCiAgIHNjb3BlCiAgICAgICAgIE9QVElPTkFM LiAgVGhlIHNjb3BlIG9mIHRoZSBhY2Nlc3MgcmVxdWVzdCBhcyBkZXNjcmliZWQgYnkKICAgICAg ICAgU2VjdGlvbiAzLjMuCiAgIHN0YXRlCiAgICAgICAgIFJFQ09NTUVOREVELiAgQW4gb3BhcXVl IHZhbHVlIHVzZWQgYnkgdGhlIGNsaWVudCB0byBtYWludGFpbgogICAgICAgICBzdGF0ZSBiZXR3 ZWVuIHRoZSByZXF1ZXN0IGFuZCBjYWxsYmFjay4gIFRoZSBhdXRob3JpemF0aW9uCiAgICAgICAg IHNlcnZlciBpbmNsdWRlcyB0aGlzIHZhbHVlIHdoZW4gcmVkaXJlY3RpbmcgdGhlIHVzZXItYWdl bnQgYmFjawogICAgICAgICB0byB0aGUgY2xpZW50LiAgVGhlIHBhcmFtZXRlciBTSE9VTEQgYmUg dXNlZCBmb3IgcHJldmVudGluZwogICAgICAgICBjcm9zcy1zaXRlIHJlcXVlc3QgZm9yZ2VyeSBh cyBkZXNjcmliZWQgaW4gU2VjdGlvbiAxMC4xMi4KCiAgIFRoZSBjbGllbnQgZGlyZWN0cyB0aGUg cmVzb3VyY2Ugb3duZXIgdG8gdGhlIGNvbnN0cnVjdGVkIFVSSSB1c2luZyBhbgogICBIVFRQIHJl ZGlyZWN0aW9uIHJlc3BvbnNlLCBvciBieSBvdGhlciBtZWFucyBhdmFpbGFibGUgdG8gaXQgdmlh IHRoZQogICB1c2VyLWFnZW50LgoKCgoKCgpIYW1tZXIsIGV0IGFsLiAgICAgICAgICBFeHBpcmVz IERlY2VtYmVyIDEwLCAyMDEyICAgICAgICAgICAgICBbUGFnZSAzMV0KDApJbnRlcm5ldC1EcmFm dCAgICAgICAgICAgICAgICAgIE9BdXRoIDIuMCAgICAgICAgICAgICAgICAgICAgICBKdW5lIDIw MTIKCgogICBGb3IgZXhhbXBsZSwgdGhlIGNsaWVudCBkaXJlY3RzIHRoZSB1c2VyLWFnZW50IHRv IG1ha2UgdGhlIGZvbGxvd2luZwogICBIVFRQIHJlcXVlc3QgdXNpbmcgVExTIChleHRyYSBsaW5l IGJyZWFrcyBhcmUgZm9yIGRpc3BsYXkgcHVycG9zZXMKICAgb25seSk6CgoKICAgIEdFVCAvYXV0 aG9yaXplP3Jlc3BvbnNlX3R5cGU9dG9rZW4mY2xpZW50X2lkPXM2QmhkUmtxdDMmc3RhdGU9eHl6 CiAgICAgICAgJnJlZGlyZWN0X3VyaT1odHRwcyUzQSUyRiUyRmNsaWVudCUyRWV4YW1wbGUlMkVj b20lMkZjYiBIVFRQLzEuMQogICAgSG9zdDogc2VydmVyLmV4YW1wbGUuY29tCgoKICAgVGhlIGF1 dGhvcml6YXRpb24gc2VydmVyIHZhbGlkYXRlcyB0aGUgcmVxdWVzdCB0byBlbnN1cmUgYWxsIHJl cXVpcmVkCiAgIHBhcmFtZXRlcnMgYXJlIHByZXNlbnQgYW5kIHZhbGlkLiAgVGhlIGF1dGhvcml6 YXRpb24gc2VydmVyIE1VU1QKICAgdmVyaWZ5IHRoYXQgdGhlIHJlZGlyZWN0aW9uIFVSSSB0byB3 aGljaCBpdCB3aWxsIHJlZGlyZWN0IHRoZSBhY2Nlc3MKICAgdG9rZW4gbWF0Y2hlcyBhIHJlZGly ZWN0aW9uIFVSSSByZWdpc3RlcmVkIGJ5IHRoZSBjbGllbnQgYXMgZGVzY3JpYmVkCiAgIGluIFNl Y3Rpb24gMy4xLjIuCgogICBJZiB0aGUgcmVxdWVzdCBpcyB2YWxpZCwgdGhlIGF1dGhvcml6YXRp b24gc2VydmVyIGF1dGhlbnRpY2F0ZXMgdGhlCiAgIHJlc291cmNlIG93bmVyIGFuZCBvYnRhaW5z IGFuIGF1dGhvcml6YXRpb24gZGVjaXNpb24gKGJ5IGFza2luZyB0aGUKICAgcmVzb3VyY2Ugb3du ZXIgb3IgYnkgZXN0YWJsaXNoaW5nIGFwcHJvdmFsIHZpYSBvdGhlciBtZWFucykuCgogICBXaGVu IGEgZGVjaXNpb24gaXMgZXN0YWJsaXNoZWQsIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBkaXJl Y3RzIHRoZQogICB1c2VyLWFnZW50IHRvIHRoZSBwcm92aWRlZCBjbGllbnQgcmVkaXJlY3Rpb24g VVJJIHVzaW5nIGFuIEhUVFAKICAgcmVkaXJlY3Rpb24gcmVzcG9uc2UsIG9yIGJ5IG90aGVyIG1l YW5zIGF2YWlsYWJsZSB0byBpdCB2aWEgdGhlIHVzZXItCiAgIGFnZW50LgoKNC4yLjIuICBBY2Nl c3MgVG9rZW4gUmVzcG9uc2UKCiAgIElmIHRoZSByZXNvdXJjZSBvd25lciBncmFudHMgdGhlIGFj Y2VzcyByZXF1ZXN0LCB0aGUgYXV0aG9yaXphdGlvbgogICBzZXJ2ZXIgaXNzdWVzIGFuIGFjY2Vz cyB0b2tlbiBhbmQgZGVsaXZlcnMgaXQgdG8gdGhlIGNsaWVudCBieSBhZGRpbmcKICAgdGhlIGZv bGxvd2luZyBwYXJhbWV0ZXJzIHRvIHRoZSBmcmFnbWVudCBjb21wb25lbnQgb2YgdGhlIHJlZGly ZWN0aW9uCiAgIFVSSSB1c2luZyB0aGUgImFwcGxpY2F0aW9uL3gtd3d3LWZvcm0tdXJsZW5jb2Rl ZCIgZm9ybWF0OgoKICAgYWNjZXNzX3Rva2VuCiAgICAgICAgIFJFUVVJUkVELiAgVGhlIGFjY2Vz cyB0b2tlbiBpc3N1ZWQgYnkgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLgogICB0b2tlbl90eXBl CiAgICAgICAgIFJFUVVJUkVELiAgVGhlIHR5cGUgb2YgdGhlIHRva2VuIGlzc3VlZCBhcyBkZXNj cmliZWQgaW4KICAgICAgICAgU2VjdGlvbiA3LjEuICBWYWx1ZSBpcyBjYXNlIGluc2Vuc2l0aXZl LgogICBleHBpcmVzX2luCiAgICAgICAgIFJFQ09NTUVOREVELiAgVGhlIGxpZmV0aW1lIGluIHNl Y29uZHMgb2YgdGhlIGFjY2VzcyB0b2tlbi4gIEZvcgogICAgICAgICBleGFtcGxlLCB0aGUgdmFs dWUgIjM2MDAiIGRlbm90ZXMgdGhhdCB0aGUgYWNjZXNzIHRva2VuIHdpbGwKICAgICAgICAgZXhw aXJlIGluIG9uZSBob3VyIGZyb20gdGhlIHRpbWUgdGhlIHJlc3BvbnNlIHdhcyBnZW5lcmF0ZWQu CiAgICAgICAgIElmIG9taXR0ZWQsIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBTSE9VTEQgcHJv dmlkZSB0aGUKICAgICAgICAgZXhwaXJhdGlvbiB0aW1lIHZpYSBvdGhlciBtZWFucyBvciBkb2N1 bWVudCB0aGUgZGVmYXVsdCB2YWx1ZS4KICAgc2NvcGUKICAgICAgICAgT1BUSU9OQUwsIGlmIGlk ZW50aWNhbCB0byB0aGUgc2NvcGUgcmVxdWVzdGVkIGJ5IHRoZSBjbGllbnQsCiAgICAgICAgIG90 aGVyd2lzZSBSRVFVSVJFRC4gIFRoZSBzY29wZSBvZiB0aGUgYWNjZXNzIHRva2VuIGFzIGRlc2Ny aWJlZAogICAgICAgICBieSBTZWN0aW9uIDMuMy4KCgoKCkhhbW1lciwgZXQgYWwuICAgICAgICAg IEV4cGlyZXMgRGVjZW1iZXIgMTAsIDIwMTIgICAgICAgICAgICAgIFtQYWdlIDMyXQoMCkludGVy bmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgT0F1dGggMi4wICAgICAgICAgICAgICAgICAgICAg IEp1bmUgMjAxMgoKCiAgIHN0YXRlCiAgICAgICAgIFJFUVVJUkVEIGlmIHRoZSAic3RhdGUiIHBh cmFtZXRlciB3YXMgcHJlc2VudCBpbiB0aGUgY2xpZW50CiAgICAgICAgIGF1dGhvcml6YXRpb24g cmVxdWVzdC4gIFRoZSBleGFjdCB2YWx1ZSByZWNlaXZlZCBmcm9tIHRoZQogICAgICAgICBjbGll bnQuCgogICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVTVCBOT1QgaXNzdWUgYSByZWZyZXNo IHRva2VuLgoKICAgRm9yIGV4YW1wbGUsIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciByZWRpcmVj dHMgdGhlIHVzZXItYWdlbnQgYnkKICAgc2VuZGluZyB0aGUgZm9sbG93aW5nIEhUVFAgcmVzcG9u c2UgKFVSSSBleHRyYSBsaW5lIGJyZWFrcyBhcmUgZm9yCiAgIGRpc3BsYXkgcHVycG9zZXMgb25s eSk6CgoKICAgICBIVFRQLzEuMSAzMDIgRm91bmQKICAgICBMb2NhdGlvbjogaHR0cDovL2V4YW1w bGUuY29tL2NiI2FjY2Vzc190b2tlbj0yWW90bkZaRkVqcjF6Q3NpY01XcEFBCiAgICAgICAgICAg ICAgICZzdGF0ZT14eXomdG9rZW5fdHlwZT1leGFtcGxlJmV4cGlyZXNfaW49MzYwMAoKCiAgIERl dmVsb3BlcnMgc2hvdWxkIG5vdGUgdGhhdCBzb21lIHVzZXItYWdlbnRzIGRvIG5vdCBzdXBwb3J0 IHRoZQogICBpbmNsdXNpb24gb2YgYSBmcmFnbWVudCBjb21wb25lbnQgaW4gdGhlIEhUVFAgIkxv Y2F0aW9uIiByZXNwb25zZQogICBoZWFkZXIgZmllbGQuICBTdWNoIGNsaWVudHMgd2lsbCByZXF1 aXJlIHVzaW5nIG90aGVyIG1ldGhvZHMgZm9yCiAgIHJlZGlyZWN0aW5nIHRoZSBjbGllbnQgdGhh biBhIDN4eCByZWRpcmVjdGlvbiByZXNwb25zZS4gIEZvciBleGFtcGxlLAogICByZXR1cm5pbmcg YW4gSFRNTCBwYWdlIHdoaWNoIGluY2x1ZGVzIGEgJ2NvbnRpbnVlJyBidXR0b24gd2l0aCBhbgog ICBhY3Rpb24gbGlua2VkIHRvIHRoZSByZWRpcmVjdGlvbiBVUkkuCgogICBUaGUgY2xpZW50IE1V U1QgaWdub3JlIHVucmVjb2duaXplZCByZXNwb25zZSBwYXJhbWV0ZXJzLiAgVGhlIGFjY2Vzcwog ICB0b2tlbiBzdHJpbmcgc2l6ZSBpcyBsZWZ0IHVuZGVmaW5lZCBieSB0aGlzIHNwZWNpZmljYXRp b24uICBUaGUKICAgY2xpZW50IHNob3VsZCBhdm9pZCBtYWtpbmcgYXNzdW1wdGlvbnMgYWJvdXQg dmFsdWUgc2l6ZXMuICBUaGUKICAgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgU0hPVUxEIGRvY3VtZW50 IHRoZSBzaXplIG9mIGFueSB2YWx1ZSBpdCBpc3N1ZXMuCgo0LjIuMi4xLiAgRXJyb3IgUmVzcG9u c2UKCiAgIElmIHRoZSByZXF1ZXN0IGZhaWxzIGR1ZSB0byBhIG1pc3NpbmcsIGludmFsaWQsIG9y IG1pc21hdGNoaW5nCiAgIHJlZGlyZWN0aW9uIFVSSSwgb3IgaWYgdGhlIGNsaWVudCBpZGVudGlm aWVyIGlzIG1pc3Npbmcgb3IgaW52YWxpZCwKICAgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIFNI T1VMRCBpbmZvcm0gdGhlIHJlc291cmNlIG93bmVyIG9mIHRoZQogICBlcnJvciwgYW5kIE1VU1Qg Tk9UIGF1dG9tYXRpY2FsbHkgcmVkaXJlY3QgdGhlIHVzZXItYWdlbnQgdG8gdGhlCiAgIGludmFs aWQgcmVkaXJlY3Rpb24gVVJJLgoKICAgSWYgdGhlIHJlc291cmNlIG93bmVyIGRlbmllcyB0aGUg YWNjZXNzIHJlcXVlc3Qgb3IgaWYgdGhlIHJlcXVlc3QKICAgZmFpbHMgZm9yIHJlYXNvbnMgb3Ro ZXIgdGhhbiBhIG1pc3Npbmcgb3IgaW52YWxpZCByZWRpcmVjdGlvbiBVUkksCiAgIHRoZSBhdXRo b3JpemF0aW9uIHNlcnZlciBpbmZvcm1zIHRoZSBjbGllbnQgYnkgYWRkaW5nIHRoZSBmb2xsb3dp bmcKICAgcGFyYW1ldGVycyB0byB0aGUgZnJhZ21lbnQgY29tcG9uZW50IG9mIHRoZSByZWRpcmVj dGlvbiBVUkkgdXNpbmcgdGhlCiAgICJhcHBsaWNhdGlvbi94LXd3dy1mb3JtLXVybGVuY29kZWQi IGZvcm1hdDoKCiAgIGVycm9yCiAgICAgICAgIFJFUVVJUkVELiAgQSBzaW5nbGUgQVNDSUkgW1VT QVNDSUldIGVycm9yIGNvZGUgZnJvbSB0aGUKICAgICAgICAgZm9sbG93aW5nOgoKCgoKCkhhbW1l ciwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgRGVjZW1iZXIgMTAsIDIwMTIgICAgICAgICAgICAg IFtQYWdlIDMzXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgT0F1dGggMi4wICAg ICAgICAgICAgICAgICAgICAgIEp1bmUgMjAxMgoKCiAgICAgICAgIGludmFsaWRfcmVxdWVzdAog ICAgICAgICAgICAgICBUaGUgcmVxdWVzdCBpcyBtaXNzaW5nIGEgcmVxdWlyZWQgcGFyYW1ldGVy LCBpbmNsdWRlcyBhbgogICAgICAgICAgICAgICBpbnZhbGlkIHBhcmFtZXRlciB2YWx1ZSwgaW5j bHVkZXMgYSBwYXJhbWV0ZXIgbW9yZSB0aGFuCiAgICAgICAgICAgICAgIG9uY2UsIG9yIGlzIG90 aGVyd2lzZSBtYWxmb3JtZWQuCiAgICAgICAgIHVuYXV0aG9yaXplZF9jbGllbnQKICAgICAgICAg ICAgICAgVGhlIGNsaWVudCBpcyBub3QgYXV0aG9yaXplZCB0byByZXF1ZXN0IGFuIGFjY2VzcyB0 b2tlbgogICAgICAgICAgICAgICB1c2luZyB0aGlzIG1ldGhvZC4KICAgICAgICAgYWNjZXNzX2Rl bmllZAogICAgICAgICAgICAgICBUaGUgcmVzb3VyY2Ugb3duZXIgb3IgYXV0aG9yaXphdGlvbiBz ZXJ2ZXIgZGVuaWVkIHRoZQogICAgICAgICAgICAgICByZXF1ZXN0LgogICAgICAgICB1bnN1cHBv cnRlZF9yZXNwb25zZV90eXBlCiAgICAgICAgICAgICAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZl ciBkb2VzIG5vdCBzdXBwb3J0IG9idGFpbmluZyBhbgogICAgICAgICAgICAgICBhY2Nlc3MgdG9r ZW4gdXNpbmcgdGhpcyBtZXRob2QuCiAgICAgICAgIGludmFsaWRfc2NvcGUKICAgICAgICAgICAg ICAgVGhlIHJlcXVlc3RlZCBzY29wZSBpcyBpbnZhbGlkLCB1bmtub3duLCBvciBtYWxmb3JtZWQu CiAgICAgICAgIHNlcnZlcl9lcnJvcgogICAgICAgICAgICAgICBUaGUgYXV0aG9yaXphdGlvbiBz ZXJ2ZXIgZW5jb3VudGVyZWQgYW4gdW5leHBlY3RlZAogICAgICAgICAgICAgICBjb25kaXRpb24g d2hpY2ggcHJldmVudGVkIGl0IGZyb20gZnVsZmlsbGluZyB0aGUgcmVxdWVzdC4KICAgICAgICAg dGVtcG9yYXJpbHlfdW5hdmFpbGFibGUKICAgICAgICAgICAgICAgVGhlIGF1dGhvcml6YXRpb24g c2VydmVyIGlzIGN1cnJlbnRseSB1bmFibGUgdG8gaGFuZGxlCiAgICAgICAgICAgICAgIHRoZSBy ZXF1ZXN0IGR1ZSB0byBhIHRlbXBvcmFyeSBvdmVybG9hZGluZyBvciBtYWludGVuYW5jZQogICAg ICAgICAgICAgICBvZiB0aGUgc2VydmVyLgogICAgICAgICBWYWx1ZXMgZm9yIHRoZSAiZXJyb3Ii IHBhcmFtZXRlciBNVVNUIE5PVCBpbmNsdWRlIGNoYXJhY3RlcnMKICAgICAgICAgb3V0c2lkZSB0 aGUgc2V0ICV4MjAtMjEgLyAleDIzLTVCIC8gJXg1RC03RS4KICAgZXJyb3JfZGVzY3JpcHRpb24K ICAgICAgICAgT1BUSU9OQUwuICBBIGh1bWFuLXJlYWRhYmxlIEFTQ0lJIFtVU0FTQ0lJXSB0ZXh0 IHByb3ZpZGluZwogICAgICAgICBhZGRpdGlvbmFsIGluZm9ybWF0aW9uLCB1c2VkIHRvIGFzc2lz dCB0aGUgY2xpZW50IGRldmVsb3BlciBpbgogICAgICAgICB1bmRlcnN0YW5kaW5nIHRoZSBlcnJv ciB0aGF0IG9jY3VycmVkLgogICAgICAgICBWYWx1ZXMgZm9yIHRoZSAiZXJyb3JfZGVzY3JpcHRp b24iIHBhcmFtZXRlciBNVVNUIE5PVCBpbmNsdWRlCiAgICAgICAgIGNoYXJhY3RlcnMgb3V0c2lk ZSB0aGUgc2V0ICV4MjAtMjEgLyAleDIzLTVCIC8gJXg1RC03RS4KICAgZXJyb3JfdXJpCiAgICAg ICAgIE9QVElPTkFMLiAgQSBVUkkgaWRlbnRpZnlpbmcgYSBodW1hbi1yZWFkYWJsZSB3ZWIgcGFn ZSB3aXRoCiAgICAgICAgIGluZm9ybWF0aW9uIGFib3V0IHRoZSBlcnJvciwgdXNlZCB0byBwcm92 aWRlIHRoZSBjbGllbnQKICAgICAgICAgZGV2ZWxvcGVyIHdpdGggYWRkaXRpb25hbCBpbmZvcm1h dGlvbiBhYm91dCB0aGUgZXJyb3IuCiAgICAgICAgIFZhbHVlcyBmb3IgdGhlICJlcnJvcl91cmki IHBhcmFtZXRlciBNVVNUIGNvbmZvcm0gdG8gdGhlIFVSSS0KICAgICAgICAgUmVmZXJlbmNlIHN5 bnRheCwgYW5kIHRodXMgTVVTVCBOT1QgaW5jbHVkZSBjaGFyYWN0ZXJzIG91dHNpZGUKICAgICAg ICAgdGhlIHNldCAleDIxIC8gJXgyMy01QiAvICV4NUQtN0UuCiAgIHN0YXRlCiAgICAgICAgIFJF UVVJUkVEIGlmIGEgInN0YXRlIiBwYXJhbWV0ZXIgd2FzIHByZXNlbnQgaW4gdGhlIGNsaWVudAog ICAgICAgICBhdXRob3JpemF0aW9uIHJlcXVlc3QuICBUaGUgZXhhY3QgdmFsdWUgcmVjZWl2ZWQg ZnJvbSB0aGUKICAgICAgICAgY2xpZW50LgoKICAgRm9yIGV4YW1wbGUsIHRoZSBhdXRob3JpemF0 aW9uIHNlcnZlciByZWRpcmVjdHMgdGhlIHVzZXItYWdlbnQgYnkKICAgc2VuZGluZyB0aGUgZm9s bG93aW5nIEhUVFAgcmVzcG9uc2U6CgoKICAgSFRUUC8xLjEgMzAyIEZvdW5kCiAgIExvY2F0aW9u OiBodHRwczovL2NsaWVudC5leGFtcGxlLmNvbS9jYiNlcnJvcj1hY2Nlc3NfZGVuaWVkJnN0YXRl PXh5egoKCgpIYW1tZXIsIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIERlY2VtYmVyIDEwLCAyMDEy ICAgICAgICAgICAgICBbUGFnZSAzNF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAg IE9BdXRoIDIuMCAgICAgICAgICAgICAgICAgICAgICBKdW5lIDIwMTIKCgo0LjMuICBSZXNvdXJj ZSBPd25lciBQYXNzd29yZCBDcmVkZW50aWFscyBHcmFudAoKICAgVGhlIHJlc291cmNlIG93bmVy IHBhc3N3b3JkIGNyZWRlbnRpYWxzIGdyYW50IHR5cGUgaXMgc3VpdGFibGUgaW4KICAgY2FzZXMg d2hlcmUgdGhlIHJlc291cmNlIG93bmVyIGhhcyBhIHRydXN0IHJlbGF0aW9uc2hpcCB3aXRoIHRo ZQogICBjbGllbnQsIHN1Y2ggYXMgdGhlIGRldmljZSBvcGVyYXRpbmcgc3lzdGVtIG9yIGEgaGln aGx5IHByaXZpbGVnZWQKICAgYXBwbGljYXRpb24uICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIg c2hvdWxkIHRha2Ugc3BlY2lhbCBjYXJlIHdoZW4KICAgZW5hYmxpbmcgdGhpcyBncmFudCB0eXBl LCBhbmQgb25seSBhbGxvdyBpdCB3aGVuIG90aGVyIGZsb3dzIGFyZSBub3QKICAgdmlhYmxlLgoK ICAgVGhlIGdyYW50IHR5cGUgaXMgc3VpdGFibGUgZm9yIGNsaWVudHMgY2FwYWJsZSBvZiBvYnRh aW5pbmcgdGhlCiAgIHJlc291cmNlIG93bmVyJ3MgY3JlZGVudGlhbHMgKHVzZXJuYW1lIGFuZCBw YXNzd29yZCwgdHlwaWNhbGx5IHVzaW5nCiAgIGFuIGludGVyYWN0aXZlIGZvcm0pLiAgSXQgaXMg YWxzbyB1c2VkIHRvIG1pZ3JhdGUgZXhpc3RpbmcgY2xpZW50cwogICB1c2luZyBkaXJlY3QgYXV0 aGVudGljYXRpb24gc2NoZW1lcyBzdWNoIGFzIEhUVFAgQmFzaWMgb3IgRGlnZXN0CiAgIGF1dGhl bnRpY2F0aW9uIHRvIE9BdXRoIGJ5IGNvbnZlcnRpbmcgdGhlIHN0b3JlZCBjcmVkZW50aWFscyB0 byBhbgogICBhY2Nlc3MgdG9rZW4uCgoKICAgICArLS0tLS0tLS0tLSsKICAgICB8IFJlc291cmNl IHwKICAgICB8ICBPd25lciAgIHwKICAgICB8ICAgICAgICAgIHwKICAgICArLS0tLS0tLS0tLSsK ICAgICAgICAgIHYKICAgICAgICAgIHwgICAgUmVzb3VyY2UgT3duZXIKICAgICAgICAgKEEpIFBh c3N3b3JkIENyZWRlbnRpYWxzCiAgICAgICAgICB8CiAgICAgICAgICB2CiAgICAgKy0tLS0tLS0t LSsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLSsKICAg ICB8ICAgICAgICAgfD4tLShCKS0tLS0gUmVzb3VyY2UgT3duZXIgLS0tLS0tLT58ICAgICAgICAg ICAgICAgfAogICAgIHwgICAgICAgICB8ICAgICAgICAgUGFzc3dvcmQgQ3JlZGVudGlhbHMgICAg IHwgQXV0aG9yaXphdGlvbiB8CiAgICAgfCBDbGllbnQgIHwgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgfCAgICAgU2VydmVyICAgIHwKICAgICB8ICAgICAgICAgfDwtLShDKS0tLS0g QWNjZXNzIFRva2VuIC0tLS0tLS0tLTx8ICAgICAgICAgICAgICAgfAogICAgIHwgICAgICAgICB8 ICAgICh3LyBPcHRpb25hbCBSZWZyZXNoIFRva2VuKSAgIHwgICAgICAgICAgICAgICB8CiAgICAg Ky0tLS0tLS0tLSsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0t LS0tLSsKCgogICAgICAgICAgICBGaWd1cmUgNTogUmVzb3VyY2UgT3duZXIgUGFzc3dvcmQgQ3Jl ZGVudGlhbHMgRmxvdwoKICAgVGhlIGZsb3cgaWxsdXN0cmF0ZWQgaW4gRmlndXJlIDUgaW5jbHVk ZXMgdGhlIGZvbGxvd2luZyBzdGVwczoKCiAgIChBKSAgVGhlIHJlc291cmNlIG93bmVyIHByb3Zp ZGVzIHRoZSBjbGllbnQgd2l0aCBpdHMgdXNlcm5hbWUgYW5kCiAgICAgICAgcGFzc3dvcmQuCiAg IChCKSAgVGhlIGNsaWVudCByZXF1ZXN0cyBhbiBhY2Nlc3MgdG9rZW4gZnJvbSB0aGUgYXV0aG9y aXphdGlvbgogICAgICAgIHNlcnZlcidzIHRva2VuIGVuZHBvaW50IGJ5IGluY2x1ZGluZyB0aGUg Y3JlZGVudGlhbHMgcmVjZWl2ZWQKICAgICAgICBmcm9tIHRoZSByZXNvdXJjZSBvd25lci4gIFdo ZW4gbWFraW5nIHRoZSByZXF1ZXN0LCB0aGUgY2xpZW50CiAgICAgICAgYXV0aGVudGljYXRlcyB3 aXRoIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlci4KCgoKCgpIYW1tZXIsIGV0IGFsLiAgICAgICAg ICBFeHBpcmVzIERlY2VtYmVyIDEwLCAyMDEyICAgICAgICAgICAgICBbUGFnZSAzNV0KDApJbnRl cm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgIE9BdXRoIDIuMCAgICAgICAgICAgICAgICAgICAg ICBKdW5lIDIwMTIKCgogICAoQykgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBhdXRoZW50aWNh dGVzIHRoZSBjbGllbnQgYW5kIHZhbGlkYXRlcwogICAgICAgIHRoZSByZXNvdXJjZSBvd25lciBj cmVkZW50aWFscywgYW5kIGlmIHZhbGlkIGlzc3VlcyBhbiBhY2Nlc3MKICAgICAgICB0b2tlbi4K CjQuMy4xLiAgQXV0aG9yaXphdGlvbiBSZXF1ZXN0IGFuZCBSZXNwb25zZQoKICAgVGhlIG1ldGhv ZCB0aHJvdWdoIHdoaWNoIHRoZSBjbGllbnQgb2J0YWlucyB0aGUgcmVzb3VyY2Ugb3duZXIKICAg Y3JlZGVudGlhbHMgaXMgYmV5b25kIHRoZSBzY29wZSBvZiB0aGlzIHNwZWNpZmljYXRpb24uICBU aGUgY2xpZW50CiAgIE1VU1QgZGlzY2FyZCB0aGUgY3JlZGVudGlhbHMgb25jZSBhbiBhY2Nlc3Mg dG9rZW4gaGFzIGJlZW4gb2J0YWluZWQuCgo0LjMuMi4gIEFjY2VzcyBUb2tlbiBSZXF1ZXN0Cgog ICBUaGUgY2xpZW50IG1ha2VzIGEgcmVxdWVzdCB0byB0aGUgdG9rZW4gZW5kcG9pbnQgYnkgYWRk aW5nIHRoZQogICBmb2xsb3dpbmcgcGFyYW1ldGVycyB1c2luZyB0aGUgImFwcGxpY2F0aW9uL3gt d3d3LWZvcm0tdXJsZW5jb2RlZCIKICAgZm9ybWF0IGluIHRoZSBIVFRQIHJlcXVlc3QgZW50aXR5 LWJvZHk6CgogICBncmFudF90eXBlCiAgICAgICAgIFJFUVVJUkVELiAgVmFsdWUgTVVTVCBiZSBz ZXQgdG8gInBhc3N3b3JkIi4KICAgdXNlcm5hbWUKICAgICAgICAgUkVRVUlSRUQuICBUaGUgcmVz b3VyY2Ugb3duZXIgdXNlcm5hbWUsIGVuY29kZWQgYXMgVVRGLTguCiAgIHBhc3N3b3JkCiAgICAg ICAgIFJFUVVJUkVELiAgVGhlIHJlc291cmNlIG93bmVyIHBhc3N3b3JkLCBlbmNvZGVkIGFzIFVU Ri04LgogICBzY29wZQogICAgICAgICBPUFRJT05BTC4gIFRoZSBzY29wZSBvZiB0aGUgYWNjZXNz IHJlcXVlc3QgYXMgZGVzY3JpYmVkIGJ5CiAgICAgICAgIFNlY3Rpb24gMy4zLgoKICAgSWYgdGhl IGNsaWVudCB0eXBlIGlzIGNvbmZpZGVudGlhbCBvciB0aGUgY2xpZW50IHdhcyBpc3N1ZWQgY2xp ZW50CiAgIGNyZWRlbnRpYWxzIChvciBhc3NpZ25lZCBvdGhlciBhdXRoZW50aWNhdGlvbiByZXF1 aXJlbWVudHMpLCB0aGUKICAgY2xpZW50IE1VU1QgYXV0aGVudGljYXRlIHdpdGggdGhlIGF1dGhv cml6YXRpb24gc2VydmVyIGFzIGRlc2NyaWJlZAogICBpbiBTZWN0aW9uIDMuMi4xLgoKICAgRm9y IGV4YW1wbGUsIHRoZSBjbGllbnQgbWFrZXMgdGhlIGZvbGxvd2luZyBIVFRQIHJlcXVlc3QgdXNp bmcKICAgdHJhbnNwb3J0LWxheWVyIHNlY3VyaXR5IChleHRyYSBsaW5lIGJyZWFrcyBhcmUgZm9y IGRpc3BsYXkgcHVycG9zZXMKICAgb25seSk6CgoKICAgICBQT1NUIC90b2tlbiBIVFRQLzEuMQog ICAgIEhvc3Q6IHNlcnZlci5leGFtcGxlLmNvbQogICAgIEF1dGhvcml6YXRpb246IEJhc2ljIGN6 WkNhR1JTYTNGME16cG5XREZtUW1GME0ySlcKICAgICBDb250ZW50LVR5cGU6IGFwcGxpY2F0aW9u L3gtd3d3LWZvcm0tdXJsZW5jb2RlZDtjaGFyc2V0PVVURi04CgogICAgIGdyYW50X3R5cGU9cGFz c3dvcmQmdXNlcm5hbWU9am9obmRvZSZwYXNzd29yZD1BM2RkajN3CgoKICAgVGhlIGF1dGhvcml6 YXRpb24gc2VydmVyIE1VU1Q6CgoKCgoKCkhhbW1lciwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMg RGVjZW1iZXIgMTAsIDIwMTIgICAgICAgICAgICAgIFtQYWdlIDM2XQoMCkludGVybmV0LURyYWZ0 ICAgICAgICAgICAgICAgICAgT0F1dGggMi4wICAgICAgICAgICAgICAgICAgICAgIEp1bmUgMjAx MgoKCiAgIG8gIHJlcXVpcmUgY2xpZW50IGF1dGhlbnRpY2F0aW9uIGZvciBjb25maWRlbnRpYWwg Y2xpZW50cyBvciBmb3IgYW55CiAgICAgIGNsaWVudCB0aGF0IHdhcyBpc3N1ZWQgY2xpZW50IGNy ZWRlbnRpYWxzIChvciB3aXRoIG90aGVyCiAgICAgIGF1dGhlbnRpY2F0aW9uIHJlcXVpcmVtZW50 cyksCiAgIG8gIGF1dGhlbnRpY2F0ZSB0aGUgY2xpZW50IGlmIGNsaWVudCBhdXRoZW50aWNhdGlv biBpcyBpbmNsdWRlZCwgYW5kCiAgIG8gIHZhbGlkYXRlIHRoZSByZXNvdXJjZSBvd25lciBwYXNz d29yZCBjcmVkZW50aWFscyB1c2luZyBpdHMKICAgICAgZXhpc3RpbmcgcGFzc3dvcmQgdmFsaWRh dGlvbiBhbGdvcml0aG0uCgogICBTaW5jZSB0aGlzIGFjY2VzcyB0b2tlbiByZXF1ZXN0IHV0aWxp emVzIHRoZSByZXNvdXJjZSBvd25lcidzCiAgIHBhc3N3b3JkLCB0aGUgYXV0aG9yaXphdGlvbiBz ZXJ2ZXIgTVVTVCBwcm90ZWN0IHRoZSBlbmRwb2ludCBhZ2FpbnN0CiAgIGJydXRlIGZvcmNlIGF0 dGFja3MgKGUuZy4gdXNpbmcgcmF0ZS1saW1pdGF0aW9uIG9yIGdlbmVyYXRpbmcKICAgYWxlcnRz KS4KCjQuMy4zLiAgQWNjZXNzIFRva2VuIFJlc3BvbnNlCgogICBJZiB0aGUgYWNjZXNzIHRva2Vu IHJlcXVlc3QgaXMgdmFsaWQgYW5kIGF1dGhvcml6ZWQsIHRoZQogICBhdXRob3JpemF0aW9uIHNl cnZlciBpc3N1ZXMgYW4gYWNjZXNzIHRva2VuIGFuZCBvcHRpb25hbCByZWZyZXNoCiAgIHRva2Vu IGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDUuMS4gIElmIHRoZSByZXF1ZXN0IGZhaWxlZCBjbGll bnQKICAgYXV0aGVudGljYXRpb24gb3IgaXMgaW52YWxpZCwgdGhlIGF1dGhvcml6YXRpb24gc2Vy dmVyIHJldHVybnMgYW4KICAgZXJyb3IgcmVzcG9uc2UgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24g NS4yLgoKICAgQW4gZXhhbXBsZSBzdWNjZXNzZnVsIHJlc3BvbnNlOgoKCiAgICAgSFRUUC8xLjEg MjAwIE9LCiAgICAgQ29udGVudC1UeXBlOiBhcHBsaWNhdGlvbi9qc29uO2NoYXJzZXQ9VVRGLTgK ICAgICBDYWNoZS1Db250cm9sOiBuby1zdG9yZQogICAgIFByYWdtYTogbm8tY2FjaGUKCiAgICAg ewogICAgICAgImFjY2Vzc190b2tlbiI6IjJZb3RuRlpGRWpyMXpDc2ljTVdwQUEiLAogICAgICAg InRva2VuX3R5cGUiOiJleGFtcGxlIiwKICAgICAgICJleHBpcmVzX2luIjozNjAwLAogICAgICAg InJlZnJlc2hfdG9rZW4iOiJ0R3p2M0pPa0YwWEc1UXgyVGxLV0lBIiwKICAgICAgICJleGFtcGxl X3BhcmFtZXRlciI6ImV4YW1wbGVfdmFsdWUiCiAgICAgfQoKCjQuNC4gIENsaWVudCBDcmVkZW50 aWFscyBHcmFudAoKICAgVGhlIGNsaWVudCBjYW4gcmVxdWVzdCBhbiBhY2Nlc3MgdG9rZW4gdXNp bmcgb25seSBpdHMgY2xpZW50CiAgIGNyZWRlbnRpYWxzIChvciBvdGhlciBzdXBwb3J0ZWQgbWVh bnMgb2YgYXV0aGVudGljYXRpb24pIHdoZW4gdGhlCiAgIGNsaWVudCBpcyByZXF1ZXN0aW5nIGFj Y2VzcyB0byB0aGUgcHJvdGVjdGVkIHJlc291cmNlcyB1bmRlciBpdHMKICAgY29udHJvbCwgb3Ig dGhvc2Ugb2YgYW5vdGhlciByZXNvdXJjZSBvd25lciB3aGljaCBoYXMgYmVlbiBwcmV2aW91c2x5 CiAgIGFycmFuZ2VkIHdpdGggdGhlIGF1dGhvcml6YXRpb24gc2VydmVyICh0aGUgbWV0aG9kIG9m IHdoaWNoIGlzIGJleW9uZAogICB0aGUgc2NvcGUgb2YgdGhpcyBzcGVjaWZpY2F0aW9uKS4KCiAg IFRoZSBjbGllbnQgY3JlZGVudGlhbHMgZ3JhbnQgdHlwZSBNVVNUIG9ubHkgYmUgdXNlZCBieSBj b25maWRlbnRpYWwKICAgY2xpZW50cy4KCgoKSGFtbWVyLCBldCBhbC4gICAgICAgICAgRXhwaXJl cyBEZWNlbWJlciAxMCwgMjAxMiAgICAgICAgICAgICAgW1BhZ2UgMzddCgwKSW50ZXJuZXQtRHJh ZnQgICAgICAgICAgICAgICAgICBPQXV0aCAyLjAgICAgICAgICAgICAgICAgICAgICAgSnVuZSAy MDEyCgoKICAgICArLS0tLS0tLS0tKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAr LS0tLS0tLS0tLS0tLS0tKwogICAgIHwgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHwgICAgICAgICAgICAgICB8CiAgICAgfCAgICAgICAgIHw+LS0oQSktIENsaWVu dCBBdXRoZW50aWNhdGlvbiAtLS0+fCBBdXRob3JpemF0aW9uIHwKICAgICB8IENsaWVudCAgfCAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICBTZXJ2ZXIgICAgfAogICAgIHwg ICAgICAgICB8PC0tKEIpLS0tLSBBY2Nlc3MgVG9rZW4gLS0tLS0tLS0tPHwgICAgICAgICAgICAg ICB8CiAgICAgfCAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAg ICAgICAgICAgICAgIHwKICAgICArLS0tLS0tLS0tKyAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICArLS0tLS0tLS0tLS0tLS0tKwoKCiAgICAgICAgICAgICAgICAgICAgIEZpZ3VyZSA2 OiBDbGllbnQgQ3JlZGVudGlhbHMgRmxvdwoKICAgVGhlIGZsb3cgaWxsdXN0cmF0ZWQgaW4gRmln dXJlIDYgaW5jbHVkZXMgdGhlIGZvbGxvd2luZyBzdGVwczoKCiAgIChBKSAgVGhlIGNsaWVudCBh dXRoZW50aWNhdGVzIHdpdGggdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGFuZAogICAgICAgIHJl cXVlc3RzIGFuIGFjY2VzcyB0b2tlbiBmcm9tIHRoZSB0b2tlbiBlbmRwb2ludC4KICAgKEIpICBU aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYXV0aGVudGljYXRlcyB0aGUgY2xpZW50LCBhbmQgaWYg dmFsaWQKICAgICAgICBpc3N1ZXMgYW4gYWNjZXNzIHRva2VuLgoKNC40LjEuICBBdXRob3JpemF0 aW9uIFJlcXVlc3QgYW5kIFJlc3BvbnNlCgogICBTaW5jZSB0aGUgY2xpZW50IGF1dGhlbnRpY2F0 aW9uIGlzIHVzZWQgYXMgdGhlIGF1dGhvcml6YXRpb24gZ3JhbnQsCiAgIG5vIGFkZGl0aW9uYWwg YXV0aG9yaXphdGlvbiByZXF1ZXN0IGlzIG5lZWRlZC4KCjQuNC4yLiAgQWNjZXNzIFRva2VuIFJl cXVlc3QKCiAgIFRoZSBjbGllbnQgbWFrZXMgYSByZXF1ZXN0IHRvIHRoZSB0b2tlbiBlbmRwb2lu dCBieSBhZGRpbmcgdGhlCiAgIGZvbGxvd2luZyBwYXJhbWV0ZXJzIHVzaW5nIHRoZSAiYXBwbGlj YXRpb24veC13d3ctZm9ybS11cmxlbmNvZGVkIgogICBmb3JtYXQgaW4gdGhlIEhUVFAgcmVxdWVz dCBlbnRpdHktYm9keToKCiAgIGdyYW50X3R5cGUKICAgICAgICAgUkVRVUlSRUQuICBWYWx1ZSBN VVNUIGJlIHNldCB0byAiY2xpZW50X2NyZWRlbnRpYWxzIi4KICAgc2NvcGUKICAgICAgICAgT1BU SU9OQUwuICBUaGUgc2NvcGUgb2YgdGhlIGFjY2VzcyByZXF1ZXN0IGFzIGRlc2NyaWJlZCBieQog ICAgICAgICBTZWN0aW9uIDMuMy4KCiAgIFRoZSBjbGllbnQgTVVTVCBhdXRoZW50aWNhdGUgd2l0 aCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYXMKICAgZGVzY3JpYmVkIGluIFNlY3Rpb24gMy4y LjEuCgogICBGb3IgZXhhbXBsZSwgdGhlIGNsaWVudCBtYWtlcyB0aGUgZm9sbG93aW5nIEhUVFAg cmVxdWVzdCB1c2luZwogICB0cmFuc3BvcnQtbGF5ZXIgc2VjdXJpdHkgKGV4dHJhIGxpbmUgYnJl YWtzIGFyZSBmb3IgZGlzcGxheSBwdXJwb3NlcwogICBvbmx5KToKCgogICAgIFBPU1QgL3Rva2Vu IEhUVFAvMS4xCiAgICAgSG9zdDogc2VydmVyLmV4YW1wbGUuY29tCiAgICAgQXV0aG9yaXphdGlv bjogQmFzaWMgY3paQ2FHUlNhM0YwTXpwbldERm1RbUYwTTJKVwogICAgIENvbnRlbnQtVHlwZTog YXBwbGljYXRpb24veC13d3ctZm9ybS11cmxlbmNvZGVkO2NoYXJzZXQ9VVRGLTgKCgoKCkhhbW1l ciwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgRGVjZW1iZXIgMTAsIDIwMTIgICAgICAgICAgICAg IFtQYWdlIDM4XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgT0F1dGggMi4wICAg ICAgICAgICAgICAgICAgICAgIEp1bmUgMjAxMgoKCiAgICAgZ3JhbnRfdHlwZT1jbGllbnRfY3Jl ZGVudGlhbHMKCgogICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVTVCBhdXRoZW50aWNhdGUg dGhlIGNsaWVudC4KCjQuNC4zLiAgQWNjZXNzIFRva2VuIFJlc3BvbnNlCgogICBJZiB0aGUgYWNj ZXNzIHRva2VuIHJlcXVlc3QgaXMgdmFsaWQgYW5kIGF1dGhvcml6ZWQsIHRoZQogICBhdXRob3Jp emF0aW9uIHNlcnZlciBpc3N1ZXMgYW4gYWNjZXNzIHRva2VuIGFzIGRlc2NyaWJlZCBpbgogICBT ZWN0aW9uIDUuMS4gIEEgcmVmcmVzaCB0b2tlbiBTSE9VTEQgTk9UIGJlIGluY2x1ZGVkLiAgSWYg dGhlIHJlcXVlc3QKICAgZmFpbGVkIGNsaWVudCBhdXRoZW50aWNhdGlvbiBvciBpcyBpbnZhbGlk LCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIKICAgcmV0dXJucyBhbiBlcnJvciByZXNwb25zZSBh cyBkZXNjcmliZWQgaW4gU2VjdGlvbiA1LjIuCgogICBBbiBleGFtcGxlIHN1Y2Nlc3NmdWwgcmVz cG9uc2U6CgoKICAgICBIVFRQLzEuMSAyMDAgT0sKICAgICBDb250ZW50LVR5cGU6IGFwcGxpY2F0 aW9uL2pzb247Y2hhcnNldD1VVEYtOAogICAgIENhY2hlLUNvbnRyb2w6IG5vLXN0b3JlCiAgICAg UHJhZ21hOiBuby1jYWNoZQoKICAgICB7CiAgICAgICAiYWNjZXNzX3Rva2VuIjoiMllvdG5GWkZF anIxekNzaWNNV3BBQSIsCiAgICAgICAidG9rZW5fdHlwZSI6ImV4YW1wbGUiLAogICAgICAgImV4 cGlyZXNfaW4iOjM2MDAsCiAgICAgICAiZXhhbXBsZV9wYXJhbWV0ZXIiOiJleGFtcGxlX3ZhbHVl IgogICAgIH0KCgo0LjUuICBFeHRlbnNpb24gR3JhbnRzCgogICBUaGUgY2xpZW50IHVzZXMgYW4g ZXh0ZW5zaW9uIGdyYW50IHR5cGUgYnkgc3BlY2lmeWluZyB0aGUgZ3JhbnQgdHlwZQogICB1c2lu ZyBhbiBhYnNvbHV0ZSBVUkkgKGRlZmluZWQgYnkgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyKSBh cyB0aGUKICAgdmFsdWUgb2YgdGhlICJncmFudF90eXBlIiBwYXJhbWV0ZXIgb2YgdGhlIHRva2Vu IGVuZHBvaW50LCBhbmQgYnkKICAgYWRkaW5nIGFueSBhZGRpdGlvbmFsIHBhcmFtZXRlcnMgbmVj ZXNzYXJ5LgoKICAgRm9yIGV4YW1wbGUsIHRvIHJlcXVlc3QgYW4gYWNjZXNzIHRva2VuIHVzaW5n IGEgU0FNTCAyLjAgYXNzZXJ0aW9uCiAgIGdyYW50IHR5cGUgYXMgZGVmaW5lZCBieSBbSS1ELmll dGYtb2F1dGgtc2FtbDItYmVhcmVyXSwgdGhlIGNsaWVudAogICBtYWtlcyB0aGUgZm9sbG93aW5n IEhUVFAgcmVxdWVzdCB1c2luZyBUTFMgKGxpbmUgYnJlYWtzIGFyZSBmb3IKICAgZGlzcGxheSBw dXJwb3NlcyBvbmx5KToKCgogICAgIFBPU1QgL3Rva2VuIEhUVFAvMS4xCiAgICAgSG9zdDogc2Vy dmVyLmV4YW1wbGUuY29tCiAgICAgQ29udGVudC1UeXBlOiBhcHBsaWNhdGlvbi94LXd3dy1mb3Jt LXVybGVuY29kZWQ7Y2hhcnNldD1VVEYtOAoKICAgICBncmFudF90eXBlPXVybiUzQWlldGYlM0Fw YXJhbXMlM0FvYXV0aCUzQWdyYW50LXR5cGUlM0FzYW1sMi0KICAgICBiZWFyZXImYXNzZXJ0aW9u PVBFRnpjMlZ5ZEdsdmJpQkpjM04xWlVsdWMzUmhiblE5SWpJd01URXRNRFUKCgoKSGFtbWVyLCBl dCBhbC4gICAgICAgICAgRXhwaXJlcyBEZWNlbWJlciAxMCwgMjAxMiAgICAgICAgICAgICAgW1Bh Z2UgMzldCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICBPQXV0aCAyLjAgICAgICAg ICAgICAgICAgICAgICAgSnVuZSAyMDEyCgoKICAgICBbLi4ub21pdHRlZCBmb3IgYnJldml0eS4u Ll1hRzVUZEdGMFpXMWxiblEtUEM5QmMzTmxjblJwYjI0LQoKCiAgIElmIHRoZSBhY2Nlc3MgdG9r ZW4gcmVxdWVzdCBpcyB2YWxpZCBhbmQgYXV0aG9yaXplZCwgdGhlCiAgIGF1dGhvcml6YXRpb24g c2VydmVyIGlzc3VlcyBhbiBhY2Nlc3MgdG9rZW4gYW5kIG9wdGlvbmFsIHJlZnJlc2gKICAgdG9r ZW4gYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gNS4xLiAgSWYgdGhlIHJlcXVlc3QgZmFpbGVkIGNs aWVudAogICBhdXRoZW50aWNhdGlvbiBvciBpcyBpbnZhbGlkLCB0aGUgYXV0aG9yaXphdGlvbiBz ZXJ2ZXIgcmV0dXJucyBhbgogICBlcnJvciByZXNwb25zZSBhcyBkZXNjcmliZWQgaW4gU2VjdGlv biA1LjIuCgoKNS4gIElzc3VpbmcgYW4gQWNjZXNzIFRva2VuCgogICBJZiB0aGUgYWNjZXNzIHRv a2VuIHJlcXVlc3QgaXMgdmFsaWQgYW5kIGF1dGhvcml6ZWQsIHRoZQogICBhdXRob3JpemF0aW9u IHNlcnZlciBpc3N1ZXMgYW4gYWNjZXNzIHRva2VuIGFuZCBvcHRpb25hbCByZWZyZXNoCiAgIHRv a2VuIGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDUuMS4gIElmIHRoZSByZXF1ZXN0IGZhaWxlZCBj bGllbnQKICAgYXV0aGVudGljYXRpb24gb3IgaXMgaW52YWxpZCwgdGhlIGF1dGhvcml6YXRpb24g c2VydmVyIHJldHVybnMgYW4KICAgZXJyb3IgcmVzcG9uc2UgYXMgZGVzY3JpYmVkIGluIFNlY3Rp b24gNS4yLgoKNS4xLiAgU3VjY2Vzc2Z1bCBSZXNwb25zZQoKICAgVGhlIGF1dGhvcml6YXRpb24g c2VydmVyIGlzc3VlcyBhbiBhY2Nlc3MgdG9rZW4gYW5kIG9wdGlvbmFsIHJlZnJlc2gKICAgdG9r ZW4sIGFuZCBjb25zdHJ1Y3RzIHRoZSByZXNwb25zZSBieSBhZGRpbmcgdGhlIGZvbGxvd2luZyBw YXJhbWV0ZXJzCiAgIHRvIHRoZSBlbnRpdHkgYm9keSBvZiB0aGUgSFRUUCByZXNwb25zZSB3aXRo IGEgMjAwIChPSykgc3RhdHVzIGNvZGU6CgogICBhY2Nlc3NfdG9rZW4KICAgICAgICAgUkVRVUlS RUQuICBUaGUgYWNjZXNzIHRva2VuIGlzc3VlZCBieSB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIu CiAgIHRva2VuX3R5cGUKICAgICAgICAgUkVRVUlSRUQuICBUaGUgdHlwZSBvZiB0aGUgdG9rZW4g aXNzdWVkIGFzIGRlc2NyaWJlZCBpbgogICAgICAgICBTZWN0aW9uIDcuMS4gIFZhbHVlIGlzIGNh c2UgaW5zZW5zaXRpdmUuCiAgIGV4cGlyZXNfaW4KICAgICAgICAgUkVDT01NRU5ERUQuICBUaGUg bGlmZXRpbWUgaW4gc2Vjb25kcyBvZiB0aGUgYWNjZXNzIHRva2VuLiAgRm9yCiAgICAgICAgIGV4 YW1wbGUsIHRoZSB2YWx1ZSAiMzYwMCIgZGVub3RlcyB0aGF0IHRoZSBhY2Nlc3MgdG9rZW4gd2ls bAogICAgICAgICBleHBpcmUgaW4gb25lIGhvdXIgZnJvbSB0aGUgdGltZSB0aGUgcmVzcG9uc2Ug d2FzIGdlbmVyYXRlZC4KICAgICAgICAgSWYgb21pdHRlZCwgdGhlIGF1dGhvcml6YXRpb24gc2Vy dmVyIFNIT1VMRCBwcm92aWRlIHRoZQogICAgICAgICBleHBpcmF0aW9uIHRpbWUgdmlhIG90aGVy IG1lYW5zIG9yIGRvY3VtZW50IHRoZSBkZWZhdWx0IHZhbHVlLgogICByZWZyZXNoX3Rva2VuCiAg ICAgICAgIE9QVElPTkFMLiAgVGhlIHJlZnJlc2ggdG9rZW4gd2hpY2ggY2FuIGJlIHVzZWQgdG8g b2J0YWluIG5ldwogICAgICAgICBhY2Nlc3MgdG9rZW5zIHVzaW5nIHRoZSBzYW1lIGF1dGhvcml6 YXRpb24gZ3JhbnQgYXMgZGVzY3JpYmVkCiAgICAgICAgIGluIFNlY3Rpb24gNi4KICAgc2NvcGUK ICAgICAgICAgT1BUSU9OQUwsIGlmIGlkZW50aWNhbCB0byB0aGUgc2NvcGUgcmVxdWVzdGVkIGJ5 IHRoZSBjbGllbnQsCiAgICAgICAgIG90aGVyd2lzZSBSRVFVSVJFRC4gIFRoZSBzY29wZSBvZiB0 aGUgYWNjZXNzIHRva2VuIGFzIGRlc2NyaWJlZAogICAgICAgICBieSBTZWN0aW9uIDMuMy4KCiAg IFRoZSBwYXJhbWV0ZXJzIGFyZSBpbmNsdWRlZCBpbiB0aGUgZW50aXR5IGJvZHkgb2YgdGhlIEhU VFAgcmVzcG9uc2UKICAgdXNpbmcgdGhlICJhcHBsaWNhdGlvbi9qc29uIiBtZWRpYSB0eXBlIGFz IGRlZmluZWQgYnkgW1JGQzQ2MjddLiAgVGhlCiAgIHBhcmFtZXRlcnMgYXJlIHNlcmlhbGl6ZWQg aW50byBhIEpTT04gc3RydWN0dXJlIGJ5IGFkZGluZyBlYWNoCiAgIHBhcmFtZXRlciBhdCB0aGUg aGlnaGVzdCBzdHJ1Y3R1cmUgbGV2ZWwuICBQYXJhbWV0ZXIgbmFtZXMgYW5kIHN0cmluZwoKCgpI YW1tZXIsIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIERlY2VtYmVyIDEwLCAyMDEyICAgICAgICAg ICAgICBbUGFnZSA0MF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgIE9BdXRoIDIu MCAgICAgICAgICAgICAgICAgICAgICBKdW5lIDIwMTIKCgogICB2YWx1ZXMgYXJlIGluY2x1ZGVk IGFzIEpTT04gc3RyaW5ncy4gIE51bWVyaWNhbCB2YWx1ZXMgYXJlIGluY2x1ZGVkCiAgIGFzIEpT T04gbnVtYmVycy4gIFRoZSBvcmRlciBvZiBwYXJhbWV0ZXJzIGRvZXMgbm90IG1hdHRlciBhbmQg Y2FuCiAgIHZhcnkuCgogICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVTVCBpbmNsdWRlIHRo ZSBIVFRQICJDYWNoZS1Db250cm9sIgogICByZXNwb25zZSBoZWFkZXIgZmllbGQgW1JGQzI2MTZd IHdpdGggYSB2YWx1ZSBvZiAibm8tc3RvcmUiIGluIGFueQogICByZXNwb25zZSBjb250YWluaW5n IHRva2VucywgY3JlZGVudGlhbHMsIG9yIG90aGVyIHNlbnNpdGl2ZQogICBpbmZvcm1hdGlvbiwg YXMgd2VsbCBhcyB0aGUgIlByYWdtYSIgcmVzcG9uc2UgaGVhZGVyIGZpZWxkIFtSRkMyNjE2XQog ICB3aXRoIGEgdmFsdWUgb2YgIm5vLWNhY2hlIi4KCiAgIEZvciBleGFtcGxlOgoKCiAgICAgSFRU UC8xLjEgMjAwIE9LCiAgICAgQ29udGVudC1UeXBlOiBhcHBsaWNhdGlvbi9qc29uO2NoYXJzZXQ9 VVRGLTgKICAgICBDYWNoZS1Db250cm9sOiBuby1zdG9yZQogICAgIFByYWdtYTogbm8tY2FjaGUK CiAgICAgewogICAgICAgImFjY2Vzc190b2tlbiI6IjJZb3RuRlpGRWpyMXpDc2ljTVdwQUEiLAog ICAgICAgInRva2VuX3R5cGUiOiJleGFtcGxlIiwKICAgICAgICJleHBpcmVzX2luIjozNjAwLAog ICAgICAgInJlZnJlc2hfdG9rZW4iOiJ0R3p2M0pPa0YwWEc1UXgyVGxLV0lBIiwKICAgICAgICJl eGFtcGxlX3BhcmFtZXRlciI6ImV4YW1wbGVfdmFsdWUiCiAgICAgfQoKCiAgIFRoZSBjbGllbnQg TVVTVCBpZ25vcmUgdW5yZWNvZ25pemVkIHZhbHVlIG5hbWVzIGluIHRoZSByZXNwb25zZS4gIFRo ZQogICBzaXplcyBvZiB0b2tlbnMgYW5kIG90aGVyIHZhbHVlcyByZWNlaXZlZCBmcm9tIHRoZSBh dXRob3JpemF0aW9uCiAgIHNlcnZlciBhcmUgbGVmdCB1bmRlZmluZWQuICBUaGUgY2xpZW50IHNo b3VsZCBhdm9pZCBtYWtpbmcKICAgYXNzdW1wdGlvbnMgYWJvdXQgdmFsdWUgc2l6ZXMuICBUaGUg YXV0aG9yaXphdGlvbiBzZXJ2ZXIgU0hPVUxECiAgIGRvY3VtZW50IHRoZSBzaXplIG9mIGFueSB2 YWx1ZSBpdCBpc3N1ZXMuCgo1LjIuICBFcnJvciBSZXNwb25zZQoKICAgVGhlIGF1dGhvcml6YXRp b24gc2VydmVyIHJlc3BvbmRzIHdpdGggYW4gSFRUUCA0MDAgKEJhZCBSZXF1ZXN0KQogICBzdGF0 dXMgY29kZSAodW5sZXNzIHNwZWNpZmllZCBvdGhlcndpc2UpIGFuZCBpbmNsdWRlcyB0aGUgZm9s bG93aW5nCiAgIHBhcmFtZXRlcnMgd2l0aCB0aGUgcmVzcG9uc2U6CgogICBlcnJvcgogICAgICAg ICBSRVFVSVJFRC4gIEEgc2luZ2xlIEFTQ0lJIFtVU0FTQ0lJXSBlcnJvciBjb2RlIGZyb20gdGhl CiAgICAgICAgIGZvbGxvd2luZzoKICAgICAgICAgaW52YWxpZF9yZXF1ZXN0CiAgICAgICAgICAg ICAgIFRoZSByZXF1ZXN0IGlzIG1pc3NpbmcgYSByZXF1aXJlZCBwYXJhbWV0ZXIsIGluY2x1ZGVz IGFuCiAgICAgICAgICAgICAgIHVuc3VwcG9ydGVkIHBhcmFtZXRlciB2YWx1ZSAob3RoZXIgdGhh biBncmFudCB0eXBlKSwKICAgICAgICAgICAgICAgcmVwZWF0cyBhIHBhcmFtZXRlciwgaW5jbHVk ZXMgbXVsdGlwbGUgY3JlZGVudGlhbHMsCiAgICAgICAgICAgICAgIHV0aWxpemVzIG1vcmUgdGhh biBvbmUgbWVjaGFuaXNtIGZvciBhdXRoZW50aWNhdGluZyB0aGUKICAgICAgICAgICAgICAgY2xp ZW50LCBvciBpcyBvdGhlcndpc2UgbWFsZm9ybWVkLgoKCgpIYW1tZXIsIGV0IGFsLiAgICAgICAg ICBFeHBpcmVzIERlY2VtYmVyIDEwLCAyMDEyICAgICAgICAgICAgICBbUGFnZSA0MV0KDApJbnRl cm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgIE9BdXRoIDIuMCAgICAgICAgICAgICAgICAgICAg ICBKdW5lIDIwMTIKCgogICAgICAgICBpbnZhbGlkX2NsaWVudAogICAgICAgICAgICAgICBDbGll bnQgYXV0aGVudGljYXRpb24gZmFpbGVkIChlLmcuIHVua25vd24gY2xpZW50LCBubwogICAgICAg ICAgICAgICBjbGllbnQgYXV0aGVudGljYXRpb24gaW5jbHVkZWQsIG9yIHVuc3VwcG9ydGVkCiAg ICAgICAgICAgICAgIGF1dGhlbnRpY2F0aW9uIG1ldGhvZCkuICBUaGUgYXV0aG9yaXphdGlvbiBz ZXJ2ZXIgTUFZCiAgICAgICAgICAgICAgIHJldHVybiBhbiBIVFRQIDQwMSAoVW5hdXRob3JpemVk KSBzdGF0dXMgY29kZSB0byBpbmRpY2F0ZQogICAgICAgICAgICAgICB3aGljaCBIVFRQIGF1dGhl bnRpY2F0aW9uIHNjaGVtZXMgYXJlIHN1cHBvcnRlZC4gIElmIHRoZQogICAgICAgICAgICAgICBj bGllbnQgYXR0ZW1wdGVkIHRvIGF1dGhlbnRpY2F0ZSB2aWEgdGhlICJBdXRob3JpemF0aW9uIgog ICAgICAgICAgICAgICByZXF1ZXN0IGhlYWRlciBmaWVsZCwgdGhlIGF1dGhvcml6YXRpb24gc2Vy dmVyIE1VU1QKICAgICAgICAgICAgICAgcmVzcG9uZCB3aXRoIGFuIEhUVFAgNDAxIChVbmF1dGhv cml6ZWQpIHN0YXR1cyBjb2RlLCBhbmQKICAgICAgICAgICAgICAgaW5jbHVkZSB0aGUgIldXVy1B dXRoZW50aWNhdGUiIHJlc3BvbnNlIGhlYWRlciBmaWVsZAogICAgICAgICAgICAgICBtYXRjaGlu ZyB0aGUgYXV0aGVudGljYXRpb24gc2NoZW1lIHVzZWQgYnkgdGhlIGNsaWVudC4KICAgICAgICAg aW52YWxpZF9ncmFudAogICAgICAgICAgICAgICBUaGUgcHJvdmlkZWQgYXV0aG9yaXphdGlvbiBn cmFudCAoZS5nLiBhdXRob3JpemF0aW9uCiAgICAgICAgICAgICAgIGNvZGUsIHJlc291cmNlIG93 bmVyIGNyZWRlbnRpYWxzKSBvciByZWZyZXNoIHRva2VuIGlzCiAgICAgICAgICAgICAgIGludmFs aWQsIGV4cGlyZWQsIHJldm9rZWQsIGRvZXMgbm90IG1hdGNoIHRoZSByZWRpcmVjdGlvbgogICAg ICAgICAgICAgICBVUkkgdXNlZCBpbiB0aGUgYXV0aG9yaXphdGlvbiByZXF1ZXN0LCBvciB3YXMg aXNzdWVkIHRvCiAgICAgICAgICAgICAgIGFub3RoZXIgY2xpZW50LgogICAgICAgICB1bmF1dGhv cml6ZWRfY2xpZW50CiAgICAgICAgICAgICAgIFRoZSBhdXRoZW50aWNhdGVkIGNsaWVudCBpcyBu b3QgYXV0aG9yaXplZCB0byB1c2UgdGhpcwogICAgICAgICAgICAgICBhdXRob3JpemF0aW9uIGdy YW50IHR5cGUuCiAgICAgICAgIHVuc3VwcG9ydGVkX2dyYW50X3R5cGUKICAgICAgICAgICAgICAg VGhlIGF1dGhvcml6YXRpb24gZ3JhbnQgdHlwZSBpcyBub3Qgc3VwcG9ydGVkIGJ5IHRoZQogICAg ICAgICAgICAgICBhdXRob3JpemF0aW9uIHNlcnZlci4KICAgICAgICAgaW52YWxpZF9zY29wZQog ICAgICAgICAgICAgICBUaGUgcmVxdWVzdGVkIHNjb3BlIGlzIGludmFsaWQsIHVua25vd24sIG1h bGZvcm1lZCwgb3IKICAgICAgICAgICAgICAgZXhjZWVkcyB0aGUgc2NvcGUgZ3JhbnRlZCBieSB0 aGUgcmVzb3VyY2Ugb3duZXIuCiAgICAgICAgIFZhbHVlcyBmb3IgdGhlICJlcnJvciIgcGFyYW1l dGVyIE1VU1QgTk9UIGluY2x1ZGUgY2hhcmFjdGVycwogICAgICAgICBvdXRzaWRlIHRoZSBzZXQg JXgyMC0yMSAvICV4MjMtNUIgLyAleDVELTdFLgogICBlcnJvcl9kZXNjcmlwdGlvbgogICAgICAg ICBPUFRJT05BTC4gIEEgaHVtYW4tcmVhZGFibGUgQVNDSUkgW1VTQVNDSUldIHRleHQgcHJvdmlk aW5nCiAgICAgICAgIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24sIHVzZWQgdG8gYXNzaXN0IHRoZSBj bGllbnQgZGV2ZWxvcGVyIGluCiAgICAgICAgIHVuZGVyc3RhbmRpbmcgdGhlIGVycm9yIHRoYXQg b2NjdXJyZWQuCiAgICAgICAgIFZhbHVlcyBmb3IgdGhlICJlcnJvcl9kZXNjcmlwdGlvbiIgcGFy YW1ldGVyIE1VU1QgTk9UIGluY2x1ZGUKICAgICAgICAgY2hhcmFjdGVycyBvdXRzaWRlIHRoZSBz ZXQgJXgyMC0yMSAvICV4MjMtNUIgLyAleDVELTdFLgogICBlcnJvcl91cmkKICAgICAgICAgT1BU SU9OQUwuICBBIFVSSSBpZGVudGlmeWluZyBhIGh1bWFuLXJlYWRhYmxlIHdlYiBwYWdlIHdpdGgK ICAgICAgICAgaW5mb3JtYXRpb24gYWJvdXQgdGhlIGVycm9yLCB1c2VkIHRvIHByb3ZpZGUgdGhl IGNsaWVudAogICAgICAgICBkZXZlbG9wZXIgd2l0aCBhZGRpdGlvbmFsIGluZm9ybWF0aW9uIGFi b3V0IHRoZSBlcnJvci4KICAgICAgICAgVmFsdWVzIGZvciB0aGUgImVycm9yX3VyaSIgcGFyYW1l dGVyIE1VU1QgY29uZm9ybSB0byB0aGUgVVJJLQogICAgICAgICBSZWZlcmVuY2Ugc3ludGF4LCBh bmQgdGh1cyBNVVNUIE5PVCBpbmNsdWRlIGNoYXJhY3RlcnMgb3V0c2lkZQogICAgICAgICB0aGUg c2V0ICV4MjEgLyAleDIzLTVCIC8gJXg1RC03RS4KCiAgIFRoZSBwYXJhbWV0ZXJzIGFyZSBpbmNs dWRlZCBpbiB0aGUgZW50aXR5IGJvZHkgb2YgdGhlIEhUVFAgcmVzcG9uc2UKICAgdXNpbmcgdGhl ICJhcHBsaWNhdGlvbi9qc29uIiBtZWRpYSB0eXBlIGFzIGRlZmluZWQgYnkgW1JGQzQ2MjddLiAg VGhlCiAgIHBhcmFtZXRlcnMgYXJlIHNlcmlhbGl6ZWQgaW50byBhIEpTT04gc3RydWN0dXJlIGJ5 IGFkZGluZyBlYWNoCiAgIHBhcmFtZXRlciBhdCB0aGUgaGlnaGVzdCBzdHJ1Y3R1cmUgbGV2ZWwu ICBQYXJhbWV0ZXIgbmFtZXMgYW5kIHN0cmluZwogICB2YWx1ZXMgYXJlIGluY2x1ZGVkIGFzIEpT T04gc3RyaW5ncy4gIE51bWVyaWNhbCB2YWx1ZXMgYXJlIGluY2x1ZGVkCiAgIGFzIEpTT04gbnVt YmVycy4gIFRoZSBvcmRlciBvZiBwYXJhbWV0ZXJzIGRvZXMgbm90IG1hdHRlciBhbmQgY2FuCgoK CkhhbW1lciwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgRGVjZW1iZXIgMTAsIDIwMTIgICAgICAg ICAgICAgIFtQYWdlIDQyXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgT0F1dGgg Mi4wICAgICAgICAgICAgICAgICAgICAgIEp1bmUgMjAxMgoKCiAgIHZhcnkuCgogICBGb3IgZXhh bXBsZToKCgogICAgIEhUVFAvMS4xIDQwMCBCYWQgUmVxdWVzdAogICAgIENvbnRlbnQtVHlwZTog YXBwbGljYXRpb24vanNvbjtjaGFyc2V0PVVURi04CiAgICAgQ2FjaGUtQ29udHJvbDogbm8tc3Rv cmUKICAgICBQcmFnbWE6IG5vLWNhY2hlCgogICAgIHsKICAgICAgICJlcnJvciI6ImludmFsaWRf cmVxdWVzdCIKICAgICB9CgoKCjYuICBSZWZyZXNoaW5nIGFuIEFjY2VzcyBUb2tlbgoKICAgSWYg dGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGlzc3VlZCBhIHJlZnJlc2ggdG9rZW4gdG8gdGhlIGNs aWVudCwgdGhlCiAgIGNsaWVudCBtYWtlcyBhIHJlZnJlc2ggcmVxdWVzdCB0byB0aGUgdG9rZW4g ZW5kcG9pbnQgYnkgYWRkaW5nIHRoZQogICBmb2xsb3dpbmcgcGFyYW1ldGVycyB1c2luZyB0aGUg ImFwcGxpY2F0aW9uL3gtd3d3LWZvcm0tdXJsZW5jb2RlZCIKICAgZm9ybWF0IGluIHRoZSBIVFRQ IHJlcXVlc3QgZW50aXR5LWJvZHk6CgogICBncmFudF90eXBlCiAgICAgICAgIFJFUVVJUkVELiAg VmFsdWUgTVVTVCBiZSBzZXQgdG8gInJlZnJlc2hfdG9rZW4iLgogICByZWZyZXNoX3Rva2VuCiAg ICAgICAgIFJFUVVJUkVELiAgVGhlIHJlZnJlc2ggdG9rZW4gaXNzdWVkIHRvIHRoZSBjbGllbnQu CiAgIHNjb3BlCiAgICAgICAgIE9QVElPTkFMLiAgVGhlIHNjb3BlIG9mIHRoZSBhY2Nlc3MgcmVx dWVzdCBhcyBkZXNjcmliZWQgYnkKICAgICAgICAgU2VjdGlvbiAzLjMuICBUaGUgcmVxdWVzdGVk IHNjb3BlIE1VU1QgTk9UIGluY2x1ZGUgYW55IHNjb3BlCiAgICAgICAgIG5vdCBvcmlnaW5hbGx5 IGdyYW50ZWQgYnkgdGhlIHJlc291cmNlIG93bmVyLCBhbmQgaWYgb21pdHRlZCBpcwogICAgICAg ICB0cmVhdGVkIGFzIGVxdWFsIHRvIHRoZSBzY29wZSBvcmlnaW5hbGx5IGdyYW50ZWQgYnkgdGhl CiAgICAgICAgIHJlc291cmNlIG93bmVyLgoKICAgQmVjYXVzZSByZWZyZXNoIHRva2VucyBhcmUg dHlwaWNhbGx5IGxvbmctbGFzdGluZyBjcmVkZW50aWFscyB1c2VkIHRvCiAgIHJlcXVlc3QgYWRk aXRpb25hbCBhY2Nlc3MgdG9rZW5zLCB0aGUgcmVmcmVzaCB0b2tlbiBpcyBib3VuZCB0byB0aGUK ICAgY2xpZW50IHdoaWNoIGl0IHdhcyBpc3N1ZWQuICBJZiB0aGUgY2xpZW50IHR5cGUgaXMgY29u ZmlkZW50aWFsIG9yCiAgIHRoZSBjbGllbnQgd2FzIGlzc3VlZCBjbGllbnQgY3JlZGVudGlhbHMg KG9yIGFzc2lnbmVkIG90aGVyCiAgIGF1dGhlbnRpY2F0aW9uIHJlcXVpcmVtZW50cyksIHRoZSBj bGllbnQgTVVTVCBhdXRoZW50aWNhdGUgd2l0aCB0aGUKICAgYXV0aG9yaXphdGlvbiBzZXJ2ZXIg YXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gMy4yLjEuCgoKCgoKCgoKCgoKSGFtbWVyLCBldCBhbC4g ICAgICAgICAgRXhwaXJlcyBEZWNlbWJlciAxMCwgMjAxMiAgICAgICAgICAgICAgW1BhZ2UgNDNd CgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICBPQXV0aCAyLjAgICAgICAgICAgICAg ICAgICAgICAgSnVuZSAyMDEyCgoKICAgRm9yIGV4YW1wbGUsIHRoZSBjbGllbnQgbWFrZXMgdGhl IGZvbGxvd2luZyBIVFRQIHJlcXVlc3QgdXNpbmcKICAgdHJhbnNwb3J0LWxheWVyIHNlY3VyaXR5 IChleHRyYSBsaW5lIGJyZWFrcyBhcmUgZm9yIGRpc3BsYXkgcHVycG9zZXMKICAgb25seSk6CgoK ICAgICBQT1NUIC90b2tlbiBIVFRQLzEuMQogICAgIEhvc3Q6IHNlcnZlci5leGFtcGxlLmNvbQog ICAgIEF1dGhvcml6YXRpb246IEJhc2ljIGN6WkNhR1JTYTNGME16cG5XREZtUW1GME0ySlcKICAg ICBDb250ZW50LVR5cGU6IGFwcGxpY2F0aW9uL3gtd3d3LWZvcm0tdXJsZW5jb2RlZDtjaGFyc2V0 PVVURi04CgogICAgIGdyYW50X3R5cGU9cmVmcmVzaF90b2tlbiZyZWZyZXNoX3Rva2VuPXRHenYz Sk9rRjBYRzVReDJUbEtXSUEKCgogICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVTVDoKCiAg IG8gIHJlcXVpcmUgY2xpZW50IGF1dGhlbnRpY2F0aW9uIGZvciBjb25maWRlbnRpYWwgY2xpZW50 cyBvciBmb3IgYW55CiAgICAgIGNsaWVudCB0aGF0IHdhcyBpc3N1ZWQgY2xpZW50IGNyZWRlbnRp YWxzIChvciB3aXRoIG90aGVyCiAgICAgIGF1dGhlbnRpY2F0aW9uIHJlcXVpcmVtZW50cyksCiAg IG8gIGF1dGhlbnRpY2F0ZSB0aGUgY2xpZW50IGlmIGNsaWVudCBhdXRoZW50aWNhdGlvbiBpcyBp bmNsdWRlZCBhbmQKICAgICAgZW5zdXJlIHRoZSByZWZyZXNoIHRva2VuIHdhcyBpc3N1ZWQgdG8g dGhlIGF1dGhlbnRpY2F0ZWQgY2xpZW50LAogICAgICBhbmQKICAgbyAgdmFsaWRhdGUgdGhlIHJl ZnJlc2ggdG9rZW4uCgogICBJZiB2YWxpZCBhbmQgYXV0aG9yaXplZCwgdGhlIGF1dGhvcml6YXRp b24gc2VydmVyIGlzc3VlcyBhbiBhY2Nlc3MKICAgdG9rZW4gYXMgZGVzY3JpYmVkIGluIFNlY3Rp b24gNS4xLiAgSWYgdGhlIHJlcXVlc3QgZmFpbGVkCiAgIHZlcmlmaWNhdGlvbiBvciBpcyBpbnZh bGlkLCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgcmV0dXJucyBhbiBlcnJvcgogICByZXNwb25z ZSBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiA1LjIuCgogICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2 ZXIgTUFZIGlzc3VlIGEgbmV3IHJlZnJlc2ggdG9rZW4sIGluIHdoaWNoIGNhc2UKICAgdGhlIGNs aWVudCBNVVNUIGRpc2NhcmQgdGhlIG9sZCByZWZyZXNoIHRva2VuIGFuZCByZXBsYWNlIGl0IHdp dGggdGhlCiAgIG5ldyByZWZyZXNoIHRva2VuLiAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIE1B WSByZXZva2UgdGhlIG9sZAogICByZWZyZXNoIHRva2VuIGFmdGVyIGlzc3VpbmcgYSBuZXcgcmVm cmVzaCB0b2tlbiB0byB0aGUgY2xpZW50LiAgSWYgYQogICBuZXcgcmVmcmVzaCB0b2tlbiBpcyBp c3N1ZWQsIHRoZSByZWZyZXNoIHRva2VuIHNjb3BlIE1VU1QgYmUKICAgaWRlbnRpY2FsIHRvIHRo YXQgb2YgdGhlIHJlZnJlc2ggdG9rZW4gaW5jbHVkZWQgYnkgdGhlIGNsaWVudCBpbiB0aGUKICAg cmVxdWVzdC4KCgo3LiAgQWNjZXNzaW5nIFByb3RlY3RlZCBSZXNvdXJjZXMKCiAgIFRoZSBjbGll bnQgYWNjZXNzZXMgcHJvdGVjdGVkIHJlc291cmNlcyBieSBwcmVzZW50aW5nIHRoZSBhY2Nlc3MK ICAgdG9rZW4gdG8gdGhlIHJlc291cmNlIHNlcnZlci4gIFRoZSByZXNvdXJjZSBzZXJ2ZXIgTVVT VCB2YWxpZGF0ZSB0aGUKICAgYWNjZXNzIHRva2VuIGFuZCBlbnN1cmUgaXQgaGFzIG5vdCBleHBp cmVkIGFuZCB0aGF0IGl0cyBzY29wZSBjb3ZlcnMKICAgdGhlIHJlcXVlc3RlZCByZXNvdXJjZS4g IFRoZSBtZXRob2RzIHVzZWQgYnkgdGhlIHJlc291cmNlIHNlcnZlciB0bwogICB2YWxpZGF0ZSB0 aGUgYWNjZXNzIHRva2VuIChhcyB3ZWxsIGFzIGFueSBlcnJvciByZXNwb25zZXMpIGFyZSBiZXlv bmQKICAgdGhlIHNjb3BlIG9mIHRoaXMgc3BlY2lmaWNhdGlvbiwgYnV0IGdlbmVyYWxseSBpbnZv bHZlIGFuIGludGVyYWN0aW9uCiAgIG9yIGNvb3JkaW5hdGlvbiBiZXR3ZWVuIHRoZSByZXNvdXJj ZSBzZXJ2ZXIgYW5kIHRoZSBhdXRob3JpemF0aW9uCiAgIHNlcnZlci4KCgoKCkhhbW1lciwgZXQg YWwuICAgICAgICAgIEV4cGlyZXMgRGVjZW1iZXIgMTAsIDIwMTIgICAgICAgICAgICAgIFtQYWdl IDQ0XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgT0F1dGggMi4wICAgICAgICAg ICAgICAgICAgICAgIEp1bmUgMjAxMgoKCiAgIFRoZSBtZXRob2QgaW4gd2hpY2ggdGhlIGNsaWVu dCB1dGlsaXplcyB0aGUgYWNjZXNzIHRva2VuIHRvCiAgIGF1dGhlbnRpY2F0ZSB3aXRoIHRoZSBy ZXNvdXJjZSBzZXJ2ZXIgZGVwZW5kcyBvbiB0aGUgdHlwZSBvZiBhY2Nlc3MKICAgdG9rZW4gaXNz dWVkIGJ5IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlci4gIFR5cGljYWxseSwgaXQgaW52b2x2ZXMK ICAgdXNpbmcgdGhlIEhUVFAgIkF1dGhvcml6YXRpb24iIHJlcXVlc3QgaGVhZGVyIGZpZWxkIFtS RkMyNjE3XSB3aXRoIGFuCiAgIGF1dGhlbnRpY2F0aW9uIHNjaGVtZSBkZWZpbmVkIGJ5IHRoZSBh Y2Nlc3MgdG9rZW4gdHlwZSBzcGVjaWZpY2F0aW9uLgoKNy4xLiAgQWNjZXNzIFRva2VuIFR5cGVz CgogICBUaGUgYWNjZXNzIHRva2VuIHR5cGUgcHJvdmlkZXMgdGhlIGNsaWVudCB3aXRoIHRoZSBp bmZvcm1hdGlvbgogICByZXF1aXJlZCB0byBzdWNjZXNzZnVsbHkgdXRpbGl6ZSB0aGUgYWNjZXNz IHRva2VuIHRvIG1ha2UgYSBwcm90ZWN0ZWQKICAgcmVzb3VyY2UgcmVxdWVzdCAoYWxvbmcgd2l0 aCB0eXBlLXNwZWNpZmljIGF0dHJpYnV0ZXMpLiAgVGhlIGNsaWVudAogICBNVVNUIE5PVCB1c2Ug YW4gYWNjZXNzIHRva2VuIGlmIGl0IGRvZXMgbm90IHVuZGVyc3RhbmQgdGhlIHRva2VuCiAgIHR5 cGUuCgogICBGb3IgZXhhbXBsZSwgdGhlICJiZWFyZXIiIHRva2VuIHR5cGUgZGVmaW5lZCBpbgog ICBbSS1ELmlldGYtb2F1dGgtdjItYmVhcmVyXSBpcyB1dGlsaXplZCBieSBzaW1wbHkgaW5jbHVk aW5nIHRoZSBhY2Nlc3MKICAgdG9rZW4gc3RyaW5nIGluIHRoZSByZXF1ZXN0OgoKCiAgICAgR0VU IC9yZXNvdXJjZS8xIEhUVFAvMS4xCiAgICAgSG9zdDogZXhhbXBsZS5jb20KICAgICBBdXRob3Jp emF0aW9uOiBCZWFyZXIgbUZfOS5CNWYtNC4xSnFNCgoKICAgd2hpbGUgdGhlICJtYWMiIHRva2Vu IHR5cGUgZGVmaW5lZCBpbiBbSS1ELmlldGYtb2F1dGgtdjItaHR0cC1tYWNdIGlzCiAgIHV0aWxp emVkIGJ5IGlzc3VpbmcgYSBNQUMga2V5IHRvZ2V0aGVyIHdpdGggdGhlIGFjY2VzcyB0b2tlbiB3 aGljaCBpcwogICB1c2VkIHRvIHNpZ24gY2VydGFpbiBjb21wb25lbnRzIG9mIHRoZSBIVFRQIHJl cXVlc3RzOgoKCiAgICAgR0VUIC9yZXNvdXJjZS8xIEhUVFAvMS4xCiAgICAgSG9zdDogZXhhbXBs ZS5jb20KICAgICBBdXRob3JpemF0aW9uOiBNQUMgaWQ9Img0ODBkanM5M2hkOCIsCiAgICAgICAg ICAgICAgICAgICAgICAgIG5vbmNlPSIyNzQzMTI6ZGo4M2hzOXMiLAogICAgICAgICAgICAgICAg ICAgICAgICBtYWM9ImtEWnZkZGtuZHh2aEdSWFpodnVEakVXaEdlRT0iCgoKICAgVGhlIGFib3Zl IGV4YW1wbGVzIGFyZSBwcm92aWRlZCBmb3IgaWxsdXN0cmF0aW9uIHB1cnBvc2VzIG9ubHkuCiAg IERldmVsb3BlcnMgYXJlIGFkdmlzZWQgdG8gY29uc3VsdCB0aGUgW0ktRC5pZXRmLW9hdXRoLXYy LWJlYXJlcl0gYW5kCiAgIFtJLUQuaWV0Zi1vYXV0aC12Mi1odHRwLW1hY10gc3BlY2lmaWNhdGlv bnMgYmVmb3JlIHVzZS4KCiAgIEVhY2ggYWNjZXNzIHRva2VuIHR5cGUgZGVmaW5pdGlvbiBzcGVj aWZpZXMgdGhlIGFkZGl0aW9uYWwgYXR0cmlidXRlcwogICAoaWYgYW55KSBzZW50IHRvIHRoZSBj bGllbnQgdG9nZXRoZXIgd2l0aCB0aGUgImFjY2Vzc190b2tlbiIgcmVzcG9uc2UKICAgcGFyYW1l dGVyLiAgSXQgYWxzbyBkZWZpbmVzIHRoZSBIVFRQIGF1dGhlbnRpY2F0aW9uIG1ldGhvZCB1c2Vk IHRvCiAgIGluY2x1ZGUgdGhlIGFjY2VzcyB0b2tlbiB3aGVuIG1ha2luZyBhIHByb3RlY3RlZCBy ZXNvdXJjZSByZXF1ZXN0LgoKCgoKCgoKSGFtbWVyLCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBE ZWNlbWJlciAxMCwgMjAxMiAgICAgICAgICAgICAgW1BhZ2UgNDVdCgwKSW50ZXJuZXQtRHJhZnQg ICAgICAgICAgICAgICAgICBPQXV0aCAyLjAgICAgICAgICAgICAgICAgICAgICAgSnVuZSAyMDEy CgoKNy4yLiAgRXJyb3IgUmVzcG9uc2UKCiAgIElmIGEgcmVzb3VyY2UgYWNjZXNzIHJlcXVlc3Qg ZmFpbHMsIHRoZSByZXNvdXJjZSBzZXJ2ZXIgU0hPVUxEIGluZm9ybQogICB0aGUgY2xpZW50IG9m IHRoZSBlcnJvci4gIFdoaWxlIHRoZSBzcGVjaWZpYyBlcnJvciByZXNwb25zZXMgcG9zc2libGUK ICAgYW5kIG1ldGhvZHMgZm9yIHRyYW5zbWl0dGluZyB0aG9zZSBlcnJvcnMgd2hlbiB1c2luZyBh bnkgcGFydGljdWxhcgogICBhY2Nlc3MgdG9rZW4gdHlwZSBhcmUgYmV5b25kIHRoZSBzY29wZSBv ZiB0aGlzIHNwZWNpZmljYXRpb24sIGFueQogICAiZXJyb3IiIGNvZGUgdmFsdWVzIGRlZmluZWQg Zm9yIHVzZSB3aXRoIE9BdXRoIHJlc291cmNlIGFjY2VzcwogICBtZXRob2RzIE1VU1QgYmUgcmVn aXN0ZXJlZCAoZm9sbG93aW5nIHRoZSBwcm9jZWR1cmVzIGluCiAgIFNlY3Rpb24gMTEuNCkuCgog ICBTcGVjaWZpY2FsbHksIHdoZW4gdGhlIE9BdXRoIHJlc291cmNlIGFjY2VzcyBtZXRob2QgdXNl cyBhbiAiZXJyb3IiCiAgIHJlc3VsdCBwYXJhbWV0ZXIgdG8gcmV0dXJuIGFuIGVycm9yIGNvZGUg dmFsdWUgdGhhdCBpbmRpY2F0ZXMgdGhlCiAgIHJlc291cmNlIGFjY2VzcyBlcnJvciBlbmNvdW50 ZXJlZCwgdGhlbiB0aGVzZSBlcnJvciBjb2RlIHZhbHVlcyBNVVNUCiAgIGJlIHJlZ2lzdGVyZWQu ICBWYWx1ZXMgZm9yIHRoZXNlICJlcnJvciIgY29kZXMgTVVTVCBOT1QgaW5jbHVkZQogICBjaGFy YWN0ZXJzIG91dHNpZGUgdGhlIHNldCAleDIwLTIxIC8gJXgyMy01QiAvICV4NUQtN0UuIFdoZW4g YW4KICAgImVycm9yIiBjb2RlIHZhbHVlIGlzIHJlZ2lzdGVyZWQgZm9yIHVzZSBieSBhbiBPQXV0 aCByZXNvdXJjZSBhY2Nlc3MKICAgbWV0aG9kLCBzaG91bGQgdGhhdCBzYW1lIGNvZGUgYWxyZWFk eSBiZSByZWdpc3RlcmVkIGZvciB1c2UgYnkKICAgYW5vdGhlciBPQXV0aCByZXNvdXJjZSBhY2Nl c3MgbWV0aG9kIG9yIGF0IGEgZGlmZmVyZW50IE9BdXRoIGVycm9yCiAgIHVzYWdlIGxvY2F0aW9u LCB0aGVuIHRoZSBtZWFuaW5nIG9mIHRoYXQgZXJyb3IgY29kZSB2YWx1ZSBpbiBpbiB0aGUKICAg bmV3IHJlZ2lzdHJhdGlvbiBNVVNUIGJlIGNvbnNpc3RlbnQgd2l0aCB0aGUgaXRzIG1lYW5pbmcg aW4gcHJpb3IKICAgcmVnaXN0cmF0aW9ucy4KCiAgIFRoZSBPQXV0aCByZXNvdXJjZSBhY2Nlc3Mg ZXJyb3IgcmVnaXN0cmF0aW9uIHJlcXVpcmVtZW50IGFwcGxpZXMgb25seQogICB0byAiZXJyb3Ii IGNvZGUgdmFsdWVzIGFuZCBub3QgdG8gb3RoZXIgbWVhbnMgb2YgcmV0dXJuaW5nIGVycm9yCiAg IGluZGljYXRpb25zLCBpbmNsdWRpbmcgSFRUUCBzdGF0dXMgY29kZXMsIG9yIG90aGVyIGVycm9y LXJlbGF0ZWQKICAgcmVzdWx0IHBhcmFtZXRlcnMsIHN1Y2ggYXMgImVycm9yX2Rlc2NyaXB0aW9u IiwgImVycm9yX3VyaSIsIG9yIG90aGVyCiAgIGtpbmRzIG9mIGVycm9yIHN0YXR1cyByZXR1cm4g bWV0aG9kcyB0aGF0IG1heSBiZSBlbXBsb3llZCBieSB0aGUKICAgcmVzb3VyY2UgYWNjZXNzIG1l dGhvZC4gIFRoZXJlIGlzIG5vIHJlcXVpcmVtZW50IHRoYXQgT0F1dGggcmVzb3VyY2UKICAgYWNj ZXNzIG1ldGhvZHMgZW1wbG95IGFuICJlcnJvciIgcGFyYW1ldGVyLgoKCjguICBFeHRlbnNpYmls aXR5Cgo4LjEuICBEZWZpbmluZyBBY2Nlc3MgVG9rZW4gVHlwZXMKCiAgIEFjY2VzcyB0b2tlbiB0 eXBlcyBjYW4gYmUgZGVmaW5lZCBpbiBvbmUgb2YgdHdvIHdheXM6IHJlZ2lzdGVyZWQgaW4KICAg dGhlIGFjY2VzcyB0b2tlbiB0eXBlIHJlZ2lzdHJ5IChmb2xsb3dpbmcgdGhlIHByb2NlZHVyZXMg aW4KICAgU2VjdGlvbiAxMS4xKSwgb3IgYnkgdXNpbmcgYSB1bmlxdWUgYWJzb2x1dGUgVVJJIGFz IGl0cyBuYW1lLgoKICAgVHlwZXMgdXRpbGl6aW5nIGEgVVJJIG5hbWUgU0hPVUxEIGJlIGxpbWl0 ZWQgdG8gdmVuZG9yLXNwZWNpZmljCiAgIGltcGxlbWVudGF0aW9ucyB0aGF0IGFyZSBub3QgY29t bW9ubHkgYXBwbGljYWJsZSwgYW5kIGFyZSBzcGVjaWZpYyB0bwogICB0aGUgaW1wbGVtZW50YXRp b24gZGV0YWlscyBvZiB0aGUgcmVzb3VyY2Ugc2VydmVyIHdoZXJlIHRoZXkgYXJlCiAgIHVzZWQu CgogICBBbGwgb3RoZXIgdHlwZXMgTVVTVCBiZSByZWdpc3RlcmVkLiAgVHlwZSBuYW1lcyBNVVNU IGNvbmZvcm0gdG8gdGhlCiAgIHR5cGUtbmFtZSBBQk5GLiAgSWYgdGhlIHR5cGUgZGVmaW5pdGlv biBpbmNsdWRlcyBhIG5ldyBIVFRQCiAgIGF1dGhlbnRpY2F0aW9uIHNjaGVtZSwgdGhlIHR5cGUg bmFtZSBTSE9VTEQgYmUgaWRlbnRpY2FsIHRvIHRoZSBIVFRQCiAgIGF1dGhlbnRpY2F0aW9uIHNj aGVtZSBuYW1lIChhcyBkZWZpbmVkIGJ5IFtSRkMyNjE3XSkuICBUaGUgdG9rZW4gdHlwZQoKCgpI YW1tZXIsIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIERlY2VtYmVyIDEwLCAyMDEyICAgICAgICAg ICAgICBbUGFnZSA0Nl0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgIE9BdXRoIDIu MCAgICAgICAgICAgICAgICAgICAgICBKdW5lIDIwMTIKCgogICAiZXhhbXBsZSIgaXMgcmVzZXJ2 ZWQgZm9yIHVzZSBpbiBleGFtcGxlcy4KCgogICAgIHR5cGUtbmFtZSAgPSAxKm5hbWUtY2hhcgog ICAgIG5hbWUtY2hhciAgPSAiLSIgLyAiLiIgLyAiXyIgLyBESUdJVCAvIEFMUEhBCgoKOC4yLiAg RGVmaW5pbmcgTmV3IEVuZHBvaW50IFBhcmFtZXRlcnMKCiAgIE5ldyByZXF1ZXN0IG9yIHJlc3Bv bnNlIHBhcmFtZXRlcnMgZm9yIHVzZSB3aXRoIHRoZSBhdXRob3JpemF0aW9uCiAgIGVuZHBvaW50 IG9yIHRoZSB0b2tlbiBlbmRwb2ludCBhcmUgZGVmaW5lZCBhbmQgcmVnaXN0ZXJlZCBpbiB0aGUK ICAgcGFyYW1ldGVycyByZWdpc3RyeSBmb2xsb3dpbmcgdGhlIHByb2NlZHVyZSBpbiBTZWN0aW9u IDExLjIuCgogICBQYXJhbWV0ZXIgbmFtZXMgTVVTVCBjb25mb3JtIHRvIHRoZSBwYXJhbS1uYW1l IEFCTkYgYW5kIHBhcmFtZXRlcgogICB2YWx1ZXMgc3ludGF4IE1VU1QgYmUgd2VsbC1kZWZpbmVk IChlLmcuLCB1c2luZyBBQk5GLCBvciBhIHJlZmVyZW5jZQogICB0byB0aGUgc3ludGF4IG9mIGFu IGV4aXN0aW5nIHBhcmFtZXRlcikuCgoKICAgICBwYXJhbS1uYW1lICA9IDEqbmFtZS1jaGFyCiAg ICAgbmFtZS1jaGFyICAgPSAiLSIgLyAiLiIgLyAiXyIgLyBESUdJVCAvIEFMUEhBCgoKICAgVW5y ZWdpc3RlcmVkIHZlbmRvci1zcGVjaWZpYyBwYXJhbWV0ZXIgZXh0ZW5zaW9ucyB0aGF0IGFyZSBu b3QKICAgY29tbW9ubHkgYXBwbGljYWJsZSwgYW5kIGFyZSBzcGVjaWZpYyB0byB0aGUgaW1wbGVt ZW50YXRpb24gZGV0YWlscwogICBvZiB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgd2hlcmUgdGhl eSBhcmUgdXNlZCBTSE9VTEQgdXRpbGl6ZSBhCiAgIHZlbmRvci1zcGVjaWZpYyBwcmVmaXggdGhh dCBpcyBub3QgbGlrZWx5IHRvIGNvbmZsaWN0IHdpdGggb3RoZXIKICAgcmVnaXN0ZXJlZCB2YWx1 ZXMgKGUuZy4gYmVnaW4gd2l0aCAnY29tcGFueW5hbWVfJykuCgo4LjMuICBEZWZpbmluZyBOZXcg QXV0aG9yaXphdGlvbiBHcmFudCBUeXBlcwoKICAgTmV3IGF1dGhvcml6YXRpb24gZ3JhbnQgdHlw ZXMgY2FuIGJlIGRlZmluZWQgYnkgYXNzaWduaW5nIHRoZW0gYQogICB1bmlxdWUgYWJzb2x1dGUg VVJJIGZvciB1c2Ugd2l0aCB0aGUgImdyYW50X3R5cGUiIHBhcmFtZXRlci4gIElmIHRoZQogICBl eHRlbnNpb24gZ3JhbnQgdHlwZSByZXF1aXJlcyBhZGRpdGlvbmFsIHRva2VuIGVuZHBvaW50IHBh cmFtZXRlcnMsCiAgIHRoZXkgTVVTVCBiZSByZWdpc3RlcmVkIGluIHRoZSBPQXV0aCBwYXJhbWV0 ZXJzIHJlZ2lzdHJ5IGFzIGRlc2NyaWJlZAogICBieSBTZWN0aW9uIDExLjIuCgo4LjQuICBEZWZp bmluZyBOZXcgQXV0aG9yaXphdGlvbiBFbmRwb2ludCBSZXNwb25zZSBUeXBlcwoKICAgTmV3IHJl c3BvbnNlIHR5cGVzIGZvciB1c2Ugd2l0aCB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludCBhcmUK ICAgZGVmaW5lZCBhbmQgcmVnaXN0ZXJlZCBpbiB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludCBy ZXNwb25zZSB0eXBlCiAgIHJlZ2lzdHJ5IGZvbGxvd2luZyB0aGUgcHJvY2VkdXJlIGluIFNlY3Rp b24gMTEuMy4gIFJlc3BvbnNlIHR5cGUKICAgbmFtZXMgTVVTVCBjb25mb3JtIHRvIHRoZSByZXNw b25zZS10eXBlIEFCTkYuCgoKICAgICByZXNwb25zZS10eXBlICA9IHJlc3BvbnNlLW5hbWUgKigg U1AgcmVzcG9uc2UtbmFtZSApCiAgICAgcmVzcG9uc2UtbmFtZSAgPSAxKnJlc3BvbnNlLWNoYXIK ICAgICByZXNwb25zZS1jaGFyICA9ICJfIiAvIERJR0lUIC8gQUxQSEEKCgoKCkhhbW1lciwgZXQg YWwuICAgICAgICAgIEV4cGlyZXMgRGVjZW1iZXIgMTAsIDIwMTIgICAgICAgICAgICAgIFtQYWdl IDQ3XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgT0F1dGggMi4wICAgICAgICAg ICAgICAgICAgICAgIEp1bmUgMjAxMgoKCiAgIElmIGEgcmVzcG9uc2UgdHlwZSBjb250YWlucyBv bmUgb3IgbW9yZSBzcGFjZSBjaGFyYWN0ZXJzICgleDIwKSwgaXQKICAgaXMgY29tcGFyZWQgYXMg YSBzcGFjZS1kZWxpbWl0ZWQgbGlzdCBvZiB2YWx1ZXMgaW4gd2hpY2ggdGhlIG9yZGVyIG9mCiAg IHZhbHVlcyBkb2VzIG5vdCBtYXR0ZXIuICBPbmx5IG9uZSBvcmRlciBvZiB2YWx1ZXMgY2FuIGJl IHJlZ2lzdGVyZWQsCiAgIHdoaWNoIGNvdmVycyBhbGwgb3RoZXIgYXJyYW5nZW1lbnRzIG9mIHRo ZSBzYW1lIHNldCBvZiB2YWx1ZXMuCgogICBGb3IgZXhhbXBsZSwgdGhlIHJlc3BvbnNlIHR5cGUg InRva2VuIGNvZGUiIGlzIGxlZnQgdW5kZWZpbmVkIGJ5IHRoaXMKICAgc3BlY2lmaWNhdGlvbi4g IEhvd2V2ZXIsIGFuIGV4dGVuc2lvbiBjYW4gZGVmaW5lIGFuZCByZWdpc3RlciB0aGUKICAgInRv a2VuIGNvZGUiIHJlc3BvbnNlIHR5cGUuICBPbmNlIHJlZ2lzdGVyZWQsIHRoZSBzYW1lIGNvbWJp bmF0aW9uCiAgIGNhbm5vdCBiZSByZWdpc3RlcmVkIGFzICJjb2RlIHRva2VuIiwgYnV0IGJvdGgg dmFsdWVzIGNhbiBiZSB1c2VkIHRvCiAgIGRlbm90ZSB0aGUgc2FtZSByZXNwb25zZSB0eXBlLgoK OC41LiAgRGVmaW5pbmcgQWRkaXRpb25hbCBFcnJvciBDb2RlcwoKICAgSW4gY2FzZXMgd2hlcmUg cHJvdG9jb2wgZXh0ZW5zaW9ucyAoaS5lLiBhY2Nlc3MgdG9rZW4gdHlwZXMsCiAgIGV4dGVuc2lv biBwYXJhbWV0ZXJzLCBvciBleHRlbnNpb24gZ3JhbnQgdHlwZXMpIHJlcXVpcmUgYWRkaXRpb25h bAogICBlcnJvciBjb2RlcyB0byBiZSB1c2VkIHdpdGggdGhlIGF1dGhvcml6YXRpb24gY29kZSBn cmFudCBlcnJvcgogICByZXNwb25zZSAoU2VjdGlvbiA0LjEuMi4xKSwgdGhlIGltcGxpY2l0IGdy YW50IGVycm9yIHJlc3BvbnNlCiAgIChTZWN0aW9uIDQuMi4yLjEpLCB0aGUgdG9rZW4gZXJyb3Ig cmVzcG9uc2UgKFNlY3Rpb24gNS4yKSwgb3IgdGhlCiAgIHJlc291cmNlIGFjY2VzcyBlcnJvciBy ZXNwb25zZSAoU2VjdGlvbiA3LjIpLCBzdWNoIGVycm9yIGNvZGVzIE1BWSBiZQogICBkZWZpbmVk LgoKICAgRXh0ZW5zaW9uIGVycm9yIGNvZGVzIE1VU1QgYmUgcmVnaXN0ZXJlZCAoZm9sbG93aW5n IHRoZSBwcm9jZWR1cmVzIGluCiAgIFNlY3Rpb24gMTEuNCkgaWYgdGhlIGV4dGVuc2lvbiB0aGV5 IGFyZSB1c2VkIGluIGNvbmp1bmN0aW9uIHdpdGggaXMgYQogICByZWdpc3RlcmVkIGFjY2VzcyB0 b2tlbiB0eXBlLCBhIHJlZ2lzdGVyZWQgZW5kcG9pbnQgcGFyYW1ldGVyLCBvciBhbgogICBleHRl bnNpb24gZ3JhbnQgdHlwZS4gIEVycm9yIGNvZGVzIHVzZWQgd2l0aCB1bnJlZ2lzdGVyZWQgZXh0 ZW5zaW9ucwogICBNQVkgYmUgcmVnaXN0ZXJlZC4KCiAgIEVycm9yIGNvZGVzIE1VU1QgY29uZm9y bSB0byB0aGUgZXJyb3IgQUJORiwgYW5kIFNIT1VMRCBiZSBwcmVmaXhlZCBieQogICBhbiBpZGVu dGlmeWluZyBuYW1lIHdoZW4gcG9zc2libGUuICBGb3IgZXhhbXBsZSwgYW4gZXJyb3IgaWRlbnRp ZnlpbmcKICAgYW4gaW52YWxpZCB2YWx1ZSBzZXQgdG8gdGhlIGV4dGVuc2lvbiBwYXJhbWV0ZXIg ImV4YW1wbGUiIFNIT1VMRCBiZQogICBuYW1lZCAiZXhhbXBsZV9pbnZhbGlkIi4KCgogICAgIGVy cm9yICAgICAgPSAxKmVycm9yLWNoYXIKICAgICBlcnJvci1jaGFyID0gJXgyMC0yMSAvICV4MjMt NUIgLyAleDVELTdFCgoKCjkuICBOYXRpdmUgQXBwbGljYXRpb25zCgogICBOYXRpdmUgYXBwbGlj YXRpb25zIGFyZSBjbGllbnRzIGluc3RhbGxlZCBhbmQgZXhlY3V0ZWQgb24gdGhlIGRldmljZQog ICB1c2VkIGJ5IHRoZSByZXNvdXJjZSBvd25lciAoaS5lLiBkZXNrdG9wIGFwcGxpY2F0aW9uLCBu YXRpdmUgbW9iaWxlCiAgIGFwcGxpY2F0aW9uKS4gIE5hdGl2ZSBhcHBsaWNhdGlvbnMgcmVxdWly ZSBzcGVjaWFsIGNvbnNpZGVyYXRpb24KICAgcmVsYXRlZCB0byBzZWN1cml0eSwgcGxhdGZvcm0g Y2FwYWJpbGl0aWVzLCBhbmQgb3ZlcmFsbCBlbmQtdXNlcgogICBleHBlcmllbmNlLgoKICAgVGhl IGF1dGhvcml6YXRpb24gZW5kcG9pbnQgcmVxdWlyZXMgaW50ZXJhY3Rpb24gYmV0d2VlbiB0aGUg Y2xpZW50CiAgIGFuZCB0aGUgcmVzb3VyY2Ugb3duZXIncyB1c2VyLWFnZW50LiAgTmF0aXZlIGFw cGxpY2F0aW9ucyBjYW4gaW52b2tlCgoKCkhhbW1lciwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMg RGVjZW1iZXIgMTAsIDIwMTIgICAgICAgICAgICAgIFtQYWdlIDQ4XQoMCkludGVybmV0LURyYWZ0 ICAgICAgICAgICAgICAgICAgT0F1dGggMi4wICAgICAgICAgICAgICAgICAgICAgIEp1bmUgMjAx MgoKCiAgIGFuIGV4dGVybmFsIHVzZXItYWdlbnQgb3IgZW1iZWQgYSB1c2VyLWFnZW50IHdpdGhp biB0aGUgYXBwbGljYXRpb24uCiAgIEZvciBleGFtcGxlOgoKICAgbyAgRXh0ZXJuYWwgdXNlci1h Z2VudCAtIHRoZSBuYXRpdmUgYXBwbGljYXRpb24gY2FuIGNhcHR1cmUgdGhlCiAgICAgIHJlc3Bv bnNlIGZyb20gdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHVzaW5nIGEgcmVkaXJlY3Rpb24gVVJJ CiAgICAgIHdpdGggYSBzY2hlbWUgcmVnaXN0ZXJlZCB3aXRoIHRoZSBvcGVyYXRpbmcgc3lzdGVt IHRvIGludm9rZSB0aGUKICAgICAgY2xpZW50IGFzIHRoZSBoYW5kbGVyLCBtYW51YWwgY29weS1h bmQtcGFzdGUgb2YgdGhlIGNyZWRlbnRpYWxzLAogICAgICBydW5uaW5nIGEgbG9jYWwgd2ViIHNl cnZlciwgaW5zdGFsbGluZyBhIHVzZXItYWdlbnQgZXh0ZW5zaW9uLCBvcgogICAgICBieSBwcm92 aWRpbmcgYSByZWRpcmVjdGlvbiBVUkkgaWRlbnRpZnlpbmcgYSBzZXJ2ZXItaG9zdGVkCiAgICAg IHJlc291cmNlIHVuZGVyIHRoZSBjbGllbnQncyBjb250cm9sLCB3aGljaCBpbiB0dXJuIG1ha2Vz IHRoZQogICAgICByZXNwb25zZSBhdmFpbGFibGUgdG8gdGhlIG5hdGl2ZSBhcHBsaWNhdGlvbi4K ICAgbyAgRW1iZWRkZWQgdXNlci1hZ2VudCAtIHRoZSBuYXRpdmUgYXBwbGljYXRpb24gb2J0YWlu cyB0aGUgcmVzcG9uc2UKICAgICAgYnkgZGlyZWN0bHkgY29tbXVuaWNhdGluZyB3aXRoIHRoZSBl bWJlZGRlZCB1c2VyLWFnZW50IGJ5CiAgICAgIG1vbml0b3Jpbmcgc3RhdGUgY2hhbmdlcyBlbWl0 dGVkIGR1cmluZyB0aGUgcmVzb3VyY2UgbG9hZCwgb3IKICAgICAgYWNjZXNzaW5nIHRoZSB1c2Vy LWFnZW50J3MgY29va2llcyBzdG9yYWdlLgoKICAgV2hlbiBjaG9vc2luZyBiZXR3ZWVuIGFuIGV4 dGVybmFsIG9yIGVtYmVkZGVkIHVzZXItYWdlbnQsIGRldmVsb3BlcnMKICAgc2hvdWxkIGNvbnNp ZGVyOgoKICAgbyAgQW4gRXh0ZXJuYWwgdXNlci1hZ2VudCBtYXkgaW1wcm92ZSBjb21wbGV0aW9u IHJhdGUgYXMgdGhlIHJlc291cmNlCiAgICAgIG93bmVyIG1heSBhbHJlYWR5IGhhdmUgYW4gYWN0 aXZlIHNlc3Npb24gd2l0aCB0aGUgYXV0aG9yaXphdGlvbgogICAgICBzZXJ2ZXIgcmVtb3Zpbmcg dGhlIG5lZWQgdG8gcmUtYXV0aGVudGljYXRlLiAgSXQgcHJvdmlkZXMgYQogICAgICBmYW1pbGlh ciBlbmQtdXNlciBleHBlcmllbmNlIGFuZCBmdW5jdGlvbmFsaXR5LiAgVGhlIHJlc291cmNlCiAg ICAgIG93bmVyIG1heSBhbHNvIHJlbHkgb24gdXNlci1hZ2VudCBmZWF0dXJlcyBvciBleHRlbnNp b25zIHRvIGFzc2lzdAogICAgICB3aXRoIGF1dGhlbnRpY2F0aW9uIChlLmcuIHBhc3N3b3JkIG1h bmFnZXIsIDItZmFjdG9yIGRldmljZQogICAgICByZWFkZXIpLgogICBvICBBbiBlbWJlZGRlZCB1 c2VyLWFnZW50IG1heSBvZmZlciBpbXByb3ZlZCB1c2FiaWxpdHksIGFzIGl0IHJlbW92ZXMKICAg ICAgdGhlIG5lZWQgdG8gc3dpdGNoIGNvbnRleHQgYW5kIG9wZW4gbmV3IHdpbmRvd3MuCiAgIG8g IEFuIGVtYmVkZGVkIHVzZXItYWdlbnQgcG9zZXMgYSBzZWN1cml0eSBjaGFsbGVuZ2UgYmVjYXVz ZSByZXNvdXJjZQogICAgICBvd25lcnMgYXJlIGF1dGhlbnRpY2F0aW5nIGluIGFuIHVuaWRlbnRp ZmllZCB3aW5kb3cgd2l0aG91dCBhY2Nlc3MKICAgICAgdG8gdGhlIHZpc3VhbCBwcm90ZWN0aW9u cyBmb3VuZCBpbiBtb3N0IGV4dGVybmFsIHVzZXItYWdlbnRzLiAgQW4KICAgICAgZW1iZWRkZWQg dXNlci1hZ2VudCBlZHVjYXRlcyBlbmQtdXNlcnMgdG8gdHJ1c3QgdW5pZGVudGlmaWVkCiAgICAg IHJlcXVlc3RzIGZvciBhdXRoZW50aWNhdGlvbiAobWFraW5nIHBoaXNoaW5nIGF0dGFja3MgZWFz aWVyIHRvCiAgICAgIGV4ZWN1dGUpLgoKICAgV2hlbiBjaG9vc2luZyBiZXR3ZWVuIHRoZSBpbXBs aWNpdCBncmFudCB0eXBlIGFuZCB0aGUgYXV0aG9yaXphdGlvbgogICBjb2RlIGdyYW50IHR5cGUs IHRoZSBmb2xsb3dpbmcgc2hvdWxkIGJlIGNvbnNpZGVyZWQ6CgogICBvICBOYXRpdmUgYXBwbGlj YXRpb25zIHRoYXQgdXNlIHRoZSBhdXRob3JpemF0aW9uIGNvZGUgZ3JhbnQgdHlwZQogICAgICBT SE9VTEQgZG8gc28gd2l0aG91dCB1c2luZyBjbGllbnQgY3JlZGVudGlhbHMsIGR1ZSB0byB0aGUg bmF0aXZlCiAgICAgIGFwcGxpY2F0aW9uJ3MgaW5hYmlsaXR5IHRvIGtlZXAgY2xpZW50IGNyZWRl bnRpYWxzIGNvbmZpZGVudGlhbC4KICAgbyAgV2hlbiB1c2luZyB0aGUgaW1wbGljaXQgZ3JhbnQg dHlwZSBmbG93IGEgcmVmcmVzaCB0b2tlbiBpcyBub3QKICAgICAgcmV0dXJuZWQgd2hpY2ggcmVx dWlyZXMgcmVwZWF0aW5nIHRoZSBhdXRob3JpemF0aW9uIHByb2Nlc3Mgb25jZQogICAgICB0aGUg YWNjZXNzIHRva2VuIGV4cGlyZXMuCgoKCgoKCgpIYW1tZXIsIGV0IGFsLiAgICAgICAgICBFeHBp cmVzIERlY2VtYmVyIDEwLCAyMDEyICAgICAgICAgICAgICBbUGFnZSA0OV0KDApJbnRlcm5ldC1E cmFmdCAgICAgICAgICAgICAgICAgIE9BdXRoIDIuMCAgICAgICAgICAgICAgICAgICAgICBKdW5l IDIwMTIKCgoxMC4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zCgogICBBcyBhIGZsZXhpYmxlIGFu ZCBleHRlbnNpYmxlIGZyYW1ld29yaywgT0F1dGgncyBzZWN1cml0eQogICBjb25zaWRlcmF0aW9u cyBkZXBlbmQgb24gbWFueSBmYWN0b3JzLiAgVGhlIGZvbGxvd2luZyBzZWN0aW9ucwogICBwcm92 aWRlIGltcGxlbWVudGVycyB3aXRoIHNlY3VyaXR5IGd1aWRlbGluZXMgZm9jdXNlZCBvbiB0aGUg dGhyZWUKICAgY2xpZW50IHByb2ZpbGVzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDIuMTogd2ViIGFw cGxpY2F0aW9uLCB1c2VyLQogICBhZ2VudC1iYXNlZCBhcHBsaWNhdGlvbiwgYW5kIG5hdGl2ZSBh cHBsaWNhdGlvbi4KCiAgIEEgY29tcHJlaGVuc2l2ZSBPQXV0aCBzZWN1cml0eSBtb2RlbCBhbmQg YW5hbHlzaXMsIGFzIHdlbGwgYXMKICAgYmFja2dyb3VuZCBmb3IgdGhlIHByb3RvY29sIGRlc2ln biBpcyBwcm92aWRlZCBieQogICBbSS1ELmlldGYtb2F1dGgtdjItdGhyZWF0bW9kZWxdLgoKMTAu MS4gIENsaWVudCBBdXRoZW50aWNhdGlvbgoKICAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGVz dGFibGlzaGVzIGNsaWVudCBjcmVkZW50aWFscyB3aXRoIHdlYgogICBhcHBsaWNhdGlvbiBjbGll bnRzIGZvciB0aGUgcHVycG9zZSBvZiBjbGllbnQgYXV0aGVudGljYXRpb24uICBUaGUKICAgYXV0 aG9yaXphdGlvbiBzZXJ2ZXIgaXMgZW5jb3VyYWdlZCB0byBjb25zaWRlciBzdHJvbmdlciBjbGll bnQKICAgYXV0aGVudGljYXRpb24gbWVhbnMgdGhhbiBhIGNsaWVudCBwYXNzd29yZC4gIFdlYiBh cHBsaWNhdGlvbiBjbGllbnRzCiAgIE1VU1QgZW5zdXJlIGNvbmZpZGVudGlhbGl0eSBvZiBjbGll bnQgcGFzc3dvcmRzIGFuZCBvdGhlciBjbGllbnQKICAgY3JlZGVudGlhbHMuCgogICBUaGUgYXV0 aG9yaXphdGlvbiBzZXJ2ZXIgTVVTVCBOT1QgaXNzdWUgY2xpZW50IHBhc3N3b3JkcyBvciBvdGhl cgogICBjbGllbnQgY3JlZGVudGlhbHMgdG8gbmF0aXZlIGFwcGxpY2F0aW9uIG9yIHVzZXItYWdl bnQtYmFzZWQKICAgYXBwbGljYXRpb24gY2xpZW50cyBmb3IgdGhlIHB1cnBvc2Ugb2YgY2xpZW50 IGF1dGhlbnRpY2F0aW9uLiAgVGhlCiAgIGF1dGhvcml6YXRpb24gc2VydmVyIE1BWSBpc3N1ZSBh IGNsaWVudCBwYXNzd29yZCBvciBvdGhlciBjcmVkZW50aWFscwogICBmb3IgYSBzcGVjaWZpYyBp bnN0YWxsYXRpb24gb2YgYSBuYXRpdmUgYXBwbGljYXRpb24gY2xpZW50IG9uIGEKICAgc3BlY2lm aWMgZGV2aWNlLgoKICAgV2hlbiBjbGllbnQgYXV0aGVudGljYXRpb24gaXMgbm90IHBvc3NpYmxl LCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIKICAgU0hPVUxEIGVtcGxveSBvdGhlciBtZWFucyB0 byB2YWxpZGF0ZSB0aGUgY2xpZW50J3MgaWRlbnRpdHkuICBGb3IKICAgZXhhbXBsZSwgYnkgcmVx dWlyaW5nIHRoZSByZWdpc3RyYXRpb24gb2YgdGhlIGNsaWVudCByZWRpcmVjdGlvbiBVUkkKICAg b3IgZW5saXN0aW5nIHRoZSByZXNvdXJjZSBvd25lciB0byBjb25maXJtIGlkZW50aXR5LiAgQSB2 YWxpZAogICByZWRpcmVjdGlvbiBVUkkgaXMgbm90IHN1ZmZpY2llbnQgdG8gdmVyaWZ5IHRoZSBj bGllbnQncyBpZGVudGl0eQogICB3aGVuIGFza2luZyBmb3IgcmVzb3VyY2Ugb3duZXIgYXV0aG9y aXphdGlvbiwgYnV0IGNhbiBiZSB1c2VkIHRvCiAgIHByZXZlbnQgZGVsaXZlcmluZyBjcmVkZW50 aWFscyB0byBhIGNvdW50ZXJmZWl0IGNsaWVudCBhZnRlcgogICBvYnRhaW5pbmcgcmVzb3VyY2Ug b3duZXIgYXV0aG9yaXphdGlvbi4KCiAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBtdXN0IGNv bnNpZGVyIHRoZSBzZWN1cml0eSBpbXBsaWNhdGlvbnMgb2YKICAgaW50ZXJhY3Rpbmcgd2l0aCB1 bmF1dGhlbnRpY2F0ZWQgY2xpZW50cyBhbmQgdGFrZSBtZWFzdXJlcyB0byBsaW1pdAogICB0aGUg cG90ZW50aWFsIGV4cG9zdXJlIG9mIG90aGVyIGNyZWRlbnRpYWxzIChlLmcuIHJlZnJlc2ggdG9r ZW5zKQogICBpc3N1ZWQgdG8gc3VjaCBjbGllbnRzLgoKMTAuMi4gIENsaWVudCBJbXBlcnNvbmF0 aW9uCgogICBBIG1hbGljaW91cyBjbGllbnQgY2FuIGltcGVyc29uYXRlIGFub3RoZXIgY2xpZW50 IGFuZCBvYnRhaW4gYWNjZXNzCiAgIHRvIHByb3RlY3RlZCByZXNvdXJjZXMsIGlmIHRoZSBpbXBl cnNvbmF0ZWQgY2xpZW50IGZhaWxzIHRvLCBvciBpcwogICB1bmFibGUgdG8sIGtlZXAgaXRzIGNs aWVudCBjcmVkZW50aWFscyBjb25maWRlbnRpYWwuCgoKCgpIYW1tZXIsIGV0IGFsLiAgICAgICAg ICBFeHBpcmVzIERlY2VtYmVyIDEwLCAyMDEyICAgICAgICAgICAgICBbUGFnZSA1MF0KDApJbnRl cm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgIE9BdXRoIDIuMCAgICAgICAgICAgICAgICAgICAg ICBKdW5lIDIwMTIKCgogICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVTVCBhdXRoZW50aWNh dGUgdGhlIGNsaWVudCB3aGVuZXZlcgogICBwb3NzaWJsZS4gIElmIHRoZSBhdXRob3JpemF0aW9u IHNlcnZlciBjYW5ub3QgYXV0aGVudGljYXRlIHRoZSBjbGllbnQKICAgZHVlIHRvIHRoZSBjbGll bnQncyBuYXR1cmUsIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBNVVNUIHJlcXVpcmUgdGhlCiAg IHJlZ2lzdHJhdGlvbiBvZiBhbnkgcmVkaXJlY3Rpb24gVVJJIHVzZWQgZm9yIHJlY2VpdmluZyBh dXRob3JpemF0aW9uCiAgIHJlc3BvbnNlcywgYW5kIFNIT1VMRCB1dGlsaXplIG90aGVyIG1lYW5z IHRvIHByb3RlY3QgcmVzb3VyY2Ugb3duZXJzCiAgIGZyb20gc3VjaCBwb3RlbnRpYWxseSBtYWxp Y2lvdXMgY2xpZW50cy4gIEZvciBleGFtcGxlLCB0aGUKICAgYXV0aG9yaXphdGlvbiBzZXJ2ZXIg Y2FuIGVuZ2FnZSB0aGUgcmVzb3VyY2Ugb3duZXIgdG8gYXNzaXN0IGluCiAgIGlkZW50aWZ5aW5n IHRoZSBjbGllbnQgYW5kIGl0cyBvcmlnaW4uCgogICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIg U0hPVUxEIGVuZm9yY2UgZXhwbGljaXQgcmVzb3VyY2Ugb3duZXIKICAgYXV0aGVudGljYXRpb24g YW5kIHByb3ZpZGUgdGhlIHJlc291cmNlIG93bmVyIHdpdGggaW5mb3JtYXRpb24gYWJvdXQKICAg dGhlIGNsaWVudCBhbmQgdGhlIHJlcXVlc3RlZCBhdXRob3JpemF0aW9uIHNjb3BlIGFuZCBsaWZl dGltZS4gIEl0IGlzCiAgIHVwIHRvIHRoZSByZXNvdXJjZSBvd25lciB0byByZXZpZXcgdGhlIGlu Zm9ybWF0aW9uIGluIHRoZSBjb250ZXh0IG9mCiAgIHRoZSBjdXJyZW50IGNsaWVudCwgYW5kIGF1 dGhvcml6ZSBvciBkZW55IHRoZSByZXF1ZXN0LgoKICAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVy IFNIT1VMRCBOT1QgcHJvY2VzcyByZXBlYXRlZCBhdXRob3JpemF0aW9uCiAgIHJlcXVlc3RzIGF1 dG9tYXRpY2FsbHkgKHdpdGhvdXQgYWN0aXZlIHJlc291cmNlIG93bmVyIGludGVyYWN0aW9uKQog ICB3aXRob3V0IGF1dGhlbnRpY2F0aW5nIHRoZSBjbGllbnQgb3IgcmVseWluZyBvbiBvdGhlciBt ZWFzdXJlcyB0bwogICBlbnN1cmUgdGhlIHJlcGVhdGVkIHJlcXVlc3QgY29tZXMgZnJvbSB0aGUg b3JpZ2luYWwgY2xpZW50IGFuZCBub3QgYW4KICAgaW1wZXJzb25hdG9yLgoKMTAuMy4gIEFjY2Vz cyBUb2tlbnMKCiAgIEFjY2VzcyB0b2tlbiBjcmVkZW50aWFscyAoYXMgd2VsbCBhcyBhbnkgY29u ZmlkZW50aWFsIGFjY2VzcyB0b2tlbgogICBhdHRyaWJ1dGVzKSBNVVNUIGJlIGtlcHQgY29uZmlk ZW50aWFsIGluIHRyYW5zaXQgYW5kIHN0b3JhZ2UsIGFuZAogICBvbmx5IHNoYXJlZCBhbW9uZyB0 aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIsIHRoZSByZXNvdXJjZSBzZXJ2ZXJzIHRoZQogICBhY2Nl c3MgdG9rZW4gaXMgdmFsaWQgZm9yLCBhbmQgdGhlIGNsaWVudCB0byB3aG9tIHRoZSBhY2Nlc3Mg dG9rZW4gaXMKICAgaXNzdWVkLiAgQWNjZXNzIHRva2VuIGNyZWRlbnRpYWxzIE1VU1Qgb25seSBi ZSB0cmFuc21pdHRlZCB1c2luZyBUTFMKICAgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gMS42IHdp dGggc2VydmVyIGF1dGhlbnRpY2F0aW9uIGFzIGRlZmluZWQgYnkKICAgW1JGQzI4MThdLgoKICAg V2hlbiB1c2luZyB0aGUgaW1wbGljaXQgZ3JhbnQgdHlwZSwgdGhlIGFjY2VzcyB0b2tlbiBpcyB0 cmFuc21pdHRlZAogICBpbiB0aGUgVVJJIGZyYWdtZW50LCB3aGljaCBjYW4gZXhwb3NlIGl0IHRv IHVuYXV0aG9yaXplZCBwYXJ0aWVzLgoKICAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIE1VU1Qg ZW5zdXJlIHRoYXQgYWNjZXNzIHRva2VucyBjYW5ub3QgYmUKICAgZ2VuZXJhdGVkLCBtb2RpZmll ZCwgb3IgZ3Vlc3NlZCB0byBwcm9kdWNlIHZhbGlkIGFjY2VzcyB0b2tlbnMgYnkKICAgdW5hdXRo b3JpemVkIHBhcnRpZXMuCgogICBUaGUgY2xpZW50IFNIT1VMRCByZXF1ZXN0IGFjY2VzcyB0b2tl bnMgd2l0aCB0aGUgbWluaW1hbCBzY29wZQogICBuZWNlc3NhcnkuICBUaGUgYXV0aG9yaXphdGlv biBzZXJ2ZXIgU0hPVUxEIHRha2UgdGhlIGNsaWVudCBpZGVudGl0eQogICBpbnRvIGFjY291bnQg d2hlbiBjaG9vc2luZyBob3cgdG8gaG9ub3IgdGhlIHJlcXVlc3RlZCBzY29wZSwgYW5kIE1BWQog ICBpc3N1ZSBhbiBhY2Nlc3MgdG9rZW4gd2l0aCBhIGxlc3MgcmlnaHRzIHRoYW4gcmVxdWVzdGVk LgoKICAgVGhpcyBzcGVjaWZpY2F0aW9uIGRvZXMgbm90IHByb3ZpZGUgYW55IG1ldGhvZHMgZm9y IHRoZSByZXNvdXJjZQogICBzZXJ2ZXIgdG8gZW5zdXJlIHRoYXQgYW4gYWNjZXNzIHRva2VuIHBy ZXNlbnRlZCB0byBpdCBieSBhIGdpdmVuCiAgIGNsaWVudCB3YXMgaXNzdWVkIHRvIHRoYXQgY2xp ZW50IGJ5IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlci4KCgoKCgpIYW1tZXIsIGV0IGFsLiAgICAg ICAgICBFeHBpcmVzIERlY2VtYmVyIDEwLCAyMDEyICAgICAgICAgICAgICBbUGFnZSA1MV0KDApJ bnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgIE9BdXRoIDIuMCAgICAgICAgICAgICAgICAg ICAgICBKdW5lIDIwMTIKCgoxMC40LiAgUmVmcmVzaCBUb2tlbnMKCiAgIEF1dGhvcml6YXRpb24g c2VydmVycyBNQVkgaXNzdWUgcmVmcmVzaCB0b2tlbnMgdG8gd2ViIGFwcGxpY2F0aW9uCiAgIGNs aWVudHMgYW5kIG5hdGl2ZSBhcHBsaWNhdGlvbiBjbGllbnRzLgoKICAgUmVmcmVzaCB0b2tlbnMg TVVTVCBiZSBrZXB0IGNvbmZpZGVudGlhbCBpbiB0cmFuc2l0IGFuZCBzdG9yYWdlLCBhbmQKICAg c2hhcmVkIG9ubHkgYW1vbmcgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGFuZCB0aGUgY2xpZW50 IHRvIHdob20gdGhlCiAgIHJlZnJlc2ggdG9rZW5zIHdlcmUgaXNzdWVkLiAgVGhlIGF1dGhvcml6 YXRpb24gc2VydmVyIE1VU1QgbWFpbnRhaW4KICAgdGhlIGJpbmRpbmcgYmV0d2VlbiBhIHJlZnJl c2ggdG9rZW4gYW5kIHRoZSBjbGllbnQgdG8gd2hvbSBpdCB3YXMKICAgaXNzdWVkLiAgUmVmcmVz aCB0b2tlbnMgTVVTVCBvbmx5IGJlIHRyYW5zbWl0dGVkIHVzaW5nIFRMUyBhcwogICBkZXNjcmli ZWQgaW4gU2VjdGlvbiAxLjYgd2l0aCBzZXJ2ZXIgYXV0aGVudGljYXRpb24gYXMgZGVmaW5lZCBi eQogICBbUkZDMjgxOF0uCgogICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVTVCB2ZXJpZnkg dGhlIGJpbmRpbmcgYmV0d2VlbiB0aGUgcmVmcmVzaAogICB0b2tlbiBhbmQgY2xpZW50IGlkZW50 aXR5IHdoZW5ldmVyIHRoZSBjbGllbnQgaWRlbnRpdHkgY2FuIGJlCiAgIGF1dGhlbnRpY2F0ZWQu ICBXaGVuIGNsaWVudCBhdXRoZW50aWNhdGlvbiBpcyBub3QgcG9zc2libGUsIHRoZQogICBhdXRo b3JpemF0aW9uIHNlcnZlciBTSE9VTEQgZGVwbG95IG90aGVyIG1lYW5zIHRvIGRldGVjdCByZWZy ZXNoCiAgIHRva2VuIGFidXNlLgoKICAgRm9yIGV4YW1wbGUsIHRoZSBhdXRob3JpemF0aW9uIHNl cnZlciBjb3VsZCBlbXBsb3kgcmVmcmVzaCB0b2tlbgogICByb3RhdGlvbiBpbiB3aGljaCBhIG5l dyByZWZyZXNoIHRva2VuIGlzIGlzc3VlZCB3aXRoIGV2ZXJ5IGFjY2VzcwogICB0b2tlbiByZWZy ZXNoIHJlc3BvbnNlLiAgVGhlIHByZXZpb3VzIHJlZnJlc2ggdG9rZW4gaXMgaW52YWxpZGF0ZWQK ICAgYnV0IHJldGFpbmVkIGJ5IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlci4gIElmIGEgcmVmcmVz aCB0b2tlbiBpcwogICBjb21wcm9taXNlZCBhbmQgc3Vic2VxdWVudGx5IHVzZWQgYnkgYm90aCB0 aGUgYXR0YWNrZXIgYW5kIHRoZQogICBsZWdpdGltYXRlIGNsaWVudCwgb25lIG9mIHRoZW0gd2ls bCBwcmVzZW50IGFuIGludmFsaWRhdGVkIHJlZnJlc2gKICAgdG9rZW4gd2hpY2ggd2lsbCBpbmZv cm0gdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIG9mIHRoZSBicmVhY2guCgogICBUaGUgYXV0aG9y aXphdGlvbiBzZXJ2ZXIgTVVTVCBlbnN1cmUgdGhhdCByZWZyZXNoIHRva2VucyBjYW5ub3QgYmUK ICAgZ2VuZXJhdGVkLCBtb2RpZmllZCwgb3IgZ3Vlc3NlZCB0byBwcm9kdWNlIHZhbGlkIHJlZnJl c2ggdG9rZW5zIGJ5CiAgIHVuYXV0aG9yaXplZCBwYXJ0aWVzLgoKMTAuNS4gIEF1dGhvcml6YXRp b24gQ29kZXMKCiAgIFRoZSB0cmFuc21pc3Npb24gb2YgYXV0aG9yaXphdGlvbiBjb2RlcyBTSE9V TEQgYmUgbWFkZSBvdmVyIGEgc2VjdXJlCiAgIGNoYW5uZWwsIGFuZCB0aGUgY2xpZW50IFNIT1VM RCByZXF1aXJlIHRoZSB1c2Ugb2YgVExTIHdpdGggaXRzCiAgIHJlZGlyZWN0aW9uIFVSSSBpZiB0 aGUgVVJJIGlkZW50aWZpZXMgYSBuZXR3b3JrIHJlc291cmNlLiAgU2luY2UKICAgYXV0aG9yaXph dGlvbiBjb2RlcyBhcmUgdHJhbnNtaXR0ZWQgdmlhIHVzZXItYWdlbnQgcmVkaXJlY3Rpb25zLCB0 aGV5CiAgIGNvdWxkIHBvdGVudGlhbGx5IGJlIGRpc2Nsb3NlZCB0aHJvdWdoIHVzZXItYWdlbnQg aGlzdG9yeSBhbmQgSFRUUAogICByZWZlcnJlciBoZWFkZXJzLgoKICAgQXV0aG9yaXphdGlvbiBj b2RlcyBvcGVyYXRlIGFzIHBsYWludGV4dCBiZWFyZXIgY3JlZGVudGlhbHMsIHVzZWQgdG8KICAg dmVyaWZ5IHRoYXQgdGhlIHJlc291cmNlIG93bmVyIHdobyBncmFudGVkIGF1dGhvcml6YXRpb24g YXQgdGhlCiAgIGF1dGhvcml6YXRpb24gc2VydmVyIGlzIHRoZSBzYW1lIHJlc291cmNlIG93bmVy IHJldHVybmluZyB0byB0aGUKICAgY2xpZW50IHRvIGNvbXBsZXRlIHRoZSBwcm9jZXNzLiAgVGhl cmVmb3JlLCBpZiB0aGUgY2xpZW50IHJlbGllcyBvbgogICB0aGUgYXV0aG9yaXphdGlvbiBjb2Rl IGZvciBpdHMgb3duIHJlc291cmNlIG93bmVyIGF1dGhlbnRpY2F0aW9uLCB0aGUKICAgY2xpZW50 IHJlZGlyZWN0aW9uIGVuZHBvaW50IE1VU1QgcmVxdWlyZSB0aGUgdXNlIG9mIFRMUy4KCiAgIEF1 dGhvcml6YXRpb24gY29kZXMgTVVTVCBiZSBzaG9ydCBsaXZlZCBhbmQgc2luZ2xlIHVzZS4gIElm IHRoZQoKCgpIYW1tZXIsIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIERlY2VtYmVyIDEwLCAyMDEy ICAgICAgICAgICAgICBbUGFnZSA1Ml0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAg IE9BdXRoIDIuMCAgICAgICAgICAgICAgICAgICAgICBKdW5lIDIwMTIKCgogICBhdXRob3JpemF0 aW9uIHNlcnZlciBvYnNlcnZlcyBtdWx0aXBsZSBhdHRlbXB0cyB0byBleGNoYW5nZSBhbgogICBh dXRob3JpemF0aW9uIGNvZGUgZm9yIGFuIGFjY2VzcyB0b2tlbiwgdGhlIGF1dGhvcml6YXRpb24g c2VydmVyCiAgIFNIT1VMRCBhdHRlbXB0IHRvIHJldm9rZSBhbGwgYWNjZXNzIHRva2VucyBhbHJl YWR5IGdyYW50ZWQgYmFzZWQgb24KICAgdGhlIGNvbXByb21pc2VkIGF1dGhvcml6YXRpb24gY29k ZS4KCiAgIElmIHRoZSBjbGllbnQgY2FuIGJlIGF1dGhlbnRpY2F0ZWQsIHRoZSBhdXRob3JpemF0 aW9uIHNlcnZlcnMgTVVTVAogICBhdXRoZW50aWNhdGUgdGhlIGNsaWVudCBhbmQgZW5zdXJlIHRo YXQgdGhlIGF1dGhvcml6YXRpb24gY29kZSB3YXMKICAgaXNzdWVkIHRvIHRoZSBzYW1lIGNsaWVu dC4KCjEwLjYuICBBdXRob3JpemF0aW9uIENvZGUgUmVkaXJlY3Rpb24gVVJJIE1hbmlwdWxhdGlv bgoKICAgV2hlbiByZXF1ZXN0aW5nIGF1dGhvcml6YXRpb24gdXNpbmcgdGhlIGF1dGhvcml6YXRp b24gY29kZSBncmFudAogICB0eXBlLCB0aGUgY2xpZW50IGNhbiBzcGVjaWZ5IGEgcmVkaXJlY3Rp b24gVVJJIHZpYSB0aGUgInJlZGlyZWN0X3VyaSIKICAgcGFyYW1ldGVyLiAgSWYgYW4gYXR0YWNr ZXIgY2FuIG1hbmlwdWxhdGUgdGhlIHZhbHVlIG9mIHRoZQogICByZWRpcmVjdGlvbiBVUkksIGl0 IGNhbiBjYXVzZSB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgdG8gcmVkaXJlY3QKICAgdGhlIHJl c291cmNlIG93bmVyIHVzZXItYWdlbnQgdG8gYSBVUkkgdW5kZXIgdGhlIGNvbnRyb2wgb2YgdGhl CiAgIGF0dGFja2VyIHdpdGggdGhlIGF1dGhvcml6YXRpb24gY29kZS4KCiAgIEFuIGF0dGFja2Vy IGNhbiBjcmVhdGUgYW4gYWNjb3VudCBhdCBhIGxlZ2l0aW1hdGUgY2xpZW50IGFuZCBpbml0aWF0 ZQogICB0aGUgYXV0aG9yaXphdGlvbiBmbG93LiAgV2hlbiB0aGUgYXR0YWNrZXIncyB1c2VyLWFn ZW50IGlzIHNlbnQgdG8KICAgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHRvIGdyYW50IGFjY2Vz cywgdGhlIGF0dGFja2VyIGdyYWJzIHRoZQogICBhdXRob3JpemF0aW9uIFVSSSBwcm92aWRlZCBi eSB0aGUgbGVnaXRpbWF0ZSBjbGllbnQsIGFuZCByZXBsYWNlcyB0aGUKICAgY2xpZW50J3MgcmVk aXJlY3Rpb24gVVJJIHdpdGggYSBVUkkgdW5kZXIgdGhlIGNvbnRyb2wgb2YgdGhlCiAgIGF0dGFj a2VyLiAgVGhlIGF0dGFja2VyIHRoZW4gdHJpY2tzIHRoZSB2aWN0aW0gaW50byBmb2xsb3dpbmcg dGhlCiAgIG1hbmlwdWxhdGVkIGxpbmsgdG8gYXV0aG9yaXplIGFjY2VzcyB0byB0aGUgbGVnaXRp bWF0ZSBjbGllbnQuCgogICBPbmNlIGF0IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciwgdGhlIHZp Y3RpbSBpcyBwcm9tcHRlZCB3aXRoIGEKICAgbm9ybWFsLCB2YWxpZCByZXF1ZXN0IG9uIGJlaGFs ZiBvZiBhIGxlZ2l0aW1hdGUgYW5kIHRydXN0ZWQgY2xpZW50LAogICBhbmQgYXV0aG9yaXplcyB0 aGUgcmVxdWVzdC4gIFRoZSB2aWN0aW0gaXMgdGhlbiByZWRpcmVjdGVkIHRvIGFuCiAgIGVuZHBv aW50IHVuZGVyIHRoZSBjb250cm9sIG9mIHRoZSBhdHRhY2tlciB3aXRoIHRoZSBhdXRob3JpemF0 aW9uCiAgIGNvZGUuICBUaGUgYXR0YWNrZXIgY29tcGxldGVzIHRoZSBhdXRob3JpemF0aW9uIGZs b3cgYnkgc2VuZGluZyB0aGUKICAgYXV0aG9yaXphdGlvbiBjb2RlIHRvIHRoZSBjbGllbnQgdXNp bmcgdGhlIG9yaWdpbmFsIHJlZGlyZWN0aW9uIFVSSQogICBwcm92aWRlZCBieSB0aGUgY2xpZW50 LiAgVGhlIGNsaWVudCBleGNoYW5nZXMgdGhlIGF1dGhvcml6YXRpb24gY29kZQogICB3aXRoIGFu IGFjY2VzcyB0b2tlbiBhbmQgbGlua3MgaXQgdG8gdGhlIGF0dGFja2VyJ3MgY2xpZW50IGFjY291 bnQKICAgd2hpY2ggY2FuIG5vdyBnYWluIGFjY2VzcyB0byB0aGUgcHJvdGVjdGVkIHJlc291cmNl cyBhdXRob3JpemVkIGJ5CiAgIHRoZSB2aWN0aW0gKHZpYSB0aGUgY2xpZW50KS4KCiAgIEluIG9y ZGVyIHRvIHByZXZlbnQgc3VjaCBhbiBhdHRhY2ssIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBN VVNUCiAgIGVuc3VyZSB0aGF0IHRoZSByZWRpcmVjdGlvbiBVUkkgdXNlZCB0byBvYnRhaW4gdGhl IGF1dGhvcml6YXRpb24gY29kZQogICBpcyBpZGVudGljYWwgdG8gdGhlIHJlZGlyZWN0aW9uIFVS SSBwcm92aWRlZCB3aGVuIGV4Y2hhbmdpbmcgdGhlCiAgIGF1dGhvcml6YXRpb24gY29kZSBmb3Ig YW4gYWNjZXNzIHRva2VuLiAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVyCiAgIE1VU1QgcmVxdWly ZSBwdWJsaWMgY2xpZW50cyBhbmQgU0hPVUxEIHJlcXVpcmUgY29uZmlkZW50aWFsIGNsaWVudHMK ICAgdG8gcmVnaXN0ZXIgdGhlaXIgcmVkaXJlY3Rpb24gVVJJcy4gIElmIGEgcmVkaXJlY3Rpb24g VVJJIGlzIHByb3ZpZGVkCiAgIGluIHRoZSByZXF1ZXN0LCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2 ZXIgTVVTVCB2YWxpZGF0ZSBpdCBhZ2FpbnN0IHRoZQogICByZWdpc3RlcmVkIHZhbHVlLgoKCgoK CgpIYW1tZXIsIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIERlY2VtYmVyIDEwLCAyMDEyICAgICAg ICAgICAgICBbUGFnZSA1M10KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgIE9BdXRo IDIuMCAgICAgICAgICAgICAgICAgICAgICBKdW5lIDIwMTIKCgoxMC43LiAgUmVzb3VyY2UgT3du ZXIgUGFzc3dvcmQgQ3JlZGVudGlhbHMKCiAgIFRoZSByZXNvdXJjZSBvd25lciBwYXNzd29yZCBj cmVkZW50aWFscyBncmFudCB0eXBlIGlzIG9mdGVuIHVzZWQgZm9yCiAgIGxlZ2FjeSBvciBtaWdy YXRpb24gcmVhc29ucy4gIEl0IHJlZHVjZXMgdGhlIG92ZXJhbGwgcmlzayBvZiBzdG9yaW5nCiAg IHVzZXJuYW1lIGFuZCBwYXNzd29yZCBieSB0aGUgY2xpZW50LCBidXQgZG9lcyBub3QgZWxpbWlu YXRlIHRoZSBuZWVkCiAgIHRvIGV4cG9zZSBoaWdobHkgcHJpdmlsZWdlZCBjcmVkZW50aWFscyB0 byB0aGUgY2xpZW50LgoKICAgVGhpcyBncmFudCB0eXBlIGNhcnJpZXMgYSBoaWdoZXIgcmlzayB0 aGFuIG90aGVyIGdyYW50IHR5cGVzIGJlY2F1c2UKICAgaXQgbWFpbnRhaW5zIHRoZSBwYXNzd29y ZCBhbnRpLXBhdHRlcm4gdGhpcyBwcm90b2NvbCBzZWVrcyB0byBhdm9pZC4KICAgVGhlIGNsaWVu dCBjb3VsZCBhYnVzZSB0aGUgcGFzc3dvcmQgb3IgdGhlIHBhc3N3b3JkIGNvdWxkCiAgIHVuaW50 ZW50aW9uYWxseSBiZSBkaXNjbG9zZWQgdG8gYW4gYXR0YWNrZXIgKGUuZy4gdmlhIGxvZyBmaWxl cyBvcgogICBvdGhlciByZWNvcmRzIGtlcHQgYnkgdGhlIGNsaWVudCkuCgogICBBZGRpdGlvbmFs bHksIGJlY2F1c2UgdGhlIHJlc291cmNlIG93bmVyIGRvZXMgbm90IGhhdmUgY29udHJvbCBvdmVy CiAgIHRoZSBhdXRob3JpemF0aW9uIHByb2Nlc3MgKHRoZSByZXNvdXJjZSBvd25lciBpbnZvbHZl bWVudCBlbmRzIHdoZW4KICAgaXQgaGFuZHMgb3ZlciBpdHMgY3JlZGVudGlhbHMgdG8gdGhlIGNs aWVudCksIHRoZSBjbGllbnQgY2FuIG9idGFpbgogICBhY2Nlc3MgdG9rZW5zIHdpdGggYSBicm9h ZGVyIHNjb3BlIHRoYW4gZGVzaXJlZCBieSB0aGUgcmVzb3VyY2UKICAgb3duZXIuICBUaGUgYXV0 aG9yaXphdGlvbiBzZXJ2ZXIgc2hvdWxkIGNvbnNpZGVyIHRoZSBzY29wZSBhbmQKICAgbGlmZXRp bWUgb2YgYWNjZXNzIHRva2VucyBpc3N1ZWQgdmlhIHRoaXMgZ3JhbnQgdHlwZS4KCiAgIFRoZSBh dXRob3JpemF0aW9uIHNlcnZlciBhbmQgY2xpZW50IFNIT1VMRCBtaW5pbWl6ZSB1c2Ugb2YgdGhp cyBncmFudAogICB0eXBlIGFuZCB1dGlsaXplIG90aGVyIGdyYW50IHR5cGVzIHdoZW5ldmVyIHBv c3NpYmxlLgoKMTAuOC4gIFJlcXVlc3QgQ29uZmlkZW50aWFsaXR5CgogICBBY2Nlc3MgdG9rZW5z LCByZWZyZXNoIHRva2VucywgcmVzb3VyY2Ugb3duZXIgcGFzc3dvcmRzLCBhbmQgY2xpZW50CiAg IGNyZWRlbnRpYWxzIE1VU1QgTk9UIGJlIHRyYW5zbWl0dGVkIGluIHRoZSBjbGVhci4gIEF1dGhv cml6YXRpb24KICAgY29kZXMgU0hPVUxEIE5PVCBiZSB0cmFuc21pdHRlZCBpbiB0aGUgY2xlYXIu CgogICBUaGUgInN0YXRlIiBhbmQgInNjb3BlIiBwYXJhbWV0ZXJzIFNIT1VMRCBOT1QgaW5jbHVk ZSBzZW5zaXRpdmUKICAgY2xpZW50IG9yIHJlc291cmNlIG93bmVyIGluZm9ybWF0aW9uIGluIHBs YWluIHRleHQgYXMgdGhleSBjYW4gYmUKICAgdHJhbnNtaXR0ZWQgb3ZlciBpbnNlY3VyZSBjaGFu bmVscyBvciBzdG9yZWQgaW5zZWN1cmVseS4KCjEwLjkuICBFbmRwb2ludHMgQXV0aGVudGljaXR5 CgogICBJbiBvcmRlciB0byBwcmV2ZW50IG1hbi1pbi10aGUtbWlkZGxlIGF0dGFja3MsIHRoZSBh dXRob3JpemF0aW9uCiAgIHNlcnZlciBNVVNUIHJlcXVpcmUgdGhlIHVzZSBvZiBUTFMgd2l0aCBz ZXJ2ZXIgYXV0aGVudGljYXRpb24gYXMKICAgZGVmaW5lZCBieSBbUkZDMjgxOF0gZm9yIGFueSBy ZXF1ZXN0IHNlbnQgdG8gdGhlIGF1dGhvcml6YXRpb24gYW5kCiAgIHRva2VuIGVuZHBvaW50cy4g IFRoZSBjbGllbnQgTVVTVCB2YWxpZGF0ZSB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIncwogICBU TFMgY2VydGlmaWNhdGUgYXMgZGVmaW5lZCBieSBbUkZDNjEyNV0sIGFuZCBpbiBhY2NvcmRhbmNl IHdpdGggaXRzCiAgIHJlcXVpcmVtZW50cyBmb3Igc2VydmVyIGlkZW50aXR5IGF1dGhlbnRpY2F0 aW9uLgoKMTAuMTAuICBDcmVkZW50aWFscyBHdWVzc2luZyBBdHRhY2tzCgogICBUaGUgYXV0aG9y aXphdGlvbiBzZXJ2ZXIgTVVTVCBwcmV2ZW50IGF0dGFja2VycyBmcm9tIGd1ZXNzaW5nIGFjY2Vz cwogICB0b2tlbnMsIGF1dGhvcml6YXRpb24gY29kZXMsIHJlZnJlc2ggdG9rZW5zLCByZXNvdXJj ZSBvd25lcgogICBwYXNzd29yZHMsIGFuZCBjbGllbnQgY3JlZGVudGlhbHMuCgoKCgpIYW1tZXIs IGV0IGFsLiAgICAgICAgICBFeHBpcmVzIERlY2VtYmVyIDEwLCAyMDEyICAgICAgICAgICAgICBb UGFnZSA1NF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgIE9BdXRoIDIuMCAgICAg ICAgICAgICAgICAgICAgICBKdW5lIDIwMTIKCgogICBUaGUgcHJvYmFiaWxpdHkgb2YgYW4gYXR0 YWNrZXIgZ3Vlc3NpbmcgZ2VuZXJhdGVkIHRva2VucyAoYW5kIG90aGVyCiAgIGNyZWRlbnRpYWxz IG5vdCBpbnRlbmRlZCBmb3IgaGFuZGxpbmcgYnkgZW5kLXVzZXJzKSBNVVNUIGJlIGxlc3MgdGhh bgogICBvciBlcXVhbCB0byAyXigtMTI4KSBhbmQgU0hPVUxEIGJlIGxlc3MgdGhhbiBvciBlcXVh bCB0byAyXigtMTYwKS4KCiAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBNVVNUIHV0aWxpemUg b3RoZXIgbWVhbnMgdG8gcHJvdGVjdAogICBjcmVkZW50aWFscyBpbnRlbmRlZCBmb3IgZW5kLXVz ZXIgdXNhZ2UuCgoxMC4xMS4gIFBoaXNoaW5nIEF0dGFja3MKCiAgIFdpZGUgZGVwbG95bWVudCBv ZiB0aGlzIGFuZCBzaW1pbGFyIHByb3RvY29scyBtYXkgY2F1c2UgZW5kLXVzZXJzIHRvCiAgIGJl Y29tZSBpbnVyZWQgdG8gdGhlIHByYWN0aWNlIG9mIGJlaW5nIHJlZGlyZWN0ZWQgdG8gd2Vic2l0 ZXMgd2hlcmUKICAgdGhleSBhcmUgYXNrZWQgdG8gZW50ZXIgdGhlaXIgcGFzc3dvcmRzLiAgSWYg ZW5kLXVzZXJzIGFyZSBub3QKICAgY2FyZWZ1bCB0byB2ZXJpZnkgdGhlIGF1dGhlbnRpY2l0eSBv ZiB0aGVzZSB3ZWJzaXRlcyBiZWZvcmUgZW50ZXJpbmcKICAgdGhlaXIgY3JlZGVudGlhbHMsIGl0 IHdpbGwgYmUgcG9zc2libGUgZm9yIGF0dGFja2VycyB0byBleHBsb2l0IHRoaXMKICAgcHJhY3Rp Y2UgdG8gc3RlYWwgcmVzb3VyY2Ugb3duZXJzJyBwYXNzd29yZHMuCgogICBTZXJ2aWNlIHByb3Zp ZGVycyBzaG91bGQgYXR0ZW1wdCB0byBlZHVjYXRlIGVuZC11c2VycyBhYm91dCB0aGUgcmlza3MK ICAgcGhpc2hpbmcgYXR0YWNrcyBwb3NlLCBhbmQgc2hvdWxkIHByb3ZpZGUgbWVjaGFuaXNtcyB0 aGF0IG1ha2UgaXQKICAgZWFzeSBmb3IgZW5kLXVzZXJzIHRvIGNvbmZpcm0gdGhlIGF1dGhlbnRp Y2l0eSBvZiB0aGVpciBzaXRlcy4KICAgQ2xpZW50IGRldmVsb3BlcnMgc2hvdWxkIGNvbnNpZGVy IHRoZSBzZWN1cml0eSBpbXBsaWNhdGlvbnMgb2YgaG93CiAgIHRoZXkgaW50ZXJhY3Qgd2l0aCB0 aGUgdXNlci1hZ2VudCAoZS5nLiwgZXh0ZXJuYWwsIGVtYmVkZGVkKSwgYW5kIHRoZQogICBhYmls aXR5IG9mIHRoZSBlbmQtdXNlciB0byB2ZXJpZnkgdGhlIGF1dGhlbnRpY2l0eSBvZiB0aGUKICAg YXV0aG9yaXphdGlvbiBzZXJ2ZXIuCgogICBUbyByZWR1Y2UgdGhlIHJpc2sgb2YgcGhpc2hpbmcg YXR0YWNrcywgdGhlIGF1dGhvcml6YXRpb24gc2VydmVycwogICBNVVNUIHJlcXVpcmUgdGhlIHVz ZSBvZiBUTFMgb24gZXZlcnkgZW5kcG9pbnQgdXNlZCBmb3IgZW5kLXVzZXIKICAgaW50ZXJhY3Rp b24uCgoxMC4xMi4gIENyb3NzLVNpdGUgUmVxdWVzdCBGb3JnZXJ5CgogICBDcm9zcy1zaXRlIHJl cXVlc3QgZm9yZ2VyeSAoQ1NSRikgaXMgYW4gZXhwbG9pdCBpbiB3aGljaCBhbiBhdHRhY2tlcgog ICBjYXVzZXMgdGhlIHVzZXItYWdlbnQgb2YgYSB2aWN0aW0gZW5kLXVzZXIgdG8gZm9sbG93IGEg bWFsaWNpb3VzIFVSSQogICAoZS5nLiBwcm92aWRlZCB0byB0aGUgdXNlci1hZ2VudCBhcyBhIG1p c2xlYWRpbmcgbGluaywgaW1hZ2UsIG9yCiAgIHJlZGlyZWN0aW9uKSB0byBhIHRydXN0aW5nIHNl cnZlciAodXN1YWxseSBlc3RhYmxpc2hlZCB2aWEgdGhlCiAgIHByZXNlbmNlIG9mIGEgdmFsaWQg c2Vzc2lvbiBjb29raWUpLgoKICAgQSBDU1JGIGF0dGFjayBhZ2FpbnN0IHRoZSBjbGllbnQncyBy ZWRpcmVjdGlvbiBVUkkgYWxsb3dzIGFuIGF0dGFja2VyCiAgIHRvIGluamVjdCB0aGVpciBvd24g YXV0aG9yaXphdGlvbiBjb2RlIG9yIGFjY2VzcyB0b2tlbiwgd2hpY2ggY2FuCiAgIHJlc3VsdCBp biB0aGUgY2xpZW50IHVzaW5nIGFuIGFjY2VzcyB0b2tlbiBhc3NvY2lhdGVkIHdpdGggdGhlCiAg IGF0dGFja2VyJ3MgcHJvdGVjdGVkIHJlc291cmNlcyByYXRoZXIgdGhhbiB0aGUgdmljdGltJ3Mg KGUuZy4gc2F2ZQogICB0aGUgdmljdGltJ3MgYmFuayBhY2NvdW50IGluZm9ybWF0aW9uIHRvIGEg cHJvdGVjdGVkIHJlc291cmNlCiAgIGNvbnRyb2xsZWQgYnkgdGhlIGF0dGFja2VyKS4KCiAgIFRo ZSBjbGllbnQgTVVTVCBpbXBsZW1lbnQgQ1NSRiBwcm90ZWN0aW9uIGZvciBpdHMgcmVkaXJlY3Rp b24gVVJJLgogICBUaGlzIGlzIHR5cGljYWxseSBhY2NvbXBsaXNoZWQgYnkgcmVxdWlyaW5nIGFu eSByZXF1ZXN0IHNlbnQgdG8gdGhlCiAgIHJlZGlyZWN0aW9uIFVSSSBlbmRwb2ludCB0byBpbmNs dWRlIGEgdmFsdWUgdGhhdCBiaW5kcyB0aGUgcmVxdWVzdCB0bwogICB0aGUgdXNlci1hZ2VudCdz IGF1dGhlbnRpY2F0ZWQgc3RhdGUgKGUuZy4gYSBoYXNoIG9mIHRoZSBzZXNzaW9uCiAgIGNvb2tp ZSB1c2VkIHRvIGF1dGhlbnRpY2F0ZSB0aGUgdXNlci1hZ2VudCkuICBUaGUgY2xpZW50IFNIT1VM RAoKCgpIYW1tZXIsIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIERlY2VtYmVyIDEwLCAyMDEyICAg ICAgICAgICAgICBbUGFnZSA1NV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgIE9B dXRoIDIuMCAgICAgICAgICAgICAgICAgICAgICBKdW5lIDIwMTIKCgogICB1dGlsaXplIHRoZSAi c3RhdGUiIHJlcXVlc3QgcGFyYW1ldGVyIHRvIGRlbGl2ZXIgdGhpcyB2YWx1ZSB0byB0aGUKICAg YXV0aG9yaXphdGlvbiBzZXJ2ZXIgd2hlbiBtYWtpbmcgYW4gYXV0aG9yaXphdGlvbiByZXF1ZXN0 LgoKICAgT25jZSBhdXRob3JpemF0aW9uIGhhcyBiZWVuIG9idGFpbmVkIGZyb20gdGhlIGVuZC11 c2VyLCB0aGUKICAgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgcmVkaXJlY3RzIHRoZSBlbmQtdXNlcidz IHVzZXItYWdlbnQgYmFjayB0byB0aGUKICAgY2xpZW50IHdpdGggdGhlIHJlcXVpcmVkIGJpbmRp bmcgdmFsdWUgY29udGFpbmVkIGluIHRoZSAic3RhdGUiCiAgIHBhcmFtZXRlci4gIFRoZSBiaW5k aW5nIHZhbHVlIGVuYWJsZXMgdGhlIGNsaWVudCB0byB2ZXJpZnkgdGhlCiAgIHZhbGlkaXR5IG9m IHRoZSByZXF1ZXN0IGJ5IG1hdGNoaW5nIHRoZSBiaW5kaW5nIHZhbHVlIHRvIHRoZSB1c2VyLQog ICBhZ2VudCdzIGF1dGhlbnRpY2F0ZWQgc3RhdGUuICBUaGUgYmluZGluZyB2YWx1ZSB1c2VkIGZv ciBDU1JGCiAgIHByb3RlY3Rpb24gTVVTVCBjb250YWluIGEgbm9uLWd1ZXNzYWJsZSB2YWx1ZSAo YXMgZGVzY3JpYmVkIGluCiAgIFNlY3Rpb24gMTAuMTApLCBhbmQgdGhlIHVzZXItYWdlbnQncyBh dXRoZW50aWNhdGVkIHN0YXRlIChlLmcuCiAgIHNlc3Npb24gY29va2llLCBIVE1MNSBsb2NhbCBz dG9yYWdlKSBNVVNUIGJlIGtlcHQgaW4gYSBsb2NhdGlvbgogICBhY2Nlc3NpYmxlIG9ubHkgdG8g dGhlIGNsaWVudCBhbmQgdGhlIHVzZXItYWdlbnQgKGkuZS4sIHByb3RlY3RlZCBieQogICBzYW1l LW9yaWdpbiBwb2xpY3kpLgoKICAgQSBDU1JGIGF0dGFjayBhZ2FpbnN0IHRoZSBhdXRob3JpemF0 aW9uIHNlcnZlcidzIGF1dGhvcml6YXRpb24KICAgZW5kcG9pbnQgY2FuIHJlc3VsdCBpbiBhbiBh dHRhY2tlciBvYnRhaW5pbmcgZW5kLXVzZXIgYXV0aG9yaXphdGlvbgogICBmb3IgYSBtYWxpY2lv dXMgY2xpZW50IHdpdGhvdXQgaW52b2x2aW5nIG9yIGFsZXJ0aW5nIHRoZSBlbmQtdXNlci4KCiAg IFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBNVVNUIGltcGxlbWVudCBDU1JGIHByb3RlY3Rpb24g Zm9yIGl0cwogICBhdXRob3JpemF0aW9uIGVuZHBvaW50LCBhbmQgZW5zdXJlIHRoYXQgYSBtYWxp Y2lvdXMgY2xpZW50IGNhbm5vdAogICBvYnRhaW4gYXV0aG9yaXphdGlvbiB3aXRob3V0IHRoZSBh d2FyZW5lc3MgYW5kIGV4cGxpY2l0IGNvbnNlbnQgb2YKICAgdGhlIHJlc291cmNlIG93bmVyLgoK MTAuMTMuICBDbGlja2phY2tpbmcKCiAgIEluIGEgY2xpY2tqYWNraW5nIGF0dGFjaywgYW4gYXR0 YWNrZXIgcmVnaXN0ZXJzIGEgbGVnaXRpbWF0ZSBjbGllbnQKICAgYW5kIHRoZW4gY29uc3RydWN0 cyBhIG1hbGljaW91cyBzaXRlIGluIHdoaWNoIGl0IGxvYWRzIHRoZQogICBhdXRob3JpemF0aW9u IHNlcnZlcidzIGF1dGhvcml6YXRpb24gZW5kcG9pbnQgd2ViIHBhZ2UgaW4gYQogICB0cmFuc3Bh cmVudCBpZnJhbWUgb3ZlcmxhaWQgb24gdG9wIG9mIGEgc2V0IG9mIGR1bW15IGJ1dHRvbnMgd2hp Y2gKICAgYXJlIGNhcmVmdWxseSBjb25zdHJ1Y3RlZCB0byBiZSBwbGFjZWQgZGlyZWN0bHkgdW5k ZXIgaW1wb3J0YW50CiAgIGJ1dHRvbnMgb24gdGhlIGF1dGhvcml6YXRpb24gcGFnZS4gIFdoZW4g YW4gZW5kLXVzZXIgY2xpY2tzIGEKICAgbWlzbGVhZGluZyB2aXNpYmxlIGJ1dHRvbiwgdGhlIGVu ZC11c2VyIGlzIGFjdHVhbGx5IGNsaWNraW5nIGFuCiAgIGludmlzaWJsZSBidXR0b24gb24gdGhl IGF1dGhvcml6YXRpb24gcGFnZSAoc3VjaCBhcyBhbiAiQXV0aG9yaXplIgogICBidXR0b24pLiAg VGhpcyBhbGxvd3MgYW4gYXR0YWNrZXIgdG8gdHJpY2sgYSByZXNvdXJjZSBvd25lciBpbnRvCiAg IGdyYW50aW5nIGl0cyBjbGllbnQgYWNjZXNzIHdpdGhvdXQgdGhlaXIga25vd2xlZGdlLgoKICAg VG8gcHJldmVudCB0aGlzIGZvcm0gb2YgYXR0YWNrLCBuYXRpdmUgYXBwbGljYXRpb25zIFNIT1VM RCB1c2UKICAgZXh0ZXJuYWwgYnJvd3NlcnMgaW5zdGVhZCBvZiBlbWJlZGRpbmcgYnJvd3NlcnMg d2l0aGluIHRoZQogICBhcHBsaWNhdGlvbiB3aGVuIHJlcXVlc3RpbmcgZW5kLXVzZXIgYXV0aG9y aXphdGlvbi4gIEZvciBtb3N0IG5ld2VyCiAgIGJyb3dzZXJzLCBhdm9pZGFuY2Ugb2YgaWZyYW1l cyBjYW4gYmUgZW5mb3JjZWQgYnkgdGhlIGF1dGhvcml6YXRpb24KICAgc2VydmVyIHVzaW5nIHRo ZSAobm9uLXN0YW5kYXJkKSAieC1mcmFtZS1vcHRpb25zIiBoZWFkZXIuICBUaGlzCiAgIGhlYWRl ciBjYW4gaGF2ZSB0d28gdmFsdWVzLCAiZGVueSIgYW5kICJzYW1lb3JpZ2luIiwgd2hpY2ggd2ls bCBibG9jawogICBhbnkgZnJhbWluZywgb3IgZnJhbWluZyBieSBzaXRlcyB3aXRoIGEgZGlmZmVy ZW50IG9yaWdpbiwKICAgcmVzcGVjdGl2ZWx5LiAgRm9yIG9sZGVyIGJyb3dzZXJzLCBKYXZhU2Ny aXB0IGZyYW1lYnVzdGluZyB0ZWNobmlxdWVzCiAgIGNhbiBiZSB1c2VkIGJ1dCBtYXkgbm90IGJl IGVmZmVjdGl2ZSBpbiBhbGwgYnJvd3NlcnMuCgoKCgoKSGFtbWVyLCBldCBhbC4gICAgICAgICAg RXhwaXJlcyBEZWNlbWJlciAxMCwgMjAxMiAgICAgICAgICAgICAgW1BhZ2UgNTZdCgwKSW50ZXJu ZXQtRHJhZnQgICAgICAgICAgICAgICAgICBPQXV0aCAyLjAgICAgICAgICAgICAgICAgICAgICAg SnVuZSAyMDEyCgoKMTAuMTQuICBDb2RlIEluamVjdGlvbiBhbmQgSW5wdXQgVmFsaWRhdGlvbgoK ICAgQSBjb2RlIGluamVjdGlvbiBhdHRhY2sgb2NjdXJzIHdoZW4gYW4gaW5wdXQgb3Igb3RoZXJ3 aXNlIGV4dGVybmFsCiAgIHZhcmlhYmxlIGlzIHVzZWQgYnkgYW4gYXBwbGljYXRpb24gdW5zYW5p dGl6ZWQgYW5kIGNhdXNlcwogICBtb2RpZmljYXRpb24gdG8gdGhlIGFwcGxpY2F0aW9uIGxvZ2lj LiAgVGhpcyBtYXkgYWxsb3cgYW4gYXR0YWNrZXIgdG8KICAgZ2FpbiBhY2Nlc3MgdG8gdGhlIGFw cGxpY2F0aW9uIGRldmljZSBvciBpdHMgZGF0YSwgY2F1c2UgZGVuaWFsIG9mCiAgIHNlcnZpY2Us IG9yIGEgd2lkZSByYW5nZSBvZiBtYWxpY2lvdXMgc2lkZS1lZmZlY3RzLgoKICAgVGhlIEF1dGhv cml6YXRpb24gc2VydmVyIGFuZCBjbGllbnQgTVVTVCBzYW5pdGl6ZSAoYW5kIHZhbGlkYXRlIHdo ZW4KICAgcG9zc2libGUpIGFueSB2YWx1ZSByZWNlaXZlZCwgaW4gcGFydGljdWxhciwgdGhlIHZh bHVlIG9mIHRoZSAic3RhdGUiCiAgIGFuZCAicmVkaXJlY3RfdXJpIiBwYXJhbWV0ZXJzLgoKMTAu MTUuICBPcGVuIFJlZGlyZWN0b3JzCgogICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYXV0aG9y aXphdGlvbiBlbmRwb2ludCBhbmQgdGhlIGNsaWVudAogICByZWRpcmVjdGlvbiBlbmRwb2ludCBj YW4gYmUgaW1wcm9wZXJseSBjb25maWd1cmVkIGFuZCBvcGVyYXRlIGFzIG9wZW4KICAgcmVkaXJl Y3RvcnMuICBBbiBvcGVuIHJlZGlyZWN0b3IgaXMgYW4gZW5kcG9pbnQgdXNpbmcgYSBwYXJhbWV0 ZXIgdG8KICAgYXV0b21hdGljYWxseSByZWRpcmVjdCBhIHVzZXItYWdlbnQgdG8gdGhlIGxvY2F0 aW9uIHNwZWNpZmllZCBieSB0aGUKICAgcGFyYW1ldGVyIHZhbHVlIHdpdGhvdXQgYW55IHZhbGlk YXRpb24uCgogICBPcGVuIHJlZGlyZWN0b3JzIGNhbiBiZSB1c2VkIGluIHBoaXNoaW5nIGF0dGFj a3MsIG9yIGJ5IGFuIGF0dGFja2VyCiAgIHRvIGdldCBlbmQtdXNlcnMgdG8gdmlzaXQgbWFsaWNp b3VzIHNpdGVzIGJ5IG1ha2luZyB0aGUgVVJJJ3MKICAgYXV0aG9yaXR5IGxvb2sgbGlrZSBhIGZh bWlsaWFyIGFuZCB0cnVzdGVkIGRlc3RpbmF0aW9uLiAgSW4gYWRkaXRpb24sCiAgIGlmIHRoZSBh dXRob3JpemF0aW9uIHNlcnZlciBhbGxvd3MgdGhlIGNsaWVudCB0byByZWdpc3RlciBvbmx5IHBh cnQKICAgb2YgdGhlIHJlZGlyZWN0aW9uIFVSSSwgYW4gYXR0YWNrZXIgY2FuIHVzZSBhbiBvcGVu IHJlZGlyZWN0b3IKICAgb3BlcmF0ZWQgYnkgdGhlIGNsaWVudCB0byBjb25zdHJ1Y3QgYSByZWRp cmVjdGlvbiBVUkkgdGhhdCB3aWxsIHBhc3MKICAgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHZh bGlkYXRpb24gYnV0IHdpbGwgc2VuZCB0aGUgYXV0aG9yaXphdGlvbgogICBjb2RlIG9yIGFjY2Vz cyB0b2tlbiB0byBhbiBlbmRwb2ludCB1bmRlciB0aGUgY29udHJvbCBvZiB0aGUKICAgYXR0YWNr ZXIuCgoKMTEuICBJQU5BIENvbnNpZGVyYXRpb25zCgoxMS4xLiAgVGhlIE9BdXRoIEFjY2VzcyBU b2tlbiBUeXBlIFJlZ2lzdHJ5CgogICBUaGlzIHNwZWNpZmljYXRpb24gZXN0YWJsaXNoZXMgdGhl IE9BdXRoIGFjY2VzcyB0b2tlbiB0eXBlIHJlZ2lzdHJ5LgoKICAgQWNjZXNzIHRva2VuIHR5cGVz IGFyZSByZWdpc3RlcmVkIHdpdGggYSBTcGVjaWZpY2F0aW9uIFJlcXVpcmVkCiAgIChbUkZDNTIy Nl0pIGFmdGVyIGEgdHdvIHdlZWsgcmV2aWV3IHBlcmlvZCBvbiB0aGUgW1RCRF1AaWV0Zi5vcmcK ICAgbWFpbGluZyBsaXN0LCBvbiB0aGUgYWR2aWNlIG9mIG9uZSBvciBtb3JlIERlc2lnbmF0ZWQg RXhwZXJ0cy4KICAgSG93ZXZlciwgdG8gYWxsb3cgZm9yIHRoZSBhbGxvY2F0aW9uIG9mIHZhbHVl cyBwcmlvciB0byBwdWJsaWNhdGlvbiwKICAgdGhlIERlc2lnbmF0ZWQgRXhwZXJ0KHMpIG1heSBh cHByb3ZlIHJlZ2lzdHJhdGlvbiBvbmNlIHRoZXkgYXJlCiAgIHNhdGlzZmllZCB0aGF0IHN1Y2gg YSBzcGVjaWZpY2F0aW9uIHdpbGwgYmUgcHVibGlzaGVkLgoKICAgUmVnaXN0cmF0aW9uIHJlcXVl c3RzIG11c3QgYmUgc2VudCB0byB0aGUgW1RCRF1AaWV0Zi5vcmcgbWFpbGluZyBsaXN0CiAgIGZv ciByZXZpZXcgYW5kIGNvbW1lbnQsIHdpdGggYW4gYXBwcm9wcmlhdGUgc3ViamVjdCAoZS5nLiwg IlJlcXVlc3QKICAgZm9yIGFjY2VzcyB0b2tlbiB0eXBlOiBleGFtcGxlIikuIFtbIE5vdGUgdG8g UkZDLUVESVRPUjogVGhlIG5hbWUgb2YKICAgdGhlIG1haWxpbmcgbGlzdCBzaG91bGQgYmUgZGV0 ZXJtaW5lZCBpbiBjb25zdWx0YXRpb24gd2l0aCB0aGUgSUVTRwoKCgpIYW1tZXIsIGV0IGFsLiAg ICAgICAgICBFeHBpcmVzIERlY2VtYmVyIDEwLCAyMDEyICAgICAgICAgICAgICBbUGFnZSA1N10K DApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgIE9BdXRoIDIuMCAgICAgICAgICAgICAg ICAgICAgICBKdW5lIDIwMTIKCgogICBhbmQgSUFOQS4gIFN1Z2dlc3RlZCBuYW1lOiBvYXV0aC1l eHQtcmV2aWV3LiBdXQoKICAgV2l0aGluIHRoZSByZXZpZXcgcGVyaW9kLCB0aGUgRGVzaWduYXRl ZCBFeHBlcnQocykgd2lsbCBlaXRoZXIKICAgYXBwcm92ZSBvciBkZW55IHRoZSByZWdpc3RyYXRp b24gcmVxdWVzdCwgY29tbXVuaWNhdGluZyB0aGlzIGRlY2lzaW9uCiAgIHRvIHRoZSByZXZpZXcg bGlzdCBhbmQgSUFOQS4gIERlbmlhbHMgc2hvdWxkIGluY2x1ZGUgYW4gZXhwbGFuYXRpb24KICAg YW5kLCBpZiBhcHBsaWNhYmxlLCBzdWdnZXN0aW9ucyBhcyB0byBob3cgdG8gbWFrZSB0aGUgcmVx dWVzdAogICBzdWNjZXNzZnVsLgoKICAgSUFOQSBtdXN0IG9ubHkgYWNjZXB0IHJlZ2lzdHJ5IHVw ZGF0ZXMgZnJvbSB0aGUgRGVzaWduYXRlZCBFeHBlcnQocyksCiAgIGFuZCBzaG91bGQgZGlyZWN0 IGFsbCByZXF1ZXN0cyBmb3IgcmVnaXN0cmF0aW9uIHRvIHRoZSByZXZpZXcgbWFpbGluZwogICBs aXN0LgoKMTEuMS4xLiAgUmVnaXN0cmF0aW9uIFRlbXBsYXRlCgogICBUeXBlIG5hbWU6CiAgICAg IFRoZSBuYW1lIHJlcXVlc3RlZCAoZS5nLiwgImV4YW1wbGUiKS4KICAgQWRkaXRpb25hbCBUb2tl biBFbmRwb2ludCBSZXNwb25zZSBQYXJhbWV0ZXJzOgogICAgICBBZGRpdGlvbmFsIHJlc3BvbnNl IHBhcmFtZXRlcnMgcmV0dXJuZWQgdG9nZXRoZXIgd2l0aCB0aGUKICAgICAgImFjY2Vzc190b2tl biIgcGFyYW1ldGVyLiAgTmV3IHBhcmFtZXRlcnMgTVVTVCBiZSBzZXBhcmF0ZWx5CiAgICAgIHJl Z2lzdGVyZWQgaW4gdGhlIE9BdXRoIHBhcmFtZXRlcnMgcmVnaXN0cnkgYXMgZGVzY3JpYmVkIGJ5 CiAgICAgIFNlY3Rpb24gMTEuMi4KICAgSFRUUCBBdXRoZW50aWNhdGlvbiBTY2hlbWUocyk6CiAg ICAgIFRoZSBIVFRQIGF1dGhlbnRpY2F0aW9uIHNjaGVtZSBuYW1lKHMpLCBpZiBhbnksIHVzZWQg dG8KICAgICAgYXV0aGVudGljYXRlIHByb3RlY3RlZCByZXNvdXJjZXMgcmVxdWVzdHMgdXNpbmcg YWNjZXNzIHRva2VucyBvZgogICAgICB0aGlzIHR5cGUuCiAgIENoYW5nZSBjb250cm9sbGVyOgog ICAgICBGb3Igc3RhbmRhcmRzLXRyYWNrIFJGQ3MsIHN0YXRlICJJRVRGIi4gIEZvciBvdGhlcnMs IGdpdmUgdGhlIG5hbWUKICAgICAgb2YgdGhlIHJlc3BvbnNpYmxlIHBhcnR5LiAgT3RoZXIgZGV0 YWlscyAoZS5nLiwgcG9zdGFsIGFkZHJlc3MsCiAgICAgIGUtbWFpbCBhZGRyZXNzLCBob21lIHBh Z2UgVVJJKSBtYXkgYWxzbyBiZSBpbmNsdWRlZC4KICAgU3BlY2lmaWNhdGlvbiBkb2N1bWVudChz KToKICAgICAgUmVmZXJlbmNlIHRvIHRoZSBkb2N1bWVudCB0aGF0IHNwZWNpZmllcyB0aGUgcGFy YW1ldGVyLCBwcmVmZXJhYmx5CiAgICAgIGluY2x1ZGluZyBhIFVSSSB0aGF0IGNhbiBiZSB1c2Vk IHRvIHJldHJpZXZlIGEgY29weSBvZiB0aGUKICAgICAgZG9jdW1lbnQuICBBbiBpbmRpY2F0aW9u IG9mIHRoZSByZWxldmFudCBzZWN0aW9ucyBtYXkgYWxzbyBiZQogICAgICBpbmNsdWRlZCwgYnV0 IGlzIG5vdCByZXF1aXJlZC4KCjExLjIuICBUaGUgT0F1dGggUGFyYW1ldGVycyBSZWdpc3RyeQoK ICAgVGhpcyBzcGVjaWZpY2F0aW9uIGVzdGFibGlzaGVzIHRoZSBPQXV0aCBwYXJhbWV0ZXJzIHJl Z2lzdHJ5LgoKICAgQWRkaXRpb25hbCBwYXJhbWV0ZXJzIGZvciBpbmNsdXNpb24gaW4gdGhlIGF1 dGhvcml6YXRpb24gZW5kcG9pbnQKICAgcmVxdWVzdCwgdGhlIGF1dGhvcml6YXRpb24gZW5kcG9p bnQgcmVzcG9uc2UsIHRoZSB0b2tlbiBlbmRwb2ludAogICByZXF1ZXN0LCBvciB0aGUgdG9rZW4g ZW5kcG9pbnQgcmVzcG9uc2UgYXJlIHJlZ2lzdGVyZWQgd2l0aCBhCiAgIFNwZWNpZmljYXRpb24g UmVxdWlyZWQgKFtSRkM1MjI2XSkgYWZ0ZXIgYSB0d28gd2VlayByZXZpZXcgcGVyaW9kIG9uCiAg IHRoZSBbVEJEXUBpZXRmLm9yZyBtYWlsaW5nIGxpc3QsIG9uIHRoZSBhZHZpY2Ugb2Ygb25lIG9y IG1vcmUKICAgRGVzaWduYXRlZCBFeHBlcnRzLiAgSG93ZXZlciwgdG8gYWxsb3cgZm9yIHRoZSBh bGxvY2F0aW9uIG9mIHZhbHVlcwogICBwcmlvciB0byBwdWJsaWNhdGlvbiwgdGhlIERlc2lnbmF0 ZWQgRXhwZXJ0KHMpIG1heSBhcHByb3ZlCiAgIHJlZ2lzdHJhdGlvbiBvbmNlIHRoZXkgYXJlIHNh dGlzZmllZCB0aGF0IHN1Y2ggYSBzcGVjaWZpY2F0aW9uIHdpbGwKICAgYmUgcHVibGlzaGVkLgoK CgpIYW1tZXIsIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIERlY2VtYmVyIDEwLCAyMDEyICAgICAg ICAgICAgICBbUGFnZSA1OF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgIE9BdXRo IDIuMCAgICAgICAgICAgICAgICAgICAgICBKdW5lIDIwMTIKCgogICBSZWdpc3RyYXRpb24gcmVx dWVzdHMgbXVzdCBiZSBzZW50IHRvIHRoZSBbVEJEXUBpZXRmLm9yZyBtYWlsaW5nIGxpc3QKICAg Zm9yIHJldmlldyBhbmQgY29tbWVudCwgd2l0aCBhbiBhcHByb3ByaWF0ZSBzdWJqZWN0IChlLmcu LCAiUmVxdWVzdAogICBmb3IgcGFyYW1ldGVyOiBleGFtcGxlIikuIFtbIE5vdGUgdG8gUkZDLUVE SVRPUjogVGhlIG5hbWUgb2YgdGhlCiAgIG1haWxpbmcgbGlzdCBzaG91bGQgYmUgZGV0ZXJtaW5l ZCBpbiBjb25zdWx0YXRpb24gd2l0aCB0aGUgSUVTRyBhbmQKICAgSUFOQS4gIFN1Z2dlc3RlZCBu YW1lOiBvYXV0aC1leHQtcmV2aWV3LiBdXQoKICAgV2l0aGluIHRoZSByZXZpZXcgcGVyaW9kLCB0 aGUgRGVzaWduYXRlZCBFeHBlcnQocykgd2lsbCBlaXRoZXIKICAgYXBwcm92ZSBvciBkZW55IHRo ZSByZWdpc3RyYXRpb24gcmVxdWVzdCwgY29tbXVuaWNhdGluZyB0aGlzIGRlY2lzaW9uCiAgIHRv IHRoZSByZXZpZXcgbGlzdCBhbmQgSUFOQS4gIERlbmlhbHMgc2hvdWxkIGluY2x1ZGUgYW4gZXhw bGFuYXRpb24KICAgYW5kLCBpZiBhcHBsaWNhYmxlLCBzdWdnZXN0aW9ucyBhcyB0byBob3cgdG8g bWFrZSB0aGUgcmVxdWVzdAogICBzdWNjZXNzZnVsLgoKICAgSUFOQSBtdXN0IG9ubHkgYWNjZXB0 IHJlZ2lzdHJ5IHVwZGF0ZXMgZnJvbSB0aGUgRGVzaWduYXRlZCBFeHBlcnQocyksCiAgIGFuZCBz aG91bGQgZGlyZWN0IGFsbCByZXF1ZXN0cyBmb3IgcmVnaXN0cmF0aW9uIHRvIHRoZSByZXZpZXcg bWFpbGluZwogICBsaXN0LgoKMTEuMi4xLiAgUmVnaXN0cmF0aW9uIFRlbXBsYXRlCgogICBQYXJh bWV0ZXIgbmFtZToKICAgICAgVGhlIG5hbWUgcmVxdWVzdGVkIChlLmcuLCAiZXhhbXBsZSIpLgog ICBQYXJhbWV0ZXIgdXNhZ2UgbG9jYXRpb246CiAgICAgIFRoZSBsb2NhdGlvbihzKSB3aGVyZSBw YXJhbWV0ZXIgY2FuIGJlIHVzZWQuICBUaGUgcG9zc2libGUKICAgICAgbG9jYXRpb25zIGFyZTog YXV0aG9yaXphdGlvbiByZXF1ZXN0LCBhdXRob3JpemF0aW9uIHJlc3BvbnNlLAogICAgICB0b2tl biByZXF1ZXN0LCBvciB0b2tlbiByZXNwb25zZS4KICAgQ2hhbmdlIGNvbnRyb2xsZXI6CiAgICAg IEZvciBzdGFuZGFyZHMtdHJhY2sgUkZDcywgc3RhdGUgIklFVEYiLiAgRm9yIG90aGVycywgZ2l2 ZSB0aGUgbmFtZQogICAgICBvZiB0aGUgcmVzcG9uc2libGUgcGFydHkuICBPdGhlciBkZXRhaWxz IChlLmcuLCBwb3N0YWwgYWRkcmVzcywKICAgICAgZS1tYWlsIGFkZHJlc3MsIGhvbWUgcGFnZSBV UkkpIG1heSBhbHNvIGJlIGluY2x1ZGVkLgogICBTcGVjaWZpY2F0aW9uIGRvY3VtZW50KHMpOgog ICAgICBSZWZlcmVuY2UgdG8gdGhlIGRvY3VtZW50IHRoYXQgc3BlY2lmaWVzIHRoZSBwYXJhbWV0 ZXIsIHByZWZlcmFibHkKICAgICAgaW5jbHVkaW5nIGEgVVJJIHRoYXQgY2FuIGJlIHVzZWQgdG8g cmV0cmlldmUgYSBjb3B5IG9mIHRoZQogICAgICBkb2N1bWVudC4gIEFuIGluZGljYXRpb24gb2Yg dGhlIHJlbGV2YW50IHNlY3Rpb25zIG1heSBhbHNvIGJlCiAgICAgIGluY2x1ZGVkLCBidXQgaXMg bm90IHJlcXVpcmVkLgoKMTEuMi4yLiAgSW5pdGlhbCBSZWdpc3RyeSBDb250ZW50cwoKICAgVGhl IE9BdXRoIFBhcmFtZXRlcnMgUmVnaXN0cnkncyBpbml0aWFsIGNvbnRlbnRzIGFyZToKCiAgIG8g IFBhcmFtZXRlciBuYW1lOiBjbGllbnRfaWQKICAgbyAgUGFyYW1ldGVyIHVzYWdlIGxvY2F0aW9u OiBhdXRob3JpemF0aW9uIHJlcXVlc3QsIHRva2VuIHJlcXVlc3QKICAgbyAgQ2hhbmdlIGNvbnRy b2xsZXI6IElFVEYKICAgbyAgU3BlY2lmaWNhdGlvbiBkb2N1bWVudChzKTogW1sgdGhpcyBkb2N1 bWVudCBdXQoKICAgbyAgUGFyYW1ldGVyIG5hbWU6IGNsaWVudF9zZWNyZXQKICAgbyAgUGFyYW1l dGVyIHVzYWdlIGxvY2F0aW9uOiB0b2tlbiByZXF1ZXN0CiAgIG8gIENoYW5nZSBjb250cm9sbGVy OiBJRVRGCgoKCgoKSGFtbWVyLCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBEZWNlbWJlciAxMCwg MjAxMiAgICAgICAgICAgICAgW1BhZ2UgNTldCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAg ICAgICBPQXV0aCAyLjAgICAgICAgICAgICAgICAgICAgICAgSnVuZSAyMDEyCgoKICAgbyAgU3Bl Y2lmaWNhdGlvbiBkb2N1bWVudChzKTogW1sgdGhpcyBkb2N1bWVudCBdXQoKICAgbyAgUGFyYW1l dGVyIG5hbWU6IHJlc3BvbnNlX3R5cGUKICAgbyAgUGFyYW1ldGVyIHVzYWdlIGxvY2F0aW9uOiBh dXRob3JpemF0aW9uIHJlcXVlc3QKICAgbyAgQ2hhbmdlIGNvbnRyb2xsZXI6IElFVEYKICAgbyAg U3BlY2lmaWNhdGlvbiBkb2N1bWVudChzKTogW1sgdGhpcyBkb2N1bWVudCBdXQoKICAgbyAgUGFy YW1ldGVyIG5hbWU6IHJlZGlyZWN0X3VyaQogICBvICBQYXJhbWV0ZXIgdXNhZ2UgbG9jYXRpb246 IGF1dGhvcml6YXRpb24gcmVxdWVzdCwgdG9rZW4gcmVxdWVzdAogICBvICBDaGFuZ2UgY29udHJv bGxlcjogSUVURgogICBvICBTcGVjaWZpY2F0aW9uIGRvY3VtZW50KHMpOiBbWyB0aGlzIGRvY3Vt ZW50IF1dCgogICBvICBQYXJhbWV0ZXIgbmFtZTogc2NvcGUKICAgbyAgUGFyYW1ldGVyIHVzYWdl IGxvY2F0aW9uOiBhdXRob3JpemF0aW9uIHJlcXVlc3QsIGF1dGhvcml6YXRpb24KICAgICAgcmVz cG9uc2UsIHRva2VuIHJlcXVlc3QsIHRva2VuIHJlc3BvbnNlCiAgIG8gIENoYW5nZSBjb250cm9s bGVyOiBJRVRGCiAgIG8gIFNwZWNpZmljYXRpb24gZG9jdW1lbnQocyk6IFtbIHRoaXMgZG9jdW1l bnQgXV0KCiAgIG8gIFBhcmFtZXRlciBuYW1lOiBzdGF0ZQogICBvICBQYXJhbWV0ZXIgdXNhZ2Ug bG9jYXRpb246IGF1dGhvcml6YXRpb24gcmVxdWVzdCwgYXV0aG9yaXphdGlvbgogICAgICByZXNw b25zZQogICBvICBDaGFuZ2UgY29udHJvbGxlcjogSUVURgogICBvICBTcGVjaWZpY2F0aW9uIGRv Y3VtZW50KHMpOiBbWyB0aGlzIGRvY3VtZW50IF1dCgogICBvICBQYXJhbWV0ZXIgbmFtZTogY29k ZQogICBvICBQYXJhbWV0ZXIgdXNhZ2UgbG9jYXRpb246IGF1dGhvcml6YXRpb24gcmVzcG9uc2Us IHRva2VuIHJlcXVlc3QKICAgbyAgQ2hhbmdlIGNvbnRyb2xsZXI6IElFVEYKICAgbyAgU3BlY2lm aWNhdGlvbiBkb2N1bWVudChzKTogW1sgdGhpcyBkb2N1bWVudCBdXQoKICAgbyAgUGFyYW1ldGVy IG5hbWU6IGVycm9yX2Rlc2NyaXB0aW9uCiAgIG8gIFBhcmFtZXRlciB1c2FnZSBsb2NhdGlvbjog YXV0aG9yaXphdGlvbiByZXNwb25zZSwgdG9rZW4gcmVzcG9uc2UKICAgbyAgQ2hhbmdlIGNvbnRy b2xsZXI6IElFVEYKICAgbyAgU3BlY2lmaWNhdGlvbiBkb2N1bWVudChzKTogW1sgdGhpcyBkb2N1 bWVudCBdXQoKICAgbyAgUGFyYW1ldGVyIG5hbWU6IGVycm9yX3VyaQogICBvICBQYXJhbWV0ZXIg dXNhZ2UgbG9jYXRpb246IGF1dGhvcml6YXRpb24gcmVzcG9uc2UsIHRva2VuIHJlc3BvbnNlCiAg IG8gIENoYW5nZSBjb250cm9sbGVyOiBJRVRGCiAgIG8gIFNwZWNpZmljYXRpb24gZG9jdW1lbnQo cyk6IFtbIHRoaXMgZG9jdW1lbnQgXV0KCiAgIG8gIFBhcmFtZXRlciBuYW1lOiBncmFudF90eXBl CiAgIG8gIFBhcmFtZXRlciB1c2FnZSBsb2NhdGlvbjogdG9rZW4gcmVxdWVzdAogICBvICBDaGFu Z2UgY29udHJvbGxlcjogSUVURgogICBvICBTcGVjaWZpY2F0aW9uIGRvY3VtZW50KHMpOiBbWyB0 aGlzIGRvY3VtZW50IF1dCgogICBvICBQYXJhbWV0ZXIgbmFtZTogYWNjZXNzX3Rva2VuCiAgIG8g IFBhcmFtZXRlciB1c2FnZSBsb2NhdGlvbjogYXV0aG9yaXphdGlvbiByZXNwb25zZSwgdG9rZW4g cmVzcG9uc2UKCgoKCgpIYW1tZXIsIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIERlY2VtYmVyIDEw LCAyMDEyICAgICAgICAgICAgICBbUGFnZSA2MF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAg ICAgICAgIE9BdXRoIDIuMCAgICAgICAgICAgICAgICAgICAgICBKdW5lIDIwMTIKCgogICBvICBD aGFuZ2UgY29udHJvbGxlcjogSUVURgogICBvICBTcGVjaWZpY2F0aW9uIGRvY3VtZW50KHMpOiBb WyB0aGlzIGRvY3VtZW50IF1dCgogICBvICBQYXJhbWV0ZXIgbmFtZTogdG9rZW5fdHlwZQogICBv ICBQYXJhbWV0ZXIgdXNhZ2UgbG9jYXRpb246IGF1dGhvcml6YXRpb24gcmVzcG9uc2UsIHRva2Vu IHJlc3BvbnNlCiAgIG8gIENoYW5nZSBjb250cm9sbGVyOiBJRVRGCiAgIG8gIFNwZWNpZmljYXRp b24gZG9jdW1lbnQocyk6IFtbIHRoaXMgZG9jdW1lbnQgXV0KCiAgIG8gIFBhcmFtZXRlciBuYW1l OiBleHBpcmVzX2luCiAgIG8gIFBhcmFtZXRlciB1c2FnZSBsb2NhdGlvbjogYXV0aG9yaXphdGlv biByZXNwb25zZSwgdG9rZW4gcmVzcG9uc2UKICAgbyAgQ2hhbmdlIGNvbnRyb2xsZXI6IElFVEYK ICAgbyAgU3BlY2lmaWNhdGlvbiBkb2N1bWVudChzKTogW1sgdGhpcyBkb2N1bWVudCBdXQoKICAg byAgUGFyYW1ldGVyIG5hbWU6IHVzZXJuYW1lCiAgIG8gIFBhcmFtZXRlciB1c2FnZSBsb2NhdGlv bjogdG9rZW4gcmVxdWVzdAogICBvICBDaGFuZ2UgY29udHJvbGxlcjogSUVURgogICBvICBTcGVj aWZpY2F0aW9uIGRvY3VtZW50KHMpOiBbWyB0aGlzIGRvY3VtZW50IF1dCgogICBvICBQYXJhbWV0 ZXIgbmFtZTogcGFzc3dvcmQKICAgbyAgUGFyYW1ldGVyIHVzYWdlIGxvY2F0aW9uOiB0b2tlbiBy ZXF1ZXN0CiAgIG8gIENoYW5nZSBjb250cm9sbGVyOiBJRVRGCiAgIG8gIFNwZWNpZmljYXRpb24g ZG9jdW1lbnQocyk6IFtbIHRoaXMgZG9jdW1lbnQgXV0KCiAgIG8gIFBhcmFtZXRlciBuYW1lOiBy ZWZyZXNoX3Rva2VuCiAgIG8gIFBhcmFtZXRlciB1c2FnZSBsb2NhdGlvbjogdG9rZW4gcmVxdWVz dCwgdG9rZW4gcmVzcG9uc2UKICAgbyAgQ2hhbmdlIGNvbnRyb2xsZXI6IElFVEYKICAgbyAgU3Bl Y2lmaWNhdGlvbiBkb2N1bWVudChzKTogW1sgdGhpcyBkb2N1bWVudCBdXQoKMTEuMy4gIFRoZSBP QXV0aCBBdXRob3JpemF0aW9uIEVuZHBvaW50IFJlc3BvbnNlIFR5cGUgUmVnaXN0cnkKCiAgIFRo aXMgc3BlY2lmaWNhdGlvbiBlc3RhYmxpc2hlcyB0aGUgT0F1dGggYXV0aG9yaXphdGlvbiBlbmRw b2ludAogICByZXNwb25zZSB0eXBlIHJlZ2lzdHJ5LgoKICAgQWRkaXRpb25hbCByZXNwb25zZSB0 eXBlIGZvciB1c2Ugd2l0aCB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludCBhcmUKICAgcmVnaXN0 ZXJlZCB3aXRoIGEgU3BlY2lmaWNhdGlvbiBSZXF1aXJlZCAoW1JGQzUyMjZdKSBhZnRlciBhIHR3 byB3ZWVrCiAgIHJldmlldyBwZXJpb2Qgb24gdGhlIFtUQkRdQGlldGYub3JnIG1haWxpbmcgbGlz dCwgb24gdGhlIGFkdmljZSBvZgogICBvbmUgb3IgbW9yZSBEZXNpZ25hdGVkIEV4cGVydHMuICBI b3dldmVyLCB0byBhbGxvdyBmb3IgdGhlIGFsbG9jYXRpb24KICAgb2YgdmFsdWVzIHByaW9yIHRv IHB1YmxpY2F0aW9uLCB0aGUgRGVzaWduYXRlZCBFeHBlcnQocykgbWF5IGFwcHJvdmUKICAgcmVn aXN0cmF0aW9uIG9uY2UgdGhleSBhcmUgc2F0aXNmaWVkIHRoYXQgc3VjaCBhIHNwZWNpZmljYXRp b24gd2lsbAogICBiZSBwdWJsaXNoZWQuCgogICBSZWdpc3RyYXRpb24gcmVxdWVzdHMgbXVzdCBi ZSBzZW50IHRvIHRoZSBbVEJEXUBpZXRmLm9yZyBtYWlsaW5nIGxpc3QKICAgZm9yIHJldmlldyBh bmQgY29tbWVudCwgd2l0aCBhbiBhcHByb3ByaWF0ZSBzdWJqZWN0IChlLmcuLCAiUmVxdWVzdAog ICBmb3IgcmVzcG9uc2UgdHlwZTogZXhhbXBsZSIpLiBbWyBOb3RlIHRvIFJGQy1FRElUT1I6IFRo ZSBuYW1lIG9mIHRoZQogICBtYWlsaW5nIGxpc3Qgc2hvdWxkIGJlIGRldGVybWluZWQgaW4gY29u c3VsdGF0aW9uIHdpdGggdGhlIElFU0cgYW5kCiAgIElBTkEuICBTdWdnZXN0ZWQgbmFtZTogb2F1 dGgtZXh0LXJldmlldy4gXV0KCiAgIFdpdGhpbiB0aGUgcmV2aWV3IHBlcmlvZCwgdGhlIERlc2ln bmF0ZWQgRXhwZXJ0KHMpIHdpbGwgZWl0aGVyCgoKCkhhbW1lciwgZXQgYWwuICAgICAgICAgIEV4 cGlyZXMgRGVjZW1iZXIgMTAsIDIwMTIgICAgICAgICAgICAgIFtQYWdlIDYxXQoMCkludGVybmV0 LURyYWZ0ICAgICAgICAgICAgICAgICAgT0F1dGggMi4wICAgICAgICAgICAgICAgICAgICAgIEp1 bmUgMjAxMgoKCiAgIGFwcHJvdmUgb3IgZGVueSB0aGUgcmVnaXN0cmF0aW9uIHJlcXVlc3QsIGNv bW11bmljYXRpbmcgdGhpcyBkZWNpc2lvbgogICB0byB0aGUgcmV2aWV3IGxpc3QgYW5kIElBTkEu ICBEZW5pYWxzIHNob3VsZCBpbmNsdWRlIGFuIGV4cGxhbmF0aW9uCiAgIGFuZCwgaWYgYXBwbGlj YWJsZSwgc3VnZ2VzdGlvbnMgYXMgdG8gaG93IHRvIG1ha2UgdGhlIHJlcXVlc3QKICAgc3VjY2Vz c2Z1bC4KCiAgIElBTkEgbXVzdCBvbmx5IGFjY2VwdCByZWdpc3RyeSB1cGRhdGVzIGZyb20gdGhl IERlc2lnbmF0ZWQgRXhwZXJ0KHMpLAogICBhbmQgc2hvdWxkIGRpcmVjdCBhbGwgcmVxdWVzdHMg Zm9yIHJlZ2lzdHJhdGlvbiB0byB0aGUgcmV2aWV3IG1haWxpbmcKICAgbGlzdC4KCjExLjMuMS4g IFJlZ2lzdHJhdGlvbiBUZW1wbGF0ZQoKICAgUmVzcG9uc2UgdHlwZSBuYW1lOgogICAgICBUaGUg bmFtZSByZXF1ZXN0ZWQgKGUuZy4sICJleGFtcGxlIikuCiAgIENoYW5nZSBjb250cm9sbGVyOgog ICAgICBGb3Igc3RhbmRhcmRzLXRyYWNrIFJGQ3MsIHN0YXRlICJJRVRGIi4gIEZvciBvdGhlcnMs IGdpdmUgdGhlIG5hbWUKICAgICAgb2YgdGhlIHJlc3BvbnNpYmxlIHBhcnR5LiAgT3RoZXIgZGV0 YWlscyAoZS5nLiwgcG9zdGFsIGFkZHJlc3MsCiAgICAgIGUtbWFpbCBhZGRyZXNzLCBob21lIHBh Z2UgVVJJKSBtYXkgYWxzbyBiZSBpbmNsdWRlZC4KICAgU3BlY2lmaWNhdGlvbiBkb2N1bWVudChz KToKICAgICAgUmVmZXJlbmNlIHRvIHRoZSBkb2N1bWVudCB0aGF0IHNwZWNpZmllcyB0aGUgdHlw ZSwgcHJlZmVyYWJseQogICAgICBpbmNsdWRpbmcgYSBVUkkgdGhhdCBjYW4gYmUgdXNlZCB0byBy ZXRyaWV2ZSBhIGNvcHkgb2YgdGhlCiAgICAgIGRvY3VtZW50LiAgQW4gaW5kaWNhdGlvbiBvZiB0 aGUgcmVsZXZhbnQgc2VjdGlvbnMgbWF5IGFsc28gYmUKICAgICAgaW5jbHVkZWQsIGJ1dCBpcyBu b3QgcmVxdWlyZWQuCgoxMS4zLjIuICBJbml0aWFsIFJlZ2lzdHJ5IENvbnRlbnRzCgogICBUaGUg T0F1dGggQXV0aG9yaXphdGlvbiBFbmRwb2ludCBSZXNwb25zZSBUeXBlIFJlZ2lzdHJ5J3MgaW5p dGlhbAogICBjb250ZW50cyBhcmU6CgogICBvICBSZXNwb25zZSB0eXBlIG5hbWU6IGNvZGUKICAg byAgQ2hhbmdlIGNvbnRyb2xsZXI6IElFVEYKICAgbyAgU3BlY2lmaWNhdGlvbiBkb2N1bWVudChz KTogW1sgdGhpcyBkb2N1bWVudCBdXQoKICAgbyAgUmVzcG9uc2UgdHlwZSBuYW1lOiB0b2tlbgog ICBvICBDaGFuZ2UgY29udHJvbGxlcjogSUVURgogICBvICBTcGVjaWZpY2F0aW9uIGRvY3VtZW50 KHMpOiBbWyB0aGlzIGRvY3VtZW50IF1dCgoxMS40LiAgVGhlIE9BdXRoIEV4dGVuc2lvbnMgRXJy b3IgUmVnaXN0cnkKCiAgIFRoaXMgc3BlY2lmaWNhdGlvbiBlc3RhYmxpc2hlcyB0aGUgT0F1dGgg ZXh0ZW5zaW9ucyBlcnJvciByZWdpc3RyeS4KCiAgIEFkZGl0aW9uYWwgZXJyb3IgY29kZXMgdXNl ZCB0b2dldGhlciB3aXRoIG90aGVyIHByb3RvY29sIGV4dGVuc2lvbnMKICAgKGkuZS4gZXh0ZW5z aW9uIGdyYW50IHR5cGVzLCBhY2Nlc3MgdG9rZW4gdHlwZXMsIG9yIGV4dGVuc2lvbgogICBwYXJh bWV0ZXJzKSBhcmUgcmVnaXN0ZXJlZCB3aXRoIGEgU3BlY2lmaWNhdGlvbiBSZXF1aXJlZCAoW1JG QzUyMjZdKQogICBhZnRlciBhIHR3byB3ZWVrIHJldmlldyBwZXJpb2Qgb24gdGhlIFtUQkRdQGll dGYub3JnIG1haWxpbmcgbGlzdCwgb24KICAgdGhlIGFkdmljZSBvZiBvbmUgb3IgbW9yZSBEZXNp Z25hdGVkIEV4cGVydHMuICBIb3dldmVyLCB0byBhbGxvdyBmb3IKICAgdGhlIGFsbG9jYXRpb24g b2YgdmFsdWVzIHByaW9yIHRvIHB1YmxpY2F0aW9uLCB0aGUgRGVzaWduYXRlZAogICBFeHBlcnQo cykgbWF5IGFwcHJvdmUgcmVnaXN0cmF0aW9uIG9uY2UgdGhleSBhcmUgc2F0aXNmaWVkIHRoYXQg c3VjaAogICBhIHNwZWNpZmljYXRpb24gd2lsbCBiZSBwdWJsaXNoZWQuCgoKCkhhbW1lciwgZXQg YWwuICAgICAgICAgIEV4cGlyZXMgRGVjZW1iZXIgMTAsIDIwMTIgICAgICAgICAgICAgIFtQYWdl IDYyXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgT0F1dGggMi4wICAgICAgICAg ICAgICAgICAgICAgIEp1bmUgMjAxMgoKCiAgIFJlZ2lzdHJhdGlvbiByZXF1ZXN0cyBtdXN0IGJl IHNlbnQgdG8gdGhlIFtUQkRdQGlldGYub3JnIG1haWxpbmcgbGlzdAogICBmb3IgcmV2aWV3IGFu ZCBjb21tZW50LCB3aXRoIGFuIGFwcHJvcHJpYXRlIHN1YmplY3QgKGUuZy4sICJSZXF1ZXN0CiAg IGZvciBlcnJvciBjb2RlOiBleGFtcGxlIikuIFtbIE5vdGUgdG8gUkZDLUVESVRPUjogVGhlIG5h bWUgb2YgdGhlCiAgIG1haWxpbmcgbGlzdCBzaG91bGQgYmUgZGV0ZXJtaW5lZCBpbiBjb25zdWx0 YXRpb24gd2l0aCB0aGUgSUVTRyBhbmQKICAgSUFOQS4gIFN1Z2dlc3RlZCBuYW1lOiBvYXV0aC1l eHQtcmV2aWV3LiBdXQoKICAgV2l0aGluIHRoZSByZXZpZXcgcGVyaW9kLCB0aGUgRGVzaWduYXRl ZCBFeHBlcnQocykgd2lsbCBlaXRoZXIKICAgYXBwcm92ZSBvciBkZW55IHRoZSByZWdpc3RyYXRp b24gcmVxdWVzdCwgY29tbXVuaWNhdGluZyB0aGlzIGRlY2lzaW9uCiAgIHRvIHRoZSByZXZpZXcg bGlzdCBhbmQgSUFOQS4gIERlbmlhbHMgc2hvdWxkIGluY2x1ZGUgYW4gZXhwbGFuYXRpb24KICAg YW5kLCBpZiBhcHBsaWNhYmxlLCBzdWdnZXN0aW9ucyBhcyB0byBob3cgdG8gbWFrZSB0aGUgcmVx dWVzdAogICBzdWNjZXNzZnVsLgoKICAgSUFOQSBtdXN0IG9ubHkgYWNjZXB0IHJlZ2lzdHJ5IHVw ZGF0ZXMgZnJvbSB0aGUgRGVzaWduYXRlZCBFeHBlcnQocyksCiAgIGFuZCBzaG91bGQgZGlyZWN0 IGFsbCByZXF1ZXN0cyBmb3IgcmVnaXN0cmF0aW9uIHRvIHRoZSByZXZpZXcgbWFpbGluZwogICBs aXN0LgoKMTEuNC4xLiAgUmVnaXN0cmF0aW9uIFRlbXBsYXRlCgogICBFcnJvciBuYW1lOgogICAg ICBUaGUgbmFtZSByZXF1ZXN0ZWQgKGUuZy4sICJleGFtcGxlIikuCiAgIEVycm9yIHVzYWdlIGxv Y2F0aW9uOgogICAgICBUaGUgbG9jYXRpb24ocykgd2hlcmUgdGhlIGVycm9yIGNhbiBiZSB1c2Vk LiAgVGhlIHBvc3NpYmxlCiAgICAgIGxvY2F0aW9ucyBhcmU6IGF1dGhvcml6YXRpb24gY29kZSBn cmFudCBlcnJvciByZXNwb25zZQogICAgICAoU2VjdGlvbiA0LjEuMi4xKSwgaW1wbGljaXQgZ3Jh bnQgZXJyb3IgcmVzcG9uc2UKICAgICAgKFNlY3Rpb24gNC4yLjIuMSksIHRva2VuIGVycm9yIHJl c3BvbnNlIChTZWN0aW9uIDUuMiksIG9yIHJlc291cmNlCiAgICAgIGFjY2VzcyBlcnJvciByZXNw b25zZSAoU2VjdGlvbiA3LjIpLgogICBSZWxhdGVkIHByb3RvY29sIGV4dGVuc2lvbjoKICAgICAg VGhlIG5hbWUgb2YgdGhlIGV4dGVuc2lvbiBncmFudCB0eXBlLCBhY2Nlc3MgdG9rZW4gdHlwZSwg b3IKICAgICAgZXh0ZW5zaW9uIHBhcmFtZXRlciwgdGhlIGVycm9yIGNvZGUgaXMgdXNlZCBpbiBj b25qdW5jdGlvbiB3aXRoLgogICBDaGFuZ2UgY29udHJvbGxlcjoKICAgICAgRm9yIHN0YW5kYXJk cy10cmFjayBSRkNzLCBzdGF0ZSAiSUVURiIuICBGb3Igb3RoZXJzLCBnaXZlIHRoZSBuYW1lCiAg ICAgIG9mIHRoZSByZXNwb25zaWJsZSBwYXJ0eS4gIE90aGVyIGRldGFpbHMgKGUuZy4sIHBvc3Rh bCBhZGRyZXNzLAogICAgICBlLW1haWwgYWRkcmVzcywgaG9tZSBwYWdlIFVSSSkgbWF5IGFsc28g YmUgaW5jbHVkZWQuCiAgIFNwZWNpZmljYXRpb24gZG9jdW1lbnQocyk6CiAgICAgIFJlZmVyZW5j ZSB0byB0aGUgZG9jdW1lbnQgdGhhdCBzcGVjaWZpZXMgdGhlIGVycm9yIGNvZGUsCiAgICAgIHBy ZWZlcmFibHkgaW5jbHVkaW5nIGEgVVJJIHRoYXQgY2FuIGJlIHVzZWQgdG8gcmV0cmlldmUgYSBj b3B5IG9mCiAgICAgIHRoZSBkb2N1bWVudC4gIEFuIGluZGljYXRpb24gb2YgdGhlIHJlbGV2YW50 IHNlY3Rpb25zIG1heSBhbHNvIGJlCiAgICAgIGluY2x1ZGVkLCBidXQgaXMgbm90IHJlcXVpcmVk LgoKCjEyLiAgUmVmZXJlbmNlcwoKMTIuMS4gIE5vcm1hdGl2ZSBSZWZlcmVuY2VzCgogICBbUkZD MjExOV0gIEJyYWRuZXIsIFMuLCAiS2V5IHdvcmRzIGZvciB1c2UgaW4gUkZDcyB0byBJbmRpY2F0 ZQogICAgICAgICAgICAgIFJlcXVpcmVtZW50IExldmVscyIsIEJDUCAxNCwgUkZDIDIxMTksIE1h cmNoIDE5OTcuCgogICBbUkZDMjI0Nl0gIERpZXJrcywgVC4gYW5kIEMuIEFsbGVuLCAiVGhlIFRM UyBQcm90b2NvbCBWZXJzaW9uIDEuMCIsCgoKCkhhbW1lciwgZXQgYWwuICAgICAgICAgIEV4cGly ZXMgRGVjZW1iZXIgMTAsIDIwMTIgICAgICAgICAgICAgIFtQYWdlIDYzXQoMCkludGVybmV0LURy YWZ0ICAgICAgICAgICAgICAgICAgT0F1dGggMi4wICAgICAgICAgICAgICAgICAgICAgIEp1bmUg MjAxMgoKCiAgICAgICAgICAgICAgUkZDIDIyNDYsIEphbnVhcnkgMTk5OS4KCiAgIFtSRkMyNjE2 XSAgRmllbGRpbmcsIFIuLCBHZXR0eXMsIEouLCBNb2d1bCwgSi4sIEZyeXN0eWssIEguLAogICAg ICAgICAgICAgIE1hc2ludGVyLCBMLiwgTGVhY2gsIFAuLCBhbmQgVC4gQmVybmVycy1MZWUsICJI eXBlcnRleHQKICAgICAgICAgICAgICBUcmFuc2ZlciBQcm90b2NvbCAtLSBIVFRQLzEuMSIsIFJG QyAyNjE2LCBKdW5lIDE5OTkuCgogICBbUkZDMjYxN10gIEZyYW5rcywgSi4sIEhhbGxhbS1CYWtl ciwgUC4sIEhvc3RldGxlciwgSi4sIExhd3JlbmNlLCBTLiwKICAgICAgICAgICAgICBMZWFjaCwg UC4sIEx1b3RvbmVuLCBBLiwgYW5kIEwuIFN0ZXdhcnQsICJIVFRQCiAgICAgICAgICAgICAgQXV0 aGVudGljYXRpb246IEJhc2ljIGFuZCBEaWdlc3QgQWNjZXNzIEF1dGhlbnRpY2F0aW9uIiwKICAg ICAgICAgICAgICBSRkMgMjYxNywgSnVuZSAxOTk5LgoKICAgW1JGQzI4MThdICBSZXNjb3JsYSwg RS4sICJIVFRQIE92ZXIgVExTIiwgUkZDIDI4MTgsIE1heSAyMDAwLgoKICAgW1JGQzM5ODZdICBC ZXJuZXJzLUxlZSwgVC4sIEZpZWxkaW5nLCBSLiwgYW5kIEwuIE1hc2ludGVyLCAiVW5pZm9ybQog ICAgICAgICAgICAgIFJlc291cmNlIElkZW50aWZpZXIgKFVSSSk6IEdlbmVyaWMgU3ludGF4Iiwg U1REIDY2LAogICAgICAgICAgICAgIFJGQyAzOTg2LCBKYW51YXJ5IDIwMDUuCgogICBbUkZDNDYy N10gIENyb2NrZm9yZCwgRC4sICJUaGUgYXBwbGljYXRpb24vanNvbiBNZWRpYSBUeXBlIGZvcgog ICAgICAgICAgICAgIEphdmFTY3JpcHQgT2JqZWN0IE5vdGF0aW9uIChKU09OKSIsIFJGQyA0NjI3 LCBKdWx5IDIwMDYuCgogICBbUkZDNDk0OV0gIFNoaXJleSwgUi4sICJJbnRlcm5ldCBTZWN1cml0 eSBHbG9zc2FyeSwgVmVyc2lvbiAyIiwKICAgICAgICAgICAgICBSRkMgNDk0OSwgQXVndXN0IDIw MDcuCgogICBbUkZDNTIyNl0gIE5hcnRlbiwgVC4gYW5kIEguIEFsdmVzdHJhbmQsICJHdWlkZWxp bmVzIGZvciBXcml0aW5nIGFuCiAgICAgICAgICAgICAgSUFOQSBDb25zaWRlcmF0aW9ucyBTZWN0 aW9uIGluIFJGQ3MiLCBCQ1AgMjYsIFJGQyA1MjI2LAogICAgICAgICAgICAgIE1heSAyMDA4LgoK ICAgW1JGQzUyMzRdICBDcm9ja2VyLCBELiBhbmQgUC4gT3ZlcmVsbCwgIkF1Z21lbnRlZCBCTkYg Zm9yIFN5bnRheAogICAgICAgICAgICAgIFNwZWNpZmljYXRpb25zOiBBQk5GIiwgU1REIDY4LCBS RkMgNTIzNCwgSmFudWFyeSAyMDA4LgoKICAgW1JGQzUyNDZdICBEaWVya3MsIFQuIGFuZCBFLiBS ZXNjb3JsYSwgIlRoZSBUcmFuc3BvcnQgTGF5ZXIgU2VjdXJpdHkKICAgICAgICAgICAgICAoVExT KSBQcm90b2NvbCBWZXJzaW9uIDEuMiIsIFJGQyA1MjQ2LCBBdWd1c3QgMjAwOC4KCiAgIFtSRkM2 MTI1XSAgU2FpbnQtQW5kcmUsIFAuIGFuZCBKLiBIb2RnZXMsICJSZXByZXNlbnRhdGlvbiBhbmQK ICAgICAgICAgICAgICBWZXJpZmljYXRpb24gb2YgRG9tYWluLUJhc2VkIEFwcGxpY2F0aW9uIFNl cnZpY2UgSWRlbnRpdHkKICAgICAgICAgICAgICB3aXRoaW4gSW50ZXJuZXQgUHVibGljIEtleSBJ bmZyYXN0cnVjdHVyZSBVc2luZyBYLjUwOQogICAgICAgICAgICAgIChQS0lYKSBDZXJ0aWZpY2F0 ZXMgaW4gdGhlIENvbnRleHQgb2YgVHJhbnNwb3J0IExheWVyCiAgICAgICAgICAgICAgU2VjdXJp dHkgKFRMUykiLCBSRkMgNjEyNSwgTWFyY2ggMjAxMS4KCiAgIFtVU0FTQ0lJXSAgQW1lcmljYW4g TmF0aW9uYWwgU3RhbmRhcmRzIEluc3RpdHV0ZSwgIkNvZGVkIENoYXJhY3RlcgogICAgICAgICAg ICAgIFNldCAtLSA3LWJpdCBBbWVyaWNhbiBTdGFuZGFyZCBDb2RlIGZvciBJbmZvcm1hdGlvbgog ICAgICAgICAgICAgIEludGVyY2hhbmdlIiwgQU5TSSBYMy40LCAxOTg2LgoKICAgW1czQy5SRUMt aHRtbDQwMS0xOTk5MTIyNF0KICAgICAgICAgICAgICBIb3JzLCBBLiwgUmFnZ2V0dCwgRC4sIGFu ZCBJLiBKYWNvYnMsICJIVE1MIDQuMDEKICAgICAgICAgICAgICBTcGVjaWZpY2F0aW9uIiwgV29y bGQgV2lkZSBXZWIgQ29uc29ydGl1bQogICAgICAgICAgICAgIFJlY29tbWVuZGF0aW9uIFJFQy1o dG1sNDAxLTE5OTkxMjI0LCBEZWNlbWJlciAxOTk5LAogICAgICAgICAgICAgIDxodHRwOi8vd3d3 LnczLm9yZy9UUi8xOTk5L1JFQy1odG1sNDAxLTE5OTkxMjI0Pi4KCgoKSGFtbWVyLCBldCBhbC4g ICAgICAgICAgRXhwaXJlcyBEZWNlbWJlciAxMCwgMjAxMiAgICAgICAgICAgICAgW1BhZ2UgNjRd CgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICBPQXV0aCAyLjAgICAgICAgICAgICAg ICAgICAgICAgSnVuZSAyMDEyCgoKMTIuMi4gIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMKCiAgIFtJ LUQuZHJhZnQtaGFyZHQtb2F1dGgtMDFdCiAgICAgICAgICAgICAgSGFyZHQsIEQuLCBFZC4sIFRv bSwgQS4sIEVhdG9uLCBCLiwgYW5kIFkuIEdvbGFuZCwgIk9BdXRoCiAgICAgICAgICAgICAgV2Vi IFJlc291cmNlIEF1dGhvcml6YXRpb24gUHJvZmlsZXMiLCBKYW51YXJ5IDIwMTAuCgogICBbSS1E LmlldGYtaHR0cGJpcy1wNy1hdXRoXQogICAgICAgICAgICAgIEZpZWxkaW5nLCBSLiwgTGFmb24s IFkuLCBhbmQgSi4gUmVzY2hrZSwgIkhUVFAvMS4xLCBwYXJ0CiAgICAgICAgICAgICAgNzogQXV0 aGVudGljYXRpb24iLCBkcmFmdC1pZXRmLWh0dHBiaXMtcDctYXV0aC0xOSAod29yayBpbgogICAg ICAgICAgICAgIHByb2dyZXNzKSwgTWFyY2ggMjAxMi4KCiAgIFtJLUQuaWV0Zi1vYXV0aC1zYW1s Mi1iZWFyZXJdCiAgICAgICAgICAgICAgTW9ydGltb3JlLCBDLiwgIlNBTUwgMi4wIEJlYXJlciBB c3NlcnRpb24gUHJvZmlsZXMgZm9yCiAgICAgICAgICAgICAgT0F1dGggMi4wIiwgZHJhZnQtaWV0 Zi1vYXV0aC1zYW1sMi1iZWFyZXItMTIgKHdvcmsgaW4KICAgICAgICAgICAgICBwcm9ncmVzcyks IE1heSAyMDEyLgoKICAgW0ktRC5pZXRmLW9hdXRoLXYyLWJlYXJlcl0KICAgICAgICAgICAgICBK b25lcywgTS4sIEhhcmR0LCBELiwgYW5kIEQuIFJlY29yZG9uLCAiVGhlIE9BdXRoIDIuMAogICAg ICAgICAgICAgIEF1dGhvcml6YXRpb24gUHJvdG9jb2w6IEJlYXJlciBUb2tlbnMiLAogICAgICAg ICAgICAgIGRyYWZ0LWlldGYtb2F1dGgtdjItYmVhcmVyLTE5ICh3b3JrIGluIHByb2dyZXNzKSwK ICAgICAgICAgICAgICBBcHJpbCAyMDEyLgoKICAgW0ktRC5pZXRmLW9hdXRoLXYyLWh0dHAtbWFj XQogICAgICAgICAgICAgIEhhbW1lci1MYWhhdiwgRS4sICJIVFRQIEF1dGhlbnRpY2F0aW9uOiBN QUMgQWNjZXNzCiAgICAgICAgICAgICAgQXV0aGVudGljYXRpb24iLCBkcmFmdC1pZXRmLW9hdXRo LXYyLWh0dHAtbWFjLTAxICh3b3JrIGluCiAgICAgICAgICAgICAgcHJvZ3Jlc3MpLCBGZWJydWFy eSAyMDEyLgoKICAgW0ktRC5pZXRmLW9hdXRoLXYyLXRocmVhdG1vZGVsXQogICAgICAgICAgICAg IE1jR2xvaW4sIE0uLCBIdW50LCBQLiwgYW5kIFQuIExvZGRlcnN0ZWR0LCAiT0F1dGggMi4wCiAg ICAgICAgICAgICAgVGhyZWF0IE1vZGVsIGFuZCBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyIsCiAg ICAgICAgICAgICAgZHJhZnQtaWV0Zi1vYXV0aC12Mi10aHJlYXRtb2RlbC0wMiAod29yayBpbiBw cm9ncmVzcyksCiAgICAgICAgICAgICAgRmVicnVhcnkgMjAxMi4KCiAgIFtSRkM1ODQ5XSAgSGFt bWVyLUxhaGF2LCBFLiwgIlRoZSBPQXV0aCAxLjAgUHJvdG9jb2wiLCBSRkMgNTg0OSwKICAgICAg ICAgICAgICBBcHJpbCAyMDEwLgoKCkFwcGVuZGl4IEEuICBBdWdtZW50ZWQgQmFja3VzLU5hdXIg Rm9ybSAoQUJORikgU3ludGF4CgogICBUaGlzIHNlY3Rpb24gcHJvdmlkZXMgQXVnbWVudGVkIEJh Y2t1cy1OYXVyIEZvcm0gKEFCTkYpIHN5bnRheAogICBkZXNjcmlwdGlvbnMgZm9yIHRoZSBlbGVt ZW50cyBkZWZpbmVkIGluIHRoaXMgc3BlY2lmaWNhdGlvbiB1c2luZyB0aGUKICAgbm90YXRpb24g b2YgW1JGQzUyMzRdLiAgRWxlbWVudHMgYXJlIHByZXNlbnRlZCBpbiB0aGUgb3JkZXIgZmlyc3QK ICAgZGVmaW5lZC4KCiAgIFNvbWUgb2YgdGhlIGRlZmluaXRpb25zIHRoYXQgZm9sbG93IHVzZSB0 aGUgIlVSSS1yZWZlcmVuY2UiCiAgIGRlZmluaXRpb24gZnJvbSBbUkZDMzk4Nl0uCgoKCgoKSGFt bWVyLCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBEZWNlbWJlciAxMCwgMjAxMiAgICAgICAgICAg ICAgW1BhZ2UgNjVdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICBPQXV0aCAyLjAg ICAgICAgICAgICAgICAgICAgICAgSnVuZSAyMDEyCgoKICAgU29tZSBvZiB0aGUgZGVmaW5pdGlv bnMgdGhhdCBmb2xsb3cgdXNlIHRoZXNlIGNvbW1vbiBkZWZpbml0aW9uczoKCiAgIFZTQ0hBUiAg ICAgPSAlMjAtN0UKICAgTlFDSEFSICAgICA9ICV4MjEgLyAleDIzLTVCIC8gJXg1RC03RQogICBO UVNDSEFSICAgID0gJXgyMC0yMSAvICV4MjMtNUIgLyAleDVELTdFCgpBLjEuICAiY2xpZW50X2lk IiBTeW50YXgKCiAgIFRoZSAiY2xpZW50X2lkIiBlbGVtZW50IGlzIGRlZmluZWQgaW4gU2VjdGlv biAyLjMuMToKCiAgIGNsaWVudC1pZCAgICAgPSAqVlNDSEFSCgogICAoVGhpcyBtYXRjaGVzIHRo ZSAidXNlcmlkIiBkZWZpbml0aW9uIGluIHRoZSBIVFRQIEJhc2ljCiAgIEF1dGhlbnRpY2F0aW9u IFNjaGVtZSBbUkZDMjYxN10uKQoKQS4yLiAgImNsaWVudF9zZWNyZXQiIFN5bnRheAoKICAgVGhl ICJjbGllbnRfc2VjcmV0IiBlbGVtZW50IGlzIGRlZmluZWQgaW4gU2VjdGlvbiAyLjMuMToKCiAg IGNsaWVudC1zZWNyZXQgPSAqVlNDSEFSCgogICAoVGhpcyBtYXRjaGVzIHRoZSAicGFzc3dvcmQi IGRlZmluaXRpb24gaW4gdGhlIEhUVFAgQmFzaWMKICAgQXV0aGVudGljYXRpb24gU2NoZW1lIFtS RkMyNjE3XS4pCgpBLjMuICAicmVzcG9uc2VfdHlwZSIgU3ludGF4CgogICBUaGUgInJlc3BvbnNl X3R5cGUiIGVsZW1lbnQgaXMgZGVmaW5lZCBpbiBTZWN0aW9uIDMuMS4xIGFuZAogICBTZWN0aW9u IDguNDoKCiAgIHJlc3BvbnNlLXR5cGUgPSByZXNwb25zZS1uYW1lICooIFNQIHJlc3BvbnNlLW5h bWUgKQogICByZXNwb25zZS1uYW1lID0gMSpyZXNwb25zZS1jaGFyCiAgIHJlc3BvbnNlLWNoYXIg PSAiXyIgLyBESUdJVCAvIEFMUEhBCgpBLjQuICAic2NvcGUiIFN5bnRheAoKICAgVGhlICJzY29w ZSIgZWxlbWVudCBpcyBkZWZpbmVkIGluIFNlY3Rpb24gMy4zOgoKICAgc2NvcGUgICAgICAgPSBz Y29wZS10b2tlbiAqKCBTUCBzY29wZS10b2tlbiApCiAgIHNjb3BlLXRva2VuID0gMSpOUUNIQVIK CkEuNS4gICJzdGF0ZSIgU3ludGF4CgogICBUaGUgInN0YXRlIiBlbGVtZW50IGlzIGRlZmluZWQg aW4gU2VjdGlvbiA0LjEuMSwgU2VjdGlvbiA0LjEuMiwKICAgU2VjdGlvbiA0LjEuMi4xLCBTZWN0 aW9uIDQuMi4xLCBTZWN0aW9uIDQuMi4yLCBhbmQgU2VjdGlvbiA0LjIuMi4xOgoKICAgc3RhdGUg ICAgICA9IDEqVlNDSEFSCgoKCgoKSGFtbWVyLCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBEZWNl bWJlciAxMCwgMjAxMiAgICAgICAgICAgICAgW1BhZ2UgNjZdCgwKSW50ZXJuZXQtRHJhZnQgICAg ICAgICAgICAgICAgICBPQXV0aCAyLjAgICAgICAgICAgICAgICAgICAgICAgSnVuZSAyMDEyCgoK QS42LiAgInJlZGlyZWN0X3VyaSIgU3ludGF4CgogICBUaGUgInJlZGlyZWN0X3VyaSIgZWxlbWVu dCBpcyBkZWZpbmVkIGluIFNlY3Rpb24gNC4xLjEsCiAgIFNlY3Rpb24gNC4xLjMsIGFuZCBTZWN0 aW9uIDQuMi4xOgoKICAgcmVkaXJlY3QtdXJpICAgICAgPSBVUkktcmVmZXJlbmNlCgpBLjcuICAi ZXJyb3IiIFN5bnRheAoKICAgVGhlICJlcnJvciIgZWxlbWVudCBpcyBkZWZpbmVkIGluIFNlY3Rp b24gNC4xLjIuMSwgU2VjdGlvbiA0LjIuMi4xLAogICBTZWN0aW9uIDUuMiwgU2VjdGlvbiA3LjIs IGFuZCBTZWN0aW9uIDguNToKCiAgIGVycm9yICAgICAgICAgICAgID0gMSpOUVNDSEFSCgpBLjgu ICAiZXJyb3JfZGVzY3JpcHRpb24iIFN5bnRheAoKICAgVGhlICJlcnJvcl9kZXNjcmlwdGlvbiIg ZWxlbWVudCBpcyBkZWZpbmVkIGluIFNlY3Rpb24gNC4xLjIuMSwKICAgU2VjdGlvbiA0LjIuMi4x LCBTZWN0aW9uIDUuMiwgYW5kIFNlY3Rpb24gNy4yOgoKICAgZXJyb3ItZGVzY3JpcHRpb24gPSAx Kk5RU0NIQVIKCkEuOS4gICJlcnJvcl91cmkiIFN5bnRheAoKICAgVGhlICJlcnJvcl91cmkiIGVs ZW1lbnQgaXMgZGVmaW5lZCBpbiBTZWN0aW9uIDQuMS4yLjEsCiAgIFNlY3Rpb24gNC4yLjIuMSwg U2VjdGlvbiA1LjIsIGFuZCBTZWN0aW9uIDcuMjoKCiAgIGVycm9yLXVyaSAgICAgICAgID0gVVJJ LXJlZmVyZW5jZQoKQS4xMC4gICJncmFudF90eXBlIiBTeW50YXgKCiAgIFRoZSAiZ3JhbnRfdHlw ZSIgZWxlbWVudCBpcyBkZWZpbmVkIGluIFNlY3Rpb24gNC4xLjMsIFNlY3Rpb24gNC4zLjIsCiAg IFNlY3Rpb24gNC40LjIsIFNlY3Rpb24gNiwgYW5kIFNlY3Rpb24gNC41OgoKICAgZ3JhbnQtdHlw ZSA9IGdyYW50LW5hbWUgLyBVUkktcmVmZXJlbmNlCiAgIGdyYW50LW5hbWUgPSAxKm5hbWUtY2hh cgogICBuYW1lLWNoYXIgID0gIi0iIC8gIi4iIC8gIl8iIC8gRElHSVQgLyBBTFBIQQoKQS4xMS4g ICJjb2RlIiBTeW50YXgKCiAgIFRoZSAiY29kZSIgZWxlbWVudCBpcyBkZWZpbmVkIGluIFNlY3Rp b24gNC4xLjM6CgogICBjb2RlICAgICAgID0gMSpWU0NIQVIKCgoKCgoKCgoKSGFtbWVyLCBldCBh bC4gICAgICAgICAgRXhwaXJlcyBEZWNlbWJlciAxMCwgMjAxMiAgICAgICAgICAgICAgW1BhZ2Ug NjddCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICBPQXV0aCAyLjAgICAgICAgICAg ICAgICAgICAgICAgSnVuZSAyMDEyCgoKQS4xMi4gICJhY2Nlc3NfdG9rZW4iIFN5bnRheAoKICAg VGhlICJhY2Nlc3NfdG9rZW4iIGVsZW1lbnQgaXMgZGVmaW5lZCBpbiBTZWN0aW9uIDQuMi4yIGFu ZAogICBTZWN0aW9uIDUuMToKCiAgIGFjY2Vzcy10b2tlbiA9IDEqVlNDSEFSCgpBLjEzLiAgInRv a2VuX3R5cGUiIFN5bnRheAoKICAgVGhlICJ0b2tlbl90eXBlIiBlbGVtZW50IGlzIGRlZmluZWQg aW4gU2VjdGlvbiA0LjIuMiwgU2VjdGlvbiA1LjEsCiAgIGFuZCBTZWN0aW9uIDguMToKCiAgIHRv a2VuLXR5cGUgPSB0eXBlLW5hbWUgLyBVUkktcmVmZXJlbmNlCiAgIHR5cGUtbmFtZSAgPSAxKm5h bWUtY2hhcgogICBuYW1lLWNoYXIgID0gIi0iIC8gIi4iIC8gIl8iIC8gRElHSVQgLyBBTFBIQQoK QS4xNC4gICJleHBpcmVzX2luIiBTeW50YXgKCiAgIFRoZSAiZXhwaXJlc19pbiIgZWxlbWVudCBp cyBkZWZpbmVkIGluIFNlY3Rpb24gNC4yLjIgYW5kIFNlY3Rpb24gNS4xOgoKICAgZXhwaXJlcy1p biA9IDEqRElHSVQKCkEuMTUuICAidXNlcm5hbWUiIFN5bnRheAoKICAgVGhlICJ1c2VybmFtZSIg ZWxlbWVudCBpcyBkZWZpbmVkIGluIFNlY3Rpb24gNC4zLjI6CgogICB1c2VybmFtZSA9ICooICV4 MjAtMzkgLyAleDNCLTdFICkKCiAgIChUaGlzIGFsbG93ZWQgY2hhcmFjdGVyIHNldCBpcyBWU0NI QVIgZXhjbHVkaW5nICI6Ii4gIFRoaXMgaXMKICAgY29tcGF0aWJsZSB3aXRoIHRoZSAidXNlcmlk IiBkZWZpbml0aW9uIGluIHRoZSBIVFRQIEJhc2ljCiAgIEF1dGhlbnRpY2F0aW9uIFNjaGVtZSBb UkZDMjYxN10uKQoKQS4xNi4gICJwYXNzd29yZCIgU3ludGF4CgogICBUaGUgInBhc3N3b3JkIiBl bGVtZW50IGlzIGRlZmluZWQgaW4gU2VjdGlvbiA0LjMuMjoKCiAgIHBhc3N3b3JkID0gKlZTQ0hB UgoKICAgKFRoaXMgbWF0Y2hlcyB0aGUgInBhc3N3b3JkIiBkZWZpbml0aW9uIGluIHRoZSBIVFRQ IEJhc2ljCiAgIEF1dGhlbnRpY2F0aW9uIFNjaGVtZSBbUkZDMjYxN10uKQoKQS4xNy4gICJyZWZy ZXNoX3Rva2VuIiBTeW50YXgKCiAgIFRoZSAicmVmcmVzaF90b2tlbiIgZWxlbWVudCBpcyBkZWZp bmVkIGluIFNlY3Rpb24gNS4xIGFuZCBTZWN0aW9uIDY6CgogICByZWZyZXNoLXRva2VuID0gMSpW U0NIQVIKCgoKCgpIYW1tZXIsIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIERlY2VtYmVyIDEwLCAy MDEyICAgICAgICAgICAgICBbUGFnZSA2OF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAg ICAgIE9BdXRoIDIuMCAgICAgICAgICAgICAgICAgICAgICBKdW5lIDIwMTIKCgpBLjE4LiAgRW5k cG9pbnQgUGFyYW1ldGVyIFN5bnRheAoKICAgVGhlIHN5bnRheCBmb3IgbmV3IGVuZHBvaW50IHBh cmFtZXRlcnMgaXMgZGVmaW5lZCBpbiBTZWN0aW9uIDguMjoKCiAgIHBhcmFtLW5hbWUgPSAxKm5h bWUtY2hhcgogICBuYW1lLWNoYXIgID0gIi0iIC8gIi4iIC8gIl8iIC8gRElHSVQgLyBBTFBIQQoK CkFwcGVuZGl4IEIuICBBY2tub3dsZWRnZW1lbnRzCgogICBUaGUgaW5pdGlhbCBPQXV0aCAyLjAg cHJvdG9jb2wgc3BlY2lmaWNhdGlvbiB3YXMgZWRpdGVkIGJ5IERhdmlkCiAgIFJlY29yZG9uLCBi YXNlZCBvbiB0d28gcHJldmlvdXMgcHVibGljYXRpb25zOiB0aGUgT0F1dGggMS4wIGNvbW11bml0 eQogICBzcGVjaWZpY2F0aW9uIFtSRkM1ODQ5XSwgYW5kIE9BdXRoIFdSQVAgKE9BdXRoIFdlYiBS ZXNvdXJjZQogICBBdXRob3JpemF0aW9uIFByb2ZpbGVzKSBbSS1ELmRyYWZ0LWhhcmR0LW9hdXRo LTAxXS4gIFRoZSBTZWN1cml0eQogICBDb25zaWRlcmF0aW9ucyBzZWN0aW9uIHdhcyBkcmFmdGVk IGJ5IFRvcnN0ZW4gTG9kZGVyc3RlZHQsIE1hcmsKICAgTWNHbG9pbiwgUGhpbCBIdW50LCBhbmQg QW50aG9ueSBOYWRhbGluLiAgVGhlIEFCTkYgc2VjdGlvbiB3YXMKICAgZHJhZnRlZCBieSBNaWNo YWVsIEIuIEpvbmVzLgoKICAgVGhlIE9BdXRoIDEuMCBjb21tdW5pdHkgc3BlY2lmaWNhdGlvbiB3 YXMgZWRpdGVkIGJ5IEVyYW4gSGFtbWVyIGFuZAogICBhdXRob3JlZCBieSBNYXJrIEF0d29vZCwg RGlyayBCYWxmYW56LCBEYXJyZW4gQm91bmRzLCBSaWNoYXJkIE0uCiAgIENvbmxhbiwgQmxhaW5l IENvb2ssIExlYWggQ3VsdmVyLCBCcmVubyBkZSBNZWRlaXJvcywgQnJpYW4gRWF0b24sCiAgIEtl bGxhbiBFbGxpb3R0LU1jQ3JlYSwgTGFycnkgSGFsZmYsIEVyYW4gSGFtbWVyLCBCZW4gTGF1cmll LCBDaHJpcwogICBNZXNzaW5hLCBKb2huIFBhbnplciwgU2FtIFF1aWdsZXksIERhdmlkIFJlY29y ZG9uLCBFcmFuIFNhbmRsZXIsCiAgIEpvbmF0aGFuIFNlcmdlbnQsIFRvZGQgU2llbGluZywgQnJp YW4gU2xlc2luc2t5LCBhbmQgQW5keSBTbWl0aC4KCiAgIFRoZSBPQXV0aCBXUkFQIHNwZWNpZmlj YXRpb24gd2FzIGVkaXRlZCBieSBEaWNrIEhhcmR0IGFuZCBhdXRob3JlZCBieQogICBCcmlhbiBF YXRvbiwgWWFyb24gWS4gR29sYW5kLCBEaWNrIEhhcmR0LCBhbmQgQWxsZW4gVG9tLgoKICAgVGhp cyBzcGVjaWZpY2F0aW9uIGlzIHRoZSB3b3JrIG9mIHRoZSBPQXV0aCBXb3JraW5nIEdyb3VwIHdo aWNoCiAgIGluY2x1ZGVzIGRvemVucyBvZiBhY3RpdmUgYW5kIGRlZGljYXRlZCBwYXJ0aWNpcGFu dHMuICBJbiBwYXJ0aWN1bGFyLAogICB0aGUgZm9sbG93aW5nIGluZGl2aWR1YWxzIGNvbnRyaWJ1 dGVkIGlkZWFzLCBmZWVkYmFjaywgYW5kIHdvcmRpbmcKICAgd2hpY2ggc2hhcGVkIGFuZCBmb3Jt ZWQgdGhlIGZpbmFsIHNwZWNpZmljYXRpb246CgogICBNaWNoYWVsIEFkYW1zLCBBbWFuZGEgQW5n YW5lcywgQW5kcmV3IEFybm90dCwgRGlyayBCYWxmYW56LCBBaWRlbgogICBCZWxsLCBKb2huIEJy YWRsZXksIEJyaWFuIENhbXBiZWxsLCBTY290dCBDYW50b3IsIE1hcmNvcyBDYWNlcmVzLAogICBC bGFpbmUgQ29vaywgUm9nZXIgQ3JldywgQnJpYW4gRWF0b24sIFdlc2xleSBFZGR5LCBMZWFoIEN1 bHZlciwgQmlsbAogICBkZSBoT3JhLCBBbmRyZSBEZU1hcnJlLCBCcmlhbiBFYXRvbiwgV29sdGVy IEVsZGVyaW5nLCBCcmlhbiBFbGxpbiwKICAgSWdvciBGYXluYmVyZywgR2VvcmdlIEZsZXRjaGVy LCBUaW0gRnJlZW1hbiwgTHVjYSBGcm9zaW5pLCBFdmFuCiAgIEdpbGJlcnQsIFlhcm9uIFkuIEdv bGFuZCwgQnJlbnQgR29sZG1hbiwgS3Jpc3RvZmZlciBHcm9ub3dza2ksIEp1c3RpbgogICBIYXJ0 LCBEaWNrIEhhcmR0LCBDcmFpZyBIZWF0aCwgUGhpbCBIdW50LCBNaWNoYWVsIEIuIEpvbmVzLCBU ZXJyeQogICBKb25lcywgSm9obiBLZW1wLCBNYXJrIEtlbnQsIFJhZmZpIEtyaWtvcmlhbiwgQ2hh c2VuIExlIEhhcmEsIFJhc211cwogICBMZXJkb3JmLCBUb3JzdGVuIExvZGRlcnN0ZWR0LCBIdWkt TGFuIEx1LCBDYXNleSBMdWNhcywgUGF1bCBNYWRzZW4sCiAgIEFsYXN0YWlyIE1haXIsIEV2ZSBN YWxlciwgSmFtZXMgTWFuZ2VyLCBNYXJrIE1jR2xvaW4sIExhdXJlbmNlIE1pYW8sCiAgIFdpbGxp YW0gTWlsbHMsIENodWNrIE1vcnRpbW9yZSwgQW50aG9ueSBOYWRhbGluLCBKdWxpYW4gUmVzY2hr ZSwKICAgSnVzdGluIFJpY2hlciwgUGV0ZXIgU2FpbnQtQW5kcmUsIE5hdCBTYWtpbXVyYSwgUm9i IFNheXJlLCBNYXJpdXMKICAgU2N1cnRlc2N1LCBOYWl0aWsgU2hhaCwgTHVrZSBTaGVwYXJkLCBW bGFkIFNrdm9ydHNvdiwgSnVzdGluIFNtaXRoLAogICBIYWliaW4gU29uZywgTml2IFN0ZWluZ2Fy dGVuLCBDaHJpc3RpYW4gU3R1Ym5lciwgSmVyZW15IFN1cmllbCwgUGF1bAogICBUYXJqYW4sIENo cmlzdG9waGVyIFRob21hcywgSGVucnkgUy4gVGhvbXBzb24sIEFsbGVuIFRvbSwgRnJhbmtsaW4K CgoKSGFtbWVyLCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBEZWNlbWJlciAxMCwgMjAxMiAgICAg ICAgICAgICAgW1BhZ2UgNjldCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICBPQXV0 aCAyLjAgICAgICAgICAgICAgICAgICAgICAgSnVuZSAyMDEyCgoKICAgVHNlLCBOaWNrIFdhbGtl ciwgU2hhbmUgV2VlZGVuLCBhbmQgU2t5bGFyIFdvb2R3YXJkLgoKICAgVGhpcyBkb2N1bWVudCB3 YXMgcHJvZHVjZWQgdW5kZXIgdGhlIGNoYWlybWFuc2hpcCBvZiBCbGFpbmUgQ29vaywKICAgUGV0 ZXIgU2FpbnQtQW5kcmUsIEhhbm5lcyBUc2Nob2ZlbmlnLCBCYXJyeSBMZWliYSwgYW5kIERlcmVr IEF0a2lucy4KICAgVGhlIGFyZWEgZGlyZWN0b3JzIGluY2x1ZGVkIExpc2EgRHVzc2VhdWx0LCBQ ZXRlciBTYWludC1BbmRyZSwgYW5kCiAgIFN0ZXBoZW4gRmFycmVsbC4KCgpBcHBlbmRpeCBDLiAg RWRpdG9yJ3MgTm90ZXMKCiAgIFdoaWxlIG1hbnkgcGVvcGxlIGNvbnRyaWJ1dGVkIHRvIHRoaXMg c3BlY2lmaWNhdGlvbiB0aHJvdWdob3V0IGl0cwogICBsb25nIGpvdXJuZXksIHRoZSBlZGl0b3Ig d291bGQgbGlrZSB0byBhY2tub3dsZWRnZSBhbmQgdGhhbmsgYSBmZXcKICAgaW5kaXZpZHVhbHMg Zm9yIHRoZWlyIG91dHN0YW5kaW5nIGFuZCBpbnZhbHVhYmxlIGVmZm9ydHMgbGVhZGluZyB1cAog ICB0byB0aGUgcHVibGljYXRpb24gb2YgdGhpcyBzcGVjaWZpY2F0aW9uLgoKICAgRGF2aWQgUmVj b3Jkb24gZm9yIGNvbnRpbnVvdXNseSBiZWluZyBvbmUgb2YgT0F1dGgncyBtb3N0IHZhbHVhYmxl CiAgIGFzc2V0cywgYnJpbmdpbmcgcHJhZ21hdGlzbSBhbmQgdXJnZW5jeSB0byB0aGUgd29yaywg YW5kIGhlbHBpbmcKICAgc2hhcGUgaXQgZnJvbSBpdHMgdmVyeSBiZWdpbm5pbmcsIGFzIHdlbGwg YXMgYmVpbmcgb25lIG9mIHRoZSBiZXN0CiAgIGNvbGxhYm9yYXRvcnMgSSBoYWQgdGhlIHBsZWFz dXJlIG9mIHdvcmtpbmcgd2l0aC4KCiAgIEphbWVzIE1hbmdlciBmb3IgaGlzIGNyZWF0aXZlIGlk ZWFzIGFuZCBhbHdheXMgaW5zaWdodGZ1bCBmZWVkYmFjay4KICAgQnJpYW4gQ2FtcGJlbGwsIFRv cnN0ZW4gTG9kZGVyc3RlZHQsIENodWNrIE1vcnRpbW9yZSwgSnVzdGluIFJpY2hlciwKICAgTWFy aXVzIFNjdXJ0ZXNjdSwgYW5kIEx1a2UgU2hlcGFyZCBmb3IgdGhlaXIgY29udGludWVkIHBhcnRp Y2lwYXRpb24KICAgYW5kIHZhbHVhYmxlIGZlZWRiYWNrLgoKICAgU3BlY2lhbCB0aGFua3MgZ29l cyB0byBNaWtlIEN1cnRpcyBhbmQgWWFob28hIGZvciB0aGVpciB1bmNvbmRpdGlvbmFsCiAgIHN1 cHBvcnQgb2YgdGhpcyB3b3JrIGZvciBvdmVyIHRocmVlIHllYXJzLgoKCkF1dGhvcnMnIEFkZHJl c3NlcwoKICAgRXJhbiBIYW1tZXIgKGVkaXRvcikKCiAgIEVtYWlsOiBlcmFuQGh1ZW5pdmVyc2Uu Y29tCiAgIFVSSTogICBodHRwOi8vaHVlbml2ZXJzZS5jb20KCgogICBEYXZpZCBSZWNvcmRvbgog ICBGYWNlYm9vawoKICAgRW1haWw6IGRyQGZiLmNvbQogICBVUkk6ICAgaHR0cDovL3d3dy5kYXZp ZHJlY29yZG9uLmNvbS8KCgoKCgoKCgoKSGFtbWVyLCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBE ZWNlbWJlciAxMCwgMjAxMiAgICAgICAgICAgICAgW1BhZ2UgNzBdCgwKSW50ZXJuZXQtRHJhZnQg ICAgICAgICAgICAgICAgICBPQXV0aCAyLjAgICAgICAgICAgICAgICAgICAgICAgSnVuZSAyMDEy CgoKICAgRGljayBIYXJkdAogICBNaWNyb3NvZnQKCiAgIEVtYWlsOiBkaWNrLmhhcmR0QGdtYWls LmNvbQogICBVUkk6ICAgaHR0cDovL2RpY2toYXJkdC5vcmcvCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgpIYW1tZXIsIGV0IGFsLiAgICAgICAgICBFeHBpcmVz IERlY2VtYmVyIDEwLCAyMDEyICAgICAgICAgICAgICBbUGFnZSA3MV0KDAo= --_006_4E1F6AAD24975D4BA5B16804296739436652EBF0TK5EX14MBXC284r_ Content-Type: text/html; name="draft-ietf-oauth-v2-26+mbj-4.html" Content-Description: draft-ietf-oauth-v2-26+mbj-4.html Content-Disposition: attachment; filename="draft-ietf-oauth-v2-26+mbj-4.html"; size=255292; creation-date="Fri, 08 Jun 2012 07:48:20 GMT"; modification-date="Fri, 08 Jun 2012 07:48:20 GMT" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMDEgVHJhbnNpdGlvbmFs Ly9FTiIgImh0dHA6Ly93d3cudzMub3JnL1RSL2h0bWw0L2xvb3NlLmR0ZCI+CjxodG1sIGxhbmc9 ImVuIj48aGVhZD48dGl0bGU+VGhlIE9BdXRoIDIuMCBBdXRob3JpemF0aW9uIEZyYW1ld29yazwv dGl0bGU+CjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9odG1s OyBjaGFyc2V0PXV0Zi04Ij4KPG1ldGEgbmFtZT0iZGVzY3JpcHRpb24iIGNvbnRlbnQ9IlRoZSBP QXV0aCAyLjAgQXV0aG9yaXphdGlvbiBGcmFtZXdvcmsiPgo8bWV0YSBuYW1lPSJnZW5lcmF0b3Ii IGNvbnRlbnQ9InhtbDJyZmMgdjEuMzYgKGh0dHA6Ly94bWwucmVzb3VyY2Uub3JnLykiPgo8c3R5 bGUgdHlwZT0ndGV4dC9jc3MnPjwhLS0KICAgICAgICBib2R5IHsKICAgICAgICAgICAgICAgIGZv bnQtZmFtaWx5OiB2ZXJkYW5hLCBjaGFyY29hbCwgaGVsdmV0aWNhLCBhcmlhbCwgc2Fucy1zZXJp ZjsKICAgICAgICAgICAgICAgIGZvbnQtc2l6ZTogc21hbGw7IGNvbG9yOiAjMDAwOyBiYWNrZ3Jv dW5kLWNvbG9yOiAjRkZGOwogICAgICAgICAgICAgICAgbWFyZ2luOiAyZW07CiAgICAgICAgfQog ICAgICAgIGgxLCBoMiwgaDMsIGg0LCBoNSwgaDYgewogICAgICAgICAgICAgICAgZm9udC1mYW1p bHk6IGhlbHZldGljYSwgbW9uYWNvLCAiTVMgU2FucyBTZXJpZiIsIGFyaWFsLCBzYW5zLXNlcmlm OwogICAgICAgICAgICAgICAgZm9udC13ZWlnaHQ6IGJvbGQ7IGZvbnQtc3R5bGU6IG5vcm1hbDsK ICAgICAgICB9CiAgICAgICAgaDEgeyBjb2xvcjogIzkwMDsgYmFja2dyb3VuZC1jb2xvcjogdHJh bnNwYXJlbnQ7IHRleHQtYWxpZ246IHJpZ2h0OyB9CiAgICAgICAgaDMgeyBjb2xvcjogIzMzMzsg YmFja2dyb3VuZC1jb2xvcjogdHJhbnNwYXJlbnQ7IH0KCiAgICAgICAgdGQuUkZDYnVnIHsKICAg ICAgICAgICAgICAgIGZvbnQtc2l6ZTogeC1zbWFsbDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOwog ICAgICAgICAgICAgICAgd2lkdGg6IDMwcHg7IGhlaWdodDogMzBweDsgcGFkZGluZy10b3A6IDJw eDsKICAgICAgICAgICAgICAgIHRleHQtYWxpZ246IGp1c3RpZnk7IHZlcnRpY2FsLWFsaWduOiBt aWRkbGU7CiAgICAgICAgICAgICAgICBiYWNrZ3JvdW5kLWNvbG9yOiAjMDAwOwogICAgICAgIH0K ICAgICAgICB0ZC5SRkNidWcgc3Bhbi5SRkMgewogICAgICAgICAgICAgICAgZm9udC1mYW1pbHk6 IG1vbmFjbywgY2hhcmNvYWwsIGdlbmV2YSwgIk1TIFNhbnMgU2VyaWYiLCBoZWx2ZXRpY2EsIHZl cmRhbmEsIHNhbnMtc2VyaWY7CiAgICAgICAgICAgICAgICBmb250LXdlaWdodDogYm9sZDsgY29s b3I6ICM2NjY7CiAgICAgICAgfQogICAgICAgIHRkLlJGQ2J1ZyBzcGFuLmhvdFRleHQgewogICAg ICAgICAgICAgICAgZm9udC1mYW1pbHk6IGNoYXJjb2FsLCBtb25hY28sIGdlbmV2YSwgIk1TIFNh bnMgU2VyaWYiLCBoZWx2ZXRpY2EsIHZlcmRhbmEsIHNhbnMtc2VyaWY7CiAgICAgICAgICAgICAg ICBmb250LXdlaWdodDogbm9ybWFsOyB0ZXh0LWFsaWduOiBjZW50ZXI7IGNvbG9yOiAjRkZGOwog ICAgICAgIH0KCiAgICAgICAgdGFibGUuVE9DYnVnIHsgd2lkdGg6IDMwcHg7IGhlaWdodDogMTVw eDsgfQogICAgICAgIHRkLlRPQ2J1ZyB7CiAgICAgICAgICAgICAgICB0ZXh0LWFsaWduOiBjZW50 ZXI7IHdpZHRoOiAzMHB4OyBoZWlnaHQ6IDE1cHg7CiAgICAgICAgICAgICAgICBjb2xvcjogI0ZG RjsgYmFja2dyb3VuZC1jb2xvcjogIzkwMDsKICAgICAgICB9CiAgICAgICAgdGQuVE9DYnVnIGEg ewogICAgICAgICAgICAgICAgZm9udC1mYW1pbHk6IG1vbmFjbywgY2hhcmNvYWwsIGdlbmV2YSwg Ik1TIFNhbnMgU2VyaWYiLCBoZWx2ZXRpY2EsIHNhbnMtc2VyaWY7CiAgICAgICAgICAgICAgICBm b250LXdlaWdodDogYm9sZDsgZm9udC1zaXplOiB4LXNtYWxsOyB0ZXh0LWRlY29yYXRpb246IG5v bmU7CiAgICAgICAgICAgICAgICBjb2xvcjogI0ZGRjsgYmFja2dyb3VuZC1jb2xvcjogdHJhbnNw YXJlbnQ7CiAgICAgICAgfQoKICAgICAgICB0ZC5oZWFkZXIgewogICAgICAgICAgICAgICAgZm9u dC1mYW1pbHk6IGFyaWFsLCBoZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogeC1zbWFs bDsKICAgICAgICAgICAgICAgIHZlcnRpY2FsLWFsaWduOiB0b3A7IHdpZHRoOiAzMyU7CiAgICAg ICAgICAgICAgICBjb2xvcjogI0ZGRjsgYmFja2dyb3VuZC1jb2xvcjogIzY2NjsKICAgICAgICB9 CiAgICAgICAgdGQuYXV0aG9yIHsgZm9udC13ZWlnaHQ6IGJvbGQ7IGZvbnQtc2l6ZTogeC1zbWFs bDsgbWFyZ2luLWxlZnQ6IDRlbTsgfQogICAgICAgIHRkLmF1dGhvci10ZXh0IHsgZm9udC1zaXpl OiB4LXNtYWxsOyB9CgogICAgICAgIC8qIGluZm8gY29kZSBmcm9tIFNhbnRhS2xhdXNzIGF0IGh0 dHA6Ly93d3cubWFkYWJvdXRzdHlsZS5jb20vdG9vbHRpcDIuaHRtbCAqLwogICAgICAgIGEuaW5m byB7CiAgICAgICAgICAgICAgICAvKiBUaGlzIGlzIHRoZSBrZXkuICovCiAgICAgICAgICAgICAg ICBwb3NpdGlvbjogcmVsYXRpdmU7CiAgICAgICAgICAgICAgICB6LWluZGV4OiAyNDsKICAgICAg ICAgICAgICAgIHRleHQtZGVjb3JhdGlvbjogbm9uZTsKICAgICAgICB9CiAgICAgICAgYS5pbmZv OmhvdmVyIHsKICAgICAgICAgICAgICAgIHotaW5kZXg6IDI1OwogICAgICAgICAgICAgICAgY29s b3I6ICNGRkY7IGJhY2tncm91bmQtY29sb3I6ICM5MDA7CiAgICAgICAgfQogICAgICAgIGEuaW5m byBzcGFuIHsgZGlzcGxheTogbm9uZTsgfQogICAgICAgIGEuaW5mbzpob3ZlciBzcGFuLmluZm8g ewogICAgICAgICAgICAgICAgLyogVGhlIHNwYW4gd2lsbCBkaXNwbGF5IGp1c3Qgb24gOmhvdmVy IHN0YXRlLiAqLwogICAgICAgICAgICAgICAgZGlzcGxheTogYmxvY2s7CiAgICAgICAgICAgICAg ICBwb3NpdGlvbjogYWJzb2x1dGU7CiAgICAgICAgICAgICAgICBmb250LXNpemU6IHNtYWxsZXI7 CiAgICAgICAgICAgICAgICB0b3A6IDJlbTsgbGVmdDogLTVlbTsgd2lkdGg6IDE1ZW07CiAgICAg ICAgICAgICAgICBwYWRkaW5nOiAycHg7IGJvcmRlcjogMXB4IHNvbGlkICMzMzM7CiAgICAgICAg ICAgICAgICBjb2xvcjogIzkwMDsgYmFja2dyb3VuZC1jb2xvcjogI0VFRTsKICAgICAgICAgICAg ICAgIHRleHQtYWxpZ246IGxlZnQ7CiAgICAgICAgfQoKICAgICAgICBhIHsgZm9udC13ZWlnaHQ6 IGJvbGQ7IH0KICAgICAgICBhOmxpbmsgICAgeyBjb2xvcjogIzkwMDsgYmFja2dyb3VuZC1jb2xv cjogdHJhbnNwYXJlbnQ7IH0KICAgICAgICBhOnZpc2l0ZWQgeyBjb2xvcjogIzYzMzsgYmFja2dy b3VuZC1jb2xvcjogdHJhbnNwYXJlbnQ7IH0KICAgICAgICBhOmFjdGl2ZSAgeyBjb2xvcjogIzYz MzsgYmFja2dyb3VuZC1jb2xvcjogdHJhbnNwYXJlbnQ7IH0KCiAgICAgICAgcCB7IG1hcmdpbi1s ZWZ0OiAyZW07IG1hcmdpbi1yaWdodDogMmVtOyB9CiAgICAgICAgcC5jb3B5cmlnaHQgeyBmb250 LXNpemU6IHgtc21hbGw7IH0KICAgICAgICBwLnRvYyB7IGZvbnQtc2l6ZTogc21hbGw7IGZvbnQt d2VpZ2h0OiBib2xkOyBtYXJnaW4tbGVmdDogM2VtOyB9CiAgICAgICAgdGFibGUudG9jIHsgbWFy Z2luOiAwIDAgMCAzZW07IHBhZGRpbmc6IDA7IGJvcmRlcjogMDsgdmVydGljYWwtYWxpZ246IHRl eHQtdG9wOyB9CiAgICAgICAgdGQudG9jIHsgZm9udC1zaXplOiBzbWFsbDsgZm9udC13ZWlnaHQ6 IGJvbGQ7IHZlcnRpY2FsLWFsaWduOiB0ZXh0LXRvcDsgfQoKICAgICAgICBvbC50ZXh0IHsgbWFy Z2luLWxlZnQ6IDJlbTsgbWFyZ2luLXJpZ2h0OiAyZW07IH0KICAgICAgICB1bC50ZXh0IHsgbWFy Z2luLWxlZnQ6IDJlbTsgbWFyZ2luLXJpZ2h0OiAyZW07IH0KICAgICAgICBsaSAgICAgIHsgbWFy Z2luLWxlZnQ6IDNlbTsgfQoKICAgICAgICAvKiBSRkMtMjYyOSA8c3Bhbng+cyBhbmQgPGFydHdv cms+cy4gKi8KICAgICAgICBlbSAgICAgeyBmb250LXN0eWxlOiBpdGFsaWM7IH0KICAgICAgICBz dHJvbmcgeyBmb250LXdlaWdodDogYm9sZDsgfQogICAgICAgIGRmbiAgICB7IGZvbnQtd2VpZ2h0 OiBib2xkOyBmb250LXN0eWxlOiBub3JtYWw7IH0KICAgICAgICBjaXRlICAgeyBmb250LXdlaWdo dDogbm9ybWFsOyBmb250LXN0eWxlOiBub3JtYWw7IH0KICAgICAgICB0dCAgICAgeyBjb2xvcjog IzAzNjsgfQogICAgICAgIHR0LCBwcmUsIHByZSBkZm4sIHByZSBlbSwgcHJlIGNpdGUsIHByZSBz cGFuIHsKICAgICAgICAgICAgICAgIGZvbnQtZmFtaWx5OiAiQ291cmllciBOZXciLCBDb3VyaWVy LCBtb25vc3BhY2U7IGZvbnQtc2l6ZTogc21hbGw7CiAgICAgICAgfQogICAgICAgIHByZSB7CiAg ICAgICAgICAgICAgICB0ZXh0LWFsaWduOiBsZWZ0OyBwYWRkaW5nOiA0cHg7CiAgICAgICAgICAg ICAgICBjb2xvcjogIzAwMDsgYmFja2dyb3VuZC1jb2xvcjogI0NDQzsKICAgICAgICB9CiAgICAg ICAgcHJlIGRmbiAgeyBjb2xvcjogIzkwMDsgfQogICAgICAgIHByZSBlbSAgIHsgY29sb3I6ICM2 NkY7IGJhY2tncm91bmQtY29sb3I6ICNGRkM7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IH0KICAgICAg ICBwcmUgLmtleSB7IGNvbG9yOiAjMzNDOyBmb250LXdlaWdodDogYm9sZDsgfQogICAgICAgIHBy ZSAuaWQgIHsgY29sb3I6ICM5MDA7IH0KICAgICAgICBwcmUgLnN0ciB7IGNvbG9yOiAjMDAwOyBi YWNrZ3JvdW5kLWNvbG9yOiAjQ0ZGOyB9CiAgICAgICAgcHJlIC52YWwgeyBjb2xvcjogIzA2Njsg fQogICAgICAgIHByZSAucmVwIHsgY29sb3I6ICM5MDk7IH0KICAgICAgICBwcmUgLm90aCB7IGNv bG9yOiAjMDAwOyBiYWNrZ3JvdW5kLWNvbG9yOiAjRkNGOyB9CiAgICAgICAgcHJlIC5lcnIgeyBi YWNrZ3JvdW5kLWNvbG9yOiAjRkNDOyB9CgogICAgICAgIC8qIFJGQy0yNjI5IDx0ZXh0dGFibGU+ cy4gKi8KICAgICAgICB0YWJsZS5hbGwsIHRhYmxlLmZ1bGwsIHRhYmxlLmhlYWRlcnMsIHRhYmxl Lm5vbmUgewogICAgICAgICAgICAgICAgZm9udC1zaXplOiBzbWFsbDsgdGV4dC1hbGlnbjogY2Vu dGVyOyBib3JkZXItd2lkdGg6IDJweDsKICAgICAgICAgICAgICAgIHZlcnRpY2FsLWFsaWduOiB0 b3A7IGJvcmRlci1jb2xsYXBzZTogY29sbGFwc2U7CiAgICAgICAgfQogICAgICAgIHRhYmxlLmFs bCwgdGFibGUuZnVsbCB7IGJvcmRlci1zdHlsZTogc29saWQ7IGJvcmRlci1jb2xvcjogYmxhY2s7 IH0KICAgICAgICB0YWJsZS5oZWFkZXJzLCB0YWJsZS5ub25lIHsgYm9yZGVyLXN0eWxlOiBub25l OyB9CiAgICAgICAgdGggewogICAgICAgICAgICAgICAgZm9udC13ZWlnaHQ6IGJvbGQ7IGJvcmRl ci1jb2xvcjogYmxhY2s7CiAgICAgICAgICAgICAgICBib3JkZXItd2lkdGg6IDJweCAycHggM3B4 IDJweDsKICAgICAgICB9CiAgICAgICAgdGFibGUuYWxsIHRoLCB0YWJsZS5mdWxsIHRoIHsgYm9y ZGVyLXN0eWxlOiBzb2xpZDsgfQogICAgICAgIHRhYmxlLmhlYWRlcnMgdGggeyBib3JkZXItc3R5 bGU6IG5vbmUgbm9uZSBzb2xpZCBub25lOyB9CiAgICAgICAgdGFibGUubm9uZSB0aCB7IGJvcmRl ci1zdHlsZTogbm9uZTsgfQogICAgICAgIHRhYmxlLmFsbCB0ZCB7CiAgICAgICAgICAgICAgICBi b3JkZXItc3R5bGU6IHNvbGlkOyBib3JkZXItY29sb3I6ICMzMzM7CiAgICAgICAgICAgICAgICBi b3JkZXItd2lkdGg6IDFweCAycHg7CiAgICAgICAgfQogICAgICAgIHRhYmxlLmZ1bGwgdGQsIHRh YmxlLmhlYWRlcnMgdGQsIHRhYmxlLm5vbmUgdGQgeyBib3JkZXItc3R5bGU6IG5vbmU7IH0KCiAg ICAgICAgaHIgeyBoZWlnaHQ6IDFweDsgfQogICAgICAgIGhyLmluc2VydCB7CiAgICAgICAgICAg ICAgICB3aWR0aDogODAlOyBib3JkZXItc3R5bGU6IG5vbmU7IGJvcmRlci13aWR0aDogMDsKICAg ICAgICAgICAgICAgIGNvbG9yOiAjQ0NDOyBiYWNrZ3JvdW5kLWNvbG9yOiAjQ0NDOwogICAgICAg IH0KLS0+PC9zdHlsZT4KPC9oZWFkPgo8Ym9keT4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2Vs bHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQi Pjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9h PjwvdGQ+PC90cj48L3RhYmxlPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiB3aWR0aD0iNjYlIiBi b3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMCI+PHRyPjx0ZD48dGFibGUg c3VtbWFyeT0ibGF5b3V0IiB3aWR0aD0iMTAwJSIgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMiIg Y2VsbHNwYWNpbmc9IjEiPgo8dHI+PHRkIGNsYXNzPSJoZWFkZXIiPk9BdXRoIFdvcmtpbmcgR3Jv dXA8L3RkPjx0ZCBjbGFzcz0iaGVhZGVyIj5FLiBIYW1tZXIsIEVkLjwvdGQ+PC90cj4KPHRyPjx0 ZCBjbGFzcz0iaGVhZGVyIj5JbnRlcm5ldC1EcmFmdDwvdGQ+PHRkIGNsYXNzPSJoZWFkZXIiPiZu YnNwOzwvdGQ+PC90cj4KPHRyPjx0ZCBjbGFzcz0iaGVhZGVyIj5PYnNvbGV0ZXM6IDxhIGhyZWY9 J2h0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzU4NDknPjU4NDk8L2E+IChpZiZuYnNwO2Fw cHJvdmVkKTwvdGQ+PHRkIGNsYXNzPSJoZWFkZXIiPkQuIFJlY29yZG9uPC90ZD48L3RyPgo8dHI+ PHRkIGNsYXNzPSJoZWFkZXIiPkludGVuZGVkIHN0YXR1czogU3RhbmRhcmRzIFRyYWNrPC90ZD48 dGQgY2xhc3M9ImhlYWRlciI+RmFjZWJvb2s8L3RkPjwvdHI+Cjx0cj48dGQgY2xhc3M9ImhlYWRl ciI+RXhwaXJlczogRGVjZW1iZXIgMTAsIDIwMTI8L3RkPjx0ZCBjbGFzcz0iaGVhZGVyIj5ELiBI YXJkdDwvdGQ+PC90cj4KPHRyPjx0ZCBjbGFzcz0iaGVhZGVyIj4mbmJzcDs8L3RkPjx0ZCBjbGFz cz0iaGVhZGVyIj5NaWNyb3NvZnQ8L3RkPjwvdHI+Cjx0cj48dGQgY2xhc3M9ImhlYWRlciI+Jm5i c3A7PC90ZD48dGQgY2xhc3M9ImhlYWRlciI+SnVuZSA4LCAyMDEyPC90ZD48L3RyPgo8L3RhYmxl PjwvdGQ+PC90cj48L3RhYmxlPgo8aDE+PGJyIC8+VGhlIE9BdXRoIDIuMCBBdXRob3JpemF0aW9u IEZyYW1ld29yazxiciAvPmRyYWZ0LWlldGYtb2F1dGgtdjItMjc8L2gxPgoKPGgzPkFic3RyYWN0 PC9oMz4KCjxwPgogICAgICAgIFRoZSBPQXV0aCAyLjAgYXV0aG9yaXphdGlvbiBmcmFtZXdvcmsg ZW5hYmxlcyBhIHRoaXJkLXBhcnR5IGFwcGxpY2F0aW9uIHRvIG9idGFpbiBsaW1pdGVkCiAgICAg ICAgYWNjZXNzIHRvIGFuIEhUVFAgc2VydmljZSwgZWl0aGVyIG9uIGJlaGFsZiBvZiBhIHJlc291 cmNlIG93bmVyIGJ5IG9yY2hlc3RyYXRpbmcgYW4gYXBwcm92YWwKICAgICAgICBpbnRlcmFjdGlv biBiZXR3ZWVuIHRoZSByZXNvdXJjZSBvd25lciBhbmQgdGhlIEhUVFAgc2VydmljZSwgb3IgYnkg YWxsb3dpbmcgdGhlIHRoaXJkLXBhcnR5CiAgICAgICAgYXBwbGljYXRpb24gdG8gb2J0YWluIGFj Y2VzcyBvbiBpdHMgb3duIGJlaGFsZi4gVGhpcyBzcGVjaWZpY2F0aW9uIHJlcGxhY2VzIGFuZCBv YnNvbGV0ZXMKICAgICAgICB0aGUgT0F1dGggMS4wIHByb3RvY29sIGRlc2NyaWJlZCBpbiBSRkMg NTg0OS4KICAgICAgCjwvcD4KPGgzPlN0YXR1cyBvZiB0aGlzIE1lbW88L2gzPgo8cD4KVGhpcyBJ bnRlcm5ldC1EcmFmdCBpcyBzdWJtaXR0ZWQgIGluIGZ1bGwKY29uZm9ybWFuY2Ugd2l0aCB0aGUg cHJvdmlzaW9ucyBvZiBCQ1AmbmJzcDs3OCBhbmQgQkNQJm5ic3A7NzkuPC9wPgo8cD4KSW50ZXJu ZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJp bmcKVGFzayBGb3JjZSAoSUVURikuICBOb3RlIHRoYXQgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRp c3RyaWJ1dGUKd29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtRHJhZnRzLiAgVGhlIGxpc3Qg b2YgY3VycmVudApJbnRlcm5ldC1EcmFmdHMgaXMgYXQgaHR0cDovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RyYWZ0cy9jdXJyZW50Ly48L3A+CjxwPgpJbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRv Y3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCBtb250aHMKYW5kIG1heSBiZSB1cGRh dGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cyBhdCBhbnkgdGlt ZS4KSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5j ZSBtYXRlcmlhbCBvciB0byBjaXRlCnRoZW0gb3RoZXIgdGhhbiBhcyAmbGRxdW87d29yayBpbiBw cm9ncmVzcy4mcmRxdW87PC9wPgo8cD4KVGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4cGlyZSBv biBEZWNlbWJlciAxMCwgMjAxMi48L3A+Cgo8aDM+Q29weXJpZ2h0IE5vdGljZTwvaDM+CjxwPgpD b3B5cmlnaHQgKGMpIDIwMTIgSUVURiBUcnVzdCBhbmQgdGhlIHBlcnNvbnMgaWRlbnRpZmllZCBh cyB0aGUKZG9jdW1lbnQgYXV0aG9ycy4gIEFsbCByaWdodHMgcmVzZXJ2ZWQuPC9wPgo8cD4KVGhp cyBkb2N1bWVudCBpcyBzdWJqZWN0IHRvIEJDUCA3OCBhbmQgdGhlIElFVEYgVHJ1c3QncyBMZWdh bApQcm92aXNpb25zIFJlbGF0aW5nIHRvIElFVEYgRG9jdW1lbnRzCihodHRwOi8vdHJ1c3RlZS5p ZXRmLm9yZy9saWNlbnNlLWluZm8pIGluIGVmZmVjdCBvbiB0aGUgZGF0ZSBvZgpwdWJsaWNhdGlv biBvZiB0aGlzIGRvY3VtZW50LiAgUGxlYXNlIHJldmlldyB0aGVzZSBkb2N1bWVudHMKY2FyZWZ1 bGx5LCBhcyB0aGV5IGRlc2NyaWJlIHlvdXIgcmlnaHRzIGFuZCByZXN0cmljdGlvbnMgd2l0aCBy ZXNwZWN0CnRvIHRoaXMgZG9jdW1lbnQuIENvZGUgQ29tcG9uZW50cyBleHRyYWN0ZWQgZnJvbSB0 aGlzIGRvY3VtZW50IG11c3QKaW5jbHVkZSBTaW1wbGlmaWVkIEJTRCBMaWNlbnNlIHRleHQgYXMg ZGVzY3JpYmVkIGluIFNlY3Rpb24gNC5lIG9mCnRoZSBUcnVzdCBMZWdhbCBQcm92aXNpb25zIGFu ZCBhcmUgcHJvdmlkZWQgd2l0aG91dCB3YXJyYW50eSBhcwpkZXNjcmliZWQgaW4gdGhlIFNpbXBs aWZpZWQgQlNEIExpY2Vuc2UuPC9wPgo8YSBuYW1lPSJ0b2MiPjwvYT48YnIgLz48aHIgLz4KPGgz PlRhYmxlIG9mIENvbnRlbnRzPC9oMz4KPHAgY2xhc3M9InRvYyI+CjxhIGhyZWY9IiNhbmNob3Ix Ij4xLjwvYT4mbmJzcDsKSW50cm9kdWN0aW9uPGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OzxhIGhyZWY9IiNhbmNob3IyIj4xLjEuPC9hPiZuYnNwOwpSb2xlczxiciAvPgombmJzcDsmbmJz cDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjYW5jaG9yMyI+MS4yLjwvYT4mbmJzcDsKUHJvdG9jb2wg RmxvdzxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjYW5jaG9yNCI+MS4z LjwvYT4mbmJzcDsKQXV0aG9yaXphdGlvbiBHcmFudDxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjYW5jaG9yNSI+MS4zLjEuPC9h PiZuYnNwOwpBdXRob3JpemF0aW9uIENvZGU8YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI2FuY2hvcjYiPjEuMy4yLjwvYT4mbmJz cDsKSW1wbGljaXQ8YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7PGEgaHJlZj0iI2FuY2hvcjciPjEuMy4zLjwvYT4mbmJzcDsKUmVzb3VyY2UgT3du ZXIgUGFzc3dvcmQgQ3JlZGVudGlhbHM8YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI2FuY2hvcjgiPjEuMy40LjwvYT4mbmJzcDsK Q2xpZW50IENyZWRlbnRpYWxzPGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9 IiNhbmNob3I5Ij4xLjQuPC9hPiZuYnNwOwpBY2Nlc3MgVG9rZW48YnIgLz4KJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI2FuY2hvcjEwIj4xLjUuPC9hPiZuYnNwOwpSZWZyZXNoIFRv a2VuPGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiN0bHMiPjEuNi48L2E+ Jm5ic3A7ClRMUyBWZXJzaW9uPGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9 IiNhbmNob3IxMSI+MS43LjwvYT4mbmJzcDsKSFRUUCBSZWRpcmVjdGlvbnM8YnIgLz4KJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI2FuY2hvcjEyIj4xLjguPC9hPiZuYnNwOwpJbnRl cm9wZXJhYmlsaXR5PGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNhbmNo b3IxMyI+MS45LjwvYT4mbmJzcDsKTm90YXRpb25hbCBDb252ZW50aW9uczxiciAvPgo8YSBocmVm PSIjYW5jaG9yMTQiPjIuPC9hPiZuYnNwOwpDbGllbnQgUmVnaXN0cmF0aW9uPGJyIC8+CiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNjbGllbnQtdHlwZXMiPjIuMS48L2E+Jm5ic3A7 CkNsaWVudCBUeXBlczxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjY2xp ZW50LWlkZW50aWZpZXIiPjIuMi48L2E+Jm5ic3A7CkNsaWVudCBJZGVudGlmaWVyPGJyIC8+CiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNjbGllbnQtYXV0aGVudGljYXRpb24iPjIu My48L2E+Jm5ic3A7CkNsaWVudCBBdXRoZW50aWNhdGlvbjxiciAvPgombmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjY2xpZW50LXBhc3N3b3Jk Ij4yLjMuMS48L2E+Jm5ic3A7CkNsaWVudCBQYXNzd29yZDxiciAvPgombmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjYW5jaG9yMTUiPjIuMy4y LjwvYT4mbmJzcDsKT3RoZXIgQXV0aGVudGljYXRpb24gTWV0aG9kczxiciAvPgombmJzcDsmbmJz cDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjYW5jaG9yMTYiPjIuNC48L2E+Jm5ic3A7ClVucmVnaXN0 ZXJlZCBDbGllbnRzPGJyIC8+CjxhIGhyZWY9IiNhbmNob3IxNyI+My48L2E+Jm5ic3A7ClByb3Rv Y29sIEVuZHBvaW50czxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjYW5j aG9yMTgiPjMuMS48L2E+Jm5ic3A7CkF1dGhvcml6YXRpb24gRW5kcG9pbnQ8YnIgLz4KJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI3Jlc3Bv bnNlLXR5cGUiPjMuMS4xLjwvYT4mbmJzcDsKUmVzcG9uc2UgVHlwZTxiciAvPgombmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjcmVkaXJlY3Qt dXJpIj4zLjEuMi48L2E+Jm5ic3A7ClJlZGlyZWN0aW9uIEVuZHBvaW50PGJyIC8+CiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNhbmNob3IyNCI+My4yLjwvYT4mbmJzcDsKVG9rZW4g RW5kcG9pbnQ8YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7PGEgaHJlZj0iI3Rva2VuLWVuZHBvaW50LWF1dGgiPjMuMi4xLjwvYT4mbmJzcDsKQ2xp ZW50IEF1dGhlbnRpY2F0aW9uPGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9 IiNzY29wZSI+My4zLjwvYT4mbmJzcDsKQWNjZXNzIFRva2VuIFNjb3BlPGJyIC8+CjxhIGhyZWY9 IiNhbmNob3IyNSI+NC48L2E+Jm5ic3A7Ck9idGFpbmluZyBBdXRob3JpemF0aW9uPGJyIC8+CiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNncmFudC1jb2RlIj40LjEuPC9hPiZuYnNw OwpBdXRob3JpemF0aW9uIENvZGUgR3JhbnQ8YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI2NvZGUtYXV0aHotcmVxIj40LjEuMS48 L2E+Jm5ic3A7CkF1dGhvcml6YXRpb24gUmVxdWVzdDxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjY29kZS1hdXRoei1yZXNwIj40 LjEuMi48L2E+Jm5ic3A7CkF1dGhvcml6YXRpb24gUmVzcG9uc2U8YnIgLz4KJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI3Rva2VuLXJlcSI+ NC4xLjMuPC9hPiZuYnNwOwpBY2Nlc3MgVG9rZW4gUmVxdWVzdDxiciAvPgombmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjYW5jaG9yMjYiPjQu MS40LjwvYT4mbmJzcDsKQWNjZXNzIFRva2VuIFJlc3BvbnNlPGJyIC8+CiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOzxhIGhyZWY9IiNncmFudC1pbXBsaWNpdCI+NC4yLjwvYT4mbmJzcDsKSW1wbGlj aXQgR3JhbnQ8YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7PGEgaHJlZj0iI2ltcGxpY2l0LWF1dGh6LXJlcSI+NC4yLjEuPC9hPiZuYnNwOwpBdXRo b3JpemF0aW9uIFJlcXVlc3Q8YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI2ltcGxpY2l0LWF1dGh6LXJlc3AiPjQuMi4yLjwvYT4m bmJzcDsKQWNjZXNzIFRva2VuIFJlc3BvbnNlPGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OzxhIGhyZWY9IiNncmFudC1wYXNzd29yZCI+NC4zLjwvYT4mbmJzcDsKUmVzb3VyY2UgT3duZXIg UGFzc3dvcmQgQ3JlZGVudGlhbHMgR3JhbnQ8YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI2FuY2hvcjI3Ij40LjMuMS48L2E+Jm5i c3A7CkF1dGhvcml6YXRpb24gUmVxdWVzdCBhbmQgUmVzcG9uc2U8YnIgLz4KJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI3Bhc3N3b3JkLXRv ay1yZXEiPjQuMy4yLjwvYT4mbmJzcDsKQWNjZXNzIFRva2VuIFJlcXVlc3Q8YnIgLz4KJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI2FuY2hv cjI4Ij40LjMuMy48L2E+Jm5ic3A7CkFjY2VzcyBUb2tlbiBSZXNwb25zZTxiciAvPgombmJzcDsm bmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjZ3JhbnQtY2xpZW50Ij40LjQuPC9hPiZuYnNwOwpD bGllbnQgQ3JlZGVudGlhbHMgR3JhbnQ8YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI2FuY2hvcjI5Ij40LjQuMS48L2E+Jm5ic3A7 CkF1dGhvcml6YXRpb24gUmVxdWVzdCBhbmQgUmVzcG9uc2U8YnIgLz4KJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI2NsaWVudC1yZXEiPjQu NC4yLjwvYT4mbmJzcDsKQWNjZXNzIFRva2VuIFJlcXVlc3Q8YnIgLz4KJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI2FuY2hvcjMwIj40LjQu My48L2E+Jm5ic3A7CkFjY2VzcyBUb2tlbiBSZXNwb25zZTxiciAvPgombmJzcDsmbmJzcDsmbmJz cDsmbmJzcDs8YSBocmVmPSIjZXh0LWdyYW50Ij40LjUuPC9hPiZuYnNwOwpFeHRlbnNpb24gR3Jh bnRzPGJyIC8+CjxhIGhyZWY9IiN0b2tlbi1pc3N1ZSI+NS48L2E+Jm5ic3A7Cklzc3VpbmcgYW4g QWNjZXNzIFRva2VuPGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiN0b2tl bi1yZXNwb25zZSI+NS4xLjwvYT4mbmJzcDsKU3VjY2Vzc2Z1bCBSZXNwb25zZTxiciAvPgombmJz cDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjdG9rZW4tZXJyb3JzIj41LjIuPC9hPiZuYnNw OwpFcnJvciBSZXNwb25zZTxiciAvPgo8YSBocmVmPSIjdG9rZW4tcmVmcmVzaCI+Ni48L2E+Jm5i c3A7ClJlZnJlc2hpbmcgYW4gQWNjZXNzIFRva2VuPGJyIC8+CjxhIGhyZWY9IiNhY2Nlc3MtcmVz b3VyY2UiPjcuPC9hPiZuYnNwOwpBY2Nlc3NpbmcgUHJvdGVjdGVkIFJlc291cmNlczxiciAvPgom bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjdG9rZW4tdHlwZXMiPjcuMS48L2E+Jm5i c3A7CkFjY2VzcyBUb2tlbiBUeXBlczxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBo cmVmPSIjcmVzb3VyY2UtZXJyb3JzIj43LjIuPC9hPiZuYnNwOwpFcnJvciBSZXNwb25zZTxiciAv Pgo8YSBocmVmPSIjZXh0ZW5zaW9ucyI+OC48L2E+Jm5ic3A7CkV4dGVuc2liaWxpdHk8YnIgLz4K Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI25ldy10eXBlcyI+OC4xLjwvYT4mbmJz cDsKRGVmaW5pbmcgQWNjZXNzIFRva2VuIFR5cGVzPGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOzxhIGhyZWY9IiNlbmRwb2ludC1wYXJhbXMiPjguMi48L2E+Jm5ic3A7CkRlZmluaW5nIE5l dyBFbmRwb2ludCBQYXJhbWV0ZXJzPGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhy ZWY9IiNhbmNob3IzMSI+OC4zLjwvYT4mbmJzcDsKRGVmaW5pbmcgTmV3IEF1dGhvcml6YXRpb24g R3JhbnQgVHlwZXM8YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI3Jlc3Bv bnNlLXR5cGUtZXh0Ij44LjQuPC9hPiZuYnNwOwpEZWZpbmluZyBOZXcgQXV0aG9yaXphdGlvbiBF bmRwb2ludCBSZXNwb25zZSBUeXBlczxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBo cmVmPSIjbmV3LWVycm9ycyI+OC41LjwvYT4mbmJzcDsKRGVmaW5pbmcgQWRkaXRpb25hbCBFcnJv ciBDb2RlczxiciAvPgo8YSBocmVmPSIjYW5jaG9yMzIiPjkuPC9hPiZuYnNwOwpOYXRpdmUgQXBw bGljYXRpb25zPGJyIC8+CjxhIGhyZWY9IiNhbmNob3IzMyI+MTAuPC9hPiZuYnNwOwpTZWN1cml0 eSBDb25zaWRlcmF0aW9uczxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIj YW5jaG9yMzQiPjEwLjEuPC9hPiZuYnNwOwpDbGllbnQgQXV0aGVudGljYXRpb248YnIgLz4KJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI2FuY2hvcjM1Ij4xMC4yLjwvYT4mbmJzcDsK Q2xpZW50IEltcGVyc29uYXRpb248YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJl Zj0iI2FuY2hvcjM2Ij4xMC4zLjwvYT4mbmJzcDsKQWNjZXNzIFRva2VuczxiciAvPgombmJzcDsm bmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjYW5jaG9yMzciPjEwLjQuPC9hPiZuYnNwOwpSZWZy ZXNoIFRva2VuczxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjYW5jaG9y MzgiPjEwLjUuPC9hPiZuYnNwOwpBdXRob3JpemF0aW9uIENvZGVzPGJyIC8+CiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNhbmNob3IzOSI+MTAuNi48L2E+Jm5ic3A7CkF1dGhvcml6 YXRpb24gQ29kZSBSZWRpcmVjdGlvbiBVUkkgTWFuaXB1bGF0aW9uPGJyIC8+CiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNhbmNob3I0MCI+MTAuNy48L2E+Jm5ic3A7ClJlc291cmNl IE93bmVyIFBhc3N3b3JkIENyZWRlbnRpYWxzPGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OzxhIGhyZWY9IiNhbmNob3I0MSI+MTAuOC48L2E+Jm5ic3A7ClJlcXVlc3QgQ29uZmlkZW50aWFs aXR5PGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNhbmNob3I0MiI+MTAu OS48L2E+Jm5ic3A7CkVuZHBvaW50cyBBdXRoZW50aWNpdHk8YnIgLz4KJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7PGEgaHJlZj0iI2FudGhyb3B5Ij4xMC4xMC48L2E+Jm5ic3A7CkNyZWRlbnRpYWxz IEd1ZXNzaW5nIEF0dGFja3M8YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0i I2FuY2hvcjQzIj4xMC4xMS48L2E+Jm5ic3A7ClBoaXNoaW5nIEF0dGFja3M8YnIgLz4KJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI0NTUkYiPjEwLjEyLjwvYT4mbmJzcDsKQ3Jvc3Mt U2l0ZSBSZXF1ZXN0IEZvcmdlcnk8YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJl Zj0iI2FuY2hvcjQ0Ij4xMC4xMy48L2E+Jm5ic3A7CkNsaWNramFja2luZzxiciAvPgombmJzcDsm bmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjYW5jaG9yNDUiPjEwLjE0LjwvYT4mbmJzcDsKQ29k ZSBJbmplY3Rpb24gYW5kIElucHV0IFZhbGlkYXRpb248YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7PGEgaHJlZj0iI29wZW4tcmVkaXJlY3QiPjEwLjE1LjwvYT4mbmJzcDsKT3BlbiBSZWRp cmVjdG9yczxiciAvPgo8YSBocmVmPSIjYW5jaG9yNDYiPjExLjwvYT4mbmJzcDsKSUFOQSBDb25z aWRlcmF0aW9uczxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjdHlwZS1y ZWdpc3RyeSI+MTEuMS48L2E+Jm5ic3A7ClRoZSBPQXV0aCBBY2Nlc3MgVG9rZW4gVHlwZSBSZWdp c3RyeTxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDs8YSBocmVmPSIjYW5jaG9yNDciPjExLjEuMS48L2E+Jm5ic3A7ClJlZ2lzdHJhdGlvbiBUZW1w bGF0ZTxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjcGFyYW1ldGVycy1y ZWdpc3RyeSI+MTEuMi48L2E+Jm5ic3A7ClRoZSBPQXV0aCBQYXJhbWV0ZXJzIFJlZ2lzdHJ5PGJy IC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhy ZWY9IiNhbmNob3I0OCI+MTEuMi4xLjwvYT4mbmJzcDsKUmVnaXN0cmF0aW9uIFRlbXBsYXRlPGJy IC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhy ZWY9IiNhbmNob3I0OSI+MTEuMi4yLjwvYT4mbmJzcDsKSW5pdGlhbCBSZWdpc3RyeSBDb250ZW50 czxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjcmVzcG9uc2UtdHlwZS1y ZWdpc3RyeSI+MTEuMy48L2E+Jm5ic3A7ClRoZSBPQXV0aCBBdXRob3JpemF0aW9uIEVuZHBvaW50 IFJlc3BvbnNlIFR5cGUgUmVnaXN0cnk8YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI2FuY2hvcjUwIj4xMS4zLjEuPC9hPiZuYnNw OwpSZWdpc3RyYXRpb24gVGVtcGxhdGU8YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI2FuY2hvcjUxIj4xMS4zLjIuPC9hPiZuYnNw OwpJbml0aWFsIFJlZ2lzdHJ5IENvbnRlbnRzPGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OzxhIGhyZWY9IiNlcnJvci1yZWdpc3RyeSI+MTEuNC48L2E+Jm5ic3A7ClRoZSBPQXV0aCBFeHRl bnNpb25zIEVycm9yIFJlZ2lzdHJ5PGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNhbmNob3I1MiI+MTEuNC4xLjwvYT4mbmJzcDsK UmVnaXN0cmF0aW9uIFRlbXBsYXRlPGJyIC8+CjxhIGhyZWY9IiNyZmMucmVmZXJlbmNlczEiPjEy LjwvYT4mbmJzcDsKUmVmZXJlbmNlczxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBo cmVmPSIjcmZjLnJlZmVyZW5jZXMxIj4xMi4xLjwvYT4mbmJzcDsKTm9ybWF0aXZlIFJlZmVyZW5j ZXM8YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI3JmYy5yZWZlcmVuY2Vz MiI+MTIuMi48L2E+Jm5ic3A7CkluZm9ybWF0aXZlIFJlZmVyZW5jZXM8YnIgLz4KPGEgaHJlZj0i I2FuY2hvcjU1Ij5BcHBlbmRpeCZuYnNwO0EuPC9hPiZuYnNwOwpBdWdtZW50ZWQgQmFja3VzLU5h dXIgRm9ybSAoQUJORikgU3ludGF4PGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhy ZWY9IiNhbmNob3I1NiI+QS4xLjwvYT4mbmJzcDsKImNsaWVudF9pZCIgU3ludGF4PGJyIC8+CiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNhbmNob3I1NyI+QS4yLjwvYT4mbmJzcDsK ImNsaWVudF9zZWNyZXQiIFN5bnRheDxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBo cmVmPSIjYW5jaG9yNTgiPkEuMy48L2E+Jm5ic3A7CiJyZXNwb25zZV90eXBlIiBTeW50YXg8YnIg Lz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI2FuY2hvcjU5Ij5BLjQuPC9hPiZu YnNwOwoic2NvcGUiIFN5bnRheDxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVm PSIjYW5jaG9yNjAiPkEuNS48L2E+Jm5ic3A7CiJzdGF0ZSIgU3ludGF4PGJyIC8+CiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNhbmNob3I2MSI+QS42LjwvYT4mbmJzcDsKInJlZGly ZWN0X3VyaSIgU3ludGF4PGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNh bmNob3I2MiI+QS43LjwvYT4mbmJzcDsKImVycm9yIiBTeW50YXg8YnIgLz4KJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI2FuY2hvcjYzIj5BLjguPC9hPiZuYnNwOwoiZXJyb3JfZGVz Y3JpcHRpb24iIFN5bnRheDxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIj YW5jaG9yNjQiPkEuOS48L2E+Jm5ic3A7CiJlcnJvcl91cmkiIFN5bnRheDxiciAvPgombmJzcDsm bmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjYW5jaG9yNjUiPkEuMTAuPC9hPiZuYnNwOwoiZ3Jh bnRfdHlwZSIgU3ludGF4PGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNh bmNob3I2NiI+QS4xMS48L2E+Jm5ic3A7CiJjb2RlIiBTeW50YXg8YnIgLz4KJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI2FuY2hvcjY3Ij5BLjEyLjwvYT4mbmJzcDsKImFjY2Vzc190 b2tlbiIgU3ludGF4PGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNhbmNo b3I2OCI+QS4xMy48L2E+Jm5ic3A7CiJ0b2tlbl90eXBlIiBTeW50YXg8YnIgLz4KJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI2FuY2hvcjY5Ij5BLjE0LjwvYT4mbmJzcDsKImV4cGly ZXNfaW4iIFN5bnRheDxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjYW5j aG9yNzAiPkEuMTUuPC9hPiZuYnNwOwoidXNlcm5hbWUiIFN5bnRheDxiciAvPgombmJzcDsmbmJz cDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjYW5jaG9yNzEiPkEuMTYuPC9hPiZuYnNwOwoicGFzc3dv cmQiIFN5bnRheDxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjYW5jaG9y NzIiPkEuMTcuPC9hPiZuYnNwOwoicmVmcmVzaF90b2tlbiIgU3ludGF4PGJyIC8+CiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNhbmNob3I3MyI+QS4xOC48L2E+Jm5ic3A7CkVuZHBv aW50IFBhcmFtZXRlciBTeW50YXg8YnIgLz4KPGEgaHJlZj0iI2FuY2hvcjc0Ij5BcHBlbmRpeCZu YnNwO0IuPC9hPiZuYnNwOwpBY2tub3dsZWRnZW1lbnRzPGJyIC8+CjxhIGhyZWY9IiNhbmNob3I3 NSI+QXBwZW5kaXgmbmJzcDtDLjwvYT4mbmJzcDsKRWRpdG9yJ3MgTm90ZXM8YnIgLz4KPGEgaHJl Zj0iI3JmYy5hdXRob3JzIj4mIzE2Nzs8L2E+Jm5ic3A7CkF1dGhvcnMnIEFkZHJlc3NlczxiciAv Pgo8L3A+CjxiciBjbGVhcj0iYWxsIiAvPgoKPGEgbmFtZT0iYW5jaG9yMSI+PC9hPjxiciAvPjxo ciAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9 IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48 YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5h bWU9InJmYy5zZWN0aW9uLjEiPjwvYT48aDM+MS4mbmJzcDsKSW50cm9kdWN0aW9uPC9oMz4KCjxw PgogICAgICAgIEluIHRoZSB0cmFkaXRpb25hbCBjbGllbnQtc2VydmVyIGF1dGhlbnRpY2F0aW9u IG1vZGVsLCB0aGUgY2xpZW50IHJlcXVlc3RzIGFuIGFjY2VzcwogICAgICAgIHJlc3RyaWN0ZWQg cmVzb3VyY2UgKHByb3RlY3RlZCByZXNvdXJjZSkgb24gdGhlIHNlcnZlciBieSBhdXRoZW50aWNh dGluZyB3aXRoIHRoZSBzZXJ2ZXIKICAgICAgICB1c2luZyB0aGUgcmVzb3VyY2Ugb3duZXIncyBj cmVkZW50aWFscy4gSW4gb3JkZXIgdG8gcHJvdmlkZSB0aGlyZC1wYXJ0eSBhcHBsaWNhdGlvbnMg YWNjZXNzCiAgICAgICAgdG8gcmVzdHJpY3RlZCByZXNvdXJjZXMsIHRoZSByZXNvdXJjZSBvd25l ciBzaGFyZXMgaXRzIGNyZWRlbnRpYWxzIHdpdGggdGhlIHRoaXJkLXBhcnR5LgogICAgICAgIFRo aXMgY3JlYXRlcyBzZXZlcmFsIHByb2JsZW1zIGFuZCBsaW1pdGF0aW9uczoKICAgICAgCjwvcD4K PHA+CiAgICAgICAgPC9wPgo8dWwgY2xhc3M9InRleHQiPgo8bGk+CiAgICAgICAgICAgIFRoaXJk LXBhcnR5IGFwcGxpY2F0aW9ucyBhcmUgcmVxdWlyZWQgdG8gc3RvcmUgdGhlIHJlc291cmNlIG93 bmVyJ3MgY3JlZGVudGlhbHMKICAgICAgICAgICAgZm9yIGZ1dHVyZSB1c2UsIHR5cGljYWxseSBh IHBhc3N3b3JkIGluIGNsZWFyLXRleHQuCiAgICAgICAgICAKPC9saT4KPGxpPgogICAgICAgICAg ICBTZXJ2ZXJzIGFyZSByZXF1aXJlZCB0byBzdXBwb3J0IHBhc3N3b3JkIGF1dGhlbnRpY2F0aW9u LCBkZXNwaXRlIHRoZSBzZWN1cml0eQogICAgICAgICAgICB3ZWFrbmVzc2VzIGluaGVyZW50IGlu IHBhc3N3b3Jkcy4KICAgICAgICAgIAo8L2xpPgo8bGk+CiAgICAgICAgICAgIFRoaXJkLXBhcnR5 IGFwcGxpY2F0aW9ucyBnYWluIG92ZXJseSBicm9hZCBhY2Nlc3MgdG8gdGhlIHJlc291cmNlIG93 bmVyJ3MgcHJvdGVjdGVkCiAgICAgICAgICAgIHJlc291cmNlcywgbGVhdmluZyByZXNvdXJjZSBv d25lcnMgd2l0aG91dCBhbnkgYWJpbGl0eSB0byByZXN0cmljdCBkdXJhdGlvbiBvciBhY2Nlc3MK ICAgICAgICAgICAgdG8gYSBsaW1pdGVkIHN1YnNldCBvZiByZXNvdXJjZXMuCiAgICAgICAgICAK PC9saT4KPGxpPgogICAgICAgICAgICBSZXNvdXJjZSBvd25lcnMgY2Fubm90IHJldm9rZSBhY2Nl c3MgdG8gYW4gaW5kaXZpZHVhbCB0aGlyZC1wYXJ0eSB3aXRob3V0IHJldm9raW5nCiAgICAgICAg ICAgIGFjY2VzcyB0byBhbGwgdGhpcmQtcGFydGllcywgYW5kIG11c3QgZG8gc28gYnkgY2hhbmdp bmcgdGhlaXIgcGFzc3dvcmQuCiAgICAgICAgICAKPC9saT4KPGxpPgogICAgICAgICAgICBDb21w cm9taXNlIG9mIGFueSB0aGlyZC1wYXJ0eSBhcHBsaWNhdGlvbiByZXN1bHRzIGluIGNvbXByb21p c2Ugb2YgdGhlIGVuZC11c2VyJ3MKICAgICAgICAgICAgcGFzc3dvcmQgYW5kIGFsbCBvZiB0aGUg ZGF0YSBwcm90ZWN0ZWQgYnkgdGhhdCBwYXNzd29yZC4KICAgICAgICAgIAo8L2xpPgo8L3VsPjxw PgogICAgICAKPC9wPgo8cD4KICAgICAgICBPQXV0aCBhZGRyZXNzZXMgdGhlc2UgaXNzdWVzIGJ5 IGludHJvZHVjaW5nIGFuIGF1dGhvcml6YXRpb24gbGF5ZXIgYW5kIHNlcGFyYXRpbmcgdGhlIHJv bGUKICAgICAgICBvZiB0aGUgY2xpZW50IGZyb20gdGhhdCBvZiB0aGUgcmVzb3VyY2Ugb3duZXIu IEluIE9BdXRoLCB0aGUgY2xpZW50IHJlcXVlc3RzIGFjY2VzcyB0bwogICAgICAgIHJlc291cmNl cyBjb250cm9sbGVkIGJ5IHRoZSByZXNvdXJjZSBvd25lciBhbmQgaG9zdGVkIGJ5IHRoZSByZXNv dXJjZSBzZXJ2ZXIsIGFuZCBpcyBpc3N1ZWQKICAgICAgICBhIGRpZmZlcmVudCBzZXQgb2YgY3Jl ZGVudGlhbHMgdGhhbiB0aG9zZSBvZiB0aGUgcmVzb3VyY2Ugb3duZXIuCiAgICAgIAo8L3A+Cjxw PgogICAgICAgIEluc3RlYWQgb2YgdXNpbmcgdGhlIHJlc291cmNlIG93bmVyJ3MgY3JlZGVudGlh bHMgdG8gYWNjZXNzIHByb3RlY3RlZCByZXNvdXJjZXMsIHRoZSBjbGllbnQKICAgICAgICBvYnRh aW5zIGFuIGFjY2VzcyB0b2tlbiAtIGEgc3RyaW5nIGRlbm90aW5nIGEgc3BlY2lmaWMgc2NvcGUs IGxpZmV0aW1lLCBhbmQgb3RoZXIgYWNjZXNzCiAgICAgICAgYXR0cmlidXRlcy4gQWNjZXNzIHRv a2VucyBhcmUgaXNzdWVkIHRvIHRoaXJkLXBhcnR5IGNsaWVudHMgYnkgYW4gYXV0aG9yaXphdGlv biBzZXJ2ZXIgd2l0aAogICAgICAgIHRoZSBhcHByb3ZhbCBvZiB0aGUgcmVzb3VyY2Ugb3duZXIu IFRoZSBjbGllbnQgdXNlcyB0aGUgYWNjZXNzIHRva2VuIHRvIGFjY2VzcyB0aGUKICAgICAgICBw cm90ZWN0ZWQgcmVzb3VyY2VzIGhvc3RlZCBieSB0aGUgcmVzb3VyY2Ugc2VydmVyLgogICAgICAK PC9wPgo8cD4KICAgICAgICBGb3IgZXhhbXBsZSwgYW4gZW5kLXVzZXIgKHJlc291cmNlIG93bmVy KSBjYW4gZ3JhbnQgYSBwcmludGluZyBzZXJ2aWNlIChjbGllbnQpIGFjY2VzcwogICAgICAgIHRv IGhlciBwcm90ZWN0ZWQgcGhvdG9zIHN0b3JlZCBhdCBhIHBob3RvIHNoYXJpbmcgc2VydmljZSAo cmVzb3VyY2Ugc2VydmVyKSwgd2l0aG91dAogICAgICAgIHNoYXJpbmcgaGVyIHVzZXJuYW1lIGFu ZCBwYXNzd29yZCB3aXRoIHRoZSBwcmludGluZyBzZXJ2aWNlLiBJbnN0ZWFkLCBzaGUgYXV0aGVu dGljYXRlcwogICAgICAgIGRpcmVjdGx5IHdpdGggYSBzZXJ2ZXIgdHJ1c3RlZCBieSB0aGUgcGhv dG8gc2hhcmluZyBzZXJ2aWNlIChhdXRob3JpemF0aW9uIHNlcnZlcikgd2hpY2gKICAgICAgICBp c3N1ZXMgdGhlIHByaW50aW5nIHNlcnZpY2UgZGVsZWdhdGlvbi1zcGVjaWZpYyBjcmVkZW50aWFs cyAoYWNjZXNzIHRva2VuKS4KICAgICAgCjwvcD4KPHA+CiAgICAgICAgVGhpcyBzcGVjaWZpY2F0 aW9uIGlzIGRlc2lnbmVkIGZvciB1c2Ugd2l0aCBIVFRQICg8YSBjbGFzcz0naW5mbycgaHJlZj0n I1JGQzI2MTYnPltSRkMyNjE2XTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5GaWVs ZGluZywgUi4sIEdldHR5cywgSi4sIE1vZ3VsLCBKLiwgRnJ5c3R5aywgSC4sIE1hc2ludGVyLCBM LiwgTGVhY2gsIFAuLCBhbmQgVC4gQmVybmVycy1MZWUsICZsZHF1bztIeXBlcnRleHQgVHJhbnNm ZXIgUHJvdG9jb2wgLS0gSFRUUC8xLjEsJnJkcXVvOyBKdW5lJm5ic3A7MTk5OS48L3NwYW4+PHNw YW4+KTwvc3Bhbj48L2E+KS4gVGhlIHVzZSBvZgogICAgICAgIE9BdXRoIG92ZXIgYW55IG90aGVy IHByb3RvY29sIHRoYW4gSFRUUCBpcyBvdXQgb2Ygc2NvcGUuCiAgICAgIAo8L3A+CjxwPgogICAg ICAgIFRoZSBPQXV0aCAxLjAgcHJvdG9jb2wgKDxhIGNsYXNzPSdpbmZvJyBocmVmPScjUkZDNTg0 OSc+W1JGQzU4NDldPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkhhbW1lci1MYWhh diwgRS4sICZsZHF1bztUaGUgT0F1dGggMS4wIFByb3RvY29sLCZyZHF1bzsgQXByaWwmbmJzcDsy MDEwLjwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4pLCBwdWJsaXNoZWQgYXMgYW4gaW5mb3JtYXRp b25hbCBkb2N1bWVudCwKICAgICAgICB3YXMgdGhlIHJlc3VsdCBvZiBhIHNtYWxsIGFkLWhvYyBj b21tdW5pdHkgZWZmb3J0LiBUaGlzIHN0YW5kYXJkcy10cmFjayBzcGVjaWZpY2F0aW9uIGJ1aWxk cwogICAgICAgIG9uIHRoZSBPQXV0aCAxLjAgZGVwbG95bWVudCBleHBlcmllbmNlLCBhcyB3ZWxs IGFzIGFkZGl0aW9uYWwgdXNlIGNhc2VzIGFuZCBleHRlbnNpYmlsaXR5CiAgICAgICAgcmVxdWly ZW1lbnRzIGdhdGhlcmVkIGZyb20gdGhlIHdpZGVyIElFVEYgY29tbXVuaXR5LiBUaGUgT0F1dGgg Mi4wIHByb3RvY29sIGlzIG5vdCBiYWNrd2FyZAogICAgICAgIGNvbXBhdGlibGUgd2l0aCBPQXV0 aCAxLjAuIFRoZSB0d28gdmVyc2lvbnMgbWF5IGNvLWV4aXN0IG9uIHRoZSBuZXR3b3JrIGFuZCBp bXBsZW1lbnRhdGlvbnMKICAgICAgICBtYXkgY2hvb3NlIHRvIHN1cHBvcnQgYm90aC4gSG93ZXZl ciwgaXQgaXMgdGhlIGludGVudGlvbiBvZiB0aGlzIHNwZWNpZmljYXRpb24gdGhhdCBuZXcKICAg ICAgICBpbXBsZW1lbnRhdGlvbiBzdXBwb3J0IE9BdXRoIDIuMCBhcyBzcGVjaWZpZWQgaW4gdGhp cyBkb2N1bWVudCwgYW5kIHRoYXQgT0F1dGggMS4wIGlzIHVzZWQKICAgICAgICBvbmx5IHRvIHN1 cHBvcnQgZXhpc3RpbmcgZGVwbG95bWVudHMuIFRoZSBPQXV0aCAyLjAgcHJvdG9jb2wgc2hhcmVz IHZlcnkgZmV3IGltcGxlbWVudGF0aW9uCiAgICAgICAgZGV0YWlscyB3aXRoIHRoZSBPQXV0aCAx LjAgcHJvdG9jb2wuIEltcGxlbWVudGVycyBmYW1pbGlhciB3aXRoIE9BdXRoIDEuMCBzaG91bGQg YXBwcm9hY2gKICAgICAgICB0aGlzIGRvY3VtZW50IHdpdGhvdXQgYW55IGFzc3VtcHRpb25zIGFz IHRvIGl0cyBzdHJ1Y3R1cmUgYW5kIGRldGFpbHMuCiAgICAgIAo8L3A+CjxhIG5hbWU9ImFuY2hv cjIiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9 IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQg Y2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90 cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi4xLjEiPjwvYT48aDM+MS4xLiZuYnNwOwpS b2xlczwvaDM+Cgo8cD4KICAgICAgICAgIE9BdXRoIGRlZmluZXMgZm91ciByb2xlczoKICAgICAg ICAKPC9wPgo8cD4KICAgICAgICAgIDwvcD4KPGJsb2NrcXVvdGUgY2xhc3M9InRleHQiPjxkbD4K PGR0PnJlc291cmNlIG93bmVyPC9kdD4KPGRkPgogICAgICAgICAgICAgIAogICAgICAgICAgICAg IEFuIGVudGl0eSBjYXBhYmxlIG9mIGdyYW50aW5nIGFjY2VzcyB0byBhIHByb3RlY3RlZCByZXNv dXJjZS4gV2hlbiB0aGUgcmVzb3VyY2Ugb3duZXIKICAgICAgICAgICAgICBpcyBhIHBlcnNvbiwg aXQgaXMgcmVmZXJyZWQgdG8gYXMgYW4gZW5kLXVzZXIuCiAgICAgICAgICAgIAo8L2RkPgo8ZHQ+ cmVzb3VyY2Ugc2VydmVyPC9kdD4KPGRkPgogICAgICAgICAgICAgIAogICAgICAgICAgICAgIFRo ZSBzZXJ2ZXIgaG9zdGluZyB0aGUgcHJvdGVjdGVkIHJlc291cmNlcywgY2FwYWJsZSBvZiBhY2Nl cHRpbmcgYW5kIHJlc3BvbmRpbmcgdG8KICAgICAgICAgICAgICBwcm90ZWN0ZWQgcmVzb3VyY2Ug cmVxdWVzdHMgdXNpbmcgYWNjZXNzIHRva2Vucy4KICAgICAgICAgICAgCjwvZGQ+CjxkdD5jbGll bnQ8L2R0Pgo8ZGQ+CiAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgQW4gYXBwbGljYXRpb24g bWFraW5nIHByb3RlY3RlZCByZXNvdXJjZSByZXF1ZXN0cyBvbiBiZWhhbGYgb2YgdGhlIHJlc291 cmNlIG93bmVyIGFuZAogICAgICAgICAgICAgIHdpdGggaXRzIGF1dGhvcml6YXRpb24uIFRoZSB0 ZXJtIGNsaWVudCBkb2VzIG5vdCBpbXBseSBhbnkgcGFydGljdWxhciBpbXBsZW1lbnRhdGlvbgog ICAgICAgICAgICAgIGNoYXJhY3RlcmlzdGljcyAoZS5nLiB3aGV0aGVyIHRoZSBhcHBsaWNhdGlv biBleGVjdXRlcyBvbiBhIHNlcnZlciwgYSBkZXNrdG9wLCBvcgogICAgICAgICAgICAgIG90aGVy IGRldmljZXMpLgogICAgICAgICAgICAKPC9kZD4KPGR0PmF1dGhvcml6YXRpb24gc2VydmVyPC9k dD4KPGRkPgogICAgICAgICAgICAgIAogICAgICAgICAgICAgIFRoZSBzZXJ2ZXIgaXNzdWluZyBh Y2Nlc3MgdG9rZW5zIHRvIHRoZSBjbGllbnQgYWZ0ZXIgc3VjY2Vzc2Z1bGx5IGF1dGhlbnRpY2F0 aW5nIHRoZQogICAgICAgICAgICAgIHJlc291cmNlIG93bmVyIGFuZCBvYnRhaW5pbmcgYXV0aG9y aXphdGlvbi4KICAgICAgICAgICAgCjwvZGQ+CjwvZGw+PC9ibG9ja3F1b3RlPjxwPgogICAgICAg IAo8L3A+CjxwPgogICAgICAgICAgVGhlIGludGVyYWN0aW9uIGJldHdlZW4gdGhlIGF1dGhvcml6 YXRpb24gc2VydmVyIGFuZCByZXNvdXJjZSBzZXJ2ZXIgaXMgYmV5b25kIHRoZSBzY29wZQogICAg ICAgICAgb2YgdGhpcyBzcGVjaWZpY2F0aW9uLiBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgbWF5 IGJlIHRoZSBzYW1lIHNlcnZlciBhcyB0aGUgcmVzb3VyY2UKICAgICAgICAgIHNlcnZlciBvciBh IHNlcGFyYXRlIGVudGl0eS4gQSBzaW5nbGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgbWF5IGlzc3Vl IGFjY2VzcyB0b2tlbnMKICAgICAgICAgIGFjY2VwdGVkIGJ5IG11bHRpcGxlIHJlc291cmNlIHNl cnZlcnMuCiAgICAgICAgCjwvcD4KPGEgbmFtZT0iYW5jaG9yMyI+PC9hPjxiciAvPjxociAvPgo8 dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNs YXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVm PSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJm Yy5zZWN0aW9uLjEuMiI+PC9hPjxoMz4xLjIuJm5ic3A7ClByb3RvY29sIEZsb3c8L2gzPgo8YnIg Lz48aHIgY2xhc3M9Imluc2VydCIgLz4KPGEgbmFtZT0iRmlndXJlLTEiPjwvYT4KPGRpdiBzdHls ZT0nZGlzcGxheTogdGFibGU7IHdpZHRoOiAwOyBtYXJnaW4tbGVmdDogM2VtOyBtYXJnaW4tcmln aHQ6IGF1dG8nPjxwcmU+CgogICstLS0tLS0tLSsgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgKy0tLS0tLS0tLS0tLS0tLSsKICB8ICAgICAgICB8LS0oQSktIEF1dGhvcml6YXRpb24gUmVx dWVzdCAtJmd0O3wgICBSZXNvdXJjZSAgICB8CiAgfCAgICAgICAgfCAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICB8ICAgICBPd25lciAgICAgfAogIHwgICAgICAgIHwmbHQ7LShCKS0tIEF1 dGhvcml6YXRpb24gR3JhbnQgLS0tfCAgICAgICAgICAgICAgIHwKICB8ICAgICAgICB8ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0rCiAgfCAgICAgICAgfAog IHwgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0t LSsKICB8ICAgICAgICB8LS0oQyktLSBBdXRob3JpemF0aW9uIEdyYW50IC0tJmd0O3wgQXV0aG9y aXphdGlvbiB8CiAgfCBDbGllbnQgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAg ICBTZXJ2ZXIgICAgfAogIHwgICAgICAgIHwmbHQ7LShEKS0tLS0tIEFjY2VzcyBUb2tlbiAtLS0t LS0tfCAgICAgICAgICAgICAgIHwKICB8ICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICstLS0tLS0tLS0tLS0tLS0rCiAgfCAgICAgICAgfAogIHwgICAgICAgIHwgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLSsKICB8ICAgICAgICB8LS0o RSktLS0tLSBBY2Nlc3MgVG9rZW4gLS0tLS0tJmd0O3wgICAgUmVzb3VyY2UgICB8CiAgfCAgICAg ICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICBTZXJ2ZXIgICAgfAogIHwg ICAgICAgIHwmbHQ7LShGKS0tLSBQcm90ZWN0ZWQgUmVzb3VyY2UgLS0tfCAgICAgICAgICAgICAg IHwKICArLS0tLS0tLS0rICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0t LS0tLS0rCgo8L3ByZT48L2Rpdj48dGFibGUgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgY2Vs bHNwYWNpbmc9IjIiIGFsaWduPSJjZW50ZXIiPjx0cj48dGQgYWxpZ249ImNlbnRlciI+PGZvbnQg ZmFjZT0ibW9uYWNvLCBNUyBTYW5zIFNlcmlmIiBzaXplPSIxIj48Yj4mbmJzcDtGaWd1cmUmbmJz cDsxOiBBYnN0cmFjdCBQcm90b2NvbCBGbG93Jm5ic3A7PC9iPjwvZm9udD48YnIgLz48L3RkPjwv dHI+PC90YWJsZT48aHIgY2xhc3M9Imluc2VydCIgLz4KCjxwPgogICAgICAgICAgVGhlIGFic3Ry YWN0IGZsb3cgaWxsdXN0cmF0ZWQgaW4gPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNGaWd1cmUtMSc+ RmlndXJlJm5ic3A7MTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5BYnN0cmFjdCBQ cm90b2NvbCBGbG93PC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPiBkZXNjcmliZXMgdGhlIGludGVy YWN0aW9uCiAgICAgICAgICBiZXR3ZWVuIHRoZSBmb3VyIHJvbGVzIGFuZCBpbmNsdWRlcyB0aGUg Zm9sbG93aW5nIHN0ZXBzOgogICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgPC9wPgo8YmxvY2tx dW90ZSBjbGFzcz0idGV4dCI+PGRsPgo8ZHQ+KEEpPC9kdD4KPGRkPgogICAgICAgICAgICAgIFRo ZSBjbGllbnQgcmVxdWVzdHMgYXV0aG9yaXphdGlvbiBmcm9tIHRoZSByZXNvdXJjZSBvd25lci4g VGhlIGF1dGhvcml6YXRpb24gcmVxdWVzdAogICAgICAgICAgICAgIGNhbiBiZSBtYWRlIGRpcmVj dGx5IHRvIHRoZSByZXNvdXJjZSBvd25lciAoYXMgc2hvd24pLCBvciBwcmVmZXJhYmx5IGluZGly ZWN0bHkgdmlhCiAgICAgICAgICAgICAgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGFzIGFuIGlu dGVybWVkaWFyeS4KICAgICAgICAgICAgCjwvZGQ+CjxkdD4oQik8L2R0Pgo8ZGQ+CiAgICAgICAg ICAgICAgVGhlIGNsaWVudCByZWNlaXZlcyBhbiBhdXRob3JpemF0aW9uIGdyYW50IHdoaWNoIGlz IGEgY3JlZGVudGlhbCByZXByZXNlbnRpbmcKICAgICAgICAgICAgICB0aGUgcmVzb3VyY2Ugb3du ZXIncyBhdXRob3JpemF0aW9uLCBleHByZXNzZWQgdXNpbmcgb25lIG9mIGZvdXIgZ3JhbnQgdHlw ZXMgZGVmaW5lZAogICAgICAgICAgICAgIGluIHRoaXMgc3BlY2lmaWNhdGlvbiBvciB1c2luZyBh biBleHRlbnNpb24gZ3JhbnQgdHlwZS4gVGhlIGF1dGhvcml6YXRpb24gZ3JhbnQgdHlwZQogICAg ICAgICAgICAgIGRlcGVuZHMgb24gdGhlIG1ldGhvZCB1c2VkIGJ5IHRoZSBjbGllbnQgdG8gcmVx dWVzdCBhdXRob3JpemF0aW9uIGFuZCB0aGUgdHlwZXMKICAgICAgICAgICAgICBzdXBwb3J0ZWQg YnkgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLgogICAgICAgICAgICAKPC9kZD4KPGR0PihDKTwv ZHQ+CjxkZD4KICAgICAgICAgICAgICBUaGUgY2xpZW50IHJlcXVlc3RzIGFuIGFjY2VzcyB0b2tl biBieSBhdXRoZW50aWNhdGluZyB3aXRoIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlcgogICAgICAg ICAgICAgIGFuZCBwcmVzZW50aW5nIHRoZSBhdXRob3JpemF0aW9uIGdyYW50LgogICAgICAgICAg ICAKPC9kZD4KPGR0PihEKTwvZHQ+CjxkZD4KICAgICAgICAgICAgICBUaGUgYXV0aG9yaXphdGlv biBzZXJ2ZXIgYXV0aGVudGljYXRlcyB0aGUgY2xpZW50IGFuZCB2YWxpZGF0ZXMgdGhlIGF1dGhv cml6YXRpb24KICAgICAgICAgICAgICBncmFudCwgYW5kIGlmIHZhbGlkIGlzc3VlcyBhbiBhY2Nl c3MgdG9rZW4uCiAgICAgICAgICAgIAo8L2RkPgo8ZHQ+KEUpPC9kdD4KPGRkPgogICAgICAgICAg ICAgIFRoZSBjbGllbnQgcmVxdWVzdHMgdGhlIHByb3RlY3RlZCByZXNvdXJjZSBmcm9tIHRoZSBy ZXNvdXJjZSBzZXJ2ZXIgYW5kIGF1dGhlbnRpY2F0ZXMKICAgICAgICAgICAgICBieSBwcmVzZW50 aW5nIHRoZSBhY2Nlc3MgdG9rZW4uCiAgICAgICAgICAgIAo8L2RkPgo8ZHQ+KEYpPC9kdD4KPGRk PgogICAgICAgICAgICAgIFRoZSByZXNvdXJjZSBzZXJ2ZXIgdmFsaWRhdGVzIHRoZSBhY2Nlc3Mg dG9rZW4sIGFuZCBpZiB2YWxpZCwgc2VydmVzIHRoZSByZXF1ZXN0LgogICAgICAgICAgICAKPC9k ZD4KPC9kbD48L2Jsb2NrcXVvdGU+PHA+CiAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICBUaGUg cHJlZmVycmVkIG1ldGhvZCBmb3IgdGhlIGNsaWVudCB0byBvYnRhaW4gYW4gYXV0aG9yaXphdGlv biBncmFudCBmcm9tIHRoZSByZXNvdXJjZQogICAgICAgICAgb3duZXIgKGRlcGljdGVkIGluIHN0 ZXBzIChBKSBhbmQgKEIpKSBpcyB0byB1c2UgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGFzIGFu IGludGVybWVkaWFyeQogICAgICAgICAgd2hpY2ggaXMgaWxsdXN0cmF0ZWQgaW4gPGEgY2xhc3M9 J2luZm8nIGhyZWY9JyNGaWd1cmUtMyc+RmlndXJlJm5ic3A7MzxzcGFuPiAoPC9zcGFuPjxzcGFu IGNsYXNzPSdpbmZvJz5BdXRob3JpemF0aW9uIENvZGUgRmxvdzwvc3Bhbj48c3Bhbj4pPC9zcGFu PjwvYT4uCiAgICAgICAgCjwvcD4KPGEgbmFtZT0iYW5jaG9yNCI+PC9hPjxiciAvPjxociAvPgo8 dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNs YXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVm PSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJm Yy5zZWN0aW9uLjEuMyI+PC9hPjxoMz4xLjMuJm5ic3A7CkF1dGhvcml6YXRpb24gR3JhbnQ8L2gz PgoKPHA+CiAgICAgICAgICBBbiBhdXRob3JpemF0aW9uIGdyYW50IGlzIGEgY3JlZGVudGlhbCBy ZXByZXNlbnRpbmcgdGhlIHJlc291cmNlIG93bmVyJ3MgYXV0aG9yaXphdGlvbgogICAgICAgICAg KHRvIGFjY2VzcyBpdHMgcHJvdGVjdGVkIHJlc291cmNlcykgdXNlZCBieSB0aGUgY2xpZW50IHRv IG9idGFpbiBhbiBhY2Nlc3MgdG9rZW4uIFRoaXMKICAgICAgICAgIHNwZWNpZmljYXRpb24gZGVm aW5lcyBmb3VyIGdyYW50IHR5cGVzOiBhdXRob3JpemF0aW9uIGNvZGUsIGltcGxpY2l0LCByZXNv dXJjZSBvd25lcgogICAgICAgICAgcGFzc3dvcmQgY3JlZGVudGlhbHMsIGFuZCBjbGllbnQgY3Jl ZGVudGlhbHMsIGFzIHdlbGwgYXMgYW4gZXh0ZW5zaWJpbGl0eSBtZWNoYW5pc20gZm9yCiAgICAg ICAgICBkZWZpbmluZyBhZGRpdGlvbmFsIHR5cGVzLgogICAgICAgIAo8L3A+CjxhIG5hbWU9ImFu Y2hvcjUiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRp bmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48 dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+ PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi4xLjMuMSI+PC9hPjxoMz4xLjMuMS4m bmJzcDsKQXV0aG9yaXphdGlvbiBDb2RlPC9oMz4KCjxwPgogICAgICAgICAgICBUaGUgYXV0aG9y aXphdGlvbiBjb2RlIGlzIG9idGFpbmVkIGJ5IHVzaW5nIGFuIGF1dGhvcml6YXRpb24gc2VydmVy IGFzIGFuIGludGVybWVkaWFyeQogICAgICAgICAgICBiZXR3ZWVuIHRoZSBjbGllbnQgYW5kIHJl c291cmNlIG93bmVyLiBJbnN0ZWFkIG9mIHJlcXVlc3RpbmcgYXV0aG9yaXphdGlvbiBkaXJlY3Rs eQogICAgICAgICAgICBmcm9tIHRoZSByZXNvdXJjZSBvd25lciwgdGhlIGNsaWVudCBkaXJlY3Rz IHRoZSByZXNvdXJjZSBvd25lciB0byBhbiBhdXRob3JpemF0aW9uCiAgICAgICAgICAgIHNlcnZl ciAodmlhIGl0cyB1c2VyLWFnZW50IGFzIGRlZmluZWQgaW4gPGEgY2xhc3M9J2luZm8nIGhyZWY9 JyNSRkMyNjE2Jz5bUkZDMjYxNl08c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+Rmll bGRpbmcsIFIuLCBHZXR0eXMsIEouLCBNb2d1bCwgSi4sIEZyeXN0eWssIEguLCBNYXNpbnRlciwg TC4sIExlYWNoLCBQLiwgYW5kIFQuIEJlcm5lcnMtTGVlLCAmbGRxdW87SHlwZXJ0ZXh0IFRyYW5z ZmVyIFByb3RvY29sIC0tIEhUVFAvMS4xLCZyZHF1bzsgSnVuZSZuYnNwOzE5OTkuPC9zcGFuPjxz cGFuPik8L3NwYW4+PC9hPiksIHdoaWNoIGluIHR1cm4KICAgICAgICAgICAgZGlyZWN0cyB0aGUg cmVzb3VyY2Ugb3duZXIgYmFjayB0byB0aGUgY2xpZW50IHdpdGggdGhlIGF1dGhvcml6YXRpb24g Y29kZS4KICAgICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgICBCZWZvcmUgZGlyZWN0aW5nIHRo ZSByZXNvdXJjZSBvd25lciBiYWNrIHRvIHRoZSBjbGllbnQgd2l0aCB0aGUgYXV0aG9yaXphdGlv biBjb2RlLCB0aGUKICAgICAgICAgICAgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYXV0aGVudGljYXRl cyB0aGUgcmVzb3VyY2Ugb3duZXIgYW5kIG9idGFpbnMgYXV0aG9yaXphdGlvbi4KICAgICAgICAg ICAgQmVjYXVzZSB0aGUgcmVzb3VyY2Ugb3duZXIgb25seSBhdXRoZW50aWNhdGVzIHdpdGggdGhl IGF1dGhvcml6YXRpb24gc2VydmVyLCB0aGUKICAgICAgICAgICAgcmVzb3VyY2Ugb3duZXIncyBj cmVkZW50aWFscyBhcmUgbmV2ZXIgc2hhcmVkIHdpdGggdGhlIGNsaWVudC4KICAgICAgICAgIAo8 L3A+CjxwPgogICAgICAgICAgICBUaGUgYXV0aG9yaXphdGlvbiBjb2RlIHByb3ZpZGVzIGEgZmV3 IGltcG9ydGFudCBzZWN1cml0eSBiZW5lZml0cyBzdWNoIGFzIHRoZSBhYmlsaXR5CiAgICAgICAg ICAgIHRvIGF1dGhlbnRpY2F0ZSB0aGUgY2xpZW50LCBhbmQgdGhlIHRyYW5zbWlzc2lvbiBvZiB0 aGUgYWNjZXNzIHRva2VuIGRpcmVjdGx5IHRvCiAgICAgICAgICAgIHRoZSBjbGllbnQgd2l0aG91 dCBwYXNzaW5nIGl0IHRocm91Z2ggdGhlIHJlc291cmNlIG93bmVyJ3MgdXNlci1hZ2VudCwgcG90 ZW50aWFsbHkKICAgICAgICAgICAgZXhwb3NpbmcgaXQgdG8gb3RoZXJzLCBpbmNsdWRpbmcgdGhl IHJlc291cmNlIG93bmVyLgogICAgICAgICAgCjwvcD4KPGEgbmFtZT0iYW5jaG9yNiI+PC9hPjxi ciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNw YWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9D YnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+ CjxhIG5hbWU9InJmYy5zZWN0aW9uLjEuMy4yIj48L2E+PGgzPjEuMy4yLiZuYnNwOwpJbXBsaWNp dDwvaDM+Cgo8cD4KICAgICAgICAgICAgVGhlIGltcGxpY2l0IGdyYW50IGlzIGEgc2ltcGxpZmll ZCBhdXRob3JpemF0aW9uIGNvZGUgZmxvdyBvcHRpbWl6ZWQgZm9yIGNsaWVudHMKICAgICAgICAg ICAgaW1wbGVtZW50ZWQgaW4gYSBicm93c2VyIHVzaW5nIGEgc2NyaXB0aW5nIGxhbmd1YWdlIHN1 Y2ggYXMgSmF2YVNjcmlwdC4gSW4gdGhlIGltcGxpY2l0CiAgICAgICAgICAgIGZsb3csIGluc3Rl YWQgb2YgaXNzdWluZyB0aGUgY2xpZW50IGFuIGF1dGhvcml6YXRpb24gY29kZSwgdGhlIGNsaWVu dCBpcyBpc3N1ZWQgYW4KICAgICAgICAgICAgYWNjZXNzIHRva2VuIGRpcmVjdGx5IChhcyB0aGUg cmVzdWx0IG9mIHRoZSByZXNvdXJjZSBvd25lciBhdXRob3JpemF0aW9uKS4gVGhlIGdyYW50CiAg ICAgICAgICAgIHR5cGUgaXMgaW1wbGljaXQgYXMgbm8gaW50ZXJtZWRpYXRlIGNyZWRlbnRpYWxz IChzdWNoIGFzIGFuIGF1dGhvcml6YXRpb24gY29kZSkgYXJlCiAgICAgICAgICAgIGlzc3VlZCAo YW5kIGxhdGVyIHVzZWQgdG8gb2J0YWluIGFuIGFjY2VzcyB0b2tlbikuCiAgICAgICAgICAKPC9w Pgo8cD4KICAgICAgICAgICAgV2hlbiBpc3N1aW5nIGFuIGFjY2VzcyB0b2tlbiBkdXJpbmcgdGhl IGltcGxpY2l0IGdyYW50IGZsb3csIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlcgogICAgICAgICAg ICBkb2VzIG5vdCBhdXRoZW50aWNhdGUgdGhlIGNsaWVudC4gSW4gc29tZSBjYXNlcywgdGhlIGNs aWVudCBpZGVudGl0eSBjYW4gYmUgdmVyaWZpZWQKICAgICAgICAgICAgdmlhIHRoZSByZWRpcmVj dGlvbiBVUkkgdXNlZCB0byBkZWxpdmVyIHRoZSBhY2Nlc3MgdG9rZW4gdG8gdGhlIGNsaWVudC4g VGhlIGFjY2VzcwogICAgICAgICAgICB0b2tlbiBtYXkgYmUgZXhwb3NlZCB0byB0aGUgcmVzb3Vy Y2Ugb3duZXIgb3Igb3RoZXIgYXBwbGljYXRpb25zIHdpdGggYWNjZXNzIHRvIHRoZQogICAgICAg ICAgICByZXNvdXJjZSBvd25lcidzIHVzZXItYWdlbnQuCiAgICAgICAgICAKPC9wPgo8cD4KICAg ICAgICAgICAgSW1wbGljaXQgZ3JhbnRzIGltcHJvdmUgdGhlIHJlc3BvbnNpdmVuZXNzIGFuZCBl ZmZpY2llbmN5IG9mIHNvbWUgY2xpZW50cyAoc3VjaCBhcyBhCiAgICAgICAgICAgIGNsaWVudCBp bXBsZW1lbnRlZCBhcyBhbiBpbi1icm93c2VyIGFwcGxpY2F0aW9uKSBzaW5jZSBpdCByZWR1Y2Vz IHRoZSBudW1iZXIgb2Ygcm91bmQKICAgICAgICAgICAgdHJpcHMgcmVxdWlyZWQgdG8gb2J0YWlu IGFuIGFjY2VzcyB0b2tlbi4gSG93ZXZlciwgdGhpcyBjb252ZW5pZW5jZSBzaG91bGQgYmUgd2Vp Z2hlZAogICAgICAgICAgICBhZ2FpbnN0IHRoZSBzZWN1cml0eSBpbXBsaWNhdGlvbnMgb2YgdXNp bmcgaW1wbGljaXQgZ3JhbnRzLCBlc3BlY2lhbGx5IHdoZW4gdGhlCiAgICAgICAgICAgIGF1dGhv cml6YXRpb24gY29kZSBncmFudCB0eXBlIGlzIGF2YWlsYWJsZS4KICAgICAgICAgIAo8L3A+Cjxh IG5hbWU9ImFuY2hvcjciPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIg Y2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmln aHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7 PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi4xLjMuMyI+PC9hPjxo Mz4xLjMuMy4mbmJzcDsKUmVzb3VyY2UgT3duZXIgUGFzc3dvcmQgQ3JlZGVudGlhbHM8L2gzPgoK PHA+CiAgICAgICAgICAgIFRoZSByZXNvdXJjZSBvd25lciBwYXNzd29yZCBjcmVkZW50aWFscyAo aS5lLiB1c2VybmFtZSBhbmQgcGFzc3dvcmQpIGNhbiBiZSB1c2VkCiAgICAgICAgICAgIGRpcmVj dGx5IGFzIGFuIGF1dGhvcml6YXRpb24gZ3JhbnQgdG8gb2J0YWluIGFuIGFjY2VzcyB0b2tlbi4g VGhlIGNyZWRlbnRpYWxzIHNob3VsZAogICAgICAgICAgICBvbmx5IGJlIHVzZWQgd2hlbiB0aGVy ZSBpcyBhIGhpZ2ggZGVncmVlIG9mIHRydXN0IGJldHdlZW4gdGhlIHJlc291cmNlIG93bmVyIGFu ZCB0aGUKICAgICAgICAgICAgY2xpZW50IChlLmcuIHRoZSBjbGllbnQgaXMgcGFydCBvZiB0aGUg ZGV2aWNlIG9wZXJhdGluZyBzeXN0ZW0gb3IgYSBoaWdobHkgcHJpdmlsZWdlZAogICAgICAgICAg ICBhcHBsaWNhdGlvbiksIGFuZCB3aGVuIG90aGVyIGF1dGhvcml6YXRpb24gZ3JhbnQgdHlwZXMg YXJlIG5vdCBhdmFpbGFibGUgKHN1Y2ggYXMgYW4KICAgICAgICAgICAgYXV0aG9yaXphdGlvbiBj b2RlKS4KICAgICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgICBFdmVuIHRob3VnaCB0aGlzIGdy YW50IHR5cGUgcmVxdWlyZXMgZGlyZWN0IGNsaWVudCBhY2Nlc3MgdG8gdGhlIHJlc291cmNlIG93 bmVyCiAgICAgICAgICAgIGNyZWRlbnRpYWxzLCB0aGUgcmVzb3VyY2Ugb3duZXIgY3JlZGVudGlh bHMgYXJlIHVzZWQgZm9yIGEgc2luZ2xlIHJlcXVlc3QgYW5kIGFyZQogICAgICAgICAgICBleGNo YW5nZWQgZm9yIGFuIGFjY2VzcyB0b2tlbi4gVGhpcyBncmFudCB0eXBlIGNhbiBlbGltaW5hdGUg dGhlIG5lZWQgZm9yIHRoZSBjbGllbnQKICAgICAgICAgICAgdG8gc3RvcmUgdGhlIHJlc291cmNl IG93bmVyIGNyZWRlbnRpYWxzIGZvciBmdXR1cmUgdXNlLCBieSBleGNoYW5naW5nIHRoZSBjcmVk ZW50aWFscwogICAgICAgICAgICB3aXRoIGEgbG9uZy1saXZlZCBhY2Nlc3MgdG9rZW4gb3IgcmVm cmVzaCB0b2tlbi4KICAgICAgICAgIAo8L3A+CjxhIG5hbWU9ImFuY2hvcjgiPjwvYT48YnIgLz48 aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5n PSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+ PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBu YW1lPSJyZmMuc2VjdGlvbi4xLjMuNCI+PC9hPjxoMz4xLjMuNC4mbmJzcDsKQ2xpZW50IENyZWRl bnRpYWxzPC9oMz4KCjxwPgogICAgICAgICAgICBUaGUgY2xpZW50IGNyZWRlbnRpYWxzIChvciBv dGhlciBmb3JtcyBvZiBjbGllbnQgYXV0aGVudGljYXRpb24pIGNhbiBiZSB1c2VkIGFzIGFuCiAg ICAgICAgICAgIGF1dGhvcml6YXRpb24gZ3JhbnQgd2hlbiB0aGUgYXV0aG9yaXphdGlvbiBzY29w ZSBpcyBsaW1pdGVkIHRvIHRoZSBwcm90ZWN0ZWQgcmVzb3VyY2VzCiAgICAgICAgICAgIHVuZGVy IHRoZSBjb250cm9sIG9mIHRoZSBjbGllbnQsIG9yIHRvIHByb3RlY3RlZCByZXNvdXJjZXMgcHJl dmlvdXNseSBhcnJhbmdlZCB3aXRoIHRoZQogICAgICAgICAgICBhdXRob3JpemF0aW9uIHNlcnZl ci4gQ2xpZW50IGNyZWRlbnRpYWxzIGFyZSB1c2VkIGFzIGFuIGF1dGhvcml6YXRpb24gZ3JhbnQg dHlwaWNhbGx5CiAgICAgICAgICAgIHdoZW4gdGhlIGNsaWVudCBpcyBhY3Rpbmcgb24gaXRzIG93 biBiZWhhbGYgKHRoZSBjbGllbnQgaXMgYWxzbyB0aGUgcmVzb3VyY2Ugb3duZXIpLCBvcgogICAg ICAgICAgICBpcyByZXF1ZXN0aW5nIGFjY2VzcyB0byBwcm90ZWN0ZWQgcmVzb3VyY2VzIGJhc2Vk IG9uIGFuIGF1dGhvcml6YXRpb24gcHJldmlvdXNseQogICAgICAgICAgICBhcnJhbmdlZCB3aXRo IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlci4KICAgICAgICAgIAo8L3A+CjxhIG5hbWU9ImFuY2hv cjkiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9 IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQg Y2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90 cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi4xLjQiPjwvYT48aDM+MS40LiZuYnNwOwpB Y2Nlc3MgVG9rZW48L2gzPgoKPHA+CiAgICAgICAgICBBY2Nlc3MgdG9rZW5zIGFyZSBjcmVkZW50 aWFscyB1c2VkIHRvIGFjY2VzcyBwcm90ZWN0ZWQgcmVzb3VyY2VzLiBBbiBhY2Nlc3MgdG9rZW4g aXMgYQogICAgICAgICAgc3RyaW5nIHJlcHJlc2VudGluZyBhbiBhdXRob3JpemF0aW9uIGlzc3Vl ZCB0byB0aGUgY2xpZW50LiBUaGUgc3RyaW5nIGlzIHVzdWFsbHkgb3BhcXVlCiAgICAgICAgICB0 byB0aGUgY2xpZW50LiBUb2tlbnMgcmVwcmVzZW50IHNwZWNpZmljIHNjb3BlcyBhbmQgZHVyYXRp b25zIG9mIGFjY2VzcywgZ3JhbnRlZCBieSB0aGUKICAgICAgICAgIHJlc291cmNlIG93bmVyLCBh bmQgZW5mb3JjZWQgYnkgdGhlIHJlc291cmNlIHNlcnZlciBhbmQgYXV0aG9yaXphdGlvbiBzZXJ2 ZXIuCiAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICBUaGUgdG9rZW4gbWF5IGRlbm90ZSBhbiBp ZGVudGlmaWVyIHVzZWQgdG8gcmV0cmlldmUgdGhlIGF1dGhvcml6YXRpb24gaW5mb3JtYXRpb24s IG9yCiAgICAgICAgICBzZWxmLWNvbnRhaW4gdGhlIGF1dGhvcml6YXRpb24gaW5mb3JtYXRpb24g aW4gYSB2ZXJpZmlhYmxlIG1hbm5lciAoaS5lLiBhIHRva2VuIHN0cmluZwogICAgICAgICAgY29u c2lzdGluZyBvZiBzb21lIGRhdGEgYW5kIGEgc2lnbmF0dXJlKS4gQWRkaXRpb25hbCBhdXRoZW50 aWNhdGlvbiBjcmVkZW50aWFscywgd2hpY2gKICAgICAgICAgIGFyZSBiZXlvbmQgdGhlIHNjb3Bl IG9mIHRoaXMgc3BlY2lmaWNhdGlvbiwgbWF5IGJlIHJlcXVpcmVkIGluIG9yZGVyIGZvciB0aGUg Y2xpZW50IHRvCiAgICAgICAgICB1c2UgYSB0b2tlbi4KICAgICAgICAKPC9wPgo8cD4KICAgICAg ICAgIFRoZSBhY2Nlc3MgdG9rZW4gcHJvdmlkZXMgYW4gYWJzdHJhY3Rpb24gbGF5ZXIsIHJlcGxh Y2luZyBkaWZmZXJlbnQgYXV0aG9yaXphdGlvbgogICAgICAgICAgY29uc3RydWN0cyAoZS5nLiB1 c2VybmFtZSBhbmQgcGFzc3dvcmQpIHdpdGggYSBzaW5nbGUgdG9rZW4gdW5kZXJzdG9vZCBieSB0 aGUgcmVzb3VyY2UKICAgICAgICAgIHNlcnZlci4gVGhpcyBhYnN0cmFjdGlvbiBlbmFibGVzIGlz c3VpbmcgYWNjZXNzIHRva2VucyBtb3JlIHJlc3RyaWN0aXZlIHRoYW4gdGhlCiAgICAgICAgICBh dXRob3JpemF0aW9uIGdyYW50IHVzZWQgdG8gb2J0YWluIHRoZW0sIGFzIHdlbGwgYXMgcmVtb3Zp bmcgdGhlIHJlc291cmNlIHNlcnZlcidzIG5lZWQgdG8KICAgICAgICAgIHVuZGVyc3RhbmQgYSB3 aWRlIHJhbmdlIG9mIGF1dGhlbnRpY2F0aW9uIG1ldGhvZHMuCiAgICAgICAgCjwvcD4KPHA+CiAg ICAgICAgICBBY2Nlc3MgdG9rZW5zIGNhbiBoYXZlIGRpZmZlcmVudCBmb3JtYXRzLCBzdHJ1Y3R1 cmVzLCBhbmQgbWV0aG9kcyBvZiB1dGlsaXphdGlvbiAoZS5nLgogICAgICAgICAgY3J5cHRvZ3Jh cGhpYyBwcm9wZXJ0aWVzKSBiYXNlZCBvbiB0aGUgcmVzb3VyY2Ugc2VydmVyIHNlY3VyaXR5IHJl cXVpcmVtZW50cy4gQWNjZXNzIHRva2VuCiAgICAgICAgICBhdHRyaWJ1dGVzIGFuZCB0aGUgbWV0 aG9kcyB1c2VkIHRvIGFjY2VzcyBwcm90ZWN0ZWQgcmVzb3VyY2VzIGFyZSBiZXlvbmQgdGhlIHNj b3BlIG9mIHRoaXMKICAgICAgICAgIHNwZWNpZmljYXRpb24gYW5kIGFyZSBkZWZpbmVkIGJ5IGNv bXBhbmlvbiBzcGVjaWZpY2F0aW9ucy4KICAgICAgICAKPC9wPgo8YSBuYW1lPSJhbmNob3IxMCI+ PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIg Y2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFz cz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwv dGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLjEuNSI+PC9hPjxoMz4xLjUuJm5ic3A7ClJlZnJl c2ggVG9rZW48L2gzPgoKPHA+CiAgICAgICAgICBSZWZyZXNoIHRva2VucyBhcmUgY3JlZGVudGlh bHMgdXNlZCB0byBvYnRhaW4gYWNjZXNzIHRva2Vucy4gUmVmcmVzaCB0b2tlbnMgYXJlIGlzc3Vl ZCB0bwogICAgICAgICAgdGhlIGNsaWVudCBieSB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYW5k IGFyZSB1c2VkIHRvIG9idGFpbiBhIG5ldyBhY2Nlc3MgdG9rZW4gd2hlbiB0aGUKICAgICAgICAg IGN1cnJlbnQgYWNjZXNzIHRva2VuIGJlY29tZXMgaW52YWxpZCBvciBleHBpcmVzLCBvciB0byBv YnRhaW4gYWRkaXRpb25hbCBhY2Nlc3MgdG9rZW5zCiAgICAgICAgICB3aXRoIGlkZW50aWNhbCBv ciBuYXJyb3dlciBzY29wZSAoYWNjZXNzIHRva2VucyBtYXkgaGF2ZSBhIHNob3J0ZXIgbGlmZXRp bWUgYW5kIGZld2VyCiAgICAgICAgICBwZXJtaXNzaW9ucyB0aGFuIGF1dGhvcml6ZWQgYnkgdGhl IHJlc291cmNlIG93bmVyKS4gSXNzdWluZyBhIHJlZnJlc2ggdG9rZW4gaXMgb3B0aW9uYWwKICAg ICAgICAgIGF0IHRoZSBkaXNjcmV0aW9uIG9mIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlci4gSWYg dGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGlzc3VlcyBhCiAgICAgICAgICByZWZyZXNoIHRva2Vu LCBpdCBpcyBpbmNsdWRlZCB3aGVuIGlzc3VpbmcgYW4gYWNjZXNzIHRva2VuIChpLmUuIHN0ZXAg KEQpIGluCiAgICAgICAgICA8YSBjbGFzcz0naW5mbycgaHJlZj0nI0ZpZ3VyZS0xJz5GaWd1cmUm bmJzcDsxPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkFic3RyYWN0IFByb3RvY29s IEZsb3c8L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+KS4KICAgICAgICAKPC9wPgo8cD4KICAgICAg ICAgIEEgcmVmcmVzaCB0b2tlbiBpcyBhIHN0cmluZyByZXByZXNlbnRpbmcgdGhlIGF1dGhvcml6 YXRpb24gZ3JhbnRlZCB0byB0aGUgY2xpZW50IGJ5IHRoZQogICAgICAgICAgcmVzb3VyY2Ugb3du ZXIuIFRoZSBzdHJpbmcgaXMgdXN1YWxseSBvcGFxdWUgdG8gdGhlIGNsaWVudC4gVGhlIHRva2Vu IGRlbm90ZXMgYW4KICAgICAgICAgIGlkZW50aWZpZXIgdXNlZCB0byByZXRyaWV2ZSB0aGUgYXV0 aG9yaXphdGlvbiBpbmZvcm1hdGlvbi4gVW5saWtlIGFjY2VzcyB0b2tlbnMsIHJlZnJlc2gKICAg ICAgICAgIHRva2VucyBhcmUgaW50ZW5kZWQgZm9yIHVzZSBvbmx5IHdpdGggYXV0aG9yaXphdGlv biBzZXJ2ZXJzIGFuZCBhcmUgbmV2ZXIgc2VudCB0bwogICAgICAgICAgcmVzb3VyY2Ugc2VydmVy cy4KICAgICAgICAKPC9wPjxiciAvPjxociBjbGFzcz0iaW5zZXJ0IiAvPgo8YSBuYW1lPSJGaWd1 cmUtMiI+PC9hPgo8ZGl2IHN0eWxlPSdkaXNwbGF5OiB0YWJsZTsgd2lkdGg6IDA7IG1hcmdpbi1s ZWZ0OiAzZW07IG1hcmdpbi1yaWdodDogYXV0byc+PHByZT4KCiAgKy0tLS0tLS0tKyAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tKwogIHwg ICAgICAgIHwtLShBKS0tLS0tLS0gQXV0aG9yaXphdGlvbiBHcmFudCAtLS0tLS0tLS0mZ3Q7fCAg ICAgICAgICAgICAgIHwKICB8ICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHwgICAgICAgICAgICAgICB8CiAgfCAgICAgICAgfCZsdDstKEIpLS0tLS0t LS0tLS0gQWNjZXNzIFRva2VuIC0tLS0tLS0tLS0tLS18ICAgICAgICAgICAgICAgfAogIHwgICAg ICAgIHwgICAgICAgICAgICAgICAmYW1wOyBSZWZyZXNoIFRva2VuICAgICAgICAgICAgIHwgICAg ICAgICAgICAgICB8CiAgfCAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB8ICAgICAgICAgICAgICAgfAogIHwgICAgICAgIHwgICAgICAgICAgICAgICAg ICAgICAgICAgICAgKy0tLS0tLS0tLS0rICAgfCAgICAgICAgICAgICAgIHwKICB8ICAgICAgICB8 LS0oQyktLS0tIEFjY2VzcyBUb2tlbiAtLS0tJmd0O3wgICAgICAgICAgfCAgIHwgICAgICAgICAg ICAgICB8CiAgfCAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAg IHwgICB8ICAgICAgICAgICAgICAgfAogIHwgICAgICAgIHwmbHQ7LShEKS0gUHJvdGVjdGVkIFJl c291cmNlIC0tfCBSZXNvdXJjZSB8ICAgfCBBdXRob3JpemF0aW9uIHwKICB8IENsaWVudCB8ICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHwgIFNlcnZlciAgfCAgIHwgICAgIFNlcnZlciAgICB8 CiAgfCAgICAgICAgfC0tKEUpLS0tLSBBY2Nlc3MgVG9rZW4gLS0tLSZndDt8ICAgICAgICAgIHwg ICB8ICAgICAgICAgICAgICAgfAogIHwgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAg ICAgfCAgICAgICAgICB8ICAgfCAgICAgICAgICAgICAgIHwKICB8ICAgICAgICB8Jmx0Oy0oRikt IEludmFsaWQgVG9rZW4gRXJyb3IgLXwgICAgICAgICAgfCAgIHwgICAgICAgICAgICAgICB8CiAg fCAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLSsgICB8ICAg ICAgICAgICAgICAgfAogIHwgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgfCAgICAgICAgICAgICAgIHwKICB8ICAgICAgICB8LS0oRyktLS0tLS0tLS0t LSBSZWZyZXNoIFRva2VuIC0tLS0tLS0tLS0tJmd0O3wgICAgICAgICAgICAgICB8CiAgfCAgICAg ICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAg ICAgICAgfAogIHwgICAgICAgIHwmbHQ7LShIKS0tLS0tLS0tLS0tIEFjY2VzcyBUb2tlbiAtLS0t LS0tLS0tLS0tfCAgICAgICAgICAgICAgIHwKICArLS0tLS0tLS0rICAgICAgICAgICAmYW1wOyBP cHRpb25hbCBSZWZyZXNoIFRva2VuICAgICAgICArLS0tLS0tLS0tLS0tLS0tKwoKPC9wcmU+PC9k aXY+PHRhYmxlIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBhbGln bj0iY2VudGVyIj48dHI+PHRkIGFsaWduPSJjZW50ZXIiPjxmb250IGZhY2U9Im1vbmFjbywgTVMg U2FucyBTZXJpZiIgc2l6ZT0iMSI+PGI+Jm5ic3A7RmlndXJlJm5ic3A7MjogUmVmcmVzaGluZyBh biBFeHBpcmVkIEFjY2VzcyBUb2tlbiZuYnNwOzwvYj48L2ZvbnQ+PGJyIC8+PC90ZD48L3RyPjwv dGFibGU+PGhyIGNsYXNzPSJpbnNlcnQiIC8+Cgo8cD4KICAgICAgICAgIFRoZSBmbG93IGlsbHVz dHJhdGVkIGluIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjRmlndXJlLTInPkZpZ3VyZSZuYnNwOzI8 c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+UmVmcmVzaGluZyBhbiBFeHBpcmVkIEFj Y2VzcyBUb2tlbjwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4gaW5jbHVkZXMgdGhlIGZvbGxvd2lu ZyBzdGVwczoKICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgIDwvcD4KPGJsb2NrcXVvdGUgY2xh c3M9InRleHQiPjxkbD4KPGR0PihBKTwvZHQ+CjxkZD4KICAgICAgICAgICAgICBUaGUgY2xpZW50 IHJlcXVlc3RzIGFuIGFjY2VzcyB0b2tlbiBieSBhdXRoZW50aWNhdGluZyB3aXRoIHRoZSBhdXRo b3JpemF0aW9uIHNlcnZlciwKICAgICAgICAgICAgICBhbmQgcHJlc2VudGluZyBhbiBhdXRob3Jp emF0aW9uIGdyYW50LgogICAgICAgICAgICAKPC9kZD4KPGR0PihCKTwvZHQ+CjxkZD4KICAgICAg ICAgICAgICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYXV0aGVudGljYXRlcyB0aGUgY2xpZW50 IGFuZCB2YWxpZGF0ZXMgdGhlIGF1dGhvcml6YXRpb24KICAgICAgICAgICAgICBncmFudCwgYW5k IGlmIHZhbGlkIGlzc3VlcyBhbiBhY2Nlc3MgdG9rZW4gYW5kIGEgcmVmcmVzaCB0b2tlbi4KICAg ICAgICAgICAgCjwvZGQ+CjxkdD4oQyk8L2R0Pgo8ZGQ+CiAgICAgICAgICAgICAgVGhlIGNsaWVu dCBtYWtlcyBhIHByb3RlY3RlZCByZXNvdXJjZSByZXF1ZXN0IHRvIHRoZSByZXNvdXJjZSBzZXJ2 ZXIgYnkgcHJlc2VudGluZwogICAgICAgICAgICAgIHRoZSBhY2Nlc3MgdG9rZW4uCiAgICAgICAg ICAgIAo8L2RkPgo8ZHQ+KEQpPC9kdD4KPGRkPgogICAgICAgICAgICAgIFRoZSByZXNvdXJjZSBz ZXJ2ZXIgdmFsaWRhdGVzIHRoZSBhY2Nlc3MgdG9rZW4sIGFuZCBpZiB2YWxpZCwgc2VydmVzIHRo ZSByZXF1ZXN0LgogICAgICAgICAgICAKPC9kZD4KPGR0PihFKTwvZHQ+CjxkZD4KICAgICAgICAg ICAgICBTdGVwcyAoQykgYW5kIChEKSByZXBlYXQgdW50aWwgdGhlIGFjY2VzcyB0b2tlbiBleHBp cmVzLiBJZiB0aGUgY2xpZW50IGtub3dzIHRoZQogICAgICAgICAgICAgIGFjY2VzcyB0b2tlbiBl eHBpcmVkLCBpdCBza2lwcyB0byBzdGVwIChHKSwgb3RoZXJ3aXNlIGl0IG1ha2VzIGFub3RoZXIg cHJvdGVjdGVkCiAgICAgICAgICAgICAgcmVzb3VyY2UgcmVxdWVzdC4KICAgICAgICAgICAgCjwv ZGQ+CjxkdD4oRik8L2R0Pgo8ZGQ+CiAgICAgICAgICAgICAgU2luY2UgdGhlIGFjY2VzcyB0b2tl biBpcyBpbnZhbGlkLCB0aGUgcmVzb3VyY2Ugc2VydmVyIHJldHVybnMgYW4gaW52YWxpZCB0b2tl bgogICAgICAgICAgICAgIGVycm9yLgogICAgICAgICAgICAKPC9kZD4KPGR0PihHKTwvZHQ+Cjxk ZD4KICAgICAgICAgICAgICBUaGUgY2xpZW50IHJlcXVlc3RzIGEgbmV3IGFjY2VzcyB0b2tlbiBi eSBhdXRoZW50aWNhdGluZyB3aXRoIHRoZSBhdXRob3JpemF0aW9uCiAgICAgICAgICAgICAgc2Vy dmVyIGFuZCBwcmVzZW50aW5nIHRoZSByZWZyZXNoIHRva2VuLiBUaGUgY2xpZW50IGF1dGhlbnRp Y2F0aW9uIHJlcXVpcmVtZW50cyBhcmUKICAgICAgICAgICAgICBiYXNlZCBvbiB0aGUgY2xpZW50 IHR5cGUgYW5kIG9uIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBwb2xpY2llcy4KICAgICAgICAg ICAgCjwvZGQ+CjxkdD4oSCk8L2R0Pgo8ZGQ+CiAgICAgICAgICAgICAgVGhlIGF1dGhvcml6YXRp b24gc2VydmVyIGF1dGhlbnRpY2F0ZXMgdGhlIGNsaWVudCBhbmQgdmFsaWRhdGVzIHRoZSByZWZy ZXNoIHRva2VuLAogICAgICAgICAgICAgIGFuZCBpZiB2YWxpZCBpc3N1ZXMgYSBuZXcgYWNjZXNz IHRva2VuIChhbmQgb3B0aW9uYWxseSwgYSBuZXcgcmVmcmVzaCB0b2tlbikuCiAgICAgICAgICAg IAo8L2RkPgo8L2RsPjwvYmxvY2txdW90ZT48cD4KICAgICAgICAKPC9wPgo8cD4KICAgICAgICAg IFN0ZXBzIEMsIEQsIEUsIGFuZCBGIGFyZSBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIHNwZWNp ZmljYXRpb24gYXMgZGVzY3JpYmVkIGluCiAgICAgICAgICA8YSBjbGFzcz0naW5mbycgaHJlZj0n I2FjY2Vzcy1yZXNvdXJjZSc+U2VjdGlvbiZuYnNwOzc8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFz cz0naW5mbyc+QWNjZXNzaW5nIFByb3RlY3RlZCBSZXNvdXJjZXM8L3NwYW4+PHNwYW4+KTwvc3Bh bj48L2E+LgogICAgICAgIAo8L3A+CjxhIG5hbWU9InRscyI+PC9hPjxiciAvPjxociAvPgo8dGFi bGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNz PSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIj dG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5z ZWN0aW9uLjEuNiI+PC9hPjxoMz4xLjYuJm5ic3A7ClRMUyBWZXJzaW9uPC9oMz4KCjxwPgogICAg ICAgICAgV2hlbmV2ZXIgVExTIGlzIHVzZWQgYnkgdGhpcyBzcGVjaWZpY2F0aW9uLCB0aGUgYXBw cm9wcmlhdGUgdmVyc2lvbiAob3IgdmVyc2lvbnMpIG9mCiAgICAgICAgICBUTFMgd2lsbCB2YXJ5 IG92ZXIgdGltZSwgYmFzZWQgb24gdGhlIHdpZGVzcHJlYWQgZGVwbG95bWVudCBhbmQga25vd24g c2VjdXJpdHkKICAgICAgICAgIHZ1bG5lcmFiaWxpdGllcy4gQXQgdGhlIHRpbWUgb2YgdGhpcyB3 cml0aW5nLCBUTFMgdmVyc2lvbiAxLjIgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNSRkM1MjQ2Jz5b UkZDNTI0Nl08c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+RGllcmtzLCBULiBhbmQg RS4gUmVzY29ybGEsICZsZHF1bztUaGUgVHJhbnNwb3J0IExheWVyIFNlY3VyaXR5IChUTFMpIFBy b3RvY29sIFZlcnNpb24gMS4yLCZyZHF1bzsgQXVndXN0Jm5ic3A7MjAwOC48L3NwYW4+PHNwYW4+ KTwvc3Bhbj48L2E+CiAgICAgICAgICBpcyB0aGUgbW9zdCByZWNlbnQgdmVyc2lvbiwgYnV0IGhh cyBhIHZlcnkgbGltaXRlZCBkZXBsb3ltZW50IGJhc2UgYW5kIG1pZ2h0IG5vdCBiZQogICAgICAg ICAgcmVhZGlseSBhdmFpbGFibGUgZm9yIGltcGxlbWVudGF0aW9uLiBUTFMgdmVyc2lvbiAxLjAg PGEgY2xhc3M9J2luZm8nIGhyZWY9JyNSRkMyMjQ2Jz5bUkZDMjI0Nl08c3Bhbj4gKDwvc3Bhbj48 c3BhbiBjbGFzcz0naW5mbyc+RGllcmtzLCBULiBhbmQgQy4gQWxsZW4sICZsZHF1bztUaGUgVExT IFByb3RvY29sIFZlcnNpb24gMS4wLCZyZHF1bzsgSmFudWFyeSZuYnNwOzE5OTkuPC9zcGFuPjxz cGFuPik8L3NwYW4+PC9hPiBpcyB0aGUKICAgICAgICAgIG1vc3Qgd2lkZWx5IGRlcGxveWVkIHZl cnNpb24sIGFuZCB3aWxsIHByb3ZpZGUgdGhlIGJyb2FkZXN0IGludGVyb3BlcmFiaWxpdHkuCiAg ICAgICAgCjwvcD4KPHA+CiAgICAgICAgICBJbXBsZW1lbnRhdGlvbnMgTUFZIGFsc28gc3VwcG9y dCBhZGRpdGlvbmFsIHRyYW5zcG9ydC1sYXllciBzZWN1cml0eSBtZWNoYW5pc21zCiAgICAgICAg ICB0aGF0IG1lZXQgdGhlaXIgc2VjdXJpdHkgcmVxdWlyZW1lbnRzLgogICAgICAgIAo8L3A+Cjxh IG5hbWU9ImFuY2hvcjExIj48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQi IGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJp Z2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNw OzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uMS43Ij48L2E+PGgz PjEuNy4mbmJzcDsKSFRUUCBSZWRpcmVjdGlvbnM8L2gzPgoKPHA+CiAgICAgICAgICBUaGlzIHNw ZWNpZmljYXRpb24gbWFrZXMgZXh0ZW5zaXZlIHVzZSBvZiBIVFRQIHJlZGlyZWN0aW9ucywgaW4g d2hpY2ggdGhlIGNsaWVudCBvciB0aGUKICAgICAgICAgIGF1dGhvcml6YXRpb24gc2VydmVyIGRp cmVjdCB0aGUgcmVzb3VyY2Ugb3duZXIncyB1c2VyLWFnZW50IHRvIGFub3RoZXIgZGVzdGluYXRp b24uIFdoaWxlCiAgICAgICAgICB0aGUgZXhhbXBsZXMgaW4gdGhpcyBzcGVjaWZpY2F0aW9uIHNo b3cgdGhlIHVzZSBvZiB0aGUgSFRUUCAzMDIgc3RhdHVzIGNvZGUsIGFueSBvdGhlcgogICAgICAg ICAgbWV0aG9kIGF2YWlsYWJsZSB2aWEgdGhlIHVzZXItYWdlbnQgdG8gYWNjb21wbGlzaCB0aGlz IHJlZGlyZWN0aW9uIGlzIGFsbG93ZWQgYW5kIGlzCiAgICAgICAgICBjb25zaWRlcmVkIHRvIGJl IGFuIGltcGxlbWVudGF0aW9uIGRldGFpbC4KICAgICAgICAKPC9wPgo8YSBuYW1lPSJhbmNob3Ix MiI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0i MCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBj bGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3Ry PjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLjEuOCI+PC9hPjxoMz4xLjguJm5ic3A7Cklu dGVyb3BlcmFiaWxpdHk8L2gzPgoKPHA+CiAgICAgICAgICBPQXV0aCAyLjAgcHJvdmlkZXMgYSBy aWNoIGF1dGhvcml6YXRpb24gZnJhbWV3b3JrIHdpdGggd2VsbC1kZWZpbmVkIHNlY3VyaXR5IHBy b3BlcnRpZXMuCiAgICAgICAgICBIb3dldmVyLCBhcyBhIHJpY2ggYW5kIGhpZ2hseSBleHRlbnNp YmxlIGZyYW1ld29yayB3aXRoIG1hbnkgb3B0aW9uYWwgY29tcG9uZW50cywgb24gaXRzCiAgICAg ICAgICBvd24sIHRoaXMgc3BlY2lmaWNhdGlvbiBpcyBsaWtlbHkgdG8gcHJvZHVjZSBhIHdpZGUg cmFuZ2Ugb2Ygbm9uLWludGVyb3BlcmFibGUKICAgICAgICAgIGltcGxlbWVudGF0aW9ucy4KICAg ICAgICAKPC9wPgo8cD4KICAgICAgICAgIEluIGFkZGl0aW9uLCB0aGlzIHNwZWNpZmljYXRpb24g bGVhdmVzIGEgZmV3IHJlcXVpcmVkIGNvbXBvbmVudHMgcGFydGlhbGx5IG9yIGZ1bGx5CiAgICAg ICAgICB1bmRlZmluZWQgKGUuZy4gY2xpZW50IHJlZ2lzdHJhdGlvbiwgYXV0aG9yaXphdGlvbiBz ZXJ2ZXIgY2FwYWJpbGl0aWVzLCBlbmRwb2ludAogICAgICAgICAgZGlzY292ZXJ5KS4gV2l0aG91 dCB0aGVzZSBjb21wb25lbnRzLCBjbGllbnRzIG11c3QgYmUgbWFudWFsbHkgYW5kIHNwZWNpZmlj YWxseQogICAgICAgICAgY29uZmlndXJlZCBhZ2FpbnN0IGEgc3BlY2lmaWMgYXV0aG9yaXphdGlv biBzZXJ2ZXIgYW5kIHJlc291cmNlIHNlcnZlciBpbiBvcmRlciB0bwogICAgICAgICAgaW50ZXJv cGVyYXRlLgogICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgVGhpcyBmcmFtZXdvcmsgd2FzIGRl c2lnbmVkIHdpdGggdGhlIGNsZWFyIGV4cGVjdGF0aW9uIHRoYXQgZnV0dXJlIHdvcmsgd2lsbCBk ZWZpbmUKICAgICAgICAgIHByZXNjcmlwdGl2ZSBwcm9maWxlcyBhbmQgZXh0ZW5zaW9ucyBuZWNl c3NhcnkgdG8gYWNoaWV2ZSBmdWxsIHdlYi1zY2FsZQogICAgICAgICAgaW50ZXJvcGVyYWJpbGl0 eS4KICAgICAgICAKPC9wPgo8YSBuYW1lPSJhbmNob3IxMyI+PC9hPjxiciAvPjxociAvPgo8dGFi bGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNz PSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIj dG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5z ZWN0aW9uLjEuOSI+PC9hPjxoMz4xLjkuJm5ic3A7Ck5vdGF0aW9uYWwgQ29udmVudGlvbnM8L2gz PgoKPHA+CiAgICAgICAgICBUaGUga2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJ UkVEIiwgIlNIQUxMIiwgIlNIQUxMIE5PVCIsICJTSE9VTEQiLCAiU0hPVUxECiAgICAgICAgICBO T1QiLCAiUkVDT01NRU5ERUQiLCAiTUFZIiwgYW5kICJPUFRJT05BTCIgaW4gdGhpcyBzcGVjaWZp Y2F0aW9uIGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcwogICAgICAgICAgZGVzY3JpYmVkIGluIDxh IGNsYXNzPSdpbmZvJyBocmVmPScjUkZDMjExOSc+W1JGQzIxMTldPHNwYW4+ICg8L3NwYW4+PHNw YW4gY2xhc3M9J2luZm8nPkJyYWRuZXIsIFMuLCAmbGRxdW87S2V5IHdvcmRzIGZvciB1c2UgaW4g UkZDcyB0byBJbmRpY2F0ZSBSZXF1aXJlbWVudCBMZXZlbHMsJnJkcXVvOyBNYXJjaCZuYnNwOzE5 OTcuPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPi4KICAgICAgICAKPC9wPgo8cD4KICAgICAgICAg IFRoaXMgc3BlY2lmaWNhdGlvbiB1c2VzIHRoZSBBdWdtZW50ZWQgQmFja3VzLU5hdXIgRm9ybSAo QUJORikgbm90YXRpb24gb2YKICAgICAgICAgIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjUkZDNTIz NCc+W1JGQzUyMzRdPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkNyb2NrZXIsIEQu IGFuZCBQLiBPdmVyZWxsLCAmbGRxdW87QXVnbWVudGVkIEJORiBmb3IgU3ludGF4IFNwZWNpZmlj YXRpb25zOiBBQk5GLCZyZHF1bzsgSmFudWFyeSZuYnNwOzIwMDguPC9zcGFuPjxzcGFuPik8L3Nw YW4+PC9hPi4KCSAgQWRkaXRpb25hbGx5LCB0aGUgcnVsZSBVUkktUmVmZXJlbmNlIGlzIGluY2x1 ZGVkIGZyb20KCSAgVW5pZm9ybSBSZXNvdXJjZSBJZGVudGlmaWVyIChVUkkpIDxhIGNsYXNzPSdp bmZvJyBocmVmPScjUkZDMzk4Nic+W1JGQzM5ODZdPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9 J2luZm8nPkJlcm5lcnMtTGVlLCBULiwgRmllbGRpbmcsIFIuLCBhbmQgTC4gTWFzaW50ZXIsICZs ZHF1bztVbmlmb3JtIFJlc291cmNlIElkZW50aWZpZXIgKFVSSSk6IEdlbmVyaWMgU3ludGF4LCZy ZHF1bzsgSmFudWFyeSZuYnNwOzIwMDUuPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPi4KICAgICAg ICAKPC9wPgo8cD4KICAgICAgICAgIENlcnRhaW4gc2VjdXJpdHktcmVsYXRlZCB0ZXJtcyBhcmUg dG8gYmUgdW5kZXJzdG9vZCBpbiB0aGUgc2Vuc2UgZGVmaW5lZCBpbgogICAgICAgICAgPGEgY2xh c3M9J2luZm8nIGhyZWY9JyNSRkM0OTQ5Jz5bUkZDNDk0OV08c3Bhbj4gKDwvc3Bhbj48c3BhbiBj bGFzcz0naW5mbyc+U2hpcmV5LCBSLiwgJmxkcXVvO0ludGVybmV0IFNlY3VyaXR5IEdsb3NzYXJ5 LCBWZXJzaW9uIDIsJnJkcXVvOyBBdWd1c3QmbmJzcDsyMDA3Ljwvc3Bhbj48c3Bhbj4pPC9zcGFu PjwvYT4uIFRoZXNlIHRlcm1zIGluY2x1ZGUsIGJ1dCBhcmUgbm90IGxpbWl0ZWQgdG8sICJhdHRh Y2siLAogICAgICAgICAgImF1dGhlbnRpY2F0aW9uIiwgImF1dGhvcml6YXRpb24iLCAiY2VydGlm aWNhdGUiLCAiY29uZmlkZW50aWFsaXR5IiwgImNyZWRlbnRpYWwiLAogICAgICAgICAgImVuY3J5 cHRpb24iLCAiaWRlbnRpdHkiLCAic2lnbiIsICJzaWduYXR1cmUiLCAidHJ1c3QiLCAidmFsaWRh dGUiLCBhbmQgInZlcmlmeSIuCiAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICBVbmxlc3Mgb3Ro ZXJ3aXNlIG5vdGVkLCBhbGwgdGhlIHByb3RvY29sIHBhcmFtZXRlciBuYW1lcyBhbmQgdmFsdWVz IGFyZSBjYXNlIHNlbnNpdGl2ZS4KICAgICAgICAKPC9wPgo8YSBuYW1lPSJhbmNob3IxNCI+PC9h PjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2Vs bHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0i VE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFi bGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLjIiPjwvYT48aDM+Mi4mbmJzcDsKQ2xpZW50IFJlZ2lz dHJhdGlvbjwvaDM+Cgo8cD4KICAgICAgICBCZWZvcmUgaW5pdGlhdGluZyB0aGUgcHJvdG9jb2ws IHRoZSBjbGllbnQgcmVnaXN0ZXJzIHdpdGggdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLiBUaGUK ICAgICAgICBtZWFucyB0aHJvdWdoIHdoaWNoIHRoZSBjbGllbnQgcmVnaXN0ZXJzIHdpdGggdGhl IGF1dGhvcml6YXRpb24gc2VydmVyIGFyZSBiZXlvbmQgdGhlCiAgICAgICAgc2NvcGUgb2YgdGhp cyBzcGVjaWZpY2F0aW9uLCBidXQgdHlwaWNhbGx5IGludm9sdmUgZW5kLXVzZXIgaW50ZXJhY3Rp b24gd2l0aCBhbiBIVE1MCiAgICAgICAgcmVnaXN0cmF0aW9uIGZvcm0uCiAgICAgIAo8L3A+Cjxw PgogICAgICAgIENsaWVudCByZWdpc3RyYXRpb24gZG9lcyBub3QgcmVxdWlyZSBhIGRpcmVjdCBp bnRlcmFjdGlvbiBiZXR3ZWVuIHRoZSBjbGllbnQgYW5kIHRoZQogICAgICAgIGF1dGhvcml6YXRp b24gc2VydmVyLiBXaGVuIHN1cHBvcnRlZCBieSB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIsIHJl Z2lzdHJhdGlvbiBjYW4gcmVseQogICAgICAgIG9uIG90aGVyIG1lYW5zIGZvciBlc3RhYmxpc2hp bmcgdHJ1c3QgYW5kIG9idGFpbmluZyB0aGUgcmVxdWlyZWQgY2xpZW50IHByb3BlcnRpZXMgKGUu Zy4KICAgICAgICByZWRpcmVjdGlvbiBVUkksIGNsaWVudCB0eXBlKS4gRm9yIGV4YW1wbGUsIHJl Z2lzdHJhdGlvbiBjYW4gYmUgYWNjb21wbGlzaGVkIHVzaW5nIGEKICAgICAgICBzZWxmLWlzc3Vl ZCBvciB0aGlyZC1wYXJ0eS1pc3N1ZWQgYXNzZXJ0aW9uLCBvciBieSB0aGUgYXV0aG9yaXphdGlv biBzZXJ2ZXIgcGVyZm9ybWluZwogICAgICAgIGNsaWVudCBkaXNjb3ZlcnkgdXNpbmcgYSB0cnVz dGVkIGNoYW5uZWwuCiAgICAgIAo8L3A+CjxwPgogICAgICAgIFdoZW4gcmVnaXN0ZXJpbmcgYSBj bGllbnQsIHRoZSBjbGllbnQgZGV2ZWxvcGVyIFNIQUxMOgogICAgICAKPC9wPgo8cD4KICAgICAg ICA8L3A+Cjx1bCBjbGFzcz0idGV4dCI+CjxsaT4KICAgICAgICAgICAgc3BlY2lmeSB0aGUgY2xp ZW50IHR5cGUgYXMgZGVzY3JpYmVkIGluIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjY2xpZW50LXR5 cGVzJz5TZWN0aW9uJm5ic3A7Mi4xPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkNs aWVudCBUeXBlczwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4sCiAgICAgICAgICAKPC9saT4KPGxp PgogICAgICAgICAgICBwcm92aWRlIGl0cyBjbGllbnQgcmVkaXJlY3Rpb24gVVJJcyBhcyBkZXNj cmliZWQgaW4KICAgICAgICAgICAgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNyZWRpcmVjdC11cmkn PlNlY3Rpb24mbmJzcDszLjEuMjxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5SZWRp cmVjdGlvbiBFbmRwb2ludDwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4sIGFuZAogICAgICAgICAg CjwvbGk+CjxsaT4KICAgICAgICAgICAgaW5jbHVkZSBhbnkgb3RoZXIgaW5mb3JtYXRpb24gcmVx dWlyZWQgYnkgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIChlLmcuIGFwcGxpY2F0aW9uCiAgICAg ICAgICAgIG5hbWUsIHdlYnNpdGUsIGRlc2NyaXB0aW9uLCBsb2dvIGltYWdlLCB0aGUgYWNjZXB0 YW5jZSBvZiBsZWdhbCB0ZXJtcykuCiAgICAgICAgICAKPC9saT4KPC91bD48cD4KICAgICAgCjwv cD4KPGEgbmFtZT0iY2xpZW50LXR5cGVzIj48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5 PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIg YWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNw O1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uMi4x Ij48L2E+PGgzPjIuMS4mbmJzcDsKQ2xpZW50IFR5cGVzPC9oMz4KCjxwPgogICAgICAgICAgT0F1 dGggZGVmaW5lcyB0d28gY2xpZW50IHR5cGVzLCBiYXNlZCBvbiB0aGVpciBhYmlsaXR5IHRvIGF1 dGhlbnRpY2F0ZSBzZWN1cmVseSB3aXRoIHRoZQogICAgICAgICAgYXV0aG9yaXphdGlvbiBzZXJ2 ZXIgKGkuZS4gYWJpbGl0eSB0byBtYWludGFpbiB0aGUgY29uZmlkZW50aWFsaXR5IG9mIHRoZWly IGNsaWVudAogICAgICAgICAgY3JlZGVudGlhbHMpOgogICAgICAgIAo8L3A+CjxwPgogICAgICAg ICAgPC9wPgo8YmxvY2txdW90ZSBjbGFzcz0idGV4dCI+PGRsPgo8ZHQ+Y29uZmlkZW50aWFsPC9k dD4KPGRkPgogICAgICAgICAgICAgIAogICAgICAgICAgICAgIENsaWVudHMgY2FwYWJsZSBvZiBt YWludGFpbmluZyB0aGUgY29uZmlkZW50aWFsaXR5IG9mIHRoZWlyIGNyZWRlbnRpYWxzIChlLmcu CiAgICAgICAgICAgICAgY2xpZW50IGltcGxlbWVudGVkIG9uIGEgc2VjdXJlIHNlcnZlciB3aXRo IHJlc3RyaWN0ZWQgYWNjZXNzIHRvIHRoZSBjbGllbnQKICAgICAgICAgICAgICBjcmVkZW50aWFs cyksIG9yIGNhcGFibGUgb2Ygc2VjdXJlIGNsaWVudCBhdXRoZW50aWNhdGlvbiB1c2luZyBvdGhl ciBtZWFucy4KICAgICAgICAgICAgCjwvZGQ+CjxkdD5wdWJsaWM8L2R0Pgo8ZGQ+CiAgICAgICAg ICAgICAgCiAgICAgICAgICAgICAgQ2xpZW50cyBpbmNhcGFibGUgb2YgbWFpbnRhaW5pbmcgdGhl IGNvbmZpZGVudGlhbGl0eSBvZiB0aGVpciBjcmVkZW50aWFscyAoZS5nLgogICAgICAgICAgICAg IGNsaWVudHMgZXhlY3V0aW5nIG9uIHRoZSBkZXZpY2UgdXNlZCBieSB0aGUgcmVzb3VyY2Ugb3du ZXIgc3VjaCBhcyBhbiBpbnN0YWxsZWQKICAgICAgICAgICAgICBuYXRpdmUgYXBwbGljYXRpb24g b3IgYSB3ZWIgYnJvd3Nlci1iYXNlZCBhcHBsaWNhdGlvbiksIGFuZCBpbmNhcGFibGUgb2Ygc2Vj dXJlCiAgICAgICAgICAgICAgY2xpZW50IGF1dGhlbnRpY2F0aW9uIHZpYSBhbnkgb3RoZXIgbWVh bnMuCiAgICAgICAgICAgIAo8L2RkPgo8L2RsPjwvYmxvY2txdW90ZT48cD4KICAgICAgICAKPC9w Pgo8cD4KICAgICAgICAgIFRoZSBjbGllbnQgdHlwZSBkZXNpZ25hdGlvbiBpcyBiYXNlZCBvbiB0 aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIncyBkZWZpbml0aW9uIG9mIHNlY3VyZQogICAgICAgICAg YXV0aGVudGljYXRpb24gYW5kIGl0cyBhY2NlcHRhYmxlIGV4cG9zdXJlIGxldmVscyBvZiBjbGll bnQgY3JlZGVudGlhbHMuIFRoZQogICAgICAgICAgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgU0hPVUxE IE5PVCBtYWtlIGFzc3VtcHRpb25zIGFib3V0IHRoZSBjbGllbnQgdHlwZS4KICAgICAgICAKPC9w Pgo8cD4KICAgICAgICAgIEEgY2xpZW50IG1heSBiZSBpbXBsZW1lbnRlZCBhcyBhIGRpc3RyaWJ1 dGVkIHNldCBvZiBjb21wb25lbnRzLCBlYWNoIHdpdGggYSBkaWZmZXJlbnQKICAgICAgICAgIGNs aWVudCB0eXBlIGFuZCBzZWN1cml0eSBjb250ZXh0IChlLmcuIGEgZGlzdHJpYnV0ZWQgY2xpZW50 IHdpdGggYm90aCBhIGNvbmZpZGVudGlhbAogICAgICAgICAgc2VydmVyLWJhc2VkIGNvbXBvbmVu dCBhbmQgYSBwdWJsaWMgYnJvd3Nlci1iYXNlZCBjb21wb25lbnQpLiBJZiB0aGUgYXV0aG9yaXph dGlvbiBzZXJ2ZXIKICAgICAgICAgIGRvZXMgbm90IHByb3ZpZGUgc3VwcG9ydCBmb3Igc3VjaCBj bGllbnRzLCBvciBkb2VzIG5vdCBwcm92aWRlIGd1aWRhbmNlIHdpdGggcmVnYXJkIHRvCiAgICAg ICAgICB0aGVpciByZWdpc3RyYXRpb24sIHRoZSBjbGllbnQgU0hPVUxEIHJlZ2lzdGVyIGVhY2gg Y29tcG9uZW50IGFzIGEgc2VwYXJhdGUgY2xpZW50LgogICAgICAgIAo8L3A+CjxwPgogICAgICAg ICAgVGhpcyBzcGVjaWZpY2F0aW9uIGhhcyBiZWVuIGRlc2lnbmVkIGFyb3VuZCB0aGUgZm9sbG93 aW5nIGNsaWVudCBwcm9maWxlczoKICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgIDwvcD4KPGJs b2NrcXVvdGUgY2xhc3M9InRleHQiPjxkbD4KPGR0PndlYiBhcHBsaWNhdGlvbjwvZHQ+CjxkZD4K ICAgICAgICAgICAgICAKICAgICAgICAgICAgICBBIHdlYiBhcHBsaWNhdGlvbiBpcyBhIGNvbmZp ZGVudGlhbCBjbGllbnQgcnVubmluZyBvbiBhIHdlYiBzZXJ2ZXIuIFJlc291cmNlIG93bmVycwog ICAgICAgICAgICAgIGFjY2VzcyB0aGUgY2xpZW50IHZpYSBhbiBIVE1MIHVzZXIgaW50ZXJmYWNl IHJlbmRlcmVkIGluIGEgdXNlci1hZ2VudCBvbiB0aGUgZGV2aWNlCiAgICAgICAgICAgICAgdXNl ZCBieSB0aGUgcmVzb3VyY2Ugb3duZXIuIFRoZSBjbGllbnQgY3JlZGVudGlhbHMgYXMgd2VsbCBh cyBhbnkgYWNjZXNzIHRva2VuIGlzc3VlZAogICAgICAgICAgICAgIHRvIHRoZSBjbGllbnQgYXJl IHN0b3JlZCBvbiB0aGUgd2ViIHNlcnZlciBhbmQgYXJlIG5vdCBleHBvc2VkIHRvIG9yIGFjY2Vz c2libGUgYnkKICAgICAgICAgICAgICB0aGUgcmVzb3VyY2Ugb3duZXIuCiAgICAgICAgICAgIAo8 L2RkPgo8ZHQ+dXNlci1hZ2VudC1iYXNlZCBhcHBsaWNhdGlvbjwvZHQ+CjxkZD4KICAgICAgICAg ICAgICAKICAgICAgICAgICAgICBBIHVzZXItYWdlbnQtYmFzZWQgYXBwbGljYXRpb24gaXMgYSBw dWJsaWMgY2xpZW50IGluIHdoaWNoIHRoZSBjbGllbnQgY29kZSBpcwogICAgICAgICAgICAgIGRv d25sb2FkZWQgZnJvbSBhIHdlYiBzZXJ2ZXIgYW5kIGV4ZWN1dGVzIHdpdGhpbiBhIHVzZXItYWdl bnQgKGUuZy4gd2ViIGJyb3dzZXIpIG9uCiAgICAgICAgICAgICAgdGhlIGRldmljZSB1c2VkIGJ5 IHRoZSByZXNvdXJjZSBvd25lci4gUHJvdG9jb2wgZGF0YSBhbmQgY3JlZGVudGlhbHMgYXJlIGVh c2lseQogICAgICAgICAgICAgIGFjY2Vzc2libGUgKGFuZCBvZnRlbiB2aXNpYmxlKSB0byB0aGUg cmVzb3VyY2Ugb3duZXIuIFNpbmNlIHN1Y2ggYXBwbGljYXRpb25zIHJlc2lkZQogICAgICAgICAg ICAgIHdpdGhpbiB0aGUgdXNlci1hZ2VudCwgdGhleSBjYW4gbWFrZSBzZWFtbGVzcyB1c2Ugb2Yg dGhlIHVzZXItYWdlbnQgY2FwYWJpbGl0aWVzIHdoZW4KICAgICAgICAgICAgICByZXF1ZXN0aW5n IGF1dGhvcml6YXRpb24uCiAgICAgICAgICAgIAo8L2RkPgo8ZHQ+bmF0aXZlIGFwcGxpY2F0aW9u PC9kdD4KPGRkPgogICAgICAgICAgICAgIAogICAgICAgICAgICAgIEEgbmF0aXZlIGFwcGxpY2F0 aW9uIGlzIGEgcHVibGljIGNsaWVudCBpbnN0YWxsZWQgYW5kIGV4ZWN1dGVkIG9uIHRoZSBkZXZp Y2UgdXNlZCBieQogICAgICAgICAgICAgIHRoZSByZXNvdXJjZSBvd25lci4gUHJvdG9jb2wgZGF0 YSBhbmQgY3JlZGVudGlhbHMgYXJlIGFjY2Vzc2libGUgdG8gdGhlIHJlc291cmNlCiAgICAgICAg ICAgICAgb3duZXIuIEl0IGlzIGFzc3VtZWQgdGhhdCBhbnkgY2xpZW50IGF1dGhlbnRpY2F0aW9u IGNyZWRlbnRpYWxzIGluY2x1ZGVkIGluIHRoZQogICAgICAgICAgICAgIGFwcGxpY2F0aW9uIGNh biBiZSBleHRyYWN0ZWQuIE9uIHRoZSBvdGhlciBoYW5kLCBkeW5hbWljYWxseSBpc3N1ZWQgY3Jl ZGVudGlhbHMgc3VjaAogICAgICAgICAgICAgIGFzIGFjY2VzcyB0b2tlbnMgb3IgcmVmcmVzaCB0 b2tlbnMgY2FuIHJlY2VpdmUgYW4gYWNjZXB0YWJsZSBsZXZlbCBvZiBwcm90ZWN0aW9uLiBBdCBh CiAgICAgICAgICAgICAgbWluaW11bSwgdGhlc2UgY3JlZGVudGlhbHMgYXJlIHByb3RlY3RlZCBm cm9tIGhvc3RpbGUgc2VydmVycyB3aXRoIHdoaWNoIHRoZQogICAgICAgICAgICAgIGFwcGxpY2F0 aW9uIG1heSBpbnRlcmFjdCB3aXRoLiBPbiBzb21lIHBsYXRmb3JtcyB0aGVzZSBjcmVkZW50aWFs cyBtaWdodCBiZSBwcm90ZWN0ZWQKICAgICAgICAgICAgICBmcm9tIG90aGVyIGFwcGxpY2F0aW9u cyByZXNpZGluZyBvbiB0aGUgc2FtZSBkZXZpY2UuCiAgICAgICAgICAgIAo8L2RkPgo8L2RsPjwv YmxvY2txdW90ZT48cD4KICAgICAgICAKPC9wPgo8YSBuYW1lPSJjbGllbnQtaWRlbnRpZmllciI+ PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIg Y2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFz cz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwv dGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLjIuMiI+PC9hPjxoMz4yLjIuJm5ic3A7CkNsaWVu dCBJZGVudGlmaWVyPC9oMz4KCjxwPgogICAgICAgICAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVy IGlzc3VlcyB0aGUgcmVnaXN0ZXJlZCBjbGllbnQgYSBjbGllbnQgaWRlbnRpZmllciAtIGEgdW5p cXVlCiAgICAgICAgICBzdHJpbmcgcmVwcmVzZW50aW5nIHRoZSByZWdpc3RyYXRpb24gaW5mb3Jt YXRpb24gcHJvdmlkZWQgYnkgdGhlIGNsaWVudC4gVGhlIGNsaWVudAogICAgICAgICAgaWRlbnRp ZmllciBpcyBub3QgYSBzZWNyZXQ7IGl0IGlzIGV4cG9zZWQgdG8gdGhlIHJlc291cmNlIG93bmVy LCBhbmQgTVVTVCBOT1QgYmUgdXNlZAogICAgICAgICAgYWxvbmUgZm9yIGNsaWVudCBhdXRoZW50 aWNhdGlvbi4gVGhlIGNsaWVudCBpZGVudGlmaWVyIGlzIHVuaXF1ZSB0byB0aGUgYXV0aG9yaXph dGlvbgogICAgICAgICAgc2VydmVyLgogICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgVGhlIGNs aWVudCBpZGVudGlmaWVyIHN0cmluZyBzaXplIGlzIGxlZnQgdW5kZWZpbmVkIGJ5IHRoaXMgc3Bl Y2lmaWNhdGlvbi4gVGhlIGNsaWVudAogICAgICAgICAgc2hvdWxkIGF2b2lkIG1ha2luZyBhc3N1 bXB0aW9ucyBhYm91dCB0aGUgaWRlbnRpZmllciBzaXplLiAgVGhlIGF1dGhvcml6YXRpb24gc2Vy dmVyCiAgICAgICAgICBTSE9VTEQgZG9jdW1lbnQgdGhlIHNpemUgb2YgYW55IGlkZW50aWZpZXIg aXQgaXNzdWVzLgogICAgICAgIAo8L3A+CjxhIG5hbWU9ImNsaWVudC1hdXRoZW50aWNhdGlvbiI+ PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIg Y2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFz cz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwv dGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLjIuMyI+PC9hPjxoMz4yLjMuJm5ic3A7CkNsaWVu dCBBdXRoZW50aWNhdGlvbjwvaDM+Cgo8cD4KICAgICAgICAgIElmIHRoZSBjbGllbnQgdHlwZSBp cyBjb25maWRlbnRpYWwsIHRoZSBjbGllbnQgYW5kIGF1dGhvcml6YXRpb24gc2VydmVyIGVzdGFi bGlzaCBhIGNsaWVudAogICAgICAgICAgYXV0aGVudGljYXRpb24gbWV0aG9kIHN1aXRhYmxlIGZv ciB0aGUgc2VjdXJpdHkgcmVxdWlyZW1lbnRzIG9mIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlci4K ICAgICAgICAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBNQVkgYWNjZXB0IGFueSBmb3JtIG9m IGNsaWVudCBhdXRoZW50aWNhdGlvbiBtZWV0aW5nIGl0cwogICAgICAgICAgc2VjdXJpdHkgcmVx dWlyZW1lbnRzLgogICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgQ29uZmlkZW50aWFsIGNsaWVu dHMgYXJlIHR5cGljYWxseSBpc3N1ZWQgKG9yIGVzdGFibGlzaCkgYSBzZXQgb2YgY2xpZW50IGNy ZWRlbnRpYWxzIHVzZWQgZm9yCiAgICAgICAgICBhdXRoZW50aWNhdGluZyB3aXRoIHRoZSBhdXRo b3JpemF0aW9uIHNlcnZlciAoZS5nLiBwYXNzd29yZCwgcHVibGljL3ByaXZhdGUga2V5IHBhaXIp LgogICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIE1B WSBlc3RhYmxpc2ggYSBjbGllbnQgYXV0aGVudGljYXRpb24gbWV0aG9kIHdpdGggcHVibGljIGNs aWVudHMuCiAgICAgICAgICBIb3dldmVyLCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVTVCBO T1QgcmVseSBvbiBwdWJsaWMgY2xpZW50IGF1dGhlbnRpY2F0aW9uIGZvciB0aGUKICAgICAgICAg IHB1cnBvc2Ugb2YgaWRlbnRpZnlpbmcgdGhlIGNsaWVudC4KICAgICAgICAKPC9wPgo8cD4KICAg ICAgICAgIFRoZSBjbGllbnQgTVVTVCBOT1QgdXNlIG1vcmUgdGhhbiBvbmUgYXV0aGVudGljYXRp b24gbWV0aG9kIGluIGVhY2ggcmVxdWVzdC4KICAgICAgICAKPC9wPgo8YSBuYW1lPSJjbGllbnQt cGFzc3dvcmQiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBh ZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0 cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwv dGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi4yLjMuMSI+PC9hPjxoMz4yLjMu MS4mbmJzcDsKQ2xpZW50IFBhc3N3b3JkPC9oMz4KCjxwPgogICAgICAgICAgICBDbGllbnRzIGlu IHBvc3Nlc3Npb24gb2YgYSBjbGllbnQgcGFzc3dvcmQgTUFZIHVzZSB0aGUgSFRUUCBCYXNpYyBh dXRoZW50aWNhdGlvbiBzY2hlbWUKICAgICAgICAgICAgYXMgZGVmaW5lZCBpbiA8YSBjbGFzcz0n aW5mbycgaHJlZj0nI1JGQzI2MTcnPltSRkMyNjE3XTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNz PSdpbmZvJz5GcmFua3MsIEouLCBIYWxsYW0tQmFrZXIsIFAuLCBIb3N0ZXRsZXIsIEouLCBMYXdy ZW5jZSwgUy4sIExlYWNoLCBQLiwgTHVvdG9uZW4sIEEuLCBhbmQgTC4gU3Rld2FydCwgJmxkcXVv O0hUVFAgQXV0aGVudGljYXRpb246IEJhc2ljIGFuZCBEaWdlc3QgQWNjZXNzIEF1dGhlbnRpY2F0 aW9uLCZyZHF1bzsgSnVuZSZuYnNwOzE5OTkuPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPiB0byBh dXRoZW50aWNhdGUgd2l0aCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIuCiAgICAgICAgICAgIFRo ZSBjbGllbnQgaWRlbnRpZmllciBpcyB1c2VkIGFzIHRoZSB1c2VybmFtZSwgYW5kIHRoZSBjbGll bnQgcGFzc3dvcmQgaXMgdXNlZCBhcyB0aGUKICAgICAgICAgICAgcGFzc3dvcmQuIFRoZSBhdXRo b3JpemF0aW9uIHNlcnZlciBNVVNUIHN1cHBvcnQgdGhlIEhUVFAgQmFzaWMgYXV0aGVudGljYXRp b24gc2NoZW1lCiAgICAgICAgICAgIGZvciBhdXRoZW50aWNhdGluZyBjbGllbnRzIHdoaWNoIHdl cmUgaXNzdWVkIGEgY2xpZW50IHBhc3N3b3JkLgogICAgICAgICAgCjwvcD4KPHA+CiAgICAgICAg ICAgICAgRm9yIGV4YW1wbGUgKGV4dHJhIGxpbmUgYnJlYWtzIGFyZSBmb3IgZGlzcGxheSBwdXJw b3NlcyBvbmx5KToKICAgICAgICAgICAgCjwvcD48ZGl2IHN0eWxlPSdkaXNwbGF5OiB0YWJsZTsg d2lkdGg6IDA7IG1hcmdpbi1sZWZ0OiAzZW07IG1hcmdpbi1yaWdodDogYXV0byc+PHByZT4KCiAg QXV0aG9yaXphdGlvbjogQmFzaWMgY3paQ2FHUlNhM0YwTXpvM1JtcG1jREJhUW5JeFMzUkVVbUp1 Wmxaa2JVbDMKCjwvcHJlPjwvZGl2Pgo8cD4KICAgICAgICAgICAgQWx0ZXJuYXRpdmVseSwgdGhl IGF1dGhvcml6YXRpb24gc2VydmVyIE1BWSBzdXBwb3J0IGluY2x1ZGluZyB0aGUgY2xpZW50IGNy ZWRlbnRpYWxzIGluCiAgICAgICAgICAgIHRoZSByZXF1ZXN0IGJvZHkgdXNpbmcgdGhlIGZvbGxv d2luZyBwYXJhbWV0ZXJzOgogICAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICAgIDwvcD4KPGJs b2NrcXVvdGUgY2xhc3M9InRleHQiPjxkbD4KPGR0PmNsaWVudF9pZDwvZHQ+CjxkZD4KICAgICAg ICAgICAgICAgIAogICAgICAgICAgICAgICAgUkVRVUlSRUQuIFRoZSBjbGllbnQgaWRlbnRpZmll ciBpc3N1ZWQgdG8gdGhlIGNsaWVudCBkdXJpbmcgdGhlIHJlZ2lzdHJhdGlvbiBwcm9jZXNzCiAg ICAgICAgICAgICAgICBkZXNjcmliZWQgYnkgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNjbGllbnQt aWRlbnRpZmllcic+U2VjdGlvbiZuYnNwOzIuMjxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdp bmZvJz5DbGllbnQgSWRlbnRpZmllcjwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4uCiAgICAgICAg ICAgICAgCjwvZGQ+CjxkdD5jbGllbnRfc2VjcmV0PC9kdD4KPGRkPgogICAgICAgICAgICAgICAg CiAgICAgICAgICAgICAgICBSRVFVSVJFRC4gVGhlIGNsaWVudCBzZWNyZXQuIFRoZSBjbGllbnQg TUFZIG9taXQgdGhlIHBhcmFtZXRlciBpZiB0aGUgY2xpZW50IHNlY3JldAogICAgICAgICAgICAg ICAgaXMgYW4gZW1wdHkgc3RyaW5nLgogICAgICAgICAgICAgIAo8L2RkPgo8L2RsPjwvYmxvY2tx dW90ZT48cD4KICAgICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgICBJbmNsdWRpbmcgdGhlIGNs aWVudCBjcmVkZW50aWFscyBpbiB0aGUgcmVxdWVzdCBib2R5IHVzaW5nIHRoZSB0d28gcGFyYW1l dGVycyBpcyBOT1QKICAgICAgICAgICAgUkVDT01NRU5ERUQsIGFuZCBTSE9VTEQgYmUgbGltaXRl ZCB0byBjbGllbnRzIHVuYWJsZSB0byBkaXJlY3RseSB1dGlsaXplIHRoZSBIVFRQIEJhc2ljCiAg ICAgICAgICAgIGF1dGhlbnRpY2F0aW9uIHNjaGVtZSAob3Igb3RoZXIgcGFzc3dvcmQtYmFzZWQg SFRUUCBhdXRoZW50aWNhdGlvbiBzY2hlbWVzKS4gVGhlCiAgICAgICAgICAgIHBhcmFtZXRlcnMg Y2FuIG9ubHkgYmUgdHJhbnNtaXR0ZWQgaW4gdGhlIHJlcXVlc3QgYm9keSBhbmQgTVVTVCBOT1Qg YmUgaW5jbHVkZWQgaW4gdGhlCiAgICAgICAgICAgIHJlcXVlc3QgVVJJLgogICAgICAgICAgCjwv cD4KPHA+CiAgICAgICAgICAgICAgRm9yIGV4YW1wbGUsIHJlcXVlc3RpbmcgdG8gcmVmcmVzaCBh biBhY2Nlc3MgdG9rZW4gKDxhIGNsYXNzPSdpbmZvJyBocmVmPScjdG9rZW4tcmVmcmVzaCc+U2Vj dGlvbiZuYnNwOzY8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+UmVmcmVzaGluZyBh biBBY2Nlc3MgVG9rZW48L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+KQogICAgICAgICAgICAgIHVz aW5nIHRoZSBib2R5IHBhcmFtZXRlcnMgKGV4dHJhIGxpbmUgYnJlYWtzIGFyZSBmb3IgZGlzcGxh eSBwdXJwb3NlcyBvbmx5KToKICAgICAgICAgICAgCjwvcD48ZGl2IHN0eWxlPSdkaXNwbGF5OiB0 YWJsZTsgd2lkdGg6IDA7IG1hcmdpbi1sZWZ0OiAzZW07IG1hcmdpbi1yaWdodDogYXV0byc+PHBy ZT4KCiAgUE9TVCAvdG9rZW4gSFRUUC8xLjEKICBIb3N0OiBzZXJ2ZXIuZXhhbXBsZS5jb20KICBD b250ZW50LVR5cGU6IGFwcGxpY2F0aW9uL3gtd3d3LWZvcm0tdXJsZW5jb2RlZDtjaGFyc2V0PVVU Ri04CgogIGdyYW50X3R5cGU9cmVmcmVzaF90b2tlbiZhbXA7cmVmcmVzaF90b2tlbj10R3p2M0pP a0YwWEc1UXgyVGxLV0lBCiAgJmFtcDtjbGllbnRfaWQ9czZCaGRSa3F0MyZhbXA7Y2xpZW50X3Nl Y3JldD03RmpmcDBaQnIxS3REUmJuZlZkbUl3Cgo8L3ByZT48L2Rpdj4KPHA+CiAgICAgICAgICAg IFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBNVVNUIHJlcXVpcmUgdGhlIHVzZSBvZiBUTFMgYXMg ZGVzY3JpYmVkIGluCiAgICAgICAgICAgIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjdGxzJz5TZWN0 aW9uJm5ic3A7MS42PHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPlRMUyBWZXJzaW9u PC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPiB3aGVuIHNlbmRpbmcgcmVxdWVzdHMgdXNpbmcgcGFz c3dvcmQgYXV0aGVudGljYXRpb24uCiAgICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgICAgU2lu Y2UgdGhpcyBjbGllbnQgYXV0aGVudGljYXRpb24gbWV0aG9kIGludm9sdmVzIGEgcGFzc3dvcmQs IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlcgogICAgICAgICAgICBNVVNUIHByb3RlY3QgYW55IGVu ZHBvaW50IHV0aWxpemluZyBpdCBhZ2FpbnN0IGJydXRlIGZvcmNlIGF0dGFja3MuCiAgICAgICAg ICAKPC9wPgo8YSBuYW1lPSJhbmNob3IxNSI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFy eT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWci IGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJz cDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLjIu My4yIj48L2E+PGgzPjIuMy4yLiZuYnNwOwpPdGhlciBBdXRoZW50aWNhdGlvbiBNZXRob2RzPC9o Mz4KCjxwPgogICAgICAgICAgICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTUFZIHN1cHBvcnQg YW55IHN1aXRhYmxlIEhUVFAgYXV0aGVudGljYXRpb24gc2NoZW1lIG1hdGNoaW5nCiAgICAgICAg ICAgIGl0cyBzZWN1cml0eSByZXF1aXJlbWVudHMuIFdoZW4gdXNpbmcgb3RoZXIgYXV0aGVudGlj YXRpb24gbWV0aG9kcywgdGhlIGF1dGhvcml6YXRpb24KICAgICAgICAgICAgc2VydmVyIE1VU1Qg ZGVmaW5lIGEgbWFwcGluZyBiZXR3ZWVuIHRoZSBjbGllbnQgaWRlbnRpZmllciAocmVnaXN0cmF0 aW9uIHJlY29yZCkgYW5kCiAgICAgICAgICAgIGF1dGhlbnRpY2F0aW9uIHNjaGVtZS4KICAgICAg ICAgIAo8L3A+CjxhIG5hbWU9ImFuY2hvcjE2Ij48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1t YXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1 ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZu YnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24u Mi40Ij48L2E+PGgzPjIuNC4mbmJzcDsKVW5yZWdpc3RlcmVkIENsaWVudHM8L2gzPgoKPHA+CiAg ICAgICAgICBUaGlzIHNwZWNpZmljYXRpb24gZG9lcyBub3QgZXhjbHVkZSB0aGUgdXNlIG9mIHVu cmVnaXN0ZXJlZCBjbGllbnRzLiBIb3dldmVyLCB0aGUgdXNlCiAgICAgICAgICB3aXRoIHN1Y2gg Y2xpZW50cyBpcyBiZXlvbmQgdGhlIHNjb3BlIG9mIHRoaXMgc3BlY2lmaWNhdGlvbiwgYW5kIHJl cXVpcmVzIGFkZGl0aW9uYWwKICAgICAgICAgIHNlY3VyaXR5IGFuYWx5c2lzIGFuZCByZXZpZXcg b2YgaXRzIGludGVyb3BlcmFiaWxpdHkgaW1wYWN0LgogICAgICAgIAo8L3A+CjxhIG5hbWU9ImFu Y2hvcjE3Ij48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRk aW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+ PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3Rk PjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uMyI+PC9hPjxoMz4zLiZuYnNwOwpQ cm90b2NvbCBFbmRwb2ludHM8L2gzPgoKPHA+CiAgICAgICAgVGhlIGF1dGhvcml6YXRpb24gcHJv Y2VzcyB1dGlsaXplcyB0d28gYXV0aG9yaXphdGlvbiBzZXJ2ZXIgZW5kcG9pbnRzIChIVFRQIHJl c291cmNlcyk6CiAgICAgIAo8L3A+CjxwPgogICAgICAgIDwvcD4KPHVsIGNsYXNzPSJ0ZXh0Ij4K PGxpPgogICAgICAgICAgICBBdXRob3JpemF0aW9uIGVuZHBvaW50IC0gdXNlZCBieSB0aGUgY2xp ZW50IHRvIG9idGFpbiBhdXRob3JpemF0aW9uIGZyb20gdGhlIHJlc291cmNlCiAgICAgICAgICAg IG93bmVyIHZpYSB1c2VyLWFnZW50IHJlZGlyZWN0aW9uLgogICAgICAgICAgCjwvbGk+CjxsaT4K ICAgICAgICAgICAgVG9rZW4gZW5kcG9pbnQgLSB1c2VkIGJ5IHRoZSBjbGllbnQgdG8gZXhjaGFu Z2UgYW4gYXV0aG9yaXphdGlvbiBncmFudCBmb3IgYW4gYWNjZXNzCiAgICAgICAgICAgIHRva2Vu LCB0eXBpY2FsbHkgd2l0aCBjbGllbnQgYXV0aGVudGljYXRpb24uCiAgICAgICAgICAKPC9saT4K PC91bD48cD4KICAgICAgCjwvcD4KPHA+CiAgICAgICAgQXMgd2VsbCBhcyBvbmUgY2xpZW50IGVu ZHBvaW50OgogICAgICAKPC9wPgo8cD4KICAgICAgICA8L3A+Cjx1bCBjbGFzcz0idGV4dCI+Cjxs aT4KICAgICAgICAgICAgUmVkaXJlY3Rpb24gZW5kcG9pbnQgLSB1c2VkIGJ5IHRoZSBhdXRob3Jp emF0aW9uIHNlcnZlciB0byByZXR1cm4gYXV0aG9yaXphdGlvbgogICAgICAgICAgICBjcmVkZW50 aWFscyByZXNwb25zZXMgdG8gdGhlIGNsaWVudCB2aWEgdGhlIHJlc291cmNlIG93bmVyIHVzZXIt YWdlbnQuCiAgICAgICAgICAKPC9saT4KPC91bD48cD4KICAgICAgCjwvcD4KPHA+CiAgICAgICAg Tm90IGV2ZXJ5IGF1dGhvcml6YXRpb24gZ3JhbnQgdHlwZSB1dGlsaXplcyBib3RoIGVuZHBvaW50 cy4gRXh0ZW5zaW9uIGdyYW50IHR5cGVzIE1BWQogICAgICAgIGRlZmluZSBhZGRpdGlvbmFsIGVu ZHBvaW50cyBhcyBuZWVkZWQuCiAgICAgIAo8L3A+CjxhIG5hbWU9ImFuY2hvcjE4Ij48L2E+PGJy IC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3Bh Y2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0Ni dWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4K PGEgbmFtZT0icmZjLnNlY3Rpb24uMy4xIj48L2E+PGgzPjMuMS4mbmJzcDsKQXV0aG9yaXphdGlv biBFbmRwb2ludDwvaDM+Cgo8cD4KICAgICAgICAgIFRoZSBhdXRob3JpemF0aW9uIGVuZHBvaW50 IGlzIHVzZWQgdG8gaW50ZXJhY3Qgd2l0aCB0aGUgcmVzb3VyY2Ugb3duZXIgYW5kIG9idGFpbgog ICAgICAgICAgYW4gYXV0aG9yaXphdGlvbiBncmFudC4gVGhlIGF1dGhvcml6YXRpb24gc2VydmVy IE1VU1QgZmlyc3QgdmVyaWZ5IHRoZSBpZGVudGl0eSBvZiB0aGUKICAgICAgICAgIHJlc291cmNl IG93bmVyLiBUaGUgd2F5IGluIHdoaWNoIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBhdXRoZW50 aWNhdGVzIHRoZSByZXNvdXJjZQogICAgICAgICAgb3duZXIgKGUuZy4gdXNlcm5hbWUgYW5kIHBh c3N3b3JkIGxvZ2luLCBzZXNzaW9uIGNvb2tpZXMpIGlzIGJleW9uZCB0aGUgc2NvcGUgb2YgdGhp cwogICAgICAgICAgc3BlY2lmaWNhdGlvbi4KICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgIFRo ZSBtZWFucyB0aHJvdWdoIHdoaWNoIHRoZSBjbGllbnQgb2J0YWlucyB0aGUgbG9jYXRpb24gb2Yg dGhlIGF1dGhvcml6YXRpb24gZW5kcG9pbnQgYXJlCiAgICAgICAgICBiZXlvbmQgdGhlIHNjb3Bl IG9mIHRoaXMgc3BlY2lmaWNhdGlvbiwgYnV0IHRoZSBsb2NhdGlvbiBpcyB0eXBpY2FsbHkgcHJv dmlkZWQgaW4gdGhlCiAgICAgICAgICBzZXJ2aWNlIGRvY3VtZW50YXRpb24uCiAgICAgICAgCjwv cD4KPHA+CiAgICAgICAgICBUaGUgZW5kcG9pbnQgVVJJIE1BWSBpbmNsdWRlIGFuCiAgICAgICAg ICA8dHQ+YXBwbGljYXRpb24veC13d3ctZm9ybS11cmxlbmNvZGVkPC90dD4gZm9ybWF0dGVkCiAg ICAgICAgICAoPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNXM0MuUkVDLWh0bWw0MDEtMTk5OTEyMjQn PltXM0MuUkVDJiM4MjA5O2h0bWw0MDEmIzgyMDk7MTk5OTEyMjRdPHNwYW4+ICg8L3NwYW4+PHNw YW4gY2xhc3M9J2luZm8nPkhvcnMsIEEuLCBSYWdnZXR0LCBELiwgYW5kIEkuIEphY29icywgJmxk cXVvO0hUTUwgNC4wMSBTcGVjaWZpY2F0aW9uLCZyZHF1bzsgRGVjZW1iZXImbmJzcDsxOTk5Ljwv c3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4pIHF1ZXJ5IGNvbXBvbmVudCAoPGEgY2xhc3M9J2luZm8n IGhyZWY9JyNSRkMzOTg2Jz5bUkZDMzk4Nl08c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5m byc+QmVybmVycy1MZWUsIFQuLCBGaWVsZGluZywgUi4sIGFuZCBMLiBNYXNpbnRlciwgJmxkcXVv O1VuaWZvcm0gUmVzb3VyY2UgSWRlbnRpZmllciAoVVJJKTogR2VuZXJpYyBTeW50YXgsJnJkcXVv OyBKYW51YXJ5Jm5ic3A7MjAwNS48L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+CiAgICAgICAgICBz ZWN0aW9uIDMuNCksIHdoaWNoIE1VU1QgYmUgcmV0YWluZWQgd2hlbiBhZGRpbmcgYWRkaXRpb25h bCBxdWVyeSBwYXJhbWV0ZXJzLiBUaGUKICAgICAgICAgIGVuZHBvaW50IFVSSSBNVVNUIE5PVCBp bmNsdWRlIGEgZnJhZ21lbnQgY29tcG9uZW50LgogICAgICAgIAo8L3A+CjxwPgogICAgICAgICAg U2luY2UgcmVxdWVzdHMgdG8gdGhlIGF1dGhvcml6YXRpb24gZW5kcG9pbnQgcmVzdWx0IGluIHVz ZXIgYXV0aGVudGljYXRpb24gYW5kIHRoZQogICAgICAgICAgdHJhbnNtaXNzaW9uIG9mIGNsZWFy LXRleHQgY3JlZGVudGlhbHMgKGluIHRoZSBIVFRQIHJlc3BvbnNlKSwgdGhlIGF1dGhvcml6YXRp b24gc2VydmVyCiAgICAgICAgICBNVVNUIHJlcXVpcmUgdGhlIHVzZSBvZiBUTFMgYXMgZGVzY3Jp YmVkIGluIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjdGxzJz5TZWN0aW9uJm5ic3A7MS42PHNwYW4+ ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPlRMUyBWZXJzaW9uPC9zcGFuPjxzcGFuPik8L3Nw YW4+PC9hPiB3aGVuIHNlbmRpbmcgcmVxdWVzdHMKICAgICAgICAgIHRvIHRoZSBhdXRob3JpemF0 aW9uIGVuZHBvaW50LgogICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgVGhlIGF1dGhvcml6YXRp b24gc2VydmVyIE1VU1Qgc3VwcG9ydCB0aGUgdXNlIG9mIHRoZSBIVFRQIDx0dD5HRVQ8L3R0Pgog ICAgICAgICAgbWV0aG9kIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjUkZDMjYxNic+W1JGQzI2MTZd PHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkZpZWxkaW5nLCBSLiwgR2V0dHlzLCBK LiwgTW9ndWwsIEouLCBGcnlzdHlrLCBILiwgTWFzaW50ZXIsIEwuLCBMZWFjaCwgUC4sIGFuZCBU LiBCZXJuZXJzLUxlZSwgJmxkcXVvO0h5cGVydGV4dCBUcmFuc2ZlciBQcm90b2NvbCAtLSBIVFRQ LzEuMSwmcmRxdW87IEp1bmUmbmJzcDsxOTk5Ljwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4gZm9y IHRoZSBhdXRob3JpemF0aW9uIGVuZHBvaW50LCBhbmQgTUFZIHN1cHBvcnQgdGhlIHVzZQogICAg ICAgICAgb2YgdGhlIDx0dD5QT1NUPC90dD4gbWV0aG9kIGFzIHdlbGwuCiAgICAgICAgCjwvcD4K PHA+CiAgICAgICAgICBQYXJhbWV0ZXJzIHNlbnQgd2l0aG91dCBhIHZhbHVlIE1VU1QgYmUgdHJl YXRlZCBhcyBpZiB0aGV5IHdlcmUgb21pdHRlZCBmcm9tIHRoZSByZXF1ZXN0LgogICAgICAgICAg VGhlIGF1dGhvcml6YXRpb24gc2VydmVyIE1VU1QgaWdub3JlIHVucmVjb2duaXplZCByZXF1ZXN0 IHBhcmFtZXRlcnMuIFJlcXVlc3QgYW5kCiAgICAgICAgICByZXNwb25zZSBwYXJhbWV0ZXJzIE1V U1QgTk9UIGJlIGluY2x1ZGVkIG1vcmUgdGhhbiBvbmNlLgogICAgICAgIAo8L3A+CjxhIG5hbWU9 InJlc3BvbnNlLXR5cGUiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIg Y2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmln aHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7 PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi4zLjEuMSI+PC9hPjxo Mz4zLjEuMS4mbmJzcDsKUmVzcG9uc2UgVHlwZTwvaDM+Cgo8cD4KICAgICAgICAgICAgVGhlIGF1 dGhvcml6YXRpb24gZW5kcG9pbnQgaXMgdXNlZCBieSB0aGUgYXV0aG9yaXphdGlvbiBjb2RlIGdy YW50IHR5cGUgYW5kIGltcGxpY2l0CiAgICAgICAgICAgIGdyYW50IHR5cGUgZmxvd3MuIFRoZSBj bGllbnQgaW5mb3JtcyB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgb2YgdGhlIGRlc2lyZWQgZ3Jh bnQKICAgICAgICAgICAgdHlwZSB1c2luZyB0aGUgZm9sbG93aW5nIHBhcmFtZXRlcjoKICAgICAg ICAgIAo8L3A+CjxwPgogICAgICAgICAgICA8L3A+CjxibG9ja3F1b3RlIGNsYXNzPSJ0ZXh0Ij48 ZGw+CjxkdD5yZXNwb25zZV90eXBlPC9kdD4KPGRkPgogICAgICAgICAgICAgICAgCiAgICAgICAg ICAgICAgICBSRVFVSVJFRC4gVGhlIHZhbHVlIE1VU1QgYmUgb25lIG9mIDx0dD5jb2RlPC90dD4g Zm9yIHJlcXVlc3RpbmcKICAgICAgICAgICAgICAgIGFuIGF1dGhvcml6YXRpb24gY29kZSBhcyBk ZXNjcmliZWQgYnkgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNjb2RlLWF1dGh6LXJlcSc+U2VjdGlv biZuYnNwOzQuMS4xPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkF1dGhvcml6YXRp b24gUmVxdWVzdDwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4sCiAgICAgICAgICAgICAgICA8dHQ+ dG9rZW48L3R0PiBmb3IgcmVxdWVzdGluZyBhbiBhY2Nlc3MgdG9rZW4gKGltcGxpY2l0IGdyYW50 KQogICAgICAgICAgICAgICAgYXMgZGVzY3JpYmVkIGJ5IDxhIGNsYXNzPSdpbmZvJyBocmVmPScj aW1wbGljaXQtYXV0aHotcmVxJz5TZWN0aW9uJm5ic3A7NC4yLjE8c3Bhbj4gKDwvc3Bhbj48c3Bh biBjbGFzcz0naW5mbyc+QXV0aG9yaXphdGlvbiBSZXF1ZXN0PC9zcGFuPjxzcGFuPik8L3NwYW4+ PC9hPiwgb3IgYSByZWdpc3RlcmVkIGV4dGVuc2lvbgogICAgICAgICAgICAgICAgdmFsdWUgYXMg ZGVzY3JpYmVkIGJ5IDxhIGNsYXNzPSdpbmZvJyBocmVmPScjcmVzcG9uc2UtdHlwZS1leHQnPlNl Y3Rpb24mbmJzcDs4LjQ8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+RGVmaW5pbmcg TmV3IEF1dGhvcml6YXRpb24gRW5kcG9pbnQgUmVzcG9uc2UgVHlwZXM8L3NwYW4+PHNwYW4+KTwv c3Bhbj48L2E+LgogICAgICAgICAgICAgIAo8L2RkPgo8L2RsPjwvYmxvY2txdW90ZT48cD4KICAg ICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgICBFeHRlbnNpb24gcmVzcG9uc2UgdHlwZXMgTUFZ IGNvbnRhaW4gYSBzcGFjZS1kZWxpbWl0ZWQgKCV4MjApIGxpc3Qgb2YgdmFsdWVzLCB3aGVyZSB0 aGUKICAgICAgICAgICAgb3JkZXIgb2YgdmFsdWVzIGRvZXMgbm90IG1hdHRlciAoZS5nLiByZXNw b25zZSB0eXBlIDx0dD5hIGI8L3R0PiBpcwogICAgICAgICAgICB0aGUgc2FtZSBhcyA8dHQ+YiBh PC90dD4pLiBUaGUgbWVhbmluZyBvZiBzdWNoIGNvbXBvc2l0ZSByZXNwb25zZQogICAgICAgICAg ICB0eXBlcyBpcyBkZWZpbmVkIGJ5IHRoZWlyIHJlc3BlY3RpdmUgc3BlY2lmaWNhdGlvbnMuCiAg ICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgICAgSWYgYW4gYXV0aG9yaXphdGlvbiByZXF1ZXN0 IGlzIG1pc3NpbmcgdGhlIDx0dD5yZXNwb25zZV90eXBlPC90dD4KICAgICAgICAgICAgcGFyYW1l dGVyLCBvciBpZiB0aGUgcmVzcG9uc2UgdHlwZSBpcyBub3QgdW5kZXJzdG9vZCwgdGhlIGF1dGhv cml6YXRpb24gc2VydmVyIE1VU1QKICAgICAgICAgICAgcmV0dXJuIGFuIGVycm9yIHJlc3BvbnNl IGFzIGRlc2NyaWJlZCBpbiA8YSBjbGFzcz0naW5mbycgaHJlZj0nI2NvZGUtYXV0aHotZXJyb3In PlNlY3Rpb24mbmJzcDs0LjEuMi4xPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkVy cm9yIFJlc3BvbnNlPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPi4KICAgICAgICAgIAo8L3A+Cjxh IG5hbWU9InJlZGlyZWN0LXVyaSI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5 b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWdu PSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0Mm bmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLjMuMS4yIj48 L2E+PGgzPjMuMS4yLiZuYnNwOwpSZWRpcmVjdGlvbiBFbmRwb2ludDwvaDM+Cgo8cD4KICAgICAg ICAgICAgQWZ0ZXIgY29tcGxldGluZyBpdHMgaW50ZXJhY3Rpb24gd2l0aCB0aGUgcmVzb3VyY2Ug b3duZXIsIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlcgogICAgICAgICAgICBkaXJlY3RzIHRoZSBy ZXNvdXJjZSBvd25lcidzIHVzZXItYWdlbnQgYmFjayB0byB0aGUgY2xpZW50LiBUaGUgYXV0aG9y aXphdGlvbiBzZXJ2ZXIKICAgICAgICAgICAgcmVkaXJlY3RzIHRoZSB1c2VyLWFnZW50IHRvIHRo ZSBjbGllbnQncyByZWRpcmVjdGlvbiBlbmRwb2ludCBwcmV2aW91c2x5IGVzdGFibGlzaGVkCiAg ICAgICAgICAgIHdpdGggdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGR1cmluZyB0aGUgY2xpZW50 IHJlZ2lzdHJhdGlvbiBwcm9jZXNzIG9yIHdoZW4gbWFraW5nCiAgICAgICAgICAgIHRoZSBhdXRo b3JpemF0aW9uIHJlcXVlc3QuCiAgICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgICAgVGhlIHJl ZGlyZWN0aW9uIGVuZHBvaW50IFVSSSBNVVNUIGJlIGFuIGFic29sdXRlIFVSSSBhcyBkZWZpbmVk IGJ5CiAgICAgICAgICAgIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjUkZDMzk4Nic+W1JGQzM5ODZd PHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkJlcm5lcnMtTGVlLCBULiwgRmllbGRp bmcsIFIuLCBhbmQgTC4gTWFzaW50ZXIsICZsZHF1bztVbmlmb3JtIFJlc291cmNlIElkZW50aWZp ZXIgKFVSSSk6IEdlbmVyaWMgU3ludGF4LCZyZHF1bzsgSmFudWFyeSZuYnNwOzIwMDUuPC9zcGFu PjxzcGFuPik8L3NwYW4+PC9hPiBzZWN0aW9uIDQuMy4gVGhlIGVuZHBvaW50IFVSSSBNQVkgaW5j bHVkZSBhbgogICAgICAgICAgICA8dHQ+YXBwbGljYXRpb24veC13d3ctZm9ybS11cmxlbmNvZGVk PC90dD4gZm9ybWF0dGVkCiAgICAgICAgICAgICg8YSBjbGFzcz0naW5mbycgaHJlZj0nI1czQy5S RUMtaHRtbDQwMS0xOTk5MTIyNCc+W1czQy5SRUMmIzgyMDk7aHRtbDQwMSYjODIwOTsxOTk5MTIy NF08c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+SG9ycywgQS4sIFJhZ2dldHQsIEQu LCBhbmQgSS4gSmFjb2JzLCAmbGRxdW87SFRNTCA0LjAxIFNwZWNpZmljYXRpb24sJnJkcXVvOyBE ZWNlbWJlciZuYnNwOzE5OTkuPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPikgcXVlcnkgY29tcG9u ZW50ICg8YSBjbGFzcz0naW5mbycgaHJlZj0nI1JGQzM5ODYnPltSRkMzOTg2XTxzcGFuPiAoPC9z cGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5CZXJuZXJzLUxlZSwgVC4sIEZpZWxkaW5nLCBSLiwgYW5k IEwuIE1hc2ludGVyLCAmbGRxdW87VW5pZm9ybSBSZXNvdXJjZSBJZGVudGlmaWVyIChVUkkpOiBH ZW5lcmljIFN5bnRheCwmcmRxdW87IEphbnVhcnkmbmJzcDsyMDA1Ljwvc3Bhbj48c3Bhbj4pPC9z cGFuPjwvYT4KICAgICAgICAgICAgc2VjdGlvbiAzLjQpLCB3aGljaCBNVVNUIGJlIHJldGFpbmVk IHdoZW4gYWRkaW5nIGFkZGl0aW9uYWwgcXVlcnkgcGFyYW1ldGVycy4gVGhlCiAgICAgICAgICAg IGVuZHBvaW50IFVSSSBNVVNUIE5PVCBpbmNsdWRlIGEgZnJhZ21lbnQgY29tcG9uZW50LgogICAg ICAgICAgCjwvcD4KPGEgbmFtZT0iYW5jaG9yMTkiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1 bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9D YnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+ Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlv bi4zLjEuMi4xIj48L2E+PGgzPjMuMS4yLjEuJm5ic3A7CkVuZHBvaW50IFJlcXVlc3QgQ29uZmlk ZW50aWFsaXR5PC9oMz4KCjxwPgogICAgICAgICAgICAgIFRoZSByZWRpcmVjdGlvbiBlbmRwb2lu dCBTSE9VTEQgcmVxdWlyZSB0aGUgdXNlIG9mIFRMUyBhcyBkZXNjcmliZWQgaW4KICAgICAgICAg ICAgICA8YSBjbGFzcz0naW5mbycgaHJlZj0nI3Rscyc+U2VjdGlvbiZuYnNwOzEuNjxzcGFuPiAo PC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5UTFMgVmVyc2lvbjwvc3Bhbj48c3Bhbj4pPC9zcGFu PjwvYT4gd2hlbiB0aGUgcmVxdWVzdGVkIHJlc3BvbnNlIHR5cGUgaXMKICAgICAgICAgICAgICA8 dHQ+Y29kZTwvdHQ+IG9yIDx0dD50b2tlbjwvdHQ+LCBvcgogICAgICAgICAgICAgIHdoZW4gdGhl IHJlZGlyZWN0aW9uIHJlcXVlc3Qgd2lsbCByZXN1bHQgaW4gdGhlIHRyYW5zbWlzc2lvbiBvZiBz ZW5zaXRpdmUgY3JlZGVudGlhbHMKICAgICAgICAgICAgICBvdmVyIGFuIG9wZW4gbmV0d29yay4g VGhpcyBzcGVjaWZpY2F0aW9uIGRvZXMgbm90IG1hbmRhdGUgdGhlIHVzZSBvZiBUTFMgYmVjYXVz ZSBhdAogICAgICAgICAgICAgIHRoZSB0aW1lIG9mIHRoaXMgd3JpdGluZywgcmVxdWlyaW5nIGNs aWVudHMgdG8gZGVwbG95IFRMUyBpcyBhIHNpZ25pZmljYW50IGh1cmRsZSBmb3IKICAgICAgICAg ICAgICBtYW55IGNsaWVudCBkZXZlbG9wZXJzLiBJZiBUTFMgaXMgbm90IGF2YWlsYWJsZSwgdGhl IGF1dGhvcml6YXRpb24gc2VydmVyIFNIT1VMRCB3YXJuCiAgICAgICAgICAgICAgdGhlIHJlc291 cmNlIG93bmVyIGFib3V0IHRoZSBpbnNlY3VyZSBlbmRwb2ludCBwcmlvciB0byByZWRpcmVjdGlv biAoZS5nLiBkaXNwbGF5IGEKICAgICAgICAgICAgICBtZXNzYWdlIGR1cmluZyB0aGUgYXV0aG9y aXphdGlvbiByZXF1ZXN0KS4KICAgICAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICAgICAgTGFj ayBvZiB0cmFuc3BvcnQtbGF5ZXIgc2VjdXJpdHkgY2FuIGhhdmUgYSBzZXZlcmUgaW1wYWN0IG9u IHRoZSBzZWN1cml0eSBvZiB0aGUKICAgICAgICAgICAgICBjbGllbnQgYW5kIHRoZSBwcm90ZWN0 ZWQgcmVzb3VyY2VzIGl0IGlzIGF1dGhvcml6ZWQgdG8gYWNjZXNzLiBUaGUgdXNlIG9mCiAgICAg ICAgICAgICAgdHJhbnNwb3J0LWxheWVyIHNlY3VyaXR5IGlzIHBhcnRpY3VsYXJseSBjcml0aWNh bCB3aGVuIHRoZSBhdXRob3JpemF0aW9uIHByb2Nlc3MgaXMKICAgICAgICAgICAgICB1c2VkIGFz IGEgZm9ybSBvZiBkZWxlZ2F0ZWQgZW5kLXVzZXIgYXV0aGVudGljYXRpb24gYnkgdGhlIGNsaWVu dCAoZS5nLiB0aGlyZC1wYXJ0eQogICAgICAgICAgICAgIHNpZ24taW4gc2VydmljZSkuCiAgICAg ICAgICAgIAo8L3A+CjxhIG5hbWU9ImFuY2hvcjIwIj48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBz dW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRP Q2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2Mi PiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rp b24uMy4xLjIuMiI+PC9hPjxoMz4zLjEuMi4yLiZuYnNwOwpSZWdpc3RyYXRpb24gUmVxdWlyZW1l bnRzPC9oMz4KCjxwPgogICAgICAgICAgICAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBNVVNU IHJlcXVpcmUgdGhlIGZvbGxvd2luZyBjbGllbnRzIHRvIHJlZ2lzdGVyIHRoZWlyCiAgICAgICAg ICAgICAgcmVkaXJlY3Rpb24gZW5kcG9pbnQ6CiAgICAgICAgICAgIAo8L3A+CjxwPgogICAgICAg ICAgICAgIDwvcD4KPHVsIGNsYXNzPSJ0ZXh0Ij4KPGxpPgogICAgICAgICAgICAgICAgICBQdWJs aWMgY2xpZW50cy4KICAgICAgICAgICAgICAgIAo8L2xpPgo8bGk+CiAgICAgICAgICAgICAgICAg IENvbmZpZGVudGlhbCBjbGllbnRzIHV0aWxpemluZyB0aGUgaW1wbGljaXQgZ3JhbnQgdHlwZS4K ICAgICAgICAgICAgICAgIAo8L2xpPgo8L3VsPjxwPgogICAgICAgICAgICAKPC9wPgo8cD4KICAg ICAgICAgICAgICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgU0hPVUxEIHJlcXVpcmUgYWxsIGNs aWVudHMgdG8gcmVnaXN0ZXIgdGhlaXIgcmVkaXJlY3Rpb24KICAgICAgICAgICAgICBlbmRwb2lu dCBwcmlvciB0byB1dGlsaXppbmcgdGhlIGF1dGhvcml6YXRpb24gZW5kcG9pbnQuCiAgICAgICAg ICAgIAo8L3A+CjxwPgogICAgICAgICAgICAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBTSE9V TEQgcmVxdWlyZSB0aGUgY2xpZW50IHRvIHByb3ZpZGUgdGhlIGNvbXBsZXRlCiAgICAgICAgICAg ICAgcmVkaXJlY3Rpb24gVVJJICh0aGUgY2xpZW50IE1BWSB1c2UgdGhlIDx0dD5zdGF0ZTwvdHQ+ IHJlcXVlc3QKICAgICAgICAgICAgICBwYXJhbWV0ZXIgdG8gYWNoaWV2ZSBwZXItcmVxdWVzdCBj dXN0b21pemF0aW9uKS4gSWYgcmVxdWlyaW5nIHRoZSByZWdpc3RyYXRpb24gb2YKICAgICAgICAg ICAgICB0aGUgY29tcGxldGUgcmVkaXJlY3Rpb24gVVJJIGlzIG5vdCBwb3NzaWJsZSwgdGhlIGF1 dGhvcml6YXRpb24gc2VydmVyIFNIT1VMRCByZXF1aXJlCiAgICAgICAgICAgICAgdGhlIHJlZ2lz dHJhdGlvbiBvZiB0aGUgVVJJIHNjaGVtZSwgYXV0aG9yaXR5LCBhbmQgcGF0aCAoYWxsb3dpbmcg dGhlIGNsaWVudCB0bwogICAgICAgICAgICAgIGR5bmFtaWNhbGx5IHZhcnkgb25seSB0aGUgcXVl cnkgY29tcG9uZW50IG9mIHRoZSByZWRpcmVjdGlvbiBVUkkgd2hlbiByZXF1ZXN0aW5nCiAgICAg ICAgICAgICAgYXV0aG9yaXphdGlvbikuCiAgICAgICAgICAgIAo8L3A+CjxwPgogICAgICAgICAg ICAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBNQVkgYWxsb3cgdGhlIGNsaWVudCB0byByZWdp c3RlciBtdWx0aXBsZSByZWRpcmVjdGlvbgogICAgICAgICAgICAgIGVuZHBvaW50cy4KICAgICAg ICAgICAgCjwvcD4KPHA+CiAgICAgICAgICAgICAgTGFjayBvZiBhIHJlZGlyZWN0aW9uIFVSSSBy ZWdpc3RyYXRpb24gcmVxdWlyZW1lbnQgY2FuIGVuYWJsZSBhbiBhdHRhY2tlciB0byB1c2UKICAg ICAgICAgICAgICB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludCBhcyBvcGVuIHJlZGlyZWN0b3Ig YXMgZGVzY3JpYmVkIGluCiAgICAgICAgICAgICAgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNvcGVu LXJlZGlyZWN0Jz5TZWN0aW9uJm5ic3A7MTAuMTU8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0n aW5mbyc+T3BlbiBSZWRpcmVjdG9yczwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4uCiAgICAgICAg ICAgIAo8L3A+CjxhIG5hbWU9ImFuY2hvcjIxIj48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1t YXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1 ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZu YnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24u My4xLjIuMyI+PC9hPjxoMz4zLjEuMi4zLiZuYnNwOwpEeW5hbWljIENvbmZpZ3VyYXRpb248L2gz PgoKPHA+CiAgICAgICAgICAgICAgSWYgbXVsdGlwbGUgcmVkaXJlY3Rpb24gVVJJcyBoYXZlIGJl ZW4gcmVnaXN0ZXJlZCwgaWYgb25seSBwYXJ0IG9mIHRoZSByZWRpcmVjdGlvbgogICAgICAgICAg ICAgIFVSSSBoYXMgYmVlbiByZWdpc3RlcmVkLCBvciBpZiBubyByZWRpcmVjdGlvbiBVUkkgaGFz IGJlZW4gcmVnaXN0ZXJlZCwgdGhlIGNsaWVudAogICAgICAgICAgICAgIE1VU1QgaW5jbHVkZSBh IHJlZGlyZWN0aW9uIFVSSSB3aXRoIHRoZSBhdXRob3JpemF0aW9uIHJlcXVlc3QgdXNpbmcgdGhl CiAgICAgICAgICAgICAgPHR0PnJlZGlyZWN0X3VyaTwvdHQ+IHJlcXVlc3QgcGFyYW1ldGVyLgog ICAgICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgICAgICBXaGVuIGEgcmVkaXJlY3Rpb24gVVJJ IGlzIGluY2x1ZGVkIGluIGFuIGF1dGhvcml6YXRpb24gcmVxdWVzdCwgdGhlIGF1dGhvcml6YXRp b24KICAgICAgICAgICAgICBzZXJ2ZXIgTVVTVCBjb21wYXJlIGFuZCBtYXRjaCB0aGUgdmFsdWUg cmVjZWl2ZWQgYWdhaW5zdCBhdCBsZWFzdCBvbmUgb2YgdGhlCiAgICAgICAgICAgICAgcmVnaXN0 ZXJlZCByZWRpcmVjdGlvbiBVUklzIChvciBVUkkgY29tcG9uZW50cykgYXMgZGVmaW5lZCBpbgog ICAgICAgICAgICAgIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjUkZDMzk4Nic+W1JGQzM5ODZdPHNw YW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkJlcm5lcnMtTGVlLCBULiwgRmllbGRpbmcs IFIuLCBhbmQgTC4gTWFzaW50ZXIsICZsZHF1bztVbmlmb3JtIFJlc291cmNlIElkZW50aWZpZXIg KFVSSSk6IEdlbmVyaWMgU3ludGF4LCZyZHF1bzsgSmFudWFyeSZuYnNwOzIwMDUuPC9zcGFuPjxz cGFuPik8L3NwYW4+PC9hPiBzZWN0aW9uIDYsIGlmIGFueSByZWRpcmVjdGlvbiBVUklzIHdlcmUg cmVnaXN0ZXJlZC4KICAgICAgICAgICAgICBJZiB0aGUgY2xpZW50IHJlZ2lzdHJhdGlvbiBpbmNs dWRlZCB0aGUgZnVsbCByZWRpcmVjdGlvbiBVUkksIHRoZSBhdXRob3JpemF0aW9uCiAgICAgICAg ICAgICAgc2VydmVyIE1VU1QgY29tcGFyZSB0aGUgdHdvIFVSSXMgdXNpbmcgc2ltcGxlIHN0cmlu ZyBjb21wYXJpc29uIGFzIGRlZmluZWQKICAgICAgICAgICAgICBpbiA8YSBjbGFzcz0naW5mbycg aHJlZj0nI1JGQzM5ODYnPltSRkMzOTg2XTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZv Jz5CZXJuZXJzLUxlZSwgVC4sIEZpZWxkaW5nLCBSLiwgYW5kIEwuIE1hc2ludGVyLCAmbGRxdW87 VW5pZm9ybSBSZXNvdXJjZSBJZGVudGlmaWVyIChVUkkpOiBHZW5lcmljIFN5bnRheCwmcmRxdW87 IEphbnVhcnkmbmJzcDsyMDA1Ljwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4gc2VjdGlvbiA2LjIu MS4KICAgICAgICAgICAgCjwvcD4KPGEgbmFtZT0iYW5jaG9yMjIiPjwvYT48YnIgLz48aHIgLz4K PHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBj bGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJl Zj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJy ZmMuc2VjdGlvbi4zLjEuMi40Ij48L2E+PGgzPjMuMS4yLjQuJm5ic3A7CkludmFsaWQgRW5kcG9p bnQ8L2gzPgoKPHA+CiAgICAgICAgICAgICAgSWYgYW4gYXV0aG9yaXphdGlvbiByZXF1ZXN0IGZh aWxzIHZhbGlkYXRpb24gZHVlIHRvIGEgbWlzc2luZywgaW52YWxpZCwgb3IKICAgICAgICAgICAg ICBtaXNtYXRjaGluZyByZWRpcmVjdGlvbiBVUkksIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBT SE9VTEQgaW5mb3JtIHRoZSByZXNvdXJjZQogICAgICAgICAgICAgIG93bmVyIG9mIHRoZSBlcnJv ciwgYW5kIE1VU1QgTk9UIGF1dG9tYXRpY2FsbHkgcmVkaXJlY3QgdGhlIHVzZXItYWdlbnQgdG8g dGhlIGludmFsaWQKICAgICAgICAgICAgICByZWRpcmVjdGlvbiBVUkkuCiAgICAgICAgICAgIAo8 L3A+CjxhIG5hbWU9ImFuY2hvcjIzIj48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJs YXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxp Z249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RP QyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uMy4xLjIu NSI+PC9hPjxoMz4zLjEuMi41LiZuYnNwOwpFbmRwb2ludCBDb250ZW50PC9oMz4KCjxwPgogICAg ICAgICAgICAgIFRoZSByZWRpcmVjdGlvbiByZXF1ZXN0IHRvIHRoZSBjbGllbnQncyBlbmRwb2lu dCB0eXBpY2FsbHkgcmVzdWx0cyBpbiBhbiBIVE1MCiAgICAgICAgICAgICAgZG9jdW1lbnQgcmVz cG9uc2UsIHByb2Nlc3NlZCBieSB0aGUgdXNlci1hZ2VudC4gSWYgdGhlIEhUTUwgcmVzcG9uc2Ug aXMgc2VydmVkCiAgICAgICAgICAgICAgZGlyZWN0bHkgYXMgdGhlIHJlc3VsdCBvZiB0aGUgcmVk aXJlY3Rpb24gcmVxdWVzdCwgYW55IHNjcmlwdCBpbmNsdWRlZCBpbiB0aGUgSFRNTAogICAgICAg ICAgICAgIGRvY3VtZW50IHdpbGwgZXhlY3V0ZSB3aXRoIGZ1bGwgYWNjZXNzIHRvIHRoZSByZWRp cmVjdGlvbiBVUkkgYW5kIHRoZSBjcmVkZW50aWFscyBpdAogICAgICAgICAgICAgIGNvbnRhaW5z LgogICAgICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgICAgICBUaGUgY2xpZW50IFNIT1VMRCBO T1QgaW5jbHVkZSBhbnkgdGhpcmQtcGFydHkgc2NyaXB0cyAoZS5nLiB0aGlyZC1wYXJ0eSBhbmFs eXRpY3MsCiAgICAgICAgICAgICAgc29jaWFsIHBsdWctaW5zLCBhZCBuZXR3b3JrcykgaW4gdGhl IHJlZGlyZWN0aW9uIGVuZHBvaW50IHJlc3BvbnNlLiBJbnN0ZWFkLCBpdAogICAgICAgICAgICAg IFNIT1VMRCBleHRyYWN0IHRoZSBjcmVkZW50aWFscyBmcm9tIHRoZSBVUkkgYW5kIHJlZGlyZWN0 IHRoZSB1c2VyLWFnZW50IGFnYWluIHRvCiAgICAgICAgICAgICAgYW5vdGhlciBlbmRwb2ludCB3 aXRob3V0IGV4cG9zaW5nIHRoZSBjcmVkZW50aWFscyAoaW4gdGhlIFVSSSBvciBlbHNld2hlcmUp LiBJZgogICAgICAgICAgICAgIHRoaXJkLXBhcnR5IHNjcmlwdHMgYXJlIGluY2x1ZGVkLCB0aGUg Y2xpZW50IE1VU1QgZW5zdXJlIHRoYXQgaXRzIG93biBzY3JpcHRzCiAgICAgICAgICAgICAgKHVz ZWQgdG8gZXh0cmFjdCBhbmQgcmVtb3ZlIHRoZSBjcmVkZW50aWFscyBmcm9tIHRoZSBVUkkpIHdp bGwgZXhlY3V0ZSBmaXJzdC4KICAgICAgICAgICAgCjwvcD4KPGEgbmFtZT0iYW5jaG9yMjQiPjwv YT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNl bGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9 IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3Rh YmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi4zLjIiPjwvYT48aDM+My4yLiZuYnNwOwpUb2tlbiBF bmRwb2ludDwvaDM+Cgo8cD4KICAgICAgICAgIFRoZSB0b2tlbiBlbmRwb2ludCBpcyB1c2VkIGJ5 IHRoZSBjbGllbnQgdG8gb2J0YWluIGFuIGFjY2VzcyB0b2tlbiBieSBwcmVzZW50aW5nIGl0cwog ICAgICAgICAgYXV0aG9yaXphdGlvbiBncmFudCBvciByZWZyZXNoIHRva2VuLiBUaGUgdG9rZW4g ZW5kcG9pbnQgaXMgdXNlZCB3aXRoIGV2ZXJ5IGF1dGhvcml6YXRpb24KICAgICAgICAgIGdyYW50 IGV4Y2VwdCBmb3IgdGhlIGltcGxpY2l0IGdyYW50IHR5cGUgKHNpbmNlIGFuIGFjY2VzcyB0b2tl biBpcyBpc3N1ZWQgZGlyZWN0bHkpLgogICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgVGhlIG1l YW5zIHRocm91Z2ggd2hpY2ggdGhlIGNsaWVudCBvYnRhaW5zIHRoZSBsb2NhdGlvbiBvZiB0aGUg dG9rZW4gZW5kcG9pbnQgYXJlCiAgICAgICAgICBiZXlvbmQgdGhlIHNjb3BlIG9mIHRoaXMgc3Bl Y2lmaWNhdGlvbiBidXQgaXMgdHlwaWNhbGx5IHByb3ZpZGVkIGluIHRoZSBzZXJ2aWNlCiAgICAg ICAgICBkb2N1bWVudGF0aW9uLgogICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgVGhlIGVuZHBv aW50IFVSSSBNQVkgaW5jbHVkZSBhbgogICAgICAgICAgPHR0PmFwcGxpY2F0aW9uL3gtd3d3LWZv cm0tdXJsZW5jb2RlZDwvdHQ+IGZvcm1hdHRlZAogICAgICAgICAgKDxhIGNsYXNzPSdpbmZvJyBo cmVmPScjVzNDLlJFQy1odG1sNDAxLTE5OTkxMjI0Jz5bVzNDLlJFQyYjODIwOTtodG1sNDAxJiM4 MjA5OzE5OTkxMjI0XTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5Ib3JzLCBBLiwg UmFnZ2V0dCwgRC4sIGFuZCBJLiBKYWNvYnMsICZsZHF1bztIVE1MIDQuMDEgU3BlY2lmaWNhdGlv biwmcmRxdW87IERlY2VtYmVyJm5ic3A7MTk5OS48L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+KSBx dWVyeSBjb21wb25lbnQgKDxhIGNsYXNzPSdpbmZvJyBocmVmPScjUkZDMzk4Nic+W1JGQzM5ODZd PHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkJlcm5lcnMtTGVlLCBULiwgRmllbGRp bmcsIFIuLCBhbmQgTC4gTWFzaW50ZXIsICZsZHF1bztVbmlmb3JtIFJlc291cmNlIElkZW50aWZp ZXIgKFVSSSk6IEdlbmVyaWMgU3ludGF4LCZyZHF1bzsgSmFudWFyeSZuYnNwOzIwMDUuPC9zcGFu PjxzcGFuPik8L3NwYW4+PC9hPgogICAgICAgICAgc2VjdGlvbiAzLjQpLCB3aGljaCBNVVNUIGJl IHJldGFpbmVkIHdoZW4gYWRkaW5nIGFkZGl0aW9uYWwgcXVlcnkgcGFyYW1ldGVycy4gVGhlCiAg ICAgICAgICBlbmRwb2ludCBVUkkgTVVTVCBOT1QgaW5jbHVkZSBhIGZyYWdtZW50IGNvbXBvbmVu dC4KICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgIFNpbmNlIHJlcXVlc3RzIHRvIHRoZSB0b2tl biBlbmRwb2ludCByZXN1bHQgaW4gdGhlIHRyYW5zbWlzc2lvbiBvZiBjbGVhci10ZXh0IGNyZWRl bnRpYWxzCiAgICAgICAgICAoaW4gdGhlIEhUVFAgcmVxdWVzdCBhbmQgcmVzcG9uc2UpLCB0aGUg YXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVTVCByZXF1aXJlIHRoZSB1c2Ugb2YgVExTCiAgICAgICAg ICBhcyBkZXNjcmliZWQgaW4gPGEgY2xhc3M9J2luZm8nIGhyZWY9JyN0bHMnPlNlY3Rpb24mbmJz cDsxLjY8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+VExTIFZlcnNpb248L3NwYW4+ PHNwYW4+KTwvc3Bhbj48L2E+IHdoZW4gc2VuZGluZyByZXF1ZXN0cyB0byB0aGUgdG9rZW4gZW5k cG9pbnQuCiAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICBUaGUgY2xpZW50IE1VU1QgdXNlIHRo ZSBIVFRQIDx0dD5QT1NUPC90dD4gbWV0aG9kIHdoZW4gbWFraW5nIGFjY2VzcwogICAgICAgICAg dG9rZW4gcmVxdWVzdHMuCiAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICBQYXJhbWV0ZXJzIHNl bnQgd2l0aG91dCBhIHZhbHVlIE1VU1QgYmUgdHJlYXRlZCBhcyBpZiB0aGV5IHdlcmUgb21pdHRl ZCBmcm9tIHRoZSByZXF1ZXN0LgogICAgICAgICAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIE1V U1QgaWdub3JlIHVucmVjb2duaXplZCByZXF1ZXN0IHBhcmFtZXRlcnMuIFJlcXVlc3QgYW5kCiAg ICAgICAgICByZXNwb25zZSBwYXJhbWV0ZXJzIE1VU1QgTk9UIGJlIGluY2x1ZGVkIG1vcmUgdGhh biBvbmNlLgogICAgICAgIAo8L3A+CjxhIG5hbWU9InRva2VuLWVuZHBvaW50LWF1dGgiPjwvYT48 YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxz cGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRP Q2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxl Pgo8YSBuYW1lPSJyZmMuc2VjdGlvbi4zLjIuMSI+PC9hPjxoMz4zLjIuMS4mbmJzcDsKQ2xpZW50 IEF1dGhlbnRpY2F0aW9uPC9oMz4KCjxwPgogICAgICAgICAgICBDb25maWRlbnRpYWwgY2xpZW50 cyBvciBvdGhlciBjbGllbnRzIGlzc3VlZCBjbGllbnQgY3JlZGVudGlhbHMgTVVTVCBhdXRoZW50 aWNhdGUgd2l0aAogICAgICAgICAgICB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYXMgZGVzY3Jp YmVkIGluIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjY2xpZW50LWF1dGhlbnRpY2F0aW9uJz5TZWN0 aW9uJm5ic3A7Mi4zPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkNsaWVudCBBdXRo ZW50aWNhdGlvbjwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4gd2hlbgogICAgICAgICAgICBtYWtp bmcgcmVxdWVzdHMgdG8gdGhlIHRva2VuIGVuZHBvaW50LiBDbGllbnQgYXV0aGVudGljYXRpb24g aXMgdXNlZCBmb3I6CiAgICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgICAgPC9wPgo8dWwgY2xh c3M9InRleHQiPgo8bGk+CiAgICAgICAgICAgICAgICBFbmZvcmNpbmcgdGhlIGJpbmRpbmcgb2Yg cmVmcmVzaCB0b2tlbnMgYW5kIGF1dGhvcml6YXRpb24gY29kZXMgdG8gdGhlIGNsaWVudCB0aGV5 CiAgICAgICAgICAgICAgICB3ZXJlIGlzc3VlZCB0by4gQ2xpZW50IGF1dGhlbnRpY2F0aW9uIGlz IGNyaXRpY2FsIHdoZW4gYW4gYXV0aG9yaXphdGlvbiBjb2RlIGlzCiAgICAgICAgICAgICAgICB0 cmFuc21pdHRlZCB0byB0aGUgcmVkaXJlY3Rpb24gZW5kcG9pbnQgb3ZlciBhbiBpbnNlY3VyZSBj aGFubmVsLCBvciB3aGVuIHRoZQogICAgICAgICAgICAgICAgcmVkaXJlY3Rpb24gVVJJIGhhcyBu b3QgYmVlbiByZWdpc3RlcmVkIGluIGZ1bGwuCiAgICAgICAgICAgICAgCjwvbGk+CjxsaT4KICAg ICAgICAgICAgICAgIFJlY292ZXJpbmcgZnJvbSBhIGNvbXByb21pc2VkIGNsaWVudCBieSBkaXNh YmxpbmcgdGhlIGNsaWVudCBvciBjaGFuZ2luZyBpdHMKICAgICAgICAgICAgICAgIGNyZWRlbnRp YWxzLCB0aHVzIHByZXZlbnRpbmcgYW4gYXR0YWNrZXIgZnJvbSBhYnVzaW5nIHN0b2xlbiByZWZy ZXNoIHRva2Vucy4gQ2hhbmdpbmcKICAgICAgICAgICAgICAgIGEgc2luZ2xlIHNldCBvZiBjbGll bnQgY3JlZGVudGlhbHMgaXMgc2lnbmlmaWNhbnRseSBmYXN0ZXIgdGhhbiByZXZva2luZyBhbiBl bnRpcmUKICAgICAgICAgICAgICAgIHNldCBvZiByZWZyZXNoIHRva2Vucy4KICAgICAgICAgICAg ICAKPC9saT4KPGxpPgogICAgICAgICAgICAgICAgSW1wbGVtZW50aW5nIGF1dGhlbnRpY2F0aW9u IG1hbmFnZW1lbnQgYmVzdCBwcmFjdGljZXMgd2hpY2ggcmVxdWlyZSBwZXJpb2RpYwogICAgICAg ICAgICAgICAgY3JlZGVudGlhbCByb3RhdGlvbi4gUm90YXRpb24gb2YgYW4gZW50aXJlIHNldCBv ZiByZWZyZXNoIHRva2VucyBjYW4gYmUKICAgICAgICAgICAgICAgIGNoYWxsZW5naW5nLCB3aGls ZSByb3RhdGlvbiBvZiBhIHNpbmdsZSBzZXQgb2YgY2xpZW50IGNyZWRlbnRpYWxzIGlzIHNpZ25p ZmljYW50bHkKICAgICAgICAgICAgICAgIGVhc2llci4KICAgICAgICAgICAgICAKPC9saT4KPC91 bD48cD4KICAgICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgICBBIHB1YmxpYyBjbGllbnQgdGhh dCB3YXMgbm90IGlzc3VlZCBhIGNsaWVudCBwYXNzd29yZCBNQVkgdXNlIHRoZQogICAgICAgICAg ICA8dHQ+Y2xpZW50X2lkPC90dD4gcmVxdWVzdCBwYXJhbWV0ZXIgdG8gaWRlbnRpZnkgaXRzZWxm IHdoZW4gc2VuZGluZwogICAgICAgICAgICByZXF1ZXN0cyB0byB0aGUgdG9rZW4gZW5kcG9pbnQg KGUuZy4gZm9yIHRoZSBwdXJwb3NlIG9mIHByb3ZpZGluZyBlbmQtdXNlciBjb250ZXh0LAogICAg ICAgICAgICBjbGllbnQgdXNhZ2Ugc3RhdGlzdGljcykuCiAgICAgICAgICAKPC9wPgo8YSBuYW1l PSJzY29wZSI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFk ZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRy Pjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90 ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLjMuMyI+PC9hPjxoMz4zLjMuJm5i c3A7CkFjY2VzcyBUb2tlbiBTY29wZTwvaDM+Cgo8cD4KICAgICAgICAgIFRoZSBhdXRob3JpemF0 aW9uIGFuZCB0b2tlbiBlbmRwb2ludHMgYWxsb3cgdGhlIGNsaWVudCB0byBzcGVjaWZ5IHRoZSBz Y29wZSBvZiB0aGUgYWNjZXNzCiAgICAgICAgICByZXF1ZXN0IHVzaW5nIHRoZSA8dHQ+c2NvcGU8 L3R0PiByZXF1ZXN0IHBhcmFtZXRlci4gSW4gdHVybiwgdGhlCiAgICAgICAgICBhdXRob3JpemF0 aW9uIHNlcnZlciB1c2VzIHRoZSA8dHQ+c2NvcGU8L3R0PiByZXNwb25zZSBwYXJhbWV0ZXIgdG8K ICAgICAgICAgIGluZm9ybSB0aGUgY2xpZW50IG9mIHRoZSBzY29wZSBvZiB0aGUgYWNjZXNzIHRv a2VuIGlzc3VlZC4KICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgIFRoZSB2YWx1ZSBvZiB0aGUg c2NvcGUgcGFyYW1ldGVyIGlzIGV4cHJlc3NlZCBhcyBhIGxpc3Qgb2Ygc3BhY2UtZGVsaW1pdGVk LCBjYXNlCiAgICAgICAgICBzZW5zaXRpdmUgc3RyaW5ncy4gVGhlIHN0cmluZ3MgYXJlIGRlZmlu ZWQgYnkgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLiBJZiB0aGUgdmFsdWUKICAgICAgICAgIGNv bnRhaW5zIG11bHRpcGxlIHNwYWNlLWRlbGltaXRlZCBzdHJpbmdzLCB0aGVpciBvcmRlciBkb2Vz IG5vdCBtYXR0ZXIsIGFuZCBlYWNoIHN0cmluZwogICAgICAgICAgYWRkcyBhbiBhZGRpdGlvbmFs IGFjY2VzcyByYW5nZSB0byB0aGUgcmVxdWVzdGVkIHNjb3BlLgogICAgICAgIAo8L3A+PGRpdiBz dHlsZT0nZGlzcGxheTogdGFibGU7IHdpZHRoOiAwOyBtYXJnaW4tbGVmdDogM2VtOyBtYXJnaW4t cmlnaHQ6IGF1dG8nPjxwcmU+CgogIHNjb3BlICAgICAgID0gc2NvcGUtdG9rZW4gKiggU1Agc2Nv cGUtdG9rZW4gKQogIHNjb3BlLXRva2VuID0gMSooICV4MjEgLyAleDIzLTVCIC8gJXg1RC03RSAp Cgo8L3ByZT48L2Rpdj4KPHA+CiAgICAgICAgICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTUFZ IGZ1bGx5IG9yIHBhcnRpYWxseSBpZ25vcmUgdGhlIHNjb3BlIHJlcXVlc3RlZCBieSB0aGUgY2xp ZW50CiAgICAgICAgICBiYXNlZCBvbiB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgcG9saWN5IG9y IHRoZSByZXNvdXJjZSBvd25lcidzIGluc3RydWN0aW9ucy4gSWYgdGhlCiAgICAgICAgICBpc3N1 ZWQgYWNjZXNzIHRva2VuIHNjb3BlIGlzIGRpZmZlcmVudCBmcm9tIHRoZSBvbmUgcmVxdWVzdGVk IGJ5IHRoZSBjbGllbnQsIHRoZQogICAgICAgICAgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVTVCBp bmNsdWRlIHRoZSA8dHQ+c2NvcGU8L3R0PiByZXNwb25zZQogICAgICAgICAgcGFyYW1ldGVyIHRv IGluZm9ybSB0aGUgY2xpZW50IG9mIHRoZSBhY3R1YWwgc2NvcGUgZ3JhbnRlZC4KICAgICAgICAK PC9wPgo8cD4KICAgICAgICAgIElmIHRoZSBjbGllbnQgb21pdHMgdGhlIHNjb3BlIHBhcmFtZXRl ciB3aGVuIHJlcXVlc3RpbmcgYXV0aG9yaXphdGlvbiwgdGhlIGF1dGhvcml6YXRpb24KICAgICAg ICAgIHNlcnZlciBNVVNUIGVpdGhlciBwcm9jZXNzIHRoZSByZXF1ZXN0IHVzaW5nIGEgcHJlLWRl ZmluZWQgZGVmYXVsdCB2YWx1ZSwgb3IgZmFpbCB0aGUKICAgICAgICAgIHJlcXVlc3QgaW5kaWNh dGluZyBhbiBpbnZhbGlkIHNjb3BlLiBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgU0hPVUxEIGRv Y3VtZW50IGl0cyBzY29wZQogICAgICAgICAgcmVxdWlyZW1lbnRzIGFuZCBkZWZhdWx0IHZhbHVl IChpZiBkZWZpbmVkKS4KICAgICAgICAKPC9wPgo8YSBuYW1lPSJhbmNob3IyNSI+PC9hPjxiciAv PjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNp bmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVn Ij48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+Cjxh IG5hbWU9InJmYy5zZWN0aW9uLjQiPjwvYT48aDM+NC4mbmJzcDsKT2J0YWluaW5nIEF1dGhvcml6 YXRpb248L2gzPgoKPHA+CiAgICAgICAgVG8gcmVxdWVzdCBhbiBhY2Nlc3MgdG9rZW4sIHRoZSBj bGllbnQgb2J0YWlucyBhdXRob3JpemF0aW9uIGZyb20gdGhlIHJlc291cmNlIG93bmVyLiBUaGUK ICAgICAgICBhdXRob3JpemF0aW9uIGlzIGV4cHJlc3NlZCBpbiB0aGUgZm9ybSBvZiBhbiBhdXRo b3JpemF0aW9uIGdyYW50IHdoaWNoIHRoZSBjbGllbnQgdXNlcyB0bwogICAgICAgIHJlcXVlc3Qg dGhlIGFjY2VzcyB0b2tlbi4gT0F1dGggZGVmaW5lcyBmb3VyIGdyYW50IHR5cGVzOiBhdXRob3Jp emF0aW9uIGNvZGUsIGltcGxpY2l0LAogICAgICAgIHJlc291cmNlIG93bmVyIHBhc3N3b3JkIGNy ZWRlbnRpYWxzLCBhbmQgY2xpZW50IGNyZWRlbnRpYWxzLiBJdCBhbHNvIHByb3ZpZGVzIGFuIGV4 dGVuc2lvbgogICAgICAgIG1lY2hhbmlzbSBmb3IgZGVmaW5pbmcgYWRkaXRpb25hbCBncmFudCB0 eXBlcy4KICAgICAgCjwvcD4KPGEgbmFtZT0iZ3JhbnQtY29kZSI+PC9hPjxiciAvPjxociAvPgo8 dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNs YXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVm PSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJm Yy5zZWN0aW9uLjQuMSI+PC9hPjxoMz40LjEuJm5ic3A7CkF1dGhvcml6YXRpb24gQ29kZSBHcmFu dDwvaDM+Cgo8cD4KICAgICAgICAgIFRoZSBhdXRob3JpemF0aW9uIGNvZGUgZ3JhbnQgdHlwZSBp cyB1c2VkIHRvIG9idGFpbiBib3RoIGFjY2VzcyB0b2tlbnMgYW5kIHJlZnJlc2gKICAgICAgICAg IHRva2VucyBhbmQgaXMgb3B0aW1pemVkIGZvciBjb25maWRlbnRpYWwgY2xpZW50cy4gQXMgYSBy ZWRpcmVjdGlvbi1iYXNlZCBmbG93LCB0aGUgY2xpZW50CiAgICAgICAgICBtdXN0IGJlIGNhcGFi bGUgb2YgaW50ZXJhY3Rpbmcgd2l0aCB0aGUgcmVzb3VyY2Ugb3duZXIncyB1c2VyLWFnZW50ICh0 eXBpY2FsbHkgYSB3ZWIKICAgICAgICAgIGJyb3dzZXIpIGFuZCBjYXBhYmxlIG9mIHJlY2Vpdmlu ZyBpbmNvbWluZyByZXF1ZXN0cyAodmlhIHJlZGlyZWN0aW9uKSBmcm9tIHRoZQogICAgICAgICAg YXV0aG9yaXphdGlvbiBzZXJ2ZXIuCiAgICAgICAgCjwvcD48YnIgLz48aHIgY2xhc3M9Imluc2Vy dCIgLz4KPGEgbmFtZT0iRmlndXJlLTMiPjwvYT4KPGRpdiBzdHlsZT0nZGlzcGxheTogdGFibGU7 IHdpZHRoOiAwOyBtYXJnaW4tbGVmdDogM2VtOyBtYXJnaW4tcmlnaHQ6IGF1dG8nPjxwcmU+Cgog ICstLS0tLS0tLS0tKwogIHwgcmVzb3VyY2UgfAogIHwgICBvd25lciAgfAogIHwgICAgICAgICAg fAogICstLS0tLS0tLS0tKwogICAgICAgXgogICAgICAgfAogICAgICAoQikKICArLS0tLXwtLS0t LSsgICAgICAgICAgQ2xpZW50IElkZW50aWZpZXIgICAgICArLS0tLS0tLS0tLS0tLS0tKwogIHwg ICAgICAgICAtKy0tLS0oQSktLSAmYW1wOyBSZWRpcmVjdGlvbiBVUkkgLS0tLSZndDt8ICAgICAg ICAgICAgICAgfAogIHwgIFVzZXItICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHwgQXV0aG9yaXphdGlvbiB8CiAgfCAgQWdlbnQgIC0rLS0tLShCKS0tIFVzZXIgYXV0aGVudGlj YXRlcyAtLS0mZ3Q7fCAgICAgU2VydmVyICAgIHwKICB8ICAgICAgICAgIHwgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgfAogIHwgICAgICAgICAtKy0tLS0o QyktLSBBdXRob3JpemF0aW9uIENvZGUgLS0tJmx0O3wgICAgICAgICAgICAgICB8CiAgKy18LS0t LXwtLS0rICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLSsK ICAgIHwgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXiAgICAg IHYKICAgKEEpICAoQykgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAg ICAgIHwKICAgIHwgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg fCAgICAgIHwKICAgIF4gICAgdiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgfCAgICAgIHwKICArLS0tLS0tLS0tKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgfCAgICAgIHwKICB8ICAgICAgICAgfCZndDstLS0oRCktLSBBdXRob3JpemF0aW9uIENv ZGUgLS0tLS0tLS0tJyAgICAgIHwKICB8ICBDbGllbnQgfCAgICAgICAgICAmYW1wOyBSZWRpcmVj dGlvbiBVUkkgICAgICAgICAgICAgICAgICB8CiAgfCAgICAgICAgIHwgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgfCAgICAgICAgIHwmbHQ7LS0tKEUpLS0t LS0gQWNjZXNzIFRva2VuIC0tLS0tLS0tLS0tLS0tLS0tLS0nCiAgKy0tLS0tLS0tLSsgICAgICAg KHcvIE9wdGlvbmFsIFJlZnJlc2ggVG9rZW4pCgo8L3ByZT48L2Rpdj4KPHA+CiAgICAgICAgICAg IE5vdGU6IFRoZSBsaW5lcyBpbGx1c3RyYXRpbmcgc3RlcHMgQSwgQiwgYW5kIEMgYXJlIGJyb2tl biBpbnRvIHR3byBwYXJ0cyBhcyB0aGV5IHBhc3MKICAgICAgICAgICAgdGhyb3VnaCB0aGUgdXNl ci1hZ2VudC4KICAgICAgICAgIAo8L3A+PHRhYmxlIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAi IGNlbGxzcGFjaW5nPSIyIiBhbGlnbj0iY2VudGVyIj48dHI+PHRkIGFsaWduPSJjZW50ZXIiPjxm b250IGZhY2U9Im1vbmFjbywgTVMgU2FucyBTZXJpZiIgc2l6ZT0iMSI+PGI+Jm5ic3A7RmlndXJl Jm5ic3A7MzogQXV0aG9yaXphdGlvbiBDb2RlIEZsb3cmbmJzcDs8L2I+PC9mb250PjxiciAvPjwv dGQ+PC90cj48L3RhYmxlPjxociBjbGFzcz0iaW5zZXJ0IiAvPgoKPHA+CiAgICAgICAgICBUaGUg ZmxvdyBpbGx1c3RyYXRlZCBpbiA8YSBjbGFzcz0naW5mbycgaHJlZj0nI0ZpZ3VyZS0zJz5GaWd1 cmUmbmJzcDszPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkF1dGhvcml6YXRpb24g Q29kZSBGbG93PC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPiBpbmNsdWRlcyB0aGUgZm9sbG93aW5n IHN0ZXBzOgogICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgPC9wPgo8YmxvY2txdW90ZSBjbGFz cz0idGV4dCI+PGRsPgo8ZHQ+KEEpPC9kdD4KPGRkPgogICAgICAgICAgICAgIFRoZSBjbGllbnQg aW5pdGlhdGVzIHRoZSBmbG93IGJ5IGRpcmVjdGluZyB0aGUgcmVzb3VyY2Ugb3duZXIncyB1c2Vy LWFnZW50IHRvIHRoZQogICAgICAgICAgICAgIGF1dGhvcml6YXRpb24gZW5kcG9pbnQuIFRoZSBj bGllbnQgaW5jbHVkZXMgaXRzIGNsaWVudCBpZGVudGlmaWVyLCByZXF1ZXN0ZWQKICAgICAgICAg ICAgICBzY29wZSwgbG9jYWwgc3RhdGUsIGFuZCBhIHJlZGlyZWN0aW9uIFVSSSB0byB3aGljaCB0 aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgd2lsbCBzZW5kCiAgICAgICAgICAgICAgdGhlIHVzZXIt YWdlbnQgYmFjayBvbmNlIGFjY2VzcyBpcyBncmFudGVkIChvciBkZW5pZWQpLgogICAgICAgICAg ICAKPC9kZD4KPGR0PihCKTwvZHQ+CjxkZD4KICAgICAgICAgICAgICBUaGUgYXV0aG9yaXphdGlv biBzZXJ2ZXIgYXV0aGVudGljYXRlcyB0aGUgcmVzb3VyY2Ugb3duZXIgKHZpYSB0aGUgdXNlci1h Z2VudCkgYW5kCiAgICAgICAgICAgICAgZXN0YWJsaXNoZXMgd2hldGhlciB0aGUgcmVzb3VyY2Ug b3duZXIgZ3JhbnRzIG9yIGRlbmllcyB0aGUgY2xpZW50J3MgYWNjZXNzIHJlcXVlc3QuCiAgICAg ICAgICAgIAo8L2RkPgo8ZHQ+KEMpPC9kdD4KPGRkPgogICAgICAgICAgICAgIEFzc3VtaW5nIHRo ZSByZXNvdXJjZSBvd25lciBncmFudHMgYWNjZXNzLCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIg cmVkaXJlY3RzIHRoZQogICAgICAgICAgICAgIHVzZXItYWdlbnQgYmFjayB0byB0aGUgY2xpZW50 IHVzaW5nIHRoZSByZWRpcmVjdGlvbiBVUkkgcHJvdmlkZWQgZWFybGllciAoaW4gdGhlCiAgICAg ICAgICAgICAgcmVxdWVzdCBvciBkdXJpbmcgY2xpZW50IHJlZ2lzdHJhdGlvbikuIFRoZSByZWRp cmVjdGlvbiBVUkkgaW5jbHVkZXMgYW4gYXV0aG9yaXphdGlvbgogICAgICAgICAgICAgIGNvZGUg YW5kIGFueSBsb2NhbCBzdGF0ZSBwcm92aWRlZCBieSB0aGUgY2xpZW50IGVhcmxpZXIuCiAgICAg ICAgICAgIAo8L2RkPgo8ZHQ+KEQpPC9kdD4KPGRkPgogICAgICAgICAgICAgIFRoZSBjbGllbnQg cmVxdWVzdHMgYW4gYWNjZXNzIHRva2VuIGZyb20gdGhlIGF1dGhvcml6YXRpb24gc2VydmVyJ3Mg dG9rZW4gZW5kcG9pbnQKICAgICAgICAgICAgICBieSBpbmNsdWRpbmcgdGhlIGF1dGhvcml6YXRp b24gY29kZSByZWNlaXZlZCBpbiB0aGUgcHJldmlvdXMgc3RlcC4gV2hlbiBtYWtpbmcgdGhlCiAg ICAgICAgICAgICAgcmVxdWVzdCwgdGhlIGNsaWVudCBhdXRoZW50aWNhdGVzIHdpdGggdGhlIGF1 dGhvcml6YXRpb24gc2VydmVyLiBUaGUgY2xpZW50IGluY2x1ZGVzCiAgICAgICAgICAgICAgdGhl IHJlZGlyZWN0aW9uIFVSSSB1c2VkIHRvIG9idGFpbiB0aGUgYXV0aG9yaXphdGlvbiBjb2RlIGZv ciB2ZXJpZmljYXRpb24uCiAgICAgICAgICAgIAo8L2RkPgo8ZHQ+KEUpPC9kdD4KPGRkPgogICAg ICAgICAgICAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBhdXRoZW50aWNhdGVzIHRoZSBjbGll bnQsIHZhbGlkYXRlcyB0aGUgYXV0aG9yaXphdGlvbiBjb2RlLAogICAgICAgICAgICAgIGFuZCBl bnN1cmVzIHRoZSByZWRpcmVjdGlvbiBVUkkgcmVjZWl2ZWQgbWF0Y2hlcyB0aGUgVVJJIHVzZWQg dG8gcmVkaXJlY3QgdGhlIGNsaWVudAogICAgICAgICAgICAgIGluIHN0ZXAgKEMpLiBJZiB2YWxp ZCwgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHJlc3BvbmRzIGJhY2sgd2l0aCBhbiBhY2Nlc3Mg dG9rZW4KICAgICAgICAgICAgICBhbmQgb3B0aW9uYWxseSwgYSByZWZyZXNoIHRva2VuLgogICAg ICAgICAgICAKPC9kZD4KPC9kbD48L2Jsb2NrcXVvdGU+PHA+CiAgICAgICAgCjwvcD4KPGEgbmFt ZT0iY29kZS1hdXRoei1yZXEiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91 dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0i cmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5i c3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi40LjEuMSI+PC9h PjxoMz40LjEuMS4mbmJzcDsKQXV0aG9yaXphdGlvbiBSZXF1ZXN0PC9oMz4KCjxwPgogICAgICAg ICAgICBUaGUgY2xpZW50IGNvbnN0cnVjdHMgdGhlIHJlcXVlc3QgVVJJIGJ5IGFkZGluZyB0aGUg Zm9sbG93aW5nIHBhcmFtZXRlcnMgdG8gdGhlCiAgICAgICAgICAgIHF1ZXJ5IGNvbXBvbmVudCBv ZiB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludCBVUkkgdXNpbmcgdGhlCiAgICAgICAgICAgIDx0 dD5hcHBsaWNhdGlvbi94LXd3dy1mb3JtLXVybGVuY29kZWQ8L3R0PiBmb3JtYXQgYXMgZGVmaW5l ZCBieQogICAgICAgICAgICA8YSBjbGFzcz0naW5mbycgaHJlZj0nI1czQy5SRUMtaHRtbDQwMS0x OTk5MTIyNCc+W1czQy5SRUMmIzgyMDk7aHRtbDQwMSYjODIwOTsxOTk5MTIyNF08c3Bhbj4gKDwv c3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+SG9ycywgQS4sIFJhZ2dldHQsIEQuLCBhbmQgSS4gSmFj b2JzLCAmbGRxdW87SFRNTCA0LjAxIFNwZWNpZmljYXRpb24sJnJkcXVvOyBEZWNlbWJlciZuYnNw OzE5OTkuPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPjoKICAgICAgICAgIAo8L3A+CjxwPgogICAg ICAgICAgICA8L3A+CjxibG9ja3F1b3RlIGNsYXNzPSJ0ZXh0Ij48ZGw+CjxkdD5yZXNwb25zZV90 eXBlPC9kdD4KPGRkPgogICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICBSRVFVSVJFRC4g VmFsdWUgTVVTVCBiZSBzZXQgdG8gPHR0PmNvZGU8L3R0Pi4KICAgICAgICAgICAgICAKPC9kZD4K PGR0PmNsaWVudF9pZDwvZHQ+CjxkZD4KICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAg UkVRVUlSRUQuIFRoZSBjbGllbnQgaWRlbnRpZmllciBhcyBkZXNjcmliZWQgaW4KICAgICAgICAg ICAgICAgIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjY2xpZW50LWlkZW50aWZpZXInPlNlY3Rpb24m bmJzcDsyLjI8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+Q2xpZW50IElkZW50aWZp ZXI8L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+LgogICAgICAgICAgICAgIAo8L2RkPgo8ZHQ+cmVk aXJlY3RfdXJpPC9kdD4KPGRkPgogICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICBPUFRJ T05BTC4gQXMgZGVzY3JpYmVkIGluIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjcmVkaXJlY3QtdXJp Jz5TZWN0aW9uJm5ic3A7My4xLjI8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+UmVk aXJlY3Rpb24gRW5kcG9pbnQ8L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+LgogICAgICAgICAgICAg IAo8L2RkPgo8ZHQ+c2NvcGU8L2R0Pgo8ZGQ+CiAgICAgICAgICAgICAgICAKICAgICAgICAgICAg ICAgIE9QVElPTkFMLiBUaGUgc2NvcGUgb2YgdGhlIGFjY2VzcyByZXF1ZXN0IGFzIGRlc2NyaWJl ZCBieSA8YSBjbGFzcz0naW5mbycgaHJlZj0nI3Njb3BlJz5TZWN0aW9uJm5ic3A7My4zPHNwYW4+ ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkFjY2VzcyBUb2tlbiBTY29wZTwvc3Bhbj48c3Bh bj4pPC9zcGFuPjwvYT4uCiAgICAgICAgICAgICAgCjwvZGQ+CjxkdD5zdGF0ZTwvZHQ+CjxkZD4K ICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgUkVDT01NRU5ERUQuIEFuIG9wYXF1ZSB2 YWx1ZSB1c2VkIGJ5IHRoZSBjbGllbnQgdG8gbWFpbnRhaW4gc3RhdGUgYmV0d2VlbiB0aGUgcmVx dWVzdAogICAgICAgICAgICAgICAgYW5kIGNhbGxiYWNrLiBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2 ZXIgaW5jbHVkZXMgdGhpcyB2YWx1ZSB3aGVuIHJlZGlyZWN0aW5nIHRoZQogICAgICAgICAgICAg ICAgdXNlci1hZ2VudCBiYWNrIHRvIHRoZSBjbGllbnQuIFRoZSBwYXJhbWV0ZXIgU0hPVUxEIGJl IHVzZWQgZm9yIHByZXZlbnRpbmcKICAgICAgICAgICAgICAgIGNyb3NzLXNpdGUgcmVxdWVzdCBm b3JnZXJ5IGFzIGRlc2NyaWJlZCBpbiA8YSBjbGFzcz0naW5mbycgaHJlZj0nI0NTUkYnPlNlY3Rp b24mbmJzcDsxMC4xMjxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5Dcm9zcy1TaXRl IFJlcXVlc3QgRm9yZ2VyeTwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4uCiAgICAgICAgICAgICAg CjwvZGQ+CjwvZGw+PC9ibG9ja3F1b3RlPjxwPgogICAgICAgICAgCjwvcD4KPHA+CiAgICAgICAg ICAgIFRoZSBjbGllbnQgZGlyZWN0cyB0aGUgcmVzb3VyY2Ugb3duZXIgdG8gdGhlIGNvbnN0cnVj dGVkIFVSSSB1c2luZyBhbiBIVFRQIHJlZGlyZWN0aW9uCiAgICAgICAgICAgIHJlc3BvbnNlLCBv ciBieSBvdGhlciBtZWFucyBhdmFpbGFibGUgdG8gaXQgdmlhIHRoZSB1c2VyLWFnZW50LgogICAg ICAgICAgCjwvcD4KPHA+CiAgICAgICAgICAgICAgRm9yIGV4YW1wbGUsIHRoZSBjbGllbnQgZGly ZWN0cyB0aGUgdXNlci1hZ2VudCB0byBtYWtlIHRoZSBmb2xsb3dpbmcgSFRUUCByZXF1ZXN0CiAg ICAgICAgICAgICAgdXNpbmcgVExTIChleHRyYSBsaW5lIGJyZWFrcyBhcmUgZm9yIGRpc3BsYXkg cHVycG9zZXMgb25seSk6CiAgICAgICAgICAgIAo8L3A+PGRpdiBzdHlsZT0nZGlzcGxheTogdGFi bGU7IHdpZHRoOiAwOyBtYXJnaW4tbGVmdDogM2VtOyBtYXJnaW4tcmlnaHQ6IGF1dG8nPjxwcmU+ CgogIEdFVCAvYXV0aG9yaXplP3Jlc3BvbnNlX3R5cGU9Y29kZSZhbXA7Y2xpZW50X2lkPXM2Qmhk UmtxdDMmYW1wO3N0YXRlPXh5egogICAgICAmYW1wO3JlZGlyZWN0X3VyaT1odHRwcyUzQSUyRiUy RmNsaWVudCUyRWV4YW1wbGUlMkVjb20lMkZjYiBIVFRQLzEuMQogIEhvc3Q6IHNlcnZlci5leGFt cGxlLmNvbQoKPC9wcmU+PC9kaXY+CjxwPgogICAgICAgICAgICBUaGUgYXV0aG9yaXphdGlvbiBz ZXJ2ZXIgdmFsaWRhdGVzIHRoZSByZXF1ZXN0IHRvIGVuc3VyZSBhbGwgcmVxdWlyZWQgcGFyYW1l dGVycyBhcmUKICAgICAgICAgICAgcHJlc2VudCBhbmQgdmFsaWQuIElmIHRoZSByZXF1ZXN0IGlz IHZhbGlkLCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYXV0aGVudGljYXRlcyB0aGUKICAgICAg ICAgICAgcmVzb3VyY2Ugb3duZXIgYW5kIG9idGFpbnMgYW4gYXV0aG9yaXphdGlvbiBkZWNpc2lv biAoYnkgYXNraW5nIHRoZSByZXNvdXJjZSBvd25lciBvcgogICAgICAgICAgICBieSBlc3RhYmxp c2hpbmcgYXBwcm92YWwgdmlhIG90aGVyIG1lYW5zKS4KICAgICAgICAgIAo8L3A+CjxwPgogICAg ICAgICAgICBXaGVuIGEgZGVjaXNpb24gaXMgZXN0YWJsaXNoZWQsIHRoZSBhdXRob3JpemF0aW9u IHNlcnZlciBkaXJlY3RzIHRoZSB1c2VyLWFnZW50IHRvIHRoZQogICAgICAgICAgICBwcm92aWRl ZCBjbGllbnQgcmVkaXJlY3Rpb24gVVJJIHVzaW5nIGFuIEhUVFAgcmVkaXJlY3Rpb24gcmVzcG9u c2UsIG9yIGJ5IG90aGVyIG1lYW5zCiAgICAgICAgICAgIGF2YWlsYWJsZSB0byBpdCB2aWEgdGhl IHVzZXItYWdlbnQuCiAgICAgICAgICAKPC9wPgo8YSBuYW1lPSJjb2RlLWF1dGh6LXJlc3AiPjwv YT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNl bGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9 IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3Rh YmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi40LjEuMiI+PC9hPjxoMz40LjEuMi4mbmJzcDsKQXV0 aG9yaXphdGlvbiBSZXNwb25zZTwvaDM+Cgo8cD4KICAgICAgICAgICAgSWYgdGhlIHJlc291cmNl IG93bmVyIGdyYW50cyB0aGUgYWNjZXNzIHJlcXVlc3QsIHRoZSBhdXRob3JpemF0aW9uIHNlcnZl ciBpc3N1ZXMgYW4KICAgICAgICAgICAgYXV0aG9yaXphdGlvbiBjb2RlIGFuZCBkZWxpdmVycyBp dCB0byB0aGUgY2xpZW50IGJ5IGFkZGluZyB0aGUgZm9sbG93aW5nIHBhcmFtZXRlcnMgdG8KICAg ICAgICAgICAgdGhlIHF1ZXJ5IGNvbXBvbmVudCBvZiB0aGUgcmVkaXJlY3Rpb24gVVJJIHVzaW5n IHRoZQogICAgICAgICAgICA8dHQ+YXBwbGljYXRpb24veC13d3ctZm9ybS11cmxlbmNvZGVkPC90 dD4gZm9ybWF0OgogICAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICAgIDwvcD4KPGJsb2NrcXVv dGUgY2xhc3M9InRleHQiPjxkbD4KPGR0PmNvZGU8L2R0Pgo8ZGQ+CiAgICAgICAgICAgICAgICAK ICAgICAgICAgICAgICAgIFJFUVVJUkVELiBUaGUgYXV0aG9yaXphdGlvbiBjb2RlIGdlbmVyYXRl ZCBieSB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIuIFRoZQogICAgICAgICAgICAgICAgYXV0aG9y aXphdGlvbiBjb2RlIE1VU1QgZXhwaXJlIHNob3J0bHkgYWZ0ZXIgaXQgaXMgaXNzdWVkIHRvIG1p dGlnYXRlIHRoZSByaXNrIG9mCiAgICAgICAgICAgICAgICBsZWFrcy4gQSBtYXhpbXVtIGF1dGhv cml6YXRpb24gY29kZSBsaWZldGltZSBvZiAxMCBtaW51dGVzIGlzIFJFQ09NTUVOREVELiBUaGUK ICAgICAgICAgICAgICAgIGNsaWVudCBNVVNUIE5PVCB1c2UgdGhlIGF1dGhvcml6YXRpb24gY29k ZSBtb3JlIHRoYW4gb25jZS4gSWYgYW4gYXV0aG9yaXphdGlvbiBjb2RlCiAgICAgICAgICAgICAg ICBpcyB1c2VkIG1vcmUgdGhhbiBvbmNlLCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVTVCBk ZW55IHRoZSByZXF1ZXN0IGFuZCBTSE9VTEQKICAgICAgICAgICAgICAgIHJldm9rZSAod2hlbiBw b3NzaWJsZSkgYWxsIHRva2VucyBwcmV2aW91c2x5IGlzc3VlZCBiYXNlZCBvbiB0aGF0IGF1dGhv cml6YXRpb24KICAgICAgICAgICAgICAgIGNvZGUuIFRoZSBhdXRob3JpemF0aW9uIGNvZGUgaXMg Ym91bmQgdG8gdGhlIGNsaWVudCBpZGVudGlmaWVyIGFuZCByZWRpcmVjdGlvbiBVUkkuCiAgICAg ICAgICAgICAgCjwvZGQ+CjxkdD5zdGF0ZTwvZHQ+CjxkZD4KICAgICAgICAgICAgICAgIAogICAg ICAgICAgICAgICAgUkVRVUlSRUQgaWYgdGhlIDx0dD5zdGF0ZTwvdHQ+IHBhcmFtZXRlciB3YXMg cHJlc2VudCBpbiB0aGUKICAgICAgICAgICAgICAgIGNsaWVudCBhdXRob3JpemF0aW9uIHJlcXVl c3QuIFRoZSBleGFjdCB2YWx1ZSByZWNlaXZlZCBmcm9tIHRoZSBjbGllbnQuCiAgICAgICAgICAg ICAgCjwvZGQ+CjwvZGw+PC9ibG9ja3F1b3RlPjxwPgogICAgICAgICAgCjwvcD4KPHA+CiAgICAg ICAgICAgICAgRm9yIGV4YW1wbGUsIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciByZWRpcmVjdHMg dGhlIHVzZXItYWdlbnQgYnkgc2VuZGluZyB0aGUKICAgICAgICAgICAgICBmb2xsb3dpbmcgSFRU UCByZXNwb25zZToKICAgICAgICAgICAgCjwvcD48ZGl2IHN0eWxlPSdkaXNwbGF5OiB0YWJsZTsg d2lkdGg6IDA7IG1hcmdpbi1sZWZ0OiAzZW07IG1hcmdpbi1yaWdodDogYXV0byc+PHByZT4KCiAg SFRUUC8xLjEgMzAyIEZvdW5kCiAgTG9jYXRpb246IGh0dHBzOi8vY2xpZW50LmV4YW1wbGUuY29t L2NiP2NvZGU9U3BseGxPQmVaUVFZYllTNld4U2JJQQogICAgICAgICAgICAmYW1wO3N0YXRlPXh5 egoKPC9wcmU+PC9kaXY+CjxwPgogICAgICAgICAgICBUaGUgY2xpZW50IE1VU1QgaWdub3JlIHVu cmVjb2duaXplZCByZXNwb25zZSBwYXJhbWV0ZXJzLiBUaGUgYXV0aG9yaXphdGlvbiBjb2RlCiAg ICAgICAgICAgIHN0cmluZyBzaXplIGlzIGxlZnQgdW5kZWZpbmVkIGJ5IHRoaXMgc3BlY2lmaWNh dGlvbi4gVGhlIGNsaWVudCBzaG91bGQgYXZvaWQgbWFraW5nCiAgICAgICAgICAgIGFzc3VtcHRp b25zIGFib3V0IGNvZGUgdmFsdWUgc2l6ZXMuIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBTSE9V TEQgZG9jdW1lbnQgdGhlIHNpemUKICAgICAgICAgICAgb2YgYW55IHZhbHVlIGl0IGlzc3Vlcy4K ICAgICAgICAgIAo8L3A+CjxhIG5hbWU9ImNvZGUtYXV0aHotZXJyb3IiPjwvYT48YnIgLz48aHIg Lz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIy IiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEg aHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1l PSJyZmMuc2VjdGlvbi40LjEuMi4xIj48L2E+PGgzPjQuMS4yLjEuJm5ic3A7CkVycm9yIFJlc3Bv bnNlPC9oMz4KCjxwPgogICAgICAgICAgICAgIElmIHRoZSByZXF1ZXN0IGZhaWxzIGR1ZSB0byBh IG1pc3NpbmcsIGludmFsaWQsIG9yIG1pc21hdGNoaW5nIHJlZGlyZWN0aW9uIFVSSSwgb3IgaWYK ICAgICAgICAgICAgICB0aGUgY2xpZW50IGlkZW50aWZpZXIgaXMgbWlzc2luZyBvciBpbnZhbGlk LCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgU0hPVUxEIGluZm9ybQogICAgICAgICAgICAgIHRo ZSByZXNvdXJjZSBvd25lciBvZiB0aGUgZXJyb3IsIGFuZCBNVVNUIE5PVCBhdXRvbWF0aWNhbGx5 IHJlZGlyZWN0IHRoZSB1c2VyLWFnZW50CiAgICAgICAgICAgICAgdG8gdGhlIGludmFsaWQgcmVk aXJlY3Rpb24gVVJJLgogICAgICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgICAgICBJZiB0aGUg cmVzb3VyY2Ugb3duZXIgZGVuaWVzIHRoZSBhY2Nlc3MgcmVxdWVzdCBvciBpZiB0aGUgcmVxdWVz dCBmYWlscyBmb3IgcmVhc29ucwogICAgICAgICAgICAgIG90aGVyIHRoYW4gYSBtaXNzaW5nIG9y IGludmFsaWQgcmVkaXJlY3Rpb24gVVJJLCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgaW5mb3Jt cyB0aGUKICAgICAgICAgICAgICBjbGllbnQgYnkgYWRkaW5nIHRoZSBmb2xsb3dpbmcgcGFyYW1l dGVycyB0byB0aGUgcXVlcnkgY29tcG9uZW50IG9mIHRoZSByZWRpcmVjdGlvbgogICAgICAgICAg ICAgIFVSSSB1c2luZyB0aGUgPHR0PmFwcGxpY2F0aW9uL3gtd3d3LWZvcm0tdXJsZW5jb2RlZDwv dHQ+IGZvcm1hdDoKICAgICAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICAgICAgPC9wPgo8Ymxv Y2txdW90ZSBjbGFzcz0idGV4dCI+PGRsPgo8ZHQ+ZXJyb3I8L2R0Pgo8ZGQ+CiAgICAgICAgICAg ICAgICAgIAogICAgICAgICAgICAgICAgICBSRVFVSVJFRC4gQSBzaW5nbGUgQVNDSUkgPGEgY2xh c3M9J2luZm8nIGhyZWY9JyNVU0FTQ0lJJz5bVVNBU0NJSV08c3Bhbj4gKDwvc3Bhbj48c3BhbiBj bGFzcz0naW5mbyc+QW1lcmljYW4gTmF0aW9uYWwgU3RhbmRhcmRzIEluc3RpdHV0ZSwgJmxkcXVv O0NvZGVkIENoYXJhY3RlciBTZXQgLS0gNy1iaXQgQW1lcmljYW4gU3RhbmRhcmQgQ29kZSBmb3Ig SW5mb3JtYXRpb24gSW50ZXJjaGFuZ2UsJnJkcXVvOyAxOTg2Ljwvc3Bhbj48c3Bhbj4pPC9zcGFu PjwvYT4gZXJyb3IgY29kZSBmcm9tIHRoZSBmb2xsb3dpbmc6CgogICAgICAgICAgICAgICAgICAK PGJsb2NrcXVvdGUgY2xhc3M9InRleHQiPjxkbD4KPGR0PmludmFsaWRfcmVxdWVzdDwvZHQ+Cjxk ZD4KICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgVGhlIHJlcXVl c3QgaXMgbWlzc2luZyBhIHJlcXVpcmVkIHBhcmFtZXRlciwgaW5jbHVkZXMgYW4gaW52YWxpZAog ICAgICAgICAgICAgICAgICAgICAgcGFyYW1ldGVyIHZhbHVlLCBpbmNsdWRlcyBhIHBhcmFtZXRl ciBtb3JlIHRoYW4gb25jZSwgb3IgaXMgb3RoZXJ3aXNlCiAgICAgICAgICAgICAgICAgICAgICBt YWxmb3JtZWQuCiAgICAgICAgICAgICAgICAgICAgCjwvZGQ+CjxkdD51bmF1dGhvcml6ZWRfY2xp ZW50PC9kdD4KPGRkPgogICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAg ICBUaGUgY2xpZW50IGlzIG5vdCBhdXRob3JpemVkIHRvIHJlcXVlc3QgYW4gYXV0aG9yaXphdGlv biBjb2RlIHVzaW5nIHRoaXMKICAgICAgICAgICAgICAgICAgICAgIG1ldGhvZC4KICAgICAgICAg ICAgICAgICAgICAKPC9kZD4KPGR0PmFjY2Vzc19kZW5pZWQ8L2R0Pgo8ZGQ+CiAgICAgICAgICAg ICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgIFRoZSByZXNvdXJjZSBvd25lciBvciBh dXRob3JpemF0aW9uIHNlcnZlciBkZW5pZWQgdGhlIHJlcXVlc3QuCiAgICAgICAgICAgICAgICAg ICAgCjwvZGQ+CjxkdD51bnN1cHBvcnRlZF9yZXNwb25zZV90eXBlPC9kdD4KPGRkPgogICAgICAg ICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICBUaGUgYXV0aG9yaXphdGlvbiBz ZXJ2ZXIgZG9lcyBub3Qgc3VwcG9ydCBvYnRhaW5pbmcgYW4gYXV0aG9yaXphdGlvbiBjb2RlCiAg ICAgICAgICAgICAgICAgICAgICB1c2luZyB0aGlzIG1ldGhvZC4KICAgICAgICAgICAgICAgICAg ICAKPC9kZD4KPGR0PmludmFsaWRfc2NvcGU8L2R0Pgo8ZGQ+CiAgICAgICAgICAgICAgICAgICAg ICAKICAgICAgICAgICAgICAgICAgICAgIFRoZSByZXF1ZXN0ZWQgc2NvcGUgaXMgaW52YWxpZCwg dW5rbm93biwgb3IgbWFsZm9ybWVkLgogICAgICAgICAgICAgICAgICAgIAo8L2RkPgo8ZHQ+c2Vy dmVyX2Vycm9yPC9kdD4KPGRkPgogICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAg ICAgICAgICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgZW5jb3VudGVyZWQgYW4gdW5leHBlY3Rl ZCBjb25kaXRpb24gd2hpY2ggcHJldmVudGVkCiAgICAgICAgICAgICAgICAgICAgICBpdCBmcm9t IGZ1bGZpbGxpbmcgdGhlIHJlcXVlc3QuCiAgICAgICAgICAgICAgICAgICAgCjwvZGQ+CjxkdD50 ZW1wb3JhcmlseV91bmF2YWlsYWJsZTwvZHQ+CjxkZD4KICAgICAgICAgICAgICAgICAgICAgIAog ICAgICAgICAgICAgICAgICAgICAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGlzIGN1cnJlbnRs eSB1bmFibGUgdG8gaGFuZGxlIHRoZSByZXF1ZXN0IGR1ZSB0byBhCiAgICAgICAgICAgICAgICAg ICAgICB0ZW1wb3Jhcnkgb3ZlcmxvYWRpbmcgb3IgbWFpbnRlbmFuY2Ugb2YgdGhlIHNlcnZlci4K ICAgICAgICAgICAgICAgICAgICAKPC9kZD4KPC9kbD48L2Jsb2NrcXVvdGU+CgoJCSAgVmFsdWVz IGZvciB0aGUgPHR0PmVycm9yPC90dD4gcGFyYW1ldGVyIE1VU1QgTk9UIGluY2x1ZGUKCQkgIGNo YXJhY3RlcnMgb3V0c2lkZSB0aGUgc2V0ICV4MjAtMjEgLyAleDIzLTVCIC8gJXg1RC03RS4KICAg ICAgICAgICAgICAgIAo8L2RkPgo8ZHQ+ZXJyb3JfZGVzY3JpcHRpb248L2R0Pgo8ZGQ+CiAgICAg ICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICBPUFRJT05BTC4gQSBodW1hbi1yZWFkYWJs ZSBBU0NJSSA8YSBjbGFzcz0naW5mbycgaHJlZj0nI1VTQVNDSUknPltVU0FTQ0lJXTxzcGFuPiAo PC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5BbWVyaWNhbiBOYXRpb25hbCBTdGFuZGFyZHMgSW5z dGl0dXRlLCAmbGRxdW87Q29kZWQgQ2hhcmFjdGVyIFNldCAtLSA3LWJpdCBBbWVyaWNhbiBTdGFu ZGFyZCBDb2RlIGZvciBJbmZvcm1hdGlvbiBJbnRlcmNoYW5nZSwmcmRxdW87IDE5ODYuPC9zcGFu PjxzcGFuPik8L3NwYW4+PC9hPiB0ZXh0IHByb3ZpZGluZyBhZGRpdGlvbmFsIGluZm9ybWF0aW9u LAogICAgICAgICAgICAgICAgICB1c2VkIHRvIGFzc2lzdCB0aGUgY2xpZW50IGRldmVsb3BlciBp biB1bmRlcnN0YW5kaW5nIHRoZSBlcnJvciB0aGF0IG9jY3VycmVkLgoJCSAgPGJyIC8+CgoJCSAg VmFsdWVzIGZvciB0aGUgPHR0PmVycm9yX2Rlc2NyaXB0aW9uPC90dD4gcGFyYW1ldGVyIE1VU1Qg Tk9UIGluY2x1ZGUKCQkgIGNoYXJhY3RlcnMgb3V0c2lkZSB0aGUgc2V0ICV4MjAtMjEgLyAleDIz LTVCIC8gJXg1RC03RS4KICAgICAgICAgICAgICAgIAo8L2RkPgo8ZHQ+ZXJyb3JfdXJpPC9kdD4K PGRkPgogICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgT1BUSU9OQUwuIEEgVVJJ IGlkZW50aWZ5aW5nIGEgaHVtYW4tcmVhZGFibGUgd2ViIHBhZ2Ugd2l0aCBpbmZvcm1hdGlvbiBh Ym91dCB0aGUKICAgICAgICAgICAgICAgICAgZXJyb3IsIHVzZWQgdG8gcHJvdmlkZSB0aGUgY2xp ZW50IGRldmVsb3BlciB3aXRoIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gYWJvdXQgdGhlCiAgICAg ICAgICAgICAgICAgIGVycm9yLgoJCSAgPGJyIC8+CgoJCSAgVmFsdWVzIGZvciB0aGUgPHR0PmVy cm9yX3VyaTwvdHQ+IHBhcmFtZXRlcgoJCSAgTVVTVCBjb25mb3JtIHRvIHRoZSBVUkktUmVmZXJl bmNlIHN5bnRheCwgYW5kIHRodXMgTVVTVCBOT1QgaW5jbHVkZQoJCSAgY2hhcmFjdGVycyBvdXRz aWRlIHRoZSBzZXQgJXgyMSAvICV4MjMtNUIgLyAleDVELTdFLgogICAgICAgICAgICAgICAgCjwv ZGQ+CjxkdD5zdGF0ZTwvZHQ+CjxkZD4KICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAg ICAgIFJFUVVJUkVEIGlmIGEgPHR0PnN0YXRlPC90dD4gcGFyYW1ldGVyIHdhcyBwcmVzZW50IGlu IHRoZQogICAgICAgICAgICAgICAgICBjbGllbnQgYXV0aG9yaXphdGlvbiByZXF1ZXN0LiBUaGUg ZXhhY3QgdmFsdWUgcmVjZWl2ZWQgZnJvbSB0aGUgY2xpZW50LgogICAgICAgICAgICAgICAgCjwv ZGQ+CjwvZGw+PC9ibG9ja3F1b3RlPjxwPgogICAgICAgICAgICAKPC9wPgo8cD4KICAgICAgICAg ICAgICAgIEZvciBleGFtcGxlLCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgcmVkaXJlY3RzIHRo ZSB1c2VyLWFnZW50IGJ5IHNlbmRpbmcgdGhlCiAgICAgICAgICAgICAgICBmb2xsb3dpbmcgSFRU UCByZXNwb25zZToKICAgICAgICAgICAgICAKPC9wPjxkaXYgc3R5bGU9J2Rpc3BsYXk6IHRhYmxl OyB3aWR0aDogMDsgbWFyZ2luLWxlZnQ6IDNlbTsgbWFyZ2luLXJpZ2h0OiBhdXRvJz48cHJlPgoK ICBIVFRQLzEuMSAzMDIgRm91bmQKICBMb2NhdGlvbjogaHR0cHM6Ly9jbGllbnQuZXhhbXBsZS5j b20vY2I/ZXJyb3I9YWNjZXNzX2RlbmllZCZhbXA7c3RhdGU9eHl6Cgo8L3ByZT48L2Rpdj4KPGEg bmFtZT0idG9rZW4tcmVxIj48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQi IGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJp Z2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNw OzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uNC4xLjMiPjwvYT48 aDM+NC4xLjMuJm5ic3A7CkFjY2VzcyBUb2tlbiBSZXF1ZXN0PC9oMz4KCjxwPgogICAgICAgICAg ICBUaGUgY2xpZW50IG1ha2VzIGEgcmVxdWVzdCB0byB0aGUgdG9rZW4gZW5kcG9pbnQgYnkgYWRk aW5nIHRoZSBmb2xsb3dpbmcgcGFyYW1ldGVycwogICAgICAgICAgICB1c2luZyB0aGUgPHR0PmFw cGxpY2F0aW9uL3gtd3d3LWZvcm0tdXJsZW5jb2RlZDwvdHQ+IGZvcm1hdCBpbiB0aGUKICAgICAg ICAgICAgSFRUUCByZXF1ZXN0IGVudGl0eS1ib2R5OgogICAgICAgICAgCjwvcD4KPHA+CiAgICAg ICAgICAgIDwvcD4KPGJsb2NrcXVvdGUgY2xhc3M9InRleHQiPjxkbD4KPGR0PmdyYW50X3R5cGU8 L2R0Pgo8ZGQ+CiAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgIFJFUVVJUkVELiBWYWx1 ZSBNVVNUIGJlIHNldCB0byA8dHQ+YXV0aG9yaXphdGlvbl9jb2RlPC90dD4uCiAgICAgICAgICAg ICAgCjwvZGQ+CjxkdD5jb2RlPC9kdD4KPGRkPgogICAgICAgICAgICAgICAgCiAgICAgICAgICAg ICAgICBSRVFVSVJFRC4gVGhlIGF1dGhvcml6YXRpb24gY29kZSByZWNlaXZlZCBmcm9tIHRoZSBh dXRob3JpemF0aW9uIHNlcnZlci4KICAgICAgICAgICAgICAKPC9kZD4KPGR0PnJlZGlyZWN0X3Vy aTwvZHQ+CjxkZD4KICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgUkVRVUlSRUQsIGlm IHRoZSA8dHQ+cmVkaXJlY3RfdXJpPC90dD4gcGFyYW1ldGVyIHdhcyBpbmNsdWRlZCBpbgogICAg ICAgICAgICAgICAgdGhlIGF1dGhvcml6YXRpb24gcmVxdWVzdCBhcyBkZXNjcmliZWQgaW4gPGEg Y2xhc3M9J2luZm8nIGhyZWY9JyNjb2RlLWF1dGh6LXJlcSc+U2VjdGlvbiZuYnNwOzQuMS4xPHNw YW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkF1dGhvcml6YXRpb24gUmVxdWVzdDwvc3Bh bj48c3Bhbj4pPC9zcGFuPjwvYT4sIGFuZAogICAgICAgICAgICAgICAgdGhlaXIgdmFsdWVzIE1V U1QgYmUgaWRlbnRpY2FsLgogICAgICAgICAgICAgIAo8L2RkPgo8L2RsPjwvYmxvY2txdW90ZT48 cD4KICAgICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgICBJZiB0aGUgY2xpZW50IHR5cGUgaXMg Y29uZmlkZW50aWFsIG9yIHRoZSBjbGllbnQgd2FzIGlzc3VlZCBjbGllbnQgY3JlZGVudGlhbHMg KG9yCiAgICAgICAgICAgIGFzc2lnbmVkIG90aGVyIGF1dGhlbnRpY2F0aW9uIHJlcXVpcmVtZW50 cyksIHRoZSBjbGllbnQgTVVTVCBhdXRoZW50aWNhdGUgd2l0aCB0aGUKICAgICAgICAgICAgYXV0 aG9yaXphdGlvbiBzZXJ2ZXIgYXMgZGVzY3JpYmVkIGluIDxhIGNsYXNzPSdpbmZvJyBocmVmPScj dG9rZW4tZW5kcG9pbnQtYXV0aCc+U2VjdGlvbiZuYnNwOzMuMi4xPHNwYW4+ICg8L3NwYW4+PHNw YW4gY2xhc3M9J2luZm8nPkNsaWVudCBBdXRoZW50aWNhdGlvbjwvc3Bhbj48c3Bhbj4pPC9zcGFu PjwvYT4uCiAgICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgICAgICBGb3IgZXhhbXBsZSwgdGhl IGNsaWVudCBtYWtlcyB0aGUgZm9sbG93aW5nIEhUVFAgcmVxdWVzdCB1c2luZyBUTFMgKGV4dHJh IGxpbmUgYnJlYWtzCiAgICAgICAgICAgICAgYXJlIGZvciBkaXNwbGF5IHB1cnBvc2VzIG9ubHkp OgogICAgICAgICAgICAKPC9wPjxkaXYgc3R5bGU9J2Rpc3BsYXk6IHRhYmxlOyB3aWR0aDogMDsg bWFyZ2luLWxlZnQ6IDNlbTsgbWFyZ2luLXJpZ2h0OiBhdXRvJz48cHJlPgoKICBQT1NUIC90b2tl biBIVFRQLzEuMQogIEhvc3Q6IHNlcnZlci5leGFtcGxlLmNvbQogIEF1dGhvcml6YXRpb246IEJh c2ljIGN6WkNhR1JTYTNGME16cG5XREZtUW1GME0ySlcKICBDb250ZW50LVR5cGU6IGFwcGxpY2F0 aW9uL3gtd3d3LWZvcm0tdXJsZW5jb2RlZDtjaGFyc2V0PVVURi04CgogIGdyYW50X3R5cGU9YXV0 aG9yaXphdGlvbl9jb2RlJmFtcDtjb2RlPVNwbHhsT0JlWlFRWWJZUzZXeFNiSUEKICAmYW1wO3Jl ZGlyZWN0X3VyaT1odHRwcyUzQSUyRiUyRmNsaWVudCUyRWV4YW1wbGUlMkVjb20lMkZjYgoKPC9w cmU+PC9kaXY+CjxwPgogICAgICAgICAgICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVTVDoK ICAgICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgICA8L3A+Cjx1bCBjbGFzcz0idGV4dCI+Cjxs aT4KICAgICAgICAgICAgICAgIHJlcXVpcmUgY2xpZW50IGF1dGhlbnRpY2F0aW9uIGZvciBjb25m aWRlbnRpYWwgY2xpZW50cyBvciBmb3IgYW55IGNsaWVudCB0aGF0IHdhcwogICAgICAgICAgICAg ICAgaXNzdWVkIGNsaWVudCBjcmVkZW50aWFscyAob3Igd2l0aCBvdGhlciBhdXRoZW50aWNhdGlv biByZXF1aXJlbWVudHMpLAogICAgICAgICAgICAgIAo8L2xpPgo8bGk+CiAgICAgICAgICAgICAg ICBhdXRoZW50aWNhdGUgdGhlIGNsaWVudCBpZiBjbGllbnQgYXV0aGVudGljYXRpb24gaXMgaW5j bHVkZWQgYW5kIGVuc3VyZSB0aGUKICAgICAgICAgICAgICAgIGF1dGhvcml6YXRpb24gY29kZSB3 YXMgaXNzdWVkIHRvIHRoZSBhdXRoZW50aWNhdGVkIGNsaWVudCwKICAgICAgICAgICAgICAKPC9s aT4KPGxpPgogICAgICAgICAgICAgICAgdmVyaWZ5IHRoYXQgdGhlIGF1dGhvcml6YXRpb24gY29k ZSBpcyB2YWxpZCwgYW5kCiAgICAgICAgICAgICAgCjwvbGk+CjxsaT4KICAgICAgICAgICAgICAg IGVuc3VyZSB0aGF0IHRoZSA8dHQ+cmVkaXJlY3RfdXJpPC90dD4gcGFyYW1ldGVyIGlzIHByZXNl bnQgaWYKICAgICAgICAgICAgICAgIHRoZSA8dHQ+cmVkaXJlY3RfdXJpPC90dD4gcGFyYW1ldGVy IHdhcyBpbmNsdWRlZCBpbiB0aGUgaW5pdGlhbAogICAgICAgICAgICAgICAgYXV0aG9yaXphdGlv biByZXF1ZXN0IGFzIGRlc2NyaWJlZCBpbiA8YSBjbGFzcz0naW5mbycgaHJlZj0nI2NvZGUtYXV0 aHotcmVxJz5TZWN0aW9uJm5ic3A7NC4xLjE8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5m byc+QXV0aG9yaXphdGlvbiBSZXF1ZXN0PC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPiwgYW5kIGlm CiAgICAgICAgICAgICAgICBpbmNsdWRlZCBlbnN1cmUgdGhlaXIgdmFsdWVzIGFyZSBpZGVudGlj YWwuCiAgICAgICAgICAgICAgCjwvbGk+CjwvdWw+PHA+CiAgICAgICAgICAKPC9wPgo8YSBuYW1l PSJhbmNob3IyNiI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxs cGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+ PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+ PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLjQuMS40Ij48L2E+PGgzPjQu MS40LiZuYnNwOwpBY2Nlc3MgVG9rZW4gUmVzcG9uc2U8L2gzPgoKPHA+CiAgICAgICAgICAgIElm IHRoZSBhY2Nlc3MgdG9rZW4gcmVxdWVzdCBpcyB2YWxpZCBhbmQgYXV0aG9yaXplZCwgdGhlIGF1 dGhvcml6YXRpb24gc2VydmVyIGlzc3VlcyBhbgogICAgICAgICAgICBhY2Nlc3MgdG9rZW4gYW5k IG9wdGlvbmFsIHJlZnJlc2ggdG9rZW4gYXMgZGVzY3JpYmVkIGluIDxhIGNsYXNzPSdpbmZvJyBo cmVmPScjdG9rZW4tcmVzcG9uc2UnPlNlY3Rpb24mbmJzcDs1LjE8c3Bhbj4gKDwvc3Bhbj48c3Bh biBjbGFzcz0naW5mbyc+U3VjY2Vzc2Z1bCBSZXNwb25zZTwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwv YT4uCiAgICAgICAgICAgIElmIHRoZSByZXF1ZXN0IGNsaWVudCBhdXRoZW50aWNhdGlvbiBmYWls ZWQgb3IgaXMgaW52YWxpZCwgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHJldHVybnMKICAgICAg ICAgICAgYW4gZXJyb3IgcmVzcG9uc2UgYXMgZGVzY3JpYmVkIGluIDxhIGNsYXNzPSdpbmZvJyBo cmVmPScjdG9rZW4tZXJyb3JzJz5TZWN0aW9uJm5ic3A7NS4yPHNwYW4+ICg8L3NwYW4+PHNwYW4g Y2xhc3M9J2luZm8nPkVycm9yIFJlc3BvbnNlPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPi4KICAg ICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgICAgIEFuIGV4YW1wbGUgc3VjY2Vzc2Z1bCByZXNw b25zZToKICAgICAgICAgICAgCjwvcD48ZGl2IHN0eWxlPSdkaXNwbGF5OiB0YWJsZTsgd2lkdGg6 IDA7IG1hcmdpbi1sZWZ0OiAzZW07IG1hcmdpbi1yaWdodDogYXV0byc+PHByZT4KCiAgSFRUUC8x LjEgMjAwIE9LCiAgQ29udGVudC1UeXBlOiBhcHBsaWNhdGlvbi9qc29uO2NoYXJzZXQ9VVRGLTgK ICBDYWNoZS1Db250cm9sOiBuby1zdG9yZQogIFByYWdtYTogbm8tY2FjaGUKCiAgewogICAgImFj Y2Vzc190b2tlbiI6IjJZb3RuRlpGRWpyMXpDc2ljTVdwQUEiLAogICAgInRva2VuX3R5cGUiOiJl eGFtcGxlIiwKICAgICJleHBpcmVzX2luIjozNjAwLAogICAgInJlZnJlc2hfdG9rZW4iOiJ0R3p2 M0pPa0YwWEc1UXgyVGxLV0lBIiwKICAgICJleGFtcGxlX3BhcmFtZXRlciI6ImV4YW1wbGVfdmFs dWUiCiAgfQoKPC9wcmU+PC9kaXY+CjxhIG5hbWU9ImdyYW50LWltcGxpY2l0Ij48L2E+PGJyIC8+ PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2lu Zz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWci PjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEg bmFtZT0icmZjLnNlY3Rpb24uNC4yIj48L2E+PGgzPjQuMi4mbmJzcDsKSW1wbGljaXQgR3JhbnQ8 L2gzPgoKPHA+CiAgICAgICAgICBUaGUgaW1wbGljaXQgZ3JhbnQgdHlwZSBpcyB1c2VkIHRvIG9i dGFpbiBhY2Nlc3MgdG9rZW5zIChpdCBkb2VzIG5vdCBzdXBwb3J0IHRoZSBpc3N1YW5jZQogICAg ICAgICAgb2YgcmVmcmVzaCB0b2tlbnMpIGFuZCBpcyBvcHRpbWl6ZWQgZm9yIHB1YmxpYyBjbGll bnRzIGtub3duIHRvIG9wZXJhdGUgYSBwYXJ0aWN1bGFyCiAgICAgICAgICByZWRpcmVjdGlvbiBV UkkuIFRoZXNlIGNsaWVudHMgYXJlIHR5cGljYWxseSBpbXBsZW1lbnRlZCBpbiBhIGJyb3dzZXIg dXNpbmcgYSBzY3JpcHRpbmcKICAgICAgICAgIGxhbmd1YWdlIHN1Y2ggYXMgSmF2YVNjcmlwdC4K ICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgIEFzIGEgcmVkaXJlY3Rpb24tYmFzZWQgZmxvdywg dGhlIGNsaWVudCBtdXN0IGJlIGNhcGFibGUgb2YgaW50ZXJhY3Rpbmcgd2l0aCB0aGUKICAgICAg ICAgIHJlc291cmNlIG93bmVyJ3MgdXNlci1hZ2VudCAodHlwaWNhbGx5IGEgd2ViIGJyb3dzZXIp IGFuZCBjYXBhYmxlIG9mIHJlY2VpdmluZyBpbmNvbWluZwogICAgICAgICAgcmVxdWVzdHMgKHZp YSByZWRpcmVjdGlvbikgZnJvbSB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIuCiAgICAgICAgCjwv cD4KPHA+CiAgICAgICAgICBVbmxpa2UgdGhlIGF1dGhvcml6YXRpb24gY29kZSBncmFudCB0eXBl IGluIHdoaWNoIHRoZSBjbGllbnQgbWFrZXMgc2VwYXJhdGUgcmVxdWVzdHMgZm9yCiAgICAgICAg ICBhdXRob3JpemF0aW9uIGFuZCBhY2Nlc3MgdG9rZW4sIHRoZSBjbGllbnQgcmVjZWl2ZXMgdGhl IGFjY2VzcyB0b2tlbiBhcyB0aGUgcmVzdWx0IG9mIHRoZQogICAgICAgICAgYXV0aG9yaXphdGlv biByZXF1ZXN0LgogICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgVGhlIGltcGxpY2l0IGdyYW50 IHR5cGUgZG9lcyBub3QgaW5jbHVkZSBjbGllbnQgYXV0aGVudGljYXRpb24sIGFuZCByZWxpZXMg b24gdGhlCiAgICAgICAgICBwcmVzZW5jZSBvZiB0aGUgcmVzb3VyY2Ugb3duZXIgYW5kIHRoZSBy ZWdpc3RyYXRpb24gb2YgdGhlIHJlZGlyZWN0aW9uIFVSSS4gQmVjYXVzZSB0aGUKICAgICAgICAg IGFjY2VzcyB0b2tlbiBpcyBlbmNvZGVkIGludG8gdGhlIHJlZGlyZWN0aW9uIFVSSSwgaXQgbWF5 IGJlIGV4cG9zZWQgdG8gdGhlIHJlc291cmNlIG93bmVyCiAgICAgICAgICBhbmQgb3RoZXIgYXBw bGljYXRpb25zIHJlc2lkaW5nIG9uIHRoZSBzYW1lIGRldmljZS4KICAgICAgICAKPC9wPjxiciAv PjxociBjbGFzcz0iaW5zZXJ0IiAvPgo8YSBuYW1lPSJGaWd1cmUtNCI+PC9hPgo8ZGl2IHN0eWxl PSdkaXNwbGF5OiB0YWJsZTsgd2lkdGg6IDA7IG1hcmdpbi1sZWZ0OiAzZW07IG1hcmdpbi1yaWdo dDogYXV0byc+PHByZT4KCiAgKy0tLS0tLS0tLS0rCiAgfCBSZXNvdXJjZSB8CiAgfCAgT3duZXIg ICB8CiAgfCAgICAgICAgICB8CiAgKy0tLS0tLS0tLS0rCiAgICAgICBeCiAgICAgICB8CiAgICAg IChCKQogICstLS0tfC0tLS0tKyAgICAgICAgICBDbGllbnQgSWRlbnRpZmllciAgICAgKy0tLS0t LS0tLS0tLS0tLSsKICB8ICAgICAgICAgLSstLS0tKEEpLS0gJmFtcDsgUmVkaXJlY3Rpb24gVVJJ IC0tLSZndDt8ICAgICAgICAgICAgICAgfAogIHwgIFVzZXItICAgfCAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgfCBBdXRob3JpemF0aW9uIHwKICB8ICBBZ2VudCAgLXwtLS0tKEIpLS0g VXNlciBhdXRoZW50aWNhdGVzIC0tJmd0O3wgICAgIFNlcnZlciAgICB8CiAgfCAgICAgICAgICB8 ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgfAogIHwgICAg ICAgICAgfCZsdDstLS0oQyktLS0gUmVkaXJlY3Rpb24gVVJJIC0tLS0mbHQ7fCAgICAgICAgICAg ICAgIHwKICB8ICAgICAgICAgIHwgICAgICAgICAgd2l0aCBBY2Nlc3MgVG9rZW4gICAgICstLS0t LS0tLS0tLS0tLS0rCiAgfCAgICAgICAgICB8ICAgICAgICAgICAgaW4gRnJhZ21lbnQKICB8ICAg ICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0r CiAgfCAgICAgICAgICB8LS0tLShEKS0tLSBSZWRpcmVjdGlvbiBVUkkgLS0tLSZndDt8ICAgV2Vi LUhvc3RlZCAgfAogIHwgICAgICAgICAgfCAgICAgICAgICB3aXRob3V0IEZyYWdtZW50ICAgICAg fCAgICAgQ2xpZW50ICAgIHwKICB8ICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHwgICAgUmVzb3VyY2UgICB8CiAgfCAgICAgKEYpICB8Jmx0Oy0tLShFKS0tLS0tLS0g U2NyaXB0IC0tLS0tLS0tLSZsdDt8ICAgICAgICAgICAgICAgfAogIHwgICAgICAgICAgfCAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLSsKICArLXwtLS0tLS0t LSsKICAgIHwgICAgfAogICAoQSkgIChHKSBBY2Nlc3MgVG9rZW4KICAgIHwgICAgfAogICAgXiAg ICB2CiAgKy0tLS0tLS0tLSsKICB8ICAgICAgICAgfAogIHwgIENsaWVudCB8CiAgfCAgICAgICAg IHwKICArLS0tLS0tLS0tKwoKPC9wcmU+PC9kaXY+CjxwPgogICAgICAgICAgICBOb3RlOiBUaGUg bGluZXMgaWxsdXN0cmF0aW5nIHN0ZXBzIEEgYW5kIEIgYXJlIGJyb2tlbiBpbnRvIHR3byBwYXJ0 cyBhcyB0aGV5IHBhc3MKICAgICAgICAgICAgdGhyb3VnaCB0aGUgdXNlci1hZ2VudC4KICAgICAg ICAgIAo8L3A+PHRhYmxlIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIy IiBhbGlnbj0iY2VudGVyIj48dHI+PHRkIGFsaWduPSJjZW50ZXIiPjxmb250IGZhY2U9Im1vbmFj bywgTVMgU2FucyBTZXJpZiIgc2l6ZT0iMSI+PGI+Jm5ic3A7RmlndXJlJm5ic3A7NDogSW1wbGlj aXQgR3JhbnQgRmxvdyZuYnNwOzwvYj48L2ZvbnQ+PGJyIC8+PC90ZD48L3RyPjwvdGFibGU+PGhy IGNsYXNzPSJpbnNlcnQiIC8+Cgo8cD4KICAgICAgICAgIFRoZSBmbG93IGlsbHVzdHJhdGVkIGlu IDxhIGNsYXNzPSdpbmZvJyBocmVmPScjRmlndXJlLTQnPkZpZ3VyZSZuYnNwOzQ8c3Bhbj4gKDwv c3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+SW1wbGljaXQgR3JhbnQgRmxvdzwvc3Bhbj48c3Bhbj4p PC9zcGFuPjwvYT4gaW5jbHVkZXMgdGhlIGZvbGxvd2luZyBzdGVwczoKICAgICAgICAKPC9wPgo8 cD4KICAgICAgICAgIDwvcD4KPGJsb2NrcXVvdGUgY2xhc3M9InRleHQiPjxkbD4KPGR0PihBKTwv ZHQ+CjxkZD4KICAgICAgICAgICAgICBUaGUgY2xpZW50IGluaXRpYXRlcyB0aGUgZmxvdyBieSBk aXJlY3RpbmcgdGhlIHJlc291cmNlIG93bmVyJ3MgdXNlci1hZ2VudCB0byB0aGUKICAgICAgICAg ICAgICBhdXRob3JpemF0aW9uIGVuZHBvaW50LiBUaGUgY2xpZW50IGluY2x1ZGVzIGl0cyBjbGll bnQgaWRlbnRpZmllciwgcmVxdWVzdGVkCiAgICAgICAgICAgICAgc2NvcGUsIGxvY2FsIHN0YXRl LCBhbmQgYSByZWRpcmVjdGlvbiBVUkkgdG8gd2hpY2ggdGhlIGF1dGhvcml6YXRpb24gc2VydmVy IHdpbGwgc2VuZAogICAgICAgICAgICAgIHRoZSB1c2VyLWFnZW50IGJhY2sgb25jZSBhY2Nlc3Mg aXMgZ3JhbnRlZCAob3IgZGVuaWVkKS4KICAgICAgICAgICAgCjwvZGQ+CjxkdD4oQik8L2R0Pgo8 ZGQ+CiAgICAgICAgICAgICAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGF1dGhlbnRpY2F0ZXMg dGhlIHJlc291cmNlIG93bmVyICh2aWEgdGhlIHVzZXItYWdlbnQpIGFuZAogICAgICAgICAgICAg IGVzdGFibGlzaGVzIHdoZXRoZXIgdGhlIHJlc291cmNlIG93bmVyIGdyYW50cyBvciBkZW5pZXMg dGhlIGNsaWVudCdzIGFjY2VzcyByZXF1ZXN0LgogICAgICAgICAgICAKPC9kZD4KPGR0PihDKTwv ZHQ+CjxkZD4KICAgICAgICAgICAgICBBc3N1bWluZyB0aGUgcmVzb3VyY2Ugb3duZXIgZ3JhbnRz IGFjY2VzcywgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHJlZGlyZWN0cyB0aGUKICAgICAgICAg ICAgICB1c2VyLWFnZW50IGJhY2sgdG8gdGhlIGNsaWVudCB1c2luZyB0aGUgcmVkaXJlY3Rpb24g VVJJIHByb3ZpZGVkIGVhcmxpZXIuIFRoZQogICAgICAgICAgICAgIHJlZGlyZWN0aW9uIFVSSSBp bmNsdWRlcyB0aGUgYWNjZXNzIHRva2VuIGluIHRoZSBVUkkgZnJhZ21lbnQuCiAgICAgICAgICAg IAo8L2RkPgo8ZHQ+KEQpPC9kdD4KPGRkPgogICAgICAgICAgICAgIFRoZSB1c2VyLWFnZW50IGZv bGxvd3MgdGhlIHJlZGlyZWN0aW9uIGluc3RydWN0aW9ucyBieSBtYWtpbmcgYSByZXF1ZXN0IHRv IHRoZQogICAgICAgICAgICAgIHdlYi1ob3N0ZWQgY2xpZW50IHJlc291cmNlICh3aGljaCBkb2Vz IG5vdCBpbmNsdWRlIHRoZSBmcmFnbWVudCBwZXIKICAgICAgICAgICAgICA8YSBjbGFzcz0naW5m bycgaHJlZj0nI1JGQzI2MTYnPltSRkMyNjE2XTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdp bmZvJz5GaWVsZGluZywgUi4sIEdldHR5cywgSi4sIE1vZ3VsLCBKLiwgRnJ5c3R5aywgSC4sIE1h c2ludGVyLCBMLiwgTGVhY2gsIFAuLCBhbmQgVC4gQmVybmVycy1MZWUsICZsZHF1bztIeXBlcnRl eHQgVHJhbnNmZXIgUHJvdG9jb2wgLS0gSFRUUC8xLjEsJnJkcXVvOyBKdW5lJm5ic3A7MTk5OS48 L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+KS4gVGhlIHVzZXItYWdlbnQgcmV0YWlucyB0aGUgZnJh Z21lbnQgaW5mb3JtYXRpb24gbG9jYWxseS4KICAgICAgICAgICAgCjwvZGQ+CjxkdD4oRSk8L2R0 Pgo8ZGQ+CiAgICAgICAgICAgICAgVGhlIHdlYi1ob3N0ZWQgY2xpZW50IHJlc291cmNlIHJldHVy bnMgYSB3ZWIgcGFnZSAodHlwaWNhbGx5IGFuIEhUTUwgZG9jdW1lbnQgd2l0aCBhbgogICAgICAg ICAgICAgIGVtYmVkZGVkIHNjcmlwdCkgY2FwYWJsZSBvZiBhY2Nlc3NpbmcgdGhlIGZ1bGwgcmVk aXJlY3Rpb24gVVJJIGluY2x1ZGluZyB0aGUgZnJhZ21lbnQKICAgICAgICAgICAgICByZXRhaW5l ZCBieSB0aGUgdXNlci1hZ2VudCwgYW5kIGV4dHJhY3RpbmcgdGhlIGFjY2VzcyB0b2tlbiAoYW5k IG90aGVyIHBhcmFtZXRlcnMpCiAgICAgICAgICAgICAgY29udGFpbmVkIGluIHRoZSBmcmFnbWVu dC4KICAgICAgICAgICAgCjwvZGQ+CjxkdD4oRik8L2R0Pgo8ZGQ+CiAgICAgICAgICAgICAgVGhl IHVzZXItYWdlbnQgZXhlY3V0ZXMgdGhlIHNjcmlwdCBwcm92aWRlZCBieSB0aGUgd2ViLWhvc3Rl ZCBjbGllbnQgcmVzb3VyY2UKICAgICAgICAgICAgICBsb2NhbGx5LCB3aGljaCBleHRyYWN0cyB0 aGUgYWNjZXNzIHRva2VuIGFuZCBwYXNzZXMgaXQgdG8gdGhlIGNsaWVudC4KICAgICAgICAgICAg CjwvZGQ+CjwvZGw+PC9ibG9ja3F1b3RlPjxwPgogICAgICAgIAo8L3A+CjxhIG5hbWU9ImltcGxp Y2l0LWF1dGh6LXJlcSI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBj ZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdo dCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8 L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLjQuMi4xIj48L2E+PGgz PjQuMi4xLiZuYnNwOwpBdXRob3JpemF0aW9uIFJlcXVlc3Q8L2gzPgoKPHA+CiAgICAgICAgICAg IFRoZSBjbGllbnQgY29uc3RydWN0cyB0aGUgcmVxdWVzdCBVUkkgYnkgYWRkaW5nIHRoZSBmb2xs b3dpbmcgcGFyYW1ldGVycyB0byB0aGUKICAgICAgICAgICAgcXVlcnkgY29tcG9uZW50IG9mIHRo ZSBhdXRob3JpemF0aW9uIGVuZHBvaW50IFVSSSB1c2luZyB0aGUKICAgICAgICAgICAgPHR0PmFw cGxpY2F0aW9uL3gtd3d3LWZvcm0tdXJsZW5jb2RlZDwvdHQ+IGZvcm1hdDoKICAgICAgICAgIAo8 L3A+CjxwPgogICAgICAgICAgICA8L3A+CjxibG9ja3F1b3RlIGNsYXNzPSJ0ZXh0Ij48ZGw+Cjxk dD5yZXNwb25zZV90eXBlPC9kdD4KPGRkPgogICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAg ICBSRVFVSVJFRC4gVmFsdWUgTVVTVCBiZSBzZXQgdG8gPHR0PnRva2VuPC90dD4uCiAgICAgICAg ICAgICAgCjwvZGQ+CjxkdD5jbGllbnRfaWQ8L2R0Pgo8ZGQ+CiAgICAgICAgICAgICAgICAKICAg ICAgICAgICAgICAgIFJFUVVJUkVELiBUaGUgY2xpZW50IGlkZW50aWZpZXIgYXMgZGVzY3JpYmVk IGluCiAgICAgICAgICAgICAgICA8YSBjbGFzcz0naW5mbycgaHJlZj0nI2NsaWVudC1pZGVudGlm aWVyJz5TZWN0aW9uJm5ic3A7Mi4yPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkNs aWVudCBJZGVudGlmaWVyPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPi4KICAgICAgICAgICAgICAK PC9kZD4KPGR0PnJlZGlyZWN0X3VyaTwvZHQ+CjxkZD4KICAgICAgICAgICAgICAgIAogICAgICAg ICAgICAgICAgT1BUSU9OQUwuIEFzIGRlc2NyaWJlZCBpbiA8YSBjbGFzcz0naW5mbycgaHJlZj0n I3JlZGlyZWN0LXVyaSc+U2VjdGlvbiZuYnNwOzMuMS4yPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xh c3M9J2luZm8nPlJlZGlyZWN0aW9uIEVuZHBvaW50PC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPi4K ICAgICAgICAgICAgICAKPC9kZD4KPGR0PnNjb3BlPC9kdD4KPGRkPgogICAgICAgICAgICAgICAg CiAgICAgICAgICAgICAgICBPUFRJT05BTC4gVGhlIHNjb3BlIG9mIHRoZSBhY2Nlc3MgcmVxdWVz dCBhcyBkZXNjcmliZWQgYnkgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNzY29wZSc+U2VjdGlvbiZu YnNwOzMuMzxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5BY2Nlc3MgVG9rZW4gU2Nv cGU8L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+LgogICAgICAgICAgICAgIAo8L2RkPgo8ZHQ+c3Rh dGU8L2R0Pgo8ZGQ+CiAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgIFJFQ09NTUVOREVE LiBBbiBvcGFxdWUgdmFsdWUgdXNlZCBieSB0aGUgY2xpZW50IHRvIG1haW50YWluIHN0YXRlIGJl dHdlZW4gdGhlIHJlcXVlc3QKICAgICAgICAgICAgICAgIGFuZCBjYWxsYmFjay4gVGhlIGF1dGhv cml6YXRpb24gc2VydmVyIGluY2x1ZGVzIHRoaXMgdmFsdWUgd2hlbiByZWRpcmVjdGluZyB0aGUK ICAgICAgICAgICAgICAgIHVzZXItYWdlbnQgYmFjayB0byB0aGUgY2xpZW50LiBUaGUgcGFyYW1l dGVyIFNIT1VMRCBiZSB1c2VkIGZvciBwcmV2ZW50aW5nCiAgICAgICAgICAgICAgICBjcm9zcy1z aXRlIHJlcXVlc3QgZm9yZ2VyeSBhcyBkZXNjcmliZWQgaW4gPGEgY2xhc3M9J2luZm8nIGhyZWY9 JyNDU1JGJz5TZWN0aW9uJm5ic3A7MTAuMTI8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5m byc+Q3Jvc3MtU2l0ZSBSZXF1ZXN0IEZvcmdlcnk8L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+Lgog ICAgICAgICAgICAgIAo8L2RkPgo8L2RsPjwvYmxvY2txdW90ZT48cD4KICAgICAgICAgIAo8L3A+ CjxwPgogICAgICAgICAgICBUaGUgY2xpZW50IGRpcmVjdHMgdGhlIHJlc291cmNlIG93bmVyIHRv IHRoZSBjb25zdHJ1Y3RlZCBVUkkgdXNpbmcgYW4gSFRUUCByZWRpcmVjdGlvbgogICAgICAgICAg ICByZXNwb25zZSwgb3IgYnkgb3RoZXIgbWVhbnMgYXZhaWxhYmxlIHRvIGl0IHZpYSB0aGUgdXNl ci1hZ2VudC4KICAgICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgICAgIEZvciBleGFtcGxlLCB0 aGUgY2xpZW50IGRpcmVjdHMgdGhlIHVzZXItYWdlbnQgdG8gbWFrZSB0aGUgZm9sbG93aW5nIEhU VFAgcmVxdWVzdAogICAgICAgICAgICAgIHVzaW5nIFRMUyAoZXh0cmEgbGluZSBicmVha3MgYXJl IGZvciBkaXNwbGF5IHB1cnBvc2VzIG9ubHkpOgogICAgICAgICAgICAKPC9wPjxkaXYgc3R5bGU9 J2Rpc3BsYXk6IHRhYmxlOyB3aWR0aDogMDsgbWFyZ2luLWxlZnQ6IDNlbTsgbWFyZ2luLXJpZ2h0 OiBhdXRvJz48cHJlPgoKICBHRVQgL2F1dGhvcml6ZT9yZXNwb25zZV90eXBlPXRva2VuJmFtcDtj bGllbnRfaWQ9czZCaGRSa3F0MyZhbXA7c3RhdGU9eHl6CiAgICAgICZhbXA7cmVkaXJlY3RfdXJp PWh0dHBzJTNBJTJGJTJGY2xpZW50JTJFZXhhbXBsZSUyRWNvbSUyRmNiIEhUVFAvMS4xCiAgSG9z dDogc2VydmVyLmV4YW1wbGUuY29tCgo8L3ByZT48L2Rpdj4KPHA+CiAgICAgICAgICAgIFRoZSBh dXRob3JpemF0aW9uIHNlcnZlciB2YWxpZGF0ZXMgdGhlIHJlcXVlc3QgdG8gZW5zdXJlIGFsbCBy ZXF1aXJlZCBwYXJhbWV0ZXJzIGFyZQogICAgICAgICAgICBwcmVzZW50IGFuZCB2YWxpZC4gVGhl IGF1dGhvcml6YXRpb24gc2VydmVyIE1VU1QgdmVyaWZ5IHRoYXQgdGhlIHJlZGlyZWN0aW9uIFVS SSB0byB3aGljaAogICAgICAgICAgICBpdCB3aWxsIHJlZGlyZWN0IHRoZSBhY2Nlc3MgdG9rZW4g bWF0Y2hlcyBhIHJlZGlyZWN0aW9uIFVSSSByZWdpc3RlcmVkIGJ5IHRoZSBjbGllbnQgYXMKICAg ICAgICAgICAgZGVzY3JpYmVkIGluIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjcmVkaXJlY3QtdXJp Jz5TZWN0aW9uJm5ic3A7My4xLjI8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+UmVk aXJlY3Rpb24gRW5kcG9pbnQ8L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+LgogICAgICAgICAgCjwv cD4KPHA+CiAgICAgICAgICAgIElmIHRoZSByZXF1ZXN0IGlzIHZhbGlkLCB0aGUgYXV0aG9yaXph dGlvbiBzZXJ2ZXIgYXV0aGVudGljYXRlcyB0aGUgcmVzb3VyY2Ugb3duZXIgYW5kCiAgICAgICAg ICAgIG9idGFpbnMgYW4gYXV0aG9yaXphdGlvbiBkZWNpc2lvbiAoYnkgYXNraW5nIHRoZSByZXNv dXJjZSBvd25lciBvciBieSBlc3RhYmxpc2hpbmcKICAgICAgICAgICAgYXBwcm92YWwgdmlhIG90 aGVyIG1lYW5zKS4KICAgICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgICBXaGVuIGEgZGVjaXNp b24gaXMgZXN0YWJsaXNoZWQsIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBkaXJlY3RzIHRoZSB1 c2VyLWFnZW50IHRvIHRoZQogICAgICAgICAgICBwcm92aWRlZCBjbGllbnQgcmVkaXJlY3Rpb24g VVJJIHVzaW5nIGFuIEhUVFAgcmVkaXJlY3Rpb24gcmVzcG9uc2UsIG9yIGJ5IG90aGVyIG1lYW5z CiAgICAgICAgICAgIGF2YWlsYWJsZSB0byBpdCB2aWEgdGhlIHVzZXItYWdlbnQuCiAgICAgICAg ICAKPC9wPgo8YSBuYW1lPSJpbXBsaWNpdC1hdXRoei1yZXNwIj48L2E+PGJyIC8+PGhyIC8+Cjx0 YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xh c3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9 IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZj LnNlY3Rpb24uNC4yLjIiPjwvYT48aDM+NC4yLjIuJm5ic3A7CkFjY2VzcyBUb2tlbiBSZXNwb25z ZTwvaDM+Cgo8cD4KICAgICAgICAgICAgSWYgdGhlIHJlc291cmNlIG93bmVyIGdyYW50cyB0aGUg YWNjZXNzIHJlcXVlc3QsIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBpc3N1ZXMgYW4KICAgICAg ICAgICAgYWNjZXNzIHRva2VuIGFuZCBkZWxpdmVycyBpdCB0byB0aGUgY2xpZW50IGJ5IGFkZGlu ZyB0aGUgZm9sbG93aW5nIHBhcmFtZXRlcnMgdG8KICAgICAgICAgICAgdGhlIGZyYWdtZW50IGNv bXBvbmVudCBvZiB0aGUgcmVkaXJlY3Rpb24gVVJJIHVzaW5nIHRoZQogICAgICAgICAgICA8dHQ+ YXBwbGljYXRpb24veC13d3ctZm9ybS11cmxlbmNvZGVkPC90dD4gZm9ybWF0OgogICAgICAgICAg CjwvcD4KPHA+CiAgICAgICAgICAgIDwvcD4KPGJsb2NrcXVvdGUgY2xhc3M9InRleHQiPjxkbD4K PGR0PmFjY2Vzc190b2tlbjwvZHQ+CjxkZD4KICAgICAgICAgICAgICAgIAogICAgICAgICAgICAg ICAgUkVRVUlSRUQuIFRoZSBhY2Nlc3MgdG9rZW4gaXNzdWVkIGJ5IHRoZSBhdXRob3JpemF0aW9u IHNlcnZlci4KICAgICAgICAgICAgICAKPC9kZD4KPGR0PnRva2VuX3R5cGU8L2R0Pgo8ZGQ+CiAg ICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgIFJFUVVJUkVELiBUaGUgdHlwZSBvZiB0aGUg dG9rZW4gaXNzdWVkIGFzIGRlc2NyaWJlZCBpbgogICAgICAgICAgICAgICAgPGEgY2xhc3M9J2lu Zm8nIGhyZWY9JyN0b2tlbi10eXBlcyc+U2VjdGlvbiZuYnNwOzcuMTxzcGFuPiAoPC9zcGFuPjxz cGFuIGNsYXNzPSdpbmZvJz5BY2Nlc3MgVG9rZW4gVHlwZXM8L3NwYW4+PHNwYW4+KTwvc3Bhbj48 L2E+LiBWYWx1ZSBpcyBjYXNlIGluc2Vuc2l0aXZlLgogICAgICAgICAgICAgIAo8L2RkPgo8ZHQ+ ZXhwaXJlc19pbjwvZHQ+CjxkZD4KICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgUkVD T01NRU5ERUQuIFRoZSBsaWZldGltZSBpbiBzZWNvbmRzIG9mIHRoZSBhY2Nlc3MgdG9rZW4uIEZv ciBleGFtcGxlLCB0aGUgdmFsdWUKICAgICAgICAgICAgICAgIDx0dD4zNjAwPC90dD4gZGVub3Rl cyB0aGF0IHRoZSBhY2Nlc3MgdG9rZW4gd2lsbCBleHBpcmUgaW4gb25lCiAgICAgICAgICAgICAg ICBob3VyIGZyb20gdGhlIHRpbWUgdGhlIHJlc3BvbnNlIHdhcyBnZW5lcmF0ZWQuIElmIG9taXR0 ZWQsIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlcgogICAgICAgICAgICAgICAgU0hPVUxEIHByb3Zp ZGUgdGhlIGV4cGlyYXRpb24gdGltZSB2aWEgb3RoZXIgbWVhbnMgb3IgZG9jdW1lbnQgdGhlIGRl ZmF1bHQgdmFsdWUuCiAgICAgICAgICAgICAgCjwvZGQ+CjxkdD5zY29wZTwvZHQ+CjxkZD4KICAg ICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgT1BUSU9OQUwsIGlmIGlkZW50aWNhbCB0byB0 aGUgc2NvcGUgcmVxdWVzdGVkIGJ5IHRoZSBjbGllbnQsIG90aGVyd2lzZSBSRVFVSVJFRC4gVGhl CiAgICAgICAgICAgICAgICBzY29wZSBvZiB0aGUgYWNjZXNzIHRva2VuIGFzIGRlc2NyaWJlZCBi eSA8YSBjbGFzcz0naW5mbycgaHJlZj0nI3Njb3BlJz5TZWN0aW9uJm5ic3A7My4zPHNwYW4+ICg8 L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkFjY2VzcyBUb2tlbiBTY29wZTwvc3Bhbj48c3Bhbj4p PC9zcGFuPjwvYT4uCiAgICAgICAgICAgICAgCjwvZGQ+CjxkdD5zdGF0ZTwvZHQ+CjxkZD4KICAg ICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgUkVRVUlSRUQgaWYgdGhlIDx0dD5zdGF0ZTwv dHQ+IHBhcmFtZXRlciB3YXMgcHJlc2VudCBpbiB0aGUKICAgICAgICAgICAgICAgIGNsaWVudCBh dXRob3JpemF0aW9uIHJlcXVlc3QuIFRoZSBleGFjdCB2YWx1ZSByZWNlaXZlZCBmcm9tIHRoZSBj bGllbnQuCiAgICAgICAgICAgICAgCjwvZGQ+CjwvZGw+PC9ibG9ja3F1b3RlPjxwPgogICAgICAg ICAgCjwvcD4KPHA+CiAgICAgICAgICAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBNVVNUIE5P VCBpc3N1ZSBhIHJlZnJlc2ggdG9rZW4uCiAgICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgICAg ICBGb3IgZXhhbXBsZSwgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHJlZGlyZWN0cyB0aGUgdXNl ci1hZ2VudCBieSBzZW5kaW5nIHRoZQogICAgICAgICAgICAgIGZvbGxvd2luZyBIVFRQIHJlc3Bv bnNlIChVUkkgZXh0cmEgbGluZSBicmVha3MgYXJlIGZvciBkaXNwbGF5IHB1cnBvc2VzIG9ubHkp OgogICAgICAgICAgICAKPC9wPjxkaXYgc3R5bGU9J2Rpc3BsYXk6IHRhYmxlOyB3aWR0aDogMDsg bWFyZ2luLWxlZnQ6IDNlbTsgbWFyZ2luLXJpZ2h0OiBhdXRvJz48cHJlPgoKICBIVFRQLzEuMSAz MDIgRm91bmQKICBMb2NhdGlvbjogaHR0cDovL2V4YW1wbGUuY29tL2NiI2FjY2Vzc190b2tlbj0y WW90bkZaRkVqcjF6Q3NpY01XcEFBCiAgICAgICAgICAgICZhbXA7c3RhdGU9eHl6JmFtcDt0b2tl bl90eXBlPWV4YW1wbGUmYW1wO2V4cGlyZXNfaW49MzYwMAoKPC9wcmU+PC9kaXY+CjxwPgogICAg ICAgICAgICAgIERldmVsb3BlcnMgc2hvdWxkIG5vdGUgdGhhdCBzb21lIHVzZXItYWdlbnRzIGRv IG5vdCBzdXBwb3J0IHRoZSBpbmNsdXNpb24gb2YgYQogICAgICAgICAgICAgIGZyYWdtZW50IGNv bXBvbmVudCBpbiB0aGUgSFRUUCA8dHQ+TG9jYXRpb248L3R0PiByZXNwb25zZSBoZWFkZXIKICAg ICAgICAgICAgICBmaWVsZC4gU3VjaCBjbGllbnRzIHdpbGwgcmVxdWlyZSB1c2luZyBvdGhlciBt ZXRob2RzIGZvciByZWRpcmVjdGluZyB0aGUgY2xpZW50IHRoYW4KICAgICAgICAgICAgICBhIDN4 eCByZWRpcmVjdGlvbiByZXNwb25zZS4gRm9yIGV4YW1wbGUsIHJldHVybmluZyBhbiBIVE1MIHBh Z2Ugd2hpY2ggaW5jbHVkZXMgYQogICAgICAgICAgICAgICdjb250aW51ZScgYnV0dG9uIHdpdGgg YW4gYWN0aW9uIGxpbmtlZCB0byB0aGUgcmVkaXJlY3Rpb24gVVJJLgogICAgICAgICAgICAKPC9w Pgo8cD4KICAgICAgICAgICAgVGhlIGNsaWVudCBNVVNUIGlnbm9yZSB1bnJlY29nbml6ZWQgcmVz cG9uc2UgcGFyYW1ldGVycy4gVGhlIGFjY2VzcyB0b2tlbiBzdHJpbmcgc2l6ZQogICAgICAgICAg ICBpcyBsZWZ0IHVuZGVmaW5lZCBieSB0aGlzIHNwZWNpZmljYXRpb24uIFRoZSBjbGllbnQgc2hv dWxkIGF2b2lkIG1ha2luZyBhc3N1bXB0aW9ucwogICAgICAgICAgICBhYm91dCB2YWx1ZSBzaXpl cy4gVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIFNIT1VMRCBkb2N1bWVudCB0aGUgc2l6ZSBvZiBh bnkgdmFsdWUgaXQKICAgICAgICAgICAgaXNzdWVzLgogICAgICAgICAgCjwvcD4KPGEgbmFtZT0i aW1wbGljaXQtYXV0aHotZXJyb3IiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9Imxh eW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGln bj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9D Jm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi40LjIuMi4x Ij48L2E+PGgzPjQuMi4yLjEuJm5ic3A7CkVycm9yIFJlc3BvbnNlPC9oMz4KCjxwPgogICAgICAg ICAgICAgIElmIHRoZSByZXF1ZXN0IGZhaWxzIGR1ZSB0byBhIG1pc3NpbmcsIGludmFsaWQsIG9y IG1pc21hdGNoaW5nIHJlZGlyZWN0aW9uIFVSSSwgb3IgaWYKICAgICAgICAgICAgICB0aGUgY2xp ZW50IGlkZW50aWZpZXIgaXMgbWlzc2luZyBvciBpbnZhbGlkLCB0aGUgYXV0aG9yaXphdGlvbiBz ZXJ2ZXIgU0hPVUxEIGluZm9ybQogICAgICAgICAgICAgIHRoZSByZXNvdXJjZSBvd25lciBvZiB0 aGUgZXJyb3IsIGFuZCBNVVNUIE5PVCBhdXRvbWF0aWNhbGx5IHJlZGlyZWN0IHRoZSB1c2VyLWFn ZW50CiAgICAgICAgICAgICAgdG8gdGhlIGludmFsaWQgcmVkaXJlY3Rpb24gVVJJLgogICAgICAg ICAgICAKPC9wPgo8cD4KICAgICAgICAgICAgICBJZiB0aGUgcmVzb3VyY2Ugb3duZXIgZGVuaWVz IHRoZSBhY2Nlc3MgcmVxdWVzdCBvciBpZiB0aGUgcmVxdWVzdCBmYWlscyBmb3IgcmVhc29ucwog ICAgICAgICAgICAgIG90aGVyIHRoYW4gYSBtaXNzaW5nIG9yIGludmFsaWQgcmVkaXJlY3Rpb24g VVJJLCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgaW5mb3JtcyB0aGUKICAgICAgICAgICAgICBj bGllbnQgYnkgYWRkaW5nIHRoZSBmb2xsb3dpbmcgcGFyYW1ldGVycyB0byB0aGUgZnJhZ21lbnQg Y29tcG9uZW50IG9mIHRoZQogICAgICAgICAgICAgIHJlZGlyZWN0aW9uIFVSSSB1c2luZyB0aGUK ICAgICAgICAgICAgICA8dHQ+YXBwbGljYXRpb24veC13d3ctZm9ybS11cmxlbmNvZGVkPC90dD4g Zm9ybWF0OgogICAgICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgICAgICA8L3A+CjxibG9ja3F1 b3RlIGNsYXNzPSJ0ZXh0Ij48ZGw+CjxkdD5lcnJvcjwvZHQ+CjxkZD4KICAgICAgICAgICAgICAg ICAgCiAgICAgICAgICAgICAgICAgIFJFUVVJUkVELiBBIHNpbmdsZSBBU0NJSSA8YSBjbGFzcz0n aW5mbycgaHJlZj0nI1VTQVNDSUknPltVU0FTQ0lJXTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNz PSdpbmZvJz5BbWVyaWNhbiBOYXRpb25hbCBTdGFuZGFyZHMgSW5zdGl0dXRlLCAmbGRxdW87Q29k ZWQgQ2hhcmFjdGVyIFNldCAtLSA3LWJpdCBBbWVyaWNhbiBTdGFuZGFyZCBDb2RlIGZvciBJbmZv cm1hdGlvbiBJbnRlcmNoYW5nZSwmcmRxdW87IDE5ODYuPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9h PiBlcnJvciBjb2RlIGZyb20gdGhlIGZvbGxvd2luZzoKCiAgICAgICAgICAgICAgICAgIAo8Ymxv Y2txdW90ZSBjbGFzcz0idGV4dCI+PGRsPgo8ZHQ+aW52YWxpZF9yZXF1ZXN0PC9kdD4KPGRkPgog ICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICBUaGUgcmVxdWVzdCBp cyBtaXNzaW5nIGEgcmVxdWlyZWQgcGFyYW1ldGVyLCBpbmNsdWRlcyBhbiBpbnZhbGlkCiAgICAg ICAgICAgICAgICAgICAgICBwYXJhbWV0ZXIgdmFsdWUsIGluY2x1ZGVzIGEgcGFyYW1ldGVyIG1v cmUgdGhhbiBvbmNlLCBvciBpcyBvdGhlcndpc2UgbWFsZm9ybWVkLgogICAgICAgICAgICAgICAg ICAgIAo8L2RkPgo8ZHQ+dW5hdXRob3JpemVkX2NsaWVudDwvZHQ+CjxkZD4KICAgICAgICAgICAg ICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgVGhlIGNsaWVudCBpcyBub3QgYXV0aG9y aXplZCB0byByZXF1ZXN0IGFuIGFjY2VzcyB0b2tlbiB1c2luZyB0aGlzIG1ldGhvZC4KICAgICAg ICAgICAgICAgICAgICAKPC9kZD4KPGR0PmFjY2Vzc19kZW5pZWQ8L2R0Pgo8ZGQ+CiAgICAgICAg ICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgIFRoZSByZXNvdXJjZSBvd25lciBv ciBhdXRob3JpemF0aW9uIHNlcnZlciBkZW5pZWQgdGhlIHJlcXVlc3QuCiAgICAgICAgICAgICAg ICAgICAgCjwvZGQ+CjxkdD51bnN1cHBvcnRlZF9yZXNwb25zZV90eXBlPC9kdD4KPGRkPgogICAg ICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICBUaGUgYXV0aG9yaXphdGlv biBzZXJ2ZXIgZG9lcyBub3Qgc3VwcG9ydCBvYnRhaW5pbmcgYW4gYWNjZXNzIHRva2VuIHVzaW5n CiAgICAgICAgICAgICAgICAgICAgICB0aGlzIG1ldGhvZC4KICAgICAgICAgICAgICAgICAgICAK PC9kZD4KPGR0PmludmFsaWRfc2NvcGU8L2R0Pgo8ZGQ+CiAgICAgICAgICAgICAgICAgICAgICAK ICAgICAgICAgICAgICAgICAgICAgIFRoZSByZXF1ZXN0ZWQgc2NvcGUgaXMgaW52YWxpZCwgdW5r bm93biwgb3IgbWFsZm9ybWVkLgogICAgICAgICAgICAgICAgICAgIAo8L2RkPgo8ZHQ+c2VydmVy X2Vycm9yPC9kdD4KPGRkPgogICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAg ICAgICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgZW5jb3VudGVyZWQgYW4gdW5leHBlY3RlZCBj b25kaXRpb24gd2hpY2ggcHJldmVudGVkCiAgICAgICAgICAgICAgICAgICAgICBpdCBmcm9tIGZ1 bGZpbGxpbmcgdGhlIHJlcXVlc3QuCiAgICAgICAgICAgICAgICAgICAgCjwvZGQ+CjxkdD50ZW1w b3JhcmlseV91bmF2YWlsYWJsZTwvZHQ+CjxkZD4KICAgICAgICAgICAgICAgICAgICAgIAogICAg ICAgICAgICAgICAgICAgICAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGlzIGN1cnJlbnRseSB1 bmFibGUgdG8gaGFuZGxlIHRoZSByZXF1ZXN0IGR1ZSB0byBhCiAgICAgICAgICAgICAgICAgICAg ICB0ZW1wb3Jhcnkgb3ZlcmxvYWRpbmcgb3IgbWFpbnRlbmFuY2Ugb2YgdGhlIHNlcnZlci4KICAg ICAgICAgICAgICAgICAgICAKPC9kZD4KPC9kbD48L2Jsb2NrcXVvdGU+CgoJCSAgVmFsdWVzIGZv ciB0aGUgPHR0PmVycm9yPC90dD4gcGFyYW1ldGVyIE1VU1QgTk9UIGluY2x1ZGUKCQkgIGNoYXJh Y3RlcnMgb3V0c2lkZSB0aGUgc2V0ICV4MjAtMjEgLyAleDIzLTVCIC8gJXg1RC03RS4KICAgICAg ICAgICAgICAgIAo8L2RkPgo8ZHQ+ZXJyb3JfZGVzY3JpcHRpb248L2R0Pgo8ZGQ+CiAgICAgICAg ICAgICAgICAgIAogICAgICAgICAgICAgICAgICBPUFRJT05BTC4gQSBodW1hbi1yZWFkYWJsZSBB U0NJSSA8YSBjbGFzcz0naW5mbycgaHJlZj0nI1VTQVNDSUknPltVU0FTQ0lJXTxzcGFuPiAoPC9z cGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5BbWVyaWNhbiBOYXRpb25hbCBTdGFuZGFyZHMgSW5zdGl0 dXRlLCAmbGRxdW87Q29kZWQgQ2hhcmFjdGVyIFNldCAtLSA3LWJpdCBBbWVyaWNhbiBTdGFuZGFy ZCBDb2RlIGZvciBJbmZvcm1hdGlvbiBJbnRlcmNoYW5nZSwmcmRxdW87IDE5ODYuPC9zcGFuPjxz cGFuPik8L3NwYW4+PC9hPiB0ZXh0IHByb3ZpZGluZyBhZGRpdGlvbmFsIGluZm9ybWF0aW9uLAog ICAgICAgICAgICAgICAgICB1c2VkIHRvIGFzc2lzdCB0aGUgY2xpZW50IGRldmVsb3BlciBpbiB1 bmRlcnN0YW5kaW5nIHRoZSBlcnJvciB0aGF0IG9jY3VycmVkLgoJCSAgPGJyIC8+CgoJCSAgVmFs dWVzIGZvciB0aGUgPHR0PmVycm9yX2Rlc2NyaXB0aW9uPC90dD4gcGFyYW1ldGVyIE1VU1QgTk9U IGluY2x1ZGUKCQkgIGNoYXJhY3RlcnMgb3V0c2lkZSB0aGUgc2V0ICV4MjAtMjEgLyAleDIzLTVC IC8gJXg1RC03RS4KICAgICAgICAgICAgICAgIAo8L2RkPgo8ZHQ+ZXJyb3JfdXJpPC9kdD4KPGRk PgogICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgT1BUSU9OQUwuIEEgVVJJIGlk ZW50aWZ5aW5nIGEgaHVtYW4tcmVhZGFibGUgd2ViIHBhZ2Ugd2l0aCBpbmZvcm1hdGlvbiBhYm91 dCB0aGUKICAgICAgICAgICAgICAgICAgZXJyb3IsIHVzZWQgdG8gcHJvdmlkZSB0aGUgY2xpZW50 IGRldmVsb3BlciB3aXRoIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gYWJvdXQgdGhlCiAgICAgICAg ICAgICAgICAgIGVycm9yLgoJCSAgPGJyIC8+CgoJCSAgVmFsdWVzIGZvciB0aGUgPHR0PmVycm9y X3VyaTwvdHQ+IHBhcmFtZXRlcgoJCSAgTVVTVCBjb25mb3JtIHRvIHRoZSBVUkktUmVmZXJlbmNl IHN5bnRheCwgYW5kIHRodXMgTVVTVCBOT1QgaW5jbHVkZQoJCSAgY2hhcmFjdGVycyBvdXRzaWRl IHRoZSBzZXQgJXgyMSAvICV4MjMtNUIgLyAleDVELTdFLgogICAgICAgICAgICAgICAgCjwvZGQ+ CjxkdD5zdGF0ZTwvZHQ+CjxkZD4KICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAg IFJFUVVJUkVEIGlmIGEgPHR0PnN0YXRlPC90dD4gcGFyYW1ldGVyIHdhcyBwcmVzZW50IGluIHRo ZQogICAgICAgICAgICAgICAgICBjbGllbnQgYXV0aG9yaXphdGlvbiByZXF1ZXN0LiBUaGUgZXhh Y3QgdmFsdWUgcmVjZWl2ZWQgZnJvbSB0aGUgY2xpZW50LgogICAgICAgICAgICAgICAgCjwvZGQ+ CjwvZGw+PC9ibG9ja3F1b3RlPjxwPgogICAgICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgICAg ICAgIEZvciBleGFtcGxlLCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgcmVkaXJlY3RzIHRoZSB1 c2VyLWFnZW50IGJ5IHNlbmRpbmcgdGhlCiAgICAgICAgICAgICAgICBmb2xsb3dpbmcgSFRUUCBy ZXNwb25zZToKICAgICAgICAgICAgICAKPC9wPjxkaXYgc3R5bGU9J2Rpc3BsYXk6IHRhYmxlOyB3 aWR0aDogMDsgbWFyZ2luLWxlZnQ6IDNlbTsgbWFyZ2luLXJpZ2h0OiBhdXRvJz48cHJlPgoKICBI VFRQLzEuMSAzMDIgRm91bmQKICBMb2NhdGlvbjogaHR0cHM6Ly9jbGllbnQuZXhhbXBsZS5jb20v Y2IjZXJyb3I9YWNjZXNzX2RlbmllZCZhbXA7c3RhdGU9eHl6Cgo8L3ByZT48L2Rpdj4KPGEgbmFt ZT0iZ3JhbnQtcGFzc3dvcmQiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91 dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0i cmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5i c3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi40LjMiPjwvYT48 aDM+NC4zLiZuYnNwOwpSZXNvdXJjZSBPd25lciBQYXNzd29yZCBDcmVkZW50aWFscyBHcmFudDwv aDM+Cgo8cD4KICAgICAgICAgIFRoZSByZXNvdXJjZSBvd25lciBwYXNzd29yZCBjcmVkZW50aWFs cyBncmFudCB0eXBlIGlzIHN1aXRhYmxlIGluIGNhc2VzIHdoZXJlIHRoZQogICAgICAgICAgcmVz b3VyY2Ugb3duZXIgaGFzIGEgdHJ1c3QgcmVsYXRpb25zaGlwIHdpdGggdGhlIGNsaWVudCwgc3Vj aCBhcyB0aGUgZGV2aWNlIG9wZXJhdGluZwogICAgICAgICAgc3lzdGVtIG9yIGEgaGlnaGx5IHBy aXZpbGVnZWQgYXBwbGljYXRpb24uIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBzaG91bGQgdGFr ZSBzcGVjaWFsCiAgICAgICAgICBjYXJlIHdoZW4gZW5hYmxpbmcgdGhpcyBncmFudCB0eXBlLCBh bmQgb25seSBhbGxvdyBpdCB3aGVuIG90aGVyIGZsb3dzIGFyZSBub3QgdmlhYmxlLgogICAgICAg IAo8L3A+CjxwPgogICAgICAgICAgVGhlIGdyYW50IHR5cGUgaXMgc3VpdGFibGUgZm9yIGNsaWVu dHMgY2FwYWJsZSBvZiBvYnRhaW5pbmcgdGhlIHJlc291cmNlIG93bmVyJ3MKICAgICAgICAgIGNy ZWRlbnRpYWxzICh1c2VybmFtZSBhbmQgcGFzc3dvcmQsIHR5cGljYWxseSB1c2luZyBhbiBpbnRl cmFjdGl2ZSBmb3JtKS4gSXQgaXMgYWxzbyB1c2VkCiAgICAgICAgICB0byBtaWdyYXRlIGV4aXN0 aW5nIGNsaWVudHMgdXNpbmcgZGlyZWN0IGF1dGhlbnRpY2F0aW9uIHNjaGVtZXMgc3VjaCBhcyBI VFRQIEJhc2ljIG9yCiAgICAgICAgICBEaWdlc3QgYXV0aGVudGljYXRpb24gdG8gT0F1dGggYnkg Y29udmVydGluZyB0aGUgc3RvcmVkIGNyZWRlbnRpYWxzIHRvIGFuIGFjY2VzcyB0b2tlbi4KICAg ICAgICAKPC9wPjxiciAvPjxociBjbGFzcz0iaW5zZXJ0IiAvPgo8YSBuYW1lPSJGaWd1cmUtNSI+ PC9hPgo8ZGl2IHN0eWxlPSdkaXNwbGF5OiB0YWJsZTsgd2lkdGg6IDA7IG1hcmdpbi1sZWZ0OiAz ZW07IG1hcmdpbi1yaWdodDogYXV0byc+PHByZT4KCiAgKy0tLS0tLS0tLS0rCiAgfCBSZXNvdXJj ZSB8CiAgfCAgT3duZXIgICB8CiAgfCAgICAgICAgICB8CiAgKy0tLS0tLS0tLS0rCiAgICAgICB2 CiAgICAgICB8ICAgIFJlc291cmNlIE93bmVyCiAgICAgIChBKSBQYXNzd29yZCBDcmVkZW50aWFs cwogICAgICAgfAogICAgICAgdgogICstLS0tLS0tLS0rICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0rCiAgfCAgICAgICAgIHwmZ3Q7LS0oQiktLS0tIFJl c291cmNlIE93bmVyIC0tLS0tLS0mZ3Q7fCAgICAgICAgICAgICAgIHwKICB8ICAgICAgICAgfCAg ICAgICAgIFBhc3N3b3JkIENyZWRlbnRpYWxzICAgICB8IEF1dGhvcml6YXRpb24gfAogIHwgQ2xp ZW50ICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgIFNlcnZlciAgICB8 CiAgfCAgICAgICAgIHwmbHQ7LS0oQyktLS0tIEFjY2VzcyBUb2tlbiAtLS0tLS0tLS0mbHQ7fCAg ICAgICAgICAgICAgIHwKICB8ICAgICAgICAgfCAgICAody8gT3B0aW9uYWwgUmVmcmVzaCBUb2tl bikgICB8ICAgICAgICAgICAgICAgfAogICstLS0tLS0tLS0rICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0rCgo8L3ByZT48L2Rpdj48dGFibGUgYm9yZGVy PSIwIiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGFsaWduPSJjZW50ZXIiPjx0cj48 dGQgYWxpZ249ImNlbnRlciI+PGZvbnQgZmFjZT0ibW9uYWNvLCBNUyBTYW5zIFNlcmlmIiBzaXpl PSIxIj48Yj4mbmJzcDtGaWd1cmUmbmJzcDs1OiBSZXNvdXJjZSBPd25lciBQYXNzd29yZCBDcmVk ZW50aWFscyBGbG93Jm5ic3A7PC9iPjwvZm9udD48YnIgLz48L3RkPjwvdHI+PC90YWJsZT48aHIg Y2xhc3M9Imluc2VydCIgLz4KCjxwPgogICAgICAgICAgVGhlIGZsb3cgaWxsdXN0cmF0ZWQgaW4g PGEgY2xhc3M9J2luZm8nIGhyZWY9JyNGaWd1cmUtNSc+RmlndXJlJm5ic3A7NTxzcGFuPiAoPC9z cGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5SZXNvdXJjZSBPd25lciBQYXNzd29yZCBDcmVkZW50aWFs cyBGbG93PC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPiBpbmNsdWRlcyB0aGUgZm9sbG93aW5nIHN0 ZXBzOgogICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgPC9wPgo8YmxvY2txdW90ZSBjbGFzcz0i dGV4dCI+PGRsPgo8ZHQ+KEEpPC9kdD4KPGRkPgogICAgICAgICAgICAgIFRoZSByZXNvdXJjZSBv d25lciBwcm92aWRlcyB0aGUgY2xpZW50IHdpdGggaXRzIHVzZXJuYW1lIGFuZCBwYXNzd29yZC4K ICAgICAgICAgICAgCjwvZGQ+CjxkdD4oQik8L2R0Pgo8ZGQ+CiAgICAgICAgICAgICAgVGhlIGNs aWVudCByZXF1ZXN0cyBhbiBhY2Nlc3MgdG9rZW4gZnJvbSB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2 ZXIncyB0b2tlbiBlbmRwb2ludCBieQogICAgICAgICAgICAgIGluY2x1ZGluZyB0aGUgY3JlZGVu dGlhbHMgcmVjZWl2ZWQgZnJvbSB0aGUgcmVzb3VyY2Ugb3duZXIuIFdoZW4gbWFraW5nIHRoZSBy ZXF1ZXN0LAogICAgICAgICAgICAgIHRoZSBjbGllbnQgYXV0aGVudGljYXRlcyB3aXRoIHRoZSBh dXRob3JpemF0aW9uIHNlcnZlci4KICAgICAgICAgICAgCjwvZGQ+CjxkdD4oQyk8L2R0Pgo8ZGQ+ CiAgICAgICAgICAgICAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGF1dGhlbnRpY2F0ZXMgdGhl IGNsaWVudCBhbmQgdmFsaWRhdGVzIHRoZSByZXNvdXJjZSBvd25lcgogICAgICAgICAgICAgIGNy ZWRlbnRpYWxzLCBhbmQgaWYgdmFsaWQgaXNzdWVzIGFuIGFjY2VzcyB0b2tlbi4KICAgICAgICAg ICAgCjwvZGQ+CjwvZGw+PC9ibG9ja3F1b3RlPjxwPgogICAgICAgIAo8L3A+CjxhIG5hbWU9ImFu Y2hvcjI3Ij48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRk aW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+ PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3Rk PjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uNC4zLjEiPjwvYT48aDM+NC4zLjEu Jm5ic3A7CkF1dGhvcml6YXRpb24gUmVxdWVzdCBhbmQgUmVzcG9uc2U8L2gzPgoKPHA+CiAgICAg ICAgICAgIFRoZSBtZXRob2QgdGhyb3VnaCB3aGljaCB0aGUgY2xpZW50IG9idGFpbnMgdGhlIHJl c291cmNlIG93bmVyIGNyZWRlbnRpYWxzIGlzIGJleW9uZAogICAgICAgICAgICB0aGUgc2NvcGUg b2YgdGhpcyBzcGVjaWZpY2F0aW9uLiBUaGUgY2xpZW50IE1VU1QgZGlzY2FyZCB0aGUgY3JlZGVu dGlhbHMgb25jZSBhbiBhY2Nlc3MKICAgICAgICAgICAgdG9rZW4gaGFzIGJlZW4gb2J0YWluZWQu CiAgICAgICAgICAKPC9wPgo8YSBuYW1lPSJwYXNzd29yZC10b2stcmVxIj48L2E+PGJyIC8+PGhy IC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0i MiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxh IGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFt ZT0icmZjLnNlY3Rpb24uNC4zLjIiPjwvYT48aDM+NC4zLjIuJm5ic3A7CkFjY2VzcyBUb2tlbiBS ZXF1ZXN0PC9oMz4KCjxwPgogICAgICAgICAgICBUaGUgY2xpZW50IG1ha2VzIGEgcmVxdWVzdCB0 byB0aGUgdG9rZW4gZW5kcG9pbnQgYnkgYWRkaW5nIHRoZSBmb2xsb3dpbmcgcGFyYW1ldGVycwog ICAgICAgICAgICB1c2luZyB0aGUgPHR0PmFwcGxpY2F0aW9uL3gtd3d3LWZvcm0tdXJsZW5jb2Rl ZDwvdHQ+IGZvcm1hdCBpbiB0aGUKICAgICAgICAgICAgSFRUUCByZXF1ZXN0IGVudGl0eS1ib2R5 OgogICAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICAgIDwvcD4KPGJsb2NrcXVvdGUgY2xhc3M9 InRleHQiPjxkbD4KPGR0PmdyYW50X3R5cGU8L2R0Pgo8ZGQ+CiAgICAgICAgICAgICAgICAKICAg ICAgICAgICAgICAgIFJFUVVJUkVELiBWYWx1ZSBNVVNUIGJlIHNldCB0byA8dHQ+cGFzc3dvcmQ8 L3R0Pi4KICAgICAgICAgICAgICAKPC9kZD4KPGR0PnVzZXJuYW1lPC9kdD4KPGRkPgogICAgICAg ICAgICAgICAgCiAgICAgICAgICAgICAgICBSRVFVSVJFRC4gVGhlIHJlc291cmNlIG93bmVyIHVz ZXJuYW1lLCBlbmNvZGVkIGFzIFVURi04LgogICAgICAgICAgICAgIAo8L2RkPgo8ZHQ+cGFzc3dv cmQ8L2R0Pgo8ZGQ+CiAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgIFJFUVVJUkVELiBU aGUgcmVzb3VyY2Ugb3duZXIgcGFzc3dvcmQsIGVuY29kZWQgYXMgVVRGLTguCiAgICAgICAgICAg ICAgCjwvZGQ+CjxkdD5zY29wZTwvZHQ+CjxkZD4KICAgICAgICAgICAgICAgIAogICAgICAgICAg ICAgICAgT1BUSU9OQUwuIFRoZSBzY29wZSBvZiB0aGUgYWNjZXNzIHJlcXVlc3QgYXMgZGVzY3Jp YmVkIGJ5IDxhIGNsYXNzPSdpbmZvJyBocmVmPScjc2NvcGUnPlNlY3Rpb24mbmJzcDszLjM8c3Bh bj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+QWNjZXNzIFRva2VuIFNjb3BlPC9zcGFuPjxz cGFuPik8L3NwYW4+PC9hPi4KICAgICAgICAgICAgICAKPC9kZD4KPC9kbD48L2Jsb2NrcXVvdGU+ PHA+CiAgICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgICAgSWYgdGhlIGNsaWVudCB0eXBlIGlz IGNvbmZpZGVudGlhbCBvciB0aGUgY2xpZW50IHdhcyBpc3N1ZWQgY2xpZW50IGNyZWRlbnRpYWxz IChvcgogICAgICAgICAgICBhc3NpZ25lZCBvdGhlciBhdXRoZW50aWNhdGlvbiByZXF1aXJlbWVu dHMpLCB0aGUgY2xpZW50IE1VU1QgYXV0aGVudGljYXRlIHdpdGggdGhlCiAgICAgICAgICAgIGF1 dGhvcml6YXRpb24gc2VydmVyIGFzIGRlc2NyaWJlZCBpbiA8YSBjbGFzcz0naW5mbycgaHJlZj0n I3Rva2VuLWVuZHBvaW50LWF1dGgnPlNlY3Rpb24mbmJzcDszLjIuMTxzcGFuPiAoPC9zcGFuPjxz cGFuIGNsYXNzPSdpbmZvJz5DbGllbnQgQXV0aGVudGljYXRpb248L3NwYW4+PHNwYW4+KTwvc3Bh bj48L2E+LgogICAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICAgICAgRm9yIGV4YW1wbGUsIHRo ZSBjbGllbnQgbWFrZXMgdGhlIGZvbGxvd2luZyBIVFRQIHJlcXVlc3QgdXNpbmcgdHJhbnNwb3J0 LWxheWVyCiAgICAgICAgICAgICAgc2VjdXJpdHkgKGV4dHJhIGxpbmUgYnJlYWtzIGFyZSBmb3Ig ZGlzcGxheSBwdXJwb3NlcyBvbmx5KToKICAgICAgICAgICAgCjwvcD48ZGl2IHN0eWxlPSdkaXNw bGF5OiB0YWJsZTsgd2lkdGg6IDA7IG1hcmdpbi1sZWZ0OiAzZW07IG1hcmdpbi1yaWdodDogYXV0 byc+PHByZT4KCiAgUE9TVCAvdG9rZW4gSFRUUC8xLjEKICBIb3N0OiBzZXJ2ZXIuZXhhbXBsZS5j b20KICBBdXRob3JpemF0aW9uOiBCYXNpYyBjelpDYUdSU2EzRjBNenBuV0RGbVFtRjBNMkpXCiAg Q29udGVudC1UeXBlOiBhcHBsaWNhdGlvbi94LXd3dy1mb3JtLXVybGVuY29kZWQ7Y2hhcnNldD1V VEYtOAoKICBncmFudF90eXBlPXBhc3N3b3JkJmFtcDt1c2VybmFtZT1qb2huZG9lJmFtcDtwYXNz d29yZD1BM2RkajN3Cgo8L3ByZT48L2Rpdj4KPHA+CiAgICAgICAgICAgIFRoZSBhdXRob3JpemF0 aW9uIHNlcnZlciBNVVNUOgogICAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICAgIDwvcD4KPHVs IGNsYXNzPSJ0ZXh0Ij4KPGxpPgogICAgICAgICAgICAgICAgcmVxdWlyZSBjbGllbnQgYXV0aGVu dGljYXRpb24gZm9yIGNvbmZpZGVudGlhbCBjbGllbnRzIG9yIGZvciBhbnkgY2xpZW50IHRoYXQg d2FzCiAgICAgICAgICAgICAgICBpc3N1ZWQgY2xpZW50IGNyZWRlbnRpYWxzIChvciB3aXRoIG90 aGVyIGF1dGhlbnRpY2F0aW9uIHJlcXVpcmVtZW50cyksCiAgICAgICAgICAgICAgCjwvbGk+Cjxs aT4KICAgICAgICAgICAgICAgIGF1dGhlbnRpY2F0ZSB0aGUgY2xpZW50IGlmIGNsaWVudCBhdXRo ZW50aWNhdGlvbiBpcyBpbmNsdWRlZCwgYW5kCiAgICAgICAgICAgICAgCjwvbGk+CjxsaT4KICAg ICAgICAgICAgICAgIHZhbGlkYXRlIHRoZSByZXNvdXJjZSBvd25lciBwYXNzd29yZCBjcmVkZW50 aWFscyB1c2luZyBpdHMgZXhpc3RpbmcgcGFzc3dvcmQKICAgICAgICAgICAgICAgIHZhbGlkYXRp b24gYWxnb3JpdGhtLgogICAgICAgICAgICAgIAo8L2xpPgo8L3VsPjxwPgogICAgICAgICAgCjwv cD4KPHA+CiAgICAgICAgICAgIFNpbmNlIHRoaXMgYWNjZXNzIHRva2VuIHJlcXVlc3QgdXRpbGl6 ZXMgdGhlIHJlc291cmNlIG93bmVyJ3MgcGFzc3dvcmQsIHRoZQogICAgICAgICAgICBhdXRob3Jp emF0aW9uIHNlcnZlciBNVVNUIHByb3RlY3QgdGhlIGVuZHBvaW50IGFnYWluc3QgYnJ1dGUgZm9y Y2UgYXR0YWNrcyAoZS5nLiB1c2luZwogICAgICAgICAgICByYXRlLWxpbWl0YXRpb24gb3IgZ2Vu ZXJhdGluZyBhbGVydHMpLgogICAgICAgICAgCjwvcD4KPGEgbmFtZT0iYW5jaG9yMjgiPjwvYT48 YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxz cGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRP Q2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxl Pgo8YSBuYW1lPSJyZmMuc2VjdGlvbi40LjMuMyI+PC9hPjxoMz40LjMuMy4mbmJzcDsKQWNjZXNz IFRva2VuIFJlc3BvbnNlPC9oMz4KCjxwPgogICAgICAgICAgICBJZiB0aGUgYWNjZXNzIHRva2Vu IHJlcXVlc3QgaXMgdmFsaWQgYW5kIGF1dGhvcml6ZWQsIHRoZSBhdXRob3JpemF0aW9uIHNlcnZl ciBpc3N1ZXMgYW4KICAgICAgICAgICAgYWNjZXNzIHRva2VuIGFuZCBvcHRpb25hbCByZWZyZXNo IHRva2VuIGFzIGRlc2NyaWJlZCBpbiA8YSBjbGFzcz0naW5mbycgaHJlZj0nI3Rva2VuLXJlc3Bv bnNlJz5TZWN0aW9uJm5ic3A7NS4xPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPlN1 Y2Nlc3NmdWwgUmVzcG9uc2U8L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+LgogICAgICAgICAgICBJ ZiB0aGUgcmVxdWVzdCBmYWlsZWQgY2xpZW50IGF1dGhlbnRpY2F0aW9uIG9yIGlzIGludmFsaWQs IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciByZXR1cm5zCiAgICAgICAgICAgIGFuIGVycm9yIHJl c3BvbnNlIGFzIGRlc2NyaWJlZCBpbiA8YSBjbGFzcz0naW5mbycgaHJlZj0nI3Rva2VuLWVycm9y cyc+U2VjdGlvbiZuYnNwOzUuMjxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5FcnJv ciBSZXNwb25zZTwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4uCiAgICAgICAgICAKPC9wPgo8cD4K ICAgICAgICAgICAgICBBbiBleGFtcGxlIHN1Y2Nlc3NmdWwgcmVzcG9uc2U6CiAgICAgICAgICAg IAo8L3A+PGRpdiBzdHlsZT0nZGlzcGxheTogdGFibGU7IHdpZHRoOiAwOyBtYXJnaW4tbGVmdDog M2VtOyBtYXJnaW4tcmlnaHQ6IGF1dG8nPjxwcmU+CgogIEhUVFAvMS4xIDIwMCBPSwogIENvbnRl bnQtVHlwZTogYXBwbGljYXRpb24vanNvbjtjaGFyc2V0PVVURi04CiAgQ2FjaGUtQ29udHJvbDog bm8tc3RvcmUKICBQcmFnbWE6IG5vLWNhY2hlCgogIHsKICAgICJhY2Nlc3NfdG9rZW4iOiIyWW90 bkZaRkVqcjF6Q3NpY01XcEFBIiwKICAgICJ0b2tlbl90eXBlIjoiZXhhbXBsZSIsCiAgICAiZXhw aXJlc19pbiI6MzYwMCwKICAgICJyZWZyZXNoX3Rva2VuIjoidEd6djNKT2tGMFhHNVF4MlRsS1dJ QSIsCiAgICAiZXhhbXBsZV9wYXJhbWV0ZXIiOiJleGFtcGxlX3ZhbHVlIgogIH0KCjwvcHJlPjwv ZGl2Pgo8YSBuYW1lPSJncmFudC1jbGllbnQiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1h cnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVn IiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5i c3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi40 LjQiPjwvYT48aDM+NC40LiZuYnNwOwpDbGllbnQgQ3JlZGVudGlhbHMgR3JhbnQ8L2gzPgoKPHA+ CiAgICAgICAgICBUaGUgY2xpZW50IGNhbiByZXF1ZXN0IGFuIGFjY2VzcyB0b2tlbiB1c2luZyBv bmx5IGl0cyBjbGllbnQgY3JlZGVudGlhbHMgKG9yIG90aGVyCiAgICAgICAgICBzdXBwb3J0ZWQg bWVhbnMgb2YgYXV0aGVudGljYXRpb24pIHdoZW4gdGhlIGNsaWVudCBpcyByZXF1ZXN0aW5nIGFj Y2VzcyB0byB0aGUKICAgICAgICAgIHByb3RlY3RlZCByZXNvdXJjZXMgdW5kZXIgaXRzIGNvbnRy b2wsIG9yIHRob3NlIG9mIGFub3RoZXIgcmVzb3VyY2Ugb3duZXIgd2hpY2ggaGFzIGJlZW4KICAg ICAgICAgIHByZXZpb3VzbHkgYXJyYW5nZWQgd2l0aCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIg KHRoZSBtZXRob2Qgb2Ygd2hpY2ggaXMgYmV5b25kIHRoZQogICAgICAgICAgc2NvcGUgb2YgdGhp cyBzcGVjaWZpY2F0aW9uKS4KICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgIFRoZSBjbGllbnQg Y3JlZGVudGlhbHMgZ3JhbnQgdHlwZSBNVVNUIG9ubHkgYmUgdXNlZCBieSBjb25maWRlbnRpYWwg Y2xpZW50cy4KICAgICAgICAKPC9wPjxiciAvPjxociBjbGFzcz0iaW5zZXJ0IiAvPgo8YSBuYW1l PSJGaWd1cmUtNiI+PC9hPgo8ZGl2IHN0eWxlPSdkaXNwbGF5OiB0YWJsZTsgd2lkdGg6IDA7IG1h cmdpbi1sZWZ0OiAzZW07IG1hcmdpbi1yaWdodDogYXV0byc+PHByZT4KCiAgKy0tLS0tLS0tLSsg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLSsKICB8ICAg ICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAg fAogIHwgICAgICAgICB8Jmd0Oy0tKEEpLSBDbGllbnQgQXV0aGVudGljYXRpb24gLS0tJmd0O3wg QXV0aG9yaXphdGlvbiB8CiAgfCBDbGllbnQgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgfCAgICAgU2VydmVyICAgIHwKICB8ICAgICAgICAgfCZsdDstLShCKS0tLS0gQWNjZXNz IFRva2VuIC0tLS0tLS0tLSZsdDt8ICAgICAgICAgICAgICAgfAogIHwgICAgICAgICB8ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICB8CiAgKy0tLS0tLS0t LSsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLSsKCjwv cHJlPjwvZGl2Pjx0YWJsZSBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0i MiIgYWxpZ249ImNlbnRlciI+PHRyPjx0ZCBhbGlnbj0iY2VudGVyIj48Zm9udCBmYWNlPSJtb25h Y28sIE1TIFNhbnMgU2VyaWYiIHNpemU9IjEiPjxiPiZuYnNwO0ZpZ3VyZSZuYnNwOzY6IENsaWVu dCBDcmVkZW50aWFscyBGbG93Jm5ic3A7PC9iPjwvZm9udD48YnIgLz48L3RkPjwvdHI+PC90YWJs ZT48aHIgY2xhc3M9Imluc2VydCIgLz4KCjxwPgogICAgICAgICAgVGhlIGZsb3cgaWxsdXN0cmF0 ZWQgaW4gPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNGaWd1cmUtNic+RmlndXJlJm5ic3A7NjxzcGFu PiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5DbGllbnQgQ3JlZGVudGlhbHMgRmxvdzwvc3Bh bj48c3Bhbj4pPC9zcGFuPjwvYT4gaW5jbHVkZXMgdGhlIGZvbGxvd2luZyBzdGVwczoKICAgICAg ICAKPC9wPgo8cD4KICAgICAgICAgIDwvcD4KPGJsb2NrcXVvdGUgY2xhc3M9InRleHQiPjxkbD4K PGR0PihBKTwvZHQ+CjxkZD4KICAgICAgICAgICAgICBUaGUgY2xpZW50IGF1dGhlbnRpY2F0ZXMg d2l0aCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYW5kIHJlcXVlc3RzIGFuIGFjY2VzcyB0b2tl bgogICAgICAgICAgICAgIGZyb20gdGhlIHRva2VuIGVuZHBvaW50LgogICAgICAgICAgICAKPC9k ZD4KPGR0PihCKTwvZHQ+CjxkZD4KICAgICAgICAgICAgICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2 ZXIgYXV0aGVudGljYXRlcyB0aGUgY2xpZW50LCBhbmQgaWYgdmFsaWQgaXNzdWVzIGFuIGFjY2Vz cwogICAgICAgICAgICAgIHRva2VuLgogICAgICAgICAgICAKPC9kZD4KPC9kbD48L2Jsb2NrcXVv dGU+PHA+CiAgICAgICAgCjwvcD4KPGEgbmFtZT0iYW5jaG9yMjkiPjwvYT48YnIgLz48aHIgLz4K PHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBj bGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJl Zj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJy ZmMuc2VjdGlvbi40LjQuMSI+PC9hPjxoMz40LjQuMS4mbmJzcDsKQXV0aG9yaXphdGlvbiBSZXF1 ZXN0IGFuZCBSZXNwb25zZTwvaDM+Cgo8cD4KICAgICAgICAgICAgU2luY2UgdGhlIGNsaWVudCBh dXRoZW50aWNhdGlvbiBpcyB1c2VkIGFzIHRoZSBhdXRob3JpemF0aW9uIGdyYW50LCBubyBhZGRp dGlvbmFsCiAgICAgICAgICAgIGF1dGhvcml6YXRpb24gcmVxdWVzdCBpcyBuZWVkZWQuCiAgICAg ICAgICAKPC9wPgo8YSBuYW1lPSJjbGllbnQtcmVxIj48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBz dW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRP Q2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2Mi PiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rp b24uNC40LjIiPjwvYT48aDM+NC40LjIuJm5ic3A7CkFjY2VzcyBUb2tlbiBSZXF1ZXN0PC9oMz4K CjxwPgogICAgICAgICAgICBUaGUgY2xpZW50IG1ha2VzIGEgcmVxdWVzdCB0byB0aGUgdG9rZW4g ZW5kcG9pbnQgYnkgYWRkaW5nIHRoZSBmb2xsb3dpbmcgcGFyYW1ldGVycwogICAgICAgICAgICB1 c2luZyB0aGUgPHR0PmFwcGxpY2F0aW9uL3gtd3d3LWZvcm0tdXJsZW5jb2RlZDwvdHQ+IGZvcm1h dCBpbiB0aGUKICAgICAgICAgICAgSFRUUCByZXF1ZXN0IGVudGl0eS1ib2R5OgogICAgICAgICAg CjwvcD4KPHA+CiAgICAgICAgICAgIDwvcD4KPGJsb2NrcXVvdGUgY2xhc3M9InRleHQiPjxkbD4K PGR0PmdyYW50X3R5cGU8L2R0Pgo8ZGQ+CiAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAg IFJFUVVJUkVELiBWYWx1ZSBNVVNUIGJlIHNldCB0byA8dHQ+Y2xpZW50X2NyZWRlbnRpYWxzPC90 dD4uCiAgICAgICAgICAgICAgCjwvZGQ+CjxkdD5zY29wZTwvZHQ+CjxkZD4KICAgICAgICAgICAg ICAgIAogICAgICAgICAgICAgICAgT1BUSU9OQUwuIFRoZSBzY29wZSBvZiB0aGUgYWNjZXNzIHJl cXVlc3QgYXMgZGVzY3JpYmVkIGJ5IDxhIGNsYXNzPSdpbmZvJyBocmVmPScjc2NvcGUnPlNlY3Rp b24mbmJzcDszLjM8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+QWNjZXNzIFRva2Vu IFNjb3BlPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPi4KICAgICAgICAgICAgICAKPC9kZD4KPC9k bD48L2Jsb2NrcXVvdGU+PHA+CiAgICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgICAgVGhlIGNs aWVudCBNVVNUIGF1dGhlbnRpY2F0ZSB3aXRoIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBhcyBk ZXNjcmliZWQgaW4KICAgICAgICAgICAgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyN0b2tlbi1lbmRw b2ludC1hdXRoJz5TZWN0aW9uJm5ic3A7My4yLjE8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0n aW5mbyc+Q2xpZW50IEF1dGhlbnRpY2F0aW9uPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPi4KICAg ICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgICAgIEZvciBleGFtcGxlLCB0aGUgY2xpZW50IG1h a2VzIHRoZSBmb2xsb3dpbmcgSFRUUCByZXF1ZXN0IHVzaW5nIHRyYW5zcG9ydC1sYXllcgogICAg ICAgICAgICAgIHNlY3VyaXR5IChleHRyYSBsaW5lIGJyZWFrcyBhcmUgZm9yIGRpc3BsYXkgcHVy cG9zZXMgb25seSk6CiAgICAgICAgICAgIAo8L3A+PGRpdiBzdHlsZT0nZGlzcGxheTogdGFibGU7 IHdpZHRoOiAwOyBtYXJnaW4tbGVmdDogM2VtOyBtYXJnaW4tcmlnaHQ6IGF1dG8nPjxwcmU+Cgog IFBPU1QgL3Rva2VuIEhUVFAvMS4xCiAgSG9zdDogc2VydmVyLmV4YW1wbGUuY29tCiAgQXV0aG9y aXphdGlvbjogQmFzaWMgY3paQ2FHUlNhM0YwTXpwbldERm1RbUYwTTJKVwogIENvbnRlbnQtVHlw ZTogYXBwbGljYXRpb24veC13d3ctZm9ybS11cmxlbmNvZGVkO2NoYXJzZXQ9VVRGLTgKCiAgZ3Jh bnRfdHlwZT1jbGllbnRfY3JlZGVudGlhbHMKCjwvcHJlPjwvZGl2Pgo8cD4KICAgICAgICAgICAg VGhlIGF1dGhvcml6YXRpb24gc2VydmVyIE1VU1QgYXV0aGVudGljYXRlIHRoZSBjbGllbnQuCiAg ICAgICAgICAKPC9wPgo8YSBuYW1lPSJhbmNob3IzMCI+PC9hPjxiciAvPjxociAvPgo8dGFibGUg c3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJU T0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9j Ij4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0 aW9uLjQuNC4zIj48L2E+PGgzPjQuNC4zLiZuYnNwOwpBY2Nlc3MgVG9rZW4gUmVzcG9uc2U8L2gz PgoKPHA+CiAgICAgICAgICAgIElmIHRoZSBhY2Nlc3MgdG9rZW4gcmVxdWVzdCBpcyB2YWxpZCBh bmQgYXV0aG9yaXplZCwgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGlzc3VlcyBhbgogICAgICAg ICAgICBhY2Nlc3MgdG9rZW4gYXMgZGVzY3JpYmVkIGluIDxhIGNsYXNzPSdpbmZvJyBocmVmPScj dG9rZW4tcmVzcG9uc2UnPlNlY3Rpb24mbmJzcDs1LjE8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFz cz0naW5mbyc+U3VjY2Vzc2Z1bCBSZXNwb25zZTwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4uIEEg cmVmcmVzaCB0b2tlbiBTSE9VTEQKICAgICAgICAgICAgTk9UIGJlIGluY2x1ZGVkLiBJZiB0aGUg cmVxdWVzdCBmYWlsZWQgY2xpZW50IGF1dGhlbnRpY2F0aW9uIG9yIGlzIGludmFsaWQsIHRoZQog ICAgICAgICAgICBhdXRob3JpemF0aW9uIHNlcnZlciByZXR1cm5zIGFuIGVycm9yIHJlc3BvbnNl IGFzIGRlc2NyaWJlZCBpbgogICAgICAgICAgICA8YSBjbGFzcz0naW5mbycgaHJlZj0nI3Rva2Vu LWVycm9ycyc+U2VjdGlvbiZuYnNwOzUuMjxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZv Jz5FcnJvciBSZXNwb25zZTwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4uCiAgICAgICAgICAKPC9w Pgo8cD4KICAgICAgICAgICAgICBBbiBleGFtcGxlIHN1Y2Nlc3NmdWwgcmVzcG9uc2U6CiAgICAg ICAgICAgIAo8L3A+PGRpdiBzdHlsZT0nZGlzcGxheTogdGFibGU7IHdpZHRoOiAwOyBtYXJnaW4t bGVmdDogM2VtOyBtYXJnaW4tcmlnaHQ6IGF1dG8nPjxwcmU+CgogIEhUVFAvMS4xIDIwMCBPSwog IENvbnRlbnQtVHlwZTogYXBwbGljYXRpb24vanNvbjtjaGFyc2V0PVVURi04CiAgQ2FjaGUtQ29u dHJvbDogbm8tc3RvcmUKICBQcmFnbWE6IG5vLWNhY2hlCgogIHsKICAgICJhY2Nlc3NfdG9rZW4i OiIyWW90bkZaRkVqcjF6Q3NpY01XcEFBIiwKICAgICJ0b2tlbl90eXBlIjoiZXhhbXBsZSIsCiAg ICAiZXhwaXJlc19pbiI6MzYwMCwKICAgICJleGFtcGxlX3BhcmFtZXRlciI6ImV4YW1wbGVfdmFs dWUiCiAgfQoKPC9wcmU+PC9kaXY+CjxhIG5hbWU9ImV4dC1ncmFudCI+PC9hPjxiciAvPjxociAv Pgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIi IGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBo cmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9 InJmYy5zZWN0aW9uLjQuNSI+PC9hPjxoMz40LjUuJm5ic3A7CkV4dGVuc2lvbiBHcmFudHM8L2gz PgoKPHA+CiAgICAgICAgICBUaGUgY2xpZW50IHVzZXMgYW4gZXh0ZW5zaW9uIGdyYW50IHR5cGUg Ynkgc3BlY2lmeWluZyB0aGUgZ3JhbnQgdHlwZSB1c2luZyBhbgogICAgICAgICAgYWJzb2x1dGUg VVJJIChkZWZpbmVkIGJ5IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlcikgYXMgdGhlIHZhbHVlIG9m IHRoZQogICAgICAgICAgPHR0PmdyYW50X3R5cGU8L3R0PiBwYXJhbWV0ZXIgb2YgdGhlIHRva2Vu IGVuZHBvaW50LCBhbmQgYnkKICAgICAgICAgIGFkZGluZyBhbnkgYWRkaXRpb25hbCBwYXJhbWV0 ZXJzIG5lY2Vzc2FyeS4KICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgICAgRm9yIGV4YW1wbGUs IHRvIHJlcXVlc3QgYW4gYWNjZXNzIHRva2VuIHVzaW5nIGEgU0FNTCAyLjAgYXNzZXJ0aW9uIGdy YW50IHR5cGUgYXMKICAgICAgICAgICAgZGVmaW5lZCBieSA8YSBjbGFzcz0naW5mbycgaHJlZj0n I0ktRC5pZXRmLW9hdXRoLXNhbWwyLWJlYXJlcic+W0kmIzgyMDk7RC5pZXRmJiM4MjA5O29hdXRo JiM4MjA5O3NhbWwyJiM4MjA5O2JlYXJlcl08c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5m byc+TW9ydGltb3JlLCBDLiwgJmxkcXVvO1NBTUwgMi4wIEJlYXJlciBBc3NlcnRpb24gUHJvZmls ZXMgZm9yIE9BdXRoIDIuMCwmcmRxdW87IE1heSZuYnNwOzIwMTIuPC9zcGFuPjxzcGFuPik8L3Nw YW4+PC9hPiwgdGhlIGNsaWVudCBtYWtlcyB0aGUKICAgICAgICAgICAgZm9sbG93aW5nIEhUVFAg cmVxdWVzdCB1c2luZyBUTFMgKGxpbmUgYnJlYWtzIGFyZSBmb3IgZGlzcGxheSBwdXJwb3NlcyBv bmx5KToKICAgICAgICAgIAo8L3A+PGRpdiBzdHlsZT0nZGlzcGxheTogdGFibGU7IHdpZHRoOiAw OyBtYXJnaW4tbGVmdDogM2VtOyBtYXJnaW4tcmlnaHQ6IGF1dG8nPjxwcmU+CgogIFBPU1QgL3Rv a2VuIEhUVFAvMS4xCiAgSG9zdDogc2VydmVyLmV4YW1wbGUuY29tCiAgQ29udGVudC1UeXBlOiBh cHBsaWNhdGlvbi94LXd3dy1mb3JtLXVybGVuY29kZWQ7Y2hhcnNldD1VVEYtOAoKICBncmFudF90 eXBlPXVybiUzQWlldGYlM0FwYXJhbXMlM0FvYXV0aCUzQWdyYW50LXR5cGUlM0FzYW1sMi0KICBi ZWFyZXImYW1wO2Fzc2VydGlvbj1QRUZ6YzJWeWRHbHZiaUJKYzNOMVpVbHVjM1JoYm5ROUlqSXdN VEV0TURVCiAgWy4uLm9taXR0ZWQgZm9yIGJyZXZpdHkuLi5dYUc1VGRHRjBaVzFsYm5RLVBDOUJj M05sY25ScGIyNC0KCjwvcHJlPjwvZGl2Pgo8cD4KICAgICAgICAgIElmIHRoZSBhY2Nlc3MgdG9r ZW4gcmVxdWVzdCBpcyB2YWxpZCBhbmQgYXV0aG9yaXplZCwgdGhlIGF1dGhvcml6YXRpb24gc2Vy dmVyIGlzc3VlcyBhbgogICAgICAgICAgYWNjZXNzIHRva2VuIGFuZCBvcHRpb25hbCByZWZyZXNo IHRva2VuIGFzIGRlc2NyaWJlZCBpbiA8YSBjbGFzcz0naW5mbycgaHJlZj0nI3Rva2VuLXJlc3Bv bnNlJz5TZWN0aW9uJm5ic3A7NS4xPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPlN1 Y2Nlc3NmdWwgUmVzcG9uc2U8L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+LgogICAgICAgICAgSWYg dGhlIHJlcXVlc3QgZmFpbGVkIGNsaWVudCBhdXRoZW50aWNhdGlvbiBvciBpcyBpbnZhbGlkLCB0 aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgcmV0dXJucwogICAgICAgICAgYW4gZXJyb3IgcmVzcG9u c2UgYXMgZGVzY3JpYmVkIGluIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjdG9rZW4tZXJyb3JzJz5T ZWN0aW9uJm5ic3A7NS4yPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkVycm9yIFJl c3BvbnNlPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPi4KICAgICAgICAKPC9wPgo8YSBuYW1lPSJ0 b2tlbi1pc3N1ZSI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxs cGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+ PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+ PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLjUiPjwvYT48aDM+NS4mbmJz cDsKSXNzdWluZyBhbiBBY2Nlc3MgVG9rZW48L2gzPgoKPHA+CiAgICAgICAgSWYgdGhlIGFjY2Vz cyB0b2tlbiByZXF1ZXN0IGlzIHZhbGlkIGFuZCBhdXRob3JpemVkLCB0aGUgYXV0aG9yaXphdGlv biBzZXJ2ZXIgaXNzdWVzIGFuCiAgICAgICAgYWNjZXNzIHRva2VuIGFuZCBvcHRpb25hbCByZWZy ZXNoIHRva2VuIGFzIGRlc2NyaWJlZCBpbiA8YSBjbGFzcz0naW5mbycgaHJlZj0nI3Rva2VuLXJl c3BvbnNlJz5TZWN0aW9uJm5ic3A7NS4xPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8n PlN1Y2Nlc3NmdWwgUmVzcG9uc2U8L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+LgogICAgICAgIElm IHRoZSByZXF1ZXN0IGZhaWxlZCBjbGllbnQgYXV0aGVudGljYXRpb24gb3IgaXMgaW52YWxpZCwg dGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHJldHVybnMKICAgICAgICBhbiBlcnJvciByZXNwb25z ZSBhcyBkZXNjcmliZWQgaW4gPGEgY2xhc3M9J2luZm8nIGhyZWY9JyN0b2tlbi1lcnJvcnMnPlNl Y3Rpb24mbmJzcDs1LjI8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+RXJyb3IgUmVz cG9uc2U8L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+LgogICAgICAKPC9wPgo8YSBuYW1lPSJ0b2tl bi1yZXNwb25zZSI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxs cGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+ PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+ PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLjUuMSI+PC9hPjxoMz41LjEu Jm5ic3A7ClN1Y2Nlc3NmdWwgUmVzcG9uc2U8L2gzPgoKPHA+CiAgICAgICAgICBUaGUgYXV0aG9y aXphdGlvbiBzZXJ2ZXIgaXNzdWVzIGFuIGFjY2VzcyB0b2tlbiBhbmQgb3B0aW9uYWwgcmVmcmVz aCB0b2tlbiwgYW5kCiAgICAgICAgICBjb25zdHJ1Y3RzIHRoZSByZXNwb25zZSBieSBhZGRpbmcg dGhlIGZvbGxvd2luZyBwYXJhbWV0ZXJzIHRvIHRoZSBlbnRpdHkgYm9keSBvZiB0aGUgSFRUUAog ICAgICAgICAgcmVzcG9uc2Ugd2l0aCBhIDIwMCAoT0spIHN0YXR1cyBjb2RlOgogICAgICAgIAo8 L3A+CjxwPgogICAgICAgICAgPC9wPgo8YmxvY2txdW90ZSBjbGFzcz0idGV4dCI+PGRsPgo8ZHQ+ YWNjZXNzX3Rva2VuPC9kdD4KPGRkPgogICAgICAgICAgICAgIAogICAgICAgICAgICAgIFJFUVVJ UkVELiBUaGUgYWNjZXNzIHRva2VuIGlzc3VlZCBieSB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIu CiAgICAgICAgICAgIAo8L2RkPgo8ZHQ+dG9rZW5fdHlwZTwvZHQ+CjxkZD4KICAgICAgICAgICAg ICAKICAgICAgICAgICAgICBSRVFVSVJFRC4gVGhlIHR5cGUgb2YgdGhlIHRva2VuIGlzc3VlZCBh cyBkZXNjcmliZWQgaW4gPGEgY2xhc3M9J2luZm8nIGhyZWY9JyN0b2tlbi10eXBlcyc+U2VjdGlv biZuYnNwOzcuMTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5BY2Nlc3MgVG9rZW4g VHlwZXM8L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+LgogICAgICAgICAgICAgIFZhbHVlIGlzIGNh c2UgaW5zZW5zaXRpdmUuCiAgICAgICAgICAgIAo8L2RkPgo8ZHQ+ZXhwaXJlc19pbjwvZHQ+Cjxk ZD4KICAgICAgICAgICAgICAKICAgICAgICAgICAgICBSRUNPTU1FTkRFRC4gVGhlIGxpZmV0aW1l IGluIHNlY29uZHMgb2YgdGhlIGFjY2VzcyB0b2tlbi4gRm9yIGV4YW1wbGUsIHRoZSB2YWx1ZQog ICAgICAgICAgICAgIDx0dD4zNjAwPC90dD4gZGVub3RlcyB0aGF0IHRoZSBhY2Nlc3MgdG9rZW4g d2lsbCBleHBpcmUgaW4gb25lCiAgICAgICAgICAgICAgaG91ciBmcm9tIHRoZSB0aW1lIHRoZSBy ZXNwb25zZSB3YXMgZ2VuZXJhdGVkLiBJZiBvbWl0dGVkLCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2 ZXIKICAgICAgICAgICAgICBTSE9VTEQgcHJvdmlkZSB0aGUgZXhwaXJhdGlvbiB0aW1lIHZpYSBv dGhlciBtZWFucyBvciBkb2N1bWVudCB0aGUgZGVmYXVsdCB2YWx1ZS4KICAgICAgICAgICAgCjwv ZGQ+CjxkdD5yZWZyZXNoX3Rva2VuPC9kdD4KPGRkPgogICAgICAgICAgICAgIAogICAgICAgICAg ICAgIE9QVElPTkFMLiBUaGUgcmVmcmVzaCB0b2tlbiB3aGljaCBjYW4gYmUgdXNlZCB0byBvYnRh aW4gbmV3IGFjY2VzcyB0b2tlbnMgdXNpbmcgdGhlCiAgICAgICAgICAgICAgc2FtZSBhdXRob3Jp emF0aW9uIGdyYW50IGFzIGRlc2NyaWJlZCBpbiA8YSBjbGFzcz0naW5mbycgaHJlZj0nI3Rva2Vu LXJlZnJlc2gnPlNlY3Rpb24mbmJzcDs2PHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8n PlJlZnJlc2hpbmcgYW4gQWNjZXNzIFRva2VuPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPi4KICAg ICAgICAgICAgCjwvZGQ+CjxkdD5zY29wZTwvZHQ+CjxkZD4KICAgICAgICAgICAgICAKICAgICAg ICAgICAgICBPUFRJT05BTCwgaWYgaWRlbnRpY2FsIHRvIHRoZSBzY29wZSByZXF1ZXN0ZWQgYnkg dGhlIGNsaWVudCwgb3RoZXJ3aXNlIFJFUVVJUkVELiBUaGUKICAgICAgICAgICAgICBzY29wZSBv ZiB0aGUgYWNjZXNzIHRva2VuIGFzIGRlc2NyaWJlZCBieSA8YSBjbGFzcz0naW5mbycgaHJlZj0n I3Njb3BlJz5TZWN0aW9uJm5ic3A7My4zPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8n PkFjY2VzcyBUb2tlbiBTY29wZTwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4uCiAgICAgICAgICAg IAo8L2RkPgo8L2RsPjwvYmxvY2txdW90ZT48cD4KICAgICAgICAKPC9wPgo8cD4KICAgICAgICAg IFRoZSBwYXJhbWV0ZXJzIGFyZSBpbmNsdWRlZCBpbiB0aGUgZW50aXR5IGJvZHkgb2YgdGhlIEhU VFAgcmVzcG9uc2UgdXNpbmcgdGhlCiAgICAgICAgICA8dHQ+YXBwbGljYXRpb24vanNvbjwvdHQ+ IG1lZGlhIHR5cGUgYXMgZGVmaW5lZCBieQogICAgICAgICAgPGEgY2xhc3M9J2luZm8nIGhyZWY9 JyNSRkM0NjI3Jz5bUkZDNDYyN108c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+Q3Jv Y2tmb3JkLCBELiwgJmxkcXVvO1RoZSBhcHBsaWNhdGlvbi9qc29uIE1lZGlhIFR5cGUgZm9yIEph dmFTY3JpcHQgT2JqZWN0IE5vdGF0aW9uIChKU09OKSwmcmRxdW87IEp1bHkmbmJzcDsyMDA2Ljwv c3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4uIFRoZSBwYXJhbWV0ZXJzIGFyZSBzZXJpYWxpemVkIGlu dG8gYSBKU09OIHN0cnVjdHVyZSBieQogICAgICAgICAgYWRkaW5nIGVhY2ggcGFyYW1ldGVyIGF0 IHRoZSBoaWdoZXN0IHN0cnVjdHVyZSBsZXZlbC4gUGFyYW1ldGVyIG5hbWVzIGFuZCBzdHJpbmcg dmFsdWVzCiAgICAgICAgICBhcmUgaW5jbHVkZWQgYXMgSlNPTiBzdHJpbmdzLiBOdW1lcmljYWwg dmFsdWVzIGFyZSBpbmNsdWRlZCBhcyBKU09OIG51bWJlcnMuIFRoZSBvcmRlciBvZgogICAgICAg ICAgcGFyYW1ldGVycyBkb2VzIG5vdCBtYXR0ZXIgYW5kIGNhbiB2YXJ5LgogICAgICAgIAo8L3A+ CjxwPgogICAgICAgICAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIE1VU1QgaW5jbHVkZSB0aGUg SFRUUAogICAgICAgICAgPHR0PkNhY2hlLUNvbnRyb2w8L3R0PiByZXNwb25zZSBoZWFkZXIgZmll bGQgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNSRkMyNjE2Jz5bUkZDMjYxNl08c3Bhbj4gKDwvc3Bh bj48c3BhbiBjbGFzcz0naW5mbyc+RmllbGRpbmcsIFIuLCBHZXR0eXMsIEouLCBNb2d1bCwgSi4s IEZyeXN0eWssIEguLCBNYXNpbnRlciwgTC4sIExlYWNoLCBQLiwgYW5kIFQuIEJlcm5lcnMtTGVl LCAmbGRxdW87SHlwZXJ0ZXh0IFRyYW5zZmVyIFByb3RvY29sIC0tIEhUVFAvMS4xLCZyZHF1bzsg SnVuZSZuYnNwOzE5OTkuPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPgogICAgICAgICAgd2l0aCBh IHZhbHVlIG9mIDx0dD5uby1zdG9yZTwvdHQ+IGluIGFueSByZXNwb25zZSBjb250YWluaW5nIHRv a2VucywKICAgICAgICAgIGNyZWRlbnRpYWxzLCBvciBvdGhlciBzZW5zaXRpdmUgaW5mb3JtYXRp b24sIGFzIHdlbGwgYXMgdGhlCiAgICAgICAgICA8dHQ+UHJhZ21hPC90dD4gcmVzcG9uc2UgaGVh ZGVyIGZpZWxkIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjUkZDMjYxNic+W1JGQzI2MTZdPHNwYW4+ ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkZpZWxkaW5nLCBSLiwgR2V0dHlzLCBKLiwgTW9n dWwsIEouLCBGcnlzdHlrLCBILiwgTWFzaW50ZXIsIEwuLCBMZWFjaCwgUC4sIGFuZCBULiBCZXJu ZXJzLUxlZSwgJmxkcXVvO0h5cGVydGV4dCBUcmFuc2ZlciBQcm90b2NvbCAtLSBIVFRQLzEuMSwm cmRxdW87IEp1bmUmbmJzcDsxOTk5Ljwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4gd2l0aCBhCiAg ICAgICAgICB2YWx1ZSBvZiA8dHQ+bm8tY2FjaGU8L3R0Pi4KICAgICAgICAKPC9wPgo8cD4KICAg ICAgICAgICAgRm9yIGV4YW1wbGU6CiAgICAgICAgICAKPC9wPjxkaXYgc3R5bGU9J2Rpc3BsYXk6 IHRhYmxlOyB3aWR0aDogMDsgbWFyZ2luLWxlZnQ6IDNlbTsgbWFyZ2luLXJpZ2h0OiBhdXRvJz48 cHJlPgoKICBIVFRQLzEuMSAyMDAgT0sKICBDb250ZW50LVR5cGU6IGFwcGxpY2F0aW9uL2pzb247 Y2hhcnNldD1VVEYtOAogIENhY2hlLUNvbnRyb2w6IG5vLXN0b3JlCiAgUHJhZ21hOiBuby1jYWNo ZQoKICB7CiAgICAiYWNjZXNzX3Rva2VuIjoiMllvdG5GWkZFanIxekNzaWNNV3BBQSIsCiAgICAi dG9rZW5fdHlwZSI6ImV4YW1wbGUiLAogICAgImV4cGlyZXNfaW4iOjM2MDAsCiAgICAicmVmcmVz aF90b2tlbiI6InRHenYzSk9rRjBYRzVReDJUbEtXSUEiLAogICAgImV4YW1wbGVfcGFyYW1ldGVy IjoiZXhhbXBsZV92YWx1ZSIKICB9Cgo8L3ByZT48L2Rpdj4KPHA+CiAgICAgICAgICBUaGUgY2xp ZW50IE1VU1QgaWdub3JlIHVucmVjb2duaXplZCB2YWx1ZSBuYW1lcyBpbiB0aGUgcmVzcG9uc2Uu IFRoZSBzaXplcyBvZiB0b2tlbnMgYW5kCiAgICAgICAgICBvdGhlciB2YWx1ZXMgcmVjZWl2ZWQg ZnJvbSB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYXJlIGxlZnQgdW5kZWZpbmVkLiBUaGUgY2xp ZW50IHNob3VsZAogICAgICAgICAgYXZvaWQgbWFraW5nIGFzc3VtcHRpb25zIGFib3V0IHZhbHVl IHNpemVzLiBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgU0hPVUxEIGRvY3VtZW50IHRoZQogICAg ICAgICAgc2l6ZSBvZiBhbnkgdmFsdWUgaXQgaXNzdWVzLgogICAgICAgIAo8L3A+CjxhIG5hbWU9 InRva2VuLWVycm9ycyI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBj ZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdo dCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8 L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLjUuMiI+PC9hPjxoMz41 LjIuJm5ic3A7CkVycm9yIFJlc3BvbnNlPC9oMz4KCjxwPgogICAgICAgICAgVGhlIGF1dGhvcml6 YXRpb24gc2VydmVyIHJlc3BvbmRzIHdpdGggYW4gSFRUUCA0MDAgKEJhZCBSZXF1ZXN0KSBzdGF0 dXMgY29kZSAodW5sZXNzCiAgICAgICAgICBzcGVjaWZpZWQgb3RoZXJ3aXNlKSBhbmQgaW5jbHVk ZXMgdGhlIGZvbGxvd2luZyBwYXJhbWV0ZXJzIHdpdGggdGhlIHJlc3BvbnNlOgogICAgICAgIAo8 L3A+CjxwPgogICAgICAgICAgPC9wPgo8YmxvY2txdW90ZSBjbGFzcz0idGV4dCI+PGRsPgo8ZHQ+ ZXJyb3I8L2R0Pgo8ZGQ+CiAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgUkVRVUlSRUQuIEEg c2luZ2xlIEFTQ0lJIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjVVNBU0NJSSc+W1VTQVNDSUldPHNw YW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkFtZXJpY2FuIE5hdGlvbmFsIFN0YW5kYXJk cyBJbnN0aXR1dGUsICZsZHF1bztDb2RlZCBDaGFyYWN0ZXIgU2V0IC0tIDctYml0IEFtZXJpY2Fu IFN0YW5kYXJkIENvZGUgZm9yIEluZm9ybWF0aW9uIEludGVyY2hhbmdlLCZyZHF1bzsgMTk4Ni48 L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+IGVycm9yIGNvZGUgZnJvbSB0aGUgZm9sbG93aW5nOgoK ICAgICAgICAgICAgICAKPGJsb2NrcXVvdGUgY2xhc3M9InRleHQiPjxkbD4KPGR0PmludmFsaWRf cmVxdWVzdDwvZHQ+CjxkZD4KICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgIFRo ZSByZXF1ZXN0IGlzIG1pc3NpbmcgYSByZXF1aXJlZCBwYXJhbWV0ZXIsIGluY2x1ZGVzIGFuIHVu c3VwcG9ydGVkCiAgICAgICAgICAgICAgICAgIHBhcmFtZXRlciB2YWx1ZSAob3RoZXIgdGhhbiBn cmFudCB0eXBlKSwgcmVwZWF0cyBhIHBhcmFtZXRlciwgaW5jbHVkZXMgbXVsdGlwbGUKICAgICAg ICAgICAgICAgICAgY3JlZGVudGlhbHMsIHV0aWxpemVzIG1vcmUgdGhhbiBvbmUgbWVjaGFuaXNt IGZvciBhdXRoZW50aWNhdGluZyB0aGUgY2xpZW50LAogICAgICAgICAgICAgICAgICBvciBpcyBv dGhlcndpc2UgbWFsZm9ybWVkLgogICAgICAgICAgICAgICAgCjwvZGQ+CjxkdD5pbnZhbGlkX2Ns aWVudDwvZHQ+CjxkZD4KICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgIENsaWVu dCBhdXRoZW50aWNhdGlvbiBmYWlsZWQgKGUuZy4gdW5rbm93biBjbGllbnQsIG5vIGNsaWVudCBh dXRoZW50aWNhdGlvbgogICAgICAgICAgICAgICAgICBpbmNsdWRlZCwgb3IgdW5zdXBwb3J0ZWQg YXV0aGVudGljYXRpb24gbWV0aG9kKS4gVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIE1BWQogICAg ICAgICAgICAgICAgICByZXR1cm4gYW4gSFRUUCA0MDEgKFVuYXV0aG9yaXplZCkgc3RhdHVzIGNv ZGUgdG8gaW5kaWNhdGUgd2hpY2ggSFRUUAogICAgICAgICAgICAgICAgICBhdXRoZW50aWNhdGlv biBzY2hlbWVzIGFyZSBzdXBwb3J0ZWQuIElmIHRoZSBjbGllbnQgYXR0ZW1wdGVkIHRvIGF1dGhl bnRpY2F0ZSB2aWEKICAgICAgICAgICAgICAgICAgdGhlIDx0dD5BdXRob3JpemF0aW9uPC90dD4g cmVxdWVzdCBoZWFkZXIgZmllbGQsCiAgICAgICAgICAgICAgICAgIHRoZSBhdXRob3JpemF0aW9u IHNlcnZlciBNVVNUIHJlc3BvbmQgd2l0aCBhbiBIVFRQIDQwMSAoVW5hdXRob3JpemVkKSBzdGF0 dXMKICAgICAgICAgICAgICAgICAgY29kZSwgYW5kIGluY2x1ZGUgdGhlIDx0dD5XV1ctQXV0aGVu dGljYXRlPC90dD4gcmVzcG9uc2UKICAgICAgICAgICAgICAgICAgaGVhZGVyIGZpZWxkIG1hdGNo aW5nIHRoZSBhdXRoZW50aWNhdGlvbiBzY2hlbWUgdXNlZCBieSB0aGUgY2xpZW50LgogICAgICAg ICAgICAgICAgCjwvZGQ+CjxkdD5pbnZhbGlkX2dyYW50PC9kdD4KPGRkPgogICAgICAgICAgICAg ICAgICAKICAgICAgICAgICAgICAgICAgVGhlIHByb3ZpZGVkIGF1dGhvcml6YXRpb24gZ3JhbnQg KGUuZy4gYXV0aG9yaXphdGlvbiBjb2RlLCByZXNvdXJjZSBvd25lcgogICAgICAgICAgICAgICAg ICBjcmVkZW50aWFscykgb3IgcmVmcmVzaCB0b2tlbiBpcyBpbnZhbGlkLCBleHBpcmVkLCByZXZv a2VkLCBkb2VzIG5vdCBtYXRjaCB0aGUKICAgICAgICAgICAgICAgICAgcmVkaXJlY3Rpb24gVVJJ IHVzZWQgaW4gdGhlIGF1dGhvcml6YXRpb24gcmVxdWVzdCwgb3Igd2FzIGlzc3VlZCB0byBhbm90 aGVyCiAgICAgICAgICAgICAgICAgIGNsaWVudC4KICAgICAgICAgICAgICAgIAo8L2RkPgo8ZHQ+ dW5hdXRob3JpemVkX2NsaWVudDwvZHQ+CjxkZD4KICAgICAgICAgICAgICAgICAgCiAgICAgICAg ICAgICAgICAgIFRoZSBhdXRoZW50aWNhdGVkIGNsaWVudCBpcyBub3QgYXV0aG9yaXplZCB0byB1 c2UgdGhpcyBhdXRob3JpemF0aW9uIGdyYW50IHR5cGUuCiAgICAgICAgICAgICAgICAKPC9kZD4K PGR0PnVuc3VwcG9ydGVkX2dyYW50X3R5cGU8L2R0Pgo8ZGQ+CiAgICAgICAgICAgICAgICAgIAog ICAgICAgICAgICAgICAgICBUaGUgYXV0aG9yaXphdGlvbiBncmFudCB0eXBlIGlzIG5vdCBzdXBw b3J0ZWQgYnkgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLgogICAgICAgICAgICAgICAgCjwvZGQ+ CjxkdD5pbnZhbGlkX3Njb3BlPC9kdD4KPGRkPgogICAgICAgICAgICAgICAgICAKICAgICAgICAg ICAgICAgICAgVGhlIHJlcXVlc3RlZCBzY29wZSBpcyBpbnZhbGlkLCB1bmtub3duLCBtYWxmb3Jt ZWQsIG9yIGV4Y2VlZHMgdGhlIHNjb3BlIGdyYW50ZWQKICAgICAgICAgICAgICAgICAgYnkgdGhl IHJlc291cmNlIG93bmVyLgogICAgICAgICAgICAgICAgCjwvZGQ+CjwvZGw+PC9ibG9ja3F1b3Rl PgoKCSAgICAgIFZhbHVlcyBmb3IgdGhlIDx0dD5lcnJvcjwvdHQ+IHBhcmFtZXRlciBNVVNUIE5P VCBpbmNsdWRlCgkgICAgICBjaGFyYWN0ZXJzIG91dHNpZGUgdGhlIHNldCAleDIwLTIxIC8gJXgy My01QiAvICV4NUQtN0UuCiAgICAgICAgICAgIAo8L2RkPgo8ZHQ+ZXJyb3JfZGVzY3JpcHRpb248 L2R0Pgo8ZGQ+CiAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgT1BUSU9OQUwuIEEgaHVtYW4t cmVhZGFibGUgQVNDSUkgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNVU0FTQ0lJJz5bVVNBU0NJSV08 c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+QW1lcmljYW4gTmF0aW9uYWwgU3RhbmRh cmRzIEluc3RpdHV0ZSwgJmxkcXVvO0NvZGVkIENoYXJhY3RlciBTZXQgLS0gNy1iaXQgQW1lcmlj YW4gU3RhbmRhcmQgQ29kZSBmb3IgSW5mb3JtYXRpb24gSW50ZXJjaGFuZ2UsJnJkcXVvOyAxOTg2 Ljwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4gdGV4dCBwcm92aWRpbmcgYWRkaXRpb25hbCBpbmZv cm1hdGlvbiwKICAgICAgICAgICAgICB1c2VkIHRvIGFzc2lzdCB0aGUgY2xpZW50IGRldmVsb3Bl ciBpbiB1bmRlcnN0YW5kaW5nIHRoZSBlcnJvciB0aGF0IG9jY3VycmVkLgoJICAgICAgPGJyIC8+ CgoJICAgICAgVmFsdWVzIGZvciB0aGUgPHR0PmVycm9yX2Rlc2NyaXB0aW9uPC90dD4gcGFyYW1l dGVyIE1VU1QgTk9UIGluY2x1ZGUKCSAgICAgIGNoYXJhY3RlcnMgb3V0c2lkZSB0aGUgc2V0ICV4 MjAtMjEgLyAleDIzLTVCIC8gJXg1RC03RS4KICAgICAgICAgICAgCjwvZGQ+CjxkdD5lcnJvcl91 cmk8L2R0Pgo8ZGQ+CiAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgT1BUSU9OQUwuIEEgVVJJ IGlkZW50aWZ5aW5nIGEgaHVtYW4tcmVhZGFibGUgd2ViIHBhZ2Ugd2l0aCBpbmZvcm1hdGlvbiBh Ym91dCB0aGUKICAgICAgICAgICAgICBlcnJvciwgdXNlZCB0byBwcm92aWRlIHRoZSBjbGllbnQg ZGV2ZWxvcGVyIHdpdGggYWRkaXRpb25hbCBpbmZvcm1hdGlvbiBhYm91dCB0aGUKICAgICAgICAg ICAgICBlcnJvci4KCSAgICAgIDxiciAvPgoKCSAgICAgIFZhbHVlcyBmb3IgdGhlIDx0dD5lcnJv cl91cmk8L3R0PiBwYXJhbWV0ZXIKCSAgICAgIE1VU1QgY29uZm9ybSB0byB0aGUgVVJJLVJlZmVy ZW5jZSBzeW50YXgsIGFuZCB0aHVzIE1VU1QgTk9UIGluY2x1ZGUKCSAgICAgIGNoYXJhY3RlcnMg b3V0c2lkZSB0aGUgc2V0ICV4MjEgLyAleDIzLTVCIC8gJXg1RC03RS4KICAgICAgICAgICAgCjwv ZGQ+CjwvZGw+PC9ibG9ja3F1b3RlPjxwPgogICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgVGhl IHBhcmFtZXRlcnMgYXJlIGluY2x1ZGVkIGluIHRoZSBlbnRpdHkgYm9keSBvZiB0aGUgSFRUUCBy ZXNwb25zZSB1c2luZyB0aGUKICAgICAgICAgIDx0dD5hcHBsaWNhdGlvbi9qc29uPC90dD4gbWVk aWEgdHlwZSBhcyBkZWZpbmVkIGJ5CiAgICAgICAgICA8YSBjbGFzcz0naW5mbycgaHJlZj0nI1JG QzQ2MjcnPltSRkM0NjI3XTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5Dcm9ja2Zv cmQsIEQuLCAmbGRxdW87VGhlIGFwcGxpY2F0aW9uL2pzb24gTWVkaWEgVHlwZSBmb3IgSmF2YVNj cmlwdCBPYmplY3QgTm90YXRpb24gKEpTT04pLCZyZHF1bzsgSnVseSZuYnNwOzIwMDYuPC9zcGFu PjxzcGFuPik8L3NwYW4+PC9hPi4gVGhlIHBhcmFtZXRlcnMgYXJlIHNlcmlhbGl6ZWQgaW50byBh IEpTT04gc3RydWN0dXJlIGJ5CiAgICAgICAgICBhZGRpbmcgZWFjaCBwYXJhbWV0ZXIgYXQgdGhl IGhpZ2hlc3Qgc3RydWN0dXJlIGxldmVsLiBQYXJhbWV0ZXIgbmFtZXMgYW5kIHN0cmluZyB2YWx1 ZXMKICAgICAgICAgIGFyZSBpbmNsdWRlZCBhcyBKU09OIHN0cmluZ3MuIE51bWVyaWNhbCB2YWx1 ZXMgYXJlIGluY2x1ZGVkIGFzIEpTT04gbnVtYmVycy4gVGhlIG9yZGVyIG9mCiAgICAgICAgICBw YXJhbWV0ZXJzIGRvZXMgbm90IG1hdHRlciBhbmQgY2FuIHZhcnkuCiAgICAgICAgCjwvcD4KPHA+ CiAgICAgICAgICAgIEZvciBleGFtcGxlOgogICAgICAgICAgCjwvcD48ZGl2IHN0eWxlPSdkaXNw bGF5OiB0YWJsZTsgd2lkdGg6IDA7IG1hcmdpbi1sZWZ0OiAzZW07IG1hcmdpbi1yaWdodDogYXV0 byc+PHByZT4KCiAgSFRUUC8xLjEgNDAwIEJhZCBSZXF1ZXN0CiAgQ29udGVudC1UeXBlOiBhcHBs aWNhdGlvbi9qc29uO2NoYXJzZXQ9VVRGLTgKICBDYWNoZS1Db250cm9sOiBuby1zdG9yZQogIFBy YWdtYTogbm8tY2FjaGUKCiAgewogICAgImVycm9yIjoiaW52YWxpZF9yZXF1ZXN0IgogIH0KCjwv cHJlPjwvZGl2Pgo8YSBuYW1lPSJ0b2tlbi1yZWZyZXNoIj48L2E+PGJyIC8+PGhyIC8+Cjx0YWJs ZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9 IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0 b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNl Y3Rpb24uNiI+PC9hPjxoMz42LiZuYnNwOwpSZWZyZXNoaW5nIGFuIEFjY2VzcyBUb2tlbjwvaDM+ Cgo8cD4KICAgICAgICBJZiB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgaXNzdWVkIGEgcmVmcmVz aCB0b2tlbiB0byB0aGUgY2xpZW50LCB0aGUgY2xpZW50IG1ha2VzIGEKICAgICAgICByZWZyZXNo IHJlcXVlc3QgdG8gdGhlIHRva2VuIGVuZHBvaW50IGJ5IGFkZGluZyB0aGUgZm9sbG93aW5nIHBh cmFtZXRlcnMgdXNpbmcgdGhlCiAgICAgICAgPHR0PmFwcGxpY2F0aW9uL3gtd3d3LWZvcm0tdXJs ZW5jb2RlZDwvdHQ+IGZvcm1hdCBpbiB0aGUgSFRUUCByZXF1ZXN0CiAgICAgICAgZW50aXR5LWJv ZHk6CiAgICAgIAo8L3A+CjxwPgogICAgICAgIDwvcD4KPGJsb2NrcXVvdGUgY2xhc3M9InRleHQi PjxkbD4KPGR0PmdyYW50X3R5cGU8L2R0Pgo8ZGQ+CiAgICAgICAgICAgIAogICAgICAgICAgICBS RVFVSVJFRC4gVmFsdWUgTVVTVCBiZSBzZXQgdG8gPHR0PnJlZnJlc2hfdG9rZW48L3R0Pi4KICAg ICAgICAgIAo8L2RkPgo8ZHQ+cmVmcmVzaF90b2tlbjwvZHQ+CjxkZD4KICAgICAgICAgICAgCiAg ICAgICAgICAgIFJFUVVJUkVELiBUaGUgcmVmcmVzaCB0b2tlbiBpc3N1ZWQgdG8gdGhlIGNsaWVu dC4KICAgICAgICAgIAo8L2RkPgo8ZHQ+c2NvcGU8L2R0Pgo8ZGQ+CiAgICAgICAgICAgIAogICAg ICAgICAgICBPUFRJT05BTC4gVGhlIHNjb3BlIG9mIHRoZSBhY2Nlc3MgcmVxdWVzdCBhcyBkZXNj cmliZWQgYnkgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNzY29wZSc+U2VjdGlvbiZuYnNwOzMuMzxz cGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5BY2Nlc3MgVG9rZW4gU2NvcGU8L3NwYW4+ PHNwYW4+KTwvc3Bhbj48L2E+LgogICAgICAgICAgICBUaGUgcmVxdWVzdGVkIHNjb3BlIE1VU1Qg Tk9UIGluY2x1ZGUgYW55IHNjb3BlIG5vdCBvcmlnaW5hbGx5IGdyYW50ZWQgYnkgdGhlIHJlc291 cmNlCiAgICAgICAgICAgIG93bmVyLCBhbmQgaWYgb21pdHRlZCBpcyB0cmVhdGVkIGFzIGVxdWFs IHRvIHRoZSBzY29wZSBvcmlnaW5hbGx5IGdyYW50ZWQgYnkgdGhlCiAgICAgICAgICAgIHJlc291 cmNlIG93bmVyLgogICAgICAgICAgCjwvZGQ+CjwvZGw+PC9ibG9ja3F1b3RlPjxwPgogICAgICAK PC9wPgo8cD4KICAgICAgICBCZWNhdXNlIHJlZnJlc2ggdG9rZW5zIGFyZSB0eXBpY2FsbHkgbG9u Zy1sYXN0aW5nIGNyZWRlbnRpYWxzIHVzZWQgdG8gcmVxdWVzdCBhZGRpdGlvbmFsCiAgICAgICAg YWNjZXNzIHRva2VucywgdGhlIHJlZnJlc2ggdG9rZW4gaXMgYm91bmQgdG8gdGhlIGNsaWVudCB3 aGljaCBpdCB3YXMgaXNzdWVkLiBJZiB0aGUgY2xpZW50IHR5cGUKICAgICAgICBpcyBjb25maWRl bnRpYWwgb3IgdGhlIGNsaWVudCB3YXMgaXNzdWVkIGNsaWVudCBjcmVkZW50aWFscyAob3IgYXNz aWduZWQgb3RoZXIKICAgICAgICBhdXRoZW50aWNhdGlvbiByZXF1aXJlbWVudHMpLCB0aGUgY2xp ZW50IE1VU1QgYXV0aGVudGljYXRlIHdpdGggdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGFzCiAg ICAgICAgZGVzY3JpYmVkIGluIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjdG9rZW4tZW5kcG9pbnQt YXV0aCc+U2VjdGlvbiZuYnNwOzMuMi4xPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8n PkNsaWVudCBBdXRoZW50aWNhdGlvbjwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4uCiAgICAgIAo8 L3A+CjxwPgogICAgICAgICAgRm9yIGV4YW1wbGUsIHRoZSBjbGllbnQgbWFrZXMgdGhlIGZvbGxv d2luZyBIVFRQIHJlcXVlc3QgdXNpbmcgdHJhbnNwb3J0LWxheWVyCiAgICAgICAgICBzZWN1cml0 eSAoZXh0cmEgbGluZSBicmVha3MgYXJlIGZvciBkaXNwbGF5IHB1cnBvc2VzIG9ubHkpOgogICAg ICAgIAo8L3A+PGRpdiBzdHlsZT0nZGlzcGxheTogdGFibGU7IHdpZHRoOiAwOyBtYXJnaW4tbGVm dDogM2VtOyBtYXJnaW4tcmlnaHQ6IGF1dG8nPjxwcmU+CgogIFBPU1QgL3Rva2VuIEhUVFAvMS4x CiAgSG9zdDogc2VydmVyLmV4YW1wbGUuY29tCiAgQXV0aG9yaXphdGlvbjogQmFzaWMgY3paQ2FH UlNhM0YwTXpwbldERm1RbUYwTTJKVwogIENvbnRlbnQtVHlwZTogYXBwbGljYXRpb24veC13d3ct Zm9ybS11cmxlbmNvZGVkO2NoYXJzZXQ9VVRGLTgKCiAgZ3JhbnRfdHlwZT1yZWZyZXNoX3Rva2Vu JmFtcDtyZWZyZXNoX3Rva2VuPXRHenYzSk9rRjBYRzVReDJUbEtXSUEKCjwvcHJlPjwvZGl2Pgo8 cD4KICAgICAgICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVTVDoKICAgICAgCjwvcD4KPHA+ CiAgICAgICAgPC9wPgo8dWwgY2xhc3M9InRleHQiPgo8bGk+CiAgICAgICAgICAgIHJlcXVpcmUg Y2xpZW50IGF1dGhlbnRpY2F0aW9uIGZvciBjb25maWRlbnRpYWwgY2xpZW50cyBvciBmb3IgYW55 IGNsaWVudCB0aGF0IHdhcwogICAgICAgICAgICBpc3N1ZWQgY2xpZW50IGNyZWRlbnRpYWxzIChv ciB3aXRoIG90aGVyIGF1dGhlbnRpY2F0aW9uIHJlcXVpcmVtZW50cyksCiAgICAgICAgICAKPC9s aT4KPGxpPgogICAgICAgICAgICBhdXRoZW50aWNhdGUgdGhlIGNsaWVudCBpZiBjbGllbnQgYXV0 aGVudGljYXRpb24gaXMgaW5jbHVkZWQgYW5kIGVuc3VyZSB0aGUKICAgICAgICAgICAgcmVmcmVz aCB0b2tlbiB3YXMgaXNzdWVkIHRvIHRoZSBhdXRoZW50aWNhdGVkIGNsaWVudCwgYW5kCiAgICAg ICAgICAKPC9saT4KPGxpPgogICAgICAgICAgICB2YWxpZGF0ZSB0aGUgcmVmcmVzaCB0b2tlbi4K ICAgICAgICAgIAo8L2xpPgo8L3VsPjxwPgogICAgICAKPC9wPgo8cD4KICAgICAgICBJZiB2YWxp ZCBhbmQgYXV0aG9yaXplZCwgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGlzc3VlcyBhbiBhY2Nl c3MgdG9rZW4gYXMgZGVzY3JpYmVkIGluCiAgICAgICAgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyN0 b2tlbi1yZXNwb25zZSc+U2VjdGlvbiZuYnNwOzUuMTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNz PSdpbmZvJz5TdWNjZXNzZnVsIFJlc3BvbnNlPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPi4gSWYg dGhlIHJlcXVlc3QgZmFpbGVkIHZlcmlmaWNhdGlvbiBvciBpcyBpbnZhbGlkLCB0aGUKICAgICAg ICBhdXRob3JpemF0aW9uIHNlcnZlciByZXR1cm5zIGFuIGVycm9yIHJlc3BvbnNlIGFzIGRlc2Ny aWJlZCBpbgogICAgICAgIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjdG9rZW4tZXJyb3JzJz5TZWN0 aW9uJm5ic3A7NS4yPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkVycm9yIFJlc3Bv bnNlPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPi4KICAgICAgCjwvcD4KPHA+CiAgICAgICAgVGhl IGF1dGhvcml6YXRpb24gc2VydmVyIE1BWSBpc3N1ZSBhIG5ldyByZWZyZXNoIHRva2VuLCBpbiB3 aGljaCBjYXNlIHRoZSBjbGllbnQgTVVTVAogICAgICAgIGRpc2NhcmQgdGhlIG9sZCByZWZyZXNo IHRva2VuIGFuZCByZXBsYWNlIGl0IHdpdGggdGhlIG5ldyByZWZyZXNoIHRva2VuLiBUaGUgYXV0 aG9yaXphdGlvbgogICAgICAgIHNlcnZlciBNQVkgcmV2b2tlIHRoZSBvbGQgcmVmcmVzaCB0b2tl biBhZnRlciBpc3N1aW5nIGEgbmV3IHJlZnJlc2ggdG9rZW4gdG8gdGhlIGNsaWVudC4gSWYKICAg ICAgICBhIG5ldyByZWZyZXNoIHRva2VuIGlzIGlzc3VlZCwgdGhlIHJlZnJlc2ggdG9rZW4gc2Nv cGUgTVVTVCBiZSBpZGVudGljYWwgdG8gdGhhdCBvZiB0aGUKICAgICAgICByZWZyZXNoIHRva2Vu IGluY2x1ZGVkIGJ5IHRoZSBjbGllbnQgaW4gdGhlIHJlcXVlc3QuCiAgICAgIAo8L3A+CjxhIG5h bWU9ImFjY2Vzcy1yZXNvdXJjZSI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5 b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWdu PSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0Mm bmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLjciPjwvYT48 aDM+Ny4mbmJzcDsKQWNjZXNzaW5nIFByb3RlY3RlZCBSZXNvdXJjZXM8L2gzPgoKPHA+CiAgICAg ICAgVGhlIGNsaWVudCBhY2Nlc3NlcyBwcm90ZWN0ZWQgcmVzb3VyY2VzIGJ5IHByZXNlbnRpbmcg dGhlIGFjY2VzcyB0b2tlbiB0byB0aGUgcmVzb3VyY2UKICAgICAgICBzZXJ2ZXIuIFRoZSByZXNv dXJjZSBzZXJ2ZXIgTVVTVCB2YWxpZGF0ZSB0aGUgYWNjZXNzIHRva2VuIGFuZCBlbnN1cmUgaXQg aGFzIG5vdCBleHBpcmVkCiAgICAgICAgYW5kIHRoYXQgaXRzIHNjb3BlIGNvdmVycyB0aGUgcmVx dWVzdGVkIHJlc291cmNlLiBUaGUgbWV0aG9kcyB1c2VkIGJ5IHRoZSByZXNvdXJjZSBzZXJ2ZXIK ICAgICAgICB0byB2YWxpZGF0ZSB0aGUgYWNjZXNzIHRva2VuIChhcyB3ZWxsIGFzIGFueSBlcnJv ciByZXNwb25zZXMpIGFyZSBiZXlvbmQgdGhlIHNjb3BlIG9mIHRoaXMKICAgICAgICBzcGVjaWZp Y2F0aW9uLCBidXQgZ2VuZXJhbGx5IGludm9sdmUgYW4gaW50ZXJhY3Rpb24gb3IgY29vcmRpbmF0 aW9uIGJldHdlZW4gdGhlIHJlc291cmNlCiAgICAgICAgc2VydmVyIGFuZCB0aGUgYXV0aG9yaXph dGlvbiBzZXJ2ZXIuCiAgICAgIAo8L3A+CjxwPgogICAgICAgIFRoZSBtZXRob2QgaW4gd2hpY2gg dGhlIGNsaWVudCB1dGlsaXplcyB0aGUgYWNjZXNzIHRva2VuIHRvIGF1dGhlbnRpY2F0ZSB3aXRo IHRoZSByZXNvdXJjZQogICAgICAgIHNlcnZlciBkZXBlbmRzIG9uIHRoZSB0eXBlIG9mIGFjY2Vz cyB0b2tlbiBpc3N1ZWQgYnkgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLiBUeXBpY2FsbHksCiAg ICAgICAgaXQgaW52b2x2ZXMgdXNpbmcgdGhlIEhUVFAgPHR0PkF1dGhvcml6YXRpb248L3R0PiBy ZXF1ZXN0IGhlYWRlciBmaWVsZAogICAgICAgIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjUkZDMjYx Nyc+W1JGQzI2MTddPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkZyYW5rcywgSi4s IEhhbGxhbS1CYWtlciwgUC4sIEhvc3RldGxlciwgSi4sIExhd3JlbmNlLCBTLiwgTGVhY2gsIFAu LCBMdW90b25lbiwgQS4sIGFuZCBMLiBTdGV3YXJ0LCAmbGRxdW87SFRUUCBBdXRoZW50aWNhdGlv bjogQmFzaWMgYW5kIERpZ2VzdCBBY2Nlc3MgQXV0aGVudGljYXRpb24sJnJkcXVvOyBKdW5lJm5i c3A7MTk5OS48L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+IHdpdGggYW4gYXV0aGVudGljYXRpb24g c2NoZW1lIGRlZmluZWQgYnkgdGhlIGFjY2VzcyB0b2tlbiB0eXBlCiAgICAgICAgc3BlY2lmaWNh dGlvbi4KICAgICAgCjwvcD4KPGEgbmFtZT0idG9rZW4tdHlwZXMiPjwvYT48YnIgLz48aHIgLz4K PHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBj bGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJl Zj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJy ZmMuc2VjdGlvbi43LjEiPjwvYT48aDM+Ny4xLiZuYnNwOwpBY2Nlc3MgVG9rZW4gVHlwZXM8L2gz PgoKPHA+CiAgICAgICAgICBUaGUgYWNjZXNzIHRva2VuIHR5cGUgcHJvdmlkZXMgdGhlIGNsaWVu dCB3aXRoIHRoZSBpbmZvcm1hdGlvbiByZXF1aXJlZCB0byBzdWNjZXNzZnVsbHkKICAgICAgICAg IHV0aWxpemUgdGhlIGFjY2VzcyB0b2tlbiB0byBtYWtlIGEgcHJvdGVjdGVkIHJlc291cmNlIHJl cXVlc3QgKGFsb25nIHdpdGggdHlwZS1zcGVjaWZpYwogICAgICAgICAgYXR0cmlidXRlcykuIFRo ZSBjbGllbnQgTVVTVCBOT1QgdXNlIGFuIGFjY2VzcyB0b2tlbiBpZiBpdCBkb2VzIG5vdCB1bmRl cnN0YW5kIHRoZSB0b2tlbgogICAgICAgICAgdHlwZS4KICAgICAgICAKPC9wPgo8cD4KICAgICAg ICAgICAgRm9yIGV4YW1wbGUsIHRoZSA8dHQ+YmVhcmVyPC90dD4gdG9rZW4gdHlwZSBkZWZpbmVk IGluCiAgICAgICAgICAgIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjSS1ELmlldGYtb2F1dGgtdjIt YmVhcmVyJz5bSSYjODIwOTtELmlldGYmIzgyMDk7b2F1dGgmIzgyMDk7djImIzgyMDk7YmVhcmVy XTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5Kb25lcywgTS4sIEhhcmR0LCBELiwg YW5kIEQuIFJlY29yZG9uLCAmbGRxdW87VGhlIE9BdXRoIDIuMCBBdXRob3JpemF0aW9uIFByb3Rv Y29sOiBCZWFyZXIgVG9rZW5zLCZyZHF1bzsgQXByaWwmbmJzcDsyMDEyLjwvc3Bhbj48c3Bhbj4p PC9zcGFuPjwvYT4gaXMgdXRpbGl6ZWQgYnkgc2ltcGx5IGluY2x1ZGluZyB0aGUgYWNjZXNzCiAg ICAgICAgICAgIHRva2VuIHN0cmluZyBpbiB0aGUgcmVxdWVzdDoKICAgICAgICAgIAo8L3A+PGRp diBzdHlsZT0nZGlzcGxheTogdGFibGU7IHdpZHRoOiAwOyBtYXJnaW4tbGVmdDogM2VtOyBtYXJn aW4tcmlnaHQ6IGF1dG8nPjxwcmU+CgogIEdFVCAvcmVzb3VyY2UvMSBIVFRQLzEuMQogIEhvc3Q6 IGV4YW1wbGUuY29tCiAgQXV0aG9yaXphdGlvbjogQmVhcmVyIG1GXzkuQjVmLTQuMUpxTQoKPC9w cmU+PC9kaXY+CjxwPgogICAgICAgICAgICB3aGlsZSB0aGUgPHR0Pm1hYzwvdHQ+IHRva2VuIHR5 cGUgZGVmaW5lZCBpbgogICAgICAgICAgICA8YSBjbGFzcz0naW5mbycgaHJlZj0nI0ktRC5pZXRm LW9hdXRoLXYyLWh0dHAtbWFjJz5bSSYjODIwOTtELmlldGYmIzgyMDk7b2F1dGgmIzgyMDk7djIm IzgyMDk7aHR0cCYjODIwOTttYWNdPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkhh bW1lci1MYWhhdiwgRS4sICZsZHF1bztIVFRQIEF1dGhlbnRpY2F0aW9uOiBNQUMgQWNjZXNzIEF1 dGhlbnRpY2F0aW9uLCZyZHF1bzsgRmVicnVhcnkmbmJzcDsyMDEyLjwvc3Bhbj48c3Bhbj4pPC9z cGFuPjwvYT4gaXMgdXRpbGl6ZWQgYnkgaXNzdWluZyBhIE1BQyBrZXkKICAgICAgICAgICAgdG9n ZXRoZXIgd2l0aCB0aGUgYWNjZXNzIHRva2VuIHdoaWNoIGlzIHVzZWQgdG8gc2lnbiBjZXJ0YWlu IGNvbXBvbmVudHMgb2YgdGhlIEhUVFAKICAgICAgICAgICAgcmVxdWVzdHM6CiAgICAgICAgICAK PC9wPjxkaXYgc3R5bGU9J2Rpc3BsYXk6IHRhYmxlOyB3aWR0aDogMDsgbWFyZ2luLWxlZnQ6IDNl bTsgbWFyZ2luLXJpZ2h0OiBhdXRvJz48cHJlPgoKICBHRVQgL3Jlc291cmNlLzEgSFRUUC8xLjEK ICBIb3N0OiBleGFtcGxlLmNvbQogIEF1dGhvcml6YXRpb246IE1BQyBpZD0iaDQ4MGRqczkzaGQ4 IiwKICAgICAgICAgICAgICAgICAgICAgbm9uY2U9IjI3NDMxMjpkajgzaHM5cyIsCiAgICAgICAg ICAgICAgICAgICAgIG1hYz0ia0RadmRka25keHZoR1JYWmh2dURqRVdoR2VFPSIKCjwvcHJlPjwv ZGl2Pgo8cD4KICAgICAgICAgIFRoZSBhYm92ZSBleGFtcGxlcyBhcmUgcHJvdmlkZWQgZm9yIGls bHVzdHJhdGlvbiBwdXJwb3NlcyBvbmx5LiBEZXZlbG9wZXJzIGFyZSBhZHZpc2VkIHRvCiAgICAg ICAgICBjb25zdWx0IHRoZSA8YSBjbGFzcz0naW5mbycgaHJlZj0nI0ktRC5pZXRmLW9hdXRoLXYy LWJlYXJlcic+W0kmIzgyMDk7RC5pZXRmJiM4MjA5O29hdXRoJiM4MjA5O3YyJiM4MjA5O2JlYXJl cl08c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+Sm9uZXMsIE0uLCBIYXJkdCwgRC4s IGFuZCBELiBSZWNvcmRvbiwgJmxkcXVvO1RoZSBPQXV0aCAyLjAgQXV0aG9yaXphdGlvbiBQcm90 b2NvbDogQmVhcmVyIFRva2VucywmcmRxdW87IEFwcmlsJm5ic3A7MjAxMi48L3NwYW4+PHNwYW4+ KTwvc3Bhbj48L2E+IGFuZAogICAgICAgICAgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNJLUQuaWV0 Zi1vYXV0aC12Mi1odHRwLW1hYyc+W0kmIzgyMDk7RC5pZXRmJiM4MjA5O29hdXRoJiM4MjA5O3Yy JiM4MjA5O2h0dHAmIzgyMDk7bWFjXTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5I YW1tZXItTGFoYXYsIEUuLCAmbGRxdW87SFRUUCBBdXRoZW50aWNhdGlvbjogTUFDIEFjY2VzcyBB dXRoZW50aWNhdGlvbiwmcmRxdW87IEZlYnJ1YXJ5Jm5ic3A7MjAxMi48L3NwYW4+PHNwYW4+KTwv c3Bhbj48L2E+IHNwZWNpZmljYXRpb25zIGJlZm9yZSB1c2UuCiAgICAgICAgCjwvcD4KPHA+CiAg ICAgICAgICBFYWNoIGFjY2VzcyB0b2tlbiB0eXBlIGRlZmluaXRpb24gc3BlY2lmaWVzIHRoZSBh ZGRpdGlvbmFsIGF0dHJpYnV0ZXMgKGlmIGFueSkgc2VudCB0bwogICAgICAgICAgdGhlIGNsaWVu dCB0b2dldGhlciB3aXRoIHRoZSA8dHQ+YWNjZXNzX3Rva2VuPC90dD4gcmVzcG9uc2UgcGFyYW1l dGVyLgogICAgICAgICAgSXQgYWxzbyBkZWZpbmVzIHRoZSBIVFRQIGF1dGhlbnRpY2F0aW9uIG1l dGhvZCB1c2VkIHRvIGluY2x1ZGUgdGhlIGFjY2VzcyB0b2tlbiB3aGVuCiAgICAgICAgICBtYWtp bmcgYSBwcm90ZWN0ZWQgcmVzb3VyY2UgcmVxdWVzdC4KICAgICAgICAKPC9wPgo8YSBuYW1lPSJy ZXNvdXJjZS1lcnJvcnMiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIg Y2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmln aHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7 PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi43LjIiPjwvYT48aDM+ Ny4yLiZuYnNwOwpFcnJvciBSZXNwb25zZTwvaDM+Cgo8cD4KCSAgSWYgYSByZXNvdXJjZSBhY2Nl c3MgcmVxdWVzdCBmYWlscywgdGhlIHJlc291cmNlIHNlcnZlciBTSE9VTEQgaW5mb3JtCgkgIHRo ZSBjbGllbnQgb2YgdGhlIGVycm9yLiAgV2hpbGUgdGhlIHNwZWNpZmljIGVycm9yIHJlc3BvbnNl cyBwb3NzaWJsZQoJICBhbmQgbWV0aG9kcyBmb3IgdHJhbnNtaXR0aW5nIHRob3NlIGVycm9ycyB3 aGVuIHVzaW5nIGFueSBwYXJ0aWN1bGFyCgkgIGFjY2VzcyB0b2tlbiB0eXBlIGFyZSBiZXlvbmQg dGhlIHNjb3BlIG9mIHRoaXMgc3BlY2lmaWNhdGlvbiwKCSAgYW55IDx0dD5lcnJvcjwvdHQ+IGNv ZGUgdmFsdWVzIGRlZmluZWQgZm9yIHVzZSB3aXRoCgkgIE9BdXRoIHJlc291cmNlIGFjY2VzcyBt ZXRob2RzIE1VU1QgYmUgcmVnaXN0ZXJlZAoJICAoZm9sbG93aW5nIHRoZSBwcm9jZWR1cmVzIGlu IDxhIGNsYXNzPSdpbmZvJyBocmVmPScjZXJyb3ItcmVnaXN0cnknPlNlY3Rpb24mbmJzcDsxMS40 PHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPlRoZSBPQXV0aCBFeHRlbnNpb25zIEVy cm9yIFJlZ2lzdHJ5PC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPikuCgkKPC9wPgo8cD4KCSAgU3Bl Y2lmaWNhbGx5LCB3aGVuIHRoZSBPQXV0aCByZXNvdXJjZSBhY2Nlc3MgbWV0aG9kIHVzZXMgYW4K CSAgPHR0PmVycm9yPC90dD4gcmVzdWx0IHBhcmFtZXRlciB0byByZXR1cm4KCSAgYW4gZXJyb3Ig Y29kZSB2YWx1ZSB0aGF0IGluZGljYXRlcyB0aGUgcmVzb3VyY2UgYWNjZXNzIGVycm9yCgkgIGVu Y291bnRlcmVkLCB0aGVuIHRoZXNlIGVycm9yIGNvZGUgdmFsdWVzIE1VU1QgYmUgcmVnaXN0ZXJl ZC4KCSAgVmFsdWVzIGZvciB0aGVzZSA8dHQ+ZXJyb3I8L3R0PiBjb2RlcyBNVVNUIE5PVCBpbmNs dWRlCgkgIGNoYXJhY3RlcnMgb3V0c2lkZSB0aGUgc2V0ICV4MjAtMjEgLyAleDIzLTVCIC8gJXg1 RC03RS4KCSAgV2hlbiBhbiAgPHR0PmVycm9yPC90dD4gY29kZSB2YWx1ZSBpcyByZWdpc3RlcmVk CgkgIGZvciB1c2UgYnkgYW4gT0F1dGggcmVzb3VyY2UgYWNjZXNzIG1ldGhvZCwgc2hvdWxkIHRo YXQgc2FtZSBjb2RlIGFscmVhZHkKCSAgYmUgcmVnaXN0ZXJlZCBmb3IgdXNlIGJ5IGFub3RoZXIg T0F1dGggcmVzb3VyY2UgYWNjZXNzIG1ldGhvZCBvciBhdAoJICBhIGRpZmZlcmVudCBPQXV0aCBl cnJvciB1c2FnZSBsb2NhdGlvbiwgdGhlbiB0aGUgbWVhbmluZyBvZiB0aGF0IGVycm9yIGNvZGUK CSAgdmFsdWUgaW4gaW4gdGhlIG5ldyByZWdpc3RyYXRpb24gTVVTVCBiZSBjb25zaXN0ZW50IHdp dGggdGhlIGl0cyBtZWFuaW5nCgkgIGluIHByaW9yIHJlZ2lzdHJhdGlvbnMuCgkKPC9wPgo8cD4K CSAgVGhlIE9BdXRoIHJlc291cmNlIGFjY2VzcyBlcnJvciByZWdpc3RyYXRpb24gcmVxdWlyZW1l bnQgYXBwbGllcyBvbmx5IHRvCgkgIDx0dD5lcnJvcjwvdHQ+IGNvZGUgdmFsdWVzIGFuZCBub3Qg dG8gb3RoZXIKCSAgbWVhbnMgb2YgcmV0dXJuaW5nIGVycm9yIGluZGljYXRpb25zLCBpbmNsdWRp bmcgSFRUUCBzdGF0dXMgY29kZXMsCgkgIG9yIG90aGVyIGVycm9yLXJlbGF0ZWQgcmVzdWx0IHBh cmFtZXRlcnMsIHN1Y2ggYXMKCSAgPHR0PmVycm9yX2Rlc2NyaXB0aW9uPC90dD4sCgkgIDx0dD5l cnJvcl91cmk8L3R0Piwgb3Igb3RoZXIga2luZHMgb2YgZXJyb3IKCSAgc3RhdHVzIHJldHVybiBt ZXRob2RzIHRoYXQgbWF5IGJlIGVtcGxveWVkIGJ5IHRoZSByZXNvdXJjZSBhY2Nlc3MgbWV0aG9k LgoJICBUaGVyZSBpcyBubyByZXF1aXJlbWVudCB0aGF0IE9BdXRoIHJlc291cmNlIGFjY2VzcyBt ZXRob2RzCgkgIGVtcGxveSBhbiA8dHQ+ZXJyb3I8L3R0PiBwYXJhbWV0ZXIuCgkKPC9wPgo8YSBu YW1lPSJleHRlbnNpb25zIj48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQi IGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJp Z2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNw OzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uOCI+PC9hPjxoMz44 LiZuYnNwOwpFeHRlbnNpYmlsaXR5PC9oMz4KCjxhIG5hbWU9Im5ldy10eXBlcyI+PC9hPjxiciAv PjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNp bmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVn Ij48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+Cjxh IG5hbWU9InJmYy5zZWN0aW9uLjguMSI+PC9hPjxoMz44LjEuJm5ic3A7CkRlZmluaW5nIEFjY2Vz cyBUb2tlbiBUeXBlczwvaDM+Cgo8cD4KICAgICAgICAgIEFjY2VzcyB0b2tlbiB0eXBlcyBjYW4g YmUgZGVmaW5lZCBpbiBvbmUgb2YgdHdvIHdheXM6IHJlZ2lzdGVyZWQgaW4gdGhlIGFjY2VzcyB0 b2tlbiB0eXBlCiAgICAgICAgICByZWdpc3RyeSAoZm9sbG93aW5nIHRoZSBwcm9jZWR1cmVzIGlu IDxhIGNsYXNzPSdpbmZvJyBocmVmPScjdHlwZS1yZWdpc3RyeSc+U2VjdGlvbiZuYnNwOzExLjE8 c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+VGhlIE9BdXRoIEFjY2VzcyBUb2tlbiBU eXBlIFJlZ2lzdHJ5PC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPiksIG9yIGJ5IHVzaW5nIGEKICAg ICAgICAgIHVuaXF1ZSBhYnNvbHV0ZSBVUkkgYXMgaXRzIG5hbWUuCiAgICAgICAgCjwvcD4KPHA+ CiAgICAgICAgICBUeXBlcyB1dGlsaXppbmcgYSBVUkkgbmFtZSBTSE9VTEQgYmUgbGltaXRlZCB0 byB2ZW5kb3Itc3BlY2lmaWMgaW1wbGVtZW50YXRpb25zIHRoYXQgYXJlCiAgICAgICAgICBub3Qg Y29tbW9ubHkgYXBwbGljYWJsZSwgYW5kIGFyZSBzcGVjaWZpYyB0byB0aGUgaW1wbGVtZW50YXRp b24gZGV0YWlscyBvZiB0aGUgcmVzb3VyY2UKICAgICAgICAgIHNlcnZlciB3aGVyZSB0aGV5IGFy ZSB1c2VkLgogICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgQWxsIG90aGVyIHR5cGVzIE1VU1Qg YmUgcmVnaXN0ZXJlZC4gVHlwZSBuYW1lcyBNVVNUIGNvbmZvcm0gdG8gdGhlIHR5cGUtbmFtZSBB Qk5GLiBJZiB0aGUKICAgICAgICAgIHR5cGUgZGVmaW5pdGlvbiBpbmNsdWRlcyBhIG5ldyBIVFRQ IGF1dGhlbnRpY2F0aW9uIHNjaGVtZSwgdGhlIHR5cGUgbmFtZSBTSE9VTEQgYmUKICAgICAgICAg IGlkZW50aWNhbCB0byB0aGUgSFRUUCBhdXRoZW50aWNhdGlvbiBzY2hlbWUgbmFtZSAoYXMgZGVm aW5lZCBieSA8YSBjbGFzcz0naW5mbycgaHJlZj0nI1JGQzI2MTcnPltSRkMyNjE3XTxzcGFuPiAo PC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5GcmFua3MsIEouLCBIYWxsYW0tQmFrZXIsIFAuLCBI b3N0ZXRsZXIsIEouLCBMYXdyZW5jZSwgUy4sIExlYWNoLCBQLiwgTHVvdG9uZW4sIEEuLCBhbmQg TC4gU3Rld2FydCwgJmxkcXVvO0hUVFAgQXV0aGVudGljYXRpb246IEJhc2ljIGFuZCBEaWdlc3Qg QWNjZXNzIEF1dGhlbnRpY2F0aW9uLCZyZHF1bzsgSnVuZSZuYnNwOzE5OTkuPC9zcGFuPjxzcGFu Pik8L3NwYW4+PC9hPikuCiAgICAgICAgICBUaGUgdG9rZW4gdHlwZSA8dHQ+ZXhhbXBsZTwvdHQ+ IGlzIHJlc2VydmVkIGZvciB1c2UgaW4gZXhhbXBsZXMuCiAgICAgICAgCjwvcD48ZGl2IHN0eWxl PSdkaXNwbGF5OiB0YWJsZTsgd2lkdGg6IDA7IG1hcmdpbi1sZWZ0OiAzZW07IG1hcmdpbi1yaWdo dDogYXV0byc+PHByZT4KCiAgdHlwZS1uYW1lICA9IDEqbmFtZS1jaGFyCiAgbmFtZS1jaGFyICA9 ICItIiAvICIuIiAvICJfIiAvIERJR0lUIC8gQUxQSEEKCjwvcHJlPjwvZGl2Pgo8YSBuYW1lPSJl bmRwb2ludC1wYXJhbXMiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIg Y2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmln aHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7 PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi44LjIiPjwvYT48aDM+ OC4yLiZuYnNwOwpEZWZpbmluZyBOZXcgRW5kcG9pbnQgUGFyYW1ldGVyczwvaDM+Cgo8cD4KICAg ICAgICAgIE5ldyByZXF1ZXN0IG9yIHJlc3BvbnNlIHBhcmFtZXRlcnMgZm9yIHVzZSB3aXRoIHRo ZSBhdXRob3JpemF0aW9uIGVuZHBvaW50IG9yIHRoZSB0b2tlbgogICAgICAgICAgZW5kcG9pbnQg YXJlIGRlZmluZWQgYW5kIHJlZ2lzdGVyZWQgaW4gdGhlIHBhcmFtZXRlcnMgcmVnaXN0cnkgZm9s bG93aW5nIHRoZSBwcm9jZWR1cmUgaW4KICAgICAgICAgIDxhIGNsYXNzPSdpbmZvJyBocmVmPScj cGFyYW1ldGVycy1yZWdpc3RyeSc+U2VjdGlvbiZuYnNwOzExLjI8c3Bhbj4gKDwvc3Bhbj48c3Bh biBjbGFzcz0naW5mbyc+VGhlIE9BdXRoIFBhcmFtZXRlcnMgUmVnaXN0cnk8L3NwYW4+PHNwYW4+ KTwvc3Bhbj48L2E+LgogICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgUGFyYW1ldGVyIG5hbWVz IE1VU1QgY29uZm9ybSB0byB0aGUgcGFyYW0tbmFtZSBBQk5GIGFuZCBwYXJhbWV0ZXIgdmFsdWVz IHN5bnRheCBNVVNUIGJlCiAgICAgICAgICB3ZWxsLWRlZmluZWQgKGUuZy4sIHVzaW5nIEFCTkYs IG9yIGEgcmVmZXJlbmNlIHRvIHRoZSBzeW50YXggb2YgYW4gZXhpc3RpbmcgcGFyYW1ldGVyKS4K ICAgICAgICAKPC9wPjxkaXYgc3R5bGU9J2Rpc3BsYXk6IHRhYmxlOyB3aWR0aDogMDsgbWFyZ2lu LWxlZnQ6IDNlbTsgbWFyZ2luLXJpZ2h0OiBhdXRvJz48cHJlPgoKICBwYXJhbS1uYW1lICA9IDEq bmFtZS1jaGFyCiAgbmFtZS1jaGFyICAgPSAiLSIgLyAiLiIgLyAiXyIgLyBESUdJVCAvIEFMUEhB Cgo8L3ByZT48L2Rpdj4KPHA+CiAgICAgICAgICBVbnJlZ2lzdGVyZWQgdmVuZG9yLXNwZWNpZmlj IHBhcmFtZXRlciBleHRlbnNpb25zIHRoYXQgYXJlIG5vdCBjb21tb25seSBhcHBsaWNhYmxlLCBh bmQKICAgICAgICAgIGFyZSBzcGVjaWZpYyB0byB0aGUgaW1wbGVtZW50YXRpb24gZGV0YWlscyBv ZiB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgd2hlcmUgdGhleSBhcmUKICAgICAgICAgIHVzZWQg U0hPVUxEIHV0aWxpemUgYSB2ZW5kb3Itc3BlY2lmaWMgcHJlZml4IHRoYXQgaXMgbm90IGxpa2Vs eSB0byBjb25mbGljdCB3aXRoIG90aGVyCiAgICAgICAgICByZWdpc3RlcmVkIHZhbHVlcyAoZS5n LiBiZWdpbiB3aXRoICdjb21wYW55bmFtZV8nKS4KICAgICAgICAKPC9wPgo8YSBuYW1lPSJhbmNo b3IzMSI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGlu Zz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0 ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48 L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLjguMyI+PC9hPjxoMz44LjMuJm5ic3A7 CkRlZmluaW5nIE5ldyBBdXRob3JpemF0aW9uIEdyYW50IFR5cGVzPC9oMz4KCjxwPgogICAgICAg ICAgTmV3IGF1dGhvcml6YXRpb24gZ3JhbnQgdHlwZXMgY2FuIGJlIGRlZmluZWQgYnkgYXNzaWdu aW5nIHRoZW0gYSB1bmlxdWUgYWJzb2x1dGUgVVJJIGZvcgogICAgICAgICAgdXNlIHdpdGggdGhl IDx0dD5ncmFudF90eXBlPC90dD4gcGFyYW1ldGVyLiBJZiB0aGUgZXh0ZW5zaW9uIGdyYW50CiAg ICAgICAgICB0eXBlIHJlcXVpcmVzIGFkZGl0aW9uYWwgdG9rZW4gZW5kcG9pbnQgcGFyYW1ldGVy cywgdGhleSBNVVNUIGJlIHJlZ2lzdGVyZWQgaW4gdGhlIE9BdXRoCiAgICAgICAgICBwYXJhbWV0 ZXJzIHJlZ2lzdHJ5IGFzIGRlc2NyaWJlZCBieSA8YSBjbGFzcz0naW5mbycgaHJlZj0nI3BhcmFt ZXRlcnMtcmVnaXN0cnknPlNlY3Rpb24mbmJzcDsxMS4yPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xh c3M9J2luZm8nPlRoZSBPQXV0aCBQYXJhbWV0ZXJzIFJlZ2lzdHJ5PC9zcGFuPjxzcGFuPik8L3Nw YW4+PC9hPi4KICAgICAgICAKPC9wPgo8YSBuYW1lPSJyZXNwb25zZS10eXBlLWV4dCI+PC9hPjxi ciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNw YWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9D YnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+ CjxhIG5hbWU9InJmYy5zZWN0aW9uLjguNCI+PC9hPjxoMz44LjQuJm5ic3A7CkRlZmluaW5nIE5l dyBBdXRob3JpemF0aW9uIEVuZHBvaW50IFJlc3BvbnNlIFR5cGVzPC9oMz4KCjxwPgogICAgICAg ICAgTmV3IHJlc3BvbnNlIHR5cGVzIGZvciB1c2Ugd2l0aCB0aGUgYXV0aG9yaXphdGlvbiBlbmRw b2ludCBhcmUgZGVmaW5lZCBhbmQgcmVnaXN0ZXJlZCBpbgogICAgICAgICAgdGhlIGF1dGhvcml6 YXRpb24gZW5kcG9pbnQgcmVzcG9uc2UgdHlwZSByZWdpc3RyeSBmb2xsb3dpbmcgdGhlIHByb2Nl ZHVyZSBpbgogICAgICAgICAgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNyZXNwb25zZS10eXBlLXJl Z2lzdHJ5Jz5TZWN0aW9uJm5ic3A7MTEuMzxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZv Jz5UaGUgT0F1dGggQXV0aG9yaXphdGlvbiBFbmRwb2ludCBSZXNwb25zZSBUeXBlIFJlZ2lzdHJ5 PC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPi4gUmVzcG9uc2UgdHlwZSBuYW1lcyBNVVNUIGNvbmZv cm0gdG8gdGhlCiAgICAgICAgICByZXNwb25zZS10eXBlIEFCTkYuCiAgICAgICAgCjwvcD48ZGl2 IHN0eWxlPSdkaXNwbGF5OiB0YWJsZTsgd2lkdGg6IDA7IG1hcmdpbi1sZWZ0OiAzZW07IG1hcmdp bi1yaWdodDogYXV0byc+PHByZT4KCiAgcmVzcG9uc2UtdHlwZSAgPSByZXNwb25zZS1uYW1lICoo IFNQIHJlc3BvbnNlLW5hbWUgKQogIHJlc3BvbnNlLW5hbWUgID0gMSpyZXNwb25zZS1jaGFyCiAg cmVzcG9uc2UtY2hhciAgPSAiXyIgLyBESUdJVCAvIEFMUEhBCgo8L3ByZT48L2Rpdj4KPHA+CiAg ICAgICAgICBJZiBhIHJlc3BvbnNlIHR5cGUgY29udGFpbnMgb25lIG9yIG1vcmUgc3BhY2UgY2hh cmFjdGVycyAoJXgyMCksIGl0IGlzIGNvbXBhcmVkIGFzIGEKICAgICAgICAgIHNwYWNlLWRlbGlt aXRlZCBsaXN0IG9mIHZhbHVlcyBpbiB3aGljaCB0aGUgb3JkZXIgb2YgdmFsdWVzIGRvZXMgbm90 IG1hdHRlci4gT25seSBvbmUKICAgICAgICAgIG9yZGVyIG9mIHZhbHVlcyBjYW4gYmUgcmVnaXN0 ZXJlZCwgd2hpY2ggY292ZXJzIGFsbCBvdGhlciBhcnJhbmdlbWVudHMgb2YgdGhlIHNhbWUgc2V0 IG9mCiAgICAgICAgICB2YWx1ZXMuCiAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICBGb3IgZXhh bXBsZSwgdGhlIHJlc3BvbnNlIHR5cGUgPHR0PnRva2VuIGNvZGU8L3R0PiBpcyBsZWZ0IHVuZGVm aW5lZAogICAgICAgICAgYnkgdGhpcyBzcGVjaWZpY2F0aW9uLiBIb3dldmVyLCBhbiBleHRlbnNp b24gY2FuIGRlZmluZSBhbmQgcmVnaXN0ZXIgdGhlCiAgICAgICAgICA8dHQ+dG9rZW4gY29kZTwv dHQ+IHJlc3BvbnNlIHR5cGUuIE9uY2UgcmVnaXN0ZXJlZCwgdGhlIHNhbWUKICAgICAgICAgIGNv bWJpbmF0aW9uIGNhbm5vdCBiZSByZWdpc3RlcmVkIGFzIDx0dD5jb2RlIHRva2VuPC90dD4sIGJ1 dCBib3RoCiAgICAgICAgICB2YWx1ZXMgY2FuIGJlIHVzZWQgdG8gZGVub3RlIHRoZSBzYW1lIHJl c3BvbnNlIHR5cGUuCiAgICAgICAgCjwvcD4KPGEgbmFtZT0ibmV3LWVycm9ycyI+PC9hPjxiciAv PjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNp bmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVn Ij48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+Cjxh IG5hbWU9InJmYy5zZWN0aW9uLjguNSI+PC9hPjxoMz44LjUuJm5ic3A7CkRlZmluaW5nIEFkZGl0 aW9uYWwgRXJyb3IgQ29kZXM8L2gzPgoKPHA+CiAgICAgICAgICBJbiBjYXNlcyB3aGVyZSBwcm90 b2NvbCBleHRlbnNpb25zIChpLmUuIGFjY2VzcyB0b2tlbiB0eXBlcywgZXh0ZW5zaW9uIHBhcmFt ZXRlcnMsIG9yCiAgICAgICAgICBleHRlbnNpb24gZ3JhbnQgdHlwZXMpIHJlcXVpcmUgYWRkaXRp b25hbCBlcnJvciBjb2RlcyB0byBiZSB1c2VkIHdpdGggdGhlIGF1dGhvcml6YXRpb24KICAgICAg ICAgIGNvZGUgZ3JhbnQgZXJyb3IgcmVzcG9uc2UgKDxhIGNsYXNzPSdpbmZvJyBocmVmPScjY29k ZS1hdXRoei1lcnJvcic+U2VjdGlvbiZuYnNwOzQuMS4yLjE8c3Bhbj4gKDwvc3Bhbj48c3BhbiBj bGFzcz0naW5mbyc+RXJyb3IgUmVzcG9uc2U8L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+KSwgdGhl IGltcGxpY2l0IGdyYW50IGVycm9yCiAgICAgICAgICByZXNwb25zZSAoPGEgY2xhc3M9J2luZm8n IGhyZWY9JyNpbXBsaWNpdC1hdXRoei1lcnJvcic+U2VjdGlvbiZuYnNwOzQuMi4yLjE8c3Bhbj4g KDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+RXJyb3IgUmVzcG9uc2U8L3NwYW4+PHNwYW4+KTwv c3Bhbj48L2E+KSwgdGhlIHRva2VuIGVycm9yIHJlc3BvbnNlCiAgICAgICAgICAoPGEgY2xhc3M9 J2luZm8nIGhyZWY9JyN0b2tlbi1lcnJvcnMnPlNlY3Rpb24mbmJzcDs1LjI8c3Bhbj4gKDwvc3Bh bj48c3BhbiBjbGFzcz0naW5mbyc+RXJyb3IgUmVzcG9uc2U8L3NwYW4+PHNwYW4+KTwvc3Bhbj48 L2E+KSwKCSAgb3IgdGhlIHJlc291cmNlIGFjY2VzcyBlcnJvciByZXNwb25zZSAoPGEgY2xhc3M9 J2luZm8nIGhyZWY9JyNyZXNvdXJjZS1lcnJvcnMnPlNlY3Rpb24mbmJzcDs3LjI8c3Bhbj4gKDwv c3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+RXJyb3IgUmVzcG9uc2U8L3NwYW4+PHNwYW4+KTwvc3Bh bj48L2E+KSwKCSAgc3VjaCBlcnJvciBjb2RlcyBNQVkgYmUgZGVmaW5lZC4KICAgICAgICAKPC9w Pgo8cD4KICAgICAgICAgIEV4dGVuc2lvbiBlcnJvciBjb2RlcyBNVVNUIGJlIHJlZ2lzdGVyZWQg KGZvbGxvd2luZyB0aGUgcHJvY2VkdXJlcyBpbgogICAgICAgICAgPGEgY2xhc3M9J2luZm8nIGhy ZWY9JyNlcnJvci1yZWdpc3RyeSc+U2VjdGlvbiZuYnNwOzExLjQ8c3Bhbj4gKDwvc3Bhbj48c3Bh biBjbGFzcz0naW5mbyc+VGhlIE9BdXRoIEV4dGVuc2lvbnMgRXJyb3IgUmVnaXN0cnk8L3NwYW4+ PHNwYW4+KTwvc3Bhbj48L2E+KSBpZiB0aGUgZXh0ZW5zaW9uIHRoZXkgYXJlIHVzZWQgaW4gY29u anVuY3Rpb24gd2l0aCBpcwogICAgICAgICAgYSByZWdpc3RlcmVkIGFjY2VzcyB0b2tlbiB0eXBl LCBhIHJlZ2lzdGVyZWQgZW5kcG9pbnQgcGFyYW1ldGVyLCBvciBhbiBleHRlbnNpb24gZ3JhbnQK ICAgICAgICAgIHR5cGUuIEVycm9yIGNvZGVzIHVzZWQgd2l0aCB1bnJlZ2lzdGVyZWQgZXh0ZW5z aW9ucyBNQVkgYmUgcmVnaXN0ZXJlZC4KICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgIEVycm9y IGNvZGVzIE1VU1QgY29uZm9ybSB0byB0aGUgZXJyb3IgQUJORiwgYW5kIFNIT1VMRCBiZSBwcmVm aXhlZCBieSBhbiBpZGVudGlmeWluZwogICAgICAgICAgbmFtZSB3aGVuIHBvc3NpYmxlLiBGb3Ig ZXhhbXBsZSwgYW4gZXJyb3IgaWRlbnRpZnlpbmcgYW4gaW52YWxpZCB2YWx1ZSBzZXQgdG8gdGhl CiAgICAgICAgICBleHRlbnNpb24gcGFyYW1ldGVyIDx0dD5leGFtcGxlPC90dD4gU0hPVUxEIGJl IG5hbWVkCiAgICAgICAgICA8dHQ+ZXhhbXBsZV9pbnZhbGlkPC90dD4uCiAgICAgICAgCjwvcD48 ZGl2IHN0eWxlPSdkaXNwbGF5OiB0YWJsZTsgd2lkdGg6IDA7IG1hcmdpbi1sZWZ0OiAzZW07IG1h cmdpbi1yaWdodDogYXV0byc+PHByZT4KCiAgZXJyb3IgICAgICA9IDEqZXJyb3ItY2hhcgogIGVy cm9yLWNoYXIgPSAleDIwLTIxIC8gJXgyMy01QiAvICV4NUQtN0UKCjwvcHJlPjwvZGl2Pgo8YSBu YW1lPSJhbmNob3IzMiI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBj ZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdo dCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8 L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLjkiPjwvYT48aDM+OS4m bmJzcDsKTmF0aXZlIEFwcGxpY2F0aW9uczwvaDM+Cgo8cD4KICAgICAgICBOYXRpdmUgYXBwbGlj YXRpb25zIGFyZSBjbGllbnRzIGluc3RhbGxlZCBhbmQgZXhlY3V0ZWQgb24gdGhlIGRldmljZSB1 c2VkIGJ5IHRoZSByZXNvdXJjZQogICAgICAgIG93bmVyIChpLmUuIGRlc2t0b3AgYXBwbGljYXRp b24sIG5hdGl2ZSBtb2JpbGUgYXBwbGljYXRpb24pLiBOYXRpdmUgYXBwbGljYXRpb25zIHJlcXVp cmUKICAgICAgICBzcGVjaWFsIGNvbnNpZGVyYXRpb24gcmVsYXRlZCB0byBzZWN1cml0eSwgcGxh dGZvcm0gY2FwYWJpbGl0aWVzLCBhbmQgb3ZlcmFsbCBlbmQtdXNlcgogICAgICAgIGV4cGVyaWVu Y2UuCiAgICAgIAo8L3A+CjxwPgogICAgICAgIFRoZSBhdXRob3JpemF0aW9uIGVuZHBvaW50IHJl cXVpcmVzIGludGVyYWN0aW9uIGJldHdlZW4gdGhlIGNsaWVudCBhbmQgdGhlIHJlc291cmNlCiAg ICAgICAgb3duZXIncyB1c2VyLWFnZW50LiBOYXRpdmUgYXBwbGljYXRpb25zIGNhbiBpbnZva2Ug YW4gZXh0ZXJuYWwgdXNlci1hZ2VudCBvciBlbWJlZCBhCiAgICAgICAgdXNlci1hZ2VudCB3aXRo aW4gdGhlIGFwcGxpY2F0aW9uLiBGb3IgZXhhbXBsZToKICAgICAgCjwvcD4KPHA+CiAgICAgICAg PC9wPgo8dWwgY2xhc3M9InRleHQiPgo8bGk+CiAgICAgICAgICAgIEV4dGVybmFsIHVzZXItYWdl bnQgLSB0aGUgbmF0aXZlIGFwcGxpY2F0aW9uIGNhbiBjYXB0dXJlIHRoZSByZXNwb25zZSBmcm9t IHRoZQogICAgICAgICAgICBhdXRob3JpemF0aW9uIHNlcnZlciB1c2luZyBhIHJlZGlyZWN0aW9u IFVSSSB3aXRoIGEgc2NoZW1lIHJlZ2lzdGVyZWQgd2l0aCB0aGUKICAgICAgICAgICAgb3BlcmF0 aW5nIHN5c3RlbSB0byBpbnZva2UgdGhlIGNsaWVudCBhcyB0aGUgaGFuZGxlciwgbWFudWFsIGNv cHktYW5kLXBhc3RlIG9mIHRoZQogICAgICAgICAgICBjcmVkZW50aWFscywgcnVubmluZyBhIGxv Y2FsIHdlYiBzZXJ2ZXIsIGluc3RhbGxpbmcgYSB1c2VyLWFnZW50IGV4dGVuc2lvbiwgb3IgYnkK ICAgICAgICAgICAgcHJvdmlkaW5nIGEgcmVkaXJlY3Rpb24gVVJJIGlkZW50aWZ5aW5nIGEgc2Vy dmVyLWhvc3RlZCByZXNvdXJjZSB1bmRlciB0aGUgY2xpZW50J3MKICAgICAgICAgICAgY29udHJv bCwgd2hpY2ggaW4gdHVybiBtYWtlcyB0aGUgcmVzcG9uc2UgYXZhaWxhYmxlIHRvIHRoZSBuYXRp dmUgYXBwbGljYXRpb24uCiAgICAgICAgICAKPC9saT4KPGxpPgogICAgICAgICAgICBFbWJlZGRl ZCB1c2VyLWFnZW50IC0gdGhlIG5hdGl2ZSBhcHBsaWNhdGlvbiBvYnRhaW5zIHRoZSByZXNwb25z ZSBieSBkaXJlY3RseQogICAgICAgICAgICBjb21tdW5pY2F0aW5nIHdpdGggdGhlIGVtYmVkZGVk IHVzZXItYWdlbnQgYnkgbW9uaXRvcmluZyBzdGF0ZSBjaGFuZ2VzIGVtaXR0ZWQgZHVyaW5nCiAg ICAgICAgICAgIHRoZSByZXNvdXJjZSBsb2FkLCBvciBhY2Nlc3NpbmcgdGhlIHVzZXItYWdlbnQn cyBjb29raWVzIHN0b3JhZ2UuCiAgICAgICAgICAKPC9saT4KPC91bD48cD4KICAgICAgCjwvcD4K PHA+CiAgICAgICAgV2hlbiBjaG9vc2luZyBiZXR3ZWVuIGFuIGV4dGVybmFsIG9yIGVtYmVkZGVk IHVzZXItYWdlbnQsIGRldmVsb3BlcnMgc2hvdWxkIGNvbnNpZGVyOgogICAgICAKPC9wPgo8cD4K ICAgICAgICA8L3A+Cjx1bCBjbGFzcz0idGV4dCI+CjxsaT4KICAgICAgICAgICAgQW4gRXh0ZXJu YWwgdXNlci1hZ2VudCBtYXkgaW1wcm92ZSBjb21wbGV0aW9uIHJhdGUgYXMgdGhlIHJlc291cmNl IG93bmVyIG1heSBhbHJlYWR5IGhhdmUKICAgICAgICAgICAgYW4gYWN0aXZlIHNlc3Npb24gd2l0 aCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgcmVtb3ZpbmcgdGhlIG5lZWQgdG8gcmUtYXV0aGVu dGljYXRlLiBJdAogICAgICAgICAgICBwcm92aWRlcyBhIGZhbWlsaWFyIGVuZC11c2VyIGV4cGVy aWVuY2UgYW5kIGZ1bmN0aW9uYWxpdHkuIFRoZSByZXNvdXJjZSBvd25lciBtYXkgYWxzbwogICAg ICAgICAgICByZWx5IG9uIHVzZXItYWdlbnQgZmVhdHVyZXMgb3IgZXh0ZW5zaW9ucyB0byBhc3Np c3Qgd2l0aCBhdXRoZW50aWNhdGlvbiAoZS5nLiBwYXNzd29yZAogICAgICAgICAgICBtYW5hZ2Vy LCAyLWZhY3RvciBkZXZpY2UgcmVhZGVyKS4KICAgICAgICAgIAo8L2xpPgo8bGk+CiAgICAgICAg ICAgIEFuIGVtYmVkZGVkIHVzZXItYWdlbnQgbWF5IG9mZmVyIGltcHJvdmVkIHVzYWJpbGl0eSwg YXMgaXQgcmVtb3ZlcyB0aGUgbmVlZCB0byBzd2l0Y2gKICAgICAgICAgICAgY29udGV4dCBhbmQg b3BlbiBuZXcgd2luZG93cy4KICAgICAgICAgIAo8L2xpPgo8bGk+CiAgICAgICAgICAgIEFuIGVt YmVkZGVkIHVzZXItYWdlbnQgcG9zZXMgYSBzZWN1cml0eSBjaGFsbGVuZ2UgYmVjYXVzZSByZXNv dXJjZSBvd25lcnMgYXJlCiAgICAgICAgICAgIGF1dGhlbnRpY2F0aW5nIGluIGFuIHVuaWRlbnRp ZmllZCB3aW5kb3cgd2l0aG91dCBhY2Nlc3MgdG8gdGhlIHZpc3VhbCBwcm90ZWN0aW9ucyBmb3Vu ZAogICAgICAgICAgICBpbiBtb3N0IGV4dGVybmFsIHVzZXItYWdlbnRzLiBBbiBlbWJlZGRlZCB1 c2VyLWFnZW50IGVkdWNhdGVzIGVuZC11c2VycyB0byB0cnVzdAogICAgICAgICAgICB1bmlkZW50 aWZpZWQgcmVxdWVzdHMgZm9yIGF1dGhlbnRpY2F0aW9uIChtYWtpbmcgcGhpc2hpbmcgYXR0YWNr cyBlYXNpZXIgdG8gZXhlY3V0ZSkuCiAgICAgICAgICAKPC9saT4KPC91bD48cD4KICAgICAgCjwv cD4KPHA+CiAgICAgICAgV2hlbiBjaG9vc2luZyBiZXR3ZWVuIHRoZSBpbXBsaWNpdCBncmFudCB0 eXBlIGFuZCB0aGUgYXV0aG9yaXphdGlvbiBjb2RlIGdyYW50IHR5cGUsIHRoZQogICAgICAgIGZv bGxvd2luZyBzaG91bGQgYmUgY29uc2lkZXJlZDoKICAgICAgCjwvcD4KPHA+CiAgICAgICAgPC9w Pgo8dWwgY2xhc3M9InRleHQiPgo8bGk+CiAgICAgICAgICAgIE5hdGl2ZSBhcHBsaWNhdGlvbnMg dGhhdCB1c2UgdGhlIGF1dGhvcml6YXRpb24gY29kZSBncmFudCB0eXBlIFNIT1VMRCBkbyBzbyB3 aXRob3V0CiAgICAgICAgICAgIHVzaW5nIGNsaWVudCBjcmVkZW50aWFscywgZHVlIHRvIHRoZSBu YXRpdmUgYXBwbGljYXRpb24ncyBpbmFiaWxpdHkgdG8ga2VlcCBjbGllbnQKICAgICAgICAgICAg Y3JlZGVudGlhbHMgY29uZmlkZW50aWFsLgogICAgICAgICAgCjwvbGk+CjxsaT4KICAgICAgICAg ICAgV2hlbiB1c2luZyB0aGUgaW1wbGljaXQgZ3JhbnQgdHlwZSBmbG93IGEgcmVmcmVzaCB0b2tl biBpcyBub3QgcmV0dXJuZWQgd2hpY2ggcmVxdWlyZXMKICAgICAgICAgICAgcmVwZWF0aW5nIHRo ZSBhdXRob3JpemF0aW9uIHByb2Nlc3Mgb25jZSB0aGUgYWNjZXNzIHRva2VuIGV4cGlyZXMuCiAg ICAgICAgICAKPC9saT4KPC91bD48cD4KICAgICAgCjwvcD4KPGEgbmFtZT0iYW5jaG9yMzMiPjwv YT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNl bGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9 IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3Rh YmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi4xMCI+PC9hPjxoMz4xMC4mbmJzcDsKU2VjdXJpdHkg Q29uc2lkZXJhdGlvbnM8L2gzPgoKPHA+CiAgICAgICAgQXMgYSBmbGV4aWJsZSBhbmQgZXh0ZW5z aWJsZSBmcmFtZXdvcmssIE9BdXRoJ3Mgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgZGVwZW5kIG9u IG1hbnkKICAgICAgICBmYWN0b3JzLiBUaGUgZm9sbG93aW5nIHNlY3Rpb25zIHByb3ZpZGUgaW1w bGVtZW50ZXJzIHdpdGggc2VjdXJpdHkgZ3VpZGVsaW5lcyBmb2N1c2VkIG9uCiAgICAgICAgdGhl IHRocmVlIGNsaWVudCBwcm9maWxlcyBkZXNjcmliZWQgaW4gPGEgY2xhc3M9J2luZm8nIGhyZWY9 JyNjbGllbnQtdHlwZXMnPlNlY3Rpb24mbmJzcDsyLjE8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFz cz0naW5mbyc+Q2xpZW50IFR5cGVzPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPjogd2ViIGFwcGxp Y2F0aW9uLAogICAgICAgIHVzZXItYWdlbnQtYmFzZWQgYXBwbGljYXRpb24sIGFuZCBuYXRpdmUg YXBwbGljYXRpb24uCiAgICAgIAo8L3A+CjxwPgogICAgICAgIEEgY29tcHJlaGVuc2l2ZSBPQXV0 aCBzZWN1cml0eSBtb2RlbCBhbmQgYW5hbHlzaXMsIGFzIHdlbGwgYXMgYmFja2dyb3VuZCBmb3Ig dGhlIHByb3RvY29sCiAgICAgICAgZGVzaWduIGlzIHByb3ZpZGVkIGJ5IDxhIGNsYXNzPSdpbmZv JyBocmVmPScjSS1ELmlldGYtb2F1dGgtdjItdGhyZWF0bW9kZWwnPltJJiM4MjA5O0QuaWV0ZiYj ODIwOTtvYXV0aCYjODIwOTt2MiYjODIwOTt0aHJlYXRtb2RlbF08c3Bhbj4gKDwvc3Bhbj48c3Bh biBjbGFzcz0naW5mbyc+TWNHbG9pbiwgTS4sIEh1bnQsIFAuLCBhbmQgVC4gTG9kZGVyc3RlZHQs ICZsZHF1bztPQXV0aCAyLjAgVGhyZWF0IE1vZGVsIGFuZCBTZWN1cml0eSBDb25zaWRlcmF0aW9u cywmcmRxdW87IEZlYnJ1YXJ5Jm5ic3A7MjAxMi48L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+Lgog ICAgICAKPC9wPgo8YSBuYW1lPSJhbmNob3IzNCI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3Vt bWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0Ni dWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4m bmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9u LjEwLjEiPjwvYT48aDM+MTAuMS4mbmJzcDsKQ2xpZW50IEF1dGhlbnRpY2F0aW9uPC9oMz4KCjxw PgogICAgICAgICAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGVzdGFibGlzaGVzIGNsaWVudCBj cmVkZW50aWFscyB3aXRoIHdlYiBhcHBsaWNhdGlvbiBjbGllbnRzIGZvcgogICAgICAgICAgdGhl IHB1cnBvc2Ugb2YgY2xpZW50IGF1dGhlbnRpY2F0aW9uLiBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2 ZXIgaXMgZW5jb3VyYWdlZCB0byBjb25zaWRlcgogICAgICAgICAgc3Ryb25nZXIgY2xpZW50IGF1 dGhlbnRpY2F0aW9uIG1lYW5zIHRoYW4gYSBjbGllbnQgcGFzc3dvcmQuIFdlYiBhcHBsaWNhdGlv biBjbGllbnRzIE1VU1QKICAgICAgICAgIGVuc3VyZSBjb25maWRlbnRpYWxpdHkgb2YgY2xpZW50 IHBhc3N3b3JkcyBhbmQgb3RoZXIgY2xpZW50IGNyZWRlbnRpYWxzLgogICAgICAgIAo8L3A+Cjxw PgogICAgICAgICAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIE1VU1QgTk9UIGlzc3VlIGNsaWVu dCBwYXNzd29yZHMgb3Igb3RoZXIgY2xpZW50IGNyZWRlbnRpYWxzIHRvCiAgICAgICAgICBuYXRp dmUgYXBwbGljYXRpb24gb3IgdXNlci1hZ2VudC1iYXNlZCBhcHBsaWNhdGlvbiBjbGllbnRzIGZv ciB0aGUgcHVycG9zZSBvZiBjbGllbnQKICAgICAgICAgIGF1dGhlbnRpY2F0aW9uLiBUaGUgYXV0 aG9yaXphdGlvbiBzZXJ2ZXIgTUFZIGlzc3VlIGEgY2xpZW50IHBhc3N3b3JkIG9yIG90aGVyIGNy ZWRlbnRpYWxzCiAgICAgICAgICBmb3IgYSBzcGVjaWZpYyBpbnN0YWxsYXRpb24gb2YgYSBuYXRp dmUgYXBwbGljYXRpb24gY2xpZW50IG9uIGEgc3BlY2lmaWMgZGV2aWNlLgogICAgICAgIAo8L3A+ CjxwPgogICAgICAgICAgV2hlbiBjbGllbnQgYXV0aGVudGljYXRpb24gaXMgbm90IHBvc3NpYmxl LCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgU0hPVUxEIGVtcGxveSBvdGhlcgogICAgICAgICAg bWVhbnMgdG8gdmFsaWRhdGUgdGhlIGNsaWVudCdzIGlkZW50aXR5LiBGb3IgZXhhbXBsZSwgYnkg cmVxdWlyaW5nIHRoZSByZWdpc3RyYXRpb24gb2YKICAgICAgICAgIHRoZSBjbGllbnQgcmVkaXJl Y3Rpb24gVVJJIG9yIGVubGlzdGluZyB0aGUgcmVzb3VyY2Ugb3duZXIgdG8gY29uZmlybSBpZGVu dGl0eS4gQSB2YWxpZAogICAgICAgICAgcmVkaXJlY3Rpb24gVVJJIGlzIG5vdCBzdWZmaWNpZW50 IHRvIHZlcmlmeSB0aGUgY2xpZW50J3MgaWRlbnRpdHkgd2hlbiBhc2tpbmcgZm9yCiAgICAgICAg ICByZXNvdXJjZSBvd25lciBhdXRob3JpemF0aW9uLCBidXQgY2FuIGJlIHVzZWQgdG8gcHJldmVu dCBkZWxpdmVyaW5nIGNyZWRlbnRpYWxzIHRvIGEKICAgICAgICAgIGNvdW50ZXJmZWl0IGNsaWVu dCBhZnRlciBvYnRhaW5pbmcgcmVzb3VyY2Ugb3duZXIgYXV0aG9yaXphdGlvbi4KICAgICAgICAK PC9wPgo8cD4KICAgICAgICAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBtdXN0IGNvbnNpZGVy IHRoZSBzZWN1cml0eSBpbXBsaWNhdGlvbnMgb2YgaW50ZXJhY3Rpbmcgd2l0aAogICAgICAgICAg dW5hdXRoZW50aWNhdGVkIGNsaWVudHMgYW5kIHRha2UgbWVhc3VyZXMgdG8gbGltaXQgdGhlIHBv dGVudGlhbCBleHBvc3VyZSBvZiBvdGhlcgogICAgICAgICAgY3JlZGVudGlhbHMgKGUuZy4gcmVm cmVzaCB0b2tlbnMpIGlzc3VlZCB0byBzdWNoIGNsaWVudHMuCiAgICAgICAgCjwvcD4KPGEgbmFt ZT0iYW5jaG9yMzUiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2Vs bHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQi Pjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9h PjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi4xMC4yIj48L2E+PGgzPjEw LjIuJm5ic3A7CkNsaWVudCBJbXBlcnNvbmF0aW9uPC9oMz4KCjxwPgogICAgICAgICAgQSBtYWxp Y2lvdXMgY2xpZW50IGNhbiBpbXBlcnNvbmF0ZSBhbm90aGVyIGNsaWVudCBhbmQgb2J0YWluIGFj Y2VzcyB0byBwcm90ZWN0ZWQKICAgICAgICAgIHJlc291cmNlcywgaWYgdGhlIGltcGVyc29uYXRl ZCBjbGllbnQgZmFpbHMgdG8sIG9yIGlzIHVuYWJsZSB0bywga2VlcCBpdHMgY2xpZW50CiAgICAg ICAgICBjcmVkZW50aWFscyBjb25maWRlbnRpYWwuCiAgICAgICAgCjwvcD4KPHA+CiAgICAgICAg ICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVTVCBhdXRoZW50aWNhdGUgdGhlIGNsaWVudCB3 aGVuZXZlciBwb3NzaWJsZS4gSWYgdGhlCiAgICAgICAgICBhdXRob3JpemF0aW9uIHNlcnZlciBj YW5ub3QgYXV0aGVudGljYXRlIHRoZSBjbGllbnQgZHVlIHRvIHRoZSBjbGllbnQncyBuYXR1cmUs IHRoZQogICAgICAgICAgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVTVCByZXF1aXJlIHRoZSByZWdp c3RyYXRpb24gb2YgYW55IHJlZGlyZWN0aW9uIFVSSSB1c2VkIGZvcgogICAgICAgICAgcmVjZWl2 aW5nIGF1dGhvcml6YXRpb24gcmVzcG9uc2VzLCBhbmQgU0hPVUxEIHV0aWxpemUgb3RoZXIgbWVh bnMgdG8gcHJvdGVjdCByZXNvdXJjZQogICAgICAgICAgb3duZXJzIGZyb20gc3VjaCBwb3RlbnRp YWxseSBtYWxpY2lvdXMgY2xpZW50cy4gRm9yIGV4YW1wbGUsIHRoZSBhdXRob3JpemF0aW9uIHNl cnZlcgogICAgICAgICAgY2FuIGVuZ2FnZSB0aGUgcmVzb3VyY2Ugb3duZXIgdG8gYXNzaXN0IGlu IGlkZW50aWZ5aW5nIHRoZSBjbGllbnQgYW5kIGl0cyBvcmlnaW4uCiAgICAgICAgCjwvcD4KPHA+ CiAgICAgICAgICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgU0hPVUxEIGVuZm9yY2UgZXhwbGlj aXQgcmVzb3VyY2Ugb3duZXIgYXV0aGVudGljYXRpb24gYW5kCiAgICAgICAgICBwcm92aWRlIHRo ZSByZXNvdXJjZSBvd25lciB3aXRoIGluZm9ybWF0aW9uIGFib3V0IHRoZSBjbGllbnQgYW5kIHRo ZSByZXF1ZXN0ZWQKICAgICAgICAgIGF1dGhvcml6YXRpb24gc2NvcGUgYW5kIGxpZmV0aW1lLiBJ dCBpcyB1cCB0byB0aGUgcmVzb3VyY2Ugb3duZXIgdG8gcmV2aWV3IHRoZQogICAgICAgICAgaW5m b3JtYXRpb24gaW4gdGhlIGNvbnRleHQgb2YgdGhlIGN1cnJlbnQgY2xpZW50LCBhbmQgYXV0aG9y aXplIG9yIGRlbnkgdGhlIHJlcXVlc3QuCiAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICBUaGUg YXV0aG9yaXphdGlvbiBzZXJ2ZXIgU0hPVUxEIE5PVCBwcm9jZXNzIHJlcGVhdGVkIGF1dGhvcml6 YXRpb24gcmVxdWVzdHMKICAgICAgICAgIGF1dG9tYXRpY2FsbHkgKHdpdGhvdXQgYWN0aXZlIHJl c291cmNlIG93bmVyIGludGVyYWN0aW9uKSB3aXRob3V0IGF1dGhlbnRpY2F0aW5nIHRoZQogICAg ICAgICAgY2xpZW50IG9yIHJlbHlpbmcgb24gb3RoZXIgbWVhc3VyZXMgdG8gZW5zdXJlIHRoZSBy ZXBlYXRlZCByZXF1ZXN0IGNvbWVzIGZyb20gdGhlCiAgICAgICAgICBvcmlnaW5hbCBjbGllbnQg YW5kIG5vdCBhbiBpbXBlcnNvbmF0b3IuCiAgICAgICAgCjwvcD4KPGEgbmFtZT0iYW5jaG9yMzYi PjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAi IGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xh c3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48 L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi4xMC4zIj48L2E+PGgzPjEwLjMuJm5ic3A7CkFj Y2VzcyBUb2tlbnM8L2gzPgoKPHA+CiAgICAgICAgICBBY2Nlc3MgdG9rZW4gY3JlZGVudGlhbHMg KGFzIHdlbGwgYXMgYW55IGNvbmZpZGVudGlhbCBhY2Nlc3MgdG9rZW4gYXR0cmlidXRlcykgTVVT VCBiZQogICAgICAgICAga2VwdCBjb25maWRlbnRpYWwgaW4gdHJhbnNpdCBhbmQgc3RvcmFnZSwg YW5kIG9ubHkgc2hhcmVkIGFtb25nIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciwKICAgICAgICAg IHRoZSByZXNvdXJjZSBzZXJ2ZXJzIHRoZSBhY2Nlc3MgdG9rZW4gaXMgdmFsaWQgZm9yLCBhbmQg dGhlIGNsaWVudCB0byB3aG9tIHRoZSBhY2Nlc3MKICAgICAgICAgIHRva2VuIGlzIGlzc3VlZC4g QWNjZXNzIHRva2VuIGNyZWRlbnRpYWxzIE1VU1Qgb25seSBiZSB0cmFuc21pdHRlZCB1c2luZyBU TFMgYXMgZGVzY3JpYmVkCiAgICAgICAgICBpbiA8YSBjbGFzcz0naW5mbycgaHJlZj0nI3Rscyc+ U2VjdGlvbiZuYnNwOzEuNjxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5UTFMgVmVy c2lvbjwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4gd2l0aCBzZXJ2ZXIgYXV0aGVudGljYXRpb24g YXMgZGVmaW5lZCBieQogICAgICAgICAgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNSRkMyODE4Jz5b UkZDMjgxOF08c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+UmVzY29ybGEsIEUuLCAm bGRxdW87SFRUUCBPdmVyIFRMUywmcmRxdW87IE1heSZuYnNwOzIwMDAuPC9zcGFuPjxzcGFuPik8 L3NwYW4+PC9hPi4KICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgIFdoZW4gdXNpbmcgdGhlIGlt cGxpY2l0IGdyYW50IHR5cGUsIHRoZSBhY2Nlc3MgdG9rZW4gaXMgdHJhbnNtaXR0ZWQgaW4gdGhl IFVSSSBmcmFnbWVudCwKICAgICAgICAgIHdoaWNoIGNhbiBleHBvc2UgaXQgdG8gdW5hdXRob3Jp emVkIHBhcnRpZXMuCiAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICBUaGUgYXV0aG9yaXphdGlv biBzZXJ2ZXIgTVVTVCBlbnN1cmUgdGhhdCBhY2Nlc3MgdG9rZW5zIGNhbm5vdCBiZSBnZW5lcmF0 ZWQsIG1vZGlmaWVkLCBvcgogICAgICAgICAgZ3Vlc3NlZCB0byBwcm9kdWNlIHZhbGlkIGFjY2Vz cyB0b2tlbnMgYnkgdW5hdXRob3JpemVkIHBhcnRpZXMuCiAgICAgICAgCjwvcD4KPHA+CiAgICAg ICAgICBUaGUgY2xpZW50IFNIT1VMRCByZXF1ZXN0IGFjY2VzcyB0b2tlbnMgd2l0aCB0aGUgbWlu aW1hbCBzY29wZSBuZWNlc3NhcnkuIFRoZQogICAgICAgICAgYXV0aG9yaXphdGlvbiBzZXJ2ZXIg U0hPVUxEIHRha2UgdGhlIGNsaWVudCBpZGVudGl0eSBpbnRvIGFjY291bnQgd2hlbiBjaG9vc2lu ZyBob3cKICAgICAgICAgIHRvIGhvbm9yIHRoZSByZXF1ZXN0ZWQgc2NvcGUsIGFuZCBNQVkgaXNz dWUgYW4gYWNjZXNzIHRva2VuIHdpdGggYSBsZXNzIHJpZ2h0cyB0aGFuCiAgICAgICAgICByZXF1 ZXN0ZWQuCiAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICBUaGlzIHNwZWNpZmljYXRpb24gZG9l cyBub3QgcHJvdmlkZSBhbnkgbWV0aG9kcyBmb3IgdGhlIHJlc291cmNlIHNlcnZlciB0byBlbnN1 cmUgdGhhdCBhbgogICAgICAgICAgYWNjZXNzIHRva2VuIHByZXNlbnRlZCB0byBpdCBieSBhIGdp dmVuIGNsaWVudCB3YXMgaXNzdWVkIHRvIHRoYXQgY2xpZW50IGJ5IHRoZQogICAgICAgICAgYXV0 aG9yaXphdGlvbiBzZXJ2ZXIuCiAgICAgICAgCjwvcD4KPGEgbmFtZT0iYW5jaG9yMzciPjwvYT48 YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxz cGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRP Q2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxl Pgo8YSBuYW1lPSJyZmMuc2VjdGlvbi4xMC40Ij48L2E+PGgzPjEwLjQuJm5ic3A7ClJlZnJlc2gg VG9rZW5zPC9oMz4KCjxwPgogICAgICAgICAgQXV0aG9yaXphdGlvbiBzZXJ2ZXJzIE1BWSBpc3N1 ZSByZWZyZXNoIHRva2VucyB0byB3ZWIgYXBwbGljYXRpb24gY2xpZW50cyBhbmQgbmF0aXZlCiAg ICAgICAgICBhcHBsaWNhdGlvbiBjbGllbnRzLgogICAgICAgIAo8L3A+CjxwPgogICAgICAgICAg UmVmcmVzaCB0b2tlbnMgTVVTVCBiZSBrZXB0IGNvbmZpZGVudGlhbCBpbiB0cmFuc2l0IGFuZCBz dG9yYWdlLCBhbmQgc2hhcmVkIG9ubHkgYW1vbmcKICAgICAgICAgIHRoZSBhdXRob3JpemF0aW9u IHNlcnZlciBhbmQgdGhlIGNsaWVudCB0byB3aG9tIHRoZSByZWZyZXNoIHRva2VucyB3ZXJlIGlz c3VlZC4gVGhlCiAgICAgICAgICBhdXRob3JpemF0aW9uIHNlcnZlciBNVVNUIG1haW50YWluIHRo ZSBiaW5kaW5nIGJldHdlZW4gYSByZWZyZXNoIHRva2VuIGFuZCB0aGUgY2xpZW50IHRvCiAgICAg ICAgICB3aG9tIGl0IHdhcyBpc3N1ZWQuIFJlZnJlc2ggdG9rZW5zIE1VU1Qgb25seSBiZSB0cmFu c21pdHRlZCB1c2luZyBUTFMgYXMgZGVzY3JpYmVkIGluCiAgICAgICAgICA8YSBjbGFzcz0naW5m bycgaHJlZj0nI3Rscyc+U2VjdGlvbiZuYnNwOzEuNjxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNz PSdpbmZvJz5UTFMgVmVyc2lvbjwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4gd2l0aCBzZXJ2ZXIg YXV0aGVudGljYXRpb24gYXMgZGVmaW5lZCBieSA8YSBjbGFzcz0naW5mbycgaHJlZj0nI1JGQzI4 MTgnPltSRkMyODE4XTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5SZXNjb3JsYSwg RS4sICZsZHF1bztIVFRQIE92ZXIgVExTLCZyZHF1bzsgTWF5Jm5ic3A7MjAwMC48L3NwYW4+PHNw YW4+KTwvc3Bhbj48L2E+LgogICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgVGhlIGF1dGhvcml6 YXRpb24gc2VydmVyIE1VU1QgdmVyaWZ5IHRoZSBiaW5kaW5nIGJldHdlZW4gdGhlIHJlZnJlc2gg dG9rZW4gYW5kIGNsaWVudAogICAgICAgICAgaWRlbnRpdHkgd2hlbmV2ZXIgdGhlIGNsaWVudCBp ZGVudGl0eSBjYW4gYmUgYXV0aGVudGljYXRlZC4gV2hlbiBjbGllbnQgYXV0aGVudGljYXRpb24g aXMKICAgICAgICAgIG5vdCBwb3NzaWJsZSwgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIFNIT1VM RCBkZXBsb3kgb3RoZXIgbWVhbnMgdG8gZGV0ZWN0IHJlZnJlc2ggdG9rZW4KICAgICAgICAgIGFi dXNlLgogICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgRm9yIGV4YW1wbGUsIHRoZSBhdXRob3Jp emF0aW9uIHNlcnZlciBjb3VsZCBlbXBsb3kgcmVmcmVzaCB0b2tlbiByb3RhdGlvbiBpbiB3aGlj aCBhIG5ldwogICAgICAgICAgcmVmcmVzaCB0b2tlbiBpcyBpc3N1ZWQgd2l0aCBldmVyeSBhY2Nl c3MgdG9rZW4gcmVmcmVzaCByZXNwb25zZS4gVGhlIHByZXZpb3VzIHJlZnJlc2gKICAgICAgICAg IHRva2VuIGlzIGludmFsaWRhdGVkIGJ1dCByZXRhaW5lZCBieSB0aGUgYXV0aG9yaXphdGlvbiBz ZXJ2ZXIuIElmIGEgcmVmcmVzaCB0b2tlbiBpcwogICAgICAgICAgY29tcHJvbWlzZWQgYW5kIHN1 YnNlcXVlbnRseSB1c2VkIGJ5IGJvdGggdGhlIGF0dGFja2VyIGFuZCB0aGUgbGVnaXRpbWF0ZSBj bGllbnQsIG9uZSBvZgogICAgICAgICAgdGhlbSB3aWxsIHByZXNlbnQgYW4gaW52YWxpZGF0ZWQg cmVmcmVzaCB0b2tlbiB3aGljaCB3aWxsIGluZm9ybSB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIK ICAgICAgICAgIG9mIHRoZSBicmVhY2guCiAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICBUaGUg YXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVTVCBlbnN1cmUgdGhhdCByZWZyZXNoIHRva2VucyBjYW5u b3QgYmUgZ2VuZXJhdGVkLCBtb2RpZmllZCwKICAgICAgICAgIG9yIGd1ZXNzZWQgdG8gcHJvZHVj ZSB2YWxpZCByZWZyZXNoIHRva2VucyBieSB1bmF1dGhvcml6ZWQgcGFydGllcy4KICAgICAgICAK PC9wPgo8YSBuYW1lPSJhbmNob3IzOCI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0i bGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFs aWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtU T0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLjEwLjUi PjwvYT48aDM+MTAuNS4mbmJzcDsKQXV0aG9yaXphdGlvbiBDb2RlczwvaDM+Cgo8cD4KICAgICAg ICAgIFRoZSB0cmFuc21pc3Npb24gb2YgYXV0aG9yaXphdGlvbiBjb2RlcyBTSE9VTEQgYmUgbWFk ZSBvdmVyIGEgc2VjdXJlIGNoYW5uZWwsIGFuZCB0aGUKICAgICAgICAgIGNsaWVudCBTSE9VTEQg cmVxdWlyZSB0aGUgdXNlIG9mIFRMUyB3aXRoIGl0cyByZWRpcmVjdGlvbiBVUkkgaWYgdGhlIFVS SSBpZGVudGlmaWVzIGEKICAgICAgICAgIG5ldHdvcmsgcmVzb3VyY2UuIFNpbmNlIGF1dGhvcml6 YXRpb24gY29kZXMgYXJlIHRyYW5zbWl0dGVkIHZpYSB1c2VyLWFnZW50IHJlZGlyZWN0aW9ucywK ICAgICAgICAgIHRoZXkgY291bGQgcG90ZW50aWFsbHkgYmUgZGlzY2xvc2VkIHRocm91Z2ggdXNl ci1hZ2VudCBoaXN0b3J5IGFuZCBIVFRQIHJlZmVycmVyIGhlYWRlcnMuCiAgICAgICAgCjwvcD4K PHA+CiAgICAgICAgICBBdXRob3JpemF0aW9uIGNvZGVzIG9wZXJhdGUgYXMgcGxhaW50ZXh0IGJl YXJlciBjcmVkZW50aWFscywgdXNlZCB0byB2ZXJpZnkgdGhhdCB0aGUKICAgICAgICAgIHJlc291 cmNlIG93bmVyIHdobyBncmFudGVkIGF1dGhvcml6YXRpb24gYXQgdGhlIGF1dGhvcml6YXRpb24g c2VydmVyIGlzIHRoZSBzYW1lCiAgICAgICAgICByZXNvdXJjZSBvd25lciByZXR1cm5pbmcgdG8g dGhlIGNsaWVudCB0byBjb21wbGV0ZSB0aGUgcHJvY2Vzcy4gVGhlcmVmb3JlLCBpZiB0aGUgY2xp ZW50CiAgICAgICAgICByZWxpZXMgb24gdGhlIGF1dGhvcml6YXRpb24gY29kZSBmb3IgaXRzIG93 biByZXNvdXJjZSBvd25lciBhdXRoZW50aWNhdGlvbiwgdGhlIGNsaWVudAogICAgICAgICAgcmVk aXJlY3Rpb24gZW5kcG9pbnQgTVVTVCByZXF1aXJlIHRoZSB1c2Ugb2YgVExTLgogICAgICAgIAo8 L3A+CjxwPgogICAgICAgICAgQXV0aG9yaXphdGlvbiBjb2RlcyBNVVNUIGJlIHNob3J0IGxpdmVk IGFuZCBzaW5nbGUgdXNlLiBJZiB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIKICAgICAgICAgIG9i c2VydmVzIG11bHRpcGxlIGF0dGVtcHRzIHRvIGV4Y2hhbmdlIGFuIGF1dGhvcml6YXRpb24gY29k ZSBmb3IgYW4gYWNjZXNzIHRva2VuLCB0aGUKICAgICAgICAgIGF1dGhvcml6YXRpb24gc2VydmVy IFNIT1VMRCBhdHRlbXB0IHRvIHJldm9rZSBhbGwgYWNjZXNzIHRva2VucyBhbHJlYWR5IGdyYW50 ZWQgYmFzZWQgb24KICAgICAgICAgIHRoZSBjb21wcm9taXNlZCBhdXRob3JpemF0aW9uIGNvZGUu CiAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICBJZiB0aGUgY2xpZW50IGNhbiBiZSBhdXRoZW50 aWNhdGVkLCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXJzIE1VU1QgYXV0aGVudGljYXRlIHRoZQog ICAgICAgICAgY2xpZW50IGFuZCBlbnN1cmUgdGhhdCB0aGUgYXV0aG9yaXphdGlvbiBjb2RlIHdh cyBpc3N1ZWQgdG8gdGhlIHNhbWUgY2xpZW50LgogICAgICAgIAo8L3A+CjxhIG5hbWU9ImFuY2hv cjM5Ij48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5n PSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRk IGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwv dHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uMTAuNiI+PC9hPjxoMz4xMC42LiZuYnNw OwpBdXRob3JpemF0aW9uIENvZGUgUmVkaXJlY3Rpb24gVVJJIE1hbmlwdWxhdGlvbjwvaDM+Cgo8 cD4KICAgICAgICAgIFdoZW4gcmVxdWVzdGluZyBhdXRob3JpemF0aW9uIHVzaW5nIHRoZSBhdXRo b3JpemF0aW9uIGNvZGUgZ3JhbnQgdHlwZSwgdGhlIGNsaWVudCBjYW4KICAgICAgICAgIHNwZWNp ZnkgYSByZWRpcmVjdGlvbiBVUkkgdmlhIHRoZSA8dHQ+cmVkaXJlY3RfdXJpPC90dD4gcGFyYW1l dGVyLgogICAgICAgICAgSWYgYW4gYXR0YWNrZXIgY2FuIG1hbmlwdWxhdGUgdGhlIHZhbHVlIG9m IHRoZSByZWRpcmVjdGlvbiBVUkksIGl0IGNhbiBjYXVzZSB0aGUKICAgICAgICAgIGF1dGhvcml6 YXRpb24gc2VydmVyIHRvIHJlZGlyZWN0IHRoZSByZXNvdXJjZSBvd25lciB1c2VyLWFnZW50IHRv IGEgVVJJIHVuZGVyIHRoZSBjb250cm9sCiAgICAgICAgICBvZiB0aGUgYXR0YWNrZXIgd2l0aCB0 aGUgYXV0aG9yaXphdGlvbiBjb2RlLgogICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgQW4gYXR0 YWNrZXIgY2FuIGNyZWF0ZSBhbiBhY2NvdW50IGF0IGEgbGVnaXRpbWF0ZSBjbGllbnQgYW5kIGlu aXRpYXRlIHRoZSBhdXRob3JpemF0aW9uCiAgICAgICAgICBmbG93LiBXaGVuIHRoZSBhdHRhY2tl cidzIHVzZXItYWdlbnQgaXMgc2VudCB0byB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgdG8gZ3Jh bnQgYWNjZXNzLAogICAgICAgICAgdGhlIGF0dGFja2VyIGdyYWJzIHRoZSBhdXRob3JpemF0aW9u IFVSSSBwcm92aWRlZCBieSB0aGUgbGVnaXRpbWF0ZSBjbGllbnQsIGFuZCByZXBsYWNlcwogICAg ICAgICAgdGhlIGNsaWVudCdzIHJlZGlyZWN0aW9uIFVSSSB3aXRoIGEgVVJJIHVuZGVyIHRoZSBj b250cm9sIG9mIHRoZSBhdHRhY2tlci4gVGhlIGF0dGFja2VyCiAgICAgICAgICB0aGVuIHRyaWNr cyB0aGUgdmljdGltIGludG8gZm9sbG93aW5nIHRoZSBtYW5pcHVsYXRlZCBsaW5rIHRvIGF1dGhv cml6ZSBhY2Nlc3MgdG8gdGhlCiAgICAgICAgICBsZWdpdGltYXRlIGNsaWVudC4KICAgICAgICAK PC9wPgo8cD4KICAgICAgICAgIE9uY2UgYXQgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLCB0aGUg dmljdGltIGlzIHByb21wdGVkIHdpdGggYSBub3JtYWwsIHZhbGlkIHJlcXVlc3Qgb24KICAgICAg ICAgIGJlaGFsZiBvZiBhIGxlZ2l0aW1hdGUgYW5kIHRydXN0ZWQgY2xpZW50LCBhbmQgYXV0aG9y aXplcyB0aGUgcmVxdWVzdC4gVGhlIHZpY3RpbSBpcwogICAgICAgICAgdGhlbiByZWRpcmVjdGVk IHRvIGFuIGVuZHBvaW50IHVuZGVyIHRoZSBjb250cm9sIG9mIHRoZSBhdHRhY2tlciB3aXRoIHRo ZSBhdXRob3JpemF0aW9uCiAgICAgICAgICBjb2RlLiBUaGUgYXR0YWNrZXIgY29tcGxldGVzIHRo ZSBhdXRob3JpemF0aW9uIGZsb3cgYnkgc2VuZGluZyB0aGUgYXV0aG9yaXphdGlvbiBjb2RlIHRv CiAgICAgICAgICB0aGUgY2xpZW50IHVzaW5nIHRoZSBvcmlnaW5hbCByZWRpcmVjdGlvbiBVUkkg cHJvdmlkZWQgYnkgdGhlIGNsaWVudC4gVGhlIGNsaWVudAogICAgICAgICAgZXhjaGFuZ2VzIHRo ZSBhdXRob3JpemF0aW9uIGNvZGUgd2l0aCBhbiBhY2Nlc3MgdG9rZW4gYW5kIGxpbmtzIGl0IHRv IHRoZSBhdHRhY2tlcidzCiAgICAgICAgICBjbGllbnQgYWNjb3VudCB3aGljaCBjYW4gbm93IGdh aW4gYWNjZXNzIHRvIHRoZSBwcm90ZWN0ZWQgcmVzb3VyY2VzIGF1dGhvcml6ZWQgYnkgdGhlCiAg ICAgICAgICB2aWN0aW0gKHZpYSB0aGUgY2xpZW50KS4KICAgICAgICAKPC9wPgo8cD4KICAgICAg ICAgIEluIG9yZGVyIHRvIHByZXZlbnQgc3VjaCBhbiBhdHRhY2ssIHRoZSBhdXRob3JpemF0aW9u IHNlcnZlciBNVVNUIGVuc3VyZSB0aGF0IHRoZQogICAgICAgICAgcmVkaXJlY3Rpb24gVVJJIHVz ZWQgdG8gb2J0YWluIHRoZSBhdXRob3JpemF0aW9uIGNvZGUgaXMgaWRlbnRpY2FsIHRvIHRoZSBy ZWRpcmVjdGlvbiBVUkkKICAgICAgICAgIHByb3ZpZGVkIHdoZW4gZXhjaGFuZ2luZyB0aGUgYXV0 aG9yaXphdGlvbiBjb2RlIGZvciBhbiBhY2Nlc3MgdG9rZW4uIFRoZSBhdXRob3JpemF0aW9uCiAg ICAgICAgICBzZXJ2ZXIgTVVTVCByZXF1aXJlIHB1YmxpYyBjbGllbnRzIGFuZCBTSE9VTEQgcmVx dWlyZSBjb25maWRlbnRpYWwgY2xpZW50cyB0byByZWdpc3RlcgogICAgICAgICAgdGhlaXIgcmVk aXJlY3Rpb24gVVJJcy4gSWYgYSByZWRpcmVjdGlvbiBVUkkgaXMgcHJvdmlkZWQgaW4gdGhlIHJl cXVlc3QsIHRoZQogICAgICAgICAgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVTVCB2YWxpZGF0ZSBp dCBhZ2FpbnN0IHRoZSByZWdpc3RlcmVkIHZhbHVlLgogICAgICAgIAo8L3A+CjxhIG5hbWU9ImFu Y2hvcjQwIj48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRk aW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+ PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3Rk PjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uMTAuNyI+PC9hPjxoMz4xMC43LiZu YnNwOwpSZXNvdXJjZSBPd25lciBQYXNzd29yZCBDcmVkZW50aWFsczwvaDM+Cgo8cD4KICAgICAg ICAgIFRoZSByZXNvdXJjZSBvd25lciBwYXNzd29yZCBjcmVkZW50aWFscyBncmFudCB0eXBlIGlz IG9mdGVuIHVzZWQgZm9yIGxlZ2FjeSBvciBtaWdyYXRpb24KICAgICAgICAgIHJlYXNvbnMuIEl0 IHJlZHVjZXMgdGhlIG92ZXJhbGwgcmlzayBvZiBzdG9yaW5nIHVzZXJuYW1lIGFuZCBwYXNzd29y ZCBieSB0aGUgY2xpZW50LCBidXQKICAgICAgICAgIGRvZXMgbm90IGVsaW1pbmF0ZSB0aGUgbmVl ZCB0byBleHBvc2UgaGlnaGx5IHByaXZpbGVnZWQgY3JlZGVudGlhbHMgdG8gdGhlIGNsaWVudC4K ICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgIFRoaXMgZ3JhbnQgdHlwZSBjYXJyaWVzIGEgaGln aGVyIHJpc2sgdGhhbiBvdGhlciBncmFudCB0eXBlcyBiZWNhdXNlIGl0IG1haW50YWlucyB0aGUK ICAgICAgICAgIHBhc3N3b3JkIGFudGktcGF0dGVybiB0aGlzIHByb3RvY29sIHNlZWtzIHRvIGF2 b2lkLiBUaGUgY2xpZW50IGNvdWxkIGFidXNlIHRoZSBwYXNzd29yZAogICAgICAgICAgb3IgdGhl IHBhc3N3b3JkIGNvdWxkIHVuaW50ZW50aW9uYWxseSBiZSBkaXNjbG9zZWQgdG8gYW4gYXR0YWNr ZXIgKGUuZy4gdmlhIGxvZyBmaWxlcyBvcgogICAgICAgICAgb3RoZXIgcmVjb3JkcyBrZXB0IGJ5 IHRoZSBjbGllbnQpLgogICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgQWRkaXRpb25hbGx5LCBi ZWNhdXNlIHRoZSByZXNvdXJjZSBvd25lciBkb2VzIG5vdCBoYXZlIGNvbnRyb2wgb3ZlciB0aGUg YXV0aG9yaXphdGlvbgogICAgICAgICAgcHJvY2VzcyAodGhlIHJlc291cmNlIG93bmVyIGludm9s dmVtZW50IGVuZHMgd2hlbiBpdCBoYW5kcyBvdmVyIGl0cyBjcmVkZW50aWFscyB0byB0aGUKICAg ICAgICAgIGNsaWVudCksIHRoZSBjbGllbnQgY2FuIG9idGFpbiBhY2Nlc3MgdG9rZW5zIHdpdGgg YSBicm9hZGVyIHNjb3BlIHRoYW4gZGVzaXJlZCBieSB0aGUKICAgICAgICAgIHJlc291cmNlIG93 bmVyLiBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgc2hvdWxkIGNvbnNpZGVyIHRoZSBzY29wZSBh bmQgbGlmZXRpbWUgb2YKICAgICAgICAgIGFjY2VzcyB0b2tlbnMgaXNzdWVkIHZpYSB0aGlzIGdy YW50IHR5cGUuCiAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICBUaGUgYXV0aG9yaXphdGlvbiBz ZXJ2ZXIgYW5kIGNsaWVudCBTSE9VTEQgbWluaW1pemUgdXNlIG9mIHRoaXMgZ3JhbnQgdHlwZSBh bmQgdXRpbGl6ZQogICAgICAgICAgb3RoZXIgZ3JhbnQgdHlwZXMgd2hlbmV2ZXIgcG9zc2libGUu CiAgICAgICAgCjwvcD4KPGEgbmFtZT0iYW5jaG9yNDEiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxl IHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0i VE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3Rv YyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2Vj dGlvbi4xMC44Ij48L2E+PGgzPjEwLjguJm5ic3A7ClJlcXVlc3QgQ29uZmlkZW50aWFsaXR5PC9o Mz4KCjxwPgogICAgICAgICAgQWNjZXNzIHRva2VucywgcmVmcmVzaCB0b2tlbnMsIHJlc291cmNl IG93bmVyIHBhc3N3b3JkcywgYW5kIGNsaWVudCBjcmVkZW50aWFscyBNVVNUIE5PVAogICAgICAg ICAgYmUgdHJhbnNtaXR0ZWQgaW4gdGhlIGNsZWFyLiBBdXRob3JpemF0aW9uIGNvZGVzIFNIT1VM RCBOT1QgYmUgdHJhbnNtaXR0ZWQgaW4gdGhlIGNsZWFyLgogICAgICAgIAo8L3A+CjxwPgogICAg ICAgICAgVGhlIDx0dD5zdGF0ZTwvdHQ+IGFuZCA8dHQ+c2NvcGU8L3R0PiBwYXJhbWV0ZXJzCiAg ICAgICAgICBTSE9VTEQgTk9UIGluY2x1ZGUgc2Vuc2l0aXZlIGNsaWVudCBvciByZXNvdXJjZSBv d25lciBpbmZvcm1hdGlvbiBpbiBwbGFpbiB0ZXh0IGFzIHRoZXkKICAgICAgICAgIGNhbiBiZSB0 cmFuc21pdHRlZCBvdmVyIGluc2VjdXJlIGNoYW5uZWxzIG9yIHN0b3JlZCBpbnNlY3VyZWx5Lgog ICAgICAgIAo8L3A+CjxhIG5hbWU9ImFuY2hvcjQyIj48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBz dW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRP Q2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2Mi PiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rp b24uMTAuOSI+PC9hPjxoMz4xMC45LiZuYnNwOwpFbmRwb2ludHMgQXV0aGVudGljaXR5PC9oMz4K CjxwPgogICAgICAgICAgSW4gb3JkZXIgdG8gcHJldmVudCBtYW4taW4tdGhlLW1pZGRsZSBhdHRh Y2tzLCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVTVCByZXF1aXJlIHRoZQogICAgICAgICAg dXNlIG9mIFRMUyB3aXRoIHNlcnZlciBhdXRoZW50aWNhdGlvbiBhcyBkZWZpbmVkIGJ5IDxhIGNs YXNzPSdpbmZvJyBocmVmPScjUkZDMjgxOCc+W1JGQzI4MThdPHNwYW4+ICg8L3NwYW4+PHNwYW4g Y2xhc3M9J2luZm8nPlJlc2NvcmxhLCBFLiwgJmxkcXVvO0hUVFAgT3ZlciBUTFMsJnJkcXVvOyBN YXkmbmJzcDsyMDAwLjwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4gZm9yCiAgICAgICAgICBhbnkg cmVxdWVzdCBzZW50IHRvIHRoZSBhdXRob3JpemF0aW9uIGFuZCB0b2tlbiBlbmRwb2ludHMuIFRo ZSBjbGllbnQgTVVTVCB2YWxpZGF0ZSB0aGUKICAgICAgICAgIGF1dGhvcml6YXRpb24gc2VydmVy J3MgVExTIGNlcnRpZmljYXRlIGFzIGRlZmluZWQgYnkgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNS RkM2MTI1Jz5bUkZDNjEyNV08c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+U2FpbnQt QW5kcmUsIFAuIGFuZCBKLiBIb2RnZXMsICZsZHF1bztSZXByZXNlbnRhdGlvbiBhbmQgVmVyaWZp Y2F0aW9uIG9mIERvbWFpbi1CYXNlZCBBcHBsaWNhdGlvbiBTZXJ2aWNlIElkZW50aXR5IHdpdGhp biBJbnRlcm5ldCBQdWJsaWMgS2V5IEluZnJhc3RydWN0dXJlIFVzaW5nIFguNTA5IChQS0lYKSBD ZXJ0aWZpY2F0ZXMgaW4gdGhlIENvbnRleHQgb2YgVHJhbnNwb3J0IExheWVyIFNlY3VyaXR5IChU TFMpLCZyZHF1bzsgTWFyY2gmbmJzcDsyMDExLjwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4sIGFu ZCBpbgogICAgICAgICAgYWNjb3JkYW5jZSB3aXRoIGl0cyByZXF1aXJlbWVudHMgZm9yIHNlcnZl ciBpZGVudGl0eSBhdXRoZW50aWNhdGlvbi4KICAgICAgICAKPC9wPgo8YSBuYW1lPSJhbnRocm9w eSI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0i MCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBj bGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3Ry PjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLjEwLjEwIj48L2E+PGgzPjEwLjEwLiZuYnNw OwpDcmVkZW50aWFscyBHdWVzc2luZyBBdHRhY2tzPC9oMz4KCjxwPgogICAgICAgICAgVGhlIGF1 dGhvcml6YXRpb24gc2VydmVyIE1VU1QgcHJldmVudCBhdHRhY2tlcnMgZnJvbSBndWVzc2luZyBh Y2Nlc3MgdG9rZW5zLAogICAgICAgICAgYXV0aG9yaXphdGlvbiBjb2RlcywgcmVmcmVzaCB0b2tl bnMsIHJlc291cmNlIG93bmVyIHBhc3N3b3JkcywgYW5kIGNsaWVudCBjcmVkZW50aWFscy4KICAg ICAgICAKPC9wPgo8cD4KICAgICAgICAgIFRoZSBwcm9iYWJpbGl0eSBvZiBhbiBhdHRhY2tlciBn dWVzc2luZyBnZW5lcmF0ZWQgdG9rZW5zIChhbmQgb3RoZXIgY3JlZGVudGlhbHMgbm90CiAgICAg ICAgICBpbnRlbmRlZCBmb3IgaGFuZGxpbmcgYnkgZW5kLXVzZXJzKSBNVVNUIGJlIGxlc3MgdGhh biBvciBlcXVhbCB0byAyXigtMTI4KSBhbmQgU0hPVUxEIGJlCiAgICAgICAgICBsZXNzIHRoYW4g b3IgZXF1YWwgdG8gMl4oLTE2MCkuCiAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICBUaGUgYXV0 aG9yaXphdGlvbiBzZXJ2ZXIgTVVTVCB1dGlsaXplIG90aGVyIG1lYW5zIHRvIHByb3RlY3QgY3Jl ZGVudGlhbHMgaW50ZW5kZWQgZm9yCiAgICAgICAgICBlbmQtdXNlciB1c2FnZS4KICAgICAgICAK PC9wPgo8YSBuYW1lPSJhbmNob3I0MyI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0i bGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFs aWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtU T0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLjEwLjEx Ij48L2E+PGgzPjEwLjExLiZuYnNwOwpQaGlzaGluZyBBdHRhY2tzPC9oMz4KCjxwPgogICAgICAg ICAgV2lkZSBkZXBsb3ltZW50IG9mIHRoaXMgYW5kIHNpbWlsYXIgcHJvdG9jb2xzIG1heSBjYXVz ZSBlbmQtdXNlcnMgdG8gYmVjb21lIGludXJlZAogICAgICAgICAgdG8gdGhlIHByYWN0aWNlIG9m IGJlaW5nIHJlZGlyZWN0ZWQgdG8gd2Vic2l0ZXMgd2hlcmUgdGhleSBhcmUgYXNrZWQgdG8gZW50 ZXIgdGhlaXIKICAgICAgICAgIHBhc3N3b3Jkcy4gSWYgZW5kLXVzZXJzIGFyZSBub3QgY2FyZWZ1 bCB0byB2ZXJpZnkgdGhlIGF1dGhlbnRpY2l0eSBvZiB0aGVzZSB3ZWJzaXRlcwogICAgICAgICAg YmVmb3JlIGVudGVyaW5nIHRoZWlyIGNyZWRlbnRpYWxzLCBpdCB3aWxsIGJlIHBvc3NpYmxlIGZv ciBhdHRhY2tlcnMgdG8gZXhwbG9pdCB0aGlzCiAgICAgICAgICBwcmFjdGljZSB0byBzdGVhbCBy ZXNvdXJjZSBvd25lcnMnIHBhc3N3b3Jkcy4KICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgIFNl cnZpY2UgcHJvdmlkZXJzIHNob3VsZCBhdHRlbXB0IHRvIGVkdWNhdGUgZW5kLXVzZXJzIGFib3V0 IHRoZSByaXNrcyBwaGlzaGluZyBhdHRhY2tzCiAgICAgICAgICBwb3NlLCBhbmQgc2hvdWxkIHBy b3ZpZGUgbWVjaGFuaXNtcyB0aGF0IG1ha2UgaXQgZWFzeSBmb3IgZW5kLXVzZXJzIHRvIGNvbmZp cm0gdGhlCiAgICAgICAgICBhdXRoZW50aWNpdHkgb2YgdGhlaXIgc2l0ZXMuIENsaWVudCBkZXZl bG9wZXJzIHNob3VsZCBjb25zaWRlciB0aGUgc2VjdXJpdHkgaW1wbGljYXRpb25zCiAgICAgICAg ICBvZiBob3cgdGhleSBpbnRlcmFjdCB3aXRoIHRoZSB1c2VyLWFnZW50IChlLmcuLCBleHRlcm5h bCwgZW1iZWRkZWQpLCBhbmQgdGhlIGFiaWxpdHkgb2YKICAgICAgICAgIHRoZSBlbmQtdXNlciB0 byB2ZXJpZnkgdGhlIGF1dGhlbnRpY2l0eSBvZiB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIuCiAg ICAgICAgCjwvcD4KPHA+CiAgICAgICAgICBUbyByZWR1Y2UgdGhlIHJpc2sgb2YgcGhpc2hpbmcg YXR0YWNrcywgdGhlIGF1dGhvcml6YXRpb24gc2VydmVycyBNVVNUIHJlcXVpcmUgdGhlIHVzZSBv ZgogICAgICAgICAgVExTIG9uIGV2ZXJ5IGVuZHBvaW50IHVzZWQgZm9yIGVuZC11c2VyIGludGVy YWN0aW9uLgogICAgICAgIAo8L3A+CjxhIG5hbWU9IkNTUkYiPjwvYT48YnIgLz48aHIgLz4KPHRh YmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFz cz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0i I3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMu c2VjdGlvbi4xMC4xMiI+PC9hPjxoMz4xMC4xMi4mbmJzcDsKQ3Jvc3MtU2l0ZSBSZXF1ZXN0IEZv cmdlcnk8L2gzPgoKPHA+CiAgICAgICAgICBDcm9zcy1zaXRlIHJlcXVlc3QgZm9yZ2VyeSAoQ1NS RikgaXMgYW4gZXhwbG9pdCBpbiB3aGljaCBhbiBhdHRhY2tlciBjYXVzZXMgdGhlCiAgICAgICAg ICB1c2VyLWFnZW50IG9mIGEgdmljdGltIGVuZC11c2VyIHRvIGZvbGxvdyBhIG1hbGljaW91cyBV UkkgKGUuZy4gcHJvdmlkZWQgdG8gdGhlCiAgICAgICAgICB1c2VyLWFnZW50IGFzIGEgbWlzbGVh ZGluZyBsaW5rLCBpbWFnZSwgb3IgcmVkaXJlY3Rpb24pIHRvIGEgdHJ1c3Rpbmcgc2VydmVyICh1 c3VhbGx5CiAgICAgICAgICBlc3RhYmxpc2hlZCB2aWEgdGhlIHByZXNlbmNlIG9mIGEgdmFsaWQg c2Vzc2lvbiBjb29raWUpLgogICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgQSBDU1JGIGF0dGFj ayBhZ2FpbnN0IHRoZSBjbGllbnQncyByZWRpcmVjdGlvbiBVUkkgYWxsb3dzIGFuIGF0dGFja2Vy IHRvIGluamVjdCB0aGVpciBvd24KICAgICAgICAgIGF1dGhvcml6YXRpb24gY29kZSBvciBhY2Nl c3MgdG9rZW4sIHdoaWNoIGNhbiByZXN1bHQgaW4gdGhlIGNsaWVudCB1c2luZyBhbiBhY2Nlc3Mg dG9rZW4KICAgICAgICAgIGFzc29jaWF0ZWQgd2l0aCB0aGUgYXR0YWNrZXIncyBwcm90ZWN0ZWQg cmVzb3VyY2VzIHJhdGhlciB0aGFuIHRoZSB2aWN0aW0ncyAoZS5nLiBzYXZlCiAgICAgICAgICB0 aGUgdmljdGltJ3MgYmFuayBhY2NvdW50IGluZm9ybWF0aW9uIHRvIGEgcHJvdGVjdGVkIHJlc291 cmNlIGNvbnRyb2xsZWQgYnkgdGhlCiAgICAgICAgICBhdHRhY2tlcikuCiAgICAgICAgCjwvcD4K PHA+CiAgICAgICAgICBUaGUgY2xpZW50IE1VU1QgaW1wbGVtZW50IENTUkYgcHJvdGVjdGlvbiBm b3IgaXRzIHJlZGlyZWN0aW9uIFVSSS4gVGhpcyBpcyB0eXBpY2FsbHkKICAgICAgICAgIGFjY29t cGxpc2hlZCBieSByZXF1aXJpbmcgYW55IHJlcXVlc3Qgc2VudCB0byB0aGUgcmVkaXJlY3Rpb24g VVJJIGVuZHBvaW50IHRvIGluY2x1ZGUgYQogICAgICAgICAgdmFsdWUgdGhhdCBiaW5kcyB0aGUg cmVxdWVzdCB0byB0aGUgdXNlci1hZ2VudCdzIGF1dGhlbnRpY2F0ZWQgc3RhdGUgKGUuZy4gYSBo YXNoIG9mIHRoZQogICAgICAgICAgc2Vzc2lvbiBjb29raWUgdXNlZCB0byBhdXRoZW50aWNhdGUg dGhlIHVzZXItYWdlbnQpLiBUaGUgY2xpZW50IFNIT1VMRCB1dGlsaXplIHRoZQogICAgICAgICAg PHR0PnN0YXRlPC90dD4gcmVxdWVzdCBwYXJhbWV0ZXIgdG8gZGVsaXZlciB0aGlzIHZhbHVlIHRv IHRoZQogICAgICAgICAgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgd2hlbiBtYWtpbmcgYW4gYXV0aG9y aXphdGlvbiByZXF1ZXN0LgogICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgT25jZSBhdXRob3Jp emF0aW9uIGhhcyBiZWVuIG9idGFpbmVkIGZyb20gdGhlIGVuZC11c2VyLCB0aGUgYXV0aG9yaXph dGlvbiBzZXJ2ZXIKICAgICAgICAgIHJlZGlyZWN0cyB0aGUgZW5kLXVzZXIncyB1c2VyLWFnZW50 IGJhY2sgdG8gdGhlIGNsaWVudCB3aXRoIHRoZSByZXF1aXJlZCBiaW5kaW5nIHZhbHVlCiAgICAg ICAgICBjb250YWluZWQgaW4gdGhlIDx0dD5zdGF0ZTwvdHQ+IHBhcmFtZXRlci4gVGhlIGJpbmRp bmcgdmFsdWUgZW5hYmxlcwogICAgICAgICAgdGhlIGNsaWVudCB0byB2ZXJpZnkgdGhlIHZhbGlk aXR5IG9mIHRoZSByZXF1ZXN0IGJ5IG1hdGNoaW5nIHRoZSBiaW5kaW5nIHZhbHVlIHRvIHRoZQog ICAgICAgICAgdXNlci1hZ2VudCdzIGF1dGhlbnRpY2F0ZWQgc3RhdGUuIFRoZSBiaW5kaW5nIHZh bHVlIHVzZWQgZm9yIENTUkYgcHJvdGVjdGlvbiBNVVNUIGNvbnRhaW4KICAgICAgICAgIGEgbm9u LWd1ZXNzYWJsZSB2YWx1ZSAoYXMgZGVzY3JpYmVkIGluIDxhIGNsYXNzPSdpbmZvJyBocmVmPScj YW50aHJvcHknPlNlY3Rpb24mbmJzcDsxMC4xMDxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdp bmZvJz5DcmVkZW50aWFscyBHdWVzc2luZyBBdHRhY2tzPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9h PiksIGFuZCB0aGUgdXNlci1hZ2VudCdzCiAgICAgICAgICBhdXRoZW50aWNhdGVkIHN0YXRlIChl LmcuIHNlc3Npb24gY29va2llLCBIVE1MNSBsb2NhbCBzdG9yYWdlKSBNVVNUIGJlIGtlcHQgaW4g YSBsb2NhdGlvbgogICAgICAgICAgYWNjZXNzaWJsZSBvbmx5IHRvIHRoZSBjbGllbnQgYW5kIHRo ZSB1c2VyLWFnZW50IChpLmUuLCBwcm90ZWN0ZWQgYnkgc2FtZS1vcmlnaW4gcG9saWN5KS4KICAg ICAgICAKPC9wPgo8cD4KICAgICAgICAgIEEgQ1NSRiBhdHRhY2sgYWdhaW5zdCB0aGUgYXV0aG9y aXphdGlvbiBzZXJ2ZXIncyBhdXRob3JpemF0aW9uIGVuZHBvaW50IGNhbiByZXN1bHQgaW4gYW4K ICAgICAgICAgIGF0dGFja2VyIG9idGFpbmluZyBlbmQtdXNlciBhdXRob3JpemF0aW9uIGZvciBh IG1hbGljaW91cyBjbGllbnQgd2l0aG91dCBpbnZvbHZpbmcgb3IKICAgICAgICAgIGFsZXJ0aW5n IHRoZSBlbmQtdXNlci4KICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgIFRoZSBhdXRob3JpemF0 aW9uIHNlcnZlciBNVVNUIGltcGxlbWVudCBDU1JGIHByb3RlY3Rpb24gZm9yIGl0cyBhdXRob3Jp emF0aW9uIGVuZHBvaW50LAogICAgICAgICAgYW5kIGVuc3VyZSB0aGF0IGEgbWFsaWNpb3VzIGNs aWVudCBjYW5ub3Qgb2J0YWluIGF1dGhvcml6YXRpb24gd2l0aG91dCB0aGUgYXdhcmVuZXNzIGFu ZAogICAgICAgICAgZXhwbGljaXQgY29uc2VudCBvZiB0aGUgcmVzb3VyY2Ugb3duZXIuCiAgICAg ICAgCjwvcD4KPGEgbmFtZT0iYW5jaG9yNDQiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1h cnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVn IiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5i c3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi4x MC4xMyI+PC9hPjxoMz4xMC4xMy4mbmJzcDsKQ2xpY2tqYWNraW5nPC9oMz4KCjxwPgogICAgICAg ICAgSW4gYSBjbGlja2phY2tpbmcgYXR0YWNrLCBhbiBhdHRhY2tlciByZWdpc3RlcnMgYSBsZWdp dGltYXRlIGNsaWVudCBhbmQgdGhlbiBjb25zdHJ1Y3RzIGEKICAgICAgICAgIG1hbGljaW91cyBz aXRlIGluIHdoaWNoIGl0IGxvYWRzIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlcidzIGF1dGhvcml6 YXRpb24gZW5kcG9pbnQgd2ViCiAgICAgICAgICBwYWdlIGluIGEgdHJhbnNwYXJlbnQgaWZyYW1l IG92ZXJsYWlkIG9uIHRvcCBvZiBhIHNldCBvZiBkdW1teSBidXR0b25zIHdoaWNoIGFyZQogICAg ICAgICAgY2FyZWZ1bGx5IGNvbnN0cnVjdGVkIHRvIGJlIHBsYWNlZCBkaXJlY3RseSB1bmRlciBp bXBvcnRhbnQgYnV0dG9ucyBvbiB0aGUgYXV0aG9yaXphdGlvbgogICAgICAgICAgcGFnZS4gV2hl biBhbiBlbmQtdXNlciBjbGlja3MgYSBtaXNsZWFkaW5nIHZpc2libGUgYnV0dG9uLCB0aGUgZW5k LXVzZXIgaXMgYWN0dWFsbHkKICAgICAgICAgIGNsaWNraW5nIGFuIGludmlzaWJsZSBidXR0b24g b24gdGhlIGF1dGhvcml6YXRpb24gcGFnZSAoc3VjaCBhcyBhbiAiQXV0aG9yaXplIiBidXR0b24p LgogICAgICAgICAgVGhpcyBhbGxvd3MgYW4gYXR0YWNrZXIgdG8gdHJpY2sgYSByZXNvdXJjZSBv d25lciBpbnRvIGdyYW50aW5nIGl0cyBjbGllbnQgYWNjZXNzIHdpdGhvdXQKICAgICAgICAgIHRo ZWlyIGtub3dsZWRnZS4KICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgIFRvIHByZXZlbnQgdGhp cyBmb3JtIG9mIGF0dGFjaywgbmF0aXZlIGFwcGxpY2F0aW9ucyBTSE9VTEQgdXNlIGV4dGVybmFs IGJyb3dzZXJzIGluc3RlYWQKICAgICAgICAgIG9mIGVtYmVkZGluZyBicm93c2VycyB3aXRoaW4g dGhlIGFwcGxpY2F0aW9uIHdoZW4gcmVxdWVzdGluZyBlbmQtdXNlciBhdXRob3JpemF0aW9uLiBG b3IKICAgICAgICAgIG1vc3QgbmV3ZXIgYnJvd3NlcnMsIGF2b2lkYW5jZSBvZiBpZnJhbWVzIGNh biBiZSBlbmZvcmNlZCBieSB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIKICAgICAgICAgIHVzaW5n IHRoZSAobm9uLXN0YW5kYXJkKSA8dHQ+eC1mcmFtZS1vcHRpb25zPC90dD4gaGVhZGVyLiBUaGlz IGhlYWRlcgogICAgICAgICAgY2FuIGhhdmUgdHdvIHZhbHVlcywgPHR0PmRlbnk8L3R0PiBhbmQK ICAgICAgICAgIDx0dD5zYW1lb3JpZ2luPC90dD4sIHdoaWNoIHdpbGwgYmxvY2sgYW55IGZyYW1p bmcsIG9yIGZyYW1pbmcgYnkgc2l0ZXMKICAgICAgICAgIHdpdGggYSBkaWZmZXJlbnQgb3JpZ2lu LCByZXNwZWN0aXZlbHkuIEZvciBvbGRlciBicm93c2VycywgSmF2YVNjcmlwdCBmcmFtZWJ1c3Rp bmcKICAgICAgICAgIHRlY2huaXF1ZXMgY2FuIGJlIHVzZWQgYnV0IG1heSBub3QgYmUgZWZmZWN0 aXZlIGluIGFsbCBicm93c2Vycy4KICAgICAgICAKPC9wPgo8YSBuYW1lPSJhbmNob3I0NSI+PC9h PjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2Vs bHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0i VE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFi bGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLjEwLjE0Ij48L2E+PGgzPjEwLjE0LiZuYnNwOwpDb2Rl IEluamVjdGlvbiBhbmQgSW5wdXQgVmFsaWRhdGlvbjwvaDM+Cgo8cD4KICAgICAgICAgIEEgY29k ZSBpbmplY3Rpb24gYXR0YWNrIG9jY3VycyB3aGVuIGFuIGlucHV0IG9yIG90aGVyd2lzZSBleHRl cm5hbCB2YXJpYWJsZSBpcyB1c2VkIGJ5IGFuCiAgICAgICAgICBhcHBsaWNhdGlvbiB1bnNhbml0 aXplZCBhbmQgY2F1c2VzIG1vZGlmaWNhdGlvbiB0byB0aGUgYXBwbGljYXRpb24gbG9naWMuIFRo aXMgbWF5IGFsbG93CiAgICAgICAgICBhbiBhdHRhY2tlciB0byBnYWluIGFjY2VzcyB0byB0aGUg YXBwbGljYXRpb24gZGV2aWNlIG9yIGl0cyBkYXRhLCBjYXVzZSBkZW5pYWwgb2YKICAgICAgICAg IHNlcnZpY2UsIG9yIGEgd2lkZSByYW5nZSBvZiBtYWxpY2lvdXMgc2lkZS1lZmZlY3RzLgogICAg ICAgIAo8L3A+CjxwPgogICAgICAgICAgVGhlIEF1dGhvcml6YXRpb24gc2VydmVyIGFuZCBjbGll bnQgTVVTVCBzYW5pdGl6ZSAoYW5kIHZhbGlkYXRlIHdoZW4gcG9zc2libGUpIGFueSB2YWx1ZQog ICAgICAgICAgcmVjZWl2ZWQsIGluIHBhcnRpY3VsYXIsIHRoZSB2YWx1ZSBvZiB0aGUgPHR0PnN0 YXRlPC90dD4gYW5kCiAgICAgICAgICA8dHQ+cmVkaXJlY3RfdXJpPC90dD4gcGFyYW1ldGVycy4K ICAgICAgICAKPC9wPgo8YSBuYW1lPSJvcGVuLXJlZGlyZWN0Ij48L2E+PGJyIC8+PGhyIC8+Cjx0 YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xh c3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9 IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZj LnNlY3Rpb24uMTAuMTUiPjwvYT48aDM+MTAuMTUuJm5ic3A7Ck9wZW4gUmVkaXJlY3RvcnM8L2gz PgoKPHA+CiAgICAgICAgICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYXV0aG9yaXphdGlvbiBl bmRwb2ludCBhbmQgdGhlIGNsaWVudCByZWRpcmVjdGlvbiBlbmRwb2ludCBjYW4KICAgICAgICAg IGJlIGltcHJvcGVybHkgY29uZmlndXJlZCBhbmQgb3BlcmF0ZSBhcyBvcGVuIHJlZGlyZWN0b3Jz LiBBbiBvcGVuIHJlZGlyZWN0b3IgaXMgYW4KICAgICAgICAgIGVuZHBvaW50IHVzaW5nIGEgcGFy YW1ldGVyIHRvIGF1dG9tYXRpY2FsbHkgcmVkaXJlY3QgYSB1c2VyLWFnZW50IHRvIHRoZSBsb2Nh dGlvbgogICAgICAgICAgc3BlY2lmaWVkIGJ5IHRoZSBwYXJhbWV0ZXIgdmFsdWUgd2l0aG91dCBh bnkgdmFsaWRhdGlvbi4KICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgIE9wZW4gcmVkaXJlY3Rv cnMgY2FuIGJlIHVzZWQgaW4gcGhpc2hpbmcgYXR0YWNrcywgb3IgYnkgYW4gYXR0YWNrZXIgdG8g Z2V0IGVuZC11c2VycyB0bwogICAgICAgICAgdmlzaXQgbWFsaWNpb3VzIHNpdGVzIGJ5IG1ha2lu ZyB0aGUgVVJJJ3MgYXV0aG9yaXR5IGxvb2sgbGlrZSBhIGZhbWlsaWFyIGFuZCB0cnVzdGVkCiAg ICAgICAgICBkZXN0aW5hdGlvbi4gSW4gYWRkaXRpb24sIGlmIHRoZSBhdXRob3JpemF0aW9uIHNl cnZlciBhbGxvd3MgdGhlIGNsaWVudCB0byByZWdpc3RlciBvbmx5CiAgICAgICAgICBwYXJ0IG9m IHRoZSByZWRpcmVjdGlvbiBVUkksIGFuIGF0dGFja2VyIGNhbiB1c2UgYW4gb3BlbiByZWRpcmVj dG9yIG9wZXJhdGVkIGJ5IHRoZQogICAgICAgICAgY2xpZW50IHRvIGNvbnN0cnVjdCBhIHJlZGly ZWN0aW9uIFVSSSB0aGF0IHdpbGwgcGFzcyB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgdmFsaWRh dGlvbgogICAgICAgICAgYnV0IHdpbGwgc2VuZCB0aGUgYXV0aG9yaXphdGlvbiBjb2RlIG9yIGFj Y2VzcyB0b2tlbiB0byBhbiBlbmRwb2ludCB1bmRlciB0aGUgY29udHJvbCBvZgogICAgICAgICAg dGhlIGF0dGFja2VyLgogICAgICAgIAo8L3A+CjxhIG5hbWU9ImFuY2hvcjQ2Ij48L2E+PGJyIC8+ PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2lu Zz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWci PjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEg bmFtZT0icmZjLnNlY3Rpb24uMTEiPjwvYT48aDM+MTEuJm5ic3A7CklBTkEgQ29uc2lkZXJhdGlv bnM8L2gzPgoKPGEgbmFtZT0idHlwZS1yZWdpc3RyeSI+PC9hPjxiciAvPjxociAvPgo8dGFibGUg c3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJU T0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9j Ij4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0 aW9uLjExLjEiPjwvYT48aDM+MTEuMS4mbmJzcDsKVGhlIE9BdXRoIEFjY2VzcyBUb2tlbiBUeXBl IFJlZ2lzdHJ5PC9oMz4KCjxwPgogICAgICAgICAgVGhpcyBzcGVjaWZpY2F0aW9uIGVzdGFibGlz aGVzIHRoZSBPQXV0aCBhY2Nlc3MgdG9rZW4gdHlwZSByZWdpc3RyeS4KICAgICAgICAKPC9wPgo8 cD4KICAgICAgICAgIEFjY2VzcyB0b2tlbiB0eXBlcyBhcmUgcmVnaXN0ZXJlZCB3aXRoIGEgU3Bl Y2lmaWNhdGlvbiBSZXF1aXJlZAogICAgICAgICAgKDxhIGNsYXNzPSdpbmZvJyBocmVmPScjUkZD NTIyNic+W1JGQzUyMjZdPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPk5hcnRlbiwg VC4gYW5kIEguIEFsdmVzdHJhbmQsICZsZHF1bztHdWlkZWxpbmVzIGZvciBXcml0aW5nIGFuIElB TkEgQ29uc2lkZXJhdGlvbnMgU2VjdGlvbiBpbiBSRkNzLCZyZHF1bzsgTWF5Jm5ic3A7MjAwOC48 L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+KSBhZnRlciBhIHR3byB3ZWVrIHJldmlldyBwZXJpb2Qg b24gdGhlIFtUQkRdQGlldGYub3JnIG1haWxpbmcKICAgICAgICAgIGxpc3QsIG9uIHRoZSBhZHZp Y2Ugb2Ygb25lIG9yIG1vcmUgRGVzaWduYXRlZCBFeHBlcnRzLiBIb3dldmVyLCB0byBhbGxvdyBm b3IgdGhlCiAgICAgICAgICBhbGxvY2F0aW9uIG9mIHZhbHVlcyBwcmlvciB0byBwdWJsaWNhdGlv biwgdGhlIERlc2lnbmF0ZWQgRXhwZXJ0KHMpIG1heSBhcHByb3ZlCiAgICAgICAgICByZWdpc3Ry YXRpb24gb25jZSB0aGV5IGFyZSBzYXRpc2ZpZWQgdGhhdCBzdWNoIGEgc3BlY2lmaWNhdGlvbiB3 aWxsIGJlIHB1Ymxpc2hlZC4KICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgIFJlZ2lzdHJhdGlv biByZXF1ZXN0cyBtdXN0IGJlIHNlbnQgdG8gdGhlIFtUQkRdQGlldGYub3JnIG1haWxpbmcgbGlz dCBmb3IgcmV2aWV3IGFuZAogICAgICAgICAgY29tbWVudCwgd2l0aCBhbiBhcHByb3ByaWF0ZSBz dWJqZWN0IChlLmcuLCAiUmVxdWVzdCBmb3IgYWNjZXNzIHRva2VuIHR5cGU6IGV4YW1wbGUiKS4K ICAgICAgICAgIFtbIE5vdGUgdG8gUkZDLUVESVRPUjogVGhlIG5hbWUgb2YgdGhlIG1haWxpbmcg bGlzdCBzaG91bGQgYmUgZGV0ZXJtaW5lZCBpbiBjb25zdWx0YXRpb24KICAgICAgICAgIHdpdGgg dGhlIElFU0cgYW5kIElBTkEuIFN1Z2dlc3RlZCBuYW1lOiBvYXV0aC1leHQtcmV2aWV3LiBdXQog ICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgV2l0aGluIHRoZSByZXZpZXcgcGVyaW9kLCB0aGUg RGVzaWduYXRlZCBFeHBlcnQocykgd2lsbCBlaXRoZXIgYXBwcm92ZSBvcgogICAgICAgICAgZGVu eSB0aGUgcmVnaXN0cmF0aW9uIHJlcXVlc3QsIGNvbW11bmljYXRpbmcgdGhpcyBkZWNpc2lvbiB0 byB0aGUgcmV2aWV3IGxpc3QgYW5kIElBTkEuCiAgICAgICAgICBEZW5pYWxzIHNob3VsZCBpbmNs dWRlIGFuIGV4cGxhbmF0aW9uIGFuZCwgaWYgYXBwbGljYWJsZSwgc3VnZ2VzdGlvbnMgYXMgdG8g aG93IHRvIG1ha2UKICAgICAgICAgIHRoZSByZXF1ZXN0IHN1Y2Nlc3NmdWwuCiAgICAgICAgCjwv cD4KPHA+CiAgICAgICAgICBJQU5BIG11c3Qgb25seSBhY2NlcHQgcmVnaXN0cnkgdXBkYXRlcyBm cm9tIHRoZSBEZXNpZ25hdGVkIEV4cGVydChzKSwgYW5kIHNob3VsZCBkaXJlY3QKICAgICAgICAg IGFsbCByZXF1ZXN0cyBmb3IgcmVnaXN0cmF0aW9uIHRvIHRoZSByZXZpZXcgbWFpbGluZyBsaXN0 LgogICAgICAgIAo8L3A+CjxhIG5hbWU9ImFuY2hvcjQ3Ij48L2E+PGJyIC8+PGhyIC8+Cjx0YWJs ZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9 IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0 b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNl Y3Rpb24uMTEuMS4xIj48L2E+PGgzPjExLjEuMS4mbmJzcDsKUmVnaXN0cmF0aW9uIFRlbXBsYXRl PC9oMz4KCjxwPgogICAgICAgICAgICA8L3A+CjxibG9ja3F1b3RlIGNsYXNzPSJ0ZXh0Ij48ZGw+ CjxkdD5UeXBlIG5hbWU6PC9kdD4KPGRkPgogICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAg ICBUaGUgbmFtZSByZXF1ZXN0ZWQgKGUuZy4sICJleGFtcGxlIikuCiAgICAgICAgICAgICAgCjwv ZGQ+CjxkdD5BZGRpdGlvbmFsIFRva2VuIEVuZHBvaW50IFJlc3BvbnNlIFBhcmFtZXRlcnM6PC9k dD4KPGRkPgogICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICBBZGRpdGlvbmFsIHJlc3Bv bnNlIHBhcmFtZXRlcnMgcmV0dXJuZWQgdG9nZXRoZXIgd2l0aCB0aGUKICAgICAgICAgICAgICAg IDx0dD5hY2Nlc3NfdG9rZW48L3R0PiBwYXJhbWV0ZXIuIE5ldyBwYXJhbWV0ZXJzIE1VU1QgYmUK ICAgICAgICAgICAgICAgIHNlcGFyYXRlbHkgcmVnaXN0ZXJlZCBpbiB0aGUgT0F1dGggcGFyYW1l dGVycyByZWdpc3RyeSBhcyBkZXNjcmliZWQgYnkKICAgICAgICAgICAgICAgIDxhIGNsYXNzPSdp bmZvJyBocmVmPScjcGFyYW1ldGVycy1yZWdpc3RyeSc+U2VjdGlvbiZuYnNwOzExLjI8c3Bhbj4g KDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+VGhlIE9BdXRoIFBhcmFtZXRlcnMgUmVnaXN0cnk8 L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+LgogICAgICAgICAgICAgIAo8L2RkPgo8ZHQ+SFRUUCBB dXRoZW50aWNhdGlvbiBTY2hlbWUocyk6PC9kdD4KPGRkPgogICAgICAgICAgICAgICAgCiAgICAg ICAgICAgICAgICBUaGUgSFRUUCBhdXRoZW50aWNhdGlvbiBzY2hlbWUgbmFtZShzKSwgaWYgYW55 LCB1c2VkIHRvIGF1dGhlbnRpY2F0ZSBwcm90ZWN0ZWQKICAgICAgICAgICAgICAgIHJlc291cmNl cyByZXF1ZXN0cyB1c2luZyBhY2Nlc3MgdG9rZW5zIG9mIHRoaXMgdHlwZS4KICAgICAgICAgICAg ICAKPC9kZD4KPGR0PkNoYW5nZSBjb250cm9sbGVyOjwvZHQ+CjxkZD4KICAgICAgICAgICAgICAg IAogICAgICAgICAgICAgICAgRm9yIHN0YW5kYXJkcy10cmFjayBSRkNzLCBzdGF0ZSAiSUVURiIu IEZvciBvdGhlcnMsIGdpdmUgdGhlIG5hbWUgb2YgdGhlCiAgICAgICAgICAgICAgICByZXNwb25z aWJsZSBwYXJ0eS4gT3RoZXIgZGV0YWlscyAoZS5nLiwgcG9zdGFsIGFkZHJlc3MsIGUtbWFpbCBh ZGRyZXNzLCBob21lIHBhZ2UKICAgICAgICAgICAgICAgIFVSSSkgbWF5IGFsc28gYmUgaW5jbHVk ZWQuCiAgICAgICAgICAgICAgCjwvZGQ+CjxkdD5TcGVjaWZpY2F0aW9uIGRvY3VtZW50KHMpOjwv ZHQ+CjxkZD4KICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgUmVmZXJlbmNlIHRvIHRo ZSBkb2N1bWVudCB0aGF0IHNwZWNpZmllcyB0aGUgcGFyYW1ldGVyLCBwcmVmZXJhYmx5IGluY2x1 ZGluZyBhIFVSSSB0aGF0CiAgICAgICAgICAgICAgICBjYW4gYmUgdXNlZCB0byByZXRyaWV2ZSBh IGNvcHkgb2YgdGhlIGRvY3VtZW50LiBBbiBpbmRpY2F0aW9uIG9mIHRoZSByZWxldmFudAogICAg ICAgICAgICAgICAgc2VjdGlvbnMgbWF5IGFsc28gYmUgaW5jbHVkZWQsIGJ1dCBpcyBub3QgcmVx dWlyZWQuCiAgICAgICAgICAgICAgCjwvZGQ+CjwvZGw+PC9ibG9ja3F1b3RlPjxwPgogICAgICAg ICAgCjwvcD4KPGEgbmFtZT0icGFyYW1ldGVycy1yZWdpc3RyeSI+PC9hPjxiciAvPjxociAvPgo8 dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNs YXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVm PSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJm Yy5zZWN0aW9uLjExLjIiPjwvYT48aDM+MTEuMi4mbmJzcDsKVGhlIE9BdXRoIFBhcmFtZXRlcnMg UmVnaXN0cnk8L2gzPgoKPHA+CiAgICAgICAgICBUaGlzIHNwZWNpZmljYXRpb24gZXN0YWJsaXNo ZXMgdGhlIE9BdXRoIHBhcmFtZXRlcnMgcmVnaXN0cnkuCiAgICAgICAgCjwvcD4KPHA+CiAgICAg ICAgICBBZGRpdGlvbmFsIHBhcmFtZXRlcnMgZm9yIGluY2x1c2lvbiBpbiB0aGUgYXV0aG9yaXph dGlvbiBlbmRwb2ludCByZXF1ZXN0LCB0aGUKICAgICAgICAgIGF1dGhvcml6YXRpb24gZW5kcG9p bnQgcmVzcG9uc2UsIHRoZSB0b2tlbiBlbmRwb2ludCByZXF1ZXN0LCBvciB0aGUgdG9rZW4gZW5k cG9pbnQKICAgICAgICAgIHJlc3BvbnNlIGFyZSByZWdpc3RlcmVkIHdpdGggYSBTcGVjaWZpY2F0 aW9uIFJlcXVpcmVkCiAgICAgICAgICAoPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNSRkM1MjI2Jz5b UkZDNTIyNl08c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+TmFydGVuLCBULiBhbmQg SC4gQWx2ZXN0cmFuZCwgJmxkcXVvO0d1aWRlbGluZXMgZm9yIFdyaXRpbmcgYW4gSUFOQSBDb25z aWRlcmF0aW9ucyBTZWN0aW9uIGluIFJGQ3MsJnJkcXVvOyBNYXkmbmJzcDsyMDA4Ljwvc3Bhbj48 c3Bhbj4pPC9zcGFuPjwvYT4pIGFmdGVyIGEgdHdvIHdlZWsgcmV2aWV3IHBlcmlvZCBvbiB0aGUg W1RCRF1AaWV0Zi5vcmcgbWFpbGluZwogICAgICAgICAgbGlzdCwgb24gdGhlIGFkdmljZSBvZiBv bmUgb3IgbW9yZSBEZXNpZ25hdGVkIEV4cGVydHMuIEhvd2V2ZXIsIHRvIGFsbG93IGZvciB0aGUK ICAgICAgICAgIGFsbG9jYXRpb24gb2YgdmFsdWVzIHByaW9yIHRvIHB1YmxpY2F0aW9uLCB0aGUg RGVzaWduYXRlZCBFeHBlcnQocykgbWF5IGFwcHJvdmUKICAgICAgICAgIHJlZ2lzdHJhdGlvbiBv bmNlIHRoZXkgYXJlIHNhdGlzZmllZCB0aGF0IHN1Y2ggYSBzcGVjaWZpY2F0aW9uIHdpbGwgYmUg cHVibGlzaGVkLgogICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgUmVnaXN0cmF0aW9uIHJlcXVl c3RzIG11c3QgYmUgc2VudCB0byB0aGUgW1RCRF1AaWV0Zi5vcmcgbWFpbGluZyBsaXN0IGZvciBy ZXZpZXcgYW5kCiAgICAgICAgICBjb21tZW50LCB3aXRoIGFuIGFwcHJvcHJpYXRlIHN1YmplY3Qg KGUuZy4sICJSZXF1ZXN0IGZvciBwYXJhbWV0ZXI6IGV4YW1wbGUiKS4KICAgICAgICAgIFtbIE5v dGUgdG8gUkZDLUVESVRPUjogVGhlIG5hbWUgb2YgdGhlIG1haWxpbmcgbGlzdCBzaG91bGQgYmUg ZGV0ZXJtaW5lZCBpbiBjb25zdWx0YXRpb24KICAgICAgICAgIHdpdGggdGhlIElFU0cgYW5kIElB TkEuIFN1Z2dlc3RlZCBuYW1lOiBvYXV0aC1leHQtcmV2aWV3LiBdXQogICAgICAgIAo8L3A+Cjxw PgogICAgICAgICAgV2l0aGluIHRoZSByZXZpZXcgcGVyaW9kLCB0aGUgRGVzaWduYXRlZCBFeHBl cnQocykgd2lsbCBlaXRoZXIgYXBwcm92ZSBvcgogICAgICAgICAgZGVueSB0aGUgcmVnaXN0cmF0 aW9uIHJlcXVlc3QsIGNvbW11bmljYXRpbmcgdGhpcyBkZWNpc2lvbiB0byB0aGUgcmV2aWV3IGxp c3QgYW5kIElBTkEuCiAgICAgICAgICBEZW5pYWxzIHNob3VsZCBpbmNsdWRlIGFuIGV4cGxhbmF0 aW9uIGFuZCwgaWYgYXBwbGljYWJsZSwgc3VnZ2VzdGlvbnMgYXMgdG8gaG93IHRvIG1ha2UKICAg ICAgICAgIHRoZSByZXF1ZXN0IHN1Y2Nlc3NmdWwuCiAgICAgICAgCjwvcD4KPHA+CiAgICAgICAg ICBJQU5BIG11c3Qgb25seSBhY2NlcHQgcmVnaXN0cnkgdXBkYXRlcyBmcm9tIHRoZSBEZXNpZ25h dGVkIEV4cGVydChzKSwgYW5kIHNob3VsZCBkaXJlY3QKICAgICAgICAgIGFsbCByZXF1ZXN0cyBm b3IgcmVnaXN0cmF0aW9uIHRvIHRoZSByZXZpZXcgbWFpbGluZyBsaXN0LgogICAgICAgIAo8L3A+ CjxhIG5hbWU9ImFuY2hvcjQ4Ij48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlv dXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249 InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZu YnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uMTEuMi4xIj48 L2E+PGgzPjExLjIuMS4mbmJzcDsKUmVnaXN0cmF0aW9uIFRlbXBsYXRlPC9oMz4KCjxwPgogICAg ICAgICAgICA8L3A+CjxibG9ja3F1b3RlIGNsYXNzPSJ0ZXh0Ij48ZGw+CjxkdD5QYXJhbWV0ZXIg bmFtZTo8L2R0Pgo8ZGQ+CiAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgIFRoZSBuYW1l IHJlcXVlc3RlZCAoZS5nLiwgImV4YW1wbGUiKS4KICAgICAgICAgICAgICAKPC9kZD4KPGR0PlBh cmFtZXRlciB1c2FnZSBsb2NhdGlvbjo8L2R0Pgo8ZGQ+CiAgICAgICAgICAgICAgICAKICAgICAg ICAgICAgICAgIFRoZSBsb2NhdGlvbihzKSB3aGVyZSBwYXJhbWV0ZXIgY2FuIGJlIHVzZWQuIFRo ZSBwb3NzaWJsZSBsb2NhdGlvbnMgYXJlOgogICAgICAgICAgICAgICAgYXV0aG9yaXphdGlvbiBy ZXF1ZXN0LCBhdXRob3JpemF0aW9uIHJlc3BvbnNlLCB0b2tlbiByZXF1ZXN0LCBvciB0b2tlbiBy ZXNwb25zZS4KICAgICAgICAgICAgICAKPC9kZD4KPGR0PkNoYW5nZSBjb250cm9sbGVyOjwvZHQ+ CjxkZD4KICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgRm9yIHN0YW5kYXJkcy10cmFj ayBSRkNzLCBzdGF0ZSAiSUVURiIuIEZvciBvdGhlcnMsIGdpdmUgdGhlIG5hbWUgb2YgdGhlCiAg ICAgICAgICAgICAgICByZXNwb25zaWJsZSBwYXJ0eS4gT3RoZXIgZGV0YWlscyAoZS5nLiwgcG9z dGFsIGFkZHJlc3MsIGUtbWFpbCBhZGRyZXNzLCBob21lIHBhZ2UKICAgICAgICAgICAgICAgIFVS SSkgbWF5IGFsc28gYmUgaW5jbHVkZWQuCiAgICAgICAgICAgICAgCjwvZGQ+CjxkdD5TcGVjaWZp Y2F0aW9uIGRvY3VtZW50KHMpOjwvZHQ+CjxkZD4KICAgICAgICAgICAgICAgIAogICAgICAgICAg ICAgICAgUmVmZXJlbmNlIHRvIHRoZSBkb2N1bWVudCB0aGF0IHNwZWNpZmllcyB0aGUgcGFyYW1l dGVyLCBwcmVmZXJhYmx5IGluY2x1ZGluZyBhIFVSSSB0aGF0CiAgICAgICAgICAgICAgICBjYW4g YmUgdXNlZCB0byByZXRyaWV2ZSBhIGNvcHkgb2YgdGhlIGRvY3VtZW50LiBBbiBpbmRpY2F0aW9u IG9mIHRoZSByZWxldmFudAogICAgICAgICAgICAgICAgc2VjdGlvbnMgbWF5IGFsc28gYmUgaW5j bHVkZWQsIGJ1dCBpcyBub3QgcmVxdWlyZWQuCiAgICAgICAgICAgICAgCjwvZGQ+CjwvZGw+PC9i bG9ja3F1b3RlPjxwPgogICAgICAgICAgCjwvcD4KPGEgbmFtZT0iYW5jaG9yNDkiPjwvYT48YnIg Lz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFj aW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1 ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8 YSBuYW1lPSJyZmMuc2VjdGlvbi4xMS4yLjIiPjwvYT48aDM+MTEuMi4yLiZuYnNwOwpJbml0aWFs IFJlZ2lzdHJ5IENvbnRlbnRzPC9oMz4KCjxwPgogICAgICAgICAgICBUaGUgT0F1dGggUGFyYW1l dGVycyBSZWdpc3RyeSdzIGluaXRpYWwgY29udGVudHMgYXJlOgogICAgICAgICAgCjwvcD4KPHA+ CiAgICAgICAgICAgIDwvcD4KPHVsIGNsYXNzPSJ0ZXh0Ij4KPGxpPgogICAgICAgICAgICAgICAg UGFyYW1ldGVyIG5hbWU6IGNsaWVudF9pZAogICAgICAgICAgICAgIAo8L2xpPgo8bGk+CiAgICAg ICAgICAgICAgICBQYXJhbWV0ZXIgdXNhZ2UgbG9jYXRpb246IGF1dGhvcml6YXRpb24gcmVxdWVz dCwgdG9rZW4gcmVxdWVzdAogICAgICAgICAgICAgIAo8L2xpPgo8bGk+CiAgICAgICAgICAgICAg ICBDaGFuZ2UgY29udHJvbGxlcjogSUVURgogICAgICAgICAgICAgIAo8L2xpPgo8bGk+CiAgICAg ICAgICAgICAgICBTcGVjaWZpY2F0aW9uIGRvY3VtZW50KHMpOiBbWyB0aGlzIGRvY3VtZW50IF1d CiAgICAgICAgICAgICAgCjwvbGk+CjwvdWw+PHA+CiAgICAgICAgICAKPC9wPgo8cD4KICAgICAg ICAgICAgPC9wPgo8dWwgY2xhc3M9InRleHQiPgo8bGk+CiAgICAgICAgICAgICAgICBQYXJhbWV0 ZXIgbmFtZTogY2xpZW50X3NlY3JldAogICAgICAgICAgICAgIAo8L2xpPgo8bGk+CiAgICAgICAg ICAgICAgICBQYXJhbWV0ZXIgdXNhZ2UgbG9jYXRpb246IHRva2VuIHJlcXVlc3QKICAgICAgICAg ICAgICAKPC9saT4KPGxpPgogICAgICAgICAgICAgICAgQ2hhbmdlIGNvbnRyb2xsZXI6IElFVEYK ICAgICAgICAgICAgICAKPC9saT4KPGxpPgogICAgICAgICAgICAgICAgU3BlY2lmaWNhdGlvbiBk b2N1bWVudChzKTogW1sgdGhpcyBkb2N1bWVudCBdXQogICAgICAgICAgICAgIAo8L2xpPgo8L3Vs PjxwPgogICAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICAgIDwvcD4KPHVsIGNsYXNzPSJ0ZXh0 Ij4KPGxpPgogICAgICAgICAgICAgICAgUGFyYW1ldGVyIG5hbWU6IHJlc3BvbnNlX3R5cGUKICAg ICAgICAgICAgICAKPC9saT4KPGxpPgogICAgICAgICAgICAgICAgUGFyYW1ldGVyIHVzYWdlIGxv Y2F0aW9uOiBhdXRob3JpemF0aW9uIHJlcXVlc3QKICAgICAgICAgICAgICAKPC9saT4KPGxpPgog ICAgICAgICAgICAgICAgQ2hhbmdlIGNvbnRyb2xsZXI6IElFVEYKICAgICAgICAgICAgICAKPC9s aT4KPGxpPgogICAgICAgICAgICAgICAgU3BlY2lmaWNhdGlvbiBkb2N1bWVudChzKTogW1sgdGhp cyBkb2N1bWVudCBdXQogICAgICAgICAgICAgIAo8L2xpPgo8L3VsPjxwPgogICAgICAgICAgCjwv cD4KPHA+CiAgICAgICAgICAgIDwvcD4KPHVsIGNsYXNzPSJ0ZXh0Ij4KPGxpPgogICAgICAgICAg ICAgICAgUGFyYW1ldGVyIG5hbWU6IHJlZGlyZWN0X3VyaQogICAgICAgICAgICAgIAo8L2xpPgo8 bGk+CiAgICAgICAgICAgICAgICBQYXJhbWV0ZXIgdXNhZ2UgbG9jYXRpb246IGF1dGhvcml6YXRp b24gcmVxdWVzdCwgdG9rZW4gcmVxdWVzdAogICAgICAgICAgICAgIAo8L2xpPgo8bGk+CiAgICAg ICAgICAgICAgICBDaGFuZ2UgY29udHJvbGxlcjogSUVURgogICAgICAgICAgICAgIAo8L2xpPgo8 bGk+CiAgICAgICAgICAgICAgICBTcGVjaWZpY2F0aW9uIGRvY3VtZW50KHMpOiBbWyB0aGlzIGRv Y3VtZW50IF1dCiAgICAgICAgICAgICAgCjwvbGk+CjwvdWw+PHA+CiAgICAgICAgICAKPC9wPgo8 cD4KICAgICAgICAgICAgPC9wPgo8dWwgY2xhc3M9InRleHQiPgo8bGk+CiAgICAgICAgICAgICAg ICBQYXJhbWV0ZXIgbmFtZTogc2NvcGUKICAgICAgICAgICAgICAKPC9saT4KPGxpPgogICAgICAg ICAgICAgICAgUGFyYW1ldGVyIHVzYWdlIGxvY2F0aW9uOiBhdXRob3JpemF0aW9uIHJlcXVlc3Qs IGF1dGhvcml6YXRpb24gcmVzcG9uc2UsIHRva2VuCiAgICAgICAgICAgICAgICByZXF1ZXN0LCB0 b2tlbiByZXNwb25zZQogICAgICAgICAgICAgIAo8L2xpPgo8bGk+CiAgICAgICAgICAgICAgICBD aGFuZ2UgY29udHJvbGxlcjogSUVURgogICAgICAgICAgICAgIAo8L2xpPgo8bGk+CiAgICAgICAg ICAgICAgICBTcGVjaWZpY2F0aW9uIGRvY3VtZW50KHMpOiBbWyB0aGlzIGRvY3VtZW50IF1dCiAg ICAgICAgICAgICAgCjwvbGk+CjwvdWw+PHA+CiAgICAgICAgICAKPC9wPgo8cD4KICAgICAgICAg ICAgPC9wPgo8dWwgY2xhc3M9InRleHQiPgo8bGk+CiAgICAgICAgICAgICAgICBQYXJhbWV0ZXIg bmFtZTogc3RhdGUKICAgICAgICAgICAgICAKPC9saT4KPGxpPgogICAgICAgICAgICAgICAgUGFy YW1ldGVyIHVzYWdlIGxvY2F0aW9uOiBhdXRob3JpemF0aW9uIHJlcXVlc3QsIGF1dGhvcml6YXRp b24gcmVzcG9uc2UKICAgICAgICAgICAgICAKPC9saT4KPGxpPgogICAgICAgICAgICAgICAgQ2hh bmdlIGNvbnRyb2xsZXI6IElFVEYKICAgICAgICAgICAgICAKPC9saT4KPGxpPgogICAgICAgICAg ICAgICAgU3BlY2lmaWNhdGlvbiBkb2N1bWVudChzKTogW1sgdGhpcyBkb2N1bWVudCBdXQogICAg ICAgICAgICAgIAo8L2xpPgo8L3VsPjxwPgogICAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICAg IDwvcD4KPHVsIGNsYXNzPSJ0ZXh0Ij4KPGxpPgogICAgICAgICAgICAgICAgUGFyYW1ldGVyIG5h bWU6IGNvZGUKICAgICAgICAgICAgICAKPC9saT4KPGxpPgogICAgICAgICAgICAgICAgUGFyYW1l dGVyIHVzYWdlIGxvY2F0aW9uOiBhdXRob3JpemF0aW9uIHJlc3BvbnNlLCB0b2tlbiByZXF1ZXN0 CiAgICAgICAgICAgICAgCjwvbGk+CjxsaT4KICAgICAgICAgICAgICAgIENoYW5nZSBjb250cm9s bGVyOiBJRVRGCiAgICAgICAgICAgICAgCjwvbGk+CjxsaT4KICAgICAgICAgICAgICAgIFNwZWNp ZmljYXRpb24gZG9jdW1lbnQocyk6IFtbIHRoaXMgZG9jdW1lbnQgXV0KICAgICAgICAgICAgICAK PC9saT4KPC91bD48cD4KICAgICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgICA8L3A+Cjx1bCBj bGFzcz0idGV4dCI+CjxsaT4KICAgICAgICAgICAgICAgIFBhcmFtZXRlciBuYW1lOiBlcnJvcl9k ZXNjcmlwdGlvbgogICAgICAgICAgICAgIAo8L2xpPgo8bGk+CiAgICAgICAgICAgICAgICBQYXJh bWV0ZXIgdXNhZ2UgbG9jYXRpb246IGF1dGhvcml6YXRpb24gcmVzcG9uc2UsIHRva2VuIHJlc3Bv bnNlCiAgICAgICAgICAgICAgCjwvbGk+CjxsaT4KICAgICAgICAgICAgICAgIENoYW5nZSBjb250 cm9sbGVyOiBJRVRGCiAgICAgICAgICAgICAgCjwvbGk+CjxsaT4KICAgICAgICAgICAgICAgIFNw ZWNpZmljYXRpb24gZG9jdW1lbnQocyk6IFtbIHRoaXMgZG9jdW1lbnQgXV0KICAgICAgICAgICAg ICAKPC9saT4KPC91bD48cD4KICAgICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgICA8L3A+Cjx1 bCBjbGFzcz0idGV4dCI+CjxsaT4KICAgICAgICAgICAgICAgIFBhcmFtZXRlciBuYW1lOiBlcnJv cl91cmkKICAgICAgICAgICAgICAKPC9saT4KPGxpPgogICAgICAgICAgICAgICAgUGFyYW1ldGVy IHVzYWdlIGxvY2F0aW9uOiBhdXRob3JpemF0aW9uIHJlc3BvbnNlLCB0b2tlbiByZXNwb25zZQog ICAgICAgICAgICAgIAo8L2xpPgo8bGk+CiAgICAgICAgICAgICAgICBDaGFuZ2UgY29udHJvbGxl cjogSUVURgogICAgICAgICAgICAgIAo8L2xpPgo8bGk+CiAgICAgICAgICAgICAgICBTcGVjaWZp Y2F0aW9uIGRvY3VtZW50KHMpOiBbWyB0aGlzIGRvY3VtZW50IF1dCiAgICAgICAgICAgICAgCjwv bGk+CjwvdWw+PHA+CiAgICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgICAgPC9wPgo8dWwgY2xh c3M9InRleHQiPgo8bGk+CiAgICAgICAgICAgICAgICBQYXJhbWV0ZXIgbmFtZTogZ3JhbnRfdHlw ZQogICAgICAgICAgICAgIAo8L2xpPgo8bGk+CiAgICAgICAgICAgICAgICBQYXJhbWV0ZXIgdXNh Z2UgbG9jYXRpb246IHRva2VuIHJlcXVlc3QKICAgICAgICAgICAgICAKPC9saT4KPGxpPgogICAg ICAgICAgICAgICAgQ2hhbmdlIGNvbnRyb2xsZXI6IElFVEYKICAgICAgICAgICAgICAKPC9saT4K PGxpPgogICAgICAgICAgICAgICAgU3BlY2lmaWNhdGlvbiBkb2N1bWVudChzKTogW1sgdGhpcyBk b2N1bWVudCBdXQogICAgICAgICAgICAgIAo8L2xpPgo8L3VsPjxwPgogICAgICAgICAgCjwvcD4K PHA+CiAgICAgICAgICAgIDwvcD4KPHVsIGNsYXNzPSJ0ZXh0Ij4KPGxpPgogICAgICAgICAgICAg ICAgUGFyYW1ldGVyIG5hbWU6IGFjY2Vzc190b2tlbgogICAgICAgICAgICAgIAo8L2xpPgo8bGk+ CiAgICAgICAgICAgICAgICBQYXJhbWV0ZXIgdXNhZ2UgbG9jYXRpb246IGF1dGhvcml6YXRpb24g cmVzcG9uc2UsIHRva2VuIHJlc3BvbnNlCiAgICAgICAgICAgICAgCjwvbGk+CjxsaT4KICAgICAg ICAgICAgICAgIENoYW5nZSBjb250cm9sbGVyOiBJRVRGCiAgICAgICAgICAgICAgCjwvbGk+Cjxs aT4KICAgICAgICAgICAgICAgIFNwZWNpZmljYXRpb24gZG9jdW1lbnQocyk6IFtbIHRoaXMgZG9j dW1lbnQgXV0KICAgICAgICAgICAgICAKPC9saT4KPC91bD48cD4KICAgICAgICAgIAo8L3A+Cjxw PgogICAgICAgICAgICA8L3A+Cjx1bCBjbGFzcz0idGV4dCI+CjxsaT4KICAgICAgICAgICAgICAg IFBhcmFtZXRlciBuYW1lOiB0b2tlbl90eXBlCiAgICAgICAgICAgICAgCjwvbGk+CjxsaT4KICAg ICAgICAgICAgICAgIFBhcmFtZXRlciB1c2FnZSBsb2NhdGlvbjogYXV0aG9yaXphdGlvbiByZXNw b25zZSwgdG9rZW4gcmVzcG9uc2UKICAgICAgICAgICAgICAKPC9saT4KPGxpPgogICAgICAgICAg ICAgICAgQ2hhbmdlIGNvbnRyb2xsZXI6IElFVEYKICAgICAgICAgICAgICAKPC9saT4KPGxpPgog ICAgICAgICAgICAgICAgU3BlY2lmaWNhdGlvbiBkb2N1bWVudChzKTogW1sgdGhpcyBkb2N1bWVu dCBdXQogICAgICAgICAgICAgIAo8L2xpPgo8L3VsPjxwPgogICAgICAgICAgCjwvcD4KPHA+CiAg ICAgICAgICAgIDwvcD4KPHVsIGNsYXNzPSJ0ZXh0Ij4KPGxpPgogICAgICAgICAgICAgICAgUGFy YW1ldGVyIG5hbWU6IGV4cGlyZXNfaW4KICAgICAgICAgICAgICAKPC9saT4KPGxpPgogICAgICAg ICAgICAgICAgUGFyYW1ldGVyIHVzYWdlIGxvY2F0aW9uOiBhdXRob3JpemF0aW9uIHJlc3BvbnNl LCB0b2tlbiByZXNwb25zZQogICAgICAgICAgICAgIAo8L2xpPgo8bGk+CiAgICAgICAgICAgICAg ICBDaGFuZ2UgY29udHJvbGxlcjogSUVURgogICAgICAgICAgICAgIAo8L2xpPgo8bGk+CiAgICAg ICAgICAgICAgICBTcGVjaWZpY2F0aW9uIGRvY3VtZW50KHMpOiBbWyB0aGlzIGRvY3VtZW50IF1d CiAgICAgICAgICAgICAgCjwvbGk+CjwvdWw+PHA+CiAgICAgICAgICAKPC9wPgo8cD4KICAgICAg ICAgICAgPC9wPgo8dWwgY2xhc3M9InRleHQiPgo8bGk+CiAgICAgICAgICAgICAgICBQYXJhbWV0 ZXIgbmFtZTogdXNlcm5hbWUKICAgICAgICAgICAgICAKPC9saT4KPGxpPgogICAgICAgICAgICAg ICAgUGFyYW1ldGVyIHVzYWdlIGxvY2F0aW9uOiB0b2tlbiByZXF1ZXN0CiAgICAgICAgICAgICAg CjwvbGk+CjxsaT4KICAgICAgICAgICAgICAgIENoYW5nZSBjb250cm9sbGVyOiBJRVRGCiAgICAg ICAgICAgICAgCjwvbGk+CjxsaT4KICAgICAgICAgICAgICAgIFNwZWNpZmljYXRpb24gZG9jdW1l bnQocyk6IFtbIHRoaXMgZG9jdW1lbnQgXV0KICAgICAgICAgICAgICAKPC9saT4KPC91bD48cD4K ICAgICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgICA8L3A+Cjx1bCBjbGFzcz0idGV4dCI+Cjxs aT4KICAgICAgICAgICAgICAgIFBhcmFtZXRlciBuYW1lOiBwYXNzd29yZAogICAgICAgICAgICAg IAo8L2xpPgo8bGk+CiAgICAgICAgICAgICAgICBQYXJhbWV0ZXIgdXNhZ2UgbG9jYXRpb246IHRv a2VuIHJlcXVlc3QKICAgICAgICAgICAgICAKPC9saT4KPGxpPgogICAgICAgICAgICAgICAgQ2hh bmdlIGNvbnRyb2xsZXI6IElFVEYKICAgICAgICAgICAgICAKPC9saT4KPGxpPgogICAgICAgICAg ICAgICAgU3BlY2lmaWNhdGlvbiBkb2N1bWVudChzKTogW1sgdGhpcyBkb2N1bWVudCBdXQogICAg ICAgICAgICAgIAo8L2xpPgo8L3VsPjxwPgogICAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICAg IDwvcD4KPHVsIGNsYXNzPSJ0ZXh0Ij4KPGxpPgogICAgICAgICAgICAgICAgUGFyYW1ldGVyIG5h bWU6IHJlZnJlc2hfdG9rZW4KICAgICAgICAgICAgICAKPC9saT4KPGxpPgogICAgICAgICAgICAg ICAgUGFyYW1ldGVyIHVzYWdlIGxvY2F0aW9uOiB0b2tlbiByZXF1ZXN0LCB0b2tlbiByZXNwb25z ZQogICAgICAgICAgICAgIAo8L2xpPgo8bGk+CiAgICAgICAgICAgICAgICBDaGFuZ2UgY29udHJv bGxlcjogSUVURgogICAgICAgICAgICAgIAo8L2xpPgo8bGk+CiAgICAgICAgICAgICAgICBTcGVj aWZpY2F0aW9uIGRvY3VtZW50KHMpOiBbWyB0aGlzIGRvY3VtZW50IF1dCiAgICAgICAgICAgICAg CjwvbGk+CjwvdWw+PHA+CiAgICAgICAgICAKPC9wPgo8YSBuYW1lPSJyZXNwb25zZS10eXBlLXJl Z2lzdHJ5Ij48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRk aW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+ PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3Rk PjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uMTEuMyI+PC9hPjxoMz4xMS4zLiZu YnNwOwpUaGUgT0F1dGggQXV0aG9yaXphdGlvbiBFbmRwb2ludCBSZXNwb25zZSBUeXBlIFJlZ2lz dHJ5PC9oMz4KCjxwPgogICAgICAgICAgVGhpcyBzcGVjaWZpY2F0aW9uIGVzdGFibGlzaGVzIHRo ZSBPQXV0aCBhdXRob3JpemF0aW9uIGVuZHBvaW50IHJlc3BvbnNlIHR5cGUgcmVnaXN0cnkuCiAg ICAgICAgCjwvcD4KPHA+CiAgICAgICAgICAgIEFkZGl0aW9uYWwgcmVzcG9uc2UgdHlwZSBmb3Ig dXNlIHdpdGggdGhlIGF1dGhvcml6YXRpb24gZW5kcG9pbnQgYXJlIHJlZ2lzdGVyZWQgd2l0aCBh CiAgICAgICAgICAgIFNwZWNpZmljYXRpb24gUmVxdWlyZWQgKDxhIGNsYXNzPSdpbmZvJyBocmVm PScjUkZDNTIyNic+W1JGQzUyMjZdPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPk5h cnRlbiwgVC4gYW5kIEguIEFsdmVzdHJhbmQsICZsZHF1bztHdWlkZWxpbmVzIGZvciBXcml0aW5n IGFuIElBTkEgQ29uc2lkZXJhdGlvbnMgU2VjdGlvbiBpbiBSRkNzLCZyZHF1bzsgTWF5Jm5ic3A7 MjAwOC48L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+KSBhZnRlciBhIHR3byB3ZWVrIHJldmlldyBw ZXJpb2Qgb24KICAgICAgICAgICAgdGhlIFtUQkRdQGlldGYub3JnIG1haWxpbmcgbGlzdCwgb24g dGhlIGFkdmljZSBvZiBvbmUgb3IgbW9yZSBEZXNpZ25hdGVkIEV4cGVydHMuCiAgICAgICAgICAg IEhvd2V2ZXIsIHRvIGFsbG93IGZvciB0aGUgYWxsb2NhdGlvbiBvZiB2YWx1ZXMgcHJpb3IgdG8g cHVibGljYXRpb24sIHRoZSBEZXNpZ25hdGVkCiAgICAgICAgICAgIEV4cGVydChzKSBtYXkgYXBw cm92ZSByZWdpc3RyYXRpb24gb25jZSB0aGV5IGFyZSBzYXRpc2ZpZWQgdGhhdCBzdWNoIGEgc3Bl Y2lmaWNhdGlvbgogICAgICAgICAgICB3aWxsIGJlIHB1Ymxpc2hlZC4KICAgICAgICAgIAo8L3A+ CjxwPgogICAgICAgICAgICBSZWdpc3RyYXRpb24gcmVxdWVzdHMgbXVzdCBiZSBzZW50IHRvIHRo ZSBbVEJEXUBpZXRmLm9yZyBtYWlsaW5nIGxpc3QgZm9yIHJldmlldyBhbmQKICAgICAgICAgICAg Y29tbWVudCwgd2l0aCBhbiBhcHByb3ByaWF0ZSBzdWJqZWN0IChlLmcuLCAiUmVxdWVzdCBmb3Ig cmVzcG9uc2UgdHlwZTogZXhhbXBsZSIpLgogICAgICAgICAgICBbWyBOb3RlIHRvIFJGQy1FRElU T1I6IFRoZSBuYW1lIG9mIHRoZSBtYWlsaW5nIGxpc3Qgc2hvdWxkIGJlIGRldGVybWluZWQgaW4g Y29uc3VsdGF0aW9uCiAgICAgICAgICAgIHdpdGggdGhlIElFU0cgYW5kIElBTkEuIFN1Z2dlc3Rl ZCBuYW1lOiBvYXV0aC1leHQtcmV2aWV3LiBdXQogICAgICAgICAgCjwvcD4KPHA+CiAgICAgICAg ICAgIFdpdGhpbiB0aGUgcmV2aWV3IHBlcmlvZCwgdGhlIERlc2lnbmF0ZWQgRXhwZXJ0KHMpIHdp bGwgZWl0aGVyIGFwcHJvdmUgb3IKICAgICAgICAgICAgZGVueSB0aGUgcmVnaXN0cmF0aW9uIHJl cXVlc3QsIGNvbW11bmljYXRpbmcgdGhpcyBkZWNpc2lvbiB0byB0aGUgcmV2aWV3IGxpc3QgYW5k IElBTkEuCiAgICAgICAgICAgIERlbmlhbHMgc2hvdWxkIGluY2x1ZGUgYW4gZXhwbGFuYXRpb24g YW5kLCBpZiBhcHBsaWNhYmxlLCBzdWdnZXN0aW9ucyBhcyB0byBob3cgdG8gbWFrZQogICAgICAg ICAgICB0aGUgcmVxdWVzdCBzdWNjZXNzZnVsLgogICAgICAgICAgCjwvcD4KPHA+CiAgICAgICAg ICAgIElBTkEgbXVzdCBvbmx5IGFjY2VwdCByZWdpc3RyeSB1cGRhdGVzIGZyb20gdGhlIERlc2ln bmF0ZWQgRXhwZXJ0KHMpLCBhbmQgc2hvdWxkIGRpcmVjdAogICAgICAgICAgICBhbGwgcmVxdWVz dHMgZm9yIHJlZ2lzdHJhdGlvbiB0byB0aGUgcmV2aWV3IG1haWxpbmcgbGlzdC4KICAgICAgICAg IAo8L3A+CjxhIG5hbWU9ImFuY2hvcjUwIj48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5 PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIg YWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNw O1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uMTEu My4xIj48L2E+PGgzPjExLjMuMS4mbmJzcDsKUmVnaXN0cmF0aW9uIFRlbXBsYXRlPC9oMz4KCjxw PgogICAgICAgICAgICA8L3A+CjxibG9ja3F1b3RlIGNsYXNzPSJ0ZXh0Ij48ZGw+CjxkdD5SZXNw b25zZSB0eXBlIG5hbWU6PC9kdD4KPGRkPgogICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAg ICBUaGUgbmFtZSByZXF1ZXN0ZWQgKGUuZy4sICJleGFtcGxlIikuCiAgICAgICAgICAgICAgCjwv ZGQ+CjxkdD5DaGFuZ2UgY29udHJvbGxlcjo8L2R0Pgo8ZGQ+CiAgICAgICAgICAgICAgICAKICAg ICAgICAgICAgICAgIEZvciBzdGFuZGFyZHMtdHJhY2sgUkZDcywgc3RhdGUgIklFVEYiLiBGb3Ig b3RoZXJzLCBnaXZlIHRoZSBuYW1lIG9mIHRoZQogICAgICAgICAgICAgICAgcmVzcG9uc2libGUg cGFydHkuIE90aGVyIGRldGFpbHMgKGUuZy4sIHBvc3RhbCBhZGRyZXNzLCBlLW1haWwgYWRkcmVz cywgaG9tZSBwYWdlCiAgICAgICAgICAgICAgICBVUkkpIG1heSBhbHNvIGJlIGluY2x1ZGVkLgog ICAgICAgICAgICAgIAo8L2RkPgo8ZHQ+U3BlY2lmaWNhdGlvbiBkb2N1bWVudChzKTo8L2R0Pgo8 ZGQ+CiAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgIFJlZmVyZW5jZSB0byB0aGUgZG9j dW1lbnQgdGhhdCBzcGVjaWZpZXMgdGhlIHR5cGUsIHByZWZlcmFibHkgaW5jbHVkaW5nIGEgVVJJ IHRoYXQKICAgICAgICAgICAgICAgIGNhbiBiZSB1c2VkIHRvIHJldHJpZXZlIGEgY29weSBvZiB0 aGUgZG9jdW1lbnQuIEFuIGluZGljYXRpb24gb2YgdGhlIHJlbGV2YW50CiAgICAgICAgICAgICAg ICBzZWN0aW9ucyBtYXkgYWxzbyBiZSBpbmNsdWRlZCwgYnV0IGlzIG5vdCByZXF1aXJlZC4KICAg ICAgICAgICAgICAKPC9kZD4KPC9kbD48L2Jsb2NrcXVvdGU+PHA+CiAgICAgICAgICAKPC9wPgo8 YSBuYW1lPSJhbmNob3I1MSI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0 IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJy aWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJz cDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLjExLjMuMiI+PC9h PjxoMz4xMS4zLjIuJm5ic3A7CkluaXRpYWwgUmVnaXN0cnkgQ29udGVudHM8L2gzPgoKPHA+CiAg ICAgICAgICAgIFRoZSBPQXV0aCBBdXRob3JpemF0aW9uIEVuZHBvaW50IFJlc3BvbnNlIFR5cGUg UmVnaXN0cnkncyBpbml0aWFsIGNvbnRlbnRzIGFyZToKICAgICAgICAgIAo8L3A+CjxwPgogICAg ICAgICAgICA8L3A+Cjx1bCBjbGFzcz0idGV4dCI+CjxsaT4KICAgICAgICAgICAgICAgIFJlc3Bv bnNlIHR5cGUgbmFtZTogY29kZQogICAgICAgICAgICAgIAo8L2xpPgo8bGk+CiAgICAgICAgICAg ICAgICBDaGFuZ2UgY29udHJvbGxlcjogSUVURgogICAgICAgICAgICAgIAo8L2xpPgo8bGk+CiAg ICAgICAgICAgICAgICBTcGVjaWZpY2F0aW9uIGRvY3VtZW50KHMpOiBbWyB0aGlzIGRvY3VtZW50 IF1dCiAgICAgICAgICAgICAgCjwvbGk+CjwvdWw+PHA+CiAgICAgICAgICAKPC9wPgo8cD4KICAg ICAgICAgICAgPC9wPgo8dWwgY2xhc3M9InRleHQiPgo8bGk+CiAgICAgICAgICAgICAgICBSZXNw b25zZSB0eXBlIG5hbWU6IHRva2VuCiAgICAgICAgICAgICAgCjwvbGk+CjxsaT4KICAgICAgICAg ICAgICAgIENoYW5nZSBjb250cm9sbGVyOiBJRVRGCiAgICAgICAgICAgICAgCjwvbGk+CjxsaT4K ICAgICAgICAgICAgICAgIFNwZWNpZmljYXRpb24gZG9jdW1lbnQocyk6IFtbIHRoaXMgZG9jdW1l bnQgXV0KICAgICAgICAgICAgICAKPC9saT4KPC91bD48cD4KICAgICAgICAgIAo8L3A+CjxhIG5h bWU9ImVycm9yLXJlZ2lzdHJ5Ij48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlv dXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249 InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZu YnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uMTEuNCI+PC9h PjxoMz4xMS40LiZuYnNwOwpUaGUgT0F1dGggRXh0ZW5zaW9ucyBFcnJvciBSZWdpc3RyeTwvaDM+ Cgo8cD4KICAgICAgICAgIFRoaXMgc3BlY2lmaWNhdGlvbiBlc3RhYmxpc2hlcyB0aGUgT0F1dGgg ZXh0ZW5zaW9ucyBlcnJvciByZWdpc3RyeS4KICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgIEFk ZGl0aW9uYWwgZXJyb3IgY29kZXMgdXNlZCB0b2dldGhlciB3aXRoIG90aGVyIHByb3RvY29sIGV4 dGVuc2lvbnMgKGkuZS4gZXh0ZW5zaW9uIGdyYW50CiAgICAgICAgICB0eXBlcywgYWNjZXNzIHRv a2VuIHR5cGVzLCBvciBleHRlbnNpb24gcGFyYW1ldGVycykgYXJlIHJlZ2lzdGVyZWQgd2l0aCBh IFNwZWNpZmljYXRpb24KICAgICAgICAgIFJlcXVpcmVkICg8YSBjbGFzcz0naW5mbycgaHJlZj0n I1JGQzUyMjYnPltSRkM1MjI2XTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5OYXJ0 ZW4sIFQuIGFuZCBILiBBbHZlc3RyYW5kLCAmbGRxdW87R3VpZGVsaW5lcyBmb3IgV3JpdGluZyBh biBJQU5BIENvbnNpZGVyYXRpb25zIFNlY3Rpb24gaW4gUkZDcywmcmRxdW87IE1heSZuYnNwOzIw MDguPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPikgYWZ0ZXIgYSB0d28gd2VlayByZXZpZXcgcGVy aW9kIG9uIHRoZQogICAgICAgICAgW1RCRF1AaWV0Zi5vcmcgbWFpbGluZyBsaXN0LCBvbiB0aGUg YWR2aWNlIG9mIG9uZSBvciBtb3JlIERlc2lnbmF0ZWQgRXhwZXJ0cy4gSG93ZXZlciwgdG8KICAg ICAgICAgIGFsbG93IGZvciB0aGUgYWxsb2NhdGlvbiBvZiB2YWx1ZXMgcHJpb3IgdG8gcHVibGlj YXRpb24sIHRoZSBEZXNpZ25hdGVkIEV4cGVydChzKSBtYXkKICAgICAgICAgIGFwcHJvdmUgcmVn aXN0cmF0aW9uIG9uY2UgdGhleSBhcmUgc2F0aXNmaWVkIHRoYXQgc3VjaCBhIHNwZWNpZmljYXRp b24gd2lsbCBiZSBwdWJsaXNoZWQuCiAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICBSZWdpc3Ry YXRpb24gcmVxdWVzdHMgbXVzdCBiZSBzZW50IHRvIHRoZSBbVEJEXUBpZXRmLm9yZyBtYWlsaW5n IGxpc3QgZm9yIHJldmlldyBhbmQKICAgICAgICAgIGNvbW1lbnQsIHdpdGggYW4gYXBwcm9wcmlh dGUgc3ViamVjdCAoZS5nLiwgIlJlcXVlc3QgZm9yIGVycm9yIGNvZGU6IGV4YW1wbGUiKS4KICAg ICAgICAgIFtbIE5vdGUgdG8gUkZDLUVESVRPUjogVGhlIG5hbWUgb2YgdGhlIG1haWxpbmcgbGlz dCBzaG91bGQgYmUgZGV0ZXJtaW5lZCBpbiBjb25zdWx0YXRpb24KICAgICAgICAgIHdpdGggdGhl IElFU0cgYW5kIElBTkEuIFN1Z2dlc3RlZCBuYW1lOiBvYXV0aC1leHQtcmV2aWV3LiBdXQogICAg ICAgIAo8L3A+CjxwPgogICAgICAgICAgV2l0aGluIHRoZSByZXZpZXcgcGVyaW9kLCB0aGUgRGVz aWduYXRlZCBFeHBlcnQocykgd2lsbCBlaXRoZXIgYXBwcm92ZSBvcgogICAgICAgICAgZGVueSB0 aGUgcmVnaXN0cmF0aW9uIHJlcXVlc3QsIGNvbW11bmljYXRpbmcgdGhpcyBkZWNpc2lvbiB0byB0 aGUgcmV2aWV3IGxpc3QgYW5kIElBTkEuCiAgICAgICAgICBEZW5pYWxzIHNob3VsZCBpbmNsdWRl IGFuIGV4cGxhbmF0aW9uIGFuZCwgaWYgYXBwbGljYWJsZSwgc3VnZ2VzdGlvbnMgYXMgdG8gaG93 IHRvIG1ha2UKICAgICAgICAgIHRoZSByZXF1ZXN0IHN1Y2Nlc3NmdWwuCiAgICAgICAgCjwvcD4K PHA+CiAgICAgICAgICBJQU5BIG11c3Qgb25seSBhY2NlcHQgcmVnaXN0cnkgdXBkYXRlcyBmcm9t IHRoZSBEZXNpZ25hdGVkIEV4cGVydChzKSwgYW5kIHNob3VsZCBkaXJlY3QKICAgICAgICAgIGFs bCByZXF1ZXN0cyBmb3IgcmVnaXN0cmF0aW9uIHRvIHRoZSByZXZpZXcgbWFpbGluZyBsaXN0Lgog ICAgICAgIAo8L3A+CjxhIG5hbWU9ImFuY2hvcjUyIj48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBz dW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRP Q2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2Mi PiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rp b24uMTEuNC4xIj48L2E+PGgzPjExLjQuMS4mbmJzcDsKUmVnaXN0cmF0aW9uIFRlbXBsYXRlPC9o Mz4KCjxwPgogICAgICAgICAgICA8L3A+CjxibG9ja3F1b3RlIGNsYXNzPSJ0ZXh0Ij48ZGw+Cjxk dD5FcnJvciBuYW1lOjwvZHQ+CjxkZD4KICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAg VGhlIG5hbWUgcmVxdWVzdGVkIChlLmcuLCAiZXhhbXBsZSIpLgogICAgICAgICAgICAgIAo8L2Rk Pgo8ZHQ+RXJyb3IgdXNhZ2UgbG9jYXRpb246PC9kdD4KPGRkPgogICAgICAgICAgICAgICAgCiAg ICAgICAgICAgICAgICBUaGUgbG9jYXRpb24ocykgd2hlcmUgdGhlIGVycm9yIGNhbiBiZSB1c2Vk LiBUaGUgcG9zc2libGUgbG9jYXRpb25zIGFyZToKICAgICAgICAgICAgICAgIGF1dGhvcml6YXRp b24gY29kZSBncmFudCBlcnJvciByZXNwb25zZSAoPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNjb2Rl LWF1dGh6LWVycm9yJz5TZWN0aW9uJm5ic3A7NC4xLjIuMTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNs YXNzPSdpbmZvJz5FcnJvciBSZXNwb25zZTwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4pLAogICAg ICAgICAgICAgICAgaW1wbGljaXQgZ3JhbnQgZXJyb3IgcmVzcG9uc2UgKDxhIGNsYXNzPSdpbmZv JyBocmVmPScjaW1wbGljaXQtYXV0aHotZXJyb3InPlNlY3Rpb24mbmJzcDs0LjIuMi4xPHNwYW4+ ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkVycm9yIFJlc3BvbnNlPC9zcGFuPjxzcGFuPik8 L3NwYW4+PC9hPiksCgkJdG9rZW4gZXJyb3IgcmVzcG9uc2UgKDxhIGNsYXNzPSdpbmZvJyBocmVm PScjdG9rZW4tZXJyb3JzJz5TZWN0aW9uJm5ic3A7NS4yPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xh c3M9J2luZm8nPkVycm9yIFJlc3BvbnNlPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPiksIG9yCgkJ cmVzb3VyY2UgYWNjZXNzIGVycm9yIHJlc3BvbnNlICg8YSBjbGFzcz0naW5mbycgaHJlZj0nI3Jl c291cmNlLWVycm9ycyc+U2VjdGlvbiZuYnNwOzcuMjxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNz PSdpbmZvJz5FcnJvciBSZXNwb25zZTwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4pLgogICAgICAg ICAgICAgIAo8L2RkPgo8ZHQ+UmVsYXRlZCBwcm90b2NvbCBleHRlbnNpb246PC9kdD4KPGRkPgog ICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICBUaGUgbmFtZSBvZiB0aGUgZXh0ZW5zaW9u IGdyYW50IHR5cGUsIGFjY2VzcyB0b2tlbiB0eXBlLCBvciBleHRlbnNpb24gcGFyYW1ldGVyLAog ICAgICAgICAgICAgICAgdGhlIGVycm9yIGNvZGUgaXMgdXNlZCBpbiBjb25qdW5jdGlvbiB3aXRo LgogICAgICAgICAgICAgIAo8L2RkPgo8ZHQ+Q2hhbmdlIGNvbnRyb2xsZXI6PC9kdD4KPGRkPgog ICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICBGb3Igc3RhbmRhcmRzLXRyYWNrIFJGQ3Ms IHN0YXRlICJJRVRGIi4gRm9yIG90aGVycywgZ2l2ZSB0aGUgbmFtZSBvZiB0aGUKICAgICAgICAg ICAgICAgIHJlc3BvbnNpYmxlIHBhcnR5LiBPdGhlciBkZXRhaWxzIChlLmcuLCBwb3N0YWwgYWRk cmVzcywgZS1tYWlsIGFkZHJlc3MsIGhvbWUgcGFnZQogICAgICAgICAgICAgICAgVVJJKSBtYXkg YWxzbyBiZSBpbmNsdWRlZC4KICAgICAgICAgICAgICAKPC9kZD4KPGR0PlNwZWNpZmljYXRpb24g ZG9jdW1lbnQocyk6PC9kdD4KPGRkPgogICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICBS ZWZlcmVuY2UgdG8gdGhlIGRvY3VtZW50IHRoYXQgc3BlY2lmaWVzIHRoZSBlcnJvciBjb2RlLCBw cmVmZXJhYmx5IGluY2x1ZGluZyBhIFVSSQogICAgICAgICAgICAgICAgdGhhdCBjYW4gYmUgdXNl ZCB0byByZXRyaWV2ZSBhIGNvcHkgb2YgdGhlIGRvY3VtZW50LiBBbiBpbmRpY2F0aW9uIG9mIHRo ZSByZWxldmFudAogICAgICAgICAgICAgICAgc2VjdGlvbnMgbWF5IGFsc28gYmUgaW5jbHVkZWQs IGJ1dCBpcyBub3QgcmVxdWlyZWQuCiAgICAgICAgICAgICAgCjwvZGQ+CjwvZGw+PC9ibG9ja3F1 b3RlPjxwPgogICAgICAgICAgCjwvcD4KPGEgbmFtZT0icmZjLnJlZmVyZW5jZXMiPjwvYT48YnIg Lz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFj aW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1 ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8 YSBuYW1lPSJyZmMuc2VjdGlvbi4xMiI+PC9hPjxoMz4xMi4mbmJzcDsKUmVmZXJlbmNlczwvaDM+ Cgo8YSBuYW1lPSJyZmMucmVmZXJlbmNlczEiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1h cnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVn IiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5i c3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8aDM+MTIuMS4mbmJzcDtOb3JtYXRp dmUgUmVmZXJlbmNlczwvaDM+Cjx0YWJsZSB3aWR0aD0iOTklIiBib3JkZXI9IjAiPgo8dHI+PHRk IGNsYXNzPSJhdXRob3ItdGV4dCIgdmFsaWduPSJ0b3AiPjxhIG5hbWU9IlJGQzIxMTkiPltSRkMy MTE5XTwvYT48L3RkPgo8dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij48YSBocmVmPSJtYWlsdG86c29i QGhhcnZhcmQuZWR1Ij5CcmFkbmVyLCBTLjwvYT4sICZsZHF1bzs8YSBocmVmPSJodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9yZmMyMTE5Ij5LZXkgd29yZHMgZm9yIHVzZSBpbiBSRkNzIHRvIElu ZGljYXRlIFJlcXVpcmVtZW50IExldmVsczwvYT4sJnJkcXVvOyBCQ1AmbmJzcDsxNCwgUkZDJm5i c3A7MjExOSwgTWFyY2gmbmJzcDsxOTk3ICg8YSBocmVmPSJodHRwOi8vd3d3LnJmYy1lZGl0b3Iu b3JnL3JmYy9yZmMyMTE5LnR4dCI+VFhUPC9hPiwgPGEgaHJlZj0iaHR0cDovL3htbC5yZXNvdXJj ZS5vcmcvcHVibGljL3JmYy9odG1sL3JmYzIxMTkuaHRtbCI+SFRNTDwvYT4sIDxhIGhyZWY9Imh0 dHA6Ly94bWwucmVzb3VyY2Uub3JnL3B1YmxpYy9yZmMveG1sL3JmYzIxMTkueG1sIj5YTUw8L2E+ KS48L3RkPjwvdHI+Cjx0cj48dGQgY2xhc3M9ImF1dGhvci10ZXh0IiB2YWxpZ249InRvcCI+PGEg bmFtZT0iUkZDMjI0NiI+W1JGQzIyNDZdPC9hPjwvdGQ+Cjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQi PjxhIGhyZWY9Im1haWx0bzp0ZGllcmtzQGNlcnRpY29tLmNvbSI+RGllcmtzLCBULjwvYT4gYW5k IDxhIGhyZWY9Im1haWx0bzpjYWxsZW5AY2VydGljb20uY29tIj5DLiBBbGxlbjwvYT4sICZsZHF1 bzs8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmMyMjQ2Ij5UaGUgVExTIFBy b3RvY29sIFZlcnNpb24gMS4wPC9hPiwmcmRxdW87IFJGQyZuYnNwOzIyNDYsIEphbnVhcnkmbmJz cDsxOTk5ICg8YSBocmVmPSJodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL3JmYy9yZmMyMjQ2LnR4 dCI+VFhUPC9hPikuPC90ZD48L3RyPgo8dHI+PHRkIGNsYXNzPSJhdXRob3ItdGV4dCIgdmFsaWdu PSJ0b3AiPjxhIG5hbWU9IlJGQzI2MTYiPltSRkMyNjE2XTwvYT48L3RkPgo8dGQgY2xhc3M9ImF1 dGhvci10ZXh0Ij48YSBocmVmPSJtYWlsdG86ZmllbGRpbmdAaWNzLnVjaS5lZHUiPkZpZWxkaW5n LCBSLjwvYT4sIDxhIGhyZWY9Im1haWx0bzpqZ0B3My5vcmciPkdldHR5cywgSi48L2E+LCA8YSBo cmVmPSJtYWlsdG86bW9ndWxAd3JsLmRlYy5jb20iPk1vZ3VsLCBKLjwvYT4sIDxhIGhyZWY9Im1h aWx0bzpmcnlzdHlrQHczLm9yZyI+RnJ5c3R5aywgSC48L2E+LCA8YSBocmVmPSJtYWlsdG86bWFz aW50ZXJAcGFyYy54ZXJveC5jb20iPk1hc2ludGVyLCBMLjwvYT4sIDxhIGhyZWY9Im1haWx0bzpw YXVsbGVAbWljcm9zb2Z0LmNvbSI+TGVhY2gsIFAuPC9hPiwgYW5kIDxhIGhyZWY9Im1haWx0bzp0 aW1ibEB3My5vcmciPlQuIEJlcm5lcnMtTGVlPC9hPiwgJmxkcXVvOzxhIGhyZWY9Imh0dHA6Ly90 b29scy5pZXRmLm9yZy9odG1sL3JmYzI2MTYiPkh5cGVydGV4dCBUcmFuc2ZlciBQcm90b2NvbCAt LSBIVFRQLzEuMTwvYT4sJnJkcXVvOyBSRkMmbmJzcDsyNjE2LCBKdW5lJm5ic3A7MTk5OSAoPGEg aHJlZj0iaHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9yZmMvcmZjMjYxNi50eHQiPlRYVDwvYT4s IDxhIGhyZWY9Imh0dHA6Ly93d3cucmZjLWVkaXRvci5vcmcvcmZjL3JmYzI2MTYucHMiPlBTPC9h PiwgPGEgaHJlZj0iaHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9yZmMvcmZjMjYxNi5wZGYiPlBE RjwvYT4sIDxhIGhyZWY9Imh0dHA6Ly94bWwucmVzb3VyY2Uub3JnL3B1YmxpYy9yZmMvaHRtbC9y ZmMyNjE2Lmh0bWwiPkhUTUw8L2E+LCA8YSBocmVmPSJodHRwOi8veG1sLnJlc291cmNlLm9yZy9w dWJsaWMvcmZjL3htbC9yZmMyNjE2LnhtbCI+WE1MPC9hPikuPC90ZD48L3RyPgo8dHI+PHRkIGNs YXNzPSJhdXRob3ItdGV4dCIgdmFsaWduPSJ0b3AiPjxhIG5hbWU9IlJGQzI2MTciPltSRkMyNjE3 XTwvYT48L3RkPgo8dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij48YSBocmVmPSJtYWlsdG86am9obkBt YXRoLm53dS5lZHUiPkZyYW5rcywgSi48L2E+LCA8YSBocmVmPSJtYWlsdG86cGJha2VyQHZlcmlz aWduLmNvbSI+SGFsbGFtLUJha2VyLCBQLjwvYT4sIDxhIGhyZWY9Im1haWx0bzpqZWZmQEFiaVNv dXJjZS5jb20iPkhvc3RldGxlciwgSi48L2E+LCA8YSBocmVmPSJtYWlsdG86bGF3cmVuY2VAYWdy YW5hdC5jb20iPkxhd3JlbmNlLCBTLjwvYT4sIDxhIGhyZWY9Im1haWx0bzpwYXVsbGVAbWljcm9z b2Z0LmNvbSI+TGVhY2gsIFAuPC9hPiwgTHVvdG9uZW4sIEEuLCBhbmQgPGEgaHJlZj0ibWFpbHRv OnN0ZXdhcnRAT3Blbk1hcmtldC5jb20iPkwuIFN0ZXdhcnQ8L2E+LCAmbGRxdW87PGEgaHJlZj0i aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMjYxNyI+SFRUUCBBdXRoZW50aWNhdGlvbjog QmFzaWMgYW5kIERpZ2VzdCBBY2Nlc3MgQXV0aGVudGljYXRpb248L2E+LCZyZHF1bzsgUkZDJm5i c3A7MjYxNywgSnVuZSZuYnNwOzE5OTkgKDxhIGhyZWY9Imh0dHA6Ly93d3cucmZjLWVkaXRvci5v cmcvcmZjL3JmYzI2MTcudHh0Ij5UWFQ8L2E+LCA8YSBocmVmPSJodHRwOi8veG1sLnJlc291cmNl Lm9yZy9wdWJsaWMvcmZjL2h0bWwvcmZjMjYxNy5odG1sIj5IVE1MPC9hPiwgPGEgaHJlZj0iaHR0 cDovL3htbC5yZXNvdXJjZS5vcmcvcHVibGljL3JmYy94bWwvcmZjMjYxNy54bWwiPlhNTDwvYT4p LjwvdGQ+PC90cj4KPHRyPjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiIHZhbGlnbj0idG9wIj48YSBu YW1lPSJSRkMyODE4Ij5bUkZDMjgxOF08L2E+PC90ZD4KPHRkIGNsYXNzPSJhdXRob3ItdGV4dCI+ UmVzY29ybGEsIEUuLCAmbGRxdW87PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv cmZjMjgxOCI+SFRUUCBPdmVyIFRMUzwvYT4sJnJkcXVvOyBSRkMmbmJzcDsyODE4LCBNYXkmbmJz cDsyMDAwICg8YSBocmVmPSJodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL3JmYy9yZmMyODE4LnR4 dCI+VFhUPC9hPikuPC90ZD48L3RyPgo8dHI+PHRkIGNsYXNzPSJhdXRob3ItdGV4dCIgdmFsaWdu PSJ0b3AiPjxhIG5hbWU9IlJGQzM5ODYiPltSRkMzOTg2XTwvYT48L3RkPgo8dGQgY2xhc3M9ImF1 dGhvci10ZXh0Ij48YSBocmVmPSJtYWlsdG86dGltYmxAdzMub3JnIj5CZXJuZXJzLUxlZSwgVC48 L2E+LCA8YSBocmVmPSJtYWlsdG86ZmllbGRpbmdAZ2Jpdi5jb20iPkZpZWxkaW5nLCBSLjwvYT4s IGFuZCA8YSBocmVmPSJtYWlsdG86TE1NQGFjbS5vcmciPkwuIE1hc2ludGVyPC9hPiwgJmxkcXVv OzxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzM5ODYiPlVuaWZvcm0gUmVz b3VyY2UgSWRlbnRpZmllciAoVVJJKTogR2VuZXJpYyBTeW50YXg8L2E+LCZyZHF1bzsgU1REJm5i c3A7NjYsIFJGQyZuYnNwOzM5ODYsIEphbnVhcnkmbmJzcDsyMDA1ICg8YSBocmVmPSJodHRwOi8v d3d3LnJmYy1lZGl0b3Iub3JnL3JmYy9yZmMzOTg2LnR4dCI+VFhUPC9hPiwgPGEgaHJlZj0iaHR0 cDovL3htbC5yZXNvdXJjZS5vcmcvcHVibGljL3JmYy9odG1sL3JmYzM5ODYuaHRtbCI+SFRNTDwv YT4sIDxhIGhyZWY9Imh0dHA6Ly94bWwucmVzb3VyY2Uub3JnL3B1YmxpYy9yZmMveG1sL3JmYzM5 ODYueG1sIj5YTUw8L2E+KS48L3RkPjwvdHI+Cjx0cj48dGQgY2xhc3M9ImF1dGhvci10ZXh0IiB2 YWxpZ249InRvcCI+PGEgbmFtZT0iUkZDNDYyNyI+W1JGQzQ2MjddPC9hPjwvdGQ+Cjx0ZCBjbGFz cz0iYXV0aG9yLXRleHQiPkNyb2NrZm9yZCwgRC4sICZsZHF1bzs8YSBocmVmPSJodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9yZmM0NjI3Ij5UaGUgYXBwbGljYXRpb24vanNvbiBNZWRpYSBUeXBl IGZvciBKYXZhU2NyaXB0IE9iamVjdCBOb3RhdGlvbiAoSlNPTik8L2E+LCZyZHF1bzsgUkZDJm5i c3A7NDYyNywgSnVseSZuYnNwOzIwMDYgKDxhIGhyZWY9Imh0dHA6Ly93d3cucmZjLWVkaXRvci5v cmcvcmZjL3JmYzQ2MjcudHh0Ij5UWFQ8L2E+KS48L3RkPjwvdHI+Cjx0cj48dGQgY2xhc3M9ImF1 dGhvci10ZXh0IiB2YWxpZ249InRvcCI+PGEgbmFtZT0iUkZDNDk0OSI+W1JGQzQ5NDldPC9hPjwv dGQ+Cjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPlNoaXJleSwgUi4sICZsZHF1bzs8YSBocmVmPSJo dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM0OTQ5Ij5JbnRlcm5ldCBTZWN1cml0eSBHbG9z c2FyeSwgVmVyc2lvbiAyPC9hPiwmcmRxdW87IFJGQyZuYnNwOzQ5NDksIEF1Z3VzdCZuYnNwOzIw MDcgKDxhIGhyZWY9Imh0dHA6Ly93d3cucmZjLWVkaXRvci5vcmcvcmZjL3JmYzQ5NDkudHh0Ij5U WFQ8L2E+KS48L3RkPjwvdHI+Cjx0cj48dGQgY2xhc3M9ImF1dGhvci10ZXh0IiB2YWxpZ249InRv cCI+PGEgbmFtZT0iUkZDNTIyNiI+W1JGQzUyMjZdPC9hPjwvdGQ+Cjx0ZCBjbGFzcz0iYXV0aG9y LXRleHQiPk5hcnRlbiwgVC4gYW5kIEguIEFsdmVzdHJhbmQsICZsZHF1bzs8YSBocmVmPSJodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1MjI2Ij5HdWlkZWxpbmVzIGZvciBXcml0aW5nIGFu IElBTkEgQ29uc2lkZXJhdGlvbnMgU2VjdGlvbiBpbiBSRkNzPC9hPiwmcmRxdW87IEJDUCZuYnNw OzI2LCBSRkMmbmJzcDs1MjI2LCBNYXkmbmJzcDsyMDA4ICg8YSBocmVmPSJodHRwOi8vd3d3LnJm Yy1lZGl0b3Iub3JnL3JmYy9yZmM1MjI2LnR4dCI+VFhUPC9hPikuPC90ZD48L3RyPgo8dHI+PHRk IGNsYXNzPSJhdXRob3ItdGV4dCIgdmFsaWduPSJ0b3AiPjxhIG5hbWU9IlJGQzUyMzQiPltSRkM1 MjM0XTwvYT48L3RkPgo8dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij5Dcm9ja2VyLCBELiBhbmQgUC4g T3ZlcmVsbCwgJmxkcXVvOzxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzUy MzQiPkF1Z21lbnRlZCBCTkYgZm9yIFN5bnRheCBTcGVjaWZpY2F0aW9uczogQUJORjwvYT4sJnJk cXVvOyBTVEQmbmJzcDs2OCwgUkZDJm5ic3A7NTIzNCwgSmFudWFyeSZuYnNwOzIwMDggKDxhIGhy ZWY9Imh0dHA6Ly93d3cucmZjLWVkaXRvci5vcmcvcmZjL3JmYzUyMzQudHh0Ij5UWFQ8L2E+KS48 L3RkPjwvdHI+Cjx0cj48dGQgY2xhc3M9ImF1dGhvci10ZXh0IiB2YWxpZ249InRvcCI+PGEgbmFt ZT0iUkZDNTI0NiI+W1JGQzUyNDZdPC9hPjwvdGQ+Cjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPkRp ZXJrcywgVC4gYW5kIEUuIFJlc2NvcmxhLCAmbGRxdW87PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmll dGYub3JnL2h0bWwvcmZjNTI0NiI+VGhlIFRyYW5zcG9ydCBMYXllciBTZWN1cml0eSAoVExTKSBQ cm90b2NvbCBWZXJzaW9uIDEuMjwvYT4sJnJkcXVvOyBSRkMmbmJzcDs1MjQ2LCBBdWd1c3QmbmJz cDsyMDA4ICg8YSBocmVmPSJodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL3JmYy9yZmM1MjQ2LnR4 dCI+VFhUPC9hPikuPC90ZD48L3RyPgo8dHI+PHRkIGNsYXNzPSJhdXRob3ItdGV4dCIgdmFsaWdu PSJ0b3AiPjxhIG5hbWU9IlJGQzYxMjUiPltSRkM2MTI1XTwvYT48L3RkPgo8dGQgY2xhc3M9ImF1 dGhvci10ZXh0Ij5TYWludC1BbmRyZSwgUC4gYW5kIEouIEhvZGdlcywgJmxkcXVvOzxhIGhyZWY9 Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzYxMjUiPlJlcHJlc2VudGF0aW9uIGFuZCBW ZXJpZmljYXRpb24gb2YgRG9tYWluLUJhc2VkIEFwcGxpY2F0aW9uIFNlcnZpY2UgSWRlbnRpdHkg d2l0aGluIEludGVybmV0IFB1YmxpYyBLZXkgSW5mcmFzdHJ1Y3R1cmUgVXNpbmcgWC41MDkgKFBL SVgpIENlcnRpZmljYXRlcyBpbiB0aGUgQ29udGV4dCBvZiBUcmFuc3BvcnQgTGF5ZXIgU2VjdXJp dHkgKFRMUyk8L2E+LCZyZHF1bzsgUkZDJm5ic3A7NjEyNSwgTWFyY2gmbmJzcDsyMDExICg8YSBo cmVmPSJodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL3JmYy9yZmM2MTI1LnR4dCI+VFhUPC9hPiku PC90ZD48L3RyPgo8dHI+PHRkIGNsYXNzPSJhdXRob3ItdGV4dCIgdmFsaWduPSJ0b3AiPjxhIG5h bWU9IlVTQVNDSUkiPltVU0FTQ0lJXTwvYT48L3RkPgo8dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij5B bWVyaWNhbiBOYXRpb25hbCBTdGFuZGFyZHMgSW5zdGl0dXRlLCAmbGRxdW87Q29kZWQgQ2hhcmFj dGVyIFNldCAtLSA3LWJpdCBBbWVyaWNhbiBTdGFuZGFyZCBDb2RlIGZvciBJbmZvcm1hdGlvbiBJ bnRlcmNoYW5nZSwmcmRxdW87IEFOU0kmbmJzcDtYMy40LCAxOTg2LjwvdGQ+PC90cj4KPHRyPjx0 ZCBjbGFzcz0iYXV0aG9yLXRleHQiIHZhbGlnbj0idG9wIj48YSBuYW1lPSJXM0MuUkVDLWh0bWw0 MDEtMTk5OTEyMjQiPltXM0MuUkVDLWh0bWw0MDEtMTk5OTEyMjRdPC9hPjwvdGQ+Cjx0ZCBjbGFz cz0iYXV0aG9yLXRleHQiPkhvcnMsIEEuLCBSYWdnZXR0LCBELiwgYW5kIEkuIEphY29icywgJmxk cXVvOzxhIGhyZWY9Imh0dHA6Ly93d3cudzMub3JnL1RSLzE5OTkvUkVDLWh0bWw0MDEtMTk5OTEy MjQiPkhUTUwgNC4wMSBTcGVjaWZpY2F0aW9uPC9hPiwmcmRxdW87IFdvcmxkIFdpZGUgV2ViIENv bnNvcnRpdW0gUmVjb21tZW5kYXRpb24mbmJzcDtSRUMtaHRtbDQwMS0xOTk5MTIyNCwgRGVjZW1i ZXImbmJzcDsxOTk5ICg8YSBocmVmPSJodHRwOi8vd3d3LnczLm9yZy9UUi8xOTk5L1JFQy1odG1s NDAxLTE5OTkxMjI0Ij5IVE1MPC9hPikuPC90ZD48L3RyPgo8L3RhYmxlPgoKPGEgbmFtZT0icmZj LnJlZmVyZW5jZXMyIj48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNl bGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0 Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwv YT48L3RkPjwvdHI+PC90YWJsZT4KPGgzPjEyLjIuJm5ic3A7SW5mb3JtYXRpdmUgUmVmZXJlbmNl czwvaDM+Cjx0YWJsZSB3aWR0aD0iOTklIiBib3JkZXI9IjAiPgo8dHI+PHRkIGNsYXNzPSJhdXRo b3ItdGV4dCIgdmFsaWduPSJ0b3AiPjxhIG5hbWU9IkktRC5kcmFmdC1oYXJkdC1vYXV0aC0wMSI+ W0ktRC5kcmFmdC1oYXJkdC1vYXV0aC0wMV08L2E+PC90ZD4KPHRkIGNsYXNzPSJhdXRob3ItdGV4 dCI+SGFyZHQsIEQuLCBFZC4sIFRvbSwgQS4sIEVhdG9uLCBCLiwgYW5kIFkuIEdvbGFuZCwgJmxk cXVvOzxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWhhcmR0LW9hdXRo LTAxIj5PQXV0aCBXZWIgUmVzb3VyY2UgQXV0aG9yaXphdGlvbiBQcm9maWxlczwvYT4sJnJkcXVv OyBKYW51YXJ5Jm5ic3A7MjAxMC48L3RkPjwvdHI+Cjx0cj48dGQgY2xhc3M9ImF1dGhvci10ZXh0 IiB2YWxpZ249InRvcCI+PGEgbmFtZT0iSS1ELmlldGYtaHR0cGJpcy1wNy1hdXRoIj5bSS1ELmll dGYtaHR0cGJpcy1wNy1hdXRoXTwvYT48L3RkPgo8dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij5GaWVs ZGluZywgUi4sIExhZm9uLCBZLiwgYW5kIEouIFJlc2Noa2UsICZsZHF1bzs8YSBocmVmPSJodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWh0dHBiaXMtcDctYXV0aC0xOSI+SFRU UC8xLjEsIHBhcnQgNzogQXV0aGVudGljYXRpb248L2E+LCZyZHF1bzsgZHJhZnQtaWV0Zi1odHRw YmlzLXA3LWF1dGgtMTkgKHdvcmsgaW4gcHJvZ3Jlc3MpLCBNYXJjaCZuYnNwOzIwMTIgKDxhIGhy ZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtaHR0cGJp cy1wNy1hdXRoLTE5LnR4dCI+VFhUPC9hPikuPC90ZD48L3RyPgo8dHI+PHRkIGNsYXNzPSJhdXRo b3ItdGV4dCIgdmFsaWduPSJ0b3AiPjxhIG5hbWU9IkktRC5pZXRmLW9hdXRoLXNhbWwyLWJlYXJl ciI+W0ktRC5pZXRmLW9hdXRoLXNhbWwyLWJlYXJlcl08L2E+PC90ZD4KPHRkIGNsYXNzPSJhdXRo b3ItdGV4dCI+TW9ydGltb3JlLCBDLiwgJmxkcXVvOzxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtc2FtbDItYmVhcmVyLTEyIj5TQU1MIDIuMCBCZWFy ZXIgQXNzZXJ0aW9uIFByb2ZpbGVzIGZvciBPQXV0aCAyLjA8L2E+LCZyZHF1bzsgZHJhZnQtaWV0 Zi1vYXV0aC1zYW1sMi1iZWFyZXItMTIgKHdvcmsgaW4gcHJvZ3Jlc3MpLCBNYXkmbmJzcDsyMDEy ICg8YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRm LW9hdXRoLXNhbWwyLWJlYXJlci0xMi50eHQiPlRYVDwvYT4pLjwvdGQ+PC90cj4KPHRyPjx0ZCBj bGFzcz0iYXV0aG9yLXRleHQiIHZhbGlnbj0idG9wIj48YSBuYW1lPSJJLUQuaWV0Zi1vYXV0aC12 Mi1iZWFyZXIiPltJLUQuaWV0Zi1vYXV0aC12Mi1iZWFyZXJdPC9hPjwvdGQ+Cjx0ZCBjbGFzcz0i YXV0aG9yLXRleHQiPkpvbmVzLCBNLiwgSGFyZHQsIEQuLCBhbmQgRC4gUmVjb3Jkb24sICZsZHF1 bzs8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLXYy LWJlYXJlci0xOSI+VGhlIE9BdXRoIDIuMCBBdXRob3JpemF0aW9uIFByb3RvY29sOiBCZWFyZXIg VG9rZW5zPC9hPiwmcmRxdW87IGRyYWZ0LWlldGYtb2F1dGgtdjItYmVhcmVyLTE5ICh3b3JrIGlu IHByb2dyZXNzKSwgQXByaWwmbmJzcDsyMDEyICg8YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3Jn L2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLW9hdXRoLXYyLWJlYXJlci0xOS50eHQiPlRYVDwv YT4sIDxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWll dGYtb2F1dGgtdjItYmVhcmVyLTE5LnBkZiI+UERGPC9hPikuPC90ZD48L3RyPgo8dHI+PHRkIGNs YXNzPSJhdXRob3ItdGV4dCIgdmFsaWduPSJ0b3AiPjxhIG5hbWU9IkktRC5pZXRmLW9hdXRoLXYy LWh0dHAtbWFjIj5bSS1ELmlldGYtb2F1dGgtdjItaHR0cC1tYWNdPC9hPjwvdGQ+Cjx0ZCBjbGFz cz0iYXV0aG9yLXRleHQiPkhhbW1lci1MYWhhdiwgRS4sICZsZHF1bzs8YSBocmVmPSJodHRwOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLXYyLWh0dHAtbWFjLTAxIj5IVFRQ IEF1dGhlbnRpY2F0aW9uOiBNQUMgQWNjZXNzIEF1dGhlbnRpY2F0aW9uPC9hPiwmcmRxdW87IGRy YWZ0LWlldGYtb2F1dGgtdjItaHR0cC1tYWMtMDEgKHdvcmsgaW4gcHJvZ3Jlc3MpLCBGZWJydWFy eSZuYnNwOzIwMTIgKDxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRz L2RyYWZ0LWlldGYtb2F1dGgtdjItaHR0cC1tYWMtMDEudHh0Ij5UWFQ8L2E+LCA8YSBocmVmPSJo dHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLW9hdXRoLXYyLWh0 dHAtbWFjLTAxLnBkZiI+UERGPC9hPikuPC90ZD48L3RyPgo8dHI+PHRkIGNsYXNzPSJhdXRob3It dGV4dCIgdmFsaWduPSJ0b3AiPjxhIG5hbWU9IkktRC5pZXRmLW9hdXRoLXYyLXRocmVhdG1vZGVs Ij5bSS1ELmlldGYtb2F1dGgtdjItdGhyZWF0bW9kZWxdPC9hPjwvdGQ+Cjx0ZCBjbGFzcz0iYXV0 aG9yLXRleHQiPk1jR2xvaW4sIE0uLCBIdW50LCBQLiwgYW5kIFQuIExvZGRlcnN0ZWR0LCAmbGRx dW87PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC12 Mi10aHJlYXRtb2RlbC0wMiI+T0F1dGggMi4wIFRocmVhdCBNb2RlbCBhbmQgU2VjdXJpdHkgQ29u c2lkZXJhdGlvbnM8L2E+LCZyZHF1bzsgZHJhZnQtaWV0Zi1vYXV0aC12Mi10aHJlYXRtb2RlbC0w MiAod29yayBpbiBwcm9ncmVzcyksIEZlYnJ1YXJ5Jm5ic3A7MjAxMiAoPGEgaHJlZj0iaHR0cDov L3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1vYXV0aC12Mi10aHJlYXRt b2RlbC0wMi50eHQiPlRYVDwvYT4pLjwvdGQ+PC90cj4KPHRyPjx0ZCBjbGFzcz0iYXV0aG9yLXRl eHQiIHZhbGlnbj0idG9wIj48YSBuYW1lPSJSRkM1ODQ5Ij5bUkZDNTg0OV08L2E+PC90ZD4KPHRk IGNsYXNzPSJhdXRob3ItdGV4dCI+SGFtbWVyLUxhaGF2LCBFLiwgJmxkcXVvOzxhIGhyZWY9Imh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzU4NDkiPlRoZSBPQXV0aCAxLjAgUHJvdG9jb2w8 L2E+LCZyZHF1bzsgUkZDJm5ic3A7NTg0OSwgQXByaWwmbmJzcDsyMDEwICg8YSBocmVmPSJodHRw Oi8vd3d3LnJmYy1lZGl0b3Iub3JnL3JmYy9yZmM1ODQ5LnR4dCI+VFhUPC9hPikuPC90ZD48L3Ry Pgo8L3RhYmxlPgoKPGEgbmFtZT0iYW5jaG9yNTUiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1 bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9D YnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+ Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlv bi5BIj48L2E+PGgzPkFwcGVuZGl4IEEuJm5ic3A7CkF1Z21lbnRlZCBCYWNrdXMtTmF1ciBGb3Jt IChBQk5GKSBTeW50YXg8L2gzPgoKPHA+CglUaGlzIHNlY3Rpb24gcHJvdmlkZXMgQXVnbWVudGVk IEJhY2t1cy1OYXVyIEZvcm0gKEFCTkYpIHN5bnRheAoJZGVzY3JpcHRpb25zIGZvciB0aGUgZWxl bWVudHMgZGVmaW5lZCBpbiB0aGlzIHNwZWNpZmljYXRpb24KCXVzaW5nIHRoZSBub3RhdGlvbiBv ZiA8YSBjbGFzcz0naW5mbycgaHJlZj0nI1JGQzUyMzQnPltSRkM1MjM0XTxzcGFuPiAoPC9zcGFu PjxzcGFuIGNsYXNzPSdpbmZvJz5Dcm9ja2VyLCBELiBhbmQgUC4gT3ZlcmVsbCwgJmxkcXVvO0F1 Z21lbnRlZCBCTkYgZm9yIFN5bnRheCBTcGVjaWZpY2F0aW9uczogQUJORiwmcmRxdW87IEphbnVh cnkmbmJzcDsyMDA4Ljwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4uCglFbGVtZW50cyBhcmUgcHJl c2VudGVkIGluIHRoZSBvcmRlciBmaXJzdCBkZWZpbmVkLgogICAgICAKPC9wPgo8cD4KCVNvbWUg b2YgdGhlIGRlZmluaXRpb25zIHRoYXQgZm9sbG93IHVzZSB0aGUKCTx0dD5VUkktcmVmZXJlbmNl PC90dD4KCWRlZmluaXRpb24gZnJvbSA8YSBjbGFzcz0naW5mbycgaHJlZj0nI1JGQzM5ODYnPltS RkMzOTg2XTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5CZXJuZXJzLUxlZSwgVC4s IEZpZWxkaW5nLCBSLiwgYW5kIEwuIE1hc2ludGVyLCAmbGRxdW87VW5pZm9ybSBSZXNvdXJjZSBJ ZGVudGlmaWVyIChVUkkpOiBHZW5lcmljIFN5bnRheCwmcmRxdW87IEphbnVhcnkmbmJzcDsyMDA1 Ljwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4uCiAgICAgIAo8L3A+CjxwPgoJICBTb21lIG9mIHRo ZSBkZWZpbml0aW9ucyB0aGF0IGZvbGxvdyB1c2UgdGhlc2UgY29tbW9uIGRlZmluaXRpb25zOgoJ CjwvcD48ZGl2IHN0eWxlPSdkaXNwbGF5OiB0YWJsZTsgd2lkdGg6IDA7IG1hcmdpbi1sZWZ0OiAz ZW07IG1hcmdpbi1yaWdodDogYXV0byc+PHByZT4KVlNDSEFSICAgICA9ICUyMC03RQpOUUNIQVIg ICAgID0gJXgyMSAvICV4MjMtNUIgLyAleDVELTdFCk5RU0NIQVIgICAgPSAleDIwLTIxIC8gJXgy My01QiAvICV4NUQtN0UKPC9wcmU+PC9kaXY+CjxhIG5hbWU9ImFuY2hvcjU2Ij48L2E+PGJyIC8+ PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2lu Zz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWci PjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEg bmFtZT0icmZjLnNlY3Rpb24uQS4xIj48L2E+PGgzPkEuMS4mbmJzcDsKImNsaWVudF9pZCIgU3lu dGF4PC9oMz4KCjxwPgoJICAgIFRoZSA8dHQ+Y2xpZW50X2lkPC90dD4gZWxlbWVudCBpcyBkZWZp bmVkIGluCgkgICAgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNjbGllbnQtcGFzc3dvcmQnPlNlY3Rp b24mbmJzcDsyLjMuMTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5DbGllbnQgUGFz c3dvcmQ8L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+OgoJICAKPC9wPjxkaXYgc3R5bGU9J2Rpc3Bs YXk6IHRhYmxlOyB3aWR0aDogMDsgbWFyZ2luLWxlZnQ6IDNlbTsgbWFyZ2luLXJpZ2h0OiBhdXRv Jz48cHJlPgpjbGllbnQtaWQgICAgID0gKlZTQ0hBUgo8L3ByZT48L2Rpdj4KPHA+CgkgIChUaGlz IG1hdGNoZXMgdGhlIDx0dD51c2VyaWQ8L3R0PiBkZWZpbml0aW9uIGluIHRoZQoJICBIVFRQIEJh c2ljIEF1dGhlbnRpY2F0aW9uIFNjaGVtZSA8YSBjbGFzcz0naW5mbycgaHJlZj0nI1JGQzI2MTcn PltSRkMyNjE3XTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5GcmFua3MsIEouLCBI YWxsYW0tQmFrZXIsIFAuLCBIb3N0ZXRsZXIsIEouLCBMYXdyZW5jZSwgUy4sIExlYWNoLCBQLiwg THVvdG9uZW4sIEEuLCBhbmQgTC4gU3Rld2FydCwgJmxkcXVvO0hUVFAgQXV0aGVudGljYXRpb246 IEJhc2ljIGFuZCBEaWdlc3QgQWNjZXNzIEF1dGhlbnRpY2F0aW9uLCZyZHF1bzsgSnVuZSZuYnNw OzE5OTkuPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPi4pCgkKPC9wPgo8YSBuYW1lPSJhbmNob3I1 NyI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0i MCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBj bGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3Ry PjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLkEuMiI+PC9hPjxoMz5BLjIuJm5ic3A7CiJj bGllbnRfc2VjcmV0IiBTeW50YXg8L2gzPgoKPHA+CgkgICAgVGhlIDx0dD5jbGllbnRfc2VjcmV0 PC90dD4gZWxlbWVudCBpcyBkZWZpbmVkIGluCgkgICAgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNj bGllbnQtcGFzc3dvcmQnPlNlY3Rpb24mbmJzcDsyLjMuMTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNs YXNzPSdpbmZvJz5DbGllbnQgUGFzc3dvcmQ8L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+OgoJICAK PC9wPjxkaXYgc3R5bGU9J2Rpc3BsYXk6IHRhYmxlOyB3aWR0aDogMDsgbWFyZ2luLWxlZnQ6IDNl bTsgbWFyZ2luLXJpZ2h0OiBhdXRvJz48cHJlPgpjbGllbnQtc2VjcmV0ID0gKlZTQ0hBUgo8L3By ZT48L2Rpdj4KPHA+CgkgIChUaGlzIG1hdGNoZXMgdGhlIDx0dD5wYXNzd29yZDwvdHQ+IGRlZmlu aXRpb24gaW4gdGhlCgkgIEhUVFAgQmFzaWMgQXV0aGVudGljYXRpb24gU2NoZW1lIDxhIGNsYXNz PSdpbmZvJyBocmVmPScjUkZDMjYxNyc+W1JGQzI2MTddPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xh c3M9J2luZm8nPkZyYW5rcywgSi4sIEhhbGxhbS1CYWtlciwgUC4sIEhvc3RldGxlciwgSi4sIExh d3JlbmNlLCBTLiwgTGVhY2gsIFAuLCBMdW90b25lbiwgQS4sIGFuZCBMLiBTdGV3YXJ0LCAmbGRx dW87SFRUUCBBdXRoZW50aWNhdGlvbjogQmFzaWMgYW5kIERpZ2VzdCBBY2Nlc3MgQXV0aGVudGlj YXRpb24sJnJkcXVvOyBKdW5lJm5ic3A7MTk5OS48L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+LikK CQo8L3A+CjxhIG5hbWU9ImFuY2hvcjU4Ij48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5 PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIg YWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNw O1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uQS4z Ij48L2E+PGgzPkEuMy4mbmJzcDsKInJlc3BvbnNlX3R5cGUiIFN5bnRheDwvaDM+Cgo8cD4KCSAg ICBUaGUgPHR0PnJlc3BvbnNlX3R5cGU8L3R0PiBlbGVtZW50IGlzIGRlZmluZWQgaW4KCSAgICA8 YSBjbGFzcz0naW5mbycgaHJlZj0nI3Jlc3BvbnNlLXR5cGUnPlNlY3Rpb24mbmJzcDszLjEuMTxz cGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5SZXNwb25zZSBUeXBlPC9zcGFuPjxzcGFu Pik8L3NwYW4+PC9hPiBhbmQKCSAgICA8YSBjbGFzcz0naW5mbycgaHJlZj0nI3Jlc3BvbnNlLXR5 cGUtZXh0Jz5TZWN0aW9uJm5ic3A7OC40PHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8n PkRlZmluaW5nIE5ldyBBdXRob3JpemF0aW9uIEVuZHBvaW50IFJlc3BvbnNlIFR5cGVzPC9zcGFu PjxzcGFuPik8L3NwYW4+PC9hPjoKCSAgCjwvcD48ZGl2IHN0eWxlPSdkaXNwbGF5OiB0YWJsZTsg d2lkdGg6IDA7IG1hcmdpbi1sZWZ0OiAzZW07IG1hcmdpbi1yaWdodDogYXV0byc+PHByZT4KcmVz cG9uc2UtdHlwZSA9IHJlc3BvbnNlLW5hbWUgKiggU1AgcmVzcG9uc2UtbmFtZSApCnJlc3BvbnNl LW5hbWUgPSAxKnJlc3BvbnNlLWNoYXIKcmVzcG9uc2UtY2hhciA9ICJfIiAvIERJR0lUIC8gQUxQ SEEKPC9wcmU+PC9kaXY+CjxhIG5hbWU9ImFuY2hvcjU5Ij48L2E+PGJyIC8+PGhyIC8+Cjx0YWJs ZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9 IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0 b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNl Y3Rpb24uQS40Ij48L2E+PGgzPkEuNC4mbmJzcDsKInNjb3BlIiBTeW50YXg8L2gzPgoKPHA+Cgkg ICAgVGhlIDx0dD5zY29wZTwvdHQ+IGVsZW1lbnQgaXMgZGVmaW5lZCBpbgoJICAgIDxhIGNsYXNz PSdpbmZvJyBocmVmPScjc2NvcGUnPlNlY3Rpb24mbmJzcDszLjM8c3Bhbj4gKDwvc3Bhbj48c3Bh biBjbGFzcz0naW5mbyc+QWNjZXNzIFRva2VuIFNjb3BlPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9h PjoKCSAgCjwvcD48ZGl2IHN0eWxlPSdkaXNwbGF5OiB0YWJsZTsgd2lkdGg6IDA7IG1hcmdpbi1s ZWZ0OiAzZW07IG1hcmdpbi1yaWdodDogYXV0byc+PHByZT4Kc2NvcGUgICAgICAgPSBzY29wZS10 b2tlbiAqKCBTUCBzY29wZS10b2tlbiApCnNjb3BlLXRva2VuID0gMSpOUUNIQVIKPC9wcmU+PC9k aXY+CjxhIG5hbWU9ImFuY2hvcjYwIj48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJs YXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxp Z249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RP QyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uQS41Ij48 L2E+PGgzPkEuNS4mbmJzcDsKInN0YXRlIiBTeW50YXg8L2gzPgoKPHA+CgkgICAgVGhlIDx0dD5z dGF0ZTwvdHQ+IGVsZW1lbnQgaXMgZGVmaW5lZCBpbgoJICAgIDxhIGNsYXNzPSdpbmZvJyBocmVm PScjY29kZS1hdXRoei1yZXEnPlNlY3Rpb24mbmJzcDs0LjEuMTxzcGFuPiAoPC9zcGFuPjxzcGFu IGNsYXNzPSdpbmZvJz5BdXRob3JpemF0aW9uIFJlcXVlc3Q8L3NwYW4+PHNwYW4+KTwvc3Bhbj48 L2E+LAoJICAgIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjY29kZS1hdXRoei1yZXNwJz5TZWN0aW9u Jm5ic3A7NC4xLjI8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+QXV0aG9yaXphdGlv biBSZXNwb25zZTwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4sCgkgICAgPGEgY2xhc3M9J2luZm8n IGhyZWY9JyNjb2RlLWF1dGh6LWVycm9yJz5TZWN0aW9uJm5ic3A7NC4xLjIuMTxzcGFuPiAoPC9z cGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5FcnJvciBSZXNwb25zZTwvc3Bhbj48c3Bhbj4pPC9zcGFu PjwvYT4sCgkgICAgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNpbXBsaWNpdC1hdXRoei1yZXEnPlNl Y3Rpb24mbmJzcDs0LjIuMTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5BdXRob3Jp emF0aW9uIFJlcXVlc3Q8L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+LAoJICAgIDxhIGNsYXNzPSdp bmZvJyBocmVmPScjaW1wbGljaXQtYXV0aHotcmVzcCc+U2VjdGlvbiZuYnNwOzQuMi4yPHNwYW4+ ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkFjY2VzcyBUb2tlbiBSZXNwb25zZTwvc3Bhbj48 c3Bhbj4pPC9zcGFuPjwvYT4sIGFuZAoJICAgIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjaW1wbGlj aXQtYXV0aHotZXJyb3InPlNlY3Rpb24mbmJzcDs0LjIuMi4xPHNwYW4+ICg8L3NwYW4+PHNwYW4g Y2xhc3M9J2luZm8nPkVycm9yIFJlc3BvbnNlPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPjoKCSAg CjwvcD48ZGl2IHN0eWxlPSdkaXNwbGF5OiB0YWJsZTsgd2lkdGg6IDA7IG1hcmdpbi1sZWZ0OiAz ZW07IG1hcmdpbi1yaWdodDogYXV0byc+PHByZT4Kc3RhdGUgICAgICA9IDEqVlNDSEFSCjwvcHJl PjwvZGl2Pgo8YSBuYW1lPSJhbmNob3I2MSI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFy eT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWci IGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJz cDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLkEu NiI+PC9hPjxoMz5BLjYuJm5ic3A7CiJyZWRpcmVjdF91cmkiIFN5bnRheDwvaDM+Cgo8cD4KCSAg ICBUaGUgPHR0PnJlZGlyZWN0X3VyaTwvdHQ+IGVsZW1lbnQgaXMgZGVmaW5lZCBpbgoJICAgIDxh IGNsYXNzPSdpbmZvJyBocmVmPScjY29kZS1hdXRoei1yZXEnPlNlY3Rpb24mbmJzcDs0LjEuMTxz cGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5BdXRob3JpemF0aW9uIFJlcXVlc3Q8L3Nw YW4+PHNwYW4+KTwvc3Bhbj48L2E+LAoJICAgIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjdG9rZW4t cmVxJz5TZWN0aW9uJm5ic3A7NC4xLjM8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+ QWNjZXNzIFRva2VuIFJlcXVlc3Q8L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+LCBhbmQKCSAgICA8 YSBjbGFzcz0naW5mbycgaHJlZj0nI2ltcGxpY2l0LWF1dGh6LXJlcSc+U2VjdGlvbiZuYnNwOzQu Mi4xPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkF1dGhvcml6YXRpb24gUmVxdWVz dDwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT46CgkgIAo8L3A+PGRpdiBzdHlsZT0nZGlzcGxheTog dGFibGU7IHdpZHRoOiAwOyBtYXJnaW4tbGVmdDogM2VtOyBtYXJnaW4tcmlnaHQ6IGF1dG8nPjxw cmU+CnJlZGlyZWN0LXVyaSAgICAgID0gVVJJLXJlZmVyZW5jZQo8L3ByZT48L2Rpdj4KPGEgbmFt ZT0iYW5jaG9yNjIiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2Vs bHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQi Pjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9h PjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi5BLjciPjwvYT48aDM+QS43 LiZuYnNwOwoiZXJyb3IiIFN5bnRheDwvaDM+Cgo8cD4KCSAgICBUaGUgPHR0PmVycm9yPC90dD4g ZWxlbWVudCBpcyBkZWZpbmVkIGluCgkgICAgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNjb2RlLWF1 dGh6LWVycm9yJz5TZWN0aW9uJm5ic3A7NC4xLjIuMTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNz PSdpbmZvJz5FcnJvciBSZXNwb25zZTwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4sCgkgICAgPGEg Y2xhc3M9J2luZm8nIGhyZWY9JyNpbXBsaWNpdC1hdXRoei1lcnJvcic+U2VjdGlvbiZuYnNwOzQu Mi4yLjE8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+RXJyb3IgUmVzcG9uc2U8L3Nw YW4+PHNwYW4+KTwvc3Bhbj48L2E+LAoJICAgIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjdG9rZW4t ZXJyb3JzJz5TZWN0aW9uJm5ic3A7NS4yPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8n PkVycm9yIFJlc3BvbnNlPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPiwKCSAgICA8YSBjbGFzcz0n aW5mbycgaHJlZj0nI3Jlc291cmNlLWVycm9ycyc+U2VjdGlvbiZuYnNwOzcuMjxzcGFuPiAoPC9z cGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5FcnJvciBSZXNwb25zZTwvc3Bhbj48c3Bhbj4pPC9zcGFu PjwvYT4sIGFuZAoJICAgIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjbmV3LWVycm9ycyc+U2VjdGlv biZuYnNwOzguNTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5EZWZpbmluZyBBZGRp dGlvbmFsIEVycm9yIENvZGVzPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPjoKCSAgCjwvcD48ZGl2 IHN0eWxlPSdkaXNwbGF5OiB0YWJsZTsgd2lkdGg6IDA7IG1hcmdpbi1sZWZ0OiAzZW07IG1hcmdp bi1yaWdodDogYXV0byc+PHByZT4KZXJyb3IgICAgICAgICAgICAgPSAxKk5RU0NIQVIKPC9wcmU+ PC9kaXY+CjxhIG5hbWU9ImFuY2hvcjYzIj48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5 PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIg YWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNw O1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uQS44 Ij48L2E+PGgzPkEuOC4mbmJzcDsKImVycm9yX2Rlc2NyaXB0aW9uIiBTeW50YXg8L2gzPgoKPHA+ CgkgICAgVGhlIDx0dD5lcnJvcl9kZXNjcmlwdGlvbjwvdHQ+IGVsZW1lbnQgaXMgZGVmaW5lZCBp bgoJICAgIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjY29kZS1hdXRoei1lcnJvcic+U2VjdGlvbiZu YnNwOzQuMS4yLjE8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+RXJyb3IgUmVzcG9u c2U8L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+LAoJICAgIDxhIGNsYXNzPSdpbmZvJyBocmVmPScj aW1wbGljaXQtYXV0aHotZXJyb3InPlNlY3Rpb24mbmJzcDs0LjIuMi4xPHNwYW4+ICg8L3NwYW4+ PHNwYW4gY2xhc3M9J2luZm8nPkVycm9yIFJlc3BvbnNlPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9h PiwKCSAgICA8YSBjbGFzcz0naW5mbycgaHJlZj0nI3Rva2VuLWVycm9ycyc+U2VjdGlvbiZuYnNw OzUuMjxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5FcnJvciBSZXNwb25zZTwvc3Bh bj48c3Bhbj4pPC9zcGFuPjwvYT4sIGFuZAoJICAgIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjcmVz b3VyY2UtZXJyb3JzJz5TZWN0aW9uJm5ic3A7Ny4yPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9 J2luZm8nPkVycm9yIFJlc3BvbnNlPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPjoKCSAgCjwvcD48 ZGl2IHN0eWxlPSdkaXNwbGF5OiB0YWJsZTsgd2lkdGg6IDA7IG1hcmdpbi1sZWZ0OiAzZW07IG1h cmdpbi1yaWdodDogYXV0byc+PHByZT4KZXJyb3ItZGVzY3JpcHRpb24gPSAxKk5RU0NIQVIKPC9w cmU+PC9kaXY+CjxhIG5hbWU9ImFuY2hvcjY0Ij48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1t YXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1 ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZu YnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24u QS45Ij48L2E+PGgzPkEuOS4mbmJzcDsKImVycm9yX3VyaSIgU3ludGF4PC9oMz4KCjxwPgoJICAg IFRoZSA8dHQ+ZXJyb3JfdXJpPC90dD4gZWxlbWVudCBpcyBkZWZpbmVkIGluCgkgICAgPGEgY2xh c3M9J2luZm8nIGhyZWY9JyNjb2RlLWF1dGh6LWVycm9yJz5TZWN0aW9uJm5ic3A7NC4xLjIuMTxz cGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5FcnJvciBSZXNwb25zZTwvc3Bhbj48c3Bh bj4pPC9zcGFuPjwvYT4sCgkgICAgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNpbXBsaWNpdC1hdXRo ei1lcnJvcic+U2VjdGlvbiZuYnNwOzQuMi4yLjE8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0n aW5mbyc+RXJyb3IgUmVzcG9uc2U8L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+LAoJICAgIDxhIGNs YXNzPSdpbmZvJyBocmVmPScjdG9rZW4tZXJyb3JzJz5TZWN0aW9uJm5ic3A7NS4yPHNwYW4+ICg8 L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkVycm9yIFJlc3BvbnNlPC9zcGFuPjxzcGFuPik8L3Nw YW4+PC9hPiwgYW5kCgkgICAgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNyZXNvdXJjZS1lcnJvcnMn PlNlY3Rpb24mbmJzcDs3LjI8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+RXJyb3Ig UmVzcG9uc2U8L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+OgoJICAKPC9wPjxkaXYgc3R5bGU9J2Rp c3BsYXk6IHRhYmxlOyB3aWR0aDogMDsgbWFyZ2luLWxlZnQ6IDNlbTsgbWFyZ2luLXJpZ2h0OiBh dXRvJz48cHJlPgplcnJvci11cmkgICAgICAgICA9IFVSSS1yZWZlcmVuY2UKPC9wcmU+PC9kaXY+ CjxhIG5hbWU9ImFuY2hvcjY1Ij48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlv dXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249 InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZu YnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uQS4xMCI+PC9h PjxoMz5BLjEwLiZuYnNwOwoiZ3JhbnRfdHlwZSIgU3ludGF4PC9oMz4KCjxwPgoJICAgIFRoZSA8 dHQ+Z3JhbnRfdHlwZTwvdHQ+IGVsZW1lbnQgaXMgZGVmaW5lZCBpbgoJICAgIDxhIGNsYXNzPSdp bmZvJyBocmVmPScjdG9rZW4tcmVxJz5TZWN0aW9uJm5ic3A7NC4xLjM8c3Bhbj4gKDwvc3Bhbj48 c3BhbiBjbGFzcz0naW5mbyc+QWNjZXNzIFRva2VuIFJlcXVlc3Q8L3NwYW4+PHNwYW4+KTwvc3Bh bj48L2E+LAoJICAgIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjcGFzc3dvcmQtdG9rLXJlcSc+U2Vj dGlvbiZuYnNwOzQuMy4yPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkFjY2VzcyBU b2tlbiBSZXF1ZXN0PC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPiwKCSAgICA8YSBjbGFzcz0naW5m bycgaHJlZj0nI2NsaWVudC1yZXEnPlNlY3Rpb24mbmJzcDs0LjQuMjxzcGFuPiAoPC9zcGFuPjxz cGFuIGNsYXNzPSdpbmZvJz5BY2Nlc3MgVG9rZW4gUmVxdWVzdDwvc3Bhbj48c3Bhbj4pPC9zcGFu PjwvYT4sCgkgICAgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyN0b2tlbi1yZWZyZXNoJz5TZWN0aW9u Jm5ic3A7NjxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5SZWZyZXNoaW5nIGFuIEFj Y2VzcyBUb2tlbjwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4sIGFuZAoJICAgIDxhIGNsYXNzPSdp bmZvJyBocmVmPScjZXh0LWdyYW50Jz5TZWN0aW9uJm5ic3A7NC41PHNwYW4+ICg8L3NwYW4+PHNw YW4gY2xhc3M9J2luZm8nPkV4dGVuc2lvbiBHcmFudHM8L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+ OgoJICAKPC9wPjxkaXYgc3R5bGU9J2Rpc3BsYXk6IHRhYmxlOyB3aWR0aDogMDsgbWFyZ2luLWxl ZnQ6IDNlbTsgbWFyZ2luLXJpZ2h0OiBhdXRvJz48cHJlPgpncmFudC10eXBlID0gZ3JhbnQtbmFt ZSAvIFVSSS1yZWZlcmVuY2UKZ3JhbnQtbmFtZSA9IDEqbmFtZS1jaGFyCm5hbWUtY2hhciAgPSAi LSIgLyAiLiIgLyAiXyIgLyBESUdJVCAvIEFMUEhBCjwvcHJlPjwvZGl2Pgo8YSBuYW1lPSJhbmNo b3I2NiI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGlu Zz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0 ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48 L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLkEuMTEiPjwvYT48aDM+QS4xMS4mbmJz cDsKImNvZGUiIFN5bnRheDwvaDM+Cgo8cD4KCSAgICBUaGUgPHR0PmNvZGU8L3R0PiBlbGVtZW50 IGlzIGRlZmluZWQgaW4KCSAgICA8YSBjbGFzcz0naW5mbycgaHJlZj0nI3Rva2VuLXJlcSc+U2Vj dGlvbiZuYnNwOzQuMS4zPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkFjY2VzcyBU b2tlbiBSZXF1ZXN0PC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPjoKCSAgCjwvcD48ZGl2IHN0eWxl PSdkaXNwbGF5OiB0YWJsZTsgd2lkdGg6IDA7IG1hcmdpbi1sZWZ0OiAzZW07IG1hcmdpbi1yaWdo dDogYXV0byc+PHByZT4KY29kZSAgICAgICA9IDEqVlNDSEFSCjwvcHJlPjwvZGl2Pgo8YSBuYW1l PSJhbmNob3I2NyI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxs cGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+ PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+ PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLkEuMTIiPjwvYT48aDM+QS4x Mi4mbmJzcDsKImFjY2Vzc190b2tlbiIgU3ludGF4PC9oMz4KCjxwPgoJICAgIFRoZSA8dHQ+YWNj ZXNzX3Rva2VuPC90dD4gZWxlbWVudCBpcyBkZWZpbmVkIGluCgkgICAgPGEgY2xhc3M9J2luZm8n IGhyZWY9JyNpbXBsaWNpdC1hdXRoei1yZXNwJz5TZWN0aW9uJm5ic3A7NC4yLjI8c3Bhbj4gKDwv c3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+QWNjZXNzIFRva2VuIFJlc3BvbnNlPC9zcGFuPjxzcGFu Pik8L3NwYW4+PC9hPiBhbmQKCSAgICA8YSBjbGFzcz0naW5mbycgaHJlZj0nI3Rva2VuLXJlc3Bv bnNlJz5TZWN0aW9uJm5ic3A7NS4xPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPlN1 Y2Nlc3NmdWwgUmVzcG9uc2U8L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+OgoJICAKPC9wPjxkaXYg c3R5bGU9J2Rpc3BsYXk6IHRhYmxlOyB3aWR0aDogMDsgbWFyZ2luLWxlZnQ6IDNlbTsgbWFyZ2lu LXJpZ2h0OiBhdXRvJz48cHJlPgphY2Nlc3MtdG9rZW4gPSAxKlZTQ0hBUgo8L3ByZT48L2Rpdj4K PGEgbmFtZT0iYW5jaG9yNjgiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91 dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0i cmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5i c3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi5BLjEzIj48L2E+ PGgzPkEuMTMuJm5ic3A7CiJ0b2tlbl90eXBlIiBTeW50YXg8L2gzPgoKPHA+CgkgICAgVGhlIDx0 dD50b2tlbl90eXBlPC90dD4gZWxlbWVudCBpcyBkZWZpbmVkIGluCgkgICAgPGEgY2xhc3M9J2lu Zm8nIGhyZWY9JyNpbXBsaWNpdC1hdXRoei1yZXNwJz5TZWN0aW9uJm5ic3A7NC4yLjI8c3Bhbj4g KDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+QWNjZXNzIFRva2VuIFJlc3BvbnNlPC9zcGFuPjxz cGFuPik8L3NwYW4+PC9hPiwKCSAgICA8YSBjbGFzcz0naW5mbycgaHJlZj0nI3Rva2VuLXJlc3Bv bnNlJz5TZWN0aW9uJm5ic3A7NS4xPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPlN1 Y2Nlc3NmdWwgUmVzcG9uc2U8L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+LCBhbmQKCSAgICA8YSBj bGFzcz0naW5mbycgaHJlZj0nI25ldy10eXBlcyc+U2VjdGlvbiZuYnNwOzguMTxzcGFuPiAoPC9z cGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5EZWZpbmluZyBBY2Nlc3MgVG9rZW4gVHlwZXM8L3NwYW4+ PHNwYW4+KTwvc3Bhbj48L2E+OgoJICAKPC9wPjxkaXYgc3R5bGU9J2Rpc3BsYXk6IHRhYmxlOyB3 aWR0aDogMDsgbWFyZ2luLWxlZnQ6IDNlbTsgbWFyZ2luLXJpZ2h0OiBhdXRvJz48cHJlPgp0b2tl bi10eXBlID0gdHlwZS1uYW1lIC8gVVJJLXJlZmVyZW5jZQp0eXBlLW5hbWUgID0gMSpuYW1lLWNo YXIKbmFtZS1jaGFyICA9ICItIiAvICIuIiAvICJfIiAvIERJR0lUIC8gQUxQSEEKPC9wcmU+PC9k aXY+CjxhIG5hbWU9ImFuY2hvcjY5Ij48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJs YXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxp Z249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RP QyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uQS4xNCI+ PC9hPjxoMz5BLjE0LiZuYnNwOwoiZXhwaXJlc19pbiIgU3ludGF4PC9oMz4KCjxwPgoJICAgIFRo ZSA8dHQ+ZXhwaXJlc19pbjwvdHQ+IGVsZW1lbnQgaXMgZGVmaW5lZCBpbgoJICAgIDxhIGNsYXNz PSdpbmZvJyBocmVmPScjaW1wbGljaXQtYXV0aHotcmVzcCc+U2VjdGlvbiZuYnNwOzQuMi4yPHNw YW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkFjY2VzcyBUb2tlbiBSZXNwb25zZTwvc3Bh bj48c3Bhbj4pPC9zcGFuPjwvYT4gYW5kCgkgICAgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyN0b2tl bi1yZXNwb25zZSc+U2VjdGlvbiZuYnNwOzUuMTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdp bmZvJz5TdWNjZXNzZnVsIFJlc3BvbnNlPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPjoKCSAgCjwv cD48ZGl2IHN0eWxlPSdkaXNwbGF5OiB0YWJsZTsgd2lkdGg6IDA7IG1hcmdpbi1sZWZ0OiAzZW07 IG1hcmdpbi1yaWdodDogYXV0byc+PHByZT4KZXhwaXJlcy1pbiA9IDEqRElHSVQKPC9wcmU+PC9k aXY+CjxhIG5hbWU9ImFuY2hvcjcwIj48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJs YXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxp Z249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RP QyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uQS4xNSI+ PC9hPjxoMz5BLjE1LiZuYnNwOwoidXNlcm5hbWUiIFN5bnRheDwvaDM+Cgo8cD4KCSAgICBUaGUg PHR0PnVzZXJuYW1lPC90dD4gZWxlbWVudCBpcyBkZWZpbmVkIGluCgkgICAgPGEgY2xhc3M9J2lu Zm8nIGhyZWY9JyNwYXNzd29yZC10b2stcmVxJz5TZWN0aW9uJm5ic3A7NC4zLjI8c3Bhbj4gKDwv c3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+QWNjZXNzIFRva2VuIFJlcXVlc3Q8L3NwYW4+PHNwYW4+ KTwvc3Bhbj48L2E+OgoJICAKPC9wPjxkaXYgc3R5bGU9J2Rpc3BsYXk6IHRhYmxlOyB3aWR0aDog MDsgbWFyZ2luLWxlZnQ6IDNlbTsgbWFyZ2luLXJpZ2h0OiBhdXRvJz48cHJlPgp1c2VybmFtZSA9 ICooICV4MjAtMzkgLyAleDNCLTdFICkKPC9wcmU+PC9kaXY+CjxwPgoJICAoVGhpcyBhbGxvd2Vk IGNoYXJhY3RlciBzZXQgaXMgVlNDSEFSIGV4Y2x1ZGluZyAiOiIuCgkgIFRoaXMgaXMgY29tcGF0 aWJsZSB3aXRoIHRoZSA8dHQ+dXNlcmlkPC90dD4KCSAgZGVmaW5pdGlvbiBpbiB0aGUKCSAgSFRU UCBCYXNpYyBBdXRoZW50aWNhdGlvbiBTY2hlbWUgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNSRkMy NjE3Jz5bUkZDMjYxN108c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+RnJhbmtzLCBK LiwgSGFsbGFtLUJha2VyLCBQLiwgSG9zdGV0bGVyLCBKLiwgTGF3cmVuY2UsIFMuLCBMZWFjaCwg UC4sIEx1b3RvbmVuLCBBLiwgYW5kIEwuIFN0ZXdhcnQsICZsZHF1bztIVFRQIEF1dGhlbnRpY2F0 aW9uOiBCYXNpYyBhbmQgRGlnZXN0IEFjY2VzcyBBdXRoZW50aWNhdGlvbiwmcmRxdW87IEp1bmUm bmJzcDsxOTk5Ljwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4uKQoJCjwvcD4KPGEgbmFtZT0iYW5j aG9yNzEiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRp bmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48 dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+ PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi5BLjE2Ij48L2E+PGgzPkEuMTYuJm5i c3A7CiJwYXNzd29yZCIgU3ludGF4PC9oMz4KCjxwPgoJICAgIFRoZSA8dHQ+cGFzc3dvcmQ8L3R0 PiBlbGVtZW50IGlzIGRlZmluZWQgaW4KCSAgICA8YSBjbGFzcz0naW5mbycgaHJlZj0nI3Bhc3N3 b3JkLXRvay1yZXEnPlNlY3Rpb24mbmJzcDs0LjMuMjxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNz PSdpbmZvJz5BY2Nlc3MgVG9rZW4gUmVxdWVzdDwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT46Cgkg IAo8L3A+PGRpdiBzdHlsZT0nZGlzcGxheTogdGFibGU7IHdpZHRoOiAwOyBtYXJnaW4tbGVmdDog M2VtOyBtYXJnaW4tcmlnaHQ6IGF1dG8nPjxwcmU+CnBhc3N3b3JkID0gKlZTQ0hBUgo8L3ByZT48 L2Rpdj4KPHA+CgkgIChUaGlzIG1hdGNoZXMgdGhlIDx0dD5wYXNzd29yZDwvdHQ+IGRlZmluaXRp b24gaW4gdGhlCgkgIEhUVFAgQmFzaWMgQXV0aGVudGljYXRpb24gU2NoZW1lIDxhIGNsYXNzPSdp bmZvJyBocmVmPScjUkZDMjYxNyc+W1JGQzI2MTddPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9 J2luZm8nPkZyYW5rcywgSi4sIEhhbGxhbS1CYWtlciwgUC4sIEhvc3RldGxlciwgSi4sIExhd3Jl bmNlLCBTLiwgTGVhY2gsIFAuLCBMdW90b25lbiwgQS4sIGFuZCBMLiBTdGV3YXJ0LCAmbGRxdW87 SFRUUCBBdXRoZW50aWNhdGlvbjogQmFzaWMgYW5kIERpZ2VzdCBBY2Nlc3MgQXV0aGVudGljYXRp b24sJnJkcXVvOyBKdW5lJm5ic3A7MTk5OS48L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+LikKCQo8 L3A+CjxhIG5hbWU9ImFuY2hvcjcyIj48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJs YXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxp Z249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RP QyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uQS4xNyI+ PC9hPjxoMz5BLjE3LiZuYnNwOwoicmVmcmVzaF90b2tlbiIgU3ludGF4PC9oMz4KCjxwPgoJICAg IFRoZSA8dHQ+cmVmcmVzaF90b2tlbjwvdHQ+IGVsZW1lbnQgaXMgZGVmaW5lZCBpbgoJICAgIDxh IGNsYXNzPSdpbmZvJyBocmVmPScjdG9rZW4tcmVzcG9uc2UnPlNlY3Rpb24mbmJzcDs1LjE8c3Bh bj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+U3VjY2Vzc2Z1bCBSZXNwb25zZTwvc3Bhbj48 c3Bhbj4pPC9zcGFuPjwvYT4gYW5kCgkgICAgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyN0b2tlbi1y ZWZyZXNoJz5TZWN0aW9uJm5ic3A7NjxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5S ZWZyZXNoaW5nIGFuIEFjY2VzcyBUb2tlbjwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT46CgkgIAo8 L3A+PGRpdiBzdHlsZT0nZGlzcGxheTogdGFibGU7IHdpZHRoOiAwOyBtYXJnaW4tbGVmdDogM2Vt OyBtYXJnaW4tcmlnaHQ6IGF1dG8nPjxwcmU+CnJlZnJlc2gtdG9rZW4gPSAxKlZTQ0hBUgo8L3By ZT48L2Rpdj4KPGEgbmFtZT0iYW5jaG9yNzMiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1h cnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVn IiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5i c3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi5B LjE4Ij48L2E+PGgzPkEuMTguJm5ic3A7CkVuZHBvaW50IFBhcmFtZXRlciBTeW50YXg8L2gzPgoK PHA+CgkgICAgVGhlIHN5bnRheCBmb3IgbmV3IGVuZHBvaW50IHBhcmFtZXRlcnMgaXMgZGVmaW5l ZCBpbgoJICAgIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjZW5kcG9pbnQtcGFyYW1zJz5TZWN0aW9u Jm5ic3A7OC4yPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkRlZmluaW5nIE5ldyBF bmRwb2ludCBQYXJhbWV0ZXJzPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPjoKCSAgCjwvcD48ZGl2 IHN0eWxlPSdkaXNwbGF5OiB0YWJsZTsgd2lkdGg6IDA7IG1hcmdpbi1sZWZ0OiAzZW07IG1hcmdp bi1yaWdodDogYXV0byc+PHByZT4KcGFyYW0tbmFtZSA9IDEqbmFtZS1jaGFyCm5hbWUtY2hhciAg PSAiLSIgLyAiLiIgLyAiXyIgLyBESUdJVCAvIEFMUEhBCjwvcHJlPjwvZGl2Pgo8YSBuYW1lPSJh bmNob3I3NCI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFk ZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRy Pjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90 ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLkIiPjwvYT48aDM+QXBwZW5kaXgg Qi4mbmJzcDsKQWNrbm93bGVkZ2VtZW50czwvaDM+Cgo8cD4KICAgICAgICBUaGUgaW5pdGlhbCBP QXV0aCAyLjAgcHJvdG9jb2wgc3BlY2lmaWNhdGlvbiB3YXMgZWRpdGVkIGJ5IERhdmlkIFJlY29y ZG9uLCBiYXNlZCBvbiB0d28KICAgICAgICBwcmV2aW91cyBwdWJsaWNhdGlvbnM6IHRoZSBPQXV0 aCAxLjAgY29tbXVuaXR5IHNwZWNpZmljYXRpb24gPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNSRkM1 ODQ5Jz5bUkZDNTg0OV08c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+SGFtbWVyLUxh aGF2LCBFLiwgJmxkcXVvO1RoZSBPQXV0aCAxLjAgUHJvdG9jb2wsJnJkcXVvOyBBcHJpbCZuYnNw OzIwMTAuPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPiwgYW5kCiAgICAgICAgT0F1dGggV1JBUCAo T0F1dGggV2ViIFJlc291cmNlIEF1dGhvcml6YXRpb24gUHJvZmlsZXMpCiAgICAgICAgPGEgY2xh c3M9J2luZm8nIGhyZWY9JyNJLUQuZHJhZnQtaGFyZHQtb2F1dGgtMDEnPltJJiM4MjA5O0QuZHJh ZnQmIzgyMDk7aGFyZHQmIzgyMDk7b2F1dGgmIzgyMDk7MDFdPHNwYW4+ICg8L3NwYW4+PHNwYW4g Y2xhc3M9J2luZm8nPkhhcmR0LCBELiwgRWQuLCBUb20sIEEuLCBFYXRvbiwgQi4sIGFuZCBZLiBH b2xhbmQsICZsZHF1bztPQXV0aCBXZWIgUmVzb3VyY2UgQXV0aG9yaXphdGlvbiBQcm9maWxlcywm cmRxdW87IEphbnVhcnkmbmJzcDsyMDEwLjwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4uIFRoZSBT ZWN1cml0eSBDb25zaWRlcmF0aW9ucyBzZWN0aW9uIHdhcyBkcmFmdGVkCiAgICAgICAgYnkgVG9y c3RlbiBMb2RkZXJzdGVkdCwgTWFyayBNY0dsb2luLCBQaGlsIEh1bnQsIGFuZCBBbnRob255IE5h ZGFsaW4uCglUaGUgQUJORiBzZWN0aW9uIHdhcyBkcmFmdGVkIGJ5IE1pY2hhZWwgQi4gSm9uZXMu CiAgICAgIAo8L3A+CjxwPgogICAgICAgIFRoZSBPQXV0aCAxLjAgY29tbXVuaXR5IHNwZWNpZmlj YXRpb24gd2FzIGVkaXRlZCBieSBFcmFuIEhhbW1lciBhbmQgYXV0aG9yZWQgYnkKICAgICAgICBN YXJrIEF0d29vZCwgRGlyayBCYWxmYW56LCBEYXJyZW4gQm91bmRzLCBSaWNoYXJkIE0uIENvbmxh biwgQmxhaW5lIENvb2ssIExlYWggQ3VsdmVyLAogICAgICAgIEJyZW5vIGRlIE1lZGVpcm9zLCBC cmlhbiBFYXRvbiwgS2VsbGFuIEVsbGlvdHQtTWNDcmVhLCBMYXJyeSBIYWxmZiwgRXJhbiBIYW1t ZXIsCiAgICAgICAgQmVuIExhdXJpZSwgQ2hyaXMgTWVzc2luYSwgSm9obiBQYW56ZXIsIFNhbSBR dWlnbGV5LCBEYXZpZCBSZWNvcmRvbiwgRXJhbiBTYW5kbGVyLAogICAgICAgIEpvbmF0aGFuIFNl cmdlbnQsIFRvZGQgU2llbGluZywgQnJpYW4gU2xlc2luc2t5LCBhbmQgQW5keSBTbWl0aC4KICAg ICAgCjwvcD4KPHA+CiAgICAgICAgVGhlIE9BdXRoIFdSQVAgc3BlY2lmaWNhdGlvbiB3YXMgZWRp dGVkIGJ5IERpY2sgSGFyZHQgYW5kIGF1dGhvcmVkIGJ5IEJyaWFuIEVhdG9uLAogICAgICAgIFlh cm9uIFkuIEdvbGFuZCwgRGljayBIYXJkdCwgYW5kIEFsbGVuIFRvbS4KICAgICAgCjwvcD4KPHA+ CiAgICAgICAgVGhpcyBzcGVjaWZpY2F0aW9uIGlzIHRoZSB3b3JrIG9mIHRoZSBPQXV0aCBXb3Jr aW5nIEdyb3VwIHdoaWNoIGluY2x1ZGVzIGRvemVucyBvZiBhY3RpdmUKICAgICAgICBhbmQgZGVk aWNhdGVkIHBhcnRpY2lwYW50cy4gSW4gcGFydGljdWxhciwgdGhlIGZvbGxvd2luZyBpbmRpdmlk dWFscyBjb250cmlidXRlZCBpZGVhcywKICAgICAgICBmZWVkYmFjaywgYW5kIHdvcmRpbmcgd2hp Y2ggc2hhcGVkIGFuZCBmb3JtZWQgdGhlIGZpbmFsIHNwZWNpZmljYXRpb246CiAgICAgIAo8L3A+ CjxwPgogICAgICAgIE1pY2hhZWwgQWRhbXMsIEFtYW5kYSBBbmdhbmVzLCBBbmRyZXcgQXJub3R0 LCBEaXJrIEJhbGZhbnosIEFpZGVuIEJlbGwsIEpvaG4gQnJhZGxleSwgQnJpYW4gQ2FtcGJlbGws CiAgICAgICAgU2NvdHQgQ2FudG9yLCBNYXJjb3MgQ2FjZXJlcywgQmxhaW5lIENvb2ssIFJvZ2Vy IENyZXcsIEJyaWFuIEVhdG9uLCBXZXNsZXkgRWRkeSwgTGVhaCBDdWx2ZXIsCiAgICAgICAgQmls bCBkZSBoT3JhLCBBbmRyZSBEZU1hcnJlLCBCcmlhbiBFYXRvbiwgV29sdGVyIEVsZGVyaW5nLCBC cmlhbiBFbGxpbiwgSWdvciBGYXluYmVyZywKICAgICAgICBHZW9yZ2UgRmxldGNoZXIsIFRpbSBG cmVlbWFuLCBMdWNhIEZyb3NpbmksIEV2YW4gR2lsYmVydCwgWWFyb24gWS4gR29sYW5kLCBCcmVu dCBHb2xkbWFuLAogICAgICAgIEtyaXN0b2ZmZXIgR3Jvbm93c2tpLCBKdXN0aW4gSGFydCwgRGlj ayBIYXJkdCwgQ3JhaWcgSGVhdGgsIFBoaWwgSHVudCwgTWljaGFlbCBCLiBKb25lcywKICAgICAg ICBUZXJyeSBKb25lcywgSm9obiBLZW1wLCBNYXJrIEtlbnQsIFJhZmZpIEtyaWtvcmlhbiwgQ2hh c2VuIExlIEhhcmEsIFJhc211cyBMZXJkb3JmLAogICAgICAgIFRvcnN0ZW4gTG9kZGVyc3RlZHQs IEh1aS1MYW4gTHUsIENhc2V5IEx1Y2FzLCBQYXVsIE1hZHNlbiwgQWxhc3RhaXIgTWFpciwgRXZl IE1hbGVyLAogICAgICAgIEphbWVzIE1hbmdlciwgTWFyayBNY0dsb2luLCBMYXVyZW5jZSBNaWFv LCBXaWxsaWFtIE1pbGxzLCBDaHVjayBNb3J0aW1vcmUsIEFudGhvbnkgTmFkYWxpbiwKICAgICAg ICBKdWxpYW4gUmVzY2hrZSwgSnVzdGluIFJpY2hlciwgUGV0ZXIgU2FpbnQtQW5kcmUsIE5hdCBT YWtpbXVyYSwgUm9iIFNheXJlLAogICAgICAgIE1hcml1cyBTY3VydGVzY3UsIE5haXRpayBTaGFo LCBMdWtlIFNoZXBhcmQsIFZsYWQgU2t2b3J0c292LCBKdXN0aW4gU21pdGgsIEhhaWJpbiBTb25n LAogICAgICAgIE5pdiBTdGVpbmdhcnRlbiwgQ2hyaXN0aWFuIFN0dWJuZXIsIEplcmVteSBTdXJp ZWwsIFBhdWwgVGFyamFuLCBDaHJpc3RvcGhlciBUaG9tYXMsCiAgICAgICAgSGVucnkgUy4gVGhv bXBzb24sIEFsbGVuIFRvbSwgRnJhbmtsaW4gVHNlLCBOaWNrIFdhbGtlciwgU2hhbmUgV2VlZGVu LCBhbmQgU2t5bGFyIFdvb2R3YXJkLgogICAgICAKPC9wPgo8cD4KICAgICAgICBUaGlzIGRvY3Vt ZW50IHdhcyBwcm9kdWNlZCB1bmRlciB0aGUgY2hhaXJtYW5zaGlwIG9mIEJsYWluZSBDb29rLCBQ ZXRlciBTYWludC1BbmRyZSwKICAgICAgICBIYW5uZXMgVHNjaG9mZW5pZywgQmFycnkgTGVpYmEs IGFuZCBEZXJlayBBdGtpbnMuIFRoZSBhcmVhIGRpcmVjdG9ycyBpbmNsdWRlZCBMaXNhIER1c3Nl YXVsdCwKICAgICAgICBQZXRlciBTYWludC1BbmRyZSwgYW5kIFN0ZXBoZW4gRmFycmVsbC4KICAg ICAgCjwvcD4KPGEgbmFtZT0iYW5jaG9yNzUiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1h cnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVn IiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5i c3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi5D Ij48L2E+PGgzPkFwcGVuZGl4IEMuJm5ic3A7CkVkaXRvcidzIE5vdGVzPC9oMz4KCjxwPgogICAg ICAgIFdoaWxlIG1hbnkgcGVvcGxlIGNvbnRyaWJ1dGVkIHRvIHRoaXMgc3BlY2lmaWNhdGlvbiB0 aHJvdWdob3V0IGl0cyBsb25nIGpvdXJuZXksIHRoZSBlZGl0b3IKICAgICAgICB3b3VsZCBsaWtl IHRvIGFja25vd2xlZGdlIGFuZCB0aGFuayBhIGZldyBpbmRpdmlkdWFscyBmb3IgdGhlaXIgb3V0 c3RhbmRpbmcgYW5kIGludmFsdWFibGUKICAgICAgICBlZmZvcnRzIGxlYWRpbmcgdXAgdG8gdGhl IHB1YmxpY2F0aW9uIG9mIHRoaXMgc3BlY2lmaWNhdGlvbi4KICAgICAgCjwvcD4KPHA+CiAgICAg ICAgRGF2aWQgUmVjb3Jkb24gZm9yIGNvbnRpbnVvdXNseSBiZWluZyBvbmUgb2YgT0F1dGgncyBt b3N0IHZhbHVhYmxlIGFzc2V0cywgYnJpbmdpbmcKICAgICAgICBwcmFnbWF0aXNtIGFuZCB1cmdl bmN5IHRvIHRoZSB3b3JrLCBhbmQgaGVscGluZyBzaGFwZSBpdCBmcm9tIGl0cyB2ZXJ5IGJlZ2lu bmluZywgYXMgd2VsbAogICAgICAgIGFzIGJlaW5nIG9uZSBvZiB0aGUgYmVzdCBjb2xsYWJvcmF0 b3JzIEkgaGFkIHRoZSBwbGVhc3VyZSBvZiB3b3JraW5nIHdpdGguCiAgICAgIAo8L3A+CjxwPgog ICAgICAgIEphbWVzIE1hbmdlciBmb3IgaGlzIGNyZWF0aXZlIGlkZWFzIGFuZCBhbHdheXMgaW5z aWdodGZ1bCBmZWVkYmFjay4gQnJpYW4gQ2FtcGJlbGwsCiAgICAgICAgVG9yc3RlbiBMb2RkZXJz dGVkdCwgQ2h1Y2sgTW9ydGltb3JlLCBKdXN0aW4gUmljaGVyLCBNYXJpdXMgU2N1cnRlc2N1LCBh bmQgTHVrZSBTaGVwYXJkIGZvcgogICAgICAgIHRoZWlyIGNvbnRpbnVlZCBwYXJ0aWNpcGF0aW9u IGFuZCB2YWx1YWJsZSBmZWVkYmFjay4KICAgICAgCjwvcD4KPHA+CiAgICAgICAgU3BlY2lhbCB0 aGFua3MgZ29lcyB0byBNaWtlIEN1cnRpcyBhbmQgWWFob28hIGZvciB0aGVpciB1bmNvbmRpdGlv bmFsIHN1cHBvcnQgb2YgdGhpcyB3b3JrCiAgICAgICAgZm9yIG92ZXIgdGhyZWUgeWVhcnMuCiAg ICAgIAo8L3A+CjxhIG5hbWU9InJmYy5hdXRob3JzIj48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBz dW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRP Q2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2Mi PiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGgzPkF1dGhvcnMnIEFkZHJl c3NlczwvaDM+Cjx0YWJsZSB3aWR0aD0iOTklIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiBj ZWxsc3BhY2luZz0iMCI+Cjx0cj48dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij4mbmJzcDs8L3RkPgo8 dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij5FcmFuIEhhbW1lciAoZWRpdG9yKTwvdGQ+PC90cj4KPHRy Pjx0ZCBjbGFzcz0iYXV0aG9yIiBhbGlnbj0icmlnaHQiPkVtYWlsOiZuYnNwOzwvdGQ+Cjx0ZCBj bGFzcz0iYXV0aG9yLXRleHQiPjxhIGhyZWY9Im1haWx0bzplcmFuQGh1ZW5pdmVyc2UuY29tIj5l cmFuQGh1ZW5pdmVyc2UuY29tPC9hPjwvdGQ+PC90cj4KPHRyPjx0ZCBjbGFzcz0iYXV0aG9yIiBh bGlnbj0icmlnaHQiPlVSSTombmJzcDs8L3RkPgo8dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij48YSBo cmVmPSJodHRwOi8vaHVlbml2ZXJzZS5jb20iPmh0dHA6Ly9odWVuaXZlcnNlLmNvbTwvYT48L3Rk PjwvdHI+Cjx0ciBjZWxscGFkZGluZz0iMyI+PHRkPiZuYnNwOzwvdGQ+PHRkPiZuYnNwOzwvdGQ+ PC90cj4KPHRyPjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPiZuYnNwOzwvdGQ+Cjx0ZCBjbGFzcz0i YXV0aG9yLXRleHQiPkRhdmlkIFJlY29yZG9uPC90ZD48L3RyPgo8dHI+PHRkIGNsYXNzPSJhdXRo b3ItdGV4dCI+Jm5ic3A7PC90ZD4KPHRkIGNsYXNzPSJhdXRob3ItdGV4dCI+RmFjZWJvb2s8L3Rk PjwvdHI+Cjx0cj48dGQgY2xhc3M9ImF1dGhvciIgYWxpZ249InJpZ2h0Ij5FbWFpbDombmJzcDs8 L3RkPgo8dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij48YSBocmVmPSJtYWlsdG86ZHJAZmIuY29tIj5k ckBmYi5jb208L2E+PC90ZD48L3RyPgo8dHI+PHRkIGNsYXNzPSJhdXRob3IiIGFsaWduPSJyaWdo dCI+VVJJOiZuYnNwOzwvdGQ+Cjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPjxhIGhyZWY9Imh0dHA6 Ly93d3cuZGF2aWRyZWNvcmRvbi5jb20vIj5odHRwOi8vd3d3LmRhdmlkcmVjb3Jkb24uY29tLzwv YT48L3RkPjwvdHI+Cjx0ciBjZWxscGFkZGluZz0iMyI+PHRkPiZuYnNwOzwvdGQ+PHRkPiZuYnNw OzwvdGQ+PC90cj4KPHRyPjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPiZuYnNwOzwvdGQ+Cjx0ZCBj bGFzcz0iYXV0aG9yLXRleHQiPkRpY2sgSGFyZHQ8L3RkPjwvdHI+Cjx0cj48dGQgY2xhc3M9ImF1 dGhvci10ZXh0Ij4mbmJzcDs8L3RkPgo8dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij5NaWNyb3NvZnQ8 L3RkPjwvdHI+Cjx0cj48dGQgY2xhc3M9ImF1dGhvciIgYWxpZ249InJpZ2h0Ij5FbWFpbDombmJz cDs8L3RkPgo8dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij48YSBocmVmPSJtYWlsdG86ZGljay5oYXJk dEBnbWFpbC5jb20iPmRpY2suaGFyZHRAZ21haWwuY29tPC9hPjwvdGQ+PC90cj4KPHRyPjx0ZCBj bGFzcz0iYXV0aG9yIiBhbGlnbj0icmlnaHQiPlVSSTombmJzcDs8L3RkPgo8dGQgY2xhc3M9ImF1 dGhvci10ZXh0Ij48YSBocmVmPSJodHRwOi8vZGlja2hhcmR0Lm9yZy8iPmh0dHA6Ly9kaWNraGFy ZHQub3JnLzwvYT48L3RkPjwvdHI+CjwvdGFibGU+CjwvYm9keT48L2h0bWw+Cg== --_006_4E1F6AAD24975D4BA5B16804296739436652EBF0TK5EX14MBXC284r_-- From julian.reschke@gmx.de Fri Jun 8 02:52:33 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 099EB21F8701 for ; Fri, 8 Jun 2012 02:52:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.164 X-Spam-Level: X-Spam-Status: No, score=-104.164 tagged_above=-999 required=5 tests=[AWL=-1.565, 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 SRQEMjjEWWNi for ; Fri, 8 Jun 2012 02:52:32 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 7E73B21F86FE for ; Fri, 8 Jun 2012 02:52:30 -0700 (PDT) Received: (qmail invoked by alias); 08 Jun 2012 09:52:28 -0000 Received: from p5DD972CB.dip.t-dialin.net (EHLO [192.168.178.36]) [93.217.114.203] by mail.gmx.net (mp028) with SMTP; 08 Jun 2012 11:52:28 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+c1xVX63+cc4qPU3ydd6ChOVhZA3S5U3d5FUsSVd Gdo0nLVQX7bLnJ Message-ID: <4FD1CB56.3040702@gmx.de> Date: Fri, 08 Jun 2012 11:52:22 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120604 Thunderbird/13.0 MIME-Version: 1.0 To: Mike Jones References: <4E1F6AAD24975D4BA5B16804296739436652EBF0@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436652EBF0@TK5EX14MBXC284.redmond.corp.microsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Draft OAuth Core spec changes updating proposed ABNF X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 09:52:33 -0000 On 2012-06-08 09:56, Mike Jones wrote: > The attached proposed edits to the Core spec update the ABNF to remove > the character set restrictions that working group participants had > objected to, and to define common syntax elements, where appropriate. > After working group review, I believe that these changes are ready to be > checked in for draft 27 after being merged with whatever other changes > Eran has made. > ... As far as I can tell, you have chosen to restrict everything to US-ASCII. That definitively makes the ABNF and the wire representation simpler, but it does break I18N big time. And please don't tell me that people do not use non-ASCII characters in credentials (-> ). Focusing on username and password... If this relates to the use in Basic and Digest, it's fine that it has their current limitations; but in that case the ABNF shouldn't invent new productions and claim that they match 2617's when they do not. If this relates to uses of usernames and passwords outside Basic and Digest (thus new uses), then I believe the proposed solution is not acceptable. Best regards, Julian From Adam.Lewis@motorolasolutions.com Fri Jun 8 06:28:23 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 834B021F8673 for ; Fri, 8 Jun 2012 06:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.217 X-Spam-Level: X-Spam-Status: No, score=-1.217 tagged_above=-999 required=5 tests=[AWL=-0.750, BAYES_00=-2.599, 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 pDmc4DtIX3-g for ; Fri, 8 Jun 2012 06:28:23 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe001.messaging.microsoft.com [216.32.181.181]) by ietfa.amsl.com (Postfix) with ESMTP id D899F21F867C for ; Fri, 8 Jun 2012 06:28:22 -0700 (PDT) Received: from mail80-ch1-R.bigfish.com (10.43.68.245) by CH1EHSOBE016.bigfish.com (10.43.70.66) with Microsoft SMTP Server id 14.1.225.23; Fri, 8 Jun 2012 13:27:31 +0000 Received: from mail80-ch1 (localhost [127.0.0.1]) by mail80-ch1-R.bigfish.com (Postfix) with ESMTP id EF90DE00C1 for ; Fri, 8 Jun 2012 13:27:30 +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: -1 X-BigFish: VPS-1(zz14ffIzz1202hzzz2fh2a8h683h839h944hd25hf0ah) Received-SPF: pass (mail80-ch1: 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.240.85; KIP:(null); UIP:(null); (null); H:BL2PRD0410HT001.namprd04.prod.outlook.com; R:internal; EFV:INT Received: from mail80-ch1 (localhost.localdomain [127.0.0.1]) by mail80-ch1 (MessageSwitch) id 1339162048512537_26113; Fri, 8 Jun 2012 13:27:28 +0000 (UTC) Received: from CH1EHSMHS029.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.226]) by mail80-ch1.bigfish.com (Postfix) with ESMTP id 7B8BE2A004A for ; Fri, 8 Jun 2012 13:27:28 +0000 (UTC) Received: from ct11msg01.am.mot-solutions.com (192.160.210.20) by CH1EHSMHS029.bigfish.com (10.43.70.29) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 8 Jun 2012 13:27:28 +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 q58DfskI003855 for ; Fri, 8 Jun 2012 08:41:59 -0500 (CDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe003.messaging.microsoft.com [213.199.154.141]) by ct11msg01.am.mot-solutions.com (8.14.3/8.14.3) with ESMTP id q58DfqGX003843 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 8 Jun 2012 08:41:54 -0500 (CDT) Received: from mail36-db3-R.bigfish.com (10.3.81.249) by DB3EHSOBE001.bigfish.com (10.3.84.21) with Microsoft SMTP Server id 14.1.225.23; Fri, 8 Jun 2012 13:27:19 +0000 Received: from mail36-db3 (localhost [127.0.0.1]) by mail36-db3-R.bigfish.com (Postfix) with ESMTP id 5271A340137 for ; Fri, 8 Jun 2012 13:27:19 +0000 (UTC) Received: from mail36-db3 (localhost.localdomain [127.0.0.1]) by mail36-db3 (MessageSwitch) id 1339162036334029_14730; Fri, 8 Jun 2012 13:27:16 +0000 (UTC) Received: from DB3EHSMHS009.bigfish.com (unknown [10.3.81.242]) by mail36-db3.bigfish.com (Postfix) with ESMTP id 45D02480048 for ; Fri, 8 Jun 2012 13:27:16 +0000 (UTC) Received: from BL2PRD0410HT001.namprd04.prod.outlook.com (157.56.240.85) by DB3EHSMHS009.bigfish.com (10.3.87.109) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 8 Jun 2012 13:27:15 +0000 Received: from BL2PRD0410MB363.namprd04.prod.outlook.com ([169.254.3.212]) by BL2PRD0410HT001.namprd04.prod.outlook.com ([10.255.99.36]) with mapi id 14.16.0164.004; Fri, 8 Jun 2012 13:28:05 +0000 From: Lewis Adam-CAL022 To: "oauth@ietf.org" Thread-Topic: Implicit vs. Code flow for Native clients Thread-Index: Ac1Feodm/+U42K50Sq+gf4CaaGMZ7g== Date: Fri, 8 Jun 2012 13:28:04 +0000 Message-ID: <59E470B10C4630419ED717AC79FCF9A90AED9377@BL2PRD0410MB363.namprd04.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {511F1BFD-AE21-4E73-9EE7-C86BB3B4EA83} x-cr-hashedpuzzle: ABan AicN AwCt A7Fk Bp7H CXHw EK7D Ez8i FQFY Fhn1 F1po F4b/ JDbj JdOM KmGJ Kp0G; 1; bwBhAHUAdABoAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {511F1BFD-AE21-4E73-9EE7-C86BB3B4EA83}; YQBkAGEAbQAuAGwAZQB3AGkAcwBAAG0AbwB0AG8AcgBvAGwAYQBzAG8AbAB1AHQAaQBvAG4AcwAuAGMAbwBtAA==; Fri, 08 Jun 2012 13:28:02 GMT; SQBtAHAAbABpAGMAaQB0ACAAdgBzAC4AIABDAG8AZABlACAAZgBsAG8AdwAgAGYAbwByACAATgBhAHQAaQB2AGUAIABjAGwAaQBlAG4AdABzAA== x-originating-ip: [150.130.14.154] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: BL2PRD0410HT001.namprd04.prod.outlook.com X-MS-Exchange-CrossPremises-SCL: -1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-rules-execution-history: Sample Spam Submissions X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-MS-Exchange-CrossPremises-ContentConversionOptions: False; 00160000; True; ; iso-8859-1 X-OrganizationHeadersPreserved: BL2PRD0410HT001.namprd04.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$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: [OAUTH-WG] Implicit vs. Code flow for Native clients X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 13:28:23 -0000 Hi all, I'm looking for a better understanding of why the code flow is recommended = as the preferred OAuth flow, even when used for native (public) clients. I totally get why it is preferred for confidential clients, as explained in= section 1.3.1. of the version 26 of the draft. The first reason is the ab= ility of the token endpoint to authenticate the client - which doesn't real= ly apply in the case of native (public) clients. The second reason cited i= s the ability to communicate the access token directly to the client, witho= ut exposing it to the UA and possibly leaking the access token. This is = probably the one where I don't fully understand the security risk. =20 In the code flow, the code obviously does flow through the UA, which could = also be exposed to malicious clients executing on the device. And a malici= ous client that steals this code could exchange it for the access token. =20 Now ... I assume the reason it is still recommended is that unlike an acces= s-token, the code can only be used ONCE in exchange for a token, and if a r= ogue clients grabs it and then the legit clients grabs it and each present = it to the token endpoint in attempt to get the token, the token endpoint ca= n detect that it has been compromised (as it has been presented twice) and = thus cut the attack short? Or is there more to it than that? I'm asking because the implicit flow avoids an additional roundtrip, and my= clients will run over (at times) very anemic bandwidths. I want to fully = understand the security implications vs. performance tradeoffs before makin= g a decision. Tx! adam From jpavelek@prospecnet.com Fri Jun 8 07:40:45 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27D5E21F8503 for ; Fri, 8 Jun 2012 07:40:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.165 X-Spam-Level: ** X-Spam-Status: No, score=2.165 tagged_above=-999 required=5 tests=[BAYES_60=1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iYGkMB6r66tD for ; Fri, 8 Jun 2012 07:40:44 -0700 (PDT) Received: from 6sabores.com (red-mecahost-server6.mecahost.net [82.159.210.33]) by ietfa.amsl.com (Postfix) with SMTP id A285121F854C for ; Fri, 8 Jun 2012 07:40:42 -0700 (PDT) Received: from Po01[81.36.1.47] by MECA6[82.159.210.33] (SMTPD32); Fri, 8 Jun 2012 16:40:38 +0200 From: =?iso-8859-1?Q?Jos=E9_Pavelek?= To: Date: Fri, 8 Jun 2012 16:43:50 +0200 Message-ID: <005001cd4585$1eb22250$5c1666f0$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0051_01CD4595.E23AF250" X-Mailer: Microsoft Office Outlook 12.0 thread-index: Ac1FhRwWdJiGg9ZzReq7OaE3pwU5dA== Content-Language: es x-cr-puzzleid: {09AD860B-83BD-42EF-9488-27C10DAF5EEA} x-cr-hashedpuzzle: Itw= AAsy ABXD A+vS BE2Y EERJ E8fZ G99m H3XF H8KL IOoe IvQq KYMy KqXs K3k4 LIqP; 1; bwBhAHUAdABoAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {09AD860B-83BD-42EF-9488-27C10DAF5EEA}; agBwAGEAdgBlAGwAZQBrAEAAcAByAG8AcwBwAGUAYwBuAGUAdAAuAGMAbwBtAA==; Fri, 08 Jun 2012 14:43:46 GMT; TABvAG8AawBpAG4AZwAgAGYAbwByACAAcwBhAG0AcABsAGUAcwA= Subject: [OAUTH-WG] Looking for samples X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 14:40:45 -0000 Este es un mensaje con varias partes en formato MIME. ------=_NextPart_000_0051_01CD4595.E23AF250 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, =20 I hope this mailing list can be used for this=85 =20 I=92m new in oAuth, I=92m a developer trying to use oAuth 2.0 to access = google calendar from web access, I use asp.net with VB, my customer want to = migrate some private calendar to google calendar, the application is in an intranet, and the objective is to schedule users appointments into = google calendar from a proprietary application, I need to get some running = examples in this environment because in the internet there are few examples in asp.net(VB) and most of them does not work fine , and the information in google is not clear for me. =20 Regards, =20 Jose Pavelek. =20 ------=_NextPart_000_0051_01CD4595.E23AF250 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi all,

 

I hope this mailing list can be = used for this…

 

I’m new in oAuth, = I’m a developer trying to use oAuth 2.0 =A0to access =A0google calendar from = web access, I use asp.net with VB, my customer want to migrate some private calendar = to google calendar, =A0the application is in an intranet, and the objective = is to schedule users appointments into google calendar from a proprietary application, = I need to get some running examples in this environment because in the internet = there are few examples in asp.net(VB) and most of them does not work fine , = and the information in google is not clear for me.

 

Regards,

 

Jose = Pavelek.

 

------=_NextPart_000_0051_01CD4595.E23AF250-- From ve7jtb@ve7jtb.com Fri Jun 8 07:51:52 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADA4821F8895 for ; Fri, 8 Jun 2012 07:51:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id noz5hsHJIaFk for ; Fri, 8 Jun 2012 07:51:45 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 91AC721F8881 for ; Fri, 8 Jun 2012 07:51:45 -0700 (PDT) Received: by ghbg16 with SMTP id g16so1521509ghb.31 for ; Fri, 08 Jun 2012 07:51:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=mtKhc0b8HCOcB+gkpW4O5U4FsPTH+pk4m4N/tyQi1O0=; b=QmrOBQ0tnq7AHuSMhuhn0sOMeb8HmdNLMUAg3DVvlHd3KhGDCymjJrf9vKqq+fQ192 toRnn74gY+9okxhsvGGLwM3BazzHoTjt5B9iPKhFR/NGp/v3+yocQbDKn4RYOuBtByt7 M6zR5+IurNTnGbtYSmZ+xvBxdDX9rTs/0knDk5r4W3ZRPVa8Uj0s9LaZswPZ41TY1dAq QThxGxNI2PHiwxTq88WJ+PoaeSeiUcUQcR+BWMYGZiIyPplastnPGgbt6+XsEkC/kNr1 7NrEz3XDrhfk3UtElgt6twCV0nW/hjr93IIhdH9aQBV4zDS3bWSq6uoEmX36meCHt8Fz YYLA== Received: by 10.236.165.74 with SMTP id d50mr7387479yhl.48.1339167104776; Fri, 08 Jun 2012 07:51:44 -0700 (PDT) Received: from [192.168.1.213] (190-20-22-159.baf.movistar.cl. [190.20.22.159]) by mx.google.com with ESMTPS id g4sm22031542yhf.12.2012.06.08.07.51.41 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 08 Jun 2012 07:51:42 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_8D0A5B30-F0EF-46ED-BFBA-8BE15431A9BF"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <59E470B10C4630419ED717AC79FCF9A90AED9377@BL2PRD0410MB363.namprd04.prod.outlook.com> Date: Fri, 8 Jun 2012 10:51:35 -0400 Message-Id: <3B97D8F2-E6FC-4D58-9B49-8154C58EB0EA@ve7jtb.com> References: <59E470B10C4630419ED717AC79FCF9A90AED9377@BL2PRD0410MB363.namprd04.prod.outlook.com> To: Lewis Adam-CAL022 X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQmYPN7TKbnOc4L6xlfGOrHmudqmCirPEce6+raZH8OycLxzC6vjYzg87YAGcBM6k10N5QwS Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Implicit vs. Code flow for Native clients X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 14:51:52 -0000 --Apple-Mail=_8D0A5B30-F0EF-46ED-BFBA-8BE15431A9BF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The implicit flow doesn't allow for refresh tokens. The refresh token mechanism allows for the AS to revoke access to the RS = when a relatively short lived access_token expires. Some people seem to prefer having the RS make a callback to the AS on = each access, and not use refresh tokens. =20 There tradeoffs each way. Issuing a non expiring access_token to the = client with no way to revoke it is quite likely a bad idea. I think you are correct that for a native client directly talking to the = AS the implicit flow is no more likely to have token exposed than code. The devil is in the details though, I am not recommending implicit over = code, the right one to use will depend on multiple factors. John B. On 2012-06-08, at 9:28 AM, Lewis Adam-CAL022 wrote: > Hi all, >=20 > I'm looking for a better understanding of why the code flow is = recommended as the preferred OAuth flow, even when used for native = (public) clients. >=20 > I totally get why it is preferred for confidential clients, as = explained in section 1.3.1. of the version 26 of the draft. The first = reason is the ability of the token endpoint to authenticate the client - = which doesn't really apply in the case of native (public) clients. The = second reason cited is the ability to communicate the access token = directly to the client, without exposing it to the UA and possibly = leaking the access token. This is probably the one where I don't = fully understand the security risk. =20 >=20 > In the code flow, the code obviously does flow through the UA, which = could also be exposed to malicious clients executing on the device. And = a malicious client that steals this code could exchange it for the = access token. =20 >=20 > Now ... I assume the reason it is still recommended is that unlike an = access-token, the code can only be used ONCE in exchange for a token, = and if a rogue clients grabs it and then the legit clients grabs it and = each present it to the token endpoint in attempt to get the token, the = token endpoint can detect that it has been compromised (as it has been = presented twice) and thus cut the attack short? Or is there more to it = than that? >=20 > I'm asking because the implicit flow avoids an additional roundtrip, = and my clients will run over (at times) very anemic bandwidths. I want = to fully understand the security implications vs. performance tradeoffs = before making a decision. >=20 > Tx! > adam >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_8D0A5B30-F0EF-46ED-BFBA-8BE15431A9BF Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw 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+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDYw ODE0NTEzNlowIwYJKoZIhvcNAQkEMRYEFBNke9Gp7FBUzK6s3e02I/5g95MEMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB ALE6YLDUqHrh6JtoITy/77ijG/Ka8+GmJ2J88Fx1cJDqyImagFprXkqTbzeSrn8we2Y9vxnc8mtY M6k9F2v1Z4a9CfTu1UWKxlCSQ17EqEJGSLupLdBKqrEbY/rpZX7cB10g9UDZXYdfihrY517W9JYb keF7IqBrq+2mrHCaEv7n9ba36wWRFZlwO5JbMKIKuRRSq57wo1tceOM6kyLocjNAp/wHrybCWO0T 6+dKAOUFTR07fACTKHPAqpDt5J2o84jmV9ojRFmSPwljXww3kXgF0JilwseEvDwAp1JqIcpXj7ZB DM0cq5X5whhDsBmHFsuZa4HlzcyeNpGrJP5eC/EAAAAAAAA= --Apple-Mail=_8D0A5B30-F0EF-46ED-BFBA-8BE15431A9BF-- From internet-drafts@ietf.org Fri Jun 8 10:44:30 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC8A511E8086; Fri, 8 Jun 2012 10:44:30 -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.071, 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 ZP46J5GpbdtQ; Fri, 8 Jun 2012 10:44:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B348E11E808C; Fri, 8 Jun 2012 10:44:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120608174429.30084.52362.idtracker@ietfa.amsl.com> Date: Fri, 08 Jun 2012 10:44:29 -0700 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-27.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, 08 Jun 2012 17:44: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 Gr= oup of the IETF. Title : The OAuth 2.0 Authorization Framework Author(s) : Eran Hammer David Recordon Dick Hardt Filename : draft-ietf-oauth-v2-27.txt Pages : 71 Date : 2012-06-08 The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-27.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-oauth-v2-27.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-v2/ From Michael.Jones@microsoft.com Fri Jun 8 10:51:36 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C94621F884B for ; Fri, 8 Jun 2012 10:51:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.735 X-Spam-Level: X-Spam-Status: No, score=-3.735 tagged_above=-999 required=5 tests=[AWL=-0.137, 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 wUZSgIGASAxF for ; Fri, 8 Jun 2012 10:51:35 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe002.messaging.microsoft.com [216.32.181.182]) by ietfa.amsl.com (Postfix) with ESMTP id D8A9F21F8846 for ; Fri, 8 Jun 2012 10:51:34 -0700 (PDT) Received: from mail90-ch1-R.bigfish.com (10.43.68.252) by CH1EHSOBE005.bigfish.com (10.43.70.55) with Microsoft SMTP Server id 14.1.225.23; Fri, 8 Jun 2012 17:50:43 +0000 Received: from mail90-ch1 (localhost [127.0.0.1]) by mail90-ch1-R.bigfish.com (Postfix) with ESMTP id 2543140220 for ; Fri, 8 Jun 2012 17:50:43 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: 0 X-BigFish: VS0(zzc85fhzz1202hzz8275bh8275dhz2fh2a8h668h839hd25hf0ah) Received-SPF: pass (mail90-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail90-ch1 (localhost.localdomain [127.0.0.1]) by mail90-ch1 (MessageSwitch) id 1339177840817884_31726; Fri, 8 Jun 2012 17:50:40 +0000 (UTC) Received: from CH1EHSMHS029.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.244]) by mail90-ch1.bigfish.com (Postfix) with ESMTP id BC290400048 for ; Fri, 8 Jun 2012 17:50:40 +0000 (UTC) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS029.bigfish.com (10.43.70.29) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 8 Jun 2012 17:50:40 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.189]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.02.0309.003; Fri, 8 Jun 2012 17:51:29 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: OAuth Core -27 Published Thread-Index: Ac1Fn1Jbo88ebeoKTpWmysQQYHT6Bw== Date: Fri, 8 Jun 2012 17:51:28 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436652F47C@TK5EX14MBXC284.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436652F47CTK5EX14MBXC284r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: [OAUTH-WG] OAuth Core -27 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, 08 Jun 2012 17:51:36 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436652F47CTK5EX14MBXC284r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The chairs approved publication of OAuth Core draft -27 today. This versio= n is based upon the proposed changes that I'd circulated to the working gro= up. Changes are: * Adds character set restrictions for error, error_description, and = error_uri parameters consistent with the OAuth Bearer spec. * Adds "resource access error response" as an error usage location i= n the OAuth Extensions Error Registry. * Adds an ABNF for all message elements. * Corrects editorial issues identified during review There are still potential issues with some ABNF definitions that need to be= discussed by the working group. I'll send a separate note about that. No= netheless, the chairs felt that publishing this version would be a step in = the right direction towards completing the Core and Bearer specifications. I'll be publishing an updated Bearer draft shortly that references the chan= ges in -27 in ways that should resolve the outstanding DISCUSS issues again= st Bearer. Thanks to Dick Hart for publishing the draft. -- Mike --_000_4E1F6AAD24975D4BA5B16804296739436652F47CTK5EX14MBXC284r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The chairs approved publication of OAuth Core draft = -27 today.  This version is based upon the proposed changes that IR= 17;d circulated to the working group.  Changes are:

·        Adds character set restrictions for error, e= rror_description, and error_uri parameters consistent with the OAuth Bearer= spec.

·        Adds “resource access error response&#= 8221; as an error usage location in the OAuth Extensions Error Registry.

·        Adds an ABNF for all message elements.<= /o:p>

·        Corrects editorial issues identified during = review

 

There are still potential issues with some ABNF defi= nitions that need to be discussed by the working group.  I’ll se= nd a separate note about that.  Nonetheless, the chairs felt that publ= ishing this version would be a step in the right direction towards completing the Core and Bearer specifications.

 

I’ll be publishing an updated Bearer draft sho= rtly that references the changes in -27 in ways that should resolve the out= standing DISCUSS issues against Bearer.

 

Thanks to Dick Hart for publishing the draft.

 

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

 

--_000_4E1F6AAD24975D4BA5B16804296739436652F47CTK5EX14MBXC284r_-- From dick.hardt@gmail.com Fri Jun 8 11:08:35 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 422BF11E8093 for ; Fri, 8 Jun 2012 11:08:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2uSF2n4AX7Hb for ; Fri, 8 Jun 2012 11:08:34 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9930111E8083 for ; Fri, 8 Jun 2012 11:08:34 -0700 (PDT) Received: by dacx6 with SMTP id x6so2708318dac.31 for ; Fri, 08 Jun 2012 11:08:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=W5J5+aDxxxLzWnsUnXYXpOkqERuJs7NQdCh8gYvaOv4=; b=CVFoVkNqU+few610QKXJFOS3jMOdPtkSKVuE5T0xjzTMfs/51UHvaOviYR47s61bzN cC9L16v27X1vBLheWdK7gUUeQYWqu4a7MTIBL8DgfrYu2lYexI66Q35fKomKF5jWv6w3 vMd+26IG5RlMmJUCBuuDcCveVAO3oceon6g6YaJ9C+6e9C0Ad4BMAlneusXFTyuOqyti PT/4TjsUVWhPs8yxrj1SNp3HVUjlPo3OzyV3l8P963SK21hGpn2YSdxmz7bIIyYQGTnF ekndI+pYWLtC6fk+qeWjycC7QtIEg7KtAvP3FpClrtb++NSXNxSQJxZmR2HhQhozoCCB OhXA== Received: by 10.68.217.100 with SMTP id ox4mr3663703pbc.87.1339178914399; Fri, 08 Jun 2012 11:08:34 -0700 (PDT) Received: from [10.0.0.4] (c-24-5-69-173.hsd1.ca.comcast.net. [24.5.69.173]) by mx.google.com with ESMTPS id z2sm8563193pbv.34.2012.06.08.11.08.32 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 08 Jun 2012 11:08:33 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_D353513D-E687-48A9-BC2B-8F431E30F660" From: Dick Hardt In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436652F47C@TK5EX14MBXC284.redmond.corp.microsoft.com> Date: Fri, 8 Jun 2012 11:08:30 -0700 Message-Id: <3308D14C-E8EA-4580-97B3-779FF5E2AA15@gmail.com> References: <4E1F6AAD24975D4BA5B16804296739436652F47C@TK5EX14MBXC284.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1278) Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth Core -27 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, 08 Jun 2012 18:08:35 -0000 --Apple-Mail=_D353513D-E687-48A9-BC2B-8F431E30F660 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jun 8, 2012, at 10:51 AM, Mike Jones wrote: > The chairs approved publication of OAuth Core draft -27 today. This = version is based upon the proposed changes that I=92d circulated to the = working group. Changes are: > =B7 Adds character set restrictions for error, = error_description, and error_uri parameters consistent with the OAuth = Bearer spec. > =B7 Adds =93resource access error response=94 as an error usage = location in the OAuth Extensions Error Registry. > =B7 Adds an ABNF for all message elements. > =B7 Corrects editorial issues identified during review > =20 > There are still potential issues with some ABNF definitions that need = to be discussed by the working group. I=92ll send a separate note about = that. Nonetheless, the chairs felt that publishing this version would = be a step in the right direction towards completing the Core and Bearer = specifications. > =20 > I=92ll be publishing an updated Bearer draft shortly that references = the changes in -27 in ways that should resolve the outstanding DISCUSS = issues against Bearer. > =20 > Thanks to Dick Hart for publishing the draft. s/Dick Hart/Dick Hardt/ :) --Apple-Mail=_D353513D-E687-48A9-BC2B-8F431E30F660 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Jun 8, 2012, at 10:51 AM, Mike = Jones wrote:

The chairs approved = publication of OAuth Core draft -27 today.  This version is based = upon the proposed changes that I=92d circulated to the working = group.  Changes are:
=B7 Adds = character set restrictions for error, error_description, and error_uri = parameters consistent with the OAuth Bearer spec.
        Adds = =93resource access error response=94 as an error usage location in the = OAuth Extensions Error Registry.
=B7 Adds = an ABNF for all message elements.
        Corrects= editorial issues identified during review
 
There are still potential = issues with some ABNF definitions that need to be discussed by the = working group.  I=92ll send a separate note about that.  = Nonetheless, the chairs felt that publishing this version would be a = step in the right direction towards completing the Core and Bearer = specifications.
 
I=92ll be publishing an updated Bearer draft shortly that = references the changes in -27 in ways that should resolve the = outstanding DISCUSS issues against Bearer.
 
Thanks to Dick Hart for = publishing the = draft.

s/Dick = Hart/Dick = Hardt/

:)



= = --Apple-Mail=_D353513D-E687-48A9-BC2B-8F431E30F660-- From Michael.Jones@microsoft.com Fri Jun 8 11:09:35 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32BCC11E80B6 for ; Fri, 8 Jun 2012 11:09:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.232 X-Spam-Level: X-Spam-Status: No, score=-5.232 tagged_above=-999 required=5 tests=[AWL=1.367, 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 e5N4lMPzPvdc for ; Fri, 8 Jun 2012 11:09:34 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by ietfa.amsl.com (Postfix) with ESMTP id 19F8C11E8083 for ; Fri, 8 Jun 2012 11:09:34 -0700 (PDT) Received: from mail93-tx2-R.bigfish.com (10.9.14.249) by TX2EHSOBE003.bigfish.com (10.9.40.23) with Microsoft SMTP Server id 14.1.225.23; Fri, 8 Jun 2012 18:08:40 +0000 Received: from mail93-tx2 (localhost [127.0.0.1]) by mail93-tx2-R.bigfish.com (Postfix) with ESMTP id 6FE4D1E0404; Fri, 8 Jun 2012 18:08:40 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -33 X-BigFish: VS-33(zz98dI9371I936eIc3f2M542Mzz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25hf0ah) Received-SPF: pass (mail93-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail93-tx2 (localhost.localdomain [127.0.0.1]) by mail93-tx2 (MessageSwitch) id 1339178919272409_27923; Fri, 8 Jun 2012 18:08:39 +0000 (UTC) Received: from TX2EHSMHS040.bigfish.com (unknown [10.9.14.252]) by mail93-tx2.bigfish.com (Postfix) with ESMTP id 35241140044; Fri, 8 Jun 2012 18:08:39 +0000 (UTC) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS040.bigfish.com (10.9.99.140) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 8 Jun 2012 18:08:38 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.189]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.02.0309.003; Fri, 8 Jun 2012 18:09:28 +0000 From: Mike Jones To: Julian Reschke Thread-Topic: Discussion needed on username and password ABNF definitions Thread-Index: Ac1FodQD2X6ejXtzRTyOfL/3OPr81w== Date: Fri, 8 Jun 2012 18:09:27 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436652F52D@TK5EX14MBXC284.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "oauth@ietf.org" Subject: [OAUTH-WG] Discussion needed on username and password ABNF definitions X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 18:09:35 -0000 Hi Julian, The current draft restricts username and password to ASCII was because RFC = 2616 says this about the TEXT fields used by HTTP Basic in RFC 2617: "Words of *TEXT MAY contain characters from character sets other than ISO-8859-1 [22] only when encoded according to the rules of RFC 2047 [14]." Given that RFC 2047 MIME encodings aren't possible in this context, that yo= u wrote that "If you define new protocol elements, either restrict them to = US-ASCII, or find a way to encode all of Unicode", and you and Peter St. An= dre wrote that using ISO-8859-1 is a non-starter, that seemed to leave ASCI= I as the only available choice. If you have an alternative proposal for encoding all of Unicode for usernam= e and password, I'd appreciate if you could propose specific text changes t= o -27 to accomplish them. I'd be fine with doing that, but didn't know how= to satisfy all the constraints above for Unicode characters. Draft -27 is= now available at http://tools.ietf.org/html/draft-ietf-oauth-v2-27. The working group should also discuss whether client_id and client_secret s= hould use the same character set restrictions as username and password or w= hether they should be different for some reason. In the case of one charac= ter, they need to be different: The client_id field already allows colon (= ":") for reasons identified by Nat Sakimura, among others, whereas username= can't because of HTTP Basic restrictions. Best wishes, -- Mike -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de]=20 Sent: Friday, June 08, 2012 2:52 AM To: Mike Jones Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Draft OAuth Core spec changes updating proposed ABN= F On 2012-06-08 09:56, Mike Jones wrote: > The attached proposed edits to the Core spec update the ABNF to remove=20 > the character set restrictions that working group participants had=20 > objected to, and to define common syntax elements, where appropriate. > After working group review, I believe that these changes are ready to=20 > be checked in for draft 27 after being merged with whatever other=20 > changes Eran has made. > ... As far as I can tell, you have chosen to restrict everything to US-ASCII. T= hat definitively makes the ABNF and the wire representation simpler, but it= does break I18N big time. And please don't tell me that people do not use non-ASCII characters in cre= dentials (-> ). Focusing on username and password... If this relates to the use in Basic an= d Digest, it's fine that it has their current limitations; but in that case= the ABNF shouldn't invent new productions and claim that they match 2617's= when they do not. If this relates to uses of usernames and passwords outside Basic and Digest= (thus new uses), then I believe the proposed solution is not acceptable. Best regards, Julian From Michael.Jones@microsoft.com Fri Jun 8 11:11:30 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF25811E8072 for ; Fri, 8 Jun 2012 11:11:30 -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=-0.171, 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 rpsH2rtR4udY for ; Fri, 8 Jun 2012 11:11:26 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe003.messaging.microsoft.com [213.199.154.206]) by ietfa.amsl.com (Postfix) with ESMTP id DF4D511E80BB for ; Fri, 8 Jun 2012 11:11:25 -0700 (PDT) Received: from mail114-am1-R.bigfish.com (10.3.201.239) by AM1EHSOBE001.bigfish.com (10.3.204.21) with Microsoft SMTP Server id 14.1.225.23; Fri, 8 Jun 2012 18:10:34 +0000 Received: from mail114-am1 (localhost [127.0.0.1]) by mail114-am1-R.bigfish.com (Postfix) with ESMTP id BDD8C340143; Fri, 8 Jun 2012 18:10:33 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: VS-22(zz98dI9371Ic85fhzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25hf0ah) Received-SPF: pass (mail114-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail114-am1 (localhost.localdomain [127.0.0.1]) by mail114-am1 (MessageSwitch) id 133917903363428_17999; Fri, 8 Jun 2012 18:10:33 +0000 (UTC) Received: from AM1EHSMHS013.bigfish.com (unknown [10.3.201.235]) by mail114-am1.bigfish.com (Postfix) with ESMTP id 0D97D3C0048; Fri, 8 Jun 2012 18:10:33 +0000 (UTC) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS013.bigfish.com (10.3.207.151) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 8 Jun 2012 18:10:30 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.189]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.02.0309.003; Fri, 8 Jun 2012 18:10:58 +0000 From: Mike Jones To: Dick Hardt Thread-Topic: [OAUTH-WG] OAuth Core -27 Published Thread-Index: Ac1Fn1Jbo88ebeoKTpWmysQQYHT6BwAAmMYAAAAPV5A= Date: Fri, 8 Jun 2012 18:10:58 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436652F554@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739436652F47C@TK5EX14MBXC284.redmond.corp.microsoft.com> <3308D14C-E8EA-4580-97B3-779FF5E2AA15@gmail.com> In-Reply-To: <3308D14C-E8EA-4580-97B3-779FF5E2AA15@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436652F554TK5EX14MBXC284r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth Core -27 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, 08 Jun 2012 18:11:31 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436652F554TK5EX14MBXC284r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Apologies, Dick HARDT! :-) From: Dick Hardt [mailto:dick.hardt@gmail.com] Sent: Friday, June 08, 2012 11:09 AM To: Mike Jones Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth Core -27 Published On Jun 8, 2012, at 10:51 AM, Mike Jones wrote: The chairs approved publication of OAuth Core draft -27 today. This versio= n is based upon the proposed changes that I'd circulated to the working gro= up. Changes are: * Adds character set restrictions for error, error_description, and = error_uri parameters consistent with the OAuth Bearer spec. * Adds "resource access error response" as an error usage location i= n the OAuth Extensions Error Registry. * Adds an ABNF for all message elements. * Corrects editorial issues identified during review There are still potential issues with some ABNF definitions that need to be= discussed by the working group. I'll send a separate note about that. No= netheless, the chairs felt that publishing this version would be a step in = the right direction towards completing the Core and Bearer specifications. I'll be publishing an updated Bearer draft shortly that references the chan= ges in -27 in ways that should resolve the outstanding DISCUSS issues again= st Bearer. Thanks to Dick Hart for publishing the draft. s/Dick Hart/Dick Hardt/ :) --_000_4E1F6AAD24975D4BA5B16804296739436652F554TK5EX14MBXC284r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Apologies, Dick HARDT! :-= )

 <= /p>

From: Dick Har= dt [mailto:dick.hardt@gmail.com]
Sent: Friday, June 08, 2012 11:09 AM
To: Mike Jones
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth Core -27 Published

 

 

On Jun 8, 2012, at 10:51 AM, Mike Jones wrote:<= /o:p>



The chairs approved publication of OAut= h Core draft -27 today.  This version is based upon the proposed chang= es that I’d circulated to the working group.  Changes are:<= /o:p>

·        Adds character set restrictions for error, error_description, and error_uri par= ameters consistent with the OAuth Bearer spec.

·        Adds “resource access error response” as an error usage location in= the OAuth Extensions Error Registry.

·        Adds an ABNF for all message elements.

·        Corrects editorial issues identified during review

 

There are still potential issues with s= ome ABNF definitions that need to be discussed by the working group.  = I’ll send a separate note about that.  Nonetheless, the chairs felt that publishing this version would be a step in the right direction t= owards completing the Core and Bearer specifications.

 

I’ll be publishing an updated Bea= rer draft shortly that references the changes in -27 in ways that should re= solve the outstanding DISCUSS issues against Bearer.

 

Thanks to Dick Hart for publishing the = draft.

 

s/Dick Hart/Dick Hardt/

 

:)

 

 

 

--_000_4E1F6AAD24975D4BA5B16804296739436652F554TK5EX14MBXC284r_-- From internet-drafts@ietf.org Fri Jun 8 13:57:13 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C979421F8740; Fri, 8 Jun 2012 13:57:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 rXLVvv91hxS5; Fri, 8 Jun 2012 13:57:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2958721F86EF; Fri, 8 Jun 2012 13:57:13 -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.02 Message-ID: <20120608205713.19105.7235.idtracker@ietfa.amsl.com> Date: Fri, 08 Jun 2012 13:57:13 -0700 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-20.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, 08 Jun 2012 20:57:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Authorization Protocol Working Gr= oup of the IETF. Title : The OAuth 2.0 Authorization Framework: Bearer Token Usage Author(s) : Michael B. Jones Dick Hardt David Recordon Filename : draft-ietf-oauth-v2-bearer-20.txt Pages : 26 Date : 2012-06-08 This specification describes how to use bearer tokens in HTTP requests to access OAuth 2.0 protected resources. Any party in possession of a bearer token (a "bearer") can use it to get access to the associated resources (without demonstrating possession of a cryptographic key). To prevent misuse, bearer tokens need to be protected from disclosure in storage and in transport. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-20.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-20.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-bearer/ From Michael.Jones@microsoft.com Fri Jun 8 14:08:53 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB43D11E819C for ; Fri, 8 Jun 2012 14:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.764 X-Spam-Level: X-Spam-Status: No, score=-3.764 tagged_above=-999 required=5 tests=[AWL=-0.166, 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 2-pnOOTTXYZD for ; Fri, 8 Jun 2012 14:08:52 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe002.messaging.microsoft.com [213.199.154.205]) by ietfa.amsl.com (Postfix) with ESMTP id 311F511E819D for ; Fri, 8 Jun 2012 14:08:52 -0700 (PDT) Received: from mail61-am1-R.bigfish.com (10.3.201.253) by AM1EHSOBE001.bigfish.com (10.3.204.21) with Microsoft SMTP Server id 14.1.225.23; Fri, 8 Jun 2012 21:08:00 +0000 Received: from mail61-am1 (localhost [127.0.0.1]) by mail61-am1-R.bigfish.com (Postfix) with ESMTP id C8B424C02A6 for ; Fri, 8 Jun 2012 21:07:59 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -19 X-BigFish: VS-19(zzc85fhzz1202hzz1033IL8275eh8275bh8275dha1495iz2fh2a8h668h839hd25hf0ah) Received-SPF: pass (mail61-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC101.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail61-am1 (localhost.localdomain [127.0.0.1]) by mail61-am1 (MessageSwitch) id 1339189677518221_27608; Fri, 8 Jun 2012 21:07:57 +0000 (UTC) Received: from AM1EHSMHS007.bigfish.com (unknown [10.3.201.233]) by mail61-am1.bigfish.com (Postfix) with ESMTP id 7C9B22E0048 for ; Fri, 8 Jun 2012 21:07:57 +0000 (UTC) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS007.bigfish.com (10.3.207.107) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 8 Jun 2012 21:07:56 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.189]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.02.0309.003; Fri, 8 Jun 2012 21:08:37 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: OAuth 2.0 Bearer Token Specification Draft -20 Thread-Index: Ac1Futblobsvy7tcQq2Ukorv/Ml+RQ== Date: Fri, 8 Jun 2012 21:08:37 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436652F914@TK5EX14MBXC284.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436652F914TK5EX14MBXC284r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: [OAUTH-WG] OAuth 2.0 Bearer Token Specification Draft -20 X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 21:08:54 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436652F914TK5EX14MBXC284r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Draft 20 of the OAuth 2.0 Bearer Token Specification has been published. I= believe that this draft addresses all DISCUSS issues and comments raised f= or this specification in IESG review. No normative changes were made, othe= r than specifying the use of Cache-Control options when using the URI Query= Parameter method. Changes made were: * Added caveat about using a reserved query parameter name being counte= r to URI namespace best practices. * Specified use of Cache-Control options when using the URI Query Param= eter method. * Changed title to "The OAuth 2.0 Authorization Framework: Bearer Token= Usage". * Referenced syntax definitions for the scope, error, error_description= , and error_uri parameters in the OAuth 2.0 core spec. * Registered the invalid_request, invalid_token, and insufficient_scope= error values in the OAuth Extensions Error Registry. * Acknowledged additional individuals. The draft is available at: * http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-20 A HTML-formatted version is available at: * http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-20.html -- Mike --_000_4E1F6AAD24975D4BA5B16804296739436652F914TK5EX14MBXC284r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Draft 20 of the OAuth 2.0 Bearer Token Specification= has been published.  I believe that this draft addresses all DISCUSS = issues and comments raised for this specification in IESG review.  No = normative changes were made, other than specifying the use of Cache-Control options when using the URI Query Parameter method= .

 

Changes made were:

  • Added caveat about using a reserved query parameter nam= e being counter to URI namespace best practices.
  • Specified use of Cache-Control o= ptions when using the URI Query Parameter method.
  • Changed title to "The OAuth= 2.0 Authorization Framework: Bearer Token Usage".
  • Referenced syntax definitions fo= r the scope, error, error_description, and error_uri parameters in the OAuth 2.0 core spec.
  • Registered the invalid_request, invalid_token, and insufficient_scope error values in the OAuth Extensions Error Registry.
  • Acknowledged additional individu= als.

 

The draft is available at:

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

A HTML-formatted version is available at:=

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

 

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

 

--_000_4E1F6AAD24975D4BA5B16804296739436652F914TK5EX14MBXC284r_-- From eran@hueniverse.com Fri Jun 8 14:28:21 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8BCA11E80AE for ; Fri, 8 Jun 2012 14:28:21 -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 dSQWN8Ic6tcE for ; Fri, 8 Jun 2012 14:28:20 -0700 (PDT) Received: from p3plex2out01.prod.phx3.secureserver.net (p3plex2out01.prod.phx3.secureserver.net [184.168.131.12]) by ietfa.amsl.com (Postfix) with ESMTP id AE84D11E80AA for ; Fri, 8 Jun 2012 14:28:20 -0700 (PDT) Received: from P3PWEX2HT003.ex2.secureserver.net ([184.168.131.11]) by p3plex2out01.prod.phx3.secureserver.net with bizsmtp id KxUL1j0050EuLVk01xUL8F; Fri, 08 Jun 2012 14:28:20 -0700 Received: from P3PWEX2MB008.ex2.secureserver.net ([169.254.8.66]) by P3PWEX2HT003.ex2.secureserver.net ([184.168.131.11]) with mapi id 14.02.0247.003; Fri, 8 Jun 2012 14:28:19 -0700 From: Eran Hammer To: Mike Jones Thread-Topic: [OAUTH-WG] OAuth Core -27 Published Thread-Index: AQHNRb2fibD0X5/m8U63YIbZPLFOOw== Date: Fri, 8 Jun 2012 21:28:19 +0000 Message-ID: References: <4E1F6AAD24975D4BA5B16804296739436652F47C@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436652F47C@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_C4D9993FFAEE4C5BBC54629930A0F35Chueniversecom_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth Core -27 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, 08 Jun 2012 21:28:21 -0000 --_000_C4D9993FFAEE4C5BBC54629930A0F35Chueniversecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable What the hell just happened? Even if this is allowed under IETF rules, it i= s clearly against IETF spirit. There is now a published draft with my name = as sole editor and text I didn't put in there. No one even suggested this i= s something the chairs might do. After all the work I put into this, this is a huge slap in the face by the = chairs. I hope the fact the Mike Jonea just took over with the blessing on the chai= rs bothers someone else too. EH On Jun 8, 2012, at 13:51, "Mike Jones" > wrote: The chairs approved publication of OAuth Core draft -27 today. This versio= n is based upon the proposed changes that I=92d circulated to the working g= roup. Changes are: =B7 Adds character set restrictions for error, error_description, an= d error_uri parameters consistent with the OAuth Bearer spec. =B7 Adds =93resource access error response=94 as an error usage loca= tion in the OAuth Extensions Error Registry. =B7 Adds an ABNF for all message elements. =B7 Corrects editorial issues identified during review There are still potential issues with some ABNF definitions that need to be= discussed by the working group. I=92ll send a separate note about that. = Nonetheless, the chairs felt that publishing this version would be a step i= n the right direction towards completing the Core and Bearer specifications= . I=92ll be publishing an updated Bearer draft shortly that references the ch= anges in -27 in ways that should resolve the outstanding DISCUSS issues aga= inst Bearer. Thanks to Dick Hart for publishing the draft. -- Mike _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_C4D9993FFAEE4C5BBC54629930A0F35Chueniversecom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
What the hell just happened? Even if this is allowed under IETF rules,= it is clearly against IETF spirit. There is now a published draft with my = name as sole editor and text I didn't put in there. No one even suggested t= his is something the chairs might do. 

After all the work I put into this, this is a huge slap in the face by= the chairs. 

I hope the fact the Mike Jonea just took over with the blessing on the= chairs bothers someone else too. 

EH

On Jun 8, 2012, at 13:51, "Mike Jones" <Michael.Jones@microsoft.com> wrote:

The chairs approved publication of OAuth Core draft = -27 today.  This version is based upon the proposed changes that I=92d= circulated to the working group.  Changes are:

=B7        Adds character set restrictions for erro= r, error_description, and error_uri parameters consistent with the OAuth Be= arer spec.

=B7        Adds =93resource access error response= =94 as an error usage location in the OAuth Extensions Error Registry.=

=B7        Adds an ABNF for all message elements.

=B7        Corrects editorial issues identified dur= ing review

 

There are still potential issues with some ABNF defi= nitions that need to be discussed by the working group.  I=92ll send a= separate note about that.  Nonetheless, the chairs felt that publishi= ng this version would be a step in the right direction towards completing the Core and Bearer specifications.

 

I=92ll be publishing an updated Bearer draft shortly= that references the changes in -27 in ways that should resolve the outstan= ding DISCUSS issues against Bearer.

 

Thanks to Dick Hart for publishing the draft.

 

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

 

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.i= etf.org/mailman/listinfo/oauth
--_000_C4D9993FFAEE4C5BBC54629930A0F35Chueniversecom_-- From stpeter@stpeter.im Fri Jun 8 14:31:46 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CB8F11E8198 for ; Fri, 8 Jun 2012 14:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.802 X-Spam-Level: X-Spam-Status: No, score=-102.802 tagged_above=-999 required=5 tests=[AWL=-0.203, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ruA9jCAv53ev for ; Fri, 8 Jun 2012 14:31:46 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id E620211E8183 for ; Fri, 8 Jun 2012 14:31:45 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 947CD400A4; Fri, 8 Jun 2012 15:48:42 -0600 (MDT) Message-ID: <4FD26F3F.6000503@stpeter.im> Date: Fri, 08 Jun 2012 15:31:43 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120601 Thunderbird/13.0 MIME-Version: 1.0 To: Eran Hammer References: <4E1F6AAD24975D4BA5B16804296739436652F47C@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth Core -27 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, 08 Jun 2012 21:31:46 -0000 I must say that I found it surprising, too. An explanation beforehand from the chairs would have helped to prevent confusion. On 6/8/12 3:28 PM, Eran Hammer wrote: > What the hell just happened? Even if this is allowed under IETF rules, > it is clearly against IETF spirit. There is now a published draft with > my name as sole editor and text I didn't put in there. No one even > suggested this is something the chairs might do. > > After all the work I put into this, this is a huge slap in the face by > the chairs. > > I hope the fact the Mike Jonea just took over with the blessing on the > chairs bothers someone else too. > > EH > > On Jun 8, 2012, at 13:51, "Mike Jones" > wrote: > >> The chairs approved publication of OAuth Core draft -27 today. This >> version is based upon the proposed changes that I’d circulated to the >> working group. Changes are: >> >> · Adds character set restrictions for error, error_description, >> and error_uri parameters consistent with the OAuth Bearer spec. >> >> · Adds “resource access error response†as an error usage >> location in the OAuth Extensions Error Registry. >> >> · Adds an ABNF for all message elements. >> >> · Corrects editorial issues identified during review >> >> >> >> There are still potential issues with some ABNF definitions that need >> to be discussed by the working group. I’ll send a separate note about >> that. Nonetheless, the chairs felt that publishing this version would >> be a step in the right direction towards completing the Core and >> Bearer specifications. >> >> >> >> I’ll be publishing an updated Bearer draft shortly that references the >> changes in -27 in ways that should resolve the outstanding DISCUSS >> issues against Bearer. >> >> >> >> Thanks to Dick Hart for publishing the draft. >> >> >> >> -- Mike >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth From Michael.Jones@microsoft.com Fri Jun 8 15:20:28 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F399B11E8171 for ; Fri, 8 Jun 2012 15:20:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.745 X-Spam-Level: X-Spam-Status: No, score=-3.745 tagged_above=-999 required=5 tests=[AWL=-0.147, 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 AVvinjWrK8Ib for ; Fri, 8 Jun 2012 15:20:24 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by ietfa.amsl.com (Postfix) with ESMTP id 783DF11E813E for ; Fri, 8 Jun 2012 15:20:23 -0700 (PDT) Received: from mail6-ch1-R.bigfish.com (10.43.68.246) by CH1EHSOBE017.bigfish.com (10.43.70.67) with Microsoft SMTP Server id 14.1.225.23; Fri, 8 Jun 2012 22:19:31 +0000 Received: from mail6-ch1 (localhost [127.0.0.1]) by mail6-ch1-R.bigfish.com (Postfix) with ESMTP id 54ACA1E0114; Fri, 8 Jun 2012 22:19:31 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC105.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -36 X-BigFish: VS-36(zzbb2dI98dI9371I936eIc85fh542Mdf9M1432I111aIzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25hf0ah) Received-SPF: pass (mail6-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC105.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail6-ch1 (localhost.localdomain [127.0.0.1]) by mail6-ch1 (MessageSwitch) id 1339193969814804_19295; Fri, 8 Jun 2012 22:19:29 +0000 (UTC) Received: from CH1EHSMHS030.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.245]) by mail6-ch1.bigfish.com (Postfix) with ESMTP id C4A86140217; Fri, 8 Jun 2012 22:19:29 +0000 (UTC) Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS030.bigfish.com (10.43.70.30) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 8 Jun 2012 22:19:29 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.189]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.02.0309.003; Fri, 8 Jun 2012 22:20:17 +0000 From: Mike Jones To: Amos Jeffries Thread-Topic: [OAUTH-WG] Cache-Control headers for Bearer URI Query Parameter method Thread-Index: Ac1FxOD3z7MhZ6PpSMarx0E+SAch6Q== Date: Fri, 8 Jun 2012 22:20:16 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436652FBFC@TK5EX14MBXC284.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436652FBFCTK5EX14MBXC284r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Cache-Control headers for Bearer URI Query Parameter method X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 22:20:28 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436652FBFCTK5EX14MBXC284r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Amos, The OAuth Bearer specification now includes the Cache-Control language we'd= discussed. See the fifth paragraph of http://tools.ietf.org/html/draft-ietf-oauth-v2-b= earer-20#section-2.3. Thanks again, -- Mike From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of M= ike Jones Sent: Thursday, May 17, 2012 3:12 PM To: oauth@ietf.org Subject: [OAUTH-WG] Cache-Control headers for Bearer URI Query Parameter me= thod Dear working group members: I'm going through the remaining open issues that have been raised about the= Bearer spec so as to be ready to publish an updated draft once the outstan= ding consensus call issues are resolved. Amos Jeffries had cited this requirement in the HTTPbis spec ( http://tools= .ietf.org/html/draft-ietf-httpbis-p7-auth-19#section-2.3.1): o The credentials carried in an Authorization header field are specific to the User Agent, and therefore have the same effect on HTTP caches as the "private" Cache-Control response directive, within the scope of the request they appear in. Therefore, new authentication schemes which choose not to carry credentials in the Authorization header (e.g., using a newly defined header) will need to explicitly disallow caching, by mandating the use of either Cache-Control request directives (e.g., "no-store") or response directives (e.g., "private"). I propose to add the following text in order to satisfy this requirement. = I have changed Amos' MUSTs to SHOULDs because, in practice, applications th= at have no option but to use the URI Query Parameter method are likely to a= lso not have control over the request's Cache-Control directives (just as t= hey do not have the ability to use an "Authorization: Bearer" header value)= : Clients using the URI Query Parameter method SHOULD also send a Cache-Control header containing the "no-store" option. Server success (2XX status) responses to these requests SHOULD contain a Cache-Control header with the "private" option. Comments? -- Mike -----Original Message----- From: Amos Jeffries [mailto:squid3@treenet.co.nz] Sent: Monday, April 23, 2012 10:13 PM To: Mike Jones Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-19.txt On 24/04/2012 4:33 p.m., Mike Jones wrote: > What specific language would you suggest be added to what section(s)? > > -- Mike Perhapse the last paragraph appended: " Because of the security weaknesses associated with the URI method (see Section 5), including the high likelihood that the URL containing the access token will be logged, it SHOULD NOT be used unless it is impossible to transport the access token in the "Authorization" request header field or the HTTP request entity-body. Resource servers compliant with this specification MAY support this method. Clients requesting URL containing the access token MUST also send a Cache-Control header containing the "no-store" option. Server success (2xx status) responses to these requests MUST contain a Cache-Control header with the "private" option. " I'm a little suspicious that the "SHOUDL NOT" in that top paragraph likely = should be a MUST NOT to further discourage needless use. AYJ > > -----Original Message----- > From: oauth-bounces@ietf.org On Behalf Of = Amos Jeffries > Sent: Monday, April 23, 2012 7:10 PM > To: oauth@ietf.org > Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-19.txt > > On 24.04.2012 13:46, 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 : The OAuth 2.0 Authorization Protocol: Bearer >> Tokens >> Author(s) : Michael B. Jones >> Dick Hardt >> David Recordon >> Filename : draft-ietf-oauth-v2-bearer-19.txt >> Pages : 24 >> Date : 2012-04-23 >> >> This specification describes how to use bearer tokens in HTTP >> requests to access OAuth 2.0 protected resources. Any party in >> possession of a bearer token (a "bearer") can use it to get >> access to >> the associated resources (without demonstrating possession of a >> cryptographic key). To prevent misuse, bearer tokens need to be >> protected from disclosure in storage and in transport. >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-19.txt > > > The section 2.3 (URL Query Parameter) text is still lacking explicit and = specific security requirements. The overarching TLS requirement is good in = general, but insufficient in the presence of HTTP intermediaries on the TLS= connection path as is becoming a common practice. > > The upcoming HTTPbis specs document this issue as a requirement for new a= uth schemes such as Bearer: > > http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-19#section-2.3.1 > " > Therefore, new authentication schemes which choose not to carry > credentials in the Authorization header (e.g., using a newly > defined header) will need to explicitly disallow caching, by > mandating the use of either Cache-Control request directives > (e.g., "no-store") or response directives (e.g., "private"). > " > > > AYJ > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --_000_4E1F6AAD24975D4BA5B16804296739436652FBFCTK5EX14MBXC284r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Amos,

 

The OAuth Bearer specification now includes the C= ache-Control language we’d discussed.

 

See the fifth paragraph of http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-20#section-2.3.

 

        &= nbsp;            &nb= sp;            =             &nb= sp;            = Thanks again,

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

 

 

From: oauth-bo= unces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Thursday, May 17, 2012 3:12 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] Cache-Control headers for Bearer URI Query Param= eter method

 

Dear working group members:

 

I'm going through the remaining open issues that = have been raised about the Bearer spec so as to be ready to publish an upda= ted draft once the outstanding consensus call issues are resolved.

 

Amos Jeffries had cited this requirement in the H= TTPbis spec ( http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-19#section-2.3.1)= :

 

   o  The credentials carried in a= n Authorization header field are

      specific to the Us= er Agent, and therefore have the same effect on

      HTTP caches as the= "private" Cache-Control response directive,

      within the scope o= f the request they appear in.

 

      Therefore, new aut= hentication schemes which choose not to carry

      credentials in the= Authorization header (e.g., using a newly

      defined header) wi= ll need to explicitly disallow caching, by

      mandating the use = of either Cache-Control request directives

      (e.g., "no-st= ore") or response directives (e.g., "private").

 

I propose to add the following text in order to s= atisfy this requirement.  I have changed Amos' MUSTs to SHOULDs becaus= e, in practice, applications that have no option but to use the URI Query P= arameter method are likely to also not have control over the request's Cache-Control directives (just as they do = not have the ability to use an "Authorization: Bearer" header val= ue):

 

    = Clients using the URI Query Parameter method SHOULD also send a<= /span>

    = Cache-Control header containing the "no-store" option.  Serv= er success

    = (2XX status) responses to these requests SHOULD contain a Cache-Control

    = header with the "private" option.

 

Comments?

 

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

 

-----Original Message-----
From: Amos Jeffries [mailt= o:squid3@treenet.co.nz]
Sent: Monday, April 23, 2012 10:13 PM
To: Mike Jones
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-19.txt<= /o:p>

 

On 24/04/2012 4:33 p.m., Mike Jones wrote:

> What specific language would you suggest be = added to what section(s)?

> 

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

 

 

Perhapse the last paragraph appended:<= /p>

"

 

    Because of the security weakne= sses associated with the URI method

    (see Section 5), including the= high likelihood that the URL

    containing the access token wi= ll be logged, it SHOULD NOT be used

    unless it is impossible to tra= nsport the access token in the

    "Authorization" requ= est header field or the HTTP request entity-body.

    Resource servers compliant wit= h this specification MAY support this

    method.

 

    Clients requesting URL contain= ing the access token MUST also send a

    Cache-Control header containin= g the "no-store" option. Server success

    (2xx status) responses to thes= e requests MUST contain a Cache-Control

    header with the "private&= quot; option.

 

"

 

I'm a little suspicious that the "SHOUDL NOT= " in that top paragraph likely should be a MUST NOT to further discour= age needless use.

 

 

AYJ

 

 

> 

> -----Original Message-----

> From: oauth-bounces@iet= f.org On Behalf Of Amos Jeffries

> Sent: Monday, April 23, 2012 7:10 PM

> To: oauth@ietf.org

> Subject: Re: [OAUTH-WG] I-D Action: draft-ie= tf-oauth-v2-bearer-19.txt

> 

> On 24.04.2012 13:46, internet-drafts@ietf.= org wrote:

>> A New Internet-Draft is available from t= he on-line Internet-Drafts

>> directories. This draft is a work item o= f the Web Authorization

>> Protocol Working Group of the IETF.=

>> 

>>       &nbs= p;   Title         &= nbsp; : The OAuth 2.0 Authorization Protocol: Bearer

>> Tokens

>>       &nbs= p;   Author(s)       : Michael B. J= ones

>>       = ;            &n= bsp;        Dick Hardt

>>       = ;             &= nbsp;       David Recordon

>>       &nbs= p;   Filename        : draft-i= etf-oauth-v2-bearer-19.txt

>>       &nbs= p;   Pages         &= nbsp; : 24

>>       &nbs= p;   Date         &n= bsp;  : 2012-04-23

>> 

>>     This specificati= on describes how to use bearer tokens in HTTP

>>     requests to acce= ss OAuth 2.0 protected resources.  Any party in

>>     possession of a = bearer token (a "bearer") can use it to get

>> access to

>>     the associated r= esources (without demonstrating possession of a

>>     cryptographic ke= y).  To prevent misuse, bearer tokens need to be

>>     protected from d= isclosure in storage and in transport.

>> 

>> 

>> A URL for this Internet-Draft is:

>> http://www.ietf.org/i= nternet-drafts/draft-ietf-oauth-v2-bearer-19.txt

> 

> 

> The section 2.3 (URL Query Parameter) text i= s still lacking explicit and specific security requirements. The overarchin= g TLS requirement is good in general, but insufficient in the presence of H= TTP intermediaries on the TLS connection path as is becoming a common practice.

> 

> The upcoming HTTPbis specs document this iss= ue as a requirement for new auth schemes such as Bearer:

> 

> http://tools.ietf.org= /html/draft-ietf-httpbis-p7-auth-19#section-2.3.1

> "

>       &nb= sp; Therefore, new authentication schemes which choose not to carry

>       &nb= sp; credentials in the Authorization header (e.g., using a newly=

>       &nb= sp; defined header) will need to explicitly disallow caching, by=

>       &nb= sp; mandating the use of either Cache-Control request directives=

>       &nb= sp; (e.g., "no-store") or response directives (e.g., "privat= e").

> "

> 

> 

> AYJ

> 

> ____________________________________________= ___

> OAuth mailing list

> OAuth@ietf.org<= /o:p>

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

> 

> 

 

 

--_000_4E1F6AAD24975D4BA5B16804296739436652FBFCTK5EX14MBXC284r_-- From Adam.Lewis@motorolasolutions.com Fri Jun 8 15:43:54 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1227F11E81BC for ; Fri, 8 Jun 2012 15:43:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.966 X-Spam-Level: X-Spam-Status: No, score=-0.966 tagged_above=-999 required=5 tests=[AWL=-0.500, 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 qO4aQB9phGbA for ; Fri, 8 Jun 2012 15:43:52 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe002.messaging.microsoft.com [213.199.154.205]) by ietfa.amsl.com (Postfix) with ESMTP id 9AF3511E8091 for ; Fri, 8 Jun 2012 15:43:29 -0700 (PDT) Received: from mail25-am1-R.bigfish.com (10.3.201.235) by AM1EHSOBE006.bigfish.com (10.3.204.26) with Microsoft SMTP Server id 14.1.225.23; Fri, 8 Jun 2012 22:42:37 +0000 Received: from mail25-am1 (localhost [127.0.0.1]) by mail25-am1-R.bigfish.com (Postfix) with ESMTP id 0841C2C01A4 for ; Fri, 8 Jun 2012 22:42:37 +0000 (UTC) X-Forefront-Antispam-Report: CIP:129.188.136.16; KIP:(null); UIP:(null); IPV:NLI; H:il06gsg01.am.mot-solutions.com; RD:none; EFVD:NLI X-SpamScore: 0 X-BigFish: VPS0(zzc85fhzz1202hzz8275bh8275dhz2fh2a8h683h839hd25hf0ah) Received-SPF: pass (mail25-am1: domain of motorolasolutions.com designates 129.188.136.16 as permitted sender) client-ip=129.188.136.16; envelope-from=Adam.Lewis@motorolasolutions.com; helo=il06gsg01.am.mot-solutions.com ; olutions.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.85; KIP:(null); UIP:(null); (null); H:BL2PRD0410HT004.namprd04.prod.outlook.com; R:internal; EFV:INT Received: from mail25-am1 (localhost.localdomain [127.0.0.1]) by mail25-am1 (MessageSwitch) id 1339195354698899_24101; Fri, 8 Jun 2012 22:42:34 +0000 (UTC) Received: from AM1EHSMHS007.bigfish.com (unknown [10.3.201.231]) by mail25-am1.bigfish.com (Postfix) with ESMTP id A54B7440239 for ; Fri, 8 Jun 2012 22:42:34 +0000 (UTC) Received: from il06gsg01.am.mot-solutions.com (129.188.136.16) by AM1EHSMHS007.bigfish.com (10.3.207.107) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 8 Jun 2012 22:42:34 +0000 Received: from il06gsg01.am.mot-solutions.com (il06vts01.mot.com [129.188.137.141]) by il06gsg01.am.mot-solutions.com (8.14.3/8.14.3) with ESMTP id q58MZPca003107 for ; Fri, 8 Jun 2012 18:35:25 -0400 (EDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe005.messaging.microsoft.com [216.32.180.31]) by il06gsg01.am.mot-solutions.com (8.14.3/8.14.3) with ESMTP id q58MZO9I003104 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 8 Jun 2012 18:35:25 -0400 (EDT) Received: from mail142-va3-R.bigfish.com (10.7.14.246) by VA3EHSOBE002.bigfish.com (10.7.40.22) with Microsoft SMTP Server id 14.1.225.23; Fri, 8 Jun 2012 22:42:32 +0000 Received: from mail142-va3 (localhost [127.0.0.1]) by mail142-va3-R.bigfish.com (Postfix) with ESMTP id BB2284C0420 for ; Fri, 8 Jun 2012 22:42:31 +0000 (UTC) Received: from mail142-va3 (localhost.localdomain [127.0.0.1]) by mail142-va3 (MessageSwitch) id 1339195349709792_26999; Fri, 8 Jun 2012 22:42:29 +0000 (UTC) Received: from VA3EHSMHS031.bigfish.com (unknown [10.7.14.244]) by mail142-va3.bigfish.com (Postfix) with ESMTP id 9E2E32003F for ; Fri, 8 Jun 2012 22:42:29 +0000 (UTC) Received: from BL2PRD0410HT004.namprd04.prod.outlook.com (157.56.240.85) by VA3EHSMHS031.bigfish.com (10.7.99.41) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 8 Jun 2012 22:42:29 +0000 Received: from BL2PRD0410MB363.namprd04.prod.outlook.com ([169.254.3.212]) by BL2PRD0410HT004.namprd04.prod.outlook.com ([10.255.99.39]) with mapi id 14.16.0164.004; Fri, 8 Jun 2012 22:43:20 +0000 From: Lewis Adam-CAL022 To: "oauth@ietf.org" Thread-Topic: Authorization Request via back channel / direct communication? Thread-Index: Ac1FyBd3lOmctaVIR/OLtuzN7H7cRQ== Date: Fri, 8 Jun 2012 22:43:19 +0000 Message-ID: <59E470B10C4630419ED717AC79FCF9A90AED9537@BL2PRD0410MB363.namprd04.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [150.130.26.74] Content-Type: multipart/alternative; boundary="_000_59E470B10C4630419ED717AC79FCF9A90AED9537BL2PRD0410MB363_" MIME-Version: 1.0 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: BL2PRD0410HT004.namprd04.prod.outlook.com X-MS-Exchange-CrossPremises-SCL: -1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-rules-execution-history: Sample Spam Submissions X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-MS-Exchange-CrossPremises-ContentConversionOptions: False; 00160000; True; ; iso-8859-1 X-OrganizationHeadersPreserved: BL2PRD0410HT004.namprd04.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$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: [OAUTH-WG] Authorization Request via back channel / direct communication? X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 22:43:55 -0000 --_000_59E470B10C4630419ED717AC79FCF9A90AED9537BL2PRD0410MB363_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I have a historical question around front channel / back channel (direct) c= ommunications and Authorization Requests. Both the code-flow and implicit-= flow utilize a front channel communication through the UA. This makes sens= e for the delegated credentials case (e.g. shutterfly accessing photos on f= acebook). I'm in the native app / client market, and the RO password credentials flow= fits really well ... expect it's limited to passwords. I've been well edu= cated (by lots of folks on this list) about the "best practices" to enable = native clients to use the code flow, e.g. registering a custom callback URI= and register my native app ass the handler for that URI. But ... (and not knowing the history behind all this), it seems that OAuth = was designed for confidential clients, and was "retro-fitted" to make nativ= e apps work. And it just feels a bit like a hack to me (albeit a workable = one), the whole custom callback URI thing, to get it to work. The RO passw= ord credentials seems like a much better fit for native apps, since it has = no need for the UA and can use back channel / direction communication to ta= lk to the AS and obtain and access token. But that limits me to a password= and eliminates any chance of strong authentication. It would seem more straight forward to define a back channel flow such that= a native client could send off an authorization request with response=3Dto= ken (or id_token in the Connect case), respond to a challenge from the AS f= or authentication, and obtain a response containing the access_token / id_t= oken and use it for its RESTful API communications with the RS/RP. This wo= uld enable strong authentication methods not possible using just RO passwor= ds. Has anybody else ever expressed interest in such back channel calls between= for native clients? Was it previously considered and dropped? Tx! adam --_000_59E470B10C4630419ED717AC79FCF9A90AED9537BL2PRD0410MB363_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I have a historical= question around front channel / back channel (direct) communications and A= uthorization Requests.  Both the code-flow and implicit-flow utilize a= front channel communication through the UA.  This makes sense for the delegated credentials case (e.g. shutte= rfly accessing photos on facebook). 

 

I’m in the na= tive app / client market, and the RO password credentials flow fits really = well … expect it’s limited to passwords.  I’ve been = well educated (by lots of folks on this list) about the “best practic= es” to enable native clients to use the code flow, e.g. registering a custom c= allback URI and register my native app ass the handler for that URI. 

 

But … (and no= t knowing the history behind all this), it seems that OAuth was designed fo= r confidential clients, and was “retro-fitted” to make native a= pps work.  And it just feels a bit like a hack to me (albeit a workable one), the whole custom callback URI thing, to get it to work.&n= bsp; The RO password credentials seems like a much better fit for native ap= ps, since it has no need for the UA and can use back channel / direction co= mmunication to talk to the AS and obtain and access token.  But that limits me to a password and eliminates an= y chance of strong authentication.

 

It would seem more = straight forward to define a back channel flow such that a native client co= uld send off an authorization request with response=3Dtoken (or id_token in= the Connect case), respond to a challenge from the AS for authentication, and obtain a response containing the acces= s_token / id_token and use it for its RESTful API communications with the R= S/RP.  This would enable strong authentication methods not possible us= ing just RO passwords.

 

Has anybody else ev= er expressed interest in such back channel calls between for native clients= ?  Was it previously considered and dropped? 

 

Tx!
adam

--_000_59E470B10C4630419ED717AC79FCF9A90AED9537BL2PRD0410MB363_-- From jricher@mitre.org Fri Jun 8 18:00:48 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 203ED21F865F for ; Fri, 8 Jun 2012 18:00:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9-lLm1HOg6Fw for ; Fri, 8 Jun 2012 18:00:47 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id C71CD21F85FC for ; Fri, 8 Jun 2012 18:00:46 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 5B9C421B13FC; Fri, 8 Jun 2012 21:00:45 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 4C32B21B05A3; Fri, 8 Jun 2012 21:00:45 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.127]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.02.0283.003; Fri, 8 Jun 2012 21:00:45 -0400 From: "Richer, Justin P." To: Lewis Adam-CAL022 Thread-Topic: [OAUTH-WG] Authorization Request via back channel / direct communication? Thread-Index: Ac1FyBd3lOmctaVIR/OLtuzN7H7cRQANLusA Date: Sat, 9 Jun 2012 01:00:44 +0000 Message-ID: <526CE92D-E1BB-4FA1-B8B9-B776C86DC5BA@mitre.org> References: <59E470B10C4630419ED717AC79FCF9A90AED9537@BL2PRD0410MB363.namprd04.prod.outlook.com> In-Reply-To: <59E470B10C4630419ED717AC79FCF9A90AED9537@BL2PRD0410MB363.namprd04.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.17.4] Content-Type: multipart/alternative; boundary="_000_526CE92DE1BB4FA1B8B9B776C86DC5BAmitreorg_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Authorization Request via back channel / direct communication? X-BeenThere: oauth@ietf.org X-Mailman-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, 09 Jun 2012 01:00:48 -0000 --_000_526CE92DE1BB4FA1B8B9B776C86DC5BAmitreorg_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable You're right in that OAuth is optimized for the confidential clients case -= - specifically, a client being a web server talking to another web server. = But what you've just described, in a nutshell, is the assertion grant type: http://tools.ietf.org/html/draft-ietf-oauth-assertions-03 Which has been profile for both SAML and JWT assertions here: http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-12 http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-04 And could be extended to house any number of stronger-auth circumstances an= d formats. I believe Google and Deutch Telekom are making wide use of this = today (correct me if I'm remembering incorrectly). But I'll say that for many cases it's still best practice to use the code f= low and go through a UI for one simple but subtle reason: a browser can tak= e in an infinitely diverse set of user credentials and the UI can change at= any time without making any changes to the native code. Say you've got an = OAuth backed native app that everyone's using the code flow and a username = and password for. Great, works, no problem. Then you decide that you're not= doing un/pw anymore and everyone needs to have a second factor, or do a ca= ptcha, or any number of other little things when they sign in and use the a= pp. These kinds of things are *easy* to add to a web server's login page, b= ut much harder to deal with in a native app directly. Challenge response sc= enarios are *trivial* with a web page -- they're practically made for it. A= nd extend this scenario further by saying that you'll now let people log in= to your service using OpenID or another distributed identity protocol. All = of this is really easy for the web server at the AS to handle, and the nati= ve app through all of this needs to be none the wiser. And this is a Very G= ood Thing. Plus it also gets your app out of the business of ever having to= see users credentials directly. Remember: when you're doing the Resource O= wners Credentials Flow, you're basically doing a benevolent man in the midd= le attack. Sure it works, and it beats logging in directly as the user at a= ll times, but only just so. We actually ran into exactly this kind of thing a few years ago with an app= here. It went like this: * Dev team was building a native application to connect to a website that h= ad several different auth mechanisms including a username/password authenti= cation key (similar to the OAuth2 un/pw flow) and OAuth 1. * They went with the un/pw setup because they figured it was easier and the= ir native app could just ask for the un/pw combination. * This all worked swimmingly in the dev environment with all the test accou= nts * They roll to the integration environment which, like the Production syste= m, was protected by OpenID 2.0 and not a username/password. In fact, none o= f the users on the system -- including the developers themselves -- actuall= y had anything resembling a local password. Their app was completely at a l= oss -- the users couldn't present anything to the app to log them in direct= ly at all. * After some head scratching and scrambling, they switched the whole app se= tup to OAuth (again, 1.0a). Now they could use the same exact code in the d= ev, integration, and production environments. And it worked across all user= sets, regardless of how they got in the front door. *And* it will continue= to work when we eventually upgrade this same service to use OpenID Connect= instead of OpenID 2.0 in the future. Hope this sheds some light on this, -- Justin On Jun 8, 2012, at 6:43 PM, Lewis Adam-CAL022 wrote: Hi, I have a historical question around front channel / back channel (direct) c= ommunications and Authorization Requests. Both the code-flow and implicit-= flow utilize a front channel communication through the UA. This makes sens= e for the delegated credentials case (e.g. shutterfly accessing photos on f= acebook). I=92m in the native app / client market, and the RO password credentials fl= ow fits really well =85 expect it=92s limited to passwords. I=92ve been we= ll educated (by lots of folks on this list) about the =93best practices=94 = to enable native clients to use the code flow, e.g. registering a custom ca= llback URI and register my native app ass the handler for that URI. But =85 (and not knowing the history behind all this), it seems that OAuth = was designed for confidential clients, and was =93retro-fitted=94 to make n= ative apps work. And it just feels a bit like a hack to me (albeit a worka= ble one), the whole custom callback URI thing, to get it to work. The RO p= assword credentials seems like a much better fit for native apps, since it = has no need for the UA and can use back channel / direction communication t= o talk to the AS and obtain and access token. But that limits me to a pass= word and eliminates any chance of strong authentication. It would seem more straight forward to define a back channel flow such that= a native client could send off an authorization request with response=3Dto= ken (or id_token in the Connect case), respond to a challenge from the AS f= or authentication, and obtain a response containing the access_token / id_t= oken and use it for its RESTful API communications with the RS/RP. This wo= uld enable strong authentication methods not possible using just RO passwor= ds. Has anybody else ever expressed interest in such back channel calls between= for native clients? Was it previously considered and dropped? Tx! adam _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_526CE92DE1BB4FA1B8B9B776C86DC5BAmitreorg_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable You're right in that OAuth is optimized for the confidential clients case -= - specifically, a client being a web server talking to another web server. = But what you've just described, in a nutshell, is the assertion grant type:


Which has been profile for both SAML and JWT assertions here:


And could be extended to house any number of stronger-auth circumstanc= es and formats. I believe Google and Deutch Telekom are making wide use of = this today (correct me if I'm remembering incorrectly).

But I'll say that for many cases it's still best practice to use the c= ode flow and go through a UI for one simple but subtle reason: a browser ca= n take in an infinitely diverse set of user credentials and the UI can chan= ge at any time without making any changes to the native code. Say you've got an OAuth backed native app that= everyone's using the code flow and a username and password for. Great, wor= ks, no problem. Then you decide that you're not doing un/pw anymore and eve= ryone needs to have a second factor, or do a captcha, or any number of other little things when they sign in an= d use the app. These kinds of things are *easy* to add to a web server's lo= gin page, but much harder to deal with in a native app directly. Challenge = response scenarios are *trivial* with a web page -- they're practically made for it. And extend this scenar= io further by saying that you'll now let people log into your service using= OpenID or another distributed identity protocol. All of this is really eas= y for the web server at the AS to handle, and the native app through all of this needs to be none the wiser.= And this is a Very Good Thing. Plus it also gets your app out of the busin= ess of ever having to see users credentials directly. Remember: when you're= doing the Resource Owners Credentials Flow, you're basically doing a benevolent man in the middle attack. Sure i= t works, and it beats logging in directly as the user at all times, but onl= y just so.

We actually ran into exactly this kind of thing a few years ago with a= n app here. It went like this:

* Dev team was building a native application to connect to a website t= hat had several different auth mechanisms including a username/password aut= hentication key (similar to the OAuth2 un/pw flow) and OAuth 1. 
* They went with the un/pw setup because they figured it was easier an= d their native app could just ask for the un/pw combination.
* This all worked swimmingly in the dev environment with all the test = accounts
* They roll to the integration environment which, like the Production = system, was protected by OpenID 2.0 and not a username/password. In fact, n= one of the users on the system -- including the developers themselves -- ac= tually had anything resembling a local password. Their app was completely at a loss -- the users couldn't p= resent anything to the app to log them in directly at all. 
* After some head scratching and scrambling, they switched the whole a= pp setup to OAuth (again, 1.0a). Now they could use the same exact code in = the dev, integration, and production environments. And it worked across all= user sets, regardless of how they got in the front door. *And* it will continue to work when we eventually u= pgrade this same service to use OpenID Connect instead of OpenID 2.0 in the= future.


Hope this sheds some light on this,
 -- Justin


On Jun 8, 2012, at 6:43 PM, Lewis Adam-CAL022 wrote:

Hi,
 
I have a historical question around front= channel / back channel (direct) communications and Authorization Requests.=   Both the code-flow and implicit-flow utilize a front channel communi= cation through the UA.  This makes sense for the delegated credentials case (e.g. shutterfly accessing photos on fa= cebook). 
 
I=92m in the native app / client market, = and the RO password credentials flow fits really well =85 expect it=92s lim= ited to passwords.  I=92ve been well educated (by lots of folks on thi= s list) about the =93best practices=94 to enable native clients to use the code flow, e.g. registering a custom callback URI and r= egister my native app ass the handler for that URI. =
 
But =85 (and not knowing the history behi= nd all this), it seems that OAuth was designed for confidential clients, an= d was =93retro-fitted=94 to make native apps work.  And it just feels = a bit like a hack to me (albeit a workable one), the whole custom callback URI thing, to get it to work.  The RO passw= ord credentials seems like a much better fit for native apps, since it has = no need for the UA and can use back channel / direction communication to ta= lk to the AS and obtain and access token.  But that limits me to a password and eliminates any chance of strong authe= ntication.
 
It would seem more straight forward to de= fine a back channel flow such that a native client could send off an author= ization request with response=3Dtoken (or id_token in the Connect case), re= spond to a challenge from the AS for authentication, and obtain a response containing the access_token / id_tok= en and use it for its RESTful API communications with the RS/RP.  This= would enable strong authentication methods not possible using just RO pass= words.
 
Has anybody else ever expressed interest = in such back channel calls between for native clients?  Was it previou= sly considered and dropped? 
 
Tx!
adam
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oaut= h

--_000_526CE92DE1BB4FA1B8B9B776C86DC5BAmitreorg_-- From jricher@mitre.org Fri Jun 8 18:08:22 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 412E011E816E for ; Fri, 8 Jun 2012 18:08:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DPHs4D64NJz9 for ; Fri, 8 Jun 2012 18:08:21 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id E363A11E80E2 for ; Fri, 8 Jun 2012 18:08:17 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 8FA6521B1402; Fri, 8 Jun 2012 21:08:17 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 78C6A21B06EE; Fri, 8 Jun 2012 21:08:17 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.127]) by IMCCAS01.MITRE.ORG ([129.83.29.78]) with mapi id 14.02.0283.003; Fri, 8 Jun 2012 21:08:17 -0400 From: "Richer, Justin P." To: Peter Saint-Andre Thread-Topic: [OAUTH-WG] OAuth Core -27 Published Thread-Index: Ac1Fn1Jbo88ebeoKTpWmysQQYHT6BwAP9QqAAAAeZoAAB5AcAA== Date: Sat, 9 Jun 2012 01:08:17 +0000 Message-ID: References: <4E1F6AAD24975D4BA5B16804296739436652F47C@TK5EX14MBXC284.redmond.corp.microsoft.com> <4FD26F3F.6000503@stpeter.im> In-Reply-To: <4FD26F3F.6000503@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.17.4] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth Core -27 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: Sat, 09 Jun 2012 01:08:22 -0000 I saw the new draft and assumed that Eran had published it, as he has been = doing so all along. If this is not the case, I also find this very surprisi= ng, even though with three authors on the spec I can see how it can happen = from a mechanical level. But even so, shouldn't all three authors at least = be aware of the publication? -- Justin On Jun 8, 2012, at 5:31 PM, Peter Saint-Andre wrote: > I must say that I found it surprising, too. An explanation beforehand > from the chairs would have helped to prevent confusion. >=20 > On 6/8/12 3:28 PM, Eran Hammer wrote: >> What the hell just happened? Even if this is allowed under IETF rules, >> it is clearly against IETF spirit. There is now a published draft with >> my name as sole editor and text I didn't put in there. No one even >> suggested this is something the chairs might do.=20 >>=20 >> After all the work I put into this, this is a huge slap in the face by >> the chairs.=20 >>=20 >> I hope the fact the Mike Jonea just took over with the blessing on the >> chairs bothers someone else too.=20 >>=20 >> EH >>=20 >> On Jun 8, 2012, at 13:51, "Mike Jones" > > wrote: >>=20 >>> The chairs approved publication of OAuth Core draft -27 today. This >>> version is based upon the proposed changes that I=92d circulated to the >>> working group. Changes are: >>>=20 >>> =B7 Adds character set restrictions for error, error_description= , >>> and error_uri parameters consistent with the OAuth Bearer spec. >>>=20 >>> =B7 Adds =93resource access error response=94 as an error usage >>> location in the OAuth Extensions Error Registry. >>>=20 >>> =B7 Adds an ABNF for all message elements. >>>=20 >>> =B7 Corrects editorial issues identified during review >>>=20 >>>=20 >>>=20 >>> There are still potential issues with some ABNF definitions that need >>> to be discussed by the working group. I=92ll send a separate note abou= t >>> that. Nonetheless, the chairs felt that publishing this version would >>> be a step in the right direction towards completing the Core and >>> Bearer specifications. >>>=20 >>>=20 >>>=20 >>> I=92ll be publishing an updated Bearer draft shortly that references th= e >>> changes in -27 in ways that should resolve the outstanding DISCUSS >>> issues against Bearer. >>>=20 >>>=20 >>>=20 >>> Thanks to Dick Hart for publishing the draft. >>>=20 >>>=20 >>>=20 >>> -- Mike >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Fri Jun 8 18:10:38 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B23D111E80FE for ; Fri, 8 Jun 2012 18:10:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W5g9aJzypsca for ; Fri, 8 Jun 2012 18:10:29 -0700 (PDT) Received: from p3plex2out04.prod.phx3.secureserver.net (p3plex2out04.prod.phx3.secureserver.net [184.168.131.18]) by ietfa.amsl.com (Postfix) with ESMTP id 4DC6211E80E2 for ; Fri, 8 Jun 2012 18:10:28 -0700 (PDT) Received: from P3PWEX2HT003.ex2.secureserver.net ([184.168.131.11]) by p3plex2out04.prod.phx3.secureserver.net with bizsmtp id L1AT1j0060EuLVk011AT6X; Fri, 08 Jun 2012 18:10:27 -0700 Received: from P3PWEX2MB008.ex2.secureserver.net ([169.254.8.66]) by P3PWEX2HT003.ex2.secureserver.net ([184.168.131.11]) with mapi id 14.02.0247.003; Fri, 8 Jun 2012 18:10:27 -0700 From: Eran Hammer To: Mike Jones , Hannes Tschofenig Thread-Topic: [OAUTH-WG] Error Encoding: Conclusion Thread-Index: AQHNORGtuzciwTXPbU2x0B3Abs7zkpbYRq5QgACsJID//4uLsIAJZTAAgAJh//qAABEIwIAC2lKAgAoSIyA= Date: Sat, 9 Jun 2012 01:10:26 +0000 Message-ID: <0CBAEB56DDB3A140BA8E8C124C04ECA201068637@P3PWEX2MB008.ex2.secureserver.net> References: <4E1F6AAD24975D4BA5B168042967394366516960@TK5EX14MBXC284.redmond.corp.microsoft.com> <0CBAEB56DDB3A140BA8E8C124C04ECA20104B3A1@P3PWEX2MB008.ex2.secureserver.net> <4E1F6AAD24975D4BA5B16804296739436651E440@TK5EX14MBXC284.redmond.corp.microsoft.com> <869336FE-0265-4982-B9DE-E2FAE06CD545@gmx.net> <0CBAEB56DDB3A140BA8E8C124C04ECA20105888A@P3PWEX2MB008.ex2.secureserver.net> <4E1F6AAD24975D4BA5B16804296739436652630D@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436652630D@TK5EX14MBXC284.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [68.36.195.242] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Error Encoding: Conclusion X-BeenThere: oauth@ietf.org X-Mailman-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, 09 Jun 2012 01:10:38 -0000 The new text published today for section 7.2 isn't acceptable. It seems (th= e lanaguage is unclear when it comes to its actual requirements) to indicat= e that any protocol used for OAuth token authentication using an error para= meter named "error" must use the new registry. Any authentication method no= t using a parameter named "error" does not have to comply with this. Questions: Can anyone write extensions where the parameter name is "err" and ignore th= is entire registry? The text already states that returning errors not using= a parameter are excluded. If someone defines a new HTTP authentication scheme outside of this WG whic= h may be used for token authentication and uses "error", does this establis= h any requirement to use the registry? What happens when the WG tries to ad= opt it for OAuth usage? The new text does not address the chairs instruction to break the registry = into separate tables for each location. As specified, IANA is going to crea= te a single table. Since this was announced in a consensus call by the chai= rs, the new text must comply unless the chairs change their mind on this. EH > -----Original Message----- > From: Mike Jones [mailto:Michael.Jones@microsoft.com] > Sent: Saturday, June 02, 2012 1:08 AM > To: Eran Hammer; Hannes Tschofenig > Cc: oauth@ietf.org WG > Subject: RE: [OAUTH-WG] Error Encoding: Conclusion >=20 > After speaking with the chairs, I volunteered to write a draft of the ABN= F text > to keep things moving towards completion. An updated version of Core > including the ABNF and my previous proposed changes addressing the > consensus call issues is attached. As long as I was at it, I also fixed = the issues > that Phil identified and ran a spell/grammar check on the draft and corre= cted > the issues identified. The significant diffs since my previous proposed > version, other than the new ABNF section, also follow inline for working > group review. >=20 > I'll send a separate note with the new ABNF section outlining aspects of = the > ABNF that I believe should be specifically reviewed by the working group. >=20 > Hopefully a new Core draft with all of these resolutions can be published > shortly, at which point I'll be able to publish a Bearer draft that refer= ences > these resolutions, enabling us to close the outstanding DISCUSS issues. >=20 > Best wishes, > -- Mike >=20 > P.S. Bill, looking at it further, you were right that vestiges of the le= ading > ALPHA in the error syntax remained in my previous draft, making it > inconsistent. I've addressed this in the new draft. >=20 > 715,720c715,720 > < o specifies the client type as described in Section 2.1, > < o provides its client redirection URIs as described in > < Section 3.1.2, and > < o includes any other information required by the authorization > < server (e.g. application name, website, description, logo image, > < the acceptance of legal terms). > --- > > o specify the client type as described in Section 2.1, > > o provide its client redirection URIs as described in Section 3.1.2= , > > and > > o include any other information required by the authorization serve= r > > (e.g. application name, website, description, logo image, the > > acceptance of legal terms). > 807c807 > < secret, it is exposed to the resource owner, and MUST NOT be used > --- > > secret; it is exposed to the resource owner, and MUST NOT be used > 2663,2666c2663,2666 > < Error codes MUST conform to the error-code ABNF, and SHOULD be > --- > > Error codes MUST conform to the error ABNF, and SHOULD be > 2669,2670c2669,2670 > < error-code =3D ALPHA *error-char > < error-char =3D "-" / "." / "_" / DIGIT / ALPHA > --- > > error =3D 1*error-char > > error-char =3D %x20-21 / %x23-5B / %x5D-7E > < client, was issued to the that client by the authorization server. > --- > > client was issued to that client by the authorization server. > 3128c3128 > < respectively. For older browsers, javascript framebusting technique= s > --- > > respectively. For older browsers, JavaScript framebusting > > techniques > 3178c3178 > < ([RFC5226]) after a two weeks review period on the [TBD]@ietf.org > --- > > ([RFC5226]) after a two week review period on the [TBD]@ietf.org > 3238c3238 > < Specification Required ([RFC5226]) after a two weeks review period o= n > --- > > Specification Required ([RFC5226]) after a two week review period > > on > 3398,3403c3398,3403 > < registered with a Specification Required ([RFC5226]) after a two wee= ks > --- > > registered with a Specification Required ([RFC5226]) after a two > > week > 3463,3465c3463,3465 > < after a two weeks review period on the [TBD]@ietf.org mailing list, > --- > > after a two week review period on the [TBD]@ietf.org mailing list, > 3593a3594,3598 > > [I-D.ietf-httpbis-p7-auth] > > Fielding, R., Lafon, Y., and J. Reschke, "HTTP/1.1, part > > 7: Authentication", draft-ietf-httpbis-p7-auth-19 (work i= n > > progress), March 2012. > > > 3616,3621d3620 > < [OASIS.saml-core-2.0-os] > < Cantor, S., Kemp, J., Philpott, R., and E. Maler, > < "Assertions and Protocol for the OASIS Security Assertion > < Markup Language (SAML) V2.0", OASIS Standard saml-core- > < 2.0-os, March 2005. > < > 3628,3633c3627,3630 > < McGloin, Phil Hunt, and Anthony Nadalin. > --- > > McGloin, Phil Hunt, and Anthony Nadalin. The ABNF section was > > drafted by Michael B. Jones. >=20 > -----Original Message----- > From: Eran Hammer [mailto:eran@hueniverse.com] > Sent: Thursday, May 31, 2012 12:35 PM > To: Hannes Tschofenig > Cc: Mike Jones; oauth@ietf.org WG > Subject: RE: [OAUTH-WG] Error Encoding: Conclusion >=20 > I'll first review the proposed text (as a WG member) and raise any issues > remaining (if any). >=20 > I will wait until the ABNF text is provided before publishing another ver= sion. >=20 > EH >=20 > > -----Original Message----- > > From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net] > > Sent: Thursday, May 31, 2012 10:54 AM > > To: Eran Hammer > > Cc: Mike Jones; oauth@ietf.org WG; Hannes Tschofenig > > Subject: Re: [OAUTH-WG] Error Encoding: Conclusion > > > > Eran, could you publish a new draft version by Sunday with these > > changes incorporated? That should give the working group enough time > > to look at these few paragraphs. > > > > In the meanwhile we are working on addressing the ABNF issue Sean > > raised and we will then go for another update. > > > > Ciao > > Hannes > > > > On May 31, 2012, at 8:20 PM, Hannes Tschofenig wrote: > > > > > Hi Mike, > > > > > > thank you for compiling the text. It looks good to me. I have not > > > seen > > anyone from the working group screaming either. > > > > > > Eran, can you incorporate these changes into the next draft version? > > > > > > Ciao > > > Hannes > > > > > > On May 30, 2012, at 2:10 AM, Mike Jones wrote: > > > > > >> I've made another set of updates to a copy of Core -26 to address > > >> the > > questions raised by Eran and David below (attached). > > >> > > >> An unrelated change that you should probably pick up, Eran is > > >> adding this > > to the section, so that the heading shows that the draft is a > > product of the "OAuth Working Group" rather than the "Network Working > Group": > > >> Security > > >> OAuth Working Group > > >> > > >> One change I didn't make, but that should be considered, is to > > >> delete the > > reference to OASIS.saml-core-2.0-os, since it is used by no in > > the document. > > >> > > >> The new proposed text for Section 7.2 follows: > > >> > > >> 7.2. Error Response > > >> > > >> If a resource access request fails, the resource server SHOULD inf= orm > > >> the client of the error. While the specific error responses possi= ble > > >> and methods for transmitting those errors when using any particula= r > > >> access token type are beyond the scope of this specification, any > > >> "error" code values defined for use with OAuth resource access > > >> methods MUST be registered (following the procedures in > > >> Section 11.4). > > >> > > >> Specifically, when the OAuth resource access method uses an "error= " > > >> result parameter to return an error code value that indicates the > > >> resource access error encountered, then these error code values > MUST > > >> be registered. Values for these "error" codes MUST NOT include > > >> characters outside the set %x20-21 / %x23-5B / %x5D-7E. When an > > >> "error" code value is registered for use by an OAuth resource acce= ss > > >> method, should that same code already be registered for use by > > >> another OAuth resource access method or at a different OAuth error > > >> usage location, then the meaning of that error code value in in th= e > > >> new registration MUST be consistent with the its meaning in prior > > >> registrations. > > >> > > >> The OAuth resource access error registration requirement applies o= nly > > >> to "error" code values and not to other means of returning error > > >> indications, including HTTP status codes, or other error-related > > >> result parameters, such as "error_description", "error_uri", or ot= her > > >> kinds of error status return methods that may be employed by the > > >> resource access method. There is no requirement that OAuth resour= ce > > >> access methods employ an "error" parameter. > > >> > > >> Hopefully incorporating these changes will enable us to close the > > remaining DISCUSS issues on both the Core and Bearer drafts. > > >> > > >> Thank= s all, > > >> -- > > >> Mike > > >> > > >> > > >> From: Eran Hammer [mailto:eran@hueniverse.com] > > >> Sent: Wednesday, May 23, 2012 11:45 PM > > >> To: David Recordon; Mike Jones; Hannes Tschofenig > > >> Cc: oauth@ietf.org WG > > >> Subject: RE: [OAUTH-WG] Error Encoding: Conclusion > > >> > > >> With the exception of section 7.2, the changes look reasonable and > > >> will be > > applied in the next revision. > > >> > > >> The new section 7.2 is confusion and does not explain the new regist= ry. > > The section introduces a new requirement to register 'any error codes > > defined for use with OAuth resource access methods'. This requirement > > is too vague. > > >> > > >> I have no clue how to (for example) apply this text to the MAC draft= . > > Adding to David's list below: > > >> > > >> * Should the HTTP status codes used by the MAC spec as currently > > >> written > > be registered (since no guidance is given to the use of an error parame= ter)? > > >> * Does this introduce a requirement to add an error parameter? > > >> * Does the parameter need to / should be called 'error'? > > >> * What about future methods in which errors are not simply > > >> expressed in > > the form of a fixes string? > > >> > > >> EH > > >> > > >> > > >> From: David Recordon [mailto:recordond@gmail.com] > > >> Sent: Wednesday, May 23, 2012 11:38 PM > > >> To: Mike Jones; Hannes Tschofenig; Eran Hammer > > >> Cc: oauth@ietf.org WG > > >> Subject: Re: [OAUTH-WG] Error Encoding: Conclusion > > >> > > >> Honestly still trying to fully wrap my head around what's going on > > >> here > > since it seems far more complex than the threads are alluding to. In > > any case, does Mike's text address what Eran brought up as needed in > > the thread Hannes referenced or is Eran wrong? > > >> > > >> The core spec currently provides full guidance and definition for > > >> error > > extensibility. Extending the registry's scope means the need for > > non-trivial new text that: > > >> > > >> * explains the process of adding new errors for endpoints not > > >> defined by > > this specification, > > >> * finds a common ground for value restrictions beyond what is > > >> already > > listed, > > >> * guide authors of future HTTP authentication schemes meant for use > > with OAuth (e.g. MAC) for their requirements for using the error > > registry, and > > >> * address the very likely scenario of the same error code carrying > > different meanings in different endpoints, or an extension that adds a > > location to a code already defined elsewhere - something very likely > > to happen if you cross the two very different domains (OAuth > > endpoints, Protected resource endpoints). This requires changing the > > entire structure of the registry to create separate records for each > code/location pair. > > >> > > >> Thanks, > > >> --David > > >> > > >> On Wed, May 23, 2012 at 10:22 PM, Mike Jones > > wrote: > > >> Thanks Hannes. In the interest of hopefully completing the edits > > >> to > > remove the DISCUSS issues for the Bearer and Core specs in the next > > few days so that we can send the docs to the RFC editors, I'd like to > > propose specific language for the Core spec to address both of the > > consensus call issue resolutions. After there's consensus on the > > specific text for Core, it will be easy for us to add a reference in > > Bearer to the language in Core for the error syntax restrictions and > > to use the OAuth errors registry. I'll do that in parallel with the di= scussions > on the proposed core language changes. > > >> > > >> > > >> > > >> A summary of the changes I made in response to the consensus call > > conclusions are: > > >> > > >> * Add syntax restrictions for "error", "error_description", a= nd > > "error_uri" from Bearer to Core > > >> > > >> * Add section 7.2 about error responses from resource access > requests > > >> > > >> * Add "resource access error response" to the category of OAu= th > > errors that can be registered > > >> > > >> > > >> > > >> Additional editorial changes that I made as I encountered issues in > > >> the > > document were: > > >> > > >> * Updated out of date references, especially the draft-hardt-= oauth- > 01 > > reference, which contained an invalid link > > >> > > >> * Added Derek Atkins to the list of chairs > > >> > > >> * Added Yaron Goland's middle initial Y. (since he prefers to= include > it > > in publications) > > >> > > >> * Replaced use of the deprecated element, which > > prevented the spec from building with strict checking, with a > >
element in the section (which creates an appendix) > > >> > > >> > > >> > > >> To make it easy to incorporate these changes into the document and > > >> so > > the proposed changes are unambiguous, I produced an edited version of > > Core -26 containing these changes. The xml, txt, and html versions > > are attached to facilitate review. Pertinent diffs from the .txt versi= on > follow. > > >> > > >> > > >> > > >> Cheers, > > >> > > >> -- Mike > > >> > > >> > > >> > > >> 683c683,684 > > >> > > >> < notation of [RFC5234]. > > >> > > >> --- > > >> > > >>> notation of [RFC5234]. Additionally, the rule URI-Reference is > > >> > > >>> included from Uniform Resource Identifier (URI) [RFC3986]. > > >> > > >> 1441c1441,1442 > > >> > > >> < REQUIRED. A single error code from the following: > > >> > > >> --- > > >> > > >>> REQUIRED. A single ASCII [USASCII] error code from the > > >> > > >>> following: > > >> > > >> 1474a1475,1476 > > >> > > >>> Values for the "error" parameter MUST NOT include > > >>> characters > > >> > > >>> outside the set %x20-21 / %x23-5B / %x5D-7E. > > >> > > >> 1476c1478 > > >> > > >> < OPTIONAL. A human-readable UTF-8 encoded text providing > > >> > > >> --- > > >> > > >>> OPTIONAL. A human-readable ASCII [USASCII] text providing > > >> > > >> 1478a1481,1482 > > >> > > >>> Values for the "error_description" parameter MUST NOT > > >>> include > > >> > > >>> characters outside the set %x20-21 / %x23-5B / %x5D-7E. > > >> > > >> 1482a1487,1489 > > >> > > >>> Values for the "error_uri" parameter MUST conform to the > > >>> URI- > > >> > > >>> Reference syntax, and thus MUST NOT include characters > > >>> outside > > >> > > >>> the set %x21 / %x23-5B / %x5D-7E. > > >> > > >> 1840c1840,1841 > > >> > > >> < REQUIRED. A single error code from the following: > > >> > > >> --- > > >> > > >>> REQUIRED. A single ASCII [USASCII] error code from the > > >> > > >>> following: > > >> > > >> 1873a1874,1875 > > >> > > >>> Values for the "error" parameter MUST NOT include > > >>> characters > > >> > > >>> outside the set %x20-21 / %x23-5B / %x5D-7E. > > >> > > >> 1875c1877 > > >> > > >> < OPTIONAL. A human-readable UTF-8 encoded text providing > > >> > > >> --- > > >> > > >>> OPTIONAL. A human-readable ASCII [USASCII] text providing > > >> > > >> 1877a1880,1881 > > >> > > >>> Values for the "error_description" parameter MUST NOT > > >>> include > > >> > > >>> characters outside the set %x20-21 / %x23-5B / %x5D-7E. > > >> > > >> 1881a1886,1888 > > >> > > >>> Values for the "error_uri" parameter MUST conform to the > > >>> URI- > > >> > > >>> Reference syntax, and thus MUST NOT include characters > > >>> outside > > >> > > >>> the set %x21 / %x23-5B / %x5D-7E. > > >> > > >> < REQUIRED. A single error code from the following: > > >> > > >> --- > > >> > > >>> REQUIRED. A single ASCII [USASCII] error code from the > > >> > > >>> following: > > >> > > >> 2325a2326,2327 > > >> > > >>> Values for the "error" parameter MUST NOT include > > >>> characters > > >> > > >>> outside the set %x20-21 / %x23-5B / %x5D-7E. > > >> > > >> 2327c2329 > > >> > > >> < OPTIONAL. A human-readable UTF-8 encoded text providing > > >> > > >> --- > > >> > > >>> OPTIONAL. A human-readable ASCII [USASCII] text providing > > >> > > >> 2329a2332,2333 > > >> > > >>> Values for the "error_description" parameter MUST NOT > > >>> include > > >> > > >>> characters outside the set %x20-21 / %x23-5B / %x5D-7E. > > >> > > >> 2333a2338,2340 > > >> > > >>> Values for the "error_uri" parameter MUST conform to the > > >>> URI- > > >> > > >>> Reference syntax, and thus MUST NOT include characters > > >>> outside > > >> > > >>> the set %x21 / %x23-5B / %x5D-7E. > > >> > > >> 2450c2460,2468 > > >> > > >> < The method in which the client utilized the access token to > > >> > > >> --- > > >> > > >>> The method in which the client utilizes the access token to > > >> > > >> 2479c2489 > > >> > > >> < Authorization: Bearer 7Fjfp0ZBr1KtDRbnfVdmIw > > >> > > >> --- > > >> > > >>> Authorization: Bearer mF_9.B5f-4.1JqM > > >> > > >> 2503a2514,2533 > > >> > > >>> > > >> > > >>> 7.2. Error Response > > >> > > >>> > > >> > > >>> If a resource access request fails, the resource server SHOULD > > >>> inform > > >> > > >>> the client of the error. While the specific error responses > > >>> possible > > >> > > >>> and methods for transmitting those errors when using any > > >>> particular > > >> > > >>> access token type are beyond the scope of this specification, > > >>> any > > >> > > >>> error codes defined for use with OAuth resource access methods > > >>> MUST > > >> > > >>> be registered (following the procedures in Section 11.4). > > >> > > >>> > > >> > > >>> > > >> > > >> 2602,2603c2624,2626 > > >> > > >> < (Section 4.2.2.1), or the token error response (Section 5.2), s= uch > > >> > > >> < error codes MAY be defined. > > >> > > >> --- > > >> > > >>> (Section 4.2.2.1), the token error response (Section 5.2), or > > >>> the > > >> > > >>> resource access error response (Section 7.2), such error codes > > >>> MAY be > > >> > > >>> defined. > > >> > > >> 3444c3484,3485 > > >> > > >> < (Section 4.2.2.1), or token error response (Section 5.2). > > >> > > >> --- > > >> > > >>> (Section 4.2.2.1), token error response (Section 5.2), or > > >>> resource > > >> > > >>> access error response (Section 7.2). > > >> > > >> 3596a3554,3557 > > >> > > >>> [USASCII] American National Standards Institute, "Coded > > >>> Character > > >> > > >>> Set -- 7-bit American Standard Code for Information > > >> > > >>> Interchange", ANSI X3.4, 1986. > > >> > > >>> > > >> > > >> 3611,3612c3572,3573 > > >> > > >> < OAuth 2.0", draft-ietf-oauth-saml2-bearer-08 (work i= n > > >> > > >> < progress), August 2011. > > >> > > >> --- > > >> > > >>> OAuth 2.0", draft-ietf-oauth-saml2-bearer-12 (work in > > >> > > >>> progress), May 2012. > > >> > > >> 3616,3617c3577,3579 > > >> > > >> < Protocol: Bearer Tokens", draft-ietf-oauth-v2-bearer= -08 > > >> > > >> < (work in progress), July 2011. > > >> > > >> --- > > >> > > >>> Authorization Protocol: Bearer Tokens", > > >> > > >>> draft-ietf-oauth-v2-bearer-19 (work in progress), > > >> > > >>> April 2012. > > >> > > >> 3620,3623c3589,3591 > > >> > > >> < Hammer-Lahav, E., Barth, A., and B. Adida, "HTTP > > >> > > >> < Authentication: MAC Access Authentication", > > >> > > >> < draft-ietf-oauth-v2-http-mac-00 (work in progress), > > >> > > >> < May 2011. > > >> > > >> --- > > >> > > >>> Hammer-Lahav, E., "HTTP Authentication: MAC Access > > >> > > >>> Authentication", draft-ietf-oauth-v2-http-mac-01 > > >>> (work in > > >> > > >>> progress), February 2012. > > >> > > >> 3626c3594 > > >> > > >> < Lodderstedt, T., McGloin, M., and P. Hunt, "OAuth 2.= 0 > > >> > > >> --- > > >> > > >>> McGloin, M., Hunt, P., and T. Lodderstedt, "OAuth 2.0 > > >> > > >> 3628,3629c3596,3597 > > >> > > >> < draft-ietf-oauth-v2-threatmodel-00 (work in progress= ), > > >> > > >> < July 2011. > > >> > > >> --- > > >> > > >>> draft-ietf-oauth-v2-threatmodel-02 (work in > > >>> progress), > > >> > > >>> February 2012. > > >> > > >> 3468,3546d3503 > > >> > > >> < Brian Eaton, Yaron Goland, Dick Hardt, and Allen Tom. > > >> > > >> 3639c3609,3639 > > >> > > >>> Brian Eaton, Yaron Y. Goland, Dick Hardt, and Allen Tom. > > >> > > >> 3468,3546d3503 > > >> > > >> < Yaron Goland, Brent Goldman, Kristoffer Gronowski, Justin Hart, > > >> > > >> 3644,3645c3644,3656 > > >> > > >>> Yaron Y. Goland, Brent Goldman, Kristoffer Gronowski, Justin > > >>> Hart, > > >> > > >> 3468,3546d3503 > > >> > > >> < This document was produced under the chairmanship of Blaine > Cook, > > >> > > >> < Peter Saint-Andre, Hannes Tschofenig, and Barry Leiba. The are= a > > >> > > >> < directors included Lisa Dusseault, Peter Saint-Andre, and Steph= en > > >> > > >> < Farrell. > > >> > > >> 3646a3658,3661 > > >> > > >>> This document was produced under the chairmanship of Blaine > > >>> Cook, > > >> > > >>> Peter Saint-Andre, Hannes Tschofenig, Barry Leiba, and Derek Atki= ns. > > >> > > >>> The area directors included Lisa Dusseault, Peter Saint-Andre, > > >>> and > > >> > > >>> Stephen Farrell. > > >> > > >> > > >> > > >> -----Original Message----- > > >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > > Behalf Of Hannes Tschofenig > > >> Sent: Wednesday, May 23, 2012 11:27 AM > > >> To: oauth@ietf.org WG > > >> Subject: [OAUTH-WG] Error Encoding: Conclusion > > >> > > >> > > >> > > >> Hi all, > > >> > > >> > > >> > > >> on May 10th we called for consensus on an open issue regarding the > > >> error > > encoding. Here is the link to the call: > > >> > > >> http://www.ietf.org/mail-archive/web/oauth/current/msg08994.html > > >> > > >> > > >> > > >> Thank you all for the feedback. The conclusion of the consensus > > >> call was > > to harmonize the encoding between the two specifications by > > incorporating the restrictions from the bearer specification into the > > base specification. The error encoding will go into the core > > specification and the bearer specification will reference it. > > >> > > >> > > >> > > >> Ciao > > >> > > >> Hannes & Derek > > >> > > >> > > >> > > >> _______________________________________________ > > >> > > >> OAuth mailing list > > >> > > >> OAuth@ietf.org > > >> > > >> https://www.ietf.org/mailman/listinfo/oauth > > >> > > >> > > >> > > >> > > >> _______________________________________________ > > >> OAuth mailing list > > >> OAuth@ietf.org > > >> https://www.ietf.org/mailman/listinfo/oauth > > >> > > >> > > >> > 2.txt> > > > >=20 From eran@hueniverse.com Fri Jun 8 18:58:14 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8029511E80F8 for ; Fri, 8 Jun 2012 18:58:14 -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, 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 bgbQH9jvkKaW for ; Fri, 8 Jun 2012 18:58:13 -0700 (PDT) Received: from p3plex2out01.prod.phx3.secureserver.net (p3plex2out01.prod.phx3.secureserver.net [184.168.131.12]) by ietfa.amsl.com (Postfix) with ESMTP id A5D4311E8095 for ; Fri, 8 Jun 2012 18:58:13 -0700 (PDT) Received: from P3PWEX2HT002.ex2.secureserver.net ([184.168.131.10]) by p3plex2out01.prod.phx3.secureserver.net with bizsmtp id L1yD1j0040Dcg9U011yDv4; Fri, 08 Jun 2012 18:58:13 -0700 Received: from P3PWEX2MB008.ex2.secureserver.net ([169.254.8.66]) by P3PWEX2HT002.ex2.secureserver.net ([184.168.131.10]) with mapi id 14.02.0247.003; Fri, 8 Jun 2012 18:58:13 -0700 From: Eran Hammer To: "oauth@ietf.org WG (oauth@ietf.org)" Thread-Topic: New draft process / editor role Thread-Index: Ac1F4i3w3TwHlNAyTkqDNHNxoOvuzA== Date: Sat, 9 Jun 2012 01:58:12 +0000 Message-ID: <0CBAEB56DDB3A140BA8E8C124C04ECA201068743@P3PWEX2MB008.ex2.secureserver.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [68.36.195.242] Content-Type: multipart/alternative; boundary="_000_0CBAEB56DDB3A140BA8E8C124C04ECA201068743P3PWEX2MB008ex2_" MIME-Version: 1.0 Subject: [OAUTH-WG] New draft process / editor role X-BeenThere: oauth@ietf.org X-Mailman-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, 09 Jun 2012 01:58:14 -0000 --_000_0CBAEB56DDB3A140BA8E8C124C04ECA201068743P3PWEX2MB008ex2_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Today, a new draft of the OAuth 2.0 specification was published. * I had nothing to do with this draft. I did not edit or authored it. I did= n't know it was being published. * The draft was authored by Mike Jones and published by Dick Hardt. * Neither one is an editor or an active author of the document. Here are the facts: * On 5/31 Hannes asked me to publish a new draft with the proposed changes = posted by Mike by Sunday 6/3 (within 3 days). The chairs did not offer any = reason for requesting such a quick turnaround. It took the chairs weeks to = respond to me about the request for ABNF or error text. There wasn't any ur= gency when it was their task. * I promptly replied that I plan to wait until the ABNF is completed before= publishing a new draft. The ABNF, which is the only pending DISCUSS for th= e core specification, is still being actively debated on the list and was c= learly presented as work in progress. * Hannes did not reply back with any other instructions. * Mike replied back trying to speak on behalf of the chairs, suggesting tha= t 'version numbers are cheap'. I replied that my time isn't. * At no point did any of the chairs indicated any issue with my publication= schedule. The full thread is here: http://www.ietf.org/mail-archive/web/oa= uth/current/msg09111.html. * Today, using Dick Hardt author credit on the document, Mike published his= draft. There is no indication that changes were made by someone other than= the editor or that the added sections are still a work in progress and pen= ding consensus as is WG practice (e.g. [[ Pending Consensus ]] or [[ Propos= ed Text]]). * No one has offered any explanation as to why the editor was pushed aside = and blindsided with a new draft. There was no communication or any attempt = to from the chairs, Mike, Dick, or anyone else. * After posting the new draft, Mike emailed the IESG to resolve a pending D= ISCUSS item on the core specification, something that is clearly my role an= d handled by me so far. I was not included in the email list but received a= copy through the tracker system as author. Publishing a new draft must be done by a listed author. The only reason Dic= k and David are listed is historical in regognition of their initial contri= bution. Both David and Dick offered to remove their name from the top credi= ts in the past (the reason Dick gave at the time was that the document was = clearly my work). Using the author credit as a way to sidestep the editor i= s within the chairs right but that doesn't make it right. I have done absolutely nothing to justify taking the document editorial wor= k from me, even temporarily. I have tirelessly published 26 drafts of this = documenty. I have been working on this specification for almost 5 years. Wh= ile the chairs can certainly decide who gets to edit and publish new drafts= , there was no reason to do this here, and typically this is done when an e= ditor is unresponsive and has to be removed. In this case, it was the chair= s who were unresponsive and uncommunicative. They didn't think to even giv= e me the courtesy of a head up. It is not clear to me what my standing is at this point with regard to this= document. I will wait for further information from the AD to decide how to= proceed. EH --_000_0CBAEB56DDB3A140BA8E8C124C04ECA201068743P3PWEX2MB008ex2_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Today, a new draft of the OAuth 2.0 specification wa= s published.

 

* I had nothing to do with this draft. I did not edi= t or authored it. I didn't know it was being published.

* The draft was authored by Mike Jones and published= by Dick Hardt.

* Neither one is an editor or an active author of th= e document.

 

Here are the facts:

 

* On 5/31 Hannes asked me to publish a new draft wit= h the proposed changes posted by Mike by Sunday 6/3 (within 3 days). The ch= airs did not offer any reason for requesting such a quick turnaround. It to= ok the chairs weeks to respond to me about the request for ABNF or error text. There wasn't any urgency when= it was their task.

* I promptly replied that I plan to wait until the A= BNF is completed before publishing a new draft. The ABNF, which is the only= pending DISCUSS for the core specification, is still being actively debate= d on the list and was clearly presented as work in progress.

* Hannes did not reply back with any other instructi= ons.

* Mike replied back trying to speak on behalf of the= chairs, suggesting that 'version numbers are cheap'. I replied that my tim= e isn't.

* At no point did any of the chairs indicated any is= sue with my publication schedule. The full thread is here: http://www.ietf.org/mail-archive/web/oauth/current/msg09111.html.

* Today, using Dick Hardt author credit on the docum= ent, Mike published his draft. There is no indication that changes were mad= e by someone other than the editor or that the added sections are still a w= ork in progress and pending consensus as is WG practice (e.g. [[ Pending Consensus ]] or [[ Proposed Text]]).

* No one has offered any explanation as to why the e= ditor was pushed aside and blindsided with a new draft. There was no commun= ication or any attempt to from the chairs, Mike, Dick, or anyone else.=

* After posting the new draft, Mike emailed the IESG= to resolve a pending DISCUSS item on the core specification, something tha= t is clearly my role and handled by me so far. I was not included in the em= ail list but received a copy through the tracker system as author.

 

Publishing a new draft must be done by a listed auth= or. The only reason Dick and David are listed is historical in regognition = of their initial contribution. Both David and Dick offered to remove their = name from the top credits in the past (the reason Dick gave at the time was that the document was clearly my wor= k). Using the author credit as a way to sidestep the editor is within the c= hairs right but that doesn't make it right.

 

I have done absolutely nothing to justify taking the= document editorial work from me, even temporarily. I have tirelessly publi= shed 26 drafts of this documenty. I have been working on this specification= for almost 5 years. While the chairs can certainly decide who gets to edit and publish new drafts, there was no= reason to do this here, and typically this is done when an editor is unres= ponsive and has to be removed. In this case, it was the chairs who were unr= esponsive  and uncommunicative. They didn't think to even give me the courtesy of a head up.

 

It is not clear to me what my standing is at this po= int with regard to this document. I will wait for further information from = the AD to decide how to proceed.

 

EH

 

--_000_0CBAEB56DDB3A140BA8E8C124C04ECA201068743P3PWEX2MB008ex2_-- From ve7jtb@ve7jtb.com Fri Jun 8 19:04:22 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D706311E8099 for ; Fri, 8 Jun 2012 19:04:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.901 X-Spam-Level: X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[AWL=-0.699, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yGgNNe9SeAIN for ; Fri, 8 Jun 2012 19:04:22 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7D66B11E8095 for ; Fri, 8 Jun 2012 19:03:55 -0700 (PDT) Received: by yhq56 with SMTP id 56so2028117yhq.31 for ; Fri, 08 Jun 2012 19:03:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=hgNcYZTTRclvy66ahvMcTRMvad6rH63I6nrusH7rHew=; b=b6KyFga8B8fOtmGczLWdSsHrkp+vvYDPN42gK/cs/XbCEkIpjo3s/atXQeYNMxmLFi OlSBe69/MvGSezUlwFG2KpaOcckSG3N3X2Qe9yjE6x1rwIepdPTlAOCFjlJ8rDmxS4k9 eH7J0Da9DpZBy3FdvXvY+7zLJMRJXnvm9gNP9uag1h6U0S0dyJIvsyYa1mo5yvzn/+V+ pbid6JlzjeTGHjTHDOT0TjYbseUdigngzZFVxtBH3Yqhp7+g7lkN/6L4p5jt1o3lJT3x bsTVyY3M6lMPmg2AwcTG8lUm98k4assWGC9qF8NPZY3AjvayvgLhBVGqmf6KHrJl7wjd hwxg== Received: by 10.236.73.6 with SMTP id u6mr10478205yhd.31.1339207435076; Fri, 08 Jun 2012 19:03:55 -0700 (PDT) Received: from [192.168.1.213] (190-20-22-159.baf.movistar.cl. [190.20.22.159]) by mx.google.com with ESMTPS id l13sm12603928ann.2.2012.06.08.19.03.52 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 08 Jun 2012 19:03:54 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_1C8294F9-C126-4567-902B-AFEC0C8C3619"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <59E470B10C4630419ED717AC79FCF9A90AED9537@BL2PRD0410MB363.namprd04.prod.outlook.com> Date: Fri, 8 Jun 2012 22:03:45 -0400 Message-Id: <0C36899C-5011-483D-89FA-E5ACF74C4119@ve7jtb.com> References: <59E470B10C4630419ED717AC79FCF9A90AED9537@BL2PRD0410MB363.namprd04.prod.outlook.com> To: Lewis Adam-CAL022 X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQkwLl4L1xmGssBK4Qxtna2fIzUsiG6t3kl5QGB0e9/ExPhVLcPpt6sAlP/3FArUyjrAUMgm Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Authorization Request via back channel / direct communication? X-BeenThere: oauth@ietf.org X-Mailman-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, 09 Jun 2012 02:04:22 -0000 --Apple-Mail=_1C8294F9-C126-4567-902B-AFEC0C8C3619 Content-Type: multipart/alternative; boundary="Apple-Mail=_9A783A92-B120-4E2A-8E37-831B685A8DA8" --Apple-Mail=_9A783A92-B120-4E2A-8E37-831B685A8DA8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 To some extent it goes to the question of who do you trust. Most of OAuth is predicated on not sharing the users credential with the = client, because clients are not trusted. Your situation may be different if you control the device. If you are using multi factor authentication then using an embedded web = view is probably your best option to allow for flexibility as = authentication mechanisms change for users rather than coding them into = the app directly. Using a embedded web view with a OTP is probably not a bad thing though = in general we want to train users not to put there credentials into = untrusted applications and sites. John B. On 2012-06-08, at 6:43 PM, Lewis Adam-CAL022 wrote: > Hi, > =20 > I have a historical question around front channel / back channel = (direct) communications and Authorization Requests. Both the code-flow = and implicit-flow utilize a front channel communication through the UA. = This makes sense for the delegated credentials case (e.g. shutterfly = accessing photos on facebook).=20 > =20 > I=92m in the native app / client market, and the RO password = credentials flow fits really well =85 expect it=92s limited to = passwords. I=92ve been well educated (by lots of folks on this list) = about the =93best practices=94 to enable native clients to use the code = flow, e.g. registering a custom callback URI and register my native app = ass the handler for that URI.=20 > =20 > But =85 (and not knowing the history behind all this), it seems that = OAuth was designed for confidential clients, and was =93retro-fitted=94 = to make native apps work. And it just feels a bit like a hack to me = (albeit a workable one), the whole custom callback URI thing, to get it = to work. The RO password credentials seems like a much better fit for = native apps, since it has no need for the UA and can use back channel / = direction communication to talk to the AS and obtain and access token. = But that limits me to a password and eliminates any chance of strong = authentication. > =20 > It would seem more straight forward to define a back channel flow such = that a native client could send off an authorization request with = response=3Dtoken (or id_token in the Connect case), respond to a = challenge from the AS for authentication, and obtain a response = containing the access_token / id_token and use it for its RESTful API = communications with the RS/RP. This would enable strong authentication = methods not possible using just RO passwords. > =20 > Has anybody else ever expressed interest in such back channel calls = between for native clients? Was it previously considered and dropped?=20= > =20 > Tx! > adam > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_9A783A92-B120-4E2A-8E37-831B685A8DA8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 To some extent it goes to the question of who do = you trust.

Most of OAuth is predicated on not sharing = the users credential with the client, because clients are not = trusted.

Your situation may be different if you = control the device.

If you are using multi = factor authentication then using an embedded web view is probably your = best option to allow for flexibility as authentication mechanisms change = for users rather than coding them into the app = directly.

Using a embedded web view with a OTP = is probably not a bad thing though in general we want to train users not = to put there credentials into untrusted applications and = sites.

John B.

On = 2012-06-08, at 6:43 PM, Lewis Adam-CAL022 wrote:

Hi,
 
I have a historical question around front channel / back channel = (direct) communications and Authorization Requests.  Both the = code-flow and implicit-flow utilize a front channel communication = through the UA.  This makes sense for the delegated credentials = case (e.g. shutterfly accessing photos on = facebook). 
 
I=92m in the native app / client market, and the RO password = credentials flow fits really well =85 expect it=92s limited to = passwords.  I=92ve been well educated (by lots of folks on this = list) about the =93best practices=94 to enable native clients to use the = code flow, e.g. registering a custom callback URI and register my native = app ass the handler for that URI. 
But =85 (and not knowing the history behind all this), it seems = that OAuth was designed for confidential clients, and was =93retro-fitted=94= to make native apps work.  And it just feels a bit like a hack to = me (albeit a workable one), the whole custom callback URI thing, to get = it to work.  The RO password credentials seems like a much better = fit for native apps, since it has no need for the UA and can use back = channel / direction communication to talk to the AS and obtain and = access token.  But that limits me to a password and eliminates any = chance of strong authentication.
It would seem more straight forward to define a back channel = flow such that a native client could send off an authorization request = with response=3Dtoken (or id_token in the Connect case), respond to a = challenge from the AS for authentication, and obtain a response = containing the access_token / id_token and use it for its RESTful API = communications with the RS/RP.  This would enable strong = authentication methods not possible using just RO = passwords.
 
Has anybody else ever expressed interest in such back channel = calls between for native clients?  Was it previously considered and = dropped? 
 
OAuth@ietf.org
Thread-Topic: [OAUTH-WG] New draft process / editor role Thread-Index: AQHNReYZTTpfMlFOTk2nnIVvnA8vDw== Date: Sat, 9 Jun 2012 02:18:03 +0000 Message-ID: References: <0CBAEB56DDB3A140BA8E8C124C04ECA201068743@P3PWEX2MB008.ex2.secureserver.net> In-Reply-To: <0CBAEB56DDB3A140BA8E8C124C04ECA201068743@P3PWEX2MB008.ex2.secureserver.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [166.147.66.24] Content-Type: multipart/alternative; boundary="_000_B26C1EF377CB694EAB6BDDC8E624B6E74606D42CBL2PRD0310MB362_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: BL2PRD0310HT003.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%HUENIVERSE.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14MLTC104.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14MLTC104.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com Subject: Re: [OAUTH-WG] New draft process / editor role X-BeenThere: oauth@ietf.org X-Mailman-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, 09 Jun 2012 02:18:16 -0000 --_000_B26C1EF377CB694EAB6BDDC8E624B6E74606D42CBL2PRD0310MB362_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Why rant here, talk to the chairs or AD Sent from my Windows Phone ________________________________ From: Eran Hammer Sent: 6/8/2012 6:58 PM To: oauth@ietf.org WG (oauth@ietf.org) Subject: [OAUTH-WG] New draft process / editor role Today, a new draft of the OAuth 2.0 specification was published. * I had nothing to do with this draft. I did not edit or authored it. I did= n't know it was being published. * The draft was authored by Mike Jones and published by Dick Hardt. * Neither one is an editor or an active author of the document. Here are the facts: * On 5/31 Hannes asked me to publish a new draft with the proposed changes = posted by Mike by Sunday 6/3 (within 3 days). The chairs did not offer any = reason for requesting such a quick turnaround. It took the chairs weeks to = respond to me about the request for ABNF or error text. There wasn't any ur= gency when it was their task. * I promptly replied that I plan to wait until the ABNF is completed before= publishing a new draft. The ABNF, which is the only pending DISCUSS for th= e core specification, is still being actively debated on the list and was c= learly presented as work in progress. * Hannes did not reply back with any other instructions. * Mike replied back trying to speak on behalf of the chairs, suggesting tha= t 'version numbers are cheap'. I replied that my time isn't. * At no point did any of the chairs indicated any issue with my publication= schedule. The full thread is here: http://www.ietf.org/mail-archive/web/oa= uth/current/msg09111.html. * Today, using Dick Hardt author credit on the document, Mike published his= draft. There is no indication that changes were made by someone other than= the editor or that the added sections are still a work in progress and pen= ding consensus as is WG practice (e.g. [[ Pending Consensus ]] or [[ Propos= ed Text]]). * No one has offered any explanation as to why the editor was pushed aside = and blindsided with a new draft. There was no communication or any attempt = to from the chairs, Mike, Dick, or anyone else. * After posting the new draft, Mike emailed the IESG to resolve a pending D= ISCUSS item on the core specification, something that is clearly my role an= d handled by me so far. I was not included in the email list but received a= copy through the tracker system as author. Publishing a new draft must be done by a listed author. The only reason Dic= k and David are listed is historical in regognition of their initial contri= bution. Both David and Dick offered to remove their name from the top credi= ts in the past (the reason Dick gave at the time was that the document was = clearly my work). Using the author credit as a way to sidestep the editor i= s within the chairs right but that doesn't make it right. I have done absolutely nothing to justify taking the document editorial wor= k from me, even temporarily. I have tirelessly published 26 drafts of this = documenty. I have been working on this specification for almost 5 years. Wh= ile the chairs can certainly decide who gets to edit and publish new drafts= , there was no reason to do this here, and typically this is done when an e= ditor is unresponsive and has to be removed. In this case, it was the chair= s who were unresponsive and uncommunicative. They didn't think to even giv= e me the courtesy of a head up. It is not clear to me what my standing is at this point with regard to this= document. I will wait for further information from the AD to decide how to= proceed. EH --_000_B26C1EF377CB694EAB6BDDC8E624B6E74606D42CBL2PRD0310MB362_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Why rant here= , talk to the chairs or AD

Sent from my Windows Phone
From: Eran H= ammer
Sent: 6/8/20= 12 6:58 PM
To: oauth@= ietf.org WG (oauth@ietf.org)
Subject: [OAUTH= -WG] New draft process / editor role

Today, a new draft of the OAuth 2.0 specification wa= s published.

 

* I had nothing to do with this draft. I did not edi= t or authored it. I didn't know it was being published.

* The draft was authored by Mike Jones and published= by Dick Hardt.

* Neither one is an editor or an active author of th= e document.

 

Here are the facts:

 

* On 5/31 Hannes asked me to publish a new draft wit= h the proposed changes posted by Mike by Sunday 6/3 (within 3 days). The ch= airs did not offer any reason for requesting such a quick turnaround. It to= ok the chairs weeks to respond to me about the request for ABNF or error text. There wasn't any urgency when= it was their task.

* I promptly replied that I plan to wait until the A= BNF is completed before publishing a new draft. The ABNF, which is the only= pending DISCUSS for the core specification, is still being actively debate= d on the list and was clearly presented as work in progress.

* Hannes did not reply back with any other instructi= ons.

* Mike replied back trying to speak on behalf of the= chairs, suggesting that 'version numbers are cheap'. I replied that my tim= e isn't.

* At no point did any of the chairs indicated any is= sue with my publication schedule. The full thread is here: http://www.ietf.org/mail-archive/web/oauth/current/msg09111.html.

* Today, using Dick Hardt author credit on the docum= ent, Mike published his draft. There is no indication that changes were mad= e by someone other than the editor or that the added sections are still a w= ork in progress and pending consensus as is WG practice (e.g. [[ Pending Consensus ]] or [[ Proposed Text]]).

* No one has offered any explanation as to why the e= ditor was pushed aside and blindsided with a new draft. There was no commun= ication or any attempt to from the chairs, Mike, Dick, or anyone else.

* After posting the new draft, Mike emailed the IESG= to resolve a pending DISCUSS item on the core specification, something tha= t is clearly my role and handled by me so far. I was not included in the em= ail list but received a copy through the tracker system as author.

 

Publishing a new draft must be done by a listed auth= or. The only reason Dick and David are listed is historical in regognition = of their initial contribution. Both David and Dick offered to remove their = name from the top credits in the past (the reason Dick gave at the time was that the document was clearly my wor= k). Using the author credit as a way to sidestep the editor is within the c= hairs right but that doesn't make it right.

 

I have done absolutely nothing to justify taking the= document editorial work from me, even temporarily. I have tirelessly publi= shed 26 drafts of this documenty. I have been working on this specification= for almost 5 years. While the chairs can certainly decide who gets to edit and publish new drafts, there was no= reason to do this here, and typically this is done when an editor is unres= ponsive and has to be removed. In this case, it was the chairs who were unr= esponsive  and uncommunicative. They didn't think to even give me the courtesy of a head up.

 

It is not clear to me what my standing is at this po= int with regard to this document. I will wait for further information from = the AD to decide how to proceed.

 

EH

 

--_000_B26C1EF377CB694EAB6BDDC8E624B6E74606D42CBL2PRD0310MB362_-- From wmills@yahoo-inc.com Fri Jun 8 19:35:56 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77DD411E80BC for ; Fri, 8 Jun 2012 19:35:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.196 X-Spam-Level: X-Spam-Status: No, score=-17.196 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4neehudpCWcu for ; Fri, 8 Jun 2012 19:35:55 -0700 (PDT) Received: from nm9.bullet.mail.sp2.yahoo.com (nm9.bullet.mail.sp2.yahoo.com [98.139.91.79]) by ietfa.amsl.com (Postfix) with SMTP id 1D7C211E80BA for ; Fri, 8 Jun 2012 19:35:55 -0700 (PDT) Received: from [72.30.22.92] by nm9.bullet.mail.sp2.yahoo.com with NNFMP; 09 Jun 2012 02:35:51 -0000 Received: from [98.139.91.13] by tm14.bullet.mail.sp2.yahoo.com with NNFMP; 09 Jun 2012 02:35:51 -0000 Received: from [127.0.0.1] by omp1013.mail.sp2.yahoo.com with NNFMP; 09 Jun 2012 02:35:51 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 757749.91045.bm@omp1013.mail.sp2.yahoo.com Received: (qmail 71000 invoked by uid 60001); 9 Jun 2012 02:35:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1339209351; bh=5D/BkqGzcL2XXePwric5ZKwq9UWQUKmVDS7UuuXzc1g=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=jbZHEQS5vyoKFQ4zb1FGEx7+ys4ttmCx/kj/aXd4vXFLKZ5axWzynVo0yQEaJIN8T1esLBR1+EVkXgjbEuYstNH1XjPKzRM+AjwWKSm0oxDiEXkrhtEh8pzmuULMkjwOQgFbcKHvOhP3hY71yKGwsj/hRdWu76JNZRDCd6sbX7c= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=CylusYGffRmLuviKT2UVkev6mCdAFCS3aemPiklB6oBijhBkoTJYEU6t4Ljyn7i9NjYsqZFcQV1kb3u1ve3PBbHMpBQKj+CjEtKcV+s5PFVgc+kAM0YWOd2r/UUBXjmn2XwTyJsQOoCTSEhGQ+M5fRqRpL9nDlT5J3ECXcUBl9g=; X-YMail-OSG: nii_aysVM1nbcPTwS221ziuhPIjqr.nWvl9U5LLzHRke_K_ VqgAulYvUFxy4xOlgPsDWBru3bdKlPh8se93YIMXGv0jig_dLm1XUwV8RMsL UOsUd_B5qRrB4LeNjjPl2X2n5Ro9iGGc16Qoefe6BA2MWpHUOWmQ8cNgafuf ccJBows9UtIBNhDpk7q8d_QHZ6KhFzkuVpXM7_LtDNyDHeQ7eGo_dsQeQgoU 6aehJCR4pcq4n_asCoXLRLipFMdf1ZY7H5Q7kkDodlsM15iLRa_.uMGuBZlF DPhAkfXGe55f_od0KMAdz2bFEgz1DMVqwAHx2_z76d8KuyazB2QluwvQmAsJ pzPS2t.HwX3q.NYzOy4JoSHkDnvHuQHPRNjF.qUACCfe92OIcUIl8pQd6q4S 4tggg04faJYUxIPZ.oSDQ39xqAEmtbNlQkVKeWaP3OkFXhwpmgg-- Received: from [209.131.62.115] by web31816.mail.mud.yahoo.com via HTTP; Fri, 08 Jun 2012 19:35:50 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.118.349524 References: <0CBAEB56DDB3A140BA8E8C124C04ECA201068743@P3PWEX2MB008.ex2.secureserver.net> Message-ID: <1339209350.70970.YahooMailNeo@web31816.mail.mud.yahoo.com> Date: Fri, 8 Jun 2012 19:35:50 -0700 (PDT) From: William Mills To: Anthony Nadalin , Eran Hammer , "oauth@ietf.org WG \(oauth@ietf.org\)" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1238014912-485408465-1339209350=:70970" Subject: Re: [OAUTH-WG] New draft process / editor role X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jun 2012 02:35:56 -0000 ---1238014912-485408465-1339209350=:70970 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable +1=0A=0A=0A=0A=0A>________________________________=0A> From: Anthony Nadali= n =0A>To: Eran Hammer ; "oauth@= ietf.org WG (oauth@ietf.org)" =0A>Sent: Friday, June 8, 20= 12 7:18 PM=0A>Subject: Re: [OAUTH-WG] New draft process / editor role=0A> = =0A>=0A> =0A>Why rant here, talk to the chairs or AD=0A>=0A>Sent from my Wi= ndows Phone=0A>=0A>________________________________=0A> From: Eran Hammer= =0A>Sent: 6/8/2012 6:58 PM=0A>To: oauth@ietf.org WG (oauth@ietf.org)=0A>Sub= ject: [OAUTH-WG] New draft process / editor role=0A>=0A>=0A>Today, a new dr= aft of the OAuth 2.0 specification was published.=0A>=A0=0A>* I had nothing= to do with this draft. I did not edit or authored it. I didn't know it was= being published.=0A>* The draft was authored by Mike Jones and published b= y Dick Hardt.=0A>* Neither one is an editor or an active author of the docu= ment.=0A>=A0=0A>Here are the facts:=0A>=A0=0A>* On 5/31 Hannes asked me to = publish a new draft with the proposed changes posted by Mike by Sunday 6/3 = (within 3 days). The chairs did not offer any reason for requesting such a = quick turnaround. It took the chairs weeks to respond to me about the reque= st for ABNF or error text. There wasn't any urgency when it was their task.= =0A>* I promptly replied that I plan to wait until the ABNF is completed be= fore publishing a new draft. The ABNF, which is the only pending DISCUSS fo= r the core specification, is still being actively debated on the list and w= as clearly presented as work in progress.=0A>* Hannes did not reply back wi= th any other instructions.=0A>* Mike replied back trying to speak on behalf= of the chairs, suggesting that 'version numbers are cheap'. I replied that= my time isn't.=0A>* At no point did any of the chairs indicated any issue = with my publication schedule. The full thread is here:=0Ahttp://www.ietf.or= g/mail-archive/web/oauth/current/msg09111.html.=0A>* Today, using Dick Hard= t author credit on the document, Mike published his draft. There is no indi= cation that changes were made by someone other than the editor or that the = added sections are still a work in progress and pending consensus as is WG = practice (e.g. [[ Pending Consensus ]] or [[ Proposed Text]]).=0A>* No one = has offered any explanation as to why the editor was pushed aside and blind= sided with a new draft. There was no communication or any attempt to from t= he chairs, Mike, Dick, or anyone else.=0A>* After posting the new draft, Mi= ke emailed the IESG to resolve a pending DISCUSS item on the core specifica= tion, something that is clearly my role and handled by me so far. I was not= included in the email list but received a copy through the tracker system = as author.=0A>=A0=0A>Publishing a new draft must be done by a listed author= . The only reason Dick and David are listed is historical in regognition of= their initial contribution. Both David and Dick offered to remove their na= me from the top credits in the past (the reason Dick gave at the time was t= hat the document was clearly my work). Using the author credit as a way to = sidestep the editor is within the chairs right but that doesn't make it rig= ht.=0A>=A0=0A>I have done absolutely nothing to justify taking the document= editorial work from me, even temporarily. I have tirelessly published 26 d= rafts of this documenty. I have been working on this specification for almo= st 5 years. While the chairs can certainly decide who gets to edit and publ= ish new drafts, there was no reason to do this here, and typically this is = done when an editor is unresponsive and has to be removed. In this case, it= was the chairs who were unresponsive =A0and uncommunicative. They didn't t= hink to even give me the courtesy of a head up.=0A>=A0=0A>It is not clear t= o me what my standing is at this point with regard to this document. I will= wait for further information from the AD to decide how to proceed.=0A>=A0= =0A>EH=0A>=A0=0A>_______________________________________________=0A>OAuth m= ailing list=0A>OAuth@ietf.org=0A>https://www.ietf.org/mailman/listinfo/oaut= h=0A>=0A>=0A> ---1238014912-485408465-1339209350=:70970 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
+1

From:<= /b> Anthony Nadalin <tonynad@microsoft.com>
To: Eran Hammer <eran@hueniverse.com>; "o= auth@ietf.org WG (oauth@ietf.org)" <oauth@ietf.org>
Sent: Friday, June 8, 2012 7:18 PM
= Subject: Re: [OAUTH-WG] N= ew draft process / editor role

=0A
=0A=0A =0A<= style>=0A=0A=0A=0A
=0A
=0A<= div style=3D"font-family:Calibri, sans-serif;font-size:11pt;">Why rant here= , talk to the chairs or AD
=0A
=0ASent from my Windows Phone
=0A=0A
=0A
=0AFrom:=0AEran Hammer
=0ASent:=0A6/8/2012 6:= 58 PM
=0ATo:=0Aoauth@ietf.org WG (oauth@ietf.org)
=0ASubject:=0A[OAUTH-WG] New draft process / editor role
=0A
=0A=0A
=0A
Today, a new draft of the OAuth 2.0 specification was published.<= /div>=0A
 
=0A
* I had nothing to do with this draft. I did not edit= or authored it. I didn't know it was being published.
=0A
* The draft was authored by Mike Jones and publi= shed by Dick Hardt.
=0A
* Neither = one is an editor or an active author of the document.
=0A
 
=0A
Here are the facts:
=0A
 =0A
* On 5/31 Hannes asked me to pub= lish a new draft with the proposed changes posted by Mike by Sunday 6/3 (wi= thin 3 days). The chairs did not offer any reason for requesting such a qui= ck turnaround. It took the chairs weeks to respond to=0A me about the reque= st for ABNF or error text. There wasn't any urgency when it was their task.=
=0A
* I promptly replied that I p= lan to wait until the ABNF is completed before publishing a new draft. The = ABNF, which is the only pending DISCUSS for the core specification, is stil= l being actively debated on the list and was clearly presented=0A as work i= n progress.
=0A
* Hannes did not r= eply back with any other instructions.
=0A
* Mike replied back trying to speak on behalf of the chairs, sugge= sting that 'version numbers are cheap'. I replied that my time isn't.
= =0A
* At no point did any of the chairs= indicated any issue with my publication schedule. The full thread is here:= =0Ahttp://www.ietf.org/mail-archive/web/oauth/current/msg09111.html.
= =0A
* Today, using Dick Hardt author cr= edit on the document, Mike published his draft. There is no indication that= changes were made by someone other than the editor or that the added secti= ons are still a work in progress and pending consensus=0A as is WG practice= (e.g. [[ Pending Consensus ]] or [[ Proposed Text]]).
=0A
* No one has offered any explanation as to why t= he editor was pushed aside and blindsided with a new draft. There was no co= mmunication or any attempt to from the chairs, Mike, Dick, or anyone else.<= /div>=0A
* After posting the new draft,= Mike emailed the IESG to resolve a pending DISCUSS item on the core specif= ication, something that is clearly my role and handled by me so far. I was = not included in the email list but received a copy through=0A the tracker s= ystem as author.
=0A
 
= =0A
Publishing a new draft must be done= by a listed author. The only reason Dick and David are listed is historica= l in regognition of their initial contribution. Both David and Dick offered= to remove their name from the top credits in the past=0A (the reason Dick = gave at the time was that the document was clearly my work). Using the auth= or credit as a way to sidestep the editor is within the chairs right but th= at doesn't make it right.
=0A
&nbs= p;
=0A
I have done absolutely noth= ing to justify taking the document editorial work from me, even temporarily= . I have tirelessly published 26 drafts of this documenty. I have been work= ing on this specification for almost 5 years. While the chairs=0A can certa= inly decide who gets to edit and publish new drafts, there was no reason to= do this here, and typically this is done when an editor is unresponsive an= d has to be removed. In this case, it was the chairs who were unresponsive =  and uncommunicative.=0A They didn't think to even give me the courtes= y of a head up.
=0A
 
= =0A
It is not clear to me what my stand= ing is at this point with regard to this document. I will wait for further = information from the AD to decide how to proceed.
=0A
 
=0A
EH<= /div>=0A
 
=0A
=0A
= =0A
=0A=0A

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


---1238014912-485408465-1339209350=:70970-- From peaceable_whale@hotmail.com Fri Jun 8 21:10:02 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F08711E80D7 for ; Fri, 8 Jun 2012 21:10:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 cnk54ijhLAe9 for ; Fri, 8 Jun 2012 21:10:02 -0700 (PDT) Received: from col0-omc2-s6.col0.hotmail.com (col0-omc2-s6.col0.hotmail.com [65.55.34.80]) by ietfa.amsl.com (Postfix) with ESMTP id 757D211E8097 for ; Fri, 8 Jun 2012 21:09:58 -0700 (PDT) Received: from COL122-DS24 ([65.55.34.72]) by col0-omc2-s6.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 8 Jun 2012 21:09:58 -0700 X-Originating-IP: [14.136.19.151] X-Originating-Email: [peaceable_whale@hotmail.com] Message-ID: From: "Franklin Tse" To: "William Mills" , "Anthony Nadalin" , "Eran Hammer" , References: <0CBAEB56DDB3A140BA8E8C124C04ECA201068743@P3PWEX2MB008.ex2.secureserver.net> <1339209350.70970.YahooMailNeo@web31816.mail.mud.yahoo.com> In-Reply-To: <1339209350.70970.YahooMailNeo@web31816.mail.mud.yahoo.com> Date: Sat, 9 Jun 2012 12:09:52 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3555.308 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3555.308 X-OriginalArrivalTime: 09 Jun 2012 04:09:58.0278 (UTC) FILETIME=[BBBF1A60:01CD45F5] Subject: Re: [OAUTH-WG] New draft process / editor role X-BeenThere: oauth@ietf.org X-Mailman-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, 09 Jun 2012 04:10:02 -0000 SSB0aGluayB0aGUgY2hhaXJzIHNob3VsZCBjbGFyaWZ5IGFuZCBleHBsYWluLCB2aWEgdGhpcyBt YWlsaW5nIGxpc3QsDQoNCjEuIFdoZXRoZXIgdGhleSBoYXZlIGF1dGhvcml6ZWQgTWlrZSBKb25l cyBhbmQgRGljayBIYXJkdCB0byBhdXRob3IgYW5kIHB1Ymxpc2ggdGhlIGRyYWZ0DQoyYS4gSWYg dGhleSBoYXZlIGdpdmVuIHRoZSBhdXRob3JpemF0aW9uLCB3aHkgdGhleSBuZWVkZWQgdG8gZG8g c28gYW5kIHdoeSB0aGUgZWRpdG9yIHdhcyBub3Qgbm90aWZpZWQ7ICANCjJiLiBPdGhlcndpc2Us IHdoZXRoZXIgdGhlIGN1cnJlbnQgZHJhZnQgc2hvdWxkIGJlIGNvbnNpZGVyZWQgaW52YWxpZC4N Cg0KVGhlIGN1cnJlbnQgc2l0dWF0aW9uIGlzIGNvbmZ1c2luZyBhbmQgSSBob3BlIHRoYXQgdGhl IGNoYWlycyB3aWxsIGdpdmUgdXMgdGhlIGFuc3dlcnMgYXMgc29vbiBhcyBwb3NzaWJsZS4= From recordond@gmail.com Fri Jun 8 23:20:23 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6B2021F8A00 for ; Fri, 8 Jun 2012 23:20:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.32 X-Spam-Level: X-Spam-Status: No, score=-3.32 tagged_above=-999 required=5 tests=[AWL=0.278, 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 ut7oKShLTinr for ; Fri, 8 Jun 2012 23:20:22 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 078B921F88B0 for ; Fri, 8 Jun 2012 23:20:14 -0700 (PDT) Received: by lagv3 with SMTP id v3so2420477lag.31 for ; Fri, 08 Jun 2012 23:20:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=u2I7WfGuhZ7b7WnjtKK/mlS2dWvNqPE7T538aaXx89c=; b=wCqi29OI0PwyLDwPTUJFGQ/cy5yuNAFhNQhlNYwsFXsAafAvxmkreaK9YS3xiiLsvc sWzCZJODXzTKV1QMlDaa9nyXNrFXZmzqmJrKdmYQW1AfdV0uElhd48RehON5tpyHvefZ J7eQrUNHvxkEEQIr7mQ5Cm3f5PdQ/32EzhCYTsqfRPEeUFJM/Xk1+tXYgf0YJGDvOlz1 KnGgIRFXdiVhxK7YI8xlRvn0ZBe77Ck+jOsBSZeFquLxr20igoBdFXvx2/9J3x9RxSvG ShctZ9pE3hW14aqJrJqkGKZuWjxDJYL/r/foEOZOiIquj26lj0sRxPlt42vp7Pbz1wRG xUOA== MIME-Version: 1.0 Received: by 10.112.82.42 with SMTP id f10mr383597lby.95.1339222813916; Fri, 08 Jun 2012 23:20:13 -0700 (PDT) Received: by 10.112.104.97 with HTTP; Fri, 8 Jun 2012 23:20:13 -0700 (PDT) In-Reply-To: References: <0CBAEB56DDB3A140BA8E8C124C04ECA201068743@P3PWEX2MB008.ex2.secureserver.net> <1339209350.70970.YahooMailNeo@web31816.mail.mud.yahoo.com> Date: Fri, 8 Jun 2012 23:20:13 -0700 Message-ID: From: David Recordon To: Franklin Tse Content-Type: multipart/alternative; boundary=f46d04016a97193f2704c2041c7b Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] New draft process / editor role X-BeenThere: oauth@ietf.org X-Mailman-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, 09 Jun 2012 06:20:24 -0000 --f46d04016a97193f2704c2041c7b Content-Type: text/plain; charset=ISO-8859-1 Yes, it would be helpful (and I think reasonable) to have an explanation of why the process was changed so wildly from the past twenty-six drafts. --David On Fri, Jun 8, 2012 at 9:09 PM, Franklin Tse wrote: > I think the chairs should clarify and explain, via this mailing list, > > 1. Whether they have authorized Mike Jones and Dick Hardt to author and > publish the draft > 2a. If they have given the authorization, why they needed to do so and why > the editor was not notified; > 2b. Otherwise, whether the current draft should be considered invalid. > > The current situation is confusing and I hope that the chairs will give us > the answers as soon as possible. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --f46d04016a97193f2704c2041c7b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yes, it would be helpful (and I think reasonable) to have an explanation of= why the process was changed so wildly from the past twenty-six drafts.
--David


On Fri= , Jun 8, 2012 at 9:09 PM, Franklin Tse <peaceable_whale@hotmail.= com> wrote:
I think the chairs should clarify and explai= n, via this mailing list,

1. Whether they have authorized Mike Jones and Dick Hardt to author and pub= lish the draft
2a. If they have given the authorization, why they needed to do so and why = the editor was not notified;
2b. Otherwise, whether the current draft should be considered invalid.

The current situation is confusing and I hope that the chairs will give us = the answers as soon as possible.
___________________________________= ____________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

--f46d04016a97193f2704c2041c7b-- From dick.hardt@gmail.com Sat Jun 9 01:56:14 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A1DE21F89E1 for ; Sat, 9 Jun 2012 01:56:14 -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 vP5QRI2ecxp4 for ; Sat, 9 Jun 2012 01:56:13 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 105A221F89DF for ; Sat, 9 Jun 2012 01:56:13 -0700 (PDT) Received: by dacx6 with SMTP id x6so3329948dac.31 for ; Sat, 09 Jun 2012 01:56:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=iYJqogG9d3NsUXJ5qFNdx3KTNuh/G1m8DIodeQE9aiE=; b=nXPaWk7mqAiCCo+JPNYG6eCLVx8h0/exN2BuK/R4cty7ttqQK8QFHHeYRskjVmiSRU sn847SwCD8f5021hyjfsE3AczLfg0dNlrHWhdbdr/SwFB98IbS7akumBH/Me2ig3zh41 uyYMHd36ilZMoG9H8PVvwoYym5Ajwq8cZMlxJ5coD8T9bsrv360v/1OugQjDpD8S9wbq lmZsTC2fod71o4WfC7xRE8i+4/Bwyg/Mem0hcebup5m+KBm9hif0Bt4qzCay4Jt/3ony J4S7zssZkCuujotcHNacHv6/GKW12iQ+oZdWlsVu4BMSSjs7/QmbHiT/lmxO9oIGX1NX YIhw== Received: by 10.68.191.106 with SMTP id gx10mr4276001pbc.37.1339232172750; Sat, 09 Jun 2012 01:56:12 -0700 (PDT) Received: from [10.0.0.91] (c-24-5-69-173.hsd1.ca.comcast.net. [24.5.69.173]) by mx.google.com with ESMTPS id tj4sm10783929pbc.33.2012.06.09.01.56.10 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 09 Jun 2012 01:56:11 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_C95A6E19-CA3E-4B1D-A10E-FAB9D9DA054A" From: Dick Hardt In-Reply-To: <0CBAEB56DDB3A140BA8E8C124C04ECA201068743@P3PWEX2MB008.ex2.secureserver.net> Date: Sat, 9 Jun 2012 01:56:11 -0700 Message-Id: <138877F6-BDF5-4EE1-9934-A40B7450EAF8@gmail.com> References: <0CBAEB56DDB3A140BA8E8C124C04ECA201068743@P3PWEX2MB008.ex2.secureserver.net> To: Eran Hammer X-Mailer: Apple Mail (2.1278) Cc: "oauth@ietf.org WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] New draft process / editor role X-BeenThere: oauth@ietf.org X-Mailman-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, 09 Jun 2012 08:56:14 -0000 --Apple-Mail=_C95A6E19-CA3E-4B1D-A10E-FAB9D9DA054A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Mike emailed me the draft and asked if I would publish it. I reviewed the draft and I thought it captured consensus. I noted that Hannes had asked Eran to publish the edits a week ago=20 There have been numerous indications that Eran has lost interest in = continuing as editor. Eg. his decision to discontinue his work on the = MAC spec. I viewed it as my duty as an author to maintain forward momentum of the = spec. Eran is still listed as the editor Can we move forward with the work at hand now? -- Dick On Jun 8, 2012, at 6:58 PM, Eran Hammer wrote: > Today, a new draft of the OAuth 2.0 specification was published. > =20 > * I had nothing to do with this draft. I did not edit or authored it. = I didn't know it was being published. > * The draft was authored by Mike Jones and published by Dick Hardt. > * Neither one is an editor or an active author of the document. > =20 > Here are the facts: > =20 > * On 5/31 Hannes asked me to publish a new draft with the proposed = changes posted by Mike by Sunday 6/3 (within 3 days). The chairs did not = offer any reason for requesting such a quick turnaround. It took the = chairs weeks to respond to me about the request for ABNF or error text. = There wasn't any urgency when it was their task. > * I promptly replied that I plan to wait until the ABNF is completed = before publishing a new draft. The ABNF, which is the only pending = DISCUSS for the core specification, is still being actively debated on = the list and was clearly presented as work in progress. > * Hannes did not reply back with any other instructions. > * Mike replied back trying to speak on behalf of the chairs, = suggesting that 'version numbers are cheap'. I replied that my time = isn't. > * At no point did any of the chairs indicated any issue with my = publication schedule. The full thread is here: = http://www.ietf.org/mail-archive/web/oauth/current/msg09111.html. > * Today, using Dick Hardt author credit on the document, Mike = published his draft. There is no indication that changes were made by = someone other than the editor or that the added sections are still a = work in progress and pending consensus as is WG practice (e.g. [[ = Pending Consensus ]] or [[ Proposed Text]]). > * No one has offered any explanation as to why the editor was pushed = aside and blindsided with a new draft. There was no communication or any = attempt to from the chairs, Mike, Dick, or anyone else. > * After posting the new draft, Mike emailed the IESG to resolve a = pending DISCUSS item on the core specification, something that is = clearly my role and handled by me so far. I was not included in the = email list but received a copy through the tracker system as author. > =20 > Publishing a new draft must be done by a listed author. The only = reason Dick and David are listed is historical in regognition of their = initial contribution. Both David and Dick offered to remove their name = from the top credits in the past (the reason Dick gave at the time was = that the document was clearly my work). Using the author credit as a way = to sidestep the editor is within the chairs right but that doesn't make = it right. > =20 > I have done absolutely nothing to justify taking the document = editorial work from me, even temporarily. I have tirelessly published 26 = drafts of this documenty. I have been working on this specification for = almost 5 years. While the chairs can certainly decide who gets to edit = and publish new drafts, there was no reason to do this here, and = typically this is done when an editor is unresponsive and has to be = removed. In this case, it was the chairs who were unresponsive and = uncommunicative. They didn't think to even give me the courtesy of a = head up. > =20 > It is not clear to me what my standing is at this point with regard to = this document. I will wait for further information from the AD to decide = how to proceed. > =20 > EH > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_C95A6E19-CA3E-4B1D-A10E-FAB9D9DA054A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Mike emailed me the draft and asked if I would = publish it.

I reviewed the draft and I thought it = captured consensus.

I noted that Hannes had = asked Eran to publish the edits a week = ago 

There have been numerous indications = that Eran has lost interest in continuing as editor. Eg. his decision to = discontinue his work on the MAC spec.

I viewed = it as my duty as an author to maintain forward momentum of the = spec.

Eran is still listed as the = editor

Can we move forward with the work at = hand now?

-- Dick

On = Jun 8, 2012, at 6:58 PM, Eran Hammer wrote:

Today, a new draft of the = OAuth 2.0 specification was published.
 
* I had nothing to do with = this draft. I did not edit or authored it. I didn't know it was being = published.
* The draft was authored by Mike = Jones and published by Dick Hardt.
* Neither one is an editor or an active author of the = document.
 
Here are the facts:
 
* On 5/31 Hannes asked me to = publish a new draft with the proposed changes posted by Mike by Sunday = 6/3 (within 3 days). The chairs did not offer any reason for requesting = such a quick turnaround. It took the chairs weeks to respond to me about = the request for ABNF or error text. There wasn't any urgency when it was = their task.
* I promptly replied that I plan to = wait until the ABNF is completed before publishing a new draft. The = ABNF, which is the only pending DISCUSS for the core specification, is = still being actively debated on the list and was clearly presented as = work in progress.
* Hannes did not reply back = with any other instructions.
* Mike replied back = trying to speak on behalf of the chairs, suggesting that 'version = numbers are cheap'. I replied that my time isn't.
Subject: Re: [OAUTH-WG] Authorization Request via back channel / direct communication? X-BeenThere: oauth@ietf.org X-Mailman-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, 09 Jun 2012 22:08:16 -0000 --_000_59E470B10C4630419ED717AC79FCF9A90AED96D7BL2PRD0410MB363_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi John, "Most of OAuth is predicated on not sharing the users credential with the c= lient, because clients are not trusted." This is exactly my point. I clearly understand the driving motivations for= why OAuth was designed the way that it was. I certainly would not want to= give website-A my password to access my data on website-B. But it seems that since OAuth was first envisioned, it has gained an incred= ible amount of momentum for use cases that it was not originally envisioned= for. As we all know, there is a dominant trend within the enterprise to m= ove away from WS-*/SOAP/WS-Trust toward RESTful APIs ... and if REST is goi= ng to replace SOAP and OAuth/Connect is the preferred means by which to sec= ure RESTful API calls, then it seems it would be useful to define some OAut= h flows that are optimized for enterprise use cases, where the client and R= S are under the same security domain. When we sell our products to custome= rs, we sell them the server and we sell them the client. It's all very tru= sted. Nobody thinks twice about entering the credentials into an Outlook c= lient to authenticate to an exchange server. WS-Trust was optimized for en= terprise scenarios and clients apps collected credentials and passed them = to the STS in exchange for a SAML assertion via a simple RST/RSTR. This is= analogous to the RO credentials flow which communicates the password in th= e request and gets the token in the response. But WS-Trust also defined ot= her types that could be passed in the RST other than password tokens. So I guess all I'm getting at is that if REST is to replace SOAP (in the en= terprise) and OAuth/Connect is to be the endgame, then borrowing some of th= e design patterns from WS-* would seem beneficial. Again, it's not that I = can't do the whole "register a handler for a browser URI thing" ... but for= enterprise use cases, it's a kludge. Just my 2 cents. It's free :) adam From: John Bradley [mailto:ve7jtb@ve7jtb.com] Sent: Friday, June 08, 2012 9:04 PM To: Lewis Adam-CAL022 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Authorization Request via back channel / direct com= munication? To some extent it goes to the question of who do you trust. Most of OAuth is predicated on not sharing the users credential with the cl= ient, because clients are not trusted. Your situation may be different if you control the device. If you are using multi factor authentication then using an embedded web vie= w is probably your best option to allow for flexibility as authentication m= echanisms change for users rather than coding them into the app directly. Using a embedded web view with a OTP is probably not a bad thing though in = general we want to train users not to put there credentials into untrusted = applications and sites. John B. On 2012-06-08, at 6:43 PM, Lewis Adam-CAL022 wrote: Hi, I have a historical question around front channel / back channel (direct) c= ommunications and Authorization Requests. Both the code-flow and implicit-= flow utilize a front channel communication through the UA. This makes sens= e for the delegated credentials case (e.g. shutterfly accessing photos on f= acebook). I'm in the native app / client market, and the RO password credentials flow= fits really well ... expect it's limited to passwords. I've been well edu= cated (by lots of folks on this list) about the "best practices" to enable = native clients to use the code flow, e.g. registering a custom callback URI= and register my native app ass the handler for that URI. But ... (and not knowing the history behind all this), it seems that OAuth = was designed for confidential clients, and was "retro-fitted" to make nativ= e apps work. And it just feels a bit like a hack to me (albeit a workable = one), the whole custom callback URI thing, to get it to work. The RO passw= ord credentials seems like a much better fit for native apps, since it has = no need for the UA and can use back channel / direction communication to ta= lk to the AS and obtain and access token. But that limits me to a password= and eliminates any chance of strong authentication. It would seem more straight forward to define a back channel flow such that= a native client could send off an authorization request with response=3Dto= ken (or id_token in the Connect case), respond to a challenge from the AS f= or authentication, and obtain a response containing the access_token / id_t= oken and use it for its RESTful API communications with the RS/RP. This wo= uld enable strong authentication methods not possible using just RO passwor= ds. Has anybody else ever expressed interest in such back channel calls between= for native clients? Was it previously considered and dropped? Tx! adam _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_59E470B10C4630419ED717AC79FCF9A90AED96D7BL2PRD0410MB363_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi John,

 

“Most of OAuth is predicated on not sharing= the users credential with the client, because clients are not trusted.R= 21;

 

This is exactly my point.  I clearly un= derstand the driving motivations for why OAuth was designed the way that it= was.  I certainly would not want to give website-A my password to access my data on website-B.

 

But it seems that since OAuth was first envi= sioned, it has gained an incredible amount of momentum for use cases that i= t was not originally envisioned for.  As we all know, there is a dominant trend within the enterprise to move away from WS-*/SOAP/WS-T= rust toward RESTful APIs … and if REST is going to replace SOAP and O= Auth/Connect is the preferred means by which to secure RESTful API calls, t= hen it seems it would be useful to define some OAuth flows that are optimized for enterprise use cases, where the cl= ient and RS are under the same security domain.  When we sell our prod= ucts to customers, we sell them the server and we sell them the client.&nbs= p; It’s all very trusted.  Nobody thinks twice about entering the credentials into an Outlook client to authenticate to a= n exchange server.  WS-Trust was optimized for enterprise scenarios &n= bsp;and clients apps collected credentials and passed them to the STS in ex= change for a SAML assertion via a simple RST/RSTR.  This is analogous to the RO credentials flow which communicates the passwo= rd in the request and gets the token in the response.  But WS-Trust al= so defined other types that could be passed in the RST other than password = tokens. 

 

So I guess all I’m getting at is that = if REST is to replace SOAP (in the enterprise) and OAuth/Connect is to be t= he endgame, then borrowing some of the design patterns from WS-* would seem beneficial.  Again, it’s not that I can’t do t= he whole “register a handler for a browser URI thing” … b= ut for enterprise use cases, it’s a kludge. 

 

Just my 2 cents.  It’s free J

adam

 

From: John Bra= dley [mailto:ve7jtb@ve7jtb.com]
Sent: Friday, June 08, 2012 9:04 PM
To: Lewis Adam-CAL022
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Authorization Request via back channel / dir= ect communication?

 

To some extent it goes to the question of who do you= trust.

 

Most of OAuth is predicated on not sharing the users= credential with the client, because clients are not trusted.

 

Your situation may be different if you control the d= evice.

 

If you are using multi factor authentication then us= ing an embedded web view is probably your best option to allow for flexibil= ity as authentication mechanisms change for users rather than coding them i= nto the app directly.

 

Using a embedded web view with a OTP is probably not= a bad thing though in general we want to train users not to put there cred= entials into untrusted applications and sites.

 

John B.

 

On 2012-06-08, at 6:43 PM, Lewis Adam-CAL022 wrote:<= o:p>



Hi,

 

I have a historical question around front channel / back= channel (direct) communications and Authorization Requests.  Both the= code-flow and implicit-flow utilize a front channel communication through the UA.  This makes sense for the delegated credentials case = (e.g. shutterfly accessing photos on facebook). 

 

I’m in the native app / client market, and the RO = password credentials flow fits really well … expect it’s limite= d to passwords.  I’ve been well educated (by lots of folks on th= is list) about the “best practices” to enable native clients to use the code = flow, e.g. registering a custom callback URI and register my native app ass= the handler for that URI. 

 

But … (and not knowing the history behind all this= ), it seems that OAuth was designed for confidential clients, and was ̶= 0;retro-fitted” to make native apps work.  And it just feels a b= it like a hack to me (albeit a workable one), the whole custom callback URI thing,= to get it to work.  The RO password credentials seems like a much bet= ter fit for native apps, since it has no need for the UA and can use back c= hannel / direction communication to talk to the AS and obtain and access token.  But that limits me to a passw= ord and eliminates any chance of strong authentication.

 

It would seem more straight forward to define a back cha= nnel flow such that a native client could send off an authorization request= with response=3Dtoken (or id_token in the Connect case), respond to a challenge from the AS for authentication, and obtain a respon= se containing the access_token / id_token and use it for its RESTful API co= mmunications with the RS/RP.  This would enable strong authentication = methods not possible using just RO passwords.

 

Has anybody else ever expressed interest in such back ch= annel calls between for native clients?  Was it previously considered = and dropped? 

 

Tx!
adam

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

 

--_000_59E470B10C4630419ED717AC79FCF9A90AED96D7BL2PRD0410MB363_-- From cmortimore@salesforce.com Sat Jun 9 20:19:24 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4349E21F8678 for ; Sat, 9 Jun 2012 20:19:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hn1agPjzRzXl for ; Sat, 9 Jun 2012 20:19:23 -0700 (PDT) Received: from exprod8og104.obsmtp.com (exprod8og104.obsmtp.com [64.18.3.88]) by ietfa.amsl.com (Postfix) with SMTP id 8C44A21F867F for ; Sat, 9 Jun 2012 20:19:22 -0700 (PDT) Received: from exsfm-hub4.internal.salesforce.com ([204.14.239.239]) by exprod8ob104.postini.com ([64.18.7.12]) with SMTP ID DSNKT9QSOdGjWdWRd3oW3aAJ03/mOt/TCeNh@postini.com; Sat, 09 Jun 2012 20:19:22 PDT Received: from EXSFM-MB03.internal.salesforce.com ([10.1.127.58]) by exsfm-hub4.internal.salesforce.com ([10.1.127.8]) with mapi; Sat, 9 Jun 2012 20:19:21 -0700 From: Chuck Mortimore To: Lewis Adam-CAL022 Date: Sat, 9 Jun 2012 20:19:19 -0700 Thread-Topic: [OAUTH-WG] Authorization Request via back channel / direct communication? Thread-Index: Ac1Gt9O8dhoqjnKJTj+e8Rz9bcvftQ== Message-ID: <1674F0F4-848C-4A18-871C-47B109E2458A@salesforce.com> References: <59E470B10C4630419ED717AC79FCF9A90AED9537@BL2PRD0410MB363.namprd04.prod.outlook.com> <0C36899C-5011-483D-89FA-E5ACF74C4119@ve7jtb.com> <59E470B10C4630419ED717AC79FCF9A90AED96D7@BL2PRD0410MB363.namprd04.prod.outlook.com> In-Reply-To: <59E470B10C4630419ED717AC79FCF9A90AED96D7@BL2PRD0410MB363.namprd04.prod.outlook.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_1674F0F4848C4A18871C47B109E2458Asalesforcecom_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Authorization Request via back channel / direct communication? X-BeenThere: oauth@ietf.org X-Mailman-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, 10 Jun 2012 03:19:24 -0000 --_000_1674F0F4848C4A18871C47B109E2458Asalesforcecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGV5IEFkYW0uLi4NCg0KVGhlcmUncyBiZWVuIGEgYnVuY2ggb2Ygd29yayBkb25lIGFkYXB0aW5n IE9BdXRoIHRvIGVudGVycHJpc2UgdXNlLWNhc2VzLiAgICBDaGVjayBvdXQgdGhlIG9hdXRoIGFz c2VydGlvbnMgZHJhZnQgYW5kIHRoZSBzYW1sIGFuZCBqd3QgYmluZGluZ3MuICAgSW4gYWRkaXRp b24sIGEgbnVtYmVyIG9mIGRlcGxveW1lbnRzIGhhdmUgZXN0YWJsaXNoZWQgc3Ryb25nIHBhdHRl cm5zIGZvciB1c2luZyB0aGUgbW9yZSBjb21tb24gZmxvd3MgaW4gZW50ZXJwcmlzZSBzZXR0aW5n cy4gICBJJ2QgYmUgaGFwcHkgdG8gZGlzY3VzcyBpZiB5b3UncmUgaW50ZXJlc3RlZC4NCg0KLSBj bW9ydA0KDQpPbiBKdW4gOSwgMjAxMiwgYXQgMzowOCBQTSwgIkxld2lzIEFkYW0tQ0FMMDIyIiA8 QWRhbS5MZXdpc0Btb3Rvcm9sYXNvbHV0aW9ucy5jb208bWFpbHRvOkFkYW0uTGV3aXNAbW90b3Jv bGFzb2x1dGlvbnMuY29tPj4gd3JvdGU6DQoNCkhpIEpvaG4sDQoNCuKAnE1vc3Qgb2YgT0F1dGgg aXMgcHJlZGljYXRlZCBvbiBub3Qgc2hhcmluZyB0aGUgdXNlcnMgY3JlZGVudGlhbCB3aXRoIHRo ZSBjbGllbnQsIGJlY2F1c2UgY2xpZW50cyBhcmUgbm90IHRydXN0ZWQu4oCdDQoNClRoaXMgaXMg ZXhhY3RseSBteSBwb2ludC4gIEkgY2xlYXJseSB1bmRlcnN0YW5kIHRoZSBkcml2aW5nIG1vdGl2 YXRpb25zIGZvciB3aHkgT0F1dGggd2FzIGRlc2lnbmVkIHRoZSB3YXkgdGhhdCBpdCB3YXMuICBJ IGNlcnRhaW5seSB3b3VsZCBub3Qgd2FudCB0byBnaXZlIHdlYnNpdGUtQSBteSBwYXNzd29yZCB0 byBhY2Nlc3MgbXkgZGF0YSBvbiB3ZWJzaXRlLUIuDQoNCkJ1dCBpdCBzZWVtcyB0aGF0IHNpbmNl IE9BdXRoIHdhcyBmaXJzdCBlbnZpc2lvbmVkLCBpdCBoYXMgZ2FpbmVkIGFuIGluY3JlZGlibGUg YW1vdW50IG9mIG1vbWVudHVtIGZvciB1c2UgY2FzZXMgdGhhdCBpdCB3YXMgbm90IG9yaWdpbmFs bHkgZW52aXNpb25lZCBmb3IuICBBcyB3ZSBhbGwga25vdywgdGhlcmUgaXMgYSBkb21pbmFudCB0 cmVuZCB3aXRoaW4gdGhlIGVudGVycHJpc2UgdG8gbW92ZSBhd2F5IGZyb20gV1MtKi9TT0FQL1dT LVRydXN0IHRvd2FyZCBSRVNUZnVsIEFQSXMg4oCmIGFuZCBpZiBSRVNUIGlzIGdvaW5nIHRvIHJl cGxhY2UgU09BUCBhbmQgT0F1dGgvQ29ubmVjdCBpcyB0aGUgcHJlZmVycmVkIG1lYW5zIGJ5IHdo aWNoIHRvIHNlY3VyZSBSRVNUZnVsIEFQSSBjYWxscywgdGhlbiBpdCBzZWVtcyBpdCB3b3VsZCBi ZSB1c2VmdWwgdG8gZGVmaW5lIHNvbWUgT0F1dGggZmxvd3MgdGhhdCBhcmUgb3B0aW1pemVkIGZv ciBlbnRlcnByaXNlIHVzZSBjYXNlcywgd2hlcmUgdGhlIGNsaWVudCBhbmQgUlMgYXJlIHVuZGVy IHRoZSBzYW1lIHNlY3VyaXR5IGRvbWFpbi4gIFdoZW4gd2Ugc2VsbCBvdXIgcHJvZHVjdHMgdG8g Y3VzdG9tZXJzLCB3ZSBzZWxsIHRoZW0gdGhlIHNlcnZlciBhbmQgd2Ugc2VsbCB0aGVtIHRoZSBj bGllbnQuICBJdOKAmXMgYWxsIHZlcnkgdHJ1c3RlZC4gIE5vYm9keSB0aGlua3MgdHdpY2UgYWJv dXQgZW50ZXJpbmcgdGhlIGNyZWRlbnRpYWxzIGludG8gYW4gT3V0bG9vayBjbGllbnQgdG8gYXV0 aGVudGljYXRlIHRvIGFuIGV4Y2hhbmdlIHNlcnZlci4gIFdTLVRydXN0IHdhcyBvcHRpbWl6ZWQg Zm9yIGVudGVycHJpc2Ugc2NlbmFyaW9zICBhbmQgY2xpZW50cyBhcHBzIGNvbGxlY3RlZCBjcmVk ZW50aWFscyBhbmQgcGFzc2VkIHRoZW0gdG8gdGhlIFNUUyBpbiBleGNoYW5nZSBmb3IgYSBTQU1M IGFzc2VydGlvbiB2aWEgYSBzaW1wbGUgUlNUL1JTVFIuICBUaGlzIGlzIGFuYWxvZ291cyB0byB0 aGUgUk8gY3JlZGVudGlhbHMgZmxvdyB3aGljaCBjb21tdW5pY2F0ZXMgdGhlIHBhc3N3b3JkIGlu IHRoZSByZXF1ZXN0IGFuZCBnZXRzIHRoZSB0b2tlbiBpbiB0aGUgcmVzcG9uc2UuICBCdXQgV1Mt VHJ1c3QgYWxzbyBkZWZpbmVkIG90aGVyIHR5cGVzIHRoYXQgY291bGQgYmUgcGFzc2VkIGluIHRo ZSBSU1Qgb3RoZXIgdGhhbiBwYXNzd29yZCB0b2tlbnMuDQoNClNvIEkgZ3Vlc3MgYWxsIEnigJlt IGdldHRpbmcgYXQgaXMgdGhhdCBpZiBSRVNUIGlzIHRvIHJlcGxhY2UgU09BUCAoaW4gdGhlIGVu dGVycHJpc2UpIGFuZCBPQXV0aC9Db25uZWN0IGlzIHRvIGJlIHRoZSBlbmRnYW1lLCB0aGVuIGJv cnJvd2luZyBzb21lIG9mIHRoZSBkZXNpZ24gcGF0dGVybnMgZnJvbSBXUy0qIHdvdWxkIHNlZW0g YmVuZWZpY2lhbC4gIEFnYWluLCBpdOKAmXMgbm90IHRoYXQgSSBjYW7igJl0IGRvIHRoZSB3aG9s ZSDigJxyZWdpc3RlciBhIGhhbmRsZXIgZm9yIGEgYnJvd3NlciBVUkkgdGhpbmfigJ0g4oCmIGJ1 dCBmb3IgZW50ZXJwcmlzZSB1c2UgY2FzZXMsIGl04oCZcyBhIGtsdWRnZS4NCg0KSnVzdCBteSAy IGNlbnRzLiAgSXTigJlzIGZyZWUg4pi6DQphZGFtDQoNCkZyb206IEpvaG4gQnJhZGxleSBbbWFp bHRvOnZlN2p0YkB2ZTdqdGIuY29tXQ0KU2VudDogRnJpZGF5LCBKdW5lIDA4LCAyMDEyIDk6MDQg UE0NClRvOiBMZXdpcyBBZGFtLUNBTDAyMg0KQ2M6IG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0 aEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIEF1dGhvcml6YXRpb24gUmVxdWVz dCB2aWEgYmFjayBjaGFubmVsIC8gZGlyZWN0IGNvbW11bmljYXRpb24/DQoNClRvIHNvbWUgZXh0 ZW50IGl0IGdvZXMgdG8gdGhlIHF1ZXN0aW9uIG9mIHdobyBkbyB5b3UgdHJ1c3QuDQoNCk1vc3Qg b2YgT0F1dGggaXMgcHJlZGljYXRlZCBvbiBub3Qgc2hhcmluZyB0aGUgdXNlcnMgY3JlZGVudGlh bCB3aXRoIHRoZSBjbGllbnQsIGJlY2F1c2UgY2xpZW50cyBhcmUgbm90IHRydXN0ZWQuDQoNCllv dXIgc2l0dWF0aW9uIG1heSBiZSBkaWZmZXJlbnQgaWYgeW91IGNvbnRyb2wgdGhlIGRldmljZS4N Cg0KSWYgeW91IGFyZSB1c2luZyBtdWx0aSBmYWN0b3IgYXV0aGVudGljYXRpb24gdGhlbiB1c2lu ZyBhbiBlbWJlZGRlZCB3ZWIgdmlldyBpcyBwcm9iYWJseSB5b3VyIGJlc3Qgb3B0aW9uIHRvIGFs bG93IGZvciBmbGV4aWJpbGl0eSBhcyBhdXRoZW50aWNhdGlvbiBtZWNoYW5pc21zIGNoYW5nZSBm b3IgdXNlcnMgcmF0aGVyIHRoYW4gY29kaW5nIHRoZW0gaW50byB0aGUgYXBwIGRpcmVjdGx5Lg0K DQpVc2luZyBhIGVtYmVkZGVkIHdlYiB2aWV3IHdpdGggYSBPVFAgaXMgcHJvYmFibHkgbm90IGEg YmFkIHRoaW5nIHRob3VnaCBpbiBnZW5lcmFsIHdlIHdhbnQgdG8gdHJhaW4gdXNlcnMgbm90IHRv IHB1dCB0aGVyZSBjcmVkZW50aWFscyBpbnRvIHVudHJ1c3RlZCBhcHBsaWNhdGlvbnMgYW5kIHNp dGVzLg0KDQpKb2huIEIuDQoNCk9uIDIwMTItMDYtMDgsIGF0IDY6NDMgUE0sIExld2lzIEFkYW0t Q0FMMDIyIHdyb3RlOg0KDQoNCkhpLA0KDQpJIGhhdmUgYSBoaXN0b3JpY2FsIHF1ZXN0aW9uIGFy b3VuZCBmcm9udCBjaGFubmVsIC8gYmFjayBjaGFubmVsIChkaXJlY3QpIGNvbW11bmljYXRpb25z IGFuZCBBdXRob3JpemF0aW9uIFJlcXVlc3RzLiAgQm90aCB0aGUgY29kZS1mbG93IGFuZCBpbXBs aWNpdC1mbG93IHV0aWxpemUgYSBmcm9udCBjaGFubmVsIGNvbW11bmljYXRpb24gdGhyb3VnaCB0 aGUgVUEuICBUaGlzIG1ha2VzIHNlbnNlIGZvciB0aGUgZGVsZWdhdGVkIGNyZWRlbnRpYWxzIGNh c2UgKGUuZy4gc2h1dHRlcmZseSBhY2Nlc3NpbmcgcGhvdG9zIG9uIGZhY2Vib29rKS4NCg0KSeKA mW0gaW4gdGhlIG5hdGl2ZSBhcHAgLyBjbGllbnQgbWFya2V0LCBhbmQgdGhlIFJPIHBhc3N3b3Jk IGNyZWRlbnRpYWxzIGZsb3cgZml0cyByZWFsbHkgd2VsbCDigKYgZXhwZWN0IGl04oCZcyBsaW1p dGVkIHRvIHBhc3N3b3Jkcy4gIEnigJl2ZSBiZWVuIHdlbGwgZWR1Y2F0ZWQgKGJ5IGxvdHMgb2Yg Zm9sa3Mgb24gdGhpcyBsaXN0KSBhYm91dCB0aGUg4oCcYmVzdCBwcmFjdGljZXPigJ0gdG8gZW5h YmxlIG5hdGl2ZSBjbGllbnRzIHRvIHVzZSB0aGUgY29kZSBmbG93LCBlLmcuIHJlZ2lzdGVyaW5n IGEgY3VzdG9tIGNhbGxiYWNrIFVSSSBhbmQgcmVnaXN0ZXIgbXkgbmF0aXZlIGFwcCBhc3MgdGhl IGhhbmRsZXIgZm9yIHRoYXQgVVJJLg0KDQpCdXQg4oCmIChhbmQgbm90IGtub3dpbmcgdGhlIGhp c3RvcnkgYmVoaW5kIGFsbCB0aGlzKSwgaXQgc2VlbXMgdGhhdCBPQXV0aCB3YXMgZGVzaWduZWQg Zm9yIGNvbmZpZGVudGlhbCBjbGllbnRzLCBhbmQgd2FzIOKAnHJldHJvLWZpdHRlZOKAnSB0byBt YWtlIG5hdGl2ZSBhcHBzIHdvcmsuICBBbmQgaXQganVzdCBmZWVscyBhIGJpdCBsaWtlIGEgaGFj ayB0byBtZSAoYWxiZWl0IGEgd29ya2FibGUgb25lKSwgdGhlIHdob2xlIGN1c3RvbSBjYWxsYmFj ayBVUkkgdGhpbmcsIHRvIGdldCBpdCB0byB3b3JrLiAgVGhlIFJPIHBhc3N3b3JkIGNyZWRlbnRp YWxzIHNlZW1zIGxpa2UgYSBtdWNoIGJldHRlciBmaXQgZm9yIG5hdGl2ZSBhcHBzLCBzaW5jZSBp dCBoYXMgbm8gbmVlZCBmb3IgdGhlIFVBIGFuZCBjYW4gdXNlIGJhY2sgY2hhbm5lbCAvIGRpcmVj dGlvbiBjb21tdW5pY2F0aW9uIHRvIHRhbGsgdG8gdGhlIEFTIGFuZCBvYnRhaW4gYW5kIGFjY2Vz cyB0b2tlbi4gIEJ1dCB0aGF0IGxpbWl0cyBtZSB0byBhIHBhc3N3b3JkIGFuZCBlbGltaW5hdGVz IGFueSBjaGFuY2Ugb2Ygc3Ryb25nIGF1dGhlbnRpY2F0aW9uLg0KDQpJdCB3b3VsZCBzZWVtIG1v cmUgc3RyYWlnaHQgZm9yd2FyZCB0byBkZWZpbmUgYSBiYWNrIGNoYW5uZWwgZmxvdyBzdWNoIHRo YXQgYSBuYXRpdmUgY2xpZW50IGNvdWxkIHNlbmQgb2ZmIGFuIGF1dGhvcml6YXRpb24gcmVxdWVz dCB3aXRoIHJlc3BvbnNlPXRva2VuIChvciBpZF90b2tlbiBpbiB0aGUgQ29ubmVjdCBjYXNlKSwg cmVzcG9uZCB0byBhIGNoYWxsZW5nZSBmcm9tIHRoZSBBUyBmb3IgYXV0aGVudGljYXRpb24sIGFu ZCBvYnRhaW4gYSByZXNwb25zZSBjb250YWluaW5nIHRoZSBhY2Nlc3NfdG9rZW4gLyBpZF90b2tl biBhbmQgdXNlIGl0IGZvciBpdHMgUkVTVGZ1bCBBUEkgY29tbXVuaWNhdGlvbnMgd2l0aCB0aGUg UlMvUlAuICBUaGlzIHdvdWxkIGVuYWJsZSBzdHJvbmcgYXV0aGVudGljYXRpb24gbWV0aG9kcyBu b3QgcG9zc2libGUgdXNpbmcganVzdCBSTyBwYXNzd29yZHMuDQoNCkhhcyBhbnlib2R5IGVsc2Ug ZXZlciBleHByZXNzZWQgaW50ZXJlc3QgaW4gc3VjaCBiYWNrIGNoYW5uZWwgY2FsbHMgYmV0d2Vl biBmb3IgbmF0aXZlIGNsaWVudHM/ICBXYXMgaXQgcHJldmlvdXNseSBjb25zaWRlcmVkIGFuZCBk cm9wcGVkPw0KDQpUeCENCmFkYW0NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpP QXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1 dGgNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9B dXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0K --_000_1674F0F4848C4A18871C47B109E2458Asalesforcecom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PC9oZWFkPjxib2R5IGJnY29sb3I9IiNGRkZGRkYiPjxkaXY+SGV5IEFkYW0u Li48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PlRoZXJlJ3MgYmVlbiBhIGJ1bmNoIG9mIHdvcmsg ZG9uZSBhZGFwdGluZyBPQXV0aCB0byBlbnRlcnByaXNlIHVzZS1jYXNlcy4gJm5ic3A7ICZuYnNw O0NoZWNrIG91dCB0aGUgb2F1dGggYXNzZXJ0aW9ucyBkcmFmdCBhbmQgdGhlIHNhbWwgYW5kIGp3 dCBiaW5kaW5ncy4gJm5ic3A7IEluIGFkZGl0aW9uLCBhIG51bWJlciBvZiBkZXBsb3ltZW50cyBo YXZlIGVzdGFibGlzaGVkIHN0cm9uZyBwYXR0ZXJucyBmb3IgdXNpbmcgdGhlIG1vcmUgY29tbW9u IGZsb3dzIGluIGVudGVycHJpc2Ugc2V0dGluZ3MuICZuYnNwOyBJJ2QgYmUgaGFwcHkgdG8gZGlz Y3VzcyBpZiB5b3UncmUgaW50ZXJlc3RlZC4gJm5ic3A7PC9kaXY+PGRpdj48YnI+LSBjbW9ydDwv ZGl2PjxkaXY+PGJyPk9uIEp1biA5LCAyMDEyLCBhdCAzOjA4IFBNLCAiTGV3aXMgQWRhbS1DQUww MjIiICZsdDs8YSBocmVmPSJtYWlsdG86QWRhbS5MZXdpc0Btb3Rvcm9sYXNvbHV0aW9ucy5jb20i PkFkYW0uTGV3aXNAbW90b3JvbGFzb2x1dGlvbnMuY29tPC9hPiZndDsgd3JvdGU6PGJyPjxicj48 L2Rpdj48ZGl2PjwvZGl2PjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxkaXY+DQo8bWV0YSBodHRw LWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1XaW5kb3dz LTEyNTIiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAx MiAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8YmFzZSBocmVmPSJ4LW1zZzovLzQ4MzkvIj48c3R5bGU+ PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpI ZWx2ZXRpY2E7DQoJcGFub3NlLTE6MiAxMSA2IDQgMiAyIDIgMiAyIDQ7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5nczsNCglwYW5vc2UtMTo1IDAgMCAw IDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5v c2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRh aG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0 aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJn aW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5 cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dl ZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5hcHBsZS1zdHlsZS1zcGFuDQoJe21zby1zdHlsZS1uYW1l OmFwcGxlLXN0eWxlLXNwYW47fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjpvbGl2ZTsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7DQoJ dGV4dC1kZWNvcmF0aW9uOm5vbmUgbm9uZTt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUt dHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQoNCg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6b2xpdmUiPkhpIEpvaG4sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpvbGl2ZSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGk+4oCcTW9zdCBvZiBPQXV0aCBpcyBwcmVkaWNhdGVk IG9uIG5vdCBzaGFyaW5nIHRoZSB1c2VycyBjcmVkZW50aWFsIHdpdGggdGhlIGNsaWVudCwgYmVj YXVzZSBjbGllbnRzIGFyZSBub3QgdHJ1c3RlZC7igJ08bzpwPjwvbzpwPjwvaT48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOm9saXZlIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOm9saXZl Ij5UaGlzIGlzIGV4YWN0bHkgbXkgcG9pbnQuJm5ic3A7IEkgY2xlYXJseSB1bmRlcnN0YW5kIHRo ZSBkcml2aW5nIG1vdGl2YXRpb25zIGZvciB3aHkgT0F1dGggd2FzIGRlc2lnbmVkIHRoZSB3YXkg dGhhdCBpdCB3YXMuJm5ic3A7IEkgY2VydGFpbmx5IHdvdWxkIG5vdCB3YW50IHRvIGdpdmUgd2Vi c2l0ZS1BIG15IHBhc3N3b3JkDQogdG8gYWNjZXNzIG15IGRhdGEgb24gd2Vic2l0ZS1CLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 b2xpdmUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6b2xpdmUiPkJ1dCBpdCBzZWVtcyB0aGF0IHNpbmNlIE9BdXRoIHdh cyBmaXJzdCBlbnZpc2lvbmVkLCBpdCBoYXMgZ2FpbmVkIGFuIGluY3JlZGlibGUgYW1vdW50IG9m IG1vbWVudHVtIGZvciB1c2UgY2FzZXMgdGhhdCBpdCB3YXMgbm90IG9yaWdpbmFsbHkgZW52aXNp b25lZCBmb3IuJm5ic3A7IEFzIHdlIGFsbCBrbm93LCB0aGVyZQ0KIGlzIGEgZG9taW5hbnQgdHJl bmQgd2l0aGluIHRoZSBlbnRlcnByaXNlIHRvIG1vdmUgYXdheSBmcm9tIFdTLSovU09BUC9XUy1U cnVzdCB0b3dhcmQgUkVTVGZ1bCBBUElzIOKApiBhbmQgaWYgUkVTVCBpcyBnb2luZyB0byByZXBs YWNlIFNPQVAgYW5kIE9BdXRoL0Nvbm5lY3QgaXMgdGhlIHByZWZlcnJlZCBtZWFucyBieSB3aGlj aCB0byBzZWN1cmUgUkVTVGZ1bCBBUEkgY2FsbHMsIHRoZW4gaXQgc2VlbXMgaXQgd291bGQgYmUg dXNlZnVsIHRvIGRlZmluZQ0KIHNvbWUgT0F1dGggZmxvd3MgdGhhdCBhcmUgb3B0aW1pemVkIGZv ciBlbnRlcnByaXNlIHVzZSBjYXNlcywgd2hlcmUgdGhlIGNsaWVudCBhbmQgUlMgYXJlIHVuZGVy IHRoZSBzYW1lIHNlY3VyaXR5IGRvbWFpbi4mbmJzcDsgV2hlbiB3ZSBzZWxsIG91ciBwcm9kdWN0 cyB0byBjdXN0b21lcnMsIHdlIHNlbGwgdGhlbSB0aGUgc2VydmVyIGFuZCB3ZSBzZWxsIHRoZW0g dGhlIGNsaWVudC4mbmJzcDsgSXTigJlzIGFsbCB2ZXJ5IHRydXN0ZWQuJm5ic3A7IE5vYm9keSB0 aGlua3MgdHdpY2UNCiBhYm91dCBlbnRlcmluZyB0aGUgY3JlZGVudGlhbHMgaW50byBhbiBPdXRs b29rIGNsaWVudCB0byBhdXRoZW50aWNhdGUgdG8gYW4gZXhjaGFuZ2Ugc2VydmVyLiZuYnNwOyBX Uy1UcnVzdCB3YXMgb3B0aW1pemVkIGZvciBlbnRlcnByaXNlIHNjZW5hcmlvcyAmbmJzcDthbmQg Y2xpZW50cyBhcHBzIGNvbGxlY3RlZCBjcmVkZW50aWFscyBhbmQgcGFzc2VkIHRoZW0gdG8gdGhl IFNUUyBpbiBleGNoYW5nZSBmb3IgYSBTQU1MIGFzc2VydGlvbiB2aWEgYSBzaW1wbGUgUlNUL1JT VFIuJm5ic3A7DQogVGhpcyBpcyBhbmFsb2dvdXMgdG8gdGhlIFJPIGNyZWRlbnRpYWxzIGZsb3cg d2hpY2ggY29tbXVuaWNhdGVzIHRoZSBwYXNzd29yZCBpbiB0aGUgcmVxdWVzdCBhbmQgZ2V0cyB0 aGUgdG9rZW4gaW4gdGhlIHJlc3BvbnNlLiZuYnNwOyBCdXQgV1MtVHJ1c3QgYWxzbyBkZWZpbmVk IG90aGVyIHR5cGVzIHRoYXQgY291bGQgYmUgcGFzc2VkIGluIHRoZSBSU1Qgb3RoZXIgdGhhbiBw YXNzd29yZCB0b2tlbnMuJm5ic3A7DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOm9saXZlIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOm9saXZlIj5TbyBJ IGd1ZXNzIGFsbCBJ4oCZbSBnZXR0aW5nIGF0IGlzIHRoYXQgaWYgUkVTVCBpcyB0byByZXBsYWNl IFNPQVAgKGluIHRoZSBlbnRlcnByaXNlKSBhbmQgT0F1dGgvQ29ubmVjdCBpcyB0byBiZSB0aGUg ZW5kZ2FtZSwgdGhlbiBib3Jyb3dpbmcgc29tZSBvZiB0aGUgZGVzaWduIHBhdHRlcm5zIGZyb20g V1MtKg0KIHdvdWxkIHNlZW0gYmVuZWZpY2lhbC4mbmJzcDsgQWdhaW4sIGl04oCZcyBub3QgdGhh dCBJIGNhbuKAmXQgZG8gdGhlIHdob2xlIOKAnHJlZ2lzdGVyIGEgaGFuZGxlciBmb3IgYSBicm93 c2VyIFVSSSB0aGluZ+KAnSDigKYgYnV0IGZvciBlbnRlcnByaXNlIHVzZSBjYXNlcywgaXTigJlz IGEga2x1ZGdlLiZuYnNwOw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpvbGl2ZSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpvbGl2ZSI+SnVzdCBteSAy IGNlbnRzLiZuYnNwOyBJdOKAmXMgZnJlZQ0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTpXaW5nZGluZ3M7Y29sb3I6b2xpdmUiPko8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpvbGl2ZSI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpvbGl2ZSI+YWRhbTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6b2xpdmUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYg MS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij4gSm9obiBCcmFkbGV5IFttYWlsdG86dmU3anRiQHZlN2p0Yi5jb21d DQo8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBKdW5lIDA4LCAyMDEyIDk6MDQgUE08YnI+DQo8 Yj5Ubzo8L2I+IExld2lzIEFkYW0tQ0FMMDIyPGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWls dG86b2F1dGhAaWV0Zi5vcmciPm9hdXRoQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9i PiBSZTogW09BVVRILVdHXSBBdXRob3JpemF0aW9uIFJlcXVlc3QgdmlhIGJhY2sgY2hhbm5lbCAv IGRpcmVjdCBjb21tdW5pY2F0aW9uPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlRvIHNvbWUgZXh0ZW50IGl0IGdvZXMgdG8gdGhlIHF1ZXN0aW9uIG9mIHdo byBkbyB5b3UgdHJ1c3QuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5Nb3N0IG9mIE9BdXRoIGlzIHByZWRpY2F0ZWQgb24gbm90IHNoYXJpbmcgdGhlIHVzZXJz IGNyZWRlbnRpYWwgd2l0aCB0aGUgY2xpZW50LCBiZWNhdXNlIGNsaWVudHMgYXJlIG5vdCB0cnVz dGVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5Zb3VyIHNpdHVhdGlvbiBtYXkgYmUgZGlmZmVyZW50IGlmIHlvdSBjb250cm9sIHRoZSBkZXZp Y2UuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PklmIHlvdSBhcmUgdXNpbmcgbXVsdGkgZmFjdG9yIGF1dGhlbnRpY2F0aW9uIHRoZW4gdXNpbmcg YW4gZW1iZWRkZWQgd2ViIHZpZXcgaXMgcHJvYmFibHkgeW91ciBiZXN0IG9wdGlvbiB0byBhbGxv dyBmb3IgZmxleGliaWxpdHkgYXMgYXV0aGVudGljYXRpb24gbWVjaGFuaXNtcyBjaGFuZ2UgZm9y IHVzZXJzIHJhdGhlciB0aGFuIGNvZGluZyB0aGVtIGludG8gdGhlIGFwcCBkaXJlY3RseS48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VXNpbmcg YSBlbWJlZGRlZCB3ZWIgdmlldyB3aXRoIGEgT1RQIGlzIHByb2JhYmx5IG5vdCBhIGJhZCB0aGlu ZyB0aG91Z2ggaW4gZ2VuZXJhbCB3ZSB3YW50IHRvIHRyYWluIHVzZXJzIG5vdCB0byBwdXQgdGhl cmUgY3JlZGVudGlhbHMgaW50byB1bnRydXN0ZWQgYXBwbGljYXRpb25zIGFuZCBzaXRlcy48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Sm9obiBC LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9u IDIwMTItMDYtMDgsIGF0IDY6NDMgUE0sIExld2lzIEFkYW0tQ0FMMDIyIHdyb3RlOjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ SGksPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5i c3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SSBo YXZlIGEgaGlzdG9yaWNhbCBxdWVzdGlvbiBhcm91bmQgZnJvbnQgY2hhbm5lbCAvIGJhY2sgY2hh bm5lbCAoZGlyZWN0KSBjb21tdW5pY2F0aW9ucyBhbmQgQXV0aG9yaXphdGlvbiBSZXF1ZXN0cy4m bmJzcDsgQm90aCB0aGUgY29kZS1mbG93IGFuZCBpbXBsaWNpdC1mbG93IHV0aWxpemUgYSBmcm9u dCBjaGFubmVsIGNvbW11bmljYXRpb24NCiB0aHJvdWdoIHRoZSBVQS4mbmJzcDsgVGhpcyBtYWtl cyBzZW5zZSBmb3IgdGhlIGRlbGVnYXRlZCBjcmVkZW50aWFscyBjYXNlIChlLmcuIHNodXR0ZXJm bHkgYWNjZXNzaW5nIHBob3RvcyBvbiBmYWNlYm9vaykuJm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SeKAmW0gaW4gdGhlIG5hdGl2ZSBhcHAg LyBjbGllbnQgbWFya2V0LCBhbmQgdGhlIFJPIHBhc3N3b3JkIGNyZWRlbnRpYWxzIGZsb3cgZml0 cyByZWFsbHkgd2VsbCDigKYgZXhwZWN0IGl04oCZcyBsaW1pdGVkIHRvIHBhc3N3b3Jkcy4mbmJz cDsgSeKAmXZlIGJlZW4gd2VsbCBlZHVjYXRlZCAoYnkgbG90cyBvZiBmb2xrcyBvbiB0aGlzIGxp c3QpIGFib3V0DQogdGhlIOKAnGJlc3QgcHJhY3RpY2Vz4oCdIHRvIGVuYWJsZSBuYXRpdmUgY2xp ZW50cyB0byB1c2UgdGhlIGNvZGUgZmxvdywgZS5nLiByZWdpc3RlcmluZyBhIGN1c3RvbSBjYWxs YmFjayBVUkkgYW5kIHJlZ2lzdGVyIG15IG5hdGl2ZSBhcHAgYXNzIHRoZSBoYW5kbGVyIGZvciB0 aGF0IFVSSS4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5CdXQg4oCmIChhbmQgbm90IGtub3dpbmcgdGhlIGhpc3RvcnkgYmVoaW5kIGFsbCB0 aGlzKSwgaXQgc2VlbXMgdGhhdCBPQXV0aCB3YXMgZGVzaWduZWQgZm9yIGNvbmZpZGVudGlhbCBj bGllbnRzLCBhbmQgd2FzIOKAnHJldHJvLWZpdHRlZOKAnSB0byBtYWtlIG5hdGl2ZSBhcHBzIHdv cmsuJm5ic3A7IEFuZCBpdCBqdXN0IGZlZWxzIGEgYml0IGxpa2UNCiBhIGhhY2sgdG8gbWUgKGFs YmVpdCBhIHdvcmthYmxlIG9uZSksIHRoZSB3aG9sZSBjdXN0b20gY2FsbGJhY2sgVVJJIHRoaW5n LCB0byBnZXQgaXQgdG8gd29yay4mbmJzcDsgVGhlIFJPIHBhc3N3b3JkIGNyZWRlbnRpYWxzIHNl ZW1zIGxpa2UgYSBtdWNoIGJldHRlciBmaXQgZm9yIG5hdGl2ZSBhcHBzLCBzaW5jZSBpdCBoYXMg bm8gbmVlZCBmb3IgdGhlIFVBIGFuZCBjYW4gdXNlIGJhY2sgY2hhbm5lbCAvIGRpcmVjdGlvbiBj b21tdW5pY2F0aW9uIHRvIHRhbGsNCiB0byB0aGUgQVMgYW5kIG9idGFpbiBhbmQgYWNjZXNzIHRv a2VuLiZuYnNwOyBCdXQgdGhhdCBsaW1pdHMgbWUgdG8gYSBwYXNzd29yZCBhbmQgZWxpbWluYXRl cyBhbnkgY2hhbmNlIG9mIHN0cm9uZyBhdXRoZW50aWNhdGlvbi48L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5JdCB3b3VsZCBzZWVtIG1vcmUgc3RyYWln aHQgZm9yd2FyZCB0byBkZWZpbmUgYSBiYWNrIGNoYW5uZWwgZmxvdyBzdWNoIHRoYXQgYSBuYXRp dmUgY2xpZW50IGNvdWxkIHNlbmQgb2ZmIGFuIGF1dGhvcml6YXRpb24gcmVxdWVzdCB3aXRoIHJl c3BvbnNlPXRva2VuIChvciBpZF90b2tlbiBpbiB0aGUgQ29ubmVjdCBjYXNlKSwNCiByZXNwb25k IHRvIGEgY2hhbGxlbmdlIGZyb20gdGhlIEFTIGZvciBhdXRoZW50aWNhdGlvbiwgYW5kIG9idGFp biBhIHJlc3BvbnNlIGNvbnRhaW5pbmcgdGhlIGFjY2Vzc190b2tlbiAvIGlkX3Rva2VuIGFuZCB1 c2UgaXQgZm9yIGl0cyBSRVNUZnVsIEFQSSBjb21tdW5pY2F0aW9ucyB3aXRoIHRoZSBSUy9SUC4m bmJzcDsgVGhpcyB3b3VsZCBlbmFibGUgc3Ryb25nIGF1dGhlbnRpY2F0aW9uIG1ldGhvZHMgbm90 IHBvc3NpYmxlIHVzaW5nIGp1c3QgUk8gcGFzc3dvcmRzLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkhhcyBhbnlib2R5IGVsc2UgZXZlciBleHByZXNz ZWQgaW50ZXJlc3QgaW4gc3VjaCBiYWNrIGNoYW5uZWwgY2FsbHMgYmV0d2VlbiBmb3IgbmF0aXZl IGNsaWVudHM/Jm5ic3A7IFdhcyBpdCBwcmV2aW91c2x5IGNvbnNpZGVyZWQgYW5kIGRyb3BwZWQ/ Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ VHghPGJyPg0KYWRhbTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9B dXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQoNCg0KPC9kaXY+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUi PjxkaXY+PHNwYW4+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188L3NwYW4+PGJyPjxzcGFuPk9BdXRoIG1haWxpbmcgbGlzdDwvc3Bhbj48YnI+PHNwYW4+PGEg aHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT48L3NwYW4+PGJy PjxzcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1 dGgiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PC9zcGFu Pjxicj48L2Rpdj48L2Jsb2NrcXVvdGU+PC9ib2R5PjwvaHRtbD4= --_000_1674F0F4848C4A18871C47B109E2458Asalesforcecom_-- From sakimura@gmail.com Sat Jun 9 23:21:17 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 477DF21F869E for ; Sat, 9 Jun 2012 23:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[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 WzBWwMe+jm-F for ; Sat, 9 Jun 2012 23:21:16 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6B57221F869C for ; Sat, 9 Jun 2012 23:21:13 -0700 (PDT) Received: by bkty8 with SMTP id y8so3207263bkt.31 for ; Sat, 09 Jun 2012 23:21:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:from:in-reply-to:mime-version:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=axhvzzE3EyEtC8XZfiQ195ioPyYdQOec2N2iVVnb1Vc=; b=IWEOBs7vsHXmrV6F34Jq7bo9FRHHDT6SP8e4yyajOb5qsL/dvGWmBXUpYMTx7eGmL1 aMraXjjRyf53LflZAfdyeiDkg4zMaVEMs0Ua44MgflsO+qVShMYi4nKJELTA0KztXxhF tF0O8Kfp08qgXvgGm0yVmXDBxkF73DqHzwyUdOZspnRNNhBKc5zPHossAONA6Pc78fT9 x1wCtCSdaTVmqHKHhnq9grJkiDVw6SjibUiEW0wOHK9biTMP9U4TkyZE+NVZetga9gtm onhqUePefkOX9NAYt0Z8U5WCZ2tpq/u3kSuJyAbc93akKtnFzwPZIOx9jDJC6JFwU1lR zoGw== Received: by 10.204.152.203 with SMTP id h11mr8495780bkw.122.1339309272426; Sat, 09 Jun 2012 23:21:12 -0700 (PDT) References: <59E470B10C4630419ED717AC79FCF9A90AED9377@BL2PRD0410MB363.namprd04.prod.outlook.com> <3B97D8F2-E6FC-4D58-9B49-8154C58EB0EA@ve7jtb.com> From: Nat Sakimura In-Reply-To: <3B97D8F2-E6FC-4D58-9B49-8154C58EB0EA@ve7jtb.com> Mime-Version: 1.0 (1.0) Date: Sun, 10 Jun 2012 15:21:11 +0900 Message-ID: <6953797407360189240@unknownmsgid> To: John Bradley Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Implicit vs. Code flow for Native clients X-BeenThere: oauth@ietf.org X-Mailman-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, 10 Jun 2012 06:21:17 -0000 I guess, in the ideal world, the app provider provide a group signature for the app and each client establishes individual keys with AS, but that is not the way current oauth is architected. Maybe the next step after the current set of the new work items are finished. =3Dnat via iPhone On 2012/06/08, at 23:51, John Bradley wrote: > The implicit flow doesn't allow for refresh tokens. > > The refresh token mechanism allows for the AS to revoke access to the RS = when a relatively short lived access_token expires. > > Some people seem to prefer having the RS make a callback to the AS on eac= h access, and not use refresh tokens. > There tradeoffs each way. Issuing a non expiring access_token to the cl= ient with no way to revoke it is quite likely a bad idea. > > I think you are correct that for a native client directly talking to the = AS the implicit flow is no more likely to have token exposed than code. > > The devil is in the details though, I am not recommending implicit over c= ode, the right one to use will depend on multiple factors. > > John B. > On 2012-06-08, at 9:28 AM, Lewis Adam-CAL022 wrote: > >> Hi all, >> >> I'm looking for a better understanding of why the code flow is recommend= ed as the preferred OAuth flow, even when used for native (public) clients. >> >> I totally get why it is preferred for confidential clients, as explained= in section 1.3.1. of the version 26 of the draft. The first reason is the= ability of the token endpoint to authenticate the client - which doesn't r= eally apply in the case of native (public) clients. The second reason cite= d is the ability to communicate the access token directly to the client, wi= thout exposing it to the UA and possibly leaking the access token. This = is probably the one where I don't fully understand the security risk. >> >> In the code flow, the code obviously does flow through the UA, which cou= ld also be exposed to malicious clients executing on the device. And a mal= icious client that steals this code could exchange it for the access token. >> >> Now ... I assume the reason it is still recommended is that unlike an ac= cess-token, the code can only be used ONCE in exchange for a token, and if = a rogue clients grabs it and then the legit clients grabs it and each prese= nt it to the token endpoint in attempt to get the token, the token endpoint= can detect that it has been compromised (as it has been presented twice) a= nd thus cut the attack short? Or is there more to it than that? >> >> I'm asking because the implicit flow avoids an additional roundtrip, and= my clients will run over (at times) very anemic bandwidths. I want to ful= ly understand the security implications vs. performance tradeoffs before ma= king a decision. >> >> 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 From hannes.tschofenig@gmx.net Sun Jun 10 10:11:25 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E81021F844E for ; Sun, 10 Jun 2012 10:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.999 X-Spam-Level: X-Spam-Status: No, score=-99.999 tagged_above=-999 required=5 tests=[BAYES_50=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 GoJ6Bq6o8CjR for ; Sun, 10 Jun 2012 10:11:14 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 1113A21F8474 for ; Sun, 10 Jun 2012 10:11:13 -0700 (PDT) Received: (qmail invoked by alias); 10 Jun 2012 17:11:11 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.104]) [88.115.216.191] by mail.gmx.net (mp029) with SMTP; 10 Jun 2012 19:11:11 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18AjdB+GmYA/d3z4OYY+w/xTdg8ikzr3TFsBNT3YD 6sHO4Jneh95IP4 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <0CBAEB56DDB3A140BA8E8C124C04ECA201068743@P3PWEX2MB008.ex2.secureserver.net> Date: Sun, 10 Jun 2012 20:11:10 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <2E3D9844-8F6E-48F3-B386-2E437C522B7D@gmx.net> References: <0CBAEB56DDB3A140BA8E8C124C04ECA201068743@P3PWEX2MB008.ex2.secureserver.net> To: Eran Hammer , "oauth@ietf.org WG (oauth@ietf.org)" X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Subject: Re: [OAUTH-WG] New draft process / editor role X-BeenThere: oauth@ietf.org X-Mailman-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, 10 Jun 2012 17:11:25 -0000 Hi Eran, Hi all,=20 The story is fairly simple: We have three authors on = draft-ietf-oauth-v2. Having more than one author is helpful in case = others are busy. We had open issues with the document and we discussed them on the list. = Text was proposed and feedback was provided to the list. Thanks everyone = for providing constructive input.=20 The step that happens afterwards is to create a new snapshot of the = document. This helps everyone to know what the latest status is (in case = you are not following all the mail discussions). We are also able to let = IESG members to clear their DISCUSSes.=20 All this work helps us to get closer to completion and I believe we are = getting closer. Unfortunately, there is still one other issue that = Julian raised after the ABNF text was published, see = http://www.ietf.org/mail-archive/web/oauth/current/msg09164.html. I am = planning to distribute a separate mail to raise awareness and to solicit = feedback.=20 We are in the final stages of getting the document published. It would = be great if everyone works together to get the work done as quickly as = possible. Is this possible? Ciao Hannes From hannes.tschofenig@gmx.net Sun Jun 10 10:24:27 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C02921F8589 for ; Sun, 10 Jun 2012 10:24:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.299 X-Spam-Level: X-Spam-Status: No, score=-101.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id koY17vt0RUCJ for ; Sun, 10 Jun 2012 10:24:26 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 38E4721F857F for ; Sun, 10 Jun 2012 10:24:26 -0700 (PDT) Received: (qmail invoked by alias); 10 Jun 2012 17:24:24 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.104]) [88.115.216.191] by mail.gmx.net (mp020) with SMTP; 10 Jun 2012 19:24:24 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX199Umdzx/J9ApuCng5L20vaJA38VFIUwknRtu3SWB dHhHlNJG3xZENN Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig X-Priority: 3 In-Reply-To: Date: Sun, 10 Jun 2012 20:24:22 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <83E11322-166D-41B5-A145-5C759CE3014D@gmx.net> References: <0CBAEB56DDB3A140BA8E8C124C04ECA201068743@P3PWEX2MB008.ex2.secureserver.net> <1339209350.70970.YahooMailNeo@web31816.mail.mud.yahoo.com> To: "Franklin Tse" X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] New draft process / editor role X-BeenThere: oauth@ietf.org X-Mailman-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, 10 Jun 2012 17:24:27 -0000 Hi Franklin,=20 On Jun 9, 2012, at 7:09 AM, Franklin Tse wrote: > I think the chairs should clarify and explain, via this mailing list, >=20 > 1. Whether they have authorized Mike Jones and Dick Hardt to author = and publish the draft Derek and I had asked for a new draft version. We are interested to get = the work on the document finished.=20 Dick is a co-author and can after using the draft submission tool = confirm the submission since he receives the confirmation URL.=20 This is completely normal. Every co-author can submit a new version. = Sometimes co-authors even regularly talk to each other. I have = co-authored many documents with other people and I had never run into = problems like these before. =20 > 2a. If they have given the authorization, why they needed to do so and = why the editor was not notified; =20 Eran had not published a new version as requested. =20 > 2b. Otherwise, whether the current draft should be considered invalid. >=20 The current draft is valid. It contains the discussed changes and there = may (or likely will) be another version upcoming to address the issue = Julian raised as well.=20 > The current situation is confusing and I hope that the chairs will = give us the answers as soon as possible. I would just hope for more collaboration to get the documents published. = I understand that everyone is busy with other work related matters and = some folks may never become best friends but maybe we could put this = aside for a few weeks and get the document out of the door.=20 Ciao Hannes > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From Michael.Jones@microsoft.com Sun Jun 10 11:38:29 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5361021F8550 for ; Sun, 10 Jun 2012 11:38:29 -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 rmTDHVmfxEyO for ; Sun, 10 Jun 2012 11:38:28 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe003.messaging.microsoft.com [65.55.88.13]) by ietfa.amsl.com (Postfix) with ESMTP id C4E9121F854F for ; Sun, 10 Jun 2012 11:38:25 -0700 (PDT) Received: from mail243-tx2-R.bigfish.com (10.9.14.241) by TX2EHSOBE002.bigfish.com (10.9.40.22) with Microsoft SMTP Server id 14.1.225.23; Sun, 10 Jun 2012 18:37:28 +0000 Received: from mail243-tx2 (localhost [127.0.0.1]) by mail243-tx2-R.bigfish.com (Postfix) with ESMTP id EA86E1F002EC; Sun, 10 Jun 2012 18:37:27 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -27 X-BigFish: VS-27(zz9371I14ffI542Mzz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25hf0ah) Received-SPF: pass (mail243-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail243-tx2 (localhost.localdomain [127.0.0.1]) by mail243-tx2 (MessageSwitch) id 133935344545263_14966; Sun, 10 Jun 2012 18:37:25 +0000 (UTC) Received: from TX2EHSMHS036.bigfish.com (unknown [10.9.14.254]) by mail243-tx2.bigfish.com (Postfix) with ESMTP id F3B0F1380048; Sun, 10 Jun 2012 18:37:24 +0000 (UTC) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS036.bigfish.com (10.9.99.136) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sun, 10 Jun 2012 18:37:24 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.189]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.02.0298.005; Sun, 10 Jun 2012 18:38:20 +0000 From: Mike Jones To: Hannes Tschofenig , "oauth@ietf.org WG (oauth@ietf.org)" Thread-Topic: [OAUTH-WG] New draft process / editor role Thread-Index: Ac1F4i3w3TwHlNAyTkqDNHNxoOvuzABSdnwAAALUIGA= Date: Sun, 10 Jun 2012 18:38:19 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436653131D@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <0CBAEB56DDB3A140BA8E8C124C04ECA201068743@P3PWEX2MB008.ex2.secureserver.net> <2E3D9844-8F6E-48F3-B386-2E437C522B7D@gmx.net> In-Reply-To: <2E3D9844-8F6E-48F3-B386-2E437C522B7D@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.34] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: Julian Reschke Subject: Re: [OAUTH-WG] New draft process / editor role X-BeenThere: oauth@ietf.org X-Mailman-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, 10 Jun 2012 18:38:29 -0000 About Julian's issue raised at http://www.ietf.org/mail-archive/web/oauth/c= urrent/msg09164.html, please see my message to him and the working group "[= OAUTH-WG] Discussion needed on username and password ABNF definitions" at h= ttp://www.ietf.org/mail-archive/web/oauth/current/msg09171.html. In it, I = request that Julian provide specific proposed text changes to -27 to extend= the appropriate parameters to be able to encode non-ASCII characters in a = way that doesn't violate constraints of the other specs used. If this is p= ossible, I suspect that the working group would be open to it. Best wishes, -- Mike -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of H= annes Tschofenig Sent: Sunday, June 10, 2012 10:11 AM To: Eran Hammer; oauth@ietf.org WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] New draft process / editor role Hi Eran, Hi all,=20 The story is fairly simple: We have three authors on draft-ietf-oauth-v2. H= aving more than one author is helpful in case others are busy. We had open issues with the document and we discussed them on the list. Tex= t was proposed and feedback was provided to the list. Thanks everyone for p= roviding constructive input.=20 The step that happens afterwards is to create a new snapshot of the documen= t. This helps everyone to know what the latest status is (in case you are n= ot following all the mail discussions). We are also able to let IESG member= s to clear their DISCUSSes.=20 All this work helps us to get closer to completion and I believe we are get= ting closer. Unfortunately, there is still one other issue that Julian rais= ed after the ABNF text was published, see http://www.ietf.org/mail-archive/= web/oauth/current/msg09164.html. I am planning to distribute a separate mai= l to raise awareness and to solicit feedback.=20 We are in the final stages of getting the document published. It would be g= reat if everyone works together to get the work done as quickly as possible= . Is this possible? Ciao Hannes _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From julian.reschke@gmx.de Sun Jun 10 11:39:23 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31AD521F8555 for ; Sun, 10 Jun 2012 11:39:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=-4.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RBKnsw66gHrI for ; Sun, 10 Jun 2012 11:39:22 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 3DFD721F8550 for ; Sun, 10 Jun 2012 11:39:22 -0700 (PDT) Received: (qmail invoked by alias); 10 Jun 2012 18:39:21 -0000 Received: from p5DD95838.dip.t-dialin.net (EHLO [192.168.178.36]) [93.217.88.56] by mail.gmx.net (mp004) with SMTP; 10 Jun 2012 20:39:21 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX189u9A7TNo9I/VtIwrab+p0iu1Ys+gpXYlIbZQ7ln OOaZ+NzS00wrPW Message-ID: <4FD4E9D4.2010808@gmx.de> Date: Sun, 10 Jun 2012 20:39:16 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120604 Thunderbird/13.0 MIME-Version: 1.0 To: Mike Jones References: <4E1F6AAD24975D4BA5B16804296739436652F52D@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436652F52D@TK5EX14MBXC284.redmond.corp.microsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions X-BeenThere: oauth@ietf.org X-Mailman-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, 10 Jun 2012 18:39:23 -0000 On 2012-06-08 20:09, Mike Jones wrote: > Hi Julian, > > The current draft restricts username and password to ASCII was because RFC 2616 says this about the TEXT fields used by HTTP Basic in RFC 2617: > "Words of *TEXT MAY contain characters from character sets other than > ISO-8859-1 [22] only when encoded according to the rules of > RFC 2047 [14]." > > Given that RFC 2047 MIME encodings aren't possible in this context, that you wrote that "If you define new protocol elements, either restrict them to US-ASCII, or find a way to encode all of Unicode", and you and Peter St. Andre wrote that using ISO-8859-1 is a non-starter, that seemed to leave ASCII as the only available choice. The other choice was "find a way to encode all of Unicode". The way to do this usually is to use UTF-8. That doesn't work with Basic and Digest, but we shouldn't extend this problem to anything new we define. > If you have an alternative proposal for encoding all of Unicode for username and password, I'd appreciate if you could propose specific text changes to -27 to accomplish them. I'd be fine with doing that, but didn't know how to satisfy all the constraints above for Unicode characters. Draft -27 is now available at http://tools.ietf.org/html/draft-ietf-oauth-v2-27. > ... I haven't looked at the core OAuth spec. The right answer depends on where you use these protocol elements. Changing this into a question to the WG: is it acceptable to restrict all of these protocol elements to US-ASCII? Best regards, Julian From Michael.Jones@microsoft.com Sun Jun 10 11:50:18 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E797421F8554 for ; Sun, 10 Jun 2012 11:50:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0gGIl6+4TDhE for ; Sun, 10 Jun 2012 11:50:18 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe002.messaging.microsoft.com [213.199.154.205]) by ietfa.amsl.com (Postfix) with ESMTP id E342821F8551 for ; Sun, 10 Jun 2012 11:50:17 -0700 (PDT) Received: from mail54-am1-R.bigfish.com (10.3.201.251) by AM1EHSOBE002.bigfish.com (10.3.204.22) with Microsoft SMTP Server id 14.1.225.23; Sun, 10 Jun 2012 18:49:20 +0000 Received: from mail54-am1 (localhost [127.0.0.1]) by mail54-am1-R.bigfish.com (Postfix) with ESMTP id 90E1D18035C; Sun, 10 Jun 2012 18:49:19 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -36 X-BigFish: VS-36(zz98dI9371I936eIc3f2M542M1dbaI1432I4015Izz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25hf0ah) Received-SPF: pass (mail54-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC107.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail54-am1 (localhost.localdomain [127.0.0.1]) by mail54-am1 (MessageSwitch) id 1339354157966350_32210; Sun, 10 Jun 2012 18:49:17 +0000 (UTC) Received: from AM1EHSMHS001.bigfish.com (unknown [10.3.201.231]) by mail54-am1.bigfish.com (Postfix) with ESMTP id E0880360048; Sun, 10 Jun 2012 18:49:17 +0000 (UTC) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS001.bigfish.com (10.3.207.101) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sun, 10 Jun 2012 18:49:17 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.189]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.02.0309.003; Sun, 10 Jun 2012 18:50:12 +0000 From: Mike Jones To: Julian Reschke Thread-Topic: Discussion needed on username and password ABNF definitions Thread-Index: Ac1FodQD2X6ejXtzRTyOfL/3OPr81wBloKQAAAAZzsA= Date: Sun, 10 Jun 2012 18:50:11 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366531375@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739436652F52D@TK5EX14MBXC284.redmond.corp.microsoft.com> <4FD4E9D4.2010808@gmx.de> In-Reply-To: <4FD4E9D4.2010808@gmx.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.34] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions X-BeenThere: oauth@ietf.org X-Mailman-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, 10 Jun 2012 18:50:19 -0000 Thanks for your reply, Julian. Given that, as you confirmed, UTF-8 "doesn't work with Basic and Digest", a= nd they're required to be used with Basic, I believe that that confirms tha= t username and password must either be ASCII or ISO-8859-1, and given that = several people have written that ISO-8859-1 is a "non-starter", that effect= ively confirms the current syntax in -27 that username and password must be= ASCII. Do you agree or am I missing a nuance here? Julian, there was one aspect of the open issue that you didn't reply to: D= o you have an opinion on whether client_id and client_secret should be rest= ricted to the same characters as username and password? This seems logical= to me, as they are objects of the same kind as username and password, but = I also sympathize with your sentiment that "we shouldn't extend this proble= m to anything new we define". On the other hand, given that client_id and = client_secret are for machine (and not for human) consumption, I don't see = any more need for internationalization of these fields than there was for s= cope (which the working group decided to limit to ASCII). Julian, what do you think? Working group, what do you think? Thanks, -- Mike -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de]=20 Sent: Sunday, June 10, 2012 11:39 AM To: Mike Jones Cc: oauth@ietf.org Subject: Re: Discussion needed on username and password ABNF definitions On 2012-06-08 20:09, Mike Jones wrote: > Hi Julian, > > The current draft restricts username and password to ASCII was because RF= C 2616 says this about the TEXT fields used by HTTP Basic in RFC 2617: > "Words of *TEXT MAY contain characters from character sets other than > ISO-8859-1 [22] only when encoded according to the rules of > RFC 2047 [14]." > > Given that RFC 2047 MIME encodings aren't possible in this context, that = you wrote that "If you define new protocol elements, either restrict them t= o US-ASCII, or find a way to encode all of Unicode", and you and Peter St. = Andre wrote that using ISO-8859-1 is a non-starter, that seemed to leave AS= CII as the only available choice. The other choice was "find a way to encode all of Unicode". The way to do t= his usually is to use UTF-8. That doesn't work with Basic and Digest, but w= e shouldn't extend this problem to anything new we define. > If you have an alternative proposal for encoding all of Unicode for usern= ame and password, I'd appreciate if you could propose specific text changes= to -27 to accomplish them. I'd be fine with doing that, but didn't know h= ow to satisfy all the constraints above for Unicode characters. Draft -27 = is now available at http://tools.ietf.org/html/draft-ietf-oauth-v2-27. > ... I haven't looked at the core OAuth spec. The right answer depends on where = you use these protocol elements. Changing this into a question to the WG: is it acceptable to restrict all o= f these protocol elements to US-ASCII? Best regards, Julian From phil.hunt@oracle.com Sun Jun 10 12:06:40 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3018A21F8557 for ; Sun, 10 Jun 2012 12:06:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ilufcV2R0yvX for ; Sun, 10 Jun 2012 12:06:39 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id DFB7B21F853C for ; Sun, 10 Jun 2012 12:06:38 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q5AJ6ZVf024851 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 10 Jun 2012 19:06:36 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q5AJ6Yib002753 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 10 Jun 2012 19:06:35 GMT Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q5AJ6YBX027279; Sun, 10 Jun 2012 14:06:34 -0500 Received: from [192.168.1.7] (/24.87.212.4) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 10 Jun 2012 12:06:34 -0700 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Phil Hunt In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366531375@TK5EX14MBXC284.redmond.corp.microsoft.com> Date: Sun, 10 Jun 2012 12:06:36 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <50E22E60-6E83-45F8-8355-8C918A9637D1@oracle.com> References: <4E1F6AAD24975D4BA5B16804296739436652F52D@TK5EX14MBXC284.redmond.corp.microsoft.com> <4FD4E9D4.2010808@gmx.de> <4E1F6AAD24975D4BA5B168042967394366531375@TK5EX14MBXC284.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1278) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: Julian Reschke , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions X-BeenThere: oauth@ietf.org X-Mailman-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, 10 Jun 2012 19:06:40 -0000 Isn't the nuance that Basic and Digest should be able to be passed = through OAuth? Or is there a secondary requirement that uid/passwords = forms in OAuth be re-encodable to Basic? So while "UTF-8 may not work with Basic and Digest" is that a valid = concern? =20 I think our concern should be limited to "Basic and Digest working = within OAuth".=20 Am I missing something? Phil @independentid www.independentid.com phil.hunt@oracle.com On 2012-06-10, at 11:50 AM, Mike Jones wrote: > Thanks for your reply, Julian. >=20 > Given that, as you confirmed, UTF-8 "doesn't work with Basic and = Digest", and they're required to be used with Basic, I believe that that = confirms that username and password must either be ASCII or ISO-8859-1, = and given that several people have written that ISO-8859-1 is a = "non-starter", that effectively confirms the current syntax in -27 that = username and password must be ASCII. Do you agree or am I missing a = nuance here? >=20 > Julian, there was one aspect of the open issue that you didn't reply = to: Do you have an opinion on whether client_id and client_secret = should be restricted to the same characters as username and password? = This seems logical to me, as they are objects of the same kind as = username and password, but I also sympathize with your sentiment that = "we shouldn't extend this problem to anything new we define". On the = other hand, given that client_id and client_secret are for machine (and = not for human) consumption, I don't see any more need for = internationalization of these fields than there was for scope (which the = working group decided to limit to ASCII). >=20 > Julian, what do you think? Working group, what do you think? >=20 > Thanks, > -- Mike >=20 > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de]=20 > Sent: Sunday, June 10, 2012 11:39 AM > To: Mike Jones > Cc: oauth@ietf.org > Subject: Re: Discussion needed on username and password ABNF = definitions >=20 > On 2012-06-08 20:09, Mike Jones wrote: >> Hi Julian, >>=20 >> The current draft restricts username and password to ASCII was = because RFC 2616 says this about the TEXT fields used by HTTP Basic in = RFC 2617: >> "Words of *TEXT MAY contain characters from character sets other = than >> ISO-8859-1 [22] only when encoded according to the rules of >> RFC 2047 [14]." >>=20 >> Given that RFC 2047 MIME encodings aren't possible in this context, = that you wrote that "If you define new protocol elements, either = restrict them to US-ASCII, or find a way to encode all of Unicode", and = you and Peter St. Andre wrote that using ISO-8859-1 is a non-starter, = that seemed to leave ASCII as the only available choice. >=20 > The other choice was "find a way to encode all of Unicode". The way to = do this usually is to use UTF-8. That doesn't work with Basic and = Digest, but we shouldn't extend this problem to anything new we define. >=20 >> If you have an alternative proposal for encoding all of Unicode for = username and password, I'd appreciate if you could propose specific text = changes to -27 to accomplish them. I'd be fine with doing that, but = didn't know how to satisfy all the constraints above for Unicode = characters. Draft -27 is now available at = http://tools.ietf.org/html/draft-ietf-oauth-v2-27. >> ... >=20 > I haven't looked at the core OAuth spec. The right answer depends on = where you use these protocol elements. >=20 > Changing this into a question to the WG: is it acceptable to restrict = all of these protocol elements to US-ASCII? >=20 > Best regards, Julian >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From Michael.Jones@microsoft.com Sun Jun 10 12:25:28 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4CE721F8435 for ; Sun, 10 Jun 2012 12:25:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.349 X-Spam-Level: X-Spam-Status: No, score=-4.349 tagged_above=-999 required=5 tests=[AWL=-0.750, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oQOSRSKCh916 for ; Sun, 10 Jun 2012 12:25:28 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe002.messaging.microsoft.com [213.199.154.140]) by ietfa.amsl.com (Postfix) with ESMTP id B1BF621F842B for ; Sun, 10 Jun 2012 12:25:27 -0700 (PDT) Received: from mail29-db3-R.bigfish.com (10.3.81.243) by DB3EHSOBE003.bigfish.com (10.3.84.23) with Microsoft SMTP Server id 14.1.225.23; Sun, 10 Jun 2012 19:24:29 +0000 Received: from mail29-db3 (localhost [127.0.0.1]) by mail29-db3-R.bigfish.com (Postfix) with ESMTP id A1C73E0429; Sun, 10 Jun 2012 19:24:29 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC106.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -36 X-BigFish: VS-36(zz98dI9371I936eIc3f2M542M1dbaI1432I4015Izz1202hzz1033IL8275bh8275dhz2fh2a8h668h839h944hd25hf0ah) Received-SPF: pass (mail29-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC106.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail29-db3 (localhost.localdomain [127.0.0.1]) by mail29-db3 (MessageSwitch) id 1339356266910131_25156; Sun, 10 Jun 2012 19:24:26 +0000 (UTC) Received: from DB3EHSMHS017.bigfish.com (unknown [10.3.81.244]) by mail29-db3.bigfish.com (Postfix) with ESMTP id D2B15180245; Sun, 10 Jun 2012 19:24:26 +0000 (UTC) Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS017.bigfish.com (10.3.87.117) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sun, 10 Jun 2012 19:24:26 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.189]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.02.0309.003; Sun, 10 Jun 2012 19:25:13 +0000 From: Mike Jones To: Phil Hunt Thread-Topic: [OAUTH-WG] Discussion needed on username and password ABNF definitions Thread-Index: Ac1FodQD2X6ejXtzRTyOfL/3OPr81wBloKQAAAAZzsAAANqTAAAALarA Date: Sun, 10 Jun 2012 19:25:12 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943665315C7@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739436652F52D@TK5EX14MBXC284.redmond.corp.microsoft.com> <4FD4E9D4.2010808@gmx.de> <4E1F6AAD24975D4BA5B168042967394366531375@TK5EX14MBXC284.redmond.corp.microsoft.com> <50E22E60-6E83-45F8-8355-8C918A9637D1@oracle.com> In-Reply-To: <50E22E60-6E83-45F8-8355-8C918A9637D1@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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: Julian Reschke , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions X-BeenThere: oauth@ietf.org X-Mailman-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, 10 Jun 2012 19:25:29 -0000 2.3.1 of Core http://tools.ietf.org/html/draft-ietf-oauth-v2-27#section-2.3= .1 requires support for HTTP Basic. Actually, in this context, it's requir= ing support for using Basic with client_id and client_secret, therefore I b= elieve those must be restricted to ASCII, as (per Julian's note), UTF-8 doe= s not work with HTTP Basic. Per your question about "Basic and Digest working within OAuth", since thes= e are separately specified by RFC 2617, I believe we are bound by the const= raints in that specification (hence this discussion). Best wishes, -- Mike P.S. In re-reading the relevant portions of the draft, I discovered that i= n A.1, A.2, and A.16 the parenthetical text currently reads "This matches t= he ... definition in the HTTP Basic Authentication Scheme [RFC2617]". This= was an editorial error, as all of these places should instead read the sam= e as A.15 which says "This is compatible with the ... definition in the HTT= P Basic Authentication Scheme [RFC2617]" (changing the word "matches" to "i= s compatible"). This explains one of Julian's remarks, which had previousl= y puzzled me. ;-) -----Original Message----- From: Phil Hunt [mailto:phil.hunt@oracle.com]=20 Sent: Sunday, June 10, 2012 12:07 PM To: Mike Jones Cc: Julian Reschke; oauth@ietf.org Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF def= initions Isn't the nuance that Basic and Digest should be able to be passed through = OAuth? Or is there a secondary requirement that uid/passwords forms in OAu= th be re-encodable to Basic? So while "UTF-8 may not work with Basic and Digest" is that a valid concern= ? =20 I think our concern should be limited to "Basic and Digest working within O= Auth".=20 Am I missing something? Phil @independentid www.independentid.com phil.hunt@oracle.com On 2012-06-10, at 11:50 AM, Mike Jones wrote: > Thanks for your reply, Julian. >=20 > Given that, as you confirmed, UTF-8 "doesn't work with Basic and Digest",= and they're required to be used with Basic, I believe that that confirms t= hat username and password must either be ASCII or ISO-8859-1, and given tha= t several people have written that ISO-8859-1 is a "non-starter", that effe= ctively confirms the current syntax in -27 that username and password must = be ASCII. Do you agree or am I missing a nuance here? >=20 > Julian, there was one aspect of the open issue that you didn't reply to: = Do you have an opinion on whether client_id and client_secret should be re= stricted to the same characters as username and password? This seems logic= al to me, as they are objects of the same kind as username and password, bu= t I also sympathize with your sentiment that "we shouldn't extend this prob= lem to anything new we define". On the other hand, given that client_id an= d client_secret are for machine (and not for human) consumption, I don't se= e any more need for internationalization of these fields than there was for= scope (which the working group decided to limit to ASCII). >=20 > Julian, what do you think? Working group, what do you think? >=20 > Thanks, > -- Mike >=20 > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de]=20 > Sent: Sunday, June 10, 2012 11:39 AM > To: Mike Jones > Cc: oauth@ietf.org > Subject: Re: Discussion needed on username and password ABNF definitions >=20 > On 2012-06-08 20:09, Mike Jones wrote: >> Hi Julian, >>=20 >> The current draft restricts username and password to ASCII was because R= FC 2616 says this about the TEXT fields used by HTTP Basic in RFC 2617: >> "Words of *TEXT MAY contain characters from character sets other than >> ISO-8859-1 [22] only when encoded according to the rules of >> RFC 2047 [14]." >>=20 >> Given that RFC 2047 MIME encodings aren't possible in this context, that= you wrote that "If you define new protocol elements, either restrict them = to US-ASCII, or find a way to encode all of Unicode", and you and Peter St.= Andre wrote that using ISO-8859-1 is a non-starter, that seemed to leave A= SCII as the only available choice. >=20 > The other choice was "find a way to encode all of Unicode". The way to do= this usually is to use UTF-8. That doesn't work with Basic and Digest, but= we shouldn't extend this problem to anything new we define. >=20 >> If you have an alternative proposal for encoding all of Unicode for user= name and password, I'd appreciate if you could propose specific text change= s to -27 to accomplish them. I'd be fine with doing that, but didn't know = how to satisfy all the constraints above for Unicode characters. Draft -27= is now available at http://tools.ietf.org/html/draft-ietf-oauth-v2-27. >> ... >=20 > I haven't looked at the core OAuth spec. The right answer depends on wher= e you use these protocol elements. >=20 > Changing this into a question to the WG: is it acceptable to restrict all= of these protocol elements to US-ASCII? >=20 > Best regards, Julian >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From ve7jtb@ve7jtb.com Sun Jun 10 12:27:46 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02FC221F844A for ; Sun, 10 Jun 2012 12:27:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YEC-mOHm+C59 for ; Sun, 10 Jun 2012 12:27:45 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id DA31321F8445 for ; Sun, 10 Jun 2012 12:27:44 -0700 (PDT) Received: by wibhn6 with SMTP id hn6so1802361wib.13 for ; Sun, 10 Jun 2012 12:27:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=nacjv4CWlJ6QFYVLeBOAmmljqvkbffbSU1dsCvMFceg=; b=a7FiCkPf1wst/tBIPKFqzkSfuTH1ADsO0PlkLFxAHeyIMxrnjRvxCSax8OLPvCnxFp JqIlCzPoPtfdLvSrI9VHR0Xf3S4lKBWdpapdgJmvYQJ1hjMAUES26/nXNu0jGzXRz+BQ 0LxJySXsUmqo2PFqljl+oZ8goTt2H6gl2h3sggoLa0e3y9VZKtj5arrH3ahMmpuM3rVG FpWRwy4bNxA8937fMJbFOLtwkzyg7zAy1ddiQEvrhD/+Rr69KeIFPsxc9sTWKW7EVeJz bKbaiGf4GafKt5YtEBAtTp8sBBXnMOfHhmtGLHWqt58gMakPqhErLcdE3BgiCpqDRuFH 3+wg== Received: by 10.180.98.231 with SMTP id el7mr15197879wib.21.1339356463874; Sun, 10 Jun 2012 12:27:43 -0700 (PDT) Received: from [10.0.0.27] (host-92-27-146-217.static.as13285.net. [92.27.146.217]) by mx.google.com with ESMTPS id ch9sm30187625wib.8.2012.06.10.12.27.41 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 10 Jun 2012 12:27:43 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: John Bradley In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366531375@TK5EX14MBXC284.redmond.corp.microsoft.com> Date: Sun, 10 Jun 2012 20:27:30 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1F47BAB6-75C5-4E11-8515-24E356CFCB50@ve7jtb.com> References: <4E1F6AAD24975D4BA5B16804296739436652F52D@TK5EX14MBXC284.redmond.corp.microsoft.com> <4FD4E9D4.2010808@gmx.de> <4E1F6AAD24975D4BA5B168042967394366531375@TK5EX14MBXC284.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQk5gtekKzAjZf/b8aO2lMmGIPtdO3deryq64cgPAw4YkmsyHbhYBGWe5xIqnu3ncrSDCpxV Cc: Julian Reschke , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions X-BeenThere: oauth@ietf.org X-Mailman-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, 10 Jun 2012 19:27:46 -0000 I think once the WG decided that client_id and client_secret need to be = passed as the username and password for HTTP Basic authentication of the = client to the Token Endpoint, the Die was cast for those elements to = have the same character restrictions. In principal you could use the assertion profile or some other mechanism = to authenticate the client, and avoid needing the restriction. However = as this is only intended to be machine readable it is probably better to = be consistent with the ABNF rather than different ones per = authentication method. So I think we are back to ASCII for the client_id and client_secret. John B. On 2012-06-10, at 7:50 PM, Mike Jones wrote: > Thanks for your reply, Julian. >=20 > Given that, as you confirmed, UTF-8 "doesn't work with Basic and = Digest", and they're required to be used with Basic, I believe that that = confirms that username and password must either be ASCII or ISO-8859-1, = and given that several people have written that ISO-8859-1 is a = "non-starter", that effectively confirms the current syntax in -27 that = username and password must be ASCII. Do you agree or am I missing a = nuance here? >=20 > Julian, there was one aspect of the open issue that you didn't reply = to: Do you have an opinion on whether client_id and client_secret = should be restricted to the same characters as username and password? = This seems logical to me, as they are objects of the same kind as = username and password, but I also sympathize with your sentiment that = "we shouldn't extend this problem to anything new we define". On the = other hand, given that client_id and client_secret are for machine (and = not for human) consumption, I don't see any more need for = internationalization of these fields than there was for scope (which the = working group decided to limit to ASCII). >=20 > Julian, what do you think? Working group, what do you think? >=20 > Thanks, > -- Mike >=20 > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de]=20 > Sent: Sunday, June 10, 2012 11:39 AM > To: Mike Jones > Cc: oauth@ietf.org > Subject: Re: Discussion needed on username and password ABNF = definitions >=20 > On 2012-06-08 20:09, Mike Jones wrote: >> Hi Julian, >>=20 >> The current draft restricts username and password to ASCII was = because RFC 2616 says this about the TEXT fields used by HTTP Basic in = RFC 2617: >> "Words of *TEXT MAY contain characters from character sets other = than >> ISO-8859-1 [22] only when encoded according to the rules of >> RFC 2047 [14]." >>=20 >> Given that RFC 2047 MIME encodings aren't possible in this context, = that you wrote that "If you define new protocol elements, either = restrict them to US-ASCII, or find a way to encode all of Unicode", and = you and Peter St. Andre wrote that using ISO-8859-1 is a non-starter, = that seemed to leave ASCII as the only available choice. >=20 > The other choice was "find a way to encode all of Unicode". The way to = do this usually is to use UTF-8. That doesn't work with Basic and = Digest, but we shouldn't extend this problem to anything new we define. >=20 >> If you have an alternative proposal for encoding all of Unicode for = username and password, I'd appreciate if you could propose specific text = changes to -27 to accomplish them. I'd be fine with doing that, but = didn't know how to satisfy all the constraints above for Unicode = characters. Draft -27 is now available at = http://tools.ietf.org/html/draft-ietf-oauth-v2-27. >> ... >=20 > I haven't looked at the core OAuth spec. The right answer depends on = where you use these protocol elements. >=20 > Changing this into a question to the WG: is it acceptable to restrict = all of these protocol elements to US-ASCII? >=20 > Best regards, Julian >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From julian.reschke@gmx.de Sun Jun 10 12:46:04 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDFD721F8539 for ; Sun, 10 Jun 2012 12:46:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, 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 uoJ9gpXE7Ago for ; Sun, 10 Jun 2012 12:46:04 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id E33BF21F8535 for ; Sun, 10 Jun 2012 12:46:03 -0700 (PDT) Received: (qmail invoked by alias); 10 Jun 2012 19:46:02 -0000 Received: from p5DD95838.dip.t-dialin.net (EHLO [192.168.178.36]) [93.217.88.56] by mail.gmx.net (mp072) with SMTP; 10 Jun 2012 21:46:02 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19g9N0AISNgUOZqWAU5vCpf6FVCaTJF+hwNRTQjQA Juvk4hN/9zO7AK Message-ID: <4FD4F976.6090801@gmx.de> Date: Sun, 10 Jun 2012 21:45:58 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120604 Thunderbird/13.0 MIME-Version: 1.0 To: Mike Jones References: <4E1F6AAD24975D4BA5B16804296739436652F52D@TK5EX14MBXC284.redmond.corp.microsoft.com> <4FD4E9D4.2010808@gmx.de> <4E1F6AAD24975D4BA5B168042967394366531375@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366531375@TK5EX14MBXC284.redmond.corp.microsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions X-BeenThere: oauth@ietf.org X-Mailman-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, 10 Jun 2012 19:46:05 -0000 On 2012-06-10 20:50, Mike Jones wrote: > Thanks for your reply, Julian. > > Given that, as you confirmed, UTF-8 "doesn't work with Basic and Digest", and they're required to be used with Basic, I believe that that confirms that username and password must either be ASCII or ISO-8859-1, and given that several people have written that ISO-8859-1 is a "non-starter", that effectively confirms the current syntax in -27 that username and password must be ASCII. Do you agree or am I missing a nuance here? I don't understand OAuth enough to know whether a constraint of Basic and Digest should affect OAuth in general. Also, we actually might be able to *fix* these schemes, in which case it would be unfortunate if OAuth adopted the constraint in a way that makes it hard to update. I believe the right thing to do is not to have a special ABNF; but instead to just note that when these protocol elements need to be used with Basic or Digest, the respective constraints of these schemes apply. > Julian, there was one aspect of the open issue that you didn't reply to: Do you have an opinion on whether client_id and client_secret should be restricted to the same characters as username and password? This seems logical to me, as they are objects of the same kind as username and password, but I also sympathize with your sentiment that "we shouldn't extend this problem to anything new we define". On the other hand, given that client_id and client_secret are for machine (and not for human) consumption, I don't see any more need for internationalization of these fields than there was for scope (which the working group decided to limit to ASCII). I'll leave that to the WG :-) Best regards, Julian From Michael.Jones@microsoft.com Sun Jun 10 12:56:06 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEDA221F850D for ; Sun, 10 Jun 2012 12:56:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.099 X-Spam-Level: X-Spam-Status: No, score=-4.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rifQqEWSi-LB for ; Sun, 10 Jun 2012 12:56:06 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe004.messaging.microsoft.com [213.199.154.142]) by ietfa.amsl.com (Postfix) with ESMTP id 9C8B921F8440 for ; Sun, 10 Jun 2012 12:56:05 -0700 (PDT) Received: from mail83-db3-R.bigfish.com (10.3.81.245) by DB3EHSOBE001.bigfish.com (10.3.84.21) with Microsoft SMTP Server id 14.1.225.23; Sun, 10 Jun 2012 19:55:07 +0000 Received: from mail83-db3 (localhost [127.0.0.1]) by mail83-db3-R.bigfish.com (Postfix) with ESMTP id 7E59D2039A; Sun, 10 Jun 2012 19:55:07 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC106.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -29 X-BigFish: VS-29(zz98dI9371I936eI542M1432Izz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25hf0ah) Received-SPF: pass (mail83-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC106.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail83-db3 (localhost.localdomain [127.0.0.1]) by mail83-db3 (MessageSwitch) id 1339358105768151_13224; Sun, 10 Jun 2012 19:55:05 +0000 (UTC) Received: from DB3EHSMHS006.bigfish.com (unknown [10.3.81.228]) by mail83-db3.bigfish.com (Postfix) with ESMTP id B0249420042; Sun, 10 Jun 2012 19:55:05 +0000 (UTC) Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS006.bigfish.com (10.3.87.106) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sun, 10 Jun 2012 19:55:05 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.189]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.02.0309.003; Sun, 10 Jun 2012 19:55:57 +0000 From: Mike Jones To: Julian Reschke Thread-Topic: Discussion needed on username and password ABNF definitions Thread-Index: Ac1FodQD2X6ejXtzRTyOfL/3OPr81wBloKQAAAAZzsAAAjqKAAAANTaQ Date: Sun, 10 Jun 2012 19:55:57 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943665316D1@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739436652F52D@TK5EX14MBXC284.redmond.corp.microsoft.com> <4FD4E9D4.2010808@gmx.de> <4E1F6AAD24975D4BA5B168042967394366531375@TK5EX14MBXC284.redmond.corp.microsoft.com> <4FD4F976.6090801@gmx.de> In-Reply-To: <4FD4F976.6090801@gmx.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.34] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions X-BeenThere: oauth@ietf.org X-Mailman-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, 10 Jun 2012 19:56:06 -0000 Hi Julian, As background, the reason for the special ABNF is to satisfy a DISCUSS rais= ed by Sean Turner specifically that specifically requested a comprehensive = ABNF. I believe that these very discussions show how valuable Sean's reque= st is to improving the clarity of the spec for implementer's, as even some = experts on the list hadn't completely worked through syntax consequences of= the dependent specs used, whereas as the ABNF makes the syntax restriction= s obvious. I believe this has improved the clarity of the spec and likely = improved interoperability of implementations because of it. Best wishes, -- Mike -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de]=20 Sent: Sunday, June 10, 2012 12:46 PM To: Mike Jones Cc: oauth@ietf.org Subject: Re: Discussion needed on username and password ABNF definitions On 2012-06-10 20:50, Mike Jones wrote: > Thanks for your reply, Julian. > > Given that, as you confirmed, UTF-8 "doesn't work with Basic and Digest",= and they're required to be used with Basic, I believe that that confirms t= hat username and password must either be ASCII or ISO-8859-1, and given tha= t several people have written that ISO-8859-1 is a "non-starter", that effe= ctively confirms the current syntax in -27 that username and password must = be ASCII. Do you agree or am I missing a nuance here? I don't understand OAuth enough to know whether a constraint of Basic and D= igest should affect OAuth in general. Also, we actually might be able to *fix* these schemes, in which case it wo= uld be unfortunate if OAuth adopted the constraint in a way that makes it h= ard to update. I believe the right thing to do is not to have a special ABNF; but instead = to just note that when these protocol elements need to be used with Basic o= r Digest, the respective constraints of these schemes apply. > Julian, there was one aspect of the open issue that you didn't reply to: = Do you have an opinion on whether client_id and client_secret should be re= stricted to the same characters as username and password? This seems logic= al to me, as they are objects of the same kind as username and password, bu= t I also sympathize with your sentiment that "we shouldn't extend this prob= lem to anything new we define". On the other hand, given that client_id an= d client_secret are for machine (and not for human) consumption, I don't se= e any more need for internationalization of these fields than there was for= scope (which the working group decided to limit to ASCII). I'll leave that to the WG :-) Best regards, Julian From ve7jtb@ve7jtb.com Sun Jun 10 13:40:46 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E918321F8522 for ; Sun, 10 Jun 2012 13:40:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.001, 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 4Qk4a-kcIiVF for ; Sun, 10 Jun 2012 13:40:46 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id B562821F84A7 for ; Sun, 10 Jun 2012 13:40:45 -0700 (PDT) Received: by wibhn6 with SMTP id hn6so1831804wib.13 for ; Sun, 10 Jun 2012 13:40:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=uC1WQCZfGPrizPkEjG7+vKI+yHENBSJEwKnekqL/O5Y=; b=VtNmUVZGh4ToXmBV8XnSrYyu0BO2+hPgOqA2dSwOH+xGKCkKSWmOaAvURTppoJX1/m B7rnox/lyTH9/jadZ82eoUReoAXKPkRQ0zBpivT4FnI0ZFr73dfe4eQNBaCP0lLajcbO HwdtUBVsNKIwJmBefLeHcYK6UVi2hHVlh2ixW+vordfFgpiye4dFA5KWaeYbaa0UK2t3 P4O5qy+JBJg/uKWU7HNQuRr99VKPr1J1FvIvDuhaSEEyGxIsF5ewh2sTDtFMJLi7Uz/t vE/YlGaqraHMwNRbNSPhMMwG35L9huHRU+lr3iPHQ9tDM3dGMSOvPF3OCz7tT/4IWUQd Evpg== Received: by 10.180.94.8 with SMTP id cy8mr15456159wib.11.1339360844858; Sun, 10 Jun 2012 13:40:44 -0700 (PDT) Received: from [10.0.0.27] (host-92-27-146-217.static.as13285.net. [92.27.146.217]) by mx.google.com with ESMTPS id gb9sm19413428wib.8.2012.06.10.13.40.43 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 10 Jun 2012 13:40:44 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_7F09C434-01B9-4804-964B-3A215C543AD2" From: John Bradley In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943665316D1@TK5EX14MBXC284.redmond.corp.microsoft.com> Date: Sun, 10 Jun 2012 21:40:41 +0100 Message-Id: <60F5CCB0-E036-4351-BD10-A44B33FCC5F6@ve7jtb.com> References: <4E1F6AAD24975D4BA5B16804296739436652F52D@TK5EX14MBXC284.redmond.corp.microsoft.com> <4FD4E9D4.2010808@gmx.de> <4E1F6AAD24975D4BA5B168042967394366531375@TK5EX14MBXC284.redmond.corp.microsoft.com> <4FD4F976.6090801@gmx.de> <4E1F6AAD24975D4BA5B1680429673943665316D1@TK5EX14MBXC284.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQlTnBLAwnH7iF8S0aC5i2Luin2zvS1a7BJccyacYiB4w535u6GXNb9qLDdQ3PqtK1BQwNge Cc: Julian Reschke , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions X-BeenThere: oauth@ietf.org X-Mailman-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, 10 Jun 2012 20:40:47 -0000 --Apple-Mail=_7F09C434-01B9-4804-964B-3A215C543AD2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii So we have two competing good ideas. 1 include an ABNF directly and codify what is expected to to work at the = cost of flexibility. 2 Reference RFC 2617 itself referencing RFC 2616 to allow for a future = fix to the encoding limitations to be automatically picked up by OAuth = if RFC 2617 is updated. =20 My observation is that if we are having a hard time deciding this, a = developer is going to as well. My vote is for directly including the ABNF. I also want to note that I think the ABNF for client-id is wrong. It should exclude ":". Colon is used as a field separator by Basic (god = help us) if you allow it it will blow up parsing. =20 * That is probably the most important thing I realized in this exercise. On 2012-06-10, at 8:55 PM, Mike Jones wrote: > Hi Julian, >=20 > As background, the reason for the special ABNF is to satisfy a DISCUSS = raised by Sean Turner specifically that specifically requested a = comprehensive ABNF. I believe that these very discussions show how = valuable Sean's request is to improving the clarity of the spec for = implementer's, as even some experts on the list hadn't completely worked = through syntax consequences of the dependent specs used, whereas as the = ABNF makes the syntax restrictions obvious. I believe this has improved = the clarity of the spec and likely improved interoperability of = implementations because of it. >=20 > Best wishes, > -- Mike >=20 > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de]=20 > Sent: Sunday, June 10, 2012 12:46 PM > To: Mike Jones > Cc: oauth@ietf.org > Subject: Re: Discussion needed on username and password ABNF = definitions >=20 > On 2012-06-10 20:50, Mike Jones wrote: >> Thanks for your reply, Julian. >>=20 >> Given that, as you confirmed, UTF-8 "doesn't work with Basic and = Digest", and they're required to be used with Basic, I believe that that = confirms that username and password must either be ASCII or ISO-8859-1, = and given that several people have written that ISO-8859-1 is a = "non-starter", that effectively confirms the current syntax in -27 that = username and password must be ASCII. Do you agree or am I missing a = nuance here? >=20 > I don't understand OAuth enough to know whether a constraint of Basic = and Digest should affect OAuth in general. >=20 > Also, we actually might be able to *fix* these schemes, in which case = it would be unfortunate if OAuth adopted the constraint in a way that = makes it hard to update. >=20 > I believe the right thing to do is not to have a special ABNF; but = instead to just note that when these protocol elements need to be used = with Basic or Digest, the respective constraints of these schemes apply. >=20 >> Julian, there was one aspect of the open issue that you didn't reply = to: Do you have an opinion on whether client_id and client_secret = should be restricted to the same characters as username and password? = This seems logical to me, as they are objects of the same kind as = username and password, but I also sympathize with your sentiment that = "we shouldn't extend this problem to anything new we define". On the = other hand, given that client_id and client_secret are for machine (and = not for human) consumption, I don't see any more need for = internationalization of these fields than there was for scope (which the = working group decided to limit to ASCII). >=20 > I'll leave that to the WG :-) >=20 > Best regards, Julian >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_7F09C434-01B9-4804-964B-3A215C543AD2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii So we = have two competing good ideas.

1 include an ABNF = directly and codify what is expected to to work at the cost of = flexibility.
2 Reference RFC 2617 itself referencing RFC 2616 = to allow for a future fix to the encoding limitations to be = automatically picked up by OAuth if RFC 2617 is updated. =  

My observation is that if we are having = a hard time deciding this,  a developer is going to as = well.
My vote is for directly including the = ABNF.

I also want to note that I think the ABNF = for client-id is wrong.
It should exclude ":".  Colon is = used as a field separator by Basic (god help us) if you allow it it will = blow up parsing.   

*<TEXT =
excluding =
":">


That is = probably the most important thing I realized in this = exercise.




On 2012-06-10, at 8:55 PM, Mike Jones wrote:

Hi = Julian,

As background, the reason for the special ABNF is to = satisfy a DISCUSS raised by Sean Turner specifically that specifically = requested a comprehensive ABNF.  I believe that these very = discussions show how valuable Sean's request is to improving the clarity = of the spec for implementer's, as even some experts on the list hadn't = completely worked through syntax consequences of the dependent specs = used, whereas as the ABNF makes the syntax restrictions obvious.  I = believe this has improved the clarity of the spec and likely improved = interoperability of implementations because of it.

Best = wishes,
= = = = -- Mike

-----Original Message-----
From: Julian Reschke = [mailto:julian.reschke@gmx.de]
Sent: Sunday, June 10, 2012 12:46 = PM
To: Mike Jones
Cc: oauth@ietf.org
Subject: Re: = Discussion needed on username and password ABNF definitions

On = 2012-06-10 20:50, Mike Jones wrote:
Thanks = for your reply, Julian.

Given that, as = you confirmed, UTF-8 "doesn't work with Basic and Digest", and they're = required to be used with Basic, I believe that that confirms that = username and password must either be ASCII or ISO-8859-1, and given that = several people have written that ISO-8859-1 is a "non-starter", that = effectively confirms the current syntax in -27 that username and = password must be ASCII.  Do you agree or am I missing a nuance = here?

I don't understand OAuth enough to know = whether a constraint of Basic and Digest should affect OAuth in = general.

Also, we actually might be able to *fix* these schemes, = in which case it would be unfortunate if OAuth adopted the constraint in = a way that makes it hard to update.

I believe the right thing to = do is not to have a special ABNF; but instead to just note that when = these protocol elements need to be used with Basic or Digest, the = respective constraints of these schemes apply.

Julian, there was one aspect of the open issue that you = didn't reply to:  Do you have an opinion on whether client_id and = client_secret should be restricted to the same characters as username = and password?  This seems logical to me, as they are objects of the = same kind as username and password, but I also sympathize with your = sentiment that "we shouldn't extend this problem to anything new we = define".  On the other hand, given that client_id and client_secret = are for machine (and not for human) consumption, I don't see any more = need for internationalization of these fields than there was for scope = (which the working group decided to limit to = ASCII).

I'll leave that to the WG :-)

Best = regards, = Julian


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

= --Apple-Mail=_7F09C434-01B9-4804-964B-3A215C543AD2-- From igor.faynberg@alcatel-lucent.com Sun Jun 10 14:25:52 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8FCD21F852B for ; Sun, 10 Jun 2012 14:25:52 -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 ByGU68YKwDV9 for ; Sun, 10 Jun 2012 14:25:52 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id DF37521F8528 for ; Sun, 10 Jun 2012 14:25:51 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id q5ALPovT009222 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sun, 10 Jun 2012 16:25:50 -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 q5ALPoqZ010978 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sun, 10 Jun 2012 16:25:50 -0500 Received: from [135.244.224.46] (faynberg.lra.lucent.com [135.244.224.46]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q5ALPl36014719; Sun, 10 Jun 2012 16:25:49 -0500 (CDT) Message-ID: <4FD510DB.2070907@alcatel-lucent.com> Date: Sun, 10 Jun 2012 17:25:47 -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: <4E1F6AAD24975D4BA5B16804296739436652F47C@TK5EX14MBXC284.redmond.corp.microsoft.com> <3308D14C-E8EA-4580-97B3-779FF5E2AA15@gmail.com> In-Reply-To: <3308D14C-E8EA-4580-97B3-779FF5E2AA15@gmail.com> Content-Type: multipart/alternative; boundary="------------010305000505030003020809" X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: Re: [OAUTH-WG] OAuth Core -27 Published 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: Sun, 10 Jun 2012 21:25:52 -0000 This is a multi-part message in MIME format. --------------010305000505030003020809 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit BRAVO! Igor On 6/8/2012 2:08 PM, Dick Hardt wrote: > > On Jun 8, 2012, at 10:51 AM, Mike Jones wrote: > >> The chairs approved publication of OAuth Core draft -27 today. This >> version is based upon the proposed changes that I’d circulated to the >> working group. Changes are: >> ·Adds character set restrictions for error, error_description, and >> error_uri parameters consistent with the OAuth Bearer spec. >> ·Adds “resource access error response” as an error usage location in >> the OAuth Extensions Error Registry. >> ·Adds an ABNF for all message elements. >> ·Corrects editorial issues identified during review >> There are still potential issues with some ABNF definitions that need >> to be discussed by the working group. I’ll send a separate note >> about that. Nonetheless, the chairs felt that publishing this >> version would be a step in the right direction towards completing the >> Core and Bearer specifications. >> I’ll be publishing an updated Bearer draft shortly that references >> the changes in -27 in ways that should resolve the outstanding >> DISCUSS issues against Bearer. >> Thanks to Dick Hart for publishing the draft. > > s/Dick Hart/Dick Hardt/ > > :) > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------010305000505030003020809 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit BRAVO!

Igor

On 6/8/2012 2:08 PM, Dick Hardt wrote:

On Jun 8, 2012, at 10:51 AM, Mike Jones wrote:

The chairs approved publication of OAuth Core draft -27 today.  This version is based upon the proposed changes that I’d circulated to the working group.  Changes are:
·        Adds character set restrictions for error, error_description, and error_uri parameters consistent with the OAuth Bearer spec.
·        Adds “resource access error response” as an error usage location in the OAuth Extensions Error Registry.
·        Adds an ABNF for all message elements.
·        Corrects editorial issues identified during review
 
There are still potential issues with some ABNF definitions that need to be discussed by the working group.  I’ll send a separate note about that.  Nonetheless, the chairs felt that publishing this version would be a step in the right direction towards completing the Core and Bearer specifications.
 
I’ll be publishing an updated Bearer draft shortly that references the changes in -27 in ways that should resolve the outstanding DISCUSS issues against Bearer.
 
Thanks to Dick Hart for publishing the draft.

s/Dick Hart/Dick Hardt/

:)




_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--------------010305000505030003020809-- From igor.faynberg@alcatel-lucent.com Sun Jun 10 14:28:12 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B75621F8546 for ; Sun, 10 Jun 2012 14:28:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Exk3yZNyrjRJ for ; Sun, 10 Jun 2012 14:28:11 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 8020B21F852B for ; Sun, 10 Jun 2012 14:28:11 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id q5ALS9n6009622 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sun, 10 Jun 2012 16:28:09 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q5ALS8rE031466 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sun, 10 Jun 2012 16:28:09 -0500 Received: from [135.244.224.46] (faynberg.lra.lucent.com [135.244.224.46]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q5ALS7wP015405; Sun, 10 Jun 2012 16:28:07 -0500 (CDT) Message-ID: <4FD51166.5080405@alcatel-lucent.com> Date: Sun, 10 Jun 2012 17:28:06 -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: <4E1F6AAD24975D4BA5B16804296739436652F47C@TK5EX14MBXC284.redmond.corp.microsoft.com> <4FD26F3F.6000503@stpeter.im> In-Reply-To: <4FD26F3F.6000503@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Subject: Re: [OAUTH-WG] OAuth Core -27 Published 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: Sun, 10 Jun 2012 21:28:12 -0000 Oh no... I never even noticed the drama. I thought that everything has been agreed on... Igor On 6/8/2012 5:31 PM, Peter Saint-Andre wrote: > I must say that I found it surprising, too. An explanation beforehand > from the chairs would have helped to prevent confusion. > > On 6/8/12 3:28 PM, Eran Hammer wrote: >> What the hell just happened? Even if this is allowed under IETF rules, >> it is clearly against IETF spirit. There is now a published draft with >> my name as sole editor and text I didn't put in there. No one even >> suggested this is something the chairs might do. >> >> After all the work I put into this, this is a huge slap in the face by >> the chairs. >> >> I hope the fact the Mike Jonea just took over with the blessing on the >> chairs bothers someone else too. >> >> EH >> >> On Jun 8, 2012, at 13:51, "Mike Jones"> > wrote: >> >>> The chairs approved publication of OAuth Core draft -27 today. This >>> version is based upon the proposed changes that I’d circulated to the >>> working group. Changes are: >>> >>> · Adds character set restrictions for error, error_description, >>> and error_uri parameters consistent with the OAuth Bearer spec. >>> >>> · Adds “resource access error response†as an error usage >>> location in the OAuth Extensions Error Registry. >>> >>> · Adds an ABNF for all message elements. >>> >>> · Corrects editorial issues identified during review >>> >>> >>> >>> There are still potential issues with some ABNF definitions that need >>> to be discussed by the working group. I’ll send a separate note about >>> that. Nonetheless, the chairs felt that publishing this version would >>> be a step in the right direction towards completing the Core and >>> Bearer specifications. >>> >>> >>> >>> I’ll be publishing an updated Bearer draft shortly that references the >>> changes in -27 in ways that should resolve the outstanding DISCUSS >>> issues against Bearer. >>> >>> >>> >>> Thanks to Dick Hart for publishing the draft. >>> >>> >>> >>> -- Mike >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From James.H.Manger@team.telstra.com Mon Jun 11 08:36:41 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EDA021F85CC for ; Mon, 11 Jun 2012 08:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E3xafB-9IMa0 for ; Mon, 11 Jun 2012 08:36:41 -0700 (PDT) Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by ietfa.amsl.com (Postfix) with ESMTP id 9F50021F85C7 for ; Mon, 11 Jun 2012 08:36:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,389,1336312800"; d="scan'208";a="77546943" Received: from unknown (HELO ipccvi.tcif.telstra.com.au) ([10.97.217.208]) by ipoavi.tcif.telstra.com.au with ESMTP; 12 Jun 2012 01:36:39 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6738"; a="68186142" Received: from wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) by ipccvi.tcif.telstra.com.au with ESMTP; 12 Jun 2012 01:36:39 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) with mapi; Tue, 12 Jun 2012 01:36:38 +1000 From: "Manger, James H" To: "oauth@ietf.org" Date: Tue, 12 Jun 2012 01:36:32 +1000 Thread-Topic: [OAUTH-WG] Discussion needed on username and password ABNF definitions Thread-Index: Ac1HSVTr9Ci40wGPRneZWq2dwMYRugAm9HTA Message-ID: <255B9BB34FB7D647A506DC292726F6E114F5474E29@WSMSG3153V.srv.dir.telstra.com> References: <4E1F6AAD24975D4BA5B16804296739436652F52D@TK5EX14MBXC284.redmond.corp.microsoft.com> <4FD4E9D4.2010808@gmx.de> <4E1F6AAD24975D4BA5B168042967394366531375@TK5EX14MBXC284.redmond.corp.microsoft.com> <4FD4F976.6090801@gmx.de> <4E1F6AAD24975D4BA5B1680429673943665316D1@TK5EX14MBXC284.redmond.corp.microsoft.com> <60F5CCB0-E036-4351-BD10-A44B33FCC5F6@ve7jtb.com> In-Reply-To: <60F5CCB0-E036-4351-BD10-A44B33FCC5F6@ve7jtb.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 15:36:41 -0000 QXJlIHdlIHNvIHN1cmUgdGhlIG5vbi1lbmdsaXNoICJoYWxmIiBvZiB0aGUgd29ybGQgb25seSB1 c2UgQVNDSUkgY2hhcmFjdGVycyBpbiBwYXNzd29yZHM/IFNvdW5kcyBoaWdobHkgdW5saWtlbHkg dG8gbWUuDQoNCj4gR2l2ZW4gdGhhdCwgYXMgeW91IGNvbmZpcm1lZCwgVVRGLTggImRvZXNuJ3Qg d29yayB3aXRoIEJhc2ljIGFuZCBEaWdlc3QiLi4uDQoNCkl0IGNhbiB3b3JrLiBJdCBpcyBqdXN0 IHVuZGVyc3BlY2lmaWVkLiBTbyB0aGluZ3MgY2FuIGdldCBtZXNzeS4NCmRyYWZ0LXJlc2Noa2Ut YmFzaWNhdXRoLWVuYy0wNSBpcyBhIGN1cnJlbnQgZHJhZnQgKE1hcmNoIDIwMTIpIGF0dGVtcHRp bmcgdG8gZml4IHRoaXMgYXMgbXVjaCBhcyBwb3NzaWJsZS4NCg0KRm9yY2luZyBBU0NJSSBwYXNz d29yZCBmb3IgcGVvcGxlIGZlZWxzIHVuYWNjZXB0YWJsZS4gQmV0dGVyIHdvdWxkIGJlIHRvIHNh eSBPQXV0aCBzZXJ2ZXJzIGFjY2VwdGluZyBIVFRQIEJBU0lDIE1VU1QgYWNjZXB0IFVURi04IGVu Y29kZWQgdXNlcm5hbWVzIGFuZCBwYXNzd29yZHMuIEEgd2FybmluZyBhYm91dCBpbnRlcm9wIHBy b2JsZW1zIHdpdGggbm9uLUFTQ0lJIHBhc3N3b3JkIGlzIG9rLg0KDQpBU0NJSS1vbmx5IGZvciB1 c2VybmFtZXMgaXMgYWxtb3N0IGFzIGJhZC4gSSB0aG91Z2h0IGludGVybmF0aW9uYWxpemVkIGVt YWlsIGFkZHJlc3NlcyB3ZXJlIGp1c3Qgc3RhbmRhcmRpemVkLCBhbmQgZW1haWwgYWRkcmVzc2Vz IGFyZSBvZnRlbiB1c2VkIGFzIHVzZXJuYW1lcy4NCg0KRm9yIGNsaWVudCBpZCAmIHBhc3N3b3Jk IEFTQ0lJLW9ubHkgaXMgbGVzcyBvZiBhbiBpc3N1ZS4gVGhlc2UgYXJlIHZhbHVlcyBjb25maWd1 cmVkIGludG8gYXBwcywgbm90IHJlbWVtYmVyZWQgYnkgaHVtYW4gYnJhaW5zLg0KDQoNCi0tDQpK YW1lcyBNYW5nZXINCg0K From torsten@lodderstedt.net Mon Jun 11 12:17:58 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF9D911E8083 for ; Mon, 11 Jun 2012 12:17:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q3tY0cGFYyK0 for ; Mon, 11 Jun 2012 12:17:55 -0700 (PDT) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.101]) by ietfa.amsl.com (Postfix) with ESMTP id 0962E21F8518 for ; Mon, 11 Jun 2012 12:17:54 -0700 (PDT) Received: from [91.2.79.30] (helo=[192.168.71.36]) by smtprelay06.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1SeA7b-0005zi-D3; Mon, 11 Jun 2012 21:17:51 +0200 Message-ID: <4FD6445B.8020904@lodderstedt.net> Date: Mon, 11 Jun 2012 21:17:47 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Mike Jones References: <4E1F6AAD24975D4BA5B16804296739436652FBFC@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436652FBFC@TK5EX14MBXC284.redmond.corp.microsoft.com> Content-Type: multipart/alternative; boundary="------------030509080908090305020906" X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Cache-Control headers for Bearer URI Query Parameter method X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 19:17:59 -0000 This is a multi-part message in MIME format. --------------030509080908090305020906 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi all, I noticed a difference in usage of cache control headers between bearer and core spec. core -27 states: " The authorization server MUST include the HTTP "Cache-Control" response header field [RFC2616] with a value of "no-store" in any response containing tokens, credentials, or other sensitive information, as well as the "Pragma" response header field [RFC2616] with a value of "no-cache"." So a "Pragma" response header field is required instead of the "Cache-Control" header "private". As far as I understand, both specs are nearly but not fully equivalent. Do we need to align both? regards, Torsten. Am 09.06.2012 00:20, schrieb Mike Jones: > > Hi Amos, > > The OAuth Bearer specification now includes the Cache-Control language > we'd discussed. > > See the fifth paragraph of > http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-20#section-2.3. > > Thanks again, > > -- Mike > > *From:*oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On > Behalf Of *Mike Jones > *Sent:* Thursday, May 17, 2012 3:12 PM > *To:* oauth@ietf.org > *Subject:* [OAUTH-WG] Cache-Control headers for Bearer URI Query > Parameter method > > Dear working group members: > > I'm going through the remaining open issues that have been raised > about the Bearer spec so as to be ready to publish an updated draft > once the outstanding consensus call issues are resolved. > > Amos Jeffries had cited this requirement in the HTTPbis spec ( > http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-19#section-2.3.1): > > o The credentials carried in an Authorization header field are > > specific to the User Agent, and therefore have the same effect on > > HTTP caches as the "private" Cache-Control response directive, > > within the scope of the request they appear in. > > Therefore, new authentication schemes which choose not to carry > > credentials in the Authorization header (e.g., using a newly > > defined header) will need to explicitly disallow caching, by > > mandating the use of either Cache-Control request directives > > (e.g., "no-store") or response directives (e.g., "private"). > > I propose to add the following text in order to satisfy this > requirement. I have changed Amos' MUSTs to SHOULDs because, in > practice, applications that have no option but to use the URI Query > Parameter method are likely to also not have control over the > request's Cache-Control directives (just as they do not have the > ability to use an "Authorization: Bearer" header value): > > Clients using the URI Query Parameter method SHOULD also send a > > Cache-Control header containing the "no-store" option. Server success > > (2XX status) responses to these requests SHOULD contain a > Cache-Control > > header with the "private" option. > > Comments? > > -- Mike > > -----Original Message----- > From: Amos Jeffries [mailto:squid3@treenet.co.nz] > > Sent: Monday, April 23, 2012 10:13 PM > To: Mike Jones > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-19.txt > > On 24/04/2012 4:33 p.m., Mike Jones wrote: > > > What specific language would you suggest be added to what section(s)? > > > > > > -- Mike > > Perhapse the last paragraph appended: > > " > > Because of the security weaknesses associated with the URI method > > (see Section 5), including the high likelihood that the URL > > containing the access token will be logged, it SHOULD NOT be used > > unless it is impossible to transport the access token in the > > "Authorization" request header field or the HTTP request entity-body. > > Resource servers compliant with this specification MAY support this > > method. > > Clients requesting URL containing the access token MUST also send a > > Cache-Control header containing the "no-store" option. Server success > > (2xx status) responses to these requests MUST contain a Cache-Control > > header with the "private" option. > > " > > I'm a little suspicious that the "SHOUDL NOT" in that top paragraph > likely should be a MUST NOT to further discourage needless use. > > AYJ > > > > > > -----Original Message----- > > > From: oauth-bounces@ietf.org On > Behalf Of Amos Jeffries > > > Sent: Monday, April 23, 2012 7:10 PM > > > To: oauth@ietf.org > > > Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-19.txt > > > > > > On 24.04.2012 13:46, 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 : The OAuth 2.0 Authorization Protocol: > Bearer > > >> Tokens > > >> Author(s) : Michael B. Jones > > >> Dick Hardt > > >> David Recordon > > >> Filename : draft-ietf-oauth-v2-bearer-19.txt > > >> Pages : 24 > > >> Date : 2012-04-23 > > >> > > >> This specification describes how to use bearer tokens in HTTP > > >> requests to access OAuth 2.0 protected resources. Any party in > > >> possession of a bearer token (a "bearer") can use it to get > > >> access to > > >> the associated resources (without demonstrating possession of a > > >> cryptographic key). To prevent misuse, bearer tokens need to be > > >> protected from disclosure in storage and in transport. > > >> > > >> > > >> A URL for this Internet-Draft is: > > >> http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-19.txt > > > > > > > > > The section 2.3 (URL Query Parameter) text is still lacking explicit > and specific security requirements. The overarching TLS requirement is > good in general, but insufficient in the presence of HTTP > intermediaries on the TLS connection path as is becoming a common > practice. > > > > > > The upcoming HTTPbis specs document this issue as a requirement for > new auth schemes such as Bearer: > > > > > > http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-19#section-2.3.1 > > > " > > > Therefore, new authentication schemes which choose not to carry > > > credentials in the Authorization header (e.g., using a newly > > > defined header) will need to explicitly disallow caching, by > > > mandating the use of either Cache-Control request directives > > > (e.g., "no-store") or response directives (e.g., "private"). > > > " > > > > > > > > > AYJ > > > > > > _______________________________________________ > > > OAuth mailing list > > > OAuth@ietf.org > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------030509080908090305020906 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi all,

I noticed a difference in usage of cache control headers between bearer and core spec.

core -27 states:

  " The authorization server MUST include the HTTP "Cache-Control"
   response header field [RFC2616] with a value of "no-store" in any
   response containing tokens, credentials, or other sensitive
   information, as well as the "Pragma" response header field [RFC2616]
   with a value of "no-cache"."

So a "Pragma" response header field is required instead of the "Cache-Control" header "private".

As far as I understand, both specs are nearly but not fully equivalent. Do we need to align both?

regards,
Torsten.

Am 09.06.2012 00:20, schrieb Mike Jones:

Hi Amos,

 

The OAuth Bearer specification now includes the Cache-Control language we’d discussed.

 

See the fifth paragraph of http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-20#section-2.3.

 

                                                            Thanks again,

                                                            -- Mike

 

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Thursday, May 17, 2012 3:12 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] Cache-Control headers for Bearer URI Query Parameter method

 

Dear working group members:

 

I'm going through the remaining open issues that have been raised about the Bearer spec so as to be ready to publish an updated draft once the outstanding consensus call issues are resolved.

 

Amos Jeffries had cited this requirement in the HTTPbis spec ( http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-19#section-2.3.1):

 

   o  The credentials carried in an Authorization header field are

      specific to the User Agent, and therefore have the same effect on

      HTTP caches as the "private" Cache-Control response directive,

      within the scope of the request they appear in.

 

      Therefore, new authentication schemes which choose not to carry

      credentials in the Authorization header (e.g., using a newly

      defined header) will need to explicitly disallow caching, by

      mandating the use of either Cache-Control request directives

      (e.g., "no-store") or response directives (e.g., "private").

 

I propose to add the following text in order to satisfy this requirement.  I have changed Amos' MUSTs to SHOULDs because, in practice, applications that have no option but to use the URI Query Parameter method are likely to also not have control over the request's Cache-Control directives (just as they do not have the ability to use an "Authorization: Bearer" header value):

 

    Clients using the URI Query Parameter method SHOULD also send a

    Cache-Control header containing the "no-store" option.  Server success

    (2XX status) responses to these requests SHOULD contain a Cache-Control

    header with the "private" option.

 

Comments?

 

                                                                -- Mike

 

-----Original Message-----
From: Amos Jeffries [mailto:squid3@treenet.co.nz]
Sent: Monday, April 23, 2012 10:13 PM
To: Mike Jones
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-19.txt

 

On 24/04/2012 4:33 p.m., Mike Jones wrote:

> What specific language would you suggest be added to what section(s)?

> 

>                                                             -- Mike

 

 

Perhapse the last paragraph appended:

"

 

    Because of the security weaknesses associated with the URI method

    (see Section 5), including the high likelihood that the URL

    containing the access token will be logged, it SHOULD NOT be used

    unless it is impossible to transport the access token in the

    "Authorization" request header field or the HTTP request entity-body.

    Resource servers compliant with this specification MAY support this

    method.

 

    Clients requesting URL containing the access token MUST also send a

    Cache-Control header containing the "no-store" option. Server success

    (2xx status) responses to these requests MUST contain a Cache-Control

    header with the "private" option.

 

"

 

I'm a little suspicious that the "SHOUDL NOT" in that top paragraph likely should be a MUST NOT to further discourage needless use.

 

 

AYJ

 

 

> 

> -----Original Message-----

> From: oauth-bounces@ietf.org On Behalf Of Amos Jeffries

> Sent: Monday, April 23, 2012 7:10 PM

> To: oauth@ietf.org

> Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-19.txt

> 

> On 24.04.2012 13:46, 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           : The OAuth 2.0 Authorization Protocol: Bearer

>> Tokens

>>           Author(s)       : Michael B. Jones

>>                            Dick Hardt

>>                            David Recordon

>>           Filename        : draft-ietf-oauth-v2-bearer-19.txt

>>           Pages           : 24

>>           Date            : 2012-04-23

>> 

>>     This specification describes how to use bearer tokens in HTTP

>>     requests to access OAuth 2.0 protected resources.  Any party in

>>     possession of a bearer token (a "bearer") can use it to get

>> access to

>>     the associated resources (without demonstrating possession of a

>>     cryptographic key).  To prevent misuse, bearer tokens need to be

>>     protected from disclosure in storage and in transport.

>> 

>> 

>> A URL for this Internet-Draft is:

>> http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-19.txt

> 

> 

> The section 2.3 (URL Query Parameter) text is still lacking explicit and specific security requirements. The overarching TLS requirement is good in general, but insufficient in the presence of HTTP intermediaries on the TLS connection path as is becoming a common practice.

> 

> The upcoming HTTPbis specs document this issue as a requirement for new auth schemes such as Bearer:

> 

> http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-19#section-2.3.1

> "

>         Therefore, new authentication schemes which choose not to carry

>         credentials in the Authorization header (e.g., using a newly

>         defined header) will need to explicitly disallow caching, by

>         mandating the use of either Cache-Control request directives

>         (e.g., "no-store") or response directives (e.g., "private").

> "

> 

> 

> AYJ

> 

> _______________________________________________

> OAuth mailing list

> OAuth@ietf.org

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

> 

> 

 

 



_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--------------030509080908090305020906-- From phil.hunt@oracle.com Mon Jun 11 12:20:48 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0E2321F85C3 for ; Mon, 11 Jun 2012 12:20:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.9 X-Spam-Level: X-Spam-Status: No, score=-9.9 tagged_above=-999 required=5 tests=[AWL=-0.699, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 scElxQ5qPYfF for ; Mon, 11 Jun 2012 12:20:46 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id E932121F85B6 for ; Mon, 11 Jun 2012 12:20:43 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q5BJKeNJ014191 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 11 Jun 2012 19:20:41 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 q5BJKdmP007049 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Jun 2012 19:20:39 GMT Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q5BJKdPa028262; Mon, 11 Jun 2012 14:20:39 -0500 Received: from [192.168.1.125] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 11 Jun 2012 12:20:38 -0700 References: <4E1F6AAD24975D4BA5B16804296739436652FBFC@TK5EX14MBXC284.redmond.corp.microsoft.com> <4FD6445B.8020904@lodderstedt.net> In-Reply-To: <4FD6445B.8020904@lodderstedt.net> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-5DB3C096-92ED-48B7-A897-7E5E96290525 Message-Id: <2FCFF7EB-7E34-49F7-93EE-F57729E420F2@oracle.com> X-Mailer: iPhone Mail (9B206) From: Phil Hunt Date: Mon, 11 Jun 2012 12:23:30 -0700 To: Torsten Lodderstedt X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Cache-Control headers for Bearer URI Query Parameter method X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 19:20:48 -0000 --Apple-Mail-5DB3C096-92ED-48B7-A897-7E5E96290525 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Private also seems inappropriate since no operation should be cached for oau= th as even when the same requestor.=20 Phil On 2012-06-11, at 12:17, Torsten Lodderstedt wrote= : > Hi all, >=20 > I noticed a difference in usage of cache control headers between bearer an= d core spec.=20 >=20 > core -27 states: >=20 > " The authorization server MUST include the HTTP "Cache-Control" > response header field [RFC2616] with a value of "no-store" in any > response containing tokens, credentials, or other sensitive > information, as well as the "Pragma" response header field [RFC2616] > with a value of "no-cache"." >=20 > So a "Pragma" response header field is required instead of the "Cache-Cont= rol" header "private". >=20 > As far as I understand, both specs are nearly but not fully equivalent. Do= we need to align both? >=20 > regards, > Torsten. >=20 > Am 09.06.2012 00:20, schrieb Mike Jones: >>=20 >> Hi Amos, >> =20 >> The OAuth Bearer specification now includes the Cache-Control language we= =E2=80=99d discussed. >> =20 >> See the fifth paragraph of http://tools.ietf.org/html/draft-ietf-oauth-v2= -bearer-20#section-2.3. >> =20 >> Thanks again,= >> -- Mike >> =20 >> =20 >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of= Mike Jones >> Sent: Thursday, May 17, 2012 3:12 PM >> To: oauth@ietf.org >> Subject: [OAUTH-WG] Cache-Control headers for Bearer URI Query Parameter m= ethod >> =20 >> Dear working group members: >> =20 >> I'm going through the remaining open issues that have been raised about t= he Bearer spec so as to be ready to publish an updated draft once the outsta= nding consensus call issues are resolved. >> =20 >> Amos Jeffries had cited this requirement in the HTTPbis spec ( http://too= ls.ietf.org/html/draft-ietf-httpbis-p7-auth-19#section-2.3.1): >> =20 >> o The credentials carried in an Authorization header field are >> specific to the User Agent, and therefore have the same effect on >> HTTP caches as the "private" Cache-Control response directive, >> within the scope of the request they appear in. >> =20 >> Therefore, new authentication schemes which choose not to carry >> credentials in the Authorization header (e.g., using a newly >> defined header) will need to explicitly disallow caching, by >> mandating the use of either Cache-Control request directives >> (e.g., "no-store") or response directives (e.g., "private"). >> =20 >> I propose to add the following text in order to satisfy this requirement.= I have changed Amos' MUSTs to SHOULDs because, in practice, applications t= hat have no option but to use the URI Query Parameter method are likely to a= lso not have control over the request's Cache-Control directives (just as th= ey do not have the ability to use an "Authorization: Bearer" header value): >> =20 >> Clients using the URI Query Parameter method SHOULD also send a >> Cache-Control header containing the "no-store" option. Server succes= s >> (2XX status) responses to these requests SHOULD contain a Cache-Contr= ol >> header with the "private" option. >> =20 >> Comments? >> =20 >> -- Mike >> =20 >> -----Original Message----- >> From: Amos Jeffries [mailto:squid3@treenet.co.nz]=20 >> Sent: Monday, April 23, 2012 10:13 PM >> To: Mike Jones >> Cc: oauth@ietf.org >> Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-19.txt >> =20 >> On 24/04/2012 4:33 p.m., Mike Jones wrote: >> > What specific language would you suggest be added to what section(s)? >> >=20 >> > -- = Mike >> =20 >> =20 >> Perhapse the last paragraph appended: >> " >> =20 >> Because of the security weaknesses associated with the URI method >> (see Section 5), including the high likelihood that the URL >> containing the access token will be logged, it SHOULD NOT be used >> unless it is impossible to transport the access token in the >> "Authorization" request header field or the HTTP request entity-body.= >> Resource servers compliant with this specification MAY support this >> method. >> =20 >> Clients requesting URL containing the access token MUST also send a >> Cache-Control header containing the "no-store" option. Server success= >> (2xx status) responses to these requests MUST contain a Cache-Control= >> header with the "private" option. >> =20 >> " >> =20 >> I'm a little suspicious that the "SHOUDL NOT" in that top paragraph likel= y should be a MUST NOT to further discourage needless use. >> =20 >> =20 >> AYJ >> =20 >> =20 >> >=20 >> > -----Original Message----- >> > From: oauth-bounces@ietf.org On Behalf Of Amos Jeffries >> > Sent: Monday, April 23, 2012 7:10 PM >> > To: oauth@ietf.org >> > Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-19.txt >> >=20 >> > On 24.04.2012 13:46, 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 : The OAuth 2.0 Authorization Protocol: Bear= er >> >> Tokens >> >> Author(s) : Michael B. Jones >> >> Dick Hardt >> >> David Recordon >> >> Filename : draft-ietf-oauth-v2-bearer-19.txt >> >> Pages : 24 >> >> Date : 2012-04-23 >> >>=20 >> >> This specification describes how to use bearer tokens in HTTP >> >> requests to access OAuth 2.0 protected resources. Any party in >> >> possession of a bearer token (a "bearer") can use it to get >> >> access to >> >> the associated resources (without demonstrating possession of a >> >> cryptographic key). To prevent misuse, bearer tokens need to be >> >> protected from disclosure in storage and in transport. >> >>=20 >> >>=20 >> >> A URL for this Internet-Draft is: >> >> http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-19.txt >> >=20 >> >=20 >> > The section 2.3 (URL Query Parameter) text is still lacking explicit an= d specific security requirements. The overarching TLS requirement is good in= general, but insufficient in the presence of HTTP intermediaries on the TLS= connection path as is becoming a common practice. >> >=20 >> > The upcoming HTTPbis specs document this issue as a requirement for new= auth schemes such as Bearer: >> >=20 >> > http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-19#section-2.3.1 >> > " >> > Therefore, new authentication schemes which choose not to carry= >> > credentials in the Authorization header (e.g., using a newly >> > defined header) will need to explicitly disallow caching, by >> > mandating the use of either Cache-Control request directives >> > (e.g., "no-store") or response directives (e.g., "private"). >> > " >> >=20 >> >=20 >> > AYJ >> >=20 >> > _______________________________________________ >> > OAuth mailing list >> > OAuth@ietf.org >> > https://www.ietf.org/mailman/listinfo/oauth >> >=20 >> >=20 >> =20 >> =20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-5DB3C096-92ED-48B7-A897-7E5E96290525 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Private also seems inappro= priate since no operation should be cached for oauth as even when the same r= equestor. 

Phil

On 2012-06-11, at 12:17, To= rsten Lodderstedt <torsten@lod= derstedt.net> wrote:

=20 =20 =20 Hi all,

I noticed a difference in usage of cache control headers between bearer and core spec.

core -27 states:

  " The authorization server MUST include the HTTP "Cache-Control"<= br>    response header field [RFC2616] with a value of "no-store" i= n any
   response containing tokens, credentials, or other sensitive=
   information, as well as the "Pragma" response header field [RFC2616]
   with a value of "no-cache"."

So a "Pragma" response header field is required instead of the "Cache-Control" header "private".

As far as I understand, both specs are nearly but not fully equivalent. Do we need to align both?

regards,
Torsten.

Am 09.06.2012 00:20, schrieb Mike Jones:

Hi Amos,

 

The OAuth Bearer specification now includes the Cache-Control language we=E2=80=99d discussed.

 

See the fifth paragraph of http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-20#sect= ion-2.3.

 

       =                    =             &nbs= p;            &n= bsp;        Thanks again,

       =             &nbs= p;            &n= bsp;            =             &nbs= p;  -- Mike

 

 

From:= oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org= ] On Behalf Of Mike Jones
Sent: Thursday, May 17, 2012 3:12 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] Cache-Control headers for Bearer URI Query Parameter method

 

Dear working group members:

=

 

I'm going through the remaining open issues that have been raised about the Bearer spec so as to be ready to publish an updated draft once the outstanding consensus call issues are resolved.

 

Amos Jeffries had cited this requirement in the HTTPbis spec ( http://tools.ietf.org/html/draft-i= etf-httpbis-p7-auth-19#section-2.3.1):

 

   o  The credentials carri= ed in an Authorization header field are

      specific to= the User Agent, and therefore have the same effect on

      HTTP caches= as the "private" Cache-Control response directive,

      within the s= cope of the request they appear in.

 

      Therefore, n= ew authentication schemes which choose not to carry

      credentials= in the Authorization header (e.g., using a newly

      defined hea= der) will need to explicitly disallow caching, by

      mandating t= he use of either Cache-Control request directives

      (e.g., "no-= store") or response directives (e.g., "private").

 

I propose to add the following text in order to satisfy this requirement.  I have changed Amos' MUST= s to SHOULDs because, in practice, applications that have no option but to use the URI Query Parameter method are likely to also not have control over the request's Cache-Control directives (just as they do not have the ability to use an "Authorization: Bearer" header value):

 

  =   Clients using the URI Query Parameter method SHOULD also send a

  =   Cache-Control header containing the "no-store" option.  Server success

  =   (2XX status) responses to these requests SHOULD contain a Cache-Control

  =   header with the "private" option.

 

Comments?

 

       =             &nbs= p;            &n= bsp;            =             &nbs= p;      -- Mike

 

-----Original Message-----
From: Amos Jeffries [mailto:squid3@treenet.co.nz]
Sent: Monday, April 23, 2012 10:13 PM
To: Mike Jones
Cc: oau= th@ietf.org
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-19.txt

 

On 24/04/2012 4:33 p.m., Mike Jones wrote:

> What specific language would you suggest be added to what section(s)?

> 

>            =             &nbs= p;            &n= bsp;            =            -- Mike

 

 

Perhapse the last paragraph appended:=

"

 

    Because of the security= weaknesses associated with the URI method

    (see Section 5), includ= ing the high likelihood that the URL

    containing the access t= oken will be logged, it SHOULD NOT be used

    unless it is impossible= to transport the access token in the

    "Authorization" request= header field or the HTTP request entity-body.

    Resource servers compli= ant with this specification MAY support this

    method.

 

    Clients requesting URL c= ontaining the access token MUST also send a

    Cache-Control header co= ntaining the "no-store" option. Server success

    (2xx status) responses t= o these requests MUST contain a Cache-Control

    header with the "privat= e" option.

 

"

 

I'm a little suspicious that the "SHOUDL NOT" in that top paragraph likely should be a MUST NOT to further discourage needless use.

 

 

AYJ

 

 

> 

> -----Original Message-----=

> From: oauth-bounces@ietf.org On Behalf Of Amos Jeffries

> Sent: Monday, April 23, 2012 7:10 PM

> To: oauth@ietf.org

> Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-19.txt

> 

> On 24.04.2012 13:46, internet-d= rafts@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.

>> 

>>      &nb= sp;    Title        &= nbsp;  : The OAuth 2.0 Authorization Protocol: Bearer

>> Tokens

>>      &nb= sp;    Author(s)       : Michael B. Jones

>>     &nbs= p;            &n= bsp;         Dick Hardt

>>     &nbs= p;               =        David Recordon

>>      &nb= sp;    Filename        : draft-ietf-oauth-v2-bearer-19.txt

>>      &nb= sp;    Pages        &= nbsp;  : 24

>>      &nb= sp;    Date        &n= bsp;   : 2012-04-23

>> 

>>     This spec= ification describes how to use bearer tokens in HTTP

>>     requests t= o access OAuth 2.0 protected resources.  Any party in

>>     possessio= n of a bearer token (a "bearer") can use it to get

>> access to

>>     the assoc= iated resources (without demonstrating possession of a

>>     cryptogra= phic key).  To prevent misuse, bearer tokens need to be

>>     protected= from disclosure in storage and in transport.

>> 

>> 

>> A URL for this Internet-Draft is:

>> http://www.ietf.org/intern= et-drafts/draft-ietf-oauth-v2-bearer-19.txt

> 

> 

> The section 2.3 (URL Query Parameter) text is still lacking explicit and specific security requirements. The overarching TLS requirement is good in general, but insufficient in the presence of HTTP intermediaries on the TLS connection path as is becoming a common practice.

> 

> The upcoming HTTPbis specs document this issue as a requirement for new auth schemes such as Bearer:

> 

> http://tools.ietf.org/html/= draft-ietf-httpbis-p7-auth-19#section-2.3.1

> "

>      &n= bsp;  Therefore, new authentication schemes which choose not to carry

>      &n= bsp;  credentials in the Authorization header (e.g., using a newly

>      &n= bsp;  defined header) will need to explicitly disallow caching, by

>      &n= bsp;  mandating the use of either Cache-Control request directives

>      &n= bsp;  (e.g., "no-store") or response directives (e.g., "private").

> "

> 

> 

> AYJ

> 

> _______________________________________________

> OAuth mailing list

> = OAuth@ietf.org

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

> 

> 

 

 



_______________________________________________
OAuth mailing list
OAuth@i=
etf.org
https://www.ietf.org/mailman/listinfo/oauth
=20
____________________= ___________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mai= lman/listinfo/oauth
= --Apple-Mail-5DB3C096-92ED-48B7-A897-7E5E96290525-- From doug.foiles@gmail.com Mon Jun 11 12:31:33 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3501821F864E for ; Mon, 11 Jun 2012 12:31:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.133 X-Spam-Level: X-Spam-Status: No, score=-3.133 tagged_above=-999 required=5 tests=[AWL=0.465, 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 rk1ZIJgjnrHY for ; Mon, 11 Jun 2012 12:31:32 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 966E921F864A for ; Mon, 11 Jun 2012 12:31:32 -0700 (PDT) Received: by yhq56 with SMTP id 56so3370922yhq.31 for ; Mon, 11 Jun 2012 12:31:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=w7t8gUnN/piWS/NhbPsxP0PrsxFtf8fC5toi/8QAnCw=; b=ktkQR01SeeaueJ7IcBjmV9FGJPdnBBIyAlNlxPXxdhwP9niplfhYVHNW1+bNBQDX+V 9yWCHP+yZFuiLIkm3TVEMm4o+OoTVg07vKpe3d92+5zLJjKmWErMIvuZOA/qzRBwYec+ xcUuiPbTloU3OpSh8Hls5DUtbe3VHi3xEpVRz0tCpcvwmFF9NCkzXw4fvBDyWKObWIsD qy2qVIwBk7FtzSXefNCTo3+cb9P6c2M88CKsqri85D2xZ35mkjaI/z91c/5BEA3/5+1O i+05T8IJ5MAV48yOv/1NmdjRNfTYEO5xQRlx9hEzqtl7ToIWYiF/KmWjUf9vXpG2JQLz /ZdQ== MIME-Version: 1.0 Received: by 10.50.207.3 with SMTP id ls3mr11648982igc.0.1339443091954; Mon, 11 Jun 2012 12:31:31 -0700 (PDT) Received: by 10.231.199.135 with HTTP; Mon, 11 Jun 2012 12:31:31 -0700 (PDT) Date: Mon, 11 Jun 2012 12:31:31 -0700 Message-ID: From: doug foiles To: oauth@ietf.org Content-Type: multipart/alternative; boundary=14dae9340d09b15afc04c2376512 Subject: [OAUTH-WG] Clarification in Section 2.0 of draft-ietf-oauth-revocation-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 19:31:33 -0000 --14dae9340d09b15afc04c2376512 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi all, I was hoping to get some clarity on a statement in section 2.0 of draft-ietf-oauth-revocation-00. If the processed token is a refresh token and the authorization server supports the revocation of access tokens, then the authorization server SHOULD also invalidate all access tokens issued for that refresh token. My question is on the statement "access tokens issued for that refresh token". What does it mean to have an Access Token "issued" for a Refresh Token? This specific case is clear to me. I am refreshing an Access Token where I keep the same Refresh Token that I used to generate the new Access Token. I see the new Access Token was issued for that Refresh Token. However these two cases are a bit muddy to me. Let=92s say I am using the "Resource Owner Password Credentials Grant" where the Access Token Response returns both an Access Token and Refresh Token. Would the Access Token have been issued for that Refresh Token? And let=92s say I am refreshing an Acce= ss Token but choose to create a new Refresh Token and immediately revoke the original Refresh Token. Would the newly created Access Token have been issued for the original Refresh Token or the new one that was created. If a client would revoke a Refresh Token =85 I would like the Access Tokens in all of the above cases to be automatically revoked as well. I just want to make sure I understand the model. Thanks. Doug Foiles Intuit --14dae9340d09b15afc04c2376512 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

I was hoping to get some clarity on a statement in section 2.0 of = draft-ietf-oauth-revocation-00.

=E3=80=80=E3=80=80 If the processed token is a refresh token and t= he authorization
=E3=80=80=E3=80=80 server supports the revocation of ac= cess tokens, then the
=E3=80=80=E3=80=80 authorization server SHOULD als= o invalidate all access tokens issued
=E3=80=80=E3=80=80 for that refres= h token.

My question is on the statement "access tokens issued for tha= t refresh token".=E3=80=80 What does it mean to have an Access Token &= quot;issued" for a Refresh Token?=E3=80=80

This specific case is clear to me.=E3=80=80 I am refreshing an Acc= ess Token where I keep the same Refresh Token that I used to generate the n= ew Access Token.=E3=80=80 I see the new Access Token was issued for that Re= fresh Token.
However these two cases are a bit muddy to me.=E3=80=80 Let=E2=80=99s = say I am using the "Resource Owner Password Credentials Grant" wh= ere the Access Token Response returns both an Access Token and Refresh Toke= n.=E3=80=80 Would the Access Token have been issued for that Refresh Token?= =E3=80=80 And let=E2=80=99s say I am refreshing an Access Token but choose = to create a new Refresh Token and immediately revoke the original Refresh T= oken.=E3=80=80 Would the newly created Access Token have been issued for th= e original Refresh Token or the new one that was created.
If a client would revoke a Refresh Token =E2=80=A6 I would like the Ac= cess Tokens in all of the above cases to be automatically revoked as well.= =E3=80=80 I just want to make sure I understand the model.=E3=80=80 Thanks.=
Doug Foiles
Intuit
--14dae9340d09b15afc04c2376512-- From paul.madsen@gmail.com Mon Jun 11 13:09:41 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C53211E809A for ; Mon, 11 Jun 2012 13:09:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kf1nbDn60mlt for ; Mon, 11 Jun 2012 13:09:40 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6786711E808F for ; Mon, 11 Jun 2012 13:09:40 -0700 (PDT) Received: by vcqp1 with SMTP id p1so2854048vcq.31 for ; Mon, 11 Jun 2012 13:09:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=k/mUylyJcl3LRsvIXnAQ0twmfsxExFW6the7zYo0H1U=; b=mRI9iBCtB34/Tg2+hLL0I/OZQrHPaqSK+fxhoUN5bQ2Zb/ZHOBpw/nzEy3pwg71WSl 3S1g6CeGhy2+p8IR6vTi66W2gcw4bVIfEkPlCDh653JkrbOvJT2k1prdMZ3lRLcf3B9A BfUrZkY+WuZZZDqW9xvQlkgnRH7MKbfq5D8UVgQytAhnJ2rNqQEqGXFcYrf1H6z88cea mZQg2WBDOMudB9q+ARC6KZMfAt1nGNQHtf+SrjhhFrCogO2kvE63AWmmsDIr2hBaBVoC 3LFF30lckr4u1klOe/ehX/SA46YPNhIqmHaoPFCu4/4oNaIdvfJKHcYR0K41VU79bW4D fh1w== Received: by 10.52.25.70 with SMTP id a6mr11091805vdg.78.1339445379861; Mon, 11 Jun 2012 13:09:39 -0700 (PDT) Received: from pmadsen-mbp.local (CPE0022b0cb82b4-CM0012256eb4b4.cpe.net.cable.rogers.com. [99.224.20.155]) by mx.google.com with ESMTPS id by3sm21525581vdc.17.2012.06.11.13.09.37 (version=SSLv3 cipher=OTHER); Mon, 11 Jun 2012 13:09:38 -0700 (PDT) Message-ID: <4FD65080.9040305@gmail.com> Date: Mon, 11 Jun 2012 16:09:37 -0400 From: Paul Madsen User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.28) Gecko/20120306 Thunderbird/3.1.20 MIME-Version: 1.0 To: doug foiles References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------090002070008090808000906" Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Clarification in Section 2.0 of draft-ietf-oauth-revocation-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 20:09:41 -0000 This is a multi-part message in MIME format. --------------090002070008090808000906 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi Doug, my interpretation is that 'for that refresh token' means those access tokens issued in exchange for that refresh token. Consequently, for the cases you cite below, the access tokens at the same time as a given refresh token need not be invalidated when that refresh token is 'processed' I assume the justification for the rule is that an access token issued in exchange for a given refresh token may have been compromised if the refresh token had been. But there is no such causal relationship between an access token & refresh token issued at same time paul On 6/11/12 3:31 PM, doug foiles wrote: > Hi all, > > I was hoping to get some clarity on a statement in section 2.0 of > draft-ietf-oauth-revocation-00. > > 　　 If the processed token is a refresh token and the authorization > 　　 server supports the revocation of access tokens, then the > 　　 authorization server SHOULD also invalidate all access tokens issued > 　　 for that refresh token. > > My question is on the statement "access tokens issued for that refresh > token".　 What does it mean to have an Access Token "issued" for a > Refresh Token?　 > > This specific case is clear to me.　 I am refreshing an Access Token > where I keep the same Refresh Token that I used to generate the new > Access Token.　 I see the new Access Token was issued for that Refresh > Token. > However these two cases are a bit muddy to me.　 Let’s say I am using > the "Resource Owner Password Credentials Grant" where the Access Token > Response returns both an Access Token and Refresh Token.　 Would the > Access Token have been issued for that Refresh Token?　 And let’s say > I am refreshing an Access Token but choose to create a new Refresh > Token and immediately revoke the original Refresh Token.　 Would the > newly created Access Token have been issued for the original Refresh > Token or the new one that was created. > If a client would revoke a Refresh Token … I would like the Access > Tokens in all of the above cases to be automatically revoked as well. > 　 I just want to make sure I understand the model.　 Thanks. > Doug Foiles > Intuit > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------090002070008090808000906 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi Doug, my interpretation is that 'for that refresh token' means those access tokens issued in exchange for that refresh token.

Consequently, for the cases you cite below, the access tokens at the same time as a given refresh token need not be invalidated when that refresh token is 'processed'

I assume the justification for the rule is that an access token issued in exchange for a given refresh token may have been compromised if the refresh token had been. But there is no such causal relationship between an access token & refresh token issued at same time

paul

On 6/11/12 3:31 PM, doug foiles wrote:
Hi all,

I was hoping to get some clarity on a statement in section 2.0 of draft-ietf-oauth-revocation-00.

　　 If the processed token is a refresh token and the authorization
　　 server supports the revocation of access tokens, then the
　　 authorization server SHOULD also invalidate all access tokens issued
　　 for that refresh token.

My question is on the statement "access tokens issued for that refresh token".　 What does it mean to have an Access Token "issued" for a Refresh Token?　

This specific case is clear to me.　 I am refreshing an Access Token where I keep the same Refresh Token that I used to generate the new Access Token.　 I see the new Access Token was issued for that Refresh Token.
However these two cases are a bit muddy to me.　 Let’s say I am using the "Resource Owner Password Credentials Grant" where the Access Token Response returns both an Access Token and Refresh Token.　 Would the Access Token have been issued for that Refresh Token?　 And let’s say I am refreshing an Access Token but choose to create a new Refresh Token and immediately revoke the original Refresh Token.　 Would the newly created Access Token have been issued for the original Refresh Token or the new one that was created.
If a client would revoke a Refresh Token … I would like the Access Tokens in all of the above cases to be automatically revoked as well.　 I just want to make sure I understand the model.　 Thanks.
Doug Foiles
Intuit

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--------------090002070008090808000906-- From gffletch@aol.com Mon Jun 11 14:11:05 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0C0521F845C for ; Mon, 11 Jun 2012 14:11:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.739 X-Spam-Level: X-Spam-Status: No, score=-0.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, 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 KCN7e+vS1qO3 for ; Mon, 11 Jun 2012 14:11:00 -0700 (PDT) Received: from imr-da04.mx.aol.com (imr-da04.mx.aol.com [205.188.105.146]) by ietfa.amsl.com (Postfix) with ESMTP id 78C7F21F844E for ; Mon, 11 Jun 2012 14:11:00 -0700 (PDT) Received: from mtaout-mb03.r1000.mx.aol.com (mtaout-mb03.r1000.mx.aol.com [172.29.41.67]) by imr-da04.mx.aol.com (8.14.1/8.14.1) with ESMTP id q5BLAnwI009663; Mon, 11 Jun 2012 17:10:49 -0400 Received: from palantir.office.aol.com (palantir.office.aol.com [10.181.186.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout-mb03.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id BE629E0001EA; Mon, 11 Jun 2012 17:10:48 -0400 (EDT) Message-ID: <4FD65ED8.6000507@aol.com> Date: Mon, 11 Jun 2012 17:10:48 -0400 From: George Fletcher Organization: AOL LLC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: oauth@ietf.org References: <4FD65080.9040305@gmail.com> In-Reply-To: <4FD65080.9040305@gmail.com> Content-Type: multipart/alternative; boundary="------------070703000700030003040407" x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20110426; t=1339449048; bh=vKl1zYSfJRMVViEIdpOGYcsnOQ6mjG3iHB97qnsCYOI=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=G2mYAn74z8s/oxxq+6nu8dBTFBjLBl6fDz+zijyyxhM/xINbxU1l/xgZCXznvlxfG oghZKjH0VvevYN4jxFgy721w7PUcMaXfQmNf62Fzr3IojL2ssOfJVkEbmhjX990Tel jYsYxaRCNJNenU8mIp/ZJ0pkoFW15Ee/L3S9TenQ= X-AOL-SCOLL-SCORE: 0:2:486304704:93952408 X-AOL-SCOLL-URL_COUNT: 0 x-aol-sid: 3039ac1d29434fd65ed84265 X-AOL-IP: 10.181.186.254 Subject: Re: [OAUTH-WG] Clarification in Section 2.0 of draft-ietf-oauth-revocation-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 21:11:05 -0000 This is a multi-part message in MIME format. --------------070703000700030003040407 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Paul, I think I came to a different conclusion... If I use the Resource Owner Password Credential flow and get back both an access_token and a refresh_token then I would assume that the issued access_token is tied in some way to the refresh_token. If the refresh_token is revoked, then my expectation is that the simultaneous issued access_token would also be revoked. I read the spec as having a typo that should read... If the processed token is a refresh token and the authorization server supports the revocation of access tokens, then the authorization server SHOULD also invalidate all access tokens issued *based on* that refresh token. Or maybe better... "invalidate all access tokens associated/tied-to that refresh token". Now in the case that the client is retrieving a new refresh_token and access_token, then the new ones should be valid and the old ones potentially revoked. Thanks, George On 6/11/12 4:09 PM, Paul Madsen wrote: > Hi Doug, my interpretation is that 'for that refresh token' means > those access tokens issued in exchange for that refresh token. > > Consequently, for the cases you cite below, the access tokens at the > same time as a given refresh token need not be invalidated when that > refresh token is 'processed' > > I assume the justification for the rule is that an access token issued > in exchange for a given refresh token may have been compromised if the > refresh token had been. But there is no such causal relationship > between an access token & refresh token issued at same time > > paul > > On 6/11/12 3:31 PM, doug foiles wrote: >> Hi all, >> >> I was hoping to get some clarity on a statement in section 2.0 of >> draft-ietf-oauth-revocation-00. >> >> If the processed token is a refresh token and the authorization >> server supports the revocation of access tokens, then the >> authorization server SHOULD also invalidate all access tokens issued >> for that refresh token. >> >> My question is on the statement "access tokens issued for that >> refresh token". What does it mean to have an Access Token "issued" >> for a Refresh Token? >> >> This specific case is clear to me. I am refreshing an Access Token >> where I keep the same Refresh Token that I used to generate the new >> Access Token. I see the new Access Token was issued for that Refresh >> Token. >> However these two cases are a bit muddy to me. Let's say I am using >> the "Resource Owner Password Credentials Grant" where the Access >> Token Response returns both an Access Token and Refresh Token. Would >> the Access Token have been issued for that Refresh Token? And let's >> say I am refreshing an Access Token but choose to create a new >> Refresh Token and immediately revoke the original Refresh Token. >> Would the newly created Access Token have been issued for the >> original Refresh Token or the new one that was created. >> If a client would revoke a Refresh Token ... I would like the Access >> Tokens in all of the above cases to be automatically revoked as well. >> I just want to make sure I understand the model. Thanks. >> Doug Foiles >> Intuit >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------070703000700030003040407 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Paul,

I think I came to a different conclusion...

If I use the Resource Owner Password Credential flow and get back both an access_token and a refresh_token then I would assume that the issued access_token is tied in some way to the refresh_token. If the refresh_token is revoked, then my expectation is that the simultaneous issued access_token would also be revoked.

I read the spec as having a typo that should read...
If the processed token is a refresh token and the authorization
server supports the revocation of access tokens, then the
authorization server SHOULD also invalidate all access tokens issued
*based on* that refresh token.
Or maybe better... "invalidate all access tokens associated/tied-to that refresh token".

Now in the case that the client is retrieving a new refresh_token and access_token, then the new ones should be valid and the old ones potentially revoked.

Thanks,
George

On 6/11/12 4:09 PM, Paul Madsen wrote:
Hi Doug, my interpretation is that 'for that refresh token' means those access tokens issued in exchange for that refresh token.

Consequently, for the cases you cite below, the access tokens at the same time as a given refresh token need not be invalidated when that refresh token is 'processed'

I assume the justification for the rule is that an access token issued in exchange for a given refresh token may have been compromised if the refresh token had been. But there is no such causal relationship between an access token & refresh token issued at same time

paul

On 6/11/12 3:31 PM, doug foiles wrote:
Hi all,

I was hoping to get some clarity on a statement in section 2.0 of draft-ietf-oauth-revocation-00.

　　 If the processed token is a refresh token and the authorization
　　 server supports the revocation of access tokens, then the
　　 authorization server SHOULD also invalidate all access tokens issued
　　 for that refresh token.

My question is on the statement "access tokens issued for that refresh token".　 What does it mean to have an Access Token "issued" for a Refresh Token?　

This specific case is clear to me.　 I am refreshing an Access Token where I keep the same Refresh Token that I used to generate the new Access Token.　 I see the new Access Token was issued for that Refresh Token.
However these two cases are a bit muddy to me.　 Let’s say I am using the "Resource Owner Password Credentials Grant" where the Access Token Response returns both an Access Token and Refresh Token.　 Would the Access Token have been issued for that Refresh Token?　 And let’s say I am refreshing an Access Token but choose to create a new Refresh Token and immediately revoke the original Refresh Token.　 Would the newly created Access Token have been issued for the original Refresh Token or the new one that was created.
If a client would revoke a Refresh Token … I would like the Access Tokens in all of the above cases to be automatically revoked as well.　 I just want to make sure I understand the model.　 Thanks.
Doug Foiles
Intuit

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



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

--------------070703000700030003040407-- From Michael.Jones@microsoft.com Mon Jun 11 15:17:00 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A3AC21F852A for ; Mon, 11 Jun 2012 15:17:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.974 X-Spam-Level: X-Spam-Status: No, score=-3.974 tagged_above=-999 required=5 tests=[AWL=-0.375, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mE7BigLVrX19 for ; Mon, 11 Jun 2012 15:16:59 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe002.messaging.microsoft.com [216.32.181.182]) by ietfa.amsl.com (Postfix) with ESMTP id 1E03B21F8525 for ; Mon, 11 Jun 2012 15:16:58 -0700 (PDT) Received: from mail114-ch1-R.bigfish.com (10.43.68.235) by CH1EHSOBE010.bigfish.com (10.43.70.60) with Microsoft SMTP Server id 14.1.225.23; Mon, 11 Jun 2012 22:15:58 +0000 Received: from mail114-ch1 (localhost [127.0.0.1]) by mail114-ch1-R.bigfish.com (Postfix) with ESMTP id 2A7E11A025D for ; Mon, 11 Jun 2012 22:15:58 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -27 X-BigFish: VS-27(zz9371I617I542Mzz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25hf0ah) Received-SPF: pass (mail114-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC103.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail114-ch1 (localhost.localdomain [127.0.0.1]) by mail114-ch1 (MessageSwitch) id 1339452955605861_15338; Mon, 11 Jun 2012 22:15:55 +0000 (UTC) Received: from CH1EHSMHS028.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.246]) by mail114-ch1.bigfish.com (Postfix) with ESMTP id 88AFD3A005E for ; Mon, 11 Jun 2012 22:15:55 +0000 (UTC) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS028.bigfish.com (10.43.70.28) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 11 Jun 2012 22:15:55 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.189]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.02.0298.005; Mon, 11 Jun 2012 22:16:48 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Discussion needed on username and password ABNF definitions Thread-Index: AQHNR+gPRaE+PhTJM0qj3EZzSy4QqZb1poqw Date: Mon, 11 Jun 2012 22:16:47 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943665346D0@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739436652F52D@TK5EX14MBXC284.redmond.corp.microsoft.com> <4FD4E9D4.2010808@gmx.de> <4E1F6AAD24975D4BA5B168042967394366531375@TK5EX14MBXC284.redmond.corp.microsoft.com> <4FD4F976.6090801@gmx.de> <4E1F6AAD24975D4BA5B1680429673943665316D1@TK5EX14MBXC284.redmond.corp.microsoft.com> <60F5CCB0-E036-4351-BD10-A44B33FCC5F6@ve7jtb.com> <255B9BB34FB7D647A506DC292726F6E114F5474E29@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F5474E29@WSMSG3153V.srv.dir.telstra.com> 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 22:17:00 -0000 Reviewing the feedback from Julian, John, and James, I'm coming to the conc= lusion that client_id and client_secret, being for machines and not humans,= should be ASCII, whereas username and password should be Unicode, since th= ey are for humans. Per John's feedback, client_id can not contain a colon = and be compatible with HTTP Basic. Therefore, I'd like to propose these updated ABNF definitions: VSCHAR =3D %20-7E NOCOLONVSCHAR =3D %x20-39 / %x3B-7E UNICODENOCTRLCHAR =3D client-id =3D *NOCOLONVSCHAR client_secret =3D *VSCHAR username =3D *UNICODENOCTRLCHAR password =3D *UNICODENOCTRLCHAR It turns out that non-ASCII characters are OK for username and password bec= ause the Core spec only passes them in the form body - not using HTTP Basic= - and UTF-8 encoding is specified. -- Mike P.S. If anyone has a better ABNF for UNICODENOCTRLCHAR than "", please send it to me! -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of M= anger, James H Sent: Monday, June 11, 2012 8:37 AM To: oauth@ietf.org Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF def= initions Are we so sure the non-english "half" of the world only use ASCII character= s in passwords? Sounds highly unlikely to me. > Given that, as you confirmed, UTF-8 "doesn't work with Basic and Digest".= .. It can work. It is just underspecified. So things can get messy. draft-reschke-basicauth-enc-05 is a current draft (March 2012) attempting t= o fix this as much as possible. Forcing ASCII password for people feels unacceptable. Better would be to sa= y OAuth servers accepting HTTP BASIC MUST accept UTF-8 encoded usernames an= d passwords. A warning about interop problems with non-ASCII password is ok= . ASCII-only for usernames is almost as bad. I thought internationalized emai= l addresses were just standardized, and email addresses are often used as u= sernames. For client id & password ASCII-only is less of an issue. These are values c= onfigured into apps, not remembered by human brains. -- James Manger _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From squid3@treenet.co.nz Mon Jun 11 15:39:58 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC1E921F853D for ; Mon, 11 Jun 2012 15:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.662 X-Spam-Level: X-Spam-Status: No, score=-0.662 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_EQ_STATIC=1.172] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4sjVYwv54n3V for ; Mon, 11 Jun 2012 15:39:57 -0700 (PDT) Received: from treenet.co.nz (ip-58-28-153-233.static-xdsl.xnet.co.nz [58.28.153.233]) by ietfa.amsl.com (Postfix) with ESMTP id 70AD721F853C for ; Mon, 11 Jun 2012 15:39:57 -0700 (PDT) Received: by treenet.co.nz (Postfix, from userid 33) id 64B42E6F2D; Tue, 12 Jun 2012 10:39:53 +1200 (NZST) To: X-PHP-Originating-Script: 0:main.inc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Tue, 12 Jun 2012 10:39:53 +1200 From: Amos Jeffries In-Reply-To: <2FCFF7EB-7E34-49F7-93EE-F57729E420F2@oracle.com> References: <4E1F6AAD24975D4BA5B16804296739436652FBFC@TK5EX14MBXC284.redmond.corp.microsoft.com> <4FD6445B.8020904@lodderstedt.net> <2FCFF7EB-7E34-49F7-93EE-F57729E420F2@oracle.com> Message-ID: X-Sender: squid3@treenet.co.nz User-Agent: Roundcube Webmail/0.7.2 Subject: Re: [OAUTH-WG] Cache-Control headers for Bearer URI Query Parameter method X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 22:39:59 -0000 On 12.06.2012 07:23, Phil Hunt wrote: > Private also seems inappropriate since no operation should be cached > for oauth as even when the same requestor. > > Phil > There is a difference in HTTP use-case between what the Bearer and core specs are covering. The core spec appears to be covering the request/response messages transferring credentials in the response entity. These mandate "no-store", which adds strict erasure requirements for any middleware and browser caches handling the response. Even single-user caches like a browser are not allowed to store the HTTP copy of the credentials response. Bearer is requiring "private" only in the specific HTTP case where the token is in query params and response is some data object (ie images or HTML page). Such that trusted proxies and other third-parties who do not implement OAuth but do relay HTTP treat the request and reply securely. With uses of Bearer via HTTP authentication framework this "private" is implicit. In these cases the response MAY be cached by a private browser cache, but not by third-party proxies. no-store is overkill and wastes bandwidth in this case. I hope this clarifies. AYJ > On 2012-06-11, at 12:17, Torsten Lodderstedt wrote: > >> Hi all, >> >> I noticed a difference in usage of cache control headers between >> bearer and core spec. >> >> core -27 states: >> >> " The authorization server MUST include the HTTP "Cache-Control" >> response header field [RFC2616] with a value of "no-store" in any >> response containing tokens, credentials, or other sensitive >> information, as well as the "Pragma" response header field >> [RFC2616] >> with a value of "no-cache"." >> >> So a "Pragma" response header field is required instead of the >> "Cache-Control" header "private". Not instead of. *As well as*. Pragma "no-cache" only tells the third-party to revalidate before using the response, it does not prevent storage and thus potential data leakage. >> >> As far as I understand, both specs are nearly but not fully >> equivalent. Do we need to align both? >> >> regards, >> Torsten. >> >> Am 09.06.2012 00:20, schrieb Mike Jones: >>> >>> Hi Amos, >>> >>> The OAuth Bearer specification now includes the Cache-Control >>> language we’d discussed. >>> >>> See the fifth paragraph of >>> http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-20#section-2.3. >>> >>> Thanks >>> again, >>> -- Mike >>> >>> >>> From: oauth-bounces@ietf.org On Behalf Of Mike Jones >>> Sent: Thursday, May 17, 2012 3:12 PM >>> Subject: [OAUTH-WG] Cache-Control headers for Bearer URI Query >>> Parameter method >>> >>> Dear working group members: >>> >>> I'm going through the remaining open issues that have been raised >>> about the Bearer spec so as to be ready to publish an updated draft >>> once the outstanding consensus call issues are resolved. >>> >>> Amos Jeffries had cited this requirement in the HTTPbis spec ( >>> http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-19#section-2.3.1): >>> >>> o The credentials carried in an Authorization header field are >>> specific to the User Agent, and therefore have the same >>> effect on >>> HTTP caches as the "private" Cache-Control response >>> directive, >>> within the scope of the request they appear in. >>> >>> Therefore, new authentication schemes which choose not to >>> carry >>> credentials in the Authorization header (e.g., using a newly >>> defined header) will need to explicitly disallow caching, by >>> mandating the use of either Cache-Control request directives >>> (e.g., "no-store") or response directives (e.g., "private"). >>> >>> I propose to add the following text in order to satisfy this >>> requirement. I have changed Amos' MUSTs to SHOULDs because, in >>> practice, applications that have no option but to use the URI Query >>> Parameter method are likely to also not have control over the >>> request's Cache-Control directives (just as they do not have the >>> ability to use an "Authorization: Bearer" header value): >>> >>> Clients using the URI Query Parameter method SHOULD also send a >>> Cache-Control header containing the "no-store" option. Server >>> success >>> (2XX status) responses to these requests SHOULD contain a >>> Cache-Control >>> header with the "private" option. >>> >>> Comments? >>> >>> -- >>> Mike >>> >>> -----Original Message----- >>> From: Amos Jeffries >>> >>> On 24/04/2012 4:33 p.m., Mike Jones wrote: >>> > What specific language would you suggest be added to what >>> section(s)? >>> > >>> > -- >>> Mike >>> >>> >>> Perhapse the last paragraph appended: >>> " >>> >>> Because of the security weaknesses associated with the URI >>> method >>> (see Section 5), including the high likelihood that the URL >>> containing the access token will be logged, it SHOULD NOT be >>> used >>> unless it is impossible to transport the access token in the >>> "Authorization" request header field or the HTTP request >>> entity-body. >>> Resource servers compliant with this specification MAY support >>> this >>> method. >>> >>> Clients requesting URL containing the access token MUST also >>> send a >>> Cache-Control header containing the "no-store" option. Server >>> success >>> (2xx status) responses to these requests MUST contain a >>> Cache-Control >>> header with the "private" option. >>> >>> " >>> >>> I'm a little suspicious that the "SHOUDL NOT" in that top paragraph >>> likely should be a MUST NOT to further discourage needless use. >>> >>> >>> AYJ >>> >>> >>> > >>> > -----Original Message----- >>> > From: oauth-bounces@ietf.org On Behalf Of Amos Jeffries >>> > >>> > On 24.04.2012 13:46, 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 : The OAuth 2.0 Authorization >>> Protocol: Bearer >>> >> Tokens >>> >> Author(s) : Michael B. Jones >>> >> Dick Hardt >>> >> David Recordon >>> >> Filename : draft-ietf-oauth-v2-bearer-19.txt >>> >> Pages : 24 >>> >> Date : 2012-04-23 >>> >> >>> >> This specification describes how to use bearer tokens in >>> HTTP >>> >> requests to access OAuth 2.0 protected resources. Any party >>> in >>> >> possession of a bearer token (a "bearer") can use it to get >>> >> access to >>> >> the associated resources (without demonstrating possession >>> of a >>> >> cryptographic key). To prevent misuse, bearer tokens need >>> to be >>> >> protected from disclosure in storage and in transport. >>> >> >>> >> >>> >> A URL for this Internet-Draft is: >>> >> >>> http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-19.txt >>> > >>> > >>> > The section 2.3 (URL Query Parameter) text is still lacking >>> explicit and specific security requirements. The overarching TLS >>> requirement is good in general, but insufficient in the presence of >>> HTTP intermediaries on the TLS connection path as is becoming a >>> common practice. >>> > >>> > The upcoming HTTPbis specs document this issue as a requirement >>> for new auth schemes such as Bearer: >>> > >>> > >>> http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-19#section-2.3.1 >>> > " >>> > Therefore, new authentication schemes which choose not to >>> carry >>> > credentials in the Authorization header (e.g., using a >>> newly >>> > defined header) will need to explicitly disallow caching, >>> by >>> > mandating the use of either Cache-Control request >>> directives >>> > (e.g., "no-store") or response directives (e.g., >>> "private"). >>> > " >>> > >>> > >>> > AYJ >>> > >>> > _______________________________________________ >>> > OAuth mailing 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 paul.madsen@gmail.com Mon Jun 11 15:52:39 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC46A21F8449 for ; Mon, 11 Jun 2012 15:52:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d37f6fnXR1Zb for ; Mon, 11 Jun 2012 15:52:39 -0700 (PDT) Received: from mail-qa0-f49.google.com (mail-qa0-f49.google.com [209.85.216.49]) by ietfa.amsl.com (Postfix) with ESMTP id 964B821F845F for ; Mon, 11 Jun 2012 15:52:36 -0700 (PDT) Received: by qabj40 with SMTP id j40so2900646qab.15 for ; Mon, 11 Jun 2012 15:52:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=Wr83G65e4axjjbcjJnLJkWlVxQE9TMvNSo3OLsNTdMs=; b=ULI45QPILsMRI9fv568BWjKJinWkrJHIf4Qvg1WdEiRZg/5bjGZEni618UUt/zAB6Y zsmATANlZt9dUHY4DWEBjS+zqN83FjHMqUC33VqLyWifc2LU42kmjHVwU+1eX8AfCJ7y YBp3aj73mKUrgzBKicYXZpL5IDMVybRivQbfIhd2BYB+DMLydgAUkWRukotn1wigjiuJ F2RYNjFY6mdJz+5qvKcULnMkG2oyUrHJHz5hp3earfI0p7SWnFI1f8iIvo2t5mKsR/An gOxjVABhZD/zvgf9/lyH/emIwbckFIEybKWA5Btrx67iQoqPNai60qwOU5uQ8hAAYVxc FMkQ== Received: by 10.224.116.135 with SMTP id m7mr6901143qaq.9.1339455156062; Mon, 11 Jun 2012 15:52:36 -0700 (PDT) Received: from [10.118.163.227] ([184.151.114.99]) by mx.google.com with ESMTPS id hj10sm11692579qab.4.2012.06.11.15.52.34 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 11 Jun 2012 15:52:35 -0700 (PDT) References: <4FD65080.9040305@gmail.com> <4FD65ED8.6000507@aol.com> In-Reply-To: <4FD65ED8.6000507@aol.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-365C97AF-7C95-4391-A77C-D7108DAE804D Message-Id: X-Mailer: iPhone Mail (9A406) From: Paul Madsen Date: Mon, 11 Jun 2012 18:52:32 -0400 To: George Fletcher Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Clarification in Section 2.0 of draft-ietf-oauth-revocation-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 22:52:40 -0000 --Apple-Mail-365C97AF-7C95-4391-A77C-D7108DAE804D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi George, perhaps it depends on the reason for the refresh token being revo= ked. If because the user removed their consent then yes I agree that *all* t= okens should be revoked Sent from my iPhone On 2012-06-11, at 5:10 PM, George Fletcher wrote: > Paul,=20 >=20 > I think I came to a different conclusion... >=20 > If I use the Resource Owner Password Credential flow and get back both an a= ccess_token and a refresh_token then I would assume that the issued access_t= oken is tied in some way to the refresh_token. If the refresh_token is revok= ed, then my expectation is that the simultaneous issued access_token would a= lso be revoked. >=20 > I read the spec as having a typo that should read... > If the processed token is a refresh token and the authorization > server supports the revocation of access tokens, then the > authorization server SHOULD also invalidate all access tokens issued > *based on* that refresh token. > Or maybe better... "invalidate all access tokens associated/tied-to that r= efresh token". >=20 > Now in the case that the client is retrieving a new refresh_token and acce= ss_token, then the new ones should be valid and the old ones potentially rev= oked. >=20 > Thanks, > George >=20 > On 6/11/12 4:09 PM, Paul Madsen wrote: >>=20 >> Hi Doug, my interpretation is that 'for that refresh token' means those a= ccess tokens issued in exchange for that refresh token.=20 >>=20 >> Consequently, for the cases you cite below, the access tokens at the same= time as a given refresh token need not be invalidated when that refresh tok= en is 'processed' >>=20 >> I assume the justification for the rule is that an access token issued in= exchange for a given refresh token may have been compromised if the refresh= token had been. But there is no such causal relationship between an access t= oken & refresh token issued at same time >>=20 >> paul=20 >>=20 >> On 6/11/12 3:31 PM, doug foiles wrote: >>>=20 >>> Hi all, >>>=20 >>> I was hoping to get some clarity on a statement in section 2.0 of draft-= ietf-oauth-revocation-00. >>>=20 >>> =E3=80=80=E3=80=80 If the processed token is a refresh token and the aut= horization >>> =E3=80=80=E3=80=80 server supports the revocation of access tokens, then= the >>> =E3=80=80=E3=80=80 authorization server SHOULD also invalidate all acces= s tokens issued >>> =E3=80=80=E3=80=80 for that refresh token. >>>=20 >>> My question is on the statement "access tokens issued for that refresh t= oken".=E3=80=80 What does it mean to have an Access Token "issued" for a Ref= resh Token?=E3=80=80 >>>=20 >>> This specific case is clear to me.=E3=80=80 I am refreshing an Access To= ken where I keep the same Refresh Token that I used to generate the new Acce= ss Token.=E3=80=80 I see the new Access Token was issued for that Refresh To= ken. >>> However these two cases are a bit muddy to me.=E3=80=80 Let=E2=80=99s sa= y I am using the "Resource Owner Password Credentials Grant" where the Acces= s Token Response returns both an Access Token and Refresh Token.=E3=80=80 Wo= uld the Access Token have been issued for that Refresh Token?=E3=80=80 And l= et=E2=80=99s say I am refreshing an Access Token but choose to create a new R= efresh Token and immediately revoke the original Refresh Token.=E3=80=80 Wou= ld the newly created Access Token have been issued for the original Refresh T= oken or the new one that was created.=20 >>> If a client would revoke a Refresh Token =E2=80=A6 I would like the Acce= ss Tokens in all of the above cases to be automatically revoked as well.=E3=80= =80 I just want to make sure I understand the model.=E3=80=80 Thanks. >>> Doug Foiles >>> Intuit >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 --Apple-Mail-365C97AF-7C95-4391-A77C-D7108DAE804D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi George, perhaps it depe= nds on the reason for the refresh token being revoked. If because the user r= emoved their consent then yes I agree that *all* tokens should be revoked
Sent from my iPhone

On 2012-06-11, at 5:10 PM, George Fle= tcher <gffletch@aol.com> wrote= :

=20 =20 =20 Paul,

I think I came to a different conclusion...

If I use the Resource Owner Password Credential flow and get back both an access_token and a refresh_token then I would assume that the issued access_token is tied in some way to the refresh_token. If the refresh_token is revoked, then my expectation is that the simultaneous issued access_token would also be revoked.

I read the spec as having a typo that should read...
If the processed token is a refresh token and the=
 authorization
server supports the revocation of access tokens, then the
authorization server SHOULD also invalidate all access tokens issued
*based on* that refresh token.
Or maybe better... "invalidate all access tokens associated/tied-to that refresh token".

Now in the case that the client is retrieving a new refresh_token and access_token, then the new ones should be valid and the old ones potentially revoked.

Thanks,
George

On 6/11/12 4:09 PM, Paul Madsen wrote:
Hi Doug, my interpretation is that 'for that refresh token' means those access tokens issued in exchange for that refresh token.

Consequently, for the cases you cite below, the access tokens at the same time as a given refresh token need not be invalidated when that refresh token is 'processed'

I assume the justification for the rule is that an access token issued in exchange for a given refresh token may have been compromised if the refresh token had been. But there is no such causal relationship between an access token & refresh token issued at same time

paul

On 6/11/12 3:31 PM, doug foiles wrote:
Hi all,

I was hoping to get some clarity on a statement in section 2.0 of draft-ietf-oauth-revocation-00.

=E3=80=80=E3=80=80 If the processed token is a refresh token and t= he authorization
=E3=80=80=E3=80=80 server supports the revocation of access tokens= , then the
=E3=80=80=E3=80=80 authorization server SHOULD also invalidate all= access tokens issued
=E3=80=80=E3=80=80 for that refresh token.

My question is on the statement "access tokens issued for that refresh token".=E3=80=80 What does it mean to have an Access Token= "issued" for a Refresh Token?=E3=80=80

This specific case is clear to me.=E3=80=80 I am refreshing an Acc= ess Token where I keep the same Refresh Token that I used to generate the new Access Token.=E3=80=80 I see the new Access Token= was issued for that Refresh Token.
However these two cases are a bit muddy to me.=E3=80=80 Let=E2=80= =99s say I am using the "Resource Owner Password Credentials Grant" where the Access Token Response returns both an Access Token and Refresh Token.=E3=80=80 Would the Access Token have been issued fo= r that Refresh Token?=E3=80=80 And let=E2=80=99s say I am refreshing= an Access Token but choose to create a new Refresh Token and immediately revoke the original Refresh Token.=E3=80=80 Would the newly create= d Access Token have been issued for the original Refresh Token or the new one that was created.
If a client would revoke a Refresh Token =E2=80=A6 I would like= the Access Tokens in all of the above cases to be automatically revoked as well.=E3=80=80 I just want to make sure I understand th= e model.=E3=80=80 Thanks.
Doug Foiles
Intuit

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



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

=20
= --Apple-Mail-365C97AF-7C95-4391-A77C-D7108DAE804D-- From phil.hunt@oracle.com Mon Jun 11 16:01:14 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2797811E808A for ; Mon, 11 Jun 2012 16:01:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.203 X-Spam-Level: X-Spam-Status: No, score=-9.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 Wxh2pn7FG4ld for ; Mon, 11 Jun 2012 16:01:13 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id CE54821F842B for ; Mon, 11 Jun 2012 16:01:12 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q5BN16uJ004003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 11 Jun 2012 23:01:07 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q5BN15JY009036 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Jun 2012 23:01:06 GMT Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q5BN156u003235; Mon, 11 Jun 2012 18:01:05 -0500 Received: from [25.69.143.114] (/74.198.150.242) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 11 Jun 2012 16:01:05 -0700 References: <4E1F6AAD24975D4BA5B16804296739436652FBFC@TK5EX14MBXC284.redmond.corp.microsoft.com> <4FD6445B.8020904@lodderstedt.net> <2FCFF7EB-7E34-49F7-93EE-F57729E420F2@oracle.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: X-Mailer: iPhone Mail (9B206) From: Phil Hunt Date: Mon, 11 Jun 2012 16:03:54 -0700 To: Amos Jeffries X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Cache-Control headers for Bearer URI Query Parameter method X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 23:01:14 -0000 Thanks. That makes sense.=20 Phil On 2012-06-11, at 15:39, Amos Jeffries wrote: > On 12.06.2012 07:23, Phil Hunt wrote: >> Private also seems inappropriate since no operation should be cached >> for oauth as even when the same requestor. >>=20 >> Phil >>=20 >=20 > There is a difference in HTTP use-case between what the Bearer and core sp= ecs are covering. >=20 > The core spec appears to be covering the request/response messages transfe= rring credentials in the response entity. These mandate "no-store", which ad= ds strict erasure requirements for any middleware and browser caches handlin= g the response. Even single-user caches like a browser are not allowed to st= ore the HTTP copy of the credentials response. >=20 > Bearer is requiring "private" only in the specific HTTP case where the tok= en is in query params and response is some data object (ie images or HTML pa= ge). Such that trusted proxies and other third-parties who do not implement O= Auth but do relay HTTP treat the request and reply securely. With uses of Be= arer via HTTP authentication framework this "private" is implicit. > In these cases the response MAY be cached by a private browser cache, but= not by third-party proxies. no-store is overkill and wastes bandwidth in th= is case. >=20 >=20 > I hope this clarifies. >=20 >=20 > AYJ >=20 >=20 >> On 2012-06-11, at 12:17, Torsten Lodderstedt wrote: >>=20 >>> Hi all, >>>=20 >>> I noticed a difference in usage of cache control headers between bearer a= nd core spec. >>>=20 >>> core -27 states: >>>=20 >>> " The authorization server MUST include the HTTP "Cache-Control" >>> response header field [RFC2616] with a value of "no-store" in any >>> response containing tokens, credentials, or other sensitive >>> information, as well as the "Pragma" response header field [RFC2616] >>> with a value of "no-cache"." >>>=20 >>> So a "Pragma" response header field is required instead of the "Cache-Co= ntrol" header "private". >=20 > Not instead of. *As well as*. Pragma "no-cache" only tells the third-part= y to revalidate before using the response, it does not prevent storage and t= hus potential data leakage. >=20 >=20 >>>=20 >>> As far as I understand, both specs are nearly but not fully equivalent. D= o we need to align both? >>>=20 >>> regards, >>> Torsten. >>>=20 >>> Am 09.06.2012 00:20, schrieb Mike Jones: >>>>=20 >>>> Hi Amos, >>>>=20 >>>> The OAuth Bearer specification now includes the Cache-Control language w= e=E2=80=99d discussed. >>>>=20 >>>> See the fifth paragraph of http://tools.ietf.org/html/draft-ietf-oauth-= v2-bearer-20#section-2.3. >>>>=20 >>>> Thanks again= , >>>> -- Mike >>>>=20 >>>>=20 >>>> From: oauth-bounces@ietf.org On Behalf Of Mike Jones >>>> Sent: Thursday, May 17, 2012 3:12 PM >>>> Subject: [OAUTH-WG] Cache-Control headers for Bearer URI Query Paramete= r method >>>>=20 >>>> Dear working group members: >>>>=20 >>>> I'm going through the remaining open issues that have been raised about= the Bearer spec so as to be ready to publish an updated draft once the outs= tanding consensus call issues are resolved. >>>>=20 >>>> Amos Jeffries had cited this requirement in the HTTPbis spec ( http://t= ools.ietf.org/html/draft-ietf-httpbis-p7-auth-19#section-2.3.1): >>>>=20 >>>> o The credentials carried in an Authorization header field are >>>> specific to the User Agent, and therefore have the same effect on >>>> HTTP caches as the "private" Cache-Control response directive, >>>> within the scope of the request they appear in. >>>>=20 >>>> Therefore, new authentication schemes which choose not to carry >>>> credentials in the Authorization header (e.g., using a newly >>>> defined header) will need to explicitly disallow caching, by >>>> mandating the use of either Cache-Control request directives >>>> (e.g., "no-store") or response directives (e.g., "private"). >>>>=20 >>>> I propose to add the following text in order to satisfy this requiremen= t. I have changed Amos' MUSTs to SHOULDs because, in practice, applications= that have no option but to use the URI Query Parameter method are likely to= also not have control over the request's Cache-Control directives (just as t= hey do not have the ability to use an "Authorization: Bearer" header value):= >>>>=20 >>>> Clients using the URI Query Parameter method SHOULD also send a >>>> Cache-Control header containing the "no-store" option. Server succe= ss >>>> (2XX status) responses to these requests SHOULD contain a Cache-Cont= rol >>>> header with the "private" option. >>>>=20 >>>> Comments? >>>>=20 >>>> -- Mike >>>>=20 >>>> -----Original Message----- >>>> From: Amos Jeffries >>>>=20 >>>> On 24/04/2012 4:33 p.m., Mike Jones wrote: >>>> > What specific language would you suggest be added to what section(s)?= >>>> > >>>> > -- = Mike >>>>=20 >>>>=20 >>>> Perhapse the last paragraph appended: >>>> " >>>>=20 >>>> Because of the security weaknesses associated with the URI method >>>> (see Section 5), including the high likelihood that the URL >>>> containing the access token will be logged, it SHOULD NOT be used >>>> unless it is impossible to transport the access token in the >>>> "Authorization" request header field or the HTTP request entity-body= . >>>> Resource servers compliant with this specification MAY support this >>>> method. >>>>=20 >>>> Clients requesting URL containing the access token MUST also send a >>>> Cache-Control header containing the "no-store" option. Server succes= s >>>> (2xx status) responses to these requests MUST contain a Cache-Contro= l >>>> header with the "private" option. >>>>=20 >>>> " >>>>=20 >>>> I'm a little suspicious that the "SHOUDL NOT" in that top paragraph lik= ely should be a MUST NOT to further discourage needless use. >>>>=20 >>>>=20 >>>> AYJ >>>>=20 >>>>=20 >>>> > >>>> > -----Original Message----- >>>> > From: oauth-bounces@ietf.org On Behalf Of Amos Jeffries >>>> > >>>> > On 24.04.2012 13:46, 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 : The OAuth 2.0 Authorization Protocol: Be= arer >>>> >> Tokens >>>> >> Author(s) : Michael B. Jones >>>> >> Dick Hardt >>>> >> David Recordon >>>> >> Filename : draft-ietf-oauth-v2-bearer-19.txt >>>> >> Pages : 24 >>>> >> Date : 2012-04-23 >>>> >> >>>> >> This specification describes how to use bearer tokens in HTTP >>>> >> requests to access OAuth 2.0 protected resources. Any party in >>>> >> possession of a bearer token (a "bearer") can use it to get >>>> >> access to >>>> >> the associated resources (without demonstrating possession of a >>>> >> cryptographic key). To prevent misuse, bearer tokens need to be= >>>> >> protected from disclosure in storage and in transport. >>>> >> >>>> >> >>>> >> A URL for this Internet-Draft is: >>>> >> http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-19.tx= t >>>> > >>>> > >>>> > The section 2.3 (URL Query Parameter) text is still lacking explicit a= nd specific security requirements. The overarching TLS requirement is good i= n general, but insufficient in the presence of HTTP intermediaries on the TL= S connection path as is becoming a common practice. >>>> > >>>> > The upcoming HTTPbis specs document this issue as a requirement for n= ew auth schemes such as Bearer: >>>> > >>>> > http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-19#section-2.3.= 1 >>>> > " >>>> > Therefore, new authentication schemes which choose not to car= ry >>>> > credentials in the Authorization header (e.g., using a newly >>>> > defined header) will need to explicitly disallow caching, by >>>> > mandating the use of either Cache-Control request directives >>>> > (e.g., "no-store") or response directives (e.g., "private"). >>>> > " >>>> > >>>> > >>>> > AYJ >>>> > >>>> > _______________________________________________ >>>> > OAuth mailing list >>>> > OAuth@ietf.org >>>> > https://www.ietf.org/mailman/listinfo/oauth >>>> > >>>> > >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From doug.foiles@gmail.com Mon Jun 11 17:13:55 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9714321F8559 for ; Mon, 11 Jun 2012 17:13:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.288 X-Spam-Level: X-Spam-Status: No, score=-3.288 tagged_above=-999 required=5 tests=[AWL=0.310, 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 4ejCq0rdYMQw for ; Mon, 11 Jun 2012 17:13:54 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4D3B221F8551 for ; Mon, 11 Jun 2012 17:13:54 -0700 (PDT) Received: by yhq56 with SMTP id 56so3569335yhq.31 for ; Mon, 11 Jun 2012 17:13:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dtVX0f9jXkb+igMdv5rGmF/iR9I++Xth6xd27d/omp0=; b=Hjpr/e8HTo3giwnpIUKR5dFSK2BYxwjks9XAHIldOWpHqyyRGVkzOw70tlvPLpqQGv 6EwK+ezYLR7jGTNhYKXAsKWxlj7HTgI2kEDm8bRKMOVotROv9epN519hILzRD9NR/mvc dK8YZtJ6gFAXLxynt+0GWnp2wQQO06l5379jSEl4NvCo9xzChOisVzaTUNSLg2/nYjuX Sp++uUuPreIgIKajyGk8DyqpDS2BS0HQa6qXaEcr1bRZkSfPg5xePWQ8Iiq4UILc9SER CccHmZwMishpRhfggNBxUHapSwVDmkeQcLU6vu3+1G1UYjPvyjzhlR/vXibeBGGo15Wd 1Xlg== MIME-Version: 1.0 Received: by 10.50.169.33 with SMTP id ab1mr7341722igc.73.1339460033622; Mon, 11 Jun 2012 17:13:53 -0700 (PDT) Received: by 10.231.199.135 with HTTP; Mon, 11 Jun 2012 17:13:53 -0700 (PDT) In-Reply-To: References: <4FD65080.9040305@gmail.com> <4FD65ED8.6000507@aol.com> Date: Mon, 11 Jun 2012 17:13:53 -0700 Message-ID: From: doug foiles To: Paul Madsen Content-Type: multipart/alternative; boundary=e89a8f3ba8717eb2ee04c23b579c Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Clarification in Section 2.0 of draft-ietf-oauth-revocation-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 00:13:55 -0000 --e89a8f3ba8717eb2ee04c23b579c Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Paul and George, Even though the Access Token is short lived, I would still like to revoke it immediately if the user chooses to revoke the Refresh Token. And I would love for the client application to only have to make one web service call to accomplish that and not one for the Refresh Token and another for the Access Token. Given that we always generate a new Refresh Token value during "Token Refresh", we would never have a true parent / child relationship between a Refresh Token and Access Token. Is there a case where it is NOT appropriate to revoke an "associated" Access Token when explictly revoking a Refresh Token? I define "associated" as an Access Token generated from a Refresh Token OR generated at the same time of the Refresh Token. I do see the AS challenges in trying to manage multiple simultaneous "associated" Access Tokens. For example let's say a client generates multiple Access Tokens at the same time while generating new Refresh Token values during each "Token Refresh" operation. However I don't really see the useful of this case. Doug On Mon, Jun 11, 2012 at 3:52 PM, Paul Madsen wrote: > Hi George, perhaps it depends on the reason for the refresh token being > revoked. If because the user removed their consent then yes I agree that > *all* tokens should be revoked > > Sent from my iPhone > > On 2012-06-11, at 5:10 PM, George Fletcher wrote: > > Paul, > > I think I came to a different conclusion... > > If I use the Resource Owner Password Credential flow and get back both an > access_token and a refresh_token then I would assume that the issued > access_token is tied in some way to the refresh_token. If the refresh_tok= en > is revoked, then my expectation is that the simultaneous issued > access_token would also be revoked. > > I read the spec as having a typo that should read... > > If the processed token is a refresh token and the authorization > server supports the revocation of access tokens, then the > authorization server SHOULD also invalidate all access tokens issued > *based on* that refresh token. > > Or maybe better... "invalidate all access tokens associated/tied-to that > refresh token". > > Now in the case that the client is retrieving a new refresh_token and > access_token, then the new ones should be valid and the old ones > potentially revoked. > > Thanks, > George > > On 6/11/12 4:09 PM, Paul Madsen wrote: > > Hi Doug, my interpretation is that 'for that refresh token' means those > access tokens issued in exchange for that refresh token. > > Consequently, for the cases you cite below, the access tokens at the same > time as a given refresh token need not be invalidated when that refresh > token is 'processed' > > I assume the justification for the rule is that an access token issued in > exchange for a given refresh token may have been compromised if the refre= sh > token had been. But there is no such causal relationship between an acces= s > token & refresh token issued at same time > > paul > > On 6/11/12 3:31 PM, doug foiles wrote: > > Hi all, > > I was hoping to get some clarity on a statement in section 2.0 of > draft-ietf-oauth-revocation-00. > > If the processed token is a refresh token and the authorization > server supports the revocation of access tokens, then the > authorization server SHOULD also invalidate all access tokens issued > for that refresh token. > > My question is on the statement "access tokens issued for that refresh > token". What does it mean to have an Access Token "issued" for a Refresh > Token? > > This specific case is clear to me. I am refreshing an Access Token where = I > keep the same Refresh Token that I used to generate the new Access Token.= I > see the new Access Token was issued for that Refresh Token. > However these two cases are a bit muddy to me. Let=92s say I am using the > "Resource Owner Password Credentials Grant" where the Access Token Respon= se > returns both an Access Token and Refresh Token. Would the Access Token ha= ve > been issued for that Refresh Token? And let=92s say I am refreshing an Ac= cess > Token but choose to create a new Refresh Token and immediately revoke the > original Refresh Token. Would the newly created Access Token have been > issued for the original Refresh Token or the new one that was created. > If a client would revoke a Refresh Token =85 I would like the Access Toke= ns > in all of the above cases to be automatically revoked as well. I just wan= t > to make sure I understand the model. Thanks. > Doug Foiles > Intuit > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau= th > > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau= th > > > --e89a8f3ba8717eb2ee04c23b579c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Paul and George,
=C2=A0
Even though the Access Token is short lived, I would still like to rev= oke it immediately if the user chooses to revoke the Refresh Token.=C2=A0 A= nd I would love for the client application to only have to make one web ser= vice call to accomplish that and not one for the Refresh Token and another = for the Access Token.
=C2=A0
Given that we always generate a new Refresh Token value during "T= oken Refresh", we would never have a true parent / child relationship = between a Refresh Token and Access Token.
=C2=A0
Is there a case where it is NOT appropriate to revoke an "associa= ted" Access Token=C2=A0when explictly revoking a Refresh Token?=C2=A0 = I define "associated" as an Access Token generated from a Refresh= Token OR generated at the same time of the Refresh Token.
=C2=A0
I do see the AS challenges in trying to manage multiple simultaneous= =C2=A0"associated" Access Tokens.=C2=A0 For example let's say= a client generates multiple Access Tokens at the same time while generatin= g new Refresh Token values during each "Token Refresh" operation.= =C2=A0 However I don't really see the useful of this case.
=C2=A0
Doug

On Mon, Jun 11, 2012 at 3:52 PM, Paul Madsen <paul.madsen@gmail.com> wrote:
Hi George, perhaps it depends on the reason for the refresh token bein= g revoked. If because the user removed their consent then yes I agree that = *all* tokens should be revoked

Sent from my iPhone

On 2012-06-11, at 5:10 PM, George Fletcher <gffletch@aol.com> wrote:

<= /div>
Paul,

I think I came to a different conclusion...

If I = use the Resource Owner Password Credential flow and get back both an access= _token and a refresh_token then I would assume that the issued access_token= is tied in some way to the refresh_token. If the refresh_token is revoked,= then my expectation is that the simultaneous issued access_token would als= o be revoked.

I read the spec as having a typo that should read...
If the pro=
cessed token is a refresh token and the authorization
server supports the revocation of access tokens, then the
authorization server SHOULD also invalidate all access tokens issued
*based on* that refresh token.
Or maybe better... "invalidate all= access tokens associated/tied-to that refresh token".

Now in t= he case that the client is retrieving a new refresh_token and access_token,= then the new ones should be valid and the old ones potentially revoked.
Thanks,
George

On 6/11/12 4:09 PM, Paul Madsen wrote:=20
Hi Doug, my interpretation i= s that 'for that refresh token' means those access tokens issued in= exchange for that refresh token.

Consequently, for the cases you c= ite below, the access tokens at the same time as a given refresh token need= not be invalidated when that refresh token is 'processed'

I assume the justification for the rule is that an access token issued = in exchange for a given refresh token may have been compromised if the refr= esh token had been. But there is no such causal relationship between an acc= ess token & refresh token issued at same time

paul

On 6/11/12 3:31 PM, doug foiles wrote:=20
Hi all,

I was hoping to get some clarity on a statement in section 2.0 of = draft-ietf-oauth-revocation-00.

=E3=80=80=E3=80=80 If the processed token is a refresh token and t= he authorization
=E3=80=80=E3=80=80 server supports the revocation of ac= cess tokens, then the
=E3=80=80=E3=80=80 authorization server SHOULD als= o invalidate all access tokens issued
=E3=80=80=E3=80=80 for that refres= h token.

My question is on the statement "access tokens issued for tha= t refresh token".=E3=80=80 What does it mean to have an Access Token &= quot;issued" for a Refresh Token?=E3=80=80

This specific case is clear to me.=E3=80=80 I am refreshing an Acc= ess Token where I keep the same Refresh Token that I used to generate the n= ew Access Token.=E3=80=80 I see the new Access Token was issued for that Re= fresh Token.
However these two cases are a bit muddy to me.=E3=80=80 Let=E2=80=99s = say I am using the "Resource Owner Password Credentials Grant" wh= ere the Access Token Response returns both an Access Token and Refresh Toke= n.=E3=80=80 Would the Access Token have been issued for that Refresh Token?= =E3=80=80 And let=E2=80=99s say I am refreshing an Access Token but choose = to create a new Refresh Token and immediately revoke the original Refresh T= oken.=E3=80=80 Would the newly created Access Token have been issued for th= e original Refresh Token or the new one that was created.
If a client would revoke a Refresh Token =E2=80=A6 I would like the Ac= cess Tokens in all of the above cases to be automatically revoked as well.= =E3=80=80 I just want to make sure I understand the model.=E3=80=80 Thanks.=
Doug Foiles
Intuit

_______________________________________________
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


--e89a8f3ba8717eb2ee04c23b579c-- From torsten@lodderstedt.net Mon Jun 11 23:06:53 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5153D21F85AD for ; Mon, 11 Jun 2012 23:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pvVtit04BN+F for ; Mon, 11 Jun 2012 23:06:52 -0700 (PDT) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.103]) by ietfa.amsl.com (Postfix) with ESMTP id F3E1021F8595 for ; Mon, 11 Jun 2012 23:06:51 -0700 (PDT) Received: from [91.2.72.7] (helo=[192.168.71.36]) by smtprelay06.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1SeKFV-0001ze-6L; Tue, 12 Jun 2012 08:06:41 +0200 Message-ID: <4FD6DC6E.80408@lodderstedt.net> Date: Tue, 12 Jun 2012 08:06:38 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Phil Hunt References: <4E1F6AAD24975D4BA5B16804296739436652FBFC@TK5EX14MBXC284.redmond.corp.microsoft.com> <4FD6445B.8020904@lodderstedt.net> <2FCFF7EB-7E34-49F7-93EE-F57729E420F2@oracle.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Cache-Control headers for Bearer URI Query Parameter method X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 06:06:53 -0000 thanks a lot Am 12.06.2012 01:03, schrieb Phil Hunt: > Thanks. That makes sense. > > Phil > > On 2012-06-11, at 15:39, Amos Jeffries wrote: > >> On 12.06.2012 07:23, Phil Hunt wrote: >>> Private also seems inappropriate since no operation should be cached >>> for oauth as even when the same requestor. >>> >>> Phil >>> >> There is a difference in HTTP use-case between what the Bearer and core specs are covering. >> >> The core spec appears to be covering the request/response messages transferring credentials in the response entity. These mandate "no-store", which adds strict erasure requirements for any middleware and browser caches handling the response. Even single-user caches like a browser are not allowed to store the HTTP copy of the credentials response. >> >> Bearer is requiring "private" only in the specific HTTP case where the token is in query params and response is some data object (ie images or HTML page). Such that trusted proxies and other third-parties who do not implement OAuth but do relay HTTP treat the request and reply securely. With uses of Bearer via HTTP authentication framework this "private" is implicit. >> In these cases the response MAY be cached by a private browser cache, but not by third-party proxies. no-store is overkill and wastes bandwidth in this case. >> >> >> I hope this clarifies. >> >> >> AYJ >> >> >>> On 2012-06-11, at 12:17, Torsten Lodderstedt wrote: >>> >>>> Hi all, >>>> >>>> I noticed a difference in usage of cache control headers between bearer and core spec. >>>> >>>> core -27 states: >>>> >>>> " The authorization server MUST include the HTTP "Cache-Control" >>>> response header field [RFC2616] with a value of "no-store" in any >>>> response containing tokens, credentials, or other sensitive >>>> information, as well as the "Pragma" response header field [RFC2616] >>>> with a value of "no-cache"." >>>> >>>> So a "Pragma" response header field is required instead of the "Cache-Control" header "private". >> Not instead of. *As well as*. Pragma "no-cache" only tells the third-party to revalidate before using the response, it does not prevent storage and thus potential data leakage. >> >> >>>> As far as I understand, both specs are nearly but not fully equivalent. Do we need to align both? >>>> >>>> regards, >>>> Torsten. >>>> >>>> Am 09.06.2012 00:20, schrieb Mike Jones: >>>>> Hi Amos, >>>>> >>>>> The OAuth Bearer specification now includes the Cache-Control language we’d discussed. >>>>> >>>>> See the fifth paragraph of http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-20#section-2.3. >>>>> >>>>> Thanks again, >>>>> -- Mike >>>>> >>>>> >>>>> From: oauth-bounces@ietf.org On Behalf Of Mike Jones >>>>> Sent: Thursday, May 17, 2012 3:12 PM >>>>> Subject: [OAUTH-WG] Cache-Control headers for Bearer URI Query Parameter method >>>>> >>>>> Dear working group members: >>>>> >>>>> I'm going through the remaining open issues that have been raised about the Bearer spec so as to be ready to publish an updated draft once the outstanding consensus call issues are resolved. >>>>> >>>>> Amos Jeffries had cited this requirement in the HTTPbis spec ( http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-19#section-2.3.1): >>>>> >>>>> o The credentials carried in an Authorization header field are >>>>> specific to the User Agent, and therefore have the same effect on >>>>> HTTP caches as the "private" Cache-Control response directive, >>>>> within the scope of the request they appear in. >>>>> >>>>> Therefore, new authentication schemes which choose not to carry >>>>> credentials in the Authorization header (e.g., using a newly >>>>> defined header) will need to explicitly disallow caching, by >>>>> mandating the use of either Cache-Control request directives >>>>> (e.g., "no-store") or response directives (e.g., "private"). >>>>> >>>>> I propose to add the following text in order to satisfy this requirement. I have changed Amos' MUSTs to SHOULDs because, in practice, applications that have no option but to use the URI Query Parameter method are likely to also not have control over the request's Cache-Control directives (just as they do not have the ability to use an "Authorization: Bearer" header value): >>>>> >>>>> Clients using the URI Query Parameter method SHOULD also send a >>>>> Cache-Control header containing the "no-store" option. Server success >>>>> (2XX status) responses to these requests SHOULD contain a Cache-Control >>>>> header with the "private" option. >>>>> >>>>> Comments? >>>>> >>>>> -- Mike >>>>> >>>>> -----Original Message----- >>>>> From: Amos Jeffries >>>>> >>>>> On 24/04/2012 4:33 p.m., Mike Jones wrote: >>>>>> What specific language would you suggest be added to what section(s)? >>>>>> >>>>>> -- Mike >>>>> >>>>> Perhapse the last paragraph appended: >>>>> " >>>>> >>>>> Because of the security weaknesses associated with the URI method >>>>> (see Section 5), including the high likelihood that the URL >>>>> containing the access token will be logged, it SHOULD NOT be used >>>>> unless it is impossible to transport the access token in the >>>>> "Authorization" request header field or the HTTP request entity-body. >>>>> Resource servers compliant with this specification MAY support this >>>>> method. >>>>> >>>>> Clients requesting URL containing the access token MUST also send a >>>>> Cache-Control header containing the "no-store" option. Server success >>>>> (2xx status) responses to these requests MUST contain a Cache-Control >>>>> header with the "private" option. >>>>> >>>>> " >>>>> >>>>> I'm a little suspicious that the "SHOUDL NOT" in that top paragraph likely should be a MUST NOT to further discourage needless use. >>>>> >>>>> >>>>> AYJ >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: oauth-bounces@ietf.org On Behalf Of Amos Jeffries >>>>>> >>>>>> On 24.04.2012 13:46, 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 : The OAuth 2.0 Authorization Protocol: Bearer >>>>>>> Tokens >>>>>>> Author(s) : Michael B. Jones >>>>>>> Dick Hardt >>>>>>> David Recordon >>>>>>> Filename : draft-ietf-oauth-v2-bearer-19.txt >>>>>>> Pages : 24 >>>>>>> Date : 2012-04-23 >>>>>>> >>>>>>> This specification describes how to use bearer tokens in HTTP >>>>>>> requests to access OAuth 2.0 protected resources. Any party in >>>>>>> possession of a bearer token (a "bearer") can use it to get >>>>>>> access to >>>>>>> the associated resources (without demonstrating possession of a >>>>>>> cryptographic key). To prevent misuse, bearer tokens need to be >>>>>>> protected from disclosure in storage and in transport. >>>>>>> >>>>>>> >>>>>>> A URL for this Internet-Draft is: >>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-19.txt >>>>>> >>>>>> The section 2.3 (URL Query Parameter) text is still lacking explicit and specific security requirements. The overarching TLS requirement is good in general, but insufficient in the presence of HTTP intermediaries on the TLS connection path as is becoming a common practice. >>>>>> >>>>>> The upcoming HTTPbis specs document this issue as a requirement for new auth schemes such as Bearer: >>>>>> >>>>>> http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-19#section-2.3.1 >>>>>> " >>>>>> Therefore, new authentication schemes which choose not to carry >>>>>> credentials in the Authorization header (e.g., using a newly >>>>>> defined header) will need to explicitly disallow caching, by >>>>>> mandating the use of either Cache-Control request directives >>>>>> (e.g., "no-store") or response directives (e.g., "private"). >>>>>> " >>>>>> >>>>>> >>>>>> AYJ >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing 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 julian.reschke@gmx.de Tue Jun 12 01:54:47 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5158D21F85AD for ; Tue, 12 Jun 2012 01:54:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.369 X-Spam-Level: X-Spam-Status: No, score=-103.369 tagged_above=-999 required=5 tests=[AWL=-0.770, 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 jLEL2-8Z97-J for ; Tue, 12 Jun 2012 01:54:46 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id A6F7321F85A1 for ; Tue, 12 Jun 2012 01:54:45 -0700 (PDT) Received: (qmail invoked by alias); 12 Jun 2012 08:54:43 -0000 Received: from p54BB3983.dip.t-dialin.net (EHLO [192.168.178.36]) [84.187.57.131] by mail.gmx.net (mp032) with SMTP; 12 Jun 2012 10:54:43 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/ffpMeDtDfXhr2nliNdPD4igs9T/FYyGkT/G7h+U 62ljXfO9z6YL/W Message-ID: <4FD703C4.6050801@gmx.de> Date: Tue, 12 Jun 2012 10:54:28 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120604 Thunderbird/13.0 MIME-Version: 1.0 To: Mike Jones References: <4E1F6AAD24975D4BA5B16804296739436652F52D@TK5EX14MBXC284.redmond.corp.microsoft.com> <4FD4E9D4.2010808@gmx.de> <4E1F6AAD24975D4BA5B168042967394366531375@TK5EX14MBXC284.redmond.corp.microsoft.com> <4FD4F976.6090801@gmx.de> <4E1F6AAD24975D4BA5B1680429673943665316D1@TK5EX14MBXC284.redmond.corp.microsoft.com> <60F5CCB0-E036-4351-BD10-A44B33FCC5F6@ve7jtb.com> <255B9BB34FB7D647A506DC292726F6E114F5474E29@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B1680429673943665346D0@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943665346D0@TK5EX14MBXC284.redmond.corp.microsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 08:54:47 -0000 On 2012-06-12 00:16, Mike Jones wrote: > Reviewing the feedback from Julian, John, and James, I'm coming to the conclusion that client_id and client_secret, being for machines and not humans, should be ASCII, whereas username and password should be Unicode, since they are for humans. Per John's feedback, client_id can not contain a colon and be compatible with HTTP Basic. I'm not sure that restricting the character repertoire just because one way to send requires this is the right approach. My preference would be not to put this into the ABNF, and just to point out that certain characters will not work over certain transports, and to just advise to avoid them. > Therefore, I'd like to propose these updated ABNF definitions: > > VSCHAR = %20-7E > NOCOLONVSCHAR = %x20-39 / %x3B-7E > UNICODENOCTRLCHAR = > > client-id = *NOCOLONVSCHAR > client_secret = *VSCHAR > > username = *UNICODENOCTRLCHAR > password = *UNICODENOCTRLCHAR In this case you should add an introductory statement pointing out that the ABNF defines the grammar in terms of Unicode code points, not octets (as it is the case most of the time). > It turns out that non-ASCII characters are OK for username and password because the Core spec only passes them in the form body - not using HTTP Basic - and UTF-8 encoding is specified. I'll send a separate mail about that, the current text in the spec is way too unspecific. > -- Mike > > P.S. If anyone has a better ABNF for UNICODENOCTRLCHAR than "", please send it to me! As noted before, here's an example: Best regards, Julian From julian.reschke@gmx.de Tue Jun 12 02:13:05 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3D4621F8503 for ; Tue, 12 Jun 2012 02:13:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.241 X-Spam-Level: X-Spam-Status: No, score=-103.241 tagged_above=-999 required=5 tests=[AWL=-0.642, 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 zXEM5i-44UJH for ; Tue, 12 Jun 2012 02:13:05 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 77BEA21F853C for ; Tue, 12 Jun 2012 02:13:04 -0700 (PDT) Received: (qmail invoked by alias); 12 Jun 2012 09:13:03 -0000 Received: from p54BB3983.dip.t-dialin.net (EHLO [192.168.178.36]) [84.187.57.131] by mail.gmx.net (mp031) with SMTP; 12 Jun 2012 11:13:03 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18mPy4gyqkme6AJkSzRyVcUxYB6ZEnSnlUjD2DUpU J5RA1bSIbxIWio Message-ID: <4FD70812.6040108@gmx.de> Date: Tue, 12 Jun 2012 11:12:50 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120604 Thunderbird/13.0 MIME-Version: 1.0 To: "OAuth WG (oauth@ietf.org)" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: [OAUTH-WG] nits about definition of using form parameters X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 09:13:05 -0000 Hi there, re : This needs a normative reference to a spec that defines the application/x-www-form-urlencoded media type (such as ). Looking at the media type definition I don't see any mention of a charset parameter, so the example probably is wrong. See also : "Note: Parameters on the application/x-www-form-urlencoded MIME type are ignored. In particular, this MIME type does not support the charset parameter." I would also advise to change The client makes a request to the token endpoint by adding the following parameters using the "application/x-www-form-urlencoded" format in the HTTP request entity-body: grant_type REQUIRED. Value MUST be set to "password". username REQUIRED. The resource owner username, encoded as UTF-8. password REQUIRED. The resource owner password, encoded as UTF-8. scope OPTIONAL. The scope of the access request as described by Section 3.3. to The client makes a request to the token endpoint by sending the following parameters using the "application/x-www-form-urlencoded" format (Section 4.10.22.5 of [WD-html5-20120329]) and a character encoding of "UTF-8" in the HTTP request entity-body: grant_type REQUIRED. Value MUST be set to "password". username REQUIRED. The resource owner username. password REQUIRED. The resource owner password. scope OPTIONAL. The scope of the access request as described by Section 3.3. Finally, it would be good if the example used characters that require escaping in the body, such as "&", "%", or non-ASCII characters. (similar nits apply to other sections using form encoding) Best regards, Julian From zhoulinlin@cnnic.cn Tue Jun 12 03:38:32 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A90E021F8568 for ; Tue, 12 Jun 2012 03:38:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 50mg0KUPZP-D for ; Tue, 12 Jun 2012 03:38:31 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id 4D3A821F8582 for ; Tue, 12 Jun 2012 03:38:28 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: zhoulinlin@cnnic.cn Received: from unknown127.0.0.1 (HELO lenovo95e6383c) (127.0.0.1) by 127.0.0.1 with SMTP; Tue, 12 Jun 2012 18:38:22 +0800 From: "Linlin Zhou" To: "'Mike Jones'" , References: <4E1F6AAD24975D4BA5B16804296739436652F52D@TK5EX14MBXC284.redmond.corp.microsoft.com> <4FD4E9D4.2010808@gmx.de> <4E1F6AAD24975D4BA5B168042967394366531375@TK5EX14MBXC284.redmond.corp.microsoft.com> <4FD4F976.6090801@gmx.de> <4E1F6AAD24975D4BA5B1680429673943665316D1@TK5EX14MBXC284.redmond.corp.microsoft.com> <60F5CCB0-E036-4351-BD10-A44B33FCC5F6@ve7jtb.com> <255B9BB34FB7D647A506DC292726F6E114F5474E29@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B1680429673943665346D0@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943665346D0@TK5EX14MBXC284.redmond.corp.microsoft.com> Date: Tue, 12 Jun 2012 18:38:22 +0800 Message-ID: <002b01cd4887$7d742180$785c6480$@cn> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHNR+gPRaE+PhTJM0qj3EZzSy4QqZb1poqwgADW1SA= Content-Language: zh-cn Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 10:38:32 -0000 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of > Mike Jones > Sent: Tuesday, June 12, 2012 6:17 AM > To: oauth@ietf.org > Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF > definitions > > Reviewing the feedback from Julian, John, and James, I'm coming to the > conclusion that client_id and client_secret, being for machines and not humans, > should be ASCII, whereas username and password should be Unicode, since > they are for humans. Per John's feedback, client_id can not contain a colon > and be compatible with HTTP Basic. > As a person in the non-English half of the world, this sounds like a reasonable solution. > Therefore, I'd like to propose these updated ABNF definitions: > > VSCHAR = %20-7E > NOCOLONVSCHAR = %x20-39 / %x3B-7E > UNICODENOCTRLCHAR = / %x7F )> > > client-id = *NOCOLONVSCHAR > client_secret = *VSCHAR > > username = *UNICODENOCTRLCHAR > password = *UNICODENOCTRLCHAR > > It turns out that non-ASCII characters are OK for username and password > because the Core spec only passes them in the form body - not using HTTP > Basic - and UTF-8 encoding is specified. > > -- Mike > > P.S. If anyone has a better ABNF for UNICODENOCTRLCHAR than " Unicode character other than ( %x0-1F / %x7F )>", please send it to me! > > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of > Manger, James H > Sent: Monday, June 11, 2012 8:37 AM > To: oauth@ietf.org > Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF > definitions > > Are we so sure the non-english "half" of the world only use ASCII characters in > passwords? Sounds highly unlikely to me. > > > Given that, as you confirmed, UTF-8 "doesn't work with Basic and Digest"... > > It can work. It is just underspecified. So things can get messy. > draft-reschke-basicauth-enc-05 is a current draft (March 2012) attempting to > fix this as much as possible. > > Forcing ASCII password for people feels unacceptable. Better would be to say > OAuth servers accepting HTTP BASIC MUST accept UTF-8 encoded usernames > and passwords. A warning about interop problems with non-ASCII password is > ok. > > ASCII-only for usernames is almost as bad. I thought internationalized email > addresses were just standardized, and email addresses are often used as > usernames. > > For client id & password ASCII-only is less of an issue. These are values > configured into apps, not remembered by human brains. > > > -- > James Manger > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From jricher@mitre.org Tue Jun 12 06:37:03 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9568E21F8541 for ; Tue, 12 Jun 2012 06:37: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=[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 URSa5Vh4p94Y for ; Tue, 12 Jun 2012 06:37:01 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id B7D0821F85A1 for ; Tue, 12 Jun 2012 06:37:00 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 1624521B0F2F for ; Tue, 12 Jun 2012 09:37:00 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 09C3521B0F1B for ; Tue, 12 Jun 2012 09:37:00 -0400 (EDT) Received: from [129.83.50.12] (129.83.31.51) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server (TLS) id 14.2.283.3; Tue, 12 Jun 2012 09:36:59 -0400 Message-ID: <4FD745EE.1040508@mitre.org> Date: Tue, 12 Jun 2012 09:36:46 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: References: <4FD65080.9040305@gmail.com> <4FD65ED8.6000507@aol.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000401020106070701040202" X-Originating-IP: [129.83.31.51] Subject: Re: [OAUTH-WG] Clarification in Section 2.0 of draft-ietf-oauth-revocation-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 13:37:03 -0000 --------------000401020106070701040202 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit I agree with Doug and George's reading: nuking the refresh token gets rid of all access tokens associated with that refresh token's lifetime. This includes both simultaneous issuance as well as derived issuance. -- Justin On 06/11/2012 08:13 PM, doug foiles wrote: > Hi Paul and George, > Even though the Access Token is short lived, I would still like to > revoke it immediately if the user chooses to revoke the Refresh > Token. And I would love for the client application to only have to > make one web service call to accomplish that and not one for the > Refresh Token and another for the Access Token. > Given that we always generate a new Refresh Token value during "Token > Refresh", we would never have a true parent / child relationship > between a Refresh Token and Access Token. > Is there a case where it is NOT appropriate to revoke an "associated" > Access Token when explictly revoking a Refresh Token? I define > "associated" as an Access Token generated from a Refresh Token OR > generated at the same time of the Refresh Token. > I do see the AS challenges in trying to manage multiple > simultaneous "associated" Access Tokens. For example let's say a > client generates multiple Access Tokens at the same time while > generating new Refresh Token values during each "Token Refresh" > operation. However I don't really see the useful of this case. > Doug > > On Mon, Jun 11, 2012 at 3:52 PM, Paul Madsen > wrote: > > Hi George, perhaps it depends on the reason for the refresh token > being revoked. If because the user removed their consent then yes > I agree that *all* tokens should be revoked > > Sent from my iPhone > > On 2012-06-11, at 5:10 PM, George Fletcher > wrote: > >> Paul, >> >> I think I came to a different conclusion... >> >> If I use the Resource Owner Password Credential flow and get back >> both an access_token and a refresh_token then I would assume that >> the issued access_token is tied in some way to the refresh_token. >> If the refresh_token is revoked, then my expectation is that the >> simultaneous issued access_token would also be revoked. >> >> I read the spec as having a typo that should read... >> If the processed token is a refresh token and the authorization >> server supports the revocation of access tokens, then the >> authorization server SHOULD also invalidate all access tokens issued >> *based on* that refresh token. >> Or maybe better... "invalidate all access tokens >> associated/tied-to that refresh token". >> >> Now in the case that the client is retrieving a new refresh_token >> and access_token, then the new ones should be valid and the old >> ones potentially revoked. >> >> Thanks, >> George >> >> On 6/11/12 4:09 PM, Paul Madsen wrote: >>> Hi Doug, my interpretation is that 'for that refresh token' >>> means those access tokens issued in exchange for that refresh >>> token. >>> >>> Consequently, for the cases you cite below, the access tokens at >>> the same time as a given refresh token need not be invalidated >>> when that refresh token is 'processed' >>> >>> I assume the justification for the rule is that an access token >>> issued in exchange for a given refresh token may have been >>> compromised if the refresh token had been. But there is no such >>> causal relationship between an access token & refresh token >>> issued at same time >>> >>> paul >>> >>> On 6/11/12 3:31 PM, doug foiles wrote: >>>> Hi all, >>>> >>>> I was hoping to get some clarity on a statement in section 2.0 >>>> of draft-ietf-oauth-revocation-00. >>>> >>>> If the processed token is a refresh token and the authorization >>>> server supports the revocation of access tokens, then the >>>> authorization server SHOULD also invalidate all access tokens >>>> issued >>>> for that refresh token. >>>> >>>> My question is on the statement "access tokens issued for that >>>> refresh token". What does it mean to have an Access Token >>>> "issued" for a Refresh Token? >>>> >>>> This specific case is clear to me. I am refreshing an Access >>>> Token where I keep the same Refresh Token that I used to >>>> generate the new Access Token. I see the new Access Token was >>>> issued for that Refresh Token. >>>> However these two cases are a bit muddy to me. Let's say I am >>>> using the "Resource Owner Password Credentials Grant" where the >>>> Access Token Response returns both an Access Token and Refresh >>>> Token. Would the Access Token have been issued for that Refresh >>>> Token? And let's say I am refreshing an Access Token but choose >>>> to create a new Refresh Token and immediately revoke the >>>> original Refresh Token. Would the newly created Access Token >>>> have been issued for the original Refresh Token or the new one >>>> that was created. >>>> If a client would revoke a Refresh Token ... I would like the >>>> Access Tokens in all of the above cases to be automatically >>>> revoked as well. I just want to make sure I understand the >>>> model. Thanks. >>>> Doug Foiles >>>> Intuit >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing 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 --------------000401020106070701040202 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit I agree with Doug and George's reading: nuking the refresh token gets rid of all access tokens associated with that refresh token's lifetime. This includes both simultaneous issuance as well as derived issuance.

 -- Justin

On 06/11/2012 08:13 PM, doug foiles wrote:
Hi Paul and George,
 
Even though the Access Token is short lived, I would still like to revoke it immediately if the user chooses to revoke the Refresh Token.  And I would love for the client application to only have to make one web service call to accomplish that and not one for the Refresh Token and another for the Access Token.
 
Given that we always generate a new Refresh Token value during "Token Refresh", we would never have a true parent / child relationship between a Refresh Token and Access Token.
 
Is there a case where it is NOT appropriate to revoke an "associated" Access Token when explictly revoking a Refresh Token?  I define "associated" as an Access Token generated from a Refresh Token OR generated at the same time of the Refresh Token.
 
I do see the AS challenges in trying to manage multiple simultaneous "associated" Access Tokens.  For example let's say a client generates multiple Access Tokens at the same time while generating new Refresh Token values during each "Token Refresh" operation.  However I don't really see the useful of this case.
 
Doug

On Mon, Jun 11, 2012 at 3:52 PM, Paul Madsen <paul.madsen@gmail.com> wrote:
Hi George, perhaps it depends on the reason for the refresh token being revoked. If because the user removed their consent then yes I agree that *all* tokens should be revoked

Sent from my iPhone

On 2012-06-11, at 5:10 PM, George Fletcher <gffletch@aol.com> wrote:

Paul,

I think I came to a different conclusion...

If I use the Resource Owner Password Credential flow and get back both an access_token and a refresh_token then I would assume that the issued access_token is tied in some way to the refresh_token. If the refresh_token is revoked, then my expectation is that the simultaneous issued access_token would also be revoked.

I read the spec as having a typo that should read...
If the processed token is a refresh token and the authorization
server supports the revocation of access tokens, then the
authorization server SHOULD also invalidate all access tokens issued
*based on* that refresh token.
Or maybe better... "invalidate all access tokens associated/tied-to that refresh token".

Now in the case that the client is retrieving a new refresh_token and access_token, then the new ones should be valid and the old ones potentially revoked.

Thanks,
George

On 6/11/12 4:09 PM, Paul Madsen wrote:
Hi Doug, my interpretation is that 'for that refresh token' means those access tokens issued in exchange for that refresh token.

Consequently, for the cases you cite below, the access tokens at the same time as a given refresh token need not be invalidated when that refresh token is 'processed'

I assume the justification for the rule is that an access token issued in exchange for a given refresh token may have been compromised if the refresh token had been. But there is no such causal relationship between an access token & refresh token issued at same time

paul

On 6/11/12 3:31 PM, doug foiles wrote:
Hi all,

I was hoping to get some clarity on a statement in section 2.0 of draft-ietf-oauth-revocation-00.

　　 If the processed token is a refresh token and the authorization
　　 server supports the revocation of access tokens, then the
　　 authorization server SHOULD also invalidate all access tokens issued
　　 for that refresh token.

My question is on the statement "access tokens issued for that refresh token".　 What does it mean to have an Access Token "issued" for a Refresh Token?　

This specific case is clear to me.　 I am refreshing an Access Token where I keep the same Refresh Token that I used to generate the new Access Token.　 I see the new Access Token was issued for that Refresh Token.
However these two cases are a bit muddy to me.　 Let’s say I am using the "Resource Owner Password Credentials Grant" where the Access Token Response returns both an Access Token and Refresh Token.　 Would the Access Token have been issued for that Refresh Token?　 And let’s say I am refreshing an Access Token but choose to create a new Refresh Token and immediately revoke the original Refresh Token.　 Would the newly created Access Token have been issued for the original Refresh Token or the new one that was created.
If a client would revoke a Refresh Token … I would like the Access Tokens in all of the above cases to be automatically revoked as well.　 I just want to make sure I understand the model.　 Thanks.
Doug Foiles
Intuit

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

--------------000401020106070701040202-- From kris@yapp.us Sat Jun 9 10:31:39 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D7AE21F8737 for ; Sat, 9 Jun 2012 10:31:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.31 X-Spam-Level: X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_FWDLOOK=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ao+jiRjYfp3P for ; Sat, 9 Jun 2012 10:31:37 -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 F32E021F8733 for ; Sat, 9 Jun 2012 10:31:36 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so3825865pbc.31 for ; Sat, 09 Jun 2012 10:31:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=6q/fdwk/GztfNNA8iuz4U5GGgvcnbgQuOWglGBDwFLM=; b=ZH+qTJKeC3U6rADlbCNCSBF2YVdyWxymaQAtV5smQRsgr0VJgaJr+uktzn6jea7sD1 AcVaODVPEJjfwFg5jhpXLnpYB/0glH/efDXBi7en92Aca8Gy6UkVC9uaHmJbIJTg5oKq JC7Sbi3WmrZ0YHbY/dZBarRqZs+9azFbtO2N+HzQsYdHzc2+miTYzafHVxFzjKEnjI8e 7mW9sWDxOO/e92Vm/XGxN591FUKhBn02U3l4+7iFnF9leeQif6S4seXVmpmLpFghuAQ2 bi2tO5o/TPwIz69wxBQU2WC2JNHhhLgtGLR0RQ9yeL6dorO0sdX4HVByv55nna6n8VVp k48g== Received: by 10.68.200.165 with SMTP id jt5mr8139805pbc.90.1339263096690; Sat, 09 Jun 2012 10:31:36 -0700 (PDT) Received: from [10.0.1.7] (c-24-17-231-146.hsd1.wa.comcast.net. [24.17.231.146]) by mx.google.com with ESMTPS id pe2sm12009101pbc.59.2012.06.09.10.31.35 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 09 Jun 2012 10:31:36 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_158462A1-9862-4F33-859C-3695633B9298" From: Kristofor Selden In-Reply-To: <138877F6-BDF5-4EE1-9934-A40B7450EAF8@gmail.com> Date: Sat, 9 Jun 2012 10:31:34 -0700 Message-Id: References: <0CBAEB56DDB3A140BA8E8C124C04ECA201068743@P3PWEX2MB008.ex2.secureserver.net> <138877F6-BDF5-4EE1-9934-A40B7450EAF8@gmail.com> To: Dick Hardt X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQlMfYI2bC2scnEaDEnsz2I1Qcj+wyRwVuIwGKL9Rc8DXLyK7QZKqJQ5ee4SVBmm3ALjepgl X-Mailman-Approved-At: Tue, 12 Jun 2012 09:42:39 -0700 Cc: "oauth@ietf.org WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] New draft process / editor role X-BeenThere: oauth@ietf.org X-Mailman-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, 09 Jun 2012 18:49:10 -0000 --Apple-Mail=_158462A1-9862-4F33-859C-3695633B9298 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > Can we move forward with the work at hand now? I find your tone to be dismissive =96 which in general isn't in the = spirit of moving things forward. Your comment on the MAC spec is = tangential. Hannes never replied that Eran's request to wait for the ABNF was a = problem nor to confirm Mike's assertion of Hannes' intent = (http://www.ietf.org/mail-archive/web/oauth/current/msg09111.html). I can understand why Eran would feel blindsided. That being said, it would be nice if further list discussion was forward = looking and the looking back discussion was with the chairs.= --Apple-Mail=_158462A1-9862-4F33-859C-3695633B9298 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Can we move forward with the work at hand = now?

I find your tone to be = dismissive =96 which in general isn't in the spirit of moving things = forward.  Your comment on the MAC spec is = tangential.

Hannes never replied that Eran's request = to wait for the ABNF was a problem nor to confirm Mike's assertion of = Hannes' intent (= http://www.ietf.org/mail-archive/web/oauth/current/msg09111.html).
I can understand why Eran would feel = blindsided.

That being said, it would be nice = if further list discussion was forward looking and the looking back = discussion was with the chairs.
= --Apple-Mail=_158462A1-9862-4F33-859C-3695633B9298-- From doug.foiles@gmail.com Tue Jun 12 10:09:40 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CD6421F8627 for ; Tue, 12 Jun 2012 10:09:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.366 X-Spam-Level: X-Spam-Status: No, score=-3.366 tagged_above=-999 required=5 tests=[AWL=0.232, 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 oofK-Ikcqig0 for ; Tue, 12 Jun 2012 10:09:39 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 37E2E21F858A for ; Tue, 12 Jun 2012 10:09:39 -0700 (PDT) Received: by yenq13 with SMTP id q13so4242892yen.31 for ; Tue, 12 Jun 2012 10:09:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=A5xpw9aGbRbNGdf7wshuiOluEG6dhkGILuZoBGPXxOQ=; b=qyRJtfNuLKX8Y6V0HO6hdNF6RP5/slNFB3wfdJh+hY6FvSDi4pxmZWJyvkK4luZ67/ JCadiTBTCiaGUyNkTPmCp1eCphs3Ug/j+YO4nuUYRSA7hpZbPKynQFoxgGnhQH+4h44P B+dJ/9lqaqo9SRch0klNGjGHAswgswupGjWjdCWbKPudC0GFNTei0Mdb51Dw4Vla6FSh AMLzkS3VKRcH0NNaAzMoNPhO19BSbL0m61YUuGJzV0/mV0p78QUHrgDYHrRuO8DI5aZ7 +ef+DGbuWpl5tQAuamn1t9fHQlI6ubVXGXWlhSq1449R0MJ4ezsFomBCJojVpWGVWDnP AuLg== MIME-Version: 1.0 Received: by 10.50.203.39 with SMTP id kn7mr8922901igc.53.1339520978405; Tue, 12 Jun 2012 10:09:38 -0700 (PDT) Received: by 10.231.199.135 with HTTP; Tue, 12 Jun 2012 10:09:38 -0700 (PDT) In-Reply-To: <4FD745EE.1040508@mitre.org> References: <4FD65080.9040305@gmail.com> <4FD65ED8.6000507@aol.com> <4FD745EE.1040508@mitre.org> Date: Tue, 12 Jun 2012 10:09:38 -0700 Message-ID: From: doug foiles To: Justin Richer , torsten@lodderstedt.net, sDronia@gmx.de, mscurtescu@google.com Content-Type: multipart/alternative; boundary=14dae9341097164a1404c24988f2 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Clarification in Section 2.0 of draft-ietf-oauth-revocation-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 17:09:40 -0000 --14dae9341097164a1404c24988f2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Thanks Justin. Perhaps we can get Torsten, Stefanie, or Marius to comment on what was intended for this ... and would be much appreciated. On Tue, Jun 12, 2012 at 6:36 AM, Justin Richer wrote: > I agree with Doug and George's reading: nuking the refresh token gets rid > of all access tokens associated with that refresh token's lifetime. This > includes both simultaneous issuance as well as derived issuance. > > -- Justin > > > On 06/11/2012 08:13 PM, doug foiles wrote: > > Hi Paul and George, > > Even though the Access Token is short lived, I would still like to revoke > it immediately if the user chooses to revoke the Refresh Token. And I > would love for the client application to only have to make one web servic= e > call to accomplish that and not one for the Refresh Token and another for > the Access Token. > > Given that we always generate a new Refresh Token value during "Token > Refresh", we would never have a true parent / child relationship between = a > Refresh Token and Access Token. > > Is there a case where it is NOT appropriate to revoke an "associated" > Access Token when explictly revoking a Refresh Token? I define > "associated" as an Access Token generated from a Refresh Token OR generat= ed > at the same time of the Refresh Token. > > I do see the AS challenges in trying to manage multiple > simultaneous "associated" Access Tokens. For example let's say a client > generates multiple Access Tokens at the same time while generating new > Refresh Token values during each "Token Refresh" operation. However I > don't really see the useful of this case. > > Doug > > On Mon, Jun 11, 2012 at 3:52 PM, Paul Madsen wrote= : > >> Hi George, perhaps it depends on the reason for the refresh token being >> revoked. If because the user removed their consent then yes I agree that >> *all* tokens should be revoked >> >> Sent from my iPhone >> >> On 2012-06-11, at 5:10 PM, George Fletcher wrote: >> >> Paul, >> >> I think I came to a different conclusion... >> >> If I use the Resource Owner Password Credential flow and get back both a= n >> access_token and a refresh_token then I would assume that the issued >> access_token is tied in some way to the refresh_token. If the refresh_to= ken >> is revoked, then my expectation is that the simultaneous issued >> access_token would also be revoked. >> >> I read the spec as having a typo that should read... >> >> If the processed token is a refresh token and the authorization >> server supports the revocation of access tokens, then the >> authorization server SHOULD also invalidate all access tokens issued >> *based on* that refresh token. >> >> Or maybe better... "invalidate all access tokens associated/tied-to that >> refresh token". >> >> Now in the case that the client is retrieving a new refresh_token and >> access_token, then the new ones should be valid and the old ones >> potentially revoked. >> >> Thanks, >> George >> >> On 6/11/12 4:09 PM, Paul Madsen wrote: >> >> Hi Doug, my interpretation is that 'for that refresh token' means those >> access tokens issued in exchange for that refresh token. >> >> Consequently, for the cases you cite below, the access tokens at the sam= e >> time as a given refresh token need not be invalidated when that refresh >> token is 'processed' >> >> I assume the justification for the rule is that an access token issued i= n >> exchange for a given refresh token may have been compromised if the refr= esh >> token had been. But there is no such causal relationship between an acce= ss >> token & refresh token issued at same time >> >> paul >> >> On 6/11/12 3:31 PM, doug foiles wrote: >> >> Hi all, >> >> I was hoping to get some clarity on a statement in section 2.0 of >> draft-ietf-oauth-revocation-00. >> >> If the processed token is a refresh token and the authorization >> server supports the revocation of access tokens, then the >> authorization server SHOULD also invalidate all access tokens issued >> for that refresh token. >> >> My question is on the statement "access tokens issued for that refresh >> token". What does it mean to have an Access Token "issued" for a Refresh >> Token? >> >> This specific case is clear to me. I am refreshing an Access Token where >> I keep the same Refresh Token that I used to generate the new Access Tok= en. >> I see the new Access Token was issued for that Refresh Token. >> However these two cases are a bit muddy to me. Let=92s say I am using th= e >> "Resource Owner Password Credentials Grant" where the Access Token Respo= nse >> returns both an Access Token and Refresh Token. Would the Access Token h= ave >> been issued for that Refresh Token? And let=92s say I am refreshing an A= ccess >> Token but choose to create a new Refresh Token and immediately revoke th= e >> original Refresh Token. Would the newly created Access Token have been >> issued for the original Refresh Token or the new one that was created. >> If a client would revoke a Refresh Token =85 I would like the Access Tok= ens >> in all of the above cases to be automatically revoked as well. I just wa= nt >> to make sure I understand the model. Thanks. >> Doug Foiles >> Intuit >> >> >> _______________________________________________ >> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oa= uth >> >> >> >> _______________________________________________ >> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oa= uth >> >> >> > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau= th > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --14dae9341097164a1404c24988f2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks Justin.=C2=A0 Perhaps we can get Torsten, Stefanie, or Marius to comment on what was intended for this = ... and would be much appreciated.

On Tue, Jun 12, 2012 at 6:36 AM, Justin Richer <= span dir=3D"ltr"><jricher@mitre.org> wrote:
I agree with Doug and George'= s reading: nuking the refresh token gets rid of all access tokens associate= d with that refresh token's lifetime. This includes both simultaneous i= ssuance as well as derived issuance.

=C2=A0-- Justin=20


On 06/11/2012 08:13 PM, doug foiles wrote:=20
Hi Paul and George,
=C2=A0
Even though the Access Token is short lived, I would still like to rev= oke it immediately if the user chooses to revoke the Refresh Token.=C2=A0 A= nd I would love for the client application to only have to make one web ser= vice call to accomplish that and not one for the Refresh Token and another = for the Access Token.
=C2=A0
Given that we always generate a new Refresh Token value during "T= oken Refresh", we would never have a true parent / child relationship = between a Refresh Token and Access Token.
=C2=A0
Is there a case where it is NOT appropriate to revoke an "associa= ted" Access Token=C2=A0when explictly revoking a Refresh Token?=C2=A0 = I define "associated" as an Access Token generated from a Refresh= Token OR generated at the same time of the Refresh Token.
=C2=A0
I do see the AS challenges in trying to manage multiple simultaneous= =C2=A0"associated" Access Tokens.=C2=A0 For example let's say= a client generates multiple Access Tokens at the same time while generatin= g new Refresh Token values during each "Token Refresh" operation.= =C2=A0 However I don't really see the useful of this case.
=C2=A0
Doug

On Mon, Jun 11, 2012 at 3:52 PM, Paul Madsen <paul.madsen@gmail.com> wrote:
Hi George, perhaps it depends on the reason for the refresh token bein= g revoked. If because the user removed their consent then yes I agree that = *all* tokens should be revoked

Sent from my iPhone

On 2012-06-11, at 5:10 PM, George Fletcher <gffletch@aol.com> wrote:

<= /div>
Paul,

I think I came to a different conclusion...

If I = use the Resource Owner Password Credential flow and get back both an access= _token and a refresh_token then I would assume that the issued access_token= is tied in some way to the refresh_token. If the refresh_token is revoked,= then my expectation is that the simultaneous issued access_token would als= o be revoked.

I read the spec as having a typo that should read...
If the pro=
cessed token is a refresh token and the authorization
server supports the revocation of access tokens, then the
authorization server SHOULD also invalidate all access tokens issued
*based on* that refresh token.
Or maybe better... "invalidate all= access tokens associated/tied-to that refresh token".

Now in t= he case that the client is retrieving a new refresh_token and access_token,= then the new ones should be valid and the old ones potentially revoked.
Thanks,
George

On 6/11/12 4:09 PM, Paul Madsen wrote:=20
Hi Doug, my interpretation i= s that 'for that refresh token' means those access tokens issued in= exchange for that refresh token.

Consequently, for the cases you c= ite below, the access tokens at the same time as a given refresh token need= not be invalidated when that refresh token is 'processed'

I assume the justification for the rule is that an access token issued = in exchange for a given refresh token may have been compromised if the refr= esh token had been. But there is no such causal relationship between an acc= ess token & refresh token issued at same time

paul

On 6/11/12 3:31 PM, doug foiles wrote:=20
Hi all,

I was hoping to get some clarity on a statement in section 2.0 of = draft-ietf-oauth-revocation-00.

=E3=80=80=E3=80=80 If the processed token is a refresh token and t= he authorization
=E3=80=80=E3=80=80 server supports the revocation of ac= cess tokens, then the
=E3=80=80=E3=80=80 authorization server SHOULD als= o invalidate all access tokens issued
=E3=80=80=E3=80=80 for that refres= h token.

My question is on the statement "access tokens issued for tha= t refresh token".=E3=80=80 What does it mean to have an Access Token &= quot;issued" for a Refresh Token?=E3=80=80

This specific case is clear to me.=E3=80=80 I am refreshing an Acc= ess Token where I keep the same Refresh Token that I used to generate the n= ew Access Token.=E3=80=80 I see the new Access Token was issued for that Re= fresh Token.
However these two cases are a bit muddy to me.=E3=80=80 Let=E2=80=99s = say I am using the "Resource Owner Password Credentials Grant" wh= ere the Access Token Response returns both an Access Token and Refresh Toke= n.=E3=80=80 Would the Access Token have been issued for that Refresh Token?= =E3=80=80 And let=E2=80=99s say I am refreshing an Access Token but choose = to create a new Refresh Token and immediately revoke the original Refresh T= oken.=E3=80=80 Would the newly created Access Token have been issued for th= e original Refresh Token or the new one that was created.
If a client would revoke a Refresh Token =E2=80=A6 I would like the Ac= cess Tokens in all of the above cases to be automatically revoked as well.= =E3=80=80 I just want to make sure I understand the model.=E3=80=80 Thanks.=
Doug Foiles
Intuit

_______________________________________________
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


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


--14dae9341097164a1404c24988f2-- From derek@ihtfp.com Tue Jun 12 10:28:38 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B72521F863E for ; Tue, 12 Jun 2012 10:28:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.988 X-Spam-Level: X-Spam-Status: No, score=-101.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, 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 xbzbrouaAYVD for ; Tue, 12 Jun 2012 10:28:37 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) by ietfa.amsl.com (Postfix) with ESMTP id 6EA1C21F8643 for ; Tue, 12 Jun 2012 10:28:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 91BD1260286; Tue, 12 Jun 2012 13:28:36 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 16241-03; Tue, 12 Jun 2012 13:28:32 -0400 (EDT) Received: from mocana.ihtfp.org (unknown [12.208.167.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (not verified)) by mail2.ihtfp.org (Postfix) with ESMTPS id 6EC7A260211; Tue, 12 Jun 2012 13:28:31 -0400 (EDT) Received: (from warlord@localhost) by mocana.ihtfp.org (8.14.5/8.14.5/Submit) id q5CHSScI011701; Tue, 12 Jun 2012 13:28:28 -0400 From: Derek Atkins To: Eran Hammer Date: Tue, 12 Jun 2012 13:28:27 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: Maia Mailguard 1.0.2a Cc: oauth@ietf.org Subject: [OAUTH-WG] On the OAuth Core Spec X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 17:28:38 -0000 Eran (and the rest of the OAuth WG), Hannes and I would like to apologize for what transpired last week with the publication of version 27 of the OAuth core specification. It was not our intention to get a document published behind your back, the goal was the get a document published in a more timely manner than it appeared you could provide. Coincidentally there was a communication breakdown where we had an expectation that your co-authors would keep you in the loop about what was going on. We clearly should have been more proactive in doing that ourselves instead of expecting others to do it for us. Moreover, I was not privy to any agreement that you may have had about being "sole editor", so I had no reason to believe that there would have been any particular issue with getting another version of the draft out when you were busy. So, we're sorry. We're also sorry we weren't more clear that we really did need to get a draft out. I'll be sure that Hannes and I are both more clear going forward when there are timely dependencies. Having said that, are you still willing and able to be the editor of this draft and see it to its conclusion and publication? If so, we will need to get another draft out by this Friday (June 15), and I suspect we'll need another draft that solves the encoding issue (brought up by the ABNF exercise), targeting Friday, June 29th. Do you think you can make these target dates (assuming that there is text for you to apply to the draft)? Thanks, and again, our apologies, -derek, co-chair -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From hannes.tschofenig@gmx.net Tue Jun 12 11:01:20 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DDCA21F8599 for ; Tue, 12 Jun 2012 11:01:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.949 X-Spam-Level: X-Spam-Status: No, score=-101.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 H0N-4oyuzqO5 for ; Tue, 12 Jun 2012 11:01:19 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 160FF21F8593 for ; Tue, 12 Jun 2012 11:01:18 -0700 (PDT) Received: (qmail invoked by alias); 12 Jun 2012 18:01:17 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.102]) [88.115.216.191] by mail.gmx.net (mp032) with SMTP; 12 Jun 2012 20:01:17 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1//XTp0cHr/SaMTqJ0RCViQA32316XyYafFYGqrOC LrnVHtLcLLXmks Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <4FD703C4.6050801@gmx.de> Date: Tue, 12 Jun 2012 21:01:14 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <5E38109E-2123-418B-8D45-B8DF4287790D@gmx.net> References: <4E1F6AAD24975D4BA5B16804296739436652F52D@TK5EX14MBXC284.redmond.corp.microsoft.com> <4FD4E9D4.2010808@gmx.de> <4E1F6AAD24975D4BA5B168042967394366531375@TK5EX14MBXC284.redmond.corp.microsoft.com> <4FD4F976.6090801@gmx.de> <4E1F6AAD24975D4BA5B1680429673943665316D1@TK5EX14MBXC284.redmond.corp.microsoft.com> <60F5CCB0-E036-4351-BD10-A44B33FCC5F6@ve7jtb.com> <255B9BB34FB7D647A506DC292726F6E114F5474E29@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B1680429673943665346D0@TK5EX14MBXC284.redmond.corp.microsoft.com> <4FD703C4.6050801@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 18:01:20 -0000 I had a chat with Julian yesterday and here is my short summary.=20 Section 2.3 of the core draft defines client authentication based on two = mechanisms (and provides room for extensions): = http://tools.ietf.org/html/draft-ietf-oauth-v2-27#section-2.3 1) HTTP Basic Authentication 2) A custom OAuth authentication mechanism (which uses client_id and = client_secret) With HTTP Basic authentication the problem is that this is a legacy = technology and there is no internationalization support.=20 With our brand new custom OAuth authentication mechanism we have more = options.=20 One possible approach is to say that the clients are devices (and not = end users) and therefore internationalization does not matter.=20 Is it, however, really true that only US-ASCII characters will appear in = the client_id and also in the client_secret?=20 Here we have the possibility to define something better.=20 In any case we have to restrict the characters that are used in these = two authentication mechanisms since they could conflict with the way how = we transport the data over the underlying protocol. Julian mentioned = this in his previous mails.=20 Julian, maybe you can provide a detailed text proposal for how to = address your comment in case we go for UTF8 (with % encoding) for the = custom OAuth client authentication mechanism?=20 Ciao Hannes On Jun 12, 2012, at 11:54 AM, Julian Reschke wrote: > On 2012-06-12 00:16, Mike Jones wrote: >> Reviewing the feedback from Julian, John, and James, I'm coming to = the conclusion that client_id and client_secret, being for machines and = not humans, should be ASCII, whereas username and password should be = Unicode, since they are for humans. Per John's feedback, client_id can = not contain a colon and be compatible with HTTP Basic. >=20 > I'm not sure that restricting the character repertoire just because = one way to send requires this is the right approach. My preference would = be not to put this into the ABNF, and just to point out that certain = characters will not work over certain transports, and to just advise to = avoid them. >=20 >> Therefore, I'd like to propose these updated ABNF definitions: >>=20 >> VSCHAR =3D %20-7E >> NOCOLONVSCHAR =3D %x20-39 / %x3B-7E >> UNICODENOCTRLCHAR =3D >>=20 >> client-id =3D *NOCOLONVSCHAR >> client_secret =3D *VSCHAR >>=20 >> username =3D *UNICODENOCTRLCHAR >> password =3D *UNICODENOCTRLCHAR >=20 > In this case you should add an introductory statement pointing out = that the ABNF defines the grammar in terms of Unicode code points, not = octets (as it is the case most of the time). >=20 >> It turns out that non-ASCII characters are OK for username and = password because the Core spec only passes them in the form body - not = using HTTP Basic - and UTF-8 encoding is specified. >=20 > I'll send a separate mail about that, the current text in the spec is = way too unspecific. >=20 >> -- Mike >>=20 >> P.S. If anyone has a better ABNF for UNICODENOCTRLCHAR than "", please send it to me! >=20 > As noted before, here's an example: = >=20 > Best regards, Julian > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From wmills@yahoo-inc.com Tue Jun 12 11:17:34 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 034DC21F84C8 for ; Tue, 12 Jun 2012 11:17:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.994 X-Spam-Level: X-Spam-Status: No, score=-16.994 tagged_above=-999 required=5 tests=[AWL=0.603, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3TnvJGmqtHLw for ; Tue, 12 Jun 2012 11:17:32 -0700 (PDT) Received: from nm17.bullet.mail.sp2.yahoo.com (nm17.bullet.mail.sp2.yahoo.com [98.139.91.87]) by ietfa.amsl.com (Postfix) with SMTP id D865B21F84B6 for ; Tue, 12 Jun 2012 11:17:32 -0700 (PDT) Received: from [98.139.91.68] by nm17.bullet.mail.sp2.yahoo.com with NNFMP; 12 Jun 2012 18:17:32 -0000 Received: from [72.30.22.33] by tm8.bullet.mail.sp2.yahoo.com with NNFMP; 12 Jun 2012 18:17:32 -0000 Received: from [127.0.0.1] by omp1061.mail.sp2.yahoo.com with NNFMP; 12 Jun 2012 18:17:32 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 778106.77510.bm@omp1061.mail.sp2.yahoo.com Received: (qmail 18491 invoked by uid 60001); 12 Jun 2012 18:17:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1339525052; bh=2S0vKXKE5VQKKnHnp5UPusinNeGJ8SxpNvrNx3byRrM=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Hbnliyfssn9qpHYPM9iWkM9m1+sLWR1W61yJZZlqZcjryHAu9nk587BgtzviNiHiPMYnmAG/AK8C1Z4sDJRaeaf8VvsZfxwsUObSS86iLPNXp/FI42E3TFh0yXL6LPVfCGDxZkUQJ/Bpph6umpRn/qRVCTkWJPCJ0IvXUH20Srs= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=GkdQGN4g3ypaeUI6MQYqWctmFtHTeC9BDtkEIDxAOhkV/DjJ6R5UDeOOu5oaXHqSW2VVpQSw5oV/ihYfJTrgcpddXMcPuJDkdKSZXTcZHeM1AI/xaGswY9IUDRaNpFqcBRuIqjz396RA85+73RN+cAwpe3m0YLlGN0/xRRae5YE=; X-YMail-OSG: DeHgd5oVM1nXZwiLW23G7BYiSUiZZlO3y0yLtfQcrqaSQmS N67h_Jn5MmFvLXehZ_mSI9O74qDLjWXBPe7zCJCJ1z9mQh92FJMawWZv_0Qj sxLcVJbWJ_Jn2jA5ymaW0k5D.pTRbIWrri3o9mjE_j07vHeVaqvfYWgKQ77W Tesj38ORWa0YPThLlyzHmG7bVnmFoNnwQILi2SCcYtC3xrFvZumLQnuyWx7d bx1NpNOmDZ.1LOC2IcJJmlUORvyVCuzEsNqt6zjrA23DjQLqtZmqJwWye45b F4gZFqZRxe56uqAEViQptlcvS8ZrgmxOjviBVT6kL4s.BtaIekhSj8pX0jhz YrGupAV4AjIwgiQ57p2cvHjCAfYR1uaTrwHZF4oq2uawTt0f0A2Xc5H8Himz WXElfgI5zLaTEz9qaGqSfqSc_KBI_DBlnfwwWJaTCgSC7mnKwe8BrnbNWuSM 9Xixy0OYnDcXB37vUWeNF3IvgGQQUbUTKt5VbEgB_Vnqq_AYyuEqh_6KaJ0U 1c9HrFisKIZREOV0LkFQl Received: from [209.131.62.115] by web31807.mail.mud.yahoo.com via HTTP; Tue, 12 Jun 2012 11:17:32 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.118.349524 References: <4E1F6AAD24975D4BA5B16804296739436652F52D@TK5EX14MBXC284.redmond.corp.microsoft.com> <4FD4E9D4.2010808@gmx.de> <4E1F6AAD24975D4BA5B168042967394366531375@TK5EX14MBXC284.redmond.corp.microsoft.com> <4FD4F976.6090801@gmx.de> <4E1F6AAD24975D4BA5B1680429673943665316D1@TK5EX14MBXC284.redmond.corp.microsoft.com> <60F5CCB0-E036-4351-BD10-A44B33FCC5F6@ve7jtb.com> <255B9BB34FB7D647A506DC292726F6E114F5474E29@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B1680429673943665346D0@TK5EX14MBXC284.redmond.corp.microsoft.com> <4FD703C4.6050801@gmx.de> <5E38109E-2123-418B-8D45-B8DF4287790D@gmx.net> Message-ID: <1339525052.8121.YahooMailNeo@web31807.mail.mud.yahoo.com> Date: Tue, 12 Jun 2012 11:17:32 -0700 (PDT) From: William Mills To: Hannes Tschofenig , Julian Reschke In-Reply-To: <5E38109E-2123-418B-8D45-B8DF4287790D@gmx.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-125733401-428407859-1339525052=:8121" Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 18:17:34 -0000 ---125733401-428407859-1339525052=:8121 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I agree generally with your assumption about clients, but rather than sayin= g "clients are devices" I think it makes much more sense to say "clients ar= e NOT users, so client_id need not be internationalized".=A0 In practical t= erms there is very little to argue for anythign beyond ASCII in a client_se= cret, base64 encoding or the equivalent being a fine way to transport arbit= rary bits in a portable/reasonable way.=0A=0AI argue that client_id need no= t be internationalized because I assume that any really internationalized a= pplication will have an internationalized presentation layer that's present= ing a pretty name for the client_id.=0A=0A-bill=0A=0A=0A=0A=0A>____________= ____________________=0A> From: Hannes Tschofenig =0A>To: Julian Reschke =0A>Cc: "oauth@ietf.org" =0A>Sent: Tuesday, June 12, 2012 11:01 AM=0A>Subject: Re: [O= AUTH-WG] Discussion needed on username and password ABNF definitions=0A> = =0A>I had a chat with Julian yesterday and here is my short summary. =0A>= =0A>Section 2.3 of the core draft defines client authentication based on tw= o mechanisms (and provides room for extensions): http://tools.ietf.org/html= /draft-ietf-oauth-v2-27#section-2.3=0A>=0A>1) HTTP Basic Authentication=0A>= =0A>2) A custom OAuth authentication mechanism (which uses client_id and cl= ient_secret)=0A>=0A>With HTTP Basic authentication the problem is that this= is a legacy technology and there is no internationalization support. =0A>= =0A>With our brand new custom OAuth authentication mechanism we have more o= ptions. =0A>=0A>One possible approach is to say that the clients are device= s (and not end users) and therefore internationalization does not matter. = =0A>=0A>Is it, however, really true that only US-ASCII characters will appe= ar in the client_id and also in the client_secret? =0A>=0A>Here we have the= possibility to define something better. =0A>=0A>In any case we have to res= trict the characters that are used in these two authentication mechanisms s= ince they could conflict with the way how we transport the data over the un= derlying protocol. Julian mentioned this in his previous mails. =0A>=0A>Jul= ian, maybe you can provide a detailed text proposal for how to address your= comment in case we go for UTF8 (with % encoding) for the custom OAuth clie= nt authentication mechanism? =0A>=0A>Ciao=0A>Hannes=0A>=0A>On Jun 12, 2012,= at 11:54 AM, Julian Reschke wrote:=0A>=0A>> On 2012-06-12 00:16, Mike Jone= s wrote:=0A>>> Reviewing the feedback from Julian, John, and James, I'm com= ing to the conclusion that client_id and client_secret, being for machines = and not humans, should be ASCII, whereas username and password should be Un= icode, since they are for humans.=A0 Per John's feedback, client_id can not= contain a colon and be compatible with HTTP Basic.=0A>> =0A>> I'm not sure= that restricting the character repertoire just because one way to send req= uires this is the right approach. My preference would be not to put this in= to the ABNF, and just to point out that certain characters will not work ov= er certain transports, and to just advise to avoid them.=0A>> =0A>>> Theref= ore, I'd like to propose these updated ABNF definitions:=0A>>> =0A>>>=A0 = =A0 VSCHAR =3D %20-7E=0A>>>=A0 =A0 NOCOLONVSCHAR =3D %x20-39 / %x3B-7E=0A= >>>=A0 =A0 UNICODENOCTRLCHAR =3D =0A>>> =0A>>>=A0 =A0 client-id =3D *NOCOLONVSCHAR=0A>>>=A0 =A0 = client_secret =3D *VSCHAR=0A>>> =0A>>>=A0 =A0 username =3D *UNICODENOCTRL= CHAR=0A>>>=A0 =A0 password =3D *UNICODENOCTRLCHAR=0A>> =0A>> In this case = you should add an introductory statement pointing out that the ABNF defines= the grammar in terms of Unicode code points, not octets (as it is the case= most of the time).=0A>> =0A>>> It turns out that non-ASCII characters are = OK for username and password because the Core spec only passes them in the = form body - not using HTTP Basic - and UTF-8 encoding is specified.=0A>> = =0A>> I'll send a separate mail about that, the current text in the spec is= way too unspecific.=0A>> =0A>>> =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 --= Mike=0A>>> =0A>>> P.S.=A0 If anyone has a better ABNF for UNICODENOCTRLCHA= R than "", please send = it to me!=0A>> =0A>> As noted before, here's an example: =0A>> =0A>> Best regards, J= ulian=0A>> _______________________________________________=0A>> OAuth maili= ng list=0A>> OAuth@ietf.org=0A>> https://www.ietf.org/mailman/listinfo/oaut= h=0A>=0A>_______________________________________________=0A>OAuth mailing l= ist=0A>OAuth@ietf.org=0A>https://www.ietf.org/mailman/listinfo/oauth=0A>=0A= >=0A> ---125733401-428407859-1339525052=:8121 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
I agree generally with your assumption about clients, but rather than say= ing "clients are devices" I think it makes much more sense to say "clients = are NOT users, so client_id need not be internationalized".  In practi= cal terms there is very little to argue for anythign beyond ASCII in a clie= nt_secret, base64 encoding or the equivalent being a fine way to transport = arbitrary bits in a portable/reasonable way.

I argue that client_id need not be internationalized b= ecause I assume that any really internationalized application will have an = internationalized presentation layer that's presenting a pretty name for th= e client_id.

-bill

From:= Hannes Tschofenig <hannes.tschofenig@gmx.net>
To: Julian Reschke <julian.reschke@gmx.de= >
Cc: "oauth@ietf.o= rg" <oauth@ietf.org>
Sent:= Tuesday, June 12, 2012 11:01 AM
Subject: Re: [OAUTH-WG] Discussion needed on username= and password ABNF definitions

=0AI had a chat with = Julian yesterday and here is my short summary.

Section 2.3 of the c= ore draft defines client authentication based on two mechanisms (and provid= es room for extensions): http://tools.ietf.org/html/draft-ietf-oauth-v2-27#= section-2.3

1) HTTP Basic Authentication

2) A custom OAuth au= thentication mechanism (which uses client_id and client_secret)

With= HTTP Basic authentication the problem is that this is a legacy technology = and there is no internationalization support.

With our brand new cu= stom OAuth authentication mechanism we have more options.

One possi= ble approach is to say that the clients are devices (and not end users) and= therefore internationalization does not matter.

Is it, however, re= ally true that only US-ASCII characters will appear in the client_id and al= so in the client_secret?

Here we have the possibility to define som= ething better.

In any case we have to restrict the characters that are used in these two authentication mechanis= ms since they could conflict with the way how we transport the data over th= e underlying protocol. Julian mentioned this in his previous mails.
Julian, maybe you can provide a detailed text proposal for how to address = your comment in case we go for UTF8 (with % encoding) for the custom OAuth = client authentication mechanism?

Ciao
Hannes

On Jun 12, 2= 012, at 11:54 AM, Julian Reschke wrote:

> On 2012-06-12 00:16, Mi= ke Jones wrote:
>> Reviewing the feedback from Julian, John, and J= ames, I'm coming to the conclusion that client_id and client_secret, being = for machines and not humans, should be ASCII, whereas username and password= should be Unicode, since they are for humans.  Per John's feedback, c= lient_id can not contain a colon and be compatible with HTTP Basic.
>=
> I'm not sure that restricting the character repertoire just because one way to send requires this is the right approach. My prefe= rence would be not to put this into the ABNF, and just to point out that ce= rtain characters will not work over certain transports, and to just advise = to avoid them.
>
>> Therefore, I'd like to propose these up= dated ABNF definitions:
>>
>>    VSCHAR =3D %= 20-7E
>>    NOCOLONVSCHAR =3D %x20-39 / %x3B-7E
>= >    UNICODENOCTRLCHAR =3D <Any Unicode character other th= an ( %x0-1F / %x7F )>
>>
>>    client-id = =3D *NOCOLONVSCHAR
>>    client_secret =3D *VSCHAR
&= gt;>
>>    username =3D *UNICODENOCTRLCHAR
>&= gt;    password =3D *UNICODENOCTRLCHAR
>
> In this = case you should add an introductory statement pointing out that the ABNF de= fines the grammar in terms of Unicode code points, not octets (as it is the= case most of the time).
>
>> It turns out that non-ASCII charac= ters are OK for username and password because the Core spec only passes the= m in the form body - not using HTTP Basic - and UTF-8 encoding is specified= .
>
> I'll send a separate mail about that, the current text i= n the spec is way too unspecific.
>
>>     &= nbsp;           -- Mike
>>=
>> P.S.  If anyone has a better ABNF for UNICODENOCTRLCHAR = than "<Any Unicode character other than ( %x0-1F / %x7F )>", please s= end it to me!
>
> As noted before, here's an example: <http= ://greenbytes.de/tech/webdav/rfc5323.html#rfc.section.5.15.1>
> > Best regards, Julian
> _______________________________________= ________
> OAuth mailing list
> OAuth@ietf.org
> htt= ps://www.ietf.org/mailman/listinfo/oauth

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


---125733401-428407859-1339525052=:8121-- From Michael.Jones@microsoft.com Tue Jun 12 11:27:07 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18EA221F864C for ; Tue, 12 Jun 2012 11:27:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.899 X-Spam-Level: X-Spam-Status: No, score=-3.899 tagged_above=-999 required=5 tests=[AWL=-0.300, 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 UqfagjCiis16 for ; Tue, 12 Jun 2012 11:27:03 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe002.messaging.microsoft.com [216.32.181.182]) by ietfa.amsl.com (Postfix) with ESMTP id 5535321F85C6 for ; Tue, 12 Jun 2012 11:27:03 -0700 (PDT) Received: from mail219-ch1-R.bigfish.com (10.43.68.225) by CH1EHSOBE004.bigfish.com (10.43.70.54) with Microsoft SMTP Server id 14.1.225.23; Tue, 12 Jun 2012 18:26:00 +0000 Received: from mail219-ch1 (localhost [127.0.0.1]) by mail219-ch1-R.bigfish.com (Postfix) with ESMTP id 5FC953601C1; Tue, 12 Jun 2012 18:26:00 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: VS-24(zz98dI9371I936eIc85fh1432Izz1202hzz8275ch1033IL8275bh8275dhz2fh2a8h668h839hd25hf0ah) Received-SPF: pass (mail219-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC101.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail219-ch1 (localhost.localdomain [127.0.0.1]) by mail219-ch1 (MessageSwitch) id 1339525557657444_10006; Tue, 12 Jun 2012 18:25:57 +0000 (UTC) Received: from CH1EHSMHS016.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.247]) by mail219-ch1.bigfish.com (Postfix) with ESMTP id 9E04C220047; Tue, 12 Jun 2012 18:25:57 +0000 (UTC) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS016.bigfish.com (10.43.70.16) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 12 Jun 2012 18:25:55 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.189]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi id 14.02.0298.005; Tue, 12 Jun 2012 18:26:40 +0000 From: Mike Jones To: William Mills , Hannes Tschofenig , Julian Reschke Thread-Topic: [OAUTH-WG] Discussion needed on username and password ABNF definitions Thread-Index: AQHNSMer+It7DCBpM0GNB6qJ+8201Zb2/wyQ Date: Tue, 12 Jun 2012 18:26:39 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366535EAD@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739436652F52D@TK5EX14MBXC284.redmond.corp.microsoft.com> <4FD4E9D4.2010808@gmx.de> <4E1F6AAD24975D4BA5B168042967394366531375@TK5EX14MBXC284.redmond.corp.microsoft.com> <4FD4F976.6090801@gmx.de> <4E1F6AAD24975D4BA5B1680429673943665316D1@TK5EX14MBXC284.redmond.corp.microsoft.com> <60F5CCB0-E036-4351-BD10-A44B33FCC5F6@ve7jtb.com> <255B9BB34FB7D647A506DC292726F6E114F5474E29@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B1680429673943665346D0@TK5EX14MBXC284.redmond.corp.microsoft.com> <4FD703C4.6050801@gmx.de> <5E38109E-2123-418B-8D45-B8DF4287790D@gmx.net> <1339525052.8121.YahooMailNeo@web31807.mail.mud.yahoo.com> In-Reply-To: <1339525052.8121.YahooMailNeo@web31807.mail.mud.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394366535EADTK5EX14MBXC284r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 18:27:07 -0000 --_000_4E1F6AAD24975D4BA5B168042967394366535EADTK5EX14MBXC284r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Not internationalizing fields intended for machine consumption only is alre= ady a precedent set and agreed to by the working group, so let me second Bi= ll's point in that regard. For instance, neither "scope" nor "error" allow= non-ASCII characters. Julian, if you want different ABNF text than the text I wrote below, I beli= eve it would be most useful if you would provide the exact replace wording = that you'd like to see instead of it. Then there's no possibility of misun= derstanding the intent of suggested changes. Thanks all, -- Mike From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of W= illiam Mills Sent: Tuesday, June 12, 2012 11:18 AM To: Hannes Tschofenig; Julian Reschke Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF def= initions I agree generally with your assumption about clients, but rather than sayin= g "clients are devices" I think it makes much more sense to say "clients ar= e NOT users, so client_id need not be internationalized". In practical ter= ms there is very little to argue for anythign beyond ASCII in a client_secr= et, base64 encoding or the equivalent being a fine way to transport arbitra= ry bits in a portable/reasonable way. I argue that client_id need not be internationalized because I assume that = any really internationalized application will have an internationalized pre= sentation layer that's presenting a pretty name for the client_id. -bill ________________________________ From: Hannes Tschofenig > To: Julian Reschke > Cc: "oauth@ietf.org" > Sent: Tuesday, June 12, 2012 11:01 AM Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF def= initions I had a chat with Julian yesterday and here is my short summary. Section 2.3 of the core draft defines client authentication based on two me= chanisms (and provides room for extensions): http://tools.ietf.org/html/dra= ft-ietf-oauth-v2-27#section-2.3 1) HTTP Basic Authentication 2) A custom OAuth authentication mechanism (which uses client_id and client= _secret) With HTTP Basic authentication the problem is that this is a legacy technol= ogy and there is no internationalization support. With our brand new custom OAuth authentication mechanism we have more optio= ns. One possible approach is to say that the clients are devices (and not end u= sers) and therefore internationalization does not matter. Is it, however, really true that only US-ASCII characters will appear in th= e client_id and also in the client_secret? Here we have the possibility to define something better. In any case we have to restrict the characters that are used in these two a= uthentication mechanisms since they could conflict with the way how we tran= sport the data over the underlying protocol. Julian mentioned this in his p= revious mails. Julian, maybe you can provide a detailed text proposal for how to address y= our comment in case we go for UTF8 (with % encoding) for the custom OAuth c= lient authentication mechanism? Ciao Hannes On Jun 12, 2012, at 11:54 AM, Julian Reschke wrote: > On 2012-06-12 00:16, Mike Jones wrote: >> Reviewing the feedback from Julian, John, and James, I'm coming to the c= onclusion that client_id and client_secret, being for machines and not huma= ns, should be ASCII, whereas username and password should be Unicode, since= they are for humans. Per John's feedback, client_id can not contain a col= on and be compatible with HTTP Basic. > > I'm not sure that restricting the character repertoire just because one w= ay to send requires this is the right approach. My preference would be not = to put this into the ABNF, and just to point out that certain characters wi= ll not work over certain transports, and to just advise to avoid them. > >> Therefore, I'd like to propose these updated ABNF definitions: >> >> VSCHAR =3D %20-7E >> NOCOLONVSCHAR =3D %x20-39 / %x3B-7E >> UNICODENOCTRLCHAR =3D >> >> client-id =3D *NOCOLONVSCHAR >> client_secret =3D *VSCHAR >> >> username =3D *UNICODENOCTRLCHAR >> password =3D *UNICODENOCTRLCHAR > > In this case you should add an introductory statement pointing out that t= he ABNF defines the grammar in terms of Unicode code points, not octets (as= it is the case most of the time). > >> It turns out that non-ASCII characters are OK for username and password = because the Core spec only passes them in the form body - not using HTTP Ba= sic - and UTF-8 encoding is specified. > > I'll send a separate mail about that, the current text in the spec is way= too unspecific. > >> -- Mike >> >> P.S. If anyone has a better ABNF for UNICODENOCTRLCHAR than "", please send it to me! > > As noted before, here's an example: > > Best regards, Julian > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_4E1F6AAD24975D4BA5B168042967394366535EADTK5EX14MBXC284r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Not internationalizing fi= elds intended for machine consumption only is already a precedent set and a= greed to by the working group, so let me second Bill’s point in that regard.  For instance, neither “scope” nor “= ;error” allow non-ASCII characters.

 <= /p>

Julian, if you want diffe= rent ABNF text than the text I wrote below, I believe it would be most usef= ul if you would provide the exact replace wording that you’d like to see instead of it.  Then there’s no possibility of misu= nderstanding the intent of suggested changes.

 <= /p>

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;     Thanks all,

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

 <= /p>

From: oauth-bo= unces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of William Mills
Sent: Tuesday, June 12, 2012 11:18 AM
To: Hannes Tschofenig; Julian Reschke
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Discussion needed on username and password A= BNF definitions

 

I agree generally w= ith your assumption about clients, but rather than saying "clients are= devices" I think it makes much more sense to say "clients are NOT users, so client_id need not be internationalized".  In = practical terms there is very little to argue for anythign beyond ASCII in = a client_secret, base64 encoding or the equivalent being a fine way to tran= sport arbitrary bits in a portable/reasonable way.

 

I argue that client= _id need not be internationalized because I assume that any really internat= ionalized application will have an internationalized presentation layer that's presenting a pretty name for the client_id.=

 

-bill



From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
To: Julian Reschke <juli= an.reschke@gmx.de>
Cc: "oauth@ietf.org"= <oauth@ietf.org>
Sent: Tuesday, June 12, 2012 11:01 AM
Subject: Re: [OAUTH-WG] Discussion needed on username and password A= BNF definitions


I had a chat with Julian yesterday and here is my short summary.

Section 2.3 of the core draft defines client authentication based on two me= chanisms (and provides room for extensions): h= ttp://tools.ietf.org/html/draft-ietf-oauth-v2-27#section-2.3

1) HTTP Basic Authentication

2) A custom OAuth authentication mechanism (which uses client_id and client= _secret)

With HTTP Basic authentication the problem is that this is a legacy technol= ogy and there is no internationalization support.

With our brand new custom OAuth authentication mechanism we have more optio= ns.

One possible approach is to say that the clients are devices (and not end u= sers) and therefore internationalization does not matter.

Is it, however, really true that only US-ASCII characters will appear in th= e client_id and also in the client_secret?

Here we have the possibility to define something better.

In any case we have to restrict the characters that are used in these two a= uthentication mechanisms since they could conflict with the way how we tran= sport the data over the underlying protocol. Julian mentioned this in his p= revious mails.

Julian, maybe you can provide a detailed text proposal for how to address y= our comment in case we go for UTF8 (with % encoding) for the custom OAuth c= lient authentication mechanism?

Ciao
Hannes

On Jun 12, 2012, at 11:54 AM, Julian Reschke wrote:

> On 2012-06-12 00:16, Mike Jones wrote:
>> Reviewing the feedback from Julian, John, and James, I'm coming to= the conclusion that client_id and client_secret, being for machines and no= t humans, should be ASCII, whereas username and password should be Unicode,= since they are for humans.  Per John's feedback, client_id can not contain a colon and be compatible with HTTP Ba= sic.
>
> I'm not sure that restricting the character repertoire just because on= e way to send requires this is the right approach. My preference would be n= ot to put this into the ABNF, and just to point out that certain characters= will not work over certain transports, and to just advise to avoid them.
>
>> Therefore, I'd like to propose these updated ABNF definitions:
>>
>>    VSCHAR =3D %20-7E
>>    NOCOLONVSCHAR =3D %x20-39 / %x3B-7E
>>    UNICODENOCTRLCHAR =3D <Any Unicode character other= than ( %x0-1F / %x7F )>
>>
>>    client-id =3D *NOCOLONVSCHAR
>>    client_secret =3D *VSCHAR
>>
>>    username =3D *UNICODENOCTRLCHAR
>>    password =3D *UNICODENOCTRLCHAR
>
> In this case you should add an introductory statement pointing out tha= t the ABNF defines the grammar in terms of Unicode code points, not octets = (as it is the case most of the time).
>
>> It turns out that non-ASCII characters are OK for username and pas= sword because the Core spec only passes them in the form body - not using H= TTP Basic - and UTF-8 encoding is specified.
>
> I'll send a separate mail about that, the current text in the spec is = way too unspecific.
>
>>              &nb= sp;  -- Mike
>>
>> P.S.  If anyone has a better ABNF for UNICODENOCTRLCHAR than = "<Any Unicode character other than ( %x0-1F / %x7F )>", ple= ase send it to me!
>
> As noted before, here's an example: <http://greenbytes.de/tech/we= bdav/rfc5323.html#rfc.section.5.15.1>
>
> Best regards, Julian
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

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

--_000_4E1F6AAD24975D4BA5B168042967394366535EADTK5EX14MBXC284r_-- From eran@hueniverse.com Tue Jun 12 11:39:22 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85D4B21F8655 for ; Tue, 12 Jun 2012 11:39:22 -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 eCOf+HDbIxUn for ; Tue, 12 Jun 2012 11:39:18 -0700 (PDT) Received: from p3plex2out01.prod.phx3.secureserver.net (p3plex2out01.prod.phx3.secureserver.net [184.168.131.12]) by ietfa.amsl.com (Postfix) with ESMTP id 802FD21F8661 for ; Tue, 12 Jun 2012 11:39:18 -0700 (PDT) Received: from P3PWEX2HT001.ex2.secureserver.net ([184.168.131.9]) by p3plex2out01.prod.phx3.secureserver.net with bizsmtp id MWfH1j0020CJzpC01WfHL5; Tue, 12 Jun 2012 11:39:17 -0700 Received: from P3PWEX2MB008.ex2.secureserver.net ([169.254.8.66]) by P3PWEX2HT001.ex2.secureserver.net ([184.168.131.9]) with mapi id 14.02.0247.003; Tue, 12 Jun 2012 11:39:17 -0700 From: Eran Hammer To: Mike Jones , William Mills , Hannes Tschofenig , "Julian Reschke" Thread-Topic: [OAUTH-WG] Discussion needed on username and password ABNF definitions Thread-Index: AQHNSMj7QEQmi4O4F06tenKhdYMV75b3AxBQ Date: Tue, 12 Jun 2012 18:39:16 +0000 Message-ID: <0CBAEB56DDB3A140BA8E8C124C04ECA20106ED1F@P3PWEX2MB008.ex2.secureserver.net> References: <4E1F6AAD24975D4BA5B16804296739436652F52D@TK5EX14MBXC284.redmond.corp.microsoft.com> <4FD4E9D4.2010808@gmx.de> <4E1F6AAD24975D4BA5B168042967394366531375@TK5EX14MBXC284.redmond.corp.microsoft.com> <4FD4F976.6090801@gmx.de> <4E1F6AAD24975D4BA5B1680429673943665316D1@TK5EX14MBXC284.redmond.corp.microsoft.com> <60F5CCB0-E036-4351-BD10-A44B33FCC5F6@ve7jtb.com> <255B9BB34FB7D647A506DC292726F6E114F5474E29@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B1680429673943665346D0@TK5EX14MBXC284.redmond.corp.microsoft.com> <4FD703C4.6050801@gmx.de> <5E38109E-2123-418B-8D45-B8DF4287790D@gmx.net> <1339525052.8121.YahooMailNeo@web31807.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B168042967394366535EAD@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366535EAD@TK5EX14MBXC284.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [37.46.32.109] Content-Type: multipart/alternative; boundary="_000_0CBAEB56DDB3A140BA8E8C124C04ECA20106ED1FP3PWEX2MB008ex2_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 18:39:22 -0000 --_000_0CBAEB56DDB3A140BA8E8C124C04ECA20106ED1FP3PWEX2MB008ex2_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Is the use case of using URI as client ids important? It seems like somethi= ng that might become useful in the future where clients can use their verif= iable servers to bypass client registration and simly use a URI the server = can validate via some other means. I just want to make sure those thinking about more complex use cases involv= ing dynamic registration or distributed client manamgenet are aware of this= potential restriction. I'm fine either way. EH From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of M= ike Jones Sent: Tuesday, June 12, 2012 11:27 AM To: William Mills; Hannes Tschofenig; Julian Reschke Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF def= initions Not internationalizing fields intended for machine consumption only is alre= ady a precedent set and agreed to by the working group, so let me second Bi= ll's point in that regard. For instance, neither "scope" nor "error" allow= non-ASCII characters. Julian, if you want different ABNF text than the text I wrote below, I beli= eve it would be most useful if you would provide the exact replace wording = that you'd like to see instead of it. Then there's no possibility of misun= derstanding the intent of suggested changes. Thanks all, -- Mike From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Willi= am Mills Sent: Tuesday, June 12, 2012 11:18 AM To: Hannes Tschofenig; Julian Reschke Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF def= initions I agree generally with your assumption about clients, but rather than sayin= g "clients are devices" I think it makes much more sense to say "clients ar= e NOT users, so client_id need not be internationalized". In practical ter= ms there is very little to argue for anythign beyond ASCII in a client_secr= et, base64 encoding or the equivalent being a fine way to transport arbitra= ry bits in a portable/reasonable way. I argue that client_id need not be internationalized because I assume that = any really internationalized application will have an internationalized pre= sentation layer that's presenting a pretty name for the client_id. -bill ________________________________ From: Hannes Tschofenig > To: Julian Reschke > Cc: "oauth@ietf.org" > Sent: Tuesday, June 12, 2012 11:01 AM Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF def= initions I had a chat with Julian yesterday and here is my short summary. Section 2.3 of the core draft defines client authentication based on two me= chanisms (and provides room for extensions): http://tools.ietf.org/html/dra= ft-ietf-oauth-v2-27#section-2.3 1) HTTP Basic Authentication 2) A custom OAuth authentication mechanism (which uses client_id and client= _secret) With HTTP Basic authentication the problem is that this is a legacy technol= ogy and there is no internationalization support. With our brand new custom OAuth authentication mechanism we have more optio= ns. One possible approach is to say that the clients are devices (and not end u= sers) and therefore internationalization does not matter. Is it, however, really true that only US-ASCII characters will appear in th= e client_id and also in the client_secret? Here we have the possibility to define something better. In any case we have to restrict the characters that are used in these two a= uthentication mechanisms since they could conflict with the way how we tran= sport the data over the underlying protocol. Julian mentioned this in his p= revious mails. Julian, maybe you can provide a detailed text proposal for how to address y= our comment in case we go for UTF8 (with % encoding) for the custom OAuth c= lient authentication mechanism? Ciao Hannes On Jun 12, 2012, at 11:54 AM, Julian Reschke wrote: > On 2012-06-12 00:16, Mike Jones wrote: >> Reviewing the feedback from Julian, John, and James, I'm coming to the c= onclusion that client_id and client_secret, being for machines and not huma= ns, should be ASCII, whereas username and password should be Unicode, since= they are for humans. Per John's feedback, client_id can not contain a col= on and be compatible with HTTP Basic. > > I'm not sure that restricting the character repertoire just because one w= ay to send requires this is the right approach. My preference would be not = to put this into the ABNF, and just to point out that certain characters wi= ll not work over certain transports, and to just advise to avoid them. > >> Therefore, I'd like to propose these updated ABNF definitions: >> >> VSCHAR =3D %20-7E >> NOCOLONVSCHAR =3D %x20-39 / %x3B-7E >> UNICODENOCTRLCHAR =3D >> >> client-id =3D *NOCOLONVSCHAR >> client_secret =3D *VSCHAR >> >> username =3D *UNICODENOCTRLCHAR >> password =3D *UNICODENOCTRLCHAR > > In this case you should add an introductory statement pointing out that t= he ABNF defines the grammar in terms of Unicode code points, not octets (as= it is the case most of the time). > >> It turns out that non-ASCII characters are OK for username and password = because the Core spec only passes them in the form body - not using HTTP Ba= sic - and UTF-8 encoding is specified. > > I'll send a separate mail about that, the current text in the spec is way= too unspecific. > >> -- Mike >> >> P.S. If anyone has a better ABNF for UNICODENOCTRLCHAR than "", please send it to me! > > As noted before, here's an example: > > Best regards, Julian > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_0CBAEB56DDB3A140BA8E8C124C04ECA20106ED1FP3PWEX2MB008ex2_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Is the use case of using = URI as client ids important? It seems like something that might become usef= ul in the future where clients can use their verifiable servers to bypass client registration and simly use a URI the server can v= alidate via some other means.

 <= /p>

I just want to make sure = those thinking about more complex use cases involving dynamic registration = or distributed client manamgenet are aware of this potential restriction.

 <= /p>

I'm fine either way.=

 <= /p>

EH

 <= /p>

From: oauth-bo= unces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Tuesday, June 12, 2012 11:27 AM
To: William Mills; Hannes Tschofenig; Julian Reschke
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Discussion needed on username and password A= BNF definitions

 

Not internationalizing fi= elds intended for machine consumption only is already a precedent set and a= greed to by the working group, so let me second Bill’s point in that regard.  For instance, neither “scope” nor “= ;error” allow non-ASCII characters.

 <= /p>

Julian, if you want diffe= rent ABNF text than the text I wrote below, I believe it would be most usef= ul if you would provide the exact replace wording that you’d like to see instead of it.  Then there’s no possibility of misu= nderstanding the intent of suggested changes.

 <= /p>

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;     Thanks all,

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

 <= /p>

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of William Mills
Sent: Tuesday, June 12, 2012 11:18 AM
To: Hannes Tschofenig; Julian Reschke
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Discussion needed on username and password A= BNF definitions

 

I agree generally w= ith your assumption about clients, but rather than saying "clients are= devices" I think it makes much more sense to say "clients are NOT users, so client_id need not be internationalized".  In = practical terms there is very little to argue for anythign beyond ASCII in = a client_secret, base64 encoding or the equivalent being a fine way to tran= sport arbitrary bits in a portable/reasonable way.

 

I argue that client= _id need not be internationalized because I assume that any really internat= ionalized application will have an internationalized presentation layer that's presenting a pretty name for the client_id.=

 

-bill

From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
To: Julian Reschke <juli= an.reschke@gmx.de>
Cc: "oauth@ietf.org"= <oauth@ietf.org>
Sent: Tuesday, June 12, 2012 11:01 AM
Subject: Re: [OAUTH-WG] Discussion needed on username and password A= BNF definitions


I had a chat with Julian yesterday and here is my short summary.

Section 2.3 of the core draft defines client authentication based on two me= chanisms (and provides room for extensions): h= ttp://tools.ietf.org/html/draft-ietf-oauth-v2-27#section-2.3

1) HTTP Basic Authentication

2) A custom OAuth authentication mechanism (which uses client_id and client= _secret)

With HTTP Basic authentication the problem is that this is a legacy technol= ogy and there is no internationalization support.

With our brand new custom OAuth authentication mechanism we have more optio= ns.

One possible approach is to say that the clients are devices (and not end u= sers) and therefore internationalization does not matter.

Is it, however, really true that only US-ASCII characters will appear in th= e client_id and also in the client_secret?

Here we have the possibility to define something better.

In any case we have to restrict the characters that are used in these two a= uthentication mechanisms since they could conflict with the way how we tran= sport the data over the underlying protocol. Julian mentioned this in his p= revious mails.

Julian, maybe you can provide a detailed text proposal for how to address y= our comment in case we go for UTF8 (with % encoding) for the custom OAuth c= lient authentication mechanism?

Ciao
Hannes

On Jun 12, 2012, at 11:54 AM, Julian Reschke wrote:

> On 2012-06-12 00:16, Mike Jones wrote:
>> Reviewing the feedback from Julian, John, and James, I'm coming to= the conclusion that client_id and client_secret, being for machines and no= t humans, should be ASCII, whereas username and password should be Unicode,= since they are for humans.  Per John's feedback, client_id can not contain a colon and be compatible with HTTP Ba= sic.
>
> I'm not sure that restricting the character repertoire just because on= e way to send requires this is the right approach. My preference would be n= ot to put this into the ABNF, and just to point out that certain characters= will not work over certain transports, and to just advise to avoid them.
>
>> Therefore, I'd like to propose these updated ABNF definitions:
>>
>>    VSCHAR =3D %20-7E
>>    NOCOLONVSCHAR =3D %x20-39 / %x3B-7E
>>    UNICODENOCTRLCHAR =3D <Any Unicode character other= than ( %x0-1F / %x7F )>
>>
>>    client-id =3D *NOCOLONVSCHAR
>>    client_secret =3D *VSCHAR
>>
>>    username =3D *UNICODENOCTRLCHAR
>>    password =3D *UNICODENOCTRLCHAR
>
> In this case you should add an introductory statement pointing out tha= t the ABNF defines the grammar in terms of Unicode code points, not octets = (as it is the case most of the time).
>
>> It turns out that non-ASCII characters are OK for username and pas= sword because the Core spec only passes them in the form body - not using H= TTP Basic - and UTF-8 encoding is specified.
>
> I'll send a separate mail about that, the current text in the spec is = way too unspecific.
>
>>              &nb= sp;  -- Mike
>>
>> P.S.  If anyone has a better ABNF for UNICODENOCTRLCHAR than = "<Any Unicode character other than ( %x0-1F / %x7F )>", ple= ase send it to me!
>
> As noted before, here's an example: <http://greenbytes.de/tech/we= bdav/rfc5323.html#rfc.section.5.15.1>
>
> Best regards, Julian
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

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

--_000_0CBAEB56DDB3A140BA8E8C124C04ECA20106ED1FP3PWEX2MB008ex2_-- From gffletch@aol.com Tue Jun 12 11:44:32 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92D2221F866D for ; Tue, 12 Jun 2012 11:44:31 -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 WdXnLywSjVpE for ; Tue, 12 Jun 2012 11:44:28 -0700 (PDT) Received: from imr-ma06.mx.aol.com (imr-ma06.mx.aol.com [64.12.78.142]) by ietfa.amsl.com (Postfix) with ESMTP id 19E8621F866A for ; Tue, 12 Jun 2012 11:44:28 -0700 (PDT) Received: from mtaout-db01.r1000.mx.aol.com (mtaout-db01.r1000.mx.aol.com [172.29.51.193]) by imr-ma06.mx.aol.com (8.14.1/8.14.1) with ESMTP id q5CIi1cQ029197; Tue, 12 Jun 2012 14:44:01 -0400 Received: from palantir.office.aol.com (palantir.office.aol.com [10.181.186.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout-db01.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id D7B0DE0000C3; Tue, 12 Jun 2012 14:44:00 -0400 (EDT) Message-ID: <4FD78DF0.8030606@aol.com> Date: Tue, 12 Jun 2012 14:44:00 -0400 From: George Fletcher Organization: AOL LLC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Eran Hammer References: <4E1F6AAD24975D4BA5B16804296739436652F52D@TK5EX14MBXC284.redmond.corp.microsoft.com> <4FD4E9D4.2010808@gmx.de> <4E1F6AAD24975D4BA5B168042967394366531375@TK5EX14MBXC284.redmond.corp.microsoft.com> <4FD4F976.6090801@gmx.de> <4E1F6AAD24975D4BA5B1680429673943665316D1@TK5EX14MBXC284.redmond.corp.microsoft.com> <60F5CCB0-E036-4351-BD10-A44B33FCC5F6@ve7jtb.com> <255B9BB34FB7D647A506DC292726F6E114F5474E29@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B1680429673943665346D0@TK5EX14MBXC284.redmond.corp.microsoft.com> <4FD703C4.6050801@gmx.de> <5E38109E-2123-418B-8D45-B8DF4287790D@gmx.net> <1339525052.8121.YahooMailNeo@web31807.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B168042967394366535EAD@TK5EX14MBXC284.redmond.corp.microsoft.com> <0CBAEB56DDB3A140BA8E8C124C04ECA20106ED1F@P3PWEX2MB008.ex2.secureserver.net> In-Reply-To: <0CBAEB56DDB3A140BA8E8C124C04ECA20106ED1F@P3PWEX2MB008.ex2.secureserver.net> Content-Type: multipart/alternative; boundary="------------040309050309070802090300" x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20110426; t=1339526641; bh=iwHh5czHbmgB3Yrx7l+oXYMZlh0Nsx9GJ8JVlSoV5vE=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=NTZMdIZnS+WfaoZXMbCr5b5nrnS8B1abyFVQ23uPlhz/EiQ4tg0oGNmoOdYGZJyQd kw+StAhV5PNWkhBH9JhDEid9nUi6Y4k5jkzK9SesB6BUX2GMZ8dkI/h9RFe1sYdj26 VCGPDhBaHRArWvSp9gsNnnx5f15gNmHBe33vVpRU= X-AOL-SCOLL-SCORE: 0:2:489493984:93952408 X-AOL-SCOLL-URL_COUNT: 0 x-aol-sid: 3039ac1d33c14fd78df018b4 X-AOL-IP: 10.181.186.254 Cc: Julian Reschke , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 18:44:32 -0000 This is a multi-part message in MIME format. --------------040309050309070802090300 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I agree that there is value in allowing the client_id to be a URI. The problem is that the ':' of the URI is not allowed in HTTP Basic which is required by the OAuth2 spec for client authentication. We could encode the client_id before HTTP Basic but that needs to be documented and adds complexity. Thanks, George On 6/12/12 2:39 PM, Eran Hammer wrote: > > Is the use case of using URI as client ids important? It seems like > something that might become useful in the future where clients can use > their verifiable servers to bypass client registration and simly use a > URI the server can validate via some other means. > > I just want to make sure those thinking about more complex use cases > involving dynamic registration or distributed client manamgenet are > aware of this potential restriction. > > I'm fine either way. > > EH > > *From:*oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On > Behalf Of *Mike Jones > *Sent:* Tuesday, June 12, 2012 11:27 AM > *To:* William Mills; Hannes Tschofenig; Julian Reschke > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Discussion needed on username and password > ABNF definitions > > Not internationalizing fields intended for machine consumption only is > already a precedent set and agreed to by the working group, so let me > second Bill's point in that regard. For instance, neither "scope" nor > "error" allow non-ASCII characters. > > Julian, if you want different ABNF text than the text I wrote below, I > believe it would be most useful if you would provide the exact replace > wording that you'd like to see instead of it. Then there's no > possibility of misunderstanding the intent of suggested changes. > > Thanks all, > > -- Mike > > *From:*oauth-bounces@ietf.org > [mailto:oauth-bounces@ietf.org] > *On Behalf Of *William Mills > *Sent:* Tuesday, June 12, 2012 11:18 AM > *To:* Hannes Tschofenig; Julian Reschke > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Discussion needed on username and password > ABNF definitions > > I agree generally with your assumption about clients, but rather than > saying "clients are devices" I think it makes much more sense to say > "clients are NOT users, so client_id need not be internationalized". > In practical terms there is very little to argue for anythign beyond > ASCII in a client_secret, base64 encoding or the equivalent being a > fine way to transport arbitrary bits in a portable/reasonable way. > > I argue that client_id need not be internationalized because I assume > that any really internationalized application will have an > internationalized presentation layer that's presenting a pretty name > for the client_id. > > -bill > > ------------------------------------------------------------------------ > > *From:*Hannes Tschofenig > > *To:* Julian Reschke > > *Cc:* "oauth@ietf.org " > > *Sent:* Tuesday, June 12, 2012 11:01 AM > *Subject:* Re: [OAUTH-WG] Discussion needed on username and password > ABNF definitions > > > I had a chat with Julian yesterday and here is my short summary. > > Section 2.3 of the core draft defines client authentication based on > two mechanisms (and provides room for extensions): > http://tools.ietf.org/html/draft-ietf-oauth-v2-27#section-2.3 > > 1) HTTP Basic Authentication > > 2) A custom OAuth authentication mechanism (which uses client_id and > client_secret) > > With HTTP Basic authentication the problem is that this is a legacy > technology and there is no internationalization support. > > With our brand new custom OAuth authentication mechanism we have more > options. > > One possible approach is to say that the clients are devices (and not > end users) and therefore internationalization does not matter. > > Is it, however, really true that only US-ASCII characters will appear > in the client_id and also in the client_secret? > > Here we have the possibility to define something better. > > In any case we have to restrict the characters that are used in these > two authentication mechanisms since they could conflict with the way > how we transport the data over the underlying protocol. Julian > mentioned this in his previous mails. > > Julian, maybe you can provide a detailed text proposal for how to > address your comment in case we go for UTF8 (with % encoding) for the > custom OAuth client authentication mechanism? > > Ciao > Hannes > > On Jun 12, 2012, at 11:54 AM, Julian Reschke wrote: > > > On 2012-06-12 00:16, Mike Jones wrote: > >> Reviewing the feedback from Julian, John, and James, I'm coming to > the conclusion that client_id and client_secret, being for machines > and not humans, should be ASCII, whereas username and password should > be Unicode, since they are for humans. Per John's feedback, client_id > can not contain a colon and be compatible with HTTP Basic. > > > > I'm not sure that restricting the character repertoire just because > one way to send requires this is the right approach. My preference > would be not to put this into the ABNF, and just to point out that > certain characters will not work over certain transports, and to just > advise to avoid them. > > > >> Therefore, I'd like to propose these updated ABNF definitions: > >> > >> VSCHAR = %20-7E > >> NOCOLONVSCHAR = %x20-39 / %x3B-7E > >> UNICODENOCTRLCHAR = %x7F )> > >> > >> client-id = *NOCOLONVSCHAR > >> client_secret = *VSCHAR > >> > >> username = *UNICODENOCTRLCHAR > >> password = *UNICODENOCTRLCHAR > > > > In this case you should add an introductory statement pointing out > that the ABNF defines the grammar in terms of Unicode code points, not > octets (as it is the case most of the time). > > > >> It turns out that non-ASCII characters are OK for username and > password because the Core spec only passes them in the form body - not > using HTTP Basic - and UTF-8 encoding is specified. > > > > I'll send a separate mail about that, the current text in the spec is > way too unspecific. > > > >> -- Mike > >> > >> P.S. If anyone has a better ABNF for UNICODENOCTRLCHAR than " Unicode character other than ( %x0-1F / %x7F )>", please send it to me! > > > > As noted before, here's an example: > > > > > Best regards, Julian > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------040309050309070802090300 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I agree that there is value in allowing the client_id to be a URI. The problem is that the ':' of the URI is not allowed in HTTP Basic which is required by the OAuth2 spec for client authentication. We could encode the client_id before HTTP Basic but that needs to be documented and adds complexity.

Thanks,
George

On 6/12/12 2:39 PM, Eran Hammer wrote:

Is the use case of using URI as client ids important? It seems like something that might become useful in the future where clients can use their verifiable servers to bypass client registration and simly use a URI the server can validate via some other means.

 

I just want to make sure those thinking about more complex use cases involving dynamic registration or distributed client manamgenet are aware of this potential restriction.

 

I'm fine either way.

 

EH

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Tuesday, June 12, 2012 11:27 AM
To: William Mills; Hannes Tschofenig; Julian Reschke
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions

 

Not internationalizing fields intended for machine consumption only is already a precedent set and agreed to by the working group, so let me second Bill’s point in that regard.  For instance, neither “scope” nor “error” allow non-ASCII characters.

 

Julian, if you want different ABNF text than the text I wrote below, I believe it would be most useful if you would provide the exact replace wording that you’d like to see instead of it.  Then there’s no possibility of misunderstanding the intent of suggested changes.

 

                                                            Thanks all,

                                                            -- Mike

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of William Mills
Sent: Tuesday, June 12, 2012 11:18 AM
To: Hannes Tschofenig; Julian Reschke
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions

 

I agree generally with your assumption about clients, but rather than saying "clients are devices" I think it makes much more sense to say "clients are NOT users, so client_id need not be internationalized".  In practical terms there is very little to argue for anythign beyond ASCII in a client_secret, base64 encoding or the equivalent being a fine way to transport arbitrary bits in a portable/reasonable way.

 

I argue that client_id need not be internationalized because I assume that any really internationalized application will have an internationalized presentation layer that's presenting a pretty name for the client_id.

 

-bill

 

From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
To: Julian Reschke <julian.reschke@gmx.de>
Cc: "oauth@ietf.org" <oauth@ietf.org>
Sent: Tuesday, June 12, 2012 11:01 AM
Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions


I had a chat with Julian yesterday and here is my short summary.

Section 2.3 of the core draft defines client authentication based on two mechanisms (and provides room for extensions): http://tools.ietf.org/html/draft-ietf-oauth-v2-27#section-2.3

1) HTTP Basic Authentication

2) A custom OAuth authentication mechanism (which uses client_id and client_secret)

With HTTP Basic authentication the problem is that this is a legacy technology and there is no internationalization support.

With our brand new custom OAuth authentication mechanism we have more options.

One possible approach is to say that the clients are devices (and not end users) and therefore internationalization does not matter.

Is it, however, really true that only US-ASCII characters will appear in the client_id and also in the client_secret?

Here we have the possibility to define something better.

In any case we have to restrict the characters that are used in these two authentication mechanisms since they could conflict with the way how we transport the data over the underlying protocol. Julian mentioned this in his previous mails.

Julian, maybe you can provide a detailed text proposal for how to address your comment in case we go for UTF8 (with % encoding) for the custom OAuth client authentication mechanism?

Ciao
Hannes

On Jun 12, 2012, at 11:54 AM, Julian Reschke wrote:

> On 2012-06-12 00:16, Mike Jones wrote:
>> Reviewing the feedback from Julian, John, and James, I'm coming to the conclusion that client_id and client_secret, being for machines and not humans, should be ASCII, whereas username and password should be Unicode, since they are for humans.  Per John's feedback, client_id can not contain a colon and be compatible with HTTP Basic.
>
> I'm not sure that restricting the character repertoire just because one way to send requires this is the right approach. My preference would be not to put this into the ABNF, and just to point out that certain characters will not work over certain transports, and to just advise to avoid them.
>
>> Therefore, I'd like to propose these updated ABNF definitions:
>>
>>    VSCHAR = %20-7E
>>    NOCOLONVSCHAR = %x20-39 / %x3B-7E
>>    UNICODENOCTRLCHAR = <Any Unicode character other than ( %x0-1F / %x7F )>
>>
>>    client-id = *NOCOLONVSCHAR
>>    client_secret = *VSCHAR
>>
>>    username = *UNICODENOCTRLCHAR
>>    password = *UNICODENOCTRLCHAR
>
> In this case you should add an introductory statement pointing out that the ABNF defines the grammar in terms of Unicode code points, not octets (as it is the case most of the time).
>
>> It turns out that non-ASCII characters are OK for username and password because the Core spec only passes them in the form body - not using HTTP Basic - and UTF-8 encoding is specified.
>
> I'll send a separate mail about that, the current text in the spec is way too unspecific.
>
>>                 -- Mike
>>
>> P.S.  If anyone has a better ABNF for UNICODENOCTRLCHAR than "<Any Unicode character other than ( %x0-1F / %x7F )>", please send it to me!
>
> As noted before, here's an example: <http://greenbytes.de/tech/webdav/rfc5323.html#rfc.section.5.15.1>
>
> Best regards, Julian
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

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



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

--------------040309050309070802090300-- From eran@hueniverse.com Tue Jun 12 11:52:39 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74C3821F859A for ; Tue, 12 Jun 2012 11:52:39 -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 YQ+yz2NB3tvZ for ; Tue, 12 Jun 2012 11:52:38 -0700 (PDT) Received: from p3plex2out04.prod.phx3.secureserver.net (p3plex2out04.prod.phx3.secureserver.net [184.168.131.18]) by ietfa.amsl.com (Postfix) with ESMTP id CF12021F8599 for ; Tue, 12 Jun 2012 11:52:38 -0700 (PDT) Received: from P3PWEX2HT002.ex2.secureserver.net ([184.168.131.10]) by p3plex2out04.prod.phx3.secureserver.net with bizsmtp id MWse1j0080Dcg9U01WsefJ; Tue, 12 Jun 2012 11:52:38 -0700 Received: from P3PWEX2MB008.ex2.secureserver.net ([169.254.8.66]) by P3PWEX2HT002.ex2.secureserver.net ([184.168.131.10]) with mapi id 14.02.0247.003; Tue, 12 Jun 2012 11:52:38 -0700 From: Eran Hammer To: Derek Atkins Thread-Topic: On the OAuth Core Spec Thread-Index: AQHNSMDROALpq7NLoUWJn1Mfr6HFMZb2/fwA Date: Tue, 12 Jun 2012 18:52:38 +0000 Message-ID: <0CBAEB56DDB3A140BA8E8C124C04ECA20106ED8B@P3PWEX2MB008.ex2.secureserver.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [37.46.32.109] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] On the OAuth Core Spec X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 18:52:39 -0000 Derek - Thank you for this note. It is very much appreacited. > From: Derek Atkins [mailto:derek@ihtfp.com] > Sent: Tuesday, June 12, 2012 10:28 AM > Having said that, are you still willing and able to be the editor of this= draft and > see it to its conclusion and publication? Yes. > If so, we will need to get another > draft out by this Friday (June 15), and I suspect we'll need another draf= t that > solves the encoding issue (brought up by the ABNF exercise), targeting > Friday, June 29th. Do you think you can make these target dates (assumin= g > that there is text for you to apply to the draft)? There are two main open issues I'm aware of: 1. Error registry text * The text provided by Mike Jones for section 7.2 is unlcear. I have provid= ed feedback on the list and am waiting to hear back from Mike (or anyone el= se). Once I understand the actual intention of the new normative language, = I will rework the text to reflect those changes. While I have strong object= ions to the error code registry in genreal, once decided, my only goal is t= o ensure the text is clear, complete, and reflects working group consensus.= I do not have strong interest in how the working group resolves the rules = around the registry as long as they are clear and practical. The current te= xt for 7.2 is not. * In the consensus call for the error registry, Hannes requested (or sugges= ted, it wasn't clear given the context) that the registry be implemented by= IANA using separate tables. This requires prose changes to instruct IANA a= s such. Without changes, IANA will create a single table which is not what = was requested. I have not seen much discussion on this. I am waiting for th= e chairs to clarify this and for someone to provide text if this is still t= he case (I have sent multiple emails on this to the list). 2. ABNF * Mike Jones is doing solid work progressing the ABNF forward with the guid= ance of Julian. I trust Julian blindly to guide the text to a successful co= nculsion and the working group seems enaged. As soon as new text is availab= le, I will incorporate and publish. If a schedule conflict arises in which = I am unable to push the ABNF changes, I have no objections to Mike Jones pu= shing a new draft with only ABNF related change after quick coordination (M= ike can submit using my contact and I'll approve it within a few hours). I also have a short list of nits and typos reported to the list and me dire= ctly over the past few weeks which are all insignificant to list. I am available to publish another draft on or by 6/14, and again on or by 6= /27 (or 6/30 after my travel). I will be travelling on the exact dates list= ed. I am hoping that these dates are flexible within a few days range. In o= rder for me to publish a new draft by 6/14, I will need the changes a day b= efore to prepare. If the changes are ABNF only, I can work with Mike Jones = to arrange it without putting my travel restriction in the way. I need the = chairs to clarify what is expected in each of these drafts and how they see= k to resolve the issues around item #1 above to continue. Again, thanks for the note. EH From eran@hueniverse.com Tue Jun 12 11:57:13 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49EFB21F863B for ; Tue, 12 Jun 2012 11:57:13 -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 d+mb3Zdt14ao for ; Tue, 12 Jun 2012 11:57:09 -0700 (PDT) Received: from p3plex2out03.prod.phx3.secureserver.net (p3plex2out03.prod.phx3.secureserver.net [184.168.131.16]) by ietfa.amsl.com (Postfix) with ESMTP id CE05121F8637 for ; Tue, 12 Jun 2012 11:57:08 -0700 (PDT) Received: from P3PWEX2HT001.ex2.secureserver.net ([184.168.131.9]) by p3plex2out03.prod.phx3.secureserver.net with bizsmtp id MWx81j0040CJzpC01Wx88N; Tue, 12 Jun 2012 11:57:08 -0700 Received: from P3PWEX2MB008.ex2.secureserver.net ([169.254.8.66]) by P3PWEX2HT001.ex2.secureserver.net ([184.168.131.9]) with mapi id 14.02.0247.003; Tue, 12 Jun 2012 11:57:08 -0700 From: Eran Hammer To: George Fletcher Thread-Topic: [OAUTH-WG] Discussion needed on username and password ABNF definitions Thread-Index: AQHNSMj7QEQmi4O4F06tenKhdYMV75b3AxBQgAB3YAD//41OkA== Date: Tue, 12 Jun 2012 18:57:07 +0000 Message-ID: <0CBAEB56DDB3A140BA8E8C124C04ECA20106EDD0@P3PWEX2MB008.ex2.secureserver.net> References: <4E1F6AAD24975D4BA5B16804296739436652F52D@TK5EX14MBXC284.redmond.corp.microsoft.com> <4FD4E9D4.2010808@gmx.de> <4E1F6AAD24975D4BA5B168042967394366531375@TK5EX14MBXC284.redmond.corp.microsoft.com> <4FD4F976.6090801@gmx.de> <4E1F6AAD24975D4BA5B1680429673943665316D1@TK5EX14MBXC284.redmond.corp.microsoft.com> <60F5CCB0-E036-4351-BD10-A44B33FCC5F6@ve7jtb.com> <255B9BB34FB7D647A506DC292726F6E114F5474E29@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B1680429673943665346D0@TK5EX14MBXC284.redmond.corp.microsoft.com> <4FD703C4.6050801@gmx.de> <5E38109E-2123-418B-8D45-B8DF4287790D@gmx.net> <1339525052.8121.YahooMailNeo@web31807.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B168042967394366535EAD@TK5EX14MBXC284.redmond.corp.microsoft.com> <0CBAEB56DDB3A140BA8E8C124C04ECA20106ED1F@P3PWEX2MB008.ex2.secureserver.net> <4FD78DF0.8030606@aol.com> In-Reply-To: <4FD78DF0.8030606@aol.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [37.46.32.109] Content-Type: multipart/alternative; boundary="_000_0CBAEB56DDB3A140BA8E8C124C04ECA20106EDD0P3PWEX2MB008ex2_" MIME-Version: 1.0 Cc: Julian Reschke , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 18:57:13 -0000 --_000_0CBAEB56DDB3A140BA8E8C124C04ECA20106EDD0P3PWEX2MB008ex2_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Encoding is an option which does not require us to address it. Those seekin= g to use URIs can simply specify that. However, Julian indicated earlier that this restriction in Basic may change= , in which case we can reference Basic and simply add an interop warning (l= ike the one we have for redirections including a fragment) about it. EH From: George Fletcher [mailto:gffletch@aol.com] Sent: Tuesday, June 12, 2012 11:44 AM To: Eran Hammer Cc: Mike Jones; William Mills; Hannes Tschofenig; Julian Reschke; oauth@iet= f.org Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF def= initions I agree that there is value in allowing the client_id to be a URI. The prob= lem is that the ':' of the URI is not allowed in HTTP Basic which is requir= ed by the OAuth2 spec for client authentication. We could encode the client= _id before HTTP Basic but that needs to be documented and adds complexity. Thanks, George On 6/12/12 2:39 PM, Eran Hammer wrote: Is the use case of using URI as client ids important? It seems like somethi= ng that might become useful in the future where clients can use their verif= iable servers to bypass client registration and simly use a URI the server = can validate via some other means. I just want to make sure those thinking about more complex use cases involv= ing dynamic registration or distributed client manamgenet are aware of this= potential restriction. I'm fine either way. EH From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Mike Jones Sent: Tuesday, June 12, 2012 11:27 AM To: William Mills; Hannes Tschofenig; Julian Reschke Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF def= initions Not internationalizing fields intended for machine consumption only is alre= ady a precedent set and agreed to by the working group, so let me second Bi= ll's point in that regard. For instance, neither "scope" nor "error" allow= non-ASCII characters. Julian, if you want different ABNF text than the text I wrote below, I beli= eve it would be most useful if you would provide the exact replace wording = that you'd like to see instead of it. Then there's no possibility of misun= derstanding the intent of suggested changes. Thanks all, -- Mike From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Willi= am Mills Sent: Tuesday, June 12, 2012 11:18 AM To: Hannes Tschofenig; Julian Reschke Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF def= initions I agree generally with your assumption about clients, but rather than sayin= g "clients are devices" I think it makes much more sense to say "clients ar= e NOT users, so client_id need not be internationalized". In practical ter= ms there is very little to argue for anythign beyond ASCII in a client_secr= et, base64 encoding or the equivalent being a fine way to transport arbitra= ry bits in a portable/reasonable way. I argue that client_id need not be internationalized because I assume that = any really internationalized application will have an internationalized pre= sentation layer that's presenting a pretty name for the client_id. -bill ________________________________ From: Hannes Tschofenig > To: Julian Reschke > Cc: "oauth@ietf.org" > Sent: Tuesday, June 12, 2012 11:01 AM Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF def= initions I had a chat with Julian yesterday and here is my short summary. Section 2.3 of the core draft defines client authentication based on two me= chanisms (and provides room for extensions): http://tools.ietf.org/html/dra= ft-ietf-oauth-v2-27#section-2.3 1) HTTP Basic Authentication 2) A custom OAuth authentication mechanism (which uses client_id and client= _secret) With HTTP Basic authentication the problem is that this is a legacy technol= ogy and there is no internationalization support. With our brand new custom OAuth authentication mechanism we have more optio= ns. One possible approach is to say that the clients are devices (and not end u= sers) and therefore internationalization does not matter. Is it, however, really true that only US-ASCII characters will appear in th= e client_id and also in the client_secret? Here we have the possibility to define something better. In any case we have to restrict the characters that are used in these two a= uthentication mechanisms since they could conflict with the way how we tran= sport the data over the underlying protocol. Julian mentioned this in his p= revious mails. Julian, maybe you can provide a detailed text proposal for how to address y= our comment in case we go for UTF8 (with % encoding) for the custom OAuth c= lient authentication mechanism? Ciao Hannes On Jun 12, 2012, at 11:54 AM, Julian Reschke wrote: > On 2012-06-12 00:16, Mike Jones wrote: >> Reviewing the feedback from Julian, John, and James, I'm coming to the c= onclusion that client_id and client_secret, being for machines and not huma= ns, should be ASCII, whereas username and password should be Unicode, since= they are for humans. Per John's feedback, client_id can not contain a col= on and be compatible with HTTP Basic. > > I'm not sure that restricting the character repertoire just because one w= ay to send requires this is the right approach. My preference would be not = to put this into the ABNF, and just to point out that certain characters wi= ll not work over certain transports, and to just advise to avoid them. > >> Therefore, I'd like to propose these updated ABNF definitions: >> >> VSCHAR =3D %20-7E >> NOCOLONVSCHAR =3D %x20-39 / %x3B-7E >> UNICODENOCTRLCHAR =3D >> >> client-id =3D *NOCOLONVSCHAR >> client_secret =3D *VSCHAR >> >> username =3D *UNICODENOCTRLCHAR >> password =3D *UNICODENOCTRLCHAR > > In this case you should add an introductory statement pointing out that t= he ABNF defines the grammar in terms of Unicode code points, not octets (as= it is the case most of the time). > >> It turns out that non-ASCII characters are OK for username and password = because the Core spec only passes them in the form body - not using HTTP Ba= sic - and UTF-8 encoding is specified. > > I'll send a separate mail about that, the current text in the spec is way= too unspecific. > >> -- Mike >> >> P.S. If anyone has a better ABNF for UNICODENOCTRLCHAR than "", please send it to me! > > As noted before, here's an example: > > Best regards, Julian > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_0CBAEB56DDB3A140BA8E8C124C04ECA20106EDD0P3PWEX2MB008ex2_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Encoding is an option whi= ch does not require us to address it. Those seeking to use URIs can simply = specify that.

 <= /p>

However, Julian indicated= earlier that this restriction in Basic may change, in which case we can re= ference Basic and simply add an interop warning (like the one we have for redirections including a fragment) about it.

 <= /p>

EH

 <= /p>

From: George Fletcher [mailto:gffletch@aol.com]
Sent: Tuesday, June 12, 2012 11:44 AM
To: Eran Hammer
Cc: Mike Jones; William Mills; Hannes Tschofenig; Julian Reschke; oa= uth@ietf.org
Subject: Re: [OAUTH-WG] Discussion needed on username and password A= BNF definitions

 

I agree that there is value in allowing the client_id = to be a URI. The problem is that the ':' of the URI is not allowed in HTTP = Basic which is required by the OAuth2 spec for client authentication. We could encode the client_id before HTTP Basic but that needs to be docum= ented and adds complexity.

Thanks,
George

On 6/12/12 2:39 PM, Eran Hammer wrote:

Is the use case of using = URI as client ids important? It seems like something that might become usef= ul in the future where clients can use their verifiable servers to bypass client registration and simly use a URI the server can v= alidate via some other means.

 <= /p>

I just want to make sure = those thinking about more complex use cases involving dynamic registration = or distributed client manamgenet are aware of this potential restriction.

 <= /p>

I'm fine either way.

 <= /p>

EH

 <= /p>

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Tuesday, June 12, 2012 11:27 AM
To: William Mills; Hannes Tschofenig; Julian Reschke
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Discussion needed on username and password A= BNF definitions

 

Not internationalizing fi= elds intended for machine consumption only is already a precedent set and a= greed to by the working group, so let me second Bill’s point in that regard.  For instance, neither “scope” nor “= ;error” allow non-ASCII characters.

 <= /p>

Julian, if you want diffe= rent ABNF text than the text I wrote below, I believe it would be most usef= ul if you would provide the exact replace wording that you’d like to see instead of it.  Then there’s no possibility of misu= nderstanding the intent of suggested changes.

 <= /p>

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;     Thanks all,

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

 <= /p>

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of William Mills
Sent: Tuesday, June 12, 2012 11:18 AM
To: Hannes Tschofenig; Julian Reschke
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Discussion needed on username and password A= BNF definitions

 

= I agree generally with your assumption about clients, but rather than sayin= g "clients are devices" I think it makes much more sense to say "clients are NOT users, so client_id need not be internationalize= d".  In practical terms there is very little to argue for anythig= n beyond ASCII in a client_secret, base64 encoding or the equivalent being = a fine way to transport arbitrary bits in a portable/reasonable way.

=  

= I argue that client_id need not be internationalized because I assume that = any really internationalized application will have an internationalized presentation layer that's presenting a pretty name for the client_id.

=  

= -bill

 

From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
To: Julian Reschke <juli= an.reschke@gmx.de>
Cc: "oauth@ietf.org"= <oauth@ietf.org>
Sent: Tuesday, June 12, 2012 11:01 AM
Subject: Re: [OAUTH-WG] Discussion needed on username and password A= BNF definitions


I had a chat with Julian yesterday and here is my short summary.

Section 2.3 of the core draft defines client authentication based on two me= chanisms (and provides room for extensions): h= ttp://tools.ietf.org/html/draft-ietf-oauth-v2-27#section-2.3

1) HTTP Basic Authentication

2) A custom OAuth authentication mechanism (which uses client_id and client= _secret)

With HTTP Basic authentication the problem is that this is a legacy technol= ogy and there is no internationalization support.

With our brand new custom OAuth authentication mechanism we have more optio= ns.

One possible approach is to say that the clients are devices (and not end u= sers) and therefore internationalization does not matter.

Is it, however, really true that only US-ASCII characters will appear in th= e client_id and also in the client_secret?

Here we have the possibility to define something better.

In any case we have to restrict the characters that are used in these two a= uthentication mechanisms since they could conflict with the way how we tran= sport the data over the underlying protocol. Julian mentioned this in his p= revious mails.

Julian, maybe you can provide a detailed text proposal for how to address y= our comment in case we go for UTF8 (with % encoding) for the custom OAuth c= lient authentication mechanism?

Ciao
Hannes

On Jun 12, 2012, at 11:54 AM, Julian Reschke wrote:

> On 2012-06-12 00:16, Mike Jones wrote:
>> Reviewing the feedback from Julian, John, and James, I'm coming to= the conclusion that client_id and client_secret, being for machines and no= t humans, should be ASCII, whereas username and password should be Unicode,= since they are for humans.  Per John's feedback, client_id can not contain a colon and be compatible with HTTP Ba= sic.
>
> I'm not sure that restricting the character repertoire just because on= e way to send requires this is the right approach. My preference would be n= ot to put this into the ABNF, and just to point out that certain characters= will not work over certain transports, and to just advise to avoid them.
>
>> Therefore, I'd like to propose these updated ABNF definitions:
>>
>>    VSCHAR =3D %20-7E
>>    NOCOLONVSCHAR =3D %x20-39 / %x3B-7E
>>    UNICODENOCTRLCHAR =3D <Any Unicode character other= than ( %x0-1F / %x7F )>
>>
>>    client-id =3D *NOCOLONVSCHAR
>>    client_secret =3D *VSCHAR
>>
>>    username =3D *UNICODENOCTRLCHAR
>>    password =3D *UNICODENOCTRLCHAR
>
> In this case you should add an introductory statement pointing out tha= t the ABNF defines the grammar in terms of Unicode code points, not octets = (as it is the case most of the time).
>
>> It turns out that non-ASCII characters are OK for username and pas= sword because the Core spec only passes them in the form body - not using H= TTP Basic - and UTF-8 encoding is specified.
>
> I'll send a separate mail about that, the current text in the spec is = way too unspecific.
>
>>              &nb= sp;  -- Mike
>>
>> P.S.  If anyone has a better ABNF for UNICODENOCTRLCHAR than = "<Any Unicode character other than ( %x0-1F / %x7F )>", ple= ase send it to me!
>
> As noted before, here's an example: <http://greenbytes.de/tech/we= bdav/rfc5323.html#rfc.section.5.15.1>
>
> Best regards, Julian
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

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




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

 

--_000_0CBAEB56DDB3A140BA8E8C124C04ECA20106EDD0P3PWEX2MB008ex2_-- From Michael.Jones@microsoft.com Tue Jun 12 12:20:41 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CF3E21F8699 for ; Tue, 12 Jun 2012 12:20:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.848 X-Spam-Level: X-Spam-Status: No, score=-3.848 tagged_above=-999 required=5 tests=[AWL=-0.250, 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 Iqch3XO1+YoZ for ; Tue, 12 Jun 2012 12:20:36 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe001.messaging.microsoft.com [216.32.181.181]) by ietfa.amsl.com (Postfix) with ESMTP id 960AC21F8625 for ; Tue, 12 Jun 2012 12:20:35 -0700 (PDT) Received: from mail109-ch1-R.bigfish.com (10.43.68.228) by CH1EHSOBE001.bigfish.com (10.43.70.51) with Microsoft SMTP Server id 14.1.225.23; Tue, 12 Jun 2012 19:19:32 +0000 Received: from mail109-ch1 (localhost [127.0.0.1]) by mail109-ch1-R.bigfish.com (Postfix) with ESMTP id A5F0EA032E; Tue, 12 Jun 2012 19:19:32 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -26 X-BigFish: VS-26(zzbb2dI98dI9371I936eIc85fh1432I4015Izz1202hzz8275ch1033IL8275bh8275dhz2fh2a8h668h839hd25hf0ah) Received-SPF: pass (mail109-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail109-ch1 (localhost.localdomain [127.0.0.1]) by mail109-ch1 (MessageSwitch) id 1339528770209093_24212; Tue, 12 Jun 2012 19:19:30 +0000 (UTC) Received: from CH1EHSMHS022.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.230]) by mail109-ch1.bigfish.com (Postfix) with ESMTP id 2F3AC40043; Tue, 12 Jun 2012 19:19:30 +0000 (UTC) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS022.bigfish.com (10.43.70.22) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 12 Jun 2012 19:19:29 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.189]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.02.0298.005; Tue, 12 Jun 2012 19:20:11 +0000 From: Mike Jones To: George Fletcher , Eran Hammer Thread-Topic: [OAUTH-WG] Discussion needed on username and password ABNF definitions Thread-Index: AQHNSMqx/TSmba1BAEWAD0wrq5RBPJb3BRMAgAAAaLA= Date: Tue, 12 Jun 2012 19:20:10 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436653606B@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739436652F52D@TK5EX14MBXC284.redmond.corp.microsoft.com> <4FD4E9D4.2010808@gmx.de> <4E1F6AAD24975D4BA5B168042967394366531375@TK5EX14MBXC284.redmond.corp.microsoft.com> <4FD4F976.6090801@gmx.de> <4E1F6AAD24975D4BA5B1680429673943665316D1@TK5EX14MBXC284.redmond.corp.microsoft.com> <60F5CCB0-E036-4351-BD10-A44B33FCC5F6@ve7jtb.com> <255B9BB34FB7D647A506DC292726F6E114F5474E29@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B1680429673943665346D0@TK5EX14MBXC284.redmond.corp.microsoft.com> <4FD703C4.6050801@gmx.de> <5E38109E-2123-418B-8D45-B8DF4287790D@gmx.net> <1339525052.8121.YahooMailNeo@web31807.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B168042967394366535EAD@TK5EX14MBXC284.redmond.corp.microsoft.com> <0CBAEB56DDB3A140BA8E8C124C04ECA20106ED1F@P3PWEX2MB008.ex2.secureserver.net> <4FD78DF0.8030606@aol.com> In-Reply-To: <4FD78DF0.8030606@aol.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436653606BTK5EX14MBXC284r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: Julian Reschke , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 19:20:42 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436653606BTK5EX14MBXC284r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Frankly, I know of an OpenID Connect use case where it would really useful = to be able to use URIs as client_id values, so the exclusion of colon (":")= is unfortunate. (Some clients might want to use URIs with iOS custom sche= mas in some cases.) In this use case, the client_id would never be sent usi= ng HTTP Basic, so the prohibition against colon is actually unnecessary. Therefore, I'm somewhat sympathetic to relaxing the restriction on client_i= d and client_password, but pointing out that if they are used with HTTP Bas= ic, the more restricted character set required by it MUST be used. I think= Julian was thinking along those lines as well. -- Mike From: George Fletcher [mailto:gffletch@aol.com] Sent: Tuesday, June 12, 2012 11:44 AM To: Eran Hammer Cc: Mike Jones; William Mills; Hannes Tschofenig; Julian Reschke; oauth@iet= f.org Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF def= initions I agree that there is value in allowing the client_id to be a URI. The prob= lem is that the ':' of the URI is not allowed in HTTP Basic which is requir= ed by the OAuth2 spec for client authentication. We could encode the client= _id before HTTP Basic but that needs to be documented and adds complexity. Thanks, George On 6/12/12 2:39 PM, Eran Hammer wrote: Is the use case of using URI as client ids important? It seems like somethi= ng that might become useful in the future where clients can use their verif= iable servers to bypass client registration and simly use a URI the server = can validate via some other means. I just want to make sure those thinking about more complex use cases involv= ing dynamic registration or distributed client manamgenet are aware of this= potential restriction. I'm fine either way. EH From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Mike Jones Sent: Tuesday, June 12, 2012 11:27 AM To: William Mills; Hannes Tschofenig; Julian Reschke Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF def= initions Not internationalizing fields intended for machine consumption only is alre= ady a precedent set and agreed to by the working group, so let me second Bi= ll's point in that regard. For instance, neither "scope" nor "error" allow= non-ASCII characters. Julian, if you want different ABNF text than the text I wrote below, I beli= eve it would be most useful if you would provide the exact replace wording = that you'd like to see instead of it. Then there's no possibility of misun= derstanding the intent of suggested changes. Thanks all, -- Mike From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Willi= am Mills Sent: Tuesday, June 12, 2012 11:18 AM To: Hannes Tschofenig; Julian Reschke Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF def= initions I agree generally with your assumption about clients, but rather than sayin= g "clients are devices" I think it makes much more sense to say "clients ar= e NOT users, so client_id need not be internationalized". In practical ter= ms there is very little to argue for anythign beyond ASCII in a client_secr= et, base64 encoding or the equivalent being a fine way to transport arbitra= ry bits in a portable/reasonable way. I argue that client_id need not be internationalized because I assume that = any really internationalized application will have an internationalized pre= sentation layer that's presenting a pretty name for the client_id. -bill ________________________________ From: Hannes Tschofenig > To: Julian Reschke > Cc: "oauth@ietf.org" > Sent: Tuesday, June 12, 2012 11:01 AM Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF def= initions I had a chat with Julian yesterday and here is my short summary. Section 2.3 of the core draft defines client authentication based on two me= chanisms (and provides room for extensions): http://tools.ietf.org/html/dra= ft-ietf-oauth-v2-27#section-2.3 1) HTTP Basic Authentication 2) A custom OAuth authentication mechanism (which uses client_id and client= _secret) With HTTP Basic authentication the problem is that this is a legacy technol= ogy and there is no internationalization support. With our brand new custom OAuth authentication mechanism we have more optio= ns. One possible approach is to say that the clients are devices (and not end u= sers) and therefore internationalization does not matter. Is it, however, really true that only US-ASCII characters will appear in th= e client_id and also in the client_secret? Here we have the possibility to define something better. In any case we have to restrict the characters that are used in these two a= uthentication mechanisms since they could conflict with the way how we tran= sport the data over the underlying protocol. Julian mentioned this in his p= revious mails. Julian, maybe you can provide a detailed text proposal for how to address y= our comment in case we go for UTF8 (with % encoding) for the custom OAuth c= lient authentication mechanism? Ciao Hannes On Jun 12, 2012, at 11:54 AM, Julian Reschke wrote: > On 2012-06-12 00:16, Mike Jones wrote: >> Reviewing the feedback from Julian, John, and James, I'm coming to the c= onclusion that client_id and client_secret, being for machines and not huma= ns, should be ASCII, whereas username and password should be Unicode, since= they are for humans. Per John's feedback, client_id can not contain a col= on and be compatible with HTTP Basic. > > I'm not sure that restricting the character repertoire just because one w= ay to send requires this is the right approach. My preference would be not = to put this into the ABNF, and just to point out that certain characters wi= ll not work over certain transports, and to just advise to avoid them. > >> Therefore, I'd like to propose these updated ABNF definitions: >> >> VSCHAR =3D %20-7E >> NOCOLONVSCHAR =3D %x20-39 / %x3B-7E >> UNICODENOCTRLCHAR =3D >> >> client-id =3D *NOCOLONVSCHAR >> client_secret =3D *VSCHAR >> >> username =3D *UNICODENOCTRLCHAR >> password =3D *UNICODENOCTRLCHAR > > In this case you should add an introductory statement pointing out that t= he ABNF defines the grammar in terms of Unicode code points, not octets (as= it is the case most of the time). > >> It turns out that non-ASCII characters are OK for username and password = because the Core spec only passes them in the form body - not using HTTP Ba= sic - and UTF-8 encoding is specified. > > I'll send a separate mail about that, the current text in the spec is way= too unspecific. > >> -- Mike >> >> P.S. If anyone has a better ABNF for UNICODENOCTRLCHAR than "", please send it to me! > > As noted before, here's an example: > > Best regards, Julian > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_4E1F6AAD24975D4BA5B16804296739436653606BTK5EX14MBXC284r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Frankly, I know of an Ope= nID Connect use case where it would really useful to be able to use URIs as= client_id values, so the exclusion of colon (“:”) is unfortuna= te.  (Some clients might want to use URIs with iOS custom schemas in some cases= .) In this use case, the client_id would never be sent using HTTP Basic, so= the prohibition against colon is actually unnecessary.

 <= /p>

Therefore, I’m some= what sympathetic to relaxing the restriction on client_id and client_passwo= rd, but pointing out that if they are used with HTTP Basic, the more restricted character set required by it MUST be used.  I think J= ulian was thinking along those lines as well.

 <= /p>

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

 <= /p>

From: George Fletcher [mailto:gffletch@aol.com]
Sent: Tuesday, June 12, 2012 11:44 AM
To: Eran Hammer
Cc: Mike Jones; William Mills; Hannes Tschofenig; Julian Reschke; oa= uth@ietf.org
Subject: Re: [OAUTH-WG] Discussion needed on username and password A= BNF definitions

 

I agree that there is value in allowing the client_id = to be a URI. The problem is that the ':' of the URI is not allowed in HTTP = Basic which is required by the OAuth2 spec for client authentication. We could encode the client_id before HTTP Basic but that needs to be docum= ented and adds complexity.

Thanks,
George

On 6/12/12 2:39 PM, Eran Hammer wrote:

Is the use case of using = URI as client ids important? It seems like something that might become usef= ul in the future where clients can use their verifiable servers to bypass client registration and simly use a URI the server can v= alidate via some other means.

 <= /p>

I just want to make sure = those thinking about more complex use cases involving dynamic registration = or distributed client manamgenet are aware of this potential restriction.

 <= /p>

I'm fine either way.

 <= /p>

EH

 <= /p>

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Tuesday, June 12, 2012 11:27 AM
To: William Mills; Hannes Tschofenig; Julian Reschke
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Discussion needed on username and password A= BNF definitions

 

Not internationalizing fi= elds intended for machine consumption only is already a precedent set and a= greed to by the working group, so let me second Bill’s point in that regard.  For instance, neither “scope” nor “= ;error” allow non-ASCII characters.

 <= /p>

Julian, if you want diffe= rent ABNF text than the text I wrote below, I believe it would be most usef= ul if you would provide the exact replace wording that you’d like to see instead of it.  Then there’s no possibility of misu= nderstanding the intent of suggested changes.

 <= /p>

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;     Thanks all,

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

 <= /p>

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of William Mills
Sent: Tuesday, June 12, 2012 11:18 AM
To: Hannes Tschofenig; Julian Reschke
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Discussion needed on username and password A= BNF definitions

 

= I agree generally with your assumption about clients, but rather than sayin= g "clients are devices" I think it makes much more sense to say "clients are NOT users, so client_id need not be internationalize= d".  In practical terms there is very little to argue for anythig= n beyond ASCII in a client_secret, base64 encoding or the equivalent being = a fine way to transport arbitrary bits in a portable/reasonable way.

=  

= I argue that client_id need not be internationalized because I assume that = any really internationalized application will have an internationalized presentation layer that's presenting a pretty name for the client_id.

=  

= -bill

 

From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
To: Julian Reschke <juli= an.reschke@gmx.de>
Cc: "oauth@ietf.org"= <oauth@ietf.org>
Sent: Tuesday, June 12, 2012 11:01 AM
Subject: Re: [OAUTH-WG] Discussion needed on username and password A= BNF definitions


I had a chat with Julian yesterday and here is my short summary.

Section 2.3 of the core draft defines client authentication based on two me= chanisms (and provides room for extensions): h= ttp://tools.ietf.org/html/draft-ietf-oauth-v2-27#section-2.3

1) HTTP Basic Authentication

2) A custom OAuth authentication mechanism (which uses client_id and client= _secret)

With HTTP Basic authentication the problem is that this is a legacy technol= ogy and there is no internationalization support.

With our brand new custom OAuth authentication mechanism we have more optio= ns.

One possible approach is to say that the clients are devices (and not end u= sers) and therefore internationalization does not matter.

Is it, however, really true that only US-ASCII characters will appear in th= e client_id and also in the client_secret?

Here we have the possibility to define something better.

In any case we have to restrict the characters that are used in these two a= uthentication mechanisms since they could conflict with the way how we tran= sport the data over the underlying protocol. Julian mentioned this in his p= revious mails.

Julian, maybe you can provide a detailed text proposal for how to address y= our comment in case we go for UTF8 (with % encoding) for the custom OAuth c= lient authentication mechanism?

Ciao
Hannes

On Jun 12, 2012, at 11:54 AM, Julian Reschke wrote:

> On 2012-06-12 00:16, Mike Jones wrote:
>> Reviewing the feedback from Julian, John, and James, I'm coming to= the conclusion that client_id and client_secret, being for machines and no= t humans, should be ASCII, whereas username and password should be Unicode,= since they are for humans.  Per John's feedback, client_id can not contain a colon and be compatible with HTTP Ba= sic.
>
> I'm not sure that restricting the character repertoire just because on= e way to send requires this is the right approach. My preference would be n= ot to put this into the ABNF, and just to point out that certain characters= will not work over certain transports, and to just advise to avoid them.
>
>> Therefore, I'd like to propose these updated ABNF definitions:
>>
>>    VSCHAR =3D %20-7E
>>    NOCOLONVSCHAR =3D %x20-39 / %x3B-7E
>>    UNICODENOCTRLCHAR =3D <Any Unicode character other= than ( %x0-1F / %x7F )>
>>
>>    client-id =3D *NOCOLONVSCHAR
>>    client_secret =3D *VSCHAR
>>
>>    username =3D *UNICODENOCTRLCHAR
>>    password =3D *UNICODENOCTRLCHAR
>
> In this case you should add an introductory statement pointing out tha= t the ABNF defines the grammar in terms of Unicode code points, not octets = (as it is the case most of the time).
>
>> It turns out that non-ASCII characters are OK for username and pas= sword because the Core spec only passes them in the form body - not using H= TTP Basic - and UTF-8 encoding is specified.
>
> I'll send a separate mail about that, the current text in the spec is = way too unspecific.
>
>>              &nb= sp;  -- Mike
>>
>> P.S.  If anyone has a better ABNF for UNICODENOCTRLCHAR than = "<Any Unicode character other than ( %x0-1F / %x7F )>", ple= ase send it to me!
>
> As noted before, here's an example: <http://greenbytes.de/tech/we= bdav/rfc5323.html#rfc.section.5.15.1>
>
> Best regards, Julian
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

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




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

 

--_000_4E1F6AAD24975D4BA5B16804296739436653606BTK5EX14MBXC284r_-- From wmills@yahoo-inc.com Tue Jun 12 13:04:15 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F348521F8510 for ; Tue, 12 Jun 2012 13:04:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.196 X-Spam-Level: X-Spam-Status: No, score=-17.196 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7+AVKfHlOig1 for ; Tue, 12 Jun 2012 13:04:13 -0700 (PDT) Received: from nm11.bullet.mail.bf1.yahoo.com (nm11.bullet.mail.bf1.yahoo.com [98.139.212.170]) by ietfa.amsl.com (Postfix) with SMTP id 3C72721F84A1 for ; Tue, 12 Jun 2012 13:04:12 -0700 (PDT) Received: from [98.139.215.142] by nm11.bullet.mail.bf1.yahoo.com with NNFMP; 12 Jun 2012 20:04:11 -0000 Received: from [98.139.212.240] by tm13.bullet.mail.bf1.yahoo.com with NNFMP; 12 Jun 2012 20:04:11 -0000 Received: from [127.0.0.1] by omp1049.mail.bf1.yahoo.com with NNFMP; 12 Jun 2012 20:04:11 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 631348.10249.bm@omp1049.mail.bf1.yahoo.com Received: (qmail 44304 invoked by uid 60001); 12 Jun 2012 20:04:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1339531450; bh=47zcoT8r4kgETWjpx0JoaVQvTUMzdW4G9s4CLCr1QcQ=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=FAL6wDlf55KJGaOoLqM1o5fodzsJBtts6ZTDgLCw/IxBwwdPecec7mitJOs9bo/9njBZNwDiifYagGgey6e16JCCeyCV5xccJ5Sk1eLucJhrojopAOQvF/e6JugwLZ9571rSJ/6eUoX7tNxVTUL+cezw/oDPtE1oyJANbD3Ry74= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=tNaLLYkz9dpb5y14Vrh9IGsypk3r42wY+ZSBQCcgi8FtpyGD02O6mEyCXyLVT7F2q2Qt3lV9Zc1rm/9c44yyV5EomTqRN2BrqW/NY2cR1R/6XWqmvNJm79ePFu3GzuYaD/JdmhGJ2rciDNHv0IM3TUHr6loRROfFZj/1UQR30A8=; X-YMail-OSG: TFbGN3sVM1lwmvR559hpaLiAikhW1EBsv2DvbGQykGOoxQG qJgCdat0AeYTfge7hFapguZZujKFo5S1DAk3B5ueNgW1V06UdVlCCZjGGexL mxENYUdbAbVsGnJodECdZ9k5NDN_rTPv1l7FIzb9HxW8ijlQtkrOBp4KIpC2 zXj9gpacqqYQWqqvkRhyuHymDe8MASMDHy5wJgntCSWIYkMcErGrNw496n.I VzWFkoqSshSnUbBnjg4mlqKDpGefFbxyrMoy9Xlk2L8uUe7NEGLUX5U5617x xhkQRXRw0BcJJxEELLErgiZ6Cm52UgWtUBCRZHkbGMkKLlXG_f2B0fWRsxiu 3Dohq69brOhWJ3l4OLdpSRm16iexH5s9xLdRUVJQYPFmb2KJq2ROniz.Nsoh SeCQfkFHSn_Xn.ILeyoFXRgoaC89CCXFpQoTz4XMUbactfdScyd06BiKcIhL sxAkrfEF8S5ttOuZzFpZHTVedWc0oORz.aruW8IMrnCrxW0bQ82S62sc_rdl y3a8iOdodPHHD5gwbC6Gf3Q-- Received: from [209.131.62.115] by web31809.mail.mud.yahoo.com via HTTP; Tue, 12 Jun 2012 13:04:10 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.118.349524 References: <4E1F6AAD24975D4BA5B16804296739436652F52D@TK5EX14MBXC284.redmond.corp.microsoft.com> <4FD4E9D4.2010808@gmx.de> <4E1F6AAD24975D4BA5B168042967394366531375@TK5EX14MBXC284.redmond.corp.microsoft.com> <4FD4F976.6090801@gmx.de> <4E1F6AAD24975D4BA5B1680429673943665316D1@TK5EX14MBXC284.redmond.corp.microsoft.com> <60F5CCB0-E036-4351-BD10-A44B33FCC5F6@ve7jtb.com> <255B9BB34FB7D647A506DC292726F6E114F5474E29@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B1680429673943665346D0@TK5EX14MBXC284.redmond.corp.microsoft.com> <4FD703C4.6050801@gmx.de> <5E38109E-2123-418B-8D45-B8DF4287790D@gmx.net> <1339525052.8121.YahooMailNeo@web31807.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B168042967394366535EAD@TK5EX14MBXC284.redmond.corp.microsoft.com> <0CBAEB56DDB3A140BA8E8C124C04ECA20106ED1F@P3PWEX2MB008.ex2.secureserver.net> Message-ID: <1339531450.39923.YahooMailNeo@web31809.mail.mud.yahoo.com> Date: Tue, 12 Jun 2012 13:04:10 -0700 (PDT) From: William Mills To: Eran Hammer , Mike Jones , Hannes Tschofenig , Julian Reschke In-Reply-To: <0CBAEB56DDB3A140BA8E8C124C04ECA20106ED1F@P3PWEX2MB008.ex2.secureserver.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1395015409-1554170055-1339531450=:39923" Cc: "oauth@ietf.org" Subject: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion needed on username and password ABNF definitions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 20:04:15 -0000 ---1395015409-1554170055-1339531450=:39923 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I think dynamic client registration is something we have not talked out eno= ugh yet.=C2=A0 There's a pretty clear use case for dynamic registration.=C2= =A0=C2=A0=0A=0ADoes identifying the client with a URI allow some form of Op= enID-ish flow for this?=C2=A0 =0A=0AIs the client ID as a URI a way to allo= w a trusted site to provide metadata about the client?=0AIs that URI a way = to hit an IDP we trust to validate the client in some way with the provided= secret?=0A=0A=0AI guess what I'm looking for here is a concrete use case/p= roblem to solve, rather then leaving a hook we think is the right thing.=0A= =0A-bill=0A=0A=0A=0A=0A=0A>________________________________=0A> From: Eran = Hammer =0A>To: Mike Jones ; William Mills ; Hannes Tschofenig ; Julian Reschke =0A>Cc: "oauth@ietf.org= " =0A>Sent: Tuesday, June 12, 2012 11:39 AM=0A>Subject: RE= : [OAUTH-WG] Discussion needed on username and password ABNF definitions=0A= > =0A>=0A> =0A>Is the use case of using URI as client ids important? It see= ms like something that might become useful in the future where clients can = use their verifiable servers to bypass client registration and simly use a = URI the server can validate via some other means.=0A>=C2=A0=0A>I just want = to make sure those thinking about more complex use cases involving dynamic = registration or distributed client manamgenet are aware of this potential r= estriction.=0A>=C2=A0=0A>I'm fine either way.=0A>=C2=A0=0A>EH=0A>=C2=A0=0A>= From:oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Mi= ke Jones=0A>Sent: Tuesday, June 12, 2012 11:27 AM=0A>To: William Mills; Han= nes Tschofenig; Julian Reschke=0A>Cc: oauth@ietf.org=0A>Subject: Re: [OAUTH= -WG] Discussion needed on username and password ABNF definitions=0A>=C2=A0= =0A>Not internationalizing fields intended for machine consumption only is = already a precedent set and agreed to by the working group, so let me secon= d Bill=E2=80=99s point in that regard.=C2=A0 For instance, neither =E2=80= =9Cscope=E2=80=9D nor =E2=80=9Cerror=E2=80=9D allow non-ASCII characters.= =0A>=C2=A0=0A>Julian, if you want different ABNF text than the text I wrote= below, I believe it would be most useful if you would provide the exact re= place wording that you=E2=80=99d like to see instead of it.=C2=A0 Then ther= e=E2=80=99s no possibility of misunderstanding the intent of suggested chan= ges.=0A>=C2=A0=0A>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Th= anks all,=0A>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mi= ke=0A>=C2=A0=0A>From:oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]= On Behalf Of William Mills=0A>Sent: Tuesday, June 12, 2012 11:18 AM=0A>To:= Hannes Tschofenig; Julian Reschke=0A>Cc: oauth@ietf.org=0A>Subject: Re: [O= AUTH-WG] Discussion needed on username and password ABNF definitions=0A>=C2= =A0=0A>I agree generally with your assumption about clients, but rather tha= n saying "clients are devices" I think it makes much more sense to say "cli= ents are NOT users, so client_id need not be internationalized".=C2=A0 In p= ractical terms there is very little to argue for anythign beyond ASCII in a= client_secret, base64 encoding or the equivalent being a fine way to trans= port arbitrary bits in a portable/reasonable way.=0A>=C2=A0=0A>I argue that= client_id need not be internationalized because I assume that any really i= nternationalized application will have an internationalized presentation la= yer that's presenting a pretty name for the client_id.=0A>=C2=A0=0A>-bill= =0A>=C2=A0=0A>=0A>________________________________=0A> =0A>From:Hannes Tsch= ofenig =0A>To: Julian Reschke =0A>Cc: "oauth@ietf.org" =0A>Sent: Tuesday, June 12,= 2012 11:01 AM=0A>Subject: Re: [OAUTH-WG] Discussion needed on username and= password ABNF definitions=0A>=0A>I had a chat with Julian yesterday and he= re is my short summary. =0A>=0A>Section 2.3 of the core draft defines clien= t authentication based on two mechanisms (and provides room for extensions)= :=0Ahttp://tools.ietf.org/html/draft-ietf-oauth-v2-27#section-2.3=0A>=0A>1)= HTTP Basic Authentication=0A>=0A>2) A custom OAuth authentication mechanis= m (which uses client_id and client_secret)=0A>=0A>With HTTP Basic authentic= ation the problem is that this is a legacy technology and there is no inter= nationalization support. =0A>=0A>With our brand new custom OAuth authentica= tion mechanism we have more options. =0A>=0A>One possible approach is to sa= y that the clients are devices (and not end users) and therefore internatio= nalization does not matter. =0A>=0A>Is it, however, really true that only U= S-ASCII characters will appear in the client_id and also in the client_secr= et? =0A>=0A>Here we have the possibility to define something better. =0A>= =0A>In any case we have to restrict the characters that are used in these t= wo authentication mechanisms since they could conflict with the way how we = transport the data over the underlying protocol. Julian mentioned this in h= is previous mails. =0A>=0A>Julian, maybe you can provide a detailed text pr= oposal for how to address your comment in case we go for UTF8 (with % encod= ing) for the custom OAuth client authentication mechanism? =0A>=0A>Ciao=0A>= Hannes=0A>=0A>On Jun 12, 2012, at 11:54 AM, Julian Reschke wrote:=0A>=0A>> = On 2012-06-12 00:16, Mike Jones wrote:=0A>>> Reviewing the feedback from Ju= lian, John, and James, I'm coming to the conclusion that client_id and clie= nt_secret, being for machines and not humans, should be ASCII, whereas user= name and password should be Unicode, since they are for humans.=C2=A0 Per J= ohn's=0A feedback, client_id can not contain a colon and be compatible with= HTTP Basic.=0A>> =0A>> I'm not sure that restricting the character reperto= ire just because one way to send requires this is the right approach. My pr= eference would be not to put this into the ABNF, and just to point out that= certain characters will not work over certain transports,=0A and to just a= dvise to avoid them.=0A>> =0A>>> Therefore, I'd like to propose these updat= ed ABNF definitions:=0A>>> =0A>>>=C2=A0 =C2=A0 VSCHAR =3D %20-7E=0A>>>=C2= =A0 =C2=A0 NOCOLONVSCHAR =3D %x20-39 / %x3B-7E=0A>>>=C2=A0 =C2=A0 UNICODENO= CTRLCHAR =3D =0A>>> =0A= >>>=C2=A0 =C2=A0 client-id =3D *NOCOLONVSCHAR=0A>>>=C2=A0 =C2=A0 client_sec= ret =3D *VSCHAR=0A>>> =0A>>>=C2=A0 =C2=A0 username =3D *UNICODENOCTRLCHAR= =0A>>>=C2=A0 =C2=A0 password =3D *UNICODENOCTRLCHAR=0A>> =0A>> In this case= you should add an introductory statement pointing out that the ABNF define= s the grammar in terms of Unicode code points, not octets (as it is the cas= e most of the time).=0A>> =0A>>> It turns out that non-ASCII characters are= OK for username and password because the Core spec only passes them in the= form body - not using HTTP Basic - and UTF-8 encoding is specified.=0A>> = =0A>> I'll send a separate mail about that, the current text in the spec is= way too unspecific.=0A>> =0A>>> =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2= =A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 -- Mike=0A>>> =0A>>> P.S.=C2=A0 If anyon= e has a better ABNF for UNICODENOCTRLCHAR than "", please send it to me!=0A>> =0A>> As noted befor= e, here's an example: =0A>> =0A>> Best regards, Julian=0A>> ________________________= _______________________=0A>> OAuth mailing list=0A>> OAuth@ietf.org=0A>> ht= tps://www.ietf.org/mailman/listinfo/oauth=0A>=0A>__________________________= _____________________=0A>OAuth mailing list=0A>OAuth@ietf.org=0A>https://ww= w.ietf.org/mailman/listinfo/oauth=0A>=0A> ---1395015409-1554170055-1339531450=:39923 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I think dynamic client registration is something we have not talked out e= nough yet.  There's a pretty clear use case for dynamic registration.&= nbsp; 

Does identif= ying the client with a URI allow some form of OpenID-ish flow for this?&nbs= p;
Is the client ID as a URI a way to allow a t= rusted site to provide metadata about the client?
Is= that URI a way to hit an IDP we trust to validate the client in some way w= ith the provided secret?

<= span>I guess what I'm looking for here is a concrete use case/problem to so= lve, rather then leaving a hook we think is the right thing.

-bill
=


From: Eran Hammer <eran@hueniverse.com>
To: Mike Jones <Michael.Jones@micr= osoft.com>; William Mills <wmills@yahoo-inc.com>; Hannes Tschofeni= g <hannes.tschofenig@gmx.net>; Julian Reschke <julian.reschke@gmx.= de>
Cc: "oauth@ietf= .org" <oauth@ietf.org>
Sen= t: Tuesday, June 12, 2012 11:39 AM
= Subject: RE: [OAUTH-WG] Discussion needed on username and passwo= rd ABNF definitions

=0A
=0A= =0A =0A =0A=0A=0A
=0A
=0A
Is the use case of using URI as = client ids important? It seems like something that might become useful in t= he future where clients can use their verifiable=0A servers to bypass clien= t registration and simly use a URI the server can validate via some other m= eans.
=0A
 
=0A
I just wa= nt to make sure those thinking about more complex use cases involving dynam= ic registration or distributed client manamgenet are aware of this potentia= l=0A restriction.
=0A
 
=0A
I'm fine either way.
=0A
 
=0A<= div class=3D"yiv141816853MsoNormal">EH
=0A
 
=0A
=0A=0A
=0A
From: oauth-= bounces@ietf.org [mailto:oauth-bounces@ietf.org]=0AOn Behalf Of Mike= Jones
=0ASent: Tuesday, June 12, 2012 11:27 AM
=0ATo: = William Mills; Hannes Tschofenig; Julian Reschke
=0ACc: oauth@iet= f.org
=0ASubject: Re: [OAUTH-WG] Discussion needed on username an= d password ABNF definitions
=0A
=0A
=0A
 
=0A
Not internationalizing f= ields intended for machine consumption only is already a precedent set and = agreed to by the working group, so let me second Bill=E2=80=99s point=0A in= that regard.  For instance, neither =E2=80=9Cscope=E2=80=9D nor =E2= =80=9Cerror=E2=80=9D allow non-ASCII characters.
=0A
=  
=0A
Julian, if you want different ABNF text t= han the text I wrote below, I believe it would be most useful if you would = provide the exact replace wording that you=E2=80=99d=0A like to see instead= of it.  Then there=E2=80=99s no possibility of misunderstanding the i= ntent of suggested changes.
=0A
 
= =0A
          &n= bsp;            = ;            &n= bsp;            = ;            Thanks = all,
=0A
       &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;  -- Mike
=0A
 
=0A
= =0A
=0A
From:=0Aoauth-bounces@ietf.org =0A[mailto:oauth-bounce= s@ietf.org] On Behalf Of William Mills
=0ASent: Tuesda= y, June 12, 2012 11:18 AM
=0ATo: Hannes Tschofenig; Julian Reschk= e
=0ACc: oauth@ietf.org
=0A= Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF= definitions
=0A
=0A
=0A
 
=0A
=0A
=0A
I agree generally with your assumption about clients, but rather than sa= ying "clients are devices" I think it makes much more sense to say "clients= =0A are NOT users, so client_id need not be internationalized".  In pr= actical terms there is very little to argue for anythign beyond ASCII in a = client_secret, base64 encoding or the equivalent being a fine way to transp= ort arbitrary bits in a portable/reasonable=0A way.
=0A
= =0A
=0A
 
=0A=0A
=0A
I argue that client_id nee= d not be internationalized because I assume that any really internationaliz= ed application will have an internationalized=0A presentation layer that's = presenting a pretty name for the client_id.
=0A
=0A
= =0A
 
=0A
=0A=0A
-bill
=0A
=0A=0A
 
=0A
=0A
=0A
=0A
=0A=0A
=0A
=0A
From: Hannes Tschofenig &= lt;hannes.tschofenig@gmx= .net>
=0ATo: Julian Reschke <julian.reschke@gmx.de>=0A
=0ACc: "oauth@ietf.org" <oauth@ietf.org>=0A
=0ASent: Tuesday, June 12, 2012 11:01 = AM
=0ASubject: Re: [OAUTH-WG] Discussion needed on username and p= assword ABNF definitions
= =0A
=0A

=0AI had a chat wit= h Julian yesterday and here is my short summary.
=0A
=0ASection 2.3 = of the core draft defines client authentication based on two mechanisms (an= d provides room for extensions):=0Ahttp://tools.ietf.org/html/draft-ietf-oa= uth-v2-27#section-2.3
=0A
=0A1) HTTP Basic Authentication
=0A
= =0A2) A custom OAuth authentication mechanism (which uses client_id and cli= ent_secret)
=0A
=0AWith HTTP Basic authentication the problem is that= this is a legacy technology and there is no internationalization support.= =0A
=0A
=0AWith our brand new custom OAuth authentication mechanism w= e have more options.
=0A
=0AOne possible approach is to say that the= clients are devices (and not end users) and therefore internationalization= does not matter.=0A
=0A
=0AIs it, however, really true that only US-= ASCII characters will appear in the client_id and also in the client_secret= ?=0A
=0A
=0AHere we have the possibility to define something better. =
=0A
=0AIn any case we have to restrict the characters that are used = in these two authentication mechanisms since they could conflict with the w= ay how we transport the data over the underlying protocol. Julian mentioned= this in his previous mails.=0A
=0A
=0AJulian, maybe you can provide = a detailed text proposal for how to address your comment in case we go for = UTF8 (with % encoding) for the custom OAuth client authentication mechanism= ?=0A
=0A
=0ACiao
=0AHannes
=0A
=0AOn Jun 12, 2012, at 11:54 = AM, Julian Reschke wrote:
=0A
=0A> On 2012-06-12 00:16, Mike Jones= wrote:
=0A>> Reviewing the feedback from Julian, John, and James,= I'm coming to the conclusion that client_id and client_secret, being for m= achines and not humans, should be ASCII, whereas username and password shou= ld be Unicode, since they are for humans.  Per John's=0A feedback, cli= ent_id can not contain a colon and be compatible with HTTP Basic.
=0A>= ;
=0A> I'm not sure that restricting the character repertoire just b= ecause one way to send requires this is the right approach. My preference w= ould be not to put this into the ABNF, and just to point out that certain c= haracters will not work over certain transports,=0A and to just advise to a= void them.
=0A>
=0A>> Therefore, I'd like to propose these = updated ABNF definitions:
=0A>>
=0A>>    VSCHA= R =3D %20-7E
=0A>>    NOCOLONVSCHAR =3D %x20-39 / %x3B-7= E
=0A>>    UNICODENOCTRLCHAR =3D <Any Unicode charact= er other than ( %x0-1F / %x7F )>
=0A>>
=0A>>  &n= bsp; client-id =3D *NOCOLONVSCHAR
=0A>>    client_secret= =3D *VSCHAR
=0A>>
=0A>>    username =3D *UNIC= ODENOCTRLCHAR
=0A>>    password =3D *UNICODENOCTRLCHAR=0A>
=0A> In this case you should add an introductory statement= pointing out that the ABNF defines the grammar in terms of Unicode code po= ints, not octets (as it is the case most of the time).
=0A>
=0A&g= t;> It turns out that non-ASCII characters are OK for username and passw= ord because the Core spec only passes them in the form body - not using HTT= P Basic - and UTF-8 encoding is specified.
=0A>
=0A> I'll send= a separate mail about that, the current text in the spec is way too unspec= ific.
=0A>
=0A>>         &nbs= p;       -- Mike
=0A>>
=0A>> P.= S.  If anyone has a better ABNF for UNICODENOCTRLCHAR than "<Any Un= icode character other than ( %x0-1F / %x7F )>", please send it to me!=0A>
=0A> As noted before, here's an example: <http://greenbytes.de/tech/webdav/rfc5323.html#rfc.se= ction.5.15.1>
=0A>
=0A> Best regards, Julian
=0A>= _______________________________________________
=0A> OAuth mailing l= ist
=0A> OAuth@ietf.org
=0A> https://www.ietf.org/mailman/listinfo/oauth
=0A
=0A= _______________________________________________
=0AOAuth mailing list=0AOAuth@ietf.org
=0Aht= tps://www.ietf.org/mailman/listinfo/oauth
=0A
=0A=0A
=0A
=0A
=0A
=0A
=0A=0A


=
---1395015409-1554170055-1339531450=:39923-- From eran@hueniverse.com Tue Jun 12 13:08:33 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59F3821F854F for ; Tue, 12 Jun 2012 13:08:33 -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 4j-42cU2hleK for ; Tue, 12 Jun 2012 13:08:31 -0700 (PDT) Received: from p3plex2out01.prod.phx3.secureserver.net (p3plex2out01.prod.phx3.secureserver.net [184.168.131.12]) by ietfa.amsl.com (Postfix) with ESMTP id 6AC6521F8543 for ; Tue, 12 Jun 2012 13:08:31 -0700 (PDT) Received: from P3PWEX2HT001.ex2.secureserver.net ([184.168.131.9]) by p3plex2out01.prod.phx3.secureserver.net with bizsmtp id MY8W1j0060CJzpC01Y8Whe; Tue, 12 Jun 2012 13:08:30 -0700 Received: from P3PWEX2MB008.ex2.secureserver.net ([169.254.8.66]) by P3PWEX2HT001.ex2.secureserver.net ([184.168.131.9]) with mapi id 14.02.0247.003; Tue, 12 Jun 2012 13:08:30 -0700 From: Eran Hammer To: William Mills , Mike Jones , Hannes Tschofenig , Julian Reschke Thread-Topic: Dynamic clients, URI, and stuff Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions Thread-Index: AQHNSNaJiQdx2TtY6EmdutHMaGibFZb3HAYg Date: Tue, 12 Jun 2012 20:08:29 +0000 Message-ID: <0CBAEB56DDB3A140BA8E8C124C04ECA20106F052@P3PWEX2MB008.ex2.secureserver.net> References: <4E1F6AAD24975D4BA5B16804296739436652F52D@TK5EX14MBXC284.redmond.corp.microsoft.com> <4FD4E9D4.2010808@gmx.de> <4E1F6AAD24975D4BA5B168042967394366531375@TK5EX14MBXC284.redmond.corp.microsoft.com> <4FD4F976.6090801@gmx.de> <4E1F6AAD24975D4BA5B1680429673943665316D1@TK5EX14MBXC284.redmond.corp.microsoft.com> <60F5CCB0-E036-4351-BD10-A44B33FCC5F6@ve7jtb.com> <255B9BB34FB7D647A506DC292726F6E114F5474E29@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B1680429673943665346D0@TK5EX14MBXC284.redmond.corp.microsoft.com> <4FD703C4.6050801@gmx.de> <5E38109E-2123-418B-8D45-B8DF4287790D@gmx.net> <1339525052.8121.YahooMailNeo@web31807.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B168042967394366535EAD@TK5EX14MBXC284.redmond.corp.microsoft.com> <0CBAEB56DDB3A140BA8E8C124C04ECA20106ED1F@P3PWEX2MB008.ex2.secureserver.net> <1339531450.39923.YahooMailNeo@web31809.mail.mud.yahoo.com> In-Reply-To: <1339531450.39923.YahooMailNeo@web31809.mail.mud.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [37.46.32.109] Content-Type: multipart/alternative; boundary="_000_0CBAEB56DDB3A140BA8E8C124C04ECA20106F052P3PWEX2MB008ex2_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion needed on username and password ABNF definitions X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 20:08:33 -0000 --_000_0CBAEB56DDB3A140BA8E8C124C04ECA20106F052P3PWEX2MB008ex2_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIG9ubHkgZGlzdGluY3Rpb24gSSB3b3VsZCBtYWtlIGlzIGJldHdlZW4gcmVtb3ZpbmcgZmxl eGliaWxpeSB0byBwcm9hY3RpdmVseSBlbmFibGluZyBmdXR1cmUgZXh0ZW5zaWJpbGl0eS4gSSB3 b3VsZCBzdG9wIHNob3J0IG9mIHBlcnNjcmliaW5nIGVuY29kaW5nIGluIG9yZGVyIHRvIGZpdCB1 cmkgaW50byB0aGUgQmFzaWMgYXV0aCBmaWVsZHMuIEJ1dCBpZiB0aGVyZSBpcyBhIHdheSB0byBh bGxvdyB0aGlzIHRvIGJlIGxlc3MgcmVzdHJpY3RpdmUgd2l0aG91dCBjbGVhbiBpbnRlcm9wIGlz c3VlcywgdGhhdCB3b3VsZCBiZSBuaWNlLg0KDQpJIGRvIGFncmVlIHdlIG5lZWQgc29tZSBhY3R1 YWwgdXNlIGNhc2VzIGJlZm9yZSB3ZSBzcGVuZCBtdWNoIG1vcmUgdGltZSBvbiB0aGlzLg0KDQpF SA0KDQpGcm9tOiBXaWxsaWFtIE1pbGxzIFttYWlsdG86d21pbGxzQHlhaG9vLWluYy5jb21dDQpT ZW50OiBUdWVzZGF5LCBKdW5lIDEyLCAyMDEyIDE6MDQgUE0NClRvOiBFcmFuIEhhbW1lcjsgTWlr ZSBKb25lczsgSGFubmVzIFRzY2hvZmVuaWc7IEp1bGlhbiBSZXNjaGtlDQpDYzogb2F1dGhAaWV0 Zi5vcmcNClN1YmplY3Q6IER5bmFtaWMgY2xpZW50cywgVVJJLCBhbmQgc3R1ZmYgUmU6IFtPQVVU SC1XR10gRGlzY3Vzc2lvbiBuZWVkZWQgb24gdXNlcm5hbWUgYW5kIHBhc3N3b3JkIEFCTkYgZGVm aW5pdGlvbnMNCg0KSSB0aGluayBkeW5hbWljIGNsaWVudCByZWdpc3RyYXRpb24gaXMgc29tZXRo aW5nIHdlIGhhdmUgbm90IHRhbGtlZCBvdXQgZW5vdWdoIHlldC4gIFRoZXJlJ3MgYSBwcmV0dHkg Y2xlYXIgdXNlIGNhc2UgZm9yIGR5bmFtaWMgcmVnaXN0cmF0aW9uLg0KDQpEb2VzIGlkZW50aWZ5 aW5nIHRoZSBjbGllbnQgd2l0aCBhIFVSSSBhbGxvdyBzb21lIGZvcm0gb2YgT3BlbklELWlzaCBm bG93IGZvciB0aGlzPw0KSXMgdGhlIGNsaWVudCBJRCBhcyBhIFVSSSBhIHdheSB0byBhbGxvdyBh IHRydXN0ZWQgc2l0ZSB0byBwcm92aWRlIG1ldGFkYXRhIGFib3V0IHRoZSBjbGllbnQ/DQpJcyB0 aGF0IFVSSSBhIHdheSB0byBoaXQgYW4gSURQIHdlIHRydXN0IHRvIHZhbGlkYXRlIHRoZSBjbGll bnQgaW4gc29tZSB3YXkgd2l0aCB0aGUgcHJvdmlkZWQgc2VjcmV0Pw0KDQpJIGd1ZXNzIHdoYXQg SSdtIGxvb2tpbmcgZm9yIGhlcmUgaXMgYSBjb25jcmV0ZSB1c2UgY2FzZS9wcm9ibGVtIHRvIHNv bHZlLCByYXRoZXIgdGhlbiBsZWF2aW5nIGEgaG9vayB3ZSB0aGluayBpcyB0aGUgcmlnaHQgdGhp bmcuDQoNCi1iaWxsDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206 IEVyYW4gSGFtbWVyIDxlcmFuQGh1ZW5pdmVyc2UuY29tPG1haWx0bzplcmFuQGh1ZW5pdmVyc2Uu Y29tPj4NClRvOiBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208bWFpbHRv Ok1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4+OyBXaWxsaWFtIE1pbGxzIDx3bWlsbHNAeWFo b28taW5jLmNvbTxtYWlsdG86d21pbGxzQHlhaG9vLWluYy5jb20+PjsgSGFubmVzIFRzY2hvZmVu aWcgPGhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQ8bWFpbHRvOmhhbm5lcy50c2Nob2ZlbmlnQGdt eC5uZXQ+PjsgSnVsaWFuIFJlc2Noa2UgPGp1bGlhbi5yZXNjaGtlQGdteC5kZTxtYWlsdG86anVs aWFuLnJlc2Noa2VAZ214LmRlPj4NCkNjOiAib2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGll dGYub3JnPiIgPG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4+DQpTZW50OiBU dWVzZGF5LCBKdW5lIDEyLCAyMDEyIDExOjM5IEFNDQpTdWJqZWN0OiBSRTogW09BVVRILVdHXSBE aXNjdXNzaW9uIG5lZWRlZCBvbiB1c2VybmFtZSBhbmQgcGFzc3dvcmQgQUJORiBkZWZpbml0aW9u cw0KDQpJcyB0aGUgdXNlIGNhc2Ugb2YgdXNpbmcgVVJJIGFzIGNsaWVudCBpZHMgaW1wb3J0YW50 PyBJdCBzZWVtcyBsaWtlIHNvbWV0aGluZyB0aGF0IG1pZ2h0IGJlY29tZSB1c2VmdWwgaW4gdGhl IGZ1dHVyZSB3aGVyZSBjbGllbnRzIGNhbiB1c2UgdGhlaXIgdmVyaWZpYWJsZSBzZXJ2ZXJzIHRv IGJ5cGFzcyBjbGllbnQgcmVnaXN0cmF0aW9uIGFuZCBzaW1seSB1c2UgYSBVUkkgdGhlIHNlcnZl ciBjYW4gdmFsaWRhdGUgdmlhIHNvbWUgb3RoZXIgbWVhbnMuDQoNCkkganVzdCB3YW50IHRvIG1h a2Ugc3VyZSB0aG9zZSB0aGlua2luZyBhYm91dCBtb3JlIGNvbXBsZXggdXNlIGNhc2VzIGludm9s dmluZyBkeW5hbWljIHJlZ2lzdHJhdGlvbiBvciBkaXN0cmlidXRlZCBjbGllbnQgbWFuYW1nZW5l dCBhcmUgYXdhcmUgb2YgdGhpcyBwb3RlbnRpYWwgcmVzdHJpY3Rpb24uDQoNCkknbSBmaW5lIGVp dGhlciB3YXkuDQoNCkVIDQoNCkZyb206IG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm9h dXRoLWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ108bWFp bHRvOlttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10+IE9uIEJlaGFsZiBPZiBNaWtlIEpv bmVzDQpTZW50OiBUdWVzZGF5LCBKdW5lIDEyLCAyMDEyIDExOjI3IEFNDQpUbzogV2lsbGlhbSBN aWxsczsgSGFubmVzIFRzY2hvZmVuaWc7IEp1bGlhbiBSZXNjaGtlDQpDYzogb2F1dGhAaWV0Zi5v cmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gRGlzY3Vz c2lvbiBuZWVkZWQgb24gdXNlcm5hbWUgYW5kIHBhc3N3b3JkIEFCTkYgZGVmaW5pdGlvbnMNCg0K Tm90IGludGVybmF0aW9uYWxpemluZyBmaWVsZHMgaW50ZW5kZWQgZm9yIG1hY2hpbmUgY29uc3Vt cHRpb24gb25seSBpcyBhbHJlYWR5IGEgcHJlY2VkZW50IHNldCBhbmQgYWdyZWVkIHRvIGJ5IHRo ZSB3b3JraW5nIGdyb3VwLCBzbyBsZXQgbWUgc2Vjb25kIEJpbGzigJlzIHBvaW50IGluIHRoYXQg cmVnYXJkLiAgRm9yIGluc3RhbmNlLCBuZWl0aGVyIOKAnHNjb3Bl4oCdIG5vciDigJxlcnJvcuKA nSBhbGxvdyBub24tQVNDSUkgY2hhcmFjdGVycy4NCg0KSnVsaWFuLCBpZiB5b3Ugd2FudCBkaWZm ZXJlbnQgQUJORiB0ZXh0IHRoYW4gdGhlIHRleHQgSSB3cm90ZSBiZWxvdywgSSBiZWxpZXZlIGl0 IHdvdWxkIGJlIG1vc3QgdXNlZnVsIGlmIHlvdSB3b3VsZCBwcm92aWRlIHRoZSBleGFjdCByZXBs YWNlIHdvcmRpbmcgdGhhdCB5b3XigJlkIGxpa2UgdG8gc2VlIGluc3RlYWQgb2YgaXQuICBUaGVu IHRoZXJl4oCZcyBubyBwb3NzaWJpbGl0eSBvZiBtaXN1bmRlcnN0YW5kaW5nIHRoZSBpbnRlbnQg b2Ygc3VnZ2VzdGVkIGNoYW5nZXMuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFRoYW5rcyBhbGwsDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCkZy b206IG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc+ IFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ108bWFpbHRvOlttYWlsdG86b2F1dGgtYm91 bmNlc0BpZXRmLm9yZ10+IE9uIEJlaGFsZiBPZiBXaWxsaWFtIE1pbGxzDQpTZW50OiBUdWVzZGF5 LCBKdW5lIDEyLCAyMDEyIDExOjE4IEFNDQpUbzogSGFubmVzIFRzY2hvZmVuaWc7IEp1bGlhbiBS ZXNjaGtlDQpDYzogb2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPg0KU3ViamVj dDogUmU6IFtPQVVUSC1XR10gRGlzY3Vzc2lvbiBuZWVkZWQgb24gdXNlcm5hbWUgYW5kIHBhc3N3 b3JkIEFCTkYgZGVmaW5pdGlvbnMNCg0KSSBhZ3JlZSBnZW5lcmFsbHkgd2l0aCB5b3VyIGFzc3Vt cHRpb24gYWJvdXQgY2xpZW50cywgYnV0IHJhdGhlciB0aGFuIHNheWluZyAiY2xpZW50cyBhcmUg ZGV2aWNlcyIgSSB0aGluayBpdCBtYWtlcyBtdWNoIG1vcmUgc2Vuc2UgdG8gc2F5ICJjbGllbnRz IGFyZSBOT1QgdXNlcnMsIHNvIGNsaWVudF9pZCBuZWVkIG5vdCBiZSBpbnRlcm5hdGlvbmFsaXpl ZCIuICBJbiBwcmFjdGljYWwgdGVybXMgdGhlcmUgaXMgdmVyeSBsaXR0bGUgdG8gYXJndWUgZm9y IGFueXRoaWduIGJleW9uZCBBU0NJSSBpbiBhIGNsaWVudF9zZWNyZXQsIGJhc2U2NCBlbmNvZGlu ZyBvciB0aGUgZXF1aXZhbGVudCBiZWluZyBhIGZpbmUgd2F5IHRvIHRyYW5zcG9ydCBhcmJpdHJh cnkgYml0cyBpbiBhIHBvcnRhYmxlL3JlYXNvbmFibGUgd2F5Lg0KDQpJIGFyZ3VlIHRoYXQgY2xp ZW50X2lkIG5lZWQgbm90IGJlIGludGVybmF0aW9uYWxpemVkIGJlY2F1c2UgSSBhc3N1bWUgdGhh dCBhbnkgcmVhbGx5IGludGVybmF0aW9uYWxpemVkIGFwcGxpY2F0aW9uIHdpbGwgaGF2ZSBhbiBp bnRlcm5hdGlvbmFsaXplZCBwcmVzZW50YXRpb24gbGF5ZXIgdGhhdCdzIHByZXNlbnRpbmcgYSBw cmV0dHkgbmFtZSBmb3IgdGhlIGNsaWVudF9pZC4NCg0KLWJpbGwNCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCkZyb206IEhhbm5lcyBUc2Nob2ZlbmlnIDxoYW5uZXMudHNjaG9m ZW5pZ0BnbXgubmV0PG1haWx0bzpoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0Pj4NClRvOiBKdWxp YW4gUmVzY2hrZSA8anVsaWFuLnJlc2Noa2VAZ214LmRlPG1haWx0bzpqdWxpYW4ucmVzY2hrZUBn bXguZGU+Pg0KQ2M6ICJvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+IiA8b2F1 dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPj4NClNlbnQ6IFR1ZXNkYXksIEp1bmUg MTIsIDIwMTIgMTE6MDEgQU0NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIERpc2N1c3Npb24gbmVl ZGVkIG9uIHVzZXJuYW1lIGFuZCBwYXNzd29yZCBBQk5GIGRlZmluaXRpb25zDQoNCkkgaGFkIGEg Y2hhdCB3aXRoIEp1bGlhbiB5ZXN0ZXJkYXkgYW5kIGhlcmUgaXMgbXkgc2hvcnQgc3VtbWFyeS4N Cg0KU2VjdGlvbiAyLjMgb2YgdGhlIGNvcmUgZHJhZnQgZGVmaW5lcyBjbGllbnQgYXV0aGVudGlj YXRpb24gYmFzZWQgb24gdHdvIG1lY2hhbmlzbXMgKGFuZCBwcm92aWRlcyByb29tIGZvciBleHRl bnNpb25zKTogaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC12Mi0y NyNzZWN0aW9uLTIuMw0KDQoxKSBIVFRQIEJhc2ljIEF1dGhlbnRpY2F0aW9uDQoNCjIpIEEgY3Vz dG9tIE9BdXRoIGF1dGhlbnRpY2F0aW9uIG1lY2hhbmlzbSAod2hpY2ggdXNlcyBjbGllbnRfaWQg YW5kIGNsaWVudF9zZWNyZXQpDQoNCldpdGggSFRUUCBCYXNpYyBhdXRoZW50aWNhdGlvbiB0aGUg cHJvYmxlbSBpcyB0aGF0IHRoaXMgaXMgYSBsZWdhY3kgdGVjaG5vbG9neSBhbmQgdGhlcmUgaXMg bm8gaW50ZXJuYXRpb25hbGl6YXRpb24gc3VwcG9ydC4NCg0KV2l0aCBvdXIgYnJhbmQgbmV3IGN1 c3RvbSBPQXV0aCBhdXRoZW50aWNhdGlvbiBtZWNoYW5pc20gd2UgaGF2ZSBtb3JlIG9wdGlvbnMu DQoNCk9uZSBwb3NzaWJsZSBhcHByb2FjaCBpcyB0byBzYXkgdGhhdCB0aGUgY2xpZW50cyBhcmUg ZGV2aWNlcyAoYW5kIG5vdCBlbmQgdXNlcnMpIGFuZCB0aGVyZWZvcmUgaW50ZXJuYXRpb25hbGl6 YXRpb24gZG9lcyBub3QgbWF0dGVyLg0KDQpJcyBpdCwgaG93ZXZlciwgcmVhbGx5IHRydWUgdGhh dCBvbmx5IFVTLUFTQ0lJIGNoYXJhY3RlcnMgd2lsbCBhcHBlYXIgaW4gdGhlIGNsaWVudF9pZCBh bmQgYWxzbyBpbiB0aGUgY2xpZW50X3NlY3JldD8NCg0KSGVyZSB3ZSBoYXZlIHRoZSBwb3NzaWJp bGl0eSB0byBkZWZpbmUgc29tZXRoaW5nIGJldHRlci4NCg0KSW4gYW55IGNhc2Ugd2UgaGF2ZSB0 byByZXN0cmljdCB0aGUgY2hhcmFjdGVycyB0aGF0IGFyZSB1c2VkIGluIHRoZXNlIHR3byBhdXRo ZW50aWNhdGlvbiBtZWNoYW5pc21zIHNpbmNlIHRoZXkgY291bGQgY29uZmxpY3Qgd2l0aCB0aGUg d2F5IGhvdyB3ZSB0cmFuc3BvcnQgdGhlIGRhdGEgb3ZlciB0aGUgdW5kZXJseWluZyBwcm90b2Nv bC4gSnVsaWFuIG1lbnRpb25lZCB0aGlzIGluIGhpcyBwcmV2aW91cyBtYWlscy4NCg0KSnVsaWFu LCBtYXliZSB5b3UgY2FuIHByb3ZpZGUgYSBkZXRhaWxlZCB0ZXh0IHByb3Bvc2FsIGZvciBob3cg dG8gYWRkcmVzcyB5b3VyIGNvbW1lbnQgaW4gY2FzZSB3ZSBnbyBmb3IgVVRGOCAod2l0aCAlIGVu Y29kaW5nKSBmb3IgdGhlIGN1c3RvbSBPQXV0aCBjbGllbnQgYXV0aGVudGljYXRpb24gbWVjaGFu aXNtPw0KDQpDaWFvDQpIYW5uZXMNCg0KT24gSnVuIDEyLCAyMDEyLCBhdCAxMTo1NCBBTSwgSnVs aWFuIFJlc2Noa2Ugd3JvdGU6DQoNCj4gT24gMjAxMi0wNi0xMiAwMDoxNiwgTWlrZSBKb25lcyB3 cm90ZToNCj4+IFJldmlld2luZyB0aGUgZmVlZGJhY2sgZnJvbSBKdWxpYW4sIEpvaG4sIGFuZCBK YW1lcywgSSdtIGNvbWluZyB0byB0aGUgY29uY2x1c2lvbiB0aGF0IGNsaWVudF9pZCBhbmQgY2xp ZW50X3NlY3JldCwgYmVpbmcgZm9yIG1hY2hpbmVzIGFuZCBub3QgaHVtYW5zLCBzaG91bGQgYmUg QVNDSUksIHdoZXJlYXMgdXNlcm5hbWUgYW5kIHBhc3N3b3JkIHNob3VsZCBiZSBVbmljb2RlLCBz aW5jZSB0aGV5IGFyZSBmb3IgaHVtYW5zLiAgUGVyIEpvaG4ncyBmZWVkYmFjaywgY2xpZW50X2lk IGNhbiBub3QgY29udGFpbiBhIGNvbG9uIGFuZCBiZSBjb21wYXRpYmxlIHdpdGggSFRUUCBCYXNp Yy4NCj4NCj4gSSdtIG5vdCBzdXJlIHRoYXQgcmVzdHJpY3RpbmcgdGhlIGNoYXJhY3RlciByZXBl cnRvaXJlIGp1c3QgYmVjYXVzZSBvbmUgd2F5IHRvIHNlbmQgcmVxdWlyZXMgdGhpcyBpcyB0aGUg cmlnaHQgYXBwcm9hY2guIE15IHByZWZlcmVuY2Ugd291bGQgYmUgbm90IHRvIHB1dCB0aGlzIGlu dG8gdGhlIEFCTkYsIGFuZCBqdXN0IHRvIHBvaW50IG91dCB0aGF0IGNlcnRhaW4gY2hhcmFjdGVy cyB3aWxsIG5vdCB3b3JrIG92ZXIgY2VydGFpbiB0cmFuc3BvcnRzLCBhbmQgdG8ganVzdCBhZHZp c2UgdG8gYXZvaWQgdGhlbS4NCj4NCj4+IFRoZXJlZm9yZSwgSSdkIGxpa2UgdG8gcHJvcG9zZSB0 aGVzZSB1cGRhdGVkIEFCTkYgZGVmaW5pdGlvbnM6DQo+Pg0KPj4gICAgVlNDSEFSID0gJTIwLTdF DQo+PiAgICBOT0NPTE9OVlNDSEFSID0gJXgyMC0zOSAvICV4M0ItN0UNCj4+ICAgIFVOSUNPREVO T0NUUkxDSEFSID0gPEFueSBVbmljb2RlIGNoYXJhY3RlciBvdGhlciB0aGFuICggJXgwLTFGIC8g JXg3RiApPg0KPj4NCj4+ICAgIGNsaWVudC1pZCA9ICpOT0NPTE9OVlNDSEFSDQo+PiAgICBjbGll bnRfc2VjcmV0ID0gKlZTQ0hBUg0KPj4NCj4+ICAgIHVzZXJuYW1lID0gKlVOSUNPREVOT0NUUkxD SEFSDQo+PiAgICBwYXNzd29yZCA9ICpVTklDT0RFTk9DVFJMQ0hBUg0KPg0KPiBJbiB0aGlzIGNh c2UgeW91IHNob3VsZCBhZGQgYW4gaW50cm9kdWN0b3J5IHN0YXRlbWVudCBwb2ludGluZyBvdXQg dGhhdCB0aGUgQUJORiBkZWZpbmVzIHRoZSBncmFtbWFyIGluIHRlcm1zIG9mIFVuaWNvZGUgY29k ZSBwb2ludHMsIG5vdCBvY3RldHMgKGFzIGl0IGlzIHRoZSBjYXNlIG1vc3Qgb2YgdGhlIHRpbWUp Lg0KPg0KPj4gSXQgdHVybnMgb3V0IHRoYXQgbm9uLUFTQ0lJIGNoYXJhY3RlcnMgYXJlIE9LIGZv ciB1c2VybmFtZSBhbmQgcGFzc3dvcmQgYmVjYXVzZSB0aGUgQ29yZSBzcGVjIG9ubHkgcGFzc2Vz IHRoZW0gaW4gdGhlIGZvcm0gYm9keSAtIG5vdCB1c2luZyBIVFRQIEJhc2ljIC0gYW5kIFVURi04 IGVuY29kaW5nIGlzIHNwZWNpZmllZC4NCj4NCj4gSSdsbCBzZW5kIGEgc2VwYXJhdGUgbWFpbCBh Ym91dCB0aGF0LCB0aGUgY3VycmVudCB0ZXh0IGluIHRoZSBzcGVjIGlzIHdheSB0b28gdW5zcGVj aWZpYy4NCj4NCj4+ICAgICAgICAgICAgICAgICAtLSBNaWtlDQo+Pg0KPj4gUC5TLiAgSWYgYW55 b25lIGhhcyBhIGJldHRlciBBQk5GIGZvciBVTklDT0RFTk9DVFJMQ0hBUiB0aGFuICI8QW55IFVu aWNvZGUgY2hhcmFjdGVyIG90aGVyIHRoYW4gKCAleDAtMUYgLyAleDdGICk+IiwgcGxlYXNlIHNl bmQgaXQgdG8gbWUhDQo+DQo+IEFzIG5vdGVkIGJlZm9yZSwgaGVyZSdzIGFuIGV4YW1wbGU6IDxo dHRwOi8vZ3JlZW5ieXRlcy5kZS90ZWNoL3dlYmRhdi9yZmM1MzIzLmh0bWwjcmZjLnNlY3Rpb24u NS4xNS4xPg0KPg0KPiBCZXN0IHJlZ2FyZHMsIEp1bGlhbg0KPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4gT0F1 dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KPiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1h aWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vb2F1dGgNCg0K --_000_0CBAEB56DDB3A140BA8E8C124C04ECA20106F052P3PWEX2MB008ex2_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQg MyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Iiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvQWNl dGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpwLnlpdjE0MTgxNjg1M21zb2FjZXRhdGUsIGxpLnlp djE0MTgxNjg1M21zb2FjZXRhdGUsIGRpdi55aXYxNDE4MTY4NTNtc29hY2V0YXRlDQoJe21zby1z dHlsZS1uYW1lOnlpdjE0MTgxNjg1M21zb2FjZXRhdGU7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCglt YXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIiwic2VyaWYiO30NCnAueWl2MTQxODE2ODUzbXNvbm9ybWFsLCBsaS55aXYxNDE4 MTY4NTNtc29ub3JtYWwsIGRpdi55aXYxNDE4MTY4NTNtc29ub3JtYWwNCgl7bXNvLXN0eWxlLW5h bWU6eWl2MTQxODE2ODUzbXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1h cmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxl ZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21h biIsInNlcmlmIjt9DQpwLnlpdjE0MTgxNjg1M21zb2NocGRlZmF1bHQsIGxpLnlpdjE0MTgxNjg1 M21zb2NocGRlZmF1bHQsIGRpdi55aXYxNDE4MTY4NTNtc29jaHBkZWZhdWx0DQoJe21zby1zdHls ZS1uYW1lOnlpdjE0MTgxNjg1M21zb2NocGRlZmF1bHQ7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCglt YXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4ueWl2MTQxODE2ODUzbXNvaHlwZXJsaW5rDQoJe21z by1zdHlsZS1uYW1lOnlpdjE0MTgxNjg1M21zb2h5cGVybGluazt9DQpzcGFuLnlpdjE0MTgxNjg1 M21zb2h5cGVybGlua2ZvbGxvd2VkDQoJe21zby1zdHlsZS1uYW1lOnlpdjE0MTgxNjg1M21zb2h5 cGVybGlua2ZvbGxvd2VkO30NCnNwYW4ueWl2MTQxODE2ODUzYmFsbG9vbnRleHRjaGFyDQoJe21z by1zdHlsZS1uYW1lOnlpdjE0MTgxNjg1M2JhbGxvb250ZXh0Y2hhcjt9DQpzcGFuLnlpdjE0MTgx Njg1M2VtYWlsc3R5bGUxOQ0KCXttc28tc3R5bGUtbmFtZTp5aXYxNDE4MTY4NTNlbWFpbHN0eWxl MTk7fQ0Kc3Bhbi55aXYxNDE4MTY4NTNlbWFpbHN0eWxlMjANCgl7bXNvLXN0eWxlLW5hbWU6eWl2 MTQxODE2ODUzZW1haWxzdHlsZTIwO30NCnAueWl2MTQxODE2ODUzbXNvbm9ybWFsMSwgbGkueWl2 MTQxODE2ODUzbXNvbm9ybWFsMSwgZGl2LnlpdjE0MTgxNjg1M21zb25vcm1hbDENCgl7bXNvLXN0 eWxlLW5hbWU6eWl2MTQxODE2ODUzbXNvbm9ybWFsMTsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi55aXYxNDE4MTY4NTNtc29oeXBlcmxpbmsxDQoJe21z by1zdHlsZS1uYW1lOnlpdjE0MTgxNjg1M21zb2h5cGVybGluazE7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4ueWl2MTQxODE2ODUzbXNvaHlwZXJsaW5r Zm9sbG93ZWQxDQoJe21zby1zdHlsZS1uYW1lOnlpdjE0MTgxNjg1M21zb2h5cGVybGlua2ZvbGxv d2VkMTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLnlp djE0MTgxNjg1M21zb2FjZXRhdGUxLCBsaS55aXYxNDE4MTY4NTNtc29hY2V0YXRlMSwgZGl2Lnlp djE0MTgxNjg1M21zb2FjZXRhdGUxDQoJe21zby1zdHlsZS1uYW1lOnlpdjE0MTgxNjg1M21zb2Fj ZXRhdGUxOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZTo4LjBwdDsNCglmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLnlpdjE0 MTgxNjg1M2JhbGxvb250ZXh0Y2hhcjENCgl7bXNvLXN0eWxlLW5hbWU6eWl2MTQxODE2ODUzYmFs bG9vbnRleHRjaGFyMTsNCglmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjt9DQpzcGFu LnlpdjE0MTgxNjg1M2VtYWlsc3R5bGUxOTENCgl7bXNvLXN0eWxlLW5hbWU6eWl2MTQxODE2ODUz ZW1haWxzdHlsZTE5MTsNCglmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjsNCgljb2xv cjojMUY0OTdEO30NCnNwYW4ueWl2MTQxODE2ODUzZW1haWxzdHlsZTIwMQ0KCXttc28tc3R5bGUt bmFtZTp5aXYxNDE4MTY4NTNlbWFpbHN0eWxlMjAxOw0KCWZvbnQtZmFtaWx5OiJBcmlhbCIsInNh bnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KcC55aXYxNDE4MTY4NTNtc29jaHBkZWZhdWx0 MSwgbGkueWl2MTQxODE2ODUzbXNvY2hwZGVmYXVsdDEsIGRpdi55aXYxNDE4MTY4NTNtc29jaHBk ZWZhdWx0MQ0KCXttc28tc3R5bGUtbmFtZTp5aXYxNDE4MTY4NTNtc29jaHBkZWZhdWx0MTsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxl MzMNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uQmFsbG9vblRleHRDaGFy DQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJU YWhvbWEiLCJzYW5zLXNlcmlmIjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz aXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0i MTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEi IC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBs YW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3Jk U2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSBvbmx5IGRpc3RpbmN0aW9uIEkgd291bGQgbWFrZSBpcyBi ZXR3ZWVuIHJlbW92aW5nIGZsZXhpYmlsaXkgdG8gcHJvYWN0aXZlbHkgZW5hYmxpbmcgZnV0dXJl IGV4dGVuc2liaWxpdHkuIEkgd291bGQgc3RvcCBzaG9ydCBvZiBwZXJzY3JpYmluZyBlbmNvZGlu ZyBpbg0KIG9yZGVyIHRvIGZpdCB1cmkgaW50byB0aGUgQmFzaWMgYXV0aCBmaWVsZHMuIEJ1dCBp ZiB0aGVyZSBpcyBhIHdheSB0byBhbGxvdyB0aGlzIHRvIGJlIGxlc3MgcmVzdHJpY3RpdmUgd2l0 aG91dCBjbGVhbiBpbnRlcm9wIGlzc3VlcywgdGhhdCB3b3VsZCBiZSBuaWNlLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ SSBkbyBhZ3JlZSB3ZSBuZWVkIHNvbWUgYWN0dWFsIHVzZSBjYXNlcyBiZWZvcmUgd2Ugc3BlbmQg bXVjaCBtb3JlIHRpbWUgb24gdGhpcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkVIPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0 LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj QjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFdpbGxpYW0gTWlsbHMgW21haWx0bzp3bWlsbHNAeWFo b28taW5jLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBKdW5lIDEyLCAyMDEyIDE6 MDQgUE08YnI+DQo8Yj5Ubzo8L2I+IEVyYW4gSGFtbWVyOyBNaWtlIEpvbmVzOyBIYW5uZXMgVHNj aG9mZW5pZzsgSnVsaWFuIFJlc2Noa2U8YnI+DQo8Yj5DYzo8L2I+IG9hdXRoQGlldGYub3JnPGJy Pg0KPGI+U3ViamVjdDo8L2I+IER5bmFtaWMgY2xpZW50cywgVVJJLCBhbmQgc3R1ZmYgUmU6IFtP QVVUSC1XR10gRGlzY3Vzc2lvbiBuZWVkZWQgb24gdXNlcm5hbWUgYW5kIHBhc3N3b3JkIEFCTkYg ZGVmaW5pdGlvbnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjE0LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpi bGFjayI+SSB0aGluayBkeW5hbWljIGNsaWVudCByZWdpc3RyYXRpb24gaXMgc29tZXRoaW5nIHdl IGhhdmUgbm90IHRhbGtlZCBvdXQgZW5vdWdoIHlldC4mbmJzcDsgVGhlcmUncyBhIHByZXR0eSBj bGVhciB1c2UgY2FzZSBmb3IgZHluYW1pYyByZWdpc3RyYXRpb24uJm5ic3A7Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTQuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPkRvZXMgaWRlbnRpZnlp bmcgdGhlIGNsaWVudCB3aXRoIGEgVVJJIGFsbG93IHNvbWUgZm9ybSBvZiBPcGVuSUQtaXNoIGZs b3cgZm9yIHRoaXM/Jm5ic3A7DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxNC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 Y29sb3I6YmxhY2siPklzIHRoZSBjbGllbnQgSUQgYXMgYSBVUkkgYSB3YXkgdG8gYWxsb3cgYSB0 cnVzdGVkIHNpdGUgdG8gcHJvdmlkZSBtZXRhZGF0YSBhYm91dCB0aGUgY2xpZW50PzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+SXMgdGhhdCBVUkkgYSB3 YXkgdG8gaGl0IGFuIElEUCB3ZSB0cnVzdCB0byB2YWxpZGF0ZSB0aGUgY2xpZW50IGluIHNvbWUg d2F5IHdpdGggdGhlIHByb3ZpZGVkIHNlY3JldD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjpibGFjayI+SSBndWVzcyB3aGF0IEknbSBsb29raW5nIGZvciBoZXJlIGlz IGEgY29uY3JldGUgdXNlIGNhc2UvcHJvYmxlbSB0byBzb2x2ZSwgcmF0aGVyIHRoZW4gbGVhdmlu ZyBhIGhvb2sgd2UgdGhpbmsgaXMgdGhlIHJpZ2h0IHRoaW5nLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5k OndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTQuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4tYmlsbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndo aXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICMxMDEwRkYgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdDttYXJnaW4tbGVm dDozLjc1cHQ7bWFyZ2luLXRvcDozLjc1cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxNC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Ymxh Y2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2Vu dGVyO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+DQo8aHIgc2l6ZT0iMSIgd2lkdGg9IjEwMCUiIGFsaWduPSJjZW50ZXIiPg0KPC9zcGFu PjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkZyb206PC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4gRXJhbiBIYW1tZXIgJmx0Ozxh IGhyZWY9Im1haWx0bzplcmFuQGh1ZW5pdmVyc2UuY29tIj5lcmFuQGh1ZW5pdmVyc2UuY29tPC9h PiZndDs8YnI+DQo8Yj5Ubzo8L2I+IE1pa2UgSm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNo YWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iPk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTwvYT4m Z3Q7OyBXaWxsaWFtIE1pbGxzICZsdDs8YSBocmVmPSJtYWlsdG86d21pbGxzQHlhaG9vLWluYy5j b20iPndtaWxsc0B5YWhvby1pbmMuY29tPC9hPiZndDs7IEhhbm5lcyBUc2Nob2ZlbmlnICZsdDs8 YSBocmVmPSJtYWlsdG86aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldCI+aGFubmVzLnRzY2hvZmVu aWdAZ214Lm5ldDwvYT4mZ3Q7Ow0KIEp1bGlhbiBSZXNjaGtlICZsdDs8YSBocmVmPSJtYWlsdG86 anVsaWFuLnJlc2Noa2VAZ214LmRlIj5qdWxpYW4ucmVzY2hrZUBnbXguZGU8L2E+Jmd0Ow0KPGJy Pg0KPGI+Q2M6PC9iPiAmcXVvdDs8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPm9hdXRo QGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIj5v YXV0aEBpZXRmLm9yZzwvYT4mZ3Q7DQo8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgSnVuZSAx MiwgMjAxMiAxMTozOSBBTTxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW09BVVRILVdHXSBEaXNj dXNzaW9uIG5lZWRlZCBvbiB1c2VybmFtZSBhbmQgcGFzc3dvcmQgQUJORiBkZWZpbml0aW9uczwv c3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBp ZD0ieWl2MTQxODE2ODUzIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtjb2xvcjojMUY0OTdEIj5JcyB0aGUgdXNlIGNhc2Ugb2YgdXNpbmcgVVJJIGFzIGNsaWVudCBp ZHMgaW1wb3J0YW50PyBJdCBzZWVtcyBsaWtlIHNvbWV0aGluZyB0aGF0IG1pZ2h0IGJlY29tZSB1 c2VmdWwgaW4gdGhlIGZ1dHVyZSB3aGVyZSBjbGllbnRzIGNhbiB1c2UgdGhlaXIgdmVyaWZpYWJs ZSBzZXJ2ZXJzIHRvDQogYnlwYXNzIGNsaWVudCByZWdpc3RyYXRpb24gYW5kIHNpbWx5IHVzZSBh IFVSSSB0aGUgc2VydmVyIGNhbiB2YWxpZGF0ZSB2aWEgc29tZSBvdGhlciBtZWFucy48L3NwYW4+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPkkganVzdCB3YW50IHRvIG1h a2Ugc3VyZSB0aG9zZSB0aGlua2luZyBhYm91dCBtb3JlIGNvbXBsZXggdXNlIGNhc2VzIGludm9s dmluZyBkeW5hbWljIHJlZ2lzdHJhdGlvbiBvciBkaXN0cmlidXRlZCBjbGllbnQgbWFuYW1nZW5l dCBhcmUgYXdhcmUgb2YgdGhpcyBwb3RlbnRpYWwgcmVzdHJpY3Rpb24uPC9zcGFuPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj5JJ20gZmluZSBlaXRoZXIgd2F5Ljwvc3Bh bj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+RUg8L3NwYW4+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2siPkZyb206PC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFjayI+DQo8YSBocmVmPSJtYWlsdG86 b2F1dGgtYm91bmNlc0BpZXRmLm9yZyI+b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwvYT4gPGEgaHJl Zj0ibWFpbHRvOlttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10iPg0KW21haWx0bzpvYXV0 aC1ib3VuY2VzQGlldGYub3JnXTwvYT4gPGI+T24gQmVoYWxmIE9mIDwvYj5NaWtlIEpvbmVzPGJy Pg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEp1bmUgMTIsIDIwMTIgMTE6MjcgQU08YnI+DQo8Yj5U bzo8L2I+IFdpbGxpYW0gTWlsbHM7IEhhbm5lcyBUc2Nob2ZlbmlnOyBKdWxpYW4gUmVzY2hrZTxi cj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIj5vYXV0aEBpZXRm Lm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gRGlzY3Vzc2lvbiBu ZWVkZWQgb24gdXNlcm5hbWUgYW5kIHBhc3N3b3JkIEFCTkYgZGVmaW5pdGlvbnM8L3NwYW4+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91 bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0Qi Pk5vdCBpbnRlcm5hdGlvbmFsaXppbmcgZmllbGRzIGludGVuZGVkIGZvciBtYWNoaW5lIGNvbnN1 bXB0aW9uIG9ubHkgaXMgYWxyZWFkeSBhIHByZWNlZGVudCBzZXQgYW5kIGFncmVlZCB0byBieSB0 aGUgd29ya2luZyBncm91cCwgc28gbGV0IG1lIHNlY29uZCBCaWxs4oCZcyBwb2ludCBpbiB0aGF0 DQogcmVnYXJkLiZuYnNwOyBGb3IgaW5zdGFuY2UsIG5laXRoZXIg4oCcc2NvcGXigJ0gbm9yIOKA nGVycm9y4oCdIGFsbG93IG5vbi1BU0NJSSBjaGFyYWN0ZXJzLjwvc3Bhbj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+SnVsaWFuLCBpZiB5b3Ugd2FudCBkaWZmZXJlbnQg QUJORiB0ZXh0IHRoYW4gdGhlIHRleHQgSSB3cm90ZSBiZWxvdywgSSBiZWxpZXZlIGl0IHdvdWxk IGJlIG1vc3QgdXNlZnVsIGlmIHlvdSB3b3VsZCBwcm92aWRlIHRoZSBleGFjdCByZXBsYWNlIHdv cmRpbmcgdGhhdCB5b3XigJlkIGxpa2UNCiB0byBzZWUgaW5zdGVhZCBvZiBpdC4mbmJzcDsgVGhl biB0aGVyZeKAmXMgbm8gcG9zc2liaWxpdHkgb2YgbWlzdW5kZXJzdGFuZGluZyB0aGUgaW50ZW50 IG9mIHN1Z2dlc3RlZCBjaGFuZ2VzLjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtj b2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoYW5rcyBhbGwsPC9zcGFuPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPC9zcGFuPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBw dDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Y29sb3I6YmxhY2siPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtjb2xvcjpibGFjayI+DQo8YSBocmVmPSJtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+DQo8YSBocmVmPSJt YWlsdG86W21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSIgdGFyZ2V0PSJfYmxhbmsiPltt YWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ108L2E+DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPldp bGxpYW0gTWlsbHM8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgSnVuZSAxMiwgMjAxMiAxMTox OCBBTTxicj4NCjxiPlRvOjwvYj4gSGFubmVzIFRzY2hvZmVuaWc7IEp1bGlhbiBSZXNjaGtlPGJy Pg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj5vYXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1X R10gRGlzY3Vzc2lvbiBuZWVkZWQgb24gdXNlcm5hbWUgYW5kIHBhc3N3b3JkIEFCTkYgZGVmaW5p dGlvbnM8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxNC4wcHQ7Y29sb3I6YmxhY2siPkkgYWdyZWUgZ2VuZXJhbGx5IHdpdGggeW91ciBh c3N1bXB0aW9uIGFib3V0IGNsaWVudHMsIGJ1dCByYXRoZXIgdGhhbiBzYXlpbmcgJnF1b3Q7Y2xp ZW50cyBhcmUgZGV2aWNlcyZxdW90OyBJIHRoaW5rIGl0IG1ha2VzIG11Y2ggbW9yZSBzZW5zZSB0 byBzYXkgJnF1b3Q7Y2xpZW50cyBhcmUgTk9UIHVzZXJzLCBzbyBjbGllbnRfaWQNCiBuZWVkIG5v dCBiZSBpbnRlcm5hdGlvbmFsaXplZCZxdW90Oy4mbmJzcDsgSW4gcHJhY3RpY2FsIHRlcm1zIHRo ZXJlIGlzIHZlcnkgbGl0dGxlIHRvIGFyZ3VlIGZvciBhbnl0aGlnbiBiZXlvbmQgQVNDSUkgaW4g YSBjbGllbnRfc2VjcmV0LCBiYXNlNjQgZW5jb2Rpbmcgb3IgdGhlIGVxdWl2YWxlbnQgYmVpbmcg YSBmaW5lIHdheSB0byB0cmFuc3BvcnQgYXJiaXRyYXJ5IGJpdHMgaW4gYSBwb3J0YWJsZS9yZWFz b25hYmxlIHdheS48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNC4w cHQ7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjE0LjBwdDtjb2xvcjpibGFjayI+SSBhcmd1ZSB0aGF0IGNsaWVudF9pZCBuZWVkIG5v dCBiZSBpbnRlcm5hdGlvbmFsaXplZCBiZWNhdXNlIEkgYXNzdW1lIHRoYXQgYW55IHJlYWxseSBp bnRlcm5hdGlvbmFsaXplZCBhcHBsaWNhdGlvbiB3aWxsIGhhdmUgYW4gaW50ZXJuYXRpb25hbGl6 ZWQgcHJlc2VudGF0aW9uIGxheWVyIHRoYXQncw0KIHByZXNlbnRpbmcgYSBwcmV0dHkgbmFtZSBm b3IgdGhlIGNsaWVudF9pZC48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxNC4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjE0LjBwdDtjb2xvcjpibGFjayI+LWJpbGw8L3NwYW4+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1ib3R0b206MTQuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0LjBw dDtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2IGNs YXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlcjti YWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOmJs YWNrIj4NCjxociBzaXplPSIxIiB3aWR0aD0iMTAwJSIgYWxpZ249ImNlbnRlciI+DQo8L3NwYW4+ PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hp dGUiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2siPiBIYW5u ZXMgVHNjaG9mZW5pZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmhhbm5lcy50c2Nob2ZlbmlnQGdteC5u ZXQiIHRhcmdldD0iX2JsYW5rIj5oYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0PC9hPiZndDs8YnI+ DQo8Yj5Ubzo8L2I+IEp1bGlhbiBSZXNjaGtlICZsdDs8YSBocmVmPSJtYWlsdG86anVsaWFuLnJl c2Noa2VAZ214LmRlIiB0YXJnZXQ9Il9ibGFuayI+anVsaWFuLnJlc2Noa2VAZ214LmRlPC9hPiZn dDsNCjxicj4NCjxiPkNjOjwvYj4gJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+b2F1dGhAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJt YWlsdG86b2F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5vYXV0aEBpZXRmLm9yZzwvYT4m Z3Q7DQo8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgSnVuZSAxMiwgMjAxMiAxMTowMSBBTTxi cj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBEaXNjdXNzaW9uIG5lZWRlZCBvbiB1 c2VybmFtZSBhbmQgcGFzc3dvcmQgQUJORiBkZWZpbml0aW9uczwvc3Bhbj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48YnI+DQpJIGhh ZCBhIGNoYXQgd2l0aCBKdWxpYW4geWVzdGVyZGF5IGFuZCBoZXJlIGlzIG15IHNob3J0IHN1bW1h cnkuIDxicj4NCjxicj4NClNlY3Rpb24gMi4zIG9mIHRoZSBjb3JlIGRyYWZ0IGRlZmluZXMgY2xp ZW50IGF1dGhlbnRpY2F0aW9uIGJhc2VkIG9uIHR3byBtZWNoYW5pc21zIChhbmQgcHJvdmlkZXMg cm9vbSBmb3IgZXh0ZW5zaW9ucyk6DQo8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLW9hdXRoLXYyLTI3I3NlY3Rpb24tMi4zIj5odHRwOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLXYyLTI3I3NlY3Rpb24tMi4zPC9hPjxicj4NCjxicj4N CjEpIEhUVFAgQmFzaWMgQXV0aGVudGljYXRpb248YnI+DQo8YnI+DQoyKSBBIGN1c3RvbSBPQXV0 aCBhdXRoZW50aWNhdGlvbiBtZWNoYW5pc20gKHdoaWNoIHVzZXMgY2xpZW50X2lkIGFuZCBjbGll bnRfc2VjcmV0KTxicj4NCjxicj4NCldpdGggSFRUUCBCYXNpYyBhdXRoZW50aWNhdGlvbiB0aGUg cHJvYmxlbSBpcyB0aGF0IHRoaXMgaXMgYSBsZWdhY3kgdGVjaG5vbG9neSBhbmQgdGhlcmUgaXMg bm8gaW50ZXJuYXRpb25hbGl6YXRpb24gc3VwcG9ydC4NCjxicj4NCjxicj4NCldpdGggb3VyIGJy YW5kIG5ldyBjdXN0b20gT0F1dGggYXV0aGVudGljYXRpb24gbWVjaGFuaXNtIHdlIGhhdmUgbW9y ZSBvcHRpb25zLiA8YnI+DQo8YnI+DQpPbmUgcG9zc2libGUgYXBwcm9hY2ggaXMgdG8gc2F5IHRo YXQgdGhlIGNsaWVudHMgYXJlIGRldmljZXMgKGFuZCBub3QgZW5kIHVzZXJzKSBhbmQgdGhlcmVm b3JlIGludGVybmF0aW9uYWxpemF0aW9uIGRvZXMgbm90IG1hdHRlci4NCjxicj4NCjxicj4NCklz IGl0LCBob3dldmVyLCByZWFsbHkgdHJ1ZSB0aGF0IG9ubHkgVVMtQVNDSUkgY2hhcmFjdGVycyB3 aWxsIGFwcGVhciBpbiB0aGUgY2xpZW50X2lkIGFuZCBhbHNvIGluIHRoZSBjbGllbnRfc2VjcmV0 Pw0KPGJyPg0KPGJyPg0KSGVyZSB3ZSBoYXZlIHRoZSBwb3NzaWJpbGl0eSB0byBkZWZpbmUgc29t ZXRoaW5nIGJldHRlci4gPGJyPg0KPGJyPg0KSW4gYW55IGNhc2Ugd2UgaGF2ZSB0byByZXN0cmlj dCB0aGUgY2hhcmFjdGVycyB0aGF0IGFyZSB1c2VkIGluIHRoZXNlIHR3byBhdXRoZW50aWNhdGlv biBtZWNoYW5pc21zIHNpbmNlIHRoZXkgY291bGQgY29uZmxpY3Qgd2l0aCB0aGUgd2F5IGhvdyB3 ZSB0cmFuc3BvcnQgdGhlIGRhdGEgb3ZlciB0aGUgdW5kZXJseWluZyBwcm90b2NvbC4gSnVsaWFu IG1lbnRpb25lZCB0aGlzIGluIGhpcyBwcmV2aW91cyBtYWlscy4NCjxicj4NCjxicj4NCkp1bGlh biwgbWF5YmUgeW91IGNhbiBwcm92aWRlIGEgZGV0YWlsZWQgdGV4dCBwcm9wb3NhbCBmb3IgaG93 IHRvIGFkZHJlc3MgeW91ciBjb21tZW50IGluIGNhc2Ugd2UgZ28gZm9yIFVURjggKHdpdGggJSBl bmNvZGluZykgZm9yIHRoZSBjdXN0b20gT0F1dGggY2xpZW50IGF1dGhlbnRpY2F0aW9uIG1lY2hh bmlzbT8NCjxicj4NCjxicj4NCkNpYW88YnI+DQpIYW5uZXM8YnI+DQo8YnI+DQpPbiBKdW4gMTIs IDIwMTIsIGF0IDExOjU0IEFNLCBKdWxpYW4gUmVzY2hrZSB3cm90ZTo8YnI+DQo8YnI+DQomZ3Q7 IE9uIDIwMTItMDYtMTIgMDA6MTYsIE1pa2UgSm9uZXMgd3JvdGU6PGJyPg0KJmd0OyZndDsgUmV2 aWV3aW5nIHRoZSBmZWVkYmFjayBmcm9tIEp1bGlhbiwgSm9obiwgYW5kIEphbWVzLCBJJ20gY29t aW5nIHRvIHRoZSBjb25jbHVzaW9uIHRoYXQgY2xpZW50X2lkIGFuZCBjbGllbnRfc2VjcmV0LCBi ZWluZyBmb3IgbWFjaGluZXMgYW5kIG5vdCBodW1hbnMsIHNob3VsZCBiZSBBU0NJSSwgd2hlcmVh cyB1c2VybmFtZSBhbmQgcGFzc3dvcmQgc2hvdWxkIGJlIFVuaWNvZGUsIHNpbmNlIHRoZXkgYXJl IGZvciBodW1hbnMuJm5ic3A7IFBlciBKb2huJ3MNCiBmZWVkYmFjaywgY2xpZW50X2lkIGNhbiBu b3QgY29udGFpbiBhIGNvbG9uIGFuZCBiZSBjb21wYXRpYmxlIHdpdGggSFRUUCBCYXNpYy48YnI+ DQomZ3Q7IDxicj4NCiZndDsgSSdtIG5vdCBzdXJlIHRoYXQgcmVzdHJpY3RpbmcgdGhlIGNoYXJh Y3RlciByZXBlcnRvaXJlIGp1c3QgYmVjYXVzZSBvbmUgd2F5IHRvIHNlbmQgcmVxdWlyZXMgdGhp cyBpcyB0aGUgcmlnaHQgYXBwcm9hY2guIE15IHByZWZlcmVuY2Ugd291bGQgYmUgbm90IHRvIHB1 dCB0aGlzIGludG8gdGhlIEFCTkYsIGFuZCBqdXN0IHRvIHBvaW50IG91dCB0aGF0IGNlcnRhaW4g Y2hhcmFjdGVycyB3aWxsIG5vdCB3b3JrIG92ZXIgY2VydGFpbiB0cmFuc3BvcnRzLA0KIGFuZCB0 byBqdXN0IGFkdmlzZSB0byBhdm9pZCB0aGVtLjxicj4NCiZndDsgPGJyPg0KJmd0OyZndDsgVGhl cmVmb3JlLCBJJ2QgbGlrZSB0byBwcm9wb3NlIHRoZXNlIHVwZGF0ZWQgQUJORiBkZWZpbml0aW9u czo8YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgVlNDSEFSID0gJTIw LTdFPGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7IE5PQ09MT05WU0NIQVIgPSAleDIwLTM5IC8g JXgzQi03RTxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyBVTklDT0RFTk9DVFJMQ0hBUiA9ICZs dDtBbnkgVW5pY29kZSBjaGFyYWN0ZXIgb3RoZXIgdGhhbiAoICV4MC0xRiAvICV4N0YgKSZndDs8 YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgY2xpZW50LWlkID0gKk5P Q09MT05WU0NIQVI8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgY2xpZW50X3NlY3JldCA9ICpW U0NIQVI8YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgdXNlcm5hbWUg PSAqVU5JQ09ERU5PQ1RSTENIQVI8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgcGFzc3dvcmQg PSAqVU5JQ09ERU5PQ1RSTENIQVI8YnI+DQomZ3Q7IDxicj4NCiZndDsgSW4gdGhpcyBjYXNlIHlv dSBzaG91bGQgYWRkIGFuIGludHJvZHVjdG9yeSBzdGF0ZW1lbnQgcG9pbnRpbmcgb3V0IHRoYXQg dGhlIEFCTkYgZGVmaW5lcyB0aGUgZ3JhbW1hciBpbiB0ZXJtcyBvZiBVbmljb2RlIGNvZGUgcG9p bnRzLCBub3Qgb2N0ZXRzIChhcyBpdCBpcyB0aGUgY2FzZSBtb3N0IG9mIHRoZSB0aW1lKS48YnI+ DQomZ3Q7IDxicj4NCiZndDsmZ3Q7IEl0IHR1cm5zIG91dCB0aGF0IG5vbi1BU0NJSSBjaGFyYWN0 ZXJzIGFyZSBPSyBmb3IgdXNlcm5hbWUgYW5kIHBhc3N3b3JkIGJlY2F1c2UgdGhlIENvcmUgc3Bl YyBvbmx5IHBhc3NlcyB0aGVtIGluIHRoZSBmb3JtIGJvZHkgLSBub3QgdXNpbmcgSFRUUCBCYXNp YyAtIGFuZCBVVEYtOCBlbmNvZGluZyBpcyBzcGVjaWZpZWQuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IEknbGwgc2VuZCBhIHNlcGFyYXRlIG1haWwgYWJvdXQgdGhhdCwgdGhlIGN1cnJlbnQgdGV4dCBp biB0aGUgc3BlYyBpcyB3YXkgdG9vIHVuc3BlY2lmaWMuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jmd0 OyAmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNw OyAmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7 IFAuUy4mbmJzcDsgSWYgYW55b25lIGhhcyBhIGJldHRlciBBQk5GIGZvciBVTklDT0RFTk9DVFJM Q0hBUiB0aGFuICZxdW90OyZsdDtBbnkgVW5pY29kZSBjaGFyYWN0ZXIgb3RoZXIgdGhhbiAoICV4 MC0xRiAvICV4N0YgKSZndDsmcXVvdDssIHBsZWFzZSBzZW5kIGl0IHRvIG1lITxicj4NCiZndDsg PGJyPg0KJmd0OyBBcyBub3RlZCBiZWZvcmUsIGhlcmUncyBhbiBleGFtcGxlOiAmbHQ7PGEgaHJl Zj0iaHR0cDovL2dyZWVuYnl0ZXMuZGUvdGVjaC93ZWJkYXYvcmZjNTMyMy5odG1sI3JmYy5zZWN0 aW9uLjUuMTUuMSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9ncmVlbmJ5dGVzLmRlL3RlY2gvd2Vi ZGF2L3JmYzUzMjMuaHRtbCNyZmMuc2VjdGlvbi41LjE1LjE8L2E+Jmd0Ozxicj4NCiZndDsgPGJy Pg0KJmd0OyBCZXN0IHJlZ2FyZHMsIEp1bGlhbjxicj4NCiZndDsgX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IE9BdXRoIG1haWxpbmcgbGlz dDxicj4NCiZndDsgPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48YnI+DQo8YnI+DQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcg bGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi Pk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw dDtiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_0CBAEB56DDB3A140BA8E8C124C04ECA20106F052P3PWEX2MB008ex2_-- From wmills@yahoo-inc.com Tue Jun 12 13:13:04 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A68C521F858F for ; Tue, 12 Jun 2012 13:13:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.296 X-Spam-Level: X-Spam-Status: No, score=-17.296 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id viS6fnuy5lg9 for ; Tue, 12 Jun 2012 13:13:03 -0700 (PDT) Received: from nm9.bullet.mail.sp2.yahoo.com (nm9.bullet.mail.sp2.yahoo.com [98.139.91.79]) by ietfa.amsl.com (Postfix) with SMTP id 2727F21F855F for ; Tue, 12 Jun 2012 13:13:03 -0700 (PDT) Received: from [72.30.22.78] by nm9.bullet.mail.sp2.yahoo.com with NNFMP; 12 Jun 2012 20:13:00 -0000 Received: from [98.139.91.12] by tm12.bullet.mail.sp2.yahoo.com with NNFMP; 12 Jun 2012 20:13:00 -0000 Received: from [127.0.0.1] by omp1012.mail.sp2.yahoo.com with NNFMP; 12 Jun 2012 20:13:00 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 353999.97268.bm@omp1012.mail.sp2.yahoo.com Received: (qmail 58613 invoked by uid 60001); 12 Jun 2012 20:12:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1339531979; bh=9ZZ+yglwwPSOiUoyjPWPeH53coAY0efrrN/+iuvcSP8=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=YK2RidyBabx+Tmz+/gNUzHNAKV2SPASzZ5fBAPGoqElLQR2gVJtm8WMMYvYBftTYiiBjVavjLyOLRDNiTNRu1Zth0QEheif65KCPaI+Ft/BRt3tQkOe4CwO7PxfxTJu+J8VLvhwugHNknQEyVD4Aw1EB0/PdAaBH7L2F8qWvnaA= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=HP8ysIY6k5J/TRFPl1/9T13302eAs0CHYhRaEu1vlBbcpI2LHdKZBx1nZ8oy+1vYfgjm7bvXiNKslyF9HOU3tpE7XocRuhxYo6t/613Hgk6Rlw1y/uSuQcvms4KICrjDqI+3k3g4BHPmR+9CMD7MaTv6cAbZ1R5HHhVbdLu/TD4=; X-YMail-OSG: HIuKxrsVM1msLfVCM7WabDfUBj5Hb9jL.6Zaj9ra5XwWybW AsRv1Z4f5Jic5F_6L_GXgTrVFLHXZZzlVhTRM7rlBvGOqXg2Op7hoi6GNvhM 56ET6EKmzgr8proIhjVTXR5uHLouZNjoDw3aDIqGzmPlc7A3Sq614WvJYj7t Y0cGJAtcYDQ9YEPxDk40f2nhK5FCIdc.vK6wspb5jHIFAY6cQ.VL6g9DVh4I ccV6VCJ4opv645paBZQZ0nUi3n2TEUPxIryEEd.KF7_9QxBwRUOadGT0Yy8U jTVYsLUqA1s41k1bFmhMGJ0r1LyiOrqSaH9zH51PM5yDjZBIo_WG_UklRnoI 0913U_ziLjmUp5pSdSV4VHvH.bt0SfLVkdZjyhbbcX3OFqaNrjvKzYpZNnNj 8J3IznV_nS9hxdFYT9DLvKUJDHQrlxCJf_Zo4KOVyNHRT3KFJqSRH4zif97v zdaJ6U85UhjWXw419vUSUPFAe064yFrVBZ4Whefy_GyhwVVDfSnrKVFz9GB9 aykY48FAoXF35SJwz.jY9Cg-- Received: from [209.131.62.115] by web31813.mail.mud.yahoo.com via HTTP; Tue, 12 Jun 2012 13:12:59 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.118.349524 References: <4E1F6AAD24975D4BA5B16804296739436652F52D@TK5EX14MBXC284.redmond.corp.microsoft.com> <4FD4E9D4.2010808@gmx.de> <4E1F6AAD24975D4BA5B168042967394366531375@TK5EX14MBXC284.redmond.corp.microsoft.com> <4FD4F976.6090801@gmx.de> <4E1F6AAD24975D4BA5B1680429673943665316D1@TK5EX14MBXC284.redmond.corp.microsoft.com> <60F5CCB0-E036-4351-BD10-A44B33FCC5F6@ve7jtb.com> <255B9BB34FB7D647A506DC292726F6E114F5474E29@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B1680429673943665346D0@TK5EX14MBXC284.redmond.corp.microsoft.com> <4FD703C4.6050801@gmx.de> <5E38109E-2123-418B-8D45-B8DF4287790D@gmx.net> <1339525052.8121.YahooMailNeo@web31807.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B168042967394366535EAD@TK5EX14MBXC284.redmond.corp.microsoft.com> <0CBAEB56DDB3A140BA8E8C124C04ECA20106ED1F@P3PWEX2MB008.ex2.secureserver.net> <4FD78DF0.8030606@aol.com> <0CBAEB56DDB3A140BA8E8C124C04ECA20106EDD0@P3PWEX2MB008.ex2.secureserver.net> Message-ID: <1339531979.25824.YahooMailNeo@web31813.mail.mud.yahoo.com> Date: Tue, 12 Jun 2012 13:12:59 -0700 (PDT) From: William Mills To: Eran Hammer , George Fletcher In-Reply-To: <0CBAEB56DDB3A140BA8E8C124C04ECA20106EDD0@P3PWEX2MB008.ex2.secureserver.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="767760015-2012310867-1339531979=:25824" Cc: Julian Reschke , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 20:13:05 -0000 --767760015-2012310867-1339531979=:25824 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Is it workable/useful then to define something like:=0A=0A=C2=A0=C2=A0=C2= =A0 basic_client_id =3D 1*basic_auth_allowed_characters=0A=C2=A0=C2=A0=C2= =A0 uri_client_id =3D 1*uri_allowed_characters=0A=0AAnd include text saying= , "Clients using HTTP Basic authentication MUST have a client_id of type ba= sic_client_id.=C2=A0 Clients using client_id of type uri_client_id MUST NOT= use HTTP Basic client authentication."?=0A=0A-bill=0A=0A=0A=0A=0A>________= ________________________=0A> From: Eran Hammer =0A>To:= George Fletcher =0A>Cc: Mike Jones ; William Mills ; Hannes Tschofenig ; Julian Reschke ; "oauth@ietf.or= g" =0A>Sent: Tuesday, June 12, 2012 11:57 AM=0A>Subject: R= E: [OAUTH-WG] Discussion needed on username and password ABNF definitions= =0A> =0A>=0A> =0A>Encoding is an option which does not require us to addres= s it. Those seeking to use URIs can simply specify that.=0A>=C2=A0=0A>Howev= er, Julian indicated earlier that this restriction in Basic may change, in = which case we can reference Basic and simply add an interop warning (like t= he one we have for redirections including a fragment) about it.=0A>=C2=A0= =0A>EH=0A>=C2=A0=0A>From:George Fletcher [mailto:gffletch@aol.com] =0A>Sent= : Tuesday, June 12, 2012 11:44 AM=0A>To: Eran Hammer=0A>Cc: Mike Jones; Wil= liam Mills; Hannes Tschofenig; Julian Reschke; oauth@ietf.org=0A>Subject: R= e: [OAUTH-WG] Discussion needed on username and password ABNF definitions= =0A>=C2=A0=0A>I agree that there is value in allowing the client_id to be a= URI. The problem is that the ':' of the URI is not allowed in HTTP Basic w= hich is required by the OAuth2 spec for client authentication. We could enc= ode the client_id before HTTP Basic but that needs to be documented and add= s complexity.=0A>=0A>Thanks,=0A>George=0A>=0A>On 6/12/12 2:39 PM, Eran Hamm= er wrote: =0A>Is the use case of using URI as client ids important? It seem= s like something that might become useful in the future where clients can u= se their verifiable servers to bypass client registration and simly use a U= RI the server can validate via some other means.=0A>=C2=A0=0A>I just want t= o make sure those thinking about more complex use cases involving dynamic r= egistration or distributed client manamgenet are aware of this potential re= striction.=0A>=C2=A0=0A>I'm fine either way.=0A>=C2=A0=0A>EH=0A>=C2=A0=0A>F= rom:oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Mik= e Jones=0A>Sent: Tuesday, June 12, 2012 11:27 AM=0A>To: William Mills; Hann= es Tschofenig; Julian Reschke=0A>Cc: oauth@ietf.org=0A>Subject: Re: [OAUTH-= WG] Discussion needed on username and password ABNF definitions=0A>=C2=A0= =0A>Not internationalizing fields intended for machine consumption only is = already a precedent set and agreed to by the working group, so let me secon= d Bill=E2=80=99s point in that regard.=C2=A0 For instance, neither =E2=80= =9Cscope=E2=80=9D nor =E2=80=9Cerror=E2=80=9D allow non-ASCII characters.= =0A>=C2=A0=0A>Julian, if you want different ABNF text than the text I wrote= below, I believe it would be most useful if you would provide the exact re= place wording that you=E2=80=99d like to see instead of it.=C2=A0 Then ther= e=E2=80=99s no possibility of misunderstanding the intent of suggested chan= ges.=0A>=C2=A0=0A>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Th= anks all,=0A>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mi= ke=0A>=C2=A0=0A>From:oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]= On Behalf Of William Mills=0A>Sent: Tuesday, June 12, 2012 11:18 AM=0A>To:= Hannes Tschofenig; Julian Reschke=0A>Cc: oauth@ietf.org=0A>Subject: Re: [O= AUTH-WG] Discussion needed on username and password ABNF definitions=0A>=C2= =A0=0A>I agree generally with your assumption about clients, but rather tha= n saying "clients are devices" I think it makes much more sense to say "cli= ents are NOT users, so client_id need not be internationalized".=C2=A0 In p= ractical terms there is very little to argue for anythign beyond ASCII in a= client_secret, base64 encoding or the equivalent being a fine way to trans= port arbitrary bits in a portable/reasonable way.=0A>=C2=A0=0A>I argue that= client_id need not be internationalized because I assume that any really i= nternationalized application will have an internationalized presentation la= yer that's presenting a pretty name for the client_id.=0A>=C2=A0=0A>-bill= =0A>=C2=A0=0A>=0A>________________________________=0A> =0A>From:Hannes Tsch= ofenig =0A>To: Julian Reschke =0A>Cc: "oauth@ietf.org" =0A>Sent: Tuesday, June 12,= 2012 11:01 AM=0A>Subject: Re: [OAUTH-WG] Discussion needed on username and= password ABNF definitions=0A>=0A>I had a chat with Julian yesterday and he= re is my short summary. =0A>=0A>Section 2.3 of the core draft defines clien= t authentication based on two mechanisms (and provides room for extensions)= :=0Ahttp://tools.ietf.org/html/draft-ietf-oauth-v2-27#section-2.3=0A>=0A>1)= HTTP Basic Authentication=0A>=0A>2) A custom OAuth authentication mechanis= m (which uses client_id and client_secret)=0A>=0A>With HTTP Basic authentic= ation the problem is that this is a legacy technology and there is no inter= nationalization support. =0A>=0A>With our brand new custom OAuth authentica= tion mechanism we have more options. =0A>=0A>One possible approach is to sa= y that the clients are devices (and not end users) and therefore internatio= nalization does not matter. =0A>=0A>Is it, however, really true that only U= S-ASCII characters will appear in the client_id and also in the client_secr= et? =0A>=0A>Here we have the possibility to define something better. =0A>= =0A>In any case we have to restrict the characters that are used in these t= wo authentication mechanisms since they could conflict with the way how we = transport the data over the underlying protocol. Julian mentioned this in h= is previous mails. =0A>=0A>Julian, maybe you can provide a detailed text pr= oposal for how to address your comment in case we go for UTF8 (with % encod= ing) for the custom OAuth client authentication mechanism? =0A>=0A>Ciao=0A>= Hannes=0A>=0A>On Jun 12, 2012, at 11:54 AM, Julian Reschke wrote:=0A>=0A>> = On 2012-06-12 00:16, Mike Jones wrote:=0A>>> Reviewing the feedback from Ju= lian, John, and James, I'm coming to the conclusion that client_id and clie= nt_secret, being for machines and not humans, should be ASCII, whereas user= name and password should be Unicode, since they are for humans.=C2=A0 Per J= ohn's=0A feedback, client_id can not contain a colon and be compatible with= HTTP Basic.=0A>> =0A>> I'm not sure that restricting the character reperto= ire just because one way to send requires this is the right approach. My pr= eference would be not to put this into the ABNF, and just to point out that= certain characters will not work over certain transports,=0A and to just a= dvise to avoid them.=0A>> =0A>>> Therefore, I'd like to propose these updat= ed ABNF definitions:=0A>>> =0A>>>=C2=A0 =C2=A0 VSCHAR =3D %20-7E=0A>>>=C2= =A0 =C2=A0 NOCOLONVSCHAR =3D %x20-39 / %x3B-7E=0A>>>=C2=A0 =C2=A0 UNICODENO= CTRLCHAR =3D =0A>>> =0A= >>>=C2=A0 =C2=A0 client-id =3D *NOCOLONVSCHAR=0A>>>=C2=A0 =C2=A0 client_sec= ret =3D *VSCHAR=0A>>> =0A>>>=C2=A0 =C2=A0 username =3D *UNICODENOCTRLCHAR= =0A>>>=C2=A0 =C2=A0 password =3D *UNICODENOCTRLCHAR=0A>> =0A>> In this case= you should add an introductory statement pointing out that the ABNF define= s the grammar in terms of Unicode code points, not octets (as it is the cas= e most of the time).=0A>> =0A>>> It turns out that non-ASCII characters are= OK for username and password because the Core spec only passes them in the= form body - not using HTTP Basic - and UTF-8 encoding is specified.=0A>> = =0A>> I'll send a separate mail about that, the current text in the spec is= way too unspecific.=0A>> =0A>>> =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2= =A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 -- Mike=0A>>> =0A>>> P.S.=C2=A0 If anyon= e has a better ABNF for UNICODENOCTRLCHAR than "", please send it to me!=0A>> =0A>> As noted befor= e, here's an example: =0A>> =0A>> Best regards, Julian=0A>> ________________________= _______________________=0A>> OAuth mailing list=0A>> OAuth@ietf.org=0A>> ht= tps://www.ietf.org/mailman/listinfo/oauth=0A>=0A>__________________________= _____________________=0A>OAuth mailing list=0A>OAuth@ietf.org=0A>https://ww= w.ietf.org/mailman/listinfo/oauth=0A>=0A>=0A>=0A>=0A>______________________= _________________________=0A>OAuth mailing list=0A>OAuth@ietf.org=0A>https:= //www.ietf.org/mailman/listinfo/oauth=0A>=C2=A0=0A>=0A> --767760015-2012310867-1339531979=:25824 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Is it workable/useful then to define something like:
    basic_clien= t_id =3D 1*basic_auth_allowed_characters
    uri_client_id =3D 1*uri_allowed_characters

And in= clude text saying, "Clients using HTTP Basic authentication MUST have a cli= ent_id of type basic_client_id.  Clients using client_id of type uri_c= lient_id MUST NOT use HTTP Basic client authentication."?
=
-bill

From: Eran Hammer <er= an@hueniverse.com>
To:<= /b> George Fletcher <gffletch@aol.com>
Cc: Mike Jones <Michael.Jones@microsoft.com>; = William Mills <wmills@yahoo-inc.com>; Hannes Tschofenig <hannes.ts= chofenig@gmx.net>; Julian Reschke <julian.reschke@gmx.de>; "oauth@= ietf.org" <oauth@ietf.org>
Sent: Tuesday, June 12, 2012 11:57 AM
Subject: RE: [OAUTH-WG] Discussion needed on us= ername and password ABNF definitions

=0A
=0A=0A =0A =0A=0A=0A
=0A
=0A
Encoding is an option which does not require us to addre= ss it. Those seeking to use URIs can simply specify that.
=0A<= div class=3D"yiv837997530MsoNormal">  
=0A
However, Julian indicated earlie= r that this restriction in Basic may change, in which case we can reference= Basic and simply add an interop warning (like the=0A one we have for redir= ections including a fragment) about it.
=0A
 
=0A
EH
=0A
 
= =0A
=0A
=0A
=0A
= From: George Fletcher [mailto:gffletc= h@aol.com]=0A
=0ASent: Tuesday, June 12, 2012 11:44 AM
=0AT= o: Eran Hammer
=0ACc: Mike Jones; William Mills; Hannes Tscho= fenig; Julian Reschke; oauth@ietf.org
=0ASubject: Re: [OAUTH-WG] = Discussion needed on username and password ABNF definitions
= =0A
=0A
=0A
 
=0A=
I agree that there is= value in allowing the client_id to be a URI. The problem is that the ':' o= f the URI is not allowed in HTTP Basic which is required by the OAuth2 spec= for client authentication.=0A We could encode the client_id before HTTP Ba= sic but that needs to be documented and adds complexity.
=0A
=0AThank= s,
=0AGeorge
=0A
=0AOn 6/12/12 2:39 PM, Eran Hammer wrote: =
=0A
Is the use case of using URI as client ids important? I= t seems like something that might become useful in the future where clients= can use their verifiable=0A servers to bypass client registration and siml= y use a URI the server can validate via some other means.
=0A<= div class=3D"yiv837997530MsoNormal"> 
=0A
I just want to make sure those th= inking about more complex use cases involving dynamic registration or distr= ibuted client manamgenet are aware of this potential=0A restriction.=
=0A
 
=0A
I'm fine either way.
=0A
 
=0A
EH
= =0A
 
=0A
=0A
=0A
=0A
From:=0Aoauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]=0AOn Behalf Of Mike Jo= nes
=0ASent: Tuesday, June 12, 2012 11:27 AM
=0ATo: Wil= liam Mills; Hannes Tschofenig; Julian Reschke
=0ACc: oauth@ietf.org
=0ASubject: Re: [OAUTH-WG] Dis= cussion needed on username and password ABNF definitions
=0A=0A
=0A
 
=0A
Not internationalizing fields intended for machine consumption only is = already a precedent set and agreed to by the working group, so let me secon= d Bill=E2=80=99s point=0A in that regard.  For instance, neither =E2= =80=9Cscope=E2=80=9D nor =E2=80=9Cerror=E2=80=9D allow non-ASCII characters= .
=0A
 
=0A
Julian, if you= want different ABNF text than the text I wrote below, I believe it would b= e most useful if you would provide the exact replace wording that you=E2=80= =99d=0A like to see instead of it.  Then there=E2=80=99s no possibilit= y of misunderstanding the intent of suggested changes.
=0A 
=0A
      =             &nb= sp;            =             &nb= sp;            =     Thanks all,
=0A
   =             &nb= sp;            =             &nb= sp;            =        -- Mike
=0A
&nbs= p;
=0A
=0A
=0A
From:=0Aoauth-bounces@= ietf.org = =0A[mailto:oauth-bounces@ietf.org] On Behalf Of William Mills=0ASent: Tuesday, June 12, 2012 11:18 AM
=0ATo: Hannes Ts= chofenig; Julian Reschke
=0ACc: oauth= @ietf.org
=0ASubject: Re: [OAUTH-WG] Discussion needed on use= rname and password ABNF definitions
=0A
=0A
=0A
 
=0A
=0A
=0A
I agree generally with your assumption about clients, but rat= her than saying "clients are devices" I think it makes much more sense to= =0A say "clients are NOT users, so client_id need not be internationalized"= .  In practical terms there is very little to argue for anythign beyon= d ASCII in a client_secret, base64 encoding or the equivalent being a fine = way to transport arbitrary bits in a portable/reasonable=0A way. =0A
=0A
=0A
 
=0A=0A
=0A
I argue that client_id need not be inte= rnationalized because I assume that any really internationalized applicatio= n will have an internationalized=0A presentation layer that's presenting a = pretty name for the client_id.
=0A
=0A
=0A
 
=0A
=0A
=0A
-bill
=0A
=0A
=0A
 
=0A
=0A
=0A=0A

=0AI had a chat with Julian= yesterday and here is my short summary.
=0A
=0ASection 2.3 of the c= ore draft defines client authentication based on two mechanisms (and provid= es room for extensions):=0Ahttp://tools.ietf.org/html/draft-ietf-oauth-v2-2= 7#section-2.3
=0A
=0A1) HTTP Basic Authentication
=0A
=0A2) A c= ustom OAuth authentication mechanism (which uses client_id and client_secre= t)
=0A
=0AWith HTTP Basic authentication the problem is that this is = a legacy technology and there is no internationalization support.=0A
=0A=
=0AWith our brand new custom OAuth authentication mechanism we have mor= e options.
=0A
=0AOne possible approach is to say that the clients a= re devices (and not end users) and therefore internationalization does not = matter.=0A
=0A
=0AIs it, however, really true that only US-ASCII char= acters will appear in the client_id and also in the client_secret?=0A
= =0A
=0AHere we have the possibility to define something better.
=0A<= br>=0AIn any case we have to restrict the characters that are used in these= two authentication mechanisms since they could conflict with the way how w= e transport the data over the underlying protocol. Julian mentioned this in= his previous mails.=0A
=0A
=0AJulian, maybe you can provide a detail= ed text proposal for how to address your comment in case we go for UTF8 (wi= th % encoding) for the custom OAuth client authentication mechanism?=0A
= =0A
=0ACiao
=0AHannes
=0A
=0AOn Jun 12, 2012, at 11:54 AM, Juli= an Reschke wrote:
=0A
=0A> On 2012-06-12 00:16, Mike Jones wrote:<= br>=0A>> Reviewing the feedback from Julian, John, and James, I'm com= ing to the conclusion that client_id and client_secret, being for machines = and not humans, should be ASCII, whereas username and password should be Un= icode, since they are for humans.  Per John's=0A feedback, client_id c= an not contain a colon and be compatible with HTTP Basic.
=0A>
= =0A> I'm not sure that restricting the character repertoire just because= one way to send requires this is the right approach. My preference would b= e not to put this into the ABNF, and just to point out that certain charact= ers will not work over certain transports,=0A and to just advise to avoid t= hem.
=0A>
=0A>> Therefore, I'd like to propose these update= d ABNF definitions:
=0A>>
=0A>>    VSCHAR =3D = %20-7E
=0A>>    NOCOLONVSCHAR =3D %x20-39 / %x3B-7E
= =0A>>    UNICODENOCTRLCHAR =3D <Any Unicode character ot= her than ( %x0-1F / %x7F )>
=0A>>
=0A>>    = client-id =3D *NOCOLONVSCHAR
=0A>>    client_secret =3D = *VSCHAR
=0A>>
=0A>>    username =3D *UNICODENO= CTRLCHAR
=0A>>    password =3D *UNICODENOCTRLCHAR
=0A= >
=0A> In this case you should add an introductory statement poin= ting out that the ABNF defines the grammar in terms of Unicode code points,= not octets (as it is the case most of the time).
=0A>
=0A>>= ; It turns out that non-ASCII characters are OK for username and password b= ecause the Core spec only passes them in the form body - not using HTTP Bas= ic - and UTF-8 encoding is specified.
=0A>
=0A> I'll send a se= parate mail about that, the current text in the spec is way too unspecific.=
=0A>
=0A>>          &nb= sp;      -- Mike
=0A>>
=0A>> P.S.&nb= sp; If anyone has a better ABNF for UNICODENOCTRLCHAR than "<Any Unicode= character other than ( %x0-1F / %x7F )>", please send it to me!
=0A&= gt;
=0A> As noted before, here's an example: <http://greenbytes.de/tech/webdav/rfc5323.html#rfc.section= .5.15.1>
=0A>
=0A> Best regards, Julian
=0A> ____= ___________________________________________
=0A> OAuth mailing list=0A> OAuth@ietf.org
=0A> https://www.ietf.org/mailman/listinfo/oauth
=0A
=0A____= ___________________________________________
=0AOAuth mailing list
=0A= OAuth@ietf.org
=0Ahttps:= //www.ietf.org/mailman/listinfo/oauth
=0A
=0A
=0A
= =0A
=0A
=0A

=0A
=0A=0A
=0A
_______________________________________________
= =0A
OAuth mailing list
=0A
OAuth@=
ietf.org
=0A
https://www.ietf.org/mailman/lis=
tinfo/oauth
=0A
 
= =0A
=0A
=0A
=0A=0A


--767760015-2012310867-1339531979=:25824-- From sm@resistor.net Tue Jun 12 13:38:42 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9E6411E8095 for ; Tue, 12 Jun 2012 13:38:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.475 X-Spam-Level: X-Spam-Status: No, score=-102.475 tagged_above=-999 required=5 tests=[AWL=0.124, 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 a96jWfKBRxb7 for ; Tue, 12 Jun 2012 13:38:41 -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 A841111E8088 for ; Tue, 12 Jun 2012 13:38:41 -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 q5CKcVpt022157; Tue, 12 Jun 2012 13:38:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1339533517; i=@resistor.net; bh=kdJpygV/X94rnzcWQTfK3uxx4lRXy9LF2hFDOif0vpU=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=M5GAXYEgXjd9fsoFEHJI29o974xTyuvm0it9TxUCO24v0u2C6zzfkVC9C0xbdj5ks pxxODZBjOHr/uSL8J56h67zJABjlXXufUvt1q3ph+V5/ytQreqBxkldsJ5RWdsSkd8 mdQFq1ljZgQ1p1cXtvKQrG5FF5e15dnGqdSZddFU= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1339533517; i=@resistor.net; bh=kdJpygV/X94rnzcWQTfK3uxx4lRXy9LF2hFDOif0vpU=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=bCbSvVgOSHuKphds9NTiM0H5BY1Zoof+XvGCDPfXKd5g+qQt7IoRMvsdo3lEpnHGD 5/b4l8C1l9uGkhJ7KsmDhI0sStdVvU/YyUBkEKe8/lkpUF3j0ZvLgNIPZMn4UY2Ku8 O48he7thx8VXJcsrXvKB0DFaou+6AEONz2MahnKU= Message-Id: <6.2.5.6.2.20120612131346.0aaa2d20@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 12 Jun 2012 13:22:32 -0700 To: Derek Atkins , Hannes Tschofenig , Eran Hammer From: SM In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] On the OAuth Core Spec X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 20:38:42 -0000 Hi Derek, Hannes, Eran, Thanks, -sm From psxjs4@nottingham.ac.uk Tue Jun 12 13:39:36 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E9E011E80A6 for ; Tue, 12 Jun 2012 13:39:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KRq2xi6evRZO for ; Tue, 12 Jun 2012 13:39:33 -0700 (PDT) Received: from ixe-mta-19.emailfiltering.com (ixe-mta-19-tx.emailfiltering.com [194.116.198.150]) by ietfa.amsl.com (Postfix) with ESMTP id 2AB9F11E80AA for ; Tue, 12 Jun 2012 13:39:31 -0700 (PDT) Received: from smtp3.nottingham.ac.uk ([128.243.44.55]) by ixe-mta-19.emailfiltering.com with emfmta (version 4.8.5.86) by TLS id 2281607244 ;865b32724ad13fb; Tue, 12 Jun 2012 21:39:25 +0100 Received: from uiwexhub02.ad.nottingham.ac.uk ([128.243.15.132]) by smtp3.nottingham.ac.uk with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1SeXs4-0004pQ-IY; Tue, 12 Jun 2012 21:39:24 +0100 Received: from EXCHANGE1.ad.nottingham.ac.uk ([fe80::7962:f868:e6ee:6267]) by UIWEXHUB02.ad.nottingham.ac.uk ([2002:80f3:f84::80f3:f84]) with mapi; Tue, 12 Jun 2012 21:38:58 +0100 From: Jianhua Shao To: Eran Hammer Date: Tue, 12 Jun 2012 21:39:00 +0100 Thread-Topic: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion needed on username and password ABNF definitions Thread-Index: Ac1I22PK5QuNFzeyRLShnQmAX3Gyrg== Message-ID: References: <4E1F6AAD24975D4BA5B16804296739436652F52D@TK5EX14MBXC284.redmond.corp.microsoft.com> <4FD4E9D4.2010808@gmx.de> <4E1F6AAD24975D4BA5B168042967394366531375@TK5EX14MBXC284.redmond.corp.microsoft.com> <4FD4F976.6090801@gmx.de> <4E1F6AAD24975D4BA5B1680429673943665316D1@TK5EX14MBXC284.redmond.corp.microsoft.com> <60F5CCB0-E036-4351-BD10-A44B33FCC5F6@ve7jtb.com> <255B9BB34FB7D647A506DC292726F6E114F5474E29@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B1680429673943665346D0@TK5EX14MBXC284.redmond.corp.microsoft.com> <4FD703C4.6050801@gmx.de> <5E38109E-2123-418B-8D45-B8DF4287790D@gmx.net> <1339525052.8121.YahooMailNeo@web31807.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B168042967394366535EAD@TK5EX14MBXC284.redmond.corp.microsoft.com> <0CBAEB56DDB3A140BA8E8C124C04ECA20106ED1F@P3PWEX2MB008.ex2.secureserver.net> <1339531450.39923.YahooMailNeo@web31809.mail.mud.yahoo.com> <0CBAEB56DDB3A140BA8E8C124C04ECA20106F052@P3PWEX2MB008.ex2.secureserver.net> In-Reply-To: <0CBAEB56DDB3A140BA8E8C124C04ECA20106F052@P3PWEX2MB008.ex2.secureserver.net> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_CDD54A9706724D98B2B4D6C73ED91587exmailnottinghamacuk_" MIME-Version: 1.0 Cc: Julian Reschke , Richard Mortier , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion needed on username and password ABNF definitions X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 20:39:36 -0000 --_000_CDD54A9706724D98B2B4D6C73ED91587exmailnottinghamacuk_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hello, Dynamic client registration is very useful if client or resource or authori= sation server is not permanently available. A typical case is that is the resource or authorisation server is in mobile= platform, the connection is not always available. Another typical case is that authorisation server do not necessary to have = client pre-registered on itself. At moment, industry like facebook would li= ke developer to register a app on its app centre first, and then ask user a= uth to use the app. We are researchers from Digital Economy Research Institute. We have this pr= oblem When we developing Dataware that could manage the control of access t= o personal data. We play around our solution base on Oauth2: https://github= .com/jianhuashao/dataware.catalog/wiki We are in the list to receive your maillist, but currently need moderate to= post any message. cc my colleague, Richard Mortier Best Jian On 12 Jun 2012, at 21:08, Eran Hammer wrote: The only distinction I would make is between removing flexibiliy to proacti= vely enabling future extensibility. I would stop short of perscribing encod= ing in order to fit uri into the Basic auth fields. But if there is a way t= o allow this to be less restrictive without clean interop issues, that woul= d be nice. I do agree we need some actual use cases before we spend much more time on = this. EH From: William Mills [mailto:wmills@yahoo-inc.com] Sent: Tuesday, June 12, 2012 1:04 PM To: Eran Hammer; Mike Jones; Hannes Tschofenig; Julian Reschke Cc: oauth@ietf.org Subject: Dynamic clients, URI, and stuff Re: [OAUTH-WG] Discussion needed o= n username and password ABNF definitions I think dynamic client registration is something we have not talked out eno= ugh yet. There's a pretty clear use case for dynamic registration. Does identifying the client with a URI allow some form of OpenID-ish flow f= or this? Is the client ID as a URI a way to allow a trusted site to provide metadata= about the client? Is that URI a way to hit an IDP we trust to validate the client in some way= with the provided secret? I guess what I'm looking for here is a concrete use case/problem to solve, = rather then leaving a hook we think is the right thing. -bill ________________________________ From: Eran Hammer > To: Mike Jones >; William Mills >; H= annes Tschofenig >; Julian Reschke > Cc: "oauth@ietf.org" > Sent: Tuesday, June 12, 2012 11:39 AM Subject: RE: [OAUTH-WG] Discussion needed on username and password ABNF def= initions Is the use case of using URI as client ids important? It seems like somethi= ng that might become useful in the future where clients can use their verif= iable servers to bypass client registration and simly use a URI the server = can validate via some other means. I just want to make sure those thinking about more complex use cases involv= ing dynamic registration or distributed client manamgenet are aware of this= potential restriction. I'm fine either way. EH From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Mike = Jones Sent: Tuesday, June 12, 2012 11:27 AM To: William Mills; Hannes Tschofenig; Julian Reschke Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF def= initions Not internationalizing fields intended for machine consumption only is alre= ady a precedent set and agreed to by the working group, so let me second Bi= ll=92s point in that regard. For instance, neither =93scope=94 nor =93erro= r=94 allow non-ASCII characters. Julian, if you want different ABNF text than the text I wrote below, I beli= eve it would be most useful if you would provide the exact replace wording = that you=92d like to see instead of it. Then there=92s no possibility of m= isunderstanding the intent of suggested changes. Thanks all, -- Mike From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Willi= am Mills Sent: Tuesday, June 12, 2012 11:18 AM To: Hannes Tschofenig; Julian Reschke Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF def= initions I agree generally with your assumption about clients, but rather than sayin= g "clients are devices" I think it makes much more sense to say "clients ar= e NOT users, so client_id need not be internationalized". In practical ter= ms there is very little to argue for anythign beyond ASCII in a client_secr= et, base64 encoding or the equivalent being a fine way to transport arbitra= ry bits in a portable/reasonable way. I argue that client_id need not be internationalized because I assume that = any really internationalized application will have an internationalized pre= sentation layer that's presenting a pretty name for the client_id. -bill ________________________________ From: Hannes Tschofenig > To: Julian Reschke > Cc: "oauth@ietf.org" > Sent: Tuesday, June 12, 2012 11:01 AM Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF def= initions I had a chat with Julian yesterday and here is my short summary. Section 2.3 of the core draft defines client authentication based on two me= chanisms (and provides room for extensions):http://tools.ietf.org/html/draf= t-ietf-oauth-v2-27#section-2.3 1) HTTP Basic Authentication 2) A custom OAuth authentication mechanism (which uses client_id and client= _secret) With HTTP Basic authentication the problem is that this is a legacy technol= ogy and there is no internationalization support. With our brand new custom OAuth authentication mechanism we have more optio= ns. One possible approach is to say that the clients are devices (and not end u= sers) and therefore internationalization does not matter. Is it, however, really true that only US-ASCII characters will appear in th= e client_id and also in the client_secret? Here we have the possibility to define something better. In any case we have to restrict the characters that are used in these two a= uthentication mechanisms since they could conflict with the way how we tran= sport the data over the underlying protocol. Julian mentioned this in his p= revious mails. Julian, maybe you can provide a detailed text proposal for how to address y= our comment in case we go for UTF8 (with % encoding) for the custom OAuth c= lient authentication mechanism? Ciao Hannes On Jun 12, 2012, at 11:54 AM, Julian Reschke wrote: > On 2012-06-12 00:16, Mike Jones wrote: >> Reviewing the feedback from Julian, John, and James, I'm coming to the c= onclusion that client_id and client_secret, being for machines and not huma= ns, should be ASCII, whereas username and password should be Unicode, since= they are for humans. Per John's feedback, client_id can not contain a col= on and be compatible with HTTP Basic. > > I'm not sure that restricting the character repertoire just because one w= ay to send requires this is the right approach. My preference would be not = to put this into the ABNF, and just to point out that certain characters wi= ll not work over certain transports, and to just advise to avoid them. > >> Therefore, I'd like to propose these updated ABNF definitions: >> >> VSCHAR =3D %20-7E >> NOCOLONVSCHAR =3D %x20-39 / %x3B-7E >> UNICODENOCTRLCHAR =3D >> >> client-id =3D *NOCOLONVSCHAR >> client_secret =3D *VSCHAR >> >> username =3D *UNICODENOCTRLCHAR >> password =3D *UNICODENOCTRLCHAR > > In this case you should add an introductory statement pointing out that t= he ABNF defines the grammar in terms of Unicode code points, not octets (as= it is the case most of the time). > >> It turns out that non-ASCII characters are OK for username and password = because the Core spec only passes them in the form body - not using HTTP Ba= sic - and UTF-8 encoding is specified. > > I'll send a separate mail about that, the current text in the spec is way= too unspecific. > >> -- Mike >> >> P.S. If anyone has a better ABNF for UNICODENOCTRLCHAR than "", please send it to me! > > As noted before, here's an example: > > Best regards, Julian > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth = This message and any attachment are intended solely for the addressee a= nd may contain confidential information. If you have received this mess= age in error, please send it back to me, and immediately delete it. P= lease do not use, copy or disclose the information contained in this me= ssage or in any attachment. Any views or opinions expressed by the aut= hor of this email do not necessarily reflect the views of the Universit= y of Nottingham.=0D=0A=0D=0AThis message has been checked for viruses b= ut the contents of an attachment=0D=0Amay still contain software viruse= s which could damage your computer system:=0D=0Ayou are advised to perf= orm your own checks. Email communications with the=0D=0AUniversity of N= ottingham may be monitored as permitted by UK legislation.= --_000_CDD54A9706724D98B2B4D6C73ED91587exmailnottinghamacuk_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable https://github.com/jianhuas= hao/dataware.catalog/wiki

We are in the list t= o receive your maillist, but currently need moderate to post any message. c= c my colleague, Richard Mortier
Best
Jian

On 12 Jun 2012, at 21:08, Eran Hammer wrote:

The only distinction I would make = is between removing flexibiliy to proactively enabling future extensibility= . I would stop short of perscribing encoding in order to fit uri into the B= asic auth fields. But if there is a way to allow this to be less restrictiv= e without clean interop issues, that would be nice.
=
 
I do ag= ree we need some actual use cases before we spend much more time on this.
 
EH
 
From: Wi= lliam Mills [mailto:wmills@yahoo-inc.com] 
Sent:&nbs= p;Tuesday, June 12, 2012 1:04 PM
To: Eran Hammer; Mike Jones; Hannes Tschofenig; Ju= lian Reschke
Cc: oauth@ietf.org
Subject: Dynamic clients, URI, and = stuff Re: [OAUTH-WG] Discussion needed on username and password ABNF defini= tions
 
=
I think dy= namic client registration is something we have not talked out enough yet.&n= bsp; There's a pretty clear use case for dynamic registration.  <= o:p>
 
Does identifying the= client with a URI allow some form of OpenID-ish flow for this? <= /o:p>
Is that URI a= way to hit an IDP we trust to validate the client in some way with the pro= vided secret?
 
<= div>
I gues= s what I'm looking for here is a concrete use case/problem to solve, rather= then leaving a hook we think is the right thing.
<= o:p> 
-bill
 
 
From: Eran Hammer <eran@hueniverse.com><= br>To: Mike Jones = <Michael.Jones@microsoft.com>; William Mi= lls <wmills@yahoo-inc.com>; Hannes Tschofenig &l= t;hannes.tschofenig@gmx.net>; Julian Reschke &= lt;julian.reschke@gmx.de> 
Cc: "oauth@ietf.org" <oauth@ietf.o= rg> 
Sent: Tuesday, June 12, 2012= 11:39 AM
Subject: RE: [OAUTH-WG] Discussion needed on username and password ABNF definiti= ons
 
 
I just want to make sure those thi= nking about more complex use cases involving dynamic registration or distri= buted client manamgenet are aware of this potential restriction.
 
I'm fine either way.=
EH
 
= From: oauth-bounces@ie= tf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Tuesday, June 12, 2012 11:27 AM
To: William Mills; Hannes Tschofenig= ; Julian Reschke
Cc: <= /span>oauth@ietf.org
Subject: Re: [OAUTH-WG] Discussion needed on username = and password ABNF definitions
 
No= t internationalizing fields intended for machine consumption only is alread= y a precedent set and agreed to by the working group, so let me second Bill= =92s point in that regard.  For instance, neither =93scope=94 nor =93e= rror=94 allow non-ASCII characters.
 
<= /div>
<= span style=3D"font-size: 11pt; color: rgb(31, 73, 125); ">Julian, if you wa= nt different ABNF text than the text I wrote below, I believe it would be m= ost useful if you would provide the exact replace wording that you=92d like= to see instead of it.  Then there=92s no possibility of misunderstand= ing the intent of suggested changes.<= o:p>
 
=
         =             &nb= sp;            =             &nb= sp;            = -- Mike
 
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of&nbs= p;William Mills
Sent: Tuesday, June 12, 2012 11:18 AM
To: Hannes Tschofenig; Julian ReschkeCc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Discussion needed on username = and password ABNF definitions
 
I a= gree generally with your assumption about clients, but rather than saying "= clients are devices" I think it makes much more sense to say "clients are N= OT users, so client_id need not be internationalized".  In practical t= erms there is very little to argue for anythign beyond ASCII in a client_se= cret, base64 encoding or the equivalent being a fine way to transport arbit= rary bits in a portable/reasonable way. 
I argue that = client_id need not be internationalized because I assume that any really in= ternationalized application will have an internationalized presentation lay= er that's presenting a pretty name for the client_id.
 
-bill
<= /div>
 
From= : Hannes Tschofenig <hannes.tschofenig@gmx.net>
To: Julian Reschke <julian.reschke@gmx.de> 
Cc: "oauth@ietf.org" <= oauth@ietf.org> 
Sent: Tuesday, June 12, 2012 11:01 AM
Subject: Re: [OAUTH-WG] Discussion need= ed on username and password ABNF definitions

I had a chat with Julian yesterday and here is= my short summary. 
Section 2.3 of the core draft defines client authentication based on two = mechanisms (and provides room for extensions):http://tools.ietf.org/html/draft-ietf-oauth-v2-27#sec= tion-2.3

1) HTTP Basic Authentication

2) A custom OAuth a= uthentication mechanism (which uses client_id and client_secret)

Wit= h HTTP Basic authentication the problem is that this is a legacy technology= and there is no internationalization support. 

With our brand new custom OAuth authenticatio= n mechanism we have more options.&nbs= p;

One possible approach is to say that the clients are devic= es (and not end users) and therefore internationalization does not matter.<= span class=3D"Apple-converted-space"> 

Is it, however, r= eally true that only US-ASCII characters will appear in the client_id and a= lso in the client_secret? 

Here we have the possibility to define something better. 

In any case we have to res= trict the characters that are used in these two authentication mechanisms s= ince they could conflict with the way how we transport the data over the un= derlying protocol. Julian mentioned this in his previous mails. 

Julian, maybe you can provi= de a detailed text proposal for how to address your comment in case we go f= or UTF8 (with % encoding) for the custom OAuth client authentication mechan= ism? 

Ciao
Hann= es

On Jun 12, 2012, at 11:54 AM, Julian Reschke wrote:

> O= n 2012-06-12 00:16, Mike Jones wrote:
>> Reviewing the feedback fr= om Julian, John, and James, I'm coming to the conclusion that client_id and= client_secret, being for machines and not humans, should be ASCII, whereas= username and password should be Unicode, since they are for humans.  = Per John's feedback, client_id can not contain a colon and be compatible wi= th HTTP Basic.
> > I'm not sure that restricting the character repertoire just because = one way to send requires this is the right approach. My preference would be= not to put this into the ABNF, and just to point out that certain characte= rs will not work over certain transports, and to just advise to avoid them.=
> 
>> The= refore, I'd like to propose these updated ABNF definitions:
>> 
>>    VS= CHAR =3D %20-7E
>>    NOCOLONVSCHAR =3D %x20-39 / %x3B-7= E
>>    UNICODENOCTRLCHAR =3D <Any Unicode character = other than ( %x0-1F / %x7F )>
>> 
>>    client-id =3D *NOCOLONVSCHAR<= br>>>    client_secret =3D *VSCHAR
>> 
>>    username = =3D *UNICODENOCTRLCHAR
>>    password =3D *UNICODENOCTRL= CHAR
> 
> In = this case you should add an introductory statement pointing out that the AB= NF defines the grammar in terms of Unicode code points, not octets (as it i= s the case most of the time).
>=  
>> It turns out that non-ASCII characters are OK for= username and password because the Core spec only passes them in the form b= ody - not using HTTP Basic - and UTF-8 encoding is specified.
> 
> I'll send a separate = mail about that, the current text in the spec is way too unspecific.
>= ; 
>>  &nbs= p;              -- Mike>> 
>> P= .S.  If anyone has a better ABNF for UNICODENOCTRLCHAR than "<Any U= nicode character other than ( %x0-1F / %x7F )>", please send it to me!> 
> As noted = before, here's an example: <http://greenbytes.de/tech/webdav/rfc5323.html#r= fc.section.5.15.1>
>&nbs= p;
> Best regards, Julian
> ____________________________= ___________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/= oauth

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

 

_____________________= __________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oaut= h

=
=0D=0A

=0D=0AThis message and any attachment are intended solely= for the addressee and may=20=0D=0Acontain confidential information. If= you have received this message in error,=20=0D=0Aplease send it back t= o me, and immediately delete it. Please do not use,=20=0D=0Acopy or d= isclose the information contained in this message or in any attachment.= =20=0D=0AAny views or opinions expressed by the author of this email d= o not necessarily=20=0D=0Areflect the views of the University of Nottin= gham.=0D=0A

=0D=0A

=0D=0AThis message has been checked for viruses= but the contents of an attachment=0D=0Amay still contain software viru= ses which could damage your computer system:=0D=0Ayou are advised to pe= rform your own checks. Email communications with the=0D=0AUniversity of= Nottingham may be monitored as permitted by UK legislation.=0D=0A

= = --_000_CDD54A9706724D98B2B4D6C73ED91587exmailnottinghamacuk_-- From wmills@yahoo-inc.com Tue Jun 12 16:19:10 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2176121F8687 for ; Tue, 12 Jun 2012 16:19:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.357 X-Spam-Level: X-Spam-Status: No, score=-17.357 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YhpTd3wKEOoX for ; Tue, 12 Jun 2012 16:19:09 -0700 (PDT) Received: from nm25-vm0.bullet.mail.bf1.yahoo.com (nm25-vm0.bullet.mail.bf1.yahoo.com [98.139.213.156]) by ietfa.amsl.com (Postfix) with SMTP id 5B55F21F867A for ; Tue, 12 Jun 2012 16:19:09 -0700 (PDT) Received: from [98.139.212.144] by nm25.bullet.mail.bf1.yahoo.com with NNFMP; 12 Jun 2012 23:19:08 -0000 Received: from [98.139.212.193] by tm1.bullet.mail.bf1.yahoo.com with NNFMP; 12 Jun 2012 23:19:08 -0000 Received: from [127.0.0.1] by omp1002.mail.bf1.yahoo.com with NNFMP; 12 Jun 2012 23:19:08 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 780915.85523.bm@omp1002.mail.bf1.yahoo.com Received: (qmail 20010 invoked by uid 60001); 12 Jun 2012 23:19:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1339543147; bh=SD4Oawa+nEqOh8C7HzkalgUVlmfvomCkbQbKgrOZGi4=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=dx62GOA8aFTFTUlMp3dU2bMvc4rYChK9l+5CVtIYGa83m4Jifi9BV9XDpcYrVzBF2VNLwrE7kL9Fdrcr366FoNig7obE/DdfZlvlmPHM8TX3Nu6Uc+v+NrmchUCr8qeQLZ3lpzn0FUSNjZ2ZQllvc6D4+WovI73xg+7q6FqA0cA= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=TzBN/Nc0x2eLa78ANs48gGeGvTME+vH9W0H77my7gIXtoGyIBVUXmzdczvrWePGKCJP6h1LNwBjFB17SSEuOE3LP5fqReYvyFTPfxK0hVhPb9uCOIdbJ2blznYrdgeNzTgmpnMUDfhunvpx/aDiumUrQw7LjXyNh3tuK9OXk+wI=; X-YMail-OSG: Og3hNnAVM1lgT5JjOm9AQZmWZznoJE2DlxppVclJ8SA55qc 1BdWzwIpKEQgoR9UpHzJsGSUuqwRLLboX7t38F_8o4IRez32.rtefsDLuIBx rBKyhEoq26kA95Jr3guxuGDxtuoz28M94FNeQ25mvqwrG3Hq0YSlPV2XpBDV ltuT2todgGT75_18bJu8Bd3p0AKjAA9egGRauPoAMAgcD06dufXxNVGHWYjy r1c_IYkeo9NNbzNGw0ZblqIGWYSI9gGB1UlGyvFGlOBHw7AOc1wE8QTi7eop MCOz8woziQM75bgffo9sdSZzdJy1DhMwh51NPjigUp9NEeGrKmRL.wQriLY_ XjouZicTS1Uxnpq4geFKKXZtaecxXFFx7lX5w1.B6J68trc0QJsKFCKvNGJZ ym4gD.KUxsrnDQ7M_vt_THI8a4rrfOmipD11wPjeF8PTlA6ra2SeNOAVrYca A8WdYoOd.lCVV5_KAMwNPSTdwsi4SyfTmjTZfEKzCtETbRB9efXcB1W015Gh .poaxzZKRaEG8laAT1FipFB6vaJzCRgLFO25oLr4.nuJXPsI- Received: from [209.131.62.115] by web31816.mail.mud.yahoo.com via HTTP; Tue, 12 Jun 2012 16:19:07 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.118.349524 References: <6.2.5.6.2.20120612131346.0aaa2d20@resistor.net> Message-ID: <1339543147.10468.YahooMailNeo@web31816.mail.mud.yahoo.com> Date: Tue, 12 Jun 2012 16:19:07 -0700 (PDT) From: William Mills To: "oauth@ietf.org" In-Reply-To: <6.2.5.6.2.20120612131346.0aaa2d20@resistor.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1238014912-491512399-1339543147=:10468" Subject: [OAUTH-WG] Oauth 2 and discovery X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 23:19:10 -0000 ---1238014912-491512399-1339543147=:10468 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable If endpoint discovery is to be via WebFinger (LRDD/XRD) we need there relat= ions defined for the OAuth endpoints=A0 I had that in http://tools.ietf.org= /id/draft-ietf-kitten-sasl-oauth-00.txt section 7.3, but I've ripped all th= e discover stuff out of there.=0A=0AThis seems more appropriate in the OAut= h 2 core spec, but it's really late to put it there.=A0 Should it get added= as part of the WF draft?=A0 As a separate I-D with just the IANA registry = items?=0A=0A-bill=0A ---1238014912-491512399-1339543147=:10468 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
If endpoi= nt discovery is to be via WebFinger (LRDD/XRD) we need there relations defi= ned for the OAuth endpoints  I had that in http://tools.ietf.org/id/dr= aft-ietf-kitten-sasl-oauth-00.txt section 7.3, but I've ripped all the disc= over stuff out of there.

This seems more appropriate in the OAuth 2 = core spec, but it's really late to put it there.  Should it get added = as part of the WF draft?  As a separate I-D with just the IANA registr= y items?

-bill
---1238014912-491512399-1339543147=:10468-- From derek@ihtfp.com Tue Jun 12 17:06:26 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7578E21F86EC for ; Tue, 12 Jun 2012 17:06:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5F5KObK5aMk7 for ; Tue, 12 Jun 2012 17:06:25 -0700 (PDT) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) by ietfa.amsl.com (Postfix) with ESMTP id B80DE21F86C9 for ; Tue, 12 Jun 2012 17:06:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 5DF45260268; Tue, 12 Jun 2012 20:06:24 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 18275-02; Tue, 12 Jun 2012 20:06:22 -0400 (EDT) Received: by mail2.ihtfp.org (Postfix, from userid 48) id E54EC260211; Tue, 12 Jun 2012 20:06:22 -0400 (EDT) Received: from 12.208.167.2 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Tue, 12 Jun 2012 20:06:22 -0400 Message-ID: <75092d0f335c24b6c80bc5ae2f007281.squirrel@mail2.ihtfp.org> In-Reply-To: <1339543147.10468.YahooMailNeo@web31816.mail.mud.yahoo.com> References: <6.2.5.6.2.20120612131346.0aaa2d20@resistor.net> <1339543147.10468.YahooMailNeo@web31816.mail.mud.yahoo.com> Date: Tue, 12 Jun 2012 20:06:22 -0400 From: "Derek Atkins" To: "William Mills" User-Agent: SquirrelMail/1.4.22-2.fc14 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: Maia Mailguard 1.0.2a Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Oauth 2 and discovery X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 00:06:26 -0000 Hi, On Tue, June 12, 2012 7:19 pm, William Mills wrote: > If endpoint discovery is to be via WebFinger (LRDD/XRD) we need there > relations defined for the OAuth endpoints  I had that in > http://tools.ietf.org/id/draft-ietf-kitten-sasl-oauth-00.txt section 7.3, > but I've ripped all the discover stuff out of there. > > This seems more appropriate in the OAuth 2 core spec, but it's really late > to put it there.  Should it get added as part of the WF draft?  As a > separate I-D with just the IANA registry items? I think it's a little late to add this to the core spec now. I would say that you should just write up a separate draft that has the IANA registry items and other ancillary data necessary. It could probably go through as an informational draft, too, and possibly even an individual submission. > -bill -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From wmills@yahoo-inc.com Tue Jun 12 17:12:02 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D00FB11E8098 for ; Tue, 12 Jun 2012 17:12:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.397 X-Spam-Level: X-Spam-Status: No, score=-17.397 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VDyCxuEQc81Y for ; Tue, 12 Jun 2012 17:12:01 -0700 (PDT) Received: from nm18-vm4.bullet.mail.ne1.yahoo.com (nm18-vm4.bullet.mail.ne1.yahoo.com [98.138.91.178]) by ietfa.amsl.com (Postfix) with SMTP id 9578511E8080 for ; Tue, 12 Jun 2012 17:12:01 -0700 (PDT) Received: from [98.138.90.49] by nm18.bullet.mail.ne1.yahoo.com with NNFMP; 13 Jun 2012 00:11:57 -0000 Received: from [98.138.89.166] by tm2.bullet.mail.ne1.yahoo.com with NNFMP; 13 Jun 2012 00:11:57 -0000 Received: from [127.0.0.1] by omp1022.mail.ne1.yahoo.com with NNFMP; 13 Jun 2012 00:11:57 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 779794.62844.bm@omp1022.mail.ne1.yahoo.com Received: (qmail 63709 invoked by uid 60001); 13 Jun 2012 00:11:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1339546317; bh=x/TlOe4GaMtg5v2HDLXM+ybQHDYPBIGf6tD7UuCI+ZY=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=PPTib6hC5uVd3inUzbXFo+jLkpQr3BKv04nNBpS6f9et6XL74XwEMg7/eRqeGChNvwm1vTFQEneKUzRKTmrAaB8XcgNMx7xCWkzC5lCuYRaoXmxqkYrIMOHqpRTd2BuW3Zbhex1jqI1yUv7g0ltQW4vBILMEsQjBtnNqIPEgew8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=FO4EUWrA9RkRCtBJi1BOoEJGwbjAZijg0XRYPEVgEU7EfLzG+wuyvDLLA4VjLRCSMTugWGjH7uU5Ybls/qf4IXJhmaWVH1gr27mOv4KplVGgWmICFMuwwUnsXTf6GpdmEu6YyZwEdjMn5WGqsOZAKicoyv5x0dIwpg+Qdy2sp4k=; X-YMail-OSG: o5OErMwVM1k5FNc7F7EaEM1F6cB6a2mTMY9ggSzMBeLaBLj 8COZJ8cO3jAwTcpaHD0Y5q2JfepOhSgvBSG.dSOmzQeqiQW1_9FVlMKlMnz6 Wxxv__veA4FeHkZTA2MLL7_S0Elmk5NK7m2KWdzW1Ju4ArmTWjZstv_XOzU0 FXsrnsVPT230XXHA_u2Fq57hv1R1AY.g6LxaP8t25B.4WAYgYpZiHx49NtpI CxZfGQYkPsdrggxv_IvJKaEOqv4BYf4BdL22ZGzIhxdnMhXYW2Pxcf0hIx9e rh0tt9fSTdsBJRSzuO6cvPHDANC9yfygpQKHFQhJdmFGkjAkNAbbbAy5gPy3 7nagXZP7LdCcye2onCgMxohsEDYAX.tdXrwGZwHhIj8fAqrP9ZiBvbF4vVTD aAadSrPOqWVO7cCDw2qcAgoOsDpIzqNwVQqVj7j7fHonCuVM.iTanEYMxWBo ktsDzwjd52g6DxUXVSsRC7zCQ71oWYjp28Q.eIHMVoZLS Received: from [209.131.62.115] by web31811.mail.mud.yahoo.com via HTTP; Tue, 12 Jun 2012 17:11:57 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.120.356233 References: <6.2.5.6.2.20120612131346.0aaa2d20@resistor.net> <1339543147.10468.YahooMailNeo@web31816.mail.mud.yahoo.com> <75092d0f335c24b6c80bc5ae2f007281.squirrel@mail2.ihtfp.org> Message-ID: <1339546317.61451.YahooMailNeo@web31811.mail.mud.yahoo.com> Date: Tue, 12 Jun 2012 17:11:57 -0700 (PDT) From: William Mills To: Derek Atkins In-Reply-To: <75092d0f335c24b6c80bc5ae2f007281.squirrel@mail2.ihtfp.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="764183289-1838218494-1339546317=:61451" Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Oauth 2 and discovery X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 00:12:02 -0000 --764183289-1838218494-1339546317=:61451 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable OK.=A0 I'll do that.=A0 Not hard.=A0 =0A=0A=0AWill folks want to discuss th= e individual submission here?=A0 Or will that be in apps-discuss?=0A=0AIs i= t informational if it does IANA registry actions?=0A=0AThanks,=0A=0A-bill= =0A=0A=0A=0A=0A>________________________________=0A> From: Derek Atkins =0A>To: William Mills =0A>Cc: "oauth@i= etf.org" =0A>Sent: Tuesday, June 12, 2012 5:06 PM=0A>Subje= ct: Re: [OAUTH-WG] Oauth 2 and discovery=0A> =0A>Hi,=0A>=0A>On Tue, June 12= , 2012 7:19 pm, William Mills wrote:=0A>> If endpoint discovery is to be vi= a WebFinger (LRDD/XRD) we need there=0A>> relations defined for the OAuth e= ndpoints=A0 I had that in=0A>> http://tools.ietf.org/id/draft-ietf-kitten-s= asl-oauth-00.txt section 7.3,=0A>> but I've ripped all the discover stuff o= ut of there.=0A>>=0A>> This seems more appropriate in the OAuth 2 core spec= , but it's really late=0A>> to put it there.=A0 Should it get added as part= of the WF draft?=A0 As a=0A>> separate I-D with just the IANA registry ite= ms?=0A>=0A>I think it's a little late to add this to the core spec now.=0A>= =0A>I would say that you should just write up a separate draft that has the= =0A>IANA registry items and other ancillary data necessary. It could probab= ly=0A>go through as an informational draft, too, and possibly even an indiv= idual=0A>submission.=0A>=0A>> -bill=0A>=0A>-derek=0A>=0A>-- =0A>=A0 =A0 =A0= Derek Atkins=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 617-623-3745=0A>=A0 =A0 =A0 = derek@ihtfp.com=A0 =A0 =A0 =A0 =A0 =A0 www.ihtfp.com=0A>=A0 =A0 =A0 Comput= er and Internet Security Consultant=0A>=0A>=0A>=0A> --764183289-1838218494-1339546317=:61451 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
OK.  I'll do that.  Not hard. 

<= span>
Will folks want to discuss the individual subm= ission here?  Or will that be in apps-discuss?

Is it informational if it does IANA registry ac= tions?

Thanks,

-bill

<= div dir=3D"ltr">
From: Derek Atkins <derek@ihtfp.= com>
To: William Mi= lls <wmills@yahoo-inc.com>
= Cc: "oauth@ietf.org" <oauth@ietf.org>
Sent: Tuesday, June 12, 2012 5:06 PM
= Subject: Re: [OAUTH-WG] O= auth 2 and discovery

=0AHi,

On Tue, June 12, = 2012 7:19 pm, William Mills wrote:
> If endpoint discovery is to be v= ia WebFinger (LRDD/XRD) we need there
> relations defined for the OAu= th endpoints  I had that in
> http://tools.ietf.org/id/draft-iet= f-kitten-sasl-oauth-00.txt section 7.3,
> but I've ripped all the dis= cover stuff out of there.
>
> This seems more appropriate in th= e OAuth 2 core spec, but it's really late
> to put it there.  Sh= ould it get added as part of the WF draft?  As a
> separate I-D = with just the IANA registry items?

I think it's a little late to add= this to the core spec now.

I would say that you should just write u= p a separate draft that has the
IANA registry items and other ancillary = data necessary. It could probably
go through as an informational draft, = too, and possibly even an individual
submission.

> -bill
-derek

--
      Derek Atkins               = ; 617-623-3745
      derek@ihtfp.com     =       = www.ihtfp.com
      Computer and Internet Security C= onsultant



= --764183289-1838218494-1339546317=:61451-- From torsten@lodderstedt.net Tue Jun 12 22:50:27 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39BEA21F8733 for ; Tue, 12 Jun 2012 22:50:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2bLOnLIbhjY6 for ; Tue, 12 Jun 2012 22:50:25 -0700 (PDT) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.103]) by ietfa.amsl.com (Postfix) with ESMTP id A174221F8731 for ; Tue, 12 Jun 2012 22:50:23 -0700 (PDT) Received: from [80.187.106.61] (helo=[2.164.135.119]) by smtprelay06.ispgateway.de with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.68) (envelope-from ) id 1SegT7-00016S-7f; Wed, 13 Jun 2012 07:50:20 +0200 References: User-Agent: K-9 Mail for Android In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----3O9JJXFD3C0QTU4RMCXANPYE2J3KVL" From: Torsten Lodderstedt Date: Wed, 13 Jun 2012 07:50:02 +0200 To: Jianhua Shao ,Eran Hammer Message-ID: <47d860c2-976a-48f0-90df-feee360d355a@email.android.com> X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Cc: Julian Reschke , Richard Mortier , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion needed on username and password ABNF definitions X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 05:50:27 -0000 ------3O9JJXFD3C0QTU4RMCXANPYE2J3KVL Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi all, can anyone please explain the relation between dynamic client registration and URIs as client ids? None of the current drafts (uma or connect) seem to require URIs. regards, Torsten. Jianhua Shao schrieb: Hello, Dynamic client registration is very useful if client or resource or authorisation server is not permanently available. A typical case is that is the resource or authorisation server is in mobile platform, the connection is not always available. Another typical case is that authorisation server do not necessary to have client pre-registered on itself. At moment, industry like facebook would like developer to register a app on its app centre first, and then ask user auth to use the app. We are researchers from Digital Economy Research Institute. We have this problem When we developing Dataware that could manage the control of access to personal data. We play around our solution base on Oauth2: https://github.com/jianhuashao/dataware.catalog/wiki We are in the list to receive your maillist, but currently need moderate to post any message. cc my colleague, Richard Mortier Best Jian On 12 Jun 2012, at 21:08, Eran Hammer wrote: The only distinction I would make is between removing flexibiliy to proactively enabling future extensibility. I would stop short of perscribing encoding in order to fit uri into the Basic auth fields. But if there is a way to allow this to be less restrictive without clean interop issues, that would be nice. I do agree we need some actual use cases before we spend much more time on this. EH From: William Mills [mailto:wmills@yahoo-inc.com] Sent: Tuesday, June 12, 2012 1:04 PM To: Eran Hammer; Mike Jones; Hannes Tschofenig; Julian Reschke Cc: oauth@ietf.org Subject: Dynamic clients, URI, and stuff Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions I think dynamic client registration is something we have not talked out enough yet. There's a pretty clear use case for dynamic registration. Does identifying the client with a URI allow some form of OpenID-ish flow for this? Is the client ID as a URI a way to allow a trusted site to provide metadata about the client? Is that URI a way to hit an IDP we trust to validate the client in some way with the provided secret? I guess what I'm looking for here is a concrete use case/problem to solve, rather then leaving a hook we think is the right thing. -bill _____________________________________________ From: Eran Hammer To: Mike Jones ; William Mills ; Hannes Tschofenig ; Julian Reschke Cc: "oauth@ietf.org" Sent: Tuesday, June 12, 2012 11:39 AM Subject: RE: [OAUTH-WG] Discussion needed on username and password ABNF definitions Is the use case of using URI as client ids important? It seems like something that might become useful in the future where clients can use their verifiable servers to bypass client registration and simly use a URI the server can validate via some other means. I just want to make sure those thinking about more complex use cases involving dynamic registration or distributed client manamgenet are aware of this potential restriction. I'm fine either way. EH From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones Sent: Tuesday, June 12, 2012 11:27 AM To: William Mills; Hannes Tschofenig; Julian Reschke Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions Not internationalizing fields intended for machine consumption only is already a precedent set and agreed to by the working group, so let me second Bill’s point in that regard. For instance, neither “scope†nor “error†allow non-ASCII characters. Julian, if you want different ABNF text than the text I wrote below, I believe it would be most useful if you would provide the exact replace wording that you’d like to see instead of it. Then there’s no possibility of misunderstanding the intent of suggested changes. Thanks all, -- Mike From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of William Mills Sent: Tuesday, June 12, 2012 11:18 AM To: Hannes Tschofenig; Julian Reschke Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions I agree generally with your assumption about clients, but rather than saying "clients are devices" I think it makes much more sense to say "clients are NOT users, so client_id need not be internationalized". In practical terms there is very little to argue for anythign beyond ASCII in a client_secret, base64 encoding or the equivalent being a fine way to transport arbitrary bits in a portable/reasonable way. I argue that client_id need not be internationalized because I assume that any really internationalized application will have an internationalized presentation layer that's presenting a pretty name for the client_id. -bill _____________________________________________ From: Hannes Tschofenig To: Julian Reschke Cc: "oauth@ietf.org" Sent: Tuesday, June 12, 2012 11:01 AM Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions I had a chat with Julian yesterday and here is my short summary. Section 2.3 of the core draft defines client authentication based on two mechanisms (and provides room for extensions):http://tools.ietf.org/html/draft-ietf-oauth-v2-27#section-2.3 1) HTTP Basic Authentication 2) A custom OAuth authentication mechanism (which uses client_id and client_secret) With HTTP Basic authentication the problem is that this is a legacy technology and there is no internationalization support. With our brand new custom OAuth authentication mechanism we have more options. One possible approach is to say that the clients are devices (and not end users) and therefore internationalization does not matter. Is it, however, really true that only US-ASCII characters will appear in the client_id and also in the client_secret? Here we have the possibility to define something better. In any case we have to restrict the characters that are used in these two authentication mechanisms since they could conflict with the way how we transport the data over the underlying protocol. Julian mentioned this in his previous mails. Julian, maybe you can provide a detailed text proposal for how to address your comment in case we go for UTF8 (with % encoding) for the custom OAuth client authentication mechanism? Ciao Hannes On Jun 12, 2012, at 11:54 AM, Julian Reschke wrote: > On 2012-06-12 00:16, Mike Jones wrote: >> Reviewing the feedback from Julian, John, and James, I'm coming to the conclusion that client_id and client_secret, being for machines and not humans, should be ASCII, whereas username and password should be Unicode, since they are for humans. Per John's feedback, client_id can not contain a colon and be compatible with HTTP Basic. > > I'm not sure that restricting the character repertoire just because one way to send requires this is the right approach. My preference would be not to put this into the ABNF, and just to point out that certain characters will not work over certain transports, and to just advise to avoid them. > >> Therefore, I'd like to propose these updated ABNF definitions: >> >> VSCHAR = %20-7E >> NOCOLONVSCHAR = %x20-39 / %x3B-7E >> UNICODENOCTRLCHAR = >> >> client-id = *NOCOLONVSCHAR >> client_secret = *VSCHAR >> >> username = *UNICODENOCTRLCHAR >> password = *UNICODENOCTRLCHAR > > In this case you should add an introductory statement pointing out that the ABNF defines the grammar in terms of Unicode code points, not octets (as it is the case most of the time). > >> It turns out that non-ASCII characters are OK for username and password because the Core spec only passes them in the form body - not using HTTP Basic - and UTF-8 encoding is specified. > > I'll send a separate mail about that, the current text in the spec is way too unspecific. > >> -- Mike >> >> P.S. If anyone has a better ABNF for UNICODENOCTRLCHAR than "", please send it to me! > > As noted before, here's an example: > > Best regards, Julian > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ------3O9JJXFD3C0QTU4RMCXANPYE2J3KVL Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi all,

can anyone please explain the relation between dynamic client registration and URIs as client ids? None of the current drafts (uma or connect) seem to require URIs.

regards,
Torsten.



Jianhua Shao <psxjs4@nottingham.ac.uk> schrieb:
Hello,

Dynamic client registration is very useful if client or resource or authorisation server is not permanently available. 
A typical case is that is the resource or authorisation server is in mobile platform, the connection is not always available. 
Another typical case is that authorisation server do not necessary to have client pre-registered on itself. At moment, industry like facebook would like developer to register a app on its app centre first, and then ask user auth to use the app. 

We are researchers from Digital Economy Research Institute. We have this problem When we developing Dataware that could manage the control of access to personal data. We play around our solution base on Oauth2: https://github.com/jianhuashao/dataware.catalog/wiki

We are in the list to receive your mail list, but currently need moderate to post any message. cc my colleague, Richard Mortier
Best
Jian


On 12 Jun 2012, at 21:08, Eran Hammer wrote:

The only distinction I would make is between removing flexibiliy to proactively enabling future extensibility. I would stop short of perscribing encoding in order to fit uri into the Basic auth fields. But if there is a way to allow this to be less restrictive without clean interop issues, that would be nice.
 
I do agree we need some actual use cases before we spend much more time on this.
 
EH
 
From: William Mills [mailto:wmills@yahoo-inc.com] 
Sent: Tuesday, June 12, 2012 1:04 PM
To: Eran Hammer; Mike Jones; Hannes Tschofenig; Julian Reschke
Cc: oauth@ietf.org
Subject: Dynamic clients, URI, and stuff Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions
 
I think dynamic client registration is something we have not talked out enough yet.  There's a pretty clear use case for dynamic registration.  
 
Does identifying the client with a URI allow some form of OpenID-ish flow for this? 
Is the client ID as a URI a way to allow a trusted site to provide metadata about the client?
Is that URI a way to hit an IDP we trust to validate the client in some way with the provided secret?
 
I guess what I'm looking for here is a concrete use case/problem to solve, rather then leaving a hook we think is the right thing.
 
-bill
 
 
From: Eran Hammer <eran@hueniverse.com>
To: Mike Jones <Michael.Jones@microsoft.com>; William Mills <wmills@yahoo-inc.com>; Hannes Tschofenig <hannes.tschofenig@gmx.net>; Julian Reschke <julian.reschke@gmx.de> 
Cc: "oauth@ietf.org" <oauth@ietf.org> 
Sent: Tuesday, June 12, 2012 11:39 AM
Subject: RE: [OAUTH-WG] Discussion needed on username and password ABNF definitions
 
Is the use case of using URI as client ids important? It seems like something that might become useful in the future where clients can use their verifiable servers to bypass client registration and simly use a URI the server can validate via some other means.
 
I just want to make sure those thinking about more complex use cases involving dynamic registration or distri buted client manamgenet are aware of this potential restriction.
 
I'm fine either way.
 
EH
 
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Tuesday, June 12, 2012 11:27 AM
To: William Mills; Hannes Tschofenig; Julian Reschke
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions
 
Not internationalizing fields intended for machine consumption only is already a precedent set and agreed to by the working group, so let me second Bill’s point in that regard.  For instance, neither “scope†nor “error†allow non-ASCII characters.
 
Julian, if you want different ABNF text than the text I wrote below, I believe it would be most useful if you would provide the exact replace wording that you’d like to see instead of it.  Then there’s no possibility of misunderstanding the intent of suggested changes.
 
                                                            Thanks all,
                                                            -- Mike
 
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of William Mills
Sent: Tuesday, June 12, 2012 11:18 AM
To: Hannes Tschofenig; Julian Reschke
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions
 
I agree generally with your assumption about clients, but rather than saying "clients are devices" I think it makes much more sense to say "clients are NOT users, so client_id need not be internationalized".  In practical terms there is very little to argue for anythign beyond ASCII in a client_secret, base64 encoding or the equivalent being a fine way to transport arbitrary bits in a portable/reasonable way.
 
I argue that client_id need not be internationalized because I assume that any really internationalized application will have an internationalized presentation layer that's presenting a pretty name for the client_id.
 
-bill
 
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
To: Julian Reschke <julian.reschke@gmx.de> 
Cc: "oauth@ietf.org" <oauth@ietf.org> 
Sent: Tuesday, June 12, 2012 11:01 AM
Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions

I had a chat with Julian yesterday and here is my short summary. 

Section 2.3 of the core draft defines client authentication based on two mechanisms (and provides room for extensions):http://tools.ietf.org/html/draft-ietf-oauth-v2-27#section-2.3

1) HTTP Basic Authentication

2) A custom OAuth authentication mechanism (which uses client_id and client_secret)

With HTTP Basic authentication the problem is that this is a legacy technology and there is no internationalization support. 

With our brand new custom OAuth authentication mechanism we have more options. 

One possible approach is to say that the clients are devices (and not end users) and therefore internationalization does not matter. 

Is it, however, really true that only US-ASCII characters will appear in the client_id and also in the client_secret? 

Here we have the possibility to define something better. 

In any case we have to restrict the characters that are used in these two authentication mechanisms since they could conflict with the way how we transport the data over the underlying protocol. Julian mentioned this in his previous mails. 

Julian, maybe you can provide a detailed text proposal for how to address your comment in case we go for UTF8 (with % encoding) for the custom OAuth client authentication mechanism? 

Ciao
Hannes

On Jun 12, 2012, at 11:54 AM, Julian Reschke wrote:

> On 2012-06-12 00:16, Mike Jones wrote:
>> Reviewing the feedback from Julian, John, and James, I'm coming to the conclusion that client_id and client_secret, being for machines and not humans, shou ld be ASCII, whereas username and password should be Unicode, since they are for humans.  Per John's feedback, client_id can not contain a colon and be compatible with HTTP Basic.
> 
> I'm not sure that restricting the character repertoire just because one way to send requires this is the right approach. My preference would be not to put this into the ABNF, and just to point out that certain characters will not work over certain transports, and to just advise to avoid them.
> 
>> Therefore, I'd like to propose these updated ABNF definitions:
>> 
>>    VSCHAR = %20-7E
>>    NOCOLONVSCHAR = %x20-39 / %x3B-7E
>>    UNICODENOCTRLCHAR = <Any Unicode character other than ( %x0-1F / %x7F )>
>> 
>>    client-id = *NOCOLONVSCHAR
>>    client_secret = *VSCHAR
>> 
>>    username = *UNICODENOCTRLCHAR
>>    password = *UNICODENOCTRLCHAR
> 
> In this case you should add an introductory statement pointing out that the ABNF defines the grammar in terms of Unicode code points, not octets (as it is the case most of the time).
> 
>> It turns out that non-ASCII characters are OK for username and password because the Core spec only passes them in the form body - not using HTTP Basic - and UTF-8 encoding is specified.
> 
> I'll send a separate mail about that, the current text in the spec is way too unspecific.
> 
>>                 -- Mike
>> 
>> P.S.  If anyone has a better ABNF for UNICODENOCTRLCHAR than "<Any Unicode character other than ( %x0-1F / %x7F )>", please send it to me!
> 
> As noted before, here's an example: <http://greenbytes.de/tech/webdav/rfc5323.html#rfc.section.5.15.1>
> 
> Best regards, Julian
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

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

 

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

This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham.

This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.

------3O9JJXFD3C0QTU4RMCXANPYE2J3KVL-- From torsten@lodderstedt.net Tue Jun 12 23:02:01 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EA1A21F8745 for ; Tue, 12 Jun 2012 23:02:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uTRT4B+87s3o for ; Tue, 12 Jun 2012 23:02:00 -0700 (PDT) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.18.16]) by ietfa.amsl.com (Postfix) with ESMTP id 7AC9721F8744 for ; Tue, 12 Jun 2012 23:01:59 -0700 (PDT) Received: from [80.187.106.61] (helo=[2.164.135.119]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.68) (envelope-from ) id 1SegeR-0002Fz-Uk; Wed, 13 Jun 2012 08:01:56 +0200 References: <4FD65080.9040305@gmail.com> <4FD65ED8.6000507@aol.com> <4FD745EE.1040508@mitre.org> User-Agent: K-9 Mail for Android In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----R0O62SLF22ROKTKF3V4ASLJ5276QK0" From: Torsten Lodderstedt Date: Wed, 13 Jun 2012 08:01:26 +0200 To: doug foiles , Justin Richer , sDronia@gmx.de, mscurtescu@google.com Message-ID: X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Clarification in Section 2.0 of draft-ietf-oauth-revocation-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 06:02:01 -0000 ------R0O62SLF22ROKTKF3V4ASLJ5276QK0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi all, we should probably adopt the wording to refer to the access grant underlying all tokens? Something like: "based on the same access grant ...". What do you think? regards, Torsten. doug foiles schrieb: Thanks Justin. Perhaps we can get Torsten, Stefanie, or Marius to comment on what was intended for this ... and would be much appreciated. On Tue, Jun 12, 2012 at 6:36 AM, Justin Richer wrote: I agree with Doug and George's reading: nuking the refresh token gets rid of all access tokens associated with that refresh token's lifetime. This includes both simultaneous issuance as well as derived issuance. -- Justin On 06/11/2012 08:13 PM, doug foiles wrote: Hi Paul and George, Even though the Access Token is short lived, I would still like to revoke it immediately if the user chooses to revoke the Refresh Token. And I would love for the client application to only have to make one web service call to accomplish that and not one for the Refresh Token and another for the Access Token. Given that we always generate a new Refresh Token value during "Token Refresh", we would never have a true parent / child relationship between a Refresh Token and Access Token. Is there a case where it is NOT appropriate to revoke an "associated" Access Token when explictly revoking a Refresh Token? I define "associated" as an Access Token generated from a Refresh Token OR generated at the same time of the Refresh Token. I do see the AS challenges in trying to manage multiple simultaneous "associated" Access Tokens. For example let's say a client generates multiple Access Tokens at the same time while generating new Refresh Token values during each "Token Refresh" operation. However I don't really see the useful of this case. Doug On Mon, Jun 11, 2012 at 3:52 PM, Paul Madsen wrote: Hi George, perhaps it depends on the reason for the refresh token being revoked. If because the user removed their consent then yes I agree that *all* tokens should be revoked Sent from my iPhone On 2012-06-11, at 5:10 PM, George Fletcher wrote: Paul, I think I came to a different conclusion... If I use the Resource Owner Password Credential flow and get back both an access_token and a refresh_token then I would assume that the issued access_token is tied in some way to the refresh_token. If the refresh_token is revoked, then my expectation is that the simultaneous issued access_token would also be revoked. I read the spec as having a typo that should read... If the processed token is a refresh token and the authorization server supports the revocation of access tokens, then the authorization server SHOULD also invalidate all access tokens issued *based on* that refresh token.Or maybe better... "invalidate all access tokens associated/tied-to that refresh token". Now in the case that the client is retrieving a new refresh_token and access_token, then the new ones should be valid and the old ones potentially revoked. Thanks, George On 6/11/12 4:09 PM, Paul Madsen wrote: Hi Doug, my interpretation is that 'for that refresh token' means those access tokens issued in exchange for that refresh token. Consequently, for the cases you cite below, the access tokens at the same time as a given refresh token need not be invalidated when that refresh token is 'processed' I assume the justification for the rule is that an access token issued in exchange for a given refresh token may have been compromised if the refresh token had been. But there is no such causal relationship between an access token & refresh token issued at same time paul On 6/11/12 3:31 PM, doug foiles wrote: Hi all, I was hoping to get some clarity on a statement in section 2.0 of draft-ietf-oauth-revocation-00. 　　 If the processed token is a refresh token and the authorization 　　 server supports the revocation of access tokens, then the 　　 authorization server SHOULD also invalidate all access tokens issued 　　 for that refresh token. My question is on the statement "access tokens issued for that refresh token".　 What does it mean to have an Access Token "issued" for a Refresh Token?　 This specific case is clear to me.　 I am refreshing an Access Token where I keep the same Refresh Token that I used to generate the new Access Token.　 I see the new Access Token was issued for that Refresh Token. However these two cases are a bit muddy to me.　 Let’s say I am using the "Resource Owner Password Credentials Grant" where the Access Token Response returns both an Access Token and Refresh Token.　 Would the Access Token have been issued for that Refresh Token?　 And let’s say I am refreshing an Access Token but choose to create a new Refresh Token and immediately revoke the original Refresh Token.　 Would the newly created Access Token have been issued for the original Refresh Token or the new one that was created. If a client would revoke a Refresh Token … I would like the Access Tokens in all of the above cases to be automatically revoked as well.　 I just want to make sure I understand the model.　 Thanks. Doug Foiles Intuit _______________________________________________ OAuth mailing 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 ------R0O62SLF22ROKTKF3V4ASLJ5276QK0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi all,

we should probably adopt the wording to refer to the access grant underlying all tokens? Something like: "based on the same access grant ...".

What do you think?

regards,
Torsten.



doug foiles <doug.foiles@gmail.com> schrieb:
Thanks Justin.  Perhaps we can get Torsten, Stefanie, or Marius to comment on what was intended for this ... and would be much appreciated.

On Tue, Jun 12, 2012 at 6:36 AM, Justin Richer <jricher@mitre.org> wrote:
I agree with Doug and George's reading: nuking the refresh token gets rid of all access tokens associated with that refresh token's lifetime. This includes both simultaneous issuance as well as derived issuance.

 -- Justin


On 06/11/2012 08:13 PM, doug foiles wrote:
Hi Paul and George,
 
Even though the Access Token is short lived, I would still like to revoke it immediately if the user chooses to revoke the Refresh Token.  And I would love for the client application to only have to make one web service call to accomplish that and not one for the Refresh Token and another for the Access Token.
 
Given that we always generate a new Refresh Token value during "Token Refresh", we would never have a true parent / child relationship between a Refresh Token and Access Token.
 
Is there a case where it is NOT appropriate to revoke an "associated" Access Token when explictly revoking a Refresh Token?  I define "associated" as an Access Token generated from a Refresh Token OR generated at the same time of the Refresh Token.
 
I do see the AS challenges in trying to manage multiple simultaneous "associated" Access Tokens.  For example let's say a client generates multiple Access Tokens at the same time while generating new Refresh Token values during each "Token Refresh" operation.  However I don't really see the useful of this case.
 
Doug

On Mon, Jun 11, 2012 at 3:52 PM, Paul Madsen <paul.madsen@gmail.com> wrote:
Hi George, perhaps it depends on the reason for the refresh token being revoked. If because the user removed their consent then yes I agree that *all* tokens should be revoked

Sent from my iPhone

On 2012-06-11, at 5:10 PM, George Fletcher <gffletch@aol.com> wrote:

Paul,

I think I came to a different conclusion...

If I use the Resource Owner Password Credential flow and get back both an access_token and a refresh_token then I would assume that the issued access_token is tied in some way to the refresh_token. If the refresh_token is revoked, then my expectation is that the simultaneous issued access_token would also be revoked.

I read the spec as having a typo that should read...
If the processed token is a refresh token and the authorization
server supports the revocation of access tokens, then the
authorization server SHOULD also invalidate all access tokens issued
*based on* that refresh token.
Or maybe better... "invalidate all access tokens associated/tied-to that refresh token".

Now in the case that the client is retrieving a new refresh_token and access_token, then the new ones should be valid and the old ones potentially revoked.

Thanks,
George

On 6/11/12 4:09 PM, Paul Madsen wrote:
Hi Doug, my interpretation is that 'for that refresh token' means those access tokens issued in exchange for that refresh token.

Consequently, for the cases you cite below, the access tokens at the same time as a given refresh token need not be invalidated when that refresh token is 'processed'

I assume the justification for the rule is that an access token issued in exchange for a given refresh token may have been compromised if the refresh token had been. But there is no such causal relationship between an access token & refresh token issued at same time

paul

On 6/11/12 3:31 PM, doug foiles wrote:
Hi all,

I was hoping to get some clarity on a statement in section 2.0 of draft-ietf-oauth-revocation-00.

　　 If the processed token is a refresh token and the authorization
　　 server supports the revocation of access tokens, then the
　　 authorization server SHOULD also invalidate all access tokens issued
　　 for that refresh token.

My question is on the statement "access tokens issued for that refresh token".　 What does it mean to have an Access Token "issued" for a Refresh Token?　

This specific case is clear to me.　 I am refreshing an Access Token where I keep the same Refresh Token that I used to generate the new Access Token.　 I see the new Access Token was issued for that Refresh Token.
However these two cases are a bit muddy to me.　 Let’s say I am using the "Resource Owner Password Credentials Grant" where the Access Token Response returns both an Access Token and Refresh Token.　 Would the Access Token have been issued for that Refresh Token?　 And let’s say I am refreshing an Access Token but choose to create a new Refresh Token and immediately revoke the original Refresh Token.　 Would the newly created Access Token have been issued for the original Refresh Token or the new one that was created.
If a client would revoke a Refresh Token … I would like the Access Tokens in all of the above cases to be automatically revoked as well.　 I just want to make sure I understand the model.　 Thanks.
Doug Foiles
Intuit

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


------R0O62SLF22ROKTKF3V4ASLJ5276QK0-- From paul.madsen@gmail.com Wed Jun 13 02:44:00 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 665CF21F867A for ; Wed, 13 Jun 2012 02:44:00 -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 k+EnLaEdLZNf for ; Wed, 13 Jun 2012 02:43:59 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id CEB6121F8679 for ; Wed, 13 Jun 2012 02:43:58 -0700 (PDT) Received: by vcqp1 with SMTP id p1so231801vcq.31 for ; Wed, 13 Jun 2012 02:43:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=Qrh5tFjiqJ3sDMBJ0eDZB9N2uZHJeakkcfsqfRqc6J4=; b=n1QCt2ckojc22BYjsIMPf+L1Bx3sFkNO2khxEVlUIq+rQ4w8NOEwE0vanA/fD3BgEK /3MRNaGWmKPkSu4I9rYj4oLU9OvKovrH2ppiJw2e/DdixD76V92rWk0ap6cVU7Akfmu5 eERpzwpFlwBn/kkd7twX74ffZynbxTOFRfWXVdyDSHxupY+eubPMMOAWgPkWh3VAF/pu n+psObdiDRE8rkya2hHHyTO+wXLciqv8Q9BPczmJrJE/C5FMX5DdNGcDL1HTsKiEZdiC /ooLwr7Xef7RCcg6C3lSAefTAuiWeYV6CLHsT2r1HbFb18LDWgGt1C8Zxnkw1e/uVk9J z5lQ== Received: by 10.220.16.8 with SMTP id m8mr16564075vca.10.1339580638074; Wed, 13 Jun 2012 02:43:58 -0700 (PDT) Received: from pmadsen-mbp.local (CPE0022b0cb82b4-CM0012256eb4b4.cpe.net.cable.rogers.com. [99.224.20.155]) by mx.google.com with ESMTPS id i10sm1058983vdw.21.2012.06.13.02.43.54 (version=SSLv3 cipher=OTHER); Wed, 13 Jun 2012 02:43:55 -0700 (PDT) Message-ID: <4FD860D9.7010007@gmail.com> Date: Wed, 13 Jun 2012 05:43:53 -0400 From: Paul Madsen User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.28) Gecko/20120306 Thunderbird/3.1.20 MIME-Version: 1.0 To: Torsten Lodderstedt References: <4FD65080.9040305@gmail.com> <4FD65ED8.6000507@aol.com> <4FD745EE.1040508@mitre.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010909010602080803070806" Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Clarification in Section 2.0 of draft-ietf-oauth-revocation-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 09:44:00 -0000 This is a multi-part message in MIME format. --------------010909010602080803070806 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit agree that it'd be preferable to refer to the higher level grant related, the spec stipulates 'The client MUST NOT make any assumptions about the timing and MUST NOT use the token again.' So what does the client do with it's existing access token when it revokes the associated refresh token? The rule indicating to the AS that access tokens be revoked as well is only a SHOULD, so the client can't be certain that the access token is 'bad' paul On 6/13/12 2:01 AM, Torsten Lodderstedt wrote: > Hi all, > > we should probably adopt the wording to refer to the access grant > underlying all tokens? Something like: "based on the same access grant > ...". > > What do you think? > > regards, > Torsten. > > > > doug foiles schrieb: > > Thanks Justin. Perhaps we can get Torsten, Stefanie, or Marius to > comment on what was intended for this ... and would be much > appreciated. > > On Tue, Jun 12, 2012 at 6:36 AM, Justin Richer > wrote: > > I agree with Doug and George's reading: nuking the refresh > token gets rid of all access tokens associated with that > refresh token's lifetime. This includes both simultaneous > issuance as well as derived issuance. > > -- Justin > > > On 06/11/2012 08:13 PM, doug foiles wrote: >> Hi Paul and George, >> Even though the Access Token is short lived, I would still >> like to revoke it immediately if the user chooses to revoke >> the Refresh Token. And I would love for the client >> application to only have to make one web service call to >> accomplish that and not one for the Refresh Token and another >> for the Access Token. >> Given that we always generate a new Refresh Token value >> during "Token Refresh", we would never have a true parent / >> child relationship between a Refresh Token and Access Token. >> Is there a case where it is NOT appropriate to revoke an >> "associated" Access Token when explictly revoking a Refresh >> Token? I define "associated" as an Access Token generated >> from a Refresh Token OR generated at the same time of the >> Refresh Token. >> I do see the AS challenges in trying to manage multiple >> simultaneous "associated" Access Tokens. For example let's >> say a client generates multiple Access Tokens at the same >> time while generating new Refresh Token values during each >> "Token Refresh" operation. However I don't really see the >> useful of this case. >> Doug >> >> On Mon, Jun 11, 2012 at 3:52 PM, Paul Madsen >> > wrote: >> >> Hi George, perhaps it depends on the reason for the >> refresh token being revoked. If because the user removed >> their consent then yes I agree that *all* tokens should >> be revoked >> >> Sent from my iPhone >> >> On 2012-06-11, at 5:10 PM, George Fletcher >> > wrote: >> >>> Paul, >>> >>> I think I came to a different conclusion... >>> >>> If I use the Resource Owner Password Credential flow and >>> get back both an access_token and a refresh_token then I >>> would assume that the issued access_token is tied in >>> some way to the refresh_token. If the refresh_token is >>> revoked, then my expectation is that the simultaneous >>> issued access_token would also be revoked. >>> >>> I read the spec as having a typo that should read... >>> If the processed token is a refresh token and the authorization >>> server supports the revocation of access tokens, then the >>> authorization server SHOULD also invalidate all access tokens issued >>> *based on* that refresh token. >>> Or maybe better... "invalidate all access tokens >>> associated/tied-to that refresh token". >>> >>> Now in the case that the client is retrieving a new >>> refresh_token and access_token, then the new ones should >>> be valid and the old ones potentially revoked. >>> >>> Thanks, >>> George >>> >>> On 6/11/12 4:09 PM, Paul Madsen wrote: >>>> Hi Doug, my interpretation is that 'for that refresh >>>> token' means those access tokens issued in exchange for >>>> that refresh token. >>>> >>>> Consequently, for the cases you cite below, the access >>>> tokens at the same time as a given refresh token need >>>> not be invalidated when that refresh token is 'processed' >>>> >>>> I assume the justification for the rule is that an >>>> access token issued in exchange for a given refresh >>>> token may have been compromised if the refresh token >>>> had been. But there is no such causal relationship >>>> between an access token & refresh token issued at same time >>>> >>>> paul >>>> >>>> On 6/11/12 3:31 PM, doug foiles wrote: >>>>> Hi all, >>>>> >>>>> I was hoping to get some clarity on a statement in >>>>> section 2.0 of draft-ietf-oauth-revocation-00. >>>>> >>>>> 　　 If the processed token is a refresh token and the >>>>> authorization >>>>> 　　 server supports the revocation of access tokens, >>>>> then the >>>>> 　　 authorization server SHOULD also invalidate all >>>>> access tokens issued >>>>> 　　 for that refresh token. >>>>> >>>>> My question is on the statement "access tokens issued >>>>> for that refresh token".　 What does it mean to have >>>>> an Access Token "issued" for a Refresh Token?　 >>>>> >>>>> This specific case is clear to me.　 I am refreshing >>>>> an Access Token where I keep the same Refresh Token >>>>> that I used to generate the new Access Token.　 I see >>>>> the new Access Token was issued for that Refresh Token. >>>>> However these two cases are a bit muddy to me.　 Let’s >>>>> say I am using the "Resource Owner Password >>>>> Credentials Grant" where the Access Token Response >>>>> returns both an Access Token and Refresh Token.　 >>>>> Would the Access Token have been issued for that >>>>> Refresh Token?　 And let’s say I am refreshing an >>>>> Access Token but choose to create a new Refresh Token >>>>> and immediately revoke the original Refresh Token.　 >>>>> Would the newly created Access Token have been issued >>>>> for the original Refresh Token or the new one that was >>>>> created. >>>>> If a client would revoke a Refresh Token … I would >>>>> like the Access Tokens in all of the above cases to be >>>>> automatically revoked as well.　 I just want to make >>>>> sure I understand the model.　 Thanks. >>>>> Doug Foiles >>>>> Intuit >>>>> >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing 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 --------------010909010602080803070806 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit agree that it'd be preferable to refer to the higher level grant

related, the spec stipulates

'The client MUST NOT make any assumptions about the timing and MUST NOT use the token again.'

So what does the client do with it's existing access token when it revokes the associated refresh token?

The rule indicating to the AS that access tokens be revoked as well is only a SHOULD, so the client can't be certain that the access token is 'bad'

paul

On 6/13/12 2:01 AM, Torsten Lodderstedt wrote:
Hi all,

we should probably adopt the wording to refer to the access grant underlying all tokens? Something like: "based on the same access grant ...".

What do you think?

regards,
Torsten.



doug foiles <doug.foiles@gmail.com> schrieb:
Thanks Justin.  Perhaps we can get Torsten, Stefanie, or Marius to comment on what was intended for this ... and would be much appreciated.

On Tue, Jun 12, 2012 at 6:36 AM, Justin Richer <jricher@mitre.org> wrote:
I agree with Doug and George's reading: nuking the refresh token gets rid of all access tokens associated with that refresh token's lifetime. This includes both simultaneous issuance as well as derived issuance.

 -- Justin


On 06/11/2012 08:13 PM, doug foiles wrote:
Hi Paul and George,
 
Even though the Access Token is short lived, I would still like to revoke it immediately if the user chooses to revoke the Refresh Token.  And I would love for the client application to only have to make one web service call to accomplish that and not one for the Refresh Token and another for the Access Token.
 
Given that we always generate a new Refresh Token value during "Token Refresh", we would never have a true parent / child relationship between a Refresh Token and Access Token.
 
Is there a case where it is NOT appropriate to revoke an "associated" Access Token when explictly revoking a Refresh Token?  I define "associated" as an Access Token generated from a Refresh Token OR generated at the same time of the Refresh Token.
 
I do see the AS challenges in trying to manage multiple simultaneous "associated" Access Tokens.  For example let's say a client generates multiple Access Tokens at the same time while generating new Refresh Token values during each "Token Refresh" operation.  However I don't really see the useful of this case.
 
Doug

On Mon, Jun 11, 2012 at 3:52 PM, Paul Madsen <paul.madsen@gmail.com> wrote:
Hi George, perhaps it depends on the reason for the refresh token being revoked. If because the user removed their consent then yes I agree that *all* tokens should be revoked

Sent from my iPhone

On 2012-06-11, at 5:10 PM, George Fletcher <gffletch@aol.com> wrote:

Paul,

I think I came to a different conclusion...

If I use the Resource Owner Password Credential flow and get back both an access_token and a refresh_token then I would assume that the issued access_token is tied in some way to the refresh_token. If the refresh_token is revoked, then my expectation is that the simultaneous issued access_token would also be revoked.

I read the spec as having a typo that should read...
If the processed token is a refresh token and the authorization
server supports the revocation of access tokens, then the
authorization server SHOULD also invalidate all access tokens issued
*based on* that refresh token.
Or maybe better... "invalidate all access tokens associated/tied-to that refresh token".

Now in the case that the client is retrieving a new refresh_token and access_token, then the new ones should be valid and the old ones potentially revoked.

Thanks,
George

On 6/11/12 4:09 PM, Paul Madsen wrote:
Hi Doug, my interpretation is that 'for that refresh token' means those access tokens issued in exchange for that refresh token.

Consequently, for the cases you cite below, the access tokens at the same time as a given refresh token need not be invalidated when that refresh token is 'processed'

I assume the justification for the rule is that an access token issued in exchange for a given refresh token may have been compromised if the refresh token had been. But there is no such causal relationship between an access token & refresh token issued at same time

paul

On 6/11/12 3:31 PM, doug foiles wrote:
Hi all,

I was hoping to get some clarity on a statement in section 2.0 of draft-ietf-oauth-revocation-00.

　　 If the processed token is a refresh token and the authorization
　　 server supports the revocation of access tokens, then the
　　 authorization server SHOULD also invalidate all access tokens issued
　　 for that refresh token.

My question is on the statement "access tokens issued for that refresh token".　 What does it mean to have an Access Token "issued" for a Refresh Token?　

This specific case is clear to me.　 I am refreshing an Access Token where I keep the same Refresh Token that I used to generate the new Access Token.　 I see the new Access Token was issued for that Refresh Token.
However these two cases are a bit muddy to me.　 Let’s say I am using the "Resource Owner Password Credentials Grant" where the Access Token Response returns both an Access Token and Refresh Token.　 Would the Access Token have been issued for that Refresh Token?　 And let’s say I am refreshing an Access Token but choose to create a new Refresh Token and immediately revoke the original Refresh Token.　 Would the newly created Access Token have been issued for the original Refresh Token or the new one that was created.
If a client would revoke a Refresh Token … I would like the Access Tokens in all of the above cases to be automatically revoked as well.　 I just want to make sure I understand the model.　 Thanks.
Doug Foiles
Intuit

_______________________________________________
OAuth mailing 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
--------------010909010602080803070806-- From ve7jtb@ve7jtb.com Wed Jun 13 03:56:52 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8154121F8474 for ; Wed, 13 Jun 2012 03:56:52 -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 NTbed4o6mSg7 for ; Wed, 13 Jun 2012 03:56:50 -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 5743921F846F for ; Wed, 13 Jun 2012 03:56:50 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so2146366pbc.31 for ; Wed, 13 Jun 2012 03:56:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=o9ygaXFv/Zm7iujcwe5VlGdQt4Q7s5Rh2Lpc0SauN6A=; b=DZcIv72sDc8MRQqgXSAK+ZyuazHyeA9mLpscpu/IEkSW7xD/yWvREIm7ki2HrML4rU 95pvdQO/0nZtMvWYHsR0Udno8JmDocrxq3jNoCNqulBDMgX81cVO9TaZfErZdqqYecdN b7KL2GzAtZxN/o5kMauHB6q0zLq8aomQC/pMtqQStSs5wm2vHG9czrPd8EdXBNMS1nMs x1zEBxBHirWaZRcqT7APOMoqD9iGcXTwe+hjBr2JYDDQnqRG5lkxlwK7cXRJ/mky4g+C PD+y9oschMR/77O88ZLSTbOg8wkZnVGw9p0jftlBWA4LetuOIPeisHHrJWEQWYKL9NMn 7KRg== Received: by 10.68.217.229 with SMTP id pb5mr31291749pbc.20.1339585009732; Wed, 13 Jun 2012 03:56:49 -0700 (PDT) Received: from [10.39.187.184] (69-90.83-90.static-ip.oleane.fr. [90.83.90.69]) by mx.google.com with ESMTPS id qn1sm5394437pbc.9.2012.06.13.03.56.45 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 13 Jun 2012 03:56:48 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_93AC71F0-B584-4478-A048-01D58B53AC0A" From: John Bradley In-Reply-To: <47d860c2-976a-48f0-90df-feee360d355a@email.android.com> Date: Wed, 13 Jun 2012 12:56:42 +0200 Message-Id: <89A82128-52B0-4EB4-B16F-69ED51262DB2@ve7jtb.com> References: <47d860c2-976a-48f0-90df-feee360d355a@email.android.com> To: Torsten Lodderstedt X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQnwcoiNZ8DO8lFBoPkhHAoFRfW5poEG9yMIrFDKhGJtcEV6r5rig3uS4TX4XEjKT2GTji0j Cc: Julian Reschke , Richard Mortier , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion needed on username and password ABNF definitions X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 10:56:52 -0000 --Apple-Mail=_93AC71F0-B584-4478-A048-01D58B53AC0A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I think that the issues are getting confused. There is a use case where the Authorization server may be a embedded = app, at least in one openID case. As it won't have a separate = registration or token endpoint, the client needs to make its own = clientID for the request. A reasonable thing to use is the redirect = URI to create a unique value that the user could use for revocation at a = later point. Currently with the no : restriction we would use the host and path to = crate the clientid. There are some scenarios where having the scheme as part of that would = be helpful. This has nothing to do with discovery or the dynamic client registration = proposal as far as I know. A URL as a client_id comes from prototype work for a personal provider = that we are doing as part of openID Connect. John B. On 2012-06-13, at 7:50 AM, Torsten Lodderstedt wrote: > Hi all, >=20 > can anyone please explain the relation between dynamic client = registration and URIs as client ids? None of the current drafts (uma or = connect) seem to require URIs. >=20 > regards, > Torsten. >=20 >=20 >=20 > Jianhua Shao schrieb: > Hello, >=20 > Dynamic client registration is very useful if client or resource or = authorisation server is not permanently available.=20 > A typical case is that is the resource or authorisation server is in = mobile platform, the connection is not always available.=20 > Another typical case is that authorisation server do not necessary to = have client pre-registered on itself. At moment, industry like facebook = would like developer to register a app on its app centre first, and then = ask user auth to use the app.=20 >=20 > We are researchers from Digital Economy Research Institute. We have = this problem When we developing Dataware that could manage the control = of access to personal data. We play around our solution base on Oauth2: = https://github.com/jianhuashao/dataware.catalog/wiki >=20 > We are in the list to receive your mail list, but currently need = moderate to post any message. cc my colleague, Richard Mortier > Best > Jian >=20 >=20 > On 12 Jun 2012, at 21:08, Eran Hammer wrote: >=20 >> The only distinction I would make is between removing flexibiliy to = proactively enabling future extensibility. I would stop short of = perscribing encoding in order to fit uri into the Basic auth fields. But = if there is a way to allow this to be less restrictive without clean = interop issues, that would be nice. >> =20 >> I do agree we need some actual use cases before we spend much more = time on this. >> =20 >> EH >> =20 >> From: William Mills [mailto:wmills@yahoo-inc.com]=20 >> Sent: Tuesday, June 12, 2012 1:04 PM >> To: Eran Hammer; Mike Jones; Hannes Tschofenig; Julian Reschke >> Cc: oauth@ietf.org >> Subject: Dynamic clients, URI, and stuff Re: [OAUTH-WG] Discussion = needed on username and password ABNF definitions >> =20 >> I think dynamic client registration is something we have not talked = out enough yet. There's a pretty clear use case for dynamic = registration. =20 >> =20 >> Does identifying the client with a URI allow some form of OpenID-ish = flow for this?=20 >> Is the client ID as a URI a way to allow a trusted site to provide = metadata about the client? >> Is that URI a way to hit an IDP we trust to validate the client in = some way with the provided secret? >> =20 >> I guess what I'm looking for here is a concrete use case/problem to = solve, rather then leaving a hook we think is the right thing. >> =20 >> -bill >> =20 >> =20 >> From: Eran Hammer >> To: Mike Jones ; William Mills = ; Hannes Tschofenig ; = Julian Reschke =20 >> Cc: "oauth@ietf.org" =20 >> Sent: Tuesday, June 12, 2012 11:39 AM >> Subject: RE: [OAUTH-WG] Discussion needed on username and password = ABNF definitions >> =20 >> Is the use case of using URI as client ids important? It seems like = something that might become useful in the future where clients can use = their verifiable servers to bypass client registration and simly use a = URI the server can validate via some other means. >> =20 >> I just want to make sure those thinking about more complex use cases = involving dynamic registration or distri buted client manamgenet are = aware of this potential restriction. >> =20 >> I'm fine either way. >> =20 >> EH >> =20 >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf Of Mike Jones >> Sent: Tuesday, June 12, 2012 11:27 AM >> To: William Mills; Hannes Tschofenig; Julian Reschke >> Cc: oauth@ietf.org >> Subject: Re: [OAUTH-WG] Discussion needed on username and password = ABNF definitions >> =20 >> Not internationalizing fields intended for machine consumption only = is already a precedent set and agreed to by the working group, so let me = second Bill=92s point in that regard. For instance, neither =93scope=94 = nor =93error=94 allow non-ASCII characters. >> =20 >> Julian, if you want different ABNF text than the text I wrote below, = I believe it would be most useful if you would provide the exact replace = wording that you=92d like to see instead of it. Then there=92s no = possibility of misunderstanding the intent of suggested changes. >> =20 >> Thanks = all, >> -- Mike >> =20 >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf Of William Mills >> Sent: Tuesday, June 12, 2012 11:18 AM >> To: Hannes Tschofenig; Julian Reschke >> Cc: oauth@ietf.org >> Subject: Re: [OAUTH-WG] Discussion needed on username and password = ABNF definitions >> =20 >> I agree generally with your assumption about clients, but rather than = saying "clients are devices" I think it makes much more sense to say = "clients are NOT users, so client_id need not be internationalized". In = practical terms there is very little to argue for anythign beyond ASCII = in a client_secret, base64 encoding or the equivalent being a fine way = to transport arbitrary bits in a portable/reasonable way. >> =20 >> I argue that client_id need not be internationalized because I assume = that any really internationalized application will have an = internationalized presentation layer that's presenting a pretty name for = the client_id. >> =20 >> -bill >> =20 >> From: Hannes Tschofenig >> To: Julian Reschke =20 >> Cc: "oauth@ietf.org" =20 >> Sent: Tuesday, June 12, 2012 11:01 AM >> Subject: Re: [OAUTH-WG] Discussion needed on username and password = ABNF definitions >>=20 >> I had a chat with Julian yesterday and here is my short summary.=20 >>=20 >> Section 2.3 of the core draft defines client authentication based on = two mechanisms (and provides room for = extensions):http://tools.ietf.org/html/draft-ietf-oauth-v2-27#section-2.3 >>=20 >> 1) HTTP Basic Authentication >>=20 >> 2) A custom OAuth authentication mechanism (which uses client_id and = client_secret) >>=20 >> With HTTP Basic authentication the problem is that this is a legacy = technology and there is no internationalization support.=20 >>=20 >> With our brand new custom OAuth authentication mechanism we have more = options.=20 >>=20 >> One possible approach is to say that the clients are devices (and not = end users) and therefore internationalization does not matter.=20 >>=20 >> Is it, however, really true that only US-ASCII characters will appear = in the client_id and also in the client_secret?=20 >>=20 >> Here we have the possibility to define something better.=20 >>=20 >> In any case we have to restrict the characters that are used in these = two authentication mechanisms since they could conflict with the way how = we transport the data over the underlying protocol. Julian mentioned = this in his previous mails.=20 >>=20 >> Julian, maybe you can provide a detailed text proposal for how to = address your comment in case we go for UTF8 (with % encoding) for the = custom OAuth client authentication mechanism?=20 >>=20 >> Ciao >> Hannes >>=20 >> On Jun 12, 2012, at 11:54 AM, Julian Reschke wrote: >>=20 >> > On 2012-06-12 00:16, Mike Jones wrote: >> >> Reviewing the feedback from Julian, John, and James, I'm coming to = the conclusion that client_id and client_secret, being for machines and = not humans, shou ld be ASCII, whereas username and password should be = Unicode, since they are for humans. Per John's feedback, client_id can = not contain a colon and be compatible with HTTP Basic. >> >=20 >> > I'm not sure that restricting the character repertoire just because = one way to send requires this is the right approach. My preference would = be not to put this into the ABNF, and just to point out that certain = characters will not work over certain transports, and to just advise to = avoid them. >> >=20 >> >> Therefore, I'd like to propose these updated ABNF definitions: >> >>=20 >> >> VSCHAR =3D %20-7E >> >> NOCOLONVSCHAR =3D %x20-39 / %x3B-7E >> >> UNICODENOCTRLCHAR =3D >> >>=20 >> >> client-id =3D *NOCOLONVSCHAR >> >> client_secret =3D *VSCHAR >> >>=20 >> >> username =3D *UNICODENOCTRLCHAR >> >> password =3D *UNICODENOCTRLCHAR >> >=20 >> > In this case you should add an introductory statement pointing out = that the ABNF defines the grammar in terms of Unicode code points, not = octets (as it is the case most of the time). >> >=20 >> >> It turns out that non-ASCII characters are OK for username and = password because the Core spec only passes them in the form body - not = using HTTP Basic - and UTF-8 encoding is specified. >> >=20 >> > I'll send a separate mail about that, the current text in the spec = is way too unspecific. >> >=20 >> >> -- Mike >> >>=20 >> >> P.S. If anyone has a better ABNF for UNICODENOCTRLCHAR than "", please send it to me! >> >=20 >> > As noted before, here's an example: = >> >=20 >> > Best regards, Julian >> > _______________________________________________ >> > OAuth mailing list >> > OAuth@ietf.org >> > https://www.ietf.org/mailman/listinfo/oauth >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> =20 >>=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 > This message and any attachment are intended solely for the addressee = and may contain confidential information. If you have received this = message in error, please send it back to me, and immediately delete it. = Please do not use, copy or disclose the information contained in this = message or in any attachment. Any views or opinions expressed by the = author of this email do not necessarily reflect the views of the = University of Nottingham. >=20 > This message has been checked for viruses but the contents of an = attachment may still contain software viruses which could damage your = computer system: you are advised to perform your own checks. Email = communications with the University of Nottingham may be monitored as = permitted by UK legislation. >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_93AC71F0-B584-4478-A048-01D58B53AC0A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I = think that the issues are getting confused.

There is = a use case where the Authorization server may be a embedded app, at = least in one openID case.    As it won't have a separate = registration or token endpoint,  the client needs to make its own = clientID for the request.   A reasonable thing to use is the = redirect URI to create a unique value that the user could use for = revocation at a later point.

Currently with the = no : restriction we would use the host and path to crate the = clientid.
There are some scenarios where having the scheme as = part of that would be helpful.

This has nothing = to do with discovery or the dynamic client registration proposal as far = as I know.

A URL as a client_id comes from = prototype work for a personal provider that we are doing as part of = openID Connect.

John B.
On = 2012-06-13, at 7:50 AM, Torsten Lodderstedt wrote:

Hi = all,

can anyone please explain the relation between dynamic client = registration and URIs as client ids? None of the current drafts (uma or = connect) seem to require URIs.

regards,
Torsten.



Jianhua Shao <psxjs4@nottingham.ac.uk> = schrieb:
Hello,

Dynamic client registration is very = useful if client or resource or authorisation server is not permanently = available. 
A typical case is that is the resource or = authorisation server is in mobile platform, the connection is not always = available. 
Another typical case is that authorisation = server do not necessary to have client pre-registered on itself. At = moment, industry like facebook would like developer to register a app on = its app centre first, and then ask user auth to use the = app. 

We are researchers from Digital = Economy Research Institute. We have this problem When we developing = Dataware that could manage the control of access to personal data. We = play around our solution base on Oauth2: https://gith= ub.com/jianhuashao/dataware.catalog/wiki

We = are in the list to receive your mail list, but currently need moderate to post any message. cc my colleague, = Richard = Mortier
Best
Jian


On= 12 Jun 2012, at 21:08, Eran Hammer wrote:

The = only distinction I would make is between removing flexibiliy to = proactively enabling future extensibility. I would stop short of = perscribing encoding in order to fit uri into the Basic auth fields. But = if there is a way to allow this to be less restrictive without clean = interop issues, that would be nice.
I do = agree we need some actual use cases before we spend much more time on = this.
 William = Mills [mailto:wmills@yahoo-inc.com] 
Sent: Tuesday, June 12, 2012 1:04 = PM
To: Eran = Hammer; Mike Jones; Hannes Tschofenig; Julian Reschke
Cc: oauth@ietf.org
Subject: Dynamic clients, URI, and = stuff Re: [OAUTH-WG] Discussion needed on username and password ABNF = definitions
 
I think dynamic client registration is = something we have not talked out enough yet.  There's a pretty = clear use case for dynamic = registration.  
Does identifying the client with a URI allow some form = of OpenID-ish flow for = this? 
Is the client ID as a URI a way to=20 allow a trusted site to provide metadata about the = client?
Is = that URI a way to hit an IDP we trust to validate the client in some way = with the provided secret?
I guess what I'm looking for here is a concrete use = case/problem to solve, rather then leaving a hook we think is the right = thing.
Is the use case of = using URI as client ids important? It seems like something that might = become useful in the future where clients can use their verifiable = servers to bypass client registration and simly use a URI the server can validate via some other means.
I just want to make = sure those thinking about more complex use cases involving dynamic = registration or distri buted client manamgenet are aware of this potential restriction.
 I'm fine either = way. 
EH 
 oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Mike = Jones
Sent: Tuesday, June 12, 2012 = 11:27 AM
To: William Mills; Hannes = Tschofenig; Julian Reschke
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Discussion = needed on username and password ABNF definitionsNot internationalizing fields intended for machine = consumption only is already a precedent set and agreed to by the working = group, so let me second Bill=92s point in that regard.  For = instance, neither =93scope=94 nor =93error=94 allow non-ASCII = characters. 
 
 
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of William = Mills
Sent: Tuesday, June 12, 2012 = 11:18 AM
To: Hannes Tschofenig; Julian = Reschke
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Discussion = needed on username and password ABNF definitions
From: Hannes Tschofenig < Julian Reschke <julian.reschke@gmx.de> 
Cc: "oauth@ietf.org" <oauth@ietf.org> 
Sent: Tuesday, June 12, 2012 = 11:01 AM
Subject: Re: [OAUTH-WG] Discussion = needed on username and password ABNF definitions

I had a chat with Julian yesterday and here is my short = summary. 

Section= 2.3 of the core draft defines client authentication based on two = mechanisms (and provides room for extensions): 

With our brand new = custom OAuth authentication mechanism we have more options. 

One possible = approach is to say that the clients are devices (and not end users) and = therefore internationalization does not matter. 

Is it, however, = really true that only US-ASCII characters will appear in the client_id = and also in the client_secret? 

Here we have the = possibility to define something better. 

In any case we have = to restrict the characters that are used in these two authentication = mechanisms since they could conflict with the way how we transport the = data over the underlying protocol. Julian mentioned this in his previous = mails. 

Julian, = maybe you can provide a detailed text proposal for how to address your = comment in case we go for UTF8 (with % encoding) for the custom OAuth = client authentication mechanism? 

Ciao
Hannes
On Jun 12, 2012, at 11:54 AM, Julian Reschke wrote:

> On = 2012-06-12 00:16, Mike Jones wrote:
>> Reviewing the feedback = from Julian, John, and James, I'm coming to the conclusion that = client_id and client_secret, being for machines and not humans, shou ld be ASCII, whereas username and password should be Unicode, since they are = for humans.  Per John's feedback, client_id can not contain a colon = and be compatible with HTTP Basic.
> 
> I'm not sure that = restricting the character repertoire just because one way to send = requires this is the right approach. My preference would be not to put = this into the ABNF, and just to point out that certain characters will = not work over certain transports, and to just advise to avoid = them.
> 
>> Therefore, I'd = like to propose these updated ABNF definitions:
>> 
>>    = VSCHAR =3D %20-7E
>>    NOCOLONVSCHAR =3D %x20-39 / = %x3B-7E
>>    UNICODENOCTRLCHAR =3D <Any Unicode = character other than ( %x0-1F / %x7F )>
>> 
>>    = client-id =3D *NOCOLONVSCHAR
>>    client_secret =3D = *VSCHAR
>> 
>>    = username =3D *UNICODENOCTRLCHAR
>>    password =3D = *UNICODENOCTRLCHAR
> 
> In this case you = should add an introductory statement pointing out that the ABNF defines = the grammar in terms of Unicode code points, not octets (as it is the = case most of the time).
> 
>> It turns out = that non-ASCII characters are OK for username and password because the = Core spec only passes them in the form body - not using HTTP Basic - and = UTF-8 encoding is specified.
> 
> I'll send a = separate mail about that, the current text in the spec is way too = unspecific.
> 
>> =             =     -- Mike
>> 
>> P.S.  If = anyone has a better ABNF for UNICODENOCTRLCHAR than "<Any Unicode = character other than ( %x0-1F / %x7F )>", please send it to = me!
> 
> = As noted before, here's an example: < 
> Best = regards, Julian
> = _______________________________________________
> OAuth mailing = list
> OAuth@ietf.org
> OAuth@ietf.org
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth

This message and any attachment are intended solely for the addressee = and may=20 contain confidential information. If you have received this message in = error,=20 please send it back to me, and immediately delete it. Please do not = use,=20 copy or disclose the information contained in this message or in any = attachment. =20 Any views or opinions expressed by the author of this email do not = necessarily=20 reflect the views of the University of Nottingham.

This message has been checked for viruses but the contents of an = attachment may still contain software viruses which could damage your computer = system: you are advised to perform your own checks. Email communications with = the University of Nottingham may be monitored as permitted by UK = legislation.

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

= --Apple-Mail=_93AC71F0-B584-4478-A048-01D58B53AC0A-- From stephen.farrell@cs.tcd.ie Wed Jun 13 05:28:37 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2975821F85DA for ; Wed, 13 Jun 2012 05:28: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=[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 LWuFVqleltS8 for ; Wed, 13 Jun 2012 05:28:36 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id A1BE321F85AE for ; Wed, 13 Jun 2012 05:28:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 140411717F3 for ; Wed, 13 Jun 2012 13:28:36 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:subject:mime-version :user-agent:from:date:message-id:received:received: x-virus-scanned; s=cs; t=1339590515; bh=mj+IuycmwYgMhK/HumJLWeMp iYS9Wy4MwmxVt5x+ECY=; b=aSl/0d7E1zPZBcLZvNXG9/r3RTyIo8NdgwZru4pj cWKfXxOz+Gl0KuceF69SRdWLRlLSryTMem2Cn2yoxnjWGiJ0/TjsnTXq3ir7Bhmq QCuvF9YZcVUnLdZnuBVxHh1x8KXjkkVEw2BTqJ78PdyJZSrCMBFS/zJTqtYUuw7D CxCHsznp4hoileDCKbc/VCtWbt7iFGvYQJFt/NT5zMW9u5UTwNgKMQfiTgUL/nvY guVLCBhUiSVZb16FHj4xRnkvAvDIJx+DumOZG6vRhiTNY1X/I0eRv5+LhqsNsc2u krsYOxXZVXkDqrxSmDGb/Y08tYEagIpMlEBqkEcOt7JtcA== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id B8UDSX3vSTg7 for ; Wed, 13 Jun 2012 13:28:35 +0100 (IST) Received: from [IPv6:2001:770:10:203:353a:5c1f:6277:879a] (unknown [IPv6:2001:770:10:203:353a:5c1f:6277:879a]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id A6C9D1714DE for ; Wed, 13 Jun 2012 13:28:35 +0100 (IST) Message-ID: <4FD88774.1000305@cs.tcd.ie> Date: Wed, 13 Jun 2012 13:28:36 +0100 From: Stephen Farrell 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" X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [OAUTH-WG] 2nd IETF LC on oauth bearer document X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 12:28:37 -0000 Hi all, Just so's you know, I've requested the additional IETF LC on the oauth bearer draft. This is because a reviewer after the previous IETF LC and after the IESG telechat noticed some IPR and did the right thing. I think we're close enough to done that folks can make their evaluations of what they think about the IPR declaration. If you disagree, that's a fine IETF LC comment:-) The IETF LC mail should pop out later today. Thanks, Stephen. From stephen.farrell@cs.tcd.ie Wed Jun 13 05:58:13 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6042121F852D for ; Wed, 13 Jun 2012 05:58:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 GEHDnlo6RxBD for ; Wed, 13 Jun 2012 05:58:12 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id BA14321F852C for ; Wed, 13 Jun 2012 05:58:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 241DC1717F3 for ; Wed, 13 Jun 2012 13:58:12 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:subject:mime-version :user-agent:from:date:message-id:received:received: x-virus-scanned; s=cs; t=1339592291; bh=LCAQYHuO57NXZIVNIr5pWs3F p+ft7WqtPX8ZEglqZ/o=; b=bkteFxJ+LxRfcNLTidcVRDrhRSaY1qBlg/zg+OHT Icb50I+gCFohD9YAAcAgaAzh/lzjQkLA2M1ZYefbBy/syUo2QfjsHIUHEOfaTG3B CBQ5aPkkNw/z7CLfzviUQsYye4b3E0gnowHLsz6sJltB3hzMG1fciTgSw/91qD57 eqS147QFSnTDF1s/VZjCcJbkGwxER+XDvxsdYITii/CaQPI4KUhj7w3Qy7mwF8pm VKXEeLUMpElAc/7GK8PK2YW0LyNOq8/owGq+VI9dC7vTD3awl+li4cX8QnNgOvVy GsyCW50mTAWeQdBK2FTUVgq+eBL7QSlfuiT1mrqiMN0BEw== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id N-CyLx6b715T for ; Wed, 13 Jun 2012 13:58:11 +0100 (IST) Received: from [IPv6:2001:770:10:203:353a:5c1f:6277:879a] (unknown [IPv6:2001:770:10:203:353a:5c1f:6277:879a]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id C09DD1714DE for ; Wed, 13 Jun 2012 13:58:11 +0100 (IST) Message-ID: <4FD88E64.1020000@cs.tcd.ie> Date: Wed, 13 Jun 2012 13:58:12 +0100 From: Stephen Farrell 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" X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [OAUTH-WG] discusses on oauth-v2 cleared X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 12:58:13 -0000 Hi all, Just to let you know that all discusses on draft-ietf-oauth-v2 have now cleared. So that means that when the chairs tell me you've finished the last few updates needed, I can shoot this on to the RFC editor (as long as you don't mess about adding crazy stuff:-). Let's get this one out the door! Thanks, S. From iesg-secretary@ietf.org Wed Jun 13 07:24:34 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18CCC21F8557; Wed, 13 Jun 2012 07:24:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.493 X-Spam-Level: X-Spam-Status: No, score=-102.493 tagged_above=-999 required=5 tests=[AWL=0.106, 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 x9YUq4bCcQQL; Wed, 13 Jun 2012 07:24:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B9AE21F8629; Wed, 13 Jun 2012 07:24:32 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.20 Message-ID: <20120613142431.12910.11401.idtracker@ietfa.amsl.com> Date: Wed, 13 Jun 2012 07:24:31 -0700 Cc: oauth@ietf.org Subject: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Framework: Bearer Token Usage) to Proposed Standard X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 14:24:34 -0000 The IESG has received a request from the Web Authorization Protocol WG (oauth) to consider the following document: - 'The OAuth 2.0 Authorization Framework: Bearer Token Usage' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-06-27. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. This 2nd IETF LC is due to an IPR declartion being made after the previous IETF LC - a reviewer noticed some IPR and did the right thing and made a declaration. Abstract This specification describes how to use bearer tokens in HTTP requests to access OAuth 2.0 protected resources. Any party in possession of a bearer token (a "bearer") can use it to get access to the associated resources (without demonstrating possession of a cryptographic key). To prevent misuse, bearer tokens need to be protected from disclosure in storage and in transport. * There is a normative reference to RFC 2246 (TLS 1.0), which has been obsoleted by RFC 5246 (TLS 1.2). The document uses this reference to note that TLS 1.0 is, at this writing, the most widely deployed version. The working group believes it is necessary to note that, and that the reference be normative. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-oauth-v2-bearer/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-oauth-v2-bearer/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1752/ From wmills@yahoo-inc.com Wed Jun 13 08:07:44 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 002AE21F84FE for ; Wed, 13 Jun 2012 08:07:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.426 X-Spam-Level: X-Spam-Status: No, score=-17.426 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I9jrK8LjLvTr for ; Wed, 13 Jun 2012 08:07:42 -0700 (PDT) Received: from nm6-vm2.bullet.mail.ne1.yahoo.com (nm6-vm2.bullet.mail.ne1.yahoo.com [98.138.90.154]) by ietfa.amsl.com (Postfix) with SMTP id 9816521F84EC for ; Wed, 13 Jun 2012 08:07:41 -0700 (PDT) Received: from [98.138.90.48] by nm6.bullet.mail.ne1.yahoo.com with NNFMP; 13 Jun 2012 15:07:37 -0000 Received: from [98.138.89.193] by tm1.bullet.mail.ne1.yahoo.com with NNFMP; 13 Jun 2012 15:07:37 -0000 Received: from [127.0.0.1] by omp1051.mail.ne1.yahoo.com with NNFMP; 13 Jun 2012 15:07:37 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 434226.46594.bm@omp1051.mail.ne1.yahoo.com Received: (qmail 94033 invoked by uid 60001); 13 Jun 2012 15:07:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1339600056; bh=DzKcAFzrcRST2Rp2O8pQfh6RUEbH8CKY6sdfwiaiObY=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=qjr3WTMStsOnAFUwJsSaxu/ucMTBoGDIISF+ybU7OUTYMln3snf8GEQEJVjTRbQJ4hnboDGx82Dgzv3ZwOBPw0HbWZx0L+XopsKDZdL+Q4y79MZkm9iNg/ne0AG8jsCovKNZnVNMQ3owG1AMrrhuE4SJL44MrmPXvz+FhN7KxXM= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=KCA1o0gI7rnrDvnDcEBkzmj3rX57S0EcQ6BemDVlB9jyF9BarmnHkS3dadOsYZajBjgGFUMwyBcL2aumTXQ0vEadUhCzN0LFyXtlaLW2utl3Zyu9egzzoPbhOX9u+1VVWxs1UhJYdhAYvV2qAK56lXPpsiZ8NF/MFgC6UdlZtEA=; X-YMail-OSG: L.If7yQVM1kF9zwYyMLWdqMJxiEhahk8xMkRitlWpJ4ObSx OCheHF1X48RlvpDpxg0l1QoDwoXa4VZDX_.f1iwXaqdJo5zmZFZXw2EtUkDf .z0WwxLbp7fXELdpZMwugpVWHZrALrsM8dbeHb8.8jzmHZBHG_WWx2wn6hS3 zqHxNU.HULZAHc7BMT3R6MECZvqeF9jl_mKctnLBPyvm9ec5UQ6HpEkiw5Oe UeRHjSAYVHIT_5PSyZDRG2XpI4pZ4X3DuRTsKMjTX1nSwZ8jwr0FfJl4Q319 xd4T6Lm61AYghLXrBtCsGMJ0OdknBf90c7NBmbRoFBbaq_FLEDKoifVOJmrt kWtLMzmiSvj.3Ap3qL..rA.4z8NEC3QOcIKraaXGuHV.CrvK61SBACtOUcoN nieUvf.BCadAcXQSPhYkIx9e__dwbFrSy2vC4vBWQ_sVmYvz4jBgJhq.4v3P hJOsqEq7cungsnRfaDXoyt7HUnsn.6JcMQ56b17wC5MbPNmINKNZMins8XQW Ab1KZHOPgMNdqneR8g87cZj8jyWuaK5xQ2THGlQNfuO1.f7W5BAAS27KAc23 ylq7mIt1Pi2VrsrLqAybGeYew8SPVcXHCd43VvGUPYU8j33Iwp._j Received: from [209.131.62.115] by web31810.mail.mud.yahoo.com via HTTP; Wed, 13 Jun 2012 08:07:36 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.120.356233 References: <47d860c2-976a-48f0-90df-feee360d355a@email.android.com> <89A82128-52B0-4EB4-B16F-69ED51262DB2@ve7jtb.com> Message-ID: <1339600056.32647.YahooMailNeo@web31810.mail.mud.yahoo.com> Date: Wed, 13 Jun 2012 08:07:36 -0700 (PDT) From: William Mills To: John Bradley , Torsten Lodderstedt In-Reply-To: <89A82128-52B0-4EB4-B16F-69ED51262DB2@ve7jtb.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1935884094-945985727-1339600056=:32647" Cc: Julian Reschke , Richard Mortier , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion needed on username and password ABNF definitions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 15:07:44 -0000 --1935884094-945985727-1339600056=:32647 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable OK cool, a use case.=C2=A0 Does the language I suggested in another thread = generally work for you then, is something liek that needed?=0A=0A=0A=0A=0A>= ________________________________=0A> From: John Bradley = =0A>To: Torsten Lodderstedt =0A>Cc: Julian Reschk= e ; Richard Mortier ; "oauth@ietf.org" =0A>Sent: Wednesday, June 13, 2012 3:= 56 AM=0A>Subject: Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discus= sion needed on username and password ABNF definitions=0A> =0A>=0A>I think t= hat the issues are getting confused.=0A>=0A>=0A>There is a use case where t= he Authorization server may be a embedded app, at least in one openID case.= =C2=A0 =C2=A0As it won't have a separate registration or token endpoint, = =C2=A0the client needs to make its own clientID for the request. =C2=A0 A r= easonable thing to use is the redirect URI to create a unique value that th= e user could use for revocation at a later point.=0A>=0A>=0A>Currently with= the no : restriction we would use the host and path to crate the clientid.= =0A>There are some scenarios where having the scheme as part of that would = be helpful.=0A>=0A>=0A>This has nothing to do with discovery or the dynamic= client registration proposal as far as I know.=0A>=0A>=0A>A URL as a clien= t_id comes from prototype work for a personal provider that we are doing as= part of openID Connect.=0A>=0A>=0A>John B.=0A>=0A>On 2012-06-13, at 7:50 A= M, Torsten Lodderstedt wrote:=0A>=0A>Hi all,=0A>>=0A>>can anyone please exp= lain the relation between dynamic client registration and URIs as client id= s? None of the current drafts (uma or connect) seem to require URIs.=0A>>= =0A>>regards,=0A>>Torsten.=0A>>=0A>>=0A>>=0A>>=0A>>Jianhua Shao schrieb:=0A>>Hello,=0A>>>=0A>>>=0A>>>Dynamic client registra= tion is very useful if client or resource or authorisation server is not pe= rmanently available.=C2=A0=0A>>>A typical case is that is the resource or a= uthorisation server is in mobile platform, the connection is not always ava= ilable.=C2=A0=0A>>>Another typical case is that authorisation server do not= necessary to have client pre-registered on itself. At moment, industry lik= e facebook would like developer to register a app on its app centre first, = and then ask user auth to use the app.=C2=A0=0A>>>=0A>>>=0A>>>We are resear= chers from Digital Economy Research Institute. We have this problem When we= developing Dataware that could manage the control of access to personal da= ta. We play around our solution base on Oauth2:=C2=A0https://github.com/jia= nhuashao/dataware.catalog/wiki=0A>>>=0A>>>=0A>>>We are in the list to recei= ve your mail list,=0Abut currently need moderate to post any message. cc my= colleague, Richard Mortier=0A>>>Best=0A>>>Jian=0A>>>=0A>>>=0A>>>=0A>>>On 1= 2 Jun 2012, at 21:08, Eran Hammer wrote:=0A>>>=0A>>>The only distinction I = would make is between removing flexibiliy to proactively enabling future ex= tensibility. I would stop short of perscribing encoding in order to fit uri= into the Basic auth fields. But if there is a way to allow this to be less= restrictive without clean interop issues, that would be nice.=0A>>>>=C2=A0= =0A>>>>I do agree we need some actual use cases before we spend much more t= ime on this.=0A>>>>=C2=A0=0A>>>>EH=0A>>>>=C2=A0=0A>>>>From:=C2=A0William Mi= lls [mailto:wmills@yahoo-inc.com]=C2=A0=0A>>>>Sent:=C2=A0Tuesday, June 12, = 2012 1:04 PM=0A>>>>To:=C2=A0Eran Hammer; Mike Jones; Hannes Tschofenig; Jul= ian Reschke=0A>>>>Cc:=C2=A0oauth@ietf.org=0A>>>>Subject:=C2=A0Dynamic clien= ts, URI, and stuff Re: [OAUTH-WG] Discussion needed on username and passwor= d ABNF definitions=0A>>>>=C2=A0=0A>>>>I think dynamic client registration i= s something we have not talked out enough yet.=C2=A0 There's a pretty clear= use case for dynamic registration.=C2=A0=C2=A0=0A>>>>=C2=A0=0A>>>>Does ide= ntifying the client with a URI allow some form of OpenID-ish flow for this?= =C2=A0=0A>>>>Is the client ID as a URI a way to allow a=0Atrusted site to = provide metadata about the client?=0A>>>>Is that URI a way to hit an IDP we= trust to validate the client in some way with the provided secret?=0A>>>>= =C2=A0=0A>>>>I guess what I'm looking for here is a concrete use case/probl= em to solve, rather then leaving a hook we think is the right thing.=0A>>>>= =C2=A0=0A>>>>-bill=0A>>>>=C2=A0=0A>>>>=C2=A0=0A>>>>>=0A>>>>>_______________= _________________=0A>>>>>=0A>>>>>From:=C2=A0Eran Hammer =0A>>>>>To:=C2=A0Mike Jones ; William Mills = ; Hannes Tschofenig ; Juli= an Reschke =C2=A0=0A>>>>>Cc:=C2=A0"oauth@ietf.org" <= oauth@ietf.org>=C2=A0=0A>>>>>Sent:=C2=A0Tuesday, June 12, 2012 11:39 AM=0A>= >>>>Subject:=C2=A0RE: [OAUTH-WG] Discussion needed on username and password= ABNF definitions=0A>>>>>=C2=A0=0A>>>>>Is the use case of using URI as clie= nt ids important? It seems like something that might become useful in the f= uture where clients can use their verifiable servers to bypass client regis= tration and simly use a URI=0Athe server can validate via some other means.= =0A>>>>>=C2=A0=0A>>>>>I just want to make sure those thinking about more co= mplex use cases involving dynamic registration or distri buted=0Aclient man= amgenet are aware of this potential restriction.=0A>>>>>=C2=A0=0A>>>>>I'm f= ine either way.=0A>>>>>=C2=A0=0A>>>>>EH=0A>>>>>=C2=A0=0A>>>>>From:=C2=A0oau= th-bounces@ietf.org=C2=A0[mailto:oauth-bounces@ietf.org]=C2=A0On Behalf Of= =C2=A0Mike Jones=0A>>>>>Sent:=C2=A0Tuesday, June 12, 2012 11:27 AM=0A>>>>>T= o:=C2=A0William Mills; Hannes Tschofenig; Julian Reschke=0A>>>>>Cc:=C2=A0oa= uth@ietf.org=0A>>>>>Subject:=C2=A0Re: [OAUTH-WG] Discussion needed on usern= ame and password ABNF definitions=0A>>>>>=C2=A0=0A>>>>>Not internationalizi= ng fields intended for machine consumption only is already a precedent set = and agreed to by the working group, so let me second Bill=E2=80=99s point i= n that regard.=C2=A0 For instance, neither =E2=80=9Cscope=E2=80=9D nor =E2= =80=9Cerror=E2=80=9D allow non-ASCII characters.=0A>>>>>=C2=A0=0A>>>>>Julia= n, if you want different ABNF text than the text I wrote below, I believe i= t would be most useful if you would provide the exact replace wording that = you=E2=80=99d like to see instead of it.=C2=A0 Then there=E2=80=99s no poss= ibility of misunderstanding the intent of suggested changes.=0A>>>>>=C2=A0= =0A>>>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Thanks all,= =0A>>>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike=0A>= >>>>=C2=A0=0A>>>>>From:=C2=A0oauth-bounces@ietf.org=C2=A0[mailto:oauth-boun= ces@ietf.org]=C2=A0On Behalf Of=C2=A0William Mills=0A>>>>>Sent:=C2=A0Tuesda= y, June 12, 2012 11:18 AM=0A>>>>>To:=C2=A0Hannes Tschofenig; Julian Reschke= =0A>>>>>Cc:=C2=A0oauth@ietf.org=0A>>>>>Subject:=C2=A0Re: [OAUTH-WG] Discuss= ion needed on username and password ABNF definitions=0A>>>>>=C2=A0=0A>>>>>I= agree generally with your assumption about clients, but rather than saying= "clients are devices" I think it makes much more sense to say "clients are= NOT users, so client_id need not be internationalized".=C2=A0 In practical= terms there is very little to argue for anythign beyond ASCII in a client_= secret, base64 encoding or the equivalent being a fine way to transport arb= itrary bits in a portable/reasonable way.=0A>>>>>=C2=A0=0A>>>>>I argue that= client_id need not be internationalized because I assume that any really i= nternationalized application will have an internationalized presentation la= yer that's presenting a pretty name for the client_id.=0A>>>>>=C2=A0=0A>>>>= >-bill=0A>>>>>=C2=A0=0A>>>>>=0A>>>>>________________________________=0A>>>>= >=0A>>>>>From:=C2=A0Hannes Tschofenig =0A>>>>>To= :=C2=A0Julian Reschke =C2=A0=0A>>>>>Cc:=C2=A0"oauth@= ietf.org" =C2=A0=0A>>>>>Sent:=C2=A0Tuesday, June 12, 2012 1= 1:01 AM=0A>>>>>Subject:=C2=A0Re: [OAUTH-WG] Discussion needed on username a= nd password ABNF definitions=0A>>>>>=0A>>>>>I had a chat with Julian yester= day and here is my short summary.=C2=A0=0A>>>>>=0A>>>>>Section 2.3 of the c= ore draft defines client authentication based on two mechanisms=0A (and=0A= provides room for extensions):http://tools.ietf.org/html/draft-ietf-oauth-v= 2-27#section-2.3=0A>>>>>=0A>>>>>1) HTTP Basic Authentication=0A>>>>>=0A>>>>= >2) A custom OAuth authentication mechanism (which uses client_id and clien= t_secret)=0A>>>>>=0A>>>>>With HTTP Basic authentication the problem is that= this is a legacy technology and there is no internationalization support.= =C2=A0=0A>>>>>=0A>>>>>With our brand new custom OAuth authentication mechan= ism we have more options.=C2=A0=0A>>>>>=0A>>>>>One possible approach is to = say that the clients are devices (and not end users) and therefore internat= ionalization does not matter.=C2=A0=0A>>>>>=0A>>>>>Is it, however, really t= rue that only US-ASCII characters will appear in the client_id and also in = the client_secret?=C2=A0=0A>>>>>=0A>>>>>Here we have the possibility to def= ine something better.=C2=A0=0A>>>>>=0A>>>>>In any case we have to restrict = the characters that are used in these two authentication mechanisms since t= hey could conflict with the way how we transport the data over the underlyi= ng protocol. Julian mentioned this in his previous mails.=C2=A0=0A>>>>>=0A>= >>>>Julian, maybe you can provide a detailed text proposal for how to addre= ss your comment in case we go for UTF8 (with % encoding) for the custom OAu= th client authentication mechanism?=C2=A0=0A>>>>>=0A>>>>>Ciao=0A>>>>>Hannes= =0A>>>>>=0A>>>>>On Jun 12, 2012, at 11:54 AM, Julian Reschke wrote:=0A>>>>>= =0A>>>>>> On 2012-06-12 00:16, Mike Jones wrote:=0A>>>>>>> Reviewing the fe= edback from Julian, John, and James, I'm coming to the conclusion that clie= nt_id and client_secret, being for machines and not humans, shou=0A ld be= =0AASCII, whereas username and password should be Unicode, since they are f= or humans.=C2=A0 Per John's feedback, client_id can not contain a colon and= be compatible with HTTP Basic.=0A>>>>>>=C2=A0=0A>>>>>> I'm not sure that r= estricting the character repertoire just because one way to send requires t= his is the right approach. My preference would be not to put this into the = ABNF, and just to point out that certain characters will not work over cert= ain transports, and to just advise to avoid them.=0A>>>>>>=C2=A0=0A>>>>>>> = Therefore, I'd like to propose these updated ABNF definitions:=0A>>>>>>>=C2= =A0=0A>>>>>>>=C2=A0 =C2=A0 VSCHAR =3D %20-7E=0A>>>>>>>=C2=A0 =C2=A0 NOCOLON= VSCHAR =3D %x20-39 / %x3B-7E=0A>>>>>>>=C2=A0 =C2=A0 UNICODENOCTRLCHAR =3D <= Any Unicode character other than ( %x0-1F / %x7F )>=0A>>>>>>>=C2=A0=0A>>>>>= >>=C2=A0 =C2=A0 client-id =3D *NOCOLONVSCHAR=0A>>>>>>>=C2=A0 =C2=A0 client_= secret =3D *VSCHAR=0A>>>>>>>=C2=A0=0A>>>>>>>=C2=A0 =C2=A0 username =3D *UNI= CODENOCTRLCHAR=0A>>>>>>>=C2=A0 =C2=A0 password =3D *UNICODENOCTRLCHAR=0A>>>= >>>=C2=A0=0A>>>>>> In this case you should add an introductory statement po= inting out that the ABNF defines the grammar in terms of Unicode code point= s, not octets (as it is the case most of the time).=0A>>>>>>=C2=A0=0A>>>>>>= > It turns out that non-ASCII characters are OK for username and password b= ecause the Core spec only passes them in the form body - not using HTTP Bas= ic - and UTF-8 encoding is specified.=0A>>>>>>=C2=A0=0A>>>>>> I'll send a s= eparate mail about that, the current text in the spec is way too unspecific= .=0A>>>>>>=C2=A0=0A>>>>>>> =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2= =A0=C2=A0 =C2=A0=C2=A0=C2=A0 -- Mike=0A>>>>>>>=C2=A0=0A>>>>>>> P.S.=C2=A0 I= f anyone has a better ABNF for UNICODENOCTRLCHAR than "", please send it to me!=0A>>>>>>=C2=A0=0A>= >>>>> As noted before, here's an example: =0A>>>>>>=C2=A0=0A>>>>>> Best regards, Jul= ian=0A>>>>>> _______________________________________________=0A>>>>>> OAuth= mailing list=0A>>>>>>=C2=A0OAuth@ietf.org=0A>>>>>>=C2=A0https://www.ietf.o= rg/mailman/listinfo/oauth=0A>>>>>=0A>>>>>__________________________________= _____________=0A>>>>>OAuth mailing list=0A>>>>>OAuth@ietf.org=0A>>>>>https:= //www.ietf.org/mailman/listinfo/oauth=0A>>>>>=C2=A0=0A_____________________= __________________________=0A>>OAuth mailing list=0A>>OAuth@ietf.org=0A>>ht= tps://www.ietf.org/mailman/listinfo/oauth=0A>>=0A>>=0A>>This message and an= y attachment are intended solely for the addressee and may =0Acontain confi= dential information. If you have received this message in error, =0Aplease = send it back to me, and immediately delete it. Please do not use, =0Acopy= or disclose the information contained in this message or in any attachment= . =0AAny views or opinions expressed by the author of this email do not ne= cessarily =0Areflect the views of the University of Nottingham. =0A>>This m= essage has been checked for viruses but the contents of an attachment=0Amay= still contain software viruses which could damage your computer system:=0A= you are advised to perform your own checks. Email communications with the= =0AUniversity of Nottingham may be monitored as permitted by UK legislation= . _______________________________________________=0A>>OAuth mailing list=0A= >>OAuth@ietf.org=0A>>https://www.ietf.org/mailman/listinfo/oauth=0A>>=0A>= =0A>_______________________________________________=0A>OAuth mailing list= =0A>OAuth@ietf.org=0A>https://www.ietf.org/mailman/listinfo/oauth=0A>=0A>= =0A> --1935884094-945985727-1339600056=:32647 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
OK cool, a use case.  Does the language I suggested in another threa= d generally work for you then, is something liek that needed?

From: John Bradle= y <ve7jtb@ve7jtb.com>
To: Torsten Lodderstedt <torsten@lodderstedt.net>
Cc: Julian Reschke <julian.resch= ke@gmx.de>; Richard Mortier <richard.mortier@nottingham.ac.uk>; "oauth@ietf.org"= <oauth@ietf.org>
Sent: Wednesday, June 13, 2012 3:56 AM
Subject: Re: [OAUTH-WG] Dynamic clients, URI, and stuff= Re: Discussion needed on username and password ABNF definitions

I think that the issues are gettin= g confused.

There is a use case where the Authorization = server may be a embedded app, at least in one openID case.    As = it won't have a separate registration or token endpoint,  the client n= eeds to make its own clientID for the request.   A reasonable thing to= use is the redirect URI to create a unique value that the user could use f= or revocation at a later point.

Currently with the= no : restriction we would use the host and path to crate the clientid.
There are some scenarios where having the scheme as pa= rt of that would be helpful.

This has nothing to d= o with discovery or the dynamic client registration proposal as far as I kn= ow.

A URL as a client_id comes from prototype work= for a personal provider that we are doing as part of openID Connect.
=

John B.
On 2012-06-13, at 7:50 AM, Torsten= Lodderstedt wrote:

=
Hi all= ,
=0A
=0Acan anyone please explain the relation between dynamic clien= t registration and URIs as client ids? None of the current drafts (uma or c= onnect) seem to require URIs.
=0A
=0Aregards,
=0ATorsten.

<= div class=3D"yiv8825061gmail_quote">
=0A
=0AJianhua Shao <psxjs4@nottingham.ac.uk> sch= rieb:
=0AHello,

Dynamic client registration is very useful= if client or resource or authorisation server is not permanently available= . 
A typical case is that is the resource or authorisation s= erver is in mobile platform, the connection is not always available. <= /div>
Another typical case is that authorisation server do not necessar= y to have client pre-registered on itself. At moment, industry like faceboo= k would like developer to register a app on its app centre first, and then = ask user auth to use the app. 

We are researc= hers from Digital Economy Research Institute. We have this problem When we = developing Dataware that could manage the control of access to personal dat= a. We play around our solution base on Oauth2: https://gith= ub.com/jianhuashao/dataware.catalog/wiki

We ar= e in the list to receive your mail=0A list,=0Abut currently need moderate t= o post any message. cc my colleague, Richard Mortier
Best
Jian


On 12 Jun 2012, at 21:08, Eran Ha= mmer wrote:

The on= ly distinction I would make is between removing flexibiliy to proactively e= nabling future extensibility. I would stop short of perscribing encoding in= order to fit uri into the Basic auth fields. But if there is a way to allo= w this to be less restrictive without clean interop issues, that would be n= ice.
 =
I do agree w= e need some actual use cases before we spend much more time on this.=
 
EH
 
From:<= span style=3D"font-size:10pt;font-family:Tahoma, sans-serif;"> William Mills [mailto:wmi= lls@yahoo-inc.com] 
Sent: <= /span>Tuesday, June 12, 2012 1:04 PM
To: Eran Hammer; Mike Jones; Hannes Tschofe= nig; Julian Reschke
Cc: oauth@ietf.org
Sub= ject: Dynam= ic clients, URI, and stuff Re: [OAUTH-WG] Discussion needed on username and= password ABNF definitions
 
I think dynamic client registration is s= omething we have not talked out enough yet.  There's a pretty clear us= e case for dynamic registration.  
 
= Does identifying the client with a URI allow some form of OpenID-ish flow for t= his? 
Is the client ID as a URI a way to =0A allow a=0Atrus= ted site to provide metadata about the client?
Is that URI a wa= y to hit an IDP we trust to validate the client in some way with the provid= ed secret?
 
I guess what I'm looking for here = is a concrete use case/problem to solve, rather then leaving a hook we thin= k is the right thing.
 
-bill
= &nbs= p;
= &nbs= p;
From: Eran Hammer <eran@hueniverse.com>
To: Mike Jones <Michael.Jones@microsoft.com>; William Mills <wmills= @yahoo-inc.com>; Hannes Tschofenig <hannes.tschofenig@gmx.net<= /a>>; Julian Reschke <julian.reschke@gmx.de> 
Cc: "oauth@ietf.org<= /a>" <oauth@ietf.org> 
Sent: Tuesday, June 12, 2012 11:39 AM
Subject: RE: [OAUTH-WG] Disc= ussion needed on username and password ABNF definitions
 
Is the use case of using URI as client ids important? It see= ms like something that might become useful in the future where clients can = use their verifiable servers to bypass client registration and simly use a= =0A URI=0Athe server can validate via some other means.
 
<= span style=3D"font-size:11pt;color:rgb(31, 73, 125);">I just want to make s= ure those thinking about more complex use cases involving dynamic registrat= ion or distri=0A buted=0Aclient manamgenet are aware of this potential rest= riction.
 
I'm fine either way.
<= /div>
 
EH
 
From: oauth-bounces@ietf.org [mailto:oauth= -bounces@ietf.org] = ;On Behalf Of&nbs= p;Mike Jones
Sent: Tuesday, June 12, 2012 11:27 AM
To: William Mills; Hann= es Tschofenig; Julian Reschke
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Discussion needed on username an= d password ABNF definitions
 
Not internationalizing fie= lds intended for machine consumption only is already a precedent set and ag= reed to by the working group, so let me second Bill=E2=80=99s point in that= regard.  For instance, neither =E2=80=9Cscope=E2=80=9D nor =E2=80=9Ce= rror=E2=80=9D allow non-ASCII characters.
 
Julian, if you want different ABNF text than the text I wrote belo= w, I believe it would be most useful if you would provide the exact replace= wording that you=E2=80=99d like to see instead of it.  Then there=E2= =80=99s no possibility of misunderstanding the intent of suggested changes.=
 
          &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           Thanks al= l,
           &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;           -- Mike
 
From: oauth-bo= unces@ietf.org [mailto:oauth-bounces@ietf= .org] On= Behalf Of = William Mills
Sent: Tuesday, June 12, 2012 11:18 AM
To: Hannes Tschofenig; Julian Res= chke
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Discussion needed on username an= d password ABNF definitions
 
I agree generally with your assumption about clients, b= ut rather than saying "clients are devices" I think it makes much more sens= e to say "clients are NOT users, so client_id need not be internationalized= ".  In practical terms there is very little to argue for anythign beyo= nd ASCII in a client_secret, base64 encoding or the equivalent being a fine= way to transport arbitrary bits in a portable/reasonable way.
 =
I a= rgue that client_id need not be internationalized because I assume that any= really internationalized application will have an internationalized presen= tation layer that's presenting a pretty name for the client_id.
 
-bill
 
From: Hannes Tschofenig <= ;hannes.tschofenig@gmx.net>
To: Julian Reschke <= ;julian.reschke@gmx.de> 
Cc: "oauth@ietf.org" <= oauth@ietf.org> = ;
Sent:&nb= sp;Tuesday, June 12, 2012 11:01 AM
Subject: Re: [OAUTH-WG] Discussion nee= ded on username and password ABNF definitions

I had a chat with Julian yesterday and here is my short su= mmary. 

= Section 2.3 of the core draft defines client authentication based on two mechanisms=0A (and= =0Aprovides room for extensions):http://tools.ietf.org/html/draft-ie= tf-oauth-v2-27#section-2.3

1) HTTP Basic Authentication

2= ) A custom OAuth authentication mechanism (which uses client_id and client_= secret)

With HTTP Basic authentication the problem is that this is a= legacy technology and there is no internationalization support. 

With our brand ne= w custom OAuth authentication mechanism we have more options. 

One possible approac= h is to say that the clients are devices (and not end users) and therefore = internationalization does not matter. 

Is it, however, really true that only US-ASC= II characters will appear in the client_id and also in the client_secret? 

Here we ha= ve the possibility to define something better. 

In any case we have to restrict the= characters that are used in these two authentication mechanisms since they= could conflict with the way how we transport the data over the underlying = protocol. Julian mentioned this in his previous mails. 

Julian, maybe you can provi= de a detailed text proposal for how to address your comment in case we go f= or UTF8 (with % encoding) for the custom OAuth client authentication mechan= ism? 

Ci= ao
Hannes

On Jun 12, 2012, at 11:54 AM, Julian Reschke wrote:
=
> On 2012-06-12 00:16, Mike Jones wrote:
>> Reviewing the feedback from Julian, John, and James, I'm coming to the conclusion that c= lient_id and client_secret, being for machines and not humans, shou=0A ld b= e=0AASCII, whereas username and password should be Unicode, since they are = for humans.  Per John's feedback, client_id can not contain a colon an= d be compatible with HTTP Basic.
> 
> I'm not sure that restricting the charac= ter repertoire just because one way to send requires this is the right appr= oach. My preference would be not to put this into the ABNF, and just to poi= nt out that certain characters will not work over certain transports, and t= o just advise to avoid them.
> 
>> Therefore, I'd like to propose these upd= ated ABNF definitions:
>> 
>>    VSCHAR =3D %20-7E
>>=     NOCOLONVSCHAR =3D %x20-39 / %x3B-7E
>>    = UNICODENOCTRLCHAR =3D <Any Unicode character other than ( %x0-1F / %x7F )>
>> 
>>    client-id =3D *NOCOLONVSCHAR
>> = ;   client_secret =3D *VSCHAR
>> 
>>    username =3D *UNI= CODENOCTRLCHAR
>>    password =3D *UNICODENOCTRLCHAR
= > 
> I= n this case you should add an introductory statement pointing out that the = ABNF defines the grammar in terms of Unicode code points, not octets (as it= is the case most of the time).
> 
>> It turns out that non-ASCII character= s are OK for username and password because the Core spec only passes them i= n the form body - not using HTTP Basic - and UTF-8 encoding is specified.> 
>= I'll send a separate mail about that, the current text in the spec is way too unspec= ific.
> <= br>>>              =    -- Mike
>> 
>> P.S.  If anyone has a better ABNF for U= NICODENOCTRLCHAR than "<Any Unicode character other than ( %x0-1F / %x7F= )>", please send it to me!
> 
> As noted before, here's an example: <http://greenbytes.de/tech/webdav/rfc5323.html#rfc.section.5.15.1>
> <= br>> Best regards, Julian
> _______________________________________________
> OAuth mailing list=
> OAuth@ietf.org
>=  https://www.ietf.org/mailman/listinfo/oauth

__________________= _____________________________
OAuth mailing list
OAuth@ietf.org<= br>https://= www.ietf.org/mailman/listinfo/oauth
 
_____________________________= __________________
OAuth mailing list
OAu= th@ietf.org
https://www.ietf.org/mailman/listinfo/oa= uth

=0AThis message and any attachment are intended solely = for the addressee and may =0Acontain confidential information. If you have = received this message in error, =0Aplease send it back to me, and immediate= ly delete it. Please do not use, =0Acopy or disclose the information cont= ained in this message or in any attachment. =0AAny views or opinions expre= ssed by the author of this email do not necessarily =0Areflect the views of= the University of Nottingham.=0A
=0AThis message has been checke= d for viruses but the contents of an attachment=0Amay still contain softwar= e viruses which could damage your computer system:=0Ayou are advised to per= form your own checks. Email communications with the=0AUniversity of Notting= ham may be monitored as permitted by UK legislation.=0A
______________= _________________________________
OAuth mailing list
OAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth


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


--1935884094-945985727-1339600056=:32647-- From wmills@yahoo-inc.com Wed Jun 13 08:27:38 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1081D21F84A7 for ; Wed, 13 Jun 2012 08:27:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.448 X-Spam-Level: X-Spam-Status: No, score=-17.448 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x8-b7L1aaIyR for ; Wed, 13 Jun 2012 08:27:37 -0700 (PDT) Received: from nm24-vm2.bullet.mail.ne1.yahoo.com (nm24-vm2.bullet.mail.ne1.yahoo.com [98.138.91.212]) by ietfa.amsl.com (Postfix) with SMTP id 3A2EF21F84A6 for ; Wed, 13 Jun 2012 08:27:37 -0700 (PDT) Received: from [98.138.90.51] by nm24.bullet.mail.ne1.yahoo.com with NNFMP; 13 Jun 2012 15:27:36 -0000 Received: from [98.138.88.236] by tm4.bullet.mail.ne1.yahoo.com with NNFMP; 13 Jun 2012 15:27:36 -0000 Received: from [127.0.0.1] by omp1036.mail.ne1.yahoo.com with NNFMP; 13 Jun 2012 15:27:36 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 677315.86680.bm@omp1036.mail.ne1.yahoo.com Received: (qmail 53650 invoked by uid 60001); 13 Jun 2012 15:27:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1339601256; bh=CXjd2AHHDCGUm6nZLZ2SYPvhyZdulHOcXb7OIBzIvDw=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=gaejzn+X+ngYMFi2Clvdl9zihVujQWmtM5+LZ3z1o45FdBXHeKGPmUBmF8ZMrrJ57jEM/fMuKWwtWJTO6AC2X6eDxRJ/xXgB/rKgQNR2hDhqpBovtfNFGvJMre+gDTZg0L9NVfEkMgRgyRyy1kDZCXxtAJgvD0ZNjjTDGsLWVIw= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=AfKewcGm/QuROApf+X5Ro91P47TkKqhABrSkcO86mo9F1YmctkmHgeGMl681Yj1ba9LVM2pRBlCXxIVUvc32vkgi+3c0bkPQ3bCscKZ6E1/osFmAkpKOVEKn/jVBEAInPEt3XLdPNEMiwtfE4gv3A9wejWpcIXWxKowebDmrt/c=; X-YMail-OSG: FpAbvqcVM1ksnjuFs5yyZtaO_19VWSkXRBaJl0CtvFRVsml wKuB3Bf1Rf53B17TbNI1xi4sRtVFedQjBHdUZZAI0CbOeoaTO2prUpKm99tx qwd3V7sNHXRGIFO4HFvgpwTwp54nU4nxc86PrsBx5cgh4MfB46QPN4X0b1h3 NI7DPY3yOp4YQxwkJLP7SXkYXhDG8G9zj93MgONldZPavj29G0JxQnTVeFjQ 7CTKoXL_LYmIaTfkm3cyQU0nGXX6DMEJvDpTkLHXBVN2gI.gIEzv.KG8qfcI bWR4K0oDaEg2Q0yw0l7uLQP3PW2aoEdhRHNjQQ4pmVGFf4YmGAkgbKfL.lZd bKjC1DjOV1df32LQuzGRTpYoTch4BI4zjf5J2i4A2UnDXzb6pT0EMoxw45oO fc5FVqozLKuzOntYWykxoIgPcwuVZ.fghi0VVcMlsEG603lljvAZ.CgxW5Rd zjrJ_bZBHNzQ2snLtzw.TxI_d6L.ghLX2vutm6X6WF6yNG.PAtKrJ4R_Bm95 Rj13g Received: from [209.131.62.115] by web31803.mail.mud.yahoo.com via HTTP; Wed, 13 Jun 2012 08:27:36 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.120.356233 Message-ID: <1339601256.43890.YahooMailNeo@web31803.mail.mud.yahoo.com> Date: Wed, 13 Jun 2012 08:27:36 -0700 (PDT) From: William Mills To: O Auth WG , Apps Discuss MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [OAUTH-WG] OAuth discovery registration. X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 15:27:38 -0000 =0A=0ASince for the OAUTH SASL mechanism I need discovery for clients to wo= rk, and I had to rip the in-band discovery out of that mechanism, and I nee= d it defined somewhere, I've drafted a small doc for the registration of li= nk relation types for OAuth.=A0 It's too late in the process to get this in= to the core OAuth 2 spec, and it doesn't really fit in the WebFinger. Submi= ssion info provided below.=0A=0A-bill=0A=0A--------------------------------= --------------------=0A=0AA new version of I-D, draft-wmills-oauth-lrdd-00.= txt=0Ahas been successfully submitted by William Mills and posted to the=0A= IETF repository.=0A=0AFilename:=A0=A0=A0 draft-wmills-oauth-lrdd=0ARevision= :=A0=A0=A0 00=0ATitle:=A0=A0=A0 =A0=A0=A0 LRDD Registry for OAuth 2=0ACreat= ion date:=A0=A0=A0 2012-06-13=0AWG ID:=A0=A0=A0 =A0=A0=A0 Individual Submis= sion=0ANumber of pages: 10=0AURL:=A0 =A0 =A0 =A0 =A0 =A0=A0http://www.ietf.= org/internet-drafts/draft-wmills-oauth-lrdd-00.txt=0AStatus:=A0 =A0 =A0 =A0= =A0=A0http://datatracker.ietf.org/doc/draft-wmills-oauth-lrdd=0AHtmlized:= =A0 =A0 =A0 =A0=A0http://tools.ietf.org/html/submission.filename=A0}}-00=0A= =0A=0AAbstract:=0A=A0 Defines link type registrations for the OAuth 2 authe= ntication=0A=A0 framework.=0A=0A=0A=0A=0AThe IETF Secretariat=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0=A0 From stpeter@stpeter.im Wed Jun 13 08:48:24 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A951E21F852C; Wed, 13 Jun 2012 08:48:24 -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 4mjUgpgowE2d; Wed, 13 Jun 2012 08:48:23 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id C821E21F8496; Wed, 13 Jun 2012 08:48:23 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 71A164005A; Wed, 13 Jun 2012 10:05:35 -0600 (MDT) Message-ID: <4FD8B646.3080509@stpeter.im> Date: Wed, 13 Jun 2012 09:48:22 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120601 Thunderbird/13.0 MIME-Version: 1.0 To: William Mills References: <1339601256.43890.YahooMailNeo@web31803.mail.mud.yahoo.com> In-Reply-To: <1339601256.43890.YahooMailNeo@web31803.mail.mud.yahoo.com> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: O Auth WG , Apps Discuss Subject: Re: [OAUTH-WG] OAuth discovery registration. X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 15:48:24 -0000 On 6/13/12 9:27 AM, William Mills wrote: > > Since for the OAUTH SASL mechanism I need discovery for clients to > work, and I had to rip the in-band discovery out of that mechanism, > and I need it defined somewhere, I've drafted a small doc for the > registration of link relation types for OAuth. It's too late in the > process to get this into the core OAuth 2 spec, and it doesn't really > fit in the WebFinger. Submission info provided below. Hi Bill, overall this looks good. A few nits: OLD This document defines the LRDD [RFC5988] link type registrations for the OAuth [I-D.ietf-oauth-v2] authentication framework. These link types are used during the endpoint discovery process using Web Host Metadata [I-D.hammer-hostmeta] and Webfinger [I-D.jones-appsawg-webfinger] by clients needing to discover the authentication endpoints for a service or site. It additionally defines link type registrations for OAuth 1.0a [RFC5849]. NEW This document defines the Link-based Resource Descriptor Documents (LRDD) [RFC6415] link type registrations for the OAuth [I-D.ietf-oauth-v2] authorization framework. These link types are used during the endpoint discovery process using Web Host Metadata [RFC6415] and Webfinger [I-D.jones-appsawg-webfinger] by clients needing to discover the authorization, token, and access token endpoints for an OAuth2 service or site. It additionally defines link type registrations for OAuth 1.0a [RFC5849] request initiation endpoints, authorization endpoints, and token endpoints. In Section 4.1.1, you register an "OAuth 2 Authentication Endpoint", however draft-ietf-oauth-v2 defines only an authorization endpoint, a token endpoint, and an access token endpoint. Whence this "authentication endpoint"? Is it just a typo? Also, is the lack of a link type for OAuth2 access token endpoints an oversight? It seems so. You have "Reference: [[this document]]" but I think you want: Reference: draft-ietf-oauth-v2 and Reference: RFC 5849 You can remove the reference for draft-hammer-hostmeta (RFC 6415 has what you need). Peter -- Peter Saint-Andre https://stpeter.im/ From eran@hueniverse.com Wed Jun 13 09:03:47 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02F3D21F8589; Wed, 13 Jun 2012 09:03:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6v6XFVNmB+Um; Wed, 13 Jun 2012 09:03:46 -0700 (PDT) Received: from p3plex2out01.prod.phx3.secureserver.net (p3plex2out01.prod.phx3.secureserver.net [184.168.131.12]) by ietfa.amsl.com (Postfix) with ESMTP id 7B82C21F8582; Wed, 13 Jun 2012 09:03:46 -0700 (PDT) Received: from P3PWEX2HT002.ex2.secureserver.net ([184.168.131.10]) by p3plex2out01.prod.phx3.secureserver.net with bizsmtp id Ms3l1j0060Dcg9U01s3lyn; Wed, 13 Jun 2012 09:03:45 -0700 Received: from P3PWEX2MB008.ex2.secureserver.net ([169.254.8.66]) by P3PWEX2HT002.ex2.secureserver.net ([184.168.131.10]) with mapi id 14.02.0247.003; Wed, 13 Jun 2012 09:03:45 -0700 From: Eran Hammer To: William Mills , O Auth WG , "Apps Discuss" Thread-Topic: [OAUTH-WG] OAuth discovery registration. Thread-Index: AQHNSXkSEZ9PqH6dREydEyx3GFnsppb4aOvA Date: Wed, 13 Jun 2012 16:03:45 +0000 Message-ID: <0CBAEB56DDB3A140BA8E8C124C04ECA201070221@P3PWEX2MB008.ex2.secureserver.net> References: <1339601256.43890.YahooMailNeo@web31803.mail.mud.yahoo.com> In-Reply-To: <1339601256.43890.YahooMailNeo@web31803.mail.mud.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.163.44.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] OAuth discovery registration. X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 16:03:47 -0000 These are straight link relation registrations, not LRDD (which has no regi= stration process). It is helpful to put these registrations in context and = use LRDD/host-meta as an example of their use, but the actual registration = request is simply for a link relation and nothing else. EH > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of William Mills > Sent: Wednesday, June 13, 2012 8:28 AM > To: O Auth WG; Apps Discuss > Subject: [OAUTH-WG] OAuth discovery registration. >=20 >=20 >=20 > Since for the OAUTH SASL mechanism I need discovery for clients to work, > and I had to rip the in-band discovery out of that mechanism, and I need = it > defined somewhere, I've drafted a small doc for the registration of link > relation types for OAuth.=A0 It's too late in the process to get this int= o the core > OAuth 2 spec, and it doesn't really fit in the WebFinger. Submission info > provided below. >=20 > -bill >=20 > ---------------------------------------------------- >=20 > A new version of I-D, draft-wmills-oauth-lrdd-00.txt has been successfull= y > submitted by William Mills and posted to the IETF repository. >=20 > Filename:=A0=A0=A0 draft-wmills-oauth-lrdd > Revision:=A0=A0=A0 00 > Title:=A0=A0=A0 =A0=A0=A0 LRDD Registry for OAuth 2 > Creation date:=A0=A0=A0 2012-06-13 > WG ID:=A0=A0=A0 =A0=A0=A0 Individual Submission > Number of pages: 10 > URL:=A0 =A0 =A0 =A0 =A0 =A0=A0http://www.ietf.org/internet-drafts/draft-w= mills-oauth-lrdd- > 00.txt > Status:=A0 =A0 =A0 =A0 =A0=A0http://datatracker.ietf.org/doc/draft-wmills= -oauth-lrdd > Htmlized:=A0 =A0 =A0 =A0=A0http://tools.ietf.org/html/submission.filename= =A0}}-00 >=20 >=20 > Abstract: > =A0 Defines link type registrations for the OAuth 2 authentication > =A0 framework. >=20 >=20 >=20 >=20 > The IETF Secretariat > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From torsten@lodderstedt.net Wed Jun 13 09:04:09 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C603E21F8596 for ; Wed, 13 Jun 2012 09:04:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rbbves7VpE+G for ; Wed, 13 Jun 2012 09:04:08 -0700 (PDT) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.37]) by ietfa.amsl.com (Postfix) with ESMTP id 3ADA621F857D for ; Wed, 13 Jun 2012 09:04:07 -0700 (PDT) Received: from [80.187.106.29] (helo=[2.164.16.19]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.68) (envelope-from ) id 1Seq35-0002xm-OK; Wed, 13 Jun 2012 18:04:04 +0200 References: <9dbeab60-8fe4-4828-9c52-d7af95378f4c@email.android.com> User-Agent: K-9 Mail for Android In-Reply-To: <9dbeab60-8fe4-4828-9c52-d7af95378f4c@email.android.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----R249WME3U1YV1LUB1S71DK7ND999RA" From: Torsten Lodderstedt Date: Wed, 13 Jun 2012 18:03:50 +0200 To: John Bradley Message-ID: <0ec59f35-4a66-4719-adf3-114dab0d1d48@email.android.com> X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Cc: Julian Reschke , Richard Mortier , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion needed on username and password ABNF definitions X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 16:04:10 -0000 ------R249WME3U1YV1LUB1S71DK7ND999RA Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi John, would it make sense to use a hash of the URI instead of the URI itself in your use case? regards, Torsten. John Bradley schrieb: I think that the issues are getting confused. There is a use case where the Authorization server may be a embedded app, at least in one openID case. As it won't have a separate registration or token endpoint, the client needs to make its own clientID for the request. A reasonable thing to use is the redirect URI to create a unique value that the user could use for revocation at a later point. Currently with the no : restriction we would use the host and path to crate the clientid. There are some scenarios where having the scheme as part of that would be helpful. This has nothing to do with discovery or the dynamic client registration proposal as far as I know. A URL as a client_id comes from prototype work for a personal provider that we are doing as part of openID Connect. John B. On 2012-06-13, at 7:50 AM, Torsten Lodderstedt wrote: Hi all, can anyone please explain the relation between dynamic client registration and URIs as client ids? None of the current drafts (uma or connect) seem to require URIs. regards, Torsten. Jianhua Shao schrieb: Hello, Dynamic client registration is very useful if client or resource or authorisation server is not permanently available. A typical case is that is the resource or authorisation server is in mobile platform, the connection is not always available. Another typical case is that authorisation server do not necessary to have client pre-registered on itself. At moment, industry like facebook would like developer to register a app on its app centre first, and then ask user auth to use the app. We are researchers from Digital Economy Research Institute. We have this problem When we developing Dataware that could manage the control of access to personal data. We play around our solution base on Oauth2: https://github.com/jianhuashao/dataware.catalog/wiki We are in the list to receive your mail list, but currently need moderate to post any message. cc my colleague, Richard Mortier Best Jian On 12 Jun 2012, at 21:08, Eran Hammer wrote: The only distinction I would make is between removing flexibiliy to proactively enabling future extensibility. I would stop short of perscribing encoding in order to fit uri into the Basic auth fields. But if there is a way to allow this to be less restrictive without clean interop issues, that would be nice. I do agree we need some actual use cases before we spend much more time on this. EH From: William Mills [mailto:wmills@yahoo-inc.com] Sent: Tuesday, June 12, 2012 1:04 PM To: Eran Hammer; Mike Jones; Hannes Tschofenig; Julian Reschke Cc: oauth@ietf.org Subject: Dynamic clients, URI, and stuff Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions I think dynamic client registration is something we have not talked out enough yet. There's a pretty clear use case for dynamic registration. Does identifying the client with a URI allow some form of OpenID-ish flow for this? Is the client ID as a URI a way to allow a trusted site to provide metadata about the client? Is that URI a way to hit an IDP we trust to validate the client in some way with the provided secret? I guess what I'm looking for here is a concrete use case/problem to solve, rather then leaving a hook we think is the right thing. -bill _____________________________________________ From: Eran Hammer To: Mike Jones ; William Mills ; Hannes Tschofenig ; Julian Reschke Cc: "oauth@ietf.org" Sent: Tuesday, June 12, 2012 11:39 AM Subject: RE: [OAUTH-WG] Discussion needed on username and password ABNF definitions Is the use case of using URI as client ids important? It seems like something that might become useful in the future where clients can use their verifiable servers to bypass client registration and simly use a URI the server can validate via some other means. I just want to make sure those thinking about more complex use cases involving dynamic registration or distri buted client manamgenet are aware of this potential restriction. I'm fine either way. EH From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones Sent: Tuesday, June 12, 2012 11:27 AM To: William Mills; Hannes Tschofenig; Julian Reschke Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions Not internationalizing fields intended for machine consumption only is already a precedent set and agreed to by the working group, so let me second Bill’s point in that regard. For instance, neither “scope†nor “error†allow non-ASCII characters. Julian, if you want different ABNF text than the text I wrote below, I believe it would be most useful if you would provide the exact replace wording that you’d like to see instead of it. Then there’s no possibility of misunderstanding the intent of suggested changes. Thanks all, -- Mike From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of William Mills Sent: Tuesday, June 12, 2012 11:18 AM To: Hannes Tschofenig; Julian Reschke Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions I agree generally with your assumption about clients, but rather than saying "clients are devices" I think it makes much more sense to say "clients are NOT users, so client_id need not be internationalized". In practical terms there is very little to argue for anythign beyond ASCII in a client_secret, base64 encoding or the equivalent being a fine way to transport arbitrary bits in a portable/reasonable way. I argue that client_id need not be internationalized because I assume that any really internationalized application will have an internationalized presentation layer that's presenting a pretty name for the client_id. -bill _____________________________________________ From: Hannes Tschofenig To: Julian Reschke Cc: "oauth@ietf.org" Sent: Tuesday, June 12, 2012 11:01 AM Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions I had a chat with Julian yesterday and here is my short summary. Section 2.3 of the core draft defines client authentication based on two mechanisms (and provides room for extensions):http://tools.ietf.org/html/draft-ietf-oauth-v2-27#section-2.3 1) HTTP Basic Authentication 2) A custom OAuth authentication mechanism (which uses client_id and client_secret) With HTTP Basic authentication the problem is that this is a legacy technology and there is no internationalization support. With our brand new custom OAuth authentication mechanism we have more options. One possible approach is to say that the clients are devices (and not end users) and therefore internationalization does not matter. Is it, however, really true that only US-ASCII characters will appear in the client_id and also in the client_secret? Here we have the possibility to define something better. In any case we have to restrict the characters that are used in these two authentication mechanisms since they could conflict with the way how we transport the data over the underlying protocol. Julian mentioned this in his previous mails. Julian, maybe you can provide a detailed text proposal for how to address your comment in case we go for UTF8 (with % encoding) for the custom OAuth client authentication mechanism? Ciao Hannes On Jun 12, 2012, at 11:54 AM, Julian Reschke wrote: > On 2012-06-12 00:16, Mike Jones wrote: >> Reviewing the feedback from Julian, John, and James, I'm coming to the conclusion that client_id and client_secret, being for machines and not humans, shou ld be ASCII, whereas username and password should be Unicode, since they are for humans. Per John's feedback, client_id can not contain a colon and be compatible with HTTP Basic. > > I'm not sure that restricting the character repertoire just because one way to send requires this is the right approach. My preference would be not to put this into the ABNF, and just to point out that certain characters will not work over certain transports, and to just advise to avoid them. > >> Therefore, I'd like to propose these updated ABNF definitions: >> >> VSCHAR = %20-7E >> NOCOLONVSCHAR = %x20-39 / %x3B-7E >> UNICODENOCTRLCHAR = >> >> client-id = *NOCOLONVSCHAR >> client_secret = *VSCHAR >> >> username = *UNICODENOCTRLCHAR >> password = *UNICODENOCTRLCHAR > > In this case you should add an introductory statement pointing out that the ABNF defines the grammar in terms of Unicode code points, not octets (as it is the case most of the time). > >> It turns out that non-ASCII characters are OK for username and password because the Core spec only passes them in the form body - not using HTTP Basic - and UTF-8 encoding is specified. > > I'll send a separate mail about that, the current text in the spec is way too unspecific. > >> -- Mike >> >> P.S. If anyone has a better ABNF for UNICODENOCTRLCHAR than "", please send it to me! > > As noted before, here's an example: > > Best regards, Julian > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ------R249WME3U1YV1LUB1S71DK7ND999RA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi John,

would it make sense to use a hash of the URI instead of the URI itself in your use case?

regards,
Torsten.



John Bradley <ve7jtb@ve7jtb.com> schrieb:
I think that the issues are getting confused.

There is a use case where the Authorization server may be a embedded app, at least in one openID case.    As it won't have a separate registration or token endpoint,  the client needs to make its own clientID for the request.   A reasonable thing to use is the redirect URI to create a unique value that the user could use for revocation at a later point.

Currently with the no : restriction we would use the host and path to crate the clientid.
There are some scenarios where having the scheme as part of that would be helpful.

This has nothing to do with discovery or the dynamic client registration proposal as far as I know.

A URL as a client_id comes from prototype work for a personal provider that we are doing as part of openID Connect.

John B.
On 2012-06-13, at 7:50 AM, To rsten Lodderstedt wrote:

Hi all,

can anyone please explain the relation between dynamic client registration and URIs as client ids? None of the current drafts (uma or connect) seem to require URIs.

regards,
Torsten.



Jianhua Shao <psxjs4@nottingham.ac.uk> schrieb:
Hello,

Dynamic client registration is very useful if client or resource or authorisation server is not permanently available. 
A typical case is that is the resource or authorisation server is in mobile platform, the connection is not always available. 
Another typical case is that authorisation server do not necessary to have client pre-registered on itself. At moment, industry like facebook would like developer to register a app on its app centre first, and then ask user auth to use the app. 

We are researchers from Digital Economy Research Institute. We have this problem When we developing Dataware that could manage the control of access to personal data. We play around our solution base on Oauth2: https://github.com/jianhuashao/dataware.catalog/wiki

We are in the list to receive your mail list, but currently need moderate to post any message. cc my colleague, Richard Mortier
Best
Jian


On 12 Jun 2012, at 21:08, Eran Hammer wrote:

The only distinction I would make is between removing flexibiliy to proactively enabling future extensibility. I would stop short of perscribing encoding in order to fit uri into the Basic auth fields. But if there is a way to allow this to be less restrictive without clean interop issues, that would be nice.
 
I do agree we need some actual use cases before we spend much more time on this.
 
EH
 
From: William Mills [mailto:wmills@yahoo-inc.com] 
Sent: Tuesday, June 12, 2012 1:04 PM
To: Eran Hammer; Mike Jones; Hannes Tschofenig; Julian Reschke
Cc: oauth@ietf.org
Subject: Dynamic clients, URI, and stuff Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions
 
I think dynamic client registration is something we have not talked out enough yet.  There's a pretty clear use case for dynamic registration.  
 
Does identifying the client with a URI allow some form of OpenID-ish flow for this? 
Is the client ID as a URI a way to allow a trusted site to provide metadata about the client?
Is that URI a way to hit an IDP we trust to validate the client in some way with the provided secret?
 
I guess what I'm looking for here is a concrete use case/problem to solve, rather then leaving a hook we think is the right thing.
 
-bill
 
 
From: Eran Hammer <eran@hueniverse.com>
To: Mike Jones <Michael.Jones@microsoft.com>; William Mills <wmills@yahoo-inc.com>; Hannes Tschofenig <hannes.tschofenig@gmx.net>; Julian Reschke <julian.reschke@gmx.de> 
Cc: "oauth@ietf.org" <oauth@ietf.org> 
Sent: Tuesday, June 12, 2012 11:39 AM
Subject: RE: [OAUTH-WG] Discussion needed on username and password ABNF definitions
 
Is the use case of using URI as client ids important? It seems like something that might become useful in the future where clients can use their verifiable servers to bypass client registration and simly use a URI the server can validate via some other means.
 
I just want to make sure those thinking about more complex use cases involving dynamic registration or distri buted client manamgenet are aware of this potential restriction.
 
I'm fine either way.
 
EH
 
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Tuesday, June 12, 2012 11:27 AM
To: William Mills; Hannes Tschofenig; Julian Reschke
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions
 
Not internationalizing fields intended for machine consumption only is already a precedent set and agreed to by the working group, so let me second Bill’s point in that regard.  For instance, neither “scope†nor “error†allow non-ASCII characters.
 
Julian, if you want different ABNF text than the text I wrote below, I believe it would be most useful if you would provide the exact replace wording that you’d like to see instead of it.  Then there’s no possibility of misunderstanding the intent of suggested changes.
 
                                                            Thanks all,
                                                            -- Mike
 
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of William Mills
Sent: Tuesday, June 12, 2012 11:18 AM
To: Hannes Tschofenig; Julian Reschke
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions
 
I agree generally with your assumption about clients, but rather than saying "clients are devices" I think it makes much more sense to say "clients are NOT users, so client_id need not be internationalized".  In practical terms there is very little to argue for anythign beyond ASCII in a client_secret, base64 encoding or the equivalent being a fine way to transport arbitrary bits in a portable/reasonable way.
 
I argue that client_id need not be internationalized because I assume that any really internationalized application will have an internationalized presentation layer that's presenting a pretty name for the client_id.
 
-bill
 
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
To: Julian Reschke <julian.reschke@gmx.de> 
Cc: "oauth@ietf.org" <oauth@ietf.org> 
Sent: Tuesday, June 12, 2012 11:01 AM
Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions

I had a chat with Julian yesterday and here is my short summary. 

Section 2.3 of the core draft defines client authentication based on two mechanisms (and provides room for extensions):http://tools.ietf.org/html/draft-ietf-oauth-v2-27#section-2.3

1) HTTP Basic Authentication

2) A custom OAuth authentication mechanism (which uses client_id and client_secret)

With HTTP Basic authentication the problem is that this is a legacy technology and there is no internationalization support. 

With our brand new custom OAuth authentication mechanism we have more options. 

One possible approach is to say that the clients are devices (and not end users) and therefore internationalization does not matter. 

Is it, however, really true that only US-ASCII characters will appear in the client_id and also in the client_secret? 

Here we have the possibility to define something better. 

In any case we have to restrict the characters that are used in these two authentication mechanisms since they could conflict with the way how we transport the data over the underlying protocol. Julian mentioned this in his previous mails. 

Julian, maybe you can provide a detailed text proposal for how to address your comment in case we go for UTF8 (with % encoding) for the custom OAuth client authentication mechanism? 

Ciao
Hannes

On Jun 12, 2012, at 11:54 AM, Julian Reschke wrote:

> On 2012-06-12 00:16, Mike Jones wrote:
>> Reviewing the feedback from Julian, John, and James, I'm coming to the conclusion that client_id and client_secret, being for machines and not humans, shou ld be ASCII, whereas username and password should be Unicode, since they are for humans.  Per John's feedback, client_id can not contain a colon and be compatible with HTTP Basic.
> 
> I'm not sure that restricting the character repertoire just because one way to send requires this is the right approach. My preference would be not to put this into the ABNF, and just to point out that certain characters will not work over certain transports, and to just advise to avoid them.
> 
>> Therefore, I'd like to propose these updated ABNF definitions:
>> 
>>    VSCHAR = %20-7E
>>    NOCOLONVSCHAR = %x20-39 / %x3B-7E
>>    UNICODENOCTRLCHAR = <Any Unicode character other than ( %x0-1F / %x7F )>
>> 
>>    client-id = *NOCOLONVSCHAR
>>    client_secret = *VSCHAR
>> 
>>    username = *UNICODENOCTRLCHAR
>>    password = *UNICODENOCTRLCHAR
> 
> In this case you should add an introductory statement pointing out that the ABNF defines the grammar in terms of Unicode code points, not octets (as it is the case most of the time).
> 
>> It turns out that non-ASCII characters are OK for username and password because the Core spec only passes them in the form body - not using HTTP Basic - and UTF-8 encoding is specified.
> 
> I'll send a separate mail about that, the current text in the spec is way too unspecific.
> 
>>                 -- Mike
>> 
>> P.S.  If anyone has a better ABNF for UNICODENOCTRLCHAR than "<Any Unicode character other than ( %x0-1F / %x7F )>", please send it to me!
> 
> As noted before, here's an example: <http://greenbytes.de/tech/webdav/rfc5323.html#rfc.section.5.15.1>
> 
> Best regards, Julian
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

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

 

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

This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham.

This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.

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

------R249WME3U1YV1LUB1S71DK7ND999RA-- From stpeter@stpeter.im Wed Jun 13 09:08:10 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E65CC21F848F; Wed, 13 Jun 2012 09:08:10 -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 G9A7P2mgZF5S; Wed, 13 Jun 2012 09:08:10 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 9181C21F8484; Wed, 13 Jun 2012 09:08:10 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2EEAF4005A; Wed, 13 Jun 2012 10:25:22 -0600 (MDT) Message-ID: <4FD8BAE7.4000005@stpeter.im> Date: Wed, 13 Jun 2012 10:08:07 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120601 Thunderbird/13.0 MIME-Version: 1.0 To: Eran Hammer References: <1339601256.43890.YahooMailNeo@web31803.mail.mud.yahoo.com> <0CBAEB56DDB3A140BA8E8C124C04ECA201070221@P3PWEX2MB008.ex2.secureserver.net> In-Reply-To: <0CBAEB56DDB3A140BA8E8C124C04ECA201070221@P3PWEX2MB008.ex2.secureserver.net> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: O Auth WG , Apps Discuss Subject: Re: [OAUTH-WG] OAuth discovery registration. X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 16:08:11 -0000 On 6/13/12 10:03 AM, Eran Hammer wrote: > These are straight link relation registrations, not LRDD (which has no registration process). Right you are! /psa From laurentwalter.goix@telecomitalia.it Wed Jun 13 09:44:46 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C27D21F85A3; Wed, 13 Jun 2012 09:44:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.719 X-Spam-Level: X-Spam-Status: No, score=-1.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, 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 Seg+hSF8id4e; Wed, 13 Jun 2012 09:44:46 -0700 (PDT) Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by ietfa.amsl.com (Postfix) with ESMTP id A14E221F855F; Wed, 13 Jun 2012 09:44:45 -0700 (PDT) Received: from GRFHUB703BA020.griffon.local (10.188.101.113) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.3.245.1; Wed, 13 Jun 2012 18:44:41 +0200 Received: from GRFMBX704BA020.griffon.local ([10.188.101.16]) by GRFHUB703BA020.griffon.local ([10.188.101.113]) with mapi; Wed, 13 Jun 2012 18:44:41 +0200 From: Goix Laurent Walter To: Peter Saint-Andre , William Mills Date: Wed, 13 Jun 2012 18:44:19 +0200 Thread-Topic: [apps-discuss] [OAUTH-WG] OAuth discovery registration. Thread-Index: Ac1JfALVoc1LenjrTn2gdPnLEga53QABrMsw Message-ID: References: <1339601256.43890.YahooMailNeo@web31803.mail.mud.yahoo.com> <4FD8B646.3080509@stpeter.im> In-Reply-To: <4FD8B646.3080509@stpeter.im> Accept-Language: en-US, it-IT Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, it-IT x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: O Auth WG , Apps Discuss Subject: [OAUTH-WG] R: [apps-discuss] OAuth discovery registration. X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 16:44:46 -0000 Thank you William for this initiative. I had similar concerns than Peter on authn vs authz. Under section 4.1.1 I would suggest to use "oauth2-authorize" instead of "o= auth2-authenticator", to be consistent with the "oauth2-token" pattern and = with the concepts of the oauth2 draft. The header of the pages still reference sasl/gss-api and would need to be u= pdated. Also, an example and/or use case section could be beneficial, e.g. to descr= ibe its usage in an xrd document. Other use cases may be mentioned as well = probably. I have also noticed that your draft is mentioned as "informational". It is = indeed your target or only a typo? Thanks walter > -----Messaggio originale----- > Da: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] = Per > conto di Peter Saint-Andre > Inviato: mercoled=EC 13 giugno 2012 17.48 > A: William Mills > Cc: O Auth WG; Apps Discuss > Oggetto: Re: [apps-discuss] [OAUTH-WG] OAuth discovery registration. > > On 6/13/12 9:27 AM, William Mills wrote: > > > > Since for the OAUTH SASL mechanism I need discovery for clients to > > work, and I had to rip the in-band discovery out of that mechanism, > > and I need it defined somewhere, I've drafted a small doc for the > > registration of link relation types for OAuth. It's too late in the > > process to get this into the core OAuth 2 spec, and it doesn't really > > fit in the WebFinger. Submission info provided below. > > Hi Bill, overall this looks good. A few nits: > > OLD > This document defines the LRDD [RFC5988] link type registrations for > the OAuth [I-D.ietf-oauth-v2] authentication framework. These link > types are used during the endpoint discovery process using Web Host > Metadata [I-D.hammer-hostmeta] and Webfinger > [I-D.jones-appsawg-webfinger] by clients needing to discover the > authentication endpoints for a service or site. It additionally > defines link type registrations for OAuth 1.0a [RFC5849]. > > NEW > This document defines the Link-based Resource Descriptor > Documents (LRDD) [RFC6415] link type registrations for the > OAuth [I-D.ietf-oauth-v2] authorization framework. These link > types are used during the endpoint discovery process using Web > Host Metadata [RFC6415] and Webfinger > [I-D.jones-appsawg-webfinger] by clients needing to discover the > authorization, token, and access token endpoints for an OAuth2 > service or site. It additionally defines link type registrations for > OAuth > 1.0a [RFC5849] request initiation endpoints, authorization endpoints, > and token endpoints. > > In Section 4.1.1, you register an "OAuth 2 Authentication Endpoint", > however draft-ietf-oauth-v2 defines only an authorization endpoint, a > token endpoint, and an access token endpoint. Whence this > "authentication endpoint"? Is it just a typo? > > Also, is the lack of a link type for OAuth2 access token endpoints an > oversight? It seems so. > > You have "Reference: [[this document]]" but I think you want: > > Reference: draft-ietf-oauth-v2 > > and > > Reference: RFC 5849 > > You can remove the reference for draft-hammer-hostmeta (RFC 6415 has > what you need). > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ > > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. From wmills@yahoo-inc.com Wed Jun 13 11:19:56 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5241621F84FD for ; Wed, 13 Jun 2012 11:19:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.464 X-Spam-Level: X-Spam-Status: No, score=-17.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MUAG2zkdEKV2 for ; Wed, 13 Jun 2012 11:19:55 -0700 (PDT) Received: from nm8-vm0.bullet.mail.sp2.yahoo.com (nm8-vm0.bullet.mail.sp2.yahoo.com [98.139.91.194]) by ietfa.amsl.com (Postfix) with SMTP id 6DDD821F84EC for ; Wed, 13 Jun 2012 11:19:55 -0700 (PDT) Received: from [98.139.91.65] by nm8.bullet.mail.sp2.yahoo.com with NNFMP; 13 Jun 2012 18:19:55 -0000 Received: from [98.139.91.6] by tm5.bullet.mail.sp2.yahoo.com with NNFMP; 13 Jun 2012 18:19:55 -0000 Received: from [127.0.0.1] by omp1006.mail.sp2.yahoo.com with NNFMP; 13 Jun 2012 18:19:55 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 185534.15467.bm@omp1006.mail.sp2.yahoo.com Received: (qmail 43502 invoked by uid 60001); 13 Jun 2012 18:19:54 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1339611594; bh=bFg0LiwI25t9lff7jNuKxpxkg+Lee4vZC6+A5Mxy/e8=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=fS9ZmN6Ckl4Xlc+XrlJ0VmZRFdh2C/DyAb2avWp2t6IQwM1XPHk0B3Xy+jDD6GtwP8tY8HKEs7NMi5If4hZmM0rYDGUIeILirZ8C+d8qlEniTAKn5AFKibq3rPlR+hjVMa+Fbnob1Iovpmv/ACViWMWW0tDBeLKqU+j/LMklYGI= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=eggE3nn2E5ormUdYuNW8bASValVOH7/r4qaVdRGHQM1YB3MXEyLyHNnqv4AucEGGuNSENYpSCmETadMK0ROv6PZl3sTSatbaMaG0YeE1dOUWIasaT7tCzMXzcwVe9rZqBnZiscLeBPjUs8HRNUjpJ9LOEn5UuxGhi2JzrbiKOO0=; X-YMail-OSG: iO9qnJgVM1lSz3K5mw.nw.MORKTrm_U4x9Ra.qvB36bJ0YV Rs55lJ2bJxF2H9nSgC059Yr2CjS3D0kKh1spDyPb5aLIc3o4q2Clrkw.Dr8m afvgWsJ218nzgpVKTvIjm.9jqZ6Pw.T7_ejSsCmaRUufLDuD7hiSxgzWngf9 FIslMJk8nz4m644efgfeZsNo3YqGIkDgPhNOpa9jQItq_ClGdPUvj__oUwIt Tf3yKOkSuwXRMRancp10.YBRmCvNnC3jqVjnR24tlYDJRgDu_oyrYhvJyqrd NI3bU_vxD_T5yc3eaySqnqHVxlStXNedEhTymHITc_azl4rO0.zPCfIhDXqq tLpCRqeEdD7z4BhfQ11xNO3VXYmydchx5umvUufLzEKxfqEzPCtV8Kv2pbFn pFxgzWFEiu7s4WPaW3X8MauA7DVBcpauh1UFPJtlRGQiCgWUz3YOxGP1K_EP Ym3BFT_3uvL_ArvAjGoa5HVut.foYroLbOHb_3_piFc9ODpU- Received: from [209.131.62.115] by web31806.mail.mud.yahoo.com via HTTP; Wed, 13 Jun 2012 11:19:54 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.120.356233 References: <1339601256.43890.YahooMailNeo@web31803.mail.mud.yahoo.com> <4FD8B646.3080509@stpeter.im> Message-ID: <1339611594.26607.YahooMailNeo@web31806.mail.mud.yahoo.com> Date: Wed, 13 Jun 2012 11:19:54 -0700 (PDT) From: William Mills To: Goix Laurent Walter , Peter Saint-Andre In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: O Auth WG , Apps Discuss Subject: Re: [OAUTH-WG] R: [apps-discuss] OAuth discovery registration. X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 18:19:56 -0000 On the informational status, that seemed right, but I honestly don't know w= hat the correct choice is here.=A0=A0 The actual registration happens via e= -mail I believe, not via this document.=0A=0AThanks for the feedback!=0A=0A= -bill=0A=0A=0A=0A----- Original Message -----=0A> From: Goix Laurent Walter= =0A> To: Peter Saint-Andre ; William Mills =0A> Cc: O Auth WG ; Apps Discuss =0A> Sent: Wednesday, June 13= , 2012 9:44 AM=0A> Subject: R: [apps-discuss] [OAUTH-WG] OAuth discovery re= gistration.=0A> =0A>T hank you William for this initiative.=0A> =0A> I had = similar concerns than Peter on authn vs authz.=0A> =0A> Under section 4.1.1= I would suggest to use "oauth2-authorize" instead =0A> of "oauth2-authenti= cator", to be consistent with the =0A> "oauth2-token" pattern and with the = concepts of the oauth2 draft.=0A> =0A> The header of the pages still refere= nce sasl/gss-api and would need to be =0A> updated.=0A> =0A> Also, an examp= le and/or use case section could be beneficial, e.g. to describe =0A> its u= sage in an xrd document. Other use cases may be mentioned as well probably.= =0A> =0A> I have also noticed that your draft is mentioned as "informationa= l". =0A> It is indeed your target or only a typo?=0A> =0A> Thanks=0A> walte= r=0A> =0A>> -----Messaggio originale-----=0A>> Da: apps-discuss-bounces@i= etf.org [mailto:apps-discuss-bounces@ietf.org] =0A> Per=0A>> conto di Pete= r Saint-Andre=0A>> Inviato: mercoled=EC 13 giugno 2012 17.48=0A>> A: Will= iam Mills=0A>> Cc: O Auth WG; Apps Discuss=0A>> Oggetto: Re: [apps-discus= s] [OAUTH-WG] OAuth discovery registration.=0A>> =0A>> On 6/13/12 9:27 AM,= William Mills wrote:=0A>> >=0A>> > Since for the OAUTH SASL mechanism I = need discovery for clients to=0A>> > work, and I had to rip the in-band di= scovery out of that mechanism,=0A>> > and I need it defined somewhere, I'v= e drafted a small doc for the=0A>> > registration of link relation types f= or OAuth.=A0 It's too late in =0A> the=0A>> > process to get this into the= core OAuth 2 spec, and it doesn't =0A> really=0A>> > fit in the WebFinger= . Submission info provided below.=0A>> =0A>> Hi Bill, overall this looks g= ood. A few nits:=0A>> =0A>> OLD=0A>> =A0 =A0 This document defines the LRD= D [RFC5988] link type registrations for=0A>> =A0 =A0 the OAuth [I-D.ietf-oa= uth-v2] authentication framework.=A0 These link=0A>> =A0 =A0 types are used= during the endpoint discovery process using Web Host=0A>> =A0 =A0 Metadata= [I-D.hammer-hostmeta] and Webfinger=0A>> =A0 =A0 [I-D.jones-appsawg-webfin= ger] by clients needing to discover the=0A>> =A0 =A0 authentication endpoin= ts for a service or site.=A0 It additionally=0A>> =A0 =A0 defines link type= registrations for OAuth 1.0a [RFC5849].=0A>> =0A>> NEW=0A>> =A0 =A0 This = document defines the Link-based Resource Descriptor=0A>> =A0 =A0 Documents = (LRDD) [RFC6415] link type registrations for the=0A>> =A0 =A0 OAuth [I-D.ie= tf-oauth-v2] authorization framework.=A0 These link=0A>> =A0 =A0 types are = used during the endpoint discovery process using Web=0A>> =A0 =A0 Host Meta= data [RFC6415] and Webfinger=0A>> =A0 =A0 [I-D.jones-appsawg-webfinger] by = clients needing to discover the=0A>> =A0 =A0 authorization, token, and acce= ss token endpoints for an OAuth2=0A>> =A0 =A0 service or site.=A0 It additi= onally defines link type registrations for=0A>> OAuth=0A>> =A0 =A0 1.0a [R= FC5849] request initiation endpoints, authorization endpoints,=0A>> =A0 =A0= and token endpoints.=0A>> =0A>> In Section 4.1.1, you register an "OAuth = 2 Authentication =0A> Endpoint",=0A>> however draft-ietf-oauth-v2 defines = only an authorization endpoint, a=0A>> token endpoint, and an access token= endpoint. Whence this=0A>> "authentication endpoint"? Is it just a typo?= =0A>> =0A>> Also, is the lack of a link type for OAuth2 access token endpo= ints an=0A>> oversight? It seems so.=0A>> =0A>> You have "Reference: [[th= is document]]" but I think you want:=0A>> =0A>> Reference: draft-ietf-oaut= h-v2=0A>> =0A>> and=0A>> =0A>> Reference: RFC 5849=0A>> =0A>> You can re= move the reference for draft-hammer-hostmeta (RFC 6415 has=0A>> what you n= eed).=0A>> =0A>> Peter=0A>> =0A>> --=0A>> Peter Saint-Andre=0A>> https:= //stpeter.im/=0A>> =0A>> =0A>> =0A>> =0A>> _______________________________= ________________=0A>> apps-discuss mailing list=0A>> apps-discuss@ietf.or= g=0A>> https://www.ietf.org/mailman/listinfo/apps-discuss=0A> =0A> Questo = messaggio e i suoi allegati sono indirizzati esclusivamente alle persone = =0A> indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a =0A> conoscenza di queste informazioni sono rigorosamente vietate. Qualor= a abbiate =0A> ricevuto questo documento per errore siete cortesemente preg= ati di darne =0A> immediata comunicazione al mittente e di provvedere alla = sua distruzione, =0A> Grazie.=0A> =0A> This e-mail and any attachments is c= onfidential and may contain privileged =0A> information intended for the ad= dressee(s) only. Dissemination, copying, printing =0A> or use by anybody el= se is unauthorised. If you are not the intended recipient, =0A> please dele= te this message and any attachments and advise the sender by return =0A> e-= mail, Thanks.=0A> From eran@hueniverse.com Wed Jun 13 11:35:01 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7ACC11E809B; Wed, 13 Jun 2012 11:35:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UqwzrJNrqM6w; Wed, 13 Jun 2012 11:35:01 -0700 (PDT) Received: from p3plex2out02.prod.phx3.secureserver.net (p3plex2out02.prod.phx3.secureserver.net [184.168.131.14]) by ietfa.amsl.com (Postfix) with ESMTP id C7ADA11E8088; Wed, 13 Jun 2012 11:35:00 -0700 (PDT) Received: from P3PWEX2HT003.ex2.secureserver.net ([184.168.131.11]) by p3plex2out02.prod.phx3.secureserver.net with bizsmtp id Mub01j0080EuLVk01ub0Jp; Wed, 13 Jun 2012 11:35:00 -0700 Received: from P3PWEX2MB008.ex2.secureserver.net ([169.254.8.66]) by P3PWEX2HT003.ex2.secureserver.net ([184.168.131.11]) with mapi id 14.02.0247.003; Wed, 13 Jun 2012 11:35:00 -0700 From: Eran Hammer To: William Mills , Goix Laurent Walter , Peter Saint-Andre Thread-Topic: [OAUTH-WG] R: [apps-discuss] OAuth discovery registration. Thread-Index: AQHNSYPh5+Oe6W1CcUOmcxnfpZl4X5b5BJMA//+OYyA= Date: Wed, 13 Jun 2012 18:34:59 +0000 Message-ID: <0CBAEB56DDB3A140BA8E8C124C04ECA2010707E7@P3PWEX2MB008.ex2.secureserver.net> References: <1339601256.43890.YahooMailNeo@web31803.mail.mud.yahoo.com> <4FD8B646.3080509@stpeter.im> <1339611594.26607.YahooMailNeo@web31806.mail.mud.yahoo.com> In-Reply-To: <1339611594.26607.YahooMailNeo@web31806.mail.mud.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.163.44.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: O Auth WG , Apps Discuss Subject: Re: [OAUTH-WG] R: [apps-discuss] OAuth discovery registration. X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 18:35:02 -0000 The registration is a simple process. You write a draft and get the designa= ted expert to review. They can decide to wait until the document is publish= ed/approved or if they think it is likely to be approved, get the registrat= ion request published earlier. They can also reject it with a reason. I would encourage you to contact the link registry list and ask for feedbac= k before making the official request which you can do once the draft is sta= ble. EH > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of William Mills > Sent: Wednesday, June 13, 2012 11:20 AM > To: Goix Laurent Walter; Peter Saint-Andre > Cc: O Auth WG; Apps Discuss > Subject: Re: [OAUTH-WG] R: [apps-discuss] OAuth discovery registration. >=20 > On the informational status, that seemed right, but I honestly don't know > what the correct choice is here.=A0=A0 The actual registration happens vi= a e-mail I > believe, not via this document. >=20 > Thanks for the feedback! >=20 > -bill >=20 >=20 >=20 > ----- Original Message ----- > > From: Goix Laurent Walter > > To: Peter Saint-Andre ; William Mills > > > > Cc: O Auth WG ; Apps Discuss > > Sent: Wednesday, June 13, 2012 9:44 AM > > Subject: R: [apps-discuss] [OAUTH-WG] OAuth discovery registration. > > > >T hank you William for this initiative. > > > > I had similar concerns than Peter on authn vs authz. > > > > Under section 4.1.1 I would suggest to use "oauth2-authorize" instead > > of "oauth2-authenticator", to be consistent with the "oauth2-token" > > pattern and with the concepts of the oauth2 draft. > > > > The header of the pages still reference sasl/gss-api and would need to > > be updated. > > > > Also, an example and/or use case section could be beneficial, e.g. to > > describe its usage in an xrd document. Other use cases may be mentioned > as well probably. > > > > I have also noticed that your draft is mentioned as "informational". > > It is indeed your target or only a typo? > > > > Thanks > > walter > > > >> -----Messaggio originale----- > >> Da: apps-discuss-bounces@ietf.org > >> [mailto:apps-discuss-bounces@ietf.org] > > Per > >> conto di Peter Saint-Andre > >> Inviato: mercoled=EC 13 giugno 2012 17.48 > >> A: William Mills > >> Cc: O Auth WG; Apps Discuss > >> Oggetto: Re: [apps-discuss] [OAUTH-WG] OAuth discovery registration. > >> > >> On 6/13/12 9:27 AM, William Mills wrote: > >> > > >> > Since for the OAUTH SASL mechanism I need discovery for clients to > >> > work, and I had to rip the in-band discovery out of that mechanism, > >> > and I need it defined somewhere, I've drafted a small doc for the > >> > registration of link relation types for OAuth.=A0 It's too late in > > the > >> > process to get this into the core OAuth 2 spec, and it doesn't > > really > >> > fit in the WebFinger. Submission info provided below. > >> > >> Hi Bill, overall this looks good. A few nits: > >> > >> OLD > >> =A0 =A0 This document defines the LRDD [RFC5988] link type registratio= ns > >> for > >> =A0 =A0 the OAuth [I-D.ietf-oauth-v2] authentication framework.=A0 The= se > >> link > >> =A0 =A0 types are used during the endpoint discovery process using Web > >> Host > >> =A0 =A0 Metadata [I-D.hammer-hostmeta] and Webfinger > >> =A0 =A0 [I-D.jones-appsawg-webfinger] by clients needing to discover t= he > >> =A0 =A0 authentication endpoints for a service or site.=A0 It addition= ally > >> =A0 =A0 defines link type registrations for OAuth 1.0a [RFC5849]. > >> > >> NEW > >> =A0 =A0 This document defines the Link-based Resource Descriptor > >> =A0 =A0 Documents (LRDD) [RFC6415] link type registrations for the > >> =A0 =A0 OAuth [I-D.ietf-oauth-v2] authorization framework.=A0 These li= nk > >> =A0 =A0 types are used during the endpoint discovery process using Web > >> =A0 =A0 Host Metadata [RFC6415] and Webfinger > >> =A0 =A0 [I-D.jones-appsawg-webfinger] by clients needing to discover t= he > >> =A0 =A0 authorization, token, and access token endpoints for an OAuth2 > >> =A0 =A0 service or site.=A0 It additionally defines link type registra= tions > >> for OAuth > >> =A0 =A0 1.0a [RFC5849] request initiation endpoints, authorization > >> endpoints, > >> =A0 =A0 and token endpoints. > >> > >> In Section 4.1.1, you register an "OAuth 2 Authentication > > Endpoint", > >> however draft-ietf-oauth-v2 defines only an authorization endpoint, > >> a token endpoint, and an access token endpoint. Whence this > >> "authentication endpoint"? Is it just a typo? > >> > >> Also, is the lack of a link type for OAuth2 access token endpoints > >> an oversight? It seems so. > >> > >> You have "Reference: [[this document]]" but I think you want: > >> > >> Reference: draft-ietf-oauth-v2 > >> > >> and > >> > >> Reference: RFC 5849 > >> > >> You can remove the reference for draft-hammer-hostmeta (RFC 6415 has > >> what you need). > >> > >> Peter > >> > >> -- > >> Peter Saint-Andre > >> https://stpeter.im/ > >> > >> > >> > >> > >> _______________________________________________ > >> apps-discuss mailing list > >> apps-discuss@ietf.org > >> https://www.ietf.org/mailman/listinfo/apps-discuss > > > > Questo messaggio e i suoi allegati sono indirizzati esclusivamente > > alle persone indicate. La diffusione, copia o qualsiasi altra azione > > derivante dalla conoscenza di queste informazioni sono rigorosamente > > vietate. Qualora abbiate ricevuto questo documento per errore siete > > cortesemente pregati di darne immediata comunicazione al mittente e di > > provvedere alla sua distruzione, Grazie. > > > > This e-mail and any attachments is confidential and may contain > > privileged information intended for the addressee(s) only. > > Dissemination, copying, printing or use by anybody else is > > unauthorised. If you are not the intended recipient, please delete > > this message and any attachments and advise the sender by return e-mail= , > Thanks. > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From wmills@yahoo-inc.com Wed Jun 13 11:39:10 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FACB21F8522 for ; Wed, 13 Jun 2012 11:39:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.478 X-Spam-Level: X-Spam-Status: No, score=-17.478 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nVBM80NeOm15 for ; Wed, 13 Jun 2012 11:39:09 -0700 (PDT) Received: from nm16.bullet.mail.sp2.yahoo.com (nm16.bullet.mail.sp2.yahoo.com [98.139.91.86]) by ietfa.amsl.com (Postfix) with SMTP id 7BAE821F8510 for ; Wed, 13 Jun 2012 11:39:09 -0700 (PDT) Received: from [98.139.91.67] by nm16.bullet.mail.sp2.yahoo.com with NNFMP; 13 Jun 2012 18:39:06 -0000 Received: from [98.139.91.24] by tm7.bullet.mail.sp2.yahoo.com with NNFMP; 13 Jun 2012 18:39:06 -0000 Received: from [127.0.0.1] by omp1024.mail.sp2.yahoo.com with NNFMP; 13 Jun 2012 18:39:06 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 183459.16960.bm@omp1024.mail.sp2.yahoo.com Received: (qmail 82567 invoked by uid 60001); 13 Jun 2012 18:39:05 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1339612745; bh=wb/7Afz8Uxq/9JC2elrIUXFkrxfBa0LWmVNsD3Lhisk=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=fv4bWx8K6yK7yMdudR3h+sQL8BlGU+y6TabC2UmBBg6X1qYscykcEAsULntN3SuHiwQ/Ja1QE1Y/r68rTOWhCmYosCe0m38Z3hk3tGND3maxdbuxn8dPGjJKeFOw57u0KGp2WdV6mYMGNAS4Emx6tZDPyCrPDl3fXz2AmtuThSI= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=cIjYCVRXmrnKWh+3lUAGhQeVFvAM3il/uz0FJkeVFe0ELdnjj/h8j26HDP21ObVSKnB9ymX+sB01iVdWlDe7nnVGQSbqigzrBFs+d4YPYAMQPji/WPIJP4W5lVAn4IMR4XOx8IdopmRhYW2bFm8HfRQpPi9+5SYQcZiQLz+BWZQ=; X-YMail-OSG: p3W5ow0VM1kPX0aYuux2Wsp.PrZHRctuKGjJvkmBMfGtLnN cvxAgR0zej1QIpVXV7v.ScsG_7osjdo3XNCpPib.hnJy618PSG02YuWbOJRZ cqLlf2W.CTP2U3rUbFDartDEazxGmJIuK8LxWYSUV1u0gXknT3TXfs7EE2K3 yJJy_Fx6Sd3nlSmwpqM0JDRjDDSyjCc7_DkChgGZLOAbpHj2uixlTtkxoBSI jXG4FRg.OlYRTTZbvtLuVyYCWXDNofMTgYep4t6by7ti0vF2CHIdEdjMcy3l nfmzvljmrIQv2Xg2UORNfP3x0suUhR0Ymuw0Df4nhOCDmOJr4i2t8t8t8ndR OTLjGzFAiAH4r_DlSckY9yW1FQcLHahkFYdMXLQMIpYtWGezVTi1i8xBhr03 pqiK70xs7zdZOVd3E6FJGYZgbulR9JeumZ2XTmQrymuH4otslOr0- Received: from [209.131.62.115] by web31808.mail.mud.yahoo.com via HTTP; Wed, 13 Jun 2012 11:39:05 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.120.356233 References: <1339601256.43890.YahooMailNeo@web31803.mail.mud.yahoo.com> <0CBAEB56DDB3A140BA8E8C124C04ECA201070221@P3PWEX2MB008.ex2.secureserver.net> Message-ID: <1339612745.81200.YahooMailNeo@web31808.mail.mud.yahoo.com> Date: Wed, 13 Jun 2012 11:39:05 -0700 (PDT) From: William Mills To: Eran Hammer , O Auth WG , Apps Discuss In-Reply-To: <0CBAEB56DDB3A140BA8E8C124C04ECA201070221@P3PWEX2MB008.ex2.secureserver.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [OAUTH-WG] OAuth discovery registration. X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 18:39:10 -0000 Worthwhile to change the document title?=0A=0AExamples are easy, can do.=0A= =0A=0A=0A----- Original Message -----=0A> From: Eran Hammer =0A> To: William Mills ; O Auth WG ; Apps Discuss =0A> Cc: =0A> Sent: Wednesday, Ju= ne 13, 2012 9:03 AM=0A> Subject: RE: [OAUTH-WG] OAuth discovery registratio= n.=0A> =0A>T hese are straight link relation registrations, not LRDD (which= has no =0A> registration process). It is helpful to put these registration= s in context and =0A> use LRDD/host-meta as an example of their use, but th= e actual registration =0A> request is simply for a link relation and nothin= g else.=0A> =0A> EH=0A> =0A>> -----Original Message-----=0A>> From: oauth= -bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf=0A>> Of Willia= m Mills=0A>> Sent: Wednesday, June 13, 2012 8:28 AM=0A>> To: O Auth WG; A= pps Discuss=0A>> Subject: [OAUTH-WG] OAuth discovery registration.=0A>> = =0A>> =0A>> =0A>> Since for the OAUTH SASL mechanism I need discovery for = clients to work,=0A>> and I had to rip the in-band discovery out of that m= echanism, and I need it=0A>> defined somewhere, I've drafted a small doc f= or the registration of =0A> link=0A>> relation types for OAuth.=A0 It's to= o late in the process to get this =0A> into the core=0A>> OAuth 2 spec, an= d it doesn't really fit in the WebFinger. Submission =0A> info=0A>> provid= ed below.=0A>> =0A>> -bill=0A>> =0A>> -----------------------------------= -----------------=0A>> =0A>> A new version of I-D, draft-wmills-oauth-lrdd= -00.txt has been successfully=0A>> submitted by William Mills and posted t= o the IETF repository.=0A>> =0A>> Filename:=A0=A0=A0 draft-wmills-oauth-lr= dd=0A>> Revision:=A0=A0=A0 00=0A>> Title:=A0=A0=A0 =A0=A0=A0 LRDD Registr= y for OAuth 2=0A>> Creation date:=A0=A0=A0 2012-06-13=0A>> WG ID:=A0=A0= =A0 =A0=A0=A0 Individual Submission=0A>> Number of pages: 10=0A>> URL:=A0= =A0 =A0 =A0 =A0 =0A> =A0=A0http://www.ietf.org/internet-drafts/draft-wmill= s-oauth-lrdd-=0A>> 00.txt=0A>> Status:=A0 =A0 =A0 =A0 =A0=A0http://datatr= acker.ietf.org/doc/draft-wmills-oauth-lrdd=0A>> Htmlized:=A0 =A0 =A0 =A0= =A0http://tools.ietf.org/html/submission.filename=A0}}-00=0A>> =0A>> =0A>> = Abstract:=0A>> =A0 Defines link type registrations for the OAuth 2 authen= tication=0A>> =A0 framework.=0A>> =0A>> =0A>> =0A>> =0A>> The IETF Secret= ariat=0A>> _______________________________________________=0A>> OAuth mai= ling list=0A>> OAuth@ietf.org=0A>> https://www.ietf.org/mailman/listinfo/= oauth=0A> From eve@xmlgrrl.com Wed Jun 13 11:39:11 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 815C621F8522; Wed, 13 Jun 2012 11:39:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.293 X-Spam-Level: X-Spam-Status: No, score=-1.293 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_DOMAIN_NOVOWEL=0.5, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JUm8D3MafEwM; Wed, 13 Jun 2012 11:39:10 -0700 (PDT) Received: from promanage-inc.com (eliasisrael.com [50.47.36.5]) by ietfa.amsl.com (Postfix) with ESMTP id 95C9121F8510; Wed, 13 Jun 2012 11:39:10 -0700 (PDT) Received: from [192.168.168.185] ([192.168.168.185]) (authenticated bits=0) by promanage-inc.com (8.14.4/8.14.4) with ESMTP id q5DId09c011345 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 13 Jun 2012 11:39:01 -0700 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Eve Maler In-Reply-To: <1339611594.26607.YahooMailNeo@web31806.mail.mud.yahoo.com> Date: Wed, 13 Jun 2012 11:38:59 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1339601256.43890.YahooMailNeo@web31803.mail.mud.yahoo.com> <4FD8B646.3080509@stpeter.im> <1339611594.26607.YahooMailNeo@web31806.mail.mud.yahoo.com> To: William Mills X-Mailer: Apple Mail (2.1278) Cc: Apps Discuss , Goix Laurent Walter , O Auth WG Subject: Re: [OAUTH-WG] [apps-discuss] OAuth discovery registration. X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 18:39:11 -0000 Hi Bill-- In incorporating OAuth into several of the UMA flows, we found = a need for the authorization server to provide OAuth-related metadata = along with UMA-specific metadata. Originally it was strictly XRD- and = hostmeta-based, but now uses a JSON format and is more akin to OpenID = Connect's metadata in style:=20 http://docs.kantarainitiative.org/uma/draft-uma-core.html#am-endpoints Do you feel that this new draft is something that ultimately *should* = replace the OAuth-specific parts of the metadata we've spec'd out for = our use case? Note that we went beyond just the two endpoints, also = covering a feature toggle for "dynamic_client_registration_supported" = and lists of "oauth_token_profiles_supported" and = "oauth_grant_types_supported". The purpose in doing this was to provide = a machine-readable mechanism for aiding OAuth-level interop. Thanks, Eve On 13 Jun 2012, at 11:19 AM, William Mills wrote: > On the informational status, that seemed right, but I honestly don't = know what the correct choice is here. The actual registration happens = via e-mail I believe, not via this document. >=20 > Thanks for the feedback! >=20 > -bill >=20 >=20 >=20 > ----- Original Message ----- >> From: Goix Laurent Walter >> To: Peter Saint-Andre ; William Mills = >> Cc: O Auth WG ; Apps Discuss >> Sent: Wednesday, June 13, 2012 9:44 AM >> Subject: R: [apps-discuss] [OAUTH-WG] OAuth discovery registration. >>=20 >> T hank you William for this initiative. >>=20 >> I had similar concerns than Peter on authn vs authz. >>=20 >> Under section 4.1.1 I would suggest to use "oauth2-authorize" instead=20= >> of "oauth2-authenticator", to be consistent with the=20 >> "oauth2-token" pattern and with the concepts of the oauth2 draft. >>=20 >> The header of the pages still reference sasl/gss-api and would need = to be=20 >> updated. >>=20 >> Also, an example and/or use case section could be beneficial, e.g. to = describe=20 >> its usage in an xrd document. Other use cases may be mentioned as = well probably. >>=20 >> I have also noticed that your draft is mentioned as "informational".=20= >> It is indeed your target or only a typo? >>=20 >> Thanks >> walter >>=20 >>> -----Messaggio originale----- >>> Da: apps-discuss-bounces@ietf.org = [mailto:apps-discuss-bounces@ietf.org]=20 >> Per >>> conto di Peter Saint-Andre >>> Inviato: mercoled=EC 13 giugno 2012 17.48 >>> A: William Mills >>> Cc: O Auth WG; Apps Discuss >>> Oggetto: Re: [apps-discuss] [OAUTH-WG] OAuth discovery registration. >>>=20 >>> On 6/13/12 9:27 AM, William Mills wrote: >>>>=20 >>>> Since for the OAUTH SASL mechanism I need discovery for clients to >>>> work, and I had to rip the in-band discovery out of that mechanism, >>>> and I need it defined somewhere, I've drafted a small doc for the >>>> registration of link relation types for OAuth. It's too late in=20 >> the >>>> process to get this into the core OAuth 2 spec, and it doesn't=20 >> really >>>> fit in the WebFinger. Submission info provided below. >>>=20 >>> Hi Bill, overall this looks good. A few nits: >>>=20 >>> OLD >>> This document defines the LRDD [RFC5988] link type registrations = for >>> the OAuth [I-D.ietf-oauth-v2] authentication framework. These = link >>> types are used during the endpoint discovery process using Web = Host >>> Metadata [I-D.hammer-hostmeta] and Webfinger >>> [I-D.jones-appsawg-webfinger] by clients needing to discover the >>> authentication endpoints for a service or site. It additionally >>> defines link type registrations for OAuth 1.0a [RFC5849]. >>>=20 >>> NEW >>> This document defines the Link-based Resource Descriptor >>> Documents (LRDD) [RFC6415] link type registrations for the >>> OAuth [I-D.ietf-oauth-v2] authorization framework. These link >>> types are used during the endpoint discovery process using Web >>> Host Metadata [RFC6415] and Webfinger >>> [I-D.jones-appsawg-webfinger] by clients needing to discover the >>> authorization, token, and access token endpoints for an OAuth2 >>> service or site. It additionally defines link type = registrations for >>> OAuth >>> 1.0a [RFC5849] request initiation endpoints, authorization = endpoints, >>> and token endpoints. >>>=20 >>> In Section 4.1.1, you register an "OAuth 2 Authentication=20 >> Endpoint", >>> however draft-ietf-oauth-v2 defines only an authorization endpoint, = a >>> token endpoint, and an access token endpoint. Whence this >>> "authentication endpoint"? Is it just a typo? >>>=20 >>> Also, is the lack of a link type for OAuth2 access token endpoints = an >>> oversight? It seems so. >>>=20 >>> You have "Reference: [[this document]]" but I think you want: >>>=20 >>> Reference: draft-ietf-oauth-v2 >>>=20 >>> and >>>=20 >>> Reference: RFC 5849 >>>=20 >>> You can remove the reference for draft-hammer-hostmeta (RFC 6415 has >>> what you need). >>>=20 >>> Peter >>>=20 >>> -- >>> Peter Saint-Andre >>> https://stpeter.im/ >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> apps-discuss mailing list >>> apps-discuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/apps-discuss >>=20 >> Questo messaggio e i suoi allegati sono indirizzati esclusivamente = alle persone=20 >> indicate. La diffusione, copia o qualsiasi altra azione derivante = dalla=20 >> conoscenza di queste informazioni sono rigorosamente vietate. Qualora = abbiate=20 >> ricevuto questo documento per errore siete cortesemente pregati di = darne=20 >> immediata comunicazione al mittente e di provvedere alla sua = distruzione,=20 >> Grazie. >>=20 >> This e-mail and any attachments is confidential and may contain = privileged=20 >> information intended for the addressee(s) only. Dissemination, = copying, printing=20 >> or use by anybody else is unauthorised. If you are not the intended = recipient,=20 >> please delete this message and any attachments and advise the sender = by return=20 >> e-mail, Thanks. >>=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl From ve7jtb@ve7jtb.com Wed Jun 13 11:40:30 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED02D11E8088 for ; Wed, 13 Jun 2012 11:40:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gK8frrwa-pNe for ; Wed, 13 Jun 2012 11:40:28 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id E4A7E11E8083 for ; Wed, 13 Jun 2012 11:40:27 -0700 (PDT) Received: by ggnc4 with SMTP id c4so815218ggn.31 for ; Wed, 13 Jun 2012 11:40:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to :x-gm-message-state; bh=vhIFq8FCaoECgxr4rHySaAJJB83IsGTMdXxb9wSlnJ4=; b=c9XJY57hRFQew1+HzSigkgPANI3511Bm0GZS0ayY0rDBWHcF9DFctLmfwIyyRm06gU 3aebQWtKe/BL9a2P894WdtVtuzErviUhCOOmPduMeWTXHB9kt2WAt2wog2ygo6yu2X1k 7RdPsLcyeSQyjUwsPOQ/dipCpG9DxMIQ3HJg+AKFCNQWEf+3/udo5FTH6wu/3lBIBfTr HwZEQ5dqrLjdFJ9Ss3Qc/aw1i9ZqlYoYtDA5C73BQFSOmBnG7jB5zZEJn8AeynbtzlCN ZhXEh+OXnW1/2YGA/zbS4te8wrrlyp6FHQhJ+ExEmEhtztUYm2XwB9WxgBmtWSk5Zvmu DEGg== Received: by 10.60.19.196 with SMTP id h4mr25525726oee.56.1339612827237; Wed, 13 Jun 2012 11:40:27 -0700 (PDT) Received: from [192.168.43.229] (mobile-166-147-064-184.mycingular.net. [166.147.64.184]) by mx.google.com with ESMTPS id a6sm2042240oeg.7.2012.06.13.11.40.15 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 13 Jun 2012 11:40:25 -0700 (PDT) References: <9dbeab60-8fe4-4828-9c52-d7af95378f4c@email.android.com> <0ec59f35-4a66-4719-adf3-114dab0d1d48@email.android.com> In-Reply-To: <0ec59f35-4a66-4719-adf3-114dab0d1d48@email.android.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-F275A567-1AA9-4A45-A44E-081D2C173A6C; protocol="application/pkcs7-signature" Message-Id: <40240328-0247-4278-BB7B-BE89AE130076@ve7jtb.com> X-Mailer: iPhone Mail (9B206) From: John Bradley Date: Wed, 13 Jun 2012 20:40:08 +0200 To: Torsten Lodderstedt X-Gm-Message-State: ALoCoQkOYr9PEzDdYBOVrQur3cGs8GcQc0ii/O8dIKQt0DFqr3QJUOmx2LJM2kd0nOZ3vgmM7iqo Cc: Julian Reschke , Richard Mortier , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion needed on username and password ABNF definitions X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 18:40:30 -0000 --Apple-Mail-F275A567-1AA9-4A45-A44E-081D2C173A6C Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-37858920-0382-4908-ADCD-97561D694E05 --Apple-Mail-37858920-0382-4908-ADCD-97561D694E05 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 That would probably work as well. That is why I am not particularly concern= ed about excluding the :=20 We originally used the URI itself, mostly for convenience of debugging, bu= t there are other potential options.=20 The authorization server needs to compare the client_id and the redirect uri= . But it could compare the hash with not much more work. Also a sha256 has= h is probably longer than the uri it is hashing. =20 I am not super concerned with being able to have : in the client_id John B.=20 Sent from my iPhone On 2012-06-13, at 6:03 PM, Torsten Lodderstedt wro= te: > Hi John, >=20 > would it make sense to use a hash of the URI instead of the URI itself in y= our use case? >=20 > regards, > Torsten. >=20 >=20 >=20 > John Bradley schrieb: > I think that the issues are getting confused. >=20 > There is a use case where the Authorization server may be a embedded app, a= t least in one openID case. As it won't have a separate registration or t= oken endpoint, the client needs to make its own clientID for the request. = A reasonable thing to use is the redirect URI to create a unique value that= the user could use for revocation at a later point. >=20 > Currently with the no : restriction we would use the host and path to crat= e the clientid. > There are some scenarios where having the scheme as part of that would be h= elpful. >=20 > This has nothing to do with discovery or the dynamic client registration p= roposal as far as I know. >=20 > A URL as a client_id comes from prototype work for a personal provider tha= t we are doing as part of openID Connect. >=20 > John B. > On 2012-06-13, at 7:50 AM, Torsten Lodderstedt wrote: >=20 >> Hi all, >>=20 >> can anyone please explain the relation between dynamic client registratio= n and URIs as client ids? None of the current drafts (uma or connect) seem t= o require URIs. >>=20 >> regards, >> Torsten. >>=20 >>=20 >>=20 >> Jianhua Shao schrieb: >> Hello, >>=20 >> Dynamic client registration is very useful if client or resource or autho= risation server is not permanently available.=20 >> A typical case is that is the resource or authorisation server is in mobi= le platform, the connection is not always available.=20 >> Another typical case is that authorisation server do not necessary to hav= e client pre-registered on itself. At moment, industry like facebook would l= ike developer to register a app on its app centre first, and then ask user a= uth to use the app.=20 >>=20 >> We are researchers from Digital Economy Research Institute. We have this p= roblem When we developing Dataware that could manage the control of access t= o personal data. We play around our solution base on Oauth2: https://github.= com/jianhuashao/dataware.catalog/wiki >>=20 >> We are in the list to receive your mail list, but currently need moderate= to post any message. cc my colleague, Richard Mortier >> Best >> Jian >>=20 >>=20 >> On 12 Jun 2012, at 21:08, Eran Hammer wrote: >>=20 >>> The only distinction I would make is between removing flexibiliy to proa= ctively enabling future extensibility. I would stop short of perscribing enc= oding in order to fit uri into the Basic auth fields. But if there is a way t= o allow this to be less restrictive without clean interop issues, that would= be nice. >>> =20 >>> I do agree we need some actual use cases before we spend much more time o= n this. >>> =20 >>> EH >>> =20 >>> From: William Mills [mailto:wmills@yahoo-inc.com]=20 >>> Sent: Tuesday, June 12, 2012 1:04 PM >>> To: Eran Hammer; Mike Jones; Hannes Tschofenig; Julian Reschke >>> Cc: oauth@ietf.org >>> Subject: Dynamic clients, URI, and stuff Re: [OAUTH-WG] Discussion neede= d on username and password ABNF definitions >>> =20 >>> I think dynamic client registration is something we have not talked out e= nough yet. There's a pretty clear use case for dynamic registration. =20 >>> =20 >>> Does identifying the client with a URI allow some form of OpenID-ish flo= w for this?=20 >>> Is the client ID as a URI a way to allow a trusted site to provide metad= ata about the client? >>> Is that URI a way to hit an IDP we trust to validate the client in some w= ay with the provided secret? >>> =20 >>> I guess what I'm looking for here is a concrete use case/problem to solv= e, rather then leaving a hook we think is the right thing. >>> =20 >>> -bill >>> =20 >>> =20 >>> From: Eran Hammer >>> To: Mike Jones ; William Mills ; Hannes Tschofenig ; Julian Reschke =20 >>> Cc: "oauth@ietf.org" =20 >>> Sent: Tuesday, June 12, 2012 11:39 AM >>> Subject: RE: [OAUTH-WG] Discussion needed on username and password ABNF d= efinitions >>> =20 >>> Is the use case of using URI as client ids important? It seems like some= thing that might become useful in the future where clients can use their ver= ifiable servers to bypass client registration and simly use a URI the server= can validate via some other means. >>> =20 >>> I just want to make sure those thinking about more complex use cases inv= olving dynamic registration or distri buted client manamgenet are aware of t= his potential restriction. >>> =20 >>> I'm fine either way. >>> =20 >>> EH >>> =20 >>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf O= f Mike Jones >>> Sent: Tuesday, June 12, 2012 11:27 AM >>> To: William Mills; Hannes Tschofenig; Julian Reschke >>> Cc: oauth@ietf.org >>> Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF d= efinitions >>> =20 >>> Not internationalizing fields intended for machine consumption only is a= lready a precedent set and agreed to by the working group, so let me second B= ill=E2=80=99s point in that regard. For instance, neither =E2=80=9Cscope=E2= =80=9D nor =E2=80=9Cerror=E2=80=9D allow non-ASCII characters. >>> =20 >>> Julian, if you want different ABNF text than the text I wrote below, I b= elieve it would be most useful if you would provide the exact replace wordin= g that you=E2=80=99d like to see instead of it. Then there=E2=80=99s no pos= sibility of misunderstanding the intent of suggested changes. >>> =20 >>> Thanks all, >>> -- Mike >>> =20 >>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf O= f William Mills >>> Sent: Tuesday, June 12, 2012 11:18 AM >>> To: Hannes Tschofenig; Julian Reschke >>> Cc: oauth@ietf.org >>> Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF d= efinitions >>> =20 >>> I agree generally with your assumption about clients, but rather than sa= ying "clients are devices" I think it makes much more sense to say "clients a= re NOT users, so client_id need not be internationalized". In practical ter= ms there is very little to argue for anythign beyond ASCII in a client_secre= t, base64 encoding or the equivalent being a fine way to transport arbitrary= bits in a portable/reasonable way. >>> =20 >>> I argue that client_id need not be internationalized because I assume th= at any really internationalized application will have an internationalized p= resentation layer that's presenting a pretty name for the client_id. >>> =20 >>> -bill >>> =20 >>> From: Hannes Tschofenig >>> To: Julian Reschke =20 >>> Cc: "oauth@ietf.org" =20 >>> Sent: Tuesday, June 12, 2012 11:01 AM >>> Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF d= efinitions >>>=20 >>> I had a chat with Julian yesterday and here is my short summary.=20 >>>=20 >>> Section 2.3 of the core draft defines client authentication based on two= mechanisms (and provides room for extensions):http://tools.ietf.org/html/dr= aft-ietf-oauth-v2-27#section-2.3 >>>=20 >>> 1) HTTP Basic Authentication >>>=20 >>> 2) A custom OAuth authentication mechanism (which uses client_id and cli= ent_secret) >>>=20 >>> With HTTP Basic authentication the problem is that this is a legacy tech= nology and there is no internationalization support.=20 >>>=20 >>> With our brand new custom OAuth authentication mechanism we have more op= tions.=20 >>>=20 >>> One possible approach is to say that the clients are devices (and not en= d users) and therefore internationalization does not matter.=20 >>>=20 >>> Is it, however, really true that only US-ASCII characters will appear in= the client_id and also in the client_secret?=20 >>>=20 >>> Here we have the possibility to define something better.=20 >>>=20 >>> In any case we have to restrict the characters that are used in these tw= o authentication mechanisms since they could conflict with the way how we tr= ansport the data over the underlying protocol. Julian mentioned this in his p= revious mails.=20 >>>=20 >>> Julian, maybe you can provide a detailed text proposal for how to addres= s your comment in case we go for UTF8 (with % encoding) for the custom OAuth= client authentication mechanism?=20 >>>=20 >>> Ciao >>> Hannes >>>=20 >>> On Jun 12, 2012, at 11:54 AM, Julian Reschke wrote: >>>=20 >>> > On 2012-06-12 00:16, Mike Jones wrote: >>> >> Reviewing the feedback from Julian, John, and James, I'm coming to th= e conclusion that client_id and client_secret, being for machines and not hu= mans, shou ld be ASCII, whereas username and password should be Unicode, sin= ce they are for humans. Per John's feedback, client_id can not contain a co= lon and be compatible with HTTP Basic. >>> >=20 >>> > I'm not sure that restricting the character repertoire just because on= e way to send requires this is the right approach. My preference would be no= t to put this into the ABNF, and just to point out that certain characters w= ill not work over certain transports, and to just advise to avoid them. >>> >=20 >>> >> Therefore, I'd like to propose these updated ABNF definitions: >>> >>=20 >>> >> VSCHAR =3D %20-7E >>> >> NOCOLONVSCHAR =3D %x20-39 / %x3B-7E >>> >> UNICODENOCTRLCHAR =3D >>> >>=20 >>> >> client-id =3D *NOCOLONVSCHAR >>> >> client_secret =3D *VSCHAR >>> >>=20 >>> >> username =3D *UNICODENOCTRLCHAR >>> >> password =3D *UNICODENOCTRLCHAR >>> >=20 >>> > In this case you should add an introductory statement pointing out tha= t the ABNF defines the grammar in terms of Unicode code points, not octets (= as it is the case most of the time). >>> >=20 >>> >> It turns out that non-ASCII characters are OK for username and passwo= rd because the Core spec only passes them in the form body - not using HTTP B= asic - and UTF-8 encoding is specified. >>> >=20 >>> > I'll send a separate mail about that, the current text in the spec is w= ay too unspecific. >>> >=20 >>> >> -- Mike >>> >>=20 >>> >> P.S. If anyone has a better ABNF for UNICODENOCTRLCHAR than "", please send it to me! >>> >=20 >>> > As noted before, here's an example: >>> >=20 >>> > Best regards, Julian >>> > _______________________________________________ >>> > OAuth mailing list >>> > OAuth@ietf.org >>> > https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> =20 >>>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >> This message and any attachment are intended solely for the addressee and= may contain confidential information. If you have received this message in e= rror, please send it back to me, and immediately delete it. Please do not us= e, copy or disclose the information contained in this message or in any atta= chment. Any views or opinions expressed by the author of this email do not n= ecessarily reflect the views of the University of Nottingham. >>=20 >> This message has been checked for viruses but the contents of an attachme= nt may still contain software viruses which could damage your computer syste= m: you are advised to perform your own checks. Email communications with the= University of Nottingham may be monitored as permitted by UK legislation. >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 --Apple-Mail-37858920-0382-4908-ADCD-97561D694E05 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
That would probably work a= s well.  That is why I am not particularly concerned about excluding th= e : 

We originally used the URI itself,  = mostly for convenience of debugging,  but there are other potential opt= ions. 

The authorization server needs to compa= re the client_id and the redirect uri. But it could compare the hash with no= t much more work.   Also a sha256 hash is probably longer than the uri i= t is hashing.  

I am not super concerned with b= eing able to have : in the client_id

John B. <= br>
Sent from my iPhone

On 2012-06-13, at 6:03 PM, Torsten L= odderstedt <torsten@loddersted= t.net> wrote:


= --_000_B36B7798CBF34557A967DD41197C1882exmailnottinghamacuk_-- From doug.foiles@gmail.com Thu Jun 14 09:50:21 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A14C21F8707 for ; Thu, 14 Jun 2012 09:50:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.412 X-Spam-Level: X-Spam-Status: No, score=-3.412 tagged_above=-999 required=5 tests=[AWL=0.186, 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 GdHOzAFIIwGD for ; Thu, 14 Jun 2012 09:50:19 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4EFA321F8704 for ; Thu, 14 Jun 2012 09:50:19 -0700 (PDT) Received: by yhq56 with SMTP id 56so1866865yhq.31 for ; Thu, 14 Jun 2012 09:50:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NfnKRo74zGpcaxzKYdB/OpQrp0qwtDcymzlTIVR7s6o=; b=zIDSkhhO+w6bjb/vM6rFVrlZFkmbbTme3IWkYJ7o186aWrCEuwfm6dkyapw2jtRihw Z9yRPslmFG59o9PJ2EUeeeBoJLwXax1jZ87Y4TSc8m6A/FPtC2ZC9nIwIYTCohDB+TWo WyYcaoybeHqlMeTJPfyXVG6F6XGyU6uwADD5Wtl9OgjXz0djReU0jELA1umyccXS7/pO cwgS+3o57NKIya+lcY8AlId2fo0oMDpYCPexsZSwXlqwSD5mSu80pHcOgOa56AzK8AI/ n3Y0/WWeH6LaX1fD+CsJswFaDnaYqkcBhA/fqFUzn45R162RUNKAC+PDOuH+cbvF8+t9 7b2A== MIME-Version: 1.0 Received: by 10.50.163.99 with SMTP id yh3mr1328758igb.53.1339692618433; Thu, 14 Jun 2012 09:50:18 -0700 (PDT) Received: by 10.231.199.135 with HTTP; Thu, 14 Jun 2012 09:50:18 -0700 (PDT) In-Reply-To: <4FD860D9.7010007@gmail.com> References: <4FD65080.9040305@gmail.com> <4FD65ED8.6000507@aol.com> <4FD745EE.1040508@mitre.org> <4FD860D9.7010007@gmail.com> Date: Thu, 14 Jun 2012 09:50:18 -0700 Message-ID: From: doug foiles To: Paul Madsen , Torsten Lodderstedt Content-Type: multipart/alternative; boundary=e89a8f83ac51a1439e04c2717ec7 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Clarification in Section 2.0 of draft-ietf-oauth-revocation-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 16:50:21 -0000 --e89a8f83ac51a1439e04c2717ec7 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable That works for me Torsten, thanks. The =93SHOULD=94s make it interesting for the clients. It seems that the client developer will need to know how the individual AS=92s are handling i= t. I pasted a couple of examples below where the terms =93SHOULD=94 and =93SHO= ULD NOT=94 are used. Both of these indicate to me that the client developer wi= ll need to know the specific implementation in order to process the request correctly. o Native applications that use the authorization code grant type SHOULD do so without using client credentials, due to the native application's inability to keep client credentials confidential. If the access token request is valid and authorized, the authorization server issues an access token as described in Section 5.1 . A refresh token SHOULD NOT be included. If the request failed client authentication or is invalid, the authorization server returns an error response as described in Section 5.2 . Doug On Wed, Jun 13, 2012 at 2:43 AM, Paul Madsen wrote: > ** > agree that it'd be preferable to refer to the higher level grant > > related, the spec stipulates > > 'The client MUST NOT make any assumptions about the timing and MUST NOT > use the token again.' > > So what does the client do with it's existing access token when it revoke= s > the associated refresh token? > > The rule indicating to the AS that access tokens be revoked as well is > only a SHOULD, so the client can't be certain that the access token is 'b= ad' > > paul > > > On 6/13/12 2:01 AM, Torsten Lodderstedt wrote: > > Hi all, > > we should probably adopt the wording to refer to the access grant > underlying all tokens? Something like: "based on the same access grant ..= .". > > What do you think? > > regards, > Torsten. > > > > doug foiles schrieb: >> >> Thanks Justin. Perhaps we can get Torsten, Stefanie, or Marius to >> comment on what was intended for this ... and would be much appreciated. >> >> On Tue, Jun 12, 2012 at 6:36 AM, Justin Richer wrote= : >> >>> I agree with Doug and George's reading: nuking the refresh token gets >>> rid of all access tokens associated with that refresh token's lifetime. >>> This includes both simultaneous issuance as well as derived issuance. >>> >>> -- Justin >>> >>> >>> On 06/11/2012 08:13 PM, doug foiles wrote: >>> >>> Hi Paul and George, >>> >>> Even though the Access Token is short lived, I would still like to >>> revoke it immediately if the user chooses to revoke the Refresh Token. = And >>> I would love for the client application to only have to make one web >>> service call to accomplish that and not one for the Refresh Token and >>> another for the Access Token. >>> >>> Given that we always generate a new Refresh Token value during "Token >>> Refresh", we would never have a true parent / child relationship betwee= n a >>> Refresh Token and Access Token. >>> >>> Is there a case where it is NOT appropriate to revoke an "associated" >>> Access Token when explictly revoking a Refresh Token? I define >>> "associated" as an Access Token generated from a Refresh Token OR gener= ated >>> at the same time of the Refresh Token. >>> >>> I do see the AS challenges in trying to manage multiple >>> simultaneous "associated" Access Tokens. For example let's say a clien= t >>> generates multiple Access Tokens at the same time while generating new >>> Refresh Token values during each "Token Refresh" operation. However I >>> don't really see the useful of this case. >>> >>> Doug >>> >>> On Mon, Jun 11, 2012 at 3:52 PM, Paul Madsen wro= te: >>> >>>> Hi George, perhaps it depends on the reason for the refresh token >>>> being revoked. If because the user removed their consent then yes I ag= ree >>>> that *all* tokens should be revoked >>>> >>>> Sent from my iPhone >>>> >>>> On 2012-06-11, at 5:10 PM, George Fletcher wrote: >>>> >>>> Paul, >>>> >>>> I think I came to a different conclusion... >>>> >>>> If I use the Resource Owner Password Credential flow and get back both >>>> an access_token and a refresh_token then I would assume that the issue= d >>>> access_token is tied in some way to the refresh_token. If the refresh_= token >>>> is revoked, then my expectation is that the simultaneous issued >>>> access_token would also be revoked. >>>> >>>> I read the spec as having a typo that should read... >>>> >>>> If the processed token is a refresh token and the authorization >>>> server supports the revocation of access tokens, then the >>>> authorization server SHOULD also invalidate all access tokens issued >>>> *based on* that refresh token. >>>> >>>> Or maybe better... "invalidate all access tokens associated/tied-to >>>> that refresh token". >>>> >>>> Now in the case that the client is retrieving a new refresh_token and >>>> access_token, then the new ones should be valid and the old ones >>>> potentially revoked. >>>> >>>> Thanks, >>>> George >>>> >>>> On 6/11/12 4:09 PM, Paul Madsen wrote: >>>> >>>> Hi Doug, my interpretation is that 'for that refresh token' means thos= e >>>> access tokens issued in exchange for that refresh token. >>>> >>>> Consequently, for the cases you cite below, the access tokens at the >>>> same time as a given refresh token need not be invalidated when that >>>> refresh token is 'processed' >>>> >>>> I assume the justification for the rule is that an access token issued >>>> in exchange for a given refresh token may have been compromised if the >>>> refresh token had been. But there is no such causal relationship betwe= en an >>>> access token & refresh token issued at same time >>>> >>>> paul >>>> >>>> On 6/11/12 3:31 PM, doug foiles wrote: >>>> >>>> Hi all, >>>> >>>> I was hoping to get some clarity on a statement in section 2.0 of >>>> draft-ietf-oauth-revocation-00. >>>> >>>> If the processed token is a refresh token and the authorization >>>> server supports the revocation of access tokens, then the >>>> authorization server SHOULD also invalidate all access tokens issued >>>> for that refresh token. >>>> >>>> My question is on the statement "access tokens issued for that refresh >>>> token". What does it mean to have an Access Token "issued" for a Refre= sh >>>> Token? >>>> >>>> This specific case is clear to me. I am refreshing an Access Token >>>> where I keep the same Refresh Token that I used to generate the new Ac= cess >>>> Token. I see the new Access Token was issued for that Refresh Token. >>>> However these two cases are a bit muddy to me. Let=92s say I am using = the >>>> "Resource Owner Password Credentials Grant" where the Access Token Res= ponse >>>> returns both an Access Token and Refresh Token. Would the Access Token= have >>>> been issued for that Refresh Token? And let=92s say I am refreshing an= Access >>>> Token but choose to create a new Refresh Token and immediately revoke = the >>>> original Refresh Token. Would the newly created Access Token have been >>>> issued for the original Refresh Token or the new one that was created. >>>> If a client would revoke a Refresh Token =85 I would like the Access >>>> Tokens in all of the above cases to be automatically revoked as well. = I >>>> just want to make sure I understand the model. Thanks. >>>> Doug Foiles >>>> Intuit >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/= oauth >>>> >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/= oauth >>>> >>>> >>>> >>> >>> >>> _______________________________________________ >>> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/o= auth >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >> > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau= th > > --e89a8f83ac51a1439e04c2717ec7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Th= at works for me Torsten, thanks.=C2=A0

= =C2=A0

Th= e =E2=80=9CSHOULD=E2=80=9Ds make it interesting for the clients.=C2=A0 It seems that the client developer will need to know how the= individual AS=E2=80=99s are handling it.=C2=A0 I pasted= a couple of examples below where the terms =E2=80=9CSHOULD=E2=80=9D and = =E2=80=9CSHOULD NOT=E2=80=9D are used.=C2=A0 Both of the= se indicate to me that the client developer will need to know the specific = implementation in order to process the request correctly.

= =C2=A0

= =C2=A0

=C2=A0=C2=A0 o=C2=A0 Native applications = that use the authorization code grant type

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 SHOULD do so without using cl= ient credentials, due to the native

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 application's inability t= o keep client credentials confidential.

= =C2=A0

=C2=A0=C2=A0 If the access token request is valid and author= ized, the

=C2=A0=C2=A0 authorization server issues an access token as = described in

=C2=A0=C2=A0 Section 5.1.=C2=A0 A refresh token SHOULD NOT be included.=C2=A0 If the request

=C2=A0=C2=A0 failed client authentication or is invalid, the= authorization server

=C2=A0=C2=A0 returns an error response as described in Section 5.2.

=C2= =A0

Doug

On Wed, Jun 13, 2012 at 2:43 AM, Paul Madsen <paul.madsen@gmail.com> wrote:
agree that i= t'd be preferable to refer to the higher level grant

related, th= e spec stipulates

'The client MUST NOT make any assumptio= ns about the timing and MUST NOT use the token again.'

So what does the client do with it's existing access token when it = revokes the associated refresh token?

The rule indicating to the AS = that access tokens be revoked as well is only a SHOULD, so the client can&#= 39;t be certain that the access token is 'bad'

paul=20


On 6/13/12 2:01 AM, Torsten Lodderstedt wrote:=20
Hi all,

we should probably adopt the wordi= ng to refer to the access grant underlying all tokens? Something like: &quo= t;based on the same access grant ...".

What do you think?

regards,
Torsten.



doug foiles <doug.foiles@gmail.com> schrieb:= =20
Thanks Justin.=C2=A0 Perh= aps we can get Torsten, Stefanie, o= r Marius to comment on what was intended for this ... and would be much app= reciated.

On Tue, Jun 12, 2012 at 6:36 AM, Justin Richer <= span dir=3D"ltr"><jricher@mitre.org> wrote:
I agree with Doug and George'= s reading: nuking the refresh token gets rid of all access tokens associate= d with that refresh token's lifetime. This includes both simultaneous i= ssuance as well as derived issuance.

=C2=A0-- Justin=20


On 06/11/2012 08:13 PM, doug foiles wrote:=20
Hi Paul and George,
=C2=A0
Even though the Access Token is short lived, I would still like to rev= oke it immediately if the user chooses to revoke the Refresh Token.=C2=A0 A= nd I would love for the client application to only have to make one web ser= vice call to accomplish that and not one for the Refresh Token and another = for the Access Token.
=C2=A0
Given that we always generate a new Refresh Token value during "T= oken Refresh", we would never have a true parent / child relationship = between a Refresh Token and Access Token.
=C2=A0
Is there a case where it is NOT appropriate to revoke an "associa= ted" Access Token=C2=A0when explictly revoking a Refresh Token?=C2=A0 = I define "associated" as an Access Token generated from a Refresh= Token OR generated at the same time of the Refresh Token.
=C2=A0
I do see the AS challenges in trying to manage multiple simultaneous= =C2=A0"associated" Access Tokens.=C2=A0 For example let's say= a client generates multiple Access Tokens at the same time while generatin= g new Refresh Token values during each "Token Refresh" operation.= =C2=A0 However I don't really see the useful of this case.
=C2=A0
Doug

On Mon, Jun 11, 2012 at 3:52 PM, Paul Madsen <paul.madsen@gmail.com> wrote:
Hi George, perhaps it depends on the reason for the refresh token bein= g revoked. If because the user removed their consent then yes I agree that = *all* tokens should be revoked

Sent from my iPhone

On 2012-06-11, at 5:10 PM, George Fletcher <gffletch@aol.com> wrote:

<= /div>
Paul,

I think I came to a different conclusion...

If I = use the Resource Owner Password Credential flow and get back both an access= _token and a refresh_token then I would assume that the issued access_token= is tied in some way to the refresh_token. If the refresh_token is revoked,= then my expectation is that the simultaneous issued access_token would als= o be revoked.

I read the spec as having a typo that should read...
If the pro=
cessed token is a refresh token and the authorization
server supports the revocation of access tokens, then the
authorization server SHOULD also invalidate all access tokens issued
*based on* that refresh token.
Or maybe better... "invalidate all= access tokens associated/tied-to that refresh token".

Now in t= he case that the client is retrieving a new refresh_token and access_token,= then the new ones should be valid and the old ones potentially revoked.
Thanks,
George

On 6/11/12 4:09 PM, Paul Madsen wrote:=20
Hi Doug, my interpretation i= s that 'for that refresh token' means those access tokens issued in= exchange for that refresh token.

Consequently, for the cases you c= ite below, the access tokens at the same time as a given refresh token need= not be invalidated when that refresh token is 'processed'

I assume the justification for the rule is that an access token issued = in exchange for a given refresh token may have been compromised if the refr= esh token had been. But there is no such causal relationship between an acc= ess token & refresh token issued at same time

paul

On 6/11/12 3:31 PM, doug foiles wrote:=20
Hi all,

I was hoping to get some clarity on a statement in section 2.0 of = draft-ietf-oauth-revocation-00.

=E3=80=80=E3=80=80 If the processed token is a refresh token and t= he authorization
=E3=80=80=E3=80=80 server supports the revocation of ac= cess tokens, then the
=E3=80=80=E3=80=80 authorization server SHOULD als= o invalidate all access tokens issued
=E3=80=80=E3=80=80 for that refres= h token.

My question is on the statement "access tokens issued for tha= t refresh token".=E3=80=80 What does it mean to have an Access Token &= quot;issued" for a Refresh Token?=E3=80=80

This specific case is clear to me.=E3=80=80 I am refreshing an Acc= ess Token where I keep the same Refresh Token that I used to generate the n= ew Access Token.=E3=80=80 I see the new Access Token was issued for that Re= fresh Token.
However these two cases are a bit muddy to me.=E3=80=80 Let=E2=80=99s = say I am using the "Resource Owner Password Credentials Grant" wh= ere the Access Token Response returns both an Access Token and Refresh Toke= n.=E3=80=80 Would the Access Token have been issued for that Refresh Token?= =E3=80=80 And let=E2=80=99s say I am refreshing an Access Token but choose = to create a new Refresh Token and immediately revoke the original Refresh T= oken.=E3=80=80 Would the newly created Access Token have been issued for th= e original Refresh Token or the new one that was created.
If a client would revoke a Refresh Token =E2=80=A6 I would like the Ac= cess Tokens in all of the above cases to be automatically revoked as well.= =E3=80=80 I just want to make sure I understand the model.=E3=80=80 Thanks.=
Doug Foiles
Intuit

_______________________________________________
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


______________________________= _________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listi= nfo/oauth



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

--e89a8f83ac51a1439e04c2717ec7-- From ruiwangwarm@gmail.com Thu Jun 14 10:18:19 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A730E21F8675 for ; Thu, 14 Jun 2012 10:18:18 -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 o-x-f8BVELhD for ; Thu, 14 Jun 2012 10:18:17 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7AEC821F8669 for ; Thu, 14 Jun 2012 10:18:17 -0700 (PDT) Received: by ggnc4 with SMTP id c4so1772202ggn.31 for ; Thu, 14 Jun 2012 10:18:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=YB6XJ0lMzBG0BgYglXm9t/K7BS8APXY08OHmojXRVR8=; b=V832Ih/RjmlZVof5F0zfOLKbISpYBHnLnSPLmnvHxM/BL2TQGbQ2WbCel0nlysEiaB XRhrX/qaX76gNNdt4XcbY1D3zKYnR48NcF+Rz+tX8/10KvnIMejgwQE3AHhZfegMuGW/ Shoq/dCDpwuI2y4wy9UCxSR8wOYUWDCZIRsdnYPTPABYillr239sMowH93H42a+nC7fY NAwnjifIEEYeIBXGeQw3fb4Eo+NseOD57xymGoaIjUT0xxBtPkktlxQeRv1+rHQdGT1L rlpsAgoK20fZMeUTOHbG8g3/4E62RkstKGTQ+ZZDcf44W+IIGKuRujCgVWrZGx1tkhya vqgQ== MIME-Version: 1.0 Received: by 10.50.160.234 with SMTP id xn10mr13116536igb.61.1339694296856; Thu, 14 Jun 2012 10:18:16 -0700 (PDT) Received: by 10.43.46.200 with HTTP; Thu, 14 Jun 2012 10:18:16 -0700 (PDT) Date: Thu, 14 Jun 2012 10:18:16 -0700 Message-ID: From: rui wang To: oauth Content-Type: multipart/alternative; boundary=14dae9340303abf8c004c271e24d Cc: Yuchen Zhou , "Shuo Chen \(MSR\)" Subject: [OAUTH-WG] Report an authentication issue X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 17:19:17 -0000 --14dae9340303abf8c004c271e24d Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Dear Facebook Security Team and OAuth Standard group, We are a research team in Microsoft Research. In January, 2011, we reported a vulnerability in Facebook Connect which allowed everyone to sign into Facebook-secured relying parties without password. It was promptly fixed after reporting. ( http://nakedsecurity.sophos.com/2011/02/02/facebook-flaw-websites-steal-per= sonal-data/ ) Recently, we found a common misunderstanding among developers of mobile/metro apps when using OAuth (including Facebook=92s OAuth) for authentication. The vulnerability resulted from this misunderstanding also allows an attacker to log into a victim user's account without password. Let's take Soluto's metro app as an example to describe the problem. The app supports Facebook Login. As an attacker, we can write a regular Facebook app. Once the victim user allows our app to access her Facebook data, we receive an access_token from the traffic. Then, on our own machine (i.e., the "attacker" machine), we run the metro app of Soluto, and use a HTTP proxy to insert the victim's access_token into the traffic of Facebook login. Through this way, we are able to log into the victim's Soluto account from our machine. Other than Soluto, we also have confirmed the same issue on another Windows 8 metro-app Givit. The Facebook SDK for Android apps ( https://developers.facebook.com/docs/mobile/android/build/#sdk) seems to have the possibility to mislead developers too. At least, the issue that we found is not clearly mentioned. In the SDK, we ran the sample code called "Hackbook" using Android Emulator (imagine it is an attacker device). Note that we have already received the access token of the victim user from our regular Facebook app. We then inject the token to the traffic of Hackbook. Through this way, Hackbook app on our own machine recognizes us as the victim. Note that this is not a convincing security exploit yet, because this sample code does not include the server-side code. However, given that we have seen real server-side code having this problem, such as Soluto, Givit and others, we do believe that the sample code can mislead mobile/metro developers. We also suspect that this may be a general issue of many OAuth implementations on mobile platforms, so we send this message to OAuth Standard group as well. We have contacted the vendors of the two vulnerable metro-apps, Soluto and Gavit. Please kindly give us an ack when you receive this message. If you want to know more details, please let us know. Best Regards, Yuchen Zhou, Rui Wang, and Shuo Chen --14dae9340303abf8c004c271e24d Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Dear Facebook Security Team and OAuth Standard group,

We are a research team in Microsoft Research. In January, 2011, we repor= ted a vulnerability in Facebook Connect which allowed everyone to sign into= Facebook-secured relying parties without password. It was promptly fixed a= fter reporting. (http://nakedsecurity.sophos.com/20= 11/02/02/facebook-flaw-websites-steal-personal-data/)

Recently, we found a common misunderstanding among developers of mobile/= metro apps when using OAuth (including Facebook=92s OAuth) for authenticati= on. The vulnerability resulted from this misunderstanding also allows an at= tacker to log into a victim user's account without password.

Let's take Soluto's metro app as an example to describe the prob= lem. The app supports Facebook Login. As an attacker, we can write a regula= r Facebook app. Once the victim user allows our app to access her Facebook = data, we receive an access_token from the traffic. Then, on our own machine= (i.e., the "attacker" machine), we run the metro app of Soluto, = and use a HTTP proxy to insert the victim's access_token into the traff= ic of Facebook login. Through this way, we are able to log into the victim&= #39;s Soluto account from our machine. Other than Soluto, we also have conf= irmed the same issue on another Windows 8 metro-app Givit.

The Facebook SDK for Android apps (https://developers.facebook.com/docs/= mobile/android/build/#sdk) seems to have the possibility to mislead dev= elopers too. At least, the issue that we found is not clearly mentioned. In= the SDK, we ran the sample code called "Hackbook" using Android = Emulator (imagine it is an attacker device). Note that we have already rece= ived the access token of the victim user from our regular Facebook app. We = then inject the token to the traffic of Hackbook. Through this way, Hackboo= k app on our own machine recognizes us as the victim. Note that this is not= a convincing security exploit yet, because this sample code does not inclu= de the server-side code. However, given that we have seen real server-side = code having this problem, such as Soluto, Givit and others, we do believe t= hat the sample code can mislead mobile/metro developers. We also suspect th= at this may be a general issue of many OAuth implementations on mobile plat= forms, so we send this message to OAuth Standard group as well.

We have contacted the vendors of the two vulnerable metro-apps, Soluto a= nd Gavit.

Please kindly give us an ack when you receive this message. If you want = to know more details, please let us know.

Best Regards,
Yuchen Zhou, Rui Wang, and Shuo Chen

--14dae9340303abf8c004c271e24d-- From eve@xmlgrrl.com Thu Jun 14 11:16:47 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CB8C21F8637; Thu, 14 Jun 2012 11:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.757 X-Spam-Level: * X-Spam-Status: No, score=1.757 tagged_above=-999 required=5 tests=[AWL=-3.049, BAYES_99=3.5, FROM_DOMAIN_NOVOWEL=0.5, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jkznM1rgCL7U; Thu, 14 Jun 2012 11:16:46 -0700 (PDT) Received: from promanage-inc.com (eliasisrael.com [50.47.36.5]) by ietfa.amsl.com (Postfix) with ESMTP id 27B8221F8628; Thu, 14 Jun 2012 11:16:45 -0700 (PDT) Received: from [192.168.168.185] ([192.168.168.185]) (authenticated bits=0) by promanage-inc.com (8.14.4/8.14.4) with ESMTP id q5EIGhue002955 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 14 Jun 2012 11:16:43 -0700 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Eve Maler In-Reply-To: <1339613945.46084.YahooMailNeo@web31813.mail.mud.yahoo.com> Date: Thu, 14 Jun 2012 11:16:42 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <54EEB138-ABDA-429F-9B0E-0F42D66F96A7@xmlgrrl.com> References: <1339601256.43890.YahooMailNeo@web31803.mail.mud.yahoo.com> <4FD8B646.3080509@stpeter.im> <1339611594.26607.YahooMailNeo@web31806.mail.mud.yahoo.com> <1339613945.46084.YahooMailNeo@web31813.mail.mud.yahoo.com> To: William Mills X-Mailer: Apple Mail (2.1278) Cc: Apps Discuss , Goix Laurent Walter , O Auth WG Subject: Re: [OAUTH-WG] [apps-discuss] OAuth discovery registration. X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 18:16:47 -0000 FWIW, the reason we ultimately went with JSON was that it removed = stumbling blocks around implementation and sheer spec volume. When we = used straight XRD, we found that we had to put a full worked example in = an appendix so it didn't impede the flow of the spec, and implementers = reported to us that JSON would have been much preferable for producing = and consuming the config data. When we found the OpenID Connect example, = it was a natural fit and so we copied it. (Not trying to open up past "JRD" discussions, just sharing our = experience... If OAuth ultimately absorbs some XRD-formatted hunk of = machine-discoverable config data, we'll leverage it.) Eve On 13 Jun 2012, at 11:59 AM, William Mills wrote: > We certainly overlap, the thing you have that is not in the link type = registrations is dynamic_client_registration_supported. We should be = consistent in naming, and ideally the OAuth related JSON elements from a = JSON format Webfinger request and your UMA stuff shoudl be identical. = My concern with using a JSON list structure for capability lists is how = it would play in the LINK header itself, that seems a bit hairy to put a = JSON list inside a quoted application data value. >=20 > Do we want something like a "capabilities" list which could include = dynamic_client_registration_supported and perhaps others? >=20 > -bill >=20 >=20 >=20 >=20 > ----- Original Message ----- >> From: Eve Maler >> To: William Mills >> Cc: Goix Laurent Walter ; Peter = Saint-Andre ; O Auth WG ; Apps = Discuss >> Sent: Wednesday, June 13, 2012 11:38 AM >> Subject: Re: [OAUTH-WG] [apps-discuss] OAuth discovery registration. >>=20 >> Hi Bill-- In incorporating OAuth into several of the UMA flows, we = found a need=20 >> for the authorization server to provide OAuth-related metadata along = with=20 >> UMA-specific metadata. Originally it was strictly XRD- and = hostmeta-based, but=20 >> now uses a JSON format and is more akin to OpenID Connect's metadata = in=20 >> style:=20 >>=20 >> = http://docs.kantarainitiative.org/uma/draft-uma-core.html#am-endpoints >>=20 >> Do you feel that this new draft is something that ultimately *should* = replace=20 >> the OAuth-specific parts of the metadata we've spec'd out for our use=20= >> case? Note that we went beyond just the two endpoints, also covering = a feature=20 >> toggle for "dynamic_client_registration_supported" and lists of=20 >> "oauth_token_profiles_supported" and=20 >> "oauth_grant_types_supported". The purpose in doing this was to=20 >> provide a machine-readable mechanism for aiding OAuth-level interop. >>=20 >> Thanks, >>=20 >> Eve >>=20 >> On 13 Jun 2012, at 11:19 AM, William Mills wrote: >>=20 >>> On the informational status, that seemed right, but I honestly don't=20= >> know what the correct choice is here. The actual registration = happens via=20 >> e-mail I believe, not via this document. >>>=20 >>> Thanks for the feedback! >>>=20 >>> -bill >>>=20 >>>=20 >>>=20 >>> ----- Original Message ----- >>>> From: Goix Laurent Walter >>>> To: Peter Saint-Andre ; William Mills=20 >> >>>> Cc: O Auth WG ; Apps Discuss=20 >> >>>> Sent: Wednesday, June 13, 2012 9:44 AM >>>> Subject: R: [apps-discuss] [OAUTH-WG] OAuth discovery registration. >>>>=20 >>>> T hank you William for this initiative. >>>>=20 >>>> I had similar concerns than Peter on authn vs authz. >>>>=20 >>>> Under section 4.1.1 I would suggest to use "oauth2-authorize"=20 >> instead=20 >>>> of "oauth2-authenticator", to be consistent with the=20 >>>> "oauth2-token" pattern and with the concepts of the oauth2=20 >> draft. >>>>=20 >>>> The header of the pages still reference sasl/gss-api and would need = to=20 >> be=20 >>>> updated. >>>>=20 >>>> Also, an example and/or use case section could be beneficial, e.g. = to=20 >> describe=20 >>>> its usage in an xrd document. Other use cases may be mentioned as = well=20 >> probably. >>>>=20 >>>> I have also noticed that your draft is mentioned as=20 >> "informational".=20 >>>> It is indeed your target or only a typo? >>>>=20 >>>> Thanks >>>> walter >>>>=20 >>>>> -----Messaggio originale----- >>>>> Da: apps-discuss-bounces@ietf.org=20 >> [mailto:apps-discuss-bounces@ietf.org]=20 >>>> Per >>>>> conto di Peter Saint-Andre >>>>> Inviato: mercoled=EC 13 giugno 2012 17.48 >>>>> A: William Mills >>>>> Cc: O Auth WG; Apps Discuss >>>>> Oggetto: Re: [apps-discuss] [OAUTH-WG] OAuth discovery=20 >> registration. >>>>>=20 >>>>> On 6/13/12 9:27 AM, William Mills wrote: >>>>>>=20 >>>>>> Since for the OAUTH SASL mechanism I need discovery for clients=20= >> to >>>>>> work, and I had to rip the in-band discovery out of that=20 >> mechanism, >>>>>> and I need it defined somewhere, I've drafted a small doc=20 >> for the >>>>>> registration of link relation types for OAuth. It's too=20 >> late in=20 >>>> the >>>>>> process to get this into the core OAuth 2 spec, and it=20 >> doesn't=20 >>>> really >>>>>> fit in the WebFinger. Submission info provided below. >>>>>=20 >>>>> Hi Bill, overall this looks good. A few nits: >>>>>=20 >>>>> OLD >>>>> This document defines the LRDD [RFC5988] link type=20 >> registrations for >>>>> the OAuth [I-D.ietf-oauth-v2] authentication framework. = These=20 >> link >>>>> types are used during the endpoint discovery process using = Web=20 >> Host >>>>> Metadata [I-D.hammer-hostmeta] and Webfinger >>>>> [I-D.jones-appsawg-webfinger] by clients needing to discover=20= >> the >>>>> authentication endpoints for a service or site. It=20 >> additionally >>>>> defines link type registrations for OAuth 1.0a [RFC5849]. >>>>>=20 >>>>> NEW >>>>> This document defines the Link-based Resource Descriptor >>>>> Documents (LRDD) [RFC6415] link type registrations for the >>>>> OAuth [I-D.ietf-oauth-v2] authorization framework. These = link >>>>> types are used during the endpoint discovery process using = Web >>>>> Host Metadata [RFC6415] and Webfinger >>>>> [I-D.jones-appsawg-webfinger] by clients needing to discover=20= >> the >>>>> authorization, token, and access token endpoints for an = OAuth2 >>>>> service or site. It additionally defines link type=20 >> registrations for >>>>> OAuth >>>>> 1.0a [RFC5849] request initiation endpoints, authorization=20 >> endpoints, >>>>> and token endpoints. >>>>>=20 >>>>> In Section 4.1.1, you register an "OAuth 2 Authentication=20 >>>> Endpoint", >>>>> however draft-ietf-oauth-v2 defines only an authorization = endpoint,=20 >> a >>>>> token endpoint, and an access token endpoint. Whence this >>>>> "authentication endpoint"? Is it just a typo? >>>>>=20 >>>>> Also, is the lack of a link type for OAuth2 access token endpoints=20= >> an >>>>> oversight? It seems so. >>>>>=20 >>>>> You have "Reference: [[this document]]" but I think you=20 >> want: >>>>>=20 >>>>> Reference: draft-ietf-oauth-v2 >>>>>=20 >>>>> and >>>>>=20 >>>>> Reference: RFC 5849 >>>>>=20 >>>>> You can remove the reference for draft-hammer-hostmeta (RFC 6415=20= >> has >>>>> what you need). >>>>>=20 >>>>> Peter >>>>>=20 >>>>> -- >>>>> Peter Saint-Andre >>>>> https://stpeter.im/ >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> apps-discuss mailing list >>>>> apps-discuss@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/apps-discuss >>>>=20 >>>> Questo messaggio e i suoi allegati sono indirizzati esclusivamente = alle=20 >> persone=20 >>>> indicate. La diffusione, copia o qualsiasi altra azione derivante = dalla=20 >>=20 >>>> conoscenza di queste informazioni sono rigorosamente vietate. = Qualora=20 >> abbiate=20 >>>> ricevuto questo documento per errore siete cortesemente pregati di=20= >> darne=20 >>>> immediata comunicazione al mittente e di provvedere alla sua=20 >> distruzione,=20 >>>> Grazie. >>>>=20 >>>> This e-mail and any attachments is confidential and may contain=20 >> privileged=20 >>>> information intended for the addressee(s) only. Dissemination, = copying,=20 >> printing=20 >>>> or use by anybody else is unauthorised. If you are not the intended=20= >> recipient,=20 >>>> please delete this message and any attachments and advise the = sender by=20 >> return=20 >>>> e-mail, Thanks. >>>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>=20 >>=20 >> Eve Maler = http://www.xmlgrrl.com/blog >> +1 425 345 6756 http://www.twitter.com/xmlgrrl >>=20 >=20 Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl From eve@xmlgrrl.com Thu Jun 14 11:18:06 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE33421F8637 for ; Thu, 14 Jun 2012 11:18:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.024 X-Spam-Level: X-Spam-Status: No, score=0.024 tagged_above=-999 required=5 tests=[AWL=0.716, BAYES_00=-2.599, FROM_DOMAIN_NOVOWEL=0.5, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, 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 S47FBHmA-Jb0 for ; Thu, 14 Jun 2012 11:18:04 -0700 (PDT) Received: from promanage-inc.com (eliasisrael.com [50.47.36.5]) by ietfa.amsl.com (Postfix) with ESMTP id 8D5AA21F867A for ; Thu, 14 Jun 2012 11:18:04 -0700 (PDT) Received: from [192.168.168.185] ([192.168.168.185]) (authenticated bits=0) by promanage-inc.com (8.14.4/8.14.4) with ESMTP id q5EIFUgQ002923 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 14 Jun 2012 11:15:30 -0700 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_FCEA4297-F604-42DE-91BA-E8373AC35188" From: Eve Maler In-Reply-To: Date: Thu, 14 Jun 2012 11:15:29 -0700 Message-Id: <378E8240-86AD-4429-8787-05A05616B5ED@xmlgrrl.com> References: <4E1F6AAD24975D4BA5B16804296739436652F52D@TK5EX14MBXC284.redmond.corp.microsoft.com> <4FD4E9D4.2010808@gmx.de> <4E1F6AAD24975D4BA5B168042967394366531375@TK5EX14MBXC284.redmond.corp.microsoft.com> <4FD4F976.6090801@gmx.de> <4E1F6AAD24975D4BA5B1680429673943665316D1@TK5EX14MBXC284.redmond.corp.microsoft.com> <60F5CCB0-E036-4351-BD10-A44B33FCC5F6@ve7jtb.com> <255B9BB34FB7D647A506DC292726F6E114F5474E29@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B1680429673943665346D0@TK5EX14MBXC284.redmond.corp.microsoft.com> <4FD703C4.6050801@gmx.de> <5E38109E-2123-418B-8D45-B8DF4287790D@gmx.net> <1339525052.8121.YahooMailNeo@web31807.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B168042967394366535EAD@TK5EX14MBXC284.redmond.corp.microsoft.com> <0CBAEB56DDB3A140BA8E8C124C04ECA20106ED1F@P3PWEX2MB008.ex2.secureserver.net> <1339531450.39923.YahooMailNeo@web31809.mail.mud.yahoo.com> <0CBAEB56DDB3A140BA8E8C124C04ECA20106F052@P3PWEX2MB008.ex2.secureserver.net> <3CCE477A-673D-450A-A310-3C5F1A8002DE@xmlgrrl.com> To: Jianhua Shao X-Mailer: Apple Mail (2.1278) Cc: Julian Reschke , Richard Mortier , WG UMA , "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion needed on username and password ABNF definitions X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 18:18:06 -0000 --Apple-Mail=_FCEA4297-F604-42DE-91BA-E8373AC35188 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Oops, sorry, should have pointed to the version of the draft that's = actually meant for the OAuth WG workstream: http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-00 We hope to contribute as this work proceeds in the OAuth group, and I've = also learned that Tom Brown has an open-source implementation here: = https://github.com/herestomwiththeweather/cyberwire/blob/master/src/org/op= ensourcecurrency/hack/AddProvider.java#L197 (He wrote recently to the OAuth list with a question about the spec: = http://www.ietf.org/mail-archive/web/oauth/current/msg09053.html) Eve p.s. I'm cc'ing the UMA WG here just to inform them of all this. = Followups should be directed only to the appropriate list(s). On 13 Jun 2012, at 1:52 PM, Jianhua Shao wrote: > Hi, UMA-flavored sound quite close to our dataware.catalog design to = solve similar problem in dynamic auth and registration. I am interesting = to know how it would push to next stage as it expired on 26 April 2012.=20= >=20 > Currently OAuth 2 are one way registration and authentication, which = is client register on authorisation server and also auth in the same = direction. Have you think about the cases that either side can start the = registration, which is in additional that authorisation server wants = client to register on it and give the permission to access to limited = resources. We met this demand that if I heard a application is very = useful by listening to my friend, I would like to actively give = permission to this application to start to use it.=20 >=20 > A concrete example is from my real experience that when I travel to = China, I have use a search engine called Baidu.com, because I am new to = this search engine but I am using google as daily, so there is a app = could leave the port that could move any historical search data into = baidu.com, If I can actively give my permission of google search history = data into that app, I would than have baidu.com to use in right way. If = you think about many other cases in the life, it is actually a very = common demand.=20 >=20 > So have you think about this kind of dynamic registration/auth, and = also can enable either side to start the process? Just want to know = where and how to contribute to your existing work.=20 >=20 > Jian >=20 > On 13 Jun 2012, at 19:42, Eve Maler wrote: >=20 >> Also please see the UMA-flavored use cases (there are two) and the = summary of requirements provided in this input document: >>=20 >> http://tools.ietf.org/html/draft-oauth-dyn-reg-v1-03 >>=20 >> Eve >>=20 >> On 12 Jun 2012, at 1:39 PM, Jianhua Shao wrote: >>=20 >>> Hello, >>>=20 >>> Dynamic client registration is very useful if client or resource or = authorisation server is not permanently available.=20 >>> A typical case is that is the resource or authorisation server is in = mobile platform, the connection is not always available.=20 >>> Another typical case is that authorisation server do not necessary = to have client pre-registered on itself. At moment, industry like = facebook would like developer to register a app on its app centre first, = and then ask user auth to use the app.=20 >>>=20 >>> We are researchers from Digital Economy Research Institute. We have = this problem When we developing Dataware that could manage the control = of access to personal data. We play around our solution base on Oauth2: = https://github.com/jianhuashao/dataware.catalog/wiki >>>=20 >>> We are in the list to receive your maillist, but currently need = moderate to post any message. cc my colleague, Richard Mortier >>> Best >>> Jian >>>=20 >>>=20 >>> On 12 Jun 2012, at 21:08, Eran Hammer wrote: >>>=20 >>>> The only distinction I would make is between removing flexibiliy to = proactively enabling future extensibility. I would stop short of = perscribing encoding in order to fit uri into the Basic auth fields. But = if there is a way to allow this to be less restrictive without clean = interop issues, that would be nice. >>>> =20 >>>> I do agree we need some actual use cases before we spend much more = time on this. >>>> =20 >>>> EH >>>> =20 >>>> From: William Mills [mailto:wmills@yahoo-inc.com]=20 >>>> Sent: Tuesday, June 12, 2012 1:04 PM >>>> To: Eran Hammer; Mike Jones; Hannes Tschofenig; Julian Reschke >>>> Cc: oauth@ietf.org >>>> Subject: Dynamic clients, URI, and stuff Re: [OAUTH-WG] Discussion = needed on username and password ABNF definitions >>>> =20 >>>> I think dynamic client registration is something we have not talked = out enough yet. There's a pretty clear use case for dynamic = registration. =20 >>>> =20 >>>> Does identifying the client with a URI allow some form of = OpenID-ish flow for this?=20 >>>> Is the client ID as a URI a way to allow a trusted site to provide = metadata about the client? >>>> Is that URI a way to hit an IDP we trust to validate the client in = some way with the provided secret? >>>> =20 >>>> I guess what I'm looking for here is a concrete use case/problem to = solve, rather then leaving a hook we think is the right thing. >>>> =20 >>>> -bill >>>> =20 >>>> =20 >>>> From: Eran Hammer >>>> To: Mike Jones ; William Mills = ; Hannes Tschofenig ; = Julian Reschke =20 >>>> Cc: "oauth@ietf.org" =20 >>>> Sent: Tuesday, June 12, 2012 11:39 AM >>>> Subject: RE: [OAUTH-WG] Discussion needed on username and password = ABNF definitions >>>> =20 >>>> Is the use case of using URI as client ids important? It seems like = something that might become useful in the future where clients can use = their verifiable servers to bypass client registration and simly use a = URI the server can validate via some other means. >>>> =20 >>>> I just want to make sure those thinking about more complex use = cases involving dynamic registration or distributed client manamgenet = are aware of this potential restriction. >>>> =20 >>>> I'm fine either way. >>>> =20 >>>> EH >>>> =20 >>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf Of Mike Jones >>>> Sent: Tuesday, June 12, 2012 11:27 AM >>>> To: William Mills; Hannes Tschofenig; Julian Reschke >>>> Cc: oauth@ietf.org >>>> Subject: Re: [OAUTH-WG] Discussion needed on username and password = ABNF definitions >>>> =20 >>>> Not internationalizing fields intended for machine consumption only = is already a precedent set and agreed to by the working group, so let me = second Bill=92s point in that regard. For instance, neither =93scope=94 = nor =93error=94 allow non-ASCII characters. >>>> =20 >>>> Julian, if you want different ABNF text than the text I wrote = below, I believe it would be most useful if you would provide the exact = replace wording that you=92d like to see instead of it. Then there=92s = no possibility of misunderstanding the intent of suggested changes. >>>> =20 >>>> Thanks = all, >>>> -- Mike >>>> =20 >>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf Of William Mills >>>> Sent: Tuesday, June 12, 2012 11:18 AM >>>> To: Hannes Tschofenig; Julian Reschke >>>> Cc: oauth@ietf.org >>>> Subject: Re: [OAUTH-WG] Discussion needed on username and password = ABNF definitions >>>> =20 >>>> I agree generally with your assumption about clients, but rather = than saying "clients are devices" I think it makes much more sense to = say "clients are NOT users, so client_id need not be internationalized". = In practical terms there is very little to argue for anythign beyond = ASCII in a client_secret, base64 encoding or the equivalent being a fine = way to transport arbitrary bits in a portable/reasonable way. >>>> =20 >>>> I argue that client_id need not be internationalized because I = assume that any really internationalized application will have an = internationalized presentation layer that's presenting a pretty name for = the client_id. >>>> =20 >>>> -bill >>>> =20 >>>> From: Hannes Tschofenig >>>> To: Julian Reschke =20 >>>> Cc: "oauth@ietf.org" =20 >>>> Sent: Tuesday, June 12, 2012 11:01 AM >>>> Subject: Re: [OAUTH-WG] Discussion needed on username and password = ABNF definitions >>>>=20 >>>> I had a chat with Julian yesterday and here is my short summary.=20 >>>>=20 >>>> Section 2.3 of the core draft defines client authentication based = on two mechanisms (and provides room for = extensions):http://tools.ietf.org/html/draft-ietf-oauth-v2-27#section-2.3 >>>>=20 >>>> 1) HTTP Basic Authentication >>>>=20 >>>> 2) A custom OAuth authentication mechanism (which uses client_id = and client_secret) >>>>=20 >>>> With HTTP Basic authentication the problem is that this is a legacy = technology and there is no internationalization support.=20 >>>>=20 >>>> With our brand new custom OAuth authentication mechanism we have = more options.=20 >>>>=20 >>>> One possible approach is to say that the clients are devices (and = not end users) and therefore internationalization does not matter.=20 >>>>=20 >>>> Is it, however, really true that only US-ASCII characters will = appear in the client_id and also in the client_secret?=20 >>>>=20 >>>> Here we have the possibility to define something better.=20 >>>>=20 >>>> In any case we have to restrict the characters that are used in = these two authentication mechanisms since they could conflict with the = way how we transport the data over the underlying protocol. Julian = mentioned this in his previous mails.=20 >>>>=20 >>>> Julian, maybe you can provide a detailed text proposal for how to = address your comment in case we go for UTF8 (with % encoding) for the = custom OAuth client authentication mechanism?=20 >>>>=20 >>>> Ciao >>>> Hannes >>>>=20 >>>> On Jun 12, 2012, at 11:54 AM, Julian Reschke wrote: >>>>=20 >>>> > On 2012-06-12 00:16, Mike Jones wrote: >>>> >> Reviewing the feedback from Julian, John, and James, I'm coming = to the conclusion that client_id and client_secret, being for machines = and not humans, should be ASCII, whereas username and password should be = Unicode, since they are for humans. Per John's feedback, client_id can = not contain a colon and be compatible with HTTP Basic. >>>> >=20 >>>> > I'm not sure that restricting the character repertoire just = because one way to send requires this is the right approach. My = preference would be not to put this into the ABNF, and just to point out = that certain characters will not work over certain transports, and to = just advise to avoid them. >>>> >=20 >>>> >> Therefore, I'd like to propose these updated ABNF definitions: >>>> >>=20 >>>> >> VSCHAR =3D %20-7E >>>> >> NOCOLONVSCHAR =3D %x20-39 / %x3B-7E >>>> >> UNICODENOCTRLCHAR =3D >>>> >>=20 >>>> >> client-id =3D *NOCOLONVSCHAR >>>> >> client_secret =3D *VSCHAR >>>> >>=20 >>>> >> username =3D *UNICODENOCTRLCHAR >>>> >> password =3D *UNICODENOCTRLCHAR >>>> >=20 >>>> > In this case you should add an introductory statement pointing = out that the ABNF defines the grammar in terms of Unicode code points, = not octets (as it is the case most of the time). >>>> >=20 >>>> >> It turns out that non-ASCII characters are OK for username and = password because the Core spec only passes them in the form body - not = using HTTP Basic - and UTF-8 encoding is specified. >>>> >=20 >>>> > I'll send a separate mail about that, the current text in the = spec is way too unspecific. >>>> >=20 >>>> >> -- Mike >>>> >>=20 >>>> >> P.S. If anyone has a better ABNF for UNICODENOCTRLCHAR than = "", please send it = to me! >>>> >=20 >>>> > As noted before, here's an example: = >>>> >=20 >>>> > Best regards, Julian >>>> > _______________________________________________ >>>> > OAuth mailing list >>>> > OAuth@ietf.org >>>> > https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> =20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>>=20 >>> This message and any attachment are intended solely for the = addressee and may contain confidential information. If you have received = this message in error, please send it back to me, and immediately delete = it. Please do not use, copy or disclose the information contained in = this message or in any attachment. Any views or opinions expressed by = the author of this email do not necessarily reflect the views of the = University of Nottingham. >>>=20 >>> This message has been checked for viruses but the contents of an = attachment may still contain software viruses which could damage your = computer system: you are advised to perform your own checks. Email = communications with the University of Nottingham may be monitored as = permitted by UK legislation. >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >> Eve Maler = http://www.xmlgrrl.com/blog >> +1 425 345 6756 = http://www.twitter.com/xmlgrrl >>=20 >>=20 >=20 Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl --Apple-Mail=_FCEA4297-F604-42DE-91BA-E8373AC35188 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 http://too= ls.ietf.org/html/draft-ietf-oauth-dyn-reg-00

= We hope to contribute as this work proceeds in the OAuth group, and I've = also learned that Tom Brown has an open-source implementation = here:


= Hi John,

would it make sense to use a hash of the URI instead of the URI itself in yo= ur use case?

regards,
Torsten.



John Bradley <ve7jtb@ve7jtb.com&= gt; schrieb:
I think that the issues are getting confused.

There is a u= se case where the Authorization server may be a embedded app, at least in on= e openID case.    As it won't have a separate registration or toke= n endpoint,  the client needs to make its own clientID for the request.=   A reasonable thing to use is the redirect URI to create a unique val= ue that the user could use for revocation at a later point.

Currently with the no : restriction we would use the host and path t= o crate the clientid.
There are some scenarios where having the sc= heme as part of that would be helpful.

This has not= hing to do with discovery or the dynamic client registration proposal as far= as I know.

A URL as a client_id comes from prototy= pe work for a personal provider that we are doing as part of openID Connect.=

John B.
On 2012-06-13, at 7:50 AM, To= rsten Lodderstedt wrote:

Hi all,=

can anyone please explain the relation between dynamic client registration a= nd URIs as client ids? None of the current drafts (uma or connect) seem to r= equire URIs.

regards,
Torsten.



Jianhua Shao <psxjs4@nottingha= m.ac.uk> schrieb:
Hello,

Dynamic client registration is very use= ful if client or resource or authorisation server is not permanently availab= le. 
A typical case is that is the resource or authorisation s= erver is in mobile platform, the connection is not always available. 
Another typical case is that authorisation server do not necessary t= o have client pre-registered on itself. At moment, industry like facebook wo= uld like developer to register a app on its app centre first, and then ask u= ser auth to use the app. 

We are researchers f= rom Digital Economy Research Institute. We have this problem When we develop= ing Dataware that could manage the control of access to personal data. We pl= ay around our solution base on Oauth2: https://github.com/jianhuashao/dataware.cat= alog/wiki

We are in the list to receive your ma= il list, but currently need moderate to post any message. cc my colleague, Richard Mo= rtier
Best
Jian


On 12 J= un 2012, at 21:08, Eran Hammer wrote:

The only distinction I would make is between removing flexibiliy to p= roactively enabling future extensibility. I would stop short of perscribing e= ncoding in order to fit uri into the Basic auth fields. But if there is a wa= y to allow this to be less restrictive without clean interop issues, that wo= uld be nice.
 
I do a= gree we need some actual use cases before we spend much more time on this.
 
EH
 
From: William Mills [mailto:wmills@yahoo-inc.com] 
Sent: Tuesday, June 12, 2012 1:04 PM
To: Eran Hammer; Mike Jones; Hann= es Tschofenig; Julian Reschke
Cc: oauth@ietf.org
Subject: Dynamic clie= nts, URI, and stuff Re: [OAUTH-WG] Discussion needed on username and passwor= d ABNF definitions
 
I think dynamic client registrati= on is something we have not talked out enough yet.  There's a pretty cl= ear use case for dynamic registration.  
&n= bsp;
Is the client ID as a UR= I a way to=20 allow a trusted site to provide metadata about the client?
Is that= URI a way to hit an IDP we trust to validate the client in some way with th= e provided secret?
 
I guess what I= 'm looking for here is a concrete use case/problem to solve, rather then lea= ving a hook we think is the right thing.
<= div style=3D"margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bo= ttom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; back= ground-image: initial; background-attachment: initial; background-origin: in= itial; background-clip: initial; background-color: white; "> 
-bill
 
 
<= /span>
= From: E= ran Hammer <eran@hueniverse.com>
To: Mike Jones <Michael.Jones@microsoft.com>; William Mills <wmills@yahoo-inc.com>; Hannes Tschofenig <ha= nnes.tschofenig@gmx.net>; Julian Reschke <julian.= reschke@gmx.de> Cc: "oau= th@ietf.org" <oauth@ietf.org> 
Sent: Tuesday, June 12, 2012 11:39 AM
Subject: RE: [OAUTH-WG] Discussion needed= on username and password ABNF definitions
 
Is the use case of using URI as client ids important? It seems li= ke something that might become useful in the future where clients can use th= eir verifiable servers to bypass client registration and simly use a URI the server can validate via some other means.
 
I just want to make s= ure those thinking about more complex use cases involving dynamic registrati= on or distri buted client manamgenet are aware of this potential restriction.
 
I'm fin= e either way.
<= /div>
 
EH
 
From:&nbs= p;oauth-bounces@ietf.org [mailto:oauth-bounces= @ietf.org] On Behal= f Of Mike Jones
= Sent: Tuesday, June 12= , 2012 11:27 AM
To: William Mills; Hannes Tschofenig; Julian Reschke
Cc: oauth@ietf.org
= Subject: Re: [OAUTH-WG= ] Discussion needed on username and password ABNF definitions
 
Not internationalizing fields intended for machine consumption onl= y is already a precedent set and agreed to by the working group, so let me s= econd Bill=E2=80=99s point in that regard.  For instance, neither =E2=80= =9Cscope=E2=80=9D nor =E2=80=9Cerror=E2=80=9D allow non-ASCII characters.
 
Julian, if you want different A= BNF text than the text I wrote below, I believe it would be most useful if y= ou would provide the exact replace wording that you=E2=80=99d like to see in= stead of it.  Then there=E2=80=99s no possibility of misunderstanding t= he intent of suggested changes.
&nbs= p;
<= div style=3D"margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12p= t; font-family: 'Times New Roman', serif; background-image: initial; backgro= und-attachment: initial; background-origin: initial; background-clip: initia= l; background-color: white; ">          &nb= sp;            &= nbsp;            = ;            &nb= sp;           Thanks all,<= /span>
      &nbs= p;            &n= bsp;            =             &nbs= p;            &n= bsp;  -- Mike
=  
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of William Mills
Sent: Tuesday, June 12, 2012 11:18 AM
T= o: Hannes Tschofenig; J= ulian Reschke
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Discussion needed on= username and password ABNF definitions
 
I agree generally with your assu= mption about clients, but rather than saying "clients are devices" I think i= t makes much more sense to say "clients are NOT users, so client_id need not= be internationalized".  In practical terms there is very little to arg= ue for anythign beyond ASCII in a client_secret, base64 encoding or the equi= valent being a fine way to transport arbitrary bits in a portable/reasonable= way.
 
I argue that client_id need not be internationali= zed because I assume that any really internationalized application will have= an internationalized presentation layer that's presenting a pretty name for= the client_id.
 
-bill
 
From:=  Hannes Tschofenig <hannes.tschofenig@gmx.net>
To: Julian Reschke <julian.reschke@gmx.de> 
Cc: "oauth@ietf.org" <oauth@ietf.org> =
Sent: Tu= esday, June 12, 2012 11:01 AM
Subject: Re: [OAUTH-WG] Discussion needed on username and pass= word ABNF definitions

= I had a chat with Julian yesterday and here is my short summary. 

Section 2.3 of the core draft d= efines client authentication based on two mechanisms (and provides room for extensions):http://tools.ietf.org/html/draft-ietf-oauth-v2-27#section-2.3
1) HTTP Basic Authentication

2) A custom OAuth authentication mechan= ism (which uses client_id and client_secret)

With HTTP Basic authenti= cation the problem is that this is a legacy technology and there is no inter= nationalization support. <= br>
With our brand new custom OAuth authentication mechanism we have more= options. 

One poss= ible approach is to say that the clients are devices (and not end users) and= therefore internationalization does not matter. 

Is it, however, really true that only US-ASCI= I characters will appear in the client_id and also in the client_secret? 

Here we have the poss= ibility to define something better.&nb= sp;

In any case we have to restrict the characters that are us= ed in these two authentication mechanisms since they could conflict with the= way how we transport the data over the underlying protocol. Julian mentione= d this in his previous mails. 

Julian, maybe you can provide a detailed text proposal for how t= o address your comment in case we go for UTF8 (with % encoding) for the cust= om OAuth client authentication mechanism? 

Ciao
Hannes

On Jun 12, 2012, at 11:54 AM, J= ulian Reschke wrote:

> On 2012-06-12 00:16, Mike Jones wrote:
&= gt;> Reviewing the feedback from Julian, John, and James, I'm coming to t= he conclusion that client_id and client_secret, being for machines and not h= umans, shou ld be ASCII, whereas username and password should be Unicode, since they are for h= umans.  Per John's feedback, client_id can not contain a colon and be c= ompatible with HTTP Basic.
>&nbs= p;
> I'm not sure that restricting the character repertoire jus= t because one way to send requires this is the right approach. My preference= would be not to put this into the ABNF, and just to point out that certain c= haracters will not work over certain transports, and to just advise to avoid= them.
> 
>>= ; Therefore, I'd like to propose these updated ABNF definitions:
>>=  
>>   = VSCHAR =3D %20-7E
>>    NOCOLONVSCHAR =3D %x20-39 / %x3B= -7E
>>    UNICODENOCTRLCHAR =3D <Any Unicode character= other than ( %x0-1F / %x7F )>
>> 
>>    client-id =3D *NOCOLONVSCHAR>>    client_secret =3D *VSCHAR
>> 
>>    username =3D *= UNICODENOCTRLCHAR
>>    password =3D *UNICODENOCTRLCHAR> 
> In this ca= se you should add an introductory statement pointing out that the ABNF defin= es the grammar in terms of Unicode code points, not octets (as it is the cas= e most of the time).
> 
>> It turns out that non-ASCII characters are OK for username a= nd password because the Core spec only passes them in the form body - not us= ing HTTP Basic - and UTF-8 encoding is specified.
> 
> I'll send a separate mail about tha= t, the current text in the spec is way too unspecific.
> 
>>      &= nbsp;          -- Mike
>> 
>> P.S.  If anyon= e has a better ABNF for UNICODENOCTRLCHAR than "<Any Unicode character ot= her than ( %x0-1F / %x7F )>", please send it to me!
> 
> As noted before, here's an exa= mple: <http://greenbytes.de/tech/webdav/rfc5323.html#rfc.section.5.15.1>= ;
> 
> Best re= gards, Julian
> _______________________________________________
>= ; OAuth mailing list
> OAuth@ietf.org
> https://www.= ietf.org/mailman/listinfo/oauth

_________________________________= ______________
OAuth mailing list
OAuth@ie= tf.org
https://www.= ietf.org/mailman/listinfo/oauth

=  

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

This message and any attachment are intended solely for the addressee and ma= y=20 contain confidential information. If you have received this message in error= ,=20 please send it back to me, and immediately delete it. Please do not use,=20= copy or disclose the information contained in this message or in any attachm= ent. =20 Any views or opinions expressed by the author of this email do not necessari= ly=20 reflect the views of the University of Nottingham.

This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.

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

= --Apple-Mail-37858920-0382-4908-ADCD-97561D694E05-- --Apple-Mail-F275A567-1AA9-4A45-A44E-081D2C173A6C Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIVvjCCBjQw 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/d1WwqI26kFo5k7686AmpUMIIHyTCCBbGgAwIBAgIBATANBgkqhkiG9w0B AQUFADB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlm aWNhdGlvbiBBdXRob3JpdHkwHhcNMDYwOTE3MTk0NjM2WhcNMzYwOTE3MTk0NjM2WjB9MQswCQYD VQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwg Q2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRo b3JpdHkwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDBiNsJvGxGfHiflXu1M5DycmLW wTYgIiRezul38kMKogZkpMyONvg45iPwbm2xPN1yo4UcodM9tDMr0y+v/uqwQVlntsQGfQqedIXW eUyAN3rfOQVSWff0G0ZDpNKFhdLDcfN1YjS6LIp/Ho/u7TTQEceWzVI9ujPW3U3eCztKS5/CJi/6 tRYccjV3yjxd5srhJosaNnZcAdt0FCX+7bWgiA/deMotHweXMAEtcnn6RtYTKqi5pquDSR3l8u/d 5AGOGAqPY1MWhWKpDhk6zLVmpsJrdAfkK+F2PrRt2PZE4XNiHzvEvqBTViVsUQn3qqvKv3b9bZvz ndu/PWa8DFaqr5hIlTpL36dYUNk4dalb6kMMAv+Z6+hsTXBbKWWc3apdzK8BMewM69KN6Oqce+Zu 9ydmDBpI125C4z/eIT574Q1w+2OqqGwaVLRcJXrJosmLFqa7LH4XXgVNWG4SHQHuEhANxjJ/GP/8 9PrNbpHoNkm+Gkhpi8KWTRoSsmkXwQqQ1vp5Iki/untp+HDH+no32NgN0nZPV/+Qt+OR0t3vwmC3 Zzrd/qqc8NSLf3Iizsafl7b4r4qgEKjZ+xjGtrVcUjyJthkqcwEKDwOzEmDyei+B26Nu/yYwl/WL 3YlXtq09s68rxbd2AvCl1iuahhQqcvbjM4xdCUsT37uMdBNSSwIDAQABo4ICUjCCAk4wDAYDVR0T BAUwAwEB/zALBgNVHQ8EBAMCAa4wHQYDVR0OBBYEFE4L7xqkQFulF2mHMMo0aEPQQa7yMGQGA1Ud HwRdMFswLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwuY3JsMCugKaAn hiVodHRwOi8vY3JsLnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwuY3JsMIIBXQYDVR0gBIIBVDCCAVAw ggFMBgsrBgEEAYG1NwEBATCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9y Zy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50ZXJt ZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQgQ29tbWVyY2lhbCAoU3RhcnRDb20p IEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBM aW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGlj eSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZI AYb4QgEBBAQDAgAHMDgGCWCGSAGG+EIBDQQrFilTdGFydENvbSBGcmVlIFNTTCBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTANBgkqhkiG9w0BAQUFAAOCAgEAFmyZ9GYMNPXQhV59CuzaEE44HF7fpiUF S5Eyweg78T3dRAlbB0mKKctmArexmvclmAk8jhvh3TaHK0u7aNM5Zj2gJsfyOZEdUauCe37Vzlrk 4gNXcGmXCPleWKYK34wGmkUWFjgKXlf2Ysd6AgXmvB618p70qSmD+LIU424oh0TDkBreOKk8rENN ZEXO3SipXPJzewT4F+irsfMuXGRuczE6Eri8sxHkfY+BUZo7jYn0TZNmezwD7dOaHZrzZVD1oNB1 ny+v8OqCQ5j4aZyJecRDjkZy42Q2Eq/3JR44iZB3fsNrarnDy0RLrHiQi+fHLB5LEUTINFInzQpd n4XBidUaePKVEFMy3YCEZnXZtWgo+2EuvoSoOMCZEoalHmdkrQYuL6lwhceWD3yJZfWOQ1QOq92l gDmUYMA0yZZwLKMS9R9Ie70cfmu3nZD0Ijuu+PwqyvqCUqDvr0tVk+vBtfAii6w0TiYiBKGHLHVK t+V9E9e4DGTANtLJL4YSjCMJwRuCO3NJo2pXh5Tl1njFmUNj403gdy3hZZlyaQQaRwnmDwFWJPsf vw55qVguucQJAX6Vum0ABj6y6koQOdjQK/W/7HW/lwLFCRsI3FU34oH7N4RDYiDK51ZLZer+bMEk kyShNOsF/5oirpt9P/FlUQqmMGqz9IgcgA38corog14xggNsMIIDaAIBATCBkzCBjDELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENl cnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRl cm1lZGlhdGUgQ2xpZW50IENBAgIeXDAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjA2MTMxODQwMTRaMCMGCSqGSIb3DQEJBDEWBBTocCaH cOGJdua7PcUQHfjT14hpbTCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQG A1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBD bGllbnQgQ0ECAh5cMIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDANBgkqhkiG9w0BAQEFAASCAQCFYRCFtwhe51UEN4cVdkvzbMA/jjCz2tFbPVvT YqMyj5AI/hVwGc4uiilyrRp94G7uGOzJs043JXkzx8tlaCI/CaZLSCj2bNHzaVVa3X5LsL520GAg YRQtXnaZ2nYAzrcFd4cm67CMjbaYE7II5Y2yXW4Cizq1Lq5yDyO688q36xTuRVLSR2JAHZ/0M2/G PZJ/o8fpliW7O8HmkuuzCbzhn0R6dfmQNwpBfAq3V/gjkrEGw/kv2yhLquboLlMD1t8iZw7Y7jsa E4u6uo4RpIRZr49JEb1+NTmZQYhM7gUZjUYfIwJaOVQQTm8q3053385Q+F+w/y6VbNRF4gIy5a6K AAAAAAAA --Apple-Mail-F275A567-1AA9-4A45-A44E-081D2C173A6C-- From eve@xmlgrrl.com Wed Jun 13 11:42:47 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7BDA21F850B for ; Wed, 13 Jun 2012 11:42:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.293 X-Spam-Level: X-Spam-Status: No, score=-1.293 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 dykjEnvd7Fp1 for ; Wed, 13 Jun 2012 11:42:46 -0700 (PDT) Received: from promanage-inc.com (eliasisrael.com [50.47.36.5]) by ietfa.amsl.com (Postfix) with ESMTP id 8898D21F8463 for ; Wed, 13 Jun 2012 11:42:45 -0700 (PDT) Received: from [192.168.168.185] ([192.168.168.185]) (authenticated bits=0) by promanage-inc.com (8.14.4/8.14.4) with ESMTP id q5DIgdBL011426 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 13 Jun 2012 11:42:39 -0700 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_1D4BE40A-F1B7-4C63-8229-1C76A6FFA8BE" From: Eve Maler In-Reply-To: Date: Wed, 13 Jun 2012 11:42:39 -0700 Message-Id: <3CCE477A-673D-450A-A310-3C5F1A8002DE@xmlgrrl.com> References: <4E1F6AAD24975D4BA5B16804296739436652F52D@TK5EX14MBXC284.redmond.corp.microsoft.com> <4FD4E9D4.2010808@gmx.de> <4E1F6AAD24975D4BA5B168042967394366531375@TK5EX14MBXC284.redmond.corp.microsoft.com> <4FD4F976.6090801@gmx.de> <4E1F6AAD24975D4BA5B1680429673943665316D1@TK5EX14MBXC284.redmond.corp.microsoft.com> <60F5CCB0-E036-4351-BD10-A44B33FCC5F6@ve7jtb.com> <255B9BB34FB7D647A506DC292726F6E114F5474E29@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B1680429673943665346D0@TK5EX14MBXC284.redmond.corp.microsoft.com> <4FD703C4.6050801@gmx.de> <5E38109E-2123-418B-8D45-B8DF4287790D@gmx.net> <1339525052.8121.YahooMailNeo@web31807.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B168042967394366535EAD@TK5EX14MBXC284.redmond.corp.microsoft.com> <0CBAEB56DDB3A140BA8E8C124C04ECA20106ED1F@P3PWEX2MB008.ex2.secureserver.net> <1339531450.39923.YahooMailNeo@web31809.mail.mud.yahoo.com> <0CBAEB56DDB3A140BA8E8C124C04ECA20106F052@P3PWEX2MB008.ex2.secureserver.net> To: Jianhua Shao X-Mailer: Apple Mail (2.1278) Cc: Julian Reschke , Richard Mortier , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion needed on username and password ABNF definitions X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 18:42:47 -0000 --Apple-Mail=_1D4BE40A-F1B7-4C63-8229-1C76A6FFA8BE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Also please see the UMA-flavored use cases (there are two) and the = summary of requirements provided in this input document: http://tools.ietf.org/html/draft-oauth-dyn-reg-v1-03 Eve On 12 Jun 2012, at 1:39 PM, Jianhua Shao wrote: > Hello, >=20 > Dynamic client registration is very useful if client or resource or = authorisation server is not permanently available.=20 > A typical case is that is the resource or authorisation server is in = mobile platform, the connection is not always available.=20 > Another typical case is that authorisation server do not necessary to = have client pre-registered on itself. At moment, industry like facebook = would like developer to register a app on its app centre first, and then = ask user auth to use the app.=20 >=20 > We are researchers from Digital Economy Research Institute. We have = this problem When we developing Dataware that could manage the control = of access to personal data. We play around our solution base on Oauth2: = https://github.com/jianhuashao/dataware.catalog/wiki >=20 > We are in the list to receive your maillist, but currently need = moderate to post any message. cc my colleague, Richard Mortier > Best > Jian >=20 >=20 > On 12 Jun 2012, at 21:08, Eran Hammer wrote: >=20 >> The only distinction I would make is between removing flexibiliy to = proactively enabling future extensibility. I would stop short of = perscribing encoding in order to fit uri into the Basic auth fields. But = if there is a way to allow this to be less restrictive without clean = interop issues, that would be nice. >> =20 >> I do agree we need some actual use cases before we spend much more = time on this. >> =20 >> EH >> =20 >> From: William Mills [mailto:wmills@yahoo-inc.com]=20 >> Sent: Tuesday, June 12, 2012 1:04 PM >> To: Eran Hammer; Mike Jones; Hannes Tschofenig; Julian Reschke >> Cc: oauth@ietf.org >> Subject: Dynamic clients, URI, and stuff Re: [OAUTH-WG] Discussion = needed on username and password ABNF definitions >> =20 >> I think dynamic client registration is something we have not talked = out enough yet. There's a pretty clear use case for dynamic = registration. =20 >> =20 >> Does identifying the client with a URI allow some form of OpenID-ish = flow for this?=20 >> Is the client ID as a URI a way to allow a trusted site to provide = metadata about the client? >> Is that URI a way to hit an IDP we trust to validate the client in = some way with the provided secret? >> =20 >> I guess what I'm looking for here is a concrete use case/problem to = solve, rather then leaving a hook we think is the right thing. >> =20 >> -bill >> =20 >> =20 >> From: Eran Hammer >> To: Mike Jones ; William Mills = ; Hannes Tschofenig ; = Julian Reschke =20 >> Cc: "oauth@ietf.org" =20 >> Sent: Tuesday, June 12, 2012 11:39 AM >> Subject: RE: [OAUTH-WG] Discussion needed on username and password = ABNF definitions >> =20 >> Is the use case of using URI as client ids important? It seems like = something that might become useful in the future where clients can use = their verifiable servers to bypass client registration and simly use a = URI the server can validate via some other means. >> =20 >> I just want to make sure those thinking about more complex use cases = involving dynamic registration or distributed client manamgenet are = aware of this potential restriction. >> =20 >> I'm fine either way. >> =20 >> EH >> =20 >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf Of Mike Jones >> Sent: Tuesday, June 12, 2012 11:27 AM >> To: William Mills; Hannes Tschofenig; Julian Reschke >> Cc: oauth@ietf.org >> Subject: Re: [OAUTH-WG] Discussion needed on username and password = ABNF definitions >> =20 >> Not internationalizing fields intended for machine consumption only = is already a precedent set and agreed to by the working group, so let me = second Bill=92s point in that regard. For instance, neither =93scope=94 = nor =93error=94 allow non-ASCII characters. >> =20 >> Julian, if you want different ABNF text than the text I wrote below, = I believe it would be most useful if you would provide the exact replace = wording that you=92d like to see instead of it. Then there=92s no = possibility of misunderstanding the intent of suggested changes. >> =20 >> Thanks = all, >> -- Mike >> =20 >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf Of William Mills >> Sent: Tuesday, June 12, 2012 11:18 AM >> To: Hannes Tschofenig; Julian Reschke >> Cc: oauth@ietf.org >> Subject: Re: [OAUTH-WG] Discussion needed on username and password = ABNF definitions >> =20 >> I agree generally with your assumption about clients, but rather than = saying "clients are devices" I think it makes much more sense to say = "clients are NOT users, so client_id need not be internationalized". In = practical terms there is very little to argue for anythign beyond ASCII = in a client_secret, base64 encoding or the equivalent being a fine way = to transport arbitrary bits in a portable/reasonable way. >> =20 >> I argue that client_id need not be internationalized because I assume = that any really internationalized application will have an = internationalized presentation layer that's presenting a pretty name for = the client_id. >> =20 >> -bill >> =20 >> From: Hannes Tschofenig >> To: Julian Reschke =20 >> Cc: "oauth@ietf.org" =20 >> Sent: Tuesday, June 12, 2012 11:01 AM >> Subject: Re: [OAUTH-WG] Discussion needed on username and password = ABNF definitions >>=20 >> I had a chat with Julian yesterday and here is my short summary.=20 >>=20 >> Section 2.3 of the core draft defines client authentication based on = two mechanisms (and provides room for = extensions):http://tools.ietf.org/html/draft-ietf-oauth-v2-27#section-2.3 >>=20 >> 1) HTTP Basic Authentication >>=20 >> 2) A custom OAuth authentication mechanism (which uses client_id and = client_secret) >>=20 >> With HTTP Basic authentication the problem is that this is a legacy = technology and there is no internationalization support.=20 >>=20 >> With our brand new custom OAuth authentication mechanism we have more = options.=20 >>=20 >> One possible approach is to say that the clients are devices (and not = end users) and therefore internationalization does not matter.=20 >>=20 >> Is it, however, really true that only US-ASCII characters will appear = in the client_id and also in the client_secret?=20 >>=20 >> Here we have the possibility to define something better.=20 >>=20 >> In any case we have to restrict the characters that are used in these = two authentication mechanisms since they could conflict with the way how = we transport the data over the underlying protocol. Julian mentioned = this in his previous mails.=20 >>=20 >> Julian, maybe you can provide a detailed text proposal for how to = address your comment in case we go for UTF8 (with % encoding) for the = custom OAuth client authentication mechanism?=20 >>=20 >> Ciao >> Hannes >>=20 >> On Jun 12, 2012, at 11:54 AM, Julian Reschke wrote: >>=20 >> > On 2012-06-12 00:16, Mike Jones wrote: >> >> Reviewing the feedback from Julian, John, and James, I'm coming to = the conclusion that client_id and client_secret, being for machines and = not humans, should be ASCII, whereas username and password should be = Unicode, since they are for humans. Per John's feedback, client_id can = not contain a colon and be compatible with HTTP Basic. >> >=20 >> > I'm not sure that restricting the character repertoire just because = one way to send requires this is the right approach. My preference would = be not to put this into the ABNF, and just to point out that certain = characters will not work over certain transports, and to just advise to = avoid them. >> >=20 >> >> Therefore, I'd like to propose these updated ABNF definitions: >> >>=20 >> >> VSCHAR =3D %20-7E >> >> NOCOLONVSCHAR =3D %x20-39 / %x3B-7E >> >> UNICODENOCTRLCHAR =3D >> >>=20 >> >> client-id =3D *NOCOLONVSCHAR >> >> client_secret =3D *VSCHAR >> >>=20 >> >> username =3D *UNICODENOCTRLCHAR >> >> password =3D *UNICODENOCTRLCHAR >> >=20 >> > In this case you should add an introductory statement pointing out = that the ABNF defines the grammar in terms of Unicode code points, not = octets (as it is the case most of the time). >> >=20 >> >> It turns out that non-ASCII characters are OK for username and = password because the Core spec only passes them in the form body - not = using HTTP Basic - and UTF-8 encoding is specified. >> >=20 >> > I'll send a separate mail about that, the current text in the spec = is way too unspecific. >> >=20 >> >> -- Mike >> >>=20 >> >> P.S. If anyone has a better ABNF for UNICODENOCTRLCHAR than "", please send it to me! >> >=20 >> > As noted before, here's an example: = >> >=20 >> > Best regards, Julian >> > _______________________________________________ >> > OAuth mailing list >> > OAuth@ietf.org >> > https://www.ietf.org/mailman/listinfo/oauth >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> =20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 > This message and any attachment are intended solely for the addressee = and may contain confidential information. If you have received this = message in error, please send it back to me, and immediately delete it. = Please do not use, copy or disclose the information contained in this = message or in any attachment. Any views or opinions expressed by the = author of this email do not necessarily reflect the views of the = University of Nottingham. >=20 > This message has been checked for viruses but the contents of an = attachment may still contain software viruses which could damage your = computer system: you are advised to perform your own checks. Email = communications with the University of Nottingham may be monitored as = permitted by UK legislation. >=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=_1D4BE40A-F1B7-4C63-8229-1C76A6FFA8BE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 http://tools= .ietf.org/html/draft-oauth-dyn-reg-v1-03

= Eve

On 12 Jun 2012, at 1:39 PM, Jianhua Shao = wrote:

Hello,

Dynamic client = registration is very useful if client or resource or authorisation = server is not permanently available. 
A typical case is = that is the resource or authorisation server is in mobile platform, the = connection is not always available. 
Another typical case = is that authorisation server do not necessary to have client = pre-registered on itself. At moment, industry like facebook would like = developer to register a app on its app centre first, and then ask user = auth to use the app. 

We are researchers = from Digital Economy Research Institute. We have this problem When we = developing Dataware that could manage the control of access to personal = data. We play around our solution base on Oauth2: https://gith= ub.com/jianhuashao/dataware.catalog/wiki

We = are in the list to receive your maillist, but currently need moderate to = post any message. cc my colleague, Richard = Mortier
Best
Jian


On= 12 Jun 2012, at 21:08, Eran Hammer wrote:

The = only distinction I would make is between removing flexibiliy to = proactively enabling future extensibility. I would stop short of = perscribing encoding in order to fit uri into the Basic auth fields. But = if there is a way to allow this to be less restrictive without clean = interop issues, that would be nice.
I do = agree we need some actual use cases before we spend much more time on = this.
 William = Mills [mailto:wmills@yahoo-inc.com] 
Sent: Tuesday, June 12, 2012 1:04 = PM
To: Eran = Hammer; Mike Jones; Hannes Tschofenig; Julian Reschke
Cc: oauth@ietf.org
Subject: Dynamic clients, URI, and = stuff Re: [OAUTH-WG] Discussion needed on username and password ABNF = definitions
I = think dynamic client registration is something we have not talked out = enough yet.  There's a pretty clear use case for dynamic = registration.  
Does identifying the client with a URI allow some form = of OpenID-ish flow for = this? 
Is the client ID as a URI a way to allow a trusted site = to provide metadata about the = client?
Is = that URI a way to hit an IDP we trust to validate the client in some way = with the provided secret?
I guess what I'm looking for here is a concrete use = case/problem to solve, rather then leaving a hook we think is the right = thing.
-bill
Is the use case of = using URI as client ids important? It seems like something that might = become useful in the future where clients can use their verifiable = servers to bypass client registration and simly use a URI the server can = validate via some other means. 
I just want to make sure those thinking about more = complex use cases involving dynamic registration or distributed client = manamgenet are aware of this potential restriction.
 I'm fine either = way. 
EH 
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Mike = Jones
Sent: Tuesday, June 12, 2012 = 11:27 AM
To: William Mills; Hannes = Tschofenig; Julian Reschke
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Discussion = needed on username and password ABNF definitionsNot = internationalizing fields intended for machine consumption only is = already a precedent set and agreed to by the working group, so let me = second Bill=92s point in that regard.  For instance, neither = =93scope=94 nor =93error=94 allow non-ASCII characters.
 Julian, if you want = different ABNF text than the text I wrote below, I believe it would be = most useful if you would provide the exact replace wording that you=92d = like to see instead of it.  Then there=92s no possibility of = misunderstanding the intent of suggested changes.
  
 oauth-bounces@ietf.org  On Behalf Of William = Mills
Sent: Tuesday, June 12, 2012 = 11:18 AM
To: Hannes Tschofenig; Julian = Reschke
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Discussion = needed on username and password ABNF definitionsI argue that = client_id need not be internationalized because I assume that any really = internationalized application will have an internationalized = presentation layer that's presenting a pretty name for the = client_id.
From: Hannes Tschofenig < Julian Reschke <julian.reschke@gmx.de> 
Cc: "oauth@ietf.org" <oauth@ietf.org> 
Sent: Tuesday, June 12, 2012 = 11:01 AM
Subject: Re: [OAUTH-WG] Discussion = needed on username and password ABNF definitions

I had a chat with Julian yesterday and here is my short = summary. 

Section= 2.3 of the core draft defines client authentication based on two = mechanisms (and provides room for extensions): 

With our brand new = custom OAuth authentication mechanism we have more options. 

One possible = approach is to say that the clients are devices (and not end users) and = therefore internationalization does not matter. 

Is it, however, = really true that only US-ASCII characters will appear in the client_id = and also in the client_secret? 

Here we have the = possibility to define something better. 

In any case we have = to restrict the characters that are used in these two authentication = mechanisms since they could conflict with the way how we transport the = data over the underlying protocol. Julian mentioned this in his previous = mails. 

Julian, = maybe you can provide a detailed text proposal for how to address your = comment in case we go for UTF8 (with % encoding) for the custom OAuth = client authentication mechanism? 

Ciao
Hannes
On Jun 12, 2012, at 11:54 AM, Julian Reschke wrote:

> On = 2012-06-12 00:16, Mike Jones wrote:
>> Reviewing the feedback = from Julian, John, and James, I'm coming to the conclusion that = client_id and client_secret, being for machines and not humans, should = be ASCII, whereas username and password should be Unicode, since they = are for humans.  Per John's feedback, client_id can not contain a = colon and be compatible with HTTP Basic.
> 
> I'm not sure that = restricting the character repertoire just because one way to send = requires this is the right approach. My preference would be not to put = this into the ABNF, and just to point out that certain characters will = not work over certain transports, and to just advise to avoid = them.
> 
>> Therefore, I'd = like to propose these updated ABNF definitions:
>> 
>>    = VSCHAR =3D %20-7E
>>    NOCOLONVSCHAR =3D %x20-39 / = %x3B-7E
>>    UNICODENOCTRLCHAR =3D <Any Unicode = character other than ( %x0-1F / %x7F )>
>> 
>>    = client-id =3D *NOCOLONVSCHAR
>>    client_secret =3D = *VSCHAR
>> 
>>    = username =3D *UNICODENOCTRLCHAR
>>    password =3D = *UNICODENOCTRLCHAR
> 
> In this case you = should add an introductory statement pointing out that the ABNF defines = the grammar in terms of Unicode code points, not octets (as it is the = case most of the time).
> 
>> It turns out = that non-ASCII characters are OK for username and password because the = Core spec only passes them in the form body - not using HTTP Basic - and = UTF-8 encoding is specified.
> 
> I'll send a = separate mail about that, the current text in the spec is way too = unspecific.
> 
>> =             =     -- Mike
>> 
>> P.S.  If = anyone has a better ABNF for UNICODENOCTRLCHAR than "<Any Unicode = character other than ( %x0-1F / %x7F )>", please send it to = me!
> 
> = As noted before, here's an example: < 
> Best = regards, Julian
> = _______________________________________________
> OAuth mailing = list
> OAuth@ietf.org
> OAuth@ietf.org
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth


This message and any attachment are intended solely for the addressee = and may=20 contain confidential information. If you have received this message in = error,=20 please send it back to me, and immediately delete it. Please do not = use,=20 copy or disclose the information contained in this message or in any = attachment. =20 Any views or opinions expressed by the author of this email do not = necessarily=20 reflect the views of the University of Nottingham.

This message has been checked for viruses but the contents of an = attachment may still contain software viruses which could damage your computer = system: you are advised to perform your own checks. Email communications with = the University of Nottingham may be monitored as permitted by UK = legislation.

_______________________________________________
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=_1D4BE40A-F1B7-4C63-8229-1C76A6FFA8BE-- From eran@hueniverse.com Wed Jun 13 11:47:05 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0766C11E80B2; Wed, 13 Jun 2012 11:47:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5JfZ2158QWAH; Wed, 13 Jun 2012 11:47:04 -0700 (PDT) Received: from p3plex2out03.prod.phx3.secureserver.net (p3plex2out03.prod.phx3.secureserver.net [184.168.131.16]) by ietfa.amsl.com (Postfix) with ESMTP id 6796911E80B4; Wed, 13 Jun 2012 11:47:04 -0700 (PDT) Received: from P3PWEX2HT001.ex2.secureserver.net ([184.168.131.9]) by p3plex2out03.prod.phx3.secureserver.net with bizsmtp id Mun41j0010CJzpC01un4go; Wed, 13 Jun 2012 11:47:04 -0700 Received: from P3PWEX2MB008.ex2.secureserver.net ([169.254.8.66]) by P3PWEX2HT001.ex2.secureserver.net ([184.168.131.9]) with mapi id 14.02.0247.003; Wed, 13 Jun 2012 11:47:03 -0700 From: Eran Hammer To: William Mills , O Auth WG , "Apps Discuss" Thread-Topic: [OAUTH-WG] OAuth discovery registration. Thread-Index: AQHNSXkSEZ9PqH6dREydEyx3GFnsppb4aOvAgAChGoD//4zaMA== Date: Wed, 13 Jun 2012 18:47:02 +0000 Message-ID: <0CBAEB56DDB3A140BA8E8C124C04ECA201070937@P3PWEX2MB008.ex2.secureserver.net> References: <1339601256.43890.YahooMailNeo@web31803.mail.mud.yahoo.com> <0CBAEB56DDB3A140BA8E8C124C04ECA201070221@P3PWEX2MB008.ex2.secureserver.net> <1339612745.81200.YahooMailNeo@web31808.mail.mud.yahoo.com> In-Reply-To: <1339612745.81200.YahooMailNeo@web31808.mail.mud.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.163.44.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] OAuth discovery registration. X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 18:47:05 -0000 Probably, unless you focus the document on using these with host-meta. Also= , LRDD is itself just a link relation type so using that instead of host-me= ta is probably more confusing than helpful. I would just register the link = relations to be used with future OAuth discovery via links and give host-me= ta as one example, and maybe Link headers in a 401 response as another exam= ple. EH > -----Original Message----- > From: William Mills [mailto:wmills@yahoo-inc.com] > Sent: Wednesday, June 13, 2012 11:39 AM > To: Eran Hammer; O Auth WG; Apps Discuss > Subject: Re: [OAUTH-WG] OAuth discovery registration. >=20 > Worthwhile to change the document title? >=20 > Examples are easy, can do. >=20 >=20 >=20 > ----- Original Message ----- > > From: Eran Hammer > > To: William Mills ; O Auth WG ; > > Apps Discuss > > Cc: > > Sent: Wednesday, June 13, 2012 9:03 AM > > Subject: RE: [OAUTH-WG] OAuth discovery registration. > > > >T hese are straight link relation registrations, not LRDD (which has no > >registration process). It is helpful to put these registrations in > >context and use LRDD/host-meta as an example of their use, but the > >actual registration request is simply for a link relation and nothing e= lse. > > > > EH > > > >> -----Original Message----- > >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > >> Behalf Of William Mills > >> Sent: Wednesday, June 13, 2012 8:28 AM > >> To: O Auth WG; Apps Discuss > >> Subject: [OAUTH-WG] OAuth discovery registration. > >> > >> > >> > >> Since for the OAUTH SASL mechanism I need discovery for clients to > >> work, and I had to rip the in-band discovery out of that mechanism, > >> and I need it defined somewhere, I've drafted a small doc for the > >> registration of > > link > >> relation types for OAuth.=A0 It's too late in the process to get this > > into the core > >> OAuth 2 spec, and it doesn't really fit in the WebFinger. Submission > > info > >> provided below. > >> > >> -bill > >> > >> ---------------------------------------------------- > >> > >> A new version of I-D, draft-wmills-oauth-lrdd-00.txt has been > >> successfully submitted by William Mills and posted to the IETF reposi= tory. > >> > >> Filename:=A0=A0=A0 draft-wmills-oauth-lrdd > >> Revision:=A0=A0=A0 00 > >> Title:=A0=A0=A0 =A0=A0=A0 LRDD Registry for OAuth 2 Creation date: > >> 2012-06-13 WG ID:=A0=A0=A0 =A0=A0=A0 Individual Submission Number of= pages: 10 > >> URL: > > =A0=A0http://www.ietf.org/internet-drafts/draft-wmills-oauth-lrdd- > >> 00.txt > >> Status: > >> http://datatracker.ietf.org/doc/draft-wmills-oauth-lrdd > >> Htmlized:=A0 =A0 =A0 =A0=A0http://tools.ietf.org/html/submission.file= name > >> }}-00 > >> > >> > >> Abstract: > >> =A0 Defines link type registrations for the OAuth 2 authentication > >> =A0 framework. > >> > >> > >> > >> > >> The IETF Secretariat > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > > From wmills@yahoo-inc.com Wed Jun 13 11:59:08 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BE9421F8517 for ; Wed, 13 Jun 2012 11:59:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.086 X-Spam-Level: X-Spam-Status: No, score=-17.086 tagged_above=-999 required=5 tests=[AWL=-0.293, BAYES_00=-2.599, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P3Dm8QGwcrxT for ; Wed, 13 Jun 2012 11:59:07 -0700 (PDT) Received: from nm13-vm4.bullet.mail.ne1.yahoo.com (nm13-vm4.bullet.mail.ne1.yahoo.com [98.138.91.173]) by ietfa.amsl.com (Postfix) with SMTP id D39A721F84E6 for ; Wed, 13 Jun 2012 11:59:06 -0700 (PDT) Received: from [98.138.90.49] by nm13.bullet.mail.ne1.yahoo.com with NNFMP; 13 Jun 2012 18:59:06 -0000 Received: from [98.138.89.173] by tm2.bullet.mail.ne1.yahoo.com with NNFMP; 13 Jun 2012 18:59:06 -0000 Received: from [127.0.0.1] by omp1029.mail.ne1.yahoo.com with NNFMP; 13 Jun 2012 18:59:06 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 403231.1278.bm@omp1029.mail.ne1.yahoo.com Received: (qmail 47041 invoked by uid 60001); 13 Jun 2012 18:59:05 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1339613945; bh=0pHAAd8Hixq273DSXR0MwxqXLtSRu1gnn2x7Qdm+l8A=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=i5jhNCorHRTu8qcoDGkZeiUKZ01liHrBlUmQxtZ5gTDrPZ6MD6ZSzm0q1bYtvL9CjJmSev7O17uz4SKpjFEfJy2Rh2jiZJde/TZS/WIA0eOH8DrOqnbt0ljxU5g3FzQY0ngMugSp0/qqOWL37+Fw6DV1ioLSUPqloN7hfao4Haw= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=cTZHIZKWVcNQV0hEGl27mxO4ulJiUnaOfs5G4EmqeQt5rB44tDlrdPW6f1XW+EMADZyLtqwoePykPYJ1wR4FVFv7Dtp4SAe9cwV5x06aSqTmHspPBqppxs3zXUB8GZ1byi35UNNPgfpCh1pSmEXQHCyl/8mrLzv+Bbw4kVkEODs=; X-YMail-OSG: uxAC5C8VM1l3d2zx9npU.jqZTxsT6r8E.fPJeOzfDLIk4Yz 3W8I0fMz9QQma.O5i8GBqerEqtoiy3G5lXYg0gczogAmJSABAYDMY9ArP2yG UFlRmYypQA53HkKqtqovGSq38dvzeys7DO04MoEWahcTuoAOX9dp_giN5uJd a_OBWzerHjTwo5PpnZkp982x6eTt_2wB15kXug8cT7pCEvTCjsuag4hHkNuv VJF36BgcLVD4AewlguJopVX51zJQh9T2DROpat4k.GAaeqXy6REjqKYgYRuN aDUhRPtmJ5eCn5rgGZGzCckEsucBVvcFc3OrnwJrO21bnr3tXqD8X36aPo5g UwuAqeNves3zOAmUzh2uXVxwdb6TNDbWu0gKHlEqA9dOiqz66W6KUMartGt3 WJtjX.l9_YR1eciGHMYalWWYF5t1Hq29QI4.EaDLYDjBpkCp1CbRyI7cYxXM kzBYebJnhKXlPCO5A93zSHvTBQLFgJZXxOELCRf6JutkypAT3lhkCFK9Y9L3 A9dLn1vykGK9LKauiAMfEL2c5fOB9IN3iRzUKFxYyOl6lLWzMRrfKhKdkkg4 ztE9m.vZvwtXaFpZvxONy83163aNugFloyR7TYlgLbAMin0HKyTsODzY.BNl YYBUwbdrG7ghYkrZtO7cO1VaN2KPChEm1hQ-- Received: from [209.131.62.115] by web31813.mail.mud.yahoo.com via HTTP; Wed, 13 Jun 2012 11:59:05 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.120.356233 References: <1339601256.43890.YahooMailNeo@web31803.mail.mud.yahoo.com> <4FD8B646.3080509@stpeter.im> <1339611594.26607.YahooMailNeo@web31806.mail.mud.yahoo.com> Message-ID: <1339613945.46084.YahooMailNeo@web31813.mail.mud.yahoo.com> Date: Wed, 13 Jun 2012 11:59:05 -0700 (PDT) From: William Mills To: Eve Maler In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Apps Discuss , Goix Laurent Walter , O Auth WG Subject: Re: [OAUTH-WG] [apps-discuss] OAuth discovery registration. X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 18:59:08 -0000 We certainly overlap, the thing you have that is not in the link type regis= trations is dynamic_client_registration_supported.=A0 We should be consiste= nt in naming, and ideally the OAuth related JSON elements from a JSON forma= t Webfinger request and your UMA stuff shoudl be identical.=A0 My concern w= ith using a JSON list structure for capability lists is how it would play i= n the LINK header itself, that seems a bit hairy to put a JSON list inside = a quoted application data value.=0A=0ADo we want something like a "capabili= ties" list which could include dynamic_client_registration_supported and pe= rhaps others?=0A=0A-bill=0A=0A=0A=0A=0A----- Original Message -----=0A> Fro= m: Eve Maler =0A> To: William Mills = =0A> Cc: Goix Laurent Walter ; Peter S= aint-Andre ; O Auth WG ; Apps Discuss <= apps-discuss@ietf.org>=0A> Sent: Wednesday, June 13, 2012 11:38 AM=0A> Subj= ect: Re: [OAUTH-WG] [apps-discuss] OAuth discovery registration.=0A> =0A> = Hi Bill-- In incorporating OAuth into several of the UMA flows, we found a = need =0A> for the authorization server to provide OAuth-related metadata al= ong with =0A> UMA-specific metadata. Originally it was strictly XRD- and ho= stmeta-based, but =0A> now uses a JSON format and is more akin to OpenID Co= nnect's metadata in =0A> style: =0A> =0A> http://docs.kantarainitiative.org= /uma/draft-uma-core.html#am-endpoints=0A> =0A> Do you feel that this new dr= aft is something that ultimately *should* replace =0A> the OAuth-specific p= arts of the metadata we've spec'd out for our use =0A> case? Note that we w= ent beyond just the two endpoints, also covering a feature =0A> toggle for = "dynamic_client_registration_supported" and lists of =0A> "oauth_token_prof= iles_supported" and =0A> "oauth_grant_types_supported". The purpose in doin= g this was to =0A> provide a machine-readable mechanism for aiding OAuth-le= vel interop.=0A> =0A> Thanks,=0A> =0A> =A0=A0=A0 Eve=0A> =0A> On 13 Jun 201= 2, at 11:19 AM, William Mills wrote:=0A> =0A>> On the informational status= , that seemed right, but I honestly don't =0A> know what the correct choice= is here.=A0 The actual registration happens via =0A> e-mail I believe, no= t via this document.=0A>> =0A>> Thanks for the feedback!=0A>> =0A>> -bill= =0A>> =0A>> =0A>> =0A>> ----- Original Message -----=0A>>> From: Goix Lau= rent Walter =0A>>> To: Peter Saint-An= dre ; William Mills =0A> =0A>>> = Cc: O Auth WG ; Apps Discuss =0A> = =0A>>> Sent: Wednesday, June 13, 2012 9:44 AM=0A>>> Subject: R: [apps-dis= cuss] [OAUTH-WG] OAuth discovery registration.=0A>>> =0A>>> T hank you Wil= liam for this initiative.=0A>>> =0A>>> I had similar concerns than Peter o= n authn vs authz.=0A>>> =0A>>> Under section 4.1.1 I would suggest to use = "oauth2-authorize" =0A> instead =0A>>> of "oauth2-authenticator", to be co= nsistent with the =0A>>> "oauth2-token" pattern and with the concepts of t= he oauth2 =0A> draft.=0A>>> =0A>>> The header of the pages still reference= sasl/gss-api and would need to =0A> be =0A>>> updated.=0A>>> =0A>>> Also= , an example and/or use case section could be beneficial, e.g. to =0A> desc= ribe =0A>>> its usage in an xrd document. Other use cases may be mentioned= as well =0A> probably.=0A>>> =0A>>> I have also noticed that your draft i= s mentioned as =0A> "informational". =0A>>> It is indeed your target or on= ly a typo?=0A>>> =0A>>> Thanks=0A>>> walter=0A>>> =0A>>>> -----Messaggio= originale-----=0A>>>> Da: apps-discuss-bounces@ietf.org =0A> [mailto:apps= -discuss-bounces@ietf.org] =0A>>> Per=0A>>>> conto di Peter Saint-Andre= =0A>>>> Inviato: mercoled=EC 13 giugno 2012 17.48=0A>>>> A: William Mills= =0A>>>> Cc: O Auth WG; Apps Discuss=0A>>>> Oggetto: Re: [apps-discuss] [O= AUTH-WG] OAuth discovery =0A> registration.=0A>>>> =0A>>>> On 6/13/12 9:27= AM, William Mills wrote:=0A>>>>> =0A>>>>> Since for the OAUTH SASL mechan= ism I need discovery for clients =0A> to=0A>>>>> work, and I had to rip th= e in-band discovery out of that =0A> mechanism,=0A>>>>> and I need it defi= ned somewhere, I've drafted a small doc =0A> for the=0A>>>>> registration = of link relation types for OAuth.=A0 It's too =0A> late in =0A>>> the=0A>>= >>> process to get this into the core OAuth 2 spec, and it =0A> doesn't = =0A>>> really=0A>>>>> fit in the WebFinger. Submission info provided belo= w.=0A>>>> =0A>>>> Hi Bill, overall this looks good. A few nits:=0A>>>> =0A= >>>> OLD=0A>>>> =A0 =A0 This document defines the LRDD [RFC5988] link typ= e =0A> registrations for=0A>>>> =A0 =A0 the OAuth [I-D.ietf-oauth-v2] auth= entication framework.=A0 These =0A> link=0A>>>> =A0 =A0 types are used dur= ing the endpoint discovery process using Web =0A> Host=0A>>>> =A0 =A0 Meta= data [I-D.hammer-hostmeta] and Webfinger=0A>>>> =A0 =A0 [I-D.jones-appsawg= -webfinger] by clients needing to discover =0A> the=0A>>>> =A0 =A0 authent= ication endpoints for a service or site.=A0 It =0A> additionally=0A>>>> =A0= =A0 defines link type registrations for OAuth 1.0a [RFC5849].=0A>>>> =0A>= >>> NEW=0A>>>> =A0 =A0 This document defines the Link-based Resource Desc= riptor=0A>>>> =A0 =A0 Documents (LRDD) [RFC6415] link type registrations f= or the=0A>>>> =A0 =A0 OAuth [I-D.ietf-oauth-v2] authorization framework.= =A0 These link=0A>>>> =A0 =A0 types are used during the endpoint discovery= process using Web=0A>>>> =A0 =A0 Host Metadata [RFC6415] and Webfinger=0A= >>>> =A0 =A0 [I-D.jones-appsawg-webfinger] by clients needing to discover = =0A> the=0A>>>> =A0 =A0 authorization, token, and access token endpoints f= or an OAuth2=0A>>>> =A0 =A0 service or site.=A0 It additionally defines li= nk type =0A> registrations for=0A>>>> OAuth=0A>>>> =A0 =A0 1.0a [RFC5849]= request initiation endpoints, authorization =0A> endpoints,=0A>>>> =A0 =A0= and token endpoints.=0A>>>> =0A>>>> In Section 4.1.1, you register an "O= Auth 2 Authentication =0A>>> Endpoint",=0A>>>> however draft-ietf-oauth-v= 2 defines only an authorization endpoint, =0A> a=0A>>>> token endpoint, an= d an access token endpoint. Whence this=0A>>>> "authentication endpoint"? = Is it just a typo?=0A>>>> =0A>>>> Also, is the lack of a link type for OAu= th2 access token endpoints =0A> an=0A>>>> oversight? It seems so.=0A>>>> = =0A>>>> You have "Reference: [[this document]]" but I think you =0A> want:= =0A>>>> =0A>>>> Reference: draft-ietf-oauth-v2=0A>>>> =0A>>>> and=0A>>>> = =0A>>>> Reference: RFC 5849=0A>>>> =0A>>>> You can remove the reference f= or draft-hammer-hostmeta (RFC 6415 =0A> has=0A>>>> what you need).=0A>>>> = =0A>>>> Peter=0A>>>> =0A>>>> --=0A>>>> Peter Saint-Andre=0A>>>> https:/= /stpeter.im/=0A>>>> =0A>>>> =0A>>>> =0A>>>> =0A>>>> ______________________= _________________________=0A>>>> apps-discuss mailing list=0A>>>> apps-di= scuss@ietf.org=0A>>>> https://www.ietf.org/mailman/listinfo/apps-discuss= =0A>>> =0A>>> Questo messaggio e i suoi allegati sono indirizzati esclusiv= amente alle =0A> persone =0A>>> indicate. La diffusione, copia o qualsiasi= altra azione derivante dalla =0A> =0A>>> conoscenza di queste informazion= i sono rigorosamente vietate. Qualora =0A> abbiate =0A>>> ricevuto questo = documento per errore siete cortesemente pregati di =0A> darne =0A>>> immed= iata comunicazione al mittente e di provvedere alla sua =0A> distruzione, = =0A>>> Grazie.=0A>>> =0A>>> This e-mail and any attachments is confidenti= al and may contain =0A> privileged =0A>>> information intended for the add= ressee(s) only. Dissemination, copying, =0A> printing =0A>>> or use by any= body else is unauthorised. If you are not the intended =0A> recipient, =0A>= >> please delete this message and any attachments and advise the sender by= =0A> return =0A>>> e-mail, Thanks.=0A>>> =0A>> _________________________= ______________________=0A>> OAuth mailing list=0A>> OAuth@ietf.org=0A>> = https://www.ietf.org/mailman/listinfo/oauth=0A>> =0A> =0A> =0A> Eve Maler= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 http://= www.xmlgrrl.com/blog=0A> +1 425 345 6756=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 http://www.twitter.com/xmlgrrl=0A> From wmills@yahoo-inc.com Wed Jun 13 13:05:13 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B137D21F85C3 for ; Wed, 13 Jun 2012 13:05:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.465 X-Spam-Level: X-Spam-Status: No, score=-17.465 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iFK4gRRaDEhh for ; Wed, 13 Jun 2012 13:05:12 -0700 (PDT) Received: from nm20-vm0.bullet.mail.bf1.yahoo.com (nm20-vm0.bullet.mail.bf1.yahoo.com [98.139.213.165]) by ietfa.amsl.com (Postfix) with SMTP id 9055821F85C2 for ; Wed, 13 Jun 2012 13:05:12 -0700 (PDT) Received: from [98.139.212.152] by nm20.bullet.mail.bf1.yahoo.com with NNFMP; 13 Jun 2012 20:05:11 -0000 Received: from [98.139.212.250] by tm9.bullet.mail.bf1.yahoo.com with NNFMP; 13 Jun 2012 20:05:11 -0000 Received: from [127.0.0.1] by omp1059.mail.bf1.yahoo.com with NNFMP; 13 Jun 2012 20:05:11 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 796089.27824.bm@omp1059.mail.bf1.yahoo.com Received: (qmail 560 invoked by uid 60001); 13 Jun 2012 20:05:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1339617910; bh=cF94E/L3e1ce9glpPSEt1vwJbfQxwJi7IKNXJSu13ZA=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Sa0e00zI7F8kD+3LdkA9FaccTwTBksT8S8xu6BchjAsT5ADoWuFFae1xX1HmkAD0tq0bjdzzE5xy4XSxXf/NYXnFbyq8/fc96Uwb+mjZP6xadTLahxHCuvUMZ7W0oZj/EL6SNob+mS/plNRDeisBcXOEaQBivDBHROiS8sezaos= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=JAd0wcP6GhIZYlzlDmWYl1+wbL/m7eyJtJAXIJQcKyXaLq85H0V9LNTjor0mideoZs/3pCHuRpXyZ8qWjICggh0zN66nsJsLXvzrIfGHGUT8rgOd8KbmmGXU/lnklyg/MnPJHyrrC4dvo+9SYQChZNb/zJSn2CK2P/kAuabsRvo=; X-YMail-OSG: wo5rXsAVM1l9ylwTlK8e3PvASBVrGfE22o.21xF6izlUAdy O4Wusbc.e3yH4KVNj2Syr_0Ia.Cqm3V.X331i6wIIMHv7w_TqfrrEEL9llZk MI22RfOOdYmZDzby3zwfCApI6f06uhozvIRV3ymWtTNk1WZDz3PxQYy4bOlB .IeuenbcLWTBp9JNQEths5INrL2uZ6LZEjppfym6ujPK4WbNbrJ5vXXo7e49 WlV2idGGogf1GsSGo.zIQmUAFNn4sZtlNd2dq8LGSR_Rt7JnVlAbdJhdFxq6 IqNBQnhVCXhDsegy9uRW54hibLZYzZg84revIjI4ZkWyCyfd5_fof2ZL3WMx 9n0SLoeaSfiYTf7R18aBD1pAkpr_ld124exjaIL.Bng7bLj7l6k1gKvrZX.v _D2RpcblQrUqkW.3eWw4oiqPQRrFodUoyHrXqMlvm8B2mBds0rGaPiZmnQmk QcPWj5NeOpvQSf5TNVHU93dvQHpExWiVBmymu8VLEA0f6 Received: from [209.131.62.115] by web31807.mail.mud.yahoo.com via HTTP; Wed, 13 Jun 2012 13:05:10 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.120.356233 References: <1339601256.43890.YahooMailNeo@web31803.mail.mud.yahoo.com> <4FD8B646.3080509@stpeter.im> Message-ID: <1339617910.72530.YahooMailNeo@web31807.mail.mud.yahoo.com> Date: Wed, 13 Jun 2012 13:05:10 -0700 (PDT) From: William Mills To: Apps Discuss , O Auth WG In-Reply-To: <4FD8B646.3080509@stpeter.im> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [OAUTH-WG] OAuth discovery registration. X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 20:05:13 -0000 I've incorporated a number of changes and added examples.=A0 Thanks to all = for the feedback.=A0 I can do a new draft any time if that's useful.=0A=0A-= bill=0A=0A=0A=0A----- Original Message -----=0A> From: Peter Saint-Andre =0A> To: William Mills =0A> Cc: O A= uth WG ; Apps Discuss =0A> Sent: Wed= nesday, June 13, 2012 8:48 AM=0A> Subject: Re: [OAUTH-WG] OAuth discovery r= egistration.=0A> =0A> On 6/13/12 9:27 AM, William Mills wrote:=0A>> =0A>> = Since for the OAUTH SASL mechanism I need discovery for clients to=0A>> wo= rk, and I had to rip the in-band discovery out of that mechanism,=0A>> and= I need it defined somewhere, I've drafted a small doc for the=0A>> regist= ration of link relation types for OAuth.=A0 It's too late in the=0A>> proc= ess to get this into the core OAuth 2 spec, and it doesn't really=0A>> fit= in the WebFinger. Submission info provided below.=0A> =0A> Hi Bill, overal= l this looks good. A few nits:=0A> =0A> OLD=0A> =A0 This document defines = the LRDD [RFC5988] link type registrations for=0A> =A0 the OAuth [I-D.ietf= -oauth-v2] authentication framework.=A0 These link=0A> =A0 types are used = during the endpoint discovery process using Web Host=0A> =A0 Metadata [I-D= .hammer-hostmeta] and Webfinger=0A> =A0 [I-D.jones-appsawg-webfinger] by c= lients needing to discover the=0A> =A0 authentication endpoints for a serv= ice or site.=A0 It additionally=0A> =A0 defines link type registrations fo= r OAuth 1.0a [RFC5849].=0A> =0A> NEW=0A> =A0 This document defines the Lin= k-based Resource Descriptor=0A> =A0 Documents (LRDD) [RFC6415] link type r= egistrations for the=0A> =A0 OAuth [I-D.ietf-oauth-v2] authorization frame= work.=A0 These link=0A> =A0 types are used during the endpoint discovery p= rocess using Web=0A> =A0 Host Metadata [RFC6415] and Webfinger=0A> =A0 [I= -D.jones-appsawg-webfinger] by clients needing to discover the=0A> =A0 aut= horization, token, and access token endpoints for an OAuth2=0A> =A0 servic= e or site.=A0 It additionally defines link type registrations for=0A> OAuth= =0A> =A0 1.0a [RFC5849] request initiation endpoints, authorization endpoi= nts,=0A> =A0 and token endpoints.=0A> =0A> In Section 4.1.1, you register = an "OAuth 2 Authentication Endpoint",=0A> however draft-ietf-oauth-v2 defin= es only an authorization endpoint, a=0A> token endpoint, and an access toke= n endpoint. Whence this=0A> "authentication endpoint"? Is it just a typo?= =0A> =0A> Also, is the lack of a link type for OAuth2 access token endpoint= s an=0A> oversight? It seems so.=0A> =0A> You have "Reference: [[this docum= ent]]" but I think you want:=0A> =0A> Reference: draft-ietf-oauth-v2=0A> = =0A> and=0A> =0A> Reference: RFC 5849=0A> =0A> You can remove the reference= for draft-hammer-hostmeta (RFC 6415 has=0A> what you need).=0A> =0A> Peter= =0A> =0A> -- =0A> Peter Saint-Andre=0A> https://stpeter.im/=0A> From psxjs4@nottingham.ac.uk Wed Jun 13 13:52:51 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E125011E8083 for ; Wed, 13 Jun 2012 13:52:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.195 X-Spam-Level: X-Spam-Status: No, score=-2.195 tagged_above=-999 required=5 tests=[AWL=-0.403, BAYES_00=-2.599, 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 51MqWiA2Fqj1 for ; Wed, 13 Jun 2012 13:52:47 -0700 (PDT) Received: from thb-mta-19.emailfiltering.com (thb-mta-19-tx.emailfiltering.com [194.116.199.150]) by ietfa.amsl.com (Postfix) with ESMTP id AD77921F853C for ; Wed, 13 Jun 2012 13:52:46 -0700 (PDT) Received: from smtp4.nottingham.ac.uk ([128.243.220.65]) by thb-mta-19.emailfiltering.com with emfmta (version 4.8.5.86) by TLS id 2464026718 ;92cbc3dbf6ba7d13; Wed, 13 Jun 2012 21:52:34 +0100 Received: from uiwexhub02.ad.nottingham.ac.uk ([128.243.15.132]) by smtp4.nottingham.ac.uk with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1SeuYL-000486-T1; Wed, 13 Jun 2012 21:52:33 +0100 Received: from EXCHANGE1.ad.nottingham.ac.uk ([fe80::7962:f868:e6ee:6267]) by UIWEXHUB02.ad.nottingham.ac.uk ([2002:80f3:f84::80f3:f84]) with mapi; Wed, 13 Jun 2012 21:52:17 +0100 From: Jianhua Shao To: Eve Maler Date: Wed, 13 Jun 2012 21:52:20 +0100 Thread-Topic: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion needed on username and password ABNF definitions Thread-Index: Ac1JpmsEABF+9FNSSJiHan/v9Dgazw== Message-ID: References: <4E1F6AAD24975D4BA5B16804296739436652F52D@TK5EX14MBXC284.redmond.corp.microsoft.com> <4FD4E9D4.2010808@gmx.de> <4E1F6AAD24975D4BA5B168042967394366531375@TK5EX14MBXC284.redmond.corp.microsoft.com> <4FD4F976.6090801@gmx.de> <4E1F6AAD24975D4BA5B1680429673943665316D1@TK5EX14MBXC284.redmond.corp.microsoft.com> <60F5CCB0-E036-4351-BD10-A44B33FCC5F6@ve7jtb.com> <255B9BB34FB7D647A506DC292726F6E114F5474E29@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B1680429673943665346D0@TK5EX14MBXC284.redmond.corp.microsoft.com> <4FD703C4.6050801@gmx.de> <5E38109E-2123-418B-8D45-B8DF4287790D@gmx.net> <1339525052.8121.YahooMailNeo@web31807.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B168042967394366535EAD@TK5EX14MBXC284.redmond.corp.microsoft.com> <0CBAEB56DDB3A140BA8E8C124C04ECA20106ED1F@P3PWEX2MB008.ex2.secureserver.net> <1339531450.39923.YahooMailNeo@web31809.mail.mud.yahoo.com> <0CBAEB56DDB3A140BA8E8C124C04ECA20106F052@P3PWEX2MB008.ex2.secureserver.net> <3CCE477A-673D-450A-A310-3C5F1A8002DE@xmlgrrl.com> In-Reply-To: <3CCE477A-673D-450A-A310-3C5F1A8002DE@xmlgrrl.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_B2E0806177EF408BBE6B045B35E30864exmailnottinghamacuk_" MIME-Version: 1.0 Cc: Julian Reschke , Richard Mortier , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion needed on username and password ABNF definitions X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 20:52:52 -0000 --_000_B2E0806177EF408BBE6B045B35E30864exmailnottinghamacuk_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, UMA-flavored sound quite close to our dataware.catalog design to solve = similar problem in dynamic auth and registration. I am interesting to know = how it would push to next stage as it expired on 26 April 2012. Currently OAuth 2 are one way registration and authentication, which is cli= ent register on authorisation server and also auth in the same direction. H= ave you think about the cases that either side can start the registration, = which is in additional that authorisation server wants client to register o= n it and give the permission to access to limited resources. We met this de= mand that if I heard a application is very useful by listening to my friend= , I would like to actively give permission to this application to start to = use it. A concrete example is from my real experience that when I travel to China, = I have use a search engine called Baidu.com, because I am= new to this search engine but I am using google as daily, so there is a ap= p could leave the port that could move any historical search data into baid= u.com, If I can actively give my permission of google sea= rch history data into that app, I would than have baidu.com to use in right way. If you think about many other cases in the life, it= is actually a very common demand. So have you think about this kind of dynamic registration/auth, and also ca= n enable either side to start the process? Just want to know where and how = to contribute to your existing work. Jian On 13 Jun 2012, at 19:42, Eve Maler wrote: Also please see the UMA-flavored use cases (there are two) and the summary = of requirements provided in this input document: http://tools.ietf.org/html/draft-oauth-dyn-reg-v1-03 Eve On 12 Jun 2012, at 1:39 PM, Jianhua Shao wrote: Hello, Dynamic client registration is very useful if client or resource or authori= sation server is not permanently available. A typical case is that is the resource or authorisation server is in mobile= platform, the connection is not always available. Another typical case is that authorisation server do not necessary to have = client pre-registered on itself. At moment, industry like facebook would li= ke developer to register a app on its app centre first, and then ask user a= uth to use the app. We are researchers from Digital Economy Research Institute. We have this pr= oblem When we developing Dataware that could manage the control of access t= o personal data. We play around our solution base on Oauth2: https://github= .com/jianhuashao/dataware.catalog/wiki We are in the list to receive your maillist, but currently need moderate to= post any message. cc my colleague, Richard Mortier Best Jian On 12 Jun 2012, at 21:08, Eran Hammer wrote: The only distinction I would make is between removing flexibiliy to proacti= vely enabling future extensibility. I would stop short of perscribing encod= ing in order to fit uri into the Basic auth fields. But if there is a way t= o allow this to be less restrictive without clean interop issues, that woul= d be nice. I do agree we need some actual use cases before we spend much more time on = this. EH From: William Mills [mailto:wmills@yahoo-inc.com] Sent: Tuesday, June 12, 2012 1:04 PM To: Eran Hammer; Mike Jones; Hannes Tschofenig; Julian Reschke Cc: oauth@ietf.org Subject: Dynamic clients, URI, and stuff Re: [OAUTH-WG] Discussion needed o= n username and password ABNF definitions I think dynamic client registration is something we have not talked out eno= ugh yet. There's a pretty clear use case for dynamic registration. Does identifying the client with a URI allow some form of OpenID-ish flow f= or this? Is the client ID as a URI a way to allow a trusted site to provide metadata= about the client? Is that URI a way to hit an IDP we trust to validate the client in some way= with the provided secret? I guess what I'm looking for here is a concrete use case/problem to solve, = rather then leaving a hook we think is the right thing. -bill ________________________________ From: Eran Hammer > To: Mike Jones >; William Mills >; H= annes Tschofenig >; Julian Reschke > Cc: "oauth@ietf.org" > Sent: Tuesday, June 12, 2012 11:39 AM Subject: RE: [OAUTH-WG] Discussion needed on username and password ABNF def= initions Is the use case of using URI as client ids important? It seems like somethi= ng that might become useful in the future where clients can use their verif= iable servers to bypass client registration and simly use a URI the server = can validate via some other means. I just want to make sure those thinking about more complex use cases involv= ing dynamic registration or distributed client manamgenet are aware of this= potential restriction. I'm fine either way. EH From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Mike = Jones Sent: Tuesday, June 12, 2012 11:27 AM To: William Mills; Hannes Tschofenig; Julian Reschke Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF def= initions Not internationalizing fields intended for machine consumption only is alre= ady a precedent set and agreed to by the working group, so let me second Bi= ll=92s point in that regard. For instance, neither =93scope=94 nor =93erro= r=94 allow non-ASCII characters. Julian, if you want different ABNF text than the text I wrote below, I beli= eve it would be most useful if you would provide the exact replace wording = that you=92d like to see instead of it. Then there=92s no possibility of m= isunderstanding the intent of suggested changes. Thanks all, -- Mike From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Willi= am Mills Sent: Tuesday, June 12, 2012 11:18 AM To: Hannes Tschofenig; Julian Reschke Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF def= initions I agree generally with your assumption about clients, but rather than sayin= g "clients are devices" I think it makes much more sense to say "clients ar= e NOT users, so client_id need not be internationalized". In practical ter= ms there is very little to argue for anythign beyond ASCII in a client_secr= et, base64 encoding or the equivalent being a fine way to transport arbitra= ry bits in a portable/reasonable way. I argue that client_id need not be internationalized because I assume that = any really internationalized application will have an internationalized pre= sentation layer that's presenting a pretty name for the client_id. -bill ________________________________ From: Hannes Tschofenig > To: Julian Reschke > Cc: "oauth@ietf.org" > Sent: Tuesday, June 12, 2012 11:01 AM Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF def= initions I had a chat with Julian yesterday and here is my short summary. Section 2.3 of the core draft defines client authentication based on two me= chanisms (and provides room for extensions):http://tools.ietf.org/html/draf= t-ietf-oauth-v2-27#section-2.3 1) HTTP Basic Authentication 2) A custom OAuth authentication mechanism (which uses client_id and client= _secret) With HTTP Basic authentication the problem is that this is a legacy technol= ogy and there is no internationalization support. With our brand new custom OAuth authentication mechanism we have more optio= ns. One possible approach is to say that the clients are devices (and not end u= sers) and therefore internationalization does not matter. Is it, however, really true that only US-ASCII characters will appear in th= e client_id and also in the client_secret? Here we have the possibility to define something better. In any case we have to restrict the characters that are used in these two a= uthentication mechanisms since they could conflict with the way how we tran= sport the data over the underlying protocol. Julian mentioned this in his p= revious mails. Julian, maybe you can provide a detailed text proposal for how to address y= our comment in case we go for UTF8 (with % encoding) for the custom OAuth c= lient authentication mechanism? Ciao Hannes On Jun 12, 2012, at 11:54 AM, Julian Reschke wrote: > On 2012-06-12 00:16, Mike Jones wrote: >> Reviewing the feedback from Julian, John, and James, I'm coming to the c= onclusion that client_id and client_secret, being for machines and not huma= ns, should be ASCII, whereas username and password should be Unicode, since= they are for humans. Per John's feedback, client_id can not contain a col= on and be compatible with HTTP Basic. > > I'm not sure that restricting the character repertoire just because one w= ay to send requires this is the right approach. My preference would be not = to put this into the ABNF, and just to point out that certain characters wi= ll not work over certain transports, and to just advise to avoid them. > >> Therefore, I'd like to propose these updated ABNF definitions: >> >> VSCHAR =3D %20-7E >> NOCOLONVSCHAR =3D %x20-39 / %x3B-7E >> UNICODENOCTRLCHAR =3D >> >> client-id =3D *NOCOLONVSCHAR >> client_secret =3D *VSCHAR >> >> username =3D *UNICODENOCTRLCHAR >> password =3D *UNICODENOCTRLCHAR > > In this case you should add an introductory statement pointing out that t= he ABNF defines the grammar in terms of Unicode code points, not octets (as= it is the case most of the time). > >> It turns out that non-ASCII characters are OK for username and password = because the Core spec only passes them in the form body - not using HTTP Ba= sic - and UTF-8 encoding is specified. > > I'll send a separate mail about that, the current text in the spec is way= too unspecific. > >> -- Mike >> >> P.S. If anyone has a better ABNF for UNICODENOCTRLCHAR than "", please send it to me! > > As noted before, here's an example: > > Best regards, Julian > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth This message and any attachment are intended solely for the addressee and m= ay contain confidential information. If you have received this message in e= rror, please send it back to me, and immediately delete it. Please do not u= se, copy or disclose the information contained in this message or in any at= tachment. Any views or opinions expressed by the author of this email do no= t necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment= may still contain software viruses which could damage your computer system= : you are advised to perform your own checks. Email communications with the= University of Nottingham may be monitored as permitted by UK legislation. _______________________________________________ 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 --_000_B2E0806177EF408BBE6B045B35E30864exmailnottinghamacuk_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi, UMA-flavored soun= d quite close to our dataware.catalog design to solve similar problem in dy= namic auth and registration. I am interesting to know how it would push to = next stage as it expired on 26 April 2012. 

C= urrently OAuth 2 are one way registration and authentication, which is clie= nt register on authorisation server and also auth in the same direction. Ha= ve you think about the cases that either side can start the registration, w= hich is in additional that authorisation server wants client to register on= it and give the permission to access to limited resources. We met this dem= and that if I heard a application is very useful by listening to my friend,= I would like to actively give permission to this application to start to u= se it. 

A concrete example is from my real ex= perience that when I travel to China, I have use a search engine called Baidu.com, because I am new to this search en= gine but I am using google as daily, so there is a app could leave the port= that could move any historical search data into baidu.com, If I can actively give my permission of google search his= tory data into that app, I would than have bai= du.com to use in right way. If you think about many other cases in the = life, it is actually a very common demand. 

S= o have you think about this kind of dynamic registration/auth, and also can= enable either side to start the process? Just want to know where and how t= o contribute to your existing work. 

Jian
On 13 Jun 2012, at 19:42, Eve Maler wrote:

Also please see the UMA-flavored use cases (there are two) = and the summary of requirements provided in this input document:
=
Eve

On 12 Jun 2012, at 1:39 PM, Jianhua Shao wrote:
Hello,
Dynamic client registration is very useful if client or resour= ce or authorisation server is not permanently available. 
A = typical case is that is the resource or authorisation server is in mobile p= latform, the connection is not always available. 
Another ty= pical case is that authorisation server do not necessary to have client pre= -registered on itself. At moment, industry like facebook would like develop= er to register a app on its app centre first, and then ask user auth to use= the app. 

We are researchers from Digital Ec= onomy Research Institute. We have this problem When we developing Dataware = that could manage the control of access to personal data. We play around ou= r solution base on Oauth2: https://github.com/jianhuashao/dataware.catalog/wiki<= /a>



On 12= Jun 2012, at 21:08, Eran Hammer wrote:

The only distinction I would make is between removing flexib= iliy to proactively enabling future extensibility. I would stop short of pe= rscribing encoding in order to fit uri into the Basic auth fields. But if t= here is a way to allow this to be less restrictive without clean interop is= sues, that would be nice.
&n= bsp;
I do agree we need some actual us= e cases before we spend much more time on this.
 
EH
 
From: William Mills [mailto:wmil= ls@yahoo-inc.com] 
= Sent: Tuesday, June 1= 2, 2012 1:04 PM
To: Eran Hammer; Mike Jones; Hannes Tschofenig; Julian Reschke
Cc: oauth@ietf.org
Subject: Dynamic clients, URI, and stuff Re: [OAUTH-WG] Dis= cussion needed on username and password ABNF definitions<= /div>
 
I think dynamic client registratio= n is something we have not talked out enough yet.  There's a pretty cl= ear use case for dynamic registration.  
<= /div>
<= span style=3D"font-size: 14pt; font-family: 'Courier New'; color: black; ">=  
Does identifying the client with a URI allow= some form of OpenID-ish flow for this? 
=
Is th= e client ID as a URI a way to allow a trusted site to provide metadata abou= t the client?
Is that URI a way to hit an IDP we tr= ust to validate the client in some way with the provided secret?=
 
I guess what I'm looking for h= ere is a concrete use case/problem to solve, rather then leaving a hook we = think is the right thing.
 <= /div>
-bill
 
&nbs= p;
From:<= /span> Eran Hamm= er <eran@hueniverse.com>
To: Mike Jones <Michael.Jones@microsoft.com>; William Mills <wmills@yahoo-inc.com>; Hannes Tschofenig <= hannes.tschofenig@gmx.net>; Julian Reschke <jul= ian.reschke@gmx.de> 
Cc: "oauth@ietf.org" <oauth@ietf.org> 
Sent: Tuesday, June 12, 2012 11:39 AM
Subject:=  RE: [OAUTH-WG] Discu= ssion needed on username and password ABNF definitions
&nb= sp;
Is the use case of using URI as client i= ds important? It seems like something that might become useful in the futur= e where clients can use their verifiable servers to bypass client registrat= ion and simly use a URI the server can validate via some other means.
 
I just want to make sure those thinking about more complex= use cases involving dynamic registration or distributed client manamgenet = are aware of this potential restriction. 
I'm fine eit= her way.
 
EH
 
 
Not internationalizing fie= lds intended for machine consumption only is already a precedent set and ag= reed to by the working group, so let me second Bill=92s point in that regar= d.  For instance, neither =93scope=94 nor =93error=94 allow non-ASCII = characters.
 
Julian, if you want different ABNF text t= han the text I wrote below, I believe it would be most useful if you would = provide the exact replace wording that you=92d like to see instead of it.&n= bsp; Then there=92s no possibility of misunderstanding the intent of sugges= ted changes.
<= /div>
<= span style=3D"font-size: 11pt; color: rgb(31, 73, 125); "> 
      &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;   Thanks all,=
&nb= sp;            =             &nb= sp;            =             &nb= sp;         -- Mike
 <= o:p>
From: oauth-bounces@ietf.org&= nbsp;[mailto:oauth-bou= nces@ietf.org] On = Behalf Of William Mil= ls
Sent: Tuesda= y, June 12, 2012 11:18 AM
To: Hannes Tschofenig; Julian Reschke
Cc: oauth@= ietf.org
Subject: = Re: [OAUTH-WG] Discussion needed on username and password ABNF defin= itions
<= /div>
 
I agree generally with you= r assumption about clients, but rather than saying "clients are devices" I = think it makes much more sense to say "clients are NOT users, so client_id = need not be internationalized".  In practical terms there is very litt= le to argue for anythign beyond ASCII in a client_secret, base64 encoding o= r the equivalent being a fine way to transport arbitrary bits in a portable= /reasonable way.
 =
I argue that client_id need not be i= nternationalized because I assume that any really internationalized applica= tion will have an internationalized presentation layer that's presenting a = pretty name for the client_id.
 
=
-bill
 <= span style=3D"color: black; ">
=
= From:=  Hannes Tschofenig <= hannes.tschofenig@gmx.net>
To: Julian Reschke < = ;
Cc: "<= a href=3D"mailto:oauth@ietf.org" target=3D"_blank" style=3D"color: blue; te= xt-decoration: underline; ">oauth@ietf.org" <oauth@ietf.org> 
Sent: Tues= day, June 12, 2012 11:01 AM
Subject: Re: [OAUTH-WG] Discussion needed on username and pass= word ABNF definitions
 

Section 2.3 of the co= re draft defines client authentication based on two mechanisms (and provide= s room for extensions):h= ttp://tools.ietf.org/html/draft-ietf-oauth-v2-27#section-2.3

1) = HTTP Basic Authentication

2) A custom OAuth authentication mechanism= (which uses client_id and client_secret)

With HTTP Basic authentica= tion the problem is that this is a legacy technology and there is no intern= ationalization support. <= br>
With our brand new custom OAuth authentication mechanism we have mor= e options. 

One po= ssible approach is to say that the clients are devices (and not end users) = and therefore internationalization does not matter. 

Is it, however, really true that only US= -ASCII characters will appear in the client_id and also in the client_secre= t? 

Here we have t= he possibility to define something better. 

In any case we have to restrict the characters th= at are used in these two authentication mechanisms since they could conflic= t with the way how we transport the data over the underlying protocol. Juli= an mentioned this in his previous mails. 

Julian, maybe you can provide a detailed text propo= sal for how to address your comment in case we go for UTF8 (with % encoding= ) for the custom OAuth client authentication mechanism? 

Ciao
Hannes

On Jun 12, 201= 2, at 11:54 AM, Julian Reschke wrote:

> On 2012-06-12 00:16, Mike= Jones wrote:
>> Reviewing the feedback from Julian, John, and Jam= es, I'm coming to the conclusion that client_id and client_secret, being fo= r machines and not humans, should be ASCII, whereas username and password s= hould be Unicode, since they are for humans.  Per John's feedback, cli= ent_id can not contain a colon and be compatible with HTTP Basic.
> 
> I'm not sure that= restricting the character repertoire just because one way to send requires= this is the right approach. My preference would be not to put this into th= e ABNF, and just to point out that certain characters will not work over ce= rtain transports, and to just advise to avoid them.
> 
>> Therefore, I'd like to prop= ose these updated ABNF definitions:
>> 
>>    VSCHAR =3D %20-7E
>&= gt;    NOCOLONVSCHAR =3D %x20-39 / %x3B-7E
>>  &nbs= p; UNICODENOCTRLCHAR =3D <Any Unicode character other than ( %x0-1F / %x= 7F )>
>> 
= >>    client-id =3D *NOCOLONVSCHAR
>>   = client_secret =3D *VSCHAR
>> 
>>    username =3D *UNICODENOCTRLCHAR
= >>    password =3D *UNICODENOCTRLCHAR
> 
> In this case you should add a= n introductory statement pointing out that the ABNF defines the grammar in = terms of Unicode code points, not octets (as it is the case most of the tim= e).
> 
>> = It turns out that non-ASCII characters are OK for username and password bec= ause the Core spec only passes them in the form body - not using HTTP Basic= - and UTF-8 encoding is specified.
> 
> I'll send a separate mail about that, the curre= nt text in the spec is way too unspecific.
> 
>>        = ;         -- Mike
>> 
>> P.S.  If anyone has a = better ABNF for UNICODENOCTRLCHAR than "<Any Unicode character other tha= n ( %x0-1F / %x7F )>", please send it to me!
> 
> As noted before, here's an example:= < 
> Best reg= ards, Julian
> _______________________________________________
>= ; OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

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

 

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


This message and any attachment are intended solely for the addressee and m= ay=20 contain confidential information. If you have received this message in erro= r,=20 please send it back to me, and immediately delete it. Please do not use,= =20 copy or disclose the information contained in this message or in any attach= ment. =20 Any views or opinions expressed by the author of this email do not necessar= ily=20 reflect the views of the University of Nottingham.

This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.

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


Eve Maler          =                     &nbs= p;  http://www.xmlgrrl.com/blo= g
+1 425 345 6756               &= nbsp;         http://www.twitter.com/xmlgrrl


= --_000_B2E0806177EF408BBE6B045B35E30864exmailnottinghamacuk_-- From altmulligmannen@hotmail.com Wed Jun 13 15:39:18 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7754F11E8097 for ; Wed, 13 Jun 2012 15:39:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1 X-Spam-Level: * X-Spam-Status: No, score=1 tagged_above=-999 required=5 tests=[BAYES_60=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 uNUlETWhwPRZ for ; Wed, 13 Jun 2012 15:39:18 -0700 (PDT) Received: from snt0-omc1-s8.snt0.hotmail.com (snt0-omc1-s8.snt0.hotmail.com [65.55.90.19]) by ietfa.amsl.com (Postfix) with ESMTP id F322A21F850C for ; Wed, 13 Jun 2012 15:39:17 -0700 (PDT) Received: from SNT139-DS10 ([65.55.90.8]) by snt0-omc1-s8.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 13 Jun 2012 15:39:17 -0700 X-Originating-IP: [10.8.209.95] X-Originating-Email: [altmulligmannen@hotmail.com] Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable From: "Rune Hagen " To: "oauth@ietf.org " Date: Wed, 13 Jun 2012 22:39:17 +0000 X-OriginalArrivalTime: 13 Jun 2012 22:39:17.0580 (UTC) FILETIME=[5DD598C0:01CD49B5] Subject: [OAUTH-WG] Subscribe . File off.. No money.... X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 22:39:18 -0000 =0A= Sendt fra min Nokia-telefon=0A= From squid3@treenet.co.nz Wed Jun 13 15:53:16 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7533611E80B8 for ; Wed, 13 Jun 2012 15:53:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.388 X-Spam-Level: X-Spam-Status: No, score=-4.388 tagged_above=-999 required=5 tests=[AWL=-3.726, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_EQ_STATIC=1.172] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G+bU5DnIdINn for ; Wed, 13 Jun 2012 15:53:16 -0700 (PDT) Received: from treenet.co.nz (ip-58-28-153-233.static-xdsl.xnet.co.nz [58.28.153.233]) by ietfa.amsl.com (Postfix) with ESMTP id E948011E80B0 for ; Wed, 13 Jun 2012 15:53:15 -0700 (PDT) Received: by treenet.co.nz (Postfix, from userid 33) id 2B717E6F33; Thu, 14 Jun 2012 10:53:13 +1200 (NZST) To: X-PHP-Originating-Script: 0:main.inc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 14 Jun 2012 10:53:12 +1200 From: Amos Jeffries In-Reply-To: <40240328-0247-4278-BB7B-BE89AE130076@ve7jtb.com> References: <9dbeab60-8fe4-4828-9c52-d7af95378f4c@email.android.com> <0ec59f35-4a66-4719-adf3-114dab0d1d48@email.android.com> <40240328-0247-4278-BB7B-BE89AE130076@ve7jtb.com> Message-ID: X-Sender: squid3@treenet.co.nz User-Agent: Roundcube Webmail/0.7.2 Subject: Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion needed on username and password ABNF definitions X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 22:53:16 -0000 On 14.06.2012 06:40, John Bradley wrote: > That would probably work as well. That is why I am not particularly > concerned about excluding the : > > We originally used the URI itself, mostly for convenience of > debugging, but there are other potential options. > > The authorization server needs to compare the client_id and the > redirect uri. But it could compare the hash with not much more work. > Also a sha256 hash is probably longer than the uri it is hashing. > > I am not super concerned with being able to have : in the client_id > > John B. > If I'm following all these threads correctly the only explicit problem with URI in client_id is HTTP username field being : terminated. As such it does not have to be a hash per-se, just an encoding that removes ":" and other reserved characters from the on-wire form *when sent via HTTP*. AYJ From psxjs4@nottingham.ac.uk Wed Jun 13 23:39:06 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4A4721F86F3 for ; Wed, 13 Jun 2012 23:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.397 X-Spam-Level: X-Spam-Status: No, score=-2.397 tagged_above=-999 required=5 tests=[AWL=0.202, 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 DcjsHYgbrE3s for ; Wed, 13 Jun 2012 23:39:04 -0700 (PDT) Received: from ixe-mta-19.emailfiltering.com (ixe-mta-19-tx.emailfiltering.com [194.116.198.150]) by ietfa.amsl.com (Postfix) with ESMTP id 33F0F21F86F2 for ; Wed, 13 Jun 2012 23:39:00 -0700 (PDT) Received: from smtp4.nottingham.ac.uk ([128.243.220.65]) by thb-mta-19.emailfiltering.com with emfmta (version 4.8.5.86) by TLS id 2464057166 ;4947ff0d6546bd03; Wed, 13 Jun 2012 22:54:52 +0100 Received: from uiwexhub02.ad.nottingham.ac.uk ([128.243.15.132]) by smtp4.nottingham.ac.uk with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1SevWe-00053d-AV; Wed, 13 Jun 2012 22:54:52 +0100 Received: from EXCHANGE1.ad.nottingham.ac.uk ([fe80::7962:f868:e6ee:6267]) by UIWEXHUB02.ad.nottingham.ac.uk ([2002:80f3:f84::80f3:f84]) with mapi; Wed, 13 Jun 2012 22:54:48 +0100 From: Jianhua Shao To: John Bradley Date: Wed, 13 Jun 2012 22:54:16 +0100 Thread-Topic: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion needed on username and password ABNF definitions Thread-Index: Ac1JryZ0XMA6DQGLRAac/I/tAZqHyQ== Message-ID: References: <9dbeab60-8fe4-4828-9c52-d7af95378f4c@email.android.com> <0ec59f35-4a66-4719-adf3-114dab0d1d48@email.android.com> <40240328-0247-4278-BB7B-BE89AE130076@ve7jtb.com> In-Reply-To: <40240328-0247-4278-BB7B-BE89AE130076@ve7jtb.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_B36B7798CBF34557A967DD41197C1882exmailnottinghamacuk_" MIME-Version: 1.0 Cc: Julian Reschke , Richard Mortier , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion needed on username and password ABNF definitions X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 06:39:06 -0000 --_000_B36B7798CBF34557A967DD41197C1882exmailnottinghamacuk_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable In dynamic, it is hard to know what A come back is B want and B original gi= ve, specially for registration. Therefore, if A wants to register on B, A s= hould give B a unique callback to identify which session it is dealing to, = B should also do the same when A come back to B to confirm the communicatio= n. Let us think about, a client have a general name (Mac OS), but a client wil= l be used by multiple entities (like browser, IM, etc in Mac OS), they all = go to a website to request for access. So in this A -> B cases, what we do = is, for any role, we will have a general name for it (we use URI), and we w= ill have a token for each session (callback, it is generated by A, and give= to B). Once registration is done, the token (it is generated by B give to= A, so that every time A can hold this token to access to B) would keep reu= se for same session. I think when you say client_id, you mean the same. In current industry impl= ementation, like facebook, because app has to be pre-register in facebook, = it is already have the customer_token already, that is why it does not need= a callback token generated by A in necessary. But in dynamic case, we have= to add it on. On 13 Jun 2012, at 19:40, John Bradley wrote: That would probably work as well. That is why I am not particularly concer= ned about excluding the : We originally used the URI itself, mostly for convenience of debugging, b= ut there are other potential options. The authorization server needs to compare the client_id and the redirect ur= i. But it could compare the hash with not much more work. Also a sha256 h= ash is probably longer than the uri it is hashing. I am not super concerned with being able to have : in the client_id John B. Sent from my iPhone On 2012-06-13, at 6:03 PM, Torsten Lodderstedt > wrote: Hi John, would it make sense to use a hash of the URI instead of the URI itself in y= our use case? regards, Torsten. John Bradley > schrieb: I think that the issues are getting confused. There is a use case where the Authorization server may be a embedded app, a= t least in one openID case. As it won't have a separate registration or = token endpoint, the client needs to make its own clientID for the request.= A reasonable thing to use is the redirect URI to create a unique value t= hat the user could use for revocation at a later point. Currently with the no : restriction we would use the host and path to crate= the clientid. There are some scenarios where having the scheme as part of that would be h= elpful. This has nothing to do with discovery or the dynamic client registration pr= oposal as far as I know. A URL as a client_id comes from prototype work for a personal provider that= we are doing as part of openID Connect. John B. On 2012-06-13, at 7:50 AM, Torsten Lodderstedt wrote: Hi all, can anyone please explain the relation between dynamic client registration = and URIs as client ids? None of the current drafts (uma or connect) seem to= require URIs. regards, Torsten. Jianhua Shao > schr= ieb: Hello, Dynamic client registration is very useful if client or resource or authori= sation server is not permanently available. A typical case is that is the resource or authorisation server is in mobile= platform, the connection is not always available. Another typical case is that authorisation server do not necessary to have = client pre-registered on itself. At moment, industry like facebook would li= ke developer to register a app on its app centre first, and then ask user a= uth to use the app. We are researchers from Digital Economy Research Institute. We have this pr= oblem When we developing Dataware that could manage the control of access t= o personal data. We play around our solution base on Oauth2: https://github= .com/jianhuashao/dataware.catalog/wiki We are in the list to receive your mail list, but currently need moderate t= o post any message. cc my colleague, Richard Mortier Best Jian On 12 Jun 2012, at 21:08, Eran Hammer wrote: The only distinction I would make is between removing flexibiliy to proacti= vely enabling future extensibility. I would stop short of perscribing encod= ing in order to fit uri into the Basic auth fields. But if there is a way t= o allow this to be less restrictive without clean interop issues, that woul= d be nice. I do agree we need some actual use cases before we spend much more time on = this. EH From: William Mills [mailto:wmills@yahoo-inc.com] Sent: Tuesday, June 12, 2012 1:04 PM To: Eran Hammer; Mike Jones; Hannes Tschofenig; Julian Reschke Cc: oauth@ietf.org Subject: Dynamic clients, URI, and stuff Re: [OAUTH-WG] Discussion needed o= n username and password ABNF definitions I think dynamic client registration is something we have not talked out eno= ugh yet. There's a pretty clear use case for dynamic registration. Does identifying the client with a URI allow some form of OpenID-ish flow f= or this? Is the client ID as a URI a way to allow a trusted site to provide metadata= about the client? Is that URI a way to hit an IDP we trust to validate the client in some way= with the provided secret? I guess what I'm looking for here is a concrete use case/problem to solve, = rather then leaving a hook we think is the right thing. -bill ________________________________ From: Eran Hammer > To: Mike Jones >; William Mills >; H= annes Tschofenig >; Julian Reschke > Cc: "oauth@ietf.org" > Sent: Tuesday, June 12, 2012 11:39 AM Subject: RE: [OAUTH-WG] Discussion needed on username and password ABNF def= initions Is the use case of using URI as client ids important? It seems like somethi= ng that might become useful in the future where clients can use their verif= iable servers to bypass client registration and simly use a URI the server = can validate via some other means. I just want to make sure those thinking about more complex use cases involv= ing dynamic registration or distri buted client manamgenet are aware of thi= s potential restriction. I'm fine either way. EH From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Mike = Jones Sent: Tuesday, June 12, 2012 11:27 AM To: William Mills; Hannes Tschofenig; Julian Reschke Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF def= initions Not internationalizing fields intended for machine consumption only is alre= ady a precedent set and agreed to by the working group, so let me second Bi= ll=92s point in that regard. For instance, neither =93scope=94 nor =93erro= r=94 allow non-ASCII characters. Julian, if you want different ABNF text than the text I wrote below, I beli= eve it would be most useful if you would provide the exact replace wording = that you=92d like to see instead of it. Then there=92s no possibility of m= isunderstanding the intent of suggested changes. Thanks all, -- Mike From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Willi= am Mills Sent: Tuesday, June 12, 2012 11:18 AM To: Hannes Tschofenig; Julian Reschke Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF def= initions I agree generally with your assumption about clients, but rather than sayin= g "clients are devices" I think it makes much more sense to say "clients ar= e NOT users, so client_id need not be internationalized". In practical ter= ms there is very little to argue for anythign beyond ASCII in a client_secr= et, base64 encoding or the equivalent being a fine way to transport arbitra= ry bits in a portable/reasonable way. I argue that client_id need not be internationalized because I assume that = any really internationalized application will have an internationalized pre= sentation layer that's presenting a pretty name for the client_id. -bill ________________________________ From: Hannes Tschofenig > To: Julian Reschke > Cc: "oauth@ietf.org" > Sent: Tuesday, June 12, 2012 11:01 AM Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF def= initions I had a chat with Julian yesterday and here is my short summary. Section 2.3 of the core draft defines client authentication based on two me= chanisms (and provides room for extensions):http://tools.ietf.org/html/draf= t-ietf-oauth-v2-27#section-2.3 1) HTTP Basic Authentication 2) A custom OAuth authentication mechanism (which uses client_id and client= _secret) With HTTP Basic authentication the problem is that this is a legacy technol= ogy and there is no internationalization support. With our brand new custom OAuth authentication mechanism we have more optio= ns. One possible approach is to say that the clients are devices (and not end u= sers) and therefore internationalization does not matter. Is it, however, really true that only US-ASCII characters will appear in th= e client_id and also in the client_secret? Here we have the possibility to define something better. In any case we have to restrict the characters that are used in these two a= uthentication mechanisms since they could conflict with the way how we tran= sport the data over the underlying protocol. Julian mentioned this in his p= revious mails. Julian, maybe you can provide a detailed text proposal for how to address y= our comment in case we go for UTF8 (with % encoding) for the custom OAuth c= lient authentication mechanism? Ciao Hannes On Jun 12, 2012, at 11:54 AM, Julian Reschke wrote: > On 2012-06-12 00:16, Mike Jones wrote: >> Reviewing the feedback from Julian, John, and James, I'm coming to the c= onclusion that client_id and client_secret, being for machines and not huma= ns, shou ld be ASCII, whereas username and password should be Unicode, sinc= e they are for humans. Per John's feedback, client_id can not contain a co= lon and be compatible with HTTP Basic. > > I'm not sure that restricting the character repertoire just because one w= ay to send requires this is the right approach. My preference would be not = to put this into the ABNF, and just to point out that certain characters wi= ll not work over certain transports, and to just advise to avoid them. > >> Therefore, I'd like to propose these updated ABNF definitions: >> >> VSCHAR =3D %20-7E >> NOCOLONVSCHAR =3D %x20-39 / %x3B-7E >> UNICODENOCTRLCHAR =3D >> >> client-id =3D *NOCOLONVSCHAR >> client_secret =3D *VSCHAR >> >> username =3D *UNICODENOCTRLCHAR >> password =3D *UNICODENOCTRLCHAR > > In this case you should add an introductory statement pointing out that t= he ABNF defines the grammar in terms of Unicode code points, not octets (as= it is the case most of the time). > >> It turns out that non-ASCII characters are OK for username and password = because the Core spec only passes them in the form body - not using HTTP Ba= sic - and UTF-8 encoding is specified. > > I'll send a separate mail about that, the current text in the spec is way= too unspecific. > >> -- Mike >> >> P.S. If anyone has a better ABNF for UNICODENOCTRLCHAR than "", please send it to me! > > As noted before, here's an example: > > Best regards, Julian > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth This message and any attachment are intended solely for the addressee and m= ay contain confidential information. If you have received this message in e= rror, please send it back to me, and immediately delete it. Please do not u= se, copy or disclose the information contained in this message or in any at= tachment. Any views or opinions expressed by the author of this email do no= t necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment= may still contain software viruses which could damage your computer system= : you are advised to perform your own checks. Email communications with the= University of Nottingham may be monitored as permitted by UK legislation. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_B36B7798CBF34557A967DD41197C1882exmailnottinghamacuk_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
In dynamic, it is har= d to know what A come back is B want and B original give, specially for reg= istration. Therefore, if A wants to register on B, A should give B a unique= callback to identify which session it is dealing to, B should also do the = same when A come back to B to confirm the communication. 
Let us think about, a client have a general name (Mac OS), but= a client will be used by multiple entities (like browser, IM, etc in Mac O= S), they all go to a website to request for access. So in this A -> B ca= ses, what we do is, for any role, we will have a general name for it (we us= e URI), and we will have a token for each session (callback, it is generate= d by A, and give to B). Once registration is done, the token (it is generat= ed by B  give to A, so that every time A can hold this token to access= to B) would keep reuse for same session.  

I= think when you say client_id, you mean the same. In current industry imple= mentation, like facebook, because app has to be pre-register in facebook, i= t is already have the customer_token already, that is why it does not need = a callback token generated by A in necessary. But in dynamic case, we have = to add it on.


On 13 Jun 2012, at 19:40, J= ohn Bradley wrote:

That would probably work as we= ll.  That is why I am not particularly concerned about excluding the :=  

We originally used the URI itself,  mo= stly for convenience of debugging,  but there are other potential opti= ons. 

The authorization server needs to compa= re the client_id and the redirect uri. But it could compare the hash with n= ot much more work.   Also a sha256 hash is probably longer than the ur= i it is hashing.  

I am not super concerned w= ith being able to have : in the client_id

John B.&= nbsp;

Sent from my iPhone

On 2012-06-13, at 6:03 PM, T= orsten Lodderstedt <torsten@l= odderstedt.net> wrote:

Hi John,

would it make sense to use a hash of the URI instead of the URI itself in y= our use case?

regards,
Torsten.



John Bradley <ve7jtb@ve7jtb.com= > schrieb:
I think that the issues are getting confused.

There is a= use case where the Authorization server may be a embedded app, at least in= one openID case.    As it won't have a separate registration or = token endpoint,  the client needs to make its own clientID for the req= uest.   A reasonable thing to use is the redirect URI to create a uniq= ue value that the user could use for revocation at a later point.

Currently with the no : restriction we would use the host a= nd path to crate the clientid.
There are some scenarios where hav= ing the scheme as part of that would be helpful.

T= his has nothing to do with discovery or the dynamic client registration pro= posal as far as I know.

A URL as a client_id comes= from prototype work for a personal provider that we are doing as part of o= penID Connect.

John B.
On 2012-06-13,= at 7:50 AM, Torsten Lodderstedt wrote:

Hi = all,

can anyone please explain the relation between dynamic client registration = and URIs as client ids? None of the current drafts (uma or connect) seem to= require URIs.

regards,
Torsten.



Jianhua Shao <psxjs4@nottingh= am.ac.uk> schrieb:
Hello,

Dynamic client registration is very us= eful if client or resource or authorisation server is not permanently avail= able. 
A typical case is that is the resource or authorisati= on server is in mobile platform, the connection is not always available.&nb= sp;
Another typical case is that authorisation server do not nece= ssary to have client pre-registered on itself. At moment, industry like fac= ebook would like developer to register a app on its app centre first, and t= hen ask user auth to use the app. 

We are res= earchers from Digital Economy Research Institute. We have this problem When= we developing Dataware that could manage the control of access to personal= data. We play around our solution base on Oauth2: https://github.com/jianhuasha= o/dataware.catalog/wiki

We are in the list to = receive your mail list, but currently need moderate to post any message. cc my colleague, Richard M= ortier
Best
Jian


On 1= 2 Jun 2012, at 21:08, Eran Hammer wrote:

The only distinction I would make is between removing flexi= biliy to proactively enabling future extensibility. I would stop short of p= erscribing encoding in order to fit uri into the Basic auth fields. But if = there is a way to allow this to be less restrictive without clean interop i= ssues, that would be nice.
 
= I do agree we need some actual use cases before we spend much more time on = this.
 
EH<= /span>
 
From: William Mills [mailto:wmills@yahoo-inc.com] 
Sent: Tuesday, June 12, 2012 1:04 PM
To:=  Eran Hammer; Mike Jo= nes; Hannes Tschofenig; Julian Reschke
Cc: oauth@ietf.or= g
Subject: = Dynamic clients, URI, and stuff Re: [OAUTH-WG] Discussion needed on usernam= e and password ABNF definitions
 
I think dynamic client reg= istration is something we have not talked out enough yet.  There's a p= retty clear use case for dynamic registration.  
 
Does identifying the client with a U= RI allow some form of OpenID-ish flow for this? 
<= span style=3D"font-size: 14pt; font-family: 'Courier New'; color: black; ">= Is that URI a way to hit an IDP we trust to validate the client in some way= with the provided secret?
 =
I guess what I'm looking for here is a concrete use case/problem to = solve, rather then leaving a hook we think is the right thing.
 
-bi= ll
 
 
=
From: = Eran Hammer <eran@hueniverse.com>
To= : Mike Jones <Michael.Jones@microsoft.com>; William Mills <= wmills@yahoo-inc.com>; Hannes Tschofenig <hannes.tschofenig@gmx.net>; Julian Reschke <julian.reschke@gmx.de> 
Cc: = ;"oauth@ietf.org" <oauth@ietf.org&g= t; 
Sent: Tuesday, June 12, 2012 11:39 A= M
Subject: RE: = [OAUTH-WG] Discussion needed on username and password ABNF definitions
 
=
Is the use case of usi= ng URI as client ids important? It seems like something that might become u= seful in the future where clients can use their verifiable servers to bypas= s client registration and simly use a URI the server can validate via some other means.
 
I just = want to make sure those thinking about more complex use cases involving dyn= amic registration or distri buted client manamgenet are aware of this potential restriction.
 
I'm fine either way.=
&nb= sp;
EH
 =
= From:=  oauth-bounces@ietf.org [mailto:oauth= -bounces@ietf.org] On Behalf Of Mike Jo= nes
Sent: Tuesd= ay, June 12, 2012 11:27 AM
To: William Mills; Hannes Tschofenig; Julian Reschke
Cc:<= /b> oauth@ietf= .org
Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF definitio= ns
 
Not internationalizing fields intended for machine consumption o= nly is already a precedent set and agreed to by the working group, so let m= e second Bill=92s point in that regard.  For instance, neither =93scop= e=94 nor =93error=94 allow non-ASCII characters.
 <= /span>
Julian, if you want differ= ent ABNF text than the text I wrote below, I believe it would be most usefu= l if you would provide the exact replace wording that you=92d like to see i= nstead of it.  Then there=92s no possibility of misunderstanding the i= ntent of suggested changes.
&n= bsp;
         &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;            Tha= nks all,
      &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;   -- Mike
 = ;
<= div style=3D"border-right-s tyle: none; border-bottom-style: none; border-left-style: none; border-width: ini= tial; border-color: initial; border-top-style: solid; border-top-color: rgb= (181, 196, 223); border-top-width: 1pt; padding-top: 3pt; padding-right: 0i= n; padding-bottom: 0in; padding-left: 0in; ">
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of William Mills
Sent: Tuesday, June 12, 2012 11:18 AMTo: Hannes Tschof= enig; Julian Reschke
Cc:&nb= sp;oauth@ietf.org
Subject: Re: [OAUTH-WG] Discussi= on needed on username and password ABNF definitions
 
I agree generally with yo= ur assumption about clients, but rather than saying "clients are devices" I= think it makes much more sense to say "clients are NOT users, so client_id= need not be internationalized".  In practical terms there is very lit= tle to argue for anythign beyond ASCII in a client_secret, base64 encoding = or the equivalent being a fine way to transport arbitrary bits in a portabl= e/reasonable way.
 =
I argue that client_id ne= ed not be internationalized because I assume that any really internationali= zed application will have an internationalized presentation layer that's pr= esenting a pretty name for the client_id.
 
-bill<= /span>
 
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
To: Julian Reschke <julian.reschke@gmx.de> 
Cc: "oauth@ietf.org" <oauth@ietf.org> 
Sent: Tuesday, June 12, 2012 11:01 AM
Subject: Re: [OAUTH-WG] Discussion needed o= n username and password ABNF definitions

I had a chat with Julian yesterday and here is my = short summary. 

Se= ction 2.3 of the core draft defines client authentication based on two mech= anisms (and provides room for extensions):http://tools.ietf.org/html/draft-ietf-oauth-v2-27#section-2.3
=
1) HTTP Basic Authentication

2) A custom OAuth authentication me= chanism (which uses client_id and client_secret)

With HTTP Basic aut= hentication the problem is that this is a legacy technology and there is no= internationalization support. <= /span>

With our brand new custom OAuth authentication mechanism we h= ave more options. 
One possible approach is to say that the clients are devices (and not end = users) and therefore internationalization does not matter. 

Is it, however, really true that = only US-ASCII characters will appear in the client_id and also in the clien= t_secret? 

Here we= have the possibility to define something better. 

In any case we have to restrict the charac= ters that are used in these two authentication mechanisms since they could = conflict with the way how we transport the data over the underlying protoco= l. Julian mentioned this in his previous mails. 

Julian, maybe you can provide a detailed tex= t proposal for how to address your comment in case we go for UTF8 (with % e= ncoding) for the custom OAuth client authentication mechanism? 

Ciao
Hannes

On Ju= n 12, 2012, at 11:54 AM, Julian Reschke wrote:

> On 2012-06-12 00= :16, Mike Jones wrote:
>> Reviewing the feedback from Julian, John= , and James, I'm coming to the conclusion that client_id and client_secret,= being for machines and not humans, shou ld be ASCII, whereas username and password should be Unicode, since they are for = humans.  Per John's feedback, client_id can not contain a colon and be= compatible with HTTP Basic.
>&= nbsp;
> I'm not sure that restricting the character repertoire= just because one way to send requires this is the right approach. My prefe= rence would be not to put this into the ABNF, and just to point out that ce= rtain characters will not work over certain transports, and to just advise = to avoid them.
> >> Therefore, I'd like to propose these updated ABNF definitions:>> 
>>&n= bsp;   VSCHAR =3D %20-7E
>>    NOCOLONVSCHAR =3D %x= 20-39 / %x3B-7E
>>    UNICODENOCTRLCHAR =3D <Any Unic= ode character other than ( %x0-1F / %x7F )>
>> 
>>    client-id =3D *= NOCOLONVSCHAR
>>    client_secret =3D *VSCHAR
>>= ; 
>>  &nbs= p; username =3D *UNICODENOCTRLCHAR
>>    password =3D *U= NICODENOCTRLCHAR
> =
> In this case you should add an introductory statement pointing out= that the ABNF defines the grammar in terms of Unicode code points, not oct= ets (as it is the case most of the time).
> 
>> It turns out that non-ASCII character= s are OK for username and password because the Core spec only passes them i= n the form body - not using HTTP Basic - and UTF-8 encoding is specified.> 
> I'll send= a separate mail about that, the current text in the spec is way too unspec= ific.
> 
>>= ;               &nbs= p; -- Mike
>> >> P.S.  If anyone has a better ABNF for UNICODENOCTRLCHAR tha= n "<Any Unicode character other than ( %x0-1F / %x7F )>", please send= it to me!
> 
&g= t; As noted before, here's an example: <http://greenbytes.de/tech/webdav/rf= c5323.html#rfc.section.5.15.1>
> 
> Best regards, Julian
> ________________= _______________________________
> OAuth mailing list
> OAuth@ietf.org
> https://w= ww.ietf.org/mailman/listinfo/oauth

_____________________________= __________________
OAuth mailing list
OA= uth@ietf.org
http= s://www.ietf.org/mailman/listinfo/oauth

 

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

This message and any attachment are intended solely for the addressee and m= ay=20 contain confidential information. If you have received this message in erro= r,=20 please send it back to me, and immediately delete it. Please do not use,= =20 copy or disclose the information contained in this message or in any attach= ment. =20 Any views or opinions expressed by the author of this email do not necessar= ily=20 reflect the views of the University of Nottingham.

This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.

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

(He wrote recently = to the OAuth list with a question about the spec: = http://www.ietf.org/mail-archive/web/oauth/current/msg09053.html)

Eve

p.s. = I'm cc'ing the UMA WG here just to inform them of all this. Followups = should be directed only to the appropriate = list(s).

On 13 Jun 2012, at 1:52 PM, Jianhua Shao = wrote:

Hi, UMA-flavored = sound quite close to our dataware.catalog design to solve similar = problem in dynamic auth and registration. I am interesting to know how = it would push to next stage as it expired on 26 April = 2012. 

Currently OAuth 2 are one way = registration and authentication, which is client register on = authorisation server and also auth in the same direction. Have you think = about the cases that either side can start the registration, which is in = additional that authorisation server wants client to register on it and = give the permission to access to limited resources. We met this demand = that if I heard a application is very useful by listening to my friend, = I would like to actively give permission to this application to start to = use it. 

A concrete example is from my = real experience that when I travel to China, I have use a search engine = called Baidu.com, because I am new to = this search engine but I am using google as daily, so there is a app = could leave the port that could move any historical search data into baidu.com, If I can actively give my = permission of google search history data into that app, I would than = have baidu.com to use in right way. If = you think about many other cases in the life, it is actually a very = common demand. 

So have you think about = this kind of dynamic registration/auth, and also can enable either side = to start the process? Just want to know where and how to contribute to = your existing = work. 

Jian

On 13 Jun = 2012, at 19:42, Eve Maler wrote:

Also please see the = UMA-flavored use cases (there are two) and the summary of requirements = provided in this input document:


= Eve

On 12 Jun 2012, at 1:39 PM, Jianhua Shao = wrote:

Hello,

Dynamic client = registration is very useful if client or resource or authorisation = server is not permanently available. 
A typical case is = that is the resource or authorisation server is in mobile platform, the = connection is not always available. 
Another typical case = is that authorisation server do not necessary to have client = pre-registered on itself. At moment, industry like facebook would like = developer to register a app on its app centre first, and then ask user = auth to use the app. 

We are researchers = from Digital Economy Research Institute. We have this problem When we = developing Dataware that could manage the control of access to personal = data. We play around our solution base on Oauth2: https://gith= ub.com/jianhuashao/dataware.catalog/wiki

We = are in the list to receive your maillist, but currently need moderate to = post any message. cc my colleague, Richard = Mortier
Best
Jian


On= 12 Jun 2012, at 21:08, Eran Hammer wrote:

The = only distinction I would make is between removing flexibiliy to = proactively enabling future extensibility. I would stop short of = perscribing encoding in order to fit uri into the Basic auth fields. But = if there is a way to allow this to be less restrictive without clean = interop issues, that would be nice.
I do = agree we need some actual use cases before we spend much more time on = this.
 William = Mills [mailto:wmills@yahoo-inc.com] 
Sent: Tuesday, June 12, 2012 1:04 = PM
To: Eran = Hammer; Mike Jones; Hannes Tschofenig; Julian Reschke
Cc: oauth@ietf.org
Subject: Dynamic clients, URI, and = stuff Re: [OAUTH-WG] Discussion needed on username and password ABNF = definitions
I = think dynamic client registration is something we have not talked out = enough yet.  There's a pretty clear use case for dynamic = registration.  
Does identifying the client with a URI allow some form = of OpenID-ish flow for = this? 
Is the client ID as a URI a way to allow a trusted site = to provide metadata about the = client?
Is = that URI a way to hit an IDP we trust to validate the client in some way = with the provided secret?
I guess what I'm looking for here is a concrete use = case/problem to solve, rather then leaving a hook we think is the right = thing.
-bill
Is the use case of = using URI as client ids important? It seems like something that might = become useful in the future where clients can use their verifiable = servers to bypass client registration and simly use a URI the server can = validate via some other means. 
I just want to make sure those thinking about more = complex use cases involving dynamic registration or distributed client = manamgenet are aware of this potential restriction.
 I'm fine either = way. 
EH 
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Mike = Jones
Sent: Tuesday, June 12, 2012 = 11:27 AM
To: William Mills; Hannes = Tschofenig; Julian Reschke
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Discussion = needed on username and password ABNF definitionsNot = internationalizing fields intended for machine consumption only is = already a precedent set and agreed to by the working group, so let me = second Bill=92s point in that regard.  For instance, neither = =93scope=94 nor =93error=94 allow non-ASCII characters.
 Julian, if you want = different ABNF text than the text I wrote below, I believe it would be = most useful if you would provide the exact replace wording that you=92d = like to see instead of it.  Then there=92s no possibility of = misunderstanding the intent of suggested changes.
  
 oauth-bounces@ietf.org  On Behalf Of William = Mills
Sent: Tuesday, June 12, 2012 = 11:18 AM
To: Hannes Tschofenig; Julian = Reschke
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Discussion = needed on username and password ABNF definitionsI argue that = client_id need not be internationalized because I assume that any really = internationalized application will have an internationalized = presentation layer that's presenting a pretty name for the = client_id.
From: Hannes Tschofenig < Julian Reschke <julian.reschke@gmx.de> 
Cc: "oauth@ietf.org" <oauth@ietf.org> 
Sent: Tuesday, June 12, 2012 = 11:01 AM
Subject: Re: [OAUTH-WG] Discussion = needed on username and password ABNF definitions

I had a chat with Julian yesterday and here is my short = summary. 

Section= 2.3 of the core draft defines client authentication based on two = mechanisms (and provides room for extensions): 

With our brand new = custom OAuth authentication mechanism we have more options. 

One possible = approach is to say that the clients are devices (and not end users) and = therefore internationalization does not matter. 

Is it, however, = really true that only US-ASCII characters will appear in the client_id = and also in the client_secret? 

Here we have the = possibility to define something better. 

In any case we have = to restrict the characters that are used in these two authentication = mechanisms since they could conflict with the way how we transport the = data over the underlying protocol. Julian mentioned this in his previous = mails. 

Julian, = maybe you can provide a detailed text proposal for how to address your = comment in case we go for UTF8 (with % encoding) for the custom OAuth = client authentication mechanism? 

Ciao
Hannes
On Jun 12, 2012, at 11:54 AM, Julian Reschke wrote:

> On = 2012-06-12 00:16, Mike Jones wrote:
>> Reviewing the feedback = from Julian, John, and James, I'm coming to the conclusion that = client_id and client_secret, being for machines and not humans, should = be ASCII, whereas username and password should be Unicode, since they = are for humans.  Per John's feedback, client_id can not contain a = colon and be compatible with HTTP Basic.
> 
> I'm not sure that = restricting the character repertoire just because one way to send = requires this is the right approach. My preference would be not to put = this into the ABNF, and just to point out that certain characters will = not work over certain transports, and to just advise to avoid = them.
> 
>> Therefore, I'd = like to propose these updated ABNF definitions:
>> 
>>    = VSCHAR =3D %20-7E
>>    NOCOLONVSCHAR =3D %x20-39 / = %x3B-7E
>>    UNICODENOCTRLCHAR =3D <Any Unicode = character other than ( %x0-1F / %x7F )>
>> 
>>    = client-id =3D *NOCOLONVSCHAR
>>    client_secret =3D = *VSCHAR
>> 
>>    = username =3D *UNICODENOCTRLCHAR
>>    password =3D = *UNICODENOCTRLCHAR
> 
> In this case you = should add an introductory statement pointing out that the ABNF defines = the grammar in terms of Unicode code points, not octets (as it is the = case most of the time).
> 
>> It turns out = that non-ASCII characters are OK for username and password because the = Core spec only passes them in the form body - not using HTTP Basic - and = UTF-8 encoding is specified.
> 
> I'll send a = separate mail about that, the current text in the spec is way too = unspecific.
> 
>> =             =     -- Mike
>> 
>> P.S.  If = anyone has a better ABNF for UNICODENOCTRLCHAR than "<Any Unicode = character other than ( %x0-1F / %x7F )>", please send it to = me!
> 
> = As noted before, here's an example: < 
> Best = regards, Julian
> = _______________________________________________
> OAuth mailing = list
> OAuth@ietf.org
> OAuth@ietf.org
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth


This message and any attachment are intended solely for the addressee = and may=20 contain confidential information. If you have received this message in = error,=20 please send it back to me, and immediately delete it. Please do not = use,=20 copy or disclose the information contained in this message or in any = attachment. =20 Any views or opinions expressed by the author of this email do not = necessarily=20 reflect the views of the University of Nottingham.

This message has been checked for viruses but the contents of an = attachment may still contain software viruses which could damage your computer = system: you are advised to perform your own checks. Email communications with = the University of Nottingham may be monitored as permitted by UK = legislation.

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




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


= --Apple-Mail=_FCEA4297-F604-42DE-91BA-E8373AC35188-- From sakimura@gmail.com Thu Jun 14 13:50:52 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C359D21F855F for ; Thu, 14 Jun 2012 13:50:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=1.299, 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 mD7a84VPdwW3 for ; Thu, 14 Jun 2012 13:50:51 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 621C221F8551 for ; Thu, 14 Jun 2012 13:50:51 -0700 (PDT) Received: by bkty8 with SMTP id y8so2064146bkt.31 for ; Thu, 14 Jun 2012 13:50:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+HsvMlYiUPLQRgADTRdLaDKcGFmnncQB84D79Ni3hmo=; b=RKHm2oiEiA/viPJ+bo7h7O+FPSV+x1K6sdpNoEnj8ONCbD07Rg0lDyRNc24Y1M4IDy 6LGj2Rpkg9uo91Kcjn2Qi3I3dqP1n/Lui9MsG1IrLAQ5qJsaw1vUq/r65Eej8g3N3DqB 5lMkWbPQQ5bhUrGw/MQv0Me+g/H6kxUrDzsMImdhe+gNT08O5KlX06RYhfCQ0SzKsGhb UljEgBKokRNq89XQCe9nqHcx5cf32ZbACPU4KOAV/FfeA5D/NjA0B04i5lVGc4FMKolI fHZ2nvTB01lUPyv5gwyYviG0PAZvf9x2jjp70gTxvQYtswNF5z6BACs3HllB4btCOwXA zyvw== MIME-Version: 1.0 Received: by 10.204.151.200 with SMTP id d8mr1902990bkw.82.1339707050284; Thu, 14 Jun 2012 13:50:50 -0700 (PDT) Received: by 10.204.240.143 with HTTP; Thu, 14 Jun 2012 13:50:50 -0700 (PDT) In-Reply-To: References: Date: Fri, 15 Jun 2012 05:50:50 +0900 Message-ID: From: Nat Sakimura To: rui wang Content-Type: multipart/alternative; boundary=0015175cba84d5d91b04c274da51 Cc: matake nov , Yuchen Zhou , oauth , "Shuo Chen \(MSR\)" Subject: Re: [OAUTH-WG] Report an authentication issue X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 20:50:52 -0000 --0015175cba84d5d91b04c274da51 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable This is a fairly well known (hopefully by now) issue. We, at the OpenID Foundation, call it "access_token phishing" attack these days. See: http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.ht= ml Nov Matake has actually built the code on iPhone to verify the problem, and has notified bunch of parties back in February including Facebook and Apple. We have the code that actually runs on a phone, and we have successfully logged in to bunch of apps, including very well known ones. They were all informed of the issue. Some immediately issued a patch to fix it while others have not. The problem is that even if these apps gets fixed, the problem does not go away. As long as the attacker has the vulnerable version of the app, he still can impersonate the victim. To stop it, the server side has to completely disable the older version, which means the service has to cut off many users pausing business problems. Nat On Fri, Jun 15, 2012 at 2:18 AM, rui wang wrote: > Dear Facebook Security Team and OAuth Standard group, > > We are a research team in Microsoft Research. In January, 2011, we > reported a vulnerability in Facebook Connect which allowed everyone to si= gn > into Facebook-secured relying parties without password. It was promptly > fixed after reporting. ( > http://nakedsecurity.sophos.com/2011/02/02/facebook-flaw-websites-steal-p= ersonal-data/ > ) > > Recently, we found a common misunderstanding among developers of > mobile/metro apps when using OAuth (including Facebook=92s OAuth) for > authentication. The vulnerability resulted from this misunderstanding als= o > allows an attacker to log into a victim user's account without password. > > Let's take Soluto's metro app as an example to describe the problem. The > app supports Facebook Login. As an attacker, we can write a regular > Facebook app. Once the victim user allows our app to access her Facebook > data, we receive an access_token from the traffic. Then, on our own machi= ne > (i.e., the "attacker" machine), we run the metro app of Soluto, and use a > HTTP proxy to insert the victim's access_token into the traffic of Facebo= ok > login. Through this way, we are able to log into the victim's Soluto > account from our machine. Other than Soluto, we also have confirmed the > same issue on another Windows 8 metro-app Givit. > > The Facebook SDK for Android apps ( > https://developers.facebook.com/docs/mobile/android/build/#sdk) seems to > have the possibility to mislead developers too. At least, the issue that = we > found is not clearly mentioned. In the SDK, we ran the sample code called > "Hackbook" using Android Emulator (imagine it is an attacker device). Not= e > that we have already received the access token of the victim user from ou= r > regular Facebook app. We then inject the token to the traffic of Hackbook= . > Through this way, Hackbook app on our own machine recognizes us as the > victim. Note that this is not a convincing security exploit yet, because > this sample code does not include the server-side code. However, given th= at > we have seen real server-side code having this problem, such as Soluto, > Givit and others, we do believe that the sample code can mislead > mobile/metro developers. We also suspect that this may be a general issue > of many OAuth implementations on mobile platforms, so we send this messag= e > to OAuth Standard group as well. > > We have contacted the vendors of the two vulnerable metro-apps, Soluto an= d > Gavit. > > Please kindly give us an ack when you receive this message. If you want t= o > know more details, please let us know. > > Best Regards, > Yuchen Zhou, Rui Wang, and Shuo Chen > > _______________________________________________ > 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 --0015175cba84d5d91b04c274da51 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable This is a fairly well known (hopefully by now) issue. We, at the OpenID Fou= ndation, call it "access_token phishing" attack these days. See:= =A0http://www.thread-safe.com/2012/01/problem-with-oauth-for= -authentication.html

Nov Matake has actually built the code on iPhone to verify t= he problem, and has notified bunch of parties back in February including Fa= cebook and Apple. We have the code that actually runs on a phone, and we ha= ve successfully logged in to bunch of apps, including very well known ones.= They were all informed of the issue. Some immediately issued a patch to fi= x it while others have not. =A0

The problem is that even if these apps gets fixed, the = problem does not go away. As long as the attacker has the vulnerable versio= n of the app, he still can impersonate the victim. To stop it, the server s= ide has to completely disable the older version, which means the service ha= s to cut off many users pausing business problems.=A0

Nat

On Fri, Jun 15, 2= 012 at 2:18 AM, rui wang <ruiwangwarm@gmail.com> wrote:<= br>

Dear Facebook Security Team and OAuth Standard group,

We are a research team in Microsoft Research. In January, 2011, we repor= ted a vulnerability in Facebook Connect which allowed everyone to sign into= Facebook-secured relying parties without password. It was promptly fixed a= fter reporting. (http://nakedsecu= rity.sophos.com/2011/02/02/facebook-flaw-websites-steal-personal-data/)=

Recently, we found a common misunderstanding among developers of mobile/= metro apps when using OAuth (including Facebook=92s OAuth) for authenticati= on. The vulnerability resulted from this misunderstanding also allows an at= tacker to log into a victim user's account without password.

Let's take Soluto's metro app as an example to describe the prob= lem. The app supports Facebook Login. As an attacker, we can write a regula= r Facebook app. Once the victim user allows our app to access her Facebook = data, we receive an access_token from the traffic. Then, on our own machine= (i.e., the "attacker" machine), we run the metro app of Soluto, = and use a HTTP proxy to insert the victim's access_token into the traff= ic of Facebook login. Through this way, we are able to log into the victim&= #39;s Soluto account from our machine. Other than Soluto, we also have conf= irmed the same issue on another Windows 8 metro-app Givit.

The Facebook SDK for Android apps (https://developers.= facebook.com/docs/mobile/android/build/#sdk) seems to have the possibil= ity to mislead developers too. At least, the issue that we found is not cle= arly mentioned. In the SDK, we ran the sample code called "Hackbook&qu= ot; using Android Emulator (imagine it is an attacker device). Note that we= have already received the access token of the victim user from our regular= Facebook app. We then inject the token to the traffic of Hackbook. Through= this way, Hackbook app on our own machine recognizes us as the victim. Not= e that this is not a convincing security exploit yet, because this sample c= ode does not include the server-side code. However, given that we have seen= real server-side code having this problem, such as Soluto, Givit and other= s, we do believe that the sample code can mislead mobile/metro developers. = We also suspect that this may be a general issue of many OAuth implementati= ons on mobile platforms, so we send this message to OAuth Standard group as= well.

We have contacted the vendors of the two vulnerable metro-apps, Soluto a= nd Gavit.

Please kindly give us an ack when you receive this message. If you want = to know more details, please let us know.

Best Regards,
Yuchen Zhou, Rui Wang, and Shuo Chen


_______________________________________________
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
=
--0015175cba84d5d91b04c274da51-- From Michael.Jones@microsoft.com Thu Jun 14 14:15:18 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8B0C21F85C5 for ; Thu, 14 Jun 2012 14:15:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.813 X-Spam-Level: X-Spam-Status: No, score=-3.813 tagged_above=-999 required=5 tests=[AWL=-0.215, 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 40TBaZpu12AO for ; Thu, 14 Jun 2012 14:15:16 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe003.messaging.microsoft.com [216.32.181.183]) by ietfa.amsl.com (Postfix) with ESMTP id 4F70121F85C4 for ; Thu, 14 Jun 2012 14:15:16 -0700 (PDT) Received: from mail223-ch1-R.bigfish.com (10.43.68.244) by CH1EHSOBE002.bigfish.com (10.43.70.52) with Microsoft SMTP Server id 14.1.225.23; Thu, 14 Jun 2012 21:14:07 +0000 Received: from mail223-ch1 (localhost [127.0.0.1]) by mail223-ch1-R.bigfish.com (Postfix) with ESMTP id 2894446064D; Thu, 14 Jun 2012 21:14:07 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -26 X-BigFish: VS-26(zz98dI9371Ic89bh936eI14ffI1432I1418Ic857hzz1202hzz8275ch1033IL8275bh8275dhz2fh2a8h668h839hd25hf0ah) Received-SPF: pass (mail223-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC103.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail223-ch1 (localhost.localdomain [127.0.0.1]) by mail223-ch1 (MessageSwitch) id 1339708444995476_30087; Thu, 14 Jun 2012 21:14:04 +0000 (UTC) Received: from CH1EHSMHS022.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.234]) by mail223-ch1.bigfish.com (Postfix) with ESMTP id F06B62E004A; Thu, 14 Jun 2012 21:14:04 +0000 (UTC) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS022.bigfish.com (10.43.70.22) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 14 Jun 2012 21:14:04 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.189]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.02.0298.005; Thu, 14 Jun 2012 21:14:29 +0000 From: Mike Jones To: John Bradley , Torsten Lodderstedt Thread-Topic: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion needed on username and password ABNF definitions Thread-Index: Ac1KcqfhqNGWQ8CmT2q76mt0mS+U2w== Date: Thu, 14 Jun 2012 21:14:28 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366539292@TK5EX14MBXC284.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394366539292TK5EX14MBXC284r_" MIME-Version: 1.0 X-FOPE-CRA-Verdict: 131.107.125.8$nottingham.ac.uk%19607%4%microsoft.com%False%False%0$ X-OriginatorOrg: microsoft.com Cc: Julian Reschke , Richard Mortier , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion needed on username and password ABNF definitions X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 21:15:19 -0000 --_000_4E1F6AAD24975D4BA5B168042967394366539292TK5EX14MBXC284r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIG1vcmUgSSB0aGluayBhYm91dCBleGNsdWRpbmcgdGhlIHBvc3NpYmlsaXR5IG9mIHVzaW5n IFVSSXMgYXMgY2xpZW50IElEcywgdGhlIG1vcmUgdW5jb21mb3J0YWJsZSBJIGFtIHdpdGggaXQu ICBJ4oCZbSBpbmNyZWFzaW5nbHkgdGhpbmtpbmcgdGhhdCB3ZSBzaG91bGQgYWxsb3cgdGhlIEFT Q0lJIGNoYXJhY3RlcnMgdXNlZCBpbiBVUklzIChhbmQgcHJvYmFibHkgdGhlIG90aGVyIHZpc2li bGUgb25lcyBhbmQgc3BhY2UgYXMgd2VsbCwgYXMgY3VycmVudGx5IHByb3Bvc2VkKSBhbmQgaGF2 ZSBzcGVjaWFsIGxhbmd1YWdlIGFib3V0IOKAnEJ1dCB3aGF0IGlmIHRoaXMgY2xpZW50X2lkIGNv bnRhaW5pbmcgY29sb24gY2hhcmFjdGVycyBpcyB0byBiZSB1c2VkIHdpdGggSFRUUCBCYXNpYz/i gJ0NCg0KQXMgb25lIHN1Z2dlc3Rpb24sIG1haW5seSB0byByZXN0YXJ0IGRpc2N1c3Npb24gKHdo aWNoIHNlZW1zIHRvIGhhdmUgc3RhbGxlZCksIHdlIGNvdWxkIHN1Z2dlc3QgKG9yIHJlcXVpcmUp IHRoYXQgYWxsIGNvbG9uIGNoYXJhY3RlcnMgaW4gY2xpZW50X2lkcyBiZSBzdWJzdGl0dXRlZCB3 aXRoIHRhYiBjaGFyYWN0ZXJzICgleDA5KSwgd2hpY2ggYXJlIGxlZ2FsIGluIEhUVFAgQmFzaWMg YnV0IG5vdCBpbiB0aGUgcHJvcG9zZWQgZGVmaW5pdGlvbiBvZiBjbGllbnRfaWRzLCBiZWZvcmUg dXNlIHdpdGggSFRUUCBCYXNpYywgYW5kIHRoYXQgdGhlIHJldmVyc2Ugc3Vic3RpdHV0aW9uIG9j Y3VyIHdoZW4gcmVjZWl2ZWQgZnJvbSBIVFRQIEJhc2ljLiAgT3RoZXIgdHJhbnNmb3JtYXRpb25z IG9yIGVuY29kaW5ncyBhcmUgcG9zc2libGUuICBXZSBjb3VsZCBhbHNvIGNvcCBvdXQgYnkgc2F5 aW5nIHNvbWV0aGluZyBsaWtlIOKAnElmIGNoYXJhY3RlcnMgbm90IGxlZ2FsIGluIEhUVFAgQmFz aWMgb2NjdXIgaW4gdGhlIGNsaWVudF9pZCwgYSB0cmFuc2Zvcm1hdGlvbiBlbmNvZGluZyB0aGVt IG11c3QgYmUgYWdyZWVkIHRvIGJ5IGJvdGggcGFydGllc+KAnS4gIEkgZG9u4oCZdCBsb3ZlIHRo ZSB0YWIgaWRlYSwgYmVjYXVzZSBpdOKAmXMgYWRtaXR0ZWRseSBhIGhhY2ssIGJ1dCBJIGJlbGll dmUgaXTigJlzIGJldHRlciB0aGFuIHByZWNsdWRpbmcgdGhlIHVzZSBvZiBVUklzIGFzIGNsaWVu dF9pZHMuDQoNClRob3VnaHRzPw0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCkZyb206IG9hdXRoLWJvdW5jZXNA aWV0Zi5vcmcgW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSm9o biBCcmFkbGV5DQpTZW50OiBXZWRuZXNkYXksIEp1bmUgMTMsIDIwMTIgMTE6NDAgQU0NClRvOiBU b3JzdGVuIExvZGRlcnN0ZWR0DQpDYzogSnVsaWFuIFJlc2Noa2U7IFJpY2hhcmQgTW9ydGllcjsg b2F1dGhAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIER5bmFtaWMgY2xpZW50cywg VVJJLCBhbmQgc3R1ZmYgUmU6IERpc2N1c3Npb24gbmVlZGVkIG9uIHVzZXJuYW1lIGFuZCBwYXNz d29yZCBBQk5GIGRlZmluaXRpb25zDQoNClRoYXQgd291bGQgcHJvYmFibHkgd29yayBhcyB3ZWxs LiAgVGhhdCBpcyB3aHkgSSBhbSBub3QgcGFydGljdWxhcmx5IGNvbmNlcm5lZCBhYm91dCBleGNs dWRpbmcgdGhlIDoNCg0KV2Ugb3JpZ2luYWxseSB1c2VkIHRoZSBVUkkgaXRzZWxmLCAgbW9zdGx5 IGZvciBjb252ZW5pZW5jZSBvZiBkZWJ1Z2dpbmcsICBidXQgdGhlcmUgYXJlIG90aGVyIHBvdGVu dGlhbCBvcHRpb25zLg0KDQpUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgbmVlZHMgdG8gY29tcGFy ZSB0aGUgY2xpZW50X2lkIGFuZCB0aGUgcmVkaXJlY3QgdXJpLiBCdXQgaXQgY291bGQgY29tcGFy ZSB0aGUgaGFzaCB3aXRoIG5vdCBtdWNoIG1vcmUgd29yay4gICBBbHNvIGEgc2hhMjU2IGhhc2gg aXMgcHJvYmFibHkgbG9uZ2VyIHRoYW4gdGhlIHVyaSBpdCBpcyBoYXNoaW5nLg0KDQpJIGFtIG5v dCBzdXBlciBjb25jZXJuZWQgd2l0aCBiZWluZyBhYmxlIHRvIGhhdmUgOiBpbiB0aGUgY2xpZW50 X2lkDQoNCkpvaG4gQi4NCg0KU2VudCBmcm9tIG15IGlQaG9uZQ0KDQpPbiAyMDEyLTA2LTEzLCBh dCA2OjAzIFBNLCBUb3JzdGVuIExvZGRlcnN0ZWR0IDx0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDxt YWlsdG86dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ+PiB3cm90ZToNCkhpIEpvaG4sDQoNCndvdWxk IGl0IG1ha2Ugc2Vuc2UgdG8gdXNlIGEgaGFzaCBvZiB0aGUgVVJJIGluc3RlYWQgb2YgdGhlIFVS SSBpdHNlbGYgaW4geW91ciB1c2UgY2FzZT8NCg0KcmVnYXJkcywNClRvcnN0ZW4uDQoNCg0KSm9o biBCcmFkbGV5IDx2ZTdqdGJAdmU3anRiLmNvbTxtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20+PiBz Y2hyaWViOg0KSSB0aGluayB0aGF0IHRoZSBpc3N1ZXMgYXJlIGdldHRpbmcgY29uZnVzZWQuDQoN ClRoZXJlIGlzIGEgdXNlIGNhc2Ugd2hlcmUgdGhlIEF1dGhvcml6YXRpb24gc2VydmVyIG1heSBi ZSBhIGVtYmVkZGVkIGFwcCwgYXQgbGVhc3QgaW4gb25lIG9wZW5JRCBjYXNlLiAgICBBcyBpdCB3 b24ndCBoYXZlIGEgc2VwYXJhdGUgcmVnaXN0cmF0aW9uIG9yIHRva2VuIGVuZHBvaW50LCAgdGhl IGNsaWVudCBuZWVkcyB0byBtYWtlIGl0cyBvd24gY2xpZW50SUQgZm9yIHRoZSByZXF1ZXN0LiAg IEEgcmVhc29uYWJsZSB0aGluZyB0byB1c2UgaXMgdGhlIHJlZGlyZWN0IFVSSSB0byBjcmVhdGUg YSB1bmlxdWUgdmFsdWUgdGhhdCB0aGUgdXNlciBjb3VsZCB1c2UgZm9yIHJldm9jYXRpb24gYXQg YSBsYXRlciBwb2ludC4NCg0KQ3VycmVudGx5IHdpdGggdGhlIG5vIDogcmVzdHJpY3Rpb24gd2Ug d291bGQgdXNlIHRoZSBob3N0IGFuZCBwYXRoIHRvIGNyYXRlIHRoZSBjbGllbnRpZC4NClRoZXJl IGFyZSBzb21lIHNjZW5hcmlvcyB3aGVyZSBoYXZpbmcgdGhlIHNjaGVtZSBhcyBwYXJ0IG9mIHRo YXQgd291bGQgYmUgaGVscGZ1bC4NCg0KVGhpcyBoYXMgbm90aGluZyB0byBkbyB3aXRoIGRpc2Nv dmVyeSBvciB0aGUgZHluYW1pYyBjbGllbnQgcmVnaXN0cmF0aW9uIHByb3Bvc2FsIGFzIGZhciBh cyBJIGtub3cuDQoNCkEgVVJMIGFzIGEgY2xpZW50X2lkIGNvbWVzIGZyb20gcHJvdG90eXBlIHdv cmsgZm9yIGEgcGVyc29uYWwgcHJvdmlkZXIgdGhhdCB3ZSBhcmUgZG9pbmcgYXMgcGFydCBvZiBv cGVuSUQgQ29ubmVjdC4NCg0KSm9obiBCLg0KT24gMjAxMi0wNi0xMywgYXQgNzo1MCBBTSwgVG9y c3RlbiBMb2RkZXJzdGVkdCB3cm90ZToNCg0KDQpIaSBhbGwsDQoNCmNhbiBhbnlvbmUgcGxlYXNl IGV4cGxhaW4gdGhlIHJlbGF0aW9uIGJldHdlZW4gZHluYW1pYyBjbGllbnQgcmVnaXN0cmF0aW9u IGFuZCBVUklzIGFzIGNsaWVudCBpZHM/IE5vbmUgb2YgdGhlIGN1cnJlbnQgZHJhZnRzICh1bWEg b3IgY29ubmVjdCkgc2VlbSB0byByZXF1aXJlIFVSSXMuDQoNCnJlZ2FyZHMsDQpUb3JzdGVuLg0K DQoNCkppYW5odWEgU2hhbyA8cHN4anM0QG5vdHRpbmdoYW0uYWMudWs8bWFpbHRvOnBzeGpzNEBu b3R0aW5naGFtLmFjLnVrPj4gc2NocmllYjoNCkhlbGxvLA0KDQpEeW5hbWljIGNsaWVudCByZWdp c3RyYXRpb24gaXMgdmVyeSB1c2VmdWwgaWYgY2xpZW50IG9yIHJlc291cmNlIG9yIGF1dGhvcmlz YXRpb24gc2VydmVyIGlzIG5vdCBwZXJtYW5lbnRseSBhdmFpbGFibGUuDQpBIHR5cGljYWwgY2Fz ZSBpcyB0aGF0IGlzIHRoZSByZXNvdXJjZSBvciBhdXRob3Jpc2F0aW9uIHNlcnZlciBpcyBpbiBt b2JpbGUgcGxhdGZvcm0sIHRoZSBjb25uZWN0aW9uIGlzIG5vdCBhbHdheXMgYXZhaWxhYmxlLg0K QW5vdGhlciB0eXBpY2FsIGNhc2UgaXMgdGhhdCBhdXRob3Jpc2F0aW9uIHNlcnZlciBkbyBub3Qg bmVjZXNzYXJ5IHRvIGhhdmUgY2xpZW50IHByZS1yZWdpc3RlcmVkIG9uIGl0c2VsZi4gQXQgbW9t ZW50LCBpbmR1c3RyeSBsaWtlIGZhY2Vib29rIHdvdWxkIGxpa2UgZGV2ZWxvcGVyIHRvIHJlZ2lz dGVyIGEgYXBwIG9uIGl0cyBhcHAgY2VudHJlIGZpcnN0LCBhbmQgdGhlbiBhc2sgdXNlciBhdXRo IHRvIHVzZSB0aGUgYXBwLg0KDQpXZSBhcmUgcmVzZWFyY2hlcnMgZnJvbSBEaWdpdGFsIEVjb25v bXkgUmVzZWFyY2ggSW5zdGl0dXRlLiBXZSBoYXZlIHRoaXMgcHJvYmxlbSBXaGVuIHdlIGRldmVs b3BpbmcgRGF0YXdhcmUgdGhhdCBjb3VsZCBtYW5hZ2UgdGhlIGNvbnRyb2wgb2YgYWNjZXNzIHRv IHBlcnNvbmFsIGRhdGEuIFdlIHBsYXkgYXJvdW5kIG91ciBzb2x1dGlvbiBiYXNlIG9uIE9hdXRo MjogaHR0cHM6Ly9naXRodWIuY29tL2ppYW5odWFzaGFvL2RhdGF3YXJlLmNhdGFsb2cvd2lraQ0K DQpXZSBhcmUgaW4gdGhlIGxpc3QgdG8gcmVjZWl2ZSB5b3VyIG1haWwgbGlzdCwgYnV0IGN1cnJl bnRseSBuZWVkIG1vZGVyYXRlIHRvIHBvc3QgYW55IG1lc3NhZ2UuIGNjIG15IGNvbGxlYWd1ZSwg UmljaGFyZCBNb3J0aWVyDQpCZXN0DQpKaWFuDQoNCg0KT24gMTIgSnVuIDIwMTIsIGF0IDIxOjA4 LCBFcmFuIEhhbW1lciB3cm90ZToNCg0KDQpUaGUgb25seSBkaXN0aW5jdGlvbiBJIHdvdWxkIG1h a2UgaXMgYmV0d2VlbiByZW1vdmluZyBmbGV4aWJpbGl5IHRvIHByb2FjdGl2ZWx5IGVuYWJsaW5n IGZ1dHVyZSBleHRlbnNpYmlsaXR5LiBJIHdvdWxkIHN0b3Agc2hvcnQgb2YgcGVyc2NyaWJpbmcg ZW5jb2RpbmcgaW4gb3JkZXIgdG8gZml0IHVyaSBpbnRvIHRoZSBCYXNpYyBhdXRoIGZpZWxkcy4g QnV0IGlmIHRoZXJlIGlzIGEgd2F5IHRvIGFsbG93IHRoaXMgdG8gYmUgbGVzcyByZXN0cmljdGl2 ZSB3aXRob3V0IGNsZWFuIGludGVyb3AgaXNzdWVzLCB0aGF0IHdvdWxkIGJlIG5pY2UuDQoNCkkg ZG8gYWdyZWUgd2UgbmVlZCBzb21lIGFjdHVhbCB1c2UgY2FzZXMgYmVmb3JlIHdlIHNwZW5kIG11 Y2ggbW9yZSB0aW1lIG9uIHRoaXMuDQoNCkVIDQoNCkZyb206IFdpbGxpYW0gTWlsbHMgW21haWx0 bzp3bWlsbHNAeWFob28taW5jLmNvbV08bWFpbHRvOlttYWlsdG86d21pbGxzQHlhaG9vLWluYy5j b21dPg0KU2VudDogVHVlc2RheSwgSnVuZSAxMiwgMjAxMiAxOjA0IFBNDQpUbzogRXJhbiBIYW1t ZXI7IE1pa2UgSm9uZXM7IEhhbm5lcyBUc2Nob2ZlbmlnOyBKdWxpYW4gUmVzY2hrZQ0KQ2M6IG9h dXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4NClN1YmplY3Q6IER5bmFtaWMgY2xp ZW50cywgVVJJLCBhbmQgc3R1ZmYgUmU6IFtPQVVUSC1XR10gRGlzY3Vzc2lvbiBuZWVkZWQgb24g dXNlcm5hbWUgYW5kIHBhc3N3b3JkIEFCTkYgZGVmaW5pdGlvbnMNCg0KSSB0aGluayBkeW5hbWlj IGNsaWVudCByZWdpc3RyYXRpb24gaXMgc29tZXRoaW5nIHdlIGhhdmUgbm90IHRhbGtlZCBvdXQg ZW5vdWdoIHlldC4gIFRoZXJlJ3MgYSBwcmV0dHkgY2xlYXIgdXNlIGNhc2UgZm9yIGR5bmFtaWMg cmVnaXN0cmF0aW9uLg0KDQpEb2VzIGlkZW50aWZ5aW5nIHRoZSBjbGllbnQgd2l0aCBhIFVSSSBh bGxvdyBzb21lIGZvcm0gb2YgT3BlbklELWlzaCBmbG93IGZvciB0aGlzPw0KSXMgdGhlIGNsaWVu dCBJRCBhcyBhIFVSSSBhIHdheSB0byBhbGxvdyBhIHRydXN0ZWQgc2l0ZSB0byBwcm92aWRlIG1l dGFkYXRhIGFib3V0IHRoZSBjbGllbnQ/DQpJcyB0aGF0IFVSSSBhIHdheSB0byBoaXQgYW4gSURQ IHdlIHRydXN0IHRvIHZhbGlkYXRlIHRoZSBjbGllbnQgaW4gc29tZSB3YXkgd2l0aCB0aGUgcHJv dmlkZWQgc2VjcmV0Pw0KDQpJIGd1ZXNzIHdoYXQgSSdtIGxvb2tpbmcgZm9yIGhlcmUgaXMgYSBj b25jcmV0ZSB1c2UgY2FzZS9wcm9ibGVtIHRvIHNvbHZlLCByYXRoZXIgdGhlbiBsZWF2aW5nIGEg aG9vayB3ZSB0aGluayBpcyB0aGUgcmlnaHQgdGhpbmcuDQoNCi1iaWxsDQoNCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IEVyYW4gSGFtbWVyIDxlcmFuQGh1ZW5pdmVy c2UuY29tPG1haWx0bzplcmFuQGh1ZW5pdmVyc2UuY29tPj4NClRvOiBNaWtlIEpvbmVzIDxNaWNo YWVsLkpvbmVzQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNv bT4+OyBXaWxsaWFtIE1pbGxzIDx3bWlsbHNAeWFob28taW5jLmNvbTxtYWlsdG86d21pbGxzQHlh aG9vLWluYy5jb20+PjsgSGFubmVzIFRzY2hvZmVuaWcgPGhhbm5lcy50c2Nob2ZlbmlnQGdteC5u ZXQ8bWFpbHRvOmhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQ+PjsgSnVsaWFuIFJlc2Noa2UgPGp1 bGlhbi5yZXNjaGtlQGdteC5kZTxtYWlsdG86anVsaWFuLnJlc2Noa2VAZ214LmRlPj4NCkNjOiAi b2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPiIgPG9hdXRoQGlldGYub3JnPG1h aWx0bzpvYXV0aEBpZXRmLm9yZz4+DQpTZW50OiBUdWVzZGF5LCBKdW5lIDEyLCAyMDEyIDExOjM5 IEFNDQpTdWJqZWN0OiBSRTogW09BVVRILVdHXSBEaXNjdXNzaW9uIG5lZWRlZCBvbiB1c2VybmFt ZSBhbmQgcGFzc3dvcmQgQUJORiBkZWZpbml0aW9ucw0KDQpJcyB0aGUgdXNlIGNhc2Ugb2YgdXNp bmcgVVJJIGFzIGNsaWVudCBpZHMgaW1wb3J0YW50PyBJdCBzZWVtcyBsaWtlIHNvbWV0aGluZyB0 aGF0IG1pZ2h0IGJlY29tZSB1c2VmdWwgaW4gdGhlIGZ1dHVyZSB3aGVyZSBjbGllbnRzIGNhbiB1 c2UgdGhlaXIgdmVyaWZpYWJsZSBzZXJ2ZXJzIHRvIGJ5cGFzcyBjbGllbnQgcmVnaXN0cmF0aW9u IGFuZCBzaW1seSB1c2UgYSBVUkkgdGhlIHNlcnZlciBjYW4gdmFsaWRhdGUgdmlhIHNvbWUgb3Ro ZXIgbWVhbnMuDQoNCkkganVzdCB3YW50IHRvIG1ha2Ugc3VyZSB0aG9zZSB0aGlua2luZyBhYm91 dCBtb3JlIGNvbXBsZXggdXNlIGNhc2VzIGludm9sdmluZyBkeW5hbWljIHJlZ2lzdHJhdGlvbiBv ciBkaXN0cmkgYnV0ZWQgY2xpZW50IG1hbmFtZ2VuZXQgYXJlIGF3YXJlIG9mIHRoaXMgcG90ZW50 aWFsIHJlc3RyaWN0aW9uLg0KDQpJJ20gZmluZSBlaXRoZXIgd2F5Lg0KDQpFSA0KDQpGcm9tOiBv YXV0aC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnPiBbbWFp bHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddPG1haWx0bzpbbWFpbHRvOm9hdXRoLWJvdW5jZXNA aWV0Zi5vcmddPiBPbiBCZWhhbGYgT2YgTWlrZSBKb25lcw0KU2VudDogVHVlc2RheSwgSnVuZSAx MiwgMjAxMiAxMToyNyBBTQ0KVG86IFdpbGxpYW0gTWlsbHM7IEhhbm5lcyBUc2Nob2ZlbmlnOyBK dWxpYW4gUmVzY2hrZQ0KQ2M6IG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4N ClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIERpc2N1c3Npb24gbmVlZGVkIG9uIHVzZXJuYW1lIGFu ZCBwYXNzd29yZCBBQk5GIGRlZmluaXRpb25zDQoNCk5vdCBpbnRlcm5hdGlvbmFsaXppbmcgZmll bGRzIGludGVuZGVkIGZvciBtYWNoaW5lIGNvbnN1bXB0aW9uIG9ubHkgaXMgYWxyZWFkeSBhIHBy ZWNlZGVudCBzZXQgYW5kIGFncmVlZCB0byBieSB0aGUgd29ya2luZyBncm91cCwgc28gbGV0IG1l IHNlY29uZCBCaWxs4oCZcyBwb2ludCBpbiB0aGF0IHJlZ2FyZC4gIEZvciBpbnN0YW5jZSwgbmVp dGhlciDigJxzY29wZeKAnSBub3Ig4oCcZXJyb3LigJ0gYWxsb3cgbm9uLUFTQ0lJIGNoYXJhY3Rl cnMuDQoNCkp1bGlhbiwgaWYgeW91IHdhbnQgZGlmZmVyZW50IEFCTkYgdGV4dCB0aGFuIHRoZSB0 ZXh0IEkgd3JvdGUgYmVsb3csIEkgYmVsaWV2ZSBpdCB3b3VsZCBiZSBtb3N0IHVzZWZ1bCBpZiB5 b3Ugd291bGQgcHJvdmlkZSB0aGUgZXhhY3QgcmVwbGFjZSB3b3JkaW5nIHRoYXQgeW914oCZZCBs aWtlIHRvIHNlZSBpbnN0ZWFkIG9mIGl0LiAgVGhlbiB0aGVyZeKAmXMgbm8gcG9zc2liaWxpdHkg b2YgbWlzdW5kZXJzdGFuZGluZyB0aGUgaW50ZW50IG9mIHN1Z2dlc3RlZCBjaGFuZ2VzLg0KDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBUaGFua3MgYWxsLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBvYXV0aC1ib3VuY2VzQGlldGYub3Jn PG1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0 Zi5vcmddPG1haWx0bzpbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddPiBPbiBCZWhhbGYg T2YgV2lsbGlhbSBNaWxscw0KU2VudDogVHVlc2RheSwgSnVuZSAxMiwgMjAxMiAxMToxOCBBTQ0K VG86IEhhbm5lcyBUc2Nob2ZlbmlnOyBKdWxpYW4gUmVzY2hrZQ0KQ2M6IG9hdXRoQGlldGYub3Jn PG1haWx0bzpvYXV0aEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIERpc2N1c3Np b24gbmVlZGVkIG9uIHVzZXJuYW1lIGFuZCBwYXNzd29yZCBBQk5GIGRlZmluaXRpb25zDQoNCkkg YWdyZWUgZ2VuZXJhbGx5IHdpdGggeW91ciBhc3N1bXB0aW9uIGFib3V0IGNsaWVudHMsIGJ1dCBy YXRoZXIgdGhhbiBzYXlpbmcgImNsaWVudHMgYXJlIGRldmljZXMiIEkgdGhpbmsgaXQgbWFrZXMg bXVjaCBtb3JlIHNlbnNlIHRvIHNheSAiY2xpZW50cyBhcmUgTk9UIHVzZXJzLCBzbyBjbGllbnRf aWQgbmVlZCBub3QgYmUgaW50ZXJuYXRpb25hbGl6ZWQiLiAgSW4gcHJhY3RpY2FsIHRlcm1zIHRo ZXJlIGlzIHZlcnkgbGl0dGxlIHRvIGFyZ3VlIGZvciBhbnl0aGlnbiBiZXlvbmQgQVNDSUkgaW4g YSBjbGllbnRfc2VjcmV0LCBiYXNlNjQgZW5jb2Rpbmcgb3IgdGhlIGVxdWl2YWxlbnQgYmVpbmcg YSBmaW5lIHdheSB0byB0cmFuc3BvcnQgYXJiaXRyYXJ5IGJpdHMgaW4gYSBwb3J0YWJsZS9yZWFz b25hYmxlIHdheS4NCg0KSSBhcmd1ZSB0aGF0IGNsaWVudF9pZCBuZWVkIG5vdCBiZSBpbnRlcm5h dGlvbmFsaXplZCBiZWNhdXNlIEkgYXNzdW1lIHRoYXQgYW55IHJlYWxseSBpbnRlcm5hdGlvbmFs aXplZCBhcHBsaWNhdGlvbiB3aWxsIGhhdmUgYW4gaW50ZXJuYXRpb25hbGl6ZWQgcHJlc2VudGF0 aW9uIGxheWVyIHRoYXQncyBwcmVzZW50aW5nIGEgcHJldHR5IG5hbWUgZm9yIHRoZSBjbGllbnRf aWQuDQoNCi1iaWxsDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBI YW5uZXMgVHNjaG9mZW5pZyA8aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldDxtYWlsdG86aGFubmVz LnRzY2hvZmVuaWdAZ214Lm5ldD4+DQpUbzogSnVsaWFuIFJlc2Noa2UgPGp1bGlhbi5yZXNjaGtl QGdteC5kZTxtYWlsdG86anVsaWFuLnJlc2Noa2VAZ214LmRlPj4NCkNjOiAib2F1dGhAaWV0Zi5v cmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPiIgPG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBp ZXRmLm9yZz4+DQpTZW50OiBUdWVzZGF5LCBKdW5lIDEyLCAyMDEyIDExOjAxIEFNDQpTdWJqZWN0 OiBSZTogW09BVVRILVdHXSBEaXNjdXNzaW9uIG5lZWRlZCBvbiB1c2VybmFtZSBhbmQgcGFzc3dv cmQgQUJORiBkZWZpbml0aW9ucw0KDQpJIGhhZCBhIGNoYXQgd2l0aCBKdWxpYW4geWVzdGVyZGF5 IGFuZCBoZXJlIGlzIG15IHNob3J0IHN1bW1hcnkuDQoNClNlY3Rpb24gMi4zIG9mIHRoZSBjb3Jl IGRyYWZ0IGRlZmluZXMgY2xpZW50IGF1dGhlbnRpY2F0aW9uIGJhc2VkIG9uIHR3byBtZWNoYW5p c21zIChhbmQgcHJvdmlkZXMgcm9vbSBmb3IgZXh0ZW5zaW9ucyk6aHR0cDovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC12Mi0yNyNzZWN0aW9uLTIuMw0KDQoxKSBIVFRQIEJh c2ljIEF1dGhlbnRpY2F0aW9uDQoNCjIpIEEgY3VzdG9tIE9BdXRoIGF1dGhlbnRpY2F0aW9uIG1l Y2hhbmlzbSAod2hpY2ggdXNlcyBjbGllbnRfaWQgYW5kIGNsaWVudF9zZWNyZXQpDQoNCldpdGgg SFRUUCBCYXNpYyBhdXRoZW50aWNhdGlvbiB0aGUgcHJvYmxlbSBpcyB0aGF0IHRoaXMgaXMgYSBs ZWdhY3kgdGVjaG5vbG9neSBhbmQgdGhlcmUgaXMgbm8gaW50ZXJuYXRpb25hbGl6YXRpb24gc3Vw cG9ydC4NCg0KV2l0aCBvdXIgYnJhbmQgbmV3IGN1c3RvbSBPQXV0aCBhdXRoZW50aWNhdGlvbiBt ZWNoYW5pc20gd2UgaGF2ZSBtb3JlIG9wdGlvbnMuDQoNCk9uZSBwb3NzaWJsZSBhcHByb2FjaCBp cyB0byBzYXkgdGhhdCB0aGUgY2xpZW50cyBhcmUgZGV2aWNlcyAoYW5kIG5vdCBlbmQgdXNlcnMp IGFuZCB0aGVyZWZvcmUgaW50ZXJuYXRpb25hbGl6YXRpb24gZG9lcyBub3QgbWF0dGVyLg0KDQpJ cyBpdCwgaG93ZXZlciwgcmVhbGx5IHRydWUgdGhhdCBvbmx5IFVTLUFTQ0lJIGNoYXJhY3RlcnMg d2lsbCBhcHBlYXIgaW4gdGhlIGNsaWVudF9pZCBhbmQgYWxzbyBpbiB0aGUgY2xpZW50X3NlY3Jl dD8NCg0KSGVyZSB3ZSBoYXZlIHRoZSBwb3NzaWJpbGl0eSB0byBkZWZpbmUgc29tZXRoaW5nIGJl dHRlci4NCg0KSW4gYW55IGNhc2Ugd2UgaGF2ZSB0byByZXN0cmljdCB0aGUgY2hhcmFjdGVycyB0 aGF0IGFyZSB1c2VkIGluIHRoZXNlIHR3byBhdXRoZW50aWNhdGlvbiBtZWNoYW5pc21zIHNpbmNl IHRoZXkgY291bGQgY29uZmxpY3Qgd2l0aCB0aGUgd2F5IGhvdyB3ZSB0cmFuc3BvcnQgdGhlIGRh dGEgb3ZlciB0aGUgdW5kZXJseWluZyBwcm90b2NvbC4gSnVsaWFuIG1lbnRpb25lZCB0aGlzIGlu IGhpcyBwcmV2aW91cyBtYWlscy4NCg0KSnVsaWFuLCBtYXliZSB5b3UgY2FuIHByb3ZpZGUgYSBk ZXRhaWxlZCB0ZXh0IHByb3Bvc2FsIGZvciBob3cgdG8gYWRkcmVzcyB5b3VyIGNvbW1lbnQgaW4g Y2FzZSB3ZSBnbyBmb3IgVVRGOCAod2l0aCAlIGVuY29kaW5nKSBmb3IgdGhlIGN1c3RvbSBPQXV0 aCBjbGllbnQgYXV0aGVudGljYXRpb24gbWVjaGFuaXNtPw0KDQpDaWFvDQpIYW5uZXMNCg0KT24g SnVuIDEyLCAyMDEyLCBhdCAxMTo1NCBBTSwgSnVsaWFuIFJlc2Noa2Ugd3JvdGU6DQoNCj4gT24g MjAxMi0wNi0xMiAwMDoxNiwgTWlrZSBKb25lcyB3cm90ZToNCj4+IFJldmlld2luZyB0aGUgZmVl ZGJhY2sgZnJvbSBKdWxpYW4sIEpvaG4sIGFuZCBKYW1lcywgSSdtIGNvbWluZyB0byB0aGUgY29u Y2x1c2lvbiB0aGF0IGNsaWVudF9pZCBhbmQgY2xpZW50X3NlY3JldCwgYmVpbmcgZm9yIG1hY2hp bmVzIGFuZCBub3QgaHVtYW5zLCBzaG91IGxkIGJlIEFTQ0lJLCB3aGVyZWFzIHVzZXJuYW1lIGFu ZCBwYXNzd29yZCBzaG91bGQgYmUgVW5pY29kZSwgc2luY2UgdGhleSBhcmUgZm9yIGh1bWFucy4g IFBlciBKb2huJ3MgZmVlZGJhY2ssIGNsaWVudF9pZCBjYW4gbm90IGNvbnRhaW4gYSBjb2xvbiBh bmQgYmUgY29tcGF0aWJsZSB3aXRoIEhUVFAgQmFzaWMuDQo+DQo+IEknbSBub3Qgc3VyZSB0aGF0 IHJlc3RyaWN0aW5nIHRoZSBjaGFyYWN0ZXIgcmVwZXJ0b2lyZSBqdXN0IGJlY2F1c2Ugb25lIHdh eSB0byBzZW5kIHJlcXVpcmVzIHRoaXMgaXMgdGhlIHJpZ2h0IGFwcHJvYWNoLiBNeSBwcmVmZXJl bmNlIHdvdWxkIGJlIG5vdCB0byBwdXQgdGhpcyBpbnRvIHRoZSBBQk5GLCBhbmQganVzdCB0byBw b2ludCBvdXQgdGhhdCBjZXJ0YWluIGNoYXJhY3RlcnMgd2lsbCBub3Qgd29yayBvdmVyIGNlcnRh aW4gdHJhbnNwb3J0cywgYW5kIHRvIGp1c3QgYWR2aXNlIHRvIGF2b2lkIHRoZW0uDQo+DQo+PiBU aGVyZWZvcmUsIEknZCBsaWtlIHRvIHByb3Bvc2UgdGhlc2UgdXBkYXRlZCBBQk5GIGRlZmluaXRp b25zOg0KPj4NCj4+ICAgIFZTQ0hBUiA9ICUyMC03RQ0KPj4gICAgTk9DT0xPTlZTQ0hBUiA9ICV4 MjAtMzkgLyAleDNCLTdFDQo+PiAgICBVTklDT0RFTk9DVFJMQ0hBUiA9IDxBbnkgVW5pY29kZSBj aGFyYWN0ZXIgb3RoZXIgdGhhbiAoICV4MC0xRiAvICV4N0YgKT4NCj4+DQo+PiAgICBjbGllbnQt aWQgPSAqTk9DT0xPTlZTQ0hBUg0KPj4gICAgY2xpZW50X3NlY3JldCA9ICpWU0NIQVINCj4+DQo+ PiAgICB1c2VybmFtZSA9ICpVTklDT0RFTk9DVFJMQ0hBUg0KPj4gICAgcGFzc3dvcmQgPSAqVU5J Q09ERU5PQ1RSTENIQVINCj4NCj4gSW4gdGhpcyBjYXNlIHlvdSBzaG91bGQgYWRkIGFuIGludHJv ZHVjdG9yeSBzdGF0ZW1lbnQgcG9pbnRpbmcgb3V0IHRoYXQgdGhlIEFCTkYgZGVmaW5lcyB0aGUg Z3JhbW1hciBpbiB0ZXJtcyBvZiBVbmljb2RlIGNvZGUgcG9pbnRzLCBub3Qgb2N0ZXRzIChhcyBp dCBpcyB0aGUgY2FzZSBtb3N0IG9mIHRoZSB0aW1lKS4NCj4NCj4+IEl0IHR1cm5zIG91dCB0aGF0 IG5vbi1BU0NJSSBjaGFyYWN0ZXJzIGFyZSBPSyBmb3IgdXNlcm5hbWUgYW5kIHBhc3N3b3JkIGJl Y2F1c2UgdGhlIENvcmUgc3BlYyBvbmx5IHBhc3NlcyB0aGVtIGluIHRoZSBmb3JtIGJvZHkgLSBu b3QgdXNpbmcgSFRUUCBCYXNpYyAtIGFuZCBVVEYtOCBlbmNvZGluZyBpcyBzcGVjaWZpZWQuDQo+ DQo+IEknbGwgc2VuZCBhIHNlcGFyYXRlIG1haWwgYWJvdXQgdGhhdCwgdGhlIGN1cnJlbnQgdGV4 dCBpbiB0aGUgc3BlYyBpcyB3YXkgdG9vIHVuc3BlY2lmaWMuDQo+DQo+PiAgICAgICAgICAgICAg ICAgLS0gTWlrZQ0KPj4NCj4+IFAuUy4gIElmIGFueW9uZSBoYXMgYSBiZXR0ZXIgQUJORiBmb3Ig VU5JQ09ERU5PQ1RSTENIQVIgdGhhbiAiPEFueSBVbmljb2RlIGNoYXJhY3RlciBvdGhlciB0aGFu ICggJXgwLTFGIC8gJXg3RiApPiIsIHBsZWFzZSBzZW5kIGl0IHRvIG1lIQ0KPg0KPiBBcyBub3Rl ZCBiZWZvcmUsIGhlcmUncyBhbiBleGFtcGxlOiA8aHR0cDovL2dyZWVuYnl0ZXMuZGUvdGVjaC93 ZWJkYXYvcmZjNTMyMy5odG1sI3JmYy5zZWN0aW9uLjUuMTUuMT4NCj4NCj4gQmVzdCByZWdhcmRz LCBKdWxpYW4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gT0F1dGggbWFpbGluZyBsaXN0DQo+IE9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBp ZXRmLm9yZz4NCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGgg bWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9B dXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KVGhpcyBtZXNzYWdlIGFuZCBhbnkgYXR0YWNobWVu dCBhcmUgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgYWRkcmVzc2VlIGFuZCBtYXkgY29udGFpbiBj b25maWRlbnRpYWwgaW5mb3JtYXRpb24uIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgbWVzc2Fn ZSBpbiBlcnJvciwgcGxlYXNlIHNlbmQgaXQgYmFjayB0byBtZSwgYW5kIGltbWVkaWF0ZWx5IGRl bGV0ZSBpdC4gUGxlYXNlIGRvIG5vdCB1c2UsIGNvcHkgb3IgZGlzY2xvc2UgdGhlIGluZm9ybWF0 aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1lc3NhZ2Ugb3IgaW4gYW55IGF0dGFjaG1lbnQuIEFueSB2 aWV3cyBvciBvcGluaW9ucyBleHByZXNzZWQgYnkgdGhlIGF1dGhvciBvZiB0aGlzIGVtYWlsIGRv IG5vdCBuZWNlc3NhcmlseSByZWZsZWN0IHRoZSB2aWV3cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBO b3R0aW5naGFtLg0KDQpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gY2hlY2tlZCBmb3IgdmlydXNlcyBi dXQgdGhlIGNvbnRlbnRzIG9mIGFuIGF0dGFjaG1lbnQgbWF5IHN0aWxsIGNvbnRhaW4gc29mdHdh cmUgdmlydXNlcyB3aGljaCBjb3VsZCBkYW1hZ2UgeW91ciBjb21wdXRlciBzeXN0ZW06IHlvdSBh cmUgYWR2aXNlZCB0byBwZXJmb3JtIHlvdXIgb3duIGNoZWNrcy4gRW1haWwgY29tbXVuaWNhdGlv bnMgd2l0aCB0aGUgVW5pdmVyc2l0eSBvZiBOb3R0aW5naGFtIG1heSBiZSBtb25pdG9yZWQgYXMg cGVybWl0dGVkIGJ5IFVLIGxlZ2lzbGF0aW9uLg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8 bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9vYXV0aA0KDQo= --_000_4E1F6AAD24975D4BA5B168042967394366539292TK5EX14MBXC284r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPGJhc2Ug aHJlZj0ieC1tc2c6Ly80MDMvIj48IS0tW2lmICFtc29dPjxzdHlsZT52XDoqIHtiZWhhdmlvcjp1 cmwoI2RlZmF1bHQjVk1MKTt9DQpvXDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQp3 XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQouc2hhcGUge2JlaGF2aW9yOnVybCgj ZGVmYXVsdCNWTUwpO30NCjwvc3R5bGU+PCFbZW5kaWZdLS0+PHN0eWxlPjwhLS0NCi8qIEZvbnQg RGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5v c2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRh aG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0 aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJn aW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5 cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dl ZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdp bi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNl dGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls ZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5z LXNlcmlmIjt9DQpzcGFuLmFwcGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFtZTph cHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsN Cgljb2xvcjojMUY0OTdEO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1l OiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls ZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlm Ijt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250 LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsN CgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9 ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFu Zz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNl Y3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5UaGUgbW9yZSBJIHRoaW5rIGFib3V0IGV4Y2x1ZGluZyB0aGUgcG9z c2liaWxpdHkgb2YgdXNpbmcgVVJJcyBhcyBjbGllbnQgSURzLCB0aGUgbW9yZSB1bmNvbWZvcnRh YmxlIEkgYW0gd2l0aCBpdC4mbmJzcDsgSeKAmW0gaW5jcmVhc2luZ2x5IHRoaW5raW5nIHRoYXQg d2Ugc2hvdWxkDQogYWxsb3cgdGhlIEFTQ0lJIGNoYXJhY3RlcnMgdXNlZCBpbiBVUklzIChhbmQg cHJvYmFibHkgdGhlIG90aGVyIHZpc2libGUgb25lcyBhbmQgc3BhY2UgYXMgd2VsbCwgYXMgY3Vy cmVudGx5IHByb3Bvc2VkKSBhbmQgaGF2ZSBzcGVjaWFsIGxhbmd1YWdlIGFib3V0IOKAnEJ1dCB3 aGF0IGlmIHRoaXMgY2xpZW50X2lkIGNvbnRhaW5pbmcgY29sb24gY2hhcmFjdGVycyBpcyB0byBi ZSB1c2VkIHdpdGggSFRUUCBCYXNpYz/igJ08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFzIG9uZSBzdWdnZXN0aW9uLCBt YWlubHkgdG8gcmVzdGFydCBkaXNjdXNzaW9uICh3aGljaCBzZWVtcyB0byBoYXZlIHN0YWxsZWQp LCB3ZSBjb3VsZCBzdWdnZXN0IChvciByZXF1aXJlKSB0aGF0IGFsbCBjb2xvbiBjaGFyYWN0ZXJz IGluIGNsaWVudF9pZHMgYmUgc3Vic3RpdHV0ZWQNCiB3aXRoIHRhYiBjaGFyYWN0ZXJzICgleDA5 KSwgd2hpY2ggYXJlIGxlZ2FsIGluIEhUVFAgQmFzaWMgYnV0IG5vdCBpbiB0aGUgcHJvcG9zZWQg ZGVmaW5pdGlvbiBvZiBjbGllbnRfaWRzLCBiZWZvcmUgdXNlIHdpdGggSFRUUCBCYXNpYywgYW5k IHRoYXQgdGhlIHJldmVyc2Ugc3Vic3RpdHV0aW9uIG9jY3VyIHdoZW4gcmVjZWl2ZWQgZnJvbSBI VFRQIEJhc2ljLiZuYnNwOyBPdGhlciB0cmFuc2Zvcm1hdGlvbnMgb3IgZW5jb2RpbmdzIGFyZSBw b3NzaWJsZS4mbmJzcDsNCiBXZSBjb3VsZCBhbHNvIGNvcCBvdXQgYnkgc2F5aW5nIHNvbWV0aGlu ZyBsaWtlIOKAnElmIGNoYXJhY3RlcnMgbm90IGxlZ2FsIGluIEhUVFAgQmFzaWMgb2NjdXIgaW4g dGhlIGNsaWVudF9pZCwgYSB0cmFuc2Zvcm1hdGlvbiBlbmNvZGluZyB0aGVtIG11c3QgYmUgYWdy ZWVkIHRvIGJ5IGJvdGggcGFydGllc+KAnS4mbmJzcDsgSSBkb27igJl0IGxvdmUgdGhlIHRhYiBp ZGVhLCBiZWNhdXNlIGl04oCZcyBhZG1pdHRlZGx5IGEgaGFjaywgYnV0IEkgYmVsaWV2ZSBpdOKA mXMNCiBiZXR0ZXIgdGhhbiBwcmVjbHVkaW5nIHRoZSB1c2Ugb2YgVVJJcyBhcyBjbGllbnRfaWRz LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+VGhvdWdodHM/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu MHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+IG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpvYXV0aC1ib3Vu Y2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5Kb2huIEJyYWRsZXk8YnI+DQo8Yj5T ZW50OjwvYj4gV2VkbmVzZGF5LCBKdW5lIDEzLCAyMDEyIDExOjQwIEFNPGJyPg0KPGI+VG86PC9i PiBUb3JzdGVuIExvZGRlcnN0ZWR0PGJyPg0KPGI+Q2M6PC9iPiBKdWxpYW4gUmVzY2hrZTsgUmlj aGFyZCBNb3J0aWVyOyBvYXV0aEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09B VVRILVdHXSBEeW5hbWljIGNsaWVudHMsIFVSSSwgYW5kIHN0dWZmIFJlOiBEaXNjdXNzaW9uIG5l ZWRlZCBvbiB1c2VybmFtZSBhbmQgcGFzc3dvcmQgQUJORiBkZWZpbml0aW9uczxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGF0IHdvdWxkIHBy b2JhYmx5IHdvcmsgYXMgd2VsbC4gJm5ic3A7VGhhdCBpcyB3aHkgSSBhbSBub3QgcGFydGljdWxh cmx5IGNvbmNlcm5lZCBhYm91dCBleGNsdWRpbmcgdGhlIDombmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2Ugb3JpZ2luYWxseSB1c2Vk IHRoZSBVUkkgaXRzZWxmLCAmbmJzcDttb3N0bHkgZm9yIGNvbnZlbmllbmNlIG9mIGRlYnVnZ2lu ZywgJm5ic3A7YnV0IHRoZXJlIGFyZSBvdGhlciBwb3RlbnRpYWwgb3B0aW9ucy4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGF1 dGhvcml6YXRpb24gc2VydmVyIG5lZWRzIHRvIGNvbXBhcmUgdGhlIGNsaWVudF9pZCBhbmQgdGhl IHJlZGlyZWN0IHVyaS4gQnV0IGl0IGNvdWxkIGNvbXBhcmUgdGhlIGhhc2ggd2l0aCBub3QgbXVj aCBtb3JlIHdvcmsuICZuYnNwOyBBbHNvIGEgc2hhMjU2IGhhc2ggaXMgcHJvYmFibHkgbG9uZ2Vy IHRoYW4gdGhlIHVyaSBpdCBpcyBoYXNoaW5nLiAmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBhbSBub3Qgc3VwZXIgY29uY2VybmVk IHdpdGggYmVpbmcgYWJsZSB0byBoYXZlIDogaW4gdGhlIGNsaWVudF9pZDxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Kb2huIEIuJm5ic3A7PGJy Pg0KPGJyPg0KU2VudCBmcm9tIG15IGlQaG9uZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+ DQpPbiAyMDEyLTA2LTEzLCBhdCA2OjAzIFBNLCBUb3JzdGVuIExvZGRlcnN0ZWR0ICZsdDs8YSBo cmVmPSJtYWlsdG86dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQiPnRvcnN0ZW5AbG9kZGVyc3RlZHQu bmV0PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+SGkgSm9obiw8YnI+ DQo8YnI+DQp3b3VsZCBpdCBtYWtlIHNlbnNlIHRvIHVzZSBhIGhhc2ggb2YgdGhlIFVSSSBpbnN0 ZWFkIG9mIHRoZSBVUkkgaXRzZWxmIGluIHlvdXIgdXNlIGNhc2U/PGJyPg0KPGJyPg0KcmVnYXJk cyw8YnI+DQpUb3JzdGVuLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxicj4NCjxicj4NCkpvaG4gQnJhZGxleSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnZlN2p0YkB2 ZTdqdGIuY29tIj52ZTdqdGJAdmU3anRiLmNvbTwvYT4mZ3Q7IHNjaHJpZWI6PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5rIHRoYXQgdGhlIGlzc3VlcyBhcmUgZ2V0 dGluZyBjb25mdXNlZC48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlRoZXJlIGlzIGEgdXNlIGNhc2Ugd2hlcmUgdGhlIEF1dGhvcml6YXRpb24gc2VydmVyIG1h eSBiZSBhIGVtYmVkZGVkIGFwcCwgYXQgbGVhc3QgaW4gb25lIG9wZW5JRCBjYXNlLiAmbmJzcDsg Jm5ic3A7QXMgaXQgd29uJ3QgaGF2ZSBhIHNlcGFyYXRlIHJlZ2lzdHJhdGlvbiBvciB0b2tlbiBl bmRwb2ludCwgJm5ic3A7dGhlIGNsaWVudCBuZWVkcyB0byBtYWtlIGl0cyBvd24gY2xpZW50SUQg Zm9yIHRoZSByZXF1ZXN0LiAmbmJzcDsgQSByZWFzb25hYmxlDQogdGhpbmcgdG8gdXNlIGlzIHRo ZSByZWRpcmVjdCBVUkkgdG8gY3JlYXRlIGEgdW5pcXVlIHZhbHVlIHRoYXQgdGhlIHVzZXIgY291 bGQgdXNlIGZvciByZXZvY2F0aW9uIGF0IGEgbGF0ZXIgcG9pbnQuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkN1cnJlbnRseSB3aXRoIHRoZSBu byA6IHJlc3RyaWN0aW9uIHdlIHdvdWxkIHVzZSB0aGUgaG9zdCBhbmQgcGF0aCB0byBjcmF0ZSB0 aGUgY2xpZW50aWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5UaGVyZSBhcmUgc29tZSBzY2VuYXJpb3Mgd2hlcmUgaGF2aW5nIHRoZSBzY2hlbWUg YXMgcGFydCBvZiB0aGF0IHdvdWxkIGJlIGhlbHBmdWwuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgaGFzIG5vdGhpbmcgdG8gZG8gd2l0 aCBkaXNjb3Zlcnkgb3IgdGhlIGR5bmFtaWMgY2xpZW50IHJlZ2lzdHJhdGlvbiBwcm9wb3NhbCBh cyBmYXIgYXMgSSBrbm93LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5BIFVSTCBhcyBhIGNsaWVudF9pZCBjb21lcyBmcm9tIHByb3RvdHlwZSB3 b3JrIGZvciBhIHBlcnNvbmFsIHByb3ZpZGVyIHRoYXQgd2UgYXJlIGRvaW5nIGFzIHBhcnQgb2Yg b3BlbklEIENvbm5lY3QuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkpvaG4gQi48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+T24gMjAxMi0wNi0xMywgYXQgNzo1MCBBTSwgVG9yc3RlbiBMb2RkZXJz dGVkdCB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5IaSBhbGwsPGJyPg0KPGJyPg0KY2FuIGFueW9u ZSBwbGVhc2UgZXhwbGFpbiB0aGUgcmVsYXRpb24gYmV0d2VlbiBkeW5hbWljIGNsaWVudCByZWdp c3RyYXRpb24gYW5kIFVSSXMgYXMgY2xpZW50IGlkcz8gTm9uZSBvZiB0aGUgY3VycmVudCBkcmFm dHMgKHVtYSBvciBjb25uZWN0KSBzZWVtIHRvIHJlcXVpcmUgVVJJcy48YnI+DQo8YnI+DQpyZWdh cmRzLDxicj4NClRvcnN0ZW4uPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGJyPg0KPGJyPg0KSmlhbmh1YSBTaGFvICZsdDs8YSBocmVmPSJtYWlsdG86cHN4anM0 QG5vdHRpbmdoYW0uYWMudWsiPnBzeGpzNEBub3R0aW5naGFtLmFjLnVrPC9hPiZndDsgc2Nocmll Yjo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IZWxsbyw8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RHluYW1p YyBjbGllbnQgcmVnaXN0cmF0aW9uIGlzIHZlcnkgdXNlZnVsIGlmIGNsaWVudCBvciByZXNvdXJj ZSBvciBhdXRob3Jpc2F0aW9uIHNlcnZlciBpcyBub3QgcGVybWFuZW50bHkgYXZhaWxhYmxlLiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ QSB0eXBpY2FsIGNhc2UgaXMgdGhhdCBpcyB0aGUgcmVzb3VyY2Ugb3IgYXV0aG9yaXNhdGlvbiBz ZXJ2ZXIgaXMgaW4gbW9iaWxlIHBsYXRmb3JtLCB0aGUgY29ubmVjdGlvbiBpcyBub3QgYWx3YXlz IGF2YWlsYWJsZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkFub3RoZXIgdHlwaWNhbCBjYXNlIGlzIHRoYXQgYXV0aG9yaXNhdGlvbiBz ZXJ2ZXIgZG8gbm90IG5lY2Vzc2FyeSB0byBoYXZlIGNsaWVudCBwcmUtcmVnaXN0ZXJlZCBvbiBp dHNlbGYuIEF0IG1vbWVudCwgaW5kdXN0cnkgbGlrZSBmYWNlYm9vayB3b3VsZCBsaWtlIGRldmVs b3BlciB0byByZWdpc3RlciBhIGFwcCBvbiBpdHMgYXBwIGNlbnRyZSBmaXJzdCwgYW5kIHRoZW4g YXNrIHVzZXIgYXV0aCB0byB1c2UNCiB0aGUgYXBwLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XZSBhcmUgcmVzZWFyY2hlcnMgZnJv bSBEaWdpdGFsIEVjb25vbXkgUmVzZWFyY2ggSW5zdGl0dXRlLiBXZSBoYXZlIHRoaXMgcHJvYmxl bSBXaGVuIHdlIGRldmVsb3BpbmcgRGF0YXdhcmUgdGhhdCBjb3VsZCBtYW5hZ2UgdGhlIGNvbnRy b2wgb2YgYWNjZXNzIHRvIHBlcnNvbmFsIGRhdGEuIFdlIHBsYXkgYXJvdW5kIG91ciBzb2x1dGlv biBiYXNlIG9uIE9hdXRoMjombmJzcDs8YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vamlhbmh1 YXNoYW8vZGF0YXdhcmUuY2F0YWxvZy93aWtpIj5odHRwczovL2dpdGh1Yi5jb20vamlhbmh1YXNo YW8vZGF0YXdhcmUuY2F0YWxvZy93aWtpPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XZSBhcmUgaW4gdGhlIGxpc3QgdG8gcmVjZWl2ZSB5 b3VyIG1haWwgbGlzdCwgYnV0IGN1cnJlbnRseSBuZWVkIG1vZGVyYXRlIHRvIHBvc3QgYW55IG1l c3NhZ2UuIGNjIG15IGNvbGxlYWd1ZSwgUmljaGFyZCBNb3J0aWVyPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CZXN0PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5KaWFuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDEyIEp1biAyMDEyLCBhdCAyMTowOCwg RXJhbiBIYW1tZXIgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ VGhlIG9ubHkgZGlzdGluY3Rpb24gSSB3b3VsZCBtYWtlIGlzIGJldHdlZW4gcmVtb3ZpbmcgZmxl eGliaWxpeSB0byBwcm9hY3RpdmVseSBlbmFibGluZyBmdXR1cmUgZXh0ZW5zaWJpbGl0eS4gSSB3 b3VsZCBzdG9wIHNob3J0IG9mIHBlcnNjcmliaW5nIGVuY29kaW5nIGluDQogb3JkZXIgdG8gZml0 IHVyaSBpbnRvIHRoZSBCYXNpYyBhdXRoIGZpZWxkcy4gQnV0IGlmIHRoZXJlIGlzIGEgd2F5IHRv IGFsbG93IHRoaXMgdG8gYmUgbGVzcyByZXN0cmljdGl2ZSB3aXRob3V0IGNsZWFuIGludGVyb3Ag aXNzdWVzLCB0aGF0IHdvdWxkIGJlIG5pY2UuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5JIGRvIGFncmVlIHdlIG5lZWQgc29tZSBhY3R1YWwgdXNlIGNhc2VzIGJlZm9y ZSB3ZSBzcGVuZCBtdWNoIG1vcmUgdGltZSBvbiB0aGlzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+RUg8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBp biAwaW4gNC4wcHQ7Ym9yZGVyLXdpZHRoOmluaXRpYWw7Ym9yZGVyLWNvbG9yOmluaXRpYWwiPg0K PGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAx LjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluO2JvcmRlci13aWR0aDppbml0aWFsO2JvcmRl ci1jb2xvcjppbml0aWFsIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+ PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5XaWxsaWFtDQogTWlsbHMgPGEgaHJl Zj0ibWFpbHRvOlttYWlsdG86d21pbGxzQHlhaG9vLWluYy5jb21dIj5bbWFpbHRvOndtaWxsc0B5 YWhvby1pbmMuY29tXTwvYT48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+PGJyPg0KPGI+U2VudDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPlR1ZXNkYXksIEp1bmUgMTIsIDIwMTIgMTowNCBQTTxicj4NCjxi PlRvOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ RXJhbiBIYW1tZXI7IE1pa2UgSm9uZXM7IEhhbm5lcyBUc2Nob2ZlbmlnOyBKdWxpYW4gUmVzY2hr ZTxicj4NCjxiPkNjOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIj5vYXV0aEBpZXRmLm9yZzwv YT48YnI+DQo8Yj5TdWJqZWN0OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+RHluYW1pYyBjbGllbnRzLCBVUkksIGFuZCBzdHVmZiBSZTogW09BVVRI LVdHXSBEaXNjdXNzaW9uIG5lZWRlZCBvbiB1c2VybmFtZSBhbmQgcGFzc3dvcmQgQUJORiBkZWZp bml0aW9uczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91 bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTQuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5JIHRoaW5rIGR5bmFtaWMgY2xpZW50IHJl Z2lzdHJhdGlvbiBpcyBzb21ldGhpbmcgd2UgaGF2ZSBub3QgdGFsa2VkIG91dCBlbm91Z2ggeWV0 LiZuYnNwOyBUaGVyZSdzIGEgcHJldHR5IGNsZWFyIHVzZSBjYXNlIGZvciBkeW5hbWljIHJlZ2lz dHJhdGlvbi4mbmJzcDsmbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3 aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+RG9lcyBpZGVudGlmeWlu ZyB0aGUgY2xpZW50IHdpdGggYSBVUkkgYWxsb3cgc29tZSBmb3JtIG9mIE9wZW5JRC1pc2ggZmxv dyBmb3IgdGhpcz8mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPklzIHRoZSBjbGllbnQgSUQgYXMgYSBVUkkgYSB3YXkg dG8gYWxsb3cgYSB0cnVzdGVkIHNpdGUgdG8gcHJvdmlkZSBtZXRhZGF0YSBhYm91dCB0aGUgY2xp ZW50Pzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjE0LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjpibGFjayI+SXMgdGhhdCBVUkkgYSB3YXkgdG8gaGl0IGFuIElEUCB3ZSB0cnVzdCB0byB2 YWxpZGF0ZSB0aGUgY2xpZW50IGluIHNvbWUgd2F5IHdpdGggdGhlIHByb3ZpZGVkIHNlY3JldD88 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxNC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6 YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjpibGFjayI+SSBndWVzcyB3aGF0IEknbSBsb29raW5nIGZvciBoZXJlIGlz IGEgY29uY3JldGUgdXNlIGNhc2UvcHJvYmxlbSB0byBzb2x2ZSwgcmF0aGVyIHRoZW4gbGVhdmlu ZyBhIGhvb2sgd2UgdGhpbmsgaXMgdGhlIHJpZ2h0IHRoaW5nLjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTQuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNr Ij4tYmlsbDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjE0LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgIzEwMTBGRiAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0O21hcmdpbi1sZWZ0OjMu NzVwdDttYXJnaW4tdG9wOjMuNzVwdDttYXJnaW4tYm90dG9tOjUuMHB0O2JvcmRlci13aWR0aDpp bml0aWFsO2JvcmRlci1jb2xvcjppbml0aWFsIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBj bGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXI7 YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNr Ij4NCjxociBzaXplPSIxIiB3aWR0aD0iMTAwJSIgYWxpZ249ImNlbnRlciI+DQo8L3NwYW4+PC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkZyb206PC9zcGFuPjwv Yj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPkVyYW4NCiBIYW1tZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpl cmFuQGh1ZW5pdmVyc2UuY29tIj5lcmFuQGh1ZW5pdmVyc2UuY29tPC9hPiZndDs8YnI+DQo8Yj5U bzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPk1p a2UgSm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20i Pk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7OyBXaWxsaWFtIE1pbGxzICZsdDs8 YSBocmVmPSJtYWlsdG86d21pbGxzQHlhaG9vLWluYy5jb20iPndtaWxsc0B5YWhvby1pbmMuY29t PC9hPiZndDs7IEhhbm5lcyBUc2Nob2ZlbmlnICZsdDs8YSBocmVmPSJtYWlsdG86aGFubmVzLnRz Y2hvZmVuaWdAZ214Lm5ldCI+aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldDwvYT4mZ3Q7Ow0KIEp1 bGlhbiBSZXNjaGtlICZsdDs8YSBocmVmPSJtYWlsdG86anVsaWFuLnJlc2Noa2VAZ214LmRlIj5q dWxpYW4ucmVzY2hrZUBnbXguZGU8L2E+Jmd0OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQo8Yj5DYzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPiZxdW90OzxhIGhyZWY9Im1haWx0bzpvYXV0aEBp ZXRmLm9yZyI+b2F1dGhAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86b2F1 dGhAaWV0Zi5vcmciPm9hdXRoQGlldGYub3JnPC9hPiZndDs8c3BhbiBjbGFzcz0iYXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KPGI+U2VudDo8L2I+PHNwYW4gY2xhc3M9 ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlR1ZXNkYXksIEp1bmUgMTIsIDIw MTIgMTE6MzkgQU08YnI+DQo8Yj5TdWJqZWN0OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+UkU6IFtPQVVUSC1XR10gRGlzY3Vzc2lvbiBuZWVkZWQg b24gdXNlcm5hbWUgYW5kIHBhc3N3b3JkIEFCTkYgZGVmaW5pdGlvbnM8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ieWl2MTQxODE2ODUzIj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dy b3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+ SXMgdGhlIHVzZSBjYXNlIG9mIHVzaW5nIFVSSSBhcyBjbGllbnQgaWRzIGltcG9ydGFudD8gSXQg c2VlbXMgbGlrZSBzb21ldGhpbmcgdGhhdCBtaWdodCBiZWNvbWUgdXNlZnVsIGluIHRoZSBmdXR1 cmUgd2hlcmUgY2xpZW50cyBjYW4gdXNlIHRoZWlyIHZlcmlmaWFibGUgc2VydmVycyB0bw0KIGJ5 cGFzcyBjbGllbnQgcmVnaXN0cmF0aW9uIGFuZCBzaW1seSB1c2UgYSBVUkkgdGhlIHNlcnZlciBj YW4gdmFsaWRhdGUgdmlhIHNvbWUgb3RoZXIgbWVhbnMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMx RjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj5JIGp1c3Qgd2FudCB0 byBtYWtlIHN1cmUgdGhvc2UgdGhpbmtpbmcgYWJvdXQgbW9yZSBjb21wbGV4IHVzZSBjYXNlcyBp bnZvbHZpbmcgZHluYW1pYyByZWdpc3RyYXRpb24gb3IgZGlzdHJpIGJ1dGVkIGNsaWVudCBtYW5h bWdlbmV0IGFyZSBhd2FyZSBvZiB0aGlzIHBvdGVudGlhbCByZXN0cmljdGlvbi48L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0Qi PkknbSBmaW5lIGVpdGhlciB3YXkuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj5FSDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjoj MUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5n OjBpbiAwaW4gMGluIDQuMHB0O2JvcmRlci13aWR0aDppbml0aWFsO2JvcmRlci1jb2xvcjppbml0 aWFsIj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNC NUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbjtib3JkZXItd2lkdGg6aW5pdGlh bDtib3JkZXItY29sb3I6aW5pdGlhbCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtjb2xvcjpibGFjayI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrIj4m bmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOmJs YWNrIj48YSBocmVmPSJtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyI+b2F1dGgtYm91bmNl c0BpZXRmLm9yZzwvYT48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+PGEgaHJlZj0ibWFpbHRvOlttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10iPltt YWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ108L2E+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiPk9uDQogQmVoYWxmIE9mPHNwYW4gY2xhc3M9ImFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5NaWtlIEpvbmVzPGJyPg0KPGI+ U2VudDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu PlR1ZXNkYXksIEp1bmUgMTIsIDIwMTIgMTE6MjcgQU08YnI+DQo8Yj5Ubzo8L2I+PHNwYW4gY2xh c3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPldpbGxpYW0gTWlsbHM7IEhh bm5lcyBUc2Nob2ZlbmlnOyBKdWxpYW4gUmVzY2hrZTxicj4NCjxiPkNjOjwvYj48c3BhbiBjbGFz cz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOm9h dXRoQGlldGYub3JnIj5vYXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj48c3Bh biBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+UmU6IFtPQVVUSC1X R10gRGlzY3Vzc2lvbiBuZWVkZWQgb24gdXNlcm5hbWUgYW5kIHBhc3N3b3JkIEFCTkYgZGVmaW5p dGlvbnM8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Nv bG9yOiMxRjQ5N0QiPk5vdCBpbnRlcm5hdGlvbmFsaXppbmcgZmllbGRzIGludGVuZGVkIGZvciBt YWNoaW5lIGNvbnN1bXB0aW9uIG9ubHkgaXMgYWxyZWFkeSBhIHByZWNlZGVudCBzZXQgYW5kIGFn cmVlZCB0byBieSB0aGUgd29ya2luZyBncm91cCwgc28gbGV0IG1lIHNlY29uZCBCaWxs4oCZcyBw b2ludCBpbiB0aGF0DQogcmVnYXJkLiZuYnNwOyBGb3IgaW5zdGFuY2UsIG5laXRoZXIg4oCcc2Nv cGXigJ0gbm9yIOKAnGVycm9y4oCdIGFsbG93IG5vbi1BU0NJSSBjaGFyYWN0ZXJzLjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFj a2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3 RCI+SnVsaWFuLCBpZiB5b3Ugd2FudCBkaWZmZXJlbnQgQUJORiB0ZXh0IHRoYW4gdGhlIHRleHQg SSB3cm90ZSBiZWxvdywgSSBiZWxpZXZlIGl0IHdvdWxkIGJlIG1vc3QgdXNlZnVsIGlmIHlvdSB3 b3VsZCBwcm92aWRlIHRoZSBleGFjdCByZXBsYWNlIHdvcmRpbmcgdGhhdCB5b3XigJlkIGxpa2UN CiB0byBzZWUgaW5zdGVhZCBvZiBpdC4mbmJzcDsgVGhlbiB0aGVyZeKAmXMgbm8gcG9zc2liaWxp dHkgb2YgbWlzdW5kZXJzdGFuZGluZyB0aGUgaW50ZW50IG9mIHN1Z2dlc3RlZCBjaGFuZ2VzLjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoYW5rcyBhbGwsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMx RjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRp bmc6My4wcHQgMGluIDBpbiAwaW47Ym9yZGVyLXJpZ2h0LXMNCiB0eWxlOg0Kbm9uZTtib3JkZXIt d2lkdGg6aW5pdGlhbDtib3JkZXItY29sb3I6aW5pdGlhbCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFjayI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGNsYXNz PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Nv bG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2NvbG9yOmJsYWNrIj48YSBocmVmPSJtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+PHNwYW4gY2xhc3M9ImFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpbbWFpbHRv Om9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIiB0YXJnZXQ9Il9ibGFuayI+W21haWx0bzpvYXV0aC1i b3VuY2VzQGlldGYub3JnXTwvYT48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+PGI+T24NCiBCZWhhbGYgT2Y8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVk LXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPldpbGxpYW0gTWlsbHM8YnI+DQo8Yj5TZW50OjwvYj48 c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+VHVlc2RheSwg SnVuZSAxMiwgMjAxMiAxMToxOCBBTTxicj4NCjxiPlRvOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+SGFubmVzIFRzY2hvZmVuaWc7IEp1bGlhbiBS ZXNjaGtlPGJyPg0KPGI+Q2M6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj5vYXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj48c3BhbiBjbGFzcz0i YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+UmU6IFtPQVVUSC1XR10gRGlzY3Vz c2lvbiBuZWVkZWQgb24gdXNlcm5hbWUgYW5kIHBhc3N3b3JkIEFCTkYgZGVmaW5pdGlvbnM8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNC4w cHQ7Y29sb3I6YmxhY2siPkkgYWdyZWUgZ2VuZXJhbGx5IHdpdGggeW91ciBhc3N1bXB0aW9uIGFi b3V0IGNsaWVudHMsIGJ1dCByYXRoZXIgdGhhbiBzYXlpbmcgJnF1b3Q7Y2xpZW50cyBhcmUgZGV2 aWNlcyZxdW90OyBJIHRoaW5rIGl0IG1ha2VzIG11Y2ggbW9yZSBzZW5zZSB0byBzYXkgJnF1b3Q7 Y2xpZW50cyBhcmUgTk9UIHVzZXJzLCBzbyBjbGllbnRfaWQNCiBuZWVkIG5vdCBiZSBpbnRlcm5h dGlvbmFsaXplZCZxdW90Oy4mbmJzcDsgSW4gcHJhY3RpY2FsIHRlcm1zIHRoZXJlIGlzIHZlcnkg bGl0dGxlIHRvIGFyZ3VlIGZvciBhbnl0aGlnbiBiZXlvbmQgQVNDSUkgaW4gYSBjbGllbnRfc2Vj cmV0LCBiYXNlNjQgZW5jb2Rpbmcgb3IgdGhlIGVxdWl2YWxlbnQgYmVpbmcgYSBmaW5lIHdheSB0 byB0cmFuc3BvcnQgYXJiaXRyYXJ5IGJpdHMgaW4gYSBwb3J0YWJsZS9yZWFzb25hYmxlIHdheS48 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjE0LjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTQuMHB0O2NvbG9yOmJsYWNrIj5JIGFyZ3VlIHRoYXQgY2xpZW50X2lkIG5lZWQg bm90IGJlIGludGVybmF0aW9uYWxpemVkIGJlY2F1c2UgSSBhc3N1bWUgdGhhdCBhbnkgcmVhbGx5 IGludGVybmF0aW9uYWxpemVkIGFwcGxpY2F0aW9uIHdpbGwgaGF2ZSBhbiBpbnRlcm5hdGlvbmFs aXplZCBwcmVzZW50YXRpb24gbGF5ZXIgdGhhdCdzDQogcHJlc2VudGluZyBhIHByZXR0eSBuYW1l IGZvciB0aGUgY2xpZW50X2lkLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdDtjb2xvcjpi bGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTQuMHB0O2NvbG9yOmJsYWNrIj4t YmlsbDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJtYXJnaW4tYm90dG9tOjE0LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTQuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGln bj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3aGl0ZSI+DQo8 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFjayI+DQo8aHIgc2l6ZT0iMSIg d2lkdGg9IjEwMCUiIGFsaWduPSJjZW50ZXIiPg0KPC9zcGFuPjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2siPkZyb206PC9zcGFuPjwvYj48c3Bh biBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtjb2xvcjpibGFjayI+SGFubmVzIFRzY2hvZmVuaWcNCiAmbHQ7PGEgaHJlZj0i bWFpbHRvOmhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQiIHRhcmdldD0iX2JsYW5rIj5oYW5uZXMu dHNjaG9mZW5pZ0BnbXgubmV0PC9hPiZndDs8YnI+DQo8Yj5Ubzo8L2I+PHNwYW4gY2xhc3M9ImFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPkp1bGlhbiBSZXNjaGtlICZsdDs8YSBo cmVmPSJtYWlsdG86anVsaWFuLnJlc2Noa2VAZ214LmRlIiB0YXJnZXQ9Il9ibGFuayI+anVsaWFu LnJlc2Noa2VAZ214LmRlPC9hPiZndDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+PGJyPg0KPGI+Q2M6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj4mcXVvdDs8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5vYXV0aEBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9 Im1haWx0bzpvYXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9hdXRoQGlldGYub3JnPC9h PiZndDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJy Pg0KPGI+U2VudDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPlR1ZXNkYXksIEp1bmUgMTIsIDIwMTIgMTE6MDEgQU08YnI+DQo8Yj5TdWJqZWN0Ojwv Yj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+UmU6IFtP QVVUSC1XR10gRGlzY3Vzc2lvbiBuZWVkZWQgb24gdXNlcm5hbWUgYW5kIHBhc3N3b3JkIEFCTkYg ZGVmaW5pdGlvbnM8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+PGJyPg0KSSBoYWQgYSBjaGF0IHdpdGggSnVsaWFuIHllc3RlcmRheSBhbmQgaGVyZSBpcyBt eSBzaG9ydCBzdW1tYXJ5LjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj48YnI+DQo8YnI+DQpTZWN0aW9uIDIuMyBvZiB0aGUgY29yZSBkcmFmdCBkZWZpbmVz IGNsaWVudCBhdXRoZW50aWNhdGlvbiBiYXNlZCBvbiB0d28gbWVjaGFuaXNtcyAoYW5kIHByb3Zp ZGVzIHJvb20gZm9yIGV4dGVuc2lvbnMpOjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWlldGYtb2F1dGgtdjItMjcjc2VjdGlvbi0yLjMiPmh0dHA6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtdjItMjcjc2VjdGlvbi0yLjM8L2E+PGJyPg0KPGJy Pg0KMSkgSFRUUCBCYXNpYyBBdXRoZW50aWNhdGlvbjxicj4NCjxicj4NCjIpIEEgY3VzdG9tIE9B dXRoIGF1dGhlbnRpY2F0aW9uIG1lY2hhbmlzbSAod2hpY2ggdXNlcyBjbGllbnRfaWQgYW5kIGNs aWVudF9zZWNyZXQpPGJyPg0KPGJyPg0KV2l0aCBIVFRQIEJhc2ljIGF1dGhlbnRpY2F0aW9uIHRo ZSBwcm9ibGVtIGlzIHRoYXQgdGhpcyBpcyBhIGxlZ2FjeSB0ZWNobm9sb2d5IGFuZCB0aGVyZSBp cyBubyBpbnRlcm5hdGlvbmFsaXphdGlvbiBzdXBwb3J0LjxzcGFuIGNsYXNzPSJhcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQo8YnI+DQpXaXRoIG91ciBicmFuZCBuZXcg Y3VzdG9tIE9BdXRoIGF1dGhlbnRpY2F0aW9uIG1lY2hhbmlzbSB3ZSBoYXZlIG1vcmUgb3B0aW9u cy48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0K PGJyPg0KT25lIHBvc3NpYmxlIGFwcHJvYWNoIGlzIHRvIHNheSB0aGF0IHRoZSBjbGllbnRzIGFy ZSBkZXZpY2VzIChhbmQgbm90IGVuZCB1c2VycykgYW5kIHRoZXJlZm9yZSBpbnRlcm5hdGlvbmFs aXphdGlvbiBkb2VzIG5vdCBtYXR0ZXIuPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPjxicj4NCjxicj4NCklzIGl0LCBob3dldmVyLCByZWFsbHkgdHJ1ZSB0 aGF0IG9ubHkgVVMtQVNDSUkgY2hhcmFjdGVycyB3aWxsIGFwcGVhciBpbiB0aGUgY2xpZW50X2lk IGFuZCBhbHNvIGluIHRoZSBjbGllbnRfc2VjcmV0PzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQo8YnI+DQpIZXJlIHdlIGhhdmUgdGhlIHBvc3Np YmlsaXR5IHRvIGRlZmluZSBzb21ldGhpbmcgYmV0dGVyLjxzcGFuIGNsYXNzPSJhcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQo8YnI+DQpJbiBhbnkgY2FzZSB3ZSBoYXZl IHRvIHJlc3RyaWN0IHRoZSBjaGFyYWN0ZXJzIHRoYXQgYXJlIHVzZWQgaW4gdGhlc2UgdHdvIGF1 dGhlbnRpY2F0aW9uIG1lY2hhbmlzbXMgc2luY2UgdGhleSBjb3VsZCBjb25mbGljdCB3aXRoIHRo ZSB3YXkgaG93IHdlIHRyYW5zcG9ydCB0aGUgZGF0YSBvdmVyIHRoZSB1bmRlcmx5aW5nIHByb3Rv Y29sLiBKdWxpYW4gbWVudGlvbmVkIHRoaXMgaW4gaGlzIHByZXZpb3VzIG1haWxzLjxzcGFuIGNs YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQo8YnI+DQpKdWxp YW4sIG1heWJlIHlvdSBjYW4gcHJvdmlkZSBhIGRldGFpbGVkIHRleHQgcHJvcG9zYWwgZm9yIGhv dyB0byBhZGRyZXNzIHlvdXIgY29tbWVudCBpbiBjYXNlIHdlIGdvIGZvciBVVEY4ICh3aXRoICUg ZW5jb2RpbmcpIGZvciB0aGUgY3VzdG9tIE9BdXRoIGNsaWVudCBhdXRoZW50aWNhdGlvbiBtZWNo YW5pc20/PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxi cj4NCjxicj4NCkNpYW88YnI+DQpIYW5uZXM8YnI+DQo8YnI+DQpPbiBKdW4gMTIsIDIwMTIsIGF0 IDExOjU0IEFNLCBKdWxpYW4gUmVzY2hrZSB3cm90ZTo8YnI+DQo8YnI+DQomZ3Q7IE9uIDIwMTIt MDYtMTIgMDA6MTYsIE1pa2UgSm9uZXMgd3JvdGU6PGJyPg0KJmd0OyZndDsgUmV2aWV3aW5nIHRo ZSBmZWVkYmFjayBmcm9tIEp1bGlhbiwgSm9obiwgYW5kIEphbWVzLCBJJ20gY29taW5nIHRvIHRo ZSBjb25jbHVzaW9uIHRoYXQgY2xpZW50X2lkIGFuZCBjbGllbnRfc2VjcmV0LCBiZWluZyBmb3Ig bWFjaGluZXMgYW5kIG5vdCBodW1hbnMsIHNob3UgbGQgYmUgQVNDSUksIHdoZXJlYXMgdXNlcm5h bWUgYW5kIHBhc3N3b3JkIHNob3VsZCBiZSBVbmljb2RlLCBzaW5jZSB0aGV5IGFyZSBmb3IgaHVt YW5zLiZuYnNwOyBQZXIgSm9obidzDQogZmVlZGJhY2ssIGNsaWVudF9pZCBjYW4gbm90IGNvbnRh aW4gYSBjb2xvbiBhbmQgYmUgY29tcGF0aWJsZSB3aXRoIEhUVFAgQmFzaWMuPGJyPg0KJmd0Ozxz cGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQomZ3Q7 IEknbSBub3Qgc3VyZSB0aGF0IHJlc3RyaWN0aW5nIHRoZSBjaGFyYWN0ZXIgcmVwZXJ0b2lyZSBq dXN0IGJlY2F1c2Ugb25lIHdheSB0byBzZW5kIHJlcXVpcmVzIHRoaXMgaXMgdGhlIHJpZ2h0IGFw cHJvYWNoLiBNeSBwcmVmZXJlbmNlIHdvdWxkIGJlIG5vdCB0byBwdXQgdGhpcyBpbnRvIHRoZSBB Qk5GLCBhbmQganVzdCB0byBwb2ludCBvdXQgdGhhdCBjZXJ0YWluIGNoYXJhY3RlcnMgd2lsbCBu b3Qgd29yayBvdmVyIGNlcnRhaW4gdHJhbnNwb3J0cywNCiBhbmQgdG8ganVzdCBhZHZpc2UgdG8g YXZvaWQgdGhlbS48YnI+DQomZ3Q7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPjxicj4NCiZndDsmZ3Q7IFRoZXJlZm9yZSwgSSdkIGxpa2UgdG8gcHJvcG9z ZSB0aGVzZSB1cGRhdGVkIEFCTkYgZGVmaW5pdGlvbnM6PGJyPg0KJmd0OyZndDs8c3BhbiBjbGFz cz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KJmd0OyZndDsmbmJz cDsgJm5ic3A7IFZTQ0hBUiA9ICUyMC03RTxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyBOT0NP TE9OVlNDSEFSID0gJXgyMC0zOSAvICV4M0ItN0U8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsg VU5JQ09ERU5PQ1RSTENIQVIgPSAmbHQ7QW55IFVuaWNvZGUgY2hhcmFjdGVyIG90aGVyIHRoYW4g KCAleDAtMUYgLyAleDdGICkmZ3Q7PGJyPg0KJmd0OyZndDs8c3BhbiBjbGFzcz0iYXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7IGNs aWVudC1pZCA9ICpOT0NPTE9OVlNDSEFSPGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7IGNsaWVu dF9zZWNyZXQgPSAqVlNDSEFSPGJyPg0KJmd0OyZndDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7IHVzZXJu YW1lID0gKlVOSUNPREVOT0NUUkxDSEFSPGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7IHBhc3N3 b3JkID0gKlVOSUNPREVOT0NUUkxDSEFSPGJyPg0KJmd0OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQomZ3Q7IEluIHRoaXMgY2FzZSB5b3Ugc2hv dWxkIGFkZCBhbiBpbnRyb2R1Y3Rvcnkgc3RhdGVtZW50IHBvaW50aW5nIG91dCB0aGF0IHRoZSBB Qk5GIGRlZmluZXMgdGhlIGdyYW1tYXIgaW4gdGVybXMgb2YgVW5pY29kZSBjb2RlIHBvaW50cywg bm90IG9jdGV0cyAoYXMgaXQgaXMgdGhlIGNhc2UgbW9zdCBvZiB0aGUgdGltZSkuPGJyPg0KJmd0 OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQom Z3Q7Jmd0OyBJdCB0dXJucyBvdXQgdGhhdCBub24tQVNDSUkgY2hhcmFjdGVycyBhcmUgT0sgZm9y IHVzZXJuYW1lIGFuZCBwYXNzd29yZCBiZWNhdXNlIHRoZSBDb3JlIHNwZWMgb25seSBwYXNzZXMg dGhlbSBpbiB0aGUgZm9ybSBib2R5IC0gbm90IHVzaW5nIEhUVFAgQmFzaWMgLSBhbmQgVVRGLTgg ZW5jb2RpbmcgaXMgc3BlY2lmaWVkLjxicj4NCiZndDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KJmd0OyBJJ2xsIHNlbmQgYSBzZXBhcmF0ZSBt YWlsIGFib3V0IHRoYXQsIHRoZSBjdXJyZW50IHRleHQgaW4gdGhlIHNwZWMgaXMgd2F5IHRvbyB1 bnNwZWNpZmljLjxicj4NCiZndDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+PGJyPg0KJmd0OyZndDsgJm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNw OyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8YnI+ DQomZ3Q7Jmd0OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj48YnI+DQomZ3Q7Jmd0OyBQLlMuJm5ic3A7IElmIGFueW9uZSBoYXMgYSBiZXR0ZXIgQUJORiBm b3IgVU5JQ09ERU5PQ1RSTENIQVIgdGhhbiAmcXVvdDsmbHQ7QW55IFVuaWNvZGUgY2hhcmFjdGVy IG90aGVyIHRoYW4gKCAleDAtMUYgLyAleDdGICkmZ3Q7JnF1b3Q7LCBwbGVhc2Ugc2VuZCBpdCB0 byBtZSE8YnI+DQomZ3Q7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPjxicj4NCiZndDsgQXMgbm90ZWQgYmVmb3JlLCBoZXJlJ3MgYW4gZXhhbXBsZTogJmx0 OzxhIGhyZWY9Imh0dHA6Ly9ncmVlbmJ5dGVzLmRlL3RlY2gvd2ViZGF2L3JmYzUzMjMuaHRtbCNy ZmMuc2VjdGlvbi41LjE1LjEiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vZ3JlZW5ieXRlcy5kZS90 ZWNoL3dlYmRhdi9yZmM1MzIzLmh0bWwjcmZjLnNlY3Rpb24uNS4xNS4xPC9hPiZndDs8YnI+DQom Z3Q7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4N CiZndDsgQmVzdCByZWdhcmRzLCBKdWxpYW48YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyBPQXV0aCBtYWlsaW5nIGxpc3Q8 YnI+DQomZ3Q7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu PjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGll dGYub3JnPC9hPjxicj4NCiZndDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vb2F1dGg8L2E+PGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJt YWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48 YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRo IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9v YXV0aDwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdDtiYWNrZ3JvdW5k OndoaXRlO2JhY2tncm91bmQtaW1hZ2U6aW5pdGlhbDtiYWNrZ3JvdW5kLWF0dGFjaG1lbnQ6aW5p dGlhbDtiYWNrZ3JvdW5kLW9yaWdpbjogaW5pdGlhbDtiYWNrZ3JvdW5kLWNsaXA6IGluaXRpYWw7 YmFja2dyb3VuZC1wb3NpdGlvbjppbml0aWFsIGluaXRpYWw7YmFja2dyb3VuZC1yZXBlYXQ6aW5p dGlhbCBpbml0aWFsIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+X19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVm PSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8cD5U aGlzIG1lc3NhZ2UgYW5kIGFueSBhdHRhY2htZW50IGFyZSBpbnRlbmRlZCBzb2xlbHkgZm9yIHRo ZSBhZGRyZXNzZWUgYW5kIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbi4gSWYg eW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBtZXNzYWdlIGluIGVycm9yLCBwbGVhc2Ugc2VuZCBpdCBi YWNrIHRvIG1lLCBhbmQgaW1tZWRpYXRlbHkgZGVsZXRlIGl0LiBQbGVhc2UgZG8gbm90IHVzZSwg Y29weSBvciBkaXNjbG9zZSB0aGUgaW5mb3JtYXRpb24NCiBjb250YWluZWQgaW4gdGhpcyBtZXNz YWdlIG9yIGluIGFueSBhdHRhY2htZW50LiBBbnkgdmlld3Mgb3Igb3BpbmlvbnMgZXhwcmVzc2Vk IGJ5IHRoZSBhdXRob3Igb2YgdGhpcyBlbWFpbCBkbyBub3QgbmVjZXNzYXJpbHkgcmVmbGVjdCB0 aGUgdmlld3Mgb2YgdGhlIFVuaXZlcnNpdHkgb2YgTm90dGluZ2hhbS4NCjxvOnA+PC9vOnA+PC9w Pg0KPHA+VGhpcyBtZXNzYWdlIGhhcyBiZWVuIGNoZWNrZWQgZm9yIHZpcnVzZXMgYnV0IHRoZSBj b250ZW50cyBvZiBhbiBhdHRhY2htZW50IG1heSBzdGlsbCBjb250YWluIHNvZnR3YXJlIHZpcnVz ZXMgd2hpY2ggY291bGQgZGFtYWdlIHlvdXIgY29tcHV0ZXIgc3lzdGVtOiB5b3UgYXJlIGFkdmlz ZWQgdG8gcGVyZm9ybSB5b3VyIG93biBjaGVja3MuIEVtYWlsIGNvbW11bmljYXRpb25zIHdpdGgg dGhlIFVuaXZlcnNpdHkgb2YgTm90dGluZ2hhbSBtYXkNCiBiZSBtb25pdG9yZWQgYXMgcGVybWl0 dGVkIGJ5IFVLIGxlZ2lzbGF0aW9uLiA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0K T0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj5P QXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL29hdXRoIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_4E1F6AAD24975D4BA5B168042967394366539292TK5EX14MBXC284r_-- From Michael.Jones@microsoft.com Thu Jun 14 14:18:43 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D0B721F85C9 for ; Thu, 14 Jun 2012 14:18:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.786 X-Spam-Level: X-Spam-Status: No, score=-3.786 tagged_above=-999 required=5 tests=[AWL=-0.187, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6GDs7bLgWtQw for ; Thu, 14 Jun 2012 14:18:42 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe006.messaging.microsoft.com [213.199.154.209]) by ietfa.amsl.com (Postfix) with ESMTP id 8024321F85C5 for ; Thu, 14 Jun 2012 14:18:41 -0700 (PDT) Received: from mail27-am1-R.bigfish.com (10.3.201.228) by AM1EHSOBE003.bigfish.com (10.3.204.23) with Microsoft SMTP Server id 14.1.225.23; Thu, 14 Jun 2012 21:17:30 +0000 Received: from mail27-am1 (localhost [127.0.0.1]) by mail27-am1-R.bigfish.com (Postfix) with ESMTP id E37004E01D1; Thu, 14 Jun 2012 21:17:29 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -33 X-BigFish: VS-33(zz9371I1b0bM542M11fbI1447Izz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25hf0ah) Received-SPF: pass (mail27-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC103.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail27-am1 (localhost.localdomain [127.0.0.1]) by mail27-am1 (MessageSwitch) id 1339708648339272_1413; Thu, 14 Jun 2012 21:17:28 +0000 (UTC) Received: from AM1EHSMHS010.bigfish.com (unknown [10.3.201.229]) by mail27-am1.bigfish.com (Postfix) with ESMTP id 50E5780048; Thu, 14 Jun 2012 21:17:28 +0000 (UTC) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS010.bigfish.com (10.3.207.110) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 14 Jun 2012 21:17:27 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.189]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.02.0298.005; Thu, 14 Jun 2012 21:18:07 +0000 From: Mike Jones To: Eran Hammer Thread-Topic: On the OAuth Core Spec Thread-Index: AQHNSMyPwu5PWEVemkyL/2V30k3dXpb6VGLA Date: Thu, 14 Jun 2012 21:18:06 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943665392B5@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <0CBAEB56DDB3A140BA8E8C124C04ECA20106ED8B@P3PWEX2MB008.ex2.secureserver.net> In-Reply-To: <0CBAEB56DDB3A140BA8E8C124C04ECA20106ED8B@P3PWEX2MB008.ex2.secureserver.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] On the OAuth Core Spec X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 21:18:43 -0000 FYI, Eran, I'm going to hold off sending you proposed updated ABNF text for= a few more days to let the discussions continue and consensus to build. I= 'm currently mentally targeting sending proposed draft updates Monday. Best wishes, -- Mike -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E= ran Hammer Sent: Tuesday, June 12, 2012 11:53 AM To: Derek Atkins Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] On the OAuth Core Spec Derek - Thank you for this note. It is very much appreacited. > From: Derek Atkins [mailto:derek@ihtfp.com] > Sent: Tuesday, June 12, 2012 10:28 AM > Having said that, are you still willing and able to be the editor of=20 > this draft and see it to its conclusion and publication? Yes. > If so, we will need to get another > draft out by this Friday (June 15), and I suspect we'll need another=20 > draft that solves the encoding issue (brought up by the ABNF=20 > exercise), targeting Friday, June 29th. Do you think you can make=20 > these target dates (assuming that there is text for you to apply to the d= raft)? There are two main open issues I'm aware of: 1. Error registry text * The text provided by Mike Jones for section 7.2 is unlcear. I have provid= ed feedback on the list and am waiting to hear back from Mike (or anyone el= se). Once I understand the actual intention of the new normative language, = I will rework the text to reflect those changes. While I have strong object= ions to the error code registry in genreal, once decided, my only goal is t= o ensure the text is clear, complete, and reflects working group consensus.= I do not have strong interest in how the working group resolves the rules = around the registry as long as they are clear and practical. The current te= xt for 7.2 is not. * In the consensus call for the error registry, Hannes requested (or sugges= ted, it wasn't clear given the context) that the registry be implemented by= IANA using separate tables. This requires prose changes to instruct IANA a= s such. Without changes, IANA will create a single table which is not what = was requested. I have not seen much discussion on this. I am waiting for th= e chairs to clarify this and for someone to provide text if this is still t= he case (I have sent multiple emails on this to the list). 2. ABNF * Mike Jones is doing solid work progressing the ABNF forward with the guid= ance of Julian. I trust Julian blindly to guide the text to a successful co= nculsion and the working group seems enaged. As soon as new text is availab= le, I will incorporate and publish. If a schedule conflict arises in which = I am unable to push the ABNF changes, I have no objections to Mike Jones pu= shing a new draft with only ABNF related change after quick coordination (M= ike can submit using my contact and I'll approve it within a few hours). I also have a short list of nits and typos reported to the list and me dire= ctly over the past few weeks which are all insignificant to list. I am available to publish another draft on or by 6/14, and again on or by 6= /27 (or 6/30 after my travel). I will be travelling on the exact dates list= ed. I am hoping that these dates are flexible within a few days range. In o= rder for me to publish a new draft by 6/14, I will need the changes a day b= efore to prepare. If the changes are ABNF only, I can work with Mike Jones = to arrange it without putting my travel restriction in the way. I need the = chairs to clarify what is expected in each of these drafts and how they see= k to resolve the issues around item #1 above to continue. Again, thanks for the note. EH _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From wmills@yahoo-inc.com Thu Jun 14 14:20:27 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCFCA21F85CD for ; Thu, 14 Jun 2012 14:20:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.498 X-Spam-Level: X-Spam-Status: No, score=-17.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fbka4YQWLr9j for ; Thu, 14 Jun 2012 14:20:25 -0700 (PDT) Received: from nm9-vm2.bullet.mail.ne1.yahoo.com (nm9-vm2.bullet.mail.ne1.yahoo.com [98.138.90.157]) by ietfa.amsl.com (Postfix) with SMTP id 32B1721F85C5 for ; Thu, 14 Jun 2012 14:20:25 -0700 (PDT) Received: from [98.138.90.55] by nm9.bullet.mail.ne1.yahoo.com with NNFMP; 14 Jun 2012 21:20:18 -0000 Received: from [98.138.89.169] by tm8.bullet.mail.ne1.yahoo.com with NNFMP; 14 Jun 2012 21:20:18 -0000 Received: from [127.0.0.1] by omp1025.mail.ne1.yahoo.com with NNFMP; 14 Jun 2012 21:20:18 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 925373.83015.bm@omp1025.mail.ne1.yahoo.com Received: (qmail 63181 invoked by uid 60001); 14 Jun 2012 21:20:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1339708818; bh=isc75ldf8DaT628RYU68VDxFOjapXXXC9lc3kzxplpk=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=SrsdzAmUEfx7nyFoPnnME/CWERO+pTc3jF36TAkyYoitSBBGNNUdwyZ67Tby+lhVFzQcmT73ftUxTOsm6ucGy9GaHP4+estzW61PVQfkxhTmxS7sbilVaj5D0jtMvLbWmd3hNAxnBkxS9CnOoA4mg72m8rprEjF1J6gX5ZpQ2uU= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=efPDJl7T9oHGmfYwmDp9CxUrjCIT5298W846vmJvWzQMS81hZK0TfCNREZi52Mq3fY9ZR4yWzVwrQSYEIwAFEOwdH26H3Hd0VCb7wqSJIsZLxkMTo0d0q30YTZlOzBksTc8YuPWVRGdon6ILry3cV4KXoh35SmA6CG1nufsE3m0=; X-YMail-OSG: HXfvShgVM1n2sDFVGW.g75Lem8ZU0gZf469xaaCM2TTBur1 6fCj6FaPcYfz3g6S6XISMR87NVDhHnT94LFiGz_qLEOKHvtEOycolNtOG4FY 1KVa1bfr6EosTsaUz2zMWKUFs_T13YabzlKP8v5CqBJtQCMLjKYyrqeXI85Z QAZgOcu6QZxqC7HEeTi1IOdRSY2Qht0e7wVMUH90tqW_G9uV.ep480Nygjzm AL57xhQ4xHkYaURkXDTKSNqex6J0uDhlRbkcCG_6CtoJwwArgWh98t7nIWF3 LRtYZ17rleTxGJgwcUQ6pjohWMYV5VK5TS5Ssk5G8x2DEks2qaJWQA8SO7fa QCLHKi8CakzaL1l027Xlqx5BuOEGxVqgkFS2vA14msRWaKvGMP1jiZsVYlOJ dnLSUvbehE46UFe.6dTu84tt77hBw45ZDpqL2Ak.vyjAy6jm397P9cvE9c5s PWwqQolaUz5DL1fk5PfWPeOBB2qabcJHAX9NjbxWGvygNm0Nd_0JZAQQRXTG tqf6hS7NGENJzcK3M0bxf72NpA16bixr7kSQKZB8F_lwnrjY5yb031lpYO.w GEgXhybuggMyIHX.3QQUkIYjXp0XJCiJ4pX02gp_L8ec3fzRcrpuytw-- Received: from [209.131.62.115] by web31808.mail.mud.yahoo.com via HTTP; Thu, 14 Jun 2012 14:20:18 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.120.356233 References: <4E1F6AAD24975D4BA5B168042967394366539292@TK5EX14MBXC284.redmond.corp.microsoft.com> Message-ID: <1339708818.17727.YahooMailNeo@web31808.mail.mud.yahoo.com> Date: Thu, 14 Jun 2012 14:20:18 -0700 (PDT) From: William Mills To: Mike Jones , John Bradley , Torsten Lodderstedt In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366539292@TK5EX14MBXC284.redmond.corp.microsoft.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="258328648-923474063-1339708818=:17727" Cc: Julian Reschke , Richard Mortier , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion needed on username and password ABNF definitions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 21:20:28 -0000 --258328648-923474063-1339708818=:17727 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Will BASIC auth be needed for clients with an ID in the form of a URI?=0A= =0A=0A=0A=0A>________________________________=0A> From: Mike Jones =0A>To: John Bradley ; Torsten Lodd= erstedt =0A>Cc: Julian Reschke ; Richard Mortier ; "oauth@ietf.org"= =0A>Sent: Thursday, June 14, 2012 2:14 PM=0A>Subject: Re:= [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion needed on userna= me and password ABNF definitions=0A> =0A>=0A> =0A>The more I think about ex= cluding the possibility of using URIs as client IDs, the more uncomfortable= I am with it.=C2=A0 I=E2=80=99m increasingly thinking that we should allow= the ASCII characters used in URIs (and probably the other visible ones and= space as well, as currently proposed) and have special language about =E2= =80=9CBut what if this client_id containing colon characters is to be used = with HTTP Basic?=E2=80=9D=0A>=C2=A0=0A>As one suggestion, mainly to restart= discussion (which seems to have stalled), we could suggest (or require) th= at all colon characters in client_ids be substituted with tab characters (%= x09), which are legal in HTTP Basic but not in the proposed definition of c= lient_ids, before use with HTTP Basic, and that the reverse substitution oc= cur when received from HTTP Basic.=C2=A0 Other transformations or encodings= are possible.=C2=A0 We could also cop out by saying something like =E2=80= =9CIf characters not legal in HTTP Basic occur in the client_id, a transfor= mation encoding them must be agreed to by both parties=E2=80=9D.=C2=A0 I do= n=E2=80=99t love the tab idea, because it=E2=80=99s admittedly a hack, but = I believe it=E2=80=99s better than precluding the use of URIs as client_ids= .=0A>=C2=A0=0A>Thoughts?=0A>=C2=A0=0A>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 -- Mike=0A>=C2=A0=0A>From:oauth-bounces@ietf.org [mailto= :oauth-bounces@ietf.org] On Behalf Of John Bradley=0A>Sent: Wednesday, June= 13, 2012 11:40 AM=0A>To: Torsten Lodderstedt=0A>Cc: Julian Reschke; Richar= d Mortier; oauth@ietf.org=0A>Subject: Re: [OAUTH-WG] Dynamic clients, URI, = and stuff Re: Discussion needed on username and password ABNF definitions= =0A>=C2=A0=0A>That would probably work as well. =C2=A0That is why I am not = particularly concerned about excluding the :=C2=A0=0A>=C2=A0=0A>We original= ly used the URI itself, =C2=A0mostly for convenience of debugging, =C2=A0bu= t there are other potential options.=C2=A0=0A>=C2=A0=0A>The authorization s= erver needs to compare the client_id and the redirect uri. But it could com= pare the hash with not much more work. =C2=A0 Also a sha256 hash is probabl= y longer than the uri it is hashing. =C2=A0=0A>=C2=A0=0A>I am not super con= cerned with being able to have : in the client_id=0A>=C2=A0=0A>John B.=C2= =A0=0A>=0A>Sent from my iPhone=0A>=0A>On 2012-06-13, at 6:03 PM, Torsten Lo= dderstedt wrote:=0A>Hi John,=0A>>=0A>>would it ma= ke sense to use a hash of the URI instead of the URI itself in your use cas= e?=0A>>=0A>>regards,=0A>>Torsten.=0A>>=0A>>=0A>>John Bradley schrieb:=0A>>I think that the issues are getting confused.=0A>>=C2=A0= =0A>>There is a use case where the Authorization server may be a embedded a= pp, at least in one openID case. =C2=A0 =C2=A0As it won't have a separate r= egistration or token endpoint, =C2=A0the client needs to make its own clien= tID for the request. =C2=A0 A reasonable thing to use is the redirect URI t= o create a unique value that the user could use for revocation at a later p= oint.=0A>>=C2=A0=0A>>Currently with the no : restriction we would use the h= ost and path to crate the clientid.=0A>>There are some scenarios where havi= ng the scheme as part of that would be helpful.=0A>>=C2=A0=0A>>This has not= hing to do with discovery or the dynamic client registration proposal as fa= r as I know.=0A>>=C2=A0=0A>>A URL as a client_id comes from prototype work = for a personal provider that we are doing as part of openID Connect.=0A>>= =C2=A0=0A>>John B.=0A>>On 2012-06-13, at 7:50 AM, Torsten Lodderstedt wrote= :=0A>>=0A>>=0A>>=0A>>Hi all,=0A>>=0A>>can anyone please explain the relatio= n between dynamic client registration and URIs as client ids? None of the c= urrent drafts (uma or connect) seem to require URIs.=0A>>=0A>>regards,=0A>>= Torsten.=0A>>=0A>>=0A>>Jianhua Shao schrieb:=0A>>= Hello,=0A>>=C2=A0=0A>>Dynamic client registration is very useful if client = or resource or authorisation server is not permanently available.=C2=A0=0A>= >A typical case is that is the resource or authorisation server is in mobil= e platform, the connection is not always available.=C2=A0=0A>>Another typic= al case is that authorisation server do not necessary to have client pre-re= gistered on itself. At moment, industry like facebook would like developer = to register a app on its app centre first, and then ask user auth to use th= e app.=C2=A0=0A>>=C2=A0=0A>>We are researchers from Digital Economy Researc= h Institute. We have this problem When we developing Dataware that could ma= nage the control of access to personal data. We play around our solution ba= se on Oauth2:=C2=A0https://github.com/jianhuashao/dataware.catalog/wiki=0A>= >=C2=A0=0A>>We are in the list to receive your mail list, but currently nee= d moderate to post any message. cc my colleague, Richard Mortier=0A>>Best= =0A>>Jian=0A>>=C2=A0=0A>>=C2=A0=0A>>On 12 Jun 2012, at 21:08, Eran Hammer w= rote:=0A>>=0A>>=0A>>=0A>>The only distinction I would make is between remov= ing flexibiliy to proactively enabling future extensibility. I would stop s= hort of perscribing encoding in order to fit uri into the Basic auth fields= . But if there is a way to allow this to be less restrictive without clean = interop issues, that would be nice.=0A>>=C2=A0=0A>>I do agree we need some = actual use cases before we spend much more time on this.=0A>>=C2=A0=0A>>EH= =0A>>=C2=A0=0A>>From:=C2=A0William Mills [mailto:wmills@yahoo-inc.com]=C2= =A0=0A>>Sent:=C2=A0Tuesday, June 12, 2012 1:04 PM=0A>>To:=C2=A0Eran Hammer;= Mike Jones; Hannes Tschofenig; Julian Reschke=0A>>Cc:=C2=A0oauth@ietf.org= =0A>>Subject:=C2=A0Dynamic clients, URI, and stuff Re: [OAUTH-WG] Discussio= n needed on username and password ABNF definitions=0A>>=C2=A0=0A>>I think d= ynamic client registration is something we have not talked out enough yet.= =C2=A0 There's a pretty clear use case for dynamic registration.=C2=A0=C2= =A0=0A>>=C2=A0=0A>>Does identifying the client with a URI allow some form o= f OpenID-ish flow for this?=C2=A0=0A>>Is the client ID as a URI a way to al= low a trusted site to provide metadata about the client?=0A>>Is that URI a = way to hit an IDP we trust to validate the client in some way with the prov= ided secret?=0A>>=C2=A0=0A>>I guess what I'm looking for here is a concrete= use case/problem to solve, rather then leaving a hook we think is the righ= t thing.=0A>>=C2=A0=0A>>-bill=0A>>=C2=A0=0A>>=C2=A0=0A>>>=0A>>>____________= ____________________=0A>>> =0A>>>From:=C2=A0Eran Hammer =0A>>>To:=C2=A0Mike Jones ; William Mills ; Hannes Tschofenig ; Julian= Reschke =C2=A0=0A>>>Cc:=C2=A0"oauth@ietf.org" =C2=A0=0A>>>Sent:=C2=A0Tuesday, June 12, 2012 11:39 AM=0A>>>Subj= ect:=C2=A0RE: [OAUTH-WG] Discussion needed on username and password ABNF de= finitions=0A>>>=C2=A0=0A>>>Is the use case of using URI as client ids impor= tant? It seems like something that might become useful in the future where = clients can use their verifiable servers to bypass client registration and = simly use a URI the server can validate via some other means.=0A>>>=C2=A0= =0A>>>I just want to make sure those thinking about more complex use cases = involving dynamic registration or distri buted client manamgenet are aware = of this potential restriction.=0A>>>=C2=A0=0A>>>I'm fine either way.=0A>>>= =C2=A0=0A>>>EH=0A>>>=C2=A0=0A>>>From:=C2=A0oauth-bounces@ietf.org=C2=A0[mai= lto:oauth-bounces@ietf.org]=C2=A0On Behalf Of=C2=A0Mike Jones=0A>>>Sent:=C2= =A0Tuesday, June 12, 2012 11:27 AM=0A>>>To:=C2=A0William Mills; Hannes Tsch= ofenig; Julian Reschke=0A>>>Cc:=C2=A0oauth@ietf.org=0A>>>Subject:=C2=A0Re: = [OAUTH-WG] Discussion needed on username and password ABNF definitions=0A>>= >=C2=A0=0A>>>Not internationalizing fields intended for machine consumption= only is already a precedent set and agreed to by the working group, so let= me second Bill=E2=80=99s point in that regard.=C2=A0 For instance, neither= =E2=80=9Cscope=E2=80=9D nor =E2=80=9Cerror=E2=80=9D allow non-ASCII charac= ters.=0A>>>=C2=A0=0A>>>Julian, if you want different ABNF text than the tex= t I wrote below, I believe it would be most useful if you would provide the= exact replace wording that you=E2=80=99d like to see instead of it.=C2=A0 = Then there=E2=80=99s no possibility of misunderstanding the intent of sugge= sted changes.=0A>>>=C2=A0=0A>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 Thanks all,=0A>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 -- Mike=0A>>>=C2=A0=0A>>>From:=C2=A0oauth-bounces@ietf.org=C2=A0[= mailto:oauth-bounces@ietf.org]=C2=A0On Behalf Of=C2=A0William Mills=0A>>>Se= nt:=C2=A0Tuesday, June 12, 2012 11:18 AM=0A>>>To:=C2=A0Hannes Tschofenig; J= ulian Reschke=0A>>>Cc:=C2=A0oauth@ietf.org=0A>>>Subject:=C2=A0Re: [OAUTH-WG= ] Discussion needed on username and password ABNF definitions=0A>>>=C2=A0= =0A>>>I agree generally with your assumption about clients, but rather than= saying "clients are devices" I think it makes much more sense to say "clie= nts are NOT users, so client_id need not be internationalized".=C2=A0 In pr= actical terms there is very little to argue for anythign beyond ASCII in a = client_secret, base64 encoding or the equivalent being a fine way to transp= ort arbitrary bits in a portable/reasonable way.=0A>>>=C2=A0=0A>>>I argue t= hat client_id need not be internationalized because I assume that any reall= y internationalized application will have an internationalized presentation= layer that's presenting a pretty name for the client_id.=0A>>>=C2=A0=0A>>>= -bill=0A>>>=C2=A0=0A>>>=0A>>>________________________________=0A>>> =0A>>>F= rom:=C2=A0Hannes Tschofenig =0A>>>To:=C2=A0Julia= n Reschke =C2=A0=0A>>>Cc:=C2=A0"oauth@ietf.org" =C2=A0=0A>>>Sent:=C2=A0Tuesday, June 12, 2012 11:01 AM=0A>>>Sub= ject:=C2=A0Re: [OAUTH-WG] Discussion needed on username and password ABNF d= efinitions=0A>>>=0A>>>I had a chat with Julian yesterday and here is my sho= rt summary.=C2=A0=0A>>>=0A>>>Section 2.3 of the core draft defines client a= uthentication based on two mechanisms (and provides room for extensions):ht= tp://tools.ietf.org/html/draft-ietf-oauth-v2-27#section-2.3=0A>>>=0A>>>1) H= TTP Basic Authentication=0A>>>=0A>>>2) A custom OAuth authentication mechan= ism (which uses client_id and client_secret)=0A>>>=0A>>>With HTTP Basic aut= hentication the problem is that this is a legacy technology and there is no= internationalization support.=C2=A0=0A>>>=0A>>>With our brand new custom O= Auth authentication mechanism we have more options.=C2=A0=0A>>>=0A>>>One po= ssible approach is to say that the clients are devices (and not end users) = and therefore internationalization does not matter.=C2=A0=0A>>>=0A>>>Is it,= however, really true that only US-ASCII characters will appear in the clie= nt_id and also in the client_secret?=C2=A0=0A>>>=0A>>>Here we have the poss= ibility to define something better.=C2=A0=0A>>>=0A>>>In any case we have to= restrict the characters that are used in these two authentication mechanis= ms since they could conflict with the way how we transport the data over th= e underlying protocol. Julian mentioned this in his previous mails.=C2=A0= =0A>>>=0A>>>Julian, maybe you can provide a detailed text proposal for how = to address your comment in case we go for UTF8 (with % encoding) for the cu= stom OAuth client authentication mechanism?=C2=A0=0A>>>=0A>>>Ciao=0A>>>Hann= es=0A>>>=0A>>>On Jun 12, 2012, at 11:54 AM, Julian Reschke wrote:=0A>>>=0A>= >>> On 2012-06-12 00:16, Mike Jones wrote:=0A>>>>> Reviewing the feedback f= rom Julian, John, and James, I'm coming to the conclusion that client_id an= d client_secret, being for machines and not humans, shou ld be ASCII, where= as username and password should be Unicode, since they are for humans.=C2= =A0 Per John's=0A feedback, client_id can not contain a colon and be compat= ible with HTTP Basic.=0A>>>>=C2=A0=0A>>>> I'm not sure that restricting the= character repertoire just because one way to send requires this is the rig= ht approach. My preference would be not to put this into the ABNF, and just= to point out that certain characters will not work over certain transports= ,=0A and to just advise to avoid them.=0A>>>>=C2=A0=0A>>>>> Therefore, I'd = like to propose these updated ABNF definitions:=0A>>>>>=C2=A0=0A>>>>>=C2=A0= =C2=A0 VSCHAR =3D %20-7E=0A>>>>>=C2=A0 =C2=A0 NOCOLONVSCHAR =3D %x20-39 / = %x3B-7E=0A>>>>>=C2=A0 =C2=A0 UNICODENOCTRLCHAR =3D =0A>>>>>=C2=A0=0A>>>>>=C2=A0 =C2=A0 client-id = =3D *NOCOLONVSCHAR=0A>>>>>=C2=A0 =C2=A0 client_secret =3D *VSCHAR=0A>>>>>= =C2=A0=0A>>>>>=C2=A0 =C2=A0 username =3D *UNICODENOCTRLCHAR=0A>>>>>=C2=A0 = =C2=A0 password =3D *UNICODENOCTRLCHAR=0A>>>>=C2=A0=0A>>>> In this case you= should add an introductory statement pointing out that the ABNF defines th= e grammar in terms of Unicode code points, not octets (as it is the case mo= st of the time).=0A>>>>=C2=A0=0A>>>>> It turns out that non-ASCII character= s are OK for username and password because the Core spec only passes them i= n the form body - not using HTTP Basic - and UTF-8 encoding is specified.= =0A>>>>=C2=A0=0A>>>> I'll send a separate mail about that, the current text= in the spec is way too unspecific.=0A>>>>=C2=A0=0A>>>>> =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 -- Mike=0A>>>>>= =C2=A0=0A>>>>> P.S.=C2=A0 If anyone has a better ABNF for UNICODENOCTRLCHAR= than "", please send i= t to me!=0A>>>>=C2=A0=0A>>>> As noted before, here's an example: =0A>>>>=C2=A0=0A>>>= > Best regards, Julian=0A>>>> _____________________________________________= __=0A>>>> OAuth mailing list=0A>>>>=C2=A0OAuth@ietf.org=0A>>>>=C2=A0https:/= /www.ietf.org/mailman/listinfo/oauth=0A>>>=0A>>>___________________________= ____________________=0A>>>OAuth mailing list=0A>>>OAuth@ietf.org=0A>>>https= ://www.ietf.org/mailman/listinfo/oauth=0A>>>=C2=A0=0A>>____________________= ___________________________=0A>>OAuth mailing list=0A>>OAuth@ietf.org=0A>>h= ttps://www.ietf.org/mailman/listinfo/oauth=0A>>This message and any attachm= ent are intended solely for the addressee and may contain confidential info= rmation. If you have received this message in error, please send it back to= me, and immediately delete it. Please do not use, copy or disclose the inf= ormation contained in this message or in any attachment. Any views or opini= ons expressed by the author of this email do not necessarily reflect the vi= ews of the University of Nottingham. =0A>>This message has been checked for= viruses but the contents of an attachment may still contain software virus= es which could damage your computer system: you are advised to perform your= own checks. Email communications with the University of Nottingham may be = monitored as permitted by UK legislation. =0A>>____________________________= ___________________=0A>>OAuth mailing list=0A>>OAuth@ietf.org=0A>>https://w= ww.ietf.org/mailman/listinfo/oauth=0A>>=C2=A0=0A>__________________________= _____________________=0A>OAuth mailing list=0A>OAuth@ietf.org=0A>https://ww= w.ietf.org/mailman/listinfo/oauth=0A>=0A>=0A> --258328648-923474063-1339708818=:17727 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Will BASIC auth be needed for clients with an ID in the form of a URI?


From: Mike Jones <Michael.Jones@microsoft.com>
= To: John Bradley <ve7jt= b@ve7jtb.com>; Torsten Lodderstedt <torsten@lodderstedt.net>
<= b>Cc: Julian Reschke <julian.reschke@gmx.de>; Richard Mortier <richard.mortier@notting= ham.ac.uk>; "oauth@ietf.org" <oauth@ietf.org>
Sent: Thursday, June 14, 2012 2:14 PM Subject: Re: [OAUTH-WG] = Dynamic clients, URI, and stuff Re: Discussion needed on username and passw= ord ABNF definitions

=0A= =0A =0A =0A=0A=0A
=0A
= =0A
The more I think about excluding the possibility of using URI= s as client IDs, the more uncomfortable I am with it.  I=E2=80=99m inc= reasingly thinking that we should=0A allow the ASCII characters used in URI= s (and probably the other visible ones and space as well, as currently prop= osed) and have special language about =E2=80=9CBut what if this client_id c= ontaining colon characters is to be used with HTTP Basic?=E2=80=9D =0A
 
=0A
As one suggestion, ma= inly to restart discussion (which seems to have stalled), we could suggest = (or require) that all colon characters in client_ids be substituted=0A with= tab characters (%x09), which are legal in HTTP Basic but not in the propos= ed definition of client_ids, before use with HTTP Basic, and that the rever= se substitution occur when received from HTTP Basic.  Other transforma= tions or encodings are possible. =0A We could also cop out by saying s= omething like =E2=80=9CIf characters not legal in HTTP Basic occur in the c= lient_id, a transformation encoding them must be agreed to by both parties= =E2=80=9D.  I don=E2=80=99t love the tab idea, because it=E2=80=99s ad= mittedly a hack, but I believe it=E2=80=99s=0A better than precluding the u= se of URIs as client_ids.
=0A
 
= =0A
Thoughts?
=0A
 
=0A=
          &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           -- Mike
=0A
 
=0A
=0A
=0AFrom= : oauth-bounces@ietf.org [mail= to:oauth-bounces@ietf.org]=0AOn Behalf Of John Bradley
=0ASent= : Wednesday, June 13, 2012 11:40 AM
=0ATo: Torsten Loddersted= t
=0ACc: Julian Reschke; Richard Mortier; oauth@ietf.org
=0ASubject: Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion= needed on username and password ABNF definitions
=0A
=0A=
=0A
 
=0A
=0AThat would probably work as well.  = That is why I am not particularly concerned about excluding the :  =0A
=0A
=0A
 
= =0A
=0A
=0A
We originally use= d the URI itself,  mostly for convenience of debugging,  but ther= e are other potential options. 
=0A
=0A
=0A
 
=0A
=0A
=0A
The authorization server needs to compare the clie= nt_id and the redirect uri. But it could compare the hash with not much mor= e work.   Also a sha256 hash is probably longer than the uri it is has= hing.  
=0A
=0A
=0A
 
=0A
=0A
=0A
I= am not super concerned with being able to have : in the client_id
= =0A
=0A
=0A
 
=0A=
=0A
=0A
John B. 
=0A=
=0ASent from my iPhone
=0A
=0A
=0A

=0AOn 2012-06-13, at 6:= 03 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
=0A
=0A
=0A
=0A
Hi John,
=0A
=0Awou= ld it make sense to use a hash of the URI instead of the URI itself in your= use case?
=0A
=0Aregards,
=0ATorsten.
=0A
=0A

=0A
=0AJohn Bradley <ve7jtb@ve7jtb.com> schrieb:
=0A
I think that the issues are getting confused. =0A
=0A
 
=0A
= =0A
=0A
There is a use case where = the Authorization server may be a embedded app, at least in one openID case= .    As it won't have a separate registration or token endpoint, =  the client needs to make its own clientID for the request.   A r= easonable=0A thing to use is the redirect URI to create a unique value that= the user could use for revocation at a later point.
=0A
=0A=0A
 
=0A
=0A
= =0A
Currently with the no : restrictio= n we would use the host and path to crate the clientid.
=0A
=0A<= div>=0A
There are some scenarios where= having the scheme as part of that would be helpful.
=0A
=0A=0A
 
=0A
=0A
= =0A
This has nothing to do with discov= ery or the dynamic client registration proposal as far as I know.
=0A=
=0A
=0A
 
=0A=0A
=0A
A URL as a client_id co= mes from prototype work for a personal provider that we are doing as part o= f openID Connect.
=0A
=0A
=0A
 
=0A
=0A
=0A
John B.
=0A
=0A
=0A
= On 2012-06-13, at 7:50 AM, Torsten Lodderstedt wrote:
=0A
=0A
=0A
=0A
=0A
=0A
Hi all,
= =0A
=0Acan anyone please explain the relation between dynamic client reg= istration and URIs as client ids? None of the current drafts (uma or connec= t) seem to require URIs.
=0A
=0Aregards,
=0ATorsten.
=0A=0A

=0A
=0AJianhua Shao <psxjs4@nottingham.ac.uk>= schrieb:
=0A
=0A
Hello, =0A
=0A
=0A
 
= =0A
=0A
=0A
Dynamic client re= gistration is very useful if client or resource or authorisation server is = not permanently available. 
=0A
=0A
=0A
A typical case is that is the resource or authorisati= on server is in mobile platform, the connection is not always available.&nb= sp;
=0A
=0A
=0A
Another= typical case is that authorisation server do not necessary to have client = pre-registered on itself. At moment, industry like facebook would like deve= loper to register a app on its app centre first, and then ask user auth to = use=0A the app. 
=0A
=0A
=0A
 
=0A
=0A
=0A
We are researchers from Digital Economy Research Institute. We have= this problem When we developing Dataware that could manage the control of = access to personal data. We play around our solution base on Oauth2: <= a rel=3D"nofollow" target=3D"_blank" href=3D"https://github.com/jianhuashao= /dataware.catalog/wiki">https://github.com/jianhuashao/dataware.catalog/wik= i
=0A
=0A
=0A
&nbs= p;
=0A
=0A
=0A
We are i= n the list to receive your mail list, but currently need moderate to post a= ny message. cc my colleague, Richard Mortier
=0A
=0A
=0ABest
=0A
=0A
=0A
Jian
=0A
=0A
=0A
 
=0A
=0A
 
=0A
=0A
=0A
On 12 Jun 2012, at 21:08, Eran Hammer wrote:
=0A
=0A

=0A
=0A
=0A
=0A
=0AThe only distinction I would make is between removing flexibiliy t= o proactively enabling future extensibility. I would stop short of perscrib= ing encoding in=0A order to fit uri into the Basic auth fields. But if ther= e is a way to allow this to be less restrictive without clean interop issue= s, that would be nice.
=0A
=0A
=0A
 
=0A
=0A
=0A
I do agree we need some actual u= se cases before we spend much more time on this.
=0A
=0A<= div>=0A
 
=0A
=0A
=0A
EH
=0A
=0A
=0A
 
=0A
=0A=0A
=0A
=0A=0A
From: William=0A Mills [mailto:wmills@yahoo-inc.com] 
=0ASent: Tuesday, June 12, 2012 1:04 PM
= =0ATo: Eran Hammer; Mike Jones; Hannes Tschofenig; Julian Reschke
=0ACc: oauth@ietf.org
=0ASubject: Dynamic clients, URI, and s= tuff Re: [OAUTH-WG] Discussion needed on username and password ABNF definit= ions
=0A
=0A
=0A
=0A
=0A
 
=0A
=0A
=0A
=0A
=0A
I think dynamic client registration is someth= ing we have not talked out enough yet.  There's a pretty clear use cas= e for dynamic registration.  
=0A
=0A
=0A<= div>=0A
=0A
 
=0A=
=0A
=0A
=0A
=0A
Does= identifying the client with a URI allow some form of OpenID-ish flow for t= his? 
=0A
=0A
=0A
=0A
=0A
Is the client ID as a URI a way to allow a trusted s= ite to provide metadata about the client?
=0A
=0A
= =0A
=0A
=0A
Is that URI a way t= o hit an IDP we trust to validate the client in some way with the provided = secret?
=0A
=0A
=0A
=0A
=0A
 
=0A
=0A
=0A
=0A
= =0A
I guess what I'm looking for here i= s a concrete use case/problem to solve, rather then leaving a hook we think= is the right thing.
=0A
=0A
=0A
=0A
=0A 
=0A
=0A
= =0A
=0A
=0A
-bill
= =0A
=0A
=0A
=0A
=0A
&= nbsp;
=0A
=0A
=0A
=0A
=0A=0A
 
=0A
=0A<= div>=0A
=0A
=0A
=0A=0A
= =0A
=0A
=0A
From: Eran=0A Hammer <eran@hueniverse.com>
=0ATo: Mike Jones <Michael.Jones@microsoft.com>; William = Mills <wmills@yahoo-inc.com&= gt;; Hannes Tschofenig <hannes.tschofenig@gmx.net>;=0A Julian Reschke <julian.reschke@gmx.de> 
=0ACc: "oauth@ietf.org" <oauth@ietf.org&= gt; 
=0A<= b>Sent: = Tuesday, June 12, 2012 11:39 AM
=0ASubject: RE: [OAUTH-WG] Discussion needed = on username and password ABNF definitions
=0A
=0A
= =0A
=0A
 
=0A
=0A
=0A
=0A
=0A
=0A
=0A
Is the use case of using URI as client ids important? It seems= like something that might become useful in the future where clients can us= e their verifiable servers to=0A bypass client registration and simly use a= URI the server can validate via some other means.
=0A
= =0A
=0A
=0A
=0A
 
=0A
=0A
=0A
=0A
=0A
I just want to make sure those thinking about more complex use= cases involving dynamic registration or distri buted client manamgenet are= aware of this potential restriction.
=0A
=0A
=0A=0A
=0A
 
=0A=
=0A
=0A
=0A
=0A
I'= m fine either way.
=0A
=0A
=0A
=0A
=0A
 
=0A
=0A
=0A<= div>=0A
=0A
EH
=0A=0A
=0A
=0A
=0A
&nbs= p;
=0A
=0A
=0A
=0A
= =0A
=0A
=0A
=0A
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On=0A Behalf Of Mike Jones
=0AS= ent: Tue= sday, June 12, 2012 11:27 AM
=0ATo: William Mills; Hannes Tschofenig; Julian = Reschke
=0ACc:=  oauth@ietf.org
=0ASubj= ect: Re:= [OAUTH-WG] Discussion needed on username and password ABNF definitions
=0A
=0A
=0A
=0A
=0A
=0A
=0A
 
=0A
=0A
=0A
=0A
=0A
Not internationalizing fields intended for m= achine consumption only is already a precedent set and agreed to by the wor= king group, so let me second Bill=E2=80=99s point in that=0A regard.  = For instance, neither =E2=80=9Cscope=E2=80=9D nor =E2=80=9Cerror=E2=80=9D a= llow non-ASCII characters.
=0A
=0A
=0A
=0A
= =0A
 
=0A
=0A<= /div>=0A
=0A
=0A
Julian, if y= ou want different ABNF text than the text I wrote below, I believe it would= be most useful if you would provide the exact replace wording that you=E2= =80=99d like=0A to see instead of it.  Then there=E2=80=99s no possibi= lity of misunderstanding the intent of suggested changes.
=0A<= /div>=0A
=0A
=0A
=0A
&nb= sp;
=0A
=0A
=0A
=0A
=0A
         &nb= sp;            =             &nb= sp;            =              Th= anks all,
=0A
=0A
=0A
=0A
=0A
        &nb= sp;            =             &nb= sp;            =             &nb= sp; -- Mike
=0A
=0A
=0A
=0A
=0A
 
=0A
=0A
=0A
=0A=
=0A
=0A
=0A
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On=0A Behalf Of William Mills
=0A<= b>Sent: = Tuesday, June 12, 2012 11:18 AM
=0ATo: Hannes Tschofenig; Julian Reschke
= =0ACc: oauth@ietf.org
=0ASubject: Re: [OAUTH-WG] D= iscussion needed on username and password ABNF definitions
=0A=
=0A
=0A
=0A
=0A
=0A
=0A
&nb= sp;
=0A
=0A
=0A
=0A
=0A
=0A
=0A
I agree generally with your assumption abou= t clients, but rather than saying "clients are devices" I think it makes mu= ch more sense to say "clients are NOT users, so client_id=0A need not be in= ternationalized".  In practical terms there is very little to argue fo= r anythign beyond ASCII in a client_secret, base64 encoding or the equivale= nt being a fine way to transport arbitrary bits in a portable/reasonable wa= y.
=0A
=0A
=0A
=0A
=0A
=0A
 
=0A
=0A
=0A
=0A<= div>=0A
=0A
=0A
I argue that cl= ient_id need not be internationalized because I assume that any really inte= rnationalized application will have an internationalized presentation layer= that's=0A presenting a pretty name for the client_id.
=0A=0A
=0A
=0A
=0A
=0A
=0A
 
=0A
=0A
=0A
=0A
=0A
=0A=
=0A
<= span style=3D"font-size:14.0pt;color:black;">-bill
=0A
= =0A
=0A
=0A
=0A
=0A
= =0A
 
=0A
=0A=0A
=0A
=0A
=0A
=0A=0A
=0A
=0A
=0A
=0A
From:<= span style=3D"font-size:10.0pt;color:black;"> Hannes Tschofenig=0A <hannes.tschofenig@gmx.net>
= =0ATo: Julian Reschke <julian.resch= ke@gmx.de> <= /span>
=0ACc:&= nbsp;"oauth@ietf.org" <oauth@ietf.org> 
=0ASent: Tuesday, June 12, 2012 11:01 AM=0ASubject: = ;Re: [OAUTH-WG] Discussion needed on username and password ABNF defi= nitions
=0A
=0A
=0A
=0A
=0A
=0A

=0AI had a chat with Julian= yesterday and here is my short summary. 
=0A
=0ASection 2.3 of the core draft de= fines client authentication based on two mechanisms (and provides room for = extensions):http://tools.ietf.org/html/dr= aft-ietf-oauth-v2-27#section-2.3
=0A
=0A1) HTTP Basic Authenticat= ion
=0A
=0A2) A custom OAuth authentication mechanism (which uses cli= ent_id and client_secret)
=0A
=0AWith HTTP Basic authentication the p= roblem is that this is a legacy technology and there is no internationaliza= tion support. 
=0A
=0AWith our brand new custom OAuth authentication mechanism we= have more options. = ;
=0A
=0AOne possible approach is to say that the clients are = devices (and not end users) and therefore internationalization does not mat= ter. 
=0A=
=0AIs it, however, really true that only US-ASCII characters will appea= r in the client_id and also in the client_secret? 
=0A
=0AHere we have the possib= ility to define something better. 
=0A
=0AIn any case we have to restrict the cha= racters that are used in these two authentication mechanisms since they cou= ld conflict with the way how we transport the data over the underlying prot= ocol. Julian mentioned this in his previous mails. 
=0A
=0AJulian, maybe you can = provide a detailed text proposal for how to address your comment in case we= go for UTF8 (with % encoding) for the custom OAuth client authentication m= echanism? =0A
=0ACiao
=0AHannes
=0A
=0AOn Jun 12, 2012, at 11:54 AM, Ju= lian Reschke wrote:
=0A
=0A> On 2012-06-12 00:16, Mike Jones wrote= :
=0A>> Reviewing the feedback from Julian, John, and James, I'm c= oming to the conclusion that client_id and client_secret, being for machine= s and not humans, shou ld be ASCII, whereas username and password should be= Unicode, since they are for humans.  Per John's=0A feedback, client_i= d can not contain a colon and be compatible with HTTP Basic.
=0A> 
=0A> I'm= not sure that restricting the character repertoire just because one way to= send requires this is the right approach. My preference would be not to pu= t this into the ABNF, and just to point out that certain characters will no= t work over certain transports,=0A and to just advise to avoid them.
=0A= > 
=0A= >> Therefore, I'd like to propose these updated ABNF definitions:
= =0A>> =
=0A>>    VSCHAR =3D %20-7E
=0A>>    = NOCOLONVSCHAR =3D %x20-39 / %x3B-7E
=0A>>    UNICODENOCT= RLCHAR =3D <Any Unicode character other than ( %x0-1F / %x7F )>
= =0A>> =
=0A>>    client-id =3D *NOCOLONVSCHAR
=0A>>&nb= sp;   client_secret =3D *VSCHAR
=0A>> 
=0A>>    userna= me =3D *UNICODENOCTRLCHAR
=0A>>    password =3D *UNICODE= NOCTRLCHAR
=0A>&nb= sp;
=0A> In this case you should add an introductory statement= pointing out that the ABNF defines the grammar in terms of Unicode code po= ints, not octets (as it is the case most of the time).
=0A> 
=0A>> It tu= rns out that non-ASCII characters are OK for username and password because = the Core spec only passes them in the form body - not using HTTP Basic - an= d UTF-8 encoding is specified.
=0A> 
=0A> I'll send a separate mail about t= hat, the current text in the spec is way too unspecific.
=0A> 
=0A>> &nb= sp;               --= Mike
=0A>>&nbs= p;
=0A>> P.S.  If anyone has a better ABNF for UNICODE= NOCTRLCHAR than "<Any Unicode character other than ( %x0-1F / %x7F )>= ", please send it to me!
=0A> 
=0A> As noted before, here's an example: <= ;http://greenbytes.de/tech/webdav/rfc5= 323.html#rfc.section.5.15.1>
=0A> 
=0A> Best regards, Julian
=0A&= gt; _______________________________________________
=0A> OAuth mailin= g list
=0A> <= /span>OAuth@ietf.org
=0A> https:= //www.ietf.org/mailman/listinfo/oauth
=0A
=0A____________________= ___________________________
=0AOAuth mailing list
=0AOAuth@ietf.org
=0Ahttps://www.ietf.org/m= ailman/listinfo/oauth
=0A
=0A
=0A
=0A
= =0A
=0A
=0A
=0A
=0A
=0A
=0A
=0A 
=0A
=0A
=0A<= /div>=0A
=0A
=0A
=0A
=0A
=0A
=0A
__________________= _____________________________
=0AOAuth mailing list
=0AOAuth@ietf.org
=0Ahttps://www.ietf.org= /mailman/listinfo/oauth
=0A
This message and any attachment a= re intended solely for the addressee and may contain confidential informati= on. If you have received this message in error, please send it back to me, = and immediately delete it. Please do not use, copy or disclose the informat= ion=0A contained in this message or in any attachment. Any views or opinion= s expressed by the author of this email do not necessarily reflect the view= s of the University of Nottingham.=0A
=0A
This message has been c= hecked for viruses but the contents of an attachment may still contain soft= ware viruses which could damage your computer system: you are advised to pe= rform your own checks. Email communications with the University of Nottingh= am may=0A be monitored as permitted by UK legislation.
=0A
_______________________________________________=
=0AOAuth mailing list
=0AOAuth@ietf.org<= /a>
=0Ahttps://www.ietf.org/mailman/listinfo/oauth =0A
=0A
 
=0A=0A
=0A
=0A=0A=0A=0A=0A
____= ___________________________________________
OAuth mailing list
OAuth@ietf.or= g
https://www.ietf.org/mailman/listinfo/oauth


= --258328648-923474063-1339708818=:17727-- From eran@hueniverse.com Thu Jun 14 14:22:31 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D06BA21F8491 for ; Thu, 14 Jun 2012 14:22:30 -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.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0g1wOk2FkORx for ; Thu, 14 Jun 2012 14:22:30 -0700 (PDT) Received: from p3plex2out04.prod.phx3.secureserver.net (p3plex2out04.prod.phx3.secureserver.net [184.168.131.18]) by ietfa.amsl.com (Postfix) with ESMTP id 0890C21F8464 for ; Thu, 14 Jun 2012 14:22:29 -0700 (PDT) Received: from P3PWEX2HT003.ex2.secureserver.net ([184.168.131.11]) by p3plex2out04.prod.phx3.secureserver.net with bizsmtp id NMNV1j0030EuLVk01MNVCd; Thu, 14 Jun 2012 14:22:29 -0700 Received: from P3PWEX2MB008.ex2.secureserver.net ([169.254.8.66]) by P3PWEX2HT003.ex2.secureserver.net ([184.168.131.11]) with mapi id 14.02.0247.003; Thu, 14 Jun 2012 14:22:29 -0700 From: Eran Hammer To: Mike Jones Thread-Topic: On the OAuth Core Spec Thread-Index: AQHNSMDROALpq7NLoUWJn1Mfr6HFMZb2/fwAgAPMPAD//4u1sA== Date: Thu, 14 Jun 2012 21:22:28 +0000 Message-ID: <0CBAEB56DDB3A140BA8E8C124C04ECA201073185@P3PWEX2MB008.ex2.secureserver.net> References: <0CBAEB56DDB3A140BA8E8C124C04ECA20106ED8B@P3PWEX2MB008.ex2.secureserver.net> <4E1F6AAD24975D4BA5B1680429673943665392B5@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943665392B5@TK5EX14MBXC284.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [37.46.45.194] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] On the OAuth Core Spec X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 21:22:31 -0000 Sounds good. Any progress on a revised 7.2? I'd like to get clarity on that so we can ag= ree on new text and close the issue along with the ABNF. EH > -----Original Message----- > From: Mike Jones [mailto:Michael.Jones@microsoft.com] > Sent: Thursday, June 14, 2012 2:18 PM > To: Eran Hammer > Cc: oauth@ietf.org > Subject: RE: On the OAuth Core Spec >=20 > FYI, Eran, I'm going to hold off sending you proposed updated ABNF text f= or > a few more days to let the discussions continue and consensus to build. = I'm > currently mentally targeting sending proposed draft updates Monday. >=20 > Best wishes, > -- Mike >=20 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Eran Hammer > Sent: Tuesday, June 12, 2012 11:53 AM > To: Derek Atkins > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] On the OAuth Core Spec >=20 > Derek - Thank you for this note. It is very much appreacited. >=20 > > From: Derek Atkins [mailto:derek@ihtfp.com] > > Sent: Tuesday, June 12, 2012 10:28 AM >=20 > > Having said that, are you still willing and able to be the editor of > > this draft and see it to its conclusion and publication? >=20 > Yes. >=20 > > If so, we will need to get another > > draft out by this Friday (June 15), and I suspect we'll need another > > draft that solves the encoding issue (brought up by the ABNF > > exercise), targeting Friday, June 29th. Do you think you can make > > these target dates (assuming that there is text for you to apply to the > draft)? >=20 > There are two main open issues I'm aware of: >=20 > 1. Error registry text >=20 > * The text provided by Mike Jones for section 7.2 is unlcear. I have prov= ided > feedback on the list and am waiting to hear back from Mike (or anyone els= e). > Once I understand the actual intention of the new normative language, I w= ill > rework the text to reflect those changes. While I have strong objections = to > the error code registry in genreal, once decided, my only goal is to ensu= re the > text is clear, complete, and reflects working group consensus. I do not h= ave > strong interest in how the working group resolves the rules around the > registry as long as they are clear and practical. The current text for 7.= 2 is not. >=20 > * In the consensus call for the error registry, Hannes requested (or > suggested, it wasn't clear given the context) that the registry be > implemented by IANA using separate tables. This requires prose changes to > instruct IANA as such. Without changes, IANA will create a single table w= hich > is not what was requested. I have not seen much discussion on this. I am > waiting for the chairs to clarify this and for someone to provide text if= this is > still the case (I have sent multiple emails on this to the list). >=20 > 2. ABNF >=20 > * Mike Jones is doing solid work progressing the ABNF forward with the > guidance of Julian. I trust Julian blindly to guide the text to a success= ful > conculsion and the working group seems enaged. As soon as new text is > available, I will incorporate and publish. If a schedule conflict arises = in which I > am unable to push the ABNF changes, I have no objections to Mike Jones > pushing a new draft with only ABNF related change after quick coordinatio= n > (Mike can submit using my contact and I'll approve it within a few hours)= . >=20 > I also have a short list of nits and typos reported to the list and me di= rectly > over the past few weeks which are all insignificant to list. >=20 > I am available to publish another draft on or by 6/14, and again on or by= 6/27 > (or 6/30 after my travel). I will be travelling on the exact dates listed= . I am > hoping that these dates are flexible within a few days range. In order fo= r me > to publish a new draft by 6/14, I will need the changes a day before to > prepare. If the changes are ABNF only, I can work with Mike Jones to arra= nge > it without putting my travel restriction in the way. I need the chairs to= clarify > what is expected in each of these drafts and how they seek to resolve the > issues around item #1 above to continue. >=20 > Again, thanks for the note. >=20 > EH > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 From eran@hueniverse.com Thu Jun 14 14:27:29 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1B7211E8083 for ; Thu, 14 Jun 2012 14:27:29 -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 shWsKZGZk6x0 for ; Thu, 14 Jun 2012 14:27:27 -0700 (PDT) Received: from p3plex2out01.prod.phx3.secureserver.net (p3plex2out01.prod.phx3.secureserver.net [184.168.131.12]) by ietfa.amsl.com (Postfix) with ESMTP id 1D57D21F8570 for ; Thu, 14 Jun 2012 14:27:27 -0700 (PDT) Received: from P3PWEX2HT002.ex2.secureserver.net ([184.168.131.10]) by p3plex2out01.prod.phx3.secureserver.net with bizsmtp id NMTS1j0040Dcg9U01MTSQY; Thu, 14 Jun 2012 14:27:26 -0700 Received: from P3PWEX2MB008.ex2.secureserver.net ([169.254.8.66]) by P3PWEX2HT002.ex2.secureserver.net ([184.168.131.10]) with mapi id 14.02.0247.003; Thu, 14 Jun 2012 14:27:26 -0700 From: Eran Hammer To: William Mills Thread-Topic: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion needed on username and password ABNF definitions Thread-Index: AQHNSnOHUUj9837t+EOJ/AwDThRme5b6Uufg Date: Thu, 14 Jun 2012 21:27:26 +0000 Message-ID: <0CBAEB56DDB3A140BA8E8C124C04ECA2010731F9@P3PWEX2MB008.ex2.secureserver.net> References: <4E1F6AAD24975D4BA5B168042967394366539292@TK5EX14MBXC284.redmond.corp.microsoft.com> <1339708818.17727.YahooMailNeo@web31808.mail.mud.yahoo.com> In-Reply-To: <1339708818.17727.YahooMailNeo@web31808.mail.mud.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [37.46.45.194] Content-Type: multipart/alternative; boundary="_000_0CBAEB56DDB3A140BA8E8C124C04ECA2010731F9P3PWEX2MB008ex2_" MIME-Version: 1.0 Cc: "oauth@ietf.org WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion needed on username and password ABNF definitions X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 21:27:29 -0000 --_000_0CBAEB56DDB3A140BA8E8C124C04ECA2010731F9P3PWEX2MB008ex2_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIHNlcnZlciBtdXN0IHN1cHBvcnQgQmFzaWMgc28gaWYgdGhpcyBpcyBub3QgcmVzb2x2ZWQs IHVzaW5nIGEgY29sb24gd2lsbCBicmVhayBzb21lIGltcGxlbWVudGF0aW9ucy4gTm90ZSB0aGF0 IHRoZXJlIGlzIGFuIGVhc3kgd2F5IG9mIHZhbGlkYXRpbmcgQmFzaWMgY3JlZGVudGlhbHMgZXZl biB3aGVuIHRoZSBjbGllbnQgaWQgaW5jbHVkZXMgYSBjb2xvbiBieSBub3QgcGFyc2luZyB0aGUg c3RyaW5nIG9uIHRoZSBzZXJ2ZXIgYW5kIGluc3RlYWQgYnVpbGRpbmcgdGhlIHNhbWUgc3RyaW5n IGFzIHRoZSBjbGllbnQuIFRoZXJlIGlzIG9mIGNvdXJzZSBhIHRoZW9yZXRpY2FsIHNlY3VyaXR5 IGlzc3VlIHdoZXJlIGEgdXNlcm5hbWUgd2l0aCBjb2xvbiBjYW4gbWF0Y2ggdGhlIHBhaXIgb2Yg YSB1c2VybmFtZSB3aXRob3V0IHdpdGggY29sb24gaW4gdGhlIHBhc3N3b3JkIGJ1dCB0aGF0J3Mg dmVyeSB1bmxpa2VseSBhbmQgbm90IHJlYWxseSBhbiBhdHRhY2sgdmVjdG9yIGlmIGNsaWVudCBp ZHMgYXJlIGlzc3VlZCBwcm9wZXJseS4NCg0KRWl0aGVyIHdheSwgSWYgY29sb24gaXMgdGhlIG9u bHkgaXNzdWUgaGVyZSwgd2Ugc2hvdWxkIGVpdGhlciBzcGVjaWZ5IGVuY29kaW5nIGZvciBCYXNp YyBvciBleGNsdWRlIGl0IGFuZCBsZWF2ZSBpdCB1cCB0byBvdGhlcnMgdG8gZGVmaW5lIGVuY29k aW5nIG9mIFVSSXMgYXMgY2xpZW50IGlkcy4gQSBmZXcgbW9udGhzIGFnbyBJIHdvdWxkIGhhdmUg YmVlbiBtb3JlIGVhZ2VyIHRvIHJldmlzaXQgdGhpcywgYnV0IGF0IHRoaXMgcG9pbnQsIHdlIG1h ZGUgb3VyIGJlZCB3aXRoIEJhc2ljIGFuZCBhcmUgcHJldHR5IG11Y2ggc3R1Y2sgd2l0aG91dCBj b2xvbiBpbiB0aGUgY2xpZW50IGlkLg0KDQpFSA0KDQoNCkZyb206IG9hdXRoLWJvdW5jZXNAaWV0 Zi5vcmcgW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgV2lsbGlh bSBNaWxscw0KU2VudDogVGh1cnNkYXksIEp1bmUgMTQsIDIwMTIgMjoyMCBQTQ0KVG86IE1pa2Ug Sm9uZXM7IEpvaG4gQnJhZGxleTsgVG9yc3RlbiBMb2RkZXJzdGVkdA0KQ2M6IEp1bGlhbiBSZXNj aGtlOyBSaWNoYXJkIE1vcnRpZXI7IG9hdXRoQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW09BVVRI LVdHXSBEeW5hbWljIGNsaWVudHMsIFVSSSwgYW5kIHN0dWZmIFJlOiBEaXNjdXNzaW9uIG5lZWRl ZCBvbiB1c2VybmFtZSBhbmQgcGFzc3dvcmQgQUJORiBkZWZpbml0aW9ucw0KDQpXaWxsIEJBU0lD IGF1dGggYmUgbmVlZGVkIGZvciBjbGllbnRzIHdpdGggYW4gSUQgaW4gdGhlIGZvcm0gb2YgYSBV Ukk/DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IE1pa2UgSm9u ZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNy b3NvZnQuY29tPj4NClRvOiBKb2huIEJyYWRsZXkgPHZlN2p0YkB2ZTdqdGIuY29tPG1haWx0bzp2 ZTdqdGJAdmU3anRiLmNvbT4+OyBUb3JzdGVuIExvZGRlcnN0ZWR0IDx0b3JzdGVuQGxvZGRlcnN0 ZWR0Lm5ldDxtYWlsdG86dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ+Pg0KQ2M6IEp1bGlhbiBSZXNj aGtlIDxqdWxpYW4ucmVzY2hrZUBnbXguZGU8bWFpbHRvOmp1bGlhbi5yZXNjaGtlQGdteC5kZT4+ OyBSaWNoYXJkIE1vcnRpZXIgPHJpY2hhcmQubW9ydGllckBub3R0aW5naGFtLmFjLnVrPG1haWx0 bzpyaWNoYXJkLm1vcnRpZXJAbm90dGluZ2hhbS5hYy51az4+OyAib2F1dGhAaWV0Zi5vcmc8bWFp bHRvOm9hdXRoQGlldGYub3JnPiIgPG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9y Zz4+DQpTZW50OiBUaHVyc2RheSwgSnVuZSAxNCwgMjAxMiAyOjE0IFBNDQpTdWJqZWN0OiBSZTog W09BVVRILVdHXSBEeW5hbWljIGNsaWVudHMsIFVSSSwgYW5kIHN0dWZmIFJlOiBEaXNjdXNzaW9u IG5lZWRlZCBvbiB1c2VybmFtZSBhbmQgcGFzc3dvcmQgQUJORiBkZWZpbml0aW9ucw0KDQpUaGUg bW9yZSBJIHRoaW5rIGFib3V0IGV4Y2x1ZGluZyB0aGUgcG9zc2liaWxpdHkgb2YgdXNpbmcgVVJJ cyBhcyBjbGllbnQgSURzLCB0aGUgbW9yZSB1bmNvbWZvcnRhYmxlIEkgYW0gd2l0aCBpdC4gIEni gJltIGluY3JlYXNpbmdseSB0aGlua2luZyB0aGF0IHdlIHNob3VsZCBhbGxvdyB0aGUgQVNDSUkg Y2hhcmFjdGVycyB1c2VkIGluIFVSSXMgKGFuZCBwcm9iYWJseSB0aGUgb3RoZXIgdmlzaWJsZSBv bmVzIGFuZCBzcGFjZSBhcyB3ZWxsLCBhcyBjdXJyZW50bHkgcHJvcG9zZWQpIGFuZCBoYXZlIHNw ZWNpYWwgbGFuZ3VhZ2UgYWJvdXQg4oCcQnV0IHdoYXQgaWYgdGhpcyBjbGllbnRfaWQgY29udGFp bmluZyBjb2xvbiBjaGFyYWN0ZXJzIGlzIHRvIGJlIHVzZWQgd2l0aCBIVFRQIEJhc2ljP+KAnQ0K DQpBcyBvbmUgc3VnZ2VzdGlvbiwgbWFpbmx5IHRvIHJlc3RhcnQgZGlzY3Vzc2lvbiAod2hpY2gg c2VlbXMgdG8gaGF2ZSBzdGFsbGVkKSwgd2UgY291bGQgc3VnZ2VzdCAob3IgcmVxdWlyZSkgdGhh dCBhbGwgY29sb24gY2hhcmFjdGVycyBpbiBjbGllbnRfaWRzIGJlIHN1YnN0aXR1dGVkIHdpdGgg dGFiIGNoYXJhY3RlcnMgKCV4MDkpLCB3aGljaCBhcmUgbGVnYWwgaW4gSFRUUCBCYXNpYyBidXQg bm90IGluIHRoZSBwcm9wb3NlZCBkZWZpbml0aW9uIG9mIGNsaWVudF9pZHMsIGJlZm9yZSB1c2Ug d2l0aCBIVFRQIEJhc2ljLCBhbmQgdGhhdCB0aGUgcmV2ZXJzZSBzdWJzdGl0dXRpb24gb2NjdXIg d2hlbiByZWNlaXZlZCBmcm9tIEhUVFAgQmFzaWMuICBPdGhlciB0cmFuc2Zvcm1hdGlvbnMgb3Ig ZW5jb2RpbmdzIGFyZSBwb3NzaWJsZS4gIFdlIGNvdWxkIGFsc28gY29wIG91dCBieSBzYXlpbmcg c29tZXRoaW5nIGxpa2Ug4oCcSWYgY2hhcmFjdGVycyBub3QgbGVnYWwgaW4gSFRUUCBCYXNpYyBv Y2N1ciBpbiB0aGUgY2xpZW50X2lkLCBhIHRyYW5zZm9ybWF0aW9uIGVuY29kaW5nIHRoZW0gbXVz dCBiZSBhZ3JlZWQgdG8gYnkgYm90aCBwYXJ0aWVz4oCdLiAgSSBkb27igJl0IGxvdmUgdGhlIHRh YiBpZGVhLCBiZWNhdXNlIGl04oCZcyBhZG1pdHRlZGx5IGEgaGFjaywgYnV0IEkgYmVsaWV2ZSBp dOKAmXMgYmV0dGVyIHRoYW4gcHJlY2x1ZGluZyB0aGUgdXNlIG9mIFVSSXMgYXMgY2xpZW50X2lk cy4NCg0KVGhvdWdodHM/DQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogb2F1dGgtYm91bmNlc0BpZXRm Lm9yZzxtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZz4gW21haWx0bzpvYXV0aC1ib3VuY2Vz QGlldGYub3JnXTxtYWlsdG86W21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXT4gT24gQmVo YWxmIE9mIEpvaG4gQnJhZGxleQ0KU2VudDogV2VkbmVzZGF5LCBKdW5lIDEzLCAyMDEyIDExOjQw IEFNDQpUbzogVG9yc3RlbiBMb2RkZXJzdGVkdA0KQ2M6IEp1bGlhbiBSZXNjaGtlOyBSaWNoYXJk IE1vcnRpZXI7IG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4NClN1YmplY3Q6 IFJlOiBbT0FVVEgtV0ddIER5bmFtaWMgY2xpZW50cywgVVJJLCBhbmQgc3R1ZmYgUmU6IERpc2N1 c3Npb24gbmVlZGVkIG9uIHVzZXJuYW1lIGFuZCBwYXNzd29yZCBBQk5GIGRlZmluaXRpb25zDQoN ClRoYXQgd291bGQgcHJvYmFibHkgd29yayBhcyB3ZWxsLiAgVGhhdCBpcyB3aHkgSSBhbSBub3Qg cGFydGljdWxhcmx5IGNvbmNlcm5lZCBhYm91dCBleGNsdWRpbmcgdGhlIDoNCg0KV2Ugb3JpZ2lu YWxseSB1c2VkIHRoZSBVUkkgaXRzZWxmLCAgbW9zdGx5IGZvciBjb252ZW5pZW5jZSBvZiBkZWJ1 Z2dpbmcsICBidXQgdGhlcmUgYXJlIG90aGVyIHBvdGVudGlhbCBvcHRpb25zLg0KDQpUaGUgYXV0 aG9yaXphdGlvbiBzZXJ2ZXIgbmVlZHMgdG8gY29tcGFyZSB0aGUgY2xpZW50X2lkIGFuZCB0aGUg cmVkaXJlY3QgdXJpLiBCdXQgaXQgY291bGQgY29tcGFyZSB0aGUgaGFzaCB3aXRoIG5vdCBtdWNo IG1vcmUgd29yay4gICBBbHNvIGEgc2hhMjU2IGhhc2ggaXMgcHJvYmFibHkgbG9uZ2VyIHRoYW4g dGhlIHVyaSBpdCBpcyBoYXNoaW5nLg0KDQpJIGFtIG5vdCBzdXBlciBjb25jZXJuZWQgd2l0aCBi ZWluZyBhYmxlIHRvIGhhdmUgOiBpbiB0aGUgY2xpZW50X2lkDQoNCkpvaG4gQi4NCg0KU2VudCBm cm9tIG15IGlQaG9uZQ0KDQpPbiAyMDEyLTA2LTEzLCBhdCA2OjAzIFBNLCBUb3JzdGVuIExvZGRl cnN0ZWR0IDx0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDxtYWlsdG86dG9yc3RlbkBsb2RkZXJzdGVk dC5uZXQ+PiB3cm90ZToNCkhpIEpvaG4sDQoNCndvdWxkIGl0IG1ha2Ugc2Vuc2UgdG8gdXNlIGEg aGFzaCBvZiB0aGUgVVJJIGluc3RlYWQgb2YgdGhlIFVSSSBpdHNlbGYgaW4geW91ciB1c2UgY2Fz ZT8NCg0KcmVnYXJkcywNClRvcnN0ZW4uDQoNCg0KSm9obiBCcmFkbGV5IDx2ZTdqdGJAdmU3anRi LmNvbTxtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20+PiBzY2hyaWViOg0KSSB0aGluayB0aGF0IHRo ZSBpc3N1ZXMgYXJlIGdldHRpbmcgY29uZnVzZWQuDQoNClRoZXJlIGlzIGEgdXNlIGNhc2Ugd2hl cmUgdGhlIEF1dGhvcml6YXRpb24gc2VydmVyIG1heSBiZSBhIGVtYmVkZGVkIGFwcCwgYXQgbGVh c3QgaW4gb25lIG9wZW5JRCBjYXNlLiAgICBBcyBpdCB3b24ndCBoYXZlIGEgc2VwYXJhdGUgcmVn aXN0cmF0aW9uIG9yIHRva2VuIGVuZHBvaW50LCAgdGhlIGNsaWVudCBuZWVkcyB0byBtYWtlIGl0 cyBvd24gY2xpZW50SUQgZm9yIHRoZSByZXF1ZXN0LiAgIEEgcmVhc29uYWJsZSB0aGluZyB0byB1 c2UgaXMgdGhlIHJlZGlyZWN0IFVSSSB0byBjcmVhdGUgYSB1bmlxdWUgdmFsdWUgdGhhdCB0aGUg dXNlciBjb3VsZCB1c2UgZm9yIHJldm9jYXRpb24gYXQgYSBsYXRlciBwb2ludC4NCg0KQ3VycmVu dGx5IHdpdGggdGhlIG5vIDogcmVzdHJpY3Rpb24gd2Ugd291bGQgdXNlIHRoZSBob3N0IGFuZCBw YXRoIHRvIGNyYXRlIHRoZSBjbGllbnRpZC4NClRoZXJlIGFyZSBzb21lIHNjZW5hcmlvcyB3aGVy ZSBoYXZpbmcgdGhlIHNjaGVtZSBhcyBwYXJ0IG9mIHRoYXQgd291bGQgYmUgaGVscGZ1bC4NCg0K VGhpcyBoYXMgbm90aGluZyB0byBkbyB3aXRoIGRpc2NvdmVyeSBvciB0aGUgZHluYW1pYyBjbGll bnQgcmVnaXN0cmF0aW9uIHByb3Bvc2FsIGFzIGZhciBhcyBJIGtub3cuDQoNCkEgVVJMIGFzIGEg Y2xpZW50X2lkIGNvbWVzIGZyb20gcHJvdG90eXBlIHdvcmsgZm9yIGEgcGVyc29uYWwgcHJvdmlk ZXIgdGhhdCB3ZSBhcmUgZG9pbmcgYXMgcGFydCBvZiBvcGVuSUQgQ29ubmVjdC4NCg0KSm9obiBC Lg0KT24gMjAxMi0wNi0xMywgYXQgNzo1MCBBTSwgVG9yc3RlbiBMb2RkZXJzdGVkdCB3cm90ZToN Cg0KSGkgYWxsLA0KDQpjYW4gYW55b25lIHBsZWFzZSBleHBsYWluIHRoZSByZWxhdGlvbiBiZXR3 ZWVuIGR5bmFtaWMgY2xpZW50IHJlZ2lzdHJhdGlvbiBhbmQgVVJJcyBhcyBjbGllbnQgaWRzPyBO b25lIG9mIHRoZSBjdXJyZW50IGRyYWZ0cyAodW1hIG9yIGNvbm5lY3QpIHNlZW0gdG8gcmVxdWly ZSBVUklzLg0KDQpyZWdhcmRzLA0KVG9yc3Rlbi4NCg0KDQpKaWFuaHVhIFNoYW8gPHBzeGpzNEBu b3R0aW5naGFtLmFjLnVrPG1haWx0bzpwc3hqczRAbm90dGluZ2hhbS5hYy51az4+IHNjaHJpZWI6 DQpIZWxsbywNCg0KRHluYW1pYyBjbGllbnQgcmVnaXN0cmF0aW9uIGlzIHZlcnkgdXNlZnVsIGlm IGNsaWVudCBvciByZXNvdXJjZSBvciBhdXRob3Jpc2F0aW9uIHNlcnZlciBpcyBub3QgcGVybWFu ZW50bHkgYXZhaWxhYmxlLg0KQSB0eXBpY2FsIGNhc2UgaXMgdGhhdCBpcyB0aGUgcmVzb3VyY2Ug b3IgYXV0aG9yaXNhdGlvbiBzZXJ2ZXIgaXMgaW4gbW9iaWxlIHBsYXRmb3JtLCB0aGUgY29ubmVj dGlvbiBpcyBub3QgYWx3YXlzIGF2YWlsYWJsZS4NCkFub3RoZXIgdHlwaWNhbCBjYXNlIGlzIHRo YXQgYXV0aG9yaXNhdGlvbiBzZXJ2ZXIgZG8gbm90IG5lY2Vzc2FyeSB0byBoYXZlIGNsaWVudCBw cmUtcmVnaXN0ZXJlZCBvbiBpdHNlbGYuIEF0IG1vbWVudCwgaW5kdXN0cnkgbGlrZSBmYWNlYm9v ayB3b3VsZCBsaWtlIGRldmVsb3BlciB0byByZWdpc3RlciBhIGFwcCBvbiBpdHMgYXBwIGNlbnRy ZSBmaXJzdCwgYW5kIHRoZW4gYXNrIHVzZXIgYXV0aCB0byB1c2UgdGhlIGFwcC4NCg0KV2UgYXJl IHJlc2VhcmNoZXJzIGZyb20gRGlnaXRhbCBFY29ub215IFJlc2VhcmNoIEluc3RpdHV0ZS4gV2Ug aGF2ZSB0aGlzIHByb2JsZW0gV2hlbiB3ZSBkZXZlbG9waW5nIERhdGF3YXJlIHRoYXQgY291bGQg bWFuYWdlIHRoZSBjb250cm9sIG9mIGFjY2VzcyB0byBwZXJzb25hbCBkYXRhLiBXZSBwbGF5IGFy b3VuZCBvdXIgc29sdXRpb24gYmFzZSBvbiBPYXV0aDI6IGh0dHBzOi8vZ2l0aHViLmNvbS9qaWFu aHVhc2hhby9kYXRhd2FyZS5jYXRhbG9nL3dpa2kNCg0KV2UgYXJlIGluIHRoZSBsaXN0IHRvIHJl Y2VpdmUgeW91ciBtYWlsIGxpc3QsIGJ1dCBjdXJyZW50bHkgbmVlZCBtb2RlcmF0ZSB0byBwb3N0 IGFueSBtZXNzYWdlLiBjYyBteSBjb2xsZWFndWUsIFJpY2hhcmQgTW9ydGllcg0KQmVzdA0KSmlh bg0KDQoNCk9uIDEyIEp1biAyMDEyLCBhdCAyMTowOCwgRXJhbiBIYW1tZXIgd3JvdGU6DQoNClRo ZSBvbmx5IGRpc3RpbmN0aW9uIEkgd291bGQgbWFrZSBpcyBiZXR3ZWVuIHJlbW92aW5nIGZsZXhp YmlsaXkgdG8gcHJvYWN0aXZlbHkgZW5hYmxpbmcgZnV0dXJlIGV4dGVuc2liaWxpdHkuIEkgd291 bGQgc3RvcCBzaG9ydCBvZiBwZXJzY3JpYmluZyBlbmNvZGluZyBpbiBvcmRlciB0byBmaXQgdXJp IGludG8gdGhlIEJhc2ljIGF1dGggZmllbGRzLiBCdXQgaWYgdGhlcmUgaXMgYSB3YXkgdG8gYWxs b3cgdGhpcyB0byBiZSBsZXNzIHJlc3RyaWN0aXZlIHdpdGhvdXQgY2xlYW4gaW50ZXJvcCBpc3N1 ZXMsIHRoYXQgd291bGQgYmUgbmljZS4NCg0KSSBkbyBhZ3JlZSB3ZSBuZWVkIHNvbWUgYWN0dWFs IHVzZSBjYXNlcyBiZWZvcmUgd2Ugc3BlbmQgbXVjaCBtb3JlIHRpbWUgb24gdGhpcy4NCg0KRUgN Cg0KRnJvbTogV2lsbGlhbSBNaWxscyBbbWFpbHRvOndtaWxsc0B5YWhvby1pbmMuY29tXTxtYWls dG86W21haWx0bzp3bWlsbHNAeWFob28taW5jLmNvbV0+DQpTZW50OiBUdWVzZGF5LCBKdW5lIDEy LCAyMDEyIDE6MDQgUE0NClRvOiBFcmFuIEhhbW1lcjsgTWlrZSBKb25lczsgSGFubmVzIFRzY2hv ZmVuaWc7IEp1bGlhbiBSZXNjaGtlDQpDYzogb2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGll dGYub3JnPg0KU3ViamVjdDogRHluYW1pYyBjbGllbnRzLCBVUkksIGFuZCBzdHVmZiBSZTogW09B VVRILVdHXSBEaXNjdXNzaW9uIG5lZWRlZCBvbiB1c2VybmFtZSBhbmQgcGFzc3dvcmQgQUJORiBk ZWZpbml0aW9ucw0KDQpJIHRoaW5rIGR5bmFtaWMgY2xpZW50IHJlZ2lzdHJhdGlvbiBpcyBzb21l dGhpbmcgd2UgaGF2ZSBub3QgdGFsa2VkIG91dCBlbm91Z2ggeWV0LiAgVGhlcmUncyBhIHByZXR0 eSBjbGVhciB1c2UgY2FzZSBmb3IgZHluYW1pYyByZWdpc3RyYXRpb24uDQoNCkRvZXMgaWRlbnRp ZnlpbmcgdGhlIGNsaWVudCB3aXRoIGEgVVJJIGFsbG93IHNvbWUgZm9ybSBvZiBPcGVuSUQtaXNo IGZsb3cgZm9yIHRoaXM/DQpJcyB0aGUgY2xpZW50IElEIGFzIGEgVVJJIGEgd2F5IHRvIGFsbG93 IGEgdHJ1c3RlZCBzaXRlIHRvIHByb3ZpZGUgbWV0YWRhdGEgYWJvdXQgdGhlIGNsaWVudD8NCklz IHRoYXQgVVJJIGEgd2F5IHRvIGhpdCBhbiBJRFAgd2UgdHJ1c3QgdG8gdmFsaWRhdGUgdGhlIGNs aWVudCBpbiBzb21lIHdheSB3aXRoIHRoZSBwcm92aWRlZCBzZWNyZXQ/DQoNCkkgZ3Vlc3Mgd2hh dCBJJ20gbG9va2luZyBmb3IgaGVyZSBpcyBhIGNvbmNyZXRlIHVzZSBjYXNlL3Byb2JsZW0gdG8g c29sdmUsIHJhdGhlciB0aGVuIGxlYXZpbmcgYSBob29rIHdlIHRoaW5rIGlzIHRoZSByaWdodCB0 aGluZy4NCg0KLWJpbGwNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJv bTogRXJhbiBIYW1tZXIgPGVyYW5AaHVlbml2ZXJzZS5jb208bWFpbHRvOmVyYW5AaHVlbml2ZXJz ZS5jb20+Pg0KVG86IE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTxtYWls dG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPj47IFdpbGxpYW0gTWlsbHMgPHdtaWxsc0B5 YWhvby1pbmMuY29tPG1haWx0bzp3bWlsbHNAeWFob28taW5jLmNvbT4+OyBIYW5uZXMgVHNjaG9m ZW5pZyA8aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldDxtYWlsdG86aGFubmVzLnRzY2hvZmVuaWdA Z214Lm5ldD4+OyBKdWxpYW4gUmVzY2hrZSA8anVsaWFuLnJlc2Noa2VAZ214LmRlPG1haWx0bzpq dWxpYW4ucmVzY2hrZUBnbXguZGU+Pg0KQ2M6ICJvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhA aWV0Zi5vcmc+IiA8b2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPj4NClNlbnQ6 IFR1ZXNkYXksIEp1bmUgMTIsIDIwMTIgMTE6MzkgQU0NClN1YmplY3Q6IFJFOiBbT0FVVEgtV0dd IERpc2N1c3Npb24gbmVlZGVkIG9uIHVzZXJuYW1lIGFuZCBwYXNzd29yZCBBQk5GIGRlZmluaXRp b25zDQoNCklzIHRoZSB1c2UgY2FzZSBvZiB1c2luZyBVUkkgYXMgY2xpZW50IGlkcyBpbXBvcnRh bnQ/IEl0IHNlZW1zIGxpa2Ugc29tZXRoaW5nIHRoYXQgbWlnaHQgYmVjb21lIHVzZWZ1bCBpbiB0 aGUgZnV0dXJlIHdoZXJlIGNsaWVudHMgY2FuIHVzZSB0aGVpciB2ZXJpZmlhYmxlIHNlcnZlcnMg dG8gYnlwYXNzIGNsaWVudCByZWdpc3RyYXRpb24gYW5kIHNpbWx5IHVzZSBhIFVSSSB0aGUgc2Vy dmVyIGNhbiB2YWxpZGF0ZSB2aWEgc29tZSBvdGhlciBtZWFucy4NCg0KSSBqdXN0IHdhbnQgdG8g bWFrZSBzdXJlIHRob3NlIHRoaW5raW5nIGFib3V0IG1vcmUgY29tcGxleCB1c2UgY2FzZXMgaW52 b2x2aW5nIGR5bmFtaWMgcmVnaXN0cmF0aW9uIG9yIGRpc3RyaSBidXRlZCBjbGllbnQgbWFuYW1n ZW5ldCBhcmUgYXdhcmUgb2YgdGhpcyBwb3RlbnRpYWwgcmVzdHJpY3Rpb24uDQoNCkknbSBmaW5l IGVpdGhlciB3YXkuDQoNCkVIDQoNCkZyb206IG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRv Om9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ108 bWFpbHRvOlttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10+IE9uIEJlaGFsZiBPZiBNaWtl IEpvbmVzDQpTZW50OiBUdWVzZGF5LCBKdW5lIDEyLCAyMDEyIDExOjI3IEFNDQpUbzogV2lsbGlh bSBNaWxsczsgSGFubmVzIFRzY2hvZmVuaWc7IEp1bGlhbiBSZXNjaGtlDQpDYzogb2F1dGhAaWV0 Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gRGlz Y3Vzc2lvbiBuZWVkZWQgb24gdXNlcm5hbWUgYW5kIHBhc3N3b3JkIEFCTkYgZGVmaW5pdGlvbnMN Cg0KTm90IGludGVybmF0aW9uYWxpemluZyBmaWVsZHMgaW50ZW5kZWQgZm9yIG1hY2hpbmUgY29u c3VtcHRpb24gb25seSBpcyBhbHJlYWR5IGEgcHJlY2VkZW50IHNldCBhbmQgYWdyZWVkIHRvIGJ5 IHRoZSB3b3JraW5nIGdyb3VwLCBzbyBsZXQgbWUgc2Vjb25kIEJpbGzigJlzIHBvaW50IGluIHRo YXQgcmVnYXJkLiAgRm9yIGluc3RhbmNlLCBuZWl0aGVyIOKAnHNjb3Bl4oCdIG5vciDigJxlcnJv cuKAnSBhbGxvdyBub24tQVNDSUkgY2hhcmFjdGVycy4NCg0KSnVsaWFuLCBpZiB5b3Ugd2FudCBk aWZmZXJlbnQgQUJORiB0ZXh0IHRoYW4gdGhlIHRleHQgSSB3cm90ZSBiZWxvdywgSSBiZWxpZXZl IGl0IHdvdWxkIGJlIG1vc3QgdXNlZnVsIGlmIHlvdSB3b3VsZCBwcm92aWRlIHRoZSBleGFjdCBy ZXBsYWNlIHdvcmRpbmcgdGhhdCB5b3XigJlkIGxpa2UgdG8gc2VlIGluc3RlYWQgb2YgaXQuICBU aGVuIHRoZXJl4oCZcyBubyBwb3NzaWJpbGl0eSBvZiBtaXN1bmRlcnN0YW5kaW5nIHRoZSBpbnRl bnQgb2Ygc3VnZ2VzdGVkIGNoYW5nZXMuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFRoYW5rcyBhbGwsDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoN CkZyb206IG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5v cmc+IFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ108bWFpbHRvOlttYWlsdG86b2F1dGgt Ym91bmNlc0BpZXRmLm9yZ10+IE9uIEJlaGFsZiBPZiBXaWxsaWFtIE1pbGxzDQpTZW50OiBUdWVz ZGF5LCBKdW5lIDEyLCAyMDEyIDExOjE4IEFNDQpUbzogSGFubmVzIFRzY2hvZmVuaWc7IEp1bGlh biBSZXNjaGtlDQpDYzogb2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPg0KU3Vi amVjdDogUmU6IFtPQVVUSC1XR10gRGlzY3Vzc2lvbiBuZWVkZWQgb24gdXNlcm5hbWUgYW5kIHBh c3N3b3JkIEFCTkYgZGVmaW5pdGlvbnMNCg0KSSBhZ3JlZSBnZW5lcmFsbHkgd2l0aCB5b3VyIGFz c3VtcHRpb24gYWJvdXQgY2xpZW50cywgYnV0IHJhdGhlciB0aGFuIHNheWluZyAiY2xpZW50cyBh cmUgZGV2aWNlcyIgSSB0aGluayBpdCBtYWtlcyBtdWNoIG1vcmUgc2Vuc2UgdG8gc2F5ICJjbGll bnRzIGFyZSBOT1QgdXNlcnMsIHNvIGNsaWVudF9pZCBuZWVkIG5vdCBiZSBpbnRlcm5hdGlvbmFs aXplZCIuICBJbiBwcmFjdGljYWwgdGVybXMgdGhlcmUgaXMgdmVyeSBsaXR0bGUgdG8gYXJndWUg Zm9yIGFueXRoaWduIGJleW9uZCBBU0NJSSBpbiBhIGNsaWVudF9zZWNyZXQsIGJhc2U2NCBlbmNv ZGluZyBvciB0aGUgZXF1aXZhbGVudCBiZWluZyBhIGZpbmUgd2F5IHRvIHRyYW5zcG9ydCBhcmJp dHJhcnkgYml0cyBpbiBhIHBvcnRhYmxlL3JlYXNvbmFibGUgd2F5Lg0KDQpJIGFyZ3VlIHRoYXQg Y2xpZW50X2lkIG5lZWQgbm90IGJlIGludGVybmF0aW9uYWxpemVkIGJlY2F1c2UgSSBhc3N1bWUg dGhhdCBhbnkgcmVhbGx5IGludGVybmF0aW9uYWxpemVkIGFwcGxpY2F0aW9uIHdpbGwgaGF2ZSBh biBpbnRlcm5hdGlvbmFsaXplZCBwcmVzZW50YXRpb24gbGF5ZXIgdGhhdCdzIHByZXNlbnRpbmcg YSBwcmV0dHkgbmFtZSBmb3IgdGhlIGNsaWVudF9pZC4NCg0KLWJpbGwNCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCkZyb206IEhhbm5lcyBUc2Nob2ZlbmlnIDxoYW5uZXMudHNj aG9mZW5pZ0BnbXgubmV0PG1haWx0bzpoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0Pj4NClRvOiBK dWxpYW4gUmVzY2hrZSA8anVsaWFuLnJlc2Noa2VAZ214LmRlPG1haWx0bzpqdWxpYW4ucmVzY2hr ZUBnbXguZGU+Pg0KQ2M6ICJvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+IiA8 b2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPj4NClNlbnQ6IFR1ZXNkYXksIEp1 bmUgMTIsIDIwMTIgMTE6MDEgQU0NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIERpc2N1c3Npb24g bmVlZGVkIG9uIHVzZXJuYW1lIGFuZCBwYXNzd29yZCBBQk5GIGRlZmluaXRpb25zDQoNCkkgaGFk IGEgY2hhdCB3aXRoIEp1bGlhbiB5ZXN0ZXJkYXkgYW5kIGhlcmUgaXMgbXkgc2hvcnQgc3VtbWFy eS4NCg0KU2VjdGlvbiAyLjMgb2YgdGhlIGNvcmUgZHJhZnQgZGVmaW5lcyBjbGllbnQgYXV0aGVu dGljYXRpb24gYmFzZWQgb24gdHdvIG1lY2hhbmlzbXMgKGFuZCBwcm92aWRlcyByb29tIGZvciBl eHRlbnNpb25zKTpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLXYy LTI3I3NlY3Rpb24tMi4zDQoNCjEpIEhUVFAgQmFzaWMgQXV0aGVudGljYXRpb24NCg0KMikgQSBj dXN0b20gT0F1dGggYXV0aGVudGljYXRpb24gbWVjaGFuaXNtICh3aGljaCB1c2VzIGNsaWVudF9p ZCBhbmQgY2xpZW50X3NlY3JldCkNCg0KV2l0aCBIVFRQIEJhc2ljIGF1dGhlbnRpY2F0aW9uIHRo ZSBwcm9ibGVtIGlzIHRoYXQgdGhpcyBpcyBhIGxlZ2FjeSB0ZWNobm9sb2d5IGFuZCB0aGVyZSBp cyBubyBpbnRlcm5hdGlvbmFsaXphdGlvbiBzdXBwb3J0Lg0KDQpXaXRoIG91ciBicmFuZCBuZXcg Y3VzdG9tIE9BdXRoIGF1dGhlbnRpY2F0aW9uIG1lY2hhbmlzbSB3ZSBoYXZlIG1vcmUgb3B0aW9u cy4NCg0KT25lIHBvc3NpYmxlIGFwcHJvYWNoIGlzIHRvIHNheSB0aGF0IHRoZSBjbGllbnRzIGFy ZSBkZXZpY2VzIChhbmQgbm90IGVuZCB1c2VycykgYW5kIHRoZXJlZm9yZSBpbnRlcm5hdGlvbmFs aXphdGlvbiBkb2VzIG5vdCBtYXR0ZXIuDQoNCklzIGl0LCBob3dldmVyLCByZWFsbHkgdHJ1ZSB0 aGF0IG9ubHkgVVMtQVNDSUkgY2hhcmFjdGVycyB3aWxsIGFwcGVhciBpbiB0aGUgY2xpZW50X2lk IGFuZCBhbHNvIGluIHRoZSBjbGllbnRfc2VjcmV0Pw0KDQpIZXJlIHdlIGhhdmUgdGhlIHBvc3Np YmlsaXR5IHRvIGRlZmluZSBzb21ldGhpbmcgYmV0dGVyLg0KDQpJbiBhbnkgY2FzZSB3ZSBoYXZl IHRvIHJlc3RyaWN0IHRoZSBjaGFyYWN0ZXJzIHRoYXQgYXJlIHVzZWQgaW4gdGhlc2UgdHdvIGF1 dGhlbnRpY2F0aW9uIG1lY2hhbmlzbXMgc2luY2UgdGhleSBjb3VsZCBjb25mbGljdCB3aXRoIHRo ZSB3YXkgaG93IHdlIHRyYW5zcG9ydCB0aGUgZGF0YSBvdmVyIHRoZSB1bmRlcmx5aW5nIHByb3Rv Y29sLiBKdWxpYW4gbWVudGlvbmVkIHRoaXMgaW4gaGlzIHByZXZpb3VzIG1haWxzLg0KDQpKdWxp YW4sIG1heWJlIHlvdSBjYW4gcHJvdmlkZSBhIGRldGFpbGVkIHRleHQgcHJvcG9zYWwgZm9yIGhv dyB0byBhZGRyZXNzIHlvdXIgY29tbWVudCBpbiBjYXNlIHdlIGdvIGZvciBVVEY4ICh3aXRoICUg ZW5jb2RpbmcpIGZvciB0aGUgY3VzdG9tIE9BdXRoIGNsaWVudCBhdXRoZW50aWNhdGlvbiBtZWNo YW5pc20/DQoNCkNpYW8NCkhhbm5lcw0KDQpPbiBKdW4gMTIsIDIwMTIsIGF0IDExOjU0IEFNLCBK dWxpYW4gUmVzY2hrZSB3cm90ZToNCg0KPiBPbiAyMDEyLTA2LTEyIDAwOjE2LCBNaWtlIEpvbmVz IHdyb3RlOg0KPj4gUmV2aWV3aW5nIHRoZSBmZWVkYmFjayBmcm9tIEp1bGlhbiwgSm9obiwgYW5k IEphbWVzLCBJJ20gY29taW5nIHRvIHRoZSBjb25jbHVzaW9uIHRoYXQgY2xpZW50X2lkIGFuZCBj bGllbnRfc2VjcmV0LCBiZWluZyBmb3IgbWFjaGluZXMgYW5kIG5vdCBodW1hbnMsIHNob3UgbGQg YmUgQVNDSUksIHdoZXJlYXMgdXNlcm5hbWUgYW5kIHBhc3N3b3JkIHNob3VsZCBiZSBVbmljb2Rl LCBzaW5jZSB0aGV5IGFyZSBmb3IgaHVtYW5zLiAgUGVyIEpvaG4ncyBmZWVkYmFjaywgY2xpZW50 X2lkIGNhbiBub3QgY29udGFpbiBhIGNvbG9uIGFuZCBiZSBjb21wYXRpYmxlIHdpdGggSFRUUCBC YXNpYy4NCj4NCj4gSSdtIG5vdCBzdXJlIHRoYXQgcmVzdHJpY3RpbmcgdGhlIGNoYXJhY3RlciBy ZXBlcnRvaXJlIGp1c3QgYmVjYXVzZSBvbmUgd2F5IHRvIHNlbmQgcmVxdWlyZXMgdGhpcyBpcyB0 aGUgcmlnaHQgYXBwcm9hY2guIE15IHByZWZlcmVuY2Ugd291bGQgYmUgbm90IHRvIHB1dCB0aGlz IGludG8gdGhlIEFCTkYsIGFuZCBqdXN0IHRvIHBvaW50IG91dCB0aGF0IGNlcnRhaW4gY2hhcmFj dGVycyB3aWxsIG5vdCB3b3JrIG92ZXIgY2VydGFpbiB0cmFuc3BvcnRzLCBhbmQgdG8ganVzdCBh ZHZpc2UgdG8gYXZvaWQgdGhlbS4NCj4NCj4+IFRoZXJlZm9yZSwgSSdkIGxpa2UgdG8gcHJvcG9z ZSB0aGVzZSB1cGRhdGVkIEFCTkYgZGVmaW5pdGlvbnM6DQo+Pg0KPj4gICAgVlNDSEFSID0gJTIw LTdFDQo+PiAgICBOT0NPTE9OVlNDSEFSID0gJXgyMC0zOSAvICV4M0ItN0UNCj4+ICAgIFVOSUNP REVOT0NUUkxDSEFSID0gPEFueSBVbmljb2RlIGNoYXJhY3RlciBvdGhlciB0aGFuICggJXgwLTFG IC8gJXg3RiApPg0KPj4NCj4+ICAgIGNsaWVudC1pZCA9ICpOT0NPTE9OVlNDSEFSDQo+PiAgICBj bGllbnRfc2VjcmV0ID0gKlZTQ0hBUg0KPj4NCj4+ICAgIHVzZXJuYW1lID0gKlVOSUNPREVOT0NU UkxDSEFSDQo+PiAgICBwYXNzd29yZCA9ICpVTklDT0RFTk9DVFJMQ0hBUg0KPg0KPiBJbiB0aGlz IGNhc2UgeW91IHNob3VsZCBhZGQgYW4gaW50cm9kdWN0b3J5IHN0YXRlbWVudCBwb2ludGluZyBv dXQgdGhhdCB0aGUgQUJORiBkZWZpbmVzIHRoZSBncmFtbWFyIGluIHRlcm1zIG9mIFVuaWNvZGUg Y29kZSBwb2ludHMsIG5vdCBvY3RldHMgKGFzIGl0IGlzIHRoZSBjYXNlIG1vc3Qgb2YgdGhlIHRp bWUpLg0KPg0KPj4gSXQgdHVybnMgb3V0IHRoYXQgbm9uLUFTQ0lJIGNoYXJhY3RlcnMgYXJlIE9L IGZvciB1c2VybmFtZSBhbmQgcGFzc3dvcmQgYmVjYXVzZSB0aGUgQ29yZSBzcGVjIG9ubHkgcGFz c2VzIHRoZW0gaW4gdGhlIGZvcm0gYm9keSAtIG5vdCB1c2luZyBIVFRQIEJhc2ljIC0gYW5kIFVU Ri04IGVuY29kaW5nIGlzIHNwZWNpZmllZC4NCj4NCj4gSSdsbCBzZW5kIGEgc2VwYXJhdGUgbWFp bCBhYm91dCB0aGF0LCB0aGUgY3VycmVudCB0ZXh0IGluIHRoZSBzcGVjIGlzIHdheSB0b28gdW5z cGVjaWZpYy4NCj4NCj4+ICAgICAgICAgICAgICAgICAtLSBNaWtlDQo+Pg0KPj4gUC5TLiAgSWYg YW55b25lIGhhcyBhIGJldHRlciBBQk5GIGZvciBVTklDT0RFTk9DVFJMQ0hBUiB0aGFuICI8QW55 IFVuaWNvZGUgY2hhcmFjdGVyIG90aGVyIHRoYW4gKCAleDAtMUYgLyAleDdGICk+IiwgcGxlYXNl IHNlbmQgaXQgdG8gbWUhDQo+DQo+IEFzIG5vdGVkIGJlZm9yZSwgaGVyZSdzIGFuIGV4YW1wbGU6 IDxodHRwOi8vZ3JlZW5ieXRlcy5kZS90ZWNoL3dlYmRhdi9yZmM1MzIzLmh0bWwjcmZjLnNlY3Rp b24uNS4xNS4xPg0KPg0KPiBCZXN0IHJlZ2FyZHMsIEp1bGlhbg0KPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4g T0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3Jn PG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vb2F1dGgNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGll dGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KVGhp cyBtZXNzYWdlIGFuZCBhbnkgYXR0YWNobWVudCBhcmUgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUg YWRkcmVzc2VlIGFuZCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24uIElmIHlv dSBoYXZlIHJlY2VpdmVkIHRoaXMgbWVzc2FnZSBpbiBlcnJvciwgcGxlYXNlIHNlbmQgaXQgYmFj ayB0byBtZSwgYW5kIGltbWVkaWF0ZWx5IGRlbGV0ZSBpdC4gUGxlYXNlIGRvIG5vdCB1c2UsIGNv cHkgb3IgZGlzY2xvc2UgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1lc3NhZ2Ug b3IgaW4gYW55IGF0dGFjaG1lbnQuIEFueSB2aWV3cyBvciBvcGluaW9ucyBleHByZXNzZWQgYnkg dGhlIGF1dGhvciBvZiB0aGlzIGVtYWlsIGRvIG5vdCBuZWNlc3NhcmlseSByZWZsZWN0IHRoZSB2 aWV3cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBOb3R0aW5naGFtLg0KVGhpcyBtZXNzYWdlIGhhcyBi ZWVuIGNoZWNrZWQgZm9yIHZpcnVzZXMgYnV0IHRoZSBjb250ZW50cyBvZiBhbiBhdHRhY2htZW50 IG1heSBzdGlsbCBjb250YWluIHNvZnR3YXJlIHZpcnVzZXMgd2hpY2ggY291bGQgZGFtYWdlIHlv dXIgY29tcHV0ZXIgc3lzdGVtOiB5b3UgYXJlIGFkdmlzZWQgdG8gcGVyZm9ybSB5b3VyIG93biBj aGVja3MuIEVtYWlsIGNvbW11bmljYXRpb25zIHdpdGggdGhlIFVuaXZlcnNpdHkgb2YgTm90dGlu Z2hhbSBtYXkgYmUgbW9uaXRvcmVkIGFzIHBlcm1pdHRlZCBieSBVSyBsZWdpc2xhdGlvbi4NCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWls aW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0 aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg== --_000_0CBAEB56DDB3A140BA8E8C124C04ECA2010731F9P3PWEX2MB008ex2_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQg MyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Iiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1y aWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGlu Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNl cmlmIjt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIi Ow0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBw dDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KcC55aXYxODAxMTc4ODc4 bXNvYWNldGF0ZSwgbGkueWl2MTgwMTE3ODg3OG1zb2FjZXRhdGUsIGRpdi55aXYxODAxMTc4ODc4 bXNvYWNldGF0ZQ0KCXttc28tc3R5bGUtbmFtZTp5aXYxODAxMTc4ODc4bXNvYWNldGF0ZTsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KcC55aXYxODAxMTc4ODc4 bXNvbm9ybWFsLCBsaS55aXYxODAxMTc4ODc4bXNvbm9ybWFsLCBkaXYueWl2MTgwMTE3ODg3OG1z b25vcm1hbA0KCXttc28tc3R5bGUtbmFtZTp5aXYxODAxMTc4ODc4bXNvbm9ybWFsOw0KCW1zby1t YXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9u dC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpwLnlpdjE4MDExNzg4Nzhtc29j aHBkZWZhdWx0LCBsaS55aXYxODAxMTc4ODc4bXNvY2hwZGVmYXVsdCwgZGl2LnlpdjE4MDExNzg4 Nzhtc29jaHBkZWZhdWx0DQoJe21zby1zdHlsZS1uYW1lOnlpdjE4MDExNzg4Nzhtc29jaHBkZWZh dWx0Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZTox Mi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpzcGFuLnlp djE4MDExNzg4Nzhtc29oeXBlcmxpbmsNCgl7bXNvLXN0eWxlLW5hbWU6eWl2MTgwMTE3ODg3OG1z b2h5cGVybGluazt9DQpzcGFuLnlpdjE4MDExNzg4Nzhtc29oeXBlcmxpbmtmb2xsb3dlZA0KCXtt c28tc3R5bGUtbmFtZTp5aXYxODAxMTc4ODc4bXNvaHlwZXJsaW5rZm9sbG93ZWQ7fQ0Kc3Bhbi55 aXYxODAxMTc4ODc4ZW1haWxzdHlsZTE5DQoJe21zby1zdHlsZS1uYW1lOnlpdjE4MDExNzg4Nzhl bWFpbHN0eWxlMTk7fQ0Kc3Bhbi55aXYxODAxMTc4ODc4YmFsbG9vbnRleHRjaGFyDQoJe21zby1z dHlsZS1uYW1lOnlpdjE4MDExNzg4NzhiYWxsb29udGV4dGNoYXI7fQ0KcC55aXYxODAxMTc4ODc4 bXNvbm9ybWFsMSwgbGkueWl2MTgwMTE3ODg3OG1zb25vcm1hbDEsIGRpdi55aXYxODAxMTc4ODc4 bXNvbm9ybWFsMQ0KCXttc28tc3R5bGUtbmFtZTp5aXYxODAxMTc4ODc4bXNvbm9ybWFsMTsNCglt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi55aXYxODAxMTc4 ODc4bXNvaHlwZXJsaW5rMQ0KCXttc28tc3R5bGUtbmFtZTp5aXYxODAxMTc4ODc4bXNvaHlwZXJs aW5rMTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi55 aXYxODAxMTc4ODc4bXNvaHlwZXJsaW5rZm9sbG93ZWQxDQoJe21zby1zdHlsZS1uYW1lOnlpdjE4 MDExNzg4Nzhtc29oeXBlcmxpbmtmb2xsb3dlZDE7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC55aXYxODAxMTc4ODc4bXNvYWNldGF0ZTEsIGxpLnlpdjE4 MDExNzg4Nzhtc29hY2V0YXRlMSwgZGl2LnlpdjE4MDExNzg4Nzhtc29hY2V0YXRlMQ0KCXttc28t c3R5bGUtbmFtZTp5aXYxODAxMTc4ODc4bXNvYWNldGF0ZTE7DQoJbWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJBcmlh bCIsInNhbnMtc2VyaWYiO30NCnNwYW4ueWl2MTgwMTE3ODg3OGVtYWlsc3R5bGUxOTENCgl7bXNv LXN0eWxlLW5hbWU6eWl2MTgwMTE3ODg3OGVtYWlsc3R5bGUxOTE7DQoJZm9udC1mYW1pbHk6IkFy aWFsIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLnlpdjE4MDExNzg4Nzhi YWxsb29udGV4dGNoYXIxDQoJe21zby1zdHlsZS1uYW1lOnlpdjE4MDExNzg4NzhiYWxsb29udGV4 dGNoYXIxOw0KCWZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO30NCnAueWl2MTgwMTE3 ODg3OG1zb2NocGRlZmF1bHQxLCBsaS55aXYxODAxMTc4ODc4bXNvY2hwZGVmYXVsdDEsIGRpdi55 aXYxODAxMTc4ODc4bXNvY2hwZGVmYXVsdDENCgl7bXNvLXN0eWxlLW5hbWU6eWl2MTgwMTE3ODg3 OG1zb2NocGRlZmF1bHQxOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdo dDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0K CWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlm Ijt9DQpzcGFuLnlpdjE4MDExNzg4NzhhcHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxl LW5hbWU6eWl2MTgwMTE3ODg3OGFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLkVtYWlsU3R5 bGUzMw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5CYWxsb29uVGV4dENo YXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6 IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4 PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i MSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5 IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9Ildv cmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlIHNlcnZlciBtdXN0IHN1cHBvcnQgQmFzaWMgc28gaWYg dGhpcyBpcyBub3QgcmVzb2x2ZWQsIHVzaW5nIGEgY29sb24gd2lsbCBicmVhayBzb21lIGltcGxl bWVudGF0aW9ucy4gTm90ZSB0aGF0IHRoZXJlIGlzIGFuIGVhc3kgd2F5IG9mIHZhbGlkYXRpbmcg QmFzaWMNCiBjcmVkZW50aWFscyBldmVuIHdoZW4gdGhlIGNsaWVudCBpZCBpbmNsdWRlcyBhIGNv bG9uIGJ5IG5vdCBwYXJzaW5nIHRoZSBzdHJpbmcgb24gdGhlIHNlcnZlciBhbmQgaW5zdGVhZCBi dWlsZGluZyB0aGUgc2FtZSBzdHJpbmcgYXMgdGhlIGNsaWVudC4gVGhlcmUgaXMgb2YgY291cnNl IGEgdGhlb3JldGljYWwgc2VjdXJpdHkgaXNzdWUgd2hlcmUgYSB1c2VybmFtZSB3aXRoIGNvbG9u IGNhbiBtYXRjaCB0aGUgcGFpciBvZiBhIHVzZXJuYW1lIHdpdGhvdXQNCiB3aXRoIGNvbG9uIGlu IHRoZSBwYXNzd29yZCBidXQgdGhhdCdzIHZlcnkgdW5saWtlbHkgYW5kIG5vdCByZWFsbHkgYW4g YXR0YWNrIHZlY3RvciBpZiBjbGllbnQgaWRzIGFyZSBpc3N1ZWQgcHJvcGVybHkuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5FaXRoZXIgd2F5LCBJZiBjb2xvbiBpcyB0aGUgb25seSBpc3N1ZSBoZXJlLCB3ZSBzaG91bGQg ZWl0aGVyIHNwZWNpZnkgZW5jb2RpbmcgZm9yIEJhc2ljIG9yIGV4Y2x1ZGUgaXQgYW5kIGxlYXZl IGl0IHVwIHRvIG90aGVycyB0byBkZWZpbmUgZW5jb2Rpbmcgb2YgVVJJcw0KIGFzIGNsaWVudCBp ZHMuIEEgZmV3IG1vbnRocyBhZ28gSSB3b3VsZCBoYXZlIGJlZW4gbW9yZSBlYWdlciB0byByZXZp c2l0IHRoaXMsIGJ1dCBhdCB0aGlzIHBvaW50LCB3ZSBtYWRlIG91ciBiZWQgd2l0aCBCYXNpYyBh bmQgYXJlIHByZXR0eSBtdWNoIHN0dWNrIHdpdGhvdXQgY29sb24gaW4gdGhlIGNsaWVudCBpZC48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPkVIPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6 MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBvYXV0aC1ib3VuY2VzQGlldGYu b3JnIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+ V2lsbGlhbSBNaWxsczxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgSnVuZSAxNCwgMjAxMiAy OjIwIFBNPGJyPg0KPGI+VG86PC9iPiBNaWtlIEpvbmVzOyBKb2huIEJyYWRsZXk7IFRvcnN0ZW4g TG9kZGVyc3RlZHQ8YnI+DQo8Yj5DYzo8L2I+IEp1bGlhbiBSZXNjaGtlOyBSaWNoYXJkIE1vcnRp ZXI7IG9hdXRoQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIER5 bmFtaWMgY2xpZW50cywgVVJJLCBhbmQgc3R1ZmYgUmU6IERpc2N1c3Npb24gbmVlZGVkIG9uIHVz ZXJuYW1lIGFuZCBwYXNzd29yZCBBQk5GIGRlZmluaXRpb25zPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3Vu ZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPldpbGwgQkFTSUMgYXV0aCBiZSBuZWVkZWQg Zm9yIGNsaWVudHMgd2l0aCBhbiBJRCBpbiB0aGUgZm9ybSBvZiBhIFVSST88bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFj a2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjMTAxMEZGIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQ7 bWFyZ2luLWxlZnQ6My43NXB0O21hcmdpbi10b3A6My43NXB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTQuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0 LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPg0KPGhyIHNpemU9IjEiIHdpZHRoPSIxMDAlIiBhbGlnbj0iY2VudGVy Ij4NCjwvc3Bhbj48L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5k OndoaXRlIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+IE1pa2UgSm9u ZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iPk1pY2hh ZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7PGJyPg0KPGI+VG86PC9iPiBKb2huIEJyYWRs ZXkgJmx0OzxhIGhyZWY9Im1haWx0bzp2ZTdqdGJAdmU3anRiLmNvbSI+dmU3anRiQHZlN2p0Yi5j b208L2E+Jmd0OzsgVG9yc3RlbiBMb2RkZXJzdGVkdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRvcnN0 ZW5AbG9kZGVyc3RlZHQubmV0Ij50b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDwvYT4mZ3Q7DQo8YnI+ DQo8Yj5DYzo8L2I+IEp1bGlhbiBSZXNjaGtlICZsdDs8YSBocmVmPSJtYWlsdG86anVsaWFuLnJl c2Noa2VAZ214LmRlIj5qdWxpYW4ucmVzY2hrZUBnbXguZGU8L2E+Jmd0OzsgUmljaGFyZCBNb3J0 aWVyICZsdDs8YSBocmVmPSJtYWlsdG86cmljaGFyZC5tb3J0aWVyQG5vdHRpbmdoYW0uYWMudWsi PnJpY2hhcmQubW9ydGllckBub3R0aW5naGFtLmFjLnVrPC9hPiZndDs7ICZxdW90OzxhIGhyZWY9 Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+b2F1dGhAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBo cmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPm9hdXRoQGlldGYub3JnPC9hPiZndDsNCjxicj4N CjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgSnVuZSAxNCwgMjAxMiAyOjE0IFBNPGJyPg0KPGI+U3Vi amVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIER5bmFtaWMgY2xpZW50cywgVVJJLCBhbmQgc3R1ZmYg UmU6IERpc2N1c3Npb24gbmVlZGVkIG9uIHVzZXJuYW1lIGFuZCBwYXNzd29yZCBBQk5GIGRlZmlu aXRpb25zPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2IGlkPSJ5aXYxODAxMTc4ODc4Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj5UaGUgbW9yZSBJIHRoaW5rIGFib3V0IGV4Y2x1ZGlu ZyB0aGUgcG9zc2liaWxpdHkgb2YgdXNpbmcgVVJJcyBhcyBjbGllbnQgSURzLCB0aGUgbW9yZSB1 bmNvbWZvcnRhYmxlIEkgYW0gd2l0aCBpdC4mbmJzcDsgSeKAmW0gaW5jcmVhc2luZ2x5IHRoaW5r aW5nIHRoYXQgd2Ugc2hvdWxkIGFsbG93IHRoZQ0KIEFTQ0lJIGNoYXJhY3RlcnMgdXNlZCBpbiBV UklzIChhbmQgcHJvYmFibHkgdGhlIG90aGVyIHZpc2libGUgb25lcyBhbmQgc3BhY2UgYXMgd2Vs bCwgYXMgY3VycmVudGx5IHByb3Bvc2VkKSBhbmQgaGF2ZSBzcGVjaWFsIGxhbmd1YWdlIGFib3V0 IOKAnEJ1dCB3aGF0IGlmIHRoaXMgY2xpZW50X2lkIGNvbnRhaW5pbmcgY29sb24gY2hhcmFjdGVy cyBpcyB0byBiZSB1c2VkIHdpdGggSFRUUCBCYXNpYz/igJ08L3NwYW4+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPkFzIG9uZSBzdWdnZXN0aW9uLCBtYWlubHkgdG8gcmVz dGFydCBkaXNjdXNzaW9uICh3aGljaCBzZWVtcyB0byBoYXZlIHN0YWxsZWQpLCB3ZSBjb3VsZCBz dWdnZXN0IChvciByZXF1aXJlKSB0aGF0IGFsbCBjb2xvbiBjaGFyYWN0ZXJzIGluIGNsaWVudF9p ZHMgYmUgc3Vic3RpdHV0ZWQgd2l0aA0KIHRhYiBjaGFyYWN0ZXJzICgleDA5KSwgd2hpY2ggYXJl IGxlZ2FsIGluIEhUVFAgQmFzaWMgYnV0IG5vdCBpbiB0aGUgcHJvcG9zZWQgZGVmaW5pdGlvbiBv ZiBjbGllbnRfaWRzLCBiZWZvcmUgdXNlIHdpdGggSFRUUCBCYXNpYywgYW5kIHRoYXQgdGhlIHJl dmVyc2Ugc3Vic3RpdHV0aW9uIG9jY3VyIHdoZW4gcmVjZWl2ZWQgZnJvbSBIVFRQIEJhc2ljLiZu YnNwOyBPdGhlciB0cmFuc2Zvcm1hdGlvbnMgb3IgZW5jb2RpbmdzIGFyZSBwb3NzaWJsZS4mbmJz cDsgV2UNCiBjb3VsZCBhbHNvIGNvcCBvdXQgYnkgc2F5aW5nIHNvbWV0aGluZyBsaWtlIOKAnElm IGNoYXJhY3RlcnMgbm90IGxlZ2FsIGluIEhUVFAgQmFzaWMgb2NjdXIgaW4gdGhlIGNsaWVudF9p ZCwgYSB0cmFuc2Zvcm1hdGlvbiBlbmNvZGluZyB0aGVtIG11c3QgYmUgYWdyZWVkIHRvIGJ5IGJv dGggcGFydGllc+KAnS4mbmJzcDsgSSBkb27igJl0IGxvdmUgdGhlIHRhYiBpZGVhLCBiZWNhdXNl IGl04oCZcyBhZG1pdHRlZGx5IGEgaGFjaywgYnV0IEkgYmVsaWV2ZSBpdOKAmXMgYmV0dGVyDQog dGhhbiBwcmVjbHVkaW5nIHRoZSB1c2Ugb2YgVVJJcyBhcyBjbGllbnRfaWRzLjwvc3Bhbj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+VGhvdWdodHM/PC9zcGFuPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTwv c3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRl Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0 REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2siPg0KPGEgaHJlZj0ibWFpbHRvOm9hdXRoLWJvdW5jZXNA aWV0Zi5vcmciPm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IDxhIGhyZWY9Im1haWx0bzpbbWFp bHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIj4NClttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRm Lm9yZ108L2E+IDxiPk9uIEJlaGFsZiBPZiA8L2I+Sm9obiBCcmFkbGV5PGJyPg0KPGI+U2VudDo8 L2I+IFdlZG5lc2RheSwgSnVuZSAxMywgMjAxMiAxMTo0MCBBTTxicj4NCjxiPlRvOjwvYj4gVG9y c3RlbiBMb2RkZXJzdGVkdDxicj4NCjxiPkNjOjwvYj4gSnVsaWFuIFJlc2Noa2U7IFJpY2hhcmQg TW9ydGllcjsgPGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIj5vYXV0aEBpZXRmLm9yZzwv YT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gRHluYW1pYyBjbGllbnRzLCBV UkksIGFuZCBzdHVmZiBSZTogRGlzY3Vzc2lvbiBuZWVkZWQgb24gdXNlcm5hbWUgYW5kIHBhc3N3 b3JkIEFCTkYgZGVmaW5pdGlvbnM8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPlRoYXQgd291bGQgcHJvYmFibHkgd29yayBhcyB3ZWxsLiAmbmJz cDtUaGF0IGlzIHdoeSBJIGFtIG5vdCBwYXJ0aWN1bGFybHkgY29uY2VybmVkIGFib3V0IGV4Y2x1 ZGluZyB0aGUgOiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRl Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPldlIG9yaWdpbmFs bHkgdXNlZCB0aGUgVVJJIGl0c2VsZiwgJm5ic3A7bW9zdGx5IGZvciBjb252ZW5pZW5jZSBvZiBk ZWJ1Z2dpbmcsICZuYnNwO2J1dCB0aGVyZSBhcmUgb3RoZXIgcG90ZW50aWFsIG9wdGlvbnMuJm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+VGhlIGF1dGhvcml6YXRpb24gc2VydmVy IG5lZWRzIHRvIGNvbXBhcmUgdGhlIGNsaWVudF9pZCBhbmQgdGhlIHJlZGlyZWN0IHVyaS4gQnV0 IGl0IGNvdWxkIGNvbXBhcmUgdGhlIGhhc2ggd2l0aCBub3QgbXVjaCBtb3JlIHdvcmsuICZuYnNw OyBBbHNvIGEgc2hhMjU2IGhhc2ggaXMgcHJvYmFibHkgbG9uZ2VyIHRoYW4gdGhlIHVyaQ0KIGl0 IGlzIGhhc2hpbmcuICZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndo aXRlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkkgYW0gbm90 IHN1cGVyIGNvbmNlcm5lZCB3aXRoIGJlaW5nIGFibGUgdG8gaGF2ZSA6IGluIHRoZSBjbGllbnRf aWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3 aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5Kb2huIEIuJm5ic3A7PGJyPg0KPGJyPg0K U2VudCBmcm9tIG15IGlQaG9uZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+PGJyPg0KT24gMjAxMi0wNi0xMywgYXQgNjowMyBQTSwgVG9yc3RlbiBMb2RkZXJzdGVkdCAm bHQ7PGEgaHJlZj0ibWFpbHRvOnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0IiB0YXJnZXQ9Il9ibGFu ayI+dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWJvdHRv bToxMi4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUi PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+SGkgSm9obiw8YnI+DQo8YnI+DQp3b3VsZCBpdCBt YWtlIHNlbnNlIHRvIHVzZSBhIGhhc2ggb2YgdGhlIFVSSSBpbnN0ZWFkIG9mIHRoZSBVUkkgaXRz ZWxmIGluIHlvdXIgdXNlIGNhc2U/PGJyPg0KPGJyPg0KcmVnYXJkcyw8YnI+DQpUb3JzdGVuLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij48YnI+DQo8YnI+DQpKb2huIEJyYWRsZXkgJmx0OzxhIGhyZWY9Im1haWx0bzp2ZTdqdGJAdmU3 anRiLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnZlN2p0YkB2ZTdqdGIuY29tPC9hPiZndDsgc2Nocmll Yjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5J IHRoaW5rIHRoYXQgdGhlIGlzc3VlcyBhcmUgZ2V0dGluZyBjb25mdXNlZC48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+VGhlcmUgaXMgYSB1c2UgY2FzZSB3aGVyZSB0aGUgQXV0aG9yaXphdGlvbiBzZXJ2 ZXIgbWF5IGJlIGEgZW1iZWRkZWQgYXBwLCBhdCBsZWFzdCBpbiBvbmUgb3BlbklEIGNhc2UuICZu YnNwOyAmbmJzcDtBcyBpdCB3b24ndCBoYXZlIGEgc2VwYXJhdGUgcmVnaXN0cmF0aW9uIG9yIHRv a2VuIGVuZHBvaW50LCAmbmJzcDt0aGUgY2xpZW50IG5lZWRzIHRvDQogbWFrZSBpdHMgb3duIGNs aWVudElEIGZvciB0aGUgcmVxdWVzdC4gJm5ic3A7IEEgcmVhc29uYWJsZSB0aGluZyB0byB1c2Ug aXMgdGhlIHJlZGlyZWN0IFVSSSB0byBjcmVhdGUgYSB1bmlxdWUgdmFsdWUgdGhhdCB0aGUgdXNl ciBjb3VsZCB1c2UgZm9yIHJldm9jYXRpb24gYXQgYSBsYXRlciBwb2ludC48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj5DdXJyZW50bHkgd2l0aCB0aGUgbm8gOiByZXN0cmljdGlvbiB3ZSB3 b3VsZCB1c2UgdGhlIGhvc3QgYW5kIHBhdGggdG8gY3JhdGUgdGhlIGNsaWVudGlkLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPlRoZXJlIGFyZSBzb21lIHNjZW5hcmlvcyB3aGVyZSBoYXZpbmcgdGhlIHNjaGVtZSBhcyBw YXJ0IG9mIHRoYXQgd291bGQgYmUgaGVscGZ1bC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFj a2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij5UaGlzIGhhcyBub3RoaW5nIHRvIGRvIHdpdGggZGlzY292ZXJ5IG9yIHRoZSBkeW5hbWljIGNs aWVudCByZWdpc3RyYXRpb24gcHJvcG9zYWwgYXMgZmFyIGFzIEkga25vdy48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj5BIFVSTCBhcyBhIGNsaWVudF9pZCBjb21lcyBmcm9tIHByb3RvdHlw ZSB3b3JrIGZvciBhIHBlcnNvbmFsIHByb3ZpZGVyIHRoYXQgd2UgYXJlIGRvaW5nIGFzIHBhcnQg b2Ygb3BlbklEIENvbm5lY3QuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hp dGUiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Sm9obiBCLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+T24gMjAxMi0wNi0xMywgYXQgNzo1MCBBTSwgVG9yc3RlbiBMb2RkZXJzdGVkdCB3 cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdDtiYWNrZ3JvdW5kOndo aXRlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPkhpIGFsbCw8YnI+DQo8YnI+DQpjYW4gYW55b25lIHBsZWFzZSBleHBsYWlu IHRoZSByZWxhdGlvbiBiZXR3ZWVuIGR5bmFtaWMgY2xpZW50IHJlZ2lzdHJhdGlvbiBhbmQgVVJJ cyBhcyBjbGllbnQgaWRzPyBOb25lIG9mIHRoZSBjdXJyZW50IGRyYWZ0cyAodW1hIG9yIGNvbm5l Y3QpIHNlZW0gdG8gcmVxdWlyZSBVUklzLjxicj4NCjxicj4NCnJlZ2FyZHMsPGJyPg0KVG9yc3Rl bi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+PGJyPg0KPGJyPg0KSmlhbmh1YSBTaGFvICZsdDs8YSBocmVmPSJtYWlsdG86cHN4anM0 QG5vdHRpbmdoYW0uYWMudWsiIHRhcmdldD0iX2JsYW5rIj5wc3hqczRAbm90dGluZ2hhbS5hYy51 azwvYT4mZ3Q7IHNjaHJpZWI6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPkhlbGxvLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNr Z3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PkR5bmFtaWMgY2xpZW50IHJlZ2lzdHJhdGlvbiBpcyB2ZXJ5IHVzZWZ1bCBpZiBjbGllbnQgb3Ig cmVzb3VyY2Ugb3IgYXV0aG9yaXNhdGlvbiBzZXJ2ZXIgaXMgbm90IHBlcm1hbmVudGx5IGF2YWls YWJsZS4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5BIHR5cGljYWwgY2FzZSBpcyB0aGF0IGlzIHRoZSByZXNv dXJjZSBvciBhdXRob3Jpc2F0aW9uIHNlcnZlciBpcyBpbiBtb2JpbGUgcGxhdGZvcm0sIHRoZSBj b25uZWN0aW9uIGlzIG5vdCBhbHdheXMgYXZhaWxhYmxlLiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkFub3Ro ZXIgdHlwaWNhbCBjYXNlIGlzIHRoYXQgYXV0aG9yaXNhdGlvbiBzZXJ2ZXIgZG8gbm90IG5lY2Vz c2FyeSB0byBoYXZlIGNsaWVudCBwcmUtcmVnaXN0ZXJlZCBvbiBpdHNlbGYuIEF0IG1vbWVudCwg aW5kdXN0cnkgbGlrZSBmYWNlYm9vayB3b3VsZCBsaWtlIGRldmVsb3BlciB0byByZWdpc3RlciBh IGFwcCBvbiBpdHMNCiBhcHAgY2VudHJlIGZpcnN0LCBhbmQgdGhlbiBhc2sgdXNlciBhdXRoIHRv IHVzZSB0aGUgYXBwLiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndo aXRlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPldlIGFyZSBy ZXNlYXJjaGVycyBmcm9tIERpZ2l0YWwgRWNvbm9teSBSZXNlYXJjaCBJbnN0aXR1dGUuIFdlIGhh dmUgdGhpcyBwcm9ibGVtIFdoZW4gd2UgZGV2ZWxvcGluZyBEYXRhd2FyZSB0aGF0IGNvdWxkIG1h bmFnZSB0aGUgY29udHJvbCBvZiBhY2Nlc3MgdG8gcGVyc29uYWwgZGF0YS4gV2UgcGxheSBhcm91 bmQgb3VyDQogc29sdXRpb24gYmFzZSBvbiBPYXV0aDI6Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9n aXRodWIuY29tL2ppYW5odWFzaGFvL2RhdGF3YXJlLmNhdGFsb2cvd2lraSIgdGFyZ2V0PSJfYmxh bmsiPmh0dHBzOi8vZ2l0aHViLmNvbS9qaWFuaHVhc2hhby9kYXRhd2FyZS5jYXRhbG9nL3dpa2k8 L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+V2UgYXJlIGluIHRoZSBsaXN0IHRvIHJl Y2VpdmUgeW91ciBtYWlsIGxpc3QsIGJ1dCBjdXJyZW50bHkgbmVlZCBtb2RlcmF0ZSB0byBwb3N0 IGFueSBtZXNzYWdlLiBjYyBteSBjb2xsZWFndWUsIFJpY2hhcmQgTW9ydGllcjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PkJlc3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj5KaWFuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPk9uIDEyIEp1biAyMDEyLCBhdCAyMTowOCwgRXJhbiBIYW1tZXIgd3JvdGU6PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQ7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5k OndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj5UaGUg b25seSBkaXN0aW5jdGlvbiBJIHdvdWxkIG1ha2UgaXMgYmV0d2VlbiByZW1vdmluZyBmbGV4aWJp bGl5IHRvIHByb2FjdGl2ZWx5IGVuYWJsaW5nIGZ1dHVyZSBleHRlbnNpYmlsaXR5LiBJIHdvdWxk IHN0b3Agc2hvcnQgb2YgcGVyc2NyaWJpbmcgZW5jb2RpbmcgaW4gb3JkZXIgdG8NCiBmaXQgdXJp IGludG8gdGhlIEJhc2ljIGF1dGggZmllbGRzLiBCdXQgaWYgdGhlcmUgaXMgYSB3YXkgdG8gYWxs b3cgdGhpcyB0byBiZSBsZXNzIHJlc3RyaWN0aXZlIHdpdGhvdXQgY2xlYW4gaW50ZXJvcCBpc3N1 ZXMsIHRoYXQgd291bGQgYmUgbmljZS48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPkkgZG8gYWdyZWUgd2Ug bmVlZCBzb21lIGFjdHVhbCB1c2UgY2FzZXMgYmVmb3JlIHdlIHNwZW5kIG11Y2ggbW9yZSB0aW1l IG9uIHRoaXMuPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj5FSDwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0O2JvcmRlci1jb2xvcjppbml0aWFsIj4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFk ZGluZzozLjBwdCAwaW4gMGluIDBpbjtib3JkZXItY29sb3I6aW5pdGlhbCI+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFjayI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIGNsYXNzPSJ5aXYxODAxMTc4ODc4YXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFjayI+V2lsbGlhbQ0KIE1pbGxzIDxh IGhyZWY9Im1haWx0bzpbbWFpbHRvOndtaWxsc0B5YWhvby1pbmMuY29tXSIgdGFyZ2V0PSJfYmxh bmsiPlttYWlsdG86d21pbGxzQHlhaG9vLWluYy5jb21dPC9hPjxzcGFuIGNsYXNzPSJ5aXYxODAx MTc4ODc4YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KPGI+U2VudDo8 L2I+PHNwYW4gY2xhc3M9InlpdjE4MDExNzg4NzhhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj5UdWVzZGF5LCBKdW5lIDEyLCAyMDEyIDE6MDQgUE08YnI+DQo8Yj5Ubzo8L2I+PHNw YW4gY2xhc3M9InlpdjE4MDExNzg4NzhhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj5FcmFuIEhhbW1lcjsgTWlrZSBKb25lczsgSGFubmVzIFRzY2hvZmVuaWc7IEp1bGlhbiBSZXNj aGtlPGJyPg0KPGI+Q2M6PC9iPjxzcGFuIGNsYXNzPSJ5aXYxODAxMTc4ODc4YXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+b2F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+PHNw YW4gY2xhc3M9InlpdjE4MDExNzg4NzhhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj5EeW5hbWljIGNsaWVudHMsIFVSSSwgYW5kIHN0dWZmIFJlOiBbT0FVVEgtV0ddIERpc2N1c3Np b24gbmVlZGVkIG9uIHVzZXJuYW1lIGFuZCBwYXNzd29yZCBBQk5GIGRlZmluaXRpb25zPC9zcGFu PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hp dGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTQuMHB0O2NvbG9yOmJsYWNrIj5JIHRoaW5rIGR5 bmFtaWMgY2xpZW50IHJlZ2lzdHJhdGlvbiBpcyBzb21ldGhpbmcgd2UgaGF2ZSBub3QgdGFsa2Vk IG91dCBlbm91Z2ggeWV0LiZuYnNwOyBUaGVyZSdzIGEgcHJldHR5IGNsZWFyIHVzZSBjYXNlIGZv ciBkeW5hbWljIHJlZ2lzdHJhdGlvbi4mbmJzcDsmbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dy b3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQ7Y29sb3I6YmxhY2siPiZu YnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjE0LjBwdDtjb2xvcjpibGFjayI+RG9lcyBpZGVudGlmeWluZyB0aGUgY2xpZW50IHdpdGgg YSBVUkkgYWxsb3cgc29tZSBmb3JtIG9mIE9wZW5JRC1pc2ggZmxvdyBmb3IgdGhpcz8mbmJzcDs8 L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox NC4wcHQ7Y29sb3I6YmxhY2siPklzIHRoZSBjbGllbnQgSUQgYXMgYSBVUkkgYSB3YXkgdG8gYWxs b3cgYSB0cnVzdGVkIHNpdGUgdG8gcHJvdmlkZSBtZXRhZGF0YSBhYm91dCB0aGUgY2xpZW50Pzwv c3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0 LjBwdDtjb2xvcjpibGFjayI+SXMgdGhhdCBVUkkgYSB3YXkgdG8gaGl0IGFuIElEUCB3ZSB0cnVz dCB0byB2YWxpZGF0ZSB0aGUgY2xpZW50IGluIHNvbWUgd2F5IHdpdGggdGhlIHByb3ZpZGVkIHNl Y3JldD88L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxNC4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5k OndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdDtjb2xvcjpibGFjayI+SSBndWVz cyB3aGF0IEknbSBsb29raW5nIGZvciBoZXJlIGlzIGEgY29uY3JldGUgdXNlIGNhc2UvcHJvYmxl bSB0byBzb2x2ZSwgcmF0aGVyIHRoZW4gbGVhdmluZyBhIGhvb2sgd2UgdGhpbmsgaXMgdGhlIHJp Z2h0IHRoaW5nLjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjE0LjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTQuMHB0O2NvbG9yOmJsYWNrIj4t YmlsbDwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjE0LjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjMTAx MEZGIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQ7bWFyZ2luLWxlZnQ6My43NXB0O21h cmdpbi10b3A6My43NXB0O21hcmdpbi1ib3R0b206NS4wcHQ7Ym9yZGVyLWNvbG9yOmluaXRpYWwi Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3 aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOzwv c3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwi IGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRl Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrIj4NCjxociBzaXpl PSIxIiB3aWR0aD0iMTAwJSIgYWxpZ249ImNlbnRlciI+DQo8L3NwYW4+PC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFjayI+RnJvbTo8L3NwYW4+PC9i PjxzcGFuIGNsYXNzPSJ5aXYxODAxMTc4ODc4YXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFjayI+RXJhbg0KIEhhbW1lciAm bHQ7PGEgaHJlZj0ibWFpbHRvOmVyYW5AaHVlbml2ZXJzZS5jb20iIHRhcmdldD0iX2JsYW5rIj5l cmFuQGh1ZW5pdmVyc2UuY29tPC9hPiZndDs8YnI+DQo8Yj5Ubzo8L2I+PHNwYW4gY2xhc3M9Inlp djE4MDExNzg4NzhhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5NaWtlIEpvbmVz ICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIiB0YXJnZXQ9 Il9ibGFuayI+TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPC9hPiZndDs7IFdpbGxpYW0gTWls bHMgJmx0OzxhIGhyZWY9Im1haWx0bzp3bWlsbHNAeWFob28taW5jLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPndtaWxsc0B5YWhvby1pbmMuY29tPC9hPiZndDs7DQogSGFubmVzIFRzY2hvZmVuaWcgJmx0 OzxhIGhyZWY9Im1haWx0bzpoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0IiB0YXJnZXQ9Il9ibGFu ayI+aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldDwvYT4mZ3Q7OyBKdWxpYW4gUmVzY2hrZSAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmp1bGlhbi5yZXNjaGtlQGdteC5kZSIgdGFyZ2V0PSJfYmxhbmsiPmp1 bGlhbi5yZXNjaGtlQGdteC5kZTwvYT4mZ3Q7PHNwYW4gY2xhc3M9InlpdjE4MDExNzg4NzhhcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQo8Yj5DYzo8L2I+PHNwYW4gY2xh c3M9InlpdjE4MDExNzg4NzhhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj4mcXVv dDs8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5vYXV0aEBp ZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPm9hdXRoQGlldGYub3JnPC9hPiZndDs8c3BhbiBjbGFzcz0ieWl2MTgwMTE3 ODg3OGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCjxiPlNlbnQ6PC9i PjxzcGFuIGNsYXNzPSJ5aXYxODAxMTc4ODc4YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+VHVlc2RheSwgSnVuZSAxMiwgMjAxMiAxMTozOSBBTTxicj4NCjxiPlN1YmplY3Q6PC9i PjxzcGFuIGNsYXNzPSJ5aXYxODAxMTc4ODc4YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+UkU6IFtPQVVUSC1XR10gRGlzY3Vzc2lvbiBuZWVkZWQgb24gdXNlcm5hbWUgYW5kIHBh c3N3b3JkIEFCTkYgZGVmaW5pdGlvbnM8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2IGlkPSJ5aXYxODAxMTc4ODc4Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPklzIHRoZSB1c2Ug Y2FzZSBvZiB1c2luZyBVUkkgYXMgY2xpZW50IGlkcyBpbXBvcnRhbnQ/IEl0IHNlZW1zIGxpa2Ug c29tZXRoaW5nIHRoYXQgbWlnaHQgYmVjb21lIHVzZWZ1bCBpbiB0aGUgZnV0dXJlIHdoZXJlIGNs aWVudHMgY2FuIHVzZSB0aGVpciB2ZXJpZmlhYmxlIHNlcnZlcnMgdG8NCiBieXBhc3MgY2xpZW50 IHJlZ2lzdHJhdGlvbiBhbmQgc2ltbHkgdXNlIGEgVVJJIHRoZSBzZXJ2ZXIgY2FuIHZhbGlkYXRl IHZpYSBzb21lIG90aGVyIG1lYW5zLjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Y29sb3I6IzFGNDk3RCI+SSBqdXN0IHdhbnQgdG8gbWFrZSBzdXJlIHRob3NlIHRoaW5raW5nIGFi b3V0IG1vcmUgY29tcGxleCB1c2UgY2FzZXMgaW52b2x2aW5nIGR5bmFtaWMgcmVnaXN0cmF0aW9u IG9yIGRpc3RyaSBidXRlZCBjbGllbnQgbWFuYW1nZW5ldCBhcmUgYXdhcmUgb2YgdGhpcyBwb3Rl bnRpYWwgcmVzdHJpY3Rpb24uPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xv cjojMUY0OTdEIj5JJ20gZmluZSBlaXRoZXIgd2F5Ljwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5k OndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj4mbmJz cDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+RUg8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z cGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0O2JvcmRlci1jb2xvcjpp bml0aWFsIj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbjtib3JkZXItY29sb3I6aW5p dGlhbCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i YmFja2dyb3VuZDp3aGl0ZSI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6 YmxhY2siPkZyb206PC9zcGFuPjwvYj48c3BhbiBjbGFzcz0ieWl2MTgwMTE3ODg3OGFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2si PiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6 YmxhY2siPjxhIGhyZWY9Im1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwvYT48c3BhbiBjbGFzcz0ieWl2MTgwMTE3ODg3 OGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpbbWFp bHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIiB0YXJnZXQ9Il9ibGFuayI+W21haWx0bzpvYXV0 aC1ib3VuY2VzQGlldGYub3JnXTwvYT48c3BhbiBjbGFzcz0ieWl2MTgwMTE3ODg3OGFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiPk9uDQogQmVoYWxmIE9mPHNwYW4gY2xhc3M9 InlpdjE4MDExNzg4NzhhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+TWlr ZSBKb25lczxicj4NCjxiPlNlbnQ6PC9iPjxzcGFuIGNsYXNzPSJ5aXYxODAxMTc4ODc4YXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+VHVlc2RheSwgSnVuZSAxMiwgMjAxMiAxMToy NyBBTTxicj4NCjxiPlRvOjwvYj48c3BhbiBjbGFzcz0ieWl2MTgwMTE3ODg3OGFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPldpbGxpYW0gTWlsbHM7IEhhbm5lcyBUc2Nob2Zlbmln OyBKdWxpYW4gUmVzY2hrZTxicj4NCjxiPkNjOjwvYj48c3BhbiBjbGFzcz0ieWl2MTgwMTE3ODg3 OGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpvYXV0 aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9hdXRoQGlldGYub3JnPC9hPjxicj4NCjxiPlN1 YmplY3Q6PC9iPjxzcGFuIGNsYXNzPSJ5aXYxODAxMTc4ODc4YXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+UmU6IFtPQVVUSC1XR10gRGlzY3Vzc2lvbiBuZWVkZWQgb24gdXNlcm5h bWUgYW5kIHBhc3N3b3JkIEFCTkYgZGVmaW5pdGlvbnM8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPk5vdCBpbnRlcm5h dGlvbmFsaXppbmcgZmllbGRzIGludGVuZGVkIGZvciBtYWNoaW5lIGNvbnN1bXB0aW9uIG9ubHkg aXMgYWxyZWFkeSBhIHByZWNlZGVudCBzZXQgYW5kIGFncmVlZCB0byBieSB0aGUgd29ya2luZyBn cm91cCwgc28gbGV0IG1lIHNlY29uZCBCaWxs4oCZcyBwb2ludCBpbiB0aGF0DQogcmVnYXJkLiZu YnNwOyBGb3IgaW5zdGFuY2UsIG5laXRoZXIg4oCcc2NvcGXigJ0gbm9yIOKAnGVycm9y4oCdIGFs bG93IG5vbi1BU0NJSSBjaGFyYWN0ZXJzLjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRl Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Y29sb3I6IzFGNDk3RCI+SnVsaWFuLCBpZiB5b3Ugd2FudCBkaWZmZXJlbnQgQUJORiB0ZXh0 IHRoYW4gdGhlIHRleHQgSSB3cm90ZSBiZWxvdywgSSBiZWxpZXZlIGl0IHdvdWxkIGJlIG1vc3Qg dXNlZnVsIGlmIHlvdSB3b3VsZCBwcm92aWRlIHRoZSBleGFjdCByZXBsYWNlIHdvcmRpbmcgdGhh dCB5b3XigJlkIGxpa2UNCiB0byBzZWUgaW5zdGVhZCBvZiBpdC4mbmJzcDsgVGhlbiB0aGVyZeKA mXMgbm8gcG9zc2liaWxpdHkgb2YgbWlzdW5kZXJzdGFuZGluZyB0aGUgaW50ZW50IG9mIHN1Z2dl c3RlZCBjaGFuZ2VzLjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoYW5rcyBhbGwsPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAtLSBNaWtlPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbjtib3JkZXItY29sb3I6aW5p dGlhbCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i YmFja2dyb3VuZDp3aGl0ZSI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6 YmxhY2siPkZyb206PC9zcGFuPjwvYj48c3BhbiBjbGFzcz0ieWl2MTgwMTE3ODg3OGFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2si PiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6 YmxhY2siPjxhIGhyZWY9Im1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwvYT48c3BhbiBjbGFzcz0ieWl2MTgwMTE3ODg3 OGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpbbWFp bHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIiB0YXJnZXQ9Il9ibGFuayI+W21haWx0bzpvYXV0 aC1ib3VuY2VzQGlldGYub3JnXTwvYT48c3BhbiBjbGFzcz0ieWl2MTgwMTE3ODg3OGFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiPk9uDQogQmVoYWxmIE9mPHNwYW4gY2xhc3M9 InlpdjE4MDExNzg4NzhhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+V2ls bGlhbSBNaWxsczxicj4NCjxiPlNlbnQ6PC9iPjxzcGFuIGNsYXNzPSJ5aXYxODAxMTc4ODc4YXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+VHVlc2RheSwgSnVuZSAxMiwgMjAxMiAx MToxOCBBTTxicj4NCjxiPlRvOjwvYj48c3BhbiBjbGFzcz0ieWl2MTgwMTE3ODg3OGFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPkhhbm5lcyBUc2Nob2ZlbmlnOyBKdWxpYW4gUmVz Y2hrZTxicj4NCjxiPkNjOjwvYj48c3BhbiBjbGFzcz0ieWl2MTgwMTE3ODg3OGFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPm9hdXRoQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPjxz cGFuIGNsYXNzPSJ5aXYxODAxMTc4ODc4YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+UmU6IFtPQVVUSC1XR10gRGlzY3Vzc2lvbiBuZWVkZWQgb24gdXNlcm5hbWUgYW5kIHBhc3N3 b3JkIEFCTkYgZGVmaW5pdGlvbnM8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQ7Y29sb3I6YmxhY2siPkkgYWdyZWUgZ2Vu ZXJhbGx5IHdpdGggeW91ciBhc3N1bXB0aW9uIGFib3V0IGNsaWVudHMsIGJ1dCByYXRoZXIgdGhh biBzYXlpbmcgJnF1b3Q7Y2xpZW50cyBhcmUgZGV2aWNlcyZxdW90OyBJIHRoaW5rIGl0IG1ha2Vz IG11Y2ggbW9yZSBzZW5zZSB0byBzYXkgJnF1b3Q7Y2xpZW50cyBhcmUgTk9UIHVzZXJzLCBzbyBj bGllbnRfaWQNCiBuZWVkIG5vdCBiZSBpbnRlcm5hdGlvbmFsaXplZCZxdW90Oy4mbmJzcDsgSW4g cHJhY3RpY2FsIHRlcm1zIHRoZXJlIGlzIHZlcnkgbGl0dGxlIHRvIGFyZ3VlIGZvciBhbnl0aGln biBiZXlvbmQgQVNDSUkgaW4gYSBjbGllbnRfc2VjcmV0LCBiYXNlNjQgZW5jb2Rpbmcgb3IgdGhl IGVxdWl2YWxlbnQgYmVpbmcgYSBmaW5lIHdheSB0byB0cmFuc3BvcnQgYXJiaXRyYXJ5IGJpdHMg aW4gYSBwb3J0YWJsZS9yZWFzb25hYmxlIHdheS48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNr Z3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdDtjb2xvcjpibGFjayI+ Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTQuMHB0O2NvbG9yOmJsYWNrIj5JIGFyZ3VlIHRoYXQgY2xp ZW50X2lkIG5lZWQgbm90IGJlIGludGVybmF0aW9uYWxpemVkIGJlY2F1c2UgSSBhc3N1bWUgdGhh dCBhbnkgcmVhbGx5IGludGVybmF0aW9uYWxpemVkIGFwcGxpY2F0aW9uIHdpbGwgaGF2ZSBhbiBp bnRlcm5hdGlvbmFsaXplZCBwcmVzZW50YXRpb24gbGF5ZXIgdGhhdCdzDQogcHJlc2VudGluZyBh IHByZXR0eSBuYW1lIGZvciB0aGUgY2xpZW50X2lkLjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdDtjb2xv cjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTQuMHB0O2NvbG9yOmJsYWNrIj4tYmlsbDwv c3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1i b3R0b206MTQuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTQuMHB0O2NvbG9yOmJs YWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNl bnRlcjtiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Nv bG9yOmJsYWNrIj4NCjxociBzaXplPSIxIiB3aWR0aD0iMTAwJSIgYWxpZ249ImNlbnRlciI+DQo8 L3NwYW4+PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Y29sb3I6YmxhY2siPkZyb206PC9zcGFuPjwvYj48c3BhbiBjbGFzcz0ieWl2MTgwMTE3ODg3OGFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6 YmxhY2siPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Y29sb3I6YmxhY2siPkhhbm5lcw0KIFRzY2hvZmVuaWcgJmx0OzxhIGhyZWY9Im1haWx0bzpoYW5u ZXMudHNjaG9mZW5pZ0BnbXgubmV0IiB0YXJnZXQ9Il9ibGFuayI+aGFubmVzLnRzY2hvZmVuaWdA Z214Lm5ldDwvYT4mZ3Q7PGJyPg0KPGI+VG86PC9iPjxzcGFuIGNsYXNzPSJ5aXYxODAxMTc4ODc4 YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+SnVsaWFuIFJlc2Noa2UgJmx0Ozxh IGhyZWY9Im1haWx0bzpqdWxpYW4ucmVzY2hrZUBnbXguZGUiIHRhcmdldD0iX2JsYW5rIj5qdWxp YW4ucmVzY2hrZUBnbXguZGU8L2E+Jmd0OzxzcGFuIGNsYXNzPSJ5aXYxODAxMTc4ODc4YXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KPGI+Q2M6PC9iPjxzcGFuIGNsYXNz PSJ5aXYxODAxMTc4ODc4YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+JnF1b3Q7 PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1dGhAaWV0 Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5vYXV0aEBpZXRmLm9yZzwvYT4mZ3Q7PHNwYW4gY2xhc3M9InlpdjE4MDExNzg4 NzhhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQo8Yj5TZW50OjwvYj48 c3BhbiBjbGFzcz0ieWl2MTgwMTE3ODg3OGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPlR1ZXNkYXksIEp1bmUgMTIsIDIwMTIgMTE6MDEgQU08YnI+DQo8Yj5TdWJqZWN0OjwvYj48 c3BhbiBjbGFzcz0ieWl2MTgwMTE3ODg3OGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPlJlOiBbT0FVVEgtV0ddIERpc2N1c3Npb24gbmVlZGVkIG9uIHVzZXJuYW1lIGFuZCBwYXNz d29yZCBBQk5GIGRlZmluaXRpb25zPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPjxicj4NCkkgaGFkIGEgY2hhdCB3aXRoIEp1bGlhbiB5ZXN0ZXJkYXkgYW5kIGhlcmUgaXMg bXkgc2hvcnQgc3VtbWFyeS48c3BhbiBjbGFzcz0ieWl2MTgwMTE3ODg3OGFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCjxicj4NClNlY3Rpb24gMi4zIG9mIHRoZSBjb3Jl IGRyYWZ0IGRlZmluZXMgY2xpZW50IGF1dGhlbnRpY2F0aW9uIGJhc2VkIG9uIHR3byBtZWNoYW5p c21zIChhbmQgcHJvdmlkZXMgcm9vbSBmb3IgZXh0ZW5zaW9ucyk6PGEgaHJlZj0iaHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC12Mi0yNyNzZWN0aW9uLTIuMyIgdGFy Z2V0PSJfYmxhbmsiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgt djItMjcjc2VjdGlvbi0yLjM8L2E+PGJyPg0KPGJyPg0KMSkgSFRUUCBCYXNpYyBBdXRoZW50aWNh dGlvbjxicj4NCjxicj4NCjIpIEEgY3VzdG9tIE9BdXRoIGF1dGhlbnRpY2F0aW9uIG1lY2hhbmlz bSAod2hpY2ggdXNlcyBjbGllbnRfaWQgYW5kIGNsaWVudF9zZWNyZXQpPGJyPg0KPGJyPg0KV2l0 aCBIVFRQIEJhc2ljIGF1dGhlbnRpY2F0aW9uIHRoZSBwcm9ibGVtIGlzIHRoYXQgdGhpcyBpcyBh IGxlZ2FjeSB0ZWNobm9sb2d5IGFuZCB0aGVyZSBpcyBubyBpbnRlcm5hdGlvbmFsaXphdGlvbiBz dXBwb3J0LjxzcGFuIGNsYXNzPSJ5aXYxODAxMTc4ODc4YXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+PGJyPg0KPGJyPg0KV2l0aCBvdXIgYnJhbmQgbmV3IGN1c3RvbSBPQXV0aCBh dXRoZW50aWNhdGlvbiBtZWNoYW5pc20gd2UgaGF2ZSBtb3JlIG9wdGlvbnMuPHNwYW4gY2xhc3M9 InlpdjE4MDExNzg4NzhhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQo8 YnI+DQpPbmUgcG9zc2libGUgYXBwcm9hY2ggaXMgdG8gc2F5IHRoYXQgdGhlIGNsaWVudHMgYXJl IGRldmljZXMgKGFuZCBub3QgZW5kIHVzZXJzKSBhbmQgdGhlcmVmb3JlIGludGVybmF0aW9uYWxp emF0aW9uIGRvZXMgbm90IG1hdHRlci48c3BhbiBjbGFzcz0ieWl2MTgwMTE3ODg3OGFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCjxicj4NCklzIGl0LCBob3dldmVyLCBy ZWFsbHkgdHJ1ZSB0aGF0IG9ubHkgVVMtQVNDSUkgY2hhcmFjdGVycyB3aWxsIGFwcGVhciBpbiB0 aGUgY2xpZW50X2lkIGFuZCBhbHNvIGluIHRoZSBjbGllbnRfc2VjcmV0PzxzcGFuIGNsYXNzPSJ5 aXYxODAxMTc4ODc4YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KPGJy Pg0KSGVyZSB3ZSBoYXZlIHRoZSBwb3NzaWJpbGl0eSB0byBkZWZpbmUgc29tZXRoaW5nIGJldHRl ci48c3BhbiBjbGFzcz0ieWl2MTgwMTE3ODg3OGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPjxicj4NCjxicj4NCkluIGFueSBjYXNlIHdlIGhhdmUgdG8gcmVzdHJpY3QgdGhlIGNo YXJhY3RlcnMgdGhhdCBhcmUgdXNlZCBpbiB0aGVzZSB0d28gYXV0aGVudGljYXRpb24gbWVjaGFu aXNtcyBzaW5jZSB0aGV5IGNvdWxkIGNvbmZsaWN0IHdpdGggdGhlIHdheSBob3cgd2UgdHJhbnNw b3J0IHRoZSBkYXRhIG92ZXIgdGhlIHVuZGVybHlpbmcgcHJvdG9jb2wuIEp1bGlhbiBtZW50aW9u ZWQgdGhpcyBpbiBoaXMgcHJldmlvdXMgbWFpbHMuPHNwYW4gY2xhc3M9InlpdjE4MDExNzg4Nzhh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQo8YnI+DQpKdWxpYW4sIG1h eWJlIHlvdSBjYW4gcHJvdmlkZSBhIGRldGFpbGVkIHRleHQgcHJvcG9zYWwgZm9yIGhvdyB0byBh ZGRyZXNzIHlvdXIgY29tbWVudCBpbiBjYXNlIHdlIGdvIGZvciBVVEY4ICh3aXRoICUgZW5jb2Rp bmcpIGZvciB0aGUgY3VzdG9tIE9BdXRoIGNsaWVudCBhdXRoZW50aWNhdGlvbiBtZWNoYW5pc20/ PHNwYW4gY2xhc3M9InlpdjE4MDExNzg4NzhhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv c3Bhbj48YnI+DQo8YnI+DQpDaWFvPGJyPg0KSGFubmVzPGJyPg0KPGJyPg0KT24gSnVuIDEyLCAy MDEyLCBhdCAxMTo1NCBBTSwgSnVsaWFuIFJlc2Noa2Ugd3JvdGU6PGJyPg0KPGJyPg0KJmd0OyBP biAyMDEyLTA2LTEyIDAwOjE2LCBNaWtlIEpvbmVzIHdyb3RlOjxicj4NCiZndDsmZ3Q7IFJldmll d2luZyB0aGUgZmVlZGJhY2sgZnJvbSBKdWxpYW4sIEpvaG4sIGFuZCBKYW1lcywgSSdtIGNvbWlu ZyB0byB0aGUgY29uY2x1c2lvbiB0aGF0IGNsaWVudF9pZCBhbmQgY2xpZW50X3NlY3JldCwgYmVp bmcgZm9yIG1hY2hpbmVzIGFuZCBub3QgaHVtYW5zLCBzaG91IGxkIGJlIEFTQ0lJLCB3aGVyZWFz IHVzZXJuYW1lIGFuZCBwYXNzd29yZCBzaG91bGQgYmUgVW5pY29kZSwgc2luY2UgdGhleSBhcmUg Zm9yIGh1bWFucy4mbmJzcDsgUGVyIEpvaG4ncw0KIGZlZWRiYWNrLCBjbGllbnRfaWQgY2FuIG5v dCBjb250YWluIGEgY29sb24gYW5kIGJlIGNvbXBhdGlibGUgd2l0aCBIVFRQIEJhc2ljLjxicj4N CiZndDs8c3BhbiBjbGFzcz0ieWl2MTgwMTE3ODg3OGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5i c3A7PC9zcGFuPjxicj4NCiZndDsgSSdtIG5vdCBzdXJlIHRoYXQgcmVzdHJpY3RpbmcgdGhlIGNo YXJhY3RlciByZXBlcnRvaXJlIGp1c3QgYmVjYXVzZSBvbmUgd2F5IHRvIHNlbmQgcmVxdWlyZXMg dGhpcyBpcyB0aGUgcmlnaHQgYXBwcm9hY2guIE15IHByZWZlcmVuY2Ugd291bGQgYmUgbm90IHRv IHB1dCB0aGlzIGludG8gdGhlIEFCTkYsIGFuZCBqdXN0IHRvIHBvaW50IG91dCB0aGF0IGNlcnRh aW4gY2hhcmFjdGVycyB3aWxsIG5vdCB3b3JrIG92ZXIgY2VydGFpbiB0cmFuc3BvcnRzLA0KIGFu ZCB0byBqdXN0IGFkdmlzZSB0byBhdm9pZCB0aGVtLjxicj4NCiZndDs8c3BhbiBjbGFzcz0ieWl2 MTgwMTE3ODg3OGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCiZndDsm Z3Q7IFRoZXJlZm9yZSwgSSdkIGxpa2UgdG8gcHJvcG9zZSB0aGVzZSB1cGRhdGVkIEFCTkYgZGVm aW5pdGlvbnM6PGJyPg0KJmd0OyZndDs8c3BhbiBjbGFzcz0ieWl2MTgwMTE3ODg3OGFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyBW U0NIQVIgPSAlMjAtN0U8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgTk9DT0xPTlZTQ0hBUiA9 ICV4MjAtMzkgLyAleDNCLTdFPGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7IFVOSUNPREVOT0NU UkxDSEFSID0gJmx0O0FueSBVbmljb2RlIGNoYXJhY3RlciBvdGhlciB0aGFuICggJXgwLTFGIC8g JXg3RiApJmd0Ozxicj4NCiZndDsmZ3Q7PHNwYW4gY2xhc3M9InlpdjE4MDExNzg4NzhhcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsg Y2xpZW50LWlkID0gKk5PQ09MT05WU0NIQVI8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgY2xp ZW50X3NlY3JldCA9ICpWU0NIQVI8YnI+DQomZ3Q7Jmd0OzxzcGFuIGNsYXNzPSJ5aXYxODAxMTc4 ODc4YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KJmd0OyZndDsmbmJz cDsgJm5ic3A7IHVzZXJuYW1lID0gKlVOSUNPREVOT0NUUkxDSEFSPGJyPg0KJmd0OyZndDsmbmJz cDsgJm5ic3A7IHBhc3N3b3JkID0gKlVOSUNPREVOT0NUUkxDSEFSPGJyPg0KJmd0OzxzcGFuIGNs YXNzPSJ5aXYxODAxMTc4ODc4YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJy Pg0KJmd0OyBJbiB0aGlzIGNhc2UgeW91IHNob3VsZCBhZGQgYW4gaW50cm9kdWN0b3J5IHN0YXRl bWVudCBwb2ludGluZyBvdXQgdGhhdCB0aGUgQUJORiBkZWZpbmVzIHRoZSBncmFtbWFyIGluIHRl cm1zIG9mIFVuaWNvZGUgY29kZSBwb2ludHMsIG5vdCBvY3RldHMgKGFzIGl0IGlzIHRoZSBjYXNl IG1vc3Qgb2YgdGhlIHRpbWUpLjxicj4NCiZndDs8c3BhbiBjbGFzcz0ieWl2MTgwMTE3ODg3OGFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCiZndDsmZ3Q7IEl0IHR1cm5z IG91dCB0aGF0IG5vbi1BU0NJSSBjaGFyYWN0ZXJzIGFyZSBPSyBmb3IgdXNlcm5hbWUgYW5kIHBh c3N3b3JkIGJlY2F1c2UgdGhlIENvcmUgc3BlYyBvbmx5IHBhc3NlcyB0aGVtIGluIHRoZSBmb3Jt IGJvZHkgLSBub3QgdXNpbmcgSFRUUCBCYXNpYyAtIGFuZCBVVEYtOCBlbmNvZGluZyBpcyBzcGVj aWZpZWQuPGJyPg0KJmd0OzxzcGFuIGNsYXNzPSJ5aXYxODAxMTc4ODc4YXBwbGUtY29udmVydGVk LXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KJmd0OyBJJ2xsIHNlbmQgYSBzZXBhcmF0ZSBtYWls IGFib3V0IHRoYXQsIHRoZSBjdXJyZW50IHRleHQgaW4gdGhlIHNwZWMgaXMgd2F5IHRvbyB1bnNw ZWNpZmljLjxicj4NCiZndDs8c3BhbiBjbGFzcz0ieWl2MTgwMTE3ODg3OGFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCiZndDsmZ3Q7ICZuYnNwOyZuYnNwOyZuYnNwOyAm bmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyAt LSBNaWtlPGJyPg0KJmd0OyZndDs8c3BhbiBjbGFzcz0ieWl2MTgwMTE3ODg3OGFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCiZndDsmZ3Q7IFAuUy4mbmJzcDsgSWYgYW55 b25lIGhhcyBhIGJldHRlciBBQk5GIGZvciBVTklDT0RFTk9DVFJMQ0hBUiB0aGFuICZxdW90OyZs dDtBbnkgVW5pY29kZSBjaGFyYWN0ZXIgb3RoZXIgdGhhbiAoICV4MC0xRiAvICV4N0YgKSZndDsm cXVvdDssIHBsZWFzZSBzZW5kIGl0IHRvIG1lITxicj4NCiZndDs8c3BhbiBjbGFzcz0ieWl2MTgw MTE3ODg3OGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCiZndDsgQXMg bm90ZWQgYmVmb3JlLCBoZXJlJ3MgYW4gZXhhbXBsZTogJmx0OzxhIGhyZWY9Imh0dHA6Ly9ncmVl bmJ5dGVzLmRlL3RlY2gvd2ViZGF2L3JmYzUzMjMuaHRtbCNyZmMuc2VjdGlvbi41LjE1LjEiIHRh cmdldD0iX2JsYW5rIj5odHRwOi8vZ3JlZW5ieXRlcy5kZS90ZWNoL3dlYmRhdi9yZmM1MzIzLmh0 bWwjcmZjLnNlY3Rpb24uNS4xNS4xPC9hPiZndDs8YnI+DQomZ3Q7PHNwYW4gY2xhc3M9InlpdjE4 MDExNzg4NzhhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQomZ3Q7IEJl c3QgcmVnYXJkcywgSnVsaWFuPGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KJmd0 OzxzcGFuIGNsYXNzPSJ5aXYxODAxMTc4ODc4YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+PGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1 dGhAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OzxzcGFuIGNsYXNzPSJ5aXYxODAxMTc4ODc4YXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PGJyPg0KPGJyPg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxp c3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5P QXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVm PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9i bGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5UaGlzIG1l c3NhZ2UgYW5kIGFueSBhdHRhY2htZW50IGFyZSBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSBhZGRy ZXNzZWUgYW5kIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbi4gSWYgeW91IGhh dmUgcmVjZWl2ZWQgdGhpcyBtZXNzYWdlIGluIGVycm9yLCBwbGVhc2Ugc2VuZCBpdCBiYWNrIHRv IG1lLCBhbmQNCiBpbW1lZGlhdGVseSBkZWxldGUgaXQuIFBsZWFzZSBkbyBub3QgdXNlLCBjb3B5 IG9yIGRpc2Nsb3NlIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtZXNzYWdlIG9y IGluIGFueSBhdHRhY2htZW50LiBBbnkgdmlld3Mgb3Igb3BpbmlvbnMgZXhwcmVzc2VkIGJ5IHRo ZSBhdXRob3Igb2YgdGhpcyBlbWFpbCBkbyBub3QgbmVjZXNzYXJpbHkgcmVmbGVjdCB0aGUgdmll d3Mgb2YgdGhlIFVuaXZlcnNpdHkgb2YgTm90dGluZ2hhbS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5k OndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlRoaXMgbWVzc2FnZSBoYXMgYmVlbiBj aGVja2VkIGZvciB2aXJ1c2VzIGJ1dCB0aGUgY29udGVudHMgb2YgYW4gYXR0YWNobWVudCBtYXkg c3RpbGwgY29udGFpbiBzb2Z0d2FyZSB2aXJ1c2VzIHdoaWNoIGNvdWxkIGRhbWFnZSB5b3VyIGNv bXB1dGVyIHN5c3RlbTogeW91IGFyZSBhZHZpc2VkIHRvIHBlcmZvcm0geW91ciBvd24NCiBjaGVj a3MuIEVtYWlsIGNvbW11bmljYXRpb25zIHdpdGggdGhlIFVuaXZlcnNpdHkgb2YgTm90dGluZ2hh bSBtYXkgYmUgbW9uaXRvcmVkIGFzIHBlcm1pdHRlZCBieSBVSyBsZWdpc2xhdGlvbi4NCjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGlu ZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3Vu ZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t Ym90dG9tOjEyLjBwdDtiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si Pjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy Pg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3Jn Ij5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_0CBAEB56DDB3A140BA8E8C124C04ECA2010731F9P3PWEX2MB008ex2_-- From wmills@yahoo-inc.com Thu Jun 14 14:38:04 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7279A11E808E for ; Thu, 14 Jun 2012 14:38:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.504 X-Spam-Level: X-Spam-Status: No, score=-17.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ntyuMG-qLxAj for ; Thu, 14 Jun 2012 14:38:03 -0700 (PDT) Received: from nm24-vm0.bullet.mail.bf1.yahoo.com (nm24-vm0.bullet.mail.bf1.yahoo.com [98.139.213.161]) by ietfa.amsl.com (Postfix) with SMTP id 7EC6111E8096 for ; Thu, 14 Jun 2012 14:38:02 -0700 (PDT) Received: from [98.139.212.149] by nm24.bullet.mail.bf1.yahoo.com with NNFMP; 14 Jun 2012 21:38:02 -0000 Received: from [98.139.212.218] by tm6.bullet.mail.bf1.yahoo.com with NNFMP; 14 Jun 2012 21:38:02 -0000 Received: from [127.0.0.1] by omp1027.mail.bf1.yahoo.com with NNFMP; 14 Jun 2012 21:38:02 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 3505.22244.bm@omp1027.mail.bf1.yahoo.com Received: (qmail 84580 invoked by uid 60001); 14 Jun 2012 21:38:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1339709881; bh=0UlzYA7wa1XulHEApabjovB9XMQQi6VsD2jgjOSYy/I=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=qIpCh4Fi1YDl8TevJiNktQ9S6GbN/Y59YG+TkIgTOjmOpE1HGOBUJXGFoquzqN63hi5PNrVJlglKJ/WW4BzLqfjPyvOtKrvyAJ64f0Qd+WjmojGT9W+D9isgV6JR2ZO+FIDzWyjFO9xB65luB7ODxEWNTKG9yhUDPulLm/axwdw= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=B+y8wAKb+ML0Hz+eWMr9dM8gPWUBIbEa7w8/cvbQ0azB22iTSV21es7CazZMtsacusRLS3PCoJ7Rk4jxWoRppIyXv9tvX5wWma/FzIJt8zmxN9FmKPEXmg97sEzsw9iDhCJ9zmOhtbvCKPsxp432N2FVgbpJ54lw0yWISCqG/j8=; X-YMail-OSG: oSJOlE8VM1nyu1PV_kA1TDcqBxoDnLJ1CvqdudSMsgh0bn5 kw8aKh9AtN.fxaJzzWV8y75.6664f0luelj3boJTEhsDD4c5wZfxWXUYvWBF DCwj2eVspE2gX0_Q_yud5YnQYHakALolc1wjRZladwacgMtH8nTtRY7y7X15 ChdJOfk3aftNMyjcZH02RolRvOFKo2GyuAd8GQS5ePY_bOvhkTfGdotEr8nK RRIaGHTXN3ur6dl96WLoQqISBrQH.LE09V79Vs7ZqydqN.8eD5zhFCed1HL2 JYa5lHUPIG4L0m3CnqX8s34Th5X0wS4SLywSTDk_nPqkz8ofIC_lnPfzG_.m 92kAvHPfCnUgmC6Hmrgwi5hhPRQ9x9kqnw_BvzxSKmMf4LpUQf3af7RRizm6 CUALvhELTyEcxxi9zdEA0RAE_7m2fbDJ0xvXqOjtHBL7k5K6cKTABrcUT.kT WylDXWVeMbNOJHgcl.xyIc_qpuXJYYWkWILJbm3VpPLLTqmSgBBhIB_DWywG OyLKdZCXSbbJ.3uu004s7NbgqjJ7M1Q-- Received: from [209.131.62.115] by web31811.mail.mud.yahoo.com via HTTP; Thu, 14 Jun 2012 14:38:00 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.120.356233 References: <1339601256.43890.YahooMailNeo@web31803.mail.mud.yahoo.com> <4FD8B646.3080509@stpeter.im> <1339611594.26607.YahooMailNeo@web31806.mail.mud.yahoo.com> Message-ID: <1339709880.77463.YahooMailNeo@web31811.mail.mud.yahoo.com> Date: Thu, 14 Jun 2012 14:38:00 -0700 (PDT) From: William Mills To: Goix Laurent Walter , Eve Maler , Peter Saint-Andre , Eran Hammer- Lahav In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: O Auth WG , Apps Discuss Subject: Re: [OAUTH-WG] OAuth discovery registration... -01 draft posed X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 21:38:04 -0000 Updated for examples, the editorial issues like replacing link header for l= rdd where it appears, fixing authenticate->authorize.=0A=0AThanks for the f= eedback so far.=0A=0A-bill=0A=0A=0A=0A=0A------------------=0A=0AA new vers= ion of I-D, draft-wmills-oauth-lrdd-01.txt=0Ahas been successfully submitte= d by William Mills and posted to the=0AIETF repository.=0A=0AFilename:=A0= =A0=A0 draft-wmills-oauth-lrdd=0ARevision:=A0=A0=A0 01=0ATitle:=A0=A0=A0 = =A0=A0=A0 Link Type Registry for OAuth 2=0ACreation date:=A0=A0=A0 2012-06-= 14=0AWG ID:=A0=A0=A0 =A0=A0=A0 Individual Submission=0ANumber of pages: 11= =0AURL:=A0 =A0 =A0 =A0 =A0 =A0=A0http://www.ietf.org/internet-drafts/draft-= wmills-oauth-lrdd-01.txt=0AStatus:=A0 =A0 =A0 =A0 =A0=A0http://datatracker.= ietf.org/doc/draft-wmills-oauth-lrdd=0AHtmlized:=A0 =A0 =A0 =A0=A0http://to= ols.ietf.org/html/draft-wmills-oauth-lrdd-01=0ADiff:=A0 =A0 =A0 =A0 =A0 =A0= =A0http://tools.ietf.org/rfcdiff?url2=3Ddraft-wmills-oauth-lrdd-01=0A=0AAbs= tract:=0A=A0 Defines link type registrations for the OAuth 2 authentication= =0A=A0 framework.=0A=0A=0A=0A=0AThe IETF Secretariat =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 From Michael.Jones@microsoft.com Thu Jun 14 14:40:29 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFBD611E808E for ; Thu, 14 Jun 2012 14:40:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.766 X-Spam-Level: X-Spam-Status: No, score=-3.766 tagged_above=-999 required=5 tests=[AWL=-0.166, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N-fjICqqbGp2 for ; Thu, 14 Jun 2012 14:40:29 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe005.messaging.microsoft.com [213.199.154.208]) by ietfa.amsl.com (Postfix) with ESMTP id A469911E8079 for ; Thu, 14 Jun 2012 14:40:28 -0700 (PDT) Received: from mail5-am1-R.bigfish.com (10.3.201.225) by AM1EHSOBE001.bigfish.com (10.3.204.21) with Microsoft SMTP Server id 14.1.225.23; Thu, 14 Jun 2012 21:39:19 +0000 Received: from mail5-am1 (localhost [127.0.0.1]) by mail5-am1-R.bigfish.com (Postfix) with ESMTP id 3F210A01B9; Thu, 14 Jun 2012 21:39:19 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -27 X-BigFish: VS-27(zz9371I14ffI542Mzz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25hf0ah) Received-SPF: pass (mail5-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC103.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail5-am1 (localhost.localdomain [127.0.0.1]) by mail5-am1 (MessageSwitch) id 1339709957636661_10007; Thu, 14 Jun 2012 21:39:17 +0000 (UTC) Received: from AM1EHSMHS009.bigfish.com (unknown [10.3.201.237]) by mail5-am1.bigfish.com (Postfix) with ESMTP id 8F5B91A0048; Thu, 14 Jun 2012 21:39:17 +0000 (UTC) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS009.bigfish.com (10.3.207.109) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 14 Jun 2012 21:39:17 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.189]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.02.0298.005; Thu, 14 Jun 2012 21:40:02 +0000 From: Mike Jones To: Hannes Tschofenig Thread-Topic: [OAUTH-WG] Error Registry: Conclusion Thread-Index: AQHNMuF2SEvCPjHVP0qi3ETkqD5Qwpb6hReg Date: Thu, 14 Jun 2012 21:40:02 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943665393AB@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <42B29A82-D8BA-40B8-9569-B209CBBBC3B7@gmx.net> In-Reply-To: <42B29A82-D8BA-40B8-9569-B209CBBBC3B7@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Error Registry: Conclusion X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 21:40:29 -0000 Hi Hannes, You stated a preference for separate registries below, but that was a large= r change to the OAuth Core spec than the current draft, which added a fourt= h error usage location "resource access error response" to the registry. T= o my knowledge, the consensus call didn't ask people to express a preferenc= e between having four separate OAuth Errors registries versus one OAuth Err= ors registry allowing any combination of a set of four usage locations to b= e specified. Given that the two choices are completely equivalent, and we had previously= established the single OAuth Errors registry with three possible usage loc= ations, extending it to a fourth seemed to be both more natural and easier = for people to understand. Therefore, I'd like to ask you to withdraw your suggestion and allow the ex= isting structure of the OAuth Errors registry to remain. Thank you, -- Mike -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of H= annes Tschofenig Sent: Tuesday, May 15, 2012 2:27 PM To: oauth@ietf.org WG Subject: [OAUTH-WG] Error Registry: Conclusion Hi all,=20 on May 8th we called for consensus on an open issue regarding the location = of the error registry. Here is the call for comments: http://www.ietf.org/m= ail-archive/web/oauth/current/msg08952.html.=20 Thank you all for the feedback. The consensus is to create the registry in = the core document. Section 11.4.1 already sort-of creates sub-registries to illustrate where t= he different errors can be used. This is needed since some of the errors ma= y only appear in certain error responses. Hence, we need add another one to= this list (suggestion: 'resource access error response'). In fact, I would= prefer IANA to create separate tables for each of these sub-registries to = avoid confusion for the reader (instead of putting everything into a single= table).=20 We believe that these changes are really minor and address IESG feedback. Ciao Hannes & Derek _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From Michael.Jones@microsoft.com Thu Jun 14 14:43:35 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB0C211E809A for ; Thu, 14 Jun 2012 14:43:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.749 X-Spam-Level: X-Spam-Status: No, score=-3.749 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uJj7mRqPDLLL for ; Thu, 14 Jun 2012 14:43:35 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe005.messaging.microsoft.com [216.32.181.185]) by ietfa.amsl.com (Postfix) with ESMTP id DD47411E8079 for ; Thu, 14 Jun 2012 14:43:34 -0700 (PDT) Received: from mail83-ch1-R.bigfish.com (10.43.68.239) by CH1EHSOBE004.bigfish.com (10.43.70.54) with Microsoft SMTP Server id 14.1.225.23; Thu, 14 Jun 2012 21:42:26 +0000 Received: from mail83-ch1 (localhost [127.0.0.1]) by mail83-ch1-R.bigfish.com (Postfix) with ESMTP id C1CEE3C0434; Thu, 14 Jun 2012 21:42:25 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -34 X-BigFish: VS-34(zz9371I1b0bM542M1432I11fbI1447Izz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25hf0ah) Received-SPF: pass (mail83-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC103.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail83-ch1 (localhost.localdomain [127.0.0.1]) by mail83-ch1 (MessageSwitch) id 1339710143341859_28466; Thu, 14 Jun 2012 21:42:23 +0000 (UTC) Received: from CH1EHSMHS020.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.252]) by mail83-ch1.bigfish.com (Postfix) with ESMTP id 4816A3E0043; Thu, 14 Jun 2012 21:42:23 +0000 (UTC) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS020.bigfish.com (10.43.70.20) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 14 Jun 2012 21:42:23 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.189]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.02.0309.003; Thu, 14 Jun 2012 21:43:24 +0000 From: Mike Jones To: Eran Hammer Thread-Topic: On the OAuth Core Spec Thread-Index: AQHNSMyPwu5PWEVemkyL/2V30k3dXpb6VGLAgAABngCAAAUlEA== Date: Thu, 14 Jun 2012 21:43:24 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943665393D6@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <0CBAEB56DDB3A140BA8E8C124C04ECA20106ED8B@P3PWEX2MB008.ex2.secureserver.net> <4E1F6AAD24975D4BA5B1680429673943665392B5@TK5EX14MBXC284.redmond.corp.microsoft.com> <0CBAEB56DDB3A140BA8E8C124C04ECA201073185@P3PWEX2MB008.ex2.secureserver.net> In-Reply-To: <0CBAEB56DDB3A140BA8E8C124C04ECA201073185@P3PWEX2MB008.ex2.secureserver.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] On the OAuth Core Spec X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 21:43:35 -0000 I'm thinking about what the appropriate updates to 7.2 are. Your question = about "What if the parameter is named 'err' rather than 'error'?" is a fair= one, for instance. I'll also target proposed updates to that for Monday. As to the question of one OAuth Errors registry versus four, as I suspect y= ou saw, I've asked Hannes to withdraw his suggestion to split the one regis= try into four. Hopefully that can be resolved soon too. -- Mike -----Original Message----- From: Eran Hammer [mailto:eran@hueniverse.com]=20 Sent: Thursday, June 14, 2012 2:22 PM To: Mike Jones Cc: oauth@ietf.org Subject: RE: On the OAuth Core Spec Sounds good. Any progress on a revised 7.2? I'd like to get clarity on that so we can ag= ree on new text and close the issue along with the ABNF. EH > -----Original Message----- > From: Mike Jones [mailto:Michael.Jones@microsoft.com] > Sent: Thursday, June 14, 2012 2:18 PM > To: Eran Hammer > Cc: oauth@ietf.org > Subject: RE: On the OAuth Core Spec >=20 > FYI, Eran, I'm going to hold off sending you proposed updated ABNF=20 > text for a few more days to let the discussions continue and consensus=20 > to build. I'm currently mentally targeting sending proposed draft update= s Monday. >=20 > Best wishes, > -- Mike >=20 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf=20 > Of Eran Hammer > Sent: Tuesday, June 12, 2012 11:53 AM > To: Derek Atkins > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] On the OAuth Core Spec >=20 > Derek - Thank you for this note. It is very much appreacited. >=20 > > From: Derek Atkins [mailto:derek@ihtfp.com] > > Sent: Tuesday, June 12, 2012 10:28 AM >=20 > > Having said that, are you still willing and able to be the editor of=20 > > this draft and see it to its conclusion and publication? >=20 > Yes. >=20 > > If so, we will need to get another > > draft out by this Friday (June 15), and I suspect we'll need another=20 > > draft that solves the encoding issue (brought up by the ABNF=20 > > exercise), targeting Friday, June 29th. Do you think you can make=20 > > these target dates (assuming that there is text for you to apply to=20 > > the > draft)? >=20 > There are two main open issues I'm aware of: >=20 > 1. Error registry text >=20 > * The text provided by Mike Jones for section 7.2 is unlcear. I have=20 > provided feedback on the list and am waiting to hear back from Mike (or a= nyone else). > Once I understand the actual intention of the new normative language,=20 > I will rework the text to reflect those changes. While I have strong=20 > objections to the error code registry in genreal, once decided, my=20 > only goal is to ensure the text is clear, complete, and reflects=20 > working group consensus. I do not have strong interest in how the=20 > working group resolves the rules around the registry as long as they are = clear and practical. The current text for 7.2 is not. >=20 > * In the consensus call for the error registry, Hannes requested (or=20 > suggested, it wasn't clear given the context) that the registry be=20 > implemented by IANA using separate tables. This requires prose changes=20 > to instruct IANA as such. Without changes, IANA will create a single=20 > table which is not what was requested. I have not seen much discussion=20 > on this. I am waiting for the chairs to clarify this and for someone=20 > to provide text if this is still the case (I have sent multiple emails on= this to the list). >=20 > 2. ABNF >=20 > * Mike Jones is doing solid work progressing the ABNF forward with the=20 > guidance of Julian. I trust Julian blindly to guide the text to a=20 > successful conculsion and the working group seems enaged. As soon as=20 > new text is available, I will incorporate and publish. If a schedule=20 > conflict arises in which I am unable to push the ABNF changes, I have=20 > no objections to Mike Jones pushing a new draft with only ABNF related=20 > change after quick coordination (Mike can submit using my contact and I'l= l approve it within a few hours). >=20 > I also have a short list of nits and typos reported to the list and me=20 > directly over the past few weeks which are all insignificant to list. >=20 > I am available to publish another draft on or by 6/14, and again on or=20 > by 6/27 (or 6/30 after my travel). I will be travelling on the exact=20 > dates listed. I am hoping that these dates are flexible within a few=20 > days range. In order for me to publish a new draft by 6/14, I will=20 > need the changes a day before to prepare. If the changes are ABNF=20 > only, I can work with Mike Jones to arrange it without putting my=20 > travel restriction in the way. I need the chairs to clarify what is=20 > expected in each of these drafts and how they seek to resolve the issues = around item #1 above to continue. >=20 > Again, thanks for the note. >=20 > EH > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 From wmills@yahoo-inc.com Thu Jun 14 14:48:12 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07DF521F85DD for ; Thu, 14 Jun 2012 14:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.514 X-Spam-Level: X-Spam-Status: No, score=-17.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dqaJuI1lg7xv for ; Thu, 14 Jun 2012 14:48:10 -0700 (PDT) Received: from nm5-vm0.bullet.mail.bf1.yahoo.com (nm5-vm0.bullet.mail.bf1.yahoo.com [98.139.213.150]) by ietfa.amsl.com (Postfix) with SMTP id 17B8F21F85DB for ; Thu, 14 Jun 2012 14:48:10 -0700 (PDT) Received: from [98.139.215.141] by nm5.bullet.mail.bf1.yahoo.com with NNFMP; 14 Jun 2012 21:48:09 -0000 Received: from [98.139.212.198] by tm12.bullet.mail.bf1.yahoo.com with NNFMP; 14 Jun 2012 21:48:09 -0000 Received: from [127.0.0.1] by omp1007.mail.bf1.yahoo.com with NNFMP; 14 Jun 2012 21:48:09 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 234598.56382.bm@omp1007.mail.bf1.yahoo.com Received: (qmail 35361 invoked by uid 60001); 14 Jun 2012 21:48:08 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1339710488; bh=oZLcgloBbAQ4Gd9/CZ7+wVg3uYyYBXH3CdMFLqeXAwA=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=gABTBuFjse4aOM85zqb2Kkrk0S5ob9yQgXCB0im82LxgoStfxy5IDlvcOz9cLt0iAP3crTTH8gdsrjbQX6YgrJfBajje7VdLDa5+vD69xCk1mhyfOOgHMRAoerFYyb7z7wkbswWK4me7UyAxvnMBcuhvirfCELuosjmrdt6Hvpw= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=lSZ39Bx8ceKE4r3uFlRCwI8jmCDz8v74XChf8Y0dxUWuxQrZ/6oaDYVwhlH6TiFkvR5n0w8zcY9geJl0aaDfbta3DIQdnRUDay0nZbT1tm3UCEQEoN1xz1nipoy1lpENzSQ96ZcH6lGFqT88M4pvFzZ3hPPfsCS/kzWOPMV83eQ=; X-YMail-OSG: Iw3XtnkVM1nCG0LGyV_TIxlIRWjqQP0mTV9h0H12AMIP9Af QjClgo8WzOpbSip5Fsy7ogfkZ_CIUp6LG1g5GU16aZ3xMU1YWrLDqcSv2wpi 5Hf9eVljCqBkd74wkjux9nng5rI32fVkttEY795f5tYsT_gIuF_IphJO.vQY 2_N257nvKrEYsEk_3UHNZgvw2ZVKV3EpHyDNWonQ8YICls2cHHhyUyS6allS fb2nUUNcl9FUYUybEcxkXmbiXFTZ7.zGqufP14XLIMc4Ipe6gwU4dTSaXl.8 Awh4KSeDGxlqUzHdBPdma7I87I_x5twmeb7JTO6KKkU0CN.q1SNloatuOvFT UR7W6zvUvJGfZu_tm_1DyLDEVADv3sI7eC8RjIXO7pE4e2aPtFiAX6N2NKMm qifWu0eArOeSm6XSz_loB0wqYQccpkDjnqUW5hkuD_HHPhGbpUw-- Received: from [209.131.62.115] by web31813.mail.mud.yahoo.com via HTTP; Thu, 14 Jun 2012 14:48:07 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.120.356233 References: <42B29A82-D8BA-40B8-9569-B209CBBBC3B7@gmx.net> <4E1F6AAD24975D4BA5B1680429673943665393AB@TK5EX14MBXC284.redmond.corp.microsoft.com> Message-ID: <1339710487.34288.YahooMailNeo@web31813.mail.mud.yahoo.com> Date: Thu, 14 Jun 2012 14:48:07 -0700 (PDT) From: William Mills To: Mike Jones , Hannes Tschofenig In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943665393AB@TK5EX14MBXC284.redmond.corp.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Error Registry: Conclusion X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 21:48:12 -0000 We might be able to combine these, but to me it really does make sense to h= ave one registry for OAuth 2 core extensions to the frameowrk and one for t= he auth profiles.=A0 The downside of this would be duplication between the = two.=A0 If we think there will be significant overlap then I think they sho= uld be merged, if they are mostly distinct then I would somewhat prefer sep= arate registries but I can live with either.=0A=0AMy tuppence.=0A=0A-bill= =0A=0A=0A=0A----- Original Message -----=0A> From: Mike Jones =0A> To: Hannes Tschofenig =0A> = Cc: "oauth@ietf.org WG" =0A> Sent: Thursday, June 14, 2012 = 2:40 PM=0A> Subject: Re: [OAUTH-WG] Error Registry: Conclusion=0A> =0A> Hi = Hannes,=0A> =0A> You stated a preference for separate registries below, but= that was a larger =0A> change to the OAuth Core spec than the current draf= t, which added a fourth error =0A> usage location "resource access error re= sponse" to the registry.=A0 To =0A> my knowledge, the consensus call didn't= ask people to express a preference =0A> between having four separate OAuth= Errors registries versus one OAuth Errors =0A> registry allowing any combi= nation of a set of four usage locations to be =0A> specified.=0A> =0A> Give= n that the two choices are completely equivalent, and we had previously =0A= > established the single OAuth Errors registry with three possible usage = =0A> locations, extending it to a fourth seemed to be both more natural and= easier =0A> for people to understand.=0A> =0A> Therefore, I'd like to ask = you to withdraw your suggestion and allow the =0A> existing structure of th= e OAuth Errors registry to remain.=0A> =0A> =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 = =A0=A0=A0 Thank you,=0A> =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 -- Mike=0A= > =0A> -----Original Message-----=0A> From: oauth-bounces@ietf.org [mailto:= oauth-bounces@ietf.org] On Behalf Of Hannes =0A> Tschofenig=0A> Sent: Tuesd= ay, May 15, 2012 2:27 PM=0A> To: oauth@ietf.org WG=0A> Subject: [OAUTH-WG] = Error Registry: Conclusion=0A> =0A> Hi all, =0A> =0A> on May 8th we called = for consensus on an open issue regarding the location of =0A> the error reg= istry. Here is the call for comments: =0A> http://www.ietf.org/mail-archive= /web/oauth/current/msg08952.html. =0A> =0A> Thank you all for the feedback.= The consensus is to create the registry in the =0A> core document.=0A> =0A= > Section 11.4.1 already sort-of creates sub-registries to illustrate where= the =0A> different errors can be used. This is needed since some of the er= rors may only =0A> appear in certain error responses. Hence, we need add an= other one to this list =0A> (suggestion: 'resource access error response').= In fact, I would prefer =0A> IANA to create separate tables for each of th= ese sub-registries to avoid =0A> confusion for the reader (instead of putti= ng everything into a single table). =0A> =0A> We believe that these changes= are really minor and address IESG feedback.=0A> =0A> Ciao=0A> Hannes & Der= ek=0A> =0A> =0A> _______________________________________________=0A> OAuth = mailing list=0A> OAuth@ietf.org=0A> https://www.ietf.org/mailman/listinfo/o= auth=0A> =0A> =0A> _______________________________________________=0A> OAut= h mailing list=0A> OAuth@ietf.org=0A> https://www.ietf.org/mailman/listinfo= /oauth=0A> From eran@hueniverse.com Thu Jun 14 14:52:59 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BB7F21F85D0 for ; Thu, 14 Jun 2012 14:52:59 -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.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id amQy-JW84SxF for ; Thu, 14 Jun 2012 14:52:58 -0700 (PDT) Received: from p3plex2out02.prod.phx3.secureserver.net (p3plex2out02.prod.phx3.secureserver.net [184.168.131.14]) by ietfa.amsl.com (Postfix) with ESMTP id 58C4421F859A for ; Thu, 14 Jun 2012 14:52:58 -0700 (PDT) Received: from P3PWEX2HT002.ex2.secureserver.net ([184.168.131.10]) by p3plex2out02.prod.phx3.secureserver.net with bizsmtp id NMsx1j00C0Dcg9U01MsxFk; Thu, 14 Jun 2012 14:52:57 -0700 Received: from P3PWEX2MB008.ex2.secureserver.net ([169.254.8.66]) by P3PWEX2HT002.ex2.secureserver.net ([184.168.131.10]) with mapi id 14.02.0247.003; Thu, 14 Jun 2012 14:52:57 -0700 From: Eran Hammer To: William Mills , Mike Jones , Hannes Tschofenig Thread-Topic: [OAUTH-WG] Error Registry: Conclusion Thread-Index: AQHNMuF2SEvCPjHVP0qi3ETkqD5Qwpb6hReggAB5QoD//4tzgA== Date: Thu, 14 Jun 2012 21:52:56 +0000 Message-ID: <0CBAEB56DDB3A140BA8E8C124C04ECA201073323@P3PWEX2MB008.ex2.secureserver.net> References: <42B29A82-D8BA-40B8-9569-B209CBBBC3B7@gmx.net> <4E1F6AAD24975D4BA5B1680429673943665393AB@TK5EX14MBXC284.redmond.corp.microsoft.com> <1339710487.34288.YahooMailNeo@web31813.mail.mud.yahoo.com> In-Reply-To: <1339710487.34288.YahooMailNeo@web31813.mail.mud.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [37.46.45.194] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Error Registry: Conclusion X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 21:52:59 -0000 We already have multiple registries. This one is about error codes only. I = don't think the overlap is clear at this point between errors on the core e= ndpoints vs error on the bearer and future auth schemes opting into this re= gistry. So it is hard to tell which format would be better. The main questi= on if we split the error registry into multiple tables is how registrations= are done because currently, the template is used as-is to insert a single = record into the IANA table. EH > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of William Mills > Sent: Thursday, June 14, 2012 2:48 PM > To: Mike Jones; Hannes Tschofenig > Cc: oauth@ietf.org WG > Subject: Re: [OAUTH-WG] Error Registry: Conclusion >=20 > We might be able to combine these, but to me it really does make sense to > have one registry for OAuth 2 core extensions to the frameowrk and one fo= r > the auth profiles.=A0 The downside of this would be duplication between t= he > two.=A0 If we think there will be significant overlap then I think they s= hould be > merged, if they are mostly distinct then I would somewhat prefer separate > registries but I can live with either. >=20 > My tuppence. >=20 > -bill >=20 >=20 >=20 > ----- Original Message ----- > > From: Mike Jones > > To: Hannes Tschofenig > > Cc: "oauth@ietf.org WG" > > Sent: Thursday, June 14, 2012 2:40 PM > > Subject: Re: [OAUTH-WG] Error Registry: Conclusion > > > > Hi Hannes, > > > > You stated a preference for separate registries below, but that was a > > larger change to the OAuth Core spec than the current draft, which > > added a fourth error usage location "resource access error response" > > to the registry.=A0 To my knowledge, the consensus call didn't ask > > people to express a preference between having four separate OAuth > > Errors registries versus one OAuth Errors registry allowing any > > combination of a set of four usage locations to be specified. > > > > Given that the two choices are completely equivalent, and we had > > previously established the single OAuth Errors registry with three > > possible usage locations, extending it to a fourth seemed to be both > > more natural and easier for people to understand. > > > > Therefore, I'd like to ask you to withdraw your suggestion and allow > > the existing structure of the OAuth Errors registry to remain. > > > > =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 Thank you, > > =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 -- Mike > > > > -----Original Message----- > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > > Of Hannes Tschofenig > > Sent: Tuesday, May 15, 2012 2:27 PM > > To: oauth@ietf.org WG > > Subject: [OAUTH-WG] Error Registry: Conclusion > > > > Hi all, > > > > on May 8th we called for consensus on an open issue regarding the > > location of the error registry. Here is the call for comments: > > http://www.ietf.org/mail-archive/web/oauth/current/msg08952.html. > > > > Thank you all for the feedback. The consensus is to create the > > registry in the core document. > > > > Section 11.4.1 already sort-of creates sub-registries to illustrate > > where the different errors can be used. This is needed since some of > > the errors may only appear in certain error responses. Hence, we need > > add another one to this list > > (suggestion: 'resource access error response'). In fact, I would > > prefer IANA to create separate tables for each of these sub-registries > > to avoid confusion for the reader (instead of putting everything into a > single table). > > > > We believe that these changes are really minor and address IESG feedbac= k. > > > > Ciao > > Hannes & Derek > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Thu Jun 14 14:58:46 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AF4611E8079 for ; Thu, 14 Jun 2012 14:58:46 -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 lgEp6r1QiMAs for ; Thu, 14 Jun 2012 14:58:45 -0700 (PDT) Received: from p3plex2out03.prod.phx3.secureserver.net (p3plex2out03.prod.phx3.secureserver.net [184.168.131.16]) by ietfa.amsl.com (Postfix) with ESMTP id B3C0421F84AC for ; Thu, 14 Jun 2012 14:58:45 -0700 (PDT) Received: from P3PWEX2HT001.ex2.secureserver.net ([184.168.131.9]) by p3plex2out03.prod.phx3.secureserver.net with bizsmtp id NMyl1j0050CJzpC01Myl7J; Thu, 14 Jun 2012 14:58:45 -0700 Received: from P3PWEX2MB008.ex2.secureserver.net ([169.254.8.66]) by P3PWEX2HT001.ex2.secureserver.net ([184.168.131.9]) with mapi id 14.02.0247.003; Thu, 14 Jun 2012 14:58:25 -0700 From: Eran Hammer To: "oauth@ietf.org WG (oauth@ietf.org)" Thread-Topic: Section 7.2 Thread-Index: Ac1KeB4PVUuFMDsJRu+q5d/rw0G4WQ== Date: Thu, 14 Jun 2012 21:58:23 +0000 Message-ID: <0CBAEB56DDB3A140BA8E8C124C04ECA201073394@P3PWEX2MB008.ex2.secureserver.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [37.46.45.194] Content-Type: multipart/alternative; boundary="_000_0CBAEB56DDB3A140BA8E8C124C04ECA201073394P3PWEX2MB008ex2_" MIME-Version: 1.0 Subject: [OAUTH-WG] Section 7.2 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 21:58:46 -0000 --_000_0CBAEB56DDB3A140BA8E8C124C04ECA201073394P3PWEX2MB008ex2_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable One simple solution is to define the new error location as an opt-in regist= ry for oauth-centric token authentication methods. Instead of requiring new= schemes to use it and deal with all the confusing qualifications, just nar= rowly define the new registry as a service for new token authentication met= hods seeking to share a common error representation format with the Bearer = and other schemes. This removes the explicit 'error' parameter name issue, = as well as any other restrictions or limitations. It also removes the MUST. IOW, the new text will establish a common registry for sharing error codes = across oauth-centric token authentication schemes and can recommend that su= ch schemes opt into the registry if they return error status beyong HTTP co= des. Such a resolution will be simple to explain and will make the registry= intentions very clear and straigh forward. If this is acceptable, I can propose new text for 7.2 based on the latest d= raft. Just an idea. EH --_000_0CBAEB56DDB3A140BA8E8C124C04ECA201073394P3PWEX2MB008ex2_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

One simple solution is to define the new error locat= ion as an opt-in registry for oauth-centric token authentication methods. I= nstead of requiring new schemes to use it and deal with all the confusing q= ualifications, just narrowly define the new registry as a service for new token authentication methods seeking= to share a common error representation format with the Bearer and other sc= hemes. This removes the explicit 'error' parameter name issue, as well as a= ny other restrictions or limitations. It also removes the MUST.

 

IOW, the new text will establish a common registry f= or sharing error codes across oauth-centric token authentication schemes an= d can recommend that such schemes opt into the registry if they return erro= r status beyong HTTP codes. Such a resolution will be simple to explain and will make the registry intentions= very clear and straigh forward.

 

If this is acceptable, I can propose new text for 7.= 2 based on the latest draft.

 

Just an idea.

 

EH

--_000_0CBAEB56DDB3A140BA8E8C124C04ECA201073394P3PWEX2MB008ex2_-- From Michael.Jones@microsoft.com Thu Jun 14 15:00:04 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E568421F84B6 for ; Thu, 14 Jun 2012 15:00:04 -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 NqXUwWx+V76J for ; Thu, 14 Jun 2012 15:00:04 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe004.messaging.microsoft.com [216.32.180.14]) by ietfa.amsl.com (Postfix) with ESMTP id A6F6C21F84A7 for ; Thu, 14 Jun 2012 15:00:03 -0700 (PDT) Received: from mail220-va3-R.bigfish.com (10.7.14.251) by VA3EHSOBE001.bigfish.com (10.7.40.21) with Microsoft SMTP Server id 14.1.225.23; Thu, 14 Jun 2012 21:58:54 +0000 Received: from mail220-va3 (localhost [127.0.0.1]) by mail220-va3-R.bigfish.com (Postfix) with ESMTP id 6854220212; Thu, 14 Jun 2012 21:58:54 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC105.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -29 X-BigFish: VS-29(zzbb2dI9371I14ffI542Mc85dh1432Izz1202hzz8275ch1033IL8275bh8275dhz2fh2a8h668h839hd25hf0ah) Received-SPF: pass (mail220-va3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC105.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail220-va3 (localhost.localdomain [127.0.0.1]) by mail220-va3 (MessageSwitch) id 1339711132863696_24539; Thu, 14 Jun 2012 21:58:52 +0000 (UTC) Received: from VA3EHSMHS019.bigfish.com (unknown [10.7.14.239]) by mail220-va3.bigfish.com (Postfix) with ESMTP id D0CABC00045; Thu, 14 Jun 2012 21:58:52 +0000 (UTC) Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS019.bigfish.com (10.7.99.29) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 14 Jun 2012 21:58:51 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.189]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.02.0309.003; Thu, 14 Jun 2012 21:59:58 +0000 From: Mike Jones To: Eran Hammer , William Mills , Hannes Tschofenig Thread-Topic: [OAUTH-WG] Error Registry: Conclusion Thread-Index: AQHNMuF2SEvCPjHVP0qi3ETkqD5Qwpb6hReggAAD6oCAAAFYAIAAAfdH Date: Thu, 14 Jun 2012 21:59:57 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436653949A@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <42B29A82-D8BA-40B8-9569-B209CBBBC3B7@gmx.net> <4E1F6AAD24975D4BA5B1680429673943665393AB@TK5EX14MBXC284.redmond.corp.microsoft.com> <1339710487.34288.YahooMailNeo@web31813.mail.mud.yahoo.com>, <0CBAEB56DDB3A140BA8E8C124C04ECA201073323@P3PWEX2MB008.ex2.secureserver.net> In-Reply-To: <0CBAEB56DDB3A140BA8E8C124C04ECA201073323@P3PWEX2MB008.ex2.secureserver.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436653949ATK5EX14MBXC284r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Error Registry: Conclusion X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 22:00:05 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436653949ATK5EX14MBXC284r_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yes, we already have multiple registries, but only one for errors. When an= error code can be used in more than one usage location, having one will ma= ke the registrations simpler and it may be somewhat more apparent how the e= rror code is used. The two structures are equivalent, but it seems to me that having one is mo= re convenient and simpler than having four. -- Mike ________________________________ From: Eran Hammer Sent: 6/14/2012 2:53 PM To: William Mills; Mike Jones; Hannes Tschofenig Cc: oauth@ietf.org WG Subject: RE: [OAUTH-WG] Error Registry: Conclusion We already have multiple registries. This one is about error codes only. I = don't think the overlap is clear at this point between errors on the core e= ndpoints vs error on the bearer and future auth schemes opting into this re= gistry. So it is hard to tell which format would be better. The main questi= on if we split the error registry into multiple tables is how registrations= are done because currently, the template is used as-is to insert a single = record into the IANA table. EH > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of William Mills > Sent: Thursday, June 14, 2012 2:48 PM > To: Mike Jones; Hannes Tschofenig > Cc: oauth@ietf.org WG > Subject: Re: [OAUTH-WG] Error Registry: Conclusion > > We might be able to combine these, but to me it really does make sense to > have one registry for OAuth 2 core extensions to the frameowrk and one fo= r > the auth profiles. The downside of this would be duplication between the > two. If we think there will be significant overlap then I think they sho= uld be > merged, if they are mostly distinct then I would somewhat prefer separate > registries but I can live with either. > > My tuppence. > > -bill > > > > ----- Original Message ----- > > From: Mike Jones > > To: Hannes Tschofenig > > Cc: "oauth@ietf.org WG" > > Sent: Thursday, June 14, 2012 2:40 PM > > Subject: Re: [OAUTH-WG] Error Registry: Conclusion > > > > Hi Hannes, > > > > You stated a preference for separate registries below, but that was a > > larger change to the OAuth Core spec than the current draft, which > > added a fourth error usage location "resource access error response" > > to the registry. To my knowledge, the consensus call didn't ask > > people to express a preference between having four separate OAuth > > Errors registries versus one OAuth Errors registry allowing any > > combination of a set of four usage locations to be specified. > > > > Given that the two choices are completely equivalent, and we had > > previously established the single OAuth Errors registry with three > > possible usage locations, extending it to a fourth seemed to be both > > more natural and easier for people to understand. > > > > Therefore, I'd like to ask you to withdraw your suggestion and allow > > the existing structure of the OAuth Errors registry to remain. > > > > Thank you, > > -- Mike > > > > -----Original Message----- > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > > Of Hannes Tschofenig > > Sent: Tuesday, May 15, 2012 2:27 PM > > To: oauth@ietf.org WG > > Subject: [OAUTH-WG] Error Registry: Conclusion > > > > Hi all, > > > > on May 8th we called for consensus on an open issue regarding the > > location of the error registry. Here is the call for comments: > > http://www.ietf.org/mail-archive/web/oauth/current/msg08952.html. > > > > Thank you all for the feedback. The consensus is to create the > > registry in the core document. > > > > Section 11.4.1 already sort-of creates sub-registries to illustrate > > where the different errors can be used. This is needed since some of > > the errors may only appear in certain error responses. Hence, we need > > add another one to this list > > (suggestion: 'resource access error response'). In fact, I would > > prefer IANA to create separate tables for each of these sub-registries > > to avoid confusion for the reader (instead of putting everything into a > single table). > > > > We believe that these changes are really minor and address IESG feedbac= k. > > > > Ciao > > Hannes & Derek > > > > > > _______________________________________________ > > OAuth mailing 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_4E1F6AAD24975D4BA5B16804296739436653949ATK5EX14MBXC284r_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Yes, we alrea= dy have multiple registries, but only one for errors.  When an error c= ode can be used in more than one usage location, having one will make the r= egistrations simpler and it may be somewhat more apparent how the error code is used.

The two structures are equivalent, but it seems to me that having one is mo= re convenient and simpler than having four.

-- Mike

From: Eran H= ammer
Sent: 6/14/2= 012 2:53 PM
To: Willia= m Mills; Mike Jones; Hannes Tschofenig
Cc: oauth@= ietf.org WG
Subject: RE: [O= AUTH-WG] Error Registry: Conclusion

We already have multiple registries. This one is a= bout error codes only. I don't think the overlap is clear at this point bet= ween errors on the core endpoints vs error on the bearer and future auth sc= hemes opting into this registry. So it is hard to tell which format would be better. The main question if we s= plit the error registry into multiple tables is how registrations are done = because currently, the template is used as-is to insert a single record int= o the IANA table.

EH


> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> Of William Mills
> Sent: Thursday, June 14, 2012 2:48 PM
> To: Mike Jones; Hannes Tschofenig
> Cc: oauth@ietf.org WG
> Subject: Re: [OAUTH-WG] Error Registry: Conclusion
>
> We might be able to combine these, but to me it really does make sense= to
> have one registry for OAuth 2 core extensions to the frameowrk and one= for
> the auth profiles.  The downside of this would be duplication bet= ween the
> two.  If we think there will be significant overlap then I think = they should be
> merged, if they are mostly distinct then I would somewhat prefer separ= ate
> registries but I can live with either.
>
> My tuppence.
>
> -bill
>
>
>
> ----- Original Message -----
> > From: Mike Jones <Michael.Jones@microsoft.com>
> > To: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
> > Cc: "oauth@ietf.org WG" <oauth@ietf.org>
> > Sent: Thursday, June 14, 2012 2:40 PM
> > Subject: Re: [OAUTH-WG] Error Registry: Conclusion
> >
> > Hi Hannes,
> >
> > You stated a preference for separate registries below, but that w= as a
> > larger change to the OAuth Core spec than the current draft, whic= h
> > added a fourth error usage location "resource access error r= esponse"
> > to the registry.  To my knowledge, the consensus call didn't= ask
> > people to express a preference between having four separate OAuth=
> > Errors registries versus one OAuth Errors registry allowing any > > combination of a set of four usage locations to be specified.
> >
> > Given that the two choices are completely equivalent, and we had<= br> > > previously established the single OAuth Errors registry with thre= e
> > possible usage locations, extending it to a fourth seemed to be b= oth
> > more natural and easier for people to understand.
> >
> > Therefore, I'd like to ask you to withdraw your suggestion and al= low
> > the existing structure of the OAuth Errors registry to remain. > >
> >              &n= bsp;  Thank you,
> >              &n= bsp;  -- Mike
> >
> > -----Original Message-----
> > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> > Of Hannes Tschofenig
> > Sent: Tuesday, May 15, 2012 2:27 PM
> > To: oauth@ietf.org WG
> > Subject: [OAUTH-WG] Error Registry: Conclusion
> >
> > Hi all,
> >
> > on May 8th we called for consensus on an open issue regarding the=
> > location of the error registry. Here is the call for comments: > > http://www.ietf.org/mail-archive/web/oauth/current/msg08952.htm= l.
> >
> > Thank you all for the feedback. The consensus is to create the > > registry in the core document.
> >
> > Section 11.4.1 already sort-of creates sub-registries to illustra= te
> > where the different errors can be used. This is needed since some= of
> > the errors may only appear in certain error responses. Hence, we = need
> > add another one to this list
> > (suggestion: 'resource access error response'). In fact, I would<= br> > > prefer IANA to create separate tables for each of these sub-regis= tries
> > to avoid confusion for the reader (instead of putting everything = into a
> single table).
> >
> > We believe that these changes are really minor and address IESG f= eedback.
> >
> > Ciao
> > Hannes & Derek
> >
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://w= ww.ietf.org/mailman/listinfo/oauth
> >
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://w= ww.ietf.org/mailman/listinfo/oauth
> >
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ie= tf.org/mailman/listinfo/oauth

 --_000_4E1F6AAD24975D4BA5B16804296739436653949ATK5EX14MBXC284r_-- From Michael.Jones@microsoft.com Thu Jun 14 15:01:57 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45ADE11E80A2 for ; Thu, 14 Jun 2012 15:01:57 -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 T8EfoiVDi5Dc for ; Thu, 14 Jun 2012 15:01:56 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe006.messaging.microsoft.com [213.199.154.144]) by ietfa.amsl.com (Postfix) with ESMTP id 3D1C511E809F for ; Thu, 14 Jun 2012 15:01:55 -0700 (PDT) Received: from mail72-db3-R.bigfish.com (10.3.81.248) by DB3EHSOBE002.bigfish.com (10.3.84.22) with Microsoft SMTP Server id 14.1.225.23; Thu, 14 Jun 2012 22:00:43 +0000 Received: from mail72-db3 (localhost [127.0.0.1]) by mail72-db3-R.bigfish.com (Postfix) with ESMTP id 3CC6EE0337; Thu, 14 Jun 2012 22:00:43 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: VS-22(zzbb2dI9371Ic85fhzz1202hzz1033IL8275dhz2fh2a8h668h839hd25hf0ah) Received-SPF: pass (mail72-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC107.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail72-db3 (localhost.localdomain [127.0.0.1]) by mail72-db3 (MessageSwitch) id 1339711240990668_20775; Thu, 14 Jun 2012 22:00:40 +0000 (UTC) Received: from DB3EHSMHS002.bigfish.com (unknown [10.3.81.238]) by mail72-db3.bigfish.com (Postfix) with ESMTP id F0226C0225; Thu, 14 Jun 2012 22:00:40 +0000 (UTC) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS002.bigfish.com (10.3.87.102) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 14 Jun 2012 22:00:39 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.189]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.02.0309.003; Thu, 14 Jun 2012 22:01:47 +0000 From: Mike Jones To: Eran Hammer , "oauth@ietf.org WG (oauth@ietf.org)" Thread-Topic: [OAUTH-WG] Section 7.2 Thread-Index: AQHNSnlK4rMFHIKNpEG6QNgV8mtEhA== Date: Thu, 14 Jun 2012 22:01:46 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943665394D7@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <0CBAEB56DDB3A140BA8E8C124C04ECA201073394@P3PWEX2MB008.ex2.secureserver.net> In-Reply-To: <0CBAEB56DDB3A140BA8E8C124C04ECA201073394@P3PWEX2MB008.ex2.secureserver.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943665394D7TK5EX14MBXC284r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [OAUTH-WG] Section 7.2 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 22:01:57 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943665394D7TK5EX14MBXC284r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable That sounds fine to me. If you want to take a stab at proposed text, have = at it! -- Mike ________________________________ From: Eran Hammer Sent: 6/14/2012 2:59 PM To: oauth@ietf.org WG (oauth@ietf.org) Subject: [OAUTH-WG] Section 7.2 One simple solution is to define the new error location as an opt-in regist= ry for oauth-centric token authentication methods. Instead of requiring new= schemes to use it and deal with all the confusing qualifications, just nar= rowly define the new registry as a service for new token authentication met= hods seeking to share a common error representation format with the Bearer = and other schemes. This removes the explicit 'error' parameter name issue, = as well as any other restrictions or limitations. It also removes the MUST. IOW, the new text will establish a common registry for sharing error codes = across oauth-centric token authentication schemes and can recommend that su= ch schemes opt into the registry if they return error status beyong HTTP co= des. Such a resolution will be simple to explain and will make the registry= intentions very clear and straigh forward. If this is acceptable, I can propose new text for 7.2 based on the latest d= raft. Just an idea. EH --_000_4E1F6AAD24975D4BA5B1680429673943665394D7TK5EX14MBXC284r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
That sounds f= ine to me.  If you want to take a stab at proposed text, have at it!
-- Mike

From: Eran H= ammer
Sent: 6/14/2= 012 2:59 PM
To: oauth@= ietf.org WG (oauth@ietf.org)
Subject: [OAUTH= -WG] Section 7.2

One simple solution is to define the new error locat= ion as an opt-in registry for oauth-centric token authentication methods. I= nstead of requiring new schemes to use it and deal with all the confusing q= ualifications, just narrowly define the new registry as a service for new token authentication methods seeking= to share a common error representation format with the Bearer and other sc= hemes. This removes the explicit 'error' parameter name issue, as well as a= ny other restrictions or limitations. It also removes the MUST.

 

IOW, the new text will establish a common registry f= or sharing error codes across oauth-centric token authentication schemes an= d can recommend that such schemes opt into the registry if they return erro= r status beyong HTTP codes. Such a resolution will be simple to explain and will make the registry intentions= very clear and straigh forward.

 

If this is acceptable, I can propose new text for 7.= 2 based on the latest draft.

 

Just an idea.

 

EH

--_000_4E1F6AAD24975D4BA5B1680429673943665394D7TK5EX14MBXC284r_-- From eran@hueniverse.com Thu Jun 14 15:02:31 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F20EE21F8547 for ; Thu, 14 Jun 2012 15:02:30 -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 Ca4YapmMf8qY for ; Thu, 14 Jun 2012 15:02:30 -0700 (PDT) Received: from p3plex2out01.prod.phx3.secureserver.net (p3plex2out01.prod.phx3.secureserver.net [184.168.131.12]) by ietfa.amsl.com (Postfix) with ESMTP id D594C21F8546 for ; Thu, 14 Jun 2012 15:02:29 -0700 (PDT) Received: from P3PWEX2HT001.ex2.secureserver.net ([184.168.131.9]) by p3plex2out01.prod.phx3.secureserver.net with bizsmtp id NN2V1j0020CJzpC01N2Vi6; Thu, 14 Jun 2012 15:02:29 -0700 Received: from P3PWEX2MB008.ex2.secureserver.net ([169.254.8.66]) by P3PWEX2HT001.ex2.secureserver.net ([184.168.131.9]) with mapi id 14.02.0247.003; Thu, 14 Jun 2012 15:02:29 -0700 From: Eran Hammer To: Mike Jones , William Mills , Hannes Tschofenig Thread-Topic: [OAUTH-WG] Error Registry: Conclusion Thread-Index: AQHNMuF2SEvCPjHVP0qi3ETkqD5Qwpb6hReggAB5QoD//4tzgIAAd9yA//+K8uA= Date: Thu, 14 Jun 2012 22:02:28 +0000 Message-ID: <0CBAEB56DDB3A140BA8E8C124C04ECA2010733C3@P3PWEX2MB008.ex2.secureserver.net> References: <42B29A82-D8BA-40B8-9569-B209CBBBC3B7@gmx.net> <4E1F6AAD24975D4BA5B1680429673943665393AB@TK5EX14MBXC284.redmond.corp.microsoft.com> <1339710487.34288.YahooMailNeo@web31813.mail.mud.yahoo.com>, <0CBAEB56DDB3A140BA8E8C124C04ECA201073323@P3PWEX2MB008.ex2.secureserver.net> <4E1F6AAD24975D4BA5B16804296739436653949A@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436653949A@TK5EX14MBXC284.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [37.46.45.194] Content-Type: multipart/alternative; boundary="_000_0CBAEB56DDB3A140BA8E8C124C04ECA2010733C3P3PWEX2MB008ex2_" MIME-Version: 1.0 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Error Registry: Conclusion X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 22:02:31 -0000 --_000_0CBAEB56DDB3A140BA8E8C124C04ECA2010733C3P3PWEX2MB008ex2_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It seems to me that a single table is a better way to accomplish the goals = set by the working group. The entire reason for adding the new location was= based on the assumption that there will be overlap. EH From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Thursday, June 14, 2012 3:00 PM To: Eran Hammer; William Mills; Hannes Tschofenig Cc: oauth@ietf.org WG Subject: RE: [OAUTH-WG] Error Registry: Conclusion Yes, we already have multiple registries, but only one for errors. When an= error code can be used in more than one usage location, having one will ma= ke the registrations simpler and it may be somewhat more apparent how the e= rror code is used. The two structures are equivalent, but it seems to me that having one is mo= re convenient and simpler than having four. -- Mike ________________________________ From: Eran Hammer Sent: 6/14/2012 2:53 PM To: William Mills; Mike Jones; Hannes Tschofenig Cc: oauth@ietf.org WG Subject: RE: [OAUTH-WG] Error Registry: Conclusion We already have multiple registries. This one is about error codes only. I = don't think the overlap is clear at this point between errors on the core e= ndpoints vs error on the bearer and future auth schemes opting into this re= gistry. So it is hard to tell which format would be better. The main questi= on if we split the error registry into multiple tables is how registrations= are done because currently, the template is used as-is to insert a single = record into the IANA table. EH > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth= -bounces@ietf.org] On Behalf > Of William Mills > Sent: Thursday, June 14, 2012 2:48 PM > To: Mike Jones; Hannes Tschofenig > Cc: oauth@ietf.org WG > Subject: Re: [OAUTH-WG] Error Registry: Conclusion > > We might be able to combine these, but to me it really does make sense to > have one registry for OAuth 2 core extensions to the frameowrk and one fo= r > the auth profiles. The downside of this would be duplication between the > two. If we think there will be significant overlap then I think they sho= uld be > merged, if they are mostly distinct then I would somewhat prefer separate > registries but I can live with either. > > My tuppence. > > -bill > > > > ----- Original Message ----- > > From: Mike Jones > > > To: Hannes Tschofenig > > > Cc: "oauth@ietf.org WG" > > > Sent: Thursday, June 14, 2012 2:40 PM > > Subject: Re: [OAUTH-WG] Error Registry: Conclusion > > > > Hi Hannes, > > > > You stated a preference for separate registries below, but that was a > > larger change to the OAuth Core spec than the current draft, which > > added a fourth error usage location "resource access error response" > > to the registry. To my knowledge, the consensus call didn't ask > > people to express a preference between having four separate OAuth > > Errors registries versus one OAuth Errors registry allowing any > > combination of a set of four usage locations to be specified. > > > > Given that the two choices are completely equivalent, and we had > > previously established the single OAuth Errors registry with three > > possible usage locations, extending it to a fourth seemed to be both > > more natural and easier for people to understand. > > > > Therefore, I'd like to ask you to withdraw your suggestion and allow > > the existing structure of the OAuth Errors registry to remain. > > > > Thank you, > > -- Mike > > > > -----Original Message----- > > From: oauth-bounces@ietf.org [mailto:oau= th-bounces@ietf.org] On Behalf > > Of Hannes Tschofenig > > Sent: Tuesday, May 15, 2012 2:27 PM > > To: oauth@ietf.org WG > > Subject: [OAUTH-WG] Error Registry: Conclusion > > > > Hi all, > > > > on May 8th we called for consensus on an open issue regarding the > > location of the error registry. Here is the call for comments: > > http://www.ietf.org/mail-archive/web/oauth/current/msg08952.html. > > > > Thank you all for the feedback. The consensus is to create the > > registry in the core document. > > > > Section 11.4.1 already sort-of creates sub-registries to illustrate > > where the different errors can be used. This is needed since some of > > the errors may only appear in certain error responses. Hence, we need > > add another one to this list > > (suggestion: 'resource access error response'). In fact, I would > > prefer IANA to create separate tables for each of these sub-registries > > to avoid confusion for the reader (instead of putting everything into a > single table). > > > > We believe that these changes are really minor and address IESG feedbac= k. > > > > Ciao > > Hannes & Derek > > > > > > _______________________________________________ > > OAuth mailing 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_0CBAEB56DDB3A140BA8E8C124C04ECA2010733C3P3PWEX2MB008ex2_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

It seems to me that a sin= gle table is a better way to accomplish the goals set by the working group.= The entire reason for adding the new location was based on the assumption that there will be overlap.

 <= /p>

EH

 <= /p>

 <= /p>

 <= /p>

From: Mike Jon= es [mailto:Michael.Jones@microsoft.com]
Sent: Thursday, June 14, 2012 3:00 PM
To: Eran Hammer; William Mills; Hannes Tschofenig
Cc: oauth@ietf.org WG
Subject: RE: [OAUTH-WG] Error Registry: Conclusion=

 

Yes, we = already have multiple registries, but only one for errors.  When an er= ror code can be used in more than one usage location, having one will make the registrations simpler and it may be somewhat more apparent h= ow the error code is used.

The two structures are equivalent, but it seems to me that having one is mo= re convenient and simpler than having four.

-- Mike

From: Eran Hammer
Sent: 6/14/2012 2:53 PM
To: William Mills; Mike Jones; Hannes= Tschofenig
Cc: oauth@ietf.org WG
Subject: RE: [OAUTH-WG] Error Registry: Conclusion=

We already have multiple registries. This one is about error co= des only. I don't think the overlap is clear at this point between errors o= n the core endpoints vs error on the bearer and future auth schemes opting into this registry. So it is hard to tell w= hich format would be better. The main question if we split the error regist= ry into multiple tables is how registrations are done because currently, th= e template is used as-is to insert a single record into the IANA table.

EH


> -----Original Message-----
> From: oauth-bounces@ietf.org= [mailto:oauth-bounces@ietf.o= rg] On Behalf
> Of William Mills
> Sent: Thursday, June 14, 2012 2:48 PM
> To: Mike Jones; Hannes Tschofenig
> Cc: oauth@ietf.org WG
> Subject: Re: [OAUTH-WG] Error Registry: Conclusion
>
> We might be able to combine these, but to me it really does make sense= to
> have one registry for OAuth 2 core extensions to the frameowrk and one= for
> the auth profiles.  The downside of this would be duplication bet= ween the
> two.  If we think there will be significant overlap then I think = they should be
> merged, if they are mostly distinct then I would somewhat prefer separ= ate
> registries but I can live with either.
>
> My tuppence.
>
> -bill
>
>
>
> ----- Original Message -----
> > From: Mike Jones <Michael.Jones@microsoft.com>
> > To: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
> > Cc: "oauth@ietf.org W= G" <oauth@ietf.org> > > Sent: Thursday, June 14, 2012 2:40 PM
> > Subject: Re: [OAUTH-WG] Error Registry: Conclusion
> >
> > Hi Hannes,
> >
> > You stated a preference for separate registries below, but that w= as a
> > larger change to the OAuth Core spec than the current draft, whic= h
> > added a fourth error usage location "resource access error r= esponse"
> > to the registry.  To my knowledge, the consensus call didn't= ask
> > people to express a preference between having four separate OAuth=
> > Errors registries versus one OAuth Errors registry allowing any > > combination of a set of four usage locations to be specified.
> >
> > Given that the two choices are completely equivalent, and we had<= br> > > previously established the single OAuth Errors registry with thre= e
> > possible usage locations, extending it to a fourth seemed to be b= oth
> > more natural and easier for people to understand.
> >
> > Therefore, I'd like to ask you to withdraw your suggestion and al= low
> > the existing structure of the OAuth Errors registry to remain. > >
> >              &n= bsp;  Thank you,
> >              &n= bsp;  -- Mike
> >
> > -----Original Message-----
> > From: oauth-bounces@iet= f.org [mailto:oauth-bounces@i= etf.org] On Behalf
> > Of Hannes Tschofenig
> > Sent: Tuesday, May 15, 2012 2:27 PM
> > To: oauth@ietf.org WG
> > Subject: [OAUTH-WG] Error Registry: Conclusion
> >
> > Hi all,
> >
> > on May 8th we called for consensus on an open issue regarding the=
> > location of the error registry. Here is the call for comments: > > http://www.ietf.org/mail-archive/web/oauth/current/msg08952.htm= l.
> >
> > Thank you all for the feedback. The consensus is to create the > > registry in the core document.
> >
> > Section 11.4.1 already sort-of creates sub-registries to illustra= te
> > where the different errors can be used. This is needed since some= of
> > the errors may only appear in certain error responses. Hence, we = need
> > add another one to this list
> > (suggestion: 'resource access error response'). In fact, I would<= br> > > prefer IANA to create separate tables for each of these sub-regis= tries
> > to avoid confusion for the reader (instead of putting everything = into a
> single table).
> >
> > We believe that these changes are really minor and address IESG f= eedback.
> >
> > Ciao
> > Hannes & Derek
> >
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://w= ww.ietf.org/mailman/listinfo/oauth
> >
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://w= ww.ietf.org/mailman/listinfo/oauth
> >
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ie= tf.org/mailman/listinfo/oauth

--_000_0CBAEB56DDB3A140BA8E8C124C04ECA2010733C3P3PWEX2MB008ex2_-- From eran@hueniverse.com Thu Jun 14 15:24:06 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E5A011E80A1 for ; Thu, 14 Jun 2012 15:24:06 -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.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VvBkVakUeaez for ; Thu, 14 Jun 2012 15:24:05 -0700 (PDT) Received: from p3plex2out03.prod.phx3.secureserver.net (p3plex2out03.prod.phx3.secureserver.net [184.168.131.16]) by ietfa.amsl.com (Postfix) with ESMTP id 45BAB11E809A for ; Thu, 14 Jun 2012 15:24:05 -0700 (PDT) Received: from P3PWEX2HT001.ex2.secureserver.net ([184.168.131.9]) by p3plex2out03.prod.phx3.secureserver.net with bizsmtp id NNQ51j0010CJzpC01NQ5gk; Thu, 14 Jun 2012 15:24:05 -0700 Received: from P3PWEX2MB008.ex2.secureserver.net ([169.254.8.66]) by P3PWEX2HT001.ex2.secureserver.net ([184.168.131.9]) with mapi id 14.02.0247.003; Thu, 14 Jun 2012 15:23:21 -0700 From: Eran Hammer To: Mike Jones , "oauth@ietf.org WG (oauth@ietf.org)" Thread-Topic: [OAUTH-WG] Section 7.2 Thread-Index: Ac1KeB4PVUuFMDsJRu+q5d/rw0G4WQAO9iAAAA6cN3A= Date: Thu, 14 Jun 2012 22:23:20 +0000 Message-ID: <0CBAEB56DDB3A140BA8E8C124C04ECA2010734C5@P3PWEX2MB008.ex2.secureserver.net> References: <0CBAEB56DDB3A140BA8E8C124C04ECA201073394@P3PWEX2MB008.ex2.secureserver.net> <4E1F6AAD24975D4BA5B1680429673943665394D7@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943665394D7@TK5EX14MBXC284.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [37.46.45.194] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Section 7.2 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 22:24:06 -0000 7.2. Error Response If a resource access request fails, the resource server SHOULD inform the client of the error. While the specifics of such error responses are beyond the scope of this specification, this documents establishes a common registry for error values to be shared among OAuth token authentication schemes.=20 New authentication schemes desgined primarily for OAuth token authentiction SHOULD define a mechanism for providing an error status code to the client, in which the error values allowed are registered in the error registry established by this specification. Such schemes MAY limit the set of valid error codes to a subset of the registered values. If the error code is returned using a named parameter= , the parameter name SHOULD be "error". Other schemes capable of being used for OAuth token authentication, but not primarily designed for that purpose, MAY bind their error values to = the registry in the same manner. EH From eran@hueniverse.com Thu Jun 14 15:29:13 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77AB811E809B for ; Thu, 14 Jun 2012 15:29: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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uAH5kqUKeviy for ; Thu, 14 Jun 2012 15:29:12 -0700 (PDT) Received: from p3plex2out02.prod.phx3.secureserver.net (p3plex2out02.prod.phx3.secureserver.net [184.168.131.14]) by ietfa.amsl.com (Postfix) with ESMTP id E8C0111E807F for ; Thu, 14 Jun 2012 15:29:11 -0700 (PDT) Received: from P3PWEX2HT003.ex2.secureserver.net ([184.168.131.11]) by p3plex2out02.prod.phx3.secureserver.net with bizsmtp id NNVB1j0070EuLVk01NVBKT; Thu, 14 Jun 2012 15:29:11 -0700 Received: from P3PWEX2MB008.ex2.secureserver.net ([169.254.8.66]) by P3PWEX2HT003.ex2.secureserver.net ([184.168.131.11]) with mapi id 14.02.0247.003; Thu, 14 Jun 2012 15:29:11 -0700 From: Eran Hammer To: Eran Hammer , Mike Jones , "oauth@ietf.org WG (oauth@ietf.org)" Thread-Topic: [OAUTH-WG] Section 7.2 Thread-Index: Ac1KeB4PVUuFMDsJRu+q5d/rw0G4WQAO9iAAAA6cN3AAHFVLIA== Date: Thu, 14 Jun 2012 22:29:10 +0000 Message-ID: <0CBAEB56DDB3A140BA8E8C124C04ECA201073573@P3PWEX2MB008.ex2.secureserver.net> References: <0CBAEB56DDB3A140BA8E8C124C04ECA201073394@P3PWEX2MB008.ex2.secureserver.net> <4E1F6AAD24975D4BA5B1680429673943665394D7@TK5EX14MBXC284.redmond.corp.microsoft.com> <0CBAEB56DDB3A140BA8E8C124C04ECA2010734C5@P3PWEX2MB008.ex2.secureserver.net> In-Reply-To: <0CBAEB56DDB3A140BA8E8C124C04ECA2010734C5@P3PWEX2MB008.ex2.secureserver.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [37.46.45.194] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Section 7.2 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 22:29:13 -0000 Mike - if you want to add the other error parameters as suggestions, that w= ould be fine by me. EH > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Eran Hammer > Sent: Thursday, June 14, 2012 3:23 PM > To: Mike Jones; oauth@ietf.org WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Section 7.2 >=20 > 7.2. Error Response >=20 > If a resource access request fails, the resource server SHOULD inform > the client of the error. While the specifics of such error responses > are beyond the scope of this specification, this documents establishes > a common registry for error values to be shared among OAuth token > authentication schemes. >=20 > New authentication schemes desgined primarily for OAuth token > authentiction SHOULD define a mechanism for providing an > error status code to the client, in which the error values allowed are > registered in the error registry established by this specification. Su= ch > schemes MAY limit the set of valid error codes to a subset of the > registered values. If the error code is returned using a named paramet= er, > the parameter name SHOULD be "error". >=20 > Other schemes capable of being used for OAuth token authentication, bu= t > not primarily designed for that purpose, MAY bind their error values t= o the > registry in the same manner. >=20 > EH >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From Michael.Jones@microsoft.com Thu Jun 14 18:15:45 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B10A611E80A1 for ; Thu, 14 Jun 2012 18:15:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.735 X-Spam-Level: X-Spam-Status: No, score=-3.735 tagged_above=-999 required=5 tests=[AWL=-0.137, 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 vavw6N4bmexS for ; Thu, 14 Jun 2012 18:15:44 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe001.messaging.microsoft.com [213.199.154.204]) by ietfa.amsl.com (Postfix) with ESMTP id 2EB5F11E808F for ; Thu, 14 Jun 2012 18:15:44 -0700 (PDT) Received: from mail29-am1-R.bigfish.com (10.3.201.231) by AM1EHSOBE003.bigfish.com (10.3.204.23) with Microsoft SMTP Server id 14.1.225.23; Fri, 15 Jun 2012 01:14:34 +0000 Received: from mail29-am1 (localhost [127.0.0.1]) by mail29-am1-R.bigfish.com (Postfix) with ESMTP id A84502A039F; Fri, 15 Jun 2012 01:14:34 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -28 X-BigFish: VS-28(zz9371Ic85fh148cI542M1432Izz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25hf0ah) Received-SPF: pass (mail29-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail29-am1 (localhost.localdomain [127.0.0.1]) by mail29-am1 (MessageSwitch) id 1339722871931381_11689; Fri, 15 Jun 2012 01:14:31 +0000 (UTC) Received: from AM1EHSMHS017.bigfish.com (unknown [10.3.201.251]) by mail29-am1.bigfish.com (Postfix) with ESMTP id DFD0C32004F; Fri, 15 Jun 2012 01:14:31 +0000 (UTC) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS017.bigfish.com (10.3.207.155) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 15 Jun 2012 01:14:30 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.189]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.02.0298.005; Fri, 15 Jun 2012 01:15:14 +0000 From: Mike Jones To: Eran Hammer , "oauth@ietf.org WG (oauth@ietf.org)" Thread-Topic: [OAUTH-WG] Section 7.2 Thread-Index: AQHNSnlK4rMFHIKNpEG6QNgV8mtEhJb6Y6gAgAABoQCAACqMcA== Date: Fri, 15 Jun 2012 01:15:13 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366539839@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <0CBAEB56DDB3A140BA8E8C124C04ECA201073394@P3PWEX2MB008.ex2.secureserver.net> <4E1F6AAD24975D4BA5B1680429673943665394D7@TK5EX14MBXC284.redmond.corp.microsoft.com> <0CBAEB56DDB3A140BA8E8C124C04ECA2010734C5@P3PWEX2MB008.ex2.secureserver.net> <0CBAEB56DDB3A140BA8E8C124C04ECA201073573@P3PWEX2MB008.ex2.secureserver.net> In-Reply-To: <0CBAEB56DDB3A140BA8E8C124C04ECA201073573@P3PWEX2MB008.ex2.secureserver.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.34] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394366539839TK5EX14MBXC284r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [OAUTH-WG] Section 7.2 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 01:15:45 -0000 --_000_4E1F6AAD24975D4BA5B168042967394366539839TK5EX14MBXC284r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for writing the text below. It looks fine to me. About adding the = other error parameters as suggestions, that seems like a reasonable thing t= o do. How about the text at the end below, which adds mentions of error_de= scription and error_uri? 7.2. Error Response If a resource access request fails, the resource server SHOULD inform the client of the error. While the specifics of such error responses are beyond the scope of this specification, this documents establishes a common registry for error values to be shared among OAuth token authentication schemes. New authentication schemes designed primarily for OAuth token authentication SHOULD define a mechanism for providing an error status code to the client, in which the error values allowed are registered in the error registry established by this specification. Such schemes MAY limit the set of valid error codes to a subset of the registered values. If the error code is returned using a named parameter= , the parameter name SHOULD be "error". Other schemes capable of being used for OAuth token authentication, but not primarily designed for that purpose, MAY bind their error values to = the registry in the same manner. New authentication schemes MAY choose to also specify the use of the "error_description" and "error_uri" parameters to return error informati= on in a manner parallel to their usage in this specification. -- Mike P.S. If you already have the text you wrote in a copy of the draft, you sh= ould apply these spelling corrections: desgined -> designed authentiction -> authentication -----Original Message----- From: Eran Hammer [mailto:eran@hueniverse.com] Sent: Thursday, June 14, 2012 3:29 PM To: Eran Hammer; Mike Jones; oauth@ietf.org WG (oauth@ietf.org) Subject: RE: [OAUTH-WG] Section 7.2 Mike - if you want to add the other error parameters as suggestions, that w= ould be fine by me. EH > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth= -bounces@ietf.org] On Behalf > Of Eran Hammer > Sent: Thursday, June 14, 2012 3:23 PM > To: Mike Jones; oauth@ietf.org WG (oauth@ietf.org<= mailto:oauth@ietf.org>) > Subject: Re: [OAUTH-WG] Section 7.2 > > 7.2. Error Response > > If a resource access request fails, the resource server SHOULD inform > the client of the error. While the specifics of such error responses > are beyond the scope of this specification, this documents establishes > a common registry for error values to be shared among OAuth token > authentication schemes. > > New authentication schemes desgined primarily for OAuth token > authentiction SHOULD define a mechanism for providing an > error status code to the client, in which the error values allowed are > registered in the error registry established by this specification. Su= ch > schemes MAY limit the set of valid error codes to a subset of the > registered values. If the error code is returned using a named paramet= er, > the parameter name SHOULD be "error". > > Other schemes capable of being used for OAuth token authentication, bu= t > not primarily designed for that purpose, MAY bind their error values t= o the > registry in the same manner. > > EH > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --_000_4E1F6AAD24975D4BA5B168042967394366539839TK5EX14MBXC284r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks for writing the text below.  It looks= fine to me.  About adding the other error parameters as suggestions, = that seems like a reasonable thing to do.  How about the text at the e= nd below, which adds mentions of error_description and error_uri?

 

7.2.  Error Response

 

   If a resource access request fails, the resource server SHO= ULD inform

   the client of the error.  While the specifics of such = error responses

   are beyond the scope of this specification, this documents = establishes

   a common registry for error values to be shared among OAuth= token

   authentication schemes.

 

   New authentication schemes designed primarily for OAuth tok= en

   authentication SHOULD define a mechanism for providing an

   error status code to the client, in which the error values = allowed are

   registered in the error registry established by this specif= ication. Such

   schemes MAY limit the set of valid error codes to a subset = of the

   registered values. If the error code is returned using a na= med parameter,

   the parameter name SHOULD be "error".<= /span>

 

   Other schemes capable of being used for OAuth token authent= ication, but

   not primarily designed for that purpose, MAY bind their err= or values to the

   registry in the same manner.

 

   New authentication schemes MAY choose to also specify the u= se of the

   "error_description" and "error_uri" par= ameters to return error information

   in a manner parallel to their usage in this specification.<= o:p>

 

 

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

 

P.S.  If you already have the text you wrote= in a copy of the draft, you should apply these spelling corrections:<= /o:p>

        &= nbsp;      desgined -> designed

        &= nbsp;      authentiction -> authentication=

 

-----Original Message-----
From: Eran Hammer [mailto:eran@hueniverse.com]
Sent: Thursday, June 14, 2012 3:29 PM
To: Eran Hammer; Mike Jones; oauth@ietf.org WG (oauth@ietf.org)
Subject: RE: [OAUTH-WG] Section 7.2

 

Mike - if you want to add the other error paramet= ers as suggestions, that would be fine by me.

 

EH

 

> -----Original Message-----

> From: oauth-bounces@iet= f.org [mailto:oauth-bounces@ietf.org] On= Behalf

> Of Eran Hammer

> Sent: Thursday, June 14, 2012 3:23 PM

> To: Mike Jones; oauth@ietf.org<= /span> WG (oauth@ietf.org)

> Subject: Re: [OAUTH-WG] Section 7.2

>

> 7.2.  Error Response

>

>    If a resource access reque= st fails, the resource server SHOULD inform

>    the client of the error.&n= bsp; While the specifics of such error responses

>    are beyond the scope of th= is specification, this documents establishes

>    a common registry for erro= r values to be shared among OAuth token

>    authentication schemes.

>

>    New authentication schemes= desgined primarily for OAuth token

>    authentiction SHOULD defin= e a mechanism for providing an

>    error status code to the c= lient, in which the error values allowed are

>    registered in the error re= gistry established by this specification. Such

>    schemes MAY limit the set = of valid error codes to a subset of the

>    registered values. If the = error code is returned using a named parameter,

>    the parameter name SHOULD = be "error".

>

>    Other schemes capable of b= eing used for OAuth token authentication, but

>    not primarily designed for= that purpose, MAY bind their error values to the

>    registry in the same manne= r.

>

> EH

>

> ____________________________________________= ___

> OAuth mailing list

> OAuth@ietf.org<= /o:p>

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

 

--_000_4E1F6AAD24975D4BA5B168042967394366539839TK5EX14MBXC284r_-- From torsten@lodderstedt.net Thu Jun 14 22:48:38 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5DA921F860E for ; Thu, 14 Jun 2012 22:48:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.607 X-Spam-Level: X-Spam-Status: No, score=-1.607 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, SARE_SUB_ENC_UTF8x3=0.641] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QAkEH5nC6xnH for ; Thu, 14 Jun 2012 22:48:36 -0700 (PDT) Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.98]) by ietfa.amsl.com (Postfix) with ESMTP id 5012F21F8611 for ; Thu, 14 Jun 2012 22:48:34 -0700 (PDT) Received: from [79.253.61.120] (helo=android-15e9366c46879293.fritz.box) by smtprelay05.ispgateway.de with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.68) (envelope-from ) id 1SfPOY-0004Il-87; Fri, 15 Jun 2012 07:48:30 +0200 References: User-Agent: K-9 Mail for Android In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----ILP66UFGRL3BAGLDXGX3HMI1236BBI" From: Torsten Lodderstedt Date: Fri, 15 Jun 2012 07:48:23 +0200 To: Eran Hammer ,William Mills Message-ID: X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Cc: "oauth@ietf.org WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] =?utf-8?q?Dynamic_clients=2C_URI=2C_and_stuff_Re=3A_Di?= =?utf-8?q?scussion_needed_on_username_and_password_ABNF=09definiti?= =?utf-8?q?ons?= X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 05:48:38 -0000 ------ILP66UFGRL3BAGLDXGX3HMI1236BBI Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit I don't like the idea of a special encoding for client ids. Let's keep it simple even if this means to exclude uris. regards, Torsten. Eran Hammer schrieb: The server must support Basic so if this is not resolved, using a colon will break some implementations. Note that there is an easy way of validating Basic credentials even when the client id includes a colon by not parsing the string on the server and instead building the same string as the client. There is of course a theoretical security issue where a username with colon can match the pair of a username without with colon in the password but that's very unlikely and not really an attack vector if client ids are issued properly. Either way, If colon is the only issue here, we should either specify encoding for Basic or exclude it and leave it up to others to define encoding of URIs as client ids. A few months ago I would have been more eager to revisit this, but at this point, we made our bed with Basic and are pretty much stuck without colon in the client id. EH From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of William Mills Sent: Thursday, June 14, 2012 2:20 PM To: Mike Jones; John Bradley; Torsten Lodderstedt Cc: Julian Reschke; Richard Mortier; oauth@ietf.org Subject: Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion needed on username and password ABNF definitions Will BASIC auth be needed for clients with an ID in the form of a URI? _____________________________________________ From: Mike Jones To: John Bradley ; Torsten Lodderstedt Cc: Julian Reschke ; Richard Mortier ; "oauth@ietf.org" Sent: Thursday, June 14, 2012 2:14 PM Subject: Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion needed on username and password ABNF definitions The more I think about excluding the possibility of using URIs as client IDs, the more uncomfortable I am with it. I’m increasingly thinking that we should allow the ASCII characters used in URIs (and probably the other visible ones and space as well, as currently proposed) and have special language about “But what if this client_id containing colon characters is to be used with HTTP Basic?†As one suggestion, mainly to restart discussion (which seems to have stalled), we could suggest (or require) that all colon characters in client_ids be substituted with tab characters (%x09), which are legal in HTTP Basic but not in the proposed definition of client_ids, before use with HTTP Basic, and that the reverse substitution occur when received from HTTP Basic. Other transformations or encodings are possible. We could also cop out by saying something like “If characters not legal in HTTP Basic occur in the client_id, a transformation encoding them must be agreed to by both partiesâ€. I don’t love the tab idea, because it’s admittedly a hack, but I believe it’s better than precluding the use of URIs as client_ids. Thoughts? -- Mike From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley Sent: Wednesday, June 13, 2012 11:40 AM To: Torsten Lodderstedt Cc: Julian Reschke; Richard Mortier; oauth@ietf.org Subject: Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion needed on username and password ABNF definitions That would probably work as well. That is why I am not particularly concerned about excluding the : We originally used the URI itself, mostly for convenience of debugging, but there are other potential options. The authorization server needs to compare the client_id and the redirect uri. But it could compare the hash with not much more work. Also a sha256 hash is probably longer than the uri it is hashing. I am not super concerned with being able to have : in the client_id John B. Sent from my iPhone On 2012-06-13, at 6:03 PM, Torsten Lodderstedt wrote: Hi John, would it make sense to use a hash of the URI instead of the URI itself in your use case? regards, Torsten. John Bradley schrieb: I think that the issues are getting confused. There is a use case where the Authorization server may be a embedded app, at least in one openID case. As it won't have a separate registration or token endpoint, the client needs to make its own clientID for the request. A reasonable thing to use is the redirect URI to create a unique value that the user could use for revocation at a later point. Currently with the no : restriction we would use the host and path to crate the clientid. There are some scenarios where having the scheme as part of that would be helpful. This has nothing to do with discovery or the dynamic client registration proposal as far as I know. A URL as a client_id comes from prototype work for a personal provider that we are doing as part of openID Connect. John B. On 2012-06-13, at 7:50 AM, Torsten Lodderstedt wrote: Hi all, can anyone please explain the relation between dynamic client registration and URIs as client ids? None of the current drafts (uma or connect) seem to require URIs. regards, Torsten. Jianhua Shao schrieb: Hello, Dynamic client registration is very useful if client or resource or authorisation server is not permanently available. A typical case is that is the resource or authorisation server is in mobile platform, the connection is not always available. Another typical case is that authorisation server do not necessary to have client pre-registered on itself. At moment, industry like facebook would like developer to register a app on its app centre first, and then ask user auth to use the app. We are researchers from Digital Economy Research Institute. We have this problem When we developing Dataware that could manage the control of access to personal data. We play around our solution base on Oauth2: https://github.com/jianhuashao/dataware.catalog/wiki We are in the list to receive your mail list, but currently need moderate to post any message. cc my colleague, Richard Mortier Best Jian On 12 Jun 2012, at 21:08, Eran Hammer wrote: The only distinction I would make is between removing flexibiliy to proactively enabling future extensibility. I would stop short of perscribing encoding in order to fit uri into the Basic auth fields. But if there is a way to allow this to be less restrictive without clean interop issues, that would be nice. I do agree we need some actual use cases before we spend much more time on this. EH From: William Mills [mailto:wmills@yahoo-inc.com] Sent: Tuesday, June 12, 2012 1:04 PM To: Eran Hammer; Mike Jones; Hannes Tschofenig; Julian Reschke Cc: oauth@ietf.org Subject: Dynamic clients, URI, and stuff Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions I think dynamic client registration is something we have not talked out enough yet. There's a pretty clear use case for dynamic registration. Does identifying the client with a URI allow some form of OpenID-ish flow for this? Is the client ID as a URI a way to allow a trusted site to provide metadata about the client? Is that URI a way to hit an IDP we trust to validate the client in some way with the provided secret? I guess what I'm looking for here is a concrete use case/problem to solve, rather then leaving a hook we think is the right thing. -bill _____________________________________________ From: Eran Hammer To: Mike Jones ; William Mills ; Hannes Tschofenig ; Julian Reschke Cc: "oauth@ietf.org" Sent: Tuesday, June 12, 2012 11:39 AM Subject: RE: [OAUTH-WG] Discussion needed on username and password ABNF definitions Is the use case of using URI as client ids important? It seems like something that might become useful in the future where clients can use their verifiable servers to bypass client registration and simly use a URI the server can validate via some other means. I just want to make sure those thinking about more complex use cases involving dynamic registration or distri buted client manamgenet are aware of this potential restriction. I'm fine either way. EH From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones Sent: Tuesday, June 12, 2012 11:27 AM To: William Mills; Hannes Tschofenig; Julian Reschke Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions Not internationalizing fields intended for machine consumption only is already a precedent set and agreed to by the working group, so let me second Bill’s point in that regard. For instance, neither “scope†nor “error†allow non-ASCII characters. Julian, if you want different ABNF text than the text I wrote below, I believe it would be most useful if you would provide the exact replace wording that you’d like to see instead of it. Then there’s no possibility of misunderstanding the intent of suggested changes. Thanks all, -- Mike From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of William Mills Sent: Tuesday, June 12, 2012 11:18 AM To: Hannes Tschofenig; Julian Reschke Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions I agree generally with your assumption about clients, but rather than saying "clients are devices" I think it makes much more sense to say "clients are NOT users, so client_id need not be internationalized". In practical terms there is very little to argue for anythign beyond ASCII in a client_secret, base64 encoding or the equivalent being a fine way to transport arbitrary bits in a portable/reasonable way. I argue that client_id need not be internationalized because I assume that any really internationalized application will have an internationalized presentation layer that's presenting a pretty name for the client_id. -bill _____________________________________________ From: Hannes Tschofenig To: Julian Reschke Cc: "oauth@ietf.org" Sent: Tuesday, June 12, 2012 11:01 AM Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions I had a chat with Julian yesterday and here is my short summary. Section 2.3 of the core draft defines client authentication based on two mechanisms (and provides room for extensions):http://tools.ietf.org/html/draft-ietf-oauth-v2-27#section-2.3 1) HTTP Basic Authentication 2) A custom OAuth authentication mechanism (which uses client_id and client_secret) With HTTP Basic authentication the problem is that this is a legacy technology and there is no internationalization support. With our brand new custom OAuth authentication mechanism we have more options. One possible approach is to say that the clients are devices (and not end users) and therefore internationalization does not matter. Is it, however, really true that only US-ASCII characters will appear in the client_id and also in the client_secret? Here we have the possibility to define something better. In any case we have to restrict the characters that are used in these two authentication mechanisms since they could conflict with the way how we transport the data over the underlying protocol. Julian mentioned this in his previous mails. Julian, maybe you can provide a detailed text proposal for how to address your comment in case we go for UTF8 (with % encoding) for the custom OAuth client authentication mechanism? Ciao Hannes On Jun 12, 2012, at 11:54 AM, Julian Reschke wrote: > On 2012-06-12 00:16, Mike Jones wrote: >> Reviewing the feedback from Julian, John, and James, I'm coming to the conclusion that client_id and client_secret, being for machines and not humans, shou ld be ASCII, whereas username and password should be Unicode, since they are for humans. Per John's feedback, client_id can not contain a colon and be compatible with HTTP Basic. > > I'm not sure that restricting the character repertoire just because one way to send requires this is the right approach. My preference would be not to put this into the ABNF, and just to point out that certain characters will not work over certain transports, and to just advise to avoid them. > >> Therefore, I'd like to propose these updated ABNF definitions: >> >> VSCHAR = %20-7E >> NOCOLONVSCHAR = %x20-39 / %x3B-7E >> UNICODENOCTRLCHAR = >> >> client-id = *NOCOLONVSCHAR >> client_secret = *VSCHAR >> >> username = *UNICODENOCTRLCHAR >> password = *UNICODENOCTRLCHAR > > In this case you should add an introductory statement pointing out that the ABNF defines the grammar in terms of Unicode code points, not octets (as it is the case most of the time). > >> It turns out that non-ASCII characters are OK for username and password because the Core spec only passes them in the form body - not using HTTP Basic - and UTF-8 encoding is specified. > > I'll send a separate mail about that, the current text in the spec is way too unspecific. > >> -- Mike >> >> P.S. If anyone has a better ABNF for UNICODENOCTRLCHAR than "", please send it to me! > > As noted before, here's an example: > > Best regards, Julian > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ------ILP66UFGRL3BAGLDXGX3HMI1236BBI Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit I don't like the idea of a special encoding for client ids. Let's keep it simple even if this means to exclude uris.

regards,
Torsten.



Eran Hammer <eran@hueniverse.com> schrieb:

The server must support Basic so if this is not resolved, using a colon will break some implementations. Note that there is an easy way of validating Basic credentials even when the client id includes a colon by not parsing the string on the server and instead building the same string as the client. There is of course a theoretical security issue where a username with colon can match the pair of a username without with colon in the password but that's very unlikely and not really an attack vector if client ids are issued properly.

 

Either way, If colon is the only issue here, we should either specify encoding for Basic or exclude it and leave it up to others to define encoding of URIs as client ids. A few months ago I would have been more eager to revisit this, but at this point, we made our bed with Basic and are pretty much stuck without colon in the client id.

 

EH

 

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of William Mills
Sent: Thursday, June 14, 2012 2:20 PM
To: Mike Jones; John Bradley; Torsten Lodderstedt
Cc: Julian Reschke; Richard Mortier; oauth@ietf.org
Subject: Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion needed on username and password ABNF definitions

 

Will BASIC auth be needed for clients with an ID in the form of a URI?

 

 

From: Mike Jones <Michael.Jones@microsoft.com>
To: John Bradley <ve7jtb@ve7jtb.com>; Torsten Lodderstedt <torsten@lodderstedt.net>
Cc: Julian Reschke <julian.reschke@gmx.de>; Richard Mortier <richard.mortier@nottingham.ac.uk>; "oauth@ietf.org" <oauth@ietf.org>
Sent: Thursday, June 14, 2012 2:14 PM
Subject: Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion needed on username and password ABNF definitions

 

The more I think about excluding the possibility of using URIs as client IDs, the more uncomfortable I am with it.  I’m increasingly thinking that we should allow the ASCII characters used in URIs (and probably the other visible ones and space as well, as currently proposed) and have special language about “But what if this client_id containing colon characters is to be used with HTTP Basic?â€

 

As one suggestion, mainly to restart discussion (which seems to have stalled), we could suggest (or require) that all colon characters in client_ids be substituted with tab characters (%x09), which are legal in HTTP Basic but not in the proposed definition of client_ids, before use with HTTP Basic, and that the reverse substitution occur when received from HTTP Basic.  Other transformations or encodings are possible.  We could also cop out by saying something like “If characters not legal in HTTP Basic occur in the client_id, a transformation encoding them must be agreed to by both partiesâ€.  I don’t love the tab idea, because it’s admittedly a hack, but I believe it’s better than precluding the use of URIs as client_ids.

 

Thoughts?

 

                                                            -- Mike

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley
Sent: Wednesday, June 13, 2012 11:40 AM
To: Torsten Lodderstedt
Cc: Julian Reschke; Richard Mortier; oauth@ietf.org
Subject: Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion needed on username and password ABNF definitions

 

That would probably work as well.  That is why I am not particularly concerned about excluding the : 

 

We originally used the URI itself,  mostly for convenience of debugging,  but there are other potential options. 

 

The authorization server needs to compare the client_id and the redirect uri. But it could compare the hash with not much more work.   Also a sha256 hash is probably longer than the uri it is hashing.  

 

I am not super concerned with being able to have : in the client_id

 

John B. 

Sent from my iPhone


On 2012-06-13, at 6:03 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

Hi John,

would it make sense to use a hash of the URI instead of the URI itself in your use case?

regards,
Torsten.



John Bradley <ve7jtb@ve7jtb.com> schrieb:

I think that the issues are getting confused.

 

There is a use case where the Authorization server may be a embedded app, at least in one openID case.    As it won't have a separate registration or token endpoint,  the client needs to make its own clientID for the request.   A reasonable thing to use is the redirect URI to create a unique value that the user could use for revocation at a later point.

 

Currently with the no : restriction we would use the host and path to crate the clientid.

There are some scenarios where having the scheme as part of that would be helpful.

 

This has nothing to do with discovery or the dynamic client registration proposal as far as I know.

 

A URL as a client_id comes from prototype work for a personal provider that we are doing as part of openID Connect.

 

John B.

On 2012-06-13, at 7:50 AM, Torsten Lodderstedt wrote:

 

Hi all,

can anyone please explain the relation between dynamic client registration and URIs as client ids? None of the current drafts (uma or connect) seem to require URIs.

regards,
Torsten.



Jianhua Shao <psxjs4@nottingham.ac.uk> schrieb:

Hello,

 

Dynamic client registration is very useful if client or resource or authorisation server is not permanently available. 

A typical case is that is the resource or authorisation server is in mobile platform, the connection is not always available. 

Another typical case is that authorisation server do not necessary to have client pre-registered on itself. At moment, industry like facebook would like developer to register a app on its app centre first, and then ask user auth to use the app. 

 

We are researchers from Digital Economy Research Institute. We have this problem When we developing Dataware that could manage the control of access to personal data. We play around our solution base on Oauth2: https://github.com/jianhuashao/dataware.catalog/wiki

 

We are in the list to receive your mail list, but currently need moderate to post any message. cc my colleague, Richard Mortier

Best

Jian

 

 

On 12 Jun 2012, at 21:08, Eran Hammer wrote:

 

The only distinction I would make is between removing flexibiliy to proactively enabling future extensibility. I would stop short of perscribing encoding in order to fit uri into the Basic auth fields. But if there is a way to allow this to be less restrictive without clean interop issues, that would be nice.

 

I do agree we need some actual use cases before we spend much more time on this.

 

EH

 

From: William Mills [mailto:wmills@yahoo-inc.com] 
Sent: Tuesday, June 12, 2012 1:04 PM
To: Eran Hammer; Mike Jones; Hannes Tschofenig; Julian Reschke
Cc: oauth@ietf.org
Subject: Dynamic clients, URI, and stuff Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions

 

I think dynamic client registration is something we have not talked out enough yet.  There's a pretty clear use case for dynamic registration.  

 

Does identifying the client with a URI allow some form of OpenID-ish flow for this? 

Is the client ID as a URI a way to allow a trusted site to provide metadata about the client?

Is that URI a way to hit an IDP we trust to validate the client in some way with the provided secret?

 

I guess what I'm looking for here is a concrete use case/problem to solve, rather then leaving a hook we think is the right thing.

 

-bill

 

 

From: Eran Hammer <eran@hueniverse.com>
To: Mike Jones <Michael.Jones@microsoft.com>; William Mills <wmills@yahoo-inc.com>; Hannes Tschofenig <hannes.tschofenig@gmx.net>; Julian Reschke <julian.reschke@gmx.de> 
Cc: "oauth@ietf.org" <oauth@ietf.org> 
Sent: Tuesday, June 12, 2012 11:39 AM
Subject: RE: [OAUTH-WG] Discussion needed on username and password ABNF definitions

 

Is the use case of using URI as client ids important? It seems like something that might become useful in the future where clients can use their verifiable servers to bypass client registration and simly use a URI the server can validate via some other means.

 

I just want to make sure those thinking about more complex use cases involving dynamic registration or distri buted client manamgenet are aware of this potential restriction.

 

I'm fine either way.

 

EH

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Tuesday, June 12, 2012 11:27 AM
To: William Mills; Hannes Tschofenig; Julian Reschke
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions

 

Not internationalizing fields intended for machine consumption only is already a precedent set and agreed to by the working group, so let me second Bill’s point in that regard.  For instance, neither “scope†nor “error†allow non-ASCII characters.

 

Julian, if you want different ABNF text than the text I wrote below, I believe it would be most useful if you would provide the exact replace wording that you’d like to see instead of it.  Then there’s no possibility of misunderstanding the intent of suggested changes.

 

                                                            Thanks all,

                                                            -- Mike

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of William Mills
Sent: Tuesday, June 12, 2012 11:18 AM
To: Hannes Tschofenig; Julian Reschke
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions

 

I agree generally with your assumption about clients, but rather than saying "clients are devices" I think it makes much more sense to say "clients are NOT users, so client_id need not be internationalized".  In practical terms there is very little to argue for anythign beyond ASCII in a client_secret, base64 encoding or the equivalent being a fine way to transport arbitrary bits in a portable/reasonable way.

 

I argue that client_id need not be internationalized because I assume that any really internationalized application will have an internationalized presentation layer that's presenting a pretty name for the client_id.

 

-bill

 

From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
To: Julian Reschke <julian.reschke@gmx.de> 
Cc: "oauth@ietf.org" <oauth@ietf.org> 
Sent: Tuesday, June 12, 2012 11:01 AM
Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions


I had a chat with Julian yesterday and here is my short summary. 

Section 2.3 of the core draft defines client authentication based on two mechanisms (and provides room for extensions):http://tools.ietf.org/html/draft-ietf-oauth-v2-27#section-2.3

1) HTTP Basic Authentication

2) A custom OAuth authentication mechanism (which uses client_id and client_secret)

With HTTP Basic authentication the problem is that this is a legacy technology and there is no internationalization support. 

With our brand new custom OAuth authentication mechanism we have more options. 

One possible approach is to say that the clients are devices (and not end users) and therefore internationalization does not matter. 

Is it, however, really true that only US-ASCII characters will appear in the client_id and also in the client_secret? 

Here we have the possibility to define something better. 

In any case we have to restrict the characters that are used in these two authentication mechanisms since they could conflict with the way how we transport the data over the underlying protocol. Julian mentioned this in his previous mails. 

Julian, maybe you can provide a detailed text proposal for how to address your comment in case we go for UTF8 (with % encoding) for the custom OAuth client authentication mechanism? 

Ciao
Hannes

On Jun 12, 2012, at 11:54 AM, Julian Reschke wrote:

> On 2012-06-12 00:16, Mike Jones wrote:
>> Reviewing the feedback from Julian, John, and James, I'm coming to the conclusion that client_id and client_secret, being for machines and not humans, shou ld be ASCII, whereas username and password should be Unicode, since they are for humans.  Per John's feedback, client_id can not contain a colon and be compatible with HTTP Basic.
> 
> I'm not sure that restricting the character repertoire just because one way to send requires this is the right approach. My preference would be not to put this into the ABNF, and just to point out that certain characters will not work over certain transports, and to just advise to avoid them.
> 
>> Therefore, I'd like to propose these updated ABNF definitions:
>> 
>>    VSCHAR = %20-7E
>>    NOCOLONVSCHAR = %x20-39 / %x3B-7E
>>    UNICODENOCTRLCHAR = <Any Unicode character other than ( %x0-1F / %x7F )>
>> 
>>    client-id = *NOCOLONVSCHAR
>>    client_secret = *VSCHAR
>> 
>>    username = *UNICODENOCTRLCHAR
>>    password = *UNICODENOCTRLCHAR
> 
> In this case you should add an introductory statement pointing out that the ABNF defines the grammar in terms of Unicode code points, not octets (as it is the case most of the time).
> 
>> It turns out that non-ASCII characters are OK for username and password because the Core spec only passes them in the form body - not using HTTP Basic - and UTF-8 encoding is specified.
> 
> I'll send a separate mail about that, the current text in the spec is way too unspecific.
> 
>>                 -- Mike
>> 
>> P.S.  If anyone has a better ABNF for UNICODENOCTRLCHAR than "<Any Unicode character other than ( %x0-1F / %x7F )>", please send it to me!
> 
> As noted before, here's an example: <http://greenbytes.de/tech/webdav/rfc5323.html#rfc.section.5.15.1>
> 
> Best regards, Julian
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

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

 

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

This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham.

This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.

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

 


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

------ILP66UFGRL3BAGLDXGX3HMI1236BBI-- From eran@hueniverse.com Thu Jun 14 23:32:29 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A22A621F86C8 for ; Thu, 14 Jun 2012 23:32:29 -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 kdJq1riprxB9 for ; Thu, 14 Jun 2012 23:32:28 -0700 (PDT) Received: from p3plex2out04.prod.phx3.secureserver.net (p3plex2out04.prod.phx3.secureserver.net [184.168.131.18]) by ietfa.amsl.com (Postfix) with ESMTP id 7202C21F8618 for ; Thu, 14 Jun 2012 23:32:28 -0700 (PDT) Received: from P3PWEX2HT001.ex2.secureserver.net ([184.168.131.9]) by p3plex2out04.prod.phx3.secureserver.net with bizsmtp id NWYS1j0020CJzpC01WYSRY; Thu, 14 Jun 2012 23:32:26 -0700 Received: from P3PWEX2MB008.ex2.secureserver.net ([169.254.8.66]) by P3PWEX2HT001.ex2.secureserver.net ([184.168.131.9]) with mapi id 14.02.0247.003; Thu, 14 Jun 2012 23:32:25 -0700 From: Eran Hammer To: Mike Jones , "oauth@ietf.org WG (oauth@ietf.org)" Thread-Topic: [OAUTH-WG] Section 7.2 Thread-Index: Ac1KeB4PVUuFMDsJRu+q5d/rw0G4WQAO9iAAAA6cN3AAHFVLIP/+3oCAgAAc8FA= Date: Fri, 15 Jun 2012 06:32:25 +0000 Message-ID: <0CBAEB56DDB3A140BA8E8C124C04ECA201073B82@P3PWEX2MB008.ex2.secureserver.net> References: <0CBAEB56DDB3A140BA8E8C124C04ECA201073394@P3PWEX2MB008.ex2.secureserver.net> <4E1F6AAD24975D4BA5B1680429673943665394D7@TK5EX14MBXC284.redmond.corp.microsoft.com> <0CBAEB56DDB3A140BA8E8C124C04ECA2010734C5@P3PWEX2MB008.ex2.secureserver.net> <0CBAEB56DDB3A140BA8E8C124C04ECA201073573@P3PWEX2MB008.ex2.secureserver.net> <4E1F6AAD24975D4BA5B168042967394366539839@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366539839@TK5EX14MBXC284.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [37.46.43.35] Content-Type: multipart/alternative; boundary="_000_0CBAEB56DDB3A140BA8E8C124C04ECA201073B82P3PWEX2MB008ex2_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Section 7.2 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 06:32:29 -0000 --_000_0CBAEB56DDB3A140BA8E8C124C04ECA201073B82P3PWEX2MB008ex2_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable WFM. This will be the new text for 7.2 unless someone has any additional feedbac= k or concerns. This closes my issue with the new error registry changes. EH From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Thursday, June 14, 2012 6:15 PM To: Eran Hammer; oauth@ietf.org WG (oauth@ietf.org) Subject: RE: [OAUTH-WG] Section 7.2 Thanks for writing the text below. It looks fine to me. About adding the = other error parameters as suggestions, that seems like a reasonable thing t= o do. How about the text at the end below, which adds mentions of error_de= scription and error_uri? 7.2. Error Response If a resource access request fails, the resource server SHOULD inform the client of the error. While the specifics of such error responses are beyond the scope of this specification, this documents establishes a common registry for error values to be shared among OAuth token authentication schemes. New authentication schemes designed primarily for OAuth token authentication SHOULD define a mechanism for providing an error status code to the client, in which the error values allowed are registered in the error registry established by this specification. Such schemes MAY limit the set of valid error codes to a subset of the registered values. If the error code is returned using a named parameter= , the parameter name SHOULD be "error". Other schemes capable of being used for OAuth token authentication, but not primarily designed for that purpose, MAY bind their error values to = the registry in the same manner. New authentication schemes MAY choose to also specify the use of the "error_description" and "error_uri" parameters to return error informati= on in a manner parallel to their usage in this specification. -- Mike P.S. If you already have the text you wrote in a copy of the draft, you sh= ould apply these spelling corrections: desgined -> designed authentiction -> authentication -----Original Message----- From: Eran Hammer [mailto:eran@hueniverse.com] Sent: Thursday, June 14, 2012 3:29 PM To: Eran Hammer; Mike Jones; oauth@ietf.org WG (oaut= h@ietf.org) Subject: RE: [OAUTH-WG] Section 7.2 Mike - if you want to add the other error parameters as suggestions, that w= ould be fine by me. EH > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth= -bounces@ietf.org] On Behalf > Of Eran Hammer > Sent: Thursday, June 14, 2012 3:23 PM > To: Mike Jones; oauth@ietf.org WG (oauth@ietf.org<= mailto:oauth@ietf.org>) > Subject: Re: [OAUTH-WG] Section 7.2 > > 7.2. Error Response > > If a resource access request fails, the resource server SHOULD inform > the client of the error. While the specifics of such error responses > are beyond the scope of this specification, this documents establishes > a common registry for error values to be shared among OAuth token > authentication schemes. > > New authentication schemes desgined primarily for OAuth token > authentiction SHOULD define a mechanism for providing an > error status code to the client, in which the error values allowed are > registered in the error registry established by this specification. Su= ch > schemes MAY limit the set of valid error codes to a subset of the > registered values. If the error code is returned using a named paramet= er, > the parameter name SHOULD be "error". > > Other schemes capable of being used for OAuth token authentication, bu= t > not primarily designed for that purpose, MAY bind their error values t= o the > registry in the same manner. > > EH > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --_000_0CBAEB56DDB3A140BA8E8C124C04ECA201073B82P3PWEX2MB008ex2_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

WFM.=

 

This will be the new t= ext for 7.2 unless someone has any additional feedback or concerns.

 

This closes my issue w= ith the new error registry changes.

 

EH

 

From: Mike Jon= es [mailto:Michael.Jones@microsoft.com]
Sent: Thursday, June 14, 2012 6:15 PM
To: Eran Hammer; oauth@ietf.org WG (oauth@ietf.org)
Subject: RE: [OAUTH-WG] Section 7.2

 

Thanks for writing the text below.  It looks= fine to me.  About adding the other error parameters as suggestions, = that seems like a reasonable thing to do.  How about the text at the e= nd below, which adds mentions of error_description and error_uri?

 

7.2.  Error Response

 

   If a resource access request fails, the resource server SHO= ULD inform

   the client of the error.  While the specifics of such = error responses

   are beyond the scope of this specification, this documents = establishes

   a common registry for error values to be shared among OAuth= token

   authentication schemes.

 

   New authentication schemes designed primarily for OAuth tok= en

   authentication SHOULD define a mechanism for providing an

   error status code to the client, in which the error values = allowed are

   registered in the error registry established by this specif= ication. Such

   schemes MAY limit the set of valid error codes to a subset = of the

   registered values. If the error code is returned using a na= med parameter,

   the parameter name SHOULD be "error".<= /span>

 

   Other schemes capable of being used for OAuth token authent= ication, but

   not primarily designed for that purpose, MAY bind their err= or values to the

   registry in the same manner.

 

   New authentication schemes MAY choose to also specify the u= se of the

   "error_description" and "error_uri" par= ameters to return error information

   in a manner parallel to their usage in this specification.<= o:p>

 

 

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

 

P.S.  If you already have the text you wrote= in a copy of the draft, you should apply these spelling corrections:<= /o:p>

        &= nbsp;      desgined -> designed

        &= nbsp;      authentiction -> authentication=

 

-----Original Message-----
From: Eran Hammer [mailto:e= ran@hueniverse.com]
Sent: Thursday, June 14, 2012 3:29 PM
To: Eran Hammer; Mike Jones; oauth@ietf.o= rg WG (oauth@ietf.org)
Subject: RE: [OAUTH-WG] Section 7.2

 

Mike - if you want to add the other error paramet= ers as suggestions, that would be fine by me.

 

EH

 

> -----Original Message-----

> From: oauth-bounces@iet= f.org [mailto:oauth-bounces@ietf.org] On= Behalf

> Of Eran Hammer

> Sent: Thursday, June 14, 2012 3:23 PM

> To: Mike Jones; oauth@ietf.org<= /span> WG (oauth@ietf.org)

> Subject: Re: [OAUTH-WG] Section 7.2

>

> 7.2.  Error Response

>

>    If a resource access reque= st fails, the resource server SHOULD inform

>    the client of the error.&n= bsp; While the specifics of such error responses

>    are beyond the scope of th= is specification, this documents establishes

>    a common registry for erro= r values to be shared among OAuth token

>    authentication schemes.

>

>    New authentication schemes= desgined primarily for OAuth token

>    authentiction SHOULD defin= e a mechanism for providing an

>    error status code to the c= lient, in which the error values allowed are

>    registered in the error re= gistry established by this specification. Such

>    schemes MAY limit the set = of valid error codes to a subset of the

>    registered values. If the = error code is returned using a named parameter,

>    the parameter name SHOULD = be "error".

>

>    Other schemes capable of b= eing used for OAuth token authentication, but

>    not primarily designed for= that purpose, MAY bind their error values to the

>    registry in the same manne= r.

>

> EH

>

> ____________________________________________= ___

> OAuth mailing list

> OAuth@ietf.org<= /o:p>

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

 

--_000_0CBAEB56DDB3A140BA8E8C124C04ECA201073B82P3PWEX2MB008ex2_-- From jricher@mitre.org Fri Jun 15 06:53:42 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B814621F86C4 for ; Fri, 15 Jun 2012 06:53:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.998 X-Spam-Level: X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6, J_CHICKENPOX_27=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 3bRmupJKKTAN for ; Fri, 15 Jun 2012 06:53:36 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 7B85F21F869D for ; Fri, 15 Jun 2012 06:53:35 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id C343621B0B02; Fri, 15 Jun 2012 09:53:32 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id A72B621B0458; Fri, 15 Jun 2012 09:53:32 -0400 (EDT) Received: from [129.83.50.12] (129.83.31.51) by IMCCAS02.MITRE.ORG (129.83.29.79) with Microsoft SMTP Server (TLS) id 14.2.283.3; Fri, 15 Jun 2012 09:53:32 -0400 Message-ID: <4FDB3E4B.1040605@mitre.org> Date: Fri, 15 Jun 2012 09:53:15 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Eran Hammer References: <4E1F6AAD24975D4BA5B168042967394366539292@TK5EX14MBXC284.redmond.corp.microsoft.com> <1339708818.17727.YahooMailNeo@web31808.mail.mud.yahoo.com> <0CBAEB56DDB3A140BA8E8C124C04ECA2010731F9@P3PWEX2MB008.ex2.secureserver.net> In-Reply-To: <0CBAEB56DDB3A140BA8E8C124C04ECA2010731F9@P3PWEX2MB008.ex2.secureserver.net> Content-Type: multipart/alternative; boundary="------------040509020403080903020203" X-Originating-IP: [129.83.31.51] Cc: "oauth@ietf.org WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion needed on username and password ABNF definitions X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 13:53:42 -0000 --------------040509020403080903020203 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit I'm in favor of allowing all characters in the string and leaving a note that if someone wants to have a character in there that they can't use elsewhere, they need to use an encoding (percent encoding? mime encoding? we should just pick one that other people use) to get that extra character into Basic. -- Justin On 06/14/2012 05:27 PM, Eran Hammer wrote: > > The server must support Basic so if this is not resolved, using a > colon will break some implementations. Note that there is an easy way > of validating Basic credentials even when the client id includes a > colon by not parsing the string on the server and instead building the > same string as the client. There is of course a theoretical security > issue where a username with colon can match the pair of a username > without with colon in the password but that's very unlikely and not > really an attack vector if client ids are issued properly. > > Either way, If colon is the only issue here, we should either specify > encoding for Basic or exclude it and leave it up to others to define > encoding of URIs as client ids. A few months ago I would have been > more eager to revisit this, but at this point, we made our bed with > Basic and are pretty much stuck without colon in the client id. > > EH > > *From:*oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On > Behalf Of *William Mills > *Sent:* Thursday, June 14, 2012 2:20 PM > *To:* Mike Jones; John Bradley; Torsten Lodderstedt > *Cc:* Julian Reschke; Richard Mortier; oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: > Discussion needed on username and password ABNF definitions > > Will BASIC auth be needed for clients with an ID in the form of a URI? > > ------------------------------------------------------------------------ > > *From:*Mike Jones > > *To:* John Bradley >; > Torsten Lodderstedt > > *Cc:* Julian Reschke >; Richard Mortier > >; "oauth@ietf.org > " > > *Sent:* Thursday, June 14, 2012 2:14 PM > *Subject:* Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: > Discussion needed on username and password ABNF definitions > > The more I think about excluding the possibility of using URIs as > client IDs, the more uncomfortable I am with it. I'm increasingly > thinking that we should allow the ASCII characters used in URIs > (and probably the other visible ones and space as well, as > currently proposed) and have special language about "But what if > this client_id containing colon characters is to be used with HTTP > Basic?" > > As one suggestion, mainly to restart discussion (which seems to > have stalled), we could suggest (or require) that all colon > characters in client_ids be substituted with tab characters > (%x09), which are legal in HTTP Basic but not in the proposed > definition of client_ids, before use with HTTP Basic, and that the > reverse substitution occur when received from HTTP Basic. Other > transformations or encodings are possible. We could also cop out > by saying something like "If characters not legal in HTTP Basic > occur in the client_id, a transformation encoding them must be > agreed to by both parties". I don't love the tab idea, because > it's admittedly a hack, but I believe it's better than precluding > the use of URIs as client_ids. > > Thoughts? > > -- Mike > > *From:*oauth-bounces@ietf.org > [mailto:oauth-bounces@ietf.org] > *On Behalf Of *John Bradley > *Sent:* Wednesday, June 13, 2012 11:40 AM > *To:* Torsten Lodderstedt > *Cc:* Julian Reschke; Richard Mortier; oauth@ietf.org > > *Subject:* Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: > Discussion needed on username and password ABNF definitions > > That would probably work as well. That is why I am not > particularly concerned about excluding the : > > We originally used the URI itself, mostly for convenience of > debugging, but there are other potential options. > > The authorization server needs to compare the client_id and the > redirect uri. But it could compare the hash with not much more > work. Also a sha256 hash is probably longer than the uri it is > hashing. > > I am not super concerned with being able to have : in the client_id > > John B. > > Sent from my iPhone > > > On 2012-06-13, at 6:03 PM, Torsten Lodderstedt > > wrote: > > Hi John, > > would it make sense to use a hash of the URI instead of the > URI itself in your use case? > > regards, > Torsten. > > > > John Bradley > > schrieb: > > I think that the issues are getting confused. > > There is a use case where the Authorization server may be a > embedded app, at least in one openID case. As it won't have > a separate registration or token endpoint, the client needs > to make its own clientID for the request. A reasonable thing > to use is the redirect URI to create a unique value that the > user could use for revocation at a later point. > > Currently with the no : restriction we would use the host and > path to crate the clientid. > > There are some scenarios where having the scheme as part of > that would be helpful. > > This has nothing to do with discovery or the dynamic client > registration proposal as far as I know. > > A URL as a client_id comes from prototype work for a personal > provider that we are doing as part of openID Connect. > > John B. > > On 2012-06-13, at 7:50 AM, Torsten Lodderstedt wrote: > > Hi all, > > can anyone please explain the relation between dynamic client > registration and URIs as client ids? None of the current > drafts (uma or connect) seem to require URIs. > > regards, > Torsten. > > > > Jianhua Shao > schrieb: > > Hello, > > Dynamic client registration is very useful if client or > resource or authorisation server is not permanently available. > > A typical case is that is the resource or authorisation server > is in mobile platform, the connection is not always available. > > Another typical case is that authorisation server do not > necessary to have client pre-registered on itself. At moment, > industry like facebook would like developer to register a app > on its app centre first, and then ask user auth to use the app. > > We are researchers from Digital Economy Research Institute. We > have this problem When we developing Dataware that could > manage the control of access to personal data. We play around > our solution base on Oauth2: > https://github.com/jianhuashao/dataware.catalog/wiki > > We are in the list to receive your mail list, but currently > need moderate to post any message. cc my colleague, Richard > Mortier > > Best > > Jian > > On 12 Jun 2012, at 21:08, Eran Hammer wrote: > > The only distinction I would make is between removing > flexibiliy to proactively enabling future extensibility. I > would stop short of perscribing encoding in order to fit uri > into the Basic auth fields. But if there is a way to allow > this to be less restrictive without clean interop issues, that > would be nice. > > I do agree we need some actual use cases before we spend much > more time on this. > > EH > > *From:*William Mills [mailto:wmills@yahoo-inc.com] > > *Sent:*Tuesday, June 12, 2012 1:04 PM > *To:*Eran Hammer; Mike Jones; Hannes Tschofenig; Julian Reschke > *Cc:*oauth@ietf.org > *Subject:*Dynamic clients, URI, and stuff Re: [OAUTH-WG] > Discussion needed on username and password ABNF definitions > > I think dynamic client registration is something we have not > talked out enough yet. There's a pretty clear use case for > dynamic registration. > > Does identifying the client with a URI allow some form of > OpenID-ish flow for this? > > Is the client ID as a URI a way to allow a trusted site to > provide metadata about the client? > > Is that URI a way to hit an IDP we trust to validate the > client in some way with the provided secret? > > I guess what I'm looking for here is a concrete use > case/problem to solve, rather then leaving a hook we think is > the right thing. > > -bill > > ------------------------------------------------------------------------ > > *From:*Eran Hammer > > *To:*Mike Jones >; William Mills > >; > Hannes Tschofenig >; Julian Reschke > > > *Cc:*"oauth@ietf.org " > > > *Sent:*Tuesday, June 12, 2012 11:39 AM > *Subject:*RE: [OAUTH-WG] Discussion needed on username and > password ABNF definitions > > Is the use case of using URI as client ids important? It > seems like something that might become useful in the > future where clients can use their verifiable servers to > bypass client registration and simly use a URI the server > can validate via some other means. > > I just want to make sure those thinking about more complex > use cases involving dynamic registration or distri buted > client manamgenet are aware of this potential restriction. > > I'm fine either way. > > EH > > *From:*oauth-bounces@ietf.org > [mailto:oauth-bounces@ietf.org] > *On Behalf Of*Mike > Jones > *Sent:*Tuesday, June 12, 2012 11:27 AM > *To:*William Mills; Hannes Tschofenig; Julian Reschke > *Cc:*oauth@ietf.org > *Subject:*Re: [OAUTH-WG] Discussion needed on username and > password ABNF definitions > > Not internationalizing fields intended for machine > consumption only is already a precedent set and agreed to > by the working group, so let me second Bill's point in > that regard. For instance, neither "scope" nor "error" > allow non-ASCII characters. > > Julian, if you want different ABNF text than the text I > wrote below, I believe it would be most useful if you > would provide the exact replace wording that you'd like to > see instead of it. Then there's no possibility of > misunderstanding the intent of suggested changes. > > Thanks > all, > > -- > Mike > > *From:*oauth-bounces@ietf.org > [mailto:oauth-bounces@ietf.org] > *On Behalf > Of*William Mills > *Sent:*Tuesday, June 12, 2012 11:18 AM > *To:*Hannes Tschofenig; Julian Reschke > *Cc:*oauth@ietf.org > *Subject:*Re: [OAUTH-WG] Discussion needed on username and > password ABNF definitions > > I agree generally with your assumption about clients, but > rather than saying "clients are devices" I think it makes > much more sense to say "clients are NOT users, so > client_id need not be internationalized". In practical > terms there is very little to argue for anythign beyond > ASCII in a client_secret, base64 encoding or the > equivalent being a fine way to transport arbitrary bits in > a portable/reasonable way. > > I argue that client_id need not be internationalized > because I assume that any really internationalized > application will have an internationalized presentation > layer that's presenting a pretty name for the client_id. > > -bill > > ------------------------------------------------------------------------ > > *From:*Hannes Tschofenig > > *To:*Julian Reschke > > *Cc:*"oauth@ietf.org " > > > *Sent:*Tuesday, June 12, 2012 11:01 AM > *Subject:*Re: [OAUTH-WG] Discussion needed on username and > password ABNF definitions > > > I had a chat with Julian yesterday and here is my short > summary. > > Section 2.3 of the core draft defines client > authentication based on two mechanisms (and provides room > for > extensions):http://tools.ietf.org/html/draft-ietf-oauth-v2-27#section-2.3 > > 1) HTTP Basic Authentication > > 2) A custom OAuth authentication mechanism (which uses > client_id and client_secret) > > With HTTP Basic authentication the problem is that this is > a legacy technology and there is no internationalization > support. > > With our brand new custom OAuth authentication mechanism > we have more options. > > One possible approach is to say that the clients are > devices (and not end users) and therefore > internationalization does not matter. > > Is it, however, really true that only US-ASCII characters > will appear in the client_id and also in the client_secret? > > Here we have the possibility to define something better. > > In any case we have to restrict the characters that are > used in these two authentication mechanisms since they > could conflict with the way how we transport the data over > the underlying protocol. Julian mentioned this in his > previous mails. > > Julian, maybe you can provide a detailed text proposal for > how to address your comment in case we go for UTF8 (with % > encoding) for the custom OAuth client authentication > mechanism? > > Ciao > Hannes > > On Jun 12, 2012, at 11:54 AM, Julian Reschke wrote: > > > On 2012-06-12 00:16, Mike Jones wrote: > >> Reviewing the feedback from Julian, John, and James, I'm > coming to the conclusion that client_id and client_secret, > being for machines and not humans, shou ld be ASCII, > whereas username and password should be Unicode, since > they are for humans. Per John's feedback, client_id can > not contain a colon and be compatible with HTTP Basic. > > > > I'm not sure that restricting the character repertoire > just because one way to send requires this is the right > approach. My preference would be not to put this into the > ABNF, and just to point out that certain characters will > not work over certain transports, and to just advise to > avoid them. > > > >> Therefore, I'd like to propose these updated ABNF > definitions: > >> > >> VSCHAR = %20-7E > >> NOCOLONVSCHAR = %x20-39 / %x3B-7E > >> UNICODENOCTRLCHAR = ( %x0-1F / %x7F )> > >> > >> client-id = *NOCOLONVSCHAR > >> client_secret = *VSCHAR > >> > >> username = *UNICODENOCTRLCHAR > >> password = *UNICODENOCTRLCHAR > > > > In this case you should add an introductory statement > pointing out that the ABNF defines the grammar in terms of > Unicode code points, not octets (as it is the case most of > the time). > > > >> It turns out that non-ASCII characters are OK for > username and password because the Core spec only passes > them in the form body - not using HTTP Basic - and UTF-8 > encoding is specified. > > > > I'll send a separate mail about that, the current text in > the spec is way too unspecific. > > > >> -- Mike > >> > >> P.S. If anyone has a better ABNF for UNICODENOCTRLCHAR > than " )>", please send it to me! > > > > As noted before, here's an example: > > > > > Best regards, Julian > > _______________________________________________ > > OAuth mailing list > >OAuth@ietf.org > >https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > This message and any attachment are intended solely for the > addressee and may contain confidential information. If you > have received this message in error, please send it back to > me, and immediately delete it. Please do not use, copy or > disclose the information contained in this message or in any > attachment. Any views or opinions expressed by the author of > this email do not necessarily reflect the views of the > University of Nottingham. > > This message has been checked for viruses but the contents of > an attachment may still contain software viruses which could > damage your computer system: you are advised to perform your > own checks. Email communications with the University of > Nottingham may be monitored as permitted by UK legislation. > > _______________________________________________ > OAuth mailing 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 --------------040509020403080903020203 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit I'm in favor of allowing all characters in the string and leaving a note that if someone wants to have a character in there that they can't use elsewhere, they need to use an encoding (percent encoding? mime encoding? we should just pick one that other people use) to get that extra character into Basic.

 -- Justin

On 06/14/2012 05:27 PM, Eran Hammer wrote:

The server must support Basic so if this is not resolved, using a colon will break some implementations. Note that there is an easy way of validating Basic credentials even when the client id includes a colon by not parsing the string on the server and instead building the same string as the client. There is of course a theoretical security issue where a username with colon can match the pair of a username without with colon in the password but that's very unlikely and not really an attack vector if client ids are issued properly.

 

Either way, If colon is the only issue here, we should either specify encoding for Basic or exclude it and leave it up to others to define encoding of URIs as client ids. A few months ago I would have been more eager to revisit this, but at this point, we made our bed with Basic and are pretty much stuck without colon in the client id.

 

EH

 

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of William Mills
Sent: Thursday, June 14, 2012 2:20 PM
To: Mike Jones; John Bradley; Torsten Lodderstedt
Cc: Julian Reschke; Richard Mortier; oauth@ietf.org
Subject: Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion needed on username and password ABNF definitions

 

Will BASIC auth be needed for clients with an ID in the form of a URI?

 

 

From: Mike Jones <Michael.Jones@microsoft.com>
To: John Bradley <ve7jtb@ve7jtb.com>; Torsten Lodderstedt <torsten@lodderstedt.net>
Cc: Julian Reschke <julian.reschke@gmx.de>; Richard Mortier <richard.mortier@nottingham.ac.uk>; "oauth@ietf.org" <oauth@ietf.org>
Sent: Thursday, June 14, 2012 2:14 PM
Subject: Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion needed on username and password ABNF definitions

 

The more I think about excluding the possibility of using URIs as client IDs, the more uncomfortable I am with it.  I’m increasingly thinking that we should allow the ASCII characters used in URIs (and probably the other visible ones and space as well, as currently proposed) and have special language about “But what if this client_id containing colon characters is to be used with HTTP Basic?”

 

As one suggestion, mainly to restart discussion (which seems to have stalled), we could suggest (or require) that all colon characters in client_ids be substituted with tab characters (%x09), which are legal in HTTP Basic but not in the proposed definition of client_ids, before use with HTTP Basic, and that the reverse substitution occur when received from HTTP Basic.  Other transformations or encodings are possible.  We could also cop out by saying something like “If characters not legal in HTTP Basic occur in the client_id, a transformation encoding them must be agreed to by both parties”.  I don’t love the tab idea, because it’s admittedly a hack, but I believe it’s better than precluding the use of URIs as client_ids.

 

Thoughts?

 

                                                            -- Mike

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley
Sent: Wednesday, June 13, 2012 11:40 AM
To: Torsten Lodderstedt
Cc: Julian Reschke; Richard Mortier; oauth@ietf.org
Subject: Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion needed on username and password ABNF definitions

 

That would probably work as well.  That is why I am not particularly concerned about excluding the : 

 

We originally used the URI itself,  mostly for convenience of debugging,  but there are other potential options. 

 

The authorization server needs to compare the client_id and the redirect uri. But it could compare the hash with not much more work.   Also a sha256 hash is probably longer than the uri it is hashing.  

 

I am not super concerned with being able to have : in the client_id

 

John B. 

Sent from my iPhone


On 2012-06-13, at 6:03 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

Hi John,

would it make sense to use a hash of the URI instead of the URI itself in your use case?

regards,
Torsten.



John Bradley <ve7jtb@ve7jtb.com> schrieb:

I think that the issues are getting confused.

 

There is a use case where the Authorization server may be a embedded app, at least in one openID case.    As it won't have a separate registration or token endpoint,  the client needs to make its own clientID for the request.   A reasonable thing to use is the redirect URI to create a unique value that the user could use for revocation at a later point.

 

Currently with the no : restriction we would use the host and path to crate the clientid.

There are some scenarios where having the scheme as part of that would be helpful.

 

This has nothing to do with discovery or the dynamic client registration proposal as far as I know.

 

A URL as a client_id comes from prototype work for a personal provider that we are doing as part of openID Connect.

 

John B.

On 2012-06-13, at 7:50 AM, Torsten Lodderstedt wrote:

 

Hi all,

can anyone please explain the relation between dynamic client registration and URIs as client ids? None of the current drafts (uma or connect) seem to require URIs.

regards,
Torsten.



Jianhua Shao <psxjs4@nottingham.ac.uk> schrieb:

Hello,

 

Dynamic client registration is very useful if client or resource or authorisation server is not permanently available. 

A typical case is that is the resource or authorisation server is in mobile platform, the connection is not always available. 

Another typical case is that authorisation server do not necessary to have client pre-registered on itself. At moment, industry like facebook would like developer to register a app on its app centre first, and then ask user auth to use the app. 

 

We are researchers from Digital Economy Research Institute. We have this problem When we developing Dataware that could manage the control of access to personal data. We play around our solution base on Oauth2: https://github.com/jianhuashao/dataware.catalog/wiki

 

We are in the list to receive your mail list, but currently need moderate to post any message. cc my colleague, Richard Mortier

Best

Jian

 

 

On 12 Jun 2012, at 21:08, Eran Hammer wrote:

 

The only distinction I would make is between removing flexibiliy to proactively enabling future extensibility. I would stop short of perscribing encoding in order to fit uri into the Basic auth fields. But if there is a way to allow this to be less restrictive without clean interop issues, that would be nice.

 

I do agree we need some actual use cases before we spend much more time on this.

 

EH

 

From: William Mills [mailto:wmills@yahoo-inc.com] 
Sent: Tuesday, June 12, 2012 1:04 PM
To: Eran Hammer; Mike Jones; Hannes Tschofenig; Julian Reschke
Cc: oauth@ietf.org
Subject: Dynamic clients, URI, and stuff Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions

 

I think dynamic client registration is something we have not talked out enough yet.  There's a pretty clear use case for dynamic registration.  

 

Does identifying the client with a URI allow some form of OpenID-ish flow for this? 

Is the client ID as a URI a way to allow a trusted site to provide metadata about the client?

Is that URI a way to hit an IDP we trust to validate the client in some way with the provided secret?

 

I guess what I'm looking for here is a concrete use case/problem to solve, rather then leaving a hook we think is the right thing.

 

-bill

 

 

From: Eran Hammer <eran@hueniverse.com>
To: Mike Jones <Michael.Jones@microsoft.com>; William Mills <wmills@yahoo-inc.com>; Hannes Tschofenig <hannes.tschofenig@gmx.net>; Julian Reschke <julian.reschke@gmx.de> 
Cc: "oauth@ietf.org" <oauth@ietf.org> 
Sent: Tuesday, June 12, 2012 11:39 AM
Subject: RE: [OAUTH-WG] Discussion needed on username and password ABNF definitions

 

Is the use case of using URI as client ids important? It seems like something that might become useful in the future where clients can use their verifiable servers to bypass client registration and simly use a URI the server can validate via some other means.

 

I just want to make sure those thinking about more complex use cases involving dynamic registration or distri buted client manamgenet are aware of this potential restriction.

 

I'm fine either way.

 

EH

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Tuesday, June 12, 2012 11:27 AM
To: William Mills; Hannes Tschofenig; Julian Reschke
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions

 

Not internationalizing fields intended for machine consumption only is already a precedent set and agreed to by the working group, so let me second Bill’s point in that regard.  For instance, neither “scope” nor “error” allow non-ASCII characters.

 

Julian, if you want different ABNF text than the text I wrote below, I believe it would be most useful if you would provide the exact replace wording that you’d like to see instead of it.  Then there’s no possibility of misunderstanding the intent of suggested changes.

 

                                                            Thanks all,

                                                            -- Mike

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of William Mills
Sent: Tuesday, June 12, 2012 11:18 AM
To: Hannes Tschofenig; Julian Reschke
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions

 

I agree generally with your assumption about clients, but rather than saying "clients are devices" I think it makes much more sense to say "clients are NOT users, so client_id need not be internationalized".  In practical terms there is very little to argue for anythign beyond ASCII in a client_secret, base64 encoding or the equivalent being a fine way to transport arbitrary bits in a portable/reasonable way.

 

I argue that client_id need not be internationalized because I assume that any really internationalized application will have an internationalized presentation layer that's presenting a pretty name for the client_id.

 

-bill

 

From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
To: Julian Reschke <julian.reschke@gmx.de> 
Cc: "oauth@ietf.org" <oauth@ietf.org> 
Sent: Tuesday, June 12, 2012 11:01 AM
Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions


I had a chat with Julian yesterday and here is my short summary. 

Section 2.3 of the core draft defines client authentication based on two mechanisms (and provides room for extensions):http://tools.ietf.org/html/draft-ietf-oauth-v2-27#section-2.3

1) HTTP Basic Authentication

2) A custom OAuth authentication mechanism (which uses client_id and client_secret)

With HTTP Basic authentication the problem is that this is a legacy technology and there is no internationalization support. 

With our brand new custom OAuth authentication mechanism we have more options. 

One possible approach is to say that the clients are devices (and not end users) and therefore internationalization does not matter. 

Is it, however, really true that only US-ASCII characters will appear in the client_id and also in the client_secret? 

Here we have the possibility to define something better. 

In any case we have to restrict the characters that are used in these two authentication mechanisms since they could conflict with the way how we transport the data over the underlying protocol. Julian mentioned this in his previous mails. 

Julian, maybe you can provide a detailed text proposal for how to address your comment in case we go for UTF8 (with % encoding) for the custom OAuth client authentication mechanism? 

Ciao
Hannes

On Jun 12, 2012, at 11:54 AM, Julian Reschke wrote:

> On 2012-06-12 00:16, Mike Jones wrote:
>> Reviewing the feedback from Julian, John, and James, I'm coming to the conclusion that client_id and client_secret, being for machines and not humans, shou ld be ASCII, whereas username and password should be Unicode, since they are for humans.  Per John's feedback, client_id can not contain a colon and be compatible with HTTP Basic.
> 
> I'm not sure that restricting the character repertoire just because one way to send requires this is the right approach. My preference would be not to put this into the ABNF, and just to point out that certain characters will not work over certain transports, and to just advise to avoid them.
> 
>> Therefore, I'd like to propose these updated ABNF definitions:
>> 
>>    VSCHAR = %20-7E
>>    NOCOLONVSCHAR = %x20-39 / %x3B-7E
>>    UNICODENOCTRLCHAR = <Any Unicode character other than ( %x0-1F / %x7F )>
>> 
>>    client-id = *NOCOLONVSCHAR
>>    client_secret = *VSCHAR
>> 
>>    username = *UNICODENOCTRLCHAR
>>    password = *UNICODENOCTRLCHAR
> 
> In this case you should add an introductory statement pointing out that the ABNF defines the grammar in terms of Unicode code points, not octets (as it is the case most of the time).
> 
>> It turns out that non-ASCII characters are OK for username and password because the Core spec only passes them in the form body - not using HTTP Basic - and UTF-8 encoding is specified.
> 
> I'll send a separate mail about that, the current text in the spec is way too unspecific.
> 
>>                 -- Mike
>> 
>> P.S.  If anyone has a better ABNF for UNICODENOCTRLCHAR than "<Any Unicode character other than ( %x0-1F / %x7F )>", please send it to me!
> 
> As noted before, here's an example: <http://greenbytes.de/tech/webdav/rfc5323.html#rfc.section.5.15.1>
> 
> Best regards, Julian
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

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

 

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

This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham.

This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.

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

--------------040509020403080903020203-- From gffletch@aol.com Fri Jun 15 08:48:37 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A25C021F8646 for ; Fri, 15 Jun 2012 08:48:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.669 X-Spam-Level: X-Spam-Status: No, score=-1.669 tagged_above=-999 required=5 tests=[AWL=0.929, 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 4Vrhb9i8Ou3A for ; Fri, 15 Jun 2012 08:48:37 -0700 (PDT) Received: from imr-db01.mx.aol.com (imr-db01.mx.aol.com [205.188.91.95]) by ietfa.amsl.com (Postfix) with ESMTP id E20B021F8628 for ; Fri, 15 Jun 2012 08:48:36 -0700 (PDT) Received: from mtaout-mb02.r1000.mx.aol.com (mtaout-mb02.r1000.mx.aol.com [172.29.41.66]) by imr-db01.mx.aol.com (8.14.1/8.14.1) with ESMTP id q5FFmBaK007740; Fri, 15 Jun 2012 11:48:11 -0400 Received: from palantir.office.aol.com (palantir.office.aol.com [10.181.186.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout-mb02.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 92ACCE0000B4; Fri, 15 Jun 2012 11:48:11 -0400 (EDT) Message-ID: <4FDB593B.4080508@aol.com> Date: Fri, 15 Jun 2012 11:48:11 -0400 From: George Fletcher Organization: AOL LLC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: oauth@ietf.org References: <9dbeab60-8fe4-4828-9c52-d7af95378f4c@email.android.com> <0ec59f35-4a66-4719-adf3-114dab0d1d48@email.android.com> <40240328-0247-4278-BB7B-BE89AE130076@ve7jtb.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040404010208080909040708" x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20110426; t=1339775291; bh=ZPUc35IuGPaAfJcmRWNUZ5Awx/Hp+qj3zNUNKzytbws=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=G1n6u5seVaQdshQ/w/y58IOzDNXzunjKlZQcaNCtXkfGpJ5XdmAZNxtvSpvfuBMTI To/LCvwej37qtna1dE2QzPdRf8kq6oddWGTa91nwCgg0L+M3+aCSaBVuAjHUJm3ey4 lgGDEcICr1CH4kDD5L7JH3427y4glF8OHySUne0w= X-AOL-SCOLL-SCORE: 0:2:462005280:93952408 X-AOL-SCOLL-URL_COUNT: 0 x-aol-sid: 3039ac1d29424fdb593b092b X-AOL-IP: 10.181.186.254 Subject: Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion needed on username and password ABNF definitions X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 15:48:37 -0000 This is a multi-part message in MIME format. --------------040404010208080909040708 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit +1 for a simple encoding and allowing ':' in the client_id On 6/13/12 6:53 PM, Amos Jeffries wrote: > On 14.06.2012 06:40, John Bradley wrote: >> That would probably work as well. That is why I am not particularly >> concerned about excluding the : >> >> We originally used the URI itself, mostly for convenience of >> debugging, but there are other potential options. >> >> The authorization server needs to compare the client_id and the >> redirect uri. But it could compare the hash with not much more work. >> Also a sha256 hash is probably longer than the uri it is hashing. >> >> I am not super concerned with being able to have : in the client_id >> >> John B. >> > > > If I'm following all these threads correctly the only explicit problem > with URI in client_id is HTTP username field being : terminated. > As such it does not have to be a hash per-se, just an encoding that > removes ":" and other reserved characters from the on-wire form *when > sent via HTTP*. > > AYJ > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --------------040404010208080909040708 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit +1 for a simple encoding and allowing ':' in the client_id

On 6/13/12 6:53 PM, Amos Jeffries wrote:
On 14.06.2012 06:40, John Bradley wrote:
That would probably work as well.  That is why I am not particularly
concerned about excluding the :

We originally used the URI itself,  mostly for convenience of
debugging,  but there are other potential options.

The authorization server needs to compare the client_id and the
redirect uri. But it could compare the hash with not much more work.
Also a sha256 hash is probably longer than the uri it is hashing.

I am not super concerned with being able to have : in the client_id

John B.



If I'm following all these threads correctly the only explicit problem with URI in client_id is HTTP username field being : terminated.
As such it does not have to be a hash per-se, just an encoding that removes ":" and other reserved characters from the on-wire form *when sent via HTTP*.

AYJ

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



--------------040404010208080909040708-- From Michael.Jones@microsoft.com Fri Jun 15 09:17:31 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6C6621F84B3 for ; Fri, 15 Jun 2012 09:17:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.723 X-Spam-Level: X-Spam-Status: No, score=-3.723 tagged_above=-999 required=5 tests=[AWL=-0.125, 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 oodGCA4ZnZBr for ; Fri, 15 Jun 2012 09:17:30 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe001.messaging.microsoft.com [213.199.154.204]) by ietfa.amsl.com (Postfix) with ESMTP id A6D8821F84A2 for ; Fri, 15 Jun 2012 09:17:29 -0700 (PDT) Received: from mail13-am1-R.bigfish.com (10.3.201.232) by AM1EHSOBE003.bigfish.com (10.3.204.23) with Microsoft SMTP Server id 14.1.225.23; Fri, 15 Jun 2012 16:16:18 +0000 Received: from mail13-am1 (localhost [127.0.0.1]) by mail13-am1-R.bigfish.com (Postfix) with ESMTP id F0ACB205C2; Fri, 15 Jun 2012 16:16:17 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC105.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -23 X-BigFish: VS-23(zzbb2dI98dI9371Ic85fhzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25hf0ah) Received-SPF: pass (mail13-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC105.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail13-am1 (localhost.localdomain [127.0.0.1]) by mail13-am1 (MessageSwitch) id 1339776975649707_23231; Fri, 15 Jun 2012 16:16:15 +0000 (UTC) Received: from AM1EHSMHS003.bigfish.com (unknown [10.3.201.248]) by mail13-am1.bigfish.com (Postfix) with ESMTP id 93249160047; Fri, 15 Jun 2012 16:16:15 +0000 (UTC) Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS003.bigfish.com (10.3.207.103) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 15 Jun 2012 16:16:15 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.53]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.02.0309.003; Fri, 15 Jun 2012 16:17:13 +0000 From: Mike Jones To: George Fletcher , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion needed on username and password ABNF definitions Thread-Index: AQHNSw5aQ+07XirTWkeEJ2jRd0gB45b7jZDw Date: Fri, 15 Jun 2012 16:17:13 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436654ABB1@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <9dbeab60-8fe4-4828-9c52-d7af95378f4c@email.android.com> <0ec59f35-4a66-4719-adf3-114dab0d1d48@email.android.com> <40240328-0247-4278-BB7B-BE89AE130076@ve7jtb.com> <4FDB593B.4080508@aol.com> In-Reply-To: <4FDB593B.4080508@aol.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_4E1F6AAD24975D4BA5B16804296739436654ABB1TK5EX14MBXC283r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion needed on username and password ABNF definitions X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 16:17:31 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436654ABB1TK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Based on use cases I'm seeing, believe it's important to allow the use of U= RIs as client_id values (which means allowing ":" in the client_id string).= I'm OK with us either specifying a specific encoding when using them in B= asic or simply saying that "When client_ids are used with HTTP Basic that c= ontain characters such as ":" not allowed in HTTP Basic usernames, then the= participants will need to agree upon a method of encoding the client_id fo= r use with HTTP Basic. -- Mike From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of G= eorge Fletcher Sent: Friday, June 15, 2012 8:48 AM To: oauth@ietf.org Subject: Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion need= ed on username and password ABNF definitions +1 for a simple encoding and allowing ':' in the client_id On 6/13/12 6:53 PM, Amos Jeffries wrote: On 14.06.2012 06:40, John Bradley wrote: That would probably work as well. That is why I am not particularly concerned about excluding the : We originally used the URI itself, mostly for convenience of debugging, but there are other potential options. The authorization server needs to compare the client_id and the redirect uri. But it could compare the hash with not much more work. Also a sha256 hash is probably longer than the uri it is hashing. I am not super concerned with being able to have : in the client_id John B. If I'm following all these threads correctly the only explicit problem with= URI in client_id is HTTP username field being : terminated. As such it does not have to be a hash per-se, just an encoding that removes= ":" and other reserved characters from the on-wire form *when sent via HTT= P*. AYJ _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_4E1F6AAD24975D4BA5B16804296739436654ABB1TK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Based on use cases I̵= 7;m seeing, believe it’s important to allow the use of URIs as client= _id values (which means allowing “:” in the client_id string).&= nbsp; I’m OK with us either specifying a specific encoding when using them in Basic = or simply saying that “When client_ids are used with HTTP Basic that = contain characters such as “:” not allowed in HTTP Basic userna= mes, then the participants will need to agree upon a method of encoding the client_id for use with HTTP Basic.

 <= /p>

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

 <= /p>

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf= .org] On Behalf Of George Fletcher
Sent: Friday, June 15, 2012 8:48 AM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussi= on needed on username and password ABNF definitions

 

+1 for a simple encoding and allowing ':' in the c= lient_id

On 6/13/12 6:53 PM, Amos Jeffries wrote:

On 14.06.2012 06:40, John Bradley wrote:

That would probably w= ork as well.  That is why I am not particularly
concerned about excluding the :

We originally used the URI itself,  mostly for convenience of
debugging,  but there are other potential options.

The authorization server needs to compare the client_id and the
redirect uri. But it could compare the hash with not much more work.
Also a sha256 hash is probably longer than the uri it is hashing.

I am not super concerned with being able to have : in the client_id

John B.



If I'm following all these threads correctly the only explicit problem with= URI in client_id is HTTP username field being : terminated.
As such it does not have to be a hash per-se, just an encoding that removes= ":" and other reserved characters from the on-wire form *when se= nt via HTTP*.

AYJ

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

 

--_000_4E1F6AAD24975D4BA5B16804296739436654ABB1TK5EX14MBXC283r_-- From bcampbell@pingidentity.com Fri Jun 15 09:20:37 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93AA421F8533 for ; Fri, 15 Jun 2012 09:20:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GMplrskVIS-p for ; Fri, 15 Jun 2012 09:20:36 -0700 (PDT) Received: from na3sys009aog121.obsmtp.com (na3sys009aog121.obsmtp.com [74.125.149.145]) by ietfa.amsl.com (Postfix) with ESMTP id 4BC2221F8532 for ; Fri, 15 Jun 2012 09:20:28 -0700 (PDT) Received: from mail-qa0-f45.google.com ([209.85.216.45]) (using TLSv1) by na3sys009aob121.postini.com ([74.125.148.12]) with SMTP ID DSNKT9tgy7sz761SpTo2AFuu5bWkAI7CUMPw@postini.com; Fri, 15 Jun 2012 09:20:28 PDT Received: by qaeb19 with SMTP id b19so221258qae.18 for ; Fri, 15 Jun 2012 09:20:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=NZgVkeAkOMP1jYVPsQRjyFSmaykl5Skxv3AAoWp17oI=; b=fb7U2jbrRdYfJcgkCeZwDlpdpUAB3PyUwnrnKSmen+jWT8NJmT5g5GRuoMAAtXP8l6 LehAycGURLk4e7zbiMHJ8Z0LhxHnOEhTlmOcFlgNlhp7iiRicGb5POOHhzAhNDQHNjFs ecXxER1nzZMg6n+RSr45T9TxZl0Is4owAi+AyLRQfaeeey9nIU3UaYE1c2ZO809P4Hx0 va8aCAGCPpViZTp1l+tfCEfJieNFYcf3JmBY91a+786ULsci6AT8VCr5cjn+E2nJCaJb O3JDRnRkn+0tH6aFvVe+vkUhnTA/tB3/u5PUaN/m6liz9x58mdDQRfT9ZrTPFFHdH3SW NLCg== Received: by 10.224.217.67 with SMTP id hl3mr12165635qab.75.1339777223904; Fri, 15 Jun 2012 09:20:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.226.140 with HTTP; Fri, 15 Jun 2012 09:19:52 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436654ABB1@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <9dbeab60-8fe4-4828-9c52-d7af95378f4c@email.android.com> <0ec59f35-4a66-4719-adf3-114dab0d1d48@email.android.com> <40240328-0247-4278-BB7B-BE89AE130076@ve7jtb.com> <4FDB593B.4080508@aol.com> <4E1F6AAD24975D4BA5B16804296739436654ABB1@TK5EX14MBXC283.redmond.corp.microsoft.com> From: Brian Campbell Date: Fri, 15 Jun 2012 10:19:52 -0600 Message-ID: To: Mike Jones Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlt7SPyiq1ur5I/Cbgpadz5fbm586BQsNVl7Zl/yf4a65UrCR+5Af2wqndsH1S+MXRGeMBw Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion needed on username and password ABNF definitions X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 16:20:37 -0000 +1 On Fri, Jun 15, 2012 at 10:17 AM, Mike Jones wrote: > Based on use cases I=92m seeing, believe it=92s important to allow the us= e of > URIs as client_id values (which means allowing =93:=94 in the client_id > string).=A0 I=92m OK with us either specifying a specific encoding when u= sing > them in Basic or simply saying that =93When client_ids are used with HTTP > Basic that contain characters such as =93:=94 not allowed in HTTP Basic > usernames, then the participants will need to agree upon a method of > encoding the client_id for use with HTTP Basic. > > > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -- Mike > > > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of > George Fletcher > Sent: Friday, June 15, 2012 8:48 AM > To: oauth@ietf.org > Subject: Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion > needed on username and password ABNF definitions > > > > +1 for a simple encoding and allowing ':' in the client_id > > On 6/13/12 6:53 PM, Amos Jeffries wrote: > > On 14.06.2012 06:40, John Bradley wrote: > > That would probably work as well.=A0 That is why I am not particularly > concerned about excluding the : > > We originally used the URI itself,=A0 mostly for convenience of > debugging,=A0 but there are other potential options. > > The authorization server needs to compare the client_id and the > redirect uri. But it could compare the hash with not much more work. > Also a sha256 hash is probably longer than the uri it is hashing. > > I am not super concerned with being able to have : in the client_id > > John B. > > > > If I'm following all these threads correctly the only explicit problem wi= th > URI in client_id is HTTP username field being : terminated. > As such it does not have to be a hash per-se, just an encoding that remov= es > ":" and other reserved characters from the on-wire form *when sent via > HTTP*. > > AYJ > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From eran@hueniverse.com Fri Jun 15 09:26:21 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 816AF21F853C for ; Fri, 15 Jun 2012 09:26:21 -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 B3v9Er2bzFNj for ; Fri, 15 Jun 2012 09:26:20 -0700 (PDT) Received: from p3plex2out03.prod.phx3.secureserver.net (p3plex2out03.prod.phx3.secureserver.net [184.168.131.16]) by ietfa.amsl.com (Postfix) with ESMTP id AB31321F852E for ; Fri, 15 Jun 2012 09:26:20 -0700 (PDT) Received: from P3PWEX2HT002.ex2.secureserver.net ([184.168.131.10]) by p3plex2out03.prod.phx3.secureserver.net with bizsmtp id NgSL1j0060Dcg9U01gSL2v; Fri, 15 Jun 2012 09:26:20 -0700 Received: from P3PWEX2MB008.ex2.secureserver.net ([169.254.8.66]) by P3PWEX2HT002.ex2.secureserver.net ([184.168.131.10]) with mapi id 14.02.0247.003; Fri, 15 Jun 2012 09:26:19 -0700 From: Eran Hammer To: Mike Jones Thread-Topic: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion needed on username and password ABNF definitions Thread-Index: AQHNSw5aQ+07XirTWkeEJ2jRd0gB45b7jZDwgAADgx0= Date: Fri, 15 Jun 2012 16:26:19 +0000 Message-ID: References: <9dbeab60-8fe4-4828-9c52-d7af95378f4c@email.android.com> <0ec59f35-4a66-4719-adf3-114dab0d1d48@email.android.com> <40240328-0247-4278-BB7B-BE89AE130076@ve7jtb.com> <4FDB593B.4080508@aol.com>, <4E1F6AAD24975D4BA5B16804296739436654ABB1@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436654ABB1@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_DDC847271B5F48ADAC3FDB9700838955hueniversecom_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion needed on username and password ABNF definitions X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 16:26:21 -0000 --_000_DDC847271B5F48ADAC3FDB9700838955hueniversecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable We should not leave this under specified. Picking an encoding for just Basi= c and just colon is simple enough. EH On Jun 15, 2012, at 19:17, "Mike Jones" > wrote: Based on use cases I=92m seeing, believe it=92s important to allow the use = of URIs as client_id values (which means allowing =93:=94 in the client_id = string). I=92m OK with us either specifying a specific encoding when using= them in Basic or simply saying that =93When client_ids are used with HTTP = Basic that contain characters such as =93:=94 not allowed in HTTP Basic use= rnames, then the participants will need to agree upon a method of encoding = the client_id for use with HTTP Basic. -- Mike From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of George Fletcher Sent: Friday, June 15, 2012 8:48 AM To: oauth@ietf.org Subject: Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion need= ed on username and password ABNF definitions +1 for a simple encoding and allowing ':' in the client_id On 6/13/12 6:53 PM, Amos Jeffries wrote: On 14.06.2012 06:40, John Bradley wrote: That would probably work as well. That is why I am not particularly concerned about excluding the : We originally used the URI itself, mostly for convenience of debugging, but there are other potential options. The authorization server needs to compare the client_id and the redirect uri. But it could compare the hash with not much more work. Also a sha256 hash is probably longer than the uri it is hashing. I am not super concerned with being able to have : in the client_id John B. If I'm following all these threads correctly the only explicit problem with= URI in client_id is HTTP username field being : terminated. As such it does not have to be a hash per-se, just an encoding that removes= ":" and other reserved characters from the on-wire form *when sent via HTT= P*. AYJ _______________________________________________ OAuth mailing 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_DDC847271B5F48ADAC3FDB9700838955hueniversecom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
We should not leave this under specified. Picking an encoding for just= Basic and just colon is simple enough. 

EH

On Jun 15, 2012, at 19:17, "Mike Jones" <Michael.Jones@microsoft.com> wrote:

Based on use cases I=92m = seeing, believe it=92s important to allow the use of URIs as client_id valu= es (which means allowing =93:=94 in the client_id string).  I=92m OK with us either specifying a specific encoding when using them in Basic = or simply saying that =93When client_ids are used with HTTP Basic that cont= ain characters such as =93:=94 not allowed in HTTP Basic usernames, then th= e participants will need to agree upon a method of encoding the client_id for use with HTTP Basic.

 <= /p>

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

 <= /p>

From: oauth-bounces@ietf.org [mailt= o:oauth-bounces@ietf.org] On Behalf Of George Fletcher
Sent: Friday, June 15, 2012 8:48 AM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussi= on needed on username and password ABNF definitions

 

+1 for a simple encoding and allowing ':' in the c= lient_id

On 6/13/12 6:53 PM, Amos Jeffries wrote:

On 14.06.2012 06:40, John Bradley wrote:

That would probably w= ork as well.  That is why I am not particularly
concerned about excluding the :

We originally used the URI itself,  mostly for convenience of
debugging,  but there are other potential options.

The authorization server needs to compare the client_id and the
redirect uri. But it could compare the hash with not much more work.
Also a sha256 hash is probably longer than the uri it is hashing.

I am not super concerned with being able to have : in the client_id

John B.



If I'm following all these threads correctly the only explicit problem with= URI in client_id is HTTP username field being : terminated.
As such it does not have to be a hash per-se, just an encoding that removes= ":" and other reserved characters from the on-wire form *when se= nt via HTTP*.

AYJ

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

 

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.i= etf.org/mailman/listinfo/oauth
--_000_DDC847271B5F48ADAC3FDB9700838955hueniversecom_-- From Michael.Jones@microsoft.com Fri Jun 15 09:30:17 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 122E821F850F for ; Fri, 15 Jun 2012 09:30:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.714 X-Spam-Level: X-Spam-Status: No, score=-3.714 tagged_above=-999 required=5 tests=[AWL=-0.116, 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 rnyu1VmrlESy for ; Fri, 15 Jun 2012 09:30:14 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe004.messaging.microsoft.com [213.199.154.207]) by ietfa.amsl.com (Postfix) with ESMTP id 2801821F85A0 for ; Fri, 15 Jun 2012 09:30:14 -0700 (PDT) Received: from mail21-am1-R.bigfish.com (10.3.201.242) by AM1EHSOBE002.bigfish.com (10.3.204.22) with Microsoft SMTP Server id 14.1.225.23; Fri, 15 Jun 2012 16:29:03 +0000 Received: from mail21-am1 (localhost [127.0.0.1]) by mail21-am1-R.bigfish.com (Postfix) with ESMTP id 8406338050A; Fri, 15 Jun 2012 16:29:02 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -23 X-BigFish: VS-23(zzbb2dI98dI9371Ic85fhzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25hf0ah) Received-SPF: pass (mail21-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC101.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail21-am1 (localhost.localdomain [127.0.0.1]) by mail21-am1 (MessageSwitch) id 1339777739613529_32726; Fri, 15 Jun 2012 16:28:59 +0000 (UTC) Received: from AM1EHSMHS010.bigfish.com (unknown [10.3.201.253]) by mail21-am1.bigfish.com (Postfix) with ESMTP id 9411A10004B; Fri, 15 Jun 2012 16:28:59 +0000 (UTC) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS010.bigfish.com (10.3.207.110) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 15 Jun 2012 16:28:57 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.53]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi id 14.02.0298.005; Fri, 15 Jun 2012 16:29:40 +0000 From: Mike Jones To: Eran Hammer Thread-Topic: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion needed on username and password ABNF definitions Thread-Index: AQHNSw5aQ+07XirTWkeEJ2jRd0gB45b7jZDwgAADgx2AAAA4oA== Date: Fri, 15 Jun 2012 16:29:40 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436654ACC2@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <9dbeab60-8fe4-4828-9c52-d7af95378f4c@email.android.com> <0ec59f35-4a66-4719-adf3-114dab0d1d48@email.android.com> <40240328-0247-4278-BB7B-BE89AE130076@ve7jtb.com> <4FDB593B.4080508@aol.com>, <4E1F6AAD24975D4BA5B16804296739436654ABB1@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.33] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436654ACC2TK5EX14MBXC283r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion needed on username and password ABNF definitions X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 16:30:17 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436654ACC2TK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree with Eran that I prefer that this not be underspecified and that an= encoding for just colon for just Basic will suffice. I'd suggested the encoding s/://g as a strawman. Are there any other = encoding proposals? -- Mike From: Eran Hammer [mailto:eran@hueniverse.com] Sent: Friday, June 15, 2012 9:26 AM To: Mike Jones Cc: George Fletcher; oauth@ietf.org Subject: Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion need= ed on username and password ABNF definitions We should not leave this under specified. Picking an encoding for just Basi= c and just colon is simple enough. EH On Jun 15, 2012, at 19:17, "Mike Jones" > wrote: Based on use cases I'm seeing, believe it's important to allow the use of U= RIs as client_id values (which means allowing ":" in the client_id string).= I'm OK with us either specifying a specific encoding when using them in B= asic or simply saying that "When client_ids are used with HTTP Basic that c= ontain characters such as ":" not allowed in HTTP Basic usernames, then the= participants will need to agree upon a method of encoding the client_id fo= r use with HTTP Basic. -- Mike From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Georg= e Fletcher Sent: Friday, June 15, 2012 8:48 AM To: oauth@ietf.org Subject: Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion need= ed on username and password ABNF definitions +1 for a simple encoding and allowing ':' in the client_id On 6/13/12 6:53 PM, Amos Jeffries wrote: On 14.06.2012 06:40, John Bradley wrote: That would probably work as well. That is why I am not particularly concerned about excluding the : We originally used the URI itself, mostly for convenience of debugging, but there are other potential options. The authorization server needs to compare the client_id and the redirect uri. But it could compare the hash with not much more work. Also a sha256 hash is probably longer than the uri it is hashing. I am not super concerned with being able to have : in the client_id John B. If I'm following all these threads correctly the only explicit problem with= URI in client_id is HTTP username field being : terminated. As such it does not have to be a hash per-se, just an encoding that removes= ":" and other reserved characters from the on-wire form *when sent via HTT= P*. AYJ _______________________________________________ OAuth mailing 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_4E1F6AAD24975D4BA5B16804296739436654ACC2TK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I agree with Eran that I = prefer that this not be underspecified and that an encoding for just colon = for just Basic will suffice.

 <= /p>

I’d suggested the e= ncoding s/:/<tab>/g as a strawman.  Are there any other encoding= proposals?

 <= /p>

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

 <= /p>

From: Eran Hammer [mailto:eran@hueniverse.com]
Sent: Friday, June 15, 2012 9:26 AM
To: Mike Jones
Cc: George Fletcher; oauth@ietf.org
Subject: Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussi= on needed on username and password ABNF definitions

 

We should not leave this under specified. Picking an= encoding for just Basic and just colon is simple enough. <= /p>

 

EH

On Jun 15, 2012, at 19:17, "Mike Jones" <Michael.Jones@microsoft.com> wrote:

Based on use cases I̵= 7;m seeing, believe it’s important to allow the use of URIs as client= _id values (which means allowing “:” in the client_id string).&= nbsp; I’m OK with us either specifying a specific encoding when using them in Basic = or simply saying that “When client_ids are used with HTTP Basic that = contain characters such as “:” not allowed in HTTP Basic userna= mes, then the participants will need to agree upon a method of encoding the client_id for use with HTTP Basic.

 <= /p>

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

 <= /p>

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of George Fletcher
Sent: Friday, June 15, 2012 8:48 AM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussi= on needed on username and password ABNF definitions

 

+1 for a simple encoding and allowing ':' in the c= lient_id

On 6/13/12 6:53 PM, Amos Jeffries wrote:

On 14.06.2012 06:40, John Bradley wrote:


That would probably w= ork as well.  That is why I am not particularly
concerned about excluding the :

We originally used the URI itself,  mostly for convenience of
debugging,  but there are other potential options.

The authorization server needs to compare the client_id and the
redirect uri. But it could compare the hash with not much more work.
Also a sha256 hash is probably longer than the uri it is hashing.

I am not super concerned with being able to have : in the client_id

John B.



If I'm following all these threads correctly the only explicit problem with= URI in client_id is HTTP username field being : terminated.
As such it does not have to be a hash per-se, just an encoding that removes= ":" and other reserved characters from the on-wire form *when se= nt via HTTP*.

AYJ

_______________________________________________
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_4E1F6AAD24975D4BA5B16804296739436654ACC2TK5EX14MBXC283r_-- From Michael.Jones@microsoft.com Fri Jun 15 10:31:09 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99AD211E8088 for ; Fri, 15 Jun 2012 10:31:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.705 X-Spam-Level: X-Spam-Status: No, score=-3.705 tagged_above=-999 required=5 tests=[AWL=-0.107, 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 q1qgKeOc-2vt for ; Fri, 15 Jun 2012 10:31:07 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe001.messaging.microsoft.com [213.199.154.139]) by ietfa.amsl.com (Postfix) with ESMTP id 5252D11E8087 for ; Fri, 15 Jun 2012 10:31:06 -0700 (PDT) Received: from mail49-db3-R.bigfish.com (10.3.81.228) by DB3EHSOBE005.bigfish.com (10.3.84.25) with Microsoft SMTP Server id 14.1.225.23; Fri, 15 Jun 2012 17:29:51 +0000 Received: from mail49-db3 (localhost [127.0.0.1]) by mail49-db3-R.bigfish.com (Postfix) with ESMTP id 3A95532010A; Fri, 15 Jun 2012 17:29:51 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -23 X-BigFish: VS-23(zzbb2dI98dI9371Ic85fhzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25hf0ah) Received-SPF: pass (mail49-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC103.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail49-db3 (localhost.localdomain [127.0.0.1]) by mail49-db3 (MessageSwitch) id 1339781389657612_29611; Fri, 15 Jun 2012 17:29:49 +0000 (UTC) Received: from DB3EHSMHS005.bigfish.com (unknown [10.3.81.230]) by mail49-db3.bigfish.com (Postfix) with ESMTP id 9CC302C0059; Fri, 15 Jun 2012 17:29:49 +0000 (UTC) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS005.bigfish.com (10.3.87.105) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 15 Jun 2012 17:29:49 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.53]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.02.0309.003; Fri, 15 Jun 2012 17:30:45 +0000 From: Mike Jones To: George Fletcher Thread-Topic: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion needed on username and password ABNF definitions Thread-Index: AQHNSw5aQ+07XirTWkeEJ2jRd0gB45b7jZDwgAADgx2AAAA4oIAAERNw Date: Fri, 15 Jun 2012 17:30:44 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436654B001@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <9dbeab60-8fe4-4828-9c52-d7af95378f4c@email.android.com> <0ec59f35-4a66-4719-adf3-114dab0d1d48@email.android.com> <40240328-0247-4278-BB7B-BE89AE130076@ve7jtb.com> <4FDB593B.4080508@aol.com>, <4E1F6AAD24975D4BA5B16804296739436654ABB1@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_4E1F6AAD24975D4BA5B16804296739436654B001TK5EX14MBXC283r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion needed on username and password ABNF definitions X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 17:31:09 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436654B001TK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I was asked a question off-list, which I think is worth answering on-line. = The question was: Why the Tab character, rather than %-encoding? Introducing % encoding would break all existing OAuth 2.0 deployments using= HTTP Basic. A non-starter... Tab is legal in HTTP Basic but not in URLs or presently client_ids. It's a= lso a character that can be visibly rendered in an acceptable manner for de= bugging. The other choices were CR and LF, which are also legal in HTTP Ba= sic but wouldn't render very nicely. ;-) Cheers, -- Mike From: Mike Jones Sent: Friday, June 15, 2012 9:30 AM To: 'Eran Hammer' Cc: George Fletcher; oauth@ietf.org Subject: RE: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion need= ed on username and password ABNF definitions I agree with Eran that I prefer that this not be underspecified and that an= encoding for just colon for just Basic will suffice. I'd suggested the encoding s/://g as a strawman. Are there any other = encoding proposals? -- Mike From: Eran Hammer [mailto:eran@hueniverse.com] Sent: Friday, June 15, 2012 9:26 AM To: Mike Jones Cc: George Fletcher; oauth@ietf.org Subject: Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion need= ed on username and password ABNF definitions We should not leave this under specified. Picking an encoding for just Basi= c and just colon is simple enough. EH On Jun 15, 2012, at 19:17, "Mike Jones" > wrote: Based on use cases I'm seeing, believe it's important to allow the use of U= RIs as client_id values (which means allowing ":" in the client_id string).= I'm OK with us either specifying a specific encoding when using them in B= asic or simply saying that "When client_ids are used with HTTP Basic that c= ontain characters such as ":" not allowed in HTTP Basic usernames, then the= participants will need to agree upon a method of encoding the client_id fo= r use with HTTP Basic. -- Mike From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Georg= e Fletcher Sent: Friday, June 15, 2012 8:48 AM To: oauth@ietf.org Subject: Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion need= ed on username and password ABNF definitions +1 for a simple encoding and allowing ':' in the client_id On 6/13/12 6:53 PM, Amos Jeffries wrote: On 14.06.2012 06:40, John Bradley wrote: That would probably work as well. That is why I am not particularly concerned about excluding the : We originally used the URI itself, mostly for convenience of debugging, but there are other potential options. The authorization server needs to compare the client_id and the redirect uri. But it could compare the hash with not much more work. Also a sha256 hash is probably longer than the uri it is hashing. I am not super concerned with being able to have : in the client_id John B. If I'm following all these threads correctly the only explicit problem with= URI in client_id is HTTP username field being : terminated. As such it does not have to be a hash per-se, just an encoding that removes= ":" and other reserved characters from the on-wire form *when sent via HTT= P*. AYJ _______________________________________________ OAuth mailing 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_4E1F6AAD24975D4BA5B16804296739436654B001TK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I was asked a question of= f-list, which I think is worth answering on-line.  The question was: &= nbsp;Why the Tab character, rather than %-encoding?

 <= /p>

Introducing % encoding wo= uld break all existing OAuth 2.0 deployments using HTTP Basic.  A non-= starter…

 <= /p>

Tab is legal in HTTP Basi= c but not in URLs or presently client_ids.  It’s also a characte= r that can be visibly rendered in an acceptable manner for debugging.  The other choices were CR and LF, which are also legal in HTTP Basic but w= ouldn’t render very nicely. ;-)

 <= /p>

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

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

 <= /p>

From: Mike Jones
Sent: Friday, June 15, 2012 9:30 AM
To: 'Eran Hammer'
Cc: George Fletcher; oauth@ietf.org
Subject: RE: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussi= on needed on username and password ABNF definitions

 

I agree with Eran that I = prefer that this not be underspecified and that an encoding for just colon = for just Basic will suffice.

 <= /p>

I’d suggested the e= ncoding s/:/<tab>/g as a strawman.  Are there any other encoding= proposals?

 <= /p>

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

 <= /p>

From: Eran Hammer [mailto:eran@hueniverse.com= ]
Sent: Friday, June 15, 2012 9:26 AM
To: Mike Jones
Cc: George Fletcher; oauth@ietf.or= g
Subject: Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussi= on needed on username and password ABNF definitions

 

We should not leave this under specified. Picking an= encoding for just Basic and just colon is simple enough. <= /p>

 

EH

On Jun 15, 2012, at 19:17, "Mike Jones" <Michael.Jones@microsoft.com> wrote:

Based on use cases I̵= 7;m seeing, believe it’s important to allow the use of URIs as client= _id values (which means allowing “:” in the client_id string).&= nbsp; I’m OK with us either specifying a specific encoding when using them in Basic = or simply saying that “When client_ids are used with HTTP Basic that = contain characters such as “:” not allowed in HTTP Basic userna= mes, then the participants will need to agree upon a method of encoding the client_id for use with HTTP Basic.

 <= /p>

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

 <= /p>

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of George Fletcher
Sent: Friday, June 15, 2012 8:48 AM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussi= on needed on username and password ABNF definitions

 

+1 for a simple encoding and allowing ':' in the c= lient_id

On 6/13/12 6:53 PM, Amos Jeffries wrote:

On 14.06.2012 06:40, = John Bradley wrote:

That would probably w= ork as well.  That is why I am not particularly
concerned about excluding the :

We originally used the URI itself,  mostly for convenience of
debugging,  but there are other potential options.

The authorization server needs to compare the client_id and the
redirect uri. But it could compare the hash with not much more work.
Also a sha256 hash is probably longer than the uri it is hashing.

I am not super concerned with being able to have : in the client_id

John B.



If I'm following all these threads correctly the only explicit problem with= URI in client_id is HTTP username field being : terminated.
As such it does not have to be a hash per-se, just an encoding that removes= ":" and other reserved characters from the on-wire form *when se= nt via HTTP*.

AYJ

_______________________________________________
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_4E1F6AAD24975D4BA5B16804296739436654B001TK5EX14MBXC283r_-- From wmills@yahoo-inc.com Fri Jun 15 11:06:19 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94B2221F856F for ; Fri, 15 Jun 2012 11:06:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.518 X-Spam-Level: X-Spam-Status: No, score=-17.518 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y6jVgtYJuLrZ for ; Fri, 15 Jun 2012 11:06:18 -0700 (PDT) Received: from nm5-vm1.bullet.mail.ne1.yahoo.com (nm5-vm1.bullet.mail.ne1.yahoo.com [98.138.91.32]) by ietfa.amsl.com (Postfix) with SMTP id 39BFF21F851A for ; Fri, 15 Jun 2012 11:06:17 -0700 (PDT) Received: from [98.138.90.56] by nm5.bullet.mail.ne1.yahoo.com with NNFMP; 15 Jun 2012 18:06:15 -0000 Received: from [98.138.89.240] by tm9.bullet.mail.ne1.yahoo.com with NNFMP; 15 Jun 2012 18:06:14 -0000 Received: from [127.0.0.1] by omp1013.mail.ne1.yahoo.com with NNFMP; 15 Jun 2012 18:06:14 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 758814.75006.bm@omp1013.mail.ne1.yahoo.com Received: (qmail 19043 invoked by uid 60001); 15 Jun 2012 18:06:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1339783574; bh=YxnwbMjQdhNKMoUidtPiCspbAXLEBcxw9rXPyyLKl/Q=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=ad/7aFb6N8/UdiklyrRLM09gIBThlNgnU8S7XOjJJO40ZX0ALL5S0SNeMneN38Zv0i/9ns1IHaQon0oosZh/0hLN1lqQ1iqd0P+iHoiQn2PNgmbsOmvsFDWuUHtLCV33NnHiKlo8rQzd9Fy4AcKlt2xfGj/P31wCG3m+xsGto+g= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=CMDxNJ27p9jIqXVCkAvju8XSWkn+xwbse/vkeUa0LuPlW6bxw9i/mkCth9vLal+bUfhT9uXb3ADW0/PyWjE1nuogwfBYwbedJn+bJWpXefoFcvb7sAe+r6XwJKzJIeGL8JxGWVLQDsBAQ3Zps+3I3OEX56JuXBDNtI/48oWpnLA=; X-YMail-OSG: VKbQl1cVM1kkL3z8R_x1HD3BnxYizXfuL3uuRTE7YqdsZ9M cUu7kz29tgmd.XfYycqLZGc_QJBiD2eGCFWrYLNld4xSm2k7y_fWW8wRpYBt Cte35YfgbOzQdCnXzVKEciiDpYkioYvsxVSLs9W2i4a22ajbXNLJv.LzlcyD dO5HnNl28euX8G5tS0IQRGev2R5sVkg7Uubpr3c41saAHO_oBr51D6s9TDwL ojxOwIYtGfK_FtNMYGLbI8ZPiRXeVIecYZxWtjitBoa9jKsZI6U_HfHexqDc BTqwzCyJRNXocJ3Tc.tyx_ZKeS1JaRLQ82LiinsWNp39ZT1ckE0wO4SULUmG OV6GyuvhxHUz1pL6sf_wAoTUNlNrPx3n31QMZyFJNte0VheOmFiyZjKGy5ha yjLvbhJVNZXyaL50Co2vfxpxUEWRyoj0Ep1UY2i7ZTeVyPu_UdPw- Received: from [209.131.62.115] by web31812.mail.mud.yahoo.com via HTTP; Fri, 15 Jun 2012 11:06:14 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.120.356233 References: <0CBAEB56DDB3A140BA8E8C124C04ECA201073394@P3PWEX2MB008.ex2.secureserver.net> <4E1F6AAD24975D4BA5B1680429673943665394D7@TK5EX14MBXC284.redmond.corp.microsoft.com> <0CBAEB56DDB3A140BA8E8C124C04ECA2010734C5@P3PWEX2MB008.ex2.secureserver.net> <0CBAEB56DDB3A140BA8E8C124C04ECA201073573@P3PWEX2MB008.ex2.secureserver.net> <4E1F6AAD24975D4BA5B168042967394366539839@TK5EX14MBXC284.redmond.corp.microsoft.com> <0CBAEB56DDB3A140BA8E8C124C04ECA201073B82@P3PWEX2MB008.ex2.secureserver.net> Message-ID: <1339783574.11702.YahooMailNeo@web31812.mail.mud.yahoo.com> Date: Fri, 15 Jun 2012 11:06:14 -0700 (PDT) From: William Mills To: Eran Hammer , Mike Jones , "oauth@ietf.org WG \(oauth@ietf.org\)" In-Reply-To: <0CBAEB56DDB3A140BA8E8C124C04ECA201073B82@P3PWEX2MB008.ex2.secureserver.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1458549034-42515180-1339783574=:11702" Subject: Re: [OAUTH-WG] Section 7.2 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, 15 Jun 2012 18:06:19 -0000 --1458549034-42515180-1339783574=:11702 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable +1=0A=0A=0A=0A=0A>________________________________=0A> From: Eran Hammer =0A>To: Mike Jones ; "oauth= @ietf.org WG (oauth@ietf.org)" =0A>Sent: Thursday, June 14= , 2012 11:32 PM=0A>Subject: Re: [OAUTH-WG] Section 7.2=0A> =0A>=0A> =0A>WFM= .=0A>=A0=0A>This will be the new text for 7.2 unless someone has any additi= onal feedback or concerns.=0A>=A0=0A>This closes my issue with the new erro= r registry changes.=0A>=A0=0A>EH=0A>=A0=0A>From:Mike Jones [mailto:Michael.= Jones@microsoft.com] =0A>Sent: Thursday, June 14, 2012 6:15 PM=0A>To: Eran = Hammer; oauth@ietf.org WG (oauth@ietf.org)=0A>Subject: RE: [OAUTH-WG] Secti= on 7.2=0A>=A0=0A>Thanks for writing the text below.=A0 It looks fine to me.= =A0 About adding the other error parameters as suggestions, that seems like= a reasonable thing to do.=A0 How about the text at the end below, which ad= ds mentions of error_description and error_uri?=0A>=A0=0A>7.2.=A0 Error Res= ponse=0A>=A0=0A>=A0=A0 If a resource access request fails, the resource ser= ver SHOULD inform=0A>=A0=A0 the client of the error.=A0 While the specifics= of such error responses=0A>=A0=A0 are beyond the scope of this specificati= on, this documents establishes=0A>=A0=A0 a common registry for error values= to be shared among OAuth token=0A>=A0=A0 authentication schemes. =0A>=A0= =0A>=A0=A0 New authentication schemes designed primarily for OAuth token=0A= >=A0=A0 authentication SHOULD define a mechanism for providing an=0A>=A0=A0= error status code to the client, in which the error values allowed are=0A>= =A0=A0 registered in the error registry established by this specification. = Such=0A>=A0=A0 schemes MAY limit the set of valid error codes to a subset o= f the=0A>=A0=A0 registered values. If the error code is returned using a na= med parameter,=0A>=A0=A0 the parameter name SHOULD be "error".=0A>=A0=0A>= =A0=A0 Other schemes capable of being used for OAuth token authentication, = but=0A>=A0=A0 not primarily designed for that purpose, MAY bind their error= values to the=0A>=A0=A0 registry in the same manner.=0A>=A0=0A>=A0 =A0New = authentication schemes MAY choose to also specify the use of the=0A>=A0 =A0= "error_description" and "error_uri" parameters to return error information= =0A>=A0=A0 in a manner parallel to their usage in this specification.=0A>= =A0=0A>=A0=0A>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -- Mike=0A>=A0=0A>P.S.=A0 If you= already have the text you wrote in a copy of the draft, you should apply t= hese spelling corrections:=0A>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 de= sgined -> designed=0A>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 authentict= ion -> authentication=0A>=A0=0A>-----Original Message-----=0A>From: Eran Ha= mmer [mailto:eran@hueniverse.com] =0A>Sent: Thursday, June 14, 2012 3:29 PM= =0A>To: Eran Hammer; Mike Jones; oauth@ietf.org WG (oauth@ietf.org)=0A>Subj= ect: RE: [OAUTH-WG] Section 7.2=0A>=A0=0A>Mike - if you want to add the oth= er error parameters as suggestions, that would be fine by me.=0A>=A0=0A>EH= =0A>=A0=0A>> -----Original Message-----=0A>> From: oauth-bounces@ietf.org [= mailto:oauth-bounces@ietf.org] On Behalf =0A>> Of Eran Hammer=0A>> Sent: Th= ursday, June 14, 2012 3:23 PM=0A>> To: Mike Jones; oauth@ietf.org WG (oauth= @ietf.org)=0A>> Subject: Re: [OAUTH-WG] Section 7.2=0A>> =0A>> 7.2.=A0 Erro= r Response=0A>> =0A>>=A0=A0=A0 If a resource access request fails, the reso= urce server SHOULD inform=0A>>=A0=A0=A0 the client of the error.=A0 While t= he specifics of such error responses=0A>>=A0=A0=A0 are beyond the scope of = this specification, this documents establishes=0A>>=A0=A0=A0 a common regis= try for error values to be shared among OAuth token=0A>>=A0=A0=A0 authentic= ation schemes.=0A>> =0A>>=A0=A0=A0 New authentication schemes desgined prim= arily for OAuth token=0A>>=A0=A0=A0 authentiction SHOULD define a mechanism= for providing an=0A>>=A0=A0=A0 error status code to the client, in which t= he error values allowed are=0A>>=A0=A0=A0 registered in the error registry = established by this specification. Such=0A>>=A0=A0=A0 schemes MAY limit the= set of valid error codes to a subset of the=0A>>=A0=A0=A0 registered value= s. If the error code is returned using a named parameter,=0A>>=A0=A0=A0 the= parameter name SHOULD be "error".=0A>> =0A>>=A0=A0=A0 Other schemes capabl= e of being used for OAuth token authentication, but=0A>>=A0=A0=A0 not prima= rily designed for that purpose, MAY bind their error values to the=0A>>=A0= =A0=A0 registry in the same manner.=0A>> =0A>> EH=0A>> =0A>> ______________= _________________________________=0A>> OAuth mailing list=0A>> OAuth@ietf.o= rg=0A>> https://www.ietf.org/mailman/listinfo/oauth=0A>=A0=0A>_____________= __________________________________=0A>OAuth mailing list=0A>OAuth@ietf.org= =0A>https://www.ietf.org/mailman/listinfo/oauth=0A>=0A>=0A> --1458549034-42515180-1339783574=:11702 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
+1

<= div style=3D"font-family: Courier New, courier, monaco, monospace, sans-ser= if; font-size: 14pt;">
From: Eran Hammer <eran@hueniverse.com>
To: Mike Jones <Michael.Jones@microsoft.com>= ; "oauth@ietf.org WG (oauth@ietf.org)" <oauth@ietf.org>
Sent: Thursday, June 14, 2012 11:3= 2 PM
Subject: Re: [OAU= TH-WG] Section 7.2

=0A
=0A=0A =0A =0A=0A=0A
=0A
=0A
WFM.
=0A
 
=0AThis will= be the new text for 7.2 unless someone has any additional feedback or conc= erns.
=0A
 
=0A
This closes my issue with the new error r= egistry changes.
=0A
 
=0A
EH
=0A
  =0A
=0A
=0A
=0A
From: Mike Jones [mailto:Michael.Jones@microsoft.com]=0A
=0ASent: Thursday, June 14, 2012 6:15 PM
=0ATo: Eran Hammer; oa= uth@ietf.org WG (oauth@ietf.org)
=0ASubject: RE: [OAUTH-WG] Secti= on 7.2
=0A
=0A
=0A
 
=0A
Thanks for wr= iting the text below.  It looks fine to me.  About adding the oth= er error parameters as suggestions, that seems like a reasonable thing to d= o.  How about the text at the end below, which adds mentions of error_= description=0A and error_uri?
=0A
 
=0A
7.2.  Error Response
=0A
 
=0A
   If a resource access req= uest fails, the resource server SHOULD inform
=0A
   the client of the= error.  While the specifics of such error responses
=0A<= div class=3D"yiv1727305955MsoPlainText">   are b= eyond the scope of this specification, this documents establishes =0A
 &nbs= p; a common registry for error values to be shared among OAuth token=
=0A
 &= nbsp; authentication schemes.=0A
=0A
 
=0A
   New authentication sche= mes designed primarily for OAuth token
=0A
   authentication SHOULD de= fine a mechanism for providing an
=0A
   error status code to the clie= nt, in which the error values allowed are
=0A
   registered in the err= or registry established by this specification. Such
=0A
   schemes MAY= limit the set of valid error codes to a subset of the
=0A   register= ed values. If the error code is returned using a named parameter, =0A
 &nbs= p; the parameter name SHOULD be "error".
=0A
 
=0A
   Other schemes = capable of being used for OAuth token authentication, but
=0A<= div class=3D"yiv1727305955MsoPlainText">   not p= rimarily designed for that purpose, MAY bind their error values to the
=0A
 = ;  registry in the same manner.
=0A
 
=0A
   New authentication = schemes MAY choose to also specify the use of the
=0A
   "error_descri= ption" and "error_uri" parameters to return error information
= =0A
   i= n a manner parallel to their usage in this specification.
=0A<= div class=3D"yiv1727305955MsoPlainText">  
=0A
 
=0A
           &nb= sp;            =             &nb= sp;            =            -- Mike
= =0A
 
=0A
P.S.  If you already have the text you wrot= e in a copy of the draft, you should apply these spelling corrections: =0A
     = ;          desgined -> desi= gned
=0A
   &n= bsp;           authentict= ion -> authentication
=0A
=  
=0A
-----Original Mes= sage-----
=0AFrom: Eran Hammer [mailto:eran@hueniverse.com]=0A
=0ASent: Thursday, Ju= ne 14, 2012 3:29 PM
=0ATo: Eran Hammer; Mike Jones; oauth@ietf.org WG (oauth@ietf.org)
=0ASubject: RE: [OAUTH-WG] Section 7.2
=0A
 
=0A
Mike - if you want to add the other error parameters as suggestions, th= at would be fine by me.
=0A
=  
=0A
EH
=0A
 
=0A
> -----Original Message-----
=0A
> From: oauth-bounces@i= etf.org=0A[mailto:oaut= h-bounces@ietf.org] On Behalf=0A
=0A
> Of Eran Hammer
=0A
> Sent: Thursday, June 14, 2012 3:23 PM
=0A
> To: Mike Jones; oauth@ietf.org= WG (oauth@ietf.org)
=0A
> Subject: Re: [OAUTH-WG] Section 7.2
= =0A
>
=0A
> 7.2.  Error Response
=0A
>
=0A
>    If a resource access request fails, the = resource server SHOULD inform
=0A
>    the client of the error.  While the specif= ics of such error responses
=0A
>    are beyond the scope of this specification, this = documents establishes
=0A
>= ;    a common registry for error values to be shared among O= Auth token
=0A
> &nbs= p;  authentication schemes.
=0A
>
=0A
> &= nbsp;  New authentication schemes desgined primarily for OAuth token =0A
>    aut= hentiction SHOULD define a mechanism for providing an
=0A
>    error status code to = the client, in which the error values allowed are
=0A
>    registered in the error reg= istry established by this specification. Such
=0A
>    schemes MAY limit the set of va= lid error codes to a subset of the
=0A
>    registered values. If the error code is re= turned using a named parameter,
=0A
>    the parameter name SHOULD be "error".
= =0A
>
=0A
>    Other schemes capable of be= ing used for OAuth token authentication, but
=0A
>    not primarily designed for that = purpose, MAY bind their error values to the
=0A
>    registry in the same manner. =0A
>
=0A
> EH
=0A
>
=0A
> ____= ___________________________________________
=0A
> OAuth mailing list
=0A
> OAuth@ietf.org
=0A =0A
  =0A
=0A
=0A
=0A=0A

______________________________= _________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.o= rg/mailman/listinfo/oauth


=
--1458549034-42515180-1339783574=:11702-- From wmills@yahoo-inc.com Fri Jun 15 11:12:52 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 662E421F859A for ; Fri, 15 Jun 2012 11:12:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.522 X-Spam-Level: X-Spam-Status: No, score=-17.522 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ml39nSfJ62P0 for ; Fri, 15 Jun 2012 11:12:51 -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 9EB7621F858A for ; Fri, 15 Jun 2012 11:12:50 -0700 (PDT) Received: from [98.139.214.32] by nm14.bullet.mail.bf1.yahoo.com with NNFMP; 15 Jun 2012 18:12:50 -0000 Received: from [98.139.212.218] by tm15.bullet.mail.bf1.yahoo.com with NNFMP; 15 Jun 2012 18:12:49 -0000 Received: from [127.0.0.1] by omp1027.mail.bf1.yahoo.com with NNFMP; 15 Jun 2012 18:12:49 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 975917.32643.bm@omp1027.mail.bf1.yahoo.com Received: (qmail 80686 invoked by uid 60001); 15 Jun 2012 18:12:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1339783969; bh=V6pS4+kWY0jg15A1hiAVMFjhp5IOV991aM7t0QnDYzU=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Oex1apaMC8VIgCE7rM1zZakYs3rtJI8rrAcezmSrlUe7KeXI8gr99rC3RfmPNIo6sfCGZ6X6u3Rff7WSMQ3bS0PPtzF/EHVV0xFrMrd+DIoMVVrNaF4FaR7xl58hyUIj7rmlt2e23iww24ftdbjs7ct5q4HEt0QVPhxlvxMNkDQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=T9cDlG7MScmudFVZ/pCPzferp8RiVBbcmX4K2U8RYHfOtLtZWH4accv5pqrPs4G8eteLVntnKwrsUT/IcL09/p4gxliD4CNEqlDFbOSZ/jOzppJcCsZ3bR5JbL2s8muYllfYUQtXoIntlytv0eJ8HBuvvfAljItlgN4eyvnywjw=; X-YMail-OSG: .eaxovkVM1kgepvTmtphLY1eIZ46hGMzWR0aPNs9So1NUcS jxM5m3pY1WJF7uLN1MmxCYkefNP88SFMrFhpPz_xOulEELQG7b0myIiXRJSx _UQHi06PkrB3vGBW3niHqNqlg01KKitjFSsd3QPaVbwKI_1Tizcs0j6Ioz_P RxbD7tGbfgr2Ihr7.Wv7zT0aUFuVzmL5Nl3jygrxp_AB6WZ69jvgwzFI18Sw WNhdS8njC.0F4Sv0ONifJ57fSj9V6mt3LVT.vc5K8XJpK1fpVHjqF2FBjQnW kjEJzwhD3U_ewrzrxpEFHGqkWFYg7S5RvHFhK2zqMVkCc0o8y.QgQc8ANov_ xUDDP.q8kKumeYgEulL2b6JGyXWuueEpYJwpzzdMoTK1hQ8wr7P3aB1gzCT4 c_7Bfrem6O0aFDkr298OTgF1ehciwPU6vG5w_Qh.DW8eiImVKnu0- Received: from [209.131.62.115] by web31806.mail.mud.yahoo.com via HTTP; Fri, 15 Jun 2012 11:12:49 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.120.356233 References: <9dbeab60-8fe4-4828-9c52-d7af95378f4c@email.android.com> <0ec59f35-4a66-4719-adf3-114dab0d1d48@email.android.com> <40240328-0247-4278-BB7B-BE89AE130076@ve7jtb.com> <4FDB593B.4080508@aol.com>, <4E1F6AAD24975D4BA5B16804296739436654ABB1@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739436654B001@TK5EX14MBXC283.redmond.corp.microsoft.com> Message-ID: <1339783969.62797.YahooMailNeo@web31806.mail.mud.yahoo.com> Date: Fri, 15 Jun 2012 11:12:49 -0700 (PDT) From: William Mills To: Mike Jones , George Fletcher In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436654B001@TK5EX14MBXC283.redmond.corp.microsoft.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1055047407-2024870578-1339783969=:62797" Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion needed on username and password ABNF definitions 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, 15 Jun 2012 18:12:52 -0000 ---1055047407-2024870578-1339783969=:62797 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Aesthetically this makes my tummy hurt...=0A=0AThat said, I think it will w= ork, and I'm willing to go with it.=0A=0A=0A=0A=0A>________________________= ________=0A> From: Mike Jones =0A>To: George F= letcher =0A>Cc: "oauth@ietf.org" =0A>Se= nt: Friday, June 15, 2012 10:30 AM=0A>Subject: Re: [OAUTH-WG] Dynamic clien= ts, URI, and stuff Re: Discussion needed on username and password ABNF defi= nitions=0A> =0A>=0A> =0A>I was asked a question off-list, which I think is = worth answering on-line.=C2=A0 The question was: =C2=A0Why the Tab characte= r, rather than %-encoding?=0A>=C2=A0=0A>Introducing % encoding would break = all existing OAuth 2.0 deployments using HTTP Basic.=C2=A0 A non-starter=E2= =80=A6=0A>=C2=A0=0A>Tab is legal in HTTP Basic but not in URLs or presently= client_ids.=C2=A0 It=E2=80=99s also a character that can be visibly render= ed in an acceptable manner for debugging.=C2=A0 The other choices were CR a= nd LF, which are also legal in HTTP Basic but wouldn=E2=80=99t render very = nicely. ;-)=0A>=C2=A0=0A>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 Cheers,=0A>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 --= Mike=0A>=C2=A0=0A>From:Mike Jones =0A>Sent: Friday, June 15, 2012 9:30 AM= =0A>To: 'Eran Hammer'=0A>Cc: George Fletcher; oauth@ietf.org=0A>Subject: RE= : [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion needed on usern= ame and password ABNF definitions=0A>=C2=A0=0A>I agree with Eran that I pre= fer that this not be underspecified and that an encoding for just colon for= just Basic will suffice.=0A>=C2=A0=0A>I=E2=80=99d suggested the encoding s= /://g as a strawman.=C2=A0 Are there any other encoding proposals?=0A>= =C2=A0=0A>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike= =0A>=C2=A0=0A>From:Eran Hammer [mailto:eran@hueniverse.com] =0A>Sent: Frida= y, June 15, 2012 9:26 AM=0A>To: Mike Jones=0A>Cc: George Fletcher; oauth@ie= tf.org=0A>Subject: Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discu= ssion needed on username and password ABNF definitions=0A>=C2=A0=0A>We shou= ld not leave this under specified. Picking an encoding for just Basic and j= ust colon is simple enough.=C2=A0=0A>=C2=A0=0A>EH=0A>=0A>On Jun 15, 2012, a= t 19:17, "Mike Jones" wrote:=0A>Based on use = cases I=E2=80=99m seeing, believe it=E2=80=99s important to allow the use o= f URIs as client_id values (which means allowing =E2=80=9C:=E2=80=9D in the= client_id string).=C2=A0 I=E2=80=99m OK with us either specifying a specif= ic encoding when using them in Basic or simply saying that =E2=80=9CWhen cl= ient_ids are used with HTTP Basic that contain characters such as =E2=80=9C= :=E2=80=9D not allowed in HTTP Basic usernames, then the participants will = need to agree upon a method of encoding the client_id for use with HTTP Bas= ic.=0A>>=C2=A0=0A>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= -- Mike=0A>>=C2=A0=0A>>From:oauth-bounces@ietf.org [mailto:oauth-bounces@i= etf.org] On Behalf Of George Fletcher=0A>>Sent: Friday, June 15, 2012 8:48 = AM=0A>>To: oauth@ietf.org=0A>>Subject: Re: [OAUTH-WG] Dynamic clients, URI,= and stuff Re: Discussion needed on username and password ABNF definitions= =0A>>=C2=A0=0A>>+1 for a simple encoding and allowing ':' in the client_id= =0A>>=0A>>On 6/13/12 6:53 PM, Amos Jeffries wrote: =0A>>On 14.06.2012 06:40= , John Bradley wrote: =0A>>=0A>>=0A>>That would probably work as well.=C2= =A0 That is why I am not particularly =0A>>concerned about excluding the : = =0A>>=0A>>We originally used the URI itself,=C2=A0 mostly for convenience o= f =0A>>debugging,=C2=A0 but there are other potential options. =0A>>=0A>>Th= e authorization server needs to compare the client_id and the =0A>>redirect= uri. But it could compare the hash with not much more work. =0A>>Also a sh= a256 hash is probably longer than the uri it is hashing. =0A>>=0A>>I am not= super concerned with being able to have : in the client_id =0A>>=0A>>John = B. =0A>>=0A>>=0A>>If I'm following all these threads correctly the only exp= licit problem with URI in client_id is HTTP username field being : terminat= ed. =0A>>As such it does not have to be a hash per-se, just an encoding tha= t removes ":" and other reserved characters from the on-wire form *when sen= t via HTTP*. =0A>>=0A>>AYJ =0A>>=0A>>______________________________________= _________ =0A>>OAuth mailing list =0A>>OAuth@ietf.org =0A>>https://www.ietf= .org/mailman/listinfo/oauth =0A>>=0A>>=0A>>=C2=A0=0A>______________________= _________________________=0A>>OAuth mailing list=0A>>OAuth@ietf.org=0A>>htt= ps://www.ietf.org/mailman/listinfo/oauth=0A>_______________________________= ________________=0A>OAuth mailing list=0A>OAuth@ietf.org=0A>https://www.iet= f.org/mailman/listinfo/oauth=0A>=0A>=0A> ---1055047407-2024870578-1339783969=:62797 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Aesthetically this makes my tummy hurt...

That said, I think it will work, and I'm willing to go = with it.

<= div style=3D"font-family: Courier New, courier, monaco, monospace, sans-ser= if; font-size: 14pt;">
From: Mike Jones <Michael.Jones@microsoft.com>
To: George Fletcher <gffletch@aol.com>= ;
Cc: "oauth@ietf.org" <oauth@ietf.org>
Sent: Friday, June 15, 2012 10:30 AM
Subject: Re: [OAUTH-WG] Dynamic clients, URI, and stuff R= e: Discussion needed on username and password ABNF definitions
 =

=0A
=0A=0A =0A =0A=0A=0A
=0A
=0A
I was asked a question off-list, which I think is worth answering on-line= .  The question was:  Why the Tab character, rather than %-encodi= ng?
=0A
 
=0A
Introducing= % encoding would break all existing OAuth 2.0 deployments using HTTP Basic= .  A non-starter=E2=80=A6
=0A
  =0A
Tab is legal in HTTP Basic but not in URLs or presently cli= ent_ids.  It=E2=80=99s also a character that can be visibly rendered i= n an acceptable manner for debugging. =0A The other choices were CR an= d LF, which are also legal in HTTP Basic but wouldn=E2=80=99t render very n= icely. ;-)
=0A
 
=0A
&nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;         Cheers,
=0A=
           = ;            &n= bsp;            = ;            &n= bsp;           -- Mike
=0A
 
=0A
=0A
=0A
From: Mike Jones=0A
=0ASent: Friday, June 15, 2012 9:30 AM
=0A= To: 'Eran Hammer'
=0ACc: George Fletcher; oauth@ietf.org
= =0ASubject: RE: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discu= ssion needed on username and password ABNF definitions
=0A=0A
=0A
 
=0A
I agree with Eran that I prefer that this not be underspecified and that= an encoding for just colon for just Basic will suffice.
=0A  
=0A
I=E2=80=99d suggested the encodin= g s/:/<tab>/g as a strawman.  Are there any other encoding propo= sals?
=0A
 
=0A
 &nb= sp;            =             &nb= sp;            =             &nb= sp;        -- Mike
=0A
 
=0A
=0A
=0A
From: Eran Hammer=0A[mailto:eran@hueniver= se.com]
=0ASent: Friday, June 15, 2012 9:26 AM
=0ATo:<= /b> Mike Jones
=0ACc: George Fletcher; oauth@ietf.org
=0ASubject: Re: [OAUTH-WG] Dynamic clients, = URI, and stuff Re: Discussion needed on username and password ABNF definiti= ons
=0A
=0A
=0A
=  
=0A
=0A
We should not= leave this under specified. Picking an encoding for just Basic and just co= lon is simple enough. 
=0A
=0A
=0A
 
=0A
=0A
=0A
EH
=0A
=0AOn Jun 15, 2012= , at 19:17, "Mike Jones" <Michael.Jones@microsoft.com> wrote:
=0A
=0A=0A
=0A
= Based on use cases I=E2=80=99m seeing, believe it=E2=80=99s important to al= low the use of URIs as client_id values (which means allowing =E2=80=9C:=E2= =80=9D in the client_id string).  I=E2=80=99m=0A OK with us either spe= cifying a specific encoding when using them in Basic or simply saying that = =E2=80=9CWhen client_ids are used with HTTP Basic that contain characters s= uch as =E2=80=9C:=E2=80=9D not allowed in HTTP Basic usernames, then the pa= rticipants will need to agree upon=0A a method of encoding the client_id fo= r use with HTTP Basic.
=0A
 
=0A           &n= bsp;            = ;            &n= bsp;            = ;           -- Mike
=0A
 
=0A
=0A
=0A
From:= =0Aoauth-bounces@ietf.org <= a rel=3D"nofollow" ymailto=3D"mailto:[mailto:oauth-bounces@ietf.org]" targe= t=3D"_blank" href=3D"mailto:[mailto:oauth-bounces@ietf.org]">=0A[mailto:oau= th-bounces@ietf.org] On Behalf Of George Fletcher
=0ASent:= Friday, June 15, 2012 8:48 AM
=0ATo: oauth@ietf.org
=0ASubject: Re: [OAUTH-WG] Dynamic client= s, URI, and stuff Re: Discussion needed on username and password ABNF defin= itions
=0A
=0A
=0A
 
=0A
+1= for a simple encoding and allowing ':' in the client_id
=0A
= =0AOn 6/13/12 6:53 PM, Amos Jeffries wrote:
=0A
On 14.06.2012 06:40, John B= radley wrote:=0A
=0A
=0A
=0A
That would probably work as well.  T= hat is why I am not particularly=0A
=0Aconcerned about excluding the : <= br>=0A
=0AWe originally used the URI itself,  mostly for convenienc= e of
=0Adebugging,  but there are other potential options.
=0A=
=0AThe authorization server needs to compare the client_id and the
= =0Aredirect uri. But it could compare the hash with not much more work. =0AAlso a sha256 hash is probably longer than the uri it is hashing.
= =0A
=0AI am not super concerned with being able to have : in the client_= id
=0A
=0AJohn B.
=0A

=0A
=0AIf I'm following all these threa= ds correctly the only explicit problem with URI in client_id is HTTP userna= me field being : terminated.=0A
=0AAs such it does not have to be a hash= per-se, just an encoding that removes ":" and other reserved characters fr= om the on-wire form *when sent via HTTP*.=0A
=0A
=0AAYJ
=0A
= =0A_______________________________________________
=0AOAuth mailing lis= t
=0AOAuth@ietf.org
=0Ahttps://www.ietf.org/mailman/listinfo/oauth=0A
=0A
=0A
= =0A
 
=0A
=0A=0A
=0A
= =0A
_= ______________________________________________
=0AOAuth mailing list
= =0AOAuth@ietf.org
=0Ahtt= ps://www.ietf.org/mailman/listinfo/oauth
=0A
=0A=0A
=0A
=0A=0A

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


= ---1055047407-2024870578-1339783969=:62797-- From jricher@mitre.org Fri Jun 15 11:16:24 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6339F21F854F for ; Fri, 15 Jun 2012 11:16:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.298 X-Spam-Level: X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[AWL=0.300, 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 d+FluYgQzmNd for ; Fri, 15 Jun 2012 11:16:21 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1D42021F859B for ; Fri, 15 Jun 2012 11:16:20 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 459F621B1B08; Fri, 15 Jun 2012 14:16:17 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 2AC0721B1B1B; Fri, 15 Jun 2012 14:16:17 -0400 (EDT) Received: from [129.83.50.12] (129.83.31.51) by IMCCAS02.MITRE.ORG (129.83.29.79) with Microsoft SMTP Server (TLS) id 14.2.283.3; Fri, 15 Jun 2012 14:16:16 -0400 Message-ID: <4FDB7BDF.60700@mitre.org> Date: Fri, 15 Jun 2012 14:15:59 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Mike Jones References: <9dbeab60-8fe4-4828-9c52-d7af95378f4c@email.android.com> <0ec59f35-4a66-4719-adf3-114dab0d1d48@email.android.com> <40240328-0247-4278-BB7B-BE89AE130076@ve7jtb.com> <4FDB593B.4080508@aol.com>, <4E1F6AAD24975D4BA5B16804296739436654ABB1@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739436654B001@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436654B001@TK5EX14MBXC283.redmond.corp.microsoft.com> Content-Type: multipart/alternative; boundary="------------060406020309070103080104" X-Originating-IP: [129.83.31.51] Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion needed on username and password ABNF definitions X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 18:16:24 -0000 --------------060406020309070103080104 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Why not percent encoding for just colon and percent? -- Justin On 06/15/2012 01:30 PM, Mike Jones wrote: > > I was asked a question off-list, which I think is worth answering > on-line. The question was: Why the Tab character, rather than > %-encoding? > > Introducing % encoding would break all existing OAuth 2.0 deployments > using HTTP Basic. A non-starter... > > Tab is legal in HTTP Basic but not in URLs or presently client_ids. > It's also a character that can be visibly rendered in an acceptable > manner for debugging. The other choices were CR and LF, which are > also legal in HTTP Basic but wouldn't render very nicely. ;-) > > Cheers, > > -- Mike > > *From:*Mike Jones > *Sent:* Friday, June 15, 2012 9:30 AM > *To:* 'Eran Hammer' > *Cc:* George Fletcher; oauth@ietf.org > *Subject:* RE: [OAUTH-WG] Dynamic clients, URI, and stuff Re: > Discussion needed on username and password ABNF definitions > > I agree with Eran that I prefer that this not be underspecified and > that an encoding for just colon for just Basic will suffice. > > I'd suggested the encoding s/://g as a strawman. Are there any > other encoding proposals? > > -- Mike > > *From:*Eran Hammer [mailto:eran@hueniverse.com] > > *Sent:* Friday, June 15, 2012 9:26 AM > *To:* Mike Jones > *Cc:* George Fletcher; oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: > Discussion needed on username and password ABNF definitions > > We should not leave this under specified. Picking an encoding for just > Basic and just colon is simple enough. > > EH > > On Jun 15, 2012, at 19:17, "Mike Jones" > wrote: > > Based on use cases I'm seeing, believe it's important to allow the > use of URIs as client_id values (which means allowing ":" in the > client_id string). I'm OK with us either specifying a specific > encoding when using them in Basic or simply saying that "When > client_ids are used with HTTP Basic that contain characters such > as ":" not allowed in HTTP Basic usernames, then the participants > will need to agree upon a method of encoding the client_id for use > with HTTP Basic. > > -- Mike > > *From:*oauth-bounces@ietf.org > [mailto:oauth-bounces@ietf.org] > *On Behalf Of *George > Fletcher > *Sent:* Friday, June 15, 2012 8:48 AM > *To:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: > Discussion needed on username and password ABNF definitions > > +1 for a simple encoding and allowing ':' in the client_id > > On 6/13/12 6:53 PM, Amos Jeffries wrote: > > On 14.06.2012 06:40, John Bradley wrote: > > That would probably work as well. That is why I am not particularly > concerned about excluding the : > > We originally used the URI itself, mostly for convenience of > debugging, but there are other potential options. > > The authorization server needs to compare the client_id and the > redirect uri. But it could compare the hash with not much more work. > Also a sha256 hash is probably longer than the uri it is hashing. > > I am not super concerned with being able to have : in the client_id > > John B. > > > > If I'm following all these threads correctly the only explicit > problem with URI in client_id is HTTP username field being : > terminated. > As such it does not have to be a hash per-se, just an encoding > that removes ":" and other reserved characters from the on-wire > form *when sent via HTTP*. > > AYJ > > _______________________________________________ > OAuth mailing 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 --------------060406020309070103080104 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Why not percent encoding for just colon and percent?

 -- Justin

On 06/15/2012 01:30 PM, Mike Jones wrote:

I was asked a question off-list, which I think is worth answering on-line.  The question was:  Why the Tab character, rather than %-encoding?

 

Introducing % encoding would break all existing OAuth 2.0 deployments using HTTP Basic.  A non-starter…

 

Tab is legal in HTTP Basic but not in URLs or presently client_ids.  It’s also a character that can be visibly rendered in an acceptable manner for debugging.  The other choices were CR and LF, which are also legal in HTTP Basic but wouldn’t render very nicely. ;-)

 

                                                            Cheers,

                                                            -- Mike

 

From: Mike Jones
Sent: Friday, June 15, 2012 9:30 AM
To: 'Eran Hammer'
Cc: George Fletcher; oauth@ietf.org
Subject: RE: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion needed on username and password ABNF definitions

 

I agree with Eran that I prefer that this not be underspecified and that an encoding for just colon for just Basic will suffice.

 

I’d suggested the encoding s/:/<tab>/g as a strawman.  Are there any other encoding proposals?

 

                                                            -- Mike

 

From: Eran Hammer [mailto:eran@hueniverse.com]
Sent: Friday, June 15, 2012 9:26 AM
To: Mike Jones
Cc: George Fletcher; oauth@ietf.org
Subject: Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion needed on username and password ABNF definitions

 

We should not leave this under specified. Picking an encoding for just Basic and just colon is simple enough. 

 

EH

On Jun 15, 2012, at 19:17, "Mike Jones" <Michael.Jones@microsoft.com> wrote:

Based on use cases I’m seeing, believe it’s important to allow the use of URIs as client_id values (which means allowing “:” in the client_id string).  I’m OK with us either specifying a specific encoding when using them in Basic or simply saying that “When client_ids are used with HTTP Basic that contain characters such as “:” not allowed in HTTP Basic usernames, then the participants will need to agree upon a method of encoding the client_id for use with HTTP Basic.

 

                                                            -- Mike

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of George Fletcher
Sent: Friday, June 15, 2012 8:48 AM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion needed on username and password ABNF definitions

 

+1 for a simple encoding and allowing ':' in the client_id

On 6/13/12 6:53 PM, Amos Jeffries wrote:

On 14.06.2012 06:40, John Bradley wrote:

That would probably work as well.  That is why I am not particularly
concerned about excluding the :

We originally used the URI itself,  mostly for convenience of
debugging,  but there are other potential options.

The authorization server needs to compare the client_id and the
redirect uri. But it could compare the hash with not much more work.
Also a sha256 hash is probably longer than the uri it is hashing.

I am not super concerned with being able to have : in the client_id

John B.



If I'm following all these threads correctly the only explicit problem with URI in client_id is HTTP username field being : terminated.
As such it does not have to be a hash per-se, just an encoding that removes ":" and other reserved characters from the on-wire form *when sent via HTTP*.

AYJ

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

--------------060406020309070103080104-- From Hannes.Tschofenig@gmx.net Fri Jun 15 11:26:52 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18CC921F84A0 for ; Fri, 15 Jun 2012 11:26:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.274 X-Spam-Level: X-Spam-Status: No, score=-102.274 tagged_above=-999 required=5 tests=[AWL=0.325, 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 jpNYEoVGXb5z for ; Fri, 15 Jun 2012 11:26:51 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 1BEBA21F8498 for ; Fri, 15 Jun 2012 11:26:50 -0700 (PDT) Received: (qmail invoked by alias); 15 Jun 2012 18:26:48 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.112]) [88.115.216.191] by mail.gmx.net (mp027) with SMTP; 15 Jun 2012 20:26:48 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/Q9oJWZ+fQBhhTWN0/bJoSqc+BzKubieaup8jKTj q6RR6VbVDpN1jj Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943665393AB@TK5EX14MBXC284.redmond.corp.microsoft.com> Date: Fri, 15 Jun 2012 21:26:48 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <42B29A82-D8BA-40B8-9569-B209CBBBC3B7@gmx.net> <4E1F6AAD24975D4BA5B1680429673943665393AB@TK5EX14MBXC284.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Error Registry: Conclusion X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 18:26:52 -0000 Hi Mike,=20 thanks for raising this issue.=20 I am fine with the currently proposed approach. I just had a personal = preference for separate tables for readability purposes -- not a big = issue.=20 Ciao Hannes On Jun 15, 2012, at 12:40 AM, Mike Jones wrote: > Hi Hannes, >=20 > You stated a preference for separate registries below, but that was a = larger change to the OAuth Core spec than the current draft, which added = a fourth error usage location "resource access error response" to the = registry. To my knowledge, the consensus call didn't ask people to = express a preference between having four separate OAuth Errors = registries versus one OAuth Errors registry allowing any combination of = a set of four usage locations to be specified. >=20 > Given that the two choices are completely equivalent, and we had = previously established the single OAuth Errors registry with three = possible usage locations, extending it to a fourth seemed to be both = more natural and easier for people to understand. >=20 > Therefore, I'd like to ask you to withdraw your suggestion and allow = the existing structure of the OAuth Errors registry to remain. >=20 > Thank you, > -- Mike >=20 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf = Of Hannes Tschofenig > Sent: Tuesday, May 15, 2012 2:27 PM > To: oauth@ietf.org WG > Subject: [OAUTH-WG] Error Registry: Conclusion >=20 > Hi all,=20 >=20 > on May 8th we called for consensus on an open issue regarding the = location of the error registry. Here is the call for comments: = http://www.ietf.org/mail-archive/web/oauth/current/msg08952.html.=20 >=20 > Thank you all for the feedback. The consensus is to create the = registry in the core document. >=20 > Section 11.4.1 already sort-of creates sub-registries to illustrate = where the different errors can be used. This is needed since some of the = errors may only appear in certain error responses. Hence, we need add = another one to this list (suggestion: 'resource access error response'). = In fact, I would prefer IANA to create separate tables for each of these = sub-registries to avoid confusion for the reader (instead of putting = everything into a single table).=20 >=20 > We believe that these changes are really minor and address IESG = feedback. >=20 > Ciao > Hannes & Derek >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 From hannes.tschofenig@gmx.net Fri Jun 15 11:28:11 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5D1421F85A3 for ; Fri, 15 Jun 2012 11:28:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.339 X-Spam-Level: X-Spam-Status: No, score=-102.339 tagged_above=-999 required=5 tests=[AWL=0.260, 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 5TegI8jN416B for ; Fri, 15 Jun 2012 11:28:11 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 9792E21F859A for ; Fri, 15 Jun 2012 11:28:10 -0700 (PDT) Received: (qmail invoked by alias); 15 Jun 2012 18:28:09 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.112]) [88.115.216.191] by mail.gmx.net (mp027) with SMTP; 15 Jun 2012 20:28:09 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+ZwnhSrJyZrtGq2Tzaoro6M3F8Y9C7kqsKzJ0eBc VBdzufTs12V2zh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366539839@TK5EX14MBXC284.redmond.corp.microsoft.com> Date: Fri, 15 Jun 2012 21:28:07 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <3929B3F4-D3B3-4CAB-BB22-CFA5BFBBE8E5@gmx.net> References: <0CBAEB56DDB3A140BA8E8C124C04ECA201073394@P3PWEX2MB008.ex2.secureserver.net> <4E1F6AAD24975D4BA5B1680429673943665394D7@TK5EX14MBXC284.redmond.corp.microsoft.com> <0CBAEB56DDB3A140BA8E8C124C04ECA2010734C5@P3PWEX2MB008.ex2.secureserver.net> <0CBAEB56DDB3A140BA8E8C124C04ECA201073573@P3PWEX2MB008.ex2.secureserver.net> <4E1F6AAD24975D4BA5B168042967394366539839@TK5EX14MBXC284.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: "oauth@ietf.org WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Section 7.2 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 18:28:12 -0000 Hi Mike,=20 I personally would find it better to have fewer SHOULDs. Most of them = have been there for a long time and so it is a bit late to complain but = the challenge for protocol architectures is to figure out under what = conditions they should do certain things.=20 Additionally, I don't buy the argument that a server should not provide = error responses (or to be only very brief, or even misleading) for a = security point of view because attackers typically know more than = ordinary developers or users and so you end up with a system that the = normal user is unable to work with (in a failure case) but adversaries = nevertheless get what they want. This comment relates to the first = sentence that gives me the impression that the server may not send any = error message in case of a failure, which sounds strange to me.=20 Ciao Hannes On Jun 15, 2012, at 4:15 AM, Mike Jones wrote: > Thanks for writing the text below. It looks fine to me. About adding = the other error parameters as suggestions, that seems like a reasonable = thing to do. How about the text at the end below, which adds mentions = of error_description and error_uri? > =20 > 7.2. Error Response > =20 > If a resource access request fails, the resource server SHOULD = inform > the client of the error. While the specifics of such error = responses > are beyond the scope of this specification, this documents = establishes > a common registry for error values to be shared among OAuth token > authentication schemes. > =20 > New authentication schemes designed primarily for OAuth token > authentication SHOULD define a mechanism for providing an > error status code to the client, in which the error values allowed = are > registered in the error registry established by this specification. = Such > schemes MAY limit the set of valid error codes to a subset of the > registered values. If the error code is returned using a named = parameter, > the parameter name SHOULD be "error". > =20 > Other schemes capable of being used for OAuth token authentication, = but > not primarily designed for that purpose, MAY bind their error = values to the > registry in the same manner. > =20 > New authentication schemes MAY choose to also specify the use of = the > "error_description" and "error_uri" parameters to return error = information > in a manner parallel to their usage in this specification. > =20 > =20 > -- Mike > =20 > P.S. If you already have the text you wrote in a copy of the draft, = you should apply these spelling corrections: > desgined -> designed > authentiction -> authentication > =20 > -----Original Message----- > From: Eran Hammer [mailto:eran@hueniverse.com]=20 > Sent: Thursday, June 14, 2012 3:29 PM > To: Eran Hammer; Mike Jones; oauth@ietf.org WG (oauth@ietf.org) > Subject: RE: [OAUTH-WG] Section 7.2 > =20 > Mike - if you want to add the other error parameters as suggestions, = that would be fine by me. > =20 > EH > =20 > > -----Original Message----- > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf > > Of Eran Hammer > > Sent: Thursday, June 14, 2012 3:23 PM > > To: Mike Jones; oauth@ietf.org WG (oauth@ietf.org) > > Subject: Re: [OAUTH-WG] Section 7.2 > > > > 7.2. Error Response > > > > If a resource access request fails, the resource server SHOULD = inform > > the client of the error. While the specifics of such error = responses > > are beyond the scope of this specification, this documents = establishes > > a common registry for error values to be shared among OAuth token > > authentication schemes. > > > > New authentication schemes desgined primarily for OAuth token > > authentiction SHOULD define a mechanism for providing an > > error status code to the client, in which the error values = allowed are > > registered in the error registry established by this = specification. Such > > schemes MAY limit the set of valid error codes to a subset of the > > registered values. If the error code is returned using a named = parameter, > > the parameter name SHOULD be "error". > > > > Other schemes capable of being used for OAuth token = authentication, but > > not primarily designed for that purpose, MAY bind their error = values to the > > registry in the same manner. > > > > EH > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From Michael.Jones@microsoft.com Fri Jun 15 11:51:49 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B0A221F848F for ; Fri, 15 Jun 2012 11:51:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.699 X-Spam-Level: X-Spam-Status: No, score=-3.699 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jp83MFMWJCn0 for ; Fri, 15 Jun 2012 11:51:44 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe004.messaging.microsoft.com [213.199.154.207]) by ietfa.amsl.com (Postfix) with ESMTP id A363D21F8483 for ; Fri, 15 Jun 2012 11:51:43 -0700 (PDT) Received: from mail4-am1-R.bigfish.com (10.3.201.230) by AM1EHSOBE005.bigfish.com (10.3.204.25) with Microsoft SMTP Server id 14.1.225.23; Fri, 15 Jun 2012 18:50:31 +0000 Received: from mail4-am1 (localhost [127.0.0.1]) by mail4-am1-R.bigfish.com (Postfix) with ESMTP id 55E7C1E0134; Fri, 15 Jun 2012 18:50:31 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -31 X-BigFish: VS-31(zz98dI9371I14ffI148cI542M1432I4015Izz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25hf0ah) Received-SPF: pass (mail4-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC101.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail4-am1 (localhost.localdomain [127.0.0.1]) by mail4-am1 (MessageSwitch) id 1339786228157681_16900; Fri, 15 Jun 2012 18:50:28 +0000 (UTC) Received: from AM1EHSMHS001.bigfish.com (unknown [10.3.201.241]) by mail4-am1.bigfish.com (Postfix) with ESMTP id 1A68B160043; Fri, 15 Jun 2012 18:50:28 +0000 (UTC) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS001.bigfish.com (10.3.207.101) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 15 Jun 2012 18:50:26 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.53]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.02.0309.003; Fri, 15 Jun 2012 18:51:33 +0000 From: Mike Jones To: Hannes Tschofenig Thread-Topic: [OAUTH-WG] Error Registry: Conclusion Thread-Index: AQHNMuF2SEvCPjHVP0qi3ETkqD5Qwpb6hReggAFd/wCAAAacUA== Date: Fri, 15 Jun 2012 18:51:33 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436654F31D@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <42B29A82-D8BA-40B8-9569-B209CBBBC3B7@gmx.net> <4E1F6AAD24975D4BA5B1680429673943665393AB@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.33] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Error Registry: Conclusion X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 18:51:49 -0000 Thanks, Hannes. I believe that leaves the particulars of the ABNF and poss= ible encoding of client_id values containing colon for use with HTTP Basic = as the only open issues for Core. -- Mike -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 Sent: Friday, June 15, 2012 11:27 AM To: Mike Jones Cc: Hannes Tschofenig; oauth@ietf.org WG Subject: Re: [OAUTH-WG] Error Registry: Conclusion Hi Mike,=20 thanks for raising this issue.=20 I am fine with the currently proposed approach. I just had a personal prefe= rence for separate tables for readability purposes -- not a big issue.=20 Ciao Hannes On Jun 15, 2012, at 12:40 AM, Mike Jones wrote: > Hi Hannes, >=20 > You stated a preference for separate registries below, but that was a lar= ger change to the OAuth Core spec than the current draft, which added a fou= rth error usage location "resource access error response" to the registry. = To my knowledge, the consensus call didn't ask people to express a prefere= nce between having four separate OAuth Errors registries versus one OAuth E= rrors registry allowing any combination of a set of four usage locations to= be specified. >=20 > Given that the two choices are completely equivalent, and we had previous= ly established the single OAuth Errors registry with three possible usage l= ocations, extending it to a fourth seemed to be both more natural and easie= r for people to understand. >=20 > Therefore, I'd like to ask you to withdraw your suggestion and allow the = existing structure of the OAuth Errors registry to remain. >=20 > Thank you, > -- Mike >=20 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of= Hannes Tschofenig > Sent: Tuesday, May 15, 2012 2:27 PM > To: oauth@ietf.org WG > Subject: [OAUTH-WG] Error Registry: Conclusion >=20 > Hi all,=20 >=20 > on May 8th we called for consensus on an open issue regarding the locatio= n of the error registry. Here is the call for comments: http://www.ietf.org= /mail-archive/web/oauth/current/msg08952.html.=20 >=20 > Thank you all for the feedback. The consensus is to create the registry i= n the core document. >=20 > Section 11.4.1 already sort-of creates sub-registries to illustrate where= the different errors can be used. This is needed since some of the errors = may only appear in certain error responses. Hence, we need add another one = to this list (suggestion: 'resource access error response'). In fact, I wou= ld prefer IANA to create separate tables for each of these sub-registries t= o avoid confusion for the reader (instead of putting everything into a sing= le table).=20 >=20 > We believe that these changes are really minor and address IESG feedback. >=20 > Ciao > Hannes & Derek >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 From jricher@mitre.org Fri Jun 15 11:53:34 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC46711E80BE for ; Fri, 15 Jun 2012 11:53:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.398 X-Spam-Level: X-Spam-Status: No, score=-6.398 tagged_above=-999 required=5 tests=[AWL=0.200, 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 BxChu4dUxXvb for ; Fri, 15 Jun 2012 11:53:31 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id BF06311E809F for ; Fri, 15 Jun 2012 11:53:30 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 4102B21B1B19; Fri, 15 Jun 2012 14:53:30 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 30C5F21B15C8; Fri, 15 Jun 2012 14:53:30 -0400 (EDT) Received: from [129.83.50.12] (129.83.31.51) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.2.283.3; Fri, 15 Jun 2012 14:53:30 -0400 Message-ID: <4FDB8499.2050808@mitre.org> Date: Fri, 15 Jun 2012 14:53:13 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Mike Jones References: <9dbeab60-8fe4-4828-9c52-d7af95378f4c@email.android.com> <0ec59f35-4a66-4719-adf3-114dab0d1d48@email.android.com> <40240328-0247-4278-BB7B-BE89AE130076@ve7jtb.com> <4FDB593B.4080508@aol.com>, <4E1F6AAD24975D4BA5B16804296739436654ABB1@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739436654B001@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020904090308020202020900" X-Originating-IP: [129.83.31.51] Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion needed on username and password ABNF definitions X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 18:53:34 -0000 --------------020904090308020202020900 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit So it's been pointed out to me that percent encoding like this would break any clients that already have % in their client_id who are using the Basic auth. My question to the group is: how many of these are out there, really? Do we really have to worry about them? Right now, those are just hyptothetical, whereas clients with a : are real. Considering there already are (at the moment, technically noncompliant) clients using : who aren't using basic that we're definitely trying to support (otherwise this issue wouldn't be coming up), I would argue in favor of the known-existence side as opposed to the potential-existence side. Which is to say, use percent encoding (which is established and referenceable from another spec) and call it a day. What *really* bothers me about the strawman proposal is that it's making up a new, arbitrary encoding mechanism for one corner case. This is such a tiny and oddly specific-to-OAuth2 thing that my gut instinct tells me this is going to be either: 1) ignored 2) implemented wrong 3) coupled with some other encoding mechanism for people who want to do other things like internationalization -- Justin On 06/15/2012 02:15 PM, Justin Richer wrote: > Why not percent encoding for just colon and percent? > > -- Justin > > On 06/15/2012 01:30 PM, Mike Jones wrote: >> >> I was asked a question off-list, which I think is worth answering >> on-line. The question was: Why the Tab character, rather than >> %-encoding? >> >> Introducing % encoding would break all existing OAuth 2.0 deployments >> using HTTP Basic. A non-starter... >> >> Tab is legal in HTTP Basic but not in URLs or presently client_ids. >> It's also a character that can be visibly rendered in an acceptable >> manner for debugging. The other choices were CR and LF, which are >> also legal in HTTP Basic but wouldn't render very nicely. ;-) >> >> Cheers, >> >> -- Mike >> >> *From:*Mike Jones >> *Sent:* Friday, June 15, 2012 9:30 AM >> *To:* 'Eran Hammer' >> *Cc:* George Fletcher; oauth@ietf.org >> *Subject:* RE: [OAUTH-WG] Dynamic clients, URI, and stuff Re: >> Discussion needed on username and password ABNF definitions >> >> I agree with Eran that I prefer that this not be underspecified and >> that an encoding for just colon for just Basic will suffice. >> >> I'd suggested the encoding s/://g as a strawman. Are there any >> other encoding proposals? >> >> -- Mike >> >> *From:*Eran Hammer [mailto:eran@hueniverse.com] >> >> *Sent:* Friday, June 15, 2012 9:26 AM >> *To:* Mike Jones >> *Cc:* George Fletcher; oauth@ietf.org >> *Subject:* Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: >> Discussion needed on username and password ABNF definitions >> >> We should not leave this under specified. Picking an encoding for >> just Basic and just colon is simple enough. >> >> EH >> >> On Jun 15, 2012, at 19:17, "Mike Jones" > > wrote: >> >> Based on use cases I'm seeing, believe it's important to allow >> the use of URIs as client_id values (which means allowing ":" in >> the client_id string). I'm OK with us either specifying a >> specific encoding when using them in Basic or simply saying that >> "When client_ids are used with HTTP Basic that contain characters >> such as ":" not allowed in HTTP Basic usernames, then the >> participants will need to agree upon a method of encoding the >> client_id for use with HTTP Basic. >> >> -- Mike >> >> *From:*oauth-bounces@ietf.org >> [mailto:oauth-bounces@ietf.org] >> *On Behalf Of *George >> Fletcher >> *Sent:* Friday, June 15, 2012 8:48 AM >> *To:* oauth@ietf.org >> *Subject:* Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: >> Discussion needed on username and password ABNF definitions >> >> +1 for a simple encoding and allowing ':' in the client_id >> >> On 6/13/12 6:53 PM, Amos Jeffries wrote: >> >> On 14.06.2012 06:40, John Bradley wrote: >> >> That would probably work as well. That is why I am not particularly >> concerned about excluding the : >> >> We originally used the URI itself, mostly for convenience of >> debugging, but there are other potential options. >> >> The authorization server needs to compare the client_id and the >> redirect uri. But it could compare the hash with not much more work. >> Also a sha256 hash is probably longer than the uri it is hashing. >> >> I am not super concerned with being able to have : in the client_id >> >> John B. >> >> >> >> If I'm following all these threads correctly the only explicit >> problem with URI in client_id is HTTP username field being : >> terminated. >> As such it does not have to be a hash per-se, just an encoding >> that removes ":" and other reserved characters from the on-wire >> form *when sent via HTTP*. >> >> AYJ >> >> _______________________________________________ >> OAuth mailing 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 --------------020904090308020202020900 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit So it's been pointed out to me that percent encoding like this would break any clients that already have % in their client_id who are using the Basic auth. My question to the group is: how many of these are out there, really? Do we really have to worry about them? Right now, those are just hyptothetical, whereas clients with a : are real.

Considering there already are (at the moment, technically noncompliant) clients using : who aren't using basic that we're definitely trying to support (otherwise this issue wouldn't be coming up), I would argue in favor of the known-existence side as opposed to the potential-existence side. Which is to say, use percent encoding (which is established and referenceable from another spec) and call it a day.

What *really* bothers me about the strawman proposal is that it's making up a new, arbitrary encoding mechanism for one corner case. This is such a tiny and oddly specific-to-OAuth2 thing that my gut instinct tells me this is going to be either:
  1) ignored
  2) implemented wrong
  3) coupled with some other encoding mechanism for people who want to do other things like internationalization

 -- Justin

On 06/15/2012 02:15 PM, Justin Richer wrote:
Why not percent encoding for just colon and percent?

 -- Justin

On 06/15/2012 01:30 PM, Mike Jones wrote:

I was asked a question off-list, which I think is worth answering on-line.  The question was:  Why the Tab character, rather than %-encoding?

 

Introducing % encoding would break all existing OAuth 2.0 deployments using HTTP Basic.  A non-starter…

 

Tab is legal in HTTP Basic but not in URLs or presently client_ids.  It’s also a character that can be visibly rendered in an acceptable manner for debugging.  The other choices were CR and LF, which are also legal in HTTP Basic but wouldn’t render very nicely. ;-)

 

                                                            Cheers,

                                                            -- Mike

 

From: Mike Jones
Sent: Friday, June 15, 2012 9:30 AM
To: 'Eran Hammer'
Cc: George Fletcher; oauth@ietf.org
Subject: RE: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion needed on username and password ABNF definitions

 

I agree with Eran that I prefer that this not be underspecified and that an encoding for just colon for just Basic will suffice.

 

I’d suggested the encoding s/:/<tab>/g as a strawman.  Are there any other encoding proposals?

 

                                                            -- Mike

 

From: Eran Hammer [mailto:eran@hueniverse.com]
Sent: Friday, June 15, 2012 9:26 AM
To: Mike Jones
Cc: George Fletcher; oauth@ietf.org
Subject: Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion needed on username and password ABNF definitions

 

We should not leave this under specified. Picking an encoding for just Basic and just colon is simple enough. 

 

EH

On Jun 15, 2012, at 19:17, "Mike Jones" <Michael.Jones@microsoft.com> wrote:

Based on use cases I’m seeing, believe it’s important to allow the use of URIs as client_id values (which means allowing “:” in the client_id string).  I’m OK with us either specifying a specific encoding when using them in Basic or simply saying that “When client_ids are used with HTTP Basic that contain characters such as “:” not allowed in HTTP Basic usernames, then the participants will need to agree upon a method of encoding the client_id for use with HTTP Basic.

 

                                                            -- Mike

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of George Fletcher
Sent: Friday, June 15, 2012 8:48 AM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion needed on username and password ABNF definitions

 

+1 for a simple encoding and allowing ':' in the client_id

On 6/13/12 6:53 PM, Amos Jeffries wrote:

On 14.06.2012 06:40, John Bradley wrote:

That would probably work as well.  That is why I am not particularly
concerned about excluding the :

We originally used the URI itself,  mostly for convenience of
debugging,  but there are other potential options.

The authorization server needs to compare the client_id and the
redirect uri. But it could compare the hash with not much more work.
Also a sha256 hash is probably longer than the uri it is hashing.

I am not super concerned with being able to have : in the client_id

John B.



If I'm following all these threads correctly the only explicit problem with URI in client_id is HTTP username field being : terminated.
As such it does not have to be a hash per-se, just an encoding that removes ":" and other reserved characters from the on-wire form *when sent via HTTP*.

AYJ

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

--------------020904090308020202020900-- From Michael.Jones@microsoft.com Fri Jun 15 11:54:32 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21B2711E809F for ; Fri, 15 Jun 2012 11:54:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.192 X-Spam-Level: X-Spam-Status: No, score=-5.192 tagged_above=-999 required=5 tests=[AWL=1.406, 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 5j0R-LNXC0ON for ; Fri, 15 Jun 2012 11:54:30 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe006.messaging.microsoft.com [216.32.180.16]) by ietfa.amsl.com (Postfix) with ESMTP id DEF0B11E8091 for ; Fri, 15 Jun 2012 11:54:29 -0700 (PDT) Received: from mail13-va3-R.bigfish.com (10.7.14.243) by VA3EHSOBE009.bigfish.com (10.7.40.29) with Microsoft SMTP Server id 14.1.225.23; Fri, 15 Jun 2012 18:53:18 +0000 Received: from mail13-va3 (localhost [127.0.0.1]) by mail13-va3-R.bigfish.com (Postfix) with ESMTP id 4FFC11603B1 for ; Fri, 15 Jun 2012 18:53:18 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: 0 X-BigFish: VS0(zzc89bhc85dhzz1202hzz8275bh8275dhz2fh2a8h668h839hd25hf0ah) Received-SPF: pass (mail13-va3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail13-va3 (localhost.localdomain [127.0.0.1]) by mail13-va3 (MessageSwitch) id 1339786396177975_15024; Fri, 15 Jun 2012 18:53:16 +0000 (UTC) Received: from VA3EHSMHS003.bigfish.com (unknown [10.7.14.237]) by mail13-va3.bigfish.com (Postfix) with ESMTP id 1E81C340049 for ; Fri, 15 Jun 2012 18:53:16 +0000 (UTC) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS003.bigfish.com (10.7.99.13) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 15 Jun 2012 18:53:14 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.53]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.02.0309.003; Fri, 15 Jun 2012 18:54:18 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: Name spelling nit in acknowledgments Thread-Index: Ac1LKEBn8xldisHMRP+rIm1TsQ1m5w== Date: Fri, 15 Jun 2012 18:54:17 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436654F355@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_4E1F6AAD24975D4BA5B16804296739436654F355TK5EX14MBXC283r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: [OAUTH-WG] Name spelling nit in acknowledgments X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 18:54:32 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436654F355TK5EX14MBXC283r_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Bearer acknowledges Bill de h=D3ra. Core acknowledges Bill de hOra. Which= is correct? -- Mike --_000_4E1F6AAD24975D4BA5B16804296739436654F355TK5EX14MBXC283r_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Bearer acknowledges Bill de h=D3ra.  Core acknowledges Bill de hOra.  Which is correct?

 

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

 

--_000_4E1F6AAD24975D4BA5B16804296739436654F355TK5EX14MBXC283r_-- From Michael.Jones@microsoft.com Fri Jun 15 11:58:32 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB0CB21F8517 for ; Fri, 15 Jun 2012 11:58:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.775 X-Spam-Level: X-Spam-Status: No, score=-3.775 tagged_above=-999 required=5 tests=[AWL=-0.177, 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 pxJUeZx5TV+V for ; Fri, 15 Jun 2012 11:58:29 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe006.messaging.microsoft.com [213.199.154.209]) by ietfa.amsl.com (Postfix) with ESMTP id 64DCF21F851B for ; Fri, 15 Jun 2012 11:58:28 -0700 (PDT) Received: from mail31-am1-R.bigfish.com (10.3.201.227) by AM1EHSOBE006.bigfish.com (10.3.204.26) with Microsoft SMTP Server id 14.1.225.23; Fri, 15 Jun 2012 18:57:17 +0000 Received: from mail31-am1 (localhost [127.0.0.1]) by mail31-am1-R.bigfish.com (Postfix) with ESMTP id BA9C320634; Fri, 15 Jun 2012 18:57:16 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC106.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: VS-24(zzbb2dI98dI9371Ic85fh148cIzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25hf0ah) Received-SPF: pass (mail31-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC106.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail31-am1 (localhost.localdomain [127.0.0.1]) by mail31-am1 (MessageSwitch) id 1339786628586026_30549; Fri, 15 Jun 2012 18:57:08 +0000 (UTC) Received: from AM1EHSMHS014.bigfish.com (unknown [10.3.201.249]) by mail31-am1.bigfish.com (Postfix) with ESMTP id 8D204420061; Fri, 15 Jun 2012 18:57:08 +0000 (UTC) Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS014.bigfish.com (10.3.207.152) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 15 Jun 2012 18:57:07 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.53]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.02.0309.003; Fri, 15 Jun 2012 18:58:01 +0000 From: Mike Jones To: Justin Richer Thread-Topic: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion needed on username and password ABNF definitions Thread-Index: AQHNSw5aQ+07XirTWkeEJ2jRd0gB45b7jZDwgAADgx2AAAA4oIAAERNwgAAX256AAABvcA== Date: Fri, 15 Jun 2012 18:58:01 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436654F381@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <9dbeab60-8fe4-4828-9c52-d7af95378f4c@email.android.com> <0ec59f35-4a66-4719-adf3-114dab0d1d48@email.android.com> <40240328-0247-4278-BB7B-BE89AE130076@ve7jtb.com> <4FDB593B.4080508@aol.com>, <4E1F6AAD24975D4BA5B16804296739436654ABB1@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739436654B001@TK5EX14MBXC283.redmond.corp.microsoft.com> <4FDB8499.2050808@mitre.org> In-Reply-To: <4FDB8499.2050808@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_4E1F6AAD24975D4BA5B16804296739436654F381TK5EX14MBXC283r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion needed on username and password ABNF definitions X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 18:58:32 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436654F381TK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Justin, it's a useful data point that you already have clients with colon (= ":") in client_id values (that work because you aren't using HTTP Basic). = Thanks for letting us know that. For the record, I'd be fine if the working group decided that %-encoding of= client_id values when used with HTTP Basic was the right thing to do. The= Tab strawman was intended to break as few implementations as possible, but= I fully recognize that the set of implementations broken by using % for %-= encoding may well be the empty set. Other's thoughts? Cheers, -- Mike From: Justin Richer [mailto:jricher@mitre.org] Sent: Friday, June 15, 2012 11:53 AM To: Mike Jones Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion need= ed on username and password ABNF definitions So it's been pointed out to me that percent encoding like this would break = any clients that already have % in their client_id who are using the Basic = auth. My question to the group is: how many of these are out there, really?= Do we really have to worry about them? Right now, those are just hyptothet= ical, whereas clients with a : are real. Considering there already are (at the moment, technically noncompliant) cli= ents using : who aren't using basic that we're definitely trying to support= (otherwise this issue wouldn't be coming up), I would argue in favor of th= e known-existence side as opposed to the potential-existence side. Which is= to say, use percent encoding (which is established and referenceable from = another spec) and call it a day. What *really* bothers me about the strawman proposal is that it's making up= a new, arbitrary encoding mechanism for one corner case. This is such a ti= ny and oddly specific-to-OAuth2 thing that my gut instinct tells me this is= going to be either: 1) ignored 2) implemented wrong 3) coupled with some other encoding mechanism for people who want to do o= ther things like internationalization -- Justin On 06/15/2012 02:15 PM, Justin Richer wrote: Why not percent encoding for just colon and percent? -- Justin On 06/15/2012 01:30 PM, Mike Jones wrote: I was asked a question off-list, which I think is worth answering on-line. = The question was: Why the Tab character, rather than %-encoding? Introducing % encoding would break all existing OAuth 2.0 deployments using= HTTP Basic. A non-starter... Tab is legal in HTTP Basic but not in URLs or presently client_ids. It's a= lso a character that can be visibly rendered in an acceptable manner for de= bugging. The other choices were CR and LF, which are also legal in HTTP Ba= sic but wouldn't render very nicely. ;-) Cheers, -- Mike From: Mike Jones Sent: Friday, June 15, 2012 9:30 AM To: 'Eran Hammer' Cc: George Fletcher; oauth@ietf.org Subject: RE: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion need= ed on username and password ABNF definitions I agree with Eran that I prefer that this not be underspecified and that an= encoding for just colon for just Basic will suffice. I'd suggested the encoding s/://g as a strawman. Are there any other = encoding proposals? -- Mike From: Eran Hammer [mailto:eran@hueniverse.com] Sent: Friday, June 15, 2012 9:26 AM To: Mike Jones Cc: George Fletcher; oauth@ietf.org Subject: Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion need= ed on username and password ABNF definitions We should not leave this under specified. Picking an encoding for just Basi= c and just colon is simple enough. EH On Jun 15, 2012, at 19:17, "Mike Jones" > wrote: Based on use cases I'm seeing, believe it's important to allow the use of U= RIs as client_id values (which means allowing ":" in the client_id string).= I'm OK with us either specifying a specific encoding when using them in B= asic or simply saying that "When client_ids are used with HTTP Basic that c= ontain characters such as ":" not allowed in HTTP Basic usernames, then the= participants will need to agree upon a method of encoding the client_id fo= r use with HTTP Basic. -- Mike From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Georg= e Fletcher Sent: Friday, June 15, 2012 8:48 AM To: oauth@ietf.org Subject: Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion need= ed on username and password ABNF definitions +1 for a simple encoding and allowing ':' in the client_id On 6/13/12 6:53 PM, Amos Jeffries wrote: On 14.06.2012 06:40, John Bradley wrote: That would probably work as well. That is why I am not particularly concerned about excluding the : We originally used the URI itself, mostly for convenience of debugging, but there are other potential options. The authorization server needs to compare the client_id and the redirect uri. But it could compare the hash with not much more work. Also a sha256 hash is probably longer than the uri it is hashing. I am not super concerned with being able to have : in the client_id John B. If I'm following all these threads correctly the only explicit problem with= URI in client_id is HTTP username field being : terminated. As such it does not have to be a hash per-se, just an encoding that removes= ":" and other reserved characters from the on-wire form *when sent via HTT= P*. AYJ _______________________________________________ OAuth mailing 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_4E1F6AAD24975D4BA5B16804296739436654F381TK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Justin, it’s a usef= ul data point that you already have clients with colon (“:”) in= client_id values (that work because you aren’t using HTTP Basic).&nb= sp; Thanks for letting us know that.

 <= /p>

For the record, I’d= be fine if the working group decided that %-encoding of client_id values w= hen used with HTTP Basic was the right thing to do.  The Tab strawman was intended to break as few implementations as possible, but I fully reco= gnize that the set of implementations broken by using % for %-encoding may = well be the empty set.

 <= /p>

Other’s thoughts?

 <= /p>

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

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

 <= /p>

From: Justin Richer [mailto:jricher@mitre.org]
Sent: Friday, June 15, 2012 11:53 AM
To: Mike Jones
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussi= on needed on username and password ABNF definitions

 

So it's been pointed out to me that percent encoding= like this would break any clients that already have % in their client_id w= ho are using the Basic auth. My question to the group is: how many of these= are out there, really? Do we really have to worry about them? Right now, those are just hyptothetical, whereas= clients with a : are real.

Considering there already are (at the moment, technically noncompliant) cli= ents using : who aren't using basic that we're definitely trying to support= (otherwise this issue wouldn't be coming up), I would argue in favor of th= e known-existence side as opposed to the potential-existence side. Which is to say, use percent encoding (wh= ich is established and referenceable from another spec) and call it a day.

What *really* bothers me about the strawman proposal is that it's making up= a new, arbitrary encoding mechanism for one corner case. This is such a ti= ny and oddly specific-to-OAuth2 thing that my gut instinct tells me this is= going to be either:
  1) ignored
  2) implemented wrong
  3) coupled with some other encoding mechanism for people who want to= do other things like internationalization

 -- Justin

On 06/15/2012 02:15 PM, Justin Richer wrote:

Why not percent encoding for just colon and percent?=

 -- Justin

On 06/15/2012 01:30 PM, Mike Jones wrote:

I was asked a question of= f-list, which I think is worth answering on-line.  The question was: &= nbsp;Why the Tab character, rather than %-encoding?

 <= /p>

Introducing % encoding wo= uld break all existing OAuth 2.0 deployments using HTTP Basic.  A non-= starter…

 <= /p>

Tab is legal in HTTP Basi= c but not in URLs or presently client_ids.  It’s also a characte= r that can be visibly rendered in an acceptable manner for debugging.  The other choices were CR and LF, which are also legal in HTTP Basic but w= ouldn’t render very nicely. ;-)

 <= /p>

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

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

 <= /p>

From: Mike Jones
Sent: Friday, June 15, 2012 9:30 AM
To: 'Eran Hammer'
Cc: George Fletcher; oauth@ietf.or= g
Subject: RE: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussi= on needed on username and password ABNF definitions

 

I agree with Eran that I = prefer that this not be underspecified and that an encoding for just colon = for just Basic will suffice.

 <= /p>

I’d suggested the e= ncoding s/:/<tab>/g as a strawman.  Are there any other encoding= proposals?

 <= /p>

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

 <= /p>

From: Eran Hammer [mailto:eran@hueniverse.com= ]
Sent: Friday, June 15, 2012 9:26 AM
To: Mike Jones
Cc: George Fletcher; oauth@ietf.or= g
Subject: Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussi= on needed on username and password ABNF definitions

 

We should not leave this under specified. Picking an= encoding for just Basic and just colon is simple enough. <= /p>

 

EH

On Jun 15, 2012, at 19:17, "Mike Jones" <Michael.Jones@microsoft.com> wrote:

Based on use cases I̵= 7;m seeing, believe it’s important to allow the use of URIs as client= _id values (which means allowing “:” in the client_id string).&= nbsp; I’m OK with us either specifying a specific encoding when using them in Basic = or simply saying that “When client_ids are used with HTTP Basic that = contain characters such as “:” not allowed in HTTP Basic userna= mes, then the participants will need to agree upon a method of encoding the client_id for use with HTTP Basic.

 <= /p>

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

 <= /p>

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of George Fletcher
Sent: Friday, June 15, 2012 8:48 AM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussi= on needed on username and password ABNF definitions

 

+1 for a simple encoding and allowing ':' in the c= lient_id

On 6/13/12 6:53 PM, Amos Jeffries wrote:

On 14.06.2012 06:40, = John Bradley wrote:


That would probably w= ork as well.  That is why I am not particularly
concerned about excluding the :

We originally used the URI itself,  mostly for convenience of
debugging,  but there are other potential options.

The authorization server needs to compare the client_id and the
redirect uri. But it could compare the hash with not much more work.
Also a sha256 hash is probably longer than the uri it is hashing.

I am not super concerned with being able to have : in the client_id

John B.



If I'm following all these threads correctly the only explicit problem with= URI in client_id is HTTP username field being : terminated.
As such it does not have to be a hash per-se, just an encoding that removes= ":" and other reserved characters from the on-wire form *when se= nt via HTTP*.

AYJ

_______________________________________________
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




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





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

 

--_000_4E1F6AAD24975D4BA5B16804296739436654F381TK5EX14MBXC283r_-- From jricher@mitre.org Fri Jun 15 11:59:53 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AD4221F851B for ; Fri, 15 Jun 2012 11:59:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.448 X-Spam-Level: X-Spam-Status: No, score=-6.448 tagged_above=-999 required=5 tests=[AWL=0.150, 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 b2+LiAxRlaVd for ; Fri, 15 Jun 2012 11:59:50 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 6C10021F8517 for ; Fri, 15 Jun 2012 11:59:50 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 1A98C21B1B28; Fri, 15 Jun 2012 14:59:50 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id F20BB21B1B1C; Fri, 15 Jun 2012 14:59:49 -0400 (EDT) Received: from [129.83.50.12] (129.83.31.51) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.2.283.3; Fri, 15 Jun 2012 14:59:49 -0400 Message-ID: <4FDB8614.502@mitre.org> Date: Fri, 15 Jun 2012 14:59:32 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Mike Jones References: <9dbeab60-8fe4-4828-9c52-d7af95378f4c@email.android.com> <0ec59f35-4a66-4719-adf3-114dab0d1d48@email.android.com> <40240328-0247-4278-BB7B-BE89AE130076@ve7jtb.com> <4FDB593B.4080508@aol.com>, <4E1F6AAD24975D4BA5B16804296739436654ABB1@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739436654B001@TK5EX14MBXC283.redmond.corp.microsoft.com> <4FDB8499.2050808@mitre.org> <4E1F6AAD24975D4BA5B16804296739436654F381@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436654F381@TK5EX14MBXC283.redmond.corp.microsoft.com> Content-Type: multipart/alternative; boundary="------------050503080607070908090202" X-Originating-IP: [129.83.31.51] Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion needed on username and password ABNF definitions X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 18:59:53 -0000 --------------050503080607070908090202 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Just to clarify, I was actually referring to the self-issued OpenID Connect clients that Nat and others have been working on that sparked this discussion of the utility of colon, not ones that we have here locally in our implementations. -- Justin On 06/15/2012 02:58 PM, Mike Jones wrote: > > Justin, it's a useful data point that you already have clients with > colon (":") in client_id values (that work because you aren't using > HTTP Basic). Thanks for letting us know that. > > For the record, I'd be fine if the working group decided that > %-encoding of client_id values when used with HTTP Basic was the right > thing to do. The Tab strawman was intended to break as few > implementations as possible, but I fully recognize that the set of > implementations broken by using % for %-encoding may well be the empty > set. > > Other's thoughts? > > Cheers, > > -- Mike > > *From:*Justin Richer [mailto:jricher@mitre.org] > *Sent:* Friday, June 15, 2012 11:53 AM > *To:* Mike Jones > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: > Discussion needed on username and password ABNF definitions > > So it's been pointed out to me that percent encoding like this would > break any clients that already have % in their client_id who are using > the Basic auth. My question to the group is: how many of these are out > there, really? Do we really have to worry about them? Right now, those > are just hyptothetical, whereas clients with a : are real. > > Considering there already are (at the moment, technically > noncompliant) clients using : who aren't using basic that we're > definitely trying to support (otherwise this issue wouldn't be coming > up), I would argue in favor of the known-existence side as opposed to > the potential-existence side. Which is to say, use percent encoding > (which is established and referenceable from another spec) and call it > a day. > > What *really* bothers me about the strawman proposal is that it's > making up a new, arbitrary encoding mechanism for one corner case. > This is such a tiny and oddly specific-to-OAuth2 thing that my gut > instinct tells me this is going to be either: > 1) ignored > 2) implemented wrong > 3) coupled with some other encoding mechanism for people who want to > do other things like internationalization > > -- Justin > > On 06/15/2012 02:15 PM, Justin Richer wrote: > > Why not percent encoding for just colon and percent? > > -- Justin > > On 06/15/2012 01:30 PM, Mike Jones wrote: > > I was asked a question off-list, which I think is worth answering > on-line. The question was: Why the Tab character, rather than > %-encoding? > > Introducing % encoding would break all existing OAuth 2.0 deployments > using HTTP Basic. A non-starter... > > Tab is legal in HTTP Basic but not in URLs or presently client_ids. > It's also a character that can be visibly rendered in an acceptable > manner for debugging. The other choices were CR and LF, which are > also legal in HTTP Basic but wouldn't render very nicely. ;-) > > Cheers, > > -- Mike > > *From:*Mike Jones > *Sent:* Friday, June 15, 2012 9:30 AM > *To:* 'Eran Hammer' > *Cc:* George Fletcher; oauth@ietf.org > *Subject:* RE: [OAUTH-WG] Dynamic clients, URI, and stuff Re: > Discussion needed on username and password ABNF definitions > > I agree with Eran that I prefer that this not be underspecified and > that an encoding for just colon for just Basic will suffice. > > I'd suggested the encoding s/://g as a strawman. Are there any > other encoding proposals? > > -- Mike > > *From:*Eran Hammer [mailto:eran@hueniverse.com] > > *Sent:* Friday, June 15, 2012 9:26 AM > *To:* Mike Jones > *Cc:* George Fletcher; oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: > Discussion needed on username and password ABNF definitions > > We should not leave this under specified. Picking an encoding for just > Basic and just colon is simple enough. > > EH > > On Jun 15, 2012, at 19:17, "Mike Jones" > wrote: > > Based on use cases I'm seeing, believe it's important to allow the > use of URIs as client_id values (which means allowing ":" in the > client_id string). I'm OK with us either specifying a specific > encoding when using them in Basic or simply saying that "When > client_ids are used with HTTP Basic that contain characters such > as ":" not allowed in HTTP Basic usernames, then the participants > will need to agree upon a method of encoding the client_id for use > with HTTP Basic. > > -- Mike > > *From:*oauth-bounces@ietf.org > [mailto:oauth-bounces@ietf.org] > *On Behalf Of *George > Fletcher > *Sent:* Friday, June 15, 2012 8:48 AM > *To:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: > Discussion needed on username and password ABNF definitions > > +1 for a simple encoding and allowing ':' in the client_id > > On 6/13/12 6:53 PM, Amos Jeffries wrote: > > On 14.06.2012 06:40, John Bradley wrote: > > > That would probably work as well. That is why I am not particularly > concerned about excluding the : > > We originally used the URI itself, mostly for convenience of > debugging, but there are other potential options. > > The authorization server needs to compare the client_id and the > redirect uri. But it could compare the hash with not much more work. > Also a sha256 hash is probably longer than the uri it is hashing. > > I am not super concerned with being able to have : in the client_id > > John B. > > > > If I'm following all these threads correctly the only explicit > problem with URI in client_id is HTTP username field being : > terminated. > As such it does not have to be a hash per-se, just an encoding > that removes ":" and other reserved characters from the on-wire > form *when sent via HTTP*. > > AYJ > > _______________________________________________ > OAuth mailing 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 > --------------050503080607070908090202 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Just to clarify, I was actually referring to the self-issued OpenID Connect clients that Nat and others have been working on that sparked this discussion of the utility of colon, not ones that we have here locally in our implementations.

 -- Justin

On 06/15/2012 02:58 PM, Mike Jones wrote:

Justin, it’s a useful data point that you already have clients with colon (“:”) in client_id values (that work because you aren’t using HTTP Basic).  Thanks for letting us know that.

 

For the record, I’d be fine if the working group decided that %-encoding of client_id values when used with HTTP Basic was the right thing to do.  The Tab strawman was intended to break as few implementations as possible, but I fully recognize that the set of implementations broken by using % for %-encoding may well be the empty set.

 

Other’s thoughts?

 

                                                            Cheers,

                                                            -- Mike

 

From: Justin Richer [mailto:jricher@mitre.org]
Sent: Friday, June 15, 2012 11:53 AM
To: Mike Jones
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion needed on username and password ABNF definitions

 

So it's been pointed out to me that percent encoding like this would break any clients that already have % in their client_id who are using the Basic auth. My question to the group is: how many of these are out there, really? Do we really have to worry about them? Right now, those are just hyptothetical, whereas clients with a : are real.

Considering there already are (at the moment, technically noncompliant) clients using : who aren't using basic that we're definitely trying to support (otherwise this issue wouldn't be coming up), I would argue in favor of the known-existence side as opposed to the potential-existence side. Which is to say, use percent encoding (which is established and referenceable from another spec) and call it a day.

What *really* bothers me about the strawman proposal is that it's making up a new, arbitrary encoding mechanism for one corner case. This is such a tiny and oddly specific-to-OAuth2 thing that my gut instinct tells me this is going to be either:
  1) ignored
  2) implemented wrong
  3) coupled with some other encoding mechanism for people who want to do other things like internationalization

 -- Justin

On 06/15/2012 02:15 PM, Justin Richer wrote:

Why not percent encoding for just colon and percent?

 -- Justin

On 06/15/2012 01:30 PM, Mike Jones wrote:

I was asked a question off-list, which I think is worth answering on-line.  The question was:  Why the Tab character, rather than %-encoding?

 

Introducing % encoding would break all existing OAuth 2.0 deployments using HTTP Basic.  A non-starter…

 

Tab is legal in HTTP Basic but not in URLs or presently client_ids.  It’s also a character that can be visibly rendered in an acceptable manner for debugging.  The other choices were CR and LF, which are also legal in HTTP Basic but wouldn’t render very nicely. ;-)

 

                                                            Cheers,

                                                            -- Mike

 

From: Mike Jones
Sent: Friday, June 15, 2012 9:30 AM
To: 'Eran Hammer'
Cc: George Fletcher; oauth@ietf.org
Subject: RE: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion needed on username and password ABNF definitions

 

I agree with Eran that I prefer that this not be underspecified and that an encoding for just colon for just Basic will suffice.

 

I’d suggested the encoding s/:/<tab>/g as a strawman.  Are there any other encoding proposals?

 

                                                            -- Mike

 

From: Eran Hammer [mailto:eran@hueniverse.com]
Sent: Friday, June 15, 2012 9:26 AM
To: Mike Jones
Cc: George Fletcher; oauth@ietf.org
Subject: Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion needed on username and password ABNF definitions

 

We should not leave this under specified. Picking an encoding for just Basic and just colon is simple enough. 

 

EH

On Jun 15, 2012, at 19:17, "Mike Jones" <Michael.Jones@microsoft.com> wrote:

Based on use cases I’m seeing, believe it’s important to allow the use of URIs as client_id values (which means allowing “:” in the client_id string).  I’m OK with us either specifying a specific encoding when using them in Basic or simply saying that “When client_ids are used with HTTP Basic that contain characters such as “:” not allowed in HTTP Basic usernames, then the participants will need to agree upon a method of encoding the client_id for use with HTTP Basic.

 

                                                            -- Mike

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of George Fletcher
Sent: Friday, June 15, 2012 8:48 AM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion needed on username and password ABNF definitions

 

+1 for a simple encoding and allowing ':' in the client_id

On 6/13/12 6:53 PM, Amos Jeffries wrote:

On 14.06.2012 06:40, John Bradley wrote:


That would probably work as well.  That is why I am not particularly
concerned about excluding the :

We originally used the URI itself,  mostly for convenience of
debugging,  but there are other potential options.

The authorization server needs to compare the client_id and the
redirect uri. But it could compare the hash with not much more work.
Also a sha256 hash is probably longer than the uri it is hashing.

I am not super concerned with being able to have : in the client_id

John B.



If I'm following all these threads correctly the only explicit problem with URI in client_id is HTTP username field being : terminated.
As such it does not have to be a hash per-se, just an encoding that removes ":" and other reserved characters from the on-wire form *when sent via HTTP*.

AYJ

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

 


--------------050503080607070908090202-- From Michael.Jones@microsoft.com Fri Jun 15 12:06:56 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FED521F8541 for ; Fri, 15 Jun 2012 12:06:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.765 X-Spam-Level: X-Spam-Status: No, score=-3.765 tagged_above=-999 required=5 tests=[AWL=-0.166, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jscfh53Ljxi2 for ; Fri, 15 Jun 2012 12:06:55 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe004.messaging.microsoft.com [216.32.181.184]) by ietfa.amsl.com (Postfix) with ESMTP id 1CC9D21F8540 for ; Fri, 15 Jun 2012 12:06:55 -0700 (PDT) Received: from mail229-ch1-R.bigfish.com (10.43.68.250) by CH1EHSOBE018.bigfish.com (10.43.70.68) with Microsoft SMTP Server id 14.1.225.23; Fri, 15 Jun 2012 19:05:42 +0000 Received: from mail229-ch1 (localhost [127.0.0.1]) by mail229-ch1-R.bigfish.com (Postfix) with ESMTP id 9CDC7F4044C; Fri, 15 Jun 2012 19:05:42 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -29 X-BigFish: VS-29(zz98dI9371I148cI542M1432Izz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25hf0ah) Received-SPF: pass (mail229-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC107.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail229-ch1 (localhost.localdomain [127.0.0.1]) by mail229-ch1 (MessageSwitch) id 1339787140194639_13327; Fri, 15 Jun 2012 19:05:40 +0000 (UTC) Received: from CH1EHSMHS020.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.229]) by mail229-ch1.bigfish.com (Postfix) with ESMTP id 231471440046; Fri, 15 Jun 2012 19:05:40 +0000 (UTC) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS020.bigfish.com (10.43.70.20) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 15 Jun 2012 19:05:38 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.53]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.02.0309.003; Fri, 15 Jun 2012 19:06:34 +0000 From: Mike Jones To: Hannes Tschofenig Thread-Topic: [OAUTH-WG] Section 7.2 Thread-Index: AQHNSnlK4rMFHIKNpEG6QNgV8mtEhJb6Y6gAgAABoQCAACqMcIABJHCAgAAKNEA= Date: Fri, 15 Jun 2012 19:06:33 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436654F446@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <0CBAEB56DDB3A140BA8E8C124C04ECA201073394@P3PWEX2MB008.ex2.secureserver.net> <4E1F6AAD24975D4BA5B1680429673943665394D7@TK5EX14MBXC284.redmond.corp.microsoft.com> <0CBAEB56DDB3A140BA8E8C124C04ECA2010734C5@P3PWEX2MB008.ex2.secureserver.net> <0CBAEB56DDB3A140BA8E8C124C04ECA201073573@P3PWEX2MB008.ex2.secureserver.net> <4E1F6AAD24975D4BA5B168042967394366539839@TK5EX14MBXC284.redmond.corp.microsoft.com> <3929B3F4-D3B3-4CAB-BB22-CFA5BFBBE8E5@gmx.net> In-Reply-To: <3929B3F4-D3B3-4CAB-BB22-CFA5BFBBE8E5@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.33] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "oauth@ietf.org WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Section 7.2 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 19:06:56 -0000 There are cases where the OAuth specs specifically *prohibit* returning an = error code or other error information, for security reasons. For instance,= http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-20#section-3.1 conta= ins the language: If the request lacks any authentication information (i.e. the client was unaware authentication is necessary or attempted using an unsupported authentication method), the resource server SHOULD NOT include an error code or other error information. Hence, the SHOULDs, rather than MUSTs. -- Mike -----Original Message----- From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net]=20 Sent: Friday, June 15, 2012 11:28 AM To: Mike Jones Cc: Hannes Tschofenig; Eran Hammer; oauth@ietf.org WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Section 7.2 Hi Mike,=20 I personally would find it better to have fewer SHOULDs. Most of them have = been there for a long time and so it is a bit late to complain but the chal= lenge for protocol architectures is to figure out under what conditions the= y should do certain things.=20 Additionally, I don't buy the argument that a server should not provide err= or responses (or to be only very brief, or even misleading) for a security = point of view because attackers typically know more than ordinary developer= s or users and so you end up with a system that the normal user is unable t= o work with (in a failure case) but adversaries nevertheless get what they = want. This comment relates to the first sentence that gives me the impressi= on that the server may not send any error message in case of a failure, whi= ch sounds strange to me.=20 Ciao Hannes On Jun 15, 2012, at 4:15 AM, Mike Jones wrote: > Thanks for writing the text below. It looks fine to me. About adding th= e other error parameters as suggestions, that seems like a reasonable thing= to do. How about the text at the end below, which adds mentions of error_= description and error_uri? > =20 > 7.2. Error Response > =20 > If a resource access request fails, the resource server SHOULD inform > the client of the error. While the specifics of such error responses > are beyond the scope of this specification, this documents establishes > a common registry for error values to be shared among OAuth token > authentication schemes. > =20 > New authentication schemes designed primarily for OAuth token > authentication SHOULD define a mechanism for providing an > error status code to the client, in which the error values allowed are > registered in the error registry established by this specification. Su= ch > schemes MAY limit the set of valid error codes to a subset of the > registered values. If the error code is returned using a named paramet= er, > the parameter name SHOULD be "error". > =20 > Other schemes capable of being used for OAuth token authentication, bu= t > not primarily designed for that purpose, MAY bind their error values t= o the > registry in the same manner. > =20 > New authentication schemes MAY choose to also specify the use of the > "error_description" and "error_uri" parameters to return error informa= tion > in a manner parallel to their usage in this specification. > =20 > =20 > -- Mike > =20 > P.S. If you already have the text you wrote in a copy of the draft, you = should apply these spelling corrections: > desgined -> designed > authentiction -> authentication > =20 > -----Original Message----- > From: Eran Hammer [mailto:eran@hueniverse.com] > Sent: Thursday, June 14, 2012 3:29 PM > To: Eran Hammer; Mike Jones; oauth@ietf.org WG (oauth@ietf.org) > Subject: RE: [OAUTH-WG] Section 7.2 > =20 > Mike - if you want to add the other error parameters as suggestions, that= would be fine by me. > =20 > EH > =20 > > -----Original Message----- > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On=20 > > Behalf Of Eran Hammer > > Sent: Thursday, June 14, 2012 3:23 PM > > To: Mike Jones; oauth@ietf.org WG (oauth@ietf.org) > > Subject: Re: [OAUTH-WG] Section 7.2 > > > > 7.2. Error Response > > > > If a resource access request fails, the resource server SHOULD infor= m > > the client of the error. While the specifics of such error response= s > > are beyond the scope of this specification, this documents establish= es > > a common registry for error values to be shared among OAuth token > > authentication schemes. > > > > New authentication schemes desgined primarily for OAuth token > > authentiction SHOULD define a mechanism for providing an > > error status code to the client, in which the error values allowed a= re > > registered in the error registry established by this specification. = Such > > schemes MAY limit the set of valid error codes to a subset of the > > registered values. If the error code is returned using a named param= eter, > > the parameter name SHOULD be "error". > > > > Other schemes capable of being used for OAuth token authentication, = but > > not primarily designed for that purpose, MAY bind their error values= to the > > registry in the same manner. > > > > EH > > > > _______________________________________________ > > 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 stephen.farrell@cs.tcd.ie Fri Jun 15 12:33:35 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D228C11E80DF for ; Fri, 15 Jun 2012 12:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.676 X-Spam-Level: X-Spam-Status: No, score=-102.676 tagged_above=-999 required=5 tests=[AWL=-0.077, 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 KkbNNoCvMVba for ; Fri, 15 Jun 2012 12:33:34 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 20D8911E80CD for ; Fri, 15 Jun 2012 12:33:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 878A817182C; Fri, 15 Jun 2012 20:33:33 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1339788813; bh=QHIM5ZdhjWY3SR a7Q2kAycIar426Z8lzg3CnnaryEjs=; b=F+uc+RwDx1C6ANgxZ+UR8ZkzHuLgg7 R9L7Tp8lrAuaY/HWLXjdTdaDzI/Kb6zEJukYwS/47Rg+H8EytQYcSCUQmz6yzqJa s8x7PPG8xLRX3Twlpj3T2ufhNAJDAOHRj9WDD+VsCzG/MPQ7+YrYNCC3jZr4uHSk gv/JbGaussLITEAlI90TI7EEjhjo3h99DQojtrMBN5Xb1GWnCA+Glx1h+qwv7qYa KMR8xI1SlLyx9uKWBFqR6bFQNSIhGt3TtnV6sUf2tXzu4Uj1R7f6raDhnaeRw3ic bJqDdgXLJndYDKcRRIDpZfWN/e2Edxo5Hn8STXDVeumiUQr1nKGM5Bjw== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id buHf9o2ee0uR; Fri, 15 Jun 2012 20:33:33 +0100 (IST) Received: from [10.87.48.7] (unknown [86.44.66.178]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 2D9BD171471; Fri, 15 Jun 2012 20:33:33 +0100 (IST) Message-ID: <4FDB8E0C.2060501@cs.tcd.ie> Date: Fri, 15 Jun 2012 20:33:32 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Mike Jones References: <4E1F6AAD24975D4BA5B16804296739436654F355@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436654F355@TK5EX14MBXC283.redmond.corp.microsoft.com> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Name spelling nit in acknowledgments X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 19:33:35 -0000 On 06/15/2012 07:54 PM, Mike Jones wrote: > Bearer acknowledges Bill de hÓra. Core acknowledges Bill de hOra. Which is correct? Bill may correct me but I believe the former is correct but can't be represented in ASCII so the latter is what you ought use. S From fcorella@pomcor.com Fri Jun 15 13:35:00 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01AB111E809C for ; Fri, 15 Jun 2012 13:35:00 -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 MMbNrs1cHggw for ; Fri, 15 Jun 2012 13:34:58 -0700 (PDT) Received: from nm29-vm4.bullet.mail.ne1.yahoo.com (nm29-vm4.bullet.mail.ne1.yahoo.com [98.138.91.189]) by ietfa.amsl.com (Postfix) with SMTP id 5680C11E8088 for ; Fri, 15 Jun 2012 13:34:58 -0700 (PDT) Received: from [98.138.90.53] by nm29.bullet.mail.ne1.yahoo.com with NNFMP; 15 Jun 2012 20:34:57 -0000 Received: from [98.138.89.196] by tm6.bullet.mail.ne1.yahoo.com with NNFMP; 15 Jun 2012 20:34:57 -0000 Received: from [127.0.0.1] by omp1054.mail.ne1.yahoo.com with NNFMP; 15 Jun 2012 20:34:57 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 82088.60719.bm@omp1054.mail.ne1.yahoo.com Received: (qmail 58113 invoked by uid 60001); 15 Jun 2012 20:34:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1339792497; bh=KZu2T6TuFheiA6m/Sjxp/5JPsRZwIInlulZ6NmPjZ+Q=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=QmUF+vS9RF7K2iGGvxFTEuwQnmjo4rnB8mnnGQR99/Gh4UVcwcdP9sPm/MUQvgRd1rBsHU5kUAsjn89KcMAwA2QEM4Jnl1KerzsyYcV0mdCCLKISc02cEzVL7d0hnEWacigdYkZPG7VaIwNG10XtqxlT6lRO4c2/WkBEJIvopTE= X-YMail-OSG: Nj3CzHwVM1kbNMV.igK0MT4rkuNtcPuGpuadlwE0cDWoLU5 kfn89x7.MrrQhKWkvQ4wp.GDgeSaKBl2AQmFUexB72gCmvjPlGGUq_NFoeyU mifhcSCO4yL01V27jl4X3CTDkNwN6RMpiHayGAdu1HlQkm7b8dgslXF2xrVS x55pNYig9mmR7shfzzWUTNIf_O4QZxEDWVZQwl3P.At52S3J1DWqhQlIOAY8 RQzUVd4mk_HuaqXbIZYmC6XsMucFnQXxBtt6PySQWbgoUJrr2BYTX1zJPy16 G.Q4.7g1hC588OhfEwidRYeetLZTOdcgtlnSFn2SJC1HdB6oafWnopyLCkN_ aMS879wob3tbWQ.uhsKXr.2cg0KqQXiwdk4F8c_z9o5RGS8HdN1YDgvdlKdQ WPoikhz3RU0RTmalmBHrWTVHj6UQTx2D7MwtMzdgLmXtzN8tUAb92Pw6czAF 4JZhUiL1JhYarQrAylDizoizLeB6DZpGOuY7NUbkTGXBSq.h.r14SEg4eJR_ DxrAHkT9Ria7NTaeton65jW7tkICPrBO0rGLeQuXqOwvEH9vGmRlVa6e1Che hyxZ5FvqV4OMl1ZA7unRz_83iOaWlTZPrMd2mlwjQdAwrzdz_AVOHcmi27O1 5zEI4zqb19h6Na.CTtzlztot0UoXa9KUHKAqJleZtCjKcqgenISiHSHXSHTk 4CEqbfA5ArhHO28HuDS3gx94HSYa.5aU86WqVdxpK.UCihU2vmSD3lfG1q6y e8T25FDUz0ioHZlA5HxAJpPfttmRN0wIkQX1eSS2zv.DvIAmt0ZtnkzcbipJ ectJyGi39KzT4X25OKwFoM7f74rlfjoSu1KEckko4yi664vz4GO.vhp1B6y3 oXLYe_VmbuAQapfR4HMSNHYN4LDj1HscJuVv8W5rkQEY5slhyfzxcR1q8pt4 - Received: from [68.8.105.216] by web125501.mail.ne1.yahoo.com via HTTP; Fri, 15 Jun 2012 13:34:56 PDT X-RocketYMMF: francisco_corella X-Mailer: YahooMailWebService/0.8.118.349524 References: Message-ID: <1339792496.52712.YahooMailNeo@web125501.mail.ne1.yahoo.com> Date: Fri, 15 Jun 2012 13:34:56 -0700 (PDT) From: Francisco Corella To: Nat Sakimura , rui wang In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="329289550-1816854462-1339792496=:52712" Cc: matake nov , Yuchen Zhou , oauth , "Shuo Chen \(MSR\)" Subject: Re: [OAUTH-WG] Report an authentication issue X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Francisco Corella List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 20:35:00 -0000 --329289550-1816854462-1339792496=:52712 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Nat and Rui,=0A=0ARui, you say that the vulnerability that you found was= due to a=0A"common misunderstanding among developers", but the attack you= =0Adescribe can be carried out against any app that uses the OAuth=0A"impli= cit grant flow", which Facebook calls "client-side=0Aauthentication".=C2=A0= No misunderstanding seems necessary.=C2=A0 What=0Amisunderstanding are you= referring to?=C2=A0 I followed the link in your=0Amessage to the Sophos po= st, and from there the link to the article in=0AThe Register.=C2=A0 The art= icle in The Register says that Facebook had=0A"fixed the vulnerability prom= ptly".=C2=A0 How did they fix it?=C2=A0 The=0Ainstructions that Facebook pr= ovides for implementing "Client-side=0Aauthentication without the JS SDK" a= t=0Ahttps://developers.facebook.com/docs/authentication/client-side/#no-jss= dk=0Astill allows the attack.=0A=0ANat, I agree that the blog post by John = Bradley that you link to=0Arefers to the same vulnerability reported by Rui= .=C2=A0 You say that some=0Aapps have issued a patch to fix it.=C2=A0 Could= you explain what the fix=0Awas?=0A=0AFrancisco=0A=0A=0A=0A=0A>____________= ____________________=0A> From: Nat Sakimura =0A>To: rui= wang =0A>Cc: matake nov ; Yuchen Zh= ou ; oauth ; Shuo Chen (MSR) =0A>Sent: Thursday, June 14, 2012 1:50 PM=0A>Subject: Re= : [OAUTH-WG] Report an authentication issue=0A> =0A>=0A>This is a fairly we= ll known (hopefully by now) issue. We, at the OpenID Foundation, call it "a= ccess_token phishing" attack these days. See:=C2=A0http://www.thread-safe.c= om/2012/01/problem-with-oauth-for-authentication.html=0A>=0A>=0A>Nov Matake= has actually built the code on iPhone to verify the problem, and has notif= ied bunch of parties back in February including Facebook and Apple. We have= the code that actually runs on a phone, and we have successfully logged in= to bunch of apps, including very well known ones. They were all informed o= f the issue. Some immediately issued a patch to fix it while others have no= t. =C2=A0=0A>=0A>=0A>The problem is that even if these apps gets fixed, the= problem does not go away. As long as the attacker has the vulnerable versi= on of the app, he still can impersonate the victim. To stop it, the server = side has to completely disable the older version, which means the service h= as to cut off many users pausing business problems.=C2=A0=0A>=0A>=0A>Nat=0A= >=0A>=0A>On Fri, Jun 15, 2012 at 2:18 AM, rui wang = wrote:=0A>=0A>Dear Facebook Security Team and OAuth Standard group,=0A>>We = are a research team in Microsoft Research. In January, 2011, we reported a = vulnerability in Facebook Connect which allowed everyone to sign into Faceb= ook-secured relying parties without password. It was promptly fixed after r= eporting. (http://nakedsecurity.sophos.com/2011/02/02/facebook-flaw-website= s-steal-personal-data/)=0A>>Recently, we found a common misunderstanding am= ong developers of mobile/metro apps when using OAuth (including Facebook=E2= =80=99s OAuth) for authentication. The vulnerability resulted from this mis= understanding also allows an attacker to log into a victim user's account w= ithout password.=0A>>Let's take Soluto's metro app as an example to describ= e the problem. The app supports Facebook Login. As an attacker, we can writ= e a regular Facebook app. Once the victim user allows our app to access her= Facebook data, we receive an access_token from the traffic. Then, on our o= wn machine (i.e., the "attacker" machine), we run the metro app of Soluto, = and use a HTTP proxy to insert the victim's access_token into the traffic o= f Facebook login. Through this way, we are able to log into the victim's So= luto account from our machine. Other than Soluto, we also have confirmed th= e same issue on another Windows 8 metro-app Givit.=0A>>The Facebook SDK for= Android apps (https://developers.facebook.com/docs/mobile/android/build/#s= dk) seems to have the possibility to mislead developers too. At least, the = issue that we found is not clearly mentioned. In the SDK, we ran the sample= code called "Hackbook" using Android Emulator (imagine it is an attacker d= evice). Note that we have already received the access token of the victim u= ser from our regular Facebook app. We then inject the token to the traffic = of Hackbook. Through this way, Hackbook app on our own machine recognizes u= s as the victim. Note that this is not a convincing security exploit yet, b= ecause this sample code does not include the server-side code. However, giv= en that we have seen real server-side code having this problem, such as Sol= uto, Givit and others, we do believe that the sample code can mislead mobil= e/metro developers. We also suspect that this may be a general issue of man= y OAuth implementations on mobile platforms, so we send this message to OAuth Standard group as well.=0A>>We have conta= cted the vendors of the two vulnerable metro-apps, Soluto and Gavit.=0A>>Pl= ease kindly give us an ack when you receive this message. If you want to kn= ow more details, please let us know.=0A>>Best Regards,=0A>>Yuchen Zhou, Rui= Wang, and Shuo Chen=0A>>_______________________________________________=0A= >>OAuth mailing list=0A>>OAuth@ietf.org=0A>>https://www.ietf.org/mailman/li= stinfo/oauth=0A>>=0A>>=0A>=0A>=0A>=0A>-- =0A>Nat Sakimura (=3Dnat)=0A>Chair= man, OpenID Foundation=0A>http://nat.sakimura.org/=0A>@_nat_en=0A>=0A>_____= __________________________________________=0A>OAuth mailing list=0A>OAuth@i= etf.org=0A>https://www.ietf.org/mailman/listinfo/oauth=0A>=0A>=0A> --329289550-1816854462-1339792496=:52712 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Nat and Rui,
Rui, you say that the vulnerability that you found was due to a
"commo= n misunderstanding among developers", but the attack you
describe can be= carried out against any app that uses the OAuth
"implicit grant flow", = which Facebook calls "client-side
authentication".  No misunderstan= ding seems necessary.  What
misunderstanding are you referring to?&= nbsp; I followed the link in your
message to the Sophos post, and from t= here the link to the article in
The Register.  The article in The R= egister says that Facebook had
"fixed the vulnerability promptly". = How did they fix it?  The
instructions that Facebook provides for = implementing "Client-side
authentication without the JS SDK" at
https://developers.facebook.com/docs/authentication/client-side/#n= o-jssdk
still allows the attack.

Nat, I agree that the blog p= ost by John Bradley that you link to
refers to the same vulnerability re= ported by Rui.  You say that some
apps have issued a patch to fix i= t.  Could you explain what the fix
was?

Francisco
From: Nat Sakimura <sakimura@gmail.c= om>
To: rui wang <ruiwangwarm@gmail.com>
Cc= : matake nov <nov@matake.jp>; Yuchen Zhou <t-yuzhou@mic= rosoft.com>; oauth <oauth@ietf.org>; Shuo Chen (MSR) <shuochen@= microsoft.com>
Sent: Thursday, June 14, 2012 1:50 PM
This is a fairly well known (h= opefully by now) issue. We, at the OpenID Foundation, call it "access_token= phishing" attack these days. See: http://www.thread-safe.com/2012/01/= problem-with-oauth-for-authentication.html
=0A
Nov Matake= has actually built the code on iPhone to verify the problem, and has notif= ied bunch of parties back in February including Facebook and Apple. We have= the code that actually runs on a phone, and we have successfully logged in= to bunch of apps, including very well known ones. They were all informed o= f the issue. Some immediately issued a patch to fix it while others have no= t.  
=0A

The problem is that even if these app= s gets fixed, the problem does not go away. As long as the attacker has the= vulnerable version of the app, he still can impersonate the victim. To sto= p it, the server side has to completely disable the older version, which me= ans the service has to cut off many users pausing business problems. <= /div>=0A

Nat

On Fri, Jun 15, 2012 at 2:18 AM, rui wang <ruiwangwarm@gmail.com> wr= ote:
=0A
Dear Facebook = Security Team and OAuth Standard group,
=0A
We are a research team= in Microsoft Research. In January, 2011, we reported a vulnerability in Fa= cebook Connect which allowed everyone to sign into Facebook-secured relying= parties without password. It was promptly fixed after reporting. (http://n= akedsecurity.sophos.com/2011/02/02/facebook-flaw-websites-steal-personal-da= ta/)
=0A=0A=0A
Recently, we found a common misunderstanding among = developers of mobile/metro apps when using OAuth (including Facebook=E2=80= =99s OAuth) for authentication. The vulnerability resulted from this misund= erstanding also allows an attacker to log into a victim user's account with= out password.
=0A=0A=0A
Let's take Soluto's metro app as an exampl= e to describe the problem. The app supports Facebook Login. As an attacker,= we can write a regular Facebook app. Once the victim user allows our app t= o access her Facebook data, we receive an access_token from the traffic. Th= en, on our own machine (i.e., the "attacker" machine), we run the metro app= of Soluto, and use a HTTP proxy to insert the victim's access_token into t= he traffic of Facebook login. Through this way, we are able to log into the= victim's Soluto account from our machine. Other than Soluto, we also have = confirmed the same issue on another Windows 8 metro-app Givit.
=0A=0A= =0A
The Facebook SDK for Android apps (https://developers.facebook.com/docs/mobile/android/build/#sdk) seem= s to have the possibility to mislead developers too. At least, the issue th= at we found is not clearly mentioned. In the SDK, we ran the sample code ca= lled "Hackbook" using Android Emulator (imagine it is an attacker device). = Note that we have already received the access token of the victim user from= our regular Facebook app. We then inject the token to the traffic of Hackb= ook. Through this way, Hackbook app on our own machine recognizes us as the= victim. Note that this is not a convincing security exploit yet, because t= his sample code does not include the server-side code. However, given that = we have seen real server-side code having this problem, such as Soluto, Giv= it and others, we do believe that the sample code can mislead mobile/metro developers. We also suspect that this may be a general issue of many OAuth= implementations on mobile platforms, so we send this message to OAuth Stan= dard group as well.
=0A=0A=0A
We have contacted the vendors of the= two vulnerable metro-apps, Soluto and Gavit.
=0A
Please kindly gi= ve us an ack when you receive this message. If you want to know more detail= s, please let us know.
=0A
Best Regards,
Yuchen Zhou, Rui Wang,= and Shuo Chen
=0A
_______________________________________________<= br>=0AOAuth mailing list
=0AOAuth@ietf.org
=0Ahttps://www.ietf.org/mailman/listinfo/oauth=0A



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

=0A=0A
=0A

__________________________= _____________________
OAuth mailing list
OAuth@ietf.org
https://www.ie= tf.org/mailman/listinfo/oauth


--329289550-1816854462-1339792496=:52712-- From ruiwangwarm@gmail.com Fri Jun 15 15:06:26 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20F4821F8559 for ; Fri, 15 Jun 2012 15:06:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.504 X-Spam-Level: X-Spam-Status: No, score=-3.504 tagged_above=-999 required=5 tests=[AWL=0.094, 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 zm5jq0Hp8JZC for ; Fri, 15 Jun 2012 15:06:23 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id D767521F846F for ; Fri, 15 Jun 2012 15:06:22 -0700 (PDT) Received: by ggnc4 with SMTP id c4so3035807ggn.31 for ; Fri, 15 Jun 2012 15:06:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=d5hQauedYgN77v+zFJrpekbvG0BnoOa27f5kCMmpt5M=; b=Tcc2C4pTddPuk68Hbr8FqRLeM19dbqJsgw3ZV7lH/w/kBJjl6AcuhLrVYZdHVak3ox KNCcCHtEUatoHCLNZG00hJLPRW2O4oYqVBLneJUpG/HacYzn6EZpFxSOZdUrMklQ3oqD 5VDKnfHKTuYBvgh8X7ZmF85C7987hmWpBH640XegMA+UUN0xAtmQofDW3g5RW1mt+c88 S/Iij3Sz1Z6I4N1kJ+RL8XT0kbEQ9uL6KYBk9ZUgnJ68cpigR2gKGGlt2ybh+BVN3GMt z9JATOcKaPA1Q8pWwNRyCHYuQ4aBLOhYVDoXTStAu40/D8E3uXowjY9Diha3NJjNLf+Y +/fw== MIME-Version: 1.0 Received: by 10.50.220.194 with SMTP id py2mr3420193igc.15.1339797981284; Fri, 15 Jun 2012 15:06:21 -0700 (PDT) Received: by 10.42.101.201 with HTTP; Fri, 15 Jun 2012 15:06:21 -0700 (PDT) In-Reply-To: <1339792496.52712.YahooMailNeo@web125501.mail.ne1.yahoo.com> References: <1339792496.52712.YahooMailNeo@web125501.mail.ne1.yahoo.com> Date: Fri, 15 Jun 2012 15:06:21 -0700 Message-ID: From: rui wang To: Francisco Corella Content-Type: multipart/alternative; boundary=bcaec5555100becb1504c28a0613 Cc: matake nov , Yuchen Zhou , oauth , "Shuo Chen \(MSR\)" Subject: Re: [OAUTH-WG] Report an authentication issue X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 22:06:26 -0000 --bcaec5555100becb1504c28a0613 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, Francisco Thank you for your reply. Here is our response for your questions. =D8 the attack you describe can be carried out against any app that uses t= he OAuth "implicit grant flow", which Facebook calls "client-side authentication". The main concern we raised here is not about attacking client-side apps. We don=92t think it is a meaningful security consequence when a client-side application (e.g., a Win8 Metro app, iPhone/iPad app) on the attacker=92s tablet misidentifies the user as the victim user. Therefore, you are right about =93this kind of attack can be carried out against any app using the OAuth =91implicit grant flow=92=94. In fact we won=92t even call this conse= quence as an attack. The real problem is that in multiple occasions, we found that the server-side authentication logic takes an access token from the client app, then queries the user's profile data from the IdP in order to "authenticate" the user into the server. We have confirmed that the servers for Soluto Metro App, Givit Metro App and EuroCup2012 Metro App make this mistake. These are apps in the official Windows 8 App Store. We only sampled a small portion of the available apps, but believe this is a vulnerability pattern due to a common misunderstanding of the usage of the access token. =D8 I followed the link in your message to the Sophos post, and from there the link to the article in The Register. The article in The Register says that Facebook had "fixed the vulnerability promptly". How did they fix it? The instructions that Facebook provides for implementing "Client-side authentication without the JS SDK" at https://developers.facebook.com/docs/authentication/client-side/#no-jssdk still allows the attack. I am very sorry for the confusion. The link to Sophos has nothing to do with this problem. It is about another issue we reported last year. I mentioned this because the email yesterday was sent to Facebook and the OAuth mailing list at the same time. I was trying to let the Facebook team know we had previous communication before. I should have removed this part in the version sent to OAuth. Again, sorry for not removing this reference. Please ignore it. Thanks, Rui On Fri, Jun 15, 2012 at 1:34 PM, Francisco Corella wro= te: > Hi Nat and Rui, > > Rui, you say that the vulnerability that you found was due to a > "common misunderstanding among developers", but the attack you > describe can be carried out against any app that uses the OAuth > "implicit grant flow", which Facebook calls "client-side > authentication". No misunderstanding seems necessary. What > misunderstanding are you referring to? I followed the link in your > message to the Sophos post, and from there the link to the article in > The Register. The article in The Register says that Facebook had > "fixed the vulnerability promptly". How did they fix it? The > instructions that Facebook provides for implementing "Client-side > authentication without the JS SDK" at > https://developers.facebook.com/docs/authentication/client-side/#no-jssdk > still allows the attack. > > Nat, I agree that the blog post by John Bradley that you link to > refers to the same vulnerability reported by Rui. You say that some > apps have issued a patch to fix it. Could you explain what the fix > was? > > Francisco > > ------------------------------ > *From:* Nat Sakimura > *To:* rui wang > *Cc:* matake nov ; Yuchen Zhou ; > oauth ; Shuo Chen (MSR) > *Sent:* Thursday, June 14, 2012 1:50 PM > > *Subject:* Re: [OAUTH-WG] Report an authentication issue > > This is a fairly well known (hopefully by now) issue. We, at the OpenID > Foundation, call it "access_token phishing" attack these days. See: > http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.= html > > Nov Matake has actually built the code on iPhone to verify the problem, > and has notified bunch of parties back in February including Facebook and > Apple. We have the code that actually runs on a phone, and we have > successfully logged in to bunch of apps, including very well known ones. > They were all informed of the issue. Some immediately issued a patch to f= ix > it while others have not. > > The problem is that even if these apps gets fixed, the problem does not g= o > away. As long as the attacker has the vulnerable version of the app, he > still can impersonate the victim. To stop it, the server side has to > completely disable the older version, which means the service has to cut > off many users pausing business problems. > > Nat > > On Fri, Jun 15, 2012 at 2:18 AM, rui wang wrote: > > Dear Facebook Security Team and OAuth Standard group, > We are a research team in Microsoft Research. In January, 2011, we > reported a vulnerability in Facebook Connect which allowed everyone to si= gn > into Facebook-secured relying parties without password. It was promptly > fixed after reporting. ( > http://nakedsecurity.sophos.com/2011/02/02/facebook-flaw-websites-steal-p= ersonal-data/ > ) > Recently, we found a common misunderstanding among developers of > mobile/metro apps when using OAuth (including Facebook=92s OAuth) for > authentication. The vulnerability resulted from this misunderstanding als= o > allows an attacker to log into a victim user's account without password. > Let's take Soluto's metro app as an example to describe the problem. The > app supports Facebook Login. As an attacker, we can write a regular > Facebook app. Once the victim user allows our app to access her Facebook > data, we receive an access_token from the traffic. Then, on our own machi= ne > (i.e., the "attacker" machine), we run the metro app of Soluto, and use a > HTTP proxy to insert the victim's access_token into the traffic of Facebo= ok > login. Through this way, we are able to log into the victim's Soluto > account from our machine. Other than Soluto, we also have confirmed the > same issue on another Windows 8 metro-app Givit. > The Facebook SDK for Android apps ( > https://developers.facebook.com/docs/mobile/android/build/#sdk) seems to > have the possibility to mislead developers too. At least, the issue that = we > found is not clearly mentioned. In the SDK, we ran the sample code called > "Hackbook" using Android Emulator (imagine it is an attacker device). Not= e > that we have already received the access token of the victim user from ou= r > regular Facebook app. We then inject the token to the traffic of Hackbook= . > Through this way, Hackbook app on our own machine recognizes us as the > victim. Note that this is not a convincing security exploit yet, because > this sample code does not include the server-side code. However, given th= at > we have seen real server-side code having this problem, such as Soluto, > Givit and others, we do believe that the sample code can mislead > mobile/metro developers. We also suspect that this may be a general issue > of many OAuth implementations on mobile platforms, so we send this messag= e > to OAuth Standard group as well. > We have contacted the vendors of the two vulnerable metro-apps, Soluto an= d > Gavit. > Please kindly give us an ack when you receive this message. If you want t= o > know more details, please let us know. > Best Regards, > Yuchen Zhou, Rui Wang, and Shuo Chen > > _______________________________________________ > 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 > > > --bcaec5555100becb1504c28a0613 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi, Francisco
=A0
Thank you for your reply. Here is our response for your questions.
=
=D8=A0 the attack you describe can be carried out against any app that = uses the OAuth "implicit grant flow", which Facebook calls "= client-side authentication".
=A0
The main concern we raised here is not about a= ttacking client-side apps. We don=92t think it is a meaningful security con= sequence when a client-side application (e.g., a Win8 Metro app, iPhone/iPa= d app) on the attacker=92s tablet misidentifies the user as the victim user= . Therefore, you are right about =93this kind of attack can be carried out = against any app=A0 using the OAuth =91implicit grant flow=92=94. In fact we= won=92t even call this consequence as an attack.
The real problem is that in multiple occasions= , we found that the server-side authentication logic takes an access token = from the client app, then queries the user's profile data from the IdP = in order to "authenticate" the user into the server. We have conf= irmed that the servers for Soluto Metro App, Givit Metro App and EuroCup201= 2 Metro App make this mistake. These are apps in the official Windows 8 App= Store. We only sampled a small portion of the available apps, but believe = this is a vulnerability pattern due to a common misunderstanding of the usa= ge of the access token.
=A0
=D8=A0 I followed the link in your message to the Sophos post, and fro= m there the link to the article in
The Register.=A0 The article in The R= egister says that Facebook had
"fixed the vulnerability promptly&qu= ot;.=A0 How did they fix it?=A0 The
instructions that Facebook provides for implementing "Client-side
a= uthentication without the JS SDK" at
https://developers.= facebook.com/docs/authentication/client-side/#no-jssdk
still allows the attack.
=A0
I am very sorry for the confusion. The link to= Sophos has nothing to do with this problem. It is about another issue we r= eported last year. I mentioned this because the email yesterday was sent to= Facebook and the OAuth mailing list at the same time. I was trying to let = the Facebook team know we had previous communication before. I should have = removed this part in the version sent to OAuth. Again, sorry for not removi= ng this reference. Please ignore it.
=A0
Thanks,
Rui
On Fri, Jun 15, 2012 at 1:34 PM, Francisco Corel= la <fcorella@pomcor.com> wrote:
Hi Nat and Rui,

Rui, you say that the vulnerability that you fou= nd was due to a
"common misunderstanding among developers", bu= t the attack you
describe can be carried out against any app that uses the OAuth
"im= plicit grant flow", which Facebook calls "client-side
authenti= cation".=A0 No misunderstanding seems necessary.=A0 What
misunderst= anding are you referring to?=A0 I followed the link in your
message to the Sophos post, and from there the link to the article in
Th= e Register.=A0 The article in The Register says that Facebook had
"= fixed the vulnerability promptly".=A0 How did they fix it?=A0 The
i= nstructions that Facebook provides for implementing "Client-side
authentication without the JS SDK" at
= https://developers.facebook.com/docs/authentication/client-side/#no-jssdk
still allows the attack.

Nat, I agree that the blog post by John Bra= dley that you link to
refers to the same vulnerability reported by Rui.= =A0 You say that some
apps have issued a patch to fix it.=A0 Could you e= xplain what the fix
was?

Francisco

From: Nat Sakimura <sakimura@gmail.com&g= t;
To: rui wang <ruiwangwarm@gmail.com= >
Cc: matake nov <nov@matake.jp>; Yuchen Z= hou <t-yuzho= u@microsoft.com>; oauth <oauth@ietf.org>; Shuo Chen (MSR) <shuochen@microsoft.com> Sent: Thursday, June 14, 201= 2 1:50 PM=20

Subject: Re: [OAUTH-WG] Report an authentication issue

This is a fairly well known (hopefully by now) issue. We, at the OpenI= D Foundation, call it "access_token phishing" attack these days. = See:=A0http://www.thread-safe.com/2012/01/= problem-with-oauth-for-authentication.html=20

Nov Matake has actually built the code on iPhone to verify the problem= , and has notified bunch of parties back in February including Facebook and= Apple. We have the code that actually runs on a phone, and we have success= fully logged in to bunch of apps, including very well known ones. They were= all informed of the issue. Some immediately issued a patch to fix it while= others have not. =A0

The problem is that even if these apps gets fixed, the problem does no= t go away. As long as the attacker has the vulnerable version of the app, h= e still can impersonate the victim. To stop it, the server side has to comp= letely disable the older version, which means the service has to cut off ma= ny users pausing business problems.=A0

Nat

On Fri, Jun 15, 2012 at 2:18 AM, rui wang <ruiwa= ngwarm@gmail.com> wrote:
Dear Facebook Security Team and OAuth Standard group,
We are a research team in Microsoft Research. In January, 2011, we rep= orted a vulnerability in Facebook Connect which allowed everyone to sign in= to Facebook-secured relying parties without password. It was promptly fixed= after reporting. (http://nakedse= curity.sophos.com/2011/02/02/facebook-flaw-websites-steal-personal-data/)
Recently, we found a common misunderstanding among developers of mobil= e/metro apps when using OAuth (including Facebook=92s OAuth) for authentica= tion. The vulnerability resulted from this misunderstanding also allows an = attacker to log into a victim user's account without password.
Let's take Soluto's metro app as an example to describe the pr= oblem. The app supports Facebook Login. As an attacker, we can write a regu= lar Facebook app. Once the victim user allows our app to access her Faceboo= k data, we receive an access_token from the traffic. Then, on our own machi= ne (i.e., the "attacker" machine), we run the metro app of Soluto= , and use a HTTP proxy to insert the victim's access_token into the tra= ffic of Facebook login. Through this way, we are able to log into the victi= m's Soluto account from our machine. Other than Soluto, we also have co= nfirmed the same issue on another Windows 8 metro-app Givit.
The Facebook SDK for Android apps (= https://developers.facebook.com/docs/mobile/android/build/#sdk) seems t= o have the possibility to mislead developers too. At least, the issue that = we found is not clearly mentioned. In the SDK, we ran the sample code calle= d "Hackbook" using Android Emulator (imagine it is an attacker de= vice). Note that we have already received the access token of the victim us= er from our regular Facebook app. We then inject the token to the traffic o= f Hackbook. Through this way, Hackbook app on our own machine recognizes us= as the victim. Note that this is not a convincing security exploit yet, be= cause this sample code does not include the server-side code. However, give= n that we have seen real server-side code having this problem, such as Solu= to, Givit and others, we do believe that the sample code can mislead mobile= /metro developers. We also suspect that this may be a general issue of many= OAuth implementations on mobile platforms, so we send this message to OAut= h Standard group as well.
We have contacted the vendors of the two vulnerable metro-apps, Soluto= and Gavit.
Please kindly give us an ack when you receive this message. If you wan= t to know more details, please let us know.
Best Regards,
Yuchen Zhou, Rui Wang, and Shuo Chen

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




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


_______________________________________________
OAuth mailing lis= t
OAuth@ietf.org
<= a href=3D"https://www.ietf.org/mailman/listinfo/oauth" target=3D"_blank">ht= tps://www.ietf.org/mailman/listinfo/oauth


=

--bcaec5555100becb1504c28a0613-- From phil.hunt@oracle.com Fri Jun 15 15:59:02 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F55111E8102 for ; Fri, 15 Jun 2012 15:59:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.366 X-Spam-Level: X-Spam-Status: No, score=-10.366 tagged_above=-999 required=5 tests=[AWL=0.232, 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 tmdGlJB2Vr6B for ; Fri, 15 Jun 2012 15:59:01 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id C2EA911E80ED for ; Fri, 15 Jun 2012 15:59:00 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q5FMwv2j029893 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 15 Jun 2012 22:58: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 q5FMwuIi026700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 Jun 2012 22:58:57 GMT Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q5FMwuja018294; Fri, 15 Jun 2012 17:58:56 -0500 Received: from [192.168.1.7] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 15 Jun 2012 15:58:56 -0700 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_60E322D7-8D04-4878-B661-29464FD31C33" From: Phil Hunt In-Reply-To: Date: Fri, 15 Jun 2012 15:58:53 -0700 Message-Id: References: <1339792496.52712.YahooMailNeo@web125501.mail.ne1.yahoo.com> To: rui wang X-Mailer: Apple Mail (2.1278) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "Shuo Chen \(MSR\)" , matake nov , Yuchen Zhou , oauth Subject: Re: [OAUTH-WG] Report an authentication issue X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 22:59:02 -0000 --Apple-Mail=_60E322D7-8D04-4878-B661-29464FD31C33 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I am a bit confused. It sounds like you are sniffing a bearer token from an unsecured = connection to a resource server and then letting another client use that = token. Is this correct? Phil @independentid www.independentid.com phil.hunt@oracle.com On 2012-06-15, at 3:06 PM, rui wang wrote: > Hi, Francisco > =20 > Thank you for your reply. Here is our response for your questions. >=20 > =D8 the attack you describe can be carried out against any app that = uses the OAuth "implicit grant flow", which Facebook calls "client-side = authentication". > =20 > The main concern we raised here is not about attacking client-side = apps. We don=92t think it is a meaningful security consequence when a = client-side application (e.g., a Win8 Metro app, iPhone/iPad app) on the = attacker=92s tablet misidentifies the user as the victim user. = Therefore, you are right about =93this kind of attack can be carried out = against any app using the OAuth =91implicit grant flow=92=94. In fact = we won=92t even call this consequence as an attack. > The real problem is that in multiple occasions, we found that the = server-side authentication logic takes an access token from the client = app, then queries the user's profile data from the IdP in order to = "authenticate" the user into the server. We have confirmed that the = servers for Soluto Metro App, Givit Metro App and EuroCup2012 Metro App = make this mistake. These are apps in the official Windows 8 App Store. = We only sampled a small portion of the available apps, but believe this = is a vulnerability pattern due to a common misunderstanding of the usage = of the access token. > =20 > =D8 I followed the link in your message to the Sophos post, and from = there the link to the article in > The Register. The article in The Register says that Facebook had > "fixed the vulnerability promptly". How did they fix it? The > instructions that Facebook provides for implementing "Client-side > authentication without the JS SDK" at > = https://developers.facebook.com/docs/authentication/client-side/#no-jssdk > still allows the attack. > =20 > I am very sorry for the confusion. The link to Sophos has nothing to = do with this problem. It is about another issue we reported last year. I = mentioned this because the email yesterday was sent to Facebook and the = OAuth mailing list at the same time. I was trying to let the Facebook = team know we had previous communication before. I should have removed = this part in the version sent to OAuth. Again, sorry for not removing = this reference. Please ignore it. > =20 > Thanks, > Rui > On Fri, Jun 15, 2012 at 1:34 PM, Francisco Corella = wrote: > Hi Nat and Rui, >=20 > Rui, you say that the vulnerability that you found was due to a > "common misunderstanding among developers", but the attack you > describe can be carried out against any app that uses the OAuth > "implicit grant flow", which Facebook calls "client-side > authentication". No misunderstanding seems necessary. What > misunderstanding are you referring to? I followed the link in your > message to the Sophos post, and from there the link to the article in > The Register. The article in The Register says that Facebook had > "fixed the vulnerability promptly". How did they fix it? The > instructions that Facebook provides for implementing "Client-side > authentication without the JS SDK" at > = https://developers.facebook.com/docs/authentication/client-side/#no-jssdk > still allows the attack. >=20 > Nat, I agree that the blog post by John Bradley that you link to > refers to the same vulnerability reported by Rui. You say that some > apps have issued a patch to fix it. Could you explain what the fix > was? >=20 > Francisco >=20 > From: Nat Sakimura > To: rui wang =20 > Cc: matake nov ; Yuchen Zhou ; = oauth ; Shuo Chen (MSR) =20 > Sent: Thursday, June 14, 2012 1:50 PM >=20 > Subject: Re: [OAUTH-WG] Report an authentication issue >=20 > This is a fairly well known (hopefully by now) issue. We, at the = OpenID Foundation, call it "access_token phishing" attack these days. = See: = http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.h= tml >=20 > Nov Matake has actually built the code on iPhone to verify the = problem, and has notified bunch of parties back in February including = Facebook and Apple. We have the code that actually runs on a phone, and = we have successfully logged in to bunch of apps, including very well = known ones. They were all informed of the issue. Some immediately issued = a patch to fix it while others have not. =20 >=20 > The problem is that even if these apps gets fixed, the problem does = not go away. As long as the attacker has the vulnerable version of the = app, he still can impersonate the victim. To stop it, the server side = has to completely disable the older version, which means the service has = to cut off many users pausing business problems.=20 >=20 > Nat >=20 > On Fri, Jun 15, 2012 at 2:18 AM, rui wang = wrote: > Dear Facebook Security Team and OAuth Standard group, > We are a research team in Microsoft Research. In January, 2011, we = reported a vulnerability in Facebook Connect which allowed everyone to = sign into Facebook-secured relying parties without password. It was = promptly fixed after reporting. = (http://nakedsecurity.sophos.com/2011/02/02/facebook-flaw-websites-steal-p= ersonal-data/) > Recently, we found a common misunderstanding among developers of = mobile/metro apps when using OAuth (including Facebook=92s OAuth) for = authentication. The vulnerability resulted from this misunderstanding = also allows an attacker to log into a victim user's account without = password. > Let's take Soluto's metro app as an example to describe the problem. = The app supports Facebook Login. As an attacker, we can write a regular = Facebook app. Once the victim user allows our app to access her Facebook = data, we receive an access_token from the traffic. Then, on our own = machine (i.e., the "attacker" machine), we run the metro app of Soluto, = and use a HTTP proxy to insert the victim's access_token into the = traffic of Facebook login. Through this way, we are able to log into the = victim's Soluto account from our machine. Other than Soluto, we also = have confirmed the same issue on another Windows 8 metro-app Givit. > The Facebook SDK for Android apps = (https://developers.facebook.com/docs/mobile/android/build/#sdk) seems = to have the possibility to mislead developers too. At least, the issue = that we found is not clearly mentioned. In the SDK, we ran the sample = code called "Hackbook" using Android Emulator (imagine it is an attacker = device). Note that we have already received the access token of the = victim user from our regular Facebook app. We then inject the token to = the traffic of Hackbook. Through this way, Hackbook app on our own = machine recognizes us as the victim. Note that this is not a convincing = security exploit yet, because this sample code does not include the = server-side code. However, given that we have seen real server-side code = having this problem, such as Soluto, Givit and others, we do believe = that the sample code can mislead mobile/metro developers. We also = suspect that this may be a general issue of many OAuth implementations = on mobile platforms, so we send this message to OAuth Standard group as = well. > We have contacted the vendors of the two vulnerable metro-apps, Soluto = and Gavit. > Please kindly give us an ack when you receive this message. If you = want to know more details, please let us know. > Best Regards, > Yuchen Zhou, Rui Wang, and Shuo Chen >=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 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_60E322D7-8D04-4878-B661-29464FD31C33 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I am = a bit confused.

It sounds like you are sniffing a = bearer token from an unsecured connection to a resource server and then = letting another client use that token.

Is this = correct?

Phil

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





On 2012-06-15, at 3:06 PM, rui wang wrote:

Hi, = Francisco
 
Thank you for your reply. Here is our response for your = questions.

=D8  the attack you describe can be carried out = against any app that uses the OAuth "implicit grant flow", which = Facebook calls "client-side authentication".
 
The main concern we raised here is not = about attacking client-side apps. We don=92t think it is a meaningful = security consequence when a client-side application (e.g., a Win8 Metro = app, iPhone/iPad app) on the attacker=92s tablet misidentifies the user = as the victim user. Therefore, you are right about =93this kind of = attack can be carried out against any app  using the OAuth = =91implicit grant flow=92=94. In fact we won=92t even call this = consequence as an attack.
The real problem is that in multiple = occasions, we found that the server-side authentication logic takes an = access token from the client app, then queries the user's profile data = from the IdP in order to "authenticate" the user into the server. We = have confirmed that the servers for Soluto Metro App, Givit Metro App = and EuroCup2012 Metro App make this mistake. These are apps in the = official Windows 8 App Store. We only sampled a small portion of the = available apps, but believe this is a vulnerability pattern due to a = common misunderstanding of the usage of the access token.
 
=D8  I followed the link in your message to the Sophos post, = and from there the link to the article in
The Register.  The = article in The Register says that Facebook had
"fixed the = vulnerability promptly".  How did they fix it?  The
instructions that Facebook provides for implementing = "Client-side
authentication without the JS SDK" at
https://developers.facebook.com/docs/authentication/client-side/#= no-jssdk
still allows the attack.
 
I am very sorry for the confusion. The link = to Sophos has nothing to do with this problem. It is about another issue = we reported last year. I mentioned this because the email yesterday was = sent to Facebook and the OAuth mailing list at the same time. I was = trying to let the Facebook team know we had previous communication = before. I should have removed this part in the version sent to OAuth. = Again, sorry for not removing this reference. Please ignore = it.
 
Thanks,
Rui
On Fri, Jun 15, 2012 at 1:34 PM, Francisco = Corella <fcorella@pomcor.com> wrote:
Hi Nat and Rui,

Rui, you say = that the vulnerability that you found was due to a
"common = misunderstanding among developers", but the attack you
describe can be carried out against any app that uses the = OAuth
"implicit grant flow", which Facebook calls = "client-side
authentication".  No misunderstanding seems = necessary.  What
misunderstanding are you referring to?  I = followed the link in your
message to the Sophos post, and from there the link to the article = in
The Register.  The article in The Register says that Facebook = had
"fixed the vulnerability promptly".  How did they fix = it?  The
instructions that Facebook provides for implementing = "Client-side
authentication without the JS SDK" at
https://developers.facebook.com/docs/authentication/clie= nt-side/#no-jssdk
still allows the attack.

Nat, I agree that the blog post by John = Bradley that you link to
refers to the same vulnerability reported by = Rui.  You say that some
apps have issued a patch to fix = it.  Could you explain what the fix
was?

Francisco

From: Nat Sakimura <sakimura@gmail.com>
To: rui wang <ruiwangwarm@gmail.com>
Cc: matake nov <nov@matake.jp>; = Yuchen Zhou <t-yuzhou@microsoft.com>; oauth <oauth@ietf.org>; = Shuo Chen (MSR) <shuochen@microsoft.com>
Sent: Thursday, June 14, = 2012 1:50 PM=20

Subject: Re: [OAUTH-WG] Report an = authentication issue

This is a fairly well known (hopefully by now) issue. We, at the = OpenID Foundation, call it "access_token phishing" attack these days. = See: http://www.thread-safe.com/2012/01/problem-with-oauth-fo= r-authentication.html=20

Nov Matake has actually built the code on iPhone to verify the = problem, and has notified bunch of parties back in February including = Facebook and Apple. We have the code that actually runs on a phone, and = we have successfully logged in to bunch of apps, including very well = known ones. They were all informed of the issue. Some immediately issued = a patch to fix it while others have not.  

The problem is that even if these apps gets fixed, the problem does = not go away. As long as the attacker has the vulnerable version of the = app, he still can impersonate the victim. To stop it, the server side = has to completely disable the older version, which means the service has = to cut off many users pausing business problems. 

Nat

On Fri, Jun 15, 2012 at 2:18 AM, rui wang <ruiwangwarm@gmail.com> wrote:
Dear Facebook Security Team and OAuth Standard group,
We are a research team in Microsoft Research. In January, 2011, we = reported a vulnerability in Facebook Connect which allowed everyone to = sign into Facebook-secured relying parties without password. It was = promptly fixed after reporting. (http://nakedsecurity.sophos.com/2011/02/02/facebook-flaw= -websites-steal-personal-data/)
Recently, we found a common misunderstanding among developers of = mobile/metro apps when using OAuth (including Facebook=92s OAuth) for = authentication. The vulnerability resulted from this misunderstanding = also allows an attacker to log into a victim user's account without = password.
Let's take Soluto's metro app as an example to describe the = problem. The app supports Facebook Login. As an attacker, we can write a = regular Facebook app. Once the victim user allows our app to access her = Facebook data, we receive an access_token from the traffic. Then, on our = own machine (i.e., the "attacker" machine), we run the metro app of = Soluto, and use a HTTP proxy to insert the victim's access_token into = the traffic of Facebook login. Through this way, we are able to log into = the victim's Soluto account from our machine. Other than Soluto, we also = have confirmed the same issue on another Windows 8 metro-app = Givit.
The Facebook SDK for Android apps (https://developers.facebook.com/docs/mobile/android/buil= d/#sdk) seems to have the possibility to mislead developers too. At = least, the issue that we found is not clearly mentioned. In the SDK, we = ran the sample code called "Hackbook" using Android Emulator (imagine it = is an attacker device). Note that we have already received the access = token of the victim user from our regular Facebook app. We then inject = the token to the traffic of Hackbook. Through this way, Hackbook app on = our own machine recognizes us as the victim. Note that this is not a = convincing security exploit yet, because this sample code does not = include the server-side code. However, given that we have seen real = server-side code having this problem, such as Soluto, Givit and others, = we do believe that the sample code can mislead mobile/metro developers. = We also suspect that this may be a general issue of many OAuth = implementations on mobile platforms, so we send this message to OAuth = Standard group as well.
We have contacted the vendors of the two vulnerable metro-apps, = Soluto and Gavit.
Please kindly give us an ack when you receive this message. If you = want to know more details, please let us know.
Best Regards,
Yuchen Zhou, Rui Wang, and Shuo = Chen

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

<= /blockquote>



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

=

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

<= br>

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

= --Apple-Mail=_60E322D7-8D04-4878-B661-29464FD31C33-- From phil.hunt@oracle.com Fri Jun 15 16:33:23 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72A6311E80FD for ; Fri, 15 Jun 2012 16:33:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.424 X-Spam-Level: X-Spam-Status: No, score=-10.424 tagged_above=-999 required=5 tests=[AWL=0.174, 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 Yi9n2SSg+kzv for ; Fri, 15 Jun 2012 16:33:21 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id 7536911E80CE for ; Fri, 15 Jun 2012 16:33:21 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q5FNXIRs015793 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 15 Jun 2012 23:33:19 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q5FNXGbm008890 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 Jun 2012 23:33:17 GMT Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q5FNXGhE017539; Fri, 15 Jun 2012 18:33:16 -0500 Received: from [192.168.1.7] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 15 Jun 2012 16:33:15 -0700 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_6C469159-0132-49D6-A672-65A7D0CB73C8" From: Phil Hunt In-Reply-To: <854774286EF8A240BACC342973A86EAC01667CF7@BL2PRD0310MB387.namprd03.prod.outlook.com> Date: Fri, 15 Jun 2012 16:33:12 -0700 Message-Id: <7C011ECD-070A-49F4-9A41-0AC981F844DE@oracle.com> References: <1339792496.52712.YahooMailNeo@web125501.mail.ne1.yahoo.com> <854774286EF8A240BACC342973A86EAC01667CF7@BL2PRD0310MB387.namprd03.prod.outlook.com> To: "Shuo Chen (MSR)" X-Mailer: Apple Mail (2.1278) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: matake nov , Yuchen Zhou , oauth Subject: Re: [OAUTH-WG] Report an authentication issue X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 23:33:23 -0000 --Apple-Mail=_6C469159-0132-49D6-A672-65A7D0CB73C8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 That sounds like the recent Twitter / thunderclap issue (thunderclap = collected multiple twitter update tokens on a single server to allow = simultaneous tweets to occur from huge numbers of twitter accounts). If BobApp was previously approved as a client and the SP discovered = BobApp was mis-behaving (witness the recent thunderclap twitter = scenario), the SP can simply revoke to tokens issued to BobApp. This just demonstrates why a server should never depend on parseable = bearer tokens by themselves. SPs should check for token revocation. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2012-06-15, at 4:22 PM, Shuo Chen (MSR) wrote: > The attack does not involve sniffing. It is about an app (let=92s call = it BobApp) running on victim Alice=92s tablet, which is able to get the = access token. > Note that BobApp getting this access token on Alice=92s device is NOT = a security issue, but the natural consequence of the design of OAuth. > =20 > However, the real problem we concern about is that server-side = authentication logic takes this access token from the client app, then = queries the user's profile data from the IdP in order to "authenticate" = the user into the server. This implementation pattern causes the real = security problem, because BobApp could send the token to the attacker = Bob, who can now authenticate into the server as Alice on Bob=92s = tablet. > =20 > =D8 and then letting another client use that token > So =93letting another client use the token=94 is not THE = vulnerability, but an attack step that BobApp voluntarily does to = exploit the server-side vulnerability. > =20 > Thanks, > -Shuo > =20 > From: Phil Hunt [mailto:phil.hunt@oracle.com]=20 > Sent: Friday, June 15, 2012 3:59 PM > To: rui wang > Cc: Francisco Corella; matake nov; Yuchen Zhou; oauth; Shuo Chen (MSR) > Subject: Re: [OAUTH-WG] Report an authentication issue > =20 > I am a bit confused. > =20 > It sounds like you are sniffing a bearer token from an unsecured = connection to a resource server and then letting another client use that = token. > =20 > Is this correct? > =20 > Phil > =20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 > =20 >=20 >=20 > =20 > On 2012-06-15, at 3:06 PM, rui wang wrote: >=20 >=20 > Hi, Francisco > =20 > Thank you for your reply. Here is our response for your questions. >=20 > =D8 the attack you describe can be carried out against any app that = uses the OAuth "implicit grant flow", which Facebook calls "client-side = authentication". > =20 > The main concern we raised here is not about attacking client-side = apps. We don=92t think it is a meaningful security consequence when a = client-side application (e.g., a Win8 Metro app, iPhone/iPad app) on the = attacker=92s tablet misidentifies the user as the victim user. = Therefore, you are right about =93this kind of attack can be carried out = against any app using the OAuth =91implicit grant flow=92=94. In fact = we won=92t even call this consequence as an attack. > The real problem is that in multiple occasions, we found that the = server-side authentication logic takes an access token from the client = app, then queries the user's profile data from the IdP in order to = "authenticate" the user into the server. We have confirmed that the = servers for Soluto Metro App, Givit Metro App and EuroCup2012 Metro App = make this mistake. These are apps in the official Windows 8 App Store. = We only sampled a small portion of the available apps, but believe this = is a vulnerability pattern due to a common misunderstanding of the usage = of the access token. > =20 > =D8 I followed the link in your message to the Sophos post, and from = there the link to the article in > The Register. The article in The Register says that Facebook had > "fixed the vulnerability promptly". How did they fix it? The > instructions that Facebook provides for implementing "Client-side > authentication without the JS SDK" at > = https://developers.facebook.com/docs/authentication/client-side/#no-jssdk > still allows the attack. > =20 > I am very sorry for the confusion. The link to Sophos has nothing to = do with this problem. It is about another issue we reported last year. I = mentioned this because the email yesterday was sent to Facebook and the = OAuth mailing list at the same time. I was trying to let the Facebook = team know we had previous communication before. I should have removed = this part in the version sent to OAuth. Again, sorry for not removing = this reference. Please ignore it. > =20 > Thanks, > Rui > On Fri, Jun 15, 2012 at 1:34 PM, Francisco Corella = wrote: > Hi Nat and Rui, >=20 > Rui, you say that the vulnerability that you found was due to a > "common misunderstanding among developers", but the attack you > describe can be carried out against any app that uses the OAuth > "implicit grant flow", which Facebook calls "client-side > authentication". No misunderstanding seems necessary. What > misunderstanding are you referring to? I followed the link in your > message to the Sophos post, and from there the link to the article in > The Register. The article in The Register says that Facebook had > "fixed the vulnerability promptly". How did they fix it? The > instructions that Facebook provides for implementing "Client-side > authentication without the JS SDK" at > = https://developers.facebook.com/docs/authentication/client-side/#no-jssdk > still allows the attack. >=20 > Nat, I agree that the blog post by John Bradley that you link to > refers to the same vulnerability reported by Rui. You say that some > apps have issued a patch to fix it. Could you explain what the fix > was? >=20 > Francisco > =20 > From: Nat Sakimura > To: rui wang =20 > Cc: matake nov ; Yuchen Zhou ; = oauth ; Shuo Chen (MSR) =20 > Sent: Thursday, June 14, 2012 1:50 PM >=20 > Subject: Re: [OAUTH-WG] Report an authentication issue > =20 > This is a fairly well known (hopefully by now) issue. We, at the = OpenID Foundation, call it "access_token phishing" attack these days. = See: = http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.h= tml > =20 > Nov Matake has actually built the code on iPhone to verify the = problem, and has notified bunch of parties back in February including = Facebook and Apple. We have the code that actually runs on a phone, and = we have successfully logged in to bunch of apps, including very well = known ones. They were all informed of the issue. Some immediately issued = a patch to fix it while others have not. =20 > =20 > The problem is that even if these apps gets fixed, the problem does = not go away. As long as the attacker has the vulnerable version of the = app, he still can impersonate the victim. To stop it, the server side = has to completely disable the older version, which means the service has = to cut off many users pausing business problems.=20 > =20 > Nat >=20 > On Fri, Jun 15, 2012 at 2:18 AM, rui wang = wrote: > Dear Facebook Security Team and OAuth Standard group, > We are a research team in Microsoft Research. In January, 2011, we = reported a vulnerability in Facebook Connect which allowed everyone to = sign into Facebook-secured relying parties without password. It was = promptly fixed after reporting. = (http://nakedsecurity.sophos.com/2011/02/02/facebook-flaw-websites-steal-p= ersonal-data/) > Recently, we found a common misunderstanding among developers of = mobile/metro apps when using OAuth (including Facebook=92s OAuth) for = authentication. The vulnerability resulted from this misunderstanding = also allows an attacker to log into a victim user's account without = password. > Let's take Soluto's metro app as an example to describe the problem. = The app supports Facebook Login. As an attacker, we can write a regular = Facebook app. Once the victim user allows our app to access her Facebook = data, we receive an access_token from the traffic. Then, on our own = machine (i.e., the "attacker" machine), we run the metro app of Soluto, = and use a HTTP proxy to insert the victim's access_token into the = traffic of Facebook login. Through this way, we are able to log into the = victim's Soluto account from our machine. Other than Soluto, we also = have confirmed the same issue on another Windows 8 metro-app Givit. > The Facebook SDK for Android apps = (https://developers.facebook.com/docs/mobile/android/build/#sdk) seems = to have the possibility to mislead developers too. At least, the issue = that we found is not clearly mentioned. In the SDK, we ran the sample = code called "Hackbook" using Android Emulator (imagine it is an attacker = device). Note that we have already received the access token of the = victim user from our regular Facebook app. We then inject the token to = the traffic of Hackbook. Through this way, Hackbook app on our own = machine recognizes us as the victim. Note that this is not a convincing = security exploit yet, because this sample code does not include the = server-side code. However, given that we have seen real server-side code = having this problem, such as Soluto, Givit and others, we do believe = that the sample code can mislead mobile/metro developers. We also = suspect that this may be a general issue of many OAuth implementations = on mobile platforms, so we send this message to OAuth Standard group as = well. > We have contacted the vendors of the two vulnerable metro-apps, Soluto = and Gavit. > Please kindly give us an ack when you receive this message. If you = want to know more details, please let us know. > Best Regards, > Yuchen Zhou, Rui Wang, and Shuo Chen >=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 > =20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_6C469159-0132-49D6-A672-65A7D0CB73C8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Phil

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





On 2012-06-15, at 4:22 PM, Shuo Chen (MSR) wrote:

The attack does not involve sniffing. = It is about an app (let=92s call it BobApp) running on victim Alice=92s = tablet, which is able to get the access = token.
Note that BobApp getting this access = token on Alice=92s device is NOT a security = issue, but the natural consequence of the design of = OAuth.
 
However, the real problem we concern about is that server-side = authentication logic takes this access token from the = client app, then queries the user's profile data from the IdP in order = to "authenticate" the user into the server. This implementation pattern = causes the real security problem, because BobApp could send the token to = the attacker Bob, who can now authenticate into the = server as Alice on = Bob=92s tablet.
 
=D8 and = then letting another client use that token
So =93letting another client use the token=94 is not THE = vulnerability, but an attack step that BobApp voluntarily does to = exploit the server-side vulnerability.
 
Thanks,
-Shuo
From: Phil Hunt = [mailto:phil.hunt@oracle.com] 
Sent: Friday, June 15, 2012 3:59 = PM
To: rui = wang
Cc: Francisco Corella; matake = nov; Yuchen Zhou; oauth; Shuo Chen (MSR)
Subject: Re: [OAUTH-WG] Report an = authentication issue
 
I am a bit = confused.
It sounds like you are = sniffing a bearer token from an unsecured connection to a resource = server and then letting another client use that = token.
Is this = correct?
Phil
@independentid
Hi Nat and = Rui,

Rui, you say that the vulnerability that you found was due = to a
"common misunderstanding among developers", but the attack = you
describe can be carried out against any app that uses the = OAuth
"implicit grant flow", which Facebook calls = "client-side
authentication".  No misunderstanding seems = necessary.  What
misunderstanding are you referring to?  I = followed the link in your
message to the Sophos post, and from there = the link to the article in
The Register.  The article in The = Register says that Facebook had
"fixed the vulnerability = promptly".  How did they fix it?  The
instructions that = Facebook provides for implementing "Client-side
authentication = without the JS SDK" at
https://developers.facebook.com/docs/authentication/client-side/#no-jssd= k
still allows the attack.

Nat, I agree that the blog post = by John Bradley that you link to
refers to the same vulnerability = reported by Rui.  You say that some
apps have issued a patch to = fix it.  Could you explain what the = fix
was?

Francisco
From: Nat Sakimura < rui wang <ruiwangwarm@gmail.com> 
Cc: matake nov <nov@matake.jp>; Yuchen Zhou <t-yuzhou@microsoft.com>; = oauth <shuochen@microsoft.com> 
Sent: Thursday, June 14, 2012 = 1:50 PM

Subject: Re: [OAUTH-WG] Report an = authentication issue
 
This is a fairly well known (hopefully by now) issue. = We, at the OpenID Foundation, call it "access_token phishing" attack = these days. See: http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication= .html
Nov Matake has actually = built the code on iPhone to verify the problem, and has notified bunch = of parties back in February including Facebook and Apple. We have the = code that actually runs on a phone, and we have successfully logged in = to bunch of apps, including very well known ones. They were all informed = of the issue. Some immediately issued a patch to fix it while others = have not.  
The problem is that even = if these apps gets fixed, the problem does not go away. As long as the = attacker has the vulnerable version of the app, he still can impersonate = the victim. To stop it, the server side has to completely disable the = older version, which means the service has to cut off many users pausing = business problems. 
 

Nat

On Fri, Jun 15, 2012 at = 2:18 AM, rui wang <Dear Facebook Security Team and OAuth Standard = group,




_______________________________________________
OAuth = mailing list
OAuth@ietf.org
Subject: Re: [OAUTH-WG] Report an authentication issue X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 00:16:45 -0000 --000e0cdf7408e9af0a04c28bd8cb Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable As to how the fix was done, Nov can provide more detail, but ... 1. Properly verify the signature/HMAC of the "signed_request". This will essentially audience restricts the token. 2. There is an undocumented API for Facebook which returns to whom the token was issued. This also audience restricts the token. The service that fixed took these measures. Note that none of the above is defined in OAuth. The same facility was called "id_token" and "check ID endpoint" for OpenID Connect. The scale of the impact is large, too large to disclose the actual names in the public list, though, eventually, we would publish them in a paper. Nat On Sat, Jun 16, 2012 at 5:34 AM, Francisco Corella wro= te: > Hi Nat and Rui, > > Rui, you say that the vulnerability that you found was due to a > "common misunderstanding among developers", but the attack you > describe can be carried out against any app that uses the OAuth > "implicit grant flow", which Facebook calls "client-side > authentication". No misunderstanding seems necessary. What > misunderstanding are you referring to? I followed the link in your > message to the Sophos post, and from there the link to the article in > The Register. The article in The Register says that Facebook had > "fixed the vulnerability promptly". How did they fix it? The > instructions that Facebook provides for implementing "Client-side > authentication without the JS SDK" at > https://developers.facebook.com/docs/authentication/client-side/#no-jssdk > still allows the attack. > > Nat, I agree that the blog post by John Bradley that you link to > refers to the same vulnerability reported by Rui. You say that some > apps have issued a patch to fix it. Could you explain what the fix > was? > > Francisco > > ------------------------------ > *From:* Nat Sakimura > *To:* rui wang > *Cc:* matake nov ; Yuchen Zhou ; > oauth ; Shuo Chen (MSR) > *Sent:* Thursday, June 14, 2012 1:50 PM > *Subject:* Re: [OAUTH-WG] Report an authentication issue > > This is a fairly well known (hopefully by now) issue. We, at the OpenID > Foundation, call it "access_token phishing" attack these days. See: > http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.= html > > Nov Matake has actually built the code on iPhone to verify the problem, > and has notified bunch of parties back in February including Facebook and > Apple. We have the code that actually runs on a phone, and we have > successfully logged in to bunch of apps, including very well known ones. > They were all informed of the issue. Some immediately issued a patch to f= ix > it while others have not. > > The problem is that even if these apps gets fixed, the problem does not g= o > away. As long as the attacker has the vulnerable version of the app, he > still can impersonate the victim. To stop it, the server side has to > completely disable the older version, which means the service has to cut > off many users pausing business problems. > > Nat > > On Fri, Jun 15, 2012 at 2:18 AM, rui wang wrote: > > Dear Facebook Security Team and OAuth Standard group, > We are a research team in Microsoft Research. In January, 2011, we > reported a vulnerability in Facebook Connect which allowed everyone to si= gn > into Facebook-secured relying parties without password. It was promptly > fixed after reporting. ( > http://nakedsecurity.sophos.com/2011/02/02/facebook-flaw-websites-steal-p= ersonal-data/ > ) > Recently, we found a common misunderstanding among developers of > mobile/metro apps when using OAuth (including Facebook=92s OAuth) for > authentication. The vulnerability resulted from this misunderstanding als= o > allows an attacker to log into a victim user's account without password. > Let's take Soluto's metro app as an example to describe the problem. The > app supports Facebook Login. As an attacker, we can write a regular > Facebook app. Once the victim user allows our app to access her Facebook > data, we receive an access_token from the traffic. Then, on our own machi= ne > (i.e., the "attacker" machine), we run the metro app of Soluto, and use a > HTTP proxy to insert the victim's access_token into the traffic of Facebo= ok > login. Through this way, we are able to log into the victim's Soluto > account from our machine. Other than Soluto, we also have confirmed the > same issue on another Windows 8 metro-app Givit. > The Facebook SDK for Android apps ( > https://developers.facebook.com/docs/mobile/android/build/#sdk) seems to > have the possibility to mislead developers too. At least, the issue that = we > found is not clearly mentioned. In the SDK, we ran the sample code called > "Hackbook" using Android Emulator (imagine it is an attacker device). Not= e > that we have already received the access token of the victim user from ou= r > regular Facebook app. We then inject the token to the traffic of Hackbook= . > Through this way, Hackbook app on our own machine recognizes us as the > victim. Note that this is not a convincing security exploit yet, because > this sample code does not include the server-side code. However, given th= at > we have seen real server-side code having this problem, such as Soluto, > Givit and others, we do believe that the sample code can mislead > mobile/metro developers. We also suspect that this may be a general issue > of many OAuth implementations on mobile platforms, so we send this messag= e > to OAuth Standard group as well. > We have contacted the vendors of the two vulnerable metro-apps, Soluto an= d > Gavit. > Please kindly give us an ack when you receive this message. If you want t= o > know more details, please let us know. > Best Regards, > Yuchen Zhou, Rui Wang, and Shuo Chen > > _______________________________________________ > 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 > > > --=20 Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --000e0cdf7408e9af0a04c28bd8cb Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable As to how the fix was done, Nov can provide more detail, but ...=A0


The service that fixed took these measures. Note that n= one of the above is defined in OAuth.=A0
The same facility was ca= lled "id_token" and "check ID endpoint" for OpenID Conn= ect.=A0

The scale of the impact is large, too large to disclose= the actual names in the public list, though, eventually, we would publish = them in a paper.=A0

Nat

On Sat, Jun 16, 2012 at 5:34 AM, Francisco Corella <fcorella@pomcor.com<= /a>> wrote:
Hi Nat and Rui,

Rui, you say that the vulnerability that yo= u found was due to a
"common misunderstanding among developers"= ;, but the attack you
describe can be carried out against any app that uses the OAuth
"im= plicit grant flow", which Facebook calls "client-side
authenti= cation".=A0 No misunderstanding seems necessary.=A0 What
misunderst= anding are you referring to?=A0 I followed the link in your
message to the Sophos post, and from there the link to the article in
Th= e Register.=A0 The article in The Register says that Facebook had
"= fixed the vulnerability promptly".=A0 How did they fix it?=A0 The
i= nstructions that Facebook provides for implementing "Client-side
authentication without the JS SDK" at
= https://developers.facebook.com/docs/authentication/client-side/#no-jssdk
still allows the attack.

Nat, I agree that the blog post by John Bra= dley that you link to
refers to the same vulnerability reported by Rui.= =A0 You say that some
apps have issued a patch to fix it.=A0 Could you e= xplain what the fix
was?

Francisco

From: Nat Sakimura <sakimura@gmail.com>
To: rui wang <ruiwangwarm= @gmail.com>
Cc: m= atake nov <nov@matake= .jp>; Yuchen Zhou <t-yuzhou@microsoft.com>; oauth <oauth@ietf.org>; Shuo Chen (MSR) &l= t;shuochen@micr= osoft.com>
Sent: Thursday, June 14, 20= 12 1:50 PM
Subject: Re: = [OAUTH-WG] Report an authentication issue

This is a fairly well known (hopefully by now) issue. We, at the OpenI= D Foundation, call it "access_token phishing" attack these days. = See:=A0http://www.thread-safe.com/2012/01/= problem-with-oauth-for-authentication.html

Nov Matake has actually built the code on iPhone to verify t= he problem, and has notified bunch of parties back in February including Fa= cebook and Apple. We have the code that actually runs on a phone, and we ha= ve successfully logged in to bunch of apps, including very well known ones.= They were all informed of the issue. Some immediately issued a patch to fi= x it while others have not. =A0

The problem is that even if these apps gets fixed, the = problem does not go away. As long as the attacker has the vulnerable versio= n of the app, he still can impersonate the victim. To stop it, the server s= ide has to completely disable the older version, which means the service ha= s to cut off many users pausing business problems.=A0

Nat

On Fri, Jun 15, 2012 at 2:18 AM, rui wa= ng <ruiwangwarm@gmail.com> wrote:
Dear Facebook Security Team and OAuth Standard group,
We are a research team in Microsoft Research. In January, 2011, we rep= orted a vulnerability in Facebook Connect which allowed everyone to sign in= to Facebook-secured relying parties without password. It was promptly fixed= after reporting. (http://nakedse= curity.sophos.com/2011/02/02/facebook-flaw-websites-steal-personal-data/)
Recently, we found a common misunderstanding among developers of mobil= e/metro apps when using OAuth (including Facebook=92s OAuth) for authentica= tion. The vulnerability resulted from this misunderstanding also allows an = attacker to log into a victim user's account without password.
Let's take Soluto's metro app as an example to describe the pr= oblem. The app supports Facebook Login. As an attacker, we can write a regu= lar Facebook app. Once the victim user allows our app to access her Faceboo= k data, we receive an access_token from the traffic. Then, on our own machi= ne (i.e., the "attacker" machine), we run the metro app of Soluto= , and use a HTTP proxy to insert the victim's access_token into the tra= ffic of Facebook login. Through this way, we are able to log into the victi= m's Soluto account from our machine. Other than Soluto, we also have co= nfirmed the same issue on another Windows 8 metro-app Givit.
The Facebook SDK for Android apps (= https://developers.facebook.com/docs/mobile/android/build/#sdk) seems t= o have the possibility to mislead developers too. At least, the issue that = we found is not clearly mentioned. In the SDK, we ran the sample code calle= d "Hackbook" using Android Emulator (imagine it is an attacker de= vice). Note that we have already received the access token of the victim us= er from our regular Facebook app. We then inject the token to the traffic o= f Hackbook. Through this way, Hackbook app on our own machine recognizes us= as the victim. Note that this is not a convincing security exploit yet, be= cause this sample code does not include the server-side code. However, give= n that we have seen real server-side code having this problem, such as Solu= to, Givit and others, we do believe that the sample code can mislead mobile= /metro developers. We also suspect that this may be a general issue of many OAuth= implementations on mobile platforms, so we send this message to OAuth Stan= dard group as well.
We have contacted the vendors of the two vulnerable metro-apps, Soluto= and Gavit.
Please kindly give us an ack when you receive this message. If you wan= t to know more details, please let us know.
Best Regards,
Yuchen Zhou, Rui Wang, and Shuo Chen

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




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

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





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

--000e0cdf7408e9af0a04c28bd8cb-- From fcorella@pomcor.com Fri Jun 15 17:27:28 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5892111E807F for ; Fri, 15 Jun 2012 17:27:28 -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 9TOaQpHLfgvB for ; Fri, 15 Jun 2012 17:27:26 -0700 (PDT) Received: from nm7-vm2.bullet.mail.ne1.yahoo.com (nm7-vm2.bullet.mail.ne1.yahoo.com [98.138.90.155]) by ietfa.amsl.com (Postfix) with SMTP id 7471511E80CE for ; Fri, 15 Jun 2012 17:27:26 -0700 (PDT) Received: from [98.138.90.53] by nm7.bullet.mail.ne1.yahoo.com with NNFMP; 16 Jun 2012 00:27:23 -0000 Received: from [98.138.88.236] by tm6.bullet.mail.ne1.yahoo.com with NNFMP; 16 Jun 2012 00:27:23 -0000 Received: from [127.0.0.1] by omp1036.mail.ne1.yahoo.com with NNFMP; 16 Jun 2012 00:27:23 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 273324.78546.bm@omp1036.mail.ne1.yahoo.com Received: (qmail 31927 invoked by uid 60001); 16 Jun 2012 00:27:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1339806443; bh=aVgJ3+Mx/cNQtHExob4AUEVk53Pb5EA0gpHhAd0IpYg=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=b8v74m+t2OIFS3xig2QusAtDNIZ0oG4YPL1rpvh/zzv1D25fytOjhjAQxIvl61z8Z1vGrZj5IMO4Y3IyAsIxaFG3xVDkGpvUDmjz5yhB58O2xi0o6bEHgdF26jzvLE1W5zaFdC6qHHSot/jt9ClTgBlKlzvIc4ZQcPTXB+L7xz0= X-YMail-OSG: bkJVVAMVM1m7u_xGMj4KPqxExQrSQEvqUia5bLhTsy0TaxB 9YL92iXFOhlxaT5JJ299FIsuEYmUNYvoA1sDXi1kr.2XaP51YIuHSjc7BKEO 8XMVpU7WZrnxpSMA9kTdQqWc.WBaPj7p4_de8zx_CoxClVS8L_3GZhG5R4_V fJyGNi.UEe2LR1VrlQGnaPd_UNrZ7k_H_PNctJ9o5cD2fRVHfM2GZCaHzItf P9JiXT1ELLDgapHX5tAkc2CsCb8Nwm8urK0jRnxg4N5_MwlRe7se6rwQMOFl EP1hPRFIw9NX_dqVEID9_ajn9rNTO5Q_TLZze_VAtRgXTgKXnCGGao3LK_P. SkeWXyjWsBHeBGpmQlssuY3wCOwpvHD9nrt1Nz5eGMnwj1MnKvt7qGPpbxy2 N7.nsoE7vHRFI8jGTXN6uVL1PG51RZwB0e6C.5SJv9oO3O8AN9HDtXFo82On vms5CxOZbSEpNDmEaeim6tfWCbRO3VvrzapxDfttM6u8e9iwquwx_jYqWsi8 SN11n2BgFb5PHkzP0H_k8LUJPqG_ezJofTJI9O2c2Ub6NPugt5se1iIwtw4L B4zAPKD4VoCHXYYZYgNOxekrROZ50WpdCMmobfpbYn3HmFsoIfVN9fp32uqo 2bNYDEHJw1dlDf3mwJ0tP.0sGlsV8.CjNN1PgdKZPavD1pHPA3gJO_S66ulR XISoqDofdaBJBPAR4z.xxxlbOgmIIlmZpzoKiFD2c1GEdl00MhFtryjZH2Bq LxhrtLxytMfg3PAihuVrVu_tlN5BthRvg8agSOJZTweNSYpwJ3WmGqyuCYkg bJYXfZgbnjSM9IDZjgSPu6tR9e5T1b5MnIOs3FqMFRS4HWAHjrPIoGZz_rel AEZE2pKGgKl8AcJ.r6BbUWotpEtxCHQtETf_piU2QMdoeyxfHMdtlq8jS.A- - Received: from [68.8.105.216] by web125505.mail.ne1.yahoo.com via HTTP; Fri, 15 Jun 2012 17:27:22 PDT X-RocketYMMF: francisco_corella X-Mailer: YahooMailWebService/0.8.118.349524 References: <1339792496.52712.YahooMailNeo@web125501.mail.ne1.yahoo.com> Message-ID: <1339806442.14665.YahooMailNeo@web125505.mail.ne1.yahoo.com> Date: Fri, 15 Jun 2012 17:27:22 -0700 (PDT) From: Francisco Corella To: rui wang In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-781490481-1738368359-1339806442=:14665" Cc: matake nov , Yuchen Zhou , oauth , "Shuo Chen \(MSR\)" Subject: Re: [OAUTH-WG] Report an authentication issue X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Francisco Corella List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jun 2012 00:27:28 -0000 ---781490481-1738368359-1339806442=:14665 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Rui, my fault about the Sophos link.=C2=A0 I hadn't read your message ca= refully enough, otherwise I would have realized that it was unrelated.=C2= =A0=C2=A0=C2=A0 - Francisco=0A=0A=C2=A0=0A=0A=0A>__________________________= ______=0A> From: rui wang =0A>To: Francisco Corella = =0A>Cc: Nat Sakimura ; matake nov= ; Yuchen Zhou ; oauth ; Shuo Chen (MSR) =0A>Sent: Friday, June 15, 20= 12 3:06 PM=0A>Subject: Re: [OAUTH-WG] Report an authentication issue=0A> = =0A>=0A>Hi, Francisco=0A>=C2=A0=0A>Thank you for your reply. Here is our re= sponse for your questions.=0A>=0A>=C3=98=C2=A0 the attack you describe can = be carried out against any app that uses the OAuth "implicit grant flow", w= hich Facebook calls "client-side authentication".=0A>=C2=A0=0A>The main con= cern we raised here is not about attacking client-side apps. We don=E2=80= =99t think it is a meaningful security consequence when a client-side appli= cation (e.g., a Win8 Metro app, iPhone/iPad app) on the attacker=E2=80=99s = tablet misidentifies the user as the victim user. Therefore, you are right = about =E2=80=9Cthis kind of attack can be carried out against any app=C2=A0= using the OAuth =E2=80=98implicit grant flow=E2=80=99=E2=80=9D. In fact we= won=E2=80=99t even call this consequence as an attack. =0A>The real proble= m is that in multiple occasions, we found that the server-side authenticati= on logic takes an access token from the client app, then queries the user's= profile data from the IdP in order to "authenticate" the user into the ser= ver. We have confirmed that the servers for Soluto Metro App, Givit Metro A= pp and EuroCup2012 Metro App make this mistake. These are apps in the offic= ial Windows 8 App Store. We only sampled a small portion of the available a= pps, but believe this is a vulnerability pattern due to a common misunderst= anding of the usage of the access token.=0A>=C2=A0=0A>=C3=98=C2=A0 I follow= ed the link in your message to the Sophos post, and from there the link to = the article in=0A>The Register.=C2=A0 The article in The Register says that= Facebook had=0A>"fixed the vulnerability promptly".=C2=A0 How did they fix= it?=C2=A0 The=0A>instructions that Facebook provides for implementing "Cli= ent-side=0A>authentication without the JS SDK" at=0A>https://developers.fac= ebook.com/docs/authentication/client-side/#no-jssdk=0A>still allows the att= ack.=0A>=C2=A0=0A>I am very sorry for the confusion. The link to Sophos has= nothing to do with this problem. It is about another issue we reported las= t year. I mentioned this because the email yesterday was sent to Facebook a= nd the OAuth mailing list at the same time. I was trying to let the Faceboo= k team know we had previous communication before. I should have removed thi= s part in the version sent to OAuth. Again, sorry for not removing this ref= erence. Please ignore it.=0A>=C2=A0=0A>Thanks,=0A>Rui=0A>On Fri, Jun 15, 20= 12 at 1:34 PM, Francisco Corella wrote:=0A>=0A>Hi Nat= and Rui,=0A>>=0A>>Rui, you say that the vulnerability that you found was d= ue to a=0A>>"common misunderstanding among developers", but the attack you= =0A>>describe can be carried out against any app that uses the OAuth=0A>>"i= mplicit grant flow", which Facebook calls "client-side=0A>>authentication".= =C2=A0 No misunderstanding seems necessary.=C2=A0 What=0A>>misunderstanding= are you referring to?=C2=A0 I followed the link in your=0A>>message to the= Sophos post, and from there the link to the article in=0A>>The Register.= =C2=A0 The article in The Register says that Facebook had=0A>>"fixed the vu= lnerability promptly".=C2=A0 How did they fix it?=C2=A0 The=0A>>instruction= s that Facebook provides for implementing "Client-side=0A>>authentication w= ithout the JS SDK" at=0A>>https://developers.facebook.com/docs/authenticati= on/client-side/#no-jssdk=0A>>still allows the attack.=0A>>=0A>>Nat, I agree= that the blog post by John Bradley that you link to=0A>>refers to the same= vulnerability reported by Rui.=C2=A0 You say that some=0A>>apps have issue= d a patch to fix it.=C2=A0 Could you explain what the fix=0A>>was?=0A>>=0A>= >Francisco=0A>>=0A>>=0A>>=0A>>=0A>>>________________________________=0A>>> = From: Nat Sakimura =0A>>>To: rui wang =0A>>>Cc: matake nov ; Yuchen Zhou ; oauth ; Shuo Chen (MSR) = =0A>>>Sent: Thursday, June 14, 2012 1:50 PM =0A>>>=0A>>>Subject: Re: [OAUTH= -WG] Report an authentication issue=0A>>>=0A>>>=0A>>>This is a fairly well = known (hopefully by now) issue. We, at the OpenID Foundation, call it "acce= ss_token phishing" attack these days. See:=C2=A0http://www.thread-safe.com/= 2012/01/problem-with-oauth-for-authentication.html =0A>>>=0A>>>=0A>>>Nov Ma= take has actually built the code on iPhone to verify the problem, and has n= otified bunch of parties back in February including Facebook and Apple. We = have the code that actually runs on a phone, and we have successfully logge= d in to bunch of apps, including very well known ones. They were all inform= ed of the issue. Some immediately issued a patch to fix it while others hav= e not. =C2=A0=0A>>>=0A>>>=0A>>>The problem is that even if these apps gets = fixed, the problem does not go away. As long as the attacker has the vulner= able version of the app, he still can impersonate the victim. To stop it, t= he server side has to completely disable the older version, which means the= service has to cut off many users pausing business problems.=C2=A0=0A>>>= =0A>>>=0A>>>Nat=0A>>>=0A>>>=0A>>>On Fri, Jun 15, 2012 at 2:18 AM, rui wang = wrote:=0A>>>=0A>>>Dear Facebook Security Team and O= Auth Standard group,=0A>>>>We are a research team in Microsoft Research. In= January, 2011, we reported a vulnerability in Facebook Connect which allow= ed everyone to sign into Facebook-secured relying parties without password.= It was promptly fixed after reporting. (http://nakedsecurity.sophos.com/20= 11/02/02/facebook-flaw-websites-steal-personal-data/)=0A>>>>Recently, we fo= und a common misunderstanding among developers of mobile/metro apps when us= ing OAuth (including Facebook=E2=80=99s OAuth) for authentication. The vuln= erability resulted from this misunderstanding also allows an attacker to lo= g into a victim user's account without password.=0A>>>>Let's take Soluto's = metro app as an example to describe the problem. The app supports Facebook = Login. As an attacker, we can write a regular Facebook app. Once the victim= user allows our app to access her Facebook data, we receive an access_toke= n from the traffic. Then, on our own machine (i.e., the "attacker" machine)= , we run the metro app of Soluto, and use a HTTP proxy to insert the victim= 's access_token into the traffic of Facebook login. Through this way, we ar= e able to log into the victim's Soluto account from our machine. Other than= Soluto, we also have confirmed the same issue on another Windows 8 metro-a= pp Givit.=0A>>>>The Facebook SDK for Android apps (https://developers.faceb= ook.com/docs/mobile/android/build/#sdk) seems to have the possibility to mi= slead developers too. At least, the issue that we found is not clearly ment= ioned. In the SDK, we ran the sample code called "Hackbook" using Android E= mulator (imagine it is an attacker device). Note that we have already recei= ved the access token of the victim user from our regular Facebook app. We t= hen inject the token to the traffic of Hackbook. Through this way, Hackbook= app on our own machine recognizes us as the victim. Note that this is not = a convincing security exploit yet, because this sample code does not includ= e the server-side code. However, given that we have seen real server-side c= ode having this problem, such as Soluto, Givit and others, we do believe th= at the sample code can mislead mobile/metro developers. We also suspect tha= t this may be a general issue of many OAuth implementations on mobile platf= orms, so we send this message to OAuth Standard group as well.=0A>>>>We have con= tacted the vendors of the two vulnerable metro-apps, Soluto and Gavit.=0A>>= >>Please kindly give us an ack when you receive this message. If you want t= o know more details, please let us know.=0A>>>>Best Regards,=0A>>>>Yuchen Z= hou, Rui Wang, and Shuo Chen=0A>>>>________________________________________= _______=0A>>>>OAuth mailing list=0A>>>>OAuth@ietf.org=0A>>>>https://www.iet= f.org/mailman/listinfo/oauth=0A>>>>=0A>>>>=0A>>>=0A>>>=0A>>>=0A>>>-- =0A>>>= Nat Sakimura (=3Dnat) =0A>>>Chairman, OpenID Foundation=0A>>>http://nat.sak= imura.org/=0A>>>@_nat_en=0A>>>=0A>>>_______________________________________= ________=0A>>>OAuth mailing list=0A>>>OAuth@ietf.org=0A>>>https://www.ietf.= org/mailman/listinfo/oauth=0A>>>=0A>>>=0A>>>=0A>=0A>=0A> ---781490481-1738368359-1339806442=:14665 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
=0A

---781490481-1738368359-1339806442=:14665-- From sakimura@gmail.com Fri Jun 15 17:30:32 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 281EF11E807F for ; Fri, 15 Jun 2012 17:30:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.165 X-Spam-Level: X-Spam-Status: No, score=-3.165 tagged_above=-999 required=5 tests=[AWL=0.433, 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 1AE251yH4YIh for ; Fri, 15 Jun 2012 17:30:27 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4E64011E80CE for ; Fri, 15 Jun 2012 17:30:26 -0700 (PDT) Received: by bkty8 with SMTP id y8so3140747bkt.31 for ; Fri, 15 Jun 2012 17:30:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XQaPu27Is775+EtTdICCbS0rkUxFs3huTY4nCGh4mYg=; b=fZdSUa/KV1nQAzJuO02xFS+3BUurCefZ4EJBZC3po2YXaJ7TasVnaidwnsgjmQZ+nl o+tjCoog4jtCvMryAxGih7AcJbWdHBOfM3FEJUDpBfupSavXPcyZv8M52iYdlWWGYb/S grIXdvklqjLZ8fbzc+eRBSVXPZ4PPAF0LcMTH9C6xpdxY4DGx7+DIhgTGfYV9vVSG6NE w4bnRVKdWXuKEKs1G6UiPWiuJqlyxHJM4atlV68Ud2TpxCCTiZ97bI9JgOT5qikV28gb qHePM9IQy3HoN9LkXTN3hr4dM4Dhuia63/jCqPKL1ynpW6VzrBI7r2MROF22bCjGT6PK lPSg== MIME-Version: 1.0 Received: by 10.204.152.203 with SMTP id h11mr3490224bkw.122.1339806625195; Fri, 15 Jun 2012 17:30:25 -0700 (PDT) Received: by 10.204.240.143 with HTTP; Fri, 15 Jun 2012 17:30:25 -0700 (PDT) In-Reply-To: References: <1339792496.52712.YahooMailNeo@web125501.mail.ne1.yahoo.com> Date: Sat, 16 Jun 2012 09:30:25 +0900 Message-ID: From: Nat Sakimura To: Phil Hunt Content-Type: multipart/alternative; boundary=0015175cabd8f6660b04c28c0948 Cc: matake nov , Yuchen Zhou , oauth , "Shuo Chen \(MSR\)" Subject: Re: [OAUTH-WG] Report an authentication issue X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 00:30:32 -0000 --0015175cabd8f6660b04c28c0948 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable No. You do not need the sniffing in an unsecured connection. But I am not sure if I should disclose the detail of the attack here in the public list as that will open up a much more serious attack vector than leaked passwords hash in recent incidents. OAuth is not an authentication protocol. It is an access delegation protocol. The fact that one has an authorization to access an API does not mean that he is the subject. There are bunch of assumptions that have to be fulfilled for OAuth to act as an entity authentication. If you pass a token from a client to another, e.g., from an APP to the server side component, the assumption is violated. And, this is not only the condition, but there are others as well. That's why we have been creating OpenID Connect. OpenID Connect adds bunch of restrictions on OAuth 2.0. They are the things you have to do before you can use OAuth 2.0 as an authentication protocol. Best, Nat On Sat, Jun 16, 2012 at 7:58 AM, Phil Hunt wrote: > I am a bit confused. > > It sounds like you are sniffing a bearer token from an unsecured > connection to a resource server and then letting another client use that > token. > > Is this correct? > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > On 2012-06-15, at 3:06 PM, rui wang wrote: > > Hi, Francisco > > Thank you for your reply. Here is our response for your questions. > > =D8 the attack you describe can be carried out against any app that uses > the OAuth "implicit grant flow", which Facebook calls "client-side > authentication". > > The main concern we raised here is not about attacking client-side apps. > We don=92t think it is a meaningful security consequence when a client-si= de > application (e.g., a Win8 Metro app, iPhone/iPad app) on the attacker=92s > tablet misidentifies the user as the victim user. Therefore, you are righ= t > about =93this kind of attack can be carried out against any app using th= e > OAuth =91implicit grant flow=92=94. In fact we won=92t even call this con= sequence > as an attack. > The real problem is that in multiple occasions, we found that the > server-side authentication logic takes an access token from the client ap= p, > then queries the user's profile data from the IdP in order to > "authenticate" the user into the server. We have confirmed that the serve= rs > for Soluto Metro App, Givit Metro App and EuroCup2012 Metro App make this > mistake. These are apps in the official Windows 8 App Store. We only > sampled a small portion of the available apps, but believe this is a > vulnerability pattern due to a common misunderstanding of the usage of th= e > access token. > > =D8 I followed the link in your message to the Sophos post, and from the= re > the link to the article in > The Register. The article in The Register says that Facebook had > "fixed the vulnerability promptly". How did they fix it? The > instructions that Facebook provides for implementing "Client-side > authentication without the JS SDK" at > https://developers.facebook.com/docs/authentication/client-side/#no-jssdk > still allows the attack. > > I am very sorry for the confusion. The link to Sophos has nothing to do > with this problem. It is about another issue we reported last year. I > mentioned this because the email yesterday was sent to Facebook and the > OAuth mailing list at the same time. I was trying to let the Facebook tea= m > know we had previous communication before. I should have removed this par= t > in the version sent to OAuth. Again, sorry for not removing this referenc= e. > Please ignore it. > > Thanks, > Rui > On Fri, Jun 15, 2012 at 1:34 PM, Francisco Corella w= rote: > >> Hi Nat and Rui, >> >> Rui, you say that the vulnerability that you found was due to a >> "common misunderstanding among developers", but the attack you >> describe can be carried out against any app that uses the OAuth >> "implicit grant flow", which Facebook calls "client-side >> authentication". No misunderstanding seems necessary. What >> misunderstanding are you referring to? I followed the link in your >> message to the Sophos post, and from there the link to the article in >> The Register. The article in The Register says that Facebook had >> "fixed the vulnerability promptly". How did they fix it? The >> instructions that Facebook provides for implementing "Client-side >> authentication without the JS SDK" at >> https://developers.facebook.com/docs/authentication/client-side/#no-jssd= k >> still allows the attack. >> >> Nat, I agree that the blog post by John Bradley that you link to >> refers to the same vulnerability reported by Rui. You say that some >> apps have issued a patch to fix it. Could you explain what the fix >> was? >> >> Francisco >> >> ------------------------------ >> *From:* Nat Sakimura >> *To:* rui wang >> *Cc:* matake nov ; Yuchen Zhou ; >> oauth ; Shuo Chen (MSR) >> *Sent:* Thursday, June 14, 2012 1:50 PM >> >> *Subject:* Re: [OAUTH-WG] Report an authentication issue >> >> This is a fairly well known (hopefully by now) issue. We, at the OpenID >> Foundation, call it "access_token phishing" attack these days. See: >> http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication= .html >> >> Nov Matake has actually built the code on iPhone to verify the problem, >> and has notified bunch of parties back in February including Facebook an= d >> Apple. We have the code that actually runs on a phone, and we have >> successfully logged in to bunch of apps, including very well known ones. >> They were all informed of the issue. Some immediately issued a patch to = fix >> it while others have not. >> >> The problem is that even if these apps gets fixed, the problem does not >> go away. As long as the attacker has the vulnerable version of the app, = he >> still can impersonate the victim. To stop it, the server side has to >> completely disable the older version, which means the service has to cut >> off many users pausing business problems. >> >> Nat >> >> On Fri, Jun 15, 2012 at 2:18 AM, rui wang wrote: >> >> Dear Facebook Security Team and OAuth Standard group, >> We are a research team in Microsoft Research. In January, 2011, we >> reported a vulnerability in Facebook Connect which allowed everyone to s= ign >> into Facebook-secured relying parties without password. It was promptly >> fixed after reporting. ( >> http://nakedsecurity.sophos.com/2011/02/02/facebook-flaw-websites-steal-= personal-data/ >> ) >> Recently, we found a common misunderstanding among developers of >> mobile/metro apps when using OAuth (including Facebook=92s OAuth) for >> authentication. The vulnerability resulted from this misunderstanding al= so >> allows an attacker to log into a victim user's account without password. >> Let's take Soluto's metro app as an example to describe the problem. The >> app supports Facebook Login. As an attacker, we can write a regular >> Facebook app. Once the victim user allows our app to access her Facebook >> data, we receive an access_token from the traffic. Then, on our own mach= ine >> (i.e., the "attacker" machine), we run the metro app of Soluto, and use = a >> HTTP proxy to insert the victim's access_token into the traffic of Faceb= ook >> login. Through this way, we are able to log into the victim's Soluto >> account from our machine. Other than Soluto, we also have confirmed the >> same issue on another Windows 8 metro-app Givit. >> The Facebook SDK for Android apps ( >> https://developers.facebook.com/docs/mobile/android/build/#sdk) seems to >> have the possibility to mislead developers too. At least, the issue that= we >> found is not clearly mentioned. In the SDK, we ran the sample code calle= d >> "Hackbook" using Android Emulator (imagine it is an attacker device). No= te >> that we have already received the access token of the victim user from o= ur >> regular Facebook app. We then inject the token to the traffic of Hackboo= k. >> Through this way, Hackbook app on our own machine recognizes us as the >> victim. Note that this is not a convincing security exploit yet, because >> this sample code does not include the server-side code. However, given t= hat >> we have seen real server-side code having this problem, such as Soluto, >> Givit and others, we do believe that the sample code can mislead >> mobile/metro developers. We also suspect that this may be a general issu= e >> of many OAuth implementations on mobile platforms, so we send this messa= ge >> to OAuth Standard group as well. >> We have contacted the vendors of the two vulnerable metro-apps, Soluto >> and Gavit. >> Please kindly give us an ack when you receive this message. If you want >> to know more details, please let us know. >> Best Regards, >> Yuchen Zhou, Rui Wang, and Shuo Chen >> >> _______________________________________________ >> 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 > > > > _______________________________________________ > 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 --0015175cabd8f6660b04c28c0948 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable No. You do not need the sniffing in an unsecured connection.=A0

But I am not sure if I should disclose the detail of the attack her= e in the public list as that will open up a much more serious attack vector= than leaked passwords hash in recent incidents.=A0

OAuth is not an authentication protocol. It is an acces= s delegation protocol.=A0
The fact that one has an authorization = to access an API does not mean that he is the subject.=A0
There a= re bunch of assumptions that have to be fulfilled for OAuth to act as an en= tity authentication.=A0
If you pass a token from a client to another, e.g., from an APP to the= server side component, the assumption is violated.=A0
And, this = is not only the condition, but there are others as well.=A0

<= /div>
That's why we have been creating OpenID Connect. OpenID Connect ad= ds bunch of restrictions on OAuth 2.0. They are the things you have to do b= efore you can use OAuth 2.0 as an authentication protocol.

Best,=A0

Nat

On Sat, Jun 16, 2012 at 7:58 AM, Phil Hunt <phil.hunt@= oracle.com> wrote:
I am a b= it confused.

It sounds like you are sniffing a bearer to= ken from an unsecured connection to a resource server and then letting anot= her client use that token.

Is this correct?


On 2012-06-15, at 3:06 PM, rui wang wrote:

Hi, Francisco
=A0
Thank you for your reply. Here is our response for your questions.
=
=D8=A0 the attack you describe can be carried out against any app that = uses the OAuth "implicit grant flow", which Facebook calls "= client-side authentication".
=A0
The main concern we raised here is not about a= ttacking client-side apps. We don=92t think it is a meaningful security con= sequence when a client-side application (e.g., a Win8 Metro app, iPhone/iPa= d app) on the attacker=92s tablet misidentifies the user as the victim user= . Therefore, you are right about =93this kind of attack can be carried out = against any app=A0 using the OAuth =91implicit grant flow=92=94. In fact we= won=92t even call this consequence as an attack.
The real problem is that in multiple occasions= , we found that the server-side authentication logic takes an access token = from the client app, then queries the user's profile data from the IdP = in order to "authenticate" the user into the server. We have conf= irmed that the servers for Soluto Metro App, Givit Metro App and EuroCup201= 2 Metro App make this mistake. These are apps in the official Windows 8 App= Store. We only sampled a small portion of the available apps, but believe = this is a vulnerability pattern due to a common misunderstanding of the usa= ge of the access token.
=A0
=D8=A0 I followed the link in your message to the Sophos post, and fro= m there the link to the article in
The Register.=A0 The article in The R= egister says that Facebook had
"fixed the vulnerability promptly&qu= ot;.=A0 How did they fix it?=A0 The
instructions that Facebook provides for implementing "Client-side
a= uthentication without the JS SDK" at
h= ttps://developers.facebook.com/docs/authentication/client-side/#no-jssdk
still allows the attack.
=A0
I am very sorry for the confusion. The link to= Sophos has nothing to do with this problem. It is about another issue we r= eported last year. I mentioned this because the email yesterday was sent to= Facebook and the OAuth mailing list at the same time. I was trying to let = the Facebook team know we had previous communication before. I should have = removed this part in the version sent to OAuth. Again, sorry for not removi= ng this reference. Please ignore it.
=A0
Thanks,
Rui
On Fri, Jun 15, 2012 at 1:34 PM, Francisco Corel= la <fcorella@pomcor.com> wrote:
Hi Nat and Rui,

Rui, you say that the vulnerability that you fou= nd was due to a
"common misunderstanding among developers", bu= t the attack you
describe can be carried out against any app that uses the OAuth
"im= plicit grant flow", which Facebook calls "client-side
authenti= cation".=A0 No misunderstanding seems necessary.=A0 What
misunderst= anding are you referring to?=A0 I followed the link in your
message to the Sophos post, and from there the link to the article in
Th= e Register.=A0 The article in The Register says that Facebook had
"= fixed the vulnerability promptly".=A0 How did they fix it?=A0 The
i= nstructions that Facebook provides for implementing "Client-side
authentication without the JS SDK" at
= https://developers.facebook.com/docs/authentication/client-side/#no-jssdk
still allows the attack.

Nat, I agree that the blog post by John Bra= dley that you link to
refers to the same vulnerability reported by Rui.= =A0 You say that some
apps have issued a patch to fix it.=A0 Could you e= xplain what the fix
was?

Francisco

From: Nat Sakimura <sakimura@gmail.com&g= t;
To: rui wang <ruiwangwarm@gmail.com= >
Cc: matake nov <nov@matake.jp>; Yuchen Z= hou <t-yuzho= u@microsoft.com>; oauth <oauth@ietf.org>; Shuo Chen (MSR) <shuochen@microsoft.com> Sent: Thursday, June 14, 201= 2 1:50 PM=20

Subject: Re: [OAUTH= -WG] Report an authentication issue

This is a fairly well known (hopefully by now) issue. We, at the OpenI= D Foundation, call it "access_token phishing" attack these days. = See:=A0http://www.thread-safe.com/2012/01/= problem-with-oauth-for-authentication.html=20

Nov Matake has actually built the code on iPhone to verify the problem= , and has notified bunch of parties back in February including Facebook and= Apple. We have the code that actually runs on a phone, and we have success= fully logged in to bunch of apps, including very well known ones. They were= all informed of the issue. Some immediately issued a patch to fix it while= others have not. =A0

The problem is that even if these apps gets fixed, the problem does no= t go away. As long as the attacker has the vulnerable version of the app, h= e still can impersonate the victim. To stop it, the server side has to comp= letely disable the older version, which means the service has to cut off ma= ny users pausing business problems.=A0

Nat

On Fri, Jun 15, 2012 at 2:18 AM, rui wang <ruiwa= ngwarm@gmail.com> wrote:
Dear Facebook Security Team and OAuth Standard group,
We are a research team in Microsoft Research. In January, 2011, we rep= orted a vulnerability in Facebook Connect which allowed everyone to sign in= to Facebook-secured relying parties without password. It was promptly fixed= after reporting. (http://nakedse= curity.sophos.com/2011/02/02/facebook-flaw-websites-steal-personal-data/)
Recently, we found a common misunderstanding among developers of mobil= e/metro apps when using OAuth (including Facebook=92s OAuth) for authentica= tion. The vulnerability resulted from this misunderstanding also allows an = attacker to log into a victim user's account without password.
Let's take Soluto's metro app as an example to describe the pr= oblem. The app supports Facebook Login. As an attacker, we can write a regu= lar Facebook app. Once the victim user allows our app to access her Faceboo= k data, we receive an access_token from the traffic. Then, on our own machi= ne (i.e., the "attacker" machine), we run the metro app of Soluto= , and use a HTTP proxy to insert the victim's access_token into the tra= ffic of Facebook login. Through this way, we are able to log into the victi= m's Soluto account from our machine. Other than Soluto, we also have co= nfirmed the same issue on another Windows 8 metro-app Givit.
The Facebook SDK for Android apps (= https://developers.facebook.com/docs/mobile/android/build/#sdk) seems t= o have the possibility to mislead developers too. At least, the issue that = we found is not clearly mentioned. In the SDK, we ran the sample code calle= d "Hackbook" using Android Emulator (imagine it is an attacker de= vice). Note that we have already received the access token of the victim us= er from our regular Facebook app. We then inject the token to the traffic o= f Hackbook. Through this way, Hackbook app on our own machine recognizes us= as the victim. Note that this is not a convincing security exploit yet, be= cause this sample code does not include the server-side code. However, give= n that we have seen real server-side code having this problem, such as Solu= to, Givit and others, we do believe that the sample code can mislead mobile= /metro developers. We also suspect that this may be a general issue of many= OAuth implementations on mobile platforms, so we send this message to OAut= h Standard group as well.
We have contacted the vendors of the two vulnerable metro-apps, Soluto= and Gavit.
Please kindly give us an ack when you receive this message. If you wan= t to know more details, please let us know.
Best Regards,
Yuchen Zhou, Rui Wang, and Shuo Chen

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




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


_______________________________________________
OAuth mailing lis= t
OAuth@ietf.org
<= a href=3D"https://www.ietf.org/mailman/listinfo/oauth" target=3D"_blank">ht= tps://www.ietf.org/mailman/listinfo/oauth


=

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


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




--
Nat Saki= mura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
=
--0015175cabd8f6660b04c28c0948-- From phil.hunt@oracle.com Fri Jun 15 17:52:06 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 617AD21F8494 for ; Fri, 15 Jun 2012 17:52:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.761 X-Spam-Level: X-Spam-Status: No, score=-9.761 tagged_above=-999 required=5 tests=[AWL=-0.559, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 dfWuJNtMko6N for ; Fri, 15 Jun 2012 17:52:04 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id 6679021F844B for ; Fri, 15 Jun 2012 17:52:04 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q5G0q1fn030922 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 16 Jun 2012 00:52:02 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 q5G0q0aq029664 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 16 Jun 2012 00:52:01 GMT Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q5G0q0FD016775; Fri, 15 Jun 2012 19:52:00 -0500 Received: from [192.168.1.125] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 15 Jun 2012 17:52:00 -0700 References: <1339792496.52712.YahooMailNeo@web125501.mail.ne1.yahoo.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-3288AEA0-C8CF-4DAB-9B6D-25373CAF7596 Message-Id: <579AA814-426B-434B-8493-5262C7ED63FF@oracle.com> X-Mailer: iPhone Mail (9B206) From: Phil Hunt Date: Fri, 15 Jun 2012 17:55:00 -0700 To: Nat Sakimura X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: matake nov , Yuchen Zhou , oauth , "Shuo Chen \(MSR\)" Subject: Re: [OAUTH-WG] Report an authentication issue X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 00:52:06 -0000 --Apple-Mail-3288AEA0-C8CF-4DAB-9B6D-25373CAF7596 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Ok. Are you recommending specific changes that should be made to the group? Phil On 2012-06-15, at 17:30, Nat Sakimura wrote: > No. You do not need the sniffing in an unsecured connection.=20 >=20 > But I am not sure if I should disclose the detail of the attack here in th= e public list as that will open up a much more serious attack vector than le= aked passwords hash in recent incidents.=20 >=20 > OAuth is not an authentication protocol. It is an access delegation protoc= ol.=20 > The fact that one has an authorization to access an API does not mean that= he is the subject.=20 > There are bunch of assumptions that have to be fulfilled for OAuth to act a= s an entity authentication.=20 > If you pass a token from a client to another, e.g., from an APP to the ser= ver side component, the assumption is violated.=20 > And, this is not only the condition, but there are others as well.=20 >=20 > That's why we have been creating OpenID Connect. OpenID Connect adds bunch= of restrictions on OAuth 2.0. They are the things you have to do before you= can use OAuth 2.0 as an authentication protocol. >=20 > Best,=20 >=20 > Nat >=20 > On Sat, Jun 16, 2012 at 7:58 AM, Phil Hunt wrote: > I am a bit confused. >=20 > It sounds like you are sniffing a bearer token from an unsecured connectio= n to a resource server and then letting another client use that token. >=20 > Is this correct? >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 >=20 >=20 > On 2012-06-15, at 3:06 PM, rui wang wrote: >=20 >> Hi, Francisco >> =20 >> Thank you for your reply. Here is our response for your questions. >>=20 >> =C3=98 the attack you describe can be carried out against any app that u= ses the OAuth "implicit grant flow", which Facebook calls "client-side authe= ntication". >> =20 >> The main concern we raised here is not about attacking client-side apps. W= e don=E2=80=99t think it is a meaningful security consequence when a client-= side application (e.g., a Win8 Metro app, iPhone/iPad app) on the attacker=E2= =80=99s tablet misidentifies the user as the victim user. Therefore, you are= right about =E2=80=9Cthis kind of attack can be carried out against any app= using the OAuth =E2=80=98implicit grant flow=E2=80=99=E2=80=9D. In fact we= won=E2=80=99t even call this consequence as an attack. >> The real problem is that in multiple occasions, we found that the server-= side authentication logic takes an access token from the client app, then qu= eries the user's profile data from the IdP in order to "authenticate" the us= er into the server. We have confirmed that the servers for Soluto Metro App,= Givit Metro App and EuroCup2012 Metro App make this mistake. These are apps= in the official Windows 8 App Store. We only sampled a small portion of the= available apps, but believe this is a vulnerability pattern due to a common= misunderstanding of the usage of the access token. >> =20 >> =C3=98 I followed the link in your message to the Sophos post, and from t= here the link to the article in >> The Register. The article in The Register says that Facebook had >> "fixed the vulnerability promptly". How did they fix it? The >> instructions that Facebook provides for implementing "Client-side >> authentication without the JS SDK" at >> https://developers.facebook.com/docs/authentication/client-side/#no-jssdk= >> still allows the attack. >> =20 >> I am very sorry for the confusion. The link to Sophos has nothing to do w= ith this problem. It is about another issue we reported last year. I mention= ed this because the email yesterday was sent to Facebook and the OAuth maili= ng list at the same time. I was trying to let the Facebook team know we had p= revious communication before. I should have removed this part in the version= sent to OAuth. Again, sorry for not removing this reference. Please ignore i= t. >> =20 >> Thanks, >> Rui >> On Fri, Jun 15, 2012 at 1:34 PM, Francisco Corella w= rote: >> Hi Nat and Rui, >>=20 >> Rui, you say that the vulnerability that you found was due to a >> "common misunderstanding among developers", but the attack you >> describe can be carried out against any app that uses the OAuth >> "implicit grant flow", which Facebook calls "client-side >> authentication". No misunderstanding seems necessary. What >> misunderstanding are you referring to? I followed the link in your >> message to the Sophos post, and from there the link to the article in >> The Register. The article in The Register says that Facebook had >> "fixed the vulnerability promptly". How did they fix it? The >> instructions that Facebook provides for implementing "Client-side >> authentication without the JS SDK" at >> https://developers.facebook.com/docs/authentication/client-side/#no-jssdk= >> still allows the attack. >>=20 >> Nat, I agree that the blog post by John Bradley that you link to >> refers to the same vulnerability reported by Rui. You say that some >> apps have issued a patch to fix it. Could you explain what the fix >> was? >>=20 >> Francisco >>=20 >> From: Nat Sakimura >> To: rui wang =20 >> Cc: matake nov ; Yuchen Zhou ; oau= th ; Shuo Chen (MSR) =20 >> Sent: Thursday, June 14, 2012 1:50 PM >>=20 >> Subject: Re: [OAUTH-WG] Report an authentication issue >>=20 >> This is a fairly well known (hopefully by now) issue. We, at the OpenID Fo= undation, call it "access_token phishing" attack these days. See: http://www= .thread-safe.com/2012/01/problem-with-oauth-for-authentication.html >>=20 >> Nov Matake has actually built the code on iPhone to verify the problem, a= nd has notified bunch of parties back in February including Facebook and App= le. We have the code that actually runs on a phone, and we have successfully= logged in to bunch of apps, including very well known ones. They were all i= nformed of the issue. Some immediately issued a patch to fix it while others= have not. =20 >>=20 >> The problem is that even if these apps gets fixed, the problem does not g= o away. As long as the attacker has the vulnerable version of the app, he st= ill can impersonate the victim. To stop it, the server side has to completel= y disable the older version, which means the service has to cut off many use= rs pausing business problems.=20 >>=20 >> Nat >>=20 >> On Fri, Jun 15, 2012 at 2:18 AM, rui wang wrote: >> Dear Facebook Security Team and OAuth Standard group, >> We are a research team in Microsoft Research. In January, 2011, we report= ed a vulnerability in Facebook Connect which allowed everyone to sign into Fa= cebook-secured relying parties without password. It was promptly fixed after= reporting. (http://nakedsecurity.sophos.com/2011/02/02/facebook-flaw-websit= es-steal-personal-data/) >> Recently, we found a common misunderstanding among developers of mobile/m= etro apps when using OAuth (including Facebook=E2=80=99s OAuth) for authenti= cation. The vulnerability resulted from this misunderstanding also allows an= attacker to log into a victim user's account without password. >> Let's take Soluto's metro app as an example to describe the problem. The a= pp supports Facebook Login. As an attacker, we can write a regular Facebook a= pp. Once the victim user allows our app to access her Facebook data, we rece= ive an access_token from the traffic. Then, on our own machine (i.e., the "a= ttacker" machine), we run the metro app of Soluto, and use a HTTP proxy to i= nsert the victim's access_token into the traffic of Facebook login. Through t= his way, we are able to log into the victim's Soluto account from our machin= e. Other than Soluto, we also have confirmed the same issue on another Windo= ws 8 metro-app Givit. >> The Facebook SDK for Android apps (https://developers.facebook.com/docs/m= obile/android/build/#sdk) seems to have the possibility to mislead developer= s too. At least, the issue that we found is not clearly mentioned. In the SD= K, we ran the sample code called "Hackbook" using Android Emulator (imagine i= t is an attacker device). Note that we have already received the access toke= n of the victim user from our regular Facebook app. We then inject the token= to the traffic of Hackbook. Through this way, Hackbook app on our own machi= ne recognizes us as the victim. Note that this is not a convincing security e= xploit yet, because this sample code does not include the server-side code. H= owever, given that we have seen real server-side code having this problem, s= uch as Soluto, Givit and others, we do believe that the sample code can misl= ead mobile/metro developers. We also suspect that this may be a general issu= e of many OAuth implementations on mobile platforms, so we send this message= to OAuth Standard group as well. >> We have contacted the vendors of the two vulnerable metro-apps, Soluto an= d Gavit. >> Please kindly give us an ack when you receive this message. If you want t= o know more details, please let us know. >> Best Regards, >> Yuchen Zhou, Rui Wang, and Shuo Chen >>=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 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 > _______________________________________________ > 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 >=20 --Apple-Mail-3288AEA0-C8CF-4DAB-9B6D-25373CAF7596 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Ok. Are you recommending s= pecific changes that should be made to the group?

Phil

= On 2012-06-15, at 17:30, Nat Sakimura <sakimura@gmail.com> wrote:

No. You do not need the sniffing in an unsecured connection= . 

But I am not sure if I should disclose the detail= of the attack here in the public list as that will open up a much more seri= ous attack vector than leaked passwords hash in recent incidents. 

OAuth is not an authentication protocol. It is an access= delegation protocol. 
The fact that one has an authorization= to access an API does not mean that he is the subject. 
Ther= e are bunch of assumptions that have to be fulfilled for OAuth to act as an e= ntity authentication. 
If you pass a token from a client to another, e.g., from an APP to the s= erver side component, the assumption is violated. 
And, this i= s not only the condition, but there are others as well. 

=
That's why we have been creating OpenID Connect. OpenID Connect adds bu= nch of restrictions on OAuth 2.0. They are the things you have to do before y= ou can use OAuth 2.0 as an authentication protocol.

Best, 

Nat

On Sat, Jun 16, 2012 at 7:58 AM, Phil Hunt <phil.hunt@or= acle.com> wrote:
I am a bit= confused.

It sounds like you are sniffing a bearer token= from an unsecured connection to a resource server and then letting another c= lient use that token.

Is this correct?


On 2012-06-15, at 3:06 PM, rui wang wrote:

Hi, Francisco
 
Thank you for your reply. Here is our response for your questions.
<= br>=C3=98  the attack you describe can be carried out against any app t= hat uses the OAuth "implicit grant flow", which Facebook calls "client-side a= uthentication".
 
The main concern we raised here is not about at= tacking client-side apps. We don=E2=80=99t think it is a meaningful security= consequence when a client-side application (e.g., a Win8 Metro app, iPhone/= iPad app) on the attacker=E2=80=99s tablet misidentifies the user as the vic= tim user. Therefore, you are right about =E2=80=9Cthis kind of attack can be= carried out against any app  using the OAuth =E2=80=98implicit grant f= low=E2=80=99=E2=80=9D. In fact we won=E2=80=99t even call this consequence a= s an attack.
The real problem is that in multiple occasions,= we found that the server-side authentication logic takes an access token fr= om the client app, then queries the user's profile data from the IdP in orde= r to "authenticate" the user into the server. We have confirmed that the ser= vers for Soluto Metro App, Givit Metro App and EuroCup2012 Metro App make th= is mistake. These are apps in the official Windows 8 App Store. We only samp= led a small portion of the available apps, but believe this is a vulnerabili= ty pattern due to a common misunderstanding of the usage of the access token= .
 
=C3=98  I followed the link in your message to the Sophos post, an= d from there the link to the article in
The Register.  The article i= n The Register says that Facebook had
"fixed the vulnerability promptly".=   How did they fix it?  The
instructions that Facebook provides for implementing "Client-side
authent= ication without the JS SDK" at
https://develo= pers.facebook.com/docs/authentication/client-side/#no-jssdk
still allows the attack.
 
I am very sorry for the confusion. The link to S= ophos has nothing to do with this problem. It is about another issue we repo= rted last year. I mentioned this because the email yesterday was sent to Fac= ebook and the OAuth mailing list at the same time. I was trying to let the Fa= cebook team know we had previous communication before. I should have removed= this part in the version sent to OAuth. Again, sorry for not removing this r= eference. Please ignore it.
 
Thanks,
Rui
On Fri, Jun 15, 2012 at 1:34 PM, Francisco Corell= a <fcorella@pomcor.com> wrote:
Hi Nat and Rui,

Rui, you say that the vulnerability that you found= was due to a
"common misunderstanding among developers", but the attack y= ou
describe can be carried out against any app that uses the OAuth
"implicit= grant flow", which Facebook calls "client-side
authentication".  No= misunderstanding seems necessary.  What
misunderstanding are you re= ferring to?  I followed the link in your
message to the Sophos post, and from there the link to the article in
The= Register.  The article in The Register says that Facebook had
"fixe= d the vulnerability promptly".  How did they fix it?  The
instr= uctions that Facebook provides for implementing "Client-side
authentication without the JS SDK" at
https:/= /developers.facebook.com/docs/authentication/client-side/#no-jssdk
still allows the attack.

Nat, I agree that the blog post by John Brad= ley that you link to
refers to the same vulnerability reported by Rui.&nb= sp; You say that some
apps have issued a patch to fix it.  Could you= explain what the fix
was?

Francisco

From: Nat Sakimura <sakimura@gmail.com>=
To: rui wang <ruiwangwarm@gmail.com&g= t;
Cc: matake nov <nov@matake.jp>; Yuchen Zhou &= lt;t-yuzhou@micr= osoft.com>; oauth <oauth@ietf.org>; Shuo Chen (MSR) <shuochen@microsoft.com>
Sent: Thursday, June 14, 2012= 1:50 PM=20

Subject: Re: [OAUTH-= WG] Report an authentication issue

This is a fairly well known (hopefully by now) issue. We, at the OpenID= Foundation, call it "access_token phishing" attack these days. See: http://www.thread-safe.com/2012/01/problem-wit= h-oauth-for-authentication.html=20

Nov Matake has actually built the code on iPhone to verify the problem,= and has notified bunch of parties back in February including Facebook and A= pple. We have the code that actually runs on a phone, and we have successful= ly logged in to bunch of apps, including very well known ones. They were all= informed of the issue. Some immediately issued a patch to fix it while othe= rs have not.  

The problem is that even if these apps gets fixed, the problem does not= go away. As long as the attacker has the vulnerable version of the app, he s= till can impersonate the victim. To stop it, the server side has to complete= ly disable the older version, which means the service has to cut off many us= ers pausing business problems. 

Nat

On Fri, Jun 15, 2012 at 2:18 AM, rui wang <ruiwang= warm@gmail.com> wrote:
Dear Facebook Security Team and OAuth Standard group,
We are a research team in Microsoft Research. In January, 2011, we repo= rted a vulnerability in Facebook Connect which allowed everyone to sign into= Facebook-secured relying parties without password. It was promptly fixed af= ter reporting. (http://nakedsecurit= y.sophos.com/2011/02/02/facebook-flaw-websites-steal-personal-data/)
Recently, we found a common misunderstanding among developers of mobile= /metro apps when using OAuth (including Facebook=E2=80=99s OAuth) for authen= tication. The vulnerability resulted from this misunderstanding also allows a= n attacker to log into a victim user's account without password.
Let's take Soluto's metro app as an example to describe the problem. Th= e app supports Facebook Login. As an attacker, we can write a regular Facebo= ok app. Once the victim user allows our app to access her Facebook data, we r= eceive an access_token from the traffic. Then, on our own machine (i.e., the= "attacker" machine), we run the metro app of Soluto, and use a HTTP proxy t= o insert the victim's access_token into the traffic of Facebook login. Throu= gh this way, we are able to log into the victim's Soluto account from our ma= chine. Other than Soluto, we also have confirmed the same issue on another W= indows 8 metro-app Givit.
The Facebook SDK for Android apps (ht= tps://developers.facebook.com/docs/mobile/android/build/#sdk) seems to h= ave the possibility to mislead developers too. At least, the issue that we f= ound is not clearly mentioned. In the SDK, we ran the sample code called "Ha= ckbook" using Android Emulator (imagine it is an attacker device). Note that= we have already received the access token of the victim user from our regul= ar Facebook app. We then inject the token to the traffic of Hackbook. Throug= h this way, Hackbook app on our own machine recognizes us as the victim. Not= e that this is not a convincing security exploit yet, because this sample co= de does not include the server-side code. However, given that we have seen r= eal server-side code having this problem, such as Soluto, Givit and others, w= e do believe that the sample code can mislead mobile/metro developers. We al= so suspect that this may be a general issue of many OAuth implementations on= mobile platforms, so we send this message to OAuth Standard group as well.<= /div>
We have contacted the vendors of the two vulnerable metro-apps, Soluto a= nd Gavit.
Please kindly give us an ack when you receive this message. If you want= to know more details, please let us know.
Best Regards,
Yuchen Zhou, Rui Wang, and Shuo Chen

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




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


_______________________________________________
OAuth mailing list OAuth@ietf.org
http= s://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
ht= tps://www.ietf.org/mailman/listinfo/oauth




--
Nat Sakim= ura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
= --Apple-Mail-3288AEA0-C8CF-4DAB-9B6D-25373CAF7596-- From sakimura@gmail.com Fri Jun 15 18:19:28 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5D4F21F8505 for ; Fri, 15 Jun 2012 18:19:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.338 X-Spam-Level: X-Spam-Status: No, score=-3.338 tagged_above=-999 required=5 tests=[AWL=0.260, 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 NjhUFE3O+RO6 for ; Fri, 15 Jun 2012 18:19:27 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5949921F8504 for ; Fri, 15 Jun 2012 18:19:26 -0700 (PDT) Received: by bkty8 with SMTP id y8so3157203bkt.31 for ; Fri, 15 Jun 2012 18:19:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Zll5VpuCaHnCvQZjg2WkTNP89nPkGDeOzMgcDL4Ngec=; b=l/cGoGIqGBEFNfqC2fP3WEVUAiH21k7ZmyPWKkAlfry3RUxOUhEAmkb8Stgoqbl3O8 oDmhjEBK8Sw/WBPGVTf9TOhELd2RtlesZPbuMKAGOU4/WcmHebDcxilItTVVW3BUBVZM 0oF5bi5Wiup+b+WmJuG8FUrs0hM9hBzgMTIbP6Vnu57Czfvw5QzHs+C87yH/iVUqEJfC Hdf3/mptfKymd9nfJlZAk5vY3eCASGMmm/UQforwyxhLyMf9k1eS8zCty14el91Lkvp1 buEzAdqjQ/2QbRBjyaBO9e4lJb0z++Id5aXoxx8dlt+G47dImotqe79zEOi0ZRNlEu9S 3RwQ== MIME-Version: 1.0 Received: by 10.204.145.78 with SMTP id c14mr3540776bkv.43.1339809565299; Fri, 15 Jun 2012 18:19:25 -0700 (PDT) Received: by 10.204.240.143 with HTTP; Fri, 15 Jun 2012 18:19:25 -0700 (PDT) In-Reply-To: <579AA814-426B-434B-8493-5262C7ED63FF@oracle.com> References: <1339792496.52712.YahooMailNeo@web125501.mail.ne1.yahoo.com> <579AA814-426B-434B-8493-5262C7ED63FF@oracle.com> Date: Sat, 16 Jun 2012 10:19:25 +0900 Message-ID: From: Nat Sakimura To: Phil Hunt Content-Type: multipart/alternative; boundary=00151759338c34d40e04c28cb9ad Cc: matake nov , Yuchen Zhou , oauth , "Shuo Chen \(MSR\)" Subject: Re: [OAUTH-WG] Report an authentication issue X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 01:19:28 -0000 --00151759338c34d40e04c28cb9ad Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hmm let me see. I was not proposing any change because OAuth as a protocol is just fine. It is the mis-use of OAuth (i.e, using OAuth for authentication) that is causing the problem. In OAuth, an entity, say Alice, has given the authorization to access the resource to people/services, say Eve. Eve being able to access to the resource is not a problem at all. Bob, looking at Eve being able to access the Alice's resource, mistaking Eve as Alice is outright stupid, but that is what is happening in the attack described. However, after reading your message, I started to think that perhaps warning the implementors of the above in the security consideration may be useful. A new section 10.16? Is it not too late? =3Dnat On Sat, Jun 16, 2012 at 9:55 AM, Phil Hunt wrote: > Ok. Are you recommending specific changes that should be made to the grou= p? > > Phil > > On 2012-06-15, at 17:30, Nat Sakimura wrote: > > No. You do not need the sniffing in an unsecured connection. > > But I am not sure if I should disclose the detail of the attack here in > the public list as that will open up a much more serious attack vector th= an > leaked passwords hash in recent incidents. > > OAuth is not an authentication protocol. It is an access delegation > protocol. > The fact that one has an authorization to access an API does not mean tha= t > he is the subject. > There are bunch of assumptions that have to be fulfilled for OAuth to act > as an entity authentication. > If you pass a token from a client to another, e.g., from an APP to the > server side component, the assumption is violated. > And, this is not only the condition, but there are others as well. > > That's why we have been creating OpenID Connect. OpenID Connect adds bunc= h > of restrictions on OAuth 2.0. They are the things you have to do before y= ou > can use OAuth 2.0 as an authentication protocol. > > Best, > > Nat > > On Sat, Jun 16, 2012 at 7:58 AM, Phil Hunt wrote: > >> I am a bit confused. >> >> It sounds like you are sniffing a bearer token from an unsecured >> connection to a resource server and then letting another client use that >> token. >> >> Is this correct? >> >> Phil >> >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >> >> >> >> >> >> On 2012-06-15, at 3:06 PM, rui wang wrote: >> >> Hi, Francisco >> >> Thank you for your reply. Here is our response for your questions. >> >> =D8 the attack you describe can be carried out against any app that use= s >> the OAuth "implicit grant flow", which Facebook calls "client-side >> authentication". >> >> The main concern we raised here is not about attacking client-side apps. >> We don=92t think it is a meaningful security consequence when a client-s= ide >> application (e.g., a Win8 Metro app, iPhone/iPad app) on the attacker=92= s >> tablet misidentifies the user as the victim user. Therefore, you are rig= ht >> about =93this kind of attack can be carried out against any app using t= he >> OAuth =91implicit grant flow=92=94. In fact we won=92t even call this co= nsequence >> as an attack. >> The real problem is that in multiple occasions, we found that the >> server-side authentication logic takes an access token from the client a= pp, >> then queries the user's profile data from the IdP in order to >> "authenticate" the user into the server. We have confirmed that the serv= ers >> for Soluto Metro App, Givit Metro App and EuroCup2012 Metro App make thi= s >> mistake. These are apps in the official Windows 8 App Store. We only >> sampled a small portion of the available apps, but believe this is a >> vulnerability pattern due to a common misunderstanding of the usage of t= he >> access token. >> >> =D8 I followed the link in your message to the Sophos post, and from th= ere >> the link to the article in >> The Register. The article in The Register says that Facebook had >> "fixed the vulnerability promptly". How did they fix it? The >> instructions that Facebook provides for implementing "Client-side >> authentication without the JS SDK" at >> https://developers.facebook.com/docs/authentication/client-side/#no-jssd= k >> still allows the attack. >> >> I am very sorry for the confusion. The link to Sophos has nothing to do >> with this problem. It is about another issue we reported last year. I >> mentioned this because the email yesterday was sent to Facebook and the >> OAuth mailing list at the same time. I was trying to let the Facebook te= am >> know we had previous communication before. I should have removed this pa= rt >> in the version sent to OAuth. Again, sorry for not removing this referen= ce. >> Please ignore it. >> >> Thanks, >> Rui >> On Fri, Jun 15, 2012 at 1:34 PM, Francisco Corella = wrote: >> >>> Hi Nat and Rui, >>> >>> Rui, you say that the vulnerability that you found was due to a >>> "common misunderstanding among developers", but the attack you >>> describe can be carried out against any app that uses the OAuth >>> "implicit grant flow", which Facebook calls "client-side >>> authentication". No misunderstanding seems necessary. What >>> misunderstanding are you referring to? I followed the link in your >>> message to the Sophos post, and from there the link to the article in >>> The Register. The article in The Register says that Facebook had >>> "fixed the vulnerability promptly". How did they fix it? The >>> instructions that Facebook provides for implementing "Client-side >>> authentication without the JS SDK" at >>> https://developers.facebook.com/docs/authentication/client-side/#no-jss= dk >>> still allows the attack. >>> >>> Nat, I agree that the blog post by John Bradley that you link to >>> refers to the same vulnerability reported by Rui. You say that some >>> apps have issued a patch to fix it. Could you explain what the fix >>> was? >>> >>> Francisco >>> >>> ------------------------------ >>> *From:* Nat Sakimura >>> *To:* rui wang >>> *Cc:* matake nov ; Yuchen Zhou ; >>> oauth ; Shuo Chen (MSR) >>> *Sent:* Thursday, June 14, 2012 1:50 PM >>> >>> *Subject:* Re: [OAUTH-WG] Report an authentication issue >>> >>> This is a fairly well known (hopefully by now) issue. We, at the >>> OpenID Foundation, call it "access_token phishing" attack these days. S= ee: >>> http://www.thread-safe.com/2012/01/problem-with-oauth-for-authenticatio= n.html >>> >>> Nov Matake has actually built the code on iPhone to verify the problem, >>> and has notified bunch of parties back in February including Facebook a= nd >>> Apple. We have the code that actually runs on a phone, and we have >>> successfully logged in to bunch of apps, including very well known ones= . >>> They were all informed of the issue. Some immediately issued a patch to= fix >>> it while others have not. >>> >>> The problem is that even if these apps gets fixed, the problem does not >>> go away. As long as the attacker has the vulnerable version of the app,= he >>> still can impersonate the victim. To stop it, the server side has to >>> completely disable the older version, which means the service has to cu= t >>> off many users pausing business problems. >>> >>> Nat >>> >>> On Fri, Jun 15, 2012 at 2:18 AM, rui wang wrote= : >>> >>> Dear Facebook Security Team and OAuth Standard group, >>> We are a research team in Microsoft Research. In January, 2011, we >>> reported a vulnerability in Facebook Connect which allowed everyone to = sign >>> into Facebook-secured relying parties without password. It was promptly >>> fixed after reporting. ( >>> http://nakedsecurity.sophos.com/2011/02/02/facebook-flaw-websites-steal= -personal-data/ >>> ) >>> Recently, we found a common misunderstanding among developers of >>> mobile/metro apps when using OAuth (including Facebook=92s OAuth) for >>> authentication. The vulnerability resulted from this misunderstanding a= lso >>> allows an attacker to log into a victim user's account without password= . >>> Let's take Soluto's metro app as an example to describe the problem. Th= e >>> app supports Facebook Login. As an attacker, we can write a regular >>> Facebook app. Once the victim user allows our app to access her Faceboo= k >>> data, we receive an access_token from the traffic. Then, on our own mac= hine >>> (i.e., the "attacker" machine), we run the metro app of Soluto, and use= a >>> HTTP proxy to insert the victim's access_token into the traffic of Face= book >>> login. Through this way, we are able to log into the victim's Soluto >>> account from our machine. Other than Soluto, we also have confirmed the >>> same issue on another Windows 8 metro-app Givit. >>> The Facebook SDK for Android apps ( >>> https://developers.facebook.com/docs/mobile/android/build/#sdk) seems >>> to have the possibility to mislead developers too. At least, the issue = that >>> we found is not clearly mentioned. In the SDK, we ran the sample code >>> called "Hackbook" using Android Emulator (imagine it is an attacker >>> device). Note that we have already received the access token of the vic= tim >>> user from our regular Facebook app. We then inject the token to the tra= ffic >>> of Hackbook. Through this way, Hackbook app on our own machine recogniz= es >>> us as the victim. Note that this is not a convincing security exploit y= et, >>> because this sample code does not include the server-side code. However= , >>> given that we have seen real server-side code having this problem, such= as >>> Soluto, Givit and others, we do believe that the sample code can mislea= d >>> mobile/metro developers. We also suspect that this may be a general iss= ue >>> of many OAuth implementations on mobile platforms, so we send this mess= age >>> to OAuth Standard group as well. >>> We have contacted the vendors of the two vulnerable metro-apps, Soluto >>> and Gavit. >>> Please kindly give us an ack when you receive this message. If you want >>> to know more details, please let us know. >>> Best Regards, >>> Yuchen Zhou, Rui Wang, and Shuo Chen >>> >>> _______________________________________________ >>> 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 >> >> >> >> _______________________________________________ >> 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 > > --=20 Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --00151759338c34d40e04c28cb9ad Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hmm let me see. I was not proposing any change because OAuth as a protocol = is just fine. It is the mis-use of OAuth (i.e, using OAuth for authenticati= on) that is causing the problem.=A0

In OAuth, an entity,= say Alice, has given the authorization to access the resource to people/se= rvices, say Eve.=A0
Eve being able to access to the resource is not a problem at all.=A0
Bob, looking at Eve being able to access the Alice's resource,= mistaking Eve as Alice is outright stupid, but that is what is happening i= n the attack described.=A0

However, after reading your message, I started to think= that perhaps warning the implementors of the above in the security conside= ration may be useful. A new section 10.16? Is it not too late?=A0

=3Dnat


On Sat, Ju= n 16, 2012 at 9:55 AM, Phil Hunt <phil.hunt@oracle.com> w= rote:
Ok. Are you re= commending specific changes that should be made to the group?

Phil

On 2012-06-15, = at 17:30, Nat Sakimura <sakimura@gmail.com> wrote:

No. You do not need the sniffing in an unsecured connection.=A0
But I am not sure if I should disclose the detail of the attac= k here in the public list as that will open up a much more serious attack v= ector than leaked passwords hash in recent incidents.=A0

OAuth is not an authentication protocol. It is an acces= s delegation protocol.=A0
The fact that one has an authorization = to access an API does not mean that he is the subject.=A0
There a= re bunch of assumptions that have to be fulfilled for OAuth to act as an en= tity authentication.=A0
If you pass a token from a client to another, e.g., from an APP to the= server side component, the assumption is violated.=A0
And, this = is not only the condition, but there are others as well.=A0

That's why we have been creating OpenID Connect. OpenID Connect ad= ds bunch of restrictions on OAuth 2.0. They are the things you have to do b= efore you can use OAuth 2.0 as an authentication protocol.

Best,=A0

Nat

On Sat, Jun 16, 2012 at 7:58 AM, Phil Hunt <phil.hunt@= oracle.com> wrote:
I am a b= it confused.

It sounds like you are sniffing a bearer to= ken from an unsecured connection to a resource server and then letting anot= her client use that token.

Is this correct?


On 2012-06-15, at 3:06 PM, rui wang wrote:

Hi, Francisco
=A0
Thank you for your reply. Here is our response for your questions.
=
=D8=A0 the attack you describe can be carried out against any app that = uses the OAuth "implicit grant flow", which Facebook calls "= client-side authentication".
=A0
The main concern we raised here is not about a= ttacking client-side apps. We don=92t think it is a meaningful security con= sequence when a client-side application (e.g., a Win8 Metro app, iPhone/iPa= d app) on the attacker=92s tablet misidentifies the user as the victim user= . Therefore, you are right about =93this kind of attack can be carried out = against any app=A0 using the OAuth =91implicit grant flow=92=94. In fact we= won=92t even call this consequence as an attack.
The real problem is that in multiple occasions= , we found that the server-side authentication logic takes an access token = from the client app, then queries the user's profile data from the IdP = in order to "authenticate" the user into the server. We have conf= irmed that the servers for Soluto Metro App, Givit Metro App and EuroCup201= 2 Metro App make this mistake. These are apps in the official Windows 8 App= Store. We only sampled a small portion of the available apps, but believe = this is a vulnerability pattern due to a common misunderstanding of the usa= ge of the access token.
=A0
=D8=A0 I followed the link in your message to the Sophos post, and fro= m there the link to the article in
The Register.=A0 The article in The R= egister says that Facebook had
"fixed the vulnerability promptly&qu= ot;.=A0 How did they fix it?=A0 The
instructions that Facebook provides for implementing "Client-side
a= uthentication without the JS SDK" at
h= ttps://developers.facebook.com/docs/authentication/client-side/#no-jssdk
still allows the attack.
=A0
I am very sorry for the confusion. The link to= Sophos has nothing to do with this problem. It is about another issue we r= eported last year. I mentioned this because the email yesterday was sent to= Facebook and the OAuth mailing list at the same time. I was trying to let = the Facebook team know we had previous communication before. I should have = removed this part in the version sent to OAuth. Again, sorry for not removi= ng this reference. Please ignore it.
=A0
Thanks,
Rui
On Fri, Jun 15, 2012 at 1:34 PM, Francisco Corel= la <fcorella@pomcor.com> wrote:
Hi Nat and Rui,

Rui, you say that the vulnerability that you fou= nd was due to a
"common misunderstanding among developers", bu= t the attack you
describe can be carried out against any app that uses the OAuth
"im= plicit grant flow", which Facebook calls "client-side
authenti= cation".=A0 No misunderstanding seems necessary.=A0 What
misunderst= anding are you referring to?=A0 I followed the link in your
message to the Sophos post, and from there the link to the article in
Th= e Register.=A0 The article in The Register says that Facebook had
"= fixed the vulnerability promptly".=A0 How did they fix it?=A0 The
i= nstructions that Facebook provides for implementing "Client-side
authentication without the JS SDK" at
= https://developers.facebook.com/docs/authentication/client-side/#no-jssdk
still allows the attack.

Nat, I agree that the blog post by John Bra= dley that you link to
refers to the same vulnerability reported by Rui.= =A0 You say that some
apps have issued a patch to fix it.=A0 Could you e= xplain what the fix
was?

Francisco

From: Nat Sakimura <sakimura@gmail.com&g= t;
To: rui wang <ruiwangwarm@gmail.com= >
Cc: matake nov <nov@matake.jp>; Yuchen Z= hou <t-yuzho= u@microsoft.com>; oauth <oauth@ietf.org>; Shuo Chen (MSR) <shuochen@microsoft.com> Sent: Thursday, June 14, 201= 2 1:50 PM=20

Subject: Re: [OAUTH= -WG] Report an authentication issue

This is a fairly well known (hopefully by now) issue. We, at the OpenI= D Foundation, call it "access_token phishing" attack these days. = See:=A0http://www.thread-safe.com/2012/01/= problem-with-oauth-for-authentication.html=20

Nov Matake has actually built the code on iPhone to verify the problem= , and has notified bunch of parties back in February including Facebook and= Apple. We have the code that actually runs on a phone, and we have success= fully logged in to bunch of apps, including very well known ones. They were= all informed of the issue. Some immediately issued a patch to fix it while= others have not. =A0

The problem is that even if these apps gets fixed, the problem does no= t go away. As long as the attacker has the vulnerable version of the app, h= e still can impersonate the victim. To stop it, the server side has to comp= letely disable the older version, which means the service has to cut off ma= ny users pausing business problems.=A0

Nat

On Fri, Jun 15, 2012 at 2:18 AM, rui wang <ruiwa= ngwarm@gmail.com> wrote:
Dear Facebook Security Team and OAuth Standard group,
We are a research team in Microsoft Research. In January, 2011, we rep= orted a vulnerability in Facebook Connect which allowed everyone to sign in= to Facebook-secured relying parties without password. It was promptly fixed= after reporting. (http://nakedse= curity.sophos.com/2011/02/02/facebook-flaw-websites-steal-personal-data/)
Recently, we found a common misunderstanding among developers of mobil= e/metro apps when using OAuth (including Facebook=92s OAuth) for authentica= tion. The vulnerability resulted from this misunderstanding also allows an = attacker to log into a victim user's account without password.
Let's take Soluto's metro app as an example to describe the pr= oblem. The app supports Facebook Login. As an attacker, we can write a regu= lar Facebook app. Once the victim user allows our app to access her Faceboo= k data, we receive an access_token from the traffic. Then, on our own machi= ne (i.e., the "attacker" machine), we run the metro app of Soluto= , and use a HTTP proxy to insert the victim's access_token into the tra= ffic of Facebook login. Through this way, we are able to log into the victi= m's Soluto account from our machine. Other than Soluto, we also have co= nfirmed the same issue on another Windows 8 metro-app Givit.
The Facebook SDK for Android apps (= https://developers.facebook.com/docs/mobile/android/build/#sdk) seems t= o have the possibility to mislead developers too. At least, the issue that = we found is not clearly mentioned. In the SDK, we ran the sample code calle= d "Hackbook" using Android Emulator (imagine it is an attacker de= vice). Note that we have already received the access token of the victim us= er from our regular Facebook app. We then inject the token to the traffic o= f Hackbook. Through this way, Hackbook app on our own machine recognizes us= as the victim. Note that this is not a convincing security exploit yet, be= cause this sample code does not include the server-side code. However, give= n that we have seen real server-side code having this problem, such as Solu= to, Givit and others, we do believe that the sample code can mislead mobile= /metro developers. We also suspect that this may be a general issue of many= OAuth implementations on mobile platforms, so we send this message to OAut= h Standard group as well.
We have contacted the vendors of the two vulnerable metro-apps, Soluto= and Gavit.
Please kindly give us an ack when you receive this message. If you wan= t to know more details, please let us know.
Best Regards,
Yuchen Zhou, Rui Wang, and Shuo Chen

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




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


_______________________________________________
OAuth mailing lis= t
OAuth@ietf.org
<= a href=3D"https://www.ietf.org/mailman/listinfo/oauth" target=3D"_blank">ht= tps://www.ietf.org/mailman/listinfo/oauth


=

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


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




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



--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundat= ion
http://nat.sa= kimura.org/
@_nat_en

--00151759338c34d40e04c28cb9ad-- From nov@matake.jp Fri Jun 15 20:22:27 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50CB511E8116 for ; Fri, 15 Jun 2012 20:22:27 -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 1cBk07pk51e4 for ; Fri, 15 Jun 2012 20:22:25 -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 B8C2F11E8114 for ; Fri, 15 Jun 2012 20:22:25 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so6049453pbc.31 for ; Fri, 15 Jun 2012 20:22:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=evDPvvKNQELXLHgVBScO9Yg0VKfdU0QfGdGa608weo8=; b=dFTGEoltDUyycTFZcSw0dGRWZwLPkP+I7SYEaY6TRjDLI7dPsIKY3g7hTS6kLT/dcC ZvaJu9gUs33FrXqrW799OqMBWH05+H/KhvKHGIaKt6KLbSMkySts0AIJYWFiUbYdiX1t pn2th7YU2xWWVCQ1+NPhMHD910cS6m4phDt4vMLvDvS8vGC7P2OdOApmFOC9wWwODMkU Z9q1VPfF1u8X0M3fkvK86y8dyEvHCjm/3jfm+RBcjkUVRZ2n6sU+I1HEgbZNS6Phvi63 vUqD+wXvA8wj1q3bZ94wdE+WcHLU0qnNSm0gAhPGDm/qFKBmIp8DVLwGeLyUTCHfE/m4 Ef6A== Received: by 10.68.222.197 with SMTP id qo5mr15971204pbc.72.1339816944453; Fri, 15 Jun 2012 20:22:24 -0700 (PDT) Received: from [192.168.1.4] (y241176.dynamic.ppp.asahi-net.or.jp. [118.243.241.176]) by mx.google.com with ESMTPS id ku7sm15351198pbc.31.2012.06.15.20.22.22 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 15 Jun 2012 20:22:23 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_2DD1D5E5-5E44-4BDC-B879-19556A590246" From: nov matake In-Reply-To: Date: Sat, 16 Jun 2012 12:22:23 +0900 Message-Id: References: <1339792496.52712.YahooMailNeo@web125501.mail.ne1.yahoo.com> To: Nat Sakimura X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQkZTbMQmwjQ6YOwzrtso5FsZONn45Uk7j536NqFd8XKrKoocg2G1m2X+MYIfPjCyCAnQmuj Cc: "Shuo Chen \(MSR\)" , Yuchen Zhou , oauth Subject: Re: [OAUTH-WG] Report an authentication issue X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 03:22:27 -0000 --Apple-Mail=_2DD1D5E5-5E44-4BDC-B879-19556A590246 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 There are 4 ways to fix this issue. 1. Use response_type=3Dtoken%20code (It's not in OAuth 2.0 Core, but = seems best way for interoperability) 2. Use singed_request (or some signed token like JWT) 3. Use grant_type=3Dfb_exchange_token (Facebook custom way) 4. Access to https://graph.facebook.com/app?access_token=3DYOUR_TOKEN = (Facebook custom way, moreover undocumented API) Two iPhone app developers I reported this issue fixed it by using (4). I also tried to use (1) for my own iPhone app implementation, but = unfortunately it doesn't work when using authorization codes obtained = via FB iOS SDK. So I'm using (3) in my case. nov On 2012/06/16, at 9:16, Nat Sakimura wrote: > As to how the fix was done, Nov can provide more detail, but ...=20 >=20 > 1. Properly verify the signature/HMAC of the "signed_request". This = will essentially audience restricts the token.=20 > 2. There is an undocumented API for Facebook which returns to whom the = token was issued. This also audience restricts the token.=20 >=20 > The service that fixed took these measures. Note that none of the = above is defined in OAuth.=20 > The same facility was called "id_token" and "check ID endpoint" for = OpenID Connect.=20 >=20 > The scale of the impact is large, too large to disclose the actual = names in the public list, though, eventually, we would publish them in a = paper.=20 >=20 > Nat >=20 > On Sat, Jun 16, 2012 at 5:34 AM, Francisco Corella = wrote: > Hi Nat and Rui, >=20 > Rui, you say that the vulnerability that you found was due to a > "common misunderstanding among developers", but the attack you > describe can be carried out against any app that uses the OAuth > "implicit grant flow", which Facebook calls "client-side > authentication". No misunderstanding seems necessary. What > misunderstanding are you referring to? I followed the link in your > message to the Sophos post, and from there the link to the article in > The Register. The article in The Register says that Facebook had > "fixed the vulnerability promptly". How did they fix it? The > instructions that Facebook provides for implementing "Client-side > authentication without the JS SDK" at > = https://developers.facebook.com/docs/authentication/client-side/#no-jssdk > still allows the attack. >=20 > Nat, I agree that the blog post by John Bradley that you link to > refers to the same vulnerability reported by Rui. You say that some > apps have issued a patch to fix it. Could you explain what the fix > was? >=20 > Francisco >=20 > From: Nat Sakimura > To: rui wang =20 > Cc: matake nov ; Yuchen Zhou ; = oauth ; Shuo Chen (MSR) =20 > Sent: Thursday, June 14, 2012 1:50 PM > Subject: Re: [OAUTH-WG] Report an authentication issue >=20 > This is a fairly well known (hopefully by now) issue. We, at the = OpenID Foundation, call it "access_token phishing" attack these days. = See: = http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.h= tml >=20 > Nov Matake has actually built the code on iPhone to verify the = problem, and has notified bunch of parties back in February including = Facebook and Apple. We have the code that actually runs on a phone, and = we have successfully logged in to bunch of apps, including very well = known ones. They were all informed of the issue. Some immediately issued = a patch to fix it while others have not. =20 >=20 > The problem is that even if these apps gets fixed, the problem does = not go away. As long as the attacker has the vulnerable version of the = app, he still can impersonate the victim. To stop it, the server side = has to completely disable the older version, which means the service has = to cut off many users pausing business problems.=20 >=20 > Nat >=20 > On Fri, Jun 15, 2012 at 2:18 AM, rui wang = wrote: > Dear Facebook Security Team and OAuth Standard group, > We are a research team in Microsoft Research. In January, 2011, we = reported a vulnerability in Facebook Connect which allowed everyone to = sign into Facebook-secured relying parties without password. It was = promptly fixed after reporting. = (http://nakedsecurity.sophos.com/2011/02/02/facebook-flaw-websites-steal-p= ersonal-data/) > Recently, we found a common misunderstanding among developers of = mobile/metro apps when using OAuth (including Facebook=92s OAuth) for = authentication. The vulnerability resulted from this misunderstanding = also allows an attacker to log into a victim user's account without = password. > Let's take Soluto's metro app as an example to describe the problem. = The app supports Facebook Login. As an attacker, we can write a regular = Facebook app. Once the victim user allows our app to access her Facebook = data, we receive an access_token from the traffic. Then, on our own = machine (i.e., the "attacker" machine), we run the metro app of Soluto, = and use a HTTP proxy to insert the victim's access_token into the = traffic of Facebook login. Through this way, we are able to log into the = victim's Soluto account from our machine. Other than Soluto, we also = have confirmed the same issue on another Windows 8 metro-app Givit. > The Facebook SDK for Android apps = (https://developers.facebook.com/docs/mobile/android/build/#sdk) seems = to have the possibility to mislead developers too. At least, the issue = that we found is not clearly mentioned. In the SDK, we ran the sample = code called "Hackbook" using Android Emulator (imagine it is an attacker = device). Note that we have already received the access token of the = victim user from our regular Facebook app. We then inject the token to = the traffic of Hackbook. Through this way, Hackbook app on our own = machine recognizes us as the victim. Note that this is not a convincing = security exploit yet, because this sample code does not include the = server-side code. However, given that we have seen real server-side code = having this problem, such as Soluto, Givit and others, we do believe = that the sample code can mislead mobile/metro developers. We also = suspect that this may be a general issue of many OAuth implementations = on mobile platforms, so we send this message to OAuth Standard group as = well. > We have contacted the vendors of the two vulnerable metro-apps, Soluto = and Gavit. > Please kindly give us an ack when you receive this message. If you = want to know more details, please let us know. > Best Regards, > Yuchen Zhou, Rui Wang, and Shuo Chen >=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 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 >=20 >=20 > --=20 > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_2DD1D5E5-5E44-4BDC-B879-19556A590246 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 https://= graph.facebook.com/app?access_token=3DYOUR_TOKEN (Facebook custom = way, moreover undocumented API)

Two iPhone = app developers I reported this issue fixed it by using = (4).

I also tried to use (1) for my own = iPhone app implementation, but unfortunately it doesn't work when using = authorization codes obtained via FB iOS SDK.
So I'm using (3) = in my case.

nov

On = 2012/06/16, at 9:16, Nat Sakimura wrote:

As to how = the fix was done, Nov can provide more detail, but = ... 

1. Properly verify the signature/HMAC of = the "signed_request". This will essentially audience restricts the = token. 
2. There is an undocumented API for Facebook = which returns to whom the token was issued. This also audience restricts = the token. 

The service that fixed took these measures. Note = that none of the above is defined in OAuth. 
The same = facility was called "id_token" and "check ID endpoint" for OpenID = Connect. 

The scale of the impact is large, too large to = disclose the actual names in the public list, though, eventually, we = would publish them in a = paper. 

Nat

On Sat, Jun 16, 2012 at 5:34 AM, Francisco Corella <fcorella@pomcor.com> = wrote:
Hi Nat and Rui,

Rui, you say that the = vulnerability that you found was due to a
"common misunderstanding = among developers", but the attack you
describe can be carried out against any app that uses the = OAuth
"implicit grant flow", which Facebook calls = "client-side
authentication".  No misunderstanding seems = necessary.  What
misunderstanding are you referring to?  I = followed the link in your
message to the Sophos post, and from there the link to the article = in
The Register.  The article in The Register says that Facebook = had
"fixed the vulnerability promptly".  How did they fix = it?  The
instructions that Facebook provides for implementing = "Client-side
authentication without the JS SDK" at
https://developers.facebook.com/docs/authentication/clie= nt-side/#no-jssdk
still allows the attack.

Nat, I agree that the blog post by John = Bradley that you link to
refers to the same vulnerability reported by = Rui.  You say that some
apps have issued a patch to fix = it.  Could you explain what the fix
was?

Francisco

=
From: Nat Sakimura <sakimura@gmail.com>
To: rui wang <ruiwangwarm@gmail.com>
Cc: matake nov <nov@matake.jp>; = Yuchen Zhou <t-yuzhou@microsoft.com>; oauth <oauth@ietf.org>; = Shuo Chen (MSR) <shuochen@microsoft.com>
Sent: Thursday, June 14, = 2012 1:50 PM
Subject: = Re: [OAUTH-WG] Report an authentication issue
 =

This is a fairly well known (hopefully by now) issue. We, at the = OpenID Foundation, call it "access_token phishing" attack these days. = See: http://www.thread-safe.com/2012/01/problem-with-oauth-fo= r-authentication.html

Nov Matake has actually built the code on iPhone to = verify the problem, and has notified bunch of parties back in February = including Facebook and Apple. We have the code that actually runs on a = phone, and we have successfully logged in to bunch of apps, including = very well known ones. They were all informed of the issue. Some = immediately issued a patch to fix it while others have not.  

The problem is that even if these apps gets fixed, = the problem does not go away. As long as the attacker has the vulnerable = version of the app, he still can impersonate the victim. To stop it, the = server side has to completely disable the older version, which means the = service has to cut off many users pausing business problems. 

Nat

On Fri, Jun 15, 2012 at 2:18 AM, rui = wang <ruiwangwarm@gmail.com> = wrote:
Dear Facebook Security Team and OAuth Standard group,
We are a research team in Microsoft Research. In January, 2011, we = reported a vulnerability in Facebook Connect which allowed everyone to = sign into Facebook-secured relying parties without password. It was = promptly fixed after reporting. (http://nakedsecurity.sophos.com/2011/02/02/facebook-flaw= -websites-steal-personal-data/)
Recently, we found a common misunderstanding among developers of = mobile/metro apps when using OAuth (including Facebook=92s OAuth) for = authentication. The vulnerability resulted from this misunderstanding = also allows an attacker to log into a victim user's account without = password.
Let's take Soluto's metro app as an example to describe the = problem. The app supports Facebook Login. As an attacker, we can write a = regular Facebook app. Once the victim user allows our app to access her = Facebook data, we receive an access_token from the traffic. Then, on our = own machine (i.e., the "attacker" machine), we run the metro app of = Soluto, and use a HTTP proxy to insert the victim's access_token into = the traffic of Facebook login. Through this way, we are able to log into = the victim's Soluto account from our machine. Other than Soluto, we also = have confirmed the same issue on another Windows 8 metro-app = Givit.
The Facebook SDK for Android apps (https://developers.facebook.com/docs/mobile/android/buil= d/#sdk) seems to have the possibility to mislead developers too. At = least, the issue that we found is not clearly mentioned. In the SDK, we = ran the sample code called "Hackbook" using Android Emulator (imagine it = is an attacker device). Note that we have already received the access = token of the victim user from our regular Facebook app. We then inject = the token to the traffic of Hackbook. Through this way, Hackbook app on = our own machine recognizes us as the victim. Note that this is not a = convincing security exploit yet, because this sample code does not = include the server-side code. However, given that we have seen real = server-side code having this problem, such as Soluto, Givit and others, = we do believe that the sample code can mislead mobile/metro developers. We also suspect that this may be a general issue of many = OAuth implementations on mobile platforms, so we send this message to = OAuth Standard group as well.
We have contacted the vendors of the two vulnerable metro-apps, = Soluto and Gavit.
Please kindly give us an ack when you receive this message. If you = want to know more details, please let us know.
Best Regards,
Yuchen Zhou, Rui Wang, and Shuo Chen

_______________________________________________
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


=



-- =
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=_2DD1D5E5-5E44-4BDC-B879-19556A590246-- From kris.selden@gmail.com Sat Jun 16 09:33:06 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6F7421F8543 for ; Sat, 16 Jun 2012 09:33:06 -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 SVhIEg93ZvsR for ; Sat, 16 Jun 2012 09:33:05 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1EC1421F8542 for ; Sat, 16 Jun 2012 09:33:05 -0700 (PDT) Received: by dacx6 with SMTP id x6so5261703dac.31 for ; Sat, 16 Jun 2012 09:33:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=DEIltjyls2qXUlyrEKbk83Kp333qwV+USj509OASDLQ=; b=zFOVDzwXNfo7XCHuyqDRpillvUooMqusPD9HyqMCaCJVI1ysZtSSkRq8DWfHEKUS7s 7mllWk+jknKQNmCa6QpFHf6GlaTUtFxinxvKS6ZvI/i5cKKG8OnFCcgnd5wY6Hn12I0T bKDsQQzcVulMrj1vbTFF0XsX87955K6tkIZSoLwZLru/NPPGXG9/Qg2JjyBegdE2DJ5P MeDnxqpUe5OOy829q5WZ0Tdluk6vZhoFXCE4v9zLDCehzvSXW+ZmoCyx97GzdQaWZWRy cD+tk8IqHHV+pQ7A0UD9QCGcY953tYjfJpKSVLUp7ttQ9uVBQmEPuvQk+NjTDLvrd3Df 3Ptg== Received: by 10.68.226.226 with SMTP id rv2mr32687668pbc.101.1339864384549; Sat, 16 Jun 2012 09:33:04 -0700 (PDT) Received: from [10.0.1.7] (c-24-17-231-146.hsd1.wa.comcast.net. [24.17.231.146]) by mx.google.com with ESMTPS id hc7sm17289586pbc.54.2012.06.16.09.33.02 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 16 Jun 2012 09:33:03 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_A9788739-84C2-498C-9594-C89766F4AB8A" From: Kristofor Selden In-Reply-To: Date: Sat, 16 Jun 2012 09:33:01 -0700 Message-Id: References: <1339792496.52712.YahooMailNeo@web125501.mail.ne1.yahoo.com> To: nov matake , oauth X-Mailer: Apple Mail (2.1257) Cc: Yuchen Zhou , Luke Melia , "Shuo Chen \(MSR\)" Subject: Re: [OAUTH-WG] Report an authentication issue X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 16:33:07 -0000 --Apple-Mail=_A9788739-84C2-498C-9594-C89766F4AB8A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Nov demonstrated the problem to us at Yapp and we used solution 4 = (because the solution is server side and our app was in the app store). FB Connect is authentication and authorization, where OAuth 2 is = concerned only with authorization =96 I'm not sure that app developers = appreciate this subtlety. With OAuth 2 you authorize an app to use a protected resource. With FB = Connect, you do that, but also authenticate with the app you are = authorizing. So the access_token protects not just the FB resources but the auth end = point of the authorized app (very common with apps that use the iOS = SDK). So now the app needs a way to verify that it was the app that was = authorized to FB. Solution 4 explanation: on FB you can register a iPhone app and a server = app with the same client_id and get a client_secret for use on the = server. The server side API posts the access_token, client_id, and = client_secret to https://graph.facebook.com/app to verify that the = bearer token actually belongs to the app that is being authenticated = before assuming they are authorized to the app's protected resources. Kris On Jun 15, 2012, at 8:22 PM, nov matake wrote: > There are 4 ways to fix this issue. >=20 > 1. Use response_type=3Dtoken%20code (It's not in OAuth 2.0 Core, but = seems best way for interoperability) > 2. Use singed_request (or some signed token like JWT) > 3. Use grant_type=3Dfb_exchange_token (Facebook custom way) > 4. Access to https://graph.facebook.com/app?access_token=3DYOUR_TOKEN = (Facebook custom way, moreover undocumented API) >=20 > Two iPhone app developers I reported this issue fixed it by using (4). >=20 > I also tried to use (1) for my own iPhone app implementation, but = unfortunately it doesn't work when using authorization codes obtained = via FB iOS SDK. > So I'm using (3) in my case. >=20 > nov >=20 > On 2012/06/16, at 9:16, Nat Sakimura wrote: >=20 >> As to how the fix was done, Nov can provide more detail, but ...=20 >>=20 >> 1. Properly verify the signature/HMAC of the "signed_request". This = will essentially audience restricts the token.=20 >> 2. There is an undocumented API for Facebook which returns to whom = the token was issued. This also audience restricts the token.=20 >>=20 >> The service that fixed took these measures. Note that none of the = above is defined in OAuth.=20 >> The same facility was called "id_token" and "check ID endpoint" for = OpenID Connect.=20 >>=20 >> The scale of the impact is large, too large to disclose the actual = names in the public list, though, eventually, we would publish them in a = paper.=20 >>=20 >> Nat >>=20 >> On Sat, Jun 16, 2012 at 5:34 AM, Francisco Corella = wrote: >> Hi Nat and Rui, >>=20 >> Rui, you say that the vulnerability that you found was due to a >> "common misunderstanding among developers", but the attack you >> describe can be carried out against any app that uses the OAuth >> "implicit grant flow", which Facebook calls "client-side >> authentication". No misunderstanding seems necessary. What >> misunderstanding are you referring to? I followed the link in your >> message to the Sophos post, and from there the link to the article in >> The Register. The article in The Register says that Facebook had >> "fixed the vulnerability promptly". How did they fix it? The >> instructions that Facebook provides for implementing "Client-side >> authentication without the JS SDK" at >> = https://developers.facebook.com/docs/authentication/client-side/#no-jssdk >> still allows the attack. >>=20 >> Nat, I agree that the blog post by John Bradley that you link to >> refers to the same vulnerability reported by Rui. You say that some >> apps have issued a patch to fix it. Could you explain what the fix >> was? >>=20 >> Francisco >>=20 >> From: Nat Sakimura >> To: rui wang =20 >> Cc: matake nov ; Yuchen Zhou ; = oauth ; Shuo Chen (MSR) =20 >> Sent: Thursday, June 14, 2012 1:50 PM >> Subject: Re: [OAUTH-WG] Report an authentication issue >>=20 >> This is a fairly well known (hopefully by now) issue. We, at the = OpenID Foundation, call it "access_token phishing" attack these days. = See: = http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.h= tml >>=20 >> Nov Matake has actually built the code on iPhone to verify the = problem, and has notified bunch of parties back in February including = Facebook and Apple. We have the code that actually runs on a phone, and = we have successfully logged in to bunch of apps, including very well = known ones. They were all informed of the issue. Some immediately issued = a patch to fix it while others have not. =20 >>=20 >> The problem is that even if these apps gets fixed, the problem does = not go away. As long as the attacker has the vulnerable version of the = app, he still can impersonate the victim. To stop it, the server side = has to completely disable the older version, which means the service has = to cut off many users pausing business problems.=20 >>=20 >> Nat >>=20 >> On Fri, Jun 15, 2012 at 2:18 AM, rui wang = wrote: >> Dear Facebook Security Team and OAuth Standard group, >> We are a research team in Microsoft Research. In January, 2011, we = reported a vulnerability in Facebook Connect which allowed everyone to = sign into Facebook-secured relying parties without password. It was = promptly fixed after reporting. = (http://nakedsecurity.sophos.com/2011/02/02/facebook-flaw-websites-steal-p= ersonal-data/) >> Recently, we found a common misunderstanding among developers of = mobile/metro apps when using OAuth (including Facebook=92s OAuth) for = authentication. The vulnerability resulted from this misunderstanding = also allows an attacker to log into a victim user's account without = password. >> Let's take Soluto's metro app as an example to describe the problem. = The app supports Facebook Login. As an attacker, we can write a regular = Facebook app. Once the victim user allows our app to access her Facebook = data, we receive an access_token from the traffic. Then, on our own = machine (i.e., the "attacker" machine), we run the metro app of Soluto, = and use a HTTP proxy to insert the victim's access_token into the = traffic of Facebook login. Through this way, we are able to log into the = victim's Soluto account from our machine. Other than Soluto, we also = have confirmed the same issue on another Windows 8 metro-app Givit. >> The Facebook SDK for Android apps = (https://developers.facebook.com/docs/mobile/android/build/#sdk) seems = to have the possibility to mislead developers too. At least, the issue = that we found is not clearly mentioned. In the SDK, we ran the sample = code called "Hackbook" using Android Emulator (imagine it is an attacker = device). Note that we have already received the access token of the = victim user from our regular Facebook app. We then inject the token to = the traffic of Hackbook. Through this way, Hackbook app on our own = machine recognizes us as the victim. Note that this is not a convincing = security exploit yet, because this sample code does not include the = server-side code. However, given that we have seen real server-side code = having this problem, such as Soluto, Givit and others, we do believe = that the sample code can mislead mobile/metro developers. We also = suspect that this may be a general issue of many OAuth implementations = on mobile platforms, so we send this message to OAuth Standard group as = well. >> We have contacted the vendors of the two vulnerable metro-apps, = Soluto and Gavit. >> Please kindly give us an ack when you receive this message. If you = want to know more details, please let us know. >> Best Regards, >> Yuchen Zhou, Rui Wang, and Shuo Chen >>=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 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >>=20 >>=20 >>=20 >> --=20 >> Nat Sakimura (=3Dnat) >> Chairman, OpenID Foundation >> http://nat.sakimura.org/ >> @_nat_en >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_A9788739-84C2-498C-9594-C89766F4AB8A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 https://= graph.facebook.com/app to verify that the bearer token = actually belongs to the app that is being authenticated before assuming = they are authorized to the app's protected = resources.

Kris

On Jun 15, = 2012, at 8:22 PM, nov matake wrote:

There are 4 ways to fix = this issue.

1. Use response_type=3Dtoken%20code = (It's not in OAuth 2.0 Core, but seems best way for = interoperability)
2. Use singed_request (or some signed token = like JWT)
3. Use grant_type=3Dfb_exchange_token (Facebook custom = way)
4. Access to https://= graph.facebook.com/app?access_token=3DYOUR_TOKEN (Facebook custom = way, moreover undocumented API)

Two iPhone = app developers I reported this issue fixed it by using = (4).

I also tried to use (1) for my own = iPhone app implementation, but unfortunately it doesn't work when using = authorization codes obtained via FB iOS SDK.
So I'm using (3) = in my case.

nov

On = 2012/06/16, at 9:16, Nat Sakimura wrote:

As to how = the fix was done, Nov can provide more detail, but = ... 

1. Properly verify the signature/HMAC of = the "signed_request". This will essentially audience restricts the = token. 
2. There is an undocumented API for Facebook = which returns to whom the token was issued. This also audience restricts = the token. 

The service that fixed took these measures. Note = that none of the above is defined in OAuth. 
The same = facility was called "id_token" and "check ID endpoint" for OpenID = Connect. 

The scale of the impact is large, too large to = disclose the actual names in the public list, though, eventually, we = would publish them in a = paper. 

Nat

On Sat, Jun 16, 2012 at 5:34 AM, Francisco Corella <fcorella@pomcor.com> = wrote:
Hi Nat and Rui,

Rui, you say that the = vulnerability that you found was due to a
"common misunderstanding = among developers", but the attack you
describe can be carried out against any app that uses the = OAuth
"implicit grant flow", which Facebook calls = "client-side
authentication".  No misunderstanding seems = necessary.  What
misunderstanding are you referring to?  I = followed the link in your
message to the Sophos post, and from there the link to the article = in
The Register.  The article in The Register says that Facebook = had
"fixed the vulnerability promptly".  How did they fix = it?  The
instructions that Facebook provides for implementing = "Client-side
authentication without the JS SDK" at
https://developers.facebook.com/docs/authentication/clie= nt-side/#no-jssdk
still allows the attack.

Nat, I agree that the blog post by John = Bradley that you link to
refers to the same vulnerability reported by = Rui.  You say that some
apps have issued a patch to fix = it.  Could you explain what the fix
was?

Francisco

=
From: Nat Sakimura <sakimura@gmail.com>
To: rui wang <ruiwangwarm@gmail.com>
Cc: matake nov <nov@matake.jp>; = Yuchen Zhou <t-yuzhou@microsoft.com>; oauth <oauth@ietf.org>; = Shuo Chen (MSR) <shuochen@microsoft.com>
Sent: Thursday, June 14, = 2012 1:50 PM
Subject: = Re: [OAUTH-WG] Report an authentication issue
 =

This is a fairly well known (hopefully by now) issue. We, at the = OpenID Foundation, call it "access_token phishing" attack these days. = See: http://www.thread-safe.com/2012/01/problem-with-oauth-fo= r-authentication.html

Nov Matake has actually built the code on iPhone to = verify the problem, and has notified bunch of parties back in February = including Facebook and Apple. We have the code that actually runs on a = phone, and we have successfully logged in to bunch of apps, including = very well known ones. They were all informed of the issue. Some = immediately issued a patch to fix it while others have not.  

The problem is that even if these apps gets fixed, = the problem does not go away. As long as the attacker has the vulnerable = version of the app, he still can impersonate the victim. To stop it, the = server side has to completely disable the older version, which means the = service has to cut off many users pausing business problems. 

Nat

On Fri, Jun 15, 2012 at 2:18 AM, rui = wang <ruiwangwarm@gmail.com> = wrote:
Dear Facebook Security Team and OAuth Standard group,
We are a research team in Microsoft Research. In January, 2011, we = reported a vulnerability in Facebook Connect which allowed everyone to = sign into Facebook-secured relying parties without password. It was = promptly fixed after reporting. (http://nakedsecurity.sophos.com/2011/02/02/facebook-flaw= -websites-steal-personal-data/)
Recently, we found a common misunderstanding among developers of = mobile/metro apps when using OAuth (including Facebook=92s OAuth) for = authentication. The vulnerability resulted from this misunderstanding = also allows an attacker to log into a victim user's account without = password.
Let's take Soluto's metro app as an example to describe the = problem. The app supports Facebook Login. As an attacker, we can write a = regular Facebook app. Once the victim user allows our app to access her = Facebook data, we receive an access_token from the traffic. Then, on our = own machine (i.e., the "attacker" machine), we run the metro app of = Soluto, and use a HTTP proxy to insert the victim's access_token into = the traffic of Facebook login. Through this way, we are able to log into = the victim's Soluto account from our machine. Other than Soluto, we also = have confirmed the same issue on another Windows 8 metro-app = Givit.
The Facebook SDK for Android apps (https://developers.facebook.com/docs/mobile/android/buil= d/#sdk) seems to have the possibility to mislead developers too. At = least, the issue that we found is not clearly mentioned. In the SDK, we = ran the sample code called "Hackbook" using Android Emulator (imagine it = is an attacker device). Note that we have already received the access = token of the victim user from our regular Facebook app. We then inject = the token to the traffic of Hackbook. Through this way, Hackbook app on = our own machine recognizes us as the victim. Note that this is not a = convincing security exploit yet, because this sample code does not = include the server-side code. However, given that we have seen real = server-side code having this problem, such as Soluto, Givit and others, = we do believe that the sample code can mislead mobile/metro developers. We also suspect that this may be a general issue of many = OAuth implementations on mobile platforms, so we send this message to = OAuth Standard group as well.
We have contacted the vendors of the two vulnerable metro-apps, = Soluto and Gavit.
Please kindly give us an ack when you receive this message. If you = want to know more details, please let us know.
Best Regards,
Yuchen Zhou, Rui Wang, and Shuo Chen

_______________________________________________
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


=



-- =
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=_A9788739-84C2-498C-9594-C89766F4AB8A-- From Michael.Jones@microsoft.com Sat Jun 16 12:17:16 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D4A121F8507 for ; Sat, 16 Jun 2012 12:17:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.859 X-Spam-Level: X-Spam-Status: No, score=-3.859 tagged_above=-999 required=5 tests=[AWL=-0.261, 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 uwn-r-daEc4m for ; Sat, 16 Jun 2012 12:17:13 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by ietfa.amsl.com (Postfix) with ESMTP id 1C54F21F84FD for ; Sat, 16 Jun 2012 12:17:13 -0700 (PDT) Received: from mail126-ch1-R.bigfish.com (10.43.68.253) by CH1EHSOBE016.bigfish.com (10.43.70.66) with Microsoft SMTP Server id 14.1.225.23; Sat, 16 Jun 2012 19:15:59 +0000 Received: from mail126-ch1 (localhost [127.0.0.1]) by mail126-ch1-R.bigfish.com (Postfix) with ESMTP id 081564E00A9; Sat, 16 Jun 2012 19:15:59 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC105.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -28 X-BigFish: VS-28(zz9371Ic85fh148cI542M1432Izz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25hf0ah) Received-SPF: pass (mail126-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC105.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail126-ch1 (localhost.localdomain [127.0.0.1]) by mail126-ch1 (MessageSwitch) id 1339874156779332_1746; Sat, 16 Jun 2012 19:15:56 +0000 (UTC) Received: from CH1EHSMHS001.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.231]) by mail126-ch1.bigfish.com (Postfix) with ESMTP id BC8E7120043; Sat, 16 Jun 2012 19:15:56 +0000 (UTC) Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS001.bigfish.com (10.43.70.1) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 16 Jun 2012 19:15:56 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.53]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.02.0309.003; Sat, 16 Jun 2012 19:17:07 +0000 From: Mike Jones To: Eran Hammer , "oauth@ietf.org WG (oauth@ietf.org)" Thread-Topic: [OAUTH-WG] Section 7.2 Thread-Index: AQHNSnlK4rMFHIKNpEG6QNgV8mtEhJb6Y6gAgAABoQCAACqMcIAAXHmAgAJnIXA= Date: Sat, 16 Jun 2012 19:17:06 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366554B42@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <0CBAEB56DDB3A140BA8E8C124C04ECA201073394@P3PWEX2MB008.ex2.secureserver.net> <4E1F6AAD24975D4BA5B1680429673943665394D7@TK5EX14MBXC284.redmond.corp.microsoft.com> <0CBAEB56DDB3A140BA8E8C124C04ECA2010734C5@P3PWEX2MB008.ex2.secureserver.net> <0CBAEB56DDB3A140BA8E8C124C04ECA201073573@P3PWEX2MB008.ex2.secureserver.net> <4E1F6AAD24975D4BA5B168042967394366539839@TK5EX14MBXC284.redmond.corp.microsoft.com> <0CBAEB56DDB3A140BA8E8C124C04ECA201073B82@P3PWEX2MB008.ex2.secureserver.net> In-Reply-To: <0CBAEB56DDB3A140BA8E8C124C04ECA201073B82@P3PWEX2MB008.ex2.secureserver.net> 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_4E1F6AAD24975D4BA5B168042967394366554B42TK5EX14MBXC283r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [OAUTH-WG] Section 7.2 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jun 2012 19:17:16 -0000 --_000_4E1F6AAD24975D4BA5B168042967394366554B42TK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable While adding the new text into a proposed draft, I realized that no charact= er set restrictions on the error code values were defined in the agreed tex= t. Therefore, I've added the following sentence (which was already present= in -27): Values for these error codes MUST NOT include characters outside the set %x20-21 / %x23-5B / %x5D-7E. This is the same restriction that is referenced every other place that the = "error" parameter is used in the draft. -- Mike From: Eran Hammer [mailto:eran@hueniverse.com] Sent: Thursday, June 14, 2012 11:32 PM To: Mike Jones; oauth@ietf.org WG (oauth@ietf.org) Subject: RE: [OAUTH-WG] Section 7.2 WFM. This will be the new text for 7.2 unless someone has any additional feedbac= k or concerns. This closes my issue with the new error registry changes. EH From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Thursday, June 14, 2012 6:15 PM To: Eran Hammer; oauth@ietf.org WG (oauth@ietf.org) Subject: RE: [OAUTH-WG] Section 7.2 Thanks for writing the text below. It looks fine to me. About adding the = other error parameters as suggestions, that seems like a reasonable thing t= o do. How about the text at the end below, which adds mentions of error_de= scription and error_uri? 7.2. Error Response If a resource access request fails, the resource server SHOULD inform the client of the error. While the specifics of such error responses are beyond the scope of this specification, this documents establishes a common registry for error values to be shared among OAuth token authentication schemes. New authentication schemes designed primarily for OAuth token authentication SHOULD define a mechanism for providing an error status code to the client, in which the error values allowed are registered in the error registry established by this specification. Such schemes MAY limit the set of valid error codes to a subset of the registered values. If the error code is returned using a named parameter= , the parameter name SHOULD be "error". Other schemes capable of being used for OAuth token authentication, but not primarily designed for that purpose, MAY bind their error values to = the registry in the same manner. New authentication schemes MAY choose to also specify the use of the "error_description" and "error_uri" parameters to return error informati= on in a manner parallel to their usage in this specification. -- Mike P.S. If you already have the text you wrote in a copy of the draft, you sh= ould apply these spelling corrections: desgined -> designed authentiction -> authentication -----Original Message----- From: Eran Hammer [mailto:eran@hueniverse.com] Sent: Thursday, June 14, 2012 3:29 PM To: Eran Hammer; Mike Jones; oauth@ietf.org WG (oaut= h@ietf.org) Subject: RE: [OAUTH-WG] Section 7.2 Mike - if you want to add the other error parameters as suggestions, that w= ould be fine by me. EH > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth= -bounces@ietf.org] On Behalf > Of Eran Hammer > Sent: Thursday, June 14, 2012 3:23 PM > To: Mike Jones; oauth@ietf.org WG (oauth@ietf.org<= mailto:oauth@ietf.org>) > Subject: Re: [OAUTH-WG] Section 7.2 > > 7.2. Error Response > > If a resource access request fails, the resource server SHOULD inform > the client of the error. While the specifics of such error responses > are beyond the scope of this specification, this documents establishes > a common registry for error values to be shared among OAuth token > authentication schemes. > > New authentication schemes desgined primarily for OAuth token > authentiction SHOULD define a mechanism for providing an > error status code to the client, in which the error values allowed are > registered in the error registry established by this specification. Su= ch > schemes MAY limit the set of valid error codes to a subset of the > registered values. If the error code is returned using a named paramet= er, > the parameter name SHOULD be "error". > > Other schemes capable of being used for OAuth token authentication, bu= t > not primarily designed for that purpose, MAY bind their error values t= o the > registry in the same manner. > > EH > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --_000_4E1F6AAD24975D4BA5B168042967394366554B42TK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

While adding the new t= ext into a proposed draft, I realized that no character set restrictions on= the error code values were defined in the agreed text.  Therefore, I&= #8217;ve added the following sentence (which was already present in -27):

   &nbs= p;             Value= s for these error codes MUST NOT include

   &nbs= p;             chara= cters outside the set %x20-21 / %x23-5B / %x5D-7E.

 

This is the same restr= iction that is referenced every other place that the “error” pa= rameter is used in the draft.

 

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

 

From: Eran Ham= mer [mailto:eran@hueniverse.com]
Sent: Thursday, June 14, 2012 11:32 PM
To: Mike Jones; oauth@ietf.org WG (oauth@ietf.org)
Subject: RE: [OAUTH-WG] Section 7.2

 

WFM.=

 

This will be the new t= ext for 7.2 unless someone has any additional feedback or concerns.

 

This closes my issue w= ith the new error registry changes.

 

EH

 

From: Mike Jon= es [mailto:Michael.Jon= es@microsoft.com]
Sent: Thursday, June 14, 2012 6:15 PM
To: Eran Hammer; oauth@ietf.org WG (oauth@ietf.org)
Subject: RE: [OAUTH-WG] Section 7.2

 

Thanks for writing the text below.  It looks= fine to me.  About adding the other error parameters as suggestions, = that seems like a reasonable thing to do.  How about the text at the e= nd below, which adds mentions of error_description and error_uri?

 

7.2.  Error Response

 

   If a resource access request fails, the resource server SHO= ULD inform

   the client of the error.  While the specifics of such = error responses

   are beyond the scope of this specification, this documents = establishes

   a common registry for error values to be shared among OAuth= token

   authentication schemes.

 

   New authentication schemes designed primarily for OAuth tok= en

   authentication SHOULD define a mechanism for providing an

   error status code to the client, in which the error values = allowed are

   registered in the error registry established by this specif= ication. Such

   schemes MAY limit the set of valid error codes to a subset = of the

   registered values. If the error code is returned using a na= med parameter,

   the parameter name SHOULD be "error".<= /span>

 

   Other schemes capable of being used for OAuth token authent= ication, but

   not primarily designed for that purpose, MAY bind their err= or values to the

   registry in the same manner.

 

   New authentication schemes MAY choose to also specify the u= se of the

   "error_description" and "error_uri" par= ameters to return error information

   in a manner parallel to their usage in this specification.<= o:p>

 

 

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

 

P.S.  If you already have the text you wrote= in a copy of the draft, you should apply these spelling corrections:<= /o:p>

        &= nbsp;      desgined -> designed

        &= nbsp;      authentiction -> authentication=

 

-----Original Message-----
From: Eran Hammer [mailto:e= ran@hueniverse.com]
Sent: Thursday, June 14, 2012 3:29 PM
To: Eran Hammer; Mike Jones; oauth@ietf.o= rg WG (oauth@ietf.org)
Subject: RE: [OAUTH-WG] Section 7.2

 

Mike - if you want to add the other error paramet= ers as suggestions, that would be fine by me.

 

EH

 

> -----Original Message-----

> From: oauth-bounces@iet= f.org [mailto:oauth-bounces@ietf.org] On= Behalf

> Of Eran Hammer

> Sent: Thursday, June 14, 2012 3:23 PM

> To: Mike Jones; oauth@ietf.org<= /span> WG (oauth@ietf.org)

> Subject: Re: [OAUTH-WG] Section 7.2

>

> 7.2.  Error Response

>

>    If a resource access reque= st fails, the resource server SHOULD inform

>    the client of the error.&n= bsp; While the specifics of such error responses

>    are beyond the scope of th= is specification, this documents establishes

>    a common registry for erro= r values to be shared among OAuth token

>    authentication schemes.

>

>    New authentication schemes= desgined primarily for OAuth token

>    authentiction SHOULD defin= e a mechanism for providing an

>    error status code to the c= lient, in which the error values allowed are

>    registered in the error re= gistry established by this specification. Such

>    schemes MAY limit the set = of valid error codes to a subset of the

>    registered values. If the = error code is returned using a named parameter,

>    the parameter name SHOULD = be "error".

>

>    Other schemes capable of b= eing used for OAuth token authentication, but

>    not primarily designed for= that purpose, MAY bind their error values to the

>    registry in the same manne= r.

>

> EH

>

> ____________________________________________= ___

> OAuth mailing list

> OAuth@ietf.org<= /o:p>

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

 

--_000_4E1F6AAD24975D4BA5B168042967394366554B42TK5EX14MBXC283r_-- From eran@hueniverse.com Sat Jun 16 12:43:55 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A389721F84A1 for ; Sat, 16 Jun 2012 12:43:55 -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 68dT6728dta2 for ; Sat, 16 Jun 2012 12:43:52 -0700 (PDT) Received: from p3plex2out04.prod.phx3.secureserver.net (p3plex2out04.prod.phx3.secureserver.net [184.168.131.18]) by ietfa.amsl.com (Postfix) with ESMTP id EC0AC21F8501 for ; Sat, 16 Jun 2012 12:43:39 -0700 (PDT) Received: from P3PWEX2HT001.ex2.secureserver.net ([184.168.131.9]) by p3plex2out04.prod.phx3.secureserver.net with bizsmtp id P7je1j0020CJzpC017jebt; Sat, 16 Jun 2012 12:43:38 -0700 Received: from P3PWEX2MB008.ex2.secureserver.net ([169.254.8.66]) by P3PWEX2HT001.ex2.secureserver.net ([184.168.131.9]) with mapi id 14.02.0247.003; Sat, 16 Jun 2012 12:43:38 -0700 From: Eran Hammer To: Mike Jones , "oauth@ietf.org WG (oauth@ietf.org)" Thread-Topic: [OAUTH-WG] Section 7.2 Thread-Index: Ac1KeB4PVUuFMDsJRu+q5d/rw0G4WQAO9iAAAA6cN3AAHFVLIP/+3oCAgAAc8FCAAqOrAIAAbiTQ Date: Sat, 16 Jun 2012 19:43:37 +0000 Message-ID: <0CBAEB56DDB3A140BA8E8C124C04ECA201075967@P3PWEX2MB008.ex2.secureserver.net> References: <0CBAEB56DDB3A140BA8E8C124C04ECA201073394@P3PWEX2MB008.ex2.secureserver.net> <4E1F6AAD24975D4BA5B1680429673943665394D7@TK5EX14MBXC284.redmond.corp.microsoft.com> <0CBAEB56DDB3A140BA8E8C124C04ECA2010734C5@P3PWEX2MB008.ex2.secureserver.net> <0CBAEB56DDB3A140BA8E8C124C04ECA201073573@P3PWEX2MB008.ex2.secureserver.net> <4E1F6AAD24975D4BA5B168042967394366539839@TK5EX14MBXC284.redmond.corp.microsoft.com> <0CBAEB56DDB3A140BA8E8C124C04ECA201073B82@P3PWEX2MB008.ex2.secureserver.net> <4E1F6AAD24975D4BA5B168042967394366554B42@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366554B42@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [109.2.71.183] Content-Type: multipart/alternative; boundary="_000_0CBAEB56DDB3A140BA8E8C124C04ECA201075967P3PWEX2MB008ex2_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Section 7.2 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jun 2012 19:43:55 -0000 --_000_0CBAEB56DDB3A140BA8E8C124C04ECA201075967P3PWEX2MB008ex2_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I would rather these restrictions be in the error registry section below an= d add a forward reference from 7.2. EH From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Saturday, June 16, 2012 12:17 PM To: Eran Hammer; oauth@ietf.org WG (oauth@ietf.org) Subject: RE: [OAUTH-WG] Section 7.2 While adding the new text into a proposed draft, I realized that no charact= er set restrictions on the error code values were defined in the agreed tex= t. Therefore, I've added the following sentence (which was already present= in -27): Values for these error codes MUST NOT include characters outside the set %x20-21 / %x23-5B / %x5D-7E. This is the same restriction that is referenced every other place that the = "error" parameter is used in the draft. -- Mike From: Eran Hammer [mailto:eran@hueniverse.com] Sent: Thursday, June 14, 2012 11:32 PM To: Mike Jones; oauth@ietf.org WG (oauth@ietf.org) Subject: RE: [OAUTH-WG] Section 7.2 WFM. This will be the new text for 7.2 unless someone has any additional feedbac= k or concerns. This closes my issue with the new error registry changes. EH From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Thursday, June 14, 2012 6:15 PM To: Eran Hammer; oauth@ietf.org WG (oauth@ietf.org) Subject: RE: [OAUTH-WG] Section 7.2 Thanks for writing the text below. It looks fine to me. About adding the = other error parameters as suggestions, that seems like a reasonable thing t= o do. How about the text at the end below, which adds mentions of error_de= scription and error_uri? 7.2. Error Response If a resource access request fails, the resource server SHOULD inform the client of the error. While the specifics of such error responses are beyond the scope of this specification, this documents establishes a common registry for error values to be shared among OAuth token authentication schemes. New authentication schemes designed primarily for OAuth token authentication SHOULD define a mechanism for providing an error status code to the client, in which the error values allowed are registered in the error registry established by this specification. Such schemes MAY limit the set of valid error codes to a subset of the registered values. If the error code is returned using a named parameter= , the parameter name SHOULD be "error". Other schemes capable of being used for OAuth token authentication, but not primarily designed for that purpose, MAY bind their error values to = the registry in the same manner. New authentication schemes MAY choose to also specify the use of the "error_description" and "error_uri" parameters to return error informati= on in a manner parallel to their usage in this specification. -- Mike P.S. If you already have the text you wrote in a copy of the draft, you sh= ould apply these spelling corrections: desgined -> designed authentiction -> authentication -----Original Message----- From: Eran Hammer [mailto:eran@hueniverse.com] Sent: Thursday, June 14, 2012 3:29 PM To: Eran Hammer; Mike Jones; oauth@ietf.org WG (oaut= h@ietf.org) Subject: RE: [OAUTH-WG] Section 7.2 Mike - if you want to add the other error parameters as suggestions, that w= ould be fine by me. EH > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth= -bounces@ietf.org] On Behalf > Of Eran Hammer > Sent: Thursday, June 14, 2012 3:23 PM > To: Mike Jones; oauth@ietf.org WG (oauth@ietf.org<= mailto:oauth@ietf.org>) > Subject: Re: [OAUTH-WG] Section 7.2 > > 7.2. Error Response > > If a resource access request fails, the resource server SHOULD inform > the client of the error. While the specifics of such error responses > are beyond the scope of this specification, this documents establishes > a common registry for error values to be shared among OAuth token > authentication schemes. > > New authentication schemes desgined primarily for OAuth token > authentiction SHOULD define a mechanism for providing an > error status code to the client, in which the error values allowed are > registered in the error registry established by this specification. Su= ch > schemes MAY limit the set of valid error codes to a subset of the > registered values. If the error code is returned using a named paramet= er, > the parameter name SHOULD be "error". > > Other schemes capable of being used for OAuth token authentication, bu= t > not primarily designed for that purpose, MAY bind their error values t= o the > registry in the same manner. > > EH > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --_000_0CBAEB56DDB3A140BA8E8C124C04ECA201075967P3PWEX2MB008ex2_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I would rather these r= estrictions be in the error registry section below and add a forward refere= nce from 7.2.

 

EH

 

From: Mike Jon= es [mailto:Michael.Jones@microsoft.com]
Sent: Saturday, June 16, 2012 12:17 PM
To: Eran Hammer; oauth@ietf.org WG (oauth@ietf.org)
Subject: RE: [OAUTH-WG] Section 7.2

 

While adding the new t= ext into a proposed draft, I realized that no character set restrictions on= the error code values were defined in the agreed text.  Therefore, I&= #8217;ve added the following sentence (which was already present in -27):

   &nbs= p;             Value= s for these error codes MUST NOT include

   &nbs= p;             chara= cters outside the set %x20-21 / %x23-5B / %x5D-7E.

 

This is the same restr= iction that is referenced every other place that the “error” pa= rameter is used in the draft.

 

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

 

From: Eran Ham= mer [mailto:eran@hueniverse.com= ]
Sent: Thursday, June 14, 2012 11:32 PM
To: Mike Jones; oauth@ietf.org= WG (oauth@ietf.org)
Subject: RE: [OAUTH-WG] Section 7.2

 

WFM.=

 

This will be the new t= ext for 7.2 unless someone has any additional feedback or concerns.

 

This closes my issue w= ith the new error registry changes.

 

EH

 

From: Mike Jon= es [mailto:Michael.Jon= es@microsoft.com]
Sent: Thursday, June 14, 2012 6:15 PM
To: Eran Hammer; oauth@ietf.org WG (oauth@ietf.org)
Subject: RE: [OAUTH-WG] Section 7.2

 

Thanks for writing the text below.  It looks= fine to me.  About adding the other error parameters as suggestions, = that seems like a reasonable thing to do.  How about the text at the e= nd below, which adds mentions of error_description and error_uri?

 

7.2.  Error Response

 

   If a resource access request fails, the resource server SHO= ULD inform

   the client of the error.  While the specifics of such = error responses

   are beyond the scope of this specification, this documents = establishes

   a common registry for error values to be shared among OAuth= token

   authentication schemes.

 

   New authentication schemes designed primarily for OAuth tok= en

   authentication SHOULD define a mechanism for providing an

   error status code to the client, in which the error values = allowed are

   registered in the error registry established by this specif= ication. Such

   schemes MAY limit the set of valid error codes to a subset = of the

   registered values. If the error code is returned using a na= med parameter,

   the parameter name SHOULD be "error".<= /span>

 

   Other schemes capable of being used for OAuth token authent= ication, but

   not primarily designed for that purpose, MAY bind their err= or values to the

   registry in the same manner.

 

   New authentication schemes MAY choose to also specify the u= se of the

   "error_description" and "error_uri" par= ameters to return error information

   in a manner parallel to their usage in this specification.<= o:p>

 

 

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

 

P.S.  If you already have the text you wrote= in a copy of the draft, you should apply these spelling corrections:<= /o:p>

        &= nbsp;      desgined -> designed

        &= nbsp;      authentiction -> authentication=

 

-----Original Message-----
From: Eran Hammer [mailto:e= ran@hueniverse.com]
Sent: Thursday, June 14, 2012 3:29 PM
To: Eran Hammer; Mike Jones; oauth@ietf.o= rg WG (oauth@ietf.org)
Subject: RE: [OAUTH-WG] Section 7.2

 

Mike - if you want to add the other error paramet= ers as suggestions, that would be fine by me.

 

EH

 

> -----Original Message-----

> From: oauth-bounces@iet= f.org [mailto:oauth-bounces@ietf.org] On= Behalf

> Of Eran Hammer

> Sent: Thursday, June 14, 2012 3:23 PM

> To: Mike Jones; oauth@ietf.org<= /span> WG (oauth@ietf.org)

> Subject: Re: [OAUTH-WG] Section 7.2

>

> 7.2.  Error Response

>

>    If a resource access reque= st fails, the resource server SHOULD inform

>    the client of the error.&n= bsp; While the specifics of such error responses

>    are beyond the scope of th= is specification, this documents establishes

>    a common registry for erro= r values to be shared among OAuth token

>    authentication schemes.

>

>    New authentication schemes= desgined primarily for OAuth token

>    authentiction SHOULD defin= e a mechanism for providing an

>    error status code to the c= lient, in which the error values allowed are

>    registered in the error re= gistry established by this specification. Such

>    schemes MAY limit the set = of valid error codes to a subset of the

>    registered values. If the = error code is returned using a named parameter,

>    the parameter name SHOULD = be "error".

>

>    Other schemes capable of b= eing used for OAuth token authentication, but

>    not primarily designed for= that purpose, MAY bind their error values to the

>    registry in the same manne= r.

>

> EH

>

> ____________________________________________= ___

> OAuth mailing list

> OAuth@ietf.org<= /o:p>

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

 

--_000_0CBAEB56DDB3A140BA8E8C124C04ECA201075967P3PWEX2MB008ex2_-- From Michael.Jones@microsoft.com Sat Jun 16 12:54:27 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 603BC21F8501 for ; Sat, 16 Jun 2012 12:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.098 X-Spam-Level: X-Spam-Status: No, score=-5.098 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_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 k5FBnz-J+UP1 for ; Sat, 16 Jun 2012 12:54:26 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by ietfa.amsl.com (Postfix) with ESMTP id EAFB021F84FC for ; Sat, 16 Jun 2012 12:54:25 -0700 (PDT) Received: from mail113-tx2-R.bigfish.com (10.9.14.240) by TX2EHSOBE009.bigfish.com (10.9.40.29) with Microsoft SMTP Server id 14.1.225.23; Sat, 16 Jun 2012 19:53:12 +0000 Received: from mail113-tx2 (localhost [127.0.0.1]) by mail113-tx2-R.bigfish.com (Postfix) with ESMTP id 9CF3A3A0340; Sat, 16 Jun 2012 19:53:11 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -29 X-BigFish: VS-29(zzbb2dI9371Ic85eh148cI542M1432Izz1202hzz1033IL8275dhz2fh2a8h668h839hd25hf0ah) Received-SPF: pass (mail113-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC103.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail113-tx2 (localhost.localdomain [127.0.0.1]) by mail113-tx2 (MessageSwitch) id 133987639076698_31363; Sat, 16 Jun 2012 19:53:10 +0000 (UTC) Received: from TX2EHSMHS024.bigfish.com (unknown [10.9.14.235]) by mail113-tx2.bigfish.com (Postfix) with ESMTP id 05719100045; Sat, 16 Jun 2012 19:53:10 +0000 (UTC) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS024.bigfish.com (10.9.99.124) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 16 Jun 2012 19:53:07 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.53]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.02.0309.003; Sat, 16 Jun 2012 19:54:19 +0000 From: Mike Jones To: Eran Hammer , "oauth@ietf.org WG (oauth@ietf.org)" Thread-Topic: [OAUTH-WG] Section 7.2 Thread-Index: AQHNSnlK4rMFHIKNpEG6QNgV8mtEhJb6Y6gAgAABoQCAACqMcIAAXHmAgAJnIXCAAAhDgIAAAv2E Date: Sat, 16 Jun 2012 19:54:18 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366554BAD@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <0CBAEB56DDB3A140BA8E8C124C04ECA201073394@P3PWEX2MB008.ex2.secureserver.net> <4E1F6AAD24975D4BA5B1680429673943665394D7@TK5EX14MBXC284.redmond.corp.microsoft.com> <0CBAEB56DDB3A140BA8E8C124C04ECA2010734C5@P3PWEX2MB008.ex2.secureserver.net> <0CBAEB56DDB3A140BA8E8C124C04ECA201073573@P3PWEX2MB008.ex2.secureserver.net> <4E1F6AAD24975D4BA5B168042967394366539839@TK5EX14MBXC284.redmond.corp.microsoft.com> <0CBAEB56DDB3A140BA8E8C124C04ECA201073B82@P3PWEX2MB008.ex2.secureserver.net> <4E1F6AAD24975D4BA5B168042967394366554B42@TK5EX14MBXC283.redmond.corp.microsoft.com>, <0CBAEB56DDB3A140BA8E8C124C04ECA201075967@P3PWEX2MB008.ex2.secureserver.net> In-Reply-To: <0CBAEB56DDB3A140BA8E8C124C04ECA201075967@P3PWEX2MB008.ex2.secureserver.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394366554BADTK5EX14MBXC283r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [OAUTH-WG] Section 7.2 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jun 2012 19:54:27 -0000 --_000_4E1F6AAD24975D4BA5B168042967394366554BADTK5EX14MBXC283r_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable OK - will do. ________________________________ From: Eran Hammer Sent: 6/16/2012 12:43 PM To: Mike Jones; oauth@ietf.org WG (oauth@ietf.org) Subject: RE: [OAUTH-WG] Section 7.2 I would rather these restrictions be in the error registry section below an= d add a forward reference from 7.2. EH From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Saturday, June 16, 2012 12:17 PM To: Eran Hammer; oauth@ietf.org WG (oauth@ietf.org) Subject: RE: [OAUTH-WG] Section 7.2 While adding the new text into a proposed draft, I realized that no charact= er set restrictions on the error code values were defined in the agreed tex= t. Therefore, I=92ve added the following sentence (which was already prese= nt in -27): Values for these error codes MUST NOT include characters outside the set %x20-21 / %x23-5B / %x5D-7E. This is the same restriction that is referenced every other place that the = =93error=94 parameter is used in the draft. -- Mike From: Eran Hammer [mailto:eran@hueniverse.com] Sent: Thursday, June 14, 2012 11:32 PM To: Mike Jones; oauth@ietf.org WG (oauth@ietf.org) Subject: RE: [OAUTH-WG] Section 7.2 WFM. This will be the new text for 7.2 unless someone has any additional feedbac= k or concerns. This closes my issue with the new error registry changes. EH From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Thursday, June 14, 2012 6:15 PM To: Eran Hammer; oauth@ietf.org WG (oauth@ietf.org) Subject: RE: [OAUTH-WG] Section 7.2 Thanks for writing the text below. It looks fine to me. About adding the = other error parameters as suggestions, that seems like a reasonable thing t= o do. How about the text at the end below, which adds mentions of error_de= scription and error_uri? 7.2. Error Response If a resource access request fails, the resource server SHOULD inform the client of the error. While the specifics of such error responses are beyond the scope of this specification, this documents establishes a common registry for error values to be shared among OAuth token authentication schemes. New authentication schemes designed primarily for OAuth token authentication SHOULD define a mechanism for providing an error status code to the client, in which the error values allowed are registered in the error registry established by this specification. Such schemes MAY limit the set of valid error codes to a subset of the registered values. If the error code is returned using a named parameter= , the parameter name SHOULD be "error". Other schemes capable of being used for OAuth token authentication, but not primarily designed for that purpose, MAY bind their error values to = the registry in the same manner. New authentication schemes MAY choose to also specify the use of the "error_description" and "error_uri" parameters to return error informati= on in a manner parallel to their usage in this specification. -- Mike P.S. If you already have the text you wrote in a copy of the draft, you sh= ould apply these spelling corrections: desgined -> designed authentiction -> authentication -----Original Message----- From: Eran Hammer [mailto:eran@hueniverse.com] Sent: Thursday, June 14, 2012 3:29 PM To: Eran Hammer; Mike Jones; oauth@ietf.org WG (oaut= h@ietf.org) Subject: RE: [OAUTH-WG] Section 7.2 Mike - if you want to add the other error parameters as suggestions, that w= ould be fine by me. EH > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth= -bounces@ietf.org] On Behalf > Of Eran Hammer > Sent: Thursday, June 14, 2012 3:23 PM > To: Mike Jones; oauth@ietf.org WG (oauth@ietf.org<= mailto:oauth@ietf.org>) > Subject: Re: [OAUTH-WG] Section 7.2 > > 7.2. Error Response > > If a resource access request fails, the resource server SHOULD inform > the client of the error. While the specifics of such error responses > are beyond the scope of this specification, this documents establishes > a common registry for error values to be shared among OAuth token > authentication schemes. > > New authentication schemes desgined primarily for OAuth token > authentiction SHOULD define a mechanism for providing an > error status code to the client, in which the error values allowed are > registered in the error registry established by this specification. Su= ch > schemes MAY limit the set of valid error codes to a subset of the > registered values. If the error code is returned using a named paramet= er, > the parameter name SHOULD be "error". > > Other schemes capable of being used for OAuth token authentication, bu= t > not primarily designed for that purpose, MAY bind their error values t= o the > registry in the same manner. > > EH > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --_000_4E1F6AAD24975D4BA5B168042967394366554BADTK5EX14MBXC283r_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
OK - will do.=

From: Eran H= ammer
Sent: 6/16/2= 012 12:43 PM
To: Mike J= ones; oauth@ietf.org WG (oauth@ietf.org)
Subject: RE: [O= AUTH-WG] Section 7.2

I would rather these r= estrictions be in the error registry section below and add a forward refere= nce from 7.2.

 

EH

 

From: Mike J= ones [mailto:Michael.Jones@microsoft.com]
Sent: Saturday, June 16, 2012 12:17 PM
To: Eran Hammer; oauth@ietf.org WG (oauth@ietf.org)
Subject: RE: [OAUTH-WG] Section 7.2

 

While adding the new t= ext into a proposed draft, I realized that no character set restrictions on= the error code values were defined in the agreed text.  Therefore, I= =92ve added the following sentence (which was already present in -27):

   &nbs= p;             Value= s for these error codes MUST NOT include

   &nbs= p;             chara= cters outside the set %x20-21 / %x23-5B / %x5D-7E.

 

This is the same restr= iction that is referenced every other place that the =93error=94 parameter = is used in the draft.

 

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

 

From: Eran H= ammer [mailto:eran@hueniverse.com= ]
Sent: Thursday, June 14, 2012 11:32 PM
To: Mike Jones; oauth@ietf.org= WG (oauth@ietf.org)
Subject: RE: [OAUTH-WG] Section 7.2

 

WFM.

 

This will be the new t= ext for 7.2 unless someone has any additional feedback or concerns.<= /p>

 

This closes my issue w= ith the new error registry changes.

 

EH

 

From: Mike J= ones [mailto:Michael.Jon= es@microsoft.com]
Sent: Thursday, June 14, 2012 6:15 PM
To: Eran Hammer; oauth@ietf.org WG (oauth@ietf.org)
Subject: RE: [OAUTH-WG] Section 7.2

 

Thanks for writing the text below.  It looks= fine to me.  About adding the other error parameters as suggestions, = that seems like a reasonable thing to do.  How about the text at the e= nd below, which adds mentions of error_description and error_uri?

 

7.2.  Error Response

 

   If a resource access request fails, the resource server SHO= ULD inform

   the client of the error.  While the specifics of such = error responses

   are beyond the scope of this specification, this documents = establishes

   a common registry for error values to be shared among OAuth= token

   authentication schemes.

 

   New authentication schemes designed primarily for OAuth tok= en

   authentication SHOULD define a mechanism for providing an

   error status code to the client, in which the error values = allowed are

   registered in the error registry established by this specif= ication. Such

   schemes MAY limit the set of valid error codes to a subset = of the

   registered values. If the error code is returned using a na= med parameter,

   the parameter name SHOULD be "error".

 

   Other schemes capable of being used for OAuth token authent= ication, but

   not primarily designed for that purpose, MAY bind their err= or values to the

   registry in the same manner.

 

   New authentication schemes MAY choose to also specify the u= se of the

   "error_description" and "error_uri" par= ameters to return error information

   in a manner parallel to their usage in this specification.<= /span>

 

 

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

 

P.S.  If you already have the text you wrote= in a copy of the draft, you should apply these spelling corrections:

        &= nbsp;      desgined -> designed

        &= nbsp;      authentiction -> authentication

 

-----Original Message-----
From: Eran Hammer [mailto:e= ran@hueniverse.com]
Sent: Thursday, June 14, 2012 3:29 PM
To: Eran Hammer; Mike Jones; oauth@ietf.o= rg WG (oauth@ietf.org)
Subject: RE: [OAUTH-WG] Section 7.2

 

Mike - if you want to add the other error paramet= ers as suggestions, that would be fine by me.

 

EH

 

> -----Original Message-----

> From: oauth-bounces@ie= tf.org [mailto:oauth-bounces@ietf.org] O= n Behalf

> Of Eran Hammer

> Sent: Thursday, June 14, 2012 3:23 PM

> To: Mike Jones; oauth@ietf.org= WG (oauth@ietf.org)

> Subject: Re: [OAUTH-WG] Section 7.2

>

> 7.2.  Error Response

>

>    If a resource access reque= st fails, the resource server SHOULD inform

>    the client of the error.&n= bsp; While the specifics of such error responses

>    are beyond the scope of th= is specification, this documents establishes

>    a common registry for erro= r values to be shared among OAuth token

>    authentication schemes.

>

>    New authentication schemes= desgined primarily for OAuth token

>    authentiction SHOULD defin= e a mechanism for providing an

>    error status code to the c= lient, in which the error values allowed are

>    registered in the error re= gistry established by this specification. Such

>    schemes MAY limit the set = of valid error codes to a subset of the

>    registered values. If the = error code is returned using a named parameter,

>    the parameter name SHOULD = be "error".

>

>    Other schemes capable of b= eing used for OAuth token authentication, but

>    not primarily designed for= that purpose, MAY bind their error values to the

>    registry in the same manne= r.

>

> EH

>

> ____________________________________________= ___

> OAuth mailing list

> OAuth@ietf.org

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

 

--_000_4E1F6AAD24975D4BA5B168042967394366554BADTK5EX14MBXC283r_-- From hannes.tschofenig@gmx.net Mon Jun 18 05:01:49 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEE7F21F84CF for ; Mon, 18 Jun 2012 05:01:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.491 X-Spam-Level: X-Spam-Status: No, score=-102.491 tagged_above=-999 required=5 tests=[AWL=0.108, 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 zZx2Hc53HZWT for ; Mon, 18 Jun 2012 05:01:48 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 34C8F21F84F0 for ; Mon, 18 Jun 2012 05:01:48 -0700 (PDT) Received: (qmail invoked by alias); 18 Jun 2012 12:01:46 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.101]) [88.115.216.191] by mail.gmx.net (mp002) with SMTP; 18 Jun 2012 14:01:46 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/fHNsPEXDfADAZUU3eZD3zufErFxSv27eziQMsk9 KuJjyQySNJIyGI Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436654F446@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Mon, 18 Jun 2012 15:01:45 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0CBAEB56DDB3A140BA8E8C124C04ECA201073394@P3PWEX2MB008.ex2.secureserver.net> <4E1F6AAD24975D4BA5B1680429673943665394D7@TK5EX14MBXC284.redmond.corp.microsoft.com> <0CBAEB56DDB3A140BA8E8C124C04ECA2010734C5@P3PWEX2MB008.ex2.secureserver.net> <0CBAEB56DDB3A140BA8E8C124C04ECA201073573@P3PWEX2MB008.ex2.secureserver.net> <4E1F6AAD24975D4BA5B168042967394366539839@TK5EX14MBXC284.redmond.corp.microsoft.com> <3929B3F4-D3B3-4CAB-BB22-CFA5BFBBE8E5@gmx.net> <4E1F6AAD24975D4BA5B16804296739436654F446@TK5EX14MBXC283.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: "oauth@ietf.org WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Section 7.2 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2012 12:01:49 -0000 Hi Mike,=20 this text below does not prohibit error information to be sent back to = the client (otherwise there would be a MUST NOT).=20 So, if a developer reads this below then when should he send an error = response and when not?=20 Ciao Hannes PS: (I also believe that the "i.e." should rather be a "e.g." in the = text below.) On Jun 15, 2012, at 10:06 PM, Mike Jones wrote: > There are cases where the OAuth specs specifically *prohibit* = returning an error code or other error information, for security = reasons. For instance, = http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-20#section-3.1 = contains the language: >=20 > If the request lacks any authentication information (i.e. the client > was unaware authentication is necessary or attempted using an > unsupported authentication method), the resource server SHOULD NOT > include an error code or other error information. >=20 > Hence, the SHOULDs, rather than MUSTs. >=20 > -- Mike >=20 > -----Original Message----- > From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net]=20 > Sent: Friday, June 15, 2012 11:28 AM > To: Mike Jones > Cc: Hannes Tschofenig; Eran Hammer; oauth@ietf.org WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Section 7.2 >=20 > Hi Mike,=20 >=20 > I personally would find it better to have fewer SHOULDs. Most of them = have been there for a long time and so it is a bit late to complain but = the challenge for protocol architectures is to figure out under what = conditions they should do certain things.=20 >=20 > Additionally, I don't buy the argument that a server should not = provide error responses (or to be only very brief, or even misleading) = for a security point of view because attackers typically know more than = ordinary developers or users and so you end up with a system that the = normal user is unable to work with (in a failure case) but adversaries = nevertheless get what they want. This comment relates to the first = sentence that gives me the impression that the server may not send any = error message in case of a failure, which sounds strange to me.=20 >=20 > Ciao > Hannes >=20 > On Jun 15, 2012, at 4:15 AM, Mike Jones wrote: >=20 >> Thanks for writing the text below. It looks fine to me. About = adding the other error parameters as suggestions, that seems like a = reasonable thing to do. How about the text at the end below, which adds = mentions of error_description and error_uri? >>=20 >> 7.2. Error Response >>=20 >> If a resource access request fails, the resource server SHOULD = inform >> the client of the error. While the specifics of such error = responses >> are beyond the scope of this specification, this documents = establishes >> a common registry for error values to be shared among OAuth token >> authentication schemes. >>=20 >> New authentication schemes designed primarily for OAuth token >> authentication SHOULD define a mechanism for providing an >> error status code to the client, in which the error values allowed = are >> registered in the error registry established by this specification. = Such >> schemes MAY limit the set of valid error codes to a subset of the >> registered values. If the error code is returned using a named = parameter, >> the parameter name SHOULD be "error". >>=20 >> Other schemes capable of being used for OAuth token authentication, = but >> not primarily designed for that purpose, MAY bind their error = values to the >> registry in the same manner. >>=20 >> New authentication schemes MAY choose to also specify the use of = the >> "error_description" and "error_uri" parameters to return error = information >> in a manner parallel to their usage in this specification. >>=20 >>=20 >> -- Mike >>=20 >> P.S. If you already have the text you wrote in a copy of the draft, = you should apply these spelling corrections: >> desgined -> designed >> authentiction -> authentication >>=20 >> -----Original Message----- >> From: Eran Hammer [mailto:eran@hueniverse.com] >> Sent: Thursday, June 14, 2012 3:29 PM >> To: Eran Hammer; Mike Jones; oauth@ietf.org WG (oauth@ietf.org) >> Subject: RE: [OAUTH-WG] Section 7.2 >>=20 >> Mike - if you want to add the other error parameters as suggestions, = that would be fine by me. >>=20 >> EH >>=20 >>> -----Original Message----- >>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On=20 >>> Behalf Of Eran Hammer >>> Sent: Thursday, June 14, 2012 3:23 PM >>> To: Mike Jones; oauth@ietf.org WG (oauth@ietf.org) >>> Subject: Re: [OAUTH-WG] Section 7.2 >>>=20 >>> 7.2. Error Response >>>=20 >>> If a resource access request fails, the resource server SHOULD = inform >>> the client of the error. While the specifics of such error = responses >>> are beyond the scope of this specification, this documents = establishes >>> a common registry for error values to be shared among OAuth token >>> authentication schemes. >>>=20 >>> New authentication schemes desgined primarily for OAuth token >>> authentiction SHOULD define a mechanism for providing an >>> error status code to the client, in which the error values allowed = are >>> registered in the error registry established by this = specification. Such >>> schemes MAY limit the set of valid error codes to a subset of the >>> registered values. If the error code is returned using a named = parameter, >>> the parameter name SHOULD be "error". >>>=20 >>> Other schemes capable of being used for OAuth token = authentication, but >>> not primarily designed for that purpose, MAY bind their error = values to the >>> registry in the same manner. >>>=20 >>> EH >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 From eran@hueniverse.com Mon Jun 18 10:13:50 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6501121F86F2 for ; Mon, 18 Jun 2012 10:13:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LFybo2+uyoB0 for ; Mon, 18 Jun 2012 10:13:49 -0700 (PDT) Received: from p3plex2out01.prod.phx3.secureserver.net (p3plex2out01.prod.phx3.secureserver.net [184.168.131.12]) by ietfa.amsl.com (Postfix) with ESMTP id 890C721F86F1 for ; Mon, 18 Jun 2012 10:13:49 -0700 (PDT) Received: from P3PWEX2HT003.ex2.secureserver.net ([184.168.131.11]) by p3plex2out01.prod.phx3.secureserver.net with bizsmtp id PtDp1j0010EuLVk01tDpJk; Mon, 18 Jun 2012 10:13:49 -0700 Received: from P3PWEX2MB008.ex2.secureserver.net ([169.254.8.66]) by P3PWEX2HT003.ex2.secureserver.net ([184.168.131.11]) with mapi id 14.02.0247.003; Mon, 18 Jun 2012 10:13:48 -0700 From: Eran Hammer To: Hannes Tschofenig , Mike Jones Thread-Topic: [OAUTH-WG] Section 7.2 Thread-Index: Ac1KeB4PVUuFMDsJRu+q5d/rw0G4WQAO9iAAAA6cN3AAHFVLIP/+3oCAgAT2VMD//6kPAA== Date: Mon, 18 Jun 2012 17:13:47 +0000 Message-ID: <0CBAEB56DDB3A140BA8E8C124C04ECA201077203@P3PWEX2MB008.ex2.secureserver.net> References: <0CBAEB56DDB3A140BA8E8C124C04ECA201073394@P3PWEX2MB008.ex2.secureserver.net> <4E1F6AAD24975D4BA5B1680429673943665394D7@TK5EX14MBXC284.redmond.corp.microsoft.com> <0CBAEB56DDB3A140BA8E8C124C04ECA2010734C5@P3PWEX2MB008.ex2.secureserver.net> <0CBAEB56DDB3A140BA8E8C124C04ECA201073573@P3PWEX2MB008.ex2.secureserver.net> <4E1F6AAD24975D4BA5B168042967394366539839@TK5EX14MBXC284.redmond.corp.microsoft.com> <3929B3F4-D3B3-4CAB-BB22-CFA5BFBBE8E5@gmx.net> <4E1F6AAD24975D4BA5B16804296739436654F446@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [80.36.76.35] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Section 7.2 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2012 17:13:50 -0000 Same as any SHOULD. Do it unless you have a good reason not to. We have ple= nty of other SHOULDs without any detailed explanation of the qualifications= . EH > -----Original Message----- > From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net] > Sent: Monday, June 18, 2012 5:02 AM > To: Mike Jones > Cc: Hannes Tschofenig; Eran Hammer; oauth@ietf.org WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Section 7.2 >=20 > Hi Mike, >=20 > this text below does not prohibit error information to be sent back to th= e > client (otherwise there would be a MUST NOT). >=20 > So, if a developer reads this below then when should he send an error > response and when not? >=20 > Ciao > Hannes >=20 > PS: (I also believe that the "i.e." should rather be a "e.g." in the text= below.) >=20 > On Jun 15, 2012, at 10:06 PM, Mike Jones wrote: >=20 > > There are cases where the OAuth specs specifically *prohibit* returning= an > error code or other error information, for security reasons. For instanc= e, > http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-20#section-3.1 > contains the language: > > > > If the request lacks any authentication information (i.e. the client > > was unaware authentication is necessary or attempted using an > > unsupported authentication method), the resource server SHOULD NOT > > include an error code or other error information. > > > > Hence, the SHOULDs, rather than MUSTs. > > > > -- Mike > > > > -----Original Message----- > > From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net] > > Sent: Friday, June 15, 2012 11:28 AM > > To: Mike Jones > > Cc: Hannes Tschofenig; Eran Hammer; oauth@ietf.org WG > (oauth@ietf.org) > > Subject: Re: [OAUTH-WG] Section 7.2 > > > > Hi Mike, > > > > I personally would find it better to have fewer SHOULDs. Most of them > have been there for a long time and so it is a bit late to complain but t= he > challenge for protocol architectures is to figure out under what conditio= ns > they should do certain things. >=20 > > > > Additionally, I don't buy the argument that a server should not provide > error responses (or to be only very brief, or even misleading) for a secu= rity > point of view because attackers typically know more than ordinary > developers or users and so you end up with a system that the normal user = is > unable to work with (in a failure case) but adversaries nevertheless get = what > they want. This comment relates to the first sentence that gives me the > impression that the server may not send any error message in case of a > failure, which sounds strange to me. > > > > Ciao > > Hannes > > > > On Jun 15, 2012, at 4:15 AM, Mike Jones wrote: > > > >> Thanks for writing the text below. It looks fine to me. About adding= the > other error parameters as suggestions, that seems like a reasonable thing= to > do. How about the text at the end below, which adds mentions of > error_description and error_uri? > >> > >> 7.2. Error Response > >> > >> If a resource access request fails, the resource server SHOULD infor= m > >> the client of the error. While the specifics of such error response= s > >> are beyond the scope of this specification, this documents establish= es > >> a common registry for error values to be shared among OAuth token > >> authentication schemes. > >> > >> New authentication schemes designed primarily for OAuth token > >> authentication SHOULD define a mechanism for providing an > >> error status code to the client, in which the error values allowed a= re > >> registered in the error registry established by this specification. = Such > >> schemes MAY limit the set of valid error codes to a subset of the > >> registered values. If the error code is returned using a named param= eter, > >> the parameter name SHOULD be "error". > >> > >> Other schemes capable of being used for OAuth token authentication, > but > >> not primarily designed for that purpose, MAY bind their error values= to > the > >> registry in the same manner. > >> > >> New authentication schemes MAY choose to also specify the use of the > >> "error_description" and "error_uri" parameters to return error > information > >> in a manner parallel to their usage in this specification. > >> > >> > >> -- Mike > >> > >> P.S. If you already have the text you wrote in a copy of the draft, y= ou > should apply these spelling corrections: > >> desgined -> designed > >> authentiction -> authentication > >> > >> -----Original Message----- > >> From: Eran Hammer [mailto:eran@hueniverse.com] > >> Sent: Thursday, June 14, 2012 3:29 PM > >> To: Eran Hammer; Mike Jones; oauth@ietf.org WG (oauth@ietf.org) > >> Subject: RE: [OAUTH-WG] Section 7.2 > >> > >> Mike - if you want to add the other error parameters as suggestions, t= hat > would be fine by me. > >> > >> EH > >> > >>> -----Original Message----- > >>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > >>> Behalf Of Eran Hammer > >>> Sent: Thursday, June 14, 2012 3:23 PM > >>> To: Mike Jones; oauth@ietf.org WG (oauth@ietf.org) > >>> Subject: Re: [OAUTH-WG] Section 7.2 > >>> > >>> 7.2. Error Response > >>> > >>> If a resource access request fails, the resource server SHOULD info= rm > >>> the client of the error. While the specifics of such error respons= es > >>> are beyond the scope of this specification, this documents establis= hes > >>> a common registry for error values to be shared among OAuth token > >>> authentication schemes. > >>> > >>> New authentication schemes desgined primarily for OAuth token > >>> authentiction SHOULD define a mechanism for providing an > >>> error status code to the client, in which the error values allowed = are > >>> registered in the error registry established by this specification.= Such > >>> schemes MAY limit the set of valid error codes to a subset of the > >>> registered values. If the error code is returned using a named > parameter, > >>> the parameter name SHOULD be "error". > >>> > >>> Other schemes capable of being used for OAuth token authentication, > but > >>> not primarily designed for that purpose, MAY bind their error value= s to > the > >>> registry in the same manner. > >>> > >>> EH > >>> > >>> _______________________________________________ > >>> OAuth mailing list > >>> OAuth@ietf.org > >>> https://www.ietf.org/mailman/listinfo/oauth > >> > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > > > > > > From Michael.Jones@microsoft.com Mon Jun 18 11:08:24 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 243EB21F86DE for ; Mon, 18 Jun 2012 11:08:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.849 X-Spam-Level: X-Spam-Status: No, score=-3.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IiMPQbk23b0l for ; Mon, 18 Jun 2012 11:08:23 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe003.messaging.microsoft.com [216.32.181.183]) by ietfa.amsl.com (Postfix) with ESMTP id 3193C21F86D9 for ; Mon, 18 Jun 2012 11:08:22 -0700 (PDT) Received: from mail80-ch1-R.bigfish.com (10.43.68.243) by CH1EHSOBE015.bigfish.com (10.43.70.65) with Microsoft SMTP Server id 14.1.225.23; Mon, 18 Jun 2012 18:07:03 +0000 Received: from mail80-ch1 (localhost [127.0.0.1]) by mail80-ch1-R.bigfish.com (Postfix) with ESMTP id 73B92E0138; Mon, 18 Jun 2012 18:07:03 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -28 X-BigFish: VS-28(zz9371I1454I542M111aIzz1202hzz1033IL8275dhz2fh2a8h668h839h93fhd25hf0ah) Received-SPF: pass (mail80-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail80-ch1 (localhost.localdomain [127.0.0.1]) by mail80-ch1 (MessageSwitch) id 1340042821480392_27669; Mon, 18 Jun 2012 18:07:01 +0000 (UTC) Received: from CH1EHSMHS002.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.240]) by mail80-ch1.bigfish.com (Postfix) with ESMTP id 71AE62A004A; Mon, 18 Jun 2012 18:07:01 +0000 (UTC) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS002.bigfish.com (10.43.70.2) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 18 Jun 2012 18:06:59 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.53]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.02.0298.005; Mon, 18 Jun 2012 18:08:17 +0000 From: Mike Jones To: Stephen Farrell Thread-Topic: Pete Resnick's Discuss on draft-ietf-oauth-v2-bearer-20: (with DISCUSS and COMMENT) Thread-Index: Ac1NfVJ2/vngAAOnQsWKq1/c+fOMkQ== Date: Mon, 18 Jun 2012 18:08:16 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366558C4C@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.70] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: Pete Resnick , Mark Nottingham , "oauth@ietf.org" Subject: [OAUTH-WG] FW: Pete Resnick's Discuss on draft-ietf-oauth-v2-bearer-20: (with DISCUSS and 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: Mon, 18 Jun 2012 18:08:24 -0000 SGkgU3RlcGhlbiwNCg0KUGV0ZSBpcyBob2xkaW5nIGhpcyBESVNDVVNTIG9uIEJlYXJlciBvcGVu IHVudGlsIHRoZSBjdXJyZW50IHRleHQgb24gdGhlIFVSSSBxdWVyeSBwYXJhbWV0ZXIgaHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC12Mi1iZWFyZXItMjAjc2VjdGlv bi0yLjMgcmVjZWl2ZXMgVzNDIHJldmlldy4gIENhbiB5b3UgdHJ5IHRvIGhhdmUgdGhhdCByZXZp ZXcgaGFwcGVuIHRoaXMgd2VlaywgaG9wZWZ1bGx5IGZpbmlzaGluZyBzb21ldGltZSBuZXh0IHdl ZWs/DQoNCkknbSBjYzonaW5nIE1hcmsgaW4gaGlzIHJvbGUgYXMgVzNDIGxpYWlzb24uDQoNCgkJ CQlUaGFua3MgYWdhaW4sDQoJCQkJLS0gTWlrZQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KRnJvbTogUGV0ZSBSZXNuaWNrIFttYWlsdG86cHJlc25pY2tAcXVhbGNvbW0uY29tXSANClNl bnQ6IFR1ZXNkYXksIEp1bmUgMTIsIDIwMTIgMTo0MCBQTQ0KVG86IFRoZSBJRVNHDQpDYzogb2F1 dGgtY2hhaXJzQHRvb2xzLmlldGYub3JnOyBkcmFmdC1pZXRmLW9hdXRoLXYyLWJlYXJlckB0b29s cy5pZXRmLm9yZw0KU3ViamVjdDogUGV0ZSBSZXNuaWNrJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRm LW9hdXRoLXYyLWJlYXJlci0yMDogKHdpdGggRElTQ1VTUyBhbmQgQ09NTUVOVCkNCg0KUGV0ZSBS ZXNuaWNrIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KZHJh ZnQtaWV0Zi1vYXV0aC12Mi1iZWFyZXItMjA6IERpc2N1c3MNCg0KV2hlbiByZXNwb25kaW5nLCBw bGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsIGVtYWls IGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRv IGN1dCB0aGlzIGludHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KDQoNClBsZWFzZSBy ZWZlciB0byBodHRwOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVy aWEuaHRtbA0KZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01N RU5UIHBvc2l0aW9ucy4NCg0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KRElTQ1VTUzoNCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCg0KTWFyayBOb3R0aW5naGFtJ3MgQXBwbGljYXRpb25zIEFyZWEgcmV2aWV3IDxodHRw Oi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvYXBwcy1kaXNjdXNzL2N1cnJlbnQvbXNn MDM4MDUuaHRtbD4NCmlkZW50aWZpZWQgdGhlIGlzc3VlIG9mIFVSSSBxdWVyeSBwYXJhbWV0ZXJz IGluIHNlY3Rpb24gMi4zOiBVUkkgcXVlcnkgcGFyYW1ldGVycyBhcmUgbm9ybWFsbHkgbG9jYWxs eSBzY29wZWQuIEluIHRoaXMgZG9jdW1lbnQsIGEgcXVlcnkgcGFyYW1ldGVyIChhY2Nlc3NfdG9r ZW4pIGlzIGJlaW5nIGRlZmluZWQgYXMgYXBwbHlpbmcgdG8gYWxsIFVSSXMuIFRoaXMgaXMgKHJl bGF0aXZlbHkpIG5vdmVsLiBBIGZldyBwZW9wbGUgaW4gdGhlIEhUVFAgY29tbXVuaXR5IChpbmNs dWRpbmcNCk1hcmspIGhhdmUgZXhwcmVzc2VkIGNvbmNlcm5zLiAoU2VlIGFsc28gaHR0cDovL3d3 dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2FwcHMtZGlzY3Vzcy9jdXJyZW50L21zZzA0OTMy Lmh0bWwNCmFuZA0KaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2FwcHMtZGlz Y3Vzcy9jdXJyZW50L21zZzA0OTMzLmh0bWwNCmZyb20gdGhlIGFwcHMtZGlzY3VzcyBhcmNoaXZl LikgVGhpcyBpc3N1ZSBzaG91bGQgcHJvYmFibHkgYmUgZnVydGhlciByZXZpZXdlZCBieSBXM0Mg Zm9sa3MuIEknbSBob2xkaW5nIHRoZSBESVNDVVNTIGFzIHBlciBTdGVwaGVuIHRvIG1ha2Ugc3Vy ZSB3ZSBnZXQgdGhhdCByZXZpZXcuDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KQ09NTUVOVDoNCi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCg0KSW4gc2VjdGlvbiAyLjMsIHRoZSBuZXcgbGFzdCBwYXJhZ3JhcGggc3RhcnRz Og0KDQogICAgVGhpcyBtZXRob2QgaXMgaW5jbHVkZWQgdG8gZG9jdW1lbnQgY3VycmVudCB1c2U7 IGl0cyB1c2UgaXMgTk9UDQogICAgUkVDT01NRU5ERUQuLi4NCg0KTk9UIFJFQ09NTUVOREVEIGlz IG5vdCBkZWZpbmVkIGJ5IDIxMTksIGFuZCB0aGUgbGFuZ3VhZ2UgaXMgcmVkdW5kYW50IHdpdGgg dGhlIHByZXZpb3VzIHBhcmFncmFwaCBhbmQgcG90ZW50aWFsbHkgY29uZnVzaW5nLiBJIHN1Z2dl c3QgcmVwbGFjaW5nIGl0IHdpdGggc2ltcGx5Og0KDQogICAgVGhpcyBtZXRob2QgaXMgaW5jbHVk ZWQgdG8gZG9jdW1lbnQgY3VycmVudCB1c2U7IGFzIGluZGljYXRlZA0KICAgIGluIHRoZSBwcmV2 aW91cyBwYXJhZ3JhcGgsIHRoZSB1c2Ugb2YgdGhpcyBtZXRob2QgaXMgbm90DQogICAgcmVjb21t ZW5kZWQuLi4NCg0KQlRXOiBUaGUgIlNIT1VMRCBOT1QgdW5sZXNzLi4uIiBpbiB0aGUgcHJldmlv dXMgcGFyYWdyYXBoIGlzIGl0c2VsZiByZWR1bmRhbnQuIEkgdGhpbmsgeW91IG1lYW4gIk1VU1Qg Tk9UIHVubGVzcy4uLiIuIFNIT1VMRCBOT1QgKm1lYW5zKiBNVVNUIE5PVCB1bmxlc3MgeW91IHVu ZGVyc3RhbmQgd2hhdCB5b3UncmUgZG9pbmcuDQoNCk1hcmsgTm90dGluZ2hhbSdzIEFwcGxpY2F0 aW9ucyBBcmVhIHJldmlldyA8aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2Fw cHMtZGlzY3Vzcy9jdXJyZW50L21zZzAzODA1Lmh0bWw+DQpoYXMgYSBjb3VwbGUgb2YgY29tbWVu dHMgdGhhdCBJIHRoaW5rIGRlc2VydmUgZnVydGhlciByZXBseToNCg0KCSogU2VjdGlvbiAxOiBJ bnRyb2R1Y3Rpb24NCg0KCVRoZSBpbnRyb2R1Y3Rpb24gZXhwbGFpbnMgb2F1dGgsIGJ1dCBpdCBk b2Vzbid0IGZ1bGx5IGV4cGxhaW4gdGhlDQoJcmVsYXRpb25zaGlwIG9mIHRoaXMgc3BlY2lmaWNh dGlvbiB0byBPQXV0aCAyLjAuIEUuZy4sIGNhbiBpdCBiZQ0KCXVzZWQgaW5kZXBlbmRlbnRseSBm cm9tIHRoZSByZXN0IG9mIE9BdXRoPyBMaWtld2lzZSwgdGhlIG92ZXJ2aWV3DQoJKHNlY3Rpb24g MS4zKSBzZWVtcyBtb3JlIHNwZWNpZmljIHRvIHRoZSBPQXV0aCBzcGVjaWZpY2F0aW9uIHRoYW4N Cgl0aGlzIGRvY3VtZW50LiBBcyBJIHJlYWQgaXQsIHRoaXMgbWVjaGFuaXNtIGNvdWxkIGJlIHVz ZWQgZm9yIEFOWQ0KCWJlYXJlciB0b2tlbiwgbm90IGp1c3Qgb25lIGdlbmVyYXRlZCB0aHJvdWdo IE9BdXRoIGZsb3dzLg0KDQoJSWYgaXQgaXMgaW5kZWVkIG1vcmUgZ2VuZXJhbCwgSSdkIHJlY29t bWVuZCBtaW5pbWlzaW5nIHRoZQ0KCWRpc2N1c3Npb24gb2YgT0F1dGgsIHBlcmhhcHMgZXZlbiBy ZW1vdmluZyBpdCBmcm9tIHRoZSBkb2N1bWVudA0KCXRpdGxlLg0KDQpJIGFncmVlIHRoYXQgdGhl IHRpdGxlIHdvdWxkIGJlIGJldHRlciBzaW1wbHkgYXMgIkhUVFAgQmVhcmVyIFRva2VucyIsIGFu ZCB0aGVuIGV4cGxhaW4gaW4gdGhlIEFic3RyYWN0IGFuZCBJbnRybyB0aGF0IHRoZSBtb3RpdmF0 aW9uIGFuZCBpbnRlbmRlZCB1c2Ugb2YgdGhlc2UgQmVhcmVyIFRva2VucyBpcyB0aGUgT0F1dGgg Mi4wIHNwZWNpZmljYXRpb24uIEEgcG9zc2libHkgdXNlZnVsIHNpZGUgZWZmZWN0IG9mIHRoaXMg Y2hhbmdlIG1pZ2h0IGJlIHRoYXQgeW91IGNhbiBtYWtlIE9BdXRoIDIuMCBhbiBpbmZvcm1hdGl2 ZSAoYXMgYWdhaW5zdCBhIG5vcm1hdGl2ZSkgcmVmZXJlbmNlLCBhbmQgdGhhdCB0aGVzZSB0aGlu Z3MgY291bGQgYmUgcmV1c2VkIGZvciBvdGhlciBwdXJwb3NlcyBpbiB0aGUgZnV0dXJlLiBOb3Qg YSBodWdlIGRlYWwsIGJ1dCBJIChsaWtlIE1hcmspIHdhcyB1bmNvbnZpbmNlZCB0aGF0IHRoZSBy ZWZlcmVuY2UgdG8gT0F1dGggaW4gdGhlIHRpdGxlIHdhcyBuZWNlc3NhcnkuDQoNCgkqIFNlY3Rp b24gMyBUaGUgV1dXLUF1dGhlbnRpY2F0ZSBSZXNwb25zZSBIZWFkZXIgRmllbGQNCg0KCVRoZSBk aWZmZXJlbmNlIGJldHdlZW4gYSByZWFsbSBhbmQgYSBzY29wZSBpcyBub3QgZXhwbGFpbmVkLiBB cmUgdGhlDQoJZnVuY3Rpb25hbGx5IGVxdWl2YWxlbnQsIGp1c3QgYSBzaW5nbGUgdmFsdWUgdnMu IGEgbGlzdD8NCg0KU29tZSB0ZXh0LCBhbmQgcHJvYmFibHkgYW4gZXhhbXBsZSwgbWlnaHQgaGVs cCBleHBsYWluIHRoaXMgYSBiaXQgYmV0dGVyLg0KDQpPbmUgb2YgaGlzIGNvbW1lbnRzIGFza2Vk IGZvciBzb21lIGFkZGl0aW9uYWwgcmV2aWV3LiBJIGRvbid0IGhhdmUgYSBwZXJzb25hbCBvcGlu aW9uIHdoZXRoZXIgdGhpcyBpcyBuZWVkZWQsIGJ1dCBwZXJoYXBzIHlvdSBzaG91bGQgcHVyc3Vl DQp0aGlzOg0KDQoJKiBHZW5lcmFsDQoNCglUaGUgZHJhZnQgY3VycmVudGx5IGRvZXNuJ3QgbWVu dGlvbiB3aGV0aGVyIEJlYXJlciBpcyBzdWl0YWJsZSBmb3INCgl1c2UgYXMgYSBwcm94eSBhdXRo ZW50aWNhdGlvbiBzY2hlbWUuIEkgc3VzcGVjdCBpdCAqbWF5KjsgaXQgd291bGQNCgliZSB3b3J0 aCBkaXNjdXNzaW5nIHRoaXMgd2l0aCBzb21lIHByb3h5IGltcGxlbWVudGVycyB0byBnYXVnZSB0 aGVpcg0KCWludGVyZXN0IChlLmcuLCBTcXVpZCkuDQoNCg0KDQo= From martin.dessureault@unboundid.com Mon Jun 18 11:29:48 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E9D321F8582 for ; Mon, 18 Jun 2012 11:29:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6BW9J0m+v78M for ; Mon, 18 Jun 2012 11:29:47 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 79B8521F8559 for ; Mon, 18 Jun 2012 11:29:47 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so8758678obb.31 for ; Mon, 18 Jun 2012 11:29:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:x-gm-message-state; bh=GNOhiIVCyW2TJ0Bq5sdK2Eu0ZFoBT8cThGJLyFUxn7Y=; b=RUhlAuFkLdqPLpLPf1SES0b510p1K6CrY3uS5gVZ+2PcNzuRLmFiFbRTWbsGNTPhh4 BenZ52zxWnTYOGoMc90yBsX9QgPo0Jkpq6YjgT2rPquOGoZOHnd7K5xVvqsFNPRx8cCy 1ta2gIMJKSzeJHZtGXz6bTWxxxRJJqhUmad5e7l3L+EhzCTqGqpLV1P2JWZKSJ/c5lOA VT7x/9TU0mhN6ukrVyi982EdwjcgQqdc9ma/6+q9BPazNAelnDR473xseO7uGhErXcx3 WPlj5IoT/DWG0bWnCKgN+8eYgD85VIglDYgKFh2TrjPg6QxD41EvOvlsIQZX9409u67t olBQ== Received: by 10.60.10.99 with SMTP id h3mr16569972oeb.72.1340044187068; Mon, 18 Jun 2012 11:29:47 -0700 (PDT) Received: from [10.8.1.216] (24-155-184-100.static.grandenetworks.net. [24.155.184.100]) by mx.google.com with ESMTPS id kt5sm15612841obb.21.2012.06.18.11.29.45 (version=SSLv3 cipher=OTHER); Mon, 18 Jun 2012 11:29:46 -0700 (PDT) Message-ID: <4FDF7399.2040706@unboundid.com> Date: Mon, 18 Jun 2012 13:29:45 -0500 From: Martin Dessureault Organization: UnboundID Corp User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: oauth@ietf.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080605000003050803030403" X-Gm-Message-State: ALoCoQmE0N9LwlVvF3fLMwg3TciJl1fJguZi4osJdPV93SoPzJmfnvqPO1+ikojlugD5a7GTINwy Subject: [OAUTH-WG] Section 11.2.2. Initial Registry Contents X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 18:31:12 -0000 This is a cryptographically signed message in MIME format. --------------ms080605000003050803030403 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable This section doesn't mention the 'error' parameter. Since it mentions=20 the error_uri and error_description parameters, it seems to just have=20 been omitted/forgotten. --------------ms080605000003050803030403 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMWDCC BWIwggRKoAMCAQICEF2HVZeDrp0iVcj0k4gRvk0wDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlz aWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAe Fw0xMjA0MTAwMDAwMDBaFw0xMzA0MTAyMzU5NTlaMIIBJTEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52 ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMp OTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJ RCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRswGQYDVQQDFBJNYXJ0aW4gRGVz c3VyZWF1bHQxLzAtBgkqhkiG9w0BCQEWIG1hcnRpbi5kZXNzdXJlYXVsdEB1bmJvdW5kaWQu Y29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyblB6kBolV47dVSGRN2dUQXs few7XuzY6EFLWp3au3fc1Byre4mq+2jBkQRgrh2J8TYR2kwSjm90Q8TgenTQORlslCUejcOv 5rMlrWz1p/wwrCA/iVTeY71/sp3eOlxuxds1rSWCJW3CfwhDNqatzNu4FOwKkX+Zqs9Pfs7f zi/PI0Ll1gkzRYVpd2sm4AOGLuCUej5iNW/60ZE6R+MPRAxY0QC6ULEW0t16uc/rkT6UE+04 qtXPfxsIcuX8Up7lcZ23VeOHvjTnO7i4ke6Y0T+ard4YGvz3vHITUJh8UJS623wU6Jgh4HuV PXrJhAC3SrtCacy+iU7dT3JQ7Lg6YQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0w OzA5BgtghkgBhvhFAQcXATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5j b20vcnBhMAsGA1UdDwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYD VR0fBEkwRzBFoEOgQYY/aHR0cDovL2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5j b20vSW5kQzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAJQAvZimBZYC95 GeXMtaOSi2/KtKMVaS5Q4K/0NxM77HhGk2WigJJSDlvSY08MSGok4fpouAaX0LJrsur2y6E4 Kpw8m740XbJ5Hw5uPkfOKOmDIyARMXpIbayjEols6fLcynEQNSBfT5p+UuJmBix7cIKSnGWP AoMzyKjpQd4+TOmIGG9TsgR66KeRY/1MScCz1JjwlViR6YE4BCR4wZiFt/yv/V74pGt0j4p2 2kyznx2PgBr39ctLgjvey7aKhwQhnGeCXMXWB1/rRNw1trwTTNvlPvYI/M1HGEC461J7oYX1 XaTHE+rLcATiYUpn81XN987GhDYEt6r7pintyXNgMIIG7jCCBdagAwIBAgIQcRVmBUrkkSFN 6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEo YykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYD VQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0 aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNp Z24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYD VQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU40 99oL42r6ZYggCxET6ZvgSU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54U GAdPWr2f0jGyVBlzRmoZQhHsEnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50 ABMN0Ibak2f4MwOuGjxraXj2wCyO4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3 r2yxBF6+wbaULZeQLSfSux7pg2qE9sSyriMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6 JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUF BzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0TAQH/BAgwBgEB/wIBADBwBgNV HSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlz aWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3Jw YTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLWczLmNy bDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1hZ2UvZ2lm MCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28udmVy aXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRl TGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYDVR0j BIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4x HzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZl cmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlT aWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBH M4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5 hIls5DSoWufYbAlMJBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pU WkO/N4t6jhmND0OojPKvYLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4S cAjr+zvid+zoK2Q1ds262uDRyxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/ XLJtSd5lUkL7DojS7Uodv0vj+Mxy+kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV 7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/wYIxggTsMIIE6AIBATCB8jCB3TELMAkGA1UEBhMC VVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24u Y29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQD Ey5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBdh1WX g66dIlXI9JOIEb5NMAkGBSsOAwIaBQCgggLOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTEyMDYxODE4Mjk0NVowIwYJKoZIhvcNAQkEMRYEFLQsQZST41Ky IjsBwyHrv1KT3TQkMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIB KDCCAQMGCSsGAQQBgjcQBDGB9TCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJU ZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAx IEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBdh1WXg66dIlXI9JOIEb5NMIIBBQYL KoZIhvcNAQkQAgsxgfWggfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMg b2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsT FVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRp dmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQXYdVl4OunSJVyPSTiBG+TTANBgkqhkiG9w0B AQEFAASCAQAX4BZVXtzdxhvi8RqmxJTPVboqlL7l91NGS4ZCZNaR8/SuyFwcOfYwIImQj+VB HHwiFsMmQEPtbwo1aKCTPxthX98V6GDfnimWaruUjzF100nqAbjA/76exXxP3sM3kEGspLKV EV4J+N40xw0J5N9wBbNEEL7squ1FPEmYHibhNkGd9c9WS8+co/QxgPBpZRTAhe3vViWP7Xmr t+qDt7kB6MPy/t+n3oEU39esnXvYmigtTbm9QeBUU89N3NqvxfOhIBWWE7T4cozcNa5tm+/6 rtEME2uvV/oi39uIaWLfn8YVvlcJoCWyFGkMTV32kUhltM2UgMv8HE3UCPe6ZK5SAAAAAAAA --------------ms080605000003050803030403-- From Michael.Jones@microsoft.com Mon Jun 18 12:32:47 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68CD911E8089 for ; Mon, 18 Jun 2012 12:32:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.839 X-Spam-Level: X-Spam-Status: No, score=-3.839 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xr0DnkJ2H4BR for ; Mon, 18 Jun 2012 12:32:46 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe004.messaging.microsoft.com [213.199.154.207]) by ietfa.amsl.com (Postfix) with ESMTP id 319CF21F86B8 for ; Mon, 18 Jun 2012 12:32:46 -0700 (PDT) Received: from mail92-am1-R.bigfish.com (10.3.201.225) by AM1EHSOBE006.bigfish.com (10.3.204.26) with Microsoft SMTP Server id 14.1.225.23; Mon, 18 Jun 2012 19:31:26 +0000 Received: from mail92-am1 (localhost [127.0.0.1]) by mail92-am1-R.bigfish.com (Postfix) with ESMTP id D2D061C0378; Mon, 18 Jun 2012 19:31:25 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -31 X-BigFish: VS-31(zz9371I1b0bM542Mzz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25hf0ah) Received-SPF: pass (mail92-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC107.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail92-am1 (localhost.localdomain [127.0.0.1]) by mail92-am1 (MessageSwitch) id 1340047883116910_29502; Mon, 18 Jun 2012 19:31:23 +0000 (UTC) Received: from AM1EHSMHS010.bigfish.com (unknown [10.3.201.243]) by mail92-am1.bigfish.com (Postfix) with ESMTP id 1A54B220047; Mon, 18 Jun 2012 19:31:23 +0000 (UTC) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS010.bigfish.com (10.3.207.110) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 18 Jun 2012 19:31:22 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.53]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.02.0309.003; Mon, 18 Jun 2012 19:32:37 +0000 From: Mike Jones To: Stephen Farrell Thread-Topic: [W3C Web Crypto WG - Information] IETF seeking review on oauth-v2-bearer draft specification Thread-Index: Ac1NiRcSEeOui+ZrRSGN5WY6EED9BQ== Date: Mon, 18 Jun 2012 19:32:35 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436655A051@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.70] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: Pete Resnick , Mark Nottingham , "oauth@ietf.org" , Thomas Roessler Subject: [OAUTH-WG] FW: [W3C Web Crypto WG - Information] IETF seeking review on oauth-v2-bearer draft specification X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2012 19:32:47 -0000 FYI, per the forwarded note below, at least the W3C WebCrypto WG was inform= ed last week of the request to review the URI Query Parameter text (Section= 2.3) of the OAuth Bearer spec. I've learned of no feedback to date. -- Mike -----Original Message----- From: GALINDO Virginie [mailto:Virginie.GALINDO@gemalto.com]=20 Sent: Wednesday, June 13, 2012 9:53 AM To: public-webcrypto@w3.org Cc: Thomas Roessler Subject: RE: [W3C Web Crypto WG - Information] IETF seeking review on oauth= -v2-bearer draft specification=20 Dear all, As highlighted by Thomas, IETF is seeking special advices, on the aspect of= using the access token in the request URI query component, as described in= section 2.3.=20 Regards, Virginie -----Original Message----- From: GALINDO Virginie=20 Sent: mercredi 13 juin 2012 15:54 To: public-webcrypto@w3.org Cc: Thomas Roessler Subject: [W3C Web Crypto WG - Information] IETF seeking review on oauth-v2-= bearer draft specification=20 Dear all, This is to inform you that IETF is currently reviewing its OAuth 2.0 bearer= token usage [1], covering the way OAuth tokens are used in HTPP requests t= o access protected resources. This topic is out of scope at the moment but = may be a use case for secondary features.=20 In case you have specific comments to share with the editors, you can direc= t it to IETF or to Thomas Roessler (CC) who is liaising with IETF.=20 Regards, Virginie gemalto [1] https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-bearer/=20 From stephen.farrell@cs.tcd.ie Mon Jun 18 12:46:58 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99C0221F8646 for ; Mon, 18 Jun 2012 12:46:58 -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 srkyt1J3zG1y for ; Mon, 18 Jun 2012 12:46:57 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 76A4121F8634 for ; Mon, 18 Jun 2012 12:46:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id D7768171530; Mon, 18 Jun 2012 20:46:56 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1340048816; bh=Fu+5MHJ2hfGUSQ KkCnhw+/3SnLhj+/iDAy8Y6rtzMEY=; b=foZRWLnLrsoxWwZHgCu+Dn1EMuxVzU Fe6CIi5oAPBYg2O357Zk/8NsOBJElSrqKQcMf/1Pb8c0f+1nXr9fOVSNkN02ZzO2 20PsLZZA7CnQkbDo2K/TdzzZEl3j4KolgpGYroMlp0wPKXqW7qGW4sLwm8UC0ZeX 9IJ5x852OqTPVzuSXe2Jf1oZWZl+HFHNRTo0tGYpy6yXIzbeahjZdsvxIVbj8e3k B26ui6RvlGJe4pS+psYydUwty8r4uQu/PxE0ACEQmofsTW+Pwut7pT6F1t75Hyf0 ZCKCgc6t6Z9wrmBHXMysAsyFwPJzo3zzoA0qkViB2xrhJpEIwXuTOGoQ== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id xYyKRect43LJ; Mon, 18 Jun 2012 20:46:56 +0100 (IST) Received: from [10.87.48.10] (unknown [86.41.12.186]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id C6D5617152C; Mon, 18 Jun 2012 20:46:53 +0100 (IST) Message-ID: <4FDF85AD.8040706@cs.tcd.ie> Date: Mon, 18 Jun 2012 20:46:53 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Mike Jones References: <4E1F6AAD24975D4BA5B168042967394366558C4C@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366558C4C@TK5EX14MBXC283.redmond.corp.microsoft.com> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Pete Resnick , Mark Nottingham , "oauth@ietf.org" Subject: Re: [OAUTH-WG] FW: Pete Resnick's Discuss on draft-ietf-oauth-v2-bearer-20: (with DISCUSS and 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: Mon, 18 Jun 2012 19:46:58 -0000 Hi Mike, As you noted this is under way. When I mailed tlr I asked for two weeks from the 13th, which co-incides with the end of the IETF LC caused by the IPR declaration, so it should be fine. Cheers, S. On 06/18/2012 07:08 PM, Mike Jones wrote: > Hi Stephen, > > Pete is holding his DISCUSS on Bearer open until the current text on the URI query parameter http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-20#section-2.3 receives W3C review. Can you try to have that review happen this week, hopefully finishing sometime next week? > > I'm cc:'ing Mark in his role as W3C liaison. > > Thanks again, > -- Mike > > -----Original Message----- > From: Pete Resnick [mailto:presnick@qualcomm.com] > Sent: Tuesday, June 12, 2012 1:40 PM > To: The IESG > Cc: oauth-chairs@tools.ietf.org; draft-ietf-oauth-v2-bearer@tools.ietf.org > Subject: Pete Resnick's Discuss on draft-ietf-oauth-v2-bearer-20: (with DISCUSS and COMMENT) > > Pete Resnick has entered the following ballot position for > draft-ietf-oauth-v2-bearer-20: Discuss > > When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Mark Nottingham's Applications Area review > identified the issue of URI query parameters in section 2.3: URI query parameters are normally locally scoped. In this document, a query parameter (access_token) is being defined as applying to all URIs. This is (relatively) novel. A few people in the HTTP community (including > Mark) have expressed concerns. (See also http://www.ietf.org/mail-archive/web/apps-discuss/current/msg04932.html > and > http://www.ietf.org/mail-archive/web/apps-discuss/current/msg04933.html > from the apps-discuss archive.) This issue should probably be further reviewed by W3C folks. I'm holding the DISCUSS as per Stephen to make sure we get that review. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > In section 2.3, the new last paragraph starts: > > This method is included to document current use; its use is NOT > RECOMMENDED... > > NOT RECOMMENDED is not defined by 2119, and the language is redundant with the previous paragraph and potentially confusing. I suggest replacing it with simply: > > This method is included to document current use; as indicated > in the previous paragraph, the use of this method is not > recommended... > > BTW: The "SHOULD NOT unless..." in the previous paragraph is itself redundant. I think you mean "MUST NOT unless...". SHOULD NOT *means* MUST NOT unless you understand what you're doing. > > Mark Nottingham's Applications Area review > has a couple of comments that I think deserve further reply: > > * Section 1: Introduction > > The introduction explains oauth, but it doesn't fully explain the > relationship of this specification to OAuth 2.0. E.g., can it be > used independently from the rest of OAuth? Likewise, the overview > (section 1.3) seems more specific to the OAuth specification than > this document. As I read it, this mechanism could be used for ANY > bearer token, not just one generated through OAuth flows. > > If it is indeed more general, I'd recommend minimising the > discussion of OAuth, perhaps even removing it from the document > title. > > I agree that the title would be better simply as "HTTP Bearer Tokens", and then explain in the Abstract and Intro that the motivation and intended use of these Bearer Tokens is the OAuth 2.0 specification. A possibly useful side effect of this change might be that you can make OAuth 2.0 an informative (as against a normative) reference, and that these things could be reused for other purposes in the future. Not a huge deal, but I (like Mark) was unconvinced that the reference to OAuth in the title was necessary. > > * Section 3 The WWW-Authenticate Response Header Field > > The difference between a realm and a scope is not explained. Are the > functionally equivalent, just a single value vs. a list? > > Some text, and probably an example, might help explain this a bit better. > > One of his comments asked for some additional review. I don't have a personal opinion whether this is needed, but perhaps you should pursue > this: > > * General > > The draft currently doesn't mention whether Bearer is suitable for > use as a proxy authentication scheme. I suspect it *may*; it would > be worth discussing this with some proxy implementers to gauge their > interest (e.g., Squid). > > > From shuochen@microsoft.com Mon Jun 18 13:20:48 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12A5411E80A3 for ; Mon, 18 Jun 2012 13:20:48 -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_65=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 mm1tTVze1eEi for ; Mon, 18 Jun 2012 13:20:45 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by ietfa.amsl.com (Postfix) with ESMTP id 992E211E809C for ; Mon, 18 Jun 2012 13:20:44 -0700 (PDT) Received: from mail86-tx2-R.bigfish.com (10.9.14.246) by TX2EHSOBE002.bigfish.com (10.9.40.22) with Microsoft SMTP Server id 14.1.225.23; Mon, 18 Jun 2012 20:19:24 +0000 Received: from mail86-tx2 (localhost [127.0.0.1]) by mail86-tx2-R.bigfish.com (Postfix) with ESMTP id 1FF9B440629 for ; Mon, 18 Jun 2012 20:19:24 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -29 X-BigFish: VS-29(zz9371Ic85fh1454I542M1432I1418Izz1202hzz1033IL8275bh8275dhz2fh2a8h683h839hd25hf0ah) Received-SPF: pass (mail86-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=shuochen@microsoft.com; helo=TK5EX14MLTC102.redmond.corp.microsoft.com ; icrosoft.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT004.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail86-tx2 (localhost.localdomain [127.0.0.1]) by mail86-tx2 (MessageSwitch) id 1340050762113140_17184; Mon, 18 Jun 2012 20:19:22 +0000 (UTC) Received: from TX2EHSMHS023.bigfish.com (unknown [10.9.14.253]) by mail86-tx2.bigfish.com (Postfix) with ESMTP id 0E9344C0043 for ; Mon, 18 Jun 2012 20:19:22 +0000 (UTC) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS023.bigfish.com (10.9.99.123) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 18 Jun 2012 20:19:20 +0000 Received: from va3outboundpool.messaging.microsoft.com (157.54.51.113) by mail.microsoft.com (157.54.79.180) with Microsoft SMTP Server (TLS) id 14.2.298.5; Mon, 18 Jun 2012 20:20:36 +0000 Received: from mail175-va3-R.bigfish.com (10.7.14.240) by VA3EHSOBE002.bigfish.com (10.7.40.22) with Microsoft SMTP Server id 14.1.225.23; Mon, 18 Jun 2012 20:18:24 +0000 Received: from mail175-va3 (localhost [127.0.0.1]) by mail175-va3-R.bigfish.com (Postfix) with ESMTP id 565DF340494 for ; Mon, 18 Jun 2012 20:18:24 +0000 (UTC) Received: from mail175-va3 (localhost.localdomain [127.0.0.1]) by mail175-va3 (MessageSwitch) id 1340050702506722_1038; Mon, 18 Jun 2012 20:18:22 +0000 (UTC) Received: from VA3EHSMHS030.bigfish.com (unknown [10.7.14.241]) by mail175-va3.bigfish.com (Postfix) with ESMTP id 6D620A0046; Mon, 18 Jun 2012 20:18:22 +0000 (UTC) Received: from BL2PRD0310HT004.namprd03.prod.outlook.com (157.56.240.21) by VA3EHSMHS030.bigfish.com (10.7.99.40) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 18 Jun 2012 20:18:20 +0000 Received: from BL2PRD0310MB387.namprd03.prod.outlook.com ([169.254.11.224]) by BL2PRD0310HT004.namprd03.prod.outlook.com ([10.255.97.39]) with mapi id 14.16.0152.000; Mon, 18 Jun 2012 20:19:38 +0000 From: "Shuo Chen (MSR)" To: "oauth@ietf.org" Thread-Topic: proposal of a paragraph to add to the security considerations section Thread-Index: Ac1Njb26Cfi2sNORQY2bLPj4RMYfIg== Date: Mon, 18 Jun 2012 20:19:38 +0000 Message-ID: <854774286EF8A240BACC342973A86EAC016693D6@BL2PRD0310MB387.namprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.192.57] Content-Type: multipart/alternative; boundary="_000_854774286EF8A240BACC342973A86EAC016693D6BL2PRD0310MB387_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: BL2PRD0310HT004.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%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%GMAIL.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IHTFP.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%GMX.NET$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%INDIANA.EDU$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%CS.TCD.IE$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14MLTC102.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14MLTC102.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com X-Mailman-Approved-At: Mon, 18 Jun 2012 13:35:36 -0700 Cc: rui wang , Yuchen Zhou , Derek Atkins Subject: [OAUTH-WG] proposal of a paragraph to add to the security considerations section X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 20:28:42 -0000 --_000_854774286EF8A240BACC342973A86EAC016693D6BL2PRD0310MB387_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi OAuth group, This is regarding the recent discussion about an implementation issue of so= me cloud services using OAuth for authentication. Derek Atkins and Dick Hardt suggested the possibility to discuss with the g= roup a paragraph to add to the security considerations section. Derek's suggestion: =3D=3D=3D=3D =3D=3D=3D =3D=3D=3D =3D=3D=3D >> Perhaps you could boil it down to a paragraph >> or two for addition to the security considerations section that basicall= y says >> "beware of implementing it *this* way because it leads to *that* attack = vector", etc. =3D=3D=3D=3D =3D=3D=3D =3D=3D=3D =3D=3D=3D Here is out suggested text: =3D=3D=3D=3D =3D=3D=3D =3D=3D=3D =3D=3D=3D It has been observed that in multiple occasions that the server-side authentication logic takes an access token from the client, then queries the user's profile data from the IdP in order to "authenticate" the user. This implementation must be forbidden. It will allow an untrusted app running on a victim's client device to work with an attacker's device to sign into the victim's account on the ser= ver side. =3D=3D=3D=3D =3D=3D=3D =3D=3D=3D =3D=3D=3D Thank you. -Shuo p.s. below is the email thread giving a better context of the discussion. > -----Original Message----- > From: Derek Atkins [mailto:derek@ihtfp.com] > Sent: Monday, June 18, 2012 11:25 AM > To: Shuo Chen (MSR) > Cc: Hannes Tschofenig; rui wang; Stephen Farrell; Yuchen Zhou; Derek > Atkins; Dick Hardt > Subject: Re: [OAUTH-WG] web sso study... > > Hi, > > "Shuo Chen (MSR)" writes: > >> Hi Hannes, Derek and Stephen, >> >> Thank you for your replies. >> >>> First, let me ask whether it is OK if I share your post with the >>> OAuth WG >> >> Yes, please feel free to share it. >> >>> Second, could you describe the attack in more details to me? >> >> Let's consider the mobile+cloud scenario for concreteness (although >> some other scenarios are also applicable). The attack steps are the >> following: suppose Alice's tablet runs a Windows 8 Metro app written >> by attacker Bob. This app is able to request and obtain an access >> token from the IdP (associated with Alice). The app can then send the >> access token to Bob's own tablet. Note that there is no security >> problem up to this point. However the real problem is that some cloud >> services use the access token to query the user's profile data from >> the IdP in order to "authenticate" the user. In this case, Bob's >> tablet will be able to sign into the cloud service as Alice. We have >> confirmed that the cloud services for Soluto Metro App, Givit Metro >> App and EuroCup2012 Metro App make this mistake. These are apps in >> the official Windows 8 App Store. We actually sampled only a small porti= on of the available apps, but believe this is a vulnerability pattern. >> >> We don't think there is anything wrong in the OAuth spec. It is >> developers who didn't comprehensively understand the usage of the >> access token. In the meanwhile, this vulnerability pattern is not explic= itly excluded by the spec. >> More importantly, it has been seen in the wild. >> >>> [from Derek's email] Perhaps you could boil it down to a paragraph >>> or two for >> addition to the security considerations section that basically says >> "beware of implementing it *this* way because it leads to *that* attack = vector", etc. >> >> This is a great idea. I think that although it is difficult to >> anticipate in general all kinds of incomprehensive understandings of >> average developers, it is very worthwhile to take any common existing >> vulnerability pattern as a precious feedback to improve the >> specification text. In this case, since we have already seen this >> vulnerability pattern on multiple services in the wild, certainly we >> should be explicit about it in the security considerations section. >> >> Our suggested text: >> >> It has been observed that in multiple occasions that the server-side >> authentication logic takes an access token from the client, then >> queries the user's profile data from the IdP in order to >> "authenticate" the user. This implementation must be forbidden. It >> will allow an untrusted app running on a victim's client device to >> work with an attacker's device to sign into the victim's account on the = server side. >> >> Any questions or suggestions? > > Could you please send this to the oauth@ietf.org mailing list? > >> Thanks a lot. >> >> -Shuo > > -derek > >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: Friday, June 15, 2012 11:36 AM >> To: rui wang >> Cc: Hannes Tschofenig; Stephen Farrell; Shuo Chen (MSR); Yuchen Zhou; >> Derek Atkins >> Subject: Re: [OAUTH-WG] web sso study... >> >> Hi Rui, >> >> let me independently respond (in addition to the previous responses >> you had already gotten). >> >> First, let me ask whether it is OK if I share your post with the >> OAuth WG since it is more detailed than the one you distributed on the l= ist mid April. >> >> Second, could you describe the attack in more details to me? What I >> would like to better understand whether this the raised issue is a >> problem with one of our specifications, with a specific >> implementation of the IETF OAuth specifications, a problem with other >> OAuth related work (Facebook, as you know, implements far more than >> just the IETF OAuth specifications), a violation of the IETF OAuth >> specification in the way how the Websites use OAuth, whether this is >> a configuration related aspect, or an aspect we already documented in th= e threats document. >> >> The reason why I am so specific is to know where to put text to >> address this issue or whether this is even an issue beyond the IETF >> OAuth working group and needs to be tackled somewhere else. >> >> Ciao >> >> Hannes >> --_000_854774286EF8A240BACC342973A86EAC016693D6BL2PRD0310MB387_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi OAuth group,

 

This is regarding the recent discussion about an imp= lementation issue of some cloud services using OAuth for authentication.

Derek Atkins and Dick Hardt suggested the possibilit= y to discuss with the group a paragraph to add to the security consideratio= ns section.

 

Derek’s suggestion:

=3D=3D=3D=3D   =3D=3D=3D  =3D=3D=3D&n= bsp; =3D=3D=3D

>> Perhaps you could boil it down to a paragra= ph

>> or two for addition to the security conside= rations section that basically says

>> "beware of implementing it *this* way = because it leads to *that* attack vector", etc.

=3D=3D=3D=3D   =3D=3D=3D  =3D=3D=3D&n= bsp; =3D=3D=3D

 

 

Here is out suggested text:

=3D=3D=3D=3D   =3D=3D=3D  =3D=3D=3D&n= bsp; =3D=3D=3D

It has been observed that in multiple occasions that= the server-side

authentication logic takes an access token from the = client, then

queries the user's profile data from the IdP in orde= r to

"authenticate" the user. This implementati= on must be forbidden. It

will allow an untrusted app running on a victim̵= 7;s client device to

work with an attacker’s device to sign into th= e victim’s account on the server side.

=3D=3D=3D=3D   =3D=3D=3D  =3D=3D=3D&n= bsp; =3D=3D=3D

 

 

Thank you.

-Shuo

p.s. below is the email thread giving a better conte= xt of the discussion.

 

 

> -----Original Message-----

> From: Derek Atkins [mailto:derek@ihtfp.com]

> Sent: Monday, June 18, 2012 11:25 AM=

> To: Shuo Chen (MSR)

> Cc: Hannes Tschofenig; rui wang; Stephen Farrel= l; Yuchen Zhou; Derek

> Atkins; Dick Hardt

> Subject: Re: [OAUTH-WG] web sso study...

> 

> Hi,

> 

> "Shuo Chen (MSR)" <shuochen@micros= oft.com> writes:

> 

>> Hi Hannes, Derek and Stephen,

>> 

>> Thank you for your replies.

>> 

>>> First, let me ask whether it is OK if I= share your post with the

>>> OAuth WG

>> 

>> Yes, please feel free to share it.

>> 

>>> Second, could you describe the attack i= n more details to me?

>> 

>> Let's consider the mobile+cloud scenari= o for concreteness (although

>> some other scenarios are also applicable). = The attack steps are the

>> following: suppose Alice's tablet runs a Wi= ndows 8 Metro app written

>> by attacker Bob. This app is able to reques= t and obtain an access

>> token from the IdP (associated with Alice).= The app can then send the

>> access token to Bob's own tablet. Note that= there is no security

>> problem up to this point. However the real = problem is that some cloud

>> services use the access token to query the = user's profile data from

>> the IdP in order to "authenticate"= ; the user. In this case, Bob's

>> tablet will be able to sign into the cloud = service as Alice. We have

>> confirmed that the cloud services for Solut= o Metro App, Givit Metro

>> App and EuroCup2012 Metro App make this mis= take. These are apps in

>> the official Windows 8 App Store. We actual= ly sampled only a small portion of the available apps, but believe this is = a vulnerability pattern.

>> 

>> We don’t think there is anything wron= g in the OAuth spec. It is

>> developers who didn’t comprehensively= understand the usage of the

>> access token. In the meanwhile, this vulner= ability pattern is not explicitly excluded by the spec.

>> More importantly, it has been seen in the w= ild.

>> 

>>> [from Derek's email] Perhaps you could = boil it down to a paragraph

>>> or two for

>> addition to the security considerations sec= tion that basically says

>> "beware of implementing it *this* way = because it leads to *that* attack vector", etc.

>> 

>> This is a great idea. I think that although= it is difficult to

>> anticipate in general all kinds of incompre= hensive understandings of

>> average developers, it is very worthwhile t= o take any common existing

>> vulnerability pattern as a precious feedbac= k to improve the

>> specification text. In this case, since we = have already seen this

>> vulnerability pattern on multiple services = in the wild, certainly we

>> should be explicit about it in the security= considerations section.

>> 

>> Our suggested text:

>> 

>> It has been observed that in multiple occas= ions that the server-side

>> authentication logic takes an access token = from the client, then

>> queries the user's profile data from the Id= P in order to

>> "authenticate" the user. This imp= lementation must be forbidden. It

>> will allow an untrusted app running on a vi= ctim’s client device to

>> work with an attacker’s device to sig= n into the victim’s account on the server side.

>> 

>> Any questions or suggestions?

> 

> Could you please send this to the oauth@ietf.or= g mailing list?

> 

>> Thanks a lot.

>> 

>> -Shuo

> 

> -derek

> 

>> -----Original Message-----

>> From: Hannes Tschofenig [mailto:Hannes.Tsch= ofenig@gmx.net]

>> Sent: Friday, June 15, 2012 11:36 AM

>> To: rui wang

>> Cc: Hannes Tschofenig; Stephen Farrell; Shu= o Chen (MSR); Yuchen Zhou;

>> Derek Atkins

>> Subject: Re: [OAUTH-WG] web sso study...

>> 

>> Hi Rui,

>> 

>> let me independently respond (in addition t= o the previous responses

>> you had already gotten).

>> 

>> First, let me ask whether it is OK if I sha= re your post with the

>> OAuth WG since it is more detailed than the= one you distributed on the list mid April.

>> 

>> Second, could you describe the attack in mo= re details to me? What I

>> would like to better understand whether thi= s the raised issue is a

>> problem with one of our specifications, wit= h a specific

>> implementation of the IETF OAuth specificat= ions, a problem with other

>> OAuth related work (Facebook, as you know, = implements far more than

>> just the IETF OAuth specifications), a viol= ation of the IETF OAuth

>> specification in the way how the Websites u= se OAuth, whether this is

>> a configuration related aspect, or an aspec= t we already documented in the threats document.

>> 

>> The reason why I am so specific is to know = where to put text to

>> address this issue or whether this is even = an issue beyond the IETF

>> OAuth working group and needs to be tackled= somewhere else.

>> 

>> Ciao

>> 

>> Hannes

>>

--_000_854774286EF8A240BACC342973A86EAC016693D6BL2PRD0310MB387_-- From ve7jtb@ve7jtb.com Mon Jun 18 14:04:43 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40C1011E80E0 for ; Mon, 18 Jun 2012 14:04:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_65=0.6, 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 EbZlObPX8urj for ; Mon, 18 Jun 2012 14:04:41 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 65B5F11E80D6 for ; Mon, 18 Jun 2012 14:04:41 -0700 (PDT) Received: by yhq56 with SMTP id 56so4656178yhq.31 for ; Mon, 18 Jun 2012 14:04:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=MuOO9zOilAKbH5HOzrIHELuevAmbrkUhMA3rheEc0HI=; b=VHxQpRBdz7G82kvsAdOlrQI+POA14GBmYqxagD5KaSlXCottfETI29E561NBE6fSiX 1sLYuGbBUgxNzZriCOcV4aWuYy1gUSHxG4BuPCQ5MRPkb+GuBmAL2VNs0xKyK9RkgPnW 9J3cZXV9ibTyqcrSCl0mllC0MmMxB/wrgSb/RkHlbpNoRJM0UuPXp4ys6JQO5OkKEndq pJYmgiTCiOgOW+hbkOXMnQZRYwN5TGyiISo9OR+GWHA8iFEa1ODk7ueetLYVL7//RNvN eMAjGtk4bpvgltou6YTBPw6EgwWFU16xulEF+bFgDeQIpy7c+otyHhg8zuIu4DP7GvEw adsQ== Received: by 10.236.136.8 with SMTP id v8mr20226401yhi.101.1340053480657; Mon, 18 Jun 2012 14:04:40 -0700 (PDT) Received: from [192.168.1.213] (190-20-29-46.baf.movistar.cl. [190.20.29.46]) by mx.google.com with ESMTPS id p29sm69177868yhl.19.2012.06.18.14.04.27 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 18 Jun 2012 14:04:38 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_02B4B427-8C61-4473-ABED-9F505CDDEC3A"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <854774286EF8A240BACC342973A86EAC016693D6@BL2PRD0310MB387.namprd03.prod.outlook.com> Date: Mon, 18 Jun 2012 17:04:16 -0400 Message-Id: <484A13D0-7C9A-42CC-BB94-3657741834DE@ve7jtb.com> References: <854774286EF8A240BACC342973A86EAC016693D6@BL2PRD0310MB387.namprd03.prod.outlook.com> To: "Shuo Chen (MSR)" X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQmv7Ah+30mVLIVaswQhfEx41yV4vPKupK4ywirphtebmkiRj7mQ7bSm1IbJkVCMiP4tkclJ Cc: Yuchen Zhou , Derek Atkins , "oauth@ietf.org" , rui wang Subject: Re: [OAUTH-WG] proposal of a paragraph to add to the security considerations section X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 21:04:43 -0000 --Apple-Mail=_02B4B427-8C61-4473-ABED-9F505CDDEC3A Content-Type: multipart/alternative; boundary="Apple-Mail=_D8AA8225-1C90-48CB-9AEC-D67D50A9F158" --Apple-Mail=_D8AA8225-1C90-48CB-9AEC-D67D50A9F158 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I blogged about this in the hypothetical several months ago. = http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.h= tml Nov Matake and others built some tests and found quite a number of = deployments vulnerable.=20 = http://www.thread-safe.com/2012/02/more-on-oauth-implicit-flow-application= .html The bottom line is that OAuth has no explicit audience restriction for = tokens, hence accepting any token outside of the code flow is subject = to attack. In general it is not a issue for authorization, it is however a big = issue then there is a presumption that the presenter of a token that = grants a client access to resource x is the "resource owner" of resource = x, when it is possible that the presenter is any client who has ever had = a access token for resource x. We might want to include the why it is insecure in the security = consideration, otherwise people reading the below will likely ignore = the advice as it seems on the surface a touch extreme. There are certainly OAuth flows that allow you to do authentication = safely, just not all of them without additional precautions. That is why openID Connect has a audience restricted id_token similar to = Facebook's signed request to allow the implicit flows to be safely used = for authentication. John B. On 2012-06-18, at 4:19 PM, Shuo Chen (MSR) wrote: > Hi OAuth group, > =20 > This is regarding the recent discussion about an implementation issue = of some cloud services using OAuth for authentication. > Derek Atkins and Dick Hardt suggested the possibility to discuss with = the group a paragraph to add to the security considerations section. > =20 > Derek=92s suggestion: > =3D=3D=3D=3D =3D=3D=3D =3D=3D=3D =3D=3D=3D > >> Perhaps you could boil it down to a paragraph > >> or two for addition to the security considerations section that = basically says > >> "beware of implementing it *this* way because it leads to *that* = attack vector", etc. > =3D=3D=3D=3D =3D=3D=3D =3D=3D=3D =3D=3D=3D > =20 > =20 > Here is out suggested text: > =3D=3D=3D=3D =3D=3D=3D =3D=3D=3D =3D=3D=3D > It has been observed that in multiple occasions that the server-side > authentication logic takes an access token from the client, then > queries the user's profile data from the IdP in order to > "authenticate" the user. This implementation must be forbidden. It > will allow an untrusted app running on a victim=92s client device to > work with an attacker=92s device to sign into the victim=92s account = on the server side. > =3D=3D=3D=3D =3D=3D=3D =3D=3D=3D =3D=3D=3D > =20 > =20 > Thank you. > -Shuo > p.s. below is the email thread giving a better context of the = discussion. > =20 > =20 > > -----Original Message----- > > From: Derek Atkins [mailto:derek@ihtfp.com] > > Sent: Monday, June 18, 2012 11:25 AM > > To: Shuo Chen (MSR) > > Cc: Hannes Tschofenig; rui wang; Stephen Farrell; Yuchen Zhou; Derek > > Atkins; Dick Hardt > > Subject: Re: [OAUTH-WG] web sso study... > >=20 > > Hi, > >=20 > > "Shuo Chen (MSR)" writes: > >=20 > >> Hi Hannes, Derek and Stephen, > >>=20 > >> Thank you for your replies. > >>=20 > >>> First, let me ask whether it is OK if I share your post with the > >>> OAuth WG > >>=20 > >> Yes, please feel free to share it. > >>=20 > >>> Second, could you describe the attack in more details to me? > >>=20 > >> Let's consider the mobile+cloud scenario for concreteness (although > >> some other scenarios are also applicable). The attack steps are the > >> following: suppose Alice's tablet runs a Windows 8 Metro app = written > >> by attacker Bob. This app is able to request and obtain an access > >> token from the IdP (associated with Alice). The app can then send = the > >> access token to Bob's own tablet. Note that there is no security > >> problem up to this point. However the real problem is that some = cloud > >> services use the access token to query the user's profile data from > >> the IdP in order to "authenticate" the user. In this case, Bob's > >> tablet will be able to sign into the cloud service as Alice. We = have > >> confirmed that the cloud services for Soluto Metro App, Givit Metro > >> App and EuroCup2012 Metro App make this mistake. These are apps in > >> the official Windows 8 App Store. We actually sampled only a small = portion of the available apps, but believe this is a vulnerability = pattern. > >>=20 > >> We don=92t think there is anything wrong in the OAuth spec. It is > >> developers who didn=92t comprehensively understand the usage of the > >> access token. In the meanwhile, this vulnerability pattern is not = explicitly excluded by the spec. > >> More importantly, it has been seen in the wild. > >>=20 > >>> [from Derek's email] Perhaps you could boil it down to a paragraph > >>> or two for > >> addition to the security considerations section that basically says > >> "beware of implementing it *this* way because it leads to *that* = attack vector", etc. > >>=20 > >> This is a great idea. I think that although it is difficult to > >> anticipate in general all kinds of incomprehensive understandings = of > >> average developers, it is very worthwhile to take any common = existing > >> vulnerability pattern as a precious feedback to improve the > >> specification text. In this case, since we have already seen this > >> vulnerability pattern on multiple services in the wild, certainly = we > >> should be explicit about it in the security considerations section. > >>=20 > >> Our suggested text: > >>=20 > >> It has been observed that in multiple occasions that the = server-side > >> authentication logic takes an access token from the client, then > >> queries the user's profile data from the IdP in order to > >> "authenticate" the user. This implementation must be forbidden. It > >> will allow an untrusted app running on a victim=92s client device = to > >> work with an attacker=92s device to sign into the victim=92s = account on the server side. > >>=20 > >> Any questions or suggestions? > >=20 > > Could you please send this to the oauth@ietf.org mailing list? > >=20 > >> Thanks a lot. > >>=20 > >> -Shuo > >=20 > > -derek > >=20 > >> -----Original Message----- > >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > >> Sent: Friday, June 15, 2012 11:36 AM > >> To: rui wang > >> Cc: Hannes Tschofenig; Stephen Farrell; Shuo Chen (MSR); Yuchen = Zhou; > >> Derek Atkins > >> Subject: Re: [OAUTH-WG] web sso study... > >>=20 > >> Hi Rui, > >>=20 > >> let me independently respond (in addition to the previous responses > >> you had already gotten). > >>=20 > >> First, let me ask whether it is OK if I share your post with the > >> OAuth WG since it is more detailed than the one you distributed on = the list mid April. > >>=20 > >> Second, could you describe the attack in more details to me? What I > >> would like to better understand whether this the raised issue is a > >> problem with one of our specifications, with a specific > >> implementation of the IETF OAuth specifications, a problem with = other > >> OAuth related work (Facebook, as you know, implements far more than > >> just the IETF OAuth specifications), a violation of the IETF OAuth > >> specification in the way how the Websites use OAuth, whether this = is > >> a configuration related aspect, or an aspect we already documented = in the threats document. > >>=20 > >> The reason why I am so specific is to know where to put text to > >> address this issue or whether this is even an issue beyond the IETF > >> OAuth working group and needs to be tackled somewhere else. > >>=20 > >> Ciao > >>=20 > >> Hannes > >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_D8AA8225-1C90-48CB-9AEC-D67D50A9F158 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I blogged about this in the hypothetical several = months ago. http://www.thread-safe.com/2012/01/problem-with-oauth-for-aut= hentication.html

Nov Matake and others built some = tests and found quite a number of deployments = vulnerable. 

The bottom line is = that OAuth has no explicit audience restriction for tokens,  hence = accepting any token outside of the code flow is subject to = attack.

In general it is not a issue for = authorization,  it is however a big issue then there is a = presumption that the presenter of a token that grants a client access to = resource x is the "resource owner" of resource x, when it is possible = that the presenter is any client who has ever had a access token for = resource x.

We might want to include the why it = is insecure in the security consideration,  otherwise people = reading the below will likely ignore the advice as it seems on the = surface a touch extreme.

There are certainly = OAuth flows that allow you to do authentication safely,  just not = all of them without additional = precautions.

That is why openID Connect has a = audience restricted id_token similar to Facebook's signed request to = allow the implicit flows to be safely used for = authentication.

John = B.




On = 2012-06-18, at 4:19 PM, Shuo Chen (MSR) wrote:

Hi OAuth = group,
 
This is regarding = the recent discussion about an implementation issue of some cloud = services using OAuth for authentication.
Derek Atkins and Dick Hardt suggested the possibility to = discuss with the group a paragraph to add to the security considerations = section.
 
Derek=92s suggestion:
=3D=3D=3D=3D   =3D=3D=3D  =3D=3D=3D  = =3D=3D=3D
>> Perhaps you could boil it = down to a paragraph
>> or two for addition = to the security considerations section that basically = says
>> "beware of implementing it *this* way = because it leads to *that* attack vector", etc.
=3D=3D=3D=3D   =3D=3D=3D  =3D=3D=3D  = =3D=3D=3D
 
 
Here is out suggested = text:
=3D=3D=3D=3D   =3D=3D=3D  = =3D=3D=3D  =3D=3D=3D
It has been observed that in = multiple occasions that the server-side
authentication logic takes an access token from the = client, then
queries the user's profile = data from the IdP in order to
"authenticate" the = user. This implementation must be forbidden. It
will allow an untrusted app running on a victim=92s client = device to
work with an attacker=92s device to = sign into the victim=92s account on the server = side.
=3D=3D=3D=3D   =3D=3D=3D  = =3D=3D=3D  =3D=3D=3D
 
 
Thank = you.
-Shuo
p.s. below is the = email thread giving a better context of the = discussion.
 
 
> -----Original = Message-----
> From: Derek Atkins = [mailto:derek@ihtfp.com]
> Sent: Monday, June 18, = 2012 11:25 AM
> To: Shuo Chen = (MSR)
> Cc: Hannes Tschofenig; rui wang; Stephen = Farrell; Yuchen Zhou; Derek
> Atkins; Dick = Hardt
> Subject: Re: [OAUTH-WG] web sso = study...
> 
> Hi,
> "Shuo Chen (MSR)" <shuochen@microsoft.com> = writes:
> 
>> Hi Hannes, Derek and = Stephen,
>> 
>> Thank you for your replies.
>> 
>>> First, = let me ask whether it is OK if I share your post with = the
>>> OAuth WG
>> 
>> Yes, = please feel free to share it.
>>> Second, could you = describe the attack in more details to me?
>> 
>> Let's = consider the mobile+cloud scenario for concreteness = (although
>> some other scenarios are = also applicable). The attack steps are the
>> following: suppose Alice's tablet runs a Windows = 8 Metro app written
>> by attacker Bob. This = app is able to request and obtain an access
>> token from the IdP (associated with Alice). The = app can then send the
>> access token to Bob's = own tablet. Note that there is no security
>> problem up to this point. However the real = problem is that some cloud
>> services = use the access token to query the user's profile data = from
>> the IdP in order to "authenticate" the = user. In this case, Bob's
>> tablet will be able = to sign into the cloud service as Alice. We have
>> confirmed that the cloud services for Soluto = Metro App, Givit Metro
>> App and EuroCup2012 = Metro App make this mistake. These are apps in
>> the official Windows 8 App Store. We actually = sampled only a small portion of the available apps, but believe this is = a vulnerability pattern.
>> We don=92t think = there is anything wrong in the OAuth spec. It is
>> developers who didn=92t comprehensively = understand the usage of the
>> access = token. In the meanwhile, this vulnerability pattern is not explicitly = excluded by the spec.
>> More importantly, it = has been seen in the wild.
>>> [from Derek's = email] Perhaps you could boil it down to a = paragraph
>>> or two = for
>> addition to the security considerations = section that basically says
>> "beware of = implementing it *this* way because it leads to *that* attack vector", = etc.
>> 
>> This is a great idea. I think that although it is = difficult to
>> anticipate in general = all kinds of incomprehensive understandings of
>> average developers, it is very worthwhile to take = any common existing
>> vulnerability pattern = as a precious feedback to improve the
>> specification text. In this case, since we have = already seen this
>> vulnerability pattern = on multiple services in the wild, certainly we
>> should be explicit about it in the security = considerations section.
>> Our suggested = text:
>> 
>> It has been observed that in multiple occasions = that the server-side
>> authentication logic = takes an access token from the client, then
>> queries the user's profile data from the IdP in = order to
>> "authenticate" the user. = This implementation must be forbidden. It
>> will allow an untrusted app running on a victim=92s= client device to
>> work with an = attacker=92s device to sign into the victim=92s account on the server = side.
>> 
>> Any questions or = suggestions?
> Could you please send = this to the oauth@ietf.org mailing = list?
> 
>> Thanks a lot.
>> 
>> = -Shuo
> 
> -derek
>> -----Original = Message-----
>> From: Hannes = Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
>> Sent: Friday, June 15, 2012 11:36 = AM
>> To: rui wang
>> Cc: Hannes Tschofenig; Stephen Farrell; Shuo Chen = (MSR); Yuchen Zhou;
>> Derek = Atkins
>> Subject: Re: [OAUTH-WG] web sso = study...
>> 
>> Hi Rui,
>> let me independently = respond (in addition to the previous responses
>> you had already gotten).
>> 
>> First, let = me ask whether it is OK if I share your post with = the
>> OAuth WG since it is more detailed than = the one you distributed on the list mid April.
>> 
>> Second, = could you describe the attack in more details to me? What = I
>> would like to better understand whether = this the raised issue is a
>> problem = with one of our specifications, with a specific
>> implementation of the IETF OAuth specifications, = a problem with other
>> OAuth related work = (Facebook, as you know, implements far more than
>> just the IETF OAuth specifications), a violation = of the IETF OAuth
>> specification in the = way how the Websites use OAuth, whether this is
>> a configuration related aspect, or an aspect we = already documented in the threats document.
>> 
>> The reason = why I am so specific is to know where to put text = to
>> address this issue or whether this is = even an issue beyond the IETF
>> OAuth = working group and needs to be tackled somewhere = else.
>> 
>> Ciao
>> = Hannes
Thread-Topic: [OAUTH-WG] nits about definition of using form parameters Thread-Index: AQHNSHuYXSQLx0xX+0SqLBLjyunoDJcApo5A Date: Mon, 18 Jun 2012 21:48:14 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436655A58E@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <4FD70812.6040108@gmx.de> In-Reply-To: <4FD70812.6040108@gmx.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.70] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [OAUTH-WG] nits about definition of using form parameters X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 21:48:21 -0000 Hi Julian, Both the Core and Bearer specs already reference W3C.REC-html401-19991224 f= or the definition of application/x-www-form-urlencoded. I'll leave it up to others to comment on whether the ;charset=3DUTF-8 param= eter is correct or not. -- Mike -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of J= ulian Reschke Sent: Tuesday, June 12, 2012 2:13 AM To: OAuth WG (oauth@ietf.org) Subject: [OAUTH-WG] nits about definition of using form parameters Hi there, re : This needs a normative reference to a spec that defines the application/x-w= ww-form-urlencoded media type (such as ). Looking at the media type definition I don't see any mention of a charset p= arameter, so the example probably is wrong. See also : "Note: Parameters on the application/x-www-form-urlencoded MIME type are ig= nored. In particular, this MIME type does not support the charset parameter= ." I would also advise to change The client makes a request to the token endpoint by adding the following parameters using the "application/x-www-form-urlencoded" format in the HTTP request entity-body: grant_type REQUIRED. Value MUST be set to "password". username REQUIRED. The resource owner username, encoded as UTF-8. password REQUIRED. The resource owner password, encoded as UTF-8. scope OPTIONAL. The scope of the access request as described by Section 3.3. to The client makes a request to the token endpoint by sending the following parameters using the "application/x-www-form-urlencoded" format (Section 4.10.22.5 of [WD-html5-20120329]) and a character encoding of "UTF-8" in the HTTP request entity-body: grant_type REQUIRED. Value MUST be set to "password". username REQUIRED. The resource owner username. password REQUIRED. The resource owner password. scope OPTIONAL. The scope of the access request as described by Section 3.3. Finally, it would be good if the example used characters that require escap= ing in the body, such as "&", "%", or non-ASCII characters. (similar nits apply to other sections using form encoding) Best regards, Julian _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Mon Jun 18 15:17:42 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C135A11E80D9 for ; Mon, 18 Jun 2012 15:17:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LEJUqdMDGGVE for ; Mon, 18 Jun 2012 15:17:42 -0700 (PDT) Received: from p3plex2out04.prod.phx3.secureserver.net (p3plex2out04.prod.phx3.secureserver.net [184.168.131.18]) by ietfa.amsl.com (Postfix) with ESMTP id 0A44F11E80C1 for ; Mon, 18 Jun 2012 15:17:42 -0700 (PDT) Received: from P3PWEX2HT002.ex2.secureserver.net ([184.168.131.10]) by p3plex2out04.prod.phx3.secureserver.net with bizsmtp id PyHh1j0030Dcg9U01yHhTz; Mon, 18 Jun 2012 15:17:41 -0700 Received: from P3PWEX2MB008.ex2.secureserver.net ([169.254.8.66]) by P3PWEX2HT002.ex2.secureserver.net ([184.168.131.10]) with mapi id 14.02.0247.003; Mon, 18 Jun 2012 15:17:41 -0700 From: Eran Hammer To: Mike Jones , Julian Reschke , "OAuth WG (oauth@ietf.org)" Thread-Topic: [OAUTH-WG] nits about definition of using form parameters Thread-Index: AQHNSHuYNn5GyPRYwECfY+U4MeoAcZcBHIEA//+SpkA= Date: Mon, 18 Jun 2012 22:17:40 +0000 Message-ID: <0CBAEB56DDB3A140BA8E8C124C04ECA201077978@P3PWEX2MB008.ex2.secureserver.net> References: <4FD70812.6040108@gmx.de> <4E1F6AAD24975D4BA5B16804296739436655A58E@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436655A58E@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [80.36.76.35] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] nits about definition of using form parameters X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 22:17:42 -0000 I believe the UTF-8 piece came from Brian Eaton a while back because of som= e security issue identified at Google. EH > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Mike Jones > Sent: Monday, June 18, 2012 2:48 PM > To: Julian Reschke; OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] nits about definition of using form parameters >=20 > Hi Julian, >=20 > Both the Core and Bearer specs already reference W3C.REC-html401- > 19991224 for the definition of application/x-www-form-urlencoded. >=20 > I'll leave it up to others to comment on whether the ;charset=3DUTF-8 > parameter is correct or not. >=20 > -- Mike >=20 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Julian Reschke > Sent: Tuesday, June 12, 2012 2:13 AM > To: OAuth WG (oauth@ietf.org) > Subject: [OAUTH-WG] nits about definition of using form parameters >=20 > Hi there, >=20 > re : >=20 > This needs a normative reference to a spec that defines the application/x= - > www-form-urlencoded media type (such as > urlencoded>). >=20 > Looking at the media type definition I don't see any mention of a charset > parameter, so the example probably is wrong. See also > data>: >=20 > "Note: Parameters on the application/x-www-form-urlencoded MIME type > are ignored. In particular, this MIME type does not support the charset > parameter." >=20 > I would also advise to change >=20 > The client makes a request to the token endpoint by adding the > following parameters using the "application/x-www-form-urlencoded" > format in the HTTP request entity-body: >=20 > grant_type > REQUIRED. Value MUST be set to "password". > username > REQUIRED. The resource owner username, encoded as UTF-8. > password > REQUIRED. The resource owner password, encoded as UTF-8. > scope > OPTIONAL. The scope of the access request as described by > Section 3.3. >=20 > to >=20 >=20 > The client makes a request to the token endpoint by sending the > following parameters using the "application/x-www-form-urlencoded" > format (Section 4.10.22.5 of [WD-html5-20120329]) and a > character encoding of "UTF-8" in the HTTP request entity-body: >=20 > grant_type > REQUIRED. Value MUST be set to "password". > username > REQUIRED. The resource owner username. > password > REQUIRED. The resource owner password. > scope > OPTIONAL. The scope of the access request as described by > Section 3.3. >=20 > Finally, it would be good if the example used characters that require esc= aping > in the body, such as "&", "%", or non-ASCII characters. >=20 > (similar nits apply to other sections using form encoding) >=20 > Best regards, Julian > _______________________________________________ > 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 Michael.Jones@microsoft.com Mon Jun 18 17:03:51 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 735EF11E8073 for ; Mon, 18 Jun 2012 17:03:51 -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 gGBkDb27jray for ; Mon, 18 Jun 2012 17:03:50 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by ietfa.amsl.com (Postfix) with ESMTP id D523B21F84FC for ; Mon, 18 Jun 2012 17:03:47 -0700 (PDT) Received: from mail177-tx2-R.bigfish.com (10.9.14.251) by TX2EHSOBE003.bigfish.com (10.9.40.23) with Microsoft SMTP Server id 14.1.225.23; Tue, 19 Jun 2012 00:02:28 +0000 Received: from mail177-tx2 (localhost [127.0.0.1]) by mail177-tx2-R.bigfish.com (Postfix) with ESMTP id A657316013B for ; Tue, 19 Jun 2012 00:02:27 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC105.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: 0 X-BigFish: VS0(zzc85fhzz1202hzz8275bh8275dhz2fh793h2a8h668h839hd25hf0ah34h) Received-SPF: pass (mail177-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC105.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail177-tx2 (localhost.localdomain [127.0.0.1]) by mail177-tx2 (MessageSwitch) id 1340064144473731_21345; Tue, 19 Jun 2012 00:02:24 +0000 (UTC) Received: from TX2EHSMHS026.bigfish.com (unknown [10.9.14.243]) by mail177-tx2.bigfish.com (Postfix) with ESMTP id 5C0F960046 for ; Tue, 19 Jun 2012 00:02:24 +0000 (UTC) Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS026.bigfish.com (10.9.99.126) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 19 Jun 2012 00:02:21 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.53]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.02.0309.003; Tue, 19 Jun 2012 00:03:38 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: Proposed OAuth Core -28 Thread-Index: Ac1NrvRHCkTMxAd8QmCkI0dM6RnD+w== Date: Tue, 19 Jun 2012 00:03:37 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436655A85E@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.70] Content-Type: multipart/mixed; boundary="_007_4E1F6AAD24975D4BA5B16804296739436655A85ETK5EX14MBXC283r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: [OAUTH-WG] Proposed OAuth Core -28 X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 00:03:51 -0000 --_007_4E1F6AAD24975D4BA5B16804296739436655A85ETK5EX14MBXC283r_ Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436655A85ETK5EX14MBXC283r_" --_000_4E1F6AAD24975D4BA5B16804296739436655A85ETK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In cooperation with the chairs and Eran, I've produced the attached propose= d OAuth Core -28 version. It updates the ABNF in the manner discussed by t= he working group, allowing username and password to be Unicode and restrict= ing client_id and client_secret to ASCII. It specifies the use of the appl= ication/x-www-form-urlencoded content-type encoding method to encode the cl= ient_id when used as the password for HTTP Basic. A few minor grammar erro= rs encountered were also corrected. Normative changes are in sections 2.3.= 1, A.1, A.2, A.15, and A.16. Unless I hear objections, I'll use the public= ation tool to post this as -28 at close of business tomorrow, with Eran bei= ng the one to give approval in the tool for publication. Cheers, -- Mike --_000_4E1F6AAD24975D4BA5B16804296739436655A85ETK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In cooperation with the chairs and Eran, I’ve = produced the attached proposed OAuth Core -28 version.  It updates the= ABNF in the manner discussed by the working group, allowing username and p= assword to be Unicode and restricting client_id and client_secret to ASCII.  It specifies the use of the application/= x-www-form-urlencoded content-type encoding method to encode the client_id = when used as the password for HTTP Basic.  A few minor grammar errors = encountered were also corrected.  Normative changes are in sections 2.3.1, A.1, A.2, A.15, and A.16.  Unless I he= ar objections, I’ll use the publication tool to post this as -28 at c= lose of business tomorrow, with Eran being the one to give approval in the = tool for publication.

 

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

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

 

--_000_4E1F6AAD24975D4BA5B16804296739436655A85ETK5EX14MBXC283r_-- --_007_4E1F6AAD24975D4BA5B16804296739436655A85ETK5EX14MBXC283r_ Content-Type: text/html; name="draft-ietf-oauth-v2-28-preliminary.html" Content-Description: draft-ietf-oauth-v2-28-preliminary.html Content-Disposition: attachment; filename="draft-ietf-oauth-v2-28-preliminary.html"; size=253756; creation-date="Mon, 18 Jun 2012 22:51:52 GMT"; modification-date="Mon, 18 Jun 2012 22:47:57 GMT" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMDEgVHJhbnNpdGlvbmFs Ly9FTiIgImh0dHA6Ly93d3cudzMub3JnL1RSL2h0bWw0L2xvb3NlLmR0ZCI+CjxodG1sIGxhbmc9 ImVuIj48aGVhZD48dGl0bGU+VGhlIE9BdXRoIDIuMCBBdXRob3JpemF0aW9uIEZyYW1ld29yazwv dGl0bGU+CjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9odG1s OyBjaGFyc2V0PXV0Zi04Ij4KPG1ldGEgbmFtZT0iZGVzY3JpcHRpb24iIGNvbnRlbnQ9IlRoZSBP QXV0aCAyLjAgQXV0aG9yaXphdGlvbiBGcmFtZXdvcmsiPgo8bWV0YSBuYW1lPSJnZW5lcmF0b3Ii IGNvbnRlbnQ9InhtbDJyZmMgdjEuMzYgKGh0dHA6Ly94bWwucmVzb3VyY2Uub3JnLykiPgo8c3R5 bGUgdHlwZT0ndGV4dC9jc3MnPjwhLS0KICAgICAgICBib2R5IHsKICAgICAgICAgICAgICAgIGZv bnQtZmFtaWx5OiB2ZXJkYW5hLCBjaGFyY29hbCwgaGVsdmV0aWNhLCBhcmlhbCwgc2Fucy1zZXJp ZjsKICAgICAgICAgICAgICAgIGZvbnQtc2l6ZTogc21hbGw7IGNvbG9yOiAjMDAwOyBiYWNrZ3Jv dW5kLWNvbG9yOiAjRkZGOwogICAgICAgICAgICAgICAgbWFyZ2luOiAyZW07CiAgICAgICAgfQog ICAgICAgIGgxLCBoMiwgaDMsIGg0LCBoNSwgaDYgewogICAgICAgICAgICAgICAgZm9udC1mYW1p bHk6IGhlbHZldGljYSwgbW9uYWNvLCAiTVMgU2FucyBTZXJpZiIsIGFyaWFsLCBzYW5zLXNlcmlm OwogICAgICAgICAgICAgICAgZm9udC13ZWlnaHQ6IGJvbGQ7IGZvbnQtc3R5bGU6IG5vcm1hbDsK ICAgICAgICB9CiAgICAgICAgaDEgeyBjb2xvcjogIzkwMDsgYmFja2dyb3VuZC1jb2xvcjogdHJh bnNwYXJlbnQ7IHRleHQtYWxpZ246IHJpZ2h0OyB9CiAgICAgICAgaDMgeyBjb2xvcjogIzMzMzsg YmFja2dyb3VuZC1jb2xvcjogdHJhbnNwYXJlbnQ7IH0KCiAgICAgICAgdGQuUkZDYnVnIHsKICAg ICAgICAgICAgICAgIGZvbnQtc2l6ZTogeC1zbWFsbDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOwog ICAgICAgICAgICAgICAgd2lkdGg6IDMwcHg7IGhlaWdodDogMzBweDsgcGFkZGluZy10b3A6IDJw eDsKICAgICAgICAgICAgICAgIHRleHQtYWxpZ246IGp1c3RpZnk7IHZlcnRpY2FsLWFsaWduOiBt aWRkbGU7CiAgICAgICAgICAgICAgICBiYWNrZ3JvdW5kLWNvbG9yOiAjMDAwOwogICAgICAgIH0K ICAgICAgICB0ZC5SRkNidWcgc3Bhbi5SRkMgewogICAgICAgICAgICAgICAgZm9udC1mYW1pbHk6 IG1vbmFjbywgY2hhcmNvYWwsIGdlbmV2YSwgIk1TIFNhbnMgU2VyaWYiLCBoZWx2ZXRpY2EsIHZl cmRhbmEsIHNhbnMtc2VyaWY7CiAgICAgICAgICAgICAgICBmb250LXdlaWdodDogYm9sZDsgY29s b3I6ICM2NjY7CiAgICAgICAgfQogICAgICAgIHRkLlJGQ2J1ZyBzcGFuLmhvdFRleHQgewogICAg ICAgICAgICAgICAgZm9udC1mYW1pbHk6IGNoYXJjb2FsLCBtb25hY28sIGdlbmV2YSwgIk1TIFNh bnMgU2VyaWYiLCBoZWx2ZXRpY2EsIHZlcmRhbmEsIHNhbnMtc2VyaWY7CiAgICAgICAgICAgICAg ICBmb250LXdlaWdodDogbm9ybWFsOyB0ZXh0LWFsaWduOiBjZW50ZXI7IGNvbG9yOiAjRkZGOwog ICAgICAgIH0KCiAgICAgICAgdGFibGUuVE9DYnVnIHsgd2lkdGg6IDMwcHg7IGhlaWdodDogMTVw eDsgfQogICAgICAgIHRkLlRPQ2J1ZyB7CiAgICAgICAgICAgICAgICB0ZXh0LWFsaWduOiBjZW50 ZXI7IHdpZHRoOiAzMHB4OyBoZWlnaHQ6IDE1cHg7CiAgICAgICAgICAgICAgICBjb2xvcjogI0ZG RjsgYmFja2dyb3VuZC1jb2xvcjogIzkwMDsKICAgICAgICB9CiAgICAgICAgdGQuVE9DYnVnIGEg ewogICAgICAgICAgICAgICAgZm9udC1mYW1pbHk6IG1vbmFjbywgY2hhcmNvYWwsIGdlbmV2YSwg Ik1TIFNhbnMgU2VyaWYiLCBoZWx2ZXRpY2EsIHNhbnMtc2VyaWY7CiAgICAgICAgICAgICAgICBm b250LXdlaWdodDogYm9sZDsgZm9udC1zaXplOiB4LXNtYWxsOyB0ZXh0LWRlY29yYXRpb246IG5v bmU7CiAgICAgICAgICAgICAgICBjb2xvcjogI0ZGRjsgYmFja2dyb3VuZC1jb2xvcjogdHJhbnNw YXJlbnQ7CiAgICAgICAgfQoKICAgICAgICB0ZC5oZWFkZXIgewogICAgICAgICAgICAgICAgZm9u dC1mYW1pbHk6IGFyaWFsLCBoZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogeC1zbWFs bDsKICAgICAgICAgICAgICAgIHZlcnRpY2FsLWFsaWduOiB0b3A7IHdpZHRoOiAzMyU7CiAgICAg ICAgICAgICAgICBjb2xvcjogI0ZGRjsgYmFja2dyb3VuZC1jb2xvcjogIzY2NjsKICAgICAgICB9 CiAgICAgICAgdGQuYXV0aG9yIHsgZm9udC13ZWlnaHQ6IGJvbGQ7IGZvbnQtc2l6ZTogeC1zbWFs bDsgbWFyZ2luLWxlZnQ6IDRlbTsgfQogICAgICAgIHRkLmF1dGhvci10ZXh0IHsgZm9udC1zaXpl OiB4LXNtYWxsOyB9CgogICAgICAgIC8qIGluZm8gY29kZSBmcm9tIFNhbnRhS2xhdXNzIGF0IGh0 dHA6Ly93d3cubWFkYWJvdXRzdHlsZS5jb20vdG9vbHRpcDIuaHRtbCAqLwogICAgICAgIGEuaW5m byB7CiAgICAgICAgICAgICAgICAvKiBUaGlzIGlzIHRoZSBrZXkuICovCiAgICAgICAgICAgICAg ICBwb3NpdGlvbjogcmVsYXRpdmU7CiAgICAgICAgICAgICAgICB6LWluZGV4OiAyNDsKICAgICAg ICAgICAgICAgIHRleHQtZGVjb3JhdGlvbjogbm9uZTsKICAgICAgICB9CiAgICAgICAgYS5pbmZv OmhvdmVyIHsKICAgICAgICAgICAgICAgIHotaW5kZXg6IDI1OwogICAgICAgICAgICAgICAgY29s b3I6ICNGRkY7IGJhY2tncm91bmQtY29sb3I6ICM5MDA7CiAgICAgICAgfQogICAgICAgIGEuaW5m byBzcGFuIHsgZGlzcGxheTogbm9uZTsgfQogICAgICAgIGEuaW5mbzpob3ZlciBzcGFuLmluZm8g ewogICAgICAgICAgICAgICAgLyogVGhlIHNwYW4gd2lsbCBkaXNwbGF5IGp1c3Qgb24gOmhvdmVy IHN0YXRlLiAqLwogICAgICAgICAgICAgICAgZGlzcGxheTogYmxvY2s7CiAgICAgICAgICAgICAg ICBwb3NpdGlvbjogYWJzb2x1dGU7CiAgICAgICAgICAgICAgICBmb250LXNpemU6IHNtYWxsZXI7 CiAgICAgICAgICAgICAgICB0b3A6IDJlbTsgbGVmdDogLTVlbTsgd2lkdGg6IDE1ZW07CiAgICAg ICAgICAgICAgICBwYWRkaW5nOiAycHg7IGJvcmRlcjogMXB4IHNvbGlkICMzMzM7CiAgICAgICAg ICAgICAgICBjb2xvcjogIzkwMDsgYmFja2dyb3VuZC1jb2xvcjogI0VFRTsKICAgICAgICAgICAg ICAgIHRleHQtYWxpZ246IGxlZnQ7CiAgICAgICAgfQoKICAgICAgICBhIHsgZm9udC13ZWlnaHQ6 IGJvbGQ7IH0KICAgICAgICBhOmxpbmsgICAgeyBjb2xvcjogIzkwMDsgYmFja2dyb3VuZC1jb2xv cjogdHJhbnNwYXJlbnQ7IH0KICAgICAgICBhOnZpc2l0ZWQgeyBjb2xvcjogIzYzMzsgYmFja2dy b3VuZC1jb2xvcjogdHJhbnNwYXJlbnQ7IH0KICAgICAgICBhOmFjdGl2ZSAgeyBjb2xvcjogIzYz MzsgYmFja2dyb3VuZC1jb2xvcjogdHJhbnNwYXJlbnQ7IH0KCiAgICAgICAgcCB7IG1hcmdpbi1s ZWZ0OiAyZW07IG1hcmdpbi1yaWdodDogMmVtOyB9CiAgICAgICAgcC5jb3B5cmlnaHQgeyBmb250 LXNpemU6IHgtc21hbGw7IH0KICAgICAgICBwLnRvYyB7IGZvbnQtc2l6ZTogc21hbGw7IGZvbnQt d2VpZ2h0OiBib2xkOyBtYXJnaW4tbGVmdDogM2VtOyB9CiAgICAgICAgdGFibGUudG9jIHsgbWFy Z2luOiAwIDAgMCAzZW07IHBhZGRpbmc6IDA7IGJvcmRlcjogMDsgdmVydGljYWwtYWxpZ246IHRl eHQtdG9wOyB9CiAgICAgICAgdGQudG9jIHsgZm9udC1zaXplOiBzbWFsbDsgZm9udC13ZWlnaHQ6 IGJvbGQ7IHZlcnRpY2FsLWFsaWduOiB0ZXh0LXRvcDsgfQoKICAgICAgICBvbC50ZXh0IHsgbWFy Z2luLWxlZnQ6IDJlbTsgbWFyZ2luLXJpZ2h0OiAyZW07IH0KICAgICAgICB1bC50ZXh0IHsgbWFy Z2luLWxlZnQ6IDJlbTsgbWFyZ2luLXJpZ2h0OiAyZW07IH0KICAgICAgICBsaSAgICAgIHsgbWFy Z2luLWxlZnQ6IDNlbTsgfQoKICAgICAgICAvKiBSRkMtMjYyOSA8c3Bhbng+cyBhbmQgPGFydHdv cms+cy4gKi8KICAgICAgICBlbSAgICAgeyBmb250LXN0eWxlOiBpdGFsaWM7IH0KICAgICAgICBz dHJvbmcgeyBmb250LXdlaWdodDogYm9sZDsgfQogICAgICAgIGRmbiAgICB7IGZvbnQtd2VpZ2h0 OiBib2xkOyBmb250LXN0eWxlOiBub3JtYWw7IH0KICAgICAgICBjaXRlICAgeyBmb250LXdlaWdo dDogbm9ybWFsOyBmb250LXN0eWxlOiBub3JtYWw7IH0KICAgICAgICB0dCAgICAgeyBjb2xvcjog IzAzNjsgfQogICAgICAgIHR0LCBwcmUsIHByZSBkZm4sIHByZSBlbSwgcHJlIGNpdGUsIHByZSBz cGFuIHsKICAgICAgICAgICAgICAgIGZvbnQtZmFtaWx5OiAiQ291cmllciBOZXciLCBDb3VyaWVy LCBtb25vc3BhY2U7IGZvbnQtc2l6ZTogc21hbGw7CiAgICAgICAgfQogICAgICAgIHByZSB7CiAg ICAgICAgICAgICAgICB0ZXh0LWFsaWduOiBsZWZ0OyBwYWRkaW5nOiA0cHg7CiAgICAgICAgICAg ICAgICBjb2xvcjogIzAwMDsgYmFja2dyb3VuZC1jb2xvcjogI0NDQzsKICAgICAgICB9CiAgICAg ICAgcHJlIGRmbiAgeyBjb2xvcjogIzkwMDsgfQogICAgICAgIHByZSBlbSAgIHsgY29sb3I6ICM2 NkY7IGJhY2tncm91bmQtY29sb3I6ICNGRkM7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IH0KICAgICAg ICBwcmUgLmtleSB7IGNvbG9yOiAjMzNDOyBmb250LXdlaWdodDogYm9sZDsgfQogICAgICAgIHBy ZSAuaWQgIHsgY29sb3I6ICM5MDA7IH0KICAgICAgICBwcmUgLnN0ciB7IGNvbG9yOiAjMDAwOyBi YWNrZ3JvdW5kLWNvbG9yOiAjQ0ZGOyB9CiAgICAgICAgcHJlIC52YWwgeyBjb2xvcjogIzA2Njsg fQogICAgICAgIHByZSAucmVwIHsgY29sb3I6ICM5MDk7IH0KICAgICAgICBwcmUgLm90aCB7IGNv bG9yOiAjMDAwOyBiYWNrZ3JvdW5kLWNvbG9yOiAjRkNGOyB9CiAgICAgICAgcHJlIC5lcnIgeyBi YWNrZ3JvdW5kLWNvbG9yOiAjRkNDOyB9CgogICAgICAgIC8qIFJGQy0yNjI5IDx0ZXh0dGFibGU+ cy4gKi8KICAgICAgICB0YWJsZS5hbGwsIHRhYmxlLmZ1bGwsIHRhYmxlLmhlYWRlcnMsIHRhYmxl Lm5vbmUgewogICAgICAgICAgICAgICAgZm9udC1zaXplOiBzbWFsbDsgdGV4dC1hbGlnbjogY2Vu dGVyOyBib3JkZXItd2lkdGg6IDJweDsKICAgICAgICAgICAgICAgIHZlcnRpY2FsLWFsaWduOiB0 b3A7IGJvcmRlci1jb2xsYXBzZTogY29sbGFwc2U7CiAgICAgICAgfQogICAgICAgIHRhYmxlLmFs bCwgdGFibGUuZnVsbCB7IGJvcmRlci1zdHlsZTogc29saWQ7IGJvcmRlci1jb2xvcjogYmxhY2s7 IH0KICAgICAgICB0YWJsZS5oZWFkZXJzLCB0YWJsZS5ub25lIHsgYm9yZGVyLXN0eWxlOiBub25l OyB9CiAgICAgICAgdGggewogICAgICAgICAgICAgICAgZm9udC13ZWlnaHQ6IGJvbGQ7IGJvcmRl ci1jb2xvcjogYmxhY2s7CiAgICAgICAgICAgICAgICBib3JkZXItd2lkdGg6IDJweCAycHggM3B4 IDJweDsKICAgICAgICB9CiAgICAgICAgdGFibGUuYWxsIHRoLCB0YWJsZS5mdWxsIHRoIHsgYm9y ZGVyLXN0eWxlOiBzb2xpZDsgfQogICAgICAgIHRhYmxlLmhlYWRlcnMgdGggeyBib3JkZXItc3R5 bGU6IG5vbmUgbm9uZSBzb2xpZCBub25lOyB9CiAgICAgICAgdGFibGUubm9uZSB0aCB7IGJvcmRl ci1zdHlsZTogbm9uZTsgfQogICAgICAgIHRhYmxlLmFsbCB0ZCB7CiAgICAgICAgICAgICAgICBi b3JkZXItc3R5bGU6IHNvbGlkOyBib3JkZXItY29sb3I6ICMzMzM7CiAgICAgICAgICAgICAgICBi b3JkZXItd2lkdGg6IDFweCAycHg7CiAgICAgICAgfQogICAgICAgIHRhYmxlLmZ1bGwgdGQsIHRh YmxlLmhlYWRlcnMgdGQsIHRhYmxlLm5vbmUgdGQgeyBib3JkZXItc3R5bGU6IG5vbmU7IH0KCiAg ICAgICAgaHIgeyBoZWlnaHQ6IDFweDsgfQogICAgICAgIGhyLmluc2VydCB7CiAgICAgICAgICAg ICAgICB3aWR0aDogODAlOyBib3JkZXItc3R5bGU6IG5vbmU7IGJvcmRlci13aWR0aDogMDsKICAg ICAgICAgICAgICAgIGNvbG9yOiAjQ0NDOyBiYWNrZ3JvdW5kLWNvbG9yOiAjQ0NDOwogICAgICAg IH0KLS0+PC9zdHlsZT4KPC9oZWFkPgo8Ym9keT4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2Vs bHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQi Pjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9h PjwvdGQ+PC90cj48L3RhYmxlPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiB3aWR0aD0iNjYlIiBi b3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMCI+PHRyPjx0ZD48dGFibGUg c3VtbWFyeT0ibGF5b3V0IiB3aWR0aD0iMTAwJSIgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMiIg Y2VsbHNwYWNpbmc9IjEiPgo8dHI+PHRkIGNsYXNzPSJoZWFkZXIiPk9BdXRoIFdvcmtpbmcgR3Jv dXA8L3RkPjx0ZCBjbGFzcz0iaGVhZGVyIj5FLiBIYW1tZXIsIEVkLjwvdGQ+PC90cj4KPHRyPjx0 ZCBjbGFzcz0iaGVhZGVyIj5JbnRlcm5ldC1EcmFmdDwvdGQ+PHRkIGNsYXNzPSJoZWFkZXIiPiZu YnNwOzwvdGQ+PC90cj4KPHRyPjx0ZCBjbGFzcz0iaGVhZGVyIj5PYnNvbGV0ZXM6IDxhIGhyZWY9 J2h0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzU4NDknPjU4NDk8L2E+IChpZiZuYnNwO2Fw cHJvdmVkKTwvdGQ+PHRkIGNsYXNzPSJoZWFkZXIiPkQuIFJlY29yZG9uPC90ZD48L3RyPgo8dHI+ PHRkIGNsYXNzPSJoZWFkZXIiPkludGVuZGVkIHN0YXR1czogU3RhbmRhcmRzIFRyYWNrPC90ZD48 dGQgY2xhc3M9ImhlYWRlciI+RmFjZWJvb2s8L3RkPjwvdHI+Cjx0cj48dGQgY2xhc3M9ImhlYWRl ciI+RXhwaXJlczogRGVjZW1iZXIgMjAsIDIwMTI8L3RkPjx0ZCBjbGFzcz0iaGVhZGVyIj5ELiBI YXJkdDwvdGQ+PC90cj4KPHRyPjx0ZCBjbGFzcz0iaGVhZGVyIj4mbmJzcDs8L3RkPjx0ZCBjbGFz cz0iaGVhZGVyIj5NaWNyb3NvZnQ8L3RkPjwvdHI+Cjx0cj48dGQgY2xhc3M9ImhlYWRlciI+Jm5i c3A7PC90ZD48dGQgY2xhc3M9ImhlYWRlciI+SnVuZSAxOCwgMjAxMjwvdGQ+PC90cj4KPC90YWJs ZT48L3RkPjwvdHI+PC90YWJsZT4KPGgxPjxiciAvPlRoZSBPQXV0aCAyLjAgQXV0aG9yaXphdGlv biBGcmFtZXdvcms8YnIgLz5kcmFmdC1pZXRmLW9hdXRoLXYyLTI4PC9oMT4KCjxoMz5BYnN0cmFj dDwvaDM+Cgo8cD4KICAgICAgICBUaGUgT0F1dGggMi4wIGF1dGhvcml6YXRpb24gZnJhbWV3b3Jr IGVuYWJsZXMgYSB0aGlyZC1wYXJ0eSBhcHBsaWNhdGlvbiB0byBvYnRhaW4gbGltaXRlZAogICAg ICAgIGFjY2VzcyB0byBhbiBIVFRQIHNlcnZpY2UsIGVpdGhlciBvbiBiZWhhbGYgb2YgYSByZXNv dXJjZSBvd25lciBieSBvcmNoZXN0cmF0aW5nIGFuIGFwcHJvdmFsCiAgICAgICAgaW50ZXJhY3Rp b24gYmV0d2VlbiB0aGUgcmVzb3VyY2Ugb3duZXIgYW5kIHRoZSBIVFRQIHNlcnZpY2UsIG9yIGJ5 IGFsbG93aW5nIHRoZSB0aGlyZC1wYXJ0eQogICAgICAgIGFwcGxpY2F0aW9uIHRvIG9idGFpbiBh Y2Nlc3Mgb24gaXRzIG93biBiZWhhbGYuIFRoaXMgc3BlY2lmaWNhdGlvbiByZXBsYWNlcyBhbmQg b2Jzb2xldGVzCiAgICAgICAgdGhlIE9BdXRoIDEuMCBwcm90b2NvbCBkZXNjcmliZWQgaW4gUkZD IDU4NDkuCiAgICAgIAo8L3A+CjxoMz5TdGF0dXMgb2YgdGhpcyBNZW1vPC9oMz4KPHA+ClRoaXMg SW50ZXJuZXQtRHJhZnQgaXMgc3VibWl0dGVkICBpbiBmdWxsCmNvbmZvcm1hbmNlIHdpdGggdGhl IHByb3Zpc2lvbnMgb2YgQkNQJm5ic3A7NzggYW5kIEJDUCZuYnNwOzc5LjwvcD4KPHA+CkludGVy bmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVy aW5nClRhc2sgRm9yY2UgKElFVEYpLiAgTm90ZSB0aGF0IG90aGVyIGdyb3VwcyBtYXkgYWxzbyBk aXN0cmlidXRlCndvcmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LURyYWZ0cy4gIFRoZSBsaXN0 IG9mIGN1cnJlbnQKSW50ZXJuZXQtRHJhZnRzIGlzIGF0IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kcmFmdHMvY3VycmVudC8uPC9wPgo8cD4KSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBk b2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzCmFuZCBtYXkgYmUgdXBk YXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMgYXQgYW55IHRp bWUuCkl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVu Y2UgbWF0ZXJpYWwgb3IgdG8gY2l0ZQp0aGVtIG90aGVyIHRoYW4gYXMgJmxkcXVvO3dvcmsgaW4g cHJvZ3Jlc3MuJnJkcXVvOzwvcD4KPHA+ClRoaXMgSW50ZXJuZXQtRHJhZnQgd2lsbCBleHBpcmUg b24gRGVjZW1iZXIgMjAsIDIwMTIuPC9wPgoKPGgzPkNvcHlyaWdodCBOb3RpY2U8L2gzPgo8cD4K Q29weXJpZ2h0IChjKSAyMDEyIElFVEYgVHJ1c3QgYW5kIHRoZSBwZXJzb25zIGlkZW50aWZpZWQg YXMgdGhlCmRvY3VtZW50IGF1dGhvcnMuICBBbGwgcmlnaHRzIHJlc2VydmVkLjwvcD4KPHA+ClRo aXMgZG9jdW1lbnQgaXMgc3ViamVjdCB0byBCQ1AgNzggYW5kIHRoZSBJRVRGIFRydXN0J3MgTGVn YWwKUHJvdmlzaW9ucyBSZWxhdGluZyB0byBJRVRGIERvY3VtZW50cwooaHR0cDovL3RydXN0ZWUu aWV0Zi5vcmcvbGljZW5zZS1pbmZvKSBpbiBlZmZlY3Qgb24gdGhlIGRhdGUgb2YKcHVibGljYXRp b24gb2YgdGhpcyBkb2N1bWVudC4gIFBsZWFzZSByZXZpZXcgdGhlc2UgZG9jdW1lbnRzCmNhcmVm dWxseSwgYXMgdGhleSBkZXNjcmliZSB5b3VyIHJpZ2h0cyBhbmQgcmVzdHJpY3Rpb25zIHdpdGgg cmVzcGVjdAp0byB0aGlzIGRvY3VtZW50LiBDb2RlIENvbXBvbmVudHMgZXh0cmFjdGVkIGZyb20g dGhpcyBkb2N1bWVudCBtdXN0CmluY2x1ZGUgU2ltcGxpZmllZCBCU0QgTGljZW5zZSB0ZXh0IGFz IGRlc2NyaWJlZCBpbiBTZWN0aW9uIDQuZSBvZgp0aGUgVHJ1c3QgTGVnYWwgUHJvdmlzaW9ucyBh bmQgYXJlIHByb3ZpZGVkIHdpdGhvdXQgd2FycmFudHkgYXMKZGVzY3JpYmVkIGluIHRoZSBTaW1w bGlmaWVkIEJTRCBMaWNlbnNlLjwvcD4KPGEgbmFtZT0idG9jIj48L2E+PGJyIC8+PGhyIC8+Cjxo Mz5UYWJsZSBvZiBDb250ZW50czwvaDM+CjxwIGNsYXNzPSJ0b2MiPgo8YSBocmVmPSIjYW5jaG9y MSI+MS48L2E+Jm5ic3A7CkludHJvZHVjdGlvbjxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJz cDs8YSBocmVmPSIjYW5jaG9yMiI+MS4xLjwvYT4mbmJzcDsKUm9sZXM8YnIgLz4KJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI2FuY2hvcjMiPjEuMi48L2E+Jm5ic3A7ClByb3RvY29s IEZsb3c8YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI2FuY2hvcjQiPjEu My48L2E+Jm5ic3A7CkF1dGhvcml6YXRpb24gR3JhbnQ8YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI2FuY2hvcjUiPjEuMy4xLjwv YT4mbmJzcDsKQXV0aG9yaXphdGlvbiBDb2RlPGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNhbmNob3I2Ij4xLjMuMi48L2E+Jm5i c3A7CkltcGxpY2l0PGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOzxhIGhyZWY9IiNhbmNob3I3Ij4xLjMuMy48L2E+Jm5ic3A7ClJlc291cmNlIE93 bmVyIFBhc3N3b3JkIENyZWRlbnRpYWxzPGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNhbmNob3I4Ij4xLjMuNC48L2E+Jm5ic3A7 CkNsaWVudCBDcmVkZW50aWFsczxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVm PSIjYW5jaG9yOSI+MS40LjwvYT4mbmJzcDsKQWNjZXNzIFRva2VuPGJyIC8+CiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNhbmNob3IxMCI+MS41LjwvYT4mbmJzcDsKUmVmcmVzaCBU b2tlbjxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjdGxzIj4xLjYuPC9h PiZuYnNwOwpUTFMgVmVyc2lvbjxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVm PSIjYW5jaG9yMTEiPjEuNy48L2E+Jm5ic3A7CkhUVFAgUmVkaXJlY3Rpb25zPGJyIC8+CiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNhbmNob3IxMiI+MS44LjwvYT4mbmJzcDsKSW50 ZXJvcGVyYWJpbGl0eTxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjYW5j aG9yMTMiPjEuOS48L2E+Jm5ic3A7Ck5vdGF0aW9uYWwgQ29udmVudGlvbnM8YnIgLz4KPGEgaHJl Zj0iI2FuY2hvcjE0Ij4yLjwvYT4mbmJzcDsKQ2xpZW50IFJlZ2lzdHJhdGlvbjxiciAvPgombmJz cDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjY2xpZW50LXR5cGVzIj4yLjEuPC9hPiZuYnNw OwpDbGllbnQgVHlwZXM8YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI2Ns aWVudC1pZGVudGlmaWVyIj4yLjIuPC9hPiZuYnNwOwpDbGllbnQgSWRlbnRpZmllcjxiciAvPgom bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjY2xpZW50LWF1dGhlbnRpY2F0aW9uIj4y LjMuPC9hPiZuYnNwOwpDbGllbnQgQXV0aGVudGljYXRpb248YnIgLz4KJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI2NsaWVudC1wYXNzd29y ZCI+Mi4zLjEuPC9hPiZuYnNwOwpDbGllbnQgUGFzc3dvcmQ8YnIgLz4KJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI2FuY2hvcjE1Ij4yLjMu Mi48L2E+Jm5ic3A7Ck90aGVyIEF1dGhlbnRpY2F0aW9uIE1ldGhvZHM8YnIgLz4KJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI2FuY2hvcjE2Ij4yLjQuPC9hPiZuYnNwOwpVbnJlZ2lz dGVyZWQgQ2xpZW50czxiciAvPgo8YSBocmVmPSIjYW5jaG9yMTciPjMuPC9hPiZuYnNwOwpQcm90 b2NvbCBFbmRwb2ludHM8YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI2Fu Y2hvcjE4Ij4zLjEuPC9hPiZuYnNwOwpBdXRob3JpemF0aW9uIEVuZHBvaW50PGJyIC8+CiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNyZXNw b25zZS10eXBlIj4zLjEuMS48L2E+Jm5ic3A7ClJlc3BvbnNlIFR5cGU8YnIgLz4KJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI3JlZGlyZWN0 LXVyaSI+My4xLjIuPC9hPiZuYnNwOwpSZWRpcmVjdGlvbiBFbmRwb2ludDxiciAvPgombmJzcDsm bmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjYW5jaG9yMjQiPjMuMi48L2E+Jm5ic3A7ClRva2Vu IEVuZHBvaW50PGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOzxhIGhyZWY9IiN0b2tlbi1lbmRwb2ludC1hdXRoIj4zLjIuMS48L2E+Jm5ic3A7CkNs aWVudCBBdXRoZW50aWNhdGlvbjxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVm PSIjc2NvcGUiPjMuMy48L2E+Jm5ic3A7CkFjY2VzcyBUb2tlbiBTY29wZTxiciAvPgo8YSBocmVm PSIjYW5jaG9yMjUiPjQuPC9hPiZuYnNwOwpPYnRhaW5pbmcgQXV0aG9yaXphdGlvbjxiciAvPgom bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjZ3JhbnQtY29kZSI+NC4xLjwvYT4mbmJz cDsKQXV0aG9yaXphdGlvbiBDb2RlIEdyYW50PGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNjb2RlLWF1dGh6LXJlcSI+NC4xLjEu PC9hPiZuYnNwOwpBdXRob3JpemF0aW9uIFJlcXVlc3Q8YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI2NvZGUtYXV0aHotcmVzcCI+ NC4xLjIuPC9hPiZuYnNwOwpBdXRob3JpemF0aW9uIFJlc3BvbnNlPGJyIC8+CiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiN0b2tlbi1yZXEi PjQuMS4zLjwvYT4mbmJzcDsKQWNjZXNzIFRva2VuIFJlcXVlc3Q8YnIgLz4KJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI2FuY2hvcjI2Ij40 LjEuNC48L2E+Jm5ic3A7CkFjY2VzcyBUb2tlbiBSZXNwb25zZTxiciAvPgombmJzcDsmbmJzcDsm bmJzcDsmbmJzcDs8YSBocmVmPSIjZ3JhbnQtaW1wbGljaXQiPjQuMi48L2E+Jm5ic3A7CkltcGxp Y2l0IEdyYW50PGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOzxhIGhyZWY9IiNpbXBsaWNpdC1hdXRoei1yZXEiPjQuMi4xLjwvYT4mbmJzcDsKQXV0 aG9yaXphdGlvbiBSZXF1ZXN0PGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNpbXBsaWNpdC1hdXRoei1yZXNwIj40LjIuMi48L2E+ Jm5ic3A7CkFjY2VzcyBUb2tlbiBSZXNwb25zZTxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJz cDs8YSBocmVmPSIjZ3JhbnQtcGFzc3dvcmQiPjQuMy48L2E+Jm5ic3A7ClJlc291cmNlIE93bmVy IFBhc3N3b3JkIENyZWRlbnRpYWxzIEdyYW50PGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNhbmNob3IyNyI+NC4zLjEuPC9hPiZu YnNwOwpBdXRob3JpemF0aW9uIFJlcXVlc3QgYW5kIFJlc3BvbnNlPGJyIC8+CiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNwYXNzd29yZC10 b2stcmVxIj40LjMuMi48L2E+Jm5ic3A7CkFjY2VzcyBUb2tlbiBSZXF1ZXN0PGJyIC8+CiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNhbmNo b3IyOCI+NC4zLjMuPC9hPiZuYnNwOwpBY2Nlc3MgVG9rZW4gUmVzcG9uc2U8YnIgLz4KJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI2dyYW50LWNsaWVudCI+NC40LjwvYT4mbmJzcDsK Q2xpZW50IENyZWRlbnRpYWxzIEdyYW50PGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNhbmNob3IyOSI+NC40LjEuPC9hPiZuYnNw OwpBdXRob3JpemF0aW9uIFJlcXVlc3QgYW5kIFJlc3BvbnNlPGJyIC8+CiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNjbGllbnQtcmVxIj40 LjQuMi48L2E+Jm5ic3A7CkFjY2VzcyBUb2tlbiBSZXF1ZXN0PGJyIC8+CiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNhbmNob3IzMCI+NC40 LjMuPC9hPiZuYnNwOwpBY2Nlc3MgVG9rZW4gUmVzcG9uc2U8YnIgLz4KJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7PGEgaHJlZj0iI2V4dC1ncmFudCI+NC41LjwvYT4mbmJzcDsKRXh0ZW5zaW9uIEdy YW50czxiciAvPgo8YSBocmVmPSIjdG9rZW4taXNzdWUiPjUuPC9hPiZuYnNwOwpJc3N1aW5nIGFu IEFjY2VzcyBUb2tlbjxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjdG9r ZW4tcmVzcG9uc2UiPjUuMS48L2E+Jm5ic3A7ClN1Y2Nlc3NmdWwgUmVzcG9uc2U8YnIgLz4KJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI3Rva2VuLWVycm9ycyI+NS4yLjwvYT4mbmJz cDsKRXJyb3IgUmVzcG9uc2U8YnIgLz4KPGEgaHJlZj0iI3Rva2VuLXJlZnJlc2giPjYuPC9hPiZu YnNwOwpSZWZyZXNoaW5nIGFuIEFjY2VzcyBUb2tlbjxiciAvPgo8YSBocmVmPSIjYWNjZXNzLXJl c291cmNlIj43LjwvYT4mbmJzcDsKQWNjZXNzaW5nIFByb3RlY3RlZCBSZXNvdXJjZXM8YnIgLz4K Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI3Rva2VuLXR5cGVzIj43LjEuPC9hPiZu YnNwOwpBY2Nlc3MgVG9rZW4gVHlwZXM8YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEg aHJlZj0iI3Jlc291cmNlLWVycm9ycyI+Ny4yLjwvYT4mbmJzcDsKRXJyb3IgUmVzcG9uc2U8YnIg Lz4KPGEgaHJlZj0iI2V4dGVuc2lvbnMiPjguPC9hPiZuYnNwOwpFeHRlbnNpYmlsaXR5PGJyIC8+ CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNuZXctdHlwZXMiPjguMS48L2E+Jm5i c3A7CkRlZmluaW5nIEFjY2VzcyBUb2tlbiBUeXBlczxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsm bmJzcDs8YSBocmVmPSIjZW5kcG9pbnQtcGFyYW1zIj44LjIuPC9hPiZuYnNwOwpEZWZpbmluZyBO ZXcgRW5kcG9pbnQgUGFyYW1ldGVyczxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBo cmVmPSIjYW5jaG9yMzEiPjguMy48L2E+Jm5ic3A7CkRlZmluaW5nIE5ldyBBdXRob3JpemF0aW9u IEdyYW50IFR5cGVzPGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNyZXNw b25zZS10eXBlLWV4dCI+OC40LjwvYT4mbmJzcDsKRGVmaW5pbmcgTmV3IEF1dGhvcml6YXRpb24g RW5kcG9pbnQgUmVzcG9uc2UgVHlwZXM8YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEg aHJlZj0iI25ldy1lcnJvcnMiPjguNS48L2E+Jm5ic3A7CkRlZmluaW5nIEFkZGl0aW9uYWwgRXJy b3IgQ29kZXM8YnIgLz4KPGEgaHJlZj0iI2FuY2hvcjMyIj45LjwvYT4mbmJzcDsKTmF0aXZlIEFw cGxpY2F0aW9uczxiciAvPgo8YSBocmVmPSIjYW5jaG9yMzMiPjEwLjwvYT4mbmJzcDsKU2VjdXJp dHkgQ29uc2lkZXJhdGlvbnM8YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0i I2FuY2hvcjM0Ij4xMC4xLjwvYT4mbmJzcDsKQ2xpZW50IEF1dGhlbnRpY2F0aW9uPGJyIC8+CiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNhbmNob3IzNSI+MTAuMi48L2E+Jm5ic3A7 CkNsaWVudCBJbXBlcnNvbmF0aW9uPGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhy ZWY9IiNhbmNob3IzNiI+MTAuMy48L2E+Jm5ic3A7CkFjY2VzcyBUb2tlbnM8YnIgLz4KJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI2FuY2hvcjM3Ij4xMC40LjwvYT4mbmJzcDsKUmVm cmVzaCBUb2tlbnM8YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI2FuY2hv cjM4Ij4xMC41LjwvYT4mbmJzcDsKQXV0aG9yaXphdGlvbiBDb2RlczxiciAvPgombmJzcDsmbmJz cDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjYW5jaG9yMzkiPjEwLjYuPC9hPiZuYnNwOwpBdXRob3Jp emF0aW9uIENvZGUgUmVkaXJlY3Rpb24gVVJJIE1hbmlwdWxhdGlvbjxiciAvPgombmJzcDsmbmJz cDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjYW5jaG9yNDAiPjEwLjcuPC9hPiZuYnNwOwpSZXNvdXJj ZSBPd25lciBQYXNzd29yZCBDcmVkZW50aWFsczxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJz cDs8YSBocmVmPSIjYW5jaG9yNDEiPjEwLjguPC9hPiZuYnNwOwpSZXF1ZXN0IENvbmZpZGVudGlh bGl0eTxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjYW5jaG9yNDIiPjEw LjkuPC9hPiZuYnNwOwpFbmRwb2ludHMgQXV0aGVudGljaXR5PGJyIC8+CiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOzxhIGhyZWY9IiNhbnRocm9weSI+MTAuMTAuPC9hPiZuYnNwOwpDcmVkZW50aWFs cyBHdWVzc2luZyBBdHRhY2tzPGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9 IiNhbmNob3I0MyI+MTAuMTEuPC9hPiZuYnNwOwpQaGlzaGluZyBBdHRhY2tzPGJyIC8+CiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNDU1JGIj4xMC4xMi48L2E+Jm5ic3A7CkNyb3Nz LVNpdGUgUmVxdWVzdCBGb3JnZXJ5PGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhy ZWY9IiNhbmNob3I0NCI+MTAuMTMuPC9hPiZuYnNwOwpDbGlja2phY2tpbmc8YnIgLz4KJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI2FuY2hvcjQ1Ij4xMC4xNC48L2E+Jm5ic3A7CkNv ZGUgSW5qZWN0aW9uIGFuZCBJbnB1dCBWYWxpZGF0aW9uPGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOzxhIGhyZWY9IiNvcGVuLXJlZGlyZWN0Ij4xMC4xNS48L2E+Jm5ic3A7Ck9wZW4gUmVk aXJlY3RvcnM8YnIgLz4KPGEgaHJlZj0iI2FuY2hvcjQ2Ij4xMS48L2E+Jm5ic3A7CklBTkEgQ29u c2lkZXJhdGlvbnM8YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI3R5cGUt cmVnaXN0cnkiPjExLjEuPC9hPiZuYnNwOwpUaGUgT0F1dGggQWNjZXNzIFRva2VuIFR5cGUgUmVn aXN0cnk8YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7PGEgaHJlZj0iI2FuY2hvcjQ3Ij4xMS4xLjEuPC9hPiZuYnNwOwpSZWdpc3RyYXRpb24gVGVt cGxhdGU8YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI3BhcmFtZXRlcnMt cmVnaXN0cnkiPjExLjIuPC9hPiZuYnNwOwpUaGUgT0F1dGggUGFyYW1ldGVycyBSZWdpc3RyeTxi ciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBo cmVmPSIjYW5jaG9yNDgiPjExLjIuMS48L2E+Jm5ic3A7ClJlZ2lzdHJhdGlvbiBUZW1wbGF0ZTxi ciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBo cmVmPSIjYW5jaG9yNDkiPjExLjIuMi48L2E+Jm5ic3A7CkluaXRpYWwgUmVnaXN0cnkgQ29udGVu dHM8YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI3Jlc3BvbnNlLXR5cGUt cmVnaXN0cnkiPjExLjMuPC9hPiZuYnNwOwpUaGUgT0F1dGggQXV0aG9yaXphdGlvbiBFbmRwb2lu dCBSZXNwb25zZSBUeXBlIFJlZ2lzdHJ5PGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNhbmNob3I1MCI+MTEuMy4xLjwvYT4mbmJz cDsKUmVnaXN0cmF0aW9uIFRlbXBsYXRlPGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNhbmNob3I1MSI+MTEuMy4yLjwvYT4mbmJz cDsKSW5pdGlhbCBSZWdpc3RyeSBDb250ZW50czxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJz cDs8YSBocmVmPSIjZXJyb3ItcmVnaXN0cnkiPjExLjQuPC9hPiZuYnNwOwpUaGUgT0F1dGggRXh0 ZW5zaW9ucyBFcnJvciBSZWdpc3RyeTxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjYW5jaG9yNTIiPjExLjQuMS48L2E+Jm5ic3A7 ClJlZ2lzdHJhdGlvbiBUZW1wbGF0ZTxiciAvPgo8YSBocmVmPSIjcmZjLnJlZmVyZW5jZXMxIj4x Mi48L2E+Jm5ic3A7ClJlZmVyZW5jZXM8YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEg aHJlZj0iI3JmYy5yZWZlcmVuY2VzMSI+MTIuMS48L2E+Jm5ic3A7Ck5vcm1hdGl2ZSBSZWZlcmVu Y2VzPGJyIC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNyZmMucmVmZXJlbmNl czIiPjEyLjIuPC9hPiZuYnNwOwpJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzPGJyIC8+CjxhIGhyZWY9 IiNhbmNob3I1NSI+QXBwZW5kaXgmbmJzcDtBLjwvYT4mbmJzcDsKQXVnbWVudGVkIEJhY2t1cy1O YXVyIEZvcm0gKEFCTkYpIFN5bnRheDxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBo cmVmPSIjYW5jaG9yNTYiPkEuMS48L2E+Jm5ic3A7CiJjbGllbnRfaWQiIFN5bnRheDxiciAvPgom bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjYW5jaG9yNTciPkEuMi48L2E+Jm5ic3A7 CiJjbGllbnRfc2VjcmV0IiBTeW50YXg8YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEg aHJlZj0iI2FuY2hvcjU4Ij5BLjMuPC9hPiZuYnNwOwoicmVzcG9uc2VfdHlwZSIgU3ludGF4PGJy IC8+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNhbmNob3I1OSI+QS40LjwvYT4m bmJzcDsKInNjb3BlIiBTeW50YXg8YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJl Zj0iI2FuY2hvcjYwIj5BLjUuPC9hPiZuYnNwOwoic3RhdGUiIFN5bnRheDxiciAvPgombmJzcDsm bmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjYW5jaG9yNjEiPkEuNi48L2E+Jm5ic3A7CiJyZWRp cmVjdF91cmkiIFN5bnRheDxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIj YW5jaG9yNjIiPkEuNy48L2E+Jm5ic3A7CiJlcnJvciIgU3ludGF4PGJyIC8+CiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNhbmNob3I2MyI+QS44LjwvYT4mbmJzcDsKImVycm9yX2Rl c2NyaXB0aW9uIiBTeW50YXg8YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0i I2FuY2hvcjY0Ij5BLjkuPC9hPiZuYnNwOwoiZXJyb3JfdXJpIiBTeW50YXg8YnIgLz4KJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI2FuY2hvcjY1Ij5BLjEwLjwvYT4mbmJzcDsKImdy YW50X3R5cGUiIFN5bnRheDxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIj YW5jaG9yNjYiPkEuMTEuPC9hPiZuYnNwOwoiY29kZSIgU3ludGF4PGJyIC8+CiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNhbmNob3I2NyI+QS4xMi48L2E+Jm5ic3A7CiJhY2Nlc3Nf dG9rZW4iIFN5bnRheDxiciAvPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjYW5j aG9yNjgiPkEuMTMuPC9hPiZuYnNwOwoidG9rZW5fdHlwZSIgU3ludGF4PGJyIC8+CiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNhbmNob3I2OSI+QS4xNC48L2E+Jm5ic3A7CiJleHBp cmVzX2luIiBTeW50YXg8YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI2Fu Y2hvcjcwIj5BLjE1LjwvYT4mbmJzcDsKInVzZXJuYW1lIiBTeW50YXg8YnIgLz4KJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI2FuY2hvcjcxIj5BLjE2LjwvYT4mbmJzcDsKInBhc3N3 b3JkIiBTeW50YXg8YnIgLz4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI2FuY2hv cjcyIj5BLjE3LjwvYT4mbmJzcDsKInJlZnJlc2hfdG9rZW4iIFN5bnRheDxiciAvPgombmJzcDsm bmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjYW5jaG9yNzMiPkEuMTguPC9hPiZuYnNwOwpFbmRw b2ludCBQYXJhbWV0ZXIgU3ludGF4PGJyIC8+CjxhIGhyZWY9IiNhbmNob3I3NCI+QXBwZW5kaXgm bmJzcDtCLjwvYT4mbmJzcDsKQWNrbm93bGVkZ2VtZW50czxiciAvPgo8YSBocmVmPSIjYW5jaG9y NzUiPkFwcGVuZGl4Jm5ic3A7Qy48L2E+Jm5ic3A7CkVkaXRvcidzIE5vdGVzPGJyIC8+CjxhIGhy ZWY9IiNyZmMuYXV0aG9ycyI+JiMxNjc7PC9hPiZuYnNwOwpBdXRob3JzJyBBZGRyZXNzZXM8YnIg Lz4KPC9wPgo8YnIgY2xlYXI9ImFsbCIgLz4KCjxhIG5hbWU9ImFuY2hvcjEiPjwvYT48YnIgLz48 aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5n PSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+ PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBu YW1lPSJyZmMuc2VjdGlvbi4xIj48L2E+PGgzPjEuJm5ic3A7CkludHJvZHVjdGlvbjwvaDM+Cgo8 cD4KICAgICAgICBJbiB0aGUgdHJhZGl0aW9uYWwgY2xpZW50LXNlcnZlciBhdXRoZW50aWNhdGlv biBtb2RlbCwgdGhlIGNsaWVudCByZXF1ZXN0cyBhbiBhY2Nlc3MKICAgICAgICByZXN0cmljdGVk IHJlc291cmNlIChwcm90ZWN0ZWQgcmVzb3VyY2UpIG9uIHRoZSBzZXJ2ZXIgYnkgYXV0aGVudGlj YXRpbmcgd2l0aCB0aGUgc2VydmVyCiAgICAgICAgdXNpbmcgdGhlIHJlc291cmNlIG93bmVyJ3Mg Y3JlZGVudGlhbHMuIEluIG9yZGVyIHRvIHByb3ZpZGUgdGhpcmQtcGFydHkgYXBwbGljYXRpb25z IGFjY2VzcwogICAgICAgIHRvIHJlc3RyaWN0ZWQgcmVzb3VyY2VzLCB0aGUgcmVzb3VyY2Ugb3du ZXIgc2hhcmVzIGl0cyBjcmVkZW50aWFscyB3aXRoIHRoZSB0aGlyZC1wYXJ0eS4KICAgICAgICBU aGlzIGNyZWF0ZXMgc2V2ZXJhbCBwcm9ibGVtcyBhbmQgbGltaXRhdGlvbnM6CiAgICAgIAo8L3A+ CjxwPgogICAgICAgIDwvcD4KPHVsIGNsYXNzPSJ0ZXh0Ij4KPGxpPgogICAgICAgICAgICBUaGly ZC1wYXJ0eSBhcHBsaWNhdGlvbnMgYXJlIHJlcXVpcmVkIHRvIHN0b3JlIHRoZSByZXNvdXJjZSBv d25lcidzIGNyZWRlbnRpYWxzCiAgICAgICAgICAgIGZvciBmdXR1cmUgdXNlLCB0eXBpY2FsbHkg YSBwYXNzd29yZCBpbiBjbGVhci10ZXh0LgogICAgICAgICAgCjwvbGk+CjxsaT4KICAgICAgICAg ICAgU2VydmVycyBhcmUgcmVxdWlyZWQgdG8gc3VwcG9ydCBwYXNzd29yZCBhdXRoZW50aWNhdGlv biwgZGVzcGl0ZSB0aGUgc2VjdXJpdHkKICAgICAgICAgICAgd2Vha25lc3NlcyBpbmhlcmVudCBp biBwYXNzd29yZHMuCiAgICAgICAgICAKPC9saT4KPGxpPgogICAgICAgICAgICBUaGlyZC1wYXJ0 eSBhcHBsaWNhdGlvbnMgZ2FpbiBvdmVybHkgYnJvYWQgYWNjZXNzIHRvIHRoZSByZXNvdXJjZSBv d25lcidzIHByb3RlY3RlZAogICAgICAgICAgICByZXNvdXJjZXMsIGxlYXZpbmcgcmVzb3VyY2Ug b3duZXJzIHdpdGhvdXQgYW55IGFiaWxpdHkgdG8gcmVzdHJpY3QgZHVyYXRpb24gb3IgYWNjZXNz CiAgICAgICAgICAgIHRvIGEgbGltaXRlZCBzdWJzZXQgb2YgcmVzb3VyY2VzLgogICAgICAgICAg CjwvbGk+CjxsaT4KICAgICAgICAgICAgUmVzb3VyY2Ugb3duZXJzIGNhbm5vdCByZXZva2UgYWNj ZXNzIHRvIGFuIGluZGl2aWR1YWwgdGhpcmQtcGFydHkgd2l0aG91dCByZXZva2luZwogICAgICAg ICAgICBhY2Nlc3MgdG8gYWxsIHRoaXJkLXBhcnRpZXMsIGFuZCBtdXN0IGRvIHNvIGJ5IGNoYW5n aW5nIHRoZWlyIHBhc3N3b3JkLgogICAgICAgICAgCjwvbGk+CjxsaT4KICAgICAgICAgICAgQ29t cHJvbWlzZSBvZiBhbnkgdGhpcmQtcGFydHkgYXBwbGljYXRpb24gcmVzdWx0cyBpbiBjb21wcm9t aXNlIG9mIHRoZSBlbmQtdXNlcidzCiAgICAgICAgICAgIHBhc3N3b3JkIGFuZCBhbGwgb2YgdGhl IGRhdGEgcHJvdGVjdGVkIGJ5IHRoYXQgcGFzc3dvcmQuCiAgICAgICAgICAKPC9saT4KPC91bD48 cD4KICAgICAgCjwvcD4KPHA+CiAgICAgICAgT0F1dGggYWRkcmVzc2VzIHRoZXNlIGlzc3VlcyBi eSBpbnRyb2R1Y2luZyBhbiBhdXRob3JpemF0aW9uIGxheWVyIGFuZCBzZXBhcmF0aW5nIHRoZSBy b2xlCiAgICAgICAgb2YgdGhlIGNsaWVudCBmcm9tIHRoYXQgb2YgdGhlIHJlc291cmNlIG93bmVy LiBJbiBPQXV0aCwgdGhlIGNsaWVudCByZXF1ZXN0cyBhY2Nlc3MgdG8KICAgICAgICByZXNvdXJj ZXMgY29udHJvbGxlZCBieSB0aGUgcmVzb3VyY2Ugb3duZXIgYW5kIGhvc3RlZCBieSB0aGUgcmVz b3VyY2Ugc2VydmVyLCBhbmQgaXMgaXNzdWVkCiAgICAgICAgYSBkaWZmZXJlbnQgc2V0IG9mIGNy ZWRlbnRpYWxzIHRoYW4gdGhvc2Ugb2YgdGhlIHJlc291cmNlIG93bmVyLgogICAgICAKPC9wPgo8 cD4KICAgICAgICBJbnN0ZWFkIG9mIHVzaW5nIHRoZSByZXNvdXJjZSBvd25lcidzIGNyZWRlbnRp YWxzIHRvIGFjY2VzcyBwcm90ZWN0ZWQgcmVzb3VyY2VzLCB0aGUgY2xpZW50CiAgICAgICAgb2J0 YWlucyBhbiBhY2Nlc3MgdG9rZW4gLSBhIHN0cmluZyBkZW5vdGluZyBhIHNwZWNpZmljIHNjb3Bl LCBsaWZldGltZSwgYW5kIG90aGVyIGFjY2VzcwogICAgICAgIGF0dHJpYnV0ZXMuIEFjY2VzcyB0 b2tlbnMgYXJlIGlzc3VlZCB0byB0aGlyZC1wYXJ0eSBjbGllbnRzIGJ5IGFuIGF1dGhvcml6YXRp b24gc2VydmVyIHdpdGgKICAgICAgICB0aGUgYXBwcm92YWwgb2YgdGhlIHJlc291cmNlIG93bmVy LiBUaGUgY2xpZW50IHVzZXMgdGhlIGFjY2VzcyB0b2tlbiB0byBhY2Nlc3MgdGhlCiAgICAgICAg cHJvdGVjdGVkIHJlc291cmNlcyBob3N0ZWQgYnkgdGhlIHJlc291cmNlIHNlcnZlci4KICAgICAg CjwvcD4KPHA+CiAgICAgICAgRm9yIGV4YW1wbGUsIGFuIGVuZC11c2VyIChyZXNvdXJjZSBvd25l cikgY2FuIGdyYW50IGEgcHJpbnRpbmcgc2VydmljZSAoY2xpZW50KSBhY2Nlc3MKICAgICAgICB0 byBoZXIgcHJvdGVjdGVkIHBob3RvcyBzdG9yZWQgYXQgYSBwaG90byBzaGFyaW5nIHNlcnZpY2Ug KHJlc291cmNlIHNlcnZlciksIHdpdGhvdXQKICAgICAgICBzaGFyaW5nIGhlciB1c2VybmFtZSBh bmQgcGFzc3dvcmQgd2l0aCB0aGUgcHJpbnRpbmcgc2VydmljZS4gSW5zdGVhZCwgc2hlIGF1dGhl bnRpY2F0ZXMKICAgICAgICBkaXJlY3RseSB3aXRoIGEgc2VydmVyIHRydXN0ZWQgYnkgdGhlIHBo b3RvIHNoYXJpbmcgc2VydmljZSAoYXV0aG9yaXphdGlvbiBzZXJ2ZXIpIHdoaWNoCiAgICAgICAg aXNzdWVzIHRoZSBwcmludGluZyBzZXJ2aWNlIGRlbGVnYXRpb24tc3BlY2lmaWMgY3JlZGVudGlh bHMgKGFjY2VzcyB0b2tlbikuCiAgICAgIAo8L3A+CjxwPgogICAgICAgIFRoaXMgc3BlY2lmaWNh dGlvbiBpcyBkZXNpZ25lZCBmb3IgdXNlIHdpdGggSFRUUCAoPGEgY2xhc3M9J2luZm8nIGhyZWY9 JyNSRkMyNjE2Jz5bUkZDMjYxNl08c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+Rmll bGRpbmcsIFIuLCBHZXR0eXMsIEouLCBNb2d1bCwgSi4sIEZyeXN0eWssIEguLCBNYXNpbnRlciwg TC4sIExlYWNoLCBQLiwgYW5kIFQuIEJlcm5lcnMtTGVlLCAmbGRxdW87SHlwZXJ0ZXh0IFRyYW5z ZmVyIFByb3RvY29sIC0tIEhUVFAvMS4xLCZyZHF1bzsgSnVuZSZuYnNwOzE5OTkuPC9zcGFuPjxz cGFuPik8L3NwYW4+PC9hPikuIFRoZSB1c2Ugb2YKICAgICAgICBPQXV0aCBvdmVyIGFueSBvdGhl ciBwcm90b2NvbCB0aGFuIEhUVFAgaXMgb3V0IG9mIHNjb3BlLgogICAgICAKPC9wPgo8cD4KICAg ICAgICBUaGUgT0F1dGggMS4wIHByb3RvY29sICg8YSBjbGFzcz0naW5mbycgaHJlZj0nI1JGQzU4 NDknPltSRkM1ODQ5XTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5IYW1tZXItTGFo YXYsIEUuLCAmbGRxdW87VGhlIE9BdXRoIDEuMCBQcm90b2NvbCwmcmRxdW87IEFwcmlsJm5ic3A7 MjAxMC48L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+KSwgcHVibGlzaGVkIGFzIGFuIGluZm9ybWF0 aW9uYWwgZG9jdW1lbnQsCiAgICAgICAgd2FzIHRoZSByZXN1bHQgb2YgYSBzbWFsbCBhZC1ob2Mg Y29tbXVuaXR5IGVmZm9ydC4gVGhpcyBzdGFuZGFyZHMtdHJhY2sgc3BlY2lmaWNhdGlvbiBidWls ZHMKICAgICAgICBvbiB0aGUgT0F1dGggMS4wIGRlcGxveW1lbnQgZXhwZXJpZW5jZSwgYXMgd2Vs bCBhcyBhZGRpdGlvbmFsIHVzZSBjYXNlcyBhbmQgZXh0ZW5zaWJpbGl0eQogICAgICAgIHJlcXVp cmVtZW50cyBnYXRoZXJlZCBmcm9tIHRoZSB3aWRlciBJRVRGIGNvbW11bml0eS4gVGhlIE9BdXRo IDIuMCBwcm90b2NvbCBpcyBub3QgYmFja3dhcmQKICAgICAgICBjb21wYXRpYmxlIHdpdGggT0F1 dGggMS4wLiBUaGUgdHdvIHZlcnNpb25zIG1heSBjby1leGlzdCBvbiB0aGUgbmV0d29yayBhbmQg aW1wbGVtZW50YXRpb25zCiAgICAgICAgbWF5IGNob29zZSB0byBzdXBwb3J0IGJvdGguIEhvd2V2 ZXIsIGl0IGlzIHRoZSBpbnRlbnRpb24gb2YgdGhpcyBzcGVjaWZpY2F0aW9uIHRoYXQgbmV3CiAg ICAgICAgaW1wbGVtZW50YXRpb24gc3VwcG9ydCBPQXV0aCAyLjAgYXMgc3BlY2lmaWVkIGluIHRo aXMgZG9jdW1lbnQsIGFuZCB0aGF0IE9BdXRoIDEuMCBpcyB1c2VkCiAgICAgICAgb25seSB0byBz dXBwb3J0IGV4aXN0aW5nIGRlcGxveW1lbnRzLiBUaGUgT0F1dGggMi4wIHByb3RvY29sIHNoYXJl cyB2ZXJ5IGZldyBpbXBsZW1lbnRhdGlvbgogICAgICAgIGRldGFpbHMgd2l0aCB0aGUgT0F1dGgg MS4wIHByb3RvY29sLiBJbXBsZW1lbnRlcnMgZmFtaWxpYXIgd2l0aCBPQXV0aCAxLjAgc2hvdWxk IGFwcHJvYWNoCiAgICAgICAgdGhpcyBkb2N1bWVudCB3aXRob3V0IGFueSBhc3N1bXB0aW9ucyBh cyB0byBpdHMgc3RydWN0dXJlIGFuZCBkZXRhaWxzLgogICAgICAKPC9wPgo8YSBuYW1lPSJhbmNo b3IyIj48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5n PSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRk IGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwv dHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uMS4xIj48L2E+PGgzPjEuMS4mbmJzcDsK Um9sZXM8L2gzPgoKPHA+CiAgICAgICAgICBPQXV0aCBkZWZpbmVzIGZvdXIgcm9sZXM6CiAgICAg ICAgCjwvcD4KPHA+CiAgICAgICAgICA8L3A+CjxibG9ja3F1b3RlIGNsYXNzPSJ0ZXh0Ij48ZGw+ CjxkdD5yZXNvdXJjZSBvd25lcjwvZHQ+CjxkZD4KICAgICAgICAgICAgICAKICAgICAgICAgICAg ICBBbiBlbnRpdHkgY2FwYWJsZSBvZiBncmFudGluZyBhY2Nlc3MgdG8gYSBwcm90ZWN0ZWQgcmVz b3VyY2UuIFdoZW4gdGhlIHJlc291cmNlIG93bmVyCiAgICAgICAgICAgICAgaXMgYSBwZXJzb24s IGl0IGlzIHJlZmVycmVkIHRvIGFzIGFuIGVuZC11c2VyLgogICAgICAgICAgICAKPC9kZD4KPGR0 PnJlc291cmNlIHNlcnZlcjwvZHQ+CjxkZD4KICAgICAgICAgICAgICAKICAgICAgICAgICAgICBU aGUgc2VydmVyIGhvc3RpbmcgdGhlIHByb3RlY3RlZCByZXNvdXJjZXMsIGNhcGFibGUgb2YgYWNj ZXB0aW5nIGFuZCByZXNwb25kaW5nIHRvCiAgICAgICAgICAgICAgcHJvdGVjdGVkIHJlc291cmNl IHJlcXVlc3RzIHVzaW5nIGFjY2VzcyB0b2tlbnMuCiAgICAgICAgICAgIAo8L2RkPgo8ZHQ+Y2xp ZW50PC9kdD4KPGRkPgogICAgICAgICAgICAgIAogICAgICAgICAgICAgIEFuIGFwcGxpY2F0aW9u IG1ha2luZyBwcm90ZWN0ZWQgcmVzb3VyY2UgcmVxdWVzdHMgb24gYmVoYWxmIG9mIHRoZSByZXNv dXJjZSBvd25lciBhbmQKICAgICAgICAgICAgICB3aXRoIGl0cyBhdXRob3JpemF0aW9uLiBUaGUg dGVybSBjbGllbnQgZG9lcyBub3QgaW1wbHkgYW55IHBhcnRpY3VsYXIgaW1wbGVtZW50YXRpb24K ICAgICAgICAgICAgICBjaGFyYWN0ZXJpc3RpY3MgKGUuZy4gd2hldGhlciB0aGUgYXBwbGljYXRp b24gZXhlY3V0ZXMgb24gYSBzZXJ2ZXIsIGEgZGVza3RvcCwgb3IKICAgICAgICAgICAgICBvdGhl ciBkZXZpY2VzKS4KICAgICAgICAgICAgCjwvZGQ+CjxkdD5hdXRob3JpemF0aW9uIHNlcnZlcjwv ZHQ+CjxkZD4KICAgICAgICAgICAgICAKICAgICAgICAgICAgICBUaGUgc2VydmVyIGlzc3Vpbmcg YWNjZXNzIHRva2VucyB0byB0aGUgY2xpZW50IGFmdGVyIHN1Y2Nlc3NmdWxseSBhdXRoZW50aWNh dGluZyB0aGUKICAgICAgICAgICAgICByZXNvdXJjZSBvd25lciBhbmQgb2J0YWluaW5nIGF1dGhv cml6YXRpb24uCiAgICAgICAgICAgIAo8L2RkPgo8L2RsPjwvYmxvY2txdW90ZT48cD4KICAgICAg ICAKPC9wPgo8cD4KICAgICAgICAgIFRoZSBpbnRlcmFjdGlvbiBiZXR3ZWVuIHRoZSBhdXRob3Jp emF0aW9uIHNlcnZlciBhbmQgcmVzb3VyY2Ugc2VydmVyIGlzIGJleW9uZCB0aGUgc2NvcGUKICAg ICAgICAgIG9mIHRoaXMgc3BlY2lmaWNhdGlvbi4gVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIG1h eSBiZSB0aGUgc2FtZSBzZXJ2ZXIgYXMgdGhlIHJlc291cmNlCiAgICAgICAgICBzZXJ2ZXIgb3Ig YSBzZXBhcmF0ZSBlbnRpdHkuIEEgc2luZ2xlIGF1dGhvcml6YXRpb24gc2VydmVyIG1heSBpc3N1 ZSBhY2Nlc3MgdG9rZW5zCiAgICAgICAgICBhY2NlcHRlZCBieSBtdWx0aXBsZSByZXNvdXJjZSBz ZXJ2ZXJzLgogICAgICAgIAo8L3A+CjxhIG5hbWU9ImFuY2hvcjMiPjwvYT48YnIgLz48aHIgLz4K PHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBj bGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJl Zj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJy ZmMuc2VjdGlvbi4xLjIiPjwvYT48aDM+MS4yLiZuYnNwOwpQcm90b2NvbCBGbG93PC9oMz4KPGJy IC8+PGhyIGNsYXNzPSJpbnNlcnQiIC8+CjxhIG5hbWU9IkZpZ3VyZS0xIj48L2E+CjxkaXYgc3R5 bGU9J2Rpc3BsYXk6IHRhYmxlOyB3aWR0aDogMDsgbWFyZ2luLWxlZnQ6IDNlbTsgbWFyZ2luLXJp Z2h0OiBhdXRvJz48cHJlPgoKICArLS0tLS0tLS0rICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICstLS0tLS0tLS0tLS0tLS0rCiAgfCAgICAgICAgfC0tKEEpLSBBdXRob3JpemF0aW9uIFJl cXVlc3QgLSZndDt8ICAgUmVzb3VyY2UgICAgfAogIHwgICAgICAgIHwgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgfCAgICAgT3duZXIgICAgIHwKICB8ICAgICAgICB8Jmx0Oy0oQiktLSBB dXRob3JpemF0aW9uIEdyYW50IC0tLXwgICAgICAgICAgICAgICB8CiAgfCAgICAgICAgfCAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tKwogIHwgICAgICAgIHwK ICB8ICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0t LS0rCiAgfCAgICAgICAgfC0tKEMpLS0gQXV0aG9yaXphdGlvbiBHcmFudCAtLSZndDt8IEF1dGhv cml6YXRpb24gfAogIHwgQ2xpZW50IHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAg ICAgU2VydmVyICAgIHwKICB8ICAgICAgICB8Jmx0Oy0oRCktLS0tLSBBY2Nlc3MgVG9rZW4gLS0t LS0tLXwgICAgICAgICAgICAgICB8CiAgfCAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICArLS0tLS0tLS0tLS0tLS0tKwogIHwgICAgICAgIHwKICB8ICAgICAgICB8ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0rCiAgfCAgICAgICAgfC0t KEUpLS0tLS0gQWNjZXNzIFRva2VuIC0tLS0tLSZndDt8ICAgIFJlc291cmNlICAgfAogIHwgICAg ICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgU2VydmVyICAgIHwKICB8 ICAgICAgICB8Jmx0Oy0oRiktLS0gUHJvdGVjdGVkIFJlc291cmNlIC0tLXwgICAgICAgICAgICAg ICB8CiAgKy0tLS0tLS0tKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0t LS0tLS0tKwoKPC9wcmU+PC9kaXY+PHRhYmxlIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiIGNl bGxzcGFjaW5nPSIyIiBhbGlnbj0iY2VudGVyIj48dHI+PHRkIGFsaWduPSJjZW50ZXIiPjxmb250 IGZhY2U9Im1vbmFjbywgTVMgU2FucyBTZXJpZiIgc2l6ZT0iMSI+PGI+Jm5ic3A7RmlndXJlJm5i c3A7MTogQWJzdHJhY3QgUHJvdG9jb2wgRmxvdyZuYnNwOzwvYj48L2ZvbnQ+PGJyIC8+PC90ZD48 L3RyPjwvdGFibGU+PGhyIGNsYXNzPSJpbnNlcnQiIC8+Cgo8cD4KICAgICAgICAgIFRoZSBhYnN0 cmFjdCBmbG93IGlsbHVzdHJhdGVkIGluIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjRmlndXJlLTEn PkZpZ3VyZSZuYnNwOzE8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+QWJzdHJhY3Qg UHJvdG9jb2wgRmxvdzwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4gZGVzY3JpYmVzIHRoZSBpbnRl cmFjdGlvbgogICAgICAgICAgYmV0d2VlbiB0aGUgZm91ciByb2xlcyBhbmQgaW5jbHVkZXMgdGhl IGZvbGxvd2luZyBzdGVwczoKICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgIDwvcD4KPGJsb2Nr cXVvdGUgY2xhc3M9InRleHQiPjxkbD4KPGR0PihBKTwvZHQ+CjxkZD4KICAgICAgICAgICAgICBU aGUgY2xpZW50IHJlcXVlc3RzIGF1dGhvcml6YXRpb24gZnJvbSB0aGUgcmVzb3VyY2Ugb3duZXIu IFRoZSBhdXRob3JpemF0aW9uIHJlcXVlc3QKICAgICAgICAgICAgICBjYW4gYmUgbWFkZSBkaXJl Y3RseSB0byB0aGUgcmVzb3VyY2Ugb3duZXIgKGFzIHNob3duKSwgb3IgcHJlZmVyYWJseSBpbmRp cmVjdGx5IHZpYQogICAgICAgICAgICAgIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBhcyBhbiBp bnRlcm1lZGlhcnkuCiAgICAgICAgICAgIAo8L2RkPgo8ZHQ+KEIpPC9kdD4KPGRkPgogICAgICAg ICAgICAgIFRoZSBjbGllbnQgcmVjZWl2ZXMgYW4gYXV0aG9yaXphdGlvbiBncmFudCB3aGljaCBp cyBhIGNyZWRlbnRpYWwgcmVwcmVzZW50aW5nCiAgICAgICAgICAgICAgdGhlIHJlc291cmNlIG93 bmVyJ3MgYXV0aG9yaXphdGlvbiwgZXhwcmVzc2VkIHVzaW5nIG9uZSBvZiBmb3VyIGdyYW50IHR5 cGVzIGRlZmluZWQKICAgICAgICAgICAgICBpbiB0aGlzIHNwZWNpZmljYXRpb24gb3IgdXNpbmcg YW4gZXh0ZW5zaW9uIGdyYW50IHR5cGUuIFRoZSBhdXRob3JpemF0aW9uIGdyYW50IHR5cGUKICAg ICAgICAgICAgICBkZXBlbmRzIG9uIHRoZSBtZXRob2QgdXNlZCBieSB0aGUgY2xpZW50IHRvIHJl cXVlc3QgYXV0aG9yaXphdGlvbiBhbmQgdGhlIHR5cGVzCiAgICAgICAgICAgICAgc3VwcG9ydGVk IGJ5IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlci4KICAgICAgICAgICAgCjwvZGQ+CjxkdD4oQyk8 L2R0Pgo8ZGQ+CiAgICAgICAgICAgICAgVGhlIGNsaWVudCByZXF1ZXN0cyBhbiBhY2Nlc3MgdG9r ZW4gYnkgYXV0aGVudGljYXRpbmcgd2l0aCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIKICAgICAg ICAgICAgICBhbmQgcHJlc2VudGluZyB0aGUgYXV0aG9yaXphdGlvbiBncmFudC4KICAgICAgICAg ICAgCjwvZGQ+CjxkdD4oRCk8L2R0Pgo8ZGQ+CiAgICAgICAgICAgICAgVGhlIGF1dGhvcml6YXRp b24gc2VydmVyIGF1dGhlbnRpY2F0ZXMgdGhlIGNsaWVudCBhbmQgdmFsaWRhdGVzIHRoZSBhdXRo b3JpemF0aW9uCiAgICAgICAgICAgICAgZ3JhbnQsIGFuZCBpZiB2YWxpZCBpc3N1ZXMgYW4gYWNj ZXNzIHRva2VuLgogICAgICAgICAgICAKPC9kZD4KPGR0PihFKTwvZHQ+CjxkZD4KICAgICAgICAg ICAgICBUaGUgY2xpZW50IHJlcXVlc3RzIHRoZSBwcm90ZWN0ZWQgcmVzb3VyY2UgZnJvbSB0aGUg cmVzb3VyY2Ugc2VydmVyIGFuZCBhdXRoZW50aWNhdGVzCiAgICAgICAgICAgICAgYnkgcHJlc2Vu dGluZyB0aGUgYWNjZXNzIHRva2VuLgogICAgICAgICAgICAKPC9kZD4KPGR0PihGKTwvZHQ+Cjxk ZD4KICAgICAgICAgICAgICBUaGUgcmVzb3VyY2Ugc2VydmVyIHZhbGlkYXRlcyB0aGUgYWNjZXNz IHRva2VuLCBhbmQgaWYgdmFsaWQsIHNlcnZlcyB0aGUgcmVxdWVzdC4KICAgICAgICAgICAgCjwv ZGQ+CjwvZGw+PC9ibG9ja3F1b3RlPjxwPgogICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgVGhl IHByZWZlcnJlZCBtZXRob2QgZm9yIHRoZSBjbGllbnQgdG8gb2J0YWluIGFuIGF1dGhvcml6YXRp b24gZ3JhbnQgZnJvbSB0aGUgcmVzb3VyY2UKICAgICAgICAgIG93bmVyIChkZXBpY3RlZCBpbiBz dGVwcyAoQSkgYW5kIChCKSkgaXMgdG8gdXNlIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBhcyBh biBpbnRlcm1lZGlhcnkKICAgICAgICAgIHdoaWNoIGlzIGlsbHVzdHJhdGVkIGluIDxhIGNsYXNz PSdpbmZvJyBocmVmPScjRmlndXJlLTMnPkZpZ3VyZSZuYnNwOzM8c3Bhbj4gKDwvc3Bhbj48c3Bh biBjbGFzcz0naW5mbyc+QXV0aG9yaXphdGlvbiBDb2RlIEZsb3c8L3NwYW4+PHNwYW4+KTwvc3Bh bj48L2E+LgogICAgICAgIAo8L3A+CjxhIG5hbWU9ImFuY2hvcjQiPjwvYT48YnIgLz48aHIgLz4K PHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBj bGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJl Zj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJy ZmMuc2VjdGlvbi4xLjMiPjwvYT48aDM+MS4zLiZuYnNwOwpBdXRob3JpemF0aW9uIEdyYW50PC9o Mz4KCjxwPgogICAgICAgICAgQW4gYXV0aG9yaXphdGlvbiBncmFudCBpcyBhIGNyZWRlbnRpYWwg cmVwcmVzZW50aW5nIHRoZSByZXNvdXJjZSBvd25lcidzIGF1dGhvcml6YXRpb24KICAgICAgICAg ICh0byBhY2Nlc3MgaXRzIHByb3RlY3RlZCByZXNvdXJjZXMpIHVzZWQgYnkgdGhlIGNsaWVudCB0 byBvYnRhaW4gYW4gYWNjZXNzIHRva2VuLiBUaGlzCiAgICAgICAgICBzcGVjaWZpY2F0aW9uIGRl ZmluZXMgZm91ciBncmFudCB0eXBlczogYXV0aG9yaXphdGlvbiBjb2RlLCBpbXBsaWNpdCwgcmVz b3VyY2Ugb3duZXIKICAgICAgICAgIHBhc3N3b3JkIGNyZWRlbnRpYWxzLCBhbmQgY2xpZW50IGNy ZWRlbnRpYWxzLCBhcyB3ZWxsIGFzIGFuIGV4dGVuc2liaWxpdHkgbWVjaGFuaXNtIGZvcgogICAg ICAgICAgZGVmaW5pbmcgYWRkaXRpb25hbCB0eXBlcy4KICAgICAgICAKPC9wPgo8YSBuYW1lPSJh bmNob3I1Ij48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRk aW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+ PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3Rk PjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uMS4zLjEiPjwvYT48aDM+MS4zLjEu Jm5ic3A7CkF1dGhvcml6YXRpb24gQ29kZTwvaDM+Cgo8cD4KICAgICAgICAgICAgVGhlIGF1dGhv cml6YXRpb24gY29kZSBpcyBvYnRhaW5lZCBieSB1c2luZyBhbiBhdXRob3JpemF0aW9uIHNlcnZl ciBhcyBhbiBpbnRlcm1lZGlhcnkKICAgICAgICAgICAgYmV0d2VlbiB0aGUgY2xpZW50IGFuZCBy ZXNvdXJjZSBvd25lci4gSW5zdGVhZCBvZiByZXF1ZXN0aW5nIGF1dGhvcml6YXRpb24gZGlyZWN0 bHkKICAgICAgICAgICAgZnJvbSB0aGUgcmVzb3VyY2Ugb3duZXIsIHRoZSBjbGllbnQgZGlyZWN0 cyB0aGUgcmVzb3VyY2Ugb3duZXIgdG8gYW4gYXV0aG9yaXphdGlvbgogICAgICAgICAgICBzZXJ2 ZXIgKHZpYSBpdHMgdXNlci1hZ2VudCBhcyBkZWZpbmVkIGluIDxhIGNsYXNzPSdpbmZvJyBocmVm PScjUkZDMjYxNic+W1JGQzI2MTZdPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkZp ZWxkaW5nLCBSLiwgR2V0dHlzLCBKLiwgTW9ndWwsIEouLCBGcnlzdHlrLCBILiwgTWFzaW50ZXIs IEwuLCBMZWFjaCwgUC4sIGFuZCBULiBCZXJuZXJzLUxlZSwgJmxkcXVvO0h5cGVydGV4dCBUcmFu c2ZlciBQcm90b2NvbCAtLSBIVFRQLzEuMSwmcmRxdW87IEp1bmUmbmJzcDsxOTk5Ljwvc3Bhbj48 c3Bhbj4pPC9zcGFuPjwvYT4pLCB3aGljaCBpbiB0dXJuCiAgICAgICAgICAgIGRpcmVjdHMgdGhl IHJlc291cmNlIG93bmVyIGJhY2sgdG8gdGhlIGNsaWVudCB3aXRoIHRoZSBhdXRob3JpemF0aW9u IGNvZGUuCiAgICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgICAgQmVmb3JlIGRpcmVjdGluZyB0 aGUgcmVzb3VyY2Ugb3duZXIgYmFjayB0byB0aGUgY2xpZW50IHdpdGggdGhlIGF1dGhvcml6YXRp b24gY29kZSwgdGhlCiAgICAgICAgICAgIGF1dGhvcml6YXRpb24gc2VydmVyIGF1dGhlbnRpY2F0 ZXMgdGhlIHJlc291cmNlIG93bmVyIGFuZCBvYnRhaW5zIGF1dGhvcml6YXRpb24uCiAgICAgICAg ICAgIEJlY2F1c2UgdGhlIHJlc291cmNlIG93bmVyIG9ubHkgYXV0aGVudGljYXRlcyB3aXRoIHRo ZSBhdXRob3JpemF0aW9uIHNlcnZlciwgdGhlCiAgICAgICAgICAgIHJlc291cmNlIG93bmVyJ3Mg Y3JlZGVudGlhbHMgYXJlIG5ldmVyIHNoYXJlZCB3aXRoIHRoZSBjbGllbnQuCiAgICAgICAgICAK PC9wPgo8cD4KICAgICAgICAgICAgVGhlIGF1dGhvcml6YXRpb24gY29kZSBwcm92aWRlcyBhIGZl dyBpbXBvcnRhbnQgc2VjdXJpdHkgYmVuZWZpdHMgc3VjaCBhcyB0aGUgYWJpbGl0eQogICAgICAg ICAgICB0byBhdXRoZW50aWNhdGUgdGhlIGNsaWVudCwgYW5kIHRoZSB0cmFuc21pc3Npb24gb2Yg dGhlIGFjY2VzcyB0b2tlbiBkaXJlY3RseSB0bwogICAgICAgICAgICB0aGUgY2xpZW50IHdpdGhv dXQgcGFzc2luZyBpdCB0aHJvdWdoIHRoZSByZXNvdXJjZSBvd25lcidzIHVzZXItYWdlbnQsIHBv dGVudGlhbGx5CiAgICAgICAgICAgIGV4cG9zaW5nIGl0IHRvIG90aGVycywgaW5jbHVkaW5nIHRo ZSByZXNvdXJjZSBvd25lci4KICAgICAgICAgIAo8L3A+CjxhIG5hbWU9ImFuY2hvcjYiPjwvYT48 YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxz cGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRP Q2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxl Pgo8YSBuYW1lPSJyZmMuc2VjdGlvbi4xLjMuMiI+PC9hPjxoMz4xLjMuMi4mbmJzcDsKSW1wbGlj aXQ8L2gzPgoKPHA+CiAgICAgICAgICAgIFRoZSBpbXBsaWNpdCBncmFudCBpcyBhIHNpbXBsaWZp ZWQgYXV0aG9yaXphdGlvbiBjb2RlIGZsb3cgb3B0aW1pemVkIGZvciBjbGllbnRzCiAgICAgICAg ICAgIGltcGxlbWVudGVkIGluIGEgYnJvd3NlciB1c2luZyBhIHNjcmlwdGluZyBsYW5ndWFnZSBz dWNoIGFzIEphdmFTY3JpcHQuIEluIHRoZSBpbXBsaWNpdAogICAgICAgICAgICBmbG93LCBpbnN0 ZWFkIG9mIGlzc3VpbmcgdGhlIGNsaWVudCBhbiBhdXRob3JpemF0aW9uIGNvZGUsIHRoZSBjbGll bnQgaXMgaXNzdWVkIGFuCiAgICAgICAgICAgIGFjY2VzcyB0b2tlbiBkaXJlY3RseSAoYXMgdGhl IHJlc3VsdCBvZiB0aGUgcmVzb3VyY2Ugb3duZXIgYXV0aG9yaXphdGlvbikuIFRoZSBncmFudAog ICAgICAgICAgICB0eXBlIGlzIGltcGxpY2l0IGFzIG5vIGludGVybWVkaWF0ZSBjcmVkZW50aWFs cyAoc3VjaCBhcyBhbiBhdXRob3JpemF0aW9uIGNvZGUpIGFyZQogICAgICAgICAgICBpc3N1ZWQg KGFuZCBsYXRlciB1c2VkIHRvIG9idGFpbiBhbiBhY2Nlc3MgdG9rZW4pLgogICAgICAgICAgCjwv cD4KPHA+CiAgICAgICAgICAgIFdoZW4gaXNzdWluZyBhbiBhY2Nlc3MgdG9rZW4gZHVyaW5nIHRo ZSBpbXBsaWNpdCBncmFudCBmbG93LCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIKICAgICAgICAg ICAgZG9lcyBub3QgYXV0aGVudGljYXRlIHRoZSBjbGllbnQuIEluIHNvbWUgY2FzZXMsIHRoZSBj bGllbnQgaWRlbnRpdHkgY2FuIGJlIHZlcmlmaWVkCiAgICAgICAgICAgIHZpYSB0aGUgcmVkaXJl Y3Rpb24gVVJJIHVzZWQgdG8gZGVsaXZlciB0aGUgYWNjZXNzIHRva2VuIHRvIHRoZSBjbGllbnQu IFRoZSBhY2Nlc3MKICAgICAgICAgICAgdG9rZW4gbWF5IGJlIGV4cG9zZWQgdG8gdGhlIHJlc291 cmNlIG93bmVyIG9yIG90aGVyIGFwcGxpY2F0aW9ucyB3aXRoIGFjY2VzcyB0byB0aGUKICAgICAg ICAgICAgcmVzb3VyY2Ugb3duZXIncyB1c2VyLWFnZW50LgogICAgICAgICAgCjwvcD4KPHA+CiAg ICAgICAgICAgIEltcGxpY2l0IGdyYW50cyBpbXByb3ZlIHRoZSByZXNwb25zaXZlbmVzcyBhbmQg ZWZmaWNpZW5jeSBvZiBzb21lIGNsaWVudHMgKHN1Y2ggYXMgYQogICAgICAgICAgICBjbGllbnQg aW1wbGVtZW50ZWQgYXMgYW4gaW4tYnJvd3NlciBhcHBsaWNhdGlvbikgc2luY2UgaXQgcmVkdWNl cyB0aGUgbnVtYmVyIG9mIHJvdW5kCiAgICAgICAgICAgIHRyaXBzIHJlcXVpcmVkIHRvIG9idGFp biBhbiBhY2Nlc3MgdG9rZW4uIEhvd2V2ZXIsIHRoaXMgY29udmVuaWVuY2Ugc2hvdWxkIGJlIHdl aWdoZWQKICAgICAgICAgICAgYWdhaW5zdCB0aGUgc2VjdXJpdHkgaW1wbGljYXRpb25zIG9mIHVz aW5nIGltcGxpY2l0IGdyYW50cywgZXNwZWNpYWxseSB3aGVuIHRoZQogICAgICAgICAgICBhdXRo b3JpemF0aW9uIGNvZGUgZ3JhbnQgdHlwZSBpcyBhdmFpbGFibGUuCiAgICAgICAgICAKPC9wPgo8 YSBuYW1lPSJhbmNob3I3Ij48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQi IGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJp Z2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNw OzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uMS4zLjMiPjwvYT48 aDM+MS4zLjMuJm5ic3A7ClJlc291cmNlIE93bmVyIFBhc3N3b3JkIENyZWRlbnRpYWxzPC9oMz4K CjxwPgogICAgICAgICAgICBUaGUgcmVzb3VyY2Ugb3duZXIgcGFzc3dvcmQgY3JlZGVudGlhbHMg KGkuZS4gdXNlcm5hbWUgYW5kIHBhc3N3b3JkKSBjYW4gYmUgdXNlZAogICAgICAgICAgICBkaXJl Y3RseSBhcyBhbiBhdXRob3JpemF0aW9uIGdyYW50IHRvIG9idGFpbiBhbiBhY2Nlc3MgdG9rZW4u IFRoZSBjcmVkZW50aWFscyBzaG91bGQKICAgICAgICAgICAgb25seSBiZSB1c2VkIHdoZW4gdGhl cmUgaXMgYSBoaWdoIGRlZ3JlZSBvZiB0cnVzdCBiZXR3ZWVuIHRoZSByZXNvdXJjZSBvd25lciBh bmQgdGhlCiAgICAgICAgICAgIGNsaWVudCAoZS5nLiB0aGUgY2xpZW50IGlzIHBhcnQgb2YgdGhl IGRldmljZSBvcGVyYXRpbmcgc3lzdGVtIG9yIGEgaGlnaGx5IHByaXZpbGVnZWQKICAgICAgICAg ICAgYXBwbGljYXRpb24pLCBhbmQgd2hlbiBvdGhlciBhdXRob3JpemF0aW9uIGdyYW50IHR5cGVz IGFyZSBub3QgYXZhaWxhYmxlIChzdWNoIGFzIGFuCiAgICAgICAgICAgIGF1dGhvcml6YXRpb24g Y29kZSkuCiAgICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgICAgRXZlbiB0aG91Z2ggdGhpcyBn cmFudCB0eXBlIHJlcXVpcmVzIGRpcmVjdCBjbGllbnQgYWNjZXNzIHRvIHRoZSByZXNvdXJjZSBv d25lcgogICAgICAgICAgICBjcmVkZW50aWFscywgdGhlIHJlc291cmNlIG93bmVyIGNyZWRlbnRp YWxzIGFyZSB1c2VkIGZvciBhIHNpbmdsZSByZXF1ZXN0IGFuZCBhcmUKICAgICAgICAgICAgZXhj aGFuZ2VkIGZvciBhbiBhY2Nlc3MgdG9rZW4uIFRoaXMgZ3JhbnQgdHlwZSBjYW4gZWxpbWluYXRl IHRoZSBuZWVkIGZvciB0aGUgY2xpZW50CiAgICAgICAgICAgIHRvIHN0b3JlIHRoZSByZXNvdXJj ZSBvd25lciBjcmVkZW50aWFscyBmb3IgZnV0dXJlIHVzZSwgYnkgZXhjaGFuZ2luZyB0aGUgY3Jl ZGVudGlhbHMKICAgICAgICAgICAgd2l0aCBhIGxvbmctbGl2ZWQgYWNjZXNzIHRva2VuIG9yIHJl ZnJlc2ggdG9rZW4uCiAgICAgICAgICAKPC9wPgo8YSBuYW1lPSJhbmNob3I4Ij48L2E+PGJyIC8+ PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2lu Zz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWci PjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEg bmFtZT0icmZjLnNlY3Rpb24uMS4zLjQiPjwvYT48aDM+MS4zLjQuJm5ic3A7CkNsaWVudCBDcmVk ZW50aWFsczwvaDM+Cgo8cD4KICAgICAgICAgICAgVGhlIGNsaWVudCBjcmVkZW50aWFscyAob3Ig b3RoZXIgZm9ybXMgb2YgY2xpZW50IGF1dGhlbnRpY2F0aW9uKSBjYW4gYmUgdXNlZCBhcyBhbgog ICAgICAgICAgICBhdXRob3JpemF0aW9uIGdyYW50IHdoZW4gdGhlIGF1dGhvcml6YXRpb24gc2Nv cGUgaXMgbGltaXRlZCB0byB0aGUgcHJvdGVjdGVkIHJlc291cmNlcwogICAgICAgICAgICB1bmRl ciB0aGUgY29udHJvbCBvZiB0aGUgY2xpZW50LCBvciB0byBwcm90ZWN0ZWQgcmVzb3VyY2VzIHBy ZXZpb3VzbHkgYXJyYW5nZWQgd2l0aCB0aGUKICAgICAgICAgICAgYXV0aG9yaXphdGlvbiBzZXJ2 ZXIuIENsaWVudCBjcmVkZW50aWFscyBhcmUgdXNlZCBhcyBhbiBhdXRob3JpemF0aW9uIGdyYW50 IHR5cGljYWxseQogICAgICAgICAgICB3aGVuIHRoZSBjbGllbnQgaXMgYWN0aW5nIG9uIGl0cyBv d24gYmVoYWxmICh0aGUgY2xpZW50IGlzIGFsc28gdGhlIHJlc291cmNlIG93bmVyKSwgb3IKICAg ICAgICAgICAgaXMgcmVxdWVzdGluZyBhY2Nlc3MgdG8gcHJvdGVjdGVkIHJlc291cmNlcyBiYXNl ZCBvbiBhbiBhdXRob3JpemF0aW9uIHByZXZpb3VzbHkKICAgICAgICAgICAgYXJyYW5nZWQgd2l0 aCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIuCiAgICAgICAgICAKPC9wPgo8YSBuYW1lPSJhbmNo b3I5Ij48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5n PSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRk IGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwv dHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uMS40Ij48L2E+PGgzPjEuNC4mbmJzcDsK QWNjZXNzIFRva2VuPC9oMz4KCjxwPgogICAgICAgICAgQWNjZXNzIHRva2VucyBhcmUgY3JlZGVu dGlhbHMgdXNlZCB0byBhY2Nlc3MgcHJvdGVjdGVkIHJlc291cmNlcy4gQW4gYWNjZXNzIHRva2Vu IGlzIGEKICAgICAgICAgIHN0cmluZyByZXByZXNlbnRpbmcgYW4gYXV0aG9yaXphdGlvbiBpc3N1 ZWQgdG8gdGhlIGNsaWVudC4gVGhlIHN0cmluZyBpcyB1c3VhbGx5IG9wYXF1ZQogICAgICAgICAg dG8gdGhlIGNsaWVudC4gVG9rZW5zIHJlcHJlc2VudCBzcGVjaWZpYyBzY29wZXMgYW5kIGR1cmF0 aW9ucyBvZiBhY2Nlc3MsIGdyYW50ZWQgYnkgdGhlCiAgICAgICAgICByZXNvdXJjZSBvd25lciwg YW5kIGVuZm9yY2VkIGJ5IHRoZSByZXNvdXJjZSBzZXJ2ZXIgYW5kIGF1dGhvcml6YXRpb24gc2Vy dmVyLgogICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgVGhlIHRva2VuIG1heSBkZW5vdGUgYW4g aWRlbnRpZmllciB1c2VkIHRvIHJldHJpZXZlIHRoZSBhdXRob3JpemF0aW9uIGluZm9ybWF0aW9u LCBvcgogICAgICAgICAgc2VsZi1jb250YWluIHRoZSBhdXRob3JpemF0aW9uIGluZm9ybWF0aW9u IGluIGEgdmVyaWZpYWJsZSBtYW5uZXIgKGkuZS4gYSB0b2tlbiBzdHJpbmcKICAgICAgICAgIGNv bnNpc3Rpbmcgb2Ygc29tZSBkYXRhIGFuZCBhIHNpZ25hdHVyZSkuIEFkZGl0aW9uYWwgYXV0aGVu dGljYXRpb24gY3JlZGVudGlhbHMsIHdoaWNoCiAgICAgICAgICBhcmUgYmV5b25kIHRoZSBzY29w ZSBvZiB0aGlzIHNwZWNpZmljYXRpb24sIG1heSBiZSByZXF1aXJlZCBpbiBvcmRlciBmb3IgdGhl IGNsaWVudCB0bwogICAgICAgICAgdXNlIGEgdG9rZW4uCiAgICAgICAgCjwvcD4KPHA+CiAgICAg ICAgICBUaGUgYWNjZXNzIHRva2VuIHByb3ZpZGVzIGFuIGFic3RyYWN0aW9uIGxheWVyLCByZXBs YWNpbmcgZGlmZmVyZW50IGF1dGhvcml6YXRpb24KICAgICAgICAgIGNvbnN0cnVjdHMgKGUuZy4g dXNlcm5hbWUgYW5kIHBhc3N3b3JkKSB3aXRoIGEgc2luZ2xlIHRva2VuIHVuZGVyc3Rvb2QgYnkg dGhlIHJlc291cmNlCiAgICAgICAgICBzZXJ2ZXIuIFRoaXMgYWJzdHJhY3Rpb24gZW5hYmxlcyBp c3N1aW5nIGFjY2VzcyB0b2tlbnMgbW9yZSByZXN0cmljdGl2ZSB0aGFuIHRoZQogICAgICAgICAg YXV0aG9yaXphdGlvbiBncmFudCB1c2VkIHRvIG9idGFpbiB0aGVtLCBhcyB3ZWxsIGFzIHJlbW92 aW5nIHRoZSByZXNvdXJjZSBzZXJ2ZXIncyBuZWVkIHRvCiAgICAgICAgICB1bmRlcnN0YW5kIGEg d2lkZSByYW5nZSBvZiBhdXRoZW50aWNhdGlvbiBtZXRob2RzLgogICAgICAgIAo8L3A+CjxwPgog ICAgICAgICAgQWNjZXNzIHRva2VucyBjYW4gaGF2ZSBkaWZmZXJlbnQgZm9ybWF0cywgc3RydWN0 dXJlcywgYW5kIG1ldGhvZHMgb2YgdXRpbGl6YXRpb24gKGUuZy4KICAgICAgICAgIGNyeXB0b2dy YXBoaWMgcHJvcGVydGllcykgYmFzZWQgb24gdGhlIHJlc291cmNlIHNlcnZlciBzZWN1cml0eSBy ZXF1aXJlbWVudHMuIEFjY2VzcyB0b2tlbgogICAgICAgICAgYXR0cmlidXRlcyBhbmQgdGhlIG1l dGhvZHMgdXNlZCB0byBhY2Nlc3MgcHJvdGVjdGVkIHJlc291cmNlcyBhcmUgYmV5b25kIHRoZSBz Y29wZSBvZiB0aGlzCiAgICAgICAgICBzcGVjaWZpY2F0aW9uIGFuZCBhcmUgZGVmaW5lZCBieSBj b21wYW5pb24gc3BlY2lmaWNhdGlvbnMuCiAgICAgICAgCjwvcD4KPGEgbmFtZT0iYW5jaG9yMTAi PjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAi IGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xh c3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48 L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi4xLjUiPjwvYT48aDM+MS41LiZuYnNwOwpSZWZy ZXNoIFRva2VuPC9oMz4KCjxwPgogICAgICAgICAgUmVmcmVzaCB0b2tlbnMgYXJlIGNyZWRlbnRp YWxzIHVzZWQgdG8gb2J0YWluIGFjY2VzcyB0b2tlbnMuIFJlZnJlc2ggdG9rZW5zIGFyZSBpc3N1 ZWQgdG8KICAgICAgICAgIHRoZSBjbGllbnQgYnkgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGFu ZCBhcmUgdXNlZCB0byBvYnRhaW4gYSBuZXcgYWNjZXNzIHRva2VuIHdoZW4gdGhlCiAgICAgICAg ICBjdXJyZW50IGFjY2VzcyB0b2tlbiBiZWNvbWVzIGludmFsaWQgb3IgZXhwaXJlcywgb3IgdG8g b2J0YWluIGFkZGl0aW9uYWwgYWNjZXNzIHRva2VucwogICAgICAgICAgd2l0aCBpZGVudGljYWwg b3IgbmFycm93ZXIgc2NvcGUgKGFjY2VzcyB0b2tlbnMgbWF5IGhhdmUgYSBzaG9ydGVyIGxpZmV0 aW1lIGFuZCBmZXdlcgogICAgICAgICAgcGVybWlzc2lvbnMgdGhhbiBhdXRob3JpemVkIGJ5IHRo ZSByZXNvdXJjZSBvd25lcikuIElzc3VpbmcgYSByZWZyZXNoIHRva2VuIGlzIG9wdGlvbmFsCiAg ICAgICAgICBhdCB0aGUgZGlzY3JldGlvbiBvZiB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIuIElm IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBpc3N1ZXMgYQogICAgICAgICAgcmVmcmVzaCB0b2tl biwgaXQgaXMgaW5jbHVkZWQgd2hlbiBpc3N1aW5nIGFuIGFjY2VzcyB0b2tlbiAoaS5lLiBzdGVw IChEKSBpbgogICAgICAgICAgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNGaWd1cmUtMSc+RmlndXJl Jm5ic3A7MTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5BYnN0cmFjdCBQcm90b2Nv bCBGbG93PC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPikuCiAgICAgICAgCjwvcD4KPHA+CiAgICAg ICAgICBBIHJlZnJlc2ggdG9rZW4gaXMgYSBzdHJpbmcgcmVwcmVzZW50aW5nIHRoZSBhdXRob3Jp emF0aW9uIGdyYW50ZWQgdG8gdGhlIGNsaWVudCBieSB0aGUKICAgICAgICAgIHJlc291cmNlIG93 bmVyLiBUaGUgc3RyaW5nIGlzIHVzdWFsbHkgb3BhcXVlIHRvIHRoZSBjbGllbnQuIFRoZSB0b2tl biBkZW5vdGVzIGFuCiAgICAgICAgICBpZGVudGlmaWVyIHVzZWQgdG8gcmV0cmlldmUgdGhlIGF1 dGhvcml6YXRpb24gaW5mb3JtYXRpb24uIFVubGlrZSBhY2Nlc3MgdG9rZW5zLCByZWZyZXNoCiAg ICAgICAgICB0b2tlbnMgYXJlIGludGVuZGVkIGZvciB1c2Ugb25seSB3aXRoIGF1dGhvcml6YXRp b24gc2VydmVycyBhbmQgYXJlIG5ldmVyIHNlbnQgdG8KICAgICAgICAgIHJlc291cmNlIHNlcnZl cnMuCiAgICAgICAgCjwvcD48YnIgLz48aHIgY2xhc3M9Imluc2VydCIgLz4KPGEgbmFtZT0iRmln dXJlLTIiPjwvYT4KPGRpdiBzdHlsZT0nZGlzcGxheTogdGFibGU7IHdpZHRoOiAwOyBtYXJnaW4t bGVmdDogM2VtOyBtYXJnaW4tcmlnaHQ6IGF1dG8nPjxwcmU+CgogICstLS0tLS0tLSsgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLSsKICB8 ICAgICAgICB8LS0oQSktLS0tLS0tIEF1dGhvcml6YXRpb24gR3JhbnQgLS0tLS0tLS0tJmd0O3wg ICAgICAgICAgICAgICB8CiAgfCAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgfAogIHwgICAgICAgIHwmbHQ7LShCKS0tLS0t LS0tLS0tIEFjY2VzcyBUb2tlbiAtLS0tLS0tLS0tLS0tfCAgICAgICAgICAgICAgIHwKICB8ICAg ICAgICB8ICAgICAgICAgICAgICAgJmFtcDsgUmVmcmVzaCBUb2tlbiAgICAgICAgICAgICB8ICAg ICAgICAgICAgICAgfAogIHwgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgfCAgICAgICAgICAgICAgIHwKICB8ICAgICAgICB8ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICstLS0tLS0tLS0tKyAgIHwgICAgICAgICAgICAgICB8CiAgfCAgICAgICAg fC0tKEMpLS0tLSBBY2Nlc3MgVG9rZW4gLS0tLSZndDt8ICAgICAgICAgIHwgICB8ICAgICAgICAg ICAgICAgfAogIHwgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAg ICB8ICAgfCAgICAgICAgICAgICAgIHwKICB8ICAgICAgICB8Jmx0Oy0oRCktIFByb3RlY3RlZCBS ZXNvdXJjZSAtLXwgUmVzb3VyY2UgfCAgIHwgQXV0aG9yaXphdGlvbiB8CiAgfCBDbGllbnQgfCAg ICAgICAgICAgICAgICAgICAgICAgICAgICB8ICBTZXJ2ZXIgIHwgICB8ICAgICBTZXJ2ZXIgICAg fAogIHwgICAgICAgIHwtLShFKS0tLS0gQWNjZXNzIFRva2VuIC0tLS0mZ3Q7fCAgICAgICAgICB8 ICAgfCAgICAgICAgICAgICAgIHwKICB8ICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHwgICAgICAgICAgfCAgIHwgICAgICAgICAgICAgICB8CiAgfCAgICAgICAgfCZsdDstKEYp LSBJbnZhbGlkIFRva2VuIEVycm9yIC18ICAgICAgICAgIHwgICB8ICAgICAgICAgICAgICAgfAog IHwgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0rICAgfCAg ICAgICAgICAgICAgIHwKICB8ICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHwgICAgICAgICAgICAgICB8CiAgfCAgICAgICAgfC0tKEcpLS0tLS0tLS0t LS0gUmVmcmVzaCBUb2tlbiAtLS0tLS0tLS0tLSZndDt8ICAgICAgICAgICAgICAgfAogIHwgICAg ICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAg ICAgICAgIHwKICB8ICAgICAgICB8Jmx0Oy0oSCktLS0tLS0tLS0tLSBBY2Nlc3MgVG9rZW4gLS0t LS0tLS0tLS0tLXwgICAgICAgICAgICAgICB8CiAgKy0tLS0tLS0tKyAgICAgICAgICAgJmFtcDsg T3B0aW9uYWwgUmVmcmVzaCBUb2tlbiAgICAgICAgKy0tLS0tLS0tLS0tLS0tLSsKCjwvcHJlPjwv ZGl2Pjx0YWJsZSBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgYWxp Z249ImNlbnRlciI+PHRyPjx0ZCBhbGlnbj0iY2VudGVyIj48Zm9udCBmYWNlPSJtb25hY28sIE1T IFNhbnMgU2VyaWYiIHNpemU9IjEiPjxiPiZuYnNwO0ZpZ3VyZSZuYnNwOzI6IFJlZnJlc2hpbmcg YW4gRXhwaXJlZCBBY2Nlc3MgVG9rZW4mbmJzcDs8L2I+PC9mb250PjxiciAvPjwvdGQ+PC90cj48 L3RhYmxlPjxociBjbGFzcz0iaW5zZXJ0IiAvPgoKPHA+CiAgICAgICAgICBUaGUgZmxvdyBpbGx1 c3RyYXRlZCBpbiA8YSBjbGFzcz0naW5mbycgaHJlZj0nI0ZpZ3VyZS0yJz5GaWd1cmUmbmJzcDsy PHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPlJlZnJlc2hpbmcgYW4gRXhwaXJlZCBB Y2Nlc3MgVG9rZW48L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+IGluY2x1ZGVzIHRoZSBmb2xsb3dp bmcgc3RlcHM6CiAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICA8L3A+CjxibG9ja3F1b3RlIGNs YXNzPSJ0ZXh0Ij48ZGw+CjxkdD4oQSk8L2R0Pgo8ZGQ+CiAgICAgICAgICAgICAgVGhlIGNsaWVu dCByZXF1ZXN0cyBhbiBhY2Nlc3MgdG9rZW4gYnkgYXV0aGVudGljYXRpbmcgd2l0aCB0aGUgYXV0 aG9yaXphdGlvbiBzZXJ2ZXIsCiAgICAgICAgICAgICAgYW5kIHByZXNlbnRpbmcgYW4gYXV0aG9y aXphdGlvbiBncmFudC4KICAgICAgICAgICAgCjwvZGQ+CjxkdD4oQik8L2R0Pgo8ZGQ+CiAgICAg ICAgICAgICAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGF1dGhlbnRpY2F0ZXMgdGhlIGNsaWVu dCBhbmQgdmFsaWRhdGVzIHRoZSBhdXRob3JpemF0aW9uCiAgICAgICAgICAgICAgZ3JhbnQsIGFu ZCBpZiB2YWxpZCBpc3N1ZXMgYW4gYWNjZXNzIHRva2VuIGFuZCBhIHJlZnJlc2ggdG9rZW4uCiAg ICAgICAgICAgIAo8L2RkPgo8ZHQ+KEMpPC9kdD4KPGRkPgogICAgICAgICAgICAgIFRoZSBjbGll bnQgbWFrZXMgYSBwcm90ZWN0ZWQgcmVzb3VyY2UgcmVxdWVzdCB0byB0aGUgcmVzb3VyY2Ugc2Vy dmVyIGJ5IHByZXNlbnRpbmcKICAgICAgICAgICAgICB0aGUgYWNjZXNzIHRva2VuLgogICAgICAg ICAgICAKPC9kZD4KPGR0PihEKTwvZHQ+CjxkZD4KICAgICAgICAgICAgICBUaGUgcmVzb3VyY2Ug c2VydmVyIHZhbGlkYXRlcyB0aGUgYWNjZXNzIHRva2VuLCBhbmQgaWYgdmFsaWQsIHNlcnZlcyB0 aGUgcmVxdWVzdC4KICAgICAgICAgICAgCjwvZGQ+CjxkdD4oRSk8L2R0Pgo8ZGQ+CiAgICAgICAg ICAgICAgU3RlcHMgKEMpIGFuZCAoRCkgcmVwZWF0IHVudGlsIHRoZSBhY2Nlc3MgdG9rZW4gZXhw aXJlcy4gSWYgdGhlIGNsaWVudCBrbm93cyB0aGUKICAgICAgICAgICAgICBhY2Nlc3MgdG9rZW4g ZXhwaXJlZCwgaXQgc2tpcHMgdG8gc3RlcCAoRyksIG90aGVyd2lzZSBpdCBtYWtlcyBhbm90aGVy IHByb3RlY3RlZAogICAgICAgICAgICAgIHJlc291cmNlIHJlcXVlc3QuCiAgICAgICAgICAgIAo8 L2RkPgo8ZHQ+KEYpPC9kdD4KPGRkPgogICAgICAgICAgICAgIFNpbmNlIHRoZSBhY2Nlc3MgdG9r ZW4gaXMgaW52YWxpZCwgdGhlIHJlc291cmNlIHNlcnZlciByZXR1cm5zIGFuIGludmFsaWQgdG9r ZW4KICAgICAgICAgICAgICBlcnJvci4KICAgICAgICAgICAgCjwvZGQ+CjxkdD4oRyk8L2R0Pgo8 ZGQ+CiAgICAgICAgICAgICAgVGhlIGNsaWVudCByZXF1ZXN0cyBhIG5ldyBhY2Nlc3MgdG9rZW4g YnkgYXV0aGVudGljYXRpbmcgd2l0aCB0aGUgYXV0aG9yaXphdGlvbgogICAgICAgICAgICAgIHNl cnZlciBhbmQgcHJlc2VudGluZyB0aGUgcmVmcmVzaCB0b2tlbi4gVGhlIGNsaWVudCBhdXRoZW50 aWNhdGlvbiByZXF1aXJlbWVudHMgYXJlCiAgICAgICAgICAgICAgYmFzZWQgb24gdGhlIGNsaWVu dCB0eXBlIGFuZCBvbiB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgcG9saWNpZXMuCiAgICAgICAg ICAgIAo8L2RkPgo8ZHQ+KEgpPC9kdD4KPGRkPgogICAgICAgICAgICAgIFRoZSBhdXRob3JpemF0 aW9uIHNlcnZlciBhdXRoZW50aWNhdGVzIHRoZSBjbGllbnQgYW5kIHZhbGlkYXRlcyB0aGUgcmVm cmVzaCB0b2tlbiwKICAgICAgICAgICAgICBhbmQgaWYgdmFsaWQgaXNzdWVzIGEgbmV3IGFjY2Vz cyB0b2tlbiAoYW5kIG9wdGlvbmFsbHksIGEgbmV3IHJlZnJlc2ggdG9rZW4pLgogICAgICAgICAg ICAKPC9kZD4KPC9kbD48L2Jsb2NrcXVvdGU+PHA+CiAgICAgICAgCjwvcD4KPHA+CiAgICAgICAg ICBTdGVwcyBDLCBELCBFLCBhbmQgRiBhcmUgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBzcGVj aWZpY2F0aW9uIGFzIGRlc2NyaWJlZCBpbgogICAgICAgICAgPGEgY2xhc3M9J2luZm8nIGhyZWY9 JyNhY2Nlc3MtcmVzb3VyY2UnPlNlY3Rpb24mbmJzcDs3PHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xh c3M9J2luZm8nPkFjY2Vzc2luZyBQcm90ZWN0ZWQgUmVzb3VyY2VzPC9zcGFuPjxzcGFuPik8L3Nw YW4+PC9hPi4KICAgICAgICAKPC9wPgo8YSBuYW1lPSJ0bHMiPjwvYT48YnIgLz48aHIgLz4KPHRh YmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFz cz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0i I3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMu c2VjdGlvbi4xLjYiPjwvYT48aDM+MS42LiZuYnNwOwpUTFMgVmVyc2lvbjwvaDM+Cgo8cD4KICAg ICAgICAgIFdoZW5ldmVyIFRMUyBpcyB1c2VkIGJ5IHRoaXMgc3BlY2lmaWNhdGlvbiwgdGhlIGFw cHJvcHJpYXRlIHZlcnNpb24gKG9yIHZlcnNpb25zKSBvZgogICAgICAgICAgVExTIHdpbGwgdmFy eSBvdmVyIHRpbWUsIGJhc2VkIG9uIHRoZSB3aWRlc3ByZWFkIGRlcGxveW1lbnQgYW5kIGtub3du IHNlY3VyaXR5CiAgICAgICAgICB2dWxuZXJhYmlsaXRpZXMuIEF0IHRoZSB0aW1lIG9mIHRoaXMg d3JpdGluZywgVExTIHZlcnNpb24gMS4yIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjUkZDNTI0Nic+ W1JGQzUyNDZdPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkRpZXJrcywgVC4gYW5k IEUuIFJlc2NvcmxhLCAmbGRxdW87VGhlIFRyYW5zcG9ydCBMYXllciBTZWN1cml0eSAoVExTKSBQ cm90b2NvbCBWZXJzaW9uIDEuMiwmcmRxdW87IEF1Z3VzdCZuYnNwOzIwMDguPC9zcGFuPjxzcGFu Pik8L3NwYW4+PC9hPgogICAgICAgICAgaXMgdGhlIG1vc3QgcmVjZW50IHZlcnNpb24sIGJ1dCBo YXMgYSB2ZXJ5IGxpbWl0ZWQgZGVwbG95bWVudCBiYXNlIGFuZCBtaWdodCBub3QgYmUKICAgICAg ICAgIHJlYWRpbHkgYXZhaWxhYmxlIGZvciBpbXBsZW1lbnRhdGlvbi4gVExTIHZlcnNpb24gMS4w IDxhIGNsYXNzPSdpbmZvJyBocmVmPScjUkZDMjI0Nic+W1JGQzIyNDZdPHNwYW4+ICg8L3NwYW4+ PHNwYW4gY2xhc3M9J2luZm8nPkRpZXJrcywgVC4gYW5kIEMuIEFsbGVuLCAmbGRxdW87VGhlIFRM UyBQcm90b2NvbCBWZXJzaW9uIDEuMCwmcmRxdW87IEphbnVhcnkmbmJzcDsxOTk5Ljwvc3Bhbj48 c3Bhbj4pPC9zcGFuPjwvYT4gaXMgdGhlCiAgICAgICAgICBtb3N0IHdpZGVseSBkZXBsb3llZCB2 ZXJzaW9uLCBhbmQgd2lsbCBwcm92aWRlIHRoZSBicm9hZGVzdCBpbnRlcm9wZXJhYmlsaXR5Lgog ICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgSW1wbGVtZW50YXRpb25zIE1BWSBhbHNvIHN1cHBv cnQgYWRkaXRpb25hbCB0cmFuc3BvcnQtbGF5ZXIgc2VjdXJpdHkgbWVjaGFuaXNtcwogICAgICAg ICAgdGhhdCBtZWV0IHRoZWlyIHNlY3VyaXR5IHJlcXVpcmVtZW50cy4KICAgICAgICAKPC9wPgo8 YSBuYW1lPSJhbmNob3IxMSI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0 IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJy aWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJz cDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLjEuNyI+PC9hPjxo Mz4xLjcuJm5ic3A7CkhUVFAgUmVkaXJlY3Rpb25zPC9oMz4KCjxwPgogICAgICAgICAgVGhpcyBz cGVjaWZpY2F0aW9uIG1ha2VzIGV4dGVuc2l2ZSB1c2Ugb2YgSFRUUCByZWRpcmVjdGlvbnMsIGlu IHdoaWNoIHRoZSBjbGllbnQgb3IgdGhlCiAgICAgICAgICBhdXRob3JpemF0aW9uIHNlcnZlciBk aXJlY3QgdGhlIHJlc291cmNlIG93bmVyJ3MgdXNlci1hZ2VudCB0byBhbm90aGVyIGRlc3RpbmF0 aW9uLiBXaGlsZQogICAgICAgICAgdGhlIGV4YW1wbGVzIGluIHRoaXMgc3BlY2lmaWNhdGlvbiBz aG93IHRoZSB1c2Ugb2YgdGhlIEhUVFAgMzAyIHN0YXR1cyBjb2RlLCBhbnkgb3RoZXIKICAgICAg ICAgIG1ldGhvZCBhdmFpbGFibGUgdmlhIHRoZSB1c2VyLWFnZW50IHRvIGFjY29tcGxpc2ggdGhp cyByZWRpcmVjdGlvbiBpcyBhbGxvd2VkIGFuZCBpcwogICAgICAgICAgY29uc2lkZXJlZCB0byBi ZSBhbiBpbXBsZW1lbnRhdGlvbiBkZXRhaWwuCiAgICAgICAgCjwvcD4KPGEgbmFtZT0iYW5jaG9y MTIiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9 IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQg Y2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90 cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi4xLjgiPjwvYT48aDM+MS44LiZuYnNwOwpJ bnRlcm9wZXJhYmlsaXR5PC9oMz4KCjxwPgogICAgICAgICAgT0F1dGggMi4wIHByb3ZpZGVzIGEg cmljaCBhdXRob3JpemF0aW9uIGZyYW1ld29yayB3aXRoIHdlbGwtZGVmaW5lZCBzZWN1cml0eSBw cm9wZXJ0aWVzLgogICAgICAgICAgSG93ZXZlciwgYXMgYSByaWNoIGFuZCBoaWdobHkgZXh0ZW5z aWJsZSBmcmFtZXdvcmsgd2l0aCBtYW55IG9wdGlvbmFsIGNvbXBvbmVudHMsIG9uIGl0cwogICAg ICAgICAgb3duLCB0aGlzIHNwZWNpZmljYXRpb24gaXMgbGlrZWx5IHRvIHByb2R1Y2UgYSB3aWRl IHJhbmdlIG9mIG5vbi1pbnRlcm9wZXJhYmxlCiAgICAgICAgICBpbXBsZW1lbnRhdGlvbnMuCiAg ICAgICAgCjwvcD4KPHA+CiAgICAgICAgICBJbiBhZGRpdGlvbiwgdGhpcyBzcGVjaWZpY2F0aW9u IGxlYXZlcyBhIGZldyByZXF1aXJlZCBjb21wb25lbnRzIHBhcnRpYWxseSBvciBmdWxseQogICAg ICAgICAgdW5kZWZpbmVkIChlLmcuIGNsaWVudCByZWdpc3RyYXRpb24sIGF1dGhvcml6YXRpb24g c2VydmVyIGNhcGFiaWxpdGllcywgZW5kcG9pbnQKICAgICAgICAgIGRpc2NvdmVyeSkuIFdpdGhv dXQgdGhlc2UgY29tcG9uZW50cywgY2xpZW50cyBtdXN0IGJlIG1hbnVhbGx5IGFuZCBzcGVjaWZp Y2FsbHkKICAgICAgICAgIGNvbmZpZ3VyZWQgYWdhaW5zdCBhIHNwZWNpZmljIGF1dGhvcml6YXRp b24gc2VydmVyIGFuZCByZXNvdXJjZSBzZXJ2ZXIgaW4gb3JkZXIgdG8KICAgICAgICAgIGludGVy b3BlcmF0ZS4KICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgIFRoaXMgZnJhbWV3b3JrIHdhcyBk ZXNpZ25lZCB3aXRoIHRoZSBjbGVhciBleHBlY3RhdGlvbiB0aGF0IGZ1dHVyZSB3b3JrIHdpbGwg ZGVmaW5lCiAgICAgICAgICBwcmVzY3JpcHRpdmUgcHJvZmlsZXMgYW5kIGV4dGVuc2lvbnMgbmVj ZXNzYXJ5IHRvIGFjaGlldmUgZnVsbCB3ZWItc2NhbGUKICAgICAgICAgIGludGVyb3BlcmFiaWxp dHkuCiAgICAgICAgCjwvcD4KPGEgbmFtZT0iYW5jaG9yMTMiPjwvYT48YnIgLz48aHIgLz4KPHRh YmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFz cz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0i I3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMu c2VjdGlvbi4xLjkiPjwvYT48aDM+MS45LiZuYnNwOwpOb3RhdGlvbmFsIENvbnZlbnRpb25zPC9o Mz4KCjxwPgogICAgICAgICAgVGhlIGtleSB3b3JkcyAiTVVTVCIsICJNVVNUIE5PVCIsICJSRVFV SVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1QiLCAiU0hPVUxEIiwgIlNIT1VMRAogICAgICAgICAg Tk9UIiwgIlJFQ09NTUVOREVEIiwgIk1BWSIsIGFuZCAiT1BUSU9OQUwiIGluIHRoaXMgc3BlY2lm aWNhdGlvbiBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMKICAgICAgICAgIGRlc2NyaWJlZCBpbiA8 YSBjbGFzcz0naW5mbycgaHJlZj0nI1JGQzIxMTknPltSRkMyMTE5XTxzcGFuPiAoPC9zcGFuPjxz cGFuIGNsYXNzPSdpbmZvJz5CcmFkbmVyLCBTLiwgJmxkcXVvO0tleSB3b3JkcyBmb3IgdXNlIGlu IFJGQ3MgdG8gSW5kaWNhdGUgUmVxdWlyZW1lbnQgTGV2ZWxzLCZyZHF1bzsgTWFyY2gmbmJzcDsx OTk3Ljwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4uCiAgICAgICAgCjwvcD4KPHA+CiAgICAgICAg ICBUaGlzIHNwZWNpZmljYXRpb24gdXNlcyB0aGUgQXVnbWVudGVkIEJhY2t1cy1OYXVyIEZvcm0g KEFCTkYpIG5vdGF0aW9uIG9mCiAgICAgICAgICA8YSBjbGFzcz0naW5mbycgaHJlZj0nI1JGQzUy MzQnPltSRkM1MjM0XTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5Dcm9ja2VyLCBE LiBhbmQgUC4gT3ZlcmVsbCwgJmxkcXVvO0F1Z21lbnRlZCBCTkYgZm9yIFN5bnRheCBTcGVjaWZp Y2F0aW9uczogQUJORiwmcmRxdW87IEphbnVhcnkmbmJzcDsyMDA4Ljwvc3Bhbj48c3Bhbj4pPC9z cGFuPjwvYT4uCgkgIEFkZGl0aW9uYWxseSwgdGhlIHJ1bGUgVVJJLVJlZmVyZW5jZSBpcyBpbmNs dWRlZCBmcm9tCgkgIFVuaWZvcm0gUmVzb3VyY2UgSWRlbnRpZmllciAoVVJJKSA8YSBjbGFzcz0n aW5mbycgaHJlZj0nI1JGQzM5ODYnPltSRkMzOTg2XTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNz PSdpbmZvJz5CZXJuZXJzLUxlZSwgVC4sIEZpZWxkaW5nLCBSLiwgYW5kIEwuIE1hc2ludGVyLCAm bGRxdW87VW5pZm9ybSBSZXNvdXJjZSBJZGVudGlmaWVyIChVUkkpOiBHZW5lcmljIFN5bnRheCwm cmRxdW87IEphbnVhcnkmbmJzcDsyMDA1Ljwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4uCiAgICAg ICAgCjwvcD4KPHA+CiAgICAgICAgICBDZXJ0YWluIHNlY3VyaXR5LXJlbGF0ZWQgdGVybXMgYXJl IHRvIGJlIHVuZGVyc3Rvb2QgaW4gdGhlIHNlbnNlIGRlZmluZWQgaW4KICAgICAgICAgIDxhIGNs YXNzPSdpbmZvJyBocmVmPScjUkZDNDk0OSc+W1JGQzQ5NDldPHNwYW4+ICg8L3NwYW4+PHNwYW4g Y2xhc3M9J2luZm8nPlNoaXJleSwgUi4sICZsZHF1bztJbnRlcm5ldCBTZWN1cml0eSBHbG9zc2Fy eSwgVmVyc2lvbiAyLCZyZHF1bzsgQXVndXN0Jm5ic3A7MjAwNy48L3NwYW4+PHNwYW4+KTwvc3Bh bj48L2E+LiBUaGVzZSB0ZXJtcyBpbmNsdWRlLCBidXQgYXJlIG5vdCBsaW1pdGVkIHRvLCAiYXR0 YWNrIiwKICAgICAgICAgICJhdXRoZW50aWNhdGlvbiIsICJhdXRob3JpemF0aW9uIiwgImNlcnRp ZmljYXRlIiwgImNvbmZpZGVudGlhbGl0eSIsICJjcmVkZW50aWFsIiwKICAgICAgICAgICJlbmNy eXB0aW9uIiwgImlkZW50aXR5IiwgInNpZ24iLCAic2lnbmF0dXJlIiwgInRydXN0IiwgInZhbGlk YXRlIiwgYW5kICJ2ZXJpZnkiLgogICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgVW5sZXNzIG90 aGVyd2lzZSBub3RlZCwgYWxsIHRoZSBwcm90b2NvbCBwYXJhbWV0ZXIgbmFtZXMgYW5kIHZhbHVl cyBhcmUgY2FzZSBzZW5zaXRpdmUuCiAgICAgICAgCjwvcD4KPGEgbmFtZT0iYW5jaG9yMTQiPjwv YT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNl bGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9 IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3Rh YmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi4yIj48L2E+PGgzPjIuJm5ic3A7CkNsaWVudCBSZWdp c3RyYXRpb248L2gzPgoKPHA+CiAgICAgICAgQmVmb3JlIGluaXRpYXRpbmcgdGhlIHByb3RvY29s LCB0aGUgY2xpZW50IHJlZ2lzdGVycyB3aXRoIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlci4gVGhl CiAgICAgICAgbWVhbnMgdGhyb3VnaCB3aGljaCB0aGUgY2xpZW50IHJlZ2lzdGVycyB3aXRoIHRo ZSBhdXRob3JpemF0aW9uIHNlcnZlciBhcmUgYmV5b25kIHRoZQogICAgICAgIHNjb3BlIG9mIHRo aXMgc3BlY2lmaWNhdGlvbiwgYnV0IHR5cGljYWxseSBpbnZvbHZlIGVuZC11c2VyIGludGVyYWN0 aW9uIHdpdGggYW4gSFRNTAogICAgICAgIHJlZ2lzdHJhdGlvbiBmb3JtLgogICAgICAKPC9wPgo8 cD4KICAgICAgICBDbGllbnQgcmVnaXN0cmF0aW9uIGRvZXMgbm90IHJlcXVpcmUgYSBkaXJlY3Qg aW50ZXJhY3Rpb24gYmV0d2VlbiB0aGUgY2xpZW50IGFuZCB0aGUKICAgICAgICBhdXRob3JpemF0 aW9uIHNlcnZlci4gV2hlbiBzdXBwb3J0ZWQgYnkgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLCBy ZWdpc3RyYXRpb24gY2FuIHJlbHkKICAgICAgICBvbiBvdGhlciBtZWFucyBmb3IgZXN0YWJsaXNo aW5nIHRydXN0IGFuZCBvYnRhaW5pbmcgdGhlIHJlcXVpcmVkIGNsaWVudCBwcm9wZXJ0aWVzIChl LmcuCiAgICAgICAgcmVkaXJlY3Rpb24gVVJJLCBjbGllbnQgdHlwZSkuIEZvciBleGFtcGxlLCBy ZWdpc3RyYXRpb24gY2FuIGJlIGFjY29tcGxpc2hlZCB1c2luZyBhCiAgICAgICAgc2VsZi1pc3N1 ZWQgb3IgdGhpcmQtcGFydHktaXNzdWVkIGFzc2VydGlvbiwgb3IgYnkgdGhlIGF1dGhvcml6YXRp b24gc2VydmVyIHBlcmZvcm1pbmcKICAgICAgICBjbGllbnQgZGlzY292ZXJ5IHVzaW5nIGEgdHJ1 c3RlZCBjaGFubmVsLgogICAgICAKPC9wPgo8cD4KICAgICAgICBXaGVuIHJlZ2lzdGVyaW5nIGEg Y2xpZW50LCB0aGUgY2xpZW50IGRldmVsb3BlciBTSEFMTDoKICAgICAgCjwvcD4KPHA+CiAgICAg ICAgPC9wPgo8dWwgY2xhc3M9InRleHQiPgo8bGk+CiAgICAgICAgICAgIHNwZWNpZnkgdGhlIGNs aWVudCB0eXBlIGFzIGRlc2NyaWJlZCBpbiA8YSBjbGFzcz0naW5mbycgaHJlZj0nI2NsaWVudC10 eXBlcyc+U2VjdGlvbiZuYnNwOzIuMTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5D bGllbnQgVHlwZXM8L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+LAogICAgICAgICAgCjwvbGk+Cjxs aT4KICAgICAgICAgICAgcHJvdmlkZSBpdHMgY2xpZW50IHJlZGlyZWN0aW9uIFVSSXMgYXMgZGVz Y3JpYmVkIGluCiAgICAgICAgICAgIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjcmVkaXJlY3QtdXJp Jz5TZWN0aW9uJm5ic3A7My4xLjI8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+UmVk aXJlY3Rpb24gRW5kcG9pbnQ8L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+LCBhbmQKICAgICAgICAg IAo8L2xpPgo8bGk+CiAgICAgICAgICAgIGluY2x1ZGUgYW55IG90aGVyIGluZm9ybWF0aW9uIHJl cXVpcmVkIGJ5IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciAoZS5nLiBhcHBsaWNhdGlvbgogICAg ICAgICAgICBuYW1lLCB3ZWJzaXRlLCBkZXNjcmlwdGlvbiwgbG9nbyBpbWFnZSwgdGhlIGFjY2Vw dGFuY2Ugb2YgbGVnYWwgdGVybXMpLgogICAgICAgICAgCjwvbGk+CjwvdWw+PHA+CiAgICAgIAo8 L3A+CjxhIG5hbWU9ImNsaWVudC10eXBlcyI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFy eT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWci IGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJz cDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLjIu MSI+PC9hPjxoMz4yLjEuJm5ic3A7CkNsaWVudCBUeXBlczwvaDM+Cgo8cD4KICAgICAgICAgIE9B dXRoIGRlZmluZXMgdHdvIGNsaWVudCB0eXBlcywgYmFzZWQgb24gdGhlaXIgYWJpbGl0eSB0byBh dXRoZW50aWNhdGUgc2VjdXJlbHkgd2l0aCB0aGUKICAgICAgICAgIGF1dGhvcml6YXRpb24gc2Vy dmVyIChpLmUuIGFiaWxpdHkgdG8gbWFpbnRhaW4gdGhlIGNvbmZpZGVudGlhbGl0eSBvZiB0aGVp ciBjbGllbnQKICAgICAgICAgIGNyZWRlbnRpYWxzKToKICAgICAgICAKPC9wPgo8cD4KICAgICAg ICAgIDwvcD4KPGJsb2NrcXVvdGUgY2xhc3M9InRleHQiPjxkbD4KPGR0PmNvbmZpZGVudGlhbDwv ZHQ+CjxkZD4KICAgICAgICAgICAgICAKICAgICAgICAgICAgICBDbGllbnRzIGNhcGFibGUgb2Yg bWFpbnRhaW5pbmcgdGhlIGNvbmZpZGVudGlhbGl0eSBvZiB0aGVpciBjcmVkZW50aWFscyAoZS5n LgogICAgICAgICAgICAgIGNsaWVudCBpbXBsZW1lbnRlZCBvbiBhIHNlY3VyZSBzZXJ2ZXIgd2l0 aCByZXN0cmljdGVkIGFjY2VzcyB0byB0aGUgY2xpZW50CiAgICAgICAgICAgICAgY3JlZGVudGlh bHMpLCBvciBjYXBhYmxlIG9mIHNlY3VyZSBjbGllbnQgYXV0aGVudGljYXRpb24gdXNpbmcgb3Ro ZXIgbWVhbnMuCiAgICAgICAgICAgIAo8L2RkPgo8ZHQ+cHVibGljPC9kdD4KPGRkPgogICAgICAg ICAgICAgIAogICAgICAgICAgICAgIENsaWVudHMgaW5jYXBhYmxlIG9mIG1haW50YWluaW5nIHRo ZSBjb25maWRlbnRpYWxpdHkgb2YgdGhlaXIgY3JlZGVudGlhbHMgKGUuZy4KICAgICAgICAgICAg ICBjbGllbnRzIGV4ZWN1dGluZyBvbiB0aGUgZGV2aWNlIHVzZWQgYnkgdGhlIHJlc291cmNlIG93 bmVyIHN1Y2ggYXMgYW4gaW5zdGFsbGVkCiAgICAgICAgICAgICAgbmF0aXZlIGFwcGxpY2F0aW9u IG9yIGEgd2ViIGJyb3dzZXItYmFzZWQgYXBwbGljYXRpb24pLCBhbmQgaW5jYXBhYmxlIG9mIHNl Y3VyZQogICAgICAgICAgICAgIGNsaWVudCBhdXRoZW50aWNhdGlvbiB2aWEgYW55IG90aGVyIG1l YW5zLgogICAgICAgICAgICAKPC9kZD4KPC9kbD48L2Jsb2NrcXVvdGU+PHA+CiAgICAgICAgCjwv cD4KPHA+CiAgICAgICAgICBUaGUgY2xpZW50IHR5cGUgZGVzaWduYXRpb24gaXMgYmFzZWQgb24g dGhlIGF1dGhvcml6YXRpb24gc2VydmVyJ3MgZGVmaW5pdGlvbiBvZiBzZWN1cmUKICAgICAgICAg IGF1dGhlbnRpY2F0aW9uIGFuZCBpdHMgYWNjZXB0YWJsZSBleHBvc3VyZSBsZXZlbHMgb2YgY2xp ZW50IGNyZWRlbnRpYWxzLiBUaGUKICAgICAgICAgIGF1dGhvcml6YXRpb24gc2VydmVyIFNIT1VM RCBOT1QgbWFrZSBhc3N1bXB0aW9ucyBhYm91dCB0aGUgY2xpZW50IHR5cGUuCiAgICAgICAgCjwv cD4KPHA+CiAgICAgICAgICBBIGNsaWVudCBtYXkgYmUgaW1wbGVtZW50ZWQgYXMgYSBkaXN0cmli dXRlZCBzZXQgb2YgY29tcG9uZW50cywgZWFjaCB3aXRoIGEgZGlmZmVyZW50CiAgICAgICAgICBj bGllbnQgdHlwZSBhbmQgc2VjdXJpdHkgY29udGV4dCAoZS5nLiBhIGRpc3RyaWJ1dGVkIGNsaWVu dCB3aXRoIGJvdGggYSBjb25maWRlbnRpYWwKICAgICAgICAgIHNlcnZlci1iYXNlZCBjb21wb25l bnQgYW5kIGEgcHVibGljIGJyb3dzZXItYmFzZWQgY29tcG9uZW50KS4gSWYgdGhlIGF1dGhvcml6 YXRpb24gc2VydmVyCiAgICAgICAgICBkb2VzIG5vdCBwcm92aWRlIHN1cHBvcnQgZm9yIHN1Y2gg Y2xpZW50cywgb3IgZG9lcyBub3QgcHJvdmlkZSBndWlkYW5jZSB3aXRoIHJlZ2FyZCB0bwogICAg ICAgICAgdGhlaXIgcmVnaXN0cmF0aW9uLCB0aGUgY2xpZW50IFNIT1VMRCByZWdpc3RlciBlYWNo IGNvbXBvbmVudCBhcyBhIHNlcGFyYXRlIGNsaWVudC4KICAgICAgICAKPC9wPgo8cD4KICAgICAg ICAgIFRoaXMgc3BlY2lmaWNhdGlvbiBoYXMgYmVlbiBkZXNpZ25lZCBhcm91bmQgdGhlIGZvbGxv d2luZyBjbGllbnQgcHJvZmlsZXM6CiAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICA8L3A+Cjxi bG9ja3F1b3RlIGNsYXNzPSJ0ZXh0Ij48ZGw+CjxkdD53ZWIgYXBwbGljYXRpb248L2R0Pgo8ZGQ+ CiAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgQSB3ZWIgYXBwbGljYXRpb24gaXMgYSBjb25m aWRlbnRpYWwgY2xpZW50IHJ1bm5pbmcgb24gYSB3ZWIgc2VydmVyLiBSZXNvdXJjZSBvd25lcnMK ICAgICAgICAgICAgICBhY2Nlc3MgdGhlIGNsaWVudCB2aWEgYW4gSFRNTCB1c2VyIGludGVyZmFj ZSByZW5kZXJlZCBpbiBhIHVzZXItYWdlbnQgb24gdGhlIGRldmljZQogICAgICAgICAgICAgIHVz ZWQgYnkgdGhlIHJlc291cmNlIG93bmVyLiBUaGUgY2xpZW50IGNyZWRlbnRpYWxzIGFzIHdlbGwg YXMgYW55IGFjY2VzcyB0b2tlbiBpc3N1ZWQKICAgICAgICAgICAgICB0byB0aGUgY2xpZW50IGFy ZSBzdG9yZWQgb24gdGhlIHdlYiBzZXJ2ZXIgYW5kIGFyZSBub3QgZXhwb3NlZCB0byBvciBhY2Nl c3NpYmxlIGJ5CiAgICAgICAgICAgICAgdGhlIHJlc291cmNlIG93bmVyLgogICAgICAgICAgICAK PC9kZD4KPGR0PnVzZXItYWdlbnQtYmFzZWQgYXBwbGljYXRpb248L2R0Pgo8ZGQ+CiAgICAgICAg ICAgICAgCiAgICAgICAgICAgICAgQSB1c2VyLWFnZW50LWJhc2VkIGFwcGxpY2F0aW9uIGlzIGEg cHVibGljIGNsaWVudCBpbiB3aGljaCB0aGUgY2xpZW50IGNvZGUgaXMKICAgICAgICAgICAgICBk b3dubG9hZGVkIGZyb20gYSB3ZWIgc2VydmVyIGFuZCBleGVjdXRlcyB3aXRoaW4gYSB1c2VyLWFn ZW50IChlLmcuIHdlYiBicm93c2VyKSBvbgogICAgICAgICAgICAgIHRoZSBkZXZpY2UgdXNlZCBi eSB0aGUgcmVzb3VyY2Ugb3duZXIuIFByb3RvY29sIGRhdGEgYW5kIGNyZWRlbnRpYWxzIGFyZSBl YXNpbHkKICAgICAgICAgICAgICBhY2Nlc3NpYmxlIChhbmQgb2Z0ZW4gdmlzaWJsZSkgdG8gdGhl IHJlc291cmNlIG93bmVyLiBTaW5jZSBzdWNoIGFwcGxpY2F0aW9ucyByZXNpZGUKICAgICAgICAg ICAgICB3aXRoaW4gdGhlIHVzZXItYWdlbnQsIHRoZXkgY2FuIG1ha2Ugc2VhbWxlc3MgdXNlIG9m IHRoZSB1c2VyLWFnZW50IGNhcGFiaWxpdGllcyB3aGVuCiAgICAgICAgICAgICAgcmVxdWVzdGlu ZyBhdXRob3JpemF0aW9uLgogICAgICAgICAgICAKPC9kZD4KPGR0Pm5hdGl2ZSBhcHBsaWNhdGlv bjwvZHQ+CjxkZD4KICAgICAgICAgICAgICAKICAgICAgICAgICAgICBBIG5hdGl2ZSBhcHBsaWNh dGlvbiBpcyBhIHB1YmxpYyBjbGllbnQgaW5zdGFsbGVkIGFuZCBleGVjdXRlZCBvbiB0aGUgZGV2 aWNlIHVzZWQgYnkKICAgICAgICAgICAgICB0aGUgcmVzb3VyY2Ugb3duZXIuIFByb3RvY29sIGRh dGEgYW5kIGNyZWRlbnRpYWxzIGFyZSBhY2Nlc3NpYmxlIHRvIHRoZSByZXNvdXJjZQogICAgICAg ICAgICAgIG93bmVyLiBJdCBpcyBhc3N1bWVkIHRoYXQgYW55IGNsaWVudCBhdXRoZW50aWNhdGlv biBjcmVkZW50aWFscyBpbmNsdWRlZCBpbiB0aGUKICAgICAgICAgICAgICBhcHBsaWNhdGlvbiBj YW4gYmUgZXh0cmFjdGVkLiBPbiB0aGUgb3RoZXIgaGFuZCwgZHluYW1pY2FsbHkgaXNzdWVkIGNy ZWRlbnRpYWxzIHN1Y2gKICAgICAgICAgICAgICBhcyBhY2Nlc3MgdG9rZW5zIG9yIHJlZnJlc2gg dG9rZW5zIGNhbiByZWNlaXZlIGFuIGFjY2VwdGFibGUgbGV2ZWwgb2YgcHJvdGVjdGlvbi4gQXQg YQogICAgICAgICAgICAgIG1pbmltdW0sIHRoZXNlIGNyZWRlbnRpYWxzIGFyZSBwcm90ZWN0ZWQg ZnJvbSBob3N0aWxlIHNlcnZlcnMgd2l0aCB3aGljaCB0aGUKICAgICAgICAgICAgICBhcHBsaWNh dGlvbiBtYXkgaW50ZXJhY3Qgd2l0aC4gT24gc29tZSBwbGF0Zm9ybXMgdGhlc2UgY3JlZGVudGlh bHMgbWlnaHQgYmUgcHJvdGVjdGVkCiAgICAgICAgICAgICAgZnJvbSBvdGhlciBhcHBsaWNhdGlv bnMgcmVzaWRpbmcgb24gdGhlIHNhbWUgZGV2aWNlLgogICAgICAgICAgICAKPC9kZD4KPC9kbD48 L2Jsb2NrcXVvdGU+PHA+CiAgICAgICAgCjwvcD4KPGEgbmFtZT0iY2xpZW50LWlkZW50aWZpZXIi PjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAi IGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xh c3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48 L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi4yLjIiPjwvYT48aDM+Mi4yLiZuYnNwOwpDbGll bnQgSWRlbnRpZmllcjwvaDM+Cgo8cD4KICAgICAgICAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZl ciBpc3N1ZXMgdGhlIHJlZ2lzdGVyZWQgY2xpZW50IGEgY2xpZW50IGlkZW50aWZpZXIgLSBhIHVu aXF1ZQogICAgICAgICAgc3RyaW5nIHJlcHJlc2VudGluZyB0aGUgcmVnaXN0cmF0aW9uIGluZm9y bWF0aW9uIHByb3ZpZGVkIGJ5IHRoZSBjbGllbnQuIFRoZSBjbGllbnQKICAgICAgICAgIGlkZW50 aWZpZXIgaXMgbm90IGEgc2VjcmV0OyBpdCBpcyBleHBvc2VkIHRvIHRoZSByZXNvdXJjZSBvd25l ciwgYW5kIE1VU1QgTk9UIGJlIHVzZWQKICAgICAgICAgIGFsb25lIGZvciBjbGllbnQgYXV0aGVu dGljYXRpb24uIFRoZSBjbGllbnQgaWRlbnRpZmllciBpcyB1bmlxdWUgdG8gdGhlIGF1dGhvcml6 YXRpb24KICAgICAgICAgIHNlcnZlci4KICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgIFRoZSBj bGllbnQgaWRlbnRpZmllciBzdHJpbmcgc2l6ZSBpcyBsZWZ0IHVuZGVmaW5lZCBieSB0aGlzIHNw ZWNpZmljYXRpb24uIFRoZSBjbGllbnQKICAgICAgICAgIHNob3VsZCBhdm9pZCBtYWtpbmcgYXNz dW1wdGlvbnMgYWJvdXQgdGhlIGlkZW50aWZpZXIgc2l6ZS4gIFRoZSBhdXRob3JpemF0aW9uIHNl cnZlcgogICAgICAgICAgU0hPVUxEIGRvY3VtZW50IHRoZSBzaXplIG9mIGFueSBpZGVudGlmaWVy IGl0IGlzc3Vlcy4KICAgICAgICAKPC9wPgo8YSBuYW1lPSJjbGllbnQtYXV0aGVudGljYXRpb24i PjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAi IGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xh c3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48 L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi4yLjMiPjwvYT48aDM+Mi4zLiZuYnNwOwpDbGll bnQgQXV0aGVudGljYXRpb248L2gzPgoKPHA+CiAgICAgICAgICBJZiB0aGUgY2xpZW50IHR5cGUg aXMgY29uZmlkZW50aWFsLCB0aGUgY2xpZW50IGFuZCBhdXRob3JpemF0aW9uIHNlcnZlciBlc3Rh Ymxpc2ggYSBjbGllbnQKICAgICAgICAgIGF1dGhlbnRpY2F0aW9uIG1ldGhvZCBzdWl0YWJsZSBm b3IgdGhlIHNlY3VyaXR5IHJlcXVpcmVtZW50cyBvZiB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIu CiAgICAgICAgICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTUFZIGFjY2VwdCBhbnkgZm9ybSBv ZiBjbGllbnQgYXV0aGVudGljYXRpb24gbWVldGluZyBpdHMKICAgICAgICAgIHNlY3VyaXR5IHJl cXVpcmVtZW50cy4KICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgIENvbmZpZGVudGlhbCBjbGll bnRzIGFyZSB0eXBpY2FsbHkgaXNzdWVkIChvciBlc3RhYmxpc2gpIGEgc2V0IG9mIGNsaWVudCBj cmVkZW50aWFscyB1c2VkIGZvcgogICAgICAgICAgYXV0aGVudGljYXRpbmcgd2l0aCB0aGUgYXV0 aG9yaXphdGlvbiBzZXJ2ZXIgKGUuZy4gcGFzc3dvcmQsIHB1YmxpYy9wcml2YXRlIGtleSBwYWly KS4KICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBN QVkgZXN0YWJsaXNoIGEgY2xpZW50IGF1dGhlbnRpY2F0aW9uIG1ldGhvZCB3aXRoIHB1YmxpYyBj bGllbnRzLgogICAgICAgICAgSG93ZXZlciwgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIE1VU1Qg Tk9UIHJlbHkgb24gcHVibGljIGNsaWVudCBhdXRoZW50aWNhdGlvbiBmb3IgdGhlCiAgICAgICAg ICBwdXJwb3NlIG9mIGlkZW50aWZ5aW5nIHRoZSBjbGllbnQuCiAgICAgICAgCjwvcD4KPHA+CiAg ICAgICAgICBUaGUgY2xpZW50IE1VU1QgTk9UIHVzZSBtb3JlIHRoYW4gb25lIGF1dGhlbnRpY2F0 aW9uIG1ldGhvZCBpbiBlYWNoIHJlcXVlc3QuCiAgICAgICAgCjwvcD4KPGEgbmFtZT0iY2xpZW50 LXBhc3N3b3JkIj48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxw YWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48 dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48 L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uMi4zLjEiPjwvYT48aDM+Mi4z LjEuJm5ic3A7CkNsaWVudCBQYXNzd29yZDwvaDM+Cgo8cD4KICAgICAgICAgICAgQ2xpZW50cyBp biBwb3NzZXNzaW9uIG9mIGEgY2xpZW50IHBhc3N3b3JkIE1BWSB1c2UgdGhlIEhUVFAgQmFzaWMg YXV0aGVudGljYXRpb24gc2NoZW1lCiAgICAgICAgICAgIGFzIGRlZmluZWQgaW4gPGEgY2xhc3M9 J2luZm8nIGhyZWY9JyNSRkMyNjE3Jz5bUkZDMjYxN108c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFz cz0naW5mbyc+RnJhbmtzLCBKLiwgSGFsbGFtLUJha2VyLCBQLiwgSG9zdGV0bGVyLCBKLiwgTGF3 cmVuY2UsIFMuLCBMZWFjaCwgUC4sIEx1b3RvbmVuLCBBLiwgYW5kIEwuIFN0ZXdhcnQsICZsZHF1 bztIVFRQIEF1dGhlbnRpY2F0aW9uOiBCYXNpYyBhbmQgRGlnZXN0IEFjY2VzcyBBdXRoZW50aWNh dGlvbiwmcmRxdW87IEp1bmUmbmJzcDsxOTk5Ljwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4gdG8g YXV0aGVudGljYXRlIHdpdGggdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLgogICAgICAgICAgICBU aGUgY2xpZW50IGlkZW50aWZpZXIgaXMgZW5jb2RlZCB1c2luZyB0aGUKCSAgICA8dHQ+YXBwbGlj YXRpb24veC13d3ctZm9ybS11cmxlbmNvZGVkPC90dD4KCSAgICBjb250ZW50LXR5cGUgZW5jb2Rp bmcgbWV0aG9kIGRlZmluZWQgYnkKCSAgICBIVE1MIDQuMDEgPGEgY2xhc3M9J2luZm8nIGhyZWY9 JyNXM0MuUkVDLWh0bWw0MDEtMTk5OTEyMjQnPltXM0MuUkVDJiM4MjA5O2h0bWw0MDEmIzgyMDk7 MTk5OTEyMjRdPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkhvcnMsIEEuLCBSYWdn ZXR0LCBELiwgYW5kIEkuIEphY29icywgJmxkcXVvO0hUTUwgNC4wMSBTcGVjaWZpY2F0aW9uLCZy ZHF1bzsgRGVjZW1iZXImbmJzcDsxOTk5Ljwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4gYW5kIHRo ZSBlbmNvZGVkIHZhbHVlIGlzCgkgICAgdXNlZCBhcyB0aGUgdXNlcm5hbWU7IHRoZSBjbGllbnQg cGFzc3dvcmQgaXMgdXNlZCBhcyB0aGUKICAgICAgICAgICAgcGFzc3dvcmQuIFRoZSBhdXRob3Jp emF0aW9uIHNlcnZlciBNVVNUIHN1cHBvcnQgdGhlIEhUVFAgQmFzaWMgYXV0aGVudGljYXRpb24g c2NoZW1lCiAgICAgICAgICAgIGZvciBhdXRoZW50aWNhdGluZyBjbGllbnRzIHRoYXQgd2VyZSBp c3N1ZWQgYSBjbGllbnQgcGFzc3dvcmQuCiAgICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgICAg ICBGb3IgZXhhbXBsZSAoZXh0cmEgbGluZSBicmVha3MgYXJlIGZvciBkaXNwbGF5IHB1cnBvc2Vz IG9ubHkpOgogICAgICAgICAgICAKPC9wPjxkaXYgc3R5bGU9J2Rpc3BsYXk6IHRhYmxlOyB3aWR0 aDogMDsgbWFyZ2luLWxlZnQ6IDNlbTsgbWFyZ2luLXJpZ2h0OiBhdXRvJz48cHJlPgoKICBBdXRo b3JpemF0aW9uOiBCYXNpYyBjelpDYUdSU2EzRjBNem8zUm1wbWNEQmFRbkl4UzNSRVVtSnVabFpr YlVsMwoKPC9wcmU+PC9kaXY+CjxwPgogICAgICAgICAgICBBbHRlcm5hdGl2ZWx5LCB0aGUgYXV0 aG9yaXphdGlvbiBzZXJ2ZXIgTUFZIHN1cHBvcnQgaW5jbHVkaW5nIHRoZSBjbGllbnQgY3JlZGVu dGlhbHMgaW4KICAgICAgICAgICAgdGhlIHJlcXVlc3QgYm9keSB1c2luZyB0aGUgZm9sbG93aW5n IHBhcmFtZXRlcnM6CiAgICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgICAgPC9wPgo8YmxvY2tx dW90ZSBjbGFzcz0idGV4dCI+PGRsPgo8ZHQ+Y2xpZW50X2lkPC9kdD4KPGRkPgogICAgICAgICAg ICAgICAgCiAgICAgICAgICAgICAgICBSRVFVSVJFRC4gVGhlIGNsaWVudCBpZGVudGlmaWVyIGlz c3VlZCB0byB0aGUgY2xpZW50IGR1cmluZyB0aGUgcmVnaXN0cmF0aW9uIHByb2Nlc3MKICAgICAg ICAgICAgICAgIGRlc2NyaWJlZCBieSA8YSBjbGFzcz0naW5mbycgaHJlZj0nI2NsaWVudC1pZGVu dGlmaWVyJz5TZWN0aW9uJm5ic3A7Mi4yPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8n PkNsaWVudCBJZGVudGlmaWVyPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPi4KICAgICAgICAgICAg ICAKPC9kZD4KPGR0PmNsaWVudF9zZWNyZXQ8L2R0Pgo8ZGQ+CiAgICAgICAgICAgICAgICAKICAg ICAgICAgICAgICAgIFJFUVVJUkVELiBUaGUgY2xpZW50IHNlY3JldC4gVGhlIGNsaWVudCBNQVkg b21pdCB0aGUgcGFyYW1ldGVyIGlmIHRoZSBjbGllbnQgc2VjcmV0CiAgICAgICAgICAgICAgICBp cyBhbiBlbXB0eSBzdHJpbmcuCiAgICAgICAgICAgICAgCjwvZGQ+CjwvZGw+PC9ibG9ja3F1b3Rl PjxwPgogICAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICAgIEluY2x1ZGluZyB0aGUgY2xpZW50 IGNyZWRlbnRpYWxzIGluIHRoZSByZXF1ZXN0IGJvZHkgdXNpbmcgdGhlIHR3byBwYXJhbWV0ZXJz IGlzIE5PVAogICAgICAgICAgICBSRUNPTU1FTkRFRCwgYW5kIFNIT1VMRCBiZSBsaW1pdGVkIHRv IGNsaWVudHMgdW5hYmxlIHRvIGRpcmVjdGx5IHV0aWxpemUgdGhlIEhUVFAgQmFzaWMKICAgICAg ICAgICAgYXV0aGVudGljYXRpb24gc2NoZW1lIChvciBvdGhlciBwYXNzd29yZC1iYXNlZCBIVFRQ IGF1dGhlbnRpY2F0aW9uIHNjaGVtZXMpLiBUaGUKICAgICAgICAgICAgcGFyYW1ldGVycyBjYW4g b25seSBiZSB0cmFuc21pdHRlZCBpbiB0aGUgcmVxdWVzdCBib2R5IGFuZCBNVVNUIE5PVCBiZSBp bmNsdWRlZCBpbiB0aGUKICAgICAgICAgICAgcmVxdWVzdCBVUkkuCiAgICAgICAgICAKPC9wPgo8 cD4KICAgICAgICAgICAgICBGb3IgZXhhbXBsZSwgcmVxdWVzdGluZyB0byByZWZyZXNoIGFuIGFj Y2VzcyB0b2tlbiAoPGEgY2xhc3M9J2luZm8nIGhyZWY9JyN0b2tlbi1yZWZyZXNoJz5TZWN0aW9u Jm5ic3A7NjxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5SZWZyZXNoaW5nIGFuIEFj Y2VzcyBUb2tlbjwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4pCiAgICAgICAgICAgICAgdXNpbmcg dGhlIGJvZHkgcGFyYW1ldGVycyAoZXh0cmEgbGluZSBicmVha3MgYXJlIGZvciBkaXNwbGF5IHB1 cnBvc2VzIG9ubHkpOgogICAgICAgICAgICAKPC9wPjxkaXYgc3R5bGU9J2Rpc3BsYXk6IHRhYmxl OyB3aWR0aDogMDsgbWFyZ2luLWxlZnQ6IDNlbTsgbWFyZ2luLXJpZ2h0OiBhdXRvJz48cHJlPgoK ICBQT1NUIC90b2tlbiBIVFRQLzEuMQogIEhvc3Q6IHNlcnZlci5leGFtcGxlLmNvbQogIENvbnRl bnQtVHlwZTogYXBwbGljYXRpb24veC13d3ctZm9ybS11cmxlbmNvZGVkO2NoYXJzZXQ9VVRGLTgK CiAgZ3JhbnRfdHlwZT1yZWZyZXNoX3Rva2VuJmFtcDtyZWZyZXNoX3Rva2VuPXRHenYzSk9rRjBY RzVReDJUbEtXSUEKICAmYW1wO2NsaWVudF9pZD1zNkJoZFJrcXQzJmFtcDtjbGllbnRfc2VjcmV0 PTdGamZwMFpCcjFLdERSYm5mVmRtSXcKCjwvcHJlPjwvZGl2Pgo8cD4KICAgICAgICAgICAgVGhl IGF1dGhvcml6YXRpb24gc2VydmVyIE1VU1QgcmVxdWlyZSB0aGUgdXNlIG9mIFRMUyBhcyBkZXNj cmliZWQgaW4KICAgICAgICAgICAgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyN0bHMnPlNlY3Rpb24m bmJzcDsxLjY8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+VExTIFZlcnNpb248L3Nw YW4+PHNwYW4+KTwvc3Bhbj48L2E+IHdoZW4gc2VuZGluZyByZXF1ZXN0cyB1c2luZyBwYXNzd29y ZCBhdXRoZW50aWNhdGlvbi4KICAgICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgICBTaW5jZSB0 aGlzIGNsaWVudCBhdXRoZW50aWNhdGlvbiBtZXRob2QgaW52b2x2ZXMgYSBwYXNzd29yZCwgdGhl IGF1dGhvcml6YXRpb24gc2VydmVyCiAgICAgICAgICAgIE1VU1QgcHJvdGVjdCBhbnkgZW5kcG9p bnQgdXRpbGl6aW5nIGl0IGFnYWluc3QgYnJ1dGUgZm9yY2UgYXR0YWNrcy4KICAgICAgICAgIAo8 L3A+CjxhIG5hbWU9ImFuY2hvcjE1Ij48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJs YXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxp Z249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RP QyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uMi4zLjIi PjwvYT48aDM+Mi4zLjIuJm5ic3A7Ck90aGVyIEF1dGhlbnRpY2F0aW9uIE1ldGhvZHM8L2gzPgoK PHA+CiAgICAgICAgICAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBNQVkgc3VwcG9ydCBhbnkg c3VpdGFibGUgSFRUUCBhdXRoZW50aWNhdGlvbiBzY2hlbWUgbWF0Y2hpbmcKICAgICAgICAgICAg aXRzIHNlY3VyaXR5IHJlcXVpcmVtZW50cy4gV2hlbiB1c2luZyBvdGhlciBhdXRoZW50aWNhdGlv biBtZXRob2RzLCB0aGUgYXV0aG9yaXphdGlvbgogICAgICAgICAgICBzZXJ2ZXIgTVVTVCBkZWZp bmUgYSBtYXBwaW5nIGJldHdlZW4gdGhlIGNsaWVudCBpZGVudGlmaWVyIChyZWdpc3RyYXRpb24g cmVjb3JkKSBhbmQKICAgICAgICAgICAgYXV0aGVudGljYXRpb24gc2NoZW1lLgogICAgICAgICAg CjwvcD4KPGEgbmFtZT0iYW5jaG9yMTYiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9 ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBh bGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7 VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi4yLjQi PjwvYT48aDM+Mi40LiZuYnNwOwpVbnJlZ2lzdGVyZWQgQ2xpZW50czwvaDM+Cgo8cD4KICAgICAg ICAgIFRoaXMgc3BlY2lmaWNhdGlvbiBkb2VzIG5vdCBleGNsdWRlIHRoZSB1c2Ugb2YgdW5yZWdp c3RlcmVkIGNsaWVudHMuIEhvd2V2ZXIsIHRoZSB1c2UKICAgICAgICAgIHdpdGggc3VjaCBjbGll bnRzIGlzIGJleW9uZCB0aGUgc2NvcGUgb2YgdGhpcyBzcGVjaWZpY2F0aW9uLCBhbmQgcmVxdWly ZXMgYWRkaXRpb25hbAogICAgICAgICAgc2VjdXJpdHkgYW5hbHlzaXMgYW5kIHJldmlldyBvZiBp dHMgaW50ZXJvcGVyYWJpbGl0eSBpbXBhY3QuCiAgICAgICAgCjwvcD4KPGEgbmFtZT0iYW5jaG9y MTciPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9 IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQg Y2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90 cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi4zIj48L2E+PGgzPjMuJm5ic3A7ClByb3Rv Y29sIEVuZHBvaW50czwvaDM+Cgo8cD4KICAgICAgICBUaGUgYXV0aG9yaXphdGlvbiBwcm9jZXNz IHV0aWxpemVzIHR3byBhdXRob3JpemF0aW9uIHNlcnZlciBlbmRwb2ludHMgKEhUVFAgcmVzb3Vy Y2VzKToKICAgICAgCjwvcD4KPHA+CiAgICAgICAgPC9wPgo8dWwgY2xhc3M9InRleHQiPgo8bGk+ CiAgICAgICAgICAgIEF1dGhvcml6YXRpb24gZW5kcG9pbnQgLSB1c2VkIGJ5IHRoZSBjbGllbnQg dG8gb2J0YWluIGF1dGhvcml6YXRpb24gZnJvbSB0aGUgcmVzb3VyY2UKICAgICAgICAgICAgb3du ZXIgdmlhIHVzZXItYWdlbnQgcmVkaXJlY3Rpb24uCiAgICAgICAgICAKPC9saT4KPGxpPgogICAg ICAgICAgICBUb2tlbiBlbmRwb2ludCAtIHVzZWQgYnkgdGhlIGNsaWVudCB0byBleGNoYW5nZSBh biBhdXRob3JpemF0aW9uIGdyYW50IGZvciBhbiBhY2Nlc3MKICAgICAgICAgICAgdG9rZW4sIHR5 cGljYWxseSB3aXRoIGNsaWVudCBhdXRoZW50aWNhdGlvbi4KICAgICAgICAgIAo8L2xpPgo8L3Vs PjxwPgogICAgICAKPC9wPgo8cD4KICAgICAgICBBcyB3ZWxsIGFzIG9uZSBjbGllbnQgZW5kcG9p bnQ6CiAgICAgIAo8L3A+CjxwPgogICAgICAgIDwvcD4KPHVsIGNsYXNzPSJ0ZXh0Ij4KPGxpPgog ICAgICAgICAgICBSZWRpcmVjdGlvbiBlbmRwb2ludCAtIHVzZWQgYnkgdGhlIGF1dGhvcml6YXRp b24gc2VydmVyIHRvIHJldHVybiBhdXRob3JpemF0aW9uCiAgICAgICAgICAgIGNyZWRlbnRpYWxz IHJlc3BvbnNlcyB0byB0aGUgY2xpZW50IHZpYSB0aGUgcmVzb3VyY2Ugb3duZXIgdXNlci1hZ2Vu dC4KICAgICAgICAgIAo8L2xpPgo8L3VsPjxwPgogICAgICAKPC9wPgo8cD4KICAgICAgICBOb3Qg ZXZlcnkgYXV0aG9yaXphdGlvbiBncmFudCB0eXBlIHV0aWxpemVzIGJvdGggZW5kcG9pbnRzLiBF eHRlbnNpb24gZ3JhbnQgdHlwZXMgTUFZCiAgICAgICAgZGVmaW5lIGFkZGl0aW9uYWwgZW5kcG9p bnRzIGFzIG5lZWRlZC4KICAgICAgCjwvcD4KPGEgbmFtZT0iYW5jaG9yMTgiPjwvYT48YnIgLz48 aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5n PSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+ PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBu YW1lPSJyZmMuc2VjdGlvbi4zLjEiPjwvYT48aDM+My4xLiZuYnNwOwpBdXRob3JpemF0aW9uIEVu ZHBvaW50PC9oMz4KCjxwPgogICAgICAgICAgVGhlIGF1dGhvcml6YXRpb24gZW5kcG9pbnQgaXMg dXNlZCB0byBpbnRlcmFjdCB3aXRoIHRoZSByZXNvdXJjZSBvd25lciBhbmQgb2J0YWluCiAgICAg ICAgICBhbiBhdXRob3JpemF0aW9uIGdyYW50LiBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVT VCBmaXJzdCB2ZXJpZnkgdGhlIGlkZW50aXR5IG9mIHRoZQogICAgICAgICAgcmVzb3VyY2Ugb3du ZXIuIFRoZSB3YXkgaW4gd2hpY2ggdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGF1dGhlbnRpY2F0 ZXMgdGhlIHJlc291cmNlCiAgICAgICAgICBvd25lciAoZS5nLiB1c2VybmFtZSBhbmQgcGFzc3dv cmQgbG9naW4sIHNlc3Npb24gY29va2llcykgaXMgYmV5b25kIHRoZSBzY29wZSBvZiB0aGlzCiAg ICAgICAgICBzcGVjaWZpY2F0aW9uLgogICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgVGhlIG1l YW5zIHRocm91Z2ggd2hpY2ggdGhlIGNsaWVudCBvYnRhaW5zIHRoZSBsb2NhdGlvbiBvZiB0aGUg YXV0aG9yaXphdGlvbiBlbmRwb2ludCBhcmUKICAgICAgICAgIGJleW9uZCB0aGUgc2NvcGUgb2Yg dGhpcyBzcGVjaWZpY2F0aW9uLCBidXQgdGhlIGxvY2F0aW9uIGlzIHR5cGljYWxseSBwcm92aWRl ZCBpbiB0aGUKICAgICAgICAgIHNlcnZpY2UgZG9jdW1lbnRhdGlvbi4KICAgICAgICAKPC9wPgo8 cD4KICAgICAgICAgIFRoZSBlbmRwb2ludCBVUkkgTUFZIGluY2x1ZGUgYW4KICAgICAgICAgIDx0 dD5hcHBsaWNhdGlvbi94LXd3dy1mb3JtLXVybGVuY29kZWQ8L3R0PiBmb3JtYXR0ZWQKICAgICAg ICAgICg8YSBjbGFzcz0naW5mbycgaHJlZj0nI1czQy5SRUMtaHRtbDQwMS0xOTk5MTIyNCc+W1cz Qy5SRUMmIzgyMDk7aHRtbDQwMSYjODIwOTsxOTk5MTIyNF08c3Bhbj4gKDwvc3Bhbj48c3BhbiBj bGFzcz0naW5mbyc+SG9ycywgQS4sIFJhZ2dldHQsIEQuLCBhbmQgSS4gSmFjb2JzLCAmbGRxdW87 SFRNTCA0LjAxIFNwZWNpZmljYXRpb24sJnJkcXVvOyBEZWNlbWJlciZuYnNwOzE5OTkuPC9zcGFu PjxzcGFuPik8L3NwYW4+PC9hPikgcXVlcnkgY29tcG9uZW50ICg8YSBjbGFzcz0naW5mbycgaHJl Zj0nI1JGQzM5ODYnPltSRkMzOTg2XTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5C ZXJuZXJzLUxlZSwgVC4sIEZpZWxkaW5nLCBSLiwgYW5kIEwuIE1hc2ludGVyLCAmbGRxdW87VW5p Zm9ybSBSZXNvdXJjZSBJZGVudGlmaWVyIChVUkkpOiBHZW5lcmljIFN5bnRheCwmcmRxdW87IEph bnVhcnkmbmJzcDsyMDA1Ljwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4KICAgICAgICAgIHNlY3Rp b24gMy40KSwgd2hpY2ggTVVTVCBiZSByZXRhaW5lZCB3aGVuIGFkZGluZyBhZGRpdGlvbmFsIHF1 ZXJ5IHBhcmFtZXRlcnMuIFRoZQogICAgICAgICAgZW5kcG9pbnQgVVJJIE1VU1QgTk9UIGluY2x1 ZGUgYSBmcmFnbWVudCBjb21wb25lbnQuCiAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICBTaW5j ZSByZXF1ZXN0cyB0byB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludCByZXN1bHQgaW4gdXNlciBh dXRoZW50aWNhdGlvbiBhbmQgdGhlCiAgICAgICAgICB0cmFuc21pc3Npb24gb2YgY2xlYXItdGV4 dCBjcmVkZW50aWFscyAoaW4gdGhlIEhUVFAgcmVzcG9uc2UpLCB0aGUgYXV0aG9yaXphdGlvbiBz ZXJ2ZXIKICAgICAgICAgIE1VU1QgcmVxdWlyZSB0aGUgdXNlIG9mIFRMUyBhcyBkZXNjcmliZWQg aW4gPGEgY2xhc3M9J2luZm8nIGhyZWY9JyN0bHMnPlNlY3Rpb24mbmJzcDsxLjY8c3Bhbj4gKDwv c3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+VExTIFZlcnNpb248L3NwYW4+PHNwYW4+KTwvc3Bhbj48 L2E+IHdoZW4gc2VuZGluZyByZXF1ZXN0cwogICAgICAgICAgdG8gdGhlIGF1dGhvcml6YXRpb24g ZW5kcG9pbnQuCiAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICBUaGUgYXV0aG9yaXphdGlvbiBz ZXJ2ZXIgTVVTVCBzdXBwb3J0IHRoZSB1c2Ugb2YgdGhlIEhUVFAgPHR0PkdFVDwvdHQ+CiAgICAg ICAgICBtZXRob2QgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNSRkMyNjE2Jz5bUkZDMjYxNl08c3Bh bj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+RmllbGRpbmcsIFIuLCBHZXR0eXMsIEouLCBN b2d1bCwgSi4sIEZyeXN0eWssIEguLCBNYXNpbnRlciwgTC4sIExlYWNoLCBQLiwgYW5kIFQuIEJl cm5lcnMtTGVlLCAmbGRxdW87SHlwZXJ0ZXh0IFRyYW5zZmVyIFByb3RvY29sIC0tIEhUVFAvMS4x LCZyZHF1bzsgSnVuZSZuYnNwOzE5OTkuPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPiBmb3IgdGhl IGF1dGhvcml6YXRpb24gZW5kcG9pbnQsIGFuZCBNQVkgc3VwcG9ydCB0aGUgdXNlCiAgICAgICAg ICBvZiB0aGUgPHR0PlBPU1Q8L3R0PiBtZXRob2QgYXMgd2VsbC4KICAgICAgICAKPC9wPgo8cD4K ICAgICAgICAgIFBhcmFtZXRlcnMgc2VudCB3aXRob3V0IGEgdmFsdWUgTVVTVCBiZSB0cmVhdGVk IGFzIGlmIHRoZXkgd2VyZSBvbWl0dGVkIGZyb20gdGhlIHJlcXVlc3QuCiAgICAgICAgICBUaGUg YXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVTVCBpZ25vcmUgdW5yZWNvZ25pemVkIHJlcXVlc3QgcGFy YW1ldGVycy4gUmVxdWVzdCBhbmQKICAgICAgICAgIHJlc3BvbnNlIHBhcmFtZXRlcnMgTVVTVCBO T1QgYmUgaW5jbHVkZWQgbW9yZSB0aGFuIG9uY2UuCiAgICAgICAgCjwvcD4KPGEgbmFtZT0icmVz cG9uc2UtdHlwZSI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxs cGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+ PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+ PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLjMuMS4xIj48L2E+PGgzPjMu MS4xLiZuYnNwOwpSZXNwb25zZSBUeXBlPC9oMz4KCjxwPgogICAgICAgICAgICBUaGUgYXV0aG9y aXphdGlvbiBlbmRwb2ludCBpcyB1c2VkIGJ5IHRoZSBhdXRob3JpemF0aW9uIGNvZGUgZ3JhbnQg dHlwZSBhbmQgaW1wbGljaXQKICAgICAgICAgICAgZ3JhbnQgdHlwZSBmbG93cy4gVGhlIGNsaWVu dCBpbmZvcm1zIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBvZiB0aGUgZGVzaXJlZCBncmFudAog ICAgICAgICAgICB0eXBlIHVzaW5nIHRoZSBmb2xsb3dpbmcgcGFyYW1ldGVyOgogICAgICAgICAg CjwvcD4KPHA+CiAgICAgICAgICAgIDwvcD4KPGJsb2NrcXVvdGUgY2xhc3M9InRleHQiPjxkbD4K PGR0PnJlc3BvbnNlX3R5cGU8L2R0Pgo8ZGQ+CiAgICAgICAgICAgICAgICAKICAgICAgICAgICAg ICAgIFJFUVVJUkVELiBUaGUgdmFsdWUgTVVTVCBiZSBvbmUgb2YgPHR0PmNvZGU8L3R0PiBmb3Ig cmVxdWVzdGluZwogICAgICAgICAgICAgICAgYW4gYXV0aG9yaXphdGlvbiBjb2RlIGFzIGRlc2Ny aWJlZCBieSA8YSBjbGFzcz0naW5mbycgaHJlZj0nI2NvZGUtYXV0aHotcmVxJz5TZWN0aW9uJm5i c3A7NC4xLjE8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+QXV0aG9yaXphdGlvbiBS ZXF1ZXN0PC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPiwKICAgICAgICAgICAgICAgIDx0dD50b2tl bjwvdHQ+IGZvciByZXF1ZXN0aW5nIGFuIGFjY2VzcyB0b2tlbiAoaW1wbGljaXQgZ3JhbnQpCiAg ICAgICAgICAgICAgICBhcyBkZXNjcmliZWQgYnkgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNpbXBs aWNpdC1hdXRoei1yZXEnPlNlY3Rpb24mbmJzcDs0LjIuMTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNs YXNzPSdpbmZvJz5BdXRob3JpemF0aW9uIFJlcXVlc3Q8L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+ LCBvciBhIHJlZ2lzdGVyZWQgZXh0ZW5zaW9uCiAgICAgICAgICAgICAgICB2YWx1ZSBhcyBkZXNj cmliZWQgYnkgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNyZXNwb25zZS10eXBlLWV4dCc+U2VjdGlv biZuYnNwOzguNDxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5EZWZpbmluZyBOZXcg QXV0aG9yaXphdGlvbiBFbmRwb2ludCBSZXNwb25zZSBUeXBlczwvc3Bhbj48c3Bhbj4pPC9zcGFu PjwvYT4uCiAgICAgICAgICAgICAgCjwvZGQ+CjwvZGw+PC9ibG9ja3F1b3RlPjxwPgogICAgICAg ICAgCjwvcD4KPHA+CiAgICAgICAgICAgIEV4dGVuc2lvbiByZXNwb25zZSB0eXBlcyBNQVkgY29u dGFpbiBhIHNwYWNlLWRlbGltaXRlZCAoJXgyMCkgbGlzdCBvZiB2YWx1ZXMsIHdoZXJlIHRoZQog ICAgICAgICAgICBvcmRlciBvZiB2YWx1ZXMgZG9lcyBub3QgbWF0dGVyIChlLmcuIHJlc3BvbnNl IHR5cGUgPHR0PmEgYjwvdHQ+IGlzCiAgICAgICAgICAgIHRoZSBzYW1lIGFzIDx0dD5iIGE8L3R0 PikuIFRoZSBtZWFuaW5nIG9mIHN1Y2ggY29tcG9zaXRlIHJlc3BvbnNlCiAgICAgICAgICAgIHR5 cGVzIGlzIGRlZmluZWQgYnkgdGhlaXIgcmVzcGVjdGl2ZSBzcGVjaWZpY2F0aW9ucy4KICAgICAg ICAgIAo8L3A+CjxwPgogICAgICAgICAgICBJZiBhbiBhdXRob3JpemF0aW9uIHJlcXVlc3QgaXMg bWlzc2luZyB0aGUgPHR0PnJlc3BvbnNlX3R5cGU8L3R0PgogICAgICAgICAgICBwYXJhbWV0ZXIs IG9yIGlmIHRoZSByZXNwb25zZSB0eXBlIGlzIG5vdCB1bmRlcnN0b29kLCB0aGUgYXV0aG9yaXph dGlvbiBzZXJ2ZXIgTVVTVAogICAgICAgICAgICByZXR1cm4gYW4gZXJyb3IgcmVzcG9uc2UgYXMg ZGVzY3JpYmVkIGluIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjY29kZS1hdXRoei1lcnJvcic+U2Vj dGlvbiZuYnNwOzQuMS4yLjE8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+RXJyb3Ig UmVzcG9uc2U8L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+LgogICAgICAgICAgCjwvcD4KPGEgbmFt ZT0icmVkaXJlY3QtdXJpIj48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQi IGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJp Z2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNw OzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uMy4xLjIiPjwvYT48 aDM+My4xLjIuJm5ic3A7ClJlZGlyZWN0aW9uIEVuZHBvaW50PC9oMz4KCjxwPgogICAgICAgICAg ICBBZnRlciBjb21wbGV0aW5nIGl0cyBpbnRlcmFjdGlvbiB3aXRoIHRoZSByZXNvdXJjZSBvd25l ciwgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyCiAgICAgICAgICAgIGRpcmVjdHMgdGhlIHJlc291 cmNlIG93bmVyJ3MgdXNlci1hZ2VudCBiYWNrIHRvIHRoZSBjbGllbnQuIFRoZSBhdXRob3JpemF0 aW9uIHNlcnZlcgogICAgICAgICAgICByZWRpcmVjdHMgdGhlIHVzZXItYWdlbnQgdG8gdGhlIGNs aWVudCdzIHJlZGlyZWN0aW9uIGVuZHBvaW50IHByZXZpb3VzbHkgZXN0YWJsaXNoZWQKICAgICAg ICAgICAgd2l0aCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgZHVyaW5nIHRoZSBjbGllbnQgcmVn aXN0cmF0aW9uIHByb2Nlc3Mgb3Igd2hlbiBtYWtpbmcKICAgICAgICAgICAgdGhlIGF1dGhvcml6 YXRpb24gcmVxdWVzdC4KICAgICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgICBUaGUgcmVkaXJl Y3Rpb24gZW5kcG9pbnQgVVJJIE1VU1QgYmUgYW4gYWJzb2x1dGUgVVJJIGFzIGRlZmluZWQgYnkK ICAgICAgICAgICAgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNSRkMzOTg2Jz5bUkZDMzk4Nl08c3Bh bj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+QmVybmVycy1MZWUsIFQuLCBGaWVsZGluZywg Ui4sIGFuZCBMLiBNYXNpbnRlciwgJmxkcXVvO1VuaWZvcm0gUmVzb3VyY2UgSWRlbnRpZmllciAo VVJJKTogR2VuZXJpYyBTeW50YXgsJnJkcXVvOyBKYW51YXJ5Jm5ic3A7MjAwNS48L3NwYW4+PHNw YW4+KTwvc3Bhbj48L2E+IHNlY3Rpb24gNC4zLiBUaGUgZW5kcG9pbnQgVVJJIE1BWSBpbmNsdWRl IGFuCiAgICAgICAgICAgIDx0dD5hcHBsaWNhdGlvbi94LXd3dy1mb3JtLXVybGVuY29kZWQ8L3R0 PiBmb3JtYXR0ZWQKICAgICAgICAgICAgKDxhIGNsYXNzPSdpbmZvJyBocmVmPScjVzNDLlJFQy1o dG1sNDAxLTE5OTkxMjI0Jz5bVzNDLlJFQyYjODIwOTtodG1sNDAxJiM4MjA5OzE5OTkxMjI0XTxz cGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5Ib3JzLCBBLiwgUmFnZ2V0dCwgRC4sIGFu ZCBJLiBKYWNvYnMsICZsZHF1bztIVE1MIDQuMDEgU3BlY2lmaWNhdGlvbiwmcmRxdW87IERlY2Vt YmVyJm5ic3A7MTk5OS48L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+KSBxdWVyeSBjb21wb25lbnQg KDxhIGNsYXNzPSdpbmZvJyBocmVmPScjUkZDMzk4Nic+W1JGQzM5ODZdPHNwYW4+ICg8L3NwYW4+ PHNwYW4gY2xhc3M9J2luZm8nPkJlcm5lcnMtTGVlLCBULiwgRmllbGRpbmcsIFIuLCBhbmQgTC4g TWFzaW50ZXIsICZsZHF1bztVbmlmb3JtIFJlc291cmNlIElkZW50aWZpZXIgKFVSSSk6IEdlbmVy aWMgU3ludGF4LCZyZHF1bzsgSmFudWFyeSZuYnNwOzIwMDUuPC9zcGFuPjxzcGFuPik8L3NwYW4+ PC9hPgogICAgICAgICAgICBzZWN0aW9uIDMuNCksIHdoaWNoIE1VU1QgYmUgcmV0YWluZWQgd2hl biBhZGRpbmcgYWRkaXRpb25hbCBxdWVyeSBwYXJhbWV0ZXJzLiBUaGUKICAgICAgICAgICAgZW5k cG9pbnQgVVJJIE1VU1QgTk9UIGluY2x1ZGUgYSBmcmFnbWVudCBjb21wb25lbnQuCiAgICAgICAg ICAKPC9wPgo8YSBuYW1lPSJhbmNob3IxOSI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFy eT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWci IGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJz cDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLjMu MS4yLjEiPjwvYT48aDM+My4xLjIuMS4mbmJzcDsKRW5kcG9pbnQgUmVxdWVzdCBDb25maWRlbnRp YWxpdHk8L2gzPgoKPHA+CiAgICAgICAgICAgICAgVGhlIHJlZGlyZWN0aW9uIGVuZHBvaW50IFNI T1VMRCByZXF1aXJlIHRoZSB1c2Ugb2YgVExTIGFzIGRlc2NyaWJlZCBpbgogICAgICAgICAgICAg IDxhIGNsYXNzPSdpbmZvJyBocmVmPScjdGxzJz5TZWN0aW9uJm5ic3A7MS42PHNwYW4+ICg8L3Nw YW4+PHNwYW4gY2xhc3M9J2luZm8nPlRMUyBWZXJzaW9uPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9h PiB3aGVuIHRoZSByZXF1ZXN0ZWQgcmVzcG9uc2UgdHlwZSBpcwogICAgICAgICAgICAgIDx0dD5j b2RlPC90dD4gb3IgPHR0PnRva2VuPC90dD4sIG9yCiAgICAgICAgICAgICAgd2hlbiB0aGUgcmVk aXJlY3Rpb24gcmVxdWVzdCB3aWxsIHJlc3VsdCBpbiB0aGUgdHJhbnNtaXNzaW9uIG9mIHNlbnNp dGl2ZSBjcmVkZW50aWFscwogICAgICAgICAgICAgIG92ZXIgYW4gb3BlbiBuZXR3b3JrLiBUaGlz IHNwZWNpZmljYXRpb24gZG9lcyBub3QgbWFuZGF0ZSB0aGUgdXNlIG9mIFRMUyBiZWNhdXNlIGF0 CiAgICAgICAgICAgICAgdGhlIHRpbWUgb2YgdGhpcyB3cml0aW5nLCByZXF1aXJpbmcgY2xpZW50 cyB0byBkZXBsb3kgVExTIGlzIGEgc2lnbmlmaWNhbnQgaHVyZGxlIGZvcgogICAgICAgICAgICAg IG1hbnkgY2xpZW50IGRldmVsb3BlcnMuIElmIFRMUyBpcyBub3QgYXZhaWxhYmxlLCB0aGUgYXV0 aG9yaXphdGlvbiBzZXJ2ZXIgU0hPVUxEIHdhcm4KICAgICAgICAgICAgICB0aGUgcmVzb3VyY2Ug b3duZXIgYWJvdXQgdGhlIGluc2VjdXJlIGVuZHBvaW50IHByaW9yIHRvIHJlZGlyZWN0aW9uIChl LmcuIGRpc3BsYXkgYQogICAgICAgICAgICAgIG1lc3NhZ2UgZHVyaW5nIHRoZSBhdXRob3JpemF0 aW9uIHJlcXVlc3QpLgogICAgICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgICAgICBMYWNrIG9m IHRyYW5zcG9ydC1sYXllciBzZWN1cml0eSBjYW4gaGF2ZSBhIHNldmVyZSBpbXBhY3Qgb24gdGhl IHNlY3VyaXR5IG9mIHRoZQogICAgICAgICAgICAgIGNsaWVudCBhbmQgdGhlIHByb3RlY3RlZCBy ZXNvdXJjZXMgaXQgaXMgYXV0aG9yaXplZCB0byBhY2Nlc3MuIFRoZSB1c2Ugb2YKICAgICAgICAg ICAgICB0cmFuc3BvcnQtbGF5ZXIgc2VjdXJpdHkgaXMgcGFydGljdWxhcmx5IGNyaXRpY2FsIHdo ZW4gdGhlIGF1dGhvcml6YXRpb24gcHJvY2VzcyBpcwogICAgICAgICAgICAgIHVzZWQgYXMgYSBm b3JtIG9mIGRlbGVnYXRlZCBlbmQtdXNlciBhdXRoZW50aWNhdGlvbiBieSB0aGUgY2xpZW50IChl LmcuIHRoaXJkLXBhcnR5CiAgICAgICAgICAgICAgc2lnbi1pbiBzZXJ2aWNlKS4KICAgICAgICAg ICAgCjwvcD4KPGEgbmFtZT0iYW5jaG9yMjAiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1h cnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVn IiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5i c3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi4z LjEuMi4yIj48L2E+PGgzPjMuMS4yLjIuJm5ic3A7ClJlZ2lzdHJhdGlvbiBSZXF1aXJlbWVudHM8 L2gzPgoKPHA+CiAgICAgICAgICAgICAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIE1VU1QgcmVx dWlyZSB0aGUgZm9sbG93aW5nIGNsaWVudHMgdG8gcmVnaXN0ZXIgdGhlaXIKICAgICAgICAgICAg ICByZWRpcmVjdGlvbiBlbmRwb2ludDoKICAgICAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICAg ICAgPC9wPgo8dWwgY2xhc3M9InRleHQiPgo8bGk+CiAgICAgICAgICAgICAgICAgIFB1YmxpYyBj bGllbnRzLgogICAgICAgICAgICAgICAgCjwvbGk+CjxsaT4KICAgICAgICAgICAgICAgICAgQ29u ZmlkZW50aWFsIGNsaWVudHMgdXRpbGl6aW5nIHRoZSBpbXBsaWNpdCBncmFudCB0eXBlLgogICAg ICAgICAgICAgICAgCjwvbGk+CjwvdWw+PHA+CiAgICAgICAgICAgIAo8L3A+CjxwPgogICAgICAg ICAgICAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBTSE9VTEQgcmVxdWlyZSBhbGwgY2xpZW50 cyB0byByZWdpc3RlciB0aGVpciByZWRpcmVjdGlvbgogICAgICAgICAgICAgIGVuZHBvaW50IHBy aW9yIHRvIHV0aWxpemluZyB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludC4KICAgICAgICAgICAg CjwvcD4KPHA+CiAgICAgICAgICAgICAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIFNIT1VMRCBy ZXF1aXJlIHRoZSBjbGllbnQgdG8gcHJvdmlkZSB0aGUgY29tcGxldGUKICAgICAgICAgICAgICBy ZWRpcmVjdGlvbiBVUkkgKHRoZSBjbGllbnQgTUFZIHVzZSB0aGUgPHR0PnN0YXRlPC90dD4gcmVx dWVzdAogICAgICAgICAgICAgIHBhcmFtZXRlciB0byBhY2hpZXZlIHBlci1yZXF1ZXN0IGN1c3Rv bWl6YXRpb24pLiBJZiByZXF1aXJpbmcgdGhlIHJlZ2lzdHJhdGlvbiBvZgogICAgICAgICAgICAg IHRoZSBjb21wbGV0ZSByZWRpcmVjdGlvbiBVUkkgaXMgbm90IHBvc3NpYmxlLCB0aGUgYXV0aG9y aXphdGlvbiBzZXJ2ZXIgU0hPVUxEIHJlcXVpcmUKICAgICAgICAgICAgICB0aGUgcmVnaXN0cmF0 aW9uIG9mIHRoZSBVUkkgc2NoZW1lLCBhdXRob3JpdHksIGFuZCBwYXRoIChhbGxvd2luZyB0aGUg Y2xpZW50IHRvCiAgICAgICAgICAgICAgZHluYW1pY2FsbHkgdmFyeSBvbmx5IHRoZSBxdWVyeSBj b21wb25lbnQgb2YgdGhlIHJlZGlyZWN0aW9uIFVSSSB3aGVuIHJlcXVlc3RpbmcKICAgICAgICAg ICAgICBhdXRob3JpemF0aW9uKS4KICAgICAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICAgICAg VGhlIGF1dGhvcml6YXRpb24gc2VydmVyIE1BWSBhbGxvdyB0aGUgY2xpZW50IHRvIHJlZ2lzdGVy IG11bHRpcGxlIHJlZGlyZWN0aW9uCiAgICAgICAgICAgICAgZW5kcG9pbnRzLgogICAgICAgICAg ICAKPC9wPgo8cD4KICAgICAgICAgICAgICBMYWNrIG9mIGEgcmVkaXJlY3Rpb24gVVJJIHJlZ2lz dHJhdGlvbiByZXF1aXJlbWVudCBjYW4gZW5hYmxlIGFuIGF0dGFja2VyIHRvIHVzZQogICAgICAg ICAgICAgIHRoZSBhdXRob3JpemF0aW9uIGVuZHBvaW50IGFzIG9wZW4gcmVkaXJlY3RvciBhcyBk ZXNjcmliZWQgaW4KICAgICAgICAgICAgICA8YSBjbGFzcz0naW5mbycgaHJlZj0nI29wZW4tcmVk aXJlY3QnPlNlY3Rpb24mbmJzcDsxMC4xNTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZv Jz5PcGVuIFJlZGlyZWN0b3JzPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPi4KICAgICAgICAgICAg CjwvcD4KPGEgbmFtZT0iYW5jaG9yMjEiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9 ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBh bGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7 VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi4zLjEu Mi4zIj48L2E+PGgzPjMuMS4yLjMuJm5ic3A7CkR5bmFtaWMgQ29uZmlndXJhdGlvbjwvaDM+Cgo8 cD4KICAgICAgICAgICAgICBJZiBtdWx0aXBsZSByZWRpcmVjdGlvbiBVUklzIGhhdmUgYmVlbiBy ZWdpc3RlcmVkLCBpZiBvbmx5IHBhcnQgb2YgdGhlIHJlZGlyZWN0aW9uCiAgICAgICAgICAgICAg VVJJIGhhcyBiZWVuIHJlZ2lzdGVyZWQsIG9yIGlmIG5vIHJlZGlyZWN0aW9uIFVSSSBoYXMgYmVl biByZWdpc3RlcmVkLCB0aGUgY2xpZW50CiAgICAgICAgICAgICAgTVVTVCBpbmNsdWRlIGEgcmVk aXJlY3Rpb24gVVJJIHdpdGggdGhlIGF1dGhvcml6YXRpb24gcmVxdWVzdCB1c2luZyB0aGUKICAg ICAgICAgICAgICA8dHQ+cmVkaXJlY3RfdXJpPC90dD4gcmVxdWVzdCBwYXJhbWV0ZXIuCiAgICAg ICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgICAgIFdoZW4gYSByZWRpcmVjdGlvbiBVUkkgaXMg aW5jbHVkZWQgaW4gYW4gYXV0aG9yaXphdGlvbiByZXF1ZXN0LCB0aGUgYXV0aG9yaXphdGlvbgog ICAgICAgICAgICAgIHNlcnZlciBNVVNUIGNvbXBhcmUgYW5kIG1hdGNoIHRoZSB2YWx1ZSByZWNl aXZlZCBhZ2FpbnN0IGF0IGxlYXN0IG9uZSBvZiB0aGUKICAgICAgICAgICAgICByZWdpc3RlcmVk IHJlZGlyZWN0aW9uIFVSSXMgKG9yIFVSSSBjb21wb25lbnRzKSBhcyBkZWZpbmVkIGluCiAgICAg ICAgICAgICAgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNSRkMzOTg2Jz5bUkZDMzk4Nl08c3Bhbj4g KDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+QmVybmVycy1MZWUsIFQuLCBGaWVsZGluZywgUi4s IGFuZCBMLiBNYXNpbnRlciwgJmxkcXVvO1VuaWZvcm0gUmVzb3VyY2UgSWRlbnRpZmllciAoVVJJ KTogR2VuZXJpYyBTeW50YXgsJnJkcXVvOyBKYW51YXJ5Jm5ic3A7MjAwNS48L3NwYW4+PHNwYW4+ KTwvc3Bhbj48L2E+IHNlY3Rpb24gNiwgaWYgYW55IHJlZGlyZWN0aW9uIFVSSXMgd2VyZSByZWdp c3RlcmVkLgogICAgICAgICAgICAgIElmIHRoZSBjbGllbnQgcmVnaXN0cmF0aW9uIGluY2x1ZGVk IHRoZSBmdWxsIHJlZGlyZWN0aW9uIFVSSSwgdGhlIGF1dGhvcml6YXRpb24KICAgICAgICAgICAg ICBzZXJ2ZXIgTVVTVCBjb21wYXJlIHRoZSB0d28gVVJJcyB1c2luZyBzaW1wbGUgc3RyaW5nIGNv bXBhcmlzb24gYXMgZGVmaW5lZAogICAgICAgICAgICAgIGluIDxhIGNsYXNzPSdpbmZvJyBocmVm PScjUkZDMzk4Nic+W1JGQzM5ODZdPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkJl cm5lcnMtTGVlLCBULiwgRmllbGRpbmcsIFIuLCBhbmQgTC4gTWFzaW50ZXIsICZsZHF1bztVbmlm b3JtIFJlc291cmNlIElkZW50aWZpZXIgKFVSSSk6IEdlbmVyaWMgU3ludGF4LCZyZHF1bzsgSmFu dWFyeSZuYnNwOzIwMDUuPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPiBzZWN0aW9uIDYuMi4xLgog ICAgICAgICAgICAKPC9wPgo8YSBuYW1lPSJhbmNob3IyMiI+PC9hPjxiciAvPjxociAvPgo8dGFi bGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNz PSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIj dG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5z ZWN0aW9uLjMuMS4yLjQiPjwvYT48aDM+My4xLjIuNC4mbmJzcDsKSW52YWxpZCBFbmRwb2ludDwv aDM+Cgo8cD4KICAgICAgICAgICAgICBJZiBhbiBhdXRob3JpemF0aW9uIHJlcXVlc3QgZmFpbHMg dmFsaWRhdGlvbiBkdWUgdG8gYSBtaXNzaW5nLCBpbnZhbGlkLCBvcgogICAgICAgICAgICAgIG1p c21hdGNoaW5nIHJlZGlyZWN0aW9uIFVSSSwgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIFNIT1VM RCBpbmZvcm0gdGhlIHJlc291cmNlCiAgICAgICAgICAgICAgb3duZXIgb2YgdGhlIGVycm9yLCBh bmQgTVVTVCBOT1QgYXV0b21hdGljYWxseSByZWRpcmVjdCB0aGUgdXNlci1hZ2VudCB0byB0aGUg aW52YWxpZAogICAgICAgICAgICAgIHJlZGlyZWN0aW9uIFVSSS4KICAgICAgICAgICAgCjwvcD4K PGEgbmFtZT0iYW5jaG9yMjMiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91 dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0i cmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5i c3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi4zLjEuMi41Ij48 L2E+PGgzPjMuMS4yLjUuJm5ic3A7CkVuZHBvaW50IENvbnRlbnQ8L2gzPgoKPHA+CiAgICAgICAg ICAgICAgVGhlIHJlZGlyZWN0aW9uIHJlcXVlc3QgdG8gdGhlIGNsaWVudCdzIGVuZHBvaW50IHR5 cGljYWxseSByZXN1bHRzIGluIGFuIEhUTUwKICAgICAgICAgICAgICBkb2N1bWVudCByZXNwb25z ZSwgcHJvY2Vzc2VkIGJ5IHRoZSB1c2VyLWFnZW50LiBJZiB0aGUgSFRNTCByZXNwb25zZSBpcyBz ZXJ2ZWQKICAgICAgICAgICAgICBkaXJlY3RseSBhcyB0aGUgcmVzdWx0IG9mIHRoZSByZWRpcmVj dGlvbiByZXF1ZXN0LCBhbnkgc2NyaXB0IGluY2x1ZGVkIGluIHRoZSBIVE1MCiAgICAgICAgICAg ICAgZG9jdW1lbnQgd2lsbCBleGVjdXRlIHdpdGggZnVsbCBhY2Nlc3MgdG8gdGhlIHJlZGlyZWN0 aW9uIFVSSSBhbmQgdGhlIGNyZWRlbnRpYWxzIGl0CiAgICAgICAgICAgICAgY29udGFpbnMuCiAg ICAgICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgICAgIFRoZSBjbGllbnQgU0hPVUxEIE5PVCBp bmNsdWRlIGFueSB0aGlyZC1wYXJ0eSBzY3JpcHRzIChlLmcuIHRoaXJkLXBhcnR5IGFuYWx5dGlj cywKICAgICAgICAgICAgICBzb2NpYWwgcGx1Zy1pbnMsIGFkIG5ldHdvcmtzKSBpbiB0aGUgcmVk aXJlY3Rpb24gZW5kcG9pbnQgcmVzcG9uc2UuIEluc3RlYWQsIGl0CiAgICAgICAgICAgICAgU0hP VUxEIGV4dHJhY3QgdGhlIGNyZWRlbnRpYWxzIGZyb20gdGhlIFVSSSBhbmQgcmVkaXJlY3QgdGhl IHVzZXItYWdlbnQgYWdhaW4gdG8KICAgICAgICAgICAgICBhbm90aGVyIGVuZHBvaW50IHdpdGhv dXQgZXhwb3NpbmcgdGhlIGNyZWRlbnRpYWxzIChpbiB0aGUgVVJJIG9yIGVsc2V3aGVyZSkuIElm CiAgICAgICAgICAgICAgdGhpcmQtcGFydHkgc2NyaXB0cyBhcmUgaW5jbHVkZWQsIHRoZSBjbGll bnQgTVVTVCBlbnN1cmUgdGhhdCBpdHMgb3duIHNjcmlwdHMKICAgICAgICAgICAgICAodXNlZCB0 byBleHRyYWN0IGFuZCByZW1vdmUgdGhlIGNyZWRlbnRpYWxzIGZyb20gdGhlIFVSSSkgd2lsbCBl eGVjdXRlIGZpcnN0LgogICAgICAgICAgICAKPC9wPgo8YSBuYW1lPSJhbmNob3IyNCI+PC9hPjxi ciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNw YWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9D YnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+ CjxhIG5hbWU9InJmYy5zZWN0aW9uLjMuMiI+PC9hPjxoMz4zLjIuJm5ic3A7ClRva2VuIEVuZHBv aW50PC9oMz4KCjxwPgogICAgICAgICAgVGhlIHRva2VuIGVuZHBvaW50IGlzIHVzZWQgYnkgdGhl IGNsaWVudCB0byBvYnRhaW4gYW4gYWNjZXNzIHRva2VuIGJ5IHByZXNlbnRpbmcgaXRzCiAgICAg ICAgICBhdXRob3JpemF0aW9uIGdyYW50IG9yIHJlZnJlc2ggdG9rZW4uIFRoZSB0b2tlbiBlbmRw b2ludCBpcyB1c2VkIHdpdGggZXZlcnkgYXV0aG9yaXphdGlvbgogICAgICAgICAgZ3JhbnQgZXhj ZXB0IGZvciB0aGUgaW1wbGljaXQgZ3JhbnQgdHlwZSAoc2luY2UgYW4gYWNjZXNzIHRva2VuIGlz IGlzc3VlZCBkaXJlY3RseSkuCiAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICBUaGUgbWVhbnMg dGhyb3VnaCB3aGljaCB0aGUgY2xpZW50IG9idGFpbnMgdGhlIGxvY2F0aW9uIG9mIHRoZSB0b2tl biBlbmRwb2ludCBhcmUKICAgICAgICAgIGJleW9uZCB0aGUgc2NvcGUgb2YgdGhpcyBzcGVjaWZp Y2F0aW9uIGJ1dCBpcyB0eXBpY2FsbHkgcHJvdmlkZWQgaW4gdGhlIHNlcnZpY2UKICAgICAgICAg IGRvY3VtZW50YXRpb24uCiAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICBUaGUgZW5kcG9pbnQg VVJJIE1BWSBpbmNsdWRlIGFuCiAgICAgICAgICA8dHQ+YXBwbGljYXRpb24veC13d3ctZm9ybS11 cmxlbmNvZGVkPC90dD4gZm9ybWF0dGVkCiAgICAgICAgICAoPGEgY2xhc3M9J2luZm8nIGhyZWY9 JyNXM0MuUkVDLWh0bWw0MDEtMTk5OTEyMjQnPltXM0MuUkVDJiM4MjA5O2h0bWw0MDEmIzgyMDk7 MTk5OTEyMjRdPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkhvcnMsIEEuLCBSYWdn ZXR0LCBELiwgYW5kIEkuIEphY29icywgJmxkcXVvO0hUTUwgNC4wMSBTcGVjaWZpY2F0aW9uLCZy ZHF1bzsgRGVjZW1iZXImbmJzcDsxOTk5Ljwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4pIHF1ZXJ5 IGNvbXBvbmVudCAoPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNSRkMzOTg2Jz5bUkZDMzk4Nl08c3Bh bj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+QmVybmVycy1MZWUsIFQuLCBGaWVsZGluZywg Ui4sIGFuZCBMLiBNYXNpbnRlciwgJmxkcXVvO1VuaWZvcm0gUmVzb3VyY2UgSWRlbnRpZmllciAo VVJJKTogR2VuZXJpYyBTeW50YXgsJnJkcXVvOyBKYW51YXJ5Jm5ic3A7MjAwNS48L3NwYW4+PHNw YW4+KTwvc3Bhbj48L2E+CiAgICAgICAgICBzZWN0aW9uIDMuNCksIHdoaWNoIE1VU1QgYmUgcmV0 YWluZWQgd2hlbiBhZGRpbmcgYWRkaXRpb25hbCBxdWVyeSBwYXJhbWV0ZXJzLiBUaGUKICAgICAg ICAgIGVuZHBvaW50IFVSSSBNVVNUIE5PVCBpbmNsdWRlIGEgZnJhZ21lbnQgY29tcG9uZW50Lgog ICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgU2luY2UgcmVxdWVzdHMgdG8gdGhlIHRva2VuIGVu ZHBvaW50IHJlc3VsdCBpbiB0aGUgdHJhbnNtaXNzaW9uIG9mIGNsZWFyLXRleHQgY3JlZGVudGlh bHMKICAgICAgICAgIChpbiB0aGUgSFRUUCByZXF1ZXN0IGFuZCByZXNwb25zZSksIHRoZSBhdXRo b3JpemF0aW9uIHNlcnZlciBNVVNUIHJlcXVpcmUgdGhlIHVzZSBvZiBUTFMKICAgICAgICAgIGFz IGRlc2NyaWJlZCBpbiA8YSBjbGFzcz0naW5mbycgaHJlZj0nI3Rscyc+U2VjdGlvbiZuYnNwOzEu NjxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5UTFMgVmVyc2lvbjwvc3Bhbj48c3Bh bj4pPC9zcGFuPjwvYT4gd2hlbiBzZW5kaW5nIHJlcXVlc3RzIHRvIHRoZSB0b2tlbiBlbmRwb2lu dC4KICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgIFRoZSBjbGllbnQgTVVTVCB1c2UgdGhlIEhU VFAgPHR0PlBPU1Q8L3R0PiBtZXRob2Qgd2hlbiBtYWtpbmcgYWNjZXNzCiAgICAgICAgICB0b2tl biByZXF1ZXN0cy4KICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgIFBhcmFtZXRlcnMgc2VudCB3 aXRob3V0IGEgdmFsdWUgTVVTVCBiZSB0cmVhdGVkIGFzIGlmIHRoZXkgd2VyZSBvbWl0dGVkIGZy b20gdGhlIHJlcXVlc3QuCiAgICAgICAgICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVTVCBp Z25vcmUgdW5yZWNvZ25pemVkIHJlcXVlc3QgcGFyYW1ldGVycy4gUmVxdWVzdCBhbmQKICAgICAg ICAgIHJlc3BvbnNlIHBhcmFtZXRlcnMgTVVTVCBOT1QgYmUgaW5jbHVkZWQgbW9yZSB0aGFuIG9u Y2UuCiAgICAgICAgCjwvcD4KPGEgbmFtZT0idG9rZW4tZW5kcG9pbnQtYXV0aCI+PC9hPjxiciAv PjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNp bmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVn Ij48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+Cjxh IG5hbWU9InJmYy5zZWN0aW9uLjMuMi4xIj48L2E+PGgzPjMuMi4xLiZuYnNwOwpDbGllbnQgQXV0 aGVudGljYXRpb248L2gzPgoKPHA+CiAgICAgICAgICAgIENvbmZpZGVudGlhbCBjbGllbnRzIG9y IG90aGVyIGNsaWVudHMgaXNzdWVkIGNsaWVudCBjcmVkZW50aWFscyBNVVNUIGF1dGhlbnRpY2F0 ZSB3aXRoCiAgICAgICAgICAgIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBhcyBkZXNjcmliZWQg aW4gPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNjbGllbnQtYXV0aGVudGljYXRpb24nPlNlY3Rpb24m bmJzcDsyLjM8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+Q2xpZW50IEF1dGhlbnRp Y2F0aW9uPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPiB3aGVuCiAgICAgICAgICAgIG1ha2luZyBy ZXF1ZXN0cyB0byB0aGUgdG9rZW4gZW5kcG9pbnQuIENsaWVudCBhdXRoZW50aWNhdGlvbiBpcyB1 c2VkIGZvcjoKICAgICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgICA8L3A+Cjx1bCBjbGFzcz0i dGV4dCI+CjxsaT4KICAgICAgICAgICAgICAgIEVuZm9yY2luZyB0aGUgYmluZGluZyBvZiByZWZy ZXNoIHRva2VucyBhbmQgYXV0aG9yaXphdGlvbiBjb2RlcyB0byB0aGUgY2xpZW50IHRoZXkKICAg ICAgICAgICAgICAgIHdlcmUgaXNzdWVkIHRvLiBDbGllbnQgYXV0aGVudGljYXRpb24gaXMgY3Jp dGljYWwgd2hlbiBhbiBhdXRob3JpemF0aW9uIGNvZGUgaXMKICAgICAgICAgICAgICAgIHRyYW5z bWl0dGVkIHRvIHRoZSByZWRpcmVjdGlvbiBlbmRwb2ludCBvdmVyIGFuIGluc2VjdXJlIGNoYW5u ZWwsIG9yIHdoZW4gdGhlCiAgICAgICAgICAgICAgICByZWRpcmVjdGlvbiBVUkkgaGFzIG5vdCBi ZWVuIHJlZ2lzdGVyZWQgaW4gZnVsbC4KICAgICAgICAgICAgICAKPC9saT4KPGxpPgogICAgICAg ICAgICAgICAgUmVjb3ZlcmluZyBmcm9tIGEgY29tcHJvbWlzZWQgY2xpZW50IGJ5IGRpc2FibGlu ZyB0aGUgY2xpZW50IG9yIGNoYW5naW5nIGl0cwogICAgICAgICAgICAgICAgY3JlZGVudGlhbHMs IHRodXMgcHJldmVudGluZyBhbiBhdHRhY2tlciBmcm9tIGFidXNpbmcgc3RvbGVuIHJlZnJlc2gg dG9rZW5zLiBDaGFuZ2luZwogICAgICAgICAgICAgICAgYSBzaW5nbGUgc2V0IG9mIGNsaWVudCBj cmVkZW50aWFscyBpcyBzaWduaWZpY2FudGx5IGZhc3RlciB0aGFuIHJldm9raW5nIGFuIGVudGly ZQogICAgICAgICAgICAgICAgc2V0IG9mIHJlZnJlc2ggdG9rZW5zLgogICAgICAgICAgICAgIAo8 L2xpPgo8bGk+CiAgICAgICAgICAgICAgICBJbXBsZW1lbnRpbmcgYXV0aGVudGljYXRpb24gbWFu YWdlbWVudCBiZXN0IHByYWN0aWNlcyB3aGljaCByZXF1aXJlIHBlcmlvZGljCiAgICAgICAgICAg ICAgICBjcmVkZW50aWFsIHJvdGF0aW9uLiBSb3RhdGlvbiBvZiBhbiBlbnRpcmUgc2V0IG9mIHJl ZnJlc2ggdG9rZW5zIGNhbiBiZQogICAgICAgICAgICAgICAgY2hhbGxlbmdpbmcsIHdoaWxlIHJv dGF0aW9uIG9mIGEgc2luZ2xlIHNldCBvZiBjbGllbnQgY3JlZGVudGlhbHMgaXMgc2lnbmlmaWNh bnRseQogICAgICAgICAgICAgICAgZWFzaWVyLgogICAgICAgICAgICAgIAo8L2xpPgo8L3VsPjxw PgogICAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICAgIEEgcHVibGljIGNsaWVudCB0aGF0IHdh cyBub3QgaXNzdWVkIGEgY2xpZW50IHBhc3N3b3JkIE1BWSB1c2UgdGhlCiAgICAgICAgICAgIDx0 dD5jbGllbnRfaWQ8L3R0PiByZXF1ZXN0IHBhcmFtZXRlciB0byBpZGVudGlmeSBpdHNlbGYgd2hl biBzZW5kaW5nCiAgICAgICAgICAgIHJlcXVlc3RzIHRvIHRoZSB0b2tlbiBlbmRwb2ludCAoZS5n LiBmb3IgdGhlIHB1cnBvc2Ugb2YgcHJvdmlkaW5nIGVuZC11c2VyIGNvbnRleHQsCiAgICAgICAg ICAgIGNsaWVudCB1c2FnZSBzdGF0aXN0aWNzKS4KICAgICAgICAgIAo8L3A+CjxhIG5hbWU9InNj b3BlIj48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5n PSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRk IGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwv dHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uMy4zIj48L2E+PGgzPjMuMy4mbmJzcDsK QWNjZXNzIFRva2VuIFNjb3BlPC9oMz4KCjxwPgogICAgICAgICAgVGhlIGF1dGhvcml6YXRpb24g YW5kIHRva2VuIGVuZHBvaW50cyBhbGxvdyB0aGUgY2xpZW50IHRvIHNwZWNpZnkgdGhlIHNjb3Bl IG9mIHRoZSBhY2Nlc3MKICAgICAgICAgIHJlcXVlc3QgdXNpbmcgdGhlIDx0dD5zY29wZTwvdHQ+ IHJlcXVlc3QgcGFyYW1ldGVyLiBJbiB0dXJuLCB0aGUKICAgICAgICAgIGF1dGhvcml6YXRpb24g c2VydmVyIHVzZXMgdGhlIDx0dD5zY29wZTwvdHQ+IHJlc3BvbnNlIHBhcmFtZXRlciB0bwogICAg ICAgICAgaW5mb3JtIHRoZSBjbGllbnQgb2YgdGhlIHNjb3BlIG9mIHRoZSBhY2Nlc3MgdG9rZW4g aXNzdWVkLgogICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgVGhlIHZhbHVlIG9mIHRoZSBzY29w ZSBwYXJhbWV0ZXIgaXMgZXhwcmVzc2VkIGFzIGEgbGlzdCBvZiBzcGFjZS1kZWxpbWl0ZWQsIGNh c2UKICAgICAgICAgIHNlbnNpdGl2ZSBzdHJpbmdzLiBUaGUgc3RyaW5ncyBhcmUgZGVmaW5lZCBi eSB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIuIElmIHRoZSB2YWx1ZQogICAgICAgICAgY29udGFp bnMgbXVsdGlwbGUgc3BhY2UtZGVsaW1pdGVkIHN0cmluZ3MsIHRoZWlyIG9yZGVyIGRvZXMgbm90 IG1hdHRlciwgYW5kIGVhY2ggc3RyaW5nCiAgICAgICAgICBhZGRzIGFuIGFkZGl0aW9uYWwgYWNj ZXNzIHJhbmdlIHRvIHRoZSByZXF1ZXN0ZWQgc2NvcGUuCiAgICAgICAgCjwvcD48ZGl2IHN0eWxl PSdkaXNwbGF5OiB0YWJsZTsgd2lkdGg6IDA7IG1hcmdpbi1sZWZ0OiAzZW07IG1hcmdpbi1yaWdo dDogYXV0byc+PHByZT4KCiAgc2NvcGUgICAgICAgPSBzY29wZS10b2tlbiAqKCBTUCBzY29wZS10 b2tlbiApCiAgc2NvcGUtdG9rZW4gPSAxKiggJXgyMSAvICV4MjMtNUIgLyAleDVELTdFICkKCjwv cHJlPjwvZGl2Pgo8cD4KICAgICAgICAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBNQVkgZnVs bHkgb3IgcGFydGlhbGx5IGlnbm9yZSB0aGUgc2NvcGUgcmVxdWVzdGVkIGJ5IHRoZSBjbGllbnQK ICAgICAgICAgIGJhc2VkIG9uIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBwb2xpY3kgb3IgdGhl IHJlc291cmNlIG93bmVyJ3MgaW5zdHJ1Y3Rpb25zLiBJZiB0aGUKICAgICAgICAgIGlzc3VlZCBh Y2Nlc3MgdG9rZW4gc2NvcGUgaXMgZGlmZmVyZW50IGZyb20gdGhlIG9uZSByZXF1ZXN0ZWQgYnkg dGhlIGNsaWVudCwgdGhlCiAgICAgICAgICBhdXRob3JpemF0aW9uIHNlcnZlciBNVVNUIGluY2x1 ZGUgdGhlIDx0dD5zY29wZTwvdHQ+IHJlc3BvbnNlCiAgICAgICAgICBwYXJhbWV0ZXIgdG8gaW5m b3JtIHRoZSBjbGllbnQgb2YgdGhlIGFjdHVhbCBzY29wZSBncmFudGVkLgogICAgICAgIAo8L3A+ CjxwPgogICAgICAgICAgSWYgdGhlIGNsaWVudCBvbWl0cyB0aGUgc2NvcGUgcGFyYW1ldGVyIHdo ZW4gcmVxdWVzdGluZyBhdXRob3JpemF0aW9uLCB0aGUgYXV0aG9yaXphdGlvbgogICAgICAgICAg c2VydmVyIE1VU1QgZWl0aGVyIHByb2Nlc3MgdGhlIHJlcXVlc3QgdXNpbmcgYSBwcmUtZGVmaW5l ZCBkZWZhdWx0IHZhbHVlLCBvciBmYWlsIHRoZQogICAgICAgICAgcmVxdWVzdCBpbmRpY2F0aW5n IGFuIGludmFsaWQgc2NvcGUuIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBTSE9VTEQgZG9jdW1l bnQgaXRzIHNjb3BlCiAgICAgICAgICByZXF1aXJlbWVudHMgYW5kIGRlZmF1bHQgdmFsdWUgKGlm IGRlZmluZWQpLgogICAgICAgIAo8L3A+CjxhIG5hbWU9ImFuY2hvcjI1Ij48L2E+PGJyIC8+PGhy IC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0i MiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxh IGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFt ZT0icmZjLnNlY3Rpb24uNCI+PC9hPjxoMz40LiZuYnNwOwpPYnRhaW5pbmcgQXV0aG9yaXphdGlv bjwvaDM+Cgo8cD4KICAgICAgICBUbyByZXF1ZXN0IGFuIGFjY2VzcyB0b2tlbiwgdGhlIGNsaWVu dCBvYnRhaW5zIGF1dGhvcml6YXRpb24gZnJvbSB0aGUgcmVzb3VyY2Ugb3duZXIuIFRoZQogICAg ICAgIGF1dGhvcml6YXRpb24gaXMgZXhwcmVzc2VkIGluIHRoZSBmb3JtIG9mIGFuIGF1dGhvcml6 YXRpb24gZ3JhbnQgd2hpY2ggdGhlIGNsaWVudCB1c2VzIHRvCiAgICAgICAgcmVxdWVzdCB0aGUg YWNjZXNzIHRva2VuLiBPQXV0aCBkZWZpbmVzIGZvdXIgZ3JhbnQgdHlwZXM6IGF1dGhvcml6YXRp b24gY29kZSwgaW1wbGljaXQsCiAgICAgICAgcmVzb3VyY2Ugb3duZXIgcGFzc3dvcmQgY3JlZGVu dGlhbHMsIGFuZCBjbGllbnQgY3JlZGVudGlhbHMuIEl0IGFsc28gcHJvdmlkZXMgYW4gZXh0ZW5z aW9uCiAgICAgICAgbWVjaGFuaXNtIGZvciBkZWZpbmluZyBhZGRpdGlvbmFsIGdyYW50IHR5cGVz LgogICAgICAKPC9wPgo8YSBuYW1lPSJncmFudC1jb2RlIj48L2E+PGJyIC8+PGhyIC8+Cjx0YWJs ZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9 IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0 b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNl Y3Rpb24uNC4xIj48L2E+PGgzPjQuMS4mbmJzcDsKQXV0aG9yaXphdGlvbiBDb2RlIEdyYW50PC9o Mz4KCjxwPgogICAgICAgICAgVGhlIGF1dGhvcml6YXRpb24gY29kZSBncmFudCB0eXBlIGlzIHVz ZWQgdG8gb2J0YWluIGJvdGggYWNjZXNzIHRva2VucyBhbmQgcmVmcmVzaAogICAgICAgICAgdG9r ZW5zIGFuZCBpcyBvcHRpbWl6ZWQgZm9yIGNvbmZpZGVudGlhbCBjbGllbnRzLiBBcyBhIHJlZGly ZWN0aW9uLWJhc2VkIGZsb3csIHRoZSBjbGllbnQKICAgICAgICAgIG11c3QgYmUgY2FwYWJsZSBv ZiBpbnRlcmFjdGluZyB3aXRoIHRoZSByZXNvdXJjZSBvd25lcidzIHVzZXItYWdlbnQgKHR5cGlj YWxseSBhIHdlYgogICAgICAgICAgYnJvd3NlcikgYW5kIGNhcGFibGUgb2YgcmVjZWl2aW5nIGlu Y29taW5nIHJlcXVlc3RzICh2aWEgcmVkaXJlY3Rpb24pIGZyb20gdGhlCiAgICAgICAgICBhdXRo b3JpemF0aW9uIHNlcnZlci4KICAgICAgICAKPC9wPjxiciAvPjxociBjbGFzcz0iaW5zZXJ0IiAv Pgo8YSBuYW1lPSJGaWd1cmUtMyI+PC9hPgo8ZGl2IHN0eWxlPSdkaXNwbGF5OiB0YWJsZTsgd2lk dGg6IDA7IG1hcmdpbi1sZWZ0OiAzZW07IG1hcmdpbi1yaWdodDogYXV0byc+PHByZT4KCiAgKy0t LS0tLS0tLS0rCiAgfCByZXNvdXJjZSB8CiAgfCAgIG93bmVyICB8CiAgfCAgICAgICAgICB8CiAg Ky0tLS0tLS0tLS0rCiAgICAgICBeCiAgICAgICB8CiAgICAgIChCKQogICstLS0tfC0tLS0tKyAg ICAgICAgICBDbGllbnQgSWRlbnRpZmllciAgICAgICstLS0tLS0tLS0tLS0tLS0rCiAgfCAgICAg ICAgIC0rLS0tLShBKS0tICZhbXA7IFJlZGlyZWN0aW9uIFVSSSAtLS0tJmd0O3wgICAgICAgICAg ICAgICB8CiAgfCAgVXNlci0gICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCBB dXRob3JpemF0aW9uIHwKICB8ICBBZ2VudCAgLSstLS0tKEIpLS0gVXNlciBhdXRoZW50aWNhdGVz IC0tLSZndDt8ICAgICBTZXJ2ZXIgICAgfAogIHwgICAgICAgICAgfCAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICB8CiAgfCAgICAgICAgIC0rLS0tLShDKS0t IEF1dGhvcml6YXRpb24gQ29kZSAtLS0mbHQ7fCAgICAgICAgICAgICAgIHwKICArLXwtLS0tfC0t LSsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tKwogICAg fCAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBeICAgICAgdgog ICAoQSkgIChDKSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAg fAogICAgfCAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAg ICAgfAogICAgXiAgICB2ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8 ICAgICAgfAogICstLS0tLS0tLS0rICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB8ICAgICAgfAogIHwgICAgICAgICB8Jmd0Oy0tLShEKS0tIEF1dGhvcml6YXRpb24gQ29kZSAt LS0tLS0tLS0nICAgICAgfAogIHwgIENsaWVudCB8ICAgICAgICAgICZhbXA7IFJlZGlyZWN0aW9u IFVSSSAgICAgICAgICAgICAgICAgIHwKICB8ICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHwKICB8ICAgICAgICAgfCZsdDstLS0oRSktLS0tLSBB Y2Nlc3MgVG9rZW4gLS0tLS0tLS0tLS0tLS0tLS0tLScKICArLS0tLS0tLS0tKyAgICAgICAody8g T3B0aW9uYWwgUmVmcmVzaCBUb2tlbikKCjwvcHJlPjwvZGl2Pgo8cD4KICAgICAgICAgICAgTm90 ZTogVGhlIGxpbmVzIGlsbHVzdHJhdGluZyBzdGVwcyBBLCBCLCBhbmQgQyBhcmUgYnJva2VuIGlu dG8gdHdvIHBhcnRzIGFzIHRoZXkgcGFzcwogICAgICAgICAgICB0aHJvdWdoIHRoZSB1c2VyLWFn ZW50LgogICAgICAgICAgCjwvcD48dGFibGUgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgY2Vs bHNwYWNpbmc9IjIiIGFsaWduPSJjZW50ZXIiPjx0cj48dGQgYWxpZ249ImNlbnRlciI+PGZvbnQg ZmFjZT0ibW9uYWNvLCBNUyBTYW5zIFNlcmlmIiBzaXplPSIxIj48Yj4mbmJzcDtGaWd1cmUmbmJz cDszOiBBdXRob3JpemF0aW9uIENvZGUgRmxvdyZuYnNwOzwvYj48L2ZvbnQ+PGJyIC8+PC90ZD48 L3RyPjwvdGFibGU+PGhyIGNsYXNzPSJpbnNlcnQiIC8+Cgo8cD4KICAgICAgICAgIFRoZSBmbG93 IGlsbHVzdHJhdGVkIGluIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjRmlndXJlLTMnPkZpZ3VyZSZu YnNwOzM8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+QXV0aG9yaXphdGlvbiBDb2Rl IEZsb3c8L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+IGluY2x1ZGVzIHRoZSBmb2xsb3dpbmcgc3Rl cHM6CiAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICA8L3A+CjxibG9ja3F1b3RlIGNsYXNzPSJ0 ZXh0Ij48ZGw+CjxkdD4oQSk8L2R0Pgo8ZGQ+CiAgICAgICAgICAgICAgVGhlIGNsaWVudCBpbml0 aWF0ZXMgdGhlIGZsb3cgYnkgZGlyZWN0aW5nIHRoZSByZXNvdXJjZSBvd25lcidzIHVzZXItYWdl bnQgdG8gdGhlCiAgICAgICAgICAgICAgYXV0aG9yaXphdGlvbiBlbmRwb2ludC4gVGhlIGNsaWVu dCBpbmNsdWRlcyBpdHMgY2xpZW50IGlkZW50aWZpZXIsIHJlcXVlc3RlZAogICAgICAgICAgICAg IHNjb3BlLCBsb2NhbCBzdGF0ZSwgYW5kIGEgcmVkaXJlY3Rpb24gVVJJIHRvIHdoaWNoIHRoZSBh dXRob3JpemF0aW9uIHNlcnZlciB3aWxsIHNlbmQKICAgICAgICAgICAgICB0aGUgdXNlci1hZ2Vu dCBiYWNrIG9uY2UgYWNjZXNzIGlzIGdyYW50ZWQgKG9yIGRlbmllZCkuCiAgICAgICAgICAgIAo8 L2RkPgo8ZHQ+KEIpPC9kdD4KPGRkPgogICAgICAgICAgICAgIFRoZSBhdXRob3JpemF0aW9uIHNl cnZlciBhdXRoZW50aWNhdGVzIHRoZSByZXNvdXJjZSBvd25lciAodmlhIHRoZSB1c2VyLWFnZW50 KSBhbmQKICAgICAgICAgICAgICBlc3RhYmxpc2hlcyB3aGV0aGVyIHRoZSByZXNvdXJjZSBvd25l ciBncmFudHMgb3IgZGVuaWVzIHRoZSBjbGllbnQncyBhY2Nlc3MgcmVxdWVzdC4KICAgICAgICAg ICAgCjwvZGQ+CjxkdD4oQyk8L2R0Pgo8ZGQ+CiAgICAgICAgICAgICAgQXNzdW1pbmcgdGhlIHJl c291cmNlIG93bmVyIGdyYW50cyBhY2Nlc3MsIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciByZWRp cmVjdHMgdGhlCiAgICAgICAgICAgICAgdXNlci1hZ2VudCBiYWNrIHRvIHRoZSBjbGllbnQgdXNp bmcgdGhlIHJlZGlyZWN0aW9uIFVSSSBwcm92aWRlZCBlYXJsaWVyIChpbiB0aGUKICAgICAgICAg ICAgICByZXF1ZXN0IG9yIGR1cmluZyBjbGllbnQgcmVnaXN0cmF0aW9uKS4gVGhlIHJlZGlyZWN0 aW9uIFVSSSBpbmNsdWRlcyBhbiBhdXRob3JpemF0aW9uCiAgICAgICAgICAgICAgY29kZSBhbmQg YW55IGxvY2FsIHN0YXRlIHByb3ZpZGVkIGJ5IHRoZSBjbGllbnQgZWFybGllci4KICAgICAgICAg ICAgCjwvZGQ+CjxkdD4oRCk8L2R0Pgo8ZGQ+CiAgICAgICAgICAgICAgVGhlIGNsaWVudCByZXF1 ZXN0cyBhbiBhY2Nlc3MgdG9rZW4gZnJvbSB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIncyB0b2tl biBlbmRwb2ludAogICAgICAgICAgICAgIGJ5IGluY2x1ZGluZyB0aGUgYXV0aG9yaXphdGlvbiBj b2RlIHJlY2VpdmVkIGluIHRoZSBwcmV2aW91cyBzdGVwLiBXaGVuIG1ha2luZyB0aGUKICAgICAg ICAgICAgICByZXF1ZXN0LCB0aGUgY2xpZW50IGF1dGhlbnRpY2F0ZXMgd2l0aCB0aGUgYXV0aG9y aXphdGlvbiBzZXJ2ZXIuIFRoZSBjbGllbnQgaW5jbHVkZXMKICAgICAgICAgICAgICB0aGUgcmVk aXJlY3Rpb24gVVJJIHVzZWQgdG8gb2J0YWluIHRoZSBhdXRob3JpemF0aW9uIGNvZGUgZm9yIHZl cmlmaWNhdGlvbi4KICAgICAgICAgICAgCjwvZGQ+CjxkdD4oRSk8L2R0Pgo8ZGQ+CiAgICAgICAg ICAgICAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGF1dGhlbnRpY2F0ZXMgdGhlIGNsaWVudCwg dmFsaWRhdGVzIHRoZSBhdXRob3JpemF0aW9uIGNvZGUsCiAgICAgICAgICAgICAgYW5kIGVuc3Vy ZXMgdGhlIHJlZGlyZWN0aW9uIFVSSSByZWNlaXZlZCBtYXRjaGVzIHRoZSBVUkkgdXNlZCB0byBy ZWRpcmVjdCB0aGUgY2xpZW50CiAgICAgICAgICAgICAgaW4gc3RlcCAoQykuIElmIHZhbGlkLCB0 aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgcmVzcG9uZHMgYmFjayB3aXRoIGFuIGFjY2VzcyB0b2tl bgogICAgICAgICAgICAgIGFuZCBvcHRpb25hbGx5LCBhIHJlZnJlc2ggdG9rZW4uCiAgICAgICAg ICAgIAo8L2RkPgo8L2RsPjwvYmxvY2txdW90ZT48cD4KICAgICAgICAKPC9wPgo8YSBuYW1lPSJj b2RlLWF1dGh6LXJlcSI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBj ZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdo dCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8 L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLjQuMS4xIj48L2E+PGgz PjQuMS4xLiZuYnNwOwpBdXRob3JpemF0aW9uIFJlcXVlc3Q8L2gzPgoKPHA+CiAgICAgICAgICAg IFRoZSBjbGllbnQgY29uc3RydWN0cyB0aGUgcmVxdWVzdCBVUkkgYnkgYWRkaW5nIHRoZSBmb2xs b3dpbmcgcGFyYW1ldGVycyB0byB0aGUKICAgICAgICAgICAgcXVlcnkgY29tcG9uZW50IG9mIHRo ZSBhdXRob3JpemF0aW9uIGVuZHBvaW50IFVSSSB1c2luZyB0aGUKICAgICAgICAgICAgPHR0PmFw cGxpY2F0aW9uL3gtd3d3LWZvcm0tdXJsZW5jb2RlZDwvdHQ+IGZvcm1hdCBhcyBkZWZpbmVkIGJ5 CiAgICAgICAgICAgIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjVzNDLlJFQy1odG1sNDAxLTE5OTkx MjI0Jz5bVzNDLlJFQyYjODIwOTtodG1sNDAxJiM4MjA5OzE5OTkxMjI0XTxzcGFuPiAoPC9zcGFu PjxzcGFuIGNsYXNzPSdpbmZvJz5Ib3JzLCBBLiwgUmFnZ2V0dCwgRC4sIGFuZCBJLiBKYWNvYnMs ICZsZHF1bztIVE1MIDQuMDEgU3BlY2lmaWNhdGlvbiwmcmRxdW87IERlY2VtYmVyJm5ic3A7MTk5 OS48L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+OgogICAgICAgICAgCjwvcD4KPHA+CiAgICAgICAg ICAgIDwvcD4KPGJsb2NrcXVvdGUgY2xhc3M9InRleHQiPjxkbD4KPGR0PnJlc3BvbnNlX3R5cGU8 L2R0Pgo8ZGQ+CiAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgIFJFUVVJUkVELiBWYWx1 ZSBNVVNUIGJlIHNldCB0byA8dHQ+Y29kZTwvdHQ+LgogICAgICAgICAgICAgIAo8L2RkPgo8ZHQ+ Y2xpZW50X2lkPC9kdD4KPGRkPgogICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICBSRVFV SVJFRC4gVGhlIGNsaWVudCBpZGVudGlmaWVyIGFzIGRlc2NyaWJlZCBpbgogICAgICAgICAgICAg ICAgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNjbGllbnQtaWRlbnRpZmllcic+U2VjdGlvbiZuYnNw OzIuMjxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5DbGllbnQgSWRlbnRpZmllcjwv c3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4uCiAgICAgICAgICAgICAgCjwvZGQ+CjxkdD5yZWRpcmVj dF91cmk8L2R0Pgo8ZGQ+CiAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgIE9QVElPTkFM LiBBcyBkZXNjcmliZWQgaW4gPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNyZWRpcmVjdC11cmknPlNl Y3Rpb24mbmJzcDszLjEuMjxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5SZWRpcmVj dGlvbiBFbmRwb2ludDwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4uCiAgICAgICAgICAgICAgCjwv ZGQ+CjxkdD5zY29wZTwvZHQ+CjxkZD4KICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAg T1BUSU9OQUwuIFRoZSBzY29wZSBvZiB0aGUgYWNjZXNzIHJlcXVlc3QgYXMgZGVzY3JpYmVkIGJ5 IDxhIGNsYXNzPSdpbmZvJyBocmVmPScjc2NvcGUnPlNlY3Rpb24mbmJzcDszLjM8c3Bhbj4gKDwv c3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+QWNjZXNzIFRva2VuIFNjb3BlPC9zcGFuPjxzcGFuPik8 L3NwYW4+PC9hPi4KICAgICAgICAgICAgICAKPC9kZD4KPGR0PnN0YXRlPC9kdD4KPGRkPgogICAg ICAgICAgICAgICAgCiAgICAgICAgICAgICAgICBSRUNPTU1FTkRFRC4gQW4gb3BhcXVlIHZhbHVl IHVzZWQgYnkgdGhlIGNsaWVudCB0byBtYWludGFpbiBzdGF0ZSBiZXR3ZWVuIHRoZSByZXF1ZXN0 CiAgICAgICAgICAgICAgICBhbmQgY2FsbGJhY2suIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBp bmNsdWRlcyB0aGlzIHZhbHVlIHdoZW4gcmVkaXJlY3RpbmcgdGhlCiAgICAgICAgICAgICAgICB1 c2VyLWFnZW50IGJhY2sgdG8gdGhlIGNsaWVudC4gVGhlIHBhcmFtZXRlciBTSE9VTEQgYmUgdXNl ZCBmb3IgcHJldmVudGluZwogICAgICAgICAgICAgICAgY3Jvc3Mtc2l0ZSByZXF1ZXN0IGZvcmdl cnkgYXMgZGVzY3JpYmVkIGluIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjQ1NSRic+U2VjdGlvbiZu YnNwOzEwLjEyPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkNyb3NzLVNpdGUgUmVx dWVzdCBGb3JnZXJ5PC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPi4KICAgICAgICAgICAgICAKPC9k ZD4KPC9kbD48L2Jsb2NrcXVvdGU+PHA+CiAgICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgICAg VGhlIGNsaWVudCBkaXJlY3RzIHRoZSByZXNvdXJjZSBvd25lciB0byB0aGUgY29uc3RydWN0ZWQg VVJJIHVzaW5nIGFuIEhUVFAgcmVkaXJlY3Rpb24KICAgICAgICAgICAgcmVzcG9uc2UsIG9yIGJ5 IG90aGVyIG1lYW5zIGF2YWlsYWJsZSB0byBpdCB2aWEgdGhlIHVzZXItYWdlbnQuCiAgICAgICAg ICAKPC9wPgo8cD4KICAgICAgICAgICAgICBGb3IgZXhhbXBsZSwgdGhlIGNsaWVudCBkaXJlY3Rz IHRoZSB1c2VyLWFnZW50IHRvIG1ha2UgdGhlIGZvbGxvd2luZyBIVFRQIHJlcXVlc3QKICAgICAg ICAgICAgICB1c2luZyBUTFMgKGV4dHJhIGxpbmUgYnJlYWtzIGFyZSBmb3IgZGlzcGxheSBwdXJw b3NlcyBvbmx5KToKICAgICAgICAgICAgCjwvcD48ZGl2IHN0eWxlPSdkaXNwbGF5OiB0YWJsZTsg d2lkdGg6IDA7IG1hcmdpbi1sZWZ0OiAzZW07IG1hcmdpbi1yaWdodDogYXV0byc+PHByZT4KCiAg R0VUIC9hdXRob3JpemU/cmVzcG9uc2VfdHlwZT1jb2RlJmFtcDtjbGllbnRfaWQ9czZCaGRSa3F0 MyZhbXA7c3RhdGU9eHl6CiAgICAgICZhbXA7cmVkaXJlY3RfdXJpPWh0dHBzJTNBJTJGJTJGY2xp ZW50JTJFZXhhbXBsZSUyRWNvbSUyRmNiIEhUVFAvMS4xCiAgSG9zdDogc2VydmVyLmV4YW1wbGUu Y29tCgo8L3ByZT48L2Rpdj4KPHA+CiAgICAgICAgICAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZl ciB2YWxpZGF0ZXMgdGhlIHJlcXVlc3QgdG8gZW5zdXJlIGFsbCByZXF1aXJlZCBwYXJhbWV0ZXJz IGFyZQogICAgICAgICAgICBwcmVzZW50IGFuZCB2YWxpZC4gSWYgdGhlIHJlcXVlc3QgaXMgdmFs aWQsIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBhdXRoZW50aWNhdGVzIHRoZQogICAgICAgICAg ICByZXNvdXJjZSBvd25lciBhbmQgb2J0YWlucyBhbiBhdXRob3JpemF0aW9uIGRlY2lzaW9uIChi eSBhc2tpbmcgdGhlIHJlc291cmNlIG93bmVyIG9yCiAgICAgICAgICAgIGJ5IGVzdGFibGlzaGlu ZyBhcHByb3ZhbCB2aWEgb3RoZXIgbWVhbnMpLgogICAgICAgICAgCjwvcD4KPHA+CiAgICAgICAg ICAgIFdoZW4gYSBkZWNpc2lvbiBpcyBlc3RhYmxpc2hlZCwgdGhlIGF1dGhvcml6YXRpb24gc2Vy dmVyIGRpcmVjdHMgdGhlIHVzZXItYWdlbnQgdG8gdGhlCiAgICAgICAgICAgIHByb3ZpZGVkIGNs aWVudCByZWRpcmVjdGlvbiBVUkkgdXNpbmcgYW4gSFRUUCByZWRpcmVjdGlvbiByZXNwb25zZSwg b3IgYnkgb3RoZXIgbWVhbnMKICAgICAgICAgICAgYXZhaWxhYmxlIHRvIGl0IHZpYSB0aGUgdXNl ci1hZ2VudC4KICAgICAgICAgIAo8L3A+CjxhIG5hbWU9ImNvZGUtYXV0aHotcmVzcCI+PC9hPjxi ciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNw YWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9D YnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+ CjxhIG5hbWU9InJmYy5zZWN0aW9uLjQuMS4yIj48L2E+PGgzPjQuMS4yLiZuYnNwOwpBdXRob3Jp emF0aW9uIFJlc3BvbnNlPC9oMz4KCjxwPgogICAgICAgICAgICBJZiB0aGUgcmVzb3VyY2Ugb3du ZXIgZ3JhbnRzIHRoZSBhY2Nlc3MgcmVxdWVzdCwgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGlz c3VlcyBhbgogICAgICAgICAgICBhdXRob3JpemF0aW9uIGNvZGUgYW5kIGRlbGl2ZXJzIGl0IHRv IHRoZSBjbGllbnQgYnkgYWRkaW5nIHRoZSBmb2xsb3dpbmcgcGFyYW1ldGVycyB0bwogICAgICAg ICAgICB0aGUgcXVlcnkgY29tcG9uZW50IG9mIHRoZSByZWRpcmVjdGlvbiBVUkkgdXNpbmcgdGhl CiAgICAgICAgICAgIDx0dD5hcHBsaWNhdGlvbi94LXd3dy1mb3JtLXVybGVuY29kZWQ8L3R0PiBm b3JtYXQ6CiAgICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgICAgPC9wPgo8YmxvY2txdW90ZSBj bGFzcz0idGV4dCI+PGRsPgo8ZHQ+Y29kZTwvZHQ+CjxkZD4KICAgICAgICAgICAgICAgIAogICAg ICAgICAgICAgICAgUkVRVUlSRUQuIFRoZSBhdXRob3JpemF0aW9uIGNvZGUgZ2VuZXJhdGVkIGJ5 IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlci4gVGhlCiAgICAgICAgICAgICAgICBhdXRob3JpemF0 aW9uIGNvZGUgTVVTVCBleHBpcmUgc2hvcnRseSBhZnRlciBpdCBpcyBpc3N1ZWQgdG8gbWl0aWdh dGUgdGhlIHJpc2sgb2YKICAgICAgICAgICAgICAgIGxlYWtzLiBBIG1heGltdW0gYXV0aG9yaXph dGlvbiBjb2RlIGxpZmV0aW1lIG9mIDEwIG1pbnV0ZXMgaXMgUkVDT01NRU5ERUQuIFRoZQogICAg ICAgICAgICAgICAgY2xpZW50IE1VU1QgTk9UIHVzZSB0aGUgYXV0aG9yaXphdGlvbiBjb2RlIG1v cmUgdGhhbiBvbmNlLiBJZiBhbiBhdXRob3JpemF0aW9uIGNvZGUKICAgICAgICAgICAgICAgIGlz IHVzZWQgbW9yZSB0aGFuIG9uY2UsIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBNVVNUIGRlbnkg dGhlIHJlcXVlc3QgYW5kIFNIT1VMRAogICAgICAgICAgICAgICAgcmV2b2tlICh3aGVuIHBvc3Np YmxlKSBhbGwgdG9rZW5zIHByZXZpb3VzbHkgaXNzdWVkIGJhc2VkIG9uIHRoYXQgYXV0aG9yaXph dGlvbgogICAgICAgICAgICAgICAgY29kZS4gVGhlIGF1dGhvcml6YXRpb24gY29kZSBpcyBib3Vu ZCB0byB0aGUgY2xpZW50IGlkZW50aWZpZXIgYW5kIHJlZGlyZWN0aW9uIFVSSS4KICAgICAgICAg ICAgICAKPC9kZD4KPGR0PnN0YXRlPC9kdD4KPGRkPgogICAgICAgICAgICAgICAgCiAgICAgICAg ICAgICAgICBSRVFVSVJFRCBpZiB0aGUgPHR0PnN0YXRlPC90dD4gcGFyYW1ldGVyIHdhcyBwcmVz ZW50IGluIHRoZQogICAgICAgICAgICAgICAgY2xpZW50IGF1dGhvcml6YXRpb24gcmVxdWVzdC4g VGhlIGV4YWN0IHZhbHVlIHJlY2VpdmVkIGZyb20gdGhlIGNsaWVudC4KICAgICAgICAgICAgICAK PC9kZD4KPC9kbD48L2Jsb2NrcXVvdGU+PHA+CiAgICAgICAgICAKPC9wPgo8cD4KICAgICAgICAg ICAgICBGb3IgZXhhbXBsZSwgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHJlZGlyZWN0cyB0aGUg dXNlci1hZ2VudCBieSBzZW5kaW5nIHRoZQogICAgICAgICAgICAgIGZvbGxvd2luZyBIVFRQIHJl c3BvbnNlOgogICAgICAgICAgICAKPC9wPjxkaXYgc3R5bGU9J2Rpc3BsYXk6IHRhYmxlOyB3aWR0 aDogMDsgbWFyZ2luLWxlZnQ6IDNlbTsgbWFyZ2luLXJpZ2h0OiBhdXRvJz48cHJlPgoKICBIVFRQ LzEuMSAzMDIgRm91bmQKICBMb2NhdGlvbjogaHR0cHM6Ly9jbGllbnQuZXhhbXBsZS5jb20vY2I/ Y29kZT1TcGx4bE9CZVpRUVliWVM2V3hTYklBCiAgICAgICAgICAgICZhbXA7c3RhdGU9eHl6Cgo8 L3ByZT48L2Rpdj4KPHA+CiAgICAgICAgICAgIFRoZSBjbGllbnQgTVVTVCBpZ25vcmUgdW5yZWNv Z25pemVkIHJlc3BvbnNlIHBhcmFtZXRlcnMuIFRoZSBhdXRob3JpemF0aW9uIGNvZGUKICAgICAg ICAgICAgc3RyaW5nIHNpemUgaXMgbGVmdCB1bmRlZmluZWQgYnkgdGhpcyBzcGVjaWZpY2F0aW9u LiBUaGUgY2xpZW50IHNob3VsZCBhdm9pZCBtYWtpbmcKICAgICAgICAgICAgYXNzdW1wdGlvbnMg YWJvdXQgY29kZSB2YWx1ZSBzaXplcy4gVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIFNIT1VMRCBk b2N1bWVudCB0aGUgc2l6ZQogICAgICAgICAgICBvZiBhbnkgdmFsdWUgaXQgaXNzdWVzLgogICAg ICAgICAgCjwvcD4KPGEgbmFtZT0iY29kZS1hdXRoei1lcnJvciI+PC9hPjxiciAvPjxociAvPgo8 dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNs YXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVm PSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJm Yy5zZWN0aW9uLjQuMS4yLjEiPjwvYT48aDM+NC4xLjIuMS4mbmJzcDsKRXJyb3IgUmVzcG9uc2U8 L2gzPgoKPHA+CiAgICAgICAgICAgICAgSWYgdGhlIHJlcXVlc3QgZmFpbHMgZHVlIHRvIGEgbWlz c2luZywgaW52YWxpZCwgb3IgbWlzbWF0Y2hpbmcgcmVkaXJlY3Rpb24gVVJJLCBvciBpZgogICAg ICAgICAgICAgIHRoZSBjbGllbnQgaWRlbnRpZmllciBpcyBtaXNzaW5nIG9yIGludmFsaWQsIHRo ZSBhdXRob3JpemF0aW9uIHNlcnZlciBTSE9VTEQgaW5mb3JtCiAgICAgICAgICAgICAgdGhlIHJl c291cmNlIG93bmVyIG9mIHRoZSBlcnJvciwgYW5kIE1VU1QgTk9UIGF1dG9tYXRpY2FsbHkgcmVk aXJlY3QgdGhlIHVzZXItYWdlbnQKICAgICAgICAgICAgICB0byB0aGUgaW52YWxpZCByZWRpcmVj dGlvbiBVUkkuCiAgICAgICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgICAgIElmIHRoZSByZXNv dXJjZSBvd25lciBkZW5pZXMgdGhlIGFjY2VzcyByZXF1ZXN0IG9yIGlmIHRoZSByZXF1ZXN0IGZh aWxzIGZvciByZWFzb25zCiAgICAgICAgICAgICAgb3RoZXIgdGhhbiBhIG1pc3Npbmcgb3IgaW52 YWxpZCByZWRpcmVjdGlvbiBVUkksIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBpbmZvcm1zIHRo ZQogICAgICAgICAgICAgIGNsaWVudCBieSBhZGRpbmcgdGhlIGZvbGxvd2luZyBwYXJhbWV0ZXJz IHRvIHRoZSBxdWVyeSBjb21wb25lbnQgb2YgdGhlIHJlZGlyZWN0aW9uCiAgICAgICAgICAgICAg VVJJIHVzaW5nIHRoZSA8dHQ+YXBwbGljYXRpb24veC13d3ctZm9ybS11cmxlbmNvZGVkPC90dD4g Zm9ybWF0OgogICAgICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgICAgICA8L3A+CjxibG9ja3F1 b3RlIGNsYXNzPSJ0ZXh0Ij48ZGw+CjxkdD5lcnJvcjwvZHQ+CjxkZD4KICAgICAgICAgICAgICAg ICAgCiAgICAgICAgICAgICAgICAgIFJFUVVJUkVELiBBIHNpbmdsZSBBU0NJSSA8YSBjbGFzcz0n aW5mbycgaHJlZj0nI1VTQVNDSUknPltVU0FTQ0lJXTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNz PSdpbmZvJz5BbWVyaWNhbiBOYXRpb25hbCBTdGFuZGFyZHMgSW5zdGl0dXRlLCAmbGRxdW87Q29k ZWQgQ2hhcmFjdGVyIFNldCAtLSA3LWJpdCBBbWVyaWNhbiBTdGFuZGFyZCBDb2RlIGZvciBJbmZv cm1hdGlvbiBJbnRlcmNoYW5nZSwmcmRxdW87IDE5ODYuPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9h PiBlcnJvciBjb2RlIGZyb20gdGhlIGZvbGxvd2luZzoKCiAgICAgICAgICAgICAgICAgIAo8Ymxv Y2txdW90ZSBjbGFzcz0idGV4dCI+PGRsPgo8ZHQ+aW52YWxpZF9yZXF1ZXN0PC9kdD4KPGRkPgog ICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICBUaGUgcmVxdWVzdCBp cyBtaXNzaW5nIGEgcmVxdWlyZWQgcGFyYW1ldGVyLCBpbmNsdWRlcyBhbiBpbnZhbGlkCiAgICAg ICAgICAgICAgICAgICAgICBwYXJhbWV0ZXIgdmFsdWUsIGluY2x1ZGVzIGEgcGFyYW1ldGVyIG1v cmUgdGhhbiBvbmNlLCBvciBpcyBvdGhlcndpc2UKICAgICAgICAgICAgICAgICAgICAgIG1hbGZv cm1lZC4KICAgICAgICAgICAgICAgICAgICAKPC9kZD4KPGR0PnVuYXV0aG9yaXplZF9jbGllbnQ8 L2R0Pgo8ZGQ+CiAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgIFRo ZSBjbGllbnQgaXMgbm90IGF1dGhvcml6ZWQgdG8gcmVxdWVzdCBhbiBhdXRob3JpemF0aW9uIGNv ZGUgdXNpbmcgdGhpcwogICAgICAgICAgICAgICAgICAgICAgbWV0aG9kLgogICAgICAgICAgICAg ICAgICAgIAo8L2RkPgo8ZHQ+YWNjZXNzX2RlbmllZDwvZHQ+CjxkZD4KICAgICAgICAgICAgICAg ICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgVGhlIHJlc291cmNlIG93bmVyIG9yIGF1dGhv cml6YXRpb24gc2VydmVyIGRlbmllZCB0aGUgcmVxdWVzdC4KICAgICAgICAgICAgICAgICAgICAK PC9kZD4KPGR0PnVuc3VwcG9ydGVkX3Jlc3BvbnNlX3R5cGU8L2R0Pgo8ZGQ+CiAgICAgICAgICAg ICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZl ciBkb2VzIG5vdCBzdXBwb3J0IG9idGFpbmluZyBhbiBhdXRob3JpemF0aW9uIGNvZGUKICAgICAg ICAgICAgICAgICAgICAgIHVzaW5nIHRoaXMgbWV0aG9kLgogICAgICAgICAgICAgICAgICAgIAo8 L2RkPgo8ZHQ+aW52YWxpZF9zY29wZTwvZHQ+CjxkZD4KICAgICAgICAgICAgICAgICAgICAgIAog ICAgICAgICAgICAgICAgICAgICAgVGhlIHJlcXVlc3RlZCBzY29wZSBpcyBpbnZhbGlkLCB1bmtu b3duLCBvciBtYWxmb3JtZWQuCiAgICAgICAgICAgICAgICAgICAgCjwvZGQ+CjxkdD5zZXJ2ZXJf ZXJyb3I8L2R0Pgo8ZGQ+CiAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAg ICAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBlbmNvdW50ZXJlZCBhbiB1bmV4cGVjdGVkIGNv bmRpdGlvbiB3aGljaCBwcmV2ZW50ZWQKICAgICAgICAgICAgICAgICAgICAgIGl0IGZyb20gZnVs ZmlsbGluZyB0aGUgcmVxdWVzdC4KICAgICAgICAgICAgICAgICAgICAKPC9kZD4KPGR0PnRlbXBv cmFyaWx5X3VuYXZhaWxhYmxlPC9kdD4KPGRkPgogICAgICAgICAgICAgICAgICAgICAgCiAgICAg ICAgICAgICAgICAgICAgICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgaXMgY3VycmVudGx5IHVu YWJsZSB0byBoYW5kbGUgdGhlIHJlcXVlc3QgZHVlIHRvIGEKICAgICAgICAgICAgICAgICAgICAg IHRlbXBvcmFyeSBvdmVybG9hZGluZyBvciBtYWludGVuYW5jZSBvZiB0aGUgc2VydmVyLgogICAg ICAgICAgICAgICAgICAgIAo8L2RkPgo8L2RsPjwvYmxvY2txdW90ZT4KCgkJICBWYWx1ZXMgZm9y IHRoZSA8dHQ+ZXJyb3I8L3R0PiBwYXJhbWV0ZXIgTVVTVCBOT1QgaW5jbHVkZQoJCSAgY2hhcmFj dGVycyBvdXRzaWRlIHRoZSBzZXQgJXgyMC0yMSAvICV4MjMtNUIgLyAleDVELTdFLgogICAgICAg ICAgICAgICAgCjwvZGQ+CjxkdD5lcnJvcl9kZXNjcmlwdGlvbjwvZHQ+CjxkZD4KICAgICAgICAg ICAgICAgICAgCiAgICAgICAgICAgICAgICAgIE9QVElPTkFMLiBBIGh1bWFuLXJlYWRhYmxlIEFT Q0lJIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjVVNBU0NJSSc+W1VTQVNDSUldPHNwYW4+ICg8L3Nw YW4+PHNwYW4gY2xhc3M9J2luZm8nPkFtZXJpY2FuIE5hdGlvbmFsIFN0YW5kYXJkcyBJbnN0aXR1 dGUsICZsZHF1bztDb2RlZCBDaGFyYWN0ZXIgU2V0IC0tIDctYml0IEFtZXJpY2FuIFN0YW5kYXJk IENvZGUgZm9yIEluZm9ybWF0aW9uIEludGVyY2hhbmdlLCZyZHF1bzsgMTk4Ni48L3NwYW4+PHNw YW4+KTwvc3Bhbj48L2E+IHRleHQgcHJvdmlkaW5nIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24sCiAg ICAgICAgICAgICAgICAgIHVzZWQgdG8gYXNzaXN0IHRoZSBjbGllbnQgZGV2ZWxvcGVyIGluIHVu ZGVyc3RhbmRpbmcgdGhlIGVycm9yIHRoYXQgb2NjdXJyZWQuCgkJICA8YnIgLz4KCgkJICBWYWx1 ZXMgZm9yIHRoZSA8dHQ+ZXJyb3JfZGVzY3JpcHRpb248L3R0PiBwYXJhbWV0ZXIgTVVTVCBOT1Qg aW5jbHVkZQoJCSAgY2hhcmFjdGVycyBvdXRzaWRlIHRoZSBzZXQgJXgyMC0yMSAvICV4MjMtNUIg LyAleDVELTdFLgogICAgICAgICAgICAgICAgCjwvZGQ+CjxkdD5lcnJvcl91cmk8L2R0Pgo8ZGQ+ CiAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICBPUFRJT05BTC4gQSBVUkkgaWRl bnRpZnlpbmcgYSBodW1hbi1yZWFkYWJsZSB3ZWIgcGFnZSB3aXRoIGluZm9ybWF0aW9uIGFib3V0 IHRoZQogICAgICAgICAgICAgICAgICBlcnJvciwgdXNlZCB0byBwcm92aWRlIHRoZSBjbGllbnQg ZGV2ZWxvcGVyIHdpdGggYWRkaXRpb25hbCBpbmZvcm1hdGlvbiBhYm91dCB0aGUKICAgICAgICAg ICAgICAgICAgZXJyb3IuCgkJICA8YnIgLz4KCgkJICBWYWx1ZXMgZm9yIHRoZSA8dHQ+ZXJyb3Jf dXJpPC90dD4gcGFyYW1ldGVyCgkJICBNVVNUIGNvbmZvcm0gdG8gdGhlIFVSSS1SZWZlcmVuY2Ug c3ludGF4LCBhbmQgdGh1cyBNVVNUIE5PVCBpbmNsdWRlCgkJICBjaGFyYWN0ZXJzIG91dHNpZGUg dGhlIHNldCAleDIxIC8gJXgyMy01QiAvICV4NUQtN0UuCiAgICAgICAgICAgICAgICAKPC9kZD4K PGR0PnN0YXRlPC9kdD4KPGRkPgogICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAg UkVRVUlSRUQgaWYgYSA8dHQ+c3RhdGU8L3R0PiBwYXJhbWV0ZXIgd2FzIHByZXNlbnQgaW4gdGhl CiAgICAgICAgICAgICAgICAgIGNsaWVudCBhdXRob3JpemF0aW9uIHJlcXVlc3QuIFRoZSBleGFj dCB2YWx1ZSByZWNlaXZlZCBmcm9tIHRoZSBjbGllbnQuCiAgICAgICAgICAgICAgICAKPC9kZD4K PC9kbD48L2Jsb2NrcXVvdGU+PHA+CiAgICAgICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgICAg ICAgRm9yIGV4YW1wbGUsIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciByZWRpcmVjdHMgdGhlIHVz ZXItYWdlbnQgYnkgc2VuZGluZyB0aGUKICAgICAgICAgICAgICAgIGZvbGxvd2luZyBIVFRQIHJl c3BvbnNlOgogICAgICAgICAgICAgIAo8L3A+PGRpdiBzdHlsZT0nZGlzcGxheTogdGFibGU7IHdp ZHRoOiAwOyBtYXJnaW4tbGVmdDogM2VtOyBtYXJnaW4tcmlnaHQ6IGF1dG8nPjxwcmU+CgogIEhU VFAvMS4xIDMwMiBGb3VuZAogIExvY2F0aW9uOiBodHRwczovL2NsaWVudC5leGFtcGxlLmNvbS9j Yj9lcnJvcj1hY2Nlc3NfZGVuaWVkJmFtcDtzdGF0ZT14eXoKCjwvcHJlPjwvZGl2Pgo8YSBuYW1l PSJ0b2tlbi1yZXEiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2Vs bHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQi Pjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9h PjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi40LjEuMyI+PC9hPjxoMz40 LjEuMy4mbmJzcDsKQWNjZXNzIFRva2VuIFJlcXVlc3Q8L2gzPgoKPHA+CiAgICAgICAgICAgIFRo ZSBjbGllbnQgbWFrZXMgYSByZXF1ZXN0IHRvIHRoZSB0b2tlbiBlbmRwb2ludCBieSBhZGRpbmcg dGhlIGZvbGxvd2luZyBwYXJhbWV0ZXJzCiAgICAgICAgICAgIHVzaW5nIHRoZSA8dHQ+YXBwbGlj YXRpb24veC13d3ctZm9ybS11cmxlbmNvZGVkPC90dD4gZm9ybWF0IGluIHRoZQogICAgICAgICAg ICBIVFRQIHJlcXVlc3QgZW50aXR5LWJvZHk6CiAgICAgICAgICAKPC9wPgo8cD4KICAgICAgICAg ICAgPC9wPgo8YmxvY2txdW90ZSBjbGFzcz0idGV4dCI+PGRsPgo8ZHQ+Z3JhbnRfdHlwZTwvZHQ+ CjxkZD4KICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgUkVRVUlSRUQuIFZhbHVlIE1V U1QgYmUgc2V0IHRvIDx0dD5hdXRob3JpemF0aW9uX2NvZGU8L3R0Pi4KICAgICAgICAgICAgICAK PC9kZD4KPGR0PmNvZGU8L2R0Pgo8ZGQ+CiAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAg IFJFUVVJUkVELiBUaGUgYXV0aG9yaXphdGlvbiBjb2RlIHJlY2VpdmVkIGZyb20gdGhlIGF1dGhv cml6YXRpb24gc2VydmVyLgogICAgICAgICAgICAgIAo8L2RkPgo8ZHQ+cmVkaXJlY3RfdXJpPC9k dD4KPGRkPgogICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICBSRVFVSVJFRCwgaWYgdGhl IDx0dD5yZWRpcmVjdF91cmk8L3R0PiBwYXJhbWV0ZXIgd2FzIGluY2x1ZGVkIGluCiAgICAgICAg ICAgICAgICB0aGUgYXV0aG9yaXphdGlvbiByZXF1ZXN0IGFzIGRlc2NyaWJlZCBpbiA8YSBjbGFz cz0naW5mbycgaHJlZj0nI2NvZGUtYXV0aHotcmVxJz5TZWN0aW9uJm5ic3A7NC4xLjE8c3Bhbj4g KDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+QXV0aG9yaXphdGlvbiBSZXF1ZXN0PC9zcGFuPjxz cGFuPik8L3NwYW4+PC9hPiwgYW5kCiAgICAgICAgICAgICAgICB0aGVpciB2YWx1ZXMgTVVTVCBi ZSBpZGVudGljYWwuCiAgICAgICAgICAgICAgCjwvZGQ+CjwvZGw+PC9ibG9ja3F1b3RlPjxwPgog ICAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICAgIElmIHRoZSBjbGllbnQgdHlwZSBpcyBjb25m aWRlbnRpYWwgb3IgdGhlIGNsaWVudCB3YXMgaXNzdWVkIGNsaWVudCBjcmVkZW50aWFscyAob3IK ICAgICAgICAgICAgYXNzaWduZWQgb3RoZXIgYXV0aGVudGljYXRpb24gcmVxdWlyZW1lbnRzKSwg dGhlIGNsaWVudCBNVVNUIGF1dGhlbnRpY2F0ZSB3aXRoIHRoZQogICAgICAgICAgICBhdXRob3Jp emF0aW9uIHNlcnZlciBhcyBkZXNjcmliZWQgaW4gPGEgY2xhc3M9J2luZm8nIGhyZWY9JyN0b2tl bi1lbmRwb2ludC1hdXRoJz5TZWN0aW9uJm5ic3A7My4yLjE8c3Bhbj4gKDwvc3Bhbj48c3BhbiBj bGFzcz0naW5mbyc+Q2xpZW50IEF1dGhlbnRpY2F0aW9uPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9h Pi4KICAgICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgICAgIEZvciBleGFtcGxlLCB0aGUgY2xp ZW50IG1ha2VzIHRoZSBmb2xsb3dpbmcgSFRUUCByZXF1ZXN0IHVzaW5nIFRMUyAoZXh0cmEgbGlu ZSBicmVha3MKICAgICAgICAgICAgICBhcmUgZm9yIGRpc3BsYXkgcHVycG9zZXMgb25seSk6CiAg ICAgICAgICAgIAo8L3A+PGRpdiBzdHlsZT0nZGlzcGxheTogdGFibGU7IHdpZHRoOiAwOyBtYXJn aW4tbGVmdDogM2VtOyBtYXJnaW4tcmlnaHQ6IGF1dG8nPjxwcmU+CgogIFBPU1QgL3Rva2VuIEhU VFAvMS4xCiAgSG9zdDogc2VydmVyLmV4YW1wbGUuY29tCiAgQXV0aG9yaXphdGlvbjogQmFzaWMg Y3paQ2FHUlNhM0YwTXpwbldERm1RbUYwTTJKVwogIENvbnRlbnQtVHlwZTogYXBwbGljYXRpb24v eC13d3ctZm9ybS11cmxlbmNvZGVkO2NoYXJzZXQ9VVRGLTgKCiAgZ3JhbnRfdHlwZT1hdXRob3Jp emF0aW9uX2NvZGUmYW1wO2NvZGU9U3BseGxPQmVaUVFZYllTNld4U2JJQQogICZhbXA7cmVkaXJl Y3RfdXJpPWh0dHBzJTNBJTJGJTJGY2xpZW50JTJFZXhhbXBsZSUyRWNvbSUyRmNiCgo8L3ByZT48 L2Rpdj4KPHA+CiAgICAgICAgICAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBNVVNUOgogICAg ICAgICAgCjwvcD4KPHA+CiAgICAgICAgICAgIDwvcD4KPHVsIGNsYXNzPSJ0ZXh0Ij4KPGxpPgog ICAgICAgICAgICAgICAgcmVxdWlyZSBjbGllbnQgYXV0aGVudGljYXRpb24gZm9yIGNvbmZpZGVu dGlhbCBjbGllbnRzIG9yIGZvciBhbnkgY2xpZW50IHRoYXQgd2FzCiAgICAgICAgICAgICAgICBp c3N1ZWQgY2xpZW50IGNyZWRlbnRpYWxzIChvciB3aXRoIG90aGVyIGF1dGhlbnRpY2F0aW9uIHJl cXVpcmVtZW50cyksCiAgICAgICAgICAgICAgCjwvbGk+CjxsaT4KICAgICAgICAgICAgICAgIGF1 dGhlbnRpY2F0ZSB0aGUgY2xpZW50IGlmIGNsaWVudCBhdXRoZW50aWNhdGlvbiBpcyBpbmNsdWRl ZCBhbmQgZW5zdXJlIHRoZQogICAgICAgICAgICAgICAgYXV0aG9yaXphdGlvbiBjb2RlIHdhcyBp c3N1ZWQgdG8gdGhlIGF1dGhlbnRpY2F0ZWQgY2xpZW50LAogICAgICAgICAgICAgIAo8L2xpPgo8 bGk+CiAgICAgICAgICAgICAgICB2ZXJpZnkgdGhhdCB0aGUgYXV0aG9yaXphdGlvbiBjb2RlIGlz IHZhbGlkLCBhbmQKICAgICAgICAgICAgICAKPC9saT4KPGxpPgogICAgICAgICAgICAgICAgZW5z dXJlIHRoYXQgdGhlIDx0dD5yZWRpcmVjdF91cmk8L3R0PiBwYXJhbWV0ZXIgaXMgcHJlc2VudCBp ZgogICAgICAgICAgICAgICAgdGhlIDx0dD5yZWRpcmVjdF91cmk8L3R0PiBwYXJhbWV0ZXIgd2Fz IGluY2x1ZGVkIGluIHRoZSBpbml0aWFsCiAgICAgICAgICAgICAgICBhdXRob3JpemF0aW9uIHJl cXVlc3QgYXMgZGVzY3JpYmVkIGluIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjY29kZS1hdXRoei1y ZXEnPlNlY3Rpb24mbmJzcDs0LjEuMTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5B dXRob3JpemF0aW9uIFJlcXVlc3Q8L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+LCBhbmQgaWYKICAg ICAgICAgICAgICAgIGluY2x1ZGVkIGVuc3VyZSB0aGVpciB2YWx1ZXMgYXJlIGlkZW50aWNhbC4K ICAgICAgICAgICAgICAKPC9saT4KPC91bD48cD4KICAgICAgICAgIAo8L3A+CjxhIG5hbWU9ImFu Y2hvcjI2Ij48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRk aW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+ PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3Rk PjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uNC4xLjQiPjwvYT48aDM+NC4xLjQu Jm5ic3A7CkFjY2VzcyBUb2tlbiBSZXNwb25zZTwvaDM+Cgo8cD4KICAgICAgICAgICAgSWYgdGhl IGFjY2VzcyB0b2tlbiByZXF1ZXN0IGlzIHZhbGlkIGFuZCBhdXRob3JpemVkLCB0aGUgYXV0aG9y aXphdGlvbiBzZXJ2ZXIgaXNzdWVzIGFuCiAgICAgICAgICAgIGFjY2VzcyB0b2tlbiBhbmQgb3B0 aW9uYWwgcmVmcmVzaCB0b2tlbiBhcyBkZXNjcmliZWQgaW4gPGEgY2xhc3M9J2luZm8nIGhyZWY9 JyN0b2tlbi1yZXNwb25zZSc+U2VjdGlvbiZuYnNwOzUuMTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNs YXNzPSdpbmZvJz5TdWNjZXNzZnVsIFJlc3BvbnNlPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPi4K ICAgICAgICAgICAgSWYgdGhlIHJlcXVlc3QgY2xpZW50IGF1dGhlbnRpY2F0aW9uIGZhaWxlZCBv ciBpcyBpbnZhbGlkLCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgcmV0dXJucwogICAgICAgICAg ICBhbiBlcnJvciByZXNwb25zZSBhcyBkZXNjcmliZWQgaW4gPGEgY2xhc3M9J2luZm8nIGhyZWY9 JyN0b2tlbi1lcnJvcnMnPlNlY3Rpb24mbmJzcDs1LjI8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFz cz0naW5mbyc+RXJyb3IgUmVzcG9uc2U8L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+LgogICAgICAg ICAgCjwvcD4KPHA+CiAgICAgICAgICAgICAgQW4gZXhhbXBsZSBzdWNjZXNzZnVsIHJlc3BvbnNl OgogICAgICAgICAgICAKPC9wPjxkaXYgc3R5bGU9J2Rpc3BsYXk6IHRhYmxlOyB3aWR0aDogMDsg bWFyZ2luLWxlZnQ6IDNlbTsgbWFyZ2luLXJpZ2h0OiBhdXRvJz48cHJlPgoKICBIVFRQLzEuMSAy MDAgT0sKICBDb250ZW50LVR5cGU6IGFwcGxpY2F0aW9uL2pzb247Y2hhcnNldD1VVEYtOAogIENh Y2hlLUNvbnRyb2w6IG5vLXN0b3JlCiAgUHJhZ21hOiBuby1jYWNoZQoKICB7CiAgICAiYWNjZXNz X3Rva2VuIjoiMllvdG5GWkZFanIxekNzaWNNV3BBQSIsCiAgICAidG9rZW5fdHlwZSI6ImV4YW1w bGUiLAogICAgImV4cGlyZXNfaW4iOjM2MDAsCiAgICAicmVmcmVzaF90b2tlbiI6InRHenYzSk9r RjBYRzVReDJUbEtXSUEiLAogICAgImV4YW1wbGVfcGFyYW1ldGVyIjoiZXhhbXBsZV92YWx1ZSIK ICB9Cgo8L3ByZT48L2Rpdj4KPGEgbmFtZT0iZ3JhbnQtaW1wbGljaXQiPjwvYT48YnIgLz48aHIg Lz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIy IiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEg aHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1l PSJyZmMuc2VjdGlvbi40LjIiPjwvYT48aDM+NC4yLiZuYnNwOwpJbXBsaWNpdCBHcmFudDwvaDM+ Cgo8cD4KICAgICAgICAgIFRoZSBpbXBsaWNpdCBncmFudCB0eXBlIGlzIHVzZWQgdG8gb2J0YWlu IGFjY2VzcyB0b2tlbnMgKGl0IGRvZXMgbm90IHN1cHBvcnQgdGhlIGlzc3VhbmNlCiAgICAgICAg ICBvZiByZWZyZXNoIHRva2VucykgYW5kIGlzIG9wdGltaXplZCBmb3IgcHVibGljIGNsaWVudHMg a25vd24gdG8gb3BlcmF0ZSBhIHBhcnRpY3VsYXIKICAgICAgICAgIHJlZGlyZWN0aW9uIFVSSS4g VGhlc2UgY2xpZW50cyBhcmUgdHlwaWNhbGx5IGltcGxlbWVudGVkIGluIGEgYnJvd3NlciB1c2lu ZyBhIHNjcmlwdGluZwogICAgICAgICAgbGFuZ3VhZ2Ugc3VjaCBhcyBKYXZhU2NyaXB0LgogICAg ICAgIAo8L3A+CjxwPgogICAgICAgICAgQXMgYSByZWRpcmVjdGlvbi1iYXNlZCBmbG93LCB0aGUg Y2xpZW50IG11c3QgYmUgY2FwYWJsZSBvZiBpbnRlcmFjdGluZyB3aXRoIHRoZQogICAgICAgICAg cmVzb3VyY2Ugb3duZXIncyB1c2VyLWFnZW50ICh0eXBpY2FsbHkgYSB3ZWIgYnJvd3NlcikgYW5k IGNhcGFibGUgb2YgcmVjZWl2aW5nIGluY29taW5nCiAgICAgICAgICByZXF1ZXN0cyAodmlhIHJl ZGlyZWN0aW9uKSBmcm9tIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlci4KICAgICAgICAKPC9wPgo8 cD4KICAgICAgICAgIFVubGlrZSB0aGUgYXV0aG9yaXphdGlvbiBjb2RlIGdyYW50IHR5cGUgaW4g d2hpY2ggdGhlIGNsaWVudCBtYWtlcyBzZXBhcmF0ZSByZXF1ZXN0cyBmb3IKICAgICAgICAgIGF1 dGhvcml6YXRpb24gYW5kIGFjY2VzcyB0b2tlbiwgdGhlIGNsaWVudCByZWNlaXZlcyB0aGUgYWNj ZXNzIHRva2VuIGFzIHRoZSByZXN1bHQgb2YgdGhlCiAgICAgICAgICBhdXRob3JpemF0aW9uIHJl cXVlc3QuCiAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICBUaGUgaW1wbGljaXQgZ3JhbnQgdHlw ZSBkb2VzIG5vdCBpbmNsdWRlIGNsaWVudCBhdXRoZW50aWNhdGlvbiwgYW5kIHJlbGllcyBvbiB0 aGUKICAgICAgICAgIHByZXNlbmNlIG9mIHRoZSByZXNvdXJjZSBvd25lciBhbmQgdGhlIHJlZ2lz dHJhdGlvbiBvZiB0aGUgcmVkaXJlY3Rpb24gVVJJLiBCZWNhdXNlIHRoZQogICAgICAgICAgYWNj ZXNzIHRva2VuIGlzIGVuY29kZWQgaW50byB0aGUgcmVkaXJlY3Rpb24gVVJJLCBpdCBtYXkgYmUg ZXhwb3NlZCB0byB0aGUgcmVzb3VyY2Ugb3duZXIKICAgICAgICAgIGFuZCBvdGhlciBhcHBsaWNh dGlvbnMgcmVzaWRpbmcgb24gdGhlIHNhbWUgZGV2aWNlLgogICAgICAgIAo8L3A+PGJyIC8+PGhy IGNsYXNzPSJpbnNlcnQiIC8+CjxhIG5hbWU9IkZpZ3VyZS00Ij48L2E+CjxkaXYgc3R5bGU9J2Rp c3BsYXk6IHRhYmxlOyB3aWR0aDogMDsgbWFyZ2luLWxlZnQ6IDNlbTsgbWFyZ2luLXJpZ2h0OiBh dXRvJz48cHJlPgoKICArLS0tLS0tLS0tLSsKICB8IFJlc291cmNlIHwKICB8ICBPd25lciAgIHwK ICB8ICAgICAgICAgIHwKICArLS0tLS0tLS0tLSsKICAgICAgIF4KICAgICAgIHwKICAgICAgKEIp CiAgKy0tLS18LS0tLS0rICAgICAgICAgIENsaWVudCBJZGVudGlmaWVyICAgICArLS0tLS0tLS0t LS0tLS0tKwogIHwgICAgICAgICAtKy0tLS0oQSktLSAmYW1wOyBSZWRpcmVjdGlvbiBVUkkgLS0t Jmd0O3wgICAgICAgICAgICAgICB8CiAgfCAgVXNlci0gICB8ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB8IEF1dGhvcml6YXRpb24gfAogIHwgIEFnZW50ICAtfC0tLS0oQiktLSBVc2Vy IGF1dGhlbnRpY2F0ZXMgLS0mZ3Q7fCAgICAgU2VydmVyICAgIHwKICB8ICAgICAgICAgIHwgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICB8CiAgfCAgICAgICAg ICB8Jmx0Oy0tLShDKS0tLSBSZWRpcmVjdGlvbiBVUkkgLS0tLSZsdDt8ICAgICAgICAgICAgICAg fAogIHwgICAgICAgICAgfCAgICAgICAgICB3aXRoIEFjY2VzcyBUb2tlbiAgICAgKy0tLS0tLS0t LS0tLS0tLSsKICB8ICAgICAgICAgIHwgICAgICAgICAgICBpbiBGcmFnbWVudAogIHwgICAgICAg ICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLSsKICB8 ICAgICAgICAgIHwtLS0tKEQpLS0tIFJlZGlyZWN0aW9uIFVSSSAtLS0tJmd0O3wgICBXZWItSG9z dGVkICB8CiAgfCAgICAgICAgICB8ICAgICAgICAgIHdpdGhvdXQgRnJhZ21lbnQgICAgICB8ICAg ICBDbGllbnQgICAgfAogIHwgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgfCAgICBSZXNvdXJjZSAgIHwKICB8ICAgICAoRikgIHwmbHQ7LS0tKEUpLS0tLS0tLSBTY3Jp cHQgLS0tLS0tLS0tJmx0O3wgICAgICAgICAgICAgICB8CiAgfCAgICAgICAgICB8ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tKwogICstfC0tLS0tLS0tKwog ICAgfCAgICB8CiAgIChBKSAgKEcpIEFjY2VzcyBUb2tlbgogICAgfCAgICB8CiAgICBeICAgIHYK ICArLS0tLS0tLS0tKwogIHwgICAgICAgICB8CiAgfCAgQ2xpZW50IHwKICB8ICAgICAgICAgfAog ICstLS0tLS0tLS0rCgo8L3ByZT48L2Rpdj4KPHA+CiAgICAgICAgICAgIE5vdGU6IFRoZSBsaW5l cyBpbGx1c3RyYXRpbmcgc3RlcHMgQSBhbmQgQiBhcmUgYnJva2VuIGludG8gdHdvIHBhcnRzIGFz IHRoZXkgcGFzcwogICAgICAgICAgICB0aHJvdWdoIHRoZSB1c2VyLWFnZW50LgogICAgICAgICAg CjwvcD48dGFibGUgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGFs aWduPSJjZW50ZXIiPjx0cj48dGQgYWxpZ249ImNlbnRlciI+PGZvbnQgZmFjZT0ibW9uYWNvLCBN UyBTYW5zIFNlcmlmIiBzaXplPSIxIj48Yj4mbmJzcDtGaWd1cmUmbmJzcDs0OiBJbXBsaWNpdCBH cmFudCBGbG93Jm5ic3A7PC9iPjwvZm9udD48YnIgLz48L3RkPjwvdHI+PC90YWJsZT48aHIgY2xh c3M9Imluc2VydCIgLz4KCjxwPgogICAgICAgICAgVGhlIGZsb3cgaWxsdXN0cmF0ZWQgaW4gPGEg Y2xhc3M9J2luZm8nIGhyZWY9JyNGaWd1cmUtNCc+RmlndXJlJm5ic3A7NDxzcGFuPiAoPC9zcGFu PjxzcGFuIGNsYXNzPSdpbmZvJz5JbXBsaWNpdCBHcmFudCBGbG93PC9zcGFuPjxzcGFuPik8L3Nw YW4+PC9hPiBpbmNsdWRlcyB0aGUgZm9sbG93aW5nIHN0ZXBzOgogICAgICAgIAo8L3A+CjxwPgog ICAgICAgICAgPC9wPgo8YmxvY2txdW90ZSBjbGFzcz0idGV4dCI+PGRsPgo8ZHQ+KEEpPC9kdD4K PGRkPgogICAgICAgICAgICAgIFRoZSBjbGllbnQgaW5pdGlhdGVzIHRoZSBmbG93IGJ5IGRpcmVj dGluZyB0aGUgcmVzb3VyY2Ugb3duZXIncyB1c2VyLWFnZW50IHRvIHRoZQogICAgICAgICAgICAg IGF1dGhvcml6YXRpb24gZW5kcG9pbnQuIFRoZSBjbGllbnQgaW5jbHVkZXMgaXRzIGNsaWVudCBp ZGVudGlmaWVyLCByZXF1ZXN0ZWQKICAgICAgICAgICAgICBzY29wZSwgbG9jYWwgc3RhdGUsIGFu ZCBhIHJlZGlyZWN0aW9uIFVSSSB0byB3aGljaCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgd2ls bCBzZW5kCiAgICAgICAgICAgICAgdGhlIHVzZXItYWdlbnQgYmFjayBvbmNlIGFjY2VzcyBpcyBn cmFudGVkIChvciBkZW5pZWQpLgogICAgICAgICAgICAKPC9kZD4KPGR0PihCKTwvZHQ+CjxkZD4K ICAgICAgICAgICAgICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYXV0aGVudGljYXRlcyB0aGUg cmVzb3VyY2Ugb3duZXIgKHZpYSB0aGUgdXNlci1hZ2VudCkgYW5kCiAgICAgICAgICAgICAgZXN0 YWJsaXNoZXMgd2hldGhlciB0aGUgcmVzb3VyY2Ugb3duZXIgZ3JhbnRzIG9yIGRlbmllcyB0aGUg Y2xpZW50J3MgYWNjZXNzIHJlcXVlc3QuCiAgICAgICAgICAgIAo8L2RkPgo8ZHQ+KEMpPC9kdD4K PGRkPgogICAgICAgICAgICAgIEFzc3VtaW5nIHRoZSByZXNvdXJjZSBvd25lciBncmFudHMgYWNj ZXNzLCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgcmVkaXJlY3RzIHRoZQogICAgICAgICAgICAg IHVzZXItYWdlbnQgYmFjayB0byB0aGUgY2xpZW50IHVzaW5nIHRoZSByZWRpcmVjdGlvbiBVUkkg cHJvdmlkZWQgZWFybGllci4gVGhlCiAgICAgICAgICAgICAgcmVkaXJlY3Rpb24gVVJJIGluY2x1 ZGVzIHRoZSBhY2Nlc3MgdG9rZW4gaW4gdGhlIFVSSSBmcmFnbWVudC4KICAgICAgICAgICAgCjwv ZGQ+CjxkdD4oRCk8L2R0Pgo8ZGQ+CiAgICAgICAgICAgICAgVGhlIHVzZXItYWdlbnQgZm9sbG93 cyB0aGUgcmVkaXJlY3Rpb24gaW5zdHJ1Y3Rpb25zIGJ5IG1ha2luZyBhIHJlcXVlc3QgdG8gdGhl CiAgICAgICAgICAgICAgd2ViLWhvc3RlZCBjbGllbnQgcmVzb3VyY2UgKHdoaWNoIGRvZXMgbm90 IGluY2x1ZGUgdGhlIGZyYWdtZW50IHBlcgogICAgICAgICAgICAgIDxhIGNsYXNzPSdpbmZvJyBo cmVmPScjUkZDMjYxNic+W1JGQzI2MTZdPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8n PkZpZWxkaW5nLCBSLiwgR2V0dHlzLCBKLiwgTW9ndWwsIEouLCBGcnlzdHlrLCBILiwgTWFzaW50 ZXIsIEwuLCBMZWFjaCwgUC4sIGFuZCBULiBCZXJuZXJzLUxlZSwgJmxkcXVvO0h5cGVydGV4dCBU cmFuc2ZlciBQcm90b2NvbCAtLSBIVFRQLzEuMSwmcmRxdW87IEp1bmUmbmJzcDsxOTk5Ljwvc3Bh bj48c3Bhbj4pPC9zcGFuPjwvYT4pLiBUaGUgdXNlci1hZ2VudCByZXRhaW5zIHRoZSBmcmFnbWVu dCBpbmZvcm1hdGlvbiBsb2NhbGx5LgogICAgICAgICAgICAKPC9kZD4KPGR0PihFKTwvZHQ+Cjxk ZD4KICAgICAgICAgICAgICBUaGUgd2ViLWhvc3RlZCBjbGllbnQgcmVzb3VyY2UgcmV0dXJucyBh IHdlYiBwYWdlICh0eXBpY2FsbHkgYW4gSFRNTCBkb2N1bWVudCB3aXRoIGFuCiAgICAgICAgICAg ICAgZW1iZWRkZWQgc2NyaXB0KSBjYXBhYmxlIG9mIGFjY2Vzc2luZyB0aGUgZnVsbCByZWRpcmVj dGlvbiBVUkkgaW5jbHVkaW5nIHRoZSBmcmFnbWVudAogICAgICAgICAgICAgIHJldGFpbmVkIGJ5 IHRoZSB1c2VyLWFnZW50LCBhbmQgZXh0cmFjdGluZyB0aGUgYWNjZXNzIHRva2VuIChhbmQgb3Ro ZXIgcGFyYW1ldGVycykKICAgICAgICAgICAgICBjb250YWluZWQgaW4gdGhlIGZyYWdtZW50Lgog ICAgICAgICAgICAKPC9kZD4KPGR0PihGKTwvZHQ+CjxkZD4KICAgICAgICAgICAgICBUaGUgdXNl ci1hZ2VudCBleGVjdXRlcyB0aGUgc2NyaXB0IHByb3ZpZGVkIGJ5IHRoZSB3ZWItaG9zdGVkIGNs aWVudCByZXNvdXJjZQogICAgICAgICAgICAgIGxvY2FsbHksIHdoaWNoIGV4dHJhY3RzIHRoZSBh Y2Nlc3MgdG9rZW4gYW5kIHBhc3NlcyBpdCB0byB0aGUgY2xpZW50LgogICAgICAgICAgICAKPC9k ZD4KPC9kbD48L2Jsb2NrcXVvdGU+PHA+CiAgICAgICAgCjwvcD4KPGEgbmFtZT0iaW1wbGljaXQt YXV0aHotcmVxIj48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxw YWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48 dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48 L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uNC4yLjEiPjwvYT48aDM+NC4y LjEuJm5ic3A7CkF1dGhvcml6YXRpb24gUmVxdWVzdDwvaDM+Cgo8cD4KICAgICAgICAgICAgVGhl IGNsaWVudCBjb25zdHJ1Y3RzIHRoZSByZXF1ZXN0IFVSSSBieSBhZGRpbmcgdGhlIGZvbGxvd2lu ZyBwYXJhbWV0ZXJzIHRvIHRoZQogICAgICAgICAgICBxdWVyeSBjb21wb25lbnQgb2YgdGhlIGF1 dGhvcml6YXRpb24gZW5kcG9pbnQgVVJJIHVzaW5nIHRoZQogICAgICAgICAgICA8dHQ+YXBwbGlj YXRpb24veC13d3ctZm9ybS11cmxlbmNvZGVkPC90dD4gZm9ybWF0OgogICAgICAgICAgCjwvcD4K PHA+CiAgICAgICAgICAgIDwvcD4KPGJsb2NrcXVvdGUgY2xhc3M9InRleHQiPjxkbD4KPGR0PnJl c3BvbnNlX3R5cGU8L2R0Pgo8ZGQ+CiAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgIFJF UVVJUkVELiBWYWx1ZSBNVVNUIGJlIHNldCB0byA8dHQ+dG9rZW48L3R0Pi4KICAgICAgICAgICAg ICAKPC9kZD4KPGR0PmNsaWVudF9pZDwvZHQ+CjxkZD4KICAgICAgICAgICAgICAgIAogICAgICAg ICAgICAgICAgUkVRVUlSRUQuIFRoZSBjbGllbnQgaWRlbnRpZmllciBhcyBkZXNjcmliZWQgaW4K ICAgICAgICAgICAgICAgIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjY2xpZW50LWlkZW50aWZpZXIn PlNlY3Rpb24mbmJzcDsyLjI8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+Q2xpZW50 IElkZW50aWZpZXI8L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+LgogICAgICAgICAgICAgIAo8L2Rk Pgo8ZHQ+cmVkaXJlY3RfdXJpPC9kdD4KPGRkPgogICAgICAgICAgICAgICAgCiAgICAgICAgICAg ICAgICBPUFRJT05BTC4gQXMgZGVzY3JpYmVkIGluIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjcmVk aXJlY3QtdXJpJz5TZWN0aW9uJm5ic3A7My4xLjI8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0n aW5mbyc+UmVkaXJlY3Rpb24gRW5kcG9pbnQ8L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+LgogICAg ICAgICAgICAgIAo8L2RkPgo8ZHQ+c2NvcGU8L2R0Pgo8ZGQ+CiAgICAgICAgICAgICAgICAKICAg ICAgICAgICAgICAgIE9QVElPTkFMLiBUaGUgc2NvcGUgb2YgdGhlIGFjY2VzcyByZXF1ZXN0IGFz IGRlc2NyaWJlZCBieSA8YSBjbGFzcz0naW5mbycgaHJlZj0nI3Njb3BlJz5TZWN0aW9uJm5ic3A7 My4zPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkFjY2VzcyBUb2tlbiBTY29wZTwv c3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4uCiAgICAgICAgICAgICAgCjwvZGQ+CjxkdD5zdGF0ZTwv ZHQ+CjxkZD4KICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgUkVDT01NRU5ERUQuIEFu IG9wYXF1ZSB2YWx1ZSB1c2VkIGJ5IHRoZSBjbGllbnQgdG8gbWFpbnRhaW4gc3RhdGUgYmV0d2Vl biB0aGUgcmVxdWVzdAogICAgICAgICAgICAgICAgYW5kIGNhbGxiYWNrLiBUaGUgYXV0aG9yaXph dGlvbiBzZXJ2ZXIgaW5jbHVkZXMgdGhpcyB2YWx1ZSB3aGVuIHJlZGlyZWN0aW5nIHRoZQogICAg ICAgICAgICAgICAgdXNlci1hZ2VudCBiYWNrIHRvIHRoZSBjbGllbnQuIFRoZSBwYXJhbWV0ZXIg U0hPVUxEIGJlIHVzZWQgZm9yIHByZXZlbnRpbmcKICAgICAgICAgICAgICAgIGNyb3NzLXNpdGUg cmVxdWVzdCBmb3JnZXJ5IGFzIGRlc2NyaWJlZCBpbiA8YSBjbGFzcz0naW5mbycgaHJlZj0nI0NT UkYnPlNlY3Rpb24mbmJzcDsxMC4xMjxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5D cm9zcy1TaXRlIFJlcXVlc3QgRm9yZ2VyeTwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4uCiAgICAg ICAgICAgICAgCjwvZGQ+CjwvZGw+PC9ibG9ja3F1b3RlPjxwPgogICAgICAgICAgCjwvcD4KPHA+ CiAgICAgICAgICAgIFRoZSBjbGllbnQgZGlyZWN0cyB0aGUgcmVzb3VyY2Ugb3duZXIgdG8gdGhl IGNvbnN0cnVjdGVkIFVSSSB1c2luZyBhbiBIVFRQIHJlZGlyZWN0aW9uCiAgICAgICAgICAgIHJl c3BvbnNlLCBvciBieSBvdGhlciBtZWFucyBhdmFpbGFibGUgdG8gaXQgdmlhIHRoZSB1c2VyLWFn ZW50LgogICAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICAgICAgRm9yIGV4YW1wbGUsIHRoZSBj bGllbnQgZGlyZWN0cyB0aGUgdXNlci1hZ2VudCB0byBtYWtlIHRoZSBmb2xsb3dpbmcgSFRUUCBy ZXF1ZXN0CiAgICAgICAgICAgICAgdXNpbmcgVExTIChleHRyYSBsaW5lIGJyZWFrcyBhcmUgZm9y IGRpc3BsYXkgcHVycG9zZXMgb25seSk6CiAgICAgICAgICAgIAo8L3A+PGRpdiBzdHlsZT0nZGlz cGxheTogdGFibGU7IHdpZHRoOiAwOyBtYXJnaW4tbGVmdDogM2VtOyBtYXJnaW4tcmlnaHQ6IGF1 dG8nPjxwcmU+CgogIEdFVCAvYXV0aG9yaXplP3Jlc3BvbnNlX3R5cGU9dG9rZW4mYW1wO2NsaWVu dF9pZD1zNkJoZFJrcXQzJmFtcDtzdGF0ZT14eXoKICAgICAgJmFtcDtyZWRpcmVjdF91cmk9aHR0 cHMlM0ElMkYlMkZjbGllbnQlMkVleGFtcGxlJTJFY29tJTJGY2IgSFRUUC8xLjEKICBIb3N0OiBz ZXJ2ZXIuZXhhbXBsZS5jb20KCjwvcHJlPjwvZGl2Pgo8cD4KICAgICAgICAgICAgVGhlIGF1dGhv cml6YXRpb24gc2VydmVyIHZhbGlkYXRlcyB0aGUgcmVxdWVzdCB0byBlbnN1cmUgYWxsIHJlcXVp cmVkIHBhcmFtZXRlcnMgYXJlCiAgICAgICAgICAgIHByZXNlbnQgYW5kIHZhbGlkLiBUaGUgYXV0 aG9yaXphdGlvbiBzZXJ2ZXIgTVVTVCB2ZXJpZnkgdGhhdCB0aGUgcmVkaXJlY3Rpb24gVVJJIHRv IHdoaWNoCiAgICAgICAgICAgIGl0IHdpbGwgcmVkaXJlY3QgdGhlIGFjY2VzcyB0b2tlbiBtYXRj aGVzIGEgcmVkaXJlY3Rpb24gVVJJIHJlZ2lzdGVyZWQgYnkgdGhlIGNsaWVudCBhcwogICAgICAg ICAgICBkZXNjcmliZWQgaW4gPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNyZWRpcmVjdC11cmknPlNl Y3Rpb24mbmJzcDszLjEuMjxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5SZWRpcmVj dGlvbiBFbmRwb2ludDwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4uCiAgICAgICAgICAKPC9wPgo8 cD4KICAgICAgICAgICAgSWYgdGhlIHJlcXVlc3QgaXMgdmFsaWQsIHRoZSBhdXRob3JpemF0aW9u IHNlcnZlciBhdXRoZW50aWNhdGVzIHRoZSByZXNvdXJjZSBvd25lciBhbmQKICAgICAgICAgICAg b2J0YWlucyBhbiBhdXRob3JpemF0aW9uIGRlY2lzaW9uIChieSBhc2tpbmcgdGhlIHJlc291cmNl IG93bmVyIG9yIGJ5IGVzdGFibGlzaGluZwogICAgICAgICAgICBhcHByb3ZhbCB2aWEgb3RoZXIg bWVhbnMpLgogICAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICAgIFdoZW4gYSBkZWNpc2lvbiBp cyBlc3RhYmxpc2hlZCwgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGRpcmVjdHMgdGhlIHVzZXIt YWdlbnQgdG8gdGhlCiAgICAgICAgICAgIHByb3ZpZGVkIGNsaWVudCByZWRpcmVjdGlvbiBVUkkg dXNpbmcgYW4gSFRUUCByZWRpcmVjdGlvbiByZXNwb25zZSwgb3IgYnkgb3RoZXIgbWVhbnMKICAg ICAgICAgICAgYXZhaWxhYmxlIHRvIGl0IHZpYSB0aGUgdXNlci1hZ2VudC4KICAgICAgICAgIAo8 L3A+CjxhIG5hbWU9ImltcGxpY2l0LWF1dGh6LXJlc3AiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxl IHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0i VE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3Rv YyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2Vj dGlvbi40LjIuMiI+PC9hPjxoMz40LjIuMi4mbmJzcDsKQWNjZXNzIFRva2VuIFJlc3BvbnNlPC9o Mz4KCjxwPgogICAgICAgICAgICBJZiB0aGUgcmVzb3VyY2Ugb3duZXIgZ3JhbnRzIHRoZSBhY2Nl c3MgcmVxdWVzdCwgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGlzc3VlcyBhbgogICAgICAgICAg ICBhY2Nlc3MgdG9rZW4gYW5kIGRlbGl2ZXJzIGl0IHRvIHRoZSBjbGllbnQgYnkgYWRkaW5nIHRo ZSBmb2xsb3dpbmcgcGFyYW1ldGVycyB0bwogICAgICAgICAgICB0aGUgZnJhZ21lbnQgY29tcG9u ZW50IG9mIHRoZSByZWRpcmVjdGlvbiBVUkkgdXNpbmcgdGhlCiAgICAgICAgICAgIDx0dD5hcHBs aWNhdGlvbi94LXd3dy1mb3JtLXVybGVuY29kZWQ8L3R0PiBmb3JtYXQ6CiAgICAgICAgICAKPC9w Pgo8cD4KICAgICAgICAgICAgPC9wPgo8YmxvY2txdW90ZSBjbGFzcz0idGV4dCI+PGRsPgo8ZHQ+ YWNjZXNzX3Rva2VuPC9kdD4KPGRkPgogICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICBS RVFVSVJFRC4gVGhlIGFjY2VzcyB0b2tlbiBpc3N1ZWQgYnkgdGhlIGF1dGhvcml6YXRpb24gc2Vy dmVyLgogICAgICAgICAgICAgIAo8L2RkPgo8ZHQ+dG9rZW5fdHlwZTwvZHQ+CjxkZD4KICAgICAg ICAgICAgICAgIAogICAgICAgICAgICAgICAgUkVRVUlSRUQuIFRoZSB0eXBlIG9mIHRoZSB0b2tl biBpc3N1ZWQgYXMgZGVzY3JpYmVkIGluCiAgICAgICAgICAgICAgICA8YSBjbGFzcz0naW5mbycg aHJlZj0nI3Rva2VuLXR5cGVzJz5TZWN0aW9uJm5ic3A7Ny4xPHNwYW4+ICg8L3NwYW4+PHNwYW4g Y2xhc3M9J2luZm8nPkFjY2VzcyBUb2tlbiBUeXBlczwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4u IFZhbHVlIGlzIGNhc2UgaW5zZW5zaXRpdmUuCiAgICAgICAgICAgICAgCjwvZGQ+CjxkdD5leHBp cmVzX2luPC9kdD4KPGRkPgogICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICBSRUNPTU1F TkRFRC4gVGhlIGxpZmV0aW1lIGluIHNlY29uZHMgb2YgdGhlIGFjY2VzcyB0b2tlbi4gRm9yIGV4 YW1wbGUsIHRoZSB2YWx1ZQogICAgICAgICAgICAgICAgPHR0PjM2MDA8L3R0PiBkZW5vdGVzIHRo YXQgdGhlIGFjY2VzcyB0b2tlbiB3aWxsIGV4cGlyZSBpbiBvbmUKICAgICAgICAgICAgICAgIGhv dXIgZnJvbSB0aGUgdGltZSB0aGUgcmVzcG9uc2Ugd2FzIGdlbmVyYXRlZC4gSWYgb21pdHRlZCwg dGhlIGF1dGhvcml6YXRpb24gc2VydmVyCiAgICAgICAgICAgICAgICBTSE9VTEQgcHJvdmlkZSB0 aGUgZXhwaXJhdGlvbiB0aW1lIHZpYSBvdGhlciBtZWFucyBvciBkb2N1bWVudCB0aGUgZGVmYXVs dCB2YWx1ZS4KICAgICAgICAgICAgICAKPC9kZD4KPGR0PnNjb3BlPC9kdD4KPGRkPgogICAgICAg ICAgICAgICAgCiAgICAgICAgICAgICAgICBPUFRJT05BTCwgaWYgaWRlbnRpY2FsIHRvIHRoZSBz Y29wZSByZXF1ZXN0ZWQgYnkgdGhlIGNsaWVudCwgb3RoZXJ3aXNlIFJFUVVJUkVELiBUaGUKICAg ICAgICAgICAgICAgIHNjb3BlIG9mIHRoZSBhY2Nlc3MgdG9rZW4gYXMgZGVzY3JpYmVkIGJ5IDxh IGNsYXNzPSdpbmZvJyBocmVmPScjc2NvcGUnPlNlY3Rpb24mbmJzcDszLjM8c3Bhbj4gKDwvc3Bh bj48c3BhbiBjbGFzcz0naW5mbyc+QWNjZXNzIFRva2VuIFNjb3BlPC9zcGFuPjxzcGFuPik8L3Nw YW4+PC9hPi4KICAgICAgICAgICAgICAKPC9kZD4KPGR0PnN0YXRlPC9kdD4KPGRkPgogICAgICAg ICAgICAgICAgCiAgICAgICAgICAgICAgICBSRVFVSVJFRCBpZiB0aGUgPHR0PnN0YXRlPC90dD4g cGFyYW1ldGVyIHdhcyBwcmVzZW50IGluIHRoZQogICAgICAgICAgICAgICAgY2xpZW50IGF1dGhv cml6YXRpb24gcmVxdWVzdC4gVGhlIGV4YWN0IHZhbHVlIHJlY2VpdmVkIGZyb20gdGhlIGNsaWVu dC4KICAgICAgICAgICAgICAKPC9kZD4KPC9kbD48L2Jsb2NrcXVvdGU+PHA+CiAgICAgICAgICAK PC9wPgo8cD4KICAgICAgICAgICAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIE1VU1QgTk9UIGlz c3VlIGEgcmVmcmVzaCB0b2tlbi4KICAgICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgICAgIEZv ciBleGFtcGxlLCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgcmVkaXJlY3RzIHRoZSB1c2VyLWFn ZW50IGJ5IHNlbmRpbmcgdGhlCiAgICAgICAgICAgICAgZm9sbG93aW5nIEhUVFAgcmVzcG9uc2Ug KFVSSSBleHRyYSBsaW5lIGJyZWFrcyBhcmUgZm9yIGRpc3BsYXkgcHVycG9zZXMgb25seSk6CiAg ICAgICAgICAgIAo8L3A+PGRpdiBzdHlsZT0nZGlzcGxheTogdGFibGU7IHdpZHRoOiAwOyBtYXJn aW4tbGVmdDogM2VtOyBtYXJnaW4tcmlnaHQ6IGF1dG8nPjxwcmU+CgogIEhUVFAvMS4xIDMwMiBG b3VuZAogIExvY2F0aW9uOiBodHRwOi8vZXhhbXBsZS5jb20vY2IjYWNjZXNzX3Rva2VuPTJZb3Ru RlpGRWpyMXpDc2ljTVdwQUEKICAgICAgICAgICAgJmFtcDtzdGF0ZT14eXomYW1wO3Rva2VuX3R5 cGU9ZXhhbXBsZSZhbXA7ZXhwaXJlc19pbj0zNjAwCgo8L3ByZT48L2Rpdj4KPHA+CiAgICAgICAg ICAgICAgRGV2ZWxvcGVycyBzaG91bGQgbm90ZSB0aGF0IHNvbWUgdXNlci1hZ2VudHMgZG8gbm90 IHN1cHBvcnQgdGhlIGluY2x1c2lvbiBvZiBhCiAgICAgICAgICAgICAgZnJhZ21lbnQgY29tcG9u ZW50IGluIHRoZSBIVFRQIDx0dD5Mb2NhdGlvbjwvdHQ+IHJlc3BvbnNlIGhlYWRlcgogICAgICAg ICAgICAgIGZpZWxkLiBTdWNoIGNsaWVudHMgd2lsbCByZXF1aXJlIHVzaW5nIG90aGVyIG1ldGhv ZHMgZm9yIHJlZGlyZWN0aW5nIHRoZSBjbGllbnQgdGhhbgogICAgICAgICAgICAgIGEgM3h4IHJl ZGlyZWN0aW9uIHJlc3BvbnNlLiBGb3IgZXhhbXBsZSwgcmV0dXJuaW5nIGFuIEhUTUwgcGFnZSB3 aGljaCBpbmNsdWRlcyBhCiAgICAgICAgICAgICAgJ2NvbnRpbnVlJyBidXR0b24gd2l0aCBhbiBh Y3Rpb24gbGlua2VkIHRvIHRoZSByZWRpcmVjdGlvbiBVUkkuCiAgICAgICAgICAgIAo8L3A+Cjxw PgogICAgICAgICAgICBUaGUgY2xpZW50IE1VU1QgaWdub3JlIHVucmVjb2duaXplZCByZXNwb25z ZSBwYXJhbWV0ZXJzLiBUaGUgYWNjZXNzIHRva2VuIHN0cmluZyBzaXplCiAgICAgICAgICAgIGlz IGxlZnQgdW5kZWZpbmVkIGJ5IHRoaXMgc3BlY2lmaWNhdGlvbi4gVGhlIGNsaWVudCBzaG91bGQg YXZvaWQgbWFraW5nIGFzc3VtcHRpb25zCiAgICAgICAgICAgIGFib3V0IHZhbHVlIHNpemVzLiBU aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgU0hPVUxEIGRvY3VtZW50IHRoZSBzaXplIG9mIGFueSB2 YWx1ZSBpdAogICAgICAgICAgICBpc3N1ZXMuCiAgICAgICAgICAKPC9wPgo8YSBuYW1lPSJpbXBs aWNpdC1hdXRoei1lcnJvciI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0 IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJy aWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJz cDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLjQuMi4yLjEiPjwv YT48aDM+NC4yLjIuMS4mbmJzcDsKRXJyb3IgUmVzcG9uc2U8L2gzPgoKPHA+CiAgICAgICAgICAg ICAgSWYgdGhlIHJlcXVlc3QgZmFpbHMgZHVlIHRvIGEgbWlzc2luZywgaW52YWxpZCwgb3IgbWlz bWF0Y2hpbmcgcmVkaXJlY3Rpb24gVVJJLCBvciBpZgogICAgICAgICAgICAgIHRoZSBjbGllbnQg aWRlbnRpZmllciBpcyBtaXNzaW5nIG9yIGludmFsaWQsIHRoZSBhdXRob3JpemF0aW9uIHNlcnZl ciBTSE9VTEQgaW5mb3JtCiAgICAgICAgICAgICAgdGhlIHJlc291cmNlIG93bmVyIG9mIHRoZSBl cnJvciwgYW5kIE1VU1QgTk9UIGF1dG9tYXRpY2FsbHkgcmVkaXJlY3QgdGhlIHVzZXItYWdlbnQK ICAgICAgICAgICAgICB0byB0aGUgaW52YWxpZCByZWRpcmVjdGlvbiBVUkkuCiAgICAgICAgICAg IAo8L3A+CjxwPgogICAgICAgICAgICAgIElmIHRoZSByZXNvdXJjZSBvd25lciBkZW5pZXMgdGhl IGFjY2VzcyByZXF1ZXN0IG9yIGlmIHRoZSByZXF1ZXN0IGZhaWxzIGZvciByZWFzb25zCiAgICAg ICAgICAgICAgb3RoZXIgdGhhbiBhIG1pc3Npbmcgb3IgaW52YWxpZCByZWRpcmVjdGlvbiBVUkks IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBpbmZvcm1zIHRoZQogICAgICAgICAgICAgIGNsaWVu dCBieSBhZGRpbmcgdGhlIGZvbGxvd2luZyBwYXJhbWV0ZXJzIHRvIHRoZSBmcmFnbWVudCBjb21w b25lbnQgb2YgdGhlCiAgICAgICAgICAgICAgcmVkaXJlY3Rpb24gVVJJIHVzaW5nIHRoZQogICAg ICAgICAgICAgIDx0dD5hcHBsaWNhdGlvbi94LXd3dy1mb3JtLXVybGVuY29kZWQ8L3R0PiBmb3Jt YXQ6CiAgICAgICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgICAgIDwvcD4KPGJsb2NrcXVvdGUg Y2xhc3M9InRleHQiPjxkbD4KPGR0PmVycm9yPC9kdD4KPGRkPgogICAgICAgICAgICAgICAgICAK ICAgICAgICAgICAgICAgICAgUkVRVUlSRUQuIEEgc2luZ2xlIEFTQ0lJIDxhIGNsYXNzPSdpbmZv JyBocmVmPScjVVNBU0NJSSc+W1VTQVNDSUldPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2lu Zm8nPkFtZXJpY2FuIE5hdGlvbmFsIFN0YW5kYXJkcyBJbnN0aXR1dGUsICZsZHF1bztDb2RlZCBD aGFyYWN0ZXIgU2V0IC0tIDctYml0IEFtZXJpY2FuIFN0YW5kYXJkIENvZGUgZm9yIEluZm9ybWF0 aW9uIEludGVyY2hhbmdlLCZyZHF1bzsgMTk4Ni48L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+IGVy cm9yIGNvZGUgZnJvbSB0aGUgZm9sbG93aW5nOgoKICAgICAgICAgICAgICAgICAgCjxibG9ja3F1 b3RlIGNsYXNzPSJ0ZXh0Ij48ZGw+CjxkdD5pbnZhbGlkX3JlcXVlc3Q8L2R0Pgo8ZGQ+CiAgICAg ICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgIFRoZSByZXF1ZXN0IGlzIG1p c3NpbmcgYSByZXF1aXJlZCBwYXJhbWV0ZXIsIGluY2x1ZGVzIGFuIGludmFsaWQKICAgICAgICAg ICAgICAgICAgICAgIHBhcmFtZXRlciB2YWx1ZSwgaW5jbHVkZXMgYSBwYXJhbWV0ZXIgbW9yZSB0 aGFuIG9uY2UsIG9yIGlzIG90aGVyd2lzZSBtYWxmb3JtZWQuCiAgICAgICAgICAgICAgICAgICAg CjwvZGQ+CjxkdD51bmF1dGhvcml6ZWRfY2xpZW50PC9kdD4KPGRkPgogICAgICAgICAgICAgICAg ICAgICAgCiAgICAgICAgICAgICAgICAgICAgICBUaGUgY2xpZW50IGlzIG5vdCBhdXRob3JpemVk IHRvIHJlcXVlc3QgYW4gYWNjZXNzIHRva2VuIHVzaW5nIHRoaXMgbWV0aG9kLgogICAgICAgICAg ICAgICAgICAgIAo8L2RkPgo8ZHQ+YWNjZXNzX2RlbmllZDwvZHQ+CjxkZD4KICAgICAgICAgICAg ICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgVGhlIHJlc291cmNlIG93bmVyIG9yIGF1 dGhvcml6YXRpb24gc2VydmVyIGRlbmllZCB0aGUgcmVxdWVzdC4KICAgICAgICAgICAgICAgICAg ICAKPC9kZD4KPGR0PnVuc3VwcG9ydGVkX3Jlc3BvbnNlX3R5cGU8L2R0Pgo8ZGQ+CiAgICAgICAg ICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgIFRoZSBhdXRob3JpemF0aW9uIHNl cnZlciBkb2VzIG5vdCBzdXBwb3J0IG9idGFpbmluZyBhbiBhY2Nlc3MgdG9rZW4gdXNpbmcKICAg ICAgICAgICAgICAgICAgICAgIHRoaXMgbWV0aG9kLgogICAgICAgICAgICAgICAgICAgIAo8L2Rk Pgo8ZHQ+aW52YWxpZF9zY29wZTwvZHQ+CjxkZD4KICAgICAgICAgICAgICAgICAgICAgIAogICAg ICAgICAgICAgICAgICAgICAgVGhlIHJlcXVlc3RlZCBzY29wZSBpcyBpbnZhbGlkLCB1bmtub3du LCBvciBtYWxmb3JtZWQuCiAgICAgICAgICAgICAgICAgICAgCjwvZGQ+CjxkdD5zZXJ2ZXJfZXJy b3I8L2R0Pgo8ZGQ+CiAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAg IFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBlbmNvdW50ZXJlZCBhbiB1bmV4cGVjdGVkIGNvbmRp dGlvbiB3aGljaCBwcmV2ZW50ZWQKICAgICAgICAgICAgICAgICAgICAgIGl0IGZyb20gZnVsZmls bGluZyB0aGUgcmVxdWVzdC4KICAgICAgICAgICAgICAgICAgICAKPC9kZD4KPGR0PnRlbXBvcmFy aWx5X3VuYXZhaWxhYmxlPC9kdD4KPGRkPgogICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAg ICAgICAgICAgICAgICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgaXMgY3VycmVudGx5IHVuYWJs ZSB0byBoYW5kbGUgdGhlIHJlcXVlc3QgZHVlIHRvIGEKICAgICAgICAgICAgICAgICAgICAgIHRl bXBvcmFyeSBvdmVybG9hZGluZyBvciBtYWludGVuYW5jZSBvZiB0aGUgc2VydmVyLgogICAgICAg ICAgICAgICAgICAgIAo8L2RkPgo8L2RsPjwvYmxvY2txdW90ZT4KCgkJICBWYWx1ZXMgZm9yIHRo ZSA8dHQ+ZXJyb3I8L3R0PiBwYXJhbWV0ZXIgTVVTVCBOT1QgaW5jbHVkZQoJCSAgY2hhcmFjdGVy cyBvdXRzaWRlIHRoZSBzZXQgJXgyMC0yMSAvICV4MjMtNUIgLyAleDVELTdFLgogICAgICAgICAg ICAgICAgCjwvZGQ+CjxkdD5lcnJvcl9kZXNjcmlwdGlvbjwvZHQ+CjxkZD4KICAgICAgICAgICAg ICAgICAgCiAgICAgICAgICAgICAgICAgIE9QVElPTkFMLiBBIGh1bWFuLXJlYWRhYmxlIEFTQ0lJ IDxhIGNsYXNzPSdpbmZvJyBocmVmPScjVVNBU0NJSSc+W1VTQVNDSUldPHNwYW4+ICg8L3NwYW4+ PHNwYW4gY2xhc3M9J2luZm8nPkFtZXJpY2FuIE5hdGlvbmFsIFN0YW5kYXJkcyBJbnN0aXR1dGUs ICZsZHF1bztDb2RlZCBDaGFyYWN0ZXIgU2V0IC0tIDctYml0IEFtZXJpY2FuIFN0YW5kYXJkIENv ZGUgZm9yIEluZm9ybWF0aW9uIEludGVyY2hhbmdlLCZyZHF1bzsgMTk4Ni48L3NwYW4+PHNwYW4+ KTwvc3Bhbj48L2E+IHRleHQgcHJvdmlkaW5nIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24sCiAgICAg ICAgICAgICAgICAgIHVzZWQgdG8gYXNzaXN0IHRoZSBjbGllbnQgZGV2ZWxvcGVyIGluIHVuZGVy c3RhbmRpbmcgdGhlIGVycm9yIHRoYXQgb2NjdXJyZWQuCgkJICA8YnIgLz4KCgkJICBWYWx1ZXMg Zm9yIHRoZSA8dHQ+ZXJyb3JfZGVzY3JpcHRpb248L3R0PiBwYXJhbWV0ZXIgTVVTVCBOT1QgaW5j bHVkZQoJCSAgY2hhcmFjdGVycyBvdXRzaWRlIHRoZSBzZXQgJXgyMC0yMSAvICV4MjMtNUIgLyAl eDVELTdFLgogICAgICAgICAgICAgICAgCjwvZGQ+CjxkdD5lcnJvcl91cmk8L2R0Pgo8ZGQ+CiAg ICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICBPUFRJT05BTC4gQSBVUkkgaWRlbnRp ZnlpbmcgYSBodW1hbi1yZWFkYWJsZSB3ZWIgcGFnZSB3aXRoIGluZm9ybWF0aW9uIGFib3V0IHRo ZQogICAgICAgICAgICAgICAgICBlcnJvciwgdXNlZCB0byBwcm92aWRlIHRoZSBjbGllbnQgZGV2 ZWxvcGVyIHdpdGggYWRkaXRpb25hbCBpbmZvcm1hdGlvbiBhYm91dCB0aGUKICAgICAgICAgICAg ICAgICAgZXJyb3IuCgkJICA8YnIgLz4KCgkJICBWYWx1ZXMgZm9yIHRoZSA8dHQ+ZXJyb3JfdXJp PC90dD4gcGFyYW1ldGVyCgkJICBNVVNUIGNvbmZvcm0gdG8gdGhlIFVSSS1SZWZlcmVuY2Ugc3lu dGF4LCBhbmQgdGh1cyBNVVNUIE5PVCBpbmNsdWRlCgkJICBjaGFyYWN0ZXJzIG91dHNpZGUgdGhl IHNldCAleDIxIC8gJXgyMy01QiAvICV4NUQtN0UuCiAgICAgICAgICAgICAgICAKPC9kZD4KPGR0 PnN0YXRlPC9kdD4KPGRkPgogICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgUkVR VUlSRUQgaWYgYSA8dHQ+c3RhdGU8L3R0PiBwYXJhbWV0ZXIgd2FzIHByZXNlbnQgaW4gdGhlCiAg ICAgICAgICAgICAgICAgIGNsaWVudCBhdXRob3JpemF0aW9uIHJlcXVlc3QuIFRoZSBleGFjdCB2 YWx1ZSByZWNlaXZlZCBmcm9tIHRoZSBjbGllbnQuCiAgICAgICAgICAgICAgICAKPC9kZD4KPC9k bD48L2Jsb2NrcXVvdGU+PHA+CiAgICAgICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgICAgICAg Rm9yIGV4YW1wbGUsIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciByZWRpcmVjdHMgdGhlIHVzZXIt YWdlbnQgYnkgc2VuZGluZyB0aGUKICAgICAgICAgICAgICAgIGZvbGxvd2luZyBIVFRQIHJlc3Bv bnNlOgogICAgICAgICAgICAgIAo8L3A+PGRpdiBzdHlsZT0nZGlzcGxheTogdGFibGU7IHdpZHRo OiAwOyBtYXJnaW4tbGVmdDogM2VtOyBtYXJnaW4tcmlnaHQ6IGF1dG8nPjxwcmU+CgogIEhUVFAv MS4xIDMwMiBGb3VuZAogIExvY2F0aW9uOiBodHRwczovL2NsaWVudC5leGFtcGxlLmNvbS9jYiNl cnJvcj1hY2Nlc3NfZGVuaWVkJmFtcDtzdGF0ZT14eXoKCjwvcHJlPjwvZGl2Pgo8YSBuYW1lPSJn cmFudC1wYXNzd29yZCI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBj ZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdo dCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8 L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLjQuMyI+PC9hPjxoMz40 LjMuJm5ic3A7ClJlc291cmNlIE93bmVyIFBhc3N3b3JkIENyZWRlbnRpYWxzIEdyYW50PC9oMz4K CjxwPgogICAgICAgICAgVGhlIHJlc291cmNlIG93bmVyIHBhc3N3b3JkIGNyZWRlbnRpYWxzIGdy YW50IHR5cGUgaXMgc3VpdGFibGUgaW4gY2FzZXMgd2hlcmUgdGhlCiAgICAgICAgICByZXNvdXJj ZSBvd25lciBoYXMgYSB0cnVzdCByZWxhdGlvbnNoaXAgd2l0aCB0aGUgY2xpZW50LCBzdWNoIGFz IHRoZSBkZXZpY2Ugb3BlcmF0aW5nCiAgICAgICAgICBzeXN0ZW0gb3IgYSBoaWdobHkgcHJpdmls ZWdlZCBhcHBsaWNhdGlvbi4gVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHNob3VsZCB0YWtlIHNw ZWNpYWwKICAgICAgICAgIGNhcmUgd2hlbiBlbmFibGluZyB0aGlzIGdyYW50IHR5cGUsIGFuZCBv bmx5IGFsbG93IGl0IHdoZW4gb3RoZXIgZmxvd3MgYXJlIG5vdCB2aWFibGUuCiAgICAgICAgCjwv cD4KPHA+CiAgICAgICAgICBUaGUgZ3JhbnQgdHlwZSBpcyBzdWl0YWJsZSBmb3IgY2xpZW50cyBj YXBhYmxlIG9mIG9idGFpbmluZyB0aGUgcmVzb3VyY2Ugb3duZXIncwogICAgICAgICAgY3JlZGVu dGlhbHMgKHVzZXJuYW1lIGFuZCBwYXNzd29yZCwgdHlwaWNhbGx5IHVzaW5nIGFuIGludGVyYWN0 aXZlIGZvcm0pLiBJdCBpcyBhbHNvIHVzZWQKICAgICAgICAgIHRvIG1pZ3JhdGUgZXhpc3Rpbmcg Y2xpZW50cyB1c2luZyBkaXJlY3QgYXV0aGVudGljYXRpb24gc2NoZW1lcyBzdWNoIGFzIEhUVFAg QmFzaWMgb3IKICAgICAgICAgIERpZ2VzdCBhdXRoZW50aWNhdGlvbiB0byBPQXV0aCBieSBjb252 ZXJ0aW5nIHRoZSBzdG9yZWQgY3JlZGVudGlhbHMgdG8gYW4gYWNjZXNzIHRva2VuLgogICAgICAg IAo8L3A+PGJyIC8+PGhyIGNsYXNzPSJpbnNlcnQiIC8+CjxhIG5hbWU9IkZpZ3VyZS01Ij48L2E+ CjxkaXYgc3R5bGU9J2Rpc3BsYXk6IHRhYmxlOyB3aWR0aDogMDsgbWFyZ2luLWxlZnQ6IDNlbTsg bWFyZ2luLXJpZ2h0OiBhdXRvJz48cHJlPgoKICArLS0tLS0tLS0tLSsKICB8IFJlc291cmNlIHwK ICB8ICBPd25lciAgIHwKICB8ICAgICAgICAgIHwKICArLS0tLS0tLS0tLSsKICAgICAgIHYKICAg ICAgIHwgICAgUmVzb3VyY2UgT3duZXIKICAgICAgKEEpIFBhc3N3b3JkIENyZWRlbnRpYWxzCiAg ICAgICB8CiAgICAgICB2CiAgKy0tLS0tLS0tLSsgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgKy0tLS0tLS0tLS0tLS0tLSsKICB8ICAgICAgICAgfCZndDstLShCKS0tLS0gUmVzb3Vy Y2UgT3duZXIgLS0tLS0tLSZndDt8ICAgICAgICAgICAgICAgfAogIHwgICAgICAgICB8ICAgICAg ICAgUGFzc3dvcmQgQ3JlZGVudGlhbHMgICAgIHwgQXV0aG9yaXphdGlvbiB8CiAgfCBDbGllbnQg IHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgU2VydmVyICAgIHwKICB8 ICAgICAgICAgfCZsdDstLShDKS0tLS0gQWNjZXNzIFRva2VuIC0tLS0tLS0tLSZsdDt8ICAgICAg ICAgICAgICAgfAogIHwgICAgICAgICB8ICAgICh3LyBPcHRpb25hbCBSZWZyZXNoIFRva2VuKSAg IHwgICAgICAgICAgICAgICB8CiAgKy0tLS0tLS0tLSsgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLSsKCjwvcHJlPjwvZGl2Pjx0YWJsZSBib3JkZXI9IjAi IGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgYWxpZ249ImNlbnRlciI+PHRyPjx0ZCBh bGlnbj0iY2VudGVyIj48Zm9udCBmYWNlPSJtb25hY28sIE1TIFNhbnMgU2VyaWYiIHNpemU9IjEi PjxiPiZuYnNwO0ZpZ3VyZSZuYnNwOzU6IFJlc291cmNlIE93bmVyIFBhc3N3b3JkIENyZWRlbnRp YWxzIEZsb3cmbmJzcDs8L2I+PC9mb250PjxiciAvPjwvdGQ+PC90cj48L3RhYmxlPjxociBjbGFz cz0iaW5zZXJ0IiAvPgoKPHA+CiAgICAgICAgICBUaGUgZmxvdyBpbGx1c3RyYXRlZCBpbiA8YSBj bGFzcz0naW5mbycgaHJlZj0nI0ZpZ3VyZS01Jz5GaWd1cmUmbmJzcDs1PHNwYW4+ICg8L3NwYW4+ PHNwYW4gY2xhc3M9J2luZm8nPlJlc291cmNlIE93bmVyIFBhc3N3b3JkIENyZWRlbnRpYWxzIEZs b3c8L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+IGluY2x1ZGVzIHRoZSBmb2xsb3dpbmcgc3RlcHM6 CiAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICA8L3A+CjxibG9ja3F1b3RlIGNsYXNzPSJ0ZXh0 Ij48ZGw+CjxkdD4oQSk8L2R0Pgo8ZGQ+CiAgICAgICAgICAgICAgVGhlIHJlc291cmNlIG93bmVy IHByb3ZpZGVzIHRoZSBjbGllbnQgd2l0aCBpdHMgdXNlcm5hbWUgYW5kIHBhc3N3b3JkLgogICAg ICAgICAgICAKPC9kZD4KPGR0PihCKTwvZHQ+CjxkZD4KICAgICAgICAgICAgICBUaGUgY2xpZW50 IHJlcXVlc3RzIGFuIGFjY2VzcyB0b2tlbiBmcm9tIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlcidz IHRva2VuIGVuZHBvaW50IGJ5CiAgICAgICAgICAgICAgaW5jbHVkaW5nIHRoZSBjcmVkZW50aWFs cyByZWNlaXZlZCBmcm9tIHRoZSByZXNvdXJjZSBvd25lci4gV2hlbiBtYWtpbmcgdGhlIHJlcXVl c3QsCiAgICAgICAgICAgICAgdGhlIGNsaWVudCBhdXRoZW50aWNhdGVzIHdpdGggdGhlIGF1dGhv cml6YXRpb24gc2VydmVyLgogICAgICAgICAgICAKPC9kZD4KPGR0PihDKTwvZHQ+CjxkZD4KICAg ICAgICAgICAgICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYXV0aGVudGljYXRlcyB0aGUgY2xp ZW50IGFuZCB2YWxpZGF0ZXMgdGhlIHJlc291cmNlIG93bmVyCiAgICAgICAgICAgICAgY3JlZGVu dGlhbHMsIGFuZCBpZiB2YWxpZCBpc3N1ZXMgYW4gYWNjZXNzIHRva2VuLgogICAgICAgICAgICAK PC9kZD4KPC9kbD48L2Jsb2NrcXVvdGU+PHA+CiAgICAgICAgCjwvcD4KPGEgbmFtZT0iYW5jaG9y MjciPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9 IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQg Y2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90 cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi40LjMuMSI+PC9hPjxoMz40LjMuMS4mbmJz cDsKQXV0aG9yaXphdGlvbiBSZXF1ZXN0IGFuZCBSZXNwb25zZTwvaDM+Cgo8cD4KICAgICAgICAg ICAgVGhlIG1ldGhvZCB0aHJvdWdoIHdoaWNoIHRoZSBjbGllbnQgb2J0YWlucyB0aGUgcmVzb3Vy Y2Ugb3duZXIgY3JlZGVudGlhbHMgaXMgYmV5b25kCiAgICAgICAgICAgIHRoZSBzY29wZSBvZiB0 aGlzIHNwZWNpZmljYXRpb24uIFRoZSBjbGllbnQgTVVTVCBkaXNjYXJkIHRoZSBjcmVkZW50aWFs cyBvbmNlIGFuIGFjY2VzcwogICAgICAgICAgICB0b2tlbiBoYXMgYmVlbiBvYnRhaW5lZC4KICAg ICAgICAgIAo8L3A+CjxhIG5hbWU9InBhc3N3b3JkLXRvay1yZXEiPjwvYT48YnIgLz48aHIgLz4K PHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBj bGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJl Zj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJy ZmMuc2VjdGlvbi40LjMuMiI+PC9hPjxoMz40LjMuMi4mbmJzcDsKQWNjZXNzIFRva2VuIFJlcXVl c3Q8L2gzPgoKPHA+CiAgICAgICAgICAgIFRoZSBjbGllbnQgbWFrZXMgYSByZXF1ZXN0IHRvIHRo ZSB0b2tlbiBlbmRwb2ludCBieSBhZGRpbmcgdGhlIGZvbGxvd2luZyBwYXJhbWV0ZXJzCiAgICAg ICAgICAgIHVzaW5nIHRoZSA8dHQ+YXBwbGljYXRpb24veC13d3ctZm9ybS11cmxlbmNvZGVkPC90 dD4gZm9ybWF0IGluIHRoZQogICAgICAgICAgICBIVFRQIHJlcXVlc3QgZW50aXR5LWJvZHk6CiAg ICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgICAgPC9wPgo8YmxvY2txdW90ZSBjbGFzcz0idGV4 dCI+PGRsPgo8ZHQ+Z3JhbnRfdHlwZTwvZHQ+CjxkZD4KICAgICAgICAgICAgICAgIAogICAgICAg ICAgICAgICAgUkVRVUlSRUQuIFZhbHVlIE1VU1QgYmUgc2V0IHRvIDx0dD5wYXNzd29yZDwvdHQ+ LgogICAgICAgICAgICAgIAo8L2RkPgo8ZHQ+dXNlcm5hbWU8L2R0Pgo8ZGQ+CiAgICAgICAgICAg ICAgICAKICAgICAgICAgICAgICAgIFJFUVVJUkVELiBUaGUgcmVzb3VyY2Ugb3duZXIgdXNlcm5h bWUuCiAgICAgICAgICAgICAgCjwvZGQ+CjxkdD5wYXNzd29yZDwvZHQ+CjxkZD4KICAgICAgICAg ICAgICAgIAogICAgICAgICAgICAgICAgUkVRVUlSRUQuIFRoZSByZXNvdXJjZSBvd25lciBwYXNz d29yZC4KICAgICAgICAgICAgICAKPC9kZD4KPGR0PnNjb3BlPC9kdD4KPGRkPgogICAgICAgICAg ICAgICAgCiAgICAgICAgICAgICAgICBPUFRJT05BTC4gVGhlIHNjb3BlIG9mIHRoZSBhY2Nlc3Mg cmVxdWVzdCBhcyBkZXNjcmliZWQgYnkgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNzY29wZSc+U2Vj dGlvbiZuYnNwOzMuMzxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5BY2Nlc3MgVG9r ZW4gU2NvcGU8L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+LgogICAgICAgICAgICAgIAo8L2RkPgo8 L2RsPjwvYmxvY2txdW90ZT48cD4KICAgICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgICBJZiB0 aGUgY2xpZW50IHR5cGUgaXMgY29uZmlkZW50aWFsIG9yIHRoZSBjbGllbnQgd2FzIGlzc3VlZCBj bGllbnQgY3JlZGVudGlhbHMgKG9yCiAgICAgICAgICAgIGFzc2lnbmVkIG90aGVyIGF1dGhlbnRp Y2F0aW9uIHJlcXVpcmVtZW50cyksIHRoZSBjbGllbnQgTVVTVCBhdXRoZW50aWNhdGUgd2l0aCB0 aGUKICAgICAgICAgICAgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYXMgZGVzY3JpYmVkIGluIDxhIGNs YXNzPSdpbmZvJyBocmVmPScjdG9rZW4tZW5kcG9pbnQtYXV0aCc+U2VjdGlvbiZuYnNwOzMuMi4x PHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkNsaWVudCBBdXRoZW50aWNhdGlvbjwv c3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4uCiAgICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgICAg ICBGb3IgZXhhbXBsZSwgdGhlIGNsaWVudCBtYWtlcyB0aGUgZm9sbG93aW5nIEhUVFAgcmVxdWVz dCB1c2luZyB0cmFuc3BvcnQtbGF5ZXIKICAgICAgICAgICAgICBzZWN1cml0eSAoZXh0cmEgbGlu ZSBicmVha3MgYXJlIGZvciBkaXNwbGF5IHB1cnBvc2VzIG9ubHkpOgogICAgICAgICAgICAKPC9w PjxkaXYgc3R5bGU9J2Rpc3BsYXk6IHRhYmxlOyB3aWR0aDogMDsgbWFyZ2luLWxlZnQ6IDNlbTsg bWFyZ2luLXJpZ2h0OiBhdXRvJz48cHJlPgoKICBQT1NUIC90b2tlbiBIVFRQLzEuMQogIEhvc3Q6 IHNlcnZlci5leGFtcGxlLmNvbQogIEF1dGhvcml6YXRpb246IEJhc2ljIGN6WkNhR1JTYTNGME16 cG5XREZtUW1GME0ySlcKICBDb250ZW50LVR5cGU6IGFwcGxpY2F0aW9uL3gtd3d3LWZvcm0tdXJs ZW5jb2RlZDtjaGFyc2V0PVVURi04CgogIGdyYW50X3R5cGU9cGFzc3dvcmQmYW1wO3VzZXJuYW1l PWpvaG5kb2UmYW1wO3Bhc3N3b3JkPUEzZGRqM3cKCjwvcHJlPjwvZGl2Pgo8cD4KICAgICAgICAg ICAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIE1VU1Q6CiAgICAgICAgICAKPC9wPgo8cD4KICAg ICAgICAgICAgPC9wPgo8dWwgY2xhc3M9InRleHQiPgo8bGk+CiAgICAgICAgICAgICAgICByZXF1 aXJlIGNsaWVudCBhdXRoZW50aWNhdGlvbiBmb3IgY29uZmlkZW50aWFsIGNsaWVudHMgb3IgZm9y IGFueSBjbGllbnQgdGhhdCB3YXMKICAgICAgICAgICAgICAgIGlzc3VlZCBjbGllbnQgY3JlZGVu dGlhbHMgKG9yIHdpdGggb3RoZXIgYXV0aGVudGljYXRpb24gcmVxdWlyZW1lbnRzKSwKICAgICAg ICAgICAgICAKPC9saT4KPGxpPgogICAgICAgICAgICAgICAgYXV0aGVudGljYXRlIHRoZSBjbGll bnQgaWYgY2xpZW50IGF1dGhlbnRpY2F0aW9uIGlzIGluY2x1ZGVkLCBhbmQKICAgICAgICAgICAg ICAKPC9saT4KPGxpPgogICAgICAgICAgICAgICAgdmFsaWRhdGUgdGhlIHJlc291cmNlIG93bmVy IHBhc3N3b3JkIGNyZWRlbnRpYWxzIHVzaW5nIGl0cyBleGlzdGluZyBwYXNzd29yZAogICAgICAg ICAgICAgICAgdmFsaWRhdGlvbiBhbGdvcml0aG0uCiAgICAgICAgICAgICAgCjwvbGk+CjwvdWw+ PHA+CiAgICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgICAgU2luY2UgdGhpcyBhY2Nlc3MgdG9r ZW4gcmVxdWVzdCB1dGlsaXplcyB0aGUgcmVzb3VyY2Ugb3duZXIncyBwYXNzd29yZCwgdGhlCiAg ICAgICAgICAgIGF1dGhvcml6YXRpb24gc2VydmVyIE1VU1QgcHJvdGVjdCB0aGUgZW5kcG9pbnQg YWdhaW5zdCBicnV0ZSBmb3JjZSBhdHRhY2tzIChlLmcuIHVzaW5nCiAgICAgICAgICAgIHJhdGUt bGltaXRhdGlvbiBvciBnZW5lcmF0aW5nIGFsZXJ0cykuCiAgICAgICAgICAKPC9wPgo8YSBuYW1l PSJhbmNob3IyOCI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxs cGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+ PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+ PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLjQuMy4zIj48L2E+PGgzPjQu My4zLiZuYnNwOwpBY2Nlc3MgVG9rZW4gUmVzcG9uc2U8L2gzPgoKPHA+CiAgICAgICAgICAgIElm IHRoZSBhY2Nlc3MgdG9rZW4gcmVxdWVzdCBpcyB2YWxpZCBhbmQgYXV0aG9yaXplZCwgdGhlIGF1 dGhvcml6YXRpb24gc2VydmVyIGlzc3VlcyBhbgogICAgICAgICAgICBhY2Nlc3MgdG9rZW4gYW5k IG9wdGlvbmFsIHJlZnJlc2ggdG9rZW4gYXMgZGVzY3JpYmVkIGluIDxhIGNsYXNzPSdpbmZvJyBo cmVmPScjdG9rZW4tcmVzcG9uc2UnPlNlY3Rpb24mbmJzcDs1LjE8c3Bhbj4gKDwvc3Bhbj48c3Bh biBjbGFzcz0naW5mbyc+U3VjY2Vzc2Z1bCBSZXNwb25zZTwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwv YT4uCiAgICAgICAgICAgIElmIHRoZSByZXF1ZXN0IGZhaWxlZCBjbGllbnQgYXV0aGVudGljYXRp b24gb3IgaXMgaW52YWxpZCwgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHJldHVybnMKICAgICAg ICAgICAgYW4gZXJyb3IgcmVzcG9uc2UgYXMgZGVzY3JpYmVkIGluIDxhIGNsYXNzPSdpbmZvJyBo cmVmPScjdG9rZW4tZXJyb3JzJz5TZWN0aW9uJm5ic3A7NS4yPHNwYW4+ICg8L3NwYW4+PHNwYW4g Y2xhc3M9J2luZm8nPkVycm9yIFJlc3BvbnNlPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPi4KICAg ICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgICAgIEFuIGV4YW1wbGUgc3VjY2Vzc2Z1bCByZXNw b25zZToKICAgICAgICAgICAgCjwvcD48ZGl2IHN0eWxlPSdkaXNwbGF5OiB0YWJsZTsgd2lkdGg6 IDA7IG1hcmdpbi1sZWZ0OiAzZW07IG1hcmdpbi1yaWdodDogYXV0byc+PHByZT4KCiAgSFRUUC8x LjEgMjAwIE9LCiAgQ29udGVudC1UeXBlOiBhcHBsaWNhdGlvbi9qc29uO2NoYXJzZXQ9VVRGLTgK ICBDYWNoZS1Db250cm9sOiBuby1zdG9yZQogIFByYWdtYTogbm8tY2FjaGUKCiAgewogICAgImFj Y2Vzc190b2tlbiI6IjJZb3RuRlpGRWpyMXpDc2ljTVdwQUEiLAogICAgInRva2VuX3R5cGUiOiJl eGFtcGxlIiwKICAgICJleHBpcmVzX2luIjozNjAwLAogICAgInJlZnJlc2hfdG9rZW4iOiJ0R3p2 M0pPa0YwWEc1UXgyVGxLV0lBIiwKICAgICJleGFtcGxlX3BhcmFtZXRlciI6ImV4YW1wbGVfdmFs dWUiCiAgfQoKPC9wcmU+PC9kaXY+CjxhIG5hbWU9ImdyYW50LWNsaWVudCI+PC9hPjxiciAvPjxo ciAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9 IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48 YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5h bWU9InJmYy5zZWN0aW9uLjQuNCI+PC9hPjxoMz40LjQuJm5ic3A7CkNsaWVudCBDcmVkZW50aWFs cyBHcmFudDwvaDM+Cgo8cD4KICAgICAgICAgIFRoZSBjbGllbnQgY2FuIHJlcXVlc3QgYW4gYWNj ZXNzIHRva2VuIHVzaW5nIG9ubHkgaXRzIGNsaWVudCBjcmVkZW50aWFscyAob3Igb3RoZXIKICAg ICAgICAgIHN1cHBvcnRlZCBtZWFucyBvZiBhdXRoZW50aWNhdGlvbikgd2hlbiB0aGUgY2xpZW50 IGlzIHJlcXVlc3RpbmcgYWNjZXNzIHRvIHRoZQogICAgICAgICAgcHJvdGVjdGVkIHJlc291cmNl cyB1bmRlciBpdHMgY29udHJvbCwgb3IgdGhvc2Ugb2YgYW5vdGhlciByZXNvdXJjZSBvd25lciB3 aGljaCBoYXMgYmVlbgogICAgICAgICAgcHJldmlvdXNseSBhcnJhbmdlZCB3aXRoIHRoZSBhdXRo b3JpemF0aW9uIHNlcnZlciAodGhlIG1ldGhvZCBvZiB3aGljaCBpcyBiZXlvbmQgdGhlCiAgICAg ICAgICBzY29wZSBvZiB0aGlzIHNwZWNpZmljYXRpb24pLgogICAgICAgIAo8L3A+CjxwPgogICAg ICAgICAgVGhlIGNsaWVudCBjcmVkZW50aWFscyBncmFudCB0eXBlIE1VU1Qgb25seSBiZSB1c2Vk IGJ5IGNvbmZpZGVudGlhbCBjbGllbnRzLgogICAgICAgIAo8L3A+PGJyIC8+PGhyIGNsYXNzPSJp bnNlcnQiIC8+CjxhIG5hbWU9IkZpZ3VyZS02Ij48L2E+CjxkaXYgc3R5bGU9J2Rpc3BsYXk6IHRh YmxlOyB3aWR0aDogMDsgbWFyZ2luLWxlZnQ6IDNlbTsgbWFyZ2luLXJpZ2h0OiBhdXRvJz48cHJl PgoKICArLS0tLS0tLS0tKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0t LS0tLS0tLS0tKwogIHwgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHwgICAgICAgICAgICAgICB8CiAgfCAgICAgICAgIHwmZ3Q7LS0oQSktIENsaWVudCBBdXRoZW50 aWNhdGlvbiAtLS0mZ3Q7fCBBdXRob3JpemF0aW9uIHwKICB8IENsaWVudCAgfCAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB8ICAgICBTZXJ2ZXIgICAgfAogIHwgICAgICAgICB8Jmx0 Oy0tKEIpLS0tLSBBY2Nlc3MgVG9rZW4gLS0tLS0tLS0tJmx0O3wgICAgICAgICAgICAgICB8CiAg fCAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAg ICAgIHwKICArLS0tLS0tLS0tKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0t LS0tLS0tLS0tLS0tKwoKPC9wcmU+PC9kaXY+PHRhYmxlIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9 IjAiIGNlbGxzcGFjaW5nPSIyIiBhbGlnbj0iY2VudGVyIj48dHI+PHRkIGFsaWduPSJjZW50ZXIi Pjxmb250IGZhY2U9Im1vbmFjbywgTVMgU2FucyBTZXJpZiIgc2l6ZT0iMSI+PGI+Jm5ic3A7Rmln dXJlJm5ic3A7NjogQ2xpZW50IENyZWRlbnRpYWxzIEZsb3cmbmJzcDs8L2I+PC9mb250PjxiciAv PjwvdGQ+PC90cj48L3RhYmxlPjxociBjbGFzcz0iaW5zZXJ0IiAvPgoKPHA+CiAgICAgICAgICBU aGUgZmxvdyBpbGx1c3RyYXRlZCBpbiA8YSBjbGFzcz0naW5mbycgaHJlZj0nI0ZpZ3VyZS02Jz5G aWd1cmUmbmJzcDs2PHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkNsaWVudCBDcmVk ZW50aWFscyBGbG93PC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPiBpbmNsdWRlcyB0aGUgZm9sbG93 aW5nIHN0ZXBzOgogICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgPC9wPgo8YmxvY2txdW90ZSBj bGFzcz0idGV4dCI+PGRsPgo8ZHQ+KEEpPC9kdD4KPGRkPgogICAgICAgICAgICAgIFRoZSBjbGll bnQgYXV0aGVudGljYXRlcyB3aXRoIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBhbmQgcmVxdWVz dHMgYW4gYWNjZXNzIHRva2VuCiAgICAgICAgICAgICAgZnJvbSB0aGUgdG9rZW4gZW5kcG9pbnQu CiAgICAgICAgICAgIAo8L2RkPgo8ZHQ+KEIpPC9kdD4KPGRkPgogICAgICAgICAgICAgIFRoZSBh dXRob3JpemF0aW9uIHNlcnZlciBhdXRoZW50aWNhdGVzIHRoZSBjbGllbnQsIGFuZCBpZiB2YWxp ZCBpc3N1ZXMgYW4gYWNjZXNzCiAgICAgICAgICAgICAgdG9rZW4uCiAgICAgICAgICAgIAo8L2Rk Pgo8L2RsPjwvYmxvY2txdW90ZT48cD4KICAgICAgICAKPC9wPgo8YSBuYW1lPSJhbmNob3IyOSI+ PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIg Y2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFz cz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwv dGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLjQuNC4xIj48L2E+PGgzPjQuNC4xLiZuYnNwOwpB dXRob3JpemF0aW9uIFJlcXVlc3QgYW5kIFJlc3BvbnNlPC9oMz4KCjxwPgogICAgICAgICAgICBT aW5jZSB0aGUgY2xpZW50IGF1dGhlbnRpY2F0aW9uIGlzIHVzZWQgYXMgdGhlIGF1dGhvcml6YXRp b24gZ3JhbnQsIG5vIGFkZGl0aW9uYWwKICAgICAgICAgICAgYXV0aG9yaXphdGlvbiByZXF1ZXN0 IGlzIG5lZWRlZC4KICAgICAgICAgIAo8L3A+CjxhIG5hbWU9ImNsaWVudC1yZXEiPjwvYT48YnIg Lz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFj aW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1 ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8 YSBuYW1lPSJyZmMuc2VjdGlvbi40LjQuMiI+PC9hPjxoMz40LjQuMi4mbmJzcDsKQWNjZXNzIFRv a2VuIFJlcXVlc3Q8L2gzPgoKPHA+CiAgICAgICAgICAgIFRoZSBjbGllbnQgbWFrZXMgYSByZXF1 ZXN0IHRvIHRoZSB0b2tlbiBlbmRwb2ludCBieSBhZGRpbmcgdGhlIGZvbGxvd2luZyBwYXJhbWV0 ZXJzCiAgICAgICAgICAgIHVzaW5nIHRoZSA8dHQ+YXBwbGljYXRpb24veC13d3ctZm9ybS11cmxl bmNvZGVkPC90dD4gZm9ybWF0IGluIHRoZQogICAgICAgICAgICBIVFRQIHJlcXVlc3QgZW50aXR5 LWJvZHk6CiAgICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgICAgPC9wPgo8YmxvY2txdW90ZSBj bGFzcz0idGV4dCI+PGRsPgo8ZHQ+Z3JhbnRfdHlwZTwvZHQ+CjxkZD4KICAgICAgICAgICAgICAg IAogICAgICAgICAgICAgICAgUkVRVUlSRUQuIFZhbHVlIE1VU1QgYmUgc2V0IHRvIDx0dD5jbGll bnRfY3JlZGVudGlhbHM8L3R0Pi4KICAgICAgICAgICAgICAKPC9kZD4KPGR0PnNjb3BlPC9kdD4K PGRkPgogICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICBPUFRJT05BTC4gVGhlIHNjb3Bl IG9mIHRoZSBhY2Nlc3MgcmVxdWVzdCBhcyBkZXNjcmliZWQgYnkgPGEgY2xhc3M9J2luZm8nIGhy ZWY9JyNzY29wZSc+U2VjdGlvbiZuYnNwOzMuMzxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdp bmZvJz5BY2Nlc3MgVG9rZW4gU2NvcGU8L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+LgogICAgICAg ICAgICAgIAo8L2RkPgo8L2RsPjwvYmxvY2txdW90ZT48cD4KICAgICAgICAgIAo8L3A+CjxwPgog ICAgICAgICAgICBUaGUgY2xpZW50IE1VU1QgYXV0aGVudGljYXRlIHdpdGggdGhlIGF1dGhvcml6 YXRpb24gc2VydmVyIGFzIGRlc2NyaWJlZCBpbgogICAgICAgICAgICA8YSBjbGFzcz0naW5mbycg aHJlZj0nI3Rva2VuLWVuZHBvaW50LWF1dGgnPlNlY3Rpb24mbmJzcDszLjIuMTxzcGFuPiAoPC9z cGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5DbGllbnQgQXV0aGVudGljYXRpb248L3NwYW4+PHNwYW4+ KTwvc3Bhbj48L2E+LgogICAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICAgICAgRm9yIGV4YW1w bGUsIHRoZSBjbGllbnQgbWFrZXMgdGhlIGZvbGxvd2luZyBIVFRQIHJlcXVlc3QgdXNpbmcgdHJh bnNwb3J0LWxheWVyCiAgICAgICAgICAgICAgc2VjdXJpdHkgKGV4dHJhIGxpbmUgYnJlYWtzIGFy ZSBmb3IgZGlzcGxheSBwdXJwb3NlcyBvbmx5KToKICAgICAgICAgICAgCjwvcD48ZGl2IHN0eWxl PSdkaXNwbGF5OiB0YWJsZTsgd2lkdGg6IDA7IG1hcmdpbi1sZWZ0OiAzZW07IG1hcmdpbi1yaWdo dDogYXV0byc+PHByZT4KCiAgUE9TVCAvdG9rZW4gSFRUUC8xLjEKICBIb3N0OiBzZXJ2ZXIuZXhh bXBsZS5jb20KICBBdXRob3JpemF0aW9uOiBCYXNpYyBjelpDYUdSU2EzRjBNenBuV0RGbVFtRjBN MkpXCiAgQ29udGVudC1UeXBlOiBhcHBsaWNhdGlvbi94LXd3dy1mb3JtLXVybGVuY29kZWQ7Y2hh cnNldD1VVEYtOAoKICBncmFudF90eXBlPWNsaWVudF9jcmVkZW50aWFscwoKPC9wcmU+PC9kaXY+ CjxwPgogICAgICAgICAgICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVTVCBhdXRoZW50aWNh dGUgdGhlIGNsaWVudC4KICAgICAgICAgIAo8L3A+CjxhIG5hbWU9ImFuY2hvcjMwIj48L2E+PGJy IC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3Bh Y2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0Ni dWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4K PGEgbmFtZT0icmZjLnNlY3Rpb24uNC40LjMiPjwvYT48aDM+NC40LjMuJm5ic3A7CkFjY2VzcyBU b2tlbiBSZXNwb25zZTwvaDM+Cgo8cD4KICAgICAgICAgICAgSWYgdGhlIGFjY2VzcyB0b2tlbiBy ZXF1ZXN0IGlzIHZhbGlkIGFuZCBhdXRob3JpemVkLCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIg aXNzdWVzIGFuCiAgICAgICAgICAgIGFjY2VzcyB0b2tlbiBhcyBkZXNjcmliZWQgaW4gPGEgY2xh c3M9J2luZm8nIGhyZWY9JyN0b2tlbi1yZXNwb25zZSc+U2VjdGlvbiZuYnNwOzUuMTxzcGFuPiAo PC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5TdWNjZXNzZnVsIFJlc3BvbnNlPC9zcGFuPjxzcGFu Pik8L3NwYW4+PC9hPi4gQSByZWZyZXNoIHRva2VuIFNIT1VMRAogICAgICAgICAgICBOT1QgYmUg aW5jbHVkZWQuIElmIHRoZSByZXF1ZXN0IGZhaWxlZCBjbGllbnQgYXV0aGVudGljYXRpb24gb3Ig aXMgaW52YWxpZCwgdGhlCiAgICAgICAgICAgIGF1dGhvcml6YXRpb24gc2VydmVyIHJldHVybnMg YW4gZXJyb3IgcmVzcG9uc2UgYXMgZGVzY3JpYmVkIGluCiAgICAgICAgICAgIDxhIGNsYXNzPSdp bmZvJyBocmVmPScjdG9rZW4tZXJyb3JzJz5TZWN0aW9uJm5ic3A7NS4yPHNwYW4+ICg8L3NwYW4+ PHNwYW4gY2xhc3M9J2luZm8nPkVycm9yIFJlc3BvbnNlPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9h Pi4KICAgICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgICAgIEFuIGV4YW1wbGUgc3VjY2Vzc2Z1 bCByZXNwb25zZToKICAgICAgICAgICAgCjwvcD48ZGl2IHN0eWxlPSdkaXNwbGF5OiB0YWJsZTsg d2lkdGg6IDA7IG1hcmdpbi1sZWZ0OiAzZW07IG1hcmdpbi1yaWdodDogYXV0byc+PHByZT4KCiAg SFRUUC8xLjEgMjAwIE9LCiAgQ29udGVudC1UeXBlOiBhcHBsaWNhdGlvbi9qc29uO2NoYXJzZXQ9 VVRGLTgKICBDYWNoZS1Db250cm9sOiBuby1zdG9yZQogIFByYWdtYTogbm8tY2FjaGUKCiAgewog ICAgImFjY2Vzc190b2tlbiI6IjJZb3RuRlpGRWpyMXpDc2ljTVdwQUEiLAogICAgInRva2VuX3R5 cGUiOiJleGFtcGxlIiwKICAgICJleHBpcmVzX2luIjozNjAwLAogICAgImV4YW1wbGVfcGFyYW1l dGVyIjoiZXhhbXBsZV92YWx1ZSIKICB9Cgo8L3ByZT48L2Rpdj4KPGEgbmFtZT0iZXh0LWdyYW50 Ij48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIw IiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNs YXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+ PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uNC41Ij48L2E+PGgzPjQuNS4mbmJzcDsKRXh0 ZW5zaW9uIEdyYW50czwvaDM+Cgo8cD4KICAgICAgICAgIFRoZSBjbGllbnQgdXNlcyBhbiBleHRl bnNpb24gZ3JhbnQgdHlwZSBieSBzcGVjaWZ5aW5nIHRoZSBncmFudCB0eXBlIHVzaW5nIGFuCiAg ICAgICAgICBhYnNvbHV0ZSBVUkkgKGRlZmluZWQgYnkgdGhlIGF1dGhvcml6YXRpb24gc2VydmVy KSBhcyB0aGUgdmFsdWUgb2YgdGhlCiAgICAgICAgICA8dHQ+Z3JhbnRfdHlwZTwvdHQ+IHBhcmFt ZXRlciBvZiB0aGUgdG9rZW4gZW5kcG9pbnQsIGFuZCBieQogICAgICAgICAgYWRkaW5nIGFueSBh ZGRpdGlvbmFsIHBhcmFtZXRlcnMgbmVjZXNzYXJ5LgogICAgICAgIAo8L3A+CjxwPgogICAgICAg ICAgICBGb3IgZXhhbXBsZSwgdG8gcmVxdWVzdCBhbiBhY2Nlc3MgdG9rZW4gdXNpbmcgYSBTQU1M IDIuMCBhc3NlcnRpb24gZ3JhbnQgdHlwZSBhcwogICAgICAgICAgICBkZWZpbmVkIGJ5IDxhIGNs YXNzPSdpbmZvJyBocmVmPScjSS1ELmlldGYtb2F1dGgtc2FtbDItYmVhcmVyJz5bSSYjODIwOTtE LmlldGYmIzgyMDk7b2F1dGgmIzgyMDk7c2FtbDImIzgyMDk7YmVhcmVyXTxzcGFuPiAoPC9zcGFu PjxzcGFuIGNsYXNzPSdpbmZvJz5Nb3J0aW1vcmUsIEMuLCAmbGRxdW87U0FNTCAyLjAgQmVhcmVy IEFzc2VydGlvbiBQcm9maWxlcyBmb3IgT0F1dGggMi4wLCZyZHF1bzsgTWF5Jm5ic3A7MjAxMi48 L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+LCB0aGUgY2xpZW50IG1ha2VzIHRoZQogICAgICAgICAg ICBmb2xsb3dpbmcgSFRUUCByZXF1ZXN0IHVzaW5nIFRMUyAobGluZSBicmVha3MgYXJlIGZvciBk aXNwbGF5IHB1cnBvc2VzIG9ubHkpOgogICAgICAgICAgCjwvcD48ZGl2IHN0eWxlPSdkaXNwbGF5 OiB0YWJsZTsgd2lkdGg6IDA7IG1hcmdpbi1sZWZ0OiAzZW07IG1hcmdpbi1yaWdodDogYXV0byc+ PHByZT4KCiAgUE9TVCAvdG9rZW4gSFRUUC8xLjEKICBIb3N0OiBzZXJ2ZXIuZXhhbXBsZS5jb20K ICBDb250ZW50LVR5cGU6IGFwcGxpY2F0aW9uL3gtd3d3LWZvcm0tdXJsZW5jb2RlZDtjaGFyc2V0 PVVURi04CgogIGdyYW50X3R5cGU9dXJuJTNBaWV0ZiUzQXBhcmFtcyUzQW9hdXRoJTNBZ3JhbnQt dHlwZSUzQXNhbWwyLQogIGJlYXJlciZhbXA7YXNzZXJ0aW9uPVBFRnpjMlZ5ZEdsdmJpQkpjM04x WlVsdWMzUmhiblE5SWpJd01URXRNRFUKICBbLi4ub21pdHRlZCBmb3IgYnJldml0eS4uLl1hRzVU ZEdGMFpXMWxiblEtUEM5QmMzTmxjblJwYjI0LQoKPC9wcmU+PC9kaXY+CjxwPgogICAgICAgICAg SWYgdGhlIGFjY2VzcyB0b2tlbiByZXF1ZXN0IGlzIHZhbGlkIGFuZCBhdXRob3JpemVkLCB0aGUg YXV0aG9yaXphdGlvbiBzZXJ2ZXIgaXNzdWVzIGFuCiAgICAgICAgICBhY2Nlc3MgdG9rZW4gYW5k IG9wdGlvbmFsIHJlZnJlc2ggdG9rZW4gYXMgZGVzY3JpYmVkIGluIDxhIGNsYXNzPSdpbmZvJyBo cmVmPScjdG9rZW4tcmVzcG9uc2UnPlNlY3Rpb24mbmJzcDs1LjE8c3Bhbj4gKDwvc3Bhbj48c3Bh biBjbGFzcz0naW5mbyc+U3VjY2Vzc2Z1bCBSZXNwb25zZTwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwv YT4uCiAgICAgICAgICBJZiB0aGUgcmVxdWVzdCBmYWlsZWQgY2xpZW50IGF1dGhlbnRpY2F0aW9u IG9yIGlzIGludmFsaWQsIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciByZXR1cm5zCiAgICAgICAg ICBhbiBlcnJvciByZXNwb25zZSBhcyBkZXNjcmliZWQgaW4gPGEgY2xhc3M9J2luZm8nIGhyZWY9 JyN0b2tlbi1lcnJvcnMnPlNlY3Rpb24mbmJzcDs1LjI8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFz cz0naW5mbyc+RXJyb3IgUmVzcG9uc2U8L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+LgogICAgICAg IAo8L3A+CjxhIG5hbWU9InRva2VuLWlzc3VlIj48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1t YXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1 ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZu YnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24u NSI+PC9hPjxoMz41LiZuYnNwOwpJc3N1aW5nIGFuIEFjY2VzcyBUb2tlbjwvaDM+Cgo8cD4KICAg ICAgICBJZiB0aGUgYWNjZXNzIHRva2VuIHJlcXVlc3QgaXMgdmFsaWQgYW5kIGF1dGhvcml6ZWQs IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBpc3N1ZXMgYW4KICAgICAgICBhY2Nlc3MgdG9rZW4g YW5kIG9wdGlvbmFsIHJlZnJlc2ggdG9rZW4gYXMgZGVzY3JpYmVkIGluIDxhIGNsYXNzPSdpbmZv JyBocmVmPScjdG9rZW4tcmVzcG9uc2UnPlNlY3Rpb24mbmJzcDs1LjE8c3Bhbj4gKDwvc3Bhbj48 c3BhbiBjbGFzcz0naW5mbyc+U3VjY2Vzc2Z1bCBSZXNwb25zZTwvc3Bhbj48c3Bhbj4pPC9zcGFu PjwvYT4uCiAgICAgICAgSWYgdGhlIHJlcXVlc3QgZmFpbGVkIGNsaWVudCBhdXRoZW50aWNhdGlv biBvciBpcyBpbnZhbGlkLCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgcmV0dXJucwogICAgICAg IGFuIGVycm9yIHJlc3BvbnNlIGFzIGRlc2NyaWJlZCBpbiA8YSBjbGFzcz0naW5mbycgaHJlZj0n I3Rva2VuLWVycm9ycyc+U2VjdGlvbiZuYnNwOzUuMjxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNz PSdpbmZvJz5FcnJvciBSZXNwb25zZTwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4uCiAgICAgIAo8 L3A+CjxhIG5hbWU9InRva2VuLXJlc3BvbnNlIj48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1t YXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1 ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZu YnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24u NS4xIj48L2E+PGgzPjUuMS4mbmJzcDsKU3VjY2Vzc2Z1bCBSZXNwb25zZTwvaDM+Cgo8cD4KICAg ICAgICAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBpc3N1ZXMgYW4gYWNjZXNzIHRva2VuIGFu ZCBvcHRpb25hbCByZWZyZXNoIHRva2VuLCBhbmQKICAgICAgICAgIGNvbnN0cnVjdHMgdGhlIHJl c3BvbnNlIGJ5IGFkZGluZyB0aGUgZm9sbG93aW5nIHBhcmFtZXRlcnMgdG8gdGhlIGVudGl0eSBi b2R5IG9mIHRoZSBIVFRQCiAgICAgICAgICByZXNwb25zZSB3aXRoIGEgMjAwIChPSykgc3RhdHVz IGNvZGU6CiAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICA8L3A+CjxibG9ja3F1b3RlIGNsYXNz PSJ0ZXh0Ij48ZGw+CjxkdD5hY2Nlc3NfdG9rZW48L2R0Pgo8ZGQ+CiAgICAgICAgICAgICAgCiAg ICAgICAgICAgICAgUkVRVUlSRUQuIFRoZSBhY2Nlc3MgdG9rZW4gaXNzdWVkIGJ5IHRoZSBhdXRo b3JpemF0aW9uIHNlcnZlci4KICAgICAgICAgICAgCjwvZGQ+CjxkdD50b2tlbl90eXBlPC9kdD4K PGRkPgogICAgICAgICAgICAgIAogICAgICAgICAgICAgIFJFUVVJUkVELiBUaGUgdHlwZSBvZiB0 aGUgdG9rZW4gaXNzdWVkIGFzIGRlc2NyaWJlZCBpbiA8YSBjbGFzcz0naW5mbycgaHJlZj0nI3Rv a2VuLXR5cGVzJz5TZWN0aW9uJm5ic3A7Ny4xPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2lu Zm8nPkFjY2VzcyBUb2tlbiBUeXBlczwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4uCiAgICAgICAg ICAgICAgVmFsdWUgaXMgY2FzZSBpbnNlbnNpdGl2ZS4KICAgICAgICAgICAgCjwvZGQ+CjxkdD5l eHBpcmVzX2luPC9kdD4KPGRkPgogICAgICAgICAgICAgIAogICAgICAgICAgICAgIFJFQ09NTUVO REVELiBUaGUgbGlmZXRpbWUgaW4gc2Vjb25kcyBvZiB0aGUgYWNjZXNzIHRva2VuLiBGb3IgZXhh bXBsZSwgdGhlIHZhbHVlCiAgICAgICAgICAgICAgPHR0PjM2MDA8L3R0PiBkZW5vdGVzIHRoYXQg dGhlIGFjY2VzcyB0b2tlbiB3aWxsIGV4cGlyZSBpbiBvbmUKICAgICAgICAgICAgICBob3VyIGZy b20gdGhlIHRpbWUgdGhlIHJlc3BvbnNlIHdhcyBnZW5lcmF0ZWQuIElmIG9taXR0ZWQsIHRoZSBh dXRob3JpemF0aW9uIHNlcnZlcgogICAgICAgICAgICAgIFNIT1VMRCBwcm92aWRlIHRoZSBleHBp cmF0aW9uIHRpbWUgdmlhIG90aGVyIG1lYW5zIG9yIGRvY3VtZW50IHRoZSBkZWZhdWx0IHZhbHVl LgogICAgICAgICAgICAKPC9kZD4KPGR0PnJlZnJlc2hfdG9rZW48L2R0Pgo8ZGQ+CiAgICAgICAg ICAgICAgCiAgICAgICAgICAgICAgT1BUSU9OQUwuIFRoZSByZWZyZXNoIHRva2VuIHdoaWNoIGNh biBiZSB1c2VkIHRvIG9idGFpbiBuZXcgYWNjZXNzIHRva2VucyB1c2luZyB0aGUKICAgICAgICAg ICAgICBzYW1lIGF1dGhvcml6YXRpb24gZ3JhbnQgYXMgZGVzY3JpYmVkIGluIDxhIGNsYXNzPSdp bmZvJyBocmVmPScjdG9rZW4tcmVmcmVzaCc+U2VjdGlvbiZuYnNwOzY8c3Bhbj4gKDwvc3Bhbj48 c3BhbiBjbGFzcz0naW5mbyc+UmVmcmVzaGluZyBhbiBBY2Nlc3MgVG9rZW48L3NwYW4+PHNwYW4+ KTwvc3Bhbj48L2E+LgogICAgICAgICAgICAKPC9kZD4KPGR0PnNjb3BlPC9kdD4KPGRkPgogICAg ICAgICAgICAgIAogICAgICAgICAgICAgIE9QVElPTkFMLCBpZiBpZGVudGljYWwgdG8gdGhlIHNj b3BlIHJlcXVlc3RlZCBieSB0aGUgY2xpZW50LCBvdGhlcndpc2UgUkVRVUlSRUQuIFRoZQogICAg ICAgICAgICAgIHNjb3BlIG9mIHRoZSBhY2Nlc3MgdG9rZW4gYXMgZGVzY3JpYmVkIGJ5IDxhIGNs YXNzPSdpbmZvJyBocmVmPScjc2NvcGUnPlNlY3Rpb24mbmJzcDszLjM8c3Bhbj4gKDwvc3Bhbj48 c3BhbiBjbGFzcz0naW5mbyc+QWNjZXNzIFRva2VuIFNjb3BlPC9zcGFuPjxzcGFuPik8L3NwYW4+ PC9hPi4KICAgICAgICAgICAgCjwvZGQ+CjwvZGw+PC9ibG9ja3F1b3RlPjxwPgogICAgICAgIAo8 L3A+CjxwPgogICAgICAgICAgVGhlIHBhcmFtZXRlcnMgYXJlIGluY2x1ZGVkIGluIHRoZSBlbnRp dHkgYm9keSBvZiB0aGUgSFRUUCByZXNwb25zZSB1c2luZyB0aGUKICAgICAgICAgIDx0dD5hcHBs aWNhdGlvbi9qc29uPC90dD4gbWVkaWEgdHlwZSBhcyBkZWZpbmVkIGJ5CiAgICAgICAgICA8YSBj bGFzcz0naW5mbycgaHJlZj0nI1JGQzQ2MjcnPltSRkM0NjI3XTxzcGFuPiAoPC9zcGFuPjxzcGFu IGNsYXNzPSdpbmZvJz5Dcm9ja2ZvcmQsIEQuLCAmbGRxdW87VGhlIGFwcGxpY2F0aW9uL2pzb24g TWVkaWEgVHlwZSBmb3IgSmF2YVNjcmlwdCBPYmplY3QgTm90YXRpb24gKEpTT04pLCZyZHF1bzsg SnVseSZuYnNwOzIwMDYuPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPi4gVGhlIHBhcmFtZXRlcnMg YXJlIHNlcmlhbGl6ZWQgaW50byBhIEpTT04gc3RydWN0dXJlIGJ5CiAgICAgICAgICBhZGRpbmcg ZWFjaCBwYXJhbWV0ZXIgYXQgdGhlIGhpZ2hlc3Qgc3RydWN0dXJlIGxldmVsLiBQYXJhbWV0ZXIg bmFtZXMgYW5kIHN0cmluZyB2YWx1ZXMKICAgICAgICAgIGFyZSBpbmNsdWRlZCBhcyBKU09OIHN0 cmluZ3MuIE51bWVyaWNhbCB2YWx1ZXMgYXJlIGluY2x1ZGVkIGFzIEpTT04gbnVtYmVycy4gVGhl IG9yZGVyIG9mCiAgICAgICAgICBwYXJhbWV0ZXJzIGRvZXMgbm90IG1hdHRlciBhbmQgY2FuIHZh cnkuCiAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIg TVVTVCBpbmNsdWRlIHRoZSBIVFRQCiAgICAgICAgICA8dHQ+Q2FjaGUtQ29udHJvbDwvdHQ+IHJl c3BvbnNlIGhlYWRlciBmaWVsZCA8YSBjbGFzcz0naW5mbycgaHJlZj0nI1JGQzI2MTYnPltSRkMy NjE2XTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5GaWVsZGluZywgUi4sIEdldHR5 cywgSi4sIE1vZ3VsLCBKLiwgRnJ5c3R5aywgSC4sIE1hc2ludGVyLCBMLiwgTGVhY2gsIFAuLCBh bmQgVC4gQmVybmVycy1MZWUsICZsZHF1bztIeXBlcnRleHQgVHJhbnNmZXIgUHJvdG9jb2wgLS0g SFRUUC8xLjEsJnJkcXVvOyBKdW5lJm5ic3A7MTk5OS48L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+ CiAgICAgICAgICB3aXRoIGEgdmFsdWUgb2YgPHR0Pm5vLXN0b3JlPC90dD4gaW4gYW55IHJlc3Bv bnNlIGNvbnRhaW5pbmcgdG9rZW5zLAogICAgICAgICAgY3JlZGVudGlhbHMsIG9yIG90aGVyIHNl bnNpdGl2ZSBpbmZvcm1hdGlvbiwgYXMgd2VsbCBhcyB0aGUKICAgICAgICAgIDx0dD5QcmFnbWE8 L3R0PiByZXNwb25zZSBoZWFkZXIgZmllbGQgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNSRkMyNjE2 Jz5bUkZDMjYxNl08c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+RmllbGRpbmcsIFIu LCBHZXR0eXMsIEouLCBNb2d1bCwgSi4sIEZyeXN0eWssIEguLCBNYXNpbnRlciwgTC4sIExlYWNo LCBQLiwgYW5kIFQuIEJlcm5lcnMtTGVlLCAmbGRxdW87SHlwZXJ0ZXh0IFRyYW5zZmVyIFByb3Rv Y29sIC0tIEhUVFAvMS4xLCZyZHF1bzsgSnVuZSZuYnNwOzE5OTkuPC9zcGFuPjxzcGFuPik8L3Nw YW4+PC9hPiB3aXRoIGEKICAgICAgICAgIHZhbHVlIG9mIDx0dD5uby1jYWNoZTwvdHQ+LgogICAg ICAgIAo8L3A+CjxwPgogICAgICAgICAgICBGb3IgZXhhbXBsZToKICAgICAgICAgIAo8L3A+PGRp diBzdHlsZT0nZGlzcGxheTogdGFibGU7IHdpZHRoOiAwOyBtYXJnaW4tbGVmdDogM2VtOyBtYXJn aW4tcmlnaHQ6IGF1dG8nPjxwcmU+CgogIEhUVFAvMS4xIDIwMCBPSwogIENvbnRlbnQtVHlwZTog YXBwbGljYXRpb24vanNvbjtjaGFyc2V0PVVURi04CiAgQ2FjaGUtQ29udHJvbDogbm8tc3RvcmUK ICBQcmFnbWE6IG5vLWNhY2hlCgogIHsKICAgICJhY2Nlc3NfdG9rZW4iOiIyWW90bkZaRkVqcjF6 Q3NpY01XcEFBIiwKICAgICJ0b2tlbl90eXBlIjoiZXhhbXBsZSIsCiAgICAiZXhwaXJlc19pbiI6 MzYwMCwKICAgICJyZWZyZXNoX3Rva2VuIjoidEd6djNKT2tGMFhHNVF4MlRsS1dJQSIsCiAgICAi ZXhhbXBsZV9wYXJhbWV0ZXIiOiJleGFtcGxlX3ZhbHVlIgogIH0KCjwvcHJlPjwvZGl2Pgo8cD4K ICAgICAgICAgIFRoZSBjbGllbnQgTVVTVCBpZ25vcmUgdW5yZWNvZ25pemVkIHZhbHVlIG5hbWVz IGluIHRoZSByZXNwb25zZS4gVGhlIHNpemVzIG9mIHRva2VucyBhbmQKICAgICAgICAgIG90aGVy IHZhbHVlcyByZWNlaXZlZCBmcm9tIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBhcmUgbGVmdCB1 bmRlZmluZWQuIFRoZSBjbGllbnQgc2hvdWxkCiAgICAgICAgICBhdm9pZCBtYWtpbmcgYXNzdW1w dGlvbnMgYWJvdXQgdmFsdWUgc2l6ZXMuIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBTSE9VTEQg ZG9jdW1lbnQgdGhlCiAgICAgICAgICBzaXplIG9mIGFueSB2YWx1ZSBpdCBpc3N1ZXMuCiAgICAg ICAgCjwvcD4KPGEgbmFtZT0idG9rZW4tZXJyb3JzIj48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBz dW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRP Q2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2Mi PiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rp b24uNS4yIj48L2E+PGgzPjUuMi4mbmJzcDsKRXJyb3IgUmVzcG9uc2U8L2gzPgoKPHA+CiAgICAg ICAgICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgcmVzcG9uZHMgd2l0aCBhbiBIVFRQIDQwMCAo QmFkIFJlcXVlc3QpIHN0YXR1cyBjb2RlICh1bmxlc3MKICAgICAgICAgIHNwZWNpZmllZCBvdGhl cndpc2UpIGFuZCBpbmNsdWRlcyB0aGUgZm9sbG93aW5nIHBhcmFtZXRlcnMgd2l0aCB0aGUgcmVz cG9uc2U6CiAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICA8L3A+CjxibG9ja3F1b3RlIGNsYXNz PSJ0ZXh0Ij48ZGw+CjxkdD5lcnJvcjwvZHQ+CjxkZD4KICAgICAgICAgICAgICAKICAgICAgICAg ICAgICBSRVFVSVJFRC4gQSBzaW5nbGUgQVNDSUkgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNVU0FT Q0lJJz5bVVNBU0NJSV08c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+QW1lcmljYW4g TmF0aW9uYWwgU3RhbmRhcmRzIEluc3RpdHV0ZSwgJmxkcXVvO0NvZGVkIENoYXJhY3RlciBTZXQg LS0gNy1iaXQgQW1lcmljYW4gU3RhbmRhcmQgQ29kZSBmb3IgSW5mb3JtYXRpb24gSW50ZXJjaGFu Z2UsJnJkcXVvOyAxOTg2Ljwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4gZXJyb3IgY29kZSBmcm9t IHRoZSBmb2xsb3dpbmc6CgogICAgICAgICAgICAgIAo8YmxvY2txdW90ZSBjbGFzcz0idGV4dCI+ PGRsPgo8ZHQ+aW52YWxpZF9yZXF1ZXN0PC9kdD4KPGRkPgogICAgICAgICAgICAgICAgICAKICAg ICAgICAgICAgICAgICAgVGhlIHJlcXVlc3QgaXMgbWlzc2luZyBhIHJlcXVpcmVkIHBhcmFtZXRl ciwgaW5jbHVkZXMgYW4gdW5zdXBwb3J0ZWQKICAgICAgICAgICAgICAgICAgcGFyYW1ldGVyIHZh bHVlIChvdGhlciB0aGFuIGdyYW50IHR5cGUpLCByZXBlYXRzIGEgcGFyYW1ldGVyLCBpbmNsdWRl cyBtdWx0aXBsZQogICAgICAgICAgICAgICAgICBjcmVkZW50aWFscywgdXRpbGl6ZXMgbW9yZSB0 aGFuIG9uZSBtZWNoYW5pc20gZm9yIGF1dGhlbnRpY2F0aW5nIHRoZSBjbGllbnQsCiAgICAgICAg ICAgICAgICAgIG9yIGlzIG90aGVyd2lzZSBtYWxmb3JtZWQuCiAgICAgICAgICAgICAgICAKPC9k ZD4KPGR0PmludmFsaWRfY2xpZW50PC9kdD4KPGRkPgogICAgICAgICAgICAgICAgICAKICAgICAg ICAgICAgICAgICAgQ2xpZW50IGF1dGhlbnRpY2F0aW9uIGZhaWxlZCAoZS5nLiB1bmtub3duIGNs aWVudCwgbm8gY2xpZW50IGF1dGhlbnRpY2F0aW9uCiAgICAgICAgICAgICAgICAgIGluY2x1ZGVk LCBvciB1bnN1cHBvcnRlZCBhdXRoZW50aWNhdGlvbiBtZXRob2QpLiBUaGUgYXV0aG9yaXphdGlv biBzZXJ2ZXIgTUFZCiAgICAgICAgICAgICAgICAgIHJldHVybiBhbiBIVFRQIDQwMSAoVW5hdXRo b3JpemVkKSBzdGF0dXMgY29kZSB0byBpbmRpY2F0ZSB3aGljaCBIVFRQCiAgICAgICAgICAgICAg ICAgIGF1dGhlbnRpY2F0aW9uIHNjaGVtZXMgYXJlIHN1cHBvcnRlZC4gSWYgdGhlIGNsaWVudCBh dHRlbXB0ZWQgdG8gYXV0aGVudGljYXRlIHZpYQogICAgICAgICAgICAgICAgICB0aGUgPHR0PkF1 dGhvcml6YXRpb248L3R0PiByZXF1ZXN0IGhlYWRlciBmaWVsZCwKICAgICAgICAgICAgICAgICAg dGhlIGF1dGhvcml6YXRpb24gc2VydmVyIE1VU1QgcmVzcG9uZCB3aXRoIGFuIEhUVFAgNDAxIChV bmF1dGhvcml6ZWQpIHN0YXR1cwogICAgICAgICAgICAgICAgICBjb2RlLCBhbmQgaW5jbHVkZSB0 aGUgPHR0PldXVy1BdXRoZW50aWNhdGU8L3R0PiByZXNwb25zZQogICAgICAgICAgICAgICAgICBo ZWFkZXIgZmllbGQgbWF0Y2hpbmcgdGhlIGF1dGhlbnRpY2F0aW9uIHNjaGVtZSB1c2VkIGJ5IHRo ZSBjbGllbnQuCiAgICAgICAgICAgICAgICAKPC9kZD4KPGR0PmludmFsaWRfZ3JhbnQ8L2R0Pgo8 ZGQ+CiAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICBUaGUgcHJvdmlkZWQgYXV0 aG9yaXphdGlvbiBncmFudCAoZS5nLiBhdXRob3JpemF0aW9uIGNvZGUsIHJlc291cmNlIG93bmVy CiAgICAgICAgICAgICAgICAgIGNyZWRlbnRpYWxzKSBvciByZWZyZXNoIHRva2VuIGlzIGludmFs aWQsIGV4cGlyZWQsIHJldm9rZWQsIGRvZXMgbm90IG1hdGNoIHRoZQogICAgICAgICAgICAgICAg ICByZWRpcmVjdGlvbiBVUkkgdXNlZCBpbiB0aGUgYXV0aG9yaXphdGlvbiByZXF1ZXN0LCBvciB3 YXMgaXNzdWVkIHRvIGFub3RoZXIKICAgICAgICAgICAgICAgICAgY2xpZW50LgogICAgICAgICAg ICAgICAgCjwvZGQ+CjxkdD51bmF1dGhvcml6ZWRfY2xpZW50PC9kdD4KPGRkPgogICAgICAgICAg ICAgICAgICAKICAgICAgICAgICAgICAgICAgVGhlIGF1dGhlbnRpY2F0ZWQgY2xpZW50IGlzIG5v dCBhdXRob3JpemVkIHRvIHVzZSB0aGlzIGF1dGhvcml6YXRpb24gZ3JhbnQgdHlwZS4KICAgICAg ICAgICAgICAgIAo8L2RkPgo8ZHQ+dW5zdXBwb3J0ZWRfZ3JhbnRfdHlwZTwvZHQ+CjxkZD4KICAg ICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgIFRoZSBhdXRob3JpemF0aW9uIGdyYW50 IHR5cGUgaXMgbm90IHN1cHBvcnRlZCBieSB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIuCiAgICAg ICAgICAgICAgICAKPC9kZD4KPGR0PmludmFsaWRfc2NvcGU8L2R0Pgo8ZGQ+CiAgICAgICAgICAg ICAgICAgIAogICAgICAgICAgICAgICAgICBUaGUgcmVxdWVzdGVkIHNjb3BlIGlzIGludmFsaWQs IHVua25vd24sIG1hbGZvcm1lZCwgb3IgZXhjZWVkcyB0aGUgc2NvcGUgZ3JhbnRlZAogICAgICAg ICAgICAgICAgICBieSB0aGUgcmVzb3VyY2Ugb3duZXIuCiAgICAgICAgICAgICAgICAKPC9kZD4K PC9kbD48L2Jsb2NrcXVvdGU+CgoJICAgICAgVmFsdWVzIGZvciB0aGUgPHR0PmVycm9yPC90dD4g cGFyYW1ldGVyIE1VU1QgTk9UIGluY2x1ZGUKCSAgICAgIGNoYXJhY3RlcnMgb3V0c2lkZSB0aGUg c2V0ICV4MjAtMjEgLyAleDIzLTVCIC8gJXg1RC03RS4KICAgICAgICAgICAgCjwvZGQ+CjxkdD5l cnJvcl9kZXNjcmlwdGlvbjwvZHQ+CjxkZD4KICAgICAgICAgICAgICAKICAgICAgICAgICAgICBP UFRJT05BTC4gQSBodW1hbi1yZWFkYWJsZSBBU0NJSSA8YSBjbGFzcz0naW5mbycgaHJlZj0nI1VT QVNDSUknPltVU0FTQ0lJXTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5BbWVyaWNh biBOYXRpb25hbCBTdGFuZGFyZHMgSW5zdGl0dXRlLCAmbGRxdW87Q29kZWQgQ2hhcmFjdGVyIFNl dCAtLSA3LWJpdCBBbWVyaWNhbiBTdGFuZGFyZCBDb2RlIGZvciBJbmZvcm1hdGlvbiBJbnRlcmNo YW5nZSwmcmRxdW87IDE5ODYuPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPiB0ZXh0IHByb3ZpZGlu ZyBhZGRpdGlvbmFsIGluZm9ybWF0aW9uLAogICAgICAgICAgICAgIHVzZWQgdG8gYXNzaXN0IHRo ZSBjbGllbnQgZGV2ZWxvcGVyIGluIHVuZGVyc3RhbmRpbmcgdGhlIGVycm9yIHRoYXQgb2NjdXJy ZWQuCgkgICAgICA8YnIgLz4KCgkgICAgICBWYWx1ZXMgZm9yIHRoZSA8dHQ+ZXJyb3JfZGVzY3Jp cHRpb248L3R0PiBwYXJhbWV0ZXIgTVVTVCBOT1QgaW5jbHVkZQoJICAgICAgY2hhcmFjdGVycyBv dXRzaWRlIHRoZSBzZXQgJXgyMC0yMSAvICV4MjMtNUIgLyAleDVELTdFLgogICAgICAgICAgICAK PC9kZD4KPGR0PmVycm9yX3VyaTwvZHQ+CjxkZD4KICAgICAgICAgICAgICAKICAgICAgICAgICAg ICBPUFRJT05BTC4gQSBVUkkgaWRlbnRpZnlpbmcgYSBodW1hbi1yZWFkYWJsZSB3ZWIgcGFnZSB3 aXRoIGluZm9ybWF0aW9uIGFib3V0IHRoZQogICAgICAgICAgICAgIGVycm9yLCB1c2VkIHRvIHBy b3ZpZGUgdGhlIGNsaWVudCBkZXZlbG9wZXIgd2l0aCBhZGRpdGlvbmFsIGluZm9ybWF0aW9uIGFi b3V0IHRoZQogICAgICAgICAgICAgIGVycm9yLgoJICAgICAgPGJyIC8+CgoJICAgICAgVmFsdWVz IGZvciB0aGUgPHR0PmVycm9yX3VyaTwvdHQ+IHBhcmFtZXRlcgoJICAgICAgTVVTVCBjb25mb3Jt IHRvIHRoZSBVUkktUmVmZXJlbmNlIHN5bnRheCwgYW5kIHRodXMgTVVTVCBOT1QgaW5jbHVkZQoJ ICAgICAgY2hhcmFjdGVycyBvdXRzaWRlIHRoZSBzZXQgJXgyMSAvICV4MjMtNUIgLyAleDVELTdF LgogICAgICAgICAgICAKPC9kZD4KPC9kbD48L2Jsb2NrcXVvdGU+PHA+CiAgICAgICAgCjwvcD4K PHA+CiAgICAgICAgICBUaGUgcGFyYW1ldGVycyBhcmUgaW5jbHVkZWQgaW4gdGhlIGVudGl0eSBi b2R5IG9mIHRoZSBIVFRQIHJlc3BvbnNlIHVzaW5nIHRoZQogICAgICAgICAgPHR0PmFwcGxpY2F0 aW9uL2pzb248L3R0PiBtZWRpYSB0eXBlIGFzIGRlZmluZWQgYnkKICAgICAgICAgIDxhIGNsYXNz PSdpbmZvJyBocmVmPScjUkZDNDYyNyc+W1JGQzQ2MjddPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xh c3M9J2luZm8nPkNyb2NrZm9yZCwgRC4sICZsZHF1bztUaGUgYXBwbGljYXRpb24vanNvbiBNZWRp YSBUeXBlIGZvciBKYXZhU2NyaXB0IE9iamVjdCBOb3RhdGlvbiAoSlNPTiksJnJkcXVvOyBKdWx5 Jm5ic3A7MjAwNi48L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+LiBUaGUgcGFyYW1ldGVycyBhcmUg c2VyaWFsaXplZCBpbnRvIGEgSlNPTiBzdHJ1Y3R1cmUgYnkKICAgICAgICAgIGFkZGluZyBlYWNo IHBhcmFtZXRlciBhdCB0aGUgaGlnaGVzdCBzdHJ1Y3R1cmUgbGV2ZWwuIFBhcmFtZXRlciBuYW1l cyBhbmQgc3RyaW5nIHZhbHVlcwogICAgICAgICAgYXJlIGluY2x1ZGVkIGFzIEpTT04gc3RyaW5n cy4gTnVtZXJpY2FsIHZhbHVlcyBhcmUgaW5jbHVkZWQgYXMgSlNPTiBudW1iZXJzLiBUaGUgb3Jk ZXIgb2YKICAgICAgICAgIHBhcmFtZXRlcnMgZG9lcyBub3QgbWF0dGVyIGFuZCBjYW4gdmFyeS4K ICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgICAgRm9yIGV4YW1wbGU6CiAgICAgICAgICAKPC9w PjxkaXYgc3R5bGU9J2Rpc3BsYXk6IHRhYmxlOyB3aWR0aDogMDsgbWFyZ2luLWxlZnQ6IDNlbTsg bWFyZ2luLXJpZ2h0OiBhdXRvJz48cHJlPgoKICBIVFRQLzEuMSA0MDAgQmFkIFJlcXVlc3QKICBD b250ZW50LVR5cGU6IGFwcGxpY2F0aW9uL2pzb247Y2hhcnNldD1VVEYtOAogIENhY2hlLUNvbnRy b2w6IG5vLXN0b3JlCiAgUHJhZ21hOiBuby1jYWNoZQoKICB7CiAgICAiZXJyb3IiOiJpbnZhbGlk X3JlcXVlc3QiCiAgfQoKPC9wcmU+PC9kaXY+CjxhIG5hbWU9InRva2VuLXJlZnJlc2giPjwvYT48 YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxz cGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRP Q2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxl Pgo8YSBuYW1lPSJyZmMuc2VjdGlvbi42Ij48L2E+PGgzPjYuJm5ic3A7ClJlZnJlc2hpbmcgYW4g QWNjZXNzIFRva2VuPC9oMz4KCjxwPgogICAgICAgIElmIHRoZSBhdXRob3JpemF0aW9uIHNlcnZl ciBpc3N1ZWQgYSByZWZyZXNoIHRva2VuIHRvIHRoZSBjbGllbnQsIHRoZSBjbGllbnQgbWFrZXMg YQogICAgICAgIHJlZnJlc2ggcmVxdWVzdCB0byB0aGUgdG9rZW4gZW5kcG9pbnQgYnkgYWRkaW5n IHRoZSBmb2xsb3dpbmcgcGFyYW1ldGVycyB1c2luZyB0aGUKICAgICAgICA8dHQ+YXBwbGljYXRp b24veC13d3ctZm9ybS11cmxlbmNvZGVkPC90dD4gZm9ybWF0IGluIHRoZSBIVFRQIHJlcXVlc3QK ICAgICAgICBlbnRpdHktYm9keToKICAgICAgCjwvcD4KPHA+CiAgICAgICAgPC9wPgo8YmxvY2tx dW90ZSBjbGFzcz0idGV4dCI+PGRsPgo8ZHQ+Z3JhbnRfdHlwZTwvZHQ+CjxkZD4KICAgICAgICAg ICAgCiAgICAgICAgICAgIFJFUVVJUkVELiBWYWx1ZSBNVVNUIGJlIHNldCB0byA8dHQ+cmVmcmVz aF90b2tlbjwvdHQ+LgogICAgICAgICAgCjwvZGQ+CjxkdD5yZWZyZXNoX3Rva2VuPC9kdD4KPGRk PgogICAgICAgICAgICAKICAgICAgICAgICAgUkVRVUlSRUQuIFRoZSByZWZyZXNoIHRva2VuIGlz c3VlZCB0byB0aGUgY2xpZW50LgogICAgICAgICAgCjwvZGQ+CjxkdD5zY29wZTwvZHQ+CjxkZD4K ICAgICAgICAgICAgCiAgICAgICAgICAgIE9QVElPTkFMLiBUaGUgc2NvcGUgb2YgdGhlIGFjY2Vz cyByZXF1ZXN0IGFzIGRlc2NyaWJlZCBieSA8YSBjbGFzcz0naW5mbycgaHJlZj0nI3Njb3BlJz5T ZWN0aW9uJm5ic3A7My4zPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkFjY2VzcyBU b2tlbiBTY29wZTwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4uCiAgICAgICAgICAgIFRoZSByZXF1 ZXN0ZWQgc2NvcGUgTVVTVCBOT1QgaW5jbHVkZSBhbnkgc2NvcGUgbm90IG9yaWdpbmFsbHkgZ3Jh bnRlZCBieSB0aGUgcmVzb3VyY2UKICAgICAgICAgICAgb3duZXIsIGFuZCBpZiBvbWl0dGVkIGlz IHRyZWF0ZWQgYXMgZXF1YWwgdG8gdGhlIHNjb3BlIG9yaWdpbmFsbHkgZ3JhbnRlZCBieSB0aGUK ICAgICAgICAgICAgcmVzb3VyY2Ugb3duZXIuCiAgICAgICAgICAKPC9kZD4KPC9kbD48L2Jsb2Nr cXVvdGU+PHA+CiAgICAgIAo8L3A+CjxwPgogICAgICAgIEJlY2F1c2UgcmVmcmVzaCB0b2tlbnMg YXJlIHR5cGljYWxseSBsb25nLWxhc3RpbmcgY3JlZGVudGlhbHMgdXNlZCB0byByZXF1ZXN0IGFk ZGl0aW9uYWwKICAgICAgICBhY2Nlc3MgdG9rZW5zLCB0aGUgcmVmcmVzaCB0b2tlbiBpcyBib3Vu ZCB0byB0aGUgY2xpZW50IHRvIHdoaWNoIGl0IHdhcyBpc3N1ZWQuIElmIHRoZSBjbGllbnQgdHlw ZQogICAgICAgIGlzIGNvbmZpZGVudGlhbCBvciB0aGUgY2xpZW50IHdhcyBpc3N1ZWQgY2xpZW50 IGNyZWRlbnRpYWxzIChvciBhc3NpZ25lZCBvdGhlcgogICAgICAgIGF1dGhlbnRpY2F0aW9uIHJl cXVpcmVtZW50cyksIHRoZSBjbGllbnQgTVVTVCBhdXRoZW50aWNhdGUgd2l0aCB0aGUgYXV0aG9y aXphdGlvbiBzZXJ2ZXIgYXMKICAgICAgICBkZXNjcmliZWQgaW4gPGEgY2xhc3M9J2luZm8nIGhy ZWY9JyN0b2tlbi1lbmRwb2ludC1hdXRoJz5TZWN0aW9uJm5ic3A7My4yLjE8c3Bhbj4gKDwvc3Bh bj48c3BhbiBjbGFzcz0naW5mbyc+Q2xpZW50IEF1dGhlbnRpY2F0aW9uPC9zcGFuPjxzcGFuPik8 L3NwYW4+PC9hPi4KICAgICAgCjwvcD4KPHA+CiAgICAgICAgICBGb3IgZXhhbXBsZSwgdGhlIGNs aWVudCBtYWtlcyB0aGUgZm9sbG93aW5nIEhUVFAgcmVxdWVzdCB1c2luZyB0cmFuc3BvcnQtbGF5 ZXIKICAgICAgICAgIHNlY3VyaXR5IChleHRyYSBsaW5lIGJyZWFrcyBhcmUgZm9yIGRpc3BsYXkg cHVycG9zZXMgb25seSk6CiAgICAgICAgCjwvcD48ZGl2IHN0eWxlPSdkaXNwbGF5OiB0YWJsZTsg d2lkdGg6IDA7IG1hcmdpbi1sZWZ0OiAzZW07IG1hcmdpbi1yaWdodDogYXV0byc+PHByZT4KCiAg UE9TVCAvdG9rZW4gSFRUUC8xLjEKICBIb3N0OiBzZXJ2ZXIuZXhhbXBsZS5jb20KICBBdXRob3Jp emF0aW9uOiBCYXNpYyBjelpDYUdSU2EzRjBNenBuV0RGbVFtRjBNMkpXCiAgQ29udGVudC1UeXBl OiBhcHBsaWNhdGlvbi94LXd3dy1mb3JtLXVybGVuY29kZWQ7Y2hhcnNldD1VVEYtOAoKICBncmFu dF90eXBlPXJlZnJlc2hfdG9rZW4mYW1wO3JlZnJlc2hfdG9rZW49dEd6djNKT2tGMFhHNVF4MlRs S1dJQQoKPC9wcmU+PC9kaXY+CjxwPgogICAgICAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBN VVNUOgogICAgICAKPC9wPgo8cD4KICAgICAgICA8L3A+Cjx1bCBjbGFzcz0idGV4dCI+CjxsaT4K ICAgICAgICAgICAgcmVxdWlyZSBjbGllbnQgYXV0aGVudGljYXRpb24gZm9yIGNvbmZpZGVudGlh bCBjbGllbnRzIG9yIGZvciBhbnkgY2xpZW50IHRoYXQgd2FzCiAgICAgICAgICAgIGlzc3VlZCBj bGllbnQgY3JlZGVudGlhbHMgKG9yIHdpdGggb3RoZXIgYXV0aGVudGljYXRpb24gcmVxdWlyZW1l bnRzKSwKICAgICAgICAgIAo8L2xpPgo8bGk+CiAgICAgICAgICAgIGF1dGhlbnRpY2F0ZSB0aGUg Y2xpZW50IGlmIGNsaWVudCBhdXRoZW50aWNhdGlvbiBpcyBpbmNsdWRlZCBhbmQgZW5zdXJlIHRo ZQogICAgICAgICAgICByZWZyZXNoIHRva2VuIHdhcyBpc3N1ZWQgdG8gdGhlIGF1dGhlbnRpY2F0 ZWQgY2xpZW50LCBhbmQKICAgICAgICAgIAo8L2xpPgo8bGk+CiAgICAgICAgICAgIHZhbGlkYXRl IHRoZSByZWZyZXNoIHRva2VuLgogICAgICAgICAgCjwvbGk+CjwvdWw+PHA+CiAgICAgIAo8L3A+ CjxwPgogICAgICAgIElmIHZhbGlkIGFuZCBhdXRob3JpemVkLCB0aGUgYXV0aG9yaXphdGlvbiBz ZXJ2ZXIgaXNzdWVzIGFuIGFjY2VzcyB0b2tlbiBhcyBkZXNjcmliZWQgaW4KICAgICAgICA8YSBj bGFzcz0naW5mbycgaHJlZj0nI3Rva2VuLXJlc3BvbnNlJz5TZWN0aW9uJm5ic3A7NS4xPHNwYW4+ ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPlN1Y2Nlc3NmdWwgUmVzcG9uc2U8L3NwYW4+PHNw YW4+KTwvc3Bhbj48L2E+LiBJZiB0aGUgcmVxdWVzdCBmYWlsZWQgdmVyaWZpY2F0aW9uIG9yIGlz IGludmFsaWQsIHRoZQogICAgICAgIGF1dGhvcml6YXRpb24gc2VydmVyIHJldHVybnMgYW4gZXJy b3IgcmVzcG9uc2UgYXMgZGVzY3JpYmVkIGluCiAgICAgICAgPGEgY2xhc3M9J2luZm8nIGhyZWY9 JyN0b2tlbi1lcnJvcnMnPlNlY3Rpb24mbmJzcDs1LjI8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFz cz0naW5mbyc+RXJyb3IgUmVzcG9uc2U8L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+LgogICAgICAK PC9wPgo8cD4KICAgICAgICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTUFZIGlzc3VlIGEgbmV3 IHJlZnJlc2ggdG9rZW4sIGluIHdoaWNoIGNhc2UgdGhlIGNsaWVudCBNVVNUCiAgICAgICAgZGlz Y2FyZCB0aGUgb2xkIHJlZnJlc2ggdG9rZW4gYW5kIHJlcGxhY2UgaXQgd2l0aCB0aGUgbmV3IHJl ZnJlc2ggdG9rZW4uIFRoZSBhdXRob3JpemF0aW9uCiAgICAgICAgc2VydmVyIE1BWSByZXZva2Ug dGhlIG9sZCByZWZyZXNoIHRva2VuIGFmdGVyIGlzc3VpbmcgYSBuZXcgcmVmcmVzaCB0b2tlbiB0 byB0aGUgY2xpZW50LiBJZgogICAgICAgIGEgbmV3IHJlZnJlc2ggdG9rZW4gaXMgaXNzdWVkLCB0 aGUgcmVmcmVzaCB0b2tlbiBzY29wZSBNVVNUIGJlIGlkZW50aWNhbCB0byB0aGF0IG9mIHRoZQog ICAgICAgIHJlZnJlc2ggdG9rZW4gaW5jbHVkZWQgYnkgdGhlIGNsaWVudCBpbiB0aGUgcmVxdWVz dC4KICAgICAgCjwvcD4KPGEgbmFtZT0iYWNjZXNzLXJlc291cmNlIj48L2E+PGJyIC8+PGhyIC8+ Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIg Y2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhy ZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0i cmZjLnNlY3Rpb24uNyI+PC9hPjxoMz43LiZuYnNwOwpBY2Nlc3NpbmcgUHJvdGVjdGVkIFJlc291 cmNlczwvaDM+Cgo8cD4KICAgICAgICBUaGUgY2xpZW50IGFjY2Vzc2VzIHByb3RlY3RlZCByZXNv dXJjZXMgYnkgcHJlc2VudGluZyB0aGUgYWNjZXNzIHRva2VuIHRvIHRoZSByZXNvdXJjZQogICAg ICAgIHNlcnZlci4gVGhlIHJlc291cmNlIHNlcnZlciBNVVNUIHZhbGlkYXRlIHRoZSBhY2Nlc3Mg dG9rZW4gYW5kIGVuc3VyZSBpdCBoYXMgbm90IGV4cGlyZWQKICAgICAgICBhbmQgdGhhdCBpdHMg c2NvcGUgY292ZXJzIHRoZSByZXF1ZXN0ZWQgcmVzb3VyY2UuIFRoZSBtZXRob2RzIHVzZWQgYnkg dGhlIHJlc291cmNlIHNlcnZlcgogICAgICAgIHRvIHZhbGlkYXRlIHRoZSBhY2Nlc3MgdG9rZW4g KGFzIHdlbGwgYXMgYW55IGVycm9yIHJlc3BvbnNlcykgYXJlIGJleW9uZCB0aGUgc2NvcGUgb2Yg dGhpcwogICAgICAgIHNwZWNpZmljYXRpb24sIGJ1dCBnZW5lcmFsbHkgaW52b2x2ZSBhbiBpbnRl cmFjdGlvbiBvciBjb29yZGluYXRpb24gYmV0d2VlbiB0aGUgcmVzb3VyY2UKICAgICAgICBzZXJ2 ZXIgYW5kIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlci4KICAgICAgCjwvcD4KPHA+CiAgICAgICAg VGhlIG1ldGhvZCBpbiB3aGljaCB0aGUgY2xpZW50IHV0aWxpemVzIHRoZSBhY2Nlc3MgdG9rZW4g dG8gYXV0aGVudGljYXRlIHdpdGggdGhlIHJlc291cmNlCiAgICAgICAgc2VydmVyIGRlcGVuZHMg b24gdGhlIHR5cGUgb2YgYWNjZXNzIHRva2VuIGlzc3VlZCBieSB0aGUgYXV0aG9yaXphdGlvbiBz ZXJ2ZXIuIFR5cGljYWxseSwKICAgICAgICBpdCBpbnZvbHZlcyB1c2luZyB0aGUgSFRUUCA8dHQ+ QXV0aG9yaXphdGlvbjwvdHQ+IHJlcXVlc3QgaGVhZGVyIGZpZWxkCiAgICAgICAgPGEgY2xhc3M9 J2luZm8nIGhyZWY9JyNSRkMyNjE3Jz5bUkZDMjYxN108c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFz cz0naW5mbyc+RnJhbmtzLCBKLiwgSGFsbGFtLUJha2VyLCBQLiwgSG9zdGV0bGVyLCBKLiwgTGF3 cmVuY2UsIFMuLCBMZWFjaCwgUC4sIEx1b3RvbmVuLCBBLiwgYW5kIEwuIFN0ZXdhcnQsICZsZHF1 bztIVFRQIEF1dGhlbnRpY2F0aW9uOiBCYXNpYyBhbmQgRGlnZXN0IEFjY2VzcyBBdXRoZW50aWNh dGlvbiwmcmRxdW87IEp1bmUmbmJzcDsxOTk5Ljwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4gd2l0 aCBhbiBhdXRoZW50aWNhdGlvbiBzY2hlbWUgZGVmaW5lZCBieSB0aGUgYWNjZXNzIHRva2VuIHR5 cGUKICAgICAgICBzcGVjaWZpY2F0aW9uLgogICAgICAKPC9wPgo8YSBuYW1lPSJ0b2tlbi10eXBl cyI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0i MCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBj bGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3Ry PjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLjcuMSI+PC9hPjxoMz43LjEuJm5ic3A7CkFj Y2VzcyBUb2tlbiBUeXBlczwvaDM+Cgo8cD4KICAgICAgICAgIFRoZSBhY2Nlc3MgdG9rZW4gdHlw ZSBwcm92aWRlcyB0aGUgY2xpZW50IHdpdGggdGhlIGluZm9ybWF0aW9uIHJlcXVpcmVkIHRvIHN1 Y2Nlc3NmdWxseQogICAgICAgICAgdXRpbGl6ZSB0aGUgYWNjZXNzIHRva2VuIHRvIG1ha2UgYSBw cm90ZWN0ZWQgcmVzb3VyY2UgcmVxdWVzdCAoYWxvbmcgd2l0aCB0eXBlLXNwZWNpZmljCiAgICAg ICAgICBhdHRyaWJ1dGVzKS4gVGhlIGNsaWVudCBNVVNUIE5PVCB1c2UgYW4gYWNjZXNzIHRva2Vu IGlmIGl0IGRvZXMgbm90IHVuZGVyc3RhbmQgdGhlIHRva2VuCiAgICAgICAgICB0eXBlLgogICAg ICAgIAo8L3A+CjxwPgogICAgICAgICAgICBGb3IgZXhhbXBsZSwgdGhlIDx0dD5iZWFyZXI8L3R0 PiB0b2tlbiB0eXBlIGRlZmluZWQgaW4KICAgICAgICAgICAgPGEgY2xhc3M9J2luZm8nIGhyZWY9 JyNJLUQuaWV0Zi1vYXV0aC12Mi1iZWFyZXInPltJJiM4MjA5O0QuaWV0ZiYjODIwOTtvYXV0aCYj ODIwOTt2MiYjODIwOTtiZWFyZXJdPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkpv bmVzLCBNLiwgSGFyZHQsIEQuLCBhbmQgRC4gUmVjb3Jkb24sICZsZHF1bztUaGUgT0F1dGggMi4w IEF1dGhvcml6YXRpb24gRnJhbWV3b3JrOiBCZWFyZXIgVG9rZW4gVXNhZ2UsJnJkcXVvOyBKdW5l Jm5ic3A7MjAxMi48L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+IGlzIHV0aWxpemVkIGJ5IHNpbXBs eSBpbmNsdWRpbmcgdGhlIGFjY2VzcwogICAgICAgICAgICB0b2tlbiBzdHJpbmcgaW4gdGhlIHJl cXVlc3Q6CiAgICAgICAgICAKPC9wPjxkaXYgc3R5bGU9J2Rpc3BsYXk6IHRhYmxlOyB3aWR0aDog MDsgbWFyZ2luLWxlZnQ6IDNlbTsgbWFyZ2luLXJpZ2h0OiBhdXRvJz48cHJlPgoKICBHRVQgL3Jl c291cmNlLzEgSFRUUC8xLjEKICBIb3N0OiBleGFtcGxlLmNvbQogIEF1dGhvcml6YXRpb246IEJl YXJlciBtRl85LkI1Zi00LjFKcU0KCjwvcHJlPjwvZGl2Pgo8cD4KICAgICAgICAgICAgd2hpbGUg dGhlIDx0dD5tYWM8L3R0PiB0b2tlbiB0eXBlIGRlZmluZWQgaW4KICAgICAgICAgICAgPGEgY2xh c3M9J2luZm8nIGhyZWY9JyNJLUQuaWV0Zi1vYXV0aC12Mi1odHRwLW1hYyc+W0kmIzgyMDk7RC5p ZXRmJiM4MjA5O29hdXRoJiM4MjA5O3YyJiM4MjA5O2h0dHAmIzgyMDk7bWFjXTxzcGFuPiAoPC9z cGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5IYW1tZXItTGFoYXYsIEUuLCAmbGRxdW87SFRUUCBBdXRo ZW50aWNhdGlvbjogTUFDIEFjY2VzcyBBdXRoZW50aWNhdGlvbiwmcmRxdW87IEZlYnJ1YXJ5Jm5i c3A7MjAxMi48L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+IGlzIHV0aWxpemVkIGJ5IGlzc3Vpbmcg YSBNQUMga2V5CiAgICAgICAgICAgIHRvZ2V0aGVyIHdpdGggdGhlIGFjY2VzcyB0b2tlbiB3aGlj aCBpcyB1c2VkIHRvIHNpZ24gY2VydGFpbiBjb21wb25lbnRzIG9mIHRoZSBIVFRQCiAgICAgICAg ICAgIHJlcXVlc3RzOgogICAgICAgICAgCjwvcD48ZGl2IHN0eWxlPSdkaXNwbGF5OiB0YWJsZTsg d2lkdGg6IDA7IG1hcmdpbi1sZWZ0OiAzZW07IG1hcmdpbi1yaWdodDogYXV0byc+PHByZT4KCiAg R0VUIC9yZXNvdXJjZS8xIEhUVFAvMS4xCiAgSG9zdDogZXhhbXBsZS5jb20KICBBdXRob3JpemF0 aW9uOiBNQUMgaWQ9Img0ODBkanM5M2hkOCIsCiAgICAgICAgICAgICAgICAgICAgIG5vbmNlPSIy NzQzMTI6ZGo4M2hzOXMiLAogICAgICAgICAgICAgICAgICAgICBtYWM9ImtEWnZkZGtuZHh2aEdS WFpodnVEakVXaEdlRT0iCgo8L3ByZT48L2Rpdj4KPHA+CiAgICAgICAgICBUaGUgYWJvdmUgZXhh bXBsZXMgYXJlIHByb3ZpZGVkIGZvciBpbGx1c3RyYXRpb24gcHVycG9zZXMgb25seS4gRGV2ZWxv cGVycyBhcmUgYWR2aXNlZCB0bwogICAgICAgICAgY29uc3VsdCB0aGUgPGEgY2xhc3M9J2luZm8n IGhyZWY9JyNJLUQuaWV0Zi1vYXV0aC12Mi1iZWFyZXInPltJJiM4MjA5O0QuaWV0ZiYjODIwOTtv YXV0aCYjODIwOTt2MiYjODIwOTtiZWFyZXJdPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2lu Zm8nPkpvbmVzLCBNLiwgSGFyZHQsIEQuLCBhbmQgRC4gUmVjb3Jkb24sICZsZHF1bztUaGUgT0F1 dGggMi4wIEF1dGhvcml6YXRpb24gRnJhbWV3b3JrOiBCZWFyZXIgVG9rZW4gVXNhZ2UsJnJkcXVv OyBKdW5lJm5ic3A7MjAxMi48L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+IGFuZAogICAgICAgICAg PGEgY2xhc3M9J2luZm8nIGhyZWY9JyNJLUQuaWV0Zi1vYXV0aC12Mi1odHRwLW1hYyc+W0kmIzgy MDk7RC5pZXRmJiM4MjA5O29hdXRoJiM4MjA5O3YyJiM4MjA5O2h0dHAmIzgyMDk7bWFjXTxzcGFu PiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5IYW1tZXItTGFoYXYsIEUuLCAmbGRxdW87SFRU UCBBdXRoZW50aWNhdGlvbjogTUFDIEFjY2VzcyBBdXRoZW50aWNhdGlvbiwmcmRxdW87IEZlYnJ1 YXJ5Jm5ic3A7MjAxMi48L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+IHNwZWNpZmljYXRpb25zIGJl Zm9yZSB1c2UuCiAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICBFYWNoIGFjY2VzcyB0b2tlbiB0 eXBlIGRlZmluaXRpb24gc3BlY2lmaWVzIHRoZSBhZGRpdGlvbmFsIGF0dHJpYnV0ZXMgKGlmIGFu eSkgc2VudCB0bwogICAgICAgICAgdGhlIGNsaWVudCB0b2dldGhlciB3aXRoIHRoZSA8dHQ+YWNj ZXNzX3Rva2VuPC90dD4gcmVzcG9uc2UgcGFyYW1ldGVyLgogICAgICAgICAgSXQgYWxzbyBkZWZp bmVzIHRoZSBIVFRQIGF1dGhlbnRpY2F0aW9uIG1ldGhvZCB1c2VkIHRvIGluY2x1ZGUgdGhlIGFj Y2VzcyB0b2tlbiB3aGVuCiAgICAgICAgICBtYWtpbmcgYSBwcm90ZWN0ZWQgcmVzb3VyY2UgcmVx dWVzdC4KICAgICAgICAKPC9wPgo8YSBuYW1lPSJyZXNvdXJjZS1lcnJvcnMiPjwvYT48YnIgLz48 aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5n PSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+ PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBu YW1lPSJyZmMuc2VjdGlvbi43LjIiPjwvYT48aDM+Ny4yLiZuYnNwOwpFcnJvciBSZXNwb25zZTwv aDM+Cgo8cD4KCSAgSWYgYSByZXNvdXJjZSBhY2Nlc3MgcmVxdWVzdCBmYWlscywgdGhlIHJlc291 cmNlIHNlcnZlciBTSE9VTEQgaW5mb3JtCgkgIHRoZSBjbGllbnQgb2YgdGhlIGVycm9yLiAgV2hp bGUgdGhlIHNwZWNpZmljcyBvZiBzdWNoIGVycm9yIHJlc3BvbnNlcwoJICBhcmUgYmV5b25kIHRo ZSBzY29wZSBvZiB0aGlzIHNwZWNpZmljYXRpb24sIHRoaXMgZG9jdW1lbnRzIGVzdGFibGlzaGVz CgkgIGEgY29tbW9uIHJlZ2lzdHJ5IGluIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjZXJyb3ItcmVn aXN0cnknPlNlY3Rpb24mbmJzcDsxMS40PHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8n PlRoZSBPQXV0aCBFeHRlbnNpb25zIEVycm9yIFJlZ2lzdHJ5PC9zcGFuPjxzcGFuPik8L3NwYW4+ PC9hPiBmb3IgZXJyb3IgdmFsdWVzCgkgIHRvIGJlIHNoYXJlZCBhbW9uZyBPQXV0aCB0b2tlbiBh dXRoZW50aWNhdGlvbiBzY2hlbWVzLiAKCQo8L3A+CjxwPgoJICBOZXcgYXV0aGVudGljYXRpb24g c2NoZW1lcyBkZXNpZ25lZCBwcmltYXJpbHkgZm9yIE9BdXRoIHRva2VuCgkgIGF1dGhlbnRpY2F0 aW9uIFNIT1VMRCBkZWZpbmUgYSBtZWNoYW5pc20gZm9yIHByb3ZpZGluZyBhbgoJICBlcnJvciBz dGF0dXMgY29kZSB0byB0aGUgY2xpZW50LCBpbiB3aGljaCB0aGUgZXJyb3IgdmFsdWVzIGFsbG93 ZWQgYXJlCgkgIHJlZ2lzdGVyZWQgaW4gdGhlIGVycm9yIHJlZ2lzdHJ5IGVzdGFibGlzaGVkIGJ5 IHRoaXMgc3BlY2lmaWNhdGlvbi4gU3VjaAoJICBzY2hlbWVzIE1BWSBsaW1pdCB0aGUgc2V0IG9m IHZhbGlkIGVycm9yIGNvZGVzIHRvIGEgc3Vic2V0IG9mIHRoZQoJICByZWdpc3RlcmVkIHZhbHVl cy4gSWYgdGhlIGVycm9yIGNvZGUgaXMgcmV0dXJuZWQgdXNpbmcgYSBuYW1lZCBwYXJhbWV0ZXIs CgkgIHRoZSBwYXJhbWV0ZXIgbmFtZSBTSE9VTEQgYmUgPHR0PmVycm9yPC90dD4uCgkKPC9wPgo8 cD4KCSAgT3RoZXIgc2NoZW1lcyBjYXBhYmxlIG9mIGJlaW5nIHVzZWQgZm9yIE9BdXRoIHRva2Vu IGF1dGhlbnRpY2F0aW9uLCBidXQKCSAgbm90IHByaW1hcmlseSBkZXNpZ25lZCBmb3IgdGhhdCBw dXJwb3NlLCBNQVkgYmluZCB0aGVpciBlcnJvciB2YWx1ZXMgdG8gdGhlCgkgIHJlZ2lzdHJ5IGlu IHRoZSBzYW1lIG1hbm5lci4KCQo8L3A+CjxwPgoJICBOZXcgYXV0aGVudGljYXRpb24gc2NoZW1l cyBNQVkgY2hvb3NlIHRvIGFsc28gc3BlY2lmeSB0aGUgdXNlIG9mIHRoZQoJICA8dHQ+ZXJyb3Jf ZGVzY3JpcHRpb248L3R0PiBhbmQgCgkgIDx0dD5lcnJvcl91cmk8L3R0PgoJICBwYXJhbWV0ZXJz IHRvIHJldHVybiBlcnJvciBpbmZvcm1hdGlvbiBpbiBhIG1hbm5lciBwYXJhbGxlbAoJICB0byB0 aGVpciB1c2FnZSBpbiB0aGlzIHNwZWNpZmljYXRpb24uCgkKPC9wPgo8YSBuYW1lPSJleHRlbnNp b25zIj48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5n PSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRk IGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwv dHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uOCI+PC9hPjxoMz44LiZuYnNwOwpFeHRl bnNpYmlsaXR5PC9oMz4KCjxhIG5hbWU9Im5ldy10eXBlcyI+PC9hPjxiciAvPjxociAvPgo8dGFi bGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNz PSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIj dG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5z ZWN0aW9uLjguMSI+PC9hPjxoMz44LjEuJm5ic3A7CkRlZmluaW5nIEFjY2VzcyBUb2tlbiBUeXBl czwvaDM+Cgo8cD4KICAgICAgICAgIEFjY2VzcyB0b2tlbiB0eXBlcyBjYW4gYmUgZGVmaW5lZCBp biBvbmUgb2YgdHdvIHdheXM6IHJlZ2lzdGVyZWQgaW4gdGhlIGFjY2VzcyB0b2tlbiB0eXBlCiAg ICAgICAgICByZWdpc3RyeSAoZm9sbG93aW5nIHRoZSBwcm9jZWR1cmVzIGluIDxhIGNsYXNzPSdp bmZvJyBocmVmPScjdHlwZS1yZWdpc3RyeSc+U2VjdGlvbiZuYnNwOzExLjE8c3Bhbj4gKDwvc3Bh bj48c3BhbiBjbGFzcz0naW5mbyc+VGhlIE9BdXRoIEFjY2VzcyBUb2tlbiBUeXBlIFJlZ2lzdHJ5 PC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPiksIG9yIGJ5IHVzaW5nIGEKICAgICAgICAgIHVuaXF1 ZSBhYnNvbHV0ZSBVUkkgYXMgaXRzIG5hbWUuCiAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICBU eXBlcyB1dGlsaXppbmcgYSBVUkkgbmFtZSBTSE9VTEQgYmUgbGltaXRlZCB0byB2ZW5kb3Itc3Bl Y2lmaWMgaW1wbGVtZW50YXRpb25zIHRoYXQgYXJlCiAgICAgICAgICBub3QgY29tbW9ubHkgYXBw bGljYWJsZSwgYW5kIGFyZSBzcGVjaWZpYyB0byB0aGUgaW1wbGVtZW50YXRpb24gZGV0YWlscyBv ZiB0aGUgcmVzb3VyY2UKICAgICAgICAgIHNlcnZlciB3aGVyZSB0aGV5IGFyZSB1c2VkLgogICAg ICAgIAo8L3A+CjxwPgogICAgICAgICAgQWxsIG90aGVyIHR5cGVzIE1VU1QgYmUgcmVnaXN0ZXJl ZC4gVHlwZSBuYW1lcyBNVVNUIGNvbmZvcm0gdG8gdGhlIHR5cGUtbmFtZSBBQk5GLiBJZiB0aGUK ICAgICAgICAgIHR5cGUgZGVmaW5pdGlvbiBpbmNsdWRlcyBhIG5ldyBIVFRQIGF1dGhlbnRpY2F0 aW9uIHNjaGVtZSwgdGhlIHR5cGUgbmFtZSBTSE9VTEQgYmUKICAgICAgICAgIGlkZW50aWNhbCB0 byB0aGUgSFRUUCBhdXRoZW50aWNhdGlvbiBzY2hlbWUgbmFtZSAoYXMgZGVmaW5lZCBieSA8YSBj bGFzcz0naW5mbycgaHJlZj0nI1JGQzI2MTcnPltSRkMyNjE3XTxzcGFuPiAoPC9zcGFuPjxzcGFu IGNsYXNzPSdpbmZvJz5GcmFua3MsIEouLCBIYWxsYW0tQmFrZXIsIFAuLCBIb3N0ZXRsZXIsIEou LCBMYXdyZW5jZSwgUy4sIExlYWNoLCBQLiwgTHVvdG9uZW4sIEEuLCBhbmQgTC4gU3Rld2FydCwg JmxkcXVvO0hUVFAgQXV0aGVudGljYXRpb246IEJhc2ljIGFuZCBEaWdlc3QgQWNjZXNzIEF1dGhl bnRpY2F0aW9uLCZyZHF1bzsgSnVuZSZuYnNwOzE5OTkuPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9h PikuCiAgICAgICAgICBUaGUgdG9rZW4gdHlwZSA8dHQ+ZXhhbXBsZTwvdHQ+IGlzIHJlc2VydmVk IGZvciB1c2UgaW4gZXhhbXBsZXMuCiAgICAgICAgCjwvcD48ZGl2IHN0eWxlPSdkaXNwbGF5OiB0 YWJsZTsgd2lkdGg6IDA7IG1hcmdpbi1sZWZ0OiAzZW07IG1hcmdpbi1yaWdodDogYXV0byc+PHBy ZT4KCiAgdHlwZS1uYW1lICA9IDEqbmFtZS1jaGFyCiAgbmFtZS1jaGFyICA9ICItIiAvICIuIiAv ICJfIiAvIERJR0lUIC8gQUxQSEEKCjwvcHJlPjwvZGl2Pgo8YSBuYW1lPSJlbmRwb2ludC1wYXJh bXMiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9 IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQg Y2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90 cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi44LjIiPjwvYT48aDM+OC4yLiZuYnNwOwpE ZWZpbmluZyBOZXcgRW5kcG9pbnQgUGFyYW1ldGVyczwvaDM+Cgo8cD4KICAgICAgICAgIE5ldyBy ZXF1ZXN0IG9yIHJlc3BvbnNlIHBhcmFtZXRlcnMgZm9yIHVzZSB3aXRoIHRoZSBhdXRob3JpemF0 aW9uIGVuZHBvaW50IG9yIHRoZSB0b2tlbgogICAgICAgICAgZW5kcG9pbnQgYXJlIGRlZmluZWQg YW5kIHJlZ2lzdGVyZWQgaW4gdGhlIHBhcmFtZXRlcnMgcmVnaXN0cnkgZm9sbG93aW5nIHRoZSBw cm9jZWR1cmUgaW4KICAgICAgICAgIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjcGFyYW1ldGVycy1y ZWdpc3RyeSc+U2VjdGlvbiZuYnNwOzExLjI8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5m byc+VGhlIE9BdXRoIFBhcmFtZXRlcnMgUmVnaXN0cnk8L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+ LgogICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgUGFyYW1ldGVyIG5hbWVzIE1VU1QgY29uZm9y bSB0byB0aGUgcGFyYW0tbmFtZSBBQk5GIGFuZCBwYXJhbWV0ZXIgdmFsdWVzIHN5bnRheCBNVVNU IGJlCiAgICAgICAgICB3ZWxsLWRlZmluZWQgKGUuZy4sIHVzaW5nIEFCTkYsIG9yIGEgcmVmZXJl bmNlIHRvIHRoZSBzeW50YXggb2YgYW4gZXhpc3RpbmcgcGFyYW1ldGVyKS4KICAgICAgICAKPC9w PjxkaXYgc3R5bGU9J2Rpc3BsYXk6IHRhYmxlOyB3aWR0aDogMDsgbWFyZ2luLWxlZnQ6IDNlbTsg bWFyZ2luLXJpZ2h0OiBhdXRvJz48cHJlPgoKICBwYXJhbS1uYW1lICA9IDEqbmFtZS1jaGFyCiAg bmFtZS1jaGFyICAgPSAiLSIgLyAiLiIgLyAiXyIgLyBESUdJVCAvIEFMUEhBCgo8L3ByZT48L2Rp dj4KPHA+CiAgICAgICAgICBVbnJlZ2lzdGVyZWQgdmVuZG9yLXNwZWNpZmljIHBhcmFtZXRlciBl eHRlbnNpb25zIHRoYXQgYXJlIG5vdCBjb21tb25seSBhcHBsaWNhYmxlLCBhbmQKICAgICAgICAg IGFyZSBzcGVjaWZpYyB0byB0aGUgaW1wbGVtZW50YXRpb24gZGV0YWlscyBvZiB0aGUgYXV0aG9y aXphdGlvbiBzZXJ2ZXIgd2hlcmUgdGhleSBhcmUKICAgICAgICAgIHVzZWQgU0hPVUxEIHV0aWxp emUgYSB2ZW5kb3Itc3BlY2lmaWMgcHJlZml4IHRoYXQgaXMgbm90IGxpa2VseSB0byBjb25mbGlj dCB3aXRoIG90aGVyCiAgICAgICAgICByZWdpc3RlcmVkIHZhbHVlcyAoZS5nLiBiZWdpbiB3aXRo ICdjb21wYW55bmFtZV8nKS4KICAgICAgICAKPC9wPgo8YSBuYW1lPSJhbmNob3IzMSI+PC9hPjxi ciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNw YWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9D YnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+ CjxhIG5hbWU9InJmYy5zZWN0aW9uLjguMyI+PC9hPjxoMz44LjMuJm5ic3A7CkRlZmluaW5nIE5l dyBBdXRob3JpemF0aW9uIEdyYW50IFR5cGVzPC9oMz4KCjxwPgogICAgICAgICAgTmV3IGF1dGhv cml6YXRpb24gZ3JhbnQgdHlwZXMgY2FuIGJlIGRlZmluZWQgYnkgYXNzaWduaW5nIHRoZW0gYSB1 bmlxdWUgYWJzb2x1dGUgVVJJIGZvcgogICAgICAgICAgdXNlIHdpdGggdGhlIDx0dD5ncmFudF90 eXBlPC90dD4gcGFyYW1ldGVyLiBJZiB0aGUgZXh0ZW5zaW9uIGdyYW50CiAgICAgICAgICB0eXBl IHJlcXVpcmVzIGFkZGl0aW9uYWwgdG9rZW4gZW5kcG9pbnQgcGFyYW1ldGVycywgdGhleSBNVVNU IGJlIHJlZ2lzdGVyZWQgaW4gdGhlIE9BdXRoCiAgICAgICAgICBwYXJhbWV0ZXJzIHJlZ2lzdHJ5 IGFzIGRlc2NyaWJlZCBieSA8YSBjbGFzcz0naW5mbycgaHJlZj0nI3BhcmFtZXRlcnMtcmVnaXN0 cnknPlNlY3Rpb24mbmJzcDsxMS4yPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPlRo ZSBPQXV0aCBQYXJhbWV0ZXJzIFJlZ2lzdHJ5PC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPi4KICAg ICAgICAKPC9wPgo8YSBuYW1lPSJyZXNwb25zZS10eXBlLWV4dCI+PC9hPjxiciAvPjxociAvPgo8 dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNs YXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVm PSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJm Yy5zZWN0aW9uLjguNCI+PC9hPjxoMz44LjQuJm5ic3A7CkRlZmluaW5nIE5ldyBBdXRob3JpemF0 aW9uIEVuZHBvaW50IFJlc3BvbnNlIFR5cGVzPC9oMz4KCjxwPgogICAgICAgICAgTmV3IHJlc3Bv bnNlIHR5cGVzIGZvciB1c2Ugd2l0aCB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludCBhcmUgZGVm aW5lZCBhbmQgcmVnaXN0ZXJlZCBpbgogICAgICAgICAgdGhlIGF1dGhvcml6YXRpb24gZW5kcG9p bnQgcmVzcG9uc2UgdHlwZSByZWdpc3RyeSBmb2xsb3dpbmcgdGhlIHByb2NlZHVyZSBpbgogICAg ICAgICAgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNyZXNwb25zZS10eXBlLXJlZ2lzdHJ5Jz5TZWN0 aW9uJm5ic3A7MTEuMzxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5UaGUgT0F1dGgg QXV0aG9yaXphdGlvbiBFbmRwb2ludCBSZXNwb25zZSBUeXBlIFJlZ2lzdHJ5PC9zcGFuPjxzcGFu Pik8L3NwYW4+PC9hPi4gUmVzcG9uc2UgdHlwZSBuYW1lcyBNVVNUIGNvbmZvcm0gdG8gdGhlCiAg ICAgICAgICByZXNwb25zZS10eXBlIEFCTkYuCiAgICAgICAgCjwvcD48ZGl2IHN0eWxlPSdkaXNw bGF5OiB0YWJsZTsgd2lkdGg6IDA7IG1hcmdpbi1sZWZ0OiAzZW07IG1hcmdpbi1yaWdodDogYXV0 byc+PHByZT4KCiAgcmVzcG9uc2UtdHlwZSAgPSByZXNwb25zZS1uYW1lICooIFNQIHJlc3BvbnNl LW5hbWUgKQogIHJlc3BvbnNlLW5hbWUgID0gMSpyZXNwb25zZS1jaGFyCiAgcmVzcG9uc2UtY2hh ciAgPSAiXyIgLyBESUdJVCAvIEFMUEhBCgo8L3ByZT48L2Rpdj4KPHA+CiAgICAgICAgICBJZiBh IHJlc3BvbnNlIHR5cGUgY29udGFpbnMgb25lIG9yIG1vcmUgc3BhY2UgY2hhcmFjdGVycyAoJXgy MCksIGl0IGlzIGNvbXBhcmVkIGFzIGEKICAgICAgICAgIHNwYWNlLWRlbGltaXRlZCBsaXN0IG9m IHZhbHVlcyBpbiB3aGljaCB0aGUgb3JkZXIgb2YgdmFsdWVzIGRvZXMgbm90IG1hdHRlci4gT25s eSBvbmUKICAgICAgICAgIG9yZGVyIG9mIHZhbHVlcyBjYW4gYmUgcmVnaXN0ZXJlZCwgd2hpY2gg Y292ZXJzIGFsbCBvdGhlciBhcnJhbmdlbWVudHMgb2YgdGhlIHNhbWUgc2V0IG9mCiAgICAgICAg ICB2YWx1ZXMuCiAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICBGb3IgZXhhbXBsZSwgdGhlIHJl c3BvbnNlIHR5cGUgPHR0PnRva2VuIGNvZGU8L3R0PiBpcyBsZWZ0IHVuZGVmaW5lZAogICAgICAg ICAgYnkgdGhpcyBzcGVjaWZpY2F0aW9uLiBIb3dldmVyLCBhbiBleHRlbnNpb24gY2FuIGRlZmlu ZSBhbmQgcmVnaXN0ZXIgdGhlCiAgICAgICAgICA8dHQ+dG9rZW4gY29kZTwvdHQ+IHJlc3BvbnNl IHR5cGUuIE9uY2UgcmVnaXN0ZXJlZCwgdGhlIHNhbWUKICAgICAgICAgIGNvbWJpbmF0aW9uIGNh bm5vdCBiZSByZWdpc3RlcmVkIGFzIDx0dD5jb2RlIHRva2VuPC90dD4sIGJ1dCBib3RoCiAgICAg ICAgICB2YWx1ZXMgY2FuIGJlIHVzZWQgdG8gZGVub3RlIHRoZSBzYW1lIHJlc3BvbnNlIHR5cGUu CiAgICAgICAgCjwvcD4KPGEgbmFtZT0ibmV3LWVycm9ycyI+PC9hPjxiciAvPjxociAvPgo8dGFi bGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNz PSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIj dG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5z ZWN0aW9uLjguNSI+PC9hPjxoMz44LjUuJm5ic3A7CkRlZmluaW5nIEFkZGl0aW9uYWwgRXJyb3Ig Q29kZXM8L2gzPgoKPHA+CiAgICAgICAgICBJbiBjYXNlcyB3aGVyZSBwcm90b2NvbCBleHRlbnNp b25zIChpLmUuIGFjY2VzcyB0b2tlbiB0eXBlcywgZXh0ZW5zaW9uIHBhcmFtZXRlcnMsIG9yCiAg ICAgICAgICBleHRlbnNpb24gZ3JhbnQgdHlwZXMpIHJlcXVpcmUgYWRkaXRpb25hbCBlcnJvciBj b2RlcyB0byBiZSB1c2VkIHdpdGggdGhlIGF1dGhvcml6YXRpb24KICAgICAgICAgIGNvZGUgZ3Jh bnQgZXJyb3IgcmVzcG9uc2UgKDxhIGNsYXNzPSdpbmZvJyBocmVmPScjY29kZS1hdXRoei1lcnJv cic+U2VjdGlvbiZuYnNwOzQuMS4yLjE8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+ RXJyb3IgUmVzcG9uc2U8L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+KSwgdGhlIGltcGxpY2l0IGdy YW50IGVycm9yCiAgICAgICAgICByZXNwb25zZSAoPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNpbXBs aWNpdC1hdXRoei1lcnJvcic+U2VjdGlvbiZuYnNwOzQuMi4yLjE8c3Bhbj4gKDwvc3Bhbj48c3Bh biBjbGFzcz0naW5mbyc+RXJyb3IgUmVzcG9uc2U8L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+KSwg dGhlIHRva2VuIGVycm9yIHJlc3BvbnNlCiAgICAgICAgICAoPGEgY2xhc3M9J2luZm8nIGhyZWY9 JyN0b2tlbi1lcnJvcnMnPlNlY3Rpb24mbmJzcDs1LjI8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFz cz0naW5mbyc+RXJyb3IgUmVzcG9uc2U8L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+KSwKCSAgb3Ig dGhlIHJlc291cmNlIGFjY2VzcyBlcnJvciByZXNwb25zZSAoPGEgY2xhc3M9J2luZm8nIGhyZWY9 JyNyZXNvdXJjZS1lcnJvcnMnPlNlY3Rpb24mbmJzcDs3LjI8c3Bhbj4gKDwvc3Bhbj48c3BhbiBj bGFzcz0naW5mbyc+RXJyb3IgUmVzcG9uc2U8L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+KSwKCSAg c3VjaCBlcnJvciBjb2RlcyBNQVkgYmUgZGVmaW5lZC4KICAgICAgICAKPC9wPgo8cD4KICAgICAg ICAgIEV4dGVuc2lvbiBlcnJvciBjb2RlcyBNVVNUIGJlIHJlZ2lzdGVyZWQgKGZvbGxvd2luZyB0 aGUgcHJvY2VkdXJlcyBpbgogICAgICAgICAgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNlcnJvci1y ZWdpc3RyeSc+U2VjdGlvbiZuYnNwOzExLjQ8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5m byc+VGhlIE9BdXRoIEV4dGVuc2lvbnMgRXJyb3IgUmVnaXN0cnk8L3NwYW4+PHNwYW4+KTwvc3Bh bj48L2E+KSBpZiB0aGUgZXh0ZW5zaW9uIHRoZXkgYXJlIHVzZWQgaW4gY29uanVuY3Rpb24gd2l0 aCBpcwogICAgICAgICAgYSByZWdpc3RlcmVkIGFjY2VzcyB0b2tlbiB0eXBlLCBhIHJlZ2lzdGVy ZWQgZW5kcG9pbnQgcGFyYW1ldGVyLCBvciBhbiBleHRlbnNpb24gZ3JhbnQKICAgICAgICAgIHR5 cGUuIEVycm9yIGNvZGVzIHVzZWQgd2l0aCB1bnJlZ2lzdGVyZWQgZXh0ZW5zaW9ucyBNQVkgYmUg cmVnaXN0ZXJlZC4KICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgIEVycm9yIGNvZGVzIE1VU1Qg Y29uZm9ybSB0byB0aGUgZXJyb3IgQUJORiwgYW5kIFNIT1VMRCBiZSBwcmVmaXhlZCBieSBhbiBp ZGVudGlmeWluZwogICAgICAgICAgbmFtZSB3aGVuIHBvc3NpYmxlLiBGb3IgZXhhbXBsZSwgYW4g ZXJyb3IgaWRlbnRpZnlpbmcgYW4gaW52YWxpZCB2YWx1ZSBzZXQgdG8gdGhlCiAgICAgICAgICBl eHRlbnNpb24gcGFyYW1ldGVyIDx0dD5leGFtcGxlPC90dD4gU0hPVUxEIGJlIG5hbWVkCiAgICAg ICAgICA8dHQ+ZXhhbXBsZV9pbnZhbGlkPC90dD4uCiAgICAgICAgCjwvcD48ZGl2IHN0eWxlPSdk aXNwbGF5OiB0YWJsZTsgd2lkdGg6IDA7IG1hcmdpbi1sZWZ0OiAzZW07IG1hcmdpbi1yaWdodDog YXV0byc+PHByZT4KCiAgZXJyb3IgICAgICA9IDEqZXJyb3ItY2hhcgogIGVycm9yLWNoYXIgPSAl eDIwLTIxIC8gJXgyMy01QiAvICV4NUQtN0UKCjwvcHJlPjwvZGl2Pgo8YSBuYW1lPSJhbmNob3Iz MiI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0i MCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBj bGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3Ry PjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLjkiPjwvYT48aDM+OS4mbmJzcDsKTmF0aXZl IEFwcGxpY2F0aW9uczwvaDM+Cgo8cD4KICAgICAgICBOYXRpdmUgYXBwbGljYXRpb25zIGFyZSBj bGllbnRzIGluc3RhbGxlZCBhbmQgZXhlY3V0ZWQgb24gdGhlIGRldmljZSB1c2VkIGJ5IHRoZSBy ZXNvdXJjZQogICAgICAgIG93bmVyIChpLmUuIGRlc2t0b3AgYXBwbGljYXRpb24sIG5hdGl2ZSBt b2JpbGUgYXBwbGljYXRpb24pLiBOYXRpdmUgYXBwbGljYXRpb25zIHJlcXVpcmUKICAgICAgICBz cGVjaWFsIGNvbnNpZGVyYXRpb24gcmVsYXRlZCB0byBzZWN1cml0eSwgcGxhdGZvcm0gY2FwYWJp bGl0aWVzLCBhbmQgb3ZlcmFsbCBlbmQtdXNlcgogICAgICAgIGV4cGVyaWVuY2UuCiAgICAgIAo8 L3A+CjxwPgogICAgICAgIFRoZSBhdXRob3JpemF0aW9uIGVuZHBvaW50IHJlcXVpcmVzIGludGVy YWN0aW9uIGJldHdlZW4gdGhlIGNsaWVudCBhbmQgdGhlIHJlc291cmNlCiAgICAgICAgb3duZXIn cyB1c2VyLWFnZW50LiBOYXRpdmUgYXBwbGljYXRpb25zIGNhbiBpbnZva2UgYW4gZXh0ZXJuYWwg dXNlci1hZ2VudCBvciBlbWJlZCBhCiAgICAgICAgdXNlci1hZ2VudCB3aXRoaW4gdGhlIGFwcGxp Y2F0aW9uLiBGb3IgZXhhbXBsZToKICAgICAgCjwvcD4KPHA+CiAgICAgICAgPC9wPgo8dWwgY2xh c3M9InRleHQiPgo8bGk+CiAgICAgICAgICAgIEV4dGVybmFsIHVzZXItYWdlbnQgLSB0aGUgbmF0 aXZlIGFwcGxpY2F0aW9uIGNhbiBjYXB0dXJlIHRoZSByZXNwb25zZSBmcm9tIHRoZQogICAgICAg ICAgICBhdXRob3JpemF0aW9uIHNlcnZlciB1c2luZyBhIHJlZGlyZWN0aW9uIFVSSSB3aXRoIGEg c2NoZW1lIHJlZ2lzdGVyZWQgd2l0aCB0aGUKICAgICAgICAgICAgb3BlcmF0aW5nIHN5c3RlbSB0 byBpbnZva2UgdGhlIGNsaWVudCBhcyB0aGUgaGFuZGxlciwgbWFudWFsIGNvcHktYW5kLXBhc3Rl IG9mIHRoZQogICAgICAgICAgICBjcmVkZW50aWFscywgcnVubmluZyBhIGxvY2FsIHdlYiBzZXJ2 ZXIsIGluc3RhbGxpbmcgYSB1c2VyLWFnZW50IGV4dGVuc2lvbiwgb3IgYnkKICAgICAgICAgICAg cHJvdmlkaW5nIGEgcmVkaXJlY3Rpb24gVVJJIGlkZW50aWZ5aW5nIGEgc2VydmVyLWhvc3RlZCBy ZXNvdXJjZSB1bmRlciB0aGUgY2xpZW50J3MKICAgICAgICAgICAgY29udHJvbCwgd2hpY2ggaW4g dHVybiBtYWtlcyB0aGUgcmVzcG9uc2UgYXZhaWxhYmxlIHRvIHRoZSBuYXRpdmUgYXBwbGljYXRp b24uCiAgICAgICAgICAKPC9saT4KPGxpPgogICAgICAgICAgICBFbWJlZGRlZCB1c2VyLWFnZW50 IC0gdGhlIG5hdGl2ZSBhcHBsaWNhdGlvbiBvYnRhaW5zIHRoZSByZXNwb25zZSBieSBkaXJlY3Rs eQogICAgICAgICAgICBjb21tdW5pY2F0aW5nIHdpdGggdGhlIGVtYmVkZGVkIHVzZXItYWdlbnQg YnkgbW9uaXRvcmluZyBzdGF0ZSBjaGFuZ2VzIGVtaXR0ZWQgZHVyaW5nCiAgICAgICAgICAgIHRo ZSByZXNvdXJjZSBsb2FkLCBvciBhY2Nlc3NpbmcgdGhlIHVzZXItYWdlbnQncyBjb29raWVzIHN0 b3JhZ2UuCiAgICAgICAgICAKPC9saT4KPC91bD48cD4KICAgICAgCjwvcD4KPHA+CiAgICAgICAg V2hlbiBjaG9vc2luZyBiZXR3ZWVuIGFuIGV4dGVybmFsIG9yIGVtYmVkZGVkIHVzZXItYWdlbnQs IGRldmVsb3BlcnMgc2hvdWxkIGNvbnNpZGVyOgogICAgICAKPC9wPgo8cD4KICAgICAgICA8L3A+ Cjx1bCBjbGFzcz0idGV4dCI+CjxsaT4KICAgICAgICAgICAgQW4gRXh0ZXJuYWwgdXNlci1hZ2Vu dCBtYXkgaW1wcm92ZSBjb21wbGV0aW9uIHJhdGUgYXMgdGhlIHJlc291cmNlIG93bmVyIG1heSBh bHJlYWR5IGhhdmUKICAgICAgICAgICAgYW4gYWN0aXZlIHNlc3Npb24gd2l0aCB0aGUgYXV0aG9y aXphdGlvbiBzZXJ2ZXIgcmVtb3ZpbmcgdGhlIG5lZWQgdG8gcmUtYXV0aGVudGljYXRlLiBJdAog ICAgICAgICAgICBwcm92aWRlcyBhIGZhbWlsaWFyIGVuZC11c2VyIGV4cGVyaWVuY2UgYW5kIGZ1 bmN0aW9uYWxpdHkuIFRoZSByZXNvdXJjZSBvd25lciBtYXkgYWxzbwogICAgICAgICAgICByZWx5 IG9uIHVzZXItYWdlbnQgZmVhdHVyZXMgb3IgZXh0ZW5zaW9ucyB0byBhc3Npc3Qgd2l0aCBhdXRo ZW50aWNhdGlvbiAoZS5nLiBwYXNzd29yZAogICAgICAgICAgICBtYW5hZ2VyLCAyLWZhY3RvciBk ZXZpY2UgcmVhZGVyKS4KICAgICAgICAgIAo8L2xpPgo8bGk+CiAgICAgICAgICAgIEFuIGVtYmVk ZGVkIHVzZXItYWdlbnQgbWF5IG9mZmVyIGltcHJvdmVkIHVzYWJpbGl0eSwgYXMgaXQgcmVtb3Zl cyB0aGUgbmVlZCB0byBzd2l0Y2gKICAgICAgICAgICAgY29udGV4dCBhbmQgb3BlbiBuZXcgd2lu ZG93cy4KICAgICAgICAgIAo8L2xpPgo8bGk+CiAgICAgICAgICAgIEFuIGVtYmVkZGVkIHVzZXIt YWdlbnQgcG9zZXMgYSBzZWN1cml0eSBjaGFsbGVuZ2UgYmVjYXVzZSByZXNvdXJjZSBvd25lcnMg YXJlCiAgICAgICAgICAgIGF1dGhlbnRpY2F0aW5nIGluIGFuIHVuaWRlbnRpZmllZCB3aW5kb3cg d2l0aG91dCBhY2Nlc3MgdG8gdGhlIHZpc3VhbCBwcm90ZWN0aW9ucyBmb3VuZAogICAgICAgICAg ICBpbiBtb3N0IGV4dGVybmFsIHVzZXItYWdlbnRzLiBBbiBlbWJlZGRlZCB1c2VyLWFnZW50IGVk dWNhdGVzIGVuZC11c2VycyB0byB0cnVzdAogICAgICAgICAgICB1bmlkZW50aWZpZWQgcmVxdWVz dHMgZm9yIGF1dGhlbnRpY2F0aW9uIChtYWtpbmcgcGhpc2hpbmcgYXR0YWNrcyBlYXNpZXIgdG8g ZXhlY3V0ZSkuCiAgICAgICAgICAKPC9saT4KPC91bD48cD4KICAgICAgCjwvcD4KPHA+CiAgICAg ICAgV2hlbiBjaG9vc2luZyBiZXR3ZWVuIHRoZSBpbXBsaWNpdCBncmFudCB0eXBlIGFuZCB0aGUg YXV0aG9yaXphdGlvbiBjb2RlIGdyYW50IHR5cGUsIHRoZQogICAgICAgIGZvbGxvd2luZyBzaG91 bGQgYmUgY29uc2lkZXJlZDoKICAgICAgCjwvcD4KPHA+CiAgICAgICAgPC9wPgo8dWwgY2xhc3M9 InRleHQiPgo8bGk+CiAgICAgICAgICAgIE5hdGl2ZSBhcHBsaWNhdGlvbnMgdGhhdCB1c2UgdGhl IGF1dGhvcml6YXRpb24gY29kZSBncmFudCB0eXBlIFNIT1VMRCBkbyBzbyB3aXRob3V0CiAgICAg ICAgICAgIHVzaW5nIGNsaWVudCBjcmVkZW50aWFscywgZHVlIHRvIHRoZSBuYXRpdmUgYXBwbGlj YXRpb24ncyBpbmFiaWxpdHkgdG8ga2VlcCBjbGllbnQKICAgICAgICAgICAgY3JlZGVudGlhbHMg Y29uZmlkZW50aWFsLgogICAgICAgICAgCjwvbGk+CjxsaT4KICAgICAgICAgICAgV2hlbiB1c2lu ZyB0aGUgaW1wbGljaXQgZ3JhbnQgdHlwZSBmbG93IGEgcmVmcmVzaCB0b2tlbiBpcyBub3QgcmV0 dXJuZWQgd2hpY2ggcmVxdWlyZXMKICAgICAgICAgICAgcmVwZWF0aW5nIHRoZSBhdXRob3JpemF0 aW9uIHByb2Nlc3Mgb25jZSB0aGUgYWNjZXNzIHRva2VuIGV4cGlyZXMuCiAgICAgICAgICAKPC9s aT4KPC91bD48cD4KICAgICAgCjwvcD4KPGEgbmFtZT0iYW5jaG9yMzMiPjwvYT48YnIgLz48aHIg Lz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIy IiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEg aHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1l PSJyZmMuc2VjdGlvbi4xMCI+PC9hPjxoMz4xMC4mbmJzcDsKU2VjdXJpdHkgQ29uc2lkZXJhdGlv bnM8L2gzPgoKPHA+CiAgICAgICAgQXMgYSBmbGV4aWJsZSBhbmQgZXh0ZW5zaWJsZSBmcmFtZXdv cmssIE9BdXRoJ3Mgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgZGVwZW5kIG9uIG1hbnkKICAgICAg ICBmYWN0b3JzLiBUaGUgZm9sbG93aW5nIHNlY3Rpb25zIHByb3ZpZGUgaW1wbGVtZW50ZXJzIHdp dGggc2VjdXJpdHkgZ3VpZGVsaW5lcyBmb2N1c2VkIG9uCiAgICAgICAgdGhlIHRocmVlIGNsaWVu dCBwcm9maWxlcyBkZXNjcmliZWQgaW4gPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNjbGllbnQtdHlw ZXMnPlNlY3Rpb24mbmJzcDsyLjE8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+Q2xp ZW50IFR5cGVzPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPjogd2ViIGFwcGxpY2F0aW9uLAogICAg ICAgIHVzZXItYWdlbnQtYmFzZWQgYXBwbGljYXRpb24sIGFuZCBuYXRpdmUgYXBwbGljYXRpb24u CiAgICAgIAo8L3A+CjxwPgogICAgICAgIEEgY29tcHJlaGVuc2l2ZSBPQXV0aCBzZWN1cml0eSBt b2RlbCBhbmQgYW5hbHlzaXMsIGFzIHdlbGwgYXMgYmFja2dyb3VuZCBmb3IgdGhlIHByb3RvY29s CiAgICAgICAgZGVzaWduLCBpcyBwcm92aWRlZCBieSA8YSBjbGFzcz0naW5mbycgaHJlZj0nI0kt RC5pZXRmLW9hdXRoLXYyLXRocmVhdG1vZGVsJz5bSSYjODIwOTtELmlldGYmIzgyMDk7b2F1dGgm IzgyMDk7djImIzgyMDk7dGhyZWF0bW9kZWxdPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2lu Zm8nPkxvZGRlcnN0ZWR0LCBULiwgTWNHbG9pbiwgTS4sIGFuZCBQLiBIdW50LCAmbGRxdW87T0F1 dGggMi4wIFRocmVhdCBNb2RlbCBhbmQgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMsJnJkcXVvOyBN YXkmbmJzcDsyMDEyLjwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4uCiAgICAgIAo8L3A+CjxhIG5h bWU9ImFuY2hvcjM0Ij48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNl bGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0 Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwv YT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uMTAuMSI+PC9hPjxoMz4x MC4xLiZuYnNwOwpDbGllbnQgQXV0aGVudGljYXRpb248L2gzPgoKPHA+CiAgICAgICAgICBUaGUg YXV0aG9yaXphdGlvbiBzZXJ2ZXIgZXN0YWJsaXNoZXMgY2xpZW50IGNyZWRlbnRpYWxzIHdpdGgg d2ViIGFwcGxpY2F0aW9uIGNsaWVudHMgZm9yCiAgICAgICAgICB0aGUgcHVycG9zZSBvZiBjbGll bnQgYXV0aGVudGljYXRpb24uIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBpcyBlbmNvdXJhZ2Vk IHRvIGNvbnNpZGVyCiAgICAgICAgICBzdHJvbmdlciBjbGllbnQgYXV0aGVudGljYXRpb24gbWVh bnMgdGhhbiBhIGNsaWVudCBwYXNzd29yZC4gV2ViIGFwcGxpY2F0aW9uIGNsaWVudHMgTVVTVAog ICAgICAgICAgZW5zdXJlIGNvbmZpZGVudGlhbGl0eSBvZiBjbGllbnQgcGFzc3dvcmRzIGFuZCBv dGhlciBjbGllbnQgY3JlZGVudGlhbHMuCiAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICBUaGUg YXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVTVCBOT1QgaXNzdWUgY2xpZW50IHBhc3N3b3JkcyBvciBv dGhlciBjbGllbnQgY3JlZGVudGlhbHMgdG8KICAgICAgICAgIG5hdGl2ZSBhcHBsaWNhdGlvbiBv ciB1c2VyLWFnZW50LWJhc2VkIGFwcGxpY2F0aW9uIGNsaWVudHMgZm9yIHRoZSBwdXJwb3NlIG9m IGNsaWVudAogICAgICAgICAgYXV0aGVudGljYXRpb24uIFRoZSBhdXRob3JpemF0aW9uIHNlcnZl ciBNQVkgaXNzdWUgYSBjbGllbnQgcGFzc3dvcmQgb3Igb3RoZXIgY3JlZGVudGlhbHMKICAgICAg ICAgIGZvciBhIHNwZWNpZmljIGluc3RhbGxhdGlvbiBvZiBhIG5hdGl2ZSBhcHBsaWNhdGlvbiBj bGllbnQgb24gYSBzcGVjaWZpYyBkZXZpY2UuCiAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICBX aGVuIGNsaWVudCBhdXRoZW50aWNhdGlvbiBpcyBub3QgcG9zc2libGUsIHRoZSBhdXRob3JpemF0 aW9uIHNlcnZlciBTSE9VTEQgZW1wbG95IG90aGVyCiAgICAgICAgICBtZWFucyB0byB2YWxpZGF0 ZSB0aGUgY2xpZW50J3MgaWRlbnRpdHkuIEZvciBleGFtcGxlLCBieSByZXF1aXJpbmcgdGhlIHJl Z2lzdHJhdGlvbiBvZgogICAgICAgICAgdGhlIGNsaWVudCByZWRpcmVjdGlvbiBVUkkgb3IgZW5s aXN0aW5nIHRoZSByZXNvdXJjZSBvd25lciB0byBjb25maXJtIGlkZW50aXR5LiBBIHZhbGlkCiAg ICAgICAgICByZWRpcmVjdGlvbiBVUkkgaXMgbm90IHN1ZmZpY2llbnQgdG8gdmVyaWZ5IHRoZSBj bGllbnQncyBpZGVudGl0eSB3aGVuIGFza2luZyBmb3IKICAgICAgICAgIHJlc291cmNlIG93bmVy IGF1dGhvcml6YXRpb24sIGJ1dCBjYW4gYmUgdXNlZCB0byBwcmV2ZW50IGRlbGl2ZXJpbmcgY3Jl ZGVudGlhbHMgdG8gYQogICAgICAgICAgY291bnRlcmZlaXQgY2xpZW50IGFmdGVyIG9idGFpbmlu ZyByZXNvdXJjZSBvd25lciBhdXRob3JpemF0aW9uLgogICAgICAgIAo8L3A+CjxwPgogICAgICAg ICAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIG11c3QgY29uc2lkZXIgdGhlIHNlY3VyaXR5IGlt cGxpY2F0aW9ucyBvZiBpbnRlcmFjdGluZyB3aXRoCiAgICAgICAgICB1bmF1dGhlbnRpY2F0ZWQg Y2xpZW50cyBhbmQgdGFrZSBtZWFzdXJlcyB0byBsaW1pdCB0aGUgcG90ZW50aWFsIGV4cG9zdXJl IG9mIG90aGVyCiAgICAgICAgICBjcmVkZW50aWFscyAoZS5nLiByZWZyZXNoIHRva2VucykgaXNz dWVkIHRvIHN1Y2ggY2xpZW50cy4KICAgICAgICAKPC9wPgo8YSBuYW1lPSJhbmNob3IzNSI+PC9h PjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2Vs bHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0i VE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFi bGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLjEwLjIiPjwvYT48aDM+MTAuMi4mbmJzcDsKQ2xpZW50 IEltcGVyc29uYXRpb248L2gzPgoKPHA+CiAgICAgICAgICBBIG1hbGljaW91cyBjbGllbnQgY2Fu IGltcGVyc29uYXRlIGFub3RoZXIgY2xpZW50IGFuZCBvYnRhaW4gYWNjZXNzIHRvIHByb3RlY3Rl ZAogICAgICAgICAgcmVzb3VyY2VzLCBpZiB0aGUgaW1wZXJzb25hdGVkIGNsaWVudCBmYWlscyB0 bywgb3IgaXMgdW5hYmxlIHRvLCBrZWVwIGl0cyBjbGllbnQKICAgICAgICAgIGNyZWRlbnRpYWxz IGNvbmZpZGVudGlhbC4KICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgIFRoZSBhdXRob3JpemF0 aW9uIHNlcnZlciBNVVNUIGF1dGhlbnRpY2F0ZSB0aGUgY2xpZW50IHdoZW5ldmVyIHBvc3NpYmxl LiBJZiB0aGUKICAgICAgICAgIGF1dGhvcml6YXRpb24gc2VydmVyIGNhbm5vdCBhdXRoZW50aWNh dGUgdGhlIGNsaWVudCBkdWUgdG8gdGhlIGNsaWVudCdzIG5hdHVyZSwgdGhlCiAgICAgICAgICBh dXRob3JpemF0aW9uIHNlcnZlciBNVVNUIHJlcXVpcmUgdGhlIHJlZ2lzdHJhdGlvbiBvZiBhbnkg cmVkaXJlY3Rpb24gVVJJIHVzZWQgZm9yCiAgICAgICAgICByZWNlaXZpbmcgYXV0aG9yaXphdGlv biByZXNwb25zZXMsIGFuZCBTSE9VTEQgdXRpbGl6ZSBvdGhlciBtZWFucyB0byBwcm90ZWN0IHJl c291cmNlCiAgICAgICAgICBvd25lcnMgZnJvbSBzdWNoIHBvdGVudGlhbGx5IG1hbGljaW91cyBj bGllbnRzLiBGb3IgZXhhbXBsZSwgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyCiAgICAgICAgICBj YW4gZW5nYWdlIHRoZSByZXNvdXJjZSBvd25lciB0byBhc3Npc3QgaW4gaWRlbnRpZnlpbmcgdGhl IGNsaWVudCBhbmQgaXRzIG9yaWdpbi4KICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgIFRoZSBh dXRob3JpemF0aW9uIHNlcnZlciBTSE9VTEQgZW5mb3JjZSBleHBsaWNpdCByZXNvdXJjZSBvd25l ciBhdXRoZW50aWNhdGlvbiBhbmQKICAgICAgICAgIHByb3ZpZGUgdGhlIHJlc291cmNlIG93bmVy IHdpdGggaW5mb3JtYXRpb24gYWJvdXQgdGhlIGNsaWVudCBhbmQgdGhlIHJlcXVlc3RlZAogICAg ICAgICAgYXV0aG9yaXphdGlvbiBzY29wZSBhbmQgbGlmZXRpbWUuIEl0IGlzIHVwIHRvIHRoZSBy ZXNvdXJjZSBvd25lciB0byByZXZpZXcgdGhlCiAgICAgICAgICBpbmZvcm1hdGlvbiBpbiB0aGUg Y29udGV4dCBvZiB0aGUgY3VycmVudCBjbGllbnQsIGFuZCBhdXRob3JpemUgb3IgZGVueSB0aGUg cmVxdWVzdC4KICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgIFRoZSBhdXRob3JpemF0aW9uIHNl cnZlciBTSE9VTEQgTk9UIHByb2Nlc3MgcmVwZWF0ZWQgYXV0aG9yaXphdGlvbiByZXF1ZXN0cwog ICAgICAgICAgYXV0b21hdGljYWxseSAod2l0aG91dCBhY3RpdmUgcmVzb3VyY2Ugb3duZXIgaW50 ZXJhY3Rpb24pIHdpdGhvdXQgYXV0aGVudGljYXRpbmcgdGhlCiAgICAgICAgICBjbGllbnQgb3Ig cmVseWluZyBvbiBvdGhlciBtZWFzdXJlcyB0byBlbnN1cmUgdGhlIHJlcGVhdGVkIHJlcXVlc3Qg Y29tZXMgZnJvbSB0aGUKICAgICAgICAgIG9yaWdpbmFsIGNsaWVudCBhbmQgbm90IGFuIGltcGVy c29uYXRvci4KICAgICAgICAKPC9wPgo8YSBuYW1lPSJhbmNob3IzNiI+PC9hPjxiciAvPjxociAv Pgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIi IGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBo cmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9 InJmYy5zZWN0aW9uLjEwLjMiPjwvYT48aDM+MTAuMy4mbmJzcDsKQWNjZXNzIFRva2VuczwvaDM+ Cgo8cD4KICAgICAgICAgIEFjY2VzcyB0b2tlbiBjcmVkZW50aWFscyAoYXMgd2VsbCBhcyBhbnkg Y29uZmlkZW50aWFsIGFjY2VzcyB0b2tlbiBhdHRyaWJ1dGVzKSBNVVNUIGJlCiAgICAgICAgICBr ZXB0IGNvbmZpZGVudGlhbCBpbiB0cmFuc2l0IGFuZCBzdG9yYWdlLCBhbmQgb25seSBzaGFyZWQg YW1vbmcgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLAogICAgICAgICAgdGhlIHJlc291cmNlIHNl cnZlcnMgdGhlIGFjY2VzcyB0b2tlbiBpcyB2YWxpZCBmb3IsIGFuZCB0aGUgY2xpZW50IHRvIHdo b20gdGhlIGFjY2VzcwogICAgICAgICAgdG9rZW4gaXMgaXNzdWVkLiBBY2Nlc3MgdG9rZW4gY3Jl ZGVudGlhbHMgTVVTVCBvbmx5IGJlIHRyYW5zbWl0dGVkIHVzaW5nIFRMUyBhcyBkZXNjcmliZWQK ICAgICAgICAgIGluIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjdGxzJz5TZWN0aW9uJm5ic3A7MS42 PHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPlRMUyBWZXJzaW9uPC9zcGFuPjxzcGFu Pik8L3NwYW4+PC9hPiB3aXRoIHNlcnZlciBhdXRoZW50aWNhdGlvbiBhcyBkZWZpbmVkIGJ5CiAg ICAgICAgICA8YSBjbGFzcz0naW5mbycgaHJlZj0nI1JGQzI4MTgnPltSRkMyODE4XTxzcGFuPiAo PC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5SZXNjb3JsYSwgRS4sICZsZHF1bztIVFRQIE92ZXIg VExTLCZyZHF1bzsgTWF5Jm5ic3A7MjAwMC48L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+LgogICAg ICAgIAo8L3A+CjxwPgogICAgICAgICAgV2hlbiB1c2luZyB0aGUgaW1wbGljaXQgZ3JhbnQgdHlw ZSwgdGhlIGFjY2VzcyB0b2tlbiBpcyB0cmFuc21pdHRlZCBpbiB0aGUgVVJJIGZyYWdtZW50LAog ICAgICAgICAgd2hpY2ggY2FuIGV4cG9zZSBpdCB0byB1bmF1dGhvcml6ZWQgcGFydGllcy4KICAg ICAgICAKPC9wPgo8cD4KICAgICAgICAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBNVVNUIGVu c3VyZSB0aGF0IGFjY2VzcyB0b2tlbnMgY2Fubm90IGJlIGdlbmVyYXRlZCwgbW9kaWZpZWQsIG9y CiAgICAgICAgICBndWVzc2VkIHRvIHByb2R1Y2UgdmFsaWQgYWNjZXNzIHRva2VucyBieSB1bmF1 dGhvcml6ZWQgcGFydGllcy4KICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgIFRoZSBjbGllbnQg U0hPVUxEIHJlcXVlc3QgYWNjZXNzIHRva2VucyB3aXRoIHRoZSBtaW5pbWFsIHNjb3BlIG5lY2Vz c2FyeS4gVGhlCiAgICAgICAgICBhdXRob3JpemF0aW9uIHNlcnZlciBTSE9VTEQgdGFrZSB0aGUg Y2xpZW50IGlkZW50aXR5IGludG8gYWNjb3VudCB3aGVuIGNob29zaW5nIGhvdwogICAgICAgICAg dG8gaG9ub3IgdGhlIHJlcXVlc3RlZCBzY29wZSwgYW5kIE1BWSBpc3N1ZSBhbiBhY2Nlc3MgdG9r ZW4gd2l0aCBhIGxlc3MgcmlnaHRzIHRoYW4KICAgICAgICAgIHJlcXVlc3RlZC4KICAgICAgICAK PC9wPgo8cD4KICAgICAgICAgIFRoaXMgc3BlY2lmaWNhdGlvbiBkb2VzIG5vdCBwcm92aWRlIGFu eSBtZXRob2RzIGZvciB0aGUgcmVzb3VyY2Ugc2VydmVyIHRvIGVuc3VyZSB0aGF0IGFuCiAgICAg ICAgICBhY2Nlc3MgdG9rZW4gcHJlc2VudGVkIHRvIGl0IGJ5IGEgZ2l2ZW4gY2xpZW50IHdhcyBp c3N1ZWQgdG8gdGhhdCBjbGllbnQgYnkgdGhlCiAgICAgICAgICBhdXRob3JpemF0aW9uIHNlcnZl ci4KICAgICAgICAKPC9wPgo8YSBuYW1lPSJhbmNob3IzNyI+PC9hPjxiciAvPjxociAvPgo8dGFi bGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNz PSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIj dG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5z ZWN0aW9uLjEwLjQiPjwvYT48aDM+MTAuNC4mbmJzcDsKUmVmcmVzaCBUb2tlbnM8L2gzPgoKPHA+ CiAgICAgICAgICBBdXRob3JpemF0aW9uIHNlcnZlcnMgTUFZIGlzc3VlIHJlZnJlc2ggdG9rZW5z IHRvIHdlYiBhcHBsaWNhdGlvbiBjbGllbnRzIGFuZCBuYXRpdmUKICAgICAgICAgIGFwcGxpY2F0 aW9uIGNsaWVudHMuCiAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICBSZWZyZXNoIHRva2VucyBN VVNUIGJlIGtlcHQgY29uZmlkZW50aWFsIGluIHRyYW5zaXQgYW5kIHN0b3JhZ2UsIGFuZCBzaGFy ZWQgb25seSBhbW9uZwogICAgICAgICAgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGFuZCB0aGUg Y2xpZW50IHRvIHdob20gdGhlIHJlZnJlc2ggdG9rZW5zIHdlcmUgaXNzdWVkLiBUaGUKICAgICAg ICAgIGF1dGhvcml6YXRpb24gc2VydmVyIE1VU1QgbWFpbnRhaW4gdGhlIGJpbmRpbmcgYmV0d2Vl biBhIHJlZnJlc2ggdG9rZW4gYW5kIHRoZSBjbGllbnQgdG8KICAgICAgICAgIHdob20gaXQgd2Fz IGlzc3VlZC4gUmVmcmVzaCB0b2tlbnMgTVVTVCBvbmx5IGJlIHRyYW5zbWl0dGVkIHVzaW5nIFRM UyBhcyBkZXNjcmliZWQgaW4KICAgICAgICAgIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjdGxzJz5T ZWN0aW9uJm5ic3A7MS42PHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPlRMUyBWZXJz aW9uPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPiB3aXRoIHNlcnZlciBhdXRoZW50aWNhdGlvbiBh cyBkZWZpbmVkIGJ5IDxhIGNsYXNzPSdpbmZvJyBocmVmPScjUkZDMjgxOCc+W1JGQzI4MThdPHNw YW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPlJlc2NvcmxhLCBFLiwgJmxkcXVvO0hUVFAg T3ZlciBUTFMsJnJkcXVvOyBNYXkmbmJzcDsyMDAwLjwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4u CiAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVT VCB2ZXJpZnkgdGhlIGJpbmRpbmcgYmV0d2VlbiB0aGUgcmVmcmVzaCB0b2tlbiBhbmQgY2xpZW50 CiAgICAgICAgICBpZGVudGl0eSB3aGVuZXZlciB0aGUgY2xpZW50IGlkZW50aXR5IGNhbiBiZSBh dXRoZW50aWNhdGVkLiBXaGVuIGNsaWVudCBhdXRoZW50aWNhdGlvbiBpcwogICAgICAgICAgbm90 IHBvc3NpYmxlLCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgU0hPVUxEIGRlcGxveSBvdGhlciBt ZWFucyB0byBkZXRlY3QgcmVmcmVzaCB0b2tlbgogICAgICAgICAgYWJ1c2UuCiAgICAgICAgCjwv cD4KPHA+CiAgICAgICAgICBGb3IgZXhhbXBsZSwgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGNv dWxkIGVtcGxveSByZWZyZXNoIHRva2VuIHJvdGF0aW9uIGluIHdoaWNoIGEgbmV3CiAgICAgICAg ICByZWZyZXNoIHRva2VuIGlzIGlzc3VlZCB3aXRoIGV2ZXJ5IGFjY2VzcyB0b2tlbiByZWZyZXNo IHJlc3BvbnNlLiBUaGUgcHJldmlvdXMgcmVmcmVzaAogICAgICAgICAgdG9rZW4gaXMgaW52YWxp ZGF0ZWQgYnV0IHJldGFpbmVkIGJ5IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlci4gSWYgYSByZWZy ZXNoIHRva2VuIGlzCiAgICAgICAgICBjb21wcm9taXNlZCBhbmQgc3Vic2VxdWVudGx5IHVzZWQg YnkgYm90aCB0aGUgYXR0YWNrZXIgYW5kIHRoZSBsZWdpdGltYXRlIGNsaWVudCwgb25lIG9mCiAg ICAgICAgICB0aGVtIHdpbGwgcHJlc2VudCBhbiBpbnZhbGlkYXRlZCByZWZyZXNoIHRva2VuIHdo aWNoIHdpbGwgaW5mb3JtIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlcgogICAgICAgICAgb2YgdGhl IGJyZWFjaC4KICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgIFRoZSBhdXRob3JpemF0aW9uIHNl cnZlciBNVVNUIGVuc3VyZSB0aGF0IHJlZnJlc2ggdG9rZW5zIGNhbm5vdCBiZSBnZW5lcmF0ZWQs IG1vZGlmaWVkLAogICAgICAgICAgb3IgZ3Vlc3NlZCB0byBwcm9kdWNlIHZhbGlkIHJlZnJlc2gg dG9rZW5zIGJ5IHVuYXV0aG9yaXplZCBwYXJ0aWVzLgogICAgICAgIAo8L3A+CjxhIG5hbWU9ImFu Y2hvcjM4Ij48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRk aW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+ PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3Rk PjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uMTAuNSI+PC9hPjxoMz4xMC41LiZu YnNwOwpBdXRob3JpemF0aW9uIENvZGVzPC9oMz4KCjxwPgogICAgICAgICAgVGhlIHRyYW5zbWlz c2lvbiBvZiBhdXRob3JpemF0aW9uIGNvZGVzIFNIT1VMRCBiZSBtYWRlIG92ZXIgYSBzZWN1cmUg Y2hhbm5lbCwgYW5kIHRoZQogICAgICAgICAgY2xpZW50IFNIT1VMRCByZXF1aXJlIHRoZSB1c2Ug b2YgVExTIHdpdGggaXRzIHJlZGlyZWN0aW9uIFVSSSBpZiB0aGUgVVJJIGlkZW50aWZpZXMgYQog ICAgICAgICAgbmV0d29yayByZXNvdXJjZS4gU2luY2UgYXV0aG9yaXphdGlvbiBjb2RlcyBhcmUg dHJhbnNtaXR0ZWQgdmlhIHVzZXItYWdlbnQgcmVkaXJlY3Rpb25zLAogICAgICAgICAgdGhleSBj b3VsZCBwb3RlbnRpYWxseSBiZSBkaXNjbG9zZWQgdGhyb3VnaCB1c2VyLWFnZW50IGhpc3Rvcnkg YW5kIEhUVFAgcmVmZXJyZXIgaGVhZGVycy4KICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgIEF1 dGhvcml6YXRpb24gY29kZXMgb3BlcmF0ZSBhcyBwbGFpbnRleHQgYmVhcmVyIGNyZWRlbnRpYWxz LCB1c2VkIHRvIHZlcmlmeSB0aGF0IHRoZQogICAgICAgICAgcmVzb3VyY2Ugb3duZXIgd2hvIGdy YW50ZWQgYXV0aG9yaXphdGlvbiBhdCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgaXMgdGhlIHNh bWUKICAgICAgICAgIHJlc291cmNlIG93bmVyIHJldHVybmluZyB0byB0aGUgY2xpZW50IHRvIGNv bXBsZXRlIHRoZSBwcm9jZXNzLiBUaGVyZWZvcmUsIGlmIHRoZSBjbGllbnQKICAgICAgICAgIHJl bGllcyBvbiB0aGUgYXV0aG9yaXphdGlvbiBjb2RlIGZvciBpdHMgb3duIHJlc291cmNlIG93bmVy IGF1dGhlbnRpY2F0aW9uLCB0aGUgY2xpZW50CiAgICAgICAgICByZWRpcmVjdGlvbiBlbmRwb2lu dCBNVVNUIHJlcXVpcmUgdGhlIHVzZSBvZiBUTFMuCiAgICAgICAgCjwvcD4KPHA+CiAgICAgICAg ICBBdXRob3JpemF0aW9uIGNvZGVzIE1VU1QgYmUgc2hvcnQgbGl2ZWQgYW5kIHNpbmdsZSB1c2Uu IElmIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlcgogICAgICAgICAgb2JzZXJ2ZXMgbXVsdGlwbGUg YXR0ZW1wdHMgdG8gZXhjaGFuZ2UgYW4gYXV0aG9yaXphdGlvbiBjb2RlIGZvciBhbiBhY2Nlc3Mg dG9rZW4sIHRoZQogICAgICAgICAgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgU0hPVUxEIGF0dGVtcHQg dG8gcmV2b2tlIGFsbCBhY2Nlc3MgdG9rZW5zIGFscmVhZHkgZ3JhbnRlZCBiYXNlZCBvbgogICAg ICAgICAgdGhlIGNvbXByb21pc2VkIGF1dGhvcml6YXRpb24gY29kZS4KICAgICAgICAKPC9wPgo8 cD4KICAgICAgICAgIElmIHRoZSBjbGllbnQgY2FuIGJlIGF1dGhlbnRpY2F0ZWQsIHRoZSBhdXRo b3JpemF0aW9uIHNlcnZlcnMgTVVTVCBhdXRoZW50aWNhdGUgdGhlCiAgICAgICAgICBjbGllbnQg YW5kIGVuc3VyZSB0aGF0IHRoZSBhdXRob3JpemF0aW9uIGNvZGUgd2FzIGlzc3VlZCB0byB0aGUg c2FtZSBjbGllbnQuCiAgICAgICAgCjwvcD4KPGEgbmFtZT0iYW5jaG9yMzkiPjwvYT48YnIgLz48 aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5n PSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+ PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBu YW1lPSJyZmMuc2VjdGlvbi4xMC42Ij48L2E+PGgzPjEwLjYuJm5ic3A7CkF1dGhvcml6YXRpb24g Q29kZSBSZWRpcmVjdGlvbiBVUkkgTWFuaXB1bGF0aW9uPC9oMz4KCjxwPgogICAgICAgICAgV2hl biByZXF1ZXN0aW5nIGF1dGhvcml6YXRpb24gdXNpbmcgdGhlIGF1dGhvcml6YXRpb24gY29kZSBn cmFudCB0eXBlLCB0aGUgY2xpZW50IGNhbgogICAgICAgICAgc3BlY2lmeSBhIHJlZGlyZWN0aW9u IFVSSSB2aWEgdGhlIDx0dD5yZWRpcmVjdF91cmk8L3R0PiBwYXJhbWV0ZXIuCiAgICAgICAgICBJ ZiBhbiBhdHRhY2tlciBjYW4gbWFuaXB1bGF0ZSB0aGUgdmFsdWUgb2YgdGhlIHJlZGlyZWN0aW9u IFVSSSwgaXQgY2FuIGNhdXNlIHRoZQogICAgICAgICAgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgdG8g cmVkaXJlY3QgdGhlIHJlc291cmNlIG93bmVyIHVzZXItYWdlbnQgdG8gYSBVUkkgdW5kZXIgdGhl IGNvbnRyb2wKICAgICAgICAgIG9mIHRoZSBhdHRhY2tlciB3aXRoIHRoZSBhdXRob3JpemF0aW9u IGNvZGUuCiAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICBBbiBhdHRhY2tlciBjYW4gY3JlYXRl IGFuIGFjY291bnQgYXQgYSBsZWdpdGltYXRlIGNsaWVudCBhbmQgaW5pdGlhdGUgdGhlIGF1dGhv cml6YXRpb24KICAgICAgICAgIGZsb3cuIFdoZW4gdGhlIGF0dGFja2VyJ3MgdXNlci1hZ2VudCBp cyBzZW50IHRvIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciB0byBncmFudCBhY2Nlc3MsCiAgICAg ICAgICB0aGUgYXR0YWNrZXIgZ3JhYnMgdGhlIGF1dGhvcml6YXRpb24gVVJJIHByb3ZpZGVkIGJ5 IHRoZSBsZWdpdGltYXRlIGNsaWVudCwgYW5kIHJlcGxhY2VzCiAgICAgICAgICB0aGUgY2xpZW50 J3MgcmVkaXJlY3Rpb24gVVJJIHdpdGggYSBVUkkgdW5kZXIgdGhlIGNvbnRyb2wgb2YgdGhlIGF0 dGFja2VyLiBUaGUgYXR0YWNrZXIKICAgICAgICAgIHRoZW4gdHJpY2tzIHRoZSB2aWN0aW0gaW50 byBmb2xsb3dpbmcgdGhlIG1hbmlwdWxhdGVkIGxpbmsgdG8gYXV0aG9yaXplIGFjY2VzcyB0byB0 aGUKICAgICAgICAgIGxlZ2l0aW1hdGUgY2xpZW50LgogICAgICAgIAo8L3A+CjxwPgogICAgICAg ICAgT25jZSBhdCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIsIHRoZSB2aWN0aW0gaXMgcHJvbXB0 ZWQgd2l0aCBhIG5vcm1hbCwgdmFsaWQgcmVxdWVzdCBvbgogICAgICAgICAgYmVoYWxmIG9mIGEg bGVnaXRpbWF0ZSBhbmQgdHJ1c3RlZCBjbGllbnQsIGFuZCBhdXRob3JpemVzIHRoZSByZXF1ZXN0 LiBUaGUgdmljdGltIGlzCiAgICAgICAgICB0aGVuIHJlZGlyZWN0ZWQgdG8gYW4gZW5kcG9pbnQg dW5kZXIgdGhlIGNvbnRyb2wgb2YgdGhlIGF0dGFja2VyIHdpdGggdGhlIGF1dGhvcml6YXRpb24K ICAgICAgICAgIGNvZGUuIFRoZSBhdHRhY2tlciBjb21wbGV0ZXMgdGhlIGF1dGhvcml6YXRpb24g ZmxvdyBieSBzZW5kaW5nIHRoZSBhdXRob3JpemF0aW9uIGNvZGUgdG8KICAgICAgICAgIHRoZSBj bGllbnQgdXNpbmcgdGhlIG9yaWdpbmFsIHJlZGlyZWN0aW9uIFVSSSBwcm92aWRlZCBieSB0aGUg Y2xpZW50LiBUaGUgY2xpZW50CiAgICAgICAgICBleGNoYW5nZXMgdGhlIGF1dGhvcml6YXRpb24g Y29kZSB3aXRoIGFuIGFjY2VzcyB0b2tlbiBhbmQgbGlua3MgaXQgdG8gdGhlIGF0dGFja2VyJ3MK ICAgICAgICAgIGNsaWVudCBhY2NvdW50IHdoaWNoIGNhbiBub3cgZ2FpbiBhY2Nlc3MgdG8gdGhl IHByb3RlY3RlZCByZXNvdXJjZXMgYXV0aG9yaXplZCBieSB0aGUKICAgICAgICAgIHZpY3RpbSAo dmlhIHRoZSBjbGllbnQpLgogICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgSW4gb3JkZXIgdG8g cHJldmVudCBzdWNoIGFuIGF0dGFjaywgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIE1VU1QgZW5z dXJlIHRoYXQgdGhlCiAgICAgICAgICByZWRpcmVjdGlvbiBVUkkgdXNlZCB0byBvYnRhaW4gdGhl IGF1dGhvcml6YXRpb24gY29kZSBpcyBpZGVudGljYWwgdG8gdGhlIHJlZGlyZWN0aW9uIFVSSQog ICAgICAgICAgcHJvdmlkZWQgd2hlbiBleGNoYW5naW5nIHRoZSBhdXRob3JpemF0aW9uIGNvZGUg Zm9yIGFuIGFjY2VzcyB0b2tlbi4gVGhlIGF1dGhvcml6YXRpb24KICAgICAgICAgIHNlcnZlciBN VVNUIHJlcXVpcmUgcHVibGljIGNsaWVudHMgYW5kIFNIT1VMRCByZXF1aXJlIGNvbmZpZGVudGlh bCBjbGllbnRzIHRvIHJlZ2lzdGVyCiAgICAgICAgICB0aGVpciByZWRpcmVjdGlvbiBVUklzLiBJ ZiBhIHJlZGlyZWN0aW9uIFVSSSBpcyBwcm92aWRlZCBpbiB0aGUgcmVxdWVzdCwgdGhlCiAgICAg ICAgICBhdXRob3JpemF0aW9uIHNlcnZlciBNVVNUIHZhbGlkYXRlIGl0IGFnYWluc3QgdGhlIHJl Z2lzdGVyZWQgdmFsdWUuCiAgICAgICAgCjwvcD4KPGEgbmFtZT0iYW5jaG9yNDAiPjwvYT48YnIg Lz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFj aW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1 ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8 YSBuYW1lPSJyZmMuc2VjdGlvbi4xMC43Ij48L2E+PGgzPjEwLjcuJm5ic3A7ClJlc291cmNlIE93 bmVyIFBhc3N3b3JkIENyZWRlbnRpYWxzPC9oMz4KCjxwPgogICAgICAgICAgVGhlIHJlc291cmNl IG93bmVyIHBhc3N3b3JkIGNyZWRlbnRpYWxzIGdyYW50IHR5cGUgaXMgb2Z0ZW4gdXNlZCBmb3Ig bGVnYWN5IG9yIG1pZ3JhdGlvbgogICAgICAgICAgcmVhc29ucy4gSXQgcmVkdWNlcyB0aGUgb3Zl cmFsbCByaXNrIG9mIHN0b3JpbmcgdXNlcm5hbWUgYW5kIHBhc3N3b3JkIGJ5IHRoZSBjbGllbnQs IGJ1dAogICAgICAgICAgZG9lcyBub3QgZWxpbWluYXRlIHRoZSBuZWVkIHRvIGV4cG9zZSBoaWdo bHkgcHJpdmlsZWdlZCBjcmVkZW50aWFscyB0byB0aGUgY2xpZW50LgogICAgICAgIAo8L3A+Cjxw PgogICAgICAgICAgVGhpcyBncmFudCB0eXBlIGNhcnJpZXMgYSBoaWdoZXIgcmlzayB0aGFuIG90 aGVyIGdyYW50IHR5cGVzIGJlY2F1c2UgaXQgbWFpbnRhaW5zIHRoZQogICAgICAgICAgcGFzc3dv cmQgYW50aS1wYXR0ZXJuIHRoaXMgcHJvdG9jb2wgc2Vla3MgdG8gYXZvaWQuIFRoZSBjbGllbnQg Y291bGQgYWJ1c2UgdGhlIHBhc3N3b3JkCiAgICAgICAgICBvciB0aGUgcGFzc3dvcmQgY291bGQg dW5pbnRlbnRpb25hbGx5IGJlIGRpc2Nsb3NlZCB0byBhbiBhdHRhY2tlciAoZS5nLiB2aWEgbG9n IGZpbGVzIG9yCiAgICAgICAgICBvdGhlciByZWNvcmRzIGtlcHQgYnkgdGhlIGNsaWVudCkuCiAg ICAgICAgCjwvcD4KPHA+CiAgICAgICAgICBBZGRpdGlvbmFsbHksIGJlY2F1c2UgdGhlIHJlc291 cmNlIG93bmVyIGRvZXMgbm90IGhhdmUgY29udHJvbCBvdmVyIHRoZSBhdXRob3JpemF0aW9uCiAg ICAgICAgICBwcm9jZXNzICh0aGUgcmVzb3VyY2Ugb3duZXIgaW52b2x2ZW1lbnQgZW5kcyB3aGVu IGl0IGhhbmRzIG92ZXIgaXRzIGNyZWRlbnRpYWxzIHRvIHRoZQogICAgICAgICAgY2xpZW50KSwg dGhlIGNsaWVudCBjYW4gb2J0YWluIGFjY2VzcyB0b2tlbnMgd2l0aCBhIGJyb2FkZXIgc2NvcGUg dGhhbiBkZXNpcmVkIGJ5IHRoZQogICAgICAgICAgcmVzb3VyY2Ugb3duZXIuIFRoZSBhdXRob3Jp emF0aW9uIHNlcnZlciBzaG91bGQgY29uc2lkZXIgdGhlIHNjb3BlIGFuZCBsaWZldGltZSBvZgog ICAgICAgICAgYWNjZXNzIHRva2VucyBpc3N1ZWQgdmlhIHRoaXMgZ3JhbnQgdHlwZS4KICAgICAg ICAKPC9wPgo8cD4KICAgICAgICAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBhbmQgY2xpZW50 IFNIT1VMRCBtaW5pbWl6ZSB1c2Ugb2YgdGhpcyBncmFudCB0eXBlIGFuZCB1dGlsaXplCiAgICAg ICAgICBvdGhlciBncmFudCB0eXBlcyB3aGVuZXZlciBwb3NzaWJsZS4KICAgICAgICAKPC9wPgo8 YSBuYW1lPSJhbmNob3I0MSI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0 IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJy aWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJz cDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLjEwLjgiPjwvYT48 aDM+MTAuOC4mbmJzcDsKUmVxdWVzdCBDb25maWRlbnRpYWxpdHk8L2gzPgoKPHA+CiAgICAgICAg ICBBY2Nlc3MgdG9rZW5zLCByZWZyZXNoIHRva2VucywgcmVzb3VyY2Ugb3duZXIgcGFzc3dvcmRz LCBhbmQgY2xpZW50IGNyZWRlbnRpYWxzIE1VU1QgTk9UCiAgICAgICAgICBiZSB0cmFuc21pdHRl ZCBpbiB0aGUgY2xlYXIuIEF1dGhvcml6YXRpb24gY29kZXMgU0hPVUxEIE5PVCBiZSB0cmFuc21p dHRlZCBpbiB0aGUgY2xlYXIuCiAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICBUaGUgPHR0PnN0 YXRlPC90dD4gYW5kIDx0dD5zY29wZTwvdHQ+IHBhcmFtZXRlcnMKICAgICAgICAgIFNIT1VMRCBO T1QgaW5jbHVkZSBzZW5zaXRpdmUgY2xpZW50IG9yIHJlc291cmNlIG93bmVyIGluZm9ybWF0aW9u IGluIHBsYWluIHRleHQgYXMgdGhleQogICAgICAgICAgY2FuIGJlIHRyYW5zbWl0dGVkIG92ZXIg aW5zZWN1cmUgY2hhbm5lbHMgb3Igc3RvcmVkIGluc2VjdXJlbHkuCiAgICAgICAgCjwvcD4KPGEg bmFtZT0iYW5jaG9yNDIiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIg Y2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmln aHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7 PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi4xMC45Ij48L2E+PGgz PjEwLjkuJm5ic3A7CkVuZHBvaW50cyBBdXRoZW50aWNpdHk8L2gzPgoKPHA+CiAgICAgICAgICBJ biBvcmRlciB0byBwcmV2ZW50IG1hbi1pbi10aGUtbWlkZGxlIGF0dGFja3MsIHRoZSBhdXRob3Jp emF0aW9uIHNlcnZlciBNVVNUIHJlcXVpcmUgdGhlCiAgICAgICAgICB1c2Ugb2YgVExTIHdpdGgg c2VydmVyIGF1dGhlbnRpY2F0aW9uIGFzIGRlZmluZWQgYnkgPGEgY2xhc3M9J2luZm8nIGhyZWY9 JyNSRkMyODE4Jz5bUkZDMjgxOF08c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+UmVz Y29ybGEsIEUuLCAmbGRxdW87SFRUUCBPdmVyIFRMUywmcmRxdW87IE1heSZuYnNwOzIwMDAuPC9z cGFuPjxzcGFuPik8L3NwYW4+PC9hPiBmb3IKICAgICAgICAgIGFueSByZXF1ZXN0IHNlbnQgdG8g dGhlIGF1dGhvcml6YXRpb24gYW5kIHRva2VuIGVuZHBvaW50cy4gVGhlIGNsaWVudCBNVVNUIHZh bGlkYXRlIHRoZQogICAgICAgICAgYXV0aG9yaXphdGlvbiBzZXJ2ZXIncyBUTFMgY2VydGlmaWNh dGUgYXMgZGVmaW5lZCBieSA8YSBjbGFzcz0naW5mbycgaHJlZj0nI1JGQzYxMjUnPltSRkM2MTI1 XTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5TYWludC1BbmRyZSwgUC4gYW5kIEou IEhvZGdlcywgJmxkcXVvO1JlcHJlc2VudGF0aW9uIGFuZCBWZXJpZmljYXRpb24gb2YgRG9tYWlu LUJhc2VkIEFwcGxpY2F0aW9uIFNlcnZpY2UgSWRlbnRpdHkgd2l0aGluIEludGVybmV0IFB1Ymxp YyBLZXkgSW5mcmFzdHJ1Y3R1cmUgVXNpbmcgWC41MDkgKFBLSVgpIENlcnRpZmljYXRlcyBpbiB0 aGUgQ29udGV4dCBvZiBUcmFuc3BvcnQgTGF5ZXIgU2VjdXJpdHkgKFRMUyksJnJkcXVvOyBNYXJj aCZuYnNwOzIwMTEuPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPiwgYW5kIGluCiAgICAgICAgICBh Y2NvcmRhbmNlIHdpdGggaXRzIHJlcXVpcmVtZW50cyBmb3Igc2VydmVyIGlkZW50aXR5IGF1dGhl bnRpY2F0aW9uLgogICAgICAgIAo8L3A+CjxhIG5hbWU9ImFudGhyb3B5Ij48L2E+PGJyIC8+PGhy IC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0i MiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxh IGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFt ZT0icmZjLnNlY3Rpb24uMTAuMTAiPjwvYT48aDM+MTAuMTAuJm5ic3A7CkNyZWRlbnRpYWxzIEd1 ZXNzaW5nIEF0dGFja3M8L2gzPgoKPHA+CiAgICAgICAgICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2 ZXIgTVVTVCBwcmV2ZW50IGF0dGFja2VycyBmcm9tIGd1ZXNzaW5nIGFjY2VzcyB0b2tlbnMsCiAg ICAgICAgICBhdXRob3JpemF0aW9uIGNvZGVzLCByZWZyZXNoIHRva2VucywgcmVzb3VyY2Ugb3du ZXIgcGFzc3dvcmRzLCBhbmQgY2xpZW50IGNyZWRlbnRpYWxzLgogICAgICAgIAo8L3A+CjxwPgog ICAgICAgICAgVGhlIHByb2JhYmlsaXR5IG9mIGFuIGF0dGFja2VyIGd1ZXNzaW5nIGdlbmVyYXRl ZCB0b2tlbnMgKGFuZCBvdGhlciBjcmVkZW50aWFscyBub3QKICAgICAgICAgIGludGVuZGVkIGZv ciBoYW5kbGluZyBieSBlbmQtdXNlcnMpIE1VU1QgYmUgbGVzcyB0aGFuIG9yIGVxdWFsIHRvIDJe KC0xMjgpIGFuZCBTSE9VTEQgYmUKICAgICAgICAgIGxlc3MgdGhhbiBvciBlcXVhbCB0byAyXigt MTYwKS4KICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZl ciBNVVNUIHV0aWxpemUgb3RoZXIgbWVhbnMgdG8gcHJvdGVjdCBjcmVkZW50aWFscyBpbnRlbmRl ZCBmb3IKICAgICAgICAgIGVuZC11c2VyIHVzYWdlLgogICAgICAgIAo8L3A+CjxhIG5hbWU9ImFu Y2hvcjQzIj48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRk aW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+ PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3Rk PjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uMTAuMTEiPjwvYT48aDM+MTAuMTEu Jm5ic3A7ClBoaXNoaW5nIEF0dGFja3M8L2gzPgoKPHA+CiAgICAgICAgICBXaWRlIGRlcGxveW1l bnQgb2YgdGhpcyBhbmQgc2ltaWxhciBwcm90b2NvbHMgbWF5IGNhdXNlIGVuZC11c2VycyB0byBi ZWNvbWUgaW51cmVkCiAgICAgICAgICB0byB0aGUgcHJhY3RpY2Ugb2YgYmVpbmcgcmVkaXJlY3Rl ZCB0byB3ZWJzaXRlcyB3aGVyZSB0aGV5IGFyZSBhc2tlZCB0byBlbnRlciB0aGVpcgogICAgICAg ICAgcGFzc3dvcmRzLiBJZiBlbmQtdXNlcnMgYXJlIG5vdCBjYXJlZnVsIHRvIHZlcmlmeSB0aGUg YXV0aGVudGljaXR5IG9mIHRoZXNlIHdlYnNpdGVzCiAgICAgICAgICBiZWZvcmUgZW50ZXJpbmcg dGhlaXIgY3JlZGVudGlhbHMsIGl0IHdpbGwgYmUgcG9zc2libGUgZm9yIGF0dGFja2VycyB0byBl eHBsb2l0IHRoaXMKICAgICAgICAgIHByYWN0aWNlIHRvIHN0ZWFsIHJlc291cmNlIG93bmVycycg cGFzc3dvcmRzLgogICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgU2VydmljZSBwcm92aWRlcnMg c2hvdWxkIGF0dGVtcHQgdG8gZWR1Y2F0ZSBlbmQtdXNlcnMgYWJvdXQgdGhlIHJpc2tzIHBoaXNo aW5nIGF0dGFja3MKICAgICAgICAgIHBvc2UsIGFuZCBzaG91bGQgcHJvdmlkZSBtZWNoYW5pc21z IHRoYXQgbWFrZSBpdCBlYXN5IGZvciBlbmQtdXNlcnMgdG8gY29uZmlybSB0aGUKICAgICAgICAg IGF1dGhlbnRpY2l0eSBvZiB0aGVpciBzaXRlcy4gQ2xpZW50IGRldmVsb3BlcnMgc2hvdWxkIGNv bnNpZGVyIHRoZSBzZWN1cml0eSBpbXBsaWNhdGlvbnMKICAgICAgICAgIG9mIGhvdyB0aGV5IGlu dGVyYWN0IHdpdGggdGhlIHVzZXItYWdlbnQgKGUuZy4sIGV4dGVybmFsLCBlbWJlZGRlZCksIGFu ZCB0aGUgYWJpbGl0eSBvZgogICAgICAgICAgdGhlIGVuZC11c2VyIHRvIHZlcmlmeSB0aGUgYXV0 aGVudGljaXR5IG9mIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlci4KICAgICAgICAKPC9wPgo8cD4K ICAgICAgICAgIFRvIHJlZHVjZSB0aGUgcmlzayBvZiBwaGlzaGluZyBhdHRhY2tzLCB0aGUgYXV0 aG9yaXphdGlvbiBzZXJ2ZXJzIE1VU1QgcmVxdWlyZSB0aGUgdXNlIG9mCiAgICAgICAgICBUTFMg b24gZXZlcnkgZW5kcG9pbnQgdXNlZCBmb3IgZW5kLXVzZXIgaW50ZXJhY3Rpb24uCiAgICAgICAg CjwvcD4KPGEgbmFtZT0iQ1NSRiI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5 b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWdu PSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0Mm bmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLjEwLjEyIj48 L2E+PGgzPjEwLjEyLiZuYnNwOwpDcm9zcy1TaXRlIFJlcXVlc3QgRm9yZ2VyeTwvaDM+Cgo8cD4K ICAgICAgICAgIENyb3NzLXNpdGUgcmVxdWVzdCBmb3JnZXJ5IChDU1JGKSBpcyBhbiBleHBsb2l0 IGluIHdoaWNoIGFuIGF0dGFja2VyIGNhdXNlcyB0aGUKICAgICAgICAgIHVzZXItYWdlbnQgb2Yg YSB2aWN0aW0gZW5kLXVzZXIgdG8gZm9sbG93IGEgbWFsaWNpb3VzIFVSSSAoZS5nLiBwcm92aWRl ZCB0byB0aGUKICAgICAgICAgIHVzZXItYWdlbnQgYXMgYSBtaXNsZWFkaW5nIGxpbmssIGltYWdl LCBvciByZWRpcmVjdGlvbikgdG8gYSB0cnVzdGluZyBzZXJ2ZXIgKHVzdWFsbHkKICAgICAgICAg IGVzdGFibGlzaGVkIHZpYSB0aGUgcHJlc2VuY2Ugb2YgYSB2YWxpZCBzZXNzaW9uIGNvb2tpZSku CiAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICBBIENTUkYgYXR0YWNrIGFnYWluc3QgdGhlIGNs aWVudCdzIHJlZGlyZWN0aW9uIFVSSSBhbGxvd3MgYW4gYXR0YWNrZXIgdG8gaW5qZWN0IHRoZWly IG93bgogICAgICAgICAgYXV0aG9yaXphdGlvbiBjb2RlIG9yIGFjY2VzcyB0b2tlbiwgd2hpY2gg Y2FuIHJlc3VsdCBpbiB0aGUgY2xpZW50IHVzaW5nIGFuIGFjY2VzcyB0b2tlbgogICAgICAgICAg YXNzb2NpYXRlZCB3aXRoIHRoZSBhdHRhY2tlcidzIHByb3RlY3RlZCByZXNvdXJjZXMgcmF0aGVy IHRoYW4gdGhlIHZpY3RpbSdzIChlLmcuIHNhdmUKICAgICAgICAgIHRoZSB2aWN0aW0ncyBiYW5r IGFjY291bnQgaW5mb3JtYXRpb24gdG8gYSBwcm90ZWN0ZWQgcmVzb3VyY2UgY29udHJvbGxlZCBi eSB0aGUKICAgICAgICAgIGF0dGFja2VyKS4KICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgIFRo ZSBjbGllbnQgTVVTVCBpbXBsZW1lbnQgQ1NSRiBwcm90ZWN0aW9uIGZvciBpdHMgcmVkaXJlY3Rp b24gVVJJLiBUaGlzIGlzIHR5cGljYWxseQogICAgICAgICAgYWNjb21wbGlzaGVkIGJ5IHJlcXVp cmluZyBhbnkgcmVxdWVzdCBzZW50IHRvIHRoZSByZWRpcmVjdGlvbiBVUkkgZW5kcG9pbnQgdG8g aW5jbHVkZSBhCiAgICAgICAgICB2YWx1ZSB0aGF0IGJpbmRzIHRoZSByZXF1ZXN0IHRvIHRoZSB1 c2VyLWFnZW50J3MgYXV0aGVudGljYXRlZCBzdGF0ZSAoZS5nLiBhIGhhc2ggb2YgdGhlCiAgICAg ICAgICBzZXNzaW9uIGNvb2tpZSB1c2VkIHRvIGF1dGhlbnRpY2F0ZSB0aGUgdXNlci1hZ2VudCku IFRoZSBjbGllbnQgU0hPVUxEIHV0aWxpemUgdGhlCiAgICAgICAgICA8dHQ+c3RhdGU8L3R0PiBy ZXF1ZXN0IHBhcmFtZXRlciB0byBkZWxpdmVyIHRoaXMgdmFsdWUgdG8gdGhlCiAgICAgICAgICBh dXRob3JpemF0aW9uIHNlcnZlciB3aGVuIG1ha2luZyBhbiBhdXRob3JpemF0aW9uIHJlcXVlc3Qu CiAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICBPbmNlIGF1dGhvcml6YXRpb24gaGFzIGJlZW4g b2J0YWluZWQgZnJvbSB0aGUgZW5kLXVzZXIsIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlcgogICAg ICAgICAgcmVkaXJlY3RzIHRoZSBlbmQtdXNlcidzIHVzZXItYWdlbnQgYmFjayB0byB0aGUgY2xp ZW50IHdpdGggdGhlIHJlcXVpcmVkIGJpbmRpbmcgdmFsdWUKICAgICAgICAgIGNvbnRhaW5lZCBp biB0aGUgPHR0PnN0YXRlPC90dD4gcGFyYW1ldGVyLiBUaGUgYmluZGluZyB2YWx1ZSBlbmFibGVz CiAgICAgICAgICB0aGUgY2xpZW50IHRvIHZlcmlmeSB0aGUgdmFsaWRpdHkgb2YgdGhlIHJlcXVl c3QgYnkgbWF0Y2hpbmcgdGhlIGJpbmRpbmcgdmFsdWUgdG8gdGhlCiAgICAgICAgICB1c2VyLWFn ZW50J3MgYXV0aGVudGljYXRlZCBzdGF0ZS4gVGhlIGJpbmRpbmcgdmFsdWUgdXNlZCBmb3IgQ1NS RiBwcm90ZWN0aW9uIE1VU1QgY29udGFpbgogICAgICAgICAgYSBub24tZ3Vlc3NhYmxlIHZhbHVl IChhcyBkZXNjcmliZWQgaW4gPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNhbnRocm9weSc+U2VjdGlv biZuYnNwOzEwLjEwPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkNyZWRlbnRpYWxz IEd1ZXNzaW5nIEF0dGFja3M8L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+KSwgYW5kIHRoZSB1c2Vy LWFnZW50J3MKICAgICAgICAgIGF1dGhlbnRpY2F0ZWQgc3RhdGUgKGUuZy4gc2Vzc2lvbiBjb29r aWUsIEhUTUw1IGxvY2FsIHN0b3JhZ2UpIE1VU1QgYmUga2VwdCBpbiBhIGxvY2F0aW9uCiAgICAg ICAgICBhY2Nlc3NpYmxlIG9ubHkgdG8gdGhlIGNsaWVudCBhbmQgdGhlIHVzZXItYWdlbnQgKGku ZS4sIHByb3RlY3RlZCBieSBzYW1lLW9yaWdpbiBwb2xpY3kpLgogICAgICAgIAo8L3A+CjxwPgog ICAgICAgICAgQSBDU1JGIGF0dGFjayBhZ2FpbnN0IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlcidz IGF1dGhvcml6YXRpb24gZW5kcG9pbnQgY2FuIHJlc3VsdCBpbiBhbgogICAgICAgICAgYXR0YWNr ZXIgb2J0YWluaW5nIGVuZC11c2VyIGF1dGhvcml6YXRpb24gZm9yIGEgbWFsaWNpb3VzIGNsaWVu dCB3aXRob3V0IGludm9sdmluZyBvcgogICAgICAgICAgYWxlcnRpbmcgdGhlIGVuZC11c2VyLgog ICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIE1VU1Qg aW1wbGVtZW50IENTUkYgcHJvdGVjdGlvbiBmb3IgaXRzIGF1dGhvcml6YXRpb24gZW5kcG9pbnQs CiAgICAgICAgICBhbmQgZW5zdXJlIHRoYXQgYSBtYWxpY2lvdXMgY2xpZW50IGNhbm5vdCBvYnRh aW4gYXV0aG9yaXphdGlvbiB3aXRob3V0IHRoZSBhd2FyZW5lc3MgYW5kCiAgICAgICAgICBleHBs aWNpdCBjb25zZW50IG9mIHRoZSByZXNvdXJjZSBvd25lci4KICAgICAgICAKPC9wPgo8YSBuYW1l PSJhbmNob3I0NCI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxs cGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+ PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+ PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLjEwLjEzIj48L2E+PGgzPjEw LjEzLiZuYnNwOwpDbGlja2phY2tpbmc8L2gzPgoKPHA+CiAgICAgICAgICBJbiBhIGNsaWNramFj a2luZyBhdHRhY2ssIGFuIGF0dGFja2VyIHJlZ2lzdGVycyBhIGxlZ2l0aW1hdGUgY2xpZW50IGFu ZCB0aGVuIGNvbnN0cnVjdHMgYQogICAgICAgICAgbWFsaWNpb3VzIHNpdGUgaW4gd2hpY2ggaXQg bG9hZHMgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyJ3MgYXV0aG9yaXphdGlvbiBlbmRwb2ludCB3 ZWIKICAgICAgICAgIHBhZ2UgaW4gYSB0cmFuc3BhcmVudCBpZnJhbWUgb3ZlcmxhaWQgb24gdG9w IG9mIGEgc2V0IG9mIGR1bW15IGJ1dHRvbnMgd2hpY2ggYXJlCiAgICAgICAgICBjYXJlZnVsbHkg Y29uc3RydWN0ZWQgdG8gYmUgcGxhY2VkIGRpcmVjdGx5IHVuZGVyIGltcG9ydGFudCBidXR0b25z IG9uIHRoZSBhdXRob3JpemF0aW9uCiAgICAgICAgICBwYWdlLiBXaGVuIGFuIGVuZC11c2VyIGNs aWNrcyBhIG1pc2xlYWRpbmcgdmlzaWJsZSBidXR0b24sIHRoZSBlbmQtdXNlciBpcyBhY3R1YWxs eQogICAgICAgICAgY2xpY2tpbmcgYW4gaW52aXNpYmxlIGJ1dHRvbiBvbiB0aGUgYXV0aG9yaXph dGlvbiBwYWdlIChzdWNoIGFzIGFuICJBdXRob3JpemUiIGJ1dHRvbikuCiAgICAgICAgICBUaGlz IGFsbG93cyBhbiBhdHRhY2tlciB0byB0cmljayBhIHJlc291cmNlIG93bmVyIGludG8gZ3JhbnRp bmcgaXRzIGNsaWVudCBhY2Nlc3Mgd2l0aG91dAogICAgICAgICAgdGhlaXIga25vd2xlZGdlLgog ICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgVG8gcHJldmVudCB0aGlzIGZvcm0gb2YgYXR0YWNr LCBuYXRpdmUgYXBwbGljYXRpb25zIFNIT1VMRCB1c2UgZXh0ZXJuYWwgYnJvd3NlcnMgaW5zdGVh ZAogICAgICAgICAgb2YgZW1iZWRkaW5nIGJyb3dzZXJzIHdpdGhpbiB0aGUgYXBwbGljYXRpb24g d2hlbiByZXF1ZXN0aW5nIGVuZC11c2VyIGF1dGhvcml6YXRpb24uIEZvcgogICAgICAgICAgbW9z dCBuZXdlciBicm93c2VycywgYXZvaWRhbmNlIG9mIGlmcmFtZXMgY2FuIGJlIGVuZm9yY2VkIGJ5 IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlcgogICAgICAgICAgdXNpbmcgdGhlIChub24tc3RhbmRh cmQpIDx0dD54LWZyYW1lLW9wdGlvbnM8L3R0PiBoZWFkZXIuIFRoaXMgaGVhZGVyCiAgICAgICAg ICBjYW4gaGF2ZSB0d28gdmFsdWVzLCA8dHQ+ZGVueTwvdHQ+IGFuZAogICAgICAgICAgPHR0PnNh bWVvcmlnaW48L3R0Piwgd2hpY2ggd2lsbCBibG9jayBhbnkgZnJhbWluZywgb3IgZnJhbWluZyBi eSBzaXRlcwogICAgICAgICAgd2l0aCBhIGRpZmZlcmVudCBvcmlnaW4sIHJlc3BlY3RpdmVseS4g Rm9yIG9sZGVyIGJyb3dzZXJzLCBKYXZhU2NyaXB0IGZyYW1lYnVzdGluZwogICAgICAgICAgdGVj aG5pcXVlcyBjYW4gYmUgdXNlZCBidXQgbWF5IG5vdCBiZSBlZmZlY3RpdmUgaW4gYWxsIGJyb3dz ZXJzLgogICAgICAgIAo8L3A+CjxhIG5hbWU9ImFuY2hvcjQ1Ij48L2E+PGJyIC8+PGhyIC8+Cjx0 YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xh c3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9 IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZj LnNlY3Rpb24uMTAuMTQiPjwvYT48aDM+MTAuMTQuJm5ic3A7CkNvZGUgSW5qZWN0aW9uIGFuZCBJ bnB1dCBWYWxpZGF0aW9uPC9oMz4KCjxwPgogICAgICAgICAgQSBjb2RlIGluamVjdGlvbiBhdHRh Y2sgb2NjdXJzIHdoZW4gYW4gaW5wdXQgb3Igb3RoZXJ3aXNlIGV4dGVybmFsIHZhcmlhYmxlIGlz IHVzZWQgYnkgYW4KICAgICAgICAgIGFwcGxpY2F0aW9uIHVuc2FuaXRpemVkIGFuZCBjYXVzZXMg bW9kaWZpY2F0aW9uIHRvIHRoZSBhcHBsaWNhdGlvbiBsb2dpYy4gVGhpcyBtYXkgYWxsb3cKICAg ICAgICAgIGFuIGF0dGFja2VyIHRvIGdhaW4gYWNjZXNzIHRvIHRoZSBhcHBsaWNhdGlvbiBkZXZp Y2Ugb3IgaXRzIGRhdGEsIGNhdXNlIGRlbmlhbCBvZgogICAgICAgICAgc2VydmljZSwgb3IgYSB3 aWRlIHJhbmdlIG9mIG1hbGljaW91cyBzaWRlLWVmZmVjdHMuCiAgICAgICAgCjwvcD4KPHA+CiAg ICAgICAgICBUaGUgQXV0aG9yaXphdGlvbiBzZXJ2ZXIgYW5kIGNsaWVudCBNVVNUIHNhbml0aXpl IChhbmQgdmFsaWRhdGUgd2hlbiBwb3NzaWJsZSkgYW55IHZhbHVlCiAgICAgICAgICByZWNlaXZl ZCwgaW4gcGFydGljdWxhciwgdGhlIHZhbHVlIG9mIHRoZSA8dHQ+c3RhdGU8L3R0PiBhbmQKICAg ICAgICAgIDx0dD5yZWRpcmVjdF91cmk8L3R0PiBwYXJhbWV0ZXJzLgogICAgICAgIAo8L3A+Cjxh IG5hbWU9Im9wZW4tcmVkaXJlY3QiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9Imxh eW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGln bj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9D Jm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi4xMC4xNSI+ PC9hPjxoMz4xMC4xNS4mbmJzcDsKT3BlbiBSZWRpcmVjdG9yczwvaDM+Cgo8cD4KICAgICAgICAg IFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBhdXRob3JpemF0aW9uIGVuZHBvaW50IGFuZCB0aGUg Y2xpZW50IHJlZGlyZWN0aW9uIGVuZHBvaW50IGNhbgogICAgICAgICAgYmUgaW1wcm9wZXJseSBj b25maWd1cmVkIGFuZCBvcGVyYXRlIGFzIG9wZW4gcmVkaXJlY3RvcnMuIEFuIG9wZW4gcmVkaXJl Y3RvciBpcyBhbgogICAgICAgICAgZW5kcG9pbnQgdXNpbmcgYSBwYXJhbWV0ZXIgdG8gYXV0b21h dGljYWxseSByZWRpcmVjdCBhIHVzZXItYWdlbnQgdG8gdGhlIGxvY2F0aW9uCiAgICAgICAgICBz cGVjaWZpZWQgYnkgdGhlIHBhcmFtZXRlciB2YWx1ZSB3aXRob3V0IGFueSB2YWxpZGF0aW9uLgog ICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgT3BlbiByZWRpcmVjdG9ycyBjYW4gYmUgdXNlZCBp biBwaGlzaGluZyBhdHRhY2tzLCBvciBieSBhbiBhdHRhY2tlciB0byBnZXQgZW5kLXVzZXJzIHRv CiAgICAgICAgICB2aXNpdCBtYWxpY2lvdXMgc2l0ZXMgYnkgbWFraW5nIHRoZSBVUkkncyBhdXRo b3JpdHkgbG9vayBsaWtlIGEgZmFtaWxpYXIgYW5kIHRydXN0ZWQKICAgICAgICAgIGRlc3RpbmF0 aW9uLiBJbiBhZGRpdGlvbiwgaWYgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGFsbG93cyB0aGUg Y2xpZW50IHRvIHJlZ2lzdGVyIG9ubHkKICAgICAgICAgIHBhcnQgb2YgdGhlIHJlZGlyZWN0aW9u IFVSSSwgYW4gYXR0YWNrZXIgY2FuIHVzZSBhbiBvcGVuIHJlZGlyZWN0b3Igb3BlcmF0ZWQgYnkg dGhlCiAgICAgICAgICBjbGllbnQgdG8gY29uc3RydWN0IGEgcmVkaXJlY3Rpb24gVVJJIHRoYXQg d2lsbCBwYXNzIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciB2YWxpZGF0aW9uCiAgICAgICAgICBi dXQgd2lsbCBzZW5kIHRoZSBhdXRob3JpemF0aW9uIGNvZGUgb3IgYWNjZXNzIHRva2VuIHRvIGFu IGVuZHBvaW50IHVuZGVyIHRoZSBjb250cm9sIG9mCiAgICAgICAgICB0aGUgYXR0YWNrZXIuCiAg ICAgICAgCjwvcD4KPGEgbmFtZT0iYW5jaG9yNDYiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1 bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9D YnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+ Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlv bi4xMSI+PC9hPjxoMz4xMS4mbmJzcDsKSUFOQSBDb25zaWRlcmF0aW9uczwvaDM+Cgo8YSBuYW1l PSJ0eXBlLXJlZ2lzdHJ5Ij48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQi IGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJp Z2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNw OzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uMTEuMSI+PC9hPjxo Mz4xMS4xLiZuYnNwOwpUaGUgT0F1dGggQWNjZXNzIFRva2VuIFR5cGUgUmVnaXN0cnk8L2gzPgoK PHA+CiAgICAgICAgICBUaGlzIHNwZWNpZmljYXRpb24gZXN0YWJsaXNoZXMgdGhlIE9BdXRoIGFj Y2VzcyB0b2tlbiB0eXBlIHJlZ2lzdHJ5LgogICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgQWNj ZXNzIHRva2VuIHR5cGVzIGFyZSByZWdpc3RlcmVkIHdpdGggYSBTcGVjaWZpY2F0aW9uIFJlcXVp cmVkCiAgICAgICAgICAoPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNSRkM1MjI2Jz5bUkZDNTIyNl08 c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+TmFydGVuLCBULiBhbmQgSC4gQWx2ZXN0 cmFuZCwgJmxkcXVvO0d1aWRlbGluZXMgZm9yIFdyaXRpbmcgYW4gSUFOQSBDb25zaWRlcmF0aW9u cyBTZWN0aW9uIGluIFJGQ3MsJnJkcXVvOyBNYXkmbmJzcDsyMDA4Ljwvc3Bhbj48c3Bhbj4pPC9z cGFuPjwvYT4pIGFmdGVyIGEgdHdvIHdlZWsgcmV2aWV3IHBlcmlvZCBvbiB0aGUgW1RCRF1AaWV0 Zi5vcmcgbWFpbGluZwogICAgICAgICAgbGlzdCwgb24gdGhlIGFkdmljZSBvZiBvbmUgb3IgbW9y ZSBEZXNpZ25hdGVkIEV4cGVydHMuIEhvd2V2ZXIsIHRvIGFsbG93IGZvciB0aGUKICAgICAgICAg IGFsbG9jYXRpb24gb2YgdmFsdWVzIHByaW9yIHRvIHB1YmxpY2F0aW9uLCB0aGUgRGVzaWduYXRl ZCBFeHBlcnQocykgbWF5IGFwcHJvdmUKICAgICAgICAgIHJlZ2lzdHJhdGlvbiBvbmNlIHRoZXkg YXJlIHNhdGlzZmllZCB0aGF0IHN1Y2ggYSBzcGVjaWZpY2F0aW9uIHdpbGwgYmUgcHVibGlzaGVk LgogICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgUmVnaXN0cmF0aW9uIHJlcXVlc3RzIG11c3Qg YmUgc2VudCB0byB0aGUgW1RCRF1AaWV0Zi5vcmcgbWFpbGluZyBsaXN0IGZvciByZXZpZXcgYW5k CiAgICAgICAgICBjb21tZW50LCB3aXRoIGFuIGFwcHJvcHJpYXRlIHN1YmplY3QgKGUuZy4sICJS ZXF1ZXN0IGZvciBhY2Nlc3MgdG9rZW4gdHlwZTogZXhhbXBsZSIpLgogICAgICAgICAgW1sgTm90 ZSB0byBSRkMtRURJVE9SOiBUaGUgbmFtZSBvZiB0aGUgbWFpbGluZyBsaXN0IHNob3VsZCBiZSBk ZXRlcm1pbmVkIGluIGNvbnN1bHRhdGlvbgogICAgICAgICAgd2l0aCB0aGUgSUVTRyBhbmQgSUFO QS4gU3VnZ2VzdGVkIG5hbWU6IG9hdXRoLWV4dC1yZXZpZXcuIF1dCiAgICAgICAgCjwvcD4KPHA+ CiAgICAgICAgICBXaXRoaW4gdGhlIHJldmlldyBwZXJpb2QsIHRoZSBEZXNpZ25hdGVkIEV4cGVy dChzKSB3aWxsIGVpdGhlciBhcHByb3ZlIG9yCiAgICAgICAgICBkZW55IHRoZSByZWdpc3RyYXRp b24gcmVxdWVzdCwgY29tbXVuaWNhdGluZyB0aGlzIGRlY2lzaW9uIHRvIHRoZSByZXZpZXcgbGlz dCBhbmQgSUFOQS4KICAgICAgICAgIERlbmlhbHMgc2hvdWxkIGluY2x1ZGUgYW4gZXhwbGFuYXRp b24gYW5kLCBpZiBhcHBsaWNhYmxlLCBzdWdnZXN0aW9ucyBhcyB0byBob3cgdG8gbWFrZQogICAg ICAgICAgdGhlIHJlcXVlc3Qgc3VjY2Vzc2Z1bC4KICAgICAgICAKPC9wPgo8cD4KICAgICAgICAg IElBTkEgbXVzdCBvbmx5IGFjY2VwdCByZWdpc3RyeSB1cGRhdGVzIGZyb20gdGhlIERlc2lnbmF0 ZWQgRXhwZXJ0KHMpLCBhbmQgc2hvdWxkIGRpcmVjdAogICAgICAgICAgYWxsIHJlcXVlc3RzIGZv ciByZWdpc3RyYXRpb24gdG8gdGhlIHJldmlldyBtYWlsaW5nIGxpc3QuCiAgICAgICAgCjwvcD4K PGEgbmFtZT0iYW5jaG9yNDciPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91 dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0i cmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5i c3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi4xMS4xLjEiPjwv YT48aDM+MTEuMS4xLiZuYnNwOwpSZWdpc3RyYXRpb24gVGVtcGxhdGU8L2gzPgoKPHA+CiAgICAg ICAgICAgIDwvcD4KPGJsb2NrcXVvdGUgY2xhc3M9InRleHQiPjxkbD4KPGR0PlR5cGUgbmFtZTo8 L2R0Pgo8ZGQ+CiAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgIFRoZSBuYW1lIHJlcXVl c3RlZCAoZS5nLiwgImV4YW1wbGUiKS4KICAgICAgICAgICAgICAKPC9kZD4KPGR0PkFkZGl0aW9u YWwgVG9rZW4gRW5kcG9pbnQgUmVzcG9uc2UgUGFyYW1ldGVyczo8L2R0Pgo8ZGQ+CiAgICAgICAg ICAgICAgICAKICAgICAgICAgICAgICAgIEFkZGl0aW9uYWwgcmVzcG9uc2UgcGFyYW1ldGVycyBy ZXR1cm5lZCB0b2dldGhlciB3aXRoIHRoZQogICAgICAgICAgICAgICAgPHR0PmFjY2Vzc190b2tl bjwvdHQ+IHBhcmFtZXRlci4gTmV3IHBhcmFtZXRlcnMgTVVTVCBiZQogICAgICAgICAgICAgICAg c2VwYXJhdGVseSByZWdpc3RlcmVkIGluIHRoZSBPQXV0aCBwYXJhbWV0ZXJzIHJlZ2lzdHJ5IGFz IGRlc2NyaWJlZCBieQogICAgICAgICAgICAgICAgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNwYXJh bWV0ZXJzLXJlZ2lzdHJ5Jz5TZWN0aW9uJm5ic3A7MTEuMjxzcGFuPiAoPC9zcGFuPjxzcGFuIGNs YXNzPSdpbmZvJz5UaGUgT0F1dGggUGFyYW1ldGVycyBSZWdpc3RyeTwvc3Bhbj48c3Bhbj4pPC9z cGFuPjwvYT4uCiAgICAgICAgICAgICAgCjwvZGQ+CjxkdD5IVFRQIEF1dGhlbnRpY2F0aW9uIFNj aGVtZShzKTo8L2R0Pgo8ZGQ+CiAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgIFRoZSBI VFRQIGF1dGhlbnRpY2F0aW9uIHNjaGVtZSBuYW1lKHMpLCBpZiBhbnksIHVzZWQgdG8gYXV0aGVu dGljYXRlIHByb3RlY3RlZAogICAgICAgICAgICAgICAgcmVzb3VyY2VzIHJlcXVlc3RzIHVzaW5n IGFjY2VzcyB0b2tlbnMgb2YgdGhpcyB0eXBlLgogICAgICAgICAgICAgIAo8L2RkPgo8ZHQ+Q2hh bmdlIGNvbnRyb2xsZXI6PC9kdD4KPGRkPgogICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAg ICBGb3Igc3RhbmRhcmRzLXRyYWNrIFJGQ3MsIHN0YXRlICJJRVRGIi4gRm9yIG90aGVycywgZ2l2 ZSB0aGUgbmFtZSBvZiB0aGUKICAgICAgICAgICAgICAgIHJlc3BvbnNpYmxlIHBhcnR5LiBPdGhl ciBkZXRhaWxzIChlLmcuLCBwb3N0YWwgYWRkcmVzcywgZS1tYWlsIGFkZHJlc3MsIGhvbWUgcGFn ZQogICAgICAgICAgICAgICAgVVJJKSBtYXkgYWxzbyBiZSBpbmNsdWRlZC4KICAgICAgICAgICAg ICAKPC9kZD4KPGR0PlNwZWNpZmljYXRpb24gZG9jdW1lbnQocyk6PC9kdD4KPGRkPgogICAgICAg ICAgICAgICAgCiAgICAgICAgICAgICAgICBSZWZlcmVuY2UgdG8gdGhlIGRvY3VtZW50IHRoYXQg c3BlY2lmaWVzIHRoZSBwYXJhbWV0ZXIsIHByZWZlcmFibHkgaW5jbHVkaW5nIGEgVVJJIHRoYXQK ICAgICAgICAgICAgICAgIGNhbiBiZSB1c2VkIHRvIHJldHJpZXZlIGEgY29weSBvZiB0aGUgZG9j dW1lbnQuIEFuIGluZGljYXRpb24gb2YgdGhlIHJlbGV2YW50CiAgICAgICAgICAgICAgICBzZWN0 aW9ucyBtYXkgYWxzbyBiZSBpbmNsdWRlZCwgYnV0IGlzIG5vdCByZXF1aXJlZC4KICAgICAgICAg ICAgICAKPC9kZD4KPC9kbD48L2Jsb2NrcXVvdGU+PHA+CiAgICAgICAgICAKPC9wPgo8YSBuYW1l PSJwYXJhbWV0ZXJzLXJlZ2lzdHJ5Ij48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJs YXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxp Z249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RP QyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uMTEuMiI+ PC9hPjxoMz4xMS4yLiZuYnNwOwpUaGUgT0F1dGggUGFyYW1ldGVycyBSZWdpc3RyeTwvaDM+Cgo8 cD4KICAgICAgICAgIFRoaXMgc3BlY2lmaWNhdGlvbiBlc3RhYmxpc2hlcyB0aGUgT0F1dGggcGFy YW1ldGVycyByZWdpc3RyeS4KICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgIEFkZGl0aW9uYWwg cGFyYW1ldGVycyBmb3IgaW5jbHVzaW9uIGluIHRoZSBhdXRob3JpemF0aW9uIGVuZHBvaW50IHJl cXVlc3QsIHRoZQogICAgICAgICAgYXV0aG9yaXphdGlvbiBlbmRwb2ludCByZXNwb25zZSwgdGhl IHRva2VuIGVuZHBvaW50IHJlcXVlc3QsIG9yIHRoZSB0b2tlbiBlbmRwb2ludAogICAgICAgICAg cmVzcG9uc2UgYXJlIHJlZ2lzdGVyZWQgd2l0aCBhIFNwZWNpZmljYXRpb24gUmVxdWlyZWQKICAg ICAgICAgICg8YSBjbGFzcz0naW5mbycgaHJlZj0nI1JGQzUyMjYnPltSRkM1MjI2XTxzcGFuPiAo PC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5OYXJ0ZW4sIFQuIGFuZCBILiBBbHZlc3RyYW5kLCAm bGRxdW87R3VpZGVsaW5lcyBmb3IgV3JpdGluZyBhbiBJQU5BIENvbnNpZGVyYXRpb25zIFNlY3Rp b24gaW4gUkZDcywmcmRxdW87IE1heSZuYnNwOzIwMDguPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9h PikgYWZ0ZXIgYSB0d28gd2VlayByZXZpZXcgcGVyaW9kIG9uIHRoZSBbVEJEXUBpZXRmLm9yZyBt YWlsaW5nCiAgICAgICAgICBsaXN0LCBvbiB0aGUgYWR2aWNlIG9mIG9uZSBvciBtb3JlIERlc2ln bmF0ZWQgRXhwZXJ0cy4gSG93ZXZlciwgdG8gYWxsb3cgZm9yIHRoZQogICAgICAgICAgYWxsb2Nh dGlvbiBvZiB2YWx1ZXMgcHJpb3IgdG8gcHVibGljYXRpb24sIHRoZSBEZXNpZ25hdGVkIEV4cGVy dChzKSBtYXkgYXBwcm92ZQogICAgICAgICAgcmVnaXN0cmF0aW9uIG9uY2UgdGhleSBhcmUgc2F0 aXNmaWVkIHRoYXQgc3VjaCBhIHNwZWNpZmljYXRpb24gd2lsbCBiZSBwdWJsaXNoZWQuCiAgICAg ICAgCjwvcD4KPHA+CiAgICAgICAgICBSZWdpc3RyYXRpb24gcmVxdWVzdHMgbXVzdCBiZSBzZW50 IHRvIHRoZSBbVEJEXUBpZXRmLm9yZyBtYWlsaW5nIGxpc3QgZm9yIHJldmlldyBhbmQKICAgICAg ICAgIGNvbW1lbnQsIHdpdGggYW4gYXBwcm9wcmlhdGUgc3ViamVjdCAoZS5nLiwgIlJlcXVlc3Qg Zm9yIHBhcmFtZXRlcjogZXhhbXBsZSIpLgogICAgICAgICAgW1sgTm90ZSB0byBSRkMtRURJVE9S OiBUaGUgbmFtZSBvZiB0aGUgbWFpbGluZyBsaXN0IHNob3VsZCBiZSBkZXRlcm1pbmVkIGluIGNv bnN1bHRhdGlvbgogICAgICAgICAgd2l0aCB0aGUgSUVTRyBhbmQgSUFOQS4gU3VnZ2VzdGVkIG5h bWU6IG9hdXRoLWV4dC1yZXZpZXcuIF1dCiAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICBXaXRo aW4gdGhlIHJldmlldyBwZXJpb2QsIHRoZSBEZXNpZ25hdGVkIEV4cGVydChzKSB3aWxsIGVpdGhl ciBhcHByb3ZlIG9yCiAgICAgICAgICBkZW55IHRoZSByZWdpc3RyYXRpb24gcmVxdWVzdCwgY29t bXVuaWNhdGluZyB0aGlzIGRlY2lzaW9uIHRvIHRoZSByZXZpZXcgbGlzdCBhbmQgSUFOQS4KICAg ICAgICAgIERlbmlhbHMgc2hvdWxkIGluY2x1ZGUgYW4gZXhwbGFuYXRpb24gYW5kLCBpZiBhcHBs aWNhYmxlLCBzdWdnZXN0aW9ucyBhcyB0byBob3cgdG8gbWFrZQogICAgICAgICAgdGhlIHJlcXVl c3Qgc3VjY2Vzc2Z1bC4KICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgIElBTkEgbXVzdCBvbmx5 IGFjY2VwdCByZWdpc3RyeSB1cGRhdGVzIGZyb20gdGhlIERlc2lnbmF0ZWQgRXhwZXJ0KHMpLCBh bmQgc2hvdWxkIGRpcmVjdAogICAgICAgICAgYWxsIHJlcXVlc3RzIGZvciByZWdpc3RyYXRpb24g dG8gdGhlIHJldmlldyBtYWlsaW5nIGxpc3QuCiAgICAgICAgCjwvcD4KPGEgbmFtZT0iYW5jaG9y NDgiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9 IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQg Y2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90 cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi4xMS4yLjEiPjwvYT48aDM+MTEuMi4xLiZu YnNwOwpSZWdpc3RyYXRpb24gVGVtcGxhdGU8L2gzPgoKPHA+CiAgICAgICAgICAgIDwvcD4KPGJs b2NrcXVvdGUgY2xhc3M9InRleHQiPjxkbD4KPGR0PlBhcmFtZXRlciBuYW1lOjwvZHQ+CjxkZD4K ICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgVGhlIG5hbWUgcmVxdWVzdGVkIChlLmcu LCAiZXhhbXBsZSIpLgogICAgICAgICAgICAgIAo8L2RkPgo8ZHQ+UGFyYW1ldGVyIHVzYWdlIGxv Y2F0aW9uOjwvZHQ+CjxkZD4KICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgVGhlIGxv Y2F0aW9uKHMpIHdoZXJlIHBhcmFtZXRlciBjYW4gYmUgdXNlZC4gVGhlIHBvc3NpYmxlIGxvY2F0 aW9ucyBhcmU6CiAgICAgICAgICAgICAgICBhdXRob3JpemF0aW9uIHJlcXVlc3QsIGF1dGhvcml6 YXRpb24gcmVzcG9uc2UsIHRva2VuIHJlcXVlc3QsIG9yIHRva2VuIHJlc3BvbnNlLgogICAgICAg ICAgICAgIAo8L2RkPgo8ZHQ+Q2hhbmdlIGNvbnRyb2xsZXI6PC9kdD4KPGRkPgogICAgICAgICAg ICAgICAgCiAgICAgICAgICAgICAgICBGb3Igc3RhbmRhcmRzLXRyYWNrIFJGQ3MsIHN0YXRlICJJ RVRGIi4gRm9yIG90aGVycywgZ2l2ZSB0aGUgbmFtZSBvZiB0aGUKICAgICAgICAgICAgICAgIHJl c3BvbnNpYmxlIHBhcnR5LiBPdGhlciBkZXRhaWxzIChlLmcuLCBwb3N0YWwgYWRkcmVzcywgZS1t YWlsIGFkZHJlc3MsIGhvbWUgcGFnZQogICAgICAgICAgICAgICAgVVJJKSBtYXkgYWxzbyBiZSBp bmNsdWRlZC4KICAgICAgICAgICAgICAKPC9kZD4KPGR0PlNwZWNpZmljYXRpb24gZG9jdW1lbnQo cyk6PC9kdD4KPGRkPgogICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICBSZWZlcmVuY2Ug dG8gdGhlIGRvY3VtZW50IHRoYXQgc3BlY2lmaWVzIHRoZSBwYXJhbWV0ZXIsIHByZWZlcmFibHkg aW5jbHVkaW5nIGEgVVJJIHRoYXQKICAgICAgICAgICAgICAgIGNhbiBiZSB1c2VkIHRvIHJldHJp ZXZlIGEgY29weSBvZiB0aGUgZG9jdW1lbnQuIEFuIGluZGljYXRpb24gb2YgdGhlIHJlbGV2YW50 CiAgICAgICAgICAgICAgICBzZWN0aW9ucyBtYXkgYWxzbyBiZSBpbmNsdWRlZCwgYnV0IGlzIG5v dCByZXF1aXJlZC4KICAgICAgICAgICAgICAKPC9kZD4KPC9kbD48L2Jsb2NrcXVvdGU+PHA+CiAg ICAgICAgICAKPC9wPgo8YSBuYW1lPSJhbmNob3I0OSI+PC9hPjxiciAvPjxociAvPgo8dGFibGUg c3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJU T0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9j Ij4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0 aW9uLjExLjIuMiI+PC9hPjxoMz4xMS4yLjIuJm5ic3A7CkluaXRpYWwgUmVnaXN0cnkgQ29udGVu dHM8L2gzPgoKPHA+CiAgICAgICAgICAgIFRoZSBPQXV0aCBQYXJhbWV0ZXJzIFJlZ2lzdHJ5J3Mg aW5pdGlhbCBjb250ZW50cyBhcmU6CiAgICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgICAgPC9w Pgo8dWwgY2xhc3M9InRleHQiPgo8bGk+CiAgICAgICAgICAgICAgICBQYXJhbWV0ZXIgbmFtZTog Y2xpZW50X2lkCiAgICAgICAgICAgICAgCjwvbGk+CjxsaT4KICAgICAgICAgICAgICAgIFBhcmFt ZXRlciB1c2FnZSBsb2NhdGlvbjogYXV0aG9yaXphdGlvbiByZXF1ZXN0LCB0b2tlbiByZXF1ZXN0 CiAgICAgICAgICAgICAgCjwvbGk+CjxsaT4KICAgICAgICAgICAgICAgIENoYW5nZSBjb250cm9s bGVyOiBJRVRGCiAgICAgICAgICAgICAgCjwvbGk+CjxsaT4KICAgICAgICAgICAgICAgIFNwZWNp ZmljYXRpb24gZG9jdW1lbnQocyk6IFtbIHRoaXMgZG9jdW1lbnQgXV0KICAgICAgICAgICAgICAK PC9saT4KPC91bD48cD4KICAgICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgICA8L3A+Cjx1bCBj bGFzcz0idGV4dCI+CjxsaT4KICAgICAgICAgICAgICAgIFBhcmFtZXRlciBuYW1lOiBjbGllbnRf c2VjcmV0CiAgICAgICAgICAgICAgCjwvbGk+CjxsaT4KICAgICAgICAgICAgICAgIFBhcmFtZXRl ciB1c2FnZSBsb2NhdGlvbjogdG9rZW4gcmVxdWVzdAogICAgICAgICAgICAgIAo8L2xpPgo8bGk+ CiAgICAgICAgICAgICAgICBDaGFuZ2UgY29udHJvbGxlcjogSUVURgogICAgICAgICAgICAgIAo8 L2xpPgo8bGk+CiAgICAgICAgICAgICAgICBTcGVjaWZpY2F0aW9uIGRvY3VtZW50KHMpOiBbWyB0 aGlzIGRvY3VtZW50IF1dCiAgICAgICAgICAgICAgCjwvbGk+CjwvdWw+PHA+CiAgICAgICAgICAK PC9wPgo8cD4KICAgICAgICAgICAgPC9wPgo8dWwgY2xhc3M9InRleHQiPgo8bGk+CiAgICAgICAg ICAgICAgICBQYXJhbWV0ZXIgbmFtZTogcmVzcG9uc2VfdHlwZQogICAgICAgICAgICAgIAo8L2xp Pgo8bGk+CiAgICAgICAgICAgICAgICBQYXJhbWV0ZXIgdXNhZ2UgbG9jYXRpb246IGF1dGhvcml6 YXRpb24gcmVxdWVzdAogICAgICAgICAgICAgIAo8L2xpPgo8bGk+CiAgICAgICAgICAgICAgICBD aGFuZ2UgY29udHJvbGxlcjogSUVURgogICAgICAgICAgICAgIAo8L2xpPgo8bGk+CiAgICAgICAg ICAgICAgICBTcGVjaWZpY2F0aW9uIGRvY3VtZW50KHMpOiBbWyB0aGlzIGRvY3VtZW50IF1dCiAg ICAgICAgICAgICAgCjwvbGk+CjwvdWw+PHA+CiAgICAgICAgICAKPC9wPgo8cD4KICAgICAgICAg ICAgPC9wPgo8dWwgY2xhc3M9InRleHQiPgo8bGk+CiAgICAgICAgICAgICAgICBQYXJhbWV0ZXIg bmFtZTogcmVkaXJlY3RfdXJpCiAgICAgICAgICAgICAgCjwvbGk+CjxsaT4KICAgICAgICAgICAg ICAgIFBhcmFtZXRlciB1c2FnZSBsb2NhdGlvbjogYXV0aG9yaXphdGlvbiByZXF1ZXN0LCB0b2tl biByZXF1ZXN0CiAgICAgICAgICAgICAgCjwvbGk+CjxsaT4KICAgICAgICAgICAgICAgIENoYW5n ZSBjb250cm9sbGVyOiBJRVRGCiAgICAgICAgICAgICAgCjwvbGk+CjxsaT4KICAgICAgICAgICAg ICAgIFNwZWNpZmljYXRpb24gZG9jdW1lbnQocyk6IFtbIHRoaXMgZG9jdW1lbnQgXV0KICAgICAg ICAgICAgICAKPC9saT4KPC91bD48cD4KICAgICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgICA8 L3A+Cjx1bCBjbGFzcz0idGV4dCI+CjxsaT4KICAgICAgICAgICAgICAgIFBhcmFtZXRlciBuYW1l OiBzY29wZQogICAgICAgICAgICAgIAo8L2xpPgo8bGk+CiAgICAgICAgICAgICAgICBQYXJhbWV0 ZXIgdXNhZ2UgbG9jYXRpb246IGF1dGhvcml6YXRpb24gcmVxdWVzdCwgYXV0aG9yaXphdGlvbiBy ZXNwb25zZSwgdG9rZW4KICAgICAgICAgICAgICAgIHJlcXVlc3QsIHRva2VuIHJlc3BvbnNlCiAg ICAgICAgICAgICAgCjwvbGk+CjxsaT4KICAgICAgICAgICAgICAgIENoYW5nZSBjb250cm9sbGVy OiBJRVRGCiAgICAgICAgICAgICAgCjwvbGk+CjxsaT4KICAgICAgICAgICAgICAgIFNwZWNpZmlj YXRpb24gZG9jdW1lbnQocyk6IFtbIHRoaXMgZG9jdW1lbnQgXV0KICAgICAgICAgICAgICAKPC9s aT4KPC91bD48cD4KICAgICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgICA8L3A+Cjx1bCBjbGFz cz0idGV4dCI+CjxsaT4KICAgICAgICAgICAgICAgIFBhcmFtZXRlciBuYW1lOiBzdGF0ZQogICAg ICAgICAgICAgIAo8L2xpPgo8bGk+CiAgICAgICAgICAgICAgICBQYXJhbWV0ZXIgdXNhZ2UgbG9j YXRpb246IGF1dGhvcml6YXRpb24gcmVxdWVzdCwgYXV0aG9yaXphdGlvbiByZXNwb25zZQogICAg ICAgICAgICAgIAo8L2xpPgo8bGk+CiAgICAgICAgICAgICAgICBDaGFuZ2UgY29udHJvbGxlcjog SUVURgogICAgICAgICAgICAgIAo8L2xpPgo8bGk+CiAgICAgICAgICAgICAgICBTcGVjaWZpY2F0 aW9uIGRvY3VtZW50KHMpOiBbWyB0aGlzIGRvY3VtZW50IF1dCiAgICAgICAgICAgICAgCjwvbGk+ CjwvdWw+PHA+CiAgICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgICAgPC9wPgo8dWwgY2xhc3M9 InRleHQiPgo8bGk+CiAgICAgICAgICAgICAgICBQYXJhbWV0ZXIgbmFtZTogY29kZQogICAgICAg ICAgICAgIAo8L2xpPgo8bGk+CiAgICAgICAgICAgICAgICBQYXJhbWV0ZXIgdXNhZ2UgbG9jYXRp b246IGF1dGhvcml6YXRpb24gcmVzcG9uc2UsIHRva2VuIHJlcXVlc3QKICAgICAgICAgICAgICAK PC9saT4KPGxpPgogICAgICAgICAgICAgICAgQ2hhbmdlIGNvbnRyb2xsZXI6IElFVEYKICAgICAg ICAgICAgICAKPC9saT4KPGxpPgogICAgICAgICAgICAgICAgU3BlY2lmaWNhdGlvbiBkb2N1bWVu dChzKTogW1sgdGhpcyBkb2N1bWVudCBdXQogICAgICAgICAgICAgIAo8L2xpPgo8L3VsPjxwPgog ICAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICAgIDwvcD4KPHVsIGNsYXNzPSJ0ZXh0Ij4KPGxp PgogICAgICAgICAgICAgICAgUGFyYW1ldGVyIG5hbWU6IGVycm9yX2Rlc2NyaXB0aW9uCiAgICAg ICAgICAgICAgCjwvbGk+CjxsaT4KICAgICAgICAgICAgICAgIFBhcmFtZXRlciB1c2FnZSBsb2Nh dGlvbjogYXV0aG9yaXphdGlvbiByZXNwb25zZSwgdG9rZW4gcmVzcG9uc2UKICAgICAgICAgICAg ICAKPC9saT4KPGxpPgogICAgICAgICAgICAgICAgQ2hhbmdlIGNvbnRyb2xsZXI6IElFVEYKICAg ICAgICAgICAgICAKPC9saT4KPGxpPgogICAgICAgICAgICAgICAgU3BlY2lmaWNhdGlvbiBkb2N1 bWVudChzKTogW1sgdGhpcyBkb2N1bWVudCBdXQogICAgICAgICAgICAgIAo8L2xpPgo8L3VsPjxw PgogICAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICAgIDwvcD4KPHVsIGNsYXNzPSJ0ZXh0Ij4K PGxpPgogICAgICAgICAgICAgICAgUGFyYW1ldGVyIG5hbWU6IGVycm9yX3VyaQogICAgICAgICAg ICAgIAo8L2xpPgo8bGk+CiAgICAgICAgICAgICAgICBQYXJhbWV0ZXIgdXNhZ2UgbG9jYXRpb246 IGF1dGhvcml6YXRpb24gcmVzcG9uc2UsIHRva2VuIHJlc3BvbnNlCiAgICAgICAgICAgICAgCjwv bGk+CjxsaT4KICAgICAgICAgICAgICAgIENoYW5nZSBjb250cm9sbGVyOiBJRVRGCiAgICAgICAg ICAgICAgCjwvbGk+CjxsaT4KICAgICAgICAgICAgICAgIFNwZWNpZmljYXRpb24gZG9jdW1lbnQo cyk6IFtbIHRoaXMgZG9jdW1lbnQgXV0KICAgICAgICAgICAgICAKPC9saT4KPC91bD48cD4KICAg ICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgICA8L3A+Cjx1bCBjbGFzcz0idGV4dCI+CjxsaT4K ICAgICAgICAgICAgICAgIFBhcmFtZXRlciBuYW1lOiBncmFudF90eXBlCiAgICAgICAgICAgICAg CjwvbGk+CjxsaT4KICAgICAgICAgICAgICAgIFBhcmFtZXRlciB1c2FnZSBsb2NhdGlvbjogdG9r ZW4gcmVxdWVzdAogICAgICAgICAgICAgIAo8L2xpPgo8bGk+CiAgICAgICAgICAgICAgICBDaGFu Z2UgY29udHJvbGxlcjogSUVURgogICAgICAgICAgICAgIAo8L2xpPgo8bGk+CiAgICAgICAgICAg ICAgICBTcGVjaWZpY2F0aW9uIGRvY3VtZW50KHMpOiBbWyB0aGlzIGRvY3VtZW50IF1dCiAgICAg ICAgICAgICAgCjwvbGk+CjwvdWw+PHA+CiAgICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgICAg PC9wPgo8dWwgY2xhc3M9InRleHQiPgo8bGk+CiAgICAgICAgICAgICAgICBQYXJhbWV0ZXIgbmFt ZTogYWNjZXNzX3Rva2VuCiAgICAgICAgICAgICAgCjwvbGk+CjxsaT4KICAgICAgICAgICAgICAg IFBhcmFtZXRlciB1c2FnZSBsb2NhdGlvbjogYXV0aG9yaXphdGlvbiByZXNwb25zZSwgdG9rZW4g cmVzcG9uc2UKICAgICAgICAgICAgICAKPC9saT4KPGxpPgogICAgICAgICAgICAgICAgQ2hhbmdl IGNvbnRyb2xsZXI6IElFVEYKICAgICAgICAgICAgICAKPC9saT4KPGxpPgogICAgICAgICAgICAg ICAgU3BlY2lmaWNhdGlvbiBkb2N1bWVudChzKTogW1sgdGhpcyBkb2N1bWVudCBdXQogICAgICAg ICAgICAgIAo8L2xpPgo8L3VsPjxwPgogICAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICAgIDwv cD4KPHVsIGNsYXNzPSJ0ZXh0Ij4KPGxpPgogICAgICAgICAgICAgICAgUGFyYW1ldGVyIG5hbWU6 IHRva2VuX3R5cGUKICAgICAgICAgICAgICAKPC9saT4KPGxpPgogICAgICAgICAgICAgICAgUGFy YW1ldGVyIHVzYWdlIGxvY2F0aW9uOiBhdXRob3JpemF0aW9uIHJlc3BvbnNlLCB0b2tlbiByZXNw b25zZQogICAgICAgICAgICAgIAo8L2xpPgo8bGk+CiAgICAgICAgICAgICAgICBDaGFuZ2UgY29u dHJvbGxlcjogSUVURgogICAgICAgICAgICAgIAo8L2xpPgo8bGk+CiAgICAgICAgICAgICAgICBT cGVjaWZpY2F0aW9uIGRvY3VtZW50KHMpOiBbWyB0aGlzIGRvY3VtZW50IF1dCiAgICAgICAgICAg ICAgCjwvbGk+CjwvdWw+PHA+CiAgICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgICAgPC9wPgo8 dWwgY2xhc3M9InRleHQiPgo8bGk+CiAgICAgICAgICAgICAgICBQYXJhbWV0ZXIgbmFtZTogZXhw aXJlc19pbgogICAgICAgICAgICAgIAo8L2xpPgo8bGk+CiAgICAgICAgICAgICAgICBQYXJhbWV0 ZXIgdXNhZ2UgbG9jYXRpb246IGF1dGhvcml6YXRpb24gcmVzcG9uc2UsIHRva2VuIHJlc3BvbnNl CiAgICAgICAgICAgICAgCjwvbGk+CjxsaT4KICAgICAgICAgICAgICAgIENoYW5nZSBjb250cm9s bGVyOiBJRVRGCiAgICAgICAgICAgICAgCjwvbGk+CjxsaT4KICAgICAgICAgICAgICAgIFNwZWNp ZmljYXRpb24gZG9jdW1lbnQocyk6IFtbIHRoaXMgZG9jdW1lbnQgXV0KICAgICAgICAgICAgICAK PC9saT4KPC91bD48cD4KICAgICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgICA8L3A+Cjx1bCBj bGFzcz0idGV4dCI+CjxsaT4KICAgICAgICAgICAgICAgIFBhcmFtZXRlciBuYW1lOiB1c2VybmFt ZQogICAgICAgICAgICAgIAo8L2xpPgo8bGk+CiAgICAgICAgICAgICAgICBQYXJhbWV0ZXIgdXNh Z2UgbG9jYXRpb246IHRva2VuIHJlcXVlc3QKICAgICAgICAgICAgICAKPC9saT4KPGxpPgogICAg ICAgICAgICAgICAgQ2hhbmdlIGNvbnRyb2xsZXI6IElFVEYKICAgICAgICAgICAgICAKPC9saT4K PGxpPgogICAgICAgICAgICAgICAgU3BlY2lmaWNhdGlvbiBkb2N1bWVudChzKTogW1sgdGhpcyBk b2N1bWVudCBdXQogICAgICAgICAgICAgIAo8L2xpPgo8L3VsPjxwPgogICAgICAgICAgCjwvcD4K PHA+CiAgICAgICAgICAgIDwvcD4KPHVsIGNsYXNzPSJ0ZXh0Ij4KPGxpPgogICAgICAgICAgICAg ICAgUGFyYW1ldGVyIG5hbWU6IHBhc3N3b3JkCiAgICAgICAgICAgICAgCjwvbGk+CjxsaT4KICAg ICAgICAgICAgICAgIFBhcmFtZXRlciB1c2FnZSBsb2NhdGlvbjogdG9rZW4gcmVxdWVzdAogICAg ICAgICAgICAgIAo8L2xpPgo8bGk+CiAgICAgICAgICAgICAgICBDaGFuZ2UgY29udHJvbGxlcjog SUVURgogICAgICAgICAgICAgIAo8L2xpPgo8bGk+CiAgICAgICAgICAgICAgICBTcGVjaWZpY2F0 aW9uIGRvY3VtZW50KHMpOiBbWyB0aGlzIGRvY3VtZW50IF1dCiAgICAgICAgICAgICAgCjwvbGk+ CjwvdWw+PHA+CiAgICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgICAgPC9wPgo8dWwgY2xhc3M9 InRleHQiPgo8bGk+CiAgICAgICAgICAgICAgICBQYXJhbWV0ZXIgbmFtZTogcmVmcmVzaF90b2tl bgogICAgICAgICAgICAgIAo8L2xpPgo8bGk+CiAgICAgICAgICAgICAgICBQYXJhbWV0ZXIgdXNh Z2UgbG9jYXRpb246IHRva2VuIHJlcXVlc3QsIHRva2VuIHJlc3BvbnNlCiAgICAgICAgICAgICAg CjwvbGk+CjxsaT4KICAgICAgICAgICAgICAgIENoYW5nZSBjb250cm9sbGVyOiBJRVRGCiAgICAg ICAgICAgICAgCjwvbGk+CjxsaT4KICAgICAgICAgICAgICAgIFNwZWNpZmljYXRpb24gZG9jdW1l bnQocyk6IFtbIHRoaXMgZG9jdW1lbnQgXV0KICAgICAgICAgICAgICAKPC9saT4KPC91bD48cD4K ICAgICAgICAgIAo8L3A+CjxhIG5hbWU9InJlc3BvbnNlLXR5cGUtcmVnaXN0cnkiPjwvYT48YnIg Lz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFj aW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1 ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8 YSBuYW1lPSJyZmMuc2VjdGlvbi4xMS4zIj48L2E+PGgzPjExLjMuJm5ic3A7ClRoZSBPQXV0aCBB dXRob3JpemF0aW9uIEVuZHBvaW50IFJlc3BvbnNlIFR5cGUgUmVnaXN0cnk8L2gzPgoKPHA+CiAg ICAgICAgICBUaGlzIHNwZWNpZmljYXRpb24gZXN0YWJsaXNoZXMgdGhlIE9BdXRoIGF1dGhvcml6 YXRpb24gZW5kcG9pbnQgcmVzcG9uc2UgdHlwZSByZWdpc3RyeS4KICAgICAgICAKPC9wPgo8cD4K ICAgICAgICAgICAgQWRkaXRpb25hbCByZXNwb25zZSB0eXBlIGZvciB1c2Ugd2l0aCB0aGUgYXV0 aG9yaXphdGlvbiBlbmRwb2ludCBhcmUgcmVnaXN0ZXJlZCB3aXRoIGEKICAgICAgICAgICAgU3Bl Y2lmaWNhdGlvbiBSZXF1aXJlZCAoPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNSRkM1MjI2Jz5bUkZD NTIyNl08c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+TmFydGVuLCBULiBhbmQgSC4g QWx2ZXN0cmFuZCwgJmxkcXVvO0d1aWRlbGluZXMgZm9yIFdyaXRpbmcgYW4gSUFOQSBDb25zaWRl cmF0aW9ucyBTZWN0aW9uIGluIFJGQ3MsJnJkcXVvOyBNYXkmbmJzcDsyMDA4Ljwvc3Bhbj48c3Bh bj4pPC9zcGFuPjwvYT4pIGFmdGVyIGEgdHdvIHdlZWsgcmV2aWV3IHBlcmlvZCBvbgogICAgICAg ICAgICB0aGUgW1RCRF1AaWV0Zi5vcmcgbWFpbGluZyBsaXN0LCBvbiB0aGUgYWR2aWNlIG9mIG9u ZSBvciBtb3JlIERlc2lnbmF0ZWQgRXhwZXJ0cy4KICAgICAgICAgICAgSG93ZXZlciwgdG8gYWxs b3cgZm9yIHRoZSBhbGxvY2F0aW9uIG9mIHZhbHVlcyBwcmlvciB0byBwdWJsaWNhdGlvbiwgdGhl IERlc2lnbmF0ZWQKICAgICAgICAgICAgRXhwZXJ0KHMpIG1heSBhcHByb3ZlIHJlZ2lzdHJhdGlv biBvbmNlIHRoZXkgYXJlIHNhdGlzZmllZCB0aGF0IHN1Y2ggYSBzcGVjaWZpY2F0aW9uCiAgICAg ICAgICAgIHdpbGwgYmUgcHVibGlzaGVkLgogICAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICAg IFJlZ2lzdHJhdGlvbiByZXF1ZXN0cyBtdXN0IGJlIHNlbnQgdG8gdGhlIFtUQkRdQGlldGYub3Jn IG1haWxpbmcgbGlzdCBmb3IgcmV2aWV3IGFuZAogICAgICAgICAgICBjb21tZW50LCB3aXRoIGFu IGFwcHJvcHJpYXRlIHN1YmplY3QgKGUuZy4sICJSZXF1ZXN0IGZvciByZXNwb25zZSB0eXBlOiBl eGFtcGxlIikuCiAgICAgICAgICAgIFtbIE5vdGUgdG8gUkZDLUVESVRPUjogVGhlIG5hbWUgb2Yg dGhlIG1haWxpbmcgbGlzdCBzaG91bGQgYmUgZGV0ZXJtaW5lZCBpbiBjb25zdWx0YXRpb24KICAg ICAgICAgICAgd2l0aCB0aGUgSUVTRyBhbmQgSUFOQS4gU3VnZ2VzdGVkIG5hbWU6IG9hdXRoLWV4 dC1yZXZpZXcuIF1dCiAgICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgICAgV2l0aGluIHRoZSBy ZXZpZXcgcGVyaW9kLCB0aGUgRGVzaWduYXRlZCBFeHBlcnQocykgd2lsbCBlaXRoZXIgYXBwcm92 ZSBvcgogICAgICAgICAgICBkZW55IHRoZSByZWdpc3RyYXRpb24gcmVxdWVzdCwgY29tbXVuaWNh dGluZyB0aGlzIGRlY2lzaW9uIHRvIHRoZSByZXZpZXcgbGlzdCBhbmQgSUFOQS4KICAgICAgICAg ICAgRGVuaWFscyBzaG91bGQgaW5jbHVkZSBhbiBleHBsYW5hdGlvbiBhbmQsIGlmIGFwcGxpY2Fi bGUsIHN1Z2dlc3Rpb25zIGFzIHRvIGhvdyB0byBtYWtlCiAgICAgICAgICAgIHRoZSByZXF1ZXN0 IHN1Y2Nlc3NmdWwuCiAgICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgICAgSUFOQSBtdXN0IG9u bHkgYWNjZXB0IHJlZ2lzdHJ5IHVwZGF0ZXMgZnJvbSB0aGUgRGVzaWduYXRlZCBFeHBlcnQocyks IGFuZCBzaG91bGQgZGlyZWN0CiAgICAgICAgICAgIGFsbCByZXF1ZXN0cyBmb3IgcmVnaXN0cmF0 aW9uIHRvIHRoZSByZXZpZXcgbWFpbGluZyBsaXN0LgogICAgICAgICAgCjwvcD4KPGEgbmFtZT0i YW5jaG9yNTAiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBh ZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0 cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwv dGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi4xMS4zLjEiPjwvYT48aDM+MTEu My4xLiZuYnNwOwpSZWdpc3RyYXRpb24gVGVtcGxhdGU8L2gzPgoKPHA+CiAgICAgICAgICAgIDwv cD4KPGJsb2NrcXVvdGUgY2xhc3M9InRleHQiPjxkbD4KPGR0PlJlc3BvbnNlIHR5cGUgbmFtZTo8 L2R0Pgo8ZGQ+CiAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgIFRoZSBuYW1lIHJlcXVl c3RlZCAoZS5nLiwgImV4YW1wbGUiKS4KICAgICAgICAgICAgICAKPC9kZD4KPGR0PkNoYW5nZSBj b250cm9sbGVyOjwvZHQ+CjxkZD4KICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgRm9y IHN0YW5kYXJkcy10cmFjayBSRkNzLCBzdGF0ZSAiSUVURiIuIEZvciBvdGhlcnMsIGdpdmUgdGhl IG5hbWUgb2YgdGhlCiAgICAgICAgICAgICAgICByZXNwb25zaWJsZSBwYXJ0eS4gT3RoZXIgZGV0 YWlscyAoZS5nLiwgcG9zdGFsIGFkZHJlc3MsIGUtbWFpbCBhZGRyZXNzLCBob21lIHBhZ2UKICAg ICAgICAgICAgICAgIFVSSSkgbWF5IGFsc28gYmUgaW5jbHVkZWQuCiAgICAgICAgICAgICAgCjwv ZGQ+CjxkdD5TcGVjaWZpY2F0aW9uIGRvY3VtZW50KHMpOjwvZHQ+CjxkZD4KICAgICAgICAgICAg ICAgIAogICAgICAgICAgICAgICAgUmVmZXJlbmNlIHRvIHRoZSBkb2N1bWVudCB0aGF0IHNwZWNp ZmllcyB0aGUgdHlwZSwgcHJlZmVyYWJseSBpbmNsdWRpbmcgYSBVUkkgdGhhdAogICAgICAgICAg ICAgICAgY2FuIGJlIHVzZWQgdG8gcmV0cmlldmUgYSBjb3B5IG9mIHRoZSBkb2N1bWVudC4gQW4g aW5kaWNhdGlvbiBvZiB0aGUgcmVsZXZhbnQKICAgICAgICAgICAgICAgIHNlY3Rpb25zIG1heSBh bHNvIGJlIGluY2x1ZGVkLCBidXQgaXMgbm90IHJlcXVpcmVkLgogICAgICAgICAgICAgIAo8L2Rk Pgo8L2RsPjwvYmxvY2txdW90ZT48cD4KICAgICAgICAgIAo8L3A+CjxhIG5hbWU9ImFuY2hvcjUx Ij48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIw IiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNs YXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+ PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uMTEuMy4yIj48L2E+PGgzPjExLjMuMi4mbmJz cDsKSW5pdGlhbCBSZWdpc3RyeSBDb250ZW50czwvaDM+Cgo8cD4KICAgICAgICAgICAgVGhlIE9B dXRoIEF1dGhvcml6YXRpb24gRW5kcG9pbnQgUmVzcG9uc2UgVHlwZSBSZWdpc3RyeSdzIGluaXRp YWwgY29udGVudHMgYXJlOgogICAgICAgICAgCjwvcD4KPHA+CiAgICAgICAgICAgIDwvcD4KPHVs IGNsYXNzPSJ0ZXh0Ij4KPGxpPgogICAgICAgICAgICAgICAgUmVzcG9uc2UgdHlwZSBuYW1lOiBj b2RlCiAgICAgICAgICAgICAgCjwvbGk+CjxsaT4KICAgICAgICAgICAgICAgIENoYW5nZSBjb250 cm9sbGVyOiBJRVRGCiAgICAgICAgICAgICAgCjwvbGk+CjxsaT4KICAgICAgICAgICAgICAgIFNw ZWNpZmljYXRpb24gZG9jdW1lbnQocyk6IFtbIHRoaXMgZG9jdW1lbnQgXV0KICAgICAgICAgICAg ICAKPC9saT4KPC91bD48cD4KICAgICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgICA8L3A+Cjx1 bCBjbGFzcz0idGV4dCI+CjxsaT4KICAgICAgICAgICAgICAgIFJlc3BvbnNlIHR5cGUgbmFtZTog dG9rZW4KICAgICAgICAgICAgICAKPC9saT4KPGxpPgogICAgICAgICAgICAgICAgQ2hhbmdlIGNv bnRyb2xsZXI6IElFVEYKICAgICAgICAgICAgICAKPC9saT4KPGxpPgogICAgICAgICAgICAgICAg U3BlY2lmaWNhdGlvbiBkb2N1bWVudChzKTogW1sgdGhpcyBkb2N1bWVudCBdXQogICAgICAgICAg ICAgIAo8L2xpPgo8L3VsPjxwPgogICAgICAgICAgCjwvcD4KPGEgbmFtZT0iZXJyb3ItcmVnaXN0 cnkiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9 IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQg Y2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90 cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi4xMS40Ij48L2E+PGgzPjExLjQuJm5ic3A7 ClRoZSBPQXV0aCBFeHRlbnNpb25zIEVycm9yIFJlZ2lzdHJ5PC9oMz4KCjxwPgogICAgICAgICAg VGhpcyBzcGVjaWZpY2F0aW9uIGVzdGFibGlzaGVzIHRoZSBPQXV0aCBleHRlbnNpb25zIGVycm9y IHJlZ2lzdHJ5LgogICAgICAgIAo8L3A+CjxwPgogICAgICAgICAgQWRkaXRpb25hbCBlcnJvciBj b2RlcyB1c2VkIHRvZ2V0aGVyIHdpdGggb3RoZXIgcHJvdG9jb2wgZXh0ZW5zaW9ucyAoaS5lLiBl eHRlbnNpb24gZ3JhbnQKICAgICAgICAgIHR5cGVzLCBhY2Nlc3MgdG9rZW4gdHlwZXMsIG9yIGV4 dGVuc2lvbiBwYXJhbWV0ZXJzKSBhcmUgcmVnaXN0ZXJlZCB3aXRoIGEgU3BlY2lmaWNhdGlvbgog ICAgICAgICAgUmVxdWlyZWQgKDxhIGNsYXNzPSdpbmZvJyBocmVmPScjUkZDNTIyNic+W1JGQzUy MjZdPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPk5hcnRlbiwgVC4gYW5kIEguIEFs dmVzdHJhbmQsICZsZHF1bztHdWlkZWxpbmVzIGZvciBXcml0aW5nIGFuIElBTkEgQ29uc2lkZXJh dGlvbnMgU2VjdGlvbiBpbiBSRkNzLCZyZHF1bzsgTWF5Jm5ic3A7MjAwOC48L3NwYW4+PHNwYW4+ KTwvc3Bhbj48L2E+KSBhZnRlciBhIHR3byB3ZWVrIHJldmlldyBwZXJpb2Qgb24gdGhlCiAgICAg ICAgICBbVEJEXUBpZXRmLm9yZyBtYWlsaW5nIGxpc3QsIG9uIHRoZSBhZHZpY2Ugb2Ygb25lIG9y IG1vcmUgRGVzaWduYXRlZCBFeHBlcnRzLiBIb3dldmVyLCB0bwogICAgICAgICAgYWxsb3cgZm9y IHRoZSBhbGxvY2F0aW9uIG9mIHZhbHVlcyBwcmlvciB0byBwdWJsaWNhdGlvbiwgdGhlIERlc2ln bmF0ZWQgRXhwZXJ0KHMpIG1heQogICAgICAgICAgYXBwcm92ZSByZWdpc3RyYXRpb24gb25jZSB0 aGV5IGFyZSBzYXRpc2ZpZWQgdGhhdCBzdWNoIGEgc3BlY2lmaWNhdGlvbiB3aWxsIGJlIHB1Ymxp c2hlZC4KICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgIFJlZ2lzdHJhdGlvbiByZXF1ZXN0cyBt dXN0IGJlIHNlbnQgdG8gdGhlIFtUQkRdQGlldGYub3JnIG1haWxpbmcgbGlzdCBmb3IgcmV2aWV3 IGFuZAogICAgICAgICAgY29tbWVudCwgd2l0aCBhbiBhcHByb3ByaWF0ZSBzdWJqZWN0IChlLmcu LCAiUmVxdWVzdCBmb3IgZXJyb3IgY29kZTogZXhhbXBsZSIpLgogICAgICAgICAgW1sgTm90ZSB0 byBSRkMtRURJVE9SOiBUaGUgbmFtZSBvZiB0aGUgbWFpbGluZyBsaXN0IHNob3VsZCBiZSBkZXRl cm1pbmVkIGluIGNvbnN1bHRhdGlvbgogICAgICAgICAgd2l0aCB0aGUgSUVTRyBhbmQgSUFOQS4g U3VnZ2VzdGVkIG5hbWU6IG9hdXRoLWV4dC1yZXZpZXcuIF1dCiAgICAgICAgCjwvcD4KPHA+CiAg ICAgICAgICBXaXRoaW4gdGhlIHJldmlldyBwZXJpb2QsIHRoZSBEZXNpZ25hdGVkIEV4cGVydChz KSB3aWxsIGVpdGhlciBhcHByb3ZlIG9yCiAgICAgICAgICBkZW55IHRoZSByZWdpc3RyYXRpb24g cmVxdWVzdCwgY29tbXVuaWNhdGluZyB0aGlzIGRlY2lzaW9uIHRvIHRoZSByZXZpZXcgbGlzdCBh bmQgSUFOQS4KICAgICAgICAgIERlbmlhbHMgc2hvdWxkIGluY2x1ZGUgYW4gZXhwbGFuYXRpb24g YW5kLCBpZiBhcHBsaWNhYmxlLCBzdWdnZXN0aW9ucyBhcyB0byBob3cgdG8gbWFrZQogICAgICAg ICAgdGhlIHJlcXVlc3Qgc3VjY2Vzc2Z1bC4KICAgICAgICAKPC9wPgo8cD4KICAgICAgICAgIElB TkEgbXVzdCBvbmx5IGFjY2VwdCByZWdpc3RyeSB1cGRhdGVzIGZyb20gdGhlIERlc2lnbmF0ZWQg RXhwZXJ0KHMpLCBhbmQgc2hvdWxkIGRpcmVjdAogICAgICAgICAgYWxsIHJlcXVlc3RzIGZvciBy ZWdpc3RyYXRpb24gdG8gdGhlIHJldmlldyBtYWlsaW5nIGxpc3QuCiAgICAgICAgCjwvcD4KPGEg bmFtZT0iYW5jaG9yNTIiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIg Y2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmln aHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7 PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi4xMS40LjEiPjwvYT48 aDM+MTEuNC4xLiZuYnNwOwpSZWdpc3RyYXRpb24gVGVtcGxhdGU8L2gzPgoKPHA+CiAgICAgICAg ICAgIDwvcD4KPGJsb2NrcXVvdGUgY2xhc3M9InRleHQiPjxkbD4KPGR0PkVycm9yIG5hbWU6PC9k dD4KPGRkPgogICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICBUaGUgbmFtZSByZXF1ZXN0 ZWQgKGUuZy4sICJleGFtcGxlIikuCgkJVmFsdWVzIGZvciB0aGUgZXJyb3IgbmFtZSBNVVNUIE5P VCBpbmNsdWRlCgkJY2hhcmFjdGVycyBvdXRzaWRlIHRoZSBzZXQgJXgyMC0yMSAvICV4MjMtNUIg LyAleDVELTdFLgogICAgICAgICAgICAgIAo8L2RkPgo8ZHQ+RXJyb3IgdXNhZ2UgbG9jYXRpb246 PC9kdD4KPGRkPgogICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICBUaGUgbG9jYXRpb24o cykgd2hlcmUgdGhlIGVycm9yIGNhbiBiZSB1c2VkLiBUaGUgcG9zc2libGUgbG9jYXRpb25zIGFy ZToKICAgICAgICAgICAgICAgIGF1dGhvcml6YXRpb24gY29kZSBncmFudCBlcnJvciByZXNwb25z ZSAoPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNjb2RlLWF1dGh6LWVycm9yJz5TZWN0aW9uJm5ic3A7 NC4xLjIuMTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5FcnJvciBSZXNwb25zZTwv c3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4pLAogICAgICAgICAgICAgICAgaW1wbGljaXQgZ3JhbnQg ZXJyb3IgcmVzcG9uc2UgKDxhIGNsYXNzPSdpbmZvJyBocmVmPScjaW1wbGljaXQtYXV0aHotZXJy b3InPlNlY3Rpb24mbmJzcDs0LjIuMi4xPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8n PkVycm9yIFJlc3BvbnNlPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPiksCgkJdG9rZW4gZXJyb3Ig cmVzcG9uc2UgKDxhIGNsYXNzPSdpbmZvJyBocmVmPScjdG9rZW4tZXJyb3JzJz5TZWN0aW9uJm5i c3A7NS4yPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkVycm9yIFJlc3BvbnNlPC9z cGFuPjxzcGFuPik8L3NwYW4+PC9hPiksIG9yCgkJcmVzb3VyY2UgYWNjZXNzIGVycm9yIHJlc3Bv bnNlICg8YSBjbGFzcz0naW5mbycgaHJlZj0nI3Jlc291cmNlLWVycm9ycyc+U2VjdGlvbiZuYnNw OzcuMjxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5FcnJvciBSZXNwb25zZTwvc3Bh bj48c3Bhbj4pPC9zcGFuPjwvYT4pLgogICAgICAgICAgICAgIAo8L2RkPgo8ZHQ+UmVsYXRlZCBw cm90b2NvbCBleHRlbnNpb246PC9kdD4KPGRkPgogICAgICAgICAgICAgICAgCiAgICAgICAgICAg ICAgICBUaGUgbmFtZSBvZiB0aGUgZXh0ZW5zaW9uIGdyYW50IHR5cGUsIGFjY2VzcyB0b2tlbiB0 eXBlLCBvciBleHRlbnNpb24gcGFyYW1ldGVyLAogICAgICAgICAgICAgICAgdGhlIGVycm9yIGNv ZGUgaXMgdXNlZCBpbiBjb25qdW5jdGlvbiB3aXRoLgogICAgICAgICAgICAgIAo8L2RkPgo8ZHQ+ Q2hhbmdlIGNvbnRyb2xsZXI6PC9kdD4KPGRkPgogICAgICAgICAgICAgICAgCiAgICAgICAgICAg ICAgICBGb3Igc3RhbmRhcmRzLXRyYWNrIFJGQ3MsIHN0YXRlICJJRVRGIi4gRm9yIG90aGVycywg Z2l2ZSB0aGUgbmFtZSBvZiB0aGUKICAgICAgICAgICAgICAgIHJlc3BvbnNpYmxlIHBhcnR5LiBP dGhlciBkZXRhaWxzIChlLmcuLCBwb3N0YWwgYWRkcmVzcywgZS1tYWlsIGFkZHJlc3MsIGhvbWUg cGFnZQogICAgICAgICAgICAgICAgVVJJKSBtYXkgYWxzbyBiZSBpbmNsdWRlZC4KICAgICAgICAg ICAgICAKPC9kZD4KPGR0PlNwZWNpZmljYXRpb24gZG9jdW1lbnQocyk6PC9kdD4KPGRkPgogICAg ICAgICAgICAgICAgCiAgICAgICAgICAgICAgICBSZWZlcmVuY2UgdG8gdGhlIGRvY3VtZW50IHRo YXQgc3BlY2lmaWVzIHRoZSBlcnJvciBjb2RlLCBwcmVmZXJhYmx5IGluY2x1ZGluZyBhIFVSSQog ICAgICAgICAgICAgICAgdGhhdCBjYW4gYmUgdXNlZCB0byByZXRyaWV2ZSBhIGNvcHkgb2YgdGhl IGRvY3VtZW50LiBBbiBpbmRpY2F0aW9uIG9mIHRoZSByZWxldmFudAogICAgICAgICAgICAgICAg c2VjdGlvbnMgbWF5IGFsc28gYmUgaW5jbHVkZWQsIGJ1dCBpcyBub3QgcmVxdWlyZWQuCiAgICAg ICAgICAgICAgCjwvZGQ+CjwvZGw+PC9ibG9ja3F1b3RlPjxwPgogICAgICAgICAgCjwvcD4KPGEg bmFtZT0icmZjLnJlZmVyZW5jZXMiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9Imxh eW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGln bj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9D Jm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi4xMiI+PC9h PjxoMz4xMi4mbmJzcDsKUmVmZXJlbmNlczwvaDM+Cgo8YSBuYW1lPSJyZmMucmVmZXJlbmNlczEi PjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAi IGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xh c3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48 L3RhYmxlPgo8aDM+MTIuMS4mbmJzcDtOb3JtYXRpdmUgUmVmZXJlbmNlczwvaDM+Cjx0YWJsZSB3 aWR0aD0iOTklIiBib3JkZXI9IjAiPgo8dHI+PHRkIGNsYXNzPSJhdXRob3ItdGV4dCIgdmFsaWdu PSJ0b3AiPjxhIG5hbWU9IlJGQzIxMTkiPltSRkMyMTE5XTwvYT48L3RkPgo8dGQgY2xhc3M9ImF1 dGhvci10ZXh0Ij48YSBocmVmPSJtYWlsdG86c29iQGhhcnZhcmQuZWR1Ij5CcmFkbmVyLCBTLjwv YT4sICZsZHF1bzs8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmMyMTE5Ij5L ZXkgd29yZHMgZm9yIHVzZSBpbiBSRkNzIHRvIEluZGljYXRlIFJlcXVpcmVtZW50IExldmVsczwv YT4sJnJkcXVvOyBCQ1AmbmJzcDsxNCwgUkZDJm5ic3A7MjExOSwgTWFyY2gmbmJzcDsxOTk3ICg8 YSBocmVmPSJodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL3JmYy9yZmMyMTE5LnR4dCI+VFhUPC9h PiwgPGEgaHJlZj0iaHR0cDovL3htbC5yZXNvdXJjZS5vcmcvcHVibGljL3JmYy9odG1sL3JmYzIx MTkuaHRtbCI+SFRNTDwvYT4sIDxhIGhyZWY9Imh0dHA6Ly94bWwucmVzb3VyY2Uub3JnL3B1Ymxp Yy9yZmMveG1sL3JmYzIxMTkueG1sIj5YTUw8L2E+KS48L3RkPjwvdHI+Cjx0cj48dGQgY2xhc3M9 ImF1dGhvci10ZXh0IiB2YWxpZ249InRvcCI+PGEgbmFtZT0iUkZDMjI0NiI+W1JGQzIyNDZdPC9h PjwvdGQ+Cjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPjxhIGhyZWY9Im1haWx0bzp0ZGllcmtzQGNl cnRpY29tLmNvbSI+RGllcmtzLCBULjwvYT4gYW5kIDxhIGhyZWY9Im1haWx0bzpjYWxsZW5AY2Vy dGljb20uY29tIj5DLiBBbGxlbjwvYT4sICZsZHF1bzs8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9yZmMyMjQ2Ij5UaGUgVExTIFByb3RvY29sIFZlcnNpb24gMS4wPC9hPiwmcmRx dW87IFJGQyZuYnNwOzIyNDYsIEphbnVhcnkmbmJzcDsxOTk5ICg8YSBocmVmPSJodHRwOi8vd3d3 LnJmYy1lZGl0b3Iub3JnL3JmYy9yZmMyMjQ2LnR4dCI+VFhUPC9hPikuPC90ZD48L3RyPgo8dHI+ PHRkIGNsYXNzPSJhdXRob3ItdGV4dCIgdmFsaWduPSJ0b3AiPjxhIG5hbWU9IlJGQzI2MTYiPltS RkMyNjE2XTwvYT48L3RkPgo8dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij48YSBocmVmPSJtYWlsdG86 ZmllbGRpbmdAaWNzLnVjaS5lZHUiPkZpZWxkaW5nLCBSLjwvYT4sIDxhIGhyZWY9Im1haWx0bzpq Z0B3My5vcmciPkdldHR5cywgSi48L2E+LCA8YSBocmVmPSJtYWlsdG86bW9ndWxAd3JsLmRlYy5j b20iPk1vZ3VsLCBKLjwvYT4sIDxhIGhyZWY9Im1haWx0bzpmcnlzdHlrQHczLm9yZyI+RnJ5c3R5 aywgSC48L2E+LCA8YSBocmVmPSJtYWlsdG86bWFzaW50ZXJAcGFyYy54ZXJveC5jb20iPk1hc2lu dGVyLCBMLjwvYT4sIDxhIGhyZWY9Im1haWx0bzpwYXVsbGVAbWljcm9zb2Z0LmNvbSI+TGVhY2gs IFAuPC9hPiwgYW5kIDxhIGhyZWY9Im1haWx0bzp0aW1ibEB3My5vcmciPlQuIEJlcm5lcnMtTGVl PC9hPiwgJmxkcXVvOzxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzI2MTYi Pkh5cGVydGV4dCBUcmFuc2ZlciBQcm90b2NvbCAtLSBIVFRQLzEuMTwvYT4sJnJkcXVvOyBSRkMm bmJzcDsyNjE2LCBKdW5lJm5ic3A7MTk5OSAoPGEgaHJlZj0iaHR0cDovL3d3dy5yZmMtZWRpdG9y Lm9yZy9yZmMvcmZjMjYxNi50eHQiPlRYVDwvYT4sIDxhIGhyZWY9Imh0dHA6Ly93d3cucmZjLWVk aXRvci5vcmcvcmZjL3JmYzI2MTYucHMiPlBTPC9hPiwgPGEgaHJlZj0iaHR0cDovL3d3dy5yZmMt ZWRpdG9yLm9yZy9yZmMvcmZjMjYxNi5wZGYiPlBERjwvYT4sIDxhIGhyZWY9Imh0dHA6Ly94bWwu cmVzb3VyY2Uub3JnL3B1YmxpYy9yZmMvaHRtbC9yZmMyNjE2Lmh0bWwiPkhUTUw8L2E+LCA8YSBo cmVmPSJodHRwOi8veG1sLnJlc291cmNlLm9yZy9wdWJsaWMvcmZjL3htbC9yZmMyNjE2LnhtbCI+ WE1MPC9hPikuPC90ZD48L3RyPgo8dHI+PHRkIGNsYXNzPSJhdXRob3ItdGV4dCIgdmFsaWduPSJ0 b3AiPjxhIG5hbWU9IlJGQzI2MTciPltSRkMyNjE3XTwvYT48L3RkPgo8dGQgY2xhc3M9ImF1dGhv ci10ZXh0Ij48YSBocmVmPSJtYWlsdG86am9obkBtYXRoLm53dS5lZHUiPkZyYW5rcywgSi48L2E+ LCA8YSBocmVmPSJtYWlsdG86cGJha2VyQHZlcmlzaWduLmNvbSI+SGFsbGFtLUJha2VyLCBQLjwv YT4sIDxhIGhyZWY9Im1haWx0bzpqZWZmQEFiaVNvdXJjZS5jb20iPkhvc3RldGxlciwgSi48L2E+ LCA8YSBocmVmPSJtYWlsdG86bGF3cmVuY2VAYWdyYW5hdC5jb20iPkxhd3JlbmNlLCBTLjwvYT4s IDxhIGhyZWY9Im1haWx0bzpwYXVsbGVAbWljcm9zb2Z0LmNvbSI+TGVhY2gsIFAuPC9hPiwgTHVv dG9uZW4sIEEuLCBhbmQgPGEgaHJlZj0ibWFpbHRvOnN0ZXdhcnRAT3Blbk1hcmtldC5jb20iPkwu IFN0ZXdhcnQ8L2E+LCAmbGRxdW87PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv cmZjMjYxNyI+SFRUUCBBdXRoZW50aWNhdGlvbjogQmFzaWMgYW5kIERpZ2VzdCBBY2Nlc3MgQXV0 aGVudGljYXRpb248L2E+LCZyZHF1bzsgUkZDJm5ic3A7MjYxNywgSnVuZSZuYnNwOzE5OTkgKDxh IGhyZWY9Imh0dHA6Ly93d3cucmZjLWVkaXRvci5vcmcvcmZjL3JmYzI2MTcudHh0Ij5UWFQ8L2E+ LCA8YSBocmVmPSJodHRwOi8veG1sLnJlc291cmNlLm9yZy9wdWJsaWMvcmZjL2h0bWwvcmZjMjYx Ny5odG1sIj5IVE1MPC9hPiwgPGEgaHJlZj0iaHR0cDovL3htbC5yZXNvdXJjZS5vcmcvcHVibGlj L3JmYy94bWwvcmZjMjYxNy54bWwiPlhNTDwvYT4pLjwvdGQ+PC90cj4KPHRyPjx0ZCBjbGFzcz0i YXV0aG9yLXRleHQiIHZhbGlnbj0idG9wIj48YSBuYW1lPSJSRkMyODE4Ij5bUkZDMjgxOF08L2E+ PC90ZD4KPHRkIGNsYXNzPSJhdXRob3ItdGV4dCI+UmVzY29ybGEsIEUuLCAmbGRxdW87PGEgaHJl Zj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMjgxOCI+SFRUUCBPdmVyIFRMUzwvYT4s JnJkcXVvOyBSRkMmbmJzcDsyODE4LCBNYXkmbmJzcDsyMDAwICg8YSBocmVmPSJodHRwOi8vd3d3 LnJmYy1lZGl0b3Iub3JnL3JmYy9yZmMyODE4LnR4dCI+VFhUPC9hPikuPC90ZD48L3RyPgo8dHI+ PHRkIGNsYXNzPSJhdXRob3ItdGV4dCIgdmFsaWduPSJ0b3AiPjxhIG5hbWU9IlJGQzM5ODYiPltS RkMzOTg2XTwvYT48L3RkPgo8dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij48YSBocmVmPSJtYWlsdG86 dGltYmxAdzMub3JnIj5CZXJuZXJzLUxlZSwgVC48L2E+LCA8YSBocmVmPSJtYWlsdG86ZmllbGRp bmdAZ2Jpdi5jb20iPkZpZWxkaW5nLCBSLjwvYT4sIGFuZCA8YSBocmVmPSJtYWlsdG86TE1NQGFj bS5vcmciPkwuIE1hc2ludGVyPC9hPiwgJmxkcXVvOzxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRm Lm9yZy9odG1sL3JmYzM5ODYiPlVuaWZvcm0gUmVzb3VyY2UgSWRlbnRpZmllciAoVVJJKTogR2Vu ZXJpYyBTeW50YXg8L2E+LCZyZHF1bzsgU1REJm5ic3A7NjYsIFJGQyZuYnNwOzM5ODYsIEphbnVh cnkmbmJzcDsyMDA1ICg8YSBocmVmPSJodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL3JmYy9yZmMz OTg2LnR4dCI+VFhUPC9hPiwgPGEgaHJlZj0iaHR0cDovL3htbC5yZXNvdXJjZS5vcmcvcHVibGlj L3JmYy9odG1sL3JmYzM5ODYuaHRtbCI+SFRNTDwvYT4sIDxhIGhyZWY9Imh0dHA6Ly94bWwucmVz b3VyY2Uub3JnL3B1YmxpYy9yZmMveG1sL3JmYzM5ODYueG1sIj5YTUw8L2E+KS48L3RkPjwvdHI+ Cjx0cj48dGQgY2xhc3M9ImF1dGhvci10ZXh0IiB2YWxpZ249InRvcCI+PGEgbmFtZT0iUkZDNDYy NyI+W1JGQzQ2MjddPC9hPjwvdGQ+Cjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPkNyb2NrZm9yZCwg RC4sICZsZHF1bzs8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM0NjI3Ij5U aGUgYXBwbGljYXRpb24vanNvbiBNZWRpYSBUeXBlIGZvciBKYXZhU2NyaXB0IE9iamVjdCBOb3Rh dGlvbiAoSlNPTik8L2E+LCZyZHF1bzsgUkZDJm5ic3A7NDYyNywgSnVseSZuYnNwOzIwMDYgKDxh IGhyZWY9Imh0dHA6Ly93d3cucmZjLWVkaXRvci5vcmcvcmZjL3JmYzQ2MjcudHh0Ij5UWFQ8L2E+ KS48L3RkPjwvdHI+Cjx0cj48dGQgY2xhc3M9ImF1dGhvci10ZXh0IiB2YWxpZ249InRvcCI+PGEg bmFtZT0iUkZDNDk0OSI+W1JGQzQ5NDldPC9hPjwvdGQ+Cjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQi PlNoaXJleSwgUi4sICZsZHF1bzs8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9y ZmM0OTQ5Ij5JbnRlcm5ldCBTZWN1cml0eSBHbG9zc2FyeSwgVmVyc2lvbiAyPC9hPiwmcmRxdW87 IFJGQyZuYnNwOzQ5NDksIEF1Z3VzdCZuYnNwOzIwMDcgKDxhIGhyZWY9Imh0dHA6Ly93d3cucmZj LWVkaXRvci5vcmcvcmZjL3JmYzQ5NDkudHh0Ij5UWFQ8L2E+KS48L3RkPjwvdHI+Cjx0cj48dGQg Y2xhc3M9ImF1dGhvci10ZXh0IiB2YWxpZ249InRvcCI+PGEgbmFtZT0iUkZDNTIyNiI+W1JGQzUy MjZdPC9hPjwvdGQ+Cjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPk5hcnRlbiwgVC4gYW5kIEguIEFs dmVzdHJhbmQsICZsZHF1bzs8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1 MjI2Ij5HdWlkZWxpbmVzIGZvciBXcml0aW5nIGFuIElBTkEgQ29uc2lkZXJhdGlvbnMgU2VjdGlv biBpbiBSRkNzPC9hPiwmcmRxdW87IEJDUCZuYnNwOzI2LCBSRkMmbmJzcDs1MjI2LCBNYXkmbmJz cDsyMDA4ICg8YSBocmVmPSJodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL3JmYy9yZmM1MjI2LnR4 dCI+VFhUPC9hPikuPC90ZD48L3RyPgo8dHI+PHRkIGNsYXNzPSJhdXRob3ItdGV4dCIgdmFsaWdu PSJ0b3AiPjxhIG5hbWU9IlJGQzUyMzQiPltSRkM1MjM0XTwvYT48L3RkPgo8dGQgY2xhc3M9ImF1 dGhvci10ZXh0Ij5Dcm9ja2VyLCBELiBhbmQgUC4gT3ZlcmVsbCwgJmxkcXVvOzxhIGhyZWY9Imh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzUyMzQiPkF1Z21lbnRlZCBCTkYgZm9yIFN5bnRh eCBTcGVjaWZpY2F0aW9uczogQUJORjwvYT4sJnJkcXVvOyBTVEQmbmJzcDs2OCwgUkZDJm5ic3A7 NTIzNCwgSmFudWFyeSZuYnNwOzIwMDggKDxhIGhyZWY9Imh0dHA6Ly93d3cucmZjLWVkaXRvci5v cmcvcmZjL3JmYzUyMzQudHh0Ij5UWFQ8L2E+KS48L3RkPjwvdHI+Cjx0cj48dGQgY2xhc3M9ImF1 dGhvci10ZXh0IiB2YWxpZ249InRvcCI+PGEgbmFtZT0iUkZDNTI0NiI+W1JGQzUyNDZdPC9hPjwv dGQ+Cjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPkRpZXJrcywgVC4gYW5kIEUuIFJlc2NvcmxhLCAm bGRxdW87PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTI0NiI+VGhlIFRy YW5zcG9ydCBMYXllciBTZWN1cml0eSAoVExTKSBQcm90b2NvbCBWZXJzaW9uIDEuMjwvYT4sJnJk cXVvOyBSRkMmbmJzcDs1MjQ2LCBBdWd1c3QmbmJzcDsyMDA4ICg8YSBocmVmPSJodHRwOi8vd3d3 LnJmYy1lZGl0b3Iub3JnL3JmYy9yZmM1MjQ2LnR4dCI+VFhUPC9hPikuPC90ZD48L3RyPgo8dHI+ PHRkIGNsYXNzPSJhdXRob3ItdGV4dCIgdmFsaWduPSJ0b3AiPjxhIG5hbWU9IlJGQzYxMjUiPltS RkM2MTI1XTwvYT48L3RkPgo8dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij5TYWludC1BbmRyZSwgUC4g YW5kIEouIEhvZGdlcywgJmxkcXVvOzxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L3JmYzYxMjUiPlJlcHJlc2VudGF0aW9uIGFuZCBWZXJpZmljYXRpb24gb2YgRG9tYWluLUJhc2Vk IEFwcGxpY2F0aW9uIFNlcnZpY2UgSWRlbnRpdHkgd2l0aGluIEludGVybmV0IFB1YmxpYyBLZXkg SW5mcmFzdHJ1Y3R1cmUgVXNpbmcgWC41MDkgKFBLSVgpIENlcnRpZmljYXRlcyBpbiB0aGUgQ29u dGV4dCBvZiBUcmFuc3BvcnQgTGF5ZXIgU2VjdXJpdHkgKFRMUyk8L2E+LCZyZHF1bzsgUkZDJm5i c3A7NjEyNSwgTWFyY2gmbmJzcDsyMDExICg8YSBocmVmPSJodHRwOi8vd3d3LnJmYy1lZGl0b3Iu b3JnL3JmYy9yZmM2MTI1LnR4dCI+VFhUPC9hPikuPC90ZD48L3RyPgo8dHI+PHRkIGNsYXNzPSJh dXRob3ItdGV4dCIgdmFsaWduPSJ0b3AiPjxhIG5hbWU9IlVTQVNDSUkiPltVU0FTQ0lJXTwvYT48 L3RkPgo8dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij5BbWVyaWNhbiBOYXRpb25hbCBTdGFuZGFyZHMg SW5zdGl0dXRlLCAmbGRxdW87Q29kZWQgQ2hhcmFjdGVyIFNldCAtLSA3LWJpdCBBbWVyaWNhbiBT dGFuZGFyZCBDb2RlIGZvciBJbmZvcm1hdGlvbiBJbnRlcmNoYW5nZSwmcmRxdW87IEFOU0kmbmJz cDtYMy40LCAxOTg2LjwvdGQ+PC90cj4KPHRyPjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiIHZhbGln bj0idG9wIj48YSBuYW1lPSJXM0MuUkVDLWh0bWw0MDEtMTk5OTEyMjQiPltXM0MuUkVDLWh0bWw0 MDEtMTk5OTEyMjRdPC9hPjwvdGQ+Cjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPkhvcnMsIEEuLCBS YWdnZXR0LCBELiwgYW5kIEkuIEphY29icywgJmxkcXVvOzxhIGhyZWY9Imh0dHA6Ly93d3cudzMu b3JnL1RSLzE5OTkvUkVDLWh0bWw0MDEtMTk5OTEyMjQiPkhUTUwgNC4wMSBTcGVjaWZpY2F0aW9u PC9hPiwmcmRxdW87IFdvcmxkIFdpZGUgV2ViIENvbnNvcnRpdW0gUmVjb21tZW5kYXRpb24mbmJz cDtSRUMtaHRtbDQwMS0xOTk5MTIyNCwgRGVjZW1iZXImbmJzcDsxOTk5ICg8YSBocmVmPSJodHRw Oi8vd3d3LnczLm9yZy9UUi8xOTk5L1JFQy1odG1sNDAxLTE5OTkxMjI0Ij5IVE1MPC9hPikuPC90 ZD48L3RyPgo8L3RhYmxlPgoKPGEgbmFtZT0icmZjLnJlZmVyZW5jZXMyIj48L2E+PGJyIC8+PGhy IC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0i MiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxh IGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGgzPjEy LjIuJm5ic3A7SW5mb3JtYXRpdmUgUmVmZXJlbmNlczwvaDM+Cjx0YWJsZSB3aWR0aD0iOTklIiBi b3JkZXI9IjAiPgo8dHI+PHRkIGNsYXNzPSJhdXRob3ItdGV4dCIgdmFsaWduPSJ0b3AiPjxhIG5h bWU9IkktRC5kcmFmdC1oYXJkdC1vYXV0aC0wMSI+W0ktRC5kcmFmdC1oYXJkdC1vYXV0aC0wMV08 L2E+PC90ZD4KPHRkIGNsYXNzPSJhdXRob3ItdGV4dCI+SGFyZHQsIEQuLCBFZC4sIFRvbSwgQS4s IEVhdG9uLCBCLiwgYW5kIFkuIEdvbGFuZCwgJmxkcXVvOzxhIGhyZWY9Imh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWhhcmR0LW9hdXRoLTAxIj5PQXV0aCBXZWIgUmVzb3VyY2UgQXV0 aG9yaXphdGlvbiBQcm9maWxlczwvYT4sJnJkcXVvOyBKYW51YXJ5Jm5ic3A7MjAxMC48L3RkPjwv dHI+Cjx0cj48dGQgY2xhc3M9ImF1dGhvci10ZXh0IiB2YWxpZ249InRvcCI+PGEgbmFtZT0iSS1E LmlldGYtaHR0cGJpcy1wNy1hdXRoIj5bSS1ELmlldGYtaHR0cGJpcy1wNy1hdXRoXTwvYT48L3Rk Pgo8dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij5GaWVsZGluZywgUi4sIExhZm9uLCBZLiwgYW5kIEou IFJlc2Noa2UsICZsZHF1bzs8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1pZXRmLWh0dHBiaXMtcDctYXV0aC0xOSI+SFRUUC8xLjEsIHBhcnQgNzogQXV0aGVudGljYXRp b248L2E+LCZyZHF1bzsgZHJhZnQtaWV0Zi1odHRwYmlzLXA3LWF1dGgtMTkgKHdvcmsgaW4gcHJv Z3Jlc3MpLCBNYXJjaCZuYnNwOzIwMTIgKDxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50 ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtaHR0cGJpcy1wNy1hdXRoLTE5LnR4dCI+VFhUPC9hPiku PC90ZD48L3RyPgo8dHI+PHRkIGNsYXNzPSJhdXRob3ItdGV4dCIgdmFsaWduPSJ0b3AiPjxhIG5h bWU9IkktRC5pZXRmLW9hdXRoLXNhbWwyLWJlYXJlciI+W0ktRC5pZXRmLW9hdXRoLXNhbWwyLWJl YXJlcl08L2E+PC90ZD4KPHRkIGNsYXNzPSJhdXRob3ItdGV4dCI+TW9ydGltb3JlLCBDLiwgJmxk cXVvOzxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgt c2FtbDItYmVhcmVyLTEyIj5TQU1MIDIuMCBCZWFyZXIgQXNzZXJ0aW9uIFByb2ZpbGVzIGZvciBP QXV0aCAyLjA8L2E+LCZyZHF1bzsgZHJhZnQtaWV0Zi1vYXV0aC1zYW1sMi1iZWFyZXItMTIgKHdv cmsgaW4gcHJvZ3Jlc3MpLCBNYXkmbmJzcDsyMDEyICg8YSBocmVmPSJodHRwOi8vd3d3LmlldGYu b3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLW9hdXRoLXNhbWwyLWJlYXJlci0xMi50eHQi PlRYVDwvYT4pLjwvdGQ+PC90cj4KPHRyPjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiIHZhbGlnbj0i dG9wIj48YSBuYW1lPSJJLUQuaWV0Zi1vYXV0aC12Mi1iZWFyZXIiPltJLUQuaWV0Zi1vYXV0aC12 Mi1iZWFyZXJdPC9hPjwvdGQ+Cjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPkpvbmVzLCBNLiwgSGFy ZHQsIEQuLCBhbmQgRC4gUmVjb3Jkb24sICZsZHF1bzs8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLXYyLWJlYXJlci0yMCI+VGhlIE9BdXRoIDIuMCBB dXRob3JpemF0aW9uIEZyYW1ld29yazogQmVhcmVyIFRva2VuIFVzYWdlPC9hPiwmcmRxdW87IGRy YWZ0LWlldGYtb2F1dGgtdjItYmVhcmVyLTIwICh3b3JrIGluIHByb2dyZXNzKSwgSnVuZSZuYnNw OzIwMTIgKDxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0 LWlldGYtb2F1dGgtdjItYmVhcmVyLTIwLnR4dCI+VFhUPC9hPiwgPGEgaHJlZj0iaHR0cDovL3d3 dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1vYXV0aC12Mi1iZWFyZXItMjAu cGRmIj5QREY8L2E+KS48L3RkPjwvdHI+Cjx0cj48dGQgY2xhc3M9ImF1dGhvci10ZXh0IiB2YWxp Z249InRvcCI+PGEgbmFtZT0iSS1ELmlldGYtb2F1dGgtdjItaHR0cC1tYWMiPltJLUQuaWV0Zi1v YXV0aC12Mi1odHRwLW1hY108L2E+PC90ZD4KPHRkIGNsYXNzPSJhdXRob3ItdGV4dCI+SGFtbWVy LUxhaGF2LCBFLiwgJmxkcXVvOzxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWlldGYtb2F1dGgtdjItaHR0cC1tYWMtMDEiPkhUVFAgQXV0aGVudGljYXRpb246IE1BQyBB Y2Nlc3MgQXV0aGVudGljYXRpb248L2E+LCZyZHF1bzsgZHJhZnQtaWV0Zi1vYXV0aC12Mi1odHRw LW1hYy0wMSAod29yayBpbiBwcm9ncmVzcyksIEZlYnJ1YXJ5Jm5ic3A7MjAxMiAoPGEgaHJlZj0i aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1vYXV0aC12Mi1o dHRwLW1hYy0wMS50eHQiPlRYVDwvYT4sIDxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50 ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtb2F1dGgtdjItaHR0cC1tYWMtMDEucGRmIj5QREY8L2E+ KS48L3RkPjwvdHI+Cjx0cj48dGQgY2xhc3M9ImF1dGhvci10ZXh0IiB2YWxpZ249InRvcCI+PGEg bmFtZT0iSS1ELmlldGYtb2F1dGgtdjItdGhyZWF0bW9kZWwiPltJLUQuaWV0Zi1vYXV0aC12Mi10 aHJlYXRtb2RlbF08L2E+PC90ZD4KPHRkIGNsYXNzPSJhdXRob3ItdGV4dCI+TG9kZGVyc3RlZHQs IFQuLCBNY0dsb2luLCBNLiwgYW5kIFAuIEh1bnQsICZsZHF1bzs8YSBocmVmPSJodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLXYyLXRocmVhdG1vZGVsLTA1Ij5PQXV0 aCAyLjAgVGhyZWF0IE1vZGVsIGFuZCBTZWN1cml0eSBDb25zaWRlcmF0aW9uczwvYT4sJnJkcXVv OyBkcmFmdC1pZXRmLW9hdXRoLXYyLXRocmVhdG1vZGVsLTA1ICh3b3JrIGluIHByb2dyZXNzKSwg TWF5Jm5ic3A7MjAxMiAoPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFm dHMvZHJhZnQtaWV0Zi1vYXV0aC12Mi10aHJlYXRtb2RlbC0wNS50eHQiPlRYVDwvYT4pLjwvdGQ+ PC90cj4KPHRyPjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiIHZhbGlnbj0idG9wIj48YSBuYW1lPSJS RkM1ODQ5Ij5bUkZDNTg0OV08L2E+PC90ZD4KPHRkIGNsYXNzPSJhdXRob3ItdGV4dCI+SGFtbWVy LUxhaGF2LCBFLiwgJmxkcXVvOzxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3Jm YzU4NDkiPlRoZSBPQXV0aCAxLjAgUHJvdG9jb2w8L2E+LCZyZHF1bzsgUkZDJm5ic3A7NTg0OSwg QXByaWwmbmJzcDsyMDEwICg8YSBocmVmPSJodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL3JmYy9y ZmM1ODQ5LnR4dCI+VFhUPC9hPikuPC90ZD48L3RyPgo8L3RhYmxlPgoKPGEgbmFtZT0iYW5jaG9y NTUiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9 IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQg Y2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90 cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi5BIj48L2E+PGgzPkFwcGVuZGl4IEEuJm5i c3A7CkF1Z21lbnRlZCBCYWNrdXMtTmF1ciBGb3JtIChBQk5GKSBTeW50YXg8L2gzPgoKPHA+CglU aGlzIHNlY3Rpb24gcHJvdmlkZXMgQXVnbWVudGVkIEJhY2t1cy1OYXVyIEZvcm0gKEFCTkYpIHN5 bnRheAoJZGVzY3JpcHRpb25zIGZvciB0aGUgZWxlbWVudHMgZGVmaW5lZCBpbiB0aGlzIHNwZWNp ZmljYXRpb24KCXVzaW5nIHRoZSBub3RhdGlvbiBvZiA8YSBjbGFzcz0naW5mbycgaHJlZj0nI1JG QzUyMzQnPltSRkM1MjM0XTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5Dcm9ja2Vy LCBELiBhbmQgUC4gT3ZlcmVsbCwgJmxkcXVvO0F1Z21lbnRlZCBCTkYgZm9yIFN5bnRheCBTcGVj aWZpY2F0aW9uczogQUJORiwmcmRxdW87IEphbnVhcnkmbmJzcDsyMDA4Ljwvc3Bhbj48c3Bhbj4p PC9zcGFuPjwvYT4uCglFbGVtZW50cyBhcmUgcHJlc2VudGVkIGluIHRoZSBvcmRlciBmaXJzdCBk ZWZpbmVkLgogICAgICAKPC9wPgo8cD4KCVNvbWUgb2YgdGhlIGRlZmluaXRpb25zIHRoYXQgZm9s bG93IHVzZSB0aGUKCTx0dD5VUkktcmVmZXJlbmNlPC90dD4KCWRlZmluaXRpb24gZnJvbSA8YSBj bGFzcz0naW5mbycgaHJlZj0nI1JGQzM5ODYnPltSRkMzOTg2XTxzcGFuPiAoPC9zcGFuPjxzcGFu IGNsYXNzPSdpbmZvJz5CZXJuZXJzLUxlZSwgVC4sIEZpZWxkaW5nLCBSLiwgYW5kIEwuIE1hc2lu dGVyLCAmbGRxdW87VW5pZm9ybSBSZXNvdXJjZSBJZGVudGlmaWVyIChVUkkpOiBHZW5lcmljIFN5 bnRheCwmcmRxdW87IEphbnVhcnkmbmJzcDsyMDA1Ljwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4u CiAgICAgIAo8L3A+CjxwPgoJICBTb21lIG9mIHRoZSBkZWZpbml0aW9ucyB0aGF0IGZvbGxvdyB1 c2UgdGhlc2UgY29tbW9uIGRlZmluaXRpb25zOgoJCjwvcD48ZGl2IHN0eWxlPSdkaXNwbGF5OiB0 YWJsZTsgd2lkdGg6IDA7IG1hcmdpbi1sZWZ0OiAzZW07IG1hcmdpbi1yaWdodDogYXV0byc+PHBy ZT4KVlNDSEFSICAgICA9ICUyMC03RQpOUUNIQVIgICAgID0gJXgyMSAvICV4MjMtNUIgLyAleDVE LTdFCk5RU0NIQVIgICAgPSAleDIwLTIxIC8gJXgyMy01QiAvICV4NUQtN0UKVU5JQ09ERU5PQ1RS TENIQVIgPSAmbHQ7QW55IFVuaWNvZGUgY2hhcmFjdGVyIG90aGVyIHRoYW4gKCAleDAtMUYgLyAl eDdGICkmZ3Q7CjwvcHJlPjwvZGl2Pgo8YSBuYW1lPSJhbmNob3I1NiI+PC9hPjxiciAvPjxociAv Pgo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIi IGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBo cmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9 InJmYy5zZWN0aW9uLkEuMSI+PC9hPjxoMz5BLjEuJm5ic3A7CiJjbGllbnRfaWQiIFN5bnRheDwv aDM+Cgo8cD4KCSAgICBUaGUgPHR0PmNsaWVudF9pZDwvdHQ+IGVsZW1lbnQgaXMgZGVmaW5lZCBp bgoJICAgIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjY2xpZW50LXBhc3N3b3JkJz5TZWN0aW9uJm5i c3A7Mi4zLjE8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+Q2xpZW50IFBhc3N3b3Jk PC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPjoKCSAgCjwvcD48ZGl2IHN0eWxlPSdkaXNwbGF5OiB0 YWJsZTsgd2lkdGg6IDA7IG1hcmdpbi1sZWZ0OiAzZW07IG1hcmdpbi1yaWdodDogYXV0byc+PHBy ZT4KY2xpZW50LWlkICAgICA9ICpWU0NIQVIKPC9wcmU+PC9kaXY+CjxhIG5hbWU9ImFuY2hvcjU3 Ij48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIw IiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNs YXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+ PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uQS4yIj48L2E+PGgzPkEuMi4mbmJzcDsKImNs aWVudF9zZWNyZXQiIFN5bnRheDwvaDM+Cgo8cD4KCSAgICBUaGUgPHR0PmNsaWVudF9zZWNyZXQ8 L3R0PiBlbGVtZW50IGlzIGRlZmluZWQgaW4KCSAgICA8YSBjbGFzcz0naW5mbycgaHJlZj0nI2Ns aWVudC1wYXNzd29yZCc+U2VjdGlvbiZuYnNwOzIuMy4xPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xh c3M9J2luZm8nPkNsaWVudCBQYXNzd29yZDwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT46CgkgIAo8 L3A+PGRpdiBzdHlsZT0nZGlzcGxheTogdGFibGU7IHdpZHRoOiAwOyBtYXJnaW4tbGVmdDogM2Vt OyBtYXJnaW4tcmlnaHQ6IGF1dG8nPjxwcmU+CmNsaWVudC1zZWNyZXQgPSAqVlNDSEFSCjwvcHJl PjwvZGl2Pgo8YSBuYW1lPSJhbmNob3I1OCI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFy eT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWci IGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJz cDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLkEu MyI+PC9hPjxoMz5BLjMuJm5ic3A7CiJyZXNwb25zZV90eXBlIiBTeW50YXg8L2gzPgoKPHA+Cgkg ICAgVGhlIDx0dD5yZXNwb25zZV90eXBlPC90dD4gZWxlbWVudCBpcyBkZWZpbmVkIGluCgkgICAg PGEgY2xhc3M9J2luZm8nIGhyZWY9JyNyZXNwb25zZS10eXBlJz5TZWN0aW9uJm5ic3A7My4xLjE8 c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+UmVzcG9uc2UgVHlwZTwvc3Bhbj48c3Bh bj4pPC9zcGFuPjwvYT4gYW5kCgkgICAgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNyZXNwb25zZS10 eXBlLWV4dCc+U2VjdGlvbiZuYnNwOzguNDxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZv Jz5EZWZpbmluZyBOZXcgQXV0aG9yaXphdGlvbiBFbmRwb2ludCBSZXNwb25zZSBUeXBlczwvc3Bh bj48c3Bhbj4pPC9zcGFuPjwvYT46CgkgIAo8L3A+PGRpdiBzdHlsZT0nZGlzcGxheTogdGFibGU7 IHdpZHRoOiAwOyBtYXJnaW4tbGVmdDogM2VtOyBtYXJnaW4tcmlnaHQ6IGF1dG8nPjxwcmU+CnJl c3BvbnNlLXR5cGUgPSByZXNwb25zZS1uYW1lICooIFNQIHJlc3BvbnNlLW5hbWUgKQpyZXNwb25z ZS1uYW1lID0gMSpyZXNwb25zZS1jaGFyCnJlc3BvbnNlLWNoYXIgPSAiXyIgLyBESUdJVCAvIEFM UEhBCjwvcHJlPjwvZGl2Pgo8YSBuYW1lPSJhbmNob3I1OSI+PC9hPjxiciAvPjxociAvPgo8dGFi bGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNz PSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIj dG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5z ZWN0aW9uLkEuNCI+PC9hPjxoMz5BLjQuJm5ic3A7CiJzY29wZSIgU3ludGF4PC9oMz4KCjxwPgoJ ICAgIFRoZSA8dHQ+c2NvcGU8L3R0PiBlbGVtZW50IGlzIGRlZmluZWQgaW4KCSAgICA8YSBjbGFz cz0naW5mbycgaHJlZj0nI3Njb3BlJz5TZWN0aW9uJm5ic3A7My4zPHNwYW4+ICg8L3NwYW4+PHNw YW4gY2xhc3M9J2luZm8nPkFjY2VzcyBUb2tlbiBTY29wZTwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwv YT46CgkgIAo8L3A+PGRpdiBzdHlsZT0nZGlzcGxheTogdGFibGU7IHdpZHRoOiAwOyBtYXJnaW4t bGVmdDogM2VtOyBtYXJnaW4tcmlnaHQ6IGF1dG8nPjxwcmU+CnNjb3BlICAgICAgID0gc2NvcGUt dG9rZW4gKiggU1Agc2NvcGUtdG9rZW4gKQpzY29wZS10b2tlbiA9IDEqTlFDSEFSCjwvcHJlPjwv ZGl2Pgo8YSBuYW1lPSJhbmNob3I2MCI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0i bGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFs aWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtU T0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLkEuNSI+ PC9hPjxoMz5BLjUuJm5ic3A7CiJzdGF0ZSIgU3ludGF4PC9oMz4KCjxwPgoJICAgIFRoZSA8dHQ+ c3RhdGU8L3R0PiBlbGVtZW50IGlzIGRlZmluZWQgaW4KCSAgICA8YSBjbGFzcz0naW5mbycgaHJl Zj0nI2NvZGUtYXV0aHotcmVxJz5TZWN0aW9uJm5ic3A7NC4xLjE8c3Bhbj4gKDwvc3Bhbj48c3Bh biBjbGFzcz0naW5mbyc+QXV0aG9yaXphdGlvbiBSZXF1ZXN0PC9zcGFuPjxzcGFuPik8L3NwYW4+ PC9hPiwKCSAgICA8YSBjbGFzcz0naW5mbycgaHJlZj0nI2NvZGUtYXV0aHotcmVzcCc+U2VjdGlv biZuYnNwOzQuMS4yPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkF1dGhvcml6YXRp b24gUmVzcG9uc2U8L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+LAoJICAgIDxhIGNsYXNzPSdpbmZv JyBocmVmPScjY29kZS1hdXRoei1lcnJvcic+U2VjdGlvbiZuYnNwOzQuMS4yLjE8c3Bhbj4gKDwv c3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+RXJyb3IgUmVzcG9uc2U8L3NwYW4+PHNwYW4+KTwvc3Bh bj48L2E+LAoJICAgIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjaW1wbGljaXQtYXV0aHotcmVxJz5T ZWN0aW9uJm5ic3A7NC4yLjE8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+QXV0aG9y aXphdGlvbiBSZXF1ZXN0PC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPiwKCSAgICA8YSBjbGFzcz0n aW5mbycgaHJlZj0nI2ltcGxpY2l0LWF1dGh6LXJlc3AnPlNlY3Rpb24mbmJzcDs0LjIuMjxzcGFu PiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5BY2Nlc3MgVG9rZW4gUmVzcG9uc2U8L3NwYW4+ PHNwYW4+KTwvc3Bhbj48L2E+LCBhbmQKCSAgICA8YSBjbGFzcz0naW5mbycgaHJlZj0nI2ltcGxp Y2l0LWF1dGh6LWVycm9yJz5TZWN0aW9uJm5ic3A7NC4yLjIuMTxzcGFuPiAoPC9zcGFuPjxzcGFu IGNsYXNzPSdpbmZvJz5FcnJvciBSZXNwb25zZTwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT46Cgkg IAo8L3A+PGRpdiBzdHlsZT0nZGlzcGxheTogdGFibGU7IHdpZHRoOiAwOyBtYXJnaW4tbGVmdDog M2VtOyBtYXJnaW4tcmlnaHQ6IGF1dG8nPjxwcmU+CnN0YXRlICAgICAgPSAxKlZTQ0hBUgo8L3By ZT48L2Rpdj4KPGEgbmFtZT0iYW5jaG9yNjEiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1h cnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVn IiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5i c3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi5B LjYiPjwvYT48aDM+QS42LiZuYnNwOwoicmVkaXJlY3RfdXJpIiBTeW50YXg8L2gzPgoKPHA+Cgkg ICAgVGhlIDx0dD5yZWRpcmVjdF91cmk8L3R0PiBlbGVtZW50IGlzIGRlZmluZWQgaW4KCSAgICA8 YSBjbGFzcz0naW5mbycgaHJlZj0nI2NvZGUtYXV0aHotcmVxJz5TZWN0aW9uJm5ic3A7NC4xLjE8 c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+QXV0aG9yaXphdGlvbiBSZXF1ZXN0PC9z cGFuPjxzcGFuPik8L3NwYW4+PC9hPiwKCSAgICA8YSBjbGFzcz0naW5mbycgaHJlZj0nI3Rva2Vu LXJlcSc+U2VjdGlvbiZuYnNwOzQuMS4zPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8n PkFjY2VzcyBUb2tlbiBSZXF1ZXN0PC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPiwgYW5kCgkgICAg PGEgY2xhc3M9J2luZm8nIGhyZWY9JyNpbXBsaWNpdC1hdXRoei1yZXEnPlNlY3Rpb24mbmJzcDs0 LjIuMTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5BdXRob3JpemF0aW9uIFJlcXVl c3Q8L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+OgoJICAKPC9wPjxkaXYgc3R5bGU9J2Rpc3BsYXk6 IHRhYmxlOyB3aWR0aDogMDsgbWFyZ2luLWxlZnQ6IDNlbTsgbWFyZ2luLXJpZ2h0OiBhdXRvJz48 cHJlPgpyZWRpcmVjdC11cmkgICAgICA9IFVSSS1yZWZlcmVuY2UKPC9wcmU+PC9kaXY+CjxhIG5h bWU9ImFuY2hvcjYyIj48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNl bGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0 Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwv YT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uQS43Ij48L2E+PGgzPkEu Ny4mbmJzcDsKImVycm9yIiBTeW50YXg8L2gzPgoKPHA+CgkgICAgVGhlIDx0dD5lcnJvcjwvdHQ+ IGVsZW1lbnQgaXMgZGVmaW5lZCBpbgoJICAgIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjY29kZS1h dXRoei1lcnJvcic+U2VjdGlvbiZuYnNwOzQuMS4yLjE8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFz cz0naW5mbyc+RXJyb3IgUmVzcG9uc2U8L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+LAoJICAgIDxh IGNsYXNzPSdpbmZvJyBocmVmPScjaW1wbGljaXQtYXV0aHotZXJyb3InPlNlY3Rpb24mbmJzcDs0 LjIuMi4xPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkVycm9yIFJlc3BvbnNlPC9z cGFuPjxzcGFuPik8L3NwYW4+PC9hPiwKCSAgICA8YSBjbGFzcz0naW5mbycgaHJlZj0nI3Rva2Vu LWVycm9ycyc+U2VjdGlvbiZuYnNwOzUuMjxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZv Jz5FcnJvciBSZXNwb25zZTwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4sCgkgICAgPGEgY2xhc3M9 J2luZm8nIGhyZWY9JyNyZXNvdXJjZS1lcnJvcnMnPlNlY3Rpb24mbmJzcDs3LjI8c3Bhbj4gKDwv c3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+RXJyb3IgUmVzcG9uc2U8L3NwYW4+PHNwYW4+KTwvc3Bh bj48L2E+LCBhbmQKCSAgICA8YSBjbGFzcz0naW5mbycgaHJlZj0nI25ldy1lcnJvcnMnPlNlY3Rp b24mbmJzcDs4LjU8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+RGVmaW5pbmcgQWRk aXRpb25hbCBFcnJvciBDb2Rlczwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT46CgkgIAo8L3A+PGRp diBzdHlsZT0nZGlzcGxheTogdGFibGU7IHdpZHRoOiAwOyBtYXJnaW4tbGVmdDogM2VtOyBtYXJn aW4tcmlnaHQ6IGF1dG8nPjxwcmU+CmVycm9yICAgICAgICAgICAgID0gMSpOUVNDSEFSCjwvcHJl PjwvZGl2Pgo8YSBuYW1lPSJhbmNob3I2MyI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFy eT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWci IGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJz cDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLkEu OCI+PC9hPjxoMz5BLjguJm5ic3A7CiJlcnJvcl9kZXNjcmlwdGlvbiIgU3ludGF4PC9oMz4KCjxw PgoJICAgIFRoZSA8dHQ+ZXJyb3JfZGVzY3JpcHRpb248L3R0PiBlbGVtZW50IGlzIGRlZmluZWQg aW4KCSAgICA8YSBjbGFzcz0naW5mbycgaHJlZj0nI2NvZGUtYXV0aHotZXJyb3InPlNlY3Rpb24m bmJzcDs0LjEuMi4xPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkVycm9yIFJlc3Bv bnNlPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPiwKCSAgICA8YSBjbGFzcz0naW5mbycgaHJlZj0n I2ltcGxpY2l0LWF1dGh6LWVycm9yJz5TZWN0aW9uJm5ic3A7NC4yLjIuMTxzcGFuPiAoPC9zcGFu PjxzcGFuIGNsYXNzPSdpbmZvJz5FcnJvciBSZXNwb25zZTwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwv YT4sCgkgICAgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyN0b2tlbi1lcnJvcnMnPlNlY3Rpb24mbmJz cDs1LjI8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+RXJyb3IgUmVzcG9uc2U8L3Nw YW4+PHNwYW4+KTwvc3Bhbj48L2E+LCBhbmQKCSAgICA8YSBjbGFzcz0naW5mbycgaHJlZj0nI3Jl c291cmNlLWVycm9ycyc+U2VjdGlvbiZuYnNwOzcuMjxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNz PSdpbmZvJz5FcnJvciBSZXNwb25zZTwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT46CgkgIAo8L3A+ PGRpdiBzdHlsZT0nZGlzcGxheTogdGFibGU7IHdpZHRoOiAwOyBtYXJnaW4tbGVmdDogM2VtOyBt YXJnaW4tcmlnaHQ6IGF1dG8nPjxwcmU+CmVycm9yLWRlc2NyaXB0aW9uID0gMSpOUVNDSEFSCjwv cHJlPjwvZGl2Pgo8YSBuYW1lPSJhbmNob3I2NCI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3Vt bWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0Ni dWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4m bmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9u LkEuOSI+PC9hPjxoMz5BLjkuJm5ic3A7CiJlcnJvcl91cmkiIFN5bnRheDwvaDM+Cgo8cD4KCSAg ICBUaGUgPHR0PmVycm9yX3VyaTwvdHQ+IGVsZW1lbnQgaXMgZGVmaW5lZCBpbgoJICAgIDxhIGNs YXNzPSdpbmZvJyBocmVmPScjY29kZS1hdXRoei1lcnJvcic+U2VjdGlvbiZuYnNwOzQuMS4yLjE8 c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+RXJyb3IgUmVzcG9uc2U8L3NwYW4+PHNw YW4+KTwvc3Bhbj48L2E+LAoJICAgIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjaW1wbGljaXQtYXV0 aHotZXJyb3InPlNlY3Rpb24mbmJzcDs0LjIuMi4xPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9 J2luZm8nPkVycm9yIFJlc3BvbnNlPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPiwKCSAgICA8YSBj bGFzcz0naW5mbycgaHJlZj0nI3Rva2VuLWVycm9ycyc+U2VjdGlvbiZuYnNwOzUuMjxzcGFuPiAo PC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5FcnJvciBSZXNwb25zZTwvc3Bhbj48c3Bhbj4pPC9z cGFuPjwvYT4sIGFuZAoJICAgIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjcmVzb3VyY2UtZXJyb3Jz Jz5TZWN0aW9uJm5ic3A7Ny4yPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkVycm9y IFJlc3BvbnNlPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPjoKCSAgCjwvcD48ZGl2IHN0eWxlPSdk aXNwbGF5OiB0YWJsZTsgd2lkdGg6IDA7IG1hcmdpbi1sZWZ0OiAzZW07IG1hcmdpbi1yaWdodDog YXV0byc+PHByZT4KZXJyb3ItdXJpICAgICAgICAgPSBVUkktcmVmZXJlbmNlCjwvcHJlPjwvZGl2 Pgo8YSBuYW1lPSJhbmNob3I2NSI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0ibGF5 b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWdu PSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0Mm bmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLkEuMTAiPjwv YT48aDM+QS4xMC4mbmJzcDsKImdyYW50X3R5cGUiIFN5bnRheDwvaDM+Cgo8cD4KCSAgICBUaGUg PHR0PmdyYW50X3R5cGU8L3R0PiBlbGVtZW50IGlzIGRlZmluZWQgaW4KCSAgICA8YSBjbGFzcz0n aW5mbycgaHJlZj0nI3Rva2VuLXJlcSc+U2VjdGlvbiZuYnNwOzQuMS4zPHNwYW4+ICg8L3NwYW4+ PHNwYW4gY2xhc3M9J2luZm8nPkFjY2VzcyBUb2tlbiBSZXF1ZXN0PC9zcGFuPjxzcGFuPik8L3Nw YW4+PC9hPiwKCSAgICA8YSBjbGFzcz0naW5mbycgaHJlZj0nI3Bhc3N3b3JkLXRvay1yZXEnPlNl Y3Rpb24mbmJzcDs0LjMuMjxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5BY2Nlc3Mg VG9rZW4gUmVxdWVzdDwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4sCgkgICAgPGEgY2xhc3M9J2lu Zm8nIGhyZWY9JyNjbGllbnQtcmVxJz5TZWN0aW9uJm5ic3A7NC40LjI8c3Bhbj4gKDwvc3Bhbj48 c3BhbiBjbGFzcz0naW5mbyc+QWNjZXNzIFRva2VuIFJlcXVlc3Q8L3NwYW4+PHNwYW4+KTwvc3Bh bj48L2E+LAoJICAgIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjdG9rZW4tcmVmcmVzaCc+U2VjdGlv biZuYnNwOzY8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+UmVmcmVzaGluZyBhbiBB Y2Nlc3MgVG9rZW48L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+LCBhbmQKCSAgICA8YSBjbGFzcz0n aW5mbycgaHJlZj0nI2V4dC1ncmFudCc+U2VjdGlvbiZuYnNwOzQuNTxzcGFuPiAoPC9zcGFuPjxz cGFuIGNsYXNzPSdpbmZvJz5FeHRlbnNpb24gR3JhbnRzPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9h PjoKCSAgCjwvcD48ZGl2IHN0eWxlPSdkaXNwbGF5OiB0YWJsZTsgd2lkdGg6IDA7IG1hcmdpbi1s ZWZ0OiAzZW07IG1hcmdpbi1yaWdodDogYXV0byc+PHByZT4KZ3JhbnQtdHlwZSA9IGdyYW50LW5h bWUgLyBVUkktcmVmZXJlbmNlCmdyYW50LW5hbWUgPSAxKm5hbWUtY2hhcgpuYW1lLWNoYXIgID0g Ii0iIC8gIi4iIC8gIl8iIC8gRElHSVQgLyBBTFBIQQo8L3ByZT48L2Rpdj4KPGEgbmFtZT0iYW5j aG9yNjYiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRp bmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48 dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+ PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi5BLjExIj48L2E+PGgzPkEuMTEuJm5i c3A7CiJjb2RlIiBTeW50YXg8L2gzPgoKPHA+CgkgICAgVGhlIDx0dD5jb2RlPC90dD4gZWxlbWVu dCBpcyBkZWZpbmVkIGluCgkgICAgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyN0b2tlbi1yZXEnPlNl Y3Rpb24mbmJzcDs0LjEuMzxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5BY2Nlc3Mg VG9rZW4gUmVxdWVzdDwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT46CgkgIAo8L3A+PGRpdiBzdHls ZT0nZGlzcGxheTogdGFibGU7IHdpZHRoOiAwOyBtYXJnaW4tbGVmdDogM2VtOyBtYXJnaW4tcmln aHQ6IGF1dG8nPjxwcmU+CmNvZGUgICAgICAgPSAxKlZTQ0hBUgo8L3ByZT48L2Rpdj4KPGEgbmFt ZT0iYW5jaG9yNjciPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2Vs bHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQi Pjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9h PjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi5BLjEyIj48L2E+PGgzPkEu MTIuJm5ic3A7CiJhY2Nlc3NfdG9rZW4iIFN5bnRheDwvaDM+Cgo8cD4KCSAgICBUaGUgPHR0PmFj Y2Vzc190b2tlbjwvdHQ+IGVsZW1lbnQgaXMgZGVmaW5lZCBpbgoJICAgIDxhIGNsYXNzPSdpbmZv JyBocmVmPScjaW1wbGljaXQtYXV0aHotcmVzcCc+U2VjdGlvbiZuYnNwOzQuMi4yPHNwYW4+ICg8 L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkFjY2VzcyBUb2tlbiBSZXNwb25zZTwvc3Bhbj48c3Bh bj4pPC9zcGFuPjwvYT4gYW5kCgkgICAgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyN0b2tlbi1yZXNw b25zZSc+U2VjdGlvbiZuYnNwOzUuMTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5T dWNjZXNzZnVsIFJlc3BvbnNlPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPjoKCSAgCjwvcD48ZGl2 IHN0eWxlPSdkaXNwbGF5OiB0YWJsZTsgd2lkdGg6IDA7IG1hcmdpbi1sZWZ0OiAzZW07IG1hcmdp bi1yaWdodDogYXV0byc+PHByZT4KYWNjZXNzLXRva2VuID0gMSpWU0NIQVIKPC9wcmU+PC9kaXY+ CjxhIG5hbWU9ImFuY2hvcjY4Ij48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlv dXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249 InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZu YnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uQS4xMyI+PC9h PjxoMz5BLjEzLiZuYnNwOwoidG9rZW5fdHlwZSIgU3ludGF4PC9oMz4KCjxwPgoJICAgIFRoZSA8 dHQ+dG9rZW5fdHlwZTwvdHQ+IGVsZW1lbnQgaXMgZGVmaW5lZCBpbgoJICAgIDxhIGNsYXNzPSdp bmZvJyBocmVmPScjaW1wbGljaXQtYXV0aHotcmVzcCc+U2VjdGlvbiZuYnNwOzQuMi4yPHNwYW4+ ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkFjY2VzcyBUb2tlbiBSZXNwb25zZTwvc3Bhbj48 c3Bhbj4pPC9zcGFuPjwvYT4sCgkgICAgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyN0b2tlbi1yZXNw b25zZSc+U2VjdGlvbiZuYnNwOzUuMTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5T dWNjZXNzZnVsIFJlc3BvbnNlPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPiwgYW5kCgkgICAgPGEg Y2xhc3M9J2luZm8nIGhyZWY9JyNuZXctdHlwZXMnPlNlY3Rpb24mbmJzcDs4LjE8c3Bhbj4gKDwv c3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+RGVmaW5pbmcgQWNjZXNzIFRva2VuIFR5cGVzPC9zcGFu PjxzcGFuPik8L3NwYW4+PC9hPjoKCSAgCjwvcD48ZGl2IHN0eWxlPSdkaXNwbGF5OiB0YWJsZTsg d2lkdGg6IDA7IG1hcmdpbi1sZWZ0OiAzZW07IG1hcmdpbi1yaWdodDogYXV0byc+PHByZT4KdG9r ZW4tdHlwZSA9IHR5cGUtbmFtZSAvIFVSSS1yZWZlcmVuY2UKdHlwZS1uYW1lICA9IDEqbmFtZS1j aGFyCm5hbWUtY2hhciAgPSAiLSIgLyAiLiIgLyAiXyIgLyBESUdJVCAvIEFMUEhBCjwvcHJlPjwv ZGl2Pgo8YSBuYW1lPSJhbmNob3I2OSI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0i bGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFs aWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtU T0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLkEuMTQi PjwvYT48aDM+QS4xNC4mbmJzcDsKImV4cGlyZXNfaW4iIFN5bnRheDwvaDM+Cgo8cD4KCSAgICBU aGUgPHR0PmV4cGlyZXNfaW48L3R0PiBlbGVtZW50IGlzIGRlZmluZWQgaW4KCSAgICA8YSBjbGFz cz0naW5mbycgaHJlZj0nI2ltcGxpY2l0LWF1dGh6LXJlc3AnPlNlY3Rpb24mbmJzcDs0LjIuMjxz cGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5BY2Nlc3MgVG9rZW4gUmVzcG9uc2U8L3Nw YW4+PHNwYW4+KTwvc3Bhbj48L2E+IGFuZAoJICAgIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjdG9r ZW4tcmVzcG9uc2UnPlNlY3Rpb24mbmJzcDs1LjE8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0n aW5mbyc+U3VjY2Vzc2Z1bCBSZXNwb25zZTwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT46CgkgIAo8 L3A+PGRpdiBzdHlsZT0nZGlzcGxheTogdGFibGU7IHdpZHRoOiAwOyBtYXJnaW4tbGVmdDogM2Vt OyBtYXJnaW4tcmlnaHQ6IGF1dG8nPjxwcmU+CmV4cGlyZXMtaW4gPSAxKkRJR0lUCjwvcHJlPjwv ZGl2Pgo8YSBuYW1lPSJhbmNob3I3MCI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3VtbWFyeT0i bGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFs aWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtU T0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9uLkEuMTUi PjwvYT48aDM+QS4xNS4mbmJzcDsKInVzZXJuYW1lIiBTeW50YXg8L2gzPgoKPHA+CgkgICAgVGhl IDx0dD51c2VybmFtZTwvdHQ+IGVsZW1lbnQgaXMgZGVmaW5lZCBpbgoJICAgIDxhIGNsYXNzPSdp bmZvJyBocmVmPScjcGFzc3dvcmQtdG9rLXJlcSc+U2VjdGlvbiZuYnNwOzQuMy4yPHNwYW4+ICg8 L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkFjY2VzcyBUb2tlbiBSZXF1ZXN0PC9zcGFuPjxzcGFu Pik8L3NwYW4+PC9hPjoKCSAgCjwvcD48ZGl2IHN0eWxlPSdkaXNwbGF5OiB0YWJsZTsgd2lkdGg6 IDA7IG1hcmdpbi1sZWZ0OiAzZW07IG1hcmdpbi1yaWdodDogYXV0byc+PHByZT4KdXNlcm5hbWUg PSAqVU5JQ09ERU5PQ1RSTENIQVIKPC9wcmU+PC9kaXY+CjxhIG5hbWU9ImFuY2hvcjcxIj48L2E+ PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxs c3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJU T0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJs ZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uQS4xNiI+PC9hPjxoMz5BLjE2LiZuYnNwOwoicGFzc3dv cmQiIFN5bnRheDwvaDM+Cgo8cD4KCSAgICBUaGUgPHR0PnBhc3N3b3JkPC90dD4gZWxlbWVudCBp cyBkZWZpbmVkIGluCgkgICAgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNwYXNzd29yZC10b2stcmVx Jz5TZWN0aW9uJm5ic3A7NC4zLjI8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+QWNj ZXNzIFRva2VuIFJlcXVlc3Q8L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+OgoJICAKPC9wPjxkaXYg c3R5bGU9J2Rpc3BsYXk6IHRhYmxlOyB3aWR0aDogMDsgbWFyZ2luLWxlZnQ6IDNlbTsgbWFyZ2lu LXJpZ2h0OiBhdXRvJz48cHJlPgpwYXNzd29yZCA9ICpVTklDT0RFTk9DVFJMQ0hBUgo8L3ByZT48 L2Rpdj4KPGEgbmFtZT0iYW5jaG9yNzIiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1bW1hcnk9 ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBh bGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7 VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlvbi5BLjE3 Ij48L2E+PGgzPkEuMTcuJm5ic3A7CiJyZWZyZXNoX3Rva2VuIiBTeW50YXg8L2gzPgoKPHA+Cgkg ICAgVGhlIDx0dD5yZWZyZXNoX3Rva2VuPC90dD4gZWxlbWVudCBpcyBkZWZpbmVkIGluCgkgICAg PGEgY2xhc3M9J2luZm8nIGhyZWY9JyN0b2tlbi1yZXNwb25zZSc+U2VjdGlvbiZuYnNwOzUuMTxz cGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5TdWNjZXNzZnVsIFJlc3BvbnNlPC9zcGFu PjxzcGFuPik8L3NwYW4+PC9hPiBhbmQKCSAgICA8YSBjbGFzcz0naW5mbycgaHJlZj0nI3Rva2Vu LXJlZnJlc2gnPlNlY3Rpb24mbmJzcDs2PHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8n PlJlZnJlc2hpbmcgYW4gQWNjZXNzIFRva2VuPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPjoKCSAg CjwvcD48ZGl2IHN0eWxlPSdkaXNwbGF5OiB0YWJsZTsgd2lkdGg6IDA7IG1hcmdpbi1sZWZ0OiAz ZW07IG1hcmdpbi1yaWdodDogYXV0byc+PHByZT4KcmVmcmVzaC10b2tlbiA9IDEqVlNDSEFSCjwv cHJlPjwvZGl2Pgo8YSBuYW1lPSJhbmNob3I3MyI+PC9hPjxiciAvPjxociAvPgo8dGFibGUgc3Vt bWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0Ni dWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4m bmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+CjxhIG5hbWU9InJmYy5zZWN0aW9u LkEuMTgiPjwvYT48aDM+QS4xOC4mbmJzcDsKRW5kcG9pbnQgUGFyYW1ldGVyIFN5bnRheDwvaDM+ Cgo8cD4KCSAgICBUaGUgc3ludGF4IGZvciBuZXcgZW5kcG9pbnQgcGFyYW1ldGVycyBpcyBkZWZp bmVkIGluCgkgICAgPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNlbmRwb2ludC1wYXJhbXMnPlNlY3Rp b24mbmJzcDs4LjI8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+RGVmaW5pbmcgTmV3 IEVuZHBvaW50IFBhcmFtZXRlcnM8L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+OgoJICAKPC9wPjxk aXYgc3R5bGU9J2Rpc3BsYXk6IHRhYmxlOyB3aWR0aDogMDsgbWFyZ2luLWxlZnQ6IDNlbTsgbWFy Z2luLXJpZ2h0OiBhdXRvJz48cHJlPgpwYXJhbS1uYW1lID0gMSpuYW1lLWNoYXIKbmFtZS1jaGFy ICA9ICItIiAvICIuIiAvICJfIiAvIERJR0lUIC8gQUxQSEEKPC9wcmU+PC9kaXY+CjxhIG5hbWU9 ImFuY2hvcjc0Ij48L2E+PGJyIC8+PGhyIC8+Cjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxw YWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48 dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48 L3RkPjwvdHI+PC90YWJsZT4KPGEgbmFtZT0icmZjLnNlY3Rpb24uQiI+PC9hPjxoMz5BcHBlbmRp eCBCLiZuYnNwOwpBY2tub3dsZWRnZW1lbnRzPC9oMz4KCjxwPgogICAgICAgIFRoZSBpbml0aWFs IE9BdXRoIDIuMCBwcm90b2NvbCBzcGVjaWZpY2F0aW9uIHdhcyBlZGl0ZWQgYnkgRGF2aWQgUmVj b3Jkb24sIGJhc2VkIG9uIHR3bwogICAgICAgIHByZXZpb3VzIHB1YmxpY2F0aW9uczogdGhlIE9B dXRoIDEuMCBjb21tdW5pdHkgc3BlY2lmaWNhdGlvbiA8YSBjbGFzcz0naW5mbycgaHJlZj0nI1JG QzU4NDknPltSRkM1ODQ5XTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5IYW1tZXIt TGFoYXYsIEUuLCAmbGRxdW87VGhlIE9BdXRoIDEuMCBQcm90b2NvbCwmcmRxdW87IEFwcmlsJm5i c3A7MjAxMC48L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+LCBhbmQKICAgICAgICBPQXV0aCBXUkFQ IChPQXV0aCBXZWIgUmVzb3VyY2UgQXV0aG9yaXphdGlvbiBQcm9maWxlcykKICAgICAgICA8YSBj bGFzcz0naW5mbycgaHJlZj0nI0ktRC5kcmFmdC1oYXJkdC1vYXV0aC0wMSc+W0kmIzgyMDk7RC5k cmFmdCYjODIwOTtoYXJkdCYjODIwOTtvYXV0aCYjODIwOTswMV08c3Bhbj4gKDwvc3Bhbj48c3Bh biBjbGFzcz0naW5mbyc+SGFyZHQsIEQuLCBFZC4sIFRvbSwgQS4sIEVhdG9uLCBCLiwgYW5kIFku IEdvbGFuZCwgJmxkcXVvO09BdXRoIFdlYiBSZXNvdXJjZSBBdXRob3JpemF0aW9uIFByb2ZpbGVz LCZyZHF1bzsgSmFudWFyeSZuYnNwOzIwMTAuPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPi4gVGhl IFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIHNlY3Rpb24gd2FzIGRyYWZ0ZWQKICAgICAgICBieSBU b3JzdGVuIExvZGRlcnN0ZWR0LCBNYXJrIE1jR2xvaW4sIFBoaWwgSHVudCwgYW5kIEFudGhvbnkg TmFkYWxpbi4KCVRoZSBBQk5GIHNlY3Rpb24gd2FzIGRyYWZ0ZWQgYnkgTWljaGFlbCBCLiBKb25l cy4KICAgICAgCjwvcD4KPHA+CiAgICAgICAgVGhlIE9BdXRoIDEuMCBjb21tdW5pdHkgc3BlY2lm aWNhdGlvbiB3YXMgZWRpdGVkIGJ5IEVyYW4gSGFtbWVyIGFuZCBhdXRob3JlZCBieQogICAgICAg IE1hcmsgQXR3b29kLCBEaXJrIEJhbGZhbnosIERhcnJlbiBCb3VuZHMsIFJpY2hhcmQgTS4gQ29u bGFuLCBCbGFpbmUgQ29vaywgTGVhaCBDdWx2ZXIsCiAgICAgICAgQnJlbm8gZGUgTWVkZWlyb3Ms IEJyaWFuIEVhdG9uLCBLZWxsYW4gRWxsaW90dC1NY0NyZWEsIExhcnJ5IEhhbGZmLCBFcmFuIEhh bW1lciwKICAgICAgICBCZW4gTGF1cmllLCBDaHJpcyBNZXNzaW5hLCBKb2huIFBhbnplciwgU2Ft IFF1aWdsZXksIERhdmlkIFJlY29yZG9uLCBFcmFuIFNhbmRsZXIsCiAgICAgICAgSm9uYXRoYW4g U2VyZ2VudCwgVG9kZCBTaWVsaW5nLCBCcmlhbiBTbGVzaW5za3ksIGFuZCBBbmR5IFNtaXRoLgog ICAgICAKPC9wPgo8cD4KICAgICAgICBUaGUgT0F1dGggV1JBUCBzcGVjaWZpY2F0aW9uIHdhcyBl ZGl0ZWQgYnkgRGljayBIYXJkdCBhbmQgYXV0aG9yZWQgYnkgQnJpYW4gRWF0b24sCiAgICAgICAg WWFyb24gWS4gR29sYW5kLCBEaWNrIEhhcmR0LCBhbmQgQWxsZW4gVG9tLgogICAgICAKPC9wPgo8 cD4KICAgICAgICBUaGlzIHNwZWNpZmljYXRpb24gaXMgdGhlIHdvcmsgb2YgdGhlIE9BdXRoIFdv cmtpbmcgR3JvdXAgd2hpY2ggaW5jbHVkZXMgZG96ZW5zIG9mIGFjdGl2ZQogICAgICAgIGFuZCBk ZWRpY2F0ZWQgcGFydGljaXBhbnRzLiBJbiBwYXJ0aWN1bGFyLCB0aGUgZm9sbG93aW5nIGluZGl2 aWR1YWxzIGNvbnRyaWJ1dGVkIGlkZWFzLAogICAgICAgIGZlZWRiYWNrLCBhbmQgd29yZGluZyB3 aGljaCBzaGFwZWQgYW5kIGZvcm1lZCB0aGUgZmluYWwgc3BlY2lmaWNhdGlvbjoKICAgICAgCjwv cD4KPHA+CiAgICAgICAgTWljaGFlbCBBZGFtcywgQW1hbmRhIEFuZ2FuZXMsIEFuZHJldyBBcm5v dHQsIERpcmsgQmFsZmFueiwgQWlkZW4gQmVsbCwgSm9obiBCcmFkbGV5LCBCcmlhbiBDYW1wYmVs bCwKICAgICAgICBTY290dCBDYW50b3IsIE1hcmNvcyBDYWNlcmVzLCBCbGFpbmUgQ29vaywgUm9n ZXIgQ3JldywgQnJpYW4gRWF0b24sIFdlc2xleSBFZGR5LCBMZWFoIEN1bHZlciwKICAgICAgICBC aWxsIGRlIGhPcmEsIEFuZHJlIERlTWFycmUsIEJyaWFuIEVhdG9uLCBXb2x0ZXIgRWxkZXJpbmcs IEJyaWFuIEVsbGluLCBJZ29yIEZheW5iZXJnLAogICAgICAgIEdlb3JnZSBGbGV0Y2hlciwgVGlt IEZyZWVtYW4sIEx1Y2EgRnJvc2luaSwgRXZhbiBHaWxiZXJ0LCBZYXJvbiBZLiBHb2xhbmQsIEJy ZW50IEdvbGRtYW4sCiAgICAgICAgS3Jpc3RvZmZlciBHcm9ub3dza2ksIEp1c3RpbiBIYXJ0LCBE aWNrIEhhcmR0LCBDcmFpZyBIZWF0aCwgUGhpbCBIdW50LCBNaWNoYWVsIEIuIEpvbmVzLAogICAg ICAgIFRlcnJ5IEpvbmVzLCBKb2huIEtlbXAsIE1hcmsgS2VudCwgUmFmZmkgS3Jpa29yaWFuLCBD aGFzZW4gTGUgSGFyYSwgUmFzbXVzIExlcmRvcmYsCiAgICAgICAgVG9yc3RlbiBMb2RkZXJzdGVk dCwgSHVpLUxhbiBMdSwgQ2FzZXkgTHVjYXMsIFBhdWwgTWFkc2VuLCBBbGFzdGFpciBNYWlyLCBF dmUgTWFsZXIsCiAgICAgICAgSmFtZXMgTWFuZ2VyLCBNYXJrIE1jR2xvaW4sIExhdXJlbmNlIE1p YW8sIFdpbGxpYW0gTWlsbHMsIENodWNrIE1vcnRpbW9yZSwgQW50aG9ueSBOYWRhbGluLAogICAg ICAgIEp1bGlhbiBSZXNjaGtlLCBKdXN0aW4gUmljaGVyLCBQZXRlciBTYWludC1BbmRyZSwgTmF0 IFNha2ltdXJhLCBSb2IgU2F5cmUsCiAgICAgICAgTWFyaXVzIFNjdXJ0ZXNjdSwgTmFpdGlrIFNo YWgsIEx1a2UgU2hlcGFyZCwgVmxhZCBTa3ZvcnRzb3YsIEp1c3RpbiBTbWl0aCwgSGFpYmluIFNv bmcsCiAgICAgICAgTml2IFN0ZWluZ2FydGVuLCBDaHJpc3RpYW4gU3R1ZWJuZXIsIEplcmVteSBT dXJpZWwsIFBhdWwgVGFyamFuLCBDaHJpc3RvcGhlciBUaG9tYXMsCiAgICAgICAgSGVucnkgUy4g VGhvbXBzb24sIEFsbGVuIFRvbSwgRnJhbmtsaW4gVHNlLCBOaWNrIFdhbGtlciwgU2hhbmUgV2Vl ZGVuLCBhbmQgU2t5bGFyIFdvb2R3YXJkLgogICAgICAKPC9wPgo8cD4KICAgICAgICBUaGlzIGRv Y3VtZW50IHdhcyBwcm9kdWNlZCB1bmRlciB0aGUgY2hhaXJtYW5zaGlwIG9mIEJsYWluZSBDb29r LCBQZXRlciBTYWludC1BbmRyZSwKICAgICAgICBIYW5uZXMgVHNjaG9mZW5pZywgQmFycnkgTGVp YmEsIGFuZCBEZXJlayBBdGtpbnMuIFRoZSBhcmVhIGRpcmVjdG9ycyBpbmNsdWRlZCBMaXNhIER1 c3NlYXVsdCwKICAgICAgICBQZXRlciBTYWludC1BbmRyZSwgYW5kIFN0ZXBoZW4gRmFycmVsbC4K ICAgICAgCjwvcD4KPGEgbmFtZT0iYW5jaG9yNzUiPjwvYT48YnIgLz48aHIgLz4KPHRhYmxlIHN1 bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9D YnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+ Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPgo8YSBuYW1lPSJyZmMuc2VjdGlv bi5DIj48L2E+PGgzPkFwcGVuZGl4IEMuJm5ic3A7CkVkaXRvcidzIE5vdGVzPC9oMz4KCjxwPgog ICAgICAgIFdoaWxlIG1hbnkgcGVvcGxlIGNvbnRyaWJ1dGVkIHRvIHRoaXMgc3BlY2lmaWNhdGlv biB0aHJvdWdob3V0IGl0cyBsb25nIGpvdXJuZXksIHRoZSBlZGl0b3IKICAgICAgICB3b3VsZCBs aWtlIHRvIGFja25vd2xlZGdlIGFuZCB0aGFuayBhIGZldyBpbmRpdmlkdWFscyBmb3IgdGhlaXIg b3V0c3RhbmRpbmcgYW5kIGludmFsdWFibGUKICAgICAgICBlZmZvcnRzIGxlYWRpbmcgdXAgdG8g dGhlIHB1YmxpY2F0aW9uIG9mIHRoaXMgc3BlY2lmaWNhdGlvbi4KICAgICAgCjwvcD4KPHA+CiAg ICAgICAgRGF2aWQgUmVjb3Jkb24gZm9yIGNvbnRpbnVvdXNseSBiZWluZyBvbmUgb2YgT0F1dGgn cyBtb3N0IHZhbHVhYmxlIGFzc2V0cywgYnJpbmdpbmcKICAgICAgICBwcmFnbWF0aXNtIGFuZCB1 cmdlbmN5IHRvIHRoZSB3b3JrLCBhbmQgaGVscGluZyBzaGFwZSBpdCBmcm9tIGl0cyB2ZXJ5IGJl Z2lubmluZywgYXMgd2VsbAogICAgICAgIGFzIGJlaW5nIG9uZSBvZiB0aGUgYmVzdCBjb2xsYWJv cmF0b3JzIEkgaGFkIHRoZSBwbGVhc3VyZSBvZiB3b3JraW5nIHdpdGguCiAgICAgIAo8L3A+Cjxw PgogICAgICAgIEphbWVzIE1hbmdlciBmb3IgaGlzIGNyZWF0aXZlIGlkZWFzIGFuZCBhbHdheXMg aW5zaWdodGZ1bCBmZWVkYmFjay4gQnJpYW4gQ2FtcGJlbGwsCiAgICAgICAgVG9yc3RlbiBMb2Rk ZXJzdGVkdCwgQ2h1Y2sgTW9ydGltb3JlLCBKdXN0aW4gUmljaGVyLCBNYXJpdXMgU2N1cnRlc2N1 LCBhbmQgTHVrZSBTaGVwYXJkIGZvcgogICAgICAgIHRoZWlyIGNvbnRpbnVlZCBwYXJ0aWNpcGF0 aW9uIGFuZCB2YWx1YWJsZSBmZWVkYmFjay4KICAgICAgCjwvcD4KPHA+CiAgICAgICAgU3BlY2lh bCB0aGFua3MgZ29lcyB0byBNaWtlIEN1cnRpcyBhbmQgWWFob28hIGZvciB0aGVpciB1bmNvbmRp dGlvbmFsIHN1cHBvcnQgb2YgdGhpcyB3b3JrCiAgICAgICAgZm9yIG92ZXIgdGhyZWUgeWVhcnMu CiAgICAgIAo8L3A+CjxhIG5hbWU9InJmYy5hdXRob3JzIj48L2E+PGJyIC8+PGhyIC8+Cjx0YWJs ZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9 IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0 b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4KPGgzPkF1dGhvcnMnIEFk ZHJlc3NlczwvaDM+Cjx0YWJsZSB3aWR0aD0iOTklIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIw IiBjZWxsc3BhY2luZz0iMCI+Cjx0cj48dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij4mbmJzcDs8L3Rk Pgo8dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij5FcmFuIEhhbW1lciAoZWRpdG9yKTwvdGQ+PC90cj4K PHRyPjx0ZCBjbGFzcz0iYXV0aG9yIiBhbGlnbj0icmlnaHQiPkVtYWlsOiZuYnNwOzwvdGQ+Cjx0 ZCBjbGFzcz0iYXV0aG9yLXRleHQiPjxhIGhyZWY9Im1haWx0bzplcmFuQGh1ZW5pdmVyc2UuY29t Ij5lcmFuQGh1ZW5pdmVyc2UuY29tPC9hPjwvdGQ+PC90cj4KPHRyPjx0ZCBjbGFzcz0iYXV0aG9y IiBhbGlnbj0icmlnaHQiPlVSSTombmJzcDs8L3RkPgo8dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij48 YSBocmVmPSJodHRwOi8vaHVlbml2ZXJzZS5jb20iPmh0dHA6Ly9odWVuaXZlcnNlLmNvbTwvYT48 L3RkPjwvdHI+Cjx0ciBjZWxscGFkZGluZz0iMyI+PHRkPiZuYnNwOzwvdGQ+PHRkPiZuYnNwOzwv dGQ+PC90cj4KPHRyPjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPiZuYnNwOzwvdGQ+Cjx0ZCBjbGFz cz0iYXV0aG9yLXRleHQiPkRhdmlkIFJlY29yZG9uPC90ZD48L3RyPgo8dHI+PHRkIGNsYXNzPSJh dXRob3ItdGV4dCI+Jm5ic3A7PC90ZD4KPHRkIGNsYXNzPSJhdXRob3ItdGV4dCI+RmFjZWJvb2s8 L3RkPjwvdHI+Cjx0cj48dGQgY2xhc3M9ImF1dGhvciIgYWxpZ249InJpZ2h0Ij5FbWFpbDombmJz cDs8L3RkPgo8dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij48YSBocmVmPSJtYWlsdG86ZHJAZmIuY29t Ij5kckBmYi5jb208L2E+PC90ZD48L3RyPgo8dHI+PHRkIGNsYXNzPSJhdXRob3IiIGFsaWduPSJy aWdodCI+VVJJOiZuYnNwOzwvdGQ+Cjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPjxhIGhyZWY9Imh0 dHA6Ly93d3cuZGF2aWRyZWNvcmRvbi5jb20vIj5odHRwOi8vd3d3LmRhdmlkcmVjb3Jkb24uY29t LzwvYT48L3RkPjwvdHI+Cjx0ciBjZWxscGFkZGluZz0iMyI+PHRkPiZuYnNwOzwvdGQ+PHRkPiZu YnNwOzwvdGQ+PC90cj4KPHRyPjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPiZuYnNwOzwvdGQ+Cjx0 ZCBjbGFzcz0iYXV0aG9yLXRleHQiPkRpY2sgSGFyZHQ8L3RkPjwvdHI+Cjx0cj48dGQgY2xhc3M9 ImF1dGhvci10ZXh0Ij4mbmJzcDs8L3RkPgo8dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij5NaWNyb3Nv ZnQ8L3RkPjwvdHI+Cjx0cj48dGQgY2xhc3M9ImF1dGhvciIgYWxpZ249InJpZ2h0Ij5FbWFpbDom bmJzcDs8L3RkPgo8dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij48YSBocmVmPSJtYWlsdG86ZGljay5o YXJkdEBnbWFpbC5jb20iPmRpY2suaGFyZHRAZ21haWwuY29tPC9hPjwvdGQ+PC90cj4KPHRyPjx0 ZCBjbGFzcz0iYXV0aG9yIiBhbGlnbj0icmlnaHQiPlVSSTombmJzcDs8L3RkPgo8dGQgY2xhc3M9 ImF1dGhvci10ZXh0Ij48YSBocmVmPSJodHRwOi8vZGlja2hhcmR0Lm9yZy8iPmh0dHA6Ly9kaWNr aGFyZHQub3JnLzwvYT48L3RkPjwvdHI+CjwvdGFibGU+CjwvYm9keT48L2h0bWw+Cg== --_007_4E1F6AAD24975D4BA5B16804296739436655A85ETK5EX14MBXC283r_ Content-Type: text/plain; name="draft-ietf-oauth-v2-28-preliminary.txt" Content-Description: draft-ietf-oauth-v2-28-preliminary.txt Content-Disposition: attachment; filename="draft-ietf-oauth-v2-28-preliminary.txt"; size=158606; creation-date="Mon, 18 Jun 2012 22:51:52 GMT"; modification-date="Mon, 18 Jun 2012 22:47:31 GMT" Content-Transfer-Encoding: base64 CgoKT0F1dGggV29ya2luZyBHcm91cCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIEUuIEhhbW1lciwgRWQuCkludGVybmV0LURyYWZ0Ck9ic29sZXRlczogNTg0OSAoaWYgYXBw cm92ZWQpICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBELiBSZWNvcmRvbgpJbnRlbmRl ZCBzdGF0dXM6IFN0YW5kYXJkcyBUcmFjayAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg RmFjZWJvb2sKRXhwaXJlczogRGVjZW1iZXIgMjAsIDIwMTIgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIEQuIEhhcmR0CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE1pY3Jvc29mdAogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEp1bmUgMTgsIDIwMTIK CgogICAgICAgICAgICAgICAgIFRoZSBPQXV0aCAyLjAgQXV0aG9yaXphdGlvbiBGcmFtZXdvcmsK ICAgICAgICAgICAgICAgICAgICAgICAgIGRyYWZ0LWlldGYtb2F1dGgtdjItMjgKCkFic3RyYWN0 CgogICBUaGUgT0F1dGggMi4wIGF1dGhvcml6YXRpb24gZnJhbWV3b3JrIGVuYWJsZXMgYSB0aGly ZC1wYXJ0eQogICBhcHBsaWNhdGlvbiB0byBvYnRhaW4gbGltaXRlZCBhY2Nlc3MgdG8gYW4gSFRU UCBzZXJ2aWNlLCBlaXRoZXIgb24KICAgYmVoYWxmIG9mIGEgcmVzb3VyY2Ugb3duZXIgYnkgb3Jj aGVzdHJhdGluZyBhbiBhcHByb3ZhbCBpbnRlcmFjdGlvbgogICBiZXR3ZWVuIHRoZSByZXNvdXJj ZSBvd25lciBhbmQgdGhlIEhUVFAgc2VydmljZSwgb3IgYnkgYWxsb3dpbmcgdGhlCiAgIHRoaXJk LXBhcnR5IGFwcGxpY2F0aW9uIHRvIG9idGFpbiBhY2Nlc3Mgb24gaXRzIG93biBiZWhhbGYuICBU aGlzCiAgIHNwZWNpZmljYXRpb24gcmVwbGFjZXMgYW5kIG9ic29sZXRlcyB0aGUgT0F1dGggMS4w IHByb3RvY29sIGRlc2NyaWJlZAogICBpbiBSRkMgNTg0OS4KClN0YXR1cyBvZiB0aGlzIE1lbW8K CiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgaXMgc3VibWl0dGVkIGluIGZ1bGwgY29uZm9ybWFuY2Ug d2l0aCB0aGUKICAgcHJvdmlzaW9ucyBvZiBCQ1AgNzggYW5kIEJDUCA3OS4KCiAgIEludGVybmV0 LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5n CiAgIFRhc2sgRm9yY2UgKElFVEYpLiAgTm90ZSB0aGF0IG90aGVyIGdyb3VwcyBtYXkgYWxzbyBk aXN0cmlidXRlCiAgIHdvcmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LURyYWZ0cy4gIFRoZSBs aXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtCiAgIERyYWZ0cyBpcyBhdCBodHRwOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZHJhZnRzL2N1cnJlbnQvLgoKICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFm dCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzCiAgIGFuZCBtYXkg YmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMgYXQg YW55CiAgIHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMg YXMgcmVmZXJlbmNlCiAgIG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3 b3JrIGluIHByb2dyZXNzLiIKCiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgd2lsbCBleHBpcmUgb24g RGVjZW1iZXIgMjAsIDIwMTIuCgpDb3B5cmlnaHQgTm90aWNlCgogICBDb3B5cmlnaHQgKGMpIDIw MTIgSUVURiBUcnVzdCBhbmQgdGhlIHBlcnNvbnMgaWRlbnRpZmllZCBhcyB0aGUKICAgZG9jdW1l bnQgYXV0aG9ycy4gIEFsbCByaWdodHMgcmVzZXJ2ZWQuCgogICBUaGlzIGRvY3VtZW50IGlzIHN1 YmplY3QgdG8gQkNQIDc4IGFuZCB0aGUgSUVURiBUcnVzdCdzIExlZ2FsCiAgIFByb3Zpc2lvbnMg UmVsYXRpbmcgdG8gSUVURiBEb2N1bWVudHMKICAgKGh0dHA6Ly90cnVzdGVlLmlldGYub3JnL2xp Y2Vuc2UtaW5mbykgaW4gZWZmZWN0IG9uIHRoZSBkYXRlIG9mCiAgIHB1YmxpY2F0aW9uIG9mIHRo aXMgZG9jdW1lbnQuICBQbGVhc2UgcmV2aWV3IHRoZXNlIGRvY3VtZW50cwoKCgpIYW1tZXIsIGV0 IGFsLiAgICAgICAgICBFeHBpcmVzIERlY2VtYmVyIDIwLCAyMDEyICAgICAgICAgICAgICAgW1Bh Z2UgMV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgIE9BdXRoIDIuMCAgICAgICAg ICAgICAgICAgICAgICBKdW5lIDIwMTIKCgogICBjYXJlZnVsbHksIGFzIHRoZXkgZGVzY3JpYmUg eW91ciByaWdodHMgYW5kIHJlc3RyaWN0aW9ucyB3aXRoIHJlc3BlY3QKICAgdG8gdGhpcyBkb2N1 bWVudC4gIENvZGUgQ29tcG9uZW50cyBleHRyYWN0ZWQgZnJvbSB0aGlzIGRvY3VtZW50IG11c3QK ICAgaW5jbHVkZSBTaW1wbGlmaWVkIEJTRCBMaWNlbnNlIHRleHQgYXMgZGVzY3JpYmVkIGluIFNl Y3Rpb24gNC5lIG9mCiAgIHRoZSBUcnVzdCBMZWdhbCBQcm92aXNpb25zIGFuZCBhcmUgcHJvdmlk ZWQgd2l0aG91dCB3YXJyYW50eSBhcwogICBkZXNjcmliZWQgaW4gdGhlIFNpbXBsaWZpZWQgQlNE IExpY2Vuc2UuCgoKVGFibGUgb2YgQ29udGVudHMKCiAgIDEuICBJbnRyb2R1Y3Rpb24gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNQogICAgIDEuMS4g ICBSb2xlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gIDYKICAgICAxLjIuICAgUHJvdG9jb2wgRmxvdyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuICA3CiAgICAgMS4zLiAgIEF1dGhvcml6YXRpb24gR3JhbnQgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgOAogICAgICAgMS4zLjEuICBBdXRo b3JpemF0aW9uIENvZGUgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDgKICAg ICAgIDEuMy4yLiAgSW1wbGljaXQgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuICA4CiAgICAgICAxLjMuMy4gIFJlc291cmNlIE93bmVyIFBhc3N3b3JkIENyZWRl bnRpYWxzICAuIC4gLiAuIC4gLiAuIC4gLiAgOQogICAgICAgMS4zLjQuICBDbGllbnQgQ3JlZGVu dGlhbHMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDkKICAgICAxLjQuICAg QWNjZXNzIFRva2VuICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu ICA5CiAgICAgMS41LiAgIFJlZnJlc2ggVG9rZW4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAxMAogICAgIDEuNi4gICBUTFMgVmVyc2lvbiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTIKICAgICAxLjcuICAgSFRUUCBSZWRp cmVjdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEyCiAgICAg MS44LiAgIEludGVyb3BlcmFiaWxpdHkgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAxMgogICAgIDEuOS4gICBOb3RhdGlvbmFsIENvbnZlbnRpb25zICAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTMKICAgMi4gIENsaWVudCBSZWdpc3RyYXRpb24gIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEzCiAgICAgMi4xLiAgIENs aWVudCBUeXBlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAx NAogICAgIDIuMi4gICBDbGllbnQgSWRlbnRpZmllciAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gMTUKICAgICAyLjMuICAgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE1CiAgICAgICAyLjMuMS4gIENsaWVudCBQ YXNzd29yZCAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNgogICAgICAg Mi4zLjIuICBPdGhlciBBdXRoZW50aWNhdGlvbiBNZXRob2RzIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gMTcKICAgICAyLjQuICAgVW5yZWdpc3RlcmVkIENsaWVudHMgIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE3CiAgIDMuICBQcm90b2NvbCBFbmRwb2ludHMgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNwogICAgIDMuMS4gICBBdXRo b3JpemF0aW9uIEVuZHBvaW50ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTcK ICAgICAgIDMuMS4xLiAgUmVzcG9uc2UgVHlwZSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIDE4CiAgICAgICAzLjEuMi4gIFJlZGlyZWN0aW9uIEVuZHBvaW50IC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxOQogICAgIDMuMi4gICBUb2tlbiBFbmRwb2lu dCAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjEKICAgICAgIDMu Mi4xLiAgQ2xpZW50IEF1dGhlbnRpY2F0aW9uICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIDIxCiAgICAgMy4zLiAgIEFjY2VzcyBUb2tlbiBTY29wZSAgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAyMgogICA0LiAgT2J0YWluaW5nIEF1dGhvcml6YXRpb24gIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjMKICAgICA0LjEuICAgQXV0aG9y aXphdGlvbiBDb2RlIEdyYW50ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDIzCiAg ICAgICA0LjEuMS4gIEF1dGhvcml6YXRpb24gUmVxdWVzdCAgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAyNAogICAgICAgNC4xLjIuICBBdXRob3JpemF0aW9uIFJlc3BvbnNlIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjUKICAgICAgIDQuMS4zLiAgQWNjZXNzIFRva2Vu IFJlcXVlc3QgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDI3CiAgICAgICA0LjEu NC4gIEFjY2VzcyBUb2tlbiBSZXNwb25zZSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAyOAogICAgIDQuMi4gICBJbXBsaWNpdCBHcmFudCAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gMjkKICAgICAgIDQuMi4xLiAgQXV0aG9yaXphdGlvbiBSZXF1ZXN0 ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDMxCiAgICAgICA0LjIuMi4gIEFjY2Vz cyBUb2tlbiBSZXNwb25zZSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAzMgogICAg IDQuMy4gICBSZXNvdXJjZSBPd25lciBQYXNzd29yZCBDcmVkZW50aWFscyBHcmFudCAuIC4gLiAu IC4gLiAuIC4gMzUKICAgICAgIDQuMy4xLiAgQXV0aG9yaXphdGlvbiBSZXF1ZXN0IGFuZCBSZXNw b25zZSAuIC4gLiAuIC4gLiAuIC4gLiAuIDM2CgoKCkhhbW1lciwgZXQgYWwuICAgICAgICAgIEV4 cGlyZXMgRGVjZW1iZXIgMjAsIDIwMTIgICAgICAgICAgICAgICBbUGFnZSAyXQoMCkludGVybmV0 LURyYWZ0ICAgICAgICAgICAgICAgICAgT0F1dGggMi4wICAgICAgICAgICAgICAgICAgICAgIEp1 bmUgMjAxMgoKCiAgICAgICA0LjMuMi4gIEFjY2VzcyBUb2tlbiBSZXF1ZXN0IC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAzNgogICAgICAgNC4zLjMuICBBY2Nlc3MgVG9rZW4gUmVz cG9uc2UgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMzcKICAgICA0LjQuICAgQ2xp ZW50IENyZWRlbnRpYWxzIEdyYW50ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDM3 CiAgICAgICA0LjQuMS4gIEF1dGhvcml6YXRpb24gUmVxdWVzdCBhbmQgUmVzcG9uc2UgLiAuIC4g LiAuIC4gLiAuIC4gLiAzOAogICAgICAgNC40LjIuICBBY2Nlc3MgVG9rZW4gUmVxdWVzdCAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMzgKICAgICAgIDQuNC4zLiAgQWNjZXNzIFRv a2VuIFJlc3BvbnNlICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDM5CiAgICAgNC41 LiAgIEV4dGVuc2lvbiBHcmFudHMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAzOQogICA1LiAgSXNzdWluZyBhbiBBY2Nlc3MgVG9rZW4gIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gNDAKICAgICA1LjEuICAgU3VjY2Vzc2Z1bCBSZXNwb25zZSAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDQwCiAgICAgNS4yLiAgIEVycm9y IFJlc3BvbnNlICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA0MQog ICA2LiAgUmVmcmVzaGluZyBhbiBBY2Nlc3MgVG9rZW4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gNDMKICAgNy4gIEFjY2Vzc2luZyBQcm90ZWN0ZWQgUmVzb3VyY2VzICAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDQ0CiAgICAgNy4xLiAgIEFjY2VzcyBUb2tlbiBU eXBlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA0NQogICAgIDcuMi4g ICBFcnJvciBSZXNwb25zZSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gNDYKICAgOC4gIEV4dGVuc2liaWxpdHkgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIDQ2CiAgICAgOC4xLiAgIERlZmluaW5nIEFjY2VzcyBUb2tlbiBU eXBlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA0NgogICAgIDguMi4gICBEZWZpbmlu ZyBOZXcgRW5kcG9pbnQgUGFyYW1ldGVycyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNDcKICAg ICA4LjMuICAgRGVmaW5pbmcgTmV3IEF1dGhvcml6YXRpb24gR3JhbnQgVHlwZXMgIC4gLiAuIC4g LiAuIC4gLiAuIDQ3CiAgICAgOC40LiAgIERlZmluaW5nIE5ldyBBdXRob3JpemF0aW9uIEVuZHBv aW50IFJlc3BvbnNlIFR5cGVzICAuIC4gLiA0NwogICAgIDguNS4gICBEZWZpbmluZyBBZGRpdGlv bmFsIEVycm9yIENvZGVzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNDgKICAgOS4gIE5hdGl2 ZSBBcHBsaWNhdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IDQ4CiAgIDEwLiBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiA0OQogICAgIDEwLjEuICBDbGllbnQgQXV0aGVudGljYXRpb24gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNTAKICAgICAxMC4yLiAgQ2xpZW50IElt cGVyc29uYXRpb24gIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDUwCiAgICAg MTAuMy4gIEFjY2VzcyBUb2tlbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiA1MQogICAgIDEwLjQuICBSZWZyZXNoIFRva2VucyAgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNTEKICAgICAxMC41LiAgQXV0aG9yaXphdGlvbiBDb2Rl cyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDUyCiAgICAgMTAuNi4gIEF1 dGhvcml6YXRpb24gQ29kZSBSZWRpcmVjdGlvbiBVUkkgTWFuaXB1bGF0aW9uIC4gLiAuIC4gLiA1 MwogICAgIDEwLjcuICBSZXNvdXJjZSBPd25lciBQYXNzd29yZCBDcmVkZW50aWFscyAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gNTMKICAgICAxMC44LiAgUmVxdWVzdCBDb25maWRlbnRpYWxpdHkgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDU0CiAgICAgMTAuOS4gIEVuZHBvaW50cyBB dXRoZW50aWNpdHkgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA1NAogICAgIDEw LjEwLiBDcmVkZW50aWFscyBHdWVzc2luZyBBdHRhY2tzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gNTQKICAgICAxMC4xMS4gUGhpc2hpbmcgQXR0YWNrcyAgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIDU0CiAgICAgMTAuMTIuIENyb3NzLVNpdGUgUmVxdWVzdCBG b3JnZXJ5ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA1NQogICAgIDEwLjEzLiBDbGlj a2phY2tpbmcgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNTYK ICAgICAxMC4xNC4gQ29kZSBJbmplY3Rpb24gYW5kIElucHV0IFZhbGlkYXRpb24gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIDU2CiAgICAgMTAuMTUuIE9wZW4gUmVkaXJlY3RvcnMgIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA1NwogICAxMS4gSUFOQSBDb25zaWRlcmF0aW9u cyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNTcKICAgICAxMS4x LiAgVGhlIE9BdXRoIEFjY2VzcyBUb2tlbiBUeXBlIFJlZ2lzdHJ5ICAuIC4gLiAuIC4gLiAuIC4g LiAuIDU3CiAgICAgICAxMS4xLjEuIFJlZ2lzdHJhdGlvbiBUZW1wbGF0ZSAgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiA1OAogICAgIDExLjIuICBUaGUgT0F1dGggUGFyYW1ldGVycyBS ZWdpc3RyeSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNTgKICAgICAgIDExLjIuMS4gUmVn aXN0cmF0aW9uIFRlbXBsYXRlICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDU5CiAg ICAgICAxMS4yLjIuIEluaXRpYWwgUmVnaXN0cnkgQ29udGVudHMgIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiA1OQogICAgIDExLjMuICBUaGUgT0F1dGggQXV0aG9yaXphdGlvbiBFbmRwb2lu dCBSZXNwb25zZSBUeXBlCiAgICAgICAgICAgIFJlZ2lzdHJ5ICAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA2MQogICAgICAgMTEuMy4xLiBSZWdpc3RyYXRp b24gVGVtcGxhdGUgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNjEKICAgICAgIDEx LjMuMi4gSW5pdGlhbCBSZWdpc3RyeSBDb250ZW50cyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIDYyCiAgICAgMTEuNC4gIFRoZSBPQXV0aCBFeHRlbnNpb25zIEVycm9yIFJlZ2lzdHJ5IC4g LiAuIC4gLiAuIC4gLiAuIC4gLiA2MgoKCgpIYW1tZXIsIGV0IGFsLiAgICAgICAgICBFeHBpcmVz IERlY2VtYmVyIDIwLCAyMDEyICAgICAgICAgICAgICAgW1BhZ2UgM10KDApJbnRlcm5ldC1EcmFm dCAgICAgICAgICAgICAgICAgIE9BdXRoIDIuMCAgICAgICAgICAgICAgICAgICAgICBKdW5lIDIw MTIKCgogICAgICAgMTEuNC4xLiBSZWdpc3RyYXRpb24gVGVtcGxhdGUgIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gNjMKICAgMTIuIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDYzCiAgICAgMTIuMS4gIE5vcm1hdGl2 ZSBSZWZlcmVuY2VzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA2MwogICAg IDEyLjIuICBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gNjQKICAgQXBwZW5kaXggQS4gIEF1Z21lbnRlZCBCYWNrdXMtTmF1ciBGb3JtIChB Qk5GKSBTeW50YXggIC4gLiAuIC4gLiAuIDY1CiAgICAgQS4xLiAgICJjbGllbnRfaWQiIFN5bnRh eCAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA2NgogICAgIEEuMi4gICAi Y2xpZW50X3NlY3JldCIgU3ludGF4ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g NjYKICAgICBBLjMuICAgInJlc3BvbnNlX3R5cGUiIFN5bnRheCAgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIDY2CiAgICAgQS40LiAgICJzY29wZSIgU3ludGF4ICAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA2NgogICAgIEEuNS4gICAic3RhdGUiIFN5 bnRheCAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNjYKICAgICBB LjYuICAgInJlZGlyZWN0X3VyaSIgU3ludGF4IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIDY2CiAgICAgQS43LiAgICJlcnJvciIgU3ludGF4ICAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA2NwogICAgIEEuOC4gICAiZXJyb3JfZGVzY3JpcHRpb24i IFN5bnRheCAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNjcKICAgICBBLjkuICAgImVy cm9yX3VyaSIgU3ludGF4ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDY3 CiAgICAgQS4xMC4gICJncmFudF90eXBlIiBTeW50YXggLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiA2NwogICAgIEEuMTEuICAiY29kZSIgU3ludGF4IC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNjcKICAgICBBLjEyLiAgImFjY2Vzc190b2tl biIgU3ludGF4IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDY3CiAgICAgQS4x My4gICJ0b2tlbl90eXBlIiBTeW50YXggLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiA2OAogICAgIEEuMTQuICAiZXhwaXJlc19pbiIgU3ludGF4IC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gNjgKICAgICBBLjE1LiAgInVzZXJuYW1lIiBTeW50YXggLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDY4CiAgICAgQS4xNi4gICJwYXNz d29yZCIgU3ludGF4IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA2OAog ICAgIEEuMTcuICAicmVmcmVzaF90b2tlbiIgU3ludGF4ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gNjgKICAgICBBLjE4LiAgRW5kcG9pbnQgUGFyYW1ldGVyIFN5bnRheCAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDY4CiAgIEFwcGVuZGl4IEIuICBBY2tub3dsZWRn ZW1lbnRzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA2OAogICBBcHBlbmRp eCBDLiAgRWRpdG9yJ3MgTm90ZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gNjkKICAgQXV0aG9ycycgQWRkcmVzc2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIDcwCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgpIYW1tZXIsIGV0 IGFsLiAgICAgICAgICBFeHBpcmVzIERlY2VtYmVyIDIwLCAyMDEyICAgICAgICAgICAgICAgW1Bh Z2UgNF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgIE9BdXRoIDIuMCAgICAgICAg ICAgICAgICAgICAgICBKdW5lIDIwMTIKCgoxLiAgSW50cm9kdWN0aW9uCgogICBJbiB0aGUgdHJh ZGl0aW9uYWwgY2xpZW50LXNlcnZlciBhdXRoZW50aWNhdGlvbiBtb2RlbCwgdGhlIGNsaWVudAog ICByZXF1ZXN0cyBhbiBhY2Nlc3MgcmVzdHJpY3RlZCByZXNvdXJjZSAocHJvdGVjdGVkIHJlc291 cmNlKSBvbiB0aGUKICAgc2VydmVyIGJ5IGF1dGhlbnRpY2F0aW5nIHdpdGggdGhlIHNlcnZlciB1 c2luZyB0aGUgcmVzb3VyY2Ugb3duZXIncwogICBjcmVkZW50aWFscy4gIEluIG9yZGVyIHRvIHBy b3ZpZGUgdGhpcmQtcGFydHkgYXBwbGljYXRpb25zIGFjY2VzcyB0bwogICByZXN0cmljdGVkIHJl c291cmNlcywgdGhlIHJlc291cmNlIG93bmVyIHNoYXJlcyBpdHMgY3JlZGVudGlhbHMgd2l0aAog ICB0aGUgdGhpcmQtcGFydHkuICBUaGlzIGNyZWF0ZXMgc2V2ZXJhbCBwcm9ibGVtcyBhbmQgbGlt aXRhdGlvbnM6CgogICBvICBUaGlyZC1wYXJ0eSBhcHBsaWNhdGlvbnMgYXJlIHJlcXVpcmVkIHRv IHN0b3JlIHRoZSByZXNvdXJjZQogICAgICBvd25lcidzIGNyZWRlbnRpYWxzIGZvciBmdXR1cmUg dXNlLCB0eXBpY2FsbHkgYSBwYXNzd29yZCBpbiBjbGVhci0KICAgICAgdGV4dC4KICAgbyAgU2Vy dmVycyBhcmUgcmVxdWlyZWQgdG8gc3VwcG9ydCBwYXNzd29yZCBhdXRoZW50aWNhdGlvbiwgZGVz cGl0ZQogICAgICB0aGUgc2VjdXJpdHkgd2Vha25lc3NlcyBpbmhlcmVudCBpbiBwYXNzd29yZHMu CiAgIG8gIFRoaXJkLXBhcnR5IGFwcGxpY2F0aW9ucyBnYWluIG92ZXJseSBicm9hZCBhY2Nlc3Mg dG8gdGhlIHJlc291cmNlCiAgICAgIG93bmVyJ3MgcHJvdGVjdGVkIHJlc291cmNlcywgbGVhdmlu ZyByZXNvdXJjZSBvd25lcnMgd2l0aG91dCBhbnkKICAgICAgYWJpbGl0eSB0byByZXN0cmljdCBk dXJhdGlvbiBvciBhY2Nlc3MgdG8gYSBsaW1pdGVkIHN1YnNldCBvZgogICAgICByZXNvdXJjZXMu CiAgIG8gIFJlc291cmNlIG93bmVycyBjYW5ub3QgcmV2b2tlIGFjY2VzcyB0byBhbiBpbmRpdmlk dWFsIHRoaXJkLXBhcnR5CiAgICAgIHdpdGhvdXQgcmV2b2tpbmcgYWNjZXNzIHRvIGFsbCB0aGly ZC1wYXJ0aWVzLCBhbmQgbXVzdCBkbyBzbyBieQogICAgICBjaGFuZ2luZyB0aGVpciBwYXNzd29y ZC4KICAgbyAgQ29tcHJvbWlzZSBvZiBhbnkgdGhpcmQtcGFydHkgYXBwbGljYXRpb24gcmVzdWx0 cyBpbiBjb21wcm9taXNlIG9mCiAgICAgIHRoZSBlbmQtdXNlcidzIHBhc3N3b3JkIGFuZCBhbGwg b2YgdGhlIGRhdGEgcHJvdGVjdGVkIGJ5IHRoYXQKICAgICAgcGFzc3dvcmQuCgogICBPQXV0aCBh ZGRyZXNzZXMgdGhlc2UgaXNzdWVzIGJ5IGludHJvZHVjaW5nIGFuIGF1dGhvcml6YXRpb24gbGF5 ZXIKICAgYW5kIHNlcGFyYXRpbmcgdGhlIHJvbGUgb2YgdGhlIGNsaWVudCBmcm9tIHRoYXQgb2Yg dGhlIHJlc291cmNlCiAgIG93bmVyLiAgSW4gT0F1dGgsIHRoZSBjbGllbnQgcmVxdWVzdHMgYWNj ZXNzIHRvIHJlc291cmNlcyBjb250cm9sbGVkCiAgIGJ5IHRoZSByZXNvdXJjZSBvd25lciBhbmQg aG9zdGVkIGJ5IHRoZSByZXNvdXJjZSBzZXJ2ZXIsIGFuZCBpcwogICBpc3N1ZWQgYSBkaWZmZXJl bnQgc2V0IG9mIGNyZWRlbnRpYWxzIHRoYW4gdGhvc2Ugb2YgdGhlIHJlc291cmNlCiAgIG93bmVy LgoKICAgSW5zdGVhZCBvZiB1c2luZyB0aGUgcmVzb3VyY2Ugb3duZXIncyBjcmVkZW50aWFscyB0 byBhY2Nlc3MgcHJvdGVjdGVkCiAgIHJlc291cmNlcywgdGhlIGNsaWVudCBvYnRhaW5zIGFuIGFj Y2VzcyB0b2tlbiAtIGEgc3RyaW5nIGRlbm90aW5nIGEKICAgc3BlY2lmaWMgc2NvcGUsIGxpZmV0 aW1lLCBhbmQgb3RoZXIgYWNjZXNzIGF0dHJpYnV0ZXMuICBBY2Nlc3MgdG9rZW5zCiAgIGFyZSBp c3N1ZWQgdG8gdGhpcmQtcGFydHkgY2xpZW50cyBieSBhbiBhdXRob3JpemF0aW9uIHNlcnZlciB3 aXRoIHRoZQogICBhcHByb3ZhbCBvZiB0aGUgcmVzb3VyY2Ugb3duZXIuICBUaGUgY2xpZW50IHVz ZXMgdGhlIGFjY2VzcyB0b2tlbiB0bwogICBhY2Nlc3MgdGhlIHByb3RlY3RlZCByZXNvdXJjZXMg aG9zdGVkIGJ5IHRoZSByZXNvdXJjZSBzZXJ2ZXIuCgogICBGb3IgZXhhbXBsZSwgYW4gZW5kLXVz ZXIgKHJlc291cmNlIG93bmVyKSBjYW4gZ3JhbnQgYSBwcmludGluZwogICBzZXJ2aWNlIChjbGll bnQpIGFjY2VzcyB0byBoZXIgcHJvdGVjdGVkIHBob3RvcyBzdG9yZWQgYXQgYSBwaG90bwogICBz aGFyaW5nIHNlcnZpY2UgKHJlc291cmNlIHNlcnZlciksIHdpdGhvdXQgc2hhcmluZyBoZXIgdXNl cm5hbWUgYW5kCiAgIHBhc3N3b3JkIHdpdGggdGhlIHByaW50aW5nIHNlcnZpY2UuICBJbnN0ZWFk LCBzaGUgYXV0aGVudGljYXRlcwogICBkaXJlY3RseSB3aXRoIGEgc2VydmVyIHRydXN0ZWQgYnkg dGhlIHBob3RvIHNoYXJpbmcgc2VydmljZQogICAoYXV0aG9yaXphdGlvbiBzZXJ2ZXIpIHdoaWNo IGlzc3VlcyB0aGUgcHJpbnRpbmcgc2VydmljZSBkZWxlZ2F0aW9uLQogICBzcGVjaWZpYyBjcmVk ZW50aWFscyAoYWNjZXNzIHRva2VuKS4KCiAgIFRoaXMgc3BlY2lmaWNhdGlvbiBpcyBkZXNpZ25l ZCBmb3IgdXNlIHdpdGggSFRUUCAoW1JGQzI2MTZdKS4gIFRoZQoKCgpIYW1tZXIsIGV0IGFsLiAg ICAgICAgICBFeHBpcmVzIERlY2VtYmVyIDIwLCAyMDEyICAgICAgICAgICAgICAgW1BhZ2UgNV0K DApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgIE9BdXRoIDIuMCAgICAgICAgICAgICAg ICAgICAgICBKdW5lIDIwMTIKCgogICB1c2Ugb2YgT0F1dGggb3ZlciBhbnkgb3RoZXIgcHJvdG9j b2wgdGhhbiBIVFRQIGlzIG91dCBvZiBzY29wZS4KCiAgIFRoZSBPQXV0aCAxLjAgcHJvdG9jb2wg KFtSRkM1ODQ5XSksIHB1Ymxpc2hlZCBhcyBhbiBpbmZvcm1hdGlvbmFsCiAgIGRvY3VtZW50LCB3 YXMgdGhlIHJlc3VsdCBvZiBhIHNtYWxsIGFkLWhvYyBjb21tdW5pdHkgZWZmb3J0LiAgVGhpcwog ICBzdGFuZGFyZHMtdHJhY2sgc3BlY2lmaWNhdGlvbiBidWlsZHMgb24gdGhlIE9BdXRoIDEuMCBk ZXBsb3ltZW50CiAgIGV4cGVyaWVuY2UsIGFzIHdlbGwgYXMgYWRkaXRpb25hbCB1c2UgY2FzZXMg YW5kIGV4dGVuc2liaWxpdHkKICAgcmVxdWlyZW1lbnRzIGdhdGhlcmVkIGZyb20gdGhlIHdpZGVy IElFVEYgY29tbXVuaXR5LiAgVGhlIE9BdXRoIDIuMAogICBwcm90b2NvbCBpcyBub3QgYmFja3dh cmQgY29tcGF0aWJsZSB3aXRoIE9BdXRoIDEuMC4gIFRoZSB0d28gdmVyc2lvbnMKICAgbWF5IGNv LWV4aXN0IG9uIHRoZSBuZXR3b3JrIGFuZCBpbXBsZW1lbnRhdGlvbnMgbWF5IGNob29zZSB0byBz dXBwb3J0CiAgIGJvdGguICBIb3dldmVyLCBpdCBpcyB0aGUgaW50ZW50aW9uIG9mIHRoaXMgc3Bl Y2lmaWNhdGlvbiB0aGF0IG5ldwogICBpbXBsZW1lbnRhdGlvbiBzdXBwb3J0IE9BdXRoIDIuMCBh cyBzcGVjaWZpZWQgaW4gdGhpcyBkb2N1bWVudCwgYW5kCiAgIHRoYXQgT0F1dGggMS4wIGlzIHVz ZWQgb25seSB0byBzdXBwb3J0IGV4aXN0aW5nIGRlcGxveW1lbnRzLiAgVGhlCiAgIE9BdXRoIDIu MCBwcm90b2NvbCBzaGFyZXMgdmVyeSBmZXcgaW1wbGVtZW50YXRpb24gZGV0YWlscyB3aXRoIHRo ZQogICBPQXV0aCAxLjAgcHJvdG9jb2wuICBJbXBsZW1lbnRlcnMgZmFtaWxpYXIgd2l0aCBPQXV0 aCAxLjAgc2hvdWxkCiAgIGFwcHJvYWNoIHRoaXMgZG9jdW1lbnQgd2l0aG91dCBhbnkgYXNzdW1w dGlvbnMgYXMgdG8gaXRzIHN0cnVjdHVyZQogICBhbmQgZGV0YWlscy4KCjEuMS4gIFJvbGVzCgog ICBPQXV0aCBkZWZpbmVzIGZvdXIgcm9sZXM6CgogICByZXNvdXJjZSBvd25lcgogICAgICBBbiBl bnRpdHkgY2FwYWJsZSBvZiBncmFudGluZyBhY2Nlc3MgdG8gYSBwcm90ZWN0ZWQgcmVzb3VyY2Uu CiAgICAgIFdoZW4gdGhlIHJlc291cmNlIG93bmVyIGlzIGEgcGVyc29uLCBpdCBpcyByZWZlcnJl ZCB0byBhcyBhbiBlbmQtCiAgICAgIHVzZXIuCiAgIHJlc291cmNlIHNlcnZlcgogICAgICBUaGUg c2VydmVyIGhvc3RpbmcgdGhlIHByb3RlY3RlZCByZXNvdXJjZXMsIGNhcGFibGUgb2YgYWNjZXB0 aW5nCiAgICAgIGFuZCByZXNwb25kaW5nIHRvIHByb3RlY3RlZCByZXNvdXJjZSByZXF1ZXN0cyB1 c2luZyBhY2Nlc3MgdG9rZW5zLgogICBjbGllbnQKICAgICAgQW4gYXBwbGljYXRpb24gbWFraW5n IHByb3RlY3RlZCByZXNvdXJjZSByZXF1ZXN0cyBvbiBiZWhhbGYgb2YgdGhlCiAgICAgIHJlc291 cmNlIG93bmVyIGFuZCB3aXRoIGl0cyBhdXRob3JpemF0aW9uLiAgVGhlIHRlcm0gY2xpZW50IGRv ZXMKICAgICAgbm90IGltcGx5IGFueSBwYXJ0aWN1bGFyIGltcGxlbWVudGF0aW9uIGNoYXJhY3Rl cmlzdGljcyAoZS5nLgogICAgICB3aGV0aGVyIHRoZSBhcHBsaWNhdGlvbiBleGVjdXRlcyBvbiBh IHNlcnZlciwgYSBkZXNrdG9wLCBvciBvdGhlcgogICAgICBkZXZpY2VzKS4KICAgYXV0aG9yaXph dGlvbiBzZXJ2ZXIKICAgICAgVGhlIHNlcnZlciBpc3N1aW5nIGFjY2VzcyB0b2tlbnMgdG8gdGhl IGNsaWVudCBhZnRlciBzdWNjZXNzZnVsbHkKICAgICAgYXV0aGVudGljYXRpbmcgdGhlIHJlc291 cmNlIG93bmVyIGFuZCBvYnRhaW5pbmcgYXV0aG9yaXphdGlvbi4KCiAgIFRoZSBpbnRlcmFjdGlv biBiZXR3ZWVuIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBhbmQgcmVzb3VyY2Ugc2VydmVyCiAg IGlzIGJleW9uZCB0aGUgc2NvcGUgb2YgdGhpcyBzcGVjaWZpY2F0aW9uLiAgVGhlIGF1dGhvcml6 YXRpb24gc2VydmVyCiAgIG1heSBiZSB0aGUgc2FtZSBzZXJ2ZXIgYXMgdGhlIHJlc291cmNlIHNl cnZlciBvciBhIHNlcGFyYXRlIGVudGl0eS4KICAgQSBzaW5nbGUgYXV0aG9yaXphdGlvbiBzZXJ2 ZXIgbWF5IGlzc3VlIGFjY2VzcyB0b2tlbnMgYWNjZXB0ZWQgYnkKICAgbXVsdGlwbGUgcmVzb3Vy Y2Ugc2VydmVycy4KCgoKCgoKCgpIYW1tZXIsIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIERlY2Vt YmVyIDIwLCAyMDEyICAgICAgICAgICAgICAgW1BhZ2UgNl0KDApJbnRlcm5ldC1EcmFmdCAgICAg ICAgICAgICAgICAgIE9BdXRoIDIuMCAgICAgICAgICAgICAgICAgICAgICBKdW5lIDIwMTIKCgox LjIuICBQcm90b2NvbCBGbG93CgoKICAgICArLS0tLS0tLS0rICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0rCiAgICAgfCAgICAgICAgfC0tKEEpLSBBdXRob3Jp emF0aW9uIFJlcXVlc3QgLT58ICAgUmVzb3VyY2UgICAgfAogICAgIHwgICAgICAgIHwgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgT3duZXIgICAgIHwKICAgICB8ICAgICAgICB8 PC0oQiktLSBBdXRob3JpemF0aW9uIEdyYW50IC0tLXwgICAgICAgICAgICAgICB8CiAgICAgfCAg ICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tKwog ICAgIHwgICAgICAgIHwKICAgICB8ICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICstLS0tLS0tLS0tLS0tLS0rCiAgICAgfCAgICAgICAgfC0tKEMpLS0gQXV0aG9yaXphdGlv biBHcmFudCAtLT58IEF1dGhvcml6YXRpb24gfAogICAgIHwgQ2xpZW50IHwgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgfCAgICAgU2VydmVyICAgIHwKICAgICB8ICAgICAgICB8PC0oRCkt LS0tLSBBY2Nlc3MgVG9rZW4gLS0tLS0tLXwgICAgICAgICAgICAgICB8CiAgICAgfCAgICAgICAg fCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tKwogICAgIHwg ICAgICAgIHwKICAgICB8ICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICst LS0tLS0tLS0tLS0tLS0rCiAgICAgfCAgICAgICAgfC0tKEUpLS0tLS0gQWNjZXNzIFRva2VuIC0t LS0tLT58ICAgIFJlc291cmNlICAgfAogICAgIHwgICAgICAgIHwgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgfCAgICAgU2VydmVyICAgIHwKICAgICB8ICAgICAgICB8PC0oRiktLS0gUHJv dGVjdGVkIFJlc291cmNlIC0tLXwgICAgICAgICAgICAgICB8CiAgICAgKy0tLS0tLS0tKyAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tKwoKCiAgICAgICAgICAg ICAgICAgICAgIEZpZ3VyZSAxOiBBYnN0cmFjdCBQcm90b2NvbCBGbG93CgogICBUaGUgYWJzdHJh Y3QgZmxvdyBpbGx1c3RyYXRlZCBpbiBGaWd1cmUgMSBkZXNjcmliZXMgdGhlIGludGVyYWN0aW9u CiAgIGJldHdlZW4gdGhlIGZvdXIgcm9sZXMgYW5kIGluY2x1ZGVzIHRoZSBmb2xsb3dpbmcgc3Rl cHM6CgogICAoQSkgIFRoZSBjbGllbnQgcmVxdWVzdHMgYXV0aG9yaXphdGlvbiBmcm9tIHRoZSBy ZXNvdXJjZSBvd25lci4gIFRoZQogICAgICAgIGF1dGhvcml6YXRpb24gcmVxdWVzdCBjYW4gYmUg bWFkZSBkaXJlY3RseSB0byB0aGUgcmVzb3VyY2Ugb3duZXIKICAgICAgICAoYXMgc2hvd24pLCBv ciBwcmVmZXJhYmx5IGluZGlyZWN0bHkgdmlhIHRoZSBhdXRob3JpemF0aW9uCiAgICAgICAgc2Vy dmVyIGFzIGFuIGludGVybWVkaWFyeS4KICAgKEIpICBUaGUgY2xpZW50IHJlY2VpdmVzIGFuIGF1 dGhvcml6YXRpb24gZ3JhbnQgd2hpY2ggaXMgYSBjcmVkZW50aWFsCiAgICAgICAgcmVwcmVzZW50 aW5nIHRoZSByZXNvdXJjZSBvd25lcidzIGF1dGhvcml6YXRpb24sIGV4cHJlc3NlZCB1c2luZwog ICAgICAgIG9uZSBvZiBmb3VyIGdyYW50IHR5cGVzIGRlZmluZWQgaW4gdGhpcyBzcGVjaWZpY2F0 aW9uIG9yIHVzaW5nCiAgICAgICAgYW4gZXh0ZW5zaW9uIGdyYW50IHR5cGUuICBUaGUgYXV0aG9y aXphdGlvbiBncmFudCB0eXBlIGRlcGVuZHMKICAgICAgICBvbiB0aGUgbWV0aG9kIHVzZWQgYnkg dGhlIGNsaWVudCB0byByZXF1ZXN0IGF1dGhvcml6YXRpb24gYW5kCiAgICAgICAgdGhlIHR5cGVz IHN1cHBvcnRlZCBieSB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIuCiAgIChDKSAgVGhlIGNsaWVu dCByZXF1ZXN0cyBhbiBhY2Nlc3MgdG9rZW4gYnkgYXV0aGVudGljYXRpbmcgd2l0aCB0aGUKICAg ICAgICBhdXRob3JpemF0aW9uIHNlcnZlciBhbmQgcHJlc2VudGluZyB0aGUgYXV0aG9yaXphdGlv biBncmFudC4KICAgKEQpICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYXV0aGVudGljYXRlcyB0 aGUgY2xpZW50IGFuZCB2YWxpZGF0ZXMKICAgICAgICB0aGUgYXV0aG9yaXphdGlvbiBncmFudCwg YW5kIGlmIHZhbGlkIGlzc3VlcyBhbiBhY2Nlc3MgdG9rZW4uCiAgIChFKSAgVGhlIGNsaWVudCBy ZXF1ZXN0cyB0aGUgcHJvdGVjdGVkIHJlc291cmNlIGZyb20gdGhlIHJlc291cmNlCiAgICAgICAg c2VydmVyIGFuZCBhdXRoZW50aWNhdGVzIGJ5IHByZXNlbnRpbmcgdGhlIGFjY2VzcyB0b2tlbi4K ICAgKEYpICBUaGUgcmVzb3VyY2Ugc2VydmVyIHZhbGlkYXRlcyB0aGUgYWNjZXNzIHRva2VuLCBh bmQgaWYgdmFsaWQsCiAgICAgICAgc2VydmVzIHRoZSByZXF1ZXN0LgoKICAgVGhlIHByZWZlcnJl ZCBtZXRob2QgZm9yIHRoZSBjbGllbnQgdG8gb2J0YWluIGFuIGF1dGhvcml6YXRpb24gZ3JhbnQK ICAgZnJvbSB0aGUgcmVzb3VyY2Ugb3duZXIgKGRlcGljdGVkIGluIHN0ZXBzIChBKSBhbmQgKEIp KSBpcyB0byB1c2UgdGhlCgoKCkhhbW1lciwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgRGVjZW1i ZXIgMjAsIDIwMTIgICAgICAgICAgICAgICBbUGFnZSA3XQoMCkludGVybmV0LURyYWZ0ICAgICAg ICAgICAgICAgICAgT0F1dGggMi4wICAgICAgICAgICAgICAgICAgICAgIEp1bmUgMjAxMgoKCiAg IGF1dGhvcml6YXRpb24gc2VydmVyIGFzIGFuIGludGVybWVkaWFyeSB3aGljaCBpcyBpbGx1c3Ry YXRlZCBpbgogICBGaWd1cmUgMy4KCjEuMy4gIEF1dGhvcml6YXRpb24gR3JhbnQKCiAgIEFuIGF1 dGhvcml6YXRpb24gZ3JhbnQgaXMgYSBjcmVkZW50aWFsIHJlcHJlc2VudGluZyB0aGUgcmVzb3Vy Y2UKICAgb3duZXIncyBhdXRob3JpemF0aW9uICh0byBhY2Nlc3MgaXRzIHByb3RlY3RlZCByZXNv dXJjZXMpIHVzZWQgYnkgdGhlCiAgIGNsaWVudCB0byBvYnRhaW4gYW4gYWNjZXNzIHRva2VuLiAg VGhpcyBzcGVjaWZpY2F0aW9uIGRlZmluZXMgZm91cgogICBncmFudCB0eXBlczogYXV0aG9yaXph dGlvbiBjb2RlLCBpbXBsaWNpdCwgcmVzb3VyY2Ugb3duZXIgcGFzc3dvcmQKICAgY3JlZGVudGlh bHMsIGFuZCBjbGllbnQgY3JlZGVudGlhbHMsIGFzIHdlbGwgYXMgYW4gZXh0ZW5zaWJpbGl0eQog ICBtZWNoYW5pc20gZm9yIGRlZmluaW5nIGFkZGl0aW9uYWwgdHlwZXMuCgoxLjMuMS4gIEF1dGhv cml6YXRpb24gQ29kZQoKICAgVGhlIGF1dGhvcml6YXRpb24gY29kZSBpcyBvYnRhaW5lZCBieSB1 c2luZyBhbiBhdXRob3JpemF0aW9uIHNlcnZlcgogICBhcyBhbiBpbnRlcm1lZGlhcnkgYmV0d2Vl biB0aGUgY2xpZW50IGFuZCByZXNvdXJjZSBvd25lci4gIEluc3RlYWQgb2YKICAgcmVxdWVzdGlu ZyBhdXRob3JpemF0aW9uIGRpcmVjdGx5IGZyb20gdGhlIHJlc291cmNlIG93bmVyLCB0aGUgY2xp ZW50CiAgIGRpcmVjdHMgdGhlIHJlc291cmNlIG93bmVyIHRvIGFuIGF1dGhvcml6YXRpb24gc2Vy dmVyICh2aWEgaXRzIHVzZXItCiAgIGFnZW50IGFzIGRlZmluZWQgaW4gW1JGQzI2MTZdKSwgd2hp Y2ggaW4gdHVybiBkaXJlY3RzIHRoZSByZXNvdXJjZQogICBvd25lciBiYWNrIHRvIHRoZSBjbGll bnQgd2l0aCB0aGUgYXV0aG9yaXphdGlvbiBjb2RlLgoKICAgQmVmb3JlIGRpcmVjdGluZyB0aGUg cmVzb3VyY2Ugb3duZXIgYmFjayB0byB0aGUgY2xpZW50IHdpdGggdGhlCiAgIGF1dGhvcml6YXRp b24gY29kZSwgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGF1dGhlbnRpY2F0ZXMgdGhlCiAgIHJl c291cmNlIG93bmVyIGFuZCBvYnRhaW5zIGF1dGhvcml6YXRpb24uICBCZWNhdXNlIHRoZSByZXNv dXJjZSBvd25lcgogICBvbmx5IGF1dGhlbnRpY2F0ZXMgd2l0aCB0aGUgYXV0aG9yaXphdGlvbiBz ZXJ2ZXIsIHRoZSByZXNvdXJjZQogICBvd25lcidzIGNyZWRlbnRpYWxzIGFyZSBuZXZlciBzaGFy ZWQgd2l0aCB0aGUgY2xpZW50LgoKICAgVGhlIGF1dGhvcml6YXRpb24gY29kZSBwcm92aWRlcyBh IGZldyBpbXBvcnRhbnQgc2VjdXJpdHkgYmVuZWZpdHMKICAgc3VjaCBhcyB0aGUgYWJpbGl0eSB0 byBhdXRoZW50aWNhdGUgdGhlIGNsaWVudCwgYW5kIHRoZSB0cmFuc21pc3Npb24KICAgb2YgdGhl IGFjY2VzcyB0b2tlbiBkaXJlY3RseSB0byB0aGUgY2xpZW50IHdpdGhvdXQgcGFzc2luZyBpdCB0 aHJvdWdoCiAgIHRoZSByZXNvdXJjZSBvd25lcidzIHVzZXItYWdlbnQsIHBvdGVudGlhbGx5IGV4 cG9zaW5nIGl0IHRvIG90aGVycywKICAgaW5jbHVkaW5nIHRoZSByZXNvdXJjZSBvd25lci4KCjEu My4yLiAgSW1wbGljaXQKCiAgIFRoZSBpbXBsaWNpdCBncmFudCBpcyBhIHNpbXBsaWZpZWQgYXV0 aG9yaXphdGlvbiBjb2RlIGZsb3cgb3B0aW1pemVkCiAgIGZvciBjbGllbnRzIGltcGxlbWVudGVk IGluIGEgYnJvd3NlciB1c2luZyBhIHNjcmlwdGluZyBsYW5ndWFnZSBzdWNoCiAgIGFzIEphdmFT Y3JpcHQuICBJbiB0aGUgaW1wbGljaXQgZmxvdywgaW5zdGVhZCBvZiBpc3N1aW5nIHRoZSBjbGll bnQKICAgYW4gYXV0aG9yaXphdGlvbiBjb2RlLCB0aGUgY2xpZW50IGlzIGlzc3VlZCBhbiBhY2Nl c3MgdG9rZW4gZGlyZWN0bHkKICAgKGFzIHRoZSByZXN1bHQgb2YgdGhlIHJlc291cmNlIG93bmVy IGF1dGhvcml6YXRpb24pLiAgVGhlIGdyYW50IHR5cGUKICAgaXMgaW1wbGljaXQgYXMgbm8gaW50 ZXJtZWRpYXRlIGNyZWRlbnRpYWxzIChzdWNoIGFzIGFuIGF1dGhvcml6YXRpb24KICAgY29kZSkg YXJlIGlzc3VlZCAoYW5kIGxhdGVyIHVzZWQgdG8gb2J0YWluIGFuIGFjY2VzcyB0b2tlbikuCgog ICBXaGVuIGlzc3VpbmcgYW4gYWNjZXNzIHRva2VuIGR1cmluZyB0aGUgaW1wbGljaXQgZ3JhbnQg ZmxvdywgdGhlCiAgIGF1dGhvcml6YXRpb24gc2VydmVyIGRvZXMgbm90IGF1dGhlbnRpY2F0ZSB0 aGUgY2xpZW50LiAgSW4gc29tZQogICBjYXNlcywgdGhlIGNsaWVudCBpZGVudGl0eSBjYW4gYmUg dmVyaWZpZWQgdmlhIHRoZSByZWRpcmVjdGlvbiBVUkkKICAgdXNlZCB0byBkZWxpdmVyIHRoZSBh Y2Nlc3MgdG9rZW4gdG8gdGhlIGNsaWVudC4gIFRoZSBhY2Nlc3MgdG9rZW4gbWF5CiAgIGJlIGV4 cG9zZWQgdG8gdGhlIHJlc291cmNlIG93bmVyIG9yIG90aGVyIGFwcGxpY2F0aW9ucyB3aXRoIGFj Y2VzcyB0bwoKCgpIYW1tZXIsIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIERlY2VtYmVyIDIwLCAy MDEyICAgICAgICAgICAgICAgW1BhZ2UgOF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAg ICAgIE9BdXRoIDIuMCAgICAgICAgICAgICAgICAgICAgICBKdW5lIDIwMTIKCgogICB0aGUgcmVz b3VyY2Ugb3duZXIncyB1c2VyLWFnZW50LgoKICAgSW1wbGljaXQgZ3JhbnRzIGltcHJvdmUgdGhl IHJlc3BvbnNpdmVuZXNzIGFuZCBlZmZpY2llbmN5IG9mIHNvbWUKICAgY2xpZW50cyAoc3VjaCBh cyBhIGNsaWVudCBpbXBsZW1lbnRlZCBhcyBhbiBpbi1icm93c2VyIGFwcGxpY2F0aW9uKQogICBz aW5jZSBpdCByZWR1Y2VzIHRoZSBudW1iZXIgb2Ygcm91bmQgdHJpcHMgcmVxdWlyZWQgdG8gb2J0 YWluIGFuCiAgIGFjY2VzcyB0b2tlbi4gIEhvd2V2ZXIsIHRoaXMgY29udmVuaWVuY2Ugc2hvdWxk IGJlIHdlaWdoZWQgYWdhaW5zdAogICB0aGUgc2VjdXJpdHkgaW1wbGljYXRpb25zIG9mIHVzaW5n IGltcGxpY2l0IGdyYW50cywgZXNwZWNpYWxseSB3aGVuCiAgIHRoZSBhdXRob3JpemF0aW9uIGNv ZGUgZ3JhbnQgdHlwZSBpcyBhdmFpbGFibGUuCgoxLjMuMy4gIFJlc291cmNlIE93bmVyIFBhc3N3 b3JkIENyZWRlbnRpYWxzCgogICBUaGUgcmVzb3VyY2Ugb3duZXIgcGFzc3dvcmQgY3JlZGVudGlh bHMgKGkuZS4gdXNlcm5hbWUgYW5kIHBhc3N3b3JkKQogICBjYW4gYmUgdXNlZCBkaXJlY3RseSBh cyBhbiBhdXRob3JpemF0aW9uIGdyYW50IHRvIG9idGFpbiBhbiBhY2Nlc3MKICAgdG9rZW4uICBU aGUgY3JlZGVudGlhbHMgc2hvdWxkIG9ubHkgYmUgdXNlZCB3aGVuIHRoZXJlIGlzIGEgaGlnaAog ICBkZWdyZWUgb2YgdHJ1c3QgYmV0d2VlbiB0aGUgcmVzb3VyY2Ugb3duZXIgYW5kIHRoZSBjbGll bnQgKGUuZy4gdGhlCiAgIGNsaWVudCBpcyBwYXJ0IG9mIHRoZSBkZXZpY2Ugb3BlcmF0aW5nIHN5 c3RlbSBvciBhIGhpZ2hseSBwcml2aWxlZ2VkCiAgIGFwcGxpY2F0aW9uKSwgYW5kIHdoZW4gb3Ro ZXIgYXV0aG9yaXphdGlvbiBncmFudCB0eXBlcyBhcmUgbm90CiAgIGF2YWlsYWJsZSAoc3VjaCBh cyBhbiBhdXRob3JpemF0aW9uIGNvZGUpLgoKICAgRXZlbiB0aG91Z2ggdGhpcyBncmFudCB0eXBl IHJlcXVpcmVzIGRpcmVjdCBjbGllbnQgYWNjZXNzIHRvIHRoZQogICByZXNvdXJjZSBvd25lciBj cmVkZW50aWFscywgdGhlIHJlc291cmNlIG93bmVyIGNyZWRlbnRpYWxzIGFyZSB1c2VkCiAgIGZv ciBhIHNpbmdsZSByZXF1ZXN0IGFuZCBhcmUgZXhjaGFuZ2VkIGZvciBhbiBhY2Nlc3MgdG9rZW4u ICBUaGlzCiAgIGdyYW50IHR5cGUgY2FuIGVsaW1pbmF0ZSB0aGUgbmVlZCBmb3IgdGhlIGNsaWVu dCB0byBzdG9yZSB0aGUKICAgcmVzb3VyY2Ugb3duZXIgY3JlZGVudGlhbHMgZm9yIGZ1dHVyZSB1 c2UsIGJ5IGV4Y2hhbmdpbmcgdGhlCiAgIGNyZWRlbnRpYWxzIHdpdGggYSBsb25nLWxpdmVkIGFj Y2VzcyB0b2tlbiBvciByZWZyZXNoIHRva2VuLgoKMS4zLjQuICBDbGllbnQgQ3JlZGVudGlhbHMK CiAgIFRoZSBjbGllbnQgY3JlZGVudGlhbHMgKG9yIG90aGVyIGZvcm1zIG9mIGNsaWVudCBhdXRo ZW50aWNhdGlvbikgY2FuCiAgIGJlIHVzZWQgYXMgYW4gYXV0aG9yaXphdGlvbiBncmFudCB3aGVu IHRoZSBhdXRob3JpemF0aW9uIHNjb3BlIGlzCiAgIGxpbWl0ZWQgdG8gdGhlIHByb3RlY3RlZCBy ZXNvdXJjZXMgdW5kZXIgdGhlIGNvbnRyb2wgb2YgdGhlIGNsaWVudCwKICAgb3IgdG8gcHJvdGVj dGVkIHJlc291cmNlcyBwcmV2aW91c2x5IGFycmFuZ2VkIHdpdGggdGhlIGF1dGhvcml6YXRpb24K ICAgc2VydmVyLiAgQ2xpZW50IGNyZWRlbnRpYWxzIGFyZSB1c2VkIGFzIGFuIGF1dGhvcml6YXRp b24gZ3JhbnQKICAgdHlwaWNhbGx5IHdoZW4gdGhlIGNsaWVudCBpcyBhY3Rpbmcgb24gaXRzIG93 biBiZWhhbGYgKHRoZSBjbGllbnQgaXMKICAgYWxzbyB0aGUgcmVzb3VyY2Ugb3duZXIpLCBvciBp cyByZXF1ZXN0aW5nIGFjY2VzcyB0byBwcm90ZWN0ZWQKICAgcmVzb3VyY2VzIGJhc2VkIG9uIGFu IGF1dGhvcml6YXRpb24gcHJldmlvdXNseSBhcnJhbmdlZCB3aXRoIHRoZQogICBhdXRob3JpemF0 aW9uIHNlcnZlci4KCjEuNC4gIEFjY2VzcyBUb2tlbgoKICAgQWNjZXNzIHRva2VucyBhcmUgY3Jl ZGVudGlhbHMgdXNlZCB0byBhY2Nlc3MgcHJvdGVjdGVkIHJlc291cmNlcy4gIEFuCiAgIGFjY2Vz cyB0b2tlbiBpcyBhIHN0cmluZyByZXByZXNlbnRpbmcgYW4gYXV0aG9yaXphdGlvbiBpc3N1ZWQg dG8gdGhlCiAgIGNsaWVudC4gIFRoZSBzdHJpbmcgaXMgdXN1YWxseSBvcGFxdWUgdG8gdGhlIGNs aWVudC4gIFRva2VucwogICByZXByZXNlbnQgc3BlY2lmaWMgc2NvcGVzIGFuZCBkdXJhdGlvbnMg b2YgYWNjZXNzLCBncmFudGVkIGJ5IHRoZQogICByZXNvdXJjZSBvd25lciwgYW5kIGVuZm9yY2Vk IGJ5IHRoZSByZXNvdXJjZSBzZXJ2ZXIgYW5kIGF1dGhvcml6YXRpb24KICAgc2VydmVyLgoKICAg VGhlIHRva2VuIG1heSBkZW5vdGUgYW4gaWRlbnRpZmllciB1c2VkIHRvIHJldHJpZXZlIHRoZSBh dXRob3JpemF0aW9uCgoKCkhhbW1lciwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgRGVjZW1iZXIg MjAsIDIwMTIgICAgICAgICAgICAgICBbUGFnZSA5XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAg ICAgICAgICAgT0F1dGggMi4wICAgICAgICAgICAgICAgICAgICAgIEp1bmUgMjAxMgoKCiAgIGlu Zm9ybWF0aW9uLCBvciBzZWxmLWNvbnRhaW4gdGhlIGF1dGhvcml6YXRpb24gaW5mb3JtYXRpb24g aW4gYQogICB2ZXJpZmlhYmxlIG1hbm5lciAoaS5lLiBhIHRva2VuIHN0cmluZyBjb25zaXN0aW5n IG9mIHNvbWUgZGF0YSBhbmQgYQogICBzaWduYXR1cmUpLiAgQWRkaXRpb25hbCBhdXRoZW50aWNh dGlvbiBjcmVkZW50aWFscywgd2hpY2ggYXJlIGJleW9uZAogICB0aGUgc2NvcGUgb2YgdGhpcyBz cGVjaWZpY2F0aW9uLCBtYXkgYmUgcmVxdWlyZWQgaW4gb3JkZXIgZm9yIHRoZQogICBjbGllbnQg dG8gdXNlIGEgdG9rZW4uCgogICBUaGUgYWNjZXNzIHRva2VuIHByb3ZpZGVzIGFuIGFic3RyYWN0 aW9uIGxheWVyLCByZXBsYWNpbmcgZGlmZmVyZW50CiAgIGF1dGhvcml6YXRpb24gY29uc3RydWN0 cyAoZS5nLiB1c2VybmFtZSBhbmQgcGFzc3dvcmQpIHdpdGggYSBzaW5nbGUKICAgdG9rZW4gdW5k ZXJzdG9vZCBieSB0aGUgcmVzb3VyY2Ugc2VydmVyLiAgVGhpcyBhYnN0cmFjdGlvbiBlbmFibGVz CiAgIGlzc3VpbmcgYWNjZXNzIHRva2VucyBtb3JlIHJlc3RyaWN0aXZlIHRoYW4gdGhlIGF1dGhv cml6YXRpb24gZ3JhbnQKICAgdXNlZCB0byBvYnRhaW4gdGhlbSwgYXMgd2VsbCBhcyByZW1vdmlu ZyB0aGUgcmVzb3VyY2Ugc2VydmVyJ3MgbmVlZAogICB0byB1bmRlcnN0YW5kIGEgd2lkZSByYW5n ZSBvZiBhdXRoZW50aWNhdGlvbiBtZXRob2RzLgoKICAgQWNjZXNzIHRva2VucyBjYW4gaGF2ZSBk aWZmZXJlbnQgZm9ybWF0cywgc3RydWN0dXJlcywgYW5kIG1ldGhvZHMgb2YKICAgdXRpbGl6YXRp b24gKGUuZy4gY3J5cHRvZ3JhcGhpYyBwcm9wZXJ0aWVzKSBiYXNlZCBvbiB0aGUgcmVzb3VyY2UK ICAgc2VydmVyIHNlY3VyaXR5IHJlcXVpcmVtZW50cy4gIEFjY2VzcyB0b2tlbiBhdHRyaWJ1dGVz IGFuZCB0aGUKICAgbWV0aG9kcyB1c2VkIHRvIGFjY2VzcyBwcm90ZWN0ZWQgcmVzb3VyY2VzIGFy ZSBiZXlvbmQgdGhlIHNjb3BlIG9mCiAgIHRoaXMgc3BlY2lmaWNhdGlvbiBhbmQgYXJlIGRlZmlu ZWQgYnkgY29tcGFuaW9uIHNwZWNpZmljYXRpb25zLgoKMS41LiAgUmVmcmVzaCBUb2tlbgoKICAg UmVmcmVzaCB0b2tlbnMgYXJlIGNyZWRlbnRpYWxzIHVzZWQgdG8gb2J0YWluIGFjY2VzcyB0b2tl bnMuICBSZWZyZXNoCiAgIHRva2VucyBhcmUgaXNzdWVkIHRvIHRoZSBjbGllbnQgYnkgdGhlIGF1 dGhvcml6YXRpb24gc2VydmVyIGFuZCBhcmUKICAgdXNlZCB0byBvYnRhaW4gYSBuZXcgYWNjZXNz IHRva2VuIHdoZW4gdGhlIGN1cnJlbnQgYWNjZXNzIHRva2VuCiAgIGJlY29tZXMgaW52YWxpZCBv ciBleHBpcmVzLCBvciB0byBvYnRhaW4gYWRkaXRpb25hbCBhY2Nlc3MgdG9rZW5zCiAgIHdpdGgg aWRlbnRpY2FsIG9yIG5hcnJvd2VyIHNjb3BlIChhY2Nlc3MgdG9rZW5zIG1heSBoYXZlIGEgc2hv cnRlcgogICBsaWZldGltZSBhbmQgZmV3ZXIgcGVybWlzc2lvbnMgdGhhbiBhdXRob3JpemVkIGJ5 IHRoZSByZXNvdXJjZQogICBvd25lcikuICBJc3N1aW5nIGEgcmVmcmVzaCB0b2tlbiBpcyBvcHRp b25hbCBhdCB0aGUgZGlzY3JldGlvbiBvZiB0aGUKICAgYXV0aG9yaXphdGlvbiBzZXJ2ZXIuICBJ ZiB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgaXNzdWVzIGEgcmVmcmVzaAogICB0b2tlbiwgaXQg aXMgaW5jbHVkZWQgd2hlbiBpc3N1aW5nIGFuIGFjY2VzcyB0b2tlbiAoaS5lLiBzdGVwIChEKSBp bgogICBGaWd1cmUgMSkuCgogICBBIHJlZnJlc2ggdG9rZW4gaXMgYSBzdHJpbmcgcmVwcmVzZW50 aW5nIHRoZSBhdXRob3JpemF0aW9uIGdyYW50ZWQgdG8KICAgdGhlIGNsaWVudCBieSB0aGUgcmVz b3VyY2Ugb3duZXIuICBUaGUgc3RyaW5nIGlzIHVzdWFsbHkgb3BhcXVlIHRvCiAgIHRoZSBjbGll bnQuICBUaGUgdG9rZW4gZGVub3RlcyBhbiBpZGVudGlmaWVyIHVzZWQgdG8gcmV0cmlldmUgdGhl CiAgIGF1dGhvcml6YXRpb24gaW5mb3JtYXRpb24uICBVbmxpa2UgYWNjZXNzIHRva2VucywgcmVm cmVzaCB0b2tlbnMgYXJlCiAgIGludGVuZGVkIGZvciB1c2Ugb25seSB3aXRoIGF1dGhvcml6YXRp b24gc2VydmVycyBhbmQgYXJlIG5ldmVyIHNlbnQKICAgdG8gcmVzb3VyY2Ugc2VydmVycy4KCgoK CgoKCgoKCgoKCkhhbW1lciwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgRGVjZW1iZXIgMjAsIDIw MTIgICAgICAgICAgICAgIFtQYWdlIDEwXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAg ICAgT0F1dGggMi4wICAgICAgICAgICAgICAgICAgICAgIEp1bmUgMjAxMgoKCiAgKy0tLS0tLS0t KyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0t LS0tKwogIHwgICAgICAgIHwtLShBKS0tLS0tLS0gQXV0aG9yaXphdGlvbiBHcmFudCAtLS0tLS0t LS0+fCAgICAgICAgICAgICAgIHwKICB8ICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICB8CiAgfCAgICAgICAgfDwtKEIpLS0t LS0tLS0tLS0gQWNjZXNzIFRva2VuIC0tLS0tLS0tLS0tLS18ICAgICAgICAgICAgICAgfAogIHwg ICAgICAgIHwgICAgICAgICAgICAgICAmIFJlZnJlc2ggVG9rZW4gICAgICAgICAgICAgfCAgICAg ICAgICAgICAgIHwKICB8ICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHwgICAgICAgICAgICAgICB8CiAgfCAgICAgICAgfCAgICAgICAgICAgICAgICAg ICAgICAgICAgICArLS0tLS0tLS0tLSsgICB8ICAgICAgICAgICAgICAgfAogIHwgICAgICAgIHwt LShDKS0tLS0gQWNjZXNzIFRva2VuIC0tLS0+fCAgICAgICAgICB8ICAgfCAgICAgICAgICAgICAg IHwKICB8ICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgfCAg IHwgICAgICAgICAgICAgICB8CiAgfCAgICAgICAgfDwtKEQpLSBQcm90ZWN0ZWQgUmVzb3VyY2Ug LS18IFJlc291cmNlIHwgICB8IEF1dGhvcml6YXRpb24gfAogIHwgQ2xpZW50IHwgICAgICAgICAg ICAgICAgICAgICAgICAgICAgfCAgU2VydmVyICB8ICAgfCAgICAgU2VydmVyICAgIHwKICB8ICAg ICAgICB8LS0oRSktLS0tIEFjY2VzcyBUb2tlbiAtLS0tPnwgICAgICAgICAgfCAgIHwgICAgICAg ICAgICAgICB8CiAgfCAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAg ICAgIHwgICB8ICAgICAgICAgICAgICAgfAogIHwgICAgICAgIHw8LShGKS0gSW52YWxpZCBUb2tl biBFcnJvciAtfCAgICAgICAgICB8ICAgfCAgICAgICAgICAgICAgIHwKICB8ICAgICAgICB8ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tKyAgIHwgICAgICAgICAgICAgICB8 CiAgfCAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8 ICAgICAgICAgICAgICAgfAogIHwgICAgICAgIHwtLShHKS0tLS0tLS0tLS0tIFJlZnJlc2ggVG9r ZW4gLS0tLS0tLS0tLS0+fCAgICAgICAgICAgICAgIHwKICB8ICAgICAgICB8ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICB8CiAgfCAgICAg ICAgfDwtKEgpLS0tLS0tLS0tLS0gQWNjZXNzIFRva2VuIC0tLS0tLS0tLS0tLS18ICAgICAgICAg ICAgICAgfAogICstLS0tLS0tLSsgICAgICAgICAgICYgT3B0aW9uYWwgUmVmcmVzaCBUb2tlbiAg ICAgICAgKy0tLS0tLS0tLS0tLS0tLSsKCgogICAgICAgICAgICAgICBGaWd1cmUgMjogUmVmcmVz aGluZyBhbiBFeHBpcmVkIEFjY2VzcyBUb2tlbgoKICAgVGhlIGZsb3cgaWxsdXN0cmF0ZWQgaW4g RmlndXJlIDIgaW5jbHVkZXMgdGhlIGZvbGxvd2luZyBzdGVwczoKCiAgIChBKSAgVGhlIGNsaWVu dCByZXF1ZXN0cyBhbiBhY2Nlc3MgdG9rZW4gYnkgYXV0aGVudGljYXRpbmcgd2l0aCB0aGUKICAg ICAgICBhdXRob3JpemF0aW9uIHNlcnZlciwgYW5kIHByZXNlbnRpbmcgYW4gYXV0aG9yaXphdGlv biBncmFudC4KICAgKEIpICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYXV0aGVudGljYXRlcyB0 aGUgY2xpZW50IGFuZCB2YWxpZGF0ZXMKICAgICAgICB0aGUgYXV0aG9yaXphdGlvbiBncmFudCwg YW5kIGlmIHZhbGlkIGlzc3VlcyBhbiBhY2Nlc3MgdG9rZW4gYW5kCiAgICAgICAgYSByZWZyZXNo IHRva2VuLgogICAoQykgIFRoZSBjbGllbnQgbWFrZXMgYSBwcm90ZWN0ZWQgcmVzb3VyY2UgcmVx dWVzdCB0byB0aGUgcmVzb3VyY2UKICAgICAgICBzZXJ2ZXIgYnkgcHJlc2VudGluZyB0aGUgYWNj ZXNzIHRva2VuLgogICAoRCkgIFRoZSByZXNvdXJjZSBzZXJ2ZXIgdmFsaWRhdGVzIHRoZSBhY2Nl c3MgdG9rZW4sIGFuZCBpZiB2YWxpZCwKICAgICAgICBzZXJ2ZXMgdGhlIHJlcXVlc3QuCiAgIChF KSAgU3RlcHMgKEMpIGFuZCAoRCkgcmVwZWF0IHVudGlsIHRoZSBhY2Nlc3MgdG9rZW4gZXhwaXJl cy4gIElmIHRoZQogICAgICAgIGNsaWVudCBrbm93cyB0aGUgYWNjZXNzIHRva2VuIGV4cGlyZWQs IGl0IHNraXBzIHRvIHN0ZXAgKEcpLAogICAgICAgIG90aGVyd2lzZSBpdCBtYWtlcyBhbm90aGVy IHByb3RlY3RlZCByZXNvdXJjZSByZXF1ZXN0LgogICAoRikgIFNpbmNlIHRoZSBhY2Nlc3MgdG9r ZW4gaXMgaW52YWxpZCwgdGhlIHJlc291cmNlIHNlcnZlciByZXR1cm5zCiAgICAgICAgYW4gaW52 YWxpZCB0b2tlbiBlcnJvci4KICAgKEcpICBUaGUgY2xpZW50IHJlcXVlc3RzIGEgbmV3IGFjY2Vz cyB0b2tlbiBieSBhdXRoZW50aWNhdGluZyB3aXRoCiAgICAgICAgdGhlIGF1dGhvcml6YXRpb24g c2VydmVyIGFuZCBwcmVzZW50aW5nIHRoZSByZWZyZXNoIHRva2VuLiAgVGhlCiAgICAgICAgY2xp ZW50IGF1dGhlbnRpY2F0aW9uIHJlcXVpcmVtZW50cyBhcmUgYmFzZWQgb24gdGhlIGNsaWVudCB0 eXBlCiAgICAgICAgYW5kIG9uIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBwb2xpY2llcy4KCgoK CgoKCkhhbW1lciwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgRGVjZW1iZXIgMjAsIDIwMTIgICAg ICAgICAgICAgIFtQYWdlIDExXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgT0F1 dGggMi4wICAgICAgICAgICAgICAgICAgICAgIEp1bmUgMjAxMgoKCiAgIChIKSAgVGhlIGF1dGhv cml6YXRpb24gc2VydmVyIGF1dGhlbnRpY2F0ZXMgdGhlIGNsaWVudCBhbmQgdmFsaWRhdGVzCiAg ICAgICAgdGhlIHJlZnJlc2ggdG9rZW4sIGFuZCBpZiB2YWxpZCBpc3N1ZXMgYSBuZXcgYWNjZXNz IHRva2VuIChhbmQKICAgICAgICBvcHRpb25hbGx5LCBhIG5ldyByZWZyZXNoIHRva2VuKS4KCiAg IFN0ZXBzIEMsIEQsIEUsIGFuZCBGIGFyZSBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIHNwZWNp ZmljYXRpb24gYXMKICAgZGVzY3JpYmVkIGluIFNlY3Rpb24gNy4KCjEuNi4gIFRMUyBWZXJzaW9u CgogICBXaGVuZXZlciBUTFMgaXMgdXNlZCBieSB0aGlzIHNwZWNpZmljYXRpb24sIHRoZSBhcHBy b3ByaWF0ZSB2ZXJzaW9uCiAgIChvciB2ZXJzaW9ucykgb2YgVExTIHdpbGwgdmFyeSBvdmVyIHRp bWUsIGJhc2VkIG9uIHRoZSB3aWRlc3ByZWFkCiAgIGRlcGxveW1lbnQgYW5kIGtub3duIHNlY3Vy aXR5IHZ1bG5lcmFiaWxpdGllcy4gIEF0IHRoZSB0aW1lIG9mIHRoaXMKICAgd3JpdGluZywgVExT IHZlcnNpb24gMS4yIFtSRkM1MjQ2XSBpcyB0aGUgbW9zdCByZWNlbnQgdmVyc2lvbiwgYnV0CiAg IGhhcyBhIHZlcnkgbGltaXRlZCBkZXBsb3ltZW50IGJhc2UgYW5kIG1pZ2h0IG5vdCBiZSByZWFk aWx5IGF2YWlsYWJsZQogICBmb3IgaW1wbGVtZW50YXRpb24uICBUTFMgdmVyc2lvbiAxLjAgW1JG QzIyNDZdIGlzIHRoZSBtb3N0IHdpZGVseQogICBkZXBsb3llZCB2ZXJzaW9uLCBhbmQgd2lsbCBw cm92aWRlIHRoZSBicm9hZGVzdCBpbnRlcm9wZXJhYmlsaXR5LgoKICAgSW1wbGVtZW50YXRpb25z IE1BWSBhbHNvIHN1cHBvcnQgYWRkaXRpb25hbCB0cmFuc3BvcnQtbGF5ZXIgc2VjdXJpdHkKICAg bWVjaGFuaXNtcyB0aGF0IG1lZXQgdGhlaXIgc2VjdXJpdHkgcmVxdWlyZW1lbnRzLgoKMS43LiAg SFRUUCBSZWRpcmVjdGlvbnMKCiAgIFRoaXMgc3BlY2lmaWNhdGlvbiBtYWtlcyBleHRlbnNpdmUg dXNlIG9mIEhUVFAgcmVkaXJlY3Rpb25zLCBpbiB3aGljaAogICB0aGUgY2xpZW50IG9yIHRoZSBh dXRob3JpemF0aW9uIHNlcnZlciBkaXJlY3QgdGhlIHJlc291cmNlIG93bmVyJ3MKICAgdXNlci1h Z2VudCB0byBhbm90aGVyIGRlc3RpbmF0aW9uLiAgV2hpbGUgdGhlIGV4YW1wbGVzIGluIHRoaXMK ICAgc3BlY2lmaWNhdGlvbiBzaG93IHRoZSB1c2Ugb2YgdGhlIEhUVFAgMzAyIHN0YXR1cyBjb2Rl LCBhbnkgb3RoZXIKICAgbWV0aG9kIGF2YWlsYWJsZSB2aWEgdGhlIHVzZXItYWdlbnQgdG8gYWNj b21wbGlzaCB0aGlzIHJlZGlyZWN0aW9uIGlzCiAgIGFsbG93ZWQgYW5kIGlzIGNvbnNpZGVyZWQg dG8gYmUgYW4gaW1wbGVtZW50YXRpb24gZGV0YWlsLgoKMS44LiAgSW50ZXJvcGVyYWJpbGl0eQoK ICAgT0F1dGggMi4wIHByb3ZpZGVzIGEgcmljaCBhdXRob3JpemF0aW9uIGZyYW1ld29yayB3aXRo IHdlbGwtZGVmaW5lZAogICBzZWN1cml0eSBwcm9wZXJ0aWVzLiAgSG93ZXZlciwgYXMgYSByaWNo IGFuZCBoaWdobHkgZXh0ZW5zaWJsZQogICBmcmFtZXdvcmsgd2l0aCBtYW55IG9wdGlvbmFsIGNv bXBvbmVudHMsIG9uIGl0cyBvd24sIHRoaXMKICAgc3BlY2lmaWNhdGlvbiBpcyBsaWtlbHkgdG8g cHJvZHVjZSBhIHdpZGUgcmFuZ2Ugb2Ygbm9uLWludGVyb3BlcmFibGUKICAgaW1wbGVtZW50YXRp b25zLgoKICAgSW4gYWRkaXRpb24sIHRoaXMgc3BlY2lmaWNhdGlvbiBsZWF2ZXMgYSBmZXcgcmVx dWlyZWQgY29tcG9uZW50cwogICBwYXJ0aWFsbHkgb3IgZnVsbHkgdW5kZWZpbmVkIChlLmcuIGNs aWVudCByZWdpc3RyYXRpb24sIGF1dGhvcml6YXRpb24KICAgc2VydmVyIGNhcGFiaWxpdGllcywg ZW5kcG9pbnQgZGlzY292ZXJ5KS4gIFdpdGhvdXQgdGhlc2UgY29tcG9uZW50cywKICAgY2xpZW50 cyBtdXN0IGJlIG1hbnVhbGx5IGFuZCBzcGVjaWZpY2FsbHkgY29uZmlndXJlZCBhZ2FpbnN0IGEK ICAgc3BlY2lmaWMgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYW5kIHJlc291cmNlIHNlcnZlciBpbiBv cmRlciB0bwogICBpbnRlcm9wZXJhdGUuCgogICBUaGlzIGZyYW1ld29yayB3YXMgZGVzaWduZWQg d2l0aCB0aGUgY2xlYXIgZXhwZWN0YXRpb24gdGhhdCBmdXR1cmUKICAgd29yayB3aWxsIGRlZmlu ZSBwcmVzY3JpcHRpdmUgcHJvZmlsZXMgYW5kIGV4dGVuc2lvbnMgbmVjZXNzYXJ5IHRvCiAgIGFj aGlldmUgZnVsbCB3ZWItc2NhbGUgaW50ZXJvcGVyYWJpbGl0eS4KCgoKCkhhbW1lciwgZXQgYWwu ICAgICAgICAgIEV4cGlyZXMgRGVjZW1iZXIgMjAsIDIwMTIgICAgICAgICAgICAgIFtQYWdlIDEy XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgT0F1dGggMi4wICAgICAgICAgICAg ICAgICAgICAgIEp1bmUgMjAxMgoKCjEuOS4gIE5vdGF0aW9uYWwgQ29udmVudGlvbnMKCiAgIFRo ZSBrZXkgd29yZHMgIk1VU1QiLCAiTVVTVCBOT1QiLCAiUkVRVUlSRUQiLCAiU0hBTEwiLCAiU0hB TEwgTk9UIiwKICAgIlNIT1VMRCIsICJTSE9VTEQgTk9UIiwgIlJFQ09NTUVOREVEIiwgIk1BWSIs IGFuZCAiT1BUSU9OQUwiIGluIHRoaXMKICAgc3BlY2lmaWNhdGlvbiBhcmUgdG8gYmUgaW50ZXJw cmV0ZWQgYXMgZGVzY3JpYmVkIGluIFtSRkMyMTE5XS4KCiAgIFRoaXMgc3BlY2lmaWNhdGlvbiB1 c2VzIHRoZSBBdWdtZW50ZWQgQmFja3VzLU5hdXIgRm9ybSAoQUJORikKICAgbm90YXRpb24gb2Yg W1JGQzUyMzRdLiAgQWRkaXRpb25hbGx5LCB0aGUgcnVsZSBVUkktUmVmZXJlbmNlIGlzCiAgIGlu Y2x1ZGVkIGZyb20gVW5pZm9ybSBSZXNvdXJjZSBJZGVudGlmaWVyIChVUkkpIFtSRkMzOTg2XS4K CiAgIENlcnRhaW4gc2VjdXJpdHktcmVsYXRlZCB0ZXJtcyBhcmUgdG8gYmUgdW5kZXJzdG9vZCBp biB0aGUgc2Vuc2UKICAgZGVmaW5lZCBpbiBbUkZDNDk0OV0uICBUaGVzZSB0ZXJtcyBpbmNsdWRl LCBidXQgYXJlIG5vdCBsaW1pdGVkIHRvLAogICAiYXR0YWNrIiwgImF1dGhlbnRpY2F0aW9uIiwg ImF1dGhvcml6YXRpb24iLCAiY2VydGlmaWNhdGUiLAogICAiY29uZmlkZW50aWFsaXR5IiwgImNy ZWRlbnRpYWwiLCAiZW5jcnlwdGlvbiIsICJpZGVudGl0eSIsICJzaWduIiwKICAgInNpZ25hdHVy ZSIsICJ0cnVzdCIsICJ2YWxpZGF0ZSIsIGFuZCAidmVyaWZ5Ii4KCiAgIFVubGVzcyBvdGhlcndp c2Ugbm90ZWQsIGFsbCB0aGUgcHJvdG9jb2wgcGFyYW1ldGVyIG5hbWVzIGFuZCB2YWx1ZXMKICAg YXJlIGNhc2Ugc2Vuc2l0aXZlLgoKCjIuICBDbGllbnQgUmVnaXN0cmF0aW9uCgogICBCZWZvcmUg aW5pdGlhdGluZyB0aGUgcHJvdG9jb2wsIHRoZSBjbGllbnQgcmVnaXN0ZXJzIHdpdGggdGhlCiAg IGF1dGhvcml6YXRpb24gc2VydmVyLiAgVGhlIG1lYW5zIHRocm91Z2ggd2hpY2ggdGhlIGNsaWVu dCByZWdpc3RlcnMKICAgd2l0aCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYXJlIGJleW9uZCB0 aGUgc2NvcGUgb2YgdGhpcwogICBzcGVjaWZpY2F0aW9uLCBidXQgdHlwaWNhbGx5IGludm9sdmUg ZW5kLXVzZXIgaW50ZXJhY3Rpb24gd2l0aCBhbgogICBIVE1MIHJlZ2lzdHJhdGlvbiBmb3JtLgoK ICAgQ2xpZW50IHJlZ2lzdHJhdGlvbiBkb2VzIG5vdCByZXF1aXJlIGEgZGlyZWN0IGludGVyYWN0 aW9uIGJldHdlZW4gdGhlCiAgIGNsaWVudCBhbmQgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLiAg V2hlbiBzdXBwb3J0ZWQgYnkgdGhlCiAgIGF1dGhvcml6YXRpb24gc2VydmVyLCByZWdpc3RyYXRp b24gY2FuIHJlbHkgb24gb3RoZXIgbWVhbnMgZm9yCiAgIGVzdGFibGlzaGluZyB0cnVzdCBhbmQg b2J0YWluaW5nIHRoZSByZXF1aXJlZCBjbGllbnQgcHJvcGVydGllcyAoZS5nLgogICByZWRpcmVj dGlvbiBVUkksIGNsaWVudCB0eXBlKS4gIEZvciBleGFtcGxlLCByZWdpc3RyYXRpb24gY2FuIGJl CiAgIGFjY29tcGxpc2hlZCB1c2luZyBhIHNlbGYtaXNzdWVkIG9yIHRoaXJkLXBhcnR5LWlzc3Vl ZCBhc3NlcnRpb24sIG9yCiAgIGJ5IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBwZXJmb3JtaW5n IGNsaWVudCBkaXNjb3ZlcnkgdXNpbmcgYQogICB0cnVzdGVkIGNoYW5uZWwuCgogICBXaGVuIHJl Z2lzdGVyaW5nIGEgY2xpZW50LCB0aGUgY2xpZW50IGRldmVsb3BlciBTSEFMTDoKCiAgIG8gIHNw ZWNpZnkgdGhlIGNsaWVudCB0eXBlIGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDIuMSwKICAgbyAg cHJvdmlkZSBpdHMgY2xpZW50IHJlZGlyZWN0aW9uIFVSSXMgYXMgZGVzY3JpYmVkIGluIFNlY3Rp b24gMy4xLjIsCiAgICAgIGFuZAogICBvICBpbmNsdWRlIGFueSBvdGhlciBpbmZvcm1hdGlvbiBy ZXF1aXJlZCBieSB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIKICAgICAgKGUuZy4gYXBwbGljYXRp b24gbmFtZSwgd2Vic2l0ZSwgZGVzY3JpcHRpb24sIGxvZ28gaW1hZ2UsIHRoZQogICAgICBhY2Nl cHRhbmNlIG9mIGxlZ2FsIHRlcm1zKS4KCgoKCgoKSGFtbWVyLCBldCBhbC4gICAgICAgICAgRXhw aXJlcyBEZWNlbWJlciAyMCwgMjAxMiAgICAgICAgICAgICAgW1BhZ2UgMTNdCgwKSW50ZXJuZXQt RHJhZnQgICAgICAgICAgICAgICAgICBPQXV0aCAyLjAgICAgICAgICAgICAgICAgICAgICAgSnVu ZSAyMDEyCgoKMi4xLiAgQ2xpZW50IFR5cGVzCgogICBPQXV0aCBkZWZpbmVzIHR3byBjbGllbnQg dHlwZXMsIGJhc2VkIG9uIHRoZWlyIGFiaWxpdHkgdG8KICAgYXV0aGVudGljYXRlIHNlY3VyZWx5 IHdpdGggdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIChpLmUuIGFiaWxpdHkgdG8KICAgbWFpbnRh aW4gdGhlIGNvbmZpZGVudGlhbGl0eSBvZiB0aGVpciBjbGllbnQgY3JlZGVudGlhbHMpOgoKICAg Y29uZmlkZW50aWFsCiAgICAgIENsaWVudHMgY2FwYWJsZSBvZiBtYWludGFpbmluZyB0aGUgY29u ZmlkZW50aWFsaXR5IG9mIHRoZWlyCiAgICAgIGNyZWRlbnRpYWxzIChlLmcuIGNsaWVudCBpbXBs ZW1lbnRlZCBvbiBhIHNlY3VyZSBzZXJ2ZXIgd2l0aAogICAgICByZXN0cmljdGVkIGFjY2VzcyB0 byB0aGUgY2xpZW50IGNyZWRlbnRpYWxzKSwgb3IgY2FwYWJsZSBvZiBzZWN1cmUKICAgICAgY2xp ZW50IGF1dGhlbnRpY2F0aW9uIHVzaW5nIG90aGVyIG1lYW5zLgogICBwdWJsaWMKICAgICAgQ2xp ZW50cyBpbmNhcGFibGUgb2YgbWFpbnRhaW5pbmcgdGhlIGNvbmZpZGVudGlhbGl0eSBvZiB0aGVp cgogICAgICBjcmVkZW50aWFscyAoZS5nLiBjbGllbnRzIGV4ZWN1dGluZyBvbiB0aGUgZGV2aWNl IHVzZWQgYnkgdGhlCiAgICAgIHJlc291cmNlIG93bmVyIHN1Y2ggYXMgYW4gaW5zdGFsbGVkIG5h dGl2ZSBhcHBsaWNhdGlvbiBvciBhIHdlYgogICAgICBicm93c2VyLWJhc2VkIGFwcGxpY2F0aW9u KSwgYW5kIGluY2FwYWJsZSBvZiBzZWN1cmUgY2xpZW50CiAgICAgIGF1dGhlbnRpY2F0aW9uIHZp YSBhbnkgb3RoZXIgbWVhbnMuCgogICBUaGUgY2xpZW50IHR5cGUgZGVzaWduYXRpb24gaXMgYmFz ZWQgb24gdGhlIGF1dGhvcml6YXRpb24gc2VydmVyJ3MKICAgZGVmaW5pdGlvbiBvZiBzZWN1cmUg YXV0aGVudGljYXRpb24gYW5kIGl0cyBhY2NlcHRhYmxlIGV4cG9zdXJlCiAgIGxldmVscyBvZiBj bGllbnQgY3JlZGVudGlhbHMuICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgU0hPVUxEIE5PVAog ICBtYWtlIGFzc3VtcHRpb25zIGFib3V0IHRoZSBjbGllbnQgdHlwZS4KCiAgIEEgY2xpZW50IG1h eSBiZSBpbXBsZW1lbnRlZCBhcyBhIGRpc3RyaWJ1dGVkIHNldCBvZiBjb21wb25lbnRzLCBlYWNo CiAgIHdpdGggYSBkaWZmZXJlbnQgY2xpZW50IHR5cGUgYW5kIHNlY3VyaXR5IGNvbnRleHQgKGUu Zy4gYSBkaXN0cmlidXRlZAogICBjbGllbnQgd2l0aCBib3RoIGEgY29uZmlkZW50aWFsIHNlcnZl ci1iYXNlZCBjb21wb25lbnQgYW5kIGEgcHVibGljCiAgIGJyb3dzZXItYmFzZWQgY29tcG9uZW50 KS4gIElmIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBkb2VzIG5vdAogICBwcm92aWRlIHN1cHBv cnQgZm9yIHN1Y2ggY2xpZW50cywgb3IgZG9lcyBub3QgcHJvdmlkZSBndWlkYW5jZSB3aXRoCiAg IHJlZ2FyZCB0byB0aGVpciByZWdpc3RyYXRpb24sIHRoZSBjbGllbnQgU0hPVUxEIHJlZ2lzdGVy IGVhY2gKICAgY29tcG9uZW50IGFzIGEgc2VwYXJhdGUgY2xpZW50LgoKICAgVGhpcyBzcGVjaWZp Y2F0aW9uIGhhcyBiZWVuIGRlc2lnbmVkIGFyb3VuZCB0aGUgZm9sbG93aW5nIGNsaWVudAogICBw cm9maWxlczoKCiAgIHdlYiBhcHBsaWNhdGlvbgogICAgICBBIHdlYiBhcHBsaWNhdGlvbiBpcyBh IGNvbmZpZGVudGlhbCBjbGllbnQgcnVubmluZyBvbiBhIHdlYgogICAgICBzZXJ2ZXIuICBSZXNv dXJjZSBvd25lcnMgYWNjZXNzIHRoZSBjbGllbnQgdmlhIGFuIEhUTUwgdXNlcgogICAgICBpbnRl cmZhY2UgcmVuZGVyZWQgaW4gYSB1c2VyLWFnZW50IG9uIHRoZSBkZXZpY2UgdXNlZCBieSB0aGUK ICAgICAgcmVzb3VyY2Ugb3duZXIuICBUaGUgY2xpZW50IGNyZWRlbnRpYWxzIGFzIHdlbGwgYXMg YW55IGFjY2VzcwogICAgICB0b2tlbiBpc3N1ZWQgdG8gdGhlIGNsaWVudCBhcmUgc3RvcmVkIG9u IHRoZSB3ZWIgc2VydmVyIGFuZCBhcmUKICAgICAgbm90IGV4cG9zZWQgdG8gb3IgYWNjZXNzaWJs ZSBieSB0aGUgcmVzb3VyY2Ugb3duZXIuCiAgIHVzZXItYWdlbnQtYmFzZWQgYXBwbGljYXRpb24K ICAgICAgQSB1c2VyLWFnZW50LWJhc2VkIGFwcGxpY2F0aW9uIGlzIGEgcHVibGljIGNsaWVudCBp biB3aGljaCB0aGUKICAgICAgY2xpZW50IGNvZGUgaXMgZG93bmxvYWRlZCBmcm9tIGEgd2ViIHNl cnZlciBhbmQgZXhlY3V0ZXMgd2l0aGluIGEKICAgICAgdXNlci1hZ2VudCAoZS5nLiB3ZWIgYnJv d3Nlcikgb24gdGhlIGRldmljZSB1c2VkIGJ5IHRoZSByZXNvdXJjZQogICAgICBvd25lci4gIFBy b3RvY29sIGRhdGEgYW5kIGNyZWRlbnRpYWxzIGFyZSBlYXNpbHkgYWNjZXNzaWJsZSAoYW5kCiAg ICAgIG9mdGVuIHZpc2libGUpIHRvIHRoZSByZXNvdXJjZSBvd25lci4gIFNpbmNlIHN1Y2ggYXBw bGljYXRpb25zCiAgICAgIHJlc2lkZSB3aXRoaW4gdGhlIHVzZXItYWdlbnQsIHRoZXkgY2FuIG1h a2Ugc2VhbWxlc3MgdXNlIG9mIHRoZQoKCgpIYW1tZXIsIGV0IGFsLiAgICAgICAgICBFeHBpcmVz IERlY2VtYmVyIDIwLCAyMDEyICAgICAgICAgICAgICBbUGFnZSAxNF0KDApJbnRlcm5ldC1EcmFm dCAgICAgICAgICAgICAgICAgIE9BdXRoIDIuMCAgICAgICAgICAgICAgICAgICAgICBKdW5lIDIw MTIKCgogICAgICB1c2VyLWFnZW50IGNhcGFiaWxpdGllcyB3aGVuIHJlcXVlc3RpbmcgYXV0aG9y aXphdGlvbi4KICAgbmF0aXZlIGFwcGxpY2F0aW9uCiAgICAgIEEgbmF0aXZlIGFwcGxpY2F0aW9u IGlzIGEgcHVibGljIGNsaWVudCBpbnN0YWxsZWQgYW5kIGV4ZWN1dGVkIG9uCiAgICAgIHRoZSBk ZXZpY2UgdXNlZCBieSB0aGUgcmVzb3VyY2Ugb3duZXIuICBQcm90b2NvbCBkYXRhIGFuZAogICAg ICBjcmVkZW50aWFscyBhcmUgYWNjZXNzaWJsZSB0byB0aGUgcmVzb3VyY2Ugb3duZXIuICBJdCBp cyBhc3N1bWVkCiAgICAgIHRoYXQgYW55IGNsaWVudCBhdXRoZW50aWNhdGlvbiBjcmVkZW50aWFs cyBpbmNsdWRlZCBpbiB0aGUKICAgICAgYXBwbGljYXRpb24gY2FuIGJlIGV4dHJhY3RlZC4gIE9u IHRoZSBvdGhlciBoYW5kLCBkeW5hbWljYWxseQogICAgICBpc3N1ZWQgY3JlZGVudGlhbHMgc3Vj aCBhcyBhY2Nlc3MgdG9rZW5zIG9yIHJlZnJlc2ggdG9rZW5zIGNhbgogICAgICByZWNlaXZlIGFu IGFjY2VwdGFibGUgbGV2ZWwgb2YgcHJvdGVjdGlvbi4gIEF0IGEgbWluaW11bSwgdGhlc2UKICAg ICAgY3JlZGVudGlhbHMgYXJlIHByb3RlY3RlZCBmcm9tIGhvc3RpbGUgc2VydmVycyB3aXRoIHdo aWNoIHRoZQogICAgICBhcHBsaWNhdGlvbiBtYXkgaW50ZXJhY3Qgd2l0aC4gIE9uIHNvbWUgcGxh dGZvcm1zIHRoZXNlCiAgICAgIGNyZWRlbnRpYWxzIG1pZ2h0IGJlIHByb3RlY3RlZCBmcm9tIG90 aGVyIGFwcGxpY2F0aW9ucyByZXNpZGluZyBvbgogICAgICB0aGUgc2FtZSBkZXZpY2UuCgoyLjIu ICBDbGllbnQgSWRlbnRpZmllcgoKICAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGlzc3VlcyB0 aGUgcmVnaXN0ZXJlZCBjbGllbnQgYSBjbGllbnQKICAgaWRlbnRpZmllciAtIGEgdW5pcXVlIHN0 cmluZyByZXByZXNlbnRpbmcgdGhlIHJlZ2lzdHJhdGlvbgogICBpbmZvcm1hdGlvbiBwcm92aWRl ZCBieSB0aGUgY2xpZW50LiAgVGhlIGNsaWVudCBpZGVudGlmaWVyIGlzIG5vdCBhCiAgIHNlY3Jl dDsgaXQgaXMgZXhwb3NlZCB0byB0aGUgcmVzb3VyY2Ugb3duZXIsIGFuZCBNVVNUIE5PVCBiZSB1 c2VkCiAgIGFsb25lIGZvciBjbGllbnQgYXV0aGVudGljYXRpb24uICBUaGUgY2xpZW50IGlkZW50 aWZpZXIgaXMgdW5pcXVlIHRvCiAgIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlci4KCiAgIFRoZSBj bGllbnQgaWRlbnRpZmllciBzdHJpbmcgc2l6ZSBpcyBsZWZ0IHVuZGVmaW5lZCBieSB0aGlzCiAg IHNwZWNpZmljYXRpb24uICBUaGUgY2xpZW50IHNob3VsZCBhdm9pZCBtYWtpbmcgYXNzdW1wdGlv bnMgYWJvdXQgdGhlCiAgIGlkZW50aWZpZXIgc2l6ZS4gIFRoZSBhdXRob3JpemF0aW9uIHNlcnZl ciBTSE9VTEQgZG9jdW1lbnQgdGhlIHNpemUKICAgb2YgYW55IGlkZW50aWZpZXIgaXQgaXNzdWVz LgoKMi4zLiAgQ2xpZW50IEF1dGhlbnRpY2F0aW9uCgogICBJZiB0aGUgY2xpZW50IHR5cGUgaXMg Y29uZmlkZW50aWFsLCB0aGUgY2xpZW50IGFuZCBhdXRob3JpemF0aW9uCiAgIHNlcnZlciBlc3Rh Ymxpc2ggYSBjbGllbnQgYXV0aGVudGljYXRpb24gbWV0aG9kIHN1aXRhYmxlIGZvciB0aGUKICAg c2VjdXJpdHkgcmVxdWlyZW1lbnRzIG9mIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlci4gIFRoZSBh dXRob3JpemF0aW9uCiAgIHNlcnZlciBNQVkgYWNjZXB0IGFueSBmb3JtIG9mIGNsaWVudCBhdXRo ZW50aWNhdGlvbiBtZWV0aW5nIGl0cwogICBzZWN1cml0eSByZXF1aXJlbWVudHMuCgogICBDb25m aWRlbnRpYWwgY2xpZW50cyBhcmUgdHlwaWNhbGx5IGlzc3VlZCAob3IgZXN0YWJsaXNoKSBhIHNl dCBvZgogICBjbGllbnQgY3JlZGVudGlhbHMgdXNlZCBmb3IgYXV0aGVudGljYXRpbmcgd2l0aCB0 aGUgYXV0aG9yaXphdGlvbgogICBzZXJ2ZXIgKGUuZy4gcGFzc3dvcmQsIHB1YmxpYy9wcml2YXRl IGtleSBwYWlyKS4KCiAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBNQVkgZXN0YWJsaXNoIGEg Y2xpZW50IGF1dGhlbnRpY2F0aW9uIG1ldGhvZAogICB3aXRoIHB1YmxpYyBjbGllbnRzLiAgSG93 ZXZlciwgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIE1VU1QgTk9UIHJlbHkKICAgb24gcHVibGlj IGNsaWVudCBhdXRoZW50aWNhdGlvbiBmb3IgdGhlIHB1cnBvc2Ugb2YgaWRlbnRpZnlpbmcgdGhl CiAgIGNsaWVudC4KCiAgIFRoZSBjbGllbnQgTVVTVCBOT1QgdXNlIG1vcmUgdGhhbiBvbmUgYXV0 aGVudGljYXRpb24gbWV0aG9kIGluIGVhY2gKICAgcmVxdWVzdC4KCgoKCkhhbW1lciwgZXQgYWwu ICAgICAgICAgIEV4cGlyZXMgRGVjZW1iZXIgMjAsIDIwMTIgICAgICAgICAgICAgIFtQYWdlIDE1 XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgT0F1dGggMi4wICAgICAgICAgICAg ICAgICAgICAgIEp1bmUgMjAxMgoKCjIuMy4xLiAgQ2xpZW50IFBhc3N3b3JkCgogICBDbGllbnRz IGluIHBvc3Nlc3Npb24gb2YgYSBjbGllbnQgcGFzc3dvcmQgTUFZIHVzZSB0aGUgSFRUUCBCYXNp YwogICBhdXRoZW50aWNhdGlvbiBzY2hlbWUgYXMgZGVmaW5lZCBpbiBbUkZDMjYxN10gdG8gYXV0 aGVudGljYXRlIHdpdGgKICAgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLiAgVGhlIGNsaWVudCBp ZGVudGlmaWVyIGlzIGVuY29kZWQgdXNpbmcgdGhlCiAgICJhcHBsaWNhdGlvbi94LXd3dy1mb3Jt LXVybGVuY29kZWQiIGNvbnRlbnQtdHlwZSBlbmNvZGluZyBtZXRob2QKICAgZGVmaW5lZCBieSBI VE1MIDQuMDEgW1czQy5SRUMtaHRtbDQwMS0xOTk5MTIyNF0gYW5kIHRoZSBlbmNvZGVkIHZhbHVl CiAgIGlzIHVzZWQgYXMgdGhlIHVzZXJuYW1lOyB0aGUgY2xpZW50IHBhc3N3b3JkIGlzIHVzZWQg YXMgdGhlIHBhc3N3b3JkLgogICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVTVCBzdXBwb3J0 IHRoZSBIVFRQIEJhc2ljIGF1dGhlbnRpY2F0aW9uCiAgIHNjaGVtZSBmb3IgYXV0aGVudGljYXRp bmcgY2xpZW50cyB0aGF0IHdlcmUgaXNzdWVkIGEgY2xpZW50IHBhc3N3b3JkLgoKICAgRm9yIGV4 YW1wbGUgKGV4dHJhIGxpbmUgYnJlYWtzIGFyZSBmb3IgZGlzcGxheSBwdXJwb3NlcyBvbmx5KToK CgogICAgIEF1dGhvcml6YXRpb246IEJhc2ljIGN6WkNhR1JTYTNGME16bzNSbXBtY0RCYVFuSXhT M1JFVW1KdVpsWmtiVWwzCgoKICAgQWx0ZXJuYXRpdmVseSwgdGhlIGF1dGhvcml6YXRpb24gc2Vy dmVyIE1BWSBzdXBwb3J0IGluY2x1ZGluZyB0aGUKICAgY2xpZW50IGNyZWRlbnRpYWxzIGluIHRo ZSByZXF1ZXN0IGJvZHkgdXNpbmcgdGhlIGZvbGxvd2luZwogICBwYXJhbWV0ZXJzOgoKICAgY2xp ZW50X2lkCiAgICAgICAgIFJFUVVJUkVELiAgVGhlIGNsaWVudCBpZGVudGlmaWVyIGlzc3VlZCB0 byB0aGUgY2xpZW50IGR1cmluZwogICAgICAgICB0aGUgcmVnaXN0cmF0aW9uIHByb2Nlc3MgZGVz Y3JpYmVkIGJ5IFNlY3Rpb24gMi4yLgogICBjbGllbnRfc2VjcmV0CiAgICAgICAgIFJFUVVJUkVE LiAgVGhlIGNsaWVudCBzZWNyZXQuICBUaGUgY2xpZW50IE1BWSBvbWl0IHRoZQogICAgICAgICBw YXJhbWV0ZXIgaWYgdGhlIGNsaWVudCBzZWNyZXQgaXMgYW4gZW1wdHkgc3RyaW5nLgoKICAgSW5j bHVkaW5nIHRoZSBjbGllbnQgY3JlZGVudGlhbHMgaW4gdGhlIHJlcXVlc3QgYm9keSB1c2luZyB0 aGUgdHdvCiAgIHBhcmFtZXRlcnMgaXMgTk9UIFJFQ09NTUVOREVELCBhbmQgU0hPVUxEIGJlIGxp bWl0ZWQgdG8gY2xpZW50cwogICB1bmFibGUgdG8gZGlyZWN0bHkgdXRpbGl6ZSB0aGUgSFRUUCBC YXNpYyBhdXRoZW50aWNhdGlvbiBzY2hlbWUgKG9yCiAgIG90aGVyIHBhc3N3b3JkLWJhc2VkIEhU VFAgYXV0aGVudGljYXRpb24gc2NoZW1lcykuICBUaGUgcGFyYW1ldGVycwogICBjYW4gb25seSBi ZSB0cmFuc21pdHRlZCBpbiB0aGUgcmVxdWVzdCBib2R5IGFuZCBNVVNUIE5PVCBiZSBpbmNsdWRl ZAogICBpbiB0aGUgcmVxdWVzdCBVUkkuCgogICBGb3IgZXhhbXBsZSwgcmVxdWVzdGluZyB0byBy ZWZyZXNoIGFuIGFjY2VzcyB0b2tlbiAoU2VjdGlvbiA2KSB1c2luZwogICB0aGUgYm9keSBwYXJh bWV0ZXJzIChleHRyYSBsaW5lIGJyZWFrcyBhcmUgZm9yIGRpc3BsYXkgcHVycG9zZXMKICAgb25s eSk6CgoKICAgICBQT1NUIC90b2tlbiBIVFRQLzEuMQogICAgIEhvc3Q6IHNlcnZlci5leGFtcGxl LmNvbQogICAgIENvbnRlbnQtVHlwZTogYXBwbGljYXRpb24veC13d3ctZm9ybS11cmxlbmNvZGVk O2NoYXJzZXQ9VVRGLTgKCiAgICAgZ3JhbnRfdHlwZT1yZWZyZXNoX3Rva2VuJnJlZnJlc2hfdG9r ZW49dEd6djNKT2tGMFhHNVF4MlRsS1dJQQogICAgICZjbGllbnRfaWQ9czZCaGRSa3F0MyZjbGll bnRfc2VjcmV0PTdGamZwMFpCcjFLdERSYm5mVmRtSXcKCgoKCgpIYW1tZXIsIGV0IGFsLiAgICAg ICAgICBFeHBpcmVzIERlY2VtYmVyIDIwLCAyMDEyICAgICAgICAgICAgICBbUGFnZSAxNl0KDApJ bnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgIE9BdXRoIDIuMCAgICAgICAgICAgICAgICAg ICAgICBKdW5lIDIwMTIKCgogICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVTVCByZXF1aXJl IHRoZSB1c2Ugb2YgVExTIGFzIGRlc2NyaWJlZCBpbgogICBTZWN0aW9uIDEuNiB3aGVuIHNlbmRp bmcgcmVxdWVzdHMgdXNpbmcgcGFzc3dvcmQgYXV0aGVudGljYXRpb24uCgogICBTaW5jZSB0aGlz IGNsaWVudCBhdXRoZW50aWNhdGlvbiBtZXRob2QgaW52b2x2ZXMgYSBwYXNzd29yZCwgdGhlCiAg IGF1dGhvcml6YXRpb24gc2VydmVyIE1VU1QgcHJvdGVjdCBhbnkgZW5kcG9pbnQgdXRpbGl6aW5n IGl0IGFnYWluc3QKICAgYnJ1dGUgZm9yY2UgYXR0YWNrcy4KCjIuMy4yLiAgT3RoZXIgQXV0aGVu dGljYXRpb24gTWV0aG9kcwoKICAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIE1BWSBzdXBwb3J0 IGFueSBzdWl0YWJsZSBIVFRQIGF1dGhlbnRpY2F0aW9uCiAgIHNjaGVtZSBtYXRjaGluZyBpdHMg c2VjdXJpdHkgcmVxdWlyZW1lbnRzLiAgV2hlbiB1c2luZyBvdGhlcgogICBhdXRoZW50aWNhdGlv biBtZXRob2RzLCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVTVCBkZWZpbmUgYQogICBtYXBw aW5nIGJldHdlZW4gdGhlIGNsaWVudCBpZGVudGlmaWVyIChyZWdpc3RyYXRpb24gcmVjb3JkKSBh bmQKICAgYXV0aGVudGljYXRpb24gc2NoZW1lLgoKMi40LiAgVW5yZWdpc3RlcmVkIENsaWVudHMK CiAgIFRoaXMgc3BlY2lmaWNhdGlvbiBkb2VzIG5vdCBleGNsdWRlIHRoZSB1c2Ugb2YgdW5yZWdp c3RlcmVkIGNsaWVudHMuCiAgIEhvd2V2ZXIsIHRoZSB1c2Ugd2l0aCBzdWNoIGNsaWVudHMgaXMg YmV5b25kIHRoZSBzY29wZSBvZiB0aGlzCiAgIHNwZWNpZmljYXRpb24sIGFuZCByZXF1aXJlcyBh ZGRpdGlvbmFsIHNlY3VyaXR5IGFuYWx5c2lzIGFuZCByZXZpZXcKICAgb2YgaXRzIGludGVyb3Bl cmFiaWxpdHkgaW1wYWN0LgoKCjMuICBQcm90b2NvbCBFbmRwb2ludHMKCiAgIFRoZSBhdXRob3Jp emF0aW9uIHByb2Nlc3MgdXRpbGl6ZXMgdHdvIGF1dGhvcml6YXRpb24gc2VydmVyIGVuZHBvaW50 cwogICAoSFRUUCByZXNvdXJjZXMpOgoKICAgbyAgQXV0aG9yaXphdGlvbiBlbmRwb2ludCAtIHVz ZWQgYnkgdGhlIGNsaWVudCB0byBvYnRhaW4KICAgICAgYXV0aG9yaXphdGlvbiBmcm9tIHRoZSBy ZXNvdXJjZSBvd25lciB2aWEgdXNlci1hZ2VudCByZWRpcmVjdGlvbi4KICAgbyAgVG9rZW4gZW5k cG9pbnQgLSB1c2VkIGJ5IHRoZSBjbGllbnQgdG8gZXhjaGFuZ2UgYW4gYXV0aG9yaXphdGlvbgog ICAgICBncmFudCBmb3IgYW4gYWNjZXNzIHRva2VuLCB0eXBpY2FsbHkgd2l0aCBjbGllbnQgYXV0 aGVudGljYXRpb24uCgogICBBcyB3ZWxsIGFzIG9uZSBjbGllbnQgZW5kcG9pbnQ6CgogICBvICBS ZWRpcmVjdGlvbiBlbmRwb2ludCAtIHVzZWQgYnkgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHRv IHJldHVybgogICAgICBhdXRob3JpemF0aW9uIGNyZWRlbnRpYWxzIHJlc3BvbnNlcyB0byB0aGUg Y2xpZW50IHZpYSB0aGUgcmVzb3VyY2UKICAgICAgb3duZXIgdXNlci1hZ2VudC4KCiAgIE5vdCBl dmVyeSBhdXRob3JpemF0aW9uIGdyYW50IHR5cGUgdXRpbGl6ZXMgYm90aCBlbmRwb2ludHMuCiAg IEV4dGVuc2lvbiBncmFudCB0eXBlcyBNQVkgZGVmaW5lIGFkZGl0aW9uYWwgZW5kcG9pbnRzIGFz IG5lZWRlZC4KCjMuMS4gIEF1dGhvcml6YXRpb24gRW5kcG9pbnQKCiAgIFRoZSBhdXRob3JpemF0 aW9uIGVuZHBvaW50IGlzIHVzZWQgdG8gaW50ZXJhY3Qgd2l0aCB0aGUgcmVzb3VyY2UKICAgb3du ZXIgYW5kIG9idGFpbiBhbiBhdXRob3JpemF0aW9uIGdyYW50LiAgVGhlIGF1dGhvcml6YXRpb24g c2VydmVyCiAgIE1VU1QgZmlyc3QgdmVyaWZ5IHRoZSBpZGVudGl0eSBvZiB0aGUgcmVzb3VyY2Ug b3duZXIuICBUaGUgd2F5IGluCiAgIHdoaWNoIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBhdXRo ZW50aWNhdGVzIHRoZSByZXNvdXJjZSBvd25lciAoZS5nLgoKCgpIYW1tZXIsIGV0IGFsLiAgICAg ICAgICBFeHBpcmVzIERlY2VtYmVyIDIwLCAyMDEyICAgICAgICAgICAgICBbUGFnZSAxN10KDApJ bnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgIE9BdXRoIDIuMCAgICAgICAgICAgICAgICAg ICAgICBKdW5lIDIwMTIKCgogICB1c2VybmFtZSBhbmQgcGFzc3dvcmQgbG9naW4sIHNlc3Npb24g Y29va2llcykgaXMgYmV5b25kIHRoZSBzY29wZSBvZgogICB0aGlzIHNwZWNpZmljYXRpb24uCgog ICBUaGUgbWVhbnMgdGhyb3VnaCB3aGljaCB0aGUgY2xpZW50IG9idGFpbnMgdGhlIGxvY2F0aW9u IG9mIHRoZQogICBhdXRob3JpemF0aW9uIGVuZHBvaW50IGFyZSBiZXlvbmQgdGhlIHNjb3BlIG9m IHRoaXMgc3BlY2lmaWNhdGlvbiwKICAgYnV0IHRoZSBsb2NhdGlvbiBpcyB0eXBpY2FsbHkgcHJv dmlkZWQgaW4gdGhlIHNlcnZpY2UgZG9jdW1lbnRhdGlvbi4KCiAgIFRoZSBlbmRwb2ludCBVUkkg TUFZIGluY2x1ZGUgYW4gImFwcGxpY2F0aW9uL3gtd3d3LWZvcm0tdXJsZW5jb2RlZCIKICAgZm9y bWF0dGVkIChbVzNDLlJFQy1odG1sNDAxLTE5OTkxMjI0XSkgcXVlcnkgY29tcG9uZW50IChbUkZD Mzk4Nl0KICAgc2VjdGlvbiAzLjQpLCB3aGljaCBNVVNUIGJlIHJldGFpbmVkIHdoZW4gYWRkaW5n IGFkZGl0aW9uYWwgcXVlcnkKICAgcGFyYW1ldGVycy4gIFRoZSBlbmRwb2ludCBVUkkgTVVTVCBO T1QgaW5jbHVkZSBhIGZyYWdtZW50IGNvbXBvbmVudC4KCiAgIFNpbmNlIHJlcXVlc3RzIHRvIHRo ZSBhdXRob3JpemF0aW9uIGVuZHBvaW50IHJlc3VsdCBpbiB1c2VyCiAgIGF1dGhlbnRpY2F0aW9u IGFuZCB0aGUgdHJhbnNtaXNzaW9uIG9mIGNsZWFyLXRleHQgY3JlZGVudGlhbHMgKGluIHRoZQog ICBIVFRQIHJlc3BvbnNlKSwgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIE1VU1QgcmVxdWlyZSB0 aGUgdXNlIG9mIFRMUwogICBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiAxLjYgd2hlbiBzZW5kaW5n IHJlcXVlc3RzIHRvIHRoZQogICBhdXRob3JpemF0aW9uIGVuZHBvaW50LgoKICAgVGhlIGF1dGhv cml6YXRpb24gc2VydmVyIE1VU1Qgc3VwcG9ydCB0aGUgdXNlIG9mIHRoZSBIVFRQICJHRVQiCiAg IG1ldGhvZCBbUkZDMjYxNl0gZm9yIHRoZSBhdXRob3JpemF0aW9uIGVuZHBvaW50LCBhbmQgTUFZ IHN1cHBvcnQgdGhlCiAgIHVzZSBvZiB0aGUgIlBPU1QiIG1ldGhvZCBhcyB3ZWxsLgoKICAgUGFy YW1ldGVycyBzZW50IHdpdGhvdXQgYSB2YWx1ZSBNVVNUIGJlIHRyZWF0ZWQgYXMgaWYgdGhleSB3 ZXJlCiAgIG9taXR0ZWQgZnJvbSB0aGUgcmVxdWVzdC4gIFRoZSBhdXRob3JpemF0aW9uIHNlcnZl ciBNVVNUIGlnbm9yZQogICB1bnJlY29nbml6ZWQgcmVxdWVzdCBwYXJhbWV0ZXJzLiAgUmVxdWVz dCBhbmQgcmVzcG9uc2UgcGFyYW1ldGVycwogICBNVVNUIE5PVCBiZSBpbmNsdWRlZCBtb3JlIHRo YW4gb25jZS4KCjMuMS4xLiAgUmVzcG9uc2UgVHlwZQoKICAgVGhlIGF1dGhvcml6YXRpb24gZW5k cG9pbnQgaXMgdXNlZCBieSB0aGUgYXV0aG9yaXphdGlvbiBjb2RlIGdyYW50CiAgIHR5cGUgYW5k IGltcGxpY2l0IGdyYW50IHR5cGUgZmxvd3MuICBUaGUgY2xpZW50IGluZm9ybXMgdGhlCiAgIGF1 dGhvcml6YXRpb24gc2VydmVyIG9mIHRoZSBkZXNpcmVkIGdyYW50IHR5cGUgdXNpbmcgdGhlIGZv bGxvd2luZwogICBwYXJhbWV0ZXI6CgogICByZXNwb25zZV90eXBlCiAgICAgICAgIFJFUVVJUkVE LiAgVGhlIHZhbHVlIE1VU1QgYmUgb25lIG9mICJjb2RlIiBmb3IgcmVxdWVzdGluZyBhbgogICAg ICAgICBhdXRob3JpemF0aW9uIGNvZGUgYXMgZGVzY3JpYmVkIGJ5IFNlY3Rpb24gNC4xLjEsICJ0 b2tlbiIgZm9yCiAgICAgICAgIHJlcXVlc3RpbmcgYW4gYWNjZXNzIHRva2VuIChpbXBsaWNpdCBn cmFudCkgYXMgZGVzY3JpYmVkIGJ5CiAgICAgICAgIFNlY3Rpb24gNC4yLjEsIG9yIGEgcmVnaXN0 ZXJlZCBleHRlbnNpb24gdmFsdWUgYXMgZGVzY3JpYmVkIGJ5CiAgICAgICAgIFNlY3Rpb24gOC40 LgoKICAgRXh0ZW5zaW9uIHJlc3BvbnNlIHR5cGVzIE1BWSBjb250YWluIGEgc3BhY2UtZGVsaW1p dGVkICgleDIwKSBsaXN0IG9mCiAgIHZhbHVlcywgd2hlcmUgdGhlIG9yZGVyIG9mIHZhbHVlcyBk b2VzIG5vdCBtYXR0ZXIgKGUuZy4gcmVzcG9uc2UgdHlwZQogICAiYSBiIiBpcyB0aGUgc2FtZSBh cyAiYiBhIikuICBUaGUgbWVhbmluZyBvZiBzdWNoIGNvbXBvc2l0ZSByZXNwb25zZQogICB0eXBl cyBpcyBkZWZpbmVkIGJ5IHRoZWlyIHJlc3BlY3RpdmUgc3BlY2lmaWNhdGlvbnMuCgogICBJZiBh biBhdXRob3JpemF0aW9uIHJlcXVlc3QgaXMgbWlzc2luZyB0aGUgInJlc3BvbnNlX3R5cGUiIHBh cmFtZXRlciwKICAgb3IgaWYgdGhlIHJlc3BvbnNlIHR5cGUgaXMgbm90IHVuZGVyc3Rvb2QsIHRo ZSBhdXRob3JpemF0aW9uIHNlcnZlcgoKCgpIYW1tZXIsIGV0IGFsLiAgICAgICAgICBFeHBpcmVz IERlY2VtYmVyIDIwLCAyMDEyICAgICAgICAgICAgICBbUGFnZSAxOF0KDApJbnRlcm5ldC1EcmFm dCAgICAgICAgICAgICAgICAgIE9BdXRoIDIuMCAgICAgICAgICAgICAgICAgICAgICBKdW5lIDIw MTIKCgogICBNVVNUIHJldHVybiBhbiBlcnJvciByZXNwb25zZSBhcyBkZXNjcmliZWQgaW4gU2Vj dGlvbiA0LjEuMi4xLgoKMy4xLjIuICBSZWRpcmVjdGlvbiBFbmRwb2ludAoKICAgQWZ0ZXIgY29t cGxldGluZyBpdHMgaW50ZXJhY3Rpb24gd2l0aCB0aGUgcmVzb3VyY2Ugb3duZXIsIHRoZQogICBh dXRob3JpemF0aW9uIHNlcnZlciBkaXJlY3RzIHRoZSByZXNvdXJjZSBvd25lcidzIHVzZXItYWdl bnQgYmFjayB0bwogICB0aGUgY2xpZW50LiAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHJlZGly ZWN0cyB0aGUgdXNlci1hZ2VudCB0byB0aGUKICAgY2xpZW50J3MgcmVkaXJlY3Rpb24gZW5kcG9p bnQgcHJldmlvdXNseSBlc3RhYmxpc2hlZCB3aXRoIHRoZQogICBhdXRob3JpemF0aW9uIHNlcnZl ciBkdXJpbmcgdGhlIGNsaWVudCByZWdpc3RyYXRpb24gcHJvY2VzcyBvciB3aGVuCiAgIG1ha2lu ZyB0aGUgYXV0aG9yaXphdGlvbiByZXF1ZXN0LgoKICAgVGhlIHJlZGlyZWN0aW9uIGVuZHBvaW50 IFVSSSBNVVNUIGJlIGFuIGFic29sdXRlIFVSSSBhcyBkZWZpbmVkIGJ5CiAgIFtSRkMzOTg2XSBz ZWN0aW9uIDQuMy4gIFRoZSBlbmRwb2ludCBVUkkgTUFZIGluY2x1ZGUgYW4KICAgImFwcGxpY2F0 aW9uL3gtd3d3LWZvcm0tdXJsZW5jb2RlZCIgZm9ybWF0dGVkCiAgIChbVzNDLlJFQy1odG1sNDAx LTE5OTkxMjI0XSkgcXVlcnkgY29tcG9uZW50IChbUkZDMzk4Nl0gc2VjdGlvbiAzLjQpLAogICB3 aGljaCBNVVNUIGJlIHJldGFpbmVkIHdoZW4gYWRkaW5nIGFkZGl0aW9uYWwgcXVlcnkgcGFyYW1l dGVycy4gIFRoZQogICBlbmRwb2ludCBVUkkgTVVTVCBOT1QgaW5jbHVkZSBhIGZyYWdtZW50IGNv bXBvbmVudC4KCjMuMS4yLjEuICBFbmRwb2ludCBSZXF1ZXN0IENvbmZpZGVudGlhbGl0eQoKICAg VGhlIHJlZGlyZWN0aW9uIGVuZHBvaW50IFNIT1VMRCByZXF1aXJlIHRoZSB1c2Ugb2YgVExTIGFz IGRlc2NyaWJlZAogICBpbiBTZWN0aW9uIDEuNiB3aGVuIHRoZSByZXF1ZXN0ZWQgcmVzcG9uc2Ug dHlwZSBpcyAiY29kZSIgb3IgInRva2VuIiwKICAgb3Igd2hlbiB0aGUgcmVkaXJlY3Rpb24gcmVx dWVzdCB3aWxsIHJlc3VsdCBpbiB0aGUgdHJhbnNtaXNzaW9uIG9mCiAgIHNlbnNpdGl2ZSBjcmVk ZW50aWFscyBvdmVyIGFuIG9wZW4gbmV0d29yay4gIFRoaXMgc3BlY2lmaWNhdGlvbiBkb2VzCiAg IG5vdCBtYW5kYXRlIHRoZSB1c2Ugb2YgVExTIGJlY2F1c2UgYXQgdGhlIHRpbWUgb2YgdGhpcyB3 cml0aW5nLAogICByZXF1aXJpbmcgY2xpZW50cyB0byBkZXBsb3kgVExTIGlzIGEgc2lnbmlmaWNh bnQgaHVyZGxlIGZvciBtYW55CiAgIGNsaWVudCBkZXZlbG9wZXJzLiAgSWYgVExTIGlzIG5vdCBh dmFpbGFibGUsIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlcgogICBTSE9VTEQgd2FybiB0aGUgcmVz b3VyY2Ugb3duZXIgYWJvdXQgdGhlIGluc2VjdXJlIGVuZHBvaW50IHByaW9yIHRvCiAgIHJlZGly ZWN0aW9uIChlLmcuIGRpc3BsYXkgYSBtZXNzYWdlIGR1cmluZyB0aGUgYXV0aG9yaXphdGlvbgog ICByZXF1ZXN0KS4KCiAgIExhY2sgb2YgdHJhbnNwb3J0LWxheWVyIHNlY3VyaXR5IGNhbiBoYXZl IGEgc2V2ZXJlIGltcGFjdCBvbiB0aGUKICAgc2VjdXJpdHkgb2YgdGhlIGNsaWVudCBhbmQgdGhl IHByb3RlY3RlZCByZXNvdXJjZXMgaXQgaXMgYXV0aG9yaXplZAogICB0byBhY2Nlc3MuICBUaGUg dXNlIG9mIHRyYW5zcG9ydC1sYXllciBzZWN1cml0eSBpcyBwYXJ0aWN1bGFybHkKICAgY3JpdGlj YWwgd2hlbiB0aGUgYXV0aG9yaXphdGlvbiBwcm9jZXNzIGlzIHVzZWQgYXMgYSBmb3JtIG9mCiAg IGRlbGVnYXRlZCBlbmQtdXNlciBhdXRoZW50aWNhdGlvbiBieSB0aGUgY2xpZW50IChlLmcuIHRo aXJkLXBhcnR5CiAgIHNpZ24taW4gc2VydmljZSkuCgozLjEuMi4yLiAgUmVnaXN0cmF0aW9uIFJl cXVpcmVtZW50cwoKICAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIE1VU1QgcmVxdWlyZSB0aGUg Zm9sbG93aW5nIGNsaWVudHMgdG8KICAgcmVnaXN0ZXIgdGhlaXIgcmVkaXJlY3Rpb24gZW5kcG9p bnQ6CgogICBvICBQdWJsaWMgY2xpZW50cy4KICAgbyAgQ29uZmlkZW50aWFsIGNsaWVudHMgdXRp bGl6aW5nIHRoZSBpbXBsaWNpdCBncmFudCB0eXBlLgoKICAgVGhlIGF1dGhvcml6YXRpb24gc2Vy dmVyIFNIT1VMRCByZXF1aXJlIGFsbCBjbGllbnRzIHRvIHJlZ2lzdGVyIHRoZWlyCiAgIHJlZGly ZWN0aW9uIGVuZHBvaW50IHByaW9yIHRvIHV0aWxpemluZyB0aGUgYXV0aG9yaXphdGlvbiBlbmRw b2ludC4KCgoKSGFtbWVyLCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBEZWNlbWJlciAyMCwgMjAx MiAgICAgICAgICAgICAgW1BhZ2UgMTldCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAg ICBPQXV0aCAyLjAgICAgICAgICAgICAgICAgICAgICAgSnVuZSAyMDEyCgoKICAgVGhlIGF1dGhv cml6YXRpb24gc2VydmVyIFNIT1VMRCByZXF1aXJlIHRoZSBjbGllbnQgdG8gcHJvdmlkZSB0aGUK ICAgY29tcGxldGUgcmVkaXJlY3Rpb24gVVJJICh0aGUgY2xpZW50IE1BWSB1c2UgdGhlICJzdGF0 ZSIgcmVxdWVzdAogICBwYXJhbWV0ZXIgdG8gYWNoaWV2ZSBwZXItcmVxdWVzdCBjdXN0b21pemF0 aW9uKS4gIElmIHJlcXVpcmluZyB0aGUKICAgcmVnaXN0cmF0aW9uIG9mIHRoZSBjb21wbGV0ZSBy ZWRpcmVjdGlvbiBVUkkgaXMgbm90IHBvc3NpYmxlLCB0aGUKICAgYXV0aG9yaXphdGlvbiBzZXJ2 ZXIgU0hPVUxEIHJlcXVpcmUgdGhlIHJlZ2lzdHJhdGlvbiBvZiB0aGUgVVJJCiAgIHNjaGVtZSwg YXV0aG9yaXR5LCBhbmQgcGF0aCAoYWxsb3dpbmcgdGhlIGNsaWVudCB0byBkeW5hbWljYWxseSB2 YXJ5CiAgIG9ubHkgdGhlIHF1ZXJ5IGNvbXBvbmVudCBvZiB0aGUgcmVkaXJlY3Rpb24gVVJJIHdo ZW4gcmVxdWVzdGluZwogICBhdXRob3JpemF0aW9uKS4KCiAgIFRoZSBhdXRob3JpemF0aW9uIHNl cnZlciBNQVkgYWxsb3cgdGhlIGNsaWVudCB0byByZWdpc3RlciBtdWx0aXBsZQogICByZWRpcmVj dGlvbiBlbmRwb2ludHMuCgogICBMYWNrIG9mIGEgcmVkaXJlY3Rpb24gVVJJIHJlZ2lzdHJhdGlv biByZXF1aXJlbWVudCBjYW4gZW5hYmxlIGFuCiAgIGF0dGFja2VyIHRvIHVzZSB0aGUgYXV0aG9y aXphdGlvbiBlbmRwb2ludCBhcyBvcGVuIHJlZGlyZWN0b3IgYXMKICAgZGVzY3JpYmVkIGluIFNl Y3Rpb24gMTAuMTUuCgozLjEuMi4zLiAgRHluYW1pYyBDb25maWd1cmF0aW9uCgogICBJZiBtdWx0 aXBsZSByZWRpcmVjdGlvbiBVUklzIGhhdmUgYmVlbiByZWdpc3RlcmVkLCBpZiBvbmx5IHBhcnQg b2YKICAgdGhlIHJlZGlyZWN0aW9uIFVSSSBoYXMgYmVlbiByZWdpc3RlcmVkLCBvciBpZiBubyBy ZWRpcmVjdGlvbiBVUkkgaGFzCiAgIGJlZW4gcmVnaXN0ZXJlZCwgdGhlIGNsaWVudCBNVVNUIGlu Y2x1ZGUgYSByZWRpcmVjdGlvbiBVUkkgd2l0aCB0aGUKICAgYXV0aG9yaXphdGlvbiByZXF1ZXN0 IHVzaW5nIHRoZSAicmVkaXJlY3RfdXJpIiByZXF1ZXN0IHBhcmFtZXRlci4KCiAgIFdoZW4gYSBy ZWRpcmVjdGlvbiBVUkkgaXMgaW5jbHVkZWQgaW4gYW4gYXV0aG9yaXphdGlvbiByZXF1ZXN0LCB0 aGUKICAgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVTVCBjb21wYXJlIGFuZCBtYXRjaCB0aGUgdmFs dWUgcmVjZWl2ZWQKICAgYWdhaW5zdCBhdCBsZWFzdCBvbmUgb2YgdGhlIHJlZ2lzdGVyZWQgcmVk aXJlY3Rpb24gVVJJcyAob3IgVVJJCiAgIGNvbXBvbmVudHMpIGFzIGRlZmluZWQgaW4gW1JGQzM5 ODZdIHNlY3Rpb24gNiwgaWYgYW55IHJlZGlyZWN0aW9uCiAgIFVSSXMgd2VyZSByZWdpc3RlcmVk LiAgSWYgdGhlIGNsaWVudCByZWdpc3RyYXRpb24gaW5jbHVkZWQgdGhlIGZ1bGwKICAgcmVkaXJl Y3Rpb24gVVJJLCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVTVCBjb21wYXJlIHRoZSB0d28g VVJJcwogICB1c2luZyBzaW1wbGUgc3RyaW5nIGNvbXBhcmlzb24gYXMgZGVmaW5lZCBpbiBbUkZD Mzk4Nl0gc2VjdGlvbiA2LjIuMS4KCjMuMS4yLjQuICBJbnZhbGlkIEVuZHBvaW50CgogICBJZiBh biBhdXRob3JpemF0aW9uIHJlcXVlc3QgZmFpbHMgdmFsaWRhdGlvbiBkdWUgdG8gYSBtaXNzaW5n LAogICBpbnZhbGlkLCBvciBtaXNtYXRjaGluZyByZWRpcmVjdGlvbiBVUkksIHRoZSBhdXRob3Jp emF0aW9uIHNlcnZlcgogICBTSE9VTEQgaW5mb3JtIHRoZSByZXNvdXJjZSBvd25lciBvZiB0aGUg ZXJyb3IsIGFuZCBNVVNUIE5PVAogICBhdXRvbWF0aWNhbGx5IHJlZGlyZWN0IHRoZSB1c2VyLWFn ZW50IHRvIHRoZSBpbnZhbGlkIHJlZGlyZWN0aW9uIFVSSS4KCjMuMS4yLjUuICBFbmRwb2ludCBD b250ZW50CgogICBUaGUgcmVkaXJlY3Rpb24gcmVxdWVzdCB0byB0aGUgY2xpZW50J3MgZW5kcG9p bnQgdHlwaWNhbGx5IHJlc3VsdHMgaW4KICAgYW4gSFRNTCBkb2N1bWVudCByZXNwb25zZSwgcHJv Y2Vzc2VkIGJ5IHRoZSB1c2VyLWFnZW50LiAgSWYgdGhlIEhUTUwKICAgcmVzcG9uc2UgaXMgc2Vy dmVkIGRpcmVjdGx5IGFzIHRoZSByZXN1bHQgb2YgdGhlIHJlZGlyZWN0aW9uIHJlcXVlc3QsCiAg IGFueSBzY3JpcHQgaW5jbHVkZWQgaW4gdGhlIEhUTUwgZG9jdW1lbnQgd2lsbCBleGVjdXRlIHdp dGggZnVsbAogICBhY2Nlc3MgdG8gdGhlIHJlZGlyZWN0aW9uIFVSSSBhbmQgdGhlIGNyZWRlbnRp YWxzIGl0IGNvbnRhaW5zLgoKICAgVGhlIGNsaWVudCBTSE9VTEQgTk9UIGluY2x1ZGUgYW55IHRo aXJkLXBhcnR5IHNjcmlwdHMgKGUuZy4gdGhpcmQtCiAgIHBhcnR5IGFuYWx5dGljcywgc29jaWFs IHBsdWctaW5zLCBhZCBuZXR3b3JrcykgaW4gdGhlIHJlZGlyZWN0aW9uCgoKCkhhbW1lciwgZXQg YWwuICAgICAgICAgIEV4cGlyZXMgRGVjZW1iZXIgMjAsIDIwMTIgICAgICAgICAgICAgIFtQYWdl IDIwXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgT0F1dGggMi4wICAgICAgICAg ICAgICAgICAgICAgIEp1bmUgMjAxMgoKCiAgIGVuZHBvaW50IHJlc3BvbnNlLiAgSW5zdGVhZCwg aXQgU0hPVUxEIGV4dHJhY3QgdGhlIGNyZWRlbnRpYWxzIGZyb20KICAgdGhlIFVSSSBhbmQgcmVk aXJlY3QgdGhlIHVzZXItYWdlbnQgYWdhaW4gdG8gYW5vdGhlciBlbmRwb2ludCB3aXRob3V0CiAg IGV4cG9zaW5nIHRoZSBjcmVkZW50aWFscyAoaW4gdGhlIFVSSSBvciBlbHNld2hlcmUpLiAgSWYg dGhpcmQtcGFydHkKICAgc2NyaXB0cyBhcmUgaW5jbHVkZWQsIHRoZSBjbGllbnQgTVVTVCBlbnN1 cmUgdGhhdCBpdHMgb3duIHNjcmlwdHMKICAgKHVzZWQgdG8gZXh0cmFjdCBhbmQgcmVtb3ZlIHRo ZSBjcmVkZW50aWFscyBmcm9tIHRoZSBVUkkpIHdpbGwKICAgZXhlY3V0ZSBmaXJzdC4KCjMuMi4g IFRva2VuIEVuZHBvaW50CgogICBUaGUgdG9rZW4gZW5kcG9pbnQgaXMgdXNlZCBieSB0aGUgY2xp ZW50IHRvIG9idGFpbiBhbiBhY2Nlc3MgdG9rZW4gYnkKICAgcHJlc2VudGluZyBpdHMgYXV0aG9y aXphdGlvbiBncmFudCBvciByZWZyZXNoIHRva2VuLiAgVGhlIHRva2VuCiAgIGVuZHBvaW50IGlz IHVzZWQgd2l0aCBldmVyeSBhdXRob3JpemF0aW9uIGdyYW50IGV4Y2VwdCBmb3IgdGhlCiAgIGlt cGxpY2l0IGdyYW50IHR5cGUgKHNpbmNlIGFuIGFjY2VzcyB0b2tlbiBpcyBpc3N1ZWQgZGlyZWN0 bHkpLgoKICAgVGhlIG1lYW5zIHRocm91Z2ggd2hpY2ggdGhlIGNsaWVudCBvYnRhaW5zIHRoZSBs b2NhdGlvbiBvZiB0aGUgdG9rZW4KICAgZW5kcG9pbnQgYXJlIGJleW9uZCB0aGUgc2NvcGUgb2Yg dGhpcyBzcGVjaWZpY2F0aW9uIGJ1dCBpcyB0eXBpY2FsbHkKICAgcHJvdmlkZWQgaW4gdGhlIHNl cnZpY2UgZG9jdW1lbnRhdGlvbi4KCiAgIFRoZSBlbmRwb2ludCBVUkkgTUFZIGluY2x1ZGUgYW4g ImFwcGxpY2F0aW9uL3gtd3d3LWZvcm0tdXJsZW5jb2RlZCIKICAgZm9ybWF0dGVkIChbVzNDLlJF Qy1odG1sNDAxLTE5OTkxMjI0XSkgcXVlcnkgY29tcG9uZW50IChbUkZDMzk4Nl0KICAgc2VjdGlv biAzLjQpLCB3aGljaCBNVVNUIGJlIHJldGFpbmVkIHdoZW4gYWRkaW5nIGFkZGl0aW9uYWwgcXVl cnkKICAgcGFyYW1ldGVycy4gIFRoZSBlbmRwb2ludCBVUkkgTVVTVCBOT1QgaW5jbHVkZSBhIGZy YWdtZW50IGNvbXBvbmVudC4KCiAgIFNpbmNlIHJlcXVlc3RzIHRvIHRoZSB0b2tlbiBlbmRwb2lu dCByZXN1bHQgaW4gdGhlIHRyYW5zbWlzc2lvbiBvZgogICBjbGVhci10ZXh0IGNyZWRlbnRpYWxz IChpbiB0aGUgSFRUUCByZXF1ZXN0IGFuZCByZXNwb25zZSksIHRoZQogICBhdXRob3JpemF0aW9u IHNlcnZlciBNVVNUIHJlcXVpcmUgdGhlIHVzZSBvZiBUTFMgYXMgZGVzY3JpYmVkIGluCiAgIFNl Y3Rpb24gMS42IHdoZW4gc2VuZGluZyByZXF1ZXN0cyB0byB0aGUgdG9rZW4gZW5kcG9pbnQuCgog ICBUaGUgY2xpZW50IE1VU1QgdXNlIHRoZSBIVFRQICJQT1NUIiBtZXRob2Qgd2hlbiBtYWtpbmcg YWNjZXNzIHRva2VuCiAgIHJlcXVlc3RzLgoKICAgUGFyYW1ldGVycyBzZW50IHdpdGhvdXQgYSB2 YWx1ZSBNVVNUIGJlIHRyZWF0ZWQgYXMgaWYgdGhleSB3ZXJlCiAgIG9taXR0ZWQgZnJvbSB0aGUg cmVxdWVzdC4gIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBNVVNUIGlnbm9yZQogICB1bnJlY29n bml6ZWQgcmVxdWVzdCBwYXJhbWV0ZXJzLiAgUmVxdWVzdCBhbmQgcmVzcG9uc2UgcGFyYW1ldGVy cwogICBNVVNUIE5PVCBiZSBpbmNsdWRlZCBtb3JlIHRoYW4gb25jZS4KCjMuMi4xLiAgQ2xpZW50 IEF1dGhlbnRpY2F0aW9uCgogICBDb25maWRlbnRpYWwgY2xpZW50cyBvciBvdGhlciBjbGllbnRz IGlzc3VlZCBjbGllbnQgY3JlZGVudGlhbHMgTVVTVAogICBhdXRoZW50aWNhdGUgd2l0aCB0aGUg YXV0aG9yaXphdGlvbiBzZXJ2ZXIgYXMgZGVzY3JpYmVkIGluCiAgIFNlY3Rpb24gMi4zIHdoZW4g bWFraW5nIHJlcXVlc3RzIHRvIHRoZSB0b2tlbiBlbmRwb2ludC4gIENsaWVudAogICBhdXRoZW50 aWNhdGlvbiBpcyB1c2VkIGZvcjoKCiAgIG8gIEVuZm9yY2luZyB0aGUgYmluZGluZyBvZiByZWZy ZXNoIHRva2VucyBhbmQgYXV0aG9yaXphdGlvbiBjb2RlcyB0bwogICAgICB0aGUgY2xpZW50IHRo ZXkgd2VyZSBpc3N1ZWQgdG8uICBDbGllbnQgYXV0aGVudGljYXRpb24gaXMgY3JpdGljYWwKICAg ICAgd2hlbiBhbiBhdXRob3JpemF0aW9uIGNvZGUgaXMgdHJhbnNtaXR0ZWQgdG8gdGhlIHJlZGly ZWN0aW9uCiAgICAgIGVuZHBvaW50IG92ZXIgYW4gaW5zZWN1cmUgY2hhbm5lbCwgb3Igd2hlbiB0 aGUgcmVkaXJlY3Rpb24gVVJJIGhhcwogICAgICBub3QgYmVlbiByZWdpc3RlcmVkIGluIGZ1bGwu CgoKCkhhbW1lciwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgRGVjZW1iZXIgMjAsIDIwMTIgICAg ICAgICAgICAgIFtQYWdlIDIxXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgT0F1 dGggMi4wICAgICAgICAgICAgICAgICAgICAgIEp1bmUgMjAxMgoKCiAgIG8gIFJlY292ZXJpbmcg ZnJvbSBhIGNvbXByb21pc2VkIGNsaWVudCBieSBkaXNhYmxpbmcgdGhlIGNsaWVudCBvcgogICAg ICBjaGFuZ2luZyBpdHMgY3JlZGVudGlhbHMsIHRodXMgcHJldmVudGluZyBhbiBhdHRhY2tlciBm cm9tIGFidXNpbmcKICAgICAgc3RvbGVuIHJlZnJlc2ggdG9rZW5zLiAgQ2hhbmdpbmcgYSBzaW5n bGUgc2V0IG9mIGNsaWVudAogICAgICBjcmVkZW50aWFscyBpcyBzaWduaWZpY2FudGx5IGZhc3Rl ciB0aGFuIHJldm9raW5nIGFuIGVudGlyZSBzZXQgb2YKICAgICAgcmVmcmVzaCB0b2tlbnMuCiAg IG8gIEltcGxlbWVudGluZyBhdXRoZW50aWNhdGlvbiBtYW5hZ2VtZW50IGJlc3QgcHJhY3RpY2Vz IHdoaWNoCiAgICAgIHJlcXVpcmUgcGVyaW9kaWMgY3JlZGVudGlhbCByb3RhdGlvbi4gIFJvdGF0 aW9uIG9mIGFuIGVudGlyZSBzZXQKICAgICAgb2YgcmVmcmVzaCB0b2tlbnMgY2FuIGJlIGNoYWxs ZW5naW5nLCB3aGlsZSByb3RhdGlvbiBvZiBhIHNpbmdsZQogICAgICBzZXQgb2YgY2xpZW50IGNy ZWRlbnRpYWxzIGlzIHNpZ25pZmljYW50bHkgZWFzaWVyLgoKICAgQSBwdWJsaWMgY2xpZW50IHRo YXQgd2FzIG5vdCBpc3N1ZWQgYSBjbGllbnQgcGFzc3dvcmQgTUFZIHVzZSB0aGUKICAgImNsaWVu dF9pZCIgcmVxdWVzdCBwYXJhbWV0ZXIgdG8gaWRlbnRpZnkgaXRzZWxmIHdoZW4gc2VuZGluZwog ICByZXF1ZXN0cyB0byB0aGUgdG9rZW4gZW5kcG9pbnQgKGUuZy4gZm9yIHRoZSBwdXJwb3NlIG9m IHByb3ZpZGluZwogICBlbmQtdXNlciBjb250ZXh0LCBjbGllbnQgdXNhZ2Ugc3RhdGlzdGljcyku CgozLjMuICBBY2Nlc3MgVG9rZW4gU2NvcGUKCiAgIFRoZSBhdXRob3JpemF0aW9uIGFuZCB0b2tl biBlbmRwb2ludHMgYWxsb3cgdGhlIGNsaWVudCB0byBzcGVjaWZ5IHRoZQogICBzY29wZSBvZiB0 aGUgYWNjZXNzIHJlcXVlc3QgdXNpbmcgdGhlICJzY29wZSIgcmVxdWVzdCBwYXJhbWV0ZXIuICBJ bgogICB0dXJuLCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgdXNlcyB0aGUgInNjb3BlIiByZXNw b25zZSBwYXJhbWV0ZXIgdG8KICAgaW5mb3JtIHRoZSBjbGllbnQgb2YgdGhlIHNjb3BlIG9mIHRo ZSBhY2Nlc3MgdG9rZW4gaXNzdWVkLgoKICAgVGhlIHZhbHVlIG9mIHRoZSBzY29wZSBwYXJhbWV0 ZXIgaXMgZXhwcmVzc2VkIGFzIGEgbGlzdCBvZiBzcGFjZS0KICAgZGVsaW1pdGVkLCBjYXNlIHNl bnNpdGl2ZSBzdHJpbmdzLiAgVGhlIHN0cmluZ3MgYXJlIGRlZmluZWQgYnkgdGhlCiAgIGF1dGhv cml6YXRpb24gc2VydmVyLiAgSWYgdGhlIHZhbHVlIGNvbnRhaW5zIG11bHRpcGxlIHNwYWNlLWRl bGltaXRlZAogICBzdHJpbmdzLCB0aGVpciBvcmRlciBkb2VzIG5vdCBtYXR0ZXIsIGFuZCBlYWNo IHN0cmluZyBhZGRzIGFuCiAgIGFkZGl0aW9uYWwgYWNjZXNzIHJhbmdlIHRvIHRoZSByZXF1ZXN0 ZWQgc2NvcGUuCgoKICAgICBzY29wZSAgICAgICA9IHNjb3BlLXRva2VuICooIFNQIHNjb3BlLXRv a2VuICkKICAgICBzY29wZS10b2tlbiA9IDEqKCAleDIxIC8gJXgyMy01QiAvICV4NUQtN0UgKQoK CiAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBNQVkgZnVsbHkgb3IgcGFydGlhbGx5IGlnbm9y ZSB0aGUgc2NvcGUKICAgcmVxdWVzdGVkIGJ5IHRoZSBjbGllbnQgYmFzZWQgb24gdGhlIGF1dGhv cml6YXRpb24gc2VydmVyIHBvbGljeSBvcgogICB0aGUgcmVzb3VyY2Ugb3duZXIncyBpbnN0cnVj dGlvbnMuICBJZiB0aGUgaXNzdWVkIGFjY2VzcyB0b2tlbiBzY29wZQogICBpcyBkaWZmZXJlbnQg ZnJvbSB0aGUgb25lIHJlcXVlc3RlZCBieSB0aGUgY2xpZW50LCB0aGUgYXV0aG9yaXphdGlvbgog ICBzZXJ2ZXIgTVVTVCBpbmNsdWRlIHRoZSAic2NvcGUiIHJlc3BvbnNlIHBhcmFtZXRlciB0byBp bmZvcm0gdGhlCiAgIGNsaWVudCBvZiB0aGUgYWN0dWFsIHNjb3BlIGdyYW50ZWQuCgogICBJZiB0 aGUgY2xpZW50IG9taXRzIHRoZSBzY29wZSBwYXJhbWV0ZXIgd2hlbiByZXF1ZXN0aW5nCiAgIGF1 dGhvcml6YXRpb24sIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBNVVNUIGVpdGhlciBwcm9jZXNz IHRoZQogICByZXF1ZXN0IHVzaW5nIGEgcHJlLWRlZmluZWQgZGVmYXVsdCB2YWx1ZSwgb3IgZmFp bCB0aGUgcmVxdWVzdAogICBpbmRpY2F0aW5nIGFuIGludmFsaWQgc2NvcGUuICBUaGUgYXV0aG9y aXphdGlvbiBzZXJ2ZXIgU0hPVUxECiAgIGRvY3VtZW50IGl0cyBzY29wZSByZXF1aXJlbWVudHMg YW5kIGRlZmF1bHQgdmFsdWUgKGlmIGRlZmluZWQpLgoKCgoKCgpIYW1tZXIsIGV0IGFsLiAgICAg ICAgICBFeHBpcmVzIERlY2VtYmVyIDIwLCAyMDEyICAgICAgICAgICAgICBbUGFnZSAyMl0KDApJ bnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgIE9BdXRoIDIuMCAgICAgICAgICAgICAgICAg ICAgICBKdW5lIDIwMTIKCgo0LiAgT2J0YWluaW5nIEF1dGhvcml6YXRpb24KCiAgIFRvIHJlcXVl c3QgYW4gYWNjZXNzIHRva2VuLCB0aGUgY2xpZW50IG9idGFpbnMgYXV0aG9yaXphdGlvbiBmcm9t IHRoZQogICByZXNvdXJjZSBvd25lci4gIFRoZSBhdXRob3JpemF0aW9uIGlzIGV4cHJlc3NlZCBp biB0aGUgZm9ybSBvZiBhbgogICBhdXRob3JpemF0aW9uIGdyYW50IHdoaWNoIHRoZSBjbGllbnQg dXNlcyB0byByZXF1ZXN0IHRoZSBhY2Nlc3MKICAgdG9rZW4uICBPQXV0aCBkZWZpbmVzIGZvdXIg Z3JhbnQgdHlwZXM6IGF1dGhvcml6YXRpb24gY29kZSwgaW1wbGljaXQsCiAgIHJlc291cmNlIG93 bmVyIHBhc3N3b3JkIGNyZWRlbnRpYWxzLCBhbmQgY2xpZW50IGNyZWRlbnRpYWxzLiAgSXQgYWxz bwogICBwcm92aWRlcyBhbiBleHRlbnNpb24gbWVjaGFuaXNtIGZvciBkZWZpbmluZyBhZGRpdGlv bmFsIGdyYW50IHR5cGVzLgoKNC4xLiAgQXV0aG9yaXphdGlvbiBDb2RlIEdyYW50CgogICBUaGUg YXV0aG9yaXphdGlvbiBjb2RlIGdyYW50IHR5cGUgaXMgdXNlZCB0byBvYnRhaW4gYm90aCBhY2Nl c3MKICAgdG9rZW5zIGFuZCByZWZyZXNoIHRva2VucyBhbmQgaXMgb3B0aW1pemVkIGZvciBjb25m aWRlbnRpYWwgY2xpZW50cy4KICAgQXMgYSByZWRpcmVjdGlvbi1iYXNlZCBmbG93LCB0aGUgY2xp ZW50IG11c3QgYmUgY2FwYWJsZSBvZgogICBpbnRlcmFjdGluZyB3aXRoIHRoZSByZXNvdXJjZSBv d25lcidzIHVzZXItYWdlbnQgKHR5cGljYWxseSBhIHdlYgogICBicm93c2VyKSBhbmQgY2FwYWJs ZSBvZiByZWNlaXZpbmcgaW5jb21pbmcgcmVxdWVzdHMgKHZpYSByZWRpcmVjdGlvbikKICAgZnJv bSB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIuCgoKICAgICArLS0tLS0tLS0tLSsKICAgICB8IHJl c291cmNlIHwKICAgICB8ICAgb3duZXIgIHwKICAgICB8ICAgICAgICAgIHwKICAgICArLS0tLS0t LS0tLSsKICAgICAgICAgIF4KICAgICAgICAgIHwKICAgICAgICAgKEIpCiAgICAgKy0tLS18LS0t LS0rICAgICAgICAgIENsaWVudCBJZGVudGlmaWVyICAgICAgKy0tLS0tLS0tLS0tLS0tLSsKICAg ICB8ICAgICAgICAgLSstLS0tKEEpLS0gJiBSZWRpcmVjdGlvbiBVUkkgLS0tLT58ICAgICAgICAg ICAgICAgfAogICAgIHwgIFVzZXItICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHwgQXV0aG9yaXphdGlvbiB8CiAgICAgfCAgQWdlbnQgIC0rLS0tLShCKS0tIFVzZXIgYXV0aGVu dGljYXRlcyAtLS0+fCAgICAgU2VydmVyICAgIHwKICAgICB8ICAgICAgICAgIHwgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgfAogICAgIHwgICAgICAgICAt Ky0tLS0oQyktLSBBdXRob3JpemF0aW9uIENvZGUgLS0tPHwgICAgICAgICAgICAgICB8CiAgICAg Ky18LS0tLXwtLS0rICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0t LS0tLSsKICAgICAgIHwgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgXiAgICAgIHYKICAgICAgKEEpICAoQykgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfCAgICAgIHwKICAgICAgIHwgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgfCAgICAgIHwKICAgICAgIF4gICAgdiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgfCAgICAgIHwKICAgICArLS0tLS0tLS0tKyAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgIHwKICAgICB8ICAgICAgICAgfD4tLS0o RCktLSBBdXRob3JpemF0aW9uIENvZGUgLS0tLS0tLS0tJyAgICAgIHwKICAgICB8ICBDbGllbnQg fCAgICAgICAgICAmIFJlZGlyZWN0aW9uIFVSSSAgICAgICAgICAgICAgICAgIHwKICAgICB8ICAg ICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAg ICB8ICAgICAgICAgfDwtLS0oRSktLS0tLSBBY2Nlc3MgVG9rZW4gLS0tLS0tLS0tLS0tLS0tLS0t LScKICAgICArLS0tLS0tLS0tKyAgICAgICAody8gT3B0aW9uYWwgUmVmcmVzaCBUb2tlbikKCgog ICBOb3RlOiBUaGUgbGluZXMgaWxsdXN0cmF0aW5nIHN0ZXBzIEEsIEIsIGFuZCBDIGFyZSBicm9r ZW4gaW50byB0d28KICAgcGFydHMgYXMgdGhleSBwYXNzIHRocm91Z2ggdGhlIHVzZXItYWdlbnQu CgoKCkhhbW1lciwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgRGVjZW1iZXIgMjAsIDIwMTIgICAg ICAgICAgICAgIFtQYWdlIDIzXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgT0F1 dGggMi4wICAgICAgICAgICAgICAgICAgICAgIEp1bmUgMjAxMgoKCiAgICAgICAgICAgICAgICAg ICAgIEZpZ3VyZSAzOiBBdXRob3JpemF0aW9uIENvZGUgRmxvdwoKICAgVGhlIGZsb3cgaWxsdXN0 cmF0ZWQgaW4gRmlndXJlIDMgaW5jbHVkZXMgdGhlIGZvbGxvd2luZyBzdGVwczoKCiAgIChBKSAg VGhlIGNsaWVudCBpbml0aWF0ZXMgdGhlIGZsb3cgYnkgZGlyZWN0aW5nIHRoZSByZXNvdXJjZSBv d25lcidzCiAgICAgICAgdXNlci1hZ2VudCB0byB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludC4g IFRoZSBjbGllbnQgaW5jbHVkZXMKICAgICAgICBpdHMgY2xpZW50IGlkZW50aWZpZXIsIHJlcXVl c3RlZCBzY29wZSwgbG9jYWwgc3RhdGUsIGFuZCBhCiAgICAgICAgcmVkaXJlY3Rpb24gVVJJIHRv IHdoaWNoIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciB3aWxsIHNlbmQgdGhlCiAgICAgICAgdXNl ci1hZ2VudCBiYWNrIG9uY2UgYWNjZXNzIGlzIGdyYW50ZWQgKG9yIGRlbmllZCkuCiAgIChCKSAg VGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGF1dGhlbnRpY2F0ZXMgdGhlIHJlc291cmNlIG93bmVy ICh2aWEKICAgICAgICB0aGUgdXNlci1hZ2VudCkgYW5kIGVzdGFibGlzaGVzIHdoZXRoZXIgdGhl IHJlc291cmNlIG93bmVyCiAgICAgICAgZ3JhbnRzIG9yIGRlbmllcyB0aGUgY2xpZW50J3MgYWNj ZXNzIHJlcXVlc3QuCiAgIChDKSAgQXNzdW1pbmcgdGhlIHJlc291cmNlIG93bmVyIGdyYW50cyBh Y2Nlc3MsIHRoZSBhdXRob3JpemF0aW9uCiAgICAgICAgc2VydmVyIHJlZGlyZWN0cyB0aGUgdXNl ci1hZ2VudCBiYWNrIHRvIHRoZSBjbGllbnQgdXNpbmcgdGhlCiAgICAgICAgcmVkaXJlY3Rpb24g VVJJIHByb3ZpZGVkIGVhcmxpZXIgKGluIHRoZSByZXF1ZXN0IG9yIGR1cmluZwogICAgICAgIGNs aWVudCByZWdpc3RyYXRpb24pLiAgVGhlIHJlZGlyZWN0aW9uIFVSSSBpbmNsdWRlcyBhbgogICAg ICAgIGF1dGhvcml6YXRpb24gY29kZSBhbmQgYW55IGxvY2FsIHN0YXRlIHByb3ZpZGVkIGJ5IHRo ZSBjbGllbnQKICAgICAgICBlYXJsaWVyLgogICAoRCkgIFRoZSBjbGllbnQgcmVxdWVzdHMgYW4g YWNjZXNzIHRva2VuIGZyb20gdGhlIGF1dGhvcml6YXRpb24KICAgICAgICBzZXJ2ZXIncyB0b2tl biBlbmRwb2ludCBieSBpbmNsdWRpbmcgdGhlIGF1dGhvcml6YXRpb24gY29kZQogICAgICAgIHJl Y2VpdmVkIGluIHRoZSBwcmV2aW91cyBzdGVwLiAgV2hlbiBtYWtpbmcgdGhlIHJlcXVlc3QsIHRo ZQogICAgICAgIGNsaWVudCBhdXRoZW50aWNhdGVzIHdpdGggdGhlIGF1dGhvcml6YXRpb24gc2Vy dmVyLiAgVGhlIGNsaWVudAogICAgICAgIGluY2x1ZGVzIHRoZSByZWRpcmVjdGlvbiBVUkkgdXNl ZCB0byBvYnRhaW4gdGhlIGF1dGhvcml6YXRpb24KICAgICAgICBjb2RlIGZvciB2ZXJpZmljYXRp b24uCiAgIChFKSAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGF1dGhlbnRpY2F0ZXMgdGhlIGNs aWVudCwgdmFsaWRhdGVzIHRoZQogICAgICAgIGF1dGhvcml6YXRpb24gY29kZSwgYW5kIGVuc3Vy ZXMgdGhlIHJlZGlyZWN0aW9uIFVSSSByZWNlaXZlZAogICAgICAgIG1hdGNoZXMgdGhlIFVSSSB1 c2VkIHRvIHJlZGlyZWN0IHRoZSBjbGllbnQgaW4gc3RlcCAoQykuICBJZgogICAgICAgIHZhbGlk LCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgcmVzcG9uZHMgYmFjayB3aXRoIGFuIGFjY2Vzcwog ICAgICAgIHRva2VuIGFuZCBvcHRpb25hbGx5LCBhIHJlZnJlc2ggdG9rZW4uCgo0LjEuMS4gIEF1 dGhvcml6YXRpb24gUmVxdWVzdAoKICAgVGhlIGNsaWVudCBjb25zdHJ1Y3RzIHRoZSByZXF1ZXN0 IFVSSSBieSBhZGRpbmcgdGhlIGZvbGxvd2luZwogICBwYXJhbWV0ZXJzIHRvIHRoZSBxdWVyeSBj b21wb25lbnQgb2YgdGhlIGF1dGhvcml6YXRpb24gZW5kcG9pbnQgVVJJCiAgIHVzaW5nIHRoZSAi YXBwbGljYXRpb24veC13d3ctZm9ybS11cmxlbmNvZGVkIiBmb3JtYXQgYXMgZGVmaW5lZCBieQog ICBbVzNDLlJFQy1odG1sNDAxLTE5OTkxMjI0XToKCiAgIHJlc3BvbnNlX3R5cGUKICAgICAgICAg UkVRVUlSRUQuICBWYWx1ZSBNVVNUIGJlIHNldCB0byAiY29kZSIuCiAgIGNsaWVudF9pZAogICAg ICAgICBSRVFVSVJFRC4gIFRoZSBjbGllbnQgaWRlbnRpZmllciBhcyBkZXNjcmliZWQgaW4gU2Vj dGlvbiAyLjIuCiAgIHJlZGlyZWN0X3VyaQogICAgICAgICBPUFRJT05BTC4gIEFzIGRlc2NyaWJl ZCBpbiBTZWN0aW9uIDMuMS4yLgogICBzY29wZQogICAgICAgICBPUFRJT05BTC4gIFRoZSBzY29w ZSBvZiB0aGUgYWNjZXNzIHJlcXVlc3QgYXMgZGVzY3JpYmVkIGJ5CiAgICAgICAgIFNlY3Rpb24g My4zLgoKCgoKCkhhbW1lciwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgRGVjZW1iZXIgMjAsIDIw MTIgICAgICAgICAgICAgIFtQYWdlIDI0XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAg ICAgT0F1dGggMi4wICAgICAgICAgICAgICAgICAgICAgIEp1bmUgMjAxMgoKCiAgIHN0YXRlCiAg ICAgICAgIFJFQ09NTUVOREVELiAgQW4gb3BhcXVlIHZhbHVlIHVzZWQgYnkgdGhlIGNsaWVudCB0 byBtYWludGFpbgogICAgICAgICBzdGF0ZSBiZXR3ZWVuIHRoZSByZXF1ZXN0IGFuZCBjYWxsYmFj ay4gIFRoZSBhdXRob3JpemF0aW9uCiAgICAgICAgIHNlcnZlciBpbmNsdWRlcyB0aGlzIHZhbHVl IHdoZW4gcmVkaXJlY3RpbmcgdGhlIHVzZXItYWdlbnQgYmFjawogICAgICAgICB0byB0aGUgY2xp ZW50LiAgVGhlIHBhcmFtZXRlciBTSE9VTEQgYmUgdXNlZCBmb3IgcHJldmVudGluZwogICAgICAg ICBjcm9zcy1zaXRlIHJlcXVlc3QgZm9yZ2VyeSBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiAxMC4x Mi4KCiAgIFRoZSBjbGllbnQgZGlyZWN0cyB0aGUgcmVzb3VyY2Ugb3duZXIgdG8gdGhlIGNvbnN0 cnVjdGVkIFVSSSB1c2luZyBhbgogICBIVFRQIHJlZGlyZWN0aW9uIHJlc3BvbnNlLCBvciBieSBv dGhlciBtZWFucyBhdmFpbGFibGUgdG8gaXQgdmlhIHRoZQogICB1c2VyLWFnZW50LgoKICAgRm9y IGV4YW1wbGUsIHRoZSBjbGllbnQgZGlyZWN0cyB0aGUgdXNlci1hZ2VudCB0byBtYWtlIHRoZSBm b2xsb3dpbmcKICAgSFRUUCByZXF1ZXN0IHVzaW5nIFRMUyAoZXh0cmEgbGluZSBicmVha3MgYXJl IGZvciBkaXNwbGF5IHB1cnBvc2VzCiAgIG9ubHkpOgoKCiAgICBHRVQgL2F1dGhvcml6ZT9yZXNw b25zZV90eXBlPWNvZGUmY2xpZW50X2lkPXM2QmhkUmtxdDMmc3RhdGU9eHl6CiAgICAgICAgJnJl ZGlyZWN0X3VyaT1odHRwcyUzQSUyRiUyRmNsaWVudCUyRWV4YW1wbGUlMkVjb20lMkZjYiBIVFRQ LzEuMQogICAgSG9zdDogc2VydmVyLmV4YW1wbGUuY29tCgoKICAgVGhlIGF1dGhvcml6YXRpb24g c2VydmVyIHZhbGlkYXRlcyB0aGUgcmVxdWVzdCB0byBlbnN1cmUgYWxsIHJlcXVpcmVkCiAgIHBh cmFtZXRlcnMgYXJlIHByZXNlbnQgYW5kIHZhbGlkLiAgSWYgdGhlIHJlcXVlc3QgaXMgdmFsaWQs IHRoZQogICBhdXRob3JpemF0aW9uIHNlcnZlciBhdXRoZW50aWNhdGVzIHRoZSByZXNvdXJjZSBv d25lciBhbmQgb2J0YWlucyBhbgogICBhdXRob3JpemF0aW9uIGRlY2lzaW9uIChieSBhc2tpbmcg dGhlIHJlc291cmNlIG93bmVyIG9yIGJ5CiAgIGVzdGFibGlzaGluZyBhcHByb3ZhbCB2aWEgb3Ro ZXIgbWVhbnMpLgoKICAgV2hlbiBhIGRlY2lzaW9uIGlzIGVzdGFibGlzaGVkLCB0aGUgYXV0aG9y aXphdGlvbiBzZXJ2ZXIgZGlyZWN0cyB0aGUKICAgdXNlci1hZ2VudCB0byB0aGUgcHJvdmlkZWQg Y2xpZW50IHJlZGlyZWN0aW9uIFVSSSB1c2luZyBhbiBIVFRQCiAgIHJlZGlyZWN0aW9uIHJlc3Bv bnNlLCBvciBieSBvdGhlciBtZWFucyBhdmFpbGFibGUgdG8gaXQgdmlhIHRoZSB1c2VyLQogICBh Z2VudC4KCjQuMS4yLiAgQXV0aG9yaXphdGlvbiBSZXNwb25zZQoKICAgSWYgdGhlIHJlc291cmNl IG93bmVyIGdyYW50cyB0aGUgYWNjZXNzIHJlcXVlc3QsIHRoZSBhdXRob3JpemF0aW9uCiAgIHNl cnZlciBpc3N1ZXMgYW4gYXV0aG9yaXphdGlvbiBjb2RlIGFuZCBkZWxpdmVycyBpdCB0byB0aGUg Y2xpZW50IGJ5CiAgIGFkZGluZyB0aGUgZm9sbG93aW5nIHBhcmFtZXRlcnMgdG8gdGhlIHF1ZXJ5 IGNvbXBvbmVudCBvZiB0aGUKICAgcmVkaXJlY3Rpb24gVVJJIHVzaW5nIHRoZSAiYXBwbGljYXRp b24veC13d3ctZm9ybS11cmxlbmNvZGVkIiBmb3JtYXQ6CgogICBjb2RlCiAgICAgICAgIFJFUVVJ UkVELiAgVGhlIGF1dGhvcml6YXRpb24gY29kZSBnZW5lcmF0ZWQgYnkgdGhlCiAgICAgICAgIGF1 dGhvcml6YXRpb24gc2VydmVyLiAgVGhlIGF1dGhvcml6YXRpb24gY29kZSBNVVNUIGV4cGlyZQog ICAgICAgICBzaG9ydGx5IGFmdGVyIGl0IGlzIGlzc3VlZCB0byBtaXRpZ2F0ZSB0aGUgcmlzayBv ZiBsZWFrcy4gIEEKICAgICAgICAgbWF4aW11bSBhdXRob3JpemF0aW9uIGNvZGUgbGlmZXRpbWUg b2YgMTAgbWludXRlcyBpcwogICAgICAgICBSRUNPTU1FTkRFRC4gIFRoZSBjbGllbnQgTVVTVCBO T1QgdXNlIHRoZSBhdXRob3JpemF0aW9uIGNvZGUKICAgICAgICAgbW9yZSB0aGFuIG9uY2UuICBJ ZiBhbiBhdXRob3JpemF0aW9uIGNvZGUgaXMgdXNlZCBtb3JlIHRoYW4KICAgICAgICAgb25jZSwg dGhlIGF1dGhvcml6YXRpb24gc2VydmVyIE1VU1QgZGVueSB0aGUgcmVxdWVzdCBhbmQgU0hPVUxE CiAgICAgICAgIHJldm9rZSAod2hlbiBwb3NzaWJsZSkgYWxsIHRva2VucyBwcmV2aW91c2x5IGlz c3VlZCBiYXNlZCBvbgoKCgpIYW1tZXIsIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIERlY2VtYmVy IDIwLCAyMDEyICAgICAgICAgICAgICBbUGFnZSAyNV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAg ICAgICAgICAgIE9BdXRoIDIuMCAgICAgICAgICAgICAgICAgICAgICBKdW5lIDIwMTIKCgogICAg ICAgICB0aGF0IGF1dGhvcml6YXRpb24gY29kZS4gIFRoZSBhdXRob3JpemF0aW9uIGNvZGUgaXMg Ym91bmQgdG8KICAgICAgICAgdGhlIGNsaWVudCBpZGVudGlmaWVyIGFuZCByZWRpcmVjdGlvbiBV UkkuCiAgIHN0YXRlCiAgICAgICAgIFJFUVVJUkVEIGlmIHRoZSAic3RhdGUiIHBhcmFtZXRlciB3 YXMgcHJlc2VudCBpbiB0aGUgY2xpZW50CiAgICAgICAgIGF1dGhvcml6YXRpb24gcmVxdWVzdC4g IFRoZSBleGFjdCB2YWx1ZSByZWNlaXZlZCBmcm9tIHRoZQogICAgICAgICBjbGllbnQuCgogICBG b3IgZXhhbXBsZSwgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHJlZGlyZWN0cyB0aGUgdXNlci1h Z2VudCBieQogICBzZW5kaW5nIHRoZSBmb2xsb3dpbmcgSFRUUCByZXNwb25zZToKCgogICAgIEhU VFAvMS4xIDMwMiBGb3VuZAogICAgIExvY2F0aW9uOiBodHRwczovL2NsaWVudC5leGFtcGxlLmNv bS9jYj9jb2RlPVNwbHhsT0JlWlFRWWJZUzZXeFNiSUEKICAgICAgICAgICAgICAgJnN0YXRlPXh5 egoKCiAgIFRoZSBjbGllbnQgTVVTVCBpZ25vcmUgdW5yZWNvZ25pemVkIHJlc3BvbnNlIHBhcmFt ZXRlcnMuICBUaGUKICAgYXV0aG9yaXphdGlvbiBjb2RlIHN0cmluZyBzaXplIGlzIGxlZnQgdW5k ZWZpbmVkIGJ5IHRoaXMKICAgc3BlY2lmaWNhdGlvbi4gIFRoZSBjbGllbnQgc2hvdWxkIGF2b2lk IG1ha2luZyBhc3N1bXB0aW9ucyBhYm91dCBjb2RlCiAgIHZhbHVlIHNpemVzLiAgVGhlIGF1dGhv cml6YXRpb24gc2VydmVyIFNIT1VMRCBkb2N1bWVudCB0aGUgc2l6ZSBvZgogICBhbnkgdmFsdWUg aXQgaXNzdWVzLgoKNC4xLjIuMS4gIEVycm9yIFJlc3BvbnNlCgogICBJZiB0aGUgcmVxdWVzdCBm YWlscyBkdWUgdG8gYSBtaXNzaW5nLCBpbnZhbGlkLCBvciBtaXNtYXRjaGluZwogICByZWRpcmVj dGlvbiBVUkksIG9yIGlmIHRoZSBjbGllbnQgaWRlbnRpZmllciBpcyBtaXNzaW5nIG9yIGludmFs aWQsCiAgIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBTSE9VTEQgaW5mb3JtIHRoZSByZXNvdXJj ZSBvd25lciBvZiB0aGUKICAgZXJyb3IsIGFuZCBNVVNUIE5PVCBhdXRvbWF0aWNhbGx5IHJlZGly ZWN0IHRoZSB1c2VyLWFnZW50IHRvIHRoZQogICBpbnZhbGlkIHJlZGlyZWN0aW9uIFVSSS4KCiAg IElmIHRoZSByZXNvdXJjZSBvd25lciBkZW5pZXMgdGhlIGFjY2VzcyByZXF1ZXN0IG9yIGlmIHRo ZSByZXF1ZXN0CiAgIGZhaWxzIGZvciByZWFzb25zIG90aGVyIHRoYW4gYSBtaXNzaW5nIG9yIGlu dmFsaWQgcmVkaXJlY3Rpb24gVVJJLAogICB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgaW5mb3Jt cyB0aGUgY2xpZW50IGJ5IGFkZGluZyB0aGUgZm9sbG93aW5nCiAgIHBhcmFtZXRlcnMgdG8gdGhl IHF1ZXJ5IGNvbXBvbmVudCBvZiB0aGUgcmVkaXJlY3Rpb24gVVJJIHVzaW5nIHRoZQogICAiYXBw bGljYXRpb24veC13d3ctZm9ybS11cmxlbmNvZGVkIiBmb3JtYXQ6CgogICBlcnJvcgogICAgICAg ICBSRVFVSVJFRC4gIEEgc2luZ2xlIEFTQ0lJIFtVU0FTQ0lJXSBlcnJvciBjb2RlIGZyb20gdGhl CiAgICAgICAgIGZvbGxvd2luZzoKICAgICAgICAgaW52YWxpZF9yZXF1ZXN0CiAgICAgICAgICAg ICAgIFRoZSByZXF1ZXN0IGlzIG1pc3NpbmcgYSByZXF1aXJlZCBwYXJhbWV0ZXIsIGluY2x1ZGVz IGFuCiAgICAgICAgICAgICAgIGludmFsaWQgcGFyYW1ldGVyIHZhbHVlLCBpbmNsdWRlcyBhIHBh cmFtZXRlciBtb3JlIHRoYW4KICAgICAgICAgICAgICAgb25jZSwgb3IgaXMgb3RoZXJ3aXNlIG1h bGZvcm1lZC4KICAgICAgICAgdW5hdXRob3JpemVkX2NsaWVudAogICAgICAgICAgICAgICBUaGUg Y2xpZW50IGlzIG5vdCBhdXRob3JpemVkIHRvIHJlcXVlc3QgYW4gYXV0aG9yaXphdGlvbgogICAg ICAgICAgICAgICBjb2RlIHVzaW5nIHRoaXMgbWV0aG9kLgoKCgoKCkhhbW1lciwgZXQgYWwuICAg ICAgICAgIEV4cGlyZXMgRGVjZW1iZXIgMjAsIDIwMTIgICAgICAgICAgICAgIFtQYWdlIDI2XQoM CkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgT0F1dGggMi4wICAgICAgICAgICAgICAg ICAgICAgIEp1bmUgMjAxMgoKCiAgICAgICAgIGFjY2Vzc19kZW5pZWQKICAgICAgICAgICAgICAg VGhlIHJlc291cmNlIG93bmVyIG9yIGF1dGhvcml6YXRpb24gc2VydmVyIGRlbmllZCB0aGUKICAg ICAgICAgICAgICAgcmVxdWVzdC4KICAgICAgICAgdW5zdXBwb3J0ZWRfcmVzcG9uc2VfdHlwZQog ICAgICAgICAgICAgICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgZG9lcyBub3Qgc3VwcG9ydCBv YnRhaW5pbmcgYW4KICAgICAgICAgICAgICAgYXV0aG9yaXphdGlvbiBjb2RlIHVzaW5nIHRoaXMg bWV0aG9kLgogICAgICAgICBpbnZhbGlkX3Njb3BlCiAgICAgICAgICAgICAgIFRoZSByZXF1ZXN0 ZWQgc2NvcGUgaXMgaW52YWxpZCwgdW5rbm93biwgb3IgbWFsZm9ybWVkLgogICAgICAgICBzZXJ2 ZXJfZXJyb3IKICAgICAgICAgICAgICAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGVuY291bnRl cmVkIGFuIHVuZXhwZWN0ZWQKICAgICAgICAgICAgICAgY29uZGl0aW9uIHdoaWNoIHByZXZlbnRl ZCBpdCBmcm9tIGZ1bGZpbGxpbmcgdGhlIHJlcXVlc3QuCiAgICAgICAgIHRlbXBvcmFyaWx5X3Vu YXZhaWxhYmxlCiAgICAgICAgICAgICAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBpcyBjdXJy ZW50bHkgdW5hYmxlIHRvIGhhbmRsZQogICAgICAgICAgICAgICB0aGUgcmVxdWVzdCBkdWUgdG8g YSB0ZW1wb3Jhcnkgb3ZlcmxvYWRpbmcgb3IgbWFpbnRlbmFuY2UKICAgICAgICAgICAgICAgb2Yg dGhlIHNlcnZlci4KICAgICAgICAgVmFsdWVzIGZvciB0aGUgImVycm9yIiBwYXJhbWV0ZXIgTVVT VCBOT1QgaW5jbHVkZSBjaGFyYWN0ZXJzCiAgICAgICAgIG91dHNpZGUgdGhlIHNldCAleDIwLTIx IC8gJXgyMy01QiAvICV4NUQtN0UuCiAgIGVycm9yX2Rlc2NyaXB0aW9uCiAgICAgICAgIE9QVElP TkFMLiAgQSBodW1hbi1yZWFkYWJsZSBBU0NJSSBbVVNBU0NJSV0gdGV4dCBwcm92aWRpbmcKICAg ICAgICAgYWRkaXRpb25hbCBpbmZvcm1hdGlvbiwgdXNlZCB0byBhc3Npc3QgdGhlIGNsaWVudCBk ZXZlbG9wZXIgaW4KICAgICAgICAgdW5kZXJzdGFuZGluZyB0aGUgZXJyb3IgdGhhdCBvY2N1cnJl ZC4KICAgICAgICAgVmFsdWVzIGZvciB0aGUgImVycm9yX2Rlc2NyaXB0aW9uIiBwYXJhbWV0ZXIg TVVTVCBOT1QgaW5jbHVkZQogICAgICAgICBjaGFyYWN0ZXJzIG91dHNpZGUgdGhlIHNldCAleDIw LTIxIC8gJXgyMy01QiAvICV4NUQtN0UuCiAgIGVycm9yX3VyaQogICAgICAgICBPUFRJT05BTC4g IEEgVVJJIGlkZW50aWZ5aW5nIGEgaHVtYW4tcmVhZGFibGUgd2ViIHBhZ2Ugd2l0aAogICAgICAg ICBpbmZvcm1hdGlvbiBhYm91dCB0aGUgZXJyb3IsIHVzZWQgdG8gcHJvdmlkZSB0aGUgY2xpZW50 CiAgICAgICAgIGRldmVsb3BlciB3aXRoIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gYWJvdXQgdGhl IGVycm9yLgogICAgICAgICBWYWx1ZXMgZm9yIHRoZSAiZXJyb3JfdXJpIiBwYXJhbWV0ZXIgTVVT VCBjb25mb3JtIHRvIHRoZSBVUkktCiAgICAgICAgIFJlZmVyZW5jZSBzeW50YXgsIGFuZCB0aHVz IE1VU1QgTk9UIGluY2x1ZGUgY2hhcmFjdGVycyBvdXRzaWRlCiAgICAgICAgIHRoZSBzZXQgJXgy MSAvICV4MjMtNUIgLyAleDVELTdFLgogICBzdGF0ZQogICAgICAgICBSRVFVSVJFRCBpZiBhICJz dGF0ZSIgcGFyYW1ldGVyIHdhcyBwcmVzZW50IGluIHRoZSBjbGllbnQKICAgICAgICAgYXV0aG9y aXphdGlvbiByZXF1ZXN0LiAgVGhlIGV4YWN0IHZhbHVlIHJlY2VpdmVkIGZyb20gdGhlCiAgICAg ICAgIGNsaWVudC4KCiAgIEZvciBleGFtcGxlLCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgcmVk aXJlY3RzIHRoZSB1c2VyLWFnZW50IGJ5CiAgIHNlbmRpbmcgdGhlIGZvbGxvd2luZyBIVFRQIHJl c3BvbnNlOgoKCiAgIEhUVFAvMS4xIDMwMiBGb3VuZAogICBMb2NhdGlvbjogaHR0cHM6Ly9jbGll bnQuZXhhbXBsZS5jb20vY2I/ZXJyb3I9YWNjZXNzX2RlbmllZCZzdGF0ZT14eXoKCgo0LjEuMy4g IEFjY2VzcyBUb2tlbiBSZXF1ZXN0CgogICBUaGUgY2xpZW50IG1ha2VzIGEgcmVxdWVzdCB0byB0 aGUgdG9rZW4gZW5kcG9pbnQgYnkgYWRkaW5nIHRoZQogICBmb2xsb3dpbmcgcGFyYW1ldGVycyB1 c2luZyB0aGUgImFwcGxpY2F0aW9uL3gtd3d3LWZvcm0tdXJsZW5jb2RlZCIKICAgZm9ybWF0IGlu IHRoZSBIVFRQIHJlcXVlc3QgZW50aXR5LWJvZHk6CgoKCkhhbW1lciwgZXQgYWwuICAgICAgICAg IEV4cGlyZXMgRGVjZW1iZXIgMjAsIDIwMTIgICAgICAgICAgICAgIFtQYWdlIDI3XQoMCkludGVy bmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgT0F1dGggMi4wICAgICAgICAgICAgICAgICAgICAg IEp1bmUgMjAxMgoKCiAgIGdyYW50X3R5cGUKICAgICAgICAgUkVRVUlSRUQuICBWYWx1ZSBNVVNU IGJlIHNldCB0byAiYXV0aG9yaXphdGlvbl9jb2RlIi4KICAgY29kZQogICAgICAgICBSRVFVSVJF RC4gIFRoZSBhdXRob3JpemF0aW9uIGNvZGUgcmVjZWl2ZWQgZnJvbSB0aGUKICAgICAgICAgYXV0 aG9yaXphdGlvbiBzZXJ2ZXIuCiAgIHJlZGlyZWN0X3VyaQogICAgICAgICBSRVFVSVJFRCwgaWYg dGhlICJyZWRpcmVjdF91cmkiIHBhcmFtZXRlciB3YXMgaW5jbHVkZWQgaW4gdGhlCiAgICAgICAg IGF1dGhvcml6YXRpb24gcmVxdWVzdCBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiA0LjEuMSwgYW5k IHRoZWlyCiAgICAgICAgIHZhbHVlcyBNVVNUIGJlIGlkZW50aWNhbC4KCiAgIElmIHRoZSBjbGll bnQgdHlwZSBpcyBjb25maWRlbnRpYWwgb3IgdGhlIGNsaWVudCB3YXMgaXNzdWVkIGNsaWVudAog ICBjcmVkZW50aWFscyAob3IgYXNzaWduZWQgb3RoZXIgYXV0aGVudGljYXRpb24gcmVxdWlyZW1l bnRzKSwgdGhlCiAgIGNsaWVudCBNVVNUIGF1dGhlbnRpY2F0ZSB3aXRoIHRoZSBhdXRob3JpemF0 aW9uIHNlcnZlciBhcyBkZXNjcmliZWQKICAgaW4gU2VjdGlvbiAzLjIuMS4KCiAgIEZvciBleGFt cGxlLCB0aGUgY2xpZW50IG1ha2VzIHRoZSBmb2xsb3dpbmcgSFRUUCByZXF1ZXN0IHVzaW5nIFRM UwogICAoZXh0cmEgbGluZSBicmVha3MgYXJlIGZvciBkaXNwbGF5IHB1cnBvc2VzIG9ubHkpOgoK CiAgICAgUE9TVCAvdG9rZW4gSFRUUC8xLjEKICAgICBIb3N0OiBzZXJ2ZXIuZXhhbXBsZS5jb20K ICAgICBBdXRob3JpemF0aW9uOiBCYXNpYyBjelpDYUdSU2EzRjBNenBuV0RGbVFtRjBNMkpXCiAg ICAgQ29udGVudC1UeXBlOiBhcHBsaWNhdGlvbi94LXd3dy1mb3JtLXVybGVuY29kZWQ7Y2hhcnNl dD1VVEYtOAoKICAgICBncmFudF90eXBlPWF1dGhvcml6YXRpb25fY29kZSZjb2RlPVNwbHhsT0Jl WlFRWWJZUzZXeFNiSUEKICAgICAmcmVkaXJlY3RfdXJpPWh0dHBzJTNBJTJGJTJGY2xpZW50JTJF ZXhhbXBsZSUyRWNvbSUyRmNiCgoKICAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIE1VU1Q6Cgog ICBvICByZXF1aXJlIGNsaWVudCBhdXRoZW50aWNhdGlvbiBmb3IgY29uZmlkZW50aWFsIGNsaWVu dHMgb3IgZm9yIGFueQogICAgICBjbGllbnQgdGhhdCB3YXMgaXNzdWVkIGNsaWVudCBjcmVkZW50 aWFscyAob3Igd2l0aCBvdGhlcgogICAgICBhdXRoZW50aWNhdGlvbiByZXF1aXJlbWVudHMpLAog ICBvICBhdXRoZW50aWNhdGUgdGhlIGNsaWVudCBpZiBjbGllbnQgYXV0aGVudGljYXRpb24gaXMg aW5jbHVkZWQgYW5kCiAgICAgIGVuc3VyZSB0aGUgYXV0aG9yaXphdGlvbiBjb2RlIHdhcyBpc3N1 ZWQgdG8gdGhlIGF1dGhlbnRpY2F0ZWQKICAgICAgY2xpZW50LAogICBvICB2ZXJpZnkgdGhhdCB0 aGUgYXV0aG9yaXphdGlvbiBjb2RlIGlzIHZhbGlkLCBhbmQKICAgbyAgZW5zdXJlIHRoYXQgdGhl ICJyZWRpcmVjdF91cmkiIHBhcmFtZXRlciBpcyBwcmVzZW50IGlmIHRoZQogICAgICAicmVkaXJl Y3RfdXJpIiBwYXJhbWV0ZXIgd2FzIGluY2x1ZGVkIGluIHRoZSBpbml0aWFsIGF1dGhvcml6YXRp b24KICAgICAgcmVxdWVzdCBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiA0LjEuMSwgYW5kIGlmIGlu Y2x1ZGVkIGVuc3VyZQogICAgICB0aGVpciB2YWx1ZXMgYXJlIGlkZW50aWNhbC4KCjQuMS40LiAg QWNjZXNzIFRva2VuIFJlc3BvbnNlCgogICBJZiB0aGUgYWNjZXNzIHRva2VuIHJlcXVlc3QgaXMg dmFsaWQgYW5kIGF1dGhvcml6ZWQsIHRoZQogICBhdXRob3JpemF0aW9uIHNlcnZlciBpc3N1ZXMg YW4gYWNjZXNzIHRva2VuIGFuZCBvcHRpb25hbCByZWZyZXNoCiAgIHRva2VuIGFzIGRlc2NyaWJl ZCBpbiBTZWN0aW9uIDUuMS4gIElmIHRoZSByZXF1ZXN0IGNsaWVudAogICBhdXRoZW50aWNhdGlv biBmYWlsZWQgb3IgaXMgaW52YWxpZCwgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHJldHVybnMK CgoKSGFtbWVyLCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBEZWNlbWJlciAyMCwgMjAxMiAgICAg ICAgICAgICAgW1BhZ2UgMjhdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICBPQXV0 aCAyLjAgICAgICAgICAgICAgICAgICAgICAgSnVuZSAyMDEyCgoKICAgYW4gZXJyb3IgcmVzcG9u c2UgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gNS4yLgoKICAgQW4gZXhhbXBsZSBzdWNjZXNzZnVs IHJlc3BvbnNlOgoKCiAgICAgSFRUUC8xLjEgMjAwIE9LCiAgICAgQ29udGVudC1UeXBlOiBhcHBs aWNhdGlvbi9qc29uO2NoYXJzZXQ9VVRGLTgKICAgICBDYWNoZS1Db250cm9sOiBuby1zdG9yZQog ICAgIFByYWdtYTogbm8tY2FjaGUKCiAgICAgewogICAgICAgImFjY2Vzc190b2tlbiI6IjJZb3Ru RlpGRWpyMXpDc2ljTVdwQUEiLAogICAgICAgInRva2VuX3R5cGUiOiJleGFtcGxlIiwKICAgICAg ICJleHBpcmVzX2luIjozNjAwLAogICAgICAgInJlZnJlc2hfdG9rZW4iOiJ0R3p2M0pPa0YwWEc1 UXgyVGxLV0lBIiwKICAgICAgICJleGFtcGxlX3BhcmFtZXRlciI6ImV4YW1wbGVfdmFsdWUiCiAg ICAgfQoKCjQuMi4gIEltcGxpY2l0IEdyYW50CgogICBUaGUgaW1wbGljaXQgZ3JhbnQgdHlwZSBp cyB1c2VkIHRvIG9idGFpbiBhY2Nlc3MgdG9rZW5zIChpdCBkb2VzIG5vdAogICBzdXBwb3J0IHRo ZSBpc3N1YW5jZSBvZiByZWZyZXNoIHRva2VucykgYW5kIGlzIG9wdGltaXplZCBmb3IgcHVibGlj CiAgIGNsaWVudHMga25vd24gdG8gb3BlcmF0ZSBhIHBhcnRpY3VsYXIgcmVkaXJlY3Rpb24gVVJJ LiAgVGhlc2UgY2xpZW50cwogICBhcmUgdHlwaWNhbGx5IGltcGxlbWVudGVkIGluIGEgYnJvd3Nl ciB1c2luZyBhIHNjcmlwdGluZyBsYW5ndWFnZQogICBzdWNoIGFzIEphdmFTY3JpcHQuCgogICBB cyBhIHJlZGlyZWN0aW9uLWJhc2VkIGZsb3csIHRoZSBjbGllbnQgbXVzdCBiZSBjYXBhYmxlIG9m CiAgIGludGVyYWN0aW5nIHdpdGggdGhlIHJlc291cmNlIG93bmVyJ3MgdXNlci1hZ2VudCAodHlw aWNhbGx5IGEgd2ViCiAgIGJyb3dzZXIpIGFuZCBjYXBhYmxlIG9mIHJlY2VpdmluZyBpbmNvbWlu ZyByZXF1ZXN0cyAodmlhIHJlZGlyZWN0aW9uKQogICBmcm9tIHRoZSBhdXRob3JpemF0aW9uIHNl cnZlci4KCiAgIFVubGlrZSB0aGUgYXV0aG9yaXphdGlvbiBjb2RlIGdyYW50IHR5cGUgaW4gd2hp Y2ggdGhlIGNsaWVudCBtYWtlcwogICBzZXBhcmF0ZSByZXF1ZXN0cyBmb3IgYXV0aG9yaXphdGlv biBhbmQgYWNjZXNzIHRva2VuLCB0aGUgY2xpZW50CiAgIHJlY2VpdmVzIHRoZSBhY2Nlc3MgdG9r ZW4gYXMgdGhlIHJlc3VsdCBvZiB0aGUgYXV0aG9yaXphdGlvbiByZXF1ZXN0LgoKICAgVGhlIGlt cGxpY2l0IGdyYW50IHR5cGUgZG9lcyBub3QgaW5jbHVkZSBjbGllbnQgYXV0aGVudGljYXRpb24s IGFuZAogICByZWxpZXMgb24gdGhlIHByZXNlbmNlIG9mIHRoZSByZXNvdXJjZSBvd25lciBhbmQg dGhlIHJlZ2lzdHJhdGlvbiBvZgogICB0aGUgcmVkaXJlY3Rpb24gVVJJLiAgQmVjYXVzZSB0aGUg YWNjZXNzIHRva2VuIGlzIGVuY29kZWQgaW50byB0aGUKICAgcmVkaXJlY3Rpb24gVVJJLCBpdCBt YXkgYmUgZXhwb3NlZCB0byB0aGUgcmVzb3VyY2Ugb3duZXIgYW5kIG90aGVyCiAgIGFwcGxpY2F0 aW9ucyByZXNpZGluZyBvbiB0aGUgc2FtZSBkZXZpY2UuCgoKCgoKCgoKCgpIYW1tZXIsIGV0IGFs LiAgICAgICAgICBFeHBpcmVzIERlY2VtYmVyIDIwLCAyMDEyICAgICAgICAgICAgICBbUGFnZSAy OV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgIE9BdXRoIDIuMCAgICAgICAgICAg ICAgICAgICAgICBKdW5lIDIwMTIKCgogICAgICstLS0tLS0tLS0tKwogICAgIHwgUmVzb3VyY2Ug fAogICAgIHwgIE93bmVyICAgfAogICAgIHwgICAgICAgICAgfAogICAgICstLS0tLS0tLS0tKwog ICAgICAgICAgXgogICAgICAgICAgfAogICAgICAgICAoQikKICAgICArLS0tLXwtLS0tLSsgICAg ICAgICAgQ2xpZW50IElkZW50aWZpZXIgICAgICstLS0tLS0tLS0tLS0tLS0rCiAgICAgfCAgICAg ICAgIC0rLS0tLShBKS0tICYgUmVkaXJlY3Rpb24gVVJJIC0tLT58ICAgICAgICAgICAgICAgfAog ICAgIHwgIFVzZXItICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCBBdXRob3Jp emF0aW9uIHwKICAgICB8ICBBZ2VudCAgLXwtLS0tKEIpLS0gVXNlciBhdXRoZW50aWNhdGVzIC0t PnwgICAgIFNlcnZlciAgICB8CiAgICAgfCAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB8ICAgICAgICAgICAgICAgfAogICAgIHwgICAgICAgICAgfDwtLS0oQyktLS0g UmVkaXJlY3Rpb24gVVJJIC0tLS08fCAgICAgICAgICAgICAgIHwKICAgICB8ICAgICAgICAgIHwg ICAgICAgICAgd2l0aCBBY2Nlc3MgVG9rZW4gICAgICstLS0tLS0tLS0tLS0tLS0rCiAgICAgfCAg ICAgICAgICB8ICAgICAgICAgICAgaW4gRnJhZ21lbnQKICAgICB8ICAgICAgICAgIHwgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0rCiAgICAgfCAgICAgICAg ICB8LS0tLShEKS0tLSBSZWRpcmVjdGlvbiBVUkkgLS0tLT58ICAgV2ViLUhvc3RlZCAgfAogICAg IHwgICAgICAgICAgfCAgICAgICAgICB3aXRob3V0IEZyYWdtZW50ICAgICAgfCAgICAgQ2xpZW50 ICAgIHwKICAgICB8ICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwg ICAgUmVzb3VyY2UgICB8CiAgICAgfCAgICAgKEYpICB8PC0tLShFKS0tLS0tLS0gU2NyaXB0IC0t LS0tLS0tLTx8ICAgICAgICAgICAgICAgfAogICAgIHwgICAgICAgICAgfCAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLSsKICAgICArLXwtLS0tLS0tLSsKICAg ICAgIHwgICAgfAogICAgICAoQSkgIChHKSBBY2Nlc3MgVG9rZW4KICAgICAgIHwgICAgfAogICAg ICAgXiAgICB2CiAgICAgKy0tLS0tLS0tLSsKICAgICB8ICAgICAgICAgfAogICAgIHwgIENsaWVu dCB8CiAgICAgfCAgICAgICAgIHwKICAgICArLS0tLS0tLS0tKwoKCiAgIE5vdGU6IFRoZSBsaW5l cyBpbGx1c3RyYXRpbmcgc3RlcHMgQSBhbmQgQiBhcmUgYnJva2VuIGludG8gdHdvIHBhcnRzCiAg IGFzIHRoZXkgcGFzcyB0aHJvdWdoIHRoZSB1c2VyLWFnZW50LgoKICAgICAgICAgICAgICAgICAg ICAgICBGaWd1cmUgNDogSW1wbGljaXQgR3JhbnQgRmxvdwoKICAgVGhlIGZsb3cgaWxsdXN0cmF0 ZWQgaW4gRmlndXJlIDQgaW5jbHVkZXMgdGhlIGZvbGxvd2luZyBzdGVwczoKCiAgIChBKSAgVGhl IGNsaWVudCBpbml0aWF0ZXMgdGhlIGZsb3cgYnkgZGlyZWN0aW5nIHRoZSByZXNvdXJjZSBvd25l cidzCiAgICAgICAgdXNlci1hZ2VudCB0byB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludC4gIFRo ZSBjbGllbnQgaW5jbHVkZXMKICAgICAgICBpdHMgY2xpZW50IGlkZW50aWZpZXIsIHJlcXVlc3Rl ZCBzY29wZSwgbG9jYWwgc3RhdGUsIGFuZCBhCiAgICAgICAgcmVkaXJlY3Rpb24gVVJJIHRvIHdo aWNoIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciB3aWxsIHNlbmQgdGhlCiAgICAgICAgdXNlci1h Z2VudCBiYWNrIG9uY2UgYWNjZXNzIGlzIGdyYW50ZWQgKG9yIGRlbmllZCkuCgoKCgoKSGFtbWVy LCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBEZWNlbWJlciAyMCwgMjAxMiAgICAgICAgICAgICAg W1BhZ2UgMzBdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICBPQXV0aCAyLjAgICAg ICAgICAgICAgICAgICAgICAgSnVuZSAyMDEyCgoKICAgKEIpICBUaGUgYXV0aG9yaXphdGlvbiBz ZXJ2ZXIgYXV0aGVudGljYXRlcyB0aGUgcmVzb3VyY2Ugb3duZXIgKHZpYQogICAgICAgIHRoZSB1 c2VyLWFnZW50KSBhbmQgZXN0YWJsaXNoZXMgd2hldGhlciB0aGUgcmVzb3VyY2Ugb3duZXIKICAg ICAgICBncmFudHMgb3IgZGVuaWVzIHRoZSBjbGllbnQncyBhY2Nlc3MgcmVxdWVzdC4KICAgKEMp ICBBc3N1bWluZyB0aGUgcmVzb3VyY2Ugb3duZXIgZ3JhbnRzIGFjY2VzcywgdGhlIGF1dGhvcml6 YXRpb24KICAgICAgICBzZXJ2ZXIgcmVkaXJlY3RzIHRoZSB1c2VyLWFnZW50IGJhY2sgdG8gdGhl IGNsaWVudCB1c2luZyB0aGUKICAgICAgICByZWRpcmVjdGlvbiBVUkkgcHJvdmlkZWQgZWFybGll ci4gIFRoZSByZWRpcmVjdGlvbiBVUkkgaW5jbHVkZXMKICAgICAgICB0aGUgYWNjZXNzIHRva2Vu IGluIHRoZSBVUkkgZnJhZ21lbnQuCiAgIChEKSAgVGhlIHVzZXItYWdlbnQgZm9sbG93cyB0aGUg cmVkaXJlY3Rpb24gaW5zdHJ1Y3Rpb25zIGJ5IG1ha2luZyBhCiAgICAgICAgcmVxdWVzdCB0byB0 aGUgd2ViLWhvc3RlZCBjbGllbnQgcmVzb3VyY2UgKHdoaWNoIGRvZXMgbm90CiAgICAgICAgaW5j bHVkZSB0aGUgZnJhZ21lbnQgcGVyIFtSRkMyNjE2XSkuICBUaGUgdXNlci1hZ2VudCByZXRhaW5z IHRoZQogICAgICAgIGZyYWdtZW50IGluZm9ybWF0aW9uIGxvY2FsbHkuCiAgIChFKSAgVGhlIHdl Yi1ob3N0ZWQgY2xpZW50IHJlc291cmNlIHJldHVybnMgYSB3ZWIgcGFnZSAodHlwaWNhbGx5IGFu CiAgICAgICAgSFRNTCBkb2N1bWVudCB3aXRoIGFuIGVtYmVkZGVkIHNjcmlwdCkgY2FwYWJsZSBv ZiBhY2Nlc3NpbmcgdGhlCiAgICAgICAgZnVsbCByZWRpcmVjdGlvbiBVUkkgaW5jbHVkaW5nIHRo ZSBmcmFnbWVudCByZXRhaW5lZCBieSB0aGUKICAgICAgICB1c2VyLWFnZW50LCBhbmQgZXh0cmFj dGluZyB0aGUgYWNjZXNzIHRva2VuIChhbmQgb3RoZXIKICAgICAgICBwYXJhbWV0ZXJzKSBjb250 YWluZWQgaW4gdGhlIGZyYWdtZW50LgogICAoRikgIFRoZSB1c2VyLWFnZW50IGV4ZWN1dGVzIHRo ZSBzY3JpcHQgcHJvdmlkZWQgYnkgdGhlIHdlYi1ob3N0ZWQKICAgICAgICBjbGllbnQgcmVzb3Vy Y2UgbG9jYWxseSwgd2hpY2ggZXh0cmFjdHMgdGhlIGFjY2VzcyB0b2tlbiBhbmQKICAgICAgICBw YXNzZXMgaXQgdG8gdGhlIGNsaWVudC4KCjQuMi4xLiAgQXV0aG9yaXphdGlvbiBSZXF1ZXN0Cgog ICBUaGUgY2xpZW50IGNvbnN0cnVjdHMgdGhlIHJlcXVlc3QgVVJJIGJ5IGFkZGluZyB0aGUgZm9s bG93aW5nCiAgIHBhcmFtZXRlcnMgdG8gdGhlIHF1ZXJ5IGNvbXBvbmVudCBvZiB0aGUgYXV0aG9y aXphdGlvbiBlbmRwb2ludCBVUkkKICAgdXNpbmcgdGhlICJhcHBsaWNhdGlvbi94LXd3dy1mb3Jt LXVybGVuY29kZWQiIGZvcm1hdDoKCiAgIHJlc3BvbnNlX3R5cGUKICAgICAgICAgUkVRVUlSRUQu ICBWYWx1ZSBNVVNUIGJlIHNldCB0byAidG9rZW4iLgogICBjbGllbnRfaWQKICAgICAgICAgUkVR VUlSRUQuICBUaGUgY2xpZW50IGlkZW50aWZpZXIgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gMi4y LgogICByZWRpcmVjdF91cmkKICAgICAgICAgT1BUSU9OQUwuICBBcyBkZXNjcmliZWQgaW4gU2Vj dGlvbiAzLjEuMi4KICAgc2NvcGUKICAgICAgICAgT1BUSU9OQUwuICBUaGUgc2NvcGUgb2YgdGhl IGFjY2VzcyByZXF1ZXN0IGFzIGRlc2NyaWJlZCBieQogICAgICAgICBTZWN0aW9uIDMuMy4KICAg c3RhdGUKICAgICAgICAgUkVDT01NRU5ERUQuICBBbiBvcGFxdWUgdmFsdWUgdXNlZCBieSB0aGUg Y2xpZW50IHRvIG1haW50YWluCiAgICAgICAgIHN0YXRlIGJldHdlZW4gdGhlIHJlcXVlc3QgYW5k IGNhbGxiYWNrLiAgVGhlIGF1dGhvcml6YXRpb24KICAgICAgICAgc2VydmVyIGluY2x1ZGVzIHRo aXMgdmFsdWUgd2hlbiByZWRpcmVjdGluZyB0aGUgdXNlci1hZ2VudCBiYWNrCiAgICAgICAgIHRv IHRoZSBjbGllbnQuICBUaGUgcGFyYW1ldGVyIFNIT1VMRCBiZSB1c2VkIGZvciBwcmV2ZW50aW5n CiAgICAgICAgIGNyb3NzLXNpdGUgcmVxdWVzdCBmb3JnZXJ5IGFzIGRlc2NyaWJlZCBpbiBTZWN0 aW9uIDEwLjEyLgoKICAgVGhlIGNsaWVudCBkaXJlY3RzIHRoZSByZXNvdXJjZSBvd25lciB0byB0 aGUgY29uc3RydWN0ZWQgVVJJIHVzaW5nIGFuCiAgIEhUVFAgcmVkaXJlY3Rpb24gcmVzcG9uc2Us IG9yIGJ5IG90aGVyIG1lYW5zIGF2YWlsYWJsZSB0byBpdCB2aWEgdGhlCiAgIHVzZXItYWdlbnQu CgoKCgoKCkhhbW1lciwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgRGVjZW1iZXIgMjAsIDIwMTIg ICAgICAgICAgICAgIFtQYWdlIDMxXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAg T0F1dGggMi4wICAgICAgICAgICAgICAgICAgICAgIEp1bmUgMjAxMgoKCiAgIEZvciBleGFtcGxl LCB0aGUgY2xpZW50IGRpcmVjdHMgdGhlIHVzZXItYWdlbnQgdG8gbWFrZSB0aGUgZm9sbG93aW5n CiAgIEhUVFAgcmVxdWVzdCB1c2luZyBUTFMgKGV4dHJhIGxpbmUgYnJlYWtzIGFyZSBmb3IgZGlz cGxheSBwdXJwb3NlcwogICBvbmx5KToKCgogICAgR0VUIC9hdXRob3JpemU/cmVzcG9uc2VfdHlw ZT10b2tlbiZjbGllbnRfaWQ9czZCaGRSa3F0MyZzdGF0ZT14eXoKICAgICAgICAmcmVkaXJlY3Rf dXJpPWh0dHBzJTNBJTJGJTJGY2xpZW50JTJFZXhhbXBsZSUyRWNvbSUyRmNiIEhUVFAvMS4xCiAg ICBIb3N0OiBzZXJ2ZXIuZXhhbXBsZS5jb20KCgogICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIg dmFsaWRhdGVzIHRoZSByZXF1ZXN0IHRvIGVuc3VyZSBhbGwgcmVxdWlyZWQKICAgcGFyYW1ldGVy cyBhcmUgcHJlc2VudCBhbmQgdmFsaWQuICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVTVAog ICB2ZXJpZnkgdGhhdCB0aGUgcmVkaXJlY3Rpb24gVVJJIHRvIHdoaWNoIGl0IHdpbGwgcmVkaXJl Y3QgdGhlIGFjY2VzcwogICB0b2tlbiBtYXRjaGVzIGEgcmVkaXJlY3Rpb24gVVJJIHJlZ2lzdGVy ZWQgYnkgdGhlIGNsaWVudCBhcyBkZXNjcmliZWQKICAgaW4gU2VjdGlvbiAzLjEuMi4KCiAgIElm IHRoZSByZXF1ZXN0IGlzIHZhbGlkLCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYXV0aGVudGlj YXRlcyB0aGUKICAgcmVzb3VyY2Ugb3duZXIgYW5kIG9idGFpbnMgYW4gYXV0aG9yaXphdGlvbiBk ZWNpc2lvbiAoYnkgYXNraW5nIHRoZQogICByZXNvdXJjZSBvd25lciBvciBieSBlc3RhYmxpc2hp bmcgYXBwcm92YWwgdmlhIG90aGVyIG1lYW5zKS4KCiAgIFdoZW4gYSBkZWNpc2lvbiBpcyBlc3Rh Ymxpc2hlZCwgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGRpcmVjdHMgdGhlCiAgIHVzZXItYWdl bnQgdG8gdGhlIHByb3ZpZGVkIGNsaWVudCByZWRpcmVjdGlvbiBVUkkgdXNpbmcgYW4gSFRUUAog ICByZWRpcmVjdGlvbiByZXNwb25zZSwgb3IgYnkgb3RoZXIgbWVhbnMgYXZhaWxhYmxlIHRvIGl0 IHZpYSB0aGUgdXNlci0KICAgYWdlbnQuCgo0LjIuMi4gIEFjY2VzcyBUb2tlbiBSZXNwb25zZQoK ICAgSWYgdGhlIHJlc291cmNlIG93bmVyIGdyYW50cyB0aGUgYWNjZXNzIHJlcXVlc3QsIHRoZSBh dXRob3JpemF0aW9uCiAgIHNlcnZlciBpc3N1ZXMgYW4gYWNjZXNzIHRva2VuIGFuZCBkZWxpdmVy cyBpdCB0byB0aGUgY2xpZW50IGJ5IGFkZGluZwogICB0aGUgZm9sbG93aW5nIHBhcmFtZXRlcnMg dG8gdGhlIGZyYWdtZW50IGNvbXBvbmVudCBvZiB0aGUgcmVkaXJlY3Rpb24KICAgVVJJIHVzaW5n IHRoZSAiYXBwbGljYXRpb24veC13d3ctZm9ybS11cmxlbmNvZGVkIiBmb3JtYXQ6CgogICBhY2Nl c3NfdG9rZW4KICAgICAgICAgUkVRVUlSRUQuICBUaGUgYWNjZXNzIHRva2VuIGlzc3VlZCBieSB0 aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIuCiAgIHRva2VuX3R5cGUKICAgICAgICAgUkVRVUlSRUQu ICBUaGUgdHlwZSBvZiB0aGUgdG9rZW4gaXNzdWVkIGFzIGRlc2NyaWJlZCBpbgogICAgICAgICBT ZWN0aW9uIDcuMS4gIFZhbHVlIGlzIGNhc2UgaW5zZW5zaXRpdmUuCiAgIGV4cGlyZXNfaW4KICAg ICAgICAgUkVDT01NRU5ERUQuICBUaGUgbGlmZXRpbWUgaW4gc2Vjb25kcyBvZiB0aGUgYWNjZXNz IHRva2VuLiAgRm9yCiAgICAgICAgIGV4YW1wbGUsIHRoZSB2YWx1ZSAiMzYwMCIgZGVub3RlcyB0 aGF0IHRoZSBhY2Nlc3MgdG9rZW4gd2lsbAogICAgICAgICBleHBpcmUgaW4gb25lIGhvdXIgZnJv bSB0aGUgdGltZSB0aGUgcmVzcG9uc2Ugd2FzIGdlbmVyYXRlZC4KICAgICAgICAgSWYgb21pdHRl ZCwgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIFNIT1VMRCBwcm92aWRlIHRoZQogICAgICAgICBl eHBpcmF0aW9uIHRpbWUgdmlhIG90aGVyIG1lYW5zIG9yIGRvY3VtZW50IHRoZSBkZWZhdWx0IHZh bHVlLgogICBzY29wZQogICAgICAgICBPUFRJT05BTCwgaWYgaWRlbnRpY2FsIHRvIHRoZSBzY29w ZSByZXF1ZXN0ZWQgYnkgdGhlIGNsaWVudCwKICAgICAgICAgb3RoZXJ3aXNlIFJFUVVJUkVELiAg VGhlIHNjb3BlIG9mIHRoZSBhY2Nlc3MgdG9rZW4gYXMgZGVzY3JpYmVkCiAgICAgICAgIGJ5IFNl Y3Rpb24gMy4zLgoKCgoKSGFtbWVyLCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBEZWNlbWJlciAy MCwgMjAxMiAgICAgICAgICAgICAgW1BhZ2UgMzJdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAg ICAgICAgICBPQXV0aCAyLjAgICAgICAgICAgICAgICAgICAgICAgSnVuZSAyMDEyCgoKICAgc3Rh dGUKICAgICAgICAgUkVRVUlSRUQgaWYgdGhlICJzdGF0ZSIgcGFyYW1ldGVyIHdhcyBwcmVzZW50 IGluIHRoZSBjbGllbnQKICAgICAgICAgYXV0aG9yaXphdGlvbiByZXF1ZXN0LiAgVGhlIGV4YWN0 IHZhbHVlIHJlY2VpdmVkIGZyb20gdGhlCiAgICAgICAgIGNsaWVudC4KCiAgIFRoZSBhdXRob3Jp emF0aW9uIHNlcnZlciBNVVNUIE5PVCBpc3N1ZSBhIHJlZnJlc2ggdG9rZW4uCgogICBGb3IgZXhh bXBsZSwgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHJlZGlyZWN0cyB0aGUgdXNlci1hZ2VudCBi eQogICBzZW5kaW5nIHRoZSBmb2xsb3dpbmcgSFRUUCByZXNwb25zZSAoVVJJIGV4dHJhIGxpbmUg YnJlYWtzIGFyZSBmb3IKICAgZGlzcGxheSBwdXJwb3NlcyBvbmx5KToKCgogICAgIEhUVFAvMS4x IDMwMiBGb3VuZAogICAgIExvY2F0aW9uOiBodHRwOi8vZXhhbXBsZS5jb20vY2IjYWNjZXNzX3Rv a2VuPTJZb3RuRlpGRWpyMXpDc2ljTVdwQUEKICAgICAgICAgICAgICAgJnN0YXRlPXh5eiZ0b2tl bl90eXBlPWV4YW1wbGUmZXhwaXJlc19pbj0zNjAwCgoKICAgRGV2ZWxvcGVycyBzaG91bGQgbm90 ZSB0aGF0IHNvbWUgdXNlci1hZ2VudHMgZG8gbm90IHN1cHBvcnQgdGhlCiAgIGluY2x1c2lvbiBv ZiBhIGZyYWdtZW50IGNvbXBvbmVudCBpbiB0aGUgSFRUUCAiTG9jYXRpb24iIHJlc3BvbnNlCiAg IGhlYWRlciBmaWVsZC4gIFN1Y2ggY2xpZW50cyB3aWxsIHJlcXVpcmUgdXNpbmcgb3RoZXIgbWV0 aG9kcyBmb3IKICAgcmVkaXJlY3RpbmcgdGhlIGNsaWVudCB0aGFuIGEgM3h4IHJlZGlyZWN0aW9u IHJlc3BvbnNlLiAgRm9yIGV4YW1wbGUsCiAgIHJldHVybmluZyBhbiBIVE1MIHBhZ2Ugd2hpY2gg aW5jbHVkZXMgYSAnY29udGludWUnIGJ1dHRvbiB3aXRoIGFuCiAgIGFjdGlvbiBsaW5rZWQgdG8g dGhlIHJlZGlyZWN0aW9uIFVSSS4KCiAgIFRoZSBjbGllbnQgTVVTVCBpZ25vcmUgdW5yZWNvZ25p emVkIHJlc3BvbnNlIHBhcmFtZXRlcnMuICBUaGUgYWNjZXNzCiAgIHRva2VuIHN0cmluZyBzaXpl IGlzIGxlZnQgdW5kZWZpbmVkIGJ5IHRoaXMgc3BlY2lmaWNhdGlvbi4gIFRoZQogICBjbGllbnQg c2hvdWxkIGF2b2lkIG1ha2luZyBhc3N1bXB0aW9ucyBhYm91dCB2YWx1ZSBzaXplcy4gIFRoZQog ICBhdXRob3JpemF0aW9uIHNlcnZlciBTSE9VTEQgZG9jdW1lbnQgdGhlIHNpemUgb2YgYW55IHZh bHVlIGl0IGlzc3Vlcy4KCjQuMi4yLjEuICBFcnJvciBSZXNwb25zZQoKICAgSWYgdGhlIHJlcXVl c3QgZmFpbHMgZHVlIHRvIGEgbWlzc2luZywgaW52YWxpZCwgb3IgbWlzbWF0Y2hpbmcKICAgcmVk aXJlY3Rpb24gVVJJLCBvciBpZiB0aGUgY2xpZW50IGlkZW50aWZpZXIgaXMgbWlzc2luZyBvciBp bnZhbGlkLAogICB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgU0hPVUxEIGluZm9ybSB0aGUgcmVz b3VyY2Ugb3duZXIgb2YgdGhlCiAgIGVycm9yLCBhbmQgTVVTVCBOT1QgYXV0b21hdGljYWxseSBy ZWRpcmVjdCB0aGUgdXNlci1hZ2VudCB0byB0aGUKICAgaW52YWxpZCByZWRpcmVjdGlvbiBVUkku CgogICBJZiB0aGUgcmVzb3VyY2Ugb3duZXIgZGVuaWVzIHRoZSBhY2Nlc3MgcmVxdWVzdCBvciBp ZiB0aGUgcmVxdWVzdAogICBmYWlscyBmb3IgcmVhc29ucyBvdGhlciB0aGFuIGEgbWlzc2luZyBv ciBpbnZhbGlkIHJlZGlyZWN0aW9uIFVSSSwKICAgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGlu Zm9ybXMgdGhlIGNsaWVudCBieSBhZGRpbmcgdGhlIGZvbGxvd2luZwogICBwYXJhbWV0ZXJzIHRv IHRoZSBmcmFnbWVudCBjb21wb25lbnQgb2YgdGhlIHJlZGlyZWN0aW9uIFVSSSB1c2luZyB0aGUK ICAgImFwcGxpY2F0aW9uL3gtd3d3LWZvcm0tdXJsZW5jb2RlZCIgZm9ybWF0OgoKICAgZXJyb3IK ICAgICAgICAgUkVRVUlSRUQuICBBIHNpbmdsZSBBU0NJSSBbVVNBU0NJSV0gZXJyb3IgY29kZSBm cm9tIHRoZQogICAgICAgICBmb2xsb3dpbmc6CgoKCgoKSGFtbWVyLCBldCBhbC4gICAgICAgICAg RXhwaXJlcyBEZWNlbWJlciAyMCwgMjAxMiAgICAgICAgICAgICAgW1BhZ2UgMzNdCgwKSW50ZXJu ZXQtRHJhZnQgICAgICAgICAgICAgICAgICBPQXV0aCAyLjAgICAgICAgICAgICAgICAgICAgICAg SnVuZSAyMDEyCgoKICAgICAgICAgaW52YWxpZF9yZXF1ZXN0CiAgICAgICAgICAgICAgIFRoZSBy ZXF1ZXN0IGlzIG1pc3NpbmcgYSByZXF1aXJlZCBwYXJhbWV0ZXIsIGluY2x1ZGVzIGFuCiAgICAg ICAgICAgICAgIGludmFsaWQgcGFyYW1ldGVyIHZhbHVlLCBpbmNsdWRlcyBhIHBhcmFtZXRlciBt b3JlIHRoYW4KICAgICAgICAgICAgICAgb25jZSwgb3IgaXMgb3RoZXJ3aXNlIG1hbGZvcm1lZC4K ICAgICAgICAgdW5hdXRob3JpemVkX2NsaWVudAogICAgICAgICAgICAgICBUaGUgY2xpZW50IGlz IG5vdCBhdXRob3JpemVkIHRvIHJlcXVlc3QgYW4gYWNjZXNzIHRva2VuCiAgICAgICAgICAgICAg IHVzaW5nIHRoaXMgbWV0aG9kLgogICAgICAgICBhY2Nlc3NfZGVuaWVkCiAgICAgICAgICAgICAg IFRoZSByZXNvdXJjZSBvd25lciBvciBhdXRob3JpemF0aW9uIHNlcnZlciBkZW5pZWQgdGhlCiAg ICAgICAgICAgICAgIHJlcXVlc3QuCiAgICAgICAgIHVuc3VwcG9ydGVkX3Jlc3BvbnNlX3R5cGUK ICAgICAgICAgICAgICAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGRvZXMgbm90IHN1cHBvcnQg b2J0YWluaW5nIGFuCiAgICAgICAgICAgICAgIGFjY2VzcyB0b2tlbiB1c2luZyB0aGlzIG1ldGhv ZC4KICAgICAgICAgaW52YWxpZF9zY29wZQogICAgICAgICAgICAgICBUaGUgcmVxdWVzdGVkIHNj b3BlIGlzIGludmFsaWQsIHVua25vd24sIG9yIG1hbGZvcm1lZC4KICAgICAgICAgc2VydmVyX2Vy cm9yCiAgICAgICAgICAgICAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBlbmNvdW50ZXJlZCBh biB1bmV4cGVjdGVkCiAgICAgICAgICAgICAgIGNvbmRpdGlvbiB3aGljaCBwcmV2ZW50ZWQgaXQg ZnJvbSBmdWxmaWxsaW5nIHRoZSByZXF1ZXN0LgogICAgICAgICB0ZW1wb3JhcmlseV91bmF2YWls YWJsZQogICAgICAgICAgICAgICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgaXMgY3VycmVudGx5 IHVuYWJsZSB0byBoYW5kbGUKICAgICAgICAgICAgICAgdGhlIHJlcXVlc3QgZHVlIHRvIGEgdGVt cG9yYXJ5IG92ZXJsb2FkaW5nIG9yIG1haW50ZW5hbmNlCiAgICAgICAgICAgICAgIG9mIHRoZSBz ZXJ2ZXIuCiAgICAgICAgIFZhbHVlcyBmb3IgdGhlICJlcnJvciIgcGFyYW1ldGVyIE1VU1QgTk9U IGluY2x1ZGUgY2hhcmFjdGVycwogICAgICAgICBvdXRzaWRlIHRoZSBzZXQgJXgyMC0yMSAvICV4 MjMtNUIgLyAleDVELTdFLgogICBlcnJvcl9kZXNjcmlwdGlvbgogICAgICAgICBPUFRJT05BTC4g IEEgaHVtYW4tcmVhZGFibGUgQVNDSUkgW1VTQVNDSUldIHRleHQgcHJvdmlkaW5nCiAgICAgICAg IGFkZGl0aW9uYWwgaW5mb3JtYXRpb24sIHVzZWQgdG8gYXNzaXN0IHRoZSBjbGllbnQgZGV2ZWxv cGVyIGluCiAgICAgICAgIHVuZGVyc3RhbmRpbmcgdGhlIGVycm9yIHRoYXQgb2NjdXJyZWQuCiAg ICAgICAgIFZhbHVlcyBmb3IgdGhlICJlcnJvcl9kZXNjcmlwdGlvbiIgcGFyYW1ldGVyIE1VU1Qg Tk9UIGluY2x1ZGUKICAgICAgICAgY2hhcmFjdGVycyBvdXRzaWRlIHRoZSBzZXQgJXgyMC0yMSAv ICV4MjMtNUIgLyAleDVELTdFLgogICBlcnJvcl91cmkKICAgICAgICAgT1BUSU9OQUwuICBBIFVS SSBpZGVudGlmeWluZyBhIGh1bWFuLXJlYWRhYmxlIHdlYiBwYWdlIHdpdGgKICAgICAgICAgaW5m b3JtYXRpb24gYWJvdXQgdGhlIGVycm9yLCB1c2VkIHRvIHByb3ZpZGUgdGhlIGNsaWVudAogICAg ICAgICBkZXZlbG9wZXIgd2l0aCBhZGRpdGlvbmFsIGluZm9ybWF0aW9uIGFib3V0IHRoZSBlcnJv ci4KICAgICAgICAgVmFsdWVzIGZvciB0aGUgImVycm9yX3VyaSIgcGFyYW1ldGVyIE1VU1QgY29u Zm9ybSB0byB0aGUgVVJJLQogICAgICAgICBSZWZlcmVuY2Ugc3ludGF4LCBhbmQgdGh1cyBNVVNU IE5PVCBpbmNsdWRlIGNoYXJhY3RlcnMgb3V0c2lkZQogICAgICAgICB0aGUgc2V0ICV4MjEgLyAl eDIzLTVCIC8gJXg1RC03RS4KICAgc3RhdGUKICAgICAgICAgUkVRVUlSRUQgaWYgYSAic3RhdGUi IHBhcmFtZXRlciB3YXMgcHJlc2VudCBpbiB0aGUgY2xpZW50CiAgICAgICAgIGF1dGhvcml6YXRp b24gcmVxdWVzdC4gIFRoZSBleGFjdCB2YWx1ZSByZWNlaXZlZCBmcm9tIHRoZQogICAgICAgICBj bGllbnQuCgogICBGb3IgZXhhbXBsZSwgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHJlZGlyZWN0 cyB0aGUgdXNlci1hZ2VudCBieQogICBzZW5kaW5nIHRoZSBmb2xsb3dpbmcgSFRUUCByZXNwb25z ZToKCgogICBIVFRQLzEuMSAzMDIgRm91bmQKICAgTG9jYXRpb246IGh0dHBzOi8vY2xpZW50LmV4 YW1wbGUuY29tL2NiI2Vycm9yPWFjY2Vzc19kZW5pZWQmc3RhdGU9eHl6CgoKCkhhbW1lciwgZXQg YWwuICAgICAgICAgIEV4cGlyZXMgRGVjZW1iZXIgMjAsIDIwMTIgICAgICAgICAgICAgIFtQYWdl IDM0XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgT0F1dGggMi4wICAgICAgICAg ICAgICAgICAgICAgIEp1bmUgMjAxMgoKCjQuMy4gIFJlc291cmNlIE93bmVyIFBhc3N3b3JkIENy ZWRlbnRpYWxzIEdyYW50CgogICBUaGUgcmVzb3VyY2Ugb3duZXIgcGFzc3dvcmQgY3JlZGVudGlh bHMgZ3JhbnQgdHlwZSBpcyBzdWl0YWJsZSBpbgogICBjYXNlcyB3aGVyZSB0aGUgcmVzb3VyY2Ug b3duZXIgaGFzIGEgdHJ1c3QgcmVsYXRpb25zaGlwIHdpdGggdGhlCiAgIGNsaWVudCwgc3VjaCBh cyB0aGUgZGV2aWNlIG9wZXJhdGluZyBzeXN0ZW0gb3IgYSBoaWdobHkgcHJpdmlsZWdlZAogICBh cHBsaWNhdGlvbi4gIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBzaG91bGQgdGFrZSBzcGVjaWFs IGNhcmUgd2hlbgogICBlbmFibGluZyB0aGlzIGdyYW50IHR5cGUsIGFuZCBvbmx5IGFsbG93IGl0 IHdoZW4gb3RoZXIgZmxvd3MgYXJlIG5vdAogICB2aWFibGUuCgogICBUaGUgZ3JhbnQgdHlwZSBp cyBzdWl0YWJsZSBmb3IgY2xpZW50cyBjYXBhYmxlIG9mIG9idGFpbmluZyB0aGUKICAgcmVzb3Vy Y2Ugb3duZXIncyBjcmVkZW50aWFscyAodXNlcm5hbWUgYW5kIHBhc3N3b3JkLCB0eXBpY2FsbHkg dXNpbmcKICAgYW4gaW50ZXJhY3RpdmUgZm9ybSkuICBJdCBpcyBhbHNvIHVzZWQgdG8gbWlncmF0 ZSBleGlzdGluZyBjbGllbnRzCiAgIHVzaW5nIGRpcmVjdCBhdXRoZW50aWNhdGlvbiBzY2hlbWVz IHN1Y2ggYXMgSFRUUCBCYXNpYyBvciBEaWdlc3QKICAgYXV0aGVudGljYXRpb24gdG8gT0F1dGgg YnkgY29udmVydGluZyB0aGUgc3RvcmVkIGNyZWRlbnRpYWxzIHRvIGFuCiAgIGFjY2VzcyB0b2tl bi4KCgogICAgICstLS0tLS0tLS0tKwogICAgIHwgUmVzb3VyY2UgfAogICAgIHwgIE93bmVyICAg fAogICAgIHwgICAgICAgICAgfAogICAgICstLS0tLS0tLS0tKwogICAgICAgICAgdgogICAgICAg ICAgfCAgICBSZXNvdXJjZSBPd25lcgogICAgICAgICAoQSkgUGFzc3dvcmQgQ3JlZGVudGlhbHMK ICAgICAgICAgIHwKICAgICAgICAgIHYKICAgICArLS0tLS0tLS0tKyAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tKwogICAgIHwgICAgICAgICB8Pi0tKEIp LS0tLSBSZXNvdXJjZSBPd25lciAtLS0tLS0tPnwgICAgICAgICAgICAgICB8CiAgICAgfCAgICAg ICAgIHwgICAgICAgICBQYXNzd29yZCBDcmVkZW50aWFscyAgICAgfCBBdXRob3JpemF0aW9uIHwK ICAgICB8IENsaWVudCAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICBT ZXJ2ZXIgICAgfAogICAgIHwgICAgICAgICB8PC0tKEMpLS0tLSBBY2Nlc3MgVG9rZW4gLS0tLS0t LS0tPHwgICAgICAgICAgICAgICB8CiAgICAgfCAgICAgICAgIHwgICAgKHcvIE9wdGlvbmFsIFJl ZnJlc2ggVG9rZW4pICAgfCAgICAgICAgICAgICAgIHwKICAgICArLS0tLS0tLS0tKyAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tKwoKCiAgICAgICAgICAg IEZpZ3VyZSA1OiBSZXNvdXJjZSBPd25lciBQYXNzd29yZCBDcmVkZW50aWFscyBGbG93CgogICBU aGUgZmxvdyBpbGx1c3RyYXRlZCBpbiBGaWd1cmUgNSBpbmNsdWRlcyB0aGUgZm9sbG93aW5nIHN0 ZXBzOgoKICAgKEEpICBUaGUgcmVzb3VyY2Ugb3duZXIgcHJvdmlkZXMgdGhlIGNsaWVudCB3aXRo IGl0cyB1c2VybmFtZSBhbmQKICAgICAgICBwYXNzd29yZC4KICAgKEIpICBUaGUgY2xpZW50IHJl cXVlc3RzIGFuIGFjY2VzcyB0b2tlbiBmcm9tIHRoZSBhdXRob3JpemF0aW9uCiAgICAgICAgc2Vy dmVyJ3MgdG9rZW4gZW5kcG9pbnQgYnkgaW5jbHVkaW5nIHRoZSBjcmVkZW50aWFscyByZWNlaXZl ZAogICAgICAgIGZyb20gdGhlIHJlc291cmNlIG93bmVyLiAgV2hlbiBtYWtpbmcgdGhlIHJlcXVl c3QsIHRoZSBjbGllbnQKICAgICAgICBhdXRoZW50aWNhdGVzIHdpdGggdGhlIGF1dGhvcml6YXRp b24gc2VydmVyLgoKCgoKCkhhbW1lciwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgRGVjZW1iZXIg MjAsIDIwMTIgICAgICAgICAgICAgIFtQYWdlIDM1XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAg ICAgICAgICAgT0F1dGggMi4wICAgICAgICAgICAgICAgICAgICAgIEp1bmUgMjAxMgoKCiAgIChD KSAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGF1dGhlbnRpY2F0ZXMgdGhlIGNsaWVudCBhbmQg dmFsaWRhdGVzCiAgICAgICAgdGhlIHJlc291cmNlIG93bmVyIGNyZWRlbnRpYWxzLCBhbmQgaWYg dmFsaWQgaXNzdWVzIGFuIGFjY2VzcwogICAgICAgIHRva2VuLgoKNC4zLjEuICBBdXRob3JpemF0 aW9uIFJlcXVlc3QgYW5kIFJlc3BvbnNlCgogICBUaGUgbWV0aG9kIHRocm91Z2ggd2hpY2ggdGhl IGNsaWVudCBvYnRhaW5zIHRoZSByZXNvdXJjZSBvd25lcgogICBjcmVkZW50aWFscyBpcyBiZXlv bmQgdGhlIHNjb3BlIG9mIHRoaXMgc3BlY2lmaWNhdGlvbi4gIFRoZSBjbGllbnQKICAgTVVTVCBk aXNjYXJkIHRoZSBjcmVkZW50aWFscyBvbmNlIGFuIGFjY2VzcyB0b2tlbiBoYXMgYmVlbiBvYnRh aW5lZC4KCjQuMy4yLiAgQWNjZXNzIFRva2VuIFJlcXVlc3QKCiAgIFRoZSBjbGllbnQgbWFrZXMg YSByZXF1ZXN0IHRvIHRoZSB0b2tlbiBlbmRwb2ludCBieSBhZGRpbmcgdGhlCiAgIGZvbGxvd2lu ZyBwYXJhbWV0ZXJzIHVzaW5nIHRoZSAiYXBwbGljYXRpb24veC13d3ctZm9ybS11cmxlbmNvZGVk IgogICBmb3JtYXQgaW4gdGhlIEhUVFAgcmVxdWVzdCBlbnRpdHktYm9keToKCiAgIGdyYW50X3R5 cGUKICAgICAgICAgUkVRVUlSRUQuICBWYWx1ZSBNVVNUIGJlIHNldCB0byAicGFzc3dvcmQiLgog ICB1c2VybmFtZQogICAgICAgICBSRVFVSVJFRC4gIFRoZSByZXNvdXJjZSBvd25lciB1c2VybmFt ZS4KICAgcGFzc3dvcmQKICAgICAgICAgUkVRVUlSRUQuICBUaGUgcmVzb3VyY2Ugb3duZXIgcGFz c3dvcmQuCiAgIHNjb3BlCiAgICAgICAgIE9QVElPTkFMLiAgVGhlIHNjb3BlIG9mIHRoZSBhY2Nl c3MgcmVxdWVzdCBhcyBkZXNjcmliZWQgYnkKICAgICAgICAgU2VjdGlvbiAzLjMuCgogICBJZiB0 aGUgY2xpZW50IHR5cGUgaXMgY29uZmlkZW50aWFsIG9yIHRoZSBjbGllbnQgd2FzIGlzc3VlZCBj bGllbnQKICAgY3JlZGVudGlhbHMgKG9yIGFzc2lnbmVkIG90aGVyIGF1dGhlbnRpY2F0aW9uIHJl cXVpcmVtZW50cyksIHRoZQogICBjbGllbnQgTVVTVCBhdXRoZW50aWNhdGUgd2l0aCB0aGUgYXV0 aG9yaXphdGlvbiBzZXJ2ZXIgYXMgZGVzY3JpYmVkCiAgIGluIFNlY3Rpb24gMy4yLjEuCgogICBG b3IgZXhhbXBsZSwgdGhlIGNsaWVudCBtYWtlcyB0aGUgZm9sbG93aW5nIEhUVFAgcmVxdWVzdCB1 c2luZwogICB0cmFuc3BvcnQtbGF5ZXIgc2VjdXJpdHkgKGV4dHJhIGxpbmUgYnJlYWtzIGFyZSBm b3IgZGlzcGxheSBwdXJwb3NlcwogICBvbmx5KToKCgogICAgIFBPU1QgL3Rva2VuIEhUVFAvMS4x CiAgICAgSG9zdDogc2VydmVyLmV4YW1wbGUuY29tCiAgICAgQXV0aG9yaXphdGlvbjogQmFzaWMg Y3paQ2FHUlNhM0YwTXpwbldERm1RbUYwTTJKVwogICAgIENvbnRlbnQtVHlwZTogYXBwbGljYXRp b24veC13d3ctZm9ybS11cmxlbmNvZGVkO2NoYXJzZXQ9VVRGLTgKCiAgICAgZ3JhbnRfdHlwZT1w YXNzd29yZCZ1c2VybmFtZT1qb2huZG9lJnBhc3N3b3JkPUEzZGRqM3cKCgogICBUaGUgYXV0aG9y aXphdGlvbiBzZXJ2ZXIgTVVTVDoKCgoKCgoKSGFtbWVyLCBldCBhbC4gICAgICAgICAgRXhwaXJl cyBEZWNlbWJlciAyMCwgMjAxMiAgICAgICAgICAgICAgW1BhZ2UgMzZdCgwKSW50ZXJuZXQtRHJh ZnQgICAgICAgICAgICAgICAgICBPQXV0aCAyLjAgICAgICAgICAgICAgICAgICAgICAgSnVuZSAy MDEyCgoKICAgbyAgcmVxdWlyZSBjbGllbnQgYXV0aGVudGljYXRpb24gZm9yIGNvbmZpZGVudGlh bCBjbGllbnRzIG9yIGZvciBhbnkKICAgICAgY2xpZW50IHRoYXQgd2FzIGlzc3VlZCBjbGllbnQg Y3JlZGVudGlhbHMgKG9yIHdpdGggb3RoZXIKICAgICAgYXV0aGVudGljYXRpb24gcmVxdWlyZW1l bnRzKSwKICAgbyAgYXV0aGVudGljYXRlIHRoZSBjbGllbnQgaWYgY2xpZW50IGF1dGhlbnRpY2F0 aW9uIGlzIGluY2x1ZGVkLCBhbmQKICAgbyAgdmFsaWRhdGUgdGhlIHJlc291cmNlIG93bmVyIHBh c3N3b3JkIGNyZWRlbnRpYWxzIHVzaW5nIGl0cwogICAgICBleGlzdGluZyBwYXNzd29yZCB2YWxp ZGF0aW9uIGFsZ29yaXRobS4KCiAgIFNpbmNlIHRoaXMgYWNjZXNzIHRva2VuIHJlcXVlc3QgdXRp bGl6ZXMgdGhlIHJlc291cmNlIG93bmVyJ3MKICAgcGFzc3dvcmQsIHRoZSBhdXRob3JpemF0aW9u IHNlcnZlciBNVVNUIHByb3RlY3QgdGhlIGVuZHBvaW50IGFnYWluc3QKICAgYnJ1dGUgZm9yY2Ug YXR0YWNrcyAoZS5nLiB1c2luZyByYXRlLWxpbWl0YXRpb24gb3IgZ2VuZXJhdGluZwogICBhbGVy dHMpLgoKNC4zLjMuICBBY2Nlc3MgVG9rZW4gUmVzcG9uc2UKCiAgIElmIHRoZSBhY2Nlc3MgdG9r ZW4gcmVxdWVzdCBpcyB2YWxpZCBhbmQgYXV0aG9yaXplZCwgdGhlCiAgIGF1dGhvcml6YXRpb24g c2VydmVyIGlzc3VlcyBhbiBhY2Nlc3MgdG9rZW4gYW5kIG9wdGlvbmFsIHJlZnJlc2gKICAgdG9r ZW4gYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gNS4xLiAgSWYgdGhlIHJlcXVlc3QgZmFpbGVkIGNs aWVudAogICBhdXRoZW50aWNhdGlvbiBvciBpcyBpbnZhbGlkLCB0aGUgYXV0aG9yaXphdGlvbiBz ZXJ2ZXIgcmV0dXJucyBhbgogICBlcnJvciByZXNwb25zZSBhcyBkZXNjcmliZWQgaW4gU2VjdGlv biA1LjIuCgogICBBbiBleGFtcGxlIHN1Y2Nlc3NmdWwgcmVzcG9uc2U6CgoKICAgICBIVFRQLzEu MSAyMDAgT0sKICAgICBDb250ZW50LVR5cGU6IGFwcGxpY2F0aW9uL2pzb247Y2hhcnNldD1VVEYt OAogICAgIENhY2hlLUNvbnRyb2w6IG5vLXN0b3JlCiAgICAgUHJhZ21hOiBuby1jYWNoZQoKICAg ICB7CiAgICAgICAiYWNjZXNzX3Rva2VuIjoiMllvdG5GWkZFanIxekNzaWNNV3BBQSIsCiAgICAg ICAidG9rZW5fdHlwZSI6ImV4YW1wbGUiLAogICAgICAgImV4cGlyZXNfaW4iOjM2MDAsCiAgICAg ICAicmVmcmVzaF90b2tlbiI6InRHenYzSk9rRjBYRzVReDJUbEtXSUEiLAogICAgICAgImV4YW1w bGVfcGFyYW1ldGVyIjoiZXhhbXBsZV92YWx1ZSIKICAgICB9CgoKNC40LiAgQ2xpZW50IENyZWRl bnRpYWxzIEdyYW50CgogICBUaGUgY2xpZW50IGNhbiByZXF1ZXN0IGFuIGFjY2VzcyB0b2tlbiB1 c2luZyBvbmx5IGl0cyBjbGllbnQKICAgY3JlZGVudGlhbHMgKG9yIG90aGVyIHN1cHBvcnRlZCBt ZWFucyBvZiBhdXRoZW50aWNhdGlvbikgd2hlbiB0aGUKICAgY2xpZW50IGlzIHJlcXVlc3Rpbmcg YWNjZXNzIHRvIHRoZSBwcm90ZWN0ZWQgcmVzb3VyY2VzIHVuZGVyIGl0cwogICBjb250cm9sLCBv ciB0aG9zZSBvZiBhbm90aGVyIHJlc291cmNlIG93bmVyIHdoaWNoIGhhcyBiZWVuIHByZXZpb3Vz bHkKICAgYXJyYW5nZWQgd2l0aCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgKHRoZSBtZXRob2Qg b2Ygd2hpY2ggaXMgYmV5b25kCiAgIHRoZSBzY29wZSBvZiB0aGlzIHNwZWNpZmljYXRpb24pLgoK ICAgVGhlIGNsaWVudCBjcmVkZW50aWFscyBncmFudCB0eXBlIE1VU1Qgb25seSBiZSB1c2VkIGJ5 IGNvbmZpZGVudGlhbAogICBjbGllbnRzLgoKCgpIYW1tZXIsIGV0IGFsLiAgICAgICAgICBFeHBp cmVzIERlY2VtYmVyIDIwLCAyMDEyICAgICAgICAgICAgICBbUGFnZSAzN10KDApJbnRlcm5ldC1E cmFmdCAgICAgICAgICAgICAgICAgIE9BdXRoIDIuMCAgICAgICAgICAgICAgICAgICAgICBKdW5l IDIwMTIKCgogICAgICstLS0tLS0tLS0rICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICstLS0tLS0tLS0tLS0tLS0rCiAgICAgfCAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgfCAgICAgICAgICAgICAgIHwKICAgICB8ICAgICAgICAgfD4tLShBKS0gQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIC0tLT58IEF1dGhvcml6YXRpb24gfAogICAgIHwgQ2xpZW50ICB8 ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgIFNlcnZlciAgICB8CiAgICAg fCAgICAgICAgIHw8LS0oQiktLS0tIEFjY2VzcyBUb2tlbiAtLS0tLS0tLS08fCAgICAgICAgICAg ICAgIHwKICAgICB8ICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8 ICAgICAgICAgICAgICAgfAogICAgICstLS0tLS0tLS0rICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0rCgoKICAgICAgICAgICAgICAgICAgICAgRmlndXJl IDY6IENsaWVudCBDcmVkZW50aWFscyBGbG93CgogICBUaGUgZmxvdyBpbGx1c3RyYXRlZCBpbiBG aWd1cmUgNiBpbmNsdWRlcyB0aGUgZm9sbG93aW5nIHN0ZXBzOgoKICAgKEEpICBUaGUgY2xpZW50 IGF1dGhlbnRpY2F0ZXMgd2l0aCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYW5kCiAgICAgICAg cmVxdWVzdHMgYW4gYWNjZXNzIHRva2VuIGZyb20gdGhlIHRva2VuIGVuZHBvaW50LgogICAoQikg IFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBhdXRoZW50aWNhdGVzIHRoZSBjbGllbnQsIGFuZCBp ZiB2YWxpZAogICAgICAgIGlzc3VlcyBhbiBhY2Nlc3MgdG9rZW4uCgo0LjQuMS4gIEF1dGhvcml6 YXRpb24gUmVxdWVzdCBhbmQgUmVzcG9uc2UKCiAgIFNpbmNlIHRoZSBjbGllbnQgYXV0aGVudGlj YXRpb24gaXMgdXNlZCBhcyB0aGUgYXV0aG9yaXphdGlvbiBncmFudCwKICAgbm8gYWRkaXRpb25h bCBhdXRob3JpemF0aW9uIHJlcXVlc3QgaXMgbmVlZGVkLgoKNC40LjIuICBBY2Nlc3MgVG9rZW4g UmVxdWVzdAoKICAgVGhlIGNsaWVudCBtYWtlcyBhIHJlcXVlc3QgdG8gdGhlIHRva2VuIGVuZHBv aW50IGJ5IGFkZGluZyB0aGUKICAgZm9sbG93aW5nIHBhcmFtZXRlcnMgdXNpbmcgdGhlICJhcHBs aWNhdGlvbi94LXd3dy1mb3JtLXVybGVuY29kZWQiCiAgIGZvcm1hdCBpbiB0aGUgSFRUUCByZXF1 ZXN0IGVudGl0eS1ib2R5OgoKICAgZ3JhbnRfdHlwZQogICAgICAgICBSRVFVSVJFRC4gIFZhbHVl IE1VU1QgYmUgc2V0IHRvICJjbGllbnRfY3JlZGVudGlhbHMiLgogICBzY29wZQogICAgICAgICBP UFRJT05BTC4gIFRoZSBzY29wZSBvZiB0aGUgYWNjZXNzIHJlcXVlc3QgYXMgZGVzY3JpYmVkIGJ5 CiAgICAgICAgIFNlY3Rpb24gMy4zLgoKICAgVGhlIGNsaWVudCBNVVNUIGF1dGhlbnRpY2F0ZSB3 aXRoIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBhcwogICBkZXNjcmliZWQgaW4gU2VjdGlvbiAz LjIuMS4KCiAgIEZvciBleGFtcGxlLCB0aGUgY2xpZW50IG1ha2VzIHRoZSBmb2xsb3dpbmcgSFRU UCByZXF1ZXN0IHVzaW5nCiAgIHRyYW5zcG9ydC1sYXllciBzZWN1cml0eSAoZXh0cmEgbGluZSBi cmVha3MgYXJlIGZvciBkaXNwbGF5IHB1cnBvc2VzCiAgIG9ubHkpOgoKCiAgICAgUE9TVCAvdG9r ZW4gSFRUUC8xLjEKICAgICBIb3N0OiBzZXJ2ZXIuZXhhbXBsZS5jb20KICAgICBBdXRob3JpemF0 aW9uOiBCYXNpYyBjelpDYUdSU2EzRjBNenBuV0RGbVFtRjBNMkpXCiAgICAgQ29udGVudC1UeXBl OiBhcHBsaWNhdGlvbi94LXd3dy1mb3JtLXVybGVuY29kZWQ7Y2hhcnNldD1VVEYtOAoKCgoKSGFt bWVyLCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBEZWNlbWJlciAyMCwgMjAxMiAgICAgICAgICAg ICAgW1BhZ2UgMzhdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICBPQXV0aCAyLjAg ICAgICAgICAgICAgICAgICAgICAgSnVuZSAyMDEyCgoKICAgICBncmFudF90eXBlPWNsaWVudF9j cmVkZW50aWFscwoKCiAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBNVVNUIGF1dGhlbnRpY2F0 ZSB0aGUgY2xpZW50LgoKNC40LjMuICBBY2Nlc3MgVG9rZW4gUmVzcG9uc2UKCiAgIElmIHRoZSBh Y2Nlc3MgdG9rZW4gcmVxdWVzdCBpcyB2YWxpZCBhbmQgYXV0aG9yaXplZCwgdGhlCiAgIGF1dGhv cml6YXRpb24gc2VydmVyIGlzc3VlcyBhbiBhY2Nlc3MgdG9rZW4gYXMgZGVzY3JpYmVkIGluCiAg IFNlY3Rpb24gNS4xLiAgQSByZWZyZXNoIHRva2VuIFNIT1VMRCBOT1QgYmUgaW5jbHVkZWQuICBJ ZiB0aGUgcmVxdWVzdAogICBmYWlsZWQgY2xpZW50IGF1dGhlbnRpY2F0aW9uIG9yIGlzIGludmFs aWQsIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlcgogICByZXR1cm5zIGFuIGVycm9yIHJlc3BvbnNl IGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDUuMi4KCiAgIEFuIGV4YW1wbGUgc3VjY2Vzc2Z1bCBy ZXNwb25zZToKCgogICAgIEhUVFAvMS4xIDIwMCBPSwogICAgIENvbnRlbnQtVHlwZTogYXBwbGlj YXRpb24vanNvbjtjaGFyc2V0PVVURi04CiAgICAgQ2FjaGUtQ29udHJvbDogbm8tc3RvcmUKICAg ICBQcmFnbWE6IG5vLWNhY2hlCgogICAgIHsKICAgICAgICJhY2Nlc3NfdG9rZW4iOiIyWW90bkZa RkVqcjF6Q3NpY01XcEFBIiwKICAgICAgICJ0b2tlbl90eXBlIjoiZXhhbXBsZSIsCiAgICAgICAi ZXhwaXJlc19pbiI6MzYwMCwKICAgICAgICJleGFtcGxlX3BhcmFtZXRlciI6ImV4YW1wbGVfdmFs dWUiCiAgICAgfQoKCjQuNS4gIEV4dGVuc2lvbiBHcmFudHMKCiAgIFRoZSBjbGllbnQgdXNlcyBh biBleHRlbnNpb24gZ3JhbnQgdHlwZSBieSBzcGVjaWZ5aW5nIHRoZSBncmFudCB0eXBlCiAgIHVz aW5nIGFuIGFic29sdXRlIFVSSSAoZGVmaW5lZCBieSB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIp IGFzIHRoZQogICB2YWx1ZSBvZiB0aGUgImdyYW50X3R5cGUiIHBhcmFtZXRlciBvZiB0aGUgdG9r ZW4gZW5kcG9pbnQsIGFuZCBieQogICBhZGRpbmcgYW55IGFkZGl0aW9uYWwgcGFyYW1ldGVycyBu ZWNlc3NhcnkuCgogICBGb3IgZXhhbXBsZSwgdG8gcmVxdWVzdCBhbiBhY2Nlc3MgdG9rZW4gdXNp bmcgYSBTQU1MIDIuMCBhc3NlcnRpb24KICAgZ3JhbnQgdHlwZSBhcyBkZWZpbmVkIGJ5IFtJLUQu aWV0Zi1vYXV0aC1zYW1sMi1iZWFyZXJdLCB0aGUgY2xpZW50CiAgIG1ha2VzIHRoZSBmb2xsb3dp bmcgSFRUUCByZXF1ZXN0IHVzaW5nIFRMUyAobGluZSBicmVha3MgYXJlIGZvcgogICBkaXNwbGF5 IHB1cnBvc2VzIG9ubHkpOgoKCiAgICAgUE9TVCAvdG9rZW4gSFRUUC8xLjEKICAgICBIb3N0OiBz ZXJ2ZXIuZXhhbXBsZS5jb20KICAgICBDb250ZW50LVR5cGU6IGFwcGxpY2F0aW9uL3gtd3d3LWZv cm0tdXJsZW5jb2RlZDtjaGFyc2V0PVVURi04CgogICAgIGdyYW50X3R5cGU9dXJuJTNBaWV0ZiUz QXBhcmFtcyUzQW9hdXRoJTNBZ3JhbnQtdHlwZSUzQXNhbWwyLQogICAgIGJlYXJlciZhc3NlcnRp b249UEVGemMyVnlkR2x2YmlCSmMzTjFaVWx1YzNSaGJuUTlJakl3TVRFdE1EVQoKCgpIYW1tZXIs IGV0IGFsLiAgICAgICAgICBFeHBpcmVzIERlY2VtYmVyIDIwLCAyMDEyICAgICAgICAgICAgICBb UGFnZSAzOV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgIE9BdXRoIDIuMCAgICAg ICAgICAgICAgICAgICAgICBKdW5lIDIwMTIKCgogICAgIFsuLi5vbWl0dGVkIGZvciBicmV2aXR5 Li4uXWFHNVRkR0YwWlcxbGJuUS1QQzlCYzNObGNuUnBiMjQtCgoKICAgSWYgdGhlIGFjY2VzcyB0 b2tlbiByZXF1ZXN0IGlzIHZhbGlkIGFuZCBhdXRob3JpemVkLCB0aGUKICAgYXV0aG9yaXphdGlv biBzZXJ2ZXIgaXNzdWVzIGFuIGFjY2VzcyB0b2tlbiBhbmQgb3B0aW9uYWwgcmVmcmVzaAogICB0 b2tlbiBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiA1LjEuICBJZiB0aGUgcmVxdWVzdCBmYWlsZWQg Y2xpZW50CiAgIGF1dGhlbnRpY2F0aW9uIG9yIGlzIGludmFsaWQsIHRoZSBhdXRob3JpemF0aW9u IHNlcnZlciByZXR1cm5zIGFuCiAgIGVycm9yIHJlc3BvbnNlIGFzIGRlc2NyaWJlZCBpbiBTZWN0 aW9uIDUuMi4KCgo1LiAgSXNzdWluZyBhbiBBY2Nlc3MgVG9rZW4KCiAgIElmIHRoZSBhY2Nlc3Mg dG9rZW4gcmVxdWVzdCBpcyB2YWxpZCBhbmQgYXV0aG9yaXplZCwgdGhlCiAgIGF1dGhvcml6YXRp b24gc2VydmVyIGlzc3VlcyBhbiBhY2Nlc3MgdG9rZW4gYW5kIG9wdGlvbmFsIHJlZnJlc2gKICAg dG9rZW4gYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gNS4xLiAgSWYgdGhlIHJlcXVlc3QgZmFpbGVk IGNsaWVudAogICBhdXRoZW50aWNhdGlvbiBvciBpcyBpbnZhbGlkLCB0aGUgYXV0aG9yaXphdGlv biBzZXJ2ZXIgcmV0dXJucyBhbgogICBlcnJvciByZXNwb25zZSBhcyBkZXNjcmliZWQgaW4gU2Vj dGlvbiA1LjIuCgo1LjEuICBTdWNjZXNzZnVsIFJlc3BvbnNlCgogICBUaGUgYXV0aG9yaXphdGlv biBzZXJ2ZXIgaXNzdWVzIGFuIGFjY2VzcyB0b2tlbiBhbmQgb3B0aW9uYWwgcmVmcmVzaAogICB0 b2tlbiwgYW5kIGNvbnN0cnVjdHMgdGhlIHJlc3BvbnNlIGJ5IGFkZGluZyB0aGUgZm9sbG93aW5n IHBhcmFtZXRlcnMKICAgdG8gdGhlIGVudGl0eSBib2R5IG9mIHRoZSBIVFRQIHJlc3BvbnNlIHdp dGggYSAyMDAgKE9LKSBzdGF0dXMgY29kZToKCiAgIGFjY2Vzc190b2tlbgogICAgICAgICBSRVFV SVJFRC4gIFRoZSBhY2Nlc3MgdG9rZW4gaXNzdWVkIGJ5IHRoZSBhdXRob3JpemF0aW9uIHNlcnZl ci4KICAgdG9rZW5fdHlwZQogICAgICAgICBSRVFVSVJFRC4gIFRoZSB0eXBlIG9mIHRoZSB0b2tl biBpc3N1ZWQgYXMgZGVzY3JpYmVkIGluCiAgICAgICAgIFNlY3Rpb24gNy4xLiAgVmFsdWUgaXMg Y2FzZSBpbnNlbnNpdGl2ZS4KICAgZXhwaXJlc19pbgogICAgICAgICBSRUNPTU1FTkRFRC4gIFRo ZSBsaWZldGltZSBpbiBzZWNvbmRzIG9mIHRoZSBhY2Nlc3MgdG9rZW4uICBGb3IKICAgICAgICAg ZXhhbXBsZSwgdGhlIHZhbHVlICIzNjAwIiBkZW5vdGVzIHRoYXQgdGhlIGFjY2VzcyB0b2tlbiB3 aWxsCiAgICAgICAgIGV4cGlyZSBpbiBvbmUgaG91ciBmcm9tIHRoZSB0aW1lIHRoZSByZXNwb25z ZSB3YXMgZ2VuZXJhdGVkLgogICAgICAgICBJZiBvbWl0dGVkLCB0aGUgYXV0aG9yaXphdGlvbiBz ZXJ2ZXIgU0hPVUxEIHByb3ZpZGUgdGhlCiAgICAgICAgIGV4cGlyYXRpb24gdGltZSB2aWEgb3Ro ZXIgbWVhbnMgb3IgZG9jdW1lbnQgdGhlIGRlZmF1bHQgdmFsdWUuCiAgIHJlZnJlc2hfdG9rZW4K ICAgICAgICAgT1BUSU9OQUwuICBUaGUgcmVmcmVzaCB0b2tlbiB3aGljaCBjYW4gYmUgdXNlZCB0 byBvYnRhaW4gbmV3CiAgICAgICAgIGFjY2VzcyB0b2tlbnMgdXNpbmcgdGhlIHNhbWUgYXV0aG9y aXphdGlvbiBncmFudCBhcyBkZXNjcmliZWQKICAgICAgICAgaW4gU2VjdGlvbiA2LgogICBzY29w ZQogICAgICAgICBPUFRJT05BTCwgaWYgaWRlbnRpY2FsIHRvIHRoZSBzY29wZSByZXF1ZXN0ZWQg YnkgdGhlIGNsaWVudCwKICAgICAgICAgb3RoZXJ3aXNlIFJFUVVJUkVELiAgVGhlIHNjb3BlIG9m IHRoZSBhY2Nlc3MgdG9rZW4gYXMgZGVzY3JpYmVkCiAgICAgICAgIGJ5IFNlY3Rpb24gMy4zLgoK ICAgVGhlIHBhcmFtZXRlcnMgYXJlIGluY2x1ZGVkIGluIHRoZSBlbnRpdHkgYm9keSBvZiB0aGUg SFRUUCByZXNwb25zZQogICB1c2luZyB0aGUgImFwcGxpY2F0aW9uL2pzb24iIG1lZGlhIHR5cGUg YXMgZGVmaW5lZCBieSBbUkZDNDYyN10uICBUaGUKICAgcGFyYW1ldGVycyBhcmUgc2VyaWFsaXpl ZCBpbnRvIGEgSlNPTiBzdHJ1Y3R1cmUgYnkgYWRkaW5nIGVhY2gKICAgcGFyYW1ldGVyIGF0IHRo ZSBoaWdoZXN0IHN0cnVjdHVyZSBsZXZlbC4gIFBhcmFtZXRlciBuYW1lcyBhbmQgc3RyaW5nCgoK CkhhbW1lciwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgRGVjZW1iZXIgMjAsIDIwMTIgICAgICAg ICAgICAgIFtQYWdlIDQwXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgT0F1dGgg Mi4wICAgICAgICAgICAgICAgICAgICAgIEp1bmUgMjAxMgoKCiAgIHZhbHVlcyBhcmUgaW5jbHVk ZWQgYXMgSlNPTiBzdHJpbmdzLiAgTnVtZXJpY2FsIHZhbHVlcyBhcmUgaW5jbHVkZWQKICAgYXMg SlNPTiBudW1iZXJzLiAgVGhlIG9yZGVyIG9mIHBhcmFtZXRlcnMgZG9lcyBub3QgbWF0dGVyIGFu ZCBjYW4KICAgdmFyeS4KCiAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBNVVNUIGluY2x1ZGUg dGhlIEhUVFAgIkNhY2hlLUNvbnRyb2wiCiAgIHJlc3BvbnNlIGhlYWRlciBmaWVsZCBbUkZDMjYx Nl0gd2l0aCBhIHZhbHVlIG9mICJuby1zdG9yZSIgaW4gYW55CiAgIHJlc3BvbnNlIGNvbnRhaW5p bmcgdG9rZW5zLCBjcmVkZW50aWFscywgb3Igb3RoZXIgc2Vuc2l0aXZlCiAgIGluZm9ybWF0aW9u LCBhcyB3ZWxsIGFzIHRoZSAiUHJhZ21hIiByZXNwb25zZSBoZWFkZXIgZmllbGQgW1JGQzI2MTZd CiAgIHdpdGggYSB2YWx1ZSBvZiAibm8tY2FjaGUiLgoKICAgRm9yIGV4YW1wbGU6CgoKICAgICBI VFRQLzEuMSAyMDAgT0sKICAgICBDb250ZW50LVR5cGU6IGFwcGxpY2F0aW9uL2pzb247Y2hhcnNl dD1VVEYtOAogICAgIENhY2hlLUNvbnRyb2w6IG5vLXN0b3JlCiAgICAgUHJhZ21hOiBuby1jYWNo ZQoKICAgICB7CiAgICAgICAiYWNjZXNzX3Rva2VuIjoiMllvdG5GWkZFanIxekNzaWNNV3BBQSIs CiAgICAgICAidG9rZW5fdHlwZSI6ImV4YW1wbGUiLAogICAgICAgImV4cGlyZXNfaW4iOjM2MDAs CiAgICAgICAicmVmcmVzaF90b2tlbiI6InRHenYzSk9rRjBYRzVReDJUbEtXSUEiLAogICAgICAg ImV4YW1wbGVfcGFyYW1ldGVyIjoiZXhhbXBsZV92YWx1ZSIKICAgICB9CgoKICAgVGhlIGNsaWVu dCBNVVNUIGlnbm9yZSB1bnJlY29nbml6ZWQgdmFsdWUgbmFtZXMgaW4gdGhlIHJlc3BvbnNlLiAg VGhlCiAgIHNpemVzIG9mIHRva2VucyBhbmQgb3RoZXIgdmFsdWVzIHJlY2VpdmVkIGZyb20gdGhl IGF1dGhvcml6YXRpb24KICAgc2VydmVyIGFyZSBsZWZ0IHVuZGVmaW5lZC4gIFRoZSBjbGllbnQg c2hvdWxkIGF2b2lkIG1ha2luZwogICBhc3N1bXB0aW9ucyBhYm91dCB2YWx1ZSBzaXplcy4gIFRo ZSBhdXRob3JpemF0aW9uIHNlcnZlciBTSE9VTEQKICAgZG9jdW1lbnQgdGhlIHNpemUgb2YgYW55 IHZhbHVlIGl0IGlzc3Vlcy4KCjUuMi4gIEVycm9yIFJlc3BvbnNlCgogICBUaGUgYXV0aG9yaXph dGlvbiBzZXJ2ZXIgcmVzcG9uZHMgd2l0aCBhbiBIVFRQIDQwMCAoQmFkIFJlcXVlc3QpCiAgIHN0 YXR1cyBjb2RlICh1bmxlc3Mgc3BlY2lmaWVkIG90aGVyd2lzZSkgYW5kIGluY2x1ZGVzIHRoZSBm b2xsb3dpbmcKICAgcGFyYW1ldGVycyB3aXRoIHRoZSByZXNwb25zZToKCiAgIGVycm9yCiAgICAg ICAgIFJFUVVJUkVELiAgQSBzaW5nbGUgQVNDSUkgW1VTQVNDSUldIGVycm9yIGNvZGUgZnJvbSB0 aGUKICAgICAgICAgZm9sbG93aW5nOgogICAgICAgICBpbnZhbGlkX3JlcXVlc3QKICAgICAgICAg ICAgICAgVGhlIHJlcXVlc3QgaXMgbWlzc2luZyBhIHJlcXVpcmVkIHBhcmFtZXRlciwgaW5jbHVk ZXMgYW4KICAgICAgICAgICAgICAgdW5zdXBwb3J0ZWQgcGFyYW1ldGVyIHZhbHVlIChvdGhlciB0 aGFuIGdyYW50IHR5cGUpLAogICAgICAgICAgICAgICByZXBlYXRzIGEgcGFyYW1ldGVyLCBpbmNs dWRlcyBtdWx0aXBsZSBjcmVkZW50aWFscywKICAgICAgICAgICAgICAgdXRpbGl6ZXMgbW9yZSB0 aGFuIG9uZSBtZWNoYW5pc20gZm9yIGF1dGhlbnRpY2F0aW5nIHRoZQogICAgICAgICAgICAgICBj bGllbnQsIG9yIGlzIG90aGVyd2lzZSBtYWxmb3JtZWQuCgoKCkhhbW1lciwgZXQgYWwuICAgICAg ICAgIEV4cGlyZXMgRGVjZW1iZXIgMjAsIDIwMTIgICAgICAgICAgICAgIFtQYWdlIDQxXQoMCklu dGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgT0F1dGggMi4wICAgICAgICAgICAgICAgICAg ICAgIEp1bmUgMjAxMgoKCiAgICAgICAgIGludmFsaWRfY2xpZW50CiAgICAgICAgICAgICAgIENs aWVudCBhdXRoZW50aWNhdGlvbiBmYWlsZWQgKGUuZy4gdW5rbm93biBjbGllbnQsIG5vCiAgICAg ICAgICAgICAgIGNsaWVudCBhdXRoZW50aWNhdGlvbiBpbmNsdWRlZCwgb3IgdW5zdXBwb3J0ZWQK ICAgICAgICAgICAgICAgYXV0aGVudGljYXRpb24gbWV0aG9kKS4gIFRoZSBhdXRob3JpemF0aW9u IHNlcnZlciBNQVkKICAgICAgICAgICAgICAgcmV0dXJuIGFuIEhUVFAgNDAxIChVbmF1dGhvcml6 ZWQpIHN0YXR1cyBjb2RlIHRvIGluZGljYXRlCiAgICAgICAgICAgICAgIHdoaWNoIEhUVFAgYXV0 aGVudGljYXRpb24gc2NoZW1lcyBhcmUgc3VwcG9ydGVkLiAgSWYgdGhlCiAgICAgICAgICAgICAg IGNsaWVudCBhdHRlbXB0ZWQgdG8gYXV0aGVudGljYXRlIHZpYSB0aGUgIkF1dGhvcml6YXRpb24i CiAgICAgICAgICAgICAgIHJlcXVlc3QgaGVhZGVyIGZpZWxkLCB0aGUgYXV0aG9yaXphdGlvbiBz ZXJ2ZXIgTVVTVAogICAgICAgICAgICAgICByZXNwb25kIHdpdGggYW4gSFRUUCA0MDEgKFVuYXV0 aG9yaXplZCkgc3RhdHVzIGNvZGUsIGFuZAogICAgICAgICAgICAgICBpbmNsdWRlIHRoZSAiV1dX LUF1dGhlbnRpY2F0ZSIgcmVzcG9uc2UgaGVhZGVyIGZpZWxkCiAgICAgICAgICAgICAgIG1hdGNo aW5nIHRoZSBhdXRoZW50aWNhdGlvbiBzY2hlbWUgdXNlZCBieSB0aGUgY2xpZW50LgogICAgICAg ICBpbnZhbGlkX2dyYW50CiAgICAgICAgICAgICAgIFRoZSBwcm92aWRlZCBhdXRob3JpemF0aW9u IGdyYW50IChlLmcuIGF1dGhvcml6YXRpb24KICAgICAgICAgICAgICAgY29kZSwgcmVzb3VyY2Ug b3duZXIgY3JlZGVudGlhbHMpIG9yIHJlZnJlc2ggdG9rZW4gaXMKICAgICAgICAgICAgICAgaW52 YWxpZCwgZXhwaXJlZCwgcmV2b2tlZCwgZG9lcyBub3QgbWF0Y2ggdGhlIHJlZGlyZWN0aW9uCiAg ICAgICAgICAgICAgIFVSSSB1c2VkIGluIHRoZSBhdXRob3JpemF0aW9uIHJlcXVlc3QsIG9yIHdh cyBpc3N1ZWQgdG8KICAgICAgICAgICAgICAgYW5vdGhlciBjbGllbnQuCiAgICAgICAgIHVuYXV0 aG9yaXplZF9jbGllbnQKICAgICAgICAgICAgICAgVGhlIGF1dGhlbnRpY2F0ZWQgY2xpZW50IGlz IG5vdCBhdXRob3JpemVkIHRvIHVzZSB0aGlzCiAgICAgICAgICAgICAgIGF1dGhvcml6YXRpb24g Z3JhbnQgdHlwZS4KICAgICAgICAgdW5zdXBwb3J0ZWRfZ3JhbnRfdHlwZQogICAgICAgICAgICAg ICBUaGUgYXV0aG9yaXphdGlvbiBncmFudCB0eXBlIGlzIG5vdCBzdXBwb3J0ZWQgYnkgdGhlCiAg ICAgICAgICAgICAgIGF1dGhvcml6YXRpb24gc2VydmVyLgogICAgICAgICBpbnZhbGlkX3Njb3Bl CiAgICAgICAgICAgICAgIFRoZSByZXF1ZXN0ZWQgc2NvcGUgaXMgaW52YWxpZCwgdW5rbm93biwg bWFsZm9ybWVkLCBvcgogICAgICAgICAgICAgICBleGNlZWRzIHRoZSBzY29wZSBncmFudGVkIGJ5 IHRoZSByZXNvdXJjZSBvd25lci4KICAgICAgICAgVmFsdWVzIGZvciB0aGUgImVycm9yIiBwYXJh bWV0ZXIgTVVTVCBOT1QgaW5jbHVkZSBjaGFyYWN0ZXJzCiAgICAgICAgIG91dHNpZGUgdGhlIHNl dCAleDIwLTIxIC8gJXgyMy01QiAvICV4NUQtN0UuCiAgIGVycm9yX2Rlc2NyaXB0aW9uCiAgICAg ICAgIE9QVElPTkFMLiAgQSBodW1hbi1yZWFkYWJsZSBBU0NJSSBbVVNBU0NJSV0gdGV4dCBwcm92 aWRpbmcKICAgICAgICAgYWRkaXRpb25hbCBpbmZvcm1hdGlvbiwgdXNlZCB0byBhc3Npc3QgdGhl IGNsaWVudCBkZXZlbG9wZXIgaW4KICAgICAgICAgdW5kZXJzdGFuZGluZyB0aGUgZXJyb3IgdGhh dCBvY2N1cnJlZC4KICAgICAgICAgVmFsdWVzIGZvciB0aGUgImVycm9yX2Rlc2NyaXB0aW9uIiBw YXJhbWV0ZXIgTVVTVCBOT1QgaW5jbHVkZQogICAgICAgICBjaGFyYWN0ZXJzIG91dHNpZGUgdGhl IHNldCAleDIwLTIxIC8gJXgyMy01QiAvICV4NUQtN0UuCiAgIGVycm9yX3VyaQogICAgICAgICBP UFRJT05BTC4gIEEgVVJJIGlkZW50aWZ5aW5nIGEgaHVtYW4tcmVhZGFibGUgd2ViIHBhZ2Ugd2l0 aAogICAgICAgICBpbmZvcm1hdGlvbiBhYm91dCB0aGUgZXJyb3IsIHVzZWQgdG8gcHJvdmlkZSB0 aGUgY2xpZW50CiAgICAgICAgIGRldmVsb3BlciB3aXRoIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24g YWJvdXQgdGhlIGVycm9yLgogICAgICAgICBWYWx1ZXMgZm9yIHRoZSAiZXJyb3JfdXJpIiBwYXJh bWV0ZXIgTVVTVCBjb25mb3JtIHRvIHRoZSBVUkktCiAgICAgICAgIFJlZmVyZW5jZSBzeW50YXgs IGFuZCB0aHVzIE1VU1QgTk9UIGluY2x1ZGUgY2hhcmFjdGVycyBvdXRzaWRlCiAgICAgICAgIHRo ZSBzZXQgJXgyMSAvICV4MjMtNUIgLyAleDVELTdFLgoKICAgVGhlIHBhcmFtZXRlcnMgYXJlIGlu Y2x1ZGVkIGluIHRoZSBlbnRpdHkgYm9keSBvZiB0aGUgSFRUUCByZXNwb25zZQogICB1c2luZyB0 aGUgImFwcGxpY2F0aW9uL2pzb24iIG1lZGlhIHR5cGUgYXMgZGVmaW5lZCBieSBbUkZDNDYyN10u ICBUaGUKICAgcGFyYW1ldGVycyBhcmUgc2VyaWFsaXplZCBpbnRvIGEgSlNPTiBzdHJ1Y3R1cmUg YnkgYWRkaW5nIGVhY2gKICAgcGFyYW1ldGVyIGF0IHRoZSBoaWdoZXN0IHN0cnVjdHVyZSBsZXZl bC4gIFBhcmFtZXRlciBuYW1lcyBhbmQgc3RyaW5nCiAgIHZhbHVlcyBhcmUgaW5jbHVkZWQgYXMg SlNPTiBzdHJpbmdzLiAgTnVtZXJpY2FsIHZhbHVlcyBhcmUgaW5jbHVkZWQKICAgYXMgSlNPTiBu dW1iZXJzLiAgVGhlIG9yZGVyIG9mIHBhcmFtZXRlcnMgZG9lcyBub3QgbWF0dGVyIGFuZCBjYW4K CgoKSGFtbWVyLCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBEZWNlbWJlciAyMCwgMjAxMiAgICAg ICAgICAgICAgW1BhZ2UgNDJdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICBPQXV0 aCAyLjAgICAgICAgICAgICAgICAgICAgICAgSnVuZSAyMDEyCgoKICAgdmFyeS4KCiAgIEZvciBl eGFtcGxlOgoKCiAgICAgSFRUUC8xLjEgNDAwIEJhZCBSZXF1ZXN0CiAgICAgQ29udGVudC1UeXBl OiBhcHBsaWNhdGlvbi9qc29uO2NoYXJzZXQ9VVRGLTgKICAgICBDYWNoZS1Db250cm9sOiBuby1z dG9yZQogICAgIFByYWdtYTogbm8tY2FjaGUKCiAgICAgewogICAgICAgImVycm9yIjoiaW52YWxp ZF9yZXF1ZXN0IgogICAgIH0KCgoKNi4gIFJlZnJlc2hpbmcgYW4gQWNjZXNzIFRva2VuCgogICBJ ZiB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgaXNzdWVkIGEgcmVmcmVzaCB0b2tlbiB0byB0aGUg Y2xpZW50LCB0aGUKICAgY2xpZW50IG1ha2VzIGEgcmVmcmVzaCByZXF1ZXN0IHRvIHRoZSB0b2tl biBlbmRwb2ludCBieSBhZGRpbmcgdGhlCiAgIGZvbGxvd2luZyBwYXJhbWV0ZXJzIHVzaW5nIHRo ZSAiYXBwbGljYXRpb24veC13d3ctZm9ybS11cmxlbmNvZGVkIgogICBmb3JtYXQgaW4gdGhlIEhU VFAgcmVxdWVzdCBlbnRpdHktYm9keToKCiAgIGdyYW50X3R5cGUKICAgICAgICAgUkVRVUlSRUQu ICBWYWx1ZSBNVVNUIGJlIHNldCB0byAicmVmcmVzaF90b2tlbiIuCiAgIHJlZnJlc2hfdG9rZW4K ICAgICAgICAgUkVRVUlSRUQuICBUaGUgcmVmcmVzaCB0b2tlbiBpc3N1ZWQgdG8gdGhlIGNsaWVu dC4KICAgc2NvcGUKICAgICAgICAgT1BUSU9OQUwuICBUaGUgc2NvcGUgb2YgdGhlIGFjY2VzcyBy ZXF1ZXN0IGFzIGRlc2NyaWJlZCBieQogICAgICAgICBTZWN0aW9uIDMuMy4gIFRoZSByZXF1ZXN0 ZWQgc2NvcGUgTVVTVCBOT1QgaW5jbHVkZSBhbnkgc2NvcGUKICAgICAgICAgbm90IG9yaWdpbmFs bHkgZ3JhbnRlZCBieSB0aGUgcmVzb3VyY2Ugb3duZXIsIGFuZCBpZiBvbWl0dGVkIGlzCiAgICAg ICAgIHRyZWF0ZWQgYXMgZXF1YWwgdG8gdGhlIHNjb3BlIG9yaWdpbmFsbHkgZ3JhbnRlZCBieSB0 aGUKICAgICAgICAgcmVzb3VyY2Ugb3duZXIuCgogICBCZWNhdXNlIHJlZnJlc2ggdG9rZW5zIGFy ZSB0eXBpY2FsbHkgbG9uZy1sYXN0aW5nIGNyZWRlbnRpYWxzIHVzZWQgdG8KICAgcmVxdWVzdCBh ZGRpdGlvbmFsIGFjY2VzcyB0b2tlbnMsIHRoZSByZWZyZXNoIHRva2VuIGlzIGJvdW5kIHRvIHRo ZQogICBjbGllbnQgdG8gd2hpY2ggaXQgd2FzIGlzc3VlZC4gIElmIHRoZSBjbGllbnQgdHlwZSBp cyBjb25maWRlbnRpYWwgb3IKICAgdGhlIGNsaWVudCB3YXMgaXNzdWVkIGNsaWVudCBjcmVkZW50 aWFscyAob3IgYXNzaWduZWQgb3RoZXIKICAgYXV0aGVudGljYXRpb24gcmVxdWlyZW1lbnRzKSwg dGhlIGNsaWVudCBNVVNUIGF1dGhlbnRpY2F0ZSB3aXRoIHRoZQogICBhdXRob3JpemF0aW9uIHNl cnZlciBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiAzLjIuMS4KCgoKCgoKCgoKCgpIYW1tZXIsIGV0 IGFsLiAgICAgICAgICBFeHBpcmVzIERlY2VtYmVyIDIwLCAyMDEyICAgICAgICAgICAgICBbUGFn ZSA0M10KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgIE9BdXRoIDIuMCAgICAgICAg ICAgICAgICAgICAgICBKdW5lIDIwMTIKCgogICBGb3IgZXhhbXBsZSwgdGhlIGNsaWVudCBtYWtl cyB0aGUgZm9sbG93aW5nIEhUVFAgcmVxdWVzdCB1c2luZwogICB0cmFuc3BvcnQtbGF5ZXIgc2Vj dXJpdHkgKGV4dHJhIGxpbmUgYnJlYWtzIGFyZSBmb3IgZGlzcGxheSBwdXJwb3NlcwogICBvbmx5 KToKCgogICAgIFBPU1QgL3Rva2VuIEhUVFAvMS4xCiAgICAgSG9zdDogc2VydmVyLmV4YW1wbGUu Y29tCiAgICAgQXV0aG9yaXphdGlvbjogQmFzaWMgY3paQ2FHUlNhM0YwTXpwbldERm1RbUYwTTJK VwogICAgIENvbnRlbnQtVHlwZTogYXBwbGljYXRpb24veC13d3ctZm9ybS11cmxlbmNvZGVkO2No YXJzZXQ9VVRGLTgKCiAgICAgZ3JhbnRfdHlwZT1yZWZyZXNoX3Rva2VuJnJlZnJlc2hfdG9rZW49 dEd6djNKT2tGMFhHNVF4MlRsS1dJQQoKCiAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBNVVNU OgoKICAgbyAgcmVxdWlyZSBjbGllbnQgYXV0aGVudGljYXRpb24gZm9yIGNvbmZpZGVudGlhbCBj bGllbnRzIG9yIGZvciBhbnkKICAgICAgY2xpZW50IHRoYXQgd2FzIGlzc3VlZCBjbGllbnQgY3Jl ZGVudGlhbHMgKG9yIHdpdGggb3RoZXIKICAgICAgYXV0aGVudGljYXRpb24gcmVxdWlyZW1lbnRz KSwKICAgbyAgYXV0aGVudGljYXRlIHRoZSBjbGllbnQgaWYgY2xpZW50IGF1dGhlbnRpY2F0aW9u IGlzIGluY2x1ZGVkIGFuZAogICAgICBlbnN1cmUgdGhlIHJlZnJlc2ggdG9rZW4gd2FzIGlzc3Vl ZCB0byB0aGUgYXV0aGVudGljYXRlZCBjbGllbnQsCiAgICAgIGFuZAogICBvICB2YWxpZGF0ZSB0 aGUgcmVmcmVzaCB0b2tlbi4KCiAgIElmIHZhbGlkIGFuZCBhdXRob3JpemVkLCB0aGUgYXV0aG9y aXphdGlvbiBzZXJ2ZXIgaXNzdWVzIGFuIGFjY2VzcwogICB0b2tlbiBhcyBkZXNjcmliZWQgaW4g U2VjdGlvbiA1LjEuICBJZiB0aGUgcmVxdWVzdCBmYWlsZWQKICAgdmVyaWZpY2F0aW9uIG9yIGlz IGludmFsaWQsIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciByZXR1cm5zIGFuIGVycm9yCiAgIHJl c3BvbnNlIGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDUuMi4KCiAgIFRoZSBhdXRob3JpemF0aW9u IHNlcnZlciBNQVkgaXNzdWUgYSBuZXcgcmVmcmVzaCB0b2tlbiwgaW4gd2hpY2ggY2FzZQogICB0 aGUgY2xpZW50IE1VU1QgZGlzY2FyZCB0aGUgb2xkIHJlZnJlc2ggdG9rZW4gYW5kIHJlcGxhY2Ug aXQgd2l0aCB0aGUKICAgbmV3IHJlZnJlc2ggdG9rZW4uICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2 ZXIgTUFZIHJldm9rZSB0aGUgb2xkCiAgIHJlZnJlc2ggdG9rZW4gYWZ0ZXIgaXNzdWluZyBhIG5l dyByZWZyZXNoIHRva2VuIHRvIHRoZSBjbGllbnQuICBJZiBhCiAgIG5ldyByZWZyZXNoIHRva2Vu IGlzIGlzc3VlZCwgdGhlIHJlZnJlc2ggdG9rZW4gc2NvcGUgTVVTVCBiZQogICBpZGVudGljYWwg dG8gdGhhdCBvZiB0aGUgcmVmcmVzaCB0b2tlbiBpbmNsdWRlZCBieSB0aGUgY2xpZW50IGluIHRo ZQogICByZXF1ZXN0LgoKCjcuICBBY2Nlc3NpbmcgUHJvdGVjdGVkIFJlc291cmNlcwoKICAgVGhl IGNsaWVudCBhY2Nlc3NlcyBwcm90ZWN0ZWQgcmVzb3VyY2VzIGJ5IHByZXNlbnRpbmcgdGhlIGFj Y2VzcwogICB0b2tlbiB0byB0aGUgcmVzb3VyY2Ugc2VydmVyLiAgVGhlIHJlc291cmNlIHNlcnZl ciBNVVNUIHZhbGlkYXRlIHRoZQogICBhY2Nlc3MgdG9rZW4gYW5kIGVuc3VyZSBpdCBoYXMgbm90 IGV4cGlyZWQgYW5kIHRoYXQgaXRzIHNjb3BlIGNvdmVycwogICB0aGUgcmVxdWVzdGVkIHJlc291 cmNlLiAgVGhlIG1ldGhvZHMgdXNlZCBieSB0aGUgcmVzb3VyY2Ugc2VydmVyIHRvCiAgIHZhbGlk YXRlIHRoZSBhY2Nlc3MgdG9rZW4gKGFzIHdlbGwgYXMgYW55IGVycm9yIHJlc3BvbnNlcykgYXJl IGJleW9uZAogICB0aGUgc2NvcGUgb2YgdGhpcyBzcGVjaWZpY2F0aW9uLCBidXQgZ2VuZXJhbGx5 IGludm9sdmUgYW4gaW50ZXJhY3Rpb24KICAgb3IgY29vcmRpbmF0aW9uIGJldHdlZW4gdGhlIHJl c291cmNlIHNlcnZlciBhbmQgdGhlIGF1dGhvcml6YXRpb24KICAgc2VydmVyLgoKCgoKSGFtbWVy LCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBEZWNlbWJlciAyMCwgMjAxMiAgICAgICAgICAgICAg W1BhZ2UgNDRdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICBPQXV0aCAyLjAgICAg ICAgICAgICAgICAgICAgICAgSnVuZSAyMDEyCgoKICAgVGhlIG1ldGhvZCBpbiB3aGljaCB0aGUg Y2xpZW50IHV0aWxpemVzIHRoZSBhY2Nlc3MgdG9rZW4gdG8KICAgYXV0aGVudGljYXRlIHdpdGgg dGhlIHJlc291cmNlIHNlcnZlciBkZXBlbmRzIG9uIHRoZSB0eXBlIG9mIGFjY2VzcwogICB0b2tl biBpc3N1ZWQgYnkgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLiAgVHlwaWNhbGx5LCBpdCBpbnZv bHZlcwogICB1c2luZyB0aGUgSFRUUCAiQXV0aG9yaXphdGlvbiIgcmVxdWVzdCBoZWFkZXIgZmll bGQgW1JGQzI2MTddIHdpdGggYW4KICAgYXV0aGVudGljYXRpb24gc2NoZW1lIGRlZmluZWQgYnkg dGhlIGFjY2VzcyB0b2tlbiB0eXBlIHNwZWNpZmljYXRpb24uCgo3LjEuICBBY2Nlc3MgVG9rZW4g VHlwZXMKCiAgIFRoZSBhY2Nlc3MgdG9rZW4gdHlwZSBwcm92aWRlcyB0aGUgY2xpZW50IHdpdGgg dGhlIGluZm9ybWF0aW9uCiAgIHJlcXVpcmVkIHRvIHN1Y2Nlc3NmdWxseSB1dGlsaXplIHRoZSBh Y2Nlc3MgdG9rZW4gdG8gbWFrZSBhIHByb3RlY3RlZAogICByZXNvdXJjZSByZXF1ZXN0IChhbG9u ZyB3aXRoIHR5cGUtc3BlY2lmaWMgYXR0cmlidXRlcykuICBUaGUgY2xpZW50CiAgIE1VU1QgTk9U IHVzZSBhbiBhY2Nlc3MgdG9rZW4gaWYgaXQgZG9lcyBub3QgdW5kZXJzdGFuZCB0aGUgdG9rZW4K ICAgdHlwZS4KCiAgIEZvciBleGFtcGxlLCB0aGUgImJlYXJlciIgdG9rZW4gdHlwZSBkZWZpbmVk IGluCiAgIFtJLUQuaWV0Zi1vYXV0aC12Mi1iZWFyZXJdIGlzIHV0aWxpemVkIGJ5IHNpbXBseSBp bmNsdWRpbmcgdGhlIGFjY2VzcwogICB0b2tlbiBzdHJpbmcgaW4gdGhlIHJlcXVlc3Q6CgoKICAg ICBHRVQgL3Jlc291cmNlLzEgSFRUUC8xLjEKICAgICBIb3N0OiBleGFtcGxlLmNvbQogICAgIEF1 dGhvcml6YXRpb246IEJlYXJlciBtRl85LkI1Zi00LjFKcU0KCgogICB3aGlsZSB0aGUgIm1hYyIg dG9rZW4gdHlwZSBkZWZpbmVkIGluIFtJLUQuaWV0Zi1vYXV0aC12Mi1odHRwLW1hY10gaXMKICAg dXRpbGl6ZWQgYnkgaXNzdWluZyBhIE1BQyBrZXkgdG9nZXRoZXIgd2l0aCB0aGUgYWNjZXNzIHRv a2VuIHdoaWNoIGlzCiAgIHVzZWQgdG8gc2lnbiBjZXJ0YWluIGNvbXBvbmVudHMgb2YgdGhlIEhU VFAgcmVxdWVzdHM6CgoKICAgICBHRVQgL3Jlc291cmNlLzEgSFRUUC8xLjEKICAgICBIb3N0OiBl eGFtcGxlLmNvbQogICAgIEF1dGhvcml6YXRpb246IE1BQyBpZD0iaDQ4MGRqczkzaGQ4IiwKICAg ICAgICAgICAgICAgICAgICAgICAgbm9uY2U9IjI3NDMxMjpkajgzaHM5cyIsCiAgICAgICAgICAg ICAgICAgICAgICAgIG1hYz0ia0RadmRka25keHZoR1JYWmh2dURqRVdoR2VFPSIKCgogICBUaGUg YWJvdmUgZXhhbXBsZXMgYXJlIHByb3ZpZGVkIGZvciBpbGx1c3RyYXRpb24gcHVycG9zZXMgb25s eS4KICAgRGV2ZWxvcGVycyBhcmUgYWR2aXNlZCB0byBjb25zdWx0IHRoZSBbSS1ELmlldGYtb2F1 dGgtdjItYmVhcmVyXSBhbmQKICAgW0ktRC5pZXRmLW9hdXRoLXYyLWh0dHAtbWFjXSBzcGVjaWZp Y2F0aW9ucyBiZWZvcmUgdXNlLgoKICAgRWFjaCBhY2Nlc3MgdG9rZW4gdHlwZSBkZWZpbml0aW9u IHNwZWNpZmllcyB0aGUgYWRkaXRpb25hbCBhdHRyaWJ1dGVzCiAgIChpZiBhbnkpIHNlbnQgdG8g dGhlIGNsaWVudCB0b2dldGhlciB3aXRoIHRoZSAiYWNjZXNzX3Rva2VuIiByZXNwb25zZQogICBw YXJhbWV0ZXIuICBJdCBhbHNvIGRlZmluZXMgdGhlIEhUVFAgYXV0aGVudGljYXRpb24gbWV0aG9k IHVzZWQgdG8KICAgaW5jbHVkZSB0aGUgYWNjZXNzIHRva2VuIHdoZW4gbWFraW5nIGEgcHJvdGVj dGVkIHJlc291cmNlIHJlcXVlc3QuCgoKCgoKCgpIYW1tZXIsIGV0IGFsLiAgICAgICAgICBFeHBp cmVzIERlY2VtYmVyIDIwLCAyMDEyICAgICAgICAgICAgICBbUGFnZSA0NV0KDApJbnRlcm5ldC1E cmFmdCAgICAgICAgICAgICAgICAgIE9BdXRoIDIuMCAgICAgICAgICAgICAgICAgICAgICBKdW5l IDIwMTIKCgo3LjIuICBFcnJvciBSZXNwb25zZQoKICAgSWYgYSByZXNvdXJjZSBhY2Nlc3MgcmVx dWVzdCBmYWlscywgdGhlIHJlc291cmNlIHNlcnZlciBTSE9VTEQgaW5mb3JtCiAgIHRoZSBjbGll bnQgb2YgdGhlIGVycm9yLiAgV2hpbGUgdGhlIHNwZWNpZmljcyBvZiBzdWNoIGVycm9yIHJlc3Bv bnNlcwogICBhcmUgYmV5b25kIHRoZSBzY29wZSBvZiB0aGlzIHNwZWNpZmljYXRpb24sIHRoaXMg ZG9jdW1lbnRzCiAgIGVzdGFibGlzaGVzIGEgY29tbW9uIHJlZ2lzdHJ5IGluIFNlY3Rpb24gMTEu NCBmb3IgZXJyb3IgdmFsdWVzIHRvIGJlCiAgIHNoYXJlZCBhbW9uZyBPQXV0aCB0b2tlbiBhdXRo ZW50aWNhdGlvbiBzY2hlbWVzLgoKICAgTmV3IGF1dGhlbnRpY2F0aW9uIHNjaGVtZXMgZGVzaWdu ZWQgcHJpbWFyaWx5IGZvciBPQXV0aCB0b2tlbgogICBhdXRoZW50aWNhdGlvbiBTSE9VTEQgZGVm aW5lIGEgbWVjaGFuaXNtIGZvciBwcm92aWRpbmcgYW4gZXJyb3IKICAgc3RhdHVzIGNvZGUgdG8g dGhlIGNsaWVudCwgaW4gd2hpY2ggdGhlIGVycm9yIHZhbHVlcyBhbGxvd2VkIGFyZQogICByZWdp c3RlcmVkIGluIHRoZSBlcnJvciByZWdpc3RyeSBlc3RhYmxpc2hlZCBieSB0aGlzIHNwZWNpZmlj YXRpb24uCiAgIFN1Y2ggc2NoZW1lcyBNQVkgbGltaXQgdGhlIHNldCBvZiB2YWxpZCBlcnJvciBj b2RlcyB0byBhIHN1YnNldCBvZgogICB0aGUgcmVnaXN0ZXJlZCB2YWx1ZXMuICBJZiB0aGUgZXJy b3IgY29kZSBpcyByZXR1cm5lZCB1c2luZyBhIG5hbWVkCiAgIHBhcmFtZXRlciwgdGhlIHBhcmFt ZXRlciBuYW1lIFNIT1VMRCBiZSAiZXJyb3IiLgoKICAgT3RoZXIgc2NoZW1lcyBjYXBhYmxlIG9m IGJlaW5nIHVzZWQgZm9yIE9BdXRoIHRva2VuIGF1dGhlbnRpY2F0aW9uLAogICBidXQgbm90IHBy aW1hcmlseSBkZXNpZ25lZCBmb3IgdGhhdCBwdXJwb3NlLCBNQVkgYmluZCB0aGVpciBlcnJvcgog ICB2YWx1ZXMgdG8gdGhlIHJlZ2lzdHJ5IGluIHRoZSBzYW1lIG1hbm5lci4KCiAgIE5ldyBhdXRo ZW50aWNhdGlvbiBzY2hlbWVzIE1BWSBjaG9vc2UgdG8gYWxzbyBzcGVjaWZ5IHRoZSB1c2Ugb2Yg dGhlCiAgICJlcnJvcl9kZXNjcmlwdGlvbiIgYW5kICJlcnJvcl91cmkiIHBhcmFtZXRlcnMgdG8g cmV0dXJuIGVycm9yCiAgIGluZm9ybWF0aW9uIGluIGEgbWFubmVyIHBhcmFsbGVsIHRvIHRoZWly IHVzYWdlIGluIHRoaXMKICAgc3BlY2lmaWNhdGlvbi4KCgo4LiAgRXh0ZW5zaWJpbGl0eQoKOC4x LiAgRGVmaW5pbmcgQWNjZXNzIFRva2VuIFR5cGVzCgogICBBY2Nlc3MgdG9rZW4gdHlwZXMgY2Fu IGJlIGRlZmluZWQgaW4gb25lIG9mIHR3byB3YXlzOiByZWdpc3RlcmVkIGluCiAgIHRoZSBhY2Nl c3MgdG9rZW4gdHlwZSByZWdpc3RyeSAoZm9sbG93aW5nIHRoZSBwcm9jZWR1cmVzIGluCiAgIFNl Y3Rpb24gMTEuMSksIG9yIGJ5IHVzaW5nIGEgdW5pcXVlIGFic29sdXRlIFVSSSBhcyBpdHMgbmFt ZS4KCiAgIFR5cGVzIHV0aWxpemluZyBhIFVSSSBuYW1lIFNIT1VMRCBiZSBsaW1pdGVkIHRvIHZl bmRvci1zcGVjaWZpYwogICBpbXBsZW1lbnRhdGlvbnMgdGhhdCBhcmUgbm90IGNvbW1vbmx5IGFw cGxpY2FibGUsIGFuZCBhcmUgc3BlY2lmaWMgdG8KICAgdGhlIGltcGxlbWVudGF0aW9uIGRldGFp bHMgb2YgdGhlIHJlc291cmNlIHNlcnZlciB3aGVyZSB0aGV5IGFyZQogICB1c2VkLgoKICAgQWxs IG90aGVyIHR5cGVzIE1VU1QgYmUgcmVnaXN0ZXJlZC4gIFR5cGUgbmFtZXMgTVVTVCBjb25mb3Jt IHRvIHRoZQogICB0eXBlLW5hbWUgQUJORi4gIElmIHRoZSB0eXBlIGRlZmluaXRpb24gaW5jbHVk ZXMgYSBuZXcgSFRUUAogICBhdXRoZW50aWNhdGlvbiBzY2hlbWUsIHRoZSB0eXBlIG5hbWUgU0hP VUxEIGJlIGlkZW50aWNhbCB0byB0aGUgSFRUUAogICBhdXRoZW50aWNhdGlvbiBzY2hlbWUgbmFt ZSAoYXMgZGVmaW5lZCBieSBbUkZDMjYxN10pLiAgVGhlIHRva2VuIHR5cGUKICAgImV4YW1wbGUi IGlzIHJlc2VydmVkIGZvciB1c2UgaW4gZXhhbXBsZXMuCgoKICAgICB0eXBlLW5hbWUgID0gMSpu YW1lLWNoYXIKICAgICBuYW1lLWNoYXIgID0gIi0iIC8gIi4iIC8gIl8iIC8gRElHSVQgLyBBTFBI QQoKCgpIYW1tZXIsIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIERlY2VtYmVyIDIwLCAyMDEyICAg ICAgICAgICAgICBbUGFnZSA0Nl0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgIE9B dXRoIDIuMCAgICAgICAgICAgICAgICAgICAgICBKdW5lIDIwMTIKCgo4LjIuICBEZWZpbmluZyBO ZXcgRW5kcG9pbnQgUGFyYW1ldGVycwoKICAgTmV3IHJlcXVlc3Qgb3IgcmVzcG9uc2UgcGFyYW1l dGVycyBmb3IgdXNlIHdpdGggdGhlIGF1dGhvcml6YXRpb24KICAgZW5kcG9pbnQgb3IgdGhlIHRv a2VuIGVuZHBvaW50IGFyZSBkZWZpbmVkIGFuZCByZWdpc3RlcmVkIGluIHRoZQogICBwYXJhbWV0 ZXJzIHJlZ2lzdHJ5IGZvbGxvd2luZyB0aGUgcHJvY2VkdXJlIGluIFNlY3Rpb24gMTEuMi4KCiAg IFBhcmFtZXRlciBuYW1lcyBNVVNUIGNvbmZvcm0gdG8gdGhlIHBhcmFtLW5hbWUgQUJORiBhbmQg cGFyYW1ldGVyCiAgIHZhbHVlcyBzeW50YXggTVVTVCBiZSB3ZWxsLWRlZmluZWQgKGUuZy4sIHVz aW5nIEFCTkYsIG9yIGEgcmVmZXJlbmNlCiAgIHRvIHRoZSBzeW50YXggb2YgYW4gZXhpc3Rpbmcg cGFyYW1ldGVyKS4KCgogICAgIHBhcmFtLW5hbWUgID0gMSpuYW1lLWNoYXIKICAgICBuYW1lLWNo YXIgICA9ICItIiAvICIuIiAvICJfIiAvIERJR0lUIC8gQUxQSEEKCgogICBVbnJlZ2lzdGVyZWQg dmVuZG9yLXNwZWNpZmljIHBhcmFtZXRlciBleHRlbnNpb25zIHRoYXQgYXJlIG5vdAogICBjb21t b25seSBhcHBsaWNhYmxlLCBhbmQgYXJlIHNwZWNpZmljIHRvIHRoZSBpbXBsZW1lbnRhdGlvbiBk ZXRhaWxzCiAgIG9mIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciB3aGVyZSB0aGV5IGFyZSB1c2Vk IFNIT1VMRCB1dGlsaXplIGEKICAgdmVuZG9yLXNwZWNpZmljIHByZWZpeCB0aGF0IGlzIG5vdCBs aWtlbHkgdG8gY29uZmxpY3Qgd2l0aCBvdGhlcgogICByZWdpc3RlcmVkIHZhbHVlcyAoZS5nLiBi ZWdpbiB3aXRoICdjb21wYW55bmFtZV8nKS4KCjguMy4gIERlZmluaW5nIE5ldyBBdXRob3JpemF0 aW9uIEdyYW50IFR5cGVzCgogICBOZXcgYXV0aG9yaXphdGlvbiBncmFudCB0eXBlcyBjYW4gYmUg ZGVmaW5lZCBieSBhc3NpZ25pbmcgdGhlbSBhCiAgIHVuaXF1ZSBhYnNvbHV0ZSBVUkkgZm9yIHVz ZSB3aXRoIHRoZSAiZ3JhbnRfdHlwZSIgcGFyYW1ldGVyLiAgSWYgdGhlCiAgIGV4dGVuc2lvbiBn cmFudCB0eXBlIHJlcXVpcmVzIGFkZGl0aW9uYWwgdG9rZW4gZW5kcG9pbnQgcGFyYW1ldGVycywK ICAgdGhleSBNVVNUIGJlIHJlZ2lzdGVyZWQgaW4gdGhlIE9BdXRoIHBhcmFtZXRlcnMgcmVnaXN0 cnkgYXMgZGVzY3JpYmVkCiAgIGJ5IFNlY3Rpb24gMTEuMi4KCjguNC4gIERlZmluaW5nIE5ldyBB dXRob3JpemF0aW9uIEVuZHBvaW50IFJlc3BvbnNlIFR5cGVzCgogICBOZXcgcmVzcG9uc2UgdHlw ZXMgZm9yIHVzZSB3aXRoIHRoZSBhdXRob3JpemF0aW9uIGVuZHBvaW50IGFyZQogICBkZWZpbmVk IGFuZCByZWdpc3RlcmVkIGluIHRoZSBhdXRob3JpemF0aW9uIGVuZHBvaW50IHJlc3BvbnNlIHR5 cGUKICAgcmVnaXN0cnkgZm9sbG93aW5nIHRoZSBwcm9jZWR1cmUgaW4gU2VjdGlvbiAxMS4zLiAg UmVzcG9uc2UgdHlwZQogICBuYW1lcyBNVVNUIGNvbmZvcm0gdG8gdGhlIHJlc3BvbnNlLXR5cGUg QUJORi4KCgogICAgIHJlc3BvbnNlLXR5cGUgID0gcmVzcG9uc2UtbmFtZSAqKCBTUCByZXNwb25z ZS1uYW1lICkKICAgICByZXNwb25zZS1uYW1lICA9IDEqcmVzcG9uc2UtY2hhcgogICAgIHJlc3Bv bnNlLWNoYXIgID0gIl8iIC8gRElHSVQgLyBBTFBIQQoKCiAgIElmIGEgcmVzcG9uc2UgdHlwZSBj b250YWlucyBvbmUgb3IgbW9yZSBzcGFjZSBjaGFyYWN0ZXJzICgleDIwKSwgaXQKICAgaXMgY29t cGFyZWQgYXMgYSBzcGFjZS1kZWxpbWl0ZWQgbGlzdCBvZiB2YWx1ZXMgaW4gd2hpY2ggdGhlIG9y ZGVyIG9mCiAgIHZhbHVlcyBkb2VzIG5vdCBtYXR0ZXIuICBPbmx5IG9uZSBvcmRlciBvZiB2YWx1 ZXMgY2FuIGJlIHJlZ2lzdGVyZWQsCiAgIHdoaWNoIGNvdmVycyBhbGwgb3RoZXIgYXJyYW5nZW1l bnRzIG9mIHRoZSBzYW1lIHNldCBvZiB2YWx1ZXMuCgogICBGb3IgZXhhbXBsZSwgdGhlIHJlc3Bv bnNlIHR5cGUgInRva2VuIGNvZGUiIGlzIGxlZnQgdW5kZWZpbmVkIGJ5IHRoaXMKCgoKSGFtbWVy LCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBEZWNlbWJlciAyMCwgMjAxMiAgICAgICAgICAgICAg W1BhZ2UgNDddCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICBPQXV0aCAyLjAgICAg ICAgICAgICAgICAgICAgICAgSnVuZSAyMDEyCgoKICAgc3BlY2lmaWNhdGlvbi4gIEhvd2V2ZXIs IGFuIGV4dGVuc2lvbiBjYW4gZGVmaW5lIGFuZCByZWdpc3RlciB0aGUKICAgInRva2VuIGNvZGUi IHJlc3BvbnNlIHR5cGUuICBPbmNlIHJlZ2lzdGVyZWQsIHRoZSBzYW1lIGNvbWJpbmF0aW9uCiAg IGNhbm5vdCBiZSByZWdpc3RlcmVkIGFzICJjb2RlIHRva2VuIiwgYnV0IGJvdGggdmFsdWVzIGNh biBiZSB1c2VkIHRvCiAgIGRlbm90ZSB0aGUgc2FtZSByZXNwb25zZSB0eXBlLgoKOC41LiAgRGVm aW5pbmcgQWRkaXRpb25hbCBFcnJvciBDb2RlcwoKICAgSW4gY2FzZXMgd2hlcmUgcHJvdG9jb2wg ZXh0ZW5zaW9ucyAoaS5lLiBhY2Nlc3MgdG9rZW4gdHlwZXMsCiAgIGV4dGVuc2lvbiBwYXJhbWV0 ZXJzLCBvciBleHRlbnNpb24gZ3JhbnQgdHlwZXMpIHJlcXVpcmUgYWRkaXRpb25hbAogICBlcnJv ciBjb2RlcyB0byBiZSB1c2VkIHdpdGggdGhlIGF1dGhvcml6YXRpb24gY29kZSBncmFudCBlcnJv cgogICByZXNwb25zZSAoU2VjdGlvbiA0LjEuMi4xKSwgdGhlIGltcGxpY2l0IGdyYW50IGVycm9y IHJlc3BvbnNlCiAgIChTZWN0aW9uIDQuMi4yLjEpLCB0aGUgdG9rZW4gZXJyb3IgcmVzcG9uc2Ug KFNlY3Rpb24gNS4yKSwgb3IgdGhlCiAgIHJlc291cmNlIGFjY2VzcyBlcnJvciByZXNwb25zZSAo U2VjdGlvbiA3LjIpLCBzdWNoIGVycm9yIGNvZGVzIE1BWSBiZQogICBkZWZpbmVkLgoKICAgRXh0 ZW5zaW9uIGVycm9yIGNvZGVzIE1VU1QgYmUgcmVnaXN0ZXJlZCAoZm9sbG93aW5nIHRoZSBwcm9j ZWR1cmVzIGluCiAgIFNlY3Rpb24gMTEuNCkgaWYgdGhlIGV4dGVuc2lvbiB0aGV5IGFyZSB1c2Vk IGluIGNvbmp1bmN0aW9uIHdpdGggaXMgYQogICByZWdpc3RlcmVkIGFjY2VzcyB0b2tlbiB0eXBl LCBhIHJlZ2lzdGVyZWQgZW5kcG9pbnQgcGFyYW1ldGVyLCBvciBhbgogICBleHRlbnNpb24gZ3Jh bnQgdHlwZS4gIEVycm9yIGNvZGVzIHVzZWQgd2l0aCB1bnJlZ2lzdGVyZWQgZXh0ZW5zaW9ucwog ICBNQVkgYmUgcmVnaXN0ZXJlZC4KCiAgIEVycm9yIGNvZGVzIE1VU1QgY29uZm9ybSB0byB0aGUg ZXJyb3IgQUJORiwgYW5kIFNIT1VMRCBiZSBwcmVmaXhlZCBieQogICBhbiBpZGVudGlmeWluZyBu YW1lIHdoZW4gcG9zc2libGUuICBGb3IgZXhhbXBsZSwgYW4gZXJyb3IgaWRlbnRpZnlpbmcKICAg YW4gaW52YWxpZCB2YWx1ZSBzZXQgdG8gdGhlIGV4dGVuc2lvbiBwYXJhbWV0ZXIgImV4YW1wbGUi IFNIT1VMRCBiZQogICBuYW1lZCAiZXhhbXBsZV9pbnZhbGlkIi4KCgogICAgIGVycm9yICAgICAg PSAxKmVycm9yLWNoYXIKICAgICBlcnJvci1jaGFyID0gJXgyMC0yMSAvICV4MjMtNUIgLyAleDVE LTdFCgoKCjkuICBOYXRpdmUgQXBwbGljYXRpb25zCgogICBOYXRpdmUgYXBwbGljYXRpb25zIGFy ZSBjbGllbnRzIGluc3RhbGxlZCBhbmQgZXhlY3V0ZWQgb24gdGhlIGRldmljZQogICB1c2VkIGJ5 IHRoZSByZXNvdXJjZSBvd25lciAoaS5lLiBkZXNrdG9wIGFwcGxpY2F0aW9uLCBuYXRpdmUgbW9i aWxlCiAgIGFwcGxpY2F0aW9uKS4gIE5hdGl2ZSBhcHBsaWNhdGlvbnMgcmVxdWlyZSBzcGVjaWFs IGNvbnNpZGVyYXRpb24KICAgcmVsYXRlZCB0byBzZWN1cml0eSwgcGxhdGZvcm0gY2FwYWJpbGl0 aWVzLCBhbmQgb3ZlcmFsbCBlbmQtdXNlcgogICBleHBlcmllbmNlLgoKICAgVGhlIGF1dGhvcml6 YXRpb24gZW5kcG9pbnQgcmVxdWlyZXMgaW50ZXJhY3Rpb24gYmV0d2VlbiB0aGUgY2xpZW50CiAg IGFuZCB0aGUgcmVzb3VyY2Ugb3duZXIncyB1c2VyLWFnZW50LiAgTmF0aXZlIGFwcGxpY2F0aW9u cyBjYW4gaW52b2tlCiAgIGFuIGV4dGVybmFsIHVzZXItYWdlbnQgb3IgZW1iZWQgYSB1c2VyLWFn ZW50IHdpdGhpbiB0aGUgYXBwbGljYXRpb24uCiAgIEZvciBleGFtcGxlOgoKICAgbyAgRXh0ZXJu YWwgdXNlci1hZ2VudCAtIHRoZSBuYXRpdmUgYXBwbGljYXRpb24gY2FuIGNhcHR1cmUgdGhlCiAg ICAgIHJlc3BvbnNlIGZyb20gdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHVzaW5nIGEgcmVkaXJl Y3Rpb24gVVJJCiAgICAgIHdpdGggYSBzY2hlbWUgcmVnaXN0ZXJlZCB3aXRoIHRoZSBvcGVyYXRp bmcgc3lzdGVtIHRvIGludm9rZSB0aGUKCgoKSGFtbWVyLCBldCBhbC4gICAgICAgICAgRXhwaXJl cyBEZWNlbWJlciAyMCwgMjAxMiAgICAgICAgICAgICAgW1BhZ2UgNDhdCgwKSW50ZXJuZXQtRHJh ZnQgICAgICAgICAgICAgICAgICBPQXV0aCAyLjAgICAgICAgICAgICAgICAgICAgICAgSnVuZSAy MDEyCgoKICAgICAgY2xpZW50IGFzIHRoZSBoYW5kbGVyLCBtYW51YWwgY29weS1hbmQtcGFzdGUg b2YgdGhlIGNyZWRlbnRpYWxzLAogICAgICBydW5uaW5nIGEgbG9jYWwgd2ViIHNlcnZlciwgaW5z dGFsbGluZyBhIHVzZXItYWdlbnQgZXh0ZW5zaW9uLCBvcgogICAgICBieSBwcm92aWRpbmcgYSBy ZWRpcmVjdGlvbiBVUkkgaWRlbnRpZnlpbmcgYSBzZXJ2ZXItaG9zdGVkCiAgICAgIHJlc291cmNl IHVuZGVyIHRoZSBjbGllbnQncyBjb250cm9sLCB3aGljaCBpbiB0dXJuIG1ha2VzIHRoZQogICAg ICByZXNwb25zZSBhdmFpbGFibGUgdG8gdGhlIG5hdGl2ZSBhcHBsaWNhdGlvbi4KICAgbyAgRW1i ZWRkZWQgdXNlci1hZ2VudCAtIHRoZSBuYXRpdmUgYXBwbGljYXRpb24gb2J0YWlucyB0aGUgcmVz cG9uc2UKICAgICAgYnkgZGlyZWN0bHkgY29tbXVuaWNhdGluZyB3aXRoIHRoZSBlbWJlZGRlZCB1 c2VyLWFnZW50IGJ5CiAgICAgIG1vbml0b3Jpbmcgc3RhdGUgY2hhbmdlcyBlbWl0dGVkIGR1cmlu ZyB0aGUgcmVzb3VyY2UgbG9hZCwgb3IKICAgICAgYWNjZXNzaW5nIHRoZSB1c2VyLWFnZW50J3Mg Y29va2llcyBzdG9yYWdlLgoKICAgV2hlbiBjaG9vc2luZyBiZXR3ZWVuIGFuIGV4dGVybmFsIG9y IGVtYmVkZGVkIHVzZXItYWdlbnQsIGRldmVsb3BlcnMKICAgc2hvdWxkIGNvbnNpZGVyOgoKICAg byAgQW4gRXh0ZXJuYWwgdXNlci1hZ2VudCBtYXkgaW1wcm92ZSBjb21wbGV0aW9uIHJhdGUgYXMg dGhlIHJlc291cmNlCiAgICAgIG93bmVyIG1heSBhbHJlYWR5IGhhdmUgYW4gYWN0aXZlIHNlc3Np b24gd2l0aCB0aGUgYXV0aG9yaXphdGlvbgogICAgICBzZXJ2ZXIgcmVtb3ZpbmcgdGhlIG5lZWQg dG8gcmUtYXV0aGVudGljYXRlLiAgSXQgcHJvdmlkZXMgYQogICAgICBmYW1pbGlhciBlbmQtdXNl ciBleHBlcmllbmNlIGFuZCBmdW5jdGlvbmFsaXR5LiAgVGhlIHJlc291cmNlCiAgICAgIG93bmVy IG1heSBhbHNvIHJlbHkgb24gdXNlci1hZ2VudCBmZWF0dXJlcyBvciBleHRlbnNpb25zIHRvIGFz c2lzdAogICAgICB3aXRoIGF1dGhlbnRpY2F0aW9uIChlLmcuIHBhc3N3b3JkIG1hbmFnZXIsIDIt ZmFjdG9yIGRldmljZQogICAgICByZWFkZXIpLgogICBvICBBbiBlbWJlZGRlZCB1c2VyLWFnZW50 IG1heSBvZmZlciBpbXByb3ZlZCB1c2FiaWxpdHksIGFzIGl0IHJlbW92ZXMKICAgICAgdGhlIG5l ZWQgdG8gc3dpdGNoIGNvbnRleHQgYW5kIG9wZW4gbmV3IHdpbmRvd3MuCiAgIG8gIEFuIGVtYmVk ZGVkIHVzZXItYWdlbnQgcG9zZXMgYSBzZWN1cml0eSBjaGFsbGVuZ2UgYmVjYXVzZSByZXNvdXJj ZQogICAgICBvd25lcnMgYXJlIGF1dGhlbnRpY2F0aW5nIGluIGFuIHVuaWRlbnRpZmllZCB3aW5k b3cgd2l0aG91dCBhY2Nlc3MKICAgICAgdG8gdGhlIHZpc3VhbCBwcm90ZWN0aW9ucyBmb3VuZCBp biBtb3N0IGV4dGVybmFsIHVzZXItYWdlbnRzLiAgQW4KICAgICAgZW1iZWRkZWQgdXNlci1hZ2Vu dCBlZHVjYXRlcyBlbmQtdXNlcnMgdG8gdHJ1c3QgdW5pZGVudGlmaWVkCiAgICAgIHJlcXVlc3Rz IGZvciBhdXRoZW50aWNhdGlvbiAobWFraW5nIHBoaXNoaW5nIGF0dGFja3MgZWFzaWVyIHRvCiAg ICAgIGV4ZWN1dGUpLgoKICAgV2hlbiBjaG9vc2luZyBiZXR3ZWVuIHRoZSBpbXBsaWNpdCBncmFu dCB0eXBlIGFuZCB0aGUgYXV0aG9yaXphdGlvbgogICBjb2RlIGdyYW50IHR5cGUsIHRoZSBmb2xs b3dpbmcgc2hvdWxkIGJlIGNvbnNpZGVyZWQ6CgogICBvICBOYXRpdmUgYXBwbGljYXRpb25zIHRo YXQgdXNlIHRoZSBhdXRob3JpemF0aW9uIGNvZGUgZ3JhbnQgdHlwZQogICAgICBTSE9VTEQgZG8g c28gd2l0aG91dCB1c2luZyBjbGllbnQgY3JlZGVudGlhbHMsIGR1ZSB0byB0aGUgbmF0aXZlCiAg ICAgIGFwcGxpY2F0aW9uJ3MgaW5hYmlsaXR5IHRvIGtlZXAgY2xpZW50IGNyZWRlbnRpYWxzIGNv bmZpZGVudGlhbC4KICAgbyAgV2hlbiB1c2luZyB0aGUgaW1wbGljaXQgZ3JhbnQgdHlwZSBmbG93 IGEgcmVmcmVzaCB0b2tlbiBpcyBub3QKICAgICAgcmV0dXJuZWQgd2hpY2ggcmVxdWlyZXMgcmVw ZWF0aW5nIHRoZSBhdXRob3JpemF0aW9uIHByb2Nlc3Mgb25jZQogICAgICB0aGUgYWNjZXNzIHRv a2VuIGV4cGlyZXMuCgoKMTAuICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucwoKICAgQXMgYSBmbGV4 aWJsZSBhbmQgZXh0ZW5zaWJsZSBmcmFtZXdvcmssIE9BdXRoJ3Mgc2VjdXJpdHkKICAgY29uc2lk ZXJhdGlvbnMgZGVwZW5kIG9uIG1hbnkgZmFjdG9ycy4gIFRoZSBmb2xsb3dpbmcgc2VjdGlvbnMK ICAgcHJvdmlkZSBpbXBsZW1lbnRlcnMgd2l0aCBzZWN1cml0eSBndWlkZWxpbmVzIGZvY3VzZWQg b24gdGhlIHRocmVlCiAgIGNsaWVudCBwcm9maWxlcyBkZXNjcmliZWQgaW4gU2VjdGlvbiAyLjE6 IHdlYiBhcHBsaWNhdGlvbiwgdXNlci0KICAgYWdlbnQtYmFzZWQgYXBwbGljYXRpb24sIGFuZCBu YXRpdmUgYXBwbGljYXRpb24uCgoKCgpIYW1tZXIsIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIERl Y2VtYmVyIDIwLCAyMDEyICAgICAgICAgICAgICBbUGFnZSA0OV0KDApJbnRlcm5ldC1EcmFmdCAg ICAgICAgICAgICAgICAgIE9BdXRoIDIuMCAgICAgICAgICAgICAgICAgICAgICBKdW5lIDIwMTIK CgogICBBIGNvbXByZWhlbnNpdmUgT0F1dGggc2VjdXJpdHkgbW9kZWwgYW5kIGFuYWx5c2lzLCBh cyB3ZWxsIGFzCiAgIGJhY2tncm91bmQgZm9yIHRoZSBwcm90b2NvbCBkZXNpZ24sIGlzIHByb3Zp ZGVkIGJ5CiAgIFtJLUQuaWV0Zi1vYXV0aC12Mi10aHJlYXRtb2RlbF0uCgoxMC4xLiAgQ2xpZW50 IEF1dGhlbnRpY2F0aW9uCgogICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgZXN0YWJsaXNoZXMg Y2xpZW50IGNyZWRlbnRpYWxzIHdpdGggd2ViCiAgIGFwcGxpY2F0aW9uIGNsaWVudHMgZm9yIHRo ZSBwdXJwb3NlIG9mIGNsaWVudCBhdXRoZW50aWNhdGlvbi4gIFRoZQogICBhdXRob3JpemF0aW9u IHNlcnZlciBpcyBlbmNvdXJhZ2VkIHRvIGNvbnNpZGVyIHN0cm9uZ2VyIGNsaWVudAogICBhdXRo ZW50aWNhdGlvbiBtZWFucyB0aGFuIGEgY2xpZW50IHBhc3N3b3JkLiAgV2ViIGFwcGxpY2F0aW9u IGNsaWVudHMKICAgTVVTVCBlbnN1cmUgY29uZmlkZW50aWFsaXR5IG9mIGNsaWVudCBwYXNzd29y ZHMgYW5kIG90aGVyIGNsaWVudAogICBjcmVkZW50aWFscy4KCiAgIFRoZSBhdXRob3JpemF0aW9u IHNlcnZlciBNVVNUIE5PVCBpc3N1ZSBjbGllbnQgcGFzc3dvcmRzIG9yIG90aGVyCiAgIGNsaWVu dCBjcmVkZW50aWFscyB0byBuYXRpdmUgYXBwbGljYXRpb24gb3IgdXNlci1hZ2VudC1iYXNlZAog ICBhcHBsaWNhdGlvbiBjbGllbnRzIGZvciB0aGUgcHVycG9zZSBvZiBjbGllbnQgYXV0aGVudGlj YXRpb24uICBUaGUKICAgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTUFZIGlzc3VlIGEgY2xpZW50IHBh c3N3b3JkIG9yIG90aGVyIGNyZWRlbnRpYWxzCiAgIGZvciBhIHNwZWNpZmljIGluc3RhbGxhdGlv biBvZiBhIG5hdGl2ZSBhcHBsaWNhdGlvbiBjbGllbnQgb24gYQogICBzcGVjaWZpYyBkZXZpY2Uu CgogICBXaGVuIGNsaWVudCBhdXRoZW50aWNhdGlvbiBpcyBub3QgcG9zc2libGUsIHRoZSBhdXRo b3JpemF0aW9uIHNlcnZlcgogICBTSE9VTEQgZW1wbG95IG90aGVyIG1lYW5zIHRvIHZhbGlkYXRl IHRoZSBjbGllbnQncyBpZGVudGl0eS4gIEZvcgogICBleGFtcGxlLCBieSByZXF1aXJpbmcgdGhl IHJlZ2lzdHJhdGlvbiBvZiB0aGUgY2xpZW50IHJlZGlyZWN0aW9uIFVSSQogICBvciBlbmxpc3Rp bmcgdGhlIHJlc291cmNlIG93bmVyIHRvIGNvbmZpcm0gaWRlbnRpdHkuICBBIHZhbGlkCiAgIHJl ZGlyZWN0aW9uIFVSSSBpcyBub3Qgc3VmZmljaWVudCB0byB2ZXJpZnkgdGhlIGNsaWVudCdzIGlk ZW50aXR5CiAgIHdoZW4gYXNraW5nIGZvciByZXNvdXJjZSBvd25lciBhdXRob3JpemF0aW9uLCBi dXQgY2FuIGJlIHVzZWQgdG8KICAgcHJldmVudCBkZWxpdmVyaW5nIGNyZWRlbnRpYWxzIHRvIGEg Y291bnRlcmZlaXQgY2xpZW50IGFmdGVyCiAgIG9idGFpbmluZyByZXNvdXJjZSBvd25lciBhdXRo b3JpemF0aW9uLgoKICAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIG11c3QgY29uc2lkZXIgdGhl IHNlY3VyaXR5IGltcGxpY2F0aW9ucyBvZgogICBpbnRlcmFjdGluZyB3aXRoIHVuYXV0aGVudGlj YXRlZCBjbGllbnRzIGFuZCB0YWtlIG1lYXN1cmVzIHRvIGxpbWl0CiAgIHRoZSBwb3RlbnRpYWwg ZXhwb3N1cmUgb2Ygb3RoZXIgY3JlZGVudGlhbHMgKGUuZy4gcmVmcmVzaCB0b2tlbnMpCiAgIGlz c3VlZCB0byBzdWNoIGNsaWVudHMuCgoxMC4yLiAgQ2xpZW50IEltcGVyc29uYXRpb24KCiAgIEEg bWFsaWNpb3VzIGNsaWVudCBjYW4gaW1wZXJzb25hdGUgYW5vdGhlciBjbGllbnQgYW5kIG9idGFp biBhY2Nlc3MKICAgdG8gcHJvdGVjdGVkIHJlc291cmNlcywgaWYgdGhlIGltcGVyc29uYXRlZCBj bGllbnQgZmFpbHMgdG8sIG9yIGlzCiAgIHVuYWJsZSB0bywga2VlcCBpdHMgY2xpZW50IGNyZWRl bnRpYWxzIGNvbmZpZGVudGlhbC4KCiAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBNVVNUIGF1 dGhlbnRpY2F0ZSB0aGUgY2xpZW50IHdoZW5ldmVyCiAgIHBvc3NpYmxlLiAgSWYgdGhlIGF1dGhv cml6YXRpb24gc2VydmVyIGNhbm5vdCBhdXRoZW50aWNhdGUgdGhlIGNsaWVudAogICBkdWUgdG8g dGhlIGNsaWVudCdzIG5hdHVyZSwgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIE1VU1QgcmVxdWly ZSB0aGUKICAgcmVnaXN0cmF0aW9uIG9mIGFueSByZWRpcmVjdGlvbiBVUkkgdXNlZCBmb3IgcmVj ZWl2aW5nIGF1dGhvcml6YXRpb24KICAgcmVzcG9uc2VzLCBhbmQgU0hPVUxEIHV0aWxpemUgb3Ro ZXIgbWVhbnMgdG8gcHJvdGVjdCByZXNvdXJjZSBvd25lcnMKICAgZnJvbSBzdWNoIHBvdGVudGlh bGx5IG1hbGljaW91cyBjbGllbnRzLiAgRm9yIGV4YW1wbGUsIHRoZQogICBhdXRob3JpemF0aW9u IHNlcnZlciBjYW4gZW5nYWdlIHRoZSByZXNvdXJjZSBvd25lciB0byBhc3Npc3QgaW4KICAgaWRl bnRpZnlpbmcgdGhlIGNsaWVudCBhbmQgaXRzIG9yaWdpbi4KCgoKSGFtbWVyLCBldCBhbC4gICAg ICAgICAgRXhwaXJlcyBEZWNlbWJlciAyMCwgMjAxMiAgICAgICAgICAgICAgW1BhZ2UgNTBdCgwK SW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICBPQXV0aCAyLjAgICAgICAgICAgICAgICAg ICAgICAgSnVuZSAyMDEyCgoKICAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIFNIT1VMRCBlbmZv cmNlIGV4cGxpY2l0IHJlc291cmNlIG93bmVyCiAgIGF1dGhlbnRpY2F0aW9uIGFuZCBwcm92aWRl IHRoZSByZXNvdXJjZSBvd25lciB3aXRoIGluZm9ybWF0aW9uIGFib3V0CiAgIHRoZSBjbGllbnQg YW5kIHRoZSByZXF1ZXN0ZWQgYXV0aG9yaXphdGlvbiBzY29wZSBhbmQgbGlmZXRpbWUuICBJdCBp cwogICB1cCB0byB0aGUgcmVzb3VyY2Ugb3duZXIgdG8gcmV2aWV3IHRoZSBpbmZvcm1hdGlvbiBp biB0aGUgY29udGV4dCBvZgogICB0aGUgY3VycmVudCBjbGllbnQsIGFuZCBhdXRob3JpemUgb3Ig ZGVueSB0aGUgcmVxdWVzdC4KCiAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBTSE9VTEQgTk9U IHByb2Nlc3MgcmVwZWF0ZWQgYXV0aG9yaXphdGlvbgogICByZXF1ZXN0cyBhdXRvbWF0aWNhbGx5 ICh3aXRob3V0IGFjdGl2ZSByZXNvdXJjZSBvd25lciBpbnRlcmFjdGlvbikKICAgd2l0aG91dCBh dXRoZW50aWNhdGluZyB0aGUgY2xpZW50IG9yIHJlbHlpbmcgb24gb3RoZXIgbWVhc3VyZXMgdG8K ICAgZW5zdXJlIHRoZSByZXBlYXRlZCByZXF1ZXN0IGNvbWVzIGZyb20gdGhlIG9yaWdpbmFsIGNs aWVudCBhbmQgbm90IGFuCiAgIGltcGVyc29uYXRvci4KCjEwLjMuICBBY2Nlc3MgVG9rZW5zCgog ICBBY2Nlc3MgdG9rZW4gY3JlZGVudGlhbHMgKGFzIHdlbGwgYXMgYW55IGNvbmZpZGVudGlhbCBh Y2Nlc3MgdG9rZW4KICAgYXR0cmlidXRlcykgTVVTVCBiZSBrZXB0IGNvbmZpZGVudGlhbCBpbiB0 cmFuc2l0IGFuZCBzdG9yYWdlLCBhbmQKICAgb25seSBzaGFyZWQgYW1vbmcgdGhlIGF1dGhvcml6 YXRpb24gc2VydmVyLCB0aGUgcmVzb3VyY2Ugc2VydmVycyB0aGUKICAgYWNjZXNzIHRva2VuIGlz IHZhbGlkIGZvciwgYW5kIHRoZSBjbGllbnQgdG8gd2hvbSB0aGUgYWNjZXNzIHRva2VuIGlzCiAg IGlzc3VlZC4gIEFjY2VzcyB0b2tlbiBjcmVkZW50aWFscyBNVVNUIG9ubHkgYmUgdHJhbnNtaXR0 ZWQgdXNpbmcgVExTCiAgIGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDEuNiB3aXRoIHNlcnZlciBh dXRoZW50aWNhdGlvbiBhcyBkZWZpbmVkIGJ5CiAgIFtSRkMyODE4XS4KCiAgIFdoZW4gdXNpbmcg dGhlIGltcGxpY2l0IGdyYW50IHR5cGUsIHRoZSBhY2Nlc3MgdG9rZW4gaXMgdHJhbnNtaXR0ZWQK ICAgaW4gdGhlIFVSSSBmcmFnbWVudCwgd2hpY2ggY2FuIGV4cG9zZSBpdCB0byB1bmF1dGhvcml6 ZWQgcGFydGllcy4KCiAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBNVVNUIGVuc3VyZSB0aGF0 IGFjY2VzcyB0b2tlbnMgY2Fubm90IGJlCiAgIGdlbmVyYXRlZCwgbW9kaWZpZWQsIG9yIGd1ZXNz ZWQgdG8gcHJvZHVjZSB2YWxpZCBhY2Nlc3MgdG9rZW5zIGJ5CiAgIHVuYXV0aG9yaXplZCBwYXJ0 aWVzLgoKICAgVGhlIGNsaWVudCBTSE9VTEQgcmVxdWVzdCBhY2Nlc3MgdG9rZW5zIHdpdGggdGhl IG1pbmltYWwgc2NvcGUKICAgbmVjZXNzYXJ5LiAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIFNI T1VMRCB0YWtlIHRoZSBjbGllbnQgaWRlbnRpdHkKICAgaW50byBhY2NvdW50IHdoZW4gY2hvb3Np bmcgaG93IHRvIGhvbm9yIHRoZSByZXF1ZXN0ZWQgc2NvcGUsIGFuZCBNQVkKICAgaXNzdWUgYW4g YWNjZXNzIHRva2VuIHdpdGggYSBsZXNzIHJpZ2h0cyB0aGFuIHJlcXVlc3RlZC4KCiAgIFRoaXMg c3BlY2lmaWNhdGlvbiBkb2VzIG5vdCBwcm92aWRlIGFueSBtZXRob2RzIGZvciB0aGUgcmVzb3Vy Y2UKICAgc2VydmVyIHRvIGVuc3VyZSB0aGF0IGFuIGFjY2VzcyB0b2tlbiBwcmVzZW50ZWQgdG8g aXQgYnkgYSBnaXZlbgogICBjbGllbnQgd2FzIGlzc3VlZCB0byB0aGF0IGNsaWVudCBieSB0aGUg YXV0aG9yaXphdGlvbiBzZXJ2ZXIuCgoxMC40LiAgUmVmcmVzaCBUb2tlbnMKCiAgIEF1dGhvcml6 YXRpb24gc2VydmVycyBNQVkgaXNzdWUgcmVmcmVzaCB0b2tlbnMgdG8gd2ViIGFwcGxpY2F0aW9u CiAgIGNsaWVudHMgYW5kIG5hdGl2ZSBhcHBsaWNhdGlvbiBjbGllbnRzLgoKICAgUmVmcmVzaCB0 b2tlbnMgTVVTVCBiZSBrZXB0IGNvbmZpZGVudGlhbCBpbiB0cmFuc2l0IGFuZCBzdG9yYWdlLCBh bmQKICAgc2hhcmVkIG9ubHkgYW1vbmcgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGFuZCB0aGUg Y2xpZW50IHRvIHdob20gdGhlCiAgIHJlZnJlc2ggdG9rZW5zIHdlcmUgaXNzdWVkLiAgVGhlIGF1 dGhvcml6YXRpb24gc2VydmVyIE1VU1QgbWFpbnRhaW4KICAgdGhlIGJpbmRpbmcgYmV0d2VlbiBh IHJlZnJlc2ggdG9rZW4gYW5kIHRoZSBjbGllbnQgdG8gd2hvbSBpdCB3YXMKICAgaXNzdWVkLiAg UmVmcmVzaCB0b2tlbnMgTVVTVCBvbmx5IGJlIHRyYW5zbWl0dGVkIHVzaW5nIFRMUyBhcwoKCgpI YW1tZXIsIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIERlY2VtYmVyIDIwLCAyMDEyICAgICAgICAg ICAgICBbUGFnZSA1MV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgIE9BdXRoIDIu MCAgICAgICAgICAgICAgICAgICAgICBKdW5lIDIwMTIKCgogICBkZXNjcmliZWQgaW4gU2VjdGlv biAxLjYgd2l0aCBzZXJ2ZXIgYXV0aGVudGljYXRpb24gYXMgZGVmaW5lZCBieQogICBbUkZDMjgx OF0uCgogICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVTVCB2ZXJpZnkgdGhlIGJpbmRpbmcg YmV0d2VlbiB0aGUgcmVmcmVzaAogICB0b2tlbiBhbmQgY2xpZW50IGlkZW50aXR5IHdoZW5ldmVy IHRoZSBjbGllbnQgaWRlbnRpdHkgY2FuIGJlCiAgIGF1dGhlbnRpY2F0ZWQuICBXaGVuIGNsaWVu dCBhdXRoZW50aWNhdGlvbiBpcyBub3QgcG9zc2libGUsIHRoZQogICBhdXRob3JpemF0aW9uIHNl cnZlciBTSE9VTEQgZGVwbG95IG90aGVyIG1lYW5zIHRvIGRldGVjdCByZWZyZXNoCiAgIHRva2Vu IGFidXNlLgoKICAgRm9yIGV4YW1wbGUsIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBjb3VsZCBl bXBsb3kgcmVmcmVzaCB0b2tlbgogICByb3RhdGlvbiBpbiB3aGljaCBhIG5ldyByZWZyZXNoIHRv a2VuIGlzIGlzc3VlZCB3aXRoIGV2ZXJ5IGFjY2VzcwogICB0b2tlbiByZWZyZXNoIHJlc3BvbnNl LiAgVGhlIHByZXZpb3VzIHJlZnJlc2ggdG9rZW4gaXMgaW52YWxpZGF0ZWQKICAgYnV0IHJldGFp bmVkIGJ5IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlci4gIElmIGEgcmVmcmVzaCB0b2tlbiBpcwog ICBjb21wcm9taXNlZCBhbmQgc3Vic2VxdWVudGx5IHVzZWQgYnkgYm90aCB0aGUgYXR0YWNrZXIg YW5kIHRoZQogICBsZWdpdGltYXRlIGNsaWVudCwgb25lIG9mIHRoZW0gd2lsbCBwcmVzZW50IGFu IGludmFsaWRhdGVkIHJlZnJlc2gKICAgdG9rZW4gd2hpY2ggd2lsbCBpbmZvcm0gdGhlIGF1dGhv cml6YXRpb24gc2VydmVyIG9mIHRoZSBicmVhY2guCgogICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2 ZXIgTVVTVCBlbnN1cmUgdGhhdCByZWZyZXNoIHRva2VucyBjYW5ub3QgYmUKICAgZ2VuZXJhdGVk LCBtb2RpZmllZCwgb3IgZ3Vlc3NlZCB0byBwcm9kdWNlIHZhbGlkIHJlZnJlc2ggdG9rZW5zIGJ5 CiAgIHVuYXV0aG9yaXplZCBwYXJ0aWVzLgoKMTAuNS4gIEF1dGhvcml6YXRpb24gQ29kZXMKCiAg IFRoZSB0cmFuc21pc3Npb24gb2YgYXV0aG9yaXphdGlvbiBjb2RlcyBTSE9VTEQgYmUgbWFkZSBv dmVyIGEgc2VjdXJlCiAgIGNoYW5uZWwsIGFuZCB0aGUgY2xpZW50IFNIT1VMRCByZXF1aXJlIHRo ZSB1c2Ugb2YgVExTIHdpdGggaXRzCiAgIHJlZGlyZWN0aW9uIFVSSSBpZiB0aGUgVVJJIGlkZW50 aWZpZXMgYSBuZXR3b3JrIHJlc291cmNlLiAgU2luY2UKICAgYXV0aG9yaXphdGlvbiBjb2RlcyBh cmUgdHJhbnNtaXR0ZWQgdmlhIHVzZXItYWdlbnQgcmVkaXJlY3Rpb25zLCB0aGV5CiAgIGNvdWxk IHBvdGVudGlhbGx5IGJlIGRpc2Nsb3NlZCB0aHJvdWdoIHVzZXItYWdlbnQgaGlzdG9yeSBhbmQg SFRUUAogICByZWZlcnJlciBoZWFkZXJzLgoKICAgQXV0aG9yaXphdGlvbiBjb2RlcyBvcGVyYXRl IGFzIHBsYWludGV4dCBiZWFyZXIgY3JlZGVudGlhbHMsIHVzZWQgdG8KICAgdmVyaWZ5IHRoYXQg dGhlIHJlc291cmNlIG93bmVyIHdobyBncmFudGVkIGF1dGhvcml6YXRpb24gYXQgdGhlCiAgIGF1 dGhvcml6YXRpb24gc2VydmVyIGlzIHRoZSBzYW1lIHJlc291cmNlIG93bmVyIHJldHVybmluZyB0 byB0aGUKICAgY2xpZW50IHRvIGNvbXBsZXRlIHRoZSBwcm9jZXNzLiAgVGhlcmVmb3JlLCBpZiB0 aGUgY2xpZW50IHJlbGllcyBvbgogICB0aGUgYXV0aG9yaXphdGlvbiBjb2RlIGZvciBpdHMgb3du IHJlc291cmNlIG93bmVyIGF1dGhlbnRpY2F0aW9uLCB0aGUKICAgY2xpZW50IHJlZGlyZWN0aW9u IGVuZHBvaW50IE1VU1QgcmVxdWlyZSB0aGUgdXNlIG9mIFRMUy4KCiAgIEF1dGhvcml6YXRpb24g Y29kZXMgTVVTVCBiZSBzaG9ydCBsaXZlZCBhbmQgc2luZ2xlIHVzZS4gIElmIHRoZQogICBhdXRo b3JpemF0aW9uIHNlcnZlciBvYnNlcnZlcyBtdWx0aXBsZSBhdHRlbXB0cyB0byBleGNoYW5nZSBh bgogICBhdXRob3JpemF0aW9uIGNvZGUgZm9yIGFuIGFjY2VzcyB0b2tlbiwgdGhlIGF1dGhvcml6 YXRpb24gc2VydmVyCiAgIFNIT1VMRCBhdHRlbXB0IHRvIHJldm9rZSBhbGwgYWNjZXNzIHRva2Vu cyBhbHJlYWR5IGdyYW50ZWQgYmFzZWQgb24KICAgdGhlIGNvbXByb21pc2VkIGF1dGhvcml6YXRp b24gY29kZS4KCiAgIElmIHRoZSBjbGllbnQgY2FuIGJlIGF1dGhlbnRpY2F0ZWQsIHRoZSBhdXRo b3JpemF0aW9uIHNlcnZlcnMgTVVTVAogICBhdXRoZW50aWNhdGUgdGhlIGNsaWVudCBhbmQgZW5z dXJlIHRoYXQgdGhlIGF1dGhvcml6YXRpb24gY29kZSB3YXMKICAgaXNzdWVkIHRvIHRoZSBzYW1l IGNsaWVudC4KCgoKCgpIYW1tZXIsIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIERlY2VtYmVyIDIw LCAyMDEyICAgICAgICAgICAgICBbUGFnZSA1Ml0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAg ICAgICAgIE9BdXRoIDIuMCAgICAgICAgICAgICAgICAgICAgICBKdW5lIDIwMTIKCgoxMC42LiAg QXV0aG9yaXphdGlvbiBDb2RlIFJlZGlyZWN0aW9uIFVSSSBNYW5pcHVsYXRpb24KCiAgIFdoZW4g cmVxdWVzdGluZyBhdXRob3JpemF0aW9uIHVzaW5nIHRoZSBhdXRob3JpemF0aW9uIGNvZGUgZ3Jh bnQKICAgdHlwZSwgdGhlIGNsaWVudCBjYW4gc3BlY2lmeSBhIHJlZGlyZWN0aW9uIFVSSSB2aWEg dGhlICJyZWRpcmVjdF91cmkiCiAgIHBhcmFtZXRlci4gIElmIGFuIGF0dGFja2VyIGNhbiBtYW5p cHVsYXRlIHRoZSB2YWx1ZSBvZiB0aGUKICAgcmVkaXJlY3Rpb24gVVJJLCBpdCBjYW4gY2F1c2Ug dGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHRvIHJlZGlyZWN0CiAgIHRoZSByZXNvdXJjZSBvd25l ciB1c2VyLWFnZW50IHRvIGEgVVJJIHVuZGVyIHRoZSBjb250cm9sIG9mIHRoZQogICBhdHRhY2tl ciB3aXRoIHRoZSBhdXRob3JpemF0aW9uIGNvZGUuCgogICBBbiBhdHRhY2tlciBjYW4gY3JlYXRl IGFuIGFjY291bnQgYXQgYSBsZWdpdGltYXRlIGNsaWVudCBhbmQgaW5pdGlhdGUKICAgdGhlIGF1 dGhvcml6YXRpb24gZmxvdy4gIFdoZW4gdGhlIGF0dGFja2VyJ3MgdXNlci1hZ2VudCBpcyBzZW50 IHRvCiAgIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciB0byBncmFudCBhY2Nlc3MsIHRoZSBhdHRh Y2tlciBncmFicyB0aGUKICAgYXV0aG9yaXphdGlvbiBVUkkgcHJvdmlkZWQgYnkgdGhlIGxlZ2l0 aW1hdGUgY2xpZW50LCBhbmQgcmVwbGFjZXMgdGhlCiAgIGNsaWVudCdzIHJlZGlyZWN0aW9uIFVS SSB3aXRoIGEgVVJJIHVuZGVyIHRoZSBjb250cm9sIG9mIHRoZQogICBhdHRhY2tlci4gIFRoZSBh dHRhY2tlciB0aGVuIHRyaWNrcyB0aGUgdmljdGltIGludG8gZm9sbG93aW5nIHRoZQogICBtYW5p cHVsYXRlZCBsaW5rIHRvIGF1dGhvcml6ZSBhY2Nlc3MgdG8gdGhlIGxlZ2l0aW1hdGUgY2xpZW50 LgoKICAgT25jZSBhdCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIsIHRoZSB2aWN0aW0gaXMgcHJv bXB0ZWQgd2l0aCBhCiAgIG5vcm1hbCwgdmFsaWQgcmVxdWVzdCBvbiBiZWhhbGYgb2YgYSBsZWdp dGltYXRlIGFuZCB0cnVzdGVkIGNsaWVudCwKICAgYW5kIGF1dGhvcml6ZXMgdGhlIHJlcXVlc3Qu ICBUaGUgdmljdGltIGlzIHRoZW4gcmVkaXJlY3RlZCB0byBhbgogICBlbmRwb2ludCB1bmRlciB0 aGUgY29udHJvbCBvZiB0aGUgYXR0YWNrZXIgd2l0aCB0aGUgYXV0aG9yaXphdGlvbgogICBjb2Rl LiAgVGhlIGF0dGFja2VyIGNvbXBsZXRlcyB0aGUgYXV0aG9yaXphdGlvbiBmbG93IGJ5IHNlbmRp bmcgdGhlCiAgIGF1dGhvcml6YXRpb24gY29kZSB0byB0aGUgY2xpZW50IHVzaW5nIHRoZSBvcmln aW5hbCByZWRpcmVjdGlvbiBVUkkKICAgcHJvdmlkZWQgYnkgdGhlIGNsaWVudC4gIFRoZSBjbGll bnQgZXhjaGFuZ2VzIHRoZSBhdXRob3JpemF0aW9uIGNvZGUKICAgd2l0aCBhbiBhY2Nlc3MgdG9r ZW4gYW5kIGxpbmtzIGl0IHRvIHRoZSBhdHRhY2tlcidzIGNsaWVudCBhY2NvdW50CiAgIHdoaWNo IGNhbiBub3cgZ2FpbiBhY2Nlc3MgdG8gdGhlIHByb3RlY3RlZCByZXNvdXJjZXMgYXV0aG9yaXpl ZCBieQogICB0aGUgdmljdGltICh2aWEgdGhlIGNsaWVudCkuCgogICBJbiBvcmRlciB0byBwcmV2 ZW50IHN1Y2ggYW4gYXR0YWNrLCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVTVAogICBlbnN1 cmUgdGhhdCB0aGUgcmVkaXJlY3Rpb24gVVJJIHVzZWQgdG8gb2J0YWluIHRoZSBhdXRob3JpemF0 aW9uIGNvZGUKICAgaXMgaWRlbnRpY2FsIHRvIHRoZSByZWRpcmVjdGlvbiBVUkkgcHJvdmlkZWQg d2hlbiBleGNoYW5naW5nIHRoZQogICBhdXRob3JpemF0aW9uIGNvZGUgZm9yIGFuIGFjY2VzcyB0 b2tlbi4gIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlcgogICBNVVNUIHJlcXVpcmUgcHVibGljIGNs aWVudHMgYW5kIFNIT1VMRCByZXF1aXJlIGNvbmZpZGVudGlhbCBjbGllbnRzCiAgIHRvIHJlZ2lz dGVyIHRoZWlyIHJlZGlyZWN0aW9uIFVSSXMuICBJZiBhIHJlZGlyZWN0aW9uIFVSSSBpcyBwcm92 aWRlZAogICBpbiB0aGUgcmVxdWVzdCwgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIE1VU1QgdmFs aWRhdGUgaXQgYWdhaW5zdCB0aGUKICAgcmVnaXN0ZXJlZCB2YWx1ZS4KCjEwLjcuICBSZXNvdXJj ZSBPd25lciBQYXNzd29yZCBDcmVkZW50aWFscwoKICAgVGhlIHJlc291cmNlIG93bmVyIHBhc3N3 b3JkIGNyZWRlbnRpYWxzIGdyYW50IHR5cGUgaXMgb2Z0ZW4gdXNlZCBmb3IKICAgbGVnYWN5IG9y IG1pZ3JhdGlvbiByZWFzb25zLiAgSXQgcmVkdWNlcyB0aGUgb3ZlcmFsbCByaXNrIG9mIHN0b3Jp bmcKICAgdXNlcm5hbWUgYW5kIHBhc3N3b3JkIGJ5IHRoZSBjbGllbnQsIGJ1dCBkb2VzIG5vdCBl bGltaW5hdGUgdGhlIG5lZWQKICAgdG8gZXhwb3NlIGhpZ2hseSBwcml2aWxlZ2VkIGNyZWRlbnRp YWxzIHRvIHRoZSBjbGllbnQuCgogICBUaGlzIGdyYW50IHR5cGUgY2FycmllcyBhIGhpZ2hlciBy aXNrIHRoYW4gb3RoZXIgZ3JhbnQgdHlwZXMgYmVjYXVzZQogICBpdCBtYWludGFpbnMgdGhlIHBh c3N3b3JkIGFudGktcGF0dGVybiB0aGlzIHByb3RvY29sIHNlZWtzIHRvIGF2b2lkLgogICBUaGUg Y2xpZW50IGNvdWxkIGFidXNlIHRoZSBwYXNzd29yZCBvciB0aGUgcGFzc3dvcmQgY291bGQKICAg dW5pbnRlbnRpb25hbGx5IGJlIGRpc2Nsb3NlZCB0byBhbiBhdHRhY2tlciAoZS5nLiB2aWEgbG9n IGZpbGVzIG9yCgoKCkhhbW1lciwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgRGVjZW1iZXIgMjAs IDIwMTIgICAgICAgICAgICAgIFtQYWdlIDUzXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAg ICAgICAgT0F1dGggMi4wICAgICAgICAgICAgICAgICAgICAgIEp1bmUgMjAxMgoKCiAgIG90aGVy IHJlY29yZHMga2VwdCBieSB0aGUgY2xpZW50KS4KCiAgIEFkZGl0aW9uYWxseSwgYmVjYXVzZSB0 aGUgcmVzb3VyY2Ugb3duZXIgZG9lcyBub3QgaGF2ZSBjb250cm9sIG92ZXIKICAgdGhlIGF1dGhv cml6YXRpb24gcHJvY2VzcyAodGhlIHJlc291cmNlIG93bmVyIGludm9sdmVtZW50IGVuZHMgd2hl bgogICBpdCBoYW5kcyBvdmVyIGl0cyBjcmVkZW50aWFscyB0byB0aGUgY2xpZW50KSwgdGhlIGNs aWVudCBjYW4gb2J0YWluCiAgIGFjY2VzcyB0b2tlbnMgd2l0aCBhIGJyb2FkZXIgc2NvcGUgdGhh biBkZXNpcmVkIGJ5IHRoZSByZXNvdXJjZQogICBvd25lci4gIFRoZSBhdXRob3JpemF0aW9uIHNl cnZlciBzaG91bGQgY29uc2lkZXIgdGhlIHNjb3BlIGFuZAogICBsaWZldGltZSBvZiBhY2Nlc3Mg dG9rZW5zIGlzc3VlZCB2aWEgdGhpcyBncmFudCB0eXBlLgoKICAgVGhlIGF1dGhvcml6YXRpb24g c2VydmVyIGFuZCBjbGllbnQgU0hPVUxEIG1pbmltaXplIHVzZSBvZiB0aGlzIGdyYW50CiAgIHR5 cGUgYW5kIHV0aWxpemUgb3RoZXIgZ3JhbnQgdHlwZXMgd2hlbmV2ZXIgcG9zc2libGUuCgoxMC44 LiAgUmVxdWVzdCBDb25maWRlbnRpYWxpdHkKCiAgIEFjY2VzcyB0b2tlbnMsIHJlZnJlc2ggdG9r ZW5zLCByZXNvdXJjZSBvd25lciBwYXNzd29yZHMsIGFuZCBjbGllbnQKICAgY3JlZGVudGlhbHMg TVVTVCBOT1QgYmUgdHJhbnNtaXR0ZWQgaW4gdGhlIGNsZWFyLiAgQXV0aG9yaXphdGlvbgogICBj b2RlcyBTSE9VTEQgTk9UIGJlIHRyYW5zbWl0dGVkIGluIHRoZSBjbGVhci4KCiAgIFRoZSAic3Rh dGUiIGFuZCAic2NvcGUiIHBhcmFtZXRlcnMgU0hPVUxEIE5PVCBpbmNsdWRlIHNlbnNpdGl2ZQog ICBjbGllbnQgb3IgcmVzb3VyY2Ugb3duZXIgaW5mb3JtYXRpb24gaW4gcGxhaW4gdGV4dCBhcyB0 aGV5IGNhbiBiZQogICB0cmFuc21pdHRlZCBvdmVyIGluc2VjdXJlIGNoYW5uZWxzIG9yIHN0b3Jl ZCBpbnNlY3VyZWx5LgoKMTAuOS4gIEVuZHBvaW50cyBBdXRoZW50aWNpdHkKCiAgIEluIG9yZGVy IHRvIHByZXZlbnQgbWFuLWluLXRoZS1taWRkbGUgYXR0YWNrcywgdGhlIGF1dGhvcml6YXRpb24K ICAgc2VydmVyIE1VU1QgcmVxdWlyZSB0aGUgdXNlIG9mIFRMUyB3aXRoIHNlcnZlciBhdXRoZW50 aWNhdGlvbiBhcwogICBkZWZpbmVkIGJ5IFtSRkMyODE4XSBmb3IgYW55IHJlcXVlc3Qgc2VudCB0 byB0aGUgYXV0aG9yaXphdGlvbiBhbmQKICAgdG9rZW4gZW5kcG9pbnRzLiAgVGhlIGNsaWVudCBN VVNUIHZhbGlkYXRlIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlcidzCiAgIFRMUyBjZXJ0aWZpY2F0 ZSBhcyBkZWZpbmVkIGJ5IFtSRkM2MTI1XSwgYW5kIGluIGFjY29yZGFuY2Ugd2l0aCBpdHMKICAg cmVxdWlyZW1lbnRzIGZvciBzZXJ2ZXIgaWRlbnRpdHkgYXV0aGVudGljYXRpb24uCgoxMC4xMC4g IENyZWRlbnRpYWxzIEd1ZXNzaW5nIEF0dGFja3MKCiAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZl ciBNVVNUIHByZXZlbnQgYXR0YWNrZXJzIGZyb20gZ3Vlc3NpbmcgYWNjZXNzCiAgIHRva2Vucywg YXV0aG9yaXphdGlvbiBjb2RlcywgcmVmcmVzaCB0b2tlbnMsIHJlc291cmNlIG93bmVyCiAgIHBh c3N3b3JkcywgYW5kIGNsaWVudCBjcmVkZW50aWFscy4KCiAgIFRoZSBwcm9iYWJpbGl0eSBvZiBh biBhdHRhY2tlciBndWVzc2luZyBnZW5lcmF0ZWQgdG9rZW5zIChhbmQgb3RoZXIKICAgY3JlZGVu dGlhbHMgbm90IGludGVuZGVkIGZvciBoYW5kbGluZyBieSBlbmQtdXNlcnMpIE1VU1QgYmUgbGVz cyB0aGFuCiAgIG9yIGVxdWFsIHRvIDJeKC0xMjgpIGFuZCBTSE9VTEQgYmUgbGVzcyB0aGFuIG9y IGVxdWFsIHRvIDJeKC0xNjApLgoKICAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIE1VU1QgdXRp bGl6ZSBvdGhlciBtZWFucyB0byBwcm90ZWN0CiAgIGNyZWRlbnRpYWxzIGludGVuZGVkIGZvciBl bmQtdXNlciB1c2FnZS4KCjEwLjExLiAgUGhpc2hpbmcgQXR0YWNrcwoKICAgV2lkZSBkZXBsb3lt ZW50IG9mIHRoaXMgYW5kIHNpbWlsYXIgcHJvdG9jb2xzIG1heSBjYXVzZSBlbmQtdXNlcnMgdG8K ICAgYmVjb21lIGludXJlZCB0byB0aGUgcHJhY3RpY2Ugb2YgYmVpbmcgcmVkaXJlY3RlZCB0byB3 ZWJzaXRlcyB3aGVyZQoKCgpIYW1tZXIsIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIERlY2VtYmVy IDIwLCAyMDEyICAgICAgICAgICAgICBbUGFnZSA1NF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAg ICAgICAgICAgIE9BdXRoIDIuMCAgICAgICAgICAgICAgICAgICAgICBKdW5lIDIwMTIKCgogICB0 aGV5IGFyZSBhc2tlZCB0byBlbnRlciB0aGVpciBwYXNzd29yZHMuICBJZiBlbmQtdXNlcnMgYXJl IG5vdAogICBjYXJlZnVsIHRvIHZlcmlmeSB0aGUgYXV0aGVudGljaXR5IG9mIHRoZXNlIHdlYnNp dGVzIGJlZm9yZSBlbnRlcmluZwogICB0aGVpciBjcmVkZW50aWFscywgaXQgd2lsbCBiZSBwb3Nz aWJsZSBmb3IgYXR0YWNrZXJzIHRvIGV4cGxvaXQgdGhpcwogICBwcmFjdGljZSB0byBzdGVhbCBy ZXNvdXJjZSBvd25lcnMnIHBhc3N3b3Jkcy4KCiAgIFNlcnZpY2UgcHJvdmlkZXJzIHNob3VsZCBh dHRlbXB0IHRvIGVkdWNhdGUgZW5kLXVzZXJzIGFib3V0IHRoZSByaXNrcwogICBwaGlzaGluZyBh dHRhY2tzIHBvc2UsIGFuZCBzaG91bGQgcHJvdmlkZSBtZWNoYW5pc21zIHRoYXQgbWFrZSBpdAog ICBlYXN5IGZvciBlbmQtdXNlcnMgdG8gY29uZmlybSB0aGUgYXV0aGVudGljaXR5IG9mIHRoZWly IHNpdGVzLgogICBDbGllbnQgZGV2ZWxvcGVycyBzaG91bGQgY29uc2lkZXIgdGhlIHNlY3VyaXR5 IGltcGxpY2F0aW9ucyBvZiBob3cKICAgdGhleSBpbnRlcmFjdCB3aXRoIHRoZSB1c2VyLWFnZW50 IChlLmcuLCBleHRlcm5hbCwgZW1iZWRkZWQpLCBhbmQgdGhlCiAgIGFiaWxpdHkgb2YgdGhlIGVu ZC11c2VyIHRvIHZlcmlmeSB0aGUgYXV0aGVudGljaXR5IG9mIHRoZQogICBhdXRob3JpemF0aW9u IHNlcnZlci4KCiAgIFRvIHJlZHVjZSB0aGUgcmlzayBvZiBwaGlzaGluZyBhdHRhY2tzLCB0aGUg YXV0aG9yaXphdGlvbiBzZXJ2ZXJzCiAgIE1VU1QgcmVxdWlyZSB0aGUgdXNlIG9mIFRMUyBvbiBl dmVyeSBlbmRwb2ludCB1c2VkIGZvciBlbmQtdXNlcgogICBpbnRlcmFjdGlvbi4KCjEwLjEyLiAg Q3Jvc3MtU2l0ZSBSZXF1ZXN0IEZvcmdlcnkKCiAgIENyb3NzLXNpdGUgcmVxdWVzdCBmb3JnZXJ5 IChDU1JGKSBpcyBhbiBleHBsb2l0IGluIHdoaWNoIGFuIGF0dGFja2VyCiAgIGNhdXNlcyB0aGUg dXNlci1hZ2VudCBvZiBhIHZpY3RpbSBlbmQtdXNlciB0byBmb2xsb3cgYSBtYWxpY2lvdXMgVVJJ CiAgIChlLmcuIHByb3ZpZGVkIHRvIHRoZSB1c2VyLWFnZW50IGFzIGEgbWlzbGVhZGluZyBsaW5r LCBpbWFnZSwgb3IKICAgcmVkaXJlY3Rpb24pIHRvIGEgdHJ1c3Rpbmcgc2VydmVyICh1c3VhbGx5 IGVzdGFibGlzaGVkIHZpYSB0aGUKICAgcHJlc2VuY2Ugb2YgYSB2YWxpZCBzZXNzaW9uIGNvb2tp ZSkuCgogICBBIENTUkYgYXR0YWNrIGFnYWluc3QgdGhlIGNsaWVudCdzIHJlZGlyZWN0aW9uIFVS SSBhbGxvd3MgYW4gYXR0YWNrZXIKICAgdG8gaW5qZWN0IHRoZWlyIG93biBhdXRob3JpemF0aW9u IGNvZGUgb3IgYWNjZXNzIHRva2VuLCB3aGljaCBjYW4KICAgcmVzdWx0IGluIHRoZSBjbGllbnQg dXNpbmcgYW4gYWNjZXNzIHRva2VuIGFzc29jaWF0ZWQgd2l0aCB0aGUKICAgYXR0YWNrZXIncyBw cm90ZWN0ZWQgcmVzb3VyY2VzIHJhdGhlciB0aGFuIHRoZSB2aWN0aW0ncyAoZS5nLiBzYXZlCiAg IHRoZSB2aWN0aW0ncyBiYW5rIGFjY291bnQgaW5mb3JtYXRpb24gdG8gYSBwcm90ZWN0ZWQgcmVz b3VyY2UKICAgY29udHJvbGxlZCBieSB0aGUgYXR0YWNrZXIpLgoKICAgVGhlIGNsaWVudCBNVVNU IGltcGxlbWVudCBDU1JGIHByb3RlY3Rpb24gZm9yIGl0cyByZWRpcmVjdGlvbiBVUkkuCiAgIFRo aXMgaXMgdHlwaWNhbGx5IGFjY29tcGxpc2hlZCBieSByZXF1aXJpbmcgYW55IHJlcXVlc3Qgc2Vu dCB0byB0aGUKICAgcmVkaXJlY3Rpb24gVVJJIGVuZHBvaW50IHRvIGluY2x1ZGUgYSB2YWx1ZSB0 aGF0IGJpbmRzIHRoZSByZXF1ZXN0IHRvCiAgIHRoZSB1c2VyLWFnZW50J3MgYXV0aGVudGljYXRl ZCBzdGF0ZSAoZS5nLiBhIGhhc2ggb2YgdGhlIHNlc3Npb24KICAgY29va2llIHVzZWQgdG8gYXV0 aGVudGljYXRlIHRoZSB1c2VyLWFnZW50KS4gIFRoZSBjbGllbnQgU0hPVUxECiAgIHV0aWxpemUg dGhlICJzdGF0ZSIgcmVxdWVzdCBwYXJhbWV0ZXIgdG8gZGVsaXZlciB0aGlzIHZhbHVlIHRvIHRo ZQogICBhdXRob3JpemF0aW9uIHNlcnZlciB3aGVuIG1ha2luZyBhbiBhdXRob3JpemF0aW9uIHJl cXVlc3QuCgogICBPbmNlIGF1dGhvcml6YXRpb24gaGFzIGJlZW4gb2J0YWluZWQgZnJvbSB0aGUg ZW5kLXVzZXIsIHRoZQogICBhdXRob3JpemF0aW9uIHNlcnZlciByZWRpcmVjdHMgdGhlIGVuZC11 c2VyJ3MgdXNlci1hZ2VudCBiYWNrIHRvIHRoZQogICBjbGllbnQgd2l0aCB0aGUgcmVxdWlyZWQg YmluZGluZyB2YWx1ZSBjb250YWluZWQgaW4gdGhlICJzdGF0ZSIKICAgcGFyYW1ldGVyLiAgVGhl IGJpbmRpbmcgdmFsdWUgZW5hYmxlcyB0aGUgY2xpZW50IHRvIHZlcmlmeSB0aGUKICAgdmFsaWRp dHkgb2YgdGhlIHJlcXVlc3QgYnkgbWF0Y2hpbmcgdGhlIGJpbmRpbmcgdmFsdWUgdG8gdGhlIHVz ZXItCiAgIGFnZW50J3MgYXV0aGVudGljYXRlZCBzdGF0ZS4gIFRoZSBiaW5kaW5nIHZhbHVlIHVz ZWQgZm9yIENTUkYKICAgcHJvdGVjdGlvbiBNVVNUIGNvbnRhaW4gYSBub24tZ3Vlc3NhYmxlIHZh bHVlIChhcyBkZXNjcmliZWQgaW4KICAgU2VjdGlvbiAxMC4xMCksIGFuZCB0aGUgdXNlci1hZ2Vu dCdzIGF1dGhlbnRpY2F0ZWQgc3RhdGUgKGUuZy4KCgoKSGFtbWVyLCBldCBhbC4gICAgICAgICAg RXhwaXJlcyBEZWNlbWJlciAyMCwgMjAxMiAgICAgICAgICAgICAgW1BhZ2UgNTVdCgwKSW50ZXJu ZXQtRHJhZnQgICAgICAgICAgICAgICAgICBPQXV0aCAyLjAgICAgICAgICAgICAgICAgICAgICAg SnVuZSAyMDEyCgoKICAgc2Vzc2lvbiBjb29raWUsIEhUTUw1IGxvY2FsIHN0b3JhZ2UpIE1VU1Qg YmUga2VwdCBpbiBhIGxvY2F0aW9uCiAgIGFjY2Vzc2libGUgb25seSB0byB0aGUgY2xpZW50IGFu ZCB0aGUgdXNlci1hZ2VudCAoaS5lLiwgcHJvdGVjdGVkIGJ5CiAgIHNhbWUtb3JpZ2luIHBvbGlj eSkuCgogICBBIENTUkYgYXR0YWNrIGFnYWluc3QgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyJ3Mg YXV0aG9yaXphdGlvbgogICBlbmRwb2ludCBjYW4gcmVzdWx0IGluIGFuIGF0dGFja2VyIG9idGFp bmluZyBlbmQtdXNlciBhdXRob3JpemF0aW9uCiAgIGZvciBhIG1hbGljaW91cyBjbGllbnQgd2l0 aG91dCBpbnZvbHZpbmcgb3IgYWxlcnRpbmcgdGhlIGVuZC11c2VyLgoKICAgVGhlIGF1dGhvcml6 YXRpb24gc2VydmVyIE1VU1QgaW1wbGVtZW50IENTUkYgcHJvdGVjdGlvbiBmb3IgaXRzCiAgIGF1 dGhvcml6YXRpb24gZW5kcG9pbnQsIGFuZCBlbnN1cmUgdGhhdCBhIG1hbGljaW91cyBjbGllbnQg Y2Fubm90CiAgIG9idGFpbiBhdXRob3JpemF0aW9uIHdpdGhvdXQgdGhlIGF3YXJlbmVzcyBhbmQg ZXhwbGljaXQgY29uc2VudCBvZgogICB0aGUgcmVzb3VyY2Ugb3duZXIuCgoxMC4xMy4gIENsaWNr amFja2luZwoKICAgSW4gYSBjbGlja2phY2tpbmcgYXR0YWNrLCBhbiBhdHRhY2tlciByZWdpc3Rl cnMgYSBsZWdpdGltYXRlIGNsaWVudAogICBhbmQgdGhlbiBjb25zdHJ1Y3RzIGEgbWFsaWNpb3Vz IHNpdGUgaW4gd2hpY2ggaXQgbG9hZHMgdGhlCiAgIGF1dGhvcml6YXRpb24gc2VydmVyJ3MgYXV0 aG9yaXphdGlvbiBlbmRwb2ludCB3ZWIgcGFnZSBpbiBhCiAgIHRyYW5zcGFyZW50IGlmcmFtZSBv dmVybGFpZCBvbiB0b3Agb2YgYSBzZXQgb2YgZHVtbXkgYnV0dG9ucyB3aGljaAogICBhcmUgY2Fy ZWZ1bGx5IGNvbnN0cnVjdGVkIHRvIGJlIHBsYWNlZCBkaXJlY3RseSB1bmRlciBpbXBvcnRhbnQK ICAgYnV0dG9ucyBvbiB0aGUgYXV0aG9yaXphdGlvbiBwYWdlLiAgV2hlbiBhbiBlbmQtdXNlciBj bGlja3MgYQogICBtaXNsZWFkaW5nIHZpc2libGUgYnV0dG9uLCB0aGUgZW5kLXVzZXIgaXMgYWN0 dWFsbHkgY2xpY2tpbmcgYW4KICAgaW52aXNpYmxlIGJ1dHRvbiBvbiB0aGUgYXV0aG9yaXphdGlv biBwYWdlIChzdWNoIGFzIGFuICJBdXRob3JpemUiCiAgIGJ1dHRvbikuICBUaGlzIGFsbG93cyBh biBhdHRhY2tlciB0byB0cmljayBhIHJlc291cmNlIG93bmVyIGludG8KICAgZ3JhbnRpbmcgaXRz IGNsaWVudCBhY2Nlc3Mgd2l0aG91dCB0aGVpciBrbm93bGVkZ2UuCgogICBUbyBwcmV2ZW50IHRo aXMgZm9ybSBvZiBhdHRhY2ssIG5hdGl2ZSBhcHBsaWNhdGlvbnMgU0hPVUxEIHVzZQogICBleHRl cm5hbCBicm93c2VycyBpbnN0ZWFkIG9mIGVtYmVkZGluZyBicm93c2VycyB3aXRoaW4gdGhlCiAg IGFwcGxpY2F0aW9uIHdoZW4gcmVxdWVzdGluZyBlbmQtdXNlciBhdXRob3JpemF0aW9uLiAgRm9y IG1vc3QgbmV3ZXIKICAgYnJvd3NlcnMsIGF2b2lkYW5jZSBvZiBpZnJhbWVzIGNhbiBiZSBlbmZv cmNlZCBieSB0aGUgYXV0aG9yaXphdGlvbgogICBzZXJ2ZXIgdXNpbmcgdGhlIChub24tc3RhbmRh cmQpICJ4LWZyYW1lLW9wdGlvbnMiIGhlYWRlci4gIFRoaXMKICAgaGVhZGVyIGNhbiBoYXZlIHR3 byB2YWx1ZXMsICJkZW55IiBhbmQgInNhbWVvcmlnaW4iLCB3aGljaCB3aWxsIGJsb2NrCiAgIGFu eSBmcmFtaW5nLCBvciBmcmFtaW5nIGJ5IHNpdGVzIHdpdGggYSBkaWZmZXJlbnQgb3JpZ2luLAog ICByZXNwZWN0aXZlbHkuICBGb3Igb2xkZXIgYnJvd3NlcnMsIEphdmFTY3JpcHQgZnJhbWVidXN0 aW5nIHRlY2huaXF1ZXMKICAgY2FuIGJlIHVzZWQgYnV0IG1heSBub3QgYmUgZWZmZWN0aXZlIGlu IGFsbCBicm93c2Vycy4KCjEwLjE0LiAgQ29kZSBJbmplY3Rpb24gYW5kIElucHV0IFZhbGlkYXRp b24KCiAgIEEgY29kZSBpbmplY3Rpb24gYXR0YWNrIG9jY3VycyB3aGVuIGFuIGlucHV0IG9yIG90 aGVyd2lzZSBleHRlcm5hbAogICB2YXJpYWJsZSBpcyB1c2VkIGJ5IGFuIGFwcGxpY2F0aW9uIHVu c2FuaXRpemVkIGFuZCBjYXVzZXMKICAgbW9kaWZpY2F0aW9uIHRvIHRoZSBhcHBsaWNhdGlvbiBs b2dpYy4gIFRoaXMgbWF5IGFsbG93IGFuIGF0dGFja2VyIHRvCiAgIGdhaW4gYWNjZXNzIHRvIHRo ZSBhcHBsaWNhdGlvbiBkZXZpY2Ugb3IgaXRzIGRhdGEsIGNhdXNlIGRlbmlhbCBvZgogICBzZXJ2 aWNlLCBvciBhIHdpZGUgcmFuZ2Ugb2YgbWFsaWNpb3VzIHNpZGUtZWZmZWN0cy4KCiAgIFRoZSBB dXRob3JpemF0aW9uIHNlcnZlciBhbmQgY2xpZW50IE1VU1Qgc2FuaXRpemUgKGFuZCB2YWxpZGF0 ZSB3aGVuCiAgIHBvc3NpYmxlKSBhbnkgdmFsdWUgcmVjZWl2ZWQsIGluIHBhcnRpY3VsYXIsIHRo ZSB2YWx1ZSBvZiB0aGUgInN0YXRlIgogICBhbmQgInJlZGlyZWN0X3VyaSIgcGFyYW1ldGVycy4K CgoKCkhhbW1lciwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgRGVjZW1iZXIgMjAsIDIwMTIgICAg ICAgICAgICAgIFtQYWdlIDU2XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgT0F1 dGggMi4wICAgICAgICAgICAgICAgICAgICAgIEp1bmUgMjAxMgoKCjEwLjE1LiAgT3BlbiBSZWRp cmVjdG9ycwoKICAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGF1dGhvcml6YXRpb24gZW5kcG9p bnQgYW5kIHRoZSBjbGllbnQKICAgcmVkaXJlY3Rpb24gZW5kcG9pbnQgY2FuIGJlIGltcHJvcGVy bHkgY29uZmlndXJlZCBhbmQgb3BlcmF0ZSBhcyBvcGVuCiAgIHJlZGlyZWN0b3JzLiAgQW4gb3Bl biByZWRpcmVjdG9yIGlzIGFuIGVuZHBvaW50IHVzaW5nIGEgcGFyYW1ldGVyIHRvCiAgIGF1dG9t YXRpY2FsbHkgcmVkaXJlY3QgYSB1c2VyLWFnZW50IHRvIHRoZSBsb2NhdGlvbiBzcGVjaWZpZWQg YnkgdGhlCiAgIHBhcmFtZXRlciB2YWx1ZSB3aXRob3V0IGFueSB2YWxpZGF0aW9uLgoKICAgT3Bl biByZWRpcmVjdG9ycyBjYW4gYmUgdXNlZCBpbiBwaGlzaGluZyBhdHRhY2tzLCBvciBieSBhbiBh dHRhY2tlcgogICB0byBnZXQgZW5kLXVzZXJzIHRvIHZpc2l0IG1hbGljaW91cyBzaXRlcyBieSBt YWtpbmcgdGhlIFVSSSdzCiAgIGF1dGhvcml0eSBsb29rIGxpa2UgYSBmYW1pbGlhciBhbmQgdHJ1 c3RlZCBkZXN0aW5hdGlvbi4gIEluIGFkZGl0aW9uLAogICBpZiB0aGUgYXV0aG9yaXphdGlvbiBz ZXJ2ZXIgYWxsb3dzIHRoZSBjbGllbnQgdG8gcmVnaXN0ZXIgb25seSBwYXJ0CiAgIG9mIHRoZSBy ZWRpcmVjdGlvbiBVUkksIGFuIGF0dGFja2VyIGNhbiB1c2UgYW4gb3BlbiByZWRpcmVjdG9yCiAg IG9wZXJhdGVkIGJ5IHRoZSBjbGllbnQgdG8gY29uc3RydWN0IGEgcmVkaXJlY3Rpb24gVVJJIHRo YXQgd2lsbCBwYXNzCiAgIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciB2YWxpZGF0aW9uIGJ1dCB3 aWxsIHNlbmQgdGhlIGF1dGhvcml6YXRpb24KICAgY29kZSBvciBhY2Nlc3MgdG9rZW4gdG8gYW4g ZW5kcG9pbnQgdW5kZXIgdGhlIGNvbnRyb2wgb2YgdGhlCiAgIGF0dGFja2VyLgoKCjExLiAgSUFO QSBDb25zaWRlcmF0aW9ucwoKMTEuMS4gIFRoZSBPQXV0aCBBY2Nlc3MgVG9rZW4gVHlwZSBSZWdp c3RyeQoKICAgVGhpcyBzcGVjaWZpY2F0aW9uIGVzdGFibGlzaGVzIHRoZSBPQXV0aCBhY2Nlc3Mg dG9rZW4gdHlwZSByZWdpc3RyeS4KCiAgIEFjY2VzcyB0b2tlbiB0eXBlcyBhcmUgcmVnaXN0ZXJl ZCB3aXRoIGEgU3BlY2lmaWNhdGlvbiBSZXF1aXJlZAogICAoW1JGQzUyMjZdKSBhZnRlciBhIHR3 byB3ZWVrIHJldmlldyBwZXJpb2Qgb24gdGhlIFtUQkRdQGlldGYub3JnCiAgIG1haWxpbmcgbGlz dCwgb24gdGhlIGFkdmljZSBvZiBvbmUgb3IgbW9yZSBEZXNpZ25hdGVkIEV4cGVydHMuCiAgIEhv d2V2ZXIsIHRvIGFsbG93IGZvciB0aGUgYWxsb2NhdGlvbiBvZiB2YWx1ZXMgcHJpb3IgdG8gcHVi bGljYXRpb24sCiAgIHRoZSBEZXNpZ25hdGVkIEV4cGVydChzKSBtYXkgYXBwcm92ZSByZWdpc3Ry YXRpb24gb25jZSB0aGV5IGFyZQogICBzYXRpc2ZpZWQgdGhhdCBzdWNoIGEgc3BlY2lmaWNhdGlv biB3aWxsIGJlIHB1Ymxpc2hlZC4KCiAgIFJlZ2lzdHJhdGlvbiByZXF1ZXN0cyBtdXN0IGJlIHNl bnQgdG8gdGhlIFtUQkRdQGlldGYub3JnIG1haWxpbmcgbGlzdAogICBmb3IgcmV2aWV3IGFuZCBj b21tZW50LCB3aXRoIGFuIGFwcHJvcHJpYXRlIHN1YmplY3QgKGUuZy4sICJSZXF1ZXN0CiAgIGZv ciBhY2Nlc3MgdG9rZW4gdHlwZTogZXhhbXBsZSIpLiBbWyBOb3RlIHRvIFJGQy1FRElUT1I6IFRo ZSBuYW1lIG9mCiAgIHRoZSBtYWlsaW5nIGxpc3Qgc2hvdWxkIGJlIGRldGVybWluZWQgaW4gY29u c3VsdGF0aW9uIHdpdGggdGhlIElFU0cKICAgYW5kIElBTkEuICBTdWdnZXN0ZWQgbmFtZTogb2F1 dGgtZXh0LXJldmlldy4gXV0KCiAgIFdpdGhpbiB0aGUgcmV2aWV3IHBlcmlvZCwgdGhlIERlc2ln bmF0ZWQgRXhwZXJ0KHMpIHdpbGwgZWl0aGVyCiAgIGFwcHJvdmUgb3IgZGVueSB0aGUgcmVnaXN0 cmF0aW9uIHJlcXVlc3QsIGNvbW11bmljYXRpbmcgdGhpcyBkZWNpc2lvbgogICB0byB0aGUgcmV2 aWV3IGxpc3QgYW5kIElBTkEuICBEZW5pYWxzIHNob3VsZCBpbmNsdWRlIGFuIGV4cGxhbmF0aW9u CiAgIGFuZCwgaWYgYXBwbGljYWJsZSwgc3VnZ2VzdGlvbnMgYXMgdG8gaG93IHRvIG1ha2UgdGhl IHJlcXVlc3QKICAgc3VjY2Vzc2Z1bC4KCiAgIElBTkEgbXVzdCBvbmx5IGFjY2VwdCByZWdpc3Ry eSB1cGRhdGVzIGZyb20gdGhlIERlc2lnbmF0ZWQgRXhwZXJ0KHMpLAogICBhbmQgc2hvdWxkIGRp cmVjdCBhbGwgcmVxdWVzdHMgZm9yIHJlZ2lzdHJhdGlvbiB0byB0aGUgcmV2aWV3IG1haWxpbmcK ICAgbGlzdC4KCgoKCkhhbW1lciwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgRGVjZW1iZXIgMjAs IDIwMTIgICAgICAgICAgICAgIFtQYWdlIDU3XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAg ICAgICAgT0F1dGggMi4wICAgICAgICAgICAgICAgICAgICAgIEp1bmUgMjAxMgoKCjExLjEuMS4g IFJlZ2lzdHJhdGlvbiBUZW1wbGF0ZQoKICAgVHlwZSBuYW1lOgogICAgICBUaGUgbmFtZSByZXF1 ZXN0ZWQgKGUuZy4sICJleGFtcGxlIikuCiAgIEFkZGl0aW9uYWwgVG9rZW4gRW5kcG9pbnQgUmVz cG9uc2UgUGFyYW1ldGVyczoKICAgICAgQWRkaXRpb25hbCByZXNwb25zZSBwYXJhbWV0ZXJzIHJl dHVybmVkIHRvZ2V0aGVyIHdpdGggdGhlCiAgICAgICJhY2Nlc3NfdG9rZW4iIHBhcmFtZXRlci4g IE5ldyBwYXJhbWV0ZXJzIE1VU1QgYmUgc2VwYXJhdGVseQogICAgICByZWdpc3RlcmVkIGluIHRo ZSBPQXV0aCBwYXJhbWV0ZXJzIHJlZ2lzdHJ5IGFzIGRlc2NyaWJlZCBieQogICAgICBTZWN0aW9u IDExLjIuCiAgIEhUVFAgQXV0aGVudGljYXRpb24gU2NoZW1lKHMpOgogICAgICBUaGUgSFRUUCBh dXRoZW50aWNhdGlvbiBzY2hlbWUgbmFtZShzKSwgaWYgYW55LCB1c2VkIHRvCiAgICAgIGF1dGhl bnRpY2F0ZSBwcm90ZWN0ZWQgcmVzb3VyY2VzIHJlcXVlc3RzIHVzaW5nIGFjY2VzcyB0b2tlbnMg b2YKICAgICAgdGhpcyB0eXBlLgogICBDaGFuZ2UgY29udHJvbGxlcjoKICAgICAgRm9yIHN0YW5k YXJkcy10cmFjayBSRkNzLCBzdGF0ZSAiSUVURiIuICBGb3Igb3RoZXJzLCBnaXZlIHRoZSBuYW1l CiAgICAgIG9mIHRoZSByZXNwb25zaWJsZSBwYXJ0eS4gIE90aGVyIGRldGFpbHMgKGUuZy4sIHBv c3RhbCBhZGRyZXNzLAogICAgICBlLW1haWwgYWRkcmVzcywgaG9tZSBwYWdlIFVSSSkgbWF5IGFs c28gYmUgaW5jbHVkZWQuCiAgIFNwZWNpZmljYXRpb24gZG9jdW1lbnQocyk6CiAgICAgIFJlZmVy ZW5jZSB0byB0aGUgZG9jdW1lbnQgdGhhdCBzcGVjaWZpZXMgdGhlIHBhcmFtZXRlciwgcHJlZmVy YWJseQogICAgICBpbmNsdWRpbmcgYSBVUkkgdGhhdCBjYW4gYmUgdXNlZCB0byByZXRyaWV2ZSBh IGNvcHkgb2YgdGhlCiAgICAgIGRvY3VtZW50LiAgQW4gaW5kaWNhdGlvbiBvZiB0aGUgcmVsZXZh bnQgc2VjdGlvbnMgbWF5IGFsc28gYmUKICAgICAgaW5jbHVkZWQsIGJ1dCBpcyBub3QgcmVxdWly ZWQuCgoxMS4yLiAgVGhlIE9BdXRoIFBhcmFtZXRlcnMgUmVnaXN0cnkKCiAgIFRoaXMgc3BlY2lm aWNhdGlvbiBlc3RhYmxpc2hlcyB0aGUgT0F1dGggcGFyYW1ldGVycyByZWdpc3RyeS4KCiAgIEFk ZGl0aW9uYWwgcGFyYW1ldGVycyBmb3IgaW5jbHVzaW9uIGluIHRoZSBhdXRob3JpemF0aW9uIGVu ZHBvaW50CiAgIHJlcXVlc3QsIHRoZSBhdXRob3JpemF0aW9uIGVuZHBvaW50IHJlc3BvbnNlLCB0 aGUgdG9rZW4gZW5kcG9pbnQKICAgcmVxdWVzdCwgb3IgdGhlIHRva2VuIGVuZHBvaW50IHJlc3Bv bnNlIGFyZSByZWdpc3RlcmVkIHdpdGggYQogICBTcGVjaWZpY2F0aW9uIFJlcXVpcmVkIChbUkZD NTIyNl0pIGFmdGVyIGEgdHdvIHdlZWsgcmV2aWV3IHBlcmlvZCBvbgogICB0aGUgW1RCRF1AaWV0 Zi5vcmcgbWFpbGluZyBsaXN0LCBvbiB0aGUgYWR2aWNlIG9mIG9uZSBvciBtb3JlCiAgIERlc2ln bmF0ZWQgRXhwZXJ0cy4gIEhvd2V2ZXIsIHRvIGFsbG93IGZvciB0aGUgYWxsb2NhdGlvbiBvZiB2 YWx1ZXMKICAgcHJpb3IgdG8gcHVibGljYXRpb24sIHRoZSBEZXNpZ25hdGVkIEV4cGVydChzKSBt YXkgYXBwcm92ZQogICByZWdpc3RyYXRpb24gb25jZSB0aGV5IGFyZSBzYXRpc2ZpZWQgdGhhdCBz dWNoIGEgc3BlY2lmaWNhdGlvbiB3aWxsCiAgIGJlIHB1Ymxpc2hlZC4KCiAgIFJlZ2lzdHJhdGlv biByZXF1ZXN0cyBtdXN0IGJlIHNlbnQgdG8gdGhlIFtUQkRdQGlldGYub3JnIG1haWxpbmcgbGlz dAogICBmb3IgcmV2aWV3IGFuZCBjb21tZW50LCB3aXRoIGFuIGFwcHJvcHJpYXRlIHN1YmplY3Qg KGUuZy4sICJSZXF1ZXN0CiAgIGZvciBwYXJhbWV0ZXI6IGV4YW1wbGUiKS4gW1sgTm90ZSB0byBS RkMtRURJVE9SOiBUaGUgbmFtZSBvZiB0aGUKICAgbWFpbGluZyBsaXN0IHNob3VsZCBiZSBkZXRl cm1pbmVkIGluIGNvbnN1bHRhdGlvbiB3aXRoIHRoZSBJRVNHIGFuZAogICBJQU5BLiAgU3VnZ2Vz dGVkIG5hbWU6IG9hdXRoLWV4dC1yZXZpZXcuIF1dCgogICBXaXRoaW4gdGhlIHJldmlldyBwZXJp b2QsIHRoZSBEZXNpZ25hdGVkIEV4cGVydChzKSB3aWxsIGVpdGhlcgogICBhcHByb3ZlIG9yIGRl bnkgdGhlIHJlZ2lzdHJhdGlvbiByZXF1ZXN0LCBjb21tdW5pY2F0aW5nIHRoaXMgZGVjaXNpb24K ICAgdG8gdGhlIHJldmlldyBsaXN0IGFuZCBJQU5BLiAgRGVuaWFscyBzaG91bGQgaW5jbHVkZSBh biBleHBsYW5hdGlvbgogICBhbmQsIGlmIGFwcGxpY2FibGUsIHN1Z2dlc3Rpb25zIGFzIHRvIGhv dyB0byBtYWtlIHRoZSByZXF1ZXN0CiAgIHN1Y2Nlc3NmdWwuCgoKCkhhbW1lciwgZXQgYWwuICAg ICAgICAgIEV4cGlyZXMgRGVjZW1iZXIgMjAsIDIwMTIgICAgICAgICAgICAgIFtQYWdlIDU4XQoM CkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgT0F1dGggMi4wICAgICAgICAgICAgICAg ICAgICAgIEp1bmUgMjAxMgoKCiAgIElBTkEgbXVzdCBvbmx5IGFjY2VwdCByZWdpc3RyeSB1cGRh dGVzIGZyb20gdGhlIERlc2lnbmF0ZWQgRXhwZXJ0KHMpLAogICBhbmQgc2hvdWxkIGRpcmVjdCBh bGwgcmVxdWVzdHMgZm9yIHJlZ2lzdHJhdGlvbiB0byB0aGUgcmV2aWV3IG1haWxpbmcKICAgbGlz dC4KCjExLjIuMS4gIFJlZ2lzdHJhdGlvbiBUZW1wbGF0ZQoKICAgUGFyYW1ldGVyIG5hbWU6CiAg ICAgIFRoZSBuYW1lIHJlcXVlc3RlZCAoZS5nLiwgImV4YW1wbGUiKS4KICAgUGFyYW1ldGVyIHVz YWdlIGxvY2F0aW9uOgogICAgICBUaGUgbG9jYXRpb24ocykgd2hlcmUgcGFyYW1ldGVyIGNhbiBi ZSB1c2VkLiAgVGhlIHBvc3NpYmxlCiAgICAgIGxvY2F0aW9ucyBhcmU6IGF1dGhvcml6YXRpb24g cmVxdWVzdCwgYXV0aG9yaXphdGlvbiByZXNwb25zZSwKICAgICAgdG9rZW4gcmVxdWVzdCwgb3Ig dG9rZW4gcmVzcG9uc2UuCiAgIENoYW5nZSBjb250cm9sbGVyOgogICAgICBGb3Igc3RhbmRhcmRz LXRyYWNrIFJGQ3MsIHN0YXRlICJJRVRGIi4gIEZvciBvdGhlcnMsIGdpdmUgdGhlIG5hbWUKICAg ICAgb2YgdGhlIHJlc3BvbnNpYmxlIHBhcnR5LiAgT3RoZXIgZGV0YWlscyAoZS5nLiwgcG9zdGFs IGFkZHJlc3MsCiAgICAgIGUtbWFpbCBhZGRyZXNzLCBob21lIHBhZ2UgVVJJKSBtYXkgYWxzbyBi ZSBpbmNsdWRlZC4KICAgU3BlY2lmaWNhdGlvbiBkb2N1bWVudChzKToKICAgICAgUmVmZXJlbmNl IHRvIHRoZSBkb2N1bWVudCB0aGF0IHNwZWNpZmllcyB0aGUgcGFyYW1ldGVyLCBwcmVmZXJhYmx5 CiAgICAgIGluY2x1ZGluZyBhIFVSSSB0aGF0IGNhbiBiZSB1c2VkIHRvIHJldHJpZXZlIGEgY29w eSBvZiB0aGUKICAgICAgZG9jdW1lbnQuICBBbiBpbmRpY2F0aW9uIG9mIHRoZSByZWxldmFudCBz ZWN0aW9ucyBtYXkgYWxzbyBiZQogICAgICBpbmNsdWRlZCwgYnV0IGlzIG5vdCByZXF1aXJlZC4K CjExLjIuMi4gIEluaXRpYWwgUmVnaXN0cnkgQ29udGVudHMKCiAgIFRoZSBPQXV0aCBQYXJhbWV0 ZXJzIFJlZ2lzdHJ5J3MgaW5pdGlhbCBjb250ZW50cyBhcmU6CgogICBvICBQYXJhbWV0ZXIgbmFt ZTogY2xpZW50X2lkCiAgIG8gIFBhcmFtZXRlciB1c2FnZSBsb2NhdGlvbjogYXV0aG9yaXphdGlv biByZXF1ZXN0LCB0b2tlbiByZXF1ZXN0CiAgIG8gIENoYW5nZSBjb250cm9sbGVyOiBJRVRGCiAg IG8gIFNwZWNpZmljYXRpb24gZG9jdW1lbnQocyk6IFtbIHRoaXMgZG9jdW1lbnQgXV0KCiAgIG8g IFBhcmFtZXRlciBuYW1lOiBjbGllbnRfc2VjcmV0CiAgIG8gIFBhcmFtZXRlciB1c2FnZSBsb2Nh dGlvbjogdG9rZW4gcmVxdWVzdAogICBvICBDaGFuZ2UgY29udHJvbGxlcjogSUVURgogICBvICBT cGVjaWZpY2F0aW9uIGRvY3VtZW50KHMpOiBbWyB0aGlzIGRvY3VtZW50IF1dCgogICBvICBQYXJh bWV0ZXIgbmFtZTogcmVzcG9uc2VfdHlwZQogICBvICBQYXJhbWV0ZXIgdXNhZ2UgbG9jYXRpb246 IGF1dGhvcml6YXRpb24gcmVxdWVzdAogICBvICBDaGFuZ2UgY29udHJvbGxlcjogSUVURgogICBv ICBTcGVjaWZpY2F0aW9uIGRvY3VtZW50KHMpOiBbWyB0aGlzIGRvY3VtZW50IF1dCgogICBvICBQ YXJhbWV0ZXIgbmFtZTogcmVkaXJlY3RfdXJpCiAgIG8gIFBhcmFtZXRlciB1c2FnZSBsb2NhdGlv bjogYXV0aG9yaXphdGlvbiByZXF1ZXN0LCB0b2tlbiByZXF1ZXN0CiAgIG8gIENoYW5nZSBjb250 cm9sbGVyOiBJRVRGCiAgIG8gIFNwZWNpZmljYXRpb24gZG9jdW1lbnQocyk6IFtbIHRoaXMgZG9j dW1lbnQgXV0KCgoKCgoKSGFtbWVyLCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBEZWNlbWJlciAy MCwgMjAxMiAgICAgICAgICAgICAgW1BhZ2UgNTldCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAg ICAgICAgICBPQXV0aCAyLjAgICAgICAgICAgICAgICAgICAgICAgSnVuZSAyMDEyCgoKICAgbyAg UGFyYW1ldGVyIG5hbWU6IHNjb3BlCiAgIG8gIFBhcmFtZXRlciB1c2FnZSBsb2NhdGlvbjogYXV0 aG9yaXphdGlvbiByZXF1ZXN0LCBhdXRob3JpemF0aW9uCiAgICAgIHJlc3BvbnNlLCB0b2tlbiBy ZXF1ZXN0LCB0b2tlbiByZXNwb25zZQogICBvICBDaGFuZ2UgY29udHJvbGxlcjogSUVURgogICBv ICBTcGVjaWZpY2F0aW9uIGRvY3VtZW50KHMpOiBbWyB0aGlzIGRvY3VtZW50IF1dCgogICBvICBQ YXJhbWV0ZXIgbmFtZTogc3RhdGUKICAgbyAgUGFyYW1ldGVyIHVzYWdlIGxvY2F0aW9uOiBhdXRo b3JpemF0aW9uIHJlcXVlc3QsIGF1dGhvcml6YXRpb24KICAgICAgcmVzcG9uc2UKICAgbyAgQ2hh bmdlIGNvbnRyb2xsZXI6IElFVEYKICAgbyAgU3BlY2lmaWNhdGlvbiBkb2N1bWVudChzKTogW1sg dGhpcyBkb2N1bWVudCBdXQoKICAgbyAgUGFyYW1ldGVyIG5hbWU6IGNvZGUKICAgbyAgUGFyYW1l dGVyIHVzYWdlIGxvY2F0aW9uOiBhdXRob3JpemF0aW9uIHJlc3BvbnNlLCB0b2tlbiByZXF1ZXN0 CiAgIG8gIENoYW5nZSBjb250cm9sbGVyOiBJRVRGCiAgIG8gIFNwZWNpZmljYXRpb24gZG9jdW1l bnQocyk6IFtbIHRoaXMgZG9jdW1lbnQgXV0KCiAgIG8gIFBhcmFtZXRlciBuYW1lOiBlcnJvcl9k ZXNjcmlwdGlvbgogICBvICBQYXJhbWV0ZXIgdXNhZ2UgbG9jYXRpb246IGF1dGhvcml6YXRpb24g cmVzcG9uc2UsIHRva2VuIHJlc3BvbnNlCiAgIG8gIENoYW5nZSBjb250cm9sbGVyOiBJRVRGCiAg IG8gIFNwZWNpZmljYXRpb24gZG9jdW1lbnQocyk6IFtbIHRoaXMgZG9jdW1lbnQgXV0KCiAgIG8g IFBhcmFtZXRlciBuYW1lOiBlcnJvcl91cmkKICAgbyAgUGFyYW1ldGVyIHVzYWdlIGxvY2F0aW9u OiBhdXRob3JpemF0aW9uIHJlc3BvbnNlLCB0b2tlbiByZXNwb25zZQogICBvICBDaGFuZ2UgY29u dHJvbGxlcjogSUVURgogICBvICBTcGVjaWZpY2F0aW9uIGRvY3VtZW50KHMpOiBbWyB0aGlzIGRv Y3VtZW50IF1dCgogICBvICBQYXJhbWV0ZXIgbmFtZTogZ3JhbnRfdHlwZQogICBvICBQYXJhbWV0 ZXIgdXNhZ2UgbG9jYXRpb246IHRva2VuIHJlcXVlc3QKICAgbyAgQ2hhbmdlIGNvbnRyb2xsZXI6 IElFVEYKICAgbyAgU3BlY2lmaWNhdGlvbiBkb2N1bWVudChzKTogW1sgdGhpcyBkb2N1bWVudCBd XQoKICAgbyAgUGFyYW1ldGVyIG5hbWU6IGFjY2Vzc190b2tlbgogICBvICBQYXJhbWV0ZXIgdXNh Z2UgbG9jYXRpb246IGF1dGhvcml6YXRpb24gcmVzcG9uc2UsIHRva2VuIHJlc3BvbnNlCiAgIG8g IENoYW5nZSBjb250cm9sbGVyOiBJRVRGCiAgIG8gIFNwZWNpZmljYXRpb24gZG9jdW1lbnQocyk6 IFtbIHRoaXMgZG9jdW1lbnQgXV0KCiAgIG8gIFBhcmFtZXRlciBuYW1lOiB0b2tlbl90eXBlCiAg IG8gIFBhcmFtZXRlciB1c2FnZSBsb2NhdGlvbjogYXV0aG9yaXphdGlvbiByZXNwb25zZSwgdG9r ZW4gcmVzcG9uc2UKICAgbyAgQ2hhbmdlIGNvbnRyb2xsZXI6IElFVEYKICAgbyAgU3BlY2lmaWNh dGlvbiBkb2N1bWVudChzKTogW1sgdGhpcyBkb2N1bWVudCBdXQoKICAgbyAgUGFyYW1ldGVyIG5h bWU6IGV4cGlyZXNfaW4KICAgbyAgUGFyYW1ldGVyIHVzYWdlIGxvY2F0aW9uOiBhdXRob3JpemF0 aW9uIHJlc3BvbnNlLCB0b2tlbiByZXNwb25zZQogICBvICBDaGFuZ2UgY29udHJvbGxlcjogSUVU RgogICBvICBTcGVjaWZpY2F0aW9uIGRvY3VtZW50KHMpOiBbWyB0aGlzIGRvY3VtZW50IF1dCgoK CgoKSGFtbWVyLCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBEZWNlbWJlciAyMCwgMjAxMiAgICAg ICAgICAgICAgW1BhZ2UgNjBdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICBPQXV0 aCAyLjAgICAgICAgICAgICAgICAgICAgICAgSnVuZSAyMDEyCgoKICAgbyAgUGFyYW1ldGVyIG5h bWU6IHVzZXJuYW1lCiAgIG8gIFBhcmFtZXRlciB1c2FnZSBsb2NhdGlvbjogdG9rZW4gcmVxdWVz dAogICBvICBDaGFuZ2UgY29udHJvbGxlcjogSUVURgogICBvICBTcGVjaWZpY2F0aW9uIGRvY3Vt ZW50KHMpOiBbWyB0aGlzIGRvY3VtZW50IF1dCgogICBvICBQYXJhbWV0ZXIgbmFtZTogcGFzc3dv cmQKICAgbyAgUGFyYW1ldGVyIHVzYWdlIGxvY2F0aW9uOiB0b2tlbiByZXF1ZXN0CiAgIG8gIENo YW5nZSBjb250cm9sbGVyOiBJRVRGCiAgIG8gIFNwZWNpZmljYXRpb24gZG9jdW1lbnQocyk6IFtb IHRoaXMgZG9jdW1lbnQgXV0KCiAgIG8gIFBhcmFtZXRlciBuYW1lOiByZWZyZXNoX3Rva2VuCiAg IG8gIFBhcmFtZXRlciB1c2FnZSBsb2NhdGlvbjogdG9rZW4gcmVxdWVzdCwgdG9rZW4gcmVzcG9u c2UKICAgbyAgQ2hhbmdlIGNvbnRyb2xsZXI6IElFVEYKICAgbyAgU3BlY2lmaWNhdGlvbiBkb2N1 bWVudChzKTogW1sgdGhpcyBkb2N1bWVudCBdXQoKMTEuMy4gIFRoZSBPQXV0aCBBdXRob3JpemF0 aW9uIEVuZHBvaW50IFJlc3BvbnNlIFR5cGUgUmVnaXN0cnkKCiAgIFRoaXMgc3BlY2lmaWNhdGlv biBlc3RhYmxpc2hlcyB0aGUgT0F1dGggYXV0aG9yaXphdGlvbiBlbmRwb2ludAogICByZXNwb25z ZSB0eXBlIHJlZ2lzdHJ5LgoKICAgQWRkaXRpb25hbCByZXNwb25zZSB0eXBlIGZvciB1c2Ugd2l0 aCB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludCBhcmUKICAgcmVnaXN0ZXJlZCB3aXRoIGEgU3Bl Y2lmaWNhdGlvbiBSZXF1aXJlZCAoW1JGQzUyMjZdKSBhZnRlciBhIHR3byB3ZWVrCiAgIHJldmll dyBwZXJpb2Qgb24gdGhlIFtUQkRdQGlldGYub3JnIG1haWxpbmcgbGlzdCwgb24gdGhlIGFkdmlj ZSBvZgogICBvbmUgb3IgbW9yZSBEZXNpZ25hdGVkIEV4cGVydHMuICBIb3dldmVyLCB0byBhbGxv dyBmb3IgdGhlIGFsbG9jYXRpb24KICAgb2YgdmFsdWVzIHByaW9yIHRvIHB1YmxpY2F0aW9uLCB0 aGUgRGVzaWduYXRlZCBFeHBlcnQocykgbWF5IGFwcHJvdmUKICAgcmVnaXN0cmF0aW9uIG9uY2Ug dGhleSBhcmUgc2F0aXNmaWVkIHRoYXQgc3VjaCBhIHNwZWNpZmljYXRpb24gd2lsbAogICBiZSBw dWJsaXNoZWQuCgogICBSZWdpc3RyYXRpb24gcmVxdWVzdHMgbXVzdCBiZSBzZW50IHRvIHRoZSBb VEJEXUBpZXRmLm9yZyBtYWlsaW5nIGxpc3QKICAgZm9yIHJldmlldyBhbmQgY29tbWVudCwgd2l0 aCBhbiBhcHByb3ByaWF0ZSBzdWJqZWN0IChlLmcuLCAiUmVxdWVzdAogICBmb3IgcmVzcG9uc2Ug dHlwZTogZXhhbXBsZSIpLiBbWyBOb3RlIHRvIFJGQy1FRElUT1I6IFRoZSBuYW1lIG9mIHRoZQog ICBtYWlsaW5nIGxpc3Qgc2hvdWxkIGJlIGRldGVybWluZWQgaW4gY29uc3VsdGF0aW9uIHdpdGgg dGhlIElFU0cgYW5kCiAgIElBTkEuICBTdWdnZXN0ZWQgbmFtZTogb2F1dGgtZXh0LXJldmlldy4g XV0KCiAgIFdpdGhpbiB0aGUgcmV2aWV3IHBlcmlvZCwgdGhlIERlc2lnbmF0ZWQgRXhwZXJ0KHMp IHdpbGwgZWl0aGVyCiAgIGFwcHJvdmUgb3IgZGVueSB0aGUgcmVnaXN0cmF0aW9uIHJlcXVlc3Qs IGNvbW11bmljYXRpbmcgdGhpcyBkZWNpc2lvbgogICB0byB0aGUgcmV2aWV3IGxpc3QgYW5kIElB TkEuICBEZW5pYWxzIHNob3VsZCBpbmNsdWRlIGFuIGV4cGxhbmF0aW9uCiAgIGFuZCwgaWYgYXBw bGljYWJsZSwgc3VnZ2VzdGlvbnMgYXMgdG8gaG93IHRvIG1ha2UgdGhlIHJlcXVlc3QKICAgc3Vj Y2Vzc2Z1bC4KCiAgIElBTkEgbXVzdCBvbmx5IGFjY2VwdCByZWdpc3RyeSB1cGRhdGVzIGZyb20g dGhlIERlc2lnbmF0ZWQgRXhwZXJ0KHMpLAogICBhbmQgc2hvdWxkIGRpcmVjdCBhbGwgcmVxdWVz dHMgZm9yIHJlZ2lzdHJhdGlvbiB0byB0aGUgcmV2aWV3IG1haWxpbmcKICAgbGlzdC4KCjExLjMu MS4gIFJlZ2lzdHJhdGlvbiBUZW1wbGF0ZQoKCgoKCgpIYW1tZXIsIGV0IGFsLiAgICAgICAgICBF eHBpcmVzIERlY2VtYmVyIDIwLCAyMDEyICAgICAgICAgICAgICBbUGFnZSA2MV0KDApJbnRlcm5l dC1EcmFmdCAgICAgICAgICAgICAgICAgIE9BdXRoIDIuMCAgICAgICAgICAgICAgICAgICAgICBK dW5lIDIwMTIKCgogICBSZXNwb25zZSB0eXBlIG5hbWU6CiAgICAgIFRoZSBuYW1lIHJlcXVlc3Rl ZCAoZS5nLiwgImV4YW1wbGUiKS4KICAgQ2hhbmdlIGNvbnRyb2xsZXI6CiAgICAgIEZvciBzdGFu ZGFyZHMtdHJhY2sgUkZDcywgc3RhdGUgIklFVEYiLiAgRm9yIG90aGVycywgZ2l2ZSB0aGUgbmFt ZQogICAgICBvZiB0aGUgcmVzcG9uc2libGUgcGFydHkuICBPdGhlciBkZXRhaWxzIChlLmcuLCBw b3N0YWwgYWRkcmVzcywKICAgICAgZS1tYWlsIGFkZHJlc3MsIGhvbWUgcGFnZSBVUkkpIG1heSBh bHNvIGJlIGluY2x1ZGVkLgogICBTcGVjaWZpY2F0aW9uIGRvY3VtZW50KHMpOgogICAgICBSZWZl cmVuY2UgdG8gdGhlIGRvY3VtZW50IHRoYXQgc3BlY2lmaWVzIHRoZSB0eXBlLCBwcmVmZXJhYmx5 CiAgICAgIGluY2x1ZGluZyBhIFVSSSB0aGF0IGNhbiBiZSB1c2VkIHRvIHJldHJpZXZlIGEgY29w eSBvZiB0aGUKICAgICAgZG9jdW1lbnQuICBBbiBpbmRpY2F0aW9uIG9mIHRoZSByZWxldmFudCBz ZWN0aW9ucyBtYXkgYWxzbyBiZQogICAgICBpbmNsdWRlZCwgYnV0IGlzIG5vdCByZXF1aXJlZC4K CjExLjMuMi4gIEluaXRpYWwgUmVnaXN0cnkgQ29udGVudHMKCiAgIFRoZSBPQXV0aCBBdXRob3Jp emF0aW9uIEVuZHBvaW50IFJlc3BvbnNlIFR5cGUgUmVnaXN0cnkncyBpbml0aWFsCiAgIGNvbnRl bnRzIGFyZToKCiAgIG8gIFJlc3BvbnNlIHR5cGUgbmFtZTogY29kZQogICBvICBDaGFuZ2UgY29u dHJvbGxlcjogSUVURgogICBvICBTcGVjaWZpY2F0aW9uIGRvY3VtZW50KHMpOiBbWyB0aGlzIGRv Y3VtZW50IF1dCgogICBvICBSZXNwb25zZSB0eXBlIG5hbWU6IHRva2VuCiAgIG8gIENoYW5nZSBj b250cm9sbGVyOiBJRVRGCiAgIG8gIFNwZWNpZmljYXRpb24gZG9jdW1lbnQocyk6IFtbIHRoaXMg ZG9jdW1lbnQgXV0KCjExLjQuICBUaGUgT0F1dGggRXh0ZW5zaW9ucyBFcnJvciBSZWdpc3RyeQoK ICAgVGhpcyBzcGVjaWZpY2F0aW9uIGVzdGFibGlzaGVzIHRoZSBPQXV0aCBleHRlbnNpb25zIGVy cm9yIHJlZ2lzdHJ5LgoKICAgQWRkaXRpb25hbCBlcnJvciBjb2RlcyB1c2VkIHRvZ2V0aGVyIHdp dGggb3RoZXIgcHJvdG9jb2wgZXh0ZW5zaW9ucwogICAoaS5lLiBleHRlbnNpb24gZ3JhbnQgdHlw ZXMsIGFjY2VzcyB0b2tlbiB0eXBlcywgb3IgZXh0ZW5zaW9uCiAgIHBhcmFtZXRlcnMpIGFyZSBy ZWdpc3RlcmVkIHdpdGggYSBTcGVjaWZpY2F0aW9uIFJlcXVpcmVkIChbUkZDNTIyNl0pCiAgIGFm dGVyIGEgdHdvIHdlZWsgcmV2aWV3IHBlcmlvZCBvbiB0aGUgW1RCRF1AaWV0Zi5vcmcgbWFpbGlu ZyBsaXN0LCBvbgogICB0aGUgYWR2aWNlIG9mIG9uZSBvciBtb3JlIERlc2lnbmF0ZWQgRXhwZXJ0 cy4gIEhvd2V2ZXIsIHRvIGFsbG93IGZvcgogICB0aGUgYWxsb2NhdGlvbiBvZiB2YWx1ZXMgcHJp b3IgdG8gcHVibGljYXRpb24sIHRoZSBEZXNpZ25hdGVkCiAgIEV4cGVydChzKSBtYXkgYXBwcm92 ZSByZWdpc3RyYXRpb24gb25jZSB0aGV5IGFyZSBzYXRpc2ZpZWQgdGhhdCBzdWNoCiAgIGEgc3Bl Y2lmaWNhdGlvbiB3aWxsIGJlIHB1Ymxpc2hlZC4KCiAgIFJlZ2lzdHJhdGlvbiByZXF1ZXN0cyBt dXN0IGJlIHNlbnQgdG8gdGhlIFtUQkRdQGlldGYub3JnIG1haWxpbmcgbGlzdAogICBmb3IgcmV2 aWV3IGFuZCBjb21tZW50LCB3aXRoIGFuIGFwcHJvcHJpYXRlIHN1YmplY3QgKGUuZy4sICJSZXF1 ZXN0CiAgIGZvciBlcnJvciBjb2RlOiBleGFtcGxlIikuIFtbIE5vdGUgdG8gUkZDLUVESVRPUjog VGhlIG5hbWUgb2YgdGhlCiAgIG1haWxpbmcgbGlzdCBzaG91bGQgYmUgZGV0ZXJtaW5lZCBpbiBj b25zdWx0YXRpb24gd2l0aCB0aGUgSUVTRyBhbmQKICAgSUFOQS4gIFN1Z2dlc3RlZCBuYW1lOiBv YXV0aC1leHQtcmV2aWV3LiBdXQoKICAgV2l0aGluIHRoZSByZXZpZXcgcGVyaW9kLCB0aGUgRGVz aWduYXRlZCBFeHBlcnQocykgd2lsbCBlaXRoZXIKICAgYXBwcm92ZSBvciBkZW55IHRoZSByZWdp c3RyYXRpb24gcmVxdWVzdCwgY29tbXVuaWNhdGluZyB0aGlzIGRlY2lzaW9uCiAgIHRvIHRoZSBy ZXZpZXcgbGlzdCBhbmQgSUFOQS4gIERlbmlhbHMgc2hvdWxkIGluY2x1ZGUgYW4gZXhwbGFuYXRp b24KICAgYW5kLCBpZiBhcHBsaWNhYmxlLCBzdWdnZXN0aW9ucyBhcyB0byBob3cgdG8gbWFrZSB0 aGUgcmVxdWVzdAoKCgpIYW1tZXIsIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIERlY2VtYmVyIDIw LCAyMDEyICAgICAgICAgICAgICBbUGFnZSA2Ml0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAg ICAgICAgIE9BdXRoIDIuMCAgICAgICAgICAgICAgICAgICAgICBKdW5lIDIwMTIKCgogICBzdWNj ZXNzZnVsLgoKICAgSUFOQSBtdXN0IG9ubHkgYWNjZXB0IHJlZ2lzdHJ5IHVwZGF0ZXMgZnJvbSB0 aGUgRGVzaWduYXRlZCBFeHBlcnQocyksCiAgIGFuZCBzaG91bGQgZGlyZWN0IGFsbCByZXF1ZXN0 cyBmb3IgcmVnaXN0cmF0aW9uIHRvIHRoZSByZXZpZXcgbWFpbGluZwogICBsaXN0LgoKMTEuNC4x LiAgUmVnaXN0cmF0aW9uIFRlbXBsYXRlCgogICBFcnJvciBuYW1lOgogICAgICBUaGUgbmFtZSBy ZXF1ZXN0ZWQgKGUuZy4sICJleGFtcGxlIikuICBWYWx1ZXMgZm9yIHRoZSBlcnJvciBuYW1lCiAg ICAgIE1VU1QgTk9UIGluY2x1ZGUgY2hhcmFjdGVycyBvdXRzaWRlIHRoZSBzZXQgJXgyMC0yMSAv ICV4MjMtNUIgLwogICAgICAleDVELTdFLgogICBFcnJvciB1c2FnZSBsb2NhdGlvbjoKICAgICAg VGhlIGxvY2F0aW9uKHMpIHdoZXJlIHRoZSBlcnJvciBjYW4gYmUgdXNlZC4gIFRoZSBwb3NzaWJs ZQogICAgICBsb2NhdGlvbnMgYXJlOiBhdXRob3JpemF0aW9uIGNvZGUgZ3JhbnQgZXJyb3IgcmVz cG9uc2UKICAgICAgKFNlY3Rpb24gNC4xLjIuMSksIGltcGxpY2l0IGdyYW50IGVycm9yIHJlc3Bv bnNlCiAgICAgIChTZWN0aW9uIDQuMi4yLjEpLCB0b2tlbiBlcnJvciByZXNwb25zZSAoU2VjdGlv biA1LjIpLCBvciByZXNvdXJjZQogICAgICBhY2Nlc3MgZXJyb3IgcmVzcG9uc2UgKFNlY3Rpb24g Ny4yKS4KICAgUmVsYXRlZCBwcm90b2NvbCBleHRlbnNpb246CiAgICAgIFRoZSBuYW1lIG9mIHRo ZSBleHRlbnNpb24gZ3JhbnQgdHlwZSwgYWNjZXNzIHRva2VuIHR5cGUsIG9yCiAgICAgIGV4dGVu c2lvbiBwYXJhbWV0ZXIsIHRoZSBlcnJvciBjb2RlIGlzIHVzZWQgaW4gY29uanVuY3Rpb24gd2l0 aC4KICAgQ2hhbmdlIGNvbnRyb2xsZXI6CiAgICAgIEZvciBzdGFuZGFyZHMtdHJhY2sgUkZDcywg c3RhdGUgIklFVEYiLiAgRm9yIG90aGVycywgZ2l2ZSB0aGUgbmFtZQogICAgICBvZiB0aGUgcmVz cG9uc2libGUgcGFydHkuICBPdGhlciBkZXRhaWxzIChlLmcuLCBwb3N0YWwgYWRkcmVzcywKICAg ICAgZS1tYWlsIGFkZHJlc3MsIGhvbWUgcGFnZSBVUkkpIG1heSBhbHNvIGJlIGluY2x1ZGVkLgog ICBTcGVjaWZpY2F0aW9uIGRvY3VtZW50KHMpOgogICAgICBSZWZlcmVuY2UgdG8gdGhlIGRvY3Vt ZW50IHRoYXQgc3BlY2lmaWVzIHRoZSBlcnJvciBjb2RlLAogICAgICBwcmVmZXJhYmx5IGluY2x1 ZGluZyBhIFVSSSB0aGF0IGNhbiBiZSB1c2VkIHRvIHJldHJpZXZlIGEgY29weSBvZgogICAgICB0 aGUgZG9jdW1lbnQuICBBbiBpbmRpY2F0aW9uIG9mIHRoZSByZWxldmFudCBzZWN0aW9ucyBtYXkg YWxzbyBiZQogICAgICBpbmNsdWRlZCwgYnV0IGlzIG5vdCByZXF1aXJlZC4KCgoxMi4gIFJlZmVy ZW5jZXMKCjEyLjEuICBOb3JtYXRpdmUgUmVmZXJlbmNlcwoKICAgW1JGQzIxMTldICBCcmFkbmVy LCBTLiwgIktleSB3b3JkcyBmb3IgdXNlIGluIFJGQ3MgdG8gSW5kaWNhdGUKICAgICAgICAgICAg ICBSZXF1aXJlbWVudCBMZXZlbHMiLCBCQ1AgMTQsIFJGQyAyMTE5LCBNYXJjaCAxOTk3LgoKICAg W1JGQzIyNDZdICBEaWVya3MsIFQuIGFuZCBDLiBBbGxlbiwgIlRoZSBUTFMgUHJvdG9jb2wgVmVy c2lvbiAxLjAiLAogICAgICAgICAgICAgIFJGQyAyMjQ2LCBKYW51YXJ5IDE5OTkuCgogICBbUkZD MjYxNl0gIEZpZWxkaW5nLCBSLiwgR2V0dHlzLCBKLiwgTW9ndWwsIEouLCBGcnlzdHlrLCBILiwK ICAgICAgICAgICAgICBNYXNpbnRlciwgTC4sIExlYWNoLCBQLiwgYW5kIFQuIEJlcm5lcnMtTGVl LCAiSHlwZXJ0ZXh0CiAgICAgICAgICAgICAgVHJhbnNmZXIgUHJvdG9jb2wgLS0gSFRUUC8xLjEi LCBSRkMgMjYxNiwgSnVuZSAxOTk5LgoKICAgW1JGQzI2MTddICBGcmFua3MsIEouLCBIYWxsYW0t QmFrZXIsIFAuLCBIb3N0ZXRsZXIsIEouLCBMYXdyZW5jZSwgUy4sCiAgICAgICAgICAgICAgTGVh Y2gsIFAuLCBMdW90b25lbiwgQS4sIGFuZCBMLiBTdGV3YXJ0LCAiSFRUUAoKCgpIYW1tZXIsIGV0 IGFsLiAgICAgICAgICBFeHBpcmVzIERlY2VtYmVyIDIwLCAyMDEyICAgICAgICAgICAgICBbUGFn ZSA2M10KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgIE9BdXRoIDIuMCAgICAgICAg ICAgICAgICAgICAgICBKdW5lIDIwMTIKCgogICAgICAgICAgICAgIEF1dGhlbnRpY2F0aW9uOiBC YXNpYyBhbmQgRGlnZXN0IEFjY2VzcyBBdXRoZW50aWNhdGlvbiIsCiAgICAgICAgICAgICAgUkZD IDI2MTcsIEp1bmUgMTk5OS4KCiAgIFtSRkMyODE4XSAgUmVzY29ybGEsIEUuLCAiSFRUUCBPdmVy IFRMUyIsIFJGQyAyODE4LCBNYXkgMjAwMC4KCiAgIFtSRkMzOTg2XSAgQmVybmVycy1MZWUsIFQu LCBGaWVsZGluZywgUi4sIGFuZCBMLiBNYXNpbnRlciwgIlVuaWZvcm0KICAgICAgICAgICAgICBS ZXNvdXJjZSBJZGVudGlmaWVyIChVUkkpOiBHZW5lcmljIFN5bnRheCIsIFNURCA2NiwKICAgICAg ICAgICAgICBSRkMgMzk4NiwgSmFudWFyeSAyMDA1LgoKICAgW1JGQzQ2MjddICBDcm9ja2ZvcmQs IEQuLCAiVGhlIGFwcGxpY2F0aW9uL2pzb24gTWVkaWEgVHlwZSBmb3IKICAgICAgICAgICAgICBK YXZhU2NyaXB0IE9iamVjdCBOb3RhdGlvbiAoSlNPTikiLCBSRkMgNDYyNywgSnVseSAyMDA2LgoK ICAgW1JGQzQ5NDldICBTaGlyZXksIFIuLCAiSW50ZXJuZXQgU2VjdXJpdHkgR2xvc3NhcnksIFZl cnNpb24gMiIsCiAgICAgICAgICAgICAgUkZDIDQ5NDksIEF1Z3VzdCAyMDA3LgoKICAgW1JGQzUy MjZdICBOYXJ0ZW4sIFQuIGFuZCBILiBBbHZlc3RyYW5kLCAiR3VpZGVsaW5lcyBmb3IgV3JpdGlu ZyBhbgogICAgICAgICAgICAgIElBTkEgQ29uc2lkZXJhdGlvbnMgU2VjdGlvbiBpbiBSRkNzIiwg QkNQIDI2LCBSRkMgNTIyNiwKICAgICAgICAgICAgICBNYXkgMjAwOC4KCiAgIFtSRkM1MjM0XSAg Q3JvY2tlciwgRC4gYW5kIFAuIE92ZXJlbGwsICJBdWdtZW50ZWQgQk5GIGZvciBTeW50YXgKICAg ICAgICAgICAgICBTcGVjaWZpY2F0aW9uczogQUJORiIsIFNURCA2OCwgUkZDIDUyMzQsIEphbnVh cnkgMjAwOC4KCiAgIFtSRkM1MjQ2XSAgRGllcmtzLCBULiBhbmQgRS4gUmVzY29ybGEsICJUaGUg VHJhbnNwb3J0IExheWVyIFNlY3VyaXR5CiAgICAgICAgICAgICAgKFRMUykgUHJvdG9jb2wgVmVy c2lvbiAxLjIiLCBSRkMgNTI0NiwgQXVndXN0IDIwMDguCgogICBbUkZDNjEyNV0gIFNhaW50LUFu ZHJlLCBQLiBhbmQgSi4gSG9kZ2VzLCAiUmVwcmVzZW50YXRpb24gYW5kCiAgICAgICAgICAgICAg VmVyaWZpY2F0aW9uIG9mIERvbWFpbi1CYXNlZCBBcHBsaWNhdGlvbiBTZXJ2aWNlIElkZW50aXR5 CiAgICAgICAgICAgICAgd2l0aGluIEludGVybmV0IFB1YmxpYyBLZXkgSW5mcmFzdHJ1Y3R1cmUg VXNpbmcgWC41MDkKICAgICAgICAgICAgICAoUEtJWCkgQ2VydGlmaWNhdGVzIGluIHRoZSBDb250 ZXh0IG9mIFRyYW5zcG9ydCBMYXllcgogICAgICAgICAgICAgIFNlY3VyaXR5IChUTFMpIiwgUkZD IDYxMjUsIE1hcmNoIDIwMTEuCgogICBbVVNBU0NJSV0gIEFtZXJpY2FuIE5hdGlvbmFsIFN0YW5k YXJkcyBJbnN0aXR1dGUsICJDb2RlZCBDaGFyYWN0ZXIKICAgICAgICAgICAgICBTZXQgLS0gNy1i aXQgQW1lcmljYW4gU3RhbmRhcmQgQ29kZSBmb3IgSW5mb3JtYXRpb24KICAgICAgICAgICAgICBJ bnRlcmNoYW5nZSIsIEFOU0kgWDMuNCwgMTk4Ni4KCiAgIFtXM0MuUkVDLWh0bWw0MDEtMTk5OTEy MjRdCiAgICAgICAgICAgICAgSG9ycywgQS4sIFJhZ2dldHQsIEQuLCBhbmQgSS4gSmFjb2JzLCAi SFRNTCA0LjAxCiAgICAgICAgICAgICAgU3BlY2lmaWNhdGlvbiIsIFdvcmxkIFdpZGUgV2ViIENv bnNvcnRpdW0KICAgICAgICAgICAgICBSZWNvbW1lbmRhdGlvbiBSRUMtaHRtbDQwMS0xOTk5MTIy NCwgRGVjZW1iZXIgMTk5OSwKICAgICAgICAgICAgICA8aHR0cDovL3d3dy53My5vcmcvVFIvMTk5 OS9SRUMtaHRtbDQwMS0xOTk5MTIyND4uCgoxMi4yLiAgSW5mb3JtYXRpdmUgUmVmZXJlbmNlcwoK ICAgW0ktRC5kcmFmdC1oYXJkdC1vYXV0aC0wMV0KICAgICAgICAgICAgICBIYXJkdCwgRC4sIEVk LiwgVG9tLCBBLiwgRWF0b24sIEIuLCBhbmQgWS4gR29sYW5kLCAiT0F1dGgKICAgICAgICAgICAg ICBXZWIgUmVzb3VyY2UgQXV0aG9yaXphdGlvbiBQcm9maWxlcyIsIEphbnVhcnkgMjAxMC4KCiAg IFtJLUQuaWV0Zi1odHRwYmlzLXA3LWF1dGhdCgoKCkhhbW1lciwgZXQgYWwuICAgICAgICAgIEV4 cGlyZXMgRGVjZW1iZXIgMjAsIDIwMTIgICAgICAgICAgICAgIFtQYWdlIDY0XQoMCkludGVybmV0 LURyYWZ0ICAgICAgICAgICAgICAgICAgT0F1dGggMi4wICAgICAgICAgICAgICAgICAgICAgIEp1 bmUgMjAxMgoKCiAgICAgICAgICAgICAgRmllbGRpbmcsIFIuLCBMYWZvbiwgWS4sIGFuZCBKLiBS ZXNjaGtlLCAiSFRUUC8xLjEsIHBhcnQKICAgICAgICAgICAgICA3OiBBdXRoZW50aWNhdGlvbiIs IGRyYWZ0LWlldGYtaHR0cGJpcy1wNy1hdXRoLTE5ICh3b3JrIGluCiAgICAgICAgICAgICAgcHJv Z3Jlc3MpLCBNYXJjaCAyMDEyLgoKICAgW0ktRC5pZXRmLW9hdXRoLXNhbWwyLWJlYXJlcl0KICAg ICAgICAgICAgICBNb3J0aW1vcmUsIEMuLCAiU0FNTCAyLjAgQmVhcmVyIEFzc2VydGlvbiBQcm9m aWxlcyBmb3IKICAgICAgICAgICAgICBPQXV0aCAyLjAiLCBkcmFmdC1pZXRmLW9hdXRoLXNhbWwy LWJlYXJlci0xMiAod29yayBpbgogICAgICAgICAgICAgIHByb2dyZXNzKSwgTWF5IDIwMTIuCgog ICBbSS1ELmlldGYtb2F1dGgtdjItYmVhcmVyXQogICAgICAgICAgICAgIEpvbmVzLCBNLiwgSGFy ZHQsIEQuLCBhbmQgRC4gUmVjb3Jkb24sICJUaGUgT0F1dGggMi4wCiAgICAgICAgICAgICAgQXV0 aG9yaXphdGlvbiBGcmFtZXdvcms6IEJlYXJlciBUb2tlbiBVc2FnZSIsCiAgICAgICAgICAgICAg ZHJhZnQtaWV0Zi1vYXV0aC12Mi1iZWFyZXItMjAgKHdvcmsgaW4gcHJvZ3Jlc3MpLAogICAgICAg ICAgICAgIEp1bmUgMjAxMi4KCiAgIFtJLUQuaWV0Zi1vYXV0aC12Mi1odHRwLW1hY10KICAgICAg ICAgICAgICBIYW1tZXItTGFoYXYsIEUuLCAiSFRUUCBBdXRoZW50aWNhdGlvbjogTUFDIEFjY2Vz cwogICAgICAgICAgICAgIEF1dGhlbnRpY2F0aW9uIiwgZHJhZnQtaWV0Zi1vYXV0aC12Mi1odHRw LW1hYy0wMSAod29yayBpbgogICAgICAgICAgICAgIHByb2dyZXNzKSwgRmVicnVhcnkgMjAxMi4K CiAgIFtJLUQuaWV0Zi1vYXV0aC12Mi10aHJlYXRtb2RlbF0KICAgICAgICAgICAgICBMb2RkZXJz dGVkdCwgVC4sIE1jR2xvaW4sIE0uLCBhbmQgUC4gSHVudCwgIk9BdXRoIDIuMAogICAgICAgICAg ICAgIFRocmVhdCBNb2RlbCBhbmQgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMiLAogICAgICAgICAg ICAgIGRyYWZ0LWlldGYtb2F1dGgtdjItdGhyZWF0bW9kZWwtMDUgKHdvcmsgaW4gcHJvZ3Jlc3Mp LAogICAgICAgICAgICAgIE1heSAyMDEyLgoKICAgW1JGQzU4NDldICBIYW1tZXItTGFoYXYsIEUu LCAiVGhlIE9BdXRoIDEuMCBQcm90b2NvbCIsIFJGQyA1ODQ5LAogICAgICAgICAgICAgIEFwcmls IDIwMTAuCgoKQXBwZW5kaXggQS4gIEF1Z21lbnRlZCBCYWNrdXMtTmF1ciBGb3JtIChBQk5GKSBT eW50YXgKCiAgIFRoaXMgc2VjdGlvbiBwcm92aWRlcyBBdWdtZW50ZWQgQmFja3VzLU5hdXIgRm9y bSAoQUJORikgc3ludGF4CiAgIGRlc2NyaXB0aW9ucyBmb3IgdGhlIGVsZW1lbnRzIGRlZmluZWQg aW4gdGhpcyBzcGVjaWZpY2F0aW9uIHVzaW5nIHRoZQogICBub3RhdGlvbiBvZiBbUkZDNTIzNF0u ICBFbGVtZW50cyBhcmUgcHJlc2VudGVkIGluIHRoZSBvcmRlciBmaXJzdAogICBkZWZpbmVkLgoK ICAgU29tZSBvZiB0aGUgZGVmaW5pdGlvbnMgdGhhdCBmb2xsb3cgdXNlIHRoZSAiVVJJLXJlZmVy ZW5jZSIKICAgZGVmaW5pdGlvbiBmcm9tIFtSRkMzOTg2XS4KCiAgIFNvbWUgb2YgdGhlIGRlZmlu aXRpb25zIHRoYXQgZm9sbG93IHVzZSB0aGVzZSBjb21tb24gZGVmaW5pdGlvbnM6CgpWU0NIQVIg ICAgID0gJTIwLTdFCk5RQ0hBUiAgICAgPSAleDIxIC8gJXgyMy01QiAvICV4NUQtN0UKTlFTQ0hB UiAgICA9ICV4MjAtMjEgLyAleDIzLTVCIC8gJXg1RC03RQpVTklDT0RFTk9DVFJMQ0hBUiA9IDxB bnkgVW5pY29kZSBjaGFyYWN0ZXIgb3RoZXIgdGhhbiAoICV4MC0xRiAvICV4N0YgKT4KCgoKCgpI YW1tZXIsIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIERlY2VtYmVyIDIwLCAyMDEyICAgICAgICAg ICAgICBbUGFnZSA2NV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgIE9BdXRoIDIu MCAgICAgICAgICAgICAgICAgICAgICBKdW5lIDIwMTIKCgpBLjEuICAiY2xpZW50X2lkIiBTeW50 YXgKCiAgIFRoZSAiY2xpZW50X2lkIiBlbGVtZW50IGlzIGRlZmluZWQgaW4gU2VjdGlvbiAyLjMu MToKCiAgIGNsaWVudC1pZCAgICAgPSAqVlNDSEFSCgpBLjIuICAiY2xpZW50X3NlY3JldCIgU3lu dGF4CgogICBUaGUgImNsaWVudF9zZWNyZXQiIGVsZW1lbnQgaXMgZGVmaW5lZCBpbiBTZWN0aW9u IDIuMy4xOgoKICAgY2xpZW50LXNlY3JldCA9ICpWU0NIQVIKCkEuMy4gICJyZXNwb25zZV90eXBl IiBTeW50YXgKCiAgIFRoZSAicmVzcG9uc2VfdHlwZSIgZWxlbWVudCBpcyBkZWZpbmVkIGluIFNl Y3Rpb24gMy4xLjEgYW5kCiAgIFNlY3Rpb24gOC40OgoKICAgcmVzcG9uc2UtdHlwZSA9IHJlc3Bv bnNlLW5hbWUgKiggU1AgcmVzcG9uc2UtbmFtZSApCiAgIHJlc3BvbnNlLW5hbWUgPSAxKnJlc3Bv bnNlLWNoYXIKICAgcmVzcG9uc2UtY2hhciA9ICJfIiAvIERJR0lUIC8gQUxQSEEKCkEuNC4gICJz Y29wZSIgU3ludGF4CgogICBUaGUgInNjb3BlIiBlbGVtZW50IGlzIGRlZmluZWQgaW4gU2VjdGlv biAzLjM6CgogICBzY29wZSAgICAgICA9IHNjb3BlLXRva2VuICooIFNQIHNjb3BlLXRva2VuICkK ICAgc2NvcGUtdG9rZW4gPSAxKk5RQ0hBUgoKQS41LiAgInN0YXRlIiBTeW50YXgKCiAgIFRoZSAi c3RhdGUiIGVsZW1lbnQgaXMgZGVmaW5lZCBpbiBTZWN0aW9uIDQuMS4xLCBTZWN0aW9uIDQuMS4y LAogICBTZWN0aW9uIDQuMS4yLjEsIFNlY3Rpb24gNC4yLjEsIFNlY3Rpb24gNC4yLjIsIGFuZCBT ZWN0aW9uIDQuMi4yLjE6CgogICBzdGF0ZSAgICAgID0gMSpWU0NIQVIKCkEuNi4gICJyZWRpcmVj dF91cmkiIFN5bnRheAoKICAgVGhlICJyZWRpcmVjdF91cmkiIGVsZW1lbnQgaXMgZGVmaW5lZCBp biBTZWN0aW9uIDQuMS4xLAogICBTZWN0aW9uIDQuMS4zLCBhbmQgU2VjdGlvbiA0LjIuMToKCiAg IHJlZGlyZWN0LXVyaSAgICAgID0gVVJJLXJlZmVyZW5jZQoKCgoKCgoKCgoKSGFtbWVyLCBldCBh bC4gICAgICAgICAgRXhwaXJlcyBEZWNlbWJlciAyMCwgMjAxMiAgICAgICAgICAgICAgW1BhZ2Ug NjZdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICBPQXV0aCAyLjAgICAgICAgICAg ICAgICAgICAgICAgSnVuZSAyMDEyCgoKQS43LiAgImVycm9yIiBTeW50YXgKCiAgIFRoZSAiZXJy b3IiIGVsZW1lbnQgaXMgZGVmaW5lZCBpbiBTZWN0aW9uIDQuMS4yLjEsIFNlY3Rpb24gNC4yLjIu MSwKICAgU2VjdGlvbiA1LjIsIFNlY3Rpb24gNy4yLCBhbmQgU2VjdGlvbiA4LjU6CgogICBlcnJv ciAgICAgICAgICAgICA9IDEqTlFTQ0hBUgoKQS44LiAgImVycm9yX2Rlc2NyaXB0aW9uIiBTeW50 YXgKCiAgIFRoZSAiZXJyb3JfZGVzY3JpcHRpb24iIGVsZW1lbnQgaXMgZGVmaW5lZCBpbiBTZWN0 aW9uIDQuMS4yLjEsCiAgIFNlY3Rpb24gNC4yLjIuMSwgU2VjdGlvbiA1LjIsIGFuZCBTZWN0aW9u IDcuMjoKCiAgIGVycm9yLWRlc2NyaXB0aW9uID0gMSpOUVNDSEFSCgpBLjkuICAiZXJyb3JfdXJp IiBTeW50YXgKCiAgIFRoZSAiZXJyb3JfdXJpIiBlbGVtZW50IGlzIGRlZmluZWQgaW4gU2VjdGlv biA0LjEuMi4xLAogICBTZWN0aW9uIDQuMi4yLjEsIFNlY3Rpb24gNS4yLCBhbmQgU2VjdGlvbiA3 LjI6CgogICBlcnJvci11cmkgICAgICAgICA9IFVSSS1yZWZlcmVuY2UKCkEuMTAuICAiZ3JhbnRf dHlwZSIgU3ludGF4CgogICBUaGUgImdyYW50X3R5cGUiIGVsZW1lbnQgaXMgZGVmaW5lZCBpbiBT ZWN0aW9uIDQuMS4zLCBTZWN0aW9uIDQuMy4yLAogICBTZWN0aW9uIDQuNC4yLCBTZWN0aW9uIDYs IGFuZCBTZWN0aW9uIDQuNToKCiAgIGdyYW50LXR5cGUgPSBncmFudC1uYW1lIC8gVVJJLXJlZmVy ZW5jZQogICBncmFudC1uYW1lID0gMSpuYW1lLWNoYXIKICAgbmFtZS1jaGFyICA9ICItIiAvICIu IiAvICJfIiAvIERJR0lUIC8gQUxQSEEKCkEuMTEuICAiY29kZSIgU3ludGF4CgogICBUaGUgImNv ZGUiIGVsZW1lbnQgaXMgZGVmaW5lZCBpbiBTZWN0aW9uIDQuMS4zOgoKICAgY29kZSAgICAgICA9 IDEqVlNDSEFSCgpBLjEyLiAgImFjY2Vzc190b2tlbiIgU3ludGF4CgogICBUaGUgImFjY2Vzc190 b2tlbiIgZWxlbWVudCBpcyBkZWZpbmVkIGluIFNlY3Rpb24gNC4yLjIgYW5kCiAgIFNlY3Rpb24g NS4xOgoKICAgYWNjZXNzLXRva2VuID0gMSpWU0NIQVIKCgoKCgoKCgoKSGFtbWVyLCBldCBhbC4g ICAgICAgICAgRXhwaXJlcyBEZWNlbWJlciAyMCwgMjAxMiAgICAgICAgICAgICAgW1BhZ2UgNjdd CgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICBPQXV0aCAyLjAgICAgICAgICAgICAg ICAgICAgICAgSnVuZSAyMDEyCgoKQS4xMy4gICJ0b2tlbl90eXBlIiBTeW50YXgKCiAgIFRoZSAi dG9rZW5fdHlwZSIgZWxlbWVudCBpcyBkZWZpbmVkIGluIFNlY3Rpb24gNC4yLjIsIFNlY3Rpb24g NS4xLAogICBhbmQgU2VjdGlvbiA4LjE6CgogICB0b2tlbi10eXBlID0gdHlwZS1uYW1lIC8gVVJJ LXJlZmVyZW5jZQogICB0eXBlLW5hbWUgID0gMSpuYW1lLWNoYXIKICAgbmFtZS1jaGFyICA9ICIt IiAvICIuIiAvICJfIiAvIERJR0lUIC8gQUxQSEEKCkEuMTQuICAiZXhwaXJlc19pbiIgU3ludGF4 CgogICBUaGUgImV4cGlyZXNfaW4iIGVsZW1lbnQgaXMgZGVmaW5lZCBpbiBTZWN0aW9uIDQuMi4y IGFuZCBTZWN0aW9uIDUuMToKCiAgIGV4cGlyZXMtaW4gPSAxKkRJR0lUCgpBLjE1LiAgInVzZXJu YW1lIiBTeW50YXgKCiAgIFRoZSAidXNlcm5hbWUiIGVsZW1lbnQgaXMgZGVmaW5lZCBpbiBTZWN0 aW9uIDQuMy4yOgoKICAgdXNlcm5hbWUgPSAqVU5JQ09ERU5PQ1RSTENIQVIKCkEuMTYuICAicGFz c3dvcmQiIFN5bnRheAoKICAgVGhlICJwYXNzd29yZCIgZWxlbWVudCBpcyBkZWZpbmVkIGluIFNl Y3Rpb24gNC4zLjI6CgogICBwYXNzd29yZCA9ICpVTklDT0RFTk9DVFJMQ0hBUgoKQS4xNy4gICJy ZWZyZXNoX3Rva2VuIiBTeW50YXgKCiAgIFRoZSAicmVmcmVzaF90b2tlbiIgZWxlbWVudCBpcyBk ZWZpbmVkIGluIFNlY3Rpb24gNS4xIGFuZCBTZWN0aW9uIDY6CgogICByZWZyZXNoLXRva2VuID0g MSpWU0NIQVIKCkEuMTguICBFbmRwb2ludCBQYXJhbWV0ZXIgU3ludGF4CgogICBUaGUgc3ludGF4 IGZvciBuZXcgZW5kcG9pbnQgcGFyYW1ldGVycyBpcyBkZWZpbmVkIGluIFNlY3Rpb24gOC4yOgoK ICAgcGFyYW0tbmFtZSA9IDEqbmFtZS1jaGFyCiAgIG5hbWUtY2hhciAgPSAiLSIgLyAiLiIgLyAi XyIgLyBESUdJVCAvIEFMUEhBCgoKQXBwZW5kaXggQi4gIEFja25vd2xlZGdlbWVudHMKCiAgIFRo ZSBpbml0aWFsIE9BdXRoIDIuMCBwcm90b2NvbCBzcGVjaWZpY2F0aW9uIHdhcyBlZGl0ZWQgYnkg RGF2aWQKICAgUmVjb3Jkb24sIGJhc2VkIG9uIHR3byBwcmV2aW91cyBwdWJsaWNhdGlvbnM6IHRo ZSBPQXV0aCAxLjAgY29tbXVuaXR5CiAgIHNwZWNpZmljYXRpb24gW1JGQzU4NDldLCBhbmQgT0F1 dGggV1JBUCAoT0F1dGggV2ViIFJlc291cmNlCiAgIEF1dGhvcml6YXRpb24gUHJvZmlsZXMpIFtJ LUQuZHJhZnQtaGFyZHQtb2F1dGgtMDFdLiAgVGhlIFNlY3VyaXR5CiAgIENvbnNpZGVyYXRpb25z IHNlY3Rpb24gd2FzIGRyYWZ0ZWQgYnkgVG9yc3RlbiBMb2RkZXJzdGVkdCwgTWFyawoKCgpIYW1t ZXIsIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIERlY2VtYmVyIDIwLCAyMDEyICAgICAgICAgICAg ICBbUGFnZSA2OF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgIE9BdXRoIDIuMCAg ICAgICAgICAgICAgICAgICAgICBKdW5lIDIwMTIKCgogICBNY0dsb2luLCBQaGlsIEh1bnQsIGFu ZCBBbnRob255IE5hZGFsaW4uICBUaGUgQUJORiBzZWN0aW9uIHdhcwogICBkcmFmdGVkIGJ5IE1p Y2hhZWwgQi4gSm9uZXMuCgogICBUaGUgT0F1dGggMS4wIGNvbW11bml0eSBzcGVjaWZpY2F0aW9u IHdhcyBlZGl0ZWQgYnkgRXJhbiBIYW1tZXIgYW5kCiAgIGF1dGhvcmVkIGJ5IE1hcmsgQXR3b29k LCBEaXJrIEJhbGZhbnosIERhcnJlbiBCb3VuZHMsIFJpY2hhcmQgTS4KICAgQ29ubGFuLCBCbGFp bmUgQ29vaywgTGVhaCBDdWx2ZXIsIEJyZW5vIGRlIE1lZGVpcm9zLCBCcmlhbiBFYXRvbiwKICAg S2VsbGFuIEVsbGlvdHQtTWNDcmVhLCBMYXJyeSBIYWxmZiwgRXJhbiBIYW1tZXIsIEJlbiBMYXVy aWUsIENocmlzCiAgIE1lc3NpbmEsIEpvaG4gUGFuemVyLCBTYW0gUXVpZ2xleSwgRGF2aWQgUmVj b3Jkb24sIEVyYW4gU2FuZGxlciwKICAgSm9uYXRoYW4gU2VyZ2VudCwgVG9kZCBTaWVsaW5nLCBC cmlhbiBTbGVzaW5za3ksIGFuZCBBbmR5IFNtaXRoLgoKICAgVGhlIE9BdXRoIFdSQVAgc3BlY2lm aWNhdGlvbiB3YXMgZWRpdGVkIGJ5IERpY2sgSGFyZHQgYW5kIGF1dGhvcmVkIGJ5CiAgIEJyaWFu IEVhdG9uLCBZYXJvbiBZLiBHb2xhbmQsIERpY2sgSGFyZHQsIGFuZCBBbGxlbiBUb20uCgogICBU aGlzIHNwZWNpZmljYXRpb24gaXMgdGhlIHdvcmsgb2YgdGhlIE9BdXRoIFdvcmtpbmcgR3JvdXAg d2hpY2gKICAgaW5jbHVkZXMgZG96ZW5zIG9mIGFjdGl2ZSBhbmQgZGVkaWNhdGVkIHBhcnRpY2lw YW50cy4gIEluIHBhcnRpY3VsYXIsCiAgIHRoZSBmb2xsb3dpbmcgaW5kaXZpZHVhbHMgY29udHJp YnV0ZWQgaWRlYXMsIGZlZWRiYWNrLCBhbmQgd29yZGluZwogICB3aGljaCBzaGFwZWQgYW5kIGZv cm1lZCB0aGUgZmluYWwgc3BlY2lmaWNhdGlvbjoKCiAgIE1pY2hhZWwgQWRhbXMsIEFtYW5kYSBB bmdhbmVzLCBBbmRyZXcgQXJub3R0LCBEaXJrIEJhbGZhbnosIEFpZGVuCiAgIEJlbGwsIEpvaG4g QnJhZGxleSwgQnJpYW4gQ2FtcGJlbGwsIFNjb3R0IENhbnRvciwgTWFyY29zIENhY2VyZXMsCiAg IEJsYWluZSBDb29rLCBSb2dlciBDcmV3LCBCcmlhbiBFYXRvbiwgV2VzbGV5IEVkZHksIExlYWgg Q3VsdmVyLCBCaWxsCiAgIGRlIGhPcmEsIEFuZHJlIERlTWFycmUsIEJyaWFuIEVhdG9uLCBXb2x0 ZXIgRWxkZXJpbmcsIEJyaWFuIEVsbGluLAogICBJZ29yIEZheW5iZXJnLCBHZW9yZ2UgRmxldGNo ZXIsIFRpbSBGcmVlbWFuLCBMdWNhIEZyb3NpbmksIEV2YW4KICAgR2lsYmVydCwgWWFyb24gWS4g R29sYW5kLCBCcmVudCBHb2xkbWFuLCBLcmlzdG9mZmVyIEdyb25vd3NraSwgSnVzdGluCiAgIEhh cnQsIERpY2sgSGFyZHQsIENyYWlnIEhlYXRoLCBQaGlsIEh1bnQsIE1pY2hhZWwgQi4gSm9uZXMs IFRlcnJ5CiAgIEpvbmVzLCBKb2huIEtlbXAsIE1hcmsgS2VudCwgUmFmZmkgS3Jpa29yaWFuLCBD aGFzZW4gTGUgSGFyYSwgUmFzbXVzCiAgIExlcmRvcmYsIFRvcnN0ZW4gTG9kZGVyc3RlZHQsIEh1 aS1MYW4gTHUsIENhc2V5IEx1Y2FzLCBQYXVsIE1hZHNlbiwKICAgQWxhc3RhaXIgTWFpciwgRXZl IE1hbGVyLCBKYW1lcyBNYW5nZXIsIE1hcmsgTWNHbG9pbiwgTGF1cmVuY2UgTWlhbywKICAgV2ls bGlhbSBNaWxscywgQ2h1Y2sgTW9ydGltb3JlLCBBbnRob255IE5hZGFsaW4sIEp1bGlhbiBSZXNj aGtlLAogICBKdXN0aW4gUmljaGVyLCBQZXRlciBTYWludC1BbmRyZSwgTmF0IFNha2ltdXJhLCBS b2IgU2F5cmUsIE1hcml1cwogICBTY3VydGVzY3UsIE5haXRpayBTaGFoLCBMdWtlIFNoZXBhcmQs IFZsYWQgU2t2b3J0c292LCBKdXN0aW4gU21pdGgsCiAgIEhhaWJpbiBTb25nLCBOaXYgU3RlaW5n YXJ0ZW4sIENocmlzdGlhbiBTdHVlYm5lciwgSmVyZW15IFN1cmllbCwgUGF1bAogICBUYXJqYW4s IENocmlzdG9waGVyIFRob21hcywgSGVucnkgUy4gVGhvbXBzb24sIEFsbGVuIFRvbSwgRnJhbmts aW4KICAgVHNlLCBOaWNrIFdhbGtlciwgU2hhbmUgV2VlZGVuLCBhbmQgU2t5bGFyIFdvb2R3YXJk LgoKICAgVGhpcyBkb2N1bWVudCB3YXMgcHJvZHVjZWQgdW5kZXIgdGhlIGNoYWlybWFuc2hpcCBv ZiBCbGFpbmUgQ29vaywKICAgUGV0ZXIgU2FpbnQtQW5kcmUsIEhhbm5lcyBUc2Nob2ZlbmlnLCBC YXJyeSBMZWliYSwgYW5kIERlcmVrIEF0a2lucy4KICAgVGhlIGFyZWEgZGlyZWN0b3JzIGluY2x1 ZGVkIExpc2EgRHVzc2VhdWx0LCBQZXRlciBTYWludC1BbmRyZSwgYW5kCiAgIFN0ZXBoZW4gRmFy cmVsbC4KCgpBcHBlbmRpeCBDLiAgRWRpdG9yJ3MgTm90ZXMKCiAgIFdoaWxlIG1hbnkgcGVvcGxl IGNvbnRyaWJ1dGVkIHRvIHRoaXMgc3BlY2lmaWNhdGlvbiB0aHJvdWdob3V0IGl0cwogICBsb25n IGpvdXJuZXksIHRoZSBlZGl0b3Igd291bGQgbGlrZSB0byBhY2tub3dsZWRnZSBhbmQgdGhhbmsg YSBmZXcKICAgaW5kaXZpZHVhbHMgZm9yIHRoZWlyIG91dHN0YW5kaW5nIGFuZCBpbnZhbHVhYmxl IGVmZm9ydHMgbGVhZGluZyB1cAogICB0byB0aGUgcHVibGljYXRpb24gb2YgdGhpcyBzcGVjaWZp Y2F0aW9uLgoKCgoKSGFtbWVyLCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBEZWNlbWJlciAyMCwg MjAxMiAgICAgICAgICAgICAgW1BhZ2UgNjldCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAg ICAgICBPQXV0aCAyLjAgICAgICAgICAgICAgICAgICAgICAgSnVuZSAyMDEyCgoKICAgRGF2aWQg UmVjb3Jkb24gZm9yIGNvbnRpbnVvdXNseSBiZWluZyBvbmUgb2YgT0F1dGgncyBtb3N0IHZhbHVh YmxlCiAgIGFzc2V0cywgYnJpbmdpbmcgcHJhZ21hdGlzbSBhbmQgdXJnZW5jeSB0byB0aGUgd29y aywgYW5kIGhlbHBpbmcKICAgc2hhcGUgaXQgZnJvbSBpdHMgdmVyeSBiZWdpbm5pbmcsIGFzIHdl bGwgYXMgYmVpbmcgb25lIG9mIHRoZSBiZXN0CiAgIGNvbGxhYm9yYXRvcnMgSSBoYWQgdGhlIHBs ZWFzdXJlIG9mIHdvcmtpbmcgd2l0aC4KCiAgIEphbWVzIE1hbmdlciBmb3IgaGlzIGNyZWF0aXZl IGlkZWFzIGFuZCBhbHdheXMgaW5zaWdodGZ1bCBmZWVkYmFjay4KICAgQnJpYW4gQ2FtcGJlbGws IFRvcnN0ZW4gTG9kZGVyc3RlZHQsIENodWNrIE1vcnRpbW9yZSwgSnVzdGluIFJpY2hlciwKICAg TWFyaXVzIFNjdXJ0ZXNjdSwgYW5kIEx1a2UgU2hlcGFyZCBmb3IgdGhlaXIgY29udGludWVkIHBh cnRpY2lwYXRpb24KICAgYW5kIHZhbHVhYmxlIGZlZWRiYWNrLgoKICAgU3BlY2lhbCB0aGFua3Mg Z29lcyB0byBNaWtlIEN1cnRpcyBhbmQgWWFob28hIGZvciB0aGVpciB1bmNvbmRpdGlvbmFsCiAg IHN1cHBvcnQgb2YgdGhpcyB3b3JrIGZvciBvdmVyIHRocmVlIHllYXJzLgoKCkF1dGhvcnMnIEFk ZHJlc3NlcwoKICAgRXJhbiBIYW1tZXIgKGVkaXRvcikKCiAgIEVtYWlsOiBlcmFuQGh1ZW5pdmVy c2UuY29tCiAgIFVSSTogICBodHRwOi8vaHVlbml2ZXJzZS5jb20KCgogICBEYXZpZCBSZWNvcmRv bgogICBGYWNlYm9vawoKICAgRW1haWw6IGRyQGZiLmNvbQogICBVUkk6ICAgaHR0cDovL3d3dy5k YXZpZHJlY29yZG9uLmNvbS8KCgogICBEaWNrIEhhcmR0CiAgIE1pY3Jvc29mdAoKICAgRW1haWw6 IGRpY2suaGFyZHRAZ21haWwuY29tCiAgIFVSSTogICBodHRwOi8vZGlja2hhcmR0Lm9yZy8KCgoK CgoKCgoKCgoKCgoKCgpIYW1tZXIsIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIERlY2VtYmVyIDIw LCAyMDEyICAgICAgICAgICAgICBbUGFnZSA3MF0KDAo= --_007_4E1F6AAD24975D4BA5B16804296739436655A85ETK5EX14MBXC283r_ Content-Type: application/pdf; name="draft-ietf-oauth-v2-28-preliminary.pdf" Content-Description: draft-ietf-oauth-v2-28-preliminary.pdf Content-Disposition: attachment; filename="draft-ietf-oauth-v2-28-preliminary.pdf"; size=444597; creation-date="Mon, 18 Jun 2012 22:51:52 GMT"; modification-date="Mon, 18 Jun 2012 22:48:30 GMT" Content-Transfer-Encoding: base64 JVBERi0xLjQKMSAwIG9iago8PAovVGl0bGUgKP7/AFQAaABlACAATwBBAHUAdABoACAAMgAuADAA IABBAHUAdABoAG8AcgBpAHoAYQB0AGkAbwBuACAARgByAGEAbQBlAHcAbwByAGspCi9DcmVhdG9y ICj+/ykKL1Byb2R1Y2VyICj+/wB3AGsAaAB0AG0AbAB0AG8AcABkAGYpCi9DcmVhdGlvbkRhdGUg KEQ6MjAxMjA2MTkwMDQ4MTUrMDInMDAnKQo+PgplbmRvYmoKMyAwIG9iago8PAovVHlwZSAvRXh0 R1N0YXRlCi9TQSB0cnVlCi9TTSAwLjAyCi9jYSAxLjAKL0NBIDEuMAovQUlTIGZhbHNlCi9TTWFz ayAvTm9uZT4+CmVuZG9iago0IDAgb2JqClsvUGF0dGVybiAvRGV2aWNlUkdCXQplbmRvYmoKMTEg MCBvYmoKWzAgL1hZWiA0Ny41MTk5OTk5ICAKNjg4Ljg3OTk5OSAgMF0KZW5kb2JqCjEyIDAgb2Jq ClswIC9YWVogNDcuNTE5OTk5OSAgCjU5OS41OTk5OTkgIDBdCmVuZG9iagoxMyAwIG9iagpbMCAv WFlaIDQ3LjUxOTk5OTkgIAoxNzYuMjM5OTk5ICAwXQplbmRvYmoKMTQgMCBvYmoKWzAgL1hZWiA0 Ny41MTk5OTk5ICAKNTA0LjU1OTk5OSAgMF0KZW5kb2JqCjE1IDAgb2JqClswIC9YWVogNDcuNTE5 OTk5OSAgCjM0NS4xOTk5OTkgIDBdCmVuZG9iagoxNiAwIG9iagpbMCAvWFlaIDQ3LjUxOTk5OTkg IAoyMDYuOTU5OTk5ICAwXQplbmRvYmoKMTcgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBl IC9MaW5rCi9SZWN0IFs1MjIuNzIwMDAwICA3ODIuOTU5OTk5ICA1NDMuODQwMDAwICA3OTAuNjM5 OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJm Q0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIz dG9jCj4+CmVuZG9iagoxOCAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1Jl Y3QgWzc4LjIzOTk5OTkgIDEzOS43NTk5OTkgIDg4Ljc5OTk5OTkgIDE1MC4zMTk5OTkgXQovQm9y ZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAz NzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjNhbmNob3IxCj4+ CmVuZG9iagoxOSAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzkz LjU5OTk5OTkgIDEyOC4yMzk5OTkgIDExNC43MTk5OTkgIDEzOC43OTk5OTkgXQovQm9yZGVyIFsw IDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGly IzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjNhbmNob3IyCj4+CmVuZG9i agoyMCAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzkzLjU5OTk5 OTkgIDExNi43MTk5OTkgIDExNC43MTk5OTkgIDEyNy4yNzk5OTkgXQovQm9yZGVyIFswIDAgMF0K L0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJh ZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjNhbmNob3IzCj4+CmVuZG9iagoyMSAw IG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzkzLjU5OTk5OTkgIDEw NS4xOTk5OTkgIDExNC43MTk5OTkgIDExNS43NTk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3Qg L2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRp ZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjNhbmNob3I0Cj4+CmVuZG9iagoyMiAwIG9iago8 PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzEwOC45NTk5OTkgIDkzLjY3OTk5 OTkgIDE0MC42Mzk5OTkgIDEwNC4yMzk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUj M2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJk b2F1dGgjMmR2Mi5odG1sLmh0bWwjMjNhbmNob3I1Cj4+CmVuZG9iagoyMyAwIG9iago8PAovVHlw ZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzEwOC45NTk5OTkgIDgyLjE1OTk5OTkgIDE0 MC42Mzk5OTkgIDkyLjcxOTk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYj MmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgj MmR2Mi5odG1sLmh0bWwjMjNhbmNob3I2Cj4+CmVuZG9iagoyNCAwIG9iago8PAovVHlwZSAvQW5u b3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzEwOC45NTk5OTkgIDcwLjYzOTk5OTkgIDE0MC42Mzk5 OTkgIDgxLjE5OTk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2 YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5o dG1sLmh0bWwjMjNhbmNob3I3Cj4+CmVuZG9iagoyNSAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1 YnR5cGUgL0xpbmsKL1JlY3QgWzEwOC45NTk5OTkgIDU5LjExOTk5OTkgIDE0MC42Mzk5OTkgIDY5 LjY3OTk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0 bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0 bWwjMjNhbmNob3I4Cj4+CmVuZG9iagoyNiAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUg L0xpbmsKL1JlY3QgWzkzLjU5OTk5OTkgIDQ3LjU5OTk5OTkgIDExNC43MTk5OTkgIDU4LjE1OTk5 OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZD R0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjNh bmNob3I5Cj4+CmVuZG9iagoyNyAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsK L1JlY3QgWzkzLjU5OTk5OTkgIDM2LjA3OTk5OTkgIDExNC43MTk5OTkgIDQ2LjYzOTk5OTkgXQov Qm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1w NTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjNhbmNob3Ix MAo+PgplbmRvYmoKMjggMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0 IFs4OS43NTk5OTk5ICA3NTcuMDM5OTk5ICAxMDcuOTk5OTk5ICA3NjQuNzE5OTk5IF0KL0JvcmRl ciBbMCAwIDBdCi9BIDw8Ci9UeXBlIC9BY3Rpb24KL1MgL1VSSQovVVJJIChodHRwOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9yZmM1ODQ5KQo+Pgo+PgplbmRvYmoKNSAwIG9iago8PAovVHlwZSAvUGFn ZQovUGFyZW50IDIgMCBSCi9Db250ZW50cyAyOSAwIFIKL1Jlc291cmNlcyAzMSAwIFIKL0Fubm90 cyAzMiAwIFIKL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KPj4KZW5kb2JqCjMxIDAgb2JqCjw8Ci9D b2xvclNwYWNlIDw8Ci9QQ1NwIDQgMCBSCi9DU3AgL0RldmljZVJHQgovQ1NwZyAvRGV2aWNlR3Jh eQo+PgovRXh0R1N0YXRlIDw8Ci9HU2EgMyAwIFIKPj4KL1BhdHRlcm4gPDwKPj4KL0ZvbnQgPDwK L0Y2IDYgMCBSCi9GNyA3IDAgUgovRjggOCAwIFIKL0Y5IDkgMCBSCi9GMTAgMTAgMCBSCj4+Ci9Y T2JqZWN0IDw8Cj4+Cj4+CmVuZG9iagozMiAwIG9iagpbIDE3IDAgUiAxOCAwIFIgMTkgMCBSIDIw IDAgUiAyMSAwIFIgMjIgMCBSIDIzIDAgUiAyNCAwIFIgMjUgMCBSIDI2IDAgUiAyNyAwIFIgMjgg MCBSIF0KZW5kb2JqCjI5IDAgb2JqCjw8Ci9MZW5ndGggMzAgMCBSCi9GaWx0ZXIgL0ZsYXRlRGVj b2RlCj4+CnN0cmVhbQp4nO1dy27kNhbd11doPUC7ReoNDAK4bfcAsxjAsIFZBFkEnekMgnYwThb5 /ZFUrDLrHlGHZFEquW07iW1GIi/v+0XWx388/Jz9+mf28ebhf9kX8/PmYZdf5VW3/8ry/vuDPaDb q0Lnw1fWquKqbsbRL0+75+x5d7+77/87/HzeHWbNx+8/v/y++7hfzzw1jD7t2q7uZ89zVfR/frP/ VLpruqt+KdWP5/LP4eH/7v79t+z32aWO/+eqzM2X83f7veed0lftOK7GScWf/X51kw3/KJ2pOvvj P7uv/b6WXK7M112vycpy3e2tul6T1Wrd7a26XpM17brbW3W9Juuqdbe36npNpvq1Vt3fugs2gz5f eYMzC9Z50WlV1a3zd3vBojALlJnqH+iN4LDU064oq+HXPK/68TKvB3gHa9XWqhx/13JcN6NF0/Y8 3xzzD/buqwVzV5gv5+8nMJ/ApowlfTpdq+z/yCdgOxm396KOFnl6fglzIjw7YHbB4KLLEniepvWT GPfB8zRvuHjpFOaDt9aBQ+QhLPVgh9vhH1UdROXe58XD+mr8tlfdjzzc/Kv33P7KdPbP/t/fsh9/ 6t/7xfLf8MVPj7uPn+t+q9nj12y/0If9j8c9oB+KLnv8Jfv7AMcP2eNvu8GPNAN6HGheBopxoH0Z KOUT+znuHk88WAdYjQOsXs8AVC2FqpZQWRup5BO1fKIZB7qXgVa+0slXrseB8mXgk3ziRs5xS+G4 k7uFZQEw2P7nFDQotUUElQucK+AVuRMlyaQknKoUOMcBoJvEhgIEAhwAeiPhSMWzVX2YsaWcIFmU bxXmwFdgUkDXtZQdeAKoBFxdpmKvI74M0c6nQFO4tIYC7N1K8ZWCpe4ojSgVYRX1eZphx71LuzPo e4X6vlVZU15VxpN72qneLlsD33YPXpZsarVZ6zI32Uia1kGaHmAgjYVFTTWaxXJL2UgXWw3ItYCX 6kXnkp5SXlCAQEU5NPjcADULeo/maoY3pSLUOpVkH/EFCocbDl3IVyTgupTYoMYa9oqv3CTSQd1x zRRWANQWWC9KVuQ3UH0AB3epwE74ajqL0pW0RhwOjg94hfIC4gMgrYPtJjLpdSrpOnKYppsHKJBd gClBMmAgyU56UVF54/LSdCvUF6pA0KtAk2hrPOMxcW2Ey4Jfy1050O/Akp2E41pOSn1jPof+JAe6 VFxsET/cSPDowsMEJHFkBzbWZVJHdsTOcU59I7gHGB9VDfUOPLzfZfz+AV2lSo+u45z6VioObkNo egDF4G5tYbuMR99lup70itv+L631qU+vwKm3R/Z0UOB2WFZ1TwidSywqi/sbmLiVAoJrw0odAAOh 8ScObyLobmBkz8TKQsSdXHtvuhRkOhQIdTczCyytkJRy2wp3APAiMEZDa/Ah7WdKYAAP3Bj5FWok mrfLHqAPuqpOJTt0t46EouUEcOKgxMAkchmcFSmMfBLDtbCSQpmCEQQPH7G8yxda7jsm8rGKNf37 qSLkz3sox7BFDVOpatJK1T1PdcJPUEqaW/ARW0mSSrIhENZKet1Oz3GKWzQjnsZjWqx6seiV0gQK qiGjrA9iZUxGIznMAtZRbbD4qwI1WUv+aigaYV1YppNPOFL/c3MAOSMAA3LeyVdkPANxFcLhCLQK 97IKSjJyt8ZClDOQSjiMeVBgHqxHZBzFEaIcKYZyZhXYHYBay4FGogwmbSkcQBh4gjMIkA7wIVnZ aFvrCWBlAAxoKQEzuitkt7AsDgCSgdlvL8LsLsU89wqsIlkKJ4W9wPa5WHIUohQChgAyYPbJHEGU uSjdDCOJjdSnQughlRG0BUg5Xe7AjoF1lAMmdTU3K+wODKqUZA3mgsuYnNQUHiBsmlG5HjzGnQPQ SlzoOGFALGFZAAzIL4UOjSOHlL/CzQcgiBspYHZwWsDAUP7w2C3kS4FQ4dRHo82NFHcvYLeUTxHJ wOvUV+JmDDCmuZcbrrcirDhuTiIZdZBDolLYl2OU72FNqd3zcHKBXxbxvrnWAo8NXGt4hfvJEQ4r Vw5vW2txoQSPfhEyvDUPhUfaKewLdxXAYadcl8QUpBDc1xatpjAnzRmW8T2+JewR44+sEyRG4JRG PDHLcgt0oQAH8qWwF54NBnagCEJSgrYA6gN/wLKwua2IKfeUuMrhDmuCzGaMD0MVCncDeZbWI7Xl 2O2ZxqPuh23r4Wt/U9is9hgCrVNN0YD18GpKRFjJrRjyOucgAAw4mdsXWJZXdajW9pCocPNq+ows T1JWVzQwDMwhOcg0+lkDEnTTJwMM8x1WiEvVHqiBARd4CLLciywO3QE8Syi7zQzPz8WoDh0AnQ1l ABwK2luQx7FWcTPBGKATFyxvl6U4tpbWodFwtiBBksojTQGcJ8Mw06OI/UpzuTBwpAB2rrPCfUAw YehJxNTAfItiwPJnmvChT8lmu4iiINABMMTTEjApt6XgBAIcPP3u0gBzy4Sn+niOJaapJEVWLkV2 nctUeHASE7zSEpfp7H0hA3gbPOOo5flacD8WCV+WAX3OLzrTjjWH3vw3ZnJi+nRo3O2hUCIamRLk eZFxeUwExsGjb4uyzCL6IoWG3Qr7I2BSX3iQn/sGtOjnEZtGlBvAVwbBhaCZ9vXh4cKIaj7ljyKX agkO54Bil7sFSAt5dNeVPz1X03cnqr7QoFF5EiVZHqrstHMRmoL2CB34VhK0GCGv87wUKFTI0vIg x8MPTlGN5JV2bmG4u8n7YXg+jOcp3430Akaa6u3NGtiL+ZcLqfayOFGpCQ5beNSnuSj7unUJDEr1 cr6YygeSlhfTOJ++8zrTF+H5vBjTD7xOs3dgg4tCTFqAJ8j1NgedPxHeYohGifs1oJQgBcSZjDcB UHsKxtEDyUswLi57GY0CcKTL+FTFoQz8rqWoyonI+CzBp6/ZVfTu8p7zN2jeNaKmEHGywiP8Knhk gJN4kCZBmozn+xF4DwzwBiYagK/TWpQkePboowPYeeAf4UHQsqOevO0yymRUAbZtkdYzx97SNnZv pvWMc3KKI05LpMVekV2KiS+4EuJ04Ce6+P55my34dov0XHgUGpY4OObxCoQx4Qo1SXs8MDc/CLPx ZEIKe1IfQ5CtePoer3DTB4BxBUo1W0wXC/dzYo44UpHizUIxRjlc6HhrfxLh5weAI7z4Zc7Dh9fZ Yo7gUBEq5OWqy9zzEtEZF9FexQuAEQeOpF0vkh2ArjpxLfd7w+oZFiaiczCitxK2C/E5Mi49ahlz 4JkfGEAs8wNXXF96BNtc+UFIInHmEUzyOQAwx1Vi3+FZhlofPt7B5Pqs2+7glIFBtjXguPysljQu JbLhzkK4g3GuRFdSUF01GfA0gD8vdy6hro79nHBCh4ZRGL1SJxCpx2twtLUKVAX2SS0iodSoRbR4 efTAAZJ50JgiVbHOdRL0IC5afZ5ki+hC5yWFiLp/+JHhmPN7EbFqCsptJZXnkblb4obN1Rp4ms5W 23ASN8ZvXEJtG3wkCEXqRjsB5cewIy6O4TKXLLXV5G49n+Kig+0K5Son9oqW6lN+8VaCFNMrPqG0 yGGJzTpGBXw4CM9SwecDwLVS4TeluI49B6WcNnKiD24HQCGkNd9lLjaMEORoTk5hLNRMHWSzhVMI 1y7UdunRMhkRSPGDUa+nZTLinjFej6IOGaRguWjz7i2PDEDELWK0gsdLejH+Roqb2VIEdClq4hFt aJAS4Bc1bPbGvEUOqzrMegqLU7i54VKRxDJhtdLVyXbhFC1v1OJ5Fy4eNMDlTp3Hp2OkKFaHb24z LOQRanL1ENHeEX59CmTYPWpPq6T/PBpfN3LhGQIGoIdfC71qCi1Fm3MKW1BWzs1y7RBxdneJK9E9 RJ9W5mPu9Ilo9oi4knSJ1FW8//Eq8pK8M5bXRammi5kUmxuAIbj/uUgjNO0ySXE4MUnbO/+wMY72 NyEQKcxDPQNHigo1zwrAAVfw2QGOcNEt5OcxejTkx1zpvkRpGMoQsJmJxCLPd6+SJvKQwwjFlMB7 3oqju8jNvsjtEV5IgsQJ3P2LhnuJ3FOSz7tYpYEnYRUqhTFojh+S/HrrVkmqpymOiC9ymSfXWty/ ShEq8eA7opmaY517pNxVjrg5621bkxTq9N3/upD/9d32o7el+OhxqysHPjgdCFaF+yHhN+l7NMor CbtHBE1fsT8BK7+qOvOVHfrRFRKqrrK2aa6qPSGedk1n//1t92AR8nTCU07BxQhXuCcbOaB2fcJK 1XNAcziRYD7qxEJJPcH2CK4nkGGgDZ2eFmhQ0oaBZlrfWrvZqyjrrMS1HAD16mo1gU9xaGeW+Swh g2VCEhGztOyUP8IcAyH83vb83ukXflc9aNbA9hi+PUWSg+EtnGxJJAbsBpHYaHCbfSXrKVlTU/J4 kCoSMWeXB0hzGubs8uaUOa2BbTKnhSTKnOj6X5o5Q0is8IO1uD4G3QpPgDqmHI+QQX8yvAKThmQP ZoVEr67BOy00uDWwUSHR/hpcgRtwcSEJILEJq2YdECkTpqfQegKEBARNuiiu445zoujr5nQz270F V1+CioA4/LwEslicb7BSDITIs8p7gS5sq1c29sD2BHqA2EZ1tERv1WvrCRDESm9M5k28P+ekYhgW dCH2rIxX59vbi8h4pYWMVxs22nsZr8632lt1fkcZD2Elma04fLIlHHqymR7cUBA/8H7hiWTGsX6l xrGWxrHevHGsUxrHbTnEo+AEsBKmNFwJi5kQEO0pGEcpSLAKglpI39UEhUq7rSFOC5DwuBnsNGAA BxA07jBgMtTDloP/Djt2GXfu4s85M44SQSlxkkATtq/UhWilC9Fu3oVoU7oQprC0JU0Ywkoga9w/ iJGsdxkfGK9bP3fdydx1t2FHpT1FEpXObcnemJYLIPFEiA6eN/UguJVGQKBlBEryUMV3CNr5MqF6 eVtbKPo1jY0yQmENbFMobCxxqQBiXVoqgojs4Zybm+VmivAecgLJrqXlpP/OnntMqnpEjvnx5SmW JvfZ/e7/itUa9GVuZHN0cmVhbQplbmRvYmoKMzAgMCBvYmoKMzc1OAplbmRvYmoKMzQgMCBvYmoK PDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFs5My41OTk5OTk5ICA4MDMuMTIw MDAwICAxMTQuNzE5OTk5ICA4MTMuNjc5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0IC9maWxl IzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMy ZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzdGxzCj4+CmVuZG9iagozNSAwIG9iago8PAovVHlwZSAv QW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzkzLjU5OTk5OTkgIDc5MS41OTk5OTkgIDExNC43 MTk5OTkgIDgwMi4xNTk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYj MmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2 Mi5odG1sLmh0bWwjMjNhbmNob3IxMQo+PgplbmRvYmoKMzYgMCBvYmoKPDwKL1R5cGUgL0Fubm90 Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFs5My41OTk5OTk5ICA3ODAuMDc5OTk5ICAxMTQuNzE5OTk5 ICA3OTAuNjM5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFy IzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRt bC5odG1sIzIzYW5jaG9yMTIKPj4KZW5kb2JqCjM3IDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3Vi dHlwZSAvTGluawovUmVjdCBbOTMuNTk5OTk5OSAgNzY4LjU1OTk5OSAgMTE0LjcxOTk5OSAgNzc5 LjExOTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRt cCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRt bCMyM2FuY2hvcjEzCj4+CmVuZG9iagozOCAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUg L0xpbmsKL1JlY3QgWzc4LjIzOTk5OTkgIDc1Ny4wMzk5OTkgIDg4Ljc5OTk5OTkgIDc2Ny41OTk5 OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZD R0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjNh bmNob3IxNAo+PgplbmRvYmoKMzkgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5r Ci9SZWN0IFs5My41OTk5OTk5ICA3NDUuNTE5OTk5ICAxMTQuNzE5OTk5ICA3NTYuMDc5OTk5IF0K L0JvcmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVt cDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzY2xpZW50 IzJkdHlwZXMKPj4KZW5kb2JqCjQwIDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGlu awovUmVjdCBbOTMuNTk5OTk5OSAgNzM0ICAxMTQuNzE5OTk5ICA3NDQuNTU5OTk5IF0KL0JvcmRl ciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2 LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzY2xpZW50IzJkaWRl bnRpZmllcgo+PgplbmRvYmoKNDEgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5r Ci9SZWN0IFs5My41OTk5OTk5ICA3MjIuNDc5OTk5ICAxMTQuNzE5OTk5ICA3MzMuMDM5OTk5IF0K L0JvcmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVt cDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzY2xpZW50 IzJkYXV0aGVudGljYXRpb24KPj4KZW5kb2JqCjQyIDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3Vi dHlwZSAvTGluawovUmVjdCBbMTA4Ljk1OTk5OSAgNzEwLjk1OTk5OSAgMTQwLjYzOTk5OSAgNzIx LjUxOTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRt cCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRt bCMyM2NsaWVudCMyZHBhc3N3b3JkCj4+CmVuZG9iago0MyAwIG9iago8PAovVHlwZSAvQW5ub3QK L1N1YnR5cGUgL0xpbmsKL1JlY3QgWzEwOC45NTk5OTkgIDY5OS40Mzk5OTkgIDE0MC42Mzk5OTkg IDcwOS45OTk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIj MmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1s Lmh0bWwjMjNhbmNob3IxNQo+PgplbmRvYmoKNDQgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0 eXBlIC9MaW5rCi9SZWN0IFs5My41OTk5OTk5ICA2ODcuOTE5OTk5ICAxMTQuNzE5OTk5ICA2OTgu NDc5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1w IzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1s IzIzYW5jaG9yMTYKPj4KZW5kb2JqCjQ1IDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAv TGluawovUmVjdCBbNzguMjM5OTk5OSAgNjc2LjM5OTk5OSAgODguNzk5OTk5OSAgNjg2Ljk1OTk5 OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNH SXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMyM2Fu Y2hvcjE3Cj4+CmVuZG9iago0NiAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsK L1JlY3QgWzkzLjU5OTk5OTkgIDY2NC44Nzk5OTkgIDExNC43MTk5OTkgIDY3NS40Mzk5OTkgXQov Qm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1w NTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjNhbmNob3Ix OAo+PgplbmRvYmoKNDcgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0 IFsxMDguOTU5OTk5ICA2NTMuMzU5OTk5ICAxNDAuNjM5OTk5ICA2NjMuOTE5OTk5IF0KL0JvcmRl ciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2 LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzcmVzcG9uc2UjMmR0 eXBlCj4+CmVuZG9iago0OCAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1Jl Y3QgWzEwOC45NTk5OTkgIDY0MS44Mzk5OTkgIDE0MC42Mzk5OTkgIDY1Mi4zOTk5OTkgXQovQm9y ZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAz NzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjNyZWRpcmVjdCMy ZHVyaQo+PgplbmRvYmoKNDkgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9S ZWN0IFs5My41OTk5OTk5ICA2MzAuMzE5OTk5ICAxMTQuNzE5OTk5ICA2NDAuODc5OTk5IF0KL0Jv cmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUw Mzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzYW5jaG9yMjQK Pj4KZW5kb2JqCjUwIDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBb MTA4Ljk1OTk5OSAgNjE4Ljc5OTk5OSAgMTQwLjYzOTk5OSAgNjI5LjM1OTk5OSBdCi9Cb3JkZXIg WzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5k aXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMyM3Rva2VuIzJkZW5kcG9p bnQjMmRhdXRoCj4+CmVuZG9iago1MSAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xp bmsKL1JlY3QgWzkzLjU5OTk5OTkgIDYwNy4yNzk5OTkgIDExNC43MTk5OTkgIDYxNy44Mzk5OTkg XQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0 ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjNzY29w ZQo+PgplbmRvYmoKNTIgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0 IFs3OC4yMzk5OTk5ICA1OTUuNzU5OTk5ICA4OC43OTk5OTk5ICA2MDYuMzE5OTk5IF0KL0JvcmRl ciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2 LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzYW5jaG9yMjUKPj4K ZW5kb2JqCjUzIDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbOTMu NTk5OTk5OSAgNTg0LjI0MDAwMCAgMTE0LjcxOTk5OSAgNTk0Ljc5OTk5OSBdCi9Cb3JkZXIgWzAg MCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIj MmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMyM2dyYW50IzJkY29kZQo+Pgpl bmRvYmoKNTQgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFsxMDgu OTU5OTk5ICA1NzIuNzE5OTk5ICAxNDAuNjM5OTk5ICA1ODMuMjc5OTk5IF0KL0JvcmRlciBbMCAw IDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMy ZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzY29kZSMyZGF1dGh6IzJkcmVx Cj4+CmVuZG9iago1NSAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3Qg WzEwOC45NTk5OTkgIDU2MS4xOTk5OTkgIDE0MC42Mzk5OTkgIDU3MS43NTk5OTkgXQovQm9yZGVy IFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYu ZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjNjb2RlIzJkYXV0aHoj MmRyZXNwCj4+CmVuZG9iago1NiAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsK L1JlY3QgWzEwOC45NTk5OTkgIDU0OS42Nzk5OTkgIDE0MC42Mzk5OTkgIDU2MC4yMzk5OTkgXQov Qm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1w NTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjN0b2tlbiMy ZHJlcQo+PgplbmRvYmoKNTcgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9S ZWN0IFsxMDguOTU5OTk5ICA1MzguMTU5OTk5ICAxNDAuNjM5OTk5ICA1NDguNzE5OTk5IF0KL0Jv cmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUw Mzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzYW5jaG9yMjYK Pj4KZW5kb2JqCjU4IDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBb OTMuNTk5OTk5OSAgNTI2LjYzOTk5OSAgMTE0LjcxOTk5OSAgNTM3LjE5OTk5OSBdCi9Cb3JkZXIg WzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5k aXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMyM2dyYW50IzJkaW1wbGlj aXQKPj4KZW5kb2JqCjU5IDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVj dCBbMTA4Ljk1OTk5OSAgNTE1LjEyMDAwMCAgMTQwLjYzOTk5OSAgNTI1LjY3OTk5OSBdCi9Cb3Jk ZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3 Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMyM2ltcGxpY2l0IzJk YXV0aHojMmRyZXEKPj4KZW5kb2JqCjYwIDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAv TGluawovUmVjdCBbMTA4Ljk1OTk5OSAgNTAzLjU5OTk5OSAgMTQwLjYzOTk5OSAgNTE0LjE1OTk5 OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNH SXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMyM2lt cGxpY2l0IzJkYXV0aHojMmRyZXNwCj4+CmVuZG9iago2MSAwIG9iago8PAovVHlwZSAvQW5ub3QK L1N1YnR5cGUgL0xpbmsKL1JlY3QgWzkzLjU5OTk5OTkgIDQ5Mi4wNzk5OTkgIDExNC43MTk5OTkg IDUwMi42Mzk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIj MmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1s Lmh0bWwjMjNncmFudCMyZHBhc3N3b3JkCj4+CmVuZG9iago2MiAwIG9iago8PAovVHlwZSAvQW5u b3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzEwOC45NTk5OTkgIDQ4MC41NTk5OTkgIDE0MC42Mzk5 OTkgIDQ5MS4xMTk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2 YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5o dG1sLmh0bWwjMjNhbmNob3IyNwo+PgplbmRvYmoKNjMgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9T dWJ0eXBlIC9MaW5rCi9SZWN0IFsxMDguOTU5OTk5ICA0NjkuMDM5OTk5ICAxNDAuNjM5OTk5ICA0 NzkuNTk5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJm dG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5o dG1sIzIzcGFzc3dvcmQjMmR0b2sjMmRyZXEKPj4KZW5kb2JqCjY0IDAgb2JqCjw8Ci9UeXBlIC9B bm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbMTA4Ljk1OTk5OSAgNDU3LjUxOTk5OSAgMTQwLjYz OTk5OSAgNDY4LjA3OTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMy ZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYy Lmh0bWwuaHRtbCMyM2FuY2hvcjI4Cj4+CmVuZG9iago2NSAwIG9iago8PAovVHlwZSAvQW5ub3QK L1N1YnR5cGUgL0xpbmsKL1JlY3QgWzkzLjU5OTk5OTkgIDQ0NS45OTk5OTkgIDExNC43MTk5OTkg IDQ1Ni41NTk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIj MmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1s Lmh0bWwjMjNncmFudCMyZGNsaWVudAo+PgplbmRvYmoKNjYgMCBvYmoKPDwKL1R5cGUgL0Fubm90 Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFsxMDguOTU5OTk5ICA0MzQuNDc5OTk5ICAxNDAuNjM5OTk5 ICA0NDUuMDM5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFy IzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRt bC5odG1sIzIzYW5jaG9yMjkKPj4KZW5kb2JqCjY3IDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3Vi dHlwZSAvTGluawovUmVjdCBbMTA4Ljk1OTk5OSAgNDIyLjk1OTk5OSAgMTQwLjYzOTk5OSAgNDMz LjUxOTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRt cCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRt bCMyM2NsaWVudCMyZHJlcQo+PgplbmRvYmoKNjggMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0 eXBlIC9MaW5rCi9SZWN0IFsxMDguOTU5OTk5ICA0MTEuNDM5OTk5ICAxNDAuNjM5OTk5ICA0MjEu OTk5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1w IzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1s IzIzYW5jaG9yMzAKPj4KZW5kb2JqCjY5IDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAv TGluawovUmVjdCBbOTMuNTk5OTk5OSAgMzk5LjkxOTk5OSAgMTE0LjcxOTk5OSAgNDEwLjQ3OTk5 OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNH SXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMyM2V4 dCMyZGdyYW50Cj4+CmVuZG9iago3MCAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xp bmsKL1JlY3QgWzc4LjIzOTk5OTkgIDM4OC4zOTk5OTkgIDg4Ljc5OTk5OTkgIDM5OC45NTk5OTkg XQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0 ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjN0b2tl biMyZGlzc3VlCj4+CmVuZG9iago3MSAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xp bmsKL1JlY3QgWzkzLjU5OTk5OTkgIDM3Ni44Nzk5OTkgIDExNC43MTk5OTkgIDM4Ny40Mzk5OTkg XQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0 ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjN0b2tl biMyZHJlc3BvbnNlCj4+CmVuZG9iago3MiAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUg L0xpbmsKL1JlY3QgWzkzLjU5OTk5OTkgIDM2NS4zNTk5OTkgIDExNC43MTk5OTkgIDM3NS45MTk5 OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZD R0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjN0 b2tlbiMyZGVycm9ycwo+PgplbmRvYmoKNzMgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBl IC9MaW5rCi9SZWN0IFs3OC4yMzk5OTk5ICAzNTMuODM5OTk5ICA4OC43OTk5OTk5ICAzNjQuMzk5 OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJm Q0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIz dG9rZW4jMmRyZWZyZXNoCj4+CmVuZG9iago3NCAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5 cGUgL0xpbmsKL1JlY3QgWzc4LjIzOTk5OTkgIDM0Mi4zMTk5OTkgIDg4Ljc5OTk5OTkgIDM1Mi44 Nzk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAj MmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwj MjNhY2Nlc3MjMmRyZXNvdXJjZQo+PgplbmRvYmoKNzUgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9T dWJ0eXBlIC9MaW5rCi9SZWN0IFs5My41OTk5OTk5ICAzMzAuNzk5OTk5ICAxMTQuNzE5OTk5ICAz NDEuMzU5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJm dG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5o dG1sIzIzdG9rZW4jMmR0eXBlcwo+PgplbmRvYmoKNzYgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9T dWJ0eXBlIC9MaW5rCi9SZWN0IFs5My41OTk5OTk5ICAzMTkuMjc5OTk5ICAxMTQuNzE5OTk5ICAz MjkuODM5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJm dG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5o dG1sIzIzcmVzb3VyY2UjMmRlcnJvcnMKPj4KZW5kb2JqCjc3IDAgb2JqCjw8Ci9UeXBlIC9Bbm5v dAovU3VidHlwZSAvTGluawovUmVjdCBbNzguMjM5OTk5OSAgMzA3Ljc1OTk5OSAgODguNzk5OTk5 OSAgMzE4LjMxOTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZh ciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0 bWwuaHRtbCMyM2V4dGVuc2lvbnMKPj4KZW5kb2JqCjc4IDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAov U3VidHlwZSAvTGluawovUmVjdCBbOTMuNTk5OTk5OSAgMjk2LjIzOTk5OSAgMTE0LjcxOTk5OSAg MzA2Ljc5OTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMy ZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwu aHRtbCMyM25ldyMyZHR5cGVzCj4+CmVuZG9iago3OSAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1 YnR5cGUgL0xpbmsKL1JlY3QgWzkzLjU5OTk5OTkgIDI4NC43MTk5OTkgIDExNC43MTk5OTkgIDI5 NS4yNzk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0 bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0 bWwjMjNlbmRwb2ludCMyZHBhcmFtcwo+PgplbmRvYmoKODAgMCBvYmoKPDwKL1R5cGUgL0Fubm90 Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFs5My41OTk5OTk5ICAyNzMuMTk5OTk5ICAxMTQuNzE5OTk5 ICAyODMuNzU5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFy IzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRt bC5odG1sIzIzYW5jaG9yMzEKPj4KZW5kb2JqCjgxIDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3Vi dHlwZSAvTGluawovUmVjdCBbOTMuNTk5OTk5OSAgMjYxLjY3OTk5OSAgMTE0LjcxOTk5OSAgMjcy LjIzOTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRt cCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRt bCMyM3Jlc3BvbnNlIzJkdHlwZSMyZGV4dAo+PgplbmRvYmoKODIgMCBvYmoKPDwKL1R5cGUgL0Fu bm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFs5My41OTk5OTk5ICAyNTAuMTU5OTk5ICAxMTQuNzE5 OTk5ICAyNjAuNzE5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJm dmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIu aHRtbC5odG1sIzIzbmV3IzJkZXJyb3JzCj4+CmVuZG9iago4MyAwIG9iago8PAovVHlwZSAvQW5u b3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzc4LjIzOTk5OTkgIDIzOC42Mzk5OTkgIDg4Ljc5OTk5 OTkgIDI0OS4xOTk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2 YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5o dG1sLmh0bWwjMjNhbmNob3IzMgo+PgplbmRvYmoKODQgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9T dWJ0eXBlIC9MaW5rCi9SZWN0IFs3OC4yMzk5OTk5ICAyMjcuMTE5OTk5ICA5NS41MTk5OTk5ICAy MzcuNjc5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJm dG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5o dG1sIzIzYW5jaG9yMzMKPj4KZW5kb2JqCjg1IDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlw ZSAvTGluawovUmVjdCBbOTMuNTk5OTk5OSAgMjE1LjU5OTk5OSAgMTIxLjQzOTk5OSAgMjI2LjE1 OTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMy ZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMy M2FuY2hvcjM0Cj4+CmVuZG9iago4NiAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xp bmsKL1JlY3QgWzkzLjU5OTk5OTkgIDIwNC4wNzk5OTkgIDEyMS40Mzk5OTkgIDIxNC42Mzk5OTkg XQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0 ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjNhbmNo b3IzNQo+PgplbmRvYmoKODcgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9S ZWN0IFs5My41OTk5OTk5ICAxOTIuNTU5OTk5ICAxMjEuNDM5OTk5ICAyMDMuMTE5OTk5IF0KL0Jv cmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUw Mzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzYW5jaG9yMzYK Pj4KZW5kb2JqCjg4IDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBb OTMuNTk5OTk5OSAgMTgxLjAzOTk5OSAgMTIxLjQzOTk5OSAgMTkxLjU5OTk5OSBdCi9Cb3JkZXIg WzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5k aXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMyM2FuY2hvcjM3Cj4+CmVu ZG9iago4OSAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzkzLjU5 OTk5OTkgIDE2OS41MTk5OTkgIDEyMS40Mzk5OTkgIDE4MC4wNzk5OTkgXQovQm9yZGVyIFswIDAg MF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJm ZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjNhbmNob3IzOAo+PgplbmRvYmoK OTAgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFs5My41OTk5OTk5 ICAxNTcuOTk5OTk5ICAxMjEuNDM5OTk5ICAxNjguNTU5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9E ZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0 IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzYW5jaG9yMzkKPj4KZW5kb2JqCjkxIDAg b2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbOTMuNTk5OTk5OSAgMTQ2 LjQ3OTk5OSAgMTIxLjQzOTk5OSAgMTU3LjAzOTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdCAv ZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGll dGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMyM2FuY2hvcjQwCj4+CmVuZG9iago5MiAwIG9iago8 PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzkzLjU5OTk5OTkgIDEzNC45NTk5 OTkgIDEyMS40Mzk5OTkgIDE0NS41MTk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUj M2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJk b2F1dGgjMmR2Mi5odG1sLmh0bWwjMjNhbmNob3I0MQo+PgplbmRvYmoKOTMgMCBvYmoKPDwKL1R5 cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFs5My41OTk5OTk5ICAxMjMuNDM5OTk5ICAx MjEuNDM5OTk5ICAxMzMuOTk5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJm IzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRo IzJkdjIuaHRtbC5odG1sIzIzYW5jaG9yNDIKPj4KZW5kb2JqCjk0IDAgb2JqCjw8Ci9UeXBlIC9B bm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbOTMuNTk5OTk5OSAgMTExLjkxOTk5OSAgMTI4LjE1 OTk5OSAgMTIyLjQ3OTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMy ZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYy Lmh0bWwuaHRtbCMyM2FudGhyb3B5Cj4+CmVuZG9iago5NSAwIG9iago8PAovVHlwZSAvQW5ub3QK L1N1YnR5cGUgL0xpbmsKL1JlY3QgWzkzLjU5OTk5OTkgIDEwMC4zOTk5OTkgIDEyOC4xNTk5OTkg IDExMC45NTk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIj MmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1s Lmh0bWwjMjNhbmNob3I0Mwo+PgplbmRvYmoKOTYgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0 eXBlIC9MaW5rCi9SZWN0IFs5My41OTk5OTk5ICA4OC44Nzk5OTk5ICAxMjguMTU5OTk5ICA5OS40 Mzk5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1w IzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1s IzIzQ1NSRgo+PgplbmRvYmoKOTcgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5r Ci9SZWN0IFs5My41OTk5OTk5ICA3Ny4zNTk5OTk5ICAxMjguMTU5OTk5ICA4Ny45MTk5OTk5IF0K L0JvcmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVt cDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzYW5jaG9y NDQKPj4KZW5kb2JqCjk4IDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVj dCBbOTMuNTk5OTk5OSAgNjUuODM5OTk5OSAgMTI4LjE1OTk5OSAgNzYuMzk5OTk5OSBdCi9Cb3Jk ZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3 Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMyM2FuY2hvcjQ1Cj4+ CmVuZG9iago5OSAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzkz LjU5OTk5OTkgIDU0LjMxOTk5OTkgIDEyOC4xNTk5OTkgIDY0Ljg3OTk5OTkgXQovQm9yZGVyIFsw IDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGly IzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjNvcGVuIzJkcmVkaXJlY3QK Pj4KZW5kb2JqCjEwMCAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3Qg Wzc4LjIzOTk5OTkgIDQyLjc5OTk5OTkgIDk1LjUxOTk5OTkgIDUzLjM1OTk5OTkgXQovQm9yZGVy IFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYu ZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjNhbmNob3I0Ngo+Pgpl bmRvYmoKMTAxIDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbOTMu NTk5OTk5OSAgMzEuMjc5OTk5OSAgMTIxLjQzOTk5OSAgNDEuODM5OTk5OSBdCi9Cb3JkZXIgWzAg MCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIj MmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMyM3R5cGUjMmRyZWdpc3RyeQo+ PgplbmRvYmoKMzMgMCBvYmoKPDwKL1R5cGUgL1BhZ2UKL1BhcmVudCAyIDAgUgovQ29udGVudHMg MTAyIDAgUgovUmVzb3VyY2VzIDEwNCAwIFIKL0Fubm90cyAxMDUgMCBSCi9NZWRpYUJveCBbMCAw IDU5NSA4NDJdCj4+CmVuZG9iagoxMDQgMCBvYmoKPDwKL0NvbG9yU3BhY2UgPDwKL1BDU3AgNCAw IFIKL0NTcCAvRGV2aWNlUkdCCi9DU3BnIC9EZXZpY2VHcmF5Cj4+Ci9FeHRHU3RhdGUgPDwKL0dT YSAzIDAgUgo+PgovUGF0dGVybiA8PAo+PgovRm9udCA8PAovRjYgNiAwIFIKPj4KL1hPYmplY3Qg PDwKPj4KPj4KZW5kb2JqCjEwNSAwIG9iagpbIDM0IDAgUiAzNSAwIFIgMzYgMCBSIDM3IDAgUiAz OCAwIFIgMzkgMCBSIDQwIDAgUiA0MSAwIFIgNDIgMCBSIDQzIDAgUiA0NCAwIFIgNDUgMCBSIDQ2 IDAgUiA0NyAwIFIgNDggMCBSIDQ5IDAgUiA1MCAwIFIgNTEgMCBSIDUyIDAgUiA1MyAwIFIgNTQg MCBSIDU1IDAgUiA1NiAwIFIgNTcgMCBSIDU4IDAgUiA1OSAwIFIgNjAgMCBSIDYxIDAgUiA2MiAw IFIgNjMgMCBSIDY0IDAgUiA2NSAwIFIgNjYgMCBSIDY3IDAgUiA2OCAwIFIgNjkgMCBSIDcwIDAg UiA3MSAwIFIgNzIgMCBSIDczIDAgUiA3NCAwIFIgNzUgMCBSIDc2IDAgUiA3NyAwIFIgNzggMCBS IDc5IDAgUiA4MCAwIFIgODEgMCBSIDgyIDAgUiA4MyAwIFIgODQgMCBSIDg1IDAgUiA4NiAwIFIg ODcgMCBSIDg4IDAgUiA4OSAwIFIgOTAgMCBSIDkxIDAgUiA5MiAwIFIgOTMgMCBSIDk0IDAgUiA5 NSAwIFIgOTYgMCBSIDk3IDAgUiA5OCAwIFIgOTkgMCBSIDEwMCAwIFIgMTAxIDAgUiBdCmVuZG9i agoxMDIgMCBvYmoKPDwKL0xlbmd0aCAxMDMgMCBSCi9GaWx0ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0 cmVhbQp4nO1dTY/cuBG996/ocwCPRUqUKCBYYD3rCZBDAMMD5BDkEHixCRbrRYw95O9HLcpDqaq7 qWJXN19/eGCPm9PTkor16pN8fP+Xz//a/vuP7fvnz//dfpm+P3/eVE+V68OfbTV8vZsPWP9U22r3 Z+tN/dR24+iXr5tv22+bT5tPw7/fNqYdf3H6Nvzw+yWq8euPL79v3oeLb8LI5+e/Df/739Zu/zr8 /XX7j38Ogz9Pn7d7w9eN79vhPqrK1MPL3+YvTV25dvz/MF7Rl7s3/2fz9z9tf9/dmH3y482bcIPz l++M7bv+ye5e5d/ytyO/+OF18/6lHW5w+/rLNtzBu/Dt9eumdcOLyrbb15+3f97d0g/b1183bvdD 2cDH10Fu1dP3Gevf7tbwu/VuO1yze3LjhH7dmJ0448Bvm8/xccgnLiSy52rHZXPkw45KyRMpufGR +yiDlgjFNvvfMUrp0nO8E69wku044OPzODrQ0gekn2G7ccBUbyPG0t/5cRxo4ztqcpnqZRxo4sAH +hk+CvZEFDTm8ihoLEHB2wAqCqKU0ijweCgQTLLtgwabw7hgA8ZRrWcfa6o0MJ7ZpzAgMOywD/lI b7Ynv7IaXXFgQqgG3FwBp+Oo03HoTscJnM6PeHCTTHJHtZGZD6rAaY/CNNq8ZLilZ/IO+yGJT2Po 0zCw0aexz2rY6gq4so66sg7dlXUCV/YTHrYEk2w/MlfGTD0DF9V6Ff9BP5TjhD1Mw8CWvIx9oX6Z gTxpXE70jiuh0+6g46Nb6vr5azzkBPviv5t1g5ToDLKb39sKU8dUK222czQpIwSs2Vv4nbBsiV04 6cnytV7BTZnq8m5qyIOXbioO4IHNL6V0CGwzoRxwZAXdlGiSC+GR1zueqf9Ih416qZExl0+NjCGp URxAxYVJOaGZwUVyUxMuJJNcChcsJWOFCY3AytapdxzK0TTAVhdwQjV1QjW6E6rXOyGDV/YTTXKp oLBnER9LOlmORks+KnkOLRyCRY3N6d5RY0ACelPtUN/MXGzTzQfwUL+747ms82GPGp0OMyBUplKG gfUUeBWFpoJ8YGrH2SMQZcVTtYKkaU93smUw21qC2RbXU0+YbU931aiRc8CsRJkCDuaFzwwfyoBx l777SLO/DgPjKplDD5N8fn5dnm3o5dhdgRy7ozl2hxsA+KWU0rbEVkiWIoT9gkmuLYMwU/tkz12l aruiIbliwUCh6CWzBWJ6u2iBxNd4yAj2o3/zskjp7tgCifeWVvs9C1aSPXTuQtg72NoT1odP9v3q Oql83D+wMi2/NebuRDp9mtex1eW9jq2I14kDeNjySyldW045eh3JJKsEjisyOWbZP5SJEwtjWgPC 9kpTWWtJKhsH8OxASGWjrPMNAaqpGFNZiTKtWDTAqz4rsHNgEcuxtTOK/VMNRNZXWhC2NSkIxwFY RNanu2bo4pJEma56JfdN+mZ3+V6udaSXGwfwQOyXUrq28m8IryWTzDZsUPW0hrq/dM3jFpHTXqsP bakPbeF9aLveh17bkr/gQyXK9FhtQUNlqNUW1hdwqZ66VI/uUr3ApSLViyeXKpjkPcBh4SlT6XSi yroiZVw539ecrmQfTW0FPRDbL7eBxNd4Wh9sQ//dzkP1/sYeSLy3nEUCezb4pbdHpcO15Dv29A/v oWKs4Kdqc3k/VRvip+IAHmL9UkqHEIsaWI5+SjLJt4iTYyXYFbskVyzeZ1L8iZrGFXvKzpem1gpM NUXS1NqSNLUGprsJaWqUdb6tQLUmY5oqUaY7syZrNqhyg0Mlkg77FS2DAntPGcvQkLZsDUwBNFmG 5vQoArXEHCyDQJkeluGiXWgNU6HAPFTGVDgaRADTF02mwmkGEVils2AqBMp026WzK4wZFGiSyhiC jsYMwFxLkyHoNGMGqHrjZAgEynT3hgA+RJCQCGlVEz1Zp10D00D5pZTSmMaK8kM1UTLJlAnDTIxq sxHeB0p2sjnskyyB6CW6RoHUqYhTbSriVBtgZqjgVKOs8wEIXaKTKNMjEQcPtxsFWqsylsGQvLsB 5saaLIM53TWjOu9gGQTK9Ai3wcPtpgAHV0M5uBp0Dq4opRWYhqqUjeG2ZJJzdJprMHP/zJcnUb9i rdAeZh0GnQxGkcKkP8eWIO1Za5DBUKCxeDZNJ5220mj507XSmzWU3qyBpzeLss63qNj5k0CZHvnT OfOnY6Y+bV3SNvkWosBrJYlrKElcA08SF2WtYfkQ80OBMt19fohWKFLgZitjCDoaAgETvE2GoNMM gbDSzmAIBMp094YAPkQQMJupFYp6WigC5qbzSymlMY21kiIUiiSTXOpkhEcJ5HwlEKfAklfE/7uK +H8HTLUX/H+Udb6tgC6BSJTpUQJ5lECKxjfuWskFHSUXdPDkglHWGpYPsAQiUaa7z3zASiDuWjkN HeU0dPCchlHWKoYArwQiUaa7NwTwIUIBjkNHOQ4dOsdhlNIKTDM9Kl4CkUwyYx+sXSr+TiOHA1Yj 31AsM5x84oRrl2xLDpg3MAD/jVUPSmFHtiUnYfxjWynS3oJl4SpMSmldu0HvqOGCCnACOsoJ6NA5 AaOUDuEVtW4WXJBgkjlrHgPsOWDCzw1mKRtrBtxiRCihutOCY082KzpgskK/lFIajljFnABHwSRz PmpWgU6f8ZReoYyAHEHA15rlEWMtMFnfiOs2kvUh6eMY8LUSJr60onBLnuymcrVgjZhHkHhSkCjB ll0mUy0wu13AViS3Q6rXBWydxkt3Fl1TgZLGUYMZh6PknJYJswFJ7+zBVoEhTxomtg3J2lpgcju/ lNIhwwCdtUkm+Qb81BEvfMKZZGdBnwLpnBh9jiRpLTBfnF9KKY0+wCRNMsmPJG1vINmRJA2Y2Czg OvKasfyjeCApoCQr1EXac9ACWxyXXNDL7mwy9RpmuwARWEuJwFp0IrAopUMgwA6aBJNch7ud7/9P FzOKnQzyiOfOFc91CjRnUsPQVSSb6oAZyvxSSmnDABjPSSYZ2DDYj8lb28MUkg5YL3vK5WlkKemV JnsYHZmVSodA7DJ6FkeBPk1scQwJRTpg5jO/lNIKi4NU+p0sjmCSb97i3Nt2nLMsj4MPpApwv3WU +61D536LUkqbNcAtvZJJfpi12zJryHFj4eroFaW7Cqx0Yivd0OATmFDOL6W0wkojLeKerLRgkoGt 9B77yhv+fCTNvC83hmlyhkJ9IZ3jQjO3XnTtssnTAdOlBesX2dKYpy7d5OkERGd74hd5CGBfxM6M I3KP89I4PuMsEU2uls/IwLyfv0bV8siURXs0dQek9oMwFzcr356wYhFZeunW2i7ksc7JCiucsTNv Bc9QurCgDJwTw88CvF/dnPfL2vkAHoA9kdJaAKP2ZQd5C2e9EBGYSjKvwQN2Tl+ogGCvwOklRbCf 03HtEOyB6bg8kZIcwVgN1BHBolkvReWXdbTb2sbfseXhyWyxLGIVuKjEiLXE53pgGilPpJSBWKgG ZEDsvZJG6QWrXoG7SQycmro6YNolT6QkBw5WiysAR0KyVGpH5LUhqQDXkXfUBaFzHc2klIEkqDZE QJJg1u+sl6pftj8RoBLeHy2AttTVATM3eSKlDIACZnWCWX8ANAOgOQHDmo5mmqI+uZlaZUWIZU/D u7o0K+efEgYGRT08xcn+8p7VHEkOIbA0vQAZl/c0RkIn45pJKcMEA6bpglmH4TLgt/o4TPUaTxLR sFoFOMt8TwNHdM6ymZQyrBbSfuTJaglmHedwipwu/Yq1b4UwfMnd072AJUwL5b0hsUkPzPPmiZQy UI60IC2gXDLrOIvDV5ySBdvqvyimBexkapie0cuZ2swHUDFtT/Dc2MvvdhMgVIPrC3Flh+XJo44z MexxC8VEwiwUq2ZQ68JbQGppQF+Ak66fc9KNxgSdk24mJY11fVAL/YIxkbDW8Vw+Sfx6Ka7Yq4Nf AVK63lFfjk5KN5OSAvywVukF+EnUIO3LWTSe9n61p2kNO1EgGeKqdFEudd4le7xkKZHbn3QhVDHq F1DJqVmKjjpqYDJAT6SkYSmg2g7BUkjUIGM9b9r51X0qpE9/xmpnrwGcAgSCvacuFp1AcCYlBeBg rQ4MwJGowXnWEPCOOtN6hq0y6wNUToNOP+6K3n/ak9uOzURGCZ5PJ9IaA1tdnuxwuObS+88GMI3Y XEoaRgxqYebOiMnUgLf2V2yi0TjA9VILoZIRe96+cVuZxb7x2Ws8vQ/WwRx03lC1pt2+8fnNpnWY 7QxjBZ49jAq8CKTRUL7Hbd+2ujw33HDNZf94NoCHP0+ktBZ/yNu+ZbNON7CsaLiucFUqi5Zvertc +io5hGVZJTtemE/W/7mZO1Y6G7623watNu2oqNO3L19z8fFp+2nzf0OdmotlbmRzdHJlYW0KZW5k b2JqCjEwMyAwIG9iagozMjg4CmVuZG9iagoxMDcgMCBvYmoKWzIgL1hZWiA0Ny41MTk5OTk5ICAK MzcxLjExOTk5OSAgMF0KZW5kb2JqCjEwOCAwIG9iagpbMiAvWFlaIDQ3LjUxOTk5OTkgIAo0MTIu Mzk5OTk5ICAwXQplbmRvYmoKMTA5IDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGlu awovUmVjdCBbMTA4Ljk1OTk5OSAgODAzLjEyMDAwMCAgMTQ3LjM1OTk5OSAgODEzLjY3OTk5OSBd Ci9Cb3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRl bXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMyM2FuY2hv cjQ3Cj4+CmVuZG9iagoxMTAgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9S ZWN0IFs5My41OTk5OTk5ICA3OTEuNTk5OTk5ICAxMjEuNDM5OTk5ICA4MDIuMTU5OTk5IF0KL0Jv cmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUw Mzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzcGFyYW1ldGVy cyMyZHJlZ2lzdHJ5Cj4+CmVuZG9iagoxMTEgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBl IC9MaW5rCi9SZWN0IFsxMDguOTU5OTk5ICA3ODAuMDc5OTk5ICAxNDcuMzU5OTk5ICA3OTAuNjM5 OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJm Q0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIz YW5jaG9yNDgKPj4KZW5kb2JqCjExMiAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xp bmsKL1JlY3QgWzEwOC45NTk5OTkgIDc2OC41NTk5OTkgIDE0Ny4zNTk5OTkgIDc3OS4xMTk5OTkg XQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0 ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjNhbmNo b3I0OQo+PgplbmRvYmoKMTEzIDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawov UmVjdCBbOTMuNTk5OTk5OSAgNzU3LjAzOTk5OSAgMTIxLjQzOTk5OSAgNzY3LjU5OTk5OSBdCi9C b3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1 MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMyM3Jlc3BvbnNl IzJkdHlwZSMyZHJlZ2lzdHJ5Cj4+CmVuZG9iagoxMTQgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9T dWJ0eXBlIC9MaW5rCi9SZWN0IFsxMDguOTU5OTk5ICA3NDUuNTE5OTk5ICAxNDcuMzU5OTk5ICA3 NTYuMDc5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJm dG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5o dG1sIzIzYW5jaG9yNTAKPj4KZW5kb2JqCjExNSAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5 cGUgL0xpbmsKL1JlY3QgWzEwOC45NTk5OTkgIDczNCAgMTQ3LjM1OTk5OSAgNzQ0LjU1OTk5OSBd Ci9Cb3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRl bXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMyM2FuY2hv cjUxCj4+CmVuZG9iagoxMTYgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9S ZWN0IFs5My41OTk5OTk5ICA3MjIuNDc5OTk5ICAxMjEuNDM5OTk5ICA3MzMuMDM5OTk5IF0KL0Jv cmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUw Mzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzZXJyb3IjMmRy ZWdpc3RyeQo+PgplbmRvYmoKMTE3IDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGlu awovUmVjdCBbMTA4Ljk1OTk5OSAgNzEwLjk1OTk5OSAgMTQ3LjM1OTk5OSAgNzIxLjUxOTk5OSBd Ci9Cb3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRl bXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMyM2FuY2hv cjUyCj4+CmVuZG9iagoxMTggMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9S ZWN0IFs3OC4yMzk5OTk5ICA2OTkuNDM5OTk5ICA5NS41MTk5OTk5ICA3MDkuOTk5OTk5IF0KL0Jv cmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUw Mzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzcmZjLnJlZmVy ZW5jZXMxCj4+CmVuZG9iagoxMTkgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5r Ci9SZWN0IFs5My41OTk5OTk5ICA2ODcuOTE5OTk5ICAxMjEuNDM5OTk5ICA2OTguNDc5OTk5IF0K L0JvcmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVt cDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzcmZjLnJl ZmVyZW5jZXMxCj4+CmVuZG9iagoxMjAgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9M aW5rCi9SZWN0IFs5My41OTk5OTk5ICA2NzYuMzk5OTk5ICAxMjEuNDM5OTk5ICA2ODYuOTU5OTk5 IF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJ dGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzcmZj LnJlZmVyZW5jZXMyCj4+CmVuZG9iagoxMjEgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBl IC9MaW5rCi9SZWN0IFs3OC4yMzk5OTk5ICA2NjQuODc5OTk5ICAxNDcuMzYwMDAwICA2NzUuNDM5 OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJm Q0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIz YW5jaG9yNTUKPj4KZW5kb2JqCjEyMiAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xp bmsKL1JlY3QgWzkzLjU5OTk5OTkgIDY1My4zNTk5OTkgIDExNS42Nzk5OTkgIDY2My45MTk5OTkg XQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0 ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjNhbmNo b3I1Ngo+PgplbmRvYmoKMTIzIDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawov UmVjdCBbOTMuNTk5OTk5OSAgNjQxLjgzOTk5OSAgMTE1LjY3OTk5OSAgNjUyLjM5OTk5OSBdCi9C b3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1 MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMyM2FuY2hvcjU3 Cj4+CmVuZG9iagoxMjQgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0 IFs5My41OTk5OTk5ICA2MzAuMzE5OTk5ICAxMTUuNjc5OTk5ICA2NDAuODc5OTk5IF0KL0JvcmRl ciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2 LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzYW5jaG9yNTgKPj4K ZW5kb2JqCjEyNSAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzkz LjU5OTk5OTkgIDYxOC43OTk5OTkgIDExNS42Nzk5OTkgIDYyOS4zNTk5OTkgXQovQm9yZGVyIFsw IDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGly IzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjNhbmNob3I1OQo+PgplbmRv YmoKMTI2IDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbOTMuNTk5 OTk5OSAgNjA3LjI3OTk5OSAgMTE1LjY3OTk5OSAgNjE3LjgzOTk5OSBdCi9Cb3JkZXIgWzAgMCAw XQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZk cmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMyM2FuY2hvcjYwCj4+CmVuZG9iagox MjcgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFs5My41OTk5OTk5 ICA1OTUuNzU5OTk5ICAxMTUuNjc5OTk5ICA2MDYuMzE5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9E ZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0 IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzYW5jaG9yNjEKPj4KZW5kb2JqCjEyOCAw IG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzkzLjU5OTk5OTkgIDU4 NC4yNDAwMDAgIDExNS42Nzk5OTkgIDU5NC43OTk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3Qg L2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRp ZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjNhbmNob3I2Mgo+PgplbmRvYmoKMTI5IDAgb2Jq Cjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbOTMuNTk5OTk5OSAgNTcyLjcx OTk5OSAgMTE1LjY3OTk5OSAgNTgzLjI3OTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdCAvZmls ZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYj MmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMyM2FuY2hvcjYzCj4+CmVuZG9iagoxMzAgMCBvYmoKPDwK L1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFs5My41OTk5OTk5ICA1NjEuMTk5OTk5 ICAxMTUuNjc5OTk5ICA1NzEuNzU5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNh IzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9h dXRoIzJkdjIuaHRtbC5odG1sIzIzYW5jaG9yNjQKPj4KZW5kb2JqCjEzMSAwIG9iago8PAovVHlw ZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzkzLjU5OTk5OTkgIDU0OS42Nzk5OTkgIDEy Mi4zOTk5OTkgIDU2MC4yMzk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYj MmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgj MmR2Mi5odG1sLmh0bWwjMjNhbmNob3I2NQo+PgplbmRvYmoKMTMyIDAgb2JqCjw8Ci9UeXBlIC9B bm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbOTMuNTk5OTk5OSAgNTM4LjE1OTk5OSAgMTIyLjM5 OTk5OSAgNTQ4LjcxOTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMy ZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYy Lmh0bWwuaHRtbCMyM2FuY2hvcjY2Cj4+CmVuZG9iagoxMzMgMCBvYmoKPDwKL1R5cGUgL0Fubm90 Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFs5My41OTk5OTk5ICA1MjYuNjM5OTk5ICAxMjIuMzk5OTk5 ICA1MzcuMTk5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFy IzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRt bC5odG1sIzIzYW5jaG9yNjcKPj4KZW5kb2JqCjEzNCAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1 YnR5cGUgL0xpbmsKL1JlY3QgWzkzLjU5OTk5OTkgIDUxNS4xMjAwMDAgIDEyMi4zOTk5OTkgIDUy NS42Nzk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0 bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0 bWwjMjNhbmNob3I2OAo+PgplbmRvYmoKMTM1IDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlw ZSAvTGluawovUmVjdCBbOTMuNTk5OTk5OSAgNTAzLjU5OTk5OSAgMTIyLjM5OTk5OSAgNTE0LjE1 OTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMy ZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMy M2FuY2hvcjY5Cj4+CmVuZG9iagoxMzYgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9M aW5rCi9SZWN0IFs5My41OTk5OTk5ICA0OTIuMDc5OTk5ICAxMjIuMzk5OTk5ICA1MDIuNjM5OTk5 IF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJ dGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzYW5j aG9yNzAKPj4KZW5kb2JqCjEzNyAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsK L1JlY3QgWzkzLjU5OTk5OTkgIDQ4MC41NTk5OTkgIDEyMi4zOTk5OTkgIDQ5MS4xMTk5OTkgXQov Qm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1w NTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjNhbmNob3I3 MQo+PgplbmRvYmoKMTM4IDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVj dCBbOTMuNTk5OTk5OSAgNDY5LjAzOTk5OSAgMTIyLjM5OTk5OSAgNDc5LjU5OTk5OSBdCi9Cb3Jk ZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3 Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMyM2FuY2hvcjcyCj4+ CmVuZG9iagoxMzkgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFs5 My41OTk5OTk5ICA0NTcuNTE5OTk5ICAxMjIuMzk5OTk5ICA0NjguMDc5OTk5IF0KL0JvcmRlciBb MCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRp ciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzYW5jaG9yNzMKPj4KZW5k b2JqCjE0MCAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzc4LjIz OTk5OTkgIDQ0NS45OTk5OTkgIDE0Ny4zNjAwMDAgIDQ1Ni41NTk5OTkgXQovQm9yZGVyIFswIDAg MF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJm ZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjNhbmNob3I3NAo+PgplbmRvYmoK MTQxIDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbNzguMjM5OTk5 OSAgNDM0LjQ3OTk5OSAgMTQ3LjM2MDAwMCAgNDQ1LjAzOTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQov RGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFm dCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMyM2FuY2hvcjc1Cj4+CmVuZG9iagoxNDIg MCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFs3OC4yMzk5OTk5ICA0 MjIuOTU5OTk5ICA4My4wMzk5OTk5ICA0MzMuNTE5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0 IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJk aWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzcmZjLmF1dGhvcnMKPj4KZW5kb2JqCjE0MyAw IG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzUyMi43MjAwMDAgIDM2 Ny4yNzk5OTkgIDU0My44NDAwMDAgIDM3NC45NTk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3Qg L2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRp ZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjN0b2MKPj4KZW5kb2JqCjEwNiAwIG9iago8PAov VHlwZSAvUGFnZQovUGFyZW50IDIgMCBSCi9Db250ZW50cyAxNDQgMCBSCi9SZXNvdXJjZXMgMTQ2 IDAgUgovQW5ub3RzIDE0NyAwIFIKL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KPj4KZW5kb2JqCjE0 NiAwIG9iago8PAovQ29sb3JTcGFjZSA8PAovUENTcCA0IDAgUgovQ1NwIC9EZXZpY2VSR0IKL0NT cGcgL0RldmljZUdyYXkKPj4KL0V4dEdTdGF0ZSA8PAovR1NhIDMgMCBSCj4+Ci9QYXR0ZXJuIDw8 Cj4+Ci9Gb250IDw8Ci9GNiA2IDAgUgovRjkgOSAwIFIKL0YxMCAxMCAwIFIKPj4KL1hPYmplY3Qg PDwKPj4KPj4KZW5kb2JqCjE0NyAwIG9iagpbIDEwOSAwIFIgMTEwIDAgUiAxMTEgMCBSIDExMiAw IFIgMTEzIDAgUiAxMTQgMCBSIDExNSAwIFIgMTE2IDAgUiAxMTcgMCBSIDExOCAwIFIgMTE5IDAg UiAxMjAgMCBSIDEyMSAwIFIgMTIyIDAgUiAxMjMgMCBSIDEyNCAwIFIgMTI1IDAgUiAxMjYgMCBS IDEyNyAwIFIgMTI4IDAgUiAxMjkgMCBSIDEzMCAwIFIgMTMxIDAgUiAxMzIgMCBSIDEzMyAwIFIg MTM0IDAgUiAxMzUgMCBSIDEzNiAwIFIgMTM3IDAgUiAxMzggMCBSIDEzOSAwIFIgMTQwIDAgUiAx NDEgMCBSIDE0MiAwIFIgMTQzIDAgUiBdCmVuZG9iagoxNDQgMCBvYmoKPDwKL0xlbmd0aCAxNDUg MCBSCi9GaWx0ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQp4nO1dS4/cuBG+96/QeQGPRVIiKSAI YM+OA+QQwLCBHBY5BN5sFgt7kcke8vejV4+k+qQukqIkytM2dt3DaUnFYj2+KhZLb//y6Z/Zv//I 3j5++k/2pf/38dMlf8jLqvuT5fXfN+MBaR+UzJs/mRXqQZt29Mu3y3P2fPl4+Vj///kidHth/0/9 y+sj8vbvH19+v7ztHn7pRj49/q3+9L9MZn+t//st++kf9eDP/f2aL3y72ErXdOS5UPWPX8c/ClnV VDWf6/Gc/th8+dfL33/Ifm8Ikw+2JV50BI5/fCN1rsqHenJqFcnPw6UP9R0rKUptFz+Pb6xUT0+R GVG2pIhm6qoo6yvqP2U9rru5tTzQongo6h8kHZemvViO7/N14f4Ne34Z0Vyp/s/i5wnNY9ps3ty/ o3n8rEo130HaJuOjubzc5+vC/SnNkfi8QPMSDUvrsgWf59f623Tcic/zsrEkS1Oar2agAqXw0i1d FFk9Uv/PZqLM/vuv+iEfW9UJUFDR/h3T0o0sKOjzjQvff768/aCzeuKff8k6Ct50/3zuiK5JqOn9 /HP2p4amP2eff7s05qgfkO2AGQZUO2CHgYJ+o7vH0+d68oEG5/nGhdf5qNn5lPV08kJPSSkpbfsM tByg8tXMWOCMRa1vNeHmoWzd0LdLreDjga+XT04iO/e42wy+cbObrG4onvC6bCddDVyAAU35FPyN Q4SrWRI/6RJ5OyDyYUSSCSn4Sv6hHSmGa0DlqnZADwPvyIB4pHyDS+hT8vf0EksHYL6SEAazE0/d 7EaT+QAsEXS+LPH9c1opWGkrtNhVz22j5loOai7leCA9NbeES/5aLoqUdLjmt+eqg5C/o0JOpR7v 0WmwEMM1Faj9j6zU0wejvSlBuUCXWFMxo7MwwQWFvPUYMGLJGEv5GM2amLMiD0ORh0keeZgVyGPJ JqWNPDyk6448kkce1XrkcYytqCSxFVW68KW3FdUG+CVVhNPZCh/pMlQhQf9AZVmlRlhBlS0dm9UD gBvYpE9yjJ/LGy0eJPGXqFjmRuTroYlvoCNyMw10hoH0LIUlXAowFLCchwc6Xqt+pkAnyl1Bhalh QOPynvJoF7ijFHvJI9hOgDv4YCCNNUghRhsssgtplBK8CS+MVKDBzs9AQvauR3upGL5AnhR61kZt Cj2HgfQcSgc9R7yO51GSDlN9pOsepqYepgp10pSWUCSlNQwkayvUBugz6TDVS7ruYSq95DsMU8v9 9+NESfbjhoH0LIUlXPI3FDJPyQx0YarPqp8oTIW4TZWc1vPah5bDH6nwu3EYckJwDAN8PJ2aLY1h sfRZAZKmAEknD5D0CoC0ZPfSDqY8pOseTG0fTDkqmG70yw6wwtrxz+mpV2fJ7CKqSCp0qJk5ITaG YkjF+mGQeh4nP7ESGw84Vwfs71R0f6dK14NYwiVXEU/VPXTA2WPV5RMFvTxgm7Go/rZefuDU4FVq rBT7h7pSkFB3GEhUY0dc8tfYpNxWp7Feq85mvEAJ7iq9TqU98J2U4/hpMpCeLnUWR169BaY7ZpCy w+Yovw0NooMpEIfN/UPjsCnrHOAmn0vCOMyl6jogdYvrAYmed0AK2AOqQlLQb9AJQhSpLAtH8LmQ guMTSppeEmAQkUfv6TWwxMjGmQlS4tQjNx9JL8FNAF4qKF97FYyBYYoDMEwxwjD1qo0G0rO7dsql RdOWapQhCs9VVp3Ojo6Dgv+FHTZIQflbPvVEHwsZJzCFSOrZtK/cP+aXpSHaV6aLeuyUSw7al1bE 0Gmfxyqnon0O1XqUMAdoD489vQKbA9ynoe7TpO4+jYf7TKsIu1Ngj1VGkWbVYqfyWvSwVFFCymvP r8L2AB9sqQ+2qftg6+GD0ypQ6VTYY5VBpHFHFXwf1c/XoDkq39/5qZw4v2EgUc0ZuOSiOQCZDtcc n1V20BxWPvmc2PkVR+zvcpQgLmcYSFVxhI/LSS/s81nlANTokKl3uAk4Mj4vw+d0Ycfg9AqrDvB0 ino6lbqnUz6eLr0wz2eV0dOxO50B5bbnV5wInfy8Faegni7hJnx2yiUXxYGi9eMVx2OVd1Ic8Fp4 vJpNw/AZTky9YuYmQiXt+c3AAU36lKb+M/UmfQOXXMwAwLDjzYDHKh9lBl4jeI3Q085b+cbt6KQa D6SqfMbDB8MWvzIpaWPNcL9lBxmfOWbCnxkJ2OO/70A0KxWhkZy3go57wLUKmnAPODvlUlANTlJF OZ2Ceiw7XxaAzpBHvKfXnOKAnmhFTlxbkXpPtIFLIZqTVkFNqzk+y45Aky2OdS44t8sDvKsDhYWa XL6O5/wKHKGRlbcCS+L6ioR7UNkpl4IUOKlMa6fAHsuOMr6JJt2h6ax+Rmge5a2fijrYhPs+2SmX QvQzrWqZTj89lp3P5MCBoZksqf/WpYPLZbtjnl8/D+i2VJTUf6bebWngUpB+JlWT0+mnx7KjjLNH vRxysVB+GvASkvNrX4TOQd7ap6l3TLjpj51yKUj7Egw/PZYdvSOiRlAdNroUXbpZyOHBfOuu7+/4 VOHRQiaa/lnq/RLuCmSnXArSvwSjR49lDyisw5YMASc4aJHGPR/kptEHNEEqKupRU2+CNHApSKOT KiDqNNpj2VN+lUK6b+/b3xB4NGIpx02NyslAehrY2qlSLPvUhBqxYE+L4xuxlB79k2bMG9/JBDgJ Z7MAPWNPSb7afqYDjEM7y3WtuX10ijY3KlNvblSeo7nRTIv243XKo7kR+k+HgyQsWMXSO74tLbgk h/6GrOcLVZdRTxojxz+nqi0vLV2K/DjxM3JCSpBF3+K9X7g5ACLtQBkqBo4ExIZsunUsw4O0yLz/ s/h5Ko789x1E1O+hraxUmSjnZEU27bD1i6XqAShU14+WqOAGJO2vKBbQQEnFDfJiI+5DBzJa3Cl+ nIfKo6c8UdIXXlOyqdbWcjqvtmWjtro0VzZ2+qQocfbGUsCMaXPvHOw9f48nOgB77hW96QdCOt4U vkFXD2cLjzX0HnQuAvK8cAnQAXYA6KBz6S0hNEsxN7hOedpvN/tcgisHsaJhNYKVD376wELgOhIW Qxxgsfu3j9y6CQjqQg5/uIekQcgmSrePoCLpIFPgoXmZAjpA+kFh4BusKDvYPrgEeApyyZK+RKlb UnXZ0hs7MfX8OvBMxXvwegn3gMdWUabbOrYalYbPFnw7iCG9Kb/aIEJ98mB0D/peWiSdBx0wueBl uCX9ifBULQTmxfJj94E1B/lkQfF0n531sX0nduPwWAmUAsegtIAHk+xNTydBay1umU9NLhUhnEyE pXPmchR/Ytd4z138CZo6KtuolqyAqIouFIumkHSeYzxS9rcofASHc2HTDyFhMqw+LDY7fYdwbCHJ ccvE+OMNNDGgyPxcAhQZ1pZlIYbJMFtwMDB9CCX83Sk8FgfY4GufEDckTko46NHEbPvrx2uIk0ye WpwET9knJ5LK9Pdx6w5wE1jIm0ueYzA5Fm1/33jjNOHImX30Aqhbaz5FNbWfgtUgMP1byLYDNvDX Uz4aDQk+FxQmil8TZlGmWJSLaRSAaAsbusJncfm0M5+JcwCPuFHB25Rd8KWa2+KGxR62P+fegS3z TJpCtGW77Uf5IPKi1JkQVfepakZV/bPtPny5CKEfbFUWKr/+Sk+v1N0922/WH1XVfT2bXKiq/p71 h+abo8c1v5L55MornV8uv17e/7DVnq5QopH9ogy3SclY7dcdWTnY+U2211hxCNktCEhN8IEVm1WJ AmruccOEjleWDowCFDUxyn2pF58gXPnc3hnofPG5/E4PK5gOcshvBgCW9I/4wX+gU/K3/SghMBCw v8anYYEONmeGcWNA0pkNzh2qYvjKEj5eAUop4OAjmr6E+5b/eDfo2CrwaQbwaWbBp7mCTwPg01zB p5mCTzOATz0LPvUVfGoAn/oKPvUUfJqdwKe52jkFFbpb7GDesdV6bAUWmkXWDuiLLQdL1+59RyUR fHDCO1sHOAbrwnpf3oYfVFaBXOdBEJ/FfoyI6Kpl6Wedq6COkQ8CHHbsIiT+kQ5+cXn7GVCkGgB6 EjFkS+UMqzGOzV8wjs3nMI7Ne4zTfJhinO5Xenql7u55xTjVLMaprhinAoxTXTFONcE43T23xzg2 vyfYuoHTJNiwnAzo8Fd8h/IYHr/6h5SwPeFQJ8wfojm02GMVoL2n8Xwd5VIaLwo+sXLZbqVV0L52 upWZTDcVGQqooAlI0ziUAgbU9CbCwn3UcKd6EJ5BPCrmt6oD8AX4MZAg/lxaAM45WyVgHKusXvYf wBryAe4uRyodkkpnrkiVpZqsQ4gc8psJ29SD+CcmHbKMUGXDH3nhDRWIHex6pepztgvfC/0Svhdm LnwvbB++1x9I+N7+Sk+v1N09+/DdFsVM+F6PXu9ZkPC9/VVHTTEJ39t77hC+ly+ApOB89iuDG/yW KPh9oIOH9P4aiGATGAQ7fjyTzxPhBhxQZ9E430cj5LQPaIN/H40z1xofCuDjAEVdLs4/hloGR4lr Z2er6exOrP1sXcqJdcqh9UjACaEYpdYInPnSJn4XHJ4bsIHPX+LfGACln02hO6jynue+fWQ72U29 aEGAGYIAMxsEmGsQYCAIMNcgwEyDADMEAWY2CDDXIMBAEGCuQYCZBgFmpyDAvkgc9HoDJ4aHOwIO lfBxt0MAHCPejZHLO407+a73PaPkMsCJweT8z2TGKB393tUwxq4lW/CypGRxQoWqXBQinofBZwvW 0m7UhPZkPP0WoDVK7HCMcOPkeBMaUGyf1pb0KsjuwHWehWcAwisPB1dSXW8Kb+vIFzr/3mIZH7Kw 5Tc4XX9PHqUuM6CyOcBdsi6Xhykhp9gDVIoHMvxGL98YFtwnWJQYgXOENqch2sBv68LkIK+4T09f cIXAMRCYgE5dMXJRvKoHxE67dFzcploPFnuhoCmK+1B28bH7IKNj+jfj5EKirV1Ay1HxWCKlBDs1 kdqkW+ImiOzeV50TMv+CtsT6BfJbbFFsf6mcuX5U2VBAZi0GqOUTC6kEwXc7zhiUGIknNgxw2Cy9 C8xagdmnjfg+G/AB/fO2STTEa79aabvEIId8KEyOglxEvbucoT2okPf8nYZWRUVR3mzBG+lk98JS NcFbxl5RbNDLi7f5cC3AZ4ccPQ2QoLReOXGX037gVTaMi1ztuUvQfJ6N0VQU6KBG9VsmmSK4E5UP 73Zn+yo7bODzxxgC0lBpvd7Px1zwx1wctrmgn17AOUMeCPC7fAGv6wow9LzZ2mJvlecYWlzefLIR n0MhIk8Yny9kSQ9pOcBPjg8jHU67+pMaJXnBi2FAw6s97VYU5/Dy6m+HTb0AiwIOht8qcj2Ge0s+ 6A7Vib3FTv00N8zLecVvMZoLnabSfacXlG9Sh3WvXfKEF5sk+rc53xqlrFtLMXUwrv41il8rxKKg 8s10A167GHCq+p6WZfixS0mMQ8fIZOtM/A95bFJw/Lqi9fOkEMOXcvW7PvOJDU4sl9nOrv6bPddz FLqluv/nyzenQ70z518/Zh8v/wepQAZMZW5kc3RyZWFtCmVuZG9iagoxNDUgMCBvYmoKNDE1MApl bmRvYmoKMTUwIDAgb2JqClszIC9YWVogNDcuNTE5OTk5OSAgCjI1MC4xNTk5OTkgIDBdCmVuZG9i agoxNTEgMCBvYmoKWzMgL1hZWiA0Ny41MTk5OTk5ICAKNTI1LjY3OTk5OSAgMF0KZW5kb2JqCjE1 MiAwIG9iagpbMyAvWFlaIDQ3LjUxOTk5OTkgIAoyMjAuMzk5OTk5ICAwXQplbmRvYmoKMTUzIDAg b2JqClszIC9YWVogNDcuNTE5OTk5OSAgCjE3Mi4zOTk5OTkgIDBdCmVuZG9iagoxNTQgMCBvYmoK WzMgL1hZWiA0Ny41MTk5OTk5ICAKNTU1LjQzOTk5OSAgMF0KZW5kb2JqCjE1NSAwIG9iago8PAov VHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzMwMi44Nzk5OTkgIDcxNC43OTk5OTkg IDM2MS40Mzk5OTkgIDcyNS4zNTk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2Ej MmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1 dGgjMmR2Mi5odG1sLmh0bWwjMjNSRkMyNjE2Cj4+CmVuZG9iagoxNTYgMCBvYmoKPDwKL1R5cGUg L0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFsxODcuNjgwMDAwICA2ODEuMTk5OTk5ICAyNDYu MjQwMDAwICA2OTEuNzU5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJm IzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJk djIuaHRtbC5odG1sIzIzUkZDNTg0OQo+PgplbmRvYmoKMTU3IDAgb2JqCjw8Ci9UeXBlIC9Bbm5v dAovU3VidHlwZSAvTGluawovUmVjdCBbNTIyLjcyMDAwMCAgNTIxLjgzOTk5OSAgNTQzLjg0MDAw MCAgNTI5LjUxOTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZh ciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0 bWwuaHRtbCMyM3RvYwo+PgplbmRvYmoKMTU4IDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlw ZSAvTGluawovUmVjdCBbNTIyLjcyMDAwMCAgMjE2LjU1OTk5OSAgNTQzLjg0MDAwMCAgMjI0LjIz OTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMy ZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMy M3RvYwo+PgplbmRvYmoKMTQ4IDAgb2JqCjw8Ci9UeXBlIC9QYWdlCi9QYXJlbnQgMiAwIFIKL0Nv bnRlbnRzIDE1OSAwIFIKL1Jlc291cmNlcyAxNjEgMCBSCi9Bbm5vdHMgMTYyIDAgUgovTWVkaWFC b3ggWzAgMCA1OTUgODQyXQo+PgplbmRvYmoKMTYxIDAgb2JqCjw8Ci9Db2xvclNwYWNlIDw8Ci9Q Q1NwIDQgMCBSCi9DU3AgL0RldmljZVJHQgovQ1NwZyAvRGV2aWNlR3JheQo+PgovRXh0R1N0YXRl IDw8Ci9HU2EgMyAwIFIKPj4KL1BhdHRlcm4gPDwKPj4KL0ZvbnQgPDwKL0Y2IDYgMCBSCi9GMTAg MTAgMCBSCi9GOSA5IDAgUgovRjE0OSAxNDkgMCBSCj4+Ci9YT2JqZWN0IDw8Cj4+Cj4+CmVuZG9i agoxNjIgMCBvYmoKWyAxNTUgMCBSIDE1NiAwIFIgMTU3IDAgUiAxNTggMCBSIF0KZW5kb2JqCjE1 OSAwIG9iago8PAovTGVuZ3RoIDE2MCAwIFIKL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFt Cnic7V1Lbxy5Eb7Pr+hzAMvNfk03ECxgy+sAOQQQLCCHRQ6BN7vBwl5E2UP+fvoxmpnmN5yPrC72 YzQSdiXRPc1isfjVk+T7v3z5Z/LrH8n7xy//Sb4efj5+2aUPadkMX0nafr87b8jqhzxLu6+kNvlD te9bv37fvSQvu6fdU/v/l52p+g8efrT/+NpF2n//8fX33fuh893Q8uXxb+1v/0uy5K/tf78lP/2j bfz58L7uge+7uqlaOtLU5O2f387/NHlq9g9V+3vbntp/dg//e/f3PyW/d4RlD3VPvBkIPP/zXd6+ M39oB1dOIvnl9NGWirzJTFnVzt/PX5znB3qKpCjr7KFof63aoedF2Y2nI6wom7IjsW1veVCZonvI ZHZ7tu/+6NuP7/nmeH/Hnl/OaG7yw5fz9xHNZ7RVad1NyUDzWV9Vlva/27SN209jOb3nm+P9Ns1K fHbQ7KLBNS8x+Hx5rr+P+ebF58uy4ZIlJT43VVX0y7UYy3NT7avumbZ9RIPVfqT57D3fHO9Xk+em qpseR4qxbDT7tOcb0DZuPxvL8T3fHO+PxGcHzS4aXPMSg8+X53okz558viwbLlka0zygf6fMXL+f 0xykPxqT5PU+S0pTJyb577/afp/m6bkq256bdh3Xbc9Vg32/KvMGVFtYP0WR5EWrgLO2n/K1myeZ mjX99zktQ4tDzb5c+eDH5937z1Vi0uT5l2Sg4N3w43kg+l1eZEXy/HPy546mH5Ln33adUXFoyPqG /akh7xvqU0NhPzG848fnw/DjcLpuB7Q9TteZicRpoYH2cuWD/XhMZ0JeGlCZteNJy+qVlh97Wko3 +aa2yf9kD3BvN9gvNZ8Yk7CXgWuFzejaTQe+o6aDay5P1qlbU9kfeaSUQrdAukNGCjcLF5oX5Ad0 Cx+xe8nS4I+kH05LZKqs168omZWUY0AHzItNeg4vfbQnaviIOWGG+Wg/srdRxe4mMzYhQBn0a6iQ gUzZH4H1YT7YHLKFTCAgQFie2k+sdTkgCA1PNFemgfIjN4xBSGn47GeASsBk/lKAOiqWOBZ7NSAd n63l4UEH/QgOPwrUAR3hMgarAd6B+GF3y5c6sJBLIcoHEBau+F2WwERdUKXVSBmgxABecAvEIQ8q aqs1t73XB5DODR+YGA1bCSilNhufBm4Zeth9XNGHjxaRLQoYKrDQg2PQC1AaDsobRtjV2hvzmN8A /dz8BLsHVRB3izgLHUtsKuIWzRhyV7I+ZtU4xhQutgukDu0L7hd5mNvUIpVoKXgptUlQ2qmG8SBM YwnFCEbcLXTrpR8YGmYf2eAEwSqUU1ukPGCaI1v4IvSAadqLRGCoE+xh1MbxNsqiGiEqLn5Y2tzi oCY7uIE8VhkHcx71lFLm1slRAo8cP+EjXFtuNw5990fm0CfcH9GAXO4EA+kwOI6wgB/g0NPI5EJO jgc4Ak/5ZDuEbio4mjE6IiE8rgYiJEjKbd66VFFSReHk2DIAgvoE5pannDgGKyx+SCih4IJ8cMsI WJjZgsuZzHMugiCigtmLbgCYfXTdcgUTM5R/DT9AYCC/SlmIwK6XTTb77PWlhiI9xWSu+ZYS/ln0 vIRBfEXBO+xeANh4itbDPgcmC4oLBHG3WRw6M5Bu0tMjIP12g/nM3noAoYnLssjL0bp0rf5rpRN8 KfOgiMLc4RICoVIyHusxlJUwvZUtRQJ/gw5PxT/nEWHFaES9d65ugSVMB6eS+gWhArCHJ8A2FNj9 4QUpcVBGoGTkeSjBWr6m/PlMUfNA0fbJTKkJmPOATsaD98DDzSxDHQ2a1eVodiXZX+AQqEOIX9Ka JUGuQlC14QEHgspKGn4Q2IsXEqZRzHTqX3pY5VzaQUB4Opg7yy5JnQp/VT5aIWhkC6TK12BQge7c DV3cgYKpAoGIoQ49iqVAYfIVgsESbuzQvCtWRfPNCoJ4E7wDK8uRATB5sIiog+iRagIhsqdX4h+D VGl4cgpBGSRMUJZCE1ooZSDuIHY8WcnjfBBwe9tBKjBc0CoFSgFj6FQq6anaAntBTG5WtVQcPYoN eQM8BMn398DE2BCrYg4Jti95eJQ0Peexr4gmEyQbnjiSg91G02IS80DgUQBA8IKhZUx9lRg1371E X6rhtnl4i3y7H6/t4aV/oEBA51AV423FqeB25QYD4BgvXRHUwmmgIxchSQpcEPbVyDbRiNQFlkWp 5qD5J64/eWAc6msziAPbngDu/t2SwzVPDmumPBAIwA2FZCX+JQiIg3QV6N4fg1igZMJ9Qx4I894H MXFwxlTj0UkWM90Z4lFnxuPcy+TwV+xhzQNuALJ8Dw8MLjxhzY09jxo5DiEegU++F4AvGQg4cfuY 46EgeKwXxri2DPnJDQKZAgGhdom3I6OiHxr3zGkcZKIT14hSiRonJmeqYsTWSEuVV/vzjfXhGCrZ 2gH2MQgRKAhBqoCHcQUVPFRRXShhoQfEYOgrXMt4RMu4CaFROaMAu5Jqf42yaoGSESQ1OYMcXNcA 9zwtXVN50zkcQbmaB6LwqmFY6joapSlGc/nWFPVqdcyG4ieS5MkykCGp8eIaRA+XgzYrrKwsaiEf I8+iAvOKIx0aJlZ4Ai5WyK1pxpPJXazwAwo27HLECY5obHPfTgUDMuSeCbEmc62ZEJVDHRxpfxUt lL8a0JKwLg/RgGXj6x5cUw9vwrKfup/B5KPp9Ug489HxGj9B9dFKzvfakMG0GrQTHAG2nrUryFpx ePM4309QxcRVhN4yU9Eq5RZXFVfVdEskL3r2cDq5Xc6XO61iiHQkT1d2PZr/mw4pxNFuGhtvfTeE B2VcIfbFfUyP8pKIWctp9cnhTrdHUZvGRht++B4/2Jyey6x4Dq2KSqmWtmTP9pCfroUaLtBM+wu/ Lv8+us7I43l+2VFgpz1zm+62qUt43RWMFScnEBLEth7lT6CcgLYeeGuMPUEn3DwUql5zHB8vzAdI 1tAS5wKpojpeIDWPleMRsuLJR56wE5i94ce+o5Tw4m3uGNik5yrbtKp+kTSFk1LOwlnOxVe8h2dq VLy/aKRMjycz2stB414mD8shfBOvx7YcfnS6QvmroKwizl1GGif4r/VcPcl2+81cRLMamKIGQv4J 7AHBUelRgoKL8lAHhE8XpOqpB9DjU0kt6jGpgpSwYOkKQoDUF11NFSIXXZqcwXdoXBmlAMtxzivi m1bnuQlS5bSy3mgt88Z/5pYxWmOec64DoKV1w/SkpPpSNzhoXBysYQpqbEm5m2CBiw568TjMbrt+ kIq7ER6mVnGMBKczhMsYL/TyoGOmuwUOGFw1znlwWA9T+83yUb930Jms6VWOyeBjCU+5eBhttxwF EdwucDU7MtVmPV5PHPOKZx1YaqYEOMMT/x7HxS50PpzHfk5e9yso4r2j8u2issYxhTB8fkQ7ZIK5 wRllC+RbCE5WZo7gpIbBPXW4+/Fw45TBKpSf3PYle8scsuIRZ+bnksU0hq5VtNFaO0kBge9hT0Eh cUFpsaQKLrySzuNIJb6xilt6/IRyR7c6UH7lGsb1FH2vecOGGXHRo2KXSxEvAw7HKpX9egBmFDPw tj6aaEb/gZ9dAnqZ47/AlBPcuKxwRfmGHUyPbaTcjeOWTLgqk4wl/E6HKEmiQxJAB/2Pt796jC78 +kIMHvColi3bHol5brcq7RkvxiwTnMIUDimc7Rq38GIJZpyLSPtQYVU2Tqm7Jbdlcznzan8LOXON 68TviYNQhSooD9IoKljGvca5hdChwELnC4juGNIQKRwL3y+p4KFLoF+h2FzDMo5ZUaMD7PXqC8rW Hkm+RinkLwQ72ehJ+xoq6KbMK73bYffmeDeyRiBZ4RBQlZhQlBvEaByFHxK71K6Am14Na7G+l6mN 237Rs+42Ar5u0UITVBNGMenBHuVH3PAtIioRoKo/JuNMWzgqCFR0Up75M1XhYtCbOkR5noTxXZ/E xz6dKwe4FTMLkvmcM7VaJRTxmvDt2AJTkb1JR9C+1Fw6UEdFbxV7l8QIRFlSg8HhkEvdPKcYcDUF 55FwFobHDST7e+66byO6TyUdIihauL1kx1R0NM11eIyz3y285h33/+ndvruvjqoPhZtXwvFIfHiF 2tpNjrlh6C0doVYfLTGPA9L4gecgSXZDNrwD79iqbCQ9U/mOZEJjixIYSdfOZQPZyuhHoNviglwA KEw8yq1oXLGYDk2b7BgkASUODdz5WKgBCONjuTe8oYbVCu6i68XTHCEAku/956FYiTxwwjgPS7sB 9B93AoAORx78rMGhQ88auMPvcBvPGj7TbuEdYDembLToN4Bf7ciVXvsITCWQzk8ChblVEFyP0UIv Dufkytyi6xFFNwb5cwRAygALZDsAshbC7g2raJhFPozjPI8roIzwANoiIj90AKS6RQvE47R3W0sZ MAW4BXI3ScZPcEptOvCl4QaHR8NqBXfR9aIDIPXdArk33HrDPQZyiR86ANLcjgWiwZCiNStvhiHL 03FvWGfDHVFjIWqRZreDqEE8BJ8u/Ay6u09nPbESn04SVX5TE6VqgRSaFgisQiwYcGxkmCZTq0W2 e8MqGuaJKttowGPGBgB1njCzJoCUt2iBCKLKGeCWwAIRNFBdiKlOmvuEDCumXO1uM6ADzleCXjj0 h1sPcRpWK7iLrherULNsDl8AJPa/eRRgul/Wo1LlwKS87C4KM/tXq6YYSD9VPR5k7Kww0ji2Ppw/ Yu80z2DrecmeKC67fdKBZmk30MyUqgPNoDjzg92Q2g2frgy0/U5e2uGaqqf78OPrd2kZ51PytPs/ oKMMjGVuZHN0cmVhbQplbmRvYmoKMTYwIDAgb2JqCjM1OTQKZW5kb2JqCjE2NCAwIG9iagpbNCAv WFlaIDQ3LjUxOTk5OTkgIAozNTEuOTE5OTk5ICAwXQplbmRvYmoKMTY1IDAgb2JqCls0IC9YWVog NDcuNTE5OTk5OSAgCjIyOC4wNzk5OTkgIDBdCmVuZG9iagoxNjYgMCBvYmoKWzQgL1hZWiA0Ny41 MTk5OTk5ICAKMzIyLjE1OTk5OSAgMF0KZW5kb2JqCjE2NyAwIG9iagpbNCAvWFlaIDQ3LjUxOTk5 OTkgIAoxOTguMzE5OTk5ICAwXQplbmRvYmoKMTY4IDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3Vi dHlwZSAvTGluawovUmVjdCBbMjE2LjQ3OTk5OSAgNjcwLjYzOTk5OSAgMjYyLjU2MDAwMCAgNjgx LjE5OTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRt cCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRt bCMyM0ZpZ3VyZSMyZDEKPj4KZW5kb2JqCjE2OSAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5 cGUgL0xpbmsKL1JlY3QgWzEzMS4wMzk5OTkgIDM2Mi40Nzk5OTkgIDE3Ny4xMjAwMDAgIDM3My4w Mzk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAj MmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwj MjNGaWd1cmUjMmQzCj4+CmVuZG9iagoxNzAgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBl IC9MaW5rCi9SZWN0IFs1MjIuNzIwMDAwICAzMTguMzE5OTk5ICA1NDMuODQwMDAwICAzMjYgXQov Qm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1w NTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjN0b2MKPj4K ZW5kb2JqCjE3MSAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzUy Mi43MjAwMDAgIDE5NC40Nzk5OTkgIDU0My44NDAwMDAgIDIwMi4xNTk5OTkgXQovQm9yZGVyIFsw IDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGly IzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjN0b2MKPj4KZW5kb2JqCjE3 MiAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzE2NC42Mzk5OTkg IDEyNy4yNzk5OTkgIDIyMy4xOTk5OTkgIDEzNy44Mzk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rl c3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQj MmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjNSRkMyNjE2Cj4+CmVuZG9iagoxNjMgMCBv YmoKPDwKL1R5cGUgL1BhZ2UKL1BhcmVudCAyIDAgUgovQ29udGVudHMgMTczIDAgUgovUmVzb3Vy Y2VzIDE3NSAwIFIKL0Fubm90cyAxNzYgMCBSCi9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCj4+CmVu ZG9iagoxNzUgMCBvYmoKPDwKL0NvbG9yU3BhY2UgPDwKL1BDU3AgNCAwIFIKL0NTcCAvRGV2aWNl UkdCCi9DU3BnIC9EZXZpY2VHcmF5Cj4+Ci9FeHRHU3RhdGUgPDwKL0dTYSAzIDAgUgo+PgovUGF0 dGVybiA8PAo+PgovRm9udCA8PAovRjYgNiAwIFIKL0YxNDkgMTQ5IDAgUgovRjEwIDEwIDAgUgov RjkgOSAwIFIKPj4KL1hPYmplY3QgPDwKPj4KPj4KZW5kb2JqCjE3NiAwIG9iagpbIDE2OCAwIFIg MTY5IDAgUiAxNzAgMCBSIDE3MSAwIFIgMTcyIDAgUiBdCmVuZG9iagoxNzMgMCBvYmoKPDwKL0xl bmd0aCAxNzQgMCBSCi9GaWx0ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQp4nO1dS2/cOBK+96/Q eYE4pEQ9CCwGSJxkgTkMYNjAHgZzWCSTXQT2YL1zmL+/aknuluprdlHs0qPVtJHEZtRksVj11Yuk 3v/j8V/Jv/9M3t8//jf52v17/7hTdyq37Vei6u93/Ya0ustStf9KKp3dFWXT+vVl95q87h52D/Xf rztdNB/s/qn/820I1Xz/+fWP3ft28F3b8nj/S/3TX0ma/Fz/+ZH8+lvd+K3rb//Ay66yRU2HUjqr f33u/6pTm9eU1D/X7Yr+un/4P7t//i35Y09Yelc1xOuWwP6v73JtK7VvKC8i+fX40a73PbNcP/c7 HkVfkSdGFToxVVU/Z5L//b77Xo8+y9i2HjZNVZLremwcuVCZTXVeVM6f+yNnWTeSSUpbmjtTD6nr Bc9Mvl9FpfK6vSrv0qa9XvlCtw+ltD1tf0n7/Tw7+t8LxfcezTbrvpw/D2g+0rbvuhHEhubjWJVq OUhpI+2HufT6eXb0T2kW4rODZhcNrnWZgs+n1/plyDcvPp+WDZcsCfFZK5XlTadDea7bTdUwdEgD aT/Q3Ovn2dG/mDzXfRaNphPZqNvLA6wOaeu39+fy1s+zo/+J+Oyg2UWDa12m4PPptX4h7T58Pi0b Llka0vxmzC2YtnEWyJjEFDavfYJE529m4CHMzOrmu09L2+Iws69nPvjxaff+S1EzIHn6nrQUvGv/ eWqJfmdKVSRP35K/72n6KXn6sds7FV1D2jSUx4asaaiODYY+0fbx+amb/jScrvLiCjldFeVEnA50 0F7PfLCZjzY2qb3KUzOy9YRUmQ6JqSh1QP+5JxZqWC1hsWEVDSltANW8rYb0iDsXA0hV+q/DavXU yDFEq4iosWHrDRFRJ0NUrbeDqKN4mJOGFJ4oZ1lLmEtBGjTfQPVDU35AAwybAh0f6RMwCjQodnKz 6IemazuJ4GpoYJcBeKoq2nA/erGX9kCy6IHEhq03zCIf+jOr6wAPX0Z/ZHUhjNmiB6LteA8EJifh gYChB+MIAgJWis4FLR21UvxHUvjI9RjYgGVYreAuqi8yAFKM8EBWG0pKuHWxYbsNqxXcK8iBuMps aV7W+JFqwvVjma0zDsVx2C/kiayNeXtltk+04UPTkFMDA5W5XnUvJ0+YdvrG/ZHO37BH+/qR9KEz OhdLCENK7ymln9k+gDA6FxhFUUqxU3gC6IDZAk/ZtcWPQKclYXLXqacZUw4rlqd7KTSkrN6bLa/7 hsoH7+ZUdJSKcv0zbYBOQdahD0pYJ/yG8rTH9U90FEO5DrOlWgmd4ijUt5bgB34EUlMQFvBzucx3 cgldpsqh1MFKsREMsAzlAVgGs4MwgB0FWQZsD1AYnu3s4oooDKUD1WEaeTBlNpAHfmGAdlRUPlXr mIzs4gLoAFMx1Ia1BMLgCVgpAJ0A2QYRgqjYytmgQnurA4iyB8SOR5SFxMHDfvBWimUhVFSQUt4o AQtpCgT6yDIJgSmKvcBU9q1TRQkrCD8yEV9Jq/24mTKCzpKHKAMq80DGukIIILTTDBwMNiPIS0wA 5uCwvBYCwvKuAIRSvH8VbC3PoQEP7C3XdXaGhxI+CSsguJbjDRv6JDxhLPgh23ln6QMdBYadIjC6 ftmWQVRtnZOZBZZkvFid28FkULhZfwoBgveE4SMIEDAuXyDiIzIQER4x2AgEfR/IAvFgBxoS8fFi fKSjoMsFMsaaenyCBTt+Lp2ndySs21x0Dtp5SAXSodbHiwOY+oAQHhJpDn2RgeXs4OjyEdla4SEF 4weEgUWRsQaVHfJQAnS250CMCkBZjcHVHg9tAUgWYNgnyfmdMP18EpjXBxgGtO6DhMY0UX1mnFF9 +omAv2hUX9xEVO/hUFDCeJ2aRkFuCuswHcc7A+PlA/OEMCzwAwSGTRxiHwFZH1ajPGSdT/nyLGTR ETU7QCsD3EnWOAZMzjtLfGnC3+oh5Pr6RjJQX/qnG7YUxGVWQC83BMIekSFkn+iGEgnN9VBlvnLP bykQKAl5GLYA0YbAeJYS6jwWF0NY6jujBI13rzwsHbCQjz98pfBSt1/bISg7KJPBfjvC5oz3Y1C3 +dUF6wDD8mvHZponcVoDEmcz4VRAuMFCvUf5G7Ji7ORWGypIAFesqsnr3NpXXwSljTrU0HjLxiMs m6z2cIQD0FFitxCf0AsQbhF3cryPitWLgOLe9eTiAuqSi1a/bxVRvXc5TqzrgqGCDAinxilCAA+w 8Q9I5eVBYAP7QhBzWwozU11OrqZUR31v+Ak1pSl3ipr8JmpKa9kpGgL1wFM2V+uRvhvvCuBBtfGH FUKwTwK3JOoOAvmLkB3u7LZ5j+lHe+JlT2QAtTjEhXPuDbl4X6ga0C7hcF5dxTAqSLjDNU3OR9C/ qt78HPSvWsK0OrSIOlj2oFMxkTjWXVjJ7rorcjkWOjG4kN8vYKVQYPjdM7BQMMpaF2qD+CGC0rl+ Mw+TGDKPbRwSGT6+KjuP9I/fbcen7xba0XnN0bec95Sn7uwUvWFR0nnKTcxO+Up/QHZKwvLzQR6Y C94W8teABGw/W+tGynjAejzLVhIYTHTZSAd+uTMbs8GA5FKW2WrAsoBMc8xXRdcnQdendCeOKGGi rk8lmjeKSP4Uo/4tqPZthdL8bCdRoJnEcqG9ZCLGobkQrqBvB7osPp3nxoaAQ4lr2fPpccqGd+Kv ON8dsF8TmAy39UCnoHS+V67Gw9Tes53pMHVMLXDGUeZ8WOOy96yB3NlYETN1eAcVxDAhhxf4tIBE um486ExyGyiM4n2T58SFS++7R/IxhAXcixBglMYf3YjV0ItNzmqSppMU7jZ1V5GIUcqraoD9y96s ImLHjq9Ci280GM1CbfMhD3tx8KHPu1R1X86f+yP6PP94/8tOJX8lafJz/edH8utvNT3f+hMZOWgz TZvo/OQ7a/aeWHnwxPA1avTAb/qBewJXDBraUbSm0mbPSEpKn7inDa32FVQeQXR60gavmHXINIAt uKZn3ifSvTtHp25SgRDstTohfiDSbQsvQiFwUprK5cLFcJWs+DxHuuOtXE8jg+Qbr1muK4twLu0W nADohW/xcqwJ3KJCDW0BxveOAFfCoy2LzAkP89To2ONkHjcKxT1gI/EC3znDZ2bidRcXuxc3VT65 4hq/yKVME+YhyrJycmzLl6nNdIcfb3DiZYtD65Gx+nIDfuC5kI/fakCZ7LHPCGYL6WIsL/FbgFh4 CDldtBK/Z544SSh9XpZDqAe9ZAsb2AApeFanBF9fWdrMuVJrzYkAC+fZ/7eQh3pj68IbetAXmBxf 91moIAl7GWe5rBXjE7ZS5pEC4M9OeFRK+Voiz2X+ICm/fSl8E+GlIJxVQxSexJ32Tc1KWJRKVc61 gwtM+Uq5hC8YkGWfwiXfcHG1OrhEEsVVvo9YfqUsUzBd6IQWNDuJXbDaalW8CMcXxKYIaEWqrfOk Q+dJZK/2mv/bEu24K/HpbBCw8K5ECTfRHq9p5t8VDd4YGwMGXER6zVUsieONt5UPZD3KbkPbGT0N OFvg8UpzfvrssdOlDlFOYRu3bejW9frpizeXmyGwL3vSTMRKZbf5zkWPzO31WsuZtG4l5+W3JJYi 23di9HVqthejpRrA5UIhHB6AhE75qGeK/ZAhxxtBC+UuqbDHV3zQ6aOPNkmAwtf5Fn056PxHsdI8 HywMbP/0uPdlodN8AaE1b3Km4XJGxD/6ApvxBTCPxG9/hfq7hIOxcs9YxH4c32gCmBNfRjOb0yZc DRL0L+zhsC29gcLDjPNc5xVoFlyPZ94i8l8R8p9jYYTxrcC4YO5OwBTkNb7f5lKupIi9wXvBo/EU NJ4iteNZ9gDd+tF2R8n64jMtZoDSHg47r9q+2U4RA5OW/osb0YBBA1YMvavJt2qToiu9CDou439N WSi/FBx1MUTHm0I218U4IhbHpM7ZXs3hPA94CEi7sQslEePgXNhjYyI33K8V2GfKGYmlh3NVHjqN 5z7G2rUpzn0EXNfE76zwQLoAUOKPbsIooLd8SZu/tsFDYtiYNyRRy7o1KCD8xScSx33ZbfweuzHY HR0hV5HBExCdBmyCCDgrMoULP+vZ7kuh3xLsd1RYyAHZ3HZfMBz9P4+Dr+7OGtoL1+Ycsz/luv97 wHZwBWAnmlZ0dr3PtAa1d0EunD+FK+DykwsROi2dmcH1z0tNy+GbB0+rrAabfIymFMEscOYGHqFm JAW7knNPmN45+/o7ea2nq4uG7u6fry+hZ3Efkofd/wHmheJIZW5kc3RyZWFtCmVuZG9iagoxNzQg MCBvYmoKMzE4NAplbmRvYmoKMTc4IDAgb2JqCls1IC9YWVogNDcuNTE5OTk5OSAgCjQ5Mi4wNzk5 OTkgIDBdCmVuZG9iagoxNzkgMCBvYmoKWzUgL1hZWiA0Ny41MTk5OTk5ICAKMzAxLjAzOTk5OSAg MF0KZW5kb2JqCjE4MCAwIG9iagpbNSAvWFlaIDQ3LjUxOTk5OTkgIAo3NjkuNTE5OTk5ICAwXQpl bmRvYmoKMTgxIDAgb2JqCls1IC9YWVogNDcuNTE5OTk5OSAgCjUyMS44Mzk5OTkgIDBdCmVuZG9i agoxODIgMCBvYmoKWzUgL1hZWiA0Ny41MTk5OTk5ICAKMTY1LjY3OTk5OSAgMF0KZW5kb2JqCjE4 MyAwIG9iagpbNSAvWFlaIDQ3LjUxOTk5OTkgIAozMzAuNzk5OTk5ICAwXQplbmRvYmoKMTg0IDAg b2JqCls1IC9YWVogNDcuNTE5OTk5OSAgCjE5NS40Mzk5OTkgIDBdCmVuZG9iagoxODUgMCBvYmoK WzUgL1hZWiA0Ny41MTk5OTk5ICAKNzM5Ljc1OTk5OSAgMF0KZW5kb2JqCjE4NiAwIG9iago8PAov VHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzUyMi43MjAwMDAgIDczNS45MTk5OTkg IDU0My44NDAwMDAgIDc0My41OTk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2Ej MmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1 dGgjMmR2Mi5odG1sLmh0bWwjMjN0b2MKPj4KZW5kb2JqCjE4NyAwIG9iago8PAovVHlwZSAvQW5u b3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzUyMi43MjAwMDAgIDQ4OC4yMzk5OTkgIDU0My44NDAw MDAgIDQ5NS45MTk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2 YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5o dG1sLmh0bWwjMjN0b2MKPj4KZW5kb2JqCjE4OCAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5 cGUgL0xpbmsKL1JlY3QgWzUyMi43MjAwMDAgIDI5Ny4xOTk5OTkgIDU0My44NDAwMDAgIDMwNC44 Nzk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAj MmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwj MjN0b2MKPj4KZW5kb2JqCjE4OSAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsK L1JlY3QgWzUyMi43MjAwMDAgIDE2MS44Mzk5OTkgIDU0My44NDAwMDAgIDE2OS41MTk5OTkgXQov Qm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1w NTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjN0b2MKPj4K ZW5kb2JqCjE3NyAwIG9iago8PAovVHlwZSAvUGFnZQovUGFyZW50IDIgMCBSCi9Db250ZW50cyAx OTAgMCBSCi9SZXNvdXJjZXMgMTkyIDAgUgovQW5ub3RzIDE5MyAwIFIKL01lZGlhQm94IFswIDAg NTk1IDg0Ml0KPj4KZW5kb2JqCjE5MiAwIG9iago8PAovQ29sb3JTcGFjZSA8PAovUENTcCA0IDAg UgovQ1NwIC9EZXZpY2VSR0IKL0NTcGcgL0RldmljZUdyYXkKPj4KL0V4dEdTdGF0ZSA8PAovR1Nh IDMgMCBSCj4+Ci9QYXR0ZXJuIDw8Cj4+Ci9Gb250IDw8Ci9GNiA2IDAgUgovRjEwIDEwIDAgUgov RjkgOSAwIFIKPj4KL1hPYmplY3QgPDwKPj4KPj4KZW5kb2JqCjE5MyAwIG9iagpbIDE4NiAwIFIg MTg3IDAgUiAxODggMCBSIDE4OSAwIFIgXQplbmRvYmoKMTkwIDAgb2JqCjw8Ci9MZW5ndGggMTkx IDAgUgovRmlsdGVyIC9GbGF0ZURlY29kZQo+PgpzdHJlYW0KeJztXUuP3LgRvvev0DmAx6LeAoIF 7Fk7QA4BBh4gh0UOgTe7wWJmkcke8vejlro1Ir9mF1kqUlK3PEg85nZTpWK9X/z4l2//TH79I/n4 +O0/yffT34/fDulDWrbDnyTtfj5MF7LmIc/S45+kUflDVfer318Pb8nb4enw1P3/20FV/RdPf3X/ 8fyItP/54/vvh4/Dww/DyrfHv3W//S/Jkr92//st+ekf3eLPp/2OH3g9NG3VwZGmKu/++TL9p8rT Rj1U3e/demr+8/jhfx/+/qfk9yNg2UPTA68GAKf//FAVbV48FGnazgL57f2rHRR5m6myaqy/TzfO 8xM8RaJSpR6yHrLXQ16Ux/dJ07Jbz4qHAeIOB5Xq4VWZuZ7Vxy/36+M+L5b9j+j5ZQJzm5/+WH/X YJ7Cllf9/j3M02cVbf8ZgE1bn7zLuM+LZX8TZiE8W2C2wWA7lxB4vnzWr/q6E54v04aNloTwXKrT 77VOz6U6/V7rMBjrI8yTfV4s+4vRc6nK5gjOAPP0WfWAN4BNW5+8y7jPi2X/QHi2wGyDwXYuIfB8 +axf9XUnPF+mDRstCeG56ZRgr34ynZ6b02e6dQ0GY32EebLPi2V/MXpuTr8PME+fNdAAwqatT95l 3OfFsn8gPFtgtsFgO5cQeL581q/6uhOeL9OGjZbE9GBZD5ua9kbZlGdjStMR2vpEp4z7vFj2F7Q3 ynZAnKm7q0GxAWza+vRdzvu8WPYPhGcLzDYYbOcSAs+Xz9qwN5zwfJk2bLSkw3x2O1owwr1s+ao4 aq4q77yXRJXJf//VPeSpN9UZDoHqf6awDCsWh+Dtyhc/Px8+fq06BCTPvyQDBB+Gv54HoD90uq5I nn9O/nyE6Yfk+bfD0f05LWT9Qv2+kPcLzftCYX5i2OPL8+n1w2C6aMoNYrpoq81hus6LDWK6LsrN YbrtXmh7mO6UUSBMM8Mjb1e+2L+POgZwLr1QmXXvkzYj5Tya0NbmQtMvlOYbN/Y3Vorc46uBRvWj iSQADPawILqYAzrsAYCp2qQA810Y+MiUCTq8i4kP2FS1MfCBe3wxF2hIGxOnw2PVFaTid8wFPIcf yXOAt4OvZOTBSCAVUAZUB/wBREYjiAYdXr8kH0viFOkSDgpICJ4Cr2+CDmypHue//ukrvaSeIXLz Vpe5mxFL+Nhhob3yFPrlAMsWlTMX7UdNp9IR9M/mU4Dp/EUMoDCDtwWqozHGEDHAQSSSEVIadAlR R/M6YJ0mGHNTWlw6iH6T1pFfYFMTjryl1BjCYb4cfoV8rPpE6WQ8/RBGC/IcHCVp1TGMSeRsUA6u 2mKmDCrKShNC8Ha5qWBplK1XKlnU5xUe40gUIHYTH5mSOLpBfajSGckOKhlYmzSNOEe5S2lPCko/ vRPMe9hjKM/o/lh/19x1h8/TzrznQ3sKbo/RlAsEnPWiZ7Q6s8pEwycDt9kn6hMp0Ct8Ag7MXMhq U0mA83di4PczzcrL9An2MBwysMWCUZdMGZHRCeEzWBREBeARdAntJCBL+isGFFH+IQIH9UNGCGg3 Gw0WWreKYBmiCrSzRkd3JEJ5Fja6FrlLTZTRkTuBSA0SKuwBGKO9avNc8ChJ/eOgssDEo8OjDgEy OAd/EkK6pOlhmciEjdnnGn1FqgtqEfaH18PTZHg9DAlhsS4lLOUsH1MktJQFU4QMX6CZ5+8Vc1xt CXvcX+ugcKPFMEOo+L8L0japyXFTUEv+wQkHxQ1nCzj1PznaxMi/UAjKSH2ZfzZpPQg5kKZ79pki mDC+58oM27nSMdXFo4SN4ZAupMMVQMt0ghX4gVY5jIQaI/UHIsVV1omovqKyonAzmR0Hl2x3OJ5n OhwOfLthCmI45BKsLuAp205/bvQ/LXTxsKf5ryuYIGn+PDUf62/WLRVTByMWOJlmS4sGFtF8lVoY QRtOOtyVOs2VuQedORAIkocMRc9koLxQ1zkIJBv6dAxfiqGT15JXYMhtPEw6R026Dg6OEggdh4gf rT8FSmIdQgk0YHFKNOSKwLL6bIGBLbCWuNHufnkTrr/7hUqIxinJHjLaIGtyjVAX8owcbGX/snM6 aMyQqBJ1c5yKef8aJ8x2wKaAD1oHhRAgG3ZHbfalhPrI03PvYD5AqtQViervOUcNeO4k5K5yQDyQ zuVq6vdWa8THKQ6KlGQJ0fpz21acf9Ye86WutsFc2d/qwh/FAaCdjlcxHFQ5PyhXrSTV7W2f+gID HyFy8HSQ1CEa4eB/0U4uyQ53lg8LEkghw4aco6SJDJwaOhbLEOQBC2fnClRVahIV344O3y2UZYqS qHO2FkQUWz56aMNjVfpOdoXxXBCpqw0lOAgMUpLxzafAdu4teYqcMNF2FFuUTF1U+phb11HUmtCJ FI5Aqw1wRut+f70dpmc1TizWlclElFAxeld3Xsjg3zQSpDHYQcZADEwiKBYikuIQSYBGJMZojs1o bUF9OrvIr7lj5r/pAReSOaS6PgMGEZ2bDs2HKTiiG8Yc/J6VFHk6WE+0NvB3+2hm5whuiSl1AAck c8gokAM7kPhAVUdPFPPvdokUrY3ahHulnmS19VaiOaNR2Ic8BxG11MHLl8Ir7nSOU4FHN9mZdspq Wp+36wrRVXyMNm6OPc2oYGYE52n56J91Fgk+AnsApChB6OiTf6jAoaPUfzqis90yVwpXjS6G4WT8 W70FK6eLtLbCAWFBuqaAkWjaSzSvc/+GsiZkHkEN5DBJ3jmM24EeW/+El0gZgn+njUNJO1QPMtw6 Ac+HM3/Df+wvtoDQpeX+6QyagtCZpkflxqo6qBtdKtNhL3/BZZsMIaJQMrumk5j6Qhcq+NfwMkps YtXfLpNq4JhgcUYt3VfZM6eejhGOpHkq4ADma4JbovdisbRRq3RxeF914CGmNwrymIiqy2sbCpdq 7fafRYZPoSfAmTYZHSa84QHM5WirSQxgdhjRDIcObDLQybSJDeQmkMGjKXtrc2Fg4MpkcS+SHpxK lZkyf7pizobGbU1IEAODbJn4mScxeAUDuACgIZIAJ5X5CUuR9PRw4HXgtGBXix6cfMISZirsGIEZ 3CeMLDhQu8ybM/gSFYh3VbiBKlngfhw00UiLxMHH39rICp98KD4FBLpFWc5ztugKG0AQvD4jLy0y TmAlhOqQh1qm0UawfWF2OrzUxPSyM+IkjPruZZypLkgC4Kbdwkg3R+wZI0IabCZjJGH33ZJ9ETUN M/tazFoXqHRkmhE0jKk+RRRMNSrLtcQ7XUdgycam8BNkypVxpaXDzGZaJwE+GC4d455hgIMmXHpw Cs0vYG7RCdWYcfndoXc2HkLeGD5bFipdGC4zwwH9ddIbR3lBWzEx2xTLJl8Wp5xKGdLlR3ag4ZCQ wQxzk9Y45CgJEZlDp5xI5yvMHUPgfUC2jNZrDoXodA8qY2R3CKOFY/bSDVN0xxCd+qNtpUiBpqJW mmi7pfJ2h6IOiagq29sQUUptY0NQnE7wPaw2X68LVDlw/ER/99R56J4PBa2mlmK7PXihruEpcl3E 3BXzhxmcLtcZX2XnmefZV5KlggQSSJ+fEVcK0jCwHTnOiMWEaR+iXcs40/BIrlzqlr+VZIf2AOBx QSIAOFcml60mlDecHcvk/JOq2C86m0mXt5lwlXBHgowbxWBmiPCWRBcPw6URsSZonmOoU0aKZakr h4o21yUb4BDmPNJuIYkQfogwMG0LRrOq8iZvfJWoxrkrp0ei/hPPhY5TY66DLj1by70LtH2xkLyQ eLmYTt/sjEqjSzJ/F85BodLnEIXqljXIRVROrWyA7TY8oWEkxAPuQceU6UkEIVwHOp2ISQd63sFC tuNKrlvbPjfM1RZlrQmhOMOo8RzoW95odxRG9gncscGZWLg1T0FEjTWVDQ4HE41mOpDSDMXPkChy 3tcttsjXo5Ep0iIPUoLRIg9d2ND9DA3TnKZr+rl797dVVtTNOF8jRBdQnITc9i2Ha8XSDBkepfyL YfFfmCQVYk7WWvLCG7oPNMgE4c13bgepzJIw8Zr0PkdeRbr4ei1Ng/ddcYueGF2FF2UEmEj2QGRC /zIlQYybZBzelq7/YiBoJUUigSJGVVrpyoAxgd1i+IloKWUd3icSH6RFCt3uC3sAb6+l5S2KUevQ JyOR9qPTXruIERIxXjj176J0GIUBaty/Fc+hvsffEBSpogkSo1+sYbyvW52I7duzN0X0Wn5WuIyZ cJy7xMnga2bGL/fAm0FS2y1C3WekMVl98TgCpx7OP5jHHws/u/a10IXhWsMm25nRQSew+dMiRDRf MZoG/kzncCcIIxtAF2YxYsp0WQ3wGOkEYmbnzkmb1tF7g5svrZO2JGcyhqvHP1efZI0uYhhEtlBP i0QJ3Vprl9YemxHRa1XmTEGrCeeAGqMdBYb3wdDzu/cxm4HWFYibyWJ52eg8tkfzfG2U++KPmFG1 WywGbUef3KEYVKDUMx2eMim5hIuL6JuM6NuCbL2SrUmfEwu5JB+rLpABCLiQNZhtlet4bE2sLW4D MmqtI00hu6UIdJDoMaNEZBlPZGVuxQYiBvgUWnSDhLmvyzDkAlkSbmdbN9bH0qUrEkEHmpL9fRUH scUoapaIqOx+qCfx01MuN1S1GCdUHue6nYXEBUNa0kYNkJRchvNaHIsch88IFQuV4fQ3vr0rh5AM I6LG2si3ITB4LI5Hs1p1StfWC9xYjzlQupohStG/RMWMQ/QQPkEPpwih54P01MXxAuhkZJjKHUao mDHfY7GyzqrWpPTmJ/VUHS6tpCyQJI9zW4SDxmG02NJcuC7aXl9YZal8RBAauyuHNn7iaK4cy8dR LQJeYZyQ2YXeRkvm5pqZxwjC+0d/RUJCQNsh8ge06cwRIGtJKNB5Hf/whUOJBINh9tS8LzdI2Cy0 RJF4mfVUOvYBnonwd+BLst5YCWqlchxBJ9FzK3GH+86od8SojJdxOG2IJDAsP4baDnEbmYsJBsct MLAWWxjgdSE0C0+hg7d03U8cQzdmkmV25245V3A7XEMRpxDeEpwU0WyVXeXCY5HJaMYE85mWjzS1 B4kD0NROXrLLGYDvP6/Zdm+eV5WLiSCHG8skFBmZyQxjpWxmiNwt1fM5zASnG2TpYwikP1SjiUeR 2kyyzxLjRLSWYgQowqW+q7RRNnoIM60syPAhxgi0teSPlwkUyMRAGbMtF7oBlGY6hodGu5uuw8qu FTrc47U1jGjt3N7dptakISP0vBo/cBJI636Stw4tqupf9PTX91dup8hT8nT4Py7ziPxlbmRzdHJl YW0KZW5kb2JqCjE5MSAwIG9iagozOTQ3CmVuZG9iagoxOTUgMCBvYmoKWzYgL1hZWiA0Ny41MTk5 OTk5ICAKNjg4Ljg3OTk5OSAgMF0KZW5kb2JqCjE5NiAwIG9iagpbNiAvWFlaIDQ3LjUxOTk5OTkg IAo2NTkuMTE5OTk5ICAwXQplbmRvYmoKMTk3IDAgb2JqCls2IC9YWVogNDcuNTE5OTk5OSAgCjQ2 NC4yMzk5OTkgIDBdCmVuZG9iagoxOTggMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9M aW5rCi9SZWN0IFs1MjIuNzIwMDAwICA2NTUuMjc5OTk5ICA1NDMuODQwMDAwICA2NjIuOTU5OTk5 IF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJ dGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzdG9j Cj4+CmVuZG9iagoxOTkgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0 IFszNDcuMDM5OTk5ICA1NTMuNTE5OTk5ICAzOTMuMTE5OTk5ICA1NjQuMDc5OTk5IF0KL0JvcmRl ciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2 LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzRmlndXJlIzJkMQo+ PgplbmRvYmoKMjAwIDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBb MTczLjI4MDAwMCAgMTQ2LjQ3OTk5OSAgMjE5LjM2MDAwMCAgMTU3LjAzOTk5OSBdCi9Cb3JkZXIg WzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5k aXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMyM0ZpZ3VyZSMyZDIKPj4K ZW5kb2JqCjE5NCAwIG9iago8PAovVHlwZSAvUGFnZQovUGFyZW50IDIgMCBSCi9Db250ZW50cyAy MDEgMCBSCi9SZXNvdXJjZXMgMjAzIDAgUgovQW5ub3RzIDIwNCAwIFIKL01lZGlhQm94IFswIDAg NTk1IDg0Ml0KPj4KZW5kb2JqCjIwMyAwIG9iago8PAovQ29sb3JTcGFjZSA8PAovUENTcCA0IDAg UgovQ1NwIC9EZXZpY2VSR0IKL0NTcGcgL0RldmljZUdyYXkKPj4KL0V4dEdTdGF0ZSA8PAovR1Nh IDMgMCBSCj4+Ci9QYXR0ZXJuIDw8Cj4+Ci9Gb250IDw8Ci9GNiA2IDAgUgovRjEwIDEwIDAgUgov RjkgOSAwIFIKL0YxNDkgMTQ5IDAgUgo+PgovWE9iamVjdCA8PAo+Pgo+PgplbmRvYmoKMjA0IDAg b2JqClsgMTk4IDAgUiAxOTkgMCBSIDIwMCAwIFIgXQplbmRvYmoKMjAxIDAgb2JqCjw8Ci9MZW5n dGggMjAyIDAgUgovRmlsdGVyIC9GbGF0ZURlY29kZQo+PgpzdHJlYW0KeJztXUtv3DgSvvev0HkB O6TeAhYLJE6ywBwGMGxgD4M5LJKdXQTJYL1zmL+/6la7W82vqY+qpiRKpo0Z2xU1WUXWu4riu78/ /TP59x/Ju4en/yZfjj8fnnbqXhVN95Wo9vuuD0jr+yxV+6+k1tl9WR2gX37sXpKX3ePusf3/y06X hw8ef7T/+DqFOnz/8eX33btu8l0HeXr4uf3tzyRNfmr/+5b88msL/Hocb//Aj13dlC0eSums/fN7 /0+dKV3dl+3vLVyZf+4f/s/uH39Jft8jlt7XB+R1h2D/z7uqVrpsx9T6JpRfzh9tsciaVBdlbf29 P3CWHfHJkzQrivv9Omct6Vle7OlRqmjhZb0nu4W3a1Dq/D5vEU5NeFrtP3yAn8b5bhl/vzy/9XBu suOX9fcLnPu41eow/gHn/lxNdngGcLuA92g5jfPdMr6Js6d1tuBsw8G2L1Os8/W9/nEJd1rn67xh 46VLnDtp2Qu/7fc+zqPkrdFJWeRZUug60cn//tXO+zjPzGXRzly2M9d5kmX1rHPvqW6y0kb1q9pt QAmNozDPkzJtVKu9E128TvMoU4j68N3HpYNYFOLLwAc/PO/efS4TrZLn35IOg7vux3OH9F3ZKvPk +Wvy1z1Of0uev+326v8ISA+A6gzIDoD6DMjNJ7oxPj33V3mcgn8Z+OCBHr03QdcIKtKWHq2aS1wq k56a0pOfAQ/GE/qjMSgAYFBdmx8xATht90RxBnw0By3otJoRpz+YT3xi06bKnPazwTS6YYvsQD6s OqUFP1LSaWGRgXy6+ziGuR64c3xfKnMMwOOBSqZJS6rNFYMlBPJh50yGccAUVgwYxlyPFMQUFgh4 DAZNzY+YAL5iDhIFu0/ZUlV0DCDf5CDEFMgHMQU8/DHuQdnfoLXL6kJtI8dQRCSibe4DF+3jLLeS ezBSaX4cNFOM69R7g6dQPswnkA2BWlgxKg64/SDr3Rg6Gxh1vKpHYed2DAalJlh3gzYjpA4QyzRT BzgLSB1XB1zHwLSw2+OVMKp6vrezeDHI25yDOLNzjQL8AcRxxgUfBew6X1OBU8stHZAP1IIdgyWk jrEn+1HkFxpVoNrQq+XOAde5PPwAKfRoYbJTGLQhz9hBPXBqqSJzCFAsOzcU44HAeHCEtxSe8mmv +BfcNZ5EG3L5gM0dLx8OWklgHQShtdjk3KjI8roe1mQbDKaG3HyuhAUB6vjI4OjXeLFSRW7FFDYK UIc1NVU9Dgo7R5WwD3FAxeWQjaExjEN0AYiYtg+NoQc8HDQq1+QOmUaBvdye9zwU5U3h+GYNc30Q MZApmMWiY24KLj0Zoaq8VFQLhZse8iQOiQKan3AgjgsMpQUlOfNnc8rGxjGYJJ4knyvIK3N3chaf xCXDN94FA55CcXjvb/ub6nXQ0mD2bQdPlGMcXB8aTQhilvUUc3BaniNGgaGCCnvJncV5CiDca+Hy IXF8BRWBpfQUj1G4ieEWBQQEvPhAYliP1S0fuj/VqZXZQXLNVDxWmagil4TwMAvPGgMtHho98CNc xXIOourBoYQGQT4PUAXRhSA3HWPLi1kkRZXx0yIt3EjRmqtDGY5uVMYjBcBDkjcZ79fYvOshm7R6 V9mL+UhPoQO3noISAWg27glM0Vsnyb2MV3XhuGjiDLiP7NTitTyBb+DAhjyWEKxpIMZRIGOCsiRq A8ADrBRvlJtHtIELeUsfdzd9hFacuAlbMtI8tS4QJd+hjxbIDyRpOE3qWiBRvDOdLyEtZUzS9eUg QGBOHboigRgfKeIt8/ZgYvp8qqg7v6kOZ5iu/35xGsbheX5WZuSkB33V7A8rXVFX6b7klZ2SJSmY IkjagJ3lIQX0O3Rrq/UAo1TXXZOSGknIpzQDmGnziQcDcIw6hlh68XNQWZ69Lmw+Xu8JXC1B8X2W wocX00HThQ52wEPZD1U4NHSsJ95ZqH1n0y2TVO1GZXCzMvDS/OtPxHyEJllRW2cRxH8gUbQ+5aU8 u9BpijfVlbpQISCUGDIaT8YfPECGHrMtm2iHFjtBf5hYj3kxFlVm3QZefJvllPWmGIYnggXZIS+H nqBtk9okh06V8bV5B/MB1VlzYzBLJajOCpqdBLSs11pgdY72/nlxYjgXblmj2Ka90RaUqro0BrR3 3GalvBilurYy6hSZGId2Ws5k44Wf87aDxQWeoueGBJ06k9T8sJ/wDcjpYM8EfzPQLE3ckndQCIJg 2kXgwKjcA+Hd5Vw9OHS3TNL4THF3FnYfWjlXJ+swvp/0yhoKMm8+inyCcMvDG8yWyiPNUtHedLcs t7AORyLh4CW0RvNk/4fx8jLLayokW7nesoSgguDAUvw4woSR0q2xg9YX1sGWu/Zig7TX2gY/rcY9 YZ53nqQPa5KGuVgfeR52cyepjwhUf9zstW72PAVoQe3ciy0oDq+h7mnpLbsCDhlhS9bMiynMMmcW EqT/Her+UD7luTkefUxSUQv2DW9vqsPJIQMI8gK2kZ45lpynB9TBH6eop91GaXV+hB5/dS7DeHnt zVlh2KJPL2qpPF1BYJ4zjIHiaDUtyMQKzioKNNn418tLds5HbWehF4u9Kd95mtcbztN8FXskr1Hr xRS0Zkcu++tN7np5nbTgLQ7zaH6BFeN9lrC3/GwEADjz87SrOa3Dix84j21aKc3C6zM15wl6SwTH 6cd7fZNd1lJeaul5mm3o8c9Ji9jNKTwJpftbUEDgb8Exx5jm/ePRDSa2EbJq87x1UEIMVeRZN2gv w4Hk8X4cqqc3nQKTdBUvmiS5uR5gKN3ATwr6MDGFshtUQdA7/o3Uks4yQeu64Boy7pFTjeLwfg1x 73I0ZO5b6aEWOtP7zXy8MoAmAWZ6QaLgOJWrR3qr6lPqUveFmvJZirdHlVjyxtZs1exXuTmVfoEh AMCd9oUAgBinJQIiYJWAYIVwUdn3ogxLVbvvQx4IP3DE+BrCe6v4K2cX2m2g1nJitQcAt+69CaC5 e5u73QN8ptPCGHBrumLU8ioD4IGDAmK8LBUIAN+vFqwQLir7fpRhOsIzDHYfgkUsAiIg8vpqlGG2 Rc/Q4dI+0+JqcJ5C8Qxn8S6xTwoAZnymYdUpf6SAh+n3QXMNTkudyWBWfRJAsEK4AWVYRM9wc4AU 9Lj5hK0DoTcGxN5QdKHaEaPzhbTjlgCR16dThuUWPcNgEIuACIi8vhplWEfPMAJWBVhxOdVH10Pk 9emUYbNJz3B8NRnvWpokZwiox+TdMGBT5VQfqK+Y/NCVYaWjZxgBqwKseLOjMgxbGaZb9AwF1eQU /BzuGYK/BV4MuJvQNQf3TYADBm2F9CN4G6qJKS+goHdpeZvrALXcqZU4k5QLwyVuHmX4pvpQvSrD 3KdnCLGmBnItr7sdop+3zAarpSNgesvHP6JNOUW9BYwLndz0I1vyDINZsXk9w2KLnqEgZ5jCEzFn ONZqCdy8mDMMUhmuCOBTGVYxZxgBqwKseLOjMgxbGdZb9AwlOUMgTpAzhGye6TxBLIEHa2ligWcE 5/H70JeGMIinTHnktKUjGFEZBq0MaxU9wwhYFSD2GQaxDaEAfCpDvUXPMBjEIiACIq+vRhlmm/QM BU3XEMFt+UUNb+xscijb8MbrR8Erwzx6hhEQAesBRF6fThmWW/QMJQWU+AovAnhTHT3hAoIVwg0o w2qEZxhs6npDr/13eP2W+URKj7VIWv15mRsQA8CmY++FAMEK4aKy76YMy0Sra6ow1Xtd2KTl5ar3 7kzqXIPSFI/zExnc5wLXyHSM27vPJTWfgGlz44m8Ix9uQoXbnYC1e9fDwRgUseN9gWfyj29/rezr oczLanCBAHW4hgsuvDE/kpmIZeZVb8f+nSFM+b4AYoB6p3F794N9MhnGBDgssgmAaRVg+sHcbG3O Ah+xLLKPa+uaMr0c9Lbbqc0b5vBqSHr1tsP9mvRWaIdb6vjtqvzONciY8mvJ+N2AXu7lSgt1ubmC S0v5TdKwyvySQsEFnB7YELmOsxBnVA/3qjvwJSwhOIagxzMfLHS4JrppDOPQQ6w01iPzopW0auet lCp8qqV5LkUHVqaX4Qkumucc4/Gq8W1ex4v8AWklet2ol5tBBTwGOgdWffxVoRK9RZWh5LbVePX4 NXbwo1BTu9DBonq4CdN2w/WtxBT5BTE+rorF9gvBJaY+RHm8GPpQ5OsXkAFqcQmpm++wc6MudR3y r6o2Grb5V+nHKf2r4kSMB//qbfHUPAp0Ux7HQmHgQm6/B5uEDAODUlpwllA3aoP6w4+WLl+twyR2 zOaj+WVlXHbIzszD/RwxHp8KwvMYfI8lTsBjILjjczHIloIwQBDj+lhTjw5p/TooOqSTJvyaDST8 juUg3RsVmJvv7ngNIglpwVxyXwB0jI+CiEDIAHXQyuagXD2GkrwVKIxpXLJQ92Wh6MuWIvai/LQe Ibhh5aJupb+qL+ifJJpYs7fUs+ynNb4vmuMXrLb5b08PP+9U8meSJj+1/31Lfvm1BX7tb9jAYK8N OVd3LtdFclfmpzN82vQOjjx1XqCjQ6GVuUKNSS60YPSe0OYqF1f5UEqWrpuLwvlSZOmeeLXfyUtL nC4PWB5/fPkxIHVqaPcfk8fd/wGJsHYCZW5kc3RyZWFtCmVuZG9iagoyMDIgMCBvYmoKMzQ1OQpl bmRvYmoKMjA2IDAgb2JqCls3IC9YWVogNDcuNTE5OTk5OSAgCjQyOS42Nzk5OTkgIDBdCmVuZG9i agoyMDcgMCBvYmoKWzcgL1hZWiA0Ny41MTk5OTk5ICAKMzA2Ljc5OTk5OSAgMF0KZW5kb2JqCjIw OCAwIG9iagpbNyAvWFlaIDQ3LjUxOTk5OTkgIAoxMTYuNzE5OTk5ICAwXQplbmRvYmoKMjA5IDAg b2JqCls3IC9YWVogNDcuNTE5OTk5OSAgCjU2Ny45MTk5OTkgIDBdCmVuZG9iagoyMTAgMCBvYmoK WzcgL1hZWiA0Ny41MTk5OTk5ICAKMjc2LjA3OTk5OSAgMF0KZW5kb2JqCjIxMSAwIG9iagpbNyAv WFlaIDQ3LjUxOTk5OTkgIAo1OTguNjM5OTk5ICAwXQplbmRvYmoKMjEyIDAgb2JqCls3IC9YWVog NDcuNTE5OTk5OSAgCjM5OS45MTk5OTkgIDBdCmVuZG9iagoyMTMgMCBvYmoKWzcgL1hZWiA0Ny41 MTk5OTk5ICAKODYuOTU5OTk5OSAgMF0KZW5kb2JqCjIxNCAwIG9iago8PAovVHlwZSAvQW5ub3QK L1N1YnR5cGUgL0xpbmsKL1JlY3QgWzQ1MS42ODAwMDAgIDYwOS4xOTk5OTkgIDUwMy41MTk5OTkg IDYxOS43NTk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIj MmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1s Lmh0bWwjMjNhY2Nlc3MjMmRyZXNvdXJjZQo+PgplbmRvYmoKMjE1IDAgb2JqCjw8Ci9UeXBlIC9B bm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbNTIyLjcyMDAwMCAgNTY0LjA3OTk5OSAgNTQzLjg0 MDAwMCAgNTcxLjc1OTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMy ZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYy Lmh0bWwuaHRtbCMyM3RvYwo+PgplbmRvYmoKMjE2IDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3Vi dHlwZSAvTGluawovUmVjdCBbMjYwLjYzOTk5OSAgNTA4LjM5OTk5OSAgMzE5LjE5OTk5OSAgNTE4 Ljk1OTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRt cCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRt bCMyM1JGQzUyNDYKPj4KZW5kb2JqCjIxNyAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUg L0xpbmsKL1JlY3QgWzEyNC4zMTk5OTkgIDQ4NS4zNTk5OTkgIDE4Mi44Nzk5OTkgIDQ5NS45MTk5 OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZD R0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjNS RkMyMjQ2Cj4+CmVuZG9iagoyMTggMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5r Ci9SZWN0IFs1MjIuNzIwMDAwICAzOTYuMDc5OTk5ICA1NDMuODQwMDAwICA0MDMuNzU5OTk5IF0K L0JvcmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVt cDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzdG9jCj4+ CmVuZG9iagoyMTkgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFs1 MjIuNzIwMDAwICAyNzIuMjM5OTk5ICA1NDMuODQwMDAwICAyNzkuOTE5OTk5IF0KL0JvcmRlciBb MCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRp ciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzdG9jCj4+CmVuZG9iagoy MjAgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFs1MjIuNzIwMDAw ICA4My4xMTk5OTk5ICA1NDMuODQwMDAwICA5MC43OTk5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9E ZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0 IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzdG9jCj4+CmVuZG9iagoyMDUgMCBvYmoK PDwKL1R5cGUgL1BhZ2UKL1BhcmVudCAyIDAgUgovQ29udGVudHMgMjIxIDAgUgovUmVzb3VyY2Vz IDIyMyAwIFIKL0Fubm90cyAyMjQgMCBSCi9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCj4+CmVuZG9i agoyMjMgMCBvYmoKPDwKL0NvbG9yU3BhY2UgPDwKL1BDU3AgNCAwIFIKL0NTcCAvRGV2aWNlUkdC Ci9DU3BnIC9EZXZpY2VHcmF5Cj4+Ci9FeHRHU3RhdGUgPDwKL0dTYSAzIDAgUgo+PgovUGF0dGVy biA8PAo+PgovRm9udCA8PAovRjYgNiAwIFIKL0YxMCAxMCAwIFIKL0Y5IDkgMCBSCj4+Ci9YT2Jq ZWN0IDw8Cj4+Cj4+CmVuZG9iagoyMjQgMCBvYmoKWyAyMTQgMCBSIDIxNSAwIFIgMjE2IDAgUiAy MTcgMCBSIDIxOCAwIFIgMjE5IDAgUiAyMjAgMCBSIF0KZW5kb2JqCjIyMSAwIG9iago8PAovTGVu Z3RoIDIyMiAwIFIKL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtCnic7V1Lj+O4Eb77V+gc YHpEinoBQYCZ3p0AOQQYTAM5LHIIZrMJFt2LdPaQvx9Zkt0SP9MfSRcl2e0e7I6bY5HFYrHeVfr4 52//yP71e/bx8dt/su/j34/fdvlDXrbDT5Z3fz5MB3TzUOh8/5M1qnio6n70+8vuNXvdfd197f7/ ulNV/+D4V/ePhyXy/s/v33/bfRwW3w0j3x7/2n36X6azv3T//Zr99Pdu8Odxvv0XXnZNW3Vw5Lkq ul+fp78q3Zr8oek+d+O5/ev+y//e/e0P2W97wPT+H/aPDQBOf/3QqtxUD2Y/5SUgv749+lDlRatV WTXOz9OJi2KEx2RFU5Xdt/K87LZemOFz90vR1E0H4v5jh4NKmf0vStvjun7Q4/hxnmfH/Hv0/DKB uS3GH+fnGcxT2Fq1X3aAebJWm5uH/ARs8/HJXo7zPDvmt2EWwrMDZhcMrnNJgefTZ/0yG/fD82na cNGSEJ6rqmr6z+2cnrth1X9u5zBY40eYJ/M8O+YXo+eqantwBpgna9V5Dw7ANh+f7OU4z7Nj/kR4 dsDsgsF1LinwfPqsZ/TsiefTtOGiJSE8N7Vu93N2smJGz01tdL9sMYfBGj/CPJnn2TG/GD03dVn2 yxZz2mjqDm/5Kdhm45O9HOd5dsyfCM8OmF0wuM4lBZ5Pn/XLfNwLz6dpw0VLQnhWahRsak7PSo3C Q81hsMaPME/meXbML0bPHQyqGhS9l/la7Yg4G7bZ+HQvh3meHfMnwrMDZhcMrnNJgefTZ/1ijfvg +TRtuGhpDvPB7GhBCQ/S5Stjsu7SVJ31kqky++8/u0W+9qp6hEGg+j9TWIYRh0HweubBz0+7j1+q TOXZ0y/ZAMGH4a+nAegPtSnq7Onn7I97mP6UPf2625s/44DuB+q3gaIfaN4GjP2NYY4fn8btp8F0 ZcorxHRVVleH6Sa/Rppu1NXRdJOXxfVhuiMPkwjTke6R1zMP9vvpdtMh7NSGqo5ylC5HWIq8h6U8 Aqcf+wGVH0eKCbjx66q8X9hYSKhtRDYUkeZt4EcLeHhENfYqP9iT1vaAPan6wfOEzZll4RF7FZ0H PwLL4hyPNj5qm3y/WAOqtZe158ibcKzDycEcEacPm7MPip8cQBoDuk1SqqTLKmtAK3sVvlt7Djw5 mAMOW7Nlk5AU322SC7QQWVKmVMCNAh7EQQdIP0lw6UE6lG7p8MXei6RwqI+zfu5nbUN4zufg08bd Vday4+7OsFyJa+kvg88BwmWhjSGkZc7qYVmbdGH/OAfwB+Agd3FBcAqrAI+xJ8XTt48hRpv6ROXH 52CRI3HYeLZUSnlgnd4GOEqcA07fWDxHUErJcOXmIA3uN+jyGxSuCuEqnAwByYAg4MHh4pOfi4da Fy7Xufg0ORWfHmiHzUSwJTAl7cuO58AVXwkCGSZVk2fgbvM7xSmEKkdJsIzbBRqCRzgcsH3gdfyR Vo4t6/wSub2IF+T6LSGt3JaQfT8kLSFdHGcFSwg4BhgcESd1168DeawHYPSgVvKtLOPkeF+eV44P xDrfPtxsCYm7ETpNeZFleLAp/emB6xPwDUEpVR2lhbcqLIOi+ogigWjOSjb7SlpKxF1GjMFuAQ4w ON6V2FaV/chjONbhsMPlZ4xTFLDOnbOckwOkgDFqoXpsfxH1MuZcOFcGFFLZx48BSVuSB7drqz4C ERAPA51zWIlLF35hFtKmwWsegaCIvUgwZRojuGbl4YakhYtNpfbwRHjR0X0ZjsPxfogw4SJ3xkg8 LEMjAkihZoCA6oN8mnNQbrRF0Mz1hveQhmx10iPGniSxZ51juEGdbHuuJSQpAJ17X0A88OvhiPVL OCwKfRQPtsNCDfhI5LAoCkmHxZ38FyD/a9aw1klA3IoqHCHH3lkC8y2bfVqSbZeiytJGsqAjgox4 uBGe6Luf+VLa5ilIaZR60AQl5DylZBywrZ6I6oU0NHbLDBVTwEUU8lLvGWzdHFZZJPMeEu05BWFO vMczdrXCMmU2kBrkcR18vUTnEhSpYowHw4XUIrlDyNhBFnBmGI4xkVz08Mwg3C3dCzfgcS9b8RFz vyMgiFKhB8FwOxo8pBH+TxpBkvHuVjqfsekp738r1B4aynU/zs+zAmOP7/Py48BF+222+/rvE7vU e2XfmMMmNRyQHUrSP7Jv4Ik5ok8TWfTFGkCflEsBnH4F2NFAodXbtA4hAFentalrncrxXlMwdXvY 8rAfpQIYP1fyRFxGtm+v+GQPgJYjkfAJpXACAZaYDJa7zAqUWQvlzIIgBMU5vE7B4xHAR7g/zMMh wmtfqPIZoVyg4c396RvZC8zhUePrq8BeahM2asbqJRiqR+mTw/EgYeCa1jhPm9piHizXPhgRMcZj EjwPwqPVwk0nCnCqi7A1wrPVEKdc8nPAQH6AExqwDgkLEqk0aXICJWqpBaKaqILQwg2eM+tiKRfz OsbsQEcFpktVdNwunDawFN7ygacZR6csnNPrbEdkLpIV1sucMm+de4nQHiWkwXZdYsCnw+9URDav h+IvoPpsRVnWsCzcDwdXvvA6FE0+vw9Cs5r5rBEmu4SKgdcOjobXLEeEsni4NFxwr0SqMVoqTwMC nMLhhrumx0dE5IN2i2mOdWqTeGQkIOVyJhvhwrpiRVbCOEqjHfOzw9oVGOD7j2jYwXGYJgO+KNvZ rRKxyriTIryi0MMFwfVlqnPjI1yUgfIX7k3z4DIe1z1JxUeaeGd4eZNLhRQRKkXrpLLNap2OFk8X 4kPnxQwhIjGeaIXx0s2YaraZNFqniLssnEMuoyFEqC6bVYdFVIhoj3xxZtLwEBYieStZSaC48DYf XKPwbRUhIg1K48QpF5fc8ReRlLWO8xCZgVzyZNnoAyVDs9Pb1n24vDTDI9MkEdvjauAFCpzZAV8C QCJaUYJrnIfnuXocESqxOQY3SpbJA/fgsfxyUxKSQLL6ZA9w84lqCx6VmtuKJZ11FnDIuLMMSIjX ryA/dLCQizMYihln9lAHwnuf+wRcYEBQuLe1/+4ADt514WrI+wa6UJxWTG4ss7eqDgTLM3uLCD8L JIdpUD7sXF9M/h2E7blcX93AtHDuEFaG1F47G9h1mc4xJN984cnA4wnqAuaTMoG4aps57s+JnHue 6nwODwmUpI838FOYlMeJuPEAAQzufRHIwZbIiThRIQDEbQ8ouzgtJgbMTYOIOHIKyzDiPQce5A8e LM5BuJ6bxJW0Uk+GiPiN724lVNh6/28OfnnvpTJbVqSV0DLsIknxxFYbjsckodKTK1qbTlNUH+H2 bb8Jhq4lWuuEl8tHxD8WerNItHs/JG9xpcC1T4Uf982niYdW2pIfi4ot3bh2h5oxUKpITIDzg3B1 6l44mECwUyXFo62JhPxcxzAS0Z2TGFcG1gW65BF0zts51fGDocYEHgwVSyIpBuF1cYJC+OIIgZlx ch9nfrgFIvPGr0HoGKettNmEQp7awRtDrcX9bkk55q3WgHBjtBSuHUg4WyKy9q7XkSaStBje4s1D S4moAU7SvDFRALmY81yPGxPu4PbIa4ugXAEO4krZF5FjZeNND/fs8nCHgwdgXBm43SB0o/3bS40i P8RngipQbU8KMWieeAnBYjvQq2FSOsfo+p4QHxSy2vHlsbEhCNYzvGbUiVYMODflsQBgAH9qSEKc PiLqACQAV9S34GH1NGqJZsEeQZeIGNz7Cg/xLrXcq+jRP5ciBJMHwosIIm6Qh7LJmxRDDiinfu5V 5E2KI5xGG0mjE+k+xhVYub4eEtpoUx8qJE64GcONoIgobYwn7mrYdIyFRw1+XtgcU6W7To5TmrLd dyYuPLLgBHzXK7Xfj3H/c6PYAzKBZGYP3ibgAUv0ar9BPjStE1Ka6CHSV/Qecg0kBw8Ecc81z5qN EDERjrgInQwkLAQ/IrKc+Ps7BErHPZQUyth5EEYk4Zf3IgSJA/Gj6y3JXSrLpyyqOQ9+Z+7flJZP q47VOFC2HPFSh3WqVu8SdgEJ63HbeUZCClcjYowbMVspHuR+outR8z3UFv7CI065Am8qk6iQQKrj TXV9AbuUsfct0N44O0LG/TEJvaIiYqs41HRj73/aaQqVQxrQW6tyh3IQ3AuXY+ENGxYS0u8rvLNS 9Q/VHjjb3kpnbw+S4s5ZUFl565EIk02EsZu6nPE+j0aVoKJSfUKiDa3rLZVhZSYRTmFe7JWiTs11 lUUknam9j24zqqBHJ+dFBKqHjopWP88S5j1hfJvdXha+QOpOohxLdBncqqm8mpJuchN6uwHtdP+o HfIcAoGMXlyWJx9ypxfn3NxVsCoZioiDSjt3e9eWn6S1ZZFUhq0Wra+F04iaVJ50EJFEHx2Zu/iV JdX8Jl9NCMgDDsHQRHucNEmPqGvOl1nkbdpcnRDJhEyRDLRQtx4aAfFgOjTjLEZHWacsJU1/Tepo 59XUHi8B4WS5SOJbTLP1hM57AT7e5HnppORw1Qhpnaus4Sl7EU3nYpJ0+LlI9ACR0GHXyYuVaD7u IaOo6oxUCMtKvD84RZE3V5Vi0tdTRENjCkAgJQnqPTj/4Lm3idKa8nbGHa/HDFj+5Qy3VX7a5PXh 0D16INN4tkf56TAwDa7YtaN4HnZlqEjnYXtSLCYF2HMKOy7DVSJef3uFfZUblVcHaLnNzLk6z3/m 9WQRejSEZKmQN8aaA185UgwcaFLZhe/stXEG0/LAViJIMF6q7UlOFDan2M/ISyZX2O6yZQAQ3DFk m/Jp9aM9icR2APUnKgDt+nB8dZ89sF3ItkNIPvvzoCTYoT+dSFi3Sqv1NyijkCpVzza0YRajoWUD QIZ8F0dgXtwyInshxhTz0qyIdSW8A7Asnga2YrQJByTCibuBBEkZIMImEY+6lxM8Xeor5q5yXrIl 3NPqzeAr2/EHWKj9bx7Wo3uynh9XzjTufRSsqK1ORa19ttCqZ7K54epW9slNUAiaZ2MP2Ll8+nRd bew2i+EFvfmhumvke9CiaMpMgPsbYNI2bsAOGe3KyYD9DaNFN6r0/OW9MhvF+uPLNtr9yV677aqq h3v86/tLrEH7Nfu6+z+HJVnjZW5kc3RyZWFtCmVuZG9iagoyMjIgMCBvYmoKMzc5NAplbmRvYmoK MjI2IDAgb2JqCls4IC9YWVogNDcuNTE5OTk5OSAgCjY3MC42Mzk5OTkgIDBdCmVuZG9iagoyMjcg MCBvYmoKWzggL1hZWiA0Ny41MTk5OTk5ICAKNDAxLjgzOTk5OSAgMF0KZW5kb2JqCjIyOCAwIG9i agpbOCAvWFlaIDQ3LjUxOTk5OTkgIAo2NDAuODc5OTk5ICAwXQplbmRvYmoKMjI5IDAgb2JqCls4 IC9YWVogNDcuNTE5OTk5OSAgCjM3Mi4wNzk5OTkgIDBdCmVuZG9iagoyMzAgMCBvYmoKPDwKL1R5 cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFsyMDIuMDc5OTk5ICA4MDMuMTIwMDAwICAy NjAuNjM5OTk5ICA4MTMuNjc5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJm IzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRo IzJkdjIuaHRtbC5odG1sIzIzUkZDMjExOQo+PgplbmRvYmoKMjMxIDAgb2JqCjw8Ci9UeXBlIC9B bm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbNDQ3LjgzOTk5OSAgNzgyICA1MDYuMzk5OTk5ICA3 OTIuNTU5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJm dG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5o dG1sIzIzUkZDNTIzNAo+PgplbmRvYmoKMjMyIDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlw ZSAvTGluawovUmVjdCBbNjcuNjc5OTk5OSAgNzU4Ljk1OTk5OSAgMTI2LjIzOTk5OSAgNzY5LjUx OTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMy ZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMy M1JGQzM5ODYKPj4KZW5kb2JqCjIzMyAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xp bmsKL1JlY3QgWzQzOS4xOTk5OTkgIDczNy44Mzk5OTkgIDQ5Ny43NTk5OTkgIDc0OC4zOTk5OTkg XQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0 ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjNSRkM0 OTQ5Cj4+CmVuZG9iagoyMzQgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9S ZWN0IFs1MjIuNzIwMDAwICA2MzcuMDM5OTk5ICA1NDMuODQwMDAwICA2NDQuNzE5OTk5IF0KL0Jv cmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUw Mzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzdG9jCj4+CmVu ZG9iagoyMzUgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFszMTUu MzYwMDAwICA0NTguNDc5OTk5ICAzNzcuNzU5OTk5ICA0NjkuMDM5OTk5IF0KL0JvcmRlciBbMCAw IDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMy ZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzY2xpZW50IzJkdHlwZXMKPj4K ZW5kb2JqCjIzNiAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzM2 OC4xNTk5OTkgIDQ0Ni45NTk5OTkgIDQ0MS4xMTk5OTkgIDQ1Ny41MTk5OTkgXQovQm9yZGVyIFsw IDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGly IzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjNyZWRpcmVjdCMyZHVyaQo+ PgplbmRvYmoKMjM3IDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBb NTIyLjcyMDAwMCAgMzY4LjIzOTk5OSAgNTQzLjg0MDAwMCAgMzc1LjkxOTk5OSBdCi9Cb3JkZXIg WzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5k aXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMyM3RvYwo+PgplbmRvYmoK MjI1IDAgb2JqCjw8Ci9UeXBlIC9QYWdlCi9QYXJlbnQgMiAwIFIKL0NvbnRlbnRzIDIzOCAwIFIK L1Jlc291cmNlcyAyNDAgMCBSCi9Bbm5vdHMgMjQxIDAgUgovTWVkaWFCb3ggWzAgMCA1OTUgODQy XQo+PgplbmRvYmoKMjQwIDAgb2JqCjw8Ci9Db2xvclNwYWNlIDw8Ci9QQ1NwIDQgMCBSCi9DU3Ag L0RldmljZVJHQgovQ1NwZyAvRGV2aWNlR3JheQo+PgovRXh0R1N0YXRlIDw8Ci9HU2EgMyAwIFIK Pj4KL1BhdHRlcm4gPDwKPj4KL0ZvbnQgPDwKL0Y2IDYgMCBSCi9GMTAgMTAgMCBSCi9GOSA5IDAg Ugo+PgovWE9iamVjdCA8PAo+Pgo+PgplbmRvYmoKMjQxIDAgb2JqClsgMjMwIDAgUiAyMzEgMCBS IDIzMiAwIFIgMjMzIDAgUiAyMzQgMCBSIDIzNSAwIFIgMjM2IDAgUiAyMzcgMCBSIF0KZW5kb2Jq CjIzOCAwIG9iago8PAovTGVuZ3RoIDIzOSAwIFIKL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3Ry ZWFtCnic7V1Ljxu5Eb7rV+i8gMfNfrC7gSCAPfYGyCGAYQM5LHIIZrNZLDyLTPaQv59+SJpufqI+ dqnYD41s7FrDUbOLxWK9q/j+L1//uf/3H/v3j1//s386/Pv4dZc8JEXd/9knzd93w4G0esjSpP2z r0z2YMtu9Ol597J/2X3ZfWn+/7Iztnvw8E/zy+Mrku7vH0+/7973L9/1I18f/9Z8+t8+3f+1+e+3 /U//aAZ/PszXfuF5V9W2gSNJTNb8+H34o8mSwnafm/HE/bH98q+7v/+w/70FLH2oOuBND+Dwx3cm yeqqfEibn64B+eX10QfbTJmawlbez8OJs+wAT75PrU0f8uZj1iw9y4vmieZP0YyXxUPajTc4sCZv v2RSdzxtl9GPn+b57pm/Rc8vA5jr7PDH+3kE8xC2qnrop38evatMku5z7sA2Hh+s5TTPd8/8LsxK ePbA7IPBty8x8Hx+r59H42F4Pk8bPlpSwnNp8u5dJhnTc2mK7l0mGcPgjJ9gHszz3TO/Gj2XxnZ7 3cM8fFfV4RNhG40P1nKa57tn/kh49sDsg8G3LzHwfH6vn8fjQXg+Txs+WhrDfBRrNTD5SbLC5vm+ yvKskY57U+z/+6/mJV86USAQOKb7O4SlH/EInJcLD378tnv/o903C//2y76H4F3/z7ce6HdVVuT7 bz/v/9TC9Of9t992rXg9DKTdQPk6kHUD1etA7n6jn+Pzt8Py42Da1lvEdJnEwrRQVXm58GC3HtMq U+cWVKTNekxmj7D86KzHGBf8qhsoLizws/MN85F9A+egbzH1ebzmrwOP7iOVi/n8FfNyFJrcjnCI kAHsLiDmkwsZYAg2xtK3cAzx3VbBUJbkYyr7oDFrT7rWOYoDHKbuYmC5HoLIL+wU0DKgHfYSXpvS fYA5XFrGA+LOkXxyAfNs7gCOkp4YSso4KUAK++JhkYM5emKv/ZCm7qSmn9RkF2Cfztv4mUo/uaAC G3I31xQuDuk+mA8OpFm/fpNcIBl3VmQysBiAzCUqZPaId3fWLHHf624vIBGXB6Blhq0G9xtWAwQw z7mDR4BDqPBhm+ZjlqnIh8vat5lwZvAQAQ41sAznrnS5LAw8OjSVmvP7oMzd4BzC+Xch5ZNmP8KJ yV2e+dFdv8tV4BFkiECpVB3kfBjFH8fhdNnOtR/k1LAPsFNc+aMiBHEKKATq93HdazW3qhgdbqQq PHdc3dEQIgGkCRQA76USUUCJeKo4SXBFZLoOGXAQqWCWMJFsYM5eYVSldUt4dQRRlabpEXZQKznO uIYQalRdsDICjAquzFGhCuIO+H8A7waOyDUmgaEqcDoACwmQCAA7d1RwUIHrwPZTUz7AUgPZRbkO ogwQxNcCgkjP6aCrZAWcMUAhfQTfwnk9N/4BH+v17Fgz5qiabDorj5Nyzw6X/YKDG4fHLKN1cksG uRCIGMBQDAYqsdJhDsAYYB01TG6EaggudzF8Y/KcqhzwFqqlcCcUvNYH6bUmRp2MTnvAcjlhcgYh ULlnccoGo30SgQgwRo00RFCyJIJUZE6R+t4SYAlyW2GeSIALmAZJIRx0owIWF8My5n4/gWUUB4Xc uloGQbOx/jS5fOgkrkJQ0sDKhRDeWtj2POdjHmIHRdiFAyN2MXCqAUcAy+XemBhMGeHgkQRq40eV r9ar5aVUeQhQ6uG8zCIsEVLujKF7i/jg+gZVL/hR1zTg6+IwaUDUgEe4MAbObW1uOXJHEsiT/i31 BbQL/EYCo5cqCxLKpTHSOM45niHG8QEymqusdHEIGPdwAE55JorA9xRAQgJABD5yAbOT8HqQsAqg S7xT1B6TnH4N3/T0HIoAETOQBq8JwH3RUPPH+3mUuBrwfZ7WOvGlnXiq27ziM9IpbfM1M3uUTgnQ 6wfKNz0UbczrSOE+89kd8GxyfWEL4b2V+170/GburC4ghmtJPdXb10cS+ggs99GBwyye95zVx4xU zNrjcRvuIBNkrdBsCoF9H+CHcl8LRtFNi/150rwC4jo0hyPA3ufZZcAhBInSgmAZT7ammnXANkRJ 0Ltlf7pAGwHQJcYqF7LTw746bsmiMiPhEKLAc624UgGtFVt5I+6DyY5zVJpKzw8ZnlzOUoBNzyNy 7kz4zoTvTDgcyQITmVemuW7IgGCiINViLnFRFCOmHFDdB8ulVWXympFJGPLwHBWplVovgm6oqG6m RCueyws4nY4PQcWMwMRFvsUNNs7qAA7uUoM6JUiHnl4fGcByY5Rc83yvOFIrivJAdWuEo8fHsBrS NSbyfmDgOcs+nKflK5lfXlUj7jeTKkgpIg4BqNT66MUg81NPDKj1uCnFf6HdBqUMdnt6lEYj/5dj PePWBCBI4N+Ft3AUTn9tAG+/aaHDy2dAWwI5BY/ws39L7gmFoG7w8lX4uq19oN/dAuPXRvHNZp9c 7UmScs9XBwq3a9WgmcP3UqGuA3hOgCF094GtktgDgn83rcNxLwCXfNPLhH3n5dp6xKQcSwcPQlRk UJX73qKRZ4g7pRiGuqR/CxIduLOFkz+ADiyW5//CW/i51Mh8UMi6jqOSAfWDqky3QZCislA2yUJG X4CysIxSL8iuCYhDTC9yE/gAsEOYJzNxkAkHBKPoRarrK8ghikGvIPklzV0CohsLWbCCgAiwB+gg R+0gQYM8LiwzmJRncqNhRAsq7oovw7KG64nLdTgwPFws2X6BsiTod8A1Hw1tweNWvTrvqxgx+4C0 fDBroOJKTwoVJg/eS+5JkWyugLdNTznAABGNy0qqdLi8gOjvQlinBSaSKPQsmQ4Cgrk71uYQfcsk lwmsC514sljkXMu2bTHi2zF1YxUJk55EH7ViBFluAhoKOP2LahyxvUIKzgbkU9yzxDvQAeEq6jnF sUlAnCjTWnKx56HLeezxm66gCuiuRzkbQqrhewOXTj/HIMkJE+HcPChIe8OBQdw+pFDTYKGmSZN9 1dbVPB8/pg8myQu7N6buP9XtaNb8XPUfnppzbx+qusiz5PgrO37S9nN232w+lnX/9f3owbI+zNl8 aL85eF37qzQZPXmE82n36+7jD7GqT03WVhi19qZPmMbIiJ5Hld6wA1BgewmYxVu7/ac9q0NiH/YT uoqd1PbETuryHDupq8PRbz447KT7lR0/afs5j+ykzs+xkzo/zpm77KT9VQ9NPmIn3Zzx2YlN/JRO Iz8owaY3I+MUhoeUn6e1FuzddqBH0gjmzhsnn9wiq0cnV7HZ2NX81ZqTumbNOXXNmoO61n4Y89f+ V3b8pO3nPPBXm5xT15rRw5yJq651v0qT0ZNHOGfhr6YIpo4oPbwltMBVvllylwIwpuLpm+e6rtUm mtyd5/F3fyHn+XpSYg7cMPNzIZqkHRCdnvMGzCsRknbXm74iRKUTX0CmDS1iQX5AfePcjxkA2Dxq Xow2zgGLo448PHb0BqCQ6ylcGsLXCBJ8YnD/gIQWoAe+l1zVEVwaOL2HQkBaFY+3lIpsOC+8KOPR Ncwjcg+mLyfuFltClia8JWQKRuZ2mkYm7iNAsilM6mnhsmDzxjI/VdT3WLsU5JBopAKxpnG3F3e8 8GpWfuXcdp30gCBJx5XpTXsl1RZRSoa54cglNOAD6FThzpSA1XLFaMN3P/FIGSc6wbWf4tK7S5bF nD3gNHJISms0KejunLjMYdA5AWsB9Yi6L26Jj4W4KgUtORTuHo4S8n9bl4Np2JXzaAKzqn1Xh8by ESPfzvVp3IjOVCSd7YzWqvYiaGun8FqPSNIipErmbfklSGHgHnNJNXwUd9dq5NZKisy3f8jeqqjb jriIGfuDfblWSpfFiOeuuMTlIB5M7QNEpao65JKt6b324nifePHALB6KtVixcdwenO0IKuS5f0qD pDQie7xYVcNNuLW89Wu5bp6MWNmGhR3YRjrXzR6YfeZv0SXQILajti/Et1fSvXRDQQKNdMR5KmC3 3ONOJe+tc7dU+YnnwuGHfRB0sPukyPzs2hwhgrzpDfHcu6uEyc+7q2QiTd1dJc7ub9pVUo258jza ks4NTgeJUtY+QLBnnUDj5BqWgt4yU0hU0DOA65Ncbk2/oWi9ZSUCzwkoqdSqUUkbdh1HPM0vgCvT ZmKSKzSnF21K+oFzPY/7vKZfRhZM2lf7vLMRM+T1Hpyz+fyXOny7zr1Y3VqtzpQCQYnHe3pRTUC6 KW+8DBxkugsc2yLOk/a6XZLy+R41yq+vY48bNoPndD3qMPJ6M8HLOlG99mi7Pk+uPAd07NtM9fya vaJdunWdHVv2wT2ba4/E6RanaNTCom7oolBD4ZQoXLwL4k1X3tz7HlzeKI2kjKyeTmNR6vJ46kcM E2ZZ/UpFFDT/v6soYRJ5uqUgCbotVJ+vYX5QLzO//jGgJ78g0YF3AZjeETZgKwXsYqGWuRsOKfE6 NLGOe3VJjNHnsOtSQFREkC29mztPOWRAG2boWYBdGqERc/oI08CrU/4mpF9BLoOhAT9B8CEg5sFz tDWkuUSsgqnDg1HTbdI3Zk4ruijqU3MXaA6yEoyFnDpeuy+4kuy2CiEUQpwBNqbgRghB51rOMQTh fC4U+eFW0EQl19oF2GEKiYsBYSDuf50enI9Tf6JB23CTAOw2V5KWqpWwSTVi/ysO8rSCqm7Ua00J GsMtEccHpZBiKUg55RwVU9soe4yZhfhmxdZCSlkMphxgK0Th9LeUka3jUUnzEcudx2EQM1NHRQSl XmG5GqUtjr+dH6GIVT+TrLpbTilbL9VJroiHq1WilH3cg9Px+baSzLEOj4XzAGjnOSOAEECZR8NQ kRe5/xQuc/NUgCOZZqkGUD/XHqffajJPIcCsxUeTPCsCBC16gC4BtpLTgLYlvY4G3xKjAf9CHVd4 i37UhLjuGNq25OreH2OWq1gjqiILiuKKfdBwT8RQOG76fuMFw9WruYt7Hgf/au2amaJo3DakZS2S 876Wg6cWza6TKjtOypORBGnbkJgR4z7q1WRq8ht7BInuQHScYBYqHlCIsXPFFo0WgXtOQ8ZSiyyg 0Jj62jQ6FywV8JhutAScbJ4u4lKyXo/s2hjj3ajp5b2bK3jVKD2sTXq6bonnT71FLF9ay3QJ/CaD eYvzPmR1XGpFab8VpZmvwqmcyc/Ogyo5pdMb6g2j2MOpNrn3ZqSl2vtuxlEyT9U5rhbdMa7Rl/cD g6skwRuDkEzvFaVx0bvAO4NyiztjNNpLcQtFkPao0B5EwPw1NhuyAQR3EkuEcsTqbuca26I+/AHW 6v4u4Hpa/2Qdn7a+28TTcv+uMtlR3T4cbfu6/MRlB8ajkQ+/AsK/YAPpJ2cgT8+KIelCi7xb6Kkf os5CDyRY+1d+oPzBQpPIC23rT0ytu05chbtd6Qd3wMWE9jqz9i6QNE11N9TdHVwo/YbyQrOyvZqs qI6RLuyv7BLhgZcO+E/t4ObA9Qc8zI3KJO6OJ24yEh5y6/LBQhURed42ULJJsjZEwDc8iLjwDTOI 1jZ/9y8NwoztVn745+lZevX1l/2X3f8BxjX+z2VuZHN0cmVhbQplbmRvYmoKMjM5IDAgb2JqCjQx MjgKZW5kb2JqCjI0NCAwIG9iagpbOSAvWFlaIDQ3LjUxOTk5OTkgIAo1NTUuNDM5OTk5ICAwXQpl bmRvYmoKMjQ1IDAgb2JqCls5IC9YWVogNDcuNTE5OTk5OSAgCjQyOC43MTk5OTkgIDBdCmVuZG9i agoyNDYgMCBvYmoKWzkgL1hZWiA0Ny41MTk5OTk5ICAKMjE3LjUxOTk5OSAgMF0KZW5kb2JqCjI0 NyAwIG9iagpbOSAvWFlaIDQ3LjUxOTk5OTkgIAozOTguOTU5OTk5ICAwXQplbmRvYmoKMjQ4IDAg b2JqCls5IC9YWVogNDcuNTE5OTk5OSAgCjE4Ny43NTk5OTkgIDBdCmVuZG9iagoyNDkgMCBvYmoK WzkgL1hZWiA0Ny41MTk5OTk5ICAKNTg1LjE5OTk5OSAgMF0KZW5kb2JqCjI1MCAwIG9iago8PAov VHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzUyMi43MjAwMDAgIDU1MS41OTk5OTkg IDU0My44NDAwMDAgIDU1OS4yNzk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2Ej MmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1 dGgjMmR2Mi5odG1sLmh0bWwjMjN0b2MKPj4KZW5kb2JqCjI1MSAwIG9iago8PAovVHlwZSAvQW5u b3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzUyMi43MjAwMDAgIDM5NS4xMTk5OTkgIDU0My44NDAw MDAgIDQwMi43OTk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2 YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5o dG1sLmh0bWwjMjN0b2MKPj4KZW5kb2JqCjI1MiAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5 cGUgL0xpbmsKL1JlY3QgWzUyMi43MjAwMDAgIDE4My45MTk5OTkgIDU0My44NDAwMDAgIDE5MS41 OTk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAj MmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwj MjN0b2MKPj4KZW5kb2JqCjI1MyAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsK L1JlY3QgWzExOC41NjAwMDAgIDEzOC43OTk5OTkgIDE3Ny4xMjAwMDAgIDE0OS4zNTk5OTkgXQov Qm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1w NTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjNSRkMyNjE3 Cj4+CmVuZG9iagoyNTQgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0 IFsxNzYuMTU5OTk5ICAxMTUuNzU5OTk5ICAzNDUuMTIwMDAwICAxMjYuMzE5OTk5IF0KL0JvcmRl ciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2 LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzVzNDLlJFQyMyZGh0 bWw0MDEjMmQxOTk5MTIyNAo+PgplbmRvYmoKMjQyIDAgb2JqCjw8Ci9UeXBlIC9QYWdlCi9QYXJl bnQgMiAwIFIKL0NvbnRlbnRzIDI1NSAwIFIKL1Jlc291cmNlcyAyNTcgMCBSCi9Bbm5vdHMgMjU4 IDAgUgovTWVkaWFCb3ggWzAgMCA1OTUgODQyXQo+PgplbmRvYmoKMjU3IDAgb2JqCjw8Ci9Db2xv clNwYWNlIDw8Ci9QQ1NwIDQgMCBSCi9DU3AgL0RldmljZVJHQgovQ1NwZyAvRGV2aWNlR3JheQo+ PgovRXh0R1N0YXRlIDw8Ci9HU2EgMyAwIFIKPj4KL1BhdHRlcm4gPDwKPj4KL0ZvbnQgPDwKL0Y2 IDYgMCBSCi9GMTAgMTAgMCBSCi9GOSA5IDAgUgovRjE0OSAxNDkgMCBSCi9GMjQzIDI0MyAwIFIK Pj4KL1hPYmplY3QgPDwKPj4KPj4KZW5kb2JqCjI1OCAwIG9iagpbIDI1MCAwIFIgMjUxIDAgUiAy NTIgMCBSIDI1MyAwIFIgMjU0IDAgUiBdCmVuZG9iagoyNTUgMCBvYmoKPDwKL0xlbmd0aCAyNTYg MCBSCi9GaWx0ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQp4nO1dS2/kuBG++1f0OcB4ROoNBAFm PDMBcghgjIEcFjkEs9kEC3sRZw/5+1FLcrfEr9kfSRX1aMvGrm2OmioWi/Wu4sc/f//H4V+/Hz4+ fP/P4Uf/8+H7XXKf5HX3dUia7w/DAV3dpzo5fh0qld4XZTv64+Xu9fB693j32Pz/9U4V7Qf7H80/ vr0iab9///Hb3cfu5XfdyPeHvza//e+gD39p/vv18NPfm8Gf+/mOD7zcVXXRwJEkKm3+fB7+qXRd 1vcNUKoZT8w/jw//++5vfzj8dgRM31ct8KoDcPjnB6XKJEubT6pJIL+eP3pfJGmtVV5U1t+HE6dp D092yJLqCEmSFM3S0yxvPtF85c14XRyX3Yw3OChUdp810GtzXJctAvRwnmfL/Ef0/DKAuU77L+vv I5gHsKmkaudvYR68S2nVPmPCNh4/r+U8z7NlfhNmITxbYLbBYNuXGHi+vNcvY7w54fkybdhoSQjP RVG30yf1mJ6LMmnBacZHMBjjJ5gH8zxb5hej56LUHYtJxrRRlN3vKjFgG48P1nKa59kyfyQ8W2C2 wWDblxh4vrzXL+NxJzxfpg0bLQnhWSW6n39Mz814D88YBmP8BPNgnmfL/GL03MyZdZs9po1mPO8Q CrANx4dreZvn2TJ/JDxbYLbBYNuXGHi+vNcvxrgLni/Tho2WxjB32sxRObP9PoTZSx8qjkhUeXbI s0asHf77z+bFj4NXv2mINehLfq9pZq+zMmsUzYPK317zGKa7qfZ7CEs3YtHdXq988PPT3cdvRYOC w9Mvhw6CD92Ppw7oD3VW5Yennw9/PML0p8PTr3dHTbUf0O1AeR5I24HqPJCZT3RzfH3qlx8H00VZ bRDTRVVvDtN1nm4Q03WRRcJ0oH31euWD7Xqa1TQ24YUFqUaf/VA3wqYHRtUmuCb8OjHh/2bgQH1x xEG75Amw52oEe1Iar1EVAwSX20GWnZ8ozI88mJOaH0m61+YmUVxBKs7x1ZwDQIfFfTEnNfEBkzrv VGZ/i+qeqM8Diq4WFvfJfAu8VpmQ+uMUVqtK8/SapIxYh8XBZtPXOuwtPYUOcMBaHsw5zOUjScE2 wBz0I0AfuBaAA/ZFAA78iIlCh5MNcwBJ0RMFkPYDU5lhx8hLZaUHOLg5BRWIDBACvN+yusFbgCu5 MuWpGKqVJ4aicPaFuBCQLudCCDrsJUdhAK/jIofTpcRGccZl6gYOGKOyEPUrLj4DeB3HugTBwEYB fXDCNd+SmnxLfWZvkVAEQ9iF5TTIsPqqsO62nFS6puaDZgyMjBOIq3Y9mffnY5TtKjpZrUVFn7gP xZFyj7a7ZfkB/FJ9MiE1j4Ome8vlKbwFeT9XSQOYDkxq8jocoOoEkhSwem5MWGSyCGvT6nROC1MG A4Z2EroxEppkbjioMSCDQH0AkuKSjiNoLXYAQEqxjoownAa+fPjIDdlWuFogberQcaZ1GQ6bKitk /toDYhn0HGBC3MPFXbPaRBkoLbCW7i3Kx7W0G4bGHNQgQ3zAAQG9Fw4ZV6b5vsBh5zzGnz1ygtmO jgKgpwnbF/DdIxzUu+98omSYX1aMZ712gjg39N/LVNFz6qobTUVIlY8QIiKE5wwhTjpke/TPG8nL RP/UN+9z6hD/4FobjUMhBXE7iIsLASG9uaCjDGcvlBXL/t5rfILb58DIYLmRHJylur7+7fiEUeWQ UFrhbIPxwDVQqgo6CLYYKHTQJ5aJde5yzCDtz8ZbuLkRsDgecre5Z2SYcGkPTG3G9ejgWAygbViL q1to4sZoXY82ZilLWYKlbMaW1oqxgwB8cPuDnw8Hjy+6yWAS6vQJ8XnBWwAQLg0d1BYJogrQMIL3 X4Yv19sLu4ZQN4Rz4Anw+lCt3YE/8sBCgAMzAIUyAqPWY4qhwi4FKczz/Hg6GZUxSGTcPct9zzAp T2sDSMEUiBIhlcvKSJPC+hZ/0B2CFZsPVItw5VSfzhjNddg3xvt87BkERCjFyCBwYOzcLcj1vIDU l+1EO1ebFf0OojsyjD3dk00tdLlHhK4zwz0i5C2SA6I7242QvEtvvgxTzpUNsnn4lv5s7naAviVQ pukQI0AfoETRDJAdZ48xKjlXU4UX4IwQYMILWV83JYP8Q3dIY3DoBNJiYwZmZJhwcQMBwjhxF/BM +yepoH0Kq4VDR1WhEIOV93ToIFVJDEr1MVlCJuWp1lTScSWehxDhIyD6uNPwgqT3P1PcgeOQOjln N4ENSyUZLlwpZ6Q6l/NMhSxLRpCJtPmIYtb5m2QB7TYcXssDUwFWHK+r4YZfQL3XLBiTENMO+OCO tCiBGf9ilZDjAeEO7t6X6BVAP8JR6NBZyJLGIcNz68KKwwD/Jac6uRDzNT0OApcBdrBM2kJSj7Hs oNnAeuEJnIT7SuIkf/lnJW1Ot4ns9V3q3K2mupWmtoRk5QQw81nqXyX15Uyd9GWJ7NmA3K9Fi+wn N+CpRzi8Kc+PQ7ZsgO3LmSx3SgQ4dqJUVUfxBfFok0MMg0sIpDtKVci7qZ12IdM5wOjcVQgxdq89 lEjMQoUBfs78fb9rV2amavNpOt6IOBrRPN7g7cq7pUqhJHK/F8qRg9U6uNzXknk3yCg/9/zvLjdL 2mszLv8+6lXv8DzvZO/50paX1MerBC6xkpaln/wCCQ9WBYSzLNXASp1H8ssn50o4r6dYH+eKLi+L lmvtVfhbTEh79nTlCaStLxdoC4RCNyJ+00F+rGjJdfkGi0BD+dsuLVnGZJ8pKBhDtw6QiyjCeLJX gBkoEBNdKj9qLYD5l26HpGWBhkvXwg8QVmr6Yx093tRtHlAQKGM25EU24vQOJ4izXIvuORXUViZl 2v3gcovP3+IPIdQAXXw7DJW60WYqTQNLTMKtNJOy4O+acLBeJJqGLtPRbSaxdXv3KE3msMWYxW5X jgfUAYjcvyFSE9dJutwuk7kbkgd7zbVkBT0OPJYhUY5Bc3TXe4XJ5uuGvNyDAjVADpkfAtV8WfeR gW8p7ehyEEHDbmPA/M1pU21OgoE5PktIGrtcfe9ETpVV5YhV8bCTg3rEZaq/ajerXBZh/6W24fS2 y6BuTyu7CcdIiCSf0w+yvOB+B/7tqdKiKEecbSYnuUjbp5YpF8nOhJZkQjG9k9c2igfkA+oRAixU 3uaHN2r259IO9EE3m2t5S3mjArYBYmpgkHID3f+87PpXIOubyvmzasT6Hcq3qEGO2Xj+/blQFMJr LZxeRBQec0e6SR0yeqE4LUavSpG+HQ71WlGywnjfVe7l4bxeQs+9JfUhQI5b+OPEM5Vm5ehQ7Rk3 jIQWzbiZykHbrOnzboPzUXXvvepavODD/GSsRz/ANDxRkjd6C+l+FNFVVqSS/C2Osh/Q71ygcdOG eXWUYJNI8tvt5vyWZ/cGzejVnxwF4wpzfvsa7MF7ezq4Nok2n5BICwa2kNDTBwh5MGWHukCgwFdj Jg6XpwtzoYOf4D0PazEvr4CO/YWop0DET8Rbs/JsqVlEB48XRukNsBqCkei5vWv510EXyavnagGs NqCtCz/qATd4bC3yXWbWjoe3Hfl2KJWnWVwOLSu4n51ryVw5j9LUSCDvI46JyP39NCWL49TB3pO4 eQjg4Blp4fZ/fgWpEkb0Hthfp4CN40UtdDoWIK5eVBG5deU+5Z1iJlMMT+qE1mqZpixlng5/MXx7 MvUtAjx2LbbTrhxS0RalVI3rLRbJPjkuX4+47rJamYgEOV8GfVOKnFwCXpVkb4QJbRq26+NaiKXO dHVQgFP0XXVUTxMTpwFW7Vr9U6nyl+MBCibXFjaj12yug5xXBYBAYZ6z4isicFRtpdPt6pshOdBm tZ9EH9fdPcPIYSXGNsoomheHJMXvqeS30VOJjHTKzeKAm2RmucQ4DWgUwW9K4HTKHeD8sgnuv6Cb zQ0Y1C4ETY1s7362MS4l4xJcqyq9slDv7pqzYn2puG0MFW0eSbcaD4ig/ChOZa6YzE17aWCvLn/+ OE/q1C7ZFpFsK+pg4uCgCHDGSbRRuyFWtQtZA+tz5gKJyIPy1M+L0imaqAItr0TyaZYpKEF2sZIe m7N2KpSgwjqRrDBciPWtWxr6+7xdLAjO3QIa4/jfuhwip+dRITcsyhayFx2adFDniMOlWZwRSyQ7 BHhtbreQry5PXF6gkE9DK4LtlPrp2uTgUGKnLPfPgXWutEn2EGUozp8pLlAXSOyIVXiqAaoY7+Cg RnChfBJ/jhOg+ToEmflHJHqUCxR9r0XlWktoLpLPX0BnEzEn0FMI+qY5oL6xWfUXE+907wLcIO9d iQNq54pQQPqlVJ1EORYQNooQMDnV0RFtPc7LdJJzlkOTL/LNxwhw4Bq8WemGDxrngHua0dP7CXPE qQLLamWcuu26um6pg4+oTEkL5/U7tMMQuCvHQYdc1GltWqIjR0N2+t2wTi1PuVisDi/odjqrbeKz zIy9NnVdbZolMAAtdnDzwb0BGjXtkZbAa00vg4b2nTCHxUr1GcC0AXiCGnL6K6UomNTiBQS97gqC cBtgbyF6a06ql3S6ZGllUKuMNMsMhhfQ3YcrYg7eHbgZMaCwh6tZUbi5RP57TCe9jEjMtRUBy5hZ zg27p5pZ2kQA96NciCGa3TNtzuTBikGBBZ4Vx4DPVDZecZzWUhJ200rUM54Hjwp9wN0jrs3app74 yqD4KJVWcb1CRSlJZgEeXHA2A8uD9XMh4HCN3nbyTjYTBRC5nSjiibkGxzSLbkLL8TIZn8PV7O4s V1DsDj0C+tJ5yzJSprJfNgUMAIx4GntGDHCP3h4nnH7u9jghUUOERESeG4dIIuv6hgggxJGwlt4u /tmgDgoirWMKyVtdpi+L3F3ezQmqy1m3f72au1gqu2qY0VuWo4Z6dIEWOnDvuIM5iCqEf5db3msB IYP9h+XyxDJeCuWf2Y1OfX786eVh8/StErlkmnui4ZBxCrLkq3r1Wpil4iikpS94B2npIDSBSAdF W+cc67zuv4DXmP/mkLBtn6xlXIXNUa2qcWZCbx8N0ob7POlBvjI0usvgEZMxa+DUuflEZQz0SZIm Yw5eaZ2OHZSw0qxfBqjG11ba53bmV/DV7z7M4rsynaWWtemiMJyvlw3WUNzpUhnhjE/mkmqTbL4C Ms3i796cP0+Swp03uTCi0lRFRVSamhsBZG6atHwA5oDThcfNRO3wMDXfh9dmtapowe5//HgJDVA/ Hh7v/g8Oju9oZW5kc3RyZWFtCmVuZG9iagoyNTYgMCBvYmoKMzkwNwplbmRvYmoKMjYwIDAgb2Jq ClsxMCAvWFlaIDQ3LjUxOTk5OTkgIAozNDkuMDM5OTk5ICAwXQplbmRvYmoKMjYxIDAgb2JqClsx MCAvWFlaIDQ3LjUxOTk5OTkgIAoyMzcuNjc5OTk5ICAwXQplbmRvYmoKMjYyIDAgb2JqClsxMCAv WFlaIDQ3LjUxOTk5OTkgIAoxMzYuODc5OTk5ICAwXQplbmRvYmoKMjYzIDAgb2JqClsxMCAvWFla IDQ3LjUxOTk5OTkgIAozMTkuMjc5OTk5ICAwXQplbmRvYmoKMjY0IDAgb2JqClsxMCAvWFlaIDQ3 LjUxOTk5OTkgIAoyMDYuOTU5OTk5ICAwXQplbmRvYmoKMjY1IDAgb2JqClsxMCAvWFlaIDQ3LjUx OTk5OTkgIAoxMDcuMTE5OTk5ICAwXQplbmRvYmoKMjY2IDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAov U3VidHlwZSAvTGluawovUmVjdCBbMTc0LjI0MDAwMCAgNjg5LjgzOTk5OSAgMjM2LjY0MDAwMCAg NzAwLjM5OTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMy ZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwu aHRtbCMyM2NsaWVudCMyZGlkZW50aWZpZXIKPj4KZW5kb2JqCjI2NyAwIG9iago8PAovVHlwZSAv QW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzMyNy44Mzk5OTkgIDU2NiAgMzc5LjY3OTk5OSAg NTc2LjU1OTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMy ZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwu aHRtbCMyM3Rva2VuIzJkcmVmcmVzaAo+PgplbmRvYmoKMjY4IDAgb2JqCjw8Ci9UeXBlIC9Bbm5v dAovU3VidHlwZSAvTGluawovUmVjdCBbNDA4LjQ3OTk5OSAgNDA0LjcxOTk5OSAgNDcwLjg3OTk5 OSAgNDE1LjI3OTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZh ciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0 bWwuaHRtbCMyM3Rscwo+PgplbmRvYmoKMjY5IDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlw ZSAvTGluawovUmVjdCBbNTIyLjcyMDAwMCAgMzE1LjQzOTk5OSAgNTQzLjg0MDAwMCAgMzIzLjEx OTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMy ZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMy M3RvYwo+PgplbmRvYmoKMjcwIDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawov UmVjdCBbNTIyLjcyMDAwMCAgMjAzLjExOTk5OSAgNTQzLjg0MDAwMCAgMjEwLjc5OTk5OSBdCi9C b3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1 MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMyM3RvYwo+Pgpl bmRvYmoKMjcxIDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbNTIy LjcyMDAwMCAgMTAzLjI3OTk5OSAgNTQzLjg0MDAwMCAgMTEwLjk1OTk5OSBdCi9Cb3JkZXIgWzAg MCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIj MmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMyM3RvYwo+PgplbmRvYmoKMjU5 IDAgb2JqCjw8Ci9UeXBlIC9QYWdlCi9QYXJlbnQgMiAwIFIKL0NvbnRlbnRzIDI3MiAwIFIKL1Jl c291cmNlcyAyNzQgMCBSCi9Bbm5vdHMgMjc1IDAgUgovTWVkaWFCb3ggWzAgMCA1OTUgODQyXQo+ PgplbmRvYmoKMjc0IDAgb2JqCjw8Ci9Db2xvclNwYWNlIDw8Ci9QQ1NwIDQgMCBSCi9DU3AgL0Rl dmljZVJHQgovQ1NwZyAvRGV2aWNlR3JheQo+PgovRXh0R1N0YXRlIDw8Ci9HU2EgMyAwIFIKPj4K L1BhdHRlcm4gPDwKPj4KL0ZvbnQgPDwKL0Y2IDYgMCBSCi9GMTQ5IDE0OSAwIFIKL0YxMCAxMCAw IFIKL0Y5IDkgMCBSCj4+Ci9YT2JqZWN0IDw8Cj4+Cj4+CmVuZG9iagoyNzUgMCBvYmoKWyAyNjYg MCBSIDI2NyAwIFIgMjY4IDAgUiAyNjkgMCBSIDI3MCAwIFIgMjcxIDAgUiBdCmVuZG9iagoyNzIg MCBvYmoKPDwKL0xlbmd0aCAyNzMgMCBSCi9GaWx0ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQp4 nO1dS2/kuBG+96/QeYHxiA+pRSAIMOOZCZBDAGMM5LDIIfBmsljYizh7yN8PW1J3S/U19VFsqh92 25hxm5bIYr1ZLBY//uX7P4t//1F8vP/+n+Kp/3n/fVXelZXrvorSf38YNujmzuhy81U0ytzV67b1 6WX1WryuHlYP/v/XlarbF/sf/o/bIcr2+4+n31cfu8FXXcv3+7/5T/8rdPFX/++34ud/+MZf+v42 D7ysGld7OMpSGf/r8/BXpV1d31n/2beX8tfNw7+u/v5T8fsGMH3XtMCrDsDhrx+UKUut/ZvqKJBf 96/2vW+QFfo87HgWfHVVqFJVTVFZW1hX/Pdfqx9+9NONXWlTVEr7BxscvC6N06qqm+Dn4eDG9IPZ oim7gZXyNDe28m/4r8q36/az2lC1qZVtKaxlu17f6b59189zoP8NX/wYwOxM/xX8PIJ5CJtpWnBa mIdjVaoFB2AbtQ/msuvnOdC/hDkTngMwh2AI0WUJPB+m9cu4PQrPh3kjxEuZ8OyaRrV92jE/u8Z1 w9oxDKJ9B/Ogn+dA/9n42bmyG9aOecM53elcCdu4fT+XfT/Pgf4XwnMA5hAMIbosgefDtH4Z4y0K z4d5I8RLmfCsVFV1imDMz7593QnbGAbRvoN50M9zoP9s/Oz7bGyLuDFv+HZXt4oAYBu2D+ey7ec5 0P9CeA7AHIIhRJcl8HyY1i+iPQbPh3kjxEtjmLf+qQNvbZ5j430pVa5d5f3cQlVbv+YhzXVU7fcQ mK4l4Dq+Trz4+XH18VvtYSsefxQdBB+6H48d1B9U2ZR18fhL8acNUH8uHn9bbTzlvkG3Det9g2kb mn2DlU90fXx97Oe/EK6dVdeIa1fpq8O1Z2x9hbj2jG0WwnXiGu914sV2Qsqvx/zC9NCU3IZ7VGPH 0DQSvEFDLRsa2eBkwyfZ8Fk23MuGL7Lhq2z4RoeFPuSwqhQNGjqV01cwF/mKsgwOBSiEUeAJOX0j QVeAQgAMpg/DUiQb+YqWszVaNoAIwCgSMBgFINWyDy37gCcApxpQSGlr5GyRgyQXaqA+kJLPVqLQ VGy2hoopcpCEFJ7QQNs1Aww7Heg7rrjKgN7y5s7rLW2rsVZy+3HXUjV3868mVPNX8QTQAdUUdPpN DNsz2YRFAEh7Sd6/ojs4rDQidgIOSamQIbITk5PEjRgloLYnEKQAQfORjBoWKCdnqxpqqSXonJQ4 Wzms7QBTStrTPeda8CE47JJSqOrB4nJKAdqBY4CWoMm+CEhRLAF0MON0FFBLi8hHxFyAL0HWgS8p kmFYJBSMAihMgAPmIsUS9Raw5XyG6V851jo4aR5i6Z/HLNXxtDJc6wLxAM+cicAbAI0peQasEFIT RBcAuxTR1bJTmD4wMwg3vGKF4s4xW9TTwB/AUiCYHT7UhB5KcYYkcU0WianrVmKa5qRa1q4pp7oc s1NlOz1TbiMGsFyCFaftPGhV7hH9Tbb0i52Bl0m71feyk35VPuVVKomlq7GaIXrmtYmoV+hcuIuI o0jJ4/5fhEvA9Sx4iG/JqwJ8AAr5yuU8xoz7FAgHZSkEjJqZZZZlYP8ADugUHGTqMPUNmZS7aoJM xSHh3j3QDny5+cIOfYS8vSNRpNdmjKLe6GRxGjY7f2d1GngMIWHxVmblTbtF/M3xOJFhWZAnqveB wiwxMjQTuCoC4LlbmcPjudglXoQrCg7vW/IJL1+d1yZIGR58Ayai3hgiAPgOuVnimQeSUrzRBGc8 i+vRRfiMUyGLeIuBLyCZ7zEGfupV4y0SfQoygHaEKDINu1yuA5HC/fSVPqFkuICAlcowiepY3W53 aYsRixvpmCJo6M1iC/SLc8ZlVMRKKyJxgDoFPJhgPgsk9BkukxTDtaX5JDjhwMqRaxNuwqjFSlop nCTgehrzGyHFoG9ppgxGnAD0+cozAmPUk4pwJcD7AIzRFB6OwojdBs65PENlEa8Q5R2iD7JBQaal 7LVPnBvoVuApbuW/ZLQLWoUAScmUyrH9BIx5ntQphIPPNsL/ADtTUvHnEQ14JYH/6SjcQ+N7ehGO Ibhf4Dl/kk+AveQylbC7sIg+uEndKaQO0zyUnEy+2HMevWy2/vo1L4w4V0XECShXJTgqCS52wmYy QgrsnuKV53DTb/Gacac54jUZVp24ij6wpJQrU9RMR0QbMgvNaZKpL0sA8hiAaueYX4jQHNg4h1CS 3DfIuT1h1247TCWBT/CZA6ePpmwV3yfi6/+I6NWZ6L1IMJmn2/FIBWzP8ldgthz0BM8EXgFdlpzF NWVnKJIVsDJfIQTWpUdKrq2aseii450lJcvW6/E417N5sogvcvGLhjwWwdkxt07pTJCJhOTQhLA7 CFoCQ/B8DKCdnG1CJkXEsPOPpESEmXiaAOhMboYBQQkiRJOp+XnEiEAUJ1SGBTGo4XnnXkjlhaoS tSQGGAElC2erQXPDqXjeKfAyMBWcrJeaW0GDPDiOw8qj9gApNsCZdwm6gSPuci5mlkpltKubeNrR EhhYNgIqCfDiFFCeAIwsSDdUiaCvAFbhFah5AIUUeP0GKBwAoyAcYA4CRSEy0V/WgZmiDIgZrUUC 9I8QM7rcB6kyIIgAGFCX8iGSGwhByR1RNWWRCjCSUMjLATs0pwHpAk9QtxREKORzTkk/FTJAUISQ wVY/cJB8wgBdYBRamwUnx7Uh2AfQdWB0aAEc9KdnbUITpVOreKVjgEN4jSCqUgyVugSVgmEaICbw EGdu4GUglYSUTy6HN6TBPX7Ls0XagmELHPqb8FKgZhLUOwLnGEDnpassKD8JqQU4INArVawFOAKB /sErUqVYGAUoV+dUOnqGpwuLEqAMN/XzPR3kZdkpGh1qMCysuMAKga6D2dJYmQK7DZO7VCRzExuR cTLfKlso5QaUA+mXChSMEhau4/Xh6AoUJBdXdTAKqBQgNhgUGBZmCxiDBRho5Yzhx7rZRZsznEu8 VSojoC9TqSzL/nqWLbv5ObzL5GjwnRPeR0Atz0mvgsx5pAvfkOMZSldT3eBkZcbWjVBugDNI4ozN SMyidteljebMiBScHNuA59mxTznSsMQu6KUkBr/35NqMuTZrs628jlp3fkpXFsM1/4zduap0vS+u A6ynpA1QRzaHfUQHkhZMjCh0nLCxfqkK9FaSeQFxOOVC5+gKs81Y+R+zXMpjh+w6KCO0hlpEojw9 BJmS5c0zxee7qRGlrvn6gE/uNOc3c7jcCWWOYK+RJgVE+Do5Dh8AJ3MyLJGKleK3cR0KDTxrliev DVzd/TU+3Y2pZXv/5uHPo8tnIp7nV9PMHLTVeW5zOdChuoJtOaRGbVVe6MqZwWniQOR+QCDaB9IU GvqzIpoaaDfBOh2V64lhamlsejlwx4zbS+xUH1+l6ICVhz0E2kfP5W4CDpDY3rQmOM5wnHwwLtwh cn9AdsA4dy3JVzNNW/XGip23W+D8Mv3JqcD5NV/xkcGHiyhXzV2UJeqJ3M6pn0LqTlQd4sA7dL4R oCU74MeWONZrof+pjOTcsG12lSZTqmLOr6WeUDXyTDuJMTUUEkosUV+zzyIcmpUErXGebY/TVF15 74r3NNFkYJBbKDQXLY/V3I2bq7rTHeA8Vma9tW4LZZtE5CzQK1wSziVG7GNwbyXCwc+xI80rVYDx gv0TeCXBEOU4H3y7a2imycTDwG/5cpmUUo/ztwZD5/ZzlL85VuvaZqx234PLlMdSuaBRXWh9+4bj 9m5/jQGP2wMjzI/K92cyBs4Fhpgh5g56z8hXIBjOeZaH+oFVoMK0nF3vsg3LSVeHFR/fVp2I/V9A MNztilhEBMMTkqBosYQIezHfbJ9rucgPy85P4MFh+cp/frmpRQqhvakMcV6f+zR+HvdIE6rLnqkI OrU7B7YT+J3BgPb5O1AnCsAks/LRqVZ2rPz5xcuh+eZwBZV3WoIYABxx3/BS2Juvarn252c3IKrP K/QkXKSQEDrgXj1ASr2DLKp8kXTvt+zpnObSk3PtPs3PocYIPr8TI4fDSe/KyhXTMEwrX8qGJa+b ye8Xk6NE7Nfl2xZWpbbRk8khQ+gNcdsH3kEOLRy7+T7LoPI4GfefE6wSL2cZqLQ0J5U5RT74RUwR xz94nvrbjax5L3krnxH5rjRu1pcEwAVNLfE/lTMKaZYQEpBPYPwKInpQkx0CWBA40xDiAtghoncF UTGldLWF7pYiSuwrP07GFewiharPcxtYQgXthPsq3xlLnSfr+FIOSkXc5yn3nBdKw01YS8H8eR3j +dpgsqBwjA1RaEOU9jZCbcp4vWw/V+Xd5moM/9G1H2rXtir/f9N/elopVd81zi+hyt0f6/HLdd9v +2z7ed2+UYxftettv/7T5tnhoJs/9gBuX97B+7T6dfX5p6UspDKqNZH7KsuwnfaWddGlKAVUkvJi uhzh5oitAzg0wBclV5yXBE9wU82L7tKTGSn3Bb0vD4Hf0gKdYsJIMqMeGQjaqtR98fMLMbR5wonK yenRPbyIBFHqvkUEumhOacoOHaAZFDM/Cp5DVSXsCy9xkfORtYT2kZ3K9V/AfvJvEWGicGctL9eT rOz9zS0rw231Cs7EQsXoDu21xNCAdJCV3cgG6fDiGrI+/ISU5VRMGFeKa9EuBBM67zytq8cF6S5l nv25+AmKDzHhv4tXjw9VtxPrfzy9pEbYHoqH1f8BpFJDpmVuZHN0cmVhbQplbmRvYmoKMjczIDAg b2JqCjM1MTIKZW5kb2JqCjI3NyAwIG9iagpbMTEgL1hZWiA0Ny41MTk5OTk5ICAKNjYzLjkxOTk5 OSAgMF0KZW5kb2JqCjI3OCAwIG9iagpbMTEgL1hZWiA0Ny41MTk5OTk5ICAKMzE0LjQ3OTk5OSAg MF0KZW5kb2JqCjI3OSAwIG9iagpbMTEgL1hZWiA0Ny41MTk5OTk5ICAKNTQuMzE5OTk5OSAgMF0K ZW5kb2JqCjI4MCAwIG9iagpbMTEgL1hZWiA0Ny41MTk5OTk5ICAKODQuMDc5OTk5OSAgMF0KZW5k b2JqCjI4MSAwIG9iagpbMTEgL1hZWiA0Ny41MTk5OTk5ICAKNjkzLjY3OTk5OSAgMF0KZW5kb2Jq CjI4MiAwIG9iagpbMTEgL1hZWiA0Ny41MTk5OTk5ICAKMzQ1LjE5OTk5OSAgMF0KZW5kb2JqCjI4 MyAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzUyMi43MjAwMDAg IDY2MC4wNzk5OTkgIDU0My44NDAwMDAgIDY2Ny43NTk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rl c3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQj MmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjN0b2MKPj4KZW5kb2JqCjI4NCAwIG9iago8 PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzcxLjUxOTk5OTkgIDUxNC4xNTk5 OTkgIDI0MC40Nzk5OTkgIDUyNC43MTk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUj M2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJk b2F1dGgjMmR2Mi5odG1sLmh0bWwjMjNXM0MuUkVDIzJkaHRtbDQwMSMyZDE5OTkxMjI0Cj4+CmVu ZG9iagoyODUgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFszNDIu MjQwMDAwICA1MTQuMTU5OTk5ICA0MDAuODAwMDAwICA1MjQuNzE5OTk5IF0KL0JvcmRlciBbMCAw IDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMy ZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzUkZDMzk4Ngo+PgplbmRvYmoK Mjg2IDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbMjU0Ljg3OTk5 OSAgNDQ1Ljk5OTk5OSAgMzE3LjI3OTk5OSAgNDU2LjU1OTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQov RGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFm dCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMyM3Rscwo+PgplbmRvYmoKMjg3IDAgb2Jq Cjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbNDIzLjgzOTk5OSAgNDEzLjM1 OTk5OSAgNDgyLjM5OTk5OSAgNDIzLjkxOTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdCAvZmls ZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYj MmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMyM1JGQzI2MTYKPj4KZW5kb2JqCjI4OCAwIG9iago8PAov VHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzUyMi43MjAwMDAgIDMxMC42Mzk5OTkg IDU0My44NDAwMDAgIDMxOC4zMTk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2Ej MmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1 dGgjMmR2Mi5odG1sLmh0bWwjMjN0b2MKPj4KZW5kb2JqCjI4OSAwIG9iago8PAovVHlwZSAvQW5u b3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzE4OS41OTk5OTkgIDIwOS44Mzk5OTkgIDI2Mi41NjAw MDAgIDIyMC4zOTk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2 YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5o dG1sLmh0bWwjMjNjb2RlIzJkYXV0aHojMmRyZXEKPj4KZW5kb2JqCjI5MCAwIG9iago8PAovVHlw ZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzIyMi4yMzk5OTkgIDE5Ny4zNTk5OTkgIDI5 NS4xOTk5OTkgIDIwNy45MTk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYj MmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgj MmR2Mi5odG1sLmh0bWwjMjNpbXBsaWNpdCMyZGF1dGh6IzJkcmVxCj4+CmVuZG9iagoyOTEgMCBv YmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFsxNzQuMjQwMDAwICAxODUu ODM5OTk5ICAyMzYuNjQwMDAwICAxOTYuMzk5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0IC9m aWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0 ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzcmVzcG9uc2UjMmR0eXBlIzJkZXh0Cj4+CmVuZG9i agoyOTIgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFs2Ny42Nzk5 OTk5ICA5NS41OTk5OTk5ICAxNTIuMTU5OTk5ICAxMDYuMTU5OTk5IF0KL0JvcmRlciBbMCAwIDBd Ci9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRy YWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzY29kZSMyZGF1dGh6IzJkZXJyb3IK Pj4KZW5kb2JqCjI5MyAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3Qg WzUyMi43MjAwMDAgIDUwLjQ3OTk5OTkgIDU0My44NDAwMDAgIDU4LjE1OTk5OTkgXQovQm9yZGVy IFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYu ZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjN0b2MKPj4KZW5kb2Jq CjI3NiAwIG9iago8PAovVHlwZSAvUGFnZQovUGFyZW50IDIgMCBSCi9Db250ZW50cyAyOTQgMCBS Ci9SZXNvdXJjZXMgMjk2IDAgUgovQW5ub3RzIDI5NyAwIFIKL01lZGlhQm94IFswIDAgNTk1IDg0 Ml0KPj4KZW5kb2JqCjI5NiAwIG9iago8PAovQ29sb3JTcGFjZSA8PAovUENTcCA0IDAgUgovQ1Nw IC9EZXZpY2VSR0IKL0NTcGcgL0RldmljZUdyYXkKPj4KL0V4dEdTdGF0ZSA8PAovR1NhIDMgMCBS Cj4+Ci9QYXR0ZXJuIDw8Cj4+Ci9Gb250IDw8Ci9GNiA2IDAgUgovRjEwIDEwIDAgUgovRjkgOSAw IFIKL0YxNDkgMTQ5IDAgUgovRjI0MyAyNDMgMCBSCj4+Ci9YT2JqZWN0IDw8Cj4+Cj4+CmVuZG9i agoyOTcgMCBvYmoKWyAyODMgMCBSIDI4NCAwIFIgMjg1IDAgUiAyODYgMCBSIDI4NyAwIFIgMjg4 IDAgUiAyODkgMCBSIDI5MCAwIFIgMjkxIDAgUiAyOTIgMCBSIDI5MyAwIFIgXQplbmRvYmoKMjk0 IDAgb2JqCjw8Ci9MZW5ndGggMjk1IDAgUgovRmlsdGVyIC9GbGF0ZURlY29kZQo+PgpzdHJlYW0K eJztXVmP5LgNfq9f4ecFpkeXLyAI0HMFyEOAwTSQhyAPQW82waJ7kc4+5O/HV1Xb/KyiLNNHHTPY nWq1S6ZIipdI6uOffvwj+dfvycfPP/6TPHf/fv5xUA8qLds/iar+fugPmOLBGlX/SQptH7K8GX1+ Pbwlb4fvh+/V/98OOmu+2P1T/fL4CtX8/f35t8PH9uWHduTH579Un/6XmOTP1X+/Jn/7ezX4czdf /cDroSizCg6ltK1+fOn/qK0q9ENWfa7GFf2xfvjfh7/+lPxWA2YeigZ43QLY//GDdqYsimrEzAL5 7f2rFRS2NDrNCu/n/sTWdvC4xJi8eHDVR1st3bq0Xo9SaTVe6gfTjFc4yLSrH9KGjpu8/qEZP83z 4pm/Rs8vPZhL2/3xfh7A3IPNKleTpIW59y6rs+YzhW04/r6W93lePPNTmIXw7IHZB4OPLkvgeZzW r0O8BeF5nDd8vCSE50IVZbMnzZCfC61M99oBDGT8BHNvnhfP/GL8XGiddq8d8EahKyGoRmAbjvfW cprnxTP/Qnj2wOyDwUeXJfA8TuvX4XgQnsd5w8dLQnjWxplaVVSaY8DP1bg7KZ8eDGT8BHNvnhfP /GL8XM2ZtvAMeaMaz1p4ALb+eH8tx3lePPMvhGcPzD4YfHRZAs/jtH4l4yF4HucNHy8NYT6aaSUY LZNsn8xVmNE2U5W5l+g0+e8/q7d8b2ybCAtKN3/7wLQjHgvq7cwXPz0dPn7LEq2Sp1+SFoIP7T9P LdQfKrBznTz9nPyhBuqPydOvh9pg7AZMM5C/D9hmoHgfcPSJdo6vT936F8J1od0l4row6cXhupI3 9gJxbXTmFsJ1iKujcUHaVHjSOi8rMdd9LtSDVq4St7psPmRlM6prDu8+PR90bY6WqbPq9Mts+OWs m7d5tvmcN99Ihl/N8+O81af62f5L6192AB6/fIL3uRKbn34678i9nUFLQy5du5pj9NJW13tDF3aI 6x7yvxDy6JQjoNbjFHUTvqJLOvCJTkoBU98IqyEcRTOQ+gHTj9wTKqeAFSw+6FrwtRn9ymc6KcAB azH0LZ6N1XvtF/IWndPdSnEaQGwWyfgEkJJlGEu5ENaC+PjMgW6mo5CflP8KsFQAbQFjX+lXYDco iiCAA14L1AdhwK4WcQqQ8ijk962hSOYRFErKRu/MF7Fl4X0PbEPgZdh1VOigFHIiwFcaaAg8u3cj 9IPRlBSsyAABifoBNgBgFQhBxR8OsHJZtwPlmU3E7+69CGoJSRUBx3TKiYiuR4kdk5p6wxiTHWfN CD/4duo5FgIcsowaIN1YOAJQtlsTYycGprXvPDXLdTGpOrkuJtUjroupOK91MepPxHVpf5kNv5x1 8x5dF+OKEdelGj3OW30irkvzS6MGXz7Bu4rrYtKjq2kcK3rAEAfeAysB5gBZtITVtBf+vXEH6bZM dZ5QALoBSNmviLiD7DbFSYFydI6b9NxknBtTKQOfeOQlKux+AZMxwLbn7R8edHDDWCGMgpwXjzyk EVvocuNHKHRY6i+jHabzB9KFF0tsMCDAcKceRYAlz8vt6YoeFwfmBKUcH5ML4CBJz67Mu1ltC5lW Z6g73VGJ0KgBttD1Ka7NQ44xISl+5/J0ASSzMhfJMF3DgAEewOtsWGsvXg4u/5FCCjz2jUwKBxKI D361AMdN7QaeC10LmNbvj9DwmoPzZZFAeKaI9A+wWuFMgudMKwFrq6isNl76wq7iAyMSgpq1yS9I QgjEVwOMsAhfCZ7oGT/vWSptXnz1x/t5EKAMeJ4P8E18acPkZZ37MsLjJmt4vDjyuHkcX3ZPDoIG Y4U8DmQgf3Iif3xqsKScUlIGzaiEBsnRo7JiJTTMQV/bsV/pX26n03oWLnxHU/lrYFZYLoUMASlG WBaE4EJx5VZ6Ou3PiLnHES/DrEPAYA5erC8RzY4J10Qsn3fp2UyEgAOBJc6779EZbrXR2SyT+BQg BR0KhAIJwzOuiIGe5o7I7WXSeTr1YLzZPFct2pdxJnlD7K6DJxJqo7M8dNBtu5ieDWk/UY0B1OXT +9iDe0RAxLkCjwAgN4V0pYNqgGORQzU2yBOgQoCUcviYK9qzlMj2TU0IGUXlrJcSEmbHKqIbbUxQ Mjwjhtoh514LoPOZiuvYunfdtrxuu+RsWImUgot3weYKVKfXkKgQhFMcEjHUCaQSPAB3aeEjTUwC AH9I0M6hz+SQLOL8YkiKjfDjAGgQVsgGAAanJnRSpD+r/PgSjIg8pUXOM3G7A075khQ+LYmCbjWr H6ZHFzGeAnCAYcMnlEXEHyNsMiA2S5eYfIhF3IdQQs2VlzYdCsyAdEE+3Zz1OK+gfMYVp/IZCfch QIPwCkPCYgJlz1o7KMr5YrGLcVu2Kg5aJay9jonNGwMr7f5NAz+36gnv96QVlu9xBUXURaqObXTu BtWuDapzq70iUyjAmQI+5cXUbamPiFSNy+kRAHCwhiFf8xKTGigQJN/utCansl8iLMwzhKTe0pmX NPw+hOgb7+YEaPK9u4apI63F5iUF7NWAwmNzKG83nyghBNPlp8iEADcOeJUVVhEx3b5c6THZINXY nT6TVFLPUyHppQEvaDnblR7WNpkjvE0Tfg3lOhjQfBgUjA76FsWKIQWvpZnIBir4YA5PsHXKANbN wRNs/N58ZZkQJvVkTII9fQZBSAagLXQ7oJN2T2yVIV0QbuXzdfhzD9RevCrizzlLQc2TnYSzkpjV 5AWZlj1isHx0Q6BaNMDxBGJFFL5LhPJkKFGHmweUkLFQXamG0wYcoa3SXcbxJ8hUEQBvBvi4cnFo mf2bHxsAL5WlyAafRBqZRGRYRzTc4YkX0fZVoBAxoGnnEq/dqP5xJYHPmkoBad4Bh2zTK1QiKrPj 3cK54j5XQzFza86liBAd6aoBVYj9huCztUIZjtmNHN0A85rdniAlZaJFF2Q6CsagMn3M6EAGn85E ElZChJ7gCyR223fqfsi7CzUSk94L8hEkaEQVL49CgUzVq8oHl2BLiQLTUATJiG1rve+dXsaIJ9io UdlDzEUyZCPO+AMsGzZlLqC5G+sABHRR4k2Oy+04ibn+ax7I9nDaohBN7tw/oOEwQUBfLNJPMyKW dbdapgqhVYu0Zjf3skP9MMe3lVFVLrwGNcD2n97mfJkdEGGGSSSwUVFlH+kA0JK3dvgUN17L8Cl/ /PbmMx7l0n5m8rZtT7x6zL1K2Dng2IU3XSXi0Pty42dXt1hCzAWDATJCNfP2hrlqVbybAIJkCK4k N6fee8Ps0zRb/MAgIMYEOUs8d8NqVknH3spA2pnLeIEZfM66oVgCHjOQsaZHF5usksNVF6UOxajM GWhGpHPUsTArWn0m7VzVUtpRpMxKbNvY6MnVsWP1bSm5vRg9AbElgUC6SKb3XZMK7DqbFWTbrd4B 7cI0pyqHCDMpRRjQkiZub6tK275APYrHNCCQU4LzglYQgAE5yt89Kujn5fZUIgXG4n6T1AQiUCt1 XubbbUXUetMn0HvkMyH5PMe1/MuIrF7+eJk/TQ2tbZDd/wE11QLaKuYabT7gEOEa80f28UUn55xl PoEvANRF7KZtYtSiKiO9hwY9PHRjoUHACGbBAkZ4UkX4HvCWiGum2SZ/+JaIi+B4nbKRgLjqmgX+ 6vJ1kBocipAR1FkWzFTrZAZdNJftr0BD2Krepj4jwJpDAktoEd6sCO2IcM4CjihPuOIL5YpTuEHi QjmJK+e6vgb9yK7Hm4Jw2Jk72PAeN5BrPIPSOcAiQTjsCOuA7lgoTtcqnSLLh/DfvYNw6bGTM5UA 1cAHOpa42A202kq3v9wUFwbUGE4vurycW5KXKcQB2vJlmgEXj7MdG30om32Qr4ayXpC8Iq5Pcbq4 dhGWwFuo+D6PNOC6aun9pEqkRXpC886FRE+jle5duS19sE3Mcqs8u+lVBRHlH7zGWFJhzhax+Qoy NsCAlKgZWDVZrCiPCpOXdgF5AKyOkcDQfkN0VoQyWROYKE3qXc02sVKX0yeid9lMDGnVosidmIaG 0w3NHXEQshzpiUNb4PDTdr0v+5HQVYymm0uwmN4hJl5/X2BOnXXlcEfE9xzdJlZnCz1cwDKZ2Bud ZUZrvdkdygqC1YgThNvyLaJjTUI6Lc28pLqiAuTguOnc5GyKVV92/iXKfO0IxwDaQeZDComnefVG SiClK7orgfOyOKZrE8Tb2APggC5GvBvL39E5vdA/oH3OqmFtIR2QGy9HCMRcfF3H5wLfmaAn4O8K TEKBUawGlJdFiEQ2o58XmgF3EPMycnrOd8BRV0TPMf7cW66P2+xAniYcskpswLe7hURgkXvpe+si weR2iCLBXHqj9DHsCLGunW2bKbJpo2RSiWOImLTPmFJg3u/lD3MiLiqYrokCaMmavIhl2rkyQOzw ZmNMsdF0uQNGsOsyCM2Zrcu6ivzdNAEIiEhIn37Iuoi+A9BFrj+RKGlb83zQVMzlIwwmP/BJWEuc sa9D/gBXJfTWs3OT8tVJfJ0MSh2Be7V40qEv7skjP5dSwB+eXbOuv+BYZJETcQHF+xTHNh9dbLJK pNFpTeCNzjCee0RjSgKJRM4QwBqTABFdXX6BDJxqOySDBR3hqbbcqLbBkg2H9to62ZsBfMSHKEND 4zI2jTsdL0T0zedbJnmutDuHxGUu0eF9bV7t71z/zg2l2IxwxCoee0T1SoA/Cry7yDWB6xS88Ams izAmX5TPnuoFZBpHRDR4wPg2LttcI+OrKpAR5fnxRmLI3QtIzr7nwsyV9Ss1KYgQl3zoLeJqniXT ua/CC9TZcFfiFoN8E0ixBdnHXkAPc8BbLHvvvaXV3wDHpumRziiCWSHn0w2n3W9u/TLn3qs0P9u7 ES0RxJJR52euZl0ldso3cooIcgdoPICUTTq932Alb+9cQy+02Rf2KLIRI+6rBx6BHSFw1ySf5oOg sz0XV3IzFxHd15xt57PE5yYbNZcXGK1OpXbX2+nI6NM19RKdjjCBYJlORzSTpeM3sPqyM3PwdgBM yrZPwuNPKDDElkt0MXzbJoAMASnGWDYtuz+wI+jvAljRP1nDdpnPpmuKstOM6Ll3SrkWhxo0MKC5 X1+ZUWWiQFna8VmotOAWZpz1CQ6rhmvzXAUZizpt0+H8XX5Sb0klQebxOh5gFciUeJ+kO+PqzZpK I6pMF0VUJQ3J/CndY18mD8Ac2CqFDgBq3fiBVew6uzsTzmwm3AYoO2EzwX5D5FDGM3Tpwis1ZTa8 ZdDQZXQ+OghJiO70dMI3KuDBngbJA+eplCtAEpk4MeOVnzobXk4kRHPgXchbgz20NM21IlV6O6E5 bGugOc8VkTLVi6vUknT/i8EVJkgujCtd6mGm/G5wBeocZIkSxURKHJ3dIEJgg01jq+pv8lahVGcN brp/nl9jY/rfk++H/wMz3LixZW5kc3RyZWFtCmVuZG9iagoyOTUgMCBvYmoKNDA2NQplbmRvYmoK Mjk5IDAgb2JqClsxMiAvWFlaIDQ3LjUxOTk5OTkgIAoxNjUuNjc5OTk5ICAwXQplbmRvYmoKMzAw IDAgb2JqClsxMiAvWFlaIDQ3LjUxOTk5OTkgIAo2NTkuMTE5OTk5ICAwXQplbmRvYmoKMzAxIDAg b2JqClsxMiAvWFlaIDQ3LjUxOTk5OTkgIAo0NTUuNTk5OTk5ICAwXQplbmRvYmoKMzAyIDAgb2Jq Cjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbNDA0LjYzOTk5OSAgNzQ2LjQ3 OTk5OSAgNDYzLjE5OTk5OSAgNzU3LjAzOTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdCAvZmls ZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYj MmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMyM1JGQzM5ODYKPj4KZW5kb2JqCjMwMyAwIG9iago8PAov VHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzcxLjUxOTk5OTkgIDcyMi40Nzk5OTkg IDI0MC40Nzk5OTkgIDczMy4wMzk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2Ej MmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1 dGgjMmR2Mi5odG1sLmh0bWwjMjNXM0MuUkVDIzJkaHRtbDQwMSMyZDE5OTkxMjI0Cj4+CmVuZG9i agozMDQgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFszNDIuMjQw MDAwICA3MjIuNDc5OTk5ICA0MDAuODAwMDAwICA3MzMuMDM5OTk5IF0KL0JvcmRlciBbMCAwIDBd Ci9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRy YWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzUkZDMzk4Ngo+PgplbmRvYmoKMzA1 IDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbNTIyLjcyMDAwMCAg NjU1LjI3OTk5OSAgNTQzLjg0MDAwMCAgNjYyLjk1OTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVz dCAvZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMy ZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMyM3RvYwo+PgplbmRvYmoKMzA2IDAgb2JqCjw8 Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbNDIzLjgzOTk5OSAgNjIyLjYzOTk5 OSAgNDg2LjIzOTk5OSAgNjMzLjE5OTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMz YSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRv YXV0aCMyZHYyLmh0bWwuaHRtbCMyM3Rscwo+PgplbmRvYmoKMzA3IDAgb2JqCjw8Ci9UeXBlIC9B bm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbNTIyLjcyMDAwMCAgNDUxLjc1OTk5OSAgNTQzLjg0 MDAwMCAgNDU5LjQzOTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMy ZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYy Lmh0bWwuaHRtbCMyM3RvYwo+PgplbmRvYmoKMzA4IDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3Vi dHlwZSAvTGluawovUmVjdCBbMzUwLjg3OTk5OSAgMjA2Ljk1OTk5OSAgNDI3LjY4MDAwMCAgMjE3 LjUxOTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRt cCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRt bCMyM29wZW4jMmRyZWRpcmVjdAo+PgplbmRvYmoKMzA5IDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAov U3VidHlwZSAvTGluawovUmVjdCBbNTIyLjcyMDAwMCAgMTYxLjgzOTk5OSAgNTQzLjg0MDAwMCAg MTY5LjUxOTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMy ZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwu aHRtbCMyM3RvYwo+PgplbmRvYmoKMzEwIDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAv TGluawovUmVjdCBbMjM3LjU5OTk5OSAgNjEuMDM5OTk5OSAgMjk2LjE1OTk5OSAgNzEuNTk5OTk5 OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNH SXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMyM1JG QzM5ODYKPj4KZW5kb2JqCjMxMSAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsK L1JlY3QgWzQzMS41MTk5OTkgIDM3Ljk5OTk5OTkgIDQ5MC4wNzk5OTkgIDQ4LjU1OTk5OTkgXQov Qm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1w NTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjNSRkMzOTg2 Cj4+CmVuZG9iagoyOTggMCBvYmoKPDwKL1R5cGUgL1BhZ2UKL1BhcmVudCAyIDAgUgovQ29udGVu dHMgMzEyIDAgUgovUmVzb3VyY2VzIDMxNCAwIFIKL0Fubm90cyAzMTUgMCBSCi9NZWRpYUJveCBb MCAwIDU5NSA4NDJdCj4+CmVuZG9iagozMTQgMCBvYmoKPDwKL0NvbG9yU3BhY2UgPDwKL1BDU3Ag NCAwIFIKL0NTcCAvRGV2aWNlUkdCCi9DU3BnIC9EZXZpY2VHcmF5Cj4+Ci9FeHRHU3RhdGUgPDwK L0dTYSAzIDAgUgo+PgovUGF0dGVybiA8PAo+PgovRm9udCA8PAovRjYgNiAwIFIKL0YxMCAxMCAw IFIKL0YxNDkgMTQ5IDAgUgovRjkgOSAwIFIKL0YyNDMgMjQzIDAgUgo+PgovWE9iamVjdCA8PAo+ Pgo+PgplbmRvYmoKMzE1IDAgb2JqClsgMzAyIDAgUiAzMDMgMCBSIDMwNCAwIFIgMzA1IDAgUiAz MDYgMCBSIDMwNyAwIFIgMzA4IDAgUiAzMDkgMCBSIDMxMCAwIFIgMzExIDAgUiBdCmVuZG9iagoz MTIgMCBvYmoKPDwKL0xlbmd0aCAzMTMgMCBSCi9GaWx0ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0cmVh bQp4nO1dS4/kthG+96/os4GdJUU9gSDAPsYBcgiw2AFyMHIIxnEMY8bIxIf8/agltVri19RHUaVH 92gW9vZyWlSxWG9WFT/+5fs/j//+4/jxy/f/HJ+bv798P6gHlRT1z1GVfz50B6L8wUTq9HPMtXlI s2r0+fXwdnw7fDt8K///dtBp9WDzV/nL8ytU9eeP598PH+uXH+qR71/+Vn763zE6/rX877fjT/8o B39u5jt94fWQF2kJh1LalP986f5TR0WsHvLyczmu7H+evvzr4e8/HH8/ARadfnF6rAaw+88POklV ph5iFU0C+e3y6EOqTBGV8+bOz92JjWngiY+RSZKHE55NuXQTJ+UT5U9Sjqf5adnleImDVMcluEpH 9niUnR6uxtt5Xhzzn9DzSwfmwjQ/zs89mLuw5RXea5i77ypM9R2ArTfeWUs7z4tjfhtmITw7YHbB 4NqXOfB8fa9f++NeeL5OGy5aEsJzksXVa1Xep+ckq9m4HO/BYI23MHfmeXHML0bPSZbV8+d92kiy vP4OwNYb76ylnefFMf9MeHbA7ILBtS9z4Pn6Xr/2x73wfJ02XLQkhGetkhpxuk/P5XgNnO7DYI23 MHfmeXHML0bP5ZxFXsHTpw2tUq0reGzYeuPdtZzneXHMPxOeHTC7YHDtyxx4vr7Xr/1xLzxfpw0X LfVhPptpBRgto2yfNC4xU6q6vDT3jjo5/vdf5Vu+VbZNgAWlqz9dYOoRhwX1NvDg56fDxx/TEgPH p1+ONQQf6r+eaqg/lGCXq3/6+finE1B/Pj79djgZjM1AVA1klwFTDeSXgdj+Rj3H41Oz/plwnSbm FnGdpvHN4dooo24Q10bFeiZcB7o6bwMPVgsql1O6Z1dWlEQn4olUegYmrYApWuh0vaD4Am5eDSQD K3y0vxFbc+ivNg6+WnPoelJ9waz+bH8ls3EPgACoP1qPaG09EkXXtyt2zwFv0bm9OjoHwBGC5S82 ggDLFB+4DwAY7GVsUQxHkOJI5o84+CoeQJD9CG6UvXyVMawjkjlggGQbhYh1uvuRtt8yC05tGkME 8bcAkmGjgD2UjWSAYxbSBvrg2wCQ+krHSv5PEOSZ6ktyXdgvBoxwBqESxEPW+ZLdVATUmizS/qu7 I/Y3hc0yfGPsxQWQu/7ElBAqVNgGrvuAMVP7Ear7dDKeUIEc5hCpCCnYNcC4ASj8RNWDthG0q4c7 Ug+ljzVWPN6aAhkiTDlZJ6OmTOoi1VkE5l3LthDdtxHqlxBDHGOwFvClkRwCPFTYfXgLxRjKR4og ztpAdPoLpQ9uK8LywQSxjRRO/PgWLgyATkX0RZyqvpzarpu/2xxCNoeMZku0kzKpNyUSn7sZvRWg lXD5XITAa2ngcB7K5doAJqXONcp6rvo5r/MQZ4CNBpNChBs1CPiswfwxkbdNkfSZe5fcY/ebM7fh +AgwSyS9lsw6z50WLNhtcELKAja4qefQ6iIhYltkfLbXb08S1+/VemBa89mWkUAiPIo3XmR4bA23 y2kcGNU/l1R0LSJbg6ujChC5CogXznw5Jfr6JQPb73LLpsquNLOE13ijehkpEgHO7KhtDFQlKd4L K4Vkmnh/ZyIRMidiSAUZnwbg4YhA+IOyd7hUtXNUHur6g/LneMrJOX+28lYc3/LJZfF4QU3ZceEg 7SiNLdr+8fpmDwxoIEPgbVBl9lsUbAtMCq9VNmAQK4Y5HAbimAF0OuEbwKcA2CMlQpjUcYQHamkA QbgNsLegdOxJm2+slY6VW9QKugp0M/WAPDxNlJrUnmnkjIjmMboVzkpi1ijLrWk11QrjnS9ENI0r iyS+eVgWAsEomZ2I87S/E0Lh6UL1p92KCecy0AaMPKBNnsrlEZAC0wKWHwnyb5Q47aLVXEUaGuBH OPP4PXNEE1F7gnFNgykhwXaB14rwIcABdvJKAp+aSh55vKi/OSlz2EFizpgiNFXc18mNFzHz3pxL ESFqInsSlcCIltivRivE/phdydH1MK8pe4KU9ODXkGyK7ZqOnRjUpVCo67lf/9zzpzy+z72tkS+t iLg4lR9dDRycaDhuLczoE7XswEgBiUoDfB5zAFEDnwNXN3vYyTC2g1WR/Y2GzDsDjzZBwiOUhptI QjdqBodgNmQN3xcDFMq9WQBEASD2ehFnmT0rYARgdzDTEM5gUogCJddF1EAKRNSx9VcqMYvtmrn9 7HDztoxtYuhHbkBcsVQ+WVhswpjdaWY5LB+/4ZvJPeY1I2CnUGMd9gFNyGVOFyFnB9iM53DQeAD3 wz1YROb8scgsASgXERCx0+OkTUZfpOxynjyXAAIYXyEWYFCHcDsUSdhxBoSDT8ozBW/3kC9J+oQc fhC0jo0U5ZnFicFpize4fUbl1uqBd2H7wOl2HA6us58mtlbkUZ49aoMngJYZi1dmiUcvU8B/O0b+ SlpxfLcGrJahofSQUmswiuEtPF3eYcDJGEVZJEnK45PwuSFxJc5IdTxuhARxj/dOPM5ruSE1/iTJ oxaGx10DxFJAUBUWR4+4Bg26CQpDG4sh7O0Or2qeltkLZEetYo+yDN57AaxzkKk8JQcqOyQO33wt /AE29EAh8AO8lqcPwxzLlCDxHDyuuDjBwKS5oFoqHQWn9OcqBBDA8b7HyJ4GY2QeoShO7RLL9z0F mZpbl8d9QpzHPgKR4ZEEIUERfDEBUhYUBA1wSrSu8/A5lwmzCyQaLVORG9KMhDbS8LAGeWtDoGTe wkAi/u+gdRFVlqjWoORpGdT2x4AQ7PYcdkpIlTcQO+8yBgeAvPelQOK4jMLQ9fnHZbuDLJfxqdXL 1Oxz7ubekQe783i/QH4fZKYtdMoYoFF9je4xHiduFM8Hhp0L6AIDBLO38hye4x77piT6bE+vmHaB hirNVp7p0FzHaR8re0fgsQogoBLeY7UBreYCNornCwfU+/D2Q7db1OzRXYd3UuMUFNBG8I4O8ZqS uCGCgXxeIH7Bgv3ERN445JFeD1uGO50OT26qNtD2ej1S7PnR1/jWmx7m/800OXtfBuBKB/BYeCzJ /2n7GtvYE2mILRE+lTjn5hoU3gKRPbtReYi0G29yzWOm8BtIAgrRA85fQRpwj1qiRIviNOQ8OsAm 9Si3CriShXPhIslXm6XceQ515qlbTVLTl9NrNRb1PRmWUUtZIkmI4/uGeiSHcz5cJJ98lvBCwP1T Icl2/C1bMTADtjLA0eUWl0Q722Xu8VgyHWNqb4A4Y0Jnt0G3qclnPV0u3FvHW3Dw7AuKMr65KNrH X1QQUDsXsrjx7VW2W1WwFa30vrquj6o+m5CsnBd97g9QZR7mwfi62JDWIyGd/SRy83nCEj/DprEB EYs74DgGbqwLvhpKRE+lKnFiKEAwCRQarJWc7dsOWjjOsY5HLniUJJvN6pF7BmasgIE1U+9vY+I+ k0kkEqII8e0kIJyPwjkXzjiGjiPurXdT2rqEy/Ru8vgGMCik4NV0MdQhKaoHhjozcYFdU0p6ecTu MsQbE/GOSSGr8+j/BIDYi0EB7d2RbaAzU4PVNZsoZe3tzvttraPtixkzAAcU/Uy9HO+pQRJ3fDxq 0mkG3TuvQlnobrmArMQACuKEK3N8Z2ype2vJbCIuana5NHoj6Y/GjFPFGlWxjspFR1mcHF/bz+mD VuWA1kX1IS2q0awcyJtPz6UgTx/yIomNan+Z9h9Om3mr71afTfXE0XrUtPOa6ru9l5a/bIA6P9zC +3z49fD5h7kMDW10tefx+bYkDTeZQMAk4KJbIPGtiNpr/lAQZaXqQlmpvkZZaXSmgPKTTVnVL9P+ w2kzb0tZSX6NspL8PG/5yaas0y8j1Xu4hXcZykrPd5tEYOrzZmq8ZG+d3huboV96lOsRAOTsy0MR K+W0BiRphUir8fkTuP7xp9IBxRchnQMFM1Szoq3x3R1WsrkbcVj3rr8+rZZuR/7vriIhh/urWJoq upPckt0bcfvmrHoTUXe5cpercrZ7X5bau9Llm+EgQdsuN23mwm7bjaSH3ba76QOLlao4AnpPjU// 80gzCLh4aw6sh1yA5dE4iRuqMlZWrCwpevN2Z0fQeF+DJ6OKkvbFkFd1u/wuc8e8RCnHtPq527qM IFKmT1LaplzM84EjEjDmVr1cIrZWtJXieKEcP6WsDdvsnavL1Jl5JHkGVExz04K3pIPEya3cisCr efik3BpZyftwJX0OpSE6OgHKaOvUP59iK/1nl2k/JhJXpbJtngjHQuWekVEWDd2ha3FPwegQp2Co nmmdZqEeF7/xojh6i+HeG3Q2dSijuXLt3Nw9gDdnAG+q1lBJf/92fS6lz2Ulj4iO8LhhlhdOcgfQ QxavI0d5FlAA6B6XyXClyUmXWuIY4QvI1likWsCbH2R0U9Fe6Ljx44mpzUBVZq0Xom2Q9Aar8Yj3 CHTFCGjo4dGEHsIqAT3TgJnHQyoi7seHdwKWL+LeeehQCSZaR+3ubqZNMrO0r1kp3Omry0T0UKFb G/v+vEgeVJXBoTlX3+ypNWOZbDN1viGHtbOYsu87BWaz2cxXTM6AS7EB1ICw9P1ZA5MLfzNLDG8k f3OwXnGy1knbK4i20k6eNk27fVKVPh+566DkOjFo//YxY3SZSAt+DofAhXQBwUEPVgYEwUCA0Fkm BSc4p25yP/mkL6iXDTEWufvG1nt2Kbai/T34kNcDwvJpHpeEXF5IC3OSEkChR4sBfgDFaZ3fK8/7 o/o2JpwsHrQlH+63raBRyXmVy7QV5G/BfQfTshbPneiEq81lJ7XAbgl4xQyCzoNUdzaxlm6chPYR bCwUMD87sxrrEewaOGPHwxVbAhqVmzMOxt/evIcgqEZZya/zUORz3L7Flc4s1sFCEThKQh5pEQAY D2LMcfgqcqnFfvgoxOuTGy6oviiXiQRRAeFh6gbLAwmH06giv0cZEuCljBc7HlnP98eI0sHUVVno vajUWzuOnHphWVr0ZdtcLaKp8++BNXAHAmr/7+8QR0S5aS2q7nkKa0Cy7V5MIi+Zlylp9TijWLUs 8gY7AxiT9PkWrQF79Rj/A0Kmc6ABYQtDA/0HcvaWBo51Ildx1Qm4i8itctGGWwnIJX4YHZ8j2uar bYqI5L3enwUwu+cxvsx1JXtP8BRKOMFgNzPEBeRefiy1lZMzQeK+5N5M2rO/7yqju5JzLoxMlQ/X 7wLZUR6lk2g0UGL0qHKdg1t5xRpXMyKHBPT2Q7zrkXJAwF3AHlffck0d4PBxYQVExs9lebwz4FSJ Fs6tezI1Nb6XFX3BdDvB2t0uv452GU2VtV4WlLCPPxGSiRlutjAW6B3r7ZbJ5OMXDvHVbiZPz9QH zRdKDKieW4ZZ42VSM7ilxsvgdxHJuAxOJnxVlYzczW9QETtSPKe2zoiSPkYCcgZv7rj2vdRGbTb8 J0EwQJY0T5Vf0fTeJfcezJPah6l6qoj7YnnOYJ6ITo3U2YKcKXllO8E8CRYA7wYsIpqbN1MS+SJZ Ah6T8s0MKCII0dUSy12IdrlpEmBF3JoTPVWcadWXZ+Nc8UuZWVI0PwCA/TuPmjX3ZNVqUlfksah6 Y0fZuW1FI5yh6KkjRTRcwhzDV3LrK9FXe+CTPWALuPh6h6nQlSZVfw6jlWuhcbMKEAZDC2069iQD 6DJQaHadDNnCTndyuK7JVv21OU7LQlGnqyymzvza3rwmv6hDNY+ATNt0bMyPyyQGCvASaUQVyayI ipS9EQnlAzoAc4ApAAOAWmFeilVBmOlupIauKCaOzx3q4Ab6RlN11vVoS3+bORqF0VFuYO2C5IFY tk0VIImiMDHj3HO7YHuzmEA5YqMG2VKWaqLM9IPm98sfdXgQnLuNrbT8c3wr16vTCvDmr+fX0ETW b8dvh/8D7rse4WVuZHN0cmVhbQplbmRvYmoKMzEzIDAgb2JqCjQzOTcKZW5kb2JqCjMxNyAwIG9i agpbMTMgL1hZWiA0Ny41MTk5OTk5ICAKNzYyLjc5OTk5OSAgMF0KZW5kb2JqCjMxOCAwIG9iagpb MTMgL1hZWiA0Ny41MTk5OTk5ICAKNTAwLjcxOTk5OSAgMF0KZW5kb2JqCjMxOSAwIG9iagpbMTMg L1hZWiA0Ny41MTk5OTk5ICAKNjYxLjk5OTk5OSAgMF0KZW5kb2JqCjMyMCAwIG9iagpbMTMgL1hZ WiA0Ny41MTk5OTk5ICAKNDcwLjk1OTk5OSAgMF0KZW5kb2JqCjMyMSAwIG9iagpbMTMgL1hZWiA0 Ny41MTk5OTk5ICAKMTY4LjU1OTk5OSAgMF0KZW5kb2JqCjMyMiAwIG9iagpbMTMgL1hZWiA0Ny41 MTk5OTk5ICAKMTk5LjI3OTk5OSAgMF0KZW5kb2JqCjMyMyAwIG9iago8PAovVHlwZSAvQW5ub3QK L1N1YnR5cGUgL0xpbmsKL1JlY3QgWzUyMi43MjAwMDAgIDc1OC45NTk5OTkgIDU0My44NDAwMDAg IDc2Ni42Mzk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIj MmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1s Lmh0bWwjMjN0b2MKPj4KZW5kb2JqCjMyNCAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUg L0xpbmsKL1JlY3QgWzUyMi43MjAwMDAgIDY1OC4xNTk5OTkgIDU0My44NDAwMDAgIDY2NS44Mzk5 OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZD R0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjN0 b2MKPj4KZW5kb2JqCjMyNSAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1Jl Y3QgWzUyMi43MjAwMDAgIDQ2Ny4xMTk5OTkgIDU0My44NDAwMDAgIDQ3NC43OTk5OTkgXQovQm9y ZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAz NzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjN0b2MKPj4KZW5k b2JqCjMyNiAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzcxLjUx OTk5OTkgIDM0NC4yMzk5OTkgIDI0MC40Nzk5OTkgIDM1NC43OTk5OTkgXQovQm9yZGVyIFswIDAg MF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJm ZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjNXM0MuUkVDIzJkaHRtbDQwMSMy ZDE5OTkxMjI0Cj4+CmVuZG9iagozMjcgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9M aW5rCi9SZWN0IFszNDIuMjQwMDAwICAzNDQuMjM5OTk5ICA0MDAuODAwMDAwICAzNTQuNzk5OTk5 IF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJ dGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzUkZD Mzk4Ngo+PgplbmRvYmoKMzI4IDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawov UmVjdCBbMTMwLjA3OTk5OSAgMjc3LjAzOTk5OSAgMTkyLjQ3OTk5OSAgMjg3LjU5OTk5OSBdCi9C b3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1 MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMyM3Rscwo+Pgpl bmRvYmoKMzI5IDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbNTIy LjcyMDAwMCAgMTY0LjcxOTk5OSAgNTQzLjg0MDAwMCAgMTcyLjM5OTk5OSBdCi9Cb3JkZXIgWzAg MCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIj MmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMyM3RvYwo+PgplbmRvYmoKMzMw IDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbMjQ2LjIzOTk5OSAg MTIwLjU1OTk5OSAgMzA4LjYzOTk5OSAgMTMxLjExOTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVz dCAvZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMy ZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMyM2NsaWVudCMyZGF1dGhlbnRpY2F0aW9uCj4+ CmVuZG9iagozMTYgMCBvYmoKPDwKL1R5cGUgL1BhZ2UKL1BhcmVudCAyIDAgUgovQ29udGVudHMg MzMxIDAgUgovUmVzb3VyY2VzIDMzMyAwIFIKL0Fubm90cyAzMzQgMCBSCi9NZWRpYUJveCBbMCAw IDU5NSA4NDJdCj4+CmVuZG9iagozMzMgMCBvYmoKPDwKL0NvbG9yU3BhY2UgPDwKL1BDU3AgNCAw IFIKL0NTcCAvRGV2aWNlUkdCCi9DU3BnIC9EZXZpY2VHcmF5Cj4+Ci9FeHRHU3RhdGUgPDwKL0dT YSAzIDAgUgo+PgovUGF0dGVybiA8PAo+PgovRm9udCA8PAovRjYgNiAwIFIKL0YxMCAxMCAwIFIK L0Y5IDkgMCBSCi9GMTQ5IDE0OSAwIFIKL0YyNDMgMjQzIDAgUgo+PgovWE9iamVjdCA8PAo+Pgo+ PgplbmRvYmoKMzM0IDAgb2JqClsgMzIzIDAgUiAzMjQgMCBSIDMyNSAwIFIgMzI2IDAgUiAzMjcg MCBSIDMyOCAwIFIgMzI5IDAgUiAzMzAgMCBSIF0KZW5kb2JqCjMzMSAwIG9iago8PAovTGVuZ3Ro IDMzMiAwIFIKL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtCnic7V1Lj+O4Eb77V+i8wPSQ FPUCggA9vTMBcggwmAFyWOQQ9GazWHQv0tlD/n5kSbYlfqI/ii497HYPdsfDlqlisVjvKn78y7d/ Jv/+I/n49O0/yXP399O3nXpQWdX+JKr+86E/YMqH1Kj9T1Lq9CEvmtHn191b8rb7uvta//9tp/Pm i91f9S8Pr1DNnz+ef999bF++a0e+Pf2t/vS/xCR/rf/7LfnpH/Xgz918+wded2WV13AopdP6ny/9 f+pUlfohrz/X48r95/7hX3d//yH5fQ+YeSgb4HULYP+fH3ReKWPrSc1FIL+dvlpDkVZGZ3np/dyf OE07eGySm+KhQXNVLz212X49SmVJbptV78drHOTaPtgaeuOOt9/ej5/mefHMv0fPLz2Yq7T78X4e wNyDLeumb2DuvSvvHnFhG46f1nKa58UzvwuzEJ49MPtg8O3LHHge3+vXwXgYnsdpw0dLQng2qbLN pOmQnk2q8+aZdAiDM36EuTfPi2d+MXo2qamaz+mQNkxqzR5MhG0w3lvLcZ4Xz/wz4dkDsw8G377M gefxvX4djgfheZw2fLQkhOfMVro5POWQnrOsg6EcwuCMH2HuzfPimV+MnrOsw0M5pI0s62jAhW04 3lvLcZ4Xz/wz4dkDsw8G377MgefxvX4djgfheZw2fLQkhGetMtMpTQN6rsfT9r1DGJzxI8y9eV48 84vRcz2nbd87pI16vNMNAbb+eH8th3lePPPPhGcPzD4YfPsyB57H9/rVGQ/B8zht+GhpCPPB7KhA CZ+ky+e2xkxq8lqulYnOkv/+q37L10ZXj7AIdPOnD0w74rEI3s588dP33ccveY2B5PsvSQvBh/av 7y3UH2qwizz5/nPypz1Qf06+/7bbG0DdgGkGitNA2gyUpwHrPtHO8fl7t/6ZcJ1W+TXi2qri+nCd 26uk6zy7Prq2Ki2vENdW2WomXEe6Sd7OfLFZkN47csZWlJmGKerDQdUlg1//6D7RfiU7DXxxkfKj O4ceR4o9DtjKfeLReULRJwyg/nEE063Rvv/xfh7sQ8DzfJcmvrTZw2p/Tka20OTNFpaHLTSPFDG5 AHKf6BzunsKAKZyBji6q04ALh1bOgMnct3x2J82dSQGOtJ1DqzOAuJMY9wn15A4AIPCVcvWTn+ry sKBPzqnVhm6oSwP8XMNXVOEOADsx7hMuO+kwfYYDdWRTnIFjDi6GgLksKeX4AAYMLBpAd+HArYTX AsYKdwBeC8eZIhkmxdcC41lko/C1dBtwswEwoFN+GgCw9rX6HMrcjcGdgq+4CDHuGevY27nDzyed gx4CAOPswZ74bjwDtVUx5KBRe4XfoQSPGhhwyNANvxAFnQxJ02B+hwcNTi+fYxENNP3iKgXGukh0 RWYAcXLpxhnNu5Kh3CIB0JHx0K/g9rd729MAP7v0oEBtRJpJHx1QOr25P810zorynG7nCKOZhTb5 6YX9BNiBnGExwAE8gF3K35RyGBzQr3XJBAh6Ou3hW7gqLrF3HFIYoHQXwBKpFdEJDRlhZQ/i2rav 0frc8XW5QOesOaMFp4bzCT5LDI8HqonQLZD3wFGjShwOPNHlbkVxmOVcuVsXIdL0owuHuw2gwuPy gTVFLJ/bNBIYW8e2ELILXEazGeJeSSu+ZberPfnPlnG7wvmb7nZd2d15ht10p7onkuE1AbN6+N6m /K7WDSGds+YltO6r4TBb8ZmuJPoAyVyORQj6tHJlIfXu8rdgsOaTCwegkAr6iI0CdRPh2KyWC9sA uiOQAyyfbyXHukCoZ8Rh4rK6ERPM9ZcIGfKpGnJd5IfAqYAkYCvQvgo9iSKmrM1tPGHxs4nnm5ot 3NjH11KXAnf2BERAuDwESF1tLeB8vy9jkWqeMSFlCREqyXgu4t6zHLIAdk4lwCxO9Zns6UyrIbdb RpeNke8gJLkoXsnnHqpWyAiq4mjsrOTZvttHhNtT+0jEj09PEHJQwCmPUwLT5SYEj7hxswyOFJDU dCUkRlPfmgS91J1q7JCHrKy6n0uzcoOBAVlVQEbU7u7cd5NSdHnwiNMEXVwA5fHENCqYugEZwVQd LShgXnDgJcyQjTiZbkkeRkUkomPQS3v/YnYqgpPBPnD313Qvk4+BXniU06IcnmVEIqcqAI0nyHLL 7VFieS2nyozxSeLNOpm3lFMllJWxjp44i6odwK4oy0ePv+t5QmUcDhZwOOrPX8ls4CwvVVStgoAu YJ0HdG9o5wLiClwUwVumZzXB3vrs3Uu5eV4N2TlPh0Rani6tuR+e8ymgVC0p39LCu1dU0Mb4Jrj/ nydyArmDicTTcl1jDhaXaiZWV3IS3JIRsd3g9laCDhHBHv4W7oWg5zaiUGkmO8QWasjJ1iwh4E4j QAJQGnWJCKbPygiRzHhBvV47Gn1kPGS+TLHHdlwvWxFF7zwjgO4tvmW6nyXeiXopg7f5kMsEGC8A SQRB8HqhrWovIjEDXh4mGKrO8sKHVBChAYqWQCX23c9M5CM6Xdaxh2SkYWjx+rnTz3EIX4GDGsGW 4MCA5SqXMXZpzKAsnNN+Qz61rXhDAxYnUAm2TGaGYGW/jJwqvabOMrGcmapnA1QZmssWQ2Z883jp 7HTHQ8AZiig43xY/uJRTq3RI7yjup9tHMcF8npixFZ/LMgY1uhhcDAW04bjrtkSUr+v7kRFV1dEh GqEh8/DHbWfdAQFwNZS72W+4IDvPw/tg8nJrXkytaGF0F+LjzOXeoXKMfeRVOUT1ZZXSVK5DRDZA FlyNQy6iVGgW9Wql4rqVbKUYZRLIEppHCKQsSpT5bjZzWuIgR9BpQIUrr74RUD9jPMuhBquIXljo 1EdCN93QEPeBW4ERPCfCkcwJlZsjnLYjAhwSR5urdnf14mbUizlqlbDbwfQ2oxEJsdfPC2WkhTk2 2lqGf/LwL1drpleiRnR2nSfpBAgE3EoBKcS8zU5obt7i4pOG3XBzeYTYdV1H5AcEt769K/WSUiqi 6T4vuudybCOdLnyRfBnO7t5cdVlpG6/sDgiQRFAqZ0s0kQlZGy+g5okbnAmvk3K0kO9lEUfKMo1e EGO8VmiZe25Wauvyzq2t6PyaS/l2UQ0ZN54pwBkYPrwoRbDre1FoyXPIEypgddO1xXkOlUCvML4W rufzuOZKrAxJmdvfEgpmhL2xThPTiA6O6Cjhrdivp1fS9GqMAHwsdMGJbfNgT+xxO82VZjntkmZL JdrBe6tKhkhWOyaLKjdbwcLFuRtJBY53p7hZE4MEF3v87GRSeJ4Kya4IeEFL2bbykLbJrUPbX8Y3 +8yABjLkJpj7FszMgUnhtXAzLBSfwRwel9WUAYwKwBM06d98pkQIk3ocdKAtnkEQbgPsLYS/4Z7I fJTUk4UShEqHWgXc6VG3JtHEPkljptznv7XMWUnMatoGWr1pac5lRIvRiFhYgFnFoxIBWoFEayuR nbBlPtwJIS2vUsNpN3PLO2+P5AoCoM2AnvNyPlKZ85v69SKRIhrujonI/RDJN5MI5UcUqnMVDpRr GnmJya8SeK3IOZzeL2ohhh9RHwlrCQgA8Tx8nlQ/Yz6RTCOaE5t5b8bl0vd4ykgFmwVjdiVDN6Y8 iXYAmakV93ZVR0EfVFkcUmiRwGfJJFnn7oHt9tF+5wHIRe4z24qjP6Z6l+YJjHC/iFSjdUL4AVKI pt4EdKqiylpAnfXt1QhfKD9ybR0BEtpFR0ZwlaUXR7NcVwIDGlzOGxF2a9Xz8yi/QBvRCO+NCOu+ vaT6c8dBIiI9vQvdXB1hJI7h9LTZeegwopWjRFqQi2RoKYv7IiNlVOlwe88NeSJCpVIHYRYgqyV6 4vCsN7mklUtjPDobomgZR2tEZes8nte74TrxtTdluAq6XKr0mEkqUa1wW83bJMTbxuyBa0ziafsU nyjVuB1oNGyUm4Fi9Ojqk0XyOrqEhN5Ri6nyma7RrxSNDMg4QW48SzhyxiK/i2NaLvddRoJtRW+Q lGC5n+dtN9wqoFlurF/5pMoeqIKmrgUeEuSCdEP5Kdz5zn3NoVl6k3hmRO3wHMVxAckVQNzcxxPh jeABjfj0yXNCdLO3pKzlR5YUGcUxN0Gi1uHujT0P+pa9sS5GMJ8DMMK3KsJxCm+JaIQAdWp8LZyo ImTKRgJNN5V9B4lkW4/eyTDqasJ5WCTid9VUtr1UQ2GteiO3a4S4RCSkCFcrIlol8UPCE+1utyG3 VUd3g0RDbqhIi2jZ3alXvVPcOUhBJPNQBrTKPicKcve93dk5N4lxn4gABNp8A8m6pYF8DmxzvqbH uJF+VlV6SCZnbmLGU8o7UqyTAbZS0CjibpqA1oSL3Ie4GQSt1DVunaDi9edUzm89S3g+BFAU01uH K/YSznORYFFWlkNxsOiFN1arXHK/754uIlOmu+Tv+WFwzVqeO6Q7Y+j70liwKoawrhZA30p0+Pay ymQYsdHBpLloJto549S1XBZqk3rFmolE9dNWLi6Y3q8m7WkuIXa3Rrtbm/ocWW2z5PX4OX/Qqh7Q umo+5FUzWtQDZffpuVaP84eyymyqjr/Mh1/Ou3mbZ5vPafONxPlqepw3bZ4dvLT+ZQfU4ctHeJ93 v+4+/TCXV0GnumEj9tBfyLgJMwFeBN5wiDfLjBBNEmmUnjZd59zFsyRvR1Q83PJVNhE3b8eUjL0v 24X3C5huM2xFL9vMtXehWUwXan8Hvp3bw7SzpD6t490LoKG7kkl4zNUomRFeB4nlB8Qg5kiEl7io 5i6lpkoHH1kKMeGi8mJkmf4Zs6SbruVhiQipzHFlkAg73IpPhtob83ipI+TF9PSrgEvpp2s+ATcI 8ZPMW2m5QiigV8T0iPQ8gmyheNOBx1Y2eDOvhz+INAcMoEyuhPGMZh4c58l5c1SnoXOF66DTEyfn jGud843SXmKox44l2sGhC3CWGnVylho15iw16uAs3X9ynKXtL/Phl/Nu3oOz1KgxZ2k9epwXnKXN LzugBs7Sdt4FnKVGHZ2lNAM7ICM/QvIKeBxnKibi/TRFulbGwMrZwvXkIcGlBbw0jrutAR8gR+C1 /Drclfz6K7kDI5QzAUUzQARGbAM1MkWNaGOsFyNXk2Qn0uqNB115vQnXmnhRV4TTUaJBQ4Q/jHs/ eBsIGqMKOMrLiFR+fV/EndsBCgPXomF1tFmqhAFwU2HO0SqZrOp+gLW6vwuofvFP1vDp3Hsh6vB+ lS59OD+CbluMaaAY6LjXL/nKXZmi3Ee65A/at48tzOyTLDwSyLk7xtPzPhZ1Os2cu2ke3SVVDjIP 7Z3AQocSn9MkKVTaZNKIqrJZEWWUuxGZs6TufrMpAzAHuMNgAFBrx6/GiV2nVRU5THgMNJT7wGGC 84bIcQnPuEsXXqlO02FPRgzLQvUX3BTnHo5OmvV4M5QpAOdxm/ICVQAnMnFsxkvbpR1m9G4FE+gd Bp7c0/PrP8lbjQ+dNwvr/np+ja2H+5p83f0fTiNPv2VuZHN0cmVhbQplbmRvYmoKMzMyIDAgb2Jq CjQwOTUKZW5kb2JqCjMzNiAwIG9iagpbMTQgL1hZWiA0Ny41MTk5OTk5ICAKNjg5LjgzOTk5OSAg MF0KZW5kb2JqCjMzNyAwIG9iagpbMTQgL1hZWiA0Ny41MTk5OTk5ICAKMzM3LjUxOTk5OSAgMF0K ZW5kb2JqCjMzOCAwIG9iagpbMTQgL1hZWiA0Ny41MTk5OTk5ICAKMjEzLjY3OTk5OSAgMF0KZW5k b2JqCjMzOSAwIG9iagpbMTQgL1hZWiA0Ny41MTk5OTk5ICAKNjYwLjA3OTk5OSAgMF0KZW5kb2Jq CjM0MCAwIG9iagpbMTQgL1hZWiA0Ny41MTk5OTk5ICAKMzA2Ljc5OTk5OSAgMF0KZW5kb2JqCjM0 MSAwIG9iagpbMTQgL1hZWiA0Ny41MTk5OTk5ICAKODAuMjM5OTk5OSAgMF0KZW5kb2JqCjM0MiAw IG9iagpbMTQgL1hZWiA0Ny41MTk5OTk5ICAKMTgzLjkxOTk5OSAgMF0KZW5kb2JqCjM0MyAwIG9i ago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzUyMi43MjAwMDAgIDY1Ni4y NDAwMDAgIDU0My44NDAwMDAgIDY2My45MTk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2Zp bGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRm IzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjN0b2MKPj4KZW5kb2JqCjM0NCAwIG9iago8PAovVHlw ZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzUyMi43MjAwMDAgIDMwMi45NTk5OTkgIDU0 My44NDAwMDAgIDMxMC42Mzk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYj MmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgj MmR2Mi5odG1sLmh0bWwjMjN0b2MKPj4KZW5kb2JqCjM0NSAwIG9iago8PAovVHlwZSAvQW5ub3QK L1N1YnR5cGUgL0xpbmsKL1JlY3QgWzUyMi43MjAwMDAgIDE4MC4wNzk5OTkgIDU0My44NDAwMDAg IDE4Ny43NTk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIj MmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1s Lmh0bWwjMjN0b2MKPj4KZW5kb2JqCjMzNSAwIG9iago8PAovVHlwZSAvUGFnZQovUGFyZW50IDIg MCBSCi9Db250ZW50cyAzNDYgMCBSCi9SZXNvdXJjZXMgMzQ4IDAgUgovQW5ub3RzIDM0OSAwIFIK L01lZGlhQm94IFswIDAgNTk1IDg0Ml0KPj4KZW5kb2JqCjM0OCAwIG9iago8PAovQ29sb3JTcGFj ZSA8PAovUENTcCA0IDAgUgovQ1NwIC9EZXZpY2VSR0IKL0NTcGcgL0RldmljZUdyYXkKPj4KL0V4 dEdTdGF0ZSA8PAovR1NhIDMgMCBSCj4+Ci9QYXR0ZXJuIDw8Cj4+Ci9Gb250IDw8Ci9GNiA2IDAg UgovRjEwIDEwIDAgUgovRjE0OSAxNDkgMCBSCi9GOSA5IDAgUgo+PgovWE9iamVjdCA8PAo+Pgo+ PgplbmRvYmoKMzQ5IDAgb2JqClsgMzQzIDAgUiAzNDQgMCBSIDM0NSAwIFIgXQplbmRvYmoKMzQ2 IDAgb2JqCjw8Ci9MZW5ndGggMzQ3IDAgUgovRmlsdGVyIC9GbGF0ZURlY29kZQo+PgpzdHJlYW0K eJztXUtv5LgRvvev0HmB8YgPvYAggMczEyCHAMYYyCHIIfBmEyzsRZw95O9HLam7JX7N/qhq6tEP G7vu5khksVisF6uKn//04x/Jv35PPj/9+E/y2v19+rFJH9Ksan+StP791G/Q5YPR6fYnKZV5yIum 9fV985F8bJ43z/X/PzYqb17s/tT/uBsibX5/f/1t87kdfNO2/Hj6S/3pf4lO/lz/92vyt7/XjT93 /W0feN+UVV7DkabK1F/f+l+VSVXxkNef6/bU/bp9+N+bv/6U/LYFTD+UDfCqBbD/9ZMqtUqz+k19 Fsgfh1frvkylVZaX3s/9jo3p4LGJNlY/2Pqjqadu7Baq+ier27PsQTftNQ5yZbcPKe2262L7pWnf 9/Pm6X+Lnl96MFem+/F+HsDchy0vt0vSwtwfq0ybzwDboL03l30/b57+XZgj4dkDsw8G37pMgefj a/0+bA/C83Ha8NHSEOZ2t2w3v+9zH+ZR+y3PEmXztEhMaZN6wf77z3rk5xhrXA/T8gM93EulNmk3 5cH8nfY9vnr9vHn6j7aXSm1NN+z7cKwsb9gewDZo781l38+bp/9oe2mIZw/MPhh86zIFno+v9fuw PQjPx2nDR0uR8KxSXZRNp0N6rtsr1cAzhMFp38Pc6+fN0380elapSW2DuCFt1O0q334B2Abtvbns +3nz9D8Rnj0w+2DwrcsUeD6+1u8O3kLwfJw2fLQ0m2yoVKIyVeRJpspEoWiYWCxlqqqH1mlij4il nWZcgZ44bhxbE4S1WtUadj3ibpxnmdKqmt8+MG2LR2n9OPHil5fN5+95vfDJyy9JC8Gn9s9LC/Wn Gmyjk5efkz9sgfpj8vLrZqujdw26aSgODaZpKA8N1n2i7ePbSzf/iXBdlukl4rqsN8Ol4TpL7SXS dZZmU9G10Lr8OPFiMyG1tX+PzUgZtaUebaoOGp030FTujHoTeHIalHIaNLzy3UFTwCv2gJUzpldl w+kB8N049gBa6a7PeOBV4ZKFhwpODQuvtE9k/j7Sry4c2n0Chv3qDIugu9MHwAAfHFIYNv3mvgKj VO4oAjhgLkDL7vRxXQDrQB/0FU5jSFIwORgWFhueAKzTrQwoRAQ90dkCYDAs4ANWDnYDEAysC/Qx npNhp5ROderOBXZldj6HQcA8czmXgXbyIbMxdx1FYiTuX+gh8Asx2QDmBn3wV2AunEZgcpw06XIj HI/j9BmF+oyqjap63Woj633/OX9Qqa2tLlU1H/KqaS3qhrL79LpRW6O1yqxJ9/+YD1/Ou36bZ5vP pnkjcV41+35N8+xg0PofO6B2L+/hfa2t3y8/Ta2t5Xtt7YvLOdr1Ur2WL6OVE+wkxq6PwdTSgg4L ncYAnQrOAKYHe40KmyPrwCWW+wRieZrlBuBzOi6X+tCpS8zIJwFDsHaC5eagA6Rtwyk7ig/LNwgV E4ZvIbF4PrUuXF/jGwQ0fg/GIuk4pfUuxFqtkwCCcLGKw07Cyx6ZUqSt+8pCkMZQ8ASGxJx69OJu hhvTgLm7YzzB+ORpJOZXVV5YudkMPgGuYk7hM9SK0aFEKo/35a2GCU/B2u4O0+Gwd4eps9h3h+kA hT6HaRy+bZTXMRfgZaWUilT2GAP4rPHLGbs/RoNDJ25guGYMyEe+MXF5V7LbBa7rABYCso8TCPQB c+GSbfz2RzjAZuXMTiDIFmLtQNp0XbAB1hbWxd3JHGO2nYtSh0fcfWrhuBvQDvuUy23Bdjh1gNDj Ug9tjHrahAHZ/WfHMe15KsSdGzBAyxpt5eGNNq+GzBEZG6ytR43pNaTuK+7qm++s0y4yYJk4hcwq R2RM4goLdVHGkX9ZGcwCAvyc3Is7zakqUCNn+FNopqDN8YNpZOegvFFmheodNyG4EcrxMd4cQr8F 96/OFKZjVD7cELNu5lPLHYP8xdJrYr+VwCcJJIOcC/BBiYqrSCaljMv1NyOlUo807lyqRMkXO44E KYx3HWA7gAJIl06iqgk8KvxMD1QRiLHhIibGcbRgfzy6cxHow5Tq0JDlvkGqCxjgKO4rPn/rudIg NQ5xL2SF86Uaf9geILgj+IYDOqXOEOjDKLePY5E+Awvo+OeBvRDwPLcmRg7a0F+1jTs/Qn660UWs 3VGffqSyhj6BtAUNrXXVM7bBzEO7D4gcjALq9Oiiz8ErdGjoNAuunZ5y37UsTKUnJuOOq6FXc4Tc gLdMZYA2AtcWdoi3U8dkXFjGCG/iOgrsdJCe8xw+Ud95gBPvpvTgAHNEcBQLGANzdAoLZjWedGqv oXOVBjeh/hXDOxED6zAXrinyUK4Yx8oxjGIa6icI5FMRHXy23KcdLePPkKi0MeykW/LXq7wcrrVy A9swcsfdYhpitPWCqo5OnRkt62s/6+hsMb85j3+E0H2ulwAc3MkDu5fGSJ25e+V0Z1Xm0N1N6ccC RxD6wQQHOuMdUhI3+RVLgDzNr0wCtOpLlmbB/D5AaaY7QuBuXrEAEFsiZ3JRnVpn8ahGJzj4OIK0 a7IalzFo7tbaWMET48A2isdonpi2iMGXmdn5t2N4MlER4alLdP5rodx5tuUlibLxAdz8dDHgGFjA DiLEiQq8sLi4PBZZ4MwRnLVzNY3nzwJO3TPugPgujg8kZRqtxVc7IEOIh/yHqqnn8uk2EPTAqCUh Xjzkn5qyPiMzjhiypRdUgIxb7jzRCEbhR7UR5ONSk+OcSpBCync3T6wBjWo8o8a46FmOVO5OKQK6 xCkl8JbOovpNqdeeyz/TwmGgMYLAgKi484AnDaEoB58jYJHHK4XWtYkjp3KvFL4xFWotsm2agwxe YoFq4QGZVoIIT+iDB4PNks0XUKMIOxlvgwasdozwIp5DO75Gzzz7I9IRXFsv9cDtEAEQ+QQNgqgl QfAYhUNg6gRITI/8jyNkijKY7qZxlnIPEyfECMks0yjuCwUtRJCoURyOo5zH/sPOximRm2LXLewQ YLvxTkNPjDJPA1LIPLOFxQQagk5BgeI5we5cLIwCoeAw/W8uHPyVK8JYOkoasE3mlpm/ESTyTWbK 8ynVukkb2uWp1gUdhoVONQVdMix1llkgB8hImQRS6BTWFiB1yVIDjZ23p05rWIWKeep5dwUS0GPE p0WpQoLeQuqBEhS6F+QLS059+eKOzwoRFEsIqLjF8TFh7ZfZ42oux75Y5uRk1mCuM8VF3kbRHeQF 6lPjz4W7lYkjyfTeVyBIxbufg12G8AuIoh1f5W4SQTaPhwaXASDlKRHUcxYQaePmTPIDbYDDVO5C cf+c4DSOO5tBFRpfMV8S3L2uM99zmXJbn6zHlVdS5XBtOZHFvq7CPJG5M+l+gpK2vEIN5AwD/XOJ EiEaPqA0O6BwnvSAAEF+V9vPRfI8avua8xILl3PdVd/ToE/j9+lKlPaKyJiWU/dKV0S59K6TVJlf loN2w/cIaFk8KuSmsypVW4fpsAoXn1WpcmdGMQygKfMsz81ENMZZwQtKcRHEKNzzLMdqlqtNRQyo tDD+bq55TBEMyBkf1CPRViPmJhblLrpkobDv1WwHQQTvlMUZ7jmRflBdj2CMot5L2aZrubp1rTbS lMbqVaMwingo0/3VGJdnmo7JkQ6IYOZUJThj4u69eSo1XE6ML8AxT509nncuSKoXpCLNk+8pgIMu dkDi2Sw5gQESRRBcxPHBb7tcjRs2q9SQ+1/ejT+lKryIF9zOQksVzKPZScrjeCJHR20qfufDnIkV E1cQuEJlcMxCzaPYgdKGdeu7wPK+poe636MDShds3e9mfIIn0ioIM27qSrwSEVwOETdeHEZsogqR 8RezR1mqGJmWN653IQuAq6b4tcErqZByU/ezVHs1EDNZBLevdFxdu+yn8hMoJjJ9c+kAbjChT3Tp MKcuY4CLYjoqPwFqpwmcuOSlY7+5H9TUvSAU5+8JNQS+AGGTS1a5rU4UQuRnfmvxN8TIqL/cepzz +GNXcyoEcQ+zlPG5MQtkvUGPNxUlH9G6jmI5VNZbo+Oq98N113zl2vckAmWaeCBBUE0E9eGqqX+a oBpBDAH3AU94O9PyqtA8d5V8jSguDpW01mIqzBJAdzm2Q4CCAS5fqEAgYX4LeY24r5ZLJao9LsRA 0UfjZsgE3OXoIsiY0eLzqmVhgOueUnKAwc6rmQZUgOXikh5u6IiRS9WhwN9tGXHjAzu5eEBtSVCJ lRM3XyjOtzknE5RwcfExT4nUhTS/C14XQaK7xOHL4aDebEEkIB7K8agMgYousE+p8yEgyUFwncaU ga9Vta9GE3B8zC1DjlVexID7IwRejpl040mCodZVl/jEulywSn7FB9tZuvcY8INtDSdBgqPvKzxP PnF83gms/nShE7DuedJdS8O9+AFAAEwPYS2PUDUIiikPw7O0sjtg7jGLIzWOGHbxBTPpKCdGAv8u P9wRpHLPcuSOFASj8Ps4BBrK5fpq5wl4DDAteXAA12GmucEjKwuHkU+4EDGsmkylVczFE3AdHnrM 8yh4pjaKJUEOVAxbisspXrhCYOVP4WxZyD0luUXSVSpjXCsrcYIJYtUnqQcJaYbxCuyO2UBIH9QB foXRhucy8kwNOXnIlX/jj66RROIFdmVKWx/mkRL58QXU6vPcTjhKC+WBPFzpFNS6EJTLieBaw/Md QTr8PQDzZYEyxePNOJy+Kx+ACvnNYwJLGNN/BKbx+ETdKBc08GoAsKMAY8Bh48gHkzksFsbh0dVA y+OJCjOkxPZjHJljqnASWa3MESiQtNJJwLmi4LBmfB1PSUkuCWTLBAdyVg78kC/MVZstnIOsLXHk 3OLHeTnkVDfm1J+nEEHEuzkzrfNdt/TawAAqWm2Djokzq8JxZukTIJnhqizow+NyHCXu+SWpPZZQ /yYfNeZU3qCi+/P6Lj16fE6eN/8HbQVHV2VuZHN0cmVhbQplbmRvYmoKMzQ3IDAgb2JqCjM2NzMK ZW5kb2JqCjM1MSAwIG9iagpbMTUgL1hZWiA0Ny41MTk5OTk5ICAKMTA0LjIzOTk5OSAgMF0KZW5k b2JqCjM1MiAwIG9iagpbMTUgL1hZWiA0Ny41MTk5OTk5ICAKMTMzLjk5OTk5OSAgMF0KZW5kb2Jq CjM1MyAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzE3My4yODAw MDAgIDQ0My4xMTk5OTkgIDIxOS4zNjAwMDAgIDQ1My42Nzk5OTkgXQovQm9yZGVyIFswIDAgMF0K L0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJh ZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjNGaWd1cmUjMmQzCj4+CmVuZG9iagoz NTQgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFs1MjIuNzIwMDAw ICAxMDAuMzk5OTk5ICA1NDMuODQwMDAwICAxMDguMDc5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9E ZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0 IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzdG9jCj4+CmVuZG9iagozNTUgMCBvYmoK PDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFsyMzYuNjM5OTk5ICA0My43NTk5 OTk5ICA0MDUuNTk5OTk5ICA1NC4zMTk5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0IC9maWxl IzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMy ZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzVzNDLlJFQyMyZGh0bWw0MDEjMmQxOTk5MTIyNAo+Pgpl bmRvYmoKMzUwIDAgb2JqCjw8Ci9UeXBlIC9QYWdlCi9QYXJlbnQgMiAwIFIKL0NvbnRlbnRzIDM1 NiAwIFIKL1Jlc291cmNlcyAzNTggMCBSCi9Bbm5vdHMgMzU5IDAgUgovTWVkaWFCb3ggWzAgMCA1 OTUgODQyXQo+PgplbmRvYmoKMzU4IDAgb2JqCjw8Ci9Db2xvclNwYWNlIDw8Ci9QQ1NwIDQgMCBS Ci9DU3AgL0RldmljZVJHQgovQ1NwZyAvRGV2aWNlR3JheQo+PgovRXh0R1N0YXRlIDw8Ci9HU2Eg MyAwIFIKPj4KL1BhdHRlcm4gPDwKPj4KL0ZvbnQgPDwKL0Y2IDYgMCBSCi9GMTQ5IDE0OSAwIFIK L0YxMCAxMCAwIFIKL0Y5IDkgMCBSCi9GMjQzIDI0MyAwIFIKPj4KL1hPYmplY3QgPDwKPj4KPj4K ZW5kb2JqCjM1OSAwIG9iagpbIDM1MyAwIFIgMzU0IDAgUiAzNTUgMCBSIF0KZW5kb2JqCjM1NiAw IG9iago8PAovTGVuZ3RoIDM1NyAwIFIKL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtCnic 7V1Lb9w4Er73r9B5gTh8iS0CiwFix1lgDgMYMbCHwRwWyWQXQTxY7xzm76+6Jdvq+ppdIrv06paN GduVFlksFr96sEi9/8fnfxX//rN4f/f5v8WX9ufd5426UWVovgpVf7/rEkx1Y43afRWVtjd+u6d+ edo8F8+bh81D/f/njfb7B9sf9T++dKH2339++WPzvul801A+3/1S//ZXYYqf6/++F7/+VhO/tu3t PvC0qYKv+VBK2/rPH90/tVVW3bj695qu6J+7D/9n88+/FX/sGDM31Z553TDY/fOdDqW2vm7UnMXy 89ujbes7YcV+7zacxJ8vC10aVxalUYX1rvjf75tvdfejdB503fm2bqHUVaGxa69sMLr0VfT3btfW tl25Qusy+N0fup5y68r6ifqrHqr2Kuz+2E1q5bXbT7ChdLO9MS39tZ0fkfZ3avGtw3Ow7Vf09wOe D3gzplG4p8O+vC33/FDeDujdsby08yPSPuVZSM4RnmM8xOZlCDkfn+snQu8j5+O6EdOlQ55f4C8A GKStWVdLxteirGG0XkAv6+YhD5n0/rvLTEOJINPziQdvHzfvP/lCq+LxW9Fw8K758dhw/a5me2uL x6/F33dM/VQ8ft/sgLglmD1h+0awe0L1RnD0E00b949d3EiD2ucTD+4HpF2orcHRIYX6j9KU/pCb irIHAzj1CZ5wSwi6ogRFCYa2cZferXsT9fky2+pxZTYRQVRmVYKewYTDUpotwQjKzKoEPRuC4G4l R6MTNGD2+mztyHNTUlT8QD+xlRyem3q5Am4OuFynh9p0gqZGUH+kj1ACGFIwtSpw3Rr6CeMFeqGc GuoU8GPJcQokCAu2VfM3gP4iHS0ehSQmghoMRRdqazCSGgU4gDYAp4BARwsIAosd1jZiDLTBYgxG IoBTlHULRpiFxx6zn07QMLfLUf4FunrbQUNkVCraRg9bxy7UiwLQlTBPAq9BANPg6AGAQpxDcRtX A0D9PSV8GsNcyKJQGNYXojNjqcwkooe5+EKx4PksX0gEyEFAoKnpK0YiIkMHi11C2C2vlovxhTS7 PNBppRIbKYaVRCGnRt4umK0lWwkrYdWgiVDIrHkhOV8IjI6AL3Rdjj6KkLbBZ8lFfCEY3HKUf4Eo ZEX3yAbZ8JJodLl7ZCthHoR1j+yYPIRQqBQtRBjEYKxWaCVcBMGBSzpKt23mSAgw/Dl1WBm7yumN 9ghJZqIQK2ElzNH0icY51ephrISVsAJGX8AIkpXeg/hcsBc3m/lfCSvh2gCj1AkexnKSSWvidCXM kHAJgGEusgwF6sUg2yKw32tgO3Pd7z2U+mL2e8chuIlOVokChhu0YmSiw3gLgjZKWA8OkbFk1E6v hAEBY+x7MS7a91sJK2GGBFHAuMxLYSAkATslEZLAJzJCkgwCG8WAd4AE9pALf+rFAB8QTkAvvPe4 mPhiOYQ2EhICjMu8EWkuSU/wuGlCwrBhraYoZCBDIREswLEwaCMjNIL0Cx8JAU5BgmYc4Eq6x0hF 1lhpdmvMu23bqm361erEVDUyK+PKbRuCo+bRURF17vjrW/j91kardp2rBT8RAsw/ngSoKB/AKTRK u0U+6HrAXkCE95QAqw4eYUcLSoUi5BkDiUUuJjwlwsYZCHQ9nNAP8zH5EVy5sPojxz463VJO+V5w 5njFhVwKtAFZsJIKGeYl4pKe0mR4BGYf1j40Sh9p4TEktAEq1UPI0C2vhaAf/CMgDxal2gzniUb5 0QJjMU7Pxf7KHYJ/j/GymgrghyiUVNbPGC5v8ucK55sHbmiDCqS9MuEEkqNA+LUMg/uQIMPYZb2m tHsZBmKVOwjRIJWPY4hVVEIfKYEKRMMNwNAtFbsDhwIeCcdhp9NLOD5TnU/ccqwjhN7SRmH9026h DewWtI6OFq9IhjYoHz2kTidbQ7e0l9b1CbRRkbW9pZvX53mLhhLAbQOjC6ZsOc5h3yOvSe6BiNUx pSKzm86Jpou7h5jZhNwg/gCvh6h2vA7xmjrX4KANDc/UIe/3KlS6QyvU4Yw68lYEmLRqOvZBEpl4 ZQaTkeExZKx36JaNQXOQaZplJwH/mOXmvX+AIRAhG1CCwgySGxBxqPmxwOyzAQW63CAPnjF2svnc EfBhA5U6r9rLiTh4/UhPFsRUSgimKxeTCCoVz1qkqO7UqoPgKD2rh5rKJ3rY2QUUwqQEjDYje/SB MjZIGniu5nMqJ5W12nwbs5EpLw++F2gUPHB2LLDUe6SjWdNn0y+UynHJI4HfuSG6rw4hFpOWYJUB yQB0KPNG1GsPL157D98PmIckLbSRET+le8vj7IMgYxme3TSeboa9tE0bnT1PQ/d42x3tE7Od4Q5h gAHWD7ALBDKOH39V/lOGD26AU/aRHuqQkV1MH0tveDh7t2l7iMIjRwOVfo0Glht04dZx5ERFxw7D 1jEfDLOubAZkIGNso703Qk+5kOwjOFFsvr3HzKUn4DGJySMmn17ilY735GmjbTI1czuSyepWJsQE AlUholndyr0ChEBYuprMEUymiJAlQko2XJhLHvy6MrI8xqIW8lsag8zLYnwSWcwtQ4zXsfxSbR3h JCPrAszDzhBfrAq98JPFJ/L4EBPUKkObeaBeoetcEQ7ipvYwOnNxQsfZJh4l8Z2zUThgOCUE5VsX 1ZBxUt+SQUgVD0IGLS0J6lWKtJ8e0TA4EY0UdcoZibUy4ILBfJSkTI89ijUnzcztXALsmWzziFqq oJNT0PJBhyacLCb+GyknPWB10eT+X070vxy7fV37vljEwB6R4nNOPSIofg8f5pI9VZeh7Bkpt94H DSYrHAx26lBmkCicdZdFTg1MhKDsRCHrfAZuiGPaPFDFttcGLqRcoZ0KZLYlnnxseAXRkhDWuxCb TOyYv9RplGo8bIM/d7LcksfluFwZ54GWHLRM5GAKpnmDj54gbK896lgQ2Tzv9hKOEE7jHY9jIEeq V2PzHBJXv+CRB/7GGdw6WLO4vfySybO4OduLcmoohI/BMf2cMMzDnGaTSfx6Mrwcn2GcuGQuGcfr QohBgpCMqBwapYPjgUnwzhFhh5kPICB7xNcJstvTPcq1Ms73wVjYZJFtONU6QYaS4O6Veo250csA PwwMz6TAdK4EKnMogYl86HH26KeKS66qLJw/N9ZjtKvlPttyj1OhIbcVIITl5tWTnculAZNm6c+9 HU2pQ6mum/bEeRHZ2UmvtunhzGaUrMD4I++HO5VAn8aHvjJwHyIs468CbOUhhNT2xefMsTvpt6jk eD8ZUyW3HeBV/EJBQ98+ILkb4JXohYJXtjTXo6epUr/kszU93i3A6mmPw3qA9nOV+pWBgYCdlrx0 yqv4HYQ5lSD8Xgh7Jijn5M1aSXx6LDJByVyz9D2StLhHz19UNY3aXVb8OJc1NG3BtlchWsQ3ZBLq XOadO2Q+I5QX2TFiS/ZjZ15T8pKwqjCCHMVTW08nytu/+Z5OhIostjSkR3kJvyUzxJG4YfZ55lUp J2MOtI5nz+XK685Gf8qrRIDA37Ersf5ZGEYCrWrKuMg2Z/3zhY+8G5qxWSqhZZ3E5quO3RjVfkV/ 72pgn89/vvtlo4q/ClP8XP/3vfj1t5qFr13FTux0r/ah0OXR/a1G6V+jYny7LHUkDGBp+idwxoDQ tNGtiYF3W0XQNVCNhZeQeap+kDXv6AG85zVyCA0WCtxQceLNJe17b7vDhbITeBcmCAR0OOJsHOow 4GRD4fUwEWD3bxHzZqeHDTPLLbTvkdbiE0H8YUaIavveyzB5qmicU7gyB8YzCn7B3oJLOtfq3QW9 7izjLbQwL5gpAwnx593g1JRA+f58KiBLrw9xOWPtoojuRFhrLIZNgF2Y8IwAU6QKCnphsytrmoOT esb2y5hHUcZPak9fed1Z2gehiDsaisQ/1cfb7NFBgycuRADFNfmIN0QBd99Q/QCCBoXhi8ZoLwrc A2gUuqVxCERqBtqIuFgpBNyNhU+wdtrcH28UrcP5M9yaDOcP1ZvP/AFSnxA9TjBoDTiVtNH2E9OE YtpSMWXXwnVsfsa2ZA/Xmk/u8rXBfG0c7wPI3TZwplfkgj2cvO47fN+SRGVov1CpyL/1yDjFG3t5 o33kdE04fLe0hiTGJ2o6FTWdir5lok0neTq/8NpzcNmp5HPHZbZk/ThNWHLNVGvYk4EkUHeknrIN wmjnGlpJHZlxNjI260qCDcfrb3JlZ/fvG++0316T2BlSoPN7D8Kk2ep2+6qzIwrZsVJYUE6rQQXl NJ2IkgwJ3r/CE6ANvE6XEkC0zryNs/4unuvRar9nu/3x5SnXpj0UD5v/A//vdA1lbmRzdHJlYW0K ZW5kb2JqCjM1NyAwIG9iagozMjQxCmVuZG9iagozNjEgMCBvYmoKWzE2IC9YWVogNDcuNTE5OTk5 OSAgCjM5My4xOTk5OTkgIDBdCmVuZG9iagozNjIgMCBvYmoKWzE2IC9YWVogNDcuNTE5OTk5OSAg CjM2My40Mzk5OTkgIDBdCmVuZG9iagozNjMgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBl IC9MaW5rCi9SZWN0IFszMzcuNDM5OTk5ICA3NjguNTU5OTk5ICAzOTkuODM5OTk5ICA3NzkuMTE5 OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJm Q0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIz Y2xpZW50IzJkaWRlbnRpZmllcgo+PgplbmRvYmoKMzY0IDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAov U3VidHlwZSAvTGluawovUmVjdCBbMjQyLjQwMDAwMCAgNzQ1LjUxOTk5OSAgMzE1LjM2MDAwMCAg NzU2LjA3OTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMy ZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwu aHRtbCMyM3JlZGlyZWN0IzJkdXJpCj4+CmVuZG9iagozNjUgMCBvYmoKPDwKL1R5cGUgL0Fubm90 Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFs0MDYuNTYwMDAwICA3MjIuNDc5OTk5ICA0NjguOTU5OTk5 ICA3MzMuMDM5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFy IzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRt bC5odG1sIzIzc2NvcGUKPj4KZW5kb2JqCjM2NiAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5 cGUgL0xpbmsKL1JlY3QgWzM3MC4wNzk5OTkgIDY2NC44Nzk5OTkgIDQ0Ni44Nzk5OTkgIDY3NS40 Mzk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAj MmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwj MjNDU1JGCj4+CmVuZG9iagozNjcgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5r Ci9SZWN0IFs1MjIuNzIwMDAwICAzNTkuNTk5OTk5ICA1NDMuODQwMDAwICAzNjcuMjc5OTk5IF0K L0JvcmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVt cDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzdG9jCj4+ CmVuZG9iagozNjAgMCBvYmoKPDwKL1R5cGUgL1BhZ2UKL1BhcmVudCAyIDAgUgovQ29udGVudHMg MzY4IDAgUgovUmVzb3VyY2VzIDM3MCAwIFIKL0Fubm90cyAzNzEgMCBSCi9NZWRpYUJveCBbMCAw IDU5NSA4NDJdCj4+CmVuZG9iagozNzAgMCBvYmoKPDwKL0NvbG9yU3BhY2UgPDwKL1BDU3AgNCAw IFIKL0NTcCAvRGV2aWNlUkdCCi9DU3BnIC9EZXZpY2VHcmF5Cj4+Ci9FeHRHU3RhdGUgPDwKL0dT YSAzIDAgUgo+PgovUGF0dGVybiA8PAo+PgovRm9udCA8PAovRjYgNiAwIFIKL0YxMCAxMCAwIFIK L0YxNDkgMTQ5IDAgUgovRjkgOSAwIFIKPj4KL1hPYmplY3QgPDwKPj4KPj4KZW5kb2JqCjM3MSAw IG9iagpbIDM2MyAwIFIgMzY0IDAgUiAzNjUgMCBSIDM2NiAwIFIgMzY3IDAgUiBdCmVuZG9iagoz NjggMCBvYmoKPDwKL0xlbmd0aCAzNjkgMCBSCi9GaWx0ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0cmVh bQp4nO1dTY/cuBG996/QOYDHIqlPIFjAnl0HyCHAwAPksMgh8MYbLOxFJnvI349a6g91vaYeWU2p WzNtY9djWqKKVcXHqmKx+P4vn/+Z/fpH9v7x83+yL7s/Hz9v8oe8bIdfWd79fjdusM2Ds/n2V9YY 91DVfeuX75uX7GXztHnq/v+yMVX/4u6P7h/3n8j73398+X3zfvj4Zmj5/Pi37qf/ZTb7a/ffb9nP /+gaf9n1t33g+6Zpq46OPDeu++u38V+NyxvzUHU/d+25/Ov24X9v/v6n7PctYfah6Yk3A4Hjv76z 3XtV9VDk7iKSX46v7nrfMsv387jjKPqqsuNvWZusrJqscdl//7X52n39+O0qd60123/1/Tz+tnO7 bxVZbRv30MnYbNnuinLLyzwvu/a26lne878yRUdKbqxst3X/sh33883T/1Y0X0c0t273y/vzCc0j 2jqhb/sfaB59y9lBFyRtp+3HsRz7+ebpX9KciM8emn00+OQyB5/Py/r7Kd+C+HxeN3y6dErzzHOp 7pq6uZRndY1zaQ9/LYBB3HeKopu0TeE6GM1Muf/Okw6ZTP97TMzQ4kGml4kXPz5v3n+qso7rz1+z gYJ3wx/PA9XvOrLLInv+JfvzlqgfsuffNlsg3jXYvqE+Nri+oTk2FPKJoY+fnsd8joPal4kX+wGZ 7WJwdkTVdkC2LvfE/NQTU/rpN42g33yUI/xRvmJYH/CVopZPNIIw80jpcEfG6jlk8oFF7b5bW4jv 2E+S+LJvMPmhxX2SLfaj0BzerX2UneQf+pZCKtexoRieaI9PPEpZ1FKF6/N8BBUefWUQsDETA3Yf JSVGilh2a6poSrhmgSJBH/iEVOjdK3LKPtgRGBdnwdj/VMjUDvjAoMxF69HmbhE61WbksZxGVj5h 7BUBy5XudAC7OXDhLB9w0HVzfTfGHyW6wDT5JBsAKSXsgWIhyslOTZsQw7bCXyGGIVDYeFxYRJ5I ukeeE6QHfAU6teyzyCBY54F0WCgAWoHJfHBgPEi5IGEwWroqIB1cLsD1EcTrJ17RlKcTLylaucrL NM4SUBHeB8iK4xnYEh7xJgK48sBngC8joQhgBeAMO3EW4KsSZo37IHnAAU72cZ9qCsOgLoUKpJxq VRXOVnB/ZnVMXLNOnU+xqKeTxZQCQx+w3HIPIn5wuP6CCQOj5RhAgYUvA04Sxh1G/Cy3nF6z+QF9 QDAjDSaWO0xsZsHE1ouJKF7QGXgiJSYWJtzRsRLMEAExvIEt0C/CJvo+adwjsB48C+wUpAEsSoEp Zj181uZST+YIRsErPCaUcMamXQSu5baGRsBGlA6fNc4v3ABLkONGqDU5FRJUo1OMgvDAoykk8sAr HlkmQklbecersFeuajhcypGmEBwBZII9DI4ZYFxQuMMGUCtuFpbys4sY4ziJQLpcywBmuDlG1xQe P+MbVpp9Bkk6rn6KoByFv4AVA9bHeLtZs9gB6bTTZewFhGGq/GlhuDBe+V8njMe1zAKL0lk/F3LV 5k5wNd4eBCaaD8xkQI4ksMOSoH8C425FpuwygSfqLuE0BMmhwcy3quNXDNh2N8MrYxczYKsPInxn PNUE2/fz+G4Qr/OYGYnwvKy8akLBmRsJmv3BUPi+lAF1IxjAw2tgetGQJWAx6ggASbw/dytx0GDl LSeky9c3Hs14zfHYpfaoykIgRJp4bGn7XhuRlbjGhIllDNwk/kwCCEE6YHLTDXS+CxQQ/pUuEEpO 4aveiJ2pSUcFOmC0YKhwryoel86kXMF+BmzgKmyqFP4eDZihpNASBeCSDbijrZh113GifXqYBvzb Vo86s2RwWyMFQ2GIY4pmGwa+ogAZTliAN8dDynxZgrADD3/C5IaFHAgDLsMrfI1RoD8323mEEPoA fsyy1K8nxpTQ4ixtvacMok7xcxsdLOiUx1AAyrjqBgDVesJfr9qeXs8kW2ZDHWO9ClhWqDINSfB9 Te6CpDBKr2Vh3vBOd1nXp9C9kHsg2QwB5V2gOs3CVNh9rzmVFUwi7vxRm4KDe4CHzePpVBE5ZChs zoDPJohiKpYy7tgE2L7UoUBvicdouIPF9zm4oLjXBrgsR+uMIN1F5WV6zx1W7XZeVvlhUxbUH2iF c4gew22iD+txhmDpHjWAln2QDXzzz6Pco8FJwCzgFVBM+YrxhIImKN0ly0z0AV9xwDHJICcZBHRg p9TjDD6FOnoCFjJ4BZjsSe2f4BgOHxgkOwXScfhSDLvTl6MnQAuB6zBaukobwG0YHPQBTJak4wSi GsT1w0qegtLFbeEynDKHDRqKMSkagKt89oO4EXQ4gkAfXLkBLyn4oTEMsgOVkQ0IKTBjZKegurkc LbxSAJPpV/gry6BQAGFgUMATQBgcT5DrGMqFjkVDKV8dJGEpBOVgVsK8BRCGJ6BBIjvYKE5OMQez skmJdS7cJoPxooVBlwM484KWHzVKENpkp/wV4OqV5gPSEartSVzlqrWncrgngfvsp1tJAtekRfM6 FPFnYG4li2KhA6mKDS0aOUY6eMEExclhHo6dheuKrQaezHmzqbdzRtIuhfq2OMV6RWZqQITKsy+S ZJ2q89orzvijWfNAKM09h2SdhUoJ3AqELnMEiApqmR3fuy20gC2UhMkpUuzpWc/r2lOXYrAzAoTf QG5rmnXLWp9GKNYtHB04iwmO0CssmYCaE28LDvnZB9BtvjomIAw2xDUplfQsCGamXPVI6T0nP3wC pVkv8uYU/DRaprA4FZmsfNbxk+weXU6zgDi/4wPRRu7WweakwsCeJQt3xWnakDSRMsm2rva12d3A olHRKY0py9fl1axlCn/ydkGFhsLuXivpYz1e6z0rW1C6mqzsYI6lwf4m6cquKEYeX+RqoQp1azvl N+WS3U95Sh16fac80/qk9xObbJla1BVIA/Zt6fvu/ZQngbL7KU/R6cgBPd7dNr496PzPJxf4BDzP r/eJ/Gg/UdrtjXDnSrv11VOag0OM6f1yBxazZGGPNn4XFxuGr4wd80FTWqp+cDHXqGGYSpXUJZhK I8WAPFHPWSZY0SHM2PqHaxsYLmgoKDX0Sr8LfYwt68XvnRowujnUPL/ZrfxXHb9GbOTJPhQsF/KT 39R9DvdgFeljPcGqgGOWPItRkevgmchJbO32cEHEG1MhXhyLxoQUQYGAMBIPRdG4kkLZA9Qw3l25 lcJnC1UYSZE/AGcg+Fnv6+QPrKj2xZoTpUNn0MV50U6sBouG99vDdROa23Xia7gGoD8vqBSw6qSI 71/p0rVXFFZe07bCZXmtK7uCu85PJz8eK4QDf/RYYUBiKD2GjyBL60dABA7PTHos/5gG3KmAJ+hi B0c1fSvZRB/8MCcW2EhR2KI6q+rZgnGv9lBQSVHJJ+RqMAkAcWVnpi8qbOuIBdDjh6S5GqBtDqFr gOJXfgH73c8OU7SJTjUbQzzcozincqu3Jb4xHVsmHJgOHZJgaL21tt6kuOeAFLzH9szVP/IGIRQ4 zbKFIovoVsa7UQEzQiFu2B2iNfMC4ltgNMVHTZJEJhUJ07NE//lBt/gY6hkzk3MIYsi0bozmLqFZ IhNcMPwqOI9Dkwipzd7aDcgsUhQqjb8ZO0RnoE4QP8qGnUDUBB9548bLHKtZwDkMAGIezw4QtyI7 goYzoQoaxjgUCIiS4Vqm2LtVFHrgnivMZvCQ0ZzBFujXWdkN+sjhbnQi6HSHbtW+96WUOHdKyZX2 F2cyUVHqqE4Bhq4iI/Tu+d7m4oHgyRmSQriKUgo82Z8n8M1SrGienJ09KBbeBPm7ui+yJljbCkEo HMpZrvh9W5P3nl05wyy7TnblTOZNQD4dqN1jSqyukmrirRSwS5DpuPiF7Jdifm2FQBWXmMN0jL+5 CgsXQdZcgmoYiptaAjJi4k/aYUkRrouKKq80ysoFpagepqg+GnAEkB5zQckpQvszhsMTIW99iLpC 7gmt26WJ1CsOPMfbVQpsfoXWyqVQ3tRCQ1J4Fvf0kUTSnfuYRryvhgjCQVZR1PL1nZdIBOWtX3bx 9n3AzgYEeCgDFBV6NRry1tOyk+wt9NmQtckP6M8doNDN7zT6bqyfJddLj+Q4OuPRhBXmt1tjToWZ 8Iq46+RA21KMaEWHrZBUcJu5V5DAgdNfHxGVz5TC95gndl4UjZgWV6qc9qYs6WtFDlMmAxgnbqO8 zJOiuZm8UoWmZBMvK8yPPCrsQr4RGn+MPGA/CkwCWq4xJEXsxr2e1Prfnz2qTVXsJQOaGl+PTqP+ /FAsD+jet+zSg/u1CqLciDd6r+9LBKU4hqQwU2+sVsWlmFu6U9BdUcULfaXZNAtV3YbPbtg2mqOi a9wp2umLgmvrmlMuNpKtI2Fd9WLkCcLgVnAH91ODngGlEM8A2cGRdjg4X6WUTDdnQyVTwDl4sGWW qRwAnQLpc1wT7wv4TTQsc4H7+q+jjmEhXK1e8PoV8YUTwLU38QwCriMLwUCSiouESXVwUk+hoYBj C8BCqAYrR1tIiC1gesDgZB/wWQuzMim0VeGLznoaLKhMuhD5hPqDdB1A7Ojmw2MJ57Ld/QIZyn8L qAft76xXiMoXPs37Ul3O7kt1wXEgAxWVYakbWFZJpo5sW8i0bGSDTMxCU7Y6/4ScEFpO2LrtOVHe HCfgCcmJXWLjcrwqhgJvrlkfrzxXC6g5UfQVaIqyujFOgE44qJ1O1WisNd3v7KXjmKn6oe/++PJd u234lD1t/g+5bV8JZW5kc3RyZWFtCmVuZG9iagozNjkgMCBvYmoKMzU0NAplbmRvYmoKMzczIDAg b2JqClsxNyAvWFlaIDQ3LjUxOTk5OTkgIAo3MTQuNzk5OTk5ICAwXQplbmRvYmoKMzc0IDAgb2Jq ClsxNyAvWFlaIDQ3LjUxOTk5OTkgIAo3NDQuNTU5OTk5ICAwXQplbmRvYmoKMzc1IDAgb2JqCjw8 Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbNTIyLjcyMDAwMCAgNzEwLjk1OTk5 OSAgNTQzLjg0MDAwMCAgNzE4LjYzOTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMz YSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRv YXV0aCMyZHYyLmh0bWwuaHRtbCMyM3RvYwo+PgplbmRvYmoKMzc2IDAgb2JqCjw8Ci9UeXBlIC9B bm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbMjM1LjY4MDAwMCAgNTY1LjAzOTk5OSAgMjg3LjUx OTk5OSAgNTc1LjU5OTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMy ZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYy Lmh0bWwuaHRtbCMyM1VTQVNDSUkKPj4KZW5kb2JqCjM3NyAwIG9iago8PAovVHlwZSAvQW5ub3QK L1N1YnR5cGUgL0xpbmsKL1JlY3QgWzI4Ny41MTk5OTkgIDI1Ni44Nzk5OTkgIDMzOS4zNTk5OTkg IDI2Ny40Mzk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIj MmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1s Lmh0bWwjMjNVU0FTQ0lJCj4+CmVuZG9iagozNzIgMCBvYmoKPDwKL1R5cGUgL1BhZ2UKL1BhcmVu dCAyIDAgUgovQ29udGVudHMgMzc4IDAgUgovUmVzb3VyY2VzIDM4MCAwIFIKL0Fubm90cyAzODEg MCBSCi9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCj4+CmVuZG9iagozODAgMCBvYmoKPDwKL0NvbG9y U3BhY2UgPDwKL1BDU3AgNCAwIFIKL0NTcCAvRGV2aWNlUkdCCi9DU3BnIC9EZXZpY2VHcmF5Cj4+ Ci9FeHRHU3RhdGUgPDwKL0dTYSAzIDAgUgo+PgovUGF0dGVybiA8PAo+PgovRm9udCA8PAovRjYg NiAwIFIKL0YxMCAxMCAwIFIKL0Y5IDkgMCBSCi9GMTQ5IDE0OSAwIFIKPj4KL1hPYmplY3QgPDwK Pj4KPj4KZW5kb2JqCjM4MSAwIG9iagpbIDM3NSAwIFIgMzc2IDAgUiAzNzcgMCBSIF0KZW5kb2Jq CjM3OCAwIG9iago8PAovTGVuZ3RoIDM3OSAwIFIKL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3Ry ZWFtCnic7V1Lj9y4Eb73r9A5gMciqScQBLBn7QA5BBh4gBwWOQTeOMHCXmSyh/z9qCW1WuLX1EdR pUfPyMaux3Q3WSwWv3qwWHz/5y//iP71e/T+8ct/oq/tn49fTvFDnJbNryiufr/rN+jiwej4/Csq lHnI8rr164/TS/Ryejo9Vf9/Oams/mL7R/WPlyHi+vfvX387vW8GPzUtXx7/Wv30v0hHf6n++zX6 +e9V4y9tf+cP/DgVZVbREcfKVH/93v+r0mVaUVL9XLXH9l/PH/736W9/iH47E6Yfipp41RDY/+s7 rZVOiqpTM4vkl+tX297PzHL93O94En1ZGqlcF2mUZnGURf/95+lbNfh16Cw2pVZpVjh/7g9tTDtU EqlENwTqiusmSc+sjONqtMTUbK3aK/ZnKnlIKsK03a7zB922d/18d/R/XplvPZpL0/5y/jyguU9b kp3JaWjuj5WWZ3KQtkF7by5dP98d/ds0C/HZQbOLBte6LMHn22v9Y9juxefbsuGSpSHNC2+lQpdJ lOZZZHArXcCvBCiYNkxSLUqexHkFopFKL+M8heGSqn/3iWlaHLj0MvLFj8+n95+zSMXR87eooeBd 88dzQ/W7imxVRM+/RH88E/Wn6PnX0xmG2wZdN+TXBlM3FNeGxP5E08en5z6fpwHty8gX6wlV06mU w40Zpfo8IaPLITG5PaGCTijpGtRPVh8qt7n02W6wO1XKHqWoG1L3sEnzFaW6FtMMo+Jry8e6pbSZ n7u7BVq1zRGk9Se74ZNNPGVinNNRaKewEECYx1zs6auYSbgq6eQ46YUtQx8Zk4F06MNDdGGUR8p1 +xOqGUWNSDcKM3zCHgYn88FmKnBZYC/j/G25xLnAKHw7cCEDOmBYwBQqIBy5sA+QbQcLazifgctF MQRmXH9gAOeqzYB2+8+ltdEhlW50kTodQzgM4yiwmqB2AGW0PQrVMhyXuYjgsHSlAkBWZfZXHqmu 43s5YBk4lHPFBcNyFkIfi0DIKii8kUWFa8uhHbaHTamHdWAvlAa4gGFh9fn2QDUNmjylYuhAVHF1 oMohxiKtsMtg8WBpgAO4MwW2CEcInIwNXVzOWkplVFnaaV05g+A6XRRnmD9sb5guxwwBLXwYnQto DL5Q1BlACaJfgWHBFVbNV3recpzaLTc86g8WKfoRuoEZw54BrsG+4+AlofE85GqVjSekNeJ8CGfI ZzCjODYDvlOzch3Aw73Il5tas1yLeoPmMMD30BwcxXXc9vbPg/Cfx+d5cHDioLV0lefw7A3h0lkd Cu0cVA1gaesKDVodtAkAQ0AfsMiAfABr7b7IRhoeLbTET4DUN3LQi0eiqIClq+xh7HGV/Qnoox1l y3hyknUT+mjvMI44AhjMA4yG2xh8Y3MPCmYLwwIEgcPEPWzYNgHoCXMBA4qbaR4+VgDiTne62m00 JmS80wClRb1QD8K43SrCZe79gkSgUcajQ77+8aSzARB30PwBRyNLmPZoLuvEZogNkIuIiEf8TMbi zNIh/osY1AtGv0TiBUmeeiNAiJcyPfgZ4A+GRHY3gvdldsReFICE+XMEUMZJv/MAChdehAi6nDd2 s1AUIrVAchUDH6WCx5CBJWAlcMJAfhNbTOjZngd6OQI5MuqsFMUiPjtooLLqAaM8bkWPiBbKKDKa 44RHXlIAxoPUBHgBAQet6NJCAz+a3otbsIi+huj2dJWmPth0QHCJEuYdMZ+JM0laMKDh0QcJvm9j BO5XuDfyefsR8rnaK+2Sc3cbe3zVpkmIx8vdd55DsITbhJEHynUPh3evweol40pHeN9p+vAwy3Rf LoBjPKMoPNVnLrDnZojsyIAAoeI84506nAwZRWaMU6qOSJzF98MIe55rhB2hSfl12Cg0uVJ8cEmr bHbCrBli6FYp1AFJ+ABuNuxwHApBbt+lklFuSeEtiTx8xD0bCQ7d0+UwifQOAbQPMMNxcnTHeGRp e6S6c3SXSDANyMBcJyaxc9tmbsQxU0PYCQpTBcRtV0fmHocGKZ5J97OVBuj4lE9qoMcAzbIk5bg2 yMyQX7AIIw0KkAxkCpJG7VEw8RQ6hWFjmzCIt0MfjpDDlAboQ8MnqJrSnyiAQKeO0BgA2QiDcBlg bcFagsy+7KakR6sktxqVWdIqEKoJOYMzIpZY1sym1N6q2PukdiZlKq5Jy+Lcic32Dk48Ui3Q5aXd 3kjG4AnnmW18BlwRoWqC327mhMHhtbY/gSxzKMWZK25MMVzxdfIIlqwAMIYKlFJnMo7wXaW9Ol8y CKeSBkeMOz9zlVhjktudrnmAMZeJRcPEtOtW4ornTk5w7jrrlR4LiHA5wA/kl+93G0qRuDriEWsE x5Gfmgdco6fx6VXxUAiHsnT3QrTODdjXJKp3hBA+CkGiAFzw6fNYp/wIn2a4rHRBSdR2KdykCWQO eBi8vqXoZs5Xp2o4X58qN2DhiwQxuFEgkvR3MfHLzsTnhRP3cgRNWQR+w46vwrVbLVddt/db+CrE K+BFQPmwdyOYIueLe3EBA9ToXhZq51UxhSBFu7F9o/M2X3yQUedXBgRZtFTyllXNeeLeaUvkV6PS XCQjXdKnzdNOwleJrb3qCwgh3sfbwvNtkhKX3Ibz0Hy30WpRGM6dpHnk8cNXIB2C5lMhE2nsReIg ZZ1K8kgYVM+x09hcZZCFVEohqlIOgNwCIH0TiBb2S7eCA24/QEYR9MEvZPEXLwSO5mQuBrV7u4jf 6L7czfMMJi6thbg3z3T0+GL3PmWh9pbRgWYGF9ZFDYDCdN3ecb5GQGqB3EKM8WP6PttvxTHuD9gP IXCrgrv2a9XCfJXnXUXShQRXMVbRv9lPsnCLd9eak4fDM9Ww2uiaKg0Acez2OO4NSPEICDMFnCJx 0kHJAhAHvKUkoWS5TuXl1ni9fl/RFkKQrkIhJnRwO5sXR+YpTlQO+a4LEH/Xcs89vCqTIVcDHmhY JnMee+WvVvH3xnii/Jp3AXdoy4vaPyOl44C0gMu/PLnQQ5nTKodoVU1PXuJOAyeMP8Dlum0kg7xl fASrPdXobmy3gEATfdTJw4eYru9Cio1O34beO2YSuPMkqulJwVhORILSZYqFXPBBb627+FnNpk+u zDbVbDbvRal67FV7lAB043caeVGejaqn+Vwf50defLk5AE6/SbBqdRQhJDLrxt2EjObmPn3ZFS5I mm7hnbExpRAAowLlEaRLit1XeRRVlsOFg4IYuNuhwXGTapsaGtpYM7rnm1/7fiBgm8t/QvWajIVY HvG1ADGZHhsNqb3Gk2vBZ+HZA9PLUCzzuK1jXwlprPzyvGjSdKv0dZfA6+zAEshKgjcS4LSUcsAA WwEVAkhNQJnapGpbaNryUiNlZkRIxXGhJA7SaheYgro6MnZNU8GoLBN/CJ9eIybkPgHPQeDhJFCD mx2P1HuxqITWqY0UrK+tnrBuEBZsQrUHBYvsx7IkqjEhDHo8Ns7dH8CagBLsIGmLhJ32WxYqAdHj So2emXpEd/jJHI86cI29SKLp9GLBImFph/8oBD068ebZSiX4AnjkSniaHZnILR5Nf01qmQu+9EUJ DzM34D6vhJm7UbVwall4JADw+mw83VGgwnxImiH3abj3RW8ABGSmbHVQv4Q5K1FoRtLHK2JTuoj3 uB8scYToyNQUB+p2vukFqI8o7D1FYXsLJxiF7dmpUHuWVkNu89RG3AGkAwxXICy4FvZGVZlNOlyd I6J8RJRvVJo32trEO48oC2mb67XvtxiGHttqR0TZJvWIKGfNprlenl8louxhxX4WxAR1vbb6uiK5 Mo+6TMc4D1efPpSKmU7rlIh+48FvvOoBiws29XT7kj+97kEYj9tyebjj8KlHfBFWytfkEcLV6630 ee7xDEqMsihZQoGF3CneJga90knOOkbvEZQmlC4CmTs/YZtkyRxoL4j2ZoJULYv2xj2OxInBouFw 1VUyOMLhdxUOvy7cOuFw/iZhu3AbJTbnasiV+wtDzy2KleTWhl4mmB1SfEBEz0nkRAjYgSFRDgyo 2V9B5ASeBdTNELgUhFkjUEmTG7WALhCUlEyVVJlybmCefRAgM9zbOg6a1jpo0k0+1lUG9n7QdFxd cI4icRBzHACFHwAJwXGeXQZa9RhJlcope7xQrWM/y7BExx1LwHbY7mllrgf4feCxG/L35mcVw6WC dB88n6YP27cc3OrypzWj+/ORxqKNNN9ZogSYRyBd4sErHo/bKuiVNPlevW2x0SNhb6rM0H0XDWuV ntaXbiXKTPGLRgFGuz3KIi/HBqyuh+NuS5nHsRAvNLlIAcA7Oo0Tkf+0Tn3U3QvuGiQ1IOQdIP68 ZhDP4PA4e5a4evGmwH2rGnIBVzMCXqOnoOsRB5EQqekpERixgbyq6ZlGISkAkGhFy3IFmKk7u4c1 F3NTMwRdfgbhUUKWltmX4JlqxG40ZGs3KJEE1VZRZd0Z2k6e9zK92Es3t4e0bH/BLO1/4570SGc1 yzLnsWNcv38d5y2pbWA/u9IOIXm4zt/uvLGPtELSl4n8NsD1QoH6pkyETtU00YNrMYCdTrX6Hb1U E1ZZTXn7x9cfofGWp+jp9H/WeFjDZW5kc3RyZWFtCmVuZG9iagozNzkgMCBvYmoKMzQzNwplbmRv YmoKMzgzIDAgb2JqClsxOCAvWFlaIDQ3LjUxOTk5OTkgIAo3MjUuMzU5OTk5ICAwXQplbmRvYmoK Mzg0IDAgb2JqClsxOCAvWFlaIDQ3LjUxOTk5OTkgIAoyMDEuMTk5OTk5ICAwXQplbmRvYmoKMzg1 IDAgb2JqClsxOCAvWFlaIDQ3LjUxOTk5OTkgIAoyMzAuOTU5OTk5ICAwXQplbmRvYmoKMzg2IDAg b2JqClsxOCAvWFlaIDQ3LjUxOTk5OTkgIAo3NTUuMTIwMDAwICAwXQplbmRvYmoKMzg3IDAgb2Jq Cjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbNTIyLjcyMDAwMCAgNzIxLjUx OTk5OSAgNTQzLjg0MDAwMCAgNzI5LjE5OTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdCAvZmls ZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYj MmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMyM3RvYwo+PgplbmRvYmoKMzg4IDAgb2JqCjw8Ci9UeXBl IC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbMjI3LjAzOTk5OSAgNTg0LjI0MDAwMCAgMzAw ICA1OTQuNzk5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFy IzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRt bC5odG1sIzIzY29kZSMyZGF1dGh6IzJkcmVxCj4+CmVuZG9iagozODkgMCBvYmoKPDwKL1R5cGUg L0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFsxMzAuMDc5OTk5ICA1MzkuMTIwMDAwICAyMDMu MDM5OTk5ICA1NDkuNjc5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJm IzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJk djIuaHRtbC5odG1sIzIzdG9rZW4jMmRlbmRwb2ludCMyZGF1dGgKPj4KZW5kb2JqCjM5MCAwIG9i ago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzEyOC4xNTk5OTkgIDI0Mi40 Nzk5OTkgIDIwMS4xMjAwMDAgIDI1My4wMzk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2Zp bGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRm IzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjNjb2RlIzJkYXV0aHojMmRyZXEKPj4KZW5kb2JqCjM5 MSAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzUyMi43MjAwMDAg IDE5Ny4zNTk5OTkgIDU0My44NDAwMDAgIDIwNS4wMzk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rl c3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQj MmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjN0b2MKPj4KZW5kb2JqCjM5MiAwIG9iago8 PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzMwNy42ODAwMDAgIDE1My4xOTk5 OTkgIDM3MC4wNzk5OTkgIDE2My43NTk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUj M2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJk b2F1dGgjMmR2Mi5odG1sLmh0bWwjMjN0b2tlbiMyZHJlc3BvbnNlCj4+CmVuZG9iagozOTMgMCBv YmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFsxMzAuMDc5OTk5ICAxMzAu MTU5OTk5ICAxOTIuNDc5OTk5ICAxNDAuNzE5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0IC9m aWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0 ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzdG9rZW4jMmRlcnJvcnMKPj4KZW5kb2JqCjM4MiAw IG9iago8PAovVHlwZSAvUGFnZQovUGFyZW50IDIgMCBSCi9Db250ZW50cyAzOTQgMCBSCi9SZXNv dXJjZXMgMzk2IDAgUgovQW5ub3RzIDM5NyAwIFIKL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KPj4K ZW5kb2JqCjM5NiAwIG9iago8PAovQ29sb3JTcGFjZSA8PAovUENTcCA0IDAgUgovQ1NwIC9EZXZp Y2VSR0IKL0NTcGcgL0RldmljZUdyYXkKPj4KL0V4dEdTdGF0ZSA8PAovR1NhIDMgMCBSCj4+Ci9Q YXR0ZXJuIDw8Cj4+Ci9Gb250IDw8Ci9GNiA2IDAgUgovRjE0OSAxNDkgMCBSCi9GOSA5IDAgUgov RjEwIDEwIDAgUgo+PgovWE9iamVjdCA8PAo+Pgo+PgplbmRvYmoKMzk3IDAgb2JqClsgMzg3IDAg UiAzODggMCBSIDM4OSAwIFIgMzkwIDAgUiAzOTEgMCBSIDM5MiAwIFIgMzkzIDAgUiBdCmVuZG9i agozOTQgMCBvYmoKPDwKL0xlbmd0aCAzOTUgMCBSCi9GaWx0ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0 cmVhbQp4nO1dS2/kuBG+96/QeYHx8CVKBIIAM44nQA4BjDGQQ5BD4M1ksbAXcfaQvx+9Wk3V11RR akot2W1jxmo2RRbrxY8lsvT5z9//mf379+zz/ff/ZM/d3/vvB3Enctf+ZKL6/eQXqPJOK1H/ZKXU d7ZoSp9fD2/Z2+Hx8Fj9/3aQtrmx+1N9eexCNL+/P/92+Nx2fmhLvt//tbr6X6ayv1T/fs3+/o+q 8OeuvbrC66F0tqJDCKmrjy/+R6lcRVV9XZUL+rGu/Mvhbz9lv9WEqbuyIV62BPofPyltlDR3RuiL SH473dq1XjMrdO03PIk+m2eyVK7M8sJm1mT//dfhR9X7qW8rtFMyt2Xw2u9b664vU/Wa173Uvb4e tMmrO6qfqjtlizvVMba0DSlCKlqumg9Ned/OS6D9WjQ/PJqd7n6C1wOafdrKRh1amv2+XHsNtA3K vbH07bwE2qc0J+JzgOYQDSG5LMHn87J+HZZH8fm8boR0aUjz0rZUKJvlNQlGJzQm50rTOCMzNKbK a9q6TlU+YAAp7xnmtfMSaD+dMVX/u/oDVUwhlGroJMIclp+EeWrnJdB+MmMa8jlAc4iGkFyW4PN5 Wb8SvsXw+bxuhHRpVWNyyphMByamI5ZwMLNO66fqQpZGFBUmyWR+7Odx3jQvm1+fmLYkMM2/jdz4 9enw+ZutpJU9/chaCj61f55aqj9VZMsye/o5+0NN1B+zp18PNarpClRTUJwKdFNQngoMrdG28fDU jX8ZXjtRuh3y2lVmsxCvZ2LEt5EbmwFJ47IK2J4bkqu1RyszpKak5J0K1BdaADWgIKcF96RAl7TA cTWAMA0FihQYWoCDM7TGV1pA6ZCCtmFPAr1cMtpFS8Y8cMRLS2t8owWU7+JPbKPAAGgUSKc6hN3S AgXdUlFBt6BlUAD8kDBaWiCpDsHwgXTQZWhDQbcwFipb5AdLKdIB6kAbxW5ZFuqCqiVLmKCNYgGY IXgQuIWyEIUNBSBbqmNQoEFQfKOgMCyDoFFFmQyEoUWxpo4KAwZEKdVgyA9nZrM75SHC89eDuS6i Pj8TTuy08cauxiJnfHG1kqsxljr6YrCCzqGZsMSwBrCO1uigwlhB24uUI14AXAtFJBJMGkYH/bYO 3VFzPBVIOuVjt9AG7UWVdHTQiLa0kYIWsMPtZvRlAZgIzPK5ajTLEs568BCcZQBRnvjWifzUhmyZ 4sHUb7QgIB3gUj7SbduG9FoFzcrp6KDfktYA3eO184GSCmoDbVB/GkEYyxCsAbbI3zJd/Hy3EWIA 8UMv7C0S5heYxAOwR4/QwashTMD3k1UKSQ/MpiOUKpDcEsLu5mwzImxq/OgN4BZDnWiC0aL0wQjB bkEu6GKAQ8BUqEG7CfmcyBVc0LU7R3w7gDboOJbPl5LWzjpFfrEm0llzgLTMeXgXrBUzu0Z0wCys i4IMHiA8rILYtRaa0DorbRagh+axKQXQhoIarG3DQjJkuCNt8CtcYFDECpddr/nxnNXxoTaSaOv0 GQAdHo/UItANP1enm/Au9HdGE4cnW5ZIceoIgDctkGDBmwWeM9A8rAhoDYBR8gutAcYGBgu4ijaq dQp522a9notjVBvRCQ81WJaZghMMsgz8ZJLhStGOV/bxCTY2anJqAF0kyyvppr2TTvDNdhOSb1ds VMN8oWgTZAGIlbUa7KWVpxdMwAHrr5QScArsaiMCsoNB8xh29tJyh/hMKznUZoROABUAS0FwjV99 BKbNhSEcBJDnQ5brIBRjcyKuLwlduO5nbBrU4ieXtM41j/eCG3KuKeKJaCrgfnlgx4JSxJOCks6D VEAxoCQsSJ2vaBchQ+wWGqWDU8AgaBQo5VcPQCkMH1cPi4QxP5bW8aCAks6LH0eb0jXbPNgNr4fA shkGwgNy0JiA+BNNEeUGp4huM87YFAEmAD4h8UJ+X3hUyXwoXVyfsM/r0RGxbSAOhH0lPC4OgNwr xbKkJIzczzMCJBWekQAh/KNMNoQW8SgXHiqw6IRHBdGxvUvjcmVBNOIGHM4Bh0Tzk7PRs+1Kgcrp NhOh3rQNRA68MNmwznaMSOf5ULoRUz4b7QwN71JanSSaOMPgeewIO4lY25wRYuR1dTsxR9RF3oym PzNAQ+PZnGRF0j7Ptv0udkDOS0Laq2+8mv/cYZLG8K6Zj5yAmwG5rKKoEXoJ/OARwTtSqWXQLUzM 0AbvdPmI1pU4xoMMfiyrqDYvOS1oL7HKf6kf13boyHm14/dQwcNf5OoMcAccmWHsD0l41s59p3NC KZY/q4CBRQKpSZY2M6KTfNSB5yHocnekzYv58tB+v5POQnB5zwbBi4rdqhsxuO3s03JiAWe2rVjO mDDXeQgUG4VJMzHlx7n8FrmBJwvKDVmUdDVcqqOOwHGPGWsZmEWhUT4QD8tQnFdgq/F7nvDWOjH1 sc6ZvO+tvenOkIyNljKoO+frFQAO4xeRvAuB4bNP+1D8rOXyy7+IiCurDrwlL3TsyAo5dP8Rz1AT mH/SxawrgnM1H1TiJ5nAgeex0CYEUNmtJfxpRx7uRfh2PsQKfhn23NNV5rRN+EwGkyLvn/XwuWXo qXEJ7g4SUvCNgv6DUsEOWwgZ8UkctpUnJ5HsChkvO3bLNZ+jgs8cgxk52GQiMLnzt+w/Y0si+Zfx tiuAtHe0Sz9CMWEsoHag/vyhUeglAEQ8lYEjkHxiHBg+dMsyGZJvwV5FyMalA5GKMYuhgzOwIxIk BzWAY2yNGWOBVGOaSs5MQnuMoZYi3lGjQrBs5lMF8beElvYei2DGBMLADfOpxm6nu8cLbqe7iRby SfNYV4+D42ELADkAJYAO+eyFsOT29v9e7nR0vNPRoCH8tMQn1mOtboZL4RPJvSdgk/D4oVcDVm0J GgW54FKQdeTgQNHpAOlUlEgY8BTgAi0wAJ8gaSLIhY7WUHeAWAgGB9CHdqtApVImMy3NhFAABFh2 f+pizMcskRDV0EYBpMOaDW4BHAtzzIxb1km7GkEYwKfrLPPnUDo9dWsKQXUOI0mU14ljlPd2SJmw fas7BdLs0PHDyzGH0CQeQpOq0q3S6fqFEsdrdSerSTGT0jUX1ZRTl+qqoOyunivK7V3pcqNF/6Ud 3my7dpu69bVyzR3Z8Fblju1WV3Vdv9P6SyUGN/f0Ph9+OXz9aakjdlI3D3+cjj+bu8h2uK08Yd/z 3q8UbmJ6brCPtat/HbWc8RgvQi4JZBtxDox/NLqRQy9ot9Nz2kUfe7j0QGbnpvMgi25nJbix7P6s xNKbeNOdULhNsMHhf4TTBgmAuvWAuj0L1G0P1C0CddsDdTsE6tYD6vlZoJ73QD1HoJ73QD0fAnW7 FlA/JdHZsSHNSEm/mz26M7Lj3NY6V3HF0w8sbzf/yuz8DJNe0MBDyukL/WgdSwShw1mZ3ncAcIks hTs+9X2td63s2OdudbmYDnU6D3W6s6jT9ajTIep0Pep0Q9TpPNRZnkWdZY86S0SdZY86yyHqdGuh TndEnXMeCrCAKOKFO0sEbzZjzx97EpmBw+akZ2IjygmzYF3sipwQ9uiKqusCXVFVWrYuo7kauqLu Szu82Xbtdq6oujboiurSvl1DXFH7ZUeU8VxR1+7yrsgJuX28uqYr2mN+VG2IJHe/U+dK+VG1IIzk j6FtNj/qnPxhMDo+EMofoVsw5HNx9lNqOB/JbeTC3dxGyplU2aAdbdZL3LIopwIOk7rlHy/O3ltx aYLY5m0ynjJ/rBXZZtJMfMTEzBdn8yka1TXHUzFL5mFeH62owgyHt12/u9mV5H5TWadIIrKLJNS9 eQwQ7vnrAbiLqM9Dv4mdNhZbAez8rMHWuVSdlL07Chw68XQrcNLRq8G2gVKHgrYXbxM5npDgD7oG criMqV+rS4A1TwWSHqkK6eNI2qPu9Kw3Op52xVNGa+BwJ26qT7oEaQ50OGn6jHPXyb8eOlM8hjh4 kDIjvxroM5/FbT/QcCPx/WXA1FZWGyzqWScx4mb48Z5PVS2zZWI6pFsoy2mbkM6bHZZ00ylOJjqZ F0E1W8S1p/BcQBhEAVOYzIwXZ/BBfP4dpLx2z0hqvY4oP0DgJLXHMMYSMwysMi7tJzfDfq6FWzcC 7Zbc35XGMRfhpKb72Xi3yMHOQNYaPSLLGQ5gxhHDJbZlX2vD0A1RT9XTKyFqPjgJo+UT+vJR5DSz UsH5uggYwvOMfc97Cjbz2ZkjTpPzOhSLwtJMQmU4O/VHR27tu7I9FiV8o4WrG+9abVkC8dEpFrHS CywiXCI8A1siaomIAbpNsZRbxd5T5id39XPNrp/pOa5Xzek9Qhimm2ULMC8s5KBLyubSRbP5lqGW 62WrGWoNOBWaUiwiJeUtAWukTWkR77oi0oCzbEaesY82Z1gurkz4vJ58enboln0lMv+6Aj6ra8cx srMgd90PiJ1+F7FjINxYo0M2hNRyR94aD5hKkQLMSNsyxFKdMpRDXhslLYCkE4LWsBR15JE1qJXN 5ZXUevietq3wSkINygncYLs4ryTZBbcRXm1Qr7Sl8eet8Aq6XcXCvHXjfjghvYVz9Zu9VfyQthlY 9+f5de6OnMfs8fB/XSNe9WVuZHN0cmVhbQplbmRvYmoKMzk1IDAgb2JqCjM0MzEKZW5kb2JqCjM5 OSAwIG9iagpbMTkgL1hZWiA0Ny41MTk5OTk5ICAKNDA2LjYzOTk5OSAgMF0KZW5kb2JqCjQwMCAw IG9iagpbMTkgL1hZWiA0Ny41MTk5OTk5ICAKNjg2ICAwXQplbmRvYmoKNDAxIDAgb2JqClsxOSAv WFlaIDQ3LjUxOTk5OTkgIAo2NTYuMjM5OTk5ICAwXQplbmRvYmoKNDAyIDAgb2JqCjw8Ci9UeXBl IC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbNTIyLjcyMDAwMCAgNjUyLjM5OTk5OSAgNTQz Ljg0MDAwMCAgNjYwLjA3OTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMy ZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMy ZHYyLmh0bWwuaHRtbCMyM3RvYwo+PgplbmRvYmoKMzk4IDAgb2JqCjw8Ci9UeXBlIC9QYWdlCi9Q YXJlbnQgMiAwIFIKL0NvbnRlbnRzIDQwMyAwIFIKL1Jlc291cmNlcyA0MDUgMCBSCi9Bbm5vdHMg NDA2IDAgUgovTWVkaWFCb3ggWzAgMCA1OTUgODQyXQo+PgplbmRvYmoKNDA1IDAgb2JqCjw8Ci9D b2xvclNwYWNlIDw8Ci9QQ1NwIDQgMCBSCi9DU3AgL0RldmljZVJHQgovQ1NwZyAvRGV2aWNlR3Jh eQo+PgovRXh0R1N0YXRlIDw8Ci9HU2EgMyAwIFIKPj4KL1BhdHRlcm4gPDwKPj4KL0ZvbnQgPDwK L0Y2IDYgMCBSCi9GMTQ5IDE0OSAwIFIKL0Y5IDkgMCBSCi9GMTAgMTAgMCBSCj4+Ci9YT2JqZWN0 IDw8Cj4+Cj4+CmVuZG9iago0MDYgMCBvYmoKWyA0MDIgMCBSIF0KZW5kb2JqCjQwMyAwIG9iago8 PAovTGVuZ3RoIDQwNCAwIFIKL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtCnic7V1Lb9w2 EL7vr9C5QBzxIa0EFAViNynQQ4HABnooeiiSpkUQF3V76N+vtCt75flMfSSXXGk3spF6d0qRw3nP 8KHXP9z+Vvzxb/H65vbv4sPw9+Z2U16VVbv/Kcru99UYoJsro8v+p2iUuaq3O+iH+81D8bB5v3nf /fdho+rdg8Of7n8+DlHufv/98Nfm9X7wzR5ye/NT9+m/Qhc/dv8+F7/82gE/Dv31De43TVt3eJSl Mt3XL+OvSrdVh0n3uYOX8mvf+M/Nz98Uf/WI6atmh7zaIzj++krbrbL6ypbmKJQfDo8OvffEcn0e dxyEX10VqjVlU5htXajKFv/8vvnUDX8YvC5Nq1VVN87P48GNGQazhbZl3Q1TdgPdb4ytemKWZdXB VXuld/COAbWyfSOlJVxv+y87+FM/Xxz997z5NMK5NcOP8/MznMe4df2XjziPx7J29xlwewYfzeWp ny+O/iXOiejswNmFg4svOej8Mq/vn8O96PyybLhk6TnOGZWpVZ0yNUYVlWoKhaqUW4+bqh9aF7Zu cfBH29uCJQobyNpupKrcdja8MxiP47yPM4tq9ztGZg9xmMWHiQev7zav33U2rCzuPhV7DF7t/9zt sX7Vod3x5e5j8W2P1HfF3edN7wUGgN4BtgeA2QGaA8DKFvs+3t6N6Rxm5x8mHtxNSNm26JzTS1Nq +xkZ1T7HppHoHQC6ki1uJOCdAJi3sg8JgEe0BAAeqpQtriVA0l7VbFhs8Ua20Ad2HU9360/3qkw5 cG29B/ZADVpQuiJAS4BlAAMy0jKR0DAKAKRYweRANKGFlZ1awBRkVaIOeGiYPm2hpQLYLdNd08gW UlWVfAT4Un7PmG0AMUAdCASaKQHAhiqpqm79VTVGY3KILlcQI80b0B1GidAH6ENLCUH7Dy4DEAMp o5imFYg2qwnlNEMVAaqCqlIjiyIDZA43kAYMpIwhjEQMAEl5Z8u8ykzprsHMhrMKQpPF+kN0biC6 4GWoDBmIIKRzg8mhCwVHLWcLmFrAA1yX1BgIBzQoOzzCHSTw9rT+0OqZzV8WlwEqhEYWlIymP4AY DIsKAi3kKOfjhoGmoNuYLgBi0l66nH0i4TYBeZk5DHyok+hRYeblz8+ye4/2PPcPHHRHibavvrxA B13vKh36kQ4apHzvfeyEs4EWlgH0VgDUnrjqUGEZbGd7AFSy17eyE5Am2WIQr2oCs73cK31osu+1 dntKJVEdhslb6ikdkl3pHUdrIcijQhTYHEftakS3veKaCX6BAx3ctJno5HuJmWzhwS+YzFv5CERc oOp0FGgxJMdb9/RjiNpIesAjMvTBR6AWBupKJ4f5BTxCM3/s1OE+zQRfYFhgpZQgFCmgh6SYB9Up gVRFhwUnTYcd6j6Vm2JccJH7wFtKIOwUGOVw41OIwSgg2mBQeB4Muh+u2UmsI5cxWqBDgaGiPSDm GRq5/EetGuFAHJHfkeMMfmpbOZkHkqlfjgCmHgHCA3vn0fYhzZ2STC4R3LRHuBiYLagdEIhHB9ik PN5xoTxwgwB9wOzADjnqD0GBDQwLjot2yoUMoxRuyqUoc9s+1KfaiUeyRBg8wKKRH+LBbTv0wSUI HuFuiUsQiCUIDB82iX/oHUOo4QZVBuHmfQBFKBFRhoJqB8RxtU+mfD+uKp/GwQW6a4kaz5nD0zae DCzWDnkIL1fViCSN6x14YUkgBMhhM6XTwAf0uuGsiskfEyRyKJiQUIJAcMfE9YHGBx4ZN50+1igi 6AEpBUgqzAUQi4jkfOdytE2tnxtV7t48UKNJFj7CLSZPXIEz4fxXTRqq9kSty0dPPezPmiCqhrAc No5cSy3LIohvEs7fmMdea2ohwjXz7MKfEeCN9JhgdR2CmTZvQ2Wntn1YHpgKoBJUdk4THuGw6Mm5 G+K9AnPD54/yQLMfj/yZh3aOEtQU+3lUwrNBvpYQrpYR4QFIv0clOKLO5asfx1pl2wizHFHGgwIC +HrZqat+msbH2MYpqrxeQuXOtFKIciwVIcmkf4gIoCLMHy58nE9mxwN50GW+e30hydFpatbn7HMi wjjAQwouhuQpEk7aB2IK9PCo8p8qfaxaYYUpJwxoKngQ7oXCC11g2zh7B+lO46fqAKe71LSF2yGP lUIPac6yVszFjo/Cl7n4chtfGwlnjEexhDoZ1AcelacsFrTqUcqgrI82kq8E0qXiVcqOlzLuqsCU URJe1MYyTkKISmH6PKDOmHIusSQD7OfbQvh6PC+vRSw3p1gHX2pA5b0JJIl72Jb1V2lik2xGuqDd mxddfj5RGhtuHbOERmcshd7riLlpGlHA5fuZuJxGVGh8Z5vGW2jlYsxle4t5goWUeeBW3tixnp85 xqPkSHMWe7YhoriKzAb7GJ7CzhU+pLB1EXiEr/ikMH4ekWCK2Jl72AjeRhwGiNjrfapl5ap+brhd lw8EhSn8ZIfvsRwet6RxXIcbn2aK7NItzQfRMMEyex7VPQkb0I/zoz+AWEThKEW0mDGMP060l7oA hquKWY4gDNdGTG1V4C42YhvKclyKqYRJvejigcNipHFLh2vVIlxq+HpOkmMLEcfWVsN0tGHyiKgj DsJ7rN/Q3V0RO2ix8gEnLumx9rkueVjjRzLbTAcsjRIWM0UUyssYnLspF9Jat0+lFz/ElMZyhLIe njtC/mEu1NrHbAA8ZWY/tb4N3OenGD0qgZAe8U2U3IYElZfJzWNN87Q0wG/R43ReLCDlVYRNW/vT TIYZeK84vTYPb+J0nFsbAfhOZGCmA/U0NGtVgJxRmiERHendCAC3pdErD2MumkxKM51SzpYLSEoz u9qzYJpVAXKWA2CvU85mGyABy5fn5sS8kTdlK3nr85AGpZhef0/o3OoKdjOjus5vasMB+PoFyODo jbz46hQIlCFzkC00f4EHHwWutIe4ic4lSZRw0a5p4f6ufwXXRcZV3OikYAS8jQlqkXQHFQJA+6GP 8KwJDEbM6yqgD77XB4pEYJbgHBn4XGoNPbhPAQpYeT6yfm6BXGd0TNYEGGVI9uHhyaheXpS9XAGL AHCBcdzpPWWVIWnhp5Ucu5pHAP66mwTOIK3RsXkjHXjPGn3zSEQq4OHrsiRxvpnwUZFOErsNBAJJ DdeYFOkVf/8lfxENFr/DQ5+ZIh3F38MDESi8meY0+WdSo1NnjXQWAzhj1FfAKjDzA5Iane1F1nQo 6h7HcSIinfBTcRGhz1rCOZ6mvhvw5hfcpQCSGp12jXSWDYBtIKjsvHZA094sb5uHYeEtrinerpuH Devq1Uv0SGN0VPl1RjqLQSwFAColVC/hvAJ/DzBU4/iLgV1FnkSiq1d/uQJWwOovT+kvzVfqL3Os gWjwD2tlYHoui6kM5FgDsXSxylD50HStFlMjumqE8nHayoCq1khn2YAklQF+DodvdJ01rr9MgZlp z3I8PRIZnforjXSWgtgKWCYgh8As99jmiY1OyAHi02guJC0wLN1ezlHPsvCqoUWK9CoFAKQdQg76 ykY8fQP6cJJMKAtgXXg9qdFJegJ/uYAzRn0FzAFYC8kv0SON0dEhV1j4XkkzP4ny0izkCouZ7GFK x6RDrp+ggavH2crwTvGeN97p2W94ScTdtBdlLF+ak16lYUHwUqTh71LON+SyjfNxtSkNugm5sON8 wteUWmPyXi8wV3F7RKLut3joCNVNtJ/58OfD/QTl9pDbm5+6T/8Vuvix+/e5+OXXDvix6+395n8Q GEGmZW5kc3RyZWFtCmVuZG9iago0MDQgMCBvYmoKMjgwNAplbmRvYmoKNDA4IDAgb2JqClsyMCAv WFlaIDQ3LjUxOTk5OTkgIAozNDYuMTU5OTk5ICAwXQplbmRvYmoKNDA5IDAgb2JqClsyMCAvWFla IDQ3LjUxOTk5OTkgIAozNzUuOTE5OTk5ICAwXQplbmRvYmoKNDEwIDAgb2JqCjw8Ci9UeXBlIC9B bm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbMTczLjI4MDAwMCAgNjg1LjAzOTk5OSAgMjE5LjM2 MDAwMCAgNjk1LjU5OTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMy ZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYy Lmh0bWwuaHRtbCMyM0ZpZ3VyZSMyZDQKPj4KZW5kb2JqCjQxMSAwIG9iago8PAovVHlwZSAvQW5u b3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzQ0OC44MDAwMDAgIDQ5MS4xMTk5OTkgIDUwNy4zNjAw MDAgIDUwMS42Nzk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2 YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5o dG1sLmh0bWwjMjNSRkMyNjE2Cj4+CmVuZG9iago0MTIgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9T dWJ0eXBlIC9MaW5rCi9SZWN0IFs1MjIuNzIwMDAwICAzNDIuMzE5OTk5ICA1NDMuODQwMDAwICAz NTAgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZD R0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjN0 b2MKPj4KZW5kb2JqCjQxMyAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1Jl Y3QgWzMzNy40Mzk5OTkgIDIyOC4wNzk5OTkgIDM5OS44Mzk5OTkgIDIzOC42Mzk5OTkgXQovQm9y ZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAz NzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjNjbGllbnQjMmRp ZGVudGlmaWVyCj4+CmVuZG9iago0MTQgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9M aW5rCi9SZWN0IFsyNDIuNDAwMDAwICAyMDUuMDM5OTk5ICAzMTUuMzYwMDAwICAyMTUuNTk5OTk5 IF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJ dGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzcmVk aXJlY3QjMmR1cmkKPj4KZW5kb2JqCjQxNSAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUg L0xpbmsKL1JlY3QgWzQwNi41NjAwMDAgIDE4MS45OTk5OTkgIDQ2OC45NTk5OTkgIDE5Mi41NTk5 OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZD R0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjNz Y29wZQo+PgplbmRvYmoKNDE2IDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawov UmVjdCBbMzcwLjA3OTk5OSAgMTI0LjM5OTk5OSAgNDQ2Ljg3OTk5OSAgMTM0Ljk1OTk5OSBdCi9C b3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1 MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMyM0NTUkYKPj4K ZW5kb2JqCjQwNyAwIG9iago8PAovVHlwZSAvUGFnZQovUGFyZW50IDIgMCBSCi9Db250ZW50cyA0 MTcgMCBSCi9SZXNvdXJjZXMgNDE5IDAgUgovQW5ub3RzIDQyMCAwIFIKL01lZGlhQm94IFswIDAg NTk1IDg0Ml0KPj4KZW5kb2JqCjQxOSAwIG9iago8PAovQ29sb3JTcGFjZSA8PAovUENTcCA0IDAg UgovQ1NwIC9EZXZpY2VSR0IKL0NTcGcgL0RldmljZUdyYXkKPj4KL0V4dEdTdGF0ZSA8PAovR1Nh IDMgMCBSCj4+Ci9QYXR0ZXJuIDw8Cj4+Ci9Gb250IDw8Ci9GNiA2IDAgUgovRjE0OSAxNDkgMCBS Ci9GMTAgMTAgMCBSCi9GOSA5IDAgUgo+PgovWE9iamVjdCA8PAo+Pgo+PgplbmRvYmoKNDIwIDAg b2JqClsgNDEwIDAgUiA0MTEgMCBSIDQxMiAwIFIgNDEzIDAgUiA0MTQgMCBSIDQxNSAwIFIgNDE2 IDAgUiBdCmVuZG9iago0MTcgMCBvYmoKPDwKL0xlbmd0aCA0MTggMCBSCi9GaWx0ZXIgL0ZsYXRl RGVjb2RlCj4+CnN0cmVhbQp4nO1dy27kNhbd11doPUC7RYp6AYMAbXd7gFkMYLSBWQRZBJ3pDILu YJws8vujklRV0j3FOiSLetlVRuIyW+Lj8vLcJ8n3//j8c/Lrn8n7h8//S770vx8+79K7NK+7T5I2 P++GBbq6y3S6/ySVyu6Ksi398n33krzsnnZPzf9fdqpoX+x/Nf94aCJtf/788vvufdf4riv5/PCv 5ttfiU7+2fz3W/LjT03hL319+we+76q6aPqRpipr/vw2/FPputbt96Y8lX/uH/7v7t9/S37fd0zf VW3nVdfB4Z/vdJGmddG8mV3V5ZfTq33te2LZvg8r9upfkSc6baYiyZVOTJ388Z/d16b1WdquVdO2 KfZtV4nCpos0q7XKi8r6fdh0lvVNmaTMC7P/rlQz45nJmzeaT96Ul+X+u9rPaVUoc2eaP7Qs1+Wd 7suP9Xyz1L/niq+DPtdZ/7F+H/V52Lc6bbvT9nnQVjPatjuyb+PywViO9Xyz1C/7HInOlj7b+mCb lynofH6uv4/K3eh8njdsvDTu88TLWGWZSvazZXApHYC3Bhjya8aYZsnWWjcAnqj80M5TGCaq9mfY ma7EgokvF168f969fywSlSbPX5OuB++6X89dr9813W6Y4vmX5O/7Tv2QPP+224uAvkC3BeWpIGsL qlOBkU90dXx6HtLZD+RfLrzYDkg1gNxIpnNDqvcj2k/4qDeV7B4M4NITaykwJ8peTyJTuDesZQFw wVoKtA+JUguFcr2nkEnLvtasq1Wlp3Y+yoartiC3dy3rCoycTiPpXvrQXdahSrmCH0WBgtmVlapK 9gN6CpXKZrEfJW0FSPhJFjxQqtPRaqApkJB3DCh270/Coi2oLzwhRwtjUTUbi/7o3QpSnTNdQeuQ 60XlTLAgn3IuhFdg5mDdQqXyFWUkCWkdwA4ORIZmOQcBf/BXgB4UYdQDq5SPFjpm6+m1uF1kY+B2 GC/lVAAuRBAKKc50jyO4GjXUGXRhcUuCqA8MhZEgfC0DQT54jN+mz+pOtTG5kKgDhOiQqrBjSJZK Cn2UBZIgCpRk2ayWlRpQBkDzBonaTYxSp5JHuaygEjm6fnYvjD+t5cwADWGFAEEAM4DteCtypnBw 93L4pURq5cFUbFFVQl++Tk3TsgD0JZCYIIe2o5UBHlDFxUG2RxEZOk/F7Pr3REmEcCAzECBACfcX 5pwPke04D3FOXatWnkWRukWxZ6FcmbEIGfRM6vpZFGBSadewrmMiE2dmEBkB4j5gvUOz1PgLQaZl ll0M+AcrzEF1BxiyKAyXKAb60RRGeQyqO4wFZp9aA6gvAz14x+hkc6cN9COrJdU5a2/HXOD84W/p T2SUHWDaGBtFkKl412B4wNyw6sCy8XenIadyLw2dXUAh9CjAaANcPx9kxybxv65VfC6lpFKpzetY DU05PXgrUClo4HQssNS1oqxNRV/GQYnPfrDhd7XjrxpDLHocQSoDkgHoyM7rqFp7ftDaHXQ/6Dx4 WKGOAPvJX1t2YLwIQQzsWIBmt4ymGyAvs66OQbBRywi1vmezHaAOoYEB0g+wCwgyjx7/pvSnAB0c 3M38FQd2CPAu+o/FGR6ulRhVOUbhua2B8mgNbNfowrgvoD2obhD35cYwVWUDIAM7Rit1jmJeUiHp KzhR1N/uMHP+Dnh0YnLE5O4lznRck5eV9s7UwFgi8+pWtY0gkFsR1atbpEeAiGCW3kTmDCIzCpFj mJTUXFiLH/xteWQ5xiIX8pDGJPOyGZ0kLuaq2tbXufRSlRnRkwCvC3QeIkM8SxRa4ZPFHXncxAS2 CuBmDtQ36LqWhJOoqQ5CZy1K6Dxh4lkc3yGBwgnNqUhQnhkrh8zj+o5ohBTGboRMmlpSFEcqynYc rGFQIjoqKp/NCbfMgFcM5rM4ZRxiFDefNJnbtRjYKwnzxJVUpbcLOr7RoURPNmP/zeSTnjC7aHH9 L8T6347cfltxX0xioPubuM/JwYLiMXyYS7olLoDZcbTxkr4ioX3tbpe8Md5dbw7bFPrhTAFIKrhm 2og7BU3jICbk31HbB2TbGcN24h2QxGFQpnaHwYMkWlSPQamjhi03rIfOsrNqNWG6zYgqBykTsAUS +HSKsTgEWAK2ACF2gagCERFD/Y+Q1DmN43Z7W0vK7JhLDBE2IACwCOAj9UtFTPxe3thdq+sXJPc8 Cbo4UTDagMAvzAs/P2kl5sFM266XUjq5A8HVTXut4qrzMZRNlNZ3gMz8pqc64p/DRpEAneptLSsH ClF7ATmGq27TRH+m2LCEBaC6xjSQC7uB/Ci6Gtc+rmLizk3diw93S0X6A3CY9yMAh6ldFsB0DmqG v7Bz2LIAgVuJKdgP/2TqECjz3yaJJOzPAxscSioRxXQFgyPDsg+sJ1z/R4o4JPq4Lt1IKFvbDWJ+ jIy/72Kiw6lUno9Hg2QESuPao9gcI77nsOGaJ7PAYrRke1+yX/hy5cdV8nTpgMQt0O8WChGtJHSP 9AAU8d9f+poc1VuKqc7JU3EkRHU8rW1tRuO14+vOQD2Nbx4DP0Rk+Acr3tbepplO14CoCoR7ePyL iq71Hgr3mhMz0CKKwTDcd++6RysSlh8PwAw5eB0owrGc+z8QMSRH2FTZa0lSp4Ik/OAjLplmkQcL ZRGtR/5H9G9WxnoYrZa4EtW/WeUxD6PdjqwOEavcruB7SBbamDiLtb+d7OaFVNmb+997VS7q/o8E scejoxYKxHG7ZKaz5JaxXG4J46xZrrdFMEOiXDsUID55/OBt7R4baK2nazW7K4zT9hbP899Hl0E6 PM+vivRstMXaen9Z59mbhNqLMY9atAYLCDYWAcPKJzREZvjmJCjo6hhE9FK49MbCOoMnHmRBxymD W4E+nef6AWOklDGgDtlsz1wXrjTQFQwXMB/u0QOCAFNbsmSmvbL08vVCdZkfOrPdU8gDfA3zJNuv ZZvEPAnrcfZFBZg0IIB5pHklXuAN3YO0HRfnsorQ1UfKqzEuB6xdJNFDlK51EqP2gF1ME6FXbDi4 dAPs74C0iNvpLITq1C5e6saVaVIaVn46hdQiR6aIOWuK2J9y0TYdGiA3wpvOsXRCFFD3teQPKMBb QYFxwf6RraANBZVCs9IOAUtNu+5f8imAOjQ8wTNcP52vFKXD9TPcigzVmI9j9r7kPLEg9QXS4wQD 14BSKSvtn1jGFFOZJJO/nhhll0bEeylVmuW2rjk4DP3VBO5kM6V8IiBPO6JHXaXHC6NRHkmMMrmU YWekmhRivFo8loF7h0z3BDh2LhgtDjortIJJ5DDg7F72BJwY1L4MiDo6WC3BJsgGxXim1ZibUZ4C IAOoW1B+GUDOCjmieDkSzdo/wPw87jKEPUsoOhKoVWqLoLZh9+d2Lgx0cN3xPf3+J2uFZIn4b2cJ Tyy7cuGZKh8vvKhoVRdWoi2zyQHxjCZG9P2IA3DN51AtwJcC01LCCjoaEAM1wBectg376TjA0ZO0 b0uNKwZlLlgg4lJTunAnK9hDk1oqymyT52MI9XhzcYmBV+KgninbZyURy1etfjhHUq8NC/WYaCbB xNyKieEXCUfCxNLd0IHrMhAB0d+BJXhGCMAm2j5xzCPQHng4iMOinLCQWCfk7tDgVwzvVMAOgfWm cy9ktvpH5V182gHxwoA6uI8wGJ18GIR7Inmuvm0uI6FkVVjHu7VUp2spUhlBkRjpyDEy7WPcXTGL Mv62EiqWuu5mwwfiB1x8PYu+EHAFZVQY1qmyzv9KziqZP1smnKo6zQRVt7tj9HZzkTcJ53E8rTbj FhPsZBz+zCFxDqE+8PCdsVQjxPOnsd1cM3Qi4bkqrGxCwZkrCSHxQVf4vpYAZSUIwN1rdGsxFkgs 5tmeAfbcWvygAellDudkWrLQvXZyvCJ/7FwxqtwIhIjjj+1SObWJeo7wQvvF5rytc/HNX6/6CuG1 6Jlr2XEYgEtb2h0xyXHFUIAR7YBVt64DP+OA/+mQpZWkdDscVci9fTHCMPHOprvUMQdrjruUuVgC twN3f8LiBkE+yWnHAejvf44GP8vJ4VKxGKJ+Oz6mmBpnVR56Bl4n/7XtcHYP96EAlHHWdQCq7bi/ XrU+vZ1FNk9AnZ+79NZPRlhIw1xxpDsvyzF0z2QeSDKDQ7l3VEcRTFmqD7XCccdcynDjj1+IQ8Hd wcLm/nR+jjuFjJDrf3izEbyYAaKMGzYOui+/HhesJe6j4QYWj3PwieJWGz3IEc6gHu47Pp2rltf9 B5an/DeHQ9rslbVrvbDm7LTXGphjzo6CTM5HQaEeDYby4KN8p8Ol08FnCs5KkyTSg/2QEcaVm2p8 7WWfbDroEgwDh27gESlgNUjcnD1hdNSRmi5UP9iWCKmsQHw4IaEWxIFJT2EncsVmFJWR4vwTsSih y3q8eWU1lIAnJCWAa6amlamzcVL7dmjVPxGNEjKctBZKAE9kcAIjZaMh1zQ/yUtDMVW0Q+9/ffke uv38KXna/R/wN1pfZW5kc3RyZWFtCmVuZG9iago0MTggMCBvYmoKMzM1OAplbmRvYmoKNDIyIDAg b2JqClsyMSAvWFlaIDQ3LjUxOTk5OTkgIAo1ODguMDc5OTk5ICAwXQplbmRvYmoKNDIzIDAgb2Jq ClsyMSAvWFlaIDQ3LjUxOTk5OTkgIAo0MS44Mzk5OTk5ICAwXQplbmRvYmoKNDI0IDAgb2JqClsy MSAvWFlaIDQ3LjUxOTk5OTkgIAo1NTguMzE5OTk5ICAwXQplbmRvYmoKNDI1IDAgb2JqCjw8Ci9U eXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbNjcuNjc5OTk5OSAgNjg3LjkxOTk5OSAg MTQwLjYzOTk5OSAgNjk4LjQ3OTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMy ZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0 aCMyZHYyLmh0bWwuaHRtbCMyM3JlZGlyZWN0IzJkdXJpCj4+CmVuZG9iago0MjYgMCBvYmoKPDwK L1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFs1MjIuNzIwMDAwICA1NTQuNDc5OTk5 ICA1NDMuODQwMDAwICA1NjIuMTU5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNh IzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9h dXRoIzJkdjIuaHRtbC5odG1sIzIzdG9jCj4+CmVuZG9iago0MjcgMCBvYmoKPDwKL1R5cGUgL0Fu bm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFszODQuNDc5OTk5ICA0NDIuMTU5OTk5ICA0NDYuODc5 OTk5ICA0NTIuNzE5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJm dmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIu aHRtbC5odG1sIzIzdG9rZW4jMmR0eXBlcwo+PgplbmRvYmoKNDI4IDAgb2JqCjw8Ci9UeXBlIC9B bm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbMzQxLjI3OTk5OSAgMzM3LjUxOTk5OSAgNDAzLjY3 OTk5OSAgMzQ4LjA3OTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMy ZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYy Lmh0bWwuaHRtbCMyM3Njb3BlCj4+CmVuZG9iago0MjEgMCBvYmoKPDwKL1R5cGUgL1BhZ2UKL1Bh cmVudCAyIDAgUgovQ29udGVudHMgNDI5IDAgUgovUmVzb3VyY2VzIDQzMSAwIFIKL0Fubm90cyA0 MzIgMCBSCi9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCj4+CmVuZG9iago0MzEgMCBvYmoKPDwKL0Nv bG9yU3BhY2UgPDwKL1BDU3AgNCAwIFIKL0NTcCAvRGV2aWNlUkdCCi9DU3BnIC9EZXZpY2VHcmF5 Cj4+Ci9FeHRHU3RhdGUgPDwKL0dTYSAzIDAgUgo+PgovUGF0dGVybiA8PAo+PgovRm9udCA8PAov RjYgNiAwIFIKL0YxNDkgMTQ5IDAgUgovRjEwIDEwIDAgUgovRjkgOSAwIFIKPj4KL1hPYmplY3Qg PDwKPj4KPj4KZW5kb2JqCjQzMiAwIG9iagpbIDQyNSAwIFIgNDI2IDAgUiA0MjcgMCBSIDQyOCAw IFIgXQplbmRvYmoKNDI5IDAgb2JqCjw8Ci9MZW5ndGggNDMwIDAgUgovRmlsdGVyIC9GbGF0ZURl Y29kZQo+PgpzdHJlYW0KeJztXUuPG7kRvutX9DmAx02yn0AQwDvrDZBDAMMD5LDIIfDGCRb2IpM9 5O+npW5J3fWJ/bGp6oc08mB3ZLpFFsniVw9WVb//8+d/JP/6PXn//Pk/yZfu9/PnXfqU5nX7J0mb n3f9Bls9OZvu/ySVcU9FeWj98n33mrzuPu0+Nf9/3Zni8MXuV/OPxyHSw8/vX37bvW8H37Utn5// 2nz6X2KTvzT//Zr8/Pem8Zeuv/0D33dVXTR0pKlxzV+/9f9qXFqZp6L53LSn8q/7h/+9+9sfkt/2 hNmn6kC8aQns//WdLZtvVk2n2VUkv56/2vW+Xyzf537Hk+gr8sQa5/IkL6qkrJP//nP3tRn9PHaR utqa/b/6PvfHdq4bK0uytPm8/1g0y+6yfL+WaZo37Vl2eKbYr39hsqesoczKdls+2a791M83T//7 rfnao7l23R/v5wHNfdry8vD5QHN/rDLdk4m0Ddp7czn1883Tv6RZaZ09NPto8O3LHOt8ea+/D9uD 1vkyb/h4aUjzzGfJmqaHvGhgzeFZOsJfDWAwbZwsaw5tUZgGRhOTH8f5FIdM5vDTJ6Zt8SDT68gX f3jZvf+pSEyavHxNWgretb9eWqrfNWSXNnn5Jfnjnqg/JS+/7vZA3DXYQ0N5bnCHhurckMkn2j4+ vvTXeRrUvo588TAhk9WNNLg4pXo/I9dsxICaSpJ3bjA/iAYrp2hpH/ZZPvGTbKhkQy0bPsgGSVgK o/woGz7KyVnRkMFXZKfwFZPJ2QJhssGkrA8YxcGKyQVycoGADuwUVgxWHXYfpg8NcnK2lE8UsgFW XTbwUXA9YMVkp1bSAesB+5Ll8glgS9gGmC0cD5gcoAhMDvqARZak495SluIMY+WaAhd2Z+6Ad9cD V1kEA5dGA6wqhwPYbkQhDinQB2duAFCKhnj6Ye+AZWQDYgycGNkpsG4qZwtfyWCR6Sj8K8ugUABh 8rAjSwFhcvetFGy4L3QuMZQCn4K4kIRpbJSDUwnnFkAYnoAGieygtDh5xBycykoT6+pwJQ3miyoH FQcWIAVUQaqlILTJTvlXYFVXOg9IRyi3B+5/6tn+3O63P8uF1dEzIWANPVZHNiIN4Ay1vJuPjOJR p3O5D2f7qMPHcoQOGFb2gSgMx0HO1lRyWFggSboFSulXYFjsA45DKScHKwYil68YwDJMH9iBbzZn KVgP+RVUMIDpOOlAKZ8L8Cl8BYYFqAM6gHQ6fX4IgR2QP2ZZdThitFNkSzhz3ByHUWA92mGNG1lU yv0wTMBx4KR6NvdaqK+zIdbjKvKtoWCHgDlJTyFyqii92wmninLRPBD6Qe43MMBDxN6GiM1awow5 w107GZOeW9ozVI/sLmc7ThpshJVL9KwghvlmriPb8ZBFCJUfqbBX4FRkELAwO+tgTOxOVzI6a6ke 2QdgIVgQ+IqO2CmcgG5YZ8pmOD2YzRzazZx8pyMPK+tdQwWhArTjZKiCEGMfwLnLp2sdwEKo7lG4 CzgiEeYQDLstxtwiINLJwK0GAgQ39rgYjrBUwPGrIajpUcaTSzXZYE1+TB0ABPEch2vRL82G8Icb wYEJ+J9rXeCUm84Q2KnRWJFmLQ4rUp+k7Ac9MZPb3HdWQRG9b/cPR5VFjMzuQmHuVX8YmeOkaxiZ KoscAd3cHLhdXzDSAVxIPaxc1UXCgOmk2YL7osAwwZ6vq/2HxVAY4HxBPsJ2e4KzQBzCZuoIsix8 Fd86HHKNCk4Il44aFkUqT2qEik31VDQ5KaOiDfJAP3304wdIwwSL0BWBpWBYrufBKNysDeXCq/Gz YgAKUQ/8egmCJCOUZa5wA+hwDwxwWcTJVYzPyPOjzA25teQKguSzLkyuNz1N67Fyx2HaZe1dqMSo stMdapuVZRH25HahifpCHlYr6eN2rNZlHNAL2ZMQzT59TbvI/JEzh3JZw98aEY4UumI62F9XmtoA j76I8NCv5Cp/XPJMPoYaJth0u998lLPDGA/ZAKHId73/ETYpwgEdlsNygIKxjPmoZz6MEaZoCqiA fWGcb1xu2PGIjhg1lgv/CAk6PX5FxSZ9W6pOzwA9Z4i3NTHSQ0b65c+DvOaA53nW88RBDwel3ued Xzgn9uBBL04GMeYqQ/Qojy+NiECFhvYk9QxzTFmBcwGbCueT83TLB7XkpZ7PUGZK+Xip9o9iKzk7 TrvllMkncLruAg8Dsl6ZfT8OyaXJfArYVm7u79pdjVDI8xIoNi5kFq8UDbhOqMfDN0X6uB3fFPdd BiRcKcR1+hboWl27KobIPudBVbELSlt72WyOUF+N3KAAzxJ1E0UwcwCbTbc+5vQSbs+xphIOAOnY 1BezUjgAanFwonhmBFWFNGZ70zmboSfoWrw0KQNMDRah6+wrEjS28LMmfpbZUdqhLAPuBVojnI0q Ln5P2Yf1Ta6b8Szf0s1C9NZJB8HAy5SdPgungeepEEdCwACkaoxz6fBYYlUUqFdCq6IExJPSKmII zLQeHjjhsOSLR12e0oCXFfAEFZBQacYn/Ub64LVosGAgr0UDOpenUtlKvrC28kGPW6erUag1RCQU OpWr9aI1AEvvbcssnpqspIAfbcxdm/yUtitSHYMNUEhI4OhqK/Yz+VHUSMnCu+2wpH9XvE49iHtK 3Z3HobPV1M2Hj5CQHuMjVAlnbXG3Sp13QRS4n8MssCGaNypipkPVyrxdVI1e+rFOV7IK7xmqg/PO Jzl4N54xru58ysR554esK7AKt+Qj3ke+3cFMpYRvznn3l7NVBPHT49oCvsJvBSJuJzSlZlb5hnES dxBUI9xT3HyZqRBDx1XFKcaHi7dCniIQo1iKDFugX2dB9oIg3YysDUhBATnJff/QR8AFQjT+TtFq A9zY9NIywD5bSde4J2uUcr+FTqcHGXNQDLgLwwxMGg+rGPaihJvlydqIyAUN1S1u0ONu2vcDndcH Xm0ArwtxUGXcXpx9sogT1pRig2NUcjidPNJ+liIlK1XKvCdchd3nQQcRNR4XUTY1VIaIK2kdsy+r SnEuuTeR1yePCELg9/gLOUZUlMaFxWadBXPrMrlYAed7utMmJrOEO4cjCl1Nz7mIib8POBHc7p8+ mUcsNOlju/ccOhKhLoeYAkXOL6TEBnj+u9e1nSd0wdfAowYXSRtfG8/rtPaRpqLBLMLz80jWjdX3 WShBd1K2cUT5Dk+638g1zRUhoTObSQF2JMheKozQ1ojI+tXwYCg65Wub+bgswD85661z7U4ACJIF iytI/zPGhKJ4Aud4Kt3wKK+4YsSd1vwrEW4QjrT8bosb0yvlkejx5hilK5WYvpm4pGXSeWJKeCjI 7gDn03SLd3vxMkrYnJ+cDdEXf9dS4tyQkoVA4nGfNux0lmzNO4rdCcbqq032VJxMTTWxqL1bAywS 6kxTgqLqVN9iQ2CroRW+pWwia8xwM/kLpHkmkFnzstPmYkY3lA47i+d+0XeNTioOEeHGWkjJydp3 +vSOxUbe6nTXnvq1DEFFDX0PyMduNcLgI4KTeHbwMt6yiORoXktqeihtgKa42QvyhVBHr+K8Te0p luHxruWJ8Hdf71q+4OUFK4D3MktWSwCfRYAXRxEumiJKHegF2uoAQF4cefMRnPuAt/XhbSs1WR5v VCAbFXG5EpO/ta1yYtdibu6GoHtDRcnia/vrCKrSxAvqZeI24X17OjWZuEwFduZRTBFJZaFR1iMQ ERAgDvoBBHFxYOb+QU769DI3AZcvXDvmuo+ndvgkjyIvE80PDMfyiKQ7OIWAfnK28EK2aZWDvJ72 ot6jjnEC3HorAhj6QTbAE9AgE5GgwpaTZaqcZCp4AgiD/CdId8oA/oFSuGcADpF0YPmwQnNnsjx4 ZzKoBgbHbJn6aZ5wLDDtxoaFGHQoMea5dxtpwCJkMDnoVK4pr1oHowAvB9RPg2Hpu06cRLsceFlO DnVbWrYNLuKgwXGWgtnCKLQEHbjc4WxnQAccZdgX4GSYHH3CSvmQgRSi4JfK3cc3acDe0lKJDgjz KGm9ToFPVaGtCBc6t9NgwdTVu7oeYX9AMgcQC5ACjDnLQaWTA0oRYun0V0J23GxKBx4yoJROLgBz gXQKoFemj19r+DZ4MBR1fRMcHKH8fo27D3i03/S64AG+c5o7i8YAvytUSINfJuudv9wnKrn2ZvyL MbGMNKg+Zvv5xsCa8ve5c+fBMmUReIktfoU9vUZ4TGxJRPywx8l1LQoX1RCG7+AtAda6wrfhG35L wJIRaSqe78u8eGMhp2k+5Jh1vSkrRam2ltl5EWLuLde5lQjgePpSn6Xy6V0leA2xlgdQcS2RlqDA +BkQegCb/AZtkeiwAD2KXw9GlA/SiAXVqCe0zBtM9DLrdMR58ytYsYgIUokoqKhxgbaVWJDNvMJs paj26fbuTIWXXSrYnV9sZ/T6HO/Tb4YPZwnaX0hPeevVQrlsg+3n1/aw/RrI5TncOpKrKI+9cjPr QuizLDwRkT3GvVcBKhT0wctK8IWfxVszPSN4KU+LddmQJbr74bFF5AA4XZjziHQgLCD0iccK81hx hdKgAcI8FAAmfWUR4RYRxRYQf8/fO7FOuZd7UkuiQiUV8yBsLcKJrkqEWklRnyk1CLP4wJ3N71k0 THkYJYJ54dqZz4UnZERAxlbU8NvJtsfJPF4YSIaNSPLhseQayQTcKcdTiVR0zsJK+J/nFUqtlHHG LxB4giJ31FDEjCn4OD0RYK3KbLwSGWVEHvyCp53XrJleY1BFyVrmdUTr6DorBRSh9wCAyhNgNyls CQUozYuZx9UzPX07JFxAgbl9Z/vqaA8B1LgkYNnzlz4sWdJDR1DZ3LvOEerwRjS3R772cFiNfO01 K97fd21uPR1ZN6wOoZjqbgtVLOK+Th0ZYcshRs7zLl8PaA4DoJ7yuvsDk5D/xoOiRjo7rEgxJjPM /mUY3XbL+uAdl/WcThBD1p7lQm5mb3fBcVXJBpkKauCJQjJEzp4wl1kmdqmyIhOvCt/IWtnQtVJb ibQaFmLdykpwrum7BJqf5LVZD1McJtb9+vI9NkbxU/Jp939FXCaOZW5kc3RyZWFtCmVuZG9iago0 MzAgMCBvYmoKMzc4NgplbmRvYmoKNDM0IDAgb2JqClsyMiAvWFlaIDQ3LjUxOTk5OTkgIAo3OTYu Mzk5OTk5ICAwXQplbmRvYmoKNDM1IDAgb2JqClsyMiAvWFlaIDQ3LjUxOTk5OTkgIAo1OC4xNTk5 OTk5ICAwXQplbmRvYmoKNDM2IDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawov UmVjdCBbNTIyLjcyMDAwMCAgNzkyLjU1OTk5OSAgNTQzLjg0MDAwMCAgODAwLjIzOTk5OSBdCi9C b3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1 MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMyM3RvYwo+Pgpl bmRvYmoKNDM3IDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbMjM1 LjY4MDAwMCAgNjQ2LjYzOTk5OSAgMjg3LjUxOTk5OSAgNjU3LjE5OTk5OSBdCi9Cb3JkZXIgWzAg MCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIj MmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMyM1VTQVNDSUkKPj4KZW5kb2Jq CjQzOCAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzI4Ny41MTk5 OTkgIDMzOC40Nzk5OTkgIDMzOS4zNTk5OTkgIDM0OS4wMzk5OTkgXQovQm9yZGVyIFswIDAgMF0K L0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJh ZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjNVU0FTQ0lJCj4+CmVuZG9iago0MzMg MCBvYmoKPDwKL1R5cGUgL1BhZ2UKL1BhcmVudCAyIDAgUgovQ29udGVudHMgNDM5IDAgUgovUmVz b3VyY2VzIDQ0MSAwIFIKL0Fubm90cyA0NDIgMCBSCi9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCj4+ CmVuZG9iago0NDEgMCBvYmoKPDwKL0NvbG9yU3BhY2UgPDwKL1BDU3AgNCAwIFIKL0NTcCAvRGV2 aWNlUkdCCi9DU3BnIC9EZXZpY2VHcmF5Cj4+Ci9FeHRHU3RhdGUgPDwKL0dTYSAzIDAgUgo+Pgov UGF0dGVybiA8PAo+PgovRm9udCA8PAovRjYgNiAwIFIKL0Y5IDkgMCBSCi9GMTAgMTAgMCBSCi9G MTQ5IDE0OSAwIFIKPj4KL1hPYmplY3QgPDwKPj4KPj4KZW5kb2JqCjQ0MiAwIG9iagpbIDQzNiAw IFIgNDM3IDAgUiA0MzggMCBSIF0KZW5kb2JqCjQzOSAwIG9iago8PAovTGVuZ3RoIDQ0MCAwIFIK L0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtCnic7V1Lb+S4Eb73r9A5wHhEUk8gCDDPADkE MMZADoscgtlsgoVnEWcP+ftRt9TdUn1NfRS79Gi7beza5qjJYr1ZVSy9//O3fyT/+j15/+nbf5Lv 3c9P33bpQ5rX7VeSNt/v+gO2enA23X8llXEPRXkY/f5j95K87B53j83/X3amOHyw+9H843GJ9PD9 +/ffdu/bxXftyLdPf21++19ik780//2a/PT3ZvDnbr79Az92VV00cKSpcc2fz/0/jUvT7KFqfm/G U/nn/uF/7/72h+S3PWB2/w/7j7UA9v98Z6vCFPVDkWZXgfxy/mgzl6utyYvK+3t/Yuc6eLKkyB4O gKV1s3WX5c0nmq88KYv2CbPfXANv9pA1f1g5bssHexjvzfPsmX+Pnl96MNeu+/L+PoD5DFtVt781 JPnRX8ukdg9lS5AebGL8tJfePM+e+SXMSnj2wOyDwUeXOfB8mdY/+uOBeL7MGz5eGsLcSste+H2/ 92GeJG9FnlhnizTJyyJpCPbffzYrP2rQ2DQLHbZqhrLUjLdbFfwnxs94PM/z7JlfTZaaOVtWM4Iv bd1SE2AbjPf3cpzn2TO/miwN8eyB2QeDjy5z4PkyrYeyFIbny7zh46UhzEeTWoOBmSY3WZZY60rX mObE5Ee5eYyzdubw3QemHfFYu5eRD3582r3/WjTaJ3n6JWkheNf+eGqhfteAXWXJ08/JH/dA/Sl5 +nW3N+7dgD0MlOcBdxiozgOZfKKd48vTQG/Ynp66/PvAuAc8T5ExddEDquo99S6gyhYHTNV5t0v7 SeLhw2EgOw/U1z9hCzpHxgZcfhgw6fmRz4eRYmSg3V098oRcxlbtMsbPKkbizBq5jFzXyCdgjm6V IbtN8xZfRj54YAqz92cvcUVu91yRNczRbeijkB9jKb1avOVS5GCHIHK9Ob7IOeRHHKCtZKuYSgo2 QCrhwN3Csl8lgko5AMvCKiA2dC8BWP9MPwJ7AcDaZY0b2a7cHW4XPmKk1EgG6cRojMn4pKmEQ24X KIWTSsIEAAZoB1ZWwTJ+BqgpOcJ8lhgBwZxOqgjRRXaXywbMAXsB/odJJWVgc2hpvkpLYzOJEKkg Z2ERJIxHDR+sxhXqvzkuDfS/hjIHWnHBQ3oDrSqV/bbmLjPBGiAYshFOROLR/cewCLc7K6n3eSRi KwZAw/3hzg1fheMUdksxNouWRZai3I+0nS4wrtXcPU/8i9T2KZw00CK4DwKU7iDVn2Y686KKoOS8 IM06NiHNhZJcxMFHrgAMgFAASsBL4IAB/2aSTYChI5Q1rGIVzVmuab0DdgcDlFcD1CgoaxARMM1y jqz9SO8Ef0F8pRbooj0jZtNZrif4LDE6Hrgm4hSAugeEhNpJHPhEt7uVY8Es9lqSLsKkmQ8SDggu UcACfFEVk5DlFVM0PPqggfd1nMDtMvdKZ94uiKtjvU6x+83GHl+1axJz4uXHd3oWneXYhJEHivWA A+9Wg9VzxpXu4X2v68PDLNPPchEYQ+anWgpdas9erlXspRtqdkRABFNxnPFJPYcMHUNW116uukfi BN7vTtjTtU7YPTSpT4eVQpMLxQfn9MquVaHGDXXonEmkMQ9B1qsERDpAuUm1w/VQjOYOJZWKcctN FsyJPHzETzYaGDIfmflHyQRaoqEGAQBC8NhPhCAuEmBB4lIMAR0CUBYjmGCHeXAUGYBbBAVQfcH+ WSz1tZE9I8T7rXtVMbHexbV5j9qDstDs9LsoHfQ8FVJOGLBAy2JZPW5BbD3EFxBhZMCA9gNugEJT uQoWq8KksGwqAQPtB3N4whRTBmAOC09Q02a/UAUCk3rCaaDIRhCEZADagocF1YDFRU5PFimIdaYQ 3KoQ3onJ2zkV761od5NXwb5JcHb3SshM2oJWOq9ulhKcBZRn4DGZTnuhgIMXqbc8Wvuf0DAT6Djz 87oEDBLeVj6BKPMYxSsp7lw1pPgytQcxriTNicR4zgHZ/GV8+o0c2HQ0nMkOeqRI/TWdi8Qns1JO umTS41okVi0SzSnBD/Ust5v1uelKWZpKUMFyxAmOxue3G37RuG4SEJ+EgyPPtPO4EC2TWzdfo6SH nNk8E+H9wQgsUnX3mlj1hjREiEHgjmfEJb7QjPXYpDztT6tiFrrUpOq7ZIUXNIVqgwCHl+cOA7iK 1+KqhB+4OVcp8Ts658XJOQdNA/y8lYQzRRF4/Bu++HYUklLTwV8pRxvjz8MqXEdsthJiuisek03c yuEtwgCuVBbKr2/kdFm+Ob10lJJKqSfcE1M5iXP/jordvOauTItFWREN0Sw13ZonvNKeuGaRSNOr LuGP8cW3Ysxec1nfnGJ43alys7FbVTXsCh9oAZXw8BEoDqDVRYhEGonQSCugwZheB8UlBgGD/jOy dBLh0MkAdSYlVzUpdwW5hoIMLaeZ+ay3ljrg/gPU18Ac/EoTNToaiap1z2lKKqUIv/C8scMdrHIl RmyRMYy81dNetbXKAxQKXvEyr2muX0NdQUQKXI8QY/iYLmfb7abFPXWpZ7m954fupfo8vsrsTmVO 2fpF3Eg8eWynqLXVd5VV1Xf3o4g6D/HS04CsOQ0hBiS3OKQRAaAIX5yDDkYWFDE1XQHXfiKMLLep vJUYMG40aytpkFP3PSw84H42b/zLS3EoH3Kpi2B/H7mvPb3U2RCrAQRfpsIbZwVJ5D4Cb1rCfbUZ 76xt0JdX9X9G2qIBaBGXVHkRXIAxpx380KuaXqrDDw0cMDRecGHMcytGSfOW9zByoBndjO8WEWgC E0nTvwGeGbV3MY00p4thsMRMUu68ZGh68Sq2ytCAdJ5GGEf9UBXBDLFQV7NtvU7kaldNonkrRjVA VuUqEdqN373jDWdW6gwWcs2ZJ6M4ubkCnF7xvmgXDx1NVKfLxt2UnOb23nd9umCftdPCO7TGjEKE GlW4xq/dtuW22niYuh4SDho3oLTDgOfGzzq9HqwTO7rlG0rbbn6/ziU1pR5JTmisgPhaBJtMj43G 9BXjZa9wZuE1CNPbJag0NuBWT6cYpLNY2fHVmVk7rbFnKYHiD0AJ1AtB/3/IllIMOEAraIUIUDMw phJUK5mma4M00g5FBVRcF1q3IKyyERL0f9Hxa9pOO3UxQYVP72USU+nPaxB4OAnM4GrpkU4Wy6Ms ojUyQF9pnrC/DTYWQrMHjXXki6A0ugahGgSrF1BVAMYVdE1Ee3HgtFnCTtttX5QB63GjRnOmAdEd npnjUQdusWcpAZ3eCFclLO05PyqpnjocZwu1iovAka/g6erIRClwNP1NSfNcZ6VvSwhwcyNur2q4 uSt1wqaeRUABAO8jxssdFbqnx5QZ8jMNP33R2vyIypS1EvVzuLMaDVE0z3iu8QS9nMovJ2ikED2V muqKutuvPU57j8LeUhS2RzjFKGzPT4UeqbRrb1enNnIcQDjAcQXAons2r9Q92OVD6twjyveI8oWO 6M4KId54RFnJ2jh/i643EIYeE7V7RFmCeo8oF63QnK+1LxJRDvBiv2rqhPOF0tcVydV5+ch0HRdw 1KcvAcVKp2VaGb/x4Dde9QDigk893b/krxUPAIzHbTk/3HD4NCC+CJQKdXmU9Go1oS3bPF6ucUZA MocBi7lTvE4MeqFMzjJO7z0oTSCdRWVuPMM2yZO5a3tFbV9PaMsyr7Y/QzJLxmDWcLg5dTK4h8Nv Khx+Jtwy4XD+7ryOcCsVNpdmiJXbC0Nf+66xrBQCPU8wO6b5gIqd06iJUPADY6IcGFCTH0HNCTiL 6JuhcCkIq0agxyV3akG7QFBSsVTSGVt6BZhXH0TwDD9t3RNNSyWabFUOeWDriab71QXvKhqJmHsC KD4BpKSOM3tcaNE0kslLL+/xFrIeeVZCSXlCCfgO670CmNsBfh947Ib8rZ2zqiGpoNwH89P0BezG XkRHsswZyYkd3d4ZaSzaSOudNVqABQTSNV7vxONxawW9srbeqycWK70S6021GbrtpmGd0auq47Qa bab4RaMIp12uMssbTiOoG3Bwl1wWkBbijSa3+4r3ZbSOCv/nh9JHe3rTuAVOjQh5R7A/7xnEKzgC cs8aVy/elHJfq4dcxNWMiLemU6Ub857BCJaaXhKBERuoq5peaRRTAgCFVrQtV4SburF7WNfq3NwN lS7PQQS0kKVt9jVwZlq2Gw3ZygGjUqDaGarTq+i38uItNyn24j3RF4fEqa0FFiuJ1h6xPlw2f2MD uRyA5IfMpDopefAEAOZgQLJVBnwGkEI8w9PzokeqVM5RKFLGna8iUspkMpSIdwOgQIVGZ4KvWo1F MAF0yUO4LMSsYdnQcN7IAFoR2K2n/9/I9gF04GWYw8KysBcIEwM+KKQIB7CDnBSXpSh00qnI4Urg LMUZnh6TY8SOuM0oB2KuSALDUMrBpJCvUAzEjuAU+NSBIPdeoHJSfQ953X2BEpT/xgO8I5MdNGrh rYZJ900p8tId1WWrlQppL/o5BHm/o3MIxx7pfJe+q1JKN0sOZJdfxR27VXcIavd61Gx0q8138tJs 2BQHyLsf33/EpgEek8fd/wH5pLP0ZW5kc3RyZWFtCmVuZG9iago0NDAgMCBvYmoKMzQxMAplbmRv YmoKNDQ0IDAgb2JqClsyMyAvWFlaIDQ3LjUxOTk5OTkgIAoyMTEuNzU5OTk5ICAwXQplbmRvYmoK NDQ1IDAgb2JqClsyMyAvWFlaIDQ3LjUxOTk5OTkgIAoxNDEuNjc5OTk5ICAwXQplbmRvYmoKNDQ2 IDAgb2JqClsyMyAvWFlaIDQ3LjUxOTk5OTkgIAo2NDkuNTE5OTk5ICAwXQplbmRvYmoKNDQ3IDAg b2JqClsyMyAvWFlaIDQ3LjUxOTk5OTkgIAoxMTAuOTU5OTk5ICAwXQplbmRvYmoKNDQ4IDAgb2Jq ClsyMyAvWFlaIDQ3LjUxOTk5OTkgIAoyNDEuNTE5OTk5ICAwXQplbmRvYmoKNDQ5IDAgb2JqClsy MyAvWFlaIDQ3LjUxOTk5OTkgIAo4MDkuODM5OTk5ICAwXQplbmRvYmoKNDUwIDAgb2JqCjw8Ci9U eXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbNTIyLjcyMDAwMCAgODA2ICA1NDMuODQw MDAwICA4MTMuNjc5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJm dmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIu aHRtbC5odG1sIzIzdG9jCj4+CmVuZG9iago0NTEgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0 eXBlIC9MaW5rCi9SZWN0IFsxNzMuMjgwMDAwICAzNjYuMzE5OTk5ICAyMTkuMzYwMDAwICAzNzYu ODc5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1w IzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1s IzIzRmlndXJlIzJkNQo+PgplbmRvYmoKNDUyIDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlw ZSAvTGluawovUmVjdCBbNTIyLjcyMDAwMCAgMjA3LjkxOTk5OSAgNTQzLjg0MDAwMCAgMjE1LjU5 OTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMy ZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMy M3RvYwo+PgplbmRvYmoKNDUzIDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawov UmVjdCBbNTIyLjcyMDAwMCAgMTA3LjExOTk5OSAgNTQzLjg0MDAwMCAgMTE0Ljc5OTk5OSBdCi9C b3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1 MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMyM3RvYwo+Pgpl bmRvYmoKNDQzIDAgb2JqCjw8Ci9UeXBlIC9QYWdlCi9QYXJlbnQgMiAwIFIKL0NvbnRlbnRzIDQ1 NCAwIFIKL1Jlc291cmNlcyA0NTYgMCBSCi9Bbm5vdHMgNDU3IDAgUgovTWVkaWFCb3ggWzAgMCA1 OTUgODQyXQo+PgplbmRvYmoKNDU2IDAgb2JqCjw8Ci9Db2xvclNwYWNlIDw8Ci9QQ1NwIDQgMCBS Ci9DU3AgL0RldmljZVJHQgovQ1NwZyAvRGV2aWNlR3JheQo+PgovRXh0R1N0YXRlIDw8Ci9HU2Eg MyAwIFIKPj4KL1BhdHRlcm4gPDwKPj4KL0ZvbnQgPDwKL0Y2IDYgMCBSCi9GOSA5IDAgUgovRjEw IDEwIDAgUgovRjE0OSAxNDkgMCBSCj4+Ci9YT2JqZWN0IDw8Cj4+Cj4+CmVuZG9iago0NTcgMCBv YmoKWyA0NTAgMCBSIDQ1MSAwIFIgNDUyIDAgUiA0NTMgMCBSIF0KZW5kb2JqCjQ1NCAwIG9iago8 PAovTGVuZ3RoIDQ1NSAwIFIKL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtCnic7V1Lb+M4 Er77V+i8QKfFh17AYoFOpnuBOQwQJMAeBnNYdG/vopEMNjuH+fsrS7JN8TP9kTQlS44ddMeuyGSx WKwXi8WPf3/6Z/bvP7KPD0//zb4Ovx+eNvldXjT9K8vbnw8mQNZ3SubbV1YLdVdWHfTr6+Yte9s8 bh7b/982ouy+OPxq/7jrIu9+/vj6++Zj3/mmhzw9/NK++zOT2c/tvx/Zr7+1wG9De9sHXjd1U7Z4 5LlQ7ccX86NQeS3uyvZ9C8/tj9uH/7P5x1+y37eIybu6Q170CJofP8imEXV1J3N9Fspvh68OrW+J 5XpvNhyEXyMyqYpaZIWoM5H971+b723ns3RdFm3XZfuXQuaZbNSsnXfjbmTjGneZt38VRVk735td KzV0pbOmzvX2vdAttyldbFkoz4sWLqqOnfSW7Uqh73T7QdpwucWwh+/beXG0v+XI7wbOjRpezvcj nE3cVN6h0+Fs9qVVhw7gNoIbY9m38+Jo38Y5EZ0dOLtwcM3LFHQ+PtevY7gXnY/zhouXEtFZCL2T gyN+buFN3+8YBwu+x9lo58XRfjJ+FqLI+37HvNHCZS/ubdxGcGMs+3ZeHO1PRGcHzi4cXPMyBZ2P z/WrRTcfOh/nDRcvjXHeWRIN6NUwHaR1qwdU1f7fqgG90wOPcUpedD8mMj3EoeTfTnzx/nnz8UuZ iTx7/p71GHzofz33WH9o0a519vwt++sWqb9lzz82W5tmAMgOUB0AqgPUB4C2n+jb+Pw8jH8aWmtR iI7WxaporUUp10drWcs10nprC05D6wOdpWFOHn8/stU9nqfECO20I1Wznb0jpJJlJwGaYhilfLDp 8KkD6D1AfmJPDKQ7AZB1BxDCTX8BiPSA5gCobMBPHaA8tPGT3YZjlg1Uix4zeWhEA0TYHUOzNiZI gaZvNT+0mjMKIABQQyIBTUr7CUAth8mB4cBsQavwBBCt54HiAPhsIQIUkYX9BDAJDOYeSAQUAcI7 UB0v/TBH/O3EF7sFKrahgmMrtJDbFarbhTqSQ4ZgkuFc/tmmPUxXbfcCa6myAXajw/LjQla7exlY vLEn59RoYXB2L+L+uGw5MXwE2IghgYAeDRs+UoxPFDTqWHnGE7DyvtjqEehRWU8gf8DKA7aEsUAv HFNgGPuJQSRUJyabc6FNDz5afAKWBxAZBgf0KNk0xIwFiMy5kC4PD/kBvcAC4nKMrgbOH97SspP2 Z4jtOrfk9kVl7rmj6ZWQFrPKaZwrzojQBjURXIZI4SY7dssFFZ9+WNyAOhfcMC/2NCDqQGSQGCBB +Vrmwg66Tbd0T4gyJDJgGq4/pbBRD1cPuHA5gSJWQwqaUotj8CAqN5GTmIZcsVOLg68omH20a9Lo C9mMRSxanGDZcCkEvNwDhAqgs4ec5jKWChkkqw1AG/QhoWorSidbwfgBd87v1HDD8XNLnwsEeywI oPKQW4Mp1JJHECmF3wuog0HFBSRfH0BC4I9JSMiVDhWQyMkR3jW3MKhdi2udMz93p4pgpYNCmCod XC/h3nUalaKrxhJtfCmHe1gRfhxnXY+vRDjL0bo9yIByBA/SqKlKOFFdaniFW8ccU4/lzz0fh/0Q 4jxiG8Bk1DPmIRo+L9MsOhDLEd4CVw/SBoSTMMbtj5BsQDFOIMdmSpA2iIj6fUooYppm12oCi2s9 Yuqqo8Cw6CK8vHliKR5E5uFpvr+TIrIOYgqIzL9i48HZwSOgP4+dc9tlHOGhGk9xca6ULtRYTK9u 0zCJmirELmlN5TZmPFxPZ9PD38BQWnj8IcLQXcrmtYdZH6GVw6NP3CT3sPM5x6SQqdzSidi9pTFf D4sLiEwXu0egKIENgmtMCRszGjgcUoBC3KsI0y8mZQLGH8GXvlHic4WuzsdSF4lIR3NEYvJdgIgt nIQ73ttdGQehFUQTOdOk221anlk+jwxF9obBceuHi7tJNg4S2FgzbcbwMDjfrfbYeoxIGlrIPrro mcxI38VgiQ0QXxgisse9CcGMc0j0Bu+5ElTlYxE65JabROPyn/NISqdCaxfl39eCj9Duu8x5Y3Yh KTyChrDyIHJDrXukISVIzD7oFMo9Sb4ON0O4RAhPRlhdWCIobYovhwhnj/plPNbFff+IwfGNc1c+ h6dU1o1DLJfdDnap9nmn0A8A+AJZLECmpJku/Wmm2RMYp4LsLGgDYju1DeBReZhMB+qJaFYG8Bml GRLR4SEZADiKRDOgPTCdlmZVSj5bLiApzZqbPAulWZUH8NkUgMF9SzQaGcABE/JzYhItVUsklLyJ 5l/NzM2FDYCNZ/DNwFuBNuyABswuAmB26W6WBExhdh1HxU9MJjSKnGozRA7OCfgAQA/HPnMiHiqW IUMSjaa8KvleX6WG5+b4DXADBAHWw/wrtJmbq/TNwKgAw4ST2f6KgKo2YA+lmN33aDGfmsrLLDJk mPUw//osu1pMGlVbihRaDGI3v23caDq/7fIs5UgXPzVaUGx05lzbgSco5kFkOHkMEzWtFLILaJ01 EViKDcbrOB0QxKlXJIVugLUAZmEpYYsUbj1C/tQ0m2PTSiH9Lmwhnsjh4ZHxDKwpPDJQseg8cRuE 2lNopAEetr6EZCEPhbIQf8vDI3OkE12etZcCSCqFincRF0rSKIgl2+LGismg62zBJcEET2E+Uy8G EQMA+Fs8tsQDVuCBzCP86IbmVTH/CqVQddsjuwFugGti/uXtkbnuiBBNJ4QaYVU7MdLCezvfqHpv p5YrOCUA+dm97jPO0cHFE3a30n5C9+OHSnhQXw60o5EFruyx3AejPkQBy4CxoJ0PdzZAvjo0CnjA 8O30dDxnbg8fAYAYEAjwgIMnMHwdzg6AOjwBCf2NjRgcPIFGgYTAH3Q1QBtAMaSpCDEfTh/Vaopi 3OpZZYpSFKXyOEXOq4dFVJqOPiFt9MLLq/mWkT9zcmWRW7MbjonHiWggMz95NE9tZVojIUkFuhQH sSOKD4MPa7ehkhzdL7s7jZp6d/sTFoixDyaqJIJJ5H3HTZ1QMr2vIkoe1W7gKzYeHtWYl7LaZynd MFO1ftpGkhISlINuhZtsgjgyAlIIWb298NohZKGYQUohq3OZUsheaCFy2a7CN8G4Yo4pZuSw9q70 8DI3y6gW8rlpIUWNxVtF+9OoR1Ry8K7kOAkbJpKPWpF+Tqgu1FSOlLmgunTRlTzOpUhdWBSZx4Nc SvmPa6rDEVHbCwgUXsrQw7ZbroJ4X/4jrQap+m7N22196zYlksxF7eYAfmXJQqTKhUxXV9HZc6OO qhlPzYq9+zVXLgsPwyz25sGbYU5QjymxljJyUbkjF1OGh3VeJw0P39gsPZu9b5F6TbovIkyLDMOv a+MbDEudqPfgHqSR2yJXztGsxqOe6S42WA/0ZpxpVh1HjEecI7yWWzh9PDjDbNsvwjuZDy/ne3OJ +jz/9PDLJs/+zGT2c/vvR/brby0K38yVH9hpJxeaTBRHfcZeKuzNSDwHYMciJCTCwxNwvpdfiwuA vg0zwOFIugPFAYXHYZ/RSBD7fHxtGXwAGfmO1CXgepDxJ5KshhMK5nAhEuGoQ924v4KHz3g4G5Iw bdwF4BExGMBMAokoEXF0Rt6NW032EL7KAvVrl8+nZb4vvZ5iQ9djjz/cL4q5hJhfaELNKX41ukdY hF9TG3Fxwoo9hVlu4rvZ8BYek6SIrdccjzBQ+TaqS2WE3H8w0S1SZe9KGbLel/1T5IxruT/s4XGh DdAo4gbZiBtCOUESXEub4hZ7HMuF7i7hJvJ6M8R0/xXDIFR9N8Y1K+re1vUwXhgNT1bgC4TesJ3E XHpf+Q1cMEdo4YVHH84V7bUl2+dJCUROdWTzptFcaqcxubqPGcw891LzdXjFkSK1N3pSRIpcdd7O ixRh4TvwE2g8AoMLDn18KmJBK7ouLTB0ydCJUkmPQl7oUEpMMlSCUPxSMpsiQvHTBBPm0Z6rT0o+ ZSwB6ovNDV7PcVNetZRfcx4TFOYHziYya7v6FKZsT3e/chKTVBXnc6KtNUeWlj5u3jmf8tGuHh2Q 2kVVZQ3e3vaC4l4A8KgVC+b3FAV3wQ6V3NqDKvAUAG1gTTFeSxoKEDsW7il3LLwgL04DzC2tBTk8 cRn7UGlhcWu4BkCBxy01D+vGt55ECoV3przTyhJ409z+vRjDM0UwDM6cQgkaKIUDi41uv0KjCetH aFXt7y3ne7g8xGYTRFdsYpBkjqh9mvw21ezjE9qWYTbvarjrG8PSg9ozzlnRZo9cEE+jGvqTbW3y xDFeSHiuODwP5kWkQKdzLVdonykpLG6GVTPn9RcX0vv9kdcDEY4HVlsfo38hXtbfPAKm7sZ2dfgc p3ObccEnzJL6YrHvcGDDFBN2rYlhvFCrDhancVDA8I3an+ytHZ0oOzSHX19fY2fyMXvc/B8eIBs7 ZW5kc3RyZWFtCmVuZG9iago0NTUgMCBvYmoKMzMxNAplbmRvYmoKNDU5IDAgb2JqClsyNCAvWFla IDQ3LjUxOTk5OTkgIAozNjQuMzk5OTk5ICAwXQplbmRvYmoKNDYwIDAgb2JqClsyNCAvWFlaIDQ3 LjUxOTk5OTkgIAo3Mi41NTk5OTk5ICAwXQplbmRvYmoKNDYxIDAgb2JqClsyNCAvWFlaIDQ3LjUx OTk5OTkgIAo0Mi43OTk5OTk5ICAwXQplbmRvYmoKNDYyIDAgb2JqClsyNCAvWFlaIDQ3LjUxOTk5 OTkgIAozOTQuMTU5OTk5ICAwXQplbmRvYmoKNDYzIDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3Vi dHlwZSAvTGluawovUmVjdCBbNDA2LjU2MDAwMCAgNzQ0LjU1OTk5OSAgNDY4Ljk1OTk5OSAgNzU1 LjExOTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRt cCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRt bCMyM3Njb3BlCj4+CmVuZG9iago0NjQgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9M aW5rCi9SZWN0IFsxMzAuMDc5OTk5ICA2OTkuNDM5OTk5ICAyMDMuMDM5OTk5ICA3MDkuOTk5OTk5 IF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJ dGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzdG9r ZW4jMmRlbmRwb2ludCMyZGF1dGgKPj4KZW5kb2JqCjQ2NSAwIG9iago8PAovVHlwZSAvQW5ub3QK L1N1YnR5cGUgL0xpbmsKL1JlY3QgWzUyMi43MjAwMDAgIDM2MC41NTk5OTkgIDU0My44NDAwMDAg IDM2OC4yMzk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIj MmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1s Lmh0bWwjMjN0b2MKPj4KZW5kb2JqCjQ2NiAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUg L0xpbmsKL1JlY3QgWzMwNy42ODAwMDAgIDMxNS40Mzk5OTkgIDM3MC4wNzk5OTkgIDMyNS45OTk5 OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZD R0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjN0 b2tlbiMyZHJlc3BvbnNlCj4+CmVuZG9iago0NjcgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0 eXBlIC9MaW5rCi9SZWN0IFs2Ny42Nzk5OTk5ICAyOTIuMzk5OTk5ICAxMzAuMDc5OTk5ICAzMDIu OTU5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1w IzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1s IzIzdG9rZW4jMmRlcnJvcnMKPj4KZW5kb2JqCjQ2OCAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1 YnR5cGUgL0xpbmsKL1JlY3QgWzUyMi43MjAwMDAgIDM4Ljk1OTk5OTkgIDU0My44NDAwMDAgIDQ2 LjYzOTk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0 bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0 bWwjMjN0b2MKPj4KZW5kb2JqCjQ1OCAwIG9iago8PAovVHlwZSAvUGFnZQovUGFyZW50IDIgMCBS Ci9Db250ZW50cyA0NjkgMCBSCi9SZXNvdXJjZXMgNDcxIDAgUgovQW5ub3RzIDQ3MiAwIFIKL01l ZGlhQm94IFswIDAgNTk1IDg0Ml0KPj4KZW5kb2JqCjQ3MSAwIG9iago8PAovQ29sb3JTcGFjZSA8 PAovUENTcCA0IDAgUgovQ1NwIC9EZXZpY2VSR0IKL0NTcGcgL0RldmljZUdyYXkKPj4KL0V4dEdT dGF0ZSA8PAovR1NhIDMgMCBSCj4+Ci9QYXR0ZXJuIDw8Cj4+Ci9Gb250IDw8Ci9GNiA2IDAgUgov RjEwIDEwIDAgUgovRjE0OSAxNDkgMCBSCi9GOSA5IDAgUgo+PgovWE9iamVjdCA8PAo+Pgo+Pgpl bmRvYmoKNDcyIDAgb2JqClsgNDYzIDAgUiA0NjQgMCBSIDQ2NSAwIFIgNDY2IDAgUiA0NjcgMCBS IDQ2OCAwIFIgXQplbmRvYmoKNDY5IDAgb2JqCjw8Ci9MZW5ndGggNDcwIDAgUgovRmlsdGVyIC9G bGF0ZURlY29kZQo+PgpzdHJlYW0KeJztXUtv5LgRvvev0HmB6RGfkoAgwNhjB8ghgDEGcljkEHgz WSzsRZw95O9HrVarpfrE/ig11Q9Pj7FrmU2RxXqzWKz+/Jdv/8z+/Uf2+f7bf7KX9vf9t1W+zl21 /Zfl9c+nfoMu10bnm39ZqczaF03ry9vqPXtfPa2e6v+/r5RvXmx/1R/upsibnz9efl993k6+2rZ8 u/9b/fS/TGd/rf/7Lfv5H3XjL+14mw5vq7LyNRx5rkz952v/T2XyUq19/Vy35/LPTedfV3//Kft9 A5helw3wagtg/89PRmnty7rFHgXy+/7VdvQNskLP/YEnweddpq1XLnNK1x3L7L//Wn2vp99P7nNT aeV8GXzuT25MO5nNCl3ka1vPusG7sW6DzDx3dXtp1rpprwnglW06admui+YP3R/nNTD+hjbfezBX pv0XfB7A3Iet8g0/NDD35qq5YfMMsA3be2vpxnkNjC9hToTnAMwhGEJ0WQLP47R+G7TH4XmcN0K8 NIR5YWFyteLITOEzrVIKk9JeNzCqoTDV7cbs1FQPAaK9Q1hvnNfA+MmEqR7T+gaeIWPW7a5q4AHY +u39tezGeQ2Mn0yYhngOwByCIUSXJfA8Tus30R6D53HeCPHSEOadQa/AvE0THGtrM1QVtfyUWW2M Wrl5mmdrVfPTB2bbErC17wdevHtefX70Wa1Gnr9nWwg+bX89b6H+VINd+uz5l+xPG6D+nD3/ttq4 Fm2DbhqKfYNpGsp9g5U9tmM8PLfrXwbXzlTmCnHtbD37Mrie6ai9H3ixWZDauJJjK1K533CPqXYr 0lbAqx9Fg3VNg8q7FvMoW/SdwAsfVt/LQfIvTYuVqNs32G2Pat/jXoyqCkmgQtIjQKDeLFsCKXVg weZOQqIkmeWwyk+GRJWUu7Y9XHgM7PF1fFrJkGvd81PsqJ8S7hXDuBETbJnZVgFuNloJbr6Ta5Ns pyRjYkMpx4BBJddpf0aRNqUbIqGVowaa+cP6RlFYFRSkCOZ8EKynFMOk2o6hjBz1yNW0es9qd416 D5WLnqxLgBjwChIUNAUoU6Dw10h7aMOztBK5163INpTTcJbzsm8pqZ1GOm03MdVRsF5skHhH+gNG qpTC6W7C+WMK53m5dyHZLMKgAh0Ay4CQpFaw3AlaDmKkpEgAe4NY4SBGgxh5QR3zReLgJIKWkBaT pEbTxYGbPkOLgNTIxXENwAVthvIyEjC+K8Np+U6HKg1kB9AAHB+AQlj+oxAQvvNDOOjuUd2PL+5I FeEKJ1REEp3o9GZUt/lwXImcRkJQICBeIImHtAKDN30PDsSbo2SAzTi7c2UnF4d0gWm5DHGMAdZ5 YIcq3YhNwfWyFLo707Uf5yAcgytursrOhDGuuPlaTsLanHIml7PEMv+xetz4oSKf4akDRrSUOr6n 4FyGGJkh7A8JbZ8uQyhDoZoO6gxGRIEAwDgzUwOyjLsIcHBZ5qEZjkPgZaNED60+sB+z0MnINQsE JxUYaqAMX1w6HjpSl9kqX0CZceMFpMrPortmBI01QDojeB0wsmkMk93Z8uvZDeOgAdIdiSGtqyGK ku6GC7XjESexOGMvA1YUBuWnFbANRbsip/nQBm/EaQAkApp5KGsRDMFGHdQb7DMAhzTazwUPnHmE 9EH6DOgiyAYMS19sFJIfNCbAIcIBywdGhdAOKHMIQnE1BB7yF9kATAaAQSQz1kIeq4ZdOdTD3Lyj vaOnbtzfaxGQxqh0eYEYI+AWYjpXoXRTxRxxYshzp6i0c0UdoZdhtXza6Xo54nwUHCIeueOWnMsh P6flZ85Up0QIHScUj2OD8ZOrha28mXTmGkxS840L6W13oALsD+rfjQPfa3iQr/BBgZeBqSSpMC4H DTmd9guDFBvk8gF0I1P0jFyLmbRBYrTzweXx9QJWIeEQCAFpKTALJi2CxwDSDZmQ9BXAKryiQZdB Rg1wKuAjcFh+CA4wB8C6kyK3jP5FvOzmABqkkwayTg6sBu1QwIYcIAROC2MAZaR0RzAmrIUm4KLu BhTCLAF3oMcyEnQFKATAYPkwLUWyAXUgV2uAuQPO7iGJkYuzkNgGlIMegDHaY8ZaLPSQlLOTPHkm qFW8okaGoGgGEYqwhzSkBubPgMUEwEANU7lEvQwak+rlCEFdROlAtj2MEXAYpzQgXWZcAwD9ELiu cchMU2sICIqwhpA8BBwkexigC8xCVT0ujrst4MiBUwLeIdW5uPH9mlDpFDpe6RjgEG6WqEoxVOpm qBTA+3mv1vQaAudLk7gMGBOQTP1YjjELkMJqJV1Q+VHZRlGW014K5TD+Cj1AlIH64D/I1cIYKc/K inIXKkyS9X87Oz0Meoqz0zQ5C/1YUMwNP4U3/FRtJ7Qtc5e9dc9+rXLrMqWq5qE2KJvWom4o26eX GnK/LitnTd596Icv+3bcpm/zbJo3MvGq6cY1Td/BpPWHLVC7lzt4X1a/ru5+WuxKsmkucZZ5FaTp SRKELuXM8ZqzYVKoiRTx8o+c53watpwRc4+gSwLaRpxr8nOMC7kGgHLLRWx2Ivixd8daNa1tCEW3 7HG2lqvPHl86rTFdzvbNwAaX/yPkXydw1E3PUTejjrrpHHWDjrrpHHUzdNRNz1E3o4666Rx1g466 6Rx1M3TUzakcdVN9AEHim/PrzVpEBNHLlbe9zllU8fQrnDybKoKUkE7CPRXIUeBpv9xR71UPOU5X u3yvq50a09VO73Rq/SR1dfOhH77s23E7XW3LMV1ty9249ZPU1ZsPdT54uYP3NLradZWxaNAvInEP 2ORC9OytfAqhy4nKp3zkTdOJ8rp5sjCHlOf5crvDTeaMxP+rLlLValS/837PpVFT+B0UUiTm9HMm rtlH9oQJ71eVVbETADjfme5FJbFkM/y9M9X0gbUAl/F7T6cJRSxxZydC/XHZpoeXp7kY9mM5R22u 8KSqOBfiPi15k/Losh/FUKN+wNSFJDanUjrId1eU7hAhIwAJj93zy3QpjtC43qGGCkQz4mYkv+U2 PRqGXlggXfCQIzPdHEbctuPSvsTFuDlGhisIaOAu1/SrhPw2JhTAROrzEpkLblKP1Y+qGirIiLul XIPw28awXtxz8I3LaXZlAf5PY5h0EaQvd9y5HZqOoTnREb7D5pBOP1Psb0r334zS//aC8edBFDui P48CT5y0YYxq830rY7VNmkpuVefS4QVRUEiQ8T+9B9IUGrz0YPBOBL8BErjcfIi5lPSK7kWDklcP QpJThWdpr5X0Vsdh1xwy2QOXOzGBNelpRKOCXN4VjTpT9ddbLEWMsUgsZXqMa5lI6uzzyEne5Jm2 vSnOZ5eQqOsPAxzasZxnS79MouWMyPMyNdZ8robWYUk1ncKXdvm+HNxpVHsKzcW/1iCFyMwo283D 0+AczIhoz6iodRpS8vD0rSqjkEJrvRDDwC7j2HmcHc5zLr/1Qlw7XC0PR9IN+nkz/tPYA3cr7R3r yp0kBXKRDcXNo07PMOfyqPllUFgtPwHnJy9prJKxROlECCrHGT/fS4DmGSVII9A8IxD0A3hhR+e/ bdmuWKAUtlN5V1dBflHcDGY+UeXrCG0Gx3FLBBzRLYNpU+zCTiKqKWtuOnVM3caT1qk8ABiWUKMN WOtMMoRNiuYJ5RFvVdfYLJdadQ0K7WAhRzrorahYtEwdVckQ6jtRNCPO6KnkDMnFTQVl/4iSozAt /S5FXoKXl7dqMZaG3Do/ojo0ryEHZeewUiFoqkXwTlVXNKcmwruJx7vLU07s4uU7AjRqePDrY2lJ SF4UjhceTFFSHBYHrAk9wGeyACnwKngZtIQu1BjGIrtQDxeiCNRlhHLAmNoC2oy6DFioF0AHBIFk ygYgg0sqqn5CEe4ZErME6y5SmXOGPJypbvvCDFEuqkI5zlBEAKsBp2GSTgU0T1eQUBPTSh+CbyrT 0q5aVpgp3rG683RSgWtysfYQjVvgOkevB+UhKOUOUQZYHK8gb6G4tYTUAhxguqTEgDsAuzvQZZYb SKDtae2hUWdWf8t81QeNmPCAwIzazTzGBLNcjxkGnOKX6UGPwGUubuwTMbeesC8by2z+GNn5zqod HiKy82kPnnvfHq72stPbaAOcFPDrdJVkngMnhThv6/b4A9PIk6I5gMjF4K5Prp9fJGhFVOnwYvA7 HAKgCq52VfsPxEp+FsGt4cEazvTBr4A2m4sjtuxYE47stFwMhJsqSd1HyVVwR7WUDfKajoIefryH 1FFzMaGMGX478BVhAu6ryx65S4or42Uu3YXgSsO0C2OizRkrrg8Rqpe/Uv9k7zU6lG/W1f56eZt7 uegpe1r9H234uw5lbmRzdHJlYW0KZW5kb2JqCjQ3MCAwIG9iagozMjM5CmVuZG9iago0NzQgMCBv YmoKWzI1IC9YWVogNDcuNTE5OTk5OSAgCjcwMy4yNzk5OTkgIDBdCmVuZG9iago0NzUgMCBvYmoK WzI1IC9YWVogNDcuNTE5OTk5OSAgCjM1Ni43MTk5OTkgIDBdCmVuZG9iago0NzYgMCBvYmoKWzI1 IC9YWVogNDcuNTE5OTk5OSAgCjQxNS4yNzk5OTkgIDBdCmVuZG9iago0NzcgMCBvYmoKWzI1IC9Y WVogNDcuNTE5OTk5OSAgCjQ0NS4wMzk5OTkgIDBdCmVuZG9iago0NzggMCBvYmoKWzI1IC9YWVog NDcuNTE5OTk5OSAgCjMyNS45OTk5OTkgIDBdCmVuZG9iago0NzkgMCBvYmoKPDwKL1R5cGUgL0Fu bm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFsxNzMuMjgwMDAwICA1MzUuMjc5OTk5ICAyMTkuMzYw MDAwICA1NDUuODM5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJm dmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIu aHRtbC5odG1sIzIzRmlndXJlIzJkNgo+PgplbmRvYmoKNDgwIDAgb2JqCjw8Ci9UeXBlIC9Bbm5v dAovU3VidHlwZSAvTGluawovUmVjdCBbNTIyLjcyMDAwMCAgNDExLjQzOTk5OSAgNTQzLjg0MDAw MCAgNDE5LjExOTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZh ciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0 bWwuaHRtbCMyM3RvYwo+PgplbmRvYmoKNDgxIDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlw ZSAvTGluawovUmVjdCBbNTIyLjcyMDAwMCAgMzIyLjE1OTk5OSAgNTQzLjg0MDAwMCAgMzI5Ljgz OTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMy ZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMy M3RvYwo+PgplbmRvYmoKNDgyIDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawov UmVjdCBbNDA2LjU2MDAwMCAgMjIwLjM5OTk5OSAgNDY4Ljk1OTk5OSAgMjMwLjk1OTk5OSBdCi9C b3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1 MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMyM3Njb3BlCj4+ CmVuZG9iago0ODMgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFs0 MzQuMzk5OTk5ICAxOTkuMjc5OTk5ICA1MDcuMzU5OTk5ICAyMDkuODM5OTk5IF0KL0JvcmRlciBb MCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRp ciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzdG9rZW4jMmRlbmRwb2lu dCMyZGF1dGgKPj4KZW5kb2JqCjQ3MyAwIG9iago8PAovVHlwZSAvUGFnZQovUGFyZW50IDIgMCBS Ci9Db250ZW50cyA0ODQgMCBSCi9SZXNvdXJjZXMgNDg2IDAgUgovQW5ub3RzIDQ4NyAwIFIKL01l ZGlhQm94IFswIDAgNTk1IDg0Ml0KPj4KZW5kb2JqCjQ4NiAwIG9iago8PAovQ29sb3JTcGFjZSA8 PAovUENTcCA0IDAgUgovQ1NwIC9EZXZpY2VSR0IKL0NTcGcgL0RldmljZUdyYXkKPj4KL0V4dEdT dGF0ZSA8PAovR1NhIDMgMCBSCj4+Ci9QYXR0ZXJuIDw8Cj4+Ci9Gb250IDw8Ci9GNiA2IDAgUgov RjEwIDEwIDAgUgovRjE0OSAxNDkgMCBSCi9GOSA5IDAgUgo+PgovWE9iamVjdCA8PAo+Pgo+Pgpl bmRvYmoKNDg3IDAgb2JqClsgNDc5IDAgUiA0ODAgMCBSIDQ4MSAwIFIgNDgyIDAgUiA0ODMgMCBS IF0KZW5kb2JqCjQ4NCAwIG9iago8PAovTGVuZ3RoIDQ4NSAwIFIKL0ZpbHRlciAvRmxhdGVEZWNv ZGUKPj4Kc3RyZWFtCnic7V1Lb+TIDb73r9A5wHhUD5VUQLCAxzMTIIcAxhjIYZFDMJvZYGEv4uwh fz96dVvi19VfSV3ql2Vj1zZHXUWyWCSLRVIf//Ltn9mvf2QfH779J/ve/3z4tsnv8sJ3X1lef38Y AnR1Z3TefGWVMneubKHfXzav2evmcfNY//91o1z7wf5H/Y/bKfL2+4/vv28+dpNvOsi3h7/Vv/0v 09lf6/9+y37+Rw38pR+veeBlU3lX45HnytR/Pg//VCav1J2rf6/hufyzefjfm7//Kfu9QUzfVS3y qkNw+OcHowvjzJ3O7VEov759tB+9YVbo9+HAk/DzKtNFUbisUFWmsv/+a/OjnvwkU7uimbqsp9b1 g9acdPKW7rKwIbpdbrxWhauCvw+nNqafymbO9tP6WtqMLRoRyvOihuvud9+InVP2ztaIaQnXZY1h B9+N8xwYv5HIHwOcvem/gr+PcB7iZqoGnQ7n4VyFatBB3EbwAS27cZ4D40ucE/E5gHMIh9C6LMHn /Wv9MoZH8Xm/bIRkKRGfy8qXrRpUY3kuvcrbadUYBwHf4TwY5zkwfjJ5Lr027bRqLBulN67V9hK3 MXxAy26c58D4C/E5gHMIh9C6LMHn/Wv9MoZH8Xm/bIRkaYzzwnbJaZ/XpkHXD1ZoHLZujAejPm0i a2sj5E1timobVGzneZznYaj2e4hMBwl4GK8HPvjpafPxq8tUnj39yDoMPnQ/njqsP9RoW509/ZL9 uUHqp+zpt03jUPUA3QLKN4BpAdUbwMonujG+PPX0L8Nrl9vyCnnt8qJaiNcz3dPXAx9sCVKNA72P okI3wmOtGyNTSoIqSpDdAdRnMYYqJZe+SoAcVCk5S9UCignT5g90UDlG/kXOIhEzctC8ZAxSlUSM 0jIHdfgILAMwiGKKqMO0QMtnOWhBp+XESSYjYlKkYFANkgyzAOpyDJBk9UAZBLIuOcaZfDE7im4P 5elu4HgALSDasAyUhSZncorEUflA1Lm2DMzSqv8j9LizY0WOHIEt9IkBIlgEDAgIxLHkdWbKqe2o 3TTqgLxzFRqh3EAhaPkEVcNoH6YLzYw9w61hxL6j+tAoqkM6gD+KWm50rsZLwYXiUngmpySFRb1U pyShSB2p2qw3QreBGob153YImAhsjtXcR3nLuFSAOkiqHDRaQtLYmNKFMEMDQp2dCJ9iCfeQK25c fipkoB+1osZwho/F9yEgBgyiyj+FYUeeLugeXt6mi+CpNP3IsenkR/gT3BXidguegNXnu9JRamM9 n6NNTDFWbREmRqKmc0kv9Rb5oX3OcRpcHUAdAHTnoiOz6DHG70w9CDO1BhGym8A5TnKK4cofdioI 2RKHFtyp3IBI1HE7TFdlGJJIcayJOBnPMLHcF5xuUU+kyqcfuLjmRj3FQ4echWc7grhS6CVQ1NzD BJOyiBPGWTRjuYFaSgvyA6YFWi4lQnOfzpIVym9HvaV7o+uNcqMjM90ZiohhwRFVqsMZ2sB2eCj1 Jrodh1T+BvkkLQaI3UnudCJc+xk3WNMDMIBHBOrTYwURquw8++FMGgRXbpJKtT6gU51vdKrLxV38 ABMAcCV7KQDAlBO3AlbAbQj/KbdYIi2kVfxC2AsRiFvCdAVcCWAVqX38SKSFzARf6HoWQmLaZ8hN UvbwETiS0BQAQEwFbusHHwmEbAaAXH4EzgbAD0C9omPcJ8ADaAE8vk4eI4ekKsCDX4LxeyJYfS78 CZgMxGHEKhDzPzlPk2qhIqUvdK5NdsX6cgVcCeAkIqWkSoHtgZEjqXT4Ry7PF3LvwxfiOVXUF1Jg uLgvNANATSyGZwEAmh34QZdSAx7SXsKtQIRBSeClnAYQipKfX7QvBZBUC1VrXGgFrIBVpM6qhfx6 R7YCVsAtCf/l3ZGFugDook2XK60ds32QD9H5+e5tXpl2YCB/FPIyukPMIO0AWgvIabVsLWA7+m34 I9CNQMETgcw2KCUaALxAnU8bQS3kGM3AA2iBQWEpjVxKutjIwk9ylu48CnlMSZLyykqMelxSnkz+ wZQaWvcRkZMLOVgwC8+f4iVNPMFyRhEcLZNMk6Sri1ys7nRMIvKjgM08tWtGOWYCOeT1aXMkNUHN a4RgAgvhhkOOYUwKGXKuEaEq37avwQoEJxhikigmlXcTa5NSM52pgPuKC/ynb921Qklw/V1VKEX0 0EhQJL5I94IIq3RZPZYSqVhThTiSsDHTsbhagSsad16NjnVui6iZ07S3oh+BfRbRrIc7pkBcktqg 3ssotsYevAz9eVEvw4nufEd5GaudOYeduWmf6nq6F0V0+EjhIfDaSahzo9uD82MOYrwV0QzX5X04 JpUJSVkSkzqwXG/NartXGuRtJ+L9v49arEY8zxuwTpy0ZZ5vWuDui/m0rPM7S6pBHd3LjcGfgERQ +QRKFwC6MQa1mjlENANKbvDEgwR0cjAItX7ZvyEHcgB5K4EgIGwV6EpzIFypKyAXzjAycIIMCfQQ mBJ7AHIBdwV4zCAGMNPAIspEpG4QwTpTm2NfbW9ssJB4eux0zuHhUg39TXlkCfzgOV0alyjwntF2 ag2uTV3sRZomcNc5on8cFwcIC4BI8XjtDBbGluYfe6FZ+LHevkHBTHLn27yPIUTMScKtSdougZjN SP7lT9zuScHlbisGKU4KoYKw404KUO6E9U/UH0XnEublHistury0g8EZXWencsHZa7y63XNnAJLF Qw/T4zeXcid23j7Z7/ZSJUHXphSO35z27e8rcYeXN/ODAaoY4BC9QsBuzAGdc6zv6L3Q7eles5PC rXWqcXaOlERpNUeelt3v3gWfirGuEROQIoeyFMTLsKeGCj9IIONF5SfpdgBepubenmxMwAEwhoYn 6N7W0KkgsHEPHYOnV+7jMsDa0qLR/onz+IfGKiGt0y0AKjzuqc05gnKf4WwteI1QeH2V+6D5JTre EgBl7pfreCYIDUd0IYWiAthstNE1DJowE9epXQnJIjFIW7KFiW7cmuQS2KliF5+Q5ZFayq4t5AbA frC92YMKmAPD9gZpuK9oVMPeS2+Txz95x4ETNcCd0as2Igso3dHyCv0zo9VYmvFEt0RPHwO337C0 IJcBV+EoPEKH4kN+0P61zk7ioVhXjJcrYZqjU2UR2jXzm+Yn0rZ+NyzoUnQVpCIB3YqDGA26FOpH 7iUPeAw5RYDxil9gMP129kQv1bsU33HGq5imF7FFvBUAjhf8tSHpOrofG18pC6Ei0r0WwmmVMgP7 TJcFS72P4IoTa/hSrdViTxeQ0HIpWfy3pJhPVebtdCFUaErFvHs9uIYLthmv6gT7D4Py6xEsfQbt DsFdXpVwvYmXp7qjfl83e7cdTE13azfJDE+PUEa8aY2rIYhhQpQXhCyQPzTD2h2d0FiN9XBEkjDY O/ry3uhQeRqjsntzObaT4BZiRtMW2N281ItnFvKwKd3tXFHPyR3i0ya4b4twzHgtHLfkfB/ynAz+ 6mqqUyI2HV+oBO+Vg3czTrtbOtwk0RktbBsE+wbqH1oog02R1+PYdhgGBVkGoVqiU7GW3Z8BUwRI 8gF1I+/+DUTnJ1VLsrUzRfza0dc0YA9piTxck8Es2Jh6ia7rwFW8wKCXD5DIwZNjYBbEg6dpfEm5 /kX83r3pN3tECCbQAmIH4s9zoWCWgDswEBnI7AEWAmJAPkxLmWxAHUhqDQh3wNk9tGMkcRYu2mHl 4AngGH1iBi0WnpArZyd58myjunhFjQLBX2xD9WHEdW0gfjJgEVhMQAzUMN2Xa9IiAaxJi0IKYV0C nQoOrT4Qx90WcOTAKQHvkOpcPPh+Tql0fLzSMSAh3CxNz0TBJ6arFOD7mlXDNuq+rJq7phi0/QLh kv8WUaIYHmzbInt/Bkrlx81qsS9FR93bgbr3n4YxWtkmrN//TrIZ7l8H91r7jf1cuqw342tzLelC lGADekEFsCKHa+WK0angCbf/iVScKLQf31NdESfgikE+0ac6tbyqv7PXmmPKtaT3P76/zM1je8we N/8HSnOKhWVuZHN0cmVhbQplbmRvYmoKNDg1IDAgb2JqCjMwMTUKZW5kb2JqCjQ4OSAwIG9iagpb MjYgL1hZWiA0Ny41MTk5OTk5ICAKMTM4Ljc5OTk5OSAgMF0KZW5kb2JqCjQ5MCAwIG9iagpbMjYg L1hZWiA0Ny41MTk5OTk5ICAKNDgwLjU1OTk5OSAgMF0KZW5kb2JqCjQ5MSAwIG9iagpbMjYgL1hZ WiA0Ny41MTk5OTk5ICAKMTA5LjAzOTk5OSAgMF0KZW5kb2JqCjQ5MiAwIG9iagpbMjYgL1hZWiA0 Ny41MTk5OTk5ICAKNzU5LjkxOTk5OSAgMF0KZW5kb2JqCjQ5MyAwIG9iagpbMjYgL1hZWiA0Ny41 MTk5OTk5ICAKNDUwLjc5OTk5OSAgMF0KZW5kb2JqCjQ5NCAwIG9iagpbMjYgL1hZWiA0Ny41MTk5 OTk5ICAKNzkwLjYzOTk5OSAgMF0KZW5kb2JqCjQ5NSAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1 YnR5cGUgL0xpbmsKL1JlY3QgWzUyMi43MjAwMDAgIDc1Ni4wNzk5OTkgIDU0My44NDAwMDAgIDc2 My43NTk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0 bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0 bWwjMjN0b2MKPj4KZW5kb2JqCjQ5NiAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xp bmsKL1JlY3QgWzE3NS4xOTk5OTkgIDcxMS45MTk5OTkgIDIzNy41OTk5OTkgIDcyMi40Nzk5OTkg XQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0 ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjN0b2tl biMyZHJlc3BvbnNlCj4+CmVuZG9iago0OTcgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBl IC9MaW5rCi9SZWN0IFsxMzAuMDc5OTk5ICA2ODguODc5OTk5ICAxOTIuNDc5OTk5ICA2OTkuNDM5 OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJm Q0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIz dG9rZW4jMmRlcnJvcnMKPj4KZW5kb2JqCjQ5OCAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5 cGUgL0xpbmsKL1JlY3QgWzUyMi43MjAwMDAgIDQ0Ni45NTk5OTkgIDU0My44NDAwMDAgIDQ1NC42 Mzk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAj MmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwj MjN0b2MKPj4KZW5kb2JqCjQ5OSAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsK L1JlY3QgWzgyLjA3OTk5OTkgIDM1Ny42Nzk5OTkgIDI0NC4zMTk5OTkgIDM2OC4yMzk5OTkgXQov Qm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1w NTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjNJIzJkRC5p ZXRmIzJkb2F1dGgjMmRzYW1sMiMyZGJlYXJlcgo+PgplbmRvYmoKNTAwIDAgb2JqCjw8Ci9UeXBl IC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbMzA3LjY4MDAwMCAgMTczLjM1OTk5OSAgMzcw LjA3OTk5OSAgMTgzLjkxOTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMy ZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMy ZHYyLmh0bWwuaHRtbCMyM3Rva2VuIzJkcmVzcG9uc2UKPj4KZW5kb2JqCjUwMSAwIG9iago8PAov VHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzY3LjY3OTk5OTkgIDE1MC4zMTk5OTkg IDEzMC4wNzk5OTkgIDE2MC44Nzk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2Ej MmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1 dGgjMmR2Mi5odG1sLmh0bWwjMjN0b2tlbiMyZGVycm9ycwo+PgplbmRvYmoKNTAyIDAgb2JqCjw8 Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbNTIyLjcyMDAwMCAgMTA1LjE5OTk5 OSAgNTQzLjg0MDAwMCAgMTEyLjg3OTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMz YSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRv YXV0aCMyZHYyLmh0bWwuaHRtbCMyM3RvYwo+PgplbmRvYmoKNTAzIDAgb2JqCjw8Ci9UeXBlIC9B bm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbMzA3LjY4MDAwMCAgNjEuMDM5OTk5OSAgMzcwLjA3 OTk5OSAgNzEuNTk5OTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMy ZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYy Lmh0bWwuaHRtbCMyM3Rva2VuIzJkcmVzcG9uc2UKPj4KZW5kb2JqCjUwNCAwIG9iago8PAovVHlw ZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzY3LjY3OTk5OTkgIDM3Ljk5OTk5OTkgIDEz MC4wNzk5OTkgIDQ4LjU1OTk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYj MmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgj MmR2Mi5odG1sLmh0bWwjMjN0b2tlbiMyZGVycm9ycwo+PgplbmRvYmoKNDg4IDAgb2JqCjw8Ci9U eXBlIC9QYWdlCi9QYXJlbnQgMiAwIFIKL0NvbnRlbnRzIDUwNSAwIFIKL1Jlc291cmNlcyA1MDcg MCBSCi9Bbm5vdHMgNTA4IDAgUgovTWVkaWFCb3ggWzAgMCA1OTUgODQyXQo+PgplbmRvYmoKNTA3 IDAgb2JqCjw8Ci9Db2xvclNwYWNlIDw8Ci9QQ1NwIDQgMCBSCi9DU3AgL0RldmljZVJHQgovQ1Nw ZyAvRGV2aWNlR3JheQo+PgovRXh0R1N0YXRlIDw8Ci9HU2EgMyAwIFIKPj4KL1BhdHRlcm4gPDwK Pj4KL0ZvbnQgPDwKL0Y2IDYgMCBSCi9GMTAgMTAgMCBSCi9GOSA5IDAgUgovRjE0OSAxNDkgMCBS Ci9GMjQzIDI0MyAwIFIKPj4KL1hPYmplY3QgPDwKPj4KPj4KZW5kb2JqCjUwOCAwIG9iagpbIDQ5 NSAwIFIgNDk2IDAgUiA0OTcgMCBSIDQ5OCAwIFIgNDk5IDAgUiA1MDAgMCBSIDUwMSAwIFIgNTAy IDAgUiA1MDMgMCBSIDUwNCAwIFIgXQplbmRvYmoKNTA1IDAgb2JqCjw8Ci9MZW5ndGggNTA2IDAg UgovRmlsdGVyIC9GbGF0ZURlY29kZQo+PgpzdHJlYW0KeJztXUtv5DYSvvev0DnA9PApUsBiAdvj CZBDAGMM5BDkEEw2GwR2ECeH/P2oJbVbqk9UUWyqH7ZsJO6uochivYtkUR+//fJz8f+/i493X/4s vnZ/775sxFbYqv0pRP37oQ9QfquV2P0UXupt6Rro1+fNS/Gyedg81P9/2ciyebD7U//jfgjR/P79 9Y/Nx3bwTQv5cvd9/emfQhXf1f/9Xvz4Uw38petv1+B546uyxkMIqeuvT/2vUgsvt2X9uYYL+nXX +LfND98Uf+wQU1vfIC9bBPtfP2jtjTE1xB6F8svh0RoLXSlpSx/83O9Y6w4fU5Sl3U1BiKqeujbd F1uUzm/NDuGGBqU0u29SUbhyW9XCD/08BfrfkefXHs6V7n6Cnwc493Cr5G7UHQ7P/bGcMFsxghuB H+Zy6Ocp0D/FOROdAziHcAjxZQk6j/P6uQ+PpPO4bIRkaYhzqy075Q997uM8S99KW6gao6rQriyU 0MVf/6uHfsjBZOtVSwE/VCbrddm08UMCEPgrwXr9PAX6z6ZM1puq+eyHgmlrfBruAG4DeG8ur/08 BfrPpkxDOgdwDuEQ4ssSdB7n9fMQHkXncdkIydJJlckJ5wtboyBNTmWS0qrW8w6VqYa3jeSQAAT+ SrBeP0+B/rMpU91n+0UOBbOG28bWIW59eH8u+36eAv1nU6YhnQM4h3AI8WUJOo/z+pnAY+g8Lhsh WRrivA9QKwjX5imOMbUbsjV9lC+k3evNQ1rsKJvfPjItJBA7vkw8ePu4+fi5LGqf/Phr0WLwof3z 2GL9oUa7Rvjxl+I/O6T+Wzz+vtmFyh1ANQB3AOgG4A8AQ1u0fdw/dvNfiNaVcNdI60r6q6O101Zd Ia2dLvVCtE5M8l4mHmwmJHdp6NiMagbUwmNsOUTG0Ql5dkLmALijLRwF+AZgJ0b5RAH39JHPhPRS UNQBDxiW9gHDSsnNVnqW4xR1BZiyj8CwpkVMyleIbicjxQFy20AqKmpuYd7R2SARWUbIT/OZyQvm fNSR3RQx6agMgVAl0ONmxCZs23Uu0QTl458HFiOiPW9PZg7aWJtqZ9FHjI0qm6hA7Y2NAp7eEGpH tLjhWqAYAKCkuiTBDoA9AqZSVAGA40qqn3cEIG2kblXhUZSns+NxVzxmtAVOV5/dr1nr9hO6pQZG sVKRwVqA1ULzAYYOmEMdDHocHnWQZ8sOy3o+dFK0D817E3a2OBfAA5wHSyD0wMAo1qzLaj73KU0T +jhXMAWMoqh3NuPUGrUGl8NhcwSXvEYhYgmaPV9fukcan5LuHMo6lxx4hyXN9JG4do7MqdOadiAI yzw0ZTyFgKi8HpbsKLxJhU6XETPlDOEdH5qWXDTHO12MbPhHgLtgMs8TYkAGK9u59JJcYSlkJBG+ Iah0eUW/mywsN4awXCseXz4r56U+QcgjMllq0yN0HFqwMn+u0PyU0WseJ+BdkEKAKrAfmDvfcJ5o 7eMtrUlliAEjotUMGRFvLxbJmZZMGo5UOq38UOvW1INBPUvqwZplnC2wgfaBvi9fLmLmzBYACbo9 P5qTt5wURhAoYa0ro+8rxT6iWvMMyDOkHZKov3twNOH1K7I0N0nQCA05AQhN+4jsUY1KLx/KRBgz CG2XWJjFOA2Ghblcqr5rPUeoTBVae6kaqfLVfhwQIog76A6PghYAoNsmsI+kPQVQdYYWgJihzl2z AOhDUoEwOcnshIkmM+7fgN4J2oLSTNL58o+AnAEzNfAfEKPDqs/cbAVtAZ3iKOCrQavAaQAeMH3o lKU6yLIBo2Jmd6qhBcwFNlphcmDLKR7AKKAH5NwaVBmUHWYLputTTp2S8aYLdYrSjCcz0ozdvU3Q XMwpWPHnlQyHBccEcwFmAqbQB4idysluHW9Cwe2ElmV6onlP+6AAtFSL0J01XdGSmonuZTzdrcg5 sIvX7wjUWMcDdEUAeFWwqxSgeccD/g5GYZ05TA5EE1pAzGQAU5BViDLAI8L02RaKKgA4UdBdDAip quIRILBmbMigATFAHQgEmkkBwAabVVWreFVN0ZglRJdXkISwM0EfMHSFgBDsP7gM1lXzmGYVCC8W NaE8zVBFgKqBoGGWTQUyzzeQGgwkjSH4pDIv79SiynwmeQfeoYSw2QyPGJ/eYAs6yvXYEKCpBBJC C0CM+tSQpcok3DreMNmx46tv5Ah2pfZ0iDhgDTybf8Ba4xkNCKbY4/wRJ47vKSLsqeXQaQSpqJkv w2Yee6WT6VA951noqiSiflSNz7mOAsBSF7tufZqtPtzYiJXnKUwzbONCbIz7Cfz0eb4EBH5qT4KX MUiEaaf8Pg8/LO7zwLYd3cVBPPjDEwkH6uZr5RUzO0KzcxD5RCeMrSmJzYWBQbhhvqDs7Pm8hJo4 PCyJayW3WUjSeiG3Lwnv1mh6UsRv7MN2Kr/DnnDKbb7ZWQsb5rql05wu6rLrOWcLU4qrEgx1wlk6 9vApf3JwyZO1NLYdZCpmNFMJt4qJgSMGYJJCI6lNgs0XfgOP3VrLuNR4nvzBVIRMqM3snlxEIAIH fyJO/iWcLzylTixSLpHHD1eSGWbCZfLniyIcMyVIxEngDOWU0c79SCrLUhMyA/JAVUD+JAFvRHST AfUsQQTvI6/HMEUU1PGxbI7acZYgKCD5jpc68XqaRoH9SzgbfabzpilVDDC7iy2vT1gee9PXHpxn pYKvjYQD2iN3BNFCSByXL+ADmzo/qUpI/xZJQ695wSw2cz3WTns9NNQnXafJ42Rez/CdKvxTHdFe Bz7N5Rhn2pUZiZBAOHnDu+DCy7FV3c2uaV+MQMDZtVrkBDxiqD3P4EZG6uVh948CcB//YkOT07hi SiDwojrfCrkTZm9ocYWcr69l7WrE3QJ8BSar3QmbrhHDAuqsGvIpQ0TWze4pIl8Cd8FNZXsQAfBV rXyZV47dcb52DGwdnS2sw+csJnNSkKtvexRhj+hDAZaEo1F8pyDLSxxZvbDCuEy8Uzqed1CBBIrI Vo9EFE/wRUug3bApwD4CVD3XIT7AA9wBiO59Tv7reN1dKxTnsvtSKhRRlgN+aA4A+QIt2NVfrLYK LO1OaT+rZHhgkFcytggIWqwlnNFGp4w3Ope+JTxB9wjRpZgaOizUJ2CxESv+6IQpYgnDLnOAn8ph Cj14xIAvgTXXo/BYRHDRPGYQ3ITJYaDH85bKKZQiiqxJiY8PbDXkIIAab6jZkFNBQgn8Z+tK+VFy xA9gyTBtAd8PAgH8pzKEpaiQ+oAsgxzyETdUfAEb4BHQB7ZEGDTGQhkZTA6oDqkxX63D4oELUjA5 EH5AjPLWgjOgQgfVvNACwkkovMUohTd+0EeAyJlsTBUfx1hKEczrWUAoFZxSduiDT3zBowIj5gf6 vM2NqAhlC0B5b5hAdQuzBbtNp2/4hSDWkmFRPQScED3CI2AwKMUStB/zPjBcUFQJs4W7K+ZbVDT1 MEqgUGwiOAJ6gJeygZgsy+aDstUQs/WFGfs+1hdmDFusL8x4nK6jWF+YMS0wV1xX8j5fmNHzDpf+ wgy3e/fCSU17DssFiEFYe55T1O/rnRPru08yaKFpCmD7ahi4NeLYcawZjvMe3iYxdZzl7b0ZIo8/ 8EHXtb5N4ujg5j28TWKNqIMEenvvgTjWK2nDGJ31bRJrFIbm8dii01bstCBB11u8w8zpQ8iX4Yay bnMU7vjxYUBnbioqO1DBeWjR7SBNXD8WcbcYzOX63159xnvRnBH7aw3WJW/S6brkPR1vrUvenHys AToz7BUH6O9iyfvgHS5+yduoE5v2dcl77iPrkvfj5SRbCy1599Rw0SXvwzjrkjfn/t/lkrfRQde1 LnkfHdysS96zJWiNqBmhewNL3hNGZ13yXqOwpZa8jSVBF1nytlX3A93Tf4tYyg531uBahlBtr1G1 bv+aZgUvVFYEAEUs3QHzkpIVbueCd1H0APQyBgXDllQixqsWkimh9fCF1ddDCTluLFMp4eTwYqHu 4H5vVi5pPGV0YERPRhTjapg6IU9uStKwOYHCRRmHzKe8VuNH3tOpIpVblCxSk4vIQDgl3TzpXMwE FeT4PZxHUMGZZangKnKPVmAbqkeW7v4q2FTrAdJUMkwGpfSiZFDKk8vhuncOibAKoHjcUGkAraEt zPh74lKnoUt69O5qrHhmf9bm24dt9+shRGZ31olEb2nqaiixiEgcwtLrIURfJOrf4qUmhyybeXV/ vj6n7tU/FA+bfwHy1O/HZW5kc3RyZWFtCmVuZG9iago1MDYgMCBvYmoKMzE3NAplbmRvYmoKNTEw IDAgb2JqClsyNyAvWFlaIDQ3LjUxOTk5OTkgIAo4NC4wNzk5OTk5ICAwXQplbmRvYmoKNTExIDAg b2JqClsyNyAvWFlaIDQ3LjUxOTk5OTkgIAoxMTQuNzk5OTk5ICAwXQplbmRvYmoKNTEyIDAgb2Jq ClsyNyAvWFlaIDQ3LjUxOTk5OTkgIAo4MTIuNzE5OTk5ICAwXQplbmRvYmoKNTEzIDAgb2JqClsy NyAvWFlaIDQ3LjUxOTk5OTkgIAo3ODIuOTU5OTk5ICAwXQplbmRvYmoKNTE0IDAgb2JqCjw8Ci9U eXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbNTIyLjcyMDAwMCAgNzc5LjEyMDAwMCAg NTQzLjg0MDAwMCAgNzg2Ljc5OTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMy ZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0 aCMyZHYyLmh0bWwuaHRtbCMyM3RvYwo+PgplbmRvYmoKNTE1IDAgb2JqCjw8Ci9UeXBlIC9Bbm5v dAovU3VidHlwZSAvTGluawovUmVjdCBbMzg0LjQ3OTk5OSAgNjY2Ljc5OTk5OSAgNDQ2Ljg3OTk5 OSAgNjc3LjM1OTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZh ciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0 bWwuaHRtbCMyM3Rva2VuIzJkdHlwZXMKPj4KZW5kb2JqCjUxNiAwIG9iago8PAovVHlwZSAvQW5u b3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzMzMi42Mzk5OTkgIDU2Mi4xNTk5OTkgIDM4NC40Nzk5 OTkgIDU3Mi43MTk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2 YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5o dG1sLmh0bWwjMjN0b2tlbiMyZHJlZnJlc2gKPj4KZW5kb2JqCjUxNyAwIG9iago8PAovVHlwZSAv QW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzM0MS4yNzk5OTkgIDUyNy41OTk5OTkgIDQwMy42 Nzk5OTkgIDUzOC4xNTk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYj MmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2 Mi5odG1sLmh0bWwjMjNzY29wZQo+PgplbmRvYmoKNTE4IDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAov U3VidHlwZSAvTGluawovUmVjdCBbMjk2LjE1OTk5OSAgNDk0Ljk1OTk5OSAgMzU0LjcxOTk5OSAg NTA1LjUxOTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMy ZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwu aHRtbCMyM1JGQzQ2MjcKPj4KZW5kb2JqCjUxOSAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5 cGUgL0xpbmsKL1JlY3QgWzY3LjY3OTk5OTkgIDQyNS44Mzk5OTkgIDEyNi4yMzk5OTkgIDQzNi4z OTk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAj MmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwj MjNSRkMyNjE2Cj4+CmVuZG9iago1MjAgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9M aW5rCi9SZWN0IFs0MjMuODM5OTk5ICA0MTMuMzU5OTk5ICA0ODIuMzk5OTk5ICA0MjMuOTE5OTk5 IF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJ dGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzUkZD MjYxNgo+PgplbmRvYmoKNTIxIDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawov UmVjdCBbNTIyLjcyMDAwMCAgODAuMjM5OTk5OSAgNTQzLjg0MDAwMCAgODcuOTE5OTk5OSBdCi9C b3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1 MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMyM3RvYwo+Pgpl bmRvYmoKNTA5IDAgb2JqCjw8Ci9UeXBlIC9QYWdlCi9QYXJlbnQgMiAwIFIKL0NvbnRlbnRzIDUy MiAwIFIKL1Jlc291cmNlcyA1MjQgMCBSCi9Bbm5vdHMgNTI1IDAgUgovTWVkaWFCb3ggWzAgMCA1 OTUgODQyXQo+PgplbmRvYmoKNTI0IDAgb2JqCjw8Ci9Db2xvclNwYWNlIDw8Ci9QQ1NwIDQgMCBS Ci9DU3AgL0RldmljZVJHQgovQ1NwZyAvRGV2aWNlR3JheQo+PgovRXh0R1N0YXRlIDw8Ci9HU2Eg MyAwIFIKPj4KL1BhdHRlcm4gPDwKPj4KL0ZvbnQgPDwKL0Y2IDYgMCBSCi9GOSA5IDAgUgovRjEw IDEwIDAgUgovRjE0OSAxNDkgMCBSCj4+Ci9YT2JqZWN0IDw8Cj4+Cj4+CmVuZG9iago1MjUgMCBv YmoKWyA1MTQgMCBSIDUxNSAwIFIgNTE2IDAgUiA1MTcgMCBSIDUxOCAwIFIgNTE5IDAgUiA1MjAg MCBSIDUyMSAwIFIgXQplbmRvYmoKNTIyIDAgb2JqCjw8Ci9MZW5ndGggNTIzIDAgUgovRmlsdGVy IC9GbGF0ZURlY29kZQo+PgpzdHJlYW0KeJztXUtv5LgRvvev0DnAeMSHXkAQYMYzEyCHAMYYyGGR QzCbTbCwF3H2kL8ftSR3S/WJ/VEU9Wi7bex2myORxXpXsUh+/PP3fyT/+j35eP/9P8mP7vP++yG9 S7Oq/UnS+vdDv0GXd0anx5+kVOYuL5rWH8+Hl+Tl8HB4qP//clB582L3Uf/j6xBp8/v7j98OH9vB D23L9/u/1t/+l+jkL/V/vyY//b1u/Lnr7/jA86Gs8hqONFWm/vOp/6cyaanu8vp73Z7KP48P//vw tz8kvx0B03dlA7xqAez/+cFkKjPVnU6zWSC/nF+toTCVVlleOr/3Ozamg8cmurJ3tv36fDA2O84n rQEzaXGn2/YaB7lqnlJatuvmr7q918+To/8jen7pwVyZ7sf5fQBzDzbdUKSD+TxW7+sANtF+nsu5 nydH/xLmSHh2wOyCwUWXJfA8TuvnQbsfnsd5w8VLQ5hbaTkKv+t7H+ZJ8pZntW5JszIxRZ5oVSb/ /Wc99EMMIitV6arVCANhqtutbiY9RIBoPyGs18+To/9owlT3mWXNuEPGrNvzslF8AFu/vT+X136e HP1HE6Yhnh0wu2Bw0WUJPI/T+lm0++B5nDdcvDSE+dWmVmBhpgmOrdVMYauylp9EZa9y8xBm7lTz 2wembXGYu5cLL35+PHz8licqTR5/SVoIPrQfjy3UH3SRpVXy+HPyxyNQf0oefz0crXvXoJuG4txg moby3GDlE20fXx+7+S+D69KmxRXiurS1Ul0G12c8655RGP8+8KQ8nqfImDpog6rqSL0RVOm84Ur9 Okv9ReLhU9NgTw06Z090qLvQoL42DSo9P1I0LdX5EQkINADJ1D1taEfJ3MPqjMGuyxZ2NQEQrcQw 6b2crnwC+uhGGfLfNF/95cKLDZeoYzQxxiaZbtgkU0Nh6EmHZtRBroAZFrKhlOSCUYApvspXvgnR V6kEHeCAYWUfMGxHvguzVSXVOBJ0DZDSVxDJMH0JBwIGZAD+hlcobTmC8JUvElLZwAHzgBSIDbTN 6LABk5OvqIr2AYB9XoJxHTrTXAAMuBAQpKe/ApQD2V+FlJ3qvmTdgmnb6PIZSjkvhloZBYSSG9EM SARSSf2Aw8o+ulHmzrc1Qnnubx64EZrOiCh2AVimgCnpZnUOwSSlK/kOGRHMA/B/gNhNJwMqCMCp VEOol+AVK72uCLNF6oP7ACwFdGnxocwFDAFSqe2PYesWIa6HveSGC1QKFQeQIGQQkA8uY9AHcO4i 8oEBE3jgskF9W8jqSDW8qQqNY1PKkwmlOsODnDzSgSdAMQOGoEH2YVIJWCaZxspOjJLv8LgF5s/j J/AYqKrycGUAZZLtTBQOyZsMSX7O260Sp9iCoj3YuZ2JEJW2GNH21WhaaUWl5rHAieabbNGfhaDx bvU9aEWei1oic/GmQtVFMgY0ug3xd2P4Jrck1GXQQ5JQnyLqXVM5ERKB+7maBTZE3yWKmXnVqtn7 1arBqJ+UNFvFX3/TqhrNH3fnqLOGoIMJ5VoVIr6AydEcQaQwygp5dwnZ3HEyOxzHtuPAWtSljC9l Gm/WjKQl88rJJZw5A4CfntDzeIVHlvIJD2Mc0/aW1jWMkdoLVTPMbnqaAK2zgzCRuKp65SoPI5lL KcJgu4Wtt1CMLdCv0WDBwRzvxmKjogD6gLXliU7owyNbGqzFp/jGIcsrkGHkUd5GHstbimkp92vo lMdwNK0NStEj8Q96E2VKDuOxIunLD3H0ZqFOMQsNa8N9C1n4Mqh8sqfvohjG8ZRPgYzHAC16bOXC T1vzd8aPgfgzG9f/0LBN2Y8qBIFDHHuQThA1utYVokeA5XmG5aZXCeWA+nyFlS/bTterMZzNGC6D RwbukjILl0tbFkIueU4S9Cw1cB5VO4AA9NXWSa9EcRpXNpvGn1u3KkIB+Z6e+sGSCq5neIqZK3Oe +uFeokyeerjiHhLB4/7pk4noFE4xZrfVkuGw4SW7cy1CVQx1ivksRHekhMRj/cB8EhMayTXwEilq NxBvwAPU0dxcn9tsUQ9mFZ5fxrJy8nqUyPCwgSs07vN4zI7X+05P8nhABgLg2CFzYbHHY3YetXmL FLjxOBJsLzVGGGvQuSyTwYiYlC9yN8usUna//8qkojgpYrBwWBQp8+Dg9I2YSUjSp3I5AOzmSmvo b3krhkd4AoCB9QIdySu++RIjh5SuTCMKedFkwOp2QAU4UA7mwitCA5ZjaFCI1H/LuTePYTnD+O5/ iKSHq/kewlxIjBpCgjgJ2ZzxvuNizOjwHS8BXuWtymg+/9s8E5IY0RUt08wfrXzzasxYvDwdaLAj F9AjR8frJ/grAStyPOjnPhBf19lm91lE3pzleBtuI7jjHZDl3kmhPbpetHgogHE9RGyJNJLHOuj0 xZf9FYBH0s3mFJ4HR7yz3UIzhGQlJXEr7Rp2usjJGm/ITfTW1bNXj1IhmVEEvt1cW+ZmtrxfWly6 ov33HNQYtenc0kKmgEtEvJAmsnK7HS4w2zWLeLjArLzyOkUtEfNkMXj7CutaO71elEN89dAjCQkN eJofTzMDy9EVUTg0ocuYga/b86mBO6S/7Op0oxLdMhXECFjS5ucCeazPL7J9cxHvDrQqN1079t3a Izx7DLDO3p937ocFFIdxofLYUEULzDrOjOO6V9YJCHezeHqPKhXzVQwLZW1eqVlOPAA+wql3HiXX nM1W0iI6rQTBNzpMjldbBazg71ZXeYjEOrtUaOEEko7XdXMpu2LB5Pv0uKqGPqjpxrhrW1aOYmaq 0+FaHsfReniz0x2AgON4Q1g1goJcpEDRhbG5RkWZIXnfdgJseqyyI/dmOmviKFR7jcAeUKLsAXyE 5epVBe295IhXFZE4tul0zCHaJs67HnWfPHxdp3KYlp957MDh7q1vhnvuAm9VCuLtNgQIyWjxq1B4 pwHb8j0yizx8WSJICnHfIlR1cxOB1IbwPeJKa1V/RNQI76qodaP7WfBIqJE9mGDxgLo78QB2vzx5 hYttJheyjTdDycmi1/Fp3OxesiAwCl1Lw/U43seXUbIkqyyd2baMuac1r2cNm4sRzd+G7I6lK2c8 xxVnfULpJl9d5WLZM05h4Lnbje4DWPIgrVBv/LrUptaloCSoK7ocjUv//JoGoNOW53fpSo9Kybyq Le5980qnvSrWgDMeo2x/XKTiaIlth64K+9kBjOBUj4pbnn+KURtIFa83iniyJU4UeD62d50jM/i+ 5I3OQg6Iiug9ZBjRhyRBpgesIfcQ8iQQeDfcfeP7vKbDMXN/8HV5JkaroZhqeQioy4CcG7qseI89 ZEP3yjZ+h8kroYmuxgG4/shqXEZmWJVKmhWuRuIFSTFM4vFieqfVuAVWEw81bnbx9VAaEljR2m7v FNZWByOnQyRETOOXqT7dQ3DFx5RPu33PyW6NJSnT8hTBggsPnpLkFO3wpXoN0gLDtgBTygapbOEJ AMw6zva+0AB9KKmMbEw0q9R4ozlGghjS0B45ZSizk4AZoD8AJoeFLdA4/dsWlyGS4QmqsHFyoHck HLhMAVIHggqiDMIOswXV1VuVmC9Tyl91vcGlnSlCtoMU7XxyG38VumTgtzTeI3tw8/Eud5lfmG+W xhy48JdvD9Co4cEdIdAAVhX0qmww3PCAvYNRqDGHyQFrwhPgM1mAFHgVvAywiDB9+oSWAgBGFGQX HUIpqqCIUZtRl8EAYAA6IAgkUzYAGbKoolr5i2qIxCzBulxAAtzOAHlA1xUcQtD/YDKoqeaQRmUI nS6qQjnOUEQAqw6nYZJOBTRPV5DhN0gtRTu9rDBTvGtQs9NJBa7Jbu0hGjfHZQu9JygPGfAgpHGD yaEJBUMtZwuQWoADTJeUGHAHILoDXWa5gQTarmsPtdlY/S1iMkCEUMnyvYwUMJ4hwCfkKNdjhgGn WOcKTzhqALixj8Tc2YS4LMoRsG0S3ZzvRotx2sUqp1duVh2OtovvDgnYlgZ5RxiFrwrT+iyPuQQf qnFhcussLK61P3qjs9z2UhSwzgk6/NgxzpfTbxoKOVNunfsLfHd1xbEPp0XWdarkttpOHKBRYXLT S+889t/t93LR2763y6DH2PcW5QguWoOATMZP06FOylYHzK1jlLZxdD2umKIXGi+006gzF9Z5MBaK gyMW5JV6k7ZWoxGOsYmAFu8iqTyOQQAvLYIqC/Eo6Km9Hrp+I89/EW9xnaMlbgZ1eYO65X2/295M Gke/Z5WTKVa6lKIohoDEkPgo4WCE/X4rlV3zsnOe6Zhu77z17LBWeVCKPf59UMns8Tyvc544aMOx VaKy0d2lTSG4PVcrg44G8xLg1IKiAy3W8XR+oeFeKEd8Aji2pWEv9crr6LrFqMo9rpJPYC2eGWEV 0CQLlbW3utCerxi+Wf/rsP4rZU5hbS1gh+ES5yd40GWROy5w5RiQCg2gz1LJD1/GtciU7JpHjfMS 19F1lQXzDvjlcsov8AjY1j/9cCOgnEfuiKesHP5HFC/XFu4Lz3jJL+CQ31bJc0X8zMi9XtjHmT3G OXVbneW54J7tS4sAIJZ8/zm8wmk7PS921edHLmKD39B6rxnzue+yqvsBVSv/zSPscnfW6O3ceUSZ Pe69zrPTWQHyluFOhCqJ1B6GWmHPJfl7dIASklI2SF2n4Ylc0jIbtVuhmDBVMbzJejeYGE/+BFM8 LYdXMe5lnopS3OGpBFPcVsOLjbpqqPO0uhivf7e3RFanc/oX4qbiES3VI+hLYHY7Xv4ZOtNMnH0U Z6I4DbADGXsi9kRVNjxKYp8zrX+Tl3q+Km8A7z5+PIcmZB6Sh8P/AXhJr9xlbmRzdHJlYW0KZW5k b2JqCjUyMyAwIG9iagozNjExCmVuZG9iago1MjcgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0 eXBlIC9MaW5rCi9SZWN0IFsyMzUuNjgwMDAwICA3ODcuNzU5OTk5ICAyODcuNTE5OTk5ICA3OTgu MzE5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1w IzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1s IzIzVVNBU0NJSQo+PgplbmRvYmoKNTI4IDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAv TGluawovUmVjdCBbMjg3LjUxOTk5OSAgMzYxLjUxOTk5OSAgMzM5LjM1OTk5OSAgMzcyLjA3OTk5 OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNH SXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMyM1VT QVNDSUkKPj4KZW5kb2JqCjUyOSAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsK L1JlY3QgWzI5Ni4xNTk5OTkgIDIwMC4yMzk5OTkgIDM1NC43MTk5OTkgIDIxMC43OTk5OTkgXQov Qm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1w NTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjNSRkM0NjI3 Cj4+CmVuZG9iago1MjYgMCBvYmoKPDwKL1R5cGUgL1BhZ2UKL1BhcmVudCAyIDAgUgovQ29udGVu dHMgNTMwIDAgUgovUmVzb3VyY2VzIDUzMiAwIFIKL0Fubm90cyA1MzMgMCBSCi9NZWRpYUJveCBb MCAwIDU5NSA4NDJdCj4+CmVuZG9iago1MzIgMCBvYmoKPDwKL0NvbG9yU3BhY2UgPDwKL1BDU3Ag NCAwIFIKL0NTcCAvRGV2aWNlUkdCCi9DU3BnIC9EZXZpY2VHcmF5Cj4+Ci9FeHRHU3RhdGUgPDwK L0dTYSAzIDAgUgo+PgovUGF0dGVybiA8PAo+PgovRm9udCA8PAovRjEwIDEwIDAgUgovRjE0OSAx NDkgMCBSCi9GNiA2IDAgUgo+PgovWE9iamVjdCA8PAo+Pgo+PgplbmRvYmoKNTMzIDAgb2JqClsg NTI3IDAgUiA1MjggMCBSIDUyOSAwIFIgXQplbmRvYmoKNTMwIDAgb2JqCjw8Ci9MZW5ndGggNTMx IDAgUgovRmlsdGVyIC9GbGF0ZURlY29kZQo+PgpzdHJlYW0KeJztXUtv5LgRvvev0DnAeERSUktA EMDjmQmwhwUGYyCHIIdgNptgkVnEu4f9+1G31N3q+sz+KKr0cmuMXdu0miwV68V68f1fv/4z+ffv yfunr/9LvrXfn77u0oc0r5p/SVp/vesO2PLB2fTwLymNeyj2x9Fv33cvycvuy+5L/f+XnSmOH2y/ 1X88LZEev37/9uvufbP4rhn5+vRj/dMfiU1+qP/7Jfn7P+rBn9r5Dg9835VVUcORpsbVv/63+6tx aWkeivrnejyVvx4e/s/ub39Kfj0AZh/KI/CmAbD76ztXZIVN65F8EMgvl4+2sx+Q5fu5O3Ev+Io8 sZUri8Tti/pBm/z2r93PB4xN8povNz744Xn3/rM5bETy/HPSgPCu+fZcw10k72yZp/Uff0r+XAPl /pI8/7IrD39tBj4dB/IbAx9f/8in52v094TMpA1opmyntZlYx34WA1l+HDDpecR9liP2w3HEXQbo tPZJTpI+Hkeyy0AmB4rjQOV/wpTHgf3lic8CMmMkIFYMmL34CG4fBcx9EANWPoEokwPtKgN33Lny escReD3qzG/szEe5M3IOU8lJKd6Nle9CITXNpAbw3JmklJNIEomBDACRZIZ0Bx/JJP33p27nVORI 1siR+lswJKkkgCfKeDCpJJFsLycFApBb5eSy6Z7tLkqVUgWJZYPEwpymNXKd/oQ3KQJu8DvuHcwB PIOsSSfREPgIO2BoFCxLSPmkKCIBhx/kEwAHrAJ8iPsAZAf7T5WINVS9060DJYIiQ2KZaxVOmIgh o8n/+8ILPCAAYIWPSAJAiuDKm+6ujxAHYsTuzTVGlkvOQCQx+o0KXljFpdQUi7Be6MsFTOrhkRvv goKY7yVMyhWRfMI8SSECRAbC3PQXZlyY02WR2OFdVA2RyngX3vTMBHrmFYTAMgAIYAjeDjRC6AF3 6NGzzK/JCs+AERYPPMFFAhhaVDLDXgVQFQhzvjP8wANKRYWquAXAzxnRGkFHWBVp4XsbpAh+XOei CIk3QgXy8wx3T3DXQoA+56eT/mZEBCciUqnKUzngaXh4uI4AudMfYz65M5CJsv2eMFEADfU/4Y9i rAZ4xQAwHSdYK4nsWb8h83JN05+bQ4QVqM1HlTdu3H6FW5rbb0xmVKKS/EQlEAoYRXC8aZEfoPK5 1oRluXnW3x+H53WQZzLsheqLB8a44yiXDAIYo9GGACTPqhOzHi83KehKEqQ4S917ZOWhrsXSCiTO 5AWQTwScLCNss9V7ku9LcSlJiPKGJcpda4A0GqEHv2iAqtKIcWpQBKdd7oyZxnLxnF5u+UCp24iL kKwBzJjLI9JwzaxcRudw6qprag5wTwHigSLgFEURHxHSMM0q3awmoHc5YGRqFAZKQEZKSWxVD7TV SUeC9YqpX4iTpTAn1TQovTjrAehcBIBe5R7bMXKlEDBqEweYSACHhtbkvjdw+QAFcTiol3AAM+sw 4t74A3JvzwbqowIDdhPeNsBr1j8TJCJyslzLmxpvkKOKXpX1utoDNhs+wpEMVId7GbpTSkLFFt6F uUZYsRyiZIZWMw0cKwXK67+QnQllmiMkHTgemkKW9FiSkZ1/FkUQnqdCCiMCFmhePqu8Geq5ePvi 9b3sDHhE1w0LGbfOI0LBhri1LMwBkjt9dVuSSepQ2oNUB7OLzRbm9A2HMW4C86IEUF9cj0AAz+PQ U5LWmVVUpIs5m92X4wRPzVAfhCeLiIRCsJKp2RhwoONnL9gqTkObq6Vl73x/oojN1cKUhp6rZXBN XXq9eRoOm4A4EGWSgGDKPFEvxWPhCi3crClruNBLJstj+YA3ZWk4eCdZtD/XKysY4AbKalM6BzAN wEEt8nbZeeztNsbcQeRMSpwbPjpyMKvE+74hMz4kR5jXZ3A/5ZTprEpGS1lpGiCbW/qZROp5dgdl +ADylsIW6qTW7NvVTH8t0yyceSdJf1WspNMREaU5iwiFfA9UgbTNA/flRqRq3bk/ZZp6zYkyZu9q 5xTPp0rywWVenHF3MuCdJ/sAAriSjciHDjVdB+eyltdIXHFhJfcMxaS/8tfnnYM4HUYY5kBUMi8/ YBs0CrHmMVwCfFwQf4LCBTAGFPqo6Aq3rAqGBNEcQSH90YzcD0wWUWjMqy6o9h/pkK3sfhzgMtnn fUmE59gFzAEoGsPMeKUxoHRj+rrcjXy45fJubqdKWZwtorsyTWfKQBil6gZDo6AzIzQzb3nG8cEZ RCEXLEb+R/cmGlpjUNlrrlujH2pf+ShgxaHiFdZ2l9VZdi+lumkhOZYBbueZcnsj2lMqmLfrYUMV DdHflIsxwzxbqcPbVaoa7FqNXbae5nyqOrWymW9311NCPWZ8KPevEr+ZSqzqNINOG7svlN0XosoX y/2TRvaVODe/T+fHRBnqqgqyqLxInKn3F8/CgZ0ZVw+VqsfBmUp0IuSM3kboivvlRrvm6dsVEB9a bifDeM+tEndXlQ9WjFXytAP6vgHkrZGGNwnvjmNlhkqqoaG7Irve/5kyJu8sY0bHeDnee1al9lyB 8ShA07itIeDgodG7+Z5KZ0xVXW8c1JWgpQ4DnlrwmYpEnHijgHTXpdytMFWtq7NykhRuIQyomJ21 1m1wEzQhsSL6zweQCc8LoUQR0/abHuoD7vWasuiw15FdJ/zQaqzsVFuVNdMae+ESyAyjxcvmUWIA zGuKAQdoBakQAWoGylSCaiXR2I9SsIwCKq4LV5cirLKXCNx/qmPXFA2R5KWXGBXu8kSPS/+7bgIy lOm9NfO1V2158VLnCNoIOwtI9YSZb3ixLqo9uFj2UeJR4dZcFIOg9QL8AaBcQdbwXmm8OhSegEPY m7q+NwPS40qNuiUCghvTVFyNcVcnOlB4/qyGb99zflQSPWUZjDMdP9wY8Y+RLrMx5V7gaJQUYo0M SZ7Lyb3b/aOsyy3L5XUJvGCClvbHeC4jbj/iqc7c29+/GUJE35yYLr7z3LE1ijkbA6lHGuoId5M6 H/DIhmBHU09uTIWJx6hUel9zEtSbF3ZVXtjLxil6YTt2qjxDWbDtoamQrC/ClkG076cFwFbW5rNp oNrZnc2jvHmUkUxyZwUTL9yjrKRtLq0G7tENfYvVNo+yBHXzKDceZZN5k1xG8SgHWLE6F2u0MuFS bPu2PLk6FdgRrZIiysukEY7ZM2O4Bzfnt0Q7FC3D5oJN3d++xJ2KAEyj0fSK3acB/kXYqVCTR0mu XiqS52qwYZwRkIyhwGJSe+fxQc/UO29zSjPBPIZTeqLe/MuKsPWyZDZpryjtL20P5pb2F0hGiRiM 6g635wrzzR2+Knf4ZeOmcYdjF36Pb3umxObjLQcdrKzPDT24H/5eMPQ4zuyA2pxx9JxGToSCHRjj 5UCHmvxIQI9QTkfU3Iyoq8GsEaia50YtSBdwSmqmSlqbexk44tIaTjP9L1neAk1jGWW2yce60MDS A01b6YJ3FY1AzBYAig8AKYnj7LzQRGGk/BhrtsU5JWGUayCWYj5Oc3H4TEph3u66t+ZQiELxjkS8 nQ6/TCGgMBzmmOZm9VEu0VzYLWe9nPKTX8e1LtdHK9dLd40vOHjdGDBgUinc+xecogc6t2MvAHXA EXFReX+mTMVmAHtH9FcJvvT+BsGrtHXr3zs7QJfRmwJ5iwrFhmtDi8NsIQiAp5BsdthgOyyia1vE TTnxTXx1TPcqvM+bRmkUHrQ+iWXRGROSdsU3D4CHzQO9wF0PPJ+Nk9lEUuTgrr7ecIWAb4zZxBOi +l/0slxZFcASk1T68X7auHW83Xz/qsUVMSZNsovJB6GqG89d85Kyippx5nwBB8/3CLBm+xsAEfGI GFJVEJAxTSqj0wOGKpV6+Gp737YDrP9ZZUHmTX/SxFWo9HoF9oA86/6GNb+1hKeNTcpo9+IjnpRF dHSTrXxIDKBddGJFHF8nOc8HpIL070sQ7+EeGvKqSrF5iz0CxHi0VnxP5yiHpBjzjasIfl8GvzAA dhuO74qRVpef+kRaiItHZHPyFlKcQ/D6C3pucq4PRrxBiuLo0MhMcS0kOxgAC+dRDnh6F3UGcjkA KVYyX9NJ0oQnALAcPiLlOwzAHEa+HAZtQFfBHJ6EQiAA4P9bH4H4Si8HJtt/Z4L339D0XAgfQQgK X49+BB0HEjAHhAmAyWUxowNefwvaXSMZnoB3oSyEAlHCgUniwNueJM1bUohmsbpOTvhwnsrCZSry lMQZRzPiDMwdBc7lyflA/pzJcFkaA/XJw1tzANn1OgCx7S7CRSjoQ8SqxJmDZDQ5gJJqFLxT0RVM qUp4r8LxnqeKC+dpOH8HgEaNBo06GVgFaASeQOUliQad7UASVCOCVYUVPR7uHcWqAnxcZ6085FX7 D0hH/o1nstyY7EiHhbeG6JDSUuaXDnENqMUFh+BHhN687Qnw1iPtiQe9kZAr1snrfZ3DY1/VufK6 s+8bftWsus5TgVdt+a+b/8zfoz2Dd5oyy/JnqIe2pRjovmn9lbzU72uKI+Dtt2/fYzO7viRfdv8H AcNgomVuZHN0cmVhbQplbmRvYmoKNTMxIDAgb2JqCjMzODgKZW5kb2JqCjUzNSAwIG9iagpbMjkg L1hZWiA0Ny41MTk5OTk5ICAKNzc3LjE5OTk5OSAgMF0KZW5kb2JqCjUzNiAwIG9iagpbMjkgL1hZ WiA0Ny41MTk5OTk5ICAKNzQ3LjQzOTk5OSAgMF0KZW5kb2JqCjUzNyAwIG9iagpbMjkgL1hZWiA0 Ny41MTk5OTk5ICAKMTAxLjM1OTk5OSAgMF0KZW5kb2JqCjUzOCAwIG9iagpbMjkgL1hZWiA0Ny41 MTk5OTk5ICAKMTMxLjExOTk5OSAgMF0KZW5kb2JqCjUzOSAwIG9iago8PAovVHlwZSAvQW5ub3QK L1N1YnR5cGUgL0xpbmsKL1JlY3QgWzUyMi43MjAwMDAgIDc0My41OTk5OTkgIDU0My44NDAwMDAg IDc1MS4yNzk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIj MmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1s Lmh0bWwjMjN0b2MKPj4KZW5kb2JqCjU0MCAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUg L0xpbmsKL1JlY3QgWzQwNi41NjAwMDAgIDYwNy4yNzk5OTkgIDQ2OC45NTk5OTkgIDYxNy44Mzk5 OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZD R0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjNz Y29wZQo+PgplbmRvYmoKNTQxIDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawov UmVjdCBbMTMwLjA3OTk5OSAgNTA0LjU1OTk5OSAgMjAzLjAzOTk5OSAgNTE1LjExOTk5OSBdCi9C b3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1 MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMyM3Rva2VuIzJk ZW5kcG9pbnQjMmRhdXRoCj4+CmVuZG9iago1NDIgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0 eXBlIC9MaW5rCi9SZWN0IFs2Ny42Nzk5OTk5ICAyMjEuMzU5OTk5ICAxMzAuMDc5OTk5ICAyMzEu OTE5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1w IzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1s IzIzdG9rZW4jMmRyZXNwb25zZQo+PgplbmRvYmoKNTQzIDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAov U3VidHlwZSAvTGluawovUmVjdCBbMjIwLjMxOTk5OSAgMjA5LjgzOTk5OSAgMjgyLjcxOTk5OSAg MjIwLjM5OTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMy ZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwu aHRtbCMyM3Rva2VuIzJkZXJyb3JzCj4+CmVuZG9iago1NDQgMCBvYmoKPDwKL1R5cGUgL0Fubm90 Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFs1MjIuNzIwMDAwICA5Ny41MTk5OTk5ICA1NDMuODQwMDAw ICAxMDUuMTk5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFy IzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRt bC5odG1sIzIzdG9jCj4+CmVuZG9iago1MzQgMCBvYmoKPDwKL1R5cGUgL1BhZ2UKL1BhcmVudCAy IDAgUgovQ29udGVudHMgNTQ1IDAgUgovUmVzb3VyY2VzIDU0NyAwIFIKL0Fubm90cyA1NDggMCBS Ci9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCj4+CmVuZG9iago1NDcgMCBvYmoKPDwKL0NvbG9yU3Bh Y2UgPDwKL1BDU3AgNCAwIFIKL0NTcCAvRGV2aWNlUkdCCi9DU3BnIC9EZXZpY2VHcmF5Cj4+Ci9F eHRHU3RhdGUgPDwKL0dTYSAzIDAgUgo+PgovUGF0dGVybiA8PAo+PgovRm9udCA8PAovRjYgNiAw IFIKL0YxNDkgMTQ5IDAgUgovRjkgOSAwIFIKL0YxMCAxMCAwIFIKPj4KL1hPYmplY3QgPDwKPj4K Pj4KZW5kb2JqCjU0OCAwIG9iagpbIDUzOSAwIFIgNTQwIDAgUiA1NDEgMCBSIDU0MiAwIFIgNTQz IDAgUiA1NDQgMCBSIF0KZW5kb2JqCjU0NSAwIG9iago8PAovTGVuZ3RoIDU0NiAwIFIKL0ZpbHRl ciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtCnic7V1LbyO5Eb7rV/R5gdHw0U8gCODxeALkEMCYAXJY 5BB4M1ksxos4e8jfT78kddcn6mNT7FZLlo0Zy3Q3WVWsF4vF4se/fP1n8u8/ko+PX/+TvPQ/H79u 1FZlVfeVqPr7w7DBlFtrVPOVlNpu86JtfXndvCVvm+fNc/3/20bn7Yv9j/qPuyFU+/3Hy++bj93g m67l6+Pf6k//S0zy1/rfb8nP/6gbf+n7ax543ZRVXsOhlLb1rz+Gv2qrSr3N6891u5K/Ng//uvn7 T8nvDWBmW7bA6w7A4a8fbFEUOtsalZ0F8tvh1b73hliuz8OOJ8GXZ4mpMlUltsgTmyX//dfmez36 Yexc2croLC+dn4djW9uPlSZlabemI+3rxqZZQ0tVD1qTfKu69pr+uU63af2Lke2maN5u2g/9/HD0 30zN9wHMle2/nJ9HMB9gq1TZdt/BfBirxrR9RMIm2ve4DPr54ehfwhyJzg6YXTC45mUOOh+f69cR 3fzofJw3XLw0hnluWapKk2Q1CNqUEYVJ6zwtW0U1Fqa6PW9h12MCiPY9wQb9/HD0H02Y6j4L22nQ VzFWmbdwAmzD9iEuu35+OPqPJkxjOjtgdsHgmpc56Hx8rl9Fuw+dj/OGi5fGMO/seQXWbZrgpGlj hcrGL0j03gg9h5la3X4PgelaHKb27cSLn75tPn7JE62Sb9+TDoIP3Y9vHdQfTO1A1L/9kvypAerP ybffNo1n0TeYtqE4NNi2oTw0pPKJro+nbz3+s9DaqtSq66N1DXaqZ6J1oJ/2duLFFiGdVrUreRSl quGezAiMSgneoSGzR+DdmoERO/55hI3H8xzXiYO2lKgabjtCB5O3UqR3dDBPkg4PbUMqJ/JEgynb Bq3d3KCLtiE7PPG5bchPvPIoIet4rjo0PAlAtBZPGCtfkbBrJYeVfSD+uURXf5adyAaOHaIL4wJk j6JBZ3TYJYRQOWQwMy3vpWY3O5+EVtGG8l4p+cgwlLEPoHQhG/goMMFP8pUvEjklFSLAAcPKPmBY DWoMGLykmlqCbgBS+goSGdCXcCBgMA3AvdX0uYUnAHQYBbiQvwK4AMNwToa5zdg08Nnno8wiYr3+ G0x2ITkZWJsjJwEzegl1sQwuOGzXhx70CiaDMwjwpa/AtBbiDFVfCF2/qNidC3wHe1Z4A2K5SeGw U5a4kDAvpKnoK6D99SdqlcEKBQhiLod9nCxUCDpYMgqpCTApAdoOpBAmW6o/1IfwSjdKFRVbnH0Q QpBbmBdUskAhICp1hjy0rlQP+MqS/CCXA6NFZrr/LJYIjqd8lg0eA5D1fK+jCzOm14A8kj2gARdp wLdS9GEUBXIMncKwcsVpJFcavnosJzdAHwaeoAKFwQKHtJzoA9fKkilxSQ7TAHMLOlp22j9xmYWv 1bng1ulqF7UMdxA9XApuIGexMh0yWh0e0VIBygYNsjd9aTenn3am05lWkkcCFhGwEJFPgO+iH+QT IGwgsODMyE6tjUGRvCVIofahSuAzbt8pydKCTS+SDPRkFHS16vCtdUWPbyp1mJSANJNiZL/IFgiy 8W57gzSUThoUTh+kiwdzAW4ilT0cpZvPQegVEbafJCSgWqiL76HBeFgt3nruCv0za/SYm5EfwERz 3wFcBcnLPaOWkj9OeWzgTMAoDg/lMs5EajJB2YeI2tZeJGAzUGlUH4dHHyIp6HQXF7oqBY1aMCAS 9L5i5xfawrjlkH1UXZUb58RIZJBB5nXiin3sGDQArmOkZIJGwE6sAQ2QC7fHPkgaLKIjIs7FKY53 RBGW3jpGqQFsqb7zCBeuZQMC0Kego77j9AAS8r116sBzvesd5z97aywTKsIhl+eOU1oxjq90R9KB lb8rOQ/7BvDAIsprplXsEZsAdoP3wiOCHp4CbG9QLeChawAOug+3zHSi1wMOG9es0/OJMBzGY7k0 JoMNlMizhOXm1N+hG2Rna8RS+WcUoHoDDgEVCTsE1BeJY2l0LtGjG8DIATwrjWf7cJXBV18gRNyx BGxxZ4YG5mNIAF+wekgA5UyPXaYIeXseoAc4ETwmvZbV+GVWUXerc5RxI6l/s49XzGiqoiv3TI2B X5ntOqWHI1idOAGrLlulzPbc+1lAhjQE/Kl289iSelcB3ZDkV279KOge+8WgMulkx1CZHnl6NMcM 0wWgU27JadpCSDYgDxpxryRGxgWfuRjZgctsK6w27Dg9nTbK2RrH3MYxDnnmHGaZIPMiOniZMxs3 bddirPt4lhcqoYDF9E1vZUbAFhPj+fIKZJ9zIVeGHLCABfoy++d0V/NCx0zn5MI4Fqd0ouud8xh7 tVmmArIA1cYjJaDJgCFg2Mv4iiERm2vj5dvQQmuh2A0tg6yi9pQzP2UYfvIKF8E0jOThGvE9Qi6m TxGNQeVcfoSUR4jAQh4RsDnqJURZ9AIcXAr5SUROQ+Blq8UTN31kfqa8imsWCD5V9GiuB3KLpNrd q7QIUY5RpcVhHqOYlEpPcDFWkgTofR7yTAoZU41JFHOfqbLljkcguhTgQoH9g075sXpYP6JFgPPJ t2yqlqru8r4qQtzgqeJJu0Kz1IyYnleBypwXaoFRwLcN2HmELVFfC3muGs7KsR722MADe0dTJLxP e8cxKpndsTusy7mFmM5VHtvX3FZz5QY+w/T8N1DUyyQeBJSM8DidwaNl3JJzOQQ4QEHwBCGqUzyE jk8Ujx3TRAxYhE8rj3CypK1t+GBs2wYUAfUv64NqsCmywovhnQIvxzthfWpYedIbIMUGiT6AbuUR dCtxsZMWSGzuTOE/dxJfLCwEh+El8HCQGEaBPmBmULplp/wVoCrWAnBUchs8AZxK6zvBKAgHrzQ0 KebK5j/1l10FoEG5BMfW6Als0A45bMiJiYhSAoszJuACbAfsz8t5wSgOd2DAMlCcCkgIgAH6MCwl sgV1ILG1wNwOZ/eUxEjkUihFADMHTwDF6BMBuKTwhJy5dJInzwQ181fUyBCUzCBCHvaQhtTA/Fmw mAAYqGEql/e6e6ThXndPcCHMC4xCVT0ix90WcOTAKQHvkOpcXPh+jql0Sn+lY4FDuFmiKoXXTgpQ KRgsu73CUINX+BG0G8IW55aXbJaMC8sJcH3A1MMqFkDnHkYKyk9CmgIc4NhIFQteCqgU0MopeDow CszcoLTpeVE+W3PSLmQZpV7UfQ/3NOgx9nDjZD0MY1I+Je00lrTTRiU1BxUmed1/tlut0uaCtqr9 UBu2prW5ma3sP73UkOfbssqaS7J2f8zHL+d9v+2z7WfVvpGIV9W+X9U+Oxq0uWJLjV7ew/uy+XXz 6ae5CvZpq1vRKnLnnC6SYrSWvc9rzqeJoSZixO1vOcd5GbYMiP17zEuEuY1S+GYtJ2BoKDhiEvi5 B917NV1pF4numeMMlxvKHJ8nMTJe1vfdwDrRfw8Z3Oc76kYdHHWjjjnqRu0c9eaTcNS7P+bjl/O+ 352jbtQxR71u3fcLjnr7xx6okaPe9buAo26Us2b5FQnS9MIV15M9GVCk677WuYgqDqhIdpn6kyEl ygIOxAcUreF5gDOK+rlBxeZSm5FGvaJrIHfm4HBn+CLVHK740OulLqi8YiW71vVhxGqbEVxVO3BV 7VFX1e5dVYuuqt27qnbsqtqBq2qPuqp276padFXt3lW1Y1fVLuWq2v1lUXTPwyN/GnhvJW7mbZfz iXbyq+aHPN3xw/SiJ/Ow0Cxu1Fr2Fan2Xqjc1Vroccv7rPP4VNOPinisum6ogFxARQ+PUy7Xdvz4 7JVM2lqHohrbnPUVzVrLYUvE1pFPd+rQ6/T5D9FTPBa2lmBQwF7oHPGjWfycOQ39uTcLp7mQ/ru7 sIC7wMN0gC0/9BihxnUck9KvN6rUn0LQEKAPpq/qPM6JcqJO98Dfg1cSW1FZK5kq4tLYGnHW7p7Z unYVipmtcMlln2G9dCjcgx+AhrxoIAT+31UczMOD8tVDpzZT5iiw7HF/Q4BJud79+XNS0uMoe7s7 OhVS4YIvj8AvC9gaCzA6vPASh+OWVcg8wWaOfkBJlIDrjWJUcV9Jcce7MWScvMhd3TfoxcYxH5nz Zvlr8nwptyOo01n3bulWaukAOb53v8weWIwqhfflVnwOukzy1kJLlHgbXmdamFyXYxOjohVprHvN CydJ7vxPRomx1zRHmuX9yrT4k73M/cozXUjAY/oenDrH2b2Ae0wXMkPTj53i/M+YAHF2mn021v7X lGbfW67SeDPAPNp+JcdMFr0b/OKR4oCQ/jWnGQ32M/fisjWq/3J+HqXLezzP080nDtpKcJXo7Ohd Fm16Sbp3aKFgk0cwCxpyaTmxfh2v1ucoRA0rXlg2HqyxsdI8w8Khkia9V1i5ND/VCc4A2PlJcXhF hogQ1FJSldMMYS9kg0TXe2a8T4ZEPTvRGZy03NWzjxFJXcvx0nkyfadnLbvqvJ1y63xl4pSCDUhu CfB76F3JuEE4fRpieAYe08DhiLEwiHERSYT9jZtKhL/QYcuLykuUtUZa+d/LEmV7Z5nNvJUosvVm j0UJvtz2QcubVphXXMBheu4Hj4F5eBxAU+60UYrB5VDopAQUXxocNT/XPGTaxuSYWYKT/OovPrmL hMB5pwG6fpmLDy8VJLreNcwyjo5HobWAtCWgsgeT8RsZryb+uxoWWtJ7jGMuTOmcB7oiu3uTTGDW 6k1ijdEA/wpSMAAOfrUup3rwGcFJSuhdHQDkdTo9ctYCKrbz03wwURzbRQ4vLONuzrNr70jzEft4 WdV/gRmRf/PYn3N31tqk3HXWu7LNZb1FscsEMHJTqCfIQOfA1UEdP+QS/wHJIGxSygYpDhqeyI8/ IW1yKCW0bSlRaXV9lACzIJ9QWVRa9Ye59wUC1kIqA8POTAiTqfEJ5OuhhB5kEtXfyVtND523iPU/ Xl5D91qfk+fN/wE36Q6fZW5kc3RyZWFtCmVuZG9iago1NDYgMCBvYmoKMzY5NQplbmRvYmoKNTUw IDAgb2JqClszMCAvWFlaIDQ3LjUxOTk5OTkgIAo3MjQuMzk5OTk5ICAwXQplbmRvYmoKNTUxIDAg b2JqClszMCAvWFlaIDQ3LjUxOTk5OTkgIAo2OTQuNjM5OTk5ICAwXQplbmRvYmoKNTUyIDAgb2Jq ClszMCAvWFlaIDQ3LjUxOTk5OTkgIAoyMzIuODc5OTk5ICAwXQplbmRvYmoKNTUzIDAgb2JqClsz MCAvWFlaIDQ3LjUxOTk5OTkgIAoyMDMuMTE5OTk5ICAwXQplbmRvYmoKNTU0IDAgb2JqCjw8Ci9U eXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbMzcwLjA3OTk5OSAgNzQ3LjQzOTk5OSAg NDI4LjYzOTk5OSAgNzU3Ljk5OTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMy ZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0 aCMyZHYyLmh0bWwuaHRtbCMyM1JGQzI2MTcKPj4KZW5kb2JqCjU1NSAwIG9iago8PAovVHlwZSAv QW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzUyMi43MjAwMDAgIDY5MC43OTk5OTkgIDU0My44 NDAwMDAgIDY5OC40Nzk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYj MmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2 Mi5odG1sLmh0bWwjMjN0b2MKPj4KZW5kb2JqCjU1NiAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1 YnR5cGUgL0xpbmsKL1JlY3QgWzMwMCAgNjEzLjAzOTk5OSAgNDQyLjA3OTk5OSAgNjIzLjU5OTk5 OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNH SXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMyM0kj MmRELmlldGYjMmRvYXV0aCMyZHYyIzJkYmVhcmVyCj4+CmVuZG9iago1NTcgMCBvYmoKPDwKL1R5 cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFsyNDEuNDM5OTk5ICA0ODUuMzU5OTk5ICAz OTYuOTU5OTk5ICA0OTUuOTE5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJm IzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRo IzJkdjIuaHRtbC5odG1sIzIzSSMyZEQuaWV0ZiMyZG9hdXRoIzJkdjIjMmRodHRwIzJkbWFjCj4+ CmVuZG9iago1NTggMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFsx MjUuMjgwMDAwICAzMTEuNTk5OTk5ICAyNjcuMzYwMDAwICAzMjIuMTU5OTk5IF0KL0JvcmRlciBb MCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRp ciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzSSMyZEQuaWV0ZiMyZG9h dXRoIzJkdjIjMmRiZWFyZXIKPj4KZW5kb2JqCjU1OSAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1 YnR5cGUgL0xpbmsKL1JlY3QgWzI5Mi4zMTk5OTkgIDMxMS41OTk5OTkgIDQ0Ny44Mzk5OTkgIDMy Mi4xNTk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0 bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0 bWwjMjNJIzJkRC5pZXRmIzJkb2F1dGgjMmR2MiMyZGh0dHAjMmRtYWMKPj4KZW5kb2JqCjU2MCAw IG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzUyMi43MjAwMDAgIDE5 OS4yNzk5OTkgIDU0My44NDAwMDAgIDIwNi45NTk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3Qg L2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRp ZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjN0b2MKPj4KZW5kb2JqCjU2MSAwIG9iago8PAov VHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzI5Mi4zMTk5OTkgIDE0Mi42Mzk5OTkg IDM2MS40Mzk5OTkgIDE1My4xOTk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2Ej MmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1 dGgjMmR2Mi5odG1sLmh0bWwjMjNlcnJvciMyZHJlZ2lzdHJ5Cj4+CmVuZG9iago1NDkgMCBvYmoK PDwKL1R5cGUgL1BhZ2UKL1BhcmVudCAyIDAgUgovQ29udGVudHMgNTYyIDAgUgovUmVzb3VyY2Vz IDU2NCAwIFIKL0Fubm90cyA1NjUgMCBSCi9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCj4+CmVuZG9i ago1NjQgMCBvYmoKPDwKL0NvbG9yU3BhY2UgPDwKL1BDU3AgNCAwIFIKL0NTcCAvRGV2aWNlUkdC Ci9DU3BnIC9EZXZpY2VHcmF5Cj4+Ci9FeHRHU3RhdGUgPDwKL0dTYSAzIDAgUgo+PgovUGF0dGVy biA8PAo+PgovRm9udCA8PAovRjYgNiAwIFIKL0YxMCAxMCAwIFIKL0YxNDkgMTQ5IDAgUgovRjkg OSAwIFIKL0YyNDMgMjQzIDAgUgo+PgovWE9iamVjdCA8PAo+Pgo+PgplbmRvYmoKNTY1IDAgb2Jq ClsgNTU0IDAgUiA1NTUgMCBSIDU1NiAwIFIgNTU3IDAgUiA1NTggMCBSIDU1OSAwIFIgNTYwIDAg UiA1NjEgMCBSIF0KZW5kb2JqCjU2MiAwIG9iago8PAovTGVuZ3RoIDU2MyAwIFIKL0ZpbHRlciAv RmxhdGVEZWNvZGUKPj4Kc3RyZWFtCnic7V1Lj9y4Eb73r9A5gMd86QUEAWyvN0AOAQYeIIdFDoE3 m2BhLzLZQ/5+1JKmW6pPVFFUUVLP9Ax2p5uWyGK9WKwqFt//+cs/sn/9nr3/9OU/2df+76cvJ/Wg 8rr7yVTz+27YYKoHa9T5J6u0fSjKtvXr99Nz9nx6PD02/38+6aJ9sf/T/OPLEKr9/f3rb6f33eCn ruXLp782n/6XmewvzX+/Zj/9vWn8ue/v/MD3U1UXDRxKadt8/Tb8qq2q9EPRfG7aFf16fvjfp7/9 IfvtDJh5qFrgdQfg8Os7W6uyLpqWfBXIz9dXGyhsbXReVN7Pw46t7eFxmS6L4sE1H00zdevy83xU A5guy/rBtO0NDgrtzg9pQ9tNef7Stl/6+ebp/4yeXwYw17b/8X4ewTyErTZnknQwD8aqlGs/U9jG 7YO5XPr55umfwiyEZw/MPhh8dEmB52lafx+1h+F5mjd8vDSGuZOWs/D7Pg9hXiRvRZ41gmuLrFEv WWWz//6zGflxu7G10mXmXJVpPTF4NIPVdV61eHVjQa7rUrd0cGPkk/YLsQb9fPP0LybIdV25Vre6 sVA0mv6MsgnYRu2DuVz6+ebpX0yQx3j2wOyDwUeXFHiepvX3cXsQnqd5w8dLY5hf1vMaVrdlguNc I7VFpRq7INP5i9w8xi21uv0dAtO1eJba55kXPz6d3v9YZFplT79kHQTvuj9PHdTvGrBrnT39nP3x DNSfsqdfT2fLom8wbUN5bbBtQ3VtcPSJro/PT/380+Ban7Xj7eFaW5sK15F22vPMi+2E9NmSnJpR bs7MkzvbA6MrAp3+SOGnE9I/0An9SJCiO6S4mSegj0902A6w3N+H+oECpkmD0RQORxp0QYctWTho H8awGKOAIZN8pqNQfOiSohAaPlGcUkiRDIAxRfsAJNNh8RWPBLiZyQGCloOOhIpAMrClABfiXOgr CBjwKQAGfbCd6po+weM0hVQGCCFQjg6ruz7qmVd4IQS6wORYycY+gJQAB9W4SDnQQUBKYAd7XVNW Lw555QWVFakAbcAyO68ekJWT0BK4n18cYBRe1kEKAYXbSOE2xP4gyKhVMTapyjXU1t0T2s68s5zc AZzKa2EAFbQfwMEbXPBKChGCYcF8QNblFTdrkgUIKiCIBQzlklftm6glRLJneZiBNAZ04PWcHTZi DQYFmkRNRzCdxJ6GFyAQdZAXfnJ3Q2dy/SiU9oK6iaGDiwPgkN+Ns7ZRgGhH7GEkWAiserqD5acf MBdwRrwthQpqiocUxBKGZa0a2NMFeCfuJvtC2m5qss8JEDW/AwR5+eoZ4QHzOQBXLh+FIeuHb1GW WaZ04UXaJv67AFVGpQxf4UHfZkPScbdWfuZFbv5xulfqwX/oUktUG9h1l8/Eq+95KsTTHzBAx1Cu 9nCUUQVhKfC9VbQBdP0H2gDCDdrPo1JBH8wNC33QYXstvE9gxWpFMLvcYrb86sXLJr855qUGVC9r qAYYu2xQCCcHCt5jd6zWs5ahXZptmMfPKbNqWCNpE+20P05hJAW4wmC2Ab7BiM0dHyZlA4e3Y4m/ qk2V3M51pbA7XY2l/VUH9IfRg2uKytAqmv48Wv8Dnuetg4WDtkSsz4kvU0ZZa5OV6oWE1jPtQcoB WG38Hg0auj60pjQExphjHZByILtns1hTTrk29BLKrz71glFge2GgD8/k9kzUKa0dT2hViOuuk5di DF8BO5fOBffToCt5y2CTQNJOwbnjhjRY8wvXQT7rBk3HTcxekd0mwMEHfSIyM9gIH++hTqLIkNow bHRS3loPpMrJ8rBlxFtkg1q6ygvqfWlbLTK82uEhCwivCCyYfFQ8IC0zQg/tGsBOrbkF/IRW0SfY iExASja7km9jHkQYh/oD7eMoW20ZJ2ipiFrm7RRo4COlEQn3LC/3G+Y0WYZlIbkF28nmdt0rg82+ 7YYZBMLsRyp4MF9QEYZ2onJoYXsJiB4mOVLwqk0GXq+wrwRs5fgg3fKtLU6Otxh4luJTyNmQVsAa epTM9YQ8tlapuppoVQm/jaS+vxysNICj5Qd30HaDToFnwHQHBOCiQYfhj77F89kN5j3owo1pa0FB eFLoqxlCwSt7OoyNJux7lM2qiB/2IMHU4MMaa1WRrTlisnmdhzkVER2iFtHnlSq9GILJRKheiWO3 AbsC0FfLT3Nuk2G3qVm9kkOMVWMW2UZFBhiS/EY6grrLT5ptc1IkiT/LLvJVey2HolXEVUGOGg5A A2GmKsN4jLOZPgxghDU+er/Z4BVYZiG1EzoFRQxRc/qKhU5hLjRfFKaPDTQDgB/WUn1oF6Vgc/Sv dDD9Yb6YqAqkosAbMD49ocjBK7A5oX0YmnRrADDP4ZkZNKNDD9j/syQh6nBBfIW5zYs4hM5FcIsz x/7AZZTbLR02p4RCLqNzcTAs0JZq3Rw0hEdlDBpAH8LSJRgRrfOLpRpxwJt1CbxxD4AmOAY+BWno Vds+23ltizG89+08Z7wedzvvGvOBIeYb2M4v2iJHnFKV2CIJOh7q8sXFjdG33jQZpKfSBsQqL8xp co201uPp8IqHL4kWs/bwR4wOm1n4mkONG1WjEVCQfFx5o/RFOheQlwCs84lFIC9suDKmFhFbmS7A qRqQ37o8CSKm7gUfJA/VBjJLSHUpxSZ9bjketKoag7aTfw+zgAQdflq5cozWuY323eE3fuX2HX5a FSaY/neH3+SwQoQowwXxjTv8LFgAno3YHArBlAffHO0j9xxXHDwBokpHscDcdFgHxhyVKfQisoDh 5ChgMLncSDJ3Ha5l7g2rG0CmeKnjF0heHhx9xdFOUUBAtqkmg05BP/AihGLISgwvdfhEUhHSasH6 cG9Y2xDsNV8iIHg2m4qhBblkuR0bwICGJRZeAfMIFmEQEFApoA7YyWGnMCxVB4AxEHbYlDgwSvm5 AKHYrV5PbIntsNbFZc+Z5DQ8mI/82W5+lJ0SgAO8H2AMshv5w5yP52MQy09qB7gc2eO+AS5HPtVr m7JIQDn+LCPvtuMdrBFOOTDj+BRMthxK718Y+tPAacOHwvjzj3xslD9lkkJw+RJvAXKa0J0us15U l2uOeC81cBlfdADIz59LWpdysaY8IcFIxAm6VNX3XMmAdpiDtik0s17ktmQYvr7EC9g7dWJWSF6t RBzllDu7pY15yQ5Ebxl/11NEwcZXFMa9oUQfPqqfpG7kJkpnp1pQvD3AHzgRIQNfY4I3h45apyCg xEbEsW1+3aaCjPUS+JQFgSIEwakTa9eCiiwGRy+WJrP2OR2M53t+1gXtN5bFXOSE1qz7lY9ggMce GiBjHwOaEASGUTzu151OSxeaIFKgPlREXlNEqRMchfcH8C7GAA3AC7zH7bI2e1q5Ma36NIZFG2/+ NhG+2tdOaeybGIArEsxklq9rbvwbr1cfI5oS91AeJFt2o9PyCU9HvRGHQUDe90Y1hVxuxyokqvql 3PGRRYv3vT7mFCPKrCmlCZ5Mmpqar/e+Am1d+H0FvrTLObcG+EqwsmDHO8VMA71aAJ+AwGBHw+FZ Lc85q4Fi0HQYuNKAPoGZmHaCVYDrE+2GOnGxlxNeYGBHuKEOplAOuEofpM4v0pY/FsRunlLWn7sB ltrpQmEo4TqxqwM1OlEJ9gOlJmZLRJjtIpcnyHiIlR0rvKN7iOc8GwkPsc2JHs+dvGXrcSCJGH/2 ckCtT3MeLunHKqexe9ARWTfF2cmIazwC3P9J+PCozuBEdfCsKcciI5IbyqegQN4ej6JN6icH3BkZ kem3jeZefk7+KEoniX9VxBD14FRknXLqkqTInhJElIEG5b3HIifnI/Yd/NljvjoNjMK7HNNoTNPF pK7EC3D9xVRKQHKmuAoMPZs85tmcGonCuEL+YZsTYiU5LrCJJYLbRD5jKsJrIJTZqwjeI4qnsFZE gJ3JVzEMvdhORuVrr50VI/ABcQn0nUK9qYgg606Jqm88PszbphL3maMQCe7NnXtJzZu4QQgggTjj nSOOwRER+TASpbAiTgPyUVf+KoCARYP3k7M2kYglcvvqfq3FV5RjPfPGVUTiwIDMolC85Pdtk1cX k70RoCV53ctfVcdXQ/UFRmQVyUbHu1Nk3iRSLKaqx7y6za4vwr2CT/AJfhEuC4nEOj4n8GbCcwHu xogam3ymnUSF1cNGBbf0gcgsZaXX7gioIQEyBuSPyOaLDuisrR5tKoKRbbyRPCNGIHGnC5QOEuLc y0t8O7GGJKXx7yE/Rj3y6afsdig+E0Hk1vWBetzWmSOz2l1uqQy46KCvWzjHm7xo4vyW312dJE8g 4KiOQBZAjP3D78L2WXYkthgSJ2JivAF8PhOo+30YZreyQ04VYw1xw9bfRpFXvnRZRHL+zVihaTwO KfN3chW+s+F9MmgfC4Q/Ajw/2xx+46u9BFguEdGeoxyQ93mHVjslC8KJErbNYbGYhq+OdJgiOOnl BkuY5F3m3JVZA+4YhQYPb+50es6RGUmmSuQ29zJbmiI9h8kmYJ0FvIoK8PukSNMOkF+JBTdFxYZ7 /gFr1rzmzAE+fhVTGU/GVdZFEq4KEZHIl044emaQzJqR++X9KBlZEmqGlzteRHiG2KQuOi93Mr5V EF7+2G6SE1egmd5iev1OORFrfXqOKJnjRg73idfiXCS2oyE1jUB2+SS4uSPY1+oxed3/AK/Qfwso RePvrGW8wst3Zy+HKvTLNqvXiNdiLn1FyYHdqT3Xag8fodkVBtItcvpENa14qWDFztTm5w2lKmlc bVC2powa0DjrG7IgQ6rpe3uip9Te1jXo3xae5QyMJjAaBpSpCV76+4jk8OK0SooXp3PSP3idPDWM ZrCgp/0PK7CQl2mxUJhx/1C+X08vXSumVNZpp1QRgerDNkPNQ9kZSf2BUhYkgD4hrIpM2d32fCmt l14VmYoMKUwZU9tx/zeiiqx1SfFibU36P6IqspVOi4U2ljLofwNVpGzSKTlFBKonygzZkI7TpX5X TBq4TXjSjkjLS/RmIMPAzvRyS2Flqg256Si9MtWWXq4ki2btyL1SN6JMzwAnxUu7iA37P6IyNVYl xYLpCi9c+0+vTA29+k16SjkRqNu062wXs9xSFXW72nSUsXl9k6rIqbRC6FR+A6rIwS2AwligemED u66o006pJAJ1BLsuB26TnXSuibQcwK7rlem1zo2hbkdUK3CPOpCKqiYQW0XdkAru9aKeS2ygGtEM buVpfrPnBkG6aGfa//n6PTbF5jF7PP0f3WZ4b2VuZHN0cmVhbQplbmRvYmoKNTYzIDAgb2JqCjM5 MzkKZW5kb2JqCjU2NyAwIG9iagpbMzEgL1hZWiA0Ny41MTk5OTk5ICAKMTQ1LjUxOTk5OSAgMF0K ZW5kb2JqCjU2OCAwIG9iagpbMzEgL1hZWiA0Ny41MTk5OTk5ICAKNzU4Ljk1OTk5OSAgMF0KZW5k b2JqCjU2OSAwIG9iagpbMzEgL1hZWiA0Ny41MTk5OTk5ICAKNzI5LjE5OTk5OSAgMF0KZW5kb2Jq CjU3MCAwIG9iagpbMzEgL1hZWiA0Ny41MTk5OTk5ICAKNzAyLjMxOTk5OSAgMF0KZW5kb2JqCjU3 MSAwIG9iagpbMzEgL1hZWiA0Ny41MTk5OTk5ICAKNjcyLjU1OTk5OSAgMF0KZW5kb2JqCjU3MiAw IG9iagpbMzEgL1hZWiA0Ny41MTk5OTk5ICAKMzk4Ljk1OTk5OSAgMF0KZW5kb2JqCjU3MyAwIG9i agpbMzEgL1hZWiA0Ny41MTk5OTk5ICAKMzIuMjM5OTk5OSAgMF0KZW5kb2JqCjU3NCAwIG9iagpb MzEgL1hZWiA0Ny41MTk5OTk5ICAKMTE0Ljc5OTk5OSAgMF0KZW5kb2JqCjU3NSAwIG9iagpbMzEg L1hZWiA0Ny41MTk5OTk5ICAKNDI4LjcxOTk5OSAgMF0KZW5kb2JqCjU3NiAwIG9iago8PAovVHlw ZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzUyMi43MjAwMDAgIDcyNS4zNTk5OTkgIDU0 My44NDAwMDAgIDczMy4wMzk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYj MmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgj MmR2Mi5odG1sLmh0bWwjMjN0b2MKPj4KZW5kb2JqCjU3NyAwIG9iago8PAovVHlwZSAvQW5ub3QK L1N1YnR5cGUgL0xpbmsKL1JlY3QgWzUyMi43MjAwMDAgIDY2OC43MTk5OTkgIDU0My44NDAwMDAg IDY3Ni4zOTk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIj MmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1s Lmh0bWwjMjN0b2MKPj4KZW5kb2JqCjU3OCAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUg L0xpbmsKL1JlY3QgWzI0NS4yODAwMDAgIDYyNC41NTk5OTkgIDMxNC4zOTk5OTkgIDYzNS4xMTk5 OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZD R0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjN0 eXBlIzJkcmVnaXN0cnkKPj4KZW5kb2JqCjU3OSAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5 cGUgL0xpbmsKL1JlY3QgWzM5MS4xOTk5OTkgIDUyMy43NTk5OTkgIDQ0OS43NTk5OTkgIDUzNC4z MTk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAj MmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwj MjNSRkMyNjE3Cj4+CmVuZG9iago1ODAgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9M aW5rCi9SZWN0IFs1MjIuNzIwMDAwICAzOTUuMTE5OTk5ICA1NDMuODQwMDAwICA0MDIuNzk5OTk5 IF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJ dGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzdG9j Cj4+CmVuZG9iago1ODEgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0 IFs2Ny42Nzk5OTk5ICAzMzguNDc5OTk5ICAxMzYuODAwMDAwICAzNDkuMDM5OTk5IF0KL0JvcmRl ciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2 LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzcGFyYW1ldGVycyMy ZHJlZ2lzdHJ5Cj4+CmVuZG9iago1ODIgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9M aW5rCi9SZWN0IFs1MjIuNzIwMDAwICAxMTAuOTU5OTk5ICA1NDMuODQwMDAwICAxMTguNjM5OTk5 IF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJ dGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzdG9j Cj4+CmVuZG9iago1ODMgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0 IFsxMzIuOTYwMDAwICA0Mi43OTk5OTk5ICAyMDIuMDgwMDAwICA1My4zNTk5OTk5IF0KL0JvcmRl ciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2 LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzcGFyYW1ldGVycyMy ZHJlZ2lzdHJ5Cj4+CmVuZG9iago1NjYgMCBvYmoKPDwKL1R5cGUgL1BhZ2UKL1BhcmVudCAyIDAg UgovQ29udGVudHMgNTg0IDAgUgovUmVzb3VyY2VzIDU4NiAwIFIKL0Fubm90cyA1ODcgMCBSCi9N ZWRpYUJveCBbMCAwIDU5NSA4NDJdCj4+CmVuZG9iago1ODYgMCBvYmoKPDwKL0NvbG9yU3BhY2Ug PDwKL1BDU3AgNCAwIFIKL0NTcCAvRGV2aWNlUkdCCi9DU3BnIC9EZXZpY2VHcmF5Cj4+Ci9FeHRH U3RhdGUgPDwKL0dTYSAzIDAgUgo+PgovUGF0dGVybiA8PAo+PgovRm9udCA8PAovRjYgNiAwIFIK L0YxMCAxMCAwIFIKL0YxNDkgMTQ5IDAgUgovRjkgOSAwIFIKPj4KL1hPYmplY3QgPDwKPj4KPj4K ZW5kb2JqCjU4NyAwIG9iagpbIDU3NiAwIFIgNTc3IDAgUiA1NzggMCBSIDU3OSAwIFIgNTgwIDAg UiA1ODEgMCBSIDU4MiAwIFIgNTgzIDAgUiBdCmVuZG9iago1ODQgMCBvYmoKPDwKL0xlbmd0aCA1 ODUgMCBSCi9GaWx0ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQp4nO1dS2/kuBG+96/QOcD08KUX EATweGYC7GEBYwzksMghmM0mWNiLePewfz9qSVaL9Ykqik2qJbttzLhNU2Sx3ixWUR///u1f2X/+ yD7ef/tf9r3/ef/tII4ir7uvTDTfH8YNqjpqJU5fWSX1sSjb1u/Ph5fs5fBweGj+fznIon2w/9H8 8XUK0X7/8f23w8du8kPX8u3+x+bTn5nKfmj+/Zr99M+m8ed+vFOH50NVFw0cQkjd/Po0/lVqocXR NJ+bdkF/PXX+7+Eff8l+OwGmjlULvOwAHP/6wQhd1fKoRHERyC/nR4+F0LWSeVE5P48H1rqHx2RS 1u0aGsieD9rkzRPNV95ALPRRiW5xVSFNu1BF21V5+uXUfh7nyTH+CT2/jGCudf/l/GzBPIZNFkfx CvNoLtUwTTUBm90+WsswzpNjfApzJDw7YHbB4KJLCjxP0/rZbvfC8zRvuHgpEp6VVKb9rG1+VlKX 7Wdtw0DaB5hH4zw5xo/Gz82COvxomzcaFujwA7BZ7aO1DOM8OcZPhGcHzC4YXHRJgedpWj/b7V54 nuYNFy/ZMHfa/2TMXJ/HMC+yH0WeaVmXzf9lkTUE+/3fzcwPMWhcFHW7NFHbslSUokVF026tn7QP +BqN8+QYP5osFaXqzLWw+bIou89SENjs9tFahnGeHONHkyUbzw6YXTC46JICz9O0frbbvfA8zRsu XlpVlpTKq0xXJq4sSWlkqxyonyXN2Ykc20a7fWRLh3GeHOPH87OkMa0CpD6LNHnrnCBs4/bxWl7H eXKMH9HPGuPZAbMLBhddUuB5mtbPpN0Hz9O84eIlG+bX7VYNm49lcmNMY4SKRnBUlcn8VW4ewnZC sv0eA9O1OHZCLzMPfno8fPxaZI3Wefwl6yD40P147KD+0IBd1Nnjz9lfT0D9LXv89XDa+PUNqm0o zw26bajODYb26Mb48tivPxGuSy33iOvSqN3hWolqj3ytRL0/vlYmL/eIa9NYpDS4DgwPvcw82C5I ngJYUyvK1UlQ8/J1QbqDXwr3AmS3gJquyJwb7umaS9pQtQ05xVs1M61kx/hKiCE/U1QDYOwY4jML B12+rMi0CAe/2q5B6pkudBoAxHSgSnnuUhDaGeBXWA0PPEUR4gxAdUiFmaEMzMKynSwpQwAc7KBI zE8s7QBjwJiKznLPkSFAYnAMKoYhdAHa0rVEBJ3qxGN3RiDaHaAZPhM96ejlozs9Juj0qaldCrVR nZZGlbBYUELQACxGe+ivpEEV02QBtT1qoI8gHJTWCgCrWV1AH5Hi+uauNk6VQbW7hBXuljUrYS9+ Hc7spZ9ns+twhASWGNH3kmELgmwWc+ILVZPAnLxTgLoWetBpeD8ixBbDYnhIwUkESFnXi18tNsBa oAfMAvYctAYYRXaWCeKu4q3yi/Hw78Fr4heDOIN5eWLCvDGkDLxG2oAeH/SIokRyXRHdFCCIAc4X cBUvEbxnSdGsAvxXB6teiubWAhRyAcoAEFaHrrOPuNYW+G7CglsOy/Rny7579Oet/8JJW8aoTwGo Cb5QrQkvqmHZd9PLntv60Aadd4rxHF/R4B+xJrzH/3kXLx1aDhRj7e6h8mkTPqNKehGm4hefBmWu vWkAO6EQKnXqbBw4cah8cCyMm0p8D6XpIwBqQSGTIJ1gEwB2MHmsQRewmHvKgzk7LYzBzgJGQsEY jsVdc39ZVsYmV02JMxcbZON8MRz2nlpz0/JuIJ0FolgeNo43nKwF84jIgk5gfQ3c9wPovPFlPVpX dOEy95y316uE+fCggI+2wiMOVTUjDVqzkLKbU3ROeY9v+c57JXaIETkGMtz02ITnE2Ytzie36/Al RB7Ywwct6CNsfMNjFw2PgPCzzI74SMH9SH42iOQhDiDrbPwrwHp664sLWVmXxuZlLQnwvec2p5aX R+LAsHscpPGhihhs5/CoL0SzKTVRGbAaoC9djeZP5wPsARCCPWpFhcBnCbCA9ccPo/21oude/SEW BOvmVrdcztCoVPFMRiWNk9whhwZ3EUGjOV8jK5pie+DBNCDOwHjQQ6yoEiIzbxyOANBo/Eh+obAK DG3BevQdQay6h2FibN54CiMOWAkOcdeXB+wV8B7r0SIc/GnT3bR6un58mvdggHQAqseJjUd+FZ9w liKWHrIr4g/y4RFeOzm8zzhWIi+dWAbeZWFHJgIsI88gA/CkgT0N722C8gVe5Zl3+aEOumOsRHj4 58HJMgFsNqfdN6uq1jmefe8aMiBW6wEY6yV6KOY1cyOXhDM98l755BtHRCOOPSiVE1Q2jMp7TB6B BIg98XRYrrlC0t6Xm5gQwJZnBqPQRdxF1mIYFU7Q+MAiH1gKkDo+B2aV4zDM6Z/YZcFhP92Kx9hk 7egUhc8AiBCrSLMTvx5H8E51mqzHrXhVMcQZdtlJgjOgI9Vn0oBlXQoOzlghgdiTnM7/CdP4p/yf C4l3ISBlyQASRSkkySvgY1erZArjqTAb4/fAB+938/nIfCYGW9U4EfEEJQpmBKohbrWSNlLXqZX0 CG5sxGS833h+HDOi3RzOa5oUYuOxPbmOg3PTZ/vVZ2tpCZr3E3AyvpVESu9UkUv1UC5sRQSZMC5P +9KJC000IIhzBJMWnoEXR7+bBN75Hmt5jY0NqOVVYEOgZPwLbYBDAkc8+0qVukYQDuA3KPzWISB2 HiEg7aGulsdS0tz3EJBwTAfVoCJ44xRyYgWrWxSRdspaUbcXLImB7wAD0EDJq2nZEsoa7xaIxRKN g7KgY3Yg9KAFa4auNgqksHxHXdfMLOI+Jv2VPxI3hoC49M9ZZwx7QLbc8lk05bI0s1AUxphFUXZQ IDFUHUAPFQEOQTnIgAtAi/gU8Fgx4QK8jVJfJYcScI9S34BDpv2UmfZ5p7OQ9V3UzPoggoSVy3B0 wRaaemCAzRjrxWsMGajszt8q3D3iXMcC01y9flVJI18pGOU6QNbHDihJ8Dg5jlBfErA9wF1nQMpn QEnSfq4T2srWhq838whVrlJtGRJD5XHKVz2scwHR8vx2XsY8tq1J9EWKU6TrhtxOF7BvnlIxsoo3 EqeOkmW9n9SsjRS479mebrZs/FYlzinyVarEvWXs0jsvjW7tRfm6e4iYEazkUPKMZ9BbEdVbBuib ygBNYxN2lROawjnZrqn1qMXls3sCIhd8EgkcbS+vvOqDcVGUsRruH7h2OcKlJktqez3oXTgisnOF YiDhG9laYDoPYBVuUwS1CT341Mp1blyJofCSXFLDpyd7bJyAQQI2X2y6dozgRBpTnFAjRi7oXH47 oUe+RMB2zVek4hgENXjnm7Xurjy8OOkBqiLvhBpBApgHHPFbGjaB4JYvQnpcOV9EC+2NxI0hYAn9 bwkkZJZbAondMJdAcqnZ0YWx0Y6pBkscpM0GxW93QtmPbNfJCHHu+HvG+ISBt3fP1Nxu4HZnFDfL 7u6MimMPyjomm21V/d3umbrdM2WDvs49U+8qLel2ERXBWMKLqC5V/rUm2j/4Oqs4Zmh4YdsVy+xX uhg5QGvcdjfzcuSRSLL8/Mgj2J3E3Q94U14M757nZD6HMsBzX+6YxUiyCPH+eRQmyY5OeBPfparb SFt3bz1eFMVUGfFqM6+U65DkTDogn8CDlrzLmEJk+rD1nCx7RC7YgBlqGf6ENSCkZkoyKixv9pju rVUcmsFl9XixZYzXj77xikN8PWavo+aKAxXtARWHtEYPX41KT33wRM+RTw2Ocj2DZ0DaJ8AIX7W4 vFrybbyWU+VDeW+cssZ3FQ5B+8ifsAQU8qxyh/I7f6VoyEvT2Hu/+CMp4CD+GtN1Kjl8MtD5FL7b i9hsTyPKu6x8ywmi7IVylTuJufvq4h3ecSa1tsmiIeeNTZNDPwyuZoIkqODLm67j3ChJ0LSndIng S8dTn3VtNW1jVcfs0reVUgFOckFylOtFgBAx3r0LeIesPfDVklzknuJK4nXvIMiHG2k2ewfBdpUs cGqS29D5TcS1a8WWqIzNpoJe6X4EPKWGequQ8EccM9Od3Jx1xI5EcT+XObhCAHH0+3DHTMD7QDCc wwfRWJ2xnQvFlapsFE0fiOR1/wXD0795HHS4B2thLVygVuT19Are3gbBdtjTdYgvKPFGnAg2opo2 GiMGyGkPaCimH6HEC0WNKcnt7L01hEj9uIQBVKyBLjTKoCDsQFeqKLbMdCFg6Er7+zqGW0B2zANy WoBDMSN1aUvyG0FN8529NAiSRbvS/sf359BYyEP2cPg/myk2y2VuZHN0cmVhbQplbmRvYmoKNTg1 IDAgb2JqCjMxOTEKZW5kb2JqCjU4OSAwIG9iagpbMzIgL1hZWiA0Ny41MTk5OTk5ICAKNzgzLjkx OTk5OSAgMF0KZW5kb2JqCjU5MCAwIG9iagpbMzIgL1hZWiA0Ny41MTk5OTk5ICAKMjE5LjQzOTk5 OSAgMF0KZW5kb2JqCjU5MSAwIG9iagpbMzIgL1hZWiA0Ny41MTk5OTk5ICAKNDg3LjI3OTk5OSAg MF0KZW5kb2JqCjU5MiAwIG9iagpbMzIgL1hZWiA0Ny41MTk5OTk5ICAKMTg5LjY3OTk5OSAgMF0K ZW5kb2JqCjU5MyAwIG9iagpbMzIgL1hZWiA0Ny41MTk5OTk5ICAKNTE3LjAzOTk5OSAgMF0KZW5k b2JqCjU5NCAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzUyMi43 MjAwMDAgIDc4MC4wNzk5OTkgIDU0My44NDAwMDAgIDc4Ny43NTk5OTkgXQovQm9yZGVyIFswIDAg MF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJm ZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjN0b2MKPj4KZW5kb2JqCjU5NSAw IG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzQyMi44Nzk5OTkgIDcz NS45MTk5OTkgIDQ5MiAgNzQ2LjQ3OTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMz YSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRv YXV0aCMyZHYyLmh0bWwuaHRtbCMyM3Jlc3BvbnNlIzJkdHlwZSMyZHJlZ2lzdHJ5Cj4+CmVuZG9i ago1OTYgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFs1MjIuNzIw MDAwICA0ODMuNDM5OTk5ICA1NDMuODQwMDAwICA0OTEuMTE5OTk5IF0KL0JvcmRlciBbMCAwIDBd Ci9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRy YWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzdG9jCj4+CmVuZG9iago1OTcgMCBv YmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFsxNzYuMTU5OTk5ICA0MjYu Nzk5OTk5ICAyNjAuNjM5OTk5ICA0MzcuMzU5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0IC9m aWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0 ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzY29kZSMyZGF1dGh6IzJkZXJyb3IKPj4KZW5kb2Jq CjU5OCAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzcxLjUxOTk5 OTkgIDQxNS4yNzk5OTkgIDE1NiAgNDI1LjgzOTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdCAv ZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGll dGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMyM2ltcGxpY2l0IzJkYXV0aHojMmRlcnJvcgo+Pgpl bmRvYmoKNTk5IDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbMjk1 LjE5OTk5OSAgNDE1LjI3OTk5OSAgMzU3LjU5OTk5OSAgNDI1LjgzOTk5OSBdCi9Cb3JkZXIgWzAg MCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIj MmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMyM3Rva2VuIzJkZXJyb3JzCj4+ CmVuZG9iago2MDAgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFsx MjAuNDc5OTk5ICA0MDMuNzU5OTk5ICAxODIuODc5OTk5ICA0MTQuMzE5OTk5IF0KL0JvcmRlciBb MCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRp ciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzcmVzb3VyY2UjMmRlcnJv cnMKPj4KZW5kb2JqCjYwMSAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1Jl Y3QgWzQxNS4xOTk5OTkgIDM4Mi42Mzk5OTkgIDQ4NC4zMTk5OTkgIDM5My4xOTk5OTkgXQovQm9y ZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAz NzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjNlcnJvciMyZHJl Z2lzdHJ5Cj4+CmVuZG9iago2MDIgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5r Ci9SZWN0IFs1MjIuNzIwMDAwICAxODUuODM5OTk5ICA1NDMuODQwMDAwICAxOTMuNTE5OTk5IF0K L0JvcmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVt cDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzdG9jCj4+ CmVuZG9iago1ODggMCBvYmoKPDwKL1R5cGUgL1BhZ2UKL1BhcmVudCAyIDAgUgovQ29udGVudHMg NjAzIDAgUgovUmVzb3VyY2VzIDYwNSAwIFIKL0Fubm90cyA2MDYgMCBSCi9NZWRpYUJveCBbMCAw IDU5NSA4NDJdCj4+CmVuZG9iago2MDUgMCBvYmoKPDwKL0NvbG9yU3BhY2UgPDwKL1BDU3AgNCAw IFIKL0NTcCAvRGV2aWNlUkdCCi9DU3BnIC9EZXZpY2VHcmF5Cj4+Ci9FeHRHU3RhdGUgPDwKL0dT YSAzIDAgUgo+PgovUGF0dGVybiA8PAo+PgovRm9udCA8PAovRjYgNiAwIFIKL0Y5IDkgMCBSCi9G MTAgMTAgMCBSCi9GMTQ5IDE0OSAwIFIKPj4KL1hPYmplY3QgPDwKPj4KPj4KZW5kb2JqCjYwNiAw IG9iagpbIDU5NCAwIFIgNTk1IDAgUiA1OTYgMCBSIDU5NyAwIFIgNTk4IDAgUiA1OTkgMCBSIDYw MCAwIFIgNjAxIDAgUiA2MDIgMCBSIF0KZW5kb2JqCjYwMyAwIG9iago8PAovTGVuZ3RoIDYwNCAw IFIKL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtCnic7V1Lb+S4Eb73r9B5gfGID72AYIEZ z0yAHAIYYyCHRQ6BN7uLhb2Is4f8/ejV3VJ9TRVFlV7dbWPGbVoii8VivVhV/PjX7/+Kfv0z+vj4 /T/RS/vz8fshfoiTovmK4vL7Q7dB5w9Gx9VXlCvzkGZ168vb4T16Pzwdnsr/3w8qrV9sf5R/PA4R 199/vvxx+NgMfmhavj/+vfz0v0hHfyv//R799M+y8ee2v+qBt0NepCUccaxM+etr91dl4lw9pOXn sj2mv1YP/3b4xw/RHxVg+iGvgVcNgN1fP1iVFrp6M50E8vv51bIvU3aZpLnzc7djY1p4bKTT/Pjx 7WBsUs0njpMS/ar5aCscpMo+2BJ6Tdt19qCb9nM/r47+K/T80oG5MO2X83MP5g5sRQ1NC/N5LBPX 0ABspP08l3M/r47+KcxCeHbA7ILBtS5z4PnyWr912z3xfJk2XLTUh7nZLdXmd33uwjxqv6VJZHRW sgxrS9Ziov/+uxz5SWKNE611vWhZfy8l2iQ1YrL+/En7CV+dfl4d/YvtpUTbvGJvDczdsdIG2wBb r70zl1M/r47+xfZSH88OmF0wuNZlDjxfXuu3frsXni/ThouWFt1LRlf/WxuVCya3l1SssrSWu/29 VLbnNTdR/fmT9hO+Ov28OvoX20sq1nGrELz1x9ItnBS2XntnLqd+Xh39i+2lPp4dMLtgcK3LHHi+ vNZvBG8+eL5MGy5a6sN8VE8LUNbG7Ztyu5T7ppLbeaSS4755CtMcVf3dBaZpcWiO7wMvfn4+fPyW lhiInn+JGgg+ND+eG6g/lGCXAD//HP2lAurH6Pn3Q6Uotw26bsjODaZuyM8Nlj7R9PH1uZ3/TLgu CrVDXJsSo7vDtTFZvkdcm7yYCddnPOuO/L38uWcAejzPImPsoDWqimr1LqBKpzUHKH80s1SfKB6a Bntq0I/cEy3qBhpMVjco5ca/ah5Jzk98JZ2oZkGKEU9oQ1+hkGnLQ9Y+ogcmnEIvGR05p/PT9IlH 2vClbkjdE46/UVhjulgwLPRBh0U8w3ImzXRj9zsqpUsBvcJ0+QWHycBy5vxyUnrmIcPZwZ5wsJMO moE2NQuHA/Q+SxrndXofeLFmHKryi13iHImuOUeSHYlAUyJw7ZwBSmrXPBnoIyd8WX2mqP5CX1Fc Hx7LRUmtxf0QHCzoMIrSdFg6F0QQQJpNny0u1DcqQB3sawwK8RV+GWCj0dl6jMLjlM62ZaPZABww LGCMJUucLVAQUHJBG9jdgJMDOFi2itNn9y3SGAUdZwu7gQcd+oBR2LnwSA5gW8DdcS6wTWEZAKc8 t+RB53Fqz1ImXFyk2vTlhTc7mDhwK6cy7VrvOwtZhYVcs6Rfi0HQUQD0AI2jNcSMuwFfYdUHWCic /hzqA64crAvM5QtHQchjgaGMl46LseU4IezxkyDTzY/MvjWrxyjHO97tuFagYzR9KDMCITCMbYbp GLemoZqODWY+062oWJYAFM8jfrzdcgED/I6HXuWYxESCNybvU/xW5Fvr0EvcKBKRb+De+UIa0D2g Ewr7KNZjCxdLK6qVyOzRpRnDbuS3J6UaRfmXBhzRBnC9QR8wCuKZihZD3bMAB3bKTt+AJrobBKF/ k3pA9dfRCLIg0BPuFUVH0ewrt4XTVicS2tup2v/engfN4/e2yVny3ywKU/oEnF5RnMYdl/l0Osyu QMaEI1GWDhN4hQ4LT0AfeDYJT1CMadb9AU9oAThiinXLShAN65KOoeVhUy03J1OtmX/H8gTlnncH 37a3J8CCQsMFcMp6BHiL0QMOHmPjj6Qu2Hp8JzyWeYoBnss6czzWEjgqfxjCwzHe18+vtonJK7Y9 DT9HLhiwwUD4U6QaRXpt2eEQf+BPD3n/F394yu86oEOeZETOWGD9+Z3qYKmT3X22z+1n2URK0IeY J9qJZ0fMUIfOgIqQE/G0OX7BPQDhnfk882YFs2YPnRBScF6Pd0x6O6+HIg748xCeM88SgsC7NllC 9Yji2M1i42wBQQGdAsFAp+x+ubDX+SPXgDN3PvzRFR43sDL8yV24LjeVL9u8z5hvckfICLf0JIeB mbFhKUjwYMlv5VxaIHCF1zKXESG8lolUJ6DL85SLpMxLrgBxyO9TXoPm7SM+PAAIxuNElTW6Qyxo 3jsiEbgAgAWcKHv0Cq/IaaWTGWbR55gLqTuSpkxxzLPCo8+AOF8KO9ryPI2AtYc4A4HAm/sSWvYN OAxp3H4vl8eePpNYfsdTPvH9HgMw5x46KfqUzPuLgHXjwQechME6gWYDo9An2lHWyY0whqJJwr/F bk1kvTz7hmwBPvp5yTjtiYzXtrbKaSGAkjwMLZ6dBSwmz70ARaB5wrD8QrBmhkgUMmsSt/ES3WQh PogUJNF4RVsrCapqxHmhlAuJAXHZKL15PyQvzgQiyEUs00V4yHWndgiHOu5L7zDKki131zsuoamg aLotvVrEFTv+jHgzPELAi7ZsWlahnQeREzwcE0ErKGghB8vAOXh5tkhCWIA4FzmMuWbfdPiB/x5F sVFkewQLyQHJKyjf1xHFVhE0eRxgACL5zFS+jwCnv4zpnWUEASudT690sja+DIMHX3FkRMnIYmuc gPBHKTyZjVcBN3NQcgta8zUWtjJVlecWD3xhKyDhaypshSWpoCQTNGBtKIHqUWB1t4dhQ1gFqw1L YUEDXz3LES7SXTyYDaBoezWZTGztcUYQyy9hH/CCjBfKfKzGeL1cIt2fzzn2sAb5SIyten8Dgspx FGCbAX4aNujYIwoZRDIf3cGvPiwUrxrNIbRhLh6ena0Snce+DUix8FDzBJIuPNDuCO2Q0NlNnBS7 W1302oyPB/M42J5jk0HuS4ClgJmQYOQCkgPqxwAKIc8RjDw+EyJg9Xkbn+VTHgGEATlpvBjnrWAB gbJZX8O9BmR/tosWcJuc5pX2pUM4tcuIqexkkSzD/BdhIZv1CplYYulMbPprF5L5KbHf+SQ+jzBW PhJqfJLq/ol5qo8/JSSy7paQ4VWnWwNktpFKM9LtSttoGdv2FjnvVEZrzRyEZ00cSHiTg27JfEJW eJ0cAoSUreUZEi+0kndLbm+KcFoVb0NszK5J6ZjMd6mdqFXSHxhRAKZjQFb9FRnsWFMVSltauDtI wIRfK8tCLr3NKHNMCNe0ctdmfZHXTboy5YBvKnIPjrfuBdIZ8l+mQLpg0ZmpzK5I+tzO41CAT9Ra NQzbKJu5EL9d1j2e3D1y/QQutpkn8i+gpNL4KoRtLdiBAEyPdIlZotZnOYzwTducbN8nZJMJ1Mvc rAS9h24wXMjD3bd7+pCRSqn2XqmVbjHabqRKeGDKkCJzzYnOc57mTJUgdfGb7oZYJFsS7PgdW8c7 ipFgda7b4P7Z5m2S7boTt04h83ggdXwqsHVFnOt+zdc8p4PLnFRLXIwVYDEEVDoBGrpQpAcScS6Q 4icK/SN0I3Fgwnsqx5+goGAJ0AkCKkwFqNXArQNyNllPDWAM5+LruJZh8No9GZGCmOPTkkKyGYDR 8u4OQDNQGVsdzkPfv+6ylALG6zwyYm97eZT3L4CVOS5tGlU5gMepI/1Ttj6BR4I67+xZVWOayrjr q9I6nHtj1pyMXDKn+pKbdQh2l3NfFWeUtgTJlHYxdZ+9SxEvTnUUsl4nk1vlcX/Oe1fXJfS1wSKx +6Jpo8yKNJ1TghhSTuGOSXiFNsCweEdCuuLesobgXvLiaaPPRZ/ZeyKxDhZIC2jgBQw7rESDxMWy 80wfuMa6t8RW4bcrE4QcRiYRhIXLyylbsMCeWC0VX6FkF3A7awikbPCthcUGrM8CqcOaGoKU0ofu xJpdW4moUnwflzCgTgkYkU1Dt8wSoJstouRxXZbDz9wZV0ONKGiAwksACKsMiFSEWr9kkjXHisno jg/I8/aoTM87TkCZk0hynSNnPeQ204BiThBGxk4/wG0mEWfscXAacJuXRCReQPl73lsDgAHR8fUZ Aia3SMRwQJ4O7n1+V65U4WOWu1A2npYp4u+zNnWSIT1C8ri3gj0hWKboWkCwAsbU8mG4YK9ckSj0 KPIsUPY9QL244F2DyfAl6/kzxitaS8zrYXfQXXkcjWUPhWvVkmqTKzHFfYExy8VfLn1SRtilyglI wPKOP+zmT8xmyTny0FNgD/GABWi6ATXkeO2QV9LZimh8ELqHOOT5EovTecISPQohs57XEJEaUIWR VdOWCSCUuAlb5J7rgGyhTxSO8QbXTDW2EpP3uTBvknvkfvCbm0cib8YKxnbbczUhCG2+15BkZrvV 9LmVVDuRYgIBEThsZuw8udN8tAZIVIiDhVcEcmdD3G+LOIHnkY67d51J20ZJXhDOPoczzRR0K+dy Uik5lzATUBhQC6F0hwG4AdR9d2PIy9xl7iELCZUeXwZhK2nfuD8kqsvvZ59KJOzDsJhrwaoHASeN QgIiSfbFZGVkijpVbZdILx9fOGiWIv37YeXXnSdlLoVyAZ2eg20UBtsoHUclmVoTvZ0+2wcV2yRS qqg/pEXdWjXk7aeXg1LpQ14kVV3i4x/T/stp22/9bP1Z1W9E5FV16lfVz/YGLf/YAnV8+QTvy+G3 w+cfZovZr2/GLQc63XgqUAfzLgSJGgXDzmJnrnNKu2euOYe+G+KDh7mMLza5Fdt9mRrXeHzC1/wM qeowTwHLI9M9l0a6KdduAOMOOZUJECBzJBOHbCr+mjO+j0X8tJib1waTd1BG73NdqCIVuw7Iuvgy 8rxpelV1jpZZqYW57rlGFx/mN0dYRwBTQVKF0nnjCWKmMkcrufuu6aAmoHBsgG7Hpu15nLjywZXj a3xeoEteCwd9abyB6REpBoYMbEPWwAyI6/CI2QkQB3xygkgRpCPXLZxlQJeq6qGStA8JLniAiBSo cuMRPxQQHAVz4cuiA+iL6MMeV0/wJjW/u9nwADxUWMdw8VjbldK5ljGP9uvn21iZoM5sgwtrk/Tp pGi/gPfSv3mkRbs7qxl56jpxUlVpHZ1mp6ubaL3KVnIVdDKd2TV8PKVI7SAEqpPmtAFyLRL6BDSk lFAvn8GFokYV5G7TraCmZYMDmPDAFXBwRx9S2EzIJaj7QSaPqsWRaWy+UWzCsA5ciW1SHfcvONwM JuCJmTFRBUn0L+HbCCYCOLnu3LpZfkfvJYJUWs+0/fHyFlop4il6Ovwf+ocno2VuZHN0cmVhbQpl bmRvYmoKNjA0IDAgb2JqCjM4ODgKZW5kb2JqCjYwOCAwIG9iagpbMzMgL1hZWiA0Ny41MTk5OTk5 ICAKNDUyLjcxOTk5OSAgMF0KZW5kb2JqCjYwOSAwIG9iagpbMzMgL1hZWiA0Ny41MTk5OTk5ICAK MzA2Ljc5OTk5OSAgMF0KZW5kb2JqCjYxMCAwIG9iagpbMzMgL1hZWiA0Ny41MTk5OTk5ICAKNDIx Ljk5OTk5OSAgMF0KZW5kb2JqCjYxMSAwIG9iagpbMzMgL1hZWiA0Ny41MTk5OTk5ICAKMjc3LjAz OTk5OSAgMF0KZW5kb2JqCjYxMiAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsK L1JlY3QgWzUyMi43MjAwMDAgIDQxOC4xNTk5OTkgIDU0My44NDAwMDAgIDQyNS44Mzk5OTkgXQov Qm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1w NTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjN0b2MKPj4K ZW5kb2JqCjYxMyAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzIy Ny4wMzk5OTkgIDM2Mi40Nzk5OTkgIDI4OS40Mzk5OTkgIDM3My4wMzk5OTkgXQovQm9yZGVyIFsw IDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGly IzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjNjbGllbnQjMmR0eXBlcwo+ PgplbmRvYmoKNjE0IDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBb MTc3LjEyMDAwMCAgMzE4LjMxOTk5OSAgMzUwLjg3OTk5OSAgMzI4Ljg3OTk5OSBdCi9Cb3JkZXIg WzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5k aXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMyM0kjMmRELmlldGYjMmRv YXV0aCMyZHYyIzJkdGhyZWF0bW9kZWwKPj4KZW5kb2JqCjYxNSAwIG9iago8PAovVHlwZSAvQW5u b3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzUyMi43MjAwMDAgIDI3My4xOTk5OTkgIDU0My44NDAw MDAgIDI4MC44Nzk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2 YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5o dG1sLmh0bWwjMjN0b2MKPj4KZW5kb2JqCjYwNyAwIG9iago8PAovVHlwZSAvUGFnZQovUGFyZW50 IDIgMCBSCi9Db250ZW50cyA2MTYgMCBSCi9SZXNvdXJjZXMgNjE4IDAgUgovQW5ub3RzIDYxOSAw IFIKL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KPj4KZW5kb2JqCjYxOCAwIG9iago8PAovQ29sb3JT cGFjZSA8PAovUENTcCA0IDAgUgovQ1NwIC9EZXZpY2VSR0IKL0NTcGcgL0RldmljZUdyYXkKPj4K L0V4dEdTdGF0ZSA8PAovR1NhIDMgMCBSCj4+Ci9QYXR0ZXJuIDw8Cj4+Ci9Gb250IDw8Ci9GNiA2 IDAgUgovRjEwIDEwIDAgUgovRjkgOSAwIFIKL0YyNDMgMjQzIDAgUgo+PgovWE9iamVjdCA8PAo+ Pgo+PgplbmRvYmoKNjE5IDAgb2JqClsgNjEyIDAgUiA2MTMgMCBSIDYxNCAwIFIgNjE1IDAgUiBd CmVuZG9iago2MTYgMCBvYmoKPDwKL0xlbmd0aCA2MTcgMCBSCi9GaWx0ZXIgL0ZsYXRlRGVjb2Rl Cj4+CnN0cmVhbQp4nO1dy47byBXd6yu4HsBtVhWfQBDA3WMHyCKAYQNZDLIIPJkMBvYgnVnk90NJ lJqso9KpurykKDe7MWM2JRbrces+zn3U2798+mf27z+yt0+f/pN96f99+rTLH/KyPf5keff7ZnjD Ng/O5vufrDHuoaoPd7982z1nz7uPu4/d/593pjo82P/TfXh6RX74/ePL77u3x5fvjnc+Pf2tu/pf ZrO/dv/9lv30j+7mz317+y982zVt1fUjz43r/vw6/NPYtsgfmu66u5/7f+6//Ovu7z9kv+87Zvcf 7B87dnD455vCdVfuwebVpC4/vzz6UOWutaasmuD1sGHn+v4UWWXbuvtWnrfd0F1RHq7zMqucyR+K w/1uDipT7P8w1r9v624Yh/sv7XwNtL+fnl8GfW5d/xO8HvV52De7n72+z4N3OVftlwr6Nr4/GMu5 na+B9v0+K81zoM+hPoTWZY55vrzW38b3o+b5Mm2EaElpnpvaVIc9acf03NS23V9323jUB+/+uc+D dr4G2lej56Yu7KE7bkwbTV2Wh+5A30b3B2M5t/M10P5M8xzoc6gPoXWZY54vr/W38f2oeb5MGyFa Gvf5JNZaYPJJsqIqiswVeVt34jEzZfbff3Vv+XiQBQKJYw6/w84c7wQkzvOVBx8/795+qDKTZ59/ yY49eHP85/Ox129cYfIm+/xz9qd9p/6cff5ttxew/Q17uFG/3HCHG83LjcL/xrGN95/78c8017ap 7nGuO44701wL1ZXnKw8eBtQNp9s3F0ZknOlG5Kr8NCJTef01T35/i5f+TnhxmXsvfvQn6v3hRvly 40fvGzb3u/bBWw7T+o3CN4zfqL28YMXLjSf6Dei6TwW8YxFt/OgPv/EfgUb9KYThw1jcsQ2Tv8xQ 4U/Zo/8amBC+MDA66BkdnbHea5F2F1l+01Am4C8ukjJ9xLzz5wO6DqsNHYM55YQqIHZ4rd+xvKaj BWIPMNYi3CgsNqdCHBy8BaYQlsGpMMyeU1sbmhFT+9sQtn/6JnOtv2NgMXXkQd2S4UXwLlgKKkJg zqzx1xd29/FGe2XBgcvAWDiXoZwqghL5rqKNmiPJmAER+fzPlGxrhmhGsIt0GREqHZTIIpg7lRjI 7UGmwPLD5oZlAM0NHuE9hWUATj3HyiEZwnxQ4R+SoEps19XBefdpCG9QxowMIn0CIvjju5cZibE0 DFoaxuZZNxtF0xn5p+v2weRFmRlzvKja/d1OvTem6a++7MzeqG/Lznw7f1iNH676dg/fPVwfn8jG jxbVqd3uav/d4Uv3H/adOj187u+X3a+7xx/mtqPKk/iyH/zVAEYKG5YrXxFqM9fXQC1KV1dR9wQW R7lAhPgGPgGvvTdulCIl7oixwFjgEaB1eC0XgVwUvyq1IhqqGTyyCOwAZNl3TEkUV3WwJzDNyHRR n6Vm4iy7SoA8oOUBq8fpfZYtAjSyCbvpwk6wvZG4Oe/mNAQ2APAIDeLm2BTfZJxnckscxDAfS0Ag KPG7xgbfg+vNV1MB8sNvUKRBTiITZ9Ha1pvF2+gEy2CeqBHCa4G+/cXkEFgER+DaLcCXdLSoZ8Ek a+D7GvRxN2InGt+9xkOBHEDqAETIoWneDy4xOJ2mz+kQRZGzpdLuuVJtzutw7KoxCWQXgd5yccfX bo5NxtVBtCpA+4VH0ieIS3uu7Dogbq6XcCAeOgacXYMrb4r7ZA4a4TGi88HhIi7YEXTgEyTgsZyB wMoBHMAVzHTnXwSbSvf2uoEPYRJiXrvijJjXrryAmNfuhGzvrzzE/PhhNX646ts9Ieb1PsAPEPPu 7rld6yPmhw/7TtkhYn5sdwHEvHbnuLXK4++cFQPIvhpWfDfcS+TwpUAE7j2UKxrxXgJ7PwIi5DA7 VVZUQHSqrAoAEFzMtYLoCwUJwbr4aiYuVGDr6sA9delUdyJnXnRpOGQQ0Q+Ks0Xv7qmAUNGO51li A1A0YxYXIZciAohEwJnW64gADgk8g79FAHfzeJ45BMQycaYSXs79EBGx2zNCd0qsumqCa8WxCW4C C4Kx+NJQrVKyZTSCtwU+1QA0d8UUx1D1gEI8kUJc7jwKWSa9QRB5ycPZ/bB6lH7cDxURnAwdEcBX NMIb6V/BVBNghAK0RhDOLVGIqTbUz6kSD21ckMx4/P4sGTBcY6baDurDlDP1aWDXkLbNyrq+6xYy mCLmUEWGFHk93iERyxuIvLo2XgEwccfoFjAZauwK0iokYjhgdShx2bYJdU0AmQqwdwl+r6EPU7Qr wm3A3czL2Md3rKhr5KHmjCxBxiIHoVIY1bJ0CsLVp4hCyBicKkGaYrz7YyQk1YciQiQAduAhRVRR jzBDuDqY7iKXOG/5ltGEIRoTryBwKDfCKWr8t2jlFTX2xUva2Ete0saevKT7K89LevywGj9c9e2e vKSNveQl7e6e2wUv6eHDvlMjL+mx3QW8pI2d4CXdgjzmUCRVbA0Qg1DBgOurHIy4kTNWZf1plqsE aaLmeoS8EvhRuRK4ENR+m/xsOUiuJCcLFxwNtSQitDxOZrFlAKaOt/XGq1JLQWA4irHFJCiJIqkR njRKmrjc6UZfxGg5TgZbVU35KgfKV3lR+SrPyleJyld5Vr7KsfJVDpSv8qLyVZ6VrxKVr/KsfJVj 5atcSvkqN+VrZcoXz69Nj5SYpdATct70TKkI74JGmhtAxzTqTZAZJ0gEiMCbBJT8ul0nqgmKTR2M pIoAJHQ0nk74kJ7cL1gqCYQRVI8SRMEJMucXqfsX4SnnKQiLqHPzuA44YxKo6rPka2r4eBRM0wgI F7oOcxqQqEpMtpkQSRTh0psjkiIivQh2Ls8mijUZJ4cJ1+N5F/DUmHoM6d7F9SYg3o1FEbKirwF+ m+233Erp8Mw2d/FTBDOiEI8aIe9WEsG4kGQGScW7PlN8rnEehXzPuiw3wxy3lzhxcy4rkP/plUXu 2NTTiIsRVeyNtTmVGLMJK7O8mDJPSZ+lyjssHtzgJhNEgacLiAjHI+UYkqrmnNtztVSAjnI31LVo lKn1WdqiOr1mq89CVmae+iwaSYGC+AdJZdV09z6uA035FnhLuP8gIhllFlfulvE5mV9AGzye736p MCIsZ6EM0F48VObUd6rIRvjXOFo8S53NZSr6cIEiIPZFigBxg0utTFDblOcYjLapLsRgtE3dx0rs r7wYjOOH1fjhqm/3FIPRNu5CDEZ399yu82MwDh/2nXLDGIxjuwvEYLRNe5rrI7kOzqPayrMn7woB 2+Qd0wAZNxVhUxF0FVX36AlR8x4YSOnfwUPv3DuvK/YJmuGpI+lhpv0jKrhL0b0vWrWY0808dTSN N5oITqOhOQGcM8eBaxEbWnC6pAK+KUiMlpTGpLjzWmIGtmNiUmWVoNZ0hNP9NhkiGlTID87Dffuo KQ5MG1r/OVnb1M5XLen8/TBIFZuXegxvNFqtzIQi7yzUb+drg1Zxd7fPIDhcja3i/sNq/HDVt9tb xUVuG7SK93dP7drGs4qPH9p89PC5v0tYxd2LThrQPO6JZfSqDeOfriTOYjphNqoAskzPqohg38Dy BNH7Arrkx1oI9hj3b3PNkwd8pk+yoO5NRBqdIO5afLyykpZUtNFzFhFGIzhwL0AQk63oOnV4ETxk mfSGDRVM5DKCoPF54vu5OitIkZqDHNaS76AiY2hoDtKHBp+6ZAA82Lz/CV6PzIOI73P1OvGlB8bZ Zqa8mBiwTzUrzNn8tIA3wFzy4HLYrwhSB4KngIFB3anKX8Mr5Md5bw9ZDS2NJ++9PUEObgTyAsE9 fC14yB9Mz0mvMU4YbmxPo21WVavuEFRQmPLcXUg50MhZ5ko9D+QDqQZnlfIjM2aJKFJIjZEEFSgM P8KmiSi7zMtW8Fp0/pRFRN2AAw1IV6BdSY4mvJ+E/BvFstwmviACgUyv4iKpFSNJ2eN8SeV48577 V2WQIcxR71CSCadQqfqe4+XWkjt7mxMFZoJeI+qaCZwWCnlvs9TyXa2cwv1AAawI3s6Bdg4cKuSS 8TmNWBc9oTNRXlSdeToSGIvGPhemSaB/DjanRwMvFH0jAM64Q5azPw2VCuAo7iinlo1kQ8QWTpia 01uYMWH2YdnXYBaas4QT8B0F5IQsu6llx8vS4xArLzdw5S24/jz/UrBF7p6GdGRKWwYnJN362wL0 UtdSMXW2sPZcWgGwIAE6wm2KCCUjnUFwEEZCIbPAZfdjZMSURRIYFbMAyunHY/AzmARnzsxSkDxC ++EgjEY/uIyllRQiwqz0SoulGJ2SWgsCPE2jKBy3lwMgnY7AcE1w2rl5BGzZn8No5XdaaNaNjvlM z78Nsempur8148X8noMAXH4apSAIAB9JDxNAZ7wt/WfACR5QegZigEcPVv57MfggwNWuSRveEYgb AI6kFxVwyyAA585ReRrngr6uWLd0cEHlWPT0Amk8dynCMuSBzQJwcUt1vL4Mt/IbvW688kZ0Omcd w6mqc1t54mJRJ5ArixDNRGQLKJziEeF9g6VZCbN7ZXUrlzkAfVN0FlB00s3iCKCVYg0R2KTAIyQo UsfzutcS7KckYnKP1XO9lvvIBUcHqRyI3sut6iaZ76+W+Ud4AGgm2TJlrQQH5axFoVjN2eVU1F/I Vt/smPkphm+YwvgLc6ESll9QCxU3HblTl2NWLfHWcp1B0xpqiiAZ3XEZD43iOHdjla2FiQpSvTQS JCS+SGowbGgi2WJXM2encqXC2CCj3ixsIpdvY2GriuGB2oWlczESibbCzf8IMXw/4d6rZf+CQJON 26+T28diTjrywNbB0W0BsokCQrILt2D410MfazHs1xunuLkJ1Rh7cVb0Xxe6vLkW9fnWWgwfyIwo LON1yxgomxvAY9MCsGmtFsvdmQ5TU8mtJ0Ci1QUdwVXWoRngjCmicAyt4huBvUMb6VnOknhQnn9z GzOHq0sRS7mZn5PF9I2iFwQUdL87m/P6iBQeXtVUE/JvTnnUCx1buwXNLMGEb1MpXGB/z1IxUfHw z83MCy7UImbeDc9kiyg0FiH+YabTIyDkloyKiCjz8AQsFItH42iR1NKDVVB4843FmYQGErqIDFU5 cmsWW5cHEVFYz0JxXwHC4I8FKwbzsruC+oYRR+PFZmxDru8VUlY5oGItJzjQ0WI/uArFY9nXZXFP lQaNG4uDtfM2HelnymgiQvYnOBphjhKxqFaBhmQLf0c8+q/RQGl5YK4gjZmbYWtlO6FDfK9xXYDT OWDAWYaP4vMyqxIv8Cz5UBS3wRlDPfZ+VRteM20e5VhHpth8Y7LXmWyA/ekINxcejQD+ob5SPFFE ALrOghdqmJycQ1LMWXJ48LqUru/DoIQZAy+3xpmp3NvOj9MRHFNwqwoURc/sXfg9r0s/+p4BZAFq ERq+jqgryiA9pGf28mLnGsG885QcSK+Gy0WdJPhI4TAIFRks4KB3HwU0iYJCDvqpRflrulHT67JK DnoB+QiP8Ppca/WD4+DSJyhCXAJ7pPFLEUc/aKA6N9U4dARZtWkpalqKZihN2ZwL2W5B5Kn61G2i Cy4AgVxLE+QX3rSokzJ2wLVWGP4iRwXgjEmcr7cJ4JKchs7DarlEFch+wcmSGho34C+xJVJVWHuV n08o4RrnHYcephuga8laVClxwoPsAY/j/FISM8WTjgR6rAZ2wPklDjfdWJonfZQ7NJYpkpQeVyTJ a02nGBWZoxy7+HIiQ9n2P8DA/c8ijncIN3aQBlVAGNiyHZ9WZ33fq4GTC977ozuyoconocEcQrmW xr9hfP4I4rHyp728KA2lM2HaYnx2R5+OORjW5fNe2Att4UKTn3uvzC8fJyde3Lwdt+/w5AqYVX/t cP395baXoYAJ81Lm887L8YjGQfsQku2fitFzgSuzYC7b3RNmoa1nnQWXeycP2Q8+c7wMgsqH5Ew7 75Csv6ECqzRYx3f+N3x6R1qARvsA/msMD4Lz8T2+e6kYqPvdb/bcTZGpDmPt//nyTXpEy8fs4+7/ MSmXPmVuZHN0cmVhbQplbmRvYmoKNjE3IDAgb2JqCjQ0OTYKZW5kb2JqCjYyMSAwIG9iagpbMzQg L1hZWiA0Ny41MTk5OTk5ICAKNzkyLjU1OTk5OSAgMF0KZW5kb2JqCjYyMiAwIG9iagpbMzQgL1hZ WiA0Ny41MTk5OTk5ICAKNTEyLjI0MDAwMCAgMF0KZW5kb2JqCjYyMyAwIG9iagpbMzQgL1hZWiA0 Ny41MTk5OTk5ICAKMjIyLjMxOTk5OSAgMF0KZW5kb2JqCjYyNCAwIG9iagpbMzQgL1hZWiA0Ny41 MTk5OTk5ICAKMTkxLjU5OTk5OSAgMF0KZW5kb2JqCjYyNSAwIG9iagpbMzQgL1hZWiA0Ny41MTk5 OTk5ICAKNzYyLjc5OTk5OSAgMF0KZW5kb2JqCjYyNiAwIG9iagpbMzQgL1hZWiA0Ny41MTk5OTk5 ICAKNDgyLjQ3OTk5OSAgMF0KZW5kb2JqCjYyNyAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5 cGUgL0xpbmsKL1JlY3QgWzUyMi43MjAwMDAgIDc1OC45NTk5OTkgIDU0My44NDAwMDAgIDc2Ni42 Mzk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAj MmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwj MjN0b2MKPj4KZW5kb2JqCjYyOCAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsK L1JlY3QgWzUyMi43MjAwMDAgIDQ3OC42Mzk5OTkgIDU0My44NDAwMDAgIDQ4Ni4zMTk5OTkgXQov Qm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1w NTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjN0b2MKPj4K ZW5kb2JqCjYyOSAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzY3 LjY3OTk5OTkgIDM5OS45MTk5OTkgIDEzMC4wNzk5OTkgIDQxMC40Nzk5OTkgXQovQm9yZGVyIFsw IDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGly IzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjN0bHMKPj4KZW5kb2JqCjYz MCAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzMzMS42ODAwMDAg IDM5OS45MTk5OTkgIDM5MC4yNDAwMDAgIDQxMC40Nzk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rl c3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQj MmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjNSRkMyODE4Cj4+CmVuZG9iago2MzEgMCBv YmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFs1MjIuNzIwMDAwICAxODcu NzU5OTk5ICA1NDMuODQwMDAwICAxOTUuNDM5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0IC9m aWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0 ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzdG9jCj4+CmVuZG9iago2MzIgMCBvYmoKPDwKL1R5 cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFs2Ny42Nzk5OTk5ICA3Ni4zOTk5OTk5ICAx MzAuMDc5OTk5ICA4Ni45NTk5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJm IzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRo IzJkdjIuaHRtbC5odG1sIzIzdGxzCj4+CmVuZG9iago2MzMgMCBvYmoKPDwKL1R5cGUgL0Fubm90 Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFszMzEuNjgwMDAwICA3Ni4zOTk5OTk5ICAzOTAuMjQwMDAw ICA4Ni45NTk5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFy IzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRt bC5odG1sIzIzUkZDMjgxOAo+PgplbmRvYmoKNjIwIDAgb2JqCjw8Ci9UeXBlIC9QYWdlCi9QYXJl bnQgMiAwIFIKL0NvbnRlbnRzIDYzNCAwIFIKL1Jlc291cmNlcyA2MzYgMCBSCi9Bbm5vdHMgNjM3 IDAgUgovTWVkaWFCb3ggWzAgMCA1OTUgODQyXQo+PgplbmRvYmoKNjM2IDAgb2JqCjw8Ci9Db2xv clNwYWNlIDw8Ci9QQ1NwIDQgMCBSCi9DU3AgL0RldmljZVJHQgovQ1NwZyAvRGV2aWNlR3JheQo+ PgovRXh0R1N0YXRlIDw8Ci9HU2EgMyAwIFIKPj4KL1BhdHRlcm4gPDwKPj4KL0ZvbnQgPDwKL0Y2 IDYgMCBSCi9GMTAgMTAgMCBSCi9GOSA5IDAgUgo+PgovWE9iamVjdCA8PAo+Pgo+PgplbmRvYmoK NjM3IDAgb2JqClsgNjI3IDAgUiA2MjggMCBSIDYyOSAwIFIgNjMwIDAgUiA2MzEgMCBSIDYzMiAw IFIgNjMzIDAgUiBdCmVuZG9iago2MzQgMCBvYmoKPDwKL0xlbmd0aCA2MzUgMCBSCi9GaWx0ZXIg L0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQp4nO1dS4/cuBG+96/QOYDHot4CggD22A6QQwDDA+SwyCHw ZhMsxotM9pC/H7XUL/Fr9kdVF/Vq9WB3emiJKlYV68Wq0vs/f/tH9K/fo/fP3/4TfT/8fv62i5/i vO4+Udz8vLscSKqnNIn3n6gy6VNRtqPff+zeorfd193X5v9vO1O0Nx5+Nf94fETc/vz+/bfd++7h u27k2/Nfm2//i5LoL81/v0Y//b0Z/Pkw3/6CH7uqLho44tikzZ+vl3+aNM6L9nszHtt/7i/+9+5v f4h+2wOWPFUt8KYD8PLPd1mW1M2dVVzcBfLb+danIk7rxORF5fx+OXGaHuDJoiIpn1o0183S0yxv 7mg+eVRk7ar34w0OCpM9ZQ30iT3e3b0fP8/z6ph/j55fLmCu08PH+b0H8wVs+WH6FuaLZxWHS2zY +uPntZzneXXMb8OshGcHzC4YXHQJgefrtP7RG/fD83XecPGSEp7zpK7bh5V9fs7TZg/G7XgPBmv8 BPPFPK+O+dX4OU+TrJ2/7PNGnqZle40NW3/8Yi2neV4d8wfCswNmFwwuuoTA83Va/+iPe+H5Om+4 eEkJz6ZRPC0Qps/PzXget8/tw2CNn2C+mOfVMb8aPzdzFmn73D5vNOPlSWH2Ybscv1zLcZ5Xx/yB 8OyA2QWDiy4h8Hyd1j+scR88X+cNFy/1YT6aaTUYLYNsnyLLojQriqIx9yKTR//9Z/OUr61tI7Cg TPtzCUw34rCg3m7c+PFl9/5L0WAgevkl6iB41/166aB+14BdltHLz9Ef90D9KXr5dbc3GA8DSTtQ ngfSdqA6D2T2Fd0cn18O6w+D6zxOzQJxncdZsjxcZ3G9RFxnSRwI10JX5+3Gje2CzN4Zu7aiPGk3 qqkOwJhPNnSf24HcvSBT2yuEK4x9RWVP+sXG47M9R2ldYSob0g6x2WkgjRno8QfrliRhV8BTPBCU DL8FFgeAARyA00/2pDnjTSAUwJEa+ykAh01KmAMXV1IOAh4bvny4hcOBu4GSAW4BxkVeH75fEPQP V4RI51PuP87vPRHjcT0XQAMf2oqneq8CrkinpGilU3WUTklhI+Yj3a/AOXxH2wNJJ0iMOY/k17d0 Rola3+BYeG5pM1c3qTnzTgKzgozrGLI4T2KL1oOsrd2gmpgKcFi/Y9Ip1Vxp6iN0hY022MeAaq6S UPSB/IC9D1IKZBDVc+OIHP5YRBBMypUFoN3AFgcOt9UpogxUIUAGmwLW7zDkgOVvPQWoDU8BBUNX Oxd+4Mv30OJAKJD4AAdQDniKsyGADigEZqcmG9+4EpsFdgOwA+cxAB0Wx29xkLIV73fI6TKzBLXA VKYiFQXGcOomRmW9nV5KMyfvgu/AmYiLkDWJYS5UptKPQDouqYY7uVyGHDj1FgvBjqE6hnt5eAtY NpT6IP2Rcpy3FRDEPWdkGNgvFIUeXt6krH2nrMuKuC/s1hRrwrVQWYfyAfbUNKu9jCXcrdoKKyx9 K5Yy3MJG1c61IRd2QIfYBp2rKerocasUuY6q3AQgHe4+ZB1gF9GOtFuMic8jnXS78J+BukFop8D/ 3G2VuH4KRthUZkpmk1KAdfsKDT5EDQpbiLtcQH2BRUEDhslH+ykBrfZ7xXJhLLm8Ppmqo7lOh9cT yWFBfE0ScNrk9ELkNBiD9NRMI+C0HIyltc1B3GoXxB9oMAmVIXfAp9IGWZX3Zd0KtcFEFraOEqqP ajqUVU65N+UcAZSgk4aJYvKdCJPyMJbjpPPWAUQIVsVbuI3J7YXn+/kD9dJwdvA4gFBAIW6YJLMZ xLbkPaKYVIZ4RKiBlr4R2Xvlfxb3xYyEVrAxbVqhzKRHdLhTHyAWpKIyqrj0pyU40Nznpili3mdn 94kuuqlAG5rP9v6Pc1ChqFQ/2NA/wzRUSHi4OzyZhFse/GAnSL4BpsrAJJyeazotF2jRUU6xtQ5y KkvQgJCwY4o8Yuhxesy1JqXuFVbVywrVEd/JURVzWezBq0FOw2CAmpFbNh3lbh5lhkNowbE9eHcw KdCFp4LwGHrIEMiqTcKJghfqfkZZW8JNI3mUbjv0Iuyn4BUzCVWENAh0FFUaVP2rxK6BpwQHhjwg xHOjBHnQIVI/wGBCxa3hmC/mxCBMCrNCWpdACXmENgEfink+VZEfZ93yfOasyOcRH+GFh8Mjot7u 7xBz2MPWFbgpSwsY3DqGCKLrF5yDoHHWI1ZD98ryuuwLc0EAzSPY77BtdBRRpWmHPPg+xNxALsq4 fUgNE4nw5wGmkbYqFKxxfuDq4MFN6lF2skeiA9/8kxXOGWNJv8c2oT3qMRwFbTpaqM5d6xfwv4fN CRITNgQ3djyO8YanQkvCJYJSMl5tNU3q44MbEBKs8ywuamEiksGQmU8K5kFynyXGquwjQSw0hLHj ATpV3XhWxmWbIGvPd/kqiqo2bpTxTGcu3BTaigSxU8dJQZqNESbIFOLO4fAjCo980wWb+orh9Do9 trzawulDVc7jhdPThD+JlwIIYn1huuJwrcJ7kYToI/JY22giKXq4QkeK5ukdpPPIHRxOCI+8F4V0 O+h8qhLI1Qhk0kZbHIUewnrzwl8GOmG8lJaWPQUp4uH9ZmfL2gs+sxw16+deUV/VfVk/1UGHQ7Pr aLKi6s96S5RxfaFBb4USxvlUo9Ccf4kG0QiGcpdaAfSpIt8TmfEThQcEMUrOylNVyUwn7tPcEojj 5ErycpWlHbjrKKYqdYKq0HtmXR2kOaeut4t/Hp8MNEEX/+QDuwIZAwa6x1500DCOeNYtOQ8cCmSH 50KLfmiNn9PHQkf+5yucAju4GwnTTT+Pq6yP2drG4610DI1AIQ/ZDH/jiYeaXm6XUnwjDreEub/N HRCqKwVwaHQ3WVXX1uGxtgXvSg9tCwM80g6KiYdwKMZ4BCtQaydcTRiLvIjrvjrwoC8ofL2ofx7X x5cHrHt7a2TW8KAujzcIqls0ciK5w83N7eHVwCPljXA+FfRgAIzR6miJqcPxgdEFutxxqk4f64B3 nDwJ14a5u1Ip7sv6UdPmcmMyJ3lncrQ4Dnkl9qDCxlyVKTs8/x0JJeimE6Ir4UjqccHlUMPPgDwa 9I8awJ9oW979ZjFjCe5JN7eOFkpq8phbaBW8dJcHXbdIIEHhTCKBodpJB3FcfAMZgT3dK1KV+74a B9a8iZ1GQodNXMhERn5QCON67BBe2ymI7I1Vl1tlTFKr9P41afecLHMiWiNPbia59mvKtVNpOqCx zXjkk6aievgU8P4lh/i/u+Fgau0Hveqc3JTHNobpJ1uNSvhsIoGv4QEIsi/G6aCE6x9uAQjcOWBn nnwyUW/UNVnmkhYCq7IQp6myVnmhhkd+Ij2m8UmU9C0J1tEQ1enlcTx6w8Uft8NCtNPlzfD4GxkF KiRIEE3w8um51Gp7GFVAF36Qx+1Sfo6haFIlZusf6thSMznIGy2ENNuSB07MNRtdknegj/LCUkF4 kOd5SMouFYpVuC/gkz1B38jGfX0NUENWxOVJ6ibm8GodjZe4SY72BC0X6GtgBbkC45wnP5g09I10 bUaqE465Gam5ZleeiTIQpmz7PpPKywcTRCEOflRScHi0DPnbo2upoFSTHzH6to+9tV5+fqLBdlSs oiLieR2+8k5Hzpb39O3ZHHmy2jlpBEAjbF4qEleVHjhOtQk9tZKcMAiCsgI9THOnJS1HeYxeI1uM CyYeTtc49+Xpo4APpUKx2JLuDpbRUSJV5b9gHoYStLpeTudSgTcXwmIaJ3sc49aQtZolw+WhQsKt YLmr9m1GcmVoBwf+fluVNqe8TQ0MgCLXKMdxMJ2KVE7j1Ln+ucg6xYhRmprjrNyDGp7EgmxHZSzP rfJIBJwm7REpxdu1cBRqnECN+Za0u9SF6E3t8NzhLjcsRtK3bK422aoLPFWSb1Z9pK+pHbPC+Zg1 mXFcXvI9JoiDjHKmK8hnkxwVUqOVNznk0kAQ5RgnToaOgKCB1Dg1kxosFUKQTUU5Aa+Ltfi9Qjkr iVRe/nGEjt4qjm7OSEbJivtkZieXUdInExhjeJ/MpCPhZXwM9n15XYYVN24ByBJbhDsOHVfXODMr juVjEHhcvjyZ3GGR1L7PNwDMDWNePsNtaUG6xyipKyrdUgAOEKvcx4MaRo2ixnE23Shmnkq7Vn7o JOi57ev0qNhBWVluLKTGQopx+Dw+lhdBheJjSdSpe81mQ5bn6BI7xKndOr5acGwdX3tXzKXj61TN WUP0awra8fXeHKTE9PXBuH1D88RNzs31e7k3LBRiZy45m1TDfZpNs8nHdoW5Xys5IZ1L28hRywv2 rxDbhPBoQjiUy8ELfyRJ64I5gmgMcKgoHB5l38OTxT0cO3DkuaQSdHjir9las37YLBs/JOvoh9zN yirWkCBDZDn5DlTZbxG4EOpw67xsP0Yj/WvrvNynw5idl3ngU6dncl7kThSFqDeZSyxk65l8/wZZ Y8/ki/2geQJXnwp/tgZ/A3l3XY67BDRaoxQyi3TzykPidPPbB+uDgD63iqwv4soFyFz6Wai0fICj 4iDlVcsJysyW2ArdsSWu8IItboU4T5h3Y0zF2wumpYb35Fubfm96hkn7CsS7PFtHcSVHJ0XQ6t4j NgSOHG0sMdHLQTZ3qv/YhbdZ81DEPBsZEM1dLt5KgfMqxatPxwJBkqNGMg1v4cAVLwh8rqvW51FZ lX55ffiAlLf/zaOCzz1ZqzKK2y96Ob1gLIFXn0KB22cbYx1/XFTNfbFRCOGVyh4wNpJz+4rCFmbX VbUUEWld9DFxiBudl3WQ8xcSykDhWwaX2B5a8sG+x14pXHEo49Ja6SGSeYqPPjrJz5iYJ8mbn+it Wa8pWsAPv77/kBZ+fo2+7v4PK0KIc2VuZHN0cmVhbQplbmRvYmoKNjM1IDAgb2JqCjM2NDcKZW5k b2JqCjYzOSAwIG9iagpbMzUgL1hZWiA0Ny41MTk5OTk5ICAKNDIuNzk5OTk5OSAgMF0KZW5kb2Jq CjY0MCAwIG9iagpbMzUgL1hZWiA0Ny41MTk5OTk5ICAKNjkxLjc1OTk5OSAgMF0KZW5kb2JqCjY0 MSAwIG9iagpbMzUgL1hZWiA0Ny41MTk5OTk5ICAKNDIyLjk1OTk5OSAgMF0KZW5kb2JqCjY0MiAw IG9iagpbMzUgL1hZWiA0Ny41MTk5OTk5ICAKNjYxLjk5OTk5OSAgMF0KZW5kb2JqCjY0MyAwIG9i agpbMzUgL1hZWiA0Ny41MTk5OTk5ICAKNzIuNTU5OTk5OSAgMF0KZW5kb2JqCjY0NCAwIG9iagpb MzUgL1hZWiA0Ny41MTk5OTk5ICAKMzkzLjE5OTk5OSAgMF0KZW5kb2JqCjY0NSAwIG9iago8PAov VHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzUyMi43MjAwMDAgIDY1OC4xNTk5OTkg IDU0My44NDAwMDAgIDY2NS44Mzk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2Ej MmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1 dGgjMmR2Mi5odG1sLmh0bWwjMjN0b2MKPj4KZW5kb2JqCjY0NiAwIG9iago8PAovVHlwZSAvQW5u b3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzUyMi43MjAwMDAgIDM4OS4zNTk5OTkgIDU0My44NDAw MDAgIDM5Ny4wMzk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2 YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5o dG1sLmh0bWwjMjN0b2MKPj4KZW5kb2JqCjY0NyAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5 cGUgL0xpbmsKL1JlY3QgWzUyMi43MjAwMDAgIDM4Ljk1OTk5OTkgIDU0My44NDAwMDAgIDQ2LjYz OTk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAj MmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwj MjN0b2MKPj4KZW5kb2JqCjYzOCAwIG9iago8PAovVHlwZSAvUGFnZQovUGFyZW50IDIgMCBSCi9D b250ZW50cyA2NDggMCBSCi9SZXNvdXJjZXMgNjUwIDAgUgovQW5ub3RzIDY1MSAwIFIKL01lZGlh Qm94IFswIDAgNTk1IDg0Ml0KPj4KZW5kb2JqCjY1MCAwIG9iago8PAovQ29sb3JTcGFjZSA8PAov UENTcCA0IDAgUgovQ1NwIC9EZXZpY2VSR0IKL0NTcGcgL0RldmljZUdyYXkKPj4KL0V4dEdTdGF0 ZSA8PAovR1NhIDMgMCBSCj4+Ci9QYXR0ZXJuIDw8Cj4+Ci9Gb250IDw8Ci9GNiA2IDAgUgovRjEw IDEwIDAgUgovRjkgOSAwIFIKL0YxNDkgMTQ5IDAgUgo+PgovWE9iamVjdCA8PAo+Pgo+PgplbmRv YmoKNjUxIDAgb2JqClsgNjQ1IDAgUiA2NDYgMCBSIDY0NyAwIFIgXQplbmRvYmoKNjQ4IDAgb2Jq Cjw8Ci9MZW5ndGggNjQ5IDAgUgovRmlsdGVyIC9GbGF0ZURlY29kZQo+PgpzdHJlYW0KeJztXUuP G7kRvutX6BzA42a/GwgC2LPeAHtYwLCBHBZ7COxsAmO8yGQP+/fTammkbn6iPrK62I9Rj7HxmJHI Iln86sni279/+uf+33/s3z5++u/+y+nvx0+75CEpmuPPPmn/vOk3pPVDliaHn31tsoey6lq/fN89 7593H3cf2/993pmy++Lpr/b/fBki6f788eX33dvj4Ltjy6fHn9vf/tyn+5/a/77tf/m1bfx66u/w ge+7uilbOpLEZO0/n/r/NFlSm4ey/b1tT+x/Hj78n90//rL//UBY+lB3xJsjgf1/vsmLMulaylEk P1++2lKRNakpytr5e7/jLDvRk+/TLMkP00uydupZXhzmkyRF227K7jPZYQ1Kkz/kLfWp3Z5WD+mp /dzPk6P/w/L81qO5yU4/zt8HNPdpS5vu947m/lh5eiATaRu09+Zy7ufJ0b9Ns9I6O2h20eDalxjr fH2vvw/bvdb5Om+4eElpncuq7sYyyZCfW/zoxjLJkAar/Uxzr58nR/9q/FzWSbfXR5p7Y9Vpt55A 27D9MpdLP0+O/iOts4NmFw2ufYmxztf3+vtw3bzW+TpvuHhJaZ1NWqZJ1+mQn9v2LHsRPj0arPYz zb1+nhz9q/Fz22dedvQMeaNtL5qOHqCt396fy0s/T47+I62zg2YXDa59ibHO1/f6u9Xus87XecPF S0OaX9S0BpSWIN2nzPN9VtSmatW9vSn2//tXO8rHTrcRaFCm+9Mn5tji0KCeb3zx/efd2x/LfXuS P/+2P1Lw5vjX5yPVb1qyW5o/f93/9UDU3/afv+0OCuOpIe0aqktD1jXUl4bc/sSxjw+fT/OPs9al Kde41qWpVrjWZZqtca3LLI+01kJT5/nGF7sJmYMxdm1GRXo4qGV2Zp5Hi1xT2vRX9idqOuV3lxmO JrUsT72mhT3uD/a4H7qGwl773E1qBp3Cghy/Yi57bt7bH6lsrrCHSY1NCFBW27Sn9uwcnJW7aYe9 8xiFL+qP1mxNwtYQh7X7gGGNYbP14EOb9BQopV/BYX+gbAgnxuYP09CttAkTsSEs6qNNO4wL8wdC 0vCvwE4B1/HjAHOBkwvDUhZC0mEvgY5JeBvPGD8Ox4bmxiJDp8DKfF9g+kAHUAr7kiuKh9rcJ+fC XgKl4V/BPkB+AKUUyZAv4XxwoUThUYDsHmAIuoB9YPAEUQ7y2KiZsG+m8xLeKUg+jrDeSustFc3Q yVEVDUmn00fWpgLGQ2dfFjuMlAVlax4OhYHeEdIRU03p2jwJcNvcjSwCyAW6IXQKSM41HYE0oOYl jhLOqh5aG1ewFCbnIWI2sy9Qbk1k9lFpkL631wPwMVx5XoxQXpYSOxqDqyEIcxvew9zmxiN24jHj cNhBsAftp9ETZZUxTtpB7QBApNPNOJhxRrO5Fx0wHJjD3Z5RBAQKTO6iEBxvDakDnVIpjPYURRUP H6/vcYi8QB5eYeqh4RL0CsaE623cycn1R8Gx9PCKc/2AMyr04RDUY+HRVEN8FDDRld0M96cg2sHm KZilHnhIGcD77OpIrtRthK3XorovlXEaL3eUM8aZDjeKWmUegLGZmMFMNmVkcSS05VVlYZuvuFPW dkBP5V4aqg4iHYqZBVVhZXWMcuxuJyTaCbkMmx8JM+bckh0nY5JLy3sbu2F3ebCdhw9gdzm7C44d 38y7Uge4rxwhhFuDwO3cwuboR3cfjT+uDfETo6BhcqvsitIBmwt6KyAXsCG3KH1JHRtOyowlIBzA rCOHysbJEtz3xcPLApOCnl2JAclZBFxuNLqOpyqK3baB7G20k7hTAdyWokAJ3LrA/DAXoINrZZw/ esrwJWH7eEW0/XH+Pkgz9vg8T0IOHLRDxeaQBn4FFNMulF9nZ1AE0QqrbcfqUmADntsBDcdhe6rm iR8byo+NzQeNzaClzRggBWubQW8dA+jDHvZ02Br3dE+42Z8udFLanQCHPl5hSJCJUTPb6+pMnYZR 51jqWyENCqeSqCCefY0kU4GnYCkgPY2Vy8PEIBs4atujgMFqjuvRs2mTwm65Yve+swZKH6EbBbPF I97EF4Wzooa3wCNXmSvLwAIKhr+Hn0tgtQLptqLrEW6bMnSqYjzVdeFa1CghyyWdXs55HskUsCZR /Fi8D8EtMw15ZisJsA/oTpwmwZ32oZLSS700Hn0AmMUQxXhi0twWGXZCnkcEbpLQSCTauerB0UzD Kcf50CGHxwqAKrMkAPeXwiGCs8sjroWe9GqSgHMG60yz/pF27lCjljICIo9rh/vxNkODIbXGOdSQ 9dNYxB7JheF+O4+bNTxjW6C4wLF8x9ZQEizSCBUuVT+ARY4UCTrUxxnitCCnj+f46l0p1xFL5ixS 6U07j3MYrobwoI0go1vi7OBRTMAyboYCd0cJ2QFf8rvuNpMh6nC7ZcVwyDMJYS48UKpx6zjcCXPF CQHucLvB2JEHlbAnd9txJYR7+rhRJnBSwtbdCsCNxtw8e+kV4iyb6ksOO1d9oVMQbDFyazzONg+2 8zIvgsutlHQsjKSRBCWwQAQFeQR67TRKi6/WGvkamiC/RxKPoc4llevRghRJsU9vLNLXuQX1s3p9 dORWUbsoA+eaJKFRcAGEMzPXjakOpnJ1566cXJOe1Htd5JkS8yVVTTQuncAovHpjLGw3tQWHS/Ho c11YjNM6EqTyF4fINHyFYDL88qdC4m0cfp8nx0GSD65RYYPfoJeYYBr7IMh216gUF6VEmcCpw8Uh lDrgls48wflJj9RYvExMKGBKZiPwpnDlb9KssKZ21rd+3dqfgjMNOxUc/yjpTAK9ReDBXr1SFpQR KzgNGmlG9JamxvGYpuj6ugRIY8HjelMAJLe47bl4hLd9Xekacqts53DqNdZN9y1lmMBulJRhvThh mWTn8lJbnDBQteE6RqRjJ0k94beB+d7xkB2VVdw7qFigMmg9wt04Hv4EDZCJUjp284SHAsaUnvDR gUEb22G+4ZVUBdMzmrpMfq62iz54ms7oYUMIvIWCkBQP83E/psTYFTiYaQqHxr1DnnongP97h6rF um0Udm7Fb6bEdCCMxdgiH4LsKzwxOmKodJcrnyQ0PucF4ZnEm4o0E7yLE37kPeBLUOj1FUGg4FYZ LpCgEih46miq4FKSutDW5zm/ApPaV8sYLWeqIYpOGsgrk+pOnuxYv7SOrd8q+lBN8lLYcSZPzEx5 PILiqBquzDVHHenR3l52joAXk2jqs0UDXtN5WJBFXBdDbJ8rWXLK17hKYxpv2ldUxHyDzFDIjOJC hLs24dcXZ3p1eq4EbcULCZOri6+3nHBp6jHlhD+wTyAvQcNWTtjuhJYTxl5r6BXYHHqF2cCaOdLV Ii9RltuTwemlFeOrU9EGAwIITv6NJUnhEzZvpoU9rh4bzVguukzT83b8ALwl0Lmj5NvxNCau6guu ON2V/uSR5xPl2tim1waqPhp6bZxQAd1siGHwIiSvMIVdwx059n2f7h5VD/zRJqE7g8T7lrtQsfvT rHAtmuTSy2qS/FVq6arUfRzn5+rt/sDCya9aOO5P+ehFHgMcWS5vHDyXJjVhOmPPHu0skDm0D4w1 2HyaQc2ymo1yomMerTNLcmsh+dViXjNJ4mPgnl0YxmH1jsSzrLaWRBKT08gw5LkxkzxfrxKkQwbg ndAEW4+s3VkDCLcAniepOMwuHWlduBO7p0n9v3MVQFB+YKJwOo/BaVxzmysol7V6xpD/78t6nSfl NEq65UQAMRP6rf7Wv46cKkvXdFdUx1nA/dTc03nDhT6CKqhKPI1HyAP8HAGAW8mWjlTqkbycNrnF zDMpXYs1MSCur/Fi1ebbDtUOFpYWezg3p17tKOq929PhJabjVAuPcv2OqjoaWXCSr8A20Bu+qFBw ZAM04M4TwV4uPRvxFk/xGjjhq7wUV9E9iJzR4bJkKB4wssXfuAGVQ1FwZclLdlekLI5XpAxmjc2J PIVzxbZgeF1qj+td09ikG7gFHtP1eNsmSkCZ5B5yrJf3jmHBC7RPe/E0S3PXKi7FsJEwEa8itMHQ WBhScRUKri7zrBaPCnnh19tVHvHh5tNm+hE6PEKcGrYgD6WEv1cmEENaQqa0wH5aIZM1k7KIRPdf SlxwMcAcxXe+xZ8IZE4af7oVoL2vyFGUB0cWO1sdmVJmQ2xXuczPuYyrw3SJNMt/ZkWwTL1lMHPd NlyEXNH2BK7vcOufV2b0KDrGHawLua+0olxUD+uHqmUoUgGIoiSszGRRC2KYCymGt5wkycIkQ8Tc jF1Kh2b0qE5feoU6nHiaBUl+W/0TMuxqfP/TXMdcjrLDg2UaFRY9CsoKJPU8djpyKj1CPgqSjaGc ESVXYLi/ONw9FKe+AbfTFUtIZ0310isvfsgr6oNuz10KAi/Eq06mUvFkcwua5z1oANVrig4sRefw jR9Mfc8kDhpO4qVbvFYyFuurYgj2cr+ditTJTerNVhPFYKYpwydIeqZ4GPPlx1tqyRZwua37bAEX srfbVR0m6pebN11UFpArXvjREPY6Yiqt/HdiKTeABD4Jj9fluLzcsu2UTuaNYJokVKaQ5CZIG+da 21ZicAoOilFi0FvxHf0+T2OhcAxlUNEloSN08tTFmcut2xl+ILgDDleZe3m3FD+yIFvu9XRwMLUX a9JruCOxLq9ssAN34jwv/CrqsTrioHDbIJvmEnpCJgmc3tdDwlGCLRq5aIL3W1Z02XXhN6zHiocm G4LfYkpMzFNyBIGLq89cXHLMdRxlHclWpc4FCXdroGSHI8MNjNXgdBxdONw28PALRgm9LaTooeAF 6cVkDSzLIhsrLwozhJS5IvpZYnUybz3+qY3DzNiUKiYzF8l5UaGMOodynqsYJVzNb8xw1IXkNX66 BSoGYBnoLeEaxWKL129PG5M+FpunDsPGesmYx7joiVn/m7Oj0wTqIXKvziGvI7lM4WRNlbvuPEAb JZ0N1gxyyClUS6yyDZlDkTlKGDj8So0kchTj7XePwOFMfr61weONuYyAurGgm5kh6i436sn9ejHz sIvMOcxE4belJDBs4mCsOOCVHzzM5zsPpc1Ukub18fpodCyG8LhC01ZHQOSFk1jB/a9wVcXDXQbG EPiteTAZIGIe96kgniAIrgPHmA82U2G1iCuM984iNn2EbqLcItTgovArQSjfJjFmBLbLYnhVYENx 3zdXIcNvMscql2ZKC0QFqirn9tUbkTqiqnRDFTc8kWmoLqbxlu/69y6OA2CUl2mx1v5cvs55ru7H DLGNTRdIsiFk3INN9FoDdXGqAWlUcnGkl+qIu6pwkaqRCiepUzQJVE2k/4WDu+K77OAR6jjmzC8P aXL6cf7e5yafz396/HmX7P/cp/uf2v++7X/5tSXha59JAwftWLjZHzzwVx4x7dTi8qwWpxA2BAlu a2OZwHcGO1bbeITbDifn0canym444nF56QPkAj8GJ/M7vXSSQ4uxB4ZubUpwBRobf08S6cYKYAOQ hosEa2I/wuk6Tv3NgenAbkGvDrO29wlHoY/cvSJpYX/i8XJI2z/75/bcmLJj9tNfX77fQPtji+ME ftx/3P0fquSrA2VuZHN0cmVhbQplbmRvYmoKNjQ5IDAgb2JqCjQxNzcKZW5kb2JqCjY1MyAwIG9i agpbMzYgL1hZWiA0Ny41MTk5OTk5ICAKNDY2LjE1OTk5OSAgMF0KZW5kb2JqCjY1NCAwIG9iagpb MzYgL1hZWiA0Ny41MTk5OTk5ICAKMTc2LjIzOTk5OSAgMF0KZW5kb2JqCjY1NSAwIG9iagpbMzYg L1hZWiA0Ny41MTk5OTk5ICAKNTcwLjc5OTk5OSAgMF0KZW5kb2JqCjY1NiAwIG9iagpbMzYgL1hZ WiA0Ny41MTk5OTk5ICAKMzQyLjMxOTk5OSAgMF0KZW5kb2JqCjY1NyAwIG9iagpbMzYgL1hZWiA0 Ny41MTk5OTk5ICAKNDM2LjM5OTk5OSAgMF0KZW5kb2JqCjY1OCAwIG9iagpbMzYgL1hZWiA0Ny41 MTk5OTk5ICAKMzEyLjU1OTk5OSAgMF0KZW5kb2JqCjY1OSAwIG9iagpbMzYgL1hZWiA0Ny41MTk5 OTk5ICAKMTQ1LjUxOTk5OSAgMF0KZW5kb2JqCjY2MCAwIG9iagpbMzYgL1hZWiA0Ny41MTk5OTk5 ICAKNjAwLjU1OTk5OSAgMF0KZW5kb2JqCjY2MSAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5 cGUgL0xpbmsKL1JlY3QgWzUyMi43MjAwMDAgIDU2Ni45NTk5OTkgIDU0My44NDAwMDAgIDU3NC42 Mzk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAj MmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwj MjN0b2MKPj4KZW5kb2JqCjY2MiAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsK L1JlY3QgWzUyMi43MjAwMDAgIDQzMi41NTk5OTkgIDU0My44NDAwMDAgIDQ0MC4yMzk5OTkgXQov Qm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1w NTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjN0b2MKPj4K ZW5kb2JqCjY2MyAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzI5 OS4wMzk5OTkgIDM4OC4zOTk5OTkgIDM1Ny41OTk5OTkgIDM5OC45NTk5OTkgXQovQm9yZGVyIFsw IDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGly IzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjNSRkMyODE4Cj4+CmVuZG9i ago2NjQgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFsxODcuNjgw MDAwICAzNjUuMzU5OTk5ICAyNDYuMjQwMDAwICAzNzUuOTE5OTk5IF0KL0JvcmRlciBbMCAwIDBd Ci9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRy YWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzUkZDNjEyNQo+PgplbmRvYmoKNjY1 IDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbNTIyLjcyMDAwMCAg MzA4LjcxOTk5OSAgNTQzLjg0MDAwMCAgMzE2LjM5OTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVz dCAvZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMy ZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMyM3RvYwo+PgplbmRvYmoKNjY2IDAgb2JqCjw8 Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbNTIyLjcyMDAwMCAgMTQxLjY3OTk5 OSAgNTQzLjg0MDAwMCAgMTQ5LjM1OTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMz YSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRv YXV0aCMyZHYyLmh0bWwuaHRtbCMyM3RvYwo+PgplbmRvYmoKNjUyIDAgb2JqCjw8Ci9UeXBlIC9Q YWdlCi9QYXJlbnQgMiAwIFIKL0NvbnRlbnRzIDY2NyAwIFIKL1Jlc291cmNlcyA2NjkgMCBSCi9B bm5vdHMgNjcwIDAgUgovTWVkaWFCb3ggWzAgMCA1OTUgODQyXQo+PgplbmRvYmoKNjY5IDAgb2Jq Cjw8Ci9Db2xvclNwYWNlIDw8Ci9QQ1NwIDQgMCBSCi9DU3AgL0RldmljZVJHQgovQ1NwZyAvRGV2 aWNlR3JheQo+PgovRXh0R1N0YXRlIDw8Ci9HU2EgMyAwIFIKPj4KL1BhdHRlcm4gPDwKPj4KL0Zv bnQgPDwKL0Y2IDYgMCBSCi9GOSA5IDAgUgovRjEwIDEwIDAgUgovRjE0OSAxNDkgMCBSCj4+Ci9Y T2JqZWN0IDw8Cj4+Cj4+CmVuZG9iago2NzAgMCBvYmoKWyA2NjEgMCBSIDY2MiAwIFIgNjYzIDAg UiA2NjQgMCBSIDY2NSAwIFIgNjY2IDAgUiBdCmVuZG9iago2NjcgMCBvYmoKPDwKL0xlbmd0aCA2 NjggMCBSCi9GaWx0ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQp4nO1d3W/juBF/91/h5wKbFfVB SUBRYDe7W6APBYIN0IdDH4q9XotDcmh6D/33K0uyLfFn+keOh7bsOMFdEq5MDYfD+Z7hxz9//8f6 X7+vPz5+/8/6x/jz8fsqe8iqdvhaZ933h+lA3jwUebb5WjemeLB1P/rjdfW2fls9rZ66/7+tjO0/ OP7o/nH7iqz//v3Hb6uPw8tXw8j3x792v/1vna//0v336/qnv3eDP4/zbR54XTWt7eDIMlN0f75M /zRFZpuHpvu9G8/cPzcP/3v1tz+sf9sAlm/+YfOxAcDpnx9K22Zt+VBm9iSQ3/YffbBZ0eamso33 9+nERTHCU66LJq8fNniuuqUXZdV9ov+jaMp+2d2vHQ6s2YCbmdwdHz7cj+/mefHMv0HPLxOY22L8 8v4+g3kKWzXM38M8fZcdngHYZuOTtezmefHM78KshGcPzD4YfPuSAs+H9/p1Ph6E58O04aMlJTzb zA7vauf0bLNmeFc7h8EZ38E8mefFM78aPdusHeZv57RhTTY848I2H5+sZTfPi2f+RHj2wOyDwbcv KfB8eK9n9ByI58O04aMlJTw3phOEWT/9jJ4b052dph+fweCM72CezPPimV+NnhtTFZvfB5in77J2 BNOBbTY+WctunhfP/Inw7IHZB4NvX1Lg+fBev87Hg/B8mDZ8tKSEZ5O1w6Eyc3ruxk3Tv3cOgzO+ g3kyz4tnfjV67uYsTP/eOW1042XZIw5gm45P17Kd58UzfyI8e2D2weDblxR4PrzXr854CJ4P04aP luYwb82OFpTwKF3elp0mZtuq6cyXtanW//1n95anXlcXWASm/54CM4x4LIK3Ix/8/Lz6+M12GFg/ /7IeIPgw/HgeoP7QgW3b9fPP6z9ugPrT+vnX1cYAGgfyfqDeDxT9QLMfKN0nhjm+Po/rT4Pr2nTk dH24rk334+pwnbflNeK66NjY1eG6MuYacV3leSJc7/E8eIW6L+/vMydKwPMUGbEv7VHVbnbvAKpy u+G2ttxSZW5dPHx2Bz71A+VuoDDsiRGXRwbyph8wxr8h5tF9zTDQ7gdqd+BLP2D3c3xx5/Bs+wTU aoAs309SwohxXwzTupAgBtph1mw/a8YwgAMAGiIJcGLdJwC0DDYHlgO7BbPCE4C0gQaq/cBXBxDA SF65TzweOKRxvsy3Ix/sj5LZeFsPnaUq789SbeccY8JC8njy++oiBfDYuG8BIq/dAXfS8Vxwdlj6 3zLS3n4/DfAFmBQW577FAPcBkneXjwMuYIggwEfLlo8Y4xsFk3qOxOQJOBLfXEEG+KidJ5A+4HwD WcJa4C0cUiAY94nxrNZHNptToYsPvlok3JxBGrBR8Bb3zCFgnD6A6ABSSsk4h0sfAAeSA+y+S/yw lRzrAZAOgJnCv9sCyg04UkAgE83vZOnQmmCGwXmdD9RjH6HKWf7ZRQg/2wLmBweEyqCAsw2QCiSu i9NR/TkmHDm/BK4Mx5DjlPI6UykwPziGgHVAMj/bALpLp3iSFTgqynXg27BRyHQ4xVDpGMDaF6vo uAZhAK9XOIUoYuDAAN+OV6dyQ6kf7GFQpj3c8URxYTtzayYvcKuoMTtSiIrgqjPrRSsAwgUGgEq3 N0Ad4Mebq3ZpqJmbQvHaYAAfpmgvXImBfAgkBme78FrAGFfk3AGUoJQP4VqoXEJZDzQm0J8Fmv4N mZcSOr0aCTKq0zostnDiMMc8R/GG7xWb+XgcgLHDWuhZl9gX8NoUrE7gJ0tjLPBTyAmGOwIEZ53i 43ponRMdqqAwBz8eAuOJ+to4gg7obAAZV+LgNfFzKLoOdFh92XopZCGGn+SAwD58cl9LV4uTcpWd m/mC3Y4XsAH6Jmd+oG7D2YYnqCsp4LADSwHDIIme5+4+6t8wB+wLUDIPPysE5s6kXnJNiEb7UGUX nH3qBpEIFA0tf1ns82SnTzmXDj5IdISQLW93J85+ZGAOONwCTUfDhKcxIkG0IsD5QrVW/AggmRsx nAvH+6/SuN4EppJAN+KhWjD74q2rImN0CjIYDTIeh6S+OG6Oc3LggScMkcX7BAVpCb5tOJX117XD +/UMch2pVLdeDHDDN15eBOj19Mig7OOK3C3H1caU0DRu0iart7O6SYa4uVSkLEWASkKRF/IDaSRZ vPO0RnEs9xib0ojLUg9vQDZMvAIeoNZSV0pARo1GZk+S00CPacBbBEk4sPyFJcs1uwIOgWtNkE/G zxhqvndmeCozDEgOo15BOPz8aAdkeklCQnQOiQIKbhGeYsCty/hwjiD+J1htGjZNVxuwDfekjCBW p8P7i9qH9vOYLFwhvx57TJBQIYjko4GiELkNcKQBClNI/oBIHXcTxIelkfVzts1TqbnfDLaShzJh XyjvCzCUqMMXt0FQRZQi0SWA9cPuw94KBMw5HU06nL7Kw5d7S4rwWeLUN2hbHiP2+JoQDe0SX8tR qBBzFDhWOM/RYNsqmtF5WL9G7Q6vXYAQEgDGc6kklUmh5V6nMvKmcDh5QiVNR+jY2ov5syh2AbFt mAM4d7w2oBFUTZI8dz0Zu6qxrNZpB3SX9UuX9SoS4zJWfzHQ9kRrHVY7aTqzbXezHym+wcgnB/r8 EaYJyATnpr+kBDA+PKUSE42vq37vXDTFuQrgdzx3R0xSpyZ/Zo0jEhaWmdOa6yOzMwVXoAZUw6iM L8UNsO7AG0Rz16b6zq01vmub3Y7FN74bq1uOPIEkDQx72LFjje8KaKUGfe6AQLkC5jEMpoC4reOg Y9tIO5ClAc7Hc7eBg49g54f8AFEDV0zZKK7ulr6FDvLYbiikERBH425f0KYEnmIeFrkefNySG3yp hSSSnbte2/CWkhtK48qyA0asawujAwbM59ydBK3laZfgkwVEvmu5E19ME5BByYkVjhU3wAX1uwF2 nSBN4DzJGTAHb0zBlUSPwnejbjwe1hFE0hfk+opgG7r1dHcWsGwWoCMkqoimQcccVxMwZrZ1ufvd sYw8T4VYSwEvGNZetp7F1+188aPCN1map/LnyBPmkjahMc6KFJXLK9xfUxmywcgQXbshdwcuu8Gt IRsc0ByFM/CALAHKjdE28sjXEzlYXpdzlFy9lA7oRMQFCsSjeEZOfGxUkBnE1T+N4rDzmLuCfuTv wS2jo5LUEcchvqV9SFOxFIaKQAMFjo7ErZERTxk6tHkNOCC8+byCvu3LRT5VsFTNnBA16h3evQV2 lrqsALnEy94pl5UULQuK3yjblVRuCW7SgEl59Veo91dHYjTVwughoOPR7YbFa1Odch8cbQbEw+IF 6N4YfHa9pDlEkuHuM4gk0+AzRtI93tpp4Bzi8x7BqBwW95zhZUfBTbMNcsC9M5Jmwrw9nEY1A62V DehXEJ8yJInqcV0ZGazbtDWAJ8NHBKog9IoNyPak/X4C3LU8i5prU/Ft1yTR5XurEXIeFpIinij+ zHlIwXc3vsRUkQ5PzZDNq7nICE7dVtFS88x4SZGne7vbC05KpIizFIMvpYxCwogU8k0CeqYlcSbF u1cCwuC8UyW3SPUKyk88dGWROacOIBHfh3kqaFXlgMa1Kl51r8HeuUua64zxsQNBLv/C+s3UubG+ vbxpFUml7CZF4iy+RdBai5ZQCJpyC65UveILBxLpsqhC0LzPgE4FF73u71SZYsv3zIfOo4YWrbta 7m8PVdx1xFCxu++TB4JhL7m2yzVEgT4sqO28a7vO9udNNd//81QbBIebT1xeUdj58iQdQgTeXo6i +HyLND3ZFBpUXshBpNJJNYAjiK2980gZHf5fWt9GpCm3oTXW791zc8Nh3mKnawrCvIKPBJRDYxXy sEP2COlcpsaYR4bHgKbJ3ZMSU7mNr6FB7Lxw3xIQs6YxLsAIxJtHIx9gv2R4uSh3fb7uDZYIp1tI ZCCRx2EpIfml3OolUbj4pQuoCgJXhAMR78QO6HMCdwjEd0V+D10YTlVabeFw2dvjkCp6fWFzLxEp 1Lvem2wkwMfVV3McM4TvTTbma7k32Xg+7hdXrFku2t2sGoExwd1QYLvyC6/jGwdKfCuCxKIbulh2 sbohPhHfE5DX/qhU6ZxFvmLCPlyMphGc0GuAeaNMGdYCr+Uo1DEE2szh7CluOw/Au2JVUpltq2A0 Qg8ql6fxnIh43ia5IEaQigMlAoK2y9SHgRcPn8u7JLjuPv7WcJUaXIWbvgKoXRB55BlAGlmFLmGW j0AQriwD2s1hc91Zx76uk/VTytSQmJfs8B56Ak6+a6R1mPOyzpGO6MnvZy/07JVwKlyDMOV19HVZ Nl4pcY8wERF4UxGmy94+cHazKaDTVHxzizMV33IM8aYCN+3tE+QJJjTnjm32pWqAbGYc9i82inTk kC18fEjAZjlzw0ldMuNOs1tOrqqK7X5oJFfhHILkqtYVctiHApKLQA/gH7nnI/lPaWV3vQ6/wJoF V3EK0uZ5TzJAJNy7o5HxqxL84JpN/CVaKgFGHoUIaG/Bu8UJAr0CZQg2hucwCHzXAb1KqGcyIClY 47q3pfo/VdRn6sgJ2P4A40CgYgr6eB1riXyK8lfNufni65urug3nCDTYK8nOF2S+UP4f4HTUyAwU kJmgjIYjOUU4OKC8yZNxf4x18Yoonm7FARO4MVIUAEtqZgSA8QwtHtlPQTAS3U9ggAqcWPwQ6oQk huLGYyx2Idl13GrELny5CooGIdSWwTSzGA1K4ejK0zKiNFtBii+gMEXcR+Kzp5XrAUxX3MrhGood L5RtKFhtvH21MBXk1M4ew80fe+YXYGEJvNoKVqtETmvo13qiXUVM2WwnyK83hBOQSM9PSHzrAwSM ShRJ7tRS7sZO0aRgKenZSbxLmJwCnXHjHdQCSlb0HJ8qHkzlMJ3FOmgEzgTAGRcxglykd1XMhVmv iknPNt9pKQs3YnWWW23rMjHhR5CLpHDIBAGbADji2+AH+ON49Sc9ZKgucA+VQDzylkWIdoEIEbjK YLmAoSQN2a7X/YLaIufkGtoAxyk3jajDNuDQAZ0K9Bb+EYX2CSmvTdDh/bb2IpWaE9gs5DyFy5fh uZcSSoKkU42LuwJOLgqQFDUFOje8cNNPwTUQoMcDEnk6h4Y5fT2yTmBf8VQMfuUmDZMFtPWJy2bY 511W7fgFLNz9t4AkTv9kvTywvuakVTFv5z8WCOybzo3JhtP7yKDrXAmPuMZP/sn9TMWeKA9H36Qr zbNm3oZVZ6U5mHnuwhAXbh7pdKXd9/qtW6+xPeDjjx+v0qzNp/XT6v8nmq4mZW5kc3RyZWFtCmVu ZG9iago2NjggMCBvYmoKMzk0MAplbmRvYmoKNjcyIDAgb2JqClszNyAvWFlaIDQ3LjUxOTk5OTkg IAoyOTYuMjM5OTk5ICAwXQplbmRvYmoKNjczIDAgb2JqClszNyAvWFlaIDQ3LjUxOTk5OTkgIAo1 Ny4xOTk5OTk5ICAwXQplbmRvYmoKNjc0IDAgb2JqClszNyAvWFlaIDQ3LjUxOTk5OTkgIAo3MDYu MTU5OTk5ICAwXQplbmRvYmoKNjc1IDAgb2JqClszNyAvWFlaIDQ3LjUxOTk5OTkgIAoyNjYuNDc5 OTk5ICAwXQplbmRvYmoKNjc2IDAgb2JqClszNyAvWFlaIDQ3LjUxOTk5OTkgIAo3MzYuODc5OTk5 ICAwXQplbmRvYmoKNjc3IDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVj dCBbNTIyLjcyMDAwMCAgNzAyLjMxOTk5OSAgNTQzLjg0MDAwMCAgNzA5Ljk5OTk5OSBdCi9Cb3Jk ZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3 Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMyM3RvYwo+PgplbmRv YmoKNjc4IDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbNDMwLjU2 MDAwMCAgNDMwLjYzOTk5OSAgNTA3LjM2MDAwMCAgNDQxLjE5OTk5OSBdCi9Cb3JkZXIgWzAgMCAw XQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZk cmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMyM2FudGhyb3B5Cj4+CmVuZG9iago2 NzkgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFs1MjIuNzIwMDAw ICAyNjIuNjM5OTk5ICA1NDMuODQwMDAwICAyNzAuMzE5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9E ZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0 IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzdG9jCj4+CmVuZG9iago2NzEgMCBvYmoK PDwKL1R5cGUgL1BhZ2UKL1BhcmVudCAyIDAgUgovQ29udGVudHMgNjgwIDAgUgovUmVzb3VyY2Vz IDY4MiAwIFIKL0Fubm90cyA2ODMgMCBSCi9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCj4+CmVuZG9i ago2ODIgMCBvYmoKPDwKL0NvbG9yU3BhY2UgPDwKL1BDU3AgNCAwIFIKL0NTcCAvRGV2aWNlUkdC Ci9DU3BnIC9EZXZpY2VHcmF5Cj4+Ci9FeHRHU3RhdGUgPDwKL0dTYSAzIDAgUgo+PgovUGF0dGVy biA8PAo+PgovRm9udCA8PAovRjYgNiAwIFIKL0YxMCAxMCAwIFIKL0Y5IDkgMCBSCi9GMTQ5IDE0 OSAwIFIKPj4KL1hPYmplY3QgPDwKPj4KPj4KZW5kb2JqCjY4MyAwIG9iagpbIDY3NyAwIFIgNjc4 IDAgUiA2NzkgMCBSIF0KZW5kb2JqCjY4MCAwIG9iago8PAovTGVuZ3RoIDY4MSAwIFIKL0ZpbHRl ciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtCnic7V1Lbxy5Eb7rV8w5gOUm+w0EAWytHSCHAIYN5BDk EHizCRbSIkoO+fvpeWg0zW+or1hT7IdnZOx6RE+zi8Vivav4/o9f/77553837x++/nvz/fD3w9e7 4r6o+/3Pphj+vDsd8N196Yvtz6Zz5X3T7ka/P909b57vvtx9Gf7/fOea3YOHv4Z/fHlFsfvz3++/ 3b3fv/xuP/L14c/Dp/9t/OZPw3+/bv76t2Hw58N82y883XV9M8BRFK4cfn08/dWVRVncV8PnYbwI f91++V93f/nd5rctYP6+2wHv9gCe/vqu6rxrm2HS9iKQn18fvW+Ksveubrro59OJy/IAT7UZ/s0N 3yoKPyy9rOrd56Iexttqu7ZhfMBB43a/OB+O+/beH8aP8zxG5t+i55cTmPvy8BP9PIL5FLZu99o9 zCfvGv59u1UA23j8ZC3HeR4j84cwG+E5AnMMhti+5MDz+b1+Go3L8HyeNmK0ZITnbjivh+M6oueu L7rtd4bxEQzB+BHmk3keI/Ob0XM3LGn7eQ/zybv6cg9mCNt4/GQtx3keI/NnwnME5hgMsX3Jgefz e/00Hhfh+TxtxGjJim/4bhAV20kD/uwHKHYIDc7UePz1DL7O8xiZ344/+77we8E45nW+d/UOnhC2 0fjJWo7zPEbmz4TnCMwxGGL7kgPP5/f6KcCbBM/naSNGS2OYX9S0HpSWJN2nqapN2XZFOah7gzjY /Ocfw1u+7HQbhQbldn9OgdmPRDSo5zce/Pjt7v3nZuOKzbdfNnsI3u3/+raH+t0Atqs2337e/H4L 1B8233692yqMhwG/G2hfB8rdQPc6UIXf2M/x6dth/Xlw3ZVts0Jcd2XXrg/XzQD0FtcXojrRMHh+ 48Edqt3WdDmH69pvybrp/AuaHkJEtuFAtxuow83o4pvhHJ3jc7DD7qdw/8JvwBzuIXxkTwPV68BP IWA+/AY8kr5ahPRTOEf4FtclrxaRDHN8YIvzzW6gf52jDV8LcCj2FlbbMxT6gp1vhBT29iPdqHBf EIV8o4AcQjjgAAHoiA94LZwGWG24DZyk+DZwwtUcD45T2GxYPjAlgNSCXQDG9oC5k5GQyPgJwsUA y6XcUbP91av8u0Bc9HUgLxQslR4ZZwPrXrT1rZ5WNTTC+SE/ZiFFIM1wJlsFvF0gUgAfOY478kN6 /pFRf2AY8xZKSQh6WdCtDGUuwgHfcPTAhG8pa0oOHIWwfCC6kJUpID3DMRu6MaFc4oIKvlG6YLkC 2GH9wFOpnDY5HwAHYAx4DlfbMirLl7LpurqYTwsIkW4m8hQ1ozIRXK3zUYSAjgmaPVWgucYE+y2g mRz0f7NAl4FTIDpOQUCFOVRdhUEBoGvOywfDs14dZ3UhIPSsI2RUPCJrA2LnNGVBl5yEwr10oPsY nDH0FcBaKGCCR0LKReWQH1zAOgxQ4wFQCGsRaEs3rrRIrsRdWNUeUueOI+V+da54HdmfhxPjEdhS Ohcq+XZzz+k0bEmh+c2lPje+IBKk/BAOfDSUXHWtPxIKvy8SPNe5FLYAyANgMwq/jwGZCVzFQGac Qy7LenoLsKV42xTy4ERdfI097rMdh5/o51EMUPB9HiFMfOmOC/Tb6PEZJuCbXVTcvzABD74KOEng /4JHgMZpICtm/54IucMONeG2nwS/gA5gAAy+T6HkPFDXW/KIig7fAfAgS8PI3eG49fFHYDUCH7IP Jw1xBlj1JYMDH/FnTgYIo6zx765uxtTYhxv6hvMFTRQYCJmjRbw3jwbGo8pSqkmRQNxbr5D74K2H vQU111ehQhKaSuBYFsgoqpJz17MiJiAITVKlRqDDcInMI1PccgaJnG45C3A6ibGtUHsEIWOFKsnJ Um1K2YQEXrnyimOGMTvQxPrqWhelCB4S4KeMO8khvrciYyI9rMJFGyb38EQl4IecMQFguA80nKuJ ePDkJspV0NuEUvdj+N5JIvECtzBVBgWnLD2abUG6szHzqu4CVrViZh6xCFN0O8nZ5VEQOMyAMgAV qEoan7ARVV0ThZ0CAkqUIEAhEFXpNCN4r8LdpgjgpXvKs3i1BOaQglXRI4OTwvI5k+HKTXq8bqLQ MxeHfPlg+lOFAQciNvilEqMIOIbGK0GzqARsiId400U3VxA05K/Iuua6Dcc6V+0VeQWKFBmF8aNQ j3s7adgXTo5U6l80CU/TEgOcFFwbtFoE5YVhFk3v+5dZwYtLS18UvsC5HEj0tSinADCucqU7fk3Y Eiw/R0lS2VNW/wMpaXlMcIW+wF0feXzlS/XranRjenDLjp6P9GqSacogBfRxUsV7sbioqiiB/NCJ aLyYkFcGWpi9/IxR7VGgG6UfOn600TKkfoFpol48UiRglwpDgNa4Zokkrkfh0OR+5UgfVgjL1Z1K G+FQ91GE8NUB7Dyywlm/IhdwsTWgC9HIFHaAIiYk2EqukSmCRAo+TuN7GIlJ5wYCSDl9pGcMaShZ wT8NjsdEoXoF9U8UdwU4wMPBneY2mSh9H0gD6fbaSKG2WjxJYHkyL6ROd2kJtBCem6BQ07ifLD3b URCJzGL4ZQnF3eRhqjzUGOSccnmaMnfPKTRMiKplrBG/lKWW7ZinLkYLzRgU6baddg+zQg3faqzl XDWLJg2eeM8TCxRkCVjNxbwtvJgWdW68o8MtLhTQFMSFeHEW5zuKkgnFI7C5oazC45DevE2cNWPD 3V0bBSRdY7bpb5cja0ajZ0xTkD6Jl3ai1VoUf6XnCGmijxnTnW+sPY6QxVbS5wikC3Rd8DAoAqcR C/vSthAukA+aDLgIg7CRXGW8vRlPX+J8iDfN47SbsUJueZx7Lia7mmoQTdLYYnvZZQk3pmdlK8rc pwlBCJKwebCIa8IWyc+z+dPaeszIJ01lthFC1Yt4nCb92YL75akO/IEY1bWLqYg3+TIPzVI9w+AF PdOSpw5HzjiPwx5p/gGmoSQhIG/uPZEGts0EwAkHHXWDqo6fgzY8kW9JWvMIXrBn21UfDeKUAeMO zVhsH/WZfeO0JcP0HYjaYEXzWgg2crUpX14D9j+Ayvux8YCKpu2bgdgU1PLTE29R/ylgAen+ckOP gbGyMpfG6/tqTN1XVjiQrvJYELcgc54rEjCpoGEK1e9nysheP5HZCJm2m0NA5knTcMWx2B3UVZOq 6h+PiIx9M9yDDEhOZzu4FngL95nxgInCdwd+Jp5QJuj9ZWF5L6R/2K0n/so1ikv5dOcCRr2Q8LAz NNycd3IyW83R1URuVuPv0yTkK3pMzBMdnMmruNzCuXlu2VAkaCni7Rb2VU6nxcX55/WYxZrk/U+i HeaszV6jE3ovK8tjR8O1+6D7YEGCRPHFuHGniW5dAXtL0ds07fWkdcEXstmycgExr1cPUWhdK775 07BJ31vaDi0DmDcrZ3mZgbHkexuLsz6mDynKYgUtciyc9hYc5LokyJqieq0bE+J6bP9bSio7dVlS Um8qpz3DUCdC2kih5phPZFBXeqvVHYOeqXx7Lv+JqdRpogWcuF6AhK4XxBCe93SNkbfnUViDM/Ed rCZQRIp5FhigEEiXG2U0Hm3ox7v4UuJqTNyQlOwNE0Fc56Obx0XklWeLSzXIC3fKdT3Zqpsemvra mUqjruvGAkFnX6w4CFWXMwoQFBwA+cN7eDv19O4UGkrlCnE6p+IXCeVSIiNi1UYy9UezgnevBf2e u4cVYTmuZRqQmaEVcancaerxRkzU35hqbwqNWKDuS29outbEjpuCeDEKUcmAjQIVgqshXMqups+k oleRwKLmwXNnmI7unY9ilVqqSHaKS8Jp3xjFfbawEVk7L/rqOOvtOqoxHKu5juqWjk1AV6QbzBW0 Ws02LLbN1pXdLhNZnI1wqOtpubSiqHiaWiWL/IyF1BlcOd8yacnL/ROCyt101ZCvX0AgCzFyTaoX eOd7A56L2gPV8gUXYSgYiJRQL64hY8xf4BYC0HiMI4IRG0nWJlDVakrGTA3B/liobpAXdGUyZZ6e E7cLB25JTDm0G4sLB67q/C/FFo45qC9OlCkDCSENUJhIptKVcjxTs5yb9hofXXrv55sNcTn3V7h6 eHqiYOum8TlcN09djH2Yw0GPi+OVqvy8KDIA7ELPJndYvsXry1Bv01z7wrmhYZ+S0nfR9/IsCZ7A psgsWGqN4EyXGiI+woPJT9mbVvmRgEb1/Oc/j0roBd/nBfaJL93RdL9x9dlSgGZH0kcd0IPMA40W 8ifCR/wH9gjuWCQD/8QIPhh4QH6gN5xsex0ymz58pAgfoXPga11AXP58c4nNJO0U9jyq8i+XBsPN OiZ5eumKIQ8TlV04hyLUlKNNZpagmKClm0W7zqXE86ioECTu8DQMnremcHHwJNX0tQj85oqK9Fvq Y+qBMdHgADAgdjC9pY31OKGaqLRV9XIv8Zq8E7ywI/2AaNIFwerjrIy3jkh33yqy6XFvZ7qH7Lp8 ILdUtyVsw1Lc+wKGApCClWbkrXGBNKCt13iav5jF2kiyuo8SEedcvI8c1QY03eosNCzaR8umSR51 tSg4Fcop7lbn6qKCIdByJNxcC1cctzi4wMjhI0Qkg5KGKQQ4witQgJtxscO3iuvtMyly6fzAiLv7 eswhBbWUnFUBFdGE6ayX0ldtFV3dQkw7Te+M9EJJwRUSNEGGM2ZBvSqvWZumU72iPBX2lnstFK4x RV6WQMnmfj6L7u7zMGoT2X6zUnPImLoPuLCFBUHDR+V+eSfRIrFz0EbqdFGrI48dOkkFSZYoj4kH Hg0VGiwQJLdTZ1ieloY8zpGjocM0vHyii4uWeoIUN18KVCzAGOwcddmLtaFL2WMR8McsPGWuyxEV NUYZD7uJJKuLKvbeLAziptsF2z9NBCKHXxeaswiKqQ3cJxbZj1iDU4VYhzYaM9FHuA0I6TySPtbO xLpqoWrrMZ8S1LVZSGEqQQVJhzkodbkpPxEashFTro++hh8qg74y154Mq8ibSPdhohBKD9DpK5RT ND9F/s5iUrGy9CBcVt3HpTKnbBnT4eoSd2oDzsB3wpuww9nmFbyhaSx2yNlw8urYHRMEOQ9y8JJe yM2kGpXJXVkGOoii6FdyLbZFgHqehGh+Exxn9oL0BM4xIU5mUbKUw/DjRAaF9Wc6StfhyJl+BNBS +gGm4eE17nGjnj8oJ9MkiVM6E7SyBqOL32nP7QWL/HaLdocK17mJIG58G8iMCDezEU2Njy34TIw2 /YqMLPGFxRKeiQaY8S7gH1MCaJKc0sso5rot8ta/j5D2Yj3SNKSP/Xwm6pPWuHLM/M8o1bC+CKna iKG2jaIRiJemjgvMzoVIEEWFJO/pJ8gk5jnfFk44bnVNk9GtcFQpvNSKbEQBY1YYyBb5iuk99m8R ymSCmaRGyijJoe3HfFqgD0x5M7SNFOpf5CHGeblbEo5uqEIpLikTZOPSfHZ4JHYXVNjMYdR3ozp+ Dho8RL4lafogeMF+26o+dv1QuHEeTj84RzuKwc/hI5/Oc+W3WFtoLHlw48JOAuhgcEEnj/Mbt5mk C4dvA9zj6eVo4k4VadOat9SMLOHzaRZnE9wp2vFWmdw0QFsJahzREGQEbZ+HVHPcbCtW3VfIReuq CrgoqH/hXgMrKs+1jpqKFdVtw1hRUt/PlW3fjg83RTc+MpcJNF7iG57DMpwUVaRiRhpxZYAmQTBu kmJJ7jQWJGZxAy792klFyhCeKl4Za2Lyp9saAtdLegPquRZjYcBb9JrJdLt1VdVnWdxlgRZFUQ6P ZoUEgBTBdb4c7TKzXCtoecv89k57MUJ4RwqDJvaCNBpeYpIxCPCW6xUAM6jiXY/T/KCKvFHUzW0E zBoBCuKOxfQ7pzN5wGl+fM5I5KXc37UBg+ByiKph/KI0k3DuUgIN6dFbRZBA0aNc0ovPsHVGU/ZR NKd30zeJ+KQrDFlEmSbb3aKiZKlC5nwr7Lo//AD1hf8maHEdn2xHyk2UknfeGte8hGLgJqEDCfXh csH53IS7fbKXcPtSFw5AGKEOvlG24SON8JEd2oc/m+cBY67ZLf3w1/cnre/gy+bL3f8BH/mrxWVu ZHN0cmVhbQplbmRvYmoKNjgxIDAgb2JqCjQ1MzMKZW5kb2JqCjY4NSAwIG9iagpbMzggL1hZWiA0 Ny41MTk5OTk5ICAKNjYzLjkxOTk5OSAgMF0KZW5kb2JqCjY4NiAwIG9iagpbMzggL1hZWiA0Ny41 MTk5OTk5ICAKNjkzLjY3OTk5OSAgMF0KZW5kb2JqCjY4NyAwIG9iagpbMzggL1hZWiA0Ny41MTk5 OTk5ICAKNDQ1Ljk5OTk5OSAgMF0KZW5kb2JqCjY4OCAwIG9iagpbMzggL1hZWiA0Ny41MTk5OTk5 ICAKNDcxLjkxOTk5OSAgMF0KZW5kb2JqCjY4OSAwIG9iagpbMzggL1hZWiA0Ny41MTk5OTk5ICAK NTAyLjYzOTk5OSAgMF0KZW5kb2JqCjY5MCAwIG9iagpbMzggL1hZWiA0Ny41MTk5OTk5ICAKMTY3 LjU5OTk5OSAgMF0KZW5kb2JqCjY5MSAwIG9iagpbMzggL1hZWiA0Ny41MTk5OTk5ICAKNDE2LjIz OTk5OSAgMF0KZW5kb2JqCjY5MiAwIG9iagpbMzggL1hZWiA0Ny41MTk5OTk5ICAKMTM3LjgzOTk5 OSAgMF0KZW5kb2JqCjY5MyAwIG9iagpbMzggL1hZWiA0Ny41MTk5OTk5ICAKODA5LjgzOTk5OSAg MF0KZW5kb2JqCjY5NCAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3Qg WzUyMi43MjAwMDAgIDgwNiAgNTQzLjg0MDAwMCAgODEzLjY3OTk5OSBdCi9Cb3JkZXIgWzAgMCAw XQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZk cmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMyM3RvYwo+PgplbmRvYmoKNjk1IDAg b2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbNTIyLjcyMDAwMCAgNjYw LjA3OTk5OSAgNTQzLjg0MDAwMCAgNjY3Ljc1OTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdCAv ZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGll dGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMyM3RvYwo+PgplbmRvYmoKNjk2IDAgb2JqCjw8Ci9U eXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbNTIyLjcyMDAwMCAgNDY4LjA3OTk5OSAg NTQzLjg0MDAwMCAgNDc1Ljc1OTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMy ZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0 aCMyZHYyLmh0bWwuaHRtbCMyM3RvYwo+PgplbmRvYmoKNjk3IDAgb2JqCjw8Ci9UeXBlIC9Bbm5v dAovU3VidHlwZSAvTGluawovUmVjdCBbNTIyLjcyMDAwMCAgNDEyLjM5OTk5OSAgNTQzLjg0MDAw MCAgNDIwLjA3OTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZh ciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0 bWwuaHRtbCMyM3RvYwo+PgplbmRvYmoKNjk4IDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlw ZSAvTGluawovUmVjdCBbMzg1LjQzOTk5OSAgMzU3LjY3OTk5OSAgNDQ0ICAzNjguMjM5OTk5IF0K L0JvcmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVt cDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzUkZDNTIy Ngo+PgplbmRvYmoKNjk5IDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVj dCBbNTIyLjcyMDAwMCAgMTMzLjk5OTk5OSAgNTQzLjg0MDAwMCAgMTQxLjY3OTk5OSBdCi9Cb3Jk ZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3 Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMyM3RvYwo+PgplbmRv YmoKNzAwIDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbMjg5LjQz OTk5OSAgNDIuNzk5OTk5OSAgMzU4LjU2MDAwMCAgNTMuMzU5OTk5OSBdCi9Cb3JkZXIgWzAgMCAw XQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZk cmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMyM3BhcmFtZXRlcnMjMmRyZWdpc3Ry eQo+PgplbmRvYmoKNjg0IDAgb2JqCjw8Ci9UeXBlIC9QYWdlCi9QYXJlbnQgMiAwIFIKL0NvbnRl bnRzIDcwMSAwIFIKL1Jlc291cmNlcyA3MDMgMCBSCi9Bbm5vdHMgNzA0IDAgUgovTWVkaWFCb3gg WzAgMCA1OTUgODQyXQo+PgplbmRvYmoKNzAzIDAgb2JqCjw8Ci9Db2xvclNwYWNlIDw8Ci9QQ1Nw IDQgMCBSCi9DU3AgL0RldmljZVJHQgovQ1NwZyAvRGV2aWNlR3JheQo+PgovRXh0R1N0YXRlIDw8 Ci9HU2EgMyAwIFIKPj4KL1BhdHRlcm4gPDwKPj4KL0ZvbnQgPDwKL0Y2IDYgMCBSCi9GOSA5IDAg UgovRjEwIDEwIDAgUgovRjE0OSAxNDkgMCBSCj4+Ci9YT2JqZWN0IDw8Cj4+Cj4+CmVuZG9iago3 MDQgMCBvYmoKWyA2OTQgMCBSIDY5NSAwIFIgNjk2IDAgUiA2OTcgMCBSIDY5OCAwIFIgNjk5IDAg UiA3MDAgMCBSIF0KZW5kb2JqCjcwMSAwIG9iago8PAovTGVuZ3RoIDcwMiAwIFIKL0ZpbHRlciAv RmxhdGVEZWNvZGUKPj4Kc3RyZWFtCnic7V1Lb+S4Eb73r+hzgPGID72AIMDOYwPkEGAwA+SwyCGY zSZY2Is4e8jfj1qS21J9zf5Idknqtt3GrtsciSwWi1XFevH9n7/+Y/+v3/fvP379z/77+Pvj111x V5Tt8NkX3c+7aYNt7pwtDp99Y9xdVfet3x92j/vH3Zfdl+7/jztT9S+Ov7p/fBqi6H9+//7b7v0w +G5o+frxr923/+3t/i/df7/uf/p71/jz2N/hgYdd01YdHEVhXPfn/fRP44qquWu67117If88PPzv 3d/+sP/tAJg9/MPhtQHA6Z/vfFvaorrzRX0RyI/Pr95VhWutKasm+H3asXMjPH5vbd10kBSF66bu fNm90X3Krr01d7Zv73BQGX94yFjZbuvDH337sZ/7QP8H9Pwygbl14yf4fQbzBDZX+MOSDDBPxnKm 6r9L2Obtz3N57uc+0L+EWQnPAZhDMITWZQk8n17rhzneovB8mjZCtKSE59JXA66aOT2XfoShmcMg 2o8wT/q5D/SvRs+lH/HQzGmjLEcakLDN2ydzOfZzH+h/ITwHYA7BEFqXJfB8eq1n9ByJ59O0EaIl JTxXXX89DO2cnis/ypR2DoNoP8I86ec+0L8aPVfeDt/bOW1U3g34Adhm7ZO5HPu5D/S/EJ4DMIdg CK3LEng+vdYP8/YoPJ+mjRAtKeHZmMJXff9zeu7ay7aHZw6DaD/CPOnnPtC/Gj13fda21wHntNG1 N/5JAZzDNm2fzuWpn/tA/wvhOQBzCIbQuiyB59Nr/SDaY/B8mjZCtDSH+enY0YISnqTLV97vXVM1 TXd82Ru//+8/u1G+9Lp6xonA9D9TYIaWwIng8cyLH77t3v9Y7U2x//bLfoDg3fDr2wD1uw7sttl/ +3n/xwNQf9p/+3V3OACNDbZvqJ8bXN/QPDd4+cTQx+dv4/wXwnVT1z2uy9vCdfe5OVy3xlY3iOvW uPoGcd2bQG4O19YUt4frsrK3iOuydgvh+hnPgwWu+wS/zwxWEc9TZKQO2qOqPazeCVR1HKvjtnWn wQ6ztJXEwwfZ8EPf4I8N8Ir9yF4ZkXumwRZ9gzHPjwy9tscGU4mG0BpOeq1FgzGiD9dKyGSn5pMc pekbyueGz7IPAF0OC5CaQg4rX8Hpp8/WAhy1bIDJyVHcuFJFGHZbSoRIDMFkoI98LM93LPDDs0bk xzMv9vvKHMzcpzZWafuN5Y/Q0eUaCWvCcSSlmVYihVJ88aPgfCNSnl9xjeSNAYqvz6yFHAVBl8Mi pMA1YBRokK8ApKaUoMOwACn0AdOvJaSfBWCmYcMaL8nBsrXNQGHEK5Q+DAgAmD7lEYBkwFjEKzAK xRiuC2Adpg8rx7eYfMIB0QHoHFJYOVjbWu65gAytw33gMsBGhmGltEc4MpgS3S9AdHyhkFvCJoS5 fKRwBLZYL2QulhZlGRxG7kJsgHUALAMj4yxXg7HD0gGLgbXkjAwAo6Ab2A7pFMMBi6A6vgwZxM4l zvCKObeWADvg0NKtvBGRQacgP/grXKBwerjdfYqAyT4sIIiDzo9+Rr7CR8khdlipDF4vMcRRhhqH 15AXVXdgJwJDUy7VCZSooaRT9Uhj/yM1w+SochxBM/w4QXl5hHr0xv4uZn/0cI36NAedozDjaER1 nwgGCbPlSJZPjNajM7x9EVUnY+Ui1Mf04xXSGChHKry+dM2cCUegSNKQBuny5c6hZSAIbikB0APr ryP7mjI4GXoYQBGTzg9CVJWm7GRwXcpTI/YugApPxC7mZJQf5DrAExJliMN0GyeC/oMelTVGuKrO qcOchsDWzE12MArfy/yAvY7g1mCHGRrnEqYAvk8jZBs1x/rhlYlzzQ3DTJw47oOkISBMvhDbmHFC LqoUzs3XjltXI5huhhbG1aElXAvoBYCNyk8tMP10W7IzCvuSnvxz1hZYrKIS0thjNBTwJS7JgGLk OnB2CIQaoQymH56RyLjDgvML6r7DtaTDRkxf4XitSIa6Gmf+5KQzfha/4o/fhYM+8FSM0z5igGEH +jawBV1h5ntwZLCTuQXs5meeGHG8TWyC82JGisrNLS5w7QQ6YPaSvDFMCtRl2gdIPyASB2TUUAb5 aUO68lVL6CqHwwMi8bgLzCbD4X7uePfS4v2aVjXeD2g/Pd6vGHwAxkoReya8j0fR2WFRp1GE0Amc lSGubJhedaYPHqsiY9Og01Ep3TJYrXVH6DSMENTU+2aESH3llSOZn1tBK+Hn1ohzCo9vU7AnaBwY NrInRRxKaWRJzsH2VdEY96WFJqcTa/AsHVBxVTR1tL4MIg0UP8Q8UBFQALzCVUMI+6AGpIhYbiAr GlqF3iQaiLxRiJsG1jVMoTgXHkmRDnoEU7kWBklFfegYdE51h9wNjo/XjWSVgOiVuH9ZVYItbyog dWRMFeSgEU4L7uTPCHK4WruISqhZxikFOAQPcsjxBaSHeEbEjV4LI0qnw5xwLBAhEJ8BgWMZDkk+ uW1CICNCgNeMZ7yUP5pqziDRq8slNY0k4qruSsk8seuvI3XqMojDq+X267ggeYxfjhkrI09xo9gB jbiQDJahF8DWHmoUjr2OlvxJPvirUu4jgiCzLTlnuF3EYXiJFEqVKI+MhB/+ioaavkRyC8xlkbhq xdTWzTG2VToQl6caxmPQljVUcL2EoUuNx0aIh4hMBHoEV7QFtN1wYY3qdsPoue4XMUo6D4nBIWxv DdatcJLDGGgrA73sBwHqWC7oIsPdOi5bzGfgi0mPtqhj0norEVuI8/8MAxscOSMOVAAZ96byg9w6 vmMYljMZzjHOhfxdkt9WC0bMU4A48FwvXfBIdUaXAxaimKjdFs4FqQoUD35eUkBITpz4guHHm7Ph Vx6epFFBIUe5vZ1QmgwrNjVrRNTtSJcGGSW8ULLFOlcu5I6+8XP2qJJpsmkixRWaxmL5lI6o80/q Qo7eHiGWXpA1RMPgqFGoIWfYt0iRS/GhEVm1rftN+8ThfTFnIbcj7HMCC7ls56fFRYINrmUbriu4 qiclJEdw5Wwivt3T/bERinx6jJNK4au3oyDhINscBW/ILa4iY1xTznc7emzT4xOW2ZfcDbxNNssr 25eLlH8PTF9HktXhhOkrqXrIT0/LlJbNOOhca95RRPlmTpcZDnsFk13ELuSqMPRxNYUBXVWLbbgI 093IiPFy0+9bczx4Yi49aAkZd+fIe1/GDJ1JGvx40JgmxsMzIRXu7J08cEtNwK4KhoNz1/hArrze 5TAAqdyT+qtvrclffQ36KKBugqVLAH1AvYYTBMQvE4KBA8llk16h2AJWXwBRGqj9fW5+gCMgoJIO S+tTwCjgqeFVMHCb8qIX1sleYVdyMSB3pd2ypNGgkdru1wyzSRGj6WFX6yRDbHWlQkbUBWw0XuEv I9Y3PZRNRTOCwHaVOqv87PCSz1LgJYjwZ2zkAIcgW3BwKOZT2CZIZG/0kLz7uXP/WoiMn4syXHMa 2VXp7h2oIPyipSW4brB0LTdnZni3lonJ9FUx50JjCeVLeZsXzC2nnC9QgEaoEj8QAKeCXfVJBUUD htoyOAzMDmiCX3rJmRlN08BhAVLuAeQrxbdmRjWaDJtvur7oP8k+5JlkLJw4Of4NZDhRMb1EiB+d ximhCUi7sIfAikD9JjwpI6ZkQ3qIfXR2yMXW1VbsxIyji0R8Rq7fOsTK48XXuf0oImSSIyjbLXbO 9YrEzDvRqx7QOhNmEhEqMa0llpMfka6KWlnRGO7KzZERwN5g+tRIaj4DUmkgeoTQ5KEVGYXkM9yP ehcXnkupyghn3CoE0PlqvqtUcLaRoS6diS5S1iPCgMrrNfJ02SWSv/kl5zmWzFXIQfEqCh1BZZ8U pjdBxQQVXEwE+OAH5IWuuqUXefJIiQhxqMLLbd3OCW8jg/BW3B7icTL08HQ5nEFUGWZXfqdYROov WL+XqD+2TCA2TJ9H5seabnW4vQ9j+SWbe5eJxE0v6rSM4pLhgoX9oegMc9UxXopa2W+Zs1P2GOFC SHfaR6jtqGJklJPQoPb0UPWrLRz6Zh7e1jzsUzrNoG4N68g2bproijQ6zL05Zsjw+G0gmYgyqJwl RFxkv4oLPSPFXOOclmOVUbicIUK3lRLCNZS60xNV8XZgAB2icGFt4QlKUt5LKtSIIMiI2VuEc70F sZGldIw+8BUAnZcwQ/ZAb1gGukQTVMCbcnGpyHIuD0BD8ooRFq491g+xUqtCgk/nbjkVSCUDsHLF LcQCyuqhYLdEnRFzyiFWGiJdAbQI+lW4Q5DbemPKoGs4nTXS0162vsttBrzwKZhM0suORKwDT1dM jyiLqR5J4xSWKbetUTGEX5lOUwGuJzV/uNBuIgHytXsVUeSNI8OkkDfWugJXlgzM9QVIwOwzYQpk ENp+QhRDigUN5YDpAfVillVGiomCk1FFvEVIYmC8CoUVsG4511dBb4Y+1jF4UBJCs5pi2QTvn/I/ 3bAw00y9DLNCukhYp+rgDYcQK8ZUnOOHb/ERAo5F4iOW8NThXDI2rkKawqphGhkWoYuvIzNzjhlR Gjz9xqaV2OGVOyZ1ZFtZRSNkEWtmhClfx8tAq+IsEqmwzNUYGZnwfB/y2A4q21RyIVZx5m6lDS1h ybn6o96luY11MWdVMXoY3d0R8ePp9SXWsaFxLhNRHxfgyChWFyA8HclUmxAgXHXF6XLX7TohQ+l7 dZkbOdIVU434+YjYNuDDXEGg1s9l7Efp5JBzS7yCDxVfoWwqIugkI2kjIvI99i6piyuKN4LJrKJU rBQQkB6ErOHdR67DvRCKQae+bVWVmXWCKhXvXFGO5gDDBJ/LtdT1AcBgoUC4ZVSqzkingx3CY72Q 6t5MmwL2azVtalxaE+GU2siRv85VDzoOZFvOJUR08rCKZCqN31ZDyOFMi0Q/X7lJ9c1OFZY6Nxz6 9IIrU5fNE2tZpDaxSnXrYT1WL2+7SNHpUNTkmSIjuJegRvAYN+pTYHcniBqk09CiXry36mnvEP87 Q0Itl+uiKqGawTYXinFTDBN2RWjC1xMru5ENIl1tv5Y0jquP279U+R1o1x83K8Skb3PTdEQFGx6i vkS6CJwnr+VmF55wFJHTn2Gk5qxMYiyikkQOs8sI84ZDuqpAqI4D3/Cm4sf0jagq487njagqA6k4 LIhhGFYjIYGeY7lvbJFQuWUydrOP4FKxnh3X/MnjWvipGAU8YoCBJ/k2eGl6LZgSCDJwv0IDmHCl zIEGB8wfiFBuZDQUQ0NxchX2qxxvnrh7/RRwcr2cKCK7Al1dGlHc14IAzor9wDUn9ge8xxdTUEDT zE5ku7TwZekEMfKaKgqrFXHCy/BL3u6dDFtlbSjeYaOk87ZGkcyuVz/bylWdHgAUEdsLCjw43vgt u5TfZST/hvBxaXSPs3NS1bSk1MWRE2MNahAbYBkFbQkoQOOSKm714KHr2xTqw1toeMFEbnJHI1+6 O39qOnh26ZTt+AFikv8W4R8Kd9ZTZhW8/aWcX9My6jzgDJmQKl7j6eUjVt72CIoiNFjZ4E/LntyZ Om/mOxsrbMAVlZ8lubQCOSPZTrYgqIPNaf1wQvqlfAIaKklxE17X/ewfOwSZqp/p+Ov7Q+7h58v+ y+7/wclF1mVuZHN0cmVhbQplbmRvYmoKNzAyIDAgb2JqCjQyMDMKZW5kb2JqCjcwNiAwIG9iagpb MzkgL1hZWiA0Ny41MTk5OTk5ICAKNjU5LjExOTk5OSAgMF0KZW5kb2JqCjcwNyAwIG9iagpbMzkg L1hZWiA0Ny41MTk5OTk5ICAKMzY4LjIzOTk5OSAgMF0KZW5kb2JqCjcwOCAwIG9iagpbMzkgL1hZ WiA0Ny41MTk5OTk5ICAKMTUzLjE5OTk5OSAgMF0KZW5kb2JqCjcwOSAwIG9iagpbMzkgL1hZWiA0 Ny41MTk5OTk5ICAKMzk4Ljk1OTk5OSAgMF0KZW5kb2JqCjcxMCAwIG9iagpbMzkgL1hZWiA0Ny41 MTk5OTk5ICAKMTgyLjk1OTk5OSAgMF0KZW5kb2JqCjcxMSAwIG9iagpbMzkgL1hZWiA0Ny41MTk5 OTk5ICAKNjg4Ljg3OTk5OSAgMF0KZW5kb2JqCjcxMiAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1 YnR5cGUgL0xpbmsKL1JlY3QgWzUyMi43MjAwMDAgIDY1NS4yNzk5OTkgIDU0My44NDAwMDAgIDY2 Mi45NTk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0 bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0 bWwjMjN0b2MKPj4KZW5kb2JqCjcxMyAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xp bmsKL1JlY3QgWzI2Ny4zNjAwMDAgIDU3Ny41MTk5OTkgIDMyNS45MjAwMDAgIDU4OC4wNzk5OTkg XQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0 ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjNSRkM1 MjI2Cj4+CmVuZG9iago3MTQgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9S ZWN0IFs1MjIuNzIwMDAwICAzNjQuMzk5OTk5ICA1NDMuODQwMDAwICAzNzIuMDc5OTk5IF0KL0Jv cmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUw Mzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzdG9jCj4+CmVu ZG9iago3MTUgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFs1MjIu NzIwMDAwICAxNDkuMzU5OTk5ICA1NDMuODQwMDAwICAxNTcuMDM5OTk5IF0KL0JvcmRlciBbMCAw IDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMy ZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzdG9jCj4+CmVuZG9iago3MDUg MCBvYmoKPDwKL1R5cGUgL1BhZ2UKL1BhcmVudCAyIDAgUgovQ29udGVudHMgNzE2IDAgUgovUmVz b3VyY2VzIDcxOCAwIFIKL0Fubm90cyA3MTkgMCBSCi9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCj4+ CmVuZG9iago3MTggMCBvYmoKPDwKL0NvbG9yU3BhY2UgPDwKL1BDU3AgNCAwIFIKL0NTcCAvRGV2 aWNlUkdCCi9DU3BnIC9EZXZpY2VHcmF5Cj4+Ci9FeHRHU3RhdGUgPDwKL0dTYSAzIDAgUgo+Pgov UGF0dGVybiA8PAo+PgovRm9udCA8PAovRjYgNiAwIFIKL0YxMCAxMCAwIFIKL0Y5IDkgMCBSCj4+ Ci9YT2JqZWN0IDw8Cj4+Cj4+CmVuZG9iago3MTkgMCBvYmoKWyA3MTIgMCBSIDcxMyAwIFIgNzE0 IDAgUiA3MTUgMCBSIF0KZW5kb2JqCjcxNiAwIG9iago8PAovTGVuZ3RoIDcxNyAwIFIKL0ZpbHRl ciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtCnic7V3BbuS4Eb33V+i8wHhEUaIkIAiw45kJkEOAwRjI YZFD4M1msbAXcfaQ349aUssSn9iPqiYltd0e7E4P3aKKZNWrYrGq+PEv3/+Z/PuP5OP99/8kj/3f 998P6V1a1N1PkjZ/PowbsupOZ+nxJ6mUvjNl2/r4fHhJXg7fDt+a/78clGkf7P9qfnl6Rdr++ePx 98PH7uWHruX7/d+aT/9LsuSvzX+/JT/9o2n8ue/v+IXnQ1Wbho40Vbr559P4nyqr8/Suaj437an9 z+OXfz38/Yfk9yNh2fEXx8c6Asf//FCkVVYWd1laXkTyy+ujdybVdaYKUzk/jzvWuqcnTzJdHClJ U90MXedF80TzUzTtpjoOu2lv5sCo/C5vqM/s9qw8Pty2D/08Ofo/Ts8vI5pr3f84P09oHtNWtfPe 0Tx+V63b7wBtk/bRWIZ+nhz92zQHmmcHzS4aXOsSY57n1/p52u41z/O84eKlQPNcqo4GlU75ucxS 0742ndJgtQ80j/p5cvQfjJ/LTNXta9Mpb5RZ8zmdoW3aPhrL0M+To/9I8+yg2UWDa11izPP8Wj9P 273meZ43XLwUaJ5VWtZp2+mUn1VapbqlZ0qD1T7QPOrnydF/MH5uaFCmnbgpbzTtjVavZmibtI/H curnydF/pHl20OyiwbUuMeZ5fq2frXafeZ7nDRcvTWk+mWk1GC2LbB+T54mu66P+qhJVJP/9V/OW b61tI7CgVPtnTEzX4rCgXs48+Onh8PGraWYgefgl6Sj40P310FH9oSG7Ifjh5+RPR6L+nDz8djga jH1D1jaUrw26baheG3L7G10fXx768UeZ6zzNquz65rohu9bXN9eF0dc410WZR5pr4Vbn5cyD7YCa 4TTbs5kRqdQcJbUxPqbUlPaIKjqifGhQX9oGldpjhEG/NqivrNf03v5GaTdUbUOxgHalaB9frSVW n+2xAGG0j/QzpQMmtbJnDOjgo+0alF6ymECZPVyPXnVqzQiMRivrG5my1x8YAlYmo48A7fbo1L1F mAcdNh/C4HAhasrtwEM2y7wpAeFs+Mn+xhc6QfQtSCl/pH5F68thVxvnaODFwFQwXlhuu1McL38L cBmlVHM+5K+1F8KDMC6GwKk2c2cgDxxB7DkVTLLH4CgcqIK+FrCOvxbewiGWYwwsw/LhA0wjPgCk /BhCck0nuMXJXspM22t9ZrhU5yDXcTgEJuMWBSwMRVBV2itlNyCldqdahwRMcwLMDNgd4BCGR00q nCJuL4AmB/QDFLYfQTz40aaDrx3HJZgxez6y3GZM+xHgdiCdm0uCWRfYC3luPZJ9slg3gx2HvSeB 4UOnPaacGW0IPvWwbDiCABcuXznEKRvJs5QpIYm+WGePspLyCwqHlXIyETc6QGNSFeJhURmmQiSm PoVUbh9wSU07SR17LQKIGY4OFAb0wfEQph0UNTWpYEvuMpjOyT98g6M/5zqBVgYm42Y7KGFYF4FI LcdU7NTW/TPQtZwfrmhCgMmAQSReLIopLiM8EFLXJ8NVf7VhBs0u21QB5xiOjzMJQiLnCQ4r1CsF GsFD8dJ9Ohq3wPDgDaC4i98IuGOs1ElV6251RzY03bribo+7PvfitoZJhT6AMFg6LvB8tytwQQfd ulbZsHW15R1HA6vJ7Qzu7aF+qSBO6BDm/F54RjI6LlX8ZGcVQJD4fkMsrsC6l+zmuMvAfo3EeOVi KBBlGC7dVHno9nV0ajgPeyDUzQe1K7C7Ysr/peMzajo+rt89lLXAVtvL4SeVRA8fKoVIiX8LGELg y7dxx0PeIzqvrkJ1c38P+LKpfHiAKEfEbezw/Tszq2LBYTj1KqKkcjiMhdTZdHgeCMnjEpazBDfv bk6E5QYPVW4eViUMjsft8NHy1Qb+58dMUYJBgJW5+J/z1LzGqnbZcc2P8/MkwtLj+zz+cuFLW+io jxGwM8iRtbhYvzoObEaBBtR6jpk6B/vQoCxF2euB2r1AzsOVzFa/StmcUZ/hP3gxHFF24x1Z+Sqd Z3Pj/kaY7SW8hhqCWQVTAmpN2zPwxRZrbk7YlPV7sm0ikItWO9ZFOeW2c2GtAqzbxsWyla23PLxO 4HPwWAYeXbqKy2nmZBeitgShstfj2QoR1cmDPzy4DAhzHNNfaHL3mFIVruX2OOwEOQwhqcsPrq+Z qRAgBbFPUcx4GsciQV1KaRxwCxH1z9cFBkf31yupNuqB4REnHiu3zk5oud72iKcQ89ilIJxXFgq/ PU4NoKfypvc3wN1xwgvBCInI7pGTLW5QdjmUCcyHGzvI2OFSZEu1BW07QRAP+8lBaRisfy2JsM6O SxA4RI9nVddQuwkT7J75Oen7CpzjUWIrudaD4IFOyyn79+F4l3Zb1Va3NFIWd8fAAQIhWs7NmLIA UsWPxeARoBTWl2aBeQATWNQ8tgwo5Y4OPutczHioiWAPutK5eK8x9KnX/LP9XkhY+2zNctax4cjz mduTmPdxUWccu9xbhDIEx0zUduORYWEyIcQhahcuZ9bYQpP1lHjUAxjNG7ml8GCcoogkYlkQ5sIn aPlrPfLAkJl5J5QQFHiPnRhkcdrLzR3Z3oUzztFuJ+RqW1dJdAQvJEFPxGfqGQHPUE3sETq4PCDZ tTUNo3lyp+fOozAAn6EoxwVbeTuV1hHm7GpiBT3C7eipjOB02CMgn86HhKm4ZQ6EwRmU4IB9FXZY x8d6U1RMUQkS1taK6IRw9OXFuVzqMIzmMv4mVJS4hq1wOkrOH4/iWc5CAtMWl2H5JKOPWZAmJ0hf iZEliBqFF4QUJKe8q8g57tn2sOICBK/HMR8E8XlxUuJ7lK6qEwZTX/c1o/ReCybOGAc8UIrjlIDb eUJMiFTtVXLXb07abZ20+ZJOBdwdwkexzQGLdy3DIOCu0lM9eo/0VmCZICmgHplXqxxke6iIGDss iW8kRKFmbqfaGkJXlLt5QiREC2xT3wzrToY4xxckdMRArv0Go/eles45rWDa4SSck4pySRORgSHQ a+M4gLgUh005BWIwTdBWASHKbNNEUGV93VMLpZy7Co9ytnbxPXD1obGGVUMggw3yj4A0D/4NcTHH 1dVJfb+GJt+s0/r/6KvgoX2C3ZugoClPLsLF5aGsAk/d8pwdQeV1D5MIWIgmaAb0VVyKu0U5Bd44 ZnWIQydaAxxiTPMgcYq9atLatZoehWToYCDLcUZ7Q94rDX6AGQHmBYTk9xkIApc9sCvITUVcEQPu Bshrwor/3FwF/w70sY6jgbIQurO+BBQqM1R46xZmXD5BgDsbZXG+5aDbW0QBpf16IgpinJDhWASC GyBIP2Zgw5INlIv0SwGzgcYJYnqUs6L3420Fhzs/EAyj20r/kngb5WQG8u7DhghgN0aEgKQ6rcCC 4CexXA55TEWUmhbbHKJuZQ3FcOTsfqt3IVLlZTqFKh87jEq3pIrkTlxoGxWe9Ga8MJqpVi5CuOmK w+VHpuuE6iyX1ZWuKaaGaYjoccHlXZLr/tbxH8UokIszxh8RaFB+AxIP9hCkLHjEitM6F4F0yrF0 0ARkVjEqVjqIXx7IG+JKYUQdfggRMNgzU3VQY2adYEYP0BBcxRHiCmlwTAQo67NSiUcgDBYKlBu/ ZJc74bi9CBLCY6yQ626uTYv2vbo2PSy3AFu3rc7xeT1TXgrGN+ju0gvysmKqIbxTZ8NoJp1vayGs VEj16l2qNz+VW+tcceTTm726IW+00glaolzd4NEHcCyo5249Vr9zAK9lcEAJqGO4sOncNhi+AdIG spTZz/Rho/kS2vUMU4N26lqC36hgOt7Tp0oUyrbAdhO1HTWEJ8StVM00FhYv7TEAdyPPxvLNwF6S MnafDBDgzumGd80VQoCH28b36vZFlss2tXfCYlUVFKv2MkVRopYE4UOCrP3dStk13xbLjdwQ3M+L T1OXO+6Glh+w7VYsBadlHnZKUDis3/DNE/szBwX+1He+DPu9MyPKBQe7ZcsYFQHXmbGV7kwIuCfJ 1bAwcKZLq2R5uCi5/lyev+fh5YY+eBC8b057GGWYZydlCFnQkkIA3DkgODuj9gLegAL8DzlQy08o 8Die1syXpJrbpEtCqQRZolRAsIIFzZrEGkf28NEDQ634EHzqUa1g+UZQsHL8aE2SNhIiif7qKgIE gsN8ayUbZW8ocEDAabTjStZza4f368ZI15IUGlh+Lsr3tRs5sQUeCQ+tzHPz6EUOuC4CkVqOqdip rfvDnJNfz4TwuGEBlnNMcRnhgZC6GO52+mrDDJpdtqmyWYlsDis8IFvgX90m9yRSmdh+x1gOi/mu LoDDSeWOXlg6LvB8tys4gAm7dR1uEOa19HA1l5/rxKmivkpA2m54RjK6ADXR1wEEQWx5kMXd7fGi xHjlYigQ5eUZbR66fR2dGiI3/T4g6hbD1b0Suyum/F86PqOm47vms/AQeocHOnAfKoVIiX+LX07B ffkQo8XlfaNylrtR3dzfA75sfpTFQZQj4tXchrayM7NYcKm4R0o3v8ptpUvklcmmw/NASJ6zFCPU 5eZEWG7wUOXmYVXC4HhACR8tX23gf37MFCUaIsT17m84/aZ4dRzESL/x+AZPvynneetMsg1PlIH8 FMhg2U0aEN/U9OpoTBnPA+KpCvQRNdpMrZ7C02WmGjWUfwsQ0TpzSgcROIJ4PADH3aYacGDf6B4y MA10vVgnedSt5TU1l1fhihNetXzTEj0a2QcCFEKAytKkEeQ8TZ6Hz+pOHa+JVqpuP5i6bc2SYwH1 7tNjA3fmrqqLXKfDL830YdP32373+FlX7RPJ9FFdnfptPh2/O37p8ZdZOnl4oPfx8Ovh0w+xAE7p 1glj8lOC7H5hI2qS4jnjlhvZ3DFNBScvbcEBIKlDSUFRvEpBYeakoChP3Np8sqWg/aWZPmz6fgcp KPScFBR66FeDFBx/2ROlJ1LQ9ruGFBT19UnBu8zTuyU3+CvPjYL5dxKZH3D4AZC3HNkf5az9UQ72 R4n2RznYH+XU/ihH9oeZtT/MYH8YtD/MYH+Yqf1RrmV/lFaBjls2gqtTjoDyOPEAHF6NbItq1rao BtuiQtuiGmyLampbVCPbopq1LarBtqjQtqgG26Ka2hbVWrZFdbItbtFTbHA7i546I2qCqxxXKly/ l3ijs3cOXQQ1ZUPp8/A5n4GaUhU9JBw/WVDT/dJMHzZ9vyeoKZWagZqmdehX2VDT/rInSo2hput3 BagpVXlar+vZxrztzbzkwNQ3HMQ6Mirq/gdlyvqdx1GQu7OWE42DEbVq/ebpcGCcd1MGZcdGTnDl KC08DnfKbM1plxOBhsxuyLPXSWv+JC/NeJVpCe//enyWnjN8S74d/g9B/PTIZW5kc3RyZWFtCmVu ZG9iago3MTcgMCBvYmoKNDAxMAplbmRvYmoKNzIwIDAgb2JqCjw8Ci9UeXBlIC9QYWdlCi9QYXJl bnQgMiAwIFIKL0NvbnRlbnRzIDcyMSAwIFIKL1Jlc291cmNlcyA3MjMgMCBSCi9Bbm5vdHMgNzI0 IDAgUgovTWVkaWFCb3ggWzAgMCA1OTUgODQyXQo+PgplbmRvYmoKNzIzIDAgb2JqCjw8Ci9Db2xv clNwYWNlIDw8Ci9QQ1NwIDQgMCBSCi9DU3AgL0RldmljZVJHQgovQ1NwZyAvRGV2aWNlR3JheQo+ PgovRXh0R1N0YXRlIDw8Ci9HU2EgMyAwIFIKPj4KL1BhdHRlcm4gPDwKPj4KL0ZvbnQgPDwKL0Yx MCAxMCAwIFIKPj4KL1hPYmplY3QgPDwKPj4KPj4KZW5kb2JqCjcyNCAwIG9iagpbIF0KZW5kb2Jq CjcyMSAwIG9iago8PAovTGVuZ3RoIDcyMiAwIFIKL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3Ry ZWFtCnic7V1Lj9y4Eb73r+jzAh7zWSSBIAfbuwFyCGDYQA5BDsEskmARL2LsIX8/FEWWVKya0djT w+nG0sbu0KxmqSTV4yu25tPbP336x/lfv53fvv/03/N9/fn+00ndKZ/WP2eV/77ZT5h4Z41a/pyj tncQyuz9l9PX89fTx9PH/P+vJw1lYf2Rhe0Qqvz97f7X09v14Kd15tP7v+TR/87m/Of83y/nv/09 T/5c9S0f+HKKCbIdSmmb//mf/T+1VVHfQR7nedX/c/nwv09//eH862KYuYvFeL0auP/nG2+00ZCV hmeY/JRlmi/TRp2dCibmM23jdKeV82et1wGkZdZmq3Wso/uTzgbH5J1VKAS6GKre8tkyXlec6VID TW8eLZ/dH3QRVqPaYrT3Pl/ddz88flG+PnJZ3n0+vf1JL7ft/Pmf5/W+vFl/fM7Xwurzm+XMzPnz z+c/5Dv10x/Pn385xUVcJtT7fuLHMuEf/oS2ZaJ4Uv2I7ZXEXgn7BDuMKxNumwj9cVel4WHLjOmP wg7bH0WvR9mdy4f+sB+ODsvP9qdDpbqbsLY/fXY92FGYUt9b2p8+Oyw/CrsvvQ7LTr+/Ufyw7M6t Ez9+zjnqeSHv7BbyzkkhXyZiHfUhv8X4thiqXgx5p6WQdxr1ahbyi7AapUnIF70jQt6FFhRQrnXa Lj6LEhbhvZt8T2CxsDmMAe7hzBmZjj58eTwfZp7j0DPvOqWGpVHdna3xl/JwvytqXixqgEUNeFED LGqeFjW/K2peLGoei5rnRc1jUfO0qPlRRQ1aUbPvOg/X7w4zEvPOPmVr03sF+8SQwsADK/WfOK5Y rJQel/Dj6LSqm2Bp3upvDjX3oVvCJp5QGFm2YreOFaSrvcr8CvX5q05cINVE2FJNDFKqibGlhBhZ qilCoIuh6sVUE52UaqJDvY6lmoi5BRejvWNSTcL7dTv4mbvWdxjyBFh6CBhZsPH0fJgFecD2R3FB xpi79PT+0A57oUiKuSX+gmMjRFJUtnr8MuoiaRUCXQxVL0ZSSlIkpdQiadlY6CJpERpFFqO9QyIp Kn97kTQ70W7iuAM8Lsm9Hfw2sKKtXgVv3VhHHPVWxKOWinjUrYgvoz716FbEd4uh6m2pJ2qpiOdZ 1MuKeBFWo0gRX/WOSD0Gg3N2xI+H3nV3xNHuiqsVi6vF4mp5cbVYXC0trnYrrtFIxTXPNr2GFdci NIosRnvHeLhtxXV2xK/Sq82OeMRVHtgRR5+2VANKSjXQtoGXUZ9qihDoYqh6MdX4IKUaH5rePOpT zSKsBgaSaoreEakG7O3h+OvpiFkosSx4rIMFW3+FeEfMYOkDmPsCgRPcFjjBS4ET2u7yMuoDpwiB LoaqFwMnGClwgkG9hgXOIqxGGRI4Re+IwAnx9gJnNsDdxGyA6RW7XAO8HcXow9swvxEXMm/cQZYk QpaEkCVxyJIQsiQKWeIOskQRskSELJFDloiQJVLIEkdBltQgy+z/DzLPdff/SW3YIikJWyTVsMUy 6jx8FQJdDFVv8/CkJGyRZ1EvwxZFWI0i2GLVO8DDk2rYYvb/Ryc3+//u1s3+X0o11mypxlop1di2 6b2M+lRThEAXQ9WLqcYqKdXgk6qpPqlKDqpabsHFaO+YVGOh3a/baWMG9f/8++7jwv9i30QnFzYP dlHyYNc2tZdR78FFCHQxVL3owc5LHowPXqb64CU5qG8ui4vR3jEe7PXtefBsxLuJ2YjTK/ZKjfi8 DY9f0xd54mnoBkmpRM9PugBPvoi/802ll/ShC8CKsIMVQYQVAWFF4LAiIKwIFFaEHawIIqwICCsC hxUBYUWgsCKMghWxwYq5y3SQz698lyntWr8ktn4JW7/EW7+ErV+irV/atX5JbP0Stn6Jt34JW79E W780qvVLLYfPXaajk5u7TN2tm7tMPNVoZVRLNXmsearJs3XjuYxoqqlCoIuh6q2pRudLz1PNMtv0 1kdB9wddhEaRxWjviFSTD+Ta/bqdHv21dpm47cdp8UJwUCvrNw+2IHmwDc3TbGAeXIRAF0PVix5s reTB7VHPMuo9eBFWoyzx4KJ3hAfbdHsePHeZuom5vUGv2NxluobbcNU7BFr5HajxIqjxCGo8BzUe QY2noMbvQI0TQY1DUOM4qHEIahwFNX4UqPEN1MwdgoNYvOodAq1gB3pABD2AoAc46AEEPUBBD+xA D4igBxD0AAc9gKAHKOiBUaAHGuiZOwRHJzd3CLpbN3cIpFST7JZqkkBzlGd9SwmppzmqQqCLoerF VJMEmqNlFvX2NEersBqlSapJY2iO8oEazdEN9VejdgiO6zwLpUuhP62QtSiPBdYirXXd5S6jzmFX IdDFUPU2h811RnBY3Z79LKPOYYuwGrVnLap6Bzis1pOK7yF/nRsCj5v+u+xEdy51M9/dX9MvhOSE s2EHbSTsoE3DDsuoT8UGc68h2GHRi6nYSNghz6Jehh2KsBpFsMOqd0QqNpMi8YkV4bobcW13YMOK YMMh2HAcbDgEG5aCDbsDG1YEGxbBhuVgwyLYsBRs2FFgw02KxKciidmId7duNuJSqgHYUg0I7Ep5 tu0+L6M+1UBsuQUCSTUAW6oBgV1pmUW9PbvSKqxGOZJqYAy7ktYB79ft9DWjCCGOLTus4uwTjN3h oWb+MZjO4vO4B2F147sT+AWiMeotGqPABJVn2075MuqjMdoWftGQaIx6i8YgMEEts01v6JmgVqFR ZDHaOyYa46RZfCjm5y7DQYTPXYaD+3IluwzX/f2/TjuklESklBApJY6UEiKlRJFS2iGlJCKlhEgp caSUMBknipTSIKRkFLra3HZ4PDdd97aD0Rv6MFpCH0Y39LGMOg9fhUAXQ9XbPNwoCX3k2aZXMfRR hEaRxWjvGA/Xk4fyqdBibjt0t25uO0ipxqYt1TiB1CnPtr1243pSpyoEuhiqXkw1ViB1WmabXtuT Oq3CamAgqcaOIXXK5zN5KB+MviHbDuNIJbXxbosCLxA/5dm2H298T/xUhUAXQ9WLUeAF4qdlFvX2 xE+rsBplSBT4McRP+UCTVPKhWJvt/uOmz3b/6L7Mdv8puRl2CCWICCUgQgkcoQREKIEiFNghFBAR Cj5kbYAjFECEAhShwCiEEibt5BNLxJW3+3GHPqKIPiKij8jRR0T0ESn6iDv0EUX0ERF9RI4+IqKP SNFHHIU+4qSdfCq0mO1+d+tmuy+kGquReySPBe6RPNv2uK3uuUeqEOhiqHpbqrFa4B5ZZlFvzz2y CqtRe+6RqndAqrF60k4+WBtZsB1fgEOnv6a3KmprwhYWRiCdyrNtY9yannSqCoEuhqoXw8IIpFPL LOrtSadWYTXKk7AwY0intLWTy/Kh4Lud/v9K+syrenjdul0ldGIldFgJHa+EDiuho5XQ7SqhEysh PjJsHa+EDiuho5XQjaqErlXC2VYeZJ7rbiut3xU1LxY1j0XN86Lmsah5WtT8rqh5sah5LGqeFzWP Rc3TouZHFTVoRW22la/S8My2csRVHtlWxo2wwkaJsMK2V/iUUZ9qYiOs2C2GqhdTTZQIKyw+hmsj I6wowmoUIaxY9Y5INfEGWbpGfYvMtPZxwQPl+KuLfuK4z3wmdfWzAsepjcvIKYnLyLU3A5VRFzir EOhiqHoxcJLEZWTxGUmbGJdRERpFFqO9QwLHqRskaJyN50GEzy+eu2w1v3h+qetxgdysN1DjtARq nG6gZhn1uVk3ULNbDFVvy805wQq52eHTvU4zUFOE1SgCala9I3KzbqBm7hAc5Kbr3iFYvA093Iro wyL6sBx9WEQflqIPu6EPZyT0kWebXsPQRxEaRRajvWM83Db0MXcIjk5u7hB0t27uEEipxm9MGs5L TBoO2rb4MupTDTQmjd1iqHox1XiJScPhk7vOMyaNIqxGESaNVe+IVAM3SNs1aofgJXDqVX3x7MJG oeSCRKHk2luJyqgPi4BxEAiF0qIXwyJIFEoOH5p0gVEoFWE1ilAorXpHhEW4QfrF2f93E7P/f9wd Zv//YtfjArk57iBLFCFLQsiSOGRJCFkihSxxB1miCFnwcV8XOWSJCFkihSxxFGRJDbLM/v8gN113 /+/Vhj68ktCHVw19LKPOw1ch0MVQ9TYP90pCH3kW9TL0UYTVKII+Vr0DPNyrhj5m/390crP/727d 7P+lVGM3SgtvJUoLj+/b8pZRWqxCoIuh6sVUYyRKC49P7nrDKC2K0CiyGO0dk2rsDRJqvdbvmdse lvJszLLgt6NQvkPAYvxS3/97t3EZeSdxGXl855B3jMtoFQJdDFUvhoWTuIw8Pt3qHeMyKsJqFOEy WvWOCAuvbi8sZv/fTcz+/3F3mP3/i12PC+Rm2EEWECELvi3LA4csgJAFKGSBHWTxImTB57K955DF I2TxFLLAKMgCDbLM/v8gN115/x926COI6CMg+ggcfQREH4Gij7BDH0FEHwHRR+DoI6BLB4o+wij0 EfEGzv7/4ORm/9/dutn/C6kG1MZxAUriuAB8vRYoxnGxCoEuhqq3pRpQEscF4APUoBjHRRFWowjH xap3QKoBdYMMW6P6/+N+6tD2Z5h6Aa/XG3cRGIm7CPBNRmAYd9EqBLoYql70ei1xFwE+mgqacRcV YTWQcBetekd4vblBdsXZ3h8Vx/l75RrsrtBZsdDhq53A8kJnsdBZWujsrtBZsdDhs7pgeaGzWOgs LXR2VKGzrdDNrvEg81x31whuV9S8WNQ8FjXPi5rHouZpUXO7oubEouawqDle1BwWNUeLmhtV1Hwr arNrfJV+ZnaNI67yyK4xbBQWECQKC8DXJUFgFBarEOhiqHox1QSJwgLwsVsIjMKiCKtRhMJi1Tsi 1cQb5GUa9XZylmvZYQ5/a1y7HqIcfg1V4/MCTp82ZiJIEjMR4HtoIDFmolUIdDFUvej0SWImAnye ERJjJirCahRhJlr1jnD6dIMcfbNpPKqNs2nUQW11LiipzgV8MU9QrM6tQqCLoeptIR+UVOcCPuAZ FKtzRViNInVu1Tsg5INudW42jQeZ57qbxmC2ohaMVNSCaUVtGfUeblpR2y2Gqhc93EhFLc+iXlbU irAaRYraqneEh5tW1GbT+CrtzGwaR1zlb2sa89/z1xxbOayXaKk/7r88KQcJUfrx/PH0f9iBBDxl bmRzdHJlYW0KZW5kb2JqCjcyMiAwIG9iagozODcxCmVuZG9iago3MjYgMCBvYmoKWzQxIC9YWVog NDcuNTE5OTk5OSAgCjEwMS4zNTk5OTkgIDBdCmVuZG9iago3MjcgMCBvYmoKWzQxIC9YWVogNDcu NTE5OTk5OSAgCjc1OCAgMF0KZW5kb2JqCjcyOCAwIG9iagpbNDEgL1hZWiA0Ny41MTk5OTk5ICAK NDc5LjU5OTk5OSAgMF0KZW5kb2JqCjcyOSAwIG9iagpbNDEgL1hZWiA0Ny41MTk5OTk5ICAKMjk4 LjE1OTk5OSAgMF0KZW5kb2JqCjczMCAwIG9iagpbNDEgL1hZWiA0Ny41MTk5OTk5ICAKMTMxLjEx OTk5OSAgMF0KZW5kb2JqCjczMSAwIG9iagpbNDEgL1hZWiA0Ny41MTk5OTk5ICAKNzI4LjIzOTk5 OSAgMF0KZW5kb2JqCjczMiAwIG9iagpbNDEgL1hZWiA0Ny41MTk5OTk5ICAKNDQ4Ljg3OTk5OSAg MF0KZW5kb2JqCjczMyAwIG9iagpbNDEgL1hZWiA0Ny41MTk5OTk5ICAKMjY4LjM5OTk5OSAgMF0K ZW5kb2JqCjczNCAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzUy Mi43MjAwMDAgIDcyNC4zOTk5OTkgIDU0My44NDAwMDAgIDczMi4wNzk5OTkgXQovQm9yZGVyIFsw IDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGly IzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjN0b2MKPj4KZW5kb2JqCjcz NSAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzE4Mi44Nzk5OTkg IDY1OC4xNTk5OTkgIDI0MS40Mzk5OTkgIDY2OC43MTk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rl c3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQj MmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjNSRkM1MjI2Cj4+CmVuZG9iago3MzYgMCBv YmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFs1MjIuNzIwMDAwICA0NDUu MDM5OTk5ICA1NDMuODQwMDAwICA0NTIuNzE5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0IC9m aWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0 ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzdG9jCj4+CmVuZG9iago3MzcgMCBvYmoKPDwKL1R5 cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFs1MjIuNzIwMDAwICAyNjQuNTU5OTk5ICA1 NDMuODQwMDAwICAyNzIuMjM5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJm IzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRo IzJkdjIuaHRtbC5odG1sIzIzdG9jCj4+CmVuZG9iago3MzggMCBvYmoKPDwKL1R5cGUgL0Fubm90 Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFs1MjIuNzIwMDAwICA5Ny41MTk5OTk5ICA1NDMuODQwMDAw ICAxMDUuMTk5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFy IzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRt bC5odG1sIzIzdG9jCj4+CmVuZG9iago3MjUgMCBvYmoKPDwKL1R5cGUgL1BhZ2UKL1BhcmVudCAy IDAgUgovQ29udGVudHMgNzM5IDAgUgovUmVzb3VyY2VzIDc0MSAwIFIKL0Fubm90cyA3NDIgMCBS Ci9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCj4+CmVuZG9iago3NDEgMCBvYmoKPDwKL0NvbG9yU3Bh Y2UgPDwKL1BDU3AgNCAwIFIKL0NTcCAvRGV2aWNlUkdCCi9DU3BnIC9EZXZpY2VHcmF5Cj4+Ci9F eHRHU3RhdGUgPDwKL0dTYSAzIDAgUgo+PgovUGF0dGVybiA8PAo+PgovRm9udCA8PAovRjYgNiAw IFIKL0YxMCAxMCAwIFIKL0Y5IDkgMCBSCj4+Ci9YT2JqZWN0IDw8Cj4+Cj4+CmVuZG9iago3NDIg MCBvYmoKWyA3MzQgMCBSIDczNSAwIFIgNzM2IDAgUiA3MzcgMCBSIDczOCAwIFIgXQplbmRvYmoK NzM5IDAgb2JqCjw8Ci9MZW5ndGggNzQwIDAgUgovRmlsdGVyIC9GbGF0ZURlY29kZQo+PgpzdHJl YW0KeJztXUuP3LgRvvev0NmA2+JTJBAE8IztADkEMGwgh0UOwWw2i8XMIpM95O+HerbET+yi2JRa Pe4Z7FrDbpWKZNVXxWKx9OEv3/5Z/PuP4sPjt/8UT92/j98O5bFUtv0pSvf7ftzAzVHwsv4pDBNH XTWtTy+H1+L18PXw1f3/9cB0c2P3j/uwf0TZ/P7x9PvhQ/vwQ9vy7fFv7up/BS/+6v77rfjpH67x 545e/YWXg7Ha8VGWTLg/n8d/MlFKcXRMMdde+n/WX/718Pd3xe81Y/xoGuZZy+D4z/dKSG6roy6r i1h+Pd3qaAnLmdImeD0mLETHj3SclU0fHGcvByGVu8P9KNfO9LHl2I2BZvIo3TX323nVDAAf03kO 0K+H55cRz1Z0P8HrCc9j3pxwmJ7n8bMka74DvE3aR30Z6DwH6Ps8ZxrnAM8hHkLzssY4z8/1y7Q9 apznZSMkS5nGWRlpGx7MVJ6V46d+rGuf8OC1DzyP6DwH6GeTZ2Uq1YyPmcqGMsY04wO8TdpHfRno PAforzTOAZ5DPITmZY1xnp/rl2l71DjPy0ZIljKNszFV2ZAXU3l2rLW2R0x58NoHnkd0ngP0s8mz cTazM5kT2TC2bDANeJu2j/oy0HkO0F9pnAM8h3gIzcsa4zw/1xN5jhznedkIyVIuO8i0bJTK9zeY dn6WQRsxbT/ZlBOd5wD9fP4G05Wo//BtN9NGN3wCb+P2cV96Os8B+iuNc4DnEA+heVljnOfn+sVr jxnnedkIydKU537ZYcEJX+TLaykLyYys3PKlYKr477/cU742vnrCioA1v2Nm2pbAiuD1zI0P3w8f vuiClcX3X4qWg/ftP99brt87tpUpvv9c/Klm6s/F998O9QKoa+BNQ3VqEE2DOTVI/xstjc/fu/6v M9acuy7d3lhzx/ftjbWU+hbHWqrq9sZaa3GLY60rudJYx4RJGHbIrT0dIleqjuz01+zISlmbNttc aNu01vbBdFdPB2crjsYqKcrhQz29WXd0m+/W187m1HcU01ul6em6q/q744fWH/JycvPA75MzUQ/v zgeBXs8MSzNdrA5Tzc0XE6zG/Er188W++LPx6Dd8bhpU+BusnVEmzsyx8YnAN+AxrVjI02MYxWoE I0J4VOExyIhPg/Hltxhfxrn3DVn534Ah++QTVZRqsWyapNVJk7Se0yRd9RLvrnxNaj7U05t1R3fQ JC3mNMkhYk9XgCbVH3ZMiYkmNXS30CTHx81pUlmR4ulzxn15DcH4SF8r3xSAAH+iHou9/UIS9WEi QuXzqdqZ8aBRQkD3/YmKABa/L5zdSvehL+zBJ0pONo6HyAWBZuRMmFlnwgzOhEFnwgzOhJk6E2bk TFSzzkQ1OBMVOhPV4ExUU2fCbOVMmN6Z4LoZaxu2coh4/gSmAA3ACCkmKPIgnUDDhzPENxKJaSji Dx5RDmaFeb3lKpeE25GRt7NG3g5G3qKRt4ORt1Mjb0dG3s4aeTsYeYtG3g5G3k6NvN3KyNveyIsH T8IRogDVQDp9E4b+JHxjE0OJimVJ/AXGwLWgXRpaO0XpNQDMC7ZY1eQn7xZoiLCUgFYwdWCQdjvK OEI+fnUNU6g5tvka7id4PQGiiO/TirzwoY2a2zquMqPlXDdx0MGT78zYyCb5DeVHH7Y/Ut9AWYIG Nm89bXhOkUZrCxg/tbS8M+YLjz0jCPBgeE4Wqo9+Qyvn2jeggIwjqS4jLbsMP5bBwPvdFd2wluF7 mO/7cKAK3fU5Q0ZIFeUGJgIUH9ZyJGfYO7A3tCj6NMCzQz5IohHd5YIcZtp4+oLY8R7tY2X1QhSv 8cmWQQ8wixWiF19vyLNJWEfj0sW3CrggoKeBXO3QMxfhlETbjRPAlbCWg1gE/Vx4DB3goIn6s41L Nxj2cidCBtEK3/WjIx7YueV+3XVDMedGzGe9g+olqJTQW4w50IpLBhCA9c4lbGzIxcaAD5v2vp6i TMH6AmQ7h/QDPAIa/thiiLaQBrKEwD3Nh/SBnRYHGthz2KC7cdiFcaC3rfYCufTOFwwyYOE26vGY Efql6Kj+WMFILqnORWyfAR8ZJKYLTl44ubyy3uz6EU1aU3HucmwWw6jS5hJ0CICKVjvgFGYGNiUT YAjAHyQEHgucQl9o54C0SqggpBxG69SlMFTKqaTmMP4Ye4dtrk/euPNWMEdrVoxXt8PKzizJ6QQL 1CqI7ZJexzh+dLEBGBJ2Z6L+oKyA3nSQgt6SpVM9llvziDyFBC9rDb8UVJFGEbSZ9GOhtyCHCQO0 /LERiXkohjQROtQL6h0RG/PHHUSXXrfSNpOGYti0F76tSrERAEzQ/cCm04WwI1Xp4c5nmBqQPNKe o9KQI5AjlSlCvelED7q3q6z+Y8Esj5mpRM4RulKcfzmIolzSka2END3aaVzuI6aIEO2ZA2MQhErY CNlEHFLwYrl/cHuG6lJ7UFZTgNjG3CUkAcW4KqDdELenLYbfuwhl9oU3whzuZGMjo6rmMVTGEI85 Z4aWbwZE7NkuF6EEB5lO2qcnBjdYyPBfgjscMYQ063T3wS7BZCdsUP+IeRIXqqXQ5VQv6Zh6hEcJ EwFJebTGrOLKJOR0gMbk2xrmrg89+pMR873bh4uM3yqnaSIceXQx6F1bGu0SpJ3cG07ZHUxYYN/D w5Sxj4iwvqVQ7zrRkets9tAnmjq0zwPuoi8gEXHoCUQmyykBelG95hb6IhOxxjotJU6zfOWe4u36 FkIYUrpBhkhNhUU4sg5nI2Bu4RukSEnpS2GObICEJODrINcN58FFnL6GW2Bjnz4nj6pNns4EmcLw 0Tr7KcqWUyxPOIkmuO/doOAFUCaPIZI6+BjSIwTl5f6Mw0li9tEHAD/miP4enKXFgxOQ9g6sRcgv fRyDhvcctU2ybCFncNbfuK9Kr/dBAcBWQ7iDzktMWAAC0QzFRGYml046TQgZ0kShu8vLAER4VSBC 5Lmg/QTiVCWnWH3d3O88hkf3VpMulQAJsrIEq5m8njtn38Dw+OZsxnzDeSvyBDF0D6QXj1wmnDfL kA+zVekuAN4MRwrA84jwV8FvBhrbBCtIETp7wv9iVTVD2Yx2YsbHdhOAZ7lJyJL+95aTiO8ZEiTv t5PbsMYuG/YlQXEzHDq4VopFbDTnUsBkbIqYtO+OfgmddbANHO58UzGLbWOljB6QK5X1y7RDACsi gN01chUSVvsbFWdKyO4gbVuWkw2bbMReyxtaI5Kz+6XepXmaVTmFqhg/jNTuiGxwWquuE0OjUQaU mc71joiyxQpeHsvEbIgR2nXF7tLbrtuk+yzX1Yi1DZ2Hl8ExzZENH5GXBjhMOwhk9HOd+NFycYgo ggQjRt+SYEFJmIpIGEk4ghGRtU5WaM5kU6TxQGYTp2KjzfzlKcV0Qjnu3dM51/QuRMaEUSb7F6Xk cWa2SYiMAA1wEBJOdiTMNwQm6L7spUIVMAYTBcYNvJ+EIBztL9Jv3KDXtvfQps/7XkObEZ5bhqXb tTby6XJsdD5YbOLehQZCczW1ENFHgfNYJs2v6yGkINMqmcs7D6ne41Rhq3PDqU8jJ/ONVXvnXPTQ skq1d5oGSiyY53Y+Nq91vU1Jdax2D9oGugQFw7u8UbmEdzEj1GCd2pbslbx1K3t6ODhPZrHfcOb3 qllAF/oXrGxnovLefbvHJN4rBUeWryf2cjZk9wcKLvXKW9m1A4rcX7s1fUrgtVt5MEOUPWbAqYWU 2mm0IiYsdcnqElhbGOwMpCwuX1Bg9Iws2ZlyNMRnPWXnIyGrmz60DIfWkl/uVoWJ0p5lDjmNOF20 PO0rYebolXBKlleOQy83d4InExxyERSibZxZWNgu3yuNyL6lC/aQLnPEGhBfw7JGdmXKwaDlYQw6 eHYlhzFC6hKsMp1KS9aRxXlJUKnlmIpEfdufJ6x1OwNCb/MnYDmNKSEnPBNSi95xFV98mEG3y3dV rlZbj4YVOn9i+dnJK6WKrVQZql0xCvVjvjliNy9YTX+NbSYE0MPSlQ48wmzSfgZ9RCFH+cVN9o92 IzMpvctQTHEbQEhIBcmyOZghup3iZtIKk6B0y1NFI6zwNtYvx6EPsmBnirOTUekyIbcRoYFPKIyV 4g8tf/NcSl1YGtvpOrl0nJKEoZQYEl05lo6Xw54DralXKvGyG/NIx1QgXkznrNDwR2PZzbzwYJt0 m4gDC/SLFwLikAlj7VCvmMY2OgFvjVMO9yX2cieDNEsRnhx0ji4jQveWnm0Qd3oTZpXsgRxvTXzD uWTytKxeI5esDIzlolyyal62zmSO0VlfkGwF6Vi7yWmjFxKd9RlzRie10Ukz5C1s9GrYzfPR2jRr aYfDXBmyoGb2sCA/JeHFzqRb96bfFg2JAnt5W/R+Mxh9Uc6RwXilNyoA68IudiYiJpuu7LO8FsA6 WWPL14kJJ4gjXKeFucQMsZvxspBccVG8DNfyyEqpCsZsc6Ft01o3mO7qydkpfTRWSVEOH+rpzbqj 23y3uWbNHYV3Kxvosua7k4e6Dzum+psHfp8Ovx4e3q1lmZhoCiIpXkWr3j1Vel48zy1saGUMrKcy yLwwJ5kXdk7mZdnLprvyZb75UE9v1h3dQeaFnpN5oXu67sqX+frDjik9kfmG7hYyL72jKffE3hBR WsLTUy4zSLgaobqaRXU1oLpCVFeDSKspqqsRqqtZVFcDqitEdTWgupqiutoK1VWP6vdEBKpzO0tE OHcOY/lbDDYq2baXrfuz1XYvgxrDTlBj+BzUGNFDghEANc2Henqz7ugOUFPZOaipbE/XXflQU3/I y8nNA7/bQI1RdwdyPQeS3sGlCxONi59dpgRWn5TAVnNKYE0vrNaAEjQf6unNuqM7KIGVc0pg5UBX ghLYQeqHmwd+N1ECXQ6+zd2jvGWPUrMTzGs2B/Oa9TBfX3kS3n6opzfrjm4v4bqcg3nX2tMtAeab D3k5uXngdxsJZz3M3z3Ku0d59yjf5D6rPvlyCfusoI/Ld1GxZgX3G6K3x/ippeV9vPNY+WQDUn2m voaAbbjufZAJcfURmAaC5BBGP7NrijRo3mFDFxv85+I3drYZfc0t32p4SXjElm8CYF4nnfxaOXcJ 1TUSCvzmePH8Nun1G2UA0GU+lm8c5qjVHzHKdFo/udrZbV250LnnLCUBKylDMhVxejRhh5uGg4ST wJtMf/rm3iJRvs7BgIggxCon56UPZDleoLhGbY2U40g0H/S6hwzKvCUcxwIG8BRYZZAlDm5ngCKq s9DH1dbJ6e+shQqWqU8IsqdUEshRUJysaLBmWH7ljYuUMU3whG5Gg1IKz6QUGqKrWZHFmuiKEAkp dddyYhMOt9OVvldxFujoyduLgHvhTGW7HzAK/mcRYcowscbC6ICB4WVtYZiV/cFc2bIKdXRHy2AW eFfG+GyyH9gDIYIG7jfIUXzJ/Ravrr9MN4x3/zy9pAaevhZfD/8HgWS6yWVuZHN0cmVhbQplbmRv YmoKNzQwIDAgb2JqCjQwODcKZW5kb2JqCjc0NCAwIG9iagpbNDIgL1hZWiA1MC4zOTk5OTk5ICAK OTEuNzU5OTk5OSAgMF0KZW5kb2JqCjc0NSAwIG9iagpbNDIgL1hZWiA0Ny41MTk5OTk5ICAKMjgz Ljc1OTk5OSAgMF0KZW5kb2JqCjc0NiAwIG9iagpbNDIgL1hZWiA0Ny41MTk5OTk5ICAKNTk0Ljc5 OTk5OSAgMF0KZW5kb2JqCjc0NyAwIG9iagpbNDIgL1hZWiA1MC4zOTk5OTk5ICAKMjAzLjExOTk5 OSAgMF0KZW5kb2JqCjc0OCAwIG9iagpbNDIgL1hZWiA0Ny41MTk5OTk5ICAKMzA5LjY3OTk5OSAg MF0KZW5kb2JqCjc0OSAwIG9iagpbNDIgL1hZWiA1MC4zOTk5OTk5ICAKMTkwLjYzOTk5OSAgMF0K ZW5kb2JqCjc1MCAwIG9iagpbNDIgL1hZWiA0Ny41MTk5OTk5ICAKMjUzLjAzOTk5OSAgMF0KZW5k b2JqCjc1MSAwIG9iagpbNDIgL1hZWiA1MC4zOTk5OTk5ICAKMTQ3LjQzOTk5OSAgMF0KZW5kb2Jq Cjc1MiAwIG9iagpbNDIgL1hZWiA1MC4zOTk5OTk5ICAKMjI0LjIzOTk5OSAgMF0KZW5kb2JqCjc1 MyAwIG9iagpbNDIgL1hZWiA0Ny41MTk5OTk5ICAKNjI0LjU1OTk5OSAgMF0KZW5kb2JqCjc1NCAw IG9iagpbNDIgL1hZWiA1MC4zOTk5OTk5ICAKMTY4LjU1OTk5OSAgMF0KZW5kb2JqCjc1NSAwIG9i agpbNDIgL1hZWiA1MC4zOTk5OTk5ICAKMTEzLjgzOTk5OSAgMF0KZW5kb2JqCjc1NiAwIG9iagpb NDIgL1hZWiA1MC4zOTk5OTk5ICAKMTM0Ljk1OTk5OSAgMF0KZW5kb2JqCjc1NyAwIG9iagpbNDIg L1hZWiA1MC4zOTk5OTk5ICAKODAuMjM5OTk5OSAgMF0KZW5kb2JqCjc1OCAwIG9iagpbNDIgL1hZ WiA1MC4zOTk5OTk5ICAKNTguMTU5OTk5OSAgMF0KZW5kb2JqCjc1OSAwIG9iagpbNDIgL1hZWiA1 MC4zOTk5OTk5ICAKMzcuMDM5OTk5OSAgMF0KZW5kb2JqCjc2MCAwIG9iago8PAovVHlwZSAvQW5u b3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzExNy41OTk5OTkgIDgwMy4xMjAwMDAgIDE3Ni4xNTk5 OTkgIDgxMy42Nzk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2 YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5o dG1sLmh0bWwjMjNSRkM1MjI2Cj4+CmVuZG9iago3NjEgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9T dWJ0eXBlIC9MaW5rCi9SZWN0IFs1MjIuNzIwMDAwICA1OTAuOTU5OTk5ICA1NDMuODQwMDAwICA1 OTguNjM5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJm dG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5o dG1sIzIzdG9jCj4+CmVuZG9iago3NjIgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9M aW5rCi9SZWN0IFszMTIuNDgwMDAwICA0OTkuNzU5OTk5ICAzOTYuOTYwMDAwICA1MTAuMzE5OTk5 IF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJ dGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzY29k ZSMyZGF1dGh6IzJkZXJyb3IKPj4KZW5kb2JqCjc2MyAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1 YnR5cGUgL0xpbmsKL1JlY3QgWzE2MS43NTk5OTkgIDQ4OC4yMzk5OTkgIDI0Ni4yMzk5OTkgIDQ5 OC43OTk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0 bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0 bWwjMjNpbXBsaWNpdCMyZGF1dGh6IzJkZXJyb3IKPj4KZW5kb2JqCjc2NCAwIG9iago8PAovVHlw ZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzM2Ni4yNDAwMDAgIDQ4OC4yMzk5OTkgIDQy OC42Mzk5OTkgIDQ5OC43OTk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYj MmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgj MmR2Mi5odG1sLmh0bWwjMjN0b2tlbiMyZGVycm9ycwo+PgplbmRvYmoKNzY1IDAgb2JqCjw8Ci9U eXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbMjI1LjEyMDAwMCAgNDc2LjcxOTk5OSAg Mjg3LjUxOTk5OSAgNDg3LjI3OTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMy ZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0 aCMyZHYyLmh0bWwuaHRtbCMyM3Jlc291cmNlIzJkZXJyb3JzCj4+CmVuZG9iago3NjYgMCBvYmoK PDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFs1MjIuNzIwMDAwICAzMDUuODM5 OTk5ICA1NDMuODQwMDAwICAzMTMuNTE5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0IC9maWxl IzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMy ZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzdG9jCj4+CmVuZG9iago3NjcgMCBvYmoKPDwKL1R5cGUg L0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFs1MjIuNzIwMDAwICAyNDkuMTk5OTk5ICA1NDMu ODQwMDAwICAyNTYuODc5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJm IzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJk djIuaHRtbC5odG1sIzIzdG9jCj4+CmVuZG9iago3NjggMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9T dWJ0eXBlIC9MaW5rCi9SZWN0IFsxMDQuMTU5OTk5ICAyMTYuNTU5OTk5ICAxNTIuMTU5OTk5ICAy MjQuMjM5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9BIDw8Ci9UeXBlIC9BY3Rpb24KL1MgL1VSSQov VVJJIChtYWlsdG86c29iQGhhcnZhcmQuZWR1KQo+Pgo+PgplbmRvYmoKNzY5IDAgb2JqCjw8Ci9U eXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbMTYwLjc5OTk5OSAgMjE2LjU1OTk5OSAg NDA3LjUxOTk5OSAgMjI0LjIzOTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovQSA8PAovVHlwZSAvQWN0 aW9uCi9TIC9VUkkKL1VSSSAoaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMjExOSkKPj4K Pj4KZW5kb2JqCjc3MCAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3Qg WzEwNy4wMzk5OTkgIDIwNi45NTk5OTkgIDEyMy4zNTk5OTkgIDIxNC42Mzk5OTkgXQovQm9yZGVy IFswIDAgMF0KL0EgPDwKL1R5cGUgL0FjdGlvbgovUyAvVVJJCi9VUkkgKGh0dHA6Ly93d3cucmZj LWVkaXRvci5vcmcvcmZjL3JmYzIxMTkudHh0KQo+Pgo+PgplbmRvYmoKNzcxIDAgb2JqCjw8Ci9U eXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbMTI4LjE1OTk5OSAgMjA2Ljk1OTk5OSAg MTUxLjE5OTk5OSAgMjE0LjYzOTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovQSA8PAovVHlwZSAvQWN0 aW9uCi9TIC9VUkkKL1VSSSAoaHR0cDovL3htbC5yZXNvdXJjZS5vcmcvcHVibGljL3JmYy9odG1s L3JmYzIxMTkuaHRtbCkKPj4KPj4KZW5kb2JqCjc3MiAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1 YnR5cGUgL0xpbmsKL1JlY3QgWzE1NiAgMjA2Ljk1OTk5OSAgMTczLjI4MDAwMCAgMjE0LjYzOTk5 OSBdCi9Cb3JkZXIgWzAgMCAwXQovQSA8PAovVHlwZSAvQWN0aW9uCi9TIC9VUkkKL1VSSSAoaHR0 cDovL3htbC5yZXNvdXJjZS5vcmcvcHVibGljL3JmYy94bWwvcmZjMjExOS54bWwpCj4+Cj4+CmVu ZG9iago3NzMgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFsxMDQu MTU5OTk5ICAxOTUuNDM5OTk5ICAxNDUuNDM5OTk5ICAyMDMuMTE5OTk5IF0KL0JvcmRlciBbMCAw IDBdCi9BIDw8Ci9UeXBlIC9BY3Rpb24KL1MgL1VSSQovVVJJIChtYWlsdG86dGRpZXJrc0BjZXJ0 aWNvbS5jb20pCj4+Cj4+CmVuZG9iago3NzQgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBl IC9MaW5rCi9SZWN0IFsxNjMuNjgwMDAwICAxOTUuNDM5OTk5ICAxOTYuMzE5OTk5ICAyMDMuMTE5 OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9BIDw8Ci9UeXBlIC9BY3Rpb24KL1MgL1VSSQovVVJJICht YWlsdG86Y2FsbGVuQGNlcnRpY29tLmNvbSkKPj4KPj4KZW5kb2JqCjc3NSAwIG9iago8PAovVHlw ZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzIwNC45NTk5OTkgIDE5NS40Mzk5OTkgIDMy OC43OTk5OTkgIDIwMy4xMTk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0EgPDwKL1R5cGUgL0FjdGlv bgovUyAvVVJJCi9VUkkgKGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzIyNDYpCj4+Cj4+ CmVuZG9iago3NzYgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFs0 MzQuMzk5OTk5ICAxOTUuNDM5OTk5ICA0NTAuNzE5OTk5ICAyMDMuMTE5OTk5IF0KL0JvcmRlciBb MCAwIDBdCi9BIDw8Ci9UeXBlIC9BY3Rpb24KL1MgL1VSSQovVVJJIChodHRwOi8vd3d3LnJmYy1l ZGl0b3Iub3JnL3JmYy9yZmMyMjQ2LnR4dCkKPj4KPj4KZW5kb2JqCjc3NyAwIG9iago8PAovVHlw ZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzEwNC4xNTk5OTkgIDE4Mi45NTk5OTkgIDE1 MS4xOTk5OTkgIDE5MC42Mzk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0EgPDwKL1R5cGUgL0FjdGlv bgovUyAvVVJJCi9VUkkgKG1haWx0bzpmaWVsZGluZ0BpY3MudWNpLmVkdSkKPj4KPj4KZW5kb2Jq Cjc3OCAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzE1NiAgMTgy Ljk1OTk5OSAgMTk1LjM2MDAwMCAgMTkwLjYzOTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovQSA8PAov VHlwZSAvQWN0aW9uCi9TIC9VUkkKL1VSSSAobWFpbHRvOmpnQHczLm9yZykKPj4KPj4KZW5kb2Jq Cjc3OSAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzIwMS4xMjAw MDAgIDE4Mi45NTk5OTkgIDIzNi42Mzk5OTkgIDE5MC42Mzk5OTkgXQovQm9yZGVyIFswIDAgMF0K L0EgPDwKL1R5cGUgL0FjdGlvbgovUyAvVVJJCi9VUkkgKG1haWx0bzptb2d1bEB3cmwuZGVjLmNv bSkKPj4KPj4KZW5kb2JqCjc4MCAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsK L1JlY3QgWzI0MS40Mzk5OTkgIDE4Mi45NTk5OTkgIDI4OC40ODAwMDAgIDE5MC42Mzk5OTkgXQov Qm9yZGVyIFswIDAgMF0KL0EgPDwKL1R5cGUgL0FjdGlvbgovUyAvVVJJCi9VUkkgKG1haWx0bzpm cnlzdHlrQHczLm9yZykKPj4KPj4KZW5kb2JqCjc4MSAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1 YnR5cGUgL0xpbmsKL1JlY3QgWzI5My4yNzk5OTkgIDE4Mi45NTk5OTkgIDM0My4xOTk5OTkgIDE5 MC42Mzk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0EgPDwKL1R5cGUgL0FjdGlvbgovUyAvVVJJCi9V UkkgKG1haWx0bzptYXNpbnRlckBwYXJjLnhlcm94LmNvbSkKPj4KPj4KZW5kb2JqCjc4MiAwIG9i ago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzM0OC45NTk5OTkgIDE4Mi45 NTk5OTkgIDM4Ny4zNTk5OTkgIDE5MC42Mzk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0EgPDwKL1R5 cGUgL0FjdGlvbgovUyAvVVJJCi9VUkkgKG1haWx0bzpwYXVsbGVAbWljcm9zb2Z0LmNvbSkKPj4K Pj4KZW5kb2JqCjc4MyAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3Qg WzQwOC40Nzk5OTkgIDE4Mi45NTk5OTkgIDQ3MC44Nzk5OTkgIDE5MC42Mzk5OTkgXQovQm9yZGVy IFswIDAgMF0KL0EgPDwKL1R5cGUgL0FjdGlvbgovUyAvVVJJCi9VUkkgKG1haWx0bzp0aW1ibEB3 My5vcmcpCj4+Cj4+CmVuZG9iago3ODQgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9M aW5rCi9SZWN0IFsxMDQuMTU5OTk5ICAxNzQuMzE5OTk5ICA1MjQuNjM5OTk5ICAxOTAuNjM5OTk5 IF0KL0JvcmRlciBbMCAwIDBdCi9BIDw8Ci9UeXBlIC9BY3Rpb24KL1MgL1VSSQovVVJJIChodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmMyNjE2KQo+Pgo+PgplbmRvYmoKNzg1IDAgb2JqCjw8 Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbMzIxLjEyMDAwMCAgMTczLjM1OTk5 OSAgMzM3LjQzOTk5OSAgMTgxLjAzOTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovQSA8PAovVHlwZSAv QWN0aW9uCi9TIC9VUkkKL1VSSSAoaHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9yZmMvcmZjMjYx Ni50eHQpCj4+Cj4+CmVuZG9iago3ODYgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9M aW5rCi9SZWN0IFszNDMuMTk5OTk5ICAxNzMuMzU5OTk5ICAzNTMuNzU5OTk5ICAxODEuMDM5OTk5 IF0KL0JvcmRlciBbMCAwIDBdCi9BIDw8Ci9UeXBlIC9BY3Rpb24KL1MgL1VSSQovVVJJIChodHRw Oi8vd3d3LnJmYy1lZGl0b3Iub3JnL3JmYy9yZmMyNjE2LnBzKQo+Pgo+PgplbmRvYmoKNzg3IDAg b2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbMzU4LjU2MDAwMCAgMTcz LjM1OTk5OSAgMzczLjkyMDAwMCAgMTgxLjAzOTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovQSA8PAov VHlwZSAvQWN0aW9uCi9TIC9VUkkKL1VSSSAoaHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9yZmMv cmZjMjYxNi5wZGYpCj4+Cj4+CmVuZG9iago3ODggMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0 eXBlIC9MaW5rCi9SZWN0IFszNzguNzE5OTk5ICAxNzMuMzU5OTk5ICA0MDEuNzU5OTk5ICAxODEu MDM5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9BIDw8Ci9UeXBlIC9BY3Rpb24KL1MgL1VSSQovVVJJ IChodHRwOi8veG1sLnJlc291cmNlLm9yZy9wdWJsaWMvcmZjL2h0bWwvcmZjMjYxNi5odG1sKQo+ Pgo+PgplbmRvYmoKNzg5IDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVj dCBbNDA2LjU2MDAwMCAgMTczLjM1OTk5OSAgNDIzLjg0MDAwMCAgMTgxLjAzOTk5OSBdCi9Cb3Jk ZXIgWzAgMCAwXQovQSA8PAovVHlwZSAvQWN0aW9uCi9TIC9VUkkKL1VSSSAoaHR0cDovL3htbC5y ZXNvdXJjZS5vcmcvcHVibGljL3JmYy94bWwvcmZjMjYxNi54bWwpCj4+Cj4+CmVuZG9iago3OTAg MCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFsxMDQuMTU5OTk5ICAx NjAuODc5OTk5ICAxNDMuNTE5OTk5ICAxNjguNTU5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9BIDw8 Ci9UeXBlIC9BY3Rpb24KL1MgL1VSSQovVVJJIChtYWlsdG86am9obkBtYXRoLm53dS5lZHUpCj4+ Cj4+CmVuZG9iago3OTEgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0 IFsxNDguMzE5OTk5ICAxNjAuODc5OTk5ICAyMjAuMzE5OTk5ICAxNjguNTU5OTk5IF0KL0JvcmRl ciBbMCAwIDBdCi9BIDw8Ci9UeXBlIC9BY3Rpb24KL1MgL1VSSQovVVJJIChtYWlsdG86cGJha2Vy QHZlcmlzaWduLmNvbSkKPj4KPj4KZW5kb2JqCjc5MiAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1 YnR5cGUgL0xpbmsKL1JlY3QgWzIyNS4xMjAwMDAgIDE2MC44Nzk5OTkgIDI3NiAgMTY4LjU1OTk5 OSBdCi9Cb3JkZXIgWzAgMCAwXQovQSA8PAovVHlwZSAvQWN0aW9uCi9TIC9VUkkKL1VSSSAobWFp bHRvOmplZmZAQWJpU291cmNlLmNvbSkKPj4KPj4KZW5kb2JqCjc5MyAwIG9iago8PAovVHlwZSAv QW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzI4MS43NTk5OTkgIDE2MC44Nzk5OTkgIDMzNi40 ODAwMDAgIDE2OC41NTk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0EgPDwKL1R5cGUgL0FjdGlvbgov UyAvVVJJCi9VUkkgKG1haWx0bzpsYXdyZW5jZUBhZ3JhbmF0LmNvbSkKPj4KPj4KZW5kb2JqCjc5 NCAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzM0MS4yNzk5OTkg IDE2MC44Nzk5OTkgIDM3OS42Nzk5OTkgIDE2OC41NTk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Eg PDwKL1R5cGUgL0FjdGlvbgovUyAvVVJJCi9VUkkgKG1haWx0bzpwYXVsbGVAbWljcm9zb2Z0LmNv bSkKPj4KPj4KZW5kb2JqCjc5NSAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsK L1JlY3QgWzQ1My41OTk5OTkgIDE2MC44Nzk5OTkgIDQ5Ny43NTk5OTkgIDE2OC41NTk5OTkgXQov Qm9yZGVyIFswIDAgMF0KL0EgPDwKL1R5cGUgL0FjdGlvbgovUyAvVVJJCi9VUkkgKG1haWx0bzpz dGV3YXJ0QE9wZW5NYXJrZXQuY29tKQo+Pgo+PgplbmRvYmoKNzk2IDAgb2JqCjw8Ci9UeXBlIC9B bm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbMTA0LjE1OTk5OSAgMTUyLjIzOTk5OSAgNTI4LjQ4 MDAwMCAgMTY4LjU1OTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovQSA8PAovVHlwZSAvQWN0aW9uCi9T IC9VUkkKL1VSSSAoaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMjYxNykKPj4KPj4KZW5k b2JqCjc5NyAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzQzOC4y NDAwMDAgIDE1Mi4yMzk5OTkgIDQ1NC41NjAwMDAgIDE1OS45MTk5OTkgXQovQm9yZGVyIFswIDAg MF0KL0EgPDwKL1R5cGUgL0FjdGlvbgovUyAvVVJJCi9VUkkgKGh0dHA6Ly93d3cucmZjLWVkaXRv ci5vcmcvcmZjL3JmYzI2MTcudHh0KQo+Pgo+PgplbmRvYmoKNzk4IDAgb2JqCjw8Ci9UeXBlIC9B bm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbNDU5LjM1OTk5OSAgMTUyLjIzOTk5OSAgNDgyLjM5 OTk5OSAgMTU5LjkxOTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovQSA8PAovVHlwZSAvQWN0aW9uCi9T IC9VUkkKL1VSSSAoaHR0cDovL3htbC5yZXNvdXJjZS5vcmcvcHVibGljL3JmYy9odG1sL3JmYzI2 MTcuaHRtbCkKPj4KPj4KZW5kb2JqCjc5OSAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUg L0xpbmsKL1JlY3QgWzQ4Ny4xOTk5OTkgIDE1Mi4yMzk5OTkgIDUwNC40ODAwMDAgIDE1OS45MTk5 OTkgXQovQm9yZGVyIFswIDAgMF0KL0EgPDwKL1R5cGUgL0FjdGlvbgovUyAvVVJJCi9VUkkgKGh0 dHA6Ly94bWwucmVzb3VyY2Uub3JnL3B1YmxpYy9yZmMveG1sL3JmYzI2MTcueG1sKQo+Pgo+Pgpl bmRvYmoKODAwIDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbMTU2 ICAxMzkuNzU5OTk5ICAyMTguNDAwMDAwICAxNDcuNDM5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9B IDw8Ci9UeXBlIC9BY3Rpb24KL1MgL1VSSQovVVJJIChodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9yZmMyODE4KQo+Pgo+PgplbmRvYmoKODAxIDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlw ZSAvTGluawovUmVjdCBbMzExLjUxOTk5OSAgMTM5Ljc1OTk5OSAgMzI3LjgzOTk5OSAgMTQ3LjQz OTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovQSA8PAovVHlwZSAvQWN0aW9uCi9TIC9VUkkKL1VSSSAo aHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9yZmMvcmZjMjgxOC50eHQpCj4+Cj4+CmVuZG9iago4 MDIgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFsxMDQuMTU5OTk5 ICAxMjcuMjc5OTk5ICAxNjkuNDM5OTk5ICAxMzQuOTU5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9B IDw8Ci9UeXBlIC9BY3Rpb24KL1MgL1VSSQovVVJJIChtYWlsdG86dGltYmxAdzMub3JnKQo+Pgo+ PgplbmRvYmoKODAzIDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBb MTc0LjI0MDAwMCAgMTI3LjI3OTk5OSAgMjIxLjI4MDAwMCAgMTM0Ljk1OTk5OSBdCi9Cb3JkZXIg WzAgMCAwXQovQSA8PAovVHlwZSAvQWN0aW9uCi9TIC9VUkkKL1VSSSAobWFpbHRvOmZpZWxkaW5n QGdiaXYuY29tKQo+Pgo+PgplbmRvYmoKODA0IDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlw ZSAvTGluawovUmVjdCBbMjQzLjM1OTk5OSAgMTI3LjI3OTk5OSAgMjkwLjM5OTk5OSAgMTM0Ljk1 OTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovQSA8PAovVHlwZSAvQWN0aW9uCi9TIC9VUkkKL1VSSSAo bWFpbHRvOkxNTUBhY20ub3JnKQo+Pgo+PgplbmRvYmoKODA1IDAgb2JqCjw8Ci9UeXBlIC9Bbm5v dAovU3VidHlwZSAvTGluawovUmVjdCBbMjk5LjAzOTk5OSAgMTI3LjI3OTk5OSAgNTE0LjA3OTk5 OSAgMTM0Ljk1OTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovQSA8PAovVHlwZSAvQWN0aW9uCi9TIC9V UkkKL1VSSSAoaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMzk4NikKPj4KPj4KZW5kb2Jq CjgwNiAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzIzMS44NDAw MDAgIDExOC42Mzk5OTkgIDI0OC4xNTk5OTkgIDEyNi4zMTk5OTkgXQovQm9yZGVyIFswIDAgMF0K L0EgPDwKL1R5cGUgL0FjdGlvbgovUyAvVVJJCi9VUkkgKGh0dHA6Ly93d3cucmZjLWVkaXRvci5v cmcvcmZjL3JmYzM5ODYudHh0KQo+Pgo+PgplbmRvYmoKODA3IDAgb2JqCjw8Ci9UeXBlIC9Bbm5v dAovU3VidHlwZSAvTGluawovUmVjdCBbMjUyLjk1OTk5OSAgMTE4LjYzOTk5OSAgMjc2ICAxMjYu MzE5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9BIDw8Ci9UeXBlIC9BY3Rpb24KL1MgL1VSSQovVVJJ IChodHRwOi8veG1sLnJlc291cmNlLm9yZy9wdWJsaWMvcmZjL2h0bWwvcmZjMzk4Ni5odG1sKQo+ Pgo+PgplbmRvYmoKODA4IDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVj dCBbMjgwLjgwMDAwMCAgMTE4LjYzOTk5OSAgMjk4LjA4MDAwMCAgMTI2LjMxOTk5OSBdCi9Cb3Jk ZXIgWzAgMCAwXQovQSA8PAovVHlwZSAvQWN0aW9uCi9TIC9VUkkKL1VSSSAoaHR0cDovL3htbC5y ZXNvdXJjZS5vcmcvcHVibGljL3JmYy94bWwvcmZjMzk4Ni54bWwpCj4+Cj4+CmVuZG9iago4MDkg MCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFsxNjIuNzE5OTk5ICAx MDYuMTU5OTk5ICA0NjEuMjc5OTk5ICAxMTMuODM5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9BIDw8 Ci9UeXBlIC9BY3Rpb24KL1MgL1VSSQovVVJJIChodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9y ZmM0NjI3KQo+Pgo+PgplbmRvYmoKODEwIDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAv TGluawovUmVjdCBbMTQzLjUxOTk5OSAgOTYuNTU5OTk5OSAgMTU5LjgzOTk5OSAgMTA0LjIzOTk5 OSBdCi9Cb3JkZXIgWzAgMCAwXQovQSA8PAovVHlwZSAvQWN0aW9uCi9TIC9VUkkKL1VSSSAoaHR0 cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9yZmMvcmZjNDYyNy50eHQpCj4+Cj4+CmVuZG9iago4MTEg MCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFsxNDguMzE5OTk5ICA4 NC4wNzk5OTk5ICAzMDguNjM5OTk5ICA5MS43NTk5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9BIDw8 Ci9UeXBlIC9BY3Rpb24KL1MgL1VSSQovVVJJIChodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9y ZmM0OTQ5KQo+Pgo+PgplbmRvYmoKODEyIDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAv TGluawovUmVjdCBbNDExLjM2MDAwMCAgODQuMDc5OTk5OSAgNDI3LjY4MDAwMCAgOTEuNzU5OTk5 OSBdCi9Cb3JkZXIgWzAgMCAwXQovQSA8PAovVHlwZSAvQWN0aW9uCi9TIC9VUkkKL1VSSSAoaHR0 cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9yZmMvcmZjNDk0OS50eHQpCj4+Cj4+CmVuZG9iago4MTMg MCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFsyMTguNDAwMDAwICA3 Mi41NTk5OTk5ICA0ODMuMzYwMDAwICA4MC4yMzk5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9BIDw8 Ci9UeXBlIC9BY3Rpb24KL1MgL1VSSQovVVJJIChodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9y ZmM1MjI2KQo+Pgo+PgplbmRvYmoKODE0IDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAv TGluawovUmVjdCBbMTg3LjY4MDAwMCAgNjIuOTU5OTk5OSAgMjA0ICA3MC42Mzk5OTk5IF0KL0Jv cmRlciBbMCAwIDBdCi9BIDw8Ci9UeXBlIC9BY3Rpb24KL1MgL1VSSQovVVJJIChodHRwOi8vd3d3 LnJmYy1lZGl0b3Iub3JnL3JmYy9yZmM1MjI2LnR4dCkKPj4KPj4KZW5kb2JqCjgxNSAwIG9iago8 PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzIwOC43OTk5OTkgIDUwLjQ3OTk5 OTkgIDQxNi4xNTk5OTkgIDU4LjE1OTk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0EgPDwKL1R5cGUg L0FjdGlvbgovUyAvVVJJCi9VUkkgKGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzUyMzQp Cj4+Cj4+CmVuZG9iago4MTYgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9S ZWN0IFsxNTguODc5OTk5ICA0MS44Mzk5OTk5ICAxNzUuMTk5OTk5ICA0OS41MTk5OTk5IF0KL0Jv cmRlciBbMCAwIDBdCi9BIDw8Ci9UeXBlIC9BY3Rpb24KL1MgL1VSSQovVVJJIChodHRwOi8vd3d3 LnJmYy1lZGl0b3Iub3JnL3JmYy9yZmM1MjM0LnR4dCkKPj4KPj4KZW5kb2JqCjgxNyAwIG9iago8 PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzIwNS45MTk5OTkgIDI5LjM1OTk5 OTkgIDQ0Ny44Mzk5OTkgIDM3LjAzOTk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0EgPDwKL1R5cGUg L0FjdGlvbgovUyAvVVJJCi9VUkkgKGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzUyNDYp Cj4+Cj4+CmVuZG9iago3NDMgMCBvYmoKPDwKL1R5cGUgL1BhZ2UKL1BhcmVudCAyIDAgUgovQ29u dGVudHMgODE4IDAgUgovUmVzb3VyY2VzIDgyMCAwIFIKL0Fubm90cyA4MjEgMCBSCi9NZWRpYUJv eCBbMCAwIDU5NSA4NDJdCj4+CmVuZG9iago4MjAgMCBvYmoKPDwKL0NvbG9yU3BhY2UgPDwKL1BD U3AgNCAwIFIKL0NTcCAvRGV2aWNlUkdCCi9DU3BnIC9EZXZpY2VHcmF5Cj4+Ci9FeHRHU3RhdGUg PDwKL0dTYSAzIDAgUgo+PgovUGF0dGVybiA8PAo+PgovRm9udCA8PAovRjYgNiAwIFIKL0YxMCAx MCAwIFIKL0Y5IDkgMCBSCj4+Ci9YT2JqZWN0IDw8Cj4+Cj4+CmVuZG9iago4MjEgMCBvYmoKWyA3 NjAgMCBSIDc2MSAwIFIgNzYyIDAgUiA3NjMgMCBSIDc2NCAwIFIgNzY1IDAgUiA3NjYgMCBSIDc2 NyAwIFIgNzY4IDAgUiA3NjkgMCBSIDc3MCAwIFIgNzcxIDAgUiA3NzIgMCBSIDc3MyAwIFIgNzc0 IDAgUiA3NzUgMCBSIDc3NiAwIFIgNzc3IDAgUiA3NzggMCBSIDc3OSAwIFIgNzgwIDAgUiA3ODEg MCBSIDc4MiAwIFIgNzgzIDAgUiA3ODQgMCBSIDc4NSAwIFIgNzg2IDAgUiA3ODcgMCBSIDc4OCAw IFIgNzg5IDAgUiA3OTAgMCBSIDc5MSAwIFIgNzkyIDAgUiA3OTMgMCBSIDc5NCAwIFIgNzk1IDAg UiA3OTYgMCBSIDc5NyAwIFIgNzk4IDAgUiA3OTkgMCBSIDgwMCAwIFIgODAxIDAgUiA4MDIgMCBS IDgwMyAwIFIgODA0IDAgUiA4MDUgMCBSIDgwNiAwIFIgODA3IDAgUiA4MDggMCBSIDgwOSAwIFIg ODEwIDAgUiA4MTEgMCBSIDgxMiAwIFIgODEzIDAgUiA4MTQgMCBSIDgxNSAwIFIgODE2IDAgUiA4 MTcgMCBSIF0KZW5kb2JqCjgxOCAwIG9iago8PAovTGVuZ3RoIDgxOSAwIFIKL0ZpbHRlciAvRmxh dGVEZWNvZGUKPj4Kc3RyZWFtCnic7V1Jj9y4Fb73r6hzAPeIqyQgCOClHSCHAIYN5BDkEHgyCQb2 IE4O+fspLV0i31fUI1mUxLLbRuJujpanx7dv/OmPH/9++ud/Tz+9/fjv0+f537cfH5rHxvTTn1Nz /vvKXZDdo5LN8OfUCfVo23H189eHb6dvDx8ePpz//9uDsOON8z/n//j8imb8+9/Pvz38NL38YVr5 +PbP55/+d5KnP53/9+vpr387L/48P2+44OtD19szHE0j1PnXL+6vQjWdeLTnn8/rDf11uPhfD3/5 3em3ATD52I3AiwlA99dXRrfKnD+p6W4C+dty6/lZqpfC2C74s/tgpWZ49Elp1Tzq84/m/OlKm+F7 hl+U1upRjj+ecWCFHi4Skq7LdvhlXL8850vg+QN6fnFg7tX8J/izB7MLm7GPzTPM7rtsN/4MsHnr zrdcnvMl8HwKcyE8B2AOwRDaly3wfH2vv/rrUXi+ThshWiqE5060/fxaj5470cuRjaUPA1m/wOw8 50vg+cXouZONHp4/wey8S4p2lC8UNn99+ZblOV8Cz98IzwGYQzCE9mULPF/f668+3qLwfJ02QrRU CM+9GJTfqH48eu6FtONrlQ8DWb/A7DznS+D5xei5F2rCj/JpoxdGzqqUwOatO99yec6XwPM3wnMA 5hAMoX3ZAs/X9/qrvx6F5+u0EaIlH+ZnM60HoyXJ9rFan87KQYuzuXcS5vSff5zf8mG0bTIsKDH+ dYGZVgIW1LeVG998evjpvT2J5vTpl9MEwavpn08T1K/OYBt5+vTz6fcDUH84ffr1YTAY5wU5LrTL ghoXumVB0yumZzx9mr9/I1zr877eIa61VHeI687cJa57uxGuM12dbys3jh8kBmfs2hedOfSVlm2r Z2CkpuBS+NVbekVLF95TpDyNCyb8UNFfx5JeXtssWMr/XNFr/3uVoKDRFzf0e4WkV3Tc5yEC2Lfg FfQtYrqiX654xz0DbwFIYWcMJVcAjN1d2dBnAIXAawFS+JY3HOgIGLyWYoynQ7xFJO/cLCTWQNcl qF1rQu36HYVEkJ2R7wje5USYormsaIpWPaFVqIT9RWoGrnrNYR72VwJegWgUgAqMR2EXLf0YuIKS QAQg/EM7yjQUZVJQDMUS6410NSuNrr+ZwNfELGVFXoqId5HKdw1DQIcZEiD9tbyGuEK6/ENYQJC9 URQDIVK8A7kjRoDLWJ3Ji2L5npomVFfl6AgQTPD5IJhgq54AqUAzrCZGcmdhjxAIgPaAzXCr5lGa iAhgbyoAUSLyOAPEA/Om89k2wizja0GY8TzE2ze8sZIuEJFS2c9HnyEgdYpoqq55NoBQIKTbiDkk xFvmABjFkLAsUnl9uAUJ5UiddJZ6UVScopo95BXNxTu7EfaxeEuxXERjqNb4rIovpjiKYGZKvBFK NcO9BWpOt+XxLQdJe3pLjk2dzu4holoLkAT2pYzGEH1w69I3Bp6BOpUPiPCRCR7tPOggEODzQS8B gbDOLx/sQoyxAhLhgG1gsX6QzYWGLRuDQOUPD6X2As+42xghQEG8NABaf12QtXX7LLfZWPc9S3ZW bUUE8nkLi/eWI0wMoDIeqSWoHd4CnwtYZuHIMP1LWMcvgd3vKbC7TVzjmDQNmvFgYfYFhbt9rjhA VQ4yFEjmChGliwTeHebVfYRISMdzxC0FPKycCEu6z51jp1INoTqWuoGGWE4FJxxBp+IPZQpcwZKU 1pQKS+Tx09X/NpKLj4WwZBmRX+EFBpilgFPFbRTeAvl14EqUU8CnoHToa4BAMBYUSGvcKpet8QUz mCpouwBTSWqq4P6mi4yQqVZGEbVBL0PSHZeW6APxmnIzDSCi8SbfUBKgFmBj4B4KWgT9wlPTjVU+ 6BqhiItkcgtY3t+54ck778CJoHghdsGGsnK8OVY4Z5RpXdlcdqdyInf8QzO0FdjZvIkEJAQo2zB2 cavcNa0veLcxs0uksqioxvzQGwK6LlL9OKumXoZ2M+SbpXxMQ7XZFe1NL+FLKgAjQLwgIVFkZtiz 6cxcRLtFKGKQu7w9z9IuGB4R5irEe+AZ+wQeWBLC8NZTOabq5QVD08YIcZPcSdcIRepWvudS3pc6 BRb2+6lT2CJjht+SwbgFSv+PKnSIjZncKjDPotGTmLzpjnYJXy+wjzisPEFYRrcpE42QTaKKESH1 MtF+cIhA7G5RMZDh7OdYEHxmludDvsaC1W1FGmh2SaoeZQ1tEcip3tW7teC8bXxRFWOHsdwdUcfN c9UxITReygAz81XaEUG2WMIro5lMWBGxpit+Lp9C3ad0J51XI3wbvhqugGFaoiY9osYM5DBvILDB z23iR+nkwEsUxBh/S4YGZcVURPFHRiNERAU6xKC2ap/tiJDZxajYKTGfXtjLl4Jj2S5f+cwnIQoW f/ZtV9SY2ae4MUJogIGQXlCfs98QmOC/5RifOgIfsFGg3MD6yQjC8fYicAhfc4VU9xLaJLDXGtqM sNwKuG5H5fHhiozRMLFFeDcqCCuNryGim3jLaKZeRaPkqMr9faqQKw+pvsSpwlrnjiufHCNzGXY2 jVc+/wn+7I3oirieH+CV+NJRtvTDCLUrokXacQyffRYtkrrWsIC1x7CncAX7DKRYUM/TfrhJc6Bh RQnyidIBz+QTP9rlloa9hb5lJvKeUuyaGwxXALcBL0l6z1w2qlNgV1eIGrTTRpPl7ER7/WWyHLXA tqniLlh9c+usuWbEgGh6nwxqrJ09KCiRbsfX0l/xw9XxK9P51KxfU6FWburL1kZoCaNrn6aUTdhd C6pt1dzpubj2WHAJ0iuiTQNaDpoi2Z9n0Sovw0IOzXbd+jXG+F8TMVKBn4bBhvdy6uH5RAMbRohw PGEzM9KOJVo72AZxPtypZ8NWrigK+DpQC1BSC/k/9mMUa4PngKpBgEPrEuTZaCP6NqDieyF6ibA+ 0XvAZi2Si5hMY6H64Gu20CURmQgqM/gUaIQzfsxgu7I2vLkomhI2fC0o2qQQN6MidhdpflQXcXpf fkb3WwRv874WH7YpQfyQZgE6ZZPIaCCkl4xUy5UZ9R8R7ntRaWiDU10zeo4imAy2mx04us2YrgIT AjDyCfjgLfmMsUS7CL+IZB7wNi8OeAbhjd8i7ZO6a3zyj07m3vriXhG+A47IiS3xpXl8/8vdk3Mh kdjp4Iu/Kx6Qnfa/dy8ekH1LEM0mW/k6wYiU7ovgvH3vjJSZRHNAd5qRNzN0RBAMImuBWrtC4qkP z+HfosrzhY22YCOlen8zQ7mfIuEpKeLPBONbKYpMVkhvg41QErxRn944zE9JiGhxLdBJV9Ttk/IO EtnHDIGqlgCOss8hx0PLr/lq25zC2H102T6G5z4oLDCNsVpaRwRlZE0jhFB6HlWWzIJLHXaJ7idM XiCUltHyXiRunt56m4MP0O0d5RB2ekFECcAupxlE0GlJQ9Zc8qzQv8XWVUSUI/OmTvrmRlS0s2Zq RA6EPrSsvbgcKgwaIkNi8NWEGX0yrEKAW9BggOKM9G4ENFzYU3dzxspS0HPaplmsZ0zixenV7IRE PN+Afj6WbLL5zRJ0GuGCpmfIM3aOb6PJGRFVoqrq7hy/QuJwOQvzoDDVJlnzDBub9WwiKhGwsLQA m0X0L/LGf3oPFG+mHlT1nlGrEaGV+XAaexQ07ksGS6XLVHwo1f1leuLuByH8jJAMWc7LlJARXkZS q8sZlFgWj2YXNVU2PWRzjSZ4scIPX8moPDum8n6jI+Imj1FdTn+ELojv+xxCQCqfLYGt4xme93Yz KlOLuq5KJeS+YDfTC163OXV1l+bzamgm5+sKnIe6j0DIaJT7sYLBOcYsz5YZrJ0+zS5C1++jY0vM pWVP9o03qQqJcn1xuzeRB3dc719Cg/C9HHw0lBV2OZEq/ohpXupACS3PqQcdQlWNEuYjNxCV5lPh vPjjZdkxFvVR9Si8auNnqrJNFiFyKCS47aUdmpdtWyQ2s46yfnHkGcZk1VKEJQcfx3cdFagVQHLn Uz3pjBkxaCVjht5atOR7G3elF+cdCCWj5xESa/yoqpkv1qwiOogqpGsdPQnUBre8vSp+y2PYNG0+ hjPGhc0egotyOoQLJ3thR1T6rK+cfr67II+tpoHZ01mtX+3eGenmMvFA0/AdbM4s5C3FtKN96EID 6XsoiaAaTMsFJ82j6ec/FxwIxMH5v56/RJ+vHjjnbK5Y6S58efjosJ7/RF964tsYSRl+2Crue4J7 9ZqiCbJYYLTAAoTBJPdQTefXzSUcTkGCpc+w21PsYIZeRduwrx7eJIV3pkgn9WOTqUm0yicn3Zu6 yWmA2Odlum1ACxLIh6JyFomOPH/D0RPQ5Czxbfgt85QcnfIW2HQwgulrkRXgGYGCyDUEZchHFh+z sjYr+IBbAkcEr8mKgL3qYAxuoYDxOEUE0VsU6Au+3xkkI32oeKLqHkEFDAHagVANR1NzQdwK0wnA kJMh212aDmJtXZoqsIqoeAXtDaakoFjBZ1CmkD1dYMW8pIQE24U2Ln1GA68FwGDhdTKkGgbPvqUy AUzed3Qb5HVBs4ZTgBQWUpvv1ywbI55JyGmzjNW/zah/jbyYc9K4CxXq30b5X91QztcQMXCs3P3t KGl8eENkm7RtSpBts6LybVOCoAF8S1BYgRHQR9nD9ANK7KNtyT72TeX7aFsfDcBtlW1b3xAhCfHV lMopxsG3ra95yjr4sAA5ClDN2Q6+7S4kaZS7UB9J9gT3CqyPQMHJit8jaX8FeBO8Pw8C7Vh/3igf TWiTUeNoNqGdBWq15Yi8tvXpS8qmbvoaIL6GOdjYFVqYMQdpX0g3rRFpdyD5DLvkIWGTcJCc7JqF OFRfufCRs12zEAc4ojTeGBEgAXc34GGtBQQgGgyxHYh28PEQGrqAK4CM0bmnsS5eGmMoByIVACkb UsJwOeVi1R7IcKpXDMNFRAy28NTRdacLOj2moJ6SldEcirPhW0In5BT25ekCfly6X24kscIGA7Zq QWioCVy5Xz4g1Dcbt3QMuucjqDZxDIDPMfNXzDHoNIk5PC/UR5I9wT1ilnUMUJ3x4X3o1aBeGu86 YK7+2FSg8BFZMPSxkJMUfd3k9Bz6WOgpUN24ZlHRBcgNZjiaGkahHEktwz4WpxY5haUdamll3dQi 57jvBQ0QFwObFQQFJlth6++NOFq5AXG0nU8cSjeVE0fbcaoJIlJ8vp+VLRDViihKgTD9keQzbGxx 8lHa+uSjReWyZYB4XbbgtDzehWbz9EWKnKgHeig9DTtdnJ60IOJI28otmwFiHw1sAQbWrEBVC417 RZi9gZDMQcRhIw2ZvUPouicCy/gKsEIC64nACuVGVogD6jZ5cZRRpglycp4zCFOy1njj0LgGNS02 CdSbjgQDrG7rJsEBYh8v0HkDOpMtMkOKY3Vm6FDB9EhMby/O0FSD/bwwIH/3KEtvgqzN11cDnwaq wXTKVtxNRgREDCxEmOWAD5BKMCGwp29hMyLNkaUccq5Iv1BaLRkRzHdADKdERoTmOzAjAjZ+rekN 1UlfgulGUwlWl/oYIF4Xc3WlNwaErjNLlmfTkG2TlW/bALGHBpCC8lAXQ26xS4ru0pQ7rHiXFLdL UNMlDt22OXdYdttMS7atayvfNtMSNNxZTe+A4fL7OJUsLftohK18H+dSkwsaKq/pHRDqwbtl6t6K S6XzQal76hzlpu6tWMrMR41wWaiPJHuCez4/wjuVJWp668qmiUkPLWgqkpgf9ZBDLLJ2YhGTHnLQ APOBIbTDl9/CLdDqiH47hCjZDFyJnEpdYXO5BVFKSpRq9DwqJkrJEiVGitiMLl9gElFGnk5gdUk9 NTlNZQlMjU6TQ2C6kXUTmJqcJgcNkJgAEQZjBtgGb8wKQ54PAiF3Nuli2Oni9KSbjtCT6eumpwFi hp5+xCSw6eOIAxKVa5XqMN8IAv4wz4kN9sIVEelq4MPXlFMrSXkbo312sqJy8TxAvM5OfMob5SRr EICID50uAznLY/jLikjhe1O62kpFyMdUTj4DxIz5GJvxSw8USKcUTrsLR2SWB0x4gsQxX2CCDfAH XzTCj6cpMMAno2FNw7QmviImo+oP8tesIxwx8gggZVuyofYZJRvrHfFdt/i1rDWL863YuVI/Ap0e Va+pfZFwPyUAkm7GD14CYJT2VY0xlqqaulTyALFHfJWXAAwIXWeWHEN8LDVzt62XlW/bVDbkoOHO spQDhsvvY9/5+2ilqHwf+85HQ+VZygGhHrybZim3HS0sYWYuZCkh0CMTPi6IxJ58HaZLwTyD41Vh oh9EX2BOwERZcrmCBjkipiTCLMb02ErOQN2xrdYuA3Wl7t2F+vh6bqt19rhAbStO+4DzPTKKu7Pn tByUidOUeyqxlueShjVrGa4oMOyTH/+Bw07epC+UqI+1vc/Fqhd1c7GyhNYqN44HhHrwbqqdjfGJ 9DbtDIUtMBiYKuNi4z+suZS1ic64C/WRZE9wf3cNZClZs8qGDXbGx32RwqRJBi4UKMfJlBVToJiF zAUNLxNocmuKVBw97Z2XlF3j06TSsm6aHCD2UZmelzx23MBRoydkKglmuG/KF2lfH6yqXMYpypoK zmuEnaa0kHEwCVZjZhyJgVQK74XMDZgIbAYp4hARYJ8C2R9EavoYZOT8N+QK2G1UHPRr5yP+nAJE NtMZMWkr3VLLyIVCQQYe7cOLNXqLOjRKqTjN6k5BvTmQt0xbDBy1A9OLVuIKkHTLaLMtEd/QfEqN hjPueERqRoxEAhwFYiTSjv6nM0h87Jez9Y5IHSD2mKDyGImc2uMsO/M7advG9jhn25RUlW/b1B7n oOHOEohK0g8oUTA/Tih293Eqqat3H5UkOqjyBOKAUF9nbhmiLDqhmD+YBFOMa22ON9sdy9Qf0OZU A2LpNU0gztkm8FRXnhE6WjfJVAGDaJ+MYjvqWWfamNXuQn2MPkDsbXqJMxkwxAEJRFiA7TiokpQO +lE9/TjeEWbPU8CgEOCUjVzi5/Mp14ypXeDWFTgYFXrksPcTAIMroN4fPFLWicUzINkyWcyNw2Ri IBjAKUDKn/L5ROUZO35rE/bggxywt7hRgEL6cWqH48fDJWRWEzV4TCUAf1QI1goE6mbL2AXLCAm+ 1pYWBW3iKiNCCrjKwoxZimUkiRinp9t6R5IMEHv7U7mrLKa55naXkSRt0ZEkaKtDOQF7RUlbffk6 jBHCWbzvCU+iNQ/1gRmlfFB0uI/hPc48aJ2ZB9a6CzVybevvYMRx6elDxiNC/bztQRV4hEHDp4LA 9mAn8kdkOoC02LERuMD2gAJgEU38lZzjJpzY1f4xGmt9iq/FsMIUBH9FRr84NZIkSGgwo2h9Nva+ l8g4APcWMKP0WALnCGQz9kxULJA1VamVm1Fm6plwTIAtzShZ8rRmCTGm9NlvRc2oy9dhQQabBUSe LDFtgmIZzKiCRVyOfoAwA/9asA6o7zebxGvjOHg5B1hP/9ptTuHVQ29YK5fDJ8ec3WWhPjk3QOzR PJhRaL2B6cEW4UTEc1nTlO8eLxKMnKjArY5KN1Yz6kpzhgew1VHQTg+xNWy4D7BFu4JU9gyCDIqJ mFJZIIAZQVMZ7s4WkdWIKlC+io9vkFBHmjBTtcAiinI8AojAwPhriPJnjCgoGEhtwx2aOd4M1Aux YeKMgqqDGsagFqxIMdQ4bq512j7HeYZtvQ1jcho3195Lw5icxi22uzSMtUUbxiJcE2gpg46Rkq7J Umy6RTUGzkChDy1Ra7GNr8I2jeNrDYGUd00iguSQ6wIHaBPHQ40B7qX7wTStu1ChFFPWp2h+9hNO uoJWhozy/4hiC3Z8GNrVIFq2cFa2LKpfK/oAm5gvHAEjOb3pYp+SHxxtz/dYUMqNpo+DDO2mJcok 3dDepAshY3bBPkYz9ils6hIsdat33LmwhbEu2tE2X0qnxThDq623dHqA2NvSyo11MY3MancpnW7L lk6zxjpfXF3UWF9qxkAUQvUFa2li6TQNk1ebR+AHOkUUjtQ6rSrLWB+FllMXPqUN6q0LHyD2KLpE Xfgmx92iH8ib1XzNC3s+BNZSp3cIV1tZA1W90dO7HK+Cti7fzyHDtZTr8IcMH1rQY+ZM4uGV0qw1 z9dSu9b8YZJYXbXPxOC7ybbVvuXkyKbJyBHNsmIJAc84cy6ZbSeHxjW3IOlCwHbK/VI1Wc7C9v7W Ax/CkPIuvPUzH0LUxXlGRxfAsW3oFZbSteGuAGyGnlEKm6Id+xhEp+8Omzyudsem1k2l2ITXBnBV ChPzYW2ir45L4Yo1TJz/nr6d8SHs+GHzP5+/5qrRD6cPD/8HZES3zGVuZHN0cmVhbQplbmRvYmoK ODE5IDAgb2JqCjYyMzQKZW5kb2JqCjgyMyAwIG9iagpbNDMgL1hZWiA0Ny41MTk5OTk5ICAKNjg4 Ljg3OTk5OSAgMF0KZW5kb2JqCjgyNCAwIG9iagpbNDMgL1hZWiA1MC4zOTk5OTk5ICAKNjE2Ljg3 OTk5OSAgMF0KZW5kb2JqCjgyNSAwIG9iagpbNDMgL1hZWiA1MC4zOTk5OTk5ICAKNzQ4LjM5OTk5 OSAgMF0KZW5kb2JqCjgyNiAwIG9iagpbNDMgL1hZWiA0Ny41MTk5OTk5ICAKNzE4LjYzOTk5OSAg MF0KZW5kb2JqCjgyNyAwIG9iagpbNDMgL1hZWiA0Ny41MTk5OTk5ICAKNDkwLjE1OTk5OSAgMF0K ZW5kb2JqCjgyOCAwIG9iagpbNDMgL1hZWiA0Ny41MTk5OTk5ICAKMjczLjE5OTk5OSAgMF0KZW5k b2JqCjgyOSAwIG9iagpbNDMgL1hZWiA1MC4zOTk5OTk5ICAKNTMwLjQ3OTk5OSAgMF0KZW5kb2Jq CjgzMCAwIG9iagpbNDMgL1hZWiA1MC4zOTk5OTk5ICAKNzY5LjUxOTk5OSAgMF0KZW5kb2JqCjgz MSAwIG9iagpbNDMgL1hZWiA1MC4zOTk5OTk5ICAKNTczLjY4MDAwMCAgMF0KZW5kb2JqCjgzMiAw IG9iagpbNDMgL1hZWiA1MC4zOTk5OTk5ICAKNTUyLjU2MDAwMCAgMF0KZW5kb2JqCjgzMyAwIG9i agpbNDMgL1hZWiA0Ny41MTk5OTk5ICAKMTU3LjAzOTk5OSAgMF0KZW5kb2JqCjgzNCAwIG9iagpb NDMgL1hZWiA1MC4zOTk5OTk5ICAKNjYwLjA4MDAwMCAgMF0KZW5kb2JqCjgzNSAwIG9iagpbNDMg L1hZWiA1MC4zOTk5OTk5ICAKODAwLjIzOTk5OSAgMF0KZW5kb2JqCjgzNiAwIG9iagpbNDMgL1hZ WiA1MC4zOTk5OTk5ICAKNTk0Ljc5OTk5OSAgMF0KZW5kb2JqCjgzNyAwIG9iagpbNDMgL1hZWiA0 Ny41MTk5OTk5ICAKNTE5LjkxOTk5OSAgMF0KZW5kb2JqCjgzOCAwIG9iagpbNDMgL1hZWiA0Ny41 MTk5OTk5ICAKMzAyLjk1OTk5OSAgMF0KZW5kb2JqCjgzOSAwIG9iagpbNDMgL1hZWiA0Ny41MTk5 OTk5ICAKMTg3Ljc1OTk5OSAgMF0KZW5kb2JqCjg0MCAwIG9iagpbNDMgL1hZWiA0Ny41MTk5OTk5 ICAKNzEuNTk5OTk5OSAgMF0KZW5kb2JqCjg0MSAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5 cGUgL0xpbmsKL1JlY3QgWzUyMi43MjAwMDAgIDY4NS4wMzk5OTkgIDU0My44NDAwMDAgIDY5Mi43 MTk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAj MmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwj MjN0b2MKPj4KZW5kb2JqCjg0MiAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsK L1JlY3QgWzUyMi43MjAwMDAgIDQ4Ni4zMTk5OTkgIDU0My44NDAwMDAgIDQ5My45OTk5OTkgXQov Qm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1w NTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjN0b2MKPj4K ZW5kb2JqCjg0MyAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzM1 Ni42Mzk5OTkgIDQ0Mi4xNTk5OTkgIDQxNS4xOTk5OTkgIDQ1Mi43MTk5OTkgXQovQm9yZGVyIFsw IDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGly IzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjNSRkM1MjM0Cj4+CmVuZG9i ago4NDQgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFs0MzQuMzk5 OTk5ICA0MDguNTU5OTk5ICA0OTIuOTU5OTk5ICA0MTkuMTE5OTk5IF0KL0JvcmRlciBbMCAwIDBd Ci9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRy YWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzUkZDMzk4Ngo+PgplbmRvYmoKODQ1 IDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbNTIyLjcyMDAwMCAg MjY5LjM1OTk5OSAgNTQzLjg0MDAwMCAgMjc3LjAzOTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVz dCAvZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMy ZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMyM3RvYwo+PgplbmRvYmoKODQ2IDAgb2JqCjw8 Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbMjUyICAyMzYuNzE5OTk5ICAzMjQu OTU5OTk5ICAyNDcuMjc5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJm IzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJk djIuaHRtbC5odG1sIzIzY2xpZW50IzJkcGFzc3dvcmQKPj4KZW5kb2JqCjg0NyAwIG9iago8PAov VHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzUyMi43MjAwMDAgIDE1My4xOTk5OTkg IDU0My44NDAwMDAgIDE2MC44Nzk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2Ej MmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1 dGgjMmR2Mi5odG1sLmh0bWwjMjN0b2MKPj4KZW5kb2JqCjg0OCAwIG9iago8PAovVHlwZSAvQW5u b3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzI3Ni45NTk5OTkgIDEyMC41NTk5OTkgIDM0OS45MTk5 OTkgIDEzMS4xMTk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2 YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5o dG1sLmh0bWwjMjNjbGllbnQjMmRwYXNzd29yZAo+PgplbmRvYmoKODQ5IDAgb2JqCjw8Ci9UeXBl IC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbMTU2ICA4MDUuMDM5OTk5ICAxNzIuMzE5OTk5 ICA4MTIuNzE5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9BIDw8Ci9UeXBlIC9BY3Rpb24KL1MgL1VS SQovVVJJIChodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL3JmYy9yZmM1MjQ2LnR4dCkKPj4KPj4K ZW5kb2JqCjg1MCAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzEw NC4xNTk5OTkgIDc3NC4zMTk5OTkgIDUyMi43MjAwMDAgIDgwMC4yMzk5OTkgXQovQm9yZGVyIFsw IDAgMF0KL0EgPDwKL1R5cGUgL0FjdGlvbgovUyAvVVJJCi9VUkkgKGh0dHA6Ly90b29scy5pZXRm Lm9yZy9odG1sL3JmYzYxMjUpCj4+Cj4+CmVuZG9iago4NTEgMCBvYmoKPDwKL1R5cGUgL0Fubm90 Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFszMzYuNDc5OTk5ICA3NzQuMzE5OTk5ICAzNTIuNzk5OTk5 ICA3ODEuOTk5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9BIDw8Ci9UeXBlIC9BY3Rpb24KL1MgL1VS SQovVVJJIChodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL3JmYy9yZmM2MTI1LnR4dCkKPj4KPj4K ZW5kb2JqCjg1MiAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzI0 MS40Mzk5OTkgIDczNS45MTk5OTkgIDM0My4xOTk5OTkgIDc0My41OTk5OTkgXQovQm9yZGVyIFsw IDAgMF0KL0EgPDwKL1R5cGUgL0FjdGlvbgovUyAvVVJJCi9VUkkgKGh0dHA6Ly93d3cudzMub3Jn L1RSLzE5OTkvUkVDLWh0bWw0MDEtMTk5OTEyMjQpCj4+Cj4+CmVuZG9iago4NTMgMCBvYmoKPDwK L1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFszMzIuNjM5OTk5ICA3MjYuMzE5OTk5 ICAzNTUuNjgwMDAwICA3MzMuOTk5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9BIDw8Ci9UeXBlIC9B Y3Rpb24KL1MgL1VSSQovVVJJIChodHRwOi8vd3d3LnczLm9yZy9UUi8xOTk5L1JFQy1odG1sNDAx LTE5OTkxMjI0KQo+Pgo+PgplbmRvYmoKODU0IDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlw ZSAvTGluawovUmVjdCBbMzIxLjEyMDAwMCAgNjUyLjM5OTk5OSAgNTA5LjI3OTk5OSAgNjYwLjA3 OTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovQSA8PAovVHlwZSAvQWN0aW9uCi9TIC9VUkkKL1VSSSAo aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaGFyZHQtb2F1dGgtMDEpCj4+Cj4+CmVu ZG9iago4NTUgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFsyNzcu OTIwMDAwICA2MzAuMzE5OTk5ICA0MTkuMDQwMDAwICA2MzcuOTk5OTk5IF0KL0JvcmRlciBbMCAw IDBdCi9BIDw8Ci9UeXBlIC9BY3Rpb24KL1MgL1VSSQovVVJJIChodHRwOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1pZXRmLWh0dHBiaXMtcDctYXV0aC0xOSkKPj4KPj4KZW5kb2JqCjg1NiAw IG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzI1Mi45NTk5OTkgIDYy MS42Nzk5OTkgIDI2OS4yNzk5OTkgIDYyOS4zNTk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0EgPDwK L1R5cGUgL0FjdGlvbgovUyAvVVJJCi9VUkkgKGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQt ZHJhZnRzL2RyYWZ0LWlldGYtaHR0cGJpcy1wNy1hdXRoLTE5LnR4dCkKPj4KPj4KZW5kb2JqCjg1 NyAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzE5My40Mzk5OTkg IDYwOS4xOTk5OTkgIDQwNC42Mzk5OTkgIDYxNi44Nzk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Eg PDwKL1R5cGUgL0FjdGlvbgovUyAvVVJJCi9VUkkgKGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtb2F1dGgtc2FtbDItYmVhcmVyLTEyKQo+Pgo+PgplbmRvYmoKODU4IDAgb2Jq Cjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbMjQ2LjIzOTk5OSAgNTk5LjU5 OTk5OSAgMjYyLjU2MDAwMCAgNjA3LjI3OTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovQSA8PAovVHlw ZSAvQWN0aW9uCi9TIC9VUkkKL1VSSSAoaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFm dHMvZHJhZnQtaWV0Zi1vYXV0aC1zYW1sMi1iZWFyZXItMTIudHh0KQo+Pgo+PgplbmRvYmoKODU5 IDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbMTMyICA1NzguNDc5 OTk5ICA1MTguODc5OTk5ICA1OTQuNzk5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9BIDw8Ci9UeXBl IC9BY3Rpb24KL1MgL1VSSQovVVJJIChodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p ZXRmLW9hdXRoLXYyLWJlYXJlci0yMCkKPj4KPj4KZW5kb2JqCjg2MCAwIG9iago8PAovVHlwZSAv QW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzM5NC4wNzk5OTkgIDU3OC40Nzk5OTkgIDQxMC4z OTk5OTkgIDU4Ni4xNTk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0EgPDwKL1R5cGUgL0FjdGlvbgov UyAvVVJJCi9VUkkgKGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWll dGYtb2F1dGgtdjItYmVhcmVyLTIwLnR4dCkKPj4KPj4KZW5kb2JqCjg2MSAwIG9iago8PAovVHlw ZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzQxNi4xNTk5OTkgIDU3OC40Nzk5OTkgIDQz MS41MTk5OTkgIDU4Ni4xNTk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0EgPDwKL1R5cGUgL0FjdGlv bgovUyAvVVJJCi9VUkkgKGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0 LWlldGYtb2F1dGgtdjItYmVhcmVyLTIwLnBkZikKPj4KPj4KZW5kb2JqCjg2MiAwIG9iago8PAov VHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzIxMi42Mzk5OTkgIDU2NiAgNDI3LjY3 OTk5OSAgNTczLjY3OTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovQSA8PAovVHlwZSAvQWN0aW9uCi9T IC9VUkkKL1VSSSAoaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC12 Mi1odHRwLW1hYy0wMSkKPj4KPj4KZW5kb2JqCjg2MyAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1 YnR5cGUgL0xpbmsKL1JlY3QgWzI5NC4yNDAwMDAgIDU1Ni4zOTk5OTkgIDMxMC41NjAwMDAgIDU2 NC4wNzk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0EgPDwKL1R5cGUgL0FjdGlvbgovUyAvVVJJCi9V UkkgKGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtb2F1dGgt djItaHR0cC1tYWMtMDEudHh0KQo+Pgo+PgplbmRvYmoKODY0IDAgb2JqCjw8Ci9UeXBlIC9Bbm5v dAovU3VidHlwZSAvTGluawovUmVjdCBbMzE2LjMxOTk5OSAgNTU2LjM5OTk5OSAgMzMxLjY4MDAw MCAgNTY0LjA3OTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovQSA8PAovVHlwZSAvQWN0aW9uCi9TIC9V UkkKL1VSSSAoaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1v YXV0aC12Mi1odHRwLW1hYy0wMS5wZGYpCj4+Cj4+CmVuZG9iago4NjUgMCBvYmoKPDwKL1R5cGUg L0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFsyOTMuMjc5OTk5ICA1NDQuODc5OTk5ICA1MTku ODM5OTk5ICA1NTIuNTU5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9BIDw8Ci9UeXBlIC9BY3Rpb24K L1MgL1VSSQovVVJJIChodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRo LXYyLXRocmVhdG1vZGVsLTA1KQo+Pgo+PgplbmRvYmoKODY2IDAgb2JqCjw8Ci9UeXBlIC9Bbm5v dAovU3VidHlwZSAvTGluawovUmVjdCBbMzgwLjYzOTk5OSAgNTM1LjI3OTk5OSAgMzk2Ljk1OTk5 OSAgNTQyLjk1OTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovQSA8PAovVHlwZSAvQWN0aW9uCi9TIC9V UkkKL1VSSSAoaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1v YXV0aC12Mi10aHJlYXRtb2RlbC0wNS50eHQpCj4+Cj4+CmVuZG9iago4NjcgMCBvYmoKPDwKL1R5 cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFsyMTIuNjM5OTk5ICA1MjIuNzk5OTk5ICAz MTIuNDgwMDAwICA1MzAuNDc5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9BIDw8Ci9UeXBlIC9BY3Rp b24KL1MgL1VSSQovVVJJIChodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1ODQ5KQo+Pgo+ PgplbmRvYmoKODY4IDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBb NDA1LjU5OTk5OSAgNTIyLjc5OTk5OSAgNDIxLjkxOTk5OSAgNTMwLjQ3OTk5OSBdCi9Cb3JkZXIg WzAgMCAwXQovQSA8PAovVHlwZSAvQWN0aW9uCi9TIC9VUkkKL1VSSSAoaHR0cDovL3d3dy5yZmMt ZWRpdG9yLm9yZy9yZmMvcmZjNTg0OS50eHQpCj4+Cj4+CmVuZG9iago4MjIgMCBvYmoKPDwKL1R5 cGUgL1BhZ2UKL1BhcmVudCAyIDAgUgovQ29udGVudHMgODY5IDAgUgovUmVzb3VyY2VzIDg3MSAw IFIKL0Fubm90cyA4NzIgMCBSCi9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCj4+CmVuZG9iago4NzEg MCBvYmoKPDwKL0NvbG9yU3BhY2UgPDwKL1BDU3AgNCAwIFIKL0NTcCAvRGV2aWNlUkdCCi9DU3Bn IC9EZXZpY2VHcmF5Cj4+Ci9FeHRHU3RhdGUgPDwKL0dTYSAzIDAgUgo+PgovUGF0dGVybiA8PAo+ PgovRm9udCA8PAovRjYgNiAwIFIKL0YxMCAxMCAwIFIKL0Y5IDkgMCBSCi9GMTQ5IDE0OSAwIFIK Pj4KL1hPYmplY3QgPDwKPj4KPj4KZW5kb2JqCjg3MiAwIG9iagpbIDg0MSAwIFIgODQyIDAgUiA4 NDMgMCBSIDg0NCAwIFIgODQ1IDAgUiA4NDYgMCBSIDg0NyAwIFIgODQ4IDAgUiA4NDkgMCBSIDg1 MCAwIFIgODUxIDAgUiA4NTIgMCBSIDg1MyAwIFIgODU0IDAgUiA4NTUgMCBSIDg1NiAwIFIgODU3 IDAgUiA4NTggMCBSIDg1OSAwIFIgODYwIDAgUiA4NjEgMCBSIDg2MiAwIFIgODYzIDAgUiA4NjQg MCBSIDg2NSAwIFIgODY2IDAgUiA4NjcgMCBSIDg2OCAwIFIgXQplbmRvYmoKODY5IDAgb2JqCjw8 Ci9MZW5ndGggODcwIDAgUgovRmlsdGVyIC9GbGF0ZURlY29kZQo+PgpzdHJlYW0KeJztnVuP3LqR x9/nU/RzgOMjXnQDggD2HJ8A+7CAYQN5CPZhcXJZBDPBevOwXz9St7pF1q+pkmSqW22PjWTGPBJV LNaN/yqSP//x838f/v6vw8/Pn//38Nvw8/nzU/GuKNvTn0PR/f0pbLDNO2eL/s+hMe5dVR9bf3t9 +nr4+vTp6VP3/1+fTHV8cfjR/cfzJ4rj33/99s+nn08ffzq1fH7+z+63/z/Yw390//vH4c//1TX+ Zeivf+D1qWmrjo6iMK7750v4T2Obyh9/79oL+c/+4f95+tPvDv/sCbPvmiPx5kRg+M+fyqrwrnxn i+abSP46vvquKlxrTVk1yd/Djp0b6PEH05RVP4bCdkN3vuze6P6UXXvVHJ+xPQ8q49/5jnor223d DePUfunnJdF/z56/BTS3bviT/D2iOaStMcffjzSH32qPZJK2qD0Yy6Wfl0T/kuZMfE7QnKIhNS9b 8Pn6XL/G7bP4fF02UrKUic+lqU3/2aKO5bk0zVFXu/aIBtF+oTno5yXRfzZ5Lk1bHfuvY9kobdEe n5G0xe3BWC79vCT634jPCZpTNKTmZQs+X5/rSJ5n8vm6bKRkKab5ZP17Z5b6PaR5kf+oyoP3rpup svGH7sf//bX78qccc9zUzZHCzvVFutTUret/79qj8Yv2C7+Cfl4S/WfTpaYpqiM5LpbLzpy2R3Ik bXH7OJaxn5dE/9l0KeZzguYUDal52YLP1+f6NebbLD5fl42ULN1Wl8qqc6etPViXUZdMUZvTgESc VdT2NJnCN8btoy8d+3lJ9J8vzipqd5o0EbMUdWnPgW9MW9gejuXcz0ui/3xxVsTnBM0pGlLzsgWf r8/1q2ifw+frspGSpdvqUm3KDXTJVv7Cr3DObFVe5jIcf9w+8mvs5yXRfz5dslU9zNmr+FYXNDTX aAvbw7HUV+U4bM+lSxGfEzSnaEjNyxZ8vj7Xr6J9Dp+vy0ZKlmKaz9BFi4X8Mr3x/uBd64uDbQ6d +gx682kdqmCOf0NiTi0JVOHrxIsfvjz9/GvVWZPDl78dThT8dPrx5UT1Tx3ZpTl8+cvh9z1Rfzh8 +cdTD6IMDfbYUI8N7tjQjA1ePnHq4+OXYfzb8NqbI9z0aLz21hSPx2vfmEfkte982MPxunL2EXld efd4vK4b1/O6eixW163fiNUrUe2vEy8eB9QN5/qIumns/E/dlmdiKkldfWyoLg3WigY8YZpjQzk+ cWrwkgcB21rZ6QetwTbyCdmpK0bGSrntGWnISFPVh54d1buyj+Jfn0zThg0vT59nqcK1z03P20Rn kyLZUxzPoJRAX0sJtHcUuJ6hEb3OSOF4P5KnfifFFnv8SmPOcZU3QiZNIbhiquvyNDLSQnNL0WDw CibDLhicorXj6NwHSdmzHMyvxwY7kmrkE1JJzXs5MdI2oA8DNf4o+3BSjWFBpRqbX+Xg3muvYPgz KIX1+Cg7VT9rPkpN+0X7LK2pZBCsqc4xVy02fLbsl09N52wHw1f5MmzYn+HrKY6UgBotlS8lSeXE K5gOOPhGNrSy02ftiUE7gymFQuMrUgr4FbyCJ2Qf9uQq2onRSo6BdOukymNwHyVPb8IgvEJK5SuD IjXpPgaVN2ZiMKBdkuqk6XXv5WdkpzPkUp3twRgFsy31gw1g6k4m18I3qZJrYQ30sQTee6Zhbfv4 sbF+tKs+bOjt6u1s5hA32MtKsb7uOKfYqJo7slE+YXXRlIZI79RIndH1jiYC/NCNu24hZR98BSwE P2SkOUQWgTGDZVquqvisV7VKn0qdp7TDcMuq+SMLMQ2SYxw++sArarxAF2JlVALSdf9QaF/hGq8S PMVKxNVyGjBajOWDHL4USwgMZh+UumdN+LEQm6FzqlHaJEzRw0cOboWVUk2fLpZEoXSfq47WwUqp hi0VlC13se6C2djahQ13cbEuCcfoxo0OA8EeQhfMnq4RCKFKTd5h7Gco4opADXZZNcM5Qg4YN8wc GISxDLbsPshaL/aR6AEoGEx+MESJHADiSo0ZeHZg4YFxJJx18ARAZhXjGAC9IEIE5CWxJ/PL9Rme AIF0XBqD42gz4NK+sLGN89ZLG7cveKaneNoQ7guX7hka0bspLl0mcWnEizSYctmOJ+jcEYMjLMuJ S4/VDKD9pBymGCmBugAyBnQNPVbhXuqgZDPNB5JWkg6iu/gsCKtlHyAsEYf5BaMluK3bRvkKk3jw FR9EA+nQE4HgKZ6QroFPLE8pDLheEB7Aq6nIPYF6NaXAr8ABqRPF2Yc2qAxip7oUog81p4v8ERNK YBCWXOgDWTpdguDU92uVdqL8MyR3uX5QQKwcnOxUF9QZRmj5V67IQz7vkMfFVm42A1bYgxmRsiqH emZzxfoEqgs/DhUCg9BpWQjCPBgkU78WKxjV53Ch8F42yIoWrKRyhqB1e/6KDEH9ifQwpwUsCBGm xBuRjXUJe4A0WJbRtZesMNICgLGYwgNoIQFYgKcoBck4mLZwqa8As9Ub9KIVVrHI4WddLTRlPBET ToaGanlxBCvcoNy6LkP8pTmE9dPNIe20bJhB2LNk4fLB5SieodFVi2dYb6NHunCxMjq8UfFM3fRg TDOiM50xCRr2h870FEe6Nzg0LE0CgyYBN0CDxHqRt5JeQrejMwBkFCnoiPK+ilbuhHh1QhrLwPJ4 zP0ihGKGyZYQyIxSPHwFi6/lqw92igV9oiJ00bJIx0T0RY++1kAJdpBF+2YH3dZJtweW6SYaa6sZ q+81i9wc8J2eHpG2BxJB0AOBAApvySKpM1h/6HkJEDJjQaI3qKkd5npWLJ0Q1ehyhyfIVKj3cpws Bw9z5Idc2+9baNpmzA9FDfuLQHqKY+OyOgK5V8JIDGAyYTTy63Q6V3HcL37993hC9OdnTNKyjx4H 3vY74K6FjtVxTVqdd/bRB2IiYQL1J7w0VrU0klIYDIKVZy02OduEADyTqEUBd50AT2GckCEPBnPq NEAc8A5Hg14RN6APsOgXjVRzgwIGBey47K0DLoWkJeumIYtywcGqaLUch2sDGeiDDhZkqZ8lYYmv ZECUfMeXOG6YohQAklp+xnlRl3l5ECXjqliGCCmtSIbcB4ZBaEnCVmA70Ck9Pr8RpIaSNj2iVwP4 GZ9N1JbdGjDziUq6qQoo+CrwA9UGyyndBDBzTV/O1LblZVfEMVy9NOwwXG1sbFnoOmVZzgrDybpu pmJQlQhQCZsH9I1xWPmgU70GM7FZZoqwHCzTK18lDGdQxn6bDXqANkGpvkMNY8FXEnN7n0VSdVok jWqTwhizOP4grpmRTQDag0ojPVbAExkKSHn0Qbasry/sedm2TXQN8VS3OkHE9WCa2gkrAVgO6gpK 5TTkDLedTxKm7gXNEZDnjK4DGWIGCBgrYDgd/VdPKmBudUXCdnmY5wDcwaSopUYrIlQ9MrxNhLri PIQZ+QIJr+iVR4MbnYB6twlZbX8wY2euziFrWbRhww5D1o7iWF1VhBUN3ODXShFHVAOngD5K+QSC GKx9dfxE398kTa1X9//nCFCz7KD+7pLPvfbEwrk8+TzjtBndQuun3qg+jX3Ir6xIArJTGRbqpdC0 riinRjSqVmAzKtYr9GHD5+YiM0Usl/hrSK0FDPDSJuoFDHBAcLf6YUuQZQT9kGVJGCvK1MOWKBCy AUmsB96Jx1cyZFpt63q37y7QlTNl2LC/OKCnOFKCne/E6xkaK+12O/F8UQoxfoAF8ZY5myw8veSG uXEdO8j14muUI4MhPPsEcaye9lO3suddREu5W1JCp9c2Xamp0ntdvo5i7n/FsnpFve3J5JbmUu3S FmHDDm3wYNNKwbmJXb0r6m2hKTPqbRF2q+uXHLo04yyyRAHXVH5h+SkwDwfjT1Vb4yt6agTaeZOs 1mw5vVNlV2dNYmX9sdam8BRbrPhYBw1+6GWwiPBn7BcGh/Qt1/p+SXU9O1CaKXi4BFhv61lhe26y nt0m7bfJarXpT9kvqgtq7YoqbNhhpNT4WMT3vlotpEpuuVqtm1hIf/DVaqDWyBhst7vYF+3lsw+4 8rzIEDN6+o6YDKeT074uXzQ+cF1nlu21Kh1rcrHq3q0ZPM2Q8F6VnD3mYut2PGW5CBv25+acNOhM va441HNfq7e3yr/zV7AI0Q84Ji4KAcEZ2SpDBuVbkgK/Ex7E0gSAKnIsqUT7ovt/3DE8bi/IoqlN 2HDbs2TPHvsSbuiHSWMycHa0uWe03LMzDqDeoJW4IUcyXZ5ntFuYZMa1X4lF8BvikWpYgXhwIYDz BNSFwG4hEF/XsUn3bStN+r5iw57iyEjuHALxrVwVJyRuybSVRRlPW2mrfU9bT3HEBmSKgMCY6o7T VloZXWyIXJnLzow35EqY51siV8Y0KcJW7KrgXoUZt2HJAsOs4NYoZjpCtOokGj2m0bcJ6IdpIoJb s3/2NqUYvl8fmaIezXTUsD8z3VMcSUqOsvgfsnJ8EYyAsyjAoMS9yFM8xblu6h5Uvazkh5zKe0Ug UhXf0IC44T5oQJbdCTkL+IOwRT+aG3kMjk9fib7BDjFPt4AdWNCon8AISveyaXsL6ML5Hrow5pLW clUbNuwvuOopjvR159BFz9CI3hzQhatLMW1ttfNpq0thZvcNXfQMjejdFLpw255I9gZdzJsGX82m dMa97vpdnsAyGDyr9yGirjsv2jFukQLooN7PMuPIZPW0ff1qkRxVNzy0bDm0gaIjRIk4TovVxojw 9KMqblINlaOkiFeKqiVFhNj0tNHy2V9TDuSP/nbco1mdUKr97tHsKY4U+nFKefTCpRzWWAeUclhn Mki9m5fnduoXFuzkxtsVd0DPuLx8+R3Bm0CS9z32bMCY3W2OPRtDozc0TAwuBxqmfmVGKYx6mOmM HbszrqDE6Vo69AWmvkFfMU/f9hgpBTblEZTylxSgb0zYsL9oq6c4XlHuG6XqGRrRuyncUSWPiORB sokbcoIqXRxXK6NDXBKFI5nzrpnHwyneKgTkExtWCARbEGsbNuzPPJwrBNJbEHe7N0M/jW/G3ozl BxwwYMcTWOIAoTR3tLC9TEZTviITzcuhZH6Lx6WgDxmN4U5YXp+EC4aWn9c/I5JCeKbeZJ/l6OMc 8UlrYwNUGr9vA9RTPG2A9hWf9AyN6P2RrkLy1ppYr4KUgcUhPgj89Vt7KvmKVM4hyzJx4xAp069c mtOJ3II2aDSO8TFTjhAsQZoBr4AlktYhxgorURG8ytuQBscHPDsYjdx3y+3PvLAB13Rg3x6Wz3I0 Q3iB5eKiu63II7kbkhNMNl4ZoCTOPV93lawTHsNoi51tqlTwhvEb1bK567VsR1tQXky23J5YyBEy 8Zu4ZR0JOGzihlADGJ3CUqEHRjMnQ7wQPPFRfkV2yruAMXz1IjWdQQUMg3SUFLTZFmrqVrhEdD91 CRzun4VxkXPJyFyODhwyMnYftpCygA4Gamp2MRhQhqvmZB9zDFRx3UC1aSZyeCDNIZ2sqhm3Z+sS IbnqwKKgsmi93fFNFRueFWpEo4EJT+ykn2LAcjszwwAmblhYIqukFJZ56e3JUx6hqpPzIKuH+EQO 2zSDq7rIgO+JEwyn+lBN4oxOV0xmBjdLadf9bqKsa2q06AOWOZ8z/0bhtq2UbtUV6bML37xed6eC F3AENkQ15ptEVXwFIpNl7oaNqsHcJdaC3/od4+LvDAj0Di0gJxhuJKdPaC7OWg+k9SD4JuHqNrZZ VdYZcaR+/7IaEui2mZ/FNGC0e3GzS3fiTEiuM+deB/AACMQi1V1vAjO7hE1mBjJ0kxB5Bj90b7Y8 7oYpp23HK16KEMaiBxW6SK2WDwkkRXCxv/wuwKXEU3MApxkfOCmpbxNaOtz5FaipxDQZdOn2E8CE 5KCVADSe0PtIFRfglfvge/5UHTFyNtPy3bm428cxRTOMhIoKJkGgb2RrdTqVN5itnE7QtW9O8M0J fudOcMVXCGDo6nBFQVZYnscVXbdoXZl0/Kd9rK5xQ7ceHllWuyGXORSSBAyAAwaLtmhw0Ez5hJeU einNOCgTAuHl4GzWiWjPO1NLGYA5WT39PU2ElQrAmUGtAgLSTT6rrps9VBXTsAml6BT1ArcVXW/O NmSG6O7VqGwjurpReZP2R5N2ezlCQEo7xB8rZZYDodpADs/K4eEr6IM6hbnDRNxEL3UlY1yGr6CI R5VDQhqQIYRhKLyVuDtKc4lgYHCJyw+DBpnv4KIDGRF0CqHTVzKYOWQZEhjxt31F7ZSjxcyhU9Tk LTc6ut2GmbbY4raJNYRpUz/LxWA5WsPvrbK2LM6hyIz61dRdpEsqXB0qrlDGVso+EhsIYUgnKhkd diJhD5EsfAKlP06NZTkekqDXWH4/0H7dxoMnPI5UaQJHnLK/0oY7uDBoxI0OgrrKFFMaIRLQ8TtV Xc1IoH9/dVnfCK+7polnMys4VtZn2P42qkPbk1CdKXd/m7WwJH1L9PC7jFSq0sfDntxpkwiUHzFS gRykKiOhBjjGYsKY/sDRTtWUP260Mw7+TtEOjjphp7DhaqVDeBf07SOmxgmxeouYHjdi8raIZzNr xFS7pJTfJmLaUv0eNmK68Q71hNw1cWm3l6c1DbMdnp2S2LRLn91KAQgaGtEwIOxjQ+K0mLUjLWXd V56RchxyJ9sgHkGD5EXmkQ5bOsbVl5XD4DZkAFc48+FXaRlRMiU5geNeWSJTySfQh3yiKLPyylkf 293vlVfd38PXjmOmOg59+PHb69rA5dPh09O/AQ02MsJlbmRzdHJlYW0KZW5kb2JqCjg3MCAwIG9i ago1MDU3CmVuZG9iago4NzQgMCBvYmoKWzQ0IC9YWVogNDcuNTE5OTk5OSAgCjE2NC43MTk5OTkg IDBdCmVuZG9iago4NzUgMCBvYmoKWzQ0IC9YWVogNDcuNTE5OTk5OSAgCjU3Ny41MTk5OTkgIDBd CmVuZG9iago4NzYgMCBvYmoKWzQ0IC9YWVogNDcuNTE5OTk5OSAgCjQ0OS44Mzk5OTkgIDBdCmVu ZG9iago4NzcgMCBvYmoKWzQ0IC9YWVogNDcuNTE5OTk5OSAgCjMyMi4xNTk5OTkgIDBdCmVuZG9i ago4NzggMCBvYmoKWzQ0IC9YWVogNDcuNTE5OTk5OSAgCjgxMy42Nzk5OTkgIDBdCmVuZG9iago4 NzkgMCBvYmoKWzQ0IC9YWVogNDcuNTE5OTk5OSAgCjE5NS40Mzk5OTkgIDBdCmVuZG9iago4ODAg MCBvYmoKWzQ0IC9YWVogNDcuNTE5OTk5OSAgCjY3Ljc1OTk5OTkgIDBdCmVuZG9iago4ODEgMCBv YmoKWzQ0IC9YWVogNDcuNTE5OTk5OSAgCjY3NS40Mzk5OTkgIDBdCmVuZG9iago4ODIgMCBvYmoK WzQ0IC9YWVogNDcuNTE5OTk5OSAgCjU0Ny43NTk5OTkgIDBdCmVuZG9iago4ODMgMCBvYmoKWzQ0 IC9YWVogNDcuNTE5OTk5OSAgCjQyMC4wNzk5OTkgIDBdCmVuZG9iago4ODQgMCBvYmoKWzQ0IC9Y WVogNDcuNTE5OTk5OSAgCjcwNS4xOTk5OTkgIDBdCmVuZG9iago4ODUgMCBvYmoKWzQ0IC9YWVog NDcuNTE5OTk5OSAgCjI5Mi4zOTk5OTkgIDBdCmVuZG9iago4ODYgMCBvYmoKPDwKL1R5cGUgL0Fu bm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFs1MjIuNzIwMDAwICA4MDkuODM5OTk5ICA1NDMuODQw MDAwICA4MTcuNTE5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJm dmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIu aHRtbC5odG1sIzIzdG9jCj4+CmVuZG9iago4ODcgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0 eXBlIC9MaW5rCi9SZWN0IFsyNzYuOTU5OTk5ICA3NzcuMTk5OTk5ICAzNDkuOTE5OTk5ICA3ODcu NzU5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1w IzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1s IzIzcmVzcG9uc2UjMmR0eXBlCj4+CmVuZG9iago4ODggMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9T dWJ0eXBlIC9MaW5rCi9SZWN0IFszNzQuODc5OTk5ICA3NzcuMTk5OTk5ICA0MzcuMjc5OTk5ICA3 ODcuNzU5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJm dG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5o dG1sIzIzcmVzcG9uc2UjMmR0eXBlIzJkZXh0Cj4+CmVuZG9iago4ODkgMCBvYmoKPDwKL1R5cGUg L0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFs1MjIuNzIwMDAwICA2NzEuNTk5OTk5ICA1NDMu ODQwMDAwICA2NzkuMjc5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJm IzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJk djIuaHRtbC5odG1sIzIzdG9jCj4+CmVuZG9iago4OTAgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9T dWJ0eXBlIC9MaW5rCi9SZWN0IFsyMjggIDYzOCAgMjkwLjM5OTk5OSAgNjQ4LjU1OTk5OSBdCi9C b3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1 MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMyM3Njb3BlCj4+ CmVuZG9iago4OTEgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFs1 MjIuNzIwMDAwICA1NDMuOTE5OTk5ICA1NDMuODQwMDAwICA1NTEuNTk5OTk5IF0KL0JvcmRlciBb MCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRp ciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzdG9jCj4+CmVuZG9iago4 OTIgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFsyMjggIDUxMS4y Nzk5OTkgIDMwMC45NTk5OTkgIDUyMS44Mzk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2Zp bGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRm IzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjNjb2RlIzJkYXV0aHojMmRyZXEKPj4KZW5kb2JqCjg5 MyAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzMwNy42ODAwMDAg IDUxMS4yNzk5OTkgIDM4MC42Mzk5OTkgIDUyMS44Mzk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rl c3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQj MmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjNjb2RlIzJkYXV0aHojMmRyZXNwCj4+CmVu ZG9iago4OTQgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFszODcu MzYwMDAwICA1MTEuMjc5OTk5ICA0NzEuODQwMDAwICA1MjEuODM5OTk5IF0KL0JvcmRlciBbMCAw IDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMy ZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzY29kZSMyZGF1dGh6IzJkZXJy b3IKPj4KZW5kb2JqCjg5NSAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1Jl Y3QgWzY3LjY3OTk5OTkgIDQ5OC43OTk5OTkgIDE0MC42Mzk5OTkgIDUwOS4zNTk5OTkgXQovQm9y ZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAz NzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjNpbXBsaWNpdCMy ZGF1dGh6IzJkcmVxCj4+CmVuZG9iago4OTYgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBl IC9MaW5rCi9SZWN0IFsxNDcuMzU5OTk5ICA0OTguNzk5OTk5ICAyMjAuMzE5OTk5ICA1MDkuMzU5 OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJm Q0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIz aW1wbGljaXQjMmRhdXRoeiMyZHJlc3AKPj4KZW5kb2JqCjg5NyAwIG9iago8PAovVHlwZSAvQW5u b3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzI0OS4xMjAwMDAgIDQ5OC43OTk5OTkgIDMzMy42MDAw MDAgIDUwOS4zNTk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2 YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5o dG1sLmh0bWwjMjNpbXBsaWNpdCMyZGF1dGh6IzJkZXJyb3IKPj4KZW5kb2JqCjg5OCAwIG9iago8 PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzUyMi43MjAwMDAgIDQxNi4yMzk5 OTkgIDU0My44NDAwMDAgIDQyMy45MTk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUj M2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJk b2F1dGgjMmR2Mi5odG1sLmh0bWwjMjN0b2MKPj4KZW5kb2JqCjg5OSAwIG9iago8PAovVHlwZSAv QW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzI3MC4yNDAwMDAgIDM4My41OTk5OTkgIDM0My4x OTk5OTkgIDM5NC4xNTk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYj MmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2 Mi5odG1sLmh0bWwjMjNjb2RlIzJkYXV0aHojMmRyZXEKPj4KZW5kb2JqCjkwMCAwIG9iago8PAov VHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzM1MC44Nzk5OTkgIDM4My41OTk5OTkg IDQyMy44Mzk5OTkgIDM5NC4xNTk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2Ej MmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1 dGgjMmR2Mi5odG1sLmh0bWwjMjN0b2tlbiMyZHJlcQo+PgplbmRvYmoKOTAxIDAgb2JqCjw8Ci9U eXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbNjcuNjc5OTk5OSAgMzcxLjExOTk5OSAg MTQwLjYzOTk5OSAgMzgxLjY3OTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMy ZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0 aCMyZHYyLmh0bWwuaHRtbCMyM2ltcGxpY2l0IzJkYXV0aHojMmRyZXEKPj4KZW5kb2JqCjkwMiAw IG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzUyMi43MjAwMDAgIDI4 OC41NTk5OTkgIDU0My44NDAwMDAgIDI5Ni4yMzk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3Qg L2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRp ZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjN0b2MKPj4KZW5kb2JqCjkwMyAwIG9iago8PAov VHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzIyOCAgMjU1LjkxOTk5OSAgMzEyLjQ4 MDAwMCAgMjY2LjQ3OTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMy ZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYy Lmh0bWwuaHRtbCMyM2NvZGUjMmRhdXRoeiMyZGVycm9yCj4+CmVuZG9iago5MDQgMCBvYmoKPDwK L1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFszMTguMjQwMDAwICAyNTUuOTE5OTk5 ICA0MDIuNzIwMDAwICAyNjYuNDc5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNh IzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9h dXRoIzJkdjIuaHRtbC5odG1sIzIzaW1wbGljaXQjMmRhdXRoeiMyZGVycm9yCj4+CmVuZG9iago5 MDUgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFs0MDguNDc5OTk5 ICAyNTUuOTE5OTk5ICA0NzAuODc5OTk5ICAyNjYuNDc5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9E ZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0 IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzdG9rZW4jMmRlcnJvcnMKPj4KZW5kb2Jq CjkwNiAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzY3LjY3OTk5 OTkgIDI0My40Mzk5OTkgIDEzMC4wNzk5OTkgIDI1My45OTk5OTkgXQovQm9yZGVyIFswIDAgMF0K L0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJh ZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjNyZXNvdXJjZSMyZGVycm9ycwo+Pgpl bmRvYmoKOTA3IDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbMTU4 Ljg3OTk5OSAgMjQzLjQzOTk5OSAgMjIxLjI4MDAwMCAgMjUzLjk5OTk5OSBdCi9Cb3JkZXIgWzAg MCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIj MmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMyM25ldyMyZGVycm9ycwo+Pgpl bmRvYmoKOTA4IDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbNTIy LjcyMDAwMCAgMTYwLjg3OTk5OSAgNTQzLjg0MDAwMCAgMTY4LjU1OTk5OSBdCi9Cb3JkZXIgWzAg MCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIj MmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMyM3RvYwo+PgplbmRvYmoKOTA5 IDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbMzAwLjk1OTk5OSAg MTI4LjIzOTk5OSAgMzg1LjQzOTk5OSAgMTM4Ljc5OTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVz dCAvZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMy ZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMyM2NvZGUjMmRhdXRoeiMyZGVycm9yCj4+CmVu ZG9iago5MTAgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFszOTIu MTU5OTk5ICAxMjguMjM5OTk5ICA0NzYuNjM5OTk5ICAxMzguNzk5OTk5IF0KL0JvcmRlciBbMCAw IDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMy ZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzaW1wbGljaXQjMmRhdXRoeiMy ZGVycm9yCj4+CmVuZG9iago5MTEgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5r Ci9SZWN0IFs2Ny42Nzk5OTk5ICAxMTUuNzU5OTk5ICAxMzAuMDc5OTk5ICAxMjYuMzE5OTk5IF0K L0JvcmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVt cDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzdG9rZW4j MmRlcnJvcnMKPj4KZW5kb2JqCjkxMiAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xp bmsKL1JlY3QgWzE1OC44Nzk5OTkgIDExNS43NTk5OTkgIDIyMS4yODAwMDAgIDEyNi4zMTk5OTkg XQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0 ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjNyZXNv dXJjZSMyZGVycm9ycwo+PgplbmRvYmoKODczIDAgb2JqCjw8Ci9UeXBlIC9QYWdlCi9QYXJlbnQg MiAwIFIKL0NvbnRlbnRzIDkxMyAwIFIKL1Jlc291cmNlcyA5MTUgMCBSCi9Bbm5vdHMgOTE2IDAg UgovTWVkaWFCb3ggWzAgMCA1OTUgODQyXQo+PgplbmRvYmoKOTE1IDAgb2JqCjw8Ci9Db2xvclNw YWNlIDw8Ci9QQ1NwIDQgMCBSCi9DU3AgL0RldmljZVJHQgovQ1NwZyAvRGV2aWNlR3JheQo+Pgov RXh0R1N0YXRlIDw8Ci9HU2EgMyAwIFIKPj4KL1BhdHRlcm4gPDwKPj4KL0ZvbnQgPDwKL0Y2IDYg MCBSCi9GOSA5IDAgUgovRjEwIDEwIDAgUgovRjE0OSAxNDkgMCBSCj4+Ci9YT2JqZWN0IDw8Cj4+ Cj4+CmVuZG9iago5MTYgMCBvYmoKWyA4ODYgMCBSIDg4NyAwIFIgODg4IDAgUiA4ODkgMCBSIDg5 MCAwIFIgODkxIDAgUiA4OTIgMCBSIDg5MyAwIFIgODk0IDAgUiA4OTUgMCBSIDg5NiAwIFIgODk3 IDAgUiA4OTggMCBSIDg5OSAwIFIgOTAwIDAgUiA5MDEgMCBSIDkwMiAwIFIgOTAzIDAgUiA5MDQg MCBSIDkwNSAwIFIgOTA2IDAgUiA5MDcgMCBSIDkwOCAwIFIgOTA5IDAgUiA5MTAgMCBSIDkxMSAw IFIgOTEyIDAgUiBdCmVuZG9iago5MTMgMCBvYmoKPDwKL0xlbmd0aCA5MTQgMCBSCi9GaWx0ZXIg L0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQp4nO1dS2/jNhC++1foXCAJ3w+gKLDr3RTooUCQAD0seiiy 3RYLe9F0D/37pShZImdE03EoWbKdoBtlQg2H3zz4kaLcu58f/6j++l7drR//qZ7bn+vHFbkl0jZf FXHfN6GAmVvOSP1VGcpvlfbS5+3qpXpZPawe3L8vK6r8je0P98ddF8R/f3/+trprOl81ksf1r+7q v4pVv7j/vlaffnfCz62+usF2ZaxydhBCuft1E/5KmRXk1rhrJyfw17rx36vffqi+1Yax+g/1bY2B 4a83UnPuJISYN5n80t/aaq/BSl2Hil9ln5KVEEapSjiYJa/+/XP1xfXe960It4xKZZLXYd+ct32J ihGjboW75A52LqS7w31JJ7f2lnm5w19RUTeiDMqZrn/x8k7PJqG/ds2XwGbL26/kdWRzYBv1yLQ2 B31RJvw1tC2W92Pp9WwS+qHNhXBO2JyyIeWXMXAe9vU2xu0gnIdjIxVLsc0j55IkQlfceYubgrkk nNP8eFScS4I5XIiXR+MH8g6vQM8mob9YLgnGldev4rgUTFjfBtkWyYOxdHo2Cf3FcinGOWFzyoaU X8bAedjX21h+EM7DsZGKpWlziTFTUa0qVnJeUtz5rL60cS4pLoxvY+PxA3mHV6Bnk9BfLJcUV9Rf 2zguFdfeTGxbJA/G0unZJPQXy6UY54TNKRtSfhkD52Ffb2P5QTgPx0YqlqbNJW7dVK5Z2VwyQjUc mcW5ZITm9bWTR+MH8g6vQM8mob9YLhnRcIbG5rCvhjNg2yJ5MJZOzyahv1guxTgnbE7ZkPLLGDgP +3obyw/CeTg2UrE0bS5JRSomSNlcokQa7yga55KTW+PHHI8fyDu8Aj2bhP5iuUSJakgDjePSyRvS gGyL5MFYOj2bhP5iuRTjnLA5ZUPKL2PgPOzrLcDtEJyHYyMVS9PmkmZqhFximpIdXqHP3AzId74M xx/Le7x6PZuE/nK5xHRDGmBcMt2QBmxbKA/HstOzSegvl0sRzgmbUzak/DIGzsO+3gL5ITgPx0Yq lmKbd9ufFm0Gvi5vhFtJCm1d0piq22Z4OG5jkvrv0JZGktiYfNlz4/un1d29csWkevpSNRbcND+e GqNvaqtF9fS5+rE26qfq6euq3odtBcwLdC/gXmB6gYAtGh0fn9rxjwS1VaKGmsplYW21XBzWknKy QKwlFXR5WDOrlog1J3p5WAvFloi1W2QtD2vlgF4g1orb5WFdT+gOa70sqA0Za2rsYW6ebxO/Whq+ jh4HH9A+C8ZrO/VQ2TpRBqByCzNHIgKklB8lpf2433mJ6ATsHYQKtmix2yPgHyC6jUClHULXQMAa h9j+ljUQUNgC6UC98I+whfEC2XfLsnYgpWi0EA/adEtJuhs0GGQZJbBfMxCyqB7sPaPwsudGH1jO ZMqHIksyH1lcxfkTgABHmMpBaH8U82I40ZKtDhnnAR00Yxc2MXhtweBh4FHkXgHD6j1EAwqQv5EO 1Au/h0otbAGzG9nRKj1NVFHDAbKo1qDCoWHxRy0aAd3XhObqAjbkHvRLTbYMQG9gO1i2F2Qp0oF6 yZuOlAapebw3BSM5b6LEgZakRvNG0yQXsWmcv0ZtsjKopjIYmhzgaSoDLr5HV4ZAB3QWRxMwCqy5 4oF0EFhLGeQOeTwECl6Zu4XCXlj2lsvClOiSiWrnNoVPA2I+UVtyuS+WZ4uYgi3QkgbxpHXBoLJ0 9tX/eIjeFFQS3QJ7QS2QDpbthUGAGAxdCjFFLVgBOwgEWWRrO158qz4wz21bwhoVj3LvtgSCu8C2 BNowoB+Go97CwLhuBwxsB0i3GIuT4YK2A4LB44KMyi0qQPNahlMwousyHPayoGU4FyA5S651JVGs fNjvm1UnEeS5zDijzS7TsVI0dSABWkGcZp16ToiVXIVKokeYOU4OUYk1poRBxRFA6LlRgkKjWeYc ObWkksXD3supEdsdg1PnmSue5a+cuuPU9SORi+XU/eBRZcRFLPvwaw6cOnDnlVMvmFNLFXuz3RdA lfKtj9AUmaQfqc1gP29US0Wj1tpxzWdtrcz2M4NHj9wCTIoux5gYoWLOb/WVp44CtkArlit1jKgj p+YV1BEdpJrmlJiCFO4j7CWvA7FeOCHiU2Iadot6gXZcMGPlApyBvSTGGgw++/CPocV94vHDvnU4 0oEOdqAqDysjfrT34ZREWUsA5JUoL5coCwpqwlgElqrD+jmCAZYhwVztTmEXJXyCzK3g4Jp+aMGZ Ic+EG5AoRtDRATz8vF8QV0XzZN4v6FgIIq9D2x9nQl6F6d5JzZNXjgKjBHlFbkccEQng4QLU4oJZ pKTg9Z5LYpH94POVAAvQEbL1Cb3Z7nsG7rzSueXSOa5J7M2x9j2NmaSfdt8T9fNWyudfL5CS04z5 M9iPbPdOe1uL0lOpR6hkU/PE2R5CKfIE/bovupdaKgmGvY9a0lHenh2FWiK3o73V7Du6eCs1uy+K z8+iaRlt6WZf/L1gmqwM+NCSS6LJ/eBHmVzQzinaP8m/z4G3S7J7H/gVEDTxo7xLvCRymshkVILQ vFL+5VJ+oVTszbGouBGD/ZSh4srqjPnzoeK9rUWpuBajVksUwourlmdMxdOfFwT/dgDFTivbfW7P 8N4BA+/cM8g42wBBj/eRcwOCeQ+T9/0wjbPQdQGvQy0UnDfkgS1gph6LlYCfrzIXrNoA3IMEI0WR YM0JuP7tlbkgkY8aasZAIjijNxMkWo/PKX+4EueLFR0mG0fXGgXPfp4fVtNFHjqJuhgwJ4eKtoeo zxKrwknKDDxJfX5YTTg9oNNCi0FzeirqP8XrTLEqTNHaA7DdSa/lQDV5CrZsNnjyuhisZsg6OHqO vRg0Zzg9CKtmiibqdmTaAc8GzAaI/OK7LBC0PfgyPyTyGzKsKBLtq4/BPv1ckFhi4RYaPvVYDJoz LNzw+clswJy6brflaoZIvKpwF//fyFcPq/8BqVQ5K2VuZHN0cmVhbQplbmRvYmoKOTE0IDAgb2Jq CjIyMzEKZW5kb2JqCjkxOCAwIG9iagpbNDUgL1hZWiA0Ny41MTk5OTk5ICAKNjg2Ljk1OTk5OSAg MF0KZW5kb2JqCjkxOSAwIG9iagpbNDUgL1hZWiA0Ny41MTk5OTk5ICAKNTM2LjIzOTk5OSAgMF0K ZW5kb2JqCjkyMCAwIG9iagpbNDUgL1hZWiA0Ny41MTk5OTk5ICAKODEzLjY3OTk5OSAgMF0KZW5k b2JqCjkyMSAwIG9iagpbNDUgL1hZWiA0Ny41MTk5OTk5ICAKNzkuMjc5OTk5OSAgMF0KZW5kb2Jq CjkyMiAwIG9iagpbNDUgL1hZWiA0Ny41MTk5OTk5ICAKNDIwLjA3OTk5OSAgMF0KZW5kb2JqCjky MyAwIG9iagpbNDUgL1hZWiA0Ny41MTk5OTk5ICAKMzAzLjkxOTk5OSAgMF0KZW5kb2JqCjkyNCAw IG9iagpbNDUgL1hZWiA0Ny41MTk5OTk5ICAKMTY0LjcxOTk5OSAgMF0KZW5kb2JqCjkyNSAwIG9i agpbNDUgL1hZWiA0Ny41MTk5OTk5ICAKNzE2LjcxOTk5OSAgMF0KZW5kb2JqCjkyNiAwIG9iagpb NDUgL1hZWiA0Ny41MTk5OTk5ICAKNTY2ICAwXQplbmRvYmoKOTI3IDAgb2JqCls0NSAvWFlaIDQ3 LjUxOTk5OTkgIAo0OS41MTk5OTk5ICAwXQplbmRvYmoKOTI4IDAgb2JqCls0NSAvWFlaIDQ3LjUx OTk5OTkgIAo0NDkuODM5OTk5ICAwXQplbmRvYmoKOTI5IDAgb2JqCls0NSAvWFlaIDQ3LjUxOTk5 OTkgIAozMzMuNjc5OTk5ICAwXQplbmRvYmoKOTMwIDAgb2JqCls0NSAvWFlaIDQ3LjUxOTk5OTkg IAoxOTUuNDM5OTk5ICAwXQplbmRvYmoKOTMxIDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlw ZSAvTGluawovUmVjdCBbNTIyLjcyMDAwMCAgODA5LjgzOTk5OSAgNTQzLjg0MDAwMCAgODE3LjUx OTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMy ZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMy M3RvYwo+PgplbmRvYmoKOTMyIDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawov UmVjdCBbMjUyICA3NzcuMTk5OTk5ICAzMzYuNDgwMDAwICA3ODcuNzU5OTk5IF0KL0JvcmRlciBb MCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRp ciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzY29kZSMyZGF1dGh6IzJk ZXJyb3IKPj4KZW5kb2JqCjkzMyAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsK L1JlY3QgWzM0My4xOTk5OTkgIDc3Ny4xOTk5OTkgIDQyNy42Nzk5OTkgIDc4Ny43NTk5OTkgXQov Qm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1w NTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjNpbXBsaWNp dCMyZGF1dGh6IzJkZXJyb3IKPj4KZW5kb2JqCjkzNCAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1 YnR5cGUgL0xpbmsKL1JlY3QgWzQzMy40Mzk5OTkgIDc3Ny4xOTk5OTkgIDQ5NS44Mzk5OTkgIDc4 Ny43NTk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0 bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0 bWwjMjN0b2tlbiMyZGVycm9ycwo+PgplbmRvYmoKOTM1IDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAov U3VidHlwZSAvTGluawovUmVjdCBbNjcuNjc5OTk5OSAgNzY0LjcxOTk5OSAgMTMwLjA3OTk5OSAg Nzc1LjI3OTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMy ZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwu aHRtbCMyM3Jlc291cmNlIzJkZXJyb3JzCj4+CmVuZG9iago5MzYgMCBvYmoKPDwKL1R5cGUgL0Fu bm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFs1MjIuNzIwMDAwICA2ODMuMTIwMDAwICA1NDMuODQw MDAwICA2OTAuNzk5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJm dmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIu aHRtbC5odG1sIzIzdG9jCj4+CmVuZG9iago5MzcgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0 eXBlIC9MaW5rCi9SZWN0IFsyNTguNzE5OTk5ICA2NDkuNTE5OTk5ICAzMzEuNjc5OTk5ICA2NjAu MDc5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1w IzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1s IzIzdG9rZW4jMmRyZXEKPj4KZW5kb2JqCjkzOCAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5 cGUgL0xpbmsKL1JlY3QgWzMzOC4zOTk5OTkgIDY0OS41MTk5OTkgIDQxMS4zNTk5OTkgIDY2MC4w Nzk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAj MmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwj MjNwYXNzd29yZCMyZHRvayMyZHJlcQo+PgplbmRvYmoKOTM5IDAgb2JqCjw8Ci9UeXBlIC9Bbm5v dAovU3VidHlwZSAvTGluawovUmVjdCBbNDE4LjA3OTk5OSAgNjQ5LjUxOTk5OSAgNDkxLjAzOTk5 OSAgNjYwLjA3OTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZh ciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0 bWwuaHRtbCMyM2NsaWVudCMyZHJlcQo+PgplbmRvYmoKOTQwIDAgb2JqCjw8Ci9UeXBlIC9Bbm5v dAovU3VidHlwZSAvTGluawovUmVjdCBbNjcuNjc5OTk5OSAgNjM4ICAxMTkuNTE5OTk5ICA2NDgu NTU5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1w IzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1s IzIzdG9rZW4jMmRyZWZyZXNoCj4+CmVuZG9iago5NDEgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9T dWJ0eXBlIC9MaW5rCi9SZWN0IFsxNDcuMzU5OTk5ICA2MzggIDIwOS43NTk5OTkgIDY0OC41NTk5 OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZD R0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjNl eHQjMmRncmFudAo+PgplbmRvYmoKOTQyIDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAv TGluawovUmVjdCBbNTIyLjcyMDAwMCAgNTMyLjM5OTk5OSAgNTQzLjg0MDAwMCAgNTQwLjA3OTk5 OSBdCi9Cb3JkZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNH SXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMyM3Rv Ywo+PgplbmRvYmoKOTQzIDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVj dCBbMjIxLjI4MDAwMCAgNDk5Ljc1OTk5OSAgMjk0LjI0MDAwMCAgNTEwLjMxOTk5OSBdCi9Cb3Jk ZXIgWzAgMCAwXQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3 Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMyM3Rva2VuIzJkcmVx Cj4+CmVuZG9iago5NDQgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0 IFs1MjIuNzIwMDAwICA0MTYuMjM5OTk5ICA1NDMuODQwMDAwICA0MjMuOTE5OTk5IF0KL0JvcmRl ciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2 LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzdG9jCj4+CmVuZG9i ago5NDUgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFsyNzAuMjQw MDAwICAzODMuNTk5OTk5ICAzNDMuMTk5OTk5ICAzOTQuMTU5OTk5IF0KL0JvcmRlciBbMCAwIDBd Ci9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRy YWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzaW1wbGljaXQjMmRhdXRoeiMyZHJl c3AKPj4KZW5kb2JqCjk0NiAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1Jl Y3QgWzM2OS4xMjAwMDAgIDM4My41OTk5OTkgIDQzMS41MTk5OTkgIDM5NC4xNTk5OTkgXQovQm9y ZGVyIFswIDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAz NzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjN0b2tlbiMyZHJl c3BvbnNlCj4+CmVuZG9iago5NDcgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5r Ci9SZWN0IFs1MjIuNzIwMDAwICAzMDAuMDc5OTk5ICA1NDMuODQwMDAwICAzMDcuNzU5OTk5IF0K L0JvcmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVt cDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzdG9jCj4+ CmVuZG9iago5NDggMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFsy NTguNzE5OTk5ICAyNjcuNDM5OTk5ICAzMzEuNjc5OTk5ICAyNzggXQovQm9yZGVyIFswIDAgMF0K L0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJh ZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjNpbXBsaWNpdCMyZGF1dGh6IzJkcmVz cAo+PgplbmRvYmoKOTQ5IDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVj dCBbMzM4LjM5OTk5OSAgMjY3LjQzOTk5OSAgNDAwLjc5OTk5OSAgMjc4IF0KL0JvcmRlciBbMCAw IDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMy ZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzdG9rZW4jMmRyZXNwb25zZQo+ PgplbmRvYmoKOTUwIDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBb NDI4LjYzOTk5OSAgMjY3LjQzOTk5OSAgNDkxLjAzOTk5OSAgMjc4IF0KL0JvcmRlciBbMCAwIDBd Ci9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRy YWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzbmV3IzJkdHlwZXMKPj4KZW5kb2Jq Cjk1MSAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzUyMi43MjAw MDAgIDE2MC44Nzk5OTkgIDU0My44NDAwMDAgIDE2OC41NTk5OTkgXQovQm9yZGVyIFswIDAgMF0K L0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJh ZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjN0b2MKPj4KZW5kb2JqCjk1MiAwIG9i ago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzI1OC43MTk5OTkgIDEyOC4y Mzk5OTkgIDMzMS42Nzk5OTkgIDEzOC43OTk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2Zp bGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRm IzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjNpbXBsaWNpdCMyZGF1dGh6IzJkcmVzcAo+PgplbmRv YmoKOTUzIDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbMzU2LjYz OTk5OSAgMTI4LjIzOTk5OSAgNDE5LjAzOTk5OSAgMTM4Ljc5OTk5OSBdCi9Cb3JkZXIgWzAgMCAw XQovRGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZk cmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMyM3Rva2VuIzJkcmVzcG9uc2UKPj4K ZW5kb2JqCjk1NCAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzUy Mi43MjAwMDAgIDQ1LjY3OTk5OTkgIDU0My44NDAwMDAgIDUzLjM1OTk5OTkgXQovQm9yZGVyIFsw IDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGly IzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjN0b2MKPj4KZW5kb2JqCjkx NyAwIG9iago8PAovVHlwZSAvUGFnZQovUGFyZW50IDIgMCBSCi9Db250ZW50cyA5NTUgMCBSCi9S ZXNvdXJjZXMgOTU3IDAgUgovQW5ub3RzIDk1OCAwIFIKL01lZGlhQm94IFswIDAgNTk1IDg0Ml0K Pj4KZW5kb2JqCjk1NyAwIG9iago8PAovQ29sb3JTcGFjZSA8PAovUENTcCA0IDAgUgovQ1NwIC9E ZXZpY2VSR0IKL0NTcGcgL0RldmljZUdyYXkKPj4KL0V4dEdTdGF0ZSA8PAovR1NhIDMgMCBSCj4+ Ci9QYXR0ZXJuIDw8Cj4+Ci9Gb250IDw8Ci9GNiA2IDAgUgovRjkgOSAwIFIKL0YxMCAxMCAwIFIK L0YxNDkgMTQ5IDAgUgo+PgovWE9iamVjdCA8PAo+Pgo+PgplbmRvYmoKOTU4IDAgb2JqClsgOTMx IDAgUiA5MzIgMCBSIDkzMyAwIFIgOTM0IDAgUiA5MzUgMCBSIDkzNiAwIFIgOTM3IDAgUiA5Mzgg MCBSIDkzOSAwIFIgOTQwIDAgUiA5NDEgMCBSIDk0MiAwIFIgOTQzIDAgUiA5NDQgMCBSIDk0NSAw IFIgOTQ2IDAgUiA5NDcgMCBSIDk0OCAwIFIgOTQ5IDAgUiA5NTAgMCBSIDk1MSAwIFIgOTUyIDAg UiA5NTMgMCBSIDk1NCAwIFIgXQplbmRvYmoKOTU1IDAgb2JqCjw8Ci9MZW5ndGggOTU2IDAgUgov RmlsdGVyIC9GbGF0ZURlY29kZQo+PgpzdHJlYW0KeJztXUtv4zYQvvtX6FwgCYcvkUBRYDe7KdBD gSABeih6KHa7LRb2omkP/fuVKFkiZ0RTtilFip0gG3tCz+ObB4cUpb378en34s9/i7v7p7+LT+3v +6cNu2XKNl8Fq75vfAI3t4Kz+qswIG516aifdpuX4mXzuHms/n3ZgHYfbH9Vf9yLYO7730/fNneN 8E1Debr/uXr1X8GLn6qfr8Wvv1XEzy2/esBuY6yu9GAMRPV2678FwQzc6up1RWf4bT34r80v3xXf asX4rXHKQ6Og//ZGGc1VTTFnqfzSf7TlXoMVe+0zPko/rQqpjOUFL6sfUfzzx+ZLJb2XrZmwHJQ2 0de+bCFaWbIAY+WtrF7yCnYhVY0lY6oAy8pb7ugV/hrcIOCYzt2bmt7z2Ub416754ulsRfsVfR3o 7OvGXTg0OnuybPsa6xbSPVs6PtsIf6xzJpwjOsd0iPllCpyHfb0L6aNwHo6NWCyFOk+cS5opUwjN CpUzl6Rkwtmjw1ySErTzpQ7tR/QOL4/PNsI/Wy5JWRV5s9fZlyVdXaW6BXTPlo7PNsI/Wy6FOEd0 jukQ88sUOA/7ehfSR+E8HBuxWJo3l7iwBZQ677ykhWjssWEuaSEbX9rQfkTv8PL4bCP8s+WSFrrx mQ3jUouyqX9Et4Du2dLx2Ub4Z8ulEOeIzjEdYn6ZAudhX+9C+iich2MjFkvz5pKwrJ768+aS4drZ A6jHM7ztndG8jOgdXh6fbYR/tlwy3O7VCeLSCLZXJ9QtpHu2dHy2Ef7ZcinEOaJzTIeYX6bAedjX QS6NxHk4NmKxNG8uKQn5ezyoOkfVLDjD9VK1ajbOZtTjhvS+J+75bCP8862XmAZwctHag2ku3boa 6xbQPVs6PtsI/3zrpQDniM4xHWJ+mQLnYV/vEG5jcB6OjVgszZtLJa/EV97Ku/fAFXR4+T7jSnS+ 9O0P6T1ePZ9thH++XOJKtj7bIVlKuwJIdPPpvi1yMI59eq5cCnCO6BzTIeaXKXAe9vUO0cfgPBwb sVgKdd5vf1qyGXhc3khZb9pVf+KmMPu0eTxtYxLct69LQ4lsTL4c+OD7583dg66KSfH8pWg0uGl+ PTdK39Raq+L5c/F9rdQPxfPXTb0P2xK4I5Q9QTiC6QkSj2h4fHxu7Z8IalvN9RXUoNaFtS1hdVjr qtysEGsNulwf1lXHvUasBZj1YV2VvjViLbVdH9Za2DVirRVbH9alXePcqOvuaRqse5ybC9zMLZeG XwfXg0eMT4JxrFAHla29NwAV165jA723UjsrAXq73zmK7AiCQIVHtNgdIIgPSfybEfoA4d4RbHyE +IiZlqmPsI9JTbEt0HwEWEfhHMkFwHKNI6h+BEMfEWYg3EgyHzxg8HLggy4ooD4CMRQViruokKjf 8UDAFsbyB+sfxKscTpLoqDF2jhDQ2C5txPjShsYDsfU+SXifGiEe8AiTZPrhFSMCFKCQIDmOIwBK XHTJiIYAh4bAME595lBFHpBcMMkUtqlwboPgkBSiKeFBpKRVJ0y9tDrdm5KhBOcwXLHPlKM4m0WO hpFyPAJOLwJ1664zVQPR7IloEU6fI9lGq5R2VcqySasUrepjq5RHICG8EIIgqpMRKhUjPFk4aJxh R3GMadqVZARpH0APf+RNtq/W8PHtK8fI0DTI0M9ykeo0qcuSTSLtZ/EI0nlywhQH6OU2uLo+Enyp Da5nPA0rUhlxt0q8yXAhpA0uGfEOxypOxMGaNVeIgEIwXTveFXe8wurQm1N1vIzNIkczOSjn3G6V N+pzm1D/hEY6t0u5MKGuOTtrzcpJyyOdTk4uj+e1uLMYRz+CmXKsR9o4frH9+/nBbcz6/T8iuLFn JNY0i2LEWrLCwKlMpLSo5/EuMLFM8/KuzlWy/aAjjq8hhIfAMTSNFAxhDikchwMpf4DnGDKCZ9CD 4QiSOAo5rtycxJjuM+aN7WdoKE1o5VH7GXSDI8N+BpBtPXz1rS0L152GoZ0GztARi0vaaeiNp1MH qTej9i3nch4AIO9d9wCQlDXtAUgTejPrgpEreXaUH9MgvdY1kWRPLcl6iPSYWEpsdicZ8Sane9Ht YJx0+YLkV47pnqxH8fxPGwKS+GTVSw5BJK9n0C4DN4ax2mnjxl1O21HfwHaxbYdnPNnCIOUlWZBB pgjpKx50HiBSIhtDr9T+lAoBeW1/1tv+SMA1YTFb+aqdCDvVsnZmsr8faZZCkN7bP70QXHu3ZfVu 0iCzj9uqIdjlOEo9SRN1PXqStTNTgO5NuKTOzDN+isr4Vo6eeDBd+6719l3t0ZPemxMdCZFmpJwF NHzt8ZVe16wNn1Ld7UyTdF4LObuRRez1qMaRPGY+qqHK6Fy5WHdfj2qM9q7RyzQvr3evRzWOlXI9 qrGO9b/WEFp53Pqf4D/FrdSkttKVOb7rmd4Xnby6Q3cIMNPrlZl+/a8tD1Puktb/vfG0Q8OXFUlP Q28wTLds6Us15PLmq153UQim6/ofS1nf+v+QN1/tuou7b9pTLesyvBTRm5PnSfPYQ0UOLSqmWLpk bObeZBNl4Jz7d0ksZWmi8JNiSL+TfmIN6Uzo1kG6Ji+qRzrwWCn8txFxFGe2f7rT8H1fFj+8Ap88 bisD6W89X1nc3z7gEHk/DJlHAIRhm+beCI2nT5Ua0dawNA9cok9FU5JHZ6wGzTRWs6OpuFkomkRs BKt8SISPPVkMEGTExEAIckfwUpDIUa5MVqwkuat5NVjB3HGlmFkrVqNLe9Zi5N/VvhSo8ppZP1d5 mXamQ2L4mtnJPSK+7Wo9SMxedAWgw5frwWp0B5htgmqfTr08rJL9XeZOt21rvNMmS0FigVGDT7ss Bqu5o0ZxvlAk3r1O/vRbr4tBYoH541bVS8TqqPzJ/n9eF4+b/wE4wX8KZW5kc3RyZWFtCmVuZG9i ago5NTYgMCBvYmoKMjE3OAplbmRvYmoKOTYwIDAgb2JqCls0NiAvWFlaIDQ3LjUxOTk5OTkgIAo0 ODYuMzE5OTk5ICAwXQplbmRvYmoKOTYxIDAgb2JqCls0NiAvWFlaIDQ3LjUxOTk5OTkgIAozNTku NTk5OTk5ICAwXQplbmRvYmoKOTYyIDAgb2JqCls0NiAvWFlaIDQ3LjUxOTk5OTkgIAo3NDguMzk5 OTk5ICAwXQplbmRvYmoKOTYzIDAgb2JqCls0NiAvWFlaIDQ3LjUxOTk5OTkgIAo2MzIuMjQwMDAw ICAwXQplbmRvYmoKOTY0IDAgb2JqCls0NiAvWFlaIDQ3LjUxOTk5OTkgIAo1MTYuMDc5OTk5ICAw XQplbmRvYmoKOTY1IDAgb2JqCls0NiAvWFlaIDQ3LjUxOTk5OTkgIAozODkuMzU5OTk5ICAwXQpl bmRvYmoKOTY2IDAgb2JqCls0NiAvWFlaIDQ3LjUxOTk5OTkgIAo3MTcuNjc5OTk5ICAwXQplbmRv YmoKOTY3IDAgb2JqCls0NiAvWFlaIDQ3LjUxOTk5OTkgIAo2MDIuNDc5OTk5ICAwXQplbmRvYmoK OTY4IDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBbMjQ2LjIzOTk5 OSAgNzk3LjM1OTk5OSAgMzE5LjE5OTk5OSAgODA3LjkxOTk5OSBdCi9Cb3JkZXIgWzAgMCAwXQov RGVzdCAvZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFm dCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMyM3Bhc3N3b3JkIzJkdG9rIzJkcmVxCj4+ CmVuZG9iago5NjkgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFs1 MjIuNzIwMDAwICA3MTMuODM5OTk5ICA1NDMuODQwMDAwICA3MjEuNTE5OTk5IF0KL0JvcmRlciBb MCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRp ciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzdG9jCj4+CmVuZG9iago5 NzAgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFsyNDYuMjM5OTk5 ICA2ODEuMTk5OTk5ICAzMTkuMTk5OTk5ICA2OTEuNzU5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9E ZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0 IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzcGFzc3dvcmQjMmR0b2sjMmRyZXEKPj4K ZW5kb2JqCjk3MSAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzUy Mi43MjAwMDAgIDU5OC42Mzk5OTkgIDU0My44NDAwMDAgIDYwNi4zMTk5OTkgXQovQm9yZGVyIFsw IDAgMF0KL0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGly IzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjN0b2MKPj4KZW5kb2JqCjk3 MiAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzI3Ni45NTk5OTkg IDU2NS4wMzk5OTkgIDMzOS4zNTk5OTkgIDU3NS41OTk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rl c3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQj MmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjN0b2tlbiMyZHJlc3BvbnNlCj4+CmVuZG9i ago5NzMgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFszNjQuMzE5 OTk5ICA1NjUuMDM5OTk5ICA0MTYuMTU5OTk5ICA1NzUuNTk5OTk5IF0KL0JvcmRlciBbMCAwIDBd Ci9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRy YWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzdG9rZW4jMmRyZWZyZXNoCj4+CmVu ZG9iago5NzQgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFs1MjIu NzIwMDAwICA0ODIuNDc5OTk5ICA1NDMuODQwMDAwICA0OTAuMTU5OTk5IF0KL0JvcmRlciBbMCAw IDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMy ZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzdG9jCj4+CmVuZG9iago5NzUg MCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFszMzAuNzE5OTk5ICA0 NDkuODM5OTk5ICAzOTMuMTE5OTk5ICA0NjAuMzk5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0 IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJk aWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzZW5kcG9pbnQjMmRwYXJhbXMKPj4KZW5kb2Jq Cjk3NiAwIG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzUyMi43MjAw MDAgIDM1NS43NTk5OTkgIDU0My44NDAwMDAgIDM2My40Mzk5OTkgXQovQm9yZGVyIFswIDAgMF0K L0Rlc3QgL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJh ZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjN0b2MKPj4KZW5kb2JqCjk3NyAwIG9i ago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzM3MC4wNzk5OTkgIDMxMS41 OTk5OTkgIDQyOC42Mzk5OTkgIDMyMi4xNTk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0Rlc3QgL2Zp bGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRm IzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjNSRkM1ODQ5Cj4+CmVuZG9iago5NzggMCBvYmoKPDwK L1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFsyODguNDgwMDAwICAzMDAuMDc5OTk5 ICA0MzMuNDQwMDAwICAzMTAuNjM5OTk5IF0KL0JvcmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNh IzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9h dXRoIzJkdjIuaHRtbC5odG1sIzIzSSMyZEQuZHJhZnQjMmRoYXJkdCMyZG9hdXRoIzJkMDEKPj4K ZW5kb2JqCjk1OSAwIG9iago8PAovVHlwZSAvUGFnZQovUGFyZW50IDIgMCBSCi9Db250ZW50cyA5 NzkgMCBSCi9SZXNvdXJjZXMgOTgxIDAgUgovQW5ub3RzIDk4MiAwIFIKL01lZGlhQm94IFswIDAg NTk1IDg0Ml0KPj4KZW5kb2JqCjk4MSAwIG9iago8PAovQ29sb3JTcGFjZSA8PAovUENTcCA0IDAg UgovQ1NwIC9EZXZpY2VSR0IKL0NTcGcgL0RldmljZUdyYXkKPj4KL0V4dEdTdGF0ZSA8PAovR1Nh IDMgMCBSCj4+Ci9QYXR0ZXJuIDw8Cj4+Ci9Gb250IDw8Ci9GNiA2IDAgUgovRjEwIDEwIDAgUgov RjE0OSAxNDkgMCBSCi9GOSA5IDAgUgovRjI0MyAyNDMgMCBSCj4+Ci9YT2JqZWN0IDw8Cj4+Cj4+ CmVuZG9iago5ODIgMCBvYmoKWyA5NjggMCBSIDk2OSAwIFIgOTcwIDAgUiA5NzEgMCBSIDk3MiAw IFIgOTczIDAgUiA5NzQgMCBSIDk3NSAwIFIgOTc2IDAgUiA5NzcgMCBSIDk3OCAwIFIgXQplbmRv YmoKOTc5IDAgb2JqCjw8Ci9MZW5ndGggOTgwIDAgUgovRmlsdGVyIC9GbGF0ZURlY29kZQo+Pgpz dHJlYW0KeJztXU1vHLkRvc+v6HMAy/zqLyAIIMveAHtYwLCAHBZ7COw4gSEtouxh/356plsz3fWa /UgOWzMjjYRdSXQPWVVkVb0qFtnv//7ln8W//yje3335b/F1+Hn3ZaNuVNn2X4Xqvt+NG0xzY43a fhWNtjdVvWv9+rh5Kp42nzefu/8/bXS1++Dwo/vH5yHU7vuPr79v3veDb/qWL3e/dL/9WZji5+6/ H8Wvv3WN34b+tg88bpq26uhQStvuz4fxn9qqRt9U3e9du5J/bh/+z+Yffyl+3xJmbpod8boncPzn u45Ha92NU81RJD8dPjr0vhWW7/dxx1H0VWXhqqa2hXGqMLb4378237vRD2NXyrZGl1Xj/X08trXD WK4TYNVu5adMJ3bryt3vquzaG9ONvm3v5F/pLSlKG9lu6hsztO/7efD0v52a7yOaOwb7L+/vE5rH tLXldtie5tFYnbS2ywRom7aPeNn38+DpX9KcSc4emn00+OZlDTnPz/XjpD1MzvNrw7eWpjSvrEu1 Mi6/Llmren7cVJes1f1cuin/on0vr1E/D57+s+lS130/Z266LjuB9dIG2ibtI172/Tx4+s+mS1M5 e2j20eCblzXkPD/Xj9P2IDnPrw3fWnpZXdJ1WXQj59Wl0tien3qqS6Vx/VzWU/5F+15eo34ePP1n 06XSVL1U6+m6LE1td88AbZP2ES/7fh48/WfTpamcPTT7aPDNyxpynp/rx2l7kJzn14ZvLb2sLlnT maVKFbbJqEu1dT3LaqpLtR1gtZryL9r38hr18+DpP5su1bbe9d/TPB6r2T2jtaRt0j7iZd/Pg6f/ bLo0lbOHZh8NvnlZQ87zc/04bQ+S8/za8K2lKc3PYWYLQVec3jjXBUet0124WujyWW8+p0WAevc9 JqZv8USATwsf/HC/ef9TVXSc338vegre9T/ue6rfdWSXprj/Vvx1S9Tfivsfm23AOzSYXUN9aLC7 hubQ4OQTfR+f7gf+15F1rVpzgbKutbKXJ2vj7CXK2pTu8mS9/eMCZe10u5KsE9NiTwsf3DGkt4m7 OY46a9gZxcYJRa0lQw1lSNJ/Y0Zozc2iNf9TIXwGDNDz7loP83UrmG8Ea9rJBpDGnXxCySd+Eg3m 03ynp1kAuuN+KoSeZ+efcF3LRQ9P9A166REt5dQLv5TryklJHjrVjVys8iO6Zat3EP7SKEAp9AGj cNKh05EWpc+mbdR0Nq2N6darKVWvKU1zFpoy+ogUo5WjwBNOTpYtRUMpG4z8iAZeavkRyZyRiwZG gT5gFCN5gVXkQGLQx60UUDXf6dQcTYzt/O8TYxXwPDdlkYPu1nC7RRMzK9hUO/Rf2SnbWh8EcSuU 1kjJwHqEj6Diywb7UdisYVJbv17gaoOGfpQu+hPaduhV9eNWh89U4gmgDK1pz79WB+KlQmrJDZh1 YM82J8c/bSvA81vCPwfmzQdmkdHMQ4P0DAo6BZNUnR7/jFbAFf9cPP45zGZO/FMr256FplzxzxX/ JOGfWms3ZTsK/1hQ2gz4B4CJz96WMR8BNTAS7QCWA/srIZSWK9Zn1K+YarvUXPlmMdWYeTCVknkD foB+BHyJklbNSn+kwEdLb4PrDhrUKYFaY4Vkr0DtcoGaUxWbTdAC8P4ebo4krZSkZcWQug1X81Us A9rafJbhKGBqJbeAVB1kHa9wbxHumaqcsh0F9zTILgHulRLeAJqBRBRkxDCZ9UmaTwqRgLIhqBlT BosYcmaQmuP+AymBJwDOvhmQaNrqaJA4EpN0s4M5qKWUOOqH8HjJd4Nn/ihH+cRWY4DvdnKCOf6h HlNDygFI54CAqhqOAs4ABASeLoumyWE4MLtiOY7l6mqqy1kBk3V7m0eTbriu6JYiyvU025Ic/WQh DLiFjCI4fY+QM81uWZ4newtTlTC7JVVnfEI2mPhRrFxD64wiRZhjFEwgU98FT0C+OIEOiBcgxWwg Xe6JOV5liOGs4HIUYgCQR2RPM6gQHQD2B8uJQcitpCwhkkH2tMRKkCBGUA45Zdi5H5bTEqyDgMlS sQbnuZYCiLuZZQxmf9V4wVV6qqhHxQsBAEk+gRgTnvDsjdkFOiBIVrDq5eYYEgL8wzCAGEELAGFx KA/IHSIIoBT0xrMnFCNDjP2AUljxMCysB47ToQ/wKHzFALcenD7iFoJBWHU8suERBV/98VEJQDII 0jFVcwf6AXk+ReeSUmYgd8pXDI30cVg624OXXPBFCGv59CfEj/HrEn0GLNSPBydytDeonyPOALMk +ecrBicXKhR4LgAIgz5AH8DWncboAHNDWL+EkbhT4k75ZZwh1KOkOEPutwB3zSAxWBHxKITb0Lfg H482KnZqVbghPt0mZdlOaX0htRkKWsZBHnhNOa7+KaPJb58DAKsk8aeSQEDWKQFqgGuh3gixBygf t745RMa3P8BMgDN+GRgNyT8azQSYPF51Ap5Vy2EzGbRmqjMBaY8MYbX9INcQ9yx0LQf7wCxmZlsD MmgqKEQ8cAqIRehO1ctAPA4bAubyXANelDrfdQRtT46Aj1yXpi8sPCzMhDgalZuHryBVLgA6mUM+ dgk3Q7I/XmNSSIdR5Ec4JHQa8AHd7da0xgB7Bb1zSuIf9ETxu/sByQhwouAyuIvkFS8BYVL8ZAXj 9zxexewdMWBkXlVBYRbSTi2CNSBmkAjoBE9w87y6B4gcKWZdlULOOXYJYLvlo2hAKRpeNHR1rJkc 61Gp5RlrzVMY9Gh7QCU6RIRyUXGsPhxhiZp+HmbeZrR3TtyTcpweXhOD18TgOZi7C9o44/kNCoBC oBkv1gwp36RFsunZ1oU+1klwrTi9R5rmSqmpbT4iYMnjJSpxJnWpBMWznbiEij1VYQuOdWa/GRQ6 PoRDD0+BNJpRrgEyk5rELq/P5iueGhIUCN9w5RXt0nwH8A/J+BwQkBcCBGBRigFT0pOARemiCpCh nEs+SkLNewL7KA+pqJw5zFcBYZ7z5lGkw2KXIsSSBepDfcwda7n7w7gH0426nGAgYO5CT1bk8UP1 gkfk/hymgroMXJoJtovLnRcockvNi+R5kV+8UXE8EgGPGW/cOLcBo/DaIRAQYJtb0RCQ80UjQtUO S+cS7F88PggIRAPiCgqQoCFAhS46SFrLwKt2ahPR0OTY9+HBGDdnUNjHZxy0Brw1r1hosoi59zz7 66pCPA/ka/h2M8xMgg2gyUYQYkr9RXx8k64iSxULAcdPwVthfhJWs5wZPMbNi0ekIc0S4L2t+ulV TH7AIuLRK53+l3IArhGmKWW3gaNEfktwgty5zPjB0Ryby7TcwlfmkMWrVKr1Sog60YQ9XRDquUQv wH5ChR5nH/2yTDQkWO4sGW9aa4DLkBcOgEzRQfJNEFDDjJuPla29eni2m49HlFcvwazrFh/R7gve 4uN7FTAPfK8iIHwNQGr8orzrht4J/OGLZvOOteVtOzXmDl6ww3NRHuLzuJn9+8SQMrp7gyWbASef 43Umy47n2ViRU6EmngSOz4gFhAiIq3KCpMZPCa/ijT898KqBR4KAchyYDaiJiC9WCDj3dMGHf2fO 8CXILD4iDnEA/D4N2Cfm9YiwRLhy85IHvv7B7IIPARsKzPHL9BLqk2F106xywtmpFB0CzxVfBB5Q JZCnkMxo4UJe9DBF1ZbhS4RGbykuIyEkSLgIk853gMekw/J0p69QfAlUfmD24FQCopU2fNgAFJrD t9OrZQNgKXwEvEEGTxZg/KkSpmxCARrgNQPcX/DyfX5ci+8gwy0BHNnkuASWVy7RfNlawX5ZC8sO yx9opRIJuCuJRrbndpCw1n5dTthRzaD+L4MwUXX5/iGPOONTjAn5hIRLwkMubeS0r+KF4itM3vgN fnFXYhPtt8+v4T2b04uYLeOnhrH8Lb78FcdFnUlQXpBI/J4qmkyOuWlkmyIQzi3f6wDjTodFY8ar vWmF7PXkDhV7PNpLOacTX4Z9ogLDgA01et9BekleHmtf2nBmcuwOwpoKsNzSUyPozrdkjr0jog8y DmLFUhZepUhNVYpYeUxJIeNK19PweJjG1AH889vquKfKcILmNZ1cw+oh2SkvheTnshNOoQCkOJdi wRMddQq5VRLio1DHlMcPVY1PRPy2roTSx+uhS/BctRMTARpBL9oKCMN5fhBgKMgdt3Ep7jpRbBMS QsjPpPjQgAvJrxbwfnlPHhdv/BvfUk57JtzWebnV8jlOv6YcyZGbhQhMPOg3j3dr9lEWpANAhtKZ oR2i4Q8/krKWE9HtlN+ZEhQglscd8UllkHPA2SfYlObJzQynA7E0DtY7Px2Iy4q7poC3OGW4ugOB FmAiniJPYJfHkPGvZ0o4+of4Lt5mzugQR2LxNiLlNtp85dJL/F9y6XOOm0syHgav2+YIEWHkldFm HO16GsEgf2sPL6nlWJTeEZGAGlMKN/kWCGRF+KHCBBOImXb+XiNeZJXjSowcFu91HWUISK3R7GRA 9QZyx5MttLDgdV8dfjZ7776bg7N4o0bvt0nWuG14JU/TuintiOC5xY+/wOhFJbTyxmnA1Vt8F/Bk L0vgxGcwALi3Qi8559VIAbxwjAQC4sdb4xNHWa5Z4iezc9wyxQvcUqBJfAI7YMUA3gu4FZzuvQZI JP7aHfyI5+q1PH7IPAcN15fYMNIzwM4ADIVmR95fyK97S5GypCPFDiWYHe79M6TRErw/v0It4LRL glvmFy9znUrZ8uM5Ia4xNGIKiP8DgAvtNUu2kjq3kMk8m2vHhvseDuYe0W3A1XweVJ3HEzkbIVhe Fpxhg+LNvXIsy0Wi/IQvL0hLSAogqVCSlbJXnlD5wTF/wKWXAVkQSklK1R6PLaj7TVGBgFCKp0pR rPH3D+Uol3nd75hbyUNVupy6gYB0eoLqjWKnPaU3nXfsv4Bm+W9f7n7ZqOLPwhQ/d//9KH79rWv8 NmZ7obOdACrfi0ibbXKtOvAPqjgEgpCzHk1vP9+VFMhoruDKykY2aOknlXyikj4P+oAn5pfIkbJq 95eoXmXllZU1u6StduW5yQqGlZJQ829DSpWEs82ZSiLzjPdpetN637V9Kj5vX3jtO1ftXtReP0ti AB4HtjQibUBATj4CKxcYAzsAm0lDaUe2Obft9JX0wOngPWMHNJ0/8gzpxJBqPi+ZzFLppv3bClAj WAzcpL6VM34np8ZKSc3fKJAuKafqVSXltJn2r+V6BKZBLDOSyy6G0qwrhlKKGU6ggRhgj1faPT2/ 6XuEFNp11aZUUm1qyWO5YIu67+Kpo0NXuw6HH18fF3B93+JBxp+Lz5v/Azz7vL9lbmRzdHJlYW0K ZW5kb2JqCjk4MCAwIG9iagozOTc0CmVuZG9iago5ODQgMCBvYmoKWzQ3IC9YWVogNDcuNTE5OTk5 OSAgCjQ5MS4xMTk5OTkgIDBdCmVuZG9iago5ODUgMCBvYmoKWzQ3IC9YWVogNDcuNTE5OTk5OSAg CjY4My4xMTk5OTkgIDBdCmVuZG9iago5ODYgMCBvYmoKWzQ3IC9YWVogNDcuNTE5OTk5OSAgCjQ2 MC4zOTk5OTkgIDBdCmVuZG9iago5ODcgMCBvYmoKWzQ3IC9YWVogNDcuNTE5OTk5OSAgCjcxMy44 Mzk5OTkgIDBdCmVuZG9iago5ODggMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5r Ci9SZWN0IFs1MjIuNzIwMDAwICA2NzkuMjc5OTk5ICA1NDMuODQwMDAwICA2ODYuOTU5OTk5IF0K L0JvcmRlciBbMCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVt cDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzdG9jCj4+ CmVuZG9iago5ODkgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFs1 MjIuNzIwMDAwICA0NTYuNTU5OTk5ICA1NDMuODQwMDAwICA0NjQuMjM5OTk5IF0KL0JvcmRlciBb MCAwIDBdCi9EZXN0IC9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRp ciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzdG9jCj4+CmVuZG9iago5 OTAgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFsxMzEuMDM5OTk5 ICA0MTcuMTk5OTk5ICAyMjggIDQyNC44Nzk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0EgPDwKL1R5 cGUgL0FjdGlvbgovUyAvVVJJCi9VUkkgKG1haWx0bzplcmFuQGh1ZW5pdmVyc2UuY29tKQo+Pgo+ PgplbmRvYmoKOTkxIDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovUmVjdCBb MTMxLjAzOTk5OSAgNDA3LjU5OTk5OSAgMjI4ICA0MTUuMjc5OTk5IF0KL0JvcmRlciBbMCAwIDBd Ci9BIDw8Ci9UeXBlIC9BY3Rpb24KL1MgL1VSSQovVVJJIChodHRwOi8vaHVlbml2ZXJzZS5jb20p Cj4+Cj4+CmVuZG9iago5OTIgMCBvYmoKPDwKL1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9S ZWN0IFsxMzEuMDM5OTk5ICAzNjguMjM5OTk5ICAxNzcuMTIwMDAwICAzNzUuOTE5OTk5IF0KL0Jv cmRlciBbMCAwIDBdCi9BIDw8Ci9UeXBlIC9BY3Rpb24KL1MgL1VSSQovVVJJIChtYWlsdG86ZHJA ZmIuY29tKQo+Pgo+PgplbmRvYmoKOTkzIDAgb2JqCjw8Ci9UeXBlIC9Bbm5vdAovU3VidHlwZSAv TGluawovUmVjdCBbMTMxLjAzOTk5OSAgMzU5LjU5OTk5OSAgMjY5LjI3OTk5OSAgMzY3LjI3OTk5 OSBdCi9Cb3JkZXIgWzAgMCAwXQovQSA8PAovVHlwZSAvQWN0aW9uCi9TIC9VUkkKL1VSSSAoaHR0 cDovL3d3dy5kYXZpZHJlY29yZG9uLmNvbS8pCj4+Cj4+CmVuZG9iago5OTQgMCBvYmoKPDwKL1R5 cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9SZWN0IFsxMzEuMDM5OTk5ICAzMjAuMjM5OTk5ICAy MjggIDMyNy45MTk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0EgPDwKL1R5cGUgL0FjdGlvbgovUyAv VVJJCi9VUkkgKG1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbSkKPj4KPj4KZW5kb2JqCjk5NSAw IG9iago8PAovVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL1JlY3QgWzEzMS4wMzk5OTkgIDMx MC42Mzk5OTkgIDIyMC4zMTk5OTkgIDMxOC4zMTk5OTkgXQovQm9yZGVyIFswIDAgMF0KL0EgPDwK L1R5cGUgL0FjdGlvbgovUyAvVVJJCi9VUkkgKGh0dHA6Ly9kaWNraGFyZHQub3JnLykKPj4KPj4K ZW5kb2JqCjk5OCAwIG9iago8PC9UaXRsZSAo/v8AQQBiAHMAdAByAGEAYwB0KQogIC9QYXJlbnQg OTk3IDAgUgogIC9EZXN0IC9fX1dLQU5DSE9SXzQKICAvQ291bnQgMAogIC9OZXh0IDk5OSAwIFIK Pj4KZW5kb2JqCjk5OSAwIG9iago8PC9UaXRsZSAo/v8AUwB0AGEAdAB1AHMAIABvAGYAIAB0AGgA aQBzACAATQBlAG0AbykKICAvUGFyZW50IDk5NyAwIFIKICAvRGVzdCAvX19XS0FOQ0hPUl82CiAg L0NvdW50IDAKICAvTmV4dCAxMDAwIDAgUgogIC9QcmV2IDk5OCAwIFIKPj4KZW5kb2JqCjEwMDAg MCBvYmoKPDwvVGl0bGUgKP7/AEMAbwBwAHkAcgBpAGcAaAB0ACAATgBvAHQAaQBjAGUpCiAgL1Bh cmVudCA5OTcgMCBSCiAgL0Rlc3QgL19fV0tBTkNIT1JfOAogIC9Db3VudCAwCiAgL05leHQgMTAw MSAwIFIKICAvUHJldiA5OTkgMCBSCj4+CmVuZG9iagoxMDAxIDAgb2JqCjw8L1RpdGxlICj+/wBU AGEAYgBsAGUAIABvAGYAIABDAG8AbgB0AGUAbgB0AHMpCiAgL1BhcmVudCA5OTcgMCBSCiAgL0Rl c3QgL19fV0tBTkNIT1JfYQogIC9Db3VudCAwCiAgL05leHQgMTAwMiAwIFIKICAvUHJldiAxMDAw IDAgUgo+PgplbmRvYmoKMTAwMiAwIG9iago8PC9UaXRsZSAo/v8AMQAuAKAAIABJAG4AdAByAG8A ZAB1AGMAdABpAG8AbikKICAvUGFyZW50IDk5NyAwIFIKICAvRGVzdCAvX19XS0FOQ0hPUl9jCiAg L0NvdW50IDAKICAvTmV4dCAxMDAzIDAgUgogIC9QcmV2IDEwMDEgMCBSCj4+CmVuZG9iagoxMDAz IDAgb2JqCjw8L1RpdGxlICj+/wAxAC4AMQAuAKAAIABSAG8AbABlAHMpCiAgL1BhcmVudCA5OTcg MCBSCiAgL0Rlc3QgL19fV0tBTkNIT1JfZQogIC9Db3VudCAwCiAgL05leHQgMTAwNCAwIFIKICAv UHJldiAxMDAyIDAgUgo+PgplbmRvYmoKMTAwNCAwIG9iago8PC9UaXRsZSAo/v8AMQAuADIALgCg ACAAUAByAG8AdABvAGMAbwBsACAARgBsAG8AdykKICAvUGFyZW50IDk5NyAwIFIKICAvRGVzdCAv X19XS0FOQ0hPUl9nCiAgL0NvdW50IDAKICAvTmV4dCAxMDA1IDAgUgogIC9QcmV2IDEwMDMgMCBS Cj4+CmVuZG9iagoxMDA1IDAgb2JqCjw8L1RpdGxlICj+/wAxAC4AMwAuAKAAIABBAHUAdABoAG8A cgBpAHoAYQB0AGkAbwBuACAARwByAGEAbgB0KQogIC9QYXJlbnQgOTk3IDAgUgogIC9EZXN0IC9f X1dLQU5DSE9SX2kKICAvQ291bnQgMAogIC9OZXh0IDEwMDYgMCBSCiAgL1ByZXYgMTAwNCAwIFIK Pj4KZW5kb2JqCjEwMDYgMCBvYmoKPDwvVGl0bGUgKP7/ADEALgAzAC4AMQAuAKAAIABBAHUAdABo AG8AcgBpAHoAYQB0AGkAbwBuACAAQwBvAGQAZSkKICAvUGFyZW50IDk5NyAwIFIKICAvRGVzdCAv X19XS0FOQ0hPUl9rCiAgL0NvdW50IDAKICAvTmV4dCAxMDA3IDAgUgogIC9QcmV2IDEwMDUgMCBS Cj4+CmVuZG9iagoxMDA3IDAgb2JqCjw8L1RpdGxlICj+/wAxAC4AMwAuADIALgCgACAASQBtAHAA bABpAGMAaQB0KQogIC9QYXJlbnQgOTk3IDAgUgogIC9EZXN0IC9fX1dLQU5DSE9SX20KICAvQ291 bnQgMAogIC9OZXh0IDEwMDggMCBSCiAgL1ByZXYgMTAwNiAwIFIKPj4KZW5kb2JqCjEwMDggMCBv YmoKPDwvVGl0bGUgKP7/ADEALgAzAC4AMwAuAKAAIABSAGUAcwBvAHUAcgBjAGUAIABPAHcAbgBl AHIAIABQAGEAcwBzAHcAbwByAGQAIABDAHIAZQBkAGUAbgB0AGkAYQBsAHMpCiAgL1BhcmVudCA5 OTcgMCBSCiAgL0Rlc3QgL19fV0tBTkNIT1JfbwogIC9Db3VudCAwCiAgL05leHQgMTAwOSAwIFIK ICAvUHJldiAxMDA3IDAgUgo+PgplbmRvYmoKMTAwOSAwIG9iago8PC9UaXRsZSAo/v8AMQAuADMA LgA0AC4AoAAgAEMAbABpAGUAbgB0ACAAQwByAGUAZABlAG4AdABpAGEAbABzKQogIC9QYXJlbnQg OTk3IDAgUgogIC9EZXN0IC9fX1dLQU5DSE9SX3EKICAvQ291bnQgMAogIC9OZXh0IDEwMTAgMCBS CiAgL1ByZXYgMTAwOCAwIFIKPj4KZW5kb2JqCjEwMTAgMCBvYmoKPDwvVGl0bGUgKP7/ADEALgA0 AC4AoAAgAEEAYwBjAGUAcwBzACAAVABvAGsAZQBuKQogIC9QYXJlbnQgOTk3IDAgUgogIC9EZXN0 IC9fX1dLQU5DSE9SX3MKICAvQ291bnQgMAogIC9OZXh0IDEwMTEgMCBSCiAgL1ByZXYgMTAwOSAw IFIKPj4KZW5kb2JqCjEwMTEgMCBvYmoKPDwvVGl0bGUgKP7/ADEALgA1AC4AoAAgAFIAZQBmAHIA ZQBzAGgAIABUAG8AawBlAG4pCiAgL1BhcmVudCA5OTcgMCBSCiAgL0Rlc3QgL19fV0tBTkNIT1Jf dQogIC9Db3VudCAwCiAgL05leHQgMTAxMiAwIFIKICAvUHJldiAxMDEwIDAgUgo+PgplbmRvYmoK MTAxMiAwIG9iago8PC9UaXRsZSAo/v8AMQAuADYALgCgACAAVABMAFMAIABWAGUAcgBzAGkAbwBu KQogIC9QYXJlbnQgOTk3IDAgUgogIC9EZXN0IC9fX1dLQU5DSE9SX3cKICAvQ291bnQgMAogIC9O ZXh0IDEwMTMgMCBSCiAgL1ByZXYgMTAxMSAwIFIKPj4KZW5kb2JqCjEwMTMgMCBvYmoKPDwvVGl0 bGUgKP7/ADEALgA3AC4AoAAgAEgAVABUAFAAIABSAGUAZABpAHIAZQBjAHQAaQBvAG4AcykKICAv UGFyZW50IDk5NyAwIFIKICAvRGVzdCAvX19XS0FOQ0hPUl95CiAgL0NvdW50IDAKICAvTmV4dCAx MDE0IDAgUgogIC9QcmV2IDEwMTIgMCBSCj4+CmVuZG9iagoxMDE0IDAgb2JqCjw8L1RpdGxlICj+ /wAxAC4AOAAuAKAAIABJAG4AdABlAHIAbwBwAGUAcgBhAGIAaQBsAGkAdAB5KQogIC9QYXJlbnQg OTk3IDAgUgogIC9EZXN0IC9fX1dLQU5DSE9SXzEwCiAgL0NvdW50IDAKICAvTmV4dCAxMDE1IDAg UgogIC9QcmV2IDEwMTMgMCBSCj4+CmVuZG9iagoxMDE1IDAgb2JqCjw8L1RpdGxlICj+/wAxAC4A OQAuAKAAIABOAG8AdABhAHQAaQBvAG4AYQBsACAAQwBvAG4AdgBlAG4AdABpAG8AbgBzKQogIC9Q YXJlbnQgOTk3IDAgUgogIC9EZXN0IC9fX1dLQU5DSE9SXzEyCiAgL0NvdW50IDAKICAvTmV4dCAx MDE2IDAgUgogIC9QcmV2IDEwMTQgMCBSCj4+CmVuZG9iagoxMDE2IDAgb2JqCjw8L1RpdGxlICj+ /wAyAC4AoAAgAEMAbABpAGUAbgB0ACAAUgBlAGcAaQBzAHQAcgBhAHQAaQBvAG4pCiAgL1BhcmVu dCA5OTcgMCBSCiAgL0Rlc3QgL19fV0tBTkNIT1JfMTQKICAvQ291bnQgMAogIC9OZXh0IDEwMTcg MCBSCiAgL1ByZXYgMTAxNSAwIFIKPj4KZW5kb2JqCjEwMTcgMCBvYmoKPDwvVGl0bGUgKP7/ADIA LgAxAC4AoAAgAEMAbABpAGUAbgB0ACAAVAB5AHAAZQBzKQogIC9QYXJlbnQgOTk3IDAgUgogIC9E ZXN0IC9fX1dLQU5DSE9SXzE2CiAgL0NvdW50IDAKICAvTmV4dCAxMDE4IDAgUgogIC9QcmV2IDEw MTYgMCBSCj4+CmVuZG9iagoxMDE4IDAgb2JqCjw8L1RpdGxlICj+/wAyAC4AMgAuAKAAIABDAGwA aQBlAG4AdAAgAEkAZABlAG4AdABpAGYAaQBlAHIpCiAgL1BhcmVudCA5OTcgMCBSCiAgL0Rlc3Qg L19fV0tBTkNIT1JfMTgKICAvQ291bnQgMAogIC9OZXh0IDEwMTkgMCBSCiAgL1ByZXYgMTAxNyAw IFIKPj4KZW5kb2JqCjEwMTkgMCBvYmoKPDwvVGl0bGUgKP7/ADIALgAzAC4AoAAgAEMAbABpAGUA bgB0ACAAQQB1AHQAaABlAG4AdABpAGMAYQB0AGkAbwBuKQogIC9QYXJlbnQgOTk3IDAgUgogIC9E ZXN0IC9fX1dLQU5DSE9SXzFhCiAgL0NvdW50IDAKICAvTmV4dCAxMDIwIDAgUgogIC9QcmV2IDEw MTggMCBSCj4+CmVuZG9iagoxMDIwIDAgb2JqCjw8L1RpdGxlICj+/wAyAC4AMwAuADEALgCgACAA QwBsAGkAZQBuAHQAIABQAGEAcwBzAHcAbwByAGQpCiAgL1BhcmVudCA5OTcgMCBSCiAgL0Rlc3Qg L19fV0tBTkNIT1JfMWMKICAvQ291bnQgMAogIC9OZXh0IDEwMjEgMCBSCiAgL1ByZXYgMTAxOSAw IFIKPj4KZW5kb2JqCjEwMjEgMCBvYmoKPDwvVGl0bGUgKP7/ADIALgAzAC4AMgAuAKAAIABPAHQA aABlAHIAIABBAHUAdABoAGUAbgB0AGkAYwBhAHQAaQBvAG4AIABNAGUAdABoAG8AZABzKQogIC9Q YXJlbnQgOTk3IDAgUgogIC9EZXN0IC9fX1dLQU5DSE9SXzFlCiAgL0NvdW50IDAKICAvTmV4dCAx MDIyIDAgUgogIC9QcmV2IDEwMjAgMCBSCj4+CmVuZG9iagoxMDIyIDAgb2JqCjw8L1RpdGxlICj+ /wAyAC4ANAAuAKAAIABVAG4AcgBlAGcAaQBzAHQAZQByAGUAZAAgAEMAbABpAGUAbgB0AHMpCiAg L1BhcmVudCA5OTcgMCBSCiAgL0Rlc3QgL19fV0tBTkNIT1JfMWcKICAvQ291bnQgMAogIC9OZXh0 IDEwMjMgMCBSCiAgL1ByZXYgMTAyMSAwIFIKPj4KZW5kb2JqCjEwMjMgMCBvYmoKPDwvVGl0bGUg KP7/ADMALgCgACAAUAByAG8AdABvAGMAbwBsACAARQBuAGQAcABvAGkAbgB0AHMpCiAgL1BhcmVu dCA5OTcgMCBSCiAgL0Rlc3QgL19fV0tBTkNIT1JfMWkKICAvQ291bnQgMAogIC9OZXh0IDEwMjQg MCBSCiAgL1ByZXYgMTAyMiAwIFIKPj4KZW5kb2JqCjEwMjQgMCBvYmoKPDwvVGl0bGUgKP7/ADMA LgAxAC4AoAAgAEEAdQB0AGgAbwByAGkAegBhAHQAaQBvAG4AIABFAG4AZABwAG8AaQBuAHQpCiAg L1BhcmVudCA5OTcgMCBSCiAgL0Rlc3QgL19fV0tBTkNIT1JfMWsKICAvQ291bnQgMAogIC9OZXh0 IDEwMjUgMCBSCiAgL1ByZXYgMTAyMyAwIFIKPj4KZW5kb2JqCjEwMjUgMCBvYmoKPDwvVGl0bGUg KP7/ADMALgAxAC4AMQAuAKAAIABSAGUAcwBwAG8AbgBzAGUAIABUAHkAcABlKQogIC9QYXJlbnQg OTk3IDAgUgogIC9EZXN0IC9fX1dLQU5DSE9SXzFtCiAgL0NvdW50IDAKICAvTmV4dCAxMDI2IDAg UgogIC9QcmV2IDEwMjQgMCBSCj4+CmVuZG9iagoxMDI2IDAgb2JqCjw8L1RpdGxlICj+/wAzAC4A MQAuADIALgCgACAAUgBlAGQAaQByAGUAYwB0AGkAbwBuACAARQBuAGQAcABvAGkAbgB0KQogIC9Q YXJlbnQgOTk3IDAgUgogIC9EZXN0IC9fX1dLQU5DSE9SXzFvCiAgL0NvdW50IDAKICAvTmV4dCAx MDI3IDAgUgogIC9QcmV2IDEwMjUgMCBSCj4+CmVuZG9iagoxMDI3IDAgb2JqCjw8L1RpdGxlICj+ /wAzAC4AMQAuADIALgAxAC4AoAAgAEUAbgBkAHAAbwBpAG4AdAAgAFIAZQBxAHUAZQBzAHQAIABD AG8AbgBmAGkAZABlAG4AdABpAGEAbABpAHQAeSkKICAvUGFyZW50IDk5NyAwIFIKICAvRGVzdCAv X19XS0FOQ0hPUl8xcQogIC9Db3VudCAwCiAgL05leHQgMTAyOCAwIFIKICAvUHJldiAxMDI2IDAg Ugo+PgplbmRvYmoKMTAyOCAwIG9iago8PC9UaXRsZSAo/v8AMwAuADEALgAyAC4AMgAuAKAAIABS AGUAZwBpAHMAdAByAGEAdABpAG8AbgAgAFIAZQBxAHUAaQByAGUAbQBlAG4AdABzKQogIC9QYXJl bnQgOTk3IDAgUgogIC9EZXN0IC9fX1dLQU5DSE9SXzFzCiAgL0NvdW50IDAKICAvTmV4dCAxMDI5 IDAgUgogIC9QcmV2IDEwMjcgMCBSCj4+CmVuZG9iagoxMDI5IDAgb2JqCjw8L1RpdGxlICj+/wAz AC4AMQAuADIALgAzAC4AoAAgAEQAeQBuAGEAbQBpAGMAIABDAG8AbgBmAGkAZwB1AHIAYQB0AGkA bwBuKQogIC9QYXJlbnQgOTk3IDAgUgogIC9EZXN0IC9fX1dLQU5DSE9SXzF1CiAgL0NvdW50IDAK ICAvTmV4dCAxMDMwIDAgUgogIC9QcmV2IDEwMjggMCBSCj4+CmVuZG9iagoxMDMwIDAgb2JqCjw8 L1RpdGxlICj+/wAzAC4AMQAuADIALgA0AC4AoAAgAEkAbgB2AGEAbABpAGQAIABFAG4AZABwAG8A aQBuAHQpCiAgL1BhcmVudCA5OTcgMCBSCiAgL0Rlc3QgL19fV0tBTkNIT1JfMXcKICAvQ291bnQg MAogIC9OZXh0IDEwMzEgMCBSCiAgL1ByZXYgMTAyOSAwIFIKPj4KZW5kb2JqCjEwMzEgMCBvYmoK PDwvVGl0bGUgKP7/ADMALgAxAC4AMgAuADUALgCgACAARQBuAGQAcABvAGkAbgB0ACAAQwBvAG4A dABlAG4AdCkKICAvUGFyZW50IDk5NyAwIFIKICAvRGVzdCAvX19XS0FOQ0hPUl8xeQogIC9Db3Vu dCAwCiAgL05leHQgMTAzMiAwIFIKICAvUHJldiAxMDMwIDAgUgo+PgplbmRvYmoKMTAzMiAwIG9i ago8PC9UaXRsZSAo/v8AMwAuADIALgCgACAAVABvAGsAZQBuACAARQBuAGQAcABvAGkAbgB0KQog IC9QYXJlbnQgOTk3IDAgUgogIC9EZXN0IC9fX1dLQU5DSE9SXzIwCiAgL0NvdW50IDAKICAvTmV4 dCAxMDMzIDAgUgogIC9QcmV2IDEwMzEgMCBSCj4+CmVuZG9iagoxMDMzIDAgb2JqCjw8L1RpdGxl ICj+/wAzAC4AMgAuADEALgCgACAAQwBsAGkAZQBuAHQAIABBAHUAdABoAGUAbgB0AGkAYwBhAHQA aQBvAG4pCiAgL1BhcmVudCA5OTcgMCBSCiAgL0Rlc3QgL19fV0tBTkNIT1JfMjIKICAvQ291bnQg MAogIC9OZXh0IDEwMzQgMCBSCiAgL1ByZXYgMTAzMiAwIFIKPj4KZW5kb2JqCjEwMzQgMCBvYmoK PDwvVGl0bGUgKP7/ADMALgAzAC4AoAAgAEEAYwBjAGUAcwBzACAAVABvAGsAZQBuACAAUwBjAG8A cABlKQogIC9QYXJlbnQgOTk3IDAgUgogIC9EZXN0IC9fX1dLQU5DSE9SXzI0CiAgL0NvdW50IDAK ICAvTmV4dCAxMDM1IDAgUgogIC9QcmV2IDEwMzMgMCBSCj4+CmVuZG9iagoxMDM1IDAgb2JqCjw8 L1RpdGxlICj+/wA0AC4AoAAgAE8AYgB0AGEAaQBuAGkAbgBnACAAQQB1AHQAaABvAHIAaQB6AGEA dABpAG8AbikKICAvUGFyZW50IDk5NyAwIFIKICAvRGVzdCAvX19XS0FOQ0hPUl8yNgogIC9Db3Vu dCAwCiAgL05leHQgMTAzNiAwIFIKICAvUHJldiAxMDM0IDAgUgo+PgplbmRvYmoKMTAzNiAwIG9i ago8PC9UaXRsZSAo/v8ANAAuADEALgCgACAAQQB1AHQAaABvAHIAaQB6AGEAdABpAG8AbgAgAEMA bwBkAGUAIABHAHIAYQBuAHQpCiAgL1BhcmVudCA5OTcgMCBSCiAgL0Rlc3QgL19fV0tBTkNIT1Jf MjgKICAvQ291bnQgMAogIC9OZXh0IDEwMzcgMCBSCiAgL1ByZXYgMTAzNSAwIFIKPj4KZW5kb2Jq CjEwMzcgMCBvYmoKPDwvVGl0bGUgKP7/ADQALgAxAC4AMQAuAKAAIABBAHUAdABoAG8AcgBpAHoA YQB0AGkAbwBuACAAUgBlAHEAdQBlAHMAdCkKICAvUGFyZW50IDk5NyAwIFIKICAvRGVzdCAvX19X S0FOQ0hPUl8yYQogIC9Db3VudCAwCiAgL05leHQgMTAzOCAwIFIKICAvUHJldiAxMDM2IDAgUgo+ PgplbmRvYmoKMTAzOCAwIG9iago8PC9UaXRsZSAo/v8ANAAuADEALgAyAC4AoAAgAEEAdQB0AGgA bwByAGkAegBhAHQAaQBvAG4AIABSAGUAcwBwAG8AbgBzAGUpCiAgL1BhcmVudCA5OTcgMCBSCiAg L0Rlc3QgL19fV0tBTkNIT1JfMmMKICAvQ291bnQgMAogIC9OZXh0IDEwMzkgMCBSCiAgL1ByZXYg MTAzNyAwIFIKPj4KZW5kb2JqCjEwMzkgMCBvYmoKPDwvVGl0bGUgKP7/ADQALgAxAC4AMgAuADEA LgCgACAARQByAHIAbwByACAAUgBlAHMAcABvAG4AcwBlKQogIC9QYXJlbnQgOTk3IDAgUgogIC9E ZXN0IC9fX1dLQU5DSE9SXzJlCiAgL0NvdW50IDAKICAvTmV4dCAxMDQwIDAgUgogIC9QcmV2IDEw MzggMCBSCj4+CmVuZG9iagoxMDQwIDAgb2JqCjw8L1RpdGxlICj+/wA0AC4AMQAuADMALgCgACAA QQBjAGMAZQBzAHMAIABUAG8AawBlAG4AIABSAGUAcQB1AGUAcwB0KQogIC9QYXJlbnQgOTk3IDAg UgogIC9EZXN0IC9fX1dLQU5DSE9SXzJnCiAgL0NvdW50IDAKICAvTmV4dCAxMDQxIDAgUgogIC9Q cmV2IDEwMzkgMCBSCj4+CmVuZG9iagoxMDQxIDAgb2JqCjw8L1RpdGxlICj+/wA0AC4AMQAuADQA LgCgACAAQQBjAGMAZQBzAHMAIABUAG8AawBlAG4AIABSAGUAcwBwAG8AbgBzAGUpCiAgL1BhcmVu dCA5OTcgMCBSCiAgL0Rlc3QgL19fV0tBTkNIT1JfMmkKICAvQ291bnQgMAogIC9OZXh0IDEwNDIg MCBSCiAgL1ByZXYgMTA0MCAwIFIKPj4KZW5kb2JqCjEwNDIgMCBvYmoKPDwvVGl0bGUgKP7/ADQA LgAyAC4AoAAgAEkAbQBwAGwAaQBjAGkAdAAgAEcAcgBhAG4AdCkKICAvUGFyZW50IDk5NyAwIFIK ICAvRGVzdCAvX19XS0FOQ0hPUl8yawogIC9Db3VudCAwCiAgL05leHQgMTA0MyAwIFIKICAvUHJl diAxMDQxIDAgUgo+PgplbmRvYmoKMTA0MyAwIG9iago8PC9UaXRsZSAo/v8ANAAuADIALgAxAC4A oAAgAEEAdQB0AGgAbwByAGkAegBhAHQAaQBvAG4AIABSAGUAcQB1AGUAcwB0KQogIC9QYXJlbnQg OTk3IDAgUgogIC9EZXN0IC9fX1dLQU5DSE9SXzJtCiAgL0NvdW50IDAKICAvTmV4dCAxMDQ0IDAg UgogIC9QcmV2IDEwNDIgMCBSCj4+CmVuZG9iagoxMDQ0IDAgb2JqCjw8L1RpdGxlICj+/wA0AC4A MgAuADIALgCgACAAQQBjAGMAZQBzAHMAIABUAG8AawBlAG4AIABSAGUAcwBwAG8AbgBzAGUpCiAg L1BhcmVudCA5OTcgMCBSCiAgL0Rlc3QgL19fV0tBTkNIT1JfMm8KICAvQ291bnQgMAogIC9OZXh0 IDEwNDUgMCBSCiAgL1ByZXYgMTA0MyAwIFIKPj4KZW5kb2JqCjEwNDUgMCBvYmoKPDwvVGl0bGUg KP7/ADQALgAyAC4AMgAuADEALgCgACAARQByAHIAbwByACAAUgBlAHMAcABvAG4AcwBlKQogIC9Q YXJlbnQgOTk3IDAgUgogIC9EZXN0IC9fX1dLQU5DSE9SXzJxCiAgL0NvdW50IDAKICAvTmV4dCAx MDQ2IDAgUgogIC9QcmV2IDEwNDQgMCBSCj4+CmVuZG9iagoxMDQ2IDAgb2JqCjw8L1RpdGxlICj+ /wA0AC4AMwAuAKAAIABSAGUAcwBvAHUAcgBjAGUAIABPAHcAbgBlAHIAIABQAGEAcwBzAHcAbwBy AGQAIABDAHIAZQBkAGUAbgB0AGkAYQBsAHMAIABHAHIAYQBuAHQpCiAgL1BhcmVudCA5OTcgMCBS CiAgL0Rlc3QgL19fV0tBTkNIT1JfMnMKICAvQ291bnQgMAogIC9OZXh0IDEwNDcgMCBSCiAgL1By ZXYgMTA0NSAwIFIKPj4KZW5kb2JqCjEwNDcgMCBvYmoKPDwvVGl0bGUgKP7/ADQALgAzAC4AMQAu AKAAIABBAHUAdABoAG8AcgBpAHoAYQB0AGkAbwBuACAAUgBlAHEAdQBlAHMAdAAgAGEAbgBkACAA UgBlAHMAcABvAG4AcwBlKQogIC9QYXJlbnQgOTk3IDAgUgogIC9EZXN0IC9fX1dLQU5DSE9SXzJ1 CiAgL0NvdW50IDAKICAvTmV4dCAxMDQ4IDAgUgogIC9QcmV2IDEwNDYgMCBSCj4+CmVuZG9iagox MDQ4IDAgb2JqCjw8L1RpdGxlICj+/wA0AC4AMwAuADIALgCgACAAQQBjAGMAZQBzAHMAIABUAG8A awBlAG4AIABSAGUAcQB1AGUAcwB0KQogIC9QYXJlbnQgOTk3IDAgUgogIC9EZXN0IC9fX1dLQU5D SE9SXzJ3CiAgL0NvdW50IDAKICAvTmV4dCAxMDQ5IDAgUgogIC9QcmV2IDEwNDcgMCBSCj4+CmVu ZG9iagoxMDQ5IDAgb2JqCjw8L1RpdGxlICj+/wA0AC4AMwAuADMALgCgACAAQQBjAGMAZQBzAHMA IABUAG8AawBlAG4AIABSAGUAcwBwAG8AbgBzAGUpCiAgL1BhcmVudCA5OTcgMCBSCiAgL0Rlc3Qg L19fV0tBTkNIT1JfMnkKICAvQ291bnQgMAogIC9OZXh0IDEwNTAgMCBSCiAgL1ByZXYgMTA0OCAw IFIKPj4KZW5kb2JqCjEwNTAgMCBvYmoKPDwvVGl0bGUgKP7/ADQALgA0AC4AoAAgAEMAbABpAGUA bgB0ACAAQwByAGUAZABlAG4AdABpAGEAbABzACAARwByAGEAbgB0KQogIC9QYXJlbnQgOTk3IDAg UgogIC9EZXN0IC9fX1dLQU5DSE9SXzMwCiAgL0NvdW50IDAKICAvTmV4dCAxMDUxIDAgUgogIC9Q cmV2IDEwNDkgMCBSCj4+CmVuZG9iagoxMDUxIDAgb2JqCjw8L1RpdGxlICj+/wA0AC4ANAAuADEA LgCgACAAQQB1AHQAaABvAHIAaQB6AGEAdABpAG8AbgAgAFIAZQBxAHUAZQBzAHQAIABhAG4AZAAg AFIAZQBzAHAAbwBuAHMAZSkKICAvUGFyZW50IDk5NyAwIFIKICAvRGVzdCAvX19XS0FOQ0hPUl8z MgogIC9Db3VudCAwCiAgL05leHQgMTA1MiAwIFIKICAvUHJldiAxMDUwIDAgUgo+PgplbmRvYmoK MTA1MiAwIG9iago8PC9UaXRsZSAo/v8ANAAuADQALgAyAC4AoAAgAEEAYwBjAGUAcwBzACAAVABv AGsAZQBuACAAUgBlAHEAdQBlAHMAdCkKICAvUGFyZW50IDk5NyAwIFIKICAvRGVzdCAvX19XS0FO Q0hPUl8zNAogIC9Db3VudCAwCiAgL05leHQgMTA1MyAwIFIKICAvUHJldiAxMDUxIDAgUgo+Pgpl bmRvYmoKMTA1MyAwIG9iago8PC9UaXRsZSAo/v8ANAAuADQALgAzAC4AoAAgAEEAYwBjAGUAcwBz ACAAVABvAGsAZQBuACAAUgBlAHMAcABvAG4AcwBlKQogIC9QYXJlbnQgOTk3IDAgUgogIC9EZXN0 IC9fX1dLQU5DSE9SXzM2CiAgL0NvdW50IDAKICAvTmV4dCAxMDU0IDAgUgogIC9QcmV2IDEwNTIg MCBSCj4+CmVuZG9iagoxMDU0IDAgb2JqCjw8L1RpdGxlICj+/wA0AC4ANQAuAKAAIABFAHgAdABl AG4AcwBpAG8AbgAgAEcAcgBhAG4AdABzKQogIC9QYXJlbnQgOTk3IDAgUgogIC9EZXN0IC9fX1dL QU5DSE9SXzM4CiAgL0NvdW50IDAKICAvTmV4dCAxMDU1IDAgUgogIC9QcmV2IDEwNTMgMCBSCj4+ CmVuZG9iagoxMDU1IDAgb2JqCjw8L1RpdGxlICj+/wA1AC4AoAAgAEkAcwBzAHUAaQBuAGcAIABh AG4AIABBAGMAYwBlAHMAcwAgAFQAbwBrAGUAbikKICAvUGFyZW50IDk5NyAwIFIKICAvRGVzdCAv X19XS0FOQ0hPUl8zYQogIC9Db3VudCAwCiAgL05leHQgMTA1NiAwIFIKICAvUHJldiAxMDU0IDAg Ugo+PgplbmRvYmoKMTA1NiAwIG9iago8PC9UaXRsZSAo/v8ANQAuADEALgCgACAAUwB1AGMAYwBl AHMAcwBmAHUAbAAgAFIAZQBzAHAAbwBuAHMAZSkKICAvUGFyZW50IDk5NyAwIFIKICAvRGVzdCAv X19XS0FOQ0hPUl8zYwogIC9Db3VudCAwCiAgL05leHQgMTA1NyAwIFIKICAvUHJldiAxMDU1IDAg Ugo+PgplbmRvYmoKMTA1NyAwIG9iago8PC9UaXRsZSAo/v8ANQAuADIALgCgACAARQByAHIAbwBy ACAAUgBlAHMAcABvAG4AcwBlKQogIC9QYXJlbnQgOTk3IDAgUgogIC9EZXN0IC9fX1dLQU5DSE9S XzNlCiAgL0NvdW50IDAKICAvTmV4dCAxMDU4IDAgUgogIC9QcmV2IDEwNTYgMCBSCj4+CmVuZG9i agoxMDU4IDAgb2JqCjw8L1RpdGxlICj+/wA2AC4AoAAgAFIAZQBmAHIAZQBzAGgAaQBuAGcAIABh AG4AIABBAGMAYwBlAHMAcwAgAFQAbwBrAGUAbikKICAvUGFyZW50IDk5NyAwIFIKICAvRGVzdCAv X19XS0FOQ0hPUl8zZwogIC9Db3VudCAwCiAgL05leHQgMTA1OSAwIFIKICAvUHJldiAxMDU3IDAg Ugo+PgplbmRvYmoKMTA1OSAwIG9iago8PC9UaXRsZSAo/v8ANwAuAKAAIABBAGMAYwBlAHMAcwBp AG4AZwAgAFAAcgBvAHQAZQBjAHQAZQBkACAAUgBlAHMAbwB1AHIAYwBlAHMpCiAgL1BhcmVudCA5 OTcgMCBSCiAgL0Rlc3QgL19fV0tBTkNIT1JfM2kKICAvQ291bnQgMAogIC9OZXh0IDEwNjAgMCBS CiAgL1ByZXYgMTA1OCAwIFIKPj4KZW5kb2JqCjEwNjAgMCBvYmoKPDwvVGl0bGUgKP7/ADcALgAx AC4AoAAgAEEAYwBjAGUAcwBzACAAVABvAGsAZQBuACAAVAB5AHAAZQBzKQogIC9QYXJlbnQgOTk3 IDAgUgogIC9EZXN0IC9fX1dLQU5DSE9SXzNrCiAgL0NvdW50IDAKICAvTmV4dCAxMDYxIDAgUgog IC9QcmV2IDEwNTkgMCBSCj4+CmVuZG9iagoxMDYxIDAgb2JqCjw8L1RpdGxlICj+/wA3AC4AMgAu AKAAIABFAHIAcgBvAHIAIABSAGUAcwBwAG8AbgBzAGUpCiAgL1BhcmVudCA5OTcgMCBSCiAgL0Rl c3QgL19fV0tBTkNIT1JfM20KICAvQ291bnQgMAogIC9OZXh0IDEwNjIgMCBSCiAgL1ByZXYgMTA2 MCAwIFIKPj4KZW5kb2JqCjEwNjIgMCBvYmoKPDwvVGl0bGUgKP7/ADgALgCgACAARQB4AHQAZQBu AHMAaQBiAGkAbABpAHQAeSkKICAvUGFyZW50IDk5NyAwIFIKICAvRGVzdCAvX19XS0FOQ0hPUl8z bwogIC9Db3VudCAwCiAgL05leHQgMTA2MyAwIFIKICAvUHJldiAxMDYxIDAgUgo+PgplbmRvYmoK MTA2MyAwIG9iago8PC9UaXRsZSAo/v8AOAAuADEALgCgACAARABlAGYAaQBuAGkAbgBnACAAQQBj AGMAZQBzAHMAIABUAG8AawBlAG4AIABUAHkAcABlAHMpCiAgL1BhcmVudCA5OTcgMCBSCiAgL0Rl c3QgL19fV0tBTkNIT1JfM3EKICAvQ291bnQgMAogIC9OZXh0IDEwNjQgMCBSCiAgL1ByZXYgMTA2 MiAwIFIKPj4KZW5kb2JqCjEwNjQgMCBvYmoKPDwvVGl0bGUgKP7/ADgALgAyAC4AoAAgAEQAZQBm AGkAbgBpAG4AZwAgAE4AZQB3ACAARQBuAGQAcABvAGkAbgB0ACAAUABhAHIAYQBtAGUAdABlAHIA cykKICAvUGFyZW50IDk5NyAwIFIKICAvRGVzdCAvX19XS0FOQ0hPUl8zcwogIC9Db3VudCAwCiAg L05leHQgMTA2NSAwIFIKICAvUHJldiAxMDYzIDAgUgo+PgplbmRvYmoKMTA2NSAwIG9iago8PC9U aXRsZSAo/v8AOAAuADMALgCgACAARABlAGYAaQBuAGkAbgBnACAATgBlAHcAIABBAHUAdABoAG8A cgBpAHoAYQB0AGkAbwBuACAARwByAGEAbgB0ACAAVAB5AHAAZQBzKQogIC9QYXJlbnQgOTk3IDAg UgogIC9EZXN0IC9fX1dLQU5DSE9SXzN1CiAgL0NvdW50IDAKICAvTmV4dCAxMDY2IDAgUgogIC9Q cmV2IDEwNjQgMCBSCj4+CmVuZG9iagoxMDY2IDAgb2JqCjw8L1RpdGxlICj+/wA4AC4ANAAuAKAA IABEAGUAZgBpAG4AaQBuAGcAIABOAGUAdwAgAEEAdQB0AGgAbwByAGkAegBhAHQAaQBvAG4AIABF AG4AZABwAG8AaQBuAHQAIABSAGUAcwBwAG8AbgBzAGUAIABUAHkAcABlAHMpCiAgL1BhcmVudCA5 OTcgMCBSCiAgL0Rlc3QgL19fV0tBTkNIT1JfM3cKICAvQ291bnQgMAogIC9OZXh0IDEwNjcgMCBS CiAgL1ByZXYgMTA2NSAwIFIKPj4KZW5kb2JqCjEwNjcgMCBvYmoKPDwvVGl0bGUgKP7/ADgALgA1 AC4AoAAgAEQAZQBmAGkAbgBpAG4AZwAgAEEAZABkAGkAdABpAG8AbgBhAGwAIABFAHIAcgBvAHIA IABDAG8AZABlAHMpCiAgL1BhcmVudCA5OTcgMCBSCiAgL0Rlc3QgL19fV0tBTkNIT1JfM3kKICAv Q291bnQgMAogIC9OZXh0IDEwNjggMCBSCiAgL1ByZXYgMTA2NiAwIFIKPj4KZW5kb2JqCjEwNjgg MCBvYmoKPDwvVGl0bGUgKP7/ADkALgCgACAATgBhAHQAaQB2AGUAIABBAHAAcABsAGkAYwBhAHQA aQBvAG4AcykKICAvUGFyZW50IDk5NyAwIFIKICAvRGVzdCAvX19XS0FOQ0hPUl80MAogIC9Db3Vu dCAwCiAgL05leHQgMTA2OSAwIFIKICAvUHJldiAxMDY3IDAgUgo+PgplbmRvYmoKMTA2OSAwIG9i ago8PC9UaXRsZSAo/v8AMQAwAC4AoAAgAFMAZQBjAHUAcgBpAHQAeQAgAEMAbwBuAHMAaQBkAGUA cgBhAHQAaQBvAG4AcykKICAvUGFyZW50IDk5NyAwIFIKICAvRGVzdCAvX19XS0FOQ0hPUl80Mgog IC9Db3VudCAwCiAgL05leHQgMTA3MCAwIFIKICAvUHJldiAxMDY4IDAgUgo+PgplbmRvYmoKMTA3 MCAwIG9iago8PC9UaXRsZSAo/v8AMQAwAC4AMQAuAKAAIABDAGwAaQBlAG4AdAAgAEEAdQB0AGgA ZQBuAHQAaQBjAGEAdABpAG8AbikKICAvUGFyZW50IDk5NyAwIFIKICAvRGVzdCAvX19XS0FOQ0hP Ul80NAogIC9Db3VudCAwCiAgL05leHQgMTA3MSAwIFIKICAvUHJldiAxMDY5IDAgUgo+PgplbmRv YmoKMTA3MSAwIG9iago8PC9UaXRsZSAo/v8AMQAwAC4AMgAuAKAAIABDAGwAaQBlAG4AdAAgAEkA bQBwAGUAcgBzAG8AbgBhAHQAaQBvAG4pCiAgL1BhcmVudCA5OTcgMCBSCiAgL0Rlc3QgL19fV0tB TkNIT1JfNDYKICAvQ291bnQgMAogIC9OZXh0IDEwNzIgMCBSCiAgL1ByZXYgMTA3MCAwIFIKPj4K ZW5kb2JqCjEwNzIgMCBvYmoKPDwvVGl0bGUgKP7/ADEAMAAuADMALgCgACAAQQBjAGMAZQBzAHMA IABUAG8AawBlAG4AcykKICAvUGFyZW50IDk5NyAwIFIKICAvRGVzdCAvX19XS0FOQ0hPUl80OAog IC9Db3VudCAwCiAgL05leHQgMTA3MyAwIFIKICAvUHJldiAxMDcxIDAgUgo+PgplbmRvYmoKMTA3 MyAwIG9iago8PC9UaXRsZSAo/v8AMQAwAC4ANAAuAKAAIABSAGUAZgByAGUAcwBoACAAVABvAGsA ZQBuAHMpCiAgL1BhcmVudCA5OTcgMCBSCiAgL0Rlc3QgL19fV0tBTkNIT1JfNGEKICAvQ291bnQg MAogIC9OZXh0IDEwNzQgMCBSCiAgL1ByZXYgMTA3MiAwIFIKPj4KZW5kb2JqCjEwNzQgMCBvYmoK PDwvVGl0bGUgKP7/ADEAMAAuADUALgCgACAAQQB1AHQAaABvAHIAaQB6AGEAdABpAG8AbgAgAEMA bwBkAGUAcykKICAvUGFyZW50IDk5NyAwIFIKICAvRGVzdCAvX19XS0FOQ0hPUl80YwogIC9Db3Vu dCAwCiAgL05leHQgMTA3NSAwIFIKICAvUHJldiAxMDczIDAgUgo+PgplbmRvYmoKMTA3NSAwIG9i ago8PC9UaXRsZSAo/v8AMQAwAC4ANgAuAKAAIABBAHUAdABoAG8AcgBpAHoAYQB0AGkAbwBuACAA QwBvAGQAZQAgAFIAZQBkAGkAcgBlAGMAdABpAG8AbgAgAFUAUgBJACAATQBhAG4AaQBwAHUAbABh AHQAaQBvAG4pCiAgL1BhcmVudCA5OTcgMCBSCiAgL0Rlc3QgL19fV0tBTkNIT1JfNGUKICAvQ291 bnQgMAogIC9OZXh0IDEwNzYgMCBSCiAgL1ByZXYgMTA3NCAwIFIKPj4KZW5kb2JqCjEwNzYgMCBv YmoKPDwvVGl0bGUgKP7/ADEAMAAuADcALgCgACAAUgBlAHMAbwB1AHIAYwBlACAATwB3AG4AZQBy ACAAUABhAHMAcwB3AG8AcgBkACAAQwByAGUAZABlAG4AdABpAGEAbABzKQogIC9QYXJlbnQgOTk3 IDAgUgogIC9EZXN0IC9fX1dLQU5DSE9SXzRnCiAgL0NvdW50IDAKICAvTmV4dCAxMDc3IDAgUgog IC9QcmV2IDEwNzUgMCBSCj4+CmVuZG9iagoxMDc3IDAgb2JqCjw8L1RpdGxlICj+/wAxADAALgA4 AC4AoAAgAFIAZQBxAHUAZQBzAHQAIABDAG8AbgBmAGkAZABlAG4AdABpAGEAbABpAHQAeSkKICAv UGFyZW50IDk5NyAwIFIKICAvRGVzdCAvX19XS0FOQ0hPUl80aQogIC9Db3VudCAwCiAgL05leHQg MTA3OCAwIFIKICAvUHJldiAxMDc2IDAgUgo+PgplbmRvYmoKMTA3OCAwIG9iago8PC9UaXRsZSAo /v8AMQAwAC4AOQAuAKAAIABFAG4AZABwAG8AaQBuAHQAcwAgAEEAdQB0AGgAZQBuAHQAaQBjAGkA dAB5KQogIC9QYXJlbnQgOTk3IDAgUgogIC9EZXN0IC9fX1dLQU5DSE9SXzRrCiAgL0NvdW50IDAK ICAvTmV4dCAxMDc5IDAgUgogIC9QcmV2IDEwNzcgMCBSCj4+CmVuZG9iagoxMDc5IDAgb2JqCjw8 L1RpdGxlICj+/wAxADAALgAxADAALgCgACAAQwByAGUAZABlAG4AdABpAGEAbABzACAARwB1AGUA cwBzAGkAbgBnACAAQQB0AHQAYQBjAGsAcykKICAvUGFyZW50IDk5NyAwIFIKICAvRGVzdCAvX19X S0FOQ0hPUl80bQogIC9Db3VudCAwCiAgL05leHQgMTA4MCAwIFIKICAvUHJldiAxMDc4IDAgUgo+ PgplbmRvYmoKMTA4MCAwIG9iago8PC9UaXRsZSAo/v8AMQAwAC4AMQAxAC4AoAAgAFAAaABpAHMA aABpAG4AZwAgAEEAdAB0AGEAYwBrAHMpCiAgL1BhcmVudCA5OTcgMCBSCiAgL0Rlc3QgL19fV0tB TkNIT1JfNG8KICAvQ291bnQgMAogIC9OZXh0IDEwODEgMCBSCiAgL1ByZXYgMTA3OSAwIFIKPj4K ZW5kb2JqCjEwODEgMCBvYmoKPDwvVGl0bGUgKP7/ADEAMAAuADEAMgAuAKAAIABDAHIAbwBzAHMA LQBTAGkAdABlACAAUgBlAHEAdQBlAHMAdAAgAEYAbwByAGcAZQByAHkpCiAgL1BhcmVudCA5OTcg MCBSCiAgL0Rlc3QgL19fV0tBTkNIT1JfNHEKICAvQ291bnQgMAogIC9OZXh0IDEwODIgMCBSCiAg L1ByZXYgMTA4MCAwIFIKPj4KZW5kb2JqCjEwODIgMCBvYmoKPDwvVGl0bGUgKP7/ADEAMAAuADEA MwAuAKAAIABDAGwAaQBjAGsAagBhAGMAawBpAG4AZykKICAvUGFyZW50IDk5NyAwIFIKICAvRGVz dCAvX19XS0FOQ0hPUl80cwogIC9Db3VudCAwCiAgL05leHQgMTA4MyAwIFIKICAvUHJldiAxMDgx IDAgUgo+PgplbmRvYmoKMTA4MyAwIG9iago8PC9UaXRsZSAo/v8AMQAwAC4AMQA0AC4AoAAgAEMA bwBkAGUAIABJAG4AagBlAGMAdABpAG8AbgAgAGEAbgBkACAASQBuAHAAdQB0ACAAVgBhAGwAaQBk AGEAdABpAG8AbikKICAvUGFyZW50IDk5NyAwIFIKICAvRGVzdCAvX19XS0FOQ0hPUl80dQogIC9D b3VudCAwCiAgL05leHQgMTA4NCAwIFIKICAvUHJldiAxMDgyIDAgUgo+PgplbmRvYmoKMTA4NCAw IG9iago8PC9UaXRsZSAo/v8AMQAwAC4AMQA1AC4AoAAgAE8AcABlAG4AIABSAGUAZABpAHIAZQBj AHQAbwByAHMpCiAgL1BhcmVudCA5OTcgMCBSCiAgL0Rlc3QgL19fV0tBTkNIT1JfNHcKICAvQ291 bnQgMAogIC9OZXh0IDEwODUgMCBSCiAgL1ByZXYgMTA4MyAwIFIKPj4KZW5kb2JqCjEwODUgMCBv YmoKPDwvVGl0bGUgKP7/ADEAMQAuAKAAIABJAEEATgBBACAAQwBvAG4AcwBpAGQAZQByAGEAdABp AG8AbgBzKQogIC9QYXJlbnQgOTk3IDAgUgogIC9EZXN0IC9fX1dLQU5DSE9SXzR5CiAgL0NvdW50 IDAKICAvTmV4dCAxMDg2IDAgUgogIC9QcmV2IDEwODQgMCBSCj4+CmVuZG9iagoxMDg2IDAgb2Jq Cjw8L1RpdGxlICj+/wAxADEALgAxAC4AoAAgAFQAaABlACAATwBBAHUAdABoACAAQQBjAGMAZQBz AHMAIABUAG8AawBlAG4AIABUAHkAcABlACAAUgBlAGcAaQBzAHQAcgB5KQogIC9QYXJlbnQgOTk3 IDAgUgogIC9EZXN0IC9fX1dLQU5DSE9SXzUwCiAgL0NvdW50IDAKICAvTmV4dCAxMDg3IDAgUgog IC9QcmV2IDEwODUgMCBSCj4+CmVuZG9iagoxMDg3IDAgb2JqCjw8L1RpdGxlICj+/wAxADEALgAx AC4AMQAuAKAAIABSAGUAZwBpAHMAdAByAGEAdABpAG8AbgAgAFQAZQBtAHAAbABhAHQAZSkKICAv UGFyZW50IDk5NyAwIFIKICAvRGVzdCAvX19XS0FOQ0hPUl81MgogIC9Db3VudCAwCiAgL05leHQg MTA4OCAwIFIKICAvUHJldiAxMDg2IDAgUgo+PgplbmRvYmoKMTA4OCAwIG9iago8PC9UaXRsZSAo /v8AMQAxAC4AMgAuAKAAIABUAGgAZQAgAE8AQQB1AHQAaAAgAFAAYQByAGEAbQBlAHQAZQByAHMA IABSAGUAZwBpAHMAdAByAHkpCiAgL1BhcmVudCA5OTcgMCBSCiAgL0Rlc3QgL19fV0tBTkNIT1Jf NTQKICAvQ291bnQgMAogIC9OZXh0IDEwODkgMCBSCiAgL1ByZXYgMTA4NyAwIFIKPj4KZW5kb2Jq CjEwODkgMCBvYmoKPDwvVGl0bGUgKP7/ADEAMQAuADIALgAxAC4AoAAgAFIAZQBnAGkAcwB0AHIA YQB0AGkAbwBuACAAVABlAG0AcABsAGEAdABlKQogIC9QYXJlbnQgOTk3IDAgUgogIC9EZXN0IC9f X1dLQU5DSE9SXzU2CiAgL0NvdW50IDAKICAvTmV4dCAxMDkwIDAgUgogIC9QcmV2IDEwODggMCBS Cj4+CmVuZG9iagoxMDkwIDAgb2JqCjw8L1RpdGxlICj+/wAxADEALgAyAC4AMgAuAKAAIABJAG4A aQB0AGkAYQBsACAAUgBlAGcAaQBzAHQAcgB5ACAAQwBvAG4AdABlAG4AdABzKQogIC9QYXJlbnQg OTk3IDAgUgogIC9EZXN0IC9fX1dLQU5DSE9SXzU4CiAgL0NvdW50IDAKICAvTmV4dCAxMDkxIDAg UgogIC9QcmV2IDEwODkgMCBSCj4+CmVuZG9iagoxMDkxIDAgb2JqCjw8L1RpdGxlICj+/wAxADEA LgAzAC4AoAAgAFQAaABlACAATwBBAHUAdABoACAAQQB1AHQAaABvAHIAaQB6AGEAdABpAG8AbgAg AEUAbgBkAHAAbwBpAG4AdAAgAFIAZQBzAHAAbwBuAHMAZQAgAFQAeQBwAGUAIABSAGUAZwBpAHMA dAByAHkpCiAgL1BhcmVudCA5OTcgMCBSCiAgL0Rlc3QgL19fV0tBTkNIT1JfNWEKICAvQ291bnQg MAogIC9OZXh0IDEwOTIgMCBSCiAgL1ByZXYgMTA5MCAwIFIKPj4KZW5kb2JqCjEwOTIgMCBvYmoK PDwvVGl0bGUgKP7/ADEAMQAuADMALgAxAC4AoAAgAFIAZQBnAGkAcwB0AHIAYQB0AGkAbwBuACAA VABlAG0AcABsAGEAdABlKQogIC9QYXJlbnQgOTk3IDAgUgogIC9EZXN0IC9fX1dLQU5DSE9SXzVj CiAgL0NvdW50IDAKICAvTmV4dCAxMDkzIDAgUgogIC9QcmV2IDEwOTEgMCBSCj4+CmVuZG9iagox MDkzIDAgb2JqCjw8L1RpdGxlICj+/wAxADEALgAzAC4AMgAuAKAAIABJAG4AaQB0AGkAYQBsACAA UgBlAGcAaQBzAHQAcgB5ACAAQwBvAG4AdABlAG4AdABzKQogIC9QYXJlbnQgOTk3IDAgUgogIC9E ZXN0IC9fX1dLQU5DSE9SXzVlCiAgL0NvdW50IDAKICAvTmV4dCAxMDk0IDAgUgogIC9QcmV2IDEw OTIgMCBSCj4+CmVuZG9iagoxMDk0IDAgb2JqCjw8L1RpdGxlICj+/wAxADEALgA0AC4AoAAgAFQA aABlACAATwBBAHUAdABoACAARQB4AHQAZQBuAHMAaQBvAG4AcwAgAEUAcgByAG8AcgAgAFIAZQBn AGkAcwB0AHIAeSkKICAvUGFyZW50IDk5NyAwIFIKICAvRGVzdCAvX19XS0FOQ0hPUl81ZwogIC9D b3VudCAwCiAgL05leHQgMTA5NSAwIFIKICAvUHJldiAxMDkzIDAgUgo+PgplbmRvYmoKMTA5NSAw IG9iago8PC9UaXRsZSAo/v8AMQAxAC4ANAAuADEALgCgACAAUgBlAGcAaQBzAHQAcgBhAHQAaQBv AG4AIABUAGUAbQBwAGwAYQB0AGUpCiAgL1BhcmVudCA5OTcgMCBSCiAgL0Rlc3QgL19fV0tBTkNI T1JfNWkKICAvQ291bnQgMAogIC9OZXh0IDEwOTYgMCBSCiAgL1ByZXYgMTA5NCAwIFIKPj4KZW5k b2JqCjEwOTYgMCBvYmoKPDwvVGl0bGUgKP7/ADEAMgAuAKAAIABSAGUAZgBlAHIAZQBuAGMAZQBz KQogIC9QYXJlbnQgOTk3IDAgUgogIC9EZXN0IC9fX1dLQU5DSE9SXzVrCiAgL0NvdW50IDAKICAv TmV4dCAxMDk3IDAgUgogIC9QcmV2IDEwOTUgMCBSCj4+CmVuZG9iagoxMDk3IDAgb2JqCjw8L1Rp dGxlICj+/wAxADIALgAxAC4AoABOAG8AcgBtAGEAdABpAHYAZQAgAFIAZQBmAGUAcgBlAG4AYwBl AHMpCiAgL1BhcmVudCA5OTcgMCBSCiAgL0Rlc3QgL19fV0tBTkNIT1JfNW0KICAvQ291bnQgMAog IC9OZXh0IDEwOTggMCBSCiAgL1ByZXYgMTA5NiAwIFIKPj4KZW5kb2JqCjEwOTggMCBvYmoKPDwv VGl0bGUgKP7/ADEAMgAuADIALgCgAEkAbgBmAG8AcgBtAGEAdABpAHYAZQAgAFIAZQBmAGUAcgBl AG4AYwBlAHMpCiAgL1BhcmVudCA5OTcgMCBSCiAgL0Rlc3QgL19fV0tBTkNIT1JfNW8KICAvQ291 bnQgMAogIC9OZXh0IDEwOTkgMCBSCiAgL1ByZXYgMTA5NyAwIFIKPj4KZW5kb2JqCjEwOTkgMCBv YmoKPDwvVGl0bGUgKP7/AEEAcABwAGUAbgBkAGkAeAAgAEEALgCgACAAQQB1AGcAbQBlAG4AdABl AGQAIABCAGEAYwBrAHUAcwAtAE4AYQB1AHIAIABGAG8AcgBtACAAXCgAQQBCAE4ARgBcKQAgAFMA eQBuAHQAYQB4KQogIC9QYXJlbnQgOTk3IDAgUgogIC9EZXN0IC9fX1dLQU5DSE9SXzVxCiAgL0Nv dW50IDAKICAvTmV4dCAxMTAwIDAgUgogIC9QcmV2IDEwOTggMCBSCj4+CmVuZG9iagoxMTAwIDAg b2JqCjw8L1RpdGxlICj+/wBBAC4AMQAuAKAAIAAiAGMAbABpAGUAbgB0AF8AaQBkACIAIABTAHkA bgB0AGEAeCkKICAvUGFyZW50IDk5NyAwIFIKICAvRGVzdCAvX19XS0FOQ0hPUl81cwogIC9Db3Vu dCAwCiAgL05leHQgMTEwMSAwIFIKICAvUHJldiAxMDk5IDAgUgo+PgplbmRvYmoKMTEwMSAwIG9i ago8PC9UaXRsZSAo/v8AQQAuADIALgCgACAAIgBjAGwAaQBlAG4AdABfAHMAZQBjAHIAZQB0ACIA IABTAHkAbgB0AGEAeCkKICAvUGFyZW50IDk5NyAwIFIKICAvRGVzdCAvX19XS0FOQ0hPUl81dQog IC9Db3VudCAwCiAgL05leHQgMTEwMiAwIFIKICAvUHJldiAxMTAwIDAgUgo+PgplbmRvYmoKMTEw MiAwIG9iago8PC9UaXRsZSAo/v8AQQAuADMALgCgACAAIgByAGUAcwBwAG8AbgBzAGUAXwB0AHkA cABlACIAIABTAHkAbgB0AGEAeCkKICAvUGFyZW50IDk5NyAwIFIKICAvRGVzdCAvX19XS0FOQ0hP Ul81dwogIC9Db3VudCAwCiAgL05leHQgMTEwMyAwIFIKICAvUHJldiAxMTAxIDAgUgo+PgplbmRv YmoKMTEwMyAwIG9iago8PC9UaXRsZSAo/v8AQQAuADQALgCgACAAIgBzAGMAbwBwAGUAIgAgAFMA eQBuAHQAYQB4KQogIC9QYXJlbnQgOTk3IDAgUgogIC9EZXN0IC9fX1dLQU5DSE9SXzV5CiAgL0Nv dW50IDAKICAvTmV4dCAxMTA0IDAgUgogIC9QcmV2IDExMDIgMCBSCj4+CmVuZG9iagoxMTA0IDAg b2JqCjw8L1RpdGxlICj+/wBBAC4ANQAuAKAAIAAiAHMAdABhAHQAZQAiACAAUwB5AG4AdABhAHgp CiAgL1BhcmVudCA5OTcgMCBSCiAgL0Rlc3QgL19fV0tBTkNIT1JfNjAKICAvQ291bnQgMAogIC9O ZXh0IDExMDUgMCBSCiAgL1ByZXYgMTEwMyAwIFIKPj4KZW5kb2JqCjExMDUgMCBvYmoKPDwvVGl0 bGUgKP7/AEEALgA2AC4AoAAgACIAcgBlAGQAaQByAGUAYwB0AF8AdQByAGkAIgAgAFMAeQBuAHQA YQB4KQogIC9QYXJlbnQgOTk3IDAgUgogIC9EZXN0IC9fX1dLQU5DSE9SXzYyCiAgL0NvdW50IDAK ICAvTmV4dCAxMTA2IDAgUgogIC9QcmV2IDExMDQgMCBSCj4+CmVuZG9iagoxMTA2IDAgb2JqCjw8 L1RpdGxlICj+/wBBAC4ANwAuAKAAIAAiAGUAcgByAG8AcgAiACAAUwB5AG4AdABhAHgpCiAgL1Bh cmVudCA5OTcgMCBSCiAgL0Rlc3QgL19fV0tBTkNIT1JfNjQKICAvQ291bnQgMAogIC9OZXh0IDEx MDcgMCBSCiAgL1ByZXYgMTEwNSAwIFIKPj4KZW5kb2JqCjExMDcgMCBvYmoKPDwvVGl0bGUgKP7/ AEEALgA4AC4AoAAgACIAZQByAHIAbwByAF8AZABlAHMAYwByAGkAcAB0AGkAbwBuACIAIABTAHkA bgB0AGEAeCkKICAvUGFyZW50IDk5NyAwIFIKICAvRGVzdCAvX19XS0FOQ0hPUl82NgogIC9Db3Vu dCAwCiAgL05leHQgMTEwOCAwIFIKICAvUHJldiAxMTA2IDAgUgo+PgplbmRvYmoKMTEwOCAwIG9i ago8PC9UaXRsZSAo/v8AQQAuADkALgCgACAAIgBlAHIAcgBvAHIAXwB1AHIAaQAiACAAUwB5AG4A dABhAHgpCiAgL1BhcmVudCA5OTcgMCBSCiAgL0Rlc3QgL19fV0tBTkNIT1JfNjgKICAvQ291bnQg MAogIC9OZXh0IDExMDkgMCBSCiAgL1ByZXYgMTEwNyAwIFIKPj4KZW5kb2JqCjExMDkgMCBvYmoK PDwvVGl0bGUgKP7/AEEALgAxADAALgCgACAAIgBnAHIAYQBuAHQAXwB0AHkAcABlACIAIABTAHkA bgB0AGEAeCkKICAvUGFyZW50IDk5NyAwIFIKICAvRGVzdCAvX19XS0FOQ0hPUl82YQogIC9Db3Vu dCAwCiAgL05leHQgMTExMCAwIFIKICAvUHJldiAxMTA4IDAgUgo+PgplbmRvYmoKMTExMCAwIG9i ago8PC9UaXRsZSAo/v8AQQAuADEAMQAuAKAAIAAiAGMAbwBkAGUAIgAgAFMAeQBuAHQAYQB4KQog IC9QYXJlbnQgOTk3IDAgUgogIC9EZXN0IC9fX1dLQU5DSE9SXzZjCiAgL0NvdW50IDAKICAvTmV4 dCAxMTExIDAgUgogIC9QcmV2IDExMDkgMCBSCj4+CmVuZG9iagoxMTExIDAgb2JqCjw8L1RpdGxl ICj+/wBBAC4AMQAyAC4AoAAgACIAYQBjAGMAZQBzAHMAXwB0AG8AawBlAG4AIgAgAFMAeQBuAHQA YQB4KQogIC9QYXJlbnQgOTk3IDAgUgogIC9EZXN0IC9fX1dLQU5DSE9SXzZlCiAgL0NvdW50IDAK ICAvTmV4dCAxMTEyIDAgUgogIC9QcmV2IDExMTAgMCBSCj4+CmVuZG9iagoxMTEyIDAgb2JqCjw8 L1RpdGxlICj+/wBBAC4AMQAzAC4AoAAgACIAdABvAGsAZQBuAF8AdAB5AHAAZQAiACAAUwB5AG4A dABhAHgpCiAgL1BhcmVudCA5OTcgMCBSCiAgL0Rlc3QgL19fV0tBTkNIT1JfNmcKICAvQ291bnQg MAogIC9OZXh0IDExMTMgMCBSCiAgL1ByZXYgMTExMSAwIFIKPj4KZW5kb2JqCjExMTMgMCBvYmoK PDwvVGl0bGUgKP7/AEEALgAxADQALgCgACAAIgBlAHgAcABpAHIAZQBzAF8AaQBuACIAIABTAHkA bgB0AGEAeCkKICAvUGFyZW50IDk5NyAwIFIKICAvRGVzdCAvX19XS0FOQ0hPUl82aQogIC9Db3Vu dCAwCiAgL05leHQgMTExNCAwIFIKICAvUHJldiAxMTEyIDAgUgo+PgplbmRvYmoKMTExNCAwIG9i ago8PC9UaXRsZSAo/v8AQQAuADEANQAuAKAAIAAiAHUAcwBlAHIAbgBhAG0AZQAiACAAUwB5AG4A dABhAHgpCiAgL1BhcmVudCA5OTcgMCBSCiAgL0Rlc3QgL19fV0tBTkNIT1JfNmsKICAvQ291bnQg MAogIC9OZXh0IDExMTUgMCBSCiAgL1ByZXYgMTExMyAwIFIKPj4KZW5kb2JqCjExMTUgMCBvYmoK PDwvVGl0bGUgKP7/AEEALgAxADYALgCgACAAIgBwAGEAcwBzAHcAbwByAGQAIgAgAFMAeQBuAHQA YQB4KQogIC9QYXJlbnQgOTk3IDAgUgogIC9EZXN0IC9fX1dLQU5DSE9SXzZtCiAgL0NvdW50IDAK ICAvTmV4dCAxMTE2IDAgUgogIC9QcmV2IDExMTQgMCBSCj4+CmVuZG9iagoxMTE2IDAgb2JqCjw8 L1RpdGxlICj+/wBBAC4AMQA3AC4AoAAgACIAcgBlAGYAcgBlAHMAaABfAHQAbwBrAGUAbgAiACAA UwB5AG4AdABhAHgpCiAgL1BhcmVudCA5OTcgMCBSCiAgL0Rlc3QgL19fV0tBTkNIT1JfNm8KICAv Q291bnQgMAogIC9OZXh0IDExMTcgMCBSCiAgL1ByZXYgMTExNSAwIFIKPj4KZW5kb2JqCjExMTcg MCBvYmoKPDwvVGl0bGUgKP7/AEEALgAxADgALgCgACAARQBuAGQAcABvAGkAbgB0ACAAUABhAHIA YQBtAGUAdABlAHIAIABTAHkAbgB0AGEAeCkKICAvUGFyZW50IDk5NyAwIFIKICAvRGVzdCAvX19X S0FOQ0hPUl82cQogIC9Db3VudCAwCiAgL05leHQgMTExOCAwIFIKICAvUHJldiAxMTE2IDAgUgo+ PgplbmRvYmoKMTExOCAwIG9iago8PC9UaXRsZSAo/v8AQQBwAHAAZQBuAGQAaQB4ACAAQgAuAKAA IABBAGMAawBuAG8AdwBsAGUAZABnAGUAbQBlAG4AdABzKQogIC9QYXJlbnQgOTk3IDAgUgogIC9E ZXN0IC9fX1dLQU5DSE9SXzZzCiAgL0NvdW50IDAKICAvTmV4dCAxMTE5IDAgUgogIC9QcmV2IDEx MTcgMCBSCj4+CmVuZG9iagoxMTE5IDAgb2JqCjw8L1RpdGxlICj+/wBBAHAAcABlAG4AZABpAHgA IABDAC4AoAAgAEUAZABpAHQAbwByACcAcwAgAE4AbwB0AGUAcykKICAvUGFyZW50IDk5NyAwIFIK ICAvRGVzdCAvX19XS0FOQ0hPUl82dQogIC9Db3VudCAwCiAgL05leHQgMTEyMCAwIFIKICAvUHJl diAxMTE4IDAgUgo+PgplbmRvYmoKMTEyMCAwIG9iago8PC9UaXRsZSAo/v8AQQB1AHQAaABvAHIA cwAnACAAQQBkAGQAcgBlAHMAcwBlAHMpCiAgL1BhcmVudCA5OTcgMCBSCiAgL0Rlc3QgL19fV0tB TkNIT1JfNncKICAvQ291bnQgMAogIC9QcmV2IDExMTkgMCBSCj4+CmVuZG9iago5OTcgMCBvYmoK PDwvVGl0bGUgKP7/AFQAaABlACAATwBBAHUAdABoACAAMgAuADAAIABBAHUAdABoAG8AcgBpAHoA YQB0AGkAbwBuACAARgByAGEAbQBlAHcAbwByAGsAIABkAHIAYQBmAHQALQBpAGUAdABmAC0AbwBh AHUAdABoAC0AdgAyAC0AMgA4KQogIC9QYXJlbnQgOTk2IDAgUgogIC9EZXN0IC9fX1dLQU5DSE9S XzIKICAvQ291bnQgMAogIC9GaXJzdCA5OTggMCBSCiAgL0xhc3QgMTEyMCAwIFIKPj4KZW5kb2Jq Cjk5NiAwIG9iago8PC9UeXBlIC9PdXRsaW5lcyAvRmlyc3QgOTk3IDAgUgovTGFzdCA5OTcgMCBS Pj4KZW5kb2JqCjExMjEgMCBvYmoKPDwKL1R5cGUgL0NhdGFsb2cKL1BhZ2VzIDIgMCBSCi9PdXRs aW5lcyA5OTYgMCBSCi9QYWdlTW9kZSAvVXNlT3V0bGluZXMKL0Rlc3RzIDw8Ci9maWxlIzNhIzJm IzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRo IzJkdjIuaHRtbC5odG1sIzIzVVNBU0NJSSA4MzAgMCBSCi9maWxlIzNhIzJmIzJmIzJmdmFyIzJm dG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5o dG1sIzIzRmlndXJlIzJkMSAxNTMgMCBSCi9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJ dGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzRmln dXJlIzJkMiAxOTcgMCBSCi9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2 LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzRmlndXJlIzJkMyAz NDEgMCBSCi9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRy YWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzRmlndXJlIzJkNCAzOTkgMCBSCi9m aWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0 ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzRmlndXJlIzJkNSA0NDYgMCBSCi9maWxlIzNhIzJm IzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRo IzJkdjIuaHRtbC5odG1sIzIzRmlndXJlIzJkNiA0NzQgMCBSCi9maWxlIzNhIzJmIzJmIzJmdmFy IzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRt bC5odG1sIzIzZXh0ZW5zaW9ucyA1NjggMCBSCi9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJm Q0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIz cmVzcG9uc2UjMmR0eXBlIzJkZXh0IDU3MyAwIFIKL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAj MmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwj MjNleHQjMmRncmFudCA0OTAgMCBSCi9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVt cDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzQ1NSRiA2 NzYgMCBSCi9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRy YWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzdG9rZW4jMmR0eXBlcyA1NTAgMCBS Ci9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJk aWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzUkZDMzk4NiA3NTYgMCBSCi9maWxlIzNhIzJm IzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRo IzJkdjIuaHRtbC5odG1sIzIzUkZDNDk0OSA3NDQgMCBSCi9maWxlIzNhIzJmIzJmIzJmdmFyIzJm dG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5o dG1sIzIzSSMyZEQuaWV0ZiMyZG9hdXRoIzJkdjIjMmR0aHJlYXRtb2RlbCA4MzIgMCBSCi9fX1dL QU5DSE9SXzVxIDgyNyAwIFIKL19fV0tBTkNIT1JfNmEgOTE4IDAgUgovZmlsZSMzYSMyZiMyZiMy ZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYy Lmh0bWwuaHRtbCMyM3BhcmFtZXRlcnMjMmRyZWdpc3RyeSA3MTEgMCBSCi9fX1dLQU5DSE9SXzVz IDgyOCAwIFIKL19fV0tBTkNIT1JfNmMgOTE5IDAgUgovX19XS0FOQ0hPUl81dSA4MzMgMCBSCi9f X1dLQU5DSE9SXzZlIDkyMiAwIFIKL19fV0tBTkNIT1JfNXcgODc4IDAgUgovX19XS0FOQ0hPUl82 ZyA5MjMgMCBSCi9fX1dLQU5DSE9SXzV5IDg4MSAwIFIKL19fV0tBTkNIT1JfNmkgOTI0IDAgUgov X19XS0FOQ0hPUl82ayA5MjcgMCBSCi9fX1dLQU5DSE9SXzZtIDk2NiAwIFIKL19fV0tBTkNIT1Jf Nm8gOTY3IDAgUgovX19XS0FOQ0hPUl82cSA5NjAgMCBSCi9fX1dLQU5DSE9SXzZzIDk2MSAwIFIK L19fV0tBTkNIT1JfNnUgOTg1IDAgUgovX19XS0FOQ0hPUl82dyA5ODYgMCBSCi9maWxlIzNhIzJm IzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRo IzJkdjIuaHRtbC5odG1sIzIzcmVzcG9uc2UjMmR0eXBlIzJkcmVnaXN0cnkgNzI3IDAgUgovZmls ZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYj MmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMyM3Rva2VuIzJkcmVzcG9uc2UgNTEyIDAgUgovZmlsZSMz YSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRv YXV0aCMyZHYyLmh0bWwuaHRtbCMyM3Rva2VuIzJkaXNzdWUgNDg5IDAgUgovX19XS0FOQ0hPUl81 MCA2OTEgMCBSCi9fX1dLQU5DSE9SX2EgMTMgMCBSCi9fX1dLQU5DSE9SXzFxIDMwMCAwIFIKL19f V0tBTkNIT1JfMmEgMzUxIDAgUgovX19XS0FOQ0hPUl81MiA2OTIgMCBSCi9fX1dLQU5DSE9SX2Mg MTA3IDAgUgovX19XS0FOQ0hPUl8xcyAzMDEgMCBSCi9fX1dLQU5DSE9SXzJjIDM2MiAwIFIKL19f V0tBTkNIT1JfNTQgNzA2IDAgUgovX19XS0FOQ0hPUl9lIDE1MSAwIFIKL19fV0tBTkNIT1JfMXUg Mjk5IDAgUgovX19XS0FOQ0hPUl8yZSAzNzMgMCBSCi9fX1dLQU5DSE9SXzU2IDcwNyAwIFIKL19f V0tBTkNIT1JfZyAxNTIgMCBSCi9fX1dLQU5DSE9SXzF3IDMxNyAwIFIKL19fV0tBTkNIT1JfMmcg MzgzIDAgUgovX19XS0FOQ0hPUl81OCA3MDggMCBSCi9fX1dLQU5DSE9SX2kgMTY2IDAgUgovX19X S0FOQ0hPUl8xeSAzMTkgMCBSCi9fX1dLQU5DSE9SXzJpIDM4NCAwIFIKL19fV0tBTkNIT1JfayAx NjcgMCBSCi9fX1dLQU5DSE9SXzJrIDQwMSAwIFIKL19fV0tBTkNIT1JfbSAxODUgMCBSCi9fX1dL QU5DSE9SXzJtIDQwOCAwIFIKL19fV0tBTkNIT1JfbyAxNzggMCBSCi9fX1dLQU5DSE9SXzJvIDQy NCAwIFIKL19fV0tBTkNIT1JfNjAgODgyIDAgUgovX19XS0FOQ0hPUl9xIDE3OSAwIFIKL19fV0tB TkNIT1JfMnEgNDM0IDAgUgovX19XS0FOQ0hPUl8zYSA0OTEgMCBSCi9fX1dLQU5DSE9SXzYyIDg4 MyAwIFIKL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJh ZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjNncmFudCMyZGNvZGUgMzM4IDAgUgov X19XS0FOQ0hPUl9zIDE4MiAwIFIKL19fV0tBTkNIT1JfMnMgNDQ5IDAgUgovX19XS0FOQ0hPUl8z YyA1MTMgMCBSCi9fX1dLQU5DSE9SXzY0IDg4NSAwIFIKL19fV0tBTkNIT1JfdSAxOTYgMCBSCi9m aWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0 ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzY2xpZW50IzJkdHlwZXMgMjI3IDAgUgovX19XS0FO Q0hPUl8ydSA0NDQgMCBSCi9fX1dLQU5DSE9SXzNlIDUxMCAwIFIKL19fV0tBTkNIT1JfNjYgODc0 IDAgUgovX19XS0FOQ0hPUl93IDIwOSAwIFIKL19fV0tBTkNIT1JfMncgNDQ3IDAgUgovX19XS0FO Q0hPUl8zZyA1MzYgMCBSCi9fX1dLQU5DSE9SXzY4IDkyMCAwIFIKL19fV0tBTkNIT1JfeSAyMTIg MCBSCi9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0 IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzYW5jaG9yNTAgNzI4IDAgUgovX19XS0FO Q0hPUl8yeSA0NTkgMCBSCi9fX1dLQU5DSE9SXzNpIDUzNyAwIFIKL2ZpbGUjM2EjMmYjMmYjMmZ2 YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5o dG1sLmh0bWwjMjNhbmNob3I1MSA3MjkgMCBSCi9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJm Q0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIz YW5jaG9yNTIgNzUzIDAgUgovX19XS0FOQ0hPUl8zayA1NTEgMCBSCi9fX1dLQU5DSE9SXzNtIDU1 MyAwIFIKL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJh ZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjNhbmNob3I1NSA4MzcgMCBSCi9maWxl IzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMy ZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzYW5jaG9yNTYgODM4IDAgUgovZmlsZSMzYSMyZiMyZiMy ZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYy Lmh0bWwuaHRtbCMyM2FjY2VzcyMyZHJlc291cmNlIDUzOCAwIFIKL19fV0tBTkNIT1JfM28gNTY5 IDAgUgovZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFm dCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMyM2FuY2hvcjU3IDgzOSAwIFIKL2ZpbGUj M2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJk b2F1dGgjMmR2Mi5odG1sLmh0bWwjMjNhbmNob3I1OCA4NDAgMCBSCi9fX1dLQU5DSE9SXzNxIDU3 MSAwIFIKL19fV0tBTkNIT1JfNGEgNjI0IDAgUgovZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMy ZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMy M2FuY2hvcjU5IDg4NCAwIFIKL19fV0tBTkNIT1JfM3MgNTcyIDAgUgovX19XS0FOQ0hPUl80YyA2 NDIgMCBSCi9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRy YWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzZXJyb3IjMmRyZWdpc3RyeSA3MzAg MCBSCi9fX1dLQU5DSE9SXzN1IDU3NCAwIFIKL19fV0tBTkNIT1JfNGUgNjQ0IDAgUgovX19XS0FO Q0hPUl8zdyA1ODkgMCBSCi9fX1dLQU5DSE9SXzRnIDYzOSAwIFIKL2ZpbGUjM2EjMmYjMmYjMmZ2 YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5o dG1sLmh0bWwjMjN0b2tlbiMyZHJlcSAzODYgMCBSCi9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1w IzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1s IzIzYW5jaG9yNjAgODc1IDAgUgovZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1 MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMyM2dyYW50IzJk aW1wbGljaXQgNDAwIDAgUgovX19XS0FOQ0hPUl8zeSA1OTEgMCBSCi9fX1dLQU5DSE9SXzRpIDY1 NSAwIFIKL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJh ZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjNhbmNob3I2MSA4NzYgMCBSCi9maWxl IzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMy ZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzYW5jaG9yNjIgODc3IDAgUgovX19XS0FOQ0hPUl80ayA2 NTcgMCBSCi9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRy YWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzYW5jaG9yNjMgODc5IDAgUgovZmls ZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYj MmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMyM2FuY2hvcjY0IDg4MCAwIFIKL19fV0tBTkNIT1JfNG0g NjU4IDAgUgovZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZk cmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMyM2FuY2hvcjY1IDkyNSAwIFIKL2Zp bGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRm IzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjNhbmNob3I2NiA5MjYgMCBSCi9fX1dLQU5DSE9SXzRv IDY1OSAwIFIKL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJm ZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjNhbmNob3I2NyA5MjggMCBSCi9m aWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0 ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzYW5jaG9yNjggOTI5IDAgUgovX19XS0FOQ0hPUl80 cSA2NzQgMCBSCi9fX1dLQU5DSE9SXzVhIDczMSAwIFIKL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0 bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0 bWwjMjNhbmNob3I2OSA5MzAgMCBSCi9fX1dLQU5DSE9SXzRzIDY3NSAwIFIKL19fV0tBTkNIT1Jf NWMgNzMyIDAgUgovX19XS0FOQ0hPUl80dSA2OTMgMCBSCi9fX1dLQU5DSE9SXzVlIDczMyAwIFIK L2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRp ZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjN0b2MgMTYgMCBSCi9fX1dLQU5DSE9SXzR3IDY4 NSAwIFIKL19fV0tBTkNIT1JfNWcgNzI2IDAgUgovZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMy ZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMy M3Jlc291cmNlIzJkZXJyb3JzIDU1MiAwIFIKL19fV0tBTkNIT1JfNHkgNjg4IDAgUgovX19XS0FO Q0hPUl81aSA3NDYgMCBSCi9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2 LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzYW5jaG9yNzAgOTIx IDAgUgovZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFm dCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMyM2FuY2hvcjcxIDk2MiAwIFIKL19fV0tB TkNIT1JfNWsgNzQ4IDAgUgovZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3 Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMyM2FuY2hvcjcyIDk2 MyAwIFIKL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJh ZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjNhbmNob3I3MyA5NjQgMCBSCi9maWxl IzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMy ZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzUkZDMjYxNiA3NDkgMCBSCi9fX1dLQU5DSE9SXzVtIDc1 MCAwIFIKL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJh ZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjNSRkM2MTI1IDgzNSAwIFIKL2ZpbGUj M2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJk b2F1dGgjMmR2Mi5odG1sLmh0bWwjMjNSRkMyNjE3IDc1NCAwIFIKL2ZpbGUjM2EjMmYjMmYjMmZ2 YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5o dG1sLmh0bWwjMjNhbmNob3I3NCA5NjUgMCBSCi9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJm Q0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIz UkZDMjI0NiA3NDcgMCBSCi9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2 LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzYW5jaG9yNzUgOTg3 IDAgUgovX19XS0FOQ0hPUl81byA4MjMgMCBSCi9fX1dLQU5DSE9SXzEwIDIxMCAwIFIKL19fV0tB TkNIT1JfMTIgMjEzIDAgUgovX19XS0FOQ0hPUl8xNCAyMjggMCBSCi9fX1dLQU5DSE9SXzE2IDIy OSAwIFIKL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJh ZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjNSRkMyODE4IDc1MSAwIFIKL19fV0tB TkNIT1JfMTggMjQ0IDAgUgovZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3 Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMyM3JlZGlyZWN0IzJk dXJpIDI4MCAwIFIKL19fV0tBTkNIT1JfMjAgMzIwIDAgUgovZmlsZSMzYSMyZiMyZiMyZnZhciMy ZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwu aHRtbCMyM1czQy5SRUMjMmRodG1sNDAxIzJkMTk5OTEyMjQgODI1IDAgUgovX19XS0FOQ0hPUl8y MiAzMjEgMCBSCi9fX1dLQU5DSE9SXzIgMTEgMCBSCi9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1w IzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1s IzIzZ3JhbnQjMmRwYXNzd29yZCA0MzUgMCBSCi9fX1dLQU5DSE9SXzI0IDMzOSAwIFIKL19fV0tB TkNIT1JfNCAxMiAwIFIKL19fV0tBTkNIT1JfMjYgMzQwIDAgUgovX19XS0FOQ0hPUl82IDE0IDAg UgovZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMy ZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMyM3RscyAyMTEgMCBSCi9maWxlIzNhIzJmIzJm IzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJk djIuaHRtbC5odG1sIzIzcGFzc3dvcmQjMmR0b2sjMmRyZXEgNDQ1IDAgUgovX19XS0FOQ0hPUl8y OCAzNDIgMCBSCi9fX1dLQU5DSE9SXzggMTUgMCBSCi9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1w IzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1s IzIzYW5jaG9yMTAgMTk1IDAgUgovZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1 MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMyM2FuY2hvcjEx IDIwNiAwIFIKL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJm ZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjNhbmNob3IxMiAyMDcgMCBSCi9m aWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0 ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzYW5jaG9yMTMgMjA4IDAgUgovZmlsZSMzYSMyZiMy ZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMy ZHYyLmh0bWwuaHRtbCMyM2FuY2hvcjE0IDIyNiAwIFIKL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0 bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0 bWwjMjNhbmNob3IxNSAyNjAgMCBSCi9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVt cDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzYW5jaG9y MTYgMjYxIDAgUgovX19XS0FOQ0hPUl8zMCA0NjEgMCBSCi9maWxlIzNhIzJmIzJmIzJmdmFyIzJm dG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5o dG1sIzIzYW5jaG9yMTcgMjYyIDAgUgovZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRl bXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMyM2FuY2hv cjE4IDI4MSAwIFIKL19fV0tBTkNIT1JfMzIgNDc2IDAgUgovX19XS0FOQ0hPUl8zNCA0NzggMCBS Ci9fX1dLQU5DSE9SXzM2IDQ5MiAwIFIKL19fV0tBTkNIT1JfMzggNDkzIDAgUgovZmlsZSMzYSMy ZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0 aCMyZHYyLmh0bWwuaHRtbCMyM2FuY2hvcjI0IDMxOCAwIFIKL2ZpbGUjM2EjMmYjMmYjMmZ2YXIj MmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1s Lmh0bWwjMjNhbmNob3IyNSAzMzcgMCBSCi9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJ dGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzYW5j aG9yMjYgMzg1IDAgUgovX19XS0FOQ0hPUl80MCA1OTIgMCBSCi9maWxlIzNhIzJmIzJmIzJmdmFy IzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRt bC5odG1sIzIzYW5jaG9yMjcgNDQ4IDAgUgovX19XS0FOQ0hPUl8xYSAyNDcgMCBSCi9maWxlIzNh IzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9h dXRoIzJkdjIuaHRtbC5odG1sIzIzYW5jaG9yMjggNDYyIDAgUgovZmlsZSMzYSMyZiMyZiMyZnZh ciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0 bWwuaHRtbCMyM2NsaWVudCMyZHBhc3N3b3JkIDI0NiAwIFIKL19fV0tBTkNIT1JfNDIgNjEwIDAg UgovZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMy ZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMyM0kjMmRELmRyYWZ0IzJkaGFyZHQjMmRvYXV0 aCMyZDAxIDgzNCAwIFIKL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYu ZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjNhbmNob3IyOSA0Nzcg MCBSCi9fX1dLQU5DSE9SXzFjIDI0OCAwIFIKL19fV0tBTkNIT1JfNDQgNjExIDAgUgovX19XS0FO Q0hPUl8xZSAyNjMgMCBSCi9fX1dLQU5DSE9SXzQ2IDYyNSAwIFIKL19fV0tBTkNIT1JfMWcgMjY0 IDAgUgovX19XS0FOQ0hPUl80OCA2MjYgMCBSCi9fX1dLQU5DSE9SXzFpIDI2NSAwIFIKL2ZpbGUj M2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJk b2F1dGgjMmR2Mi5odG1sLmh0bWwjMjNhbmNob3IzMCA0OTQgMCBSCi9maWxlIzNhIzJmIzJmIzJm dmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIu aHRtbC5odG1sIzIzYW5jaG9yMzEgNTY3IDAgUgovX19XS0FOQ0hPUl8xayAyNzcgMCBSCi9maWxl IzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMy ZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzYW5jaG9yMzIgNTkwIDAgUgovZmlsZSMzYSMyZiMyZiMy ZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYy Lmh0bWwuaHRtbCMyM2FuY2hvcjMzIDYwOCAwIFIKL19fV0tBTkNIT1JfMW0gMjc4IDAgUgovZmls ZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYj MmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMyM2FuY2hvcjM0IDYwOSAwIFIKL2ZpbGUjM2EjMmYjMmYj MmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2 Mi5odG1sLmh0bWwjMjNjbGllbnQjMmRpZGVudGlmaWVyIDI0OSAwIFIKL2ZpbGUjM2EjMmYjMmYj MmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2 Mi5odG1sLmh0bWwjMjNuZXcjMmR0eXBlcyA1NzAgMCBSCi9maWxlIzNhIzJmIzJmIzJmdmFyIzJm dG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5o dG1sIzIzYW5jaG9yMzUgNjIxIDAgUgovX19XS0FOQ0hPUl8xbyAyNzkgMCBSCi9maWxlIzNhIzJm IzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRo IzJkdjIuaHRtbC5odG1sIzIzYW5jaG9yMzYgNjIyIDAgUgovZmlsZSMzYSMyZiMyZiMyZnZhciMy ZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwu aHRtbCMyM3Jlc3BvbnNlIzJkdHlwZSAyODIgMCBSCi9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1w IzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1s IzIzYW5jaG9yMzcgNjIzIDAgUgovZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1 MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMyM2FuY2hvcjM4 IDY0MCAwIFIKL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJm ZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjNjbGllbnQjMmRyZXEgNDc1IDAg UgovZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMy ZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMyM2FuY2hvcjM5IDY0MSAwIFIKL2ZpbGUjM2Ej MmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1 dGgjMmR2Mi5odG1sLmh0bWwjMjNvcGVuIzJkcmVkaXJlY3QgNjg2IDAgUgovZmlsZSMzYSMyZiMy ZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMy ZHYyLmh0bWwuaHRtbCMyM2VuZHBvaW50IzJkcGFyYW1zIDU3NSAwIFIKL2ZpbGUjM2EjMmYjMmYj MmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2 Mi5odG1sLmh0bWwjMjNhbmNob3I0MCA2NDMgMCBSCi9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1w IzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1s IzIzYW5jaG9yNDEgNjYwIDAgUgovZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1 MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMyM2FuY2hvcjQy IDY1MyAwIFIKL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJm ZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjNpbXBsaWNpdCMyZGF1dGh6IzJk cmVzcCA0MjIgMCBSCi9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRp ciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzYW5jaG9yNDMgNjU0IDAg UgovZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMy ZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMyM0kjMmRELmlldGYjMmRvYXV0aCMyZHNhbWwy IzJkYmVhcmVyIDgyNCAwIFIKL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAz NzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjNhbmNob3I0NCA2 NzIgMCBSCi9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRy YWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzYW5jaG9yNDUgNjczIDAgUgovZmls ZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYj MmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMyM2FuY2hvcjQ2IDY4OSAwIFIKL2ZpbGUjM2EjMmYjMmYj MmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2 Mi5odG1sLmh0bWwjMjNhbmNob3I0NyA2OTAgMCBSCi9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1w IzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1s IzIzYW5jaG9yNDggNzA5IDAgUgovZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1 MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMyM2FuY2hvcjQ5 IDcxMCAwIFIKL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJm ZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjNjb2RlIzJkYXV0aHojMmRlcnJv ciAzNzQgMCBSCi9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMy ZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzdG9rZW4jMmRlcnJvcnMgNTEx IDAgUgovZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFm dCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMyM0kjMmRELmlldGYjMmRvYXV0aCMyZHYy IzJkaHR0cCMyZG1hYyA4MzEgMCBSCi9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVt cDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzdG9rZW4j MmRlbmRwb2ludCMyZGF1dGggMzIyIDAgUgovZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNH SXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMyM1JG QzUyMzQgNzU4IDAgUgovZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5k aXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMyM1JGQzU4NDkgODI5IDAg UgovZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMy ZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMyM1JGQzQ2MjcgNzU1IDAgUgovZmlsZSMzYSMy ZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0 aCMyZHYyLmh0bWwuaHRtbCMyM1JGQzUyNDYgNzU5IDAgUgovZmlsZSMzYSMyZiMyZiMyZnZhciMy ZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwu aHRtbCMyM25ldyMyZGVycm9ycyA1OTMgMCBSCi9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJm Q0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIz Y29kZSMyZGF1dGh6IzJkcmVzcCAzNjEgMCBSCi9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJm Q0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIz aW1wbGljaXQjMmRhdXRoeiMyZHJlcSA0MDkgMCBSCi9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1w IzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1s IzIzUkZDNTIyNiA3NTcgMCBSCi9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUw Mzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzSSMyZEQuaWV0 ZiMyZG9hdXRoIzJkdjIjMmRiZWFyZXIgODM2IDAgUgovZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRt cCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRt bCMyM2FuY2hvcjEgMTA4IDAgUgovZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1 MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMyM2FuY2hvcjIg MTU0IDAgUgovZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZk cmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMyM2FuY2hvcjMgMTUwIDAgUgovZmls ZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYj MmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMyM2FuY2hvcjQgMTY0IDAgUgovZmlsZSMzYSMyZiMyZiMy ZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYy Lmh0bWwuaHRtbCMyM2FuY2hvcjUgMTY1IDAgUgovZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMy ZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMy M2FuY2hvcjYgMTgwIDAgUgovZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3 Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMyM2FuY2hvcjcgMTgx IDAgUgovZmlsZSMzYSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFm dCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwuaHRtbCMyM2FuY2hvcjggMTgzIDAgUgovZmlsZSMz YSMyZiMyZiMyZnZhciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRv YXV0aCMyZHYyLmh0bWwuaHRtbCMyM2FuY2hvcjkgMTg0IDAgUgovZmlsZSMzYSMyZiMyZiMyZnZh ciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0 bWwuaHRtbCMyM3JmYy5yZWZlcmVuY2VzMSA3NDUgMCBSCi9maWxlIzNhIzJmIzJmIzJmdmFyIzJm dG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5o dG1sIzIzcmZjLnJlZmVyZW5jZXMyIDgyNiAwIFIKL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAj MmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwj MjNpbXBsaWNpdCMyZGF1dGh6IzJkZXJyb3IgNDIzIDAgUgovZmlsZSMzYSMyZiMyZiMyZnZhciMy ZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0bWwu aHRtbCMyM2NsaWVudCMyZGF1dGhlbnRpY2F0aW9uIDI0NSAwIFIKL2ZpbGUjM2EjMmYjMmYjMmZ2 YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5o dG1sLmh0bWwjMjNzY29wZSAzMzYgMCBSCi9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJ dGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzdHlw ZSMyZHJlZ2lzdHJ5IDY4NyAwIFIKL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1w NTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjNyZmMuYXV0 aG9ycyA5ODQgMCBSCi9maWxlIzNhIzJmIzJmIzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRp ciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJkdjIuaHRtbC5odG1sIzIzdG9rZW4jMmRyZWZyZXNo IDUzNSAwIFIKL2ZpbGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJm ZHJhZnQjMmRpZXRmIzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjNSRkMyMTE5IDc1MiAwIFIKL2Zp bGUjM2EjMmYjMmYjMmZ2YXIjMmZ0bXAjMmZDR0l0ZW1wNTAzNzYuZGlyIzJmZHJhZnQjMmRpZXRm IzJkb2F1dGgjMmR2Mi5odG1sLmh0bWwjMjNhbnRocm9weSA2NTYgMCBSCi9maWxlIzNhIzJmIzJm IzJmdmFyIzJmdG1wIzJmQ0dJdGVtcDUwMzc2LmRpciMyZmRyYWZ0IzJkaWV0ZiMyZG9hdXRoIzJk djIuaHRtbC5odG1sIzIzZ3JhbnQjMmRjbGllbnQgNDYwIDAgUgovZmlsZSMzYSMyZiMyZiMyZnZh ciMyZnRtcCMyZkNHSXRlbXA1MDM3Ni5kaXIjMmZkcmFmdCMyZGlldGYjMmRvYXV0aCMyZHYyLmh0 bWwuaHRtbCMyM2NvZGUjMmRhdXRoeiMyZHJlcSAzNTIgMCBSCj4+Cj4+CmVuZG9iago5ODMgMCBv YmoKPDwKL1R5cGUgL1BhZ2UKL1BhcmVudCAyIDAgUgovQ29udGVudHMgMTEyMiAwIFIKL1Jlc291 cmNlcyAxMTI0IDAgUgovQW5ub3RzIDExMjUgMCBSCi9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCj4+ CmVuZG9iagoxMTI0IDAgb2JqCjw8Ci9Db2xvclNwYWNlIDw8Ci9QQ1NwIDQgMCBSCi9DU3AgL0Rl dmljZVJHQgovQ1NwZyAvRGV2aWNlR3JheQo+PgovRXh0R1N0YXRlIDw8Ci9HU2EgMyAwIFIKPj4K L1BhdHRlcm4gPDwKPj4KL0ZvbnQgPDwKL0Y2IDYgMCBSCi9GMTAgMTAgMCBSCi9GOSA5IDAgUgo+ PgovWE9iamVjdCA8PAo+Pgo+PgplbmRvYmoKMTEyNSAwIG9iagpbIDk4OCAwIFIgOTg5IDAgUiA5 OTAgMCBSIDk5MSAwIFIgOTkyIDAgUiA5OTMgMCBSIDk5NCAwIFIgOTk1IDAgUiBdCmVuZG9iagox MTIyIDAgb2JqCjw8Ci9MZW5ndGggMTEyMyAwIFIKL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3Ry ZWFtCnic7V1Lb+Q2Er73r9B5gfGI1BtYBBj32AvsYYGBDewhyCGYbLII7GCdHPL3V8+WVJ+or8ih xj2BbSS2Od1ksZ5fFYvq9/94+DH55Y/k/fnhf8nn8ef54ZTepEUzfCVp+/1uOWDrm8ym3VdSm+ym rPrRz8+nl+Tl9On0qf3/y8mU/RvHH+0/Tkuk/fcfn387vR8WPw0jD+d/tb/9mdjkn+1/vybf/9AO /jTO173g+VQ3ZUtHmpqs/fNp+Wdd2eam7H99al8s/uxe/N/Tv/+W/NYRZm/qnngzELj8811pbN5u r06bLyL5ZX5rS0bWWFOUtfP35cRZNtKTJ6bJi24TqW23no2/p0U7XtQ3eT/e8qA0efeHsXLcVjd2 HL/M8+SYv2PPzwuam2z8cv6+onlJW2W6ZQeal2vVeScqpG01vtjLZZ4nx/yS5kh8dtDsosEllyP4 vC3r5/W4is/buuHSpUh8Lsqi6teq1/pclFXar1WvaRDjF5oX8zw55o+mz+12sl7W9Vo3irIpe34C bavxxV4u8zw55j+Izw6aXTS45HIEn7dl/bweV/F5WzdcurSmeQprDTh5r1hR5nmSt//ahcfEFMnv /2lX+dTHgoCIY/rvJTHDiCPivOy88fbx9P6+TEyaPP6cDBS8G348DlS/a8m27V8/JX/viPouefz1 1AXYccD2A9U8kPUD9TyQy1cMc9w9jvs/iNe2+SZ5nZmjeB0IV1523thvqCW4BVIbOypsu6GqLuqR GJtLciX9phb0m49yQ1a+pWBMsQMPcsmleSC7k5yuGGHpMFDMA/diDmO2hTMvi/yAOej2UQXuBGF8 ++aeTgq7pcsik2/7gWZ+xZluH1go6TAf5LKlWAXmMA0lPUCDBrmYdGd3wEN/DqGyA8sG2s2OLuN+ 5TJ8v6i6HyWpJVN/xXbPcrvBouo9YLgry+tm7cvyYR1jdgQOxEphKdwMZRq6CC5vas0KPyxXiWMj wCHuZosY8h1DVZU5dRMcL9AuX6HgyAfGVR7dFGZFY4a5pZuTOgRelO82/yBVt5LSBgcAvprbg+SY TSULpaviBoJ2KeeAVa4WdSDHMGRwM/RXdnPnb/4YRCLsF0OVnMNqd/elUaU0wu2gi5QbRnXmG+bo jbIVWKIIdzzMwCoceEh8h96Nht0As0LPZGIowBh26lovOojuwFRpM2giEXIGdF48IwBKwfEg4OPK zeEOCBMIkYEoJGcCewBvDuFOTjpm69XOpHJzWa3U1Cs0MvDDAEP8s10FT2FSoAMDIjBV7u6oCGHL tYfYiKLUqyJ4CzCzD0xpojAaVIAjrwD9xiKBNE20Vc5lzhC+fxsxrDTpBCssZBG0BIBlEzkHssgf mwGLUNxRajG0roZ5Fsw6vGUv4Uct4tlbQOT1T00VCECxXXgPmARkaxEAn0IzIySJ4BF5bqqoeCIP IfUElyA3Y3Ipbv/cfHTecbxKZvQOn4MCwFVAO3CIlqI24jf33rQ6ywWh2B0gHFAiqhC4XWAIN0yw MpiUW1kAFqNlBO6YFEcivKoIFqNAfMAQkDZXfxA/cAjEb5mDtB8ZmAk5aKFywByB+zYozb0dTREb 0553xHHteTkRwmt1SDzVIe4fOR5UmD83IR4NoOrmX+8Eu1QgiIBEDY4QeG0Piqr+538xUJk9g5IF 1JAocAezQ0vlp6rc+cfIj6nTVagQzAFv4ZCLxksUA5glrfagsnP3wOUCiR0EQ0A6PGvhCQZYIUe+ 54iOu5ww+YZN0UMlnnOH1Dal/A8qkBmbrznwhhh0iOFrp9yK0yD/8q+ixwp8u38U5ucFqP6LjHvu bxxuRbRfzt9XXXmK1/OePc9Fe2truq7JDWPri9F1OlcABv1cFDhG5WrcAy4ZLpQcAvadVK6aij2V lCkCNOhwIZ0pJw3V/CzfMoSocl7mXgZkGrLH9issRnrZ23lDR8H9HtkbWqelnZiAtTKeTtMiPWKd kESfgnD0XEAIPesK2QyALno2glrBD/IgXYATV65qvADF8WJANSmg/gjoiMoWxQDLQgbKG315+yig dC79ABbSAiV2AsIcNEVXqBTNBRRNWyBssDn/1iCMGnAiz3cLqRCvpUinpIB1EaqvCsvmvWOOTDBG KlSnVTVRBvV6KgfEddRvKU5B/Vs4Q5whhDF6xIlKBtovWag4Foe+0AhVjoD8Q6Hs/kfeinoM6Acv PoKeBpQ9qBVi2yBMSg+aFAfe3OUCP3g3bgxHxkta9CiGBylFz1OAagf0Zh5iUZwO0DGqMAodg3ZG hw+KEz4a61Ih0NwQVY6BUWh17hgVgmDJDzMPwfQ8LQLCgHSuU9cC0P3Pg9/SIm+ux2uPqc3lqvRG KR7O2QKCMr+JxwXBj2J4Fw5V3RiRPkqFgxfiIQjxTAHsAaAQrxpBYSXGtQzuQfx7PUK8ENRO8RyW J/1yd1nj77mw4ge74bDNUV9+JajjhfQCjvsoSlE07oBy80IjV27tW+K48qxwBjt+hRqeU8ArzwrX BcLEWQ/B/rRixdN8xVk9dZmvhSh5KQkiqH+vWxRBcTFAoALljhB1FM2RsFt+iOJfA1agEt6Bq7Cx CMVoDCm0LSEGxghwsrxdLvxGrU8kU9hpwMl9lLaU0jbrEOLaTZxIVejl/S1jyhiunDIoAA0q0hSu dxQNKvInjigidOHZ222T2YtC/g92OKQSFFJMA37wC8dHKH8MDBIlsgMd/g+LiFpwqS6X5+FKOshS cTGIqr/iyT8Ktvq3HEY5OYlRCgRnF9CDTDMdBRriBxT8ypI/xoiC0vlBGr9sBjcWY7RPwxz0IgSq FEBfUFz/JyPwY1R+Es3vPSiuBdMuQrz2wZ9Hwe/r8ttX3NdhNORYiMKWg9q6i7pZO3d+mV6BZLQP pIkTmJrLU33gdgC/9et/2zJku7CKtmt/TxPBIdALq7zRYiPo+h+2ah6WyGd9e7yop4a8PSrRW2Oi 3MD4Cz1cMCIY/lLf3tRr5x6xGSlK2LFp7VTEr3N46t/8HaAiCkp5/wFf9pCejhh3Z6/1/PHKgHoc k8qme/EYUiK0wShE91W6WxWVP97IH3Dn3/9MbwNRROi6RiQbAA/86ykx3EEOnwxAn07MH9dRmO0I +k028/Ln2/hHy5C7DwHxw9898Jo11gLAkQXkV1fbvRijdh7pXDBbRxS1CcWJZIVxLRNw/BzlOhmF ByhNOPXm9WZeLPkLX9jOrPvC9ugZ9u4NW/kKeqMZLjDDFWdUHaAM7lrj5Wu5ruuW3M7Aq92KTnfk VQg26W1/c1aT5etp7b3UfrjGfpYiNZLXuXTDd9tWuJhjLLelOyOjPMod0uTCWSpfIecYA/Vi0oEB Vmo9uOEdOjKfWrHrQ5+aqpfMfA0eSL8DuwD358jR54E8k7tb0C4/dqtTaoNK3SlRR2l2U3QuqNNV sxx4Oj2oPslrazniEN2T7fJ2UvsLcw2gZPnAFeStjBPjh1gsddhR3V8kVrAuP2aTFqqgHVQH3lJK NbiTSn4rl12Aj6O8oVN+aV9qy6p8Mg7oqU2ly5HQOKLmV4XQ/GngejX/wjnU0UZGeTlgpAYCK/OG DbyZxlGPTxmBwuWx8HGyk0lvwqfdQTV5aqLOOhI7T2sB20kAMuY4OzgAkYJEG+OpGmQfC+X6KG2L YglcFiC178n0niRMdogkjHjefOmWBPIIuFgyliCPfD4KbB+R5XZq3L12RJbbcopLpimWA1cbl2bm psA56boRb1nJOis985U6c4Jz8mx6csmr4pw8qyd9ykyxHLhefbpw7rVwjiyi8AHUUejngyf8QNbu OEnaQ0IAfKhpwBy4CrwFQFywRS7c7Mj21wRceRGMYfYA1xdMuxfmyzzqrBOxl2kRcAGckmF+DNFQ Q/YpIynQk+/dmj0uVuUhXLxMm8MTMikXsSYGUMhxqAopEBTvo6Cn+QPtrh091c06q78MXG+0m7Mz yjlwsxbaaKVnhhCK8uEBQQZZRHGZPG6KohjfJvJr9e0akF+RmostFGY5cLW2MHPulZBfDBM8xOLQ EiiuA5NcAq72O3lpJWfKXgTjj8/PoTbTxZj9FySfTv8HI15QUWVuZHN0cmVhbQplbmRvYmoKMTEy MyAwIG9iagozMDU0CmVuZG9iagoxMTI2IDAgb2JqCjw8IC9UeXBlIC9Gb250RGVzY3JpcHRvcgov Rm9udE5hbWUgL1FJUkJBQStEZWphVnVTYW5zLUJvbGQKL0ZsYWdzIDQgCi9Gb250QkJveCBbLTEw NjkuMzM1OTMgLTQxNS4wMzkwNjIgMTk3NS4wOTc2NSAxMTc0LjMxNjQwIF0KL0l0YWxpY0FuZ2xl IDAgCi9Bc2NlbnQgOTI4LjIyMjY1NiAKL0Rlc2NlbnQgLTIzNS44Mzk4NDMgCi9DYXBIZWlnaHQg OTI4LjIyMjY1NiAKL1N0ZW1WIDQzLjk0NTMxMjUgCi9Gb250RmlsZTIgMTEyNyAwIFIKPj4gZW5k b2JqCjExMjcgMCBvYmoKPDwKL0xlbmd0aDEgMTYxMTIgCi9MZW5ndGggMTEzMCAwIFIKL0ZpbHRl ciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtCnic7RtdbxtZ9dpJu+WWXbYLrBCI5W5gpRbNOkvLrlAL iIkzSbx17GBP0u0TjD3X9rT2jDUzThoeEOIFJJDgARAf4o03fgBI7Bu8IV6QEC+gfVgQvCFWWgmk peWcc+982U42TdIPJOLGvnPnfH/dMycuKzHGzrGvsQXGmu3ly2+9+r2fws634XenP9zv3fvQ+idh /Rf4XRtIx+2+UXuZsZIB168MYOP8Z578Oly7cP2JwSi+c+5j7A9w/U2kOgy6Dvs4+yBcfxeuz46c O2N2hr0Hrn8I18J3RjJ87idAu/RLxj73Mistfr/8OkCwM1fO/Ah2n1OfC39kvfIzjJXPn1tYOLtY Li/+jVXu/Z69fY9/4suXgBLb6lkuE0zcu3f2A3c/UPrxE6PSm19mpXugGf6UWe/uDxZ7Z34GWj7B 2PsvPH/hhecvPN9bZO9ECx955693f/DEU/96Kzx7iZVYUHq9/Gb5DbTH+wEmKMf/+Xb5jbt/Rjol 9fvrX/z4N19632ffZpp84SfhVGJn0z3AeWJ096OMPc3ude51FntEKf9TXvwd6y20WADrD4LNFK8y MCgnFGZ+Plz6fLr/w9JlvS6x86U39brMFkv/1usF9nRZ6PUirNt6fYa9t/xVvT7L3lf+uV6fYxfA Cmp9nn104UW9fvKZn178hl4/xT597Tt6/TQ7f+1Pen2BLV57CziWFtHXLxF3XJfYs6Xf6jXoVvqH Xi8wUbqr14tMlD+l12fYh8quXp9lz5W/pdfn2FL5V3p9nl0t/1Ovn3zh6sJ1vX6KDa69oNdPs2ev /UavL7Bz1/7OqmDpMdtnIfNYnw1YDNFzkXXZJfi8zF6C1xVYdQBCsBWAiVkEvyGTzGEjZsBujfkA X4GVyYbwEqyV0oroSsKnBJxdeHcBkh+B6yspVxs47QKvW4DjAzTK4QDO/XFchdUtwNthE4DoAqxD 1CRhOKSRACo+vI8BpgN0PYATgB8Ad4fuccaqwXg/9PqDWFzsXhKXX3rpiujsixUvjuJQOiND1Pxu RZjDoWghVCRaMpLhrnQrfAb1FUS1nd3RrcDvixVncADiqrzl7ExEd+D4fRkJJ5TC88V40hl6XeEG I8fzQbKiim1SMIJthdx2fLhYAWWGoBJbCYbuQSgiA8shi2Oj7JAvIrBgQPa9DB65Ai+2I8PIC3xx uXLlSpFyQvfFabpI9sV5kvSIuAqAWIdnIksv8MGeMbiHUZDE4OKrbBlerqaxCzQqgBvAZwhul0Qv pACpAF0JOGwQx+Ory8suEN2dVKJgEnZlLwj7suJLuL2WkyAJqCSoZ1MH72GQSgp0CToGbA9gMaxP J1iR0jrc2QeYAWF6cG9MesWUGGi1kDAwlZDq7pQlp/XIknFSSMaDtOHwmqe7CgkHVnmrzZYFDhFw /Bc/Uqk5/QI339+Zzh7c4bSKaQejcES2vg17AXjg3WRBzbaI3oioZcnlkUwDuie1Xn3i4muvG9rv yluKm4oxFe8GyRWQ933CH+sEVhwCoBrrGPN0FDhEQ1maa5oxSTEdT12CwzhU1BMKCK1kV7EsKf9V 7C3lomSJPIe4Ln1GJFcXcBytH6cs6EKEjohKTHcS+/RgNdSZdDGVMeOANQ3ljyF+VfQjx8wmuDOm rHGBQ5ewE2lc0iCmWOvA3ZjuKh78EA6GzuYuSDYhKsomexQDA6pKsbbMiPbyGiU6hIWoVNJOyIZG zju4HpE/la95roJEgG0coIeR6rlMFUQQZZUPiranrVr0/uFaJ5ZT0o7TiI5JrizqMo32yB6jI3FI sqFHVd3XGsocR5fekYdBn2iJWwDRJXoKJvFfj04iVdkSD3WJt0sSe1rSq5SdtpbOAYoBVYbMB/la lFlgthL4AB/rbIgKsEmuZBbL14A8niCdHZKcU20uxpqyhjpLnEP8GdApKLTvR/SZ1Y+j+CKmkwhP VkdrVClY6jBctMm+PlsUd7R5j2R0dSQNKU7DdEdJijZ1cz7PR11ygjp0InpUM4Z0xVONXJIU/eXn rNEvnKuKU1JDHYoeFbsJj2n7RO+qUyIl1xpkEeaQj44uQZHPtD3myWZofw8JzzugmvPUOyHVWYfq SkY32YnSiEzyZfr0kLrOSdIi4bRHWrmEvzTnPFxK9Z7G4HAvOW2XclGmcqY+db50KN+DnKwTnQdJ nOzCXW+OxSS7Q3b2dSaP4aVOL4cqqkwx8n5XMic7fG6mDKjCC/qMtIySIumgOElq3bza7dJJ4JPf 8/aaZ1Wes1zeh8fN1Uj370JrkmRbkknYOQzT3iPUGEWKY4ro2/De1x5T5yFGFU+r6oOsVAdr1dE5 EuvzsJdaaoNZxKfJGnCFfJpwZbMb0Ee26F4N9gT0cS24swNXq7C7Sn4x6Q7eX6JsvAFrpNhk20RL 0WjBO9K+CTtIW9A1Xl0H+AbQQlyLvUY8LKDWBsmasEbam7Bbh09LwyFGFXa24RrX6wy7UMWvAVg2 5Q7ioSxKUhv2M65FqWrEMZFsE65aQH9D3zWBdo3oofwG9Ue4bmg5leVaRB1thJSRZhUkqtMV7m7D 5xbAtcmeJumspG2QDmtwX+likQTKE0qiKnxuAW+EWAe5bLICcrI1pEF+RH1WCR+5XicoJVlTexnX GZWKtqWSA+2/k3Juk/51eAnS34Ydm3xjAv2EbhI760QB5eZkjW3SzyQ7NInDCsGhFdGe9TTiWjmv VMle6DeUfJU4mWSR9lxNEmp578yLDp5yWCf9LLJUnaDbYEcL4GvpjorHGula1bZWNFXcq5io56xb JR3Rs18ErpaOKZNsV9QC/XSD5M+0UB4w9Xs1Z7PM+w3t3UQemzjbc6xyg3LRIiiTfN1Oc2SN8ndT S76dRlhWA7Z1fDZTyYr2TfIogTtK7VC0Et5FD65SPNW1hO3UGgqCH0JX1S4LzrUuPefEad0untz5 rjHrRvN9p5GrtflOQFXhdYIdTcFlu+ppSZ1Z2bNOvneb94SdPB2rXj7perPuQ9Vu9UyU73pd6s9V DxilXUlAfWCQdiZ7dDc708d6dhIUnvOQs0Nnv5HySs6ijJbqKx3qFpBbNMeaB59QfObJcEznveKy R+tYdyao30TD4v5Xpp6Gk/nPrA/EXB8kuszrHPL2D8nfY/0s5ZGFsZ+saLohS57LMpugBdTcbTTl 9Sz6kNpVNj1VQBv0c5K7ZGvO1AwPeXKqV8mM69FPnU57wP04zYN4YR403Xk9uHkQnzsPEg95HsSP NA8qdvLdnEzZrCOBPNoEdd6EhT+yuZKYmSvx/8+VcnOlbMLwvzlX4oUT9tHNlficp7XHYa7E586V Mo0ezlyJHzIveDhzJc7ud66U/dXpNOdKWb4V50oHnb4HT5fU87nqJB636RJnxenS/OnGw5ku8UOs K3IWfLynTJxibLabefhTJv4YT5n41JQpe9Z9mFMm/q5TJvHQpkz8PqZM4oFNmTjZYAeovkrSKmub cP/hzY74XJ8/qtkRn5kdiUc2O+IHzo6yGdCDnx3x+5gdHUb3wc6Oksp68IkyO/Hhx5j45Kc0pznx 4Sea+Mw+sx1v4sNzE5/D5g6nMaGJZ+h/gWWTBk588KrC2Bp9QQu/14bfjEu/TCcuRlKKjhwGe5cq 4gjfgquI9eH+eBAJbzQOwli6ohcGI2GGcld/CSzhQd+6m6hv3eXZcJ5x35GhI5Ro6Vf3+IuH/vDZ L/kd+fuBYoqzF3FHxKHjypET3hZBb5oK51syHHkRfYfOi8RAhhJ49UPHB9UN0B3UAjSwWNiXhogD 4fj7YizDCBCCTgwW88AEjuiC0Bwg44FM7NTtBqMxgCNAPADqYGXpR2C9JTLJ0iUg5gonioKu5wA/ 7gbdyUj6sROjPD1vCE66iBQJQbSDXrwH5l+6RJKEchwG7qQriYzrgWJeZxJLlIEXEAxwc3c4cVGS PS8eBJMYhBl5mhFyCJUpgewkAnhUxxAjiVpzCpBoYOR4GMhzOQhFJMEPAO2BqFr9KdYoHJAdo6Fj rkxHjPYGEFgzCOiG3iT0gaEkRDcQUWCIaNK5Jbsx7qB+vWAIwYYKdQPf9VCP6CrnNpBzOsGuJA1U FJEAaRD4QQxuiNQuemWcRYC6J6KBMxzyjtRWAzEgS5yCnoEPcRGKURDKuWqLeH8sew4wqiihindH zj5kC6C7Xs/DQHOGMYQeLICo47qkuTIdJqgTglyToRNyZOTKyOv7JEZf5SogYYQ6XSASIUYiTzTN CUlyYEAGc4bzCWicRI6MGojnD/eFlwtzjuqEEr9/T7C4iNCQ6JckPSTEnAwJaS8I3UgspXm4hLyT G3wJ03aJTAaeqet86UjIJKQ6AR+gTXYDLxVM3okhY4QzHkN6OZ2hxBtKd6CMC545ZeDEYuBEQFH6 BZtg1GXR7YqJ72qBM1E5Cac0PMyrUTDErCa3oZMcMcTqAbmSAI6d7m2nD4pBHvoBx1C9v6AqsIKC BSLKYQ+F2rDEWrNhi3Zzzb5htixRa4utVnOntmqtiiWzDddLhrhRszea27YAiJbZsG+K5powGzfF 9Vpj1RDWa1stq93mzZaobW7Vaxbs1RrV+vZqrbEuVgCv0bRFvbZZs4Go3SRUTapmtZHYptWqbsCl uVKr1+ybBl+r2Q2gCcK1hCm2zJZdq27XzZbY2m5tNdsW0FgFso1aY60FXKxNC5QAQtXm1s1WbX3D NgDJhk2D2y1z1do0W9cNAcSaoHJLEEgFpAQawtpB5PaGWa+LlZrdtluWuYmwaJ31RnPT4mvN7caq adeaDbFigSrmSt1SsoEq1bpZ2zTEqrlprqM6CRMEU+pk5uCIsG41rJZZN0R7y6rWcAF2rLWsqk2Q YHuwRJ3ErTYbbeuL27ABcAkLg9/YsIgFKGDCvypJRuo3QF2kYzdbdirKjVrbMoTZqrXRI2utJoiL /myuUQRsgz3ReQ0tL/oI92ajA6AQWyu4apl1INhGMWCDF2Ahuqw7XTmOMbZ1cqvSSGVU1U6DolYV AQjhdR8SV+3REo4lyCw6dVR1yw5sPI4NVXqpfEB0w0mkSq+7K6ECRlhKgpAHWEz2vIgyHY7AUaDO PBE5Q2AGWJhFBAW10hkCWpSKWUgonhyG49ADlL3Qi6GYCGcCu6H3FX0Mh/qYIg1EpgFyyYqDkj+U 0RhOKW9XDvcrABviWUaSeH4vCEdadTJfN76atAqx6BNxN4h5EPYrgnPquE7cOh31/0ecTh/EVR8k jtMH8awPEsfsg/hsH6SLfJcoRcmZMadBzRoWfpJeSSS9En88eiWu/PDAeiWuEvZEvRI/xV6JZ72S OGavxAt9wTF6JX5QrySO3ivxXK+UT99CuwTnORSJ02qXuG6XxInaJV4Ql54bT7tl4n4gTtwy8VNt mbhumcTxWyY+3TKJ47RMfG7LJO6nZeK2ubP5ahPFNjeO1R3xTPOTdEc86Y7ESbojnu+OxLG6Iz63 OxIn6Y4wWAuJkjY+/MDGR9xH48MPb3zEERofTo1PsXd494YmTuC/QE0Dr8BH5ST/Z3CZ5na34XeZ Zmcu/VWvQn9fHcNe8a+Fh/8Pw+U977a37EGxulMZD8bLumIe6z9+MvZfDXWkx2VuZHN0cmVhbQpl bmRvYmoKMTEzMCAwIG9iago0MTgyCmVuZG9iagoxMTI4IDAgb2JqCjw8IC9UeXBlIC9Gb250Ci9T dWJ0eXBlIC9DSURGb250VHlwZTIKL0Jhc2VGb250IC9EZWphVnVTYW5zLUJvbGQKL0NJRFN5c3Rl bUluZm8gPDwgL1JlZ2lzdHJ5IChBZG9iZSkgL09yZGVyaW5nIChJZGVudGl0eSkgL1N1cHBsZW1l bnQgMCA+PgovRm9udERlc2NyaXB0b3IgMTEyNiAwIFIKL0NJRFRvR0lETWFwIC9JZGVudGl0eQov VyBbMCBbNTk1IDQxMiBdCl0KPj4KZW5kb2JqCjExMjkgMCBvYmoKPDwgL0xlbmd0aCAzNjggPj4K c3RyZWFtCi9DSURJbml0IC9Qcm9jU2V0IGZpbmRyZXNvdXJjZSBiZWdpbgoxMiBkaWN0IGJlZ2lu CmJlZ2luY21hcAovQ0lEU3lzdGVtSW5mbyA8PCAvUmVnaXN0cnkgKEFkb2JlKSAvT3JkZXJpbmcg KFVDUykgL1N1cHBsZW1lbnQgMCA+PiBkZWYKL0NNYXBOYW1lIC9BZG9iZS1JZGVudGl0eS1VQ1Mg ZGVmCi9DTWFwVHlwZSAyIGRlZgoxIGJlZ2luY29kZXNwYWNlcmFuZ2UKPDAwMDA+IDxGRkZGPgpl bmRjb2Rlc3BhY2VyYW5nZQoyIGJlZ2luYmZyYW5nZQo8MDAwMD4gPDAwMDA+IDwwMDAwPgo8MDAw MT4gPDAwMDE+IDwyMDExPgplbmRiZnJhbmdlCmVuZGNtYXAKQ01hcE5hbWUgY3VycmVudGRpY3Qg L0NNYXAgZGVmaW5lcmVzb3VyY2UgcG9wCmVuZAplbmQKZW5kc3RyZWFtCmVuZG9iagoyNDMgMCBv YmoKPDwgL1R5cGUgL0ZvbnQKL1N1YnR5cGUgL1R5cGUwCi9CYXNlRm9udCAvRGVqYVZ1U2Fucy1C b2xkCi9FbmNvZGluZyAvSWRlbnRpdHktSAovRGVzY2VuZGFudEZvbnRzIFsxMTI4IDAgUl0KL1Rv VW5pY29kZSAxMTI5IDAgUj4+CmVuZG9iagoxMTMxIDAgb2JqCjw8IC9UeXBlIC9Gb250RGVzY3Jp cHRvcgovRm9udE5hbWUgL1FOUkJBQStOaW1idXNTYW5MLUJvbGQKL0ZsYWdzIDQgCi9Gb250QkJv eCBbLTE3MyAtMzA3IDEwOTcgOTc5IF0KL0l0YWxpY0FuZ2xlIDAgCi9Bc2NlbnQgOTc5IAovRGVz Y2VudCAtMzA3IAovQ2FwSGVpZ2h0IDk3OSAKL1N0ZW1WIDY5IAovRm9udEZpbGUyIDExMzIgMCBS Cj4+IGVuZG9iagoxMTMyIDAgb2JqCjw8Ci9MZW5ndGgxIDcwMjAgCi9MZW5ndGggMTEzNSAwIFIK L0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtCnicfVgJXFNXuj/fvTdhc2NJIgJCDCQqhi0k IUS2CAjIGtk32WRRIUhERHaRoqVurRU7btTngtRnHcd2arVaO4uvY52WcXhMf3Zex3as09979dU3 vk6r5PK+cxOq7et7ubnJOeee5Tvf8v/+5xIghDiReMKQsLoN7bVn9zW+hS2dhMiW16+trFnbnarC Mm3T1WODa5NzKta/xnpgfeOmLQtPez0gZL4XIUA2WKorr1556ztCvLFOtjVWbmkmiSQB6wexHtBU 2bh20buRSqzjfHARh/gRwr0vmkAJCMjdhYv1gjee5MKvQcNNAJkmT4Kx307sl4v9FhDiiZ0idTqd XiqTSqUSWlMplapFYif3neDvb8yJKA93cZsN/hvDe5PXHTOKJh4HMwdDsg1ygBVzfYIjbaXMvVvl i4OhqIhR4L7V0+OchqshCrIMpdDptJFKnFCpEuNH4oVraCLocnKxWLGIPlHpdRopXVzGhQPM94y+ vN/c/s5AUmL/lbayE89VePP3fDdmxlYslHgw3IJruhK5p0QEH7pL3MwHjMPdwQCrD//b88/98aXM 8PLtq1ekhIf6FmZdnYLwpf5pepQnZ/pD0deiB8SHhKI8Ys6JCiITS+maQZweZdFplQwKwkppG32K gimVWqoV1v/oNCnXZOh9AHz0GZprEAcx18MydAuhsbqaP1I+vMEAYGwcLikfboyObhwWPYD6Wn3/ /hFz3qv7+yLHGWZc07v/SM7roG5qqOW/g9Sh99o3XdmRkrLz3bbWd3ekoYRaQkQjgtVcUUJPOeDl iV+OqYLltin+rO0riK6BO3zHr0DN36YWADUQJgUt2Tb9EZfLmYknIdTcVHixHgteUo1Up5dwufxd pixPcwn4u9d+YRmJ4cy29JqChXCDuTHFv3UD8sv6qd9Mf8TUi2qIDNdX4GiFROPOBOEEWrFYJVYq 9e4apv4Yf3fXLgZ81DkqycI5fkELmWOcEZbwk1dthfwTALdZ73MsgKsqlSnGOWPQx/xFN8kS6otU yw5VO3zBSSyTo4r1qHIvoUp/5Jy37ZVZgbH1OWXdaXJYue3NFuv5SwAseKyvWdMIvpkvtpV1ZqhY 9hMgPhHGLGNia9PWVQ1n2hMATJf/5iEP3ToA0NFoXFPelhu3pfdQNUrSjxK8CcGEtUcFvMnfAg0E 8xOo+2jUnwKllJAI6h0oByObh85ItadzF/zCSfBOjA2HnArqtYJ34I6Y0M3XTXExUBf/Qd/ma4kd oNGYPujR5/m6us8SO7nOdlpQFGPVyqQilzku84tFN6GiOJf/bJzvPdnQBGXlJ+DAb8Err77pPizX e+c0bk+N21yXKTGtAEvoxP64reuy55uSCcqZglG1C6PKk6gEOX8QS1SnTj/hvUx97/u7U1N33+zt /pc9GQBpuz7oia5ICgJQJlUYjBVJgYFJFVwN5Bz80+DQx8NZWcN/HBz65GfZX0BkWX9OVl9ZRER5 f3ZmX3kkarEPxfgGJZjrwAxNhFTmrlSgSrR94D8lWezn7bp2JIQzPznHpE+JOFAwsLX5Y5Qd0QZG 0b/ZZ3EJRvm74E9vOkI0MU0hL5gQ9ip6swvtJ5GDRK6VA3t26gTwtj+zL9k+ZLD332xd9+8z/VQr UaiVcJRpMYkiJIj6KTpXACu4myZCMuNW+CvzokaN0IulMjkIOtIqdXrBJfVcuNIX4N6nfLw3eHHe oam6U7BAOlcWYNRYTx6HzPDnVl0ahtkS0POnoLVxVQ6kF1X5Bsq85igClgcztWfGgO9bGq1wt/ip Zzm7Ors6efmdfWlvboTuaHCIFK50P5ccF5fs6cE5O7k42TXJlaPUHnZNUuyluGtHXapM6Fj/Fv5e P988slzQ58GqVob5jS2fuffLG1BYPEJ1hTmAO49adXmqU9TqTWaXzcrce/I30DD9QMAM5DFF/A5C xAcFVHYgPg28Zwv21YVfFKID/GvLU1bD93/MpVP1h+OWHq4Ly1mXaJdprRUgw2Tzf1pi57z6CyYr NzMXPPTmnbgq4plYjvachegEcpalXwQ2T+4+RPOTo6f4u6Pn+UmIAuXPT3LmqcesmN5PzrGzph7R PbbjHqtwj25YETaoR2zE70HqNy3gDNl8I7TzbzMn2HAExXVdvDdzHo6jZxgxrktxpJQsxbXlwgYV jrCh0UzjWwB8yY8AP4Y6pe7l2pqx7qRYQ/TO6sjal3UPdQXxgRAYXxipL46Xy+OLRRO2B+YsKD72 xy7rRHbOyvmQuZrlQFPel5neWRIWXtKTkd5TpiH2nMz0oSQCtmqVVN0UBFHPEgnFWTlia98YZHkE S5YmLZ69d+jQIfAf44yNeYh7zCTDAOwceu7qVD/bhbNpYZSpYq7MYBlTZbvNqJkr/H84sn8aals8 o21gbkEXP/6X/+THoR/1O8kueXIOQ4yEYNxoEfUWEQ2JE7K03gEj9jQtpkgiewowkUqImEEX7EOj ixXq6DBaVFqyYql7cATAys4zNXVj3YlQUt3VDKk737G2XHl+FbTwzSHZBQwEGLJCqjYDFGRFMOu2 MkznunVt0M7KPBa4L+lMzd3bYMRcum5fXv3uiMQLPQ1jnSZT51hDzwVmnl963tKVGh9oKFid7me7 zvRZ13cAdDY196Kt29HWPxM0vFTwbq1UqnfgokqpdJAZz6f4OGPrdvCPONBQPdqVAhCn98ssqQ6v P6B5GFmYEAgQmFAYaam02/px8MbVmVB4dKKnecK8OCFkAWSZGQ/bCGjKetIzukvDYagvZ1VniWBv I+p2CUYardDVn/U6qUwkeJxCLDAfuZRDSKL6VVHwwliMkHGuTGLX65b1ZzbH+PvPXqgyLIF8bTBs rI4q8JHNd+bvi8HZdq8jJgk+5l82BjNFGR+wzIOCnZVa0FQO5hpKA+bKJFK3de5LAiINIPGcG7Ls l29XRezJnUhocFcsUkfBy1TKJJRSbccDmLE7K36WnVEBIwW/0CE1U7ukdpyp63rvdwBJA9c7a053 Z7jxD3wrcixbwc9nfklcfrk3c7FmpBlNmP0Ff2/nn17KMFpGataXAbxxImtIow4DKN+AK5umx0Xz kI9R/QjUUPWUkKGOnOy8EFUjd7ieUiVYkUpCSeIdjTbz0cjg7X2rAEJqXm0ZH94GzLEXjrzmxE/M geUQsPfusdUQuvv3X662xCFt29H+4lEXbk7tSzHmAoDYzWMbCrZXmCRLfGuKKuq72x9OJXRctBbs eHmxeo5CbVySVw3Q1oJyDiJ2adGrELso5AjoKtCHt2E20gdn0PDh/GP+v3hUPDf0pJXeooknpdwJ BFwcX4z77MB9LhU0rFIG0n0yEi+PZ3TsRHFHL1CJCMFBZKJW55DQAv7R6RHbhbLSnz8+8vxfT1a6 8BPzXttT/EKlBjQ1e0uze5fJpHOd2TvlQ7Et7QCNt/hP33iD//Tm+vR9v9+27xVqoY6O93akYFz7 69UUgEgbb+Io/nsTtSNfzARJpPKZMJH9BCTCAYq2mmGMlM6V4OEf7OOXUVIV3jCseagriguEoISC SJ0dFjnzd18zCWWFUHBkssdgXVehUsZhtJSUGOzQ2F0SHl7Sm5XeW6pBDXnwsVwm4pUPSkTRSiIR CJZSJUHZpA7CqAdWde8R/2s4DD5p6e7yBQtDF3gbchf7qRUKD7iBqHaHDXrSx4iXrEgHELlMikT4 N3eemzw0OUIk7D2ZT0COTFnCclxJ8jQkhTSAS8xsWCUXwpSuq3cX/ZBQ6ZU0OyQmHCirOd25Iq7t dF1odlrKEgiKL45cXT+Pn9RGJVzpffzBSrA9jixJVCLHSizVR+bFUK+JzefMY5UlUHz8495tt4dz YG5QbOiByJwY/4T4+OplOi3AkYPVXNufQbemLz29qzAsrLArHYmXlnrSEJ4P0uyZXshkgvk4GTrg Ldt51IxGNDHlzH77OJhztp/tHGzLznYFnkUxzD4TKxadFXgYpfmMSAL3wf9qEr+D/XJKJjrL2+Ca naHAxWfmuEgZszAHQ06gNOvwWaDAmOURyIudxF4SIX7lWqoo4aPSUUqhVFBZ3eXUu2UCHVPBJFRU lWFa41y85kJq4EJgODdlbNSiKYjW1VyZ+hSDyxqf7KsD8PP2To1nsvNLvRb7R7hr06JCF+g9osLN 3ftqg33d14BH4WFD7eNgNhsG3KVhdfrVyGSAWvwwyjhPiF2JIKMjGczIgkxeBR9CT+3JzfEA//jS 1ohr+rdv3tzOeCVuu2T9ywPAWb3gevPGFgs4MF2O+RJZJghu8X0qoS7zNEuqnh5w8HwjkdvzKj3i KBRwJShskZ9XCqZ1mgc/mM1/mdR7caP18kAKbNpaXQoJ7Wcaum/E5jPgCq6zvErj88sA+cxOpAEi TmrNDs+J9ofPml7vSIjreG1D97nlsS/VFL9YFwWQm7X+XW9Dkm+IHqC6+A71mfzpj0TnEX0c0W4/ uAghrRTQhu5AbheVm0ElpEQyjei8bQxyxYEBhmNF5YetMWBoPFT1at3CpV4gn1d35i+D/8T/4926 usvTr+z/OD/oLVYxTWILVUlp6UPvtm65NrASin3jDS2XticDtHzEf3buNf6zP1jB2v0bapdwZChq 9D9XMtt+0kSGTwlQkBw49TB/zvYVkwz+w3waPwAdTCjbNTX4kL8Kpq+YRtyTHq2gwNGBdE+U5Ovt HERIFz84DFEo85SjS3/bB4y0YkVjBzCd69fUcvw9SO45t8F6fQjBwtR+smZlW2woUyg6OzWpNQDz 4sC2PVBSVHmkefmqoettll8OpMHSEAilsifg6ir0ATWJtedMlcPODsKEsvxgfceRlwI7+4OTGbZz c9zmS2Yb32nbMbFCHuI3C8Kj4if6N5zvW4kZynKorGgwARFRLPayFiaafd9f28qAPCYnREM9oNDM VSWaFksyMZttatS17jhedflxXp0FVu3+1Za6c12JsDwpyqT0n1/dCDGJfDuzq315ZaoyKLnC2N5I D480grnjGB2imZMDTPK3WN6mFd4s0B5oJ5Eae9iZJE1/rJoh/E3+bf4ifxO+xTx3mKux5zkjzmZA q3jOeNr3h3mdh4eHnjNMMcztRSVrMiUqo1oxG+TOSV3v9InOTpOgjj2DodlHTl9vGQM9qEB1eAbt TM9yfvvFzYFI/ne2CxSJmFM2ysDHmdDHwcwptI1h+kMhPhfTdymeDl+Yed+g+tHLJ2oUDxU6jafd LHYOm8msaBupGPpDgu8yfw/QhCePb7Nc3JYUaz1Wra8M9AhSwMOMctGl+jY0RVFVzUawgDlvd52h xRLWM3y66Og/zK1bAFbtuLxx49sDKT4LZikX81WwysTuYfb3xlQ3AOzu6dmH+zuEvMDoOA+4e9HX K/R9jeBAduG07pzzrj0vvgC41ZWrcv76/ODnuWkrEeNnDW4H2D7IPpqa1X3JlJaRkWa61M0+wjmP ow14h86eqkwOE8xNm5blnrzPlU5NPj0PChgZhYygGLOicELCrDjD/O1EVSOlUol+6oRkrL219gy6 mXuIwSejuFLz0Vrwt3394xMSZz7xBkDRkX/tNm56NX1JvHo+vGG7Jp73Z4go256Fh6SnTIAhR9Hm VpR/LkpDNBSv9ToPvfD2RUGpVyDrEXSUWZn7wj+nFZYjjyxM+3zMdglB2wtKAPiTnnGl9aB6/SwE bSha/SSYnQDek5dS5JajZlKQY7gJLI6yDHr+lDOTUM+PXrjIj+L/Xii8chkK8RwVxF+ATNsd220o 5EdRLmc+Ac4Jctm9WzAXpSeIlVpBw+f4uyr1HNmcZWXy7VscbzPUYSoATnQPmUjboPjAND1xjU5P i3KF82gAfSOmkUsd9GYmadi3KhdcUkHTlKM0yoz0vJko16ok0NHVtAZWxpnOtNpqce+ZDRYASwOK bLHgAdxq4feB1uCTmlcc0nRhVeLeNRkvR0dppwkUmFfngdl2DqrL11ShTsx8LdOIskiefZMk0yhn WI4eRop6coKCcnqKbpmbE/wwESc0m0UTA4+++HxT2xdf/L3/8PQn4xubxj/hj9CIVeN8Kfb5PHXf Q6Di6TuzxwXdOagSVU53wa1si2nhQpMlm6/t//v9z9s2/fX+o4Gj03fGLc3jn0wfQp3Xsr9iawR0 snuzp8bT8dvH3zNb8+Fz/gtzS75ogv+G/xZpuKv9n8D0bb6LG5l2paxFJJfIuZEnGu7WN7tQQpwT +r5HvKdzzUxCdyHce0i3bc3c5f9NCLb96IPzx4oPYk4FiouOD45hb/O3CHF5Hnv8XHxQmOnZTzyH P9znxA/vnZyVqBkDniwMxCy6QbTY1saM4TMricH2fvw3YlsK60f6sL4TxwZjmwHb+vA+6ORHOnCs K7a1Y91Ix+KtxTqdIxTb2oU5rCRZlE9M4jEyiOsU03WwzQP/k7E+JMxtFf77sH4C+x6m43DufPwP x1uPtwn702e0bqTjqCz4fxjbjuMzWj6KbXKcxxnLoyiLGW81e5PUctbp23Cf1Apa8CIm8jxed8h3 4AvJMASvwFdMCLOKqWC2MLeZb9jZbApbzw6wv2MfstOcF9fBvSeSiMyiU6LfimeLC8RD4n93Ypzm OQU6RThtdzrrLHLOdrY4n3PxdAl0iXapcul0+YPLlKvUtdR1p+uo6y03TzejW5Vbj9sLbkftdiLx eLEzVvtfHxFKyBJkpfjYgxBHGcgCrNnLDJkDyxxlDtujHWUxWQi5ZAWxkGbSTlpIA6kj9WQTRnop CcOMFEbyiJkUOGrhJBivZT/ZP5wYhCuAVOGT/298AEkka4lVGNuENaWjZTPeG4SZG7HUhLMa8ckK xzob8Gog1dhSh6V27FWPcwSQSlKD11q8Z1bOx7YN2LIey8nCyAbs3Ywzb35GrhXfyxSAp4EwvMKR H9lLWpKJYxpxvlZhjdU4Y5NQSsfdrEUJWnHWSpTr/+737BN7ezrOb0IpNpCa/wFs8MzOZW5kc3Ry ZWFtCmVuZG9iagoxMTM1IDAgb2JqCjUyMDcKZW5kb2JqCjExMzMgMCBvYmoKPDwgL1R5cGUgL0Zv bnQKL1N1YnR5cGUgL0NJREZvbnRUeXBlMgovQmFzZUZvbnQgL05pbWJ1c1NhbkwtQm9sZAovQ0lE U3lzdGVtSW5mbyA8PCAvUmVnaXN0cnkgKEFkb2JlKSAvT3JkZXJpbmcgKElkZW50aXR5KSAvU3Vw cGxlbWVudCAwID4+Ci9Gb250RGVzY3JpcHRvciAxMTMxIDAgUgovQ0lEVG9HSURNYXAgL0lkZW50 aXR5Ci9XIFswIFs0OTYgNjA2IDYwNiA1NTIgMjc2IDc3MiA3MTYgNjA2IDMzMCA1NTIgMjc2IDU1 MiA2MDYgMzg2IDI3NiA0OTYgNTUyIDYwNiA2MDYgODgyIDc3MiA1NTIgNjA2IDMzMCAzMzAgNTUy IDU1MiA2MDYgNTUyIDU1MiA2NjIgODI2IDcxNiA2MDYgNTUyIDYwNiA3MTYgMjc2IDU1MiAyNzYg NzE2IDY2MiA1NTIgNzcyIDU1MiA1NTIgNTUyIDYwNiA2NjIgNTUyIDcxNiA1NTIgNzE2IDY2MiA2 MDYgNzE2IDU1MiAyNzYgNzE2IDMzMCAzMzAgNDcwIDU1MiAyMzYgXQpdCj4+CmVuZG9iagoxMTM0 IDAgb2JqCjw8IC9MZW5ndGggODA1ID4+CnN0cmVhbQovQ0lESW5pdCAvUHJvY1NldCBmaW5kcmVz b3VyY2UgYmVnaW4KMTIgZGljdCBiZWdpbgpiZWdpbmNtYXAKL0NJRFN5c3RlbUluZm8gPDwgL1Jl Z2lzdHJ5IChBZG9iZSkgL09yZGVyaW5nIChVQ1MpIC9TdXBwbGVtZW50IDAgPj4gZGVmCi9DTWFw TmFtZSAvQWRvYmUtSWRlbnRpdHktVUNTIGRlZgovQ01hcFR5cGUgMiBkZWYKMSBiZWdpbmNvZGVz cGFjZXJhbmdlCjwwMDAwPiA8RkZGRj4KZW5kY29kZXNwYWNlcmFuZ2UKMiBiZWdpbmJmcmFuZ2UK PDAwMDA+IDwwMDAwPiA8MDAwMD4KPDAwMDE+IDwwMDNGPiBbPDAwNTQ+IDwwMDY4PiA8MDA2NT4g PDAwMjA+IDwwMDRGPiA8MDA0MT4gPDAwNzU+IDwwMDc0PiA8MDAzMj4gPDAwMkU+IDwwMDMwPiA8 MDA2Rj4gPDAwNzI+IDwwMDY5PiA8MDA3QT4gPDAwNjE+IDwwMDZFPiA8MDA0Nj4gPDAwNkQ+IDww MDc3PiA8MDA2Qj4gPDAwNjQ+IDwwMDY2PiA8MDAyRD4gPDAwNzY+IDwwMDM4PiA8MDA2Mj4gPDAw NzM+IDwwMDYzPiA8MDA1Mz4gPDAwNEQ+IDwwMDQzPiA8MDA3MD4gPDAwNzk+IDwwMDY3PiA8MDA0 RT4gPDAwNkM+IDwwMDMxPiA8MDA0OT4gPDAwNTI+IDwwMDUwPiA8MDAzMz4gPDAwNDc+IDwwMDM0 PiA8MDAzNT4gPDAwMzY+IDwwMDRDPiA8MDA1Nj4gPDAwMzc+IDwwMDQ4PiA8MDAzOT4gPDAwNTU+ IDwwMDQ1PiA8MDA3MT4gPDAwNDQ+IDwwMDc4PiA8MDA2QT4gPDAwNDI+IDwwMDI4PiA8MDAyOT4g PDAwMjI+IDwwMDVGPiA8MDAyNz4gXQplbmRiZnJhbmdlCmVuZGNtYXAKQ01hcE5hbWUgY3VycmVu dGRpY3QgL0NNYXAgZGVmaW5lcmVzb3VyY2UgcG9wCmVuZAplbmQKZW5kc3RyZWFtCmVuZG9iago5 IDAgb2JqCjw8IC9UeXBlIC9Gb250Ci9TdWJ0eXBlIC9UeXBlMAovQmFzZUZvbnQgL05pbWJ1c1Nh bkwtQm9sZAovRW5jb2RpbmcgL0lkZW50aXR5LUgKL0Rlc2NlbmRhbnRGb250cyBbMTEzMyAwIFJd Ci9Ub1VuaWNvZGUgMTEzNCAwIFI+PgplbmRvYmoKMTEzNiAwIG9iago8PCAvVHlwZSAvRm9udERl c2NyaXB0b3IKL0ZvbnROYW1lIC9RU1JCQUErTGliZXJhdGlvblNhbnMtQm9sZAovRmxhZ3MgNCAK L0ZvbnRCQm94IFstMTg0LjA4MjAzMSAtMzAzLjIyMjY1NiAxMDYyLjAxMTcxIDEwMzMuMjAzMTIg XQovSXRhbGljQW5nbGUgMCAKL0FzY2VudCA5MDUuMjczNDM3IAovRGVzY2VudCAtMjExLjkxNDA2 MiAKL0NhcEhlaWdodCA5MDUuMjczNDM3IAovU3RlbVYgMTA0Ljk4MDQ2OCAKL0ZvbnRGaWxlMiAx MTM3IDAgUgo+PiBlbmRvYmoKMTEzNyAwIG9iago8PAovTGVuZ3RoMSAzNTc2IAovTGVuZ3RoIDEx NDAgMCBSCi9GaWx0ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQp4nKVWW2wbWRn+z/gWx3HixM7F 8e2Mr4mTTO5xkiYxzqXdtklTcm13Q7dTexK7dTyWZ9I0gCjsViwrgZAQILSqWN7QCiQQT7CKeOB9 haoKLW+AkPaFFeKhCNhuvfxzfJKmu6EsyxyN5zv/fP/lnP+bkwABgDr4KpgAllf7h/559rXvoeWb eF/fKR5sJ52dryF+H8D0KK/IuewbF74MYP4j2sbyaHAEbSKApQPn0fyufsfzS5LE+RTOPUU1K5M/ m87h/DLOG3blO2Wwwz2cb+GcluRd5aH9x7dwjjHrDsBkfk84BAvUWd6wDAMQX+1pegDbQkudRXDY zIJxmX8Ews8uw53HwK/BzOocUBAfC5aH1c+TYdsM+cV1gDf/8C7WOmn5mpENBBzzAELOso6rtQEM N4vNMbFZnBdoNUp+UM1b1j/4ybz5HSCQ/ugvzG8Sq/DYrMZIhBNxNmJt7WwMt6XGUiPcaFBEt9gq msbQOlRjmCfFSGZWzt7d37x6ZkaMOInX5nL6vIlYqpCeJk3NvmBXz8i53r5Q9a+DpuUnP2/vzqQ3 dlZXJiaCQfK7W1de+txsNE4C/uHBhbnldjFE273OJjI/95WU1EdDLS5CvP6Yyfugej/m85JwZGpm bRPXlsHqRyzfhwzcgFdOrMBaK3Z0JDXGxmicG+LcwOtutdYcbK18qeTkMnG0evgWDNUcR92cEAmf TjCPBEPT6WvXX3n1mjydDgY72rsTo8PjU1K/GHa1EBo8M3l1Q//Si1fOTAT8xNUihqWBqenUSFe8 va16aLe3toWjY6PhSGur3V5n87hj0Ykz8YjHbbWKdkd7Z7I3M9XV3dFpdzjqO73JZDrd3eVtd9jJ t7YuLqXGQ5QQGhofW1p8cXF6sren02s3O4PBZDeWsLYwPzSIm+cLDAwtnF0ZHxrt7vEHGswOry/Z OzkljCejYZ+3yUmIs8nrC0eT8UjUH2jBK+CPRaNPvpvsTtCAp6XFE6SJ7r6xnt6Q6GpucYkhqQfF BiFUYB6VVA8B7AQqThwlYvNwK4mnam042msimn5affTkrrBKJg+r40QQCA5rvcPZ5HTVV39F7pNQ 9U8k9ND07Q/VB8IPXQFfwO/3uhrcbW3etg5XtQmzncXOJ7Dz43AFswk2a8R6QrVH3TjKGQk/2/9h 3u7YUTeP2m39WDcT5Buvf7h17sLoWCzeRurc/X0LE32oSLdL8Ijhrh6pf2Dr4uLIqD9AImI6vfWS fvDyF9JpMVT9vbPR50skhvtjcW+ns5E0NnR647GhRDwW9LtbhHerr7/9NvG0dHel05uxi9Gor3N8 bGNVTwRDbk+9QwzNTG+ul9SrmzNTNES6etY3733dNTU6koihSGuymRyXBsIRt6fRGfD1JsE43/C+ Z3b/5uWmqb8bh90nrhDuWh53jYD12IY+tpnqJZire+ejYaOHLNLJyyK8D/NmDdJ4Z/AO4X3OOPdA IxOkTD5gHhZ41ThbaxE/cfnJxrH9GvyaYwJNZJpjAcxkk2MThMh9js3gIe9xbIEGoZVjK7iFCxzb 4IumNY7rwGP6F8d2aDT3cuwAv3mP4waQzH/j2Al3rSGOG6HH+g/MTsx2nB2ySgxMIEgCHAtQR5Y4 NsEM2eLYDF3kkGMLdJDHHFshLoQ5tsEj4RrHddBl+i3HdqytkWMHjJvPcNwAW+bvcOyEqiXEcSNs WN+EOVChDAdQgQLsQB50PPvfwnsIBnCkEK2AAjl8vgAyvu1FdB5KkAUJUQaKOOgJb43NFHwq+LzN fA3mInrNwgJGy8Aa4mW4hNYC48t468iWkavALj4rcAttKmw/Nz/MqeWDSmEnr9O36NDAQIquKDn6 gqz30vOlrEQzxSJlrzVaUTSlclvJSXTx/OzCSmbt/PIlWtCoTPWKnFN25cotqm4/6w9YdAH/KCis NB2xiokprOKshIXDYuGGUpH1glqiq3IJDbPIKGKxMKsW8TeDpCy6l9i6Kujax3bieUHp0yAZLauU ckqF9tGPZaK1+J860unuG8xVO3YcxC01Wg4bSkUzuIPSQOr0LEc5+k7LYaToe16F/1/Xa/raYVF0 FrvGLLDY68hYZazLzNPYfZ1lKzHW2ikZlzHjNvobvXrKzLLYOs5rkVXEed7Hm7DHNK8h0/A7Wptm qPLEbv8XhaEsdwqarlTQWCjRdWlVopdlXSnpVC7l6Nqx4/L2diGrMGNWqegyklU9j9K4uVcpaLlC 1simSadJzvjAK/iJq8804am45tRKWa2VC7hzxo7dZvuwxOg6+5aZy6qu3FbokqzrimaQ8+x1Gf/t 68exz4aETs9WkOX5JYZ2kQl5XS9P9vfv7+9LMi8ji1VIWXW3/7OH1fEUKzMtKEzUO8itCVxiMXdR p89NrR+UlZyiFXZKqH8pr+8if50dZEeiNARQE+/pwt5mT0NuGvPQsXSZCfRI9BoK5wbKR2GiMSKq PK7BKXIRlnhWGRdheBtiPRLy3one7rN6svhLcfEqvjN8sixGmbUudyL6/1ozymldUwzR6nkU8glZ b6uoUE3d1vflimKIXNu7cVPJ6lRXkavQIoq1hK7yTkVRdg057zGt7ecL2Tw9UPeonM0qZR1lb9D/ U2Tps4uheMpaP6UMisfVcA0A/Btsu7bLZW5kc3RyZWFtCmVuZG9iagoxMTQwIDAgb2JqCjE5ODEK ZW5kb2JqCjExMzggMCBvYmoKPDwgL1R5cGUgL0ZvbnQKL1N1YnR5cGUgL0NJREZvbnRUeXBlMgov QmFzZUZvbnQgL0xpYmVyYXRpb25TYW5zLUJvbGQKL0NJRFN5c3RlbUluZm8gPDwgL1JlZ2lzdHJ5 IChBZG9iZSkgL09yZGVyaW5nIChJZGVudGl0eSkgL1N1cHBsZW1lbnQgMCA+PgovRm9udERlc2Ny aXB0b3IgMTEzNiAwIFIKL0NJRFRvR0lETWFwIC9JZGVudGl0eQovVyBbMCBbMzYyIDU1MiA1NTIg NTUyIDU1MiBdCl0KPj4KZW5kb2JqCjExMzkgMCBvYmoKPDwgL0xlbmd0aCAzOTIgPj4Kc3RyZWFt Ci9DSURJbml0IC9Qcm9jU2V0IGZpbmRyZXNvdXJjZSBiZWdpbgoxMiBkaWN0IGJlZ2luCmJlZ2lu Y21hcAovQ0lEU3lzdGVtSW5mbyA8PCAvUmVnaXN0cnkgKEFkb2JlKSAvT3JkZXJpbmcgKFVDUykg L1N1cHBsZW1lbnQgMCA+PiBkZWYKL0NNYXBOYW1lIC9BZG9iZS1JZGVudGl0eS1VQ1MgZGVmCi9D TWFwVHlwZSAyIGRlZgoxIGJlZ2luY29kZXNwYWNlcmFuZ2UKPDAwMDA+IDxGRkZGPgplbmRjb2Rl c3BhY2VyYW5nZQoyIGJlZ2luYmZyYW5nZQo8MDAwMD4gPDAwMDA+IDwwMDAwPgo8MDAwMT4gPDAw MDQ+IFs8MDAzNT4gPDAwMzg+IDwwMDM0PiA8MDAzOT4gXQplbmRiZnJhbmdlCmVuZGNtYXAKQ01h cE5hbWUgY3VycmVudGRpY3QgL0NNYXAgZGVmaW5lcmVzb3VyY2UgcG9wCmVuZAplbmQKZW5kc3Ry ZWFtCmVuZG9iago4IDAgb2JqCjw8IC9UeXBlIC9Gb250Ci9TdWJ0eXBlIC9UeXBlMAovQmFzZUZv bnQgL0xpYmVyYXRpb25TYW5zLUJvbGQKL0VuY29kaW5nIC9JZGVudGl0eS1ICi9EZXNjZW5kYW50 Rm9udHMgWzExMzggMCBSXQovVG9Vbmljb2RlIDExMzkgMCBSPj4KZW5kb2JqCjExNDEgMCBvYmoK PDwgL1R5cGUgL0ZvbnREZXNjcmlwdG9yCi9Gb250TmFtZSAvUVhSQkFBK0xpYmVyYXRpb25Nb25v Ci9GbGFncyA0IAovRm9udEJCb3ggWy0yNC40MTQwNjI1IC0zMDAuMjkyOTY4IDYwOC44ODY3MTgg ODMyLjUxOTUzMSBdCi9JdGFsaWNBbmdsZSAwIAovQXNjZW50IDgzMi41MTk1MzEgCi9EZXNjZW50 IC0zMDAuMjkyOTY4IAovQ2FwSGVpZ2h0IDgzMi41MTk1MzEgCi9TdGVtViA0MS4wMTU2MjUwIAov Rm9udEZpbGUyIDExNDIgMCBSCj4+IGVuZG9iagoxMTQyIDAgb2JqCjw8Ci9MZW5ndGgxIDE1MDE2 IAovTGVuZ3RoIDExNDUgMCBSCi9GaWx0ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQp4nKV6CWAU x5V2V3ePRjOaQ3P03Pd934eOkTQz0ggJ0C0kEKeQBiQOCaTBGIwPCOADGxvbiWMHn3FsE5PYu7GT 2Ovb3t2QmByb37v/nz2SrP9NNrG9m821jkHN/6pnRghBnH931RRT01PVVfXqe+9971UTiCCIWuIW giKIvqFw7A+e/Q1w504oW7bvOrDt4Zl/fQHqHxJE6FtTxfHJiR93GwkijO+lpuBG3Y1kHr7D74Rj anfp+ucVDRmCiNQTBJraNTsxztwu3EsQ0evh96/vHr9+D7GFuJ8gYhH4bpkZ31088P7PP4Hv/TCJ NQRFn0f3EDyilvcQLw5PMJY/qXFiGymv5ZF8WkCSPJKmHyPI57LE9ReIyl80N9ROZAnrBZL+OXsT 6ao5Q27fQhCP/vjvCIJu4hXwaAQiSKKDIMhJHoxE8AkiLrPKnFaZtYO0sA70eXaKt+aTZzvo89Cy RLxAj9KPEHUwC5ldZk1aZdCaIZ+7j12LnrkPPUNuYYfR2XvRWXb4XgKhXvR96iZyD5YiSloZ1EtG 0Pcfe4xApIIdJV/ivcv9As8gFU+xo/x9H5+Ar2gNO0rdAL9Z4YtSreIuu8vNXWlXOsVd8Ro+d5Ey RhH0d7aPv7ahveAPMmqE1EzQX2jf8Np4e6c/qGBI+YkDB+dLs3uv2zO7qzR/06FT99x4Q2nvzK69 +2f3zpcO3ACLx9Ki3wWJ8AkdQVgpK2VHcYQqg7orY/EpKy28Y+H87e8g9v+g3y38h0QsFYr5AprH FwhFIonoAfQ9dBN7hFf45C+ol50et91m0IpFeoPN7nY72XWwtn5Y277q2ipPtZdXlEomKsPFy2tW UfsYlT/QXlj/xpZCIeBXMfhrobDljfWFdvyVVJ46dNN8adfsnuv2zpbmDx44cdsNB0rze2f37901 s7d0w40wCPHSpQ9oM91EpLGkK+KMxyojguhr1DVqJVx2VxIukLC9slp7TXk6SRnaLRIatAFfW1sy 5nIoFS8iEpEk+WUoUKN0ZovHl0h2rs/mfD6Fkm5aGOxPpMxWsUTNQKeWQXL+4lfsDpfVrtbwabXK aDAZmIjTrTWIpbBZ4eDKFUXyB3iur136FfUH3jBhJwhFMq7A2LLCBFVxVWXXmercbHher3256Xr0 PNuPAt6t7oDXC/LWqG12fyAeTz0xMECdPYl07M9OLpT6nS7Eo3g0v4Z3O59fy6+leYX2z5KPcvKB ndfCjgRgzLgM70m8sh/pWAV8APXK1tht5fHh1ksvUvCnsZh9nlQ8N5jPhoIaFXqxXm4webzh5njS 6Vap0Qu8d9mD8Wg8FHI7Ddp6MVKpg+EV3ZMLYfIbfcmYxSQSqdS+QEvbwMJdGIeHYbe66V5Cze2X 8sqdSJPlSVHV2VSkwSzbVrrbam9tG9uwd2Z0rKXNZkfolht/8dv9173CqJ2eRDKbSze4vIxao/K6 k4nGbGPK61GrSNPdUzsLK6x2ZLeuKOycvhup7zqBTtzJ/vzGoYFYVKlACiYaGxw6eNPgUDSmUCrl sejQIJbgr0GCDMw5CF/wvC7LSLYc0eqqbLkbNBOOJ1uG2zuCYbUOvVADWyMQ1DzLr62p5fNoiqe3 mALe5sahdDrloz7H59PIZm9s7u1dy9Lkq+nmxmTc69FqzBaL3Wo3tMSjDhvMEpQR5Hg3zKkIuyog xAThBBiBqYLiTsYZ8hfo0EUfeop9E/3mW986efIkZTr5N2+8gVdyH/QKgK4IwAomkRWbLCtzH3lm 4WZq9cII+b3bKdeJ2y/+6ATeqZthp26DVXcTm2GEWAWcbltlxdW9wTeSVaOVTi7DEd9dlQdsK4PV 01nZw3Sy0gJrp4rukUqlErvF7ow7XCq1SETVGK0A9Mam7kf7+pHXlWsbGhj+UCzRG73+dMzjMxjl St4rAqM+Fu1ZtfOvt00yzMKPBltbvB4Q0WsNqUZ/0GBEQf8sieg9oA5IIjLqvZ5U0us3mOplaGTN Azs62z0umYSkm9vDIZNBKubXKpRWe0yWTSU8LjWzcfPzbKjf462xmCPh5qbkOpqsqdVoguFVgA8s za9hzQIJAZKt11AgWSLJmZxkHMMXCrNc8RgZNblcnzi7A9YHURqrOeBLJtoHc9mAH/B7lT5RQzaX w27VqGt5KrXeZDArrlJC2McnYJYPguVXEw6YJ7Jjv1ZV/KqFRlTCCvipbA31Knvvv72O/vn6sbUt TWYDUih9/mxuPbrnY/b77K+QZrAp7bDKpGTbwpu8glYXiXUURltbWmEFLunCs9T5H7M+pcJuDQZh 9KOXPqQ7QUYxoh1EVlPR46q5Uy8xd0u9X7wqIAZVXZO14qtQHikVLmdTelU6HHQ5dFrRIzKzNZFc 3bO9NLahtQ30G+DSkV83uuXIhrHGRp2WdYajcX/AYKLILoFW73RHY+g/Rzq74km9EUnq1IzF5AgG g2G7S6VxOFZ07tpx1xd27shljQafb1XP9M6bNehvkFjqdLXmxje1tbmcsnqsH3ewo7SOXknEiSFY 2aL+Jxb9NwOXmgMCXlcivVRjZPXp1KL3tV3bypGyfDzmdVlMmrIbQuRzZYdUcU86E7ilaCL7nU2b t24hwXwpna54KtsRiRktYqlEbDZFIoUm0Eg36NdKJATg2BwhrVGv08jraaFCabNHYvkLKfQNrcmg Nxrjbo9WL5YgsIoqpLnn5MJPruvvC4cYBdLqEqm+wd07ewcSSb1eqYhFR9YA/p+GvXXQq4hRvLNX bqQ7rbpyMemqpVzKc6pC47uqysNUEFK9aAcymNMNA0NTm1f2NDQ53fJHRXqt2xGLNjbFog4Hnpze H8i0duZa26IxkwWhnTvO9RUKqaTLIXmiVqW22r2+0O/ADbvdqVQu29nelHY5ULIn0+oNqNQSkcWU jPWYG8y2ejldI+CrFDZzNGoxMYxUoqxn4Fs82nvf0CACBJgt0VhBGTAaZPU1NQ+E9UaFUiStlylV NnuqgWOPDwF7/DJRQxDpJEJJxJSosYtPUe8/9CCaRTMPsZswx8QesAE0ohH8setKe8AJYtGC1CyR 4KKiVDzlERTwr+gcG9s83ru6MW23Sd6QteX2jTRlbA6pDCGZ1GHLNI7sWtEpf01gszc09vVP3LFp vCmj15OmL+7amcvqtbCrvmBTpl2yPpnQG+Op1b2Txd7+dIPBmEzMiDpa2kJhsKABX8/KqW0Y70XY 7W28MUJP+K/e76oHwG6Pqi8zShlZnjy9Ddxavn3Tlutv2bwlmzNbkN2Wy45vuvE/jx4919f/wOne XtTf9+AXV3aTZ7565DNrx/zBcGj92qNHnj575PDImoAfnf0q+2UkOXoEoSNH2V+zv77jjjtPgCQZ sGzfBG+WALtmp5YyWcpOxRUVCDFlESuqN6oyV8SpT969u1ZYV1snEAoFwjrB/d/5xp9vpGpoPs2j hSK4XXvrm0d4dQL4DfHoGvijis+jv9PbbRaHy2W32BxmNghs8HGNLxCOgLiCXjDISvQMO8rYnDZv yBQMRkIBn47cfCU6FAANhNHxPqBjjGw+j554iL2XPfUgBD2cvb4F7LUNbGZhCUeyLpptpmq2KytE oFt2u6xqVZOKqi+yL5p0+hafv3PFps3bWQ86vW/D+lyb3Vovs9qj8fY1+WzQr1Gx/76q53M//ulA Y6PDIasf0OpCkWy+7yISdre1hIM6LTo0taIrGFYyvIJC6fK2tK1pjMbBD5vFAoPRF0w3kp4d4SC7 BbCHHW1s4em2gN+kl4hZm0hoNIRD2GPuAQz1AYZagFF8CoKu0gUGoJSuWhLMc+geZyjS1Nxe6D0+ MZnNA6Ys5ly2OHn7RM+qhrTLqXnWVVgxM9bW5vbWy9HI0FciPo/dolNL2L9HPz6m0etVaqk0mdi4 8fDNDz115OZ1o8EgNiTBTGtHw+7WjM3e3jFRPMz+5o47kYAvFkpEAtT/GF7BXljBdbCC3OXYbdHE LfdmycSV3myJnSs3RE1Khd+Xz25si0e9bqNB9ajR421qXt277a5tU/mC2Woxt+eLkycme1Y3pN1O 3TP1Wp3DFY41r2vLebwKJXnm6OS2zhV2h0bjdkNMkFuR64inzJZ4dOP6I4cfeerwzetGwkG9MRjO tOZyoYAfDCwDughrw2s5DkjbwHHIJQyS/EmFPf4YvQfckX7+JLTsg1VPwaqLS/Bou4aVT7rcV11V KVxl7Zf7vSvs/pTZ0prbMnHsl0c+43hJpNH4vK2Zka5MU8Cn0SCzLZHMd7TH4olQ2OM1WeplDkdb 28ia4vzQALaGylfqGLXNCeDuT6WsNrFUrw0HWjOFdEM6GQ/6bRbgiHPAABJJg3HD+uecDYGQ2SqX S8RGQyjY1hnwGw3yerlYKmYU4Gyc8WjHlkJ70A+9kELl8WZa+6wxr0cP4Eb1MoPR7Q5mnC6NTiqT SaQyJYMJXboBSxj0l74VLJQKWygIuKvrq/JAFCe/8x7b920k4gtr64QCPp8H5khYJ6xFynNgWbJq k8VmN1kYxmK2Wi0mNflWhdEVwULIl0bZ2D5UHs+/rP/YJtBFj3dVz+49J9iTKP3wDQeGBgO+NwzG hqY1I/sOPPHDqe3k82duPjy61h/kFZDTPTB46Mazt27Z3JoxGi78Bh0/ButYXbFJ/MW8CEP+5Wts gU7QZy6M0mdOn8ar/bASk9RhnsmHdnEZTjJQ97L3Hn3hBfT3P2S70XfRb7ays7x3L46TYja88ADu h9ezFZ5ex+VmICIulyeoBxY85OmFSQrxCqfZsYfY+Glo/Ra0boHWAjwX3BLmw6DD5JMLG16nbqDP sPJHFt6HDkRFUpuhrRJH3Is+i+uyRFZLbCe9GRlMmdaxDQfZn7+O3j20aWNri8X8xuDQF3/PDrQ2 e11KBfVna1b3ZjIOxwIL8jKYEqnuVZsO5bMLHyG10uWMxzA3vPQvXMztJ1aVLR3227J6Z4xjiGDq cLkiN1FhRVWbUjV2yWWRMLUp1j9wABgfuu36of4YRwdfKNPBs7iOr4WfSsUWUyTcUUglXHalXK60 OxPJQi4cMYOmfHVHKILuvANpySTyB8ZplVKnVasE6IsXFG6Hw2Ri1LW0XKbTGg16tGtvX38iCaGr RpNMDA9fP9/fG4kAJ4dFxAeGwFf5wC48zushNhIHiXsJgldlf8tpfdUEuK609VWTsNyhqRetaTVY wKEnSiyzGzWXNSlJVYZlloUYdMTndEH0bFQZbQ5/IJZsmuntj8U1OqRWASNMtEnFEmFdTQ0QxIA/ n19XaG4K+DUazJm6V/aaLCa71eX0+Sxm5SmdPxD1xcJerVbDaAxG9hUIxSA4dwccLq1eKoWwRJ1t TAe8Os3Ksb6B/EgojGT1FnMsknM7bGajTiOqE8rrtSrg3zq5sk5kNCTihUL/6mwrjvMtehjJ4XK6 Whq4dAVC9XKbPRrLrkil/AGb3ZqOxiJAMkKjE1sP+u/cW9qY0uoQjxLcKqJr6G6r0aBU1AmRSMJR 3lxTs0+HN9Fpi1w8Pbl3TyncvXoyGQxb7XIlqhMAuZWDLt0B+rGKw2lVr6/yWcwyn6VmQPc7XmA/ wcFcLDrQN2fwur0eh00ldzjcXrtDkY/GzBbMQj+gzl4cps6e1E52d4aDgBuSomgedQrnlSCcEdbp DKHwKuFJbAO+DTNBZRugqJgA7I++TaXZd1Dm4jmUYd8Bpb7wm9OnaXHFZvjK7aEZZ2twrpbaufD7 118nha+TswuneIWFb5OpT/4CW4KvQbSWp/uBeWy8bAncNdVkhlLNqSKzNGqvgnN51M5fFuozS4k6 hlweQrFQeOXq3Q3RmD9gsat4nGK+CEr6XEVHaa3FBCQp2rZ79cpwSKl4SSQ2mCKxruZEOQ2gBGEm E4WuWNRkkIhI26HtU6tW+QIItk6tstvipFSm0hhMBnYdj3K7nCaDihFQcqVWZzJrEy4nYE2IPN6u ldunDk329qYS4NCU4diakVtLPf3hmJIx6hvSAwMgxznQ4HXlPLUajPUclfzzi99T8n7yiQXvyiaQ 8m7wX5xFRxBZx7l/1JPs6+yrb6FH2fm/RgHkO8fOoyfRK2wHGSAl7Hr0pYXfLvwN7j8B/Sch1hn6 0xkS7lqUNQe/K75cnadkZKSipkYsYdRmm1anUArq0BkQ8WehkGK5XKe128JrAz4lKVMrjQaHI9zi 8+m0YiF6ptKr3ekmv9qXTNjMUnGZ7w4sPH45qVKjUGn1BiOYRZtBJ5NGIpMhl12nkYgvpzirvYeH n1m4iyDRrwBqfw/y4s4ZODxiH/irDz74APnZ9ygp/h/LpRvk8pmyD7Naq4k4+jMX/oqKLaipty5+ lxq/m9adPnHhn3HrW2CPVgH7WreMfV0VZ1cNpD25mGFJVOyle5ksF00uU2Vcq8yWTOvasfnPrBtr ajYYBS/zwZ05GpIrb+tdDQFcPNncGtu2NdaQCgdNBpTvOLK/e6XoRaHX05rp71t33chwKqXTgq9x pRq7B9ta/F41g+Y2rFgZjen1VnM60dm+UtYQCluAaLW1HmwPBfVaAOlpJKkz6oP+7I5ME2ppnZFs LHSEg2qVwRiOZHPdDbGkLwDWhBaYTP5gIgmSPVSJIcxEFp/rXBWJLqObi2xzWS45XY2WeMk4Q/cB 8cl3rBvbNrV2LJt3ulzOfH5s3c7JsbX5vMv5dVBotyfd2NXT2OwC3s0ovO7GhpWdTQ1el5ph135A fvHto8cHhmwOh22o//ixt989fmygz2JGyGzpGzh2/N1Hdu5oa4MYCmKMtrbpnY98YWo6m9MbETLq c9npqS9c/4c/4MwAZ40LXDwrKzvNxXD2MqEuKwq2eIqlZFIBYDuD84akvF4C5PXJ25+q4dfWCPgC vlxBko999JJAJBTVScRioVgkeOmn1GQ8mQjGYg2JUDTuZFeir0sZhVal02jSmUgCRB2/eJpXYNUa p8cZiIYCTrdLh34JxpQkiuwhei/sQAR24PIpz1JXvZglXnaqde30gFYXjRVWjHk62osGi1njCoYj I225SMxm1+8dWpNuNICg/njK4L59+9eMpBqYmxobIUrnHRfU1CKdNhLqLIwKk/F1a286dPpP5BFO XvqAY5TOJZ6hiiaOpF0Z5snidAvwvqbM2IYDpdHRRlCW1wHFFlMy0T/YmLLbpGL0Gvrl7eNbM60w db0207h5463U7otf2dqBD+yUSkXI371iiuqEsZ+/9AH1IxjbeFmS7uWRVRI7ZupHWn00vmr1+LPb ttv+QsgwRoPL4d2eSrDn0O/Qk8X+oYZmkwWtW/umORcMm8xiaVfnCUpwGvs+WF++ykYRWcki2ZXY deHjuUSau/BalThpWbbCS89h/kiGEjzd5LZXS2tGwlzGmkRfBdP7AknS4ZHhfW9vHX9JKjVbQ5F8 eyLpcOF1u8Cp5doiEYtZXk/a2P97110o4N+q0xtV6noZXatmTCYgEfRH7DojMDa9ajoSQnfcyf7z noG+ZEynAZeQHBq5YX9ffyiigLkkYkPYh90PerMDZKjBpxpWWXULk9UNw0HFw+gbynC0Jdu5It/d 3dnWEo3onkLjp6gFr82phcgN3Q9czeTzxS6sPoXPaDlLjvzYL1rLNrxqu/PAJG4HGw+cybrU9iSr gklfI9BTxMk3XW5vJNac6bUbTGaFRiPrXVGIyFnfG6hWKKuXSkVCihIJ6yUyqejia1t7+1ONBhOJ am+lENncdCRKhxdu0ru9TrfZUiu0mGDv3UbyMPicLexnKXnV5+CzZqQAX/2rD9hjZ5CAPVd2OheO k59b2AFYKKG19Cj1Ybm1AvsdKDgRZaTep9befz9L3H8/zkIdA8x0cnmOrcSRJdisWWZlqxH/Im9c Tumr/qWKpeV2eFGtFMuJ5nJa1WkwNjWPbTh047oNTRmDEZ/uxaPp5lAYhzVGQ0N6eHBmbmS4Ia3X 18vMllC4JQPhk1PN/JNYglO33SsiMXxoWyc0AfPuX5OIGfUCPrAasQTofvOa/lSDzV6Ps6f1dltT 40BVlw8Od61MpnBq2WJKJVZ2DXU2N2ImIaTFFjMgJppqzwKejAZkMEYibdn2ZDTm85ksdXSdVu/z p5vIRMjnMZvk9ZjTm8weX8jl8drsKrVa5bB5Pc6FB4JBv9OmVqnUdkcwFMqAQXYpGQaYRxJHkycB cSZ6FbCGaWyhlnj+ReEl7TVXusErTlKucSgB26P4Y9pd8Yzk9vXtBZxTF32zvim9sSEctJoV9YhU GmAJ6YYV27q6QmEl9z5CJNSzembPmsEQVTmpeLZ8UrFjp02jcXujiURHBAcF8GcxxSL5RCLmdes0 7FoImhy2WDSjXeXxyurdzkxm5C3AuMFUL7dawB9M3nZk+7YVBRcEsOMai8moVypoAaM2mhwu18W/ en+uRH1/T39fLIJlF4319u/Z19sXCiuUeE6R3tUgrksXLjnoH1w6ijWZD1jn0X/7D1u2gB47wGqc KUcQHKm1lwkuuQ31nGd70D+cZ+9gT5xH/8D2nKc6IKo+tNBGtiy8Tb5JHl3kZAUi/2lnH1WKsSyI 59txiEMtISn0KmAKbW0bNx+cHRxqbLTaxV8XMiCZeLS7s7HR68YnYRwBCYH+27QG1fNhyrpwzBjp 6pqYHh5ubrKa0SvF4RF8GK7jcl0rGK/DbTDXy5Fa6fU0N65sTsZdoAuILxBL5EoF+b9PsaNOPVAS szXd2NuHLds9IJEM6HwG29Gq5Vo6/+WHuunlZJI7qGPuAe82NDA00JH3+RSMzRGJNaVCEQz4mm8K LObG9ED/zunhwUyjxewP5DsGh3p6szkz+cN9W4YGVnbl87m2jvzKDM7CScRSqcnsDzXJVnW0xyEW QhpNKFzoXLu5b6CrO5vL5tpynfdWc0jfqcSDS3NPH7DaL0JAmPkpW0sWyJvOsH6ICjeTjy+8c/E/ cb/qezH5JWcIS6zUlWcJl2WyeJpQ5pKXTxS+P8Xjjvdr+fJ6RX25Vkvv+P4PX93N50OgzpPK8D0o Nbuf283jqjW14H8o7vWNmqlX0WcUOq3ZYDWbCj09nSaz1WCC6Ia9kVe4+Gq+pTXaGO/oMFhMJqNR r0Z3s3vVeqPBZLIYOgpAkuKx1pYU1Y4j3s8BQrtgNxuItVdjdDEjc62TJ+bTgt3lFKALqFBj8/DI zKH1G1pajeXDnc0b9ne1tSbjbrf6rDHTOrAyk/H5QEPXrS1t7u9tSJtM35DLHaDUnbFozOPV6pQK tzOZaM8m4w47PsAvDo+2ZG32cGhkzaEDDz5/+20b1kdDSCq12lMNfeb1Xg/O0I9PHF4PBMFsaWjq 69/Z3pDGeZN6udkajWW7sjkIPIxqFQY/7PMjsM9BLhO4KAvGXk1D4QOF4JY1o5j5v4K8bnx6vHXB TN1Nv3zHffc/8ODDjzzy8KMPP/jgvaeOnwLJ7mNHqA7gU07CSxC8ZSdzHA9YmsJLV9/LoDqQzdnU 3Nu3xufxgR5bNSqgO3avy5uORbijTHaaXPWtbxlmVvaEcJqNR9UATgR3whA0j+IhCU7rhTqov+Re 50CEENb0FpcHXppdXswsn/srln8OZeulYrFYIpKIpBIZaj0HMDoYjMS80VAw4olFw9RxeNLH5EXq f/G+Q0hAOk41T82nKHfameZRcfJRVBtkf/bS/s+d3v8q+69BVCe6jX5y+9HuT7oQeYno+rj7+E6E xXDp0qXf0t/lDYCddRAFYhs+XYjDrJzLbMRyBMYVy1/2Web3k+h/+oR/PEU9ed/FxxoBj04NOAq3 O5FsziSSbpxpwWnAZKLtNoGwXq7VWe16vVwuEKA6gVyu19rNeq1cVicga/8HnXndoN9OdzY3MZ7N ebz1cnm9153Pjk/ksm6nTMo+nw/4DTgWForwWXY+5wvoDUKRSGjQB3w59vP//c6ws8fQy8DjCvjU EWEHF0fUWfYb7MufRwe/gw6hlyn7xX+kTlzch3/+PdVD/m3lnUUweuTZu7w/gVs3Y2uCM0FRjg8u OZNcvOyXLeMV50DXfA2IO7LEQXdUrjRZXF6P1+01WcBnP4cYucXshjtup9molCOFyulONbR3pBux jaj5Zp3L2da6bnTvrnVr21rttoW736Z+WUgkPV6rzWA2mGx24CXt8bjXYzWb4Ybd5vOk0j6f0SCV KpQ2ZzTRIlrXsyqVtJjAjUTaCxdeOXcOZPQRrG01yIiHzx9wsPDR6+RjvMKFUe5UA/OEZ+DX2nKO lEuBke+8whrOo+tQ6TzZtfBNsotcWHiYnIDW77MjtBNkuOIyU0vLqk5l0anKquzMylxOh1WFWWXM au7NQLAbhlwq5XbjNz9VGrc7GovHY1G3W6NC1bcakOC9kNnKMII6hBSM1ebxe/w+j80MJgWs2Yb3 2FFo6fU0pDvQ5raAX6+TiMnb8RtRuoC/FW3pBMvpZpgT+A0RpyvJPtUYClvBWwtIfIxmD4ab2C/t 9AfxW2GIoXqor3MY4ZdRggt150nPT1imApeFwwAZcL3sZ8kXyxEUF5FQXDgCN3Eggt8eASv6i7Kk FMlymHtVULGY7rMnFw+/q+94qqvvSjKyanDy9Hvr8ftfNrPPE/BhVCgYYZ1SZbYG30OCbDrldqkZ jcrjjkXj8WjM7VFpGLULoJllR08E/TvR+qZw0G5TM3UkzrJaw6FGNJYE1qQSCU8AAfOmGzrZx1r9 AZ1RJEG3k2KJDlSujX28I93g8cL+gJ6kAC0nAC16wgyLpDDPA7YHxZ6MQ7ECR8AlDvetCuqJdkSz /7J2ZoT97PDM8Lmftv8H4q+bWYt2rp1Z+8OFbAHtaKdy7Nu72Cn8njL6/C7UsqtcY6d2sW+jliWZ cAYzn8U8aRwt5i+ojoWPKR5FIfTlfyLreTQPTAC9IxBw+4Pui/cDzk+6wy4QCbWFy+7cBbyh7Y/x Bo7bVlNn6WWub+nZAX/5Yc2ygy26Db8Ukt+05brBbC4edzhUZw2Zpg3dLc0Br05NMg5XMJJIp8dX 96bSBpPFnGleNzr7wcHr38EZxkSqM5dI2h0KpbzeYUsmCtFk3OcxaMnX/+zWW9dvCIVxBNeY7tdv 8AZw6iif3zp+JIyPaMUSZLe2ZkaGi9tHhjMZq/Wpp5/rzmc5aqnSeHyNzYV8Y7MvoNXhKNAaj2K7 +BA7Sr0KSOVXTxwhan6ItLOn0Cx+qfvEHx4/Aa0k0CpaaVU+SpchCbQ4BS1HT9RsPvHxCZDu9srZ rRC/t1k+c0FgdBiErNSZFxbmyBv++hX2HlaEfova2DdR253UwYu3naTaF1aV2SqUj747/2+bpZnf 4Rf4l/9dugD25wcwC4QtfuUP+tScWXgQRv4QWmylf1DmvUv+xujzBH4DnoBSos+jXvo8qYDPkfI9 1A+fL0F5rfJ5BMqvodwN5T4ot0D5GpQnoByDcgeUp8vP4tpug8JUvuM2eyvlOJQ+KIXK/dVQPqzU 36p84mf5K5/frtzDY81B2QRlAub3K/jsrszjEJTDlTFPQnm+0v7+Srs8fG6pzOVYeQ2XLsCno9L/ nsoYWBYPQHkEyj4oQigfV+5DP/T7yvgfVfq+D/dgjYiqrD1Vec5dcO8hKBKow+4DA1USAaIR7N5h 4kXi31AHugn9JWkmp8mj5EOUn7qJepX20c/y4rxO3hO8D2ryNSM17/Cd/BP8x2oztdtrH6v9Wu33 an9We1HQIDgrvFP4A+Ev6lDdXXWn614RJURdos2in4mHxE9LpJIeyc2Sf5dqpS7pjPSY9MH6zfWs TCjzyu6T/YdcLD+oQAq3YqfiHsWfK29U3qd8nJEyJibJfIl5mfm2KqmaUX1ObVbH1AX1ZBlDxBhx H/aRlW/L/wxoZPH+JuK1Sh0RUs5K4T+S4KONlTpF6NAXKnUa2vxtpc4jRGT1+TWEhPRX6nziIBWp 1GsJJfVepS4gJHRtpV5HGOiBSl1EhOh3K3UxcTPvQqUuIfw1P4TRES2Ab69wM8F1RJiQsVInCQnq qdQpIoGKlToNbb5eqfMIDfpZpV5DGEhxpc4nfks2Veq1hId6tlIXEAbql5V6HdFAqyt1EbGBnqnU xQRLX6jUJcRIzQ1EOzFL7CEOEHPENGBniigRFuIMlBgRgSsNtUGiSEzCZxcxDr8GoNZNzBATRAhq OWIXXJYlvee5b0X4LMLndVxf3HI19MoDsxuEPsNQ7yN64e40134cSglaj0PbIrEbPueInXBvFjj+ p41PtM/uOTA3vX2qZDljiUUiactgcdLSNV4KWLpnJkKW3K5dFu7nectccb44d11xMmRZ3Z0vDOaG u/t6LdPzlnFLaW58srh7fG6nZXbblf0JmPQ0sZVbCB56GiY0A8P3cJ+z8PP01uLceGl6dsbSMzsD N/BUtxP7QCR4CcRgcfu+XeNQycEyJ+C3GW6Bc/CMICeST316bn6iODNZnLMELVcN9F+d2AjXdn6x ZRSkh3eXGCnOzeNm0VAkfe3HXuOhnzaH/9mOlrGznXtKiXt2ueU09+w10GKIa9XP9cQCLXGjzXCt hq8xYh+MuA36Y/FfbjnBPbsE38tPnoX6VGVrdsAGznEzmOT6Vdc2jxG3RLJ/Aj0Aue3T86XiHNyc nrGsCQ2FLP3jpeJMyTI+M2kZXuzYt23b9ESRuzlRnCuNQ+PZ0hTs+459c9Pzk9MTeLT50LVQhJV3 DtR39opNuIyc9tm5PbPl6RIgOSyx6zg59HDNS5yecl2GSsXripae8VKpOI8bT3E/7yGaiDBc+7kr BJ2unMFEZfwQV9sNLYmpUmlPUzi8f//+0HhlGhMwi9DE7O7wf/+xJbBQezgsFDkUb4e2ZUSHuGfu BpX71KFLB/YUJ4vz09tnAPChqdJuaL+GM1JVUGIAlMF7bWBv4z4x3Oa5HiWY+jgH0Cro5wE4WwE+ RQ40+ImzlefiNrsqIJypjDoOi8C9MVirQN63ZG/3c/OZgP8tsPhZ+A33meCesYfbusklT/+vzhng tGa+iEFbmgIgL4H1tllA6PzsttL+8bkiBvn8vq07ihMlS2kW2hYtuwCsM9B1fPtcsbgbw3kfh7X9 U9MTU5YDs/ss4xMTxT0lgD1u/seeHPrvg2HXNdb6/wmDXYuzqWCAIP4foBHeP2VuZHN0cmVhbQpl bmRvYmoKMTE0NSAwIG9iago5ODAwCmVuZG9iagoxMTQzIDAgb2JqCjw8IC9UeXBlIC9Gb250Ci9T dWJ0eXBlIC9DSURGb250VHlwZTIKL0Jhc2VGb250IC9MaWJlcmF0aW9uTW9ubwovQ0lEU3lzdGVt SW5mbyA8PCAvUmVnaXN0cnkgKEFkb2JlKSAvT3JkZXJpbmcgKElkZW50aXR5KSAvU3VwcGxlbWVu dCAwID4+Ci9Gb250RGVzY3JpcHRvciAxMTQxIDAgUgovQ0lEVG9HSURNYXAgL0lkZW50aXR5Ci9E VyA1OTUgPj4KZW5kb2JqCjExNDQgMCBvYmoKPDwgL0xlbmd0aCA5ODcgPj4Kc3RyZWFtCi9DSURJ bml0IC9Qcm9jU2V0IGZpbmRyZXNvdXJjZSBiZWdpbgoxMiBkaWN0IGJlZ2luCmJlZ2luY21hcAov Q0lEU3lzdGVtSW5mbyA8PCAvUmVnaXN0cnkgKEFkb2JlKSAvT3JkZXJpbmcgKFVDUykgL1N1cHBs ZW1lbnQgMCA+PiBkZWYKL0NNYXBOYW1lIC9BZG9iZS1JZGVudGl0eS1VQ1MgZGVmCi9DTWFwVHlw ZSAyIGRlZgoxIGJlZ2luY29kZXNwYWNlcmFuZ2UKPDAwMDA+IDxGRkZGPgplbmRjb2Rlc3BhY2Vy YW5nZQoyIGJlZ2luYmZyYW5nZQo8MDAwMD4gPDAwMDA+IDwwMDAwPgo8MDAwMT4gPDAwNTk+IFs8 MDAyMD4gPDAwMkI+IDwwMDJEPiA8MDA3Qz4gPDAwMjg+IDwwMDQxPiA8MDAyOT4gPDAwNzU+IDww MDc0PiA8MDA2OD4gPDAwNkY+IDwwMDcyPiA8MDA2OT4gPDAwN0E+IDwwMDYxPiA8MDA2RT4gPDAw NTI+IDwwMDY1PiA8MDA3MT4gPDAwNzM+IDwwMDNFPiA8MDA2Mz4gPDAwNEY+IDwwMDc3PiA8MDAz Qz4gPDAwNDI+IDwwMDQ3PiA8MDA0Mz4gPDAwNkM+IDwwMDUzPiA8MDA3Nj4gPDAwNDQ+IDwwMDU0 PiA8MDA2Qj4gPDAwNDU+IDwwMDQ2PiA8MDA1MD4gPDAwNjQ+IDwwMDI2PiA8MDA2Nj4gPDAwNDk+ IDwwMDQ4PiA8MDA3MD4gPDAwMkY+IDwwMDc4PiA8MDA2RD4gPDAwM0E+IDwwMDVBPiA8MDAzMz4g PDAwMzA+IDwwMDREPiA8MDA1MT4gPDAwNTU+IDwwMDRBPiA8MDA2Mj4gPDAwMzE+IDwwMDJFPiA8 MDA3OT4gPDAwM0I+IDwwMDNEPiA8MDAzOD4gPDAwNjc+IDwwMDVGPiA8MDA1OD4gPDAwMzU+IDww MDMyPiA8MDA0Qj4gPDAwNTc+IDwwMDM2PiA8MDAzNz4gPDAwNkE+IDwwMDU2PiA8MDAyQT4gPDAw MjU+IDwwMDVFPiA8MDAyNz4gPDAwM0Y+IDwwMDRDPiA8MDA1OT4gPDAwN0I+IDwwMDIyPiA8MDAy Qz4gPDAwN0Q+IDwwMDIzPiA8MDA0RT4gPDAwMzk+IDwwMDVCPiA8MDA1RD4gPDAwMzQ+IF0KZW5k YmZyYW5nZQplbmRjbWFwCkNNYXBOYW1lIGN1cnJlbnRkaWN0IC9DTWFwIGRlZmluZXJlc291cmNl IHBvcAplbmQKZW5kCmVuZHN0cmVhbQplbmRvYmoKMTQ5IDAgb2JqCjw8IC9UeXBlIC9Gb250Ci9T dWJ0eXBlIC9UeXBlMAovQmFzZUZvbnQgL0xpYmVyYXRpb25Nb25vCi9FbmNvZGluZyAvSWRlbnRp dHktSAovRGVzY2VuZGFudEZvbnRzIFsxMTQzIDAgUl0KL1RvVW5pY29kZSAxMTQ0IDAgUj4+CmVu ZG9iagoxMTQ2IDAgb2JqCjw8IC9UeXBlIC9Gb250RGVzY3JpcHRvcgovRm9udE5hbWUgL1FDU0JB QStCaXRzdHJlYW1WZXJhU2Fucy1Cb2xkCi9GbGFncyA0IAovRm9udEJCb3ggWy0xOTkuMjE4NzUw IC0yMzUuODM5ODQzIDE0MTYuOTkyMTggOTI4LjIyMjY1NiBdCi9JdGFsaWNBbmdsZSAwIAovQXNj ZW50IDkyOC4yMjI2NTYgCi9EZXNjZW50IC0yMzUuODM5ODQzIAovQ2FwSGVpZ2h0IDkyOC4yMjI2 NTYgCi9TdGVtViAxMjUuOTc2NTYyIAovRm9udEZpbGUyIDExNDcgMCBSCj4+IGVuZG9iagoxMTQ3 IDAgb2JqCjw8Ci9MZW5ndGgxIDE0OTQwIAovTGVuZ3RoIDExNTAgMCBSCi9GaWx0ZXIgL0ZsYXRl RGVjb2RlCj4+CnN0cmVhbQp4nLV6C3xTVZ7wOTePliKP0BdPuWkppRL6TiuVAmmbtoE0KUla2sKW pnk0gbzIo6VAeT9EREFEEBksT/kcxmFYdUet7M4yfrMugssoM+MwgMC4zozounyzrkJzu/9z7r1p WtHx9/u+LyHJuef+z//9vAVhhFAi2oAkCBnNeYWv7fjvcth5Ej6NHZ5up7br08uw/iNCE/Quh9Xe UaRTITQxH/ZKXLAxVpL4Ply74HqayxtetemvGR/DNZzHKo/fZv3LG3c3IDTp53D/gNe6KoCMqAOh yfVwzfqsXsc/NF/8R7gOIDTlM4Sl+5g+JENSWY30PYS4Cv6XMWOGcSYyzMhEiUQuZRgpoPzpWMQu QMKrwh0OIRax9xl5CpeCDyZ48W3YxsJtBjm556RO2XGQMgGhZIVSkaVUKJ1S1B+STOr/hHsuYfTX d4PyHDiRhJBsuewKhQMY8k6StXEKbj03VnaFu3bfID1LMDoGbsudsi/RGDQVCGUkyNPl6WmlaaUl 6uLs6RJpeppibIJcyWZPT2ZKSyTOM9Z2jNutZ860W63tZ7DrPXhxB7jn37uE8aX3pB9t2vzZnY2b Md688c5nmzfhdHzxEreP23fx0qWLeAVecekikcY5cEu2FGgqEcqSJ8izAbtibGmJsjA9LV0xPXt6 psBGEbBRKlu6Ihheyz3x0e9//xHuXBsOrvB0uEKXOrsw7uq8FHJ1eEyPTpqCL/8bdmDn5X+bPKWE u1CbmbFly58+3bIFZyoXEIqfgjakoI0kqg0ZVZtC+SW2cMfwEuzDlvt3cJLknVosr72v5r6CE+At zGy8mfgT0d9l7OIO4M1cD8HWB/fKAZtwrw9v5NbLrtybSe6dBkrjpGvQZLhQKNUK0CJ5Z4Kc6YRm aklpSVFaeppsHHdAnjgmddq03JXzNJg7iJ31S5f4fuG0My9HG/34hd2Plk7MSE3GDYufj34kbTtu zc/FnauAwiSEJMdlh1EqpQBvYrAihTIje7pakakoUjBFeCX3NGanLv05d/HDpuazZ2WHuX8eQFyW ARQ1gJqbPsRXMcJzBX4ld4Bfgk1QfarIZykxiOROXm5+7k7dQsKitqVp3bjUlBxJXtrIpKbmE9F+ advPvcUFGEukxJuaBm7LsgFbzJtSU8CMhYAKcEvYQW8i9mZ+sap83rzyVZG55RiXz41g9vjRo8e5 j7nrx44fPyZZ07C490hDY2PDkd7FDRgdOsTd4e4cghdOwSmHDgG1JeBHo+UpKAVNE3ShJu6UwTsr 4V5SyDuy6FGSk8SOC5uaI+9v3Ybxtq3vh5Y0HQnOnTNnbjA4Zy7Gc+dI+pimb+4cteXm4RPHsBRL 4Ds3v/9fLeYjvRZ49R4xW0BvvSCpXNpG5IQ4TE3h8ZN3KaEpMpMJzPRiF2YwTkxQpE3LyPNr5mMn d3BRy1LPebsTv8qcDix9/Incx8vmTMpMTsGNDQeZnPu9R9tz87o6gU7TwC2pGjSqJBKKBkrhQ7RU ERc9WSCuVL2gdoFxv8liMe031y3QNDQsXsxd/jG8cF5To0Vazv2hYML4xc2HDjc2YzxxfCF3lR2t wIcO4jScCt9jFKBV8AhmHGhVEp87ThOeyUfadr8XktMfiLUhDuSIRlUGcCeoOjtToSAnwNjpwF4C 0UmyUkKigLnRrS4uVncf5dYzepz9xOMYV9fuNs4r11zmnK8/Wjq7VTJvlsrlVM3E3Ebuq+gF2RWb 7Tf7WpfNGjdPs4FrwqFAzgwseK3AI+WQcidP+eYO4WoxeEUSaGwiygTQVGWakEhEZRHfINzJCEug zQRZUv9bowyGJwOrOns2rNuwjnv/pZcxfukEzsCJL/6I24PL5rS552vGMkXOdfPmQUqp4u7kj5+I XzgI+U1x+Ecv9j7jnFcOUF7gbPnAbWk7UC8aZq/0dMil6eAmJE6zFWlCWBCFkfygLuYdVpoeXu5p dRYUTp/WPg+Pa2vFW7Zw9/ydq9YuDwbCbnUxnjbdM+8/2tpWd0fbfV6w6Jf548dPmFSsShufNGKa sf7Hf9/SMm7sNDxWPWHilMll+ePTRic+vGjRibONDXjMWKK7owhJb0D2fRguiG1xCc8HSVEJCpKe QDnEoRMYA7Pn/nlGqcvMwNU1kSXLPd0bN6xfjR/a9+y8ef+KJ3Gf4En4ZsW8eVUucOqsbD2unZme 1tn169XuFWd4/5DtAP94CKUTOwkekZWpUGJFkVBiMvuY9XjK8/sx3v88d5vj1uONV/xzy8vn+mVX 1m34852eDTh6T3qOW4YfVTvsJSVC/pWCb6ARg/4JWVg6JhpkOqLPk1zMXeP+wl2LbifQtQglTIFI fYhAJ9N/WCmRKGvx0r638Uz4LOU+4rrf7uO6pW39/RJpVMr03++VMP0cnN4B8fcFaKsYUIHRUkEA pVywII10YuNMNfWwYsGhqBKlvBIlbz5Xb8D/68fcW+FgJOBZ4XYdMC/CJsuxg0f31FRjrXZda+uy 1pUrAx6c8cxurVaSld3W/uz1UBinKKbjnBLI2Opiu1Nd/DXOm/V3DVAEUtNm4IlTFWNxa9s/bTFZ QM9Q1eTZtNYnEZtKQD7ylkiroyeXcT1MDr7A5HA90VP4+ffwWO5LUquYLMYUq1cQSd9VrxQ/sF49 /0x8vZKnRE8JBQtoLAV7VYMFqL1SidOpsTIiuRw9yxj60xhD9IK07V704AC6xzj5CL4tfQdiaBTK g+PASarQDKjVWYNptXQ6JL0idbznloLSmaMrS2eDrhbZq7XYze2vbWnZ+IrHh/GO7Tjjg8qqXeF2 W0MoHIrgvO1b8dfgtjptVjZeUOPL2R7deNKZm+e0H/vl3y3Bky052WDyXKyYPGYUxp3dtHO5LbsH 3pDFdy6ZwzuXbHlcyYNirJTd23PwhROke7l+HW969ontq3vW9Kz597U9q1Zde0xdlPMZ0+Svycik 3Yv7/fdp91I9LQPj9Zu++HzjxkS5ArIQA5RfBi9+FXSSCxoRTELsU1xarBbzGFwKy9T4TkP6ZuWy pSt/4bBj7gCDMzINTtAPNDNTWZOr9FFYuCoaLa5QS5PkZMejJWCyW9FGpnbU6FGTOkuLscXyYvT3 TO2bJbBsPEQ7kdaCfFw6m1QKrlHWCjzR+psVT5OUeWKjZLFaCcWBGUccR7ekJXJp29at2y5FWpac CM+ZO3dOmNbgo9FX5Um00zl2goty/cdO5OVKSi2Nh1+0NGK+ABP/AH+SFYG/M+AhCBOHh64nk3or c5drwSfn49NXrnDPRpdLD0SflrzSb+L+zH2Jx+IFosd3g8fzvSAECvyjJQQfwr3Ra4yBM3ALSTnp /xl+IcpFj+IPuFlw7jDUFQaoZvFZJ1XIlDSny+NzumiPjyRvRztn5s4swIoD+/GJl7irG8D23X5P +06TEWOjaae5ddkKSFaffDoyUf74jr/+n8d3kKKM88AjtJWdnVWVODVdRXjOhi5tF/BMurRUWlJS +bQH/R4pHUWSXf+7bsrDuJC7xB08e9bp+K085bNJUyoNA6i/V9KGkeH15sWgr3UgQ6bsC+jP8oXI iuvP+HpFYkl0MBAtS6yY4OLMJ86CoqICp7MIGr6CIty5zNJg/MmytrEVdfqln+zaiX90mPuGu/bi EYz73sDVznYrcxPPr9y0ZX5FxfwtmyrnM5e4O6r0VNxqfSt/4ni8ddtHX+5+Br9zHi/HwQ8/GKsQ cvtN0LJMzO3QXTPH71+VXblv4K4RXewFGWZBDMYqrFyssEJ+zoqvsOr4CkuEkF5YE+nseKKiYtbM zuPfuN14z17ug6ef2v3UU9u39PRUVc7K277v4w7X7t149OrNG2UnuV+WTJkMWcI4R5mZrix0drz1 dddqPGmSGmvrsrIfecRQPT1rqjLf7fr7G6tWjUtB/OxF87GcyEDcS5mEN+Mn8U68OfpbTg2inJUa YFyA6gLSfiFCphLIHVJH9E1uB5MdLZBd+ei+VPqmUPFkXwHcyPiKx+vmUTJ9RP+FVL3or5jZkNm7 Sd2ToB7IVePoZJeP5vPWpkOVoJQsUSdCoUoQDE66c9qNJKfEaRBcjnnXU/YYxo+VeZaXzZ5dxvXs qNLu2oUVeMyuXdqa7fuNerx3H3eDu/bsPoP++ZbCgqXNhQUFhc1LCwqZQ6Q78pU99liZz/9Y2foZ jZYNb9ts2Go7t8HSOOOR1mW7bwSCwcCN3ctaH8Ezm/Ph1dxUkIvz80m8nwZJWsH7x9A8E9fSE7NL hqWcbBIZEsT39DS3rB6Sb3QkA30qdPM0szC/GZpx2o8CLYwmcNUwybUhhWhFkvCh0pNoKZ0A6WIW zFBOLqemte3g+4Elj8wYnyRtiyYyX98v6dMt/GzKZP1U4N1NZhSIOJZEXKnYNZQKc4p6Om8AOhZB EsHDhLu4pMFsPt3WptDq61r+fecufPgQTsCZR3rf6uPecrdZ8QZ7cVFRsd1RBC8lTlGlpOO21rcL J0yE2eb3Xz6zB//yHRjPd/36Q6wYzfwHicIKeJGIjPMqWpfp/ISJT73CTMVezhS9ye2VXelHUnRv phT10+cQMO3IJoBOBj17KigiHcaHDq6G64L+6Z5Efr+X5GhOKxst7QaLFQtTfgbvV0WkVqohUw9L m2qJOC6mCePiSTKnXdq6bdvWS5HmpoUwRUEb1bfc2m5rbWle+lOz6U6gfO6cx8IBfn48ByMTPtp7 /97R3ty89pP9Cu7uU09jxVglTi+dMKlOf0IiN5n3vWCox2bTvn1mkxBXCbNph8rLQ9rhTKqEv2AL bsR/5p7lTv2VO0U1cVMyFTRR1X9VknW/j54GvzwPp1NpVIqxBTjEIRfiEybKHTvmzsEbX+zl3uLe PPwiINr4hrG+3viGZH3/Ru6fD74Ac8TcuMw3PMbFvpbPgnxny71MciFMwFCBiZZpZIhPb8SgTY4b hkWtK5k3hTk3SCNkdfwszGuZOyDp4sdcPkiiMwdn4ePHiGq/+Ur0BfB4wi9oLpnqD9pq/CvOg9d8 8ie8Bn5PcVv7v+G2MuVMJvcq1kdvRH+B27nDZDYYGJDPprPjFJLHY4kG0zEhTchJJJsrmfInPlu3 dm3Pneh/4eew5aWTXW7i7u5Vp05xZ7jl0rP9KyPhj6+HQxhn5heGHFu2nnx58zZ7OL8QEx1ZIQLz Yk+4xvLBpRjL6wmDqbKkg0Oh5JVi9dqeYrW6uGcNDFubeo9wV7nfkYp25EU8A2cd6WXu4PRwMBiG luKPoTAQncDtevcCxhfexSEcuvDuuxdAN37cx9xmbojzqZ8JR59kblCbDfRx1XR2HcVnFkUKn1bo iMrPsh7PxZ/NdU7PwsLA/erNzq7PcF7udjmCwVtCdEfnqiSUhnLIXMIHTGamIlmcqqAvIOMKnbf4 YZwOI+OW5OVinJu35Mqt0JyyssfCt25h51roM/CeZ7jfRDcyFbhk186iIslenDPDoH9kBvfLaAgX FtjaCvO5bmbCNGv7k79bvgLLrrQuu+RbWEf84KfcXYlUPo5Ig5XARikpHkqh2kik3G+f1y3AC3QH cM6G+RqMNfO4u199fP3q1Zs3vvr81h//cP3WbYLlOHeX+ZrHklwi+IJSdIPj6zXz52vW45z9C3W6 BQe4u1/cvnX9D3+89flXN25evXr946+Inc9LXpa46FO5BOJRmfQtcX1+4XOojFeYmeRDn6VyU6SI u0psg1OVapLauKvnzsEdwIDP8M/1yHl8RjhJsI8eKJd8DV6kQYvIufjJXmg7EgRuaRFSpw0+RY3N 99P5hE+qFa3G5LAwfEsiNmP9o/qs6X0TRv+63gj9dUSfndW9+sPG5qWO4NIls+fPyH51WvJ7AFS6 Uj9VicPBdy0tLdzBKmUmnlv++nyYGbTVstdvZ6ckj5+YW2V4SNrS0LQ2YqzPf6R0tu4Zk2XMqIc/ z0lNJ499cqoXjBqxuKVpc4dBX1z0aOnC3YsW4VFjo9umZGUXVOUXatJypqsr1WTkRWfAulPAW+mz IFJaU5VnGC/3KZ4Q3StPuXmv9yaB2kmtR6GwkqQZtZL5OroXYuNTAL57U9Z2E3T4CSjSABljyJOl T8iQRj7SNq6HO8k/YS1HKHFvXF6mpQa+yvFKzEDZDcGHwT6ul6vi/pP7K1cFPdV5aTn5QIr2398D OLzcNfoEl+8kJZnJl7Hrv6/Y8WbufW4njvAZV74y9lRYnARIUzUT/2O0QDKBezj6Cm2sbjDKaHn/ F4w++irfjcsZPlMLvNF/kn5Gzvm5YyCEF1aj8TO4BlfjZ5l7UTnmOIa5x1zlpuKbCA/s4pz0CfIo SpmUi0z+iQgQ33+Au2iYs2ou3L/Xx/35iSegIlVVbCaeO1DB3BH8swhnMqOvR//zmuzKN17Q7Tbu hQS/rBeynAPuxnX1xE1xXP2lD3XVRXRcni4M+xl8qhW9mXYo6cKZbDGkxQfC5E05lsxTF7c0wWCI i0tamovU+ODDFVVNP1nu8Xh+3FRV8fDltTXVGE9+uGzZU0+fDC9f0bxvkbmk2GnbvHHvunXrmlf0 7N23/81jJ9ZvqKzCVZXr1506+dqNn//DmoXZWfjYce532cyktdU1tdVrumuqq2u4lprsHNyz9l9+ tW4tnpFTvTm6MNlhO2xrblzQXVnxMFtmO3jotX2bNtvbgZG83EVH2wvVuGL+urUnj5177eSJHpLk Ghb3tgfDPdyX+56jf1OBz4Km1WXLxsz5L/LHo+EvsNKUxL20F5THNuFMgpeDmjUS5o+BosS9sb/O iK+F0ovIybwL1TGCkuSwlt2Azx70qSQJXWbuoT7ZWXRa8gGaJLmLTsvWoybZm2gp7PVKz6Em5hw6 Lc9BfeRX5kVN0vNoOZw9KrsG57pQX4Id1cL1DnkBSiJ4pKfgrBM1yfcgZ2IjehlwnYb7S2Um+ntY sgZlw+962QQ4fx7tpefI+bNwvQf1UPhSNAHWy+leKZpK+En4CvXJ1/M0KX85aKr8OD3TLjEhP3Nu oE8OOCWn0Bn4HJfOROel5E9UIfo7WtjfKSlCnyR+gMpBdq+8CHDORNnMvYFdzB2qcRhUoHtKhSpm Q4fQa+g8ugxxnYPr8Xb8Dv6GKWRqmC3MM8xlSYZksWSz5KDkDelIaY50iTQk/SdpVFYj2yw7Kjsn 65ez8pXyTfIP5H+S9yekJaxJeD3ho8TsxPmJDYmnEn+V+MWIxBHVIxwjDo74cMStJEnSgiRv0lNJ R5N+mvT2yNkj9SOXjQyPfG7kSyPPj/zjyIGHRj10klp1IXKSWIv7C1z8Kw2Pju2XxWAwSoYrLPy9 TooMwlqCxsf2pXFrGeQ4k7CWQz1vFdYJMC/8TFgnotGJAWE9Eo0fsV1YjxqRjMKAGUuhg0fhES8K a4ymJyULawYlJj0mrCUoP7YvjVvL0PikSmEtR6qkJcI6AbWNxMI6EU2euF5Yj0T5k38irEeNm560 vdIf6A66O1xhdoYthy3Mzy9i27tZ8tfMcNBh9apYnc+Wy2o8HtZEoEKsyRFyBDsd9twYDNvoCFpZ s9UXYiv8HrvJ4XFYQw62ILcgPwZDQAjELALxg2iOSnoQ0VFJw8i6Q6yVDQetdofXGlzB+p3fxjMq qd4R9LpDIbffR+BdjqAD6HUErb6ww65inUGHgxy0uazBDoeKDftZq6+bDTiCITjgbw9b3T63rwPo 2IBxAhl2OVin3weMWW02vzcA4AQg7ALsHrfN4QPxZ2RUE4iMHEBmZ62hkN/mtgI91u63RbwOX9ga Jvw43R5HiJ1BMNIDrNnvDHdZg46MHMpJ0BEI+u0Rm4OisbtBNHd7JOygPAw5oGLdPpsnYiecdLnD Ln8kDMx43QIhAh/ktQloIyGAJ+KoWK+DSh2ItHvcIZcqjoaK0MzzB9mQA0wB0G5gVRB/GGnCHKAN EEWHBdVRQl0uv/fbB4gZnJGgDwg66EG7nw35VWwo0r7cYQuTHV7HHo+/iwhk8/vsbiJHqIwY1AI3 re3+TgeVgfclykLMEXz+MBgixO8SuwQGfYC/x4ZcVhCr3SHoDRhx+1jrEEn9PvCMIOv1Bx0PFJwN dwccTisQyhXZGnrfa+0mFLx+u9vpJs5m9YTB/WABaK12O5WeVx8QD1iDwFnEYw1SUnZHyN3ho4x0 eLoDrhA5RLzUagMkIXJC5Cg0nBLvdXZeaVbPgxEIZ0Q+BrEBez5PN+se4uogTtBB/scEhSWLEFEl sY0YIg7wOwfPfJc/aA+xGbFozCC0xRtsBgneDEFpYB29EDXtDogngjcCdiAidPrdMdYcq8IQN6w1 EIAgs7Z7HOQGLz3gHmYYlzXMuqwhwOjwDdUKkBv0cTsb8dkFljOG5pYMXsbvt2wI8hlENzUdMZSV 9ZAsAjEjAgasthXWDhAN4tHnj+WQH+5aQ0hB4gImHR4nz1atlq02Giys2VhtWawxaVmdma03GRt1 VdoqNkNjhusMFbtYZ6k1NlhYgDBpDJZm1ljNagzN7EKdoUrFapvqTVqzmTWaWF1dvV6nhT2doVLf UKUz1LAVcM5gtLB6XZ3OAkgtRnpUQKXTmgmyOq2pshYuNRU6vc7SrGKrdRYDwVkNSDVsvcZk0VU2 6DUmtr7BVG80awFHFaA16AzVJqCirdOCEICo0ljfbNLV1FpUcMgCmyrWYtJUaes0poUqwqERRDax FCQXuAQcrLaRHDbXavR6tkJnMVtMWk0dgSXaqTEY64iOGgxVGovOaGArtCCKpkKv5XkDUSr1Gl2d iq3S1GlqtOZBIgRMEGdQHeRAjdagNWn0KtZcr63UkQXoUWfSVlooJOgeNKGn7FYaDWbtogbYADiR BBikVktJgAAa+FdJOaPiG0BcgsdiNFlirCzWmbUqVmPSmQkL1SYjsEvsCSeIjA2gT2I8g8AvsRHZ +7Z3ABQ5LQhYpdXoAaGZsPEtWOpf2lU2RyBM/FsIcj5J0oTKZ1EV9Vw+GYAb1/ggfPk9ugSfhvii FYjPcoMhRoqzSkjCJI2Ah0NV4pOwvdMBmTBEUgrEiJ8klS53iMY7lEOvX6h/IasHiMGpGBTkTKsH joVibA4NKrEwBoJuONIVdIchpbDWCOwG3auFkhwUStZwCQiV4fwHHaEAVCx3p8PTnQuwQVLXKCdu n9Mf9AqiU/XZwmViLg2zHRS5HQT3BztyXeFwoCwvr6urK7ddpJALqRBVIj8KoG4URG7UgVzQNLJo BrTcOfBbCI1mPiqCVTtAsKgCYMIoBJ8gjJJW5EUq2NUhH8DnwkqDPPBmoWkVcYXolQN+HXCmE77t APltPCxqpBBWWJnh20dPVgBvHjhBMHgoJMHDogLAUQCcfRuPiEXEMSuG4/+dnKNQ0g+WlMB+v7Ru epKswnTHDne88BtEK2DPD2PGD+GHfOopTi/FGIJvP9wX8bvoPYcgXwel5AN8hEuCy0nvOmIUbXCC 8NABeyrKm59y6aPnAxRbSKDgB6xhuOeGK/LpEOSxCRoXcYYpF4SWn9Lm5bZROC9A8thFDASa590D vzY46ROsPwNloOoYjgxqQXLWTn9DlC8bnLEK8rHwITsRoOKgp8gdUT9OWHmo3QhmkcdBCsQfCf9h 1EU14qAUB3VCdgLw7QcqEcrnIDd2KkGY+lw73A3TuyKN76agonYj1vXAKXtMJ13UD1wAHaHniGa8 dC9eIhF/cIhv8txGqA5VcdYhay+1p2jrAEC1U9whOK36DjlUMTnzAFMQrkI0Sj0x3G5Bq0Ot//1S i5rjuQ3EPDo8zOsGJeqi+vD+IApiNDhBhiD11hA9M0jRTr8JDRX9JZpYDhA2io+HifdjIq+f2oW3 kI3StlOO3QKnZbEItQgnrYDVT3PEoB3i89KgFr6dEXwAHxYiIjQEVoyXQa3F54H4cyyV2ypYq13Q zKC/8Rpx03PW77EpwcznjCD1Ir+g5R9qcQLTTfl10kxAcOd+S1vfd57opTsmg5dGoZvGtJjZCP9h IfvxOzy3RK/2ONvHex8veYBS4XUWASxWek6Uyk65JTbzxWmkA+CIRC5hLxiXS63Ui3gfFmkM11Ho b8oUn+vsQzzNSu30wzkYSme4Ph7Em0qwuYeec39PVg8KGchB+fIOwSvuhGJeKcbN8CriEPKdY4jm u6hUdno+4wG1MSMm9/ATBF6svBnDPI2PHf2wWtNOY98fx29EiAfRCp1w1/0ArTnQKqprnxDRAXjz lcxKs6sjdiLe9jzf3x8xLprtWfobEnh0UG/6bl/hpXtQHid3IxRqqJYfpFk2Tnvxdvy/idmQ0J+x gjRi1IkRRToJT6wXCQonhmIMUM9eAd8dgtX4+uij+h3eh/z/yFrfLVW7ECthoT46h2irFmkpLSMy wBWhZYQrC1oMHaaJ3tPBHgu9nQnuNMJVFexWUfto6B1yP4NG5mJYE4xG1EBx8ThM8E1wN8MOwc3S a3K1EOANgIuc1aImSkML2MwU0kRx18GuHn61Ahw5UQk7DXBN1jWIdKc8PQOcstAYIucILzynFtgf pDqUKx2lKHJWB1cmwF8r3NUAbh3FR/hXUU2RtSHGZ7XAqYbqiGAmOCuBIz29IrsN8FsPcGaqTw2V mefWQGWohvu8LFrKAW8JnqNK+K0H2gSiBviyUC4IJYsAqaISEnmq6HlCdSHd5TkzClYm60EsuYIu eT6I/htjlM1Ufj28WSq/BXYs1DYawC/iFX2nhmKoi/lRA5VPQ/VgpBQq6D2iRaJPfQzSFGeVSqov YjfCeRWlpKEaMT9QEhHbUOs8yDtECjVUPi3VlJ5Cm0GPWoDXxXZ4f9RRWSsF3fI4eb/nfUIfp91K KiOx7CKgqhV8SkN1N1QKPkII/4NS8BbQCN+VcTobtL5BsG5lzNZG6mXf1spiGotaCqWhtjbHtFBN 47dO4LwhzsNEOzYI/mmMcTZUv2IciXA/JHfwuETaQy1YRf1JL3Bojmnjb+MdzF9aqHE2Ov+EY/l7 aCWP7yQHO9T4XlQVl3PjOwM+G9dQWO8wuMFdPk/z9WtwBorv5R5UxcTJme/xBzthsRvhczg/K8V3 wnbas/M9YSjWpfB1xB/rVLro3cH6zk+HXgoRP/+FKF1esohwYjguvs+00s6BUAs9QJvfV6mGT4wB Wvt5Kl10HRa6FCJfRIAl+6uHTcnBYVPW37KBKMvf0n+Q2jsgzFhuqmHSX+YKeINInNcGdUI04KT3 vMOsPuh9BFsZGt6XEh10xHFuFyzup/1FLp2/wsBNGUy1eaAh8s4FfxguQ67QFf4PFwhfbWVuZHN0 cmVhbQplbmRvYmoKMTE1MCAwIG9iago4NDE0CmVuZG9iagoxMTQ4IDAgb2JqCjw8IC9UeXBlIC9G b250Ci9TdWJ0eXBlIC9DSURGb250VHlwZTIKL0Jhc2VGb250IC9CaXRzdHJlYW1WZXJhU2Fucy1C b2xkCi9DSURTeXN0ZW1JbmZvIDw8IC9SZWdpc3RyeSAoQWRvYmUpIC9PcmRlcmluZyAoSWRlbnRp dHkpIC9TdXBwbGVtZW50IDAgPj4KL0ZvbnREZXNjcmlwdG9yIDExNDYgMCBSCi9DSURUb0dJRE1h cCAvSWRlbnRpdHkKL1cgWzAgWzU5NSAzNDUgNjc3IDg0MyA3MjggNjkwIDM3NyAzNjkgNzA2IDQ3 NCA0ODkgNjgyIDcxMCA3MDYgNTg4IDM0MCA3NjQgMzQwIDY3MyA1OTAgNjkwIDcyNyA2NzggOTE2 IDY5MCA3NjggNzA2IDU3NyA2NjkgODE0IDEwMzQgNzEwIDY5MCA2NjAgNjkwIDQzMiA2OTAgNjMy IDcxNCA3NjggNjkwIDgzMCA2OTAgNzEwIDY0NyA2OTAgODMwIDY0NyA3MTAgOTg3IDgwNiA2Nzgg NzEwIDY0MCA4MjMgNjkwIDQxMiAzNDAgNzU2IDQ1MyA0NTMgNTE3IDQ5NiAzMDQgNDk2IDQ1MyA0 NTMgMzk3IDEwOTQgMzc3IDc2OSA3NjUgMzY5IDM2MiA5OTIgXQpdCj4+CmVuZG9iagoxMTQ5IDAg b2JqCjw8IC9MZW5ndGggODgyID4+CnN0cmVhbQovQ0lESW5pdCAvUHJvY1NldCBmaW5kcmVzb3Vy Y2UgYmVnaW4KMTIgZGljdCBiZWdpbgpiZWdpbmNtYXAKL0NJRFN5c3RlbUluZm8gPDwgL1JlZ2lz dHJ5IChBZG9iZSkgL09yZGVyaW5nIChVQ1MpIC9TdXBwbGVtZW50IDAgPj4gZGVmCi9DTWFwTmFt ZSAvQWRvYmUtSWRlbnRpdHktVUNTIGRlZgovQ01hcFR5cGUgMiBkZWYKMSBiZWdpbmNvZGVzcGFj ZXJhbmdlCjwwMDAwPiA8RkZGRj4KZW5kY29kZXNwYWNlcmFuZ2UKMiBiZWdpbmJmcmFuZ2UKPDAw MDA+IDwwMDAwPiA8MDAwMD4KPDAwMDE+IDwwMDRBPiBbPDAwMjA+IDwwMDU0PiA8MDA0Rj4gPDAw NDM+IDwwMDMxPiA8MDAyRT4gPDAwNDk+IDwwMDZFPiA8MDA3ND4gPDAwNzI+IDwwMDZGPiA8MDA2 ND4gPDAwNzU+IDwwMDYzPiA8MDA2OT4gPDAwNTI+IDwwMDZDPiA8MDA2NT4gPDAwNzM+IDwwMDMy PiA8MDA1MD4gPDAwNDY+IDwwMDc3PiA8MDAzMz4gPDAwNDE+IDwwMDY4PiA8MDA3QT4gPDAwNjE+ IDwwMDQ3PiA8MDA2RD4gPDAwNzA+IDwwMDM0PiA8MDA2Qj4gPDAwMzU+IDwwMDY2PiA8MDAzNj4g PDAwNEM+IDwwMDUzPiA8MDA1Nj4gPDAwMzc+IDwwMDQ4PiA8MDAzOD4gPDAwNjI+IDwwMDc5PiA8 MDAzOT4gPDAwNEU+IDwwMDc2PiA8MDA2Nz4gPDAwNEQ+IDwwMDU1PiA8MDA0NT4gPDAwNzE+IDww MDc4PiA8MDA0ND4gPDAwMzA+IDwwMDJEPiA8MDA2QT4gPDAwNDI+IDwwMDI4PiA8MDAyOT4gPDAw MjI+IDwwMDVGPiA8MDAyNz4gPDAwQTc+IDwwMDVCPiA8MDA1RD4gPDAwM0E+IDwwMDU3PiA8MDAy Qz4gPDAwNEI+IDwwMDU4PiA8MDA0QT4gPDAwMkY+IDwwMDQwPiBdCmVuZGJmcmFuZ2UKZW5kY21h cApDTWFwTmFtZSBjdXJyZW50ZGljdCAvQ01hcCBkZWZpbmVyZXNvdXJjZSBwb3AKZW5kCmVuZApl bmRzdHJlYW0KZW5kb2JqCjYgMCBvYmoKPDwgL1R5cGUgL0ZvbnQKL1N1YnR5cGUgL1R5cGUwCi9C YXNlRm9udCAvQml0c3RyZWFtVmVyYVNhbnMtQm9sZAovRW5jb2RpbmcgL0lkZW50aXR5LUgKL0Rl c2NlbmRhbnRGb250cyBbMTE0OCAwIFJdCi9Ub1VuaWNvZGUgMTE0OSAwIFI+PgplbmRvYmoKMTE1 MSAwIG9iago8PCAvVHlwZSAvRm9udERlc2NyaXB0b3IKL0ZvbnROYW1lIC9RSFNCQUErTGliZXJh dGlvblNhbnMKL0ZsYWdzIDQgCi9Gb250QkJveCBbLTIwMy4xMjUwMDAgLTMwMy4yMjI2NTYgMTA1 MC4yOTI5NiA5MTAuMTU2MjUwIF0KL0l0YWxpY0FuZ2xlIDAgCi9Bc2NlbnQgOTA1LjI3MzQzNyAK L0Rlc2NlbnQgLTIxMS45MTQwNjIgCi9DYXBIZWlnaHQgOTA1LjI3MzQzNyAKL1N0ZW1WIDczLjI0 MjE4NzUgCi9Gb250RmlsZTIgMTE1MiAwIFIKPj4gZW5kb2JqCjExNTIgMCBvYmoKPDwKL0xlbmd0 aDEgOTMyMCAKL0xlbmd0aCAxMTU1IDAgUgovRmlsdGVyIC9GbGF0ZURlY29kZQo+PgpzdHJlYW0K eJylWQl4W9WVvvfpSfKmXU+Sre1p39enZ1ne5d3xvsSOszmKrVhO4gVbJguQxEkIYMLahdLJRyml HQo0dEmhHaDQ8rWhbYC2DNPpMJ3O15aZbwoD0w60lMRiznuWHcdJmaGj+z2/8+67y7nn/vc/5zwj jBAqQMeQAKGegVD0T2WnTkHNabh2Tew/tGcp++I7IL+FUOnpTDo1vuf+diNCZQehrjwDFbIi0RF4 /io82zNT2YMv7FPp4fnv4fmZ/TNjqXu0n/41Qvq7ufGmUgdnEYNOwvN/wTM9nZpK9/3yLRIhgxyU 2IwE5FP4biREBcLPChmEsH7lLvgp2kMoC4REsYgkuB/5ICKe6EUHL6L8L5IcaET1yHKREL6a68OM uBZ/fRdCn/vVzxEiK4WL3GyIgNKEEDEuhJmQGCFGYVE4LApLE0Hn7PgzuYxw8wePNZEvQbtdH74p /Lnw08iM6kAPkZgvLpHLyRXWGS/nS1Sr4YrYuVJvs660o9Qr9XHNSjvhz3EwvHXr8RMPP3H8xPAW nx+HgiNbTi4++siJ4yPDoeAL2GypS+4YPXx052hd0kRbzMm60Z03nNy1s67GZCDOf/GWW3btirEY V5TvTp26+cGHT50c3cFEMMPsHD156qGjmYmOdo/b7WnvmMgcPZbZ19Hl9WPs93V17NsLawH7CvvB BmJUhpBFYBHYMINxXmdXfm1igYW86/PLRx76AVH3C6J8+axCIi8qFhdgQlxQJJHIZOcIGT6TGxcu fnCUJNwet82i1QhFGq3VBg+5CMLo5g/fFLxJVqI4WEyRNwETzZtKwShEWpFWDcUGBmRh6rgtP7dt 1a4KXFlSpC/1e+vq2KjTrlbhc5jAsOGPwgWSoMxMu70xtmVbfdLrVanJyuX+3li52SKRainoVdNP zF/6is3utNi0OjGp1RgNJgMVdrhKDRIZ1lKhYFtbmvgp6Gr+8B3CK/SjUoQc3M5aWYWNZeIMxVA2 TneG2zrC6/H64/9400n24IsvlpXWlZbpjAXFogL8HvGzE3/4w4nlzd1mGgtJESwY3Qk4fVt4AYXh ofxKfGgVNsUGc1NQxSjUIHAPuMZks/q80UjdRFODyyGX4G9icaGu1OdvSUZZm1OlPgeGAAsIFuMu R1lpSRE2GCNMS+vAcog428TGbFalHGON1uutru5YPi68kDtisVgMRqVazOlWiJD4FCCgEvbfJliv CIcF1YqSq0qXx1WrVVyJrlUK//237xaXSAtLSqTFxSWSoj/+Npc6vyxXyIolxVKFqEDMFdF7T73H iSIochkuEEtKZBL5n88LjjrYWCieqCoPMzHHpUXh4qXF+praSBXT1KSnzSajUa8VTF36hFYPe2am 9U3NNgvL1FaxgqNwZNHQh2+SRrIbUYiFBRHrzqLckddUHMufwlUTi66EIGnEN9709tyWkZo6swW/ cWT7tqqE0fCsSu1wlscbm+MVLreKwlqNy1Eeq22uiLtdFEWYcr+9/TTGNktr877Ju4gQxlZbS2tm 7+03DfRFIwBQFRWJ9g8cPtI/EImq1GplNDLQDxa/FZS+FfQNcCwTY3nEswynD5wAilkPEIrTOs8c WsWdHNp50JNKLWU0eNwJjVpVotTpTLU+v95YIsWCWqvdarUYDTodbyqTqiYUMBkANQIh8UWSxACO MNPY3Ld8ATRZAgYUAC6LYe+xmIcdd/wF4dy9JwFVr7+aa8cv47enckeFFy6lCEkutHwfZ/HbwM41 0I9nShXLUALoedu5c+eE9OOPf/CvZOXFH6ysU/A2rBPOvEWxkQZhsrWlq/mla65cOhRKIUjgIklp mddfu4p1/sBzeBeU0maPuzzWujVZ7/OqVcTZHjZmNcskgHR/TV3f8h2CAavTbrPotAVCjVZvMphV QZfDUAq20GgDodZNY8shWMvm3JDgHbIDtaNJjs3zRzG+Dhwsu0ZG1pXX8fUkz8TyDwzAiuKIjDu7 qtiVC9ZuQBxh39HWxsSAnr6prK1O10QjdissgjKYgFYq2jJtm4IhSouxVh0Nd3fOzg0NhHiag4U/ tkJ4M9cFdGUuT5RlmyOM2SJTYKyQ0eZopIllGY+7rDQ3jNUquzUaqS7rcHsUcpejunrorMfhMpjk Spu1uSmz55bjmYlNbS4HjrEpHW0y6tUqspDSGk12p/PS938zlxWcn+3viTE6+DFsT9/sQk9vJKqm YB2R3m7Y4wnwhQ+CL2wGHKzaYZUdNro+7arrW6UN1sJaFBv850TAt3XLieNnj+9OtbeBUZ4sszsZ trF5y7Gdu2pqTTS2WJL1u0eP9be2JOJ+nzG3jdgcqkt29+4Y3fuNk6eGt/oCxPlVJwgb7fNX13WW M36vyaSQb3CDUomOMpYZcw/mysI+v8WiUq+6UcDFydwwsEoXSqCRdV6eA4BNreXd1RUYzi96DcNM 9KOZJ36ZeVTqYKizazY7PBwU8lvMgfwsXtltEmDudcci9bNdnaGgWvVMicRgikTba2Ksy6PRYrXS aS9nWzuiEZNBUkJYb5zIdHTA2vy+NCFXaEsNZkNuRChy2e0mg4YqFCiVpXqDqZRx2nWakiK3p3VT OnNsvLu7nDUasFwRDg8Oncp2c5usxUZDRby3B3b5EeCJHPiIYj4uoiz56xEycOleQfTSy4L7hItn ctWfzVFnoPXTYK8j6HUuamSAG55+4fXXV8YQ0itjQF+eayxwkall0XPPER88R9yxPC9cXH6cGPxg jdXngT3a0Sj0BLvHV/EVZzcAS+xaZ3SKd9GcdanVDePKqv1da4davLoj0B4/8HDfAPa4G+o3Dw7/ N5bIDEZfoJL1eM20Ui18ptCoZ5nuzpkfZyYoqkomk0lttM3B2J0abUmJQGS02oKhRJVtc0Od30tR 32+srA4ES/XhoHpo8317WxrdLpmMIKsaQ0GTQSYRF6jUFltUUV8eczu11I7Rr+aCvW4PbPVsASnE 0hKjHniN9fjgmCpupU3RcFUlO0IS4sLSMn+gfSQUXuFWkQ2sM8xZM/ZxufVqorVdPYgAFRVrSh3O eCIYMlvlym9cpl6t0eC0R0PJG9pajAKdyehxRyPJ/upKl0Ol/PqVvT4OLUeie69i6LX+lNbjravv X74DsDH84VukDlbv5ePJ9eGkdh1TKzYSErX+IIrh6Mid9kSid6G1uewBhYmOMp1d+39/4xGnozE5 Mpy+dfu2irhOg/9O1tZ2SyAS9foMRhL/aailjWH1xlCwPRAIhGxOje6uO7H+vn2TDQ0mA8a+QGf3 5N5DuqVHe7sBRw5nbTIF+/Wt3Ad4Ec4E5DIOSp3XwMbh0MbiRVJYVCyRq27wl+m2vP4I6/M7nBar ub6xIfk656E+fEvwDnhbH+pYiUi5xankjhXnw3LeKMZeEUPnvRTeEGizG7hIwEb7Bw+9PLob4zsP D/RHebeSj6ofJ/IEtPxPUgltDoebWypYp02tUqntzlh5S0M4YqZlirOZQGDpNlxKsDgQTBVqKZ0G WAZ/4aKKYxwTpS0oVEN8oi/V49nrenoZVqvTalhmoP/QfG93NKylYKcZpm+Ai0SfhT83AkNwvAHL efY5Lp+A+m34J0QPMcvVq1gLtQ2/i3/y4IMcR3CckoYeSuS4zNE2oJeNyRdXlc+30jhWvm3HjUfu Wf49/tkXlm4dH6uIP4/d3vZNE5nDud/jypnRnc3NLhfxytduvmXr9kBIuOj2DA4tnvjGnRPjDfW0 6eLX7PbWFsieMIJsl6gW/gjZuKzGxmUJbGwd/VPrg3rIHvDkuc98prjIbIgxfWa7tUyh0So9Or1E TopeFTx1qV3w1InDlbGIy66lBALRbQIBxrioREWZTK7UCW69JwH3RkCCB1gRIl3LijdaRVMszhcO CmouEuHPPKeIwHnlvmuv9kG5+Rv6BqKre34WAABOiIwM9h++sHvXs1giNdOhcHNreYXNqQQvmfc6 DeEwbVbICOvyjwK+8TKDUVsqV5AFWtDYbneR/5kbMemN6jJqIhhYWsr9era3h4VQgtvyWP/AwWxP bzgKMY5WE4sO9HEISECW+CTEYps3eNyrIrLVjMm5LumObgg5Vle5vgiexAZzvKJvIDO6qaui0uFS fk7T3nYsEQ3brJQKa3RuT2VVS7Ieok3I3vZlfvz1fRnjQ4U6ndXm8QcOV1ZBQEa5HPHypC/g93ud dqNBIce+rspqtwdWIpNYzOVMl3nY7SkQUyqLORKhzZRaIVXLNZTNyjBdn+zuxHV1t6u9RoNSXih2 ODf5DUYVJZHJIXuSqzQ6i9XnX4nMcS0fYfNnYemc8MIHMUAA71shj74cefMe9oUXBPteeeXSp155 BfoezW0hHoC+1nUxGbNh69dIgj1KUQF/a/Pus6ONLT4/H3JSfl9L4+jZ3c2t/gDkOeqlY0cXFqan 9u6dmlk4cOTY0ukjxxYOTE1PTk5PXZ89duQ0zAnaCP4Memm4LBJfzhEvp41E+rXcgeffFhUXFBcV isVC7l5cVPDH5yBRr9eaaKvNRFMUbbZYaJOW+B6MWQLr8K2sA6+nzPVU5loLvAgfLCTQ0rrr7M7m xoBPS1FaX6CxeefZXa0tAW4ZclA7e/2K2gcWQO2lY0cOLMxwy5peWDh6bGmVUTLAKFrwLZATcXHK Kpms0TYWxK6iFfJ07t5c+3PEfQd3bKuv40JJr68+uQ3f/b4G/FZ1dWeuCr/UX13tcqiVRPvyU8JF vZFhN3XsbKpPlpe7XPLlzwveqg8FLSaFbPl9SuWwRSPciYAoSPAj8HQ1l/0c/+Vozc/lw+a14Gj9 pwXxuuwRqzgaL4917UrWy54sNJkYtn1T6tiWkXhFaRlWKi3mgI9lEhVV21pbWIY2S78tTSQmuxg4 BxIpYd3R3RNPwJHAbGx/SVNNXTBkMGK/t2tTZs/BqcH++hq/l//0ALlaoLK6UbqVjYHMsF3d3Cp2 QCz3PmQJ6cs76aLzZ/paDuqKs73KqBvTijVmVV99zsn3rba2tqnpT+f+/IlPuL8tMRmY8Kb2PZtb W2KM0WCmE4me3tHqyuryilDEalepPe62tt2p+eM7tyfrXQ7dM7JSPZc49O9uaHJ55UowXHlrS199 Qz2EYozTAW7r5pGOjvIKI423b3vCUeEPmi1KpUxiNoWDjU1+LyRSSm2JQspl6V4uSR1vawkFKQqr NG5PdW2PJepx6/VSCcZypcnk9gbr3B69XglDyCB8NRi93kQl2C0Icfc5/usc718gXaKIn3wnZyBP kW9c1JNvnDmD8tH5PdCqkGvFRebQksITAuWlt58T/Af5xvK7Dyx/HwJ0rq0Wzunv4JzyGT+2YS7d 5zJ+S+6Xude/hxdz95zHUlzyw9w9+BR+JtdE+Alpbhv+4vK7yz/j+k/AXCWwk/VcbH8ZcZdDi40h eXzj6VktFmqC2dTe19fbnazzuJRKiKHDlfFg2AERlfhbhRa6KjHQty8z0J+Im03cJ4B4RU1tTW15 hdevJX51dGHrlk1ttTV1Nc2Nw1UhPw3nRiYzmX3BSkVHUyMD2RDgLxxtbdvZWp9MVLHlDBthGAiX Evdz57wXEGn7i99w1zvxj/iGu/b1yIYdroamka17Mlu21jc4nE5HQ8PWkX3jW7c0NDgdT0KG53LH E21diSqnR6WmVB5XomJTS2WFB+J/4rs/Xjo9OORwYuy0Dw2eXrrw2unbB/ptFoutf+D206/97XXT TUmj3mBMNk1f96WHZmYamw0mk6G5cWYG9gM2lZTB3hdx+2FRCFkHl6CdwRO57+GuL+Hh+8nq3zz6 xkXd/Ss4ERHQtoL/HsOrnic0G7584NYSAgZvJHHMKIRDK1mpVCaVKqS5T57K3SXiPueJC8TgCLlX j17EB0RA8YUFYoGgQFxSCCSPZ98TPA6xUYAJxyL+UNR5qV7wvEyt0mmgxCor4iGGdV4aFC5eCqnN tMUKmY/cZLLQtFkt+CkfA9LAgxwvG1dywSuYg+UOhiKPL/zDx6ZmrE8XaTUWs9vlmaiphpjuJYMx Fu/sVo9s+a45GQyZzBJpW8vtguYzl2zpvr5ElYmGY4FGABNlgIkk2o2Or2OqDahYSz83MtMaxKnV aCN2baZa+/Ct2viFZONnSQipKqu2bb/hppHtldUGo07jcTGReBWkVrRcwaXng/3Tc0ODFXG9Xq4w 08FQTTUbA37S/AsXsUWi7a2RqMkikRYXmSDo7B1ko0Z9IbffEqnVVlG1ube8wmqTc1+O5DZrZaKv vyJus8ok+LatHV3lFSbge9pUwXZ1jHTWVPt9+tIiEpyI38fGqtsb65mI0cB9a442NLZXxSBrMdHF ZDHPnNVEZyzgs5i5L89ypdniC8R8Pr/dodFqNQ673+dbPsSEg067VqPROpyhKNMQiztcFPxcjgoW cf93gqvmd93eUVn1e9w/oa7+5YbEp4TcV0zRWhX0EdfmulFjwUsIfciIT/Ejrf+FiLdQkyiBUsIh RJLz6GYigcxwvxPuSHwHKgR5iHgU3UoitITPo9vg+VauDvpMwP0k9HsE2j4tPI8egedh0aP8+2Go +xbfN4Gehf7buPcgG7k+MFYCxlri+sG7o/AshnsJPwZCwzDmDvI3KAgX96yFPtxcvXCdgfG5Ohrk EdBfjQ6js5jEAXwDlH8mYsQh4lPEI8RFwWdJMXkH+TD5BHleOCR8TRQUdYqeF10Q/UJcKu4Tf7eg paC/YLzggYIXC4nCTYVfKWov2l40V3Rv0R+LtxbPFr9cgkp+wFsrhE5wUeeKNa/6GfDQWv1O9J28 jJEM1+RlAonxjrwsQGX4b/IyCW3+IS8LUQmxOr4ISQlfXhajw4JwXi5AasFrebkQScmCvFyMDGRf Xi4Bm13IyxJ0VHgxL0uRT/QqzI7JQu5/jbwmnIyRCRvzMoGkuCsvC1AMp/MyCW2ezMtCpMP/lpdF yEBI8rIYvUtU5uUC5BY8lpcLkUHwu7xcjCpIbV4uQdvJ6bwsQTnyYl6WAq5uQI1oBs2iQ2gOTYJ/ zaAsotGX4YqiMJQ4SP0QOY3DvQ2l4K0fpHY0jcYgPqCBrfZDodf1nuef0nBPw/16vi/XshN6NaBm GC2JBkHuQd1QO8m3T8GVhdYpaJtGU3CfQ/ugbgbt+cj5UePM7KG5yYlMlv4yHQ2H43R/epxuS2X9 dPv0WJBO7t9P86/n6bn0fHru+vR4kO5sb2juTw6293TTk/N0is7OpcbTU6m5ffTMniv7I1B6Eug4 zauWBXkGJqbRADxNg+Koc3J3ei6VnZyZpgdS01DBqTqBFsAk3BJQf3piYX8KhCS0HoN30/wC52CM AG+Sjxw9OT+Wnh5Pz9EB+qqJPq5iQ3zb+bWWEbAet7toKD03zzWLBMPxaw97jUE/Sof/346uYGeC HyXLj73ScpIfezO0GOBb9fI9OYNm+dmm+VaD15ixB2bcA/05819uOcaPnYXnlZFnQM7kt2YvbOAc r8E43291bfMc4tZZ9n9BD0BuYnI+m56DyslpenNwIEj3prLp6Sydmh6nB9c69uzZMzmW5ivH0nPZ FDSeyWZg3/cuzE3Oj0+OcbPNB6+FIu7wzsHxnbliEy4jp3FmbnZmRV0EluMsdj1vhy6+eZY/p3yX gWz6+jTdlcpm0/Nc4wz/ehZVAiWH0AG+BKHTlRqM5ecP8tIUtESZbHa2MhQ6cOBAMJVXYwy0CI7N TIX++mGzwFCzPBbSPIonoO0KooP8mFNw5D5y6uyh2fR4en5yYhoAH8xkp6D9Zp6kVkHJAWAFvNcG 9h7+zsFtnu+RBdVTPEBXQT8PwNkN8EnzoOFGnMmPy7XZnwfhdH7WFCyC682BdRXIC+v29gCvzxj8 pWHxM/CO6zPGjzHLb934utE/rs4Ap83zaQ602QwAeR2s98wAQudn9mQPpObSHMjnF3bvTY9l6ewM tE3T+wGs09A1NTGXTk9xcF7gsXYgMzmWoQ/NLNCpsbH0bBZgzzX/SyMH/3ow7L/GWv+PMNi/pk0e Awj9D7X5Np9lbmRzdHJlYW0KZW5kb2JqCjExNTUgMCBvYmoKNTk5MwplbmRvYmoKMTE1MyAwIG9i ago8PCAvVHlwZSAvRm9udAovU3VidHlwZSAvQ0lERm9udFR5cGUyCi9CYXNlRm9udCAvTGliZXJh dGlvblNhbnMKL0NJRFN5c3RlbUluZm8gPDwgL1JlZ2lzdHJ5IChBZG9iZSkgL09yZGVyaW5nIChJ ZGVudGl0eSkgL1N1cHBsZW1lbnQgMCA+PgovRm9udERlc2NyaXB0b3IgMTE1MSAwIFIKL0NJRFRv R0lETWFwIC9JZGVudGl0eQovVyBbMCBbMzYyIDc3MiA2NjIgNTUyIDI3NiA1NTIgMjc2IDkzNiA1 NTIgMzMwIDQ5NiAyMjAgNTUyIDU1MiA3NzIgNTUyIDY2MiAyNzYgNzE2IDU1MiA4MjYgNTUyIDI3 NiA1NTIgMjc2IDMzMCA3MTYgMjc2IDU1MiA0OTYgMjIwIDI3NiAzMzAgNDk2IDMzMCA3MTYgNDk2 IDY2MiA2MDYgNjA2IDQ5NiA1NTIgNTUyIDU1MiA4MjYgNDk2IDU1MiBdCl0KPj4KZW5kb2JqCjEx NTQgMCBvYmoKPDwgL0xlbmd0aCA2ODYgPj4Kc3RyZWFtCi9DSURJbml0IC9Qcm9jU2V0IGZpbmRy ZXNvdXJjZSBiZWdpbgoxMiBkaWN0IGJlZ2luCmJlZ2luY21hcAovQ0lEU3lzdGVtSW5mbyA8PCAv UmVnaXN0cnkgKEFkb2JlKSAvT3JkZXJpbmcgKFVDUykgL1N1cHBsZW1lbnQgMCA+PiBkZWYKL0NN YXBOYW1lIC9BZG9iZS1JZGVudGl0eS1VQ1MgZGVmCi9DTWFwVHlwZSAyIGRlZgoxIGJlZ2luY29k ZXNwYWNlcmFuZ2UKPDAwMDA+IDxGRkZGPgplbmRjb2Rlc3BhY2VyYW5nZQoyIGJlZ2luYmZyYW5n ZQo8MDAwMD4gPDAwMDA+IDwwMDAwPgo8MDAwMT4gPDAwMkU+IFs8MDA0Rj4gPDAwNDE+IDwwMDc1 PiA8MDA3ND4gPDAwNjg+IDwwMDIwPiA8MDA1Nz4gPDAwNkY+IDwwMDcyPiA8MDA2Qj4gPDAwNjk+ IDwwMDZFPiA8MDA2Nz4gPDAwNDc+IDwwMDcwPiA8MDA0NT4gPDAwMkU+IDwwMDQ4PiA8MDA2MT4g PDAwNkQ+IDwwMDY1PiA8MDAyQz4gPDAwNjQ+IDwwMDQ5PiA8MDAyRD4gPDAwNDQ+IDwwMDY2PiA8 MDA2Mj4gPDAwNzM+IDwwMDZDPiA8MDAzQT4gPDAwMjg+IDwwMDc2PiA8MDAyOT4gPDAwNTI+IDww MDYzPiA8MDA1Mz4gPDAwNTQ+IDwwMDQ2PiA8MDA3OD4gPDAwMzI+IDwwMDMwPiA8MDAzMT4gPDAw NEQ+IDwwMDRBPiA8MDAzOD4gXQplbmRiZnJhbmdlCmVuZGNtYXAKQ01hcE5hbWUgY3VycmVudGRp Y3QgL0NNYXAgZGVmaW5lcmVzb3VyY2UgcG9wCmVuZAplbmQKZW5kc3RyZWFtCmVuZG9iago3IDAg b2JqCjw8IC9UeXBlIC9Gb250Ci9TdWJ0eXBlIC9UeXBlMAovQmFzZUZvbnQgL0xpYmVyYXRpb25T YW5zCi9FbmNvZGluZyAvSWRlbnRpdHktSAovRGVzY2VuZGFudEZvbnRzIFsxMTUzIDAgUl0KL1Rv VW5pY29kZSAxMTU0IDAgUj4+CmVuZG9iagoxMTU2IDAgb2JqCjw8IC9UeXBlIC9Gb250RGVzY3Jp cHRvcgovRm9udE5hbWUgL1FNU0JBQStCaXRzdHJlYW1WZXJhU2Fucy1Sb21hbgovRmxhZ3MgNCAK L0ZvbnRCQm94IFstMTgzLjEwNTQ2OCAtMjM1LjgzOTg0MyAxMjg3LjEwOTM3IDkyOC4yMjI2NTYg XQovSXRhbGljQW5nbGUgMCAKL0FzY2VudCA5MjguMjIyNjU2IAovRGVzY2VudCAtMjM1LjgzOTg0 MyAKL0NhcEhlaWdodCA5MjguMjIyNjU2IAovU3RlbVYgNjkuODI0MjE4NyAKL0ZvbnRGaWxlMiAx MTU3IDAgUgo+PiBlbmRvYmoKMTE1NyAwIG9iago8PAovTGVuZ3RoMSAxNTE1NiAKL0xlbmd0aCAx MTYwIDAgUgovRmlsdGVyIC9GbGF0ZURlY29kZQo+PgpzdHJlYW0KeJy1eglYU1e++Dk3C4h1QUBa O33eEIGqCAJSqo5LhADBEDAJqwqELBDNZhJERMWliogttW61UqRWHR9jnU5rO2p1Zjq2dW3nVes3 Y512RnnW9o2v9XU681kkl/c7594bAjqdft/7/xPvzbnn/M5v385FhBFC4WgtkiBUaEhJO1b1nRlm tsJVUutotM2s/u4YjP8ToXHSOqvJYivUJMH4S5h7qg4mRq4Iz0PocRaeJ9Q5/SvWjJ28FJ6zEcJ5 DrfZNEImfxKhnxB8h5ymFR5UhmwIPTENnlmXyWm9durcW/BshOvPCEtH4ueRDElludJLCHHz+F/G gNoZWzjDDJdLJOFShpGuRegXoxGbj4TPPLvfh+Yi9j4jj+ai8UthTtwD01hYZpCN2yW1yQ6AlGEI RUUqIuMVkQqbFPX5JI/33eJ2hY28961XPhHh/l6EpF/JrhI4iSJGEamMVMil3wS+vhj4Wna1u/eq bDLBexKgLPJoFAsPAJKQmKCUh8ljYJge+VTmU5ljY8dKLcfxrNmrdhWXnDgxr6Js+btmM3MgsIjp 7CwqxJXVrwZa5NGBTkt6KsbLVxAePf03pc3SJjQOKQFrjAJwZKYBrhjAnMgmJkSNhoe02LFhhFpc mDxM2tz3xvA626/sVnONpda+hPvb3k68c0ffzWfW/4rRGzbvXVg5gqms+E2NFY97LOPopLGxuKMD R+Axr3bhbS+8t7uiorTsZULZ139Tdk12F41C44EykItiYsemA+0oJjEhkY0dG8WEyeOBhUhgQZL4 2doNGG9Y+9mf1jVj3LzuT3j66Xcwfuc0d5Z7753Tp9+RafGrB7hb3K1XDxx4FT+OHz/w6sHLn3D7 uH2XP8GXL+MabPrkMqE7GiFZHeiaQRFAFytwOlZKFBIlc4r7monnmm4x0y9vDlRtviobGXhMcrR3 Mm7m1oH2X+vvkZZJq4n2o0Dh0TyzmTBUZgD3yrjEhKPHZ89avaOsGB8/nl1aXv87sxWfZA4FTPsK i6oqDzJN97uO2FLTVqwAbJnAyreyThRDbElMTvClxxAsGYAwPRI34CZuY8IE/+nTVxcsaGmRdXK/ aw90tSYmvlRUeJmpbseziU/sAp/IBy1OQCge0GQQPyBf0VxkIh2MGhMND/DFrcy7fVrvuQ/STYnx GOuLN1bZlzY0LrWXf7llS5xy4biNm7q7u5dfODvTUZCfv1w7X6HIujR13GPYV//uIr3B88SWrUD1 OpA+ijgSv5nA9PUrVziO6HYTeFN70KZxvE0zx2Y+FTkabApuFDka3EoObsVkPsW0deiKMC7SdXQU 6XRFHb2bnnlmU+/9ZzZhvOkZWdGevdyH3KUX92K890U8Dafv3dP1wTmuhWv54BzG5z7Ajbjx3AdA cyXQnAIePAKl8DRjonmamRmZvGkIwYwE0IMiQ4gZXi3AD/PrvxSXqOa69yxeCEabU1nV8prFhteu uY8ZrDfurl64yGCprlz4txUrmPT09Kaa6TMxdjmOTdQG1nXbpqZhXFO9/3R19Zg1uWo8Nja5OzE6 as0aoollwFU9cBXURIzoMAm8Joh3E8aIdzO+ncUlJcU7t5cUY1xcsv1u62aMN7fe/baltbVF8mef //x5n9/vO3+23vdyRwd3h/vvjk6MOztwFI7u6OAzgyQfqBFvIvjFtBAjWD9Wks8qEya/rDeeODFj 8aJNUbFjn5AcGzMsDGOL7deBN6TVR21pkBOkUsL7u4ClEfIMn7fSKSLlu8fhI62+3yWP/goolgHF 6xANwwBCEYOJ62HFMsmSgJY51reaORawSqsP913fflgSL2Yu4O8hmSvmR2cuYFJMXJjYmrkHPBKJ Y4inx8TwiRNiJ2MaSM3ce90Sn4hTuI9PvP56aelpefSeJyfWmtv7UiQft+veKSkWMmrYE8DXJHgQ +IgFHNMG+Jv2EG1KJ6qrqzb8oqoSn5g+vf55veHE9BnLn4OfE7PLS1c2lhZLWlfNnIFxY9NNIkBX oY4XgOncr9PioDBE47NmAxclCMkzQJePEG1H0X+QkiTKkuNf3Lr2xa3j3PVr//PtNWl13y7JEnLd 75Ls6lsiVoQO0EIEtRNkMqwE/Z48wcT/NXCUWXo3cPaEPLrPjnsC3wWOMMrAZ2Ddk+CZB2DPKJIz sJAnRO/EQlyQOFWCdybGgNySW5Antm3XG4367duK9YH2GeVlTZfWNjevvdRUVj7jxAkm5UK9z1d/ 4SLxUkZvTpu6fz93j7u3fz9OS7EeBmLA64BXUZ8Cf5JHf3+HrLj7b0rOghXSiS2J+xKG5GCKWCFx JUJWTMwYy7NIYjgR/iVkJvClSdKmMxortmSpcdrUnXPeM+ibVv+hwlTjsJlratbl5uDU9J/P/bm2 AONlno9sFeXSOUefjI7CkyYZVcoEduQkrW5zx8JFeMzoCb9+6rHHp0zW509MTBg1Yb5mw8ulxXjU KDGaK4D3aKozMeUTtkj4EoVhQYEZ03iFSvYfPz6ztHzVxea1a5svriovDZyj2jMaqSYlbzOV3985 bE1Jw6CkcBy+f//UNG4sVeBFqkzQiwX/mWlmNlCNgXNbmMcDt5gNB4gNuRLpAdAY5Sc+6JshhnvA sD6I/FCzMU8PMurhwFF5RPdgy+E7IWYFfmZxxdArVKNIqKBEfAg1ktAyid+lM9sLNfmrtju0kyal K7iZZ3AlrjxTd27WbPzShAmbjFJd3w6Jg1jb098juQ28KwRr00gjXI4V2g5SAyOhPpBeRHIbKkPh m2b4vFkIVaJAb1jM7diJX9yJw4oXFEkzjkyKjcEe74cfebw4Njqpe8KYMfv24ZE4svNlPDqK0DsP 3M6Eej+c+p2CGA/uyvMXmM8vXAjEXZBdDXQwlt7JzNnAdGJrgJc+C/ARfLaibBE24wk/sYQ/SDJ4 O/dsAcSytuBZ7ml8rnc9aUrW93IXZCmB3+N8TcvGfM0h4Ov6555lgcNEd4CV6E5OuMCk55jFq4hb 1AuRbZQcud9FuO3sH4PPQGWV0coqUUbdvXJgnZ47wv0Wz6WeCJavoHUFulksZifByLFgfMWgWBHL n+imsRnpkv16446dCwyGBTt3GPXHm9dy92uKSxYUFekMb1VUzCgrX/XRGvh8tKq8bMZxZtZZtxNj p/vsOafL5fwv7saWraNGjH8zKSamqvI3C82pabQOSbGk8+XUtJpukOAGSFpB9YcyFZGyjPh00t9w OJ/bg60XcH7fgW6pL+94Xu/Vbl7bMiNAx6I4kIdoOEopIepWEjNJIf5J0xIpVk6l5Nm5c2bN/vDa b/LVuQ1/uoDPYbRmDZ6bFdjCbdNqMNZotzGnYnPz1nB1uHlnWmqgVXYVL1n6x2cXL2YKA19nZ21Y nz2P9wqpEujy9UtBWzDleUlFwMMUBV4Hp+jm8roDmQBJ+tRE6GlEf01k+bYmXmyTlVJev8Q/ZIk2 n38919/SinFrC8br/T7b0vqGZ7jXzsAHGzauWC6ruVo5NRl3dHLXuD9C75ySXH0lb8IE/PHvcS2u hXtcPPWDm1IL8Bcv8CcWcsiGCrlo4bEhjd5nkscCXZOnTJ7S+8I2vGsX901Vtbm2orp66RGbhVT5 I/rCBUYi1gujwsOgufivb6HRihzNXkyLfRQvWtixd9HCMVHxkGu2QJ/bRnu4qXC6oZ15sHcBf4sn mXcaXytpUyn8kqilGVkiH8iExDmZNqiQBv3zzxv0WG/gDm7Izcdrmz//fG1zXv7abYYFz2z6x70N 0PMZ9C/k4/y8DevzNZr89Rvy8pn3IbxaNmsLdNqWlgJt6fiKsnVv2GsxrrW/sa6sYryyxvLcpyQ1 ffqcpUaJ59TPVanm1vvmzcV47jwSKxaw8QHa6Y+gnb4knTQyxK8yJHKOwVwGd/Xq+UClLL6vR/Jh X/phrgtXnyE714L2W0AHLOgAZWYIh6Ko0F4SDiiR5IACYuOQvE9UdUOr080/u9Q+amZZueMv6zeA J/RgCfR0hw5ztwoKdHj25qLCwqLNrToIuvHHJ0RF45aNOKokOQWcZtOdW1vbaKNLDi6jRjG7Fy/e 31W1eHFV1/7Fi3nPxdtBKqGOnr8Azto7mWau/n7Z6zTy6KkineXPUop4BTlNQW6IV+Dt3+GM55/D +LnnuYvcPLwP//LSBXzpElfEmWQp9xu2tuEUnLS17dCxt7l13Jq33sZAB/BK71C8Y9FEel4RBR4Y JioSFWm8f4oekQjUcPZ+0tvv507hydvz8/Lyt3NXLzDS26tX4bmqJsg/m1t7A18y5wOfZc/b2pY9 j7Fxs5/O9HqmZ+JD1dW/bF2gj1JYandD8sEkOx4Gi5Kzm5zvOpVYcVjy28DNK5gLpMuulvSug4My H9ttQsYXYxuu85LXA+NIlmfu9c0mkZDTHeghGet17lumST6G1DXR22OV4Oakj8xkmlrmqubN3dS1 WzM/X/OifMwXN27cvn2z59Zfe27e+LznJu1gDgAGN48hKl0oE2FK4Rx2oGvXfJKZ5u/q2sg7p3zM nZs9n9+42fPXWz03b9++cUOsU+liRiI9BtyU5/FoZtd73N3AkvdkV++Pl97onSy9cX88sfZd2HRG quS7dHIKI85998oVchaTKjnyHqJ/HvMG7ymk4DDh3YF73bKr3zthbSboqBHq0XASGaBI8g/qktTC LcXd17iT3Mlr+E3Oew1PxBOl1YE/B97Fx7k8Jp8Zyy3D7YT+UclXEidgl1EcyoyodImM3vE6UrLw S+Qu+eo1PId79zV6f3AXrXDx9I7RwC7ZVVrvjohVr/86V0J7xxG8hiNJvoHuYyw9f5OzyQLDsZxU e0I8pmeUrX+oqu6AbnCP/ElyVnlf0o3dgh4g+rEblBC4ykwWtC5dQvmh3QF4yQXmD31VEFJQnmC9 BTLBfsgEYm8qxjjtTYm3xw+qt9OE3pQeQSAepHl+a23lobKKn8742cqbjiV423buy6XLG5tXNiz3 HqmqzMp+qanHYt3a9vc6l1N24P3Mxx+fq6q3pKaPfyxpqeutT93L8KOPpvxHTpwyO6vZOWcW++iU 6uqff+D1RkUP7gZIXzqkBcVDWlSo/dC4pIS2oYxvUI868/hxJiWkBw38YnCDau7+/h+gk2w4NR0C nT0i9jLEu8CDsi/hGXh6D7l9yLVy3Pvc7zjw2jHSr8nVO1k2upc4bf8uzkYz2Aiq89G8LQnj5y/Y 6m4WzNn4dCbofzv3P40ru+fP/x1Q/GV/j2wi7Ijhrc+f7zMi6WYFeUv1xsXS0jPvlpVefP4F7jb3 n+0vYNnVvvq79qUYL7XflbT1LeKu79i5cweOFyo6qXDxpHdWZCgiiaLEIk4URQ0NZT5ydOxYBVCS nuHeZsbUP/tsF/fKex988B6u2rZxvWfZ6jVt3H9v3rJlM45aUmy4ircdCjQbJiVh/NEl7MTOjy5N mJDzh8rUqXv2cB9zl/fswdFjeI+Tjxe0p4CqRDxSSUN9Cl6Nm/GU97nmi1wzxHtfuOQeaG18H5Ki XpIj+vvAW2/D3nA4fVO1w2bpNdyJ914L3L0IXv0SY+v7FjLcWeK7HeC7PpBzGt9ZkV4lXuwdMsWT lKD6aUPeF5EMJpnzvGEB3v0i92VVjdVusJpdp61mvHDxwaNv7ygqXGDYbays8vqslvJbUL5wTp4k njXVPP9Z40qMoyMTzqQ9Og7Pn9/+DCS/Qz+dscw3exY0GMfGR44mBXy1sQT8FyKT+YpGZhgfmwo+ PpkJQojSMGWQj7snvCtMePBdYRRWJoZaUHh1+MArwzk44rvP4kaPGc2/MMQ/5V8h1tof8uqw9z+4 z75hMIPxJ5exibw6pO8S7x8/AdzQHp1mXpKr+cxLO/UrJHlB7g1cEzIX7r/DPSGN5o7Q3BOjyJBG 3/8jd6S9HfLNsv6esIlUJhaloqdQzuBei6aSkN6KNh0UQD5wDlbGk8gjPisek0nikX1cmpqWllpa nJaamlb8ciX0Dh2vLFqMqxbvu3+vBFp2WCtNS4WDcbGkpauvoktyqK/x5arKxVWdXQsXQ6O8DWvy n9mgmQ9n4PVazVrsdL1zyuFyOU6943YyJqhk6zdq8vM1G9fNn9/8/d/kI2D9NFRol/PUSZeT5KV2 8LxdQg856J0ckSqYRyXCmZXyHhJ/zAHaGbXSLgkPK9DqtOfsS0fOqChz3NiwfnPrDa5vc+vhn+Gf wIJkJrRHryyuwiDdK9AgMY3HldFRLS3cN6UpyZtb//pF21bhbSHYEA7zOPj+F3oIBZ+7mPzAB1fw Nfzp5cBZyFex0q96xdogW8KfZMjbFRKsmB4cO7E08LhkHPePQDo5PrYyDYG8vh7m94FU2HVNclh2 nccvFFbJKWb8eS6PyzvPQOAHruA2rp6ZgoTOowzqWhjtVIgfKV7Hh+/e5WCy/fu+dgJzlvYW0XyE KEgOz2DcXNk338ij733eLpe2k/eu3N6wZbL9oG8LXwdEXYfWAdrOCHXgKcHBxPehgl/Fiq//Y4U9 iWK3L5iKvpGBpCtjenNzVjfl5uRpGlfm5DGKWVpd7WtLHA7Hz2t1upnt24z68exc+47dv1jlWVbd WVqOZz7tsm9p7Vy3elVdxertO3effPVg89qsbAx1bW33v5++8qu3mvInJu7bx33JPNa+wADngQXt bUY9nBg0BRMS8OpV586uWYXjE7QbAmzMMvcvl1RVFq3PVePxirm2gz/77b62rfa6p57GSZMXuGvS MvC8uWtWHXr1128dOri6OTurtLSrxudfyd3b/SIxCzmND7wTwPx7M/i37hr24fprHMuga9wirvxT JkZIQ+l995imwEbJE+DdOIO4OM1aEP/xNP4jJUoJzrh48WL0/hgOil5gGbcXW+nfguD6Qp6urRr1 07+TP3oN/UA1fCLsENgXE48RPrAnzMkBsYjl/TX9NWGHgn9VEj966YfIJu3p75WNQSeld9Aypg3q ihb5ZI1oNMwdlShRpiwW7YL56/DbIr2NmqS30DJJPjrJTEfvStNRGdnLfIxSwi6ik/I2VCLdj07K ooX1ycgN42VMD7KQOekpNEtqQ8vkUnReegUueAbcnQQG8N+QtcPcS+i8bBfwEAvzsagNLgtc65hF 6Lx8IqythisWHZaNROcl49HrcB2Q9aHzzBvoLlwIcM6UxqOj5GKm919n0tH70nrYE41aCJ2wr1A2 s6h/l+w6ekOejnzy20Czp78PcHZIjqL3ifyAp1OK+u+EvUT5aqf6mAP0j0Fk8jTPghVaZE1oliSD 2BK6iieRHrXD9yK6jUfiNKjejfhNzDEZzCLGxWxkjjIfS6IlqZL5khbJDsktKSudIq2TtknPSK/L 5LJxskmyJtkLso9kPfJ/ky+U/1b+WdjksKfDLGH/HnYq7JOwv4fHhqeEzw3XhbvDt4QfDH8v/HL4 zWGpwxzDtg47OOxSxPCIiRFzI7ZFHIy4M5wZPmr46uEXh/9l+P1HIh9RPpLxyIeP3BnBCH9X1CMr 6VRD/soY+hmLRwbnZwRhMIqCJyz8TVKGqoSxJGReGjKWQWdiEcZyFIsKhHEY5PLXhHE4GhnuEMbD 0aPDNgjjEcOikAcwYylEBvIP2yuMMUqIGCWMGRQRUS6MJSHz0pCxDD0aYRbGcpQckSGMw1B1xN+F cTj6yTifMB6Opv7kFWE8YkxCRFOW29PotdfW+dknzRPZtKlT09maRpb8xdbvtZqcSazGZU5mVQ4H qydQPlZv9Vm9y62W5CAMW2L1mliDyeULTpEZMjFF73aaXHqrw2ryWdnU5NSpP4reiIiHERwRMYSk 3ceaWL/XZLE6Td6lrNv2IJ4REUVWr9Pu89ndLgJfZ/VagV6t1+TyWy1JrM1rtZKN5jqTt9aaxPrd rMnVyHqsXh9scNf4TXaX3VULdMzAOIH011lZm9sFjJnMZrfTA+AEwF8H2B12s9UFgj4Zl0Mg4iYC Mgtr8vncZrsJ6LEWt7neaXX5TX7Cj83usPrYJwlGuoE1uG3+BpPXGjeRcuK1erxuS73ZStFY7CCa vabeb6U8DNqQxNpdZke9hXDSYPfXuev9wIzTLhAi8F5em4C23gfwRJwk1mmlUnvqaxx2X11SCI0k QjPF7WV9VjAFQNuBVUH8IaQJc4DWQxTtF1RHCTXUuZ0PbiBmsNV7XUDQSjda3KzPncT66muWWM1+ MsPr2OFwNxCBzG6XxU7k8M0gBjXCoqnGvdxKZeB9ibIQdASX2w+G8PGzxC6eAR/g11hfnQnEqrEK egNG7C7WNEhStws8w8s63V7rQwVn/Y0eq80EhJJFtgavO02NhILTbbHb7MTZTA4/uB8MAK3JYqHS 8+oD4h6TFzird5i8lJTF6rPXuigjtY5GT52PbCJeajIDEh/ZIXLkG0qJ9zoLrzST4+EIhD0iHwPY gD2Xo5G1D3J1EMdrJf8jhMKSgY+okthGDBEr+J2VZ77B7bX42LhgNMYR2uICG0eCN05QGlhHK0RN jRXiieCtBzsQEZa77UHWrCv8EDesyeOBIDPVOKxkgZcecA8xTJ3Jz9aZfIDR6hqsFSA34OMWtt5l EViOG5xb4ngZf9iyPreDRDc1HTGUiXWQLAIxIwJ6TOalploQDeLR5Q7mkB/vWoNIQeICJq0OG89W nprNKdQZWUNhjrFUpVezGgNbpC8s0WSrs9k4lQGe45LYUo0xr7DYyAKEXqUzlrOFOaxKV87O1+iy k1h1WZFebTCwhXpWU1Ck1ahhTqPL0hZna3S57DzYpys0slpNgcYISI2FdKuASqM2EGQFan1WHjyq 5mm0GmN5EpujMeoIzhxAqmKLVHqjJqtYq9KzRcX6okKDGnBkA1qdRpejByrqAjUIAYiyCovK9Zrc PGMSbDLCZBJr1Kuy1QUq/fwkwmEhiKxnKUgycAk4WHUJ2WzIU2m17DyN0WDUq1UFBJZoJ1dXWEB0 VKzLVhk1hTp2nhpEUc3TqnneQJQsrUpTkMRmqwpUuWrDABECJogzoA6yIVetU+tV2iTWUKTO0pAB 6FGjV2cZKSToHjShpexmFeoM6gXFMAFwIgkwSJ6akgABVPAvi3JGxdeBuASPsVBvDLJSqjGok1iV XmMgLOToC4FdYk/YQWQsBn0S4+kEfomNyNyD3gFQZLcgYLZapQWEBsLGA7DUv9QrzFaPn/i3EOR8 kqQJlc+iSdRz+WQAbpzrgvDl5+gQfBrii1YgPssNhBgpzklCEiZpBDwcqhKfhC3LrZAJfSSlQIy4 SVJpsPtovEM5dLqF+uczOYAY7ApCQc40OWCbL8jm4KASC6PHa4ctDV67H1IKa6qHWa99pVCSvULJ GioBoTKUf6/V54GKZV9udTQmA6yX1DXKid1lc3udguhUfWb/DDGX+tlaitwCgru9tcl1fr9nRkpK Q0NDco1IIRlSIcpCbmgSG5EX2VEtqkN+xEIDbkYT4TcNmsypKB1GNQDBonkA40c+uLzQ+pqQEyXB rAa5AD4ZRirkgC8LjbGIy0efrPBrhT3L4W4ByAfxsKiEQphgZIC7C1YfhBJhRIgpgNsN8+SJUHFQ OEKLvMRJhmvq/0P5RqCIHy0hgf1hKe10Jxn56YwFVogkXrQU5tzI9qP4IVcRxemkGH1wd8O6iL+O rlkF+WopJRfgI1wSXDa6ag1SNMMOwkMtzCVR3tyUSxfd76HYfAIFN2D1w5odnshVK8hjFjQu4vRT LggtN6XNy22mcE6A5LGLGAg0z7sDfs2w0yVY9EkUh3KCOOKoBcleC/31Ub7MsMckyMfCRWbqgYqV 7iIron5sMHJQuxHMIo8DFIgfEv79qIFqxEopDuiEzHjg7gYq9ZTPAW4sVAI/9bkaWPXTVZHGP6eQ RO1GrOuAXZagThqoH9QBdD3dRzTjpHOhEon4vYN8k+e2nuowKcQ6ZOyk9hRt7QGoGorbB7uT/okc SUE5UwCTF558NPIcQdx2QauDrf/DUoua47n1BD3aP8TrBiRqoPpw/igKYjTYQAYv9VYf3TNA0ULv hEYS/SWaWAIQZoqPhwn1YyKvm9qFt5CZ0rZQju0CpzOCEWoUdpoAq5vmiAE7hOalAS08mBFcAO8X IsI3CFaMlwGtheaB0H0sldskWKtG0MyAv/EasdN9ph+wKcHM5wwv9SK3oOUfa3EC00j5tdFMQHAn P6CtH9pP9NIYlMFJo9BOY1rMbIR/v5D9+BmeW6JXS4jtQ72Pl9xDqfA6qwcsJrpPlMpCuSU2c4Vo pBbgiER1wpw3JJeaqBfxPizSGKoj37+UKTTXWQZ5mona6cdzMJjOUH08jLckweYOus/+A1ndK2Qg K+XLOQivOOMLeqUYN0OriFXId9ZBmm+gUlno/riH1Ma4oNxDdxB4sfLGDfE0Pna0Q2pNDY19dwi/ 9UI8iFZYDqv2h2jNilZQXbuEiPbAl69kJppdrcEdobbn+f7hiKmj2Z6lvz6BRyv1pn/uK7x0D8vj ZLWeQg3W8sM0y4ZoL9SO/5eY9dEsKtbugagTI4p0Eo5gL+IVdgzG6KGevRTutYLV+Proovod2of8 /8ha/1yqGiFW/EJ9tA3SVh5SU1qFSAdPhFYhPBlRKXSYerqmgTkWejs9rJTAUzbMZlP7qOgKWY+j kVkKY4KxEBVTXDwOPdwJ7nKYIbhZ+kye5gO8DnCRvWpURmmoAZuBQuop7gKY1cKvWoAjO7Jgphie yTgXke6Up6eDXUYaQ2Qf4YXn1AjzA1QHc6WhFEXOCuBJD/jzhFUV4NZQfIT/JKopMtYF+cwROFVR HRHMBGcWcKSlT2S2GH6LAM5A9amiMvPc6qgMObDOy6KmHPCW4DnKgt8ioE0gcoEvI+WCUDIKkElU QiJPNt1PqM6nszxnhYKVyXgAS7KgS54Pov+SIGUDlV8LX5bKb4QZI7WNCvCLeEXfyaUYCoJ+VEzl U1E9FFIK8+ga0SLRpzYIqQ+xShbVF7Eb4TybUlJRjRgeKomIbbB1HuYdIoVcKp+aakpLoQ2gRzXA a4IzvD9qqKxZgm55nLzf8z6hDdFuFpWRWHYBUFULPqWiuhssBR8hhP8BKXgLqIR7VojOBqyvE6yb FbR1IfWyB7VSSmNRTaFU1NaGoBZyaPwWCJwXh3iYaMdiwT8Lg5wN1q8YRyLcj8kdPC6R9mALZlN/ 0gocGoLa+Nd4B/KXGmqcmZ5//MH8PbiSh3aSAx1qaC+aFJJzQzsDPhvnUljnELiBWT5P8/Vr4AwU 2ss9rIqJJ2e+xx/ohMVuhM/h/FkptBO20J6d7wl9wS6FryPuYKfSQFcH6jt/OnRSiNDzn4/S5SWr F3YMxcX3mSbaORBqvodo84cq1dATo4fWfp5KAx37hS6FyFcvwJL5lUNOyd4hp6x/ZQNRln+lfy+1 t0c4Y9mphkl/mSzg9SLxvDagE6IBG11zDrH6gPcRbDPQ0L6U6KA2hHOLYHE37S+S6fnLD9zMgFNt CmiIfJPBH4bKkCx0hf8L1gkT5GVuZHN0cmVhbQplbmRvYmoKMTE2MCAwIG9iago4NTg3CmVuZG9i agoxMTU4IDAgb2JqCjw8IC9UeXBlIC9Gb250Ci9TdWJ0eXBlIC9DSURGb250VHlwZTIKL0Jhc2VG b250IC9CaXRzdHJlYW1WZXJhU2Fucy1Sb21hbgovQ0lEU3lzdGVtSW5mbyA8PCAvUmVnaXN0cnkg KEFkb2JlKSAvT3JkZXJpbmcgKElkZW50aXR5KSAvU3VwcGxlbWVudCAwID4+Ci9Gb250RGVzY3Jp cHRvciAxMTU2IDAgUgovQ0lEVG9HSURNYXAgL0lkZW50aXR5Ci9XIFswIFs1OTUgNjA2IDYyOSA2 MTAgMzE1IDc4MSA2NzkgNjI5IDM4OSA2MzEgMzE1IDYzMSA2MDggNjA3IDQwOCAyNzYgNTIxIDYy OSAzNDkgOTY2IDgxMSA1NzQgNjMwIDI3NiA1MTcgNjMwIDM1OCA2MzAgNTg3IDU0NSA3NDYgNTk4 IDU4NyAzMTUgNjMwIDYzMSA2ODkgNTcxIDY5MyA2MzEgNjMxIDYzMSA2MzEgMjkzIDc2NCA2ODEg NjMxIDYyNyAzODcgMzg3IDc0MiAzMzQgMzM0IDU4NyA1MTQgNTE0IDI3NiAyNzMgNTUzIDYzMCA2 MzAgOTgxIDI5MyA3MjYgNzY5IDg1NiA2MDYgNjMxIDQ1NiA3ODEgMzM0IDQ5NiA5NDMgNjMxIDY3 OSA2NTEgODMxIDM4NyAzODcgOTkyIDY4MCAzOTggXQpdCj4+CmVuZG9iagoxMTU5IDAgb2JqCjw8 IC9MZW5ndGggOTMxID4+CnN0cmVhbQovQ0lESW5pdCAvUHJvY1NldCBmaW5kcmVzb3VyY2UgYmVn aW4KMTIgZGljdCBiZWdpbgpiZWdpbmNtYXAKL0NJRFN5c3RlbUluZm8gPDwgL1JlZ2lzdHJ5IChB ZG9iZSkgL09yZGVyaW5nIChVQ1MpIC9TdXBwbGVtZW50IDAgPj4gZGVmCi9DTWFwTmFtZSAvQWRv YmUtSWRlbnRpdHktVUNTIGRlZgovQ01hcFR5cGUgMiBkZWYKMSBiZWdpbmNvZGVzcGFjZXJhbmdl CjwwMDAwPiA8RkZGRj4KZW5kY29kZXNwYWNlcmFuZ2UKMiBiZWdpbmJmcmFuZ2UKPDAwMDA+IDww MDAwPiA8MDAwMD4KPDAwMDE+IDwwMDUxPiBbPDAwNTQ+IDwwMDY4PiA8MDA2NT4gPDAwMjA+IDww MDRGPiA8MDA0MT4gPDAwNzU+IDwwMDc0PiA8MDAzMj4gPDAwMkU+IDwwMDMwPiA8MDA2MT4gPDAw NkY+IDwwMDcyPiA8MDA2OT4gPDAwN0E+IDwwMDZFPiA8MDA2Nj4gPDAwNkQ+IDwwMDc3PiA8MDA2 Qj4gPDAwNjI+IDwwMDZDPiA8MDA3Mz4gPDAwNjQ+IDwwMDJEPiA8MDA3MD4gPDAwNzk+IDwwMDYz PiA8MDA0OD4gPDAwNTA+IDwwMDc2PiA8MDAyQz4gPDAwNjc+IDwwMDMxPiA8MDA1Mj4gPDAwNDY+ IDwwMDQzPiA8MDAzNT4gPDAwMzg+IDwwMDM0PiA8MDAzOT4gPDAwNDk+IDwwMDQ0PiA8MDA0Mj4g PDAwMzc+IDwwMDQ1PiA8MDAyOD4gPDAwMjk+IDwwMDRFPiA8MDAzQT4gPDAwMkY+IDwwMDc4PiA8 MjAxQz4gPDIwMUQ+IDwwMDZBPiA8MDAyNz4gPDAwNEM+IDwwMDUzPiA8MDA3MT4gPDAwNTc+IDww MDRBPiA8MDA1NT4gPDAwNDc+IDwwMDREPiA8MDA1OT4gPDAwMzM+IDwwMDIyPiA8MDA1MT4gPDAw M0I+IDwwMDVGPiA8MDAyNT4gPDAwMzY+IDwwMDU2PiA8MDA0Qj4gPDAwNUU+IDwwMDVCPiA8MDA1 RD4gPDAwNDA+IDwwMDU4PiA8MDAyMT4gXQplbmRiZnJhbmdlCmVuZGNtYXAKQ01hcE5hbWUgY3Vy cmVudGRpY3QgL0NNYXAgZGVmaW5lcmVzb3VyY2UgcG9wCmVuZAplbmQKZW5kc3RyZWFtCmVuZG9i agoxMCAwIG9iago8PCAvVHlwZSAvRm9udAovU3VidHlwZSAvVHlwZTAKL0Jhc2VGb250IC9CaXRz dHJlYW1WZXJhU2Fucy1Sb21hbgovRW5jb2RpbmcgL0lkZW50aXR5LUgKL0Rlc2NlbmRhbnRGb250 cyBbMTE1OCAwIFJdCi9Ub1VuaWNvZGUgMTE1OSAwIFI+PgplbmRvYmoKMiAwIG9iago8PAovVHlw ZSAvUGFnZXMKL0tpZHMgClsKNSAwIFIKMzMgMCBSCjEwNiAwIFIKMTQ4IDAgUgoxNjMgMCBSCjE3 NyAwIFIKMTk0IDAgUgoyMDUgMCBSCjIyNSAwIFIKMjQyIDAgUgoyNTkgMCBSCjI3NiAwIFIKMjk4 IDAgUgozMTYgMCBSCjMzNSAwIFIKMzUwIDAgUgozNjAgMCBSCjM3MiAwIFIKMzgyIDAgUgozOTgg MCBSCjQwNyAwIFIKNDIxIDAgUgo0MzMgMCBSCjQ0MyAwIFIKNDU4IDAgUgo0NzMgMCBSCjQ4OCAw IFIKNTA5IDAgUgo1MjYgMCBSCjUzNCAwIFIKNTQ5IDAgUgo1NjYgMCBSCjU4OCAwIFIKNjA3IDAg Ugo2MjAgMCBSCjYzOCAwIFIKNjUyIDAgUgo2NzEgMCBSCjY4NCAwIFIKNzA1IDAgUgo3MjAgMCBS CjcyNSAwIFIKNzQzIDAgUgo4MjIgMCBSCjg3MyAwIFIKOTE3IDAgUgo5NTkgMCBSCjk4MyAwIFIK XQovQ291bnQgNDgKL1Byb2NTZXQgWy9QREYgL1RleHQgL0ltYWdlQiAvSW1hZ2VDXQo+PgplbmRv YmoKeHJlZgowIDExNjEKMDAwMDAwMDAwMCA2NTUzNSBmIAowMDAwMDAwMDA5IDAwMDAwIG4gCjAw MDA0MjA4MTYgMDAwMDAgbiAKMDAwMDAwMDIwNyAwMDAwMCBuIAowMDAwMDAwMzAyIDAwMDAwIG4g CjAwMDAwMDMyODUgMDAwMDAgbiAKMDAwMDQwMjMyMiAwMDAwMCBuIAowMDAwNDA5OTk3IDAwMDAw IG4gCjAwMDAzODAzMTUgMDAwMDAgbiAKMDAwMDM3NzExMSAwMDAwMCBuIAowMDAwNDIwNjYyIDAw MDAwIG4gCjAwMDAwMDAzMzkgMDAwMDAgbiAKMDAwMDAwMDM5MSAwMDAwMCBuIAowMDAwMDAwNDQz IDAwMDAwIG4gCjAwMDAwMDA0OTUgMDAwMDAgbiAKMDAwMDAwMDU0NyAwMDAwMCBuIAowMDAwMDAw NTk5IDAwMDAwIG4gCjAwMDAwMDA2NTEgMDAwMDAgbiAKMDAwMDAwMDg2OSAwMDAwMCBuIAowMDAw MDAxMDkxIDAwMDAwIG4gCjAwMDAwMDEzMTMgMDAwMDAgbiAKMDAwMDAwMTUzNSAwMDAwMCBuIAow MDAwMDAxNzU3IDAwMDAwIG4gCjAwMDAwMDE5NzkgMDAwMDAgbiAKMDAwMDAwMjIwMSAwMDAwMCBu IAowMDAwMDAyNDIzIDAwMDAwIG4gCjAwMDAwMDI2NDUgMDAwMDAgbiAKMDAwMDAwMjg2NyAwMDAw MCBuIAowMDAwMDAzMDkwIDAwMDAwIG4gCjAwMDAwMDM3MTggMDAwMDAgbiAKMDAwMDAwNzU1MSAw MDAwMCBuIAowMDAwMDAzNDA2IDAwMDAwIG4gCjAwMDAwMDM2MTQgMDAwMDAgbiAKMDAwMDAyMjk4 MCAwMDAwMCBuIAowMDAwMDA3NTcyIDAwMDAwIG4gCjAwMDAwMDc3OTAgMDAwMDAgbiAKMDAwMDAw ODAxMyAwMDAwMCBuIAowMDAwMDA4MjM2IDAwMDAwIG4gCjAwMDAwMDg0NTkgMDAwMDAgbiAKMDAw MDAwODY4MiAwMDAwMCBuIAowMDAwMDA4OTExIDAwMDAwIG4gCjAwMDAwMDkxMzggMDAwMDAgbiAK MDAwMDAwOTM3NiAwMDAwMCBuIAowMDAwMDA5NjA4IDAwMDAwIG4gCjAwMDAwMDk4MzEgMDAwMDAg biAKMDAwMDAxMDA1NCAwMDAwMCBuIAowMDAwMDEwMjc3IDAwMDAwIG4gCjAwMDAwMTA1MDAgMDAw MDAgbiAKMDAwMDAxMDczMCAwMDAwMCBuIAowMDAwMDEwOTU5IDAwMDAwIG4gCjAwMDAwMTExODIg MDAwMDAgbiAKMDAwMDAxMTQyMCAwMDAwMCBuIAowMDAwMDExNjQwIDAwMDAwIG4gCjAwMDAwMTE4 NjMgMDAwMDAgbiAKMDAwMDAxMjA5MCAwMDAwMCBuIAowMDAwMDEyMzIzIDAwMDAwIG4gCjAwMDAw MTI1NTcgMDAwMDAgbiAKMDAwMDAxMjc4MyAwMDAwMCBuIAowMDAwMDEzMDA2IDAwMDAwIG4gCjAw MDAwMTMyMzcgMDAwMDAgbiAKMDAwMDAxMzQ3NCAwMDAwMCBuIAowMDAwMDEzNzEyIDAwMDAwIG4g CjAwMDAwMTM5NDMgMDAwMDAgbiAKMDAwMDAxNDE2NiAwMDAwMCBuIAowMDAwMDE0NDAxIDAwMDAw IG4gCjAwMDAwMTQ2MjQgMDAwMDAgbiAKMDAwMDAxNDg1MyAwMDAwMCBuIAowMDAwMDE1MDc2IDAw MDAwIG4gCjAwMDAwMTUzMDMgMDAwMDAgbiAKMDAwMDAxNTUyNiAwMDAwMCBuIAowMDAwMDE1NzUy IDAwMDAwIG4gCjAwMDAwMTU5ODAgMDAwMDAgbiAKMDAwMDAxNjIxMSAwMDAwMCBuIAowMDAwMDE2 NDQwIDAwMDAwIG4gCjAwMDAwMTY2NzAgMDAwMDAgbiAKMDAwMDAxNjkwMiAwMDAwMCBuIAowMDAw MDE3MTMwIDAwMDAwIG4gCjAwMDAwMTczNjIgMDAwMDAgbiAKMDAwMDAxNzU4NyAwMDAwMCBuIAow MDAwMDE3ODEzIDAwMDAwIG4gCjAwMDAwMTgwNDUgMDAwMDAgbiAKMDAwMDAxODI2OCAwMDAwMCBu IAowMDAwMDE4NTA0IDAwMDAwIG4gCjAwMDAwMTg3MzEgMDAwMDAgbiAKMDAwMDAxODk1NCAwMDAw MCBuIAowMDAwMDE5MTc3IDAwMDAwIG4gCjAwMDAwMTk0MDAgMDAwMDAgbiAKMDAwMDAxOTYyMyAw MDAwMCBuIAowMDAwMDE5ODQ2IDAwMDAwIG4gCjAwMDAwMjAwNjkgMDAwMDAgbiAKMDAwMDAyMDI5 MiAwMDAwMCBuIAowMDAwMDIwNTE1IDAwMDAwIG4gCjAwMDAwMjA3MzggMDAwMDAgbiAKMDAwMDAy MDk2MSAwMDAwMCBuIAowMDAwMDIxMTg0IDAwMDAwIG4gCjAwMDAwMjE0MDcgMDAwMDAgbiAKMDAw MDAyMTYzMCAwMDAwMCBuIAowMDAwMDIxODQ5IDAwMDAwIG4gCjAwMDAwMjIwNzIgMDAwMDAgbiAK MDAwMDAyMjI5NSAwMDAwMCBuIAowMDAwMDIyNTI1IDAwMDAwIG4gCjAwMDAwMjI3NDkgMDAwMDAg biAKMDAwMDAyMzc3MSAwMDAwMCBuIAowMDAwMDI3MTM2IDAwMDAwIG4gCjAwMDAwMjMxMDUgMDAw MDAgbiAKMDAwMDAyMzI3MiAwMDAwMCBuIAowMDAwMDM1MTU1IDAwMDAwIG4gCjAwMDAwMjcxNTgg MDAwMDAgbiAKMDAwMDAyNzIxMSAwMDAwMCBuIAowMDAwMDI3MjY0IDAwMDAwIG4gCjAwMDAwMjc0 ODggMDAwMDAgbiAKMDAwMDAyNzcyNSAwMDAwMCBuIAowMDAwMDI3OTQ5IDAwMDAwIG4gCjAwMDAw MjgxNzMgMDAwMDAgbiAKMDAwMDAyODQxNSAwMDAwMCBuIAowMDAwMDI4NjM5IDAwMDAwIG4gCjAw MDAwMjg4NTYgMDAwMDAgbiAKMDAwMDAyOTA4OCAwMDAwMCBuIAowMDAwMDI5MzEyIDAwMDAwIG4g CjAwMDAwMjk1NDMgMDAwMDAgbiAKMDAwMDAyOTc3NCAwMDAwMCBuIAowMDAwMDMwMDA1IDAwMDAw IG4gCjAwMDAwMzAyMjkgMDAwMDAgbiAKMDAwMDAzMDQ1MyAwMDAwMCBuIAowMDAwMDMwNjc3IDAw MDAwIG4gCjAwMDAwMzA5MDEgMDAwMDAgbiAKMDAwMDAzMTEyNSAwMDAwMCBuIAowMDAwMDMxMzQ5 IDAwMDAwIG4gCjAwMDAwMzE1NzMgMDAwMDAgbiAKMDAwMDAzMTc5NyAwMDAwMCBuIAowMDAwMDMy MDIxIDAwMDAwIG4gCjAwMDAwMzIyNDUgMDAwMDAgbiAKMDAwMDAzMjQ2OSAwMDAwMCBuIAowMDAw MDMyNjkzIDAwMDAwIG4gCjAwMDAwMzI5MTcgMDAwMDAgbiAKMDAwMDAzMzE0MSAwMDAwMCBuIAow MDAwMDMzMzY1IDAwMDAwIG4gCjAwMDAwMzM1ODkgMDAwMDAgbiAKMDAwMDAzMzgxMyAwMDAwMCBu IAowMDAwMDM0MDM3IDAwMDAwIG4gCjAwMDAwMzQyNjEgMDAwMDAgbiAKMDAwMDAzNDQ4NSAwMDAw MCBuIAowMDAwMDM0NzA5IDAwMDAwIG4gCjAwMDAwMzQ5MzYgMDAwMDAgbiAKMDAwMDAzNTc3MSAw MDAwMCBuIAowMDAwMDM5OTk4IDAwMDAwIG4gCjAwMDAwMzUyODEgMDAwMDAgbiAKMDAwMDAzNTQ3 MCAwMDAwMCBuIAowMDAwMDQxMTY5IDAwMDAwIG4gCjAwMDAzOTE5MDUgMDAwMDAgbiAKMDAwMDA0 MDAyMCAwMDAwMCBuIAowMDAwMDQwMDczIDAwMDAwIG4gCjAwMDAwNDAxMjYgMDAwMDAgbiAKMDAw MDA0MDE3OSAwMDAwMCBuIAowMDAwMDQwMjMyIDAwMDAwIG4gCjAwMDAwNDAyODUgMDAwMDAgbiAK MDAwMDA0MDUwOCAwMDAwMCBuIAowMDAwMDQwNzMxIDAwMDAwIG4gCjAwMDAwNDA5NTAgMDAwMDAg biAKMDAwMDA0MTU1MSAwMDAwMCBuIAowMDAwMDQ1MjIyIDAwMDAwIG4gCjAwMDAwNDEyOTUgMDAw MDAgbiAKMDAwMDA0MTQ5OCAwMDAwMCBuIAowMDAwMDQ2NTYyIDAwMDAwIG4gCjAwMDAwNDUyNDQg MDAwMDAgbiAKMDAwMDA0NTI5NyAwMDAwMCBuIAowMDAwMDQ1MzUwIDAwMDAwIG4gCjAwMDAwNDU0 MDMgMDAwMDAgbiAKMDAwMDA0NTQ1NiAwMDAwMCBuIAowMDAwMDQ1NjgyIDAwMDAwIG4gCjAwMDAw NDU5MDggMDAwMDAgbiAKMDAwMDA0NjEyMCAwMDAwMCBuIAowMDAwMDQ2MzM5IDAwMDAwIG4gCjAw MDAwNDY5NTIgMDAwMDAgbiAKMDAwMDA1MDIxMyAwMDAwMCBuIAowMDAwMDQ2Njg4IDAwMDAwIG4g CjAwMDAwNDY4OTEgMDAwMDAgbiAKMDAwMDA1MTUzNSAwMDAwMCBuIAowMDAwMDUwMjM1IDAwMDAw IG4gCjAwMDAwNTAyODggMDAwMDAgbiAKMDAwMDA1MDM0MSAwMDAwMCBuIAowMDAwMDUwMzk0IDAw MDAwIG4gCjAwMDAwNTA0NDcgMDAwMDAgbiAKMDAwMDA1MDUwMCAwMDAwMCBuIAowMDAwMDUwNTUz IDAwMDAwIG4gCjAwMDAwNTA2MDYgMDAwMDAgbiAKMDAwMDA1MDY1OSAwMDAwMCBuIAowMDAwMDUw ODc4IDAwMDAwIG4gCjAwMDAwNTEwOTcgMDAwMDAgbiAKMDAwMDA1MTMxNiAwMDAwMCBuIAowMDAw MDUxOTAzIDAwMDAwIG4gCjAwMDAwNTU5MjcgMDAwMDAgbiAKMDAwMDA1MTY2MSAwMDAwMCBuIAow MDAwMDUxODUwIDAwMDAwIG4gCjAwMDAwNTY3NzkgMDAwMDAgbiAKMDAwMDA1NTk0OSAwMDAwMCBu IAowMDAwMDU2MDAyIDAwMDAwIG4gCjAwMDAwNTYwNTUgMDAwMDAgbiAKMDAwMDA1NjEwOCAwMDAw MCBuIAowMDAwMDU2MzI3IDAwMDAwIG4gCjAwMDAwNTY1NTMgMDAwMDAgbiAKMDAwMDA1NzE1MyAw MDAwMCBuIAowMDAwMDYwNjg5IDAwMDAwIG4gCjAwMDAwNTY5MDUgMDAwMDAgbiAKMDAwMDA1NzEw OCAwMDAwMCBuIAowMDAwMDYyNjkwIDAwMDAwIG4gCjAwMDAwNjA3MTEgMDAwMDAgbiAKMDAwMDA2 MDc2NCAwMDAwMCBuIAowMDAwMDYwODE3IDAwMDAwIG4gCjAwMDAwNjA4NzAgMDAwMDAgbiAKMDAw MDA2MDkyMyAwMDAwMCBuIAowMDAwMDYwOTc2IDAwMDAwIG4gCjAwMDAwNjEwMjkgMDAwMDAgbiAK MDAwMDA2MTA4MiAwMDAwMCBuIAowMDAwMDYxMTM1IDAwMDAwIG4gCjAwMDAwNjEzNjggMDAwMDAg biAKMDAwMDA2MTU4NyAwMDAwMCBuIAowMDAwMDYxODEwIDAwMDAwIG4gCjAwMDAwNjIwMzMgMDAw MDAgbiAKMDAwMDA2MjI1MiAwMDAwMCBuIAowMDAwMDYyNDcxIDAwMDAwIG4gCjAwMDAwNjMwODIg MDAwMDAgbiAKMDAwMDA2Njk1MyAwMDAwMCBuIAowMDAwMDYyODE2IDAwMDAwIG4gCjAwMDAwNjMw MDUgMDAwMDAgbiAKMDAwMDA2ODk3MCAwMDAwMCBuIAowMDAwMDY2OTc1IDAwMDAwIG4gCjAwMDAw NjcwMjggMDAwMDAgbiAKMDAwMDA2NzA4MSAwMDAwMCBuIAowMDAwMDY3MTM0IDAwMDAwIG4gCjAw MDAwNjcxODcgMDAwMDAgbiAKMDAwMDA2NzQxMCAwMDAwMCBuIAowMDAwMDY3NjI2IDAwMDAwIG4g CjAwMDAwNjc4NDkgMDAwMDAgbiAKMDAwMDA2ODA3MiAwMDAwMCBuIAowMDAwMDY4MjkxIDAwMDAw IG4gCjAwMDAwNjg1MjEgMDAwMDAgbiAKMDAwMDA2ODc1MSAwMDAwMCBuIAowMDAwMDY5MzcwIDAw MDAwIG4gCjAwMDAwNzM1NzUgMDAwMDAgbiAKMDAwMDA2OTA5NiAwMDAwMCBuIAowMDAwMDY5Mjg1 IDAwMDAwIG4gCjAwMDAwNzUwMzkgMDAwMDAgbiAKMDAwMDM3MDA5NCAwMDAwMCBuIAowMDAwMDcz NTk3IDAwMDAwIG4gCjAwMDAwNzM2NTAgMDAwMDAgbiAKMDAwMDA3MzcwMyAwMDAwMCBuIAowMDAw MDczNzU2IDAwMDAwIG4gCjAwMDAwNzM4MDkgMDAwMDAgbiAKMDAwMDA3Mzg2MiAwMDAwMCBuIAow MDAwMDczOTE1IDAwMDAwIG4gCjAwMDAwNzQxMzQgMDAwMDAgbiAKMDAwMDA3NDM1MyAwMDAwMCBu IAowMDAwMDc0NTcyIDAwMDAwIG4gCjAwMDAwNzQ3OTUgMDAwMDAgbiAKMDAwMDA3NTQ0MyAwMDAw MCBuIAowMDAwMDc5NDI3IDAwMDAwIG4gCjAwMDAwNzUxNjUgMDAwMDAgbiAKMDAwMDA3NTM4MiAw MDAwMCBuIAowMDAwMDgxMTA4IDAwMDAwIG4gCjAwMDAwNzk0NDkgMDAwMDAgbiAKMDAwMDA3OTUw MyAwMDAwMCBuIAowMDAwMDc5NTU3IDAwMDAwIG4gCjAwMDAwNzk2MTEgMDAwMDAgbiAKMDAwMDA3 OTY2NSAwMDAwMCBuIAowMDAwMDc5NzE5IDAwMDAwIG4gCjAwMDAwNzk3NzMgMDAwMDAgbiAKMDAw MDA4MDAwOCAwMDAwMCBuIAowMDAwMDgwMjMyIDAwMDAwIG4gCjAwMDAwODA0NTEgMDAwMDAgbiAK MDAwMDA4MDY3MCAwMDAwMCBuIAowMDAwMDgwODg5IDAwMDAwIG4gCjAwMDAwODE1MDYgMDAwMDAg biAKMDAwMDA4NTA5NSAwMDAwMCBuIAowMDAwMDgxMjM0IDAwMDAwIG4gCjAwMDAwODE0MzcgMDAw MDAgbiAKMDAwMDA4Nzk1MiAwMDAwMCBuIAowMDAwMDg1MTE3IDAwMDAwIG4gCjAwMDAwODUxNzEg MDAwMDAgbiAKMDAwMDA4NTIyNSAwMDAwMCBuIAowMDAwMDg1Mjc5IDAwMDAwIG4gCjAwMDAwODUz MzMgMDAwMDAgbiAKMDAwMDA4NTM4NyAwMDAwMCBuIAowMDAwMDg1NDQxIDAwMDAwIG4gCjAwMDAw ODU2NjAgMDAwMDAgbiAKMDAwMDA4NTkwNCAwMDAwMCBuIAowMDAwMDg2MTI3IDAwMDAwIG4gCjAw MDAwODYzNDYgMDAwMDAgbiAKMDAwMDA4NjU2OSAwMDAwMCBuIAowMDAwMDg2Nzg4IDAwMDAwIG4g CjAwMDAwODcwMjIgMDAwMDAgbiAKMDAwMDA4NzI2MCAwMDAwMCBuIAowMDAwMDg3NDk3IDAwMDAw IG4gCjAwMDAwODc3MzMgMDAwMDAgbiAKMDAwMDA4ODQwNCAwMDAwMCBuIAowMDAwMDkyNTQ2IDAw MDAwIG4gCjAwMDAwODgwNzggMDAwMDAgbiAKMDAwMDA4ODI5NSAwMDAwMCBuIAowMDAwMDk0OTcz IDAwMDAwIG4gCjAwMDAwOTI1NjggMDAwMDAgbiAKMDAwMDA5MjYyMiAwMDAwMCBuIAowMDAwMDky Njc2IDAwMDAwIG4gCjAwMDAwOTI3MzAgMDAwMDAgbiAKMDAwMDA5Mjk1MyAwMDAwMCBuIAowMDAw MDkzMTk3IDAwMDAwIG4gCjAwMDAwOTM0MjAgMDAwMDAgbiAKMDAwMDA5MzYzOSAwMDAwMCBuIAow MDAwMDkzODU4IDAwMDAwIG4gCjAwMDAwOTQwNzcgMDAwMDAgbiAKMDAwMDA5NDMwOCAwMDAwMCBu IAowMDAwMDk0NTI3IDAwMDAwIG4gCjAwMDAwOTQ3NTAgMDAwMDAgbiAKMDAwMDA5NTQxNyAwMDAw MCBuIAowMDAwMDk5ODkxIDAwMDAwIG4gCjAwMDAwOTUwOTkgMDAwMDAgbiAKMDAwMDA5NTMxNiAw MDAwMCBuIAowMDAwMTAyMDM4IDAwMDAwIG4gCjAwMDAwOTk5MTMgMDAwMDAgbiAKMDAwMDA5OTk2 NyAwMDAwMCBuIAowMDAwMTAwMDIxIDAwMDAwIG4gCjAwMDAxMDAwNzUgMDAwMDAgbiAKMDAwMDEw MDEyOSAwMDAwMCBuIAowMDAwMTAwMTgzIDAwMDAwIG4gCjAwMDAxMDAyMzcgMDAwMDAgbiAKMDAw MDEwMDQ1NiAwMDAwMCBuIAowMDAwMTAwNjc1IDAwMDAwIG4gCjAwMDAxMDA4OTQgMDAwMDAgbiAK MDAwMDEwMTEzOCAwMDAwMCBuIAowMDAwMTAxMzYxIDAwMDAwIG4gCjAwMDAxMDE1ODAgMDAwMDAg biAKMDAwMDEwMTc5OSAwMDAwMCBuIAowMDAwMTAyNDY2IDAwMDAwIG4gCjAwMDAxMDY2MzggMDAw MDAgbiAKMDAwMDEwMjE2NCAwMDAwMCBuIAowMDAwMTAyMzgxIDAwMDAwIG4gCjAwMDAxMDc2OTUg MDAwMDAgbiAKMDAwMDEwNjY2MCAwMDAwMCBuIAowMDAwMTA2NzE0IDAwMDAwIG4gCjAwMDAxMDY3 NjggMDAwMDAgbiAKMDAwMDEwNjgyMiAwMDAwMCBuIAowMDAwMTA2ODc2IDAwMDAwIG4gCjAwMDAx MDY5MzAgMDAwMDAgbiAKMDAwMDEwNjk4NCAwMDAwMCBuIAowMDAwMTA3MDM4IDAwMDAwIG4gCjAw MDAxMDcyNTcgMDAwMDAgbiAKMDAwMDEwNzQ3NiAwMDAwMCBuIAowMDAwMTA4MDY5IDAwMDAwIG4g CjAwMDAxMTE4MTkgMDAwMDAgbiAKMDAwMDEwNzgyMSAwMDAwMCBuIAowMDAwMTA4MDI0IDAwMDAw IG4gCjAwMDAxMTI2MzggMDAwMDAgbiAKMDAwMDExMTg0MSAwMDAwMCBuIAowMDAwMTExODk1IDAw MDAwIG4gCjAwMDAxMTE5NDkgMDAwMDAgbiAKMDAwMDExMjE3NSAwMDAwMCBuIAowMDAwMTEyMzk0 IDAwMDAwIG4gCjAwMDAxMTMwMjYgMDAwMDAgbiAKMDAwMDExNjM0NCAwMDAwMCBuIAowMDAwMTEy NzY0IDAwMDAwIG4gCjAwMDAxMTI5ODEgMDAwMDAgbiAKMDAwMDExNzU5OSAwMDAwMCBuIAowMDAw MTE2MzY2IDAwMDAwIG4gCjAwMDAxMTY0MjAgMDAwMDAgbiAKMDAwMDExNjQ3NCAwMDAwMCBuIAow MDAwMTE2NzA5IDAwMDAwIG4gCjAwMDAxMTY5MzkgMDAwMDAgbiAKMDAwMDExNzE2MCAwMDAwMCBu IAowMDAwMTE3MzgwIDAwMDAwIG4gCjAwMDAxMTc5ODkgMDAwMDAgbiAKMDAwMDEyMTYxMCAwMDAw MCBuIAowMDAwMTE3NzI1IDAwMDAwIG4gCjAwMDAxMTc5MjggMDAwMDAgbiAKMDAwMDEyMjQwNSAw MDAwMCBuIAowMDAwMTIxNjMyIDAwMDAwIG4gCjAwMDAxMjE2ODYgMDAwMDAgbiAKMDAwMDEyMTc0 MCAwMDAwMCBuIAowMDAwMTIxOTU5IDAwMDAwIG4gCjAwMDAxMjIxODIgMDAwMDAgbiAKMDAwMDEy Mjc3OSAwMDAwMCBuIAowMDAwMTI2MjkzIDAwMDAwIG4gCjAwMDAxMjI1MzEgMDAwMDAgbiAKMDAw MDEyMjczNCAwMDAwMCBuIAowMDAwMTI4MTMxIDAwMDAwIG4gCjAwMDAxMjYzMTUgMDAwMDAgbiAK MDAwMDEyNjM2OSAwMDAwMCBuIAowMDAwMTI2NDIzIDAwMDAwIG4gCjAwMDAxMjY0NzcgMDAwMDAg biAKMDAwMDEyNjUzMSAwMDAwMCBuIAowMDAwMTI2NzUwIDAwMDAwIG4gCjAwMDAxMjY5NzcgMDAw MDAgbiAKMDAwMDEyNzIxNiAwMDAwMCBuIAowMDAwMTI3NDUwIDAwMDAwIG4gCjAwMDAxMjc2Njkg MDAwMDAgbiAKMDAwMDEyNzkwMSAwMDAwMCBuIAowMDAwMTI4NTM3IDAwMDAwIG4gCjAwMDAxMzIw NDUgMDAwMDAgbiAKMDAwMDEyODI1NyAwMDAwMCBuIAowMDAwMTI4NDYwIDAwMDAwIG4gCjAwMDAx MzI0NDEgMDAwMDAgbiAKMDAwMDEzMjA2NyAwMDAwMCBuIAowMDAwMTMyMTIxIDAwMDAwIG4gCjAw MDAxMzIxNjggMDAwMDAgbiAKMDAwMDEzMjIyMiAwMDAwMCBuIAowMDAwMTMyNzk5IDAwMDAwIG4g CjAwMDAxMzU2ODAgMDAwMDAgbiAKMDAwMDEzMjU2NyAwMDAwMCBuIAowMDAwMTMyNzcwIDAwMDAw IG4gCjAwMDAxMzczNzcgMDAwMDAgbiAKMDAwMDEzNTcwMiAwMDAwMCBuIAowMDAwMTM1NzU2IDAw MDAwIG4gCjAwMDAxMzU4MTAgMDAwMDAgbiAKMDAwMDEzNjAzNiAwMDAwMCBuIAowMDAwMTM2MjU5 IDAwMDAwIG4gCjAwMDAxMzY0NzEgMDAwMDAgbiAKMDAwMDEzNjcwNiAwMDAwMCBuIAowMDAwMTM2 OTM2IDAwMDAwIG4gCjAwMDAxMzcxNTcgMDAwMDAgbiAKMDAwMDEzNzc4MyAwMDAwMCBuIAowMDAw MTQxMjE4IDAwMDAwIG4gCjAwMDAxMzc1MDMgMDAwMDAgbiAKMDAwMDEzNzcwNiAwMDAwMCBuIAow MDAwMTQyMzAxIDAwMDAwIG4gCjAwMDAxNDEyNDAgMDAwMDAgbiAKMDAwMDE0MTI5NCAwMDAwMCBu IAowMDAwMTQxMzQ4IDAwMDAwIG4gCjAwMDAxNDE0MDIgMDAwMDAgbiAKMDAwMDE0MTYzMiAwMDAw MCBuIAowMDAwMTQxODUxIDAwMDAwIG4gCjAwMDAxNDIwODAgMDAwMDAgbiAKMDAwMDE0MjY4MyAw MDAwMCBuIAowMDAwMTQ2NTQ2IDAwMDAwIG4gCjAwMDAxNDI0MjcgMDAwMDAgbiAKMDAwMDE0MjYz MCAwMDAwMCBuIAowMDAwMTQ3MzQxIDAwMDAwIG4gCjAwMDAxNDY1NjggMDAwMDAgbiAKMDAwMDE0 NjYyMiAwMDAwMCBuIAowMDAwMTQ2Njc2IDAwMDAwIG4gCjAwMDAxNDY4OTUgMDAwMDAgbiAKMDAw MDE0NzExOCAwMDAwMCBuIAowMDAwMTQ3NzE1IDAwMDAwIG4gCjAwMDAxNTEyMDIgMDAwMDAgbiAK MDAwMDE0NzQ2NyAwMDAwMCBuIAowMDAwMTQ3NjcwIDAwMDAwIG4gCjAwMDAxNTI0MjQgMDAwMDAg biAKMDAwMDE1MTIyNCAwMDAwMCBuIAowMDAwMTUxMjc4IDAwMDAwIG4gCjAwMDAxNTEzMzIgMDAw MDAgbiAKMDAwMDE1MTM4NiAwMDAwMCBuIAowMDAwMTUxNDQwIDAwMDAwIG4gCjAwMDAxNTE0OTQg MDAwMDAgbiAKMDAwMDE1MTU0OCAwMDAwMCBuIAowMDAwMTUxNzYwIDAwMDAwIG4gCjAwMDAxNTE5 ODYgMDAwMDAgbiAKMDAwMDE1MjIwNSAwMDAwMCBuIAowMDAwMTUyODA2IDAwMDAwIG4gCjAwMDAx NTYxOTcgMDAwMDAgbiAKMDAwMDE1MjU1MCAwMDAwMCBuIAowMDAwMTUyNzUzIDAwMDAwIG4gCjAw MDAxNTc3OTUgMDAwMDAgbiAKMDAwMDE1NjIxOSAwMDAwMCBuIAowMDAwMTU2MjczIDAwMDAwIG4g CjAwMDAxNTYzMjcgMDAwMDAgbiAKMDAwMDE1NjM4MSAwMDAwMCBuIAowMDAwMTU2NDM1IDAwMDAw IG4gCjAwMDAxNTY2NTYgMDAwMDAgbiAKMDAwMDE1Njg5NSAwMDAwMCBuIAowMDAwMTU3MTE0IDAw MDAwIG4gCjAwMDAxNTczNDYgMDAwMDAgbiAKMDAwMDE1NzU3NiAwMDAwMCBuIAowMDAwMTU4MTkz IDAwMDAwIG4gCjAwMDAxNjE1MDkgMDAwMDAgbiAKMDAwMDE1NzkyMSAwMDAwMCBuIAowMDAwMTU4 MTI0IDAwMDAwIG4gCjAwMDAxNjI5MjUgMDAwMDAgbiAKMDAwMDE2MTUzMSAwMDAwMCBuIAowMDAw MTYxNTg1IDAwMDAwIG4gCjAwMDAxNjE2MzkgMDAwMDAgbiAKMDAwMDE2MTY5MyAwMDAwMCBuIAow MDAwMTYxNzQ3IDAwMDAwIG4gCjAwMDAxNjE4MDEgMDAwMDAgbiAKMDAwMDE2MjAyNyAwMDAwMCBu IAowMDAwMTYyMjQ2IDAwMDAwIG4gCjAwMDAxNjI0NjUgMDAwMDAgbiAKMDAwMDE2MjY4NiAwMDAw MCBuIAowMDAwMTYzMzE1IDAwMDAwIG4gCjAwMDAxNjY0MDcgMDAwMDAgbiAKMDAwMDE2MzA1MSAw MDAwMCBuIAowMDAwMTYzMjU0IDAwMDAwIG4gCjAwMDAxNjkwNDcgMDAwMDAgbiAKMDAwMDE2NjQy OSAwMDAwMCBuIAowMDAwMTY2NDgzIDAwMDAwIG4gCjAwMDAxNjY1MzcgMDAwMDAgbiAKMDAwMDE2 NjU5MSAwMDAwMCBuIAowMDAwMTY2NjQ1IDAwMDAwIG4gCjAwMDAxNjY2OTkgMDAwMDAgbiAKMDAw MDE2Njc1MyAwMDAwMCBuIAowMDAwMTY2OTcyIDAwMDAwIG4gCjAwMDAxNjcyMDQgMDAwMDAgbiAK MDAwMDE2NzQzNCAwMDAwMCBuIAowMDAwMTY3NjUzIDAwMDAwIG4gCjAwMDAxNjc5MDQgMDAwMDAg biAKMDAwMDE2ODEzNiAwMDAwMCBuIAowMDAwMTY4MzY2IDAwMDAwIG4gCjAwMDAxNjg1ODUgMDAw MDAgbiAKMDAwMDE2ODgxNyAwMDAwMCBuIAowMDAwMTY5NDkxIDAwMDAwIG4gCjAwMDAxNzI3NDIg MDAwMDAgbiAKMDAwMDE2OTE3MyAwMDAwMCBuIAowMDAwMTY5MzkwIDAwMDAwIG4gCjAwMDAxNzQ3 NjggMDAwMDAgbiAKMDAwMDE3Mjc2NCAwMDAwMCBuIAowMDAwMTcyODE4IDAwMDAwIG4gCjAwMDAx NzI4NzIgMDAwMDAgbiAKMDAwMDE3MjkyNiAwMDAwMCBuIAowMDAwMTcyOTgwIDAwMDAwIG4gCjAw MDAxNzMxOTkgMDAwMDAgbiAKMDAwMDE3MzQyOCAwMDAwMCBuIAowMDAwMTczNjU5IDAwMDAwIG4g CjAwMDAxNzM4ODAgMDAwMDAgbiAKMDAwMDE3NDEwMyAwMDAwMCBuIAowMDAwMTc0MzI2IDAwMDAw IG4gCjAwMDAxNzQ1NDkgMDAwMDAgbiAKMDAwMDE3NTE4MiAwMDAwMCBuIAowMDAwMTc4ODcwIDAw MDAwIG4gCjAwMDAxNzQ4OTQgMDAwMDAgbiAKMDAwMDE3NTA5NyAwMDAwMCBuIAowMDAwMTc5NTYx IDAwMDAwIG4gCjAwMDAxNzg4OTIgMDAwMDAgbiAKMDAwMDE3OTExNSAwMDAwMCBuIAowMDAwMTc5 MzM4IDAwMDAwIG4gCjAwMDAxNzk5MjUgMDAwMDAgbiAKMDAwMDE4MzM5MCAwMDAwMCBuIAowMDAw MTc5Njg3IDAwMDAwIG4gCjAwMDAxNzk4ODAgMDAwMDAgbiAKMDAwMDE4NDk4OCAwMDAwMCBuIAow MDAwMTgzNDEyIDAwMDAwIG4gCjAwMDAxODM0NjYgMDAwMDAgbiAKMDAwMDE4MzUyMCAwMDAwMCBu IAowMDAwMTgzNTc0IDAwMDAwIG4gCjAwMDAxODM2MjggMDAwMDAgbiAKMDAwMDE4Mzg0NyAwMDAw MCBuIAowMDAwMTg0MDY4IDAwMDAwIG4gCjAwMDAxODQzMDcgMDAwMDAgbiAKMDAwMDE4NDUzOSAw MDAwMCBuIAowMDAwMTg0NzY5IDAwMDAwIG4gCjAwMDAxODUzODYgMDAwMDAgbiAKMDAwMDE4OTE1 OCAwMDAwMCBuIAowMDAwMTg1MTE0IDAwMDAwIG4gCjAwMDAxODUzMTcgMDAwMDAgbiAKMDAwMDE5 MTI4MiAwMDAwMCBuIAowMDAwMTg5MTgwIDAwMDAwIG4gCjAwMDAxODkyMzQgMDAwMDAgbiAKMDAw MDE4OTI4OCAwMDAwMCBuIAowMDAwMTg5MzQyIDAwMDAwIG4gCjAwMDAxODkzOTYgMDAwMDAgbiAK MDAwMDE4OTYxOSAwMDAwMCBuIAowMDAwMTg5ODM4IDAwMDAwIG4gCjAwMDAxOTAwNzkgMDAwMDAg biAKMDAwMDE5MDMzMSAwMDAwMCBuIAowMDAwMTkwNTc5IDAwMDAwIG4gCjAwMDAxOTA4MzEgMDAw MDAgbiAKMDAwMDE5MTA1MCAwMDAwMCBuIAowMDAwMTkxNzEwIDAwMDAwIG4gCjAwMDAxOTU3MjYg MDAwMDAgbiAKMDAwMDE5MTQwOCAwMDAwMCBuIAowMDAwMTkxNjI1IDAwMDAwIG4gCjAwMDAxOTgw MzggMDAwMDAgbiAKMDAwMDE5NTc0OCAwMDAwMCBuIAowMDAwMTk1ODAyIDAwMDAwIG4gCjAwMDAx OTU4NTYgMDAwMDAgbiAKMDAwMDE5NTkxMCAwMDAwMCBuIAowMDAwMTk1OTY0IDAwMDAwIG4gCjAw MDAxOTYwMTggMDAwMDAgbiAKMDAwMDE5NjA3MiAwMDAwMCBuIAowMDAwMTk2MTI2IDAwMDAwIG4g CjAwMDAxOTYxODAgMDAwMDAgbiAKMDAwMDE5NjIzNCAwMDAwMCBuIAowMDAwMTk2NDUzIDAwMDAw IG4gCjAwMDAxOTY2NzIgMDAwMDAgbiAKMDAwMDE5NjkwMyAwMDAwMCBuIAowMDAwMTk3MTI2IDAw MDAwIG4gCjAwMDAxOTczNDUgMDAwMDAgbiAKMDAwMDE5NzU4MiAwMDAwMCBuIAowMDAwMTk3ODAx IDAwMDAwIG4gCjAwMDAxOTg0NTIgMDAwMDAgbiAKMDAwMDIwMTcyMCAwMDAwMCBuIAowMDAwMTk4 MTY0IDAwMDAwIG4gCjAwMDAxOTgzNjcgMDAwMDAgbiAKMDAwMDIwNDA2OCAwMDAwMCBuIAowMDAw MjAxNzQyIDAwMDAwIG4gCjAwMDAyMDE3OTYgMDAwMDAgbiAKMDAwMDIwMTg1MCAwMDAwMCBuIAow MDAwMjAxOTA0IDAwMDAwIG4gCjAwMDAyMDE5NTggMDAwMDAgbiAKMDAwMDIwMjAxMiAwMDAwMCBu IAowMDAwMjAyMjMxIDAwMDAwIG4gCjAwMDAyMDI0NjYgMDAwMDAgbiAKMDAwMDIwMjY4NSAwMDAw MCBuIAowMDAwMjAyOTIxIDAwMDAwIG4gCjAwMDAyMDMxNTQgMDAwMDAgbiAKMDAwMDIwMzM4NCAw MDAwMCBuIAowMDAwMjAzNjE3IDAwMDAwIG4gCjAwMDAyMDM4NDkgMDAwMDAgbiAKMDAwMDIwNDQ5 MCAwMDAwMCBuIAowMDAwMjA4NDU1IDAwMDAwIG4gCjAwMDAyMDQxOTQgMDAwMDAgbiAKMDAwMDIw NDM5NyAwMDAwMCBuIAowMDAwMjA5NjE0IDAwMDAwIG4gCjAwMDAyMDg0NzcgMDAwMDAgbiAKMDAw MDIwODUzMSAwMDAwMCBuIAowMDAwMjA4NTg1IDAwMDAwIG4gCjAwMDAyMDg2MzkgMDAwMDAgbiAK MDAwMDIwODY5MyAwMDAwMCBuIAowMDAwMjA4OTEyIDAwMDAwIG4gCjAwMDAyMDkxNDIgMDAwMDAg biAKMDAwMDIwOTM5NSAwMDAwMCBuIAowMDAwMjA5OTk2IDAwMDAwIG4gCjAwMDAyMTQ1NjkgMDAw MDAgbiAKMDAwMDIwOTc0MCAwMDAwMCBuIAowMDAwMjA5OTQzIDAwMDAwIG4gCjAwMDAyMTY0NTYg MDAwMDAgbiAKMDAwMDIxNDU5MSAwMDAwMCBuIAowMDAwMjE0NjQ1IDAwMDAwIG4gCjAwMDAyMTQ2 OTkgMDAwMDAgbiAKMDAwMDIxNDc1MyAwMDAwMCBuIAowMDAwMjE0ODA3IDAwMDAwIG4gCjAwMDAy MTQ4NjEgMDAwMDAgbiAKMDAwMDIxNDkxNSAwMDAwMCBuIAowMDAwMjE1MTM0IDAwMDAwIG4gCjAw MDAyMTUzNTMgMDAwMDAgbiAKMDAwMDIxNTU3MiAwMDAwMCBuIAowMDAwMjE1Nzk1IDAwMDAwIG4g CjAwMDAyMTYwMTQgMDAwMDAgbiAKMDAwMDIxNjIzMyAwMDAwMCBuIAowMDAwMjE2ODQ4IDAwMDAw IG4gCjAwMDAyMjA1NzIgMDAwMDAgbiAKMDAwMDIxNjU4MiAwMDAwMCBuIAowMDAwMjE2NzcxIDAw MDAwIG4gCjAwMDAyMjE1NzUgMDAwMDAgbiAKMDAwMDIyMDU5NCAwMDAwMCBuIAowMDAwMjIwNjQ4 IDAwMDAwIG4gCjAwMDAyMjA3MDIgMDAwMDAgbiAKMDAwMDIyMDc1NiAwMDAwMCBuIAowMDAwMjIw ODEwIDAwMDAwIG4gCjAwMDAyMjA4NjQgMDAwMDAgbiAKMDAwMDIyMDkxOCAwMDAwMCBuIAowMDAw MjIxMTM3IDAwMDAwIG4gCjAwMDAyMjEzNTYgMDAwMDAgbiAKMDAwMDIyMTk0OSAwMDAwMCBuIAow MDAwMjI2MjAzIDAwMDAwIG4gCjAwMDAyMjE3MDEgMDAwMDAgbiAKMDAwMDIyMTkwNCAwMDAwMCBu IAowMDAwMjI3OTc5IDAwMDAwIG4gCjAwMDAyMjYyMjUgMDAwMDAgbiAKMDAwMDIyNjI3OSAwMDAw MCBuIAowMDAwMjI2MzMzIDAwMDAwIG4gCjAwMDAyMjYzODcgMDAwMDAgbiAKMDAwMDIyNjQ0MSAw MDAwMCBuIAowMDAwMjI2NDk1IDAwMDAwIG4gCjAwMDAyMjY1NDkgMDAwMDAgbiAKMDAwMDIyNjYw MyAwMDAwMCBuIAowMDAwMjI2NjU3IDAwMDAwIG4gCjAwMDAyMjY4NzYgMDAwMDAgbiAKMDAwMDIy NzA5NSAwMDAwMCBuIAowMDAwMjI3MzE4IDAwMDAwIG4gCjAwMDAyMjc1NDEgMDAwMDAgbiAKMDAw MDIyNzc2MCAwMDAwMCBuIAowMDAwMjI4Mzc3IDAwMDAwIG4gCjAwMDAyMzIzOTQgMDAwMDAgbiAK MDAwMDIyODEwNSAwMDAwMCBuIAowMDAwMjI4MzA4IDAwMDAwIG4gCjAwMDAyMzMzNDggMDAwMDAg biAKMDAwMDIzMjQxNiAwMDAwMCBuIAowMDAwMjMyNDcwIDAwMDAwIG4gCjAwMDAyMzI1MjQgMDAw MDAgbiAKMDAwMDIzMjU3OCAwMDAwMCBuIAowMDAwMjMyNjMyIDAwMDAwIG4gCjAwMDAyMzI2ODYg MDAwMDAgbiAKMDAwMDIzMjkwNSAwMDAwMCBuIAowMDAwMjMzMTI5IDAwMDAwIG4gCjAwMDAyMzM3 MjIgMDAwMDAgbiAKMDAwMDIzODMzMiAwMDAwMCBuIAowMDAwMjMzNDc0IDAwMDAwIG4gCjAwMDAy MzM2NzcgMDAwMDAgbiAKMDAwMDI0MDM4MSAwMDAwMCBuIAowMDAwMjM4MzU0IDAwMDAwIG4gCjAw MDAyMzg0MDggMDAwMDAgbiAKMDAwMDIzODQ2MiAwMDAwMCBuIAowMDAwMjM4NTE2IDAwMDAwIG4g CjAwMDAyMzg1NzAgMDAwMDAgbiAKMDAwMDIzODYyNCAwMDAwMCBuIAowMDAwMjM4Njc4IDAwMDAw IG4gCjAwMDAyMzg3MzIgMDAwMDAgbiAKMDAwMDIzODc4NiAwMDAwMCBuIAowMDAwMjM4ODQwIDAw MDAwIG4gCjAwMDAyMzkwNTIgMDAwMDAgbiAKMDAwMDIzOTI3MSAwMDAwMCBuIAowMDAwMjM5NDkw IDAwMDAwIG4gCjAwMDAyMzk3MDkgMDAwMDAgbiAKMDAwMDIzOTkyNSAwMDAwMCBuIAowMDAwMjQw MTQ0IDAwMDAwIG4gCjAwMDAyNDA3ODcgMDAwMDAgbiAKMDAwMDI0NTA2NyAwMDAwMCBuIAowMDAw MjQwNTA3IDAwMDAwIG4gCjAwMDAyNDA3MTAgMDAwMDAgbiAKMDAwMDI0NjI5MyAwMDAwMCBuIAow MDAwMjQ1MDg5IDAwMDAwIG4gCjAwMDAyNDUxNDMgMDAwMDAgbiAKMDAwMDI0NTE5NyAwMDAwMCBu IAowMDAwMjQ1MjUxIDAwMDAwIG4gCjAwMDAyNDUzMDUgMDAwMDAgbiAKMDAwMDI0NTM1OSAwMDAw MCBuIAowMDAwMjQ1NDEzIDAwMDAwIG4gCjAwMDAyNDU2MzIgMDAwMDAgbiAKMDAwMDI0NTg1NSAw MDAwMCBuIAowMDAwMjQ2MDc0IDAwMDAwIG4gCjAwMDAyNDY2NjEgMDAwMDAgbiAKMDAwMDI1MDc0 OCAwMDAwMCBuIAowMDAwMjQ2NDE5IDAwMDAwIG4gCjAwMDAyNDY2MDggMDAwMDAgbiAKMDAwMDI1 MDc3MCAwMDAwMCBuIAowMDAwMjUxMDg2IDAwMDAwIG4gCjAwMDAyNTUwMzQgMDAwMDAgbiAKMDAw MDI1MDg5NiAwMDAwMCBuIAowMDAwMjUxMDY1IDAwMDAwIG4gCjAwMDAyNTY1ODAgMDAwMDAgbiAK MDAwMDI1NTA1NiAwMDAwMCBuIAowMDAwMjU1MTEwIDAwMDAwIG4gCjAwMDAyNTUxNTcgMDAwMDAg biAKMDAwMDI1NTIxMSAwMDAwMCBuIAowMDAwMjU1MjY1IDAwMDAwIG4gCjAwMDAyNTUzMTkgMDAw MDAgbiAKMDAwMDI1NTM3MyAwMDAwMCBuIAowMDAwMjU1NDI3IDAwMDAwIG4gCjAwMDAyNTU0ODEg MDAwMDAgbiAKMDAwMDI1NTcwMCAwMDAwMCBuIAowMDAwMjU1OTIzIDAwMDAwIG4gCjAwMDAyNTYx NDIgMDAwMDAgbiAKMDAwMDI1NjM2MSAwMDAwMCBuIAowMDAwMjU2OTU2IDAwMDAwIG4gCjAwMDAy NjExMjAgMDAwMDAgbiAKMDAwMDI1NjcwNiAwMDAwMCBuIAowMDAwMjU2ODk1IDAwMDAwIG4gCjAw MDAyNzM2MTQgMDAwMDAgbiAKMDAwMDI2MTE0MiAwMDAwMCBuIAowMDAwMjYxMTk2IDAwMDAwIG4g CjAwMDAyNjEyNTAgMDAwMDAgbiAKMDAwMDI2MTMwNCAwMDAwMCBuIAowMDAwMjYxMzU4IDAwMDAw IG4gCjAwMDAyNjE0MTIgMDAwMDAgbiAKMDAwMDI2MTQ2NiAwMDAwMCBuIAowMDAwMjYxNTIwIDAw MDAwIG4gCjAwMDAyNjE1NzQgMDAwMDAgbiAKMDAwMDI2MTYyOCAwMDAwMCBuIAowMDAwMjYxNjgy IDAwMDAwIG4gCjAwMDAyNjE3MzYgMDAwMDAgbiAKMDAwMDI2MTc5MCAwMDAwMCBuIAowMDAwMjYx ODQ0IDAwMDAwIG4gCjAwMDAyNjE4OTggMDAwMDAgbiAKMDAwMDI2MTk1MiAwMDAwMCBuIAowMDAw MjYyMDA2IDAwMDAwIG4gCjAwMDAyNjIyMjkgMDAwMDAgbiAKMDAwMDI2MjQ0OCAwMDAwMCBuIAow MDAwMjYyNjg0IDAwMDAwIG4gCjAwMDAyNjI5MjQgMDAwMDAgbiAKMDAwMDI2MzE1NCAwMDAwMCBu IAowMDAwMjYzMzg3IDAwMDAwIG4gCjAwMDAyNjM2MDYgMDAwMDAgbiAKMDAwMDI2MzgyNSAwMDAw MCBuIAowMDAwMjY0MDA5IDAwMDAwIG4gCjAwMDAyNjQyMDUgMDAwMDAgbiAKMDAwMDI2NDQwOCAw MDAwMCBuIAowMDAwMjY0NjIyIDAwMDAwIG4gCjAwMDAyNjQ4MjcgMDAwMDAgbiAKMDAwMDI2NTAx NiAwMDAwMCBuIAowMDAwMjY1MjA0IDAwMDAwIG4gCjAwMDAyNjU0MDAgMDAwMDAgbiAKMDAwMDI2 NTYwMyAwMDAwMCBuIAowMDAwMjY1NzkyIDAwMDAwIG4gCjAwMDAyNjU5NjMgMDAwMDAgbiAKMDAw MDI2NjE0OSAwMDAwMCBuIAowMDAwMjY2MzMyIDAwMDAwIG4gCjAwMDAyNjY1MjQgMDAwMDAgbiAK MDAwMDI2NjcxMyAwMDAwMCBuIAowMDAwMjY2ODk0IDAwMDAwIG4gCjAwMDAyNjcwOTAgMDAwMDAg biAKMDAwMDI2NzI5MyAwMDAwMCBuIAowMDAwMjY3NDk1IDAwMDAwIG4gCjAwMDAyNjc2OTggMDAw MDAgbiAKMDAwMDI2NzkxMiAwMDAwMCBuIAowMDAwMjY4MTI0IDAwMDAwIG4gCjAwMDAyNjgzMTAg MDAwMDAgbiAKMDAwMDI2ODQ5OCAwMDAwMCBuIAowMDAwMjY4Njc4IDAwMDAwIG4gCjAwMDAyNjg4 NjcgMDAwMDAgbiAKMDAwMDI2OTA1NiAwMDAwMCBuIAowMDAwMjY5MjQ3IDAwMDAwIG4gCjAwMDAy Njk0NDMgMDAwMDAgbiAKMDAwMDI2OTY0NiAwMDAwMCBuIAowMDAwMjY5ODYwIDAwMDAwIG4gCjAw MDAyNzAwNzIgMDAwMDAgbiAKMDAwMDI3MDI2MSAwMDAwMCBuIAowMDAwMjcwNDY0IDAwMDAwIG4g CjAwMDAyNzA2NDUgMDAwMDAgbiAKMDAwMDI3MDgzMSAwMDAwMCBuIAowMDAwMjcxMDExIDAwMDAw IG4gCjAwMDAyNzEyMDcgMDAwMDAgbiAKMDAwMDI3MTQxMCAwMDAwMCBuIAowMDAwMjcxNjE3IDAw MDAwIG4gCjAwMDAyNzE4MjkgMDAwMDAgbiAKMDAwMDI3MjAyNSAwMDAwMCBuIAowMDAwMjcyMjI4 IDAwMDAwIG4gCjAwMDAyNzI0MjQgMDAwMDAgbiAKMDAwMDI3MjYyNyAwMDAwMCBuIAowMDAwMjcy ODIzIDAwMDAwIG4gCjAwMDAyNzMwMTkgMDAwMDAgbiAKMDAwMDI3MzIxNSAwMDAwMCBuIAowMDAw MjczNDE4IDAwMDAwIG4gCjAwMDAyNzQ0MTQgMDAwMDAgbiAKMDAwMDI4MDcyNSAwMDAwMCBuIAow MDAwMjczNzQwIDAwMDAwIG4gCjAwMDAyNzM5MjkgMDAwMDAgbiAKMDAwMDI4NzgzNCAwMDAwMCBu IAowMDAwMjgwNzQ3IDAwMDAwIG4gCjAwMDAyODA4MDEgMDAwMDAgbiAKMDAwMDI4MDg1NSAwMDAw MCBuIAowMDAwMjgwOTA5IDAwMDAwIG4gCjAwMDAyODA5NjMgMDAwMDAgbiAKMDAwMDI4MTAxNyAw MDAwMCBuIAowMDAwMjgxMDcxIDAwMDAwIG4gCjAwMDAyODExMjUgMDAwMDAgbiAKMDAwMDI4MTE3 OSAwMDAwMCBuIAowMDAwMjgxMjMzIDAwMDAwIG4gCjAwMDAyODEyODcgMDAwMDAgbiAKMDAwMDI4 MTM0MSAwMDAwMCBuIAowMDAwMjgxMzk1IDAwMDAwIG4gCjAwMDAyODE0NDkgMDAwMDAgbiAKMDAw MDI4MTUwMyAwMDAwMCBuIAowMDAwMjgxNTU3IDAwMDAwIG4gCjAwMDAyODE2MTEgMDAwMDAgbiAK MDAwMDI4MTY2NSAwMDAwMCBuIAowMDAwMjgxNzE5IDAwMDAwIG4gCjAwMDAyODE5MzggMDAwMDAg biAKMDAwMDI4MjE1NyAwMDAwMCBuIAowMDAwMjgyMzgwIDAwMDAwIG4gCjAwMDAyODI2MDMgMDAw MDAgbiAKMDAwMDI4MjgyMiAwMDAwMCBuIAowMDAwMjgzMDQ4IDAwMDAwIG4gCjAwMDAyODMyNjcg MDAwMDAgbiAKMDAwMDI4MzUwMCAwMDAwMCBuIAowMDAwMjgzNjk2IDAwMDAwIG4gCjAwMDAyODM4 OTIgMDAwMDAgbiAKMDAwMDI4NDA5NSAwMDAwMCBuIAowMDAwMjg0MzAzIDAwMDAwIG4gCjAwMDAy ODQ1MTEgMDAwMDAgbiAKMDAwMDI4NDcyMCAwMDAwMCBuIAowMDAwMjg0OTM4IDAwMDAwIG4gCjAw MDAyODUxNjkgMDAwMDAgbiAKMDAwMDI4NTM5MCAwMDAwMCBuIAowMDAwMjg1NjI0IDAwMDAwIG4g CjAwMDAyODU4MzUgMDAwMDAgbiAKMDAwMDI4NjA2NiAwMDAwMCBuIAowMDAwMjg2Mjk3IDAwMDAw IG4gCjAwMDAyODY1MTAgMDAwMDAgbiAKMDAwMDI4Njc0MyAwMDAwMCBuIAowMDAwMjg2OTc2IDAw MDAwIG4gCjAwMDAyODcxOTkgMDAwMDAgbiAKMDAwMDI4NzQzNSAwMDAwMCBuIAowMDAwMjg3NjMx IDAwMDAwIG4gCjAwMDAyODg0MDggMDAwMDAgbiAKMDAwMDI5MzU0MiAwMDAwMCBuIAowMDAwMjg3 OTYwIDAwMDAwIG4gCjAwMDAyODgxNjMgMDAwMDAgbiAKMDAwMDMwMDQxNCAwMDAwMCBuIAowMDAw MjkzNTY0IDAwMDAwIG4gCjAwMDAyOTM2MTggMDAwMDAgbiAKMDAwMDI5MzY3MiAwMDAwMCBuIAow MDAwMjkzNzI2IDAwMDAwIG4gCjAwMDAyOTM3ODAgMDAwMDAgbiAKMDAwMDI5MzgzNCAwMDAwMCBu IAowMDAwMjkzODg4IDAwMDAwIG4gCjAwMDAyOTM5NDIgMDAwMDAgbiAKMDAwMDI5Mzk5NiAwMDAw MCBuIAowMDAwMjk0MDUwIDAwMDAwIG4gCjAwMDAyOTQxMDQgMDAwMDAgbiAKMDAwMDI5NDE1OCAw MDAwMCBuIAowMDAwMjk0MjEyIDAwMDAwIG4gCjAwMDAyOTQ0MzEgMDAwMDAgbiAKMDAwMDI5NDY2 MiAwMDAwMCBuIAowMDAwMjk0ODk5IDAwMDAwIG4gCjAwMDAyOTUxMTggMDAwMDAgbiAKMDAwMDI5 NTMyNSAwMDAwMCBuIAowMDAwMjk1NTQ0IDAwMDAwIG4gCjAwMDAyOTU3NzEgMDAwMDAgbiAKMDAw MDI5NjAwNiAwMDAwMCBuIAowMDAwMjk2MjQyIDAwMDAwIG4gCjAwMDAyOTY0ODAgMDAwMDAgbiAK MDAwMDI5NjcxOSAwMDAwMCBuIAowMDAwMjk2OTU5IDAwMDAwIG4gCjAwMDAyOTcxNzggMDAwMDAg biAKMDAwMDI5NzQxMiAwMDAwMCBuIAowMDAwMjk3NjM5IDAwMDAwIG4gCjAwMDAyOTc4NzcgMDAw MDAgbiAKMDAwMDI5ODA5NiAwMDAwMCBuIAowMDAwMjk4MzI1IDAwMDAwIG4gCjAwMDAyOTg1NjUg MDAwMDAgbiAKMDAwMDI5ODc5NSAwMDAwMCBuIAowMDAwMjk5MDI4IDAwMDAwIG4gCjAwMDAyOTky NTYgMDAwMDAgbiAKMDAwMDI5OTQ3NSAwMDAwMCBuIAowMDAwMjk5NzExIDAwMDAwIG4gCjAwMDAy OTk5NTEgMDAwMDAgbiAKMDAwMDMwMDE4MSAwMDAwMCBuIAowMDAwMzAwOTgwIDAwMDAwIG4gCjAw MDAzMDMyODggMDAwMDAgbiAKMDAwMDMwMDU0MCAwMDAwMCBuIAowMDAwMzAwNzQzIDAwMDAwIG4g CjAwMDAzMDk0NTEgMDAwMDAgbiAKMDAwMDMwMzMxMCAwMDAwMCBuIAowMDAwMzAzMzY0IDAwMDAw IG4gCjAwMDAzMDM0MTggMDAwMDAgbiAKMDAwMDMwMzQ3MiAwMDAwMCBuIAowMDAwMzAzNTI2IDAw MDAwIG4gCjAwMDAzMDM1ODAgMDAwMDAgbiAKMDAwMDMwMzYzNCAwMDAwMCBuIAowMDAwMzAzNjg4 IDAwMDAwIG4gCjAwMDAzMDM3NDIgMDAwMDAgbiAKMDAwMDMwMzc4OSAwMDAwMCBuIAowMDAwMzAz ODQzIDAwMDAwIG4gCjAwMDAzMDM4OTcgMDAwMDAgbiAKMDAwMDMwMzk1MSAwMDAwMCBuIAowMDAw MzA0MDA1IDAwMDAwIG4gCjAwMDAzMDQyMjQgMDAwMDAgbiAKMDAwMDMwNDQ1MyAwMDAwMCBuIAow MDAwMzA0NjkzIDAwMDAwIG4gCjAwMDAzMDQ5MjMgMDAwMDAgbiAKMDAwMDMwNTE1NiAwMDAwMCBu IAowMDAwMzA1Mzc1IDAwMDAwIG4gCjAwMDAzMDU2MDIgMDAwMDAgbiAKMDAwMDMwNTgzOCAwMDAw MCBuIAowMDAwMzA2MDY2IDAwMDAwIG4gCjAwMDAzMDYyOTAgMDAwMDAgbiAKMDAwMDMwNjUxMCAw MDAwMCBuIAowMDAwMzA2NzI5IDAwMDAwIG4gCjAwMDAzMDY5NTYgMDAwMDAgbiAKMDAwMDMwNzE3 NSAwMDAwMCBuIAowMDAwMzA3NDE0IDAwMDAwIG4gCjAwMDAzMDc2NDYgMDAwMDAgbiAKMDAwMDMw Nzg2NSAwMDAwMCBuIAowMDAwMzA4MDk3IDAwMDAwIG4gCjAwMDAzMDgzMjIgMDAwMDAgbiAKMDAw MDMwODU0MiAwMDAwMCBuIAowMDAwMzA4NzYxIDAwMDAwIG4gCjAwMDAzMDkwMDAgMDAwMDAgbiAK MDAwMDMwOTIzMiAwMDAwMCBuIAowMDAwMzA5OTkzIDAwMDAwIG4gCjAwMDAzMTIyNDggMDAwMDAg biAKMDAwMDMwOTU3NyAwMDAwMCBuIAowMDAwMzA5NzgwIDAwMDAwIG4gCjAwMDAzMTUyMTcgMDAw MDAgbiAKMDAwMDMxMjI3MCAwMDAwMCBuIAowMDAwMzEyMzI0IDAwMDAwIG4gCjAwMDAzMTIzNzgg MDAwMDAgbiAKMDAwMDMxMjQzMiAwMDAwMCBuIAowMDAwMzEyNDg2IDAwMDAwIG4gCjAwMDAzMTI1 NDAgMDAwMDAgbiAKMDAwMDMxMjU5NCAwMDAwMCBuIAowMDAwMzEyNjQ4IDAwMDAwIG4gCjAwMDAz MTI3MDIgMDAwMDAgbiAKMDAwMDMxMjkzOCAwMDAwMCBuIAowMDAwMzEzMTU3IDAwMDAwIG4gCjAw MDAzMTMzOTMgMDAwMDAgbiAKMDAwMDMxMzYxMiAwMDAwMCBuIAowMDAwMzEzODQ0IDAwMDAwIG4g CjAwMDAzMTQwNzUgMDAwMDAgbiAKMDAwMDMxNDI5NCAwMDAwMCBuIAowMDAwMzE0NTI3IDAwMDAw IG4gCjAwMDAzMTQ3NDYgMDAwMDAgbiAKMDAwMDMxNDk2OSAwMDAwMCBuIAowMDAwMzE1NjY5IDAw MDAwIG4gCjAwMDAzMTk3MjAgMDAwMDAgbiAKMDAwMDMxNTM0MyAwMDAwMCBuIAowMDAwMzE1NTYw IDAwMDAwIG4gCjAwMDAzNjEzMTYgMDAwMDAgbiAKMDAwMDMxOTc0MiAwMDAwMCBuIAowMDAwMzE5 Nzk2IDAwMDAwIG4gCjAwMDAzMTk4NTAgMDAwMDAgbiAKMDAwMDMxOTkwNCAwMDAwMCBuIAowMDAw MzE5OTU4IDAwMDAwIG4gCjAwMDAzMjAxNzcgMDAwMDAgbiAKMDAwMDMyMDM5NiAwMDAwMCBuIAow MDAwMzIwNTc3IDAwMDAwIG4gCjAwMDAzMjA3NTMgMDAwMDAgbiAKMDAwMDMyMDkzMSAwMDAwMCBu IAowMDAwMzIxMTIyIDAwMDAwIG4gCjAwMDAzMjEzMDQgMDAwMDAgbiAKMDAwMDM0MzQyNiAwMDAw MCBuIAowMDAwMzQzMTg3IDAwMDAwIG4gCjAwMDAzMjE0ODcgMDAwMDAgbiAKMDAwMDMyMTYwNCAw MDAwMCBuIAowMDAwMzIxNzYwIDAwMDAwIG4gCjAwMDAzMjE5MTEgMDAwMDAgbiAKMDAwMDMyMjA2 NSAwMDAwMCBuIAowMDAwMzIyMjE3IDAwMDAwIG4gCjAwMDAzMjIzNTkgMDAwMDAgbiAKMDAwMDMy MjUxNyAwMDAwMCBuIAowMDAwMzIyNjg3IDAwMDAwIG4gCjAwMDAzMjI4NTkgMDAwMDAgbiAKMDAw MDMyMzAxMSAwMDAwMCBuIAowMDAwMzIzMjE3IDAwMDAwIG4gCjAwMDAzMjMzODkgMDAwMDAgbiAK MDAwMDMyMzU0NSAwMDAwMCBuIAowMDAwMzIzNzAzIDAwMDAwIG4gCjAwMDAzMjM4NTcgMDAwMDAg biAKMDAwMDMyNDAyMyAwMDAwMCBuIAowMDAwMzI0MTg4IDAwMDAwIG4gCjAwMDAzMjQzNjUgMDAw MDAgbiAKMDAwMDMyNDUzMiAwMDAwMCBuIAowMDAwMzI0Njg5IDAwMDAwIG4gCjAwMDAzMjQ4NTYg MDAwMDAgbiAKMDAwMDMyNTAzMSAwMDAwMCBuIAowMDAwMzI1MTk4IDAwMDAwIG4gCjAwMDAzMjUz OTEgMDAwMDAgbiAKMDAwMDMyNTU2NCAwMDAwMCBuIAowMDAwMzI1NzI5IDAwMDAwIG4gCjAwMDAz MjU5MDYgMDAwMDAgbiAKMDAwMDMyNjA2OSAwMDAwMCBuIAowMDAwMzI2MjQ2IDAwMDAwIG4gCjAw MDAzMjY0NTEgMDAwMDAgbiAKMDAwMDMyNjY0MiAwMDAwMCBuIAowMDAwMzI2ODI1IDAwMDAwIG4g CjAwMDAzMjY5OTggMDAwMDAgbiAKMDAwMDMyNzE3MSAwMDAwMCBuIAowMDAwMzI3MzMyIDAwMDAw IG4gCjAwMDAzMjc1MTEgMDAwMDAgbiAKMDAwMDMyNzY4MCAwMDAwMCBuIAowMDAwMzI3ODU1IDAw MDAwIG4gCjAwMDAzMjgwMzYgMDAwMDAgbiAKMDAwMDMyODIxNSAwMDAwMCBuIAowMDAwMzI4Mzk2 IDAwMDAwIG4gCjAwMDAzMjg1NjUgMDAwMDAgbiAKMDAwMDMyODc0MiAwMDAwMCBuIAowMDAwMzI4 OTIxIDAwMDAwIG4gCjAwMDAzMjkwODIgMDAwMDAgbiAKMDAwMDMyOTI2MSAwMDAwMCBuIAowMDAw MzI5NDQwIDAwMDAwIG4gCjAwMDAzMjk2MDkgMDAwMDAgbiAKMDAwMDMyOTgyNCAwMDAwMCBuIAow MDAwMzMwMDI5IDAwMDAwIG4gCjAwMDAzMzAyMDYgMDAwMDAgbiAKMDAwMDMzMDM4NSAwMDAwMCBu IAowMDAwMzMwNTY2IDAwMDAwIG4gCjAwMDAzMzA3NzEgMDAwMDAgbiAKMDAwMDMzMDk0OCAwMDAw MCBuIAowMDAwMzMxMTI3IDAwMDAwIG4gCjAwMDAzMzEyOTIgMDAwMDAgbiAKMDAwMDMzMTQ2NyAw MDAwMCBuIAowMDAwMzMxNjM4IDAwMDAwIG4gCjAwMDAzMzE3OTkgMDAwMDAgbiAKMDAwMDMzMTk4 MCAwMDAwMCBuIAowMDAwMzMyMTY3IDAwMDAwIG4gCjAwMDAzMzIzMzYgMDAwMDAgbiAKMDAwMDMz MjQ5NyAwMDAwMCBuIAowMDAwMzMyNjUyIDAwMDAwIG4gCjAwMDAzMzI4MzkgMDAwMDAgbiAKMDAw MDMzMzAzNiAwMDAwMCBuIAowMDAwMzMzMjQ1IDAwMDAwIG4gCjAwMDAzMzM0NzggMDAwMDAgbiAK MDAwMDMzMzY3MyAwMDAwMCBuIAowMDAwMzMzODQwIDAwMDAwIG4gCjAwMDAzMzQwMTcgMDAwMDAg biAKMDAwMDMzNDE5NCAwMDAwMCBuIAowMDAwMzM0MzY5IDAwMDAwIG4gCjAwMDAzMzQ1MzAgMDAw MDAgbiAKMDAwMDMzNDY5MyAwMDAwMCBuIAowMDAwMzM0ODY2IDAwMDAwIG4gCjAwMDAzMzUwOTUg MDAwMDAgbiAKMDAwMDMzNTMwMCAwMDAwMCBuIAowMDAwMzM1NDgxIDAwMDAwIG4gCjAwMDAzMzU2 NjAgMDAwMDAgbiAKMDAwMDMzNTg1MyAwMDAwMCBuIAowMDAwMzM2MDIyIDAwMDAwIG4gCjAwMDAz MzYyMTEgMDAwMDAgbiAKMDAwMDMzNjM3MiAwMDAwMCBuIAowMDAwMzM2NTc5IDAwMDAwIG4gCjAw MDAzMzY3NDggMDAwMDAgbiAKMDAwMDMzNjkxNyAwMDAwMCBuIAowMDAwMzM3MTI0IDAwMDAwIG4g CjAwMDAzMzczMDUgMDAwMDAgbiAKMDAwMDMzNzQ5OCAwMDAwMCBuIAowMDAwMzM3Njc5IDAwMDAw IG4gCjAwMDAzMzc4NjggMDAwMDAgbiAKMDAwMDMzODExMyAwMDAwMCBuIAowMDAwMzM4Mjk0IDAw MDAwIG4gCjAwMDAzMzg0ODMgMDAwMDAgbiAKMDAwMDMzODY4OCAwMDAwMCBuIAowMDAwMzM4ODY5 IDAwMDAwIG4gCjAwMDAzMzkwMjAgMDAwMDAgbiAKMDAwMDMzOTE5MyAwMDAwMCBuIAowMDAwMzM5 MzcwIDAwMDAwIG4gCjAwMDAzMzk1OTkgMDAwMDAgbiAKMDAwMDMzOTc2OCAwMDAwMCBuIAowMDAw MzM5OTQ1IDAwMDAwIG4gCjAwMDAzNDAxMjIgMDAwMDAgbiAKMDAwMDM0MDI4MyAwMDAwMCBuIAow MDAwMzQwNDQ0IDAwMDAwIG4gCjAwMDAzNDA2MTkgMDAwMDAgbiAKMDAwMDM0MDc4MCAwMDAwMCBu IAowMDAwMzQwOTY1IDAwMDAwIG4gCjAwMDAzNDExMzQgMDAwMDAgbiAKMDAwMDM0MTMwNyAwMDAw MCBuIAowMDAwMzQxNDY4IDAwMDAwIG4gCjAwMDAzNDE2NDUgMDAwMDAgbiAKMDAwMDM0MTgxOCAw MDAwMCBuIAowMDAwMzQxOTkxIDAwMDAwIG4gCjAwMDAzNDIxNjAgMDAwMDAgbiAKMDAwMDM0MjMy OSAwMDAwMCBuIAowMDAwMzQyNTA4IDAwMDAwIG4gCjAwMDAzNDI2OTMgMDAwMDAgbiAKMDAwMDM0 Mjg3MiAwMDAwMCBuIAowMDAwMzQzMDQ3IDAwMDAwIG4gCjAwMDAzNDM0OTIgMDAwMDAgbiAKMDAw MDM2MTcyMSAwMDAwMCBuIAowMDAwMzY0ODU0IDAwMDAwIG4gCjAwMDAzNjE0NDUgMDAwMDAgbiAK MDAwMDM2MTYzNSAwMDAwMCBuIAowMDAwMzY0ODc3IDAwMDAwIG4gCjAwMDAzNjUxNDYgMDAwMDAg biAKMDAwMDM2OTQ0NiAwMDAwMCBuIAowMDAwMzY5NjczIDAwMDAwIG4gCjAwMDAzNjk0MjMgMDAw MDAgbiAKMDAwMDM3MDI0MSAwMDAwMCBuIAowMDAwMzcwNDU0IDAwMDAwIG4gCjAwMDAzNzU3Nzgg MDAwMDAgbiAKMDAwMDM3NjI1MyAwMDAwMCBuIAowMDAwMzc1NzU1IDAwMDAwIG4gCjAwMDAzNzcy NTYgMDAwMDAgbiAKMDAwMDM3NzUyOSAwMDAwMCBuIAowMDAwMzc5NjI3IDAwMDAwIG4gCjAwMDAz Nzk4NzAgMDAwMDAgbiAKMDAwMDM3OTYwNCAwMDAwMCBuIAowMDAwMzgwNDY0IDAwMDAwIG4gCjAw MDAzODA3MzIgMDAwMDAgbiAKMDAwMDM5MDY1MCAwMDAwMCBuIAowMDAwMzkwODY1IDAwMDAwIG4g CjAwMDAzOTA2MjcgMDAwMDAgbiAKMDAwMDM5MjA1MSAwMDAwMCBuIAowMDAwMzkyMzI3IDAwMDAw IG4gCjAwMDA0MDA4NTkgMDAwMDAgbiAKMDAwMDQwMTM4NyAwMDAwMCBuIAowMDAwNDAwODM2IDAw MDAwIG4gCjAwMDA0MDI0NzQgMDAwMDAgbiAKMDAwMDQwMjc0MiAwMDAwMCBuIAowMDAwNDA4ODUy IDAwMDAwIG4gCjAwMDA0MDkyNTggMDAwMDAgbiAKMDAwMDQwODgyOSAwMDAwMCBuIAowMDAwNDEw MTQxIDAwMDAwIG4gCjAwMDA0MTA0MTggMDAwMDAgbiAKMDAwMDQxOTEyMyAwMDAwMCBuIAowMDAw NDE5Njc4IDAwMDAwIG4gCjAwMDA0MTkxMDAgMDAwMDAgbiAKdHJhaWxlcgo8PAovU2l6ZSAxMTYx Ci9JbmZvIDEgMCBSCi9Sb290IDExMjEgMCBSCj4+CnN0YXJ0eHJlZgo0MjEyOTAKJSVFT0YK --_007_4E1F6AAD24975D4BA5B16804296739436655A85ETK5EX14MBXC283r_ Content-Type: text/xml; name="draft-ietf-oauth-v2-28-preliminary.xml" Content-Description: draft-ietf-oauth-v2-28-preliminary.xml Content-Disposition: attachment; filename="draft-ietf-oauth-v2-28-preliminary.xml"; size=186756; creation-date="Mon, 18 Jun 2012 22:51:21 GMT"; modification-date="Mon, 18 Jun 2012 22:43:11 GMT" Content-Transfer-Encoding: base64 PD94bWwgdmVyc2lvbj0nMS4wJyBlbmNvZGluZz0nVVRGLTgnID8+CjwhRE9DVFlQRSByZmMgU1lT VEVNICdyZmMyNjI5LmR0ZCc+Cjw/eG1sLXN0eWxlc2hlZXQgdHlwZT0ndGV4dC94c2wnIGhyZWY9 J3JmYzI2MjkueHNsdCcgPz4KCjxyZmMgY2F0ZWdvcnk9J3N0ZCcgaXByPSd0cnVzdDIwMDkwMicg b2Jzb2xldGVzPSc1ODQ5JyBkb2NOYW1lPSdkcmFmdC1pZXRmLW9hdXRoLXYyLTI4Jz4KICA8P3Jm YyBzdHJpY3Q9J3llcycgPz4KICA8P3JmYyB0b2M9J3llcycgPz4KICA8P3JmYyB0b2NkZXB0aD0n MycgPz4KICA8P3JmYyBzeW1yZWZzPSd5ZXMnID8+CiAgPD9yZmMgc29ydHJlZnM9J3llcycgPz4K ICA8P3JmYyBjb21wYWN0PSd5ZXMnID8+CiAgPD9yZmMgc3ViY29tcGFjdD0neWVzJyA/PgogIAog IDxmcm9udD4KICAgIDx0aXRsZSBhYmJyZXY9J09BdXRoIDIuMCc+VGhlIE9BdXRoIDIuMCBBdXRo b3JpemF0aW9uIEZyYW1ld29yazwvdGl0bGU+CgogICAgPGF1dGhvciBmdWxsbmFtZT0nRXJhbiBI YW1tZXInIHN1cm5hbWU9J0hhbW1lcicgaW5pdGlhbHM9J0UnIHJvbGU9J2VkaXRvcic+CiAgICAg IDxvcmdhbml6YXRpb24+PC9vcmdhbml6YXRpb24+CiAgICAgIDxhZGRyZXNzPgogICAgICAgIDxl bWFpbD5lcmFuQGh1ZW5pdmVyc2UuY29tPC9lbWFpbD4KICAgICAgICA8dXJpPmh0dHA6Ly9odWVu aXZlcnNlLmNvbTwvdXJpPgogICAgICA8L2FkZHJlc3M+CiAgICA8L2F1dGhvcj4KICAgIDxhdXRo b3IgZnVsbG5hbWU9J0RhdmlkIFJlY29yZG9uJyBzdXJuYW1lPSdSZWNvcmRvbicgaW5pdGlhbHM9 J0QnPgogICAgICA8b3JnYW5pemF0aW9uPkZhY2Vib29rPC9vcmdhbml6YXRpb24+CiAgICAgIDxh ZGRyZXNzPgogICAgICAgIDxlbWFpbD5kckBmYi5jb208L2VtYWlsPgogICAgICAgIDx1cmk+aHR0 cDovL3d3dy5kYXZpZHJlY29yZG9uLmNvbS88L3VyaT4KICAgICAgPC9hZGRyZXNzPgogICAgPC9h dXRob3I+CiAgICA8YXV0aG9yIGZ1bGxuYW1lPSdEaWNrIEhhcmR0JyBzdXJuYW1lPSdIYXJkdCcg aW5pdGlhbHM9J0QnPgogICAgICA8b3JnYW5pemF0aW9uPk1pY3Jvc29mdDwvb3JnYW5pemF0aW9u PgogICAgICA8YWRkcmVzcz4KICAgICAgICA8ZW1haWw+ZGljay5oYXJkdEBnbWFpbC5jb208L2Vt YWlsPgogICAgICAgIDx1cmk+aHR0cDovL2RpY2toYXJkdC5vcmcvPC91cmk+CiAgICAgIDwvYWRk cmVzcz4KICAgIDwvYXV0aG9yPgoKICAgIDxkYXRlIHllYXI9IjIwMTIiIG1vbnRoPSJKdW5lIiBk YXk9IjE4IiAvPgoKICAgIDxhcmVhPlNlY3VyaXR5PC9hcmVhPgogICAgPHdvcmtncm91cD5PQXV0 aCBXb3JraW5nIEdyb3VwPC93b3JrZ3JvdXA+CgogICAgPGFic3RyYWN0PgogICAgICA8dD4KICAg ICAgICBUaGUgT0F1dGggMi4wIGF1dGhvcml6YXRpb24gZnJhbWV3b3JrIGVuYWJsZXMgYSB0aGly ZC1wYXJ0eSBhcHBsaWNhdGlvbiB0byBvYnRhaW4gbGltaXRlZAogICAgICAgIGFjY2VzcyB0byBh biBIVFRQIHNlcnZpY2UsIGVpdGhlciBvbiBiZWhhbGYgb2YgYSByZXNvdXJjZSBvd25lciBieSBv cmNoZXN0cmF0aW5nIGFuIGFwcHJvdmFsCiAgICAgICAgaW50ZXJhY3Rpb24gYmV0d2VlbiB0aGUg cmVzb3VyY2Ugb3duZXIgYW5kIHRoZSBIVFRQIHNlcnZpY2UsIG9yIGJ5IGFsbG93aW5nIHRoZSB0 aGlyZC1wYXJ0eQogICAgICAgIGFwcGxpY2F0aW9uIHRvIG9idGFpbiBhY2Nlc3Mgb24gaXRzIG93 biBiZWhhbGYuIFRoaXMgc3BlY2lmaWNhdGlvbiByZXBsYWNlcyBhbmQgb2Jzb2xldGVzCiAgICAg ICAgdGhlIE9BdXRoIDEuMCBwcm90b2NvbCBkZXNjcmliZWQgaW4gUkZDIDU4NDkuCiAgICAgIDwv dD4KICAgIDwvYWJzdHJhY3Q+CiAgPC9mcm9udD4KCiAgPG1pZGRsZT4KCiAgICA8c2VjdGlvbiB0 aXRsZT0nSW50cm9kdWN0aW9uJz4KICAgICAgPHQ+CiAgICAgICAgSW4gdGhlIHRyYWRpdGlvbmFs IGNsaWVudC1zZXJ2ZXIgYXV0aGVudGljYXRpb24gbW9kZWwsIHRoZSBjbGllbnQgcmVxdWVzdHMg YW4gYWNjZXNzCiAgICAgICAgcmVzdHJpY3RlZCByZXNvdXJjZSAocHJvdGVjdGVkIHJlc291cmNl KSBvbiB0aGUgc2VydmVyIGJ5IGF1dGhlbnRpY2F0aW5nIHdpdGggdGhlIHNlcnZlcgogICAgICAg IHVzaW5nIHRoZSByZXNvdXJjZSBvd25lcidzIGNyZWRlbnRpYWxzLiBJbiBvcmRlciB0byBwcm92 aWRlIHRoaXJkLXBhcnR5IGFwcGxpY2F0aW9ucyBhY2Nlc3MKICAgICAgICB0byByZXN0cmljdGVk IHJlc291cmNlcywgdGhlIHJlc291cmNlIG93bmVyIHNoYXJlcyBpdHMgY3JlZGVudGlhbHMgd2l0 aCB0aGUgdGhpcmQtcGFydHkuCiAgICAgICAgVGhpcyBjcmVhdGVzIHNldmVyYWwgcHJvYmxlbXMg YW5kIGxpbWl0YXRpb25zOgogICAgICA8L3Q+CiAgICAgIDx0PgogICAgICAgIDxsaXN0IHN0eWxl PSdzeW1ib2xzJz4KICAgICAgICAgIDx0PgogICAgICAgICAgICBUaGlyZC1wYXJ0eSBhcHBsaWNh dGlvbnMgYXJlIHJlcXVpcmVkIHRvIHN0b3JlIHRoZSByZXNvdXJjZSBvd25lcidzIGNyZWRlbnRp YWxzCiAgICAgICAgICAgIGZvciBmdXR1cmUgdXNlLCB0eXBpY2FsbHkgYSBwYXNzd29yZCBpbiBj bGVhci10ZXh0LgogICAgICAgICAgPC90PgogICAgICAgICAgPHQ+CiAgICAgICAgICAgIFNlcnZl cnMgYXJlIHJlcXVpcmVkIHRvIHN1cHBvcnQgcGFzc3dvcmQgYXV0aGVudGljYXRpb24sIGRlc3Bp dGUgdGhlIHNlY3VyaXR5CiAgICAgICAgICAgIHdlYWtuZXNzZXMgaW5oZXJlbnQgaW4gcGFzc3dv cmRzLgogICAgICAgICAgPC90PgogICAgICAgICAgPHQ+CiAgICAgICAgICAgIFRoaXJkLXBhcnR5 IGFwcGxpY2F0aW9ucyBnYWluIG92ZXJseSBicm9hZCBhY2Nlc3MgdG8gdGhlIHJlc291cmNlIG93 bmVyJ3MgcHJvdGVjdGVkCiAgICAgICAgICAgIHJlc291cmNlcywgbGVhdmluZyByZXNvdXJjZSBv d25lcnMgd2l0aG91dCBhbnkgYWJpbGl0eSB0byByZXN0cmljdCBkdXJhdGlvbiBvciBhY2Nlc3MK ICAgICAgICAgICAgdG8gYSBsaW1pdGVkIHN1YnNldCBvZiByZXNvdXJjZXMuCiAgICAgICAgICA8 L3Q+CiAgICAgICAgICA8dD4KICAgICAgICAgICAgUmVzb3VyY2Ugb3duZXJzIGNhbm5vdCByZXZv a2UgYWNjZXNzIHRvIGFuIGluZGl2aWR1YWwgdGhpcmQtcGFydHkgd2l0aG91dCByZXZva2luZwog ICAgICAgICAgICBhY2Nlc3MgdG8gYWxsIHRoaXJkLXBhcnRpZXMsIGFuZCBtdXN0IGRvIHNvIGJ5 IGNoYW5naW5nIHRoZWlyIHBhc3N3b3JkLgogICAgICAgICAgPC90PgogICAgICAgICAgPHQ+CiAg ICAgICAgICAgIENvbXByb21pc2Ugb2YgYW55IHRoaXJkLXBhcnR5IGFwcGxpY2F0aW9uIHJlc3Vs dHMgaW4gY29tcHJvbWlzZSBvZiB0aGUgZW5kLXVzZXIncwogICAgICAgICAgICBwYXNzd29yZCBh bmQgYWxsIG9mIHRoZSBkYXRhIHByb3RlY3RlZCBieSB0aGF0IHBhc3N3b3JkLgogICAgICAgICAg PC90PgogICAgICAgIDwvbGlzdD4KICAgICAgPC90PgogICAgICA8dD4KICAgICAgICBPQXV0aCBh ZGRyZXNzZXMgdGhlc2UgaXNzdWVzIGJ5IGludHJvZHVjaW5nIGFuIGF1dGhvcml6YXRpb24gbGF5 ZXIgYW5kIHNlcGFyYXRpbmcgdGhlIHJvbGUKICAgICAgICBvZiB0aGUgY2xpZW50IGZyb20gdGhh dCBvZiB0aGUgcmVzb3VyY2Ugb3duZXIuIEluIE9BdXRoLCB0aGUgY2xpZW50IHJlcXVlc3RzIGFj Y2VzcyB0bwogICAgICAgIHJlc291cmNlcyBjb250cm9sbGVkIGJ5IHRoZSByZXNvdXJjZSBvd25l ciBhbmQgaG9zdGVkIGJ5IHRoZSByZXNvdXJjZSBzZXJ2ZXIsIGFuZCBpcyBpc3N1ZWQKICAgICAg ICBhIGRpZmZlcmVudCBzZXQgb2YgY3JlZGVudGlhbHMgdGhhbiB0aG9zZSBvZiB0aGUgcmVzb3Vy Y2Ugb3duZXIuCiAgICAgIDwvdD4KICAgICAgPHQ+CiAgICAgICAgSW5zdGVhZCBvZiB1c2luZyB0 aGUgcmVzb3VyY2Ugb3duZXIncyBjcmVkZW50aWFscyB0byBhY2Nlc3MgcHJvdGVjdGVkIHJlc291 cmNlcywgdGhlIGNsaWVudAogICAgICAgIG9idGFpbnMgYW4gYWNjZXNzIHRva2VuIC0gYSBzdHJp bmcgZGVub3RpbmcgYSBzcGVjaWZpYyBzY29wZSwgbGlmZXRpbWUsIGFuZCBvdGhlciBhY2Nlc3MK ICAgICAgICBhdHRyaWJ1dGVzLiBBY2Nlc3MgdG9rZW5zIGFyZSBpc3N1ZWQgdG8gdGhpcmQtcGFy dHkgY2xpZW50cyBieSBhbiBhdXRob3JpemF0aW9uIHNlcnZlciB3aXRoCiAgICAgICAgdGhlIGFw cHJvdmFsIG9mIHRoZSByZXNvdXJjZSBvd25lci4gVGhlIGNsaWVudCB1c2VzIHRoZSBhY2Nlc3Mg dG9rZW4gdG8gYWNjZXNzIHRoZQogICAgICAgIHByb3RlY3RlZCByZXNvdXJjZXMgaG9zdGVkIGJ5 IHRoZSByZXNvdXJjZSBzZXJ2ZXIuCiAgICAgIDwvdD4KICAgICAgPHQ+CiAgICAgICAgRm9yIGV4 YW1wbGUsIGFuIGVuZC11c2VyIChyZXNvdXJjZSBvd25lcikgY2FuIGdyYW50IGEgcHJpbnRpbmcg c2VydmljZSAoY2xpZW50KSBhY2Nlc3MKICAgICAgICB0byBoZXIgcHJvdGVjdGVkIHBob3RvcyBz dG9yZWQgYXQgYSBwaG90byBzaGFyaW5nIHNlcnZpY2UgKHJlc291cmNlIHNlcnZlciksIHdpdGhv dXQKICAgICAgICBzaGFyaW5nIGhlciB1c2VybmFtZSBhbmQgcGFzc3dvcmQgd2l0aCB0aGUgcHJp bnRpbmcgc2VydmljZS4gSW5zdGVhZCwgc2hlIGF1dGhlbnRpY2F0ZXMKICAgICAgICBkaXJlY3Rs eSB3aXRoIGEgc2VydmVyIHRydXN0ZWQgYnkgdGhlIHBob3RvIHNoYXJpbmcgc2VydmljZSAoYXV0 aG9yaXphdGlvbiBzZXJ2ZXIpIHdoaWNoCiAgICAgICAgaXNzdWVzIHRoZSBwcmludGluZyBzZXJ2 aWNlIGRlbGVnYXRpb24tc3BlY2lmaWMgY3JlZGVudGlhbHMgKGFjY2VzcyB0b2tlbikuCiAgICAg IDwvdD4KICAgICAgPHQ+CiAgICAgICAgVGhpcyBzcGVjaWZpY2F0aW9uIGlzIGRlc2lnbmVkIGZv ciB1c2Ugd2l0aCBIVFRQICg8eHJlZiB0YXJnZXQ9J1JGQzI2MTYnIC8+KS4gVGhlIHVzZSBvZgog ICAgICAgIE9BdXRoIG92ZXIgYW55IG90aGVyIHByb3RvY29sIHRoYW4gSFRUUCBpcyBvdXQgb2Yg c2NvcGUuCiAgICAgIDwvdD4KICAgICAgPHQ+CiAgICAgICAgVGhlIE9BdXRoIDEuMCBwcm90b2Nv bCAoPHhyZWYgdGFyZ2V0PSdSRkM1ODQ5JyAvPiksIHB1Ymxpc2hlZCBhcyBhbiBpbmZvcm1hdGlv bmFsIGRvY3VtZW50LAogICAgICAgIHdhcyB0aGUgcmVzdWx0IG9mIGEgc21hbGwgYWQtaG9jIGNv bW11bml0eSBlZmZvcnQuIFRoaXMgc3RhbmRhcmRzLXRyYWNrIHNwZWNpZmljYXRpb24gYnVpbGRz CiAgICAgICAgb24gdGhlIE9BdXRoIDEuMCBkZXBsb3ltZW50IGV4cGVyaWVuY2UsIGFzIHdlbGwg YXMgYWRkaXRpb25hbCB1c2UgY2FzZXMgYW5kIGV4dGVuc2liaWxpdHkKICAgICAgICByZXF1aXJl bWVudHMgZ2F0aGVyZWQgZnJvbSB0aGUgd2lkZXIgSUVURiBjb21tdW5pdHkuIFRoZSBPQXV0aCAy LjAgcHJvdG9jb2wgaXMgbm90IGJhY2t3YXJkCiAgICAgICAgY29tcGF0aWJsZSB3aXRoIE9BdXRo IDEuMC4gVGhlIHR3byB2ZXJzaW9ucyBtYXkgY28tZXhpc3Qgb24gdGhlIG5ldHdvcmsgYW5kIGlt cGxlbWVudGF0aW9ucwogICAgICAgIG1heSBjaG9vc2UgdG8gc3VwcG9ydCBib3RoLiBIb3dldmVy LCBpdCBpcyB0aGUgaW50ZW50aW9uIG9mIHRoaXMgc3BlY2lmaWNhdGlvbiB0aGF0IG5ldwogICAg ICAgIGltcGxlbWVudGF0aW9uIHN1cHBvcnQgT0F1dGggMi4wIGFzIHNwZWNpZmllZCBpbiB0aGlz IGRvY3VtZW50LCBhbmQgdGhhdCBPQXV0aCAxLjAgaXMgdXNlZAogICAgICAgIG9ubHkgdG8gc3Vw cG9ydCBleGlzdGluZyBkZXBsb3ltZW50cy4gVGhlIE9BdXRoIDIuMCBwcm90b2NvbCBzaGFyZXMg dmVyeSBmZXcgaW1wbGVtZW50YXRpb24KICAgICAgICBkZXRhaWxzIHdpdGggdGhlIE9BdXRoIDEu MCBwcm90b2NvbC4gSW1wbGVtZW50ZXJzIGZhbWlsaWFyIHdpdGggT0F1dGggMS4wIHNob3VsZCBh cHByb2FjaAogICAgICAgIHRoaXMgZG9jdW1lbnQgd2l0aG91dCBhbnkgYXNzdW1wdGlvbnMgYXMg dG8gaXRzIHN0cnVjdHVyZSBhbmQgZGV0YWlscy4KICAgICAgPC90PgoKICAgICAgPHNlY3Rpb24g dGl0bGU9J1JvbGVzJz4KICAgICAgICA8dD4KICAgICAgICAgIE9BdXRoIGRlZmluZXMgZm91ciBy b2xlczoKICAgICAgICA8L3Q+CiAgICAgICAgPHQ+CiAgICAgICAgICA8bGlzdCBzdHlsZT0naGFu Z2luZyc+CiAgICAgICAgICAgIDx0IGhhbmdUZXh0PSdyZXNvdXJjZSBvd25lcic+CiAgICAgICAg ICAgICAgPHZzcGFjZSAvPgogICAgICAgICAgICAgIEFuIGVudGl0eSBjYXBhYmxlIG9mIGdyYW50 aW5nIGFjY2VzcyB0byBhIHByb3RlY3RlZCByZXNvdXJjZS4gV2hlbiB0aGUgcmVzb3VyY2Ugb3du ZXIKICAgICAgICAgICAgICBpcyBhIHBlcnNvbiwgaXQgaXMgcmVmZXJyZWQgdG8gYXMgYW4gZW5k LXVzZXIuCiAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAgPHQgaGFuZ1RleHQ9J3Jlc291cmNl IHNlcnZlcic+CiAgICAgICAgICAgICAgPHZzcGFjZSAvPgogICAgICAgICAgICAgIFRoZSBzZXJ2 ZXIgaG9zdGluZyB0aGUgcHJvdGVjdGVkIHJlc291cmNlcywgY2FwYWJsZSBvZiBhY2NlcHRpbmcg YW5kIHJlc3BvbmRpbmcgdG8KICAgICAgICAgICAgICBwcm90ZWN0ZWQgcmVzb3VyY2UgcmVxdWVz dHMgdXNpbmcgYWNjZXNzIHRva2Vucy4KICAgICAgICAgICAgPC90PgogICAgICAgICAgICA8dCBo YW5nVGV4dD0nY2xpZW50Jz4KICAgICAgICAgICAgICA8dnNwYWNlIC8+CiAgICAgICAgICAgICAg QW4gYXBwbGljYXRpb24gbWFraW5nIHByb3RlY3RlZCByZXNvdXJjZSByZXF1ZXN0cyBvbiBiZWhh bGYgb2YgdGhlIHJlc291cmNlIG93bmVyIGFuZAogICAgICAgICAgICAgIHdpdGggaXRzIGF1dGhv cml6YXRpb24uIFRoZSB0ZXJtIGNsaWVudCBkb2VzIG5vdCBpbXBseSBhbnkgcGFydGljdWxhciBp bXBsZW1lbnRhdGlvbgogICAgICAgICAgICAgIGNoYXJhY3RlcmlzdGljcyAoZS5nLiB3aGV0aGVy IHRoZSBhcHBsaWNhdGlvbiBleGVjdXRlcyBvbiBhIHNlcnZlciwgYSBkZXNrdG9wLCBvcgogICAg ICAgICAgICAgIG90aGVyIGRldmljZXMpLgogICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgIDx0 IGhhbmdUZXh0PSdhdXRob3JpemF0aW9uIHNlcnZlcic+CiAgICAgICAgICAgICAgPHZzcGFjZSAv PgogICAgICAgICAgICAgIFRoZSBzZXJ2ZXIgaXNzdWluZyBhY2Nlc3MgdG9rZW5zIHRvIHRoZSBj bGllbnQgYWZ0ZXIgc3VjY2Vzc2Z1bGx5IGF1dGhlbnRpY2F0aW5nIHRoZQogICAgICAgICAgICAg IHJlc291cmNlIG93bmVyIGFuZCBvYnRhaW5pbmcgYXV0aG9yaXphdGlvbi4KICAgICAgICAgICAg PC90PgogICAgICAgICAgPC9saXN0PgogICAgICAgIDwvdD4KICAgICAgICA8dD4KICAgICAgICAg IFRoZSBpbnRlcmFjdGlvbiBiZXR3ZWVuIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBhbmQgcmVz b3VyY2Ugc2VydmVyIGlzIGJleW9uZCB0aGUgc2NvcGUKICAgICAgICAgIG9mIHRoaXMgc3BlY2lm aWNhdGlvbi4gVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIG1heSBiZSB0aGUgc2FtZSBzZXJ2ZXIg YXMgdGhlIHJlc291cmNlCiAgICAgICAgICBzZXJ2ZXIgb3IgYSBzZXBhcmF0ZSBlbnRpdHkuIEEg c2luZ2xlIGF1dGhvcml6YXRpb24gc2VydmVyIG1heSBpc3N1ZSBhY2Nlc3MgdG9rZW5zCiAgICAg ICAgICBhY2NlcHRlZCBieSBtdWx0aXBsZSByZXNvdXJjZSBzZXJ2ZXJzLgogICAgICAgIDwvdD4K ICAgICAgPC9zZWN0aW9uPgoKICAgICAgPHNlY3Rpb24gdGl0bGU9J1Byb3RvY29sIEZsb3cnPgog ICAgICAgIDxmaWd1cmUgdGl0bGU9J0Fic3RyYWN0IFByb3RvY29sIEZsb3cnIGFuY2hvcj0nRmln dXJlLTEnPgogICAgICAgICAgPGFydHdvcms+CiAgICAgICAgICAgIDwhW0NEQVRBWwogICstLS0t LS0tLSsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLSsKICB8 ICAgICAgICB8LS0oQSktIEF1dGhvcml6YXRpb24gUmVxdWVzdCAtPnwgICBSZXNvdXJjZSAgICB8 CiAgfCAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICBPd25lciAg ICAgfAogIHwgICAgICAgIHw8LShCKS0tIEF1dGhvcml6YXRpb24gR3JhbnQgLS0tfCAgICAgICAg ICAgICAgIHwKICB8ICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0t LS0tLS0tLS0tLS0rCiAgfCAgICAgICAgfAogIHwgICAgICAgIHwgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLSsKICB8ICAgICAgICB8LS0oQyktLSBBdXRob3Jp emF0aW9uIEdyYW50IC0tPnwgQXV0aG9yaXphdGlvbiB8CiAgfCBDbGllbnQgfCAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICB8ICAgICBTZXJ2ZXIgICAgfAogIHwgICAgICAgIHw8LShEKS0t LS0tIEFjY2VzcyBUb2tlbiAtLS0tLS0tfCAgICAgICAgICAgICAgIHwKICB8ICAgICAgICB8ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0rCiAgfCAgICAgICAg fAogIHwgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0t LS0tLSsKICB8ICAgICAgICB8LS0oRSktLS0tLSBBY2Nlc3MgVG9rZW4gLS0tLS0tPnwgICAgUmVz b3VyY2UgICB8CiAgfCAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAg ICBTZXJ2ZXIgICAgfAogIHwgICAgICAgIHw8LShGKS0tLSBQcm90ZWN0ZWQgUmVzb3VyY2UgLS0t fCAgICAgICAgICAgICAgIHwKICArLS0tLS0tLS0rICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICstLS0tLS0tLS0tLS0tLS0rCl1dPgogICAgICAgICAgPC9hcnR3b3JrPgogICAgICAgIDwv ZmlndXJlPgogICAgICAgIDx0PgogICAgICAgICAgVGhlIGFic3RyYWN0IGZsb3cgaWxsdXN0cmF0 ZWQgaW4gPHhyZWYgdGFyZ2V0PSdGaWd1cmUtMScgLz4gZGVzY3JpYmVzIHRoZSBpbnRlcmFjdGlv bgogICAgICAgICAgYmV0d2VlbiB0aGUgZm91ciByb2xlcyBhbmQgaW5jbHVkZXMgdGhlIGZvbGxv d2luZyBzdGVwczoKICAgICAgICA8L3Q+CiAgICAgICAgPHQ+CiAgICAgICAgICA8bGlzdCBzdHls ZT0nZm9ybWF0ICglQyknPgogICAgICAgICAgICA8dD4KICAgICAgICAgICAgICBUaGUgY2xpZW50 IHJlcXVlc3RzIGF1dGhvcml6YXRpb24gZnJvbSB0aGUgcmVzb3VyY2Ugb3duZXIuIFRoZSBhdXRo b3JpemF0aW9uIHJlcXVlc3QKICAgICAgICAgICAgICBjYW4gYmUgbWFkZSBkaXJlY3RseSB0byB0 aGUgcmVzb3VyY2Ugb3duZXIgKGFzIHNob3duKSwgb3IgcHJlZmVyYWJseSBpbmRpcmVjdGx5IHZp YQogICAgICAgICAgICAgIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBhcyBhbiBpbnRlcm1lZGlh cnkuCiAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAgPHQ+CiAgICAgICAgICAgICAgVGhlIGNs aWVudCByZWNlaXZlcyBhbiBhdXRob3JpemF0aW9uIGdyYW50IHdoaWNoIGlzIGEgY3JlZGVudGlh bCByZXByZXNlbnRpbmcKICAgICAgICAgICAgICB0aGUgcmVzb3VyY2Ugb3duZXIncyBhdXRob3Jp emF0aW9uLCBleHByZXNzZWQgdXNpbmcgb25lIG9mIGZvdXIgZ3JhbnQgdHlwZXMgZGVmaW5lZAog ICAgICAgICAgICAgIGluIHRoaXMgc3BlY2lmaWNhdGlvbiBvciB1c2luZyBhbiBleHRlbnNpb24g Z3JhbnQgdHlwZS4gVGhlIGF1dGhvcml6YXRpb24gZ3JhbnQgdHlwZQogICAgICAgICAgICAgIGRl cGVuZHMgb24gdGhlIG1ldGhvZCB1c2VkIGJ5IHRoZSBjbGllbnQgdG8gcmVxdWVzdCBhdXRob3Jp emF0aW9uIGFuZCB0aGUgdHlwZXMKICAgICAgICAgICAgICBzdXBwb3J0ZWQgYnkgdGhlIGF1dGhv cml6YXRpb24gc2VydmVyLgogICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgIDx0PgogICAgICAg ICAgICAgIFRoZSBjbGllbnQgcmVxdWVzdHMgYW4gYWNjZXNzIHRva2VuIGJ5IGF1dGhlbnRpY2F0 aW5nIHdpdGggdGhlIGF1dGhvcml6YXRpb24gc2VydmVyCiAgICAgICAgICAgICAgYW5kIHByZXNl bnRpbmcgdGhlIGF1dGhvcml6YXRpb24gZ3JhbnQuCiAgICAgICAgICAgIDwvdD4KICAgICAgICAg ICAgPHQ+CiAgICAgICAgICAgICAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGF1dGhlbnRpY2F0 ZXMgdGhlIGNsaWVudCBhbmQgdmFsaWRhdGVzIHRoZSBhdXRob3JpemF0aW9uCiAgICAgICAgICAg ICAgZ3JhbnQsIGFuZCBpZiB2YWxpZCBpc3N1ZXMgYW4gYWNjZXNzIHRva2VuLgogICAgICAgICAg ICA8L3Q+CiAgICAgICAgICAgIDx0PgogICAgICAgICAgICAgIFRoZSBjbGllbnQgcmVxdWVzdHMg dGhlIHByb3RlY3RlZCByZXNvdXJjZSBmcm9tIHRoZSByZXNvdXJjZSBzZXJ2ZXIgYW5kIGF1dGhl bnRpY2F0ZXMKICAgICAgICAgICAgICBieSBwcmVzZW50aW5nIHRoZSBhY2Nlc3MgdG9rZW4uCiAg ICAgICAgICAgIDwvdD4KICAgICAgICAgICAgPHQ+CiAgICAgICAgICAgICAgVGhlIHJlc291cmNl IHNlcnZlciB2YWxpZGF0ZXMgdGhlIGFjY2VzcyB0b2tlbiwgYW5kIGlmIHZhbGlkLCBzZXJ2ZXMg dGhlIHJlcXVlc3QuCiAgICAgICAgICAgIDwvdD4KICAgICAgICAgIDwvbGlzdD4KICAgICAgICA8 L3Q+CiAgICAgICAgPHQ+CiAgICAgICAgICBUaGUgcHJlZmVycmVkIG1ldGhvZCBmb3IgdGhlIGNs aWVudCB0byBvYnRhaW4gYW4gYXV0aG9yaXphdGlvbiBncmFudCBmcm9tIHRoZSByZXNvdXJjZQog ICAgICAgICAgb3duZXIgKGRlcGljdGVkIGluIHN0ZXBzIChBKSBhbmQgKEIpKSBpcyB0byB1c2Ug dGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGFzIGFuIGludGVybWVkaWFyeQogICAgICAgICAgd2hp Y2ggaXMgaWxsdXN0cmF0ZWQgaW4gPHhyZWYgdGFyZ2V0PSdGaWd1cmUtMycgLz4uCiAgICAgICAg PC90PgogICAgICA8L3NlY3Rpb24+CgogICAgICA8c2VjdGlvbiB0aXRsZT0nQXV0aG9yaXphdGlv biBHcmFudCc+CiAgICAgICAgPHQ+CiAgICAgICAgICBBbiBhdXRob3JpemF0aW9uIGdyYW50IGlz IGEgY3JlZGVudGlhbCByZXByZXNlbnRpbmcgdGhlIHJlc291cmNlIG93bmVyJ3MgYXV0aG9yaXph dGlvbgogICAgICAgICAgKHRvIGFjY2VzcyBpdHMgcHJvdGVjdGVkIHJlc291cmNlcykgdXNlZCBi eSB0aGUgY2xpZW50IHRvIG9idGFpbiBhbiBhY2Nlc3MgdG9rZW4uIFRoaXMKICAgICAgICAgIHNw ZWNpZmljYXRpb24gZGVmaW5lcyBmb3VyIGdyYW50IHR5cGVzOiBhdXRob3JpemF0aW9uIGNvZGUs IGltcGxpY2l0LCByZXNvdXJjZSBvd25lcgogICAgICAgICAgcGFzc3dvcmQgY3JlZGVudGlhbHMs IGFuZCBjbGllbnQgY3JlZGVudGlhbHMsIGFzIHdlbGwgYXMgYW4gZXh0ZW5zaWJpbGl0eSBtZWNo YW5pc20gZm9yCiAgICAgICAgICBkZWZpbmluZyBhZGRpdGlvbmFsIHR5cGVzLgogICAgICAgIDwv dD4KCiAgICAgICAgPHNlY3Rpb24gdGl0bGU9J0F1dGhvcml6YXRpb24gQ29kZSc+CiAgICAgICAg ICA8dD4KICAgICAgICAgICAgVGhlIGF1dGhvcml6YXRpb24gY29kZSBpcyBvYnRhaW5lZCBieSB1 c2luZyBhbiBhdXRob3JpemF0aW9uIHNlcnZlciBhcyBhbiBpbnRlcm1lZGlhcnkKICAgICAgICAg ICAgYmV0d2VlbiB0aGUgY2xpZW50IGFuZCByZXNvdXJjZSBvd25lci4gSW5zdGVhZCBvZiByZXF1 ZXN0aW5nIGF1dGhvcml6YXRpb24gZGlyZWN0bHkKICAgICAgICAgICAgZnJvbSB0aGUgcmVzb3Vy Y2Ugb3duZXIsIHRoZSBjbGllbnQgZGlyZWN0cyB0aGUgcmVzb3VyY2Ugb3duZXIgdG8gYW4gYXV0 aG9yaXphdGlvbgogICAgICAgICAgICBzZXJ2ZXIgKHZpYSBpdHMgdXNlci1hZ2VudCBhcyBkZWZp bmVkIGluIDx4cmVmIHRhcmdldD0nUkZDMjYxNicgLz4pLCB3aGljaCBpbiB0dXJuCiAgICAgICAg ICAgIGRpcmVjdHMgdGhlIHJlc291cmNlIG93bmVyIGJhY2sgdG8gdGhlIGNsaWVudCB3aXRoIHRo ZSBhdXRob3JpemF0aW9uIGNvZGUuCiAgICAgICAgICA8L3Q+CiAgICAgICAgICA8dD4KICAgICAg ICAgICAgQmVmb3JlIGRpcmVjdGluZyB0aGUgcmVzb3VyY2Ugb3duZXIgYmFjayB0byB0aGUgY2xp ZW50IHdpdGggdGhlIGF1dGhvcml6YXRpb24gY29kZSwgdGhlCiAgICAgICAgICAgIGF1dGhvcml6 YXRpb24gc2VydmVyIGF1dGhlbnRpY2F0ZXMgdGhlIHJlc291cmNlIG93bmVyIGFuZCBvYnRhaW5z IGF1dGhvcml6YXRpb24uCiAgICAgICAgICAgIEJlY2F1c2UgdGhlIHJlc291cmNlIG93bmVyIG9u bHkgYXV0aGVudGljYXRlcyB3aXRoIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciwgdGhlCiAgICAg ICAgICAgIHJlc291cmNlIG93bmVyJ3MgY3JlZGVudGlhbHMgYXJlIG5ldmVyIHNoYXJlZCB3aXRo IHRoZSBjbGllbnQuCiAgICAgICAgICA8L3Q+CiAgICAgICAgICA8dD4KICAgICAgICAgICAgVGhl IGF1dGhvcml6YXRpb24gY29kZSBwcm92aWRlcyBhIGZldyBpbXBvcnRhbnQgc2VjdXJpdHkgYmVu ZWZpdHMgc3VjaCBhcyB0aGUgYWJpbGl0eQogICAgICAgICAgICB0byBhdXRoZW50aWNhdGUgdGhl IGNsaWVudCwgYW5kIHRoZSB0cmFuc21pc3Npb24gb2YgdGhlIGFjY2VzcyB0b2tlbiBkaXJlY3Rs eSB0bwogICAgICAgICAgICB0aGUgY2xpZW50IHdpdGhvdXQgcGFzc2luZyBpdCB0aHJvdWdoIHRo ZSByZXNvdXJjZSBvd25lcidzIHVzZXItYWdlbnQsIHBvdGVudGlhbGx5CiAgICAgICAgICAgIGV4 cG9zaW5nIGl0IHRvIG90aGVycywgaW5jbHVkaW5nIHRoZSByZXNvdXJjZSBvd25lci4KICAgICAg ICAgIDwvdD4KICAgICAgICA8L3NlY3Rpb24+CgogICAgICAgIDxzZWN0aW9uIHRpdGxlPSdJbXBs aWNpdCc+CiAgICAgICAgICA8dD4KICAgICAgICAgICAgVGhlIGltcGxpY2l0IGdyYW50IGlzIGEg c2ltcGxpZmllZCBhdXRob3JpemF0aW9uIGNvZGUgZmxvdyBvcHRpbWl6ZWQgZm9yIGNsaWVudHMK ICAgICAgICAgICAgaW1wbGVtZW50ZWQgaW4gYSBicm93c2VyIHVzaW5nIGEgc2NyaXB0aW5nIGxh bmd1YWdlIHN1Y2ggYXMgSmF2YVNjcmlwdC4gSW4gdGhlIGltcGxpY2l0CiAgICAgICAgICAgIGZs b3csIGluc3RlYWQgb2YgaXNzdWluZyB0aGUgY2xpZW50IGFuIGF1dGhvcml6YXRpb24gY29kZSwg dGhlIGNsaWVudCBpcyBpc3N1ZWQgYW4KICAgICAgICAgICAgYWNjZXNzIHRva2VuIGRpcmVjdGx5 IChhcyB0aGUgcmVzdWx0IG9mIHRoZSByZXNvdXJjZSBvd25lciBhdXRob3JpemF0aW9uKS4gVGhl IGdyYW50CiAgICAgICAgICAgIHR5cGUgaXMgaW1wbGljaXQgYXMgbm8gaW50ZXJtZWRpYXRlIGNy ZWRlbnRpYWxzIChzdWNoIGFzIGFuIGF1dGhvcml6YXRpb24gY29kZSkgYXJlCiAgICAgICAgICAg IGlzc3VlZCAoYW5kIGxhdGVyIHVzZWQgdG8gb2J0YWluIGFuIGFjY2VzcyB0b2tlbikuCiAgICAg ICAgICA8L3Q+CiAgICAgICAgICA8dD4KICAgICAgICAgICAgV2hlbiBpc3N1aW5nIGFuIGFjY2Vz cyB0b2tlbiBkdXJpbmcgdGhlIGltcGxpY2l0IGdyYW50IGZsb3csIHRoZSBhdXRob3JpemF0aW9u IHNlcnZlcgogICAgICAgICAgICBkb2VzIG5vdCBhdXRoZW50aWNhdGUgdGhlIGNsaWVudC4gSW4g c29tZSBjYXNlcywgdGhlIGNsaWVudCBpZGVudGl0eSBjYW4gYmUgdmVyaWZpZWQKICAgICAgICAg ICAgdmlhIHRoZSByZWRpcmVjdGlvbiBVUkkgdXNlZCB0byBkZWxpdmVyIHRoZSBhY2Nlc3MgdG9r ZW4gdG8gdGhlIGNsaWVudC4gVGhlIGFjY2VzcwogICAgICAgICAgICB0b2tlbiBtYXkgYmUgZXhw b3NlZCB0byB0aGUgcmVzb3VyY2Ugb3duZXIgb3Igb3RoZXIgYXBwbGljYXRpb25zIHdpdGggYWNj ZXNzIHRvIHRoZQogICAgICAgICAgICByZXNvdXJjZSBvd25lcidzIHVzZXItYWdlbnQuCiAgICAg ICAgICA8L3Q+CiAgICAgICAgICA8dD4KICAgICAgICAgICAgSW1wbGljaXQgZ3JhbnRzIGltcHJv dmUgdGhlIHJlc3BvbnNpdmVuZXNzIGFuZCBlZmZpY2llbmN5IG9mIHNvbWUgY2xpZW50cyAoc3Vj aCBhcyBhCiAgICAgICAgICAgIGNsaWVudCBpbXBsZW1lbnRlZCBhcyBhbiBpbi1icm93c2VyIGFw cGxpY2F0aW9uKSBzaW5jZSBpdCByZWR1Y2VzIHRoZSBudW1iZXIgb2Ygcm91bmQKICAgICAgICAg ICAgdHJpcHMgcmVxdWlyZWQgdG8gb2J0YWluIGFuIGFjY2VzcyB0b2tlbi4gSG93ZXZlciwgdGhp cyBjb252ZW5pZW5jZSBzaG91bGQgYmUgd2VpZ2hlZAogICAgICAgICAgICBhZ2FpbnN0IHRoZSBz ZWN1cml0eSBpbXBsaWNhdGlvbnMgb2YgdXNpbmcgaW1wbGljaXQgZ3JhbnRzLCBlc3BlY2lhbGx5 IHdoZW4gdGhlCiAgICAgICAgICAgIGF1dGhvcml6YXRpb24gY29kZSBncmFudCB0eXBlIGlzIGF2 YWlsYWJsZS4KICAgICAgICAgIDwvdD4KICAgICAgICA8L3NlY3Rpb24+CgogICAgICAgIDxzZWN0 aW9uIHRpdGxlPSJSZXNvdXJjZSBPd25lciBQYXNzd29yZCBDcmVkZW50aWFscyI+CiAgICAgICAg ICA8dD4KICAgICAgICAgICAgVGhlIHJlc291cmNlIG93bmVyIHBhc3N3b3JkIGNyZWRlbnRpYWxz IChpLmUuIHVzZXJuYW1lIGFuZCBwYXNzd29yZCkgY2FuIGJlIHVzZWQKICAgICAgICAgICAgZGly ZWN0bHkgYXMgYW4gYXV0aG9yaXphdGlvbiBncmFudCB0byBvYnRhaW4gYW4gYWNjZXNzIHRva2Vu LiBUaGUgY3JlZGVudGlhbHMgc2hvdWxkCiAgICAgICAgICAgIG9ubHkgYmUgdXNlZCB3aGVuIHRo ZXJlIGlzIGEgaGlnaCBkZWdyZWUgb2YgdHJ1c3QgYmV0d2VlbiB0aGUgcmVzb3VyY2Ugb3duZXIg YW5kIHRoZQogICAgICAgICAgICBjbGllbnQgKGUuZy4gdGhlIGNsaWVudCBpcyBwYXJ0IG9mIHRo ZSBkZXZpY2Ugb3BlcmF0aW5nIHN5c3RlbSBvciBhIGhpZ2hseSBwcml2aWxlZ2VkCiAgICAgICAg ICAgIGFwcGxpY2F0aW9uKSwgYW5kIHdoZW4gb3RoZXIgYXV0aG9yaXphdGlvbiBncmFudCB0eXBl cyBhcmUgbm90IGF2YWlsYWJsZSAoc3VjaCBhcyBhbgogICAgICAgICAgICBhdXRob3JpemF0aW9u IGNvZGUpLgogICAgICAgICAgPC90PgogICAgICAgICAgPHQ+CiAgICAgICAgICAgIEV2ZW4gdGhv dWdoIHRoaXMgZ3JhbnQgdHlwZSByZXF1aXJlcyBkaXJlY3QgY2xpZW50IGFjY2VzcyB0byB0aGUg cmVzb3VyY2Ugb3duZXIKICAgICAgICAgICAgY3JlZGVudGlhbHMsIHRoZSByZXNvdXJjZSBvd25l ciBjcmVkZW50aWFscyBhcmUgdXNlZCBmb3IgYSBzaW5nbGUgcmVxdWVzdCBhbmQgYXJlCiAgICAg ICAgICAgIGV4Y2hhbmdlZCBmb3IgYW4gYWNjZXNzIHRva2VuLiBUaGlzIGdyYW50IHR5cGUgY2Fu IGVsaW1pbmF0ZSB0aGUgbmVlZCBmb3IgdGhlIGNsaWVudAogICAgICAgICAgICB0byBzdG9yZSB0 aGUgcmVzb3VyY2Ugb3duZXIgY3JlZGVudGlhbHMgZm9yIGZ1dHVyZSB1c2UsIGJ5IGV4Y2hhbmdp bmcgdGhlIGNyZWRlbnRpYWxzCiAgICAgICAgICAgIHdpdGggYSBsb25nLWxpdmVkIGFjY2VzcyB0 b2tlbiBvciByZWZyZXNoIHRva2VuLgogICAgICAgICAgPC90PgogICAgICAgIDwvc2VjdGlvbj4K CiAgICAgICAgPHNlY3Rpb24gdGl0bGU9J0NsaWVudCBDcmVkZW50aWFscyc+CiAgICAgICAgICA8 dD4KICAgICAgICAgICAgVGhlIGNsaWVudCBjcmVkZW50aWFscyAob3Igb3RoZXIgZm9ybXMgb2Yg Y2xpZW50IGF1dGhlbnRpY2F0aW9uKSBjYW4gYmUgdXNlZCBhcyBhbgogICAgICAgICAgICBhdXRo b3JpemF0aW9uIGdyYW50IHdoZW4gdGhlIGF1dGhvcml6YXRpb24gc2NvcGUgaXMgbGltaXRlZCB0 byB0aGUgcHJvdGVjdGVkIHJlc291cmNlcwogICAgICAgICAgICB1bmRlciB0aGUgY29udHJvbCBv ZiB0aGUgY2xpZW50LCBvciB0byBwcm90ZWN0ZWQgcmVzb3VyY2VzIHByZXZpb3VzbHkgYXJyYW5n ZWQgd2l0aCB0aGUKICAgICAgICAgICAgYXV0aG9yaXphdGlvbiBzZXJ2ZXIuIENsaWVudCBjcmVk ZW50aWFscyBhcmUgdXNlZCBhcyBhbiBhdXRob3JpemF0aW9uIGdyYW50IHR5cGljYWxseQogICAg ICAgICAgICB3aGVuIHRoZSBjbGllbnQgaXMgYWN0aW5nIG9uIGl0cyBvd24gYmVoYWxmICh0aGUg Y2xpZW50IGlzIGFsc28gdGhlIHJlc291cmNlIG93bmVyKSwgb3IKICAgICAgICAgICAgaXMgcmVx dWVzdGluZyBhY2Nlc3MgdG8gcHJvdGVjdGVkIHJlc291cmNlcyBiYXNlZCBvbiBhbiBhdXRob3Jp emF0aW9uIHByZXZpb3VzbHkKICAgICAgICAgICAgYXJyYW5nZWQgd2l0aCB0aGUgYXV0aG9yaXph dGlvbiBzZXJ2ZXIuCiAgICAgICAgICA8L3Q+CiAgICAgICAgPC9zZWN0aW9uPgoKICAgICAgPC9z ZWN0aW9uPgoKICAgICAgPHNlY3Rpb24gdGl0bGU9J0FjY2VzcyBUb2tlbic+CiAgICAgICAgPHQ+ CiAgICAgICAgICBBY2Nlc3MgdG9rZW5zIGFyZSBjcmVkZW50aWFscyB1c2VkIHRvIGFjY2VzcyBw cm90ZWN0ZWQgcmVzb3VyY2VzLiBBbiBhY2Nlc3MgdG9rZW4gaXMgYQogICAgICAgICAgc3RyaW5n IHJlcHJlc2VudGluZyBhbiBhdXRob3JpemF0aW9uIGlzc3VlZCB0byB0aGUgY2xpZW50LiBUaGUg c3RyaW5nIGlzIHVzdWFsbHkgb3BhcXVlCiAgICAgICAgICB0byB0aGUgY2xpZW50LiBUb2tlbnMg cmVwcmVzZW50IHNwZWNpZmljIHNjb3BlcyBhbmQgZHVyYXRpb25zIG9mIGFjY2VzcywgZ3JhbnRl ZCBieSB0aGUKICAgICAgICAgIHJlc291cmNlIG93bmVyLCBhbmQgZW5mb3JjZWQgYnkgdGhlIHJl c291cmNlIHNlcnZlciBhbmQgYXV0aG9yaXphdGlvbiBzZXJ2ZXIuCiAgICAgICAgPC90PgogICAg ICAgIDx0PgogICAgICAgICAgVGhlIHRva2VuIG1heSBkZW5vdGUgYW4gaWRlbnRpZmllciB1c2Vk IHRvIHJldHJpZXZlIHRoZSBhdXRob3JpemF0aW9uIGluZm9ybWF0aW9uLCBvcgogICAgICAgICAg c2VsZi1jb250YWluIHRoZSBhdXRob3JpemF0aW9uIGluZm9ybWF0aW9uIGluIGEgdmVyaWZpYWJs ZSBtYW5uZXIgKGkuZS4gYSB0b2tlbiBzdHJpbmcKICAgICAgICAgIGNvbnNpc3Rpbmcgb2Ygc29t ZSBkYXRhIGFuZCBhIHNpZ25hdHVyZSkuIEFkZGl0aW9uYWwgYXV0aGVudGljYXRpb24gY3JlZGVu dGlhbHMsIHdoaWNoCiAgICAgICAgICBhcmUgYmV5b25kIHRoZSBzY29wZSBvZiB0aGlzIHNwZWNp ZmljYXRpb24sIG1heSBiZSByZXF1aXJlZCBpbiBvcmRlciBmb3IgdGhlIGNsaWVudCB0bwogICAg ICAgICAgdXNlIGEgdG9rZW4uCiAgICAgICAgPC90PgogICAgICAgIDx0PgogICAgICAgICAgVGhl IGFjY2VzcyB0b2tlbiBwcm92aWRlcyBhbiBhYnN0cmFjdGlvbiBsYXllciwgcmVwbGFjaW5nIGRp ZmZlcmVudCBhdXRob3JpemF0aW9uCiAgICAgICAgICBjb25zdHJ1Y3RzIChlLmcuIHVzZXJuYW1l IGFuZCBwYXNzd29yZCkgd2l0aCBhIHNpbmdsZSB0b2tlbiB1bmRlcnN0b29kIGJ5IHRoZSByZXNv dXJjZQogICAgICAgICAgc2VydmVyLiBUaGlzIGFic3RyYWN0aW9uIGVuYWJsZXMgaXNzdWluZyBh Y2Nlc3MgdG9rZW5zIG1vcmUgcmVzdHJpY3RpdmUgdGhhbiB0aGUKICAgICAgICAgIGF1dGhvcml6 YXRpb24gZ3JhbnQgdXNlZCB0byBvYnRhaW4gdGhlbSwgYXMgd2VsbCBhcyByZW1vdmluZyB0aGUg cmVzb3VyY2Ugc2VydmVyJ3MgbmVlZCB0bwogICAgICAgICAgdW5kZXJzdGFuZCBhIHdpZGUgcmFu Z2Ugb2YgYXV0aGVudGljYXRpb24gbWV0aG9kcy4KICAgICAgICA8L3Q+CiAgICAgICAgPHQ+CiAg ICAgICAgICBBY2Nlc3MgdG9rZW5zIGNhbiBoYXZlIGRpZmZlcmVudCBmb3JtYXRzLCBzdHJ1Y3R1 cmVzLCBhbmQgbWV0aG9kcyBvZiB1dGlsaXphdGlvbiAoZS5nLgogICAgICAgICAgY3J5cHRvZ3Jh cGhpYyBwcm9wZXJ0aWVzKSBiYXNlZCBvbiB0aGUgcmVzb3VyY2Ugc2VydmVyIHNlY3VyaXR5IHJl cXVpcmVtZW50cy4gQWNjZXNzIHRva2VuCiAgICAgICAgICBhdHRyaWJ1dGVzIGFuZCB0aGUgbWV0 aG9kcyB1c2VkIHRvIGFjY2VzcyBwcm90ZWN0ZWQgcmVzb3VyY2VzIGFyZSBiZXlvbmQgdGhlIHNj b3BlIG9mIHRoaXMKICAgICAgICAgIHNwZWNpZmljYXRpb24gYW5kIGFyZSBkZWZpbmVkIGJ5IGNv bXBhbmlvbiBzcGVjaWZpY2F0aW9ucy4KICAgICAgICA8L3Q+CiAgICAgIDwvc2VjdGlvbj4KCiAg ICAgIDxzZWN0aW9uIHRpdGxlPSdSZWZyZXNoIFRva2VuJz4KICAgICAgICA8dD4KICAgICAgICAg IFJlZnJlc2ggdG9rZW5zIGFyZSBjcmVkZW50aWFscyB1c2VkIHRvIG9idGFpbiBhY2Nlc3MgdG9r ZW5zLiBSZWZyZXNoIHRva2VucyBhcmUgaXNzdWVkIHRvCiAgICAgICAgICB0aGUgY2xpZW50IGJ5 IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBhbmQgYXJlIHVzZWQgdG8gb2J0YWluIGEgbmV3IGFj Y2VzcyB0b2tlbiB3aGVuIHRoZQogICAgICAgICAgY3VycmVudCBhY2Nlc3MgdG9rZW4gYmVjb21l cyBpbnZhbGlkIG9yIGV4cGlyZXMsIG9yIHRvIG9idGFpbiBhZGRpdGlvbmFsIGFjY2VzcyB0b2tl bnMKICAgICAgICAgIHdpdGggaWRlbnRpY2FsIG9yIG5hcnJvd2VyIHNjb3BlIChhY2Nlc3MgdG9r ZW5zIG1heSBoYXZlIGEgc2hvcnRlciBsaWZldGltZSBhbmQgZmV3ZXIKICAgICAgICAgIHBlcm1p c3Npb25zIHRoYW4gYXV0aG9yaXplZCBieSB0aGUgcmVzb3VyY2Ugb3duZXIpLiBJc3N1aW5nIGEg cmVmcmVzaCB0b2tlbiBpcyBvcHRpb25hbAogICAgICAgICAgYXQgdGhlIGRpc2NyZXRpb24gb2Yg dGhlIGF1dGhvcml6YXRpb24gc2VydmVyLiBJZiB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgaXNz dWVzIGEKICAgICAgICAgIHJlZnJlc2ggdG9rZW4sIGl0IGlzIGluY2x1ZGVkIHdoZW4gaXNzdWlu ZyBhbiBhY2Nlc3MgdG9rZW4gKGkuZS4gc3RlcCAoRCkgaW4KICAgICAgICAgIDx4cmVmIHRhcmdl dD0nRmlndXJlLTEnIC8+KS4KICAgICAgICA8L3Q+CiAgICAgICAgPHQ+CiAgICAgICAgICBBIHJl ZnJlc2ggdG9rZW4gaXMgYSBzdHJpbmcgcmVwcmVzZW50aW5nIHRoZSBhdXRob3JpemF0aW9uIGdy YW50ZWQgdG8gdGhlIGNsaWVudCBieSB0aGUKICAgICAgICAgIHJlc291cmNlIG93bmVyLiBUaGUg c3RyaW5nIGlzIHVzdWFsbHkgb3BhcXVlIHRvIHRoZSBjbGllbnQuIFRoZSB0b2tlbiBkZW5vdGVz IGFuCiAgICAgICAgICBpZGVudGlmaWVyIHVzZWQgdG8gcmV0cmlldmUgdGhlIGF1dGhvcml6YXRp b24gaW5mb3JtYXRpb24uIFVubGlrZSBhY2Nlc3MgdG9rZW5zLCByZWZyZXNoCiAgICAgICAgICB0 b2tlbnMgYXJlIGludGVuZGVkIGZvciB1c2Ugb25seSB3aXRoIGF1dGhvcml6YXRpb24gc2VydmVy cyBhbmQgYXJlIG5ldmVyIHNlbnQgdG8KICAgICAgICAgIHJlc291cmNlIHNlcnZlcnMuCiAgICAg ICAgPC90PgogICAgICAgIDxmaWd1cmUgdGl0bGU9J1JlZnJlc2hpbmcgYW4gRXhwaXJlZCBBY2Nl c3MgVG9rZW4nIGFuY2hvcj0nRmlndXJlLTInPgogICAgICAgICAgPGFydHdvcms+CiAgICAgICAg ICAgIDwhW0NEQVRBWwogICstLS0tLS0tLSsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLSsKICB8ICAgICAgICB8LS0oQSktLS0tLS0tIEF1 dGhvcml6YXRpb24gR3JhbnQgLS0tLS0tLS0tPnwgICAgICAgICAgICAgICB8CiAgfCAgICAgICAg fCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAg ICAgfAogIHwgICAgICAgIHw8LShCKS0tLS0tLS0tLS0tIEFjY2VzcyBUb2tlbiAtLS0tLS0tLS0t LS0tfCAgICAgICAgICAgICAgIHwKICB8ICAgICAgICB8ICAgICAgICAgICAgICAgJiBSZWZyZXNo IFRva2VuICAgICAgICAgICAgIHwgICAgICAgICAgICAgICB8CiAgfCAgICAgICAgfCAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgfAogIHwg ICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0rICAgfCAgICAg ICAgICAgICAgIHwKICB8ICAgICAgICB8LS0oQyktLS0tIEFjY2VzcyBUb2tlbiAtLS0tPnwgICAg ICAgICAgfCAgIHwgICAgICAgICAgICAgICB8CiAgfCAgICAgICAgfCAgICAgICAgICAgICAgICAg ICAgICAgICAgICB8ICAgICAgICAgIHwgICB8ICAgICAgICAgICAgICAgfAogIHwgICAgICAgIHw8 LShEKS0gUHJvdGVjdGVkIFJlc291cmNlIC0tfCBSZXNvdXJjZSB8ICAgfCBBdXRob3JpemF0aW9u IHwKICB8IENsaWVudCB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgIFNlcnZlciAgfCAg IHwgICAgIFNlcnZlciAgICB8CiAgfCAgICAgICAgfC0tKEUpLS0tLSBBY2Nlc3MgVG9rZW4gLS0t LT58ICAgICAgICAgIHwgICB8ICAgICAgICAgICAgICAgfAogIHwgICAgICAgIHwgICAgICAgICAg ICAgICAgICAgICAgICAgICAgfCAgICAgICAgICB8ICAgfCAgICAgICAgICAgICAgIHwKICB8ICAg ICAgICB8PC0oRiktIEludmFsaWQgVG9rZW4gRXJyb3IgLXwgICAgICAgICAgfCAgIHwgICAgICAg ICAgICAgICB8CiAgfCAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0t LS0tLSsgICB8ICAgICAgICAgICAgICAgfAogIHwgICAgICAgIHwgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgIHwKICB8ICAgICAgICB8LS0o RyktLS0tLS0tLS0tLSBSZWZyZXNoIFRva2VuIC0tLS0tLS0tLS0tPnwgICAgICAgICAgICAgICB8 CiAgfCAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8 ICAgICAgICAgICAgICAgfAogIHwgICAgICAgIHw8LShIKS0tLS0tLS0tLS0tIEFjY2VzcyBUb2tl biAtLS0tLS0tLS0tLS0tfCAgICAgICAgICAgICAgIHwKICArLS0tLS0tLS0rICAgICAgICAgICAm IE9wdGlvbmFsIFJlZnJlc2ggVG9rZW4gICAgICAgICstLS0tLS0tLS0tLS0tLS0rCl1dPgogICAg ICAgICAgPC9hcnR3b3JrPgogICAgICAgIDwvZmlndXJlPgogICAgICAgIDx0PgogICAgICAgICAg VGhlIGZsb3cgaWxsdXN0cmF0ZWQgaW4gPHhyZWYgdGFyZ2V0PSdGaWd1cmUtMicgLz4gaW5jbHVk ZXMgdGhlIGZvbGxvd2luZyBzdGVwczoKICAgICAgICA8L3Q+CiAgICAgICAgPHQ+CiAgICAgICAg ICA8bGlzdCBzdHlsZT0nZm9ybWF0ICglQyknPgogICAgICAgICAgICA8dD4KICAgICAgICAgICAg ICBUaGUgY2xpZW50IHJlcXVlc3RzIGFuIGFjY2VzcyB0b2tlbiBieSBhdXRoZW50aWNhdGluZyB3 aXRoIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciwKICAgICAgICAgICAgICBhbmQgcHJlc2VudGlu ZyBhbiBhdXRob3JpemF0aW9uIGdyYW50LgogICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgIDx0 PgogICAgICAgICAgICAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBhdXRoZW50aWNhdGVzIHRo ZSBjbGllbnQgYW5kIHZhbGlkYXRlcyB0aGUgYXV0aG9yaXphdGlvbgogICAgICAgICAgICAgIGdy YW50LCBhbmQgaWYgdmFsaWQgaXNzdWVzIGFuIGFjY2VzcyB0b2tlbiBhbmQgYSByZWZyZXNoIHRv a2VuLgogICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgIDx0PgogICAgICAgICAgICAgIFRoZSBj bGllbnQgbWFrZXMgYSBwcm90ZWN0ZWQgcmVzb3VyY2UgcmVxdWVzdCB0byB0aGUgcmVzb3VyY2Ug c2VydmVyIGJ5IHByZXNlbnRpbmcKICAgICAgICAgICAgICB0aGUgYWNjZXNzIHRva2VuLgogICAg ICAgICAgICA8L3Q+CiAgICAgICAgICAgIDx0PgogICAgICAgICAgICAgIFRoZSByZXNvdXJjZSBz ZXJ2ZXIgdmFsaWRhdGVzIHRoZSBhY2Nlc3MgdG9rZW4sIGFuZCBpZiB2YWxpZCwgc2VydmVzIHRo ZSByZXF1ZXN0LgogICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgIDx0PgogICAgICAgICAgICAg IFN0ZXBzIChDKSBhbmQgKEQpIHJlcGVhdCB1bnRpbCB0aGUgYWNjZXNzIHRva2VuIGV4cGlyZXMu IElmIHRoZSBjbGllbnQga25vd3MgdGhlCiAgICAgICAgICAgICAgYWNjZXNzIHRva2VuIGV4cGly ZWQsIGl0IHNraXBzIHRvIHN0ZXAgKEcpLCBvdGhlcndpc2UgaXQgbWFrZXMgYW5vdGhlciBwcm90 ZWN0ZWQKICAgICAgICAgICAgICByZXNvdXJjZSByZXF1ZXN0LgogICAgICAgICAgICA8L3Q+CiAg ICAgICAgICAgIDx0PgogICAgICAgICAgICAgIFNpbmNlIHRoZSBhY2Nlc3MgdG9rZW4gaXMgaW52 YWxpZCwgdGhlIHJlc291cmNlIHNlcnZlciByZXR1cm5zIGFuIGludmFsaWQgdG9rZW4KICAgICAg ICAgICAgICBlcnJvci4KICAgICAgICAgICAgPC90PgogICAgICAgICAgICA8dD4KICAgICAgICAg ICAgICBUaGUgY2xpZW50IHJlcXVlc3RzIGEgbmV3IGFjY2VzcyB0b2tlbiBieSBhdXRoZW50aWNh dGluZyB3aXRoIHRoZSBhdXRob3JpemF0aW9uCiAgICAgICAgICAgICAgc2VydmVyIGFuZCBwcmVz ZW50aW5nIHRoZSByZWZyZXNoIHRva2VuLiBUaGUgY2xpZW50IGF1dGhlbnRpY2F0aW9uIHJlcXVp cmVtZW50cyBhcmUKICAgICAgICAgICAgICBiYXNlZCBvbiB0aGUgY2xpZW50IHR5cGUgYW5kIG9u IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBwb2xpY2llcy4KICAgICAgICAgICAgPC90PgogICAg ICAgICAgICA8dD4KICAgICAgICAgICAgICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYXV0aGVu dGljYXRlcyB0aGUgY2xpZW50IGFuZCB2YWxpZGF0ZXMgdGhlIHJlZnJlc2ggdG9rZW4sCiAgICAg ICAgICAgICAgYW5kIGlmIHZhbGlkIGlzc3VlcyBhIG5ldyBhY2Nlc3MgdG9rZW4gKGFuZCBvcHRp b25hbGx5LCBhIG5ldyByZWZyZXNoIHRva2VuKS4KICAgICAgICAgICAgPC90PgogICAgICAgICAg PC9saXN0PgogICAgICAgIDwvdD4KICAgICAgICA8dD4KICAgICAgICAgIFN0ZXBzIEMsIEQsIEUs IGFuZCBGIGFyZSBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIHNwZWNpZmljYXRpb24gYXMgZGVz Y3JpYmVkIGluCiAgICAgICAgICA8eHJlZiB0YXJnZXQ9J2FjY2Vzcy1yZXNvdXJjZScgLz4uCiAg ICAgICAgPC90PgogICAgICA8L3NlY3Rpb24+CgogICAgICA8c2VjdGlvbiB0aXRsZT0nVExTIFZl cnNpb24nIGFuY2hvcj0ndGxzJz4KICAgICAgICA8dD4KICAgICAgICAgIFdoZW5ldmVyIFRMUyBp cyB1c2VkIGJ5IHRoaXMgc3BlY2lmaWNhdGlvbiwgdGhlIGFwcHJvcHJpYXRlIHZlcnNpb24gKG9y IHZlcnNpb25zKSBvZgogICAgICAgICAgVExTIHdpbGwgdmFyeSBvdmVyIHRpbWUsIGJhc2VkIG9u IHRoZSB3aWRlc3ByZWFkIGRlcGxveW1lbnQgYW5kIGtub3duIHNlY3VyaXR5CiAgICAgICAgICB2 dWxuZXJhYmlsaXRpZXMuIEF0IHRoZSB0aW1lIG9mIHRoaXMgd3JpdGluZywgVExTIHZlcnNpb24g MS4yIDx4cmVmIHRhcmdldD0nUkZDNTI0NicgLz4KICAgICAgICAgIGlzIHRoZSBtb3N0IHJlY2Vu dCB2ZXJzaW9uLCBidXQgaGFzIGEgdmVyeSBsaW1pdGVkIGRlcGxveW1lbnQgYmFzZSBhbmQgbWln aHQgbm90IGJlCiAgICAgICAgICByZWFkaWx5IGF2YWlsYWJsZSBmb3IgaW1wbGVtZW50YXRpb24u IFRMUyB2ZXJzaW9uIDEuMCA8eHJlZiB0YXJnZXQ9J1JGQzIyNDYnIC8+IGlzIHRoZQogICAgICAg ICAgbW9zdCB3aWRlbHkgZGVwbG95ZWQgdmVyc2lvbiwgYW5kIHdpbGwgcHJvdmlkZSB0aGUgYnJv YWRlc3QgaW50ZXJvcGVyYWJpbGl0eS4KICAgICAgICA8L3Q+CiAgICAgICAgPHQ+CiAgICAgICAg ICBJbXBsZW1lbnRhdGlvbnMgTUFZIGFsc28gc3VwcG9ydCBhZGRpdGlvbmFsIHRyYW5zcG9ydC1s YXllciBzZWN1cml0eSBtZWNoYW5pc21zCiAgICAgICAgICB0aGF0IG1lZXQgdGhlaXIgc2VjdXJp dHkgcmVxdWlyZW1lbnRzLgogICAgICAgIDwvdD4KICAgICAgPC9zZWN0aW9uPgoKICAgICAgPHNl Y3Rpb24gdGl0bGU9J0hUVFAgUmVkaXJlY3Rpb25zJz4KICAgICAgICA8dD4KICAgICAgICAgIFRo aXMgc3BlY2lmaWNhdGlvbiBtYWtlcyBleHRlbnNpdmUgdXNlIG9mIEhUVFAgcmVkaXJlY3Rpb25z LCBpbiB3aGljaCB0aGUgY2xpZW50IG9yIHRoZQogICAgICAgICAgYXV0aG9yaXphdGlvbiBzZXJ2 ZXIgZGlyZWN0IHRoZSByZXNvdXJjZSBvd25lcidzIHVzZXItYWdlbnQgdG8gYW5vdGhlciBkZXN0 aW5hdGlvbi4gV2hpbGUKICAgICAgICAgIHRoZSBleGFtcGxlcyBpbiB0aGlzIHNwZWNpZmljYXRp b24gc2hvdyB0aGUgdXNlIG9mIHRoZSBIVFRQIDMwMiBzdGF0dXMgY29kZSwgYW55IG90aGVyCiAg ICAgICAgICBtZXRob2QgYXZhaWxhYmxlIHZpYSB0aGUgdXNlci1hZ2VudCB0byBhY2NvbXBsaXNo IHRoaXMgcmVkaXJlY3Rpb24gaXMgYWxsb3dlZCBhbmQgaXMKICAgICAgICAgIGNvbnNpZGVyZWQg dG8gYmUgYW4gaW1wbGVtZW50YXRpb24gZGV0YWlsLgogICAgICAgIDwvdD4KICAgICAgPC9zZWN0 aW9uPgoKICAgICAgPHNlY3Rpb24gdGl0bGU9J0ludGVyb3BlcmFiaWxpdHknPgogICAgICAgIDx0 PgogICAgICAgICAgT0F1dGggMi4wIHByb3ZpZGVzIGEgcmljaCBhdXRob3JpemF0aW9uIGZyYW1l d29yayB3aXRoIHdlbGwtZGVmaW5lZCBzZWN1cml0eSBwcm9wZXJ0aWVzLgogICAgICAgICAgSG93 ZXZlciwgYXMgYSByaWNoIGFuZCBoaWdobHkgZXh0ZW5zaWJsZSBmcmFtZXdvcmsgd2l0aCBtYW55 IG9wdGlvbmFsIGNvbXBvbmVudHMsIG9uIGl0cwogICAgICAgICAgb3duLCB0aGlzIHNwZWNpZmlj YXRpb24gaXMgbGlrZWx5IHRvIHByb2R1Y2UgYSB3aWRlIHJhbmdlIG9mIG5vbi1pbnRlcm9wZXJh YmxlCiAgICAgICAgICBpbXBsZW1lbnRhdGlvbnMuCiAgICAgICAgPC90PgogICAgICAgIDx0Pgog ICAgICAgICAgSW4gYWRkaXRpb24sIHRoaXMgc3BlY2lmaWNhdGlvbiBsZWF2ZXMgYSBmZXcgcmVx dWlyZWQgY29tcG9uZW50cyBwYXJ0aWFsbHkgb3IgZnVsbHkKICAgICAgICAgIHVuZGVmaW5lZCAo ZS5nLiBjbGllbnQgcmVnaXN0cmF0aW9uLCBhdXRob3JpemF0aW9uIHNlcnZlciBjYXBhYmlsaXRp ZXMsIGVuZHBvaW50CiAgICAgICAgICBkaXNjb3ZlcnkpLiBXaXRob3V0IHRoZXNlIGNvbXBvbmVu dHMsIGNsaWVudHMgbXVzdCBiZSBtYW51YWxseSBhbmQgc3BlY2lmaWNhbGx5CiAgICAgICAgICBj b25maWd1cmVkIGFnYWluc3QgYSBzcGVjaWZpYyBhdXRob3JpemF0aW9uIHNlcnZlciBhbmQgcmVz b3VyY2Ugc2VydmVyIGluIG9yZGVyIHRvCiAgICAgICAgICBpbnRlcm9wZXJhdGUuCiAgICAgICAg PC90PgogICAgICAgIDx0PgogICAgICAgICAgVGhpcyBmcmFtZXdvcmsgd2FzIGRlc2lnbmVkIHdp dGggdGhlIGNsZWFyIGV4cGVjdGF0aW9uIHRoYXQgZnV0dXJlIHdvcmsgd2lsbCBkZWZpbmUKICAg ICAgICAgIHByZXNjcmlwdGl2ZSBwcm9maWxlcyBhbmQgZXh0ZW5zaW9ucyBuZWNlc3NhcnkgdG8g YWNoaWV2ZSBmdWxsIHdlYi1zY2FsZQogICAgICAgICAgaW50ZXJvcGVyYWJpbGl0eS4KICAgICAg ICA8L3Q+CiAgICAgIDwvc2VjdGlvbj4KCiAgICAgIDxzZWN0aW9uIHRpdGxlPSdOb3RhdGlvbmFs IENvbnZlbnRpb25zJz4KICAgICAgICA8dD4KICAgICAgICAgIFRoZSBrZXkgd29yZHMgIk1VU1Qi LCAiTVVTVCBOT1QiLCAiUkVRVUlSRUQiLCAiU0hBTEwiLCAiU0hBTEwgTk9UIiwgIlNIT1VMRCIs ICJTSE9VTEQKICAgICAgICAgIE5PVCIsICJSRUNPTU1FTkRFRCIsICJNQVkiLCBhbmQgIk9QVElP TkFMIiBpbiB0aGlzIHNwZWNpZmljYXRpb24gYXJlIHRvIGJlIGludGVycHJldGVkIGFzCiAgICAg ICAgICBkZXNjcmliZWQgaW4gPHhyZWYgdGFyZ2V0PSdSRkMyMTE5JyAvPi4KICAgICAgICA8L3Q+ CiAgICAgICAgPHQ+CiAgICAgICAgICBUaGlzIHNwZWNpZmljYXRpb24gdXNlcyB0aGUgQXVnbWVu dGVkIEJhY2t1cy1OYXVyIEZvcm0gKEFCTkYpIG5vdGF0aW9uIG9mCiAgICAgICAgICA8eHJlZiB0 YXJnZXQ9J1JGQzUyMzQnIC8+LgoJICBBZGRpdGlvbmFsbHksIHRoZSBydWxlIFVSSS1SZWZlcmVu Y2UgaXMgaW5jbHVkZWQgZnJvbQoJICBVbmlmb3JtIFJlc291cmNlIElkZW50aWZpZXIgKFVSSSkg PHhyZWYgdGFyZ2V0PSdSRkMzOTg2JyAvPi4KICAgICAgICA8L3Q+CiAgICAgICAgPHQ+CiAgICAg ICAgICBDZXJ0YWluIHNlY3VyaXR5LXJlbGF0ZWQgdGVybXMgYXJlIHRvIGJlIHVuZGVyc3Rvb2Qg aW4gdGhlIHNlbnNlIGRlZmluZWQgaW4KICAgICAgICAgIDx4cmVmIHRhcmdldD0nUkZDNDk0OScg Lz4uIFRoZXNlIHRlcm1zIGluY2x1ZGUsIGJ1dCBhcmUgbm90IGxpbWl0ZWQgdG8sICJhdHRhY2si LAogICAgICAgICAgImF1dGhlbnRpY2F0aW9uIiwgImF1dGhvcml6YXRpb24iLCAiY2VydGlmaWNh dGUiLCAiY29uZmlkZW50aWFsaXR5IiwgImNyZWRlbnRpYWwiLAogICAgICAgICAgImVuY3J5cHRp b24iLCAiaWRlbnRpdHkiLCAic2lnbiIsICJzaWduYXR1cmUiLCAidHJ1c3QiLCAidmFsaWRhdGUi LCBhbmQgInZlcmlmeSIuCiAgICAgICAgPC90PgogICAgICAgIDx0PgogICAgICAgICAgVW5sZXNz IG90aGVyd2lzZSBub3RlZCwgYWxsIHRoZSBwcm90b2NvbCBwYXJhbWV0ZXIgbmFtZXMgYW5kIHZh bHVlcyBhcmUgY2FzZSBzZW5zaXRpdmUuCiAgICAgICAgPC90PgogICAgICA8L3NlY3Rpb24+Cgog ICAgPC9zZWN0aW9uPgoKICAgIDxzZWN0aW9uIHRpdGxlPSdDbGllbnQgUmVnaXN0cmF0aW9uJz4K ICAgICAgPHQ+CiAgICAgICAgQmVmb3JlIGluaXRpYXRpbmcgdGhlIHByb3RvY29sLCB0aGUgY2xp ZW50IHJlZ2lzdGVycyB3aXRoIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlci4gVGhlCiAgICAgICAg bWVhbnMgdGhyb3VnaCB3aGljaCB0aGUgY2xpZW50IHJlZ2lzdGVycyB3aXRoIHRoZSBhdXRob3Jp emF0aW9uIHNlcnZlciBhcmUgYmV5b25kIHRoZQogICAgICAgIHNjb3BlIG9mIHRoaXMgc3BlY2lm aWNhdGlvbiwgYnV0IHR5cGljYWxseSBpbnZvbHZlIGVuZC11c2VyIGludGVyYWN0aW9uIHdpdGgg YW4gSFRNTAogICAgICAgIHJlZ2lzdHJhdGlvbiBmb3JtLgogICAgICA8L3Q+CiAgICAgIDx0Pgog ICAgICAgIENsaWVudCByZWdpc3RyYXRpb24gZG9lcyBub3QgcmVxdWlyZSBhIGRpcmVjdCBpbnRl cmFjdGlvbiBiZXR3ZWVuIHRoZSBjbGllbnQgYW5kIHRoZQogICAgICAgIGF1dGhvcml6YXRpb24g c2VydmVyLiBXaGVuIHN1cHBvcnRlZCBieSB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIsIHJlZ2lz dHJhdGlvbiBjYW4gcmVseQogICAgICAgIG9uIG90aGVyIG1lYW5zIGZvciBlc3RhYmxpc2hpbmcg dHJ1c3QgYW5kIG9idGFpbmluZyB0aGUgcmVxdWlyZWQgY2xpZW50IHByb3BlcnRpZXMgKGUuZy4K ICAgICAgICByZWRpcmVjdGlvbiBVUkksIGNsaWVudCB0eXBlKS4gRm9yIGV4YW1wbGUsIHJlZ2lz dHJhdGlvbiBjYW4gYmUgYWNjb21wbGlzaGVkIHVzaW5nIGEKICAgICAgICBzZWxmLWlzc3VlZCBv ciB0aGlyZC1wYXJ0eS1pc3N1ZWQgYXNzZXJ0aW9uLCBvciBieSB0aGUgYXV0aG9yaXphdGlvbiBz ZXJ2ZXIgcGVyZm9ybWluZwogICAgICAgIGNsaWVudCBkaXNjb3ZlcnkgdXNpbmcgYSB0cnVzdGVk IGNoYW5uZWwuCiAgICAgIDwvdD4KICAgICAgPHQ+CiAgICAgICAgV2hlbiByZWdpc3RlcmluZyBh IGNsaWVudCwgdGhlIGNsaWVudCBkZXZlbG9wZXIgU0hBTEw6CiAgICAgIDwvdD4KICAgICAgPHQ+ CiAgICAgICAgPGxpc3Qgc3R5bGU9J3N5bWJvbHMnPgogICAgICAgICAgPHQ+CiAgICAgICAgICAg IHNwZWNpZnkgdGhlIGNsaWVudCB0eXBlIGFzIGRlc2NyaWJlZCBpbiA8eHJlZiB0YXJnZXQ9J2Ns aWVudC10eXBlcycgLz4sCiAgICAgICAgICA8L3Q+CiAgICAgICAgICA8dD4KICAgICAgICAgICAg cHJvdmlkZSBpdHMgY2xpZW50IHJlZGlyZWN0aW9uIFVSSXMgYXMgZGVzY3JpYmVkIGluCiAgICAg ICAgICAgIDx4cmVmIHRhcmdldD0ncmVkaXJlY3QtdXJpJyAvPiwgYW5kCiAgICAgICAgICA8L3Q+ CiAgICAgICAgICA8dD4KICAgICAgICAgICAgaW5jbHVkZSBhbnkgb3RoZXIgaW5mb3JtYXRpb24g cmVxdWlyZWQgYnkgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIChlLmcuIGFwcGxpY2F0aW9uCiAg ICAgICAgICAgIG5hbWUsIHdlYnNpdGUsIGRlc2NyaXB0aW9uLCBsb2dvIGltYWdlLCB0aGUgYWNj ZXB0YW5jZSBvZiBsZWdhbCB0ZXJtcykuCiAgICAgICAgICA8L3Q+CiAgICAgICAgPC9saXN0Pgog ICAgICA8L3Q+CgogICAgICA8c2VjdGlvbiB0aXRsZT0nQ2xpZW50IFR5cGVzJyBhbmNob3I9J2Ns aWVudC10eXBlcyc+CiAgICAgICAgPHQ+CiAgICAgICAgICBPQXV0aCBkZWZpbmVzIHR3byBjbGll bnQgdHlwZXMsIGJhc2VkIG9uIHRoZWlyIGFiaWxpdHkgdG8gYXV0aGVudGljYXRlIHNlY3VyZWx5 IHdpdGggdGhlCiAgICAgICAgICBhdXRob3JpemF0aW9uIHNlcnZlciAoaS5lLiBhYmlsaXR5IHRv IG1haW50YWluIHRoZSBjb25maWRlbnRpYWxpdHkgb2YgdGhlaXIgY2xpZW50CiAgICAgICAgICBj cmVkZW50aWFscyk6CiAgICAgICAgPC90PgogICAgICAgIDx0PgogICAgICAgICAgPGxpc3Qgc3R5 bGU9J2hhbmdpbmcnPgogICAgICAgICAgICA8dCBoYW5nVGV4dD0nY29uZmlkZW50aWFsJz4KICAg ICAgICAgICAgICA8dnNwYWNlIC8+CiAgICAgICAgICAgICAgQ2xpZW50cyBjYXBhYmxlIG9mIG1h aW50YWluaW5nIHRoZSBjb25maWRlbnRpYWxpdHkgb2YgdGhlaXIgY3JlZGVudGlhbHMgKGUuZy4K ICAgICAgICAgICAgICBjbGllbnQgaW1wbGVtZW50ZWQgb24gYSBzZWN1cmUgc2VydmVyIHdpdGgg cmVzdHJpY3RlZCBhY2Nlc3MgdG8gdGhlIGNsaWVudAogICAgICAgICAgICAgIGNyZWRlbnRpYWxz KSwgb3IgY2FwYWJsZSBvZiBzZWN1cmUgY2xpZW50IGF1dGhlbnRpY2F0aW9uIHVzaW5nIG90aGVy IG1lYW5zLgogICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgIDx0IGhhbmdUZXh0PSdwdWJsaWMn PgogICAgICAgICAgICAgIDx2c3BhY2UgLz4KICAgICAgICAgICAgICBDbGllbnRzIGluY2FwYWJs ZSBvZiBtYWludGFpbmluZyB0aGUgY29uZmlkZW50aWFsaXR5IG9mIHRoZWlyIGNyZWRlbnRpYWxz IChlLmcuCiAgICAgICAgICAgICAgY2xpZW50cyBleGVjdXRpbmcgb24gdGhlIGRldmljZSB1c2Vk IGJ5IHRoZSByZXNvdXJjZSBvd25lciBzdWNoIGFzIGFuIGluc3RhbGxlZAogICAgICAgICAgICAg IG5hdGl2ZSBhcHBsaWNhdGlvbiBvciBhIHdlYiBicm93c2VyLWJhc2VkIGFwcGxpY2F0aW9uKSwg YW5kIGluY2FwYWJsZSBvZiBzZWN1cmUKICAgICAgICAgICAgICBjbGllbnQgYXV0aGVudGljYXRp b24gdmlhIGFueSBvdGhlciBtZWFucy4KICAgICAgICAgICAgPC90PgogICAgICAgICAgPC9saXN0 PgogICAgICAgIDwvdD4KICAgICAgICA8dD4KICAgICAgICAgIFRoZSBjbGllbnQgdHlwZSBkZXNp Z25hdGlvbiBpcyBiYXNlZCBvbiB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIncyBkZWZpbml0aW9u IG9mIHNlY3VyZQogICAgICAgICAgYXV0aGVudGljYXRpb24gYW5kIGl0cyBhY2NlcHRhYmxlIGV4 cG9zdXJlIGxldmVscyBvZiBjbGllbnQgY3JlZGVudGlhbHMuIFRoZQogICAgICAgICAgYXV0aG9y aXphdGlvbiBzZXJ2ZXIgU0hPVUxEIE5PVCBtYWtlIGFzc3VtcHRpb25zIGFib3V0IHRoZSBjbGll bnQgdHlwZS4KICAgICAgICA8L3Q+CiAgICAgICAgPHQ+CiAgICAgICAgICBBIGNsaWVudCBtYXkg YmUgaW1wbGVtZW50ZWQgYXMgYSBkaXN0cmlidXRlZCBzZXQgb2YgY29tcG9uZW50cywgZWFjaCB3 aXRoIGEgZGlmZmVyZW50CiAgICAgICAgICBjbGllbnQgdHlwZSBhbmQgc2VjdXJpdHkgY29udGV4 dCAoZS5nLiBhIGRpc3RyaWJ1dGVkIGNsaWVudCB3aXRoIGJvdGggYSBjb25maWRlbnRpYWwKICAg ICAgICAgIHNlcnZlci1iYXNlZCBjb21wb25lbnQgYW5kIGEgcHVibGljIGJyb3dzZXItYmFzZWQg Y29tcG9uZW50KS4gSWYgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyCiAgICAgICAgICBkb2VzIG5v dCBwcm92aWRlIHN1cHBvcnQgZm9yIHN1Y2ggY2xpZW50cywgb3IgZG9lcyBub3QgcHJvdmlkZSBn dWlkYW5jZSB3aXRoIHJlZ2FyZCB0bwogICAgICAgICAgdGhlaXIgcmVnaXN0cmF0aW9uLCB0aGUg Y2xpZW50IFNIT1VMRCByZWdpc3RlciBlYWNoIGNvbXBvbmVudCBhcyBhIHNlcGFyYXRlIGNsaWVu dC4KICAgICAgICA8L3Q+CiAgICAgICAgPHQ+CiAgICAgICAgICBUaGlzIHNwZWNpZmljYXRpb24g aGFzIGJlZW4gZGVzaWduZWQgYXJvdW5kIHRoZSBmb2xsb3dpbmcgY2xpZW50IHByb2ZpbGVzOgog ICAgICAgIDwvdD4KICAgICAgICA8dD4KICAgICAgICAgIDxsaXN0IHN0eWxlPSdoYW5naW5nJz4K ICAgICAgICAgICAgPHQgaGFuZ1RleHQ9J3dlYiBhcHBsaWNhdGlvbic+CiAgICAgICAgICAgICAg PHZzcGFjZSAvPgogICAgICAgICAgICAgIEEgd2ViIGFwcGxpY2F0aW9uIGlzIGEgY29uZmlkZW50 aWFsIGNsaWVudCBydW5uaW5nIG9uIGEgd2ViIHNlcnZlci4gUmVzb3VyY2Ugb3duZXJzCiAgICAg ICAgICAgICAgYWNjZXNzIHRoZSBjbGllbnQgdmlhIGFuIEhUTUwgdXNlciBpbnRlcmZhY2UgcmVu ZGVyZWQgaW4gYSB1c2VyLWFnZW50IG9uIHRoZSBkZXZpY2UKICAgICAgICAgICAgICB1c2VkIGJ5 IHRoZSByZXNvdXJjZSBvd25lci4gVGhlIGNsaWVudCBjcmVkZW50aWFscyBhcyB3ZWxsIGFzIGFu eSBhY2Nlc3MgdG9rZW4gaXNzdWVkCiAgICAgICAgICAgICAgdG8gdGhlIGNsaWVudCBhcmUgc3Rv cmVkIG9uIHRoZSB3ZWIgc2VydmVyIGFuZCBhcmUgbm90IGV4cG9zZWQgdG8gb3IgYWNjZXNzaWJs ZSBieQogICAgICAgICAgICAgIHRoZSByZXNvdXJjZSBvd25lci4KICAgICAgICAgICAgPC90Pgog ICAgICAgICAgICA8dCBoYW5nVGV4dD0ndXNlci1hZ2VudC1iYXNlZCBhcHBsaWNhdGlvbic+CiAg ICAgICAgICAgICAgPHZzcGFjZSAvPgogICAgICAgICAgICAgIEEgdXNlci1hZ2VudC1iYXNlZCBh cHBsaWNhdGlvbiBpcyBhIHB1YmxpYyBjbGllbnQgaW4gd2hpY2ggdGhlIGNsaWVudCBjb2RlIGlz CiAgICAgICAgICAgICAgZG93bmxvYWRlZCBmcm9tIGEgd2ViIHNlcnZlciBhbmQgZXhlY3V0ZXMg d2l0aGluIGEgdXNlci1hZ2VudCAoZS5nLiB3ZWIgYnJvd3Nlcikgb24KICAgICAgICAgICAgICB0 aGUgZGV2aWNlIHVzZWQgYnkgdGhlIHJlc291cmNlIG93bmVyLiBQcm90b2NvbCBkYXRhIGFuZCBj cmVkZW50aWFscyBhcmUgZWFzaWx5CiAgICAgICAgICAgICAgYWNjZXNzaWJsZSAoYW5kIG9mdGVu IHZpc2libGUpIHRvIHRoZSByZXNvdXJjZSBvd25lci4gU2luY2Ugc3VjaCBhcHBsaWNhdGlvbnMg cmVzaWRlCiAgICAgICAgICAgICAgd2l0aGluIHRoZSB1c2VyLWFnZW50LCB0aGV5IGNhbiBtYWtl IHNlYW1sZXNzIHVzZSBvZiB0aGUgdXNlci1hZ2VudCBjYXBhYmlsaXRpZXMgd2hlbgogICAgICAg ICAgICAgIHJlcXVlc3RpbmcgYXV0aG9yaXphdGlvbi4KICAgICAgICAgICAgPC90PgogICAgICAg ICAgICA8dCBoYW5nVGV4dD0nbmF0aXZlIGFwcGxpY2F0aW9uJz4KICAgICAgICAgICAgICA8dnNw YWNlIC8+CiAgICAgICAgICAgICAgQSBuYXRpdmUgYXBwbGljYXRpb24gaXMgYSBwdWJsaWMgY2xp ZW50IGluc3RhbGxlZCBhbmQgZXhlY3V0ZWQgb24gdGhlIGRldmljZSB1c2VkIGJ5CiAgICAgICAg ICAgICAgdGhlIHJlc291cmNlIG93bmVyLiBQcm90b2NvbCBkYXRhIGFuZCBjcmVkZW50aWFscyBh cmUgYWNjZXNzaWJsZSB0byB0aGUgcmVzb3VyY2UKICAgICAgICAgICAgICBvd25lci4gSXQgaXMg YXNzdW1lZCB0aGF0IGFueSBjbGllbnQgYXV0aGVudGljYXRpb24gY3JlZGVudGlhbHMgaW5jbHVk ZWQgaW4gdGhlCiAgICAgICAgICAgICAgYXBwbGljYXRpb24gY2FuIGJlIGV4dHJhY3RlZC4gT24g dGhlIG90aGVyIGhhbmQsIGR5bmFtaWNhbGx5IGlzc3VlZCBjcmVkZW50aWFscyBzdWNoCiAgICAg ICAgICAgICAgYXMgYWNjZXNzIHRva2VucyBvciByZWZyZXNoIHRva2VucyBjYW4gcmVjZWl2ZSBh biBhY2NlcHRhYmxlIGxldmVsIG9mIHByb3RlY3Rpb24uIEF0IGEKICAgICAgICAgICAgICBtaW5p bXVtLCB0aGVzZSBjcmVkZW50aWFscyBhcmUgcHJvdGVjdGVkIGZyb20gaG9zdGlsZSBzZXJ2ZXJz IHdpdGggd2hpY2ggdGhlCiAgICAgICAgICAgICAgYXBwbGljYXRpb24gbWF5IGludGVyYWN0IHdp dGguIE9uIHNvbWUgcGxhdGZvcm1zIHRoZXNlIGNyZWRlbnRpYWxzIG1pZ2h0IGJlIHByb3RlY3Rl ZAogICAgICAgICAgICAgIGZyb20gb3RoZXIgYXBwbGljYXRpb25zIHJlc2lkaW5nIG9uIHRoZSBz YW1lIGRldmljZS4KICAgICAgICAgICAgPC90PgogICAgICAgICAgPC9saXN0PgogICAgICAgIDwv dD4KICAgICAgPC9zZWN0aW9uPgoKICAgICAgPHNlY3Rpb24gdGl0bGU9J0NsaWVudCBJZGVudGlm aWVyJyBhbmNob3I9J2NsaWVudC1pZGVudGlmaWVyJz4KICAgICAgICA8dD4KICAgICAgICAgIFRo ZSBhdXRob3JpemF0aW9uIHNlcnZlciBpc3N1ZXMgdGhlIHJlZ2lzdGVyZWQgY2xpZW50IGEgY2xp ZW50IGlkZW50aWZpZXIgLSBhIHVuaXF1ZQogICAgICAgICAgc3RyaW5nIHJlcHJlc2VudGluZyB0 aGUgcmVnaXN0cmF0aW9uIGluZm9ybWF0aW9uIHByb3ZpZGVkIGJ5IHRoZSBjbGllbnQuIFRoZSBj bGllbnQKICAgICAgICAgIGlkZW50aWZpZXIgaXMgbm90IGEgc2VjcmV0OyBpdCBpcyBleHBvc2Vk IHRvIHRoZSByZXNvdXJjZSBvd25lciwgYW5kIE1VU1QgTk9UIGJlIHVzZWQKICAgICAgICAgIGFs b25lIGZvciBjbGllbnQgYXV0aGVudGljYXRpb24uIFRoZSBjbGllbnQgaWRlbnRpZmllciBpcyB1 bmlxdWUgdG8gdGhlIGF1dGhvcml6YXRpb24KICAgICAgICAgIHNlcnZlci4KICAgICAgICA8L3Q+ CiAgICAgICAgPHQ+CiAgICAgICAgICBUaGUgY2xpZW50IGlkZW50aWZpZXIgc3RyaW5nIHNpemUg aXMgbGVmdCB1bmRlZmluZWQgYnkgdGhpcyBzcGVjaWZpY2F0aW9uLiBUaGUgY2xpZW50CiAgICAg ICAgICBzaG91bGQgYXZvaWQgbWFraW5nIGFzc3VtcHRpb25zIGFib3V0IHRoZSBpZGVudGlmaWVy IHNpemUuICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIKICAgICAgICAgIFNIT1VMRCBkb2N1bWVu dCB0aGUgc2l6ZSBvZiBhbnkgaWRlbnRpZmllciBpdCBpc3N1ZXMuCiAgICAgICAgPC90PgogICAg ICA8L3NlY3Rpb24+CgogICAgICA8c2VjdGlvbiB0aXRsZT0nQ2xpZW50IEF1dGhlbnRpY2F0aW9u JyBhbmNob3I9J2NsaWVudC1hdXRoZW50aWNhdGlvbic+CiAgICAgICAgPHQ+CiAgICAgICAgICBJ ZiB0aGUgY2xpZW50IHR5cGUgaXMgY29uZmlkZW50aWFsLCB0aGUgY2xpZW50IGFuZCBhdXRob3Jp emF0aW9uIHNlcnZlciBlc3RhYmxpc2ggYSBjbGllbnQKICAgICAgICAgIGF1dGhlbnRpY2F0aW9u IG1ldGhvZCBzdWl0YWJsZSBmb3IgdGhlIHNlY3VyaXR5IHJlcXVpcmVtZW50cyBvZiB0aGUgYXV0 aG9yaXphdGlvbiBzZXJ2ZXIuCiAgICAgICAgICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTUFZ IGFjY2VwdCBhbnkgZm9ybSBvZiBjbGllbnQgYXV0aGVudGljYXRpb24gbWVldGluZyBpdHMKICAg ICAgICAgIHNlY3VyaXR5IHJlcXVpcmVtZW50cy4KICAgICAgICA8L3Q+CiAgICAgICAgPHQ+CiAg ICAgICAgICBDb25maWRlbnRpYWwgY2xpZW50cyBhcmUgdHlwaWNhbGx5IGlzc3VlZCAob3IgZXN0 YWJsaXNoKSBhIHNldCBvZiBjbGllbnQgY3JlZGVudGlhbHMgdXNlZCBmb3IKICAgICAgICAgIGF1 dGhlbnRpY2F0aW5nIHdpdGggdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIChlLmcuIHBhc3N3b3Jk LCBwdWJsaWMvcHJpdmF0ZSBrZXkgcGFpcikuCiAgICAgICAgPC90PgogICAgICAgIDx0PgogICAg ICAgICAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIE1BWSBlc3RhYmxpc2ggYSBjbGllbnQgYXV0 aGVudGljYXRpb24gbWV0aG9kIHdpdGggcHVibGljIGNsaWVudHMuCiAgICAgICAgICBIb3dldmVy LCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVTVCBOT1QgcmVseSBvbiBwdWJsaWMgY2xpZW50 IGF1dGhlbnRpY2F0aW9uIGZvciB0aGUKICAgICAgICAgIHB1cnBvc2Ugb2YgaWRlbnRpZnlpbmcg dGhlIGNsaWVudC4KICAgICAgICA8L3Q+CiAgICAgICAgPHQ+CiAgICAgICAgICBUaGUgY2xpZW50 IE1VU1QgTk9UIHVzZSBtb3JlIHRoYW4gb25lIGF1dGhlbnRpY2F0aW9uIG1ldGhvZCBpbiBlYWNo IHJlcXVlc3QuCiAgICAgICAgPC90PgoKICAgICAgICA8c2VjdGlvbiB0aXRsZT0nQ2xpZW50IFBh c3N3b3JkJyBhbmNob3I9ImNsaWVudC1wYXNzd29yZCI+CiAgICAgICAgICA8dD4KICAgICAgICAg ICAgQ2xpZW50cyBpbiBwb3NzZXNzaW9uIG9mIGEgY2xpZW50IHBhc3N3b3JkIE1BWSB1c2UgdGhl IEhUVFAgQmFzaWMgYXV0aGVudGljYXRpb24gc2NoZW1lCiAgICAgICAgICAgIGFzIGRlZmluZWQg aW4gPHhyZWYgdGFyZ2V0PSdSRkMyNjE3JyAvPiB0byBhdXRoZW50aWNhdGUgd2l0aCB0aGUgYXV0 aG9yaXphdGlvbiBzZXJ2ZXIuCiAgICAgICAgICAgIFRoZSBjbGllbnQgaWRlbnRpZmllciBpcyBl bmNvZGVkIHVzaW5nIHRoZQoJICAgIDxzcGFueCBzdHlsZT0ndmVyYic+YXBwbGljYXRpb24veC13 d3ctZm9ybS11cmxlbmNvZGVkPC9zcGFueD4KCSAgICBjb250ZW50LXR5cGUgZW5jb2RpbmcgbWV0 aG9kIGRlZmluZWQgYnkKCSAgICBIVE1MIDQuMDEgPHhyZWYgdGFyZ2V0PSdXM0MuUkVDLWh0bWw0 MDEtMTk5OTEyMjQnIC8+IGFuZCB0aGUgZW5jb2RlZCB2YWx1ZSBpcwoJICAgIHVzZWQgYXMgdGhl IHVzZXJuYW1lOyB0aGUgY2xpZW50IHBhc3N3b3JkIGlzIHVzZWQgYXMgdGhlCiAgICAgICAgICAg IHBhc3N3b3JkLiBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVTVCBzdXBwb3J0IHRoZSBIVFRQ IEJhc2ljIGF1dGhlbnRpY2F0aW9uIHNjaGVtZQogICAgICAgICAgICBmb3IgYXV0aGVudGljYXRp bmcgY2xpZW50cyB0aGF0IHdlcmUgaXNzdWVkIGEgY2xpZW50IHBhc3N3b3JkLgogICAgICAgICAg PC90PgogICAgICAgICAgPGZpZ3VyZT4KICAgICAgICAgICAgPHByZWFtYmxlPgogICAgICAgICAg ICAgIEZvciBleGFtcGxlIChleHRyYSBsaW5lIGJyZWFrcyBhcmUgZm9yIGRpc3BsYXkgcHVycG9z ZXMgb25seSk6CiAgICAgICAgICAgIDwvcHJlYW1ibGU+CiAgICAgICAgICAgIDxhcnR3b3JrPgog ICAgICAgICAgICAgIDwhW0NEQVRBWwogIEF1dGhvcml6YXRpb246IEJhc2ljIGN6WkNhR1JTYTNG ME16bzNSbXBtY0RCYVFuSXhTM1JFVW1KdVpsWmtiVWwzCl1dPgogICAgICAgICAgICA8L2FydHdv cms+CiAgICAgICAgICA8L2ZpZ3VyZT4KICAgICAgICAgIDx0PgogICAgICAgICAgICBBbHRlcm5h dGl2ZWx5LCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTUFZIHN1cHBvcnQgaW5jbHVkaW5nIHRo ZSBjbGllbnQgY3JlZGVudGlhbHMgaW4KICAgICAgICAgICAgdGhlIHJlcXVlc3QgYm9keSB1c2lu ZyB0aGUgZm9sbG93aW5nIHBhcmFtZXRlcnM6CiAgICAgICAgICA8L3Q+CiAgICAgICAgICA8dD4K ICAgICAgICAgICAgPGxpc3Qgc3R5bGU9J2hhbmdpbmcnIGhhbmdJbmRlbnQ9JzYnPgogICAgICAg ICAgICAgIDx0IGhhbmdUZXh0PSdjbGllbnRfaWQnPgogICAgICAgICAgICAgICAgPHZzcGFjZSAv PgogICAgICAgICAgICAgICAgUkVRVUlSRUQuIFRoZSBjbGllbnQgaWRlbnRpZmllciBpc3N1ZWQg dG8gdGhlIGNsaWVudCBkdXJpbmcgdGhlIHJlZ2lzdHJhdGlvbiBwcm9jZXNzCiAgICAgICAgICAg ICAgICBkZXNjcmliZWQgYnkgPHhyZWYgdGFyZ2V0PSdjbGllbnQtaWRlbnRpZmllcicgLz4uCiAg ICAgICAgICAgICAgPC90PgogICAgICAgICAgICAgIDx0IGhhbmdUZXh0PSdjbGllbnRfc2VjcmV0 Jz4KICAgICAgICAgICAgICAgIDx2c3BhY2UgLz4KICAgICAgICAgICAgICAgIFJFUVVJUkVELiBU aGUgY2xpZW50IHNlY3JldC4gVGhlIGNsaWVudCBNQVkgb21pdCB0aGUgcGFyYW1ldGVyIGlmIHRo ZSBjbGllbnQgc2VjcmV0CiAgICAgICAgICAgICAgICBpcyBhbiBlbXB0eSBzdHJpbmcuCiAgICAg ICAgICAgICAgPC90PgogICAgICAgICAgICA8L2xpc3Q+CiAgICAgICAgICA8L3Q+CiAgICAgICAg ICA8dD4KICAgICAgICAgICAgSW5jbHVkaW5nIHRoZSBjbGllbnQgY3JlZGVudGlhbHMgaW4gdGhl IHJlcXVlc3QgYm9keSB1c2luZyB0aGUgdHdvIHBhcmFtZXRlcnMgaXMgTk9UCiAgICAgICAgICAg IFJFQ09NTUVOREVELCBhbmQgU0hPVUxEIGJlIGxpbWl0ZWQgdG8gY2xpZW50cyB1bmFibGUgdG8g ZGlyZWN0bHkgdXRpbGl6ZSB0aGUgSFRUUCBCYXNpYwogICAgICAgICAgICBhdXRoZW50aWNhdGlv biBzY2hlbWUgKG9yIG90aGVyIHBhc3N3b3JkLWJhc2VkIEhUVFAgYXV0aGVudGljYXRpb24gc2No ZW1lcykuIFRoZQogICAgICAgICAgICBwYXJhbWV0ZXJzIGNhbiBvbmx5IGJlIHRyYW5zbWl0dGVk IGluIHRoZSByZXF1ZXN0IGJvZHkgYW5kIE1VU1QgTk9UIGJlIGluY2x1ZGVkIGluIHRoZQogICAg ICAgICAgICByZXF1ZXN0IFVSSS4KICAgICAgICAgIDwvdD4KICAgICAgICAgIDxmaWd1cmU+CiAg ICAgICAgICAgIDxwcmVhbWJsZT4KICAgICAgICAgICAgICBGb3IgZXhhbXBsZSwgcmVxdWVzdGlu ZyB0byByZWZyZXNoIGFuIGFjY2VzcyB0b2tlbiAoPHhyZWYgdGFyZ2V0PSd0b2tlbi1yZWZyZXNo JyAvPikKICAgICAgICAgICAgICB1c2luZyB0aGUgYm9keSBwYXJhbWV0ZXJzIChleHRyYSBsaW5l IGJyZWFrcyBhcmUgZm9yIGRpc3BsYXkgcHVycG9zZXMgb25seSk6CiAgICAgICAgICAgIDwvcHJl YW1ibGU+CiAgICAgICAgICAgIDxhcnR3b3JrPgogICAgICAgICAgICAgIDwhW0NEQVRBWwogIFBP U1QgL3Rva2VuIEhUVFAvMS4xCiAgSG9zdDogc2VydmVyLmV4YW1wbGUuY29tCiAgQ29udGVudC1U eXBlOiBhcHBsaWNhdGlvbi94LXd3dy1mb3JtLXVybGVuY29kZWQ7Y2hhcnNldD1VVEYtOAoKICBn cmFudF90eXBlPXJlZnJlc2hfdG9rZW4mcmVmcmVzaF90b2tlbj10R3p2M0pPa0YwWEc1UXgyVGxL V0lBCiAgJmNsaWVudF9pZD1zNkJoZFJrcXQzJmNsaWVudF9zZWNyZXQ9N0ZqZnAwWkJyMUt0RFJi bmZWZG1JdwpdXT4KICAgICAgICAgICAgPC9hcnR3b3JrPgogICAgICAgICAgPC9maWd1cmU+CiAg ICAgICAgICA8dD4KICAgICAgICAgICAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIE1VU1QgcmVx dWlyZSB0aGUgdXNlIG9mIFRMUyBhcyBkZXNjcmliZWQgaW4KICAgICAgICAgICAgPHhyZWYgdGFy Z2V0PSd0bHMnIC8+IHdoZW4gc2VuZGluZyByZXF1ZXN0cyB1c2luZyBwYXNzd29yZCBhdXRoZW50 aWNhdGlvbi4KICAgICAgICAgIDwvdD4KICAgICAgICAgIDx0PgogICAgICAgICAgICBTaW5jZSB0 aGlzIGNsaWVudCBhdXRoZW50aWNhdGlvbiBtZXRob2QgaW52b2x2ZXMgYSBwYXNzd29yZCwgdGhl IGF1dGhvcml6YXRpb24gc2VydmVyCiAgICAgICAgICAgIE1VU1QgcHJvdGVjdCBhbnkgZW5kcG9p bnQgdXRpbGl6aW5nIGl0IGFnYWluc3QgYnJ1dGUgZm9yY2UgYXR0YWNrcy4KICAgICAgICAgIDwv dD4KICAgICAgICA8L3NlY3Rpb24+CgogICAgICAgIDxzZWN0aW9uIHRpdGxlPSdPdGhlciBBdXRo ZW50aWNhdGlvbiBNZXRob2RzJz4KICAgICAgICAgIDx0PgogICAgICAgICAgICBUaGUgYXV0aG9y aXphdGlvbiBzZXJ2ZXIgTUFZIHN1cHBvcnQgYW55IHN1aXRhYmxlIEhUVFAgYXV0aGVudGljYXRp b24gc2NoZW1lIG1hdGNoaW5nCiAgICAgICAgICAgIGl0cyBzZWN1cml0eSByZXF1aXJlbWVudHMu IFdoZW4gdXNpbmcgb3RoZXIgYXV0aGVudGljYXRpb24gbWV0aG9kcywgdGhlIGF1dGhvcml6YXRp b24KICAgICAgICAgICAgc2VydmVyIE1VU1QgZGVmaW5lIGEgbWFwcGluZyBiZXR3ZWVuIHRoZSBj bGllbnQgaWRlbnRpZmllciAocmVnaXN0cmF0aW9uIHJlY29yZCkgYW5kCiAgICAgICAgICAgIGF1 dGhlbnRpY2F0aW9uIHNjaGVtZS4KICAgICAgICAgIDwvdD4KICAgICAgICA8L3NlY3Rpb24+Cgog ICAgICA8L3NlY3Rpb24+CgogICAgICA8c2VjdGlvbiB0aXRsZT0nVW5yZWdpc3RlcmVkIENsaWVu dHMnPgogICAgICAgIDx0PgogICAgICAgICAgVGhpcyBzcGVjaWZpY2F0aW9uIGRvZXMgbm90IGV4 Y2x1ZGUgdGhlIHVzZSBvZiB1bnJlZ2lzdGVyZWQgY2xpZW50cy4gSG93ZXZlciwgdGhlIHVzZQog ICAgICAgICAgd2l0aCBzdWNoIGNsaWVudHMgaXMgYmV5b25kIHRoZSBzY29wZSBvZiB0aGlzIHNw ZWNpZmljYXRpb24sIGFuZCByZXF1aXJlcyBhZGRpdGlvbmFsCiAgICAgICAgICBzZWN1cml0eSBh bmFseXNpcyBhbmQgcmV2aWV3IG9mIGl0cyBpbnRlcm9wZXJhYmlsaXR5IGltcGFjdC4KICAgICAg ICA8L3Q+CiAgICAgIDwvc2VjdGlvbj4KICAgICAgCiAgICA8L3NlY3Rpb24+CgogICAgPHNlY3Rp b24gdGl0bGU9J1Byb3RvY29sIEVuZHBvaW50cyc+CiAgICAgIDx0PgogICAgICAgIFRoZSBhdXRo b3JpemF0aW9uIHByb2Nlc3MgdXRpbGl6ZXMgdHdvIGF1dGhvcml6YXRpb24gc2VydmVyIGVuZHBv aW50cyAoSFRUUCByZXNvdXJjZXMpOgogICAgICA8L3Q+CiAgICAgIDx0PgogICAgICAgIDxsaXN0 IHN0eWxlPSdzeW1ib2xzJz4KICAgICAgICAgIDx0PgogICAgICAgICAgICBBdXRob3JpemF0aW9u IGVuZHBvaW50IC0gdXNlZCBieSB0aGUgY2xpZW50IHRvIG9idGFpbiBhdXRob3JpemF0aW9uIGZy b20gdGhlIHJlc291cmNlCiAgICAgICAgICAgIG93bmVyIHZpYSB1c2VyLWFnZW50IHJlZGlyZWN0 aW9uLgogICAgICAgICAgPC90PgogICAgICAgICAgPHQ+CiAgICAgICAgICAgIFRva2VuIGVuZHBv aW50IC0gdXNlZCBieSB0aGUgY2xpZW50IHRvIGV4Y2hhbmdlIGFuIGF1dGhvcml6YXRpb24gZ3Jh bnQgZm9yIGFuIGFjY2VzcwogICAgICAgICAgICB0b2tlbiwgdHlwaWNhbGx5IHdpdGggY2xpZW50 IGF1dGhlbnRpY2F0aW9uLgogICAgICAgICAgPC90PgogICAgICAgIDwvbGlzdD4KICAgICAgPC90 PgogICAgICA8dD4KICAgICAgICBBcyB3ZWxsIGFzIG9uZSBjbGllbnQgZW5kcG9pbnQ6CiAgICAg IDwvdD4KICAgICAgPHQ+CiAgICAgICAgPGxpc3Qgc3R5bGU9J3N5bWJvbHMnPgogICAgICAgICAg PHQ+CiAgICAgICAgICAgIFJlZGlyZWN0aW9uIGVuZHBvaW50IC0gdXNlZCBieSB0aGUgYXV0aG9y aXphdGlvbiBzZXJ2ZXIgdG8gcmV0dXJuIGF1dGhvcml6YXRpb24KICAgICAgICAgICAgY3JlZGVu dGlhbHMgcmVzcG9uc2VzIHRvIHRoZSBjbGllbnQgdmlhIHRoZSByZXNvdXJjZSBvd25lciB1c2Vy LWFnZW50LgogICAgICAgICAgPC90PgogICAgICAgIDwvbGlzdD4KICAgICAgPC90PgogICAgICA8 dD4KICAgICAgICBOb3QgZXZlcnkgYXV0aG9yaXphdGlvbiBncmFudCB0eXBlIHV0aWxpemVzIGJv dGggZW5kcG9pbnRzLiBFeHRlbnNpb24gZ3JhbnQgdHlwZXMgTUFZCiAgICAgICAgZGVmaW5lIGFk ZGl0aW9uYWwgZW5kcG9pbnRzIGFzIG5lZWRlZC4KICAgICAgPC90PgoKICAgICAgPHNlY3Rpb24g dGl0bGU9J0F1dGhvcml6YXRpb24gRW5kcG9pbnQnPgogICAgICAgIDx0PgogICAgICAgICAgVGhl IGF1dGhvcml6YXRpb24gZW5kcG9pbnQgaXMgdXNlZCB0byBpbnRlcmFjdCB3aXRoIHRoZSByZXNv dXJjZSBvd25lciBhbmQgb2J0YWluCiAgICAgICAgICBhbiBhdXRob3JpemF0aW9uIGdyYW50LiBU aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVTVCBmaXJzdCB2ZXJpZnkgdGhlIGlkZW50aXR5IG9m IHRoZQogICAgICAgICAgcmVzb3VyY2Ugb3duZXIuIFRoZSB3YXkgaW4gd2hpY2ggdGhlIGF1dGhv cml6YXRpb24gc2VydmVyIGF1dGhlbnRpY2F0ZXMgdGhlIHJlc291cmNlCiAgICAgICAgICBvd25l ciAoZS5nLiB1c2VybmFtZSBhbmQgcGFzc3dvcmQgbG9naW4sIHNlc3Npb24gY29va2llcykgaXMg YmV5b25kIHRoZSBzY29wZSBvZiB0aGlzCiAgICAgICAgICBzcGVjaWZpY2F0aW9uLgogICAgICAg IDwvdD4KICAgICAgICA8dD4KICAgICAgICAgIFRoZSBtZWFucyB0aHJvdWdoIHdoaWNoIHRoZSBj bGllbnQgb2J0YWlucyB0aGUgbG9jYXRpb24gb2YgdGhlIGF1dGhvcml6YXRpb24gZW5kcG9pbnQg YXJlCiAgICAgICAgICBiZXlvbmQgdGhlIHNjb3BlIG9mIHRoaXMgc3BlY2lmaWNhdGlvbiwgYnV0 IHRoZSBsb2NhdGlvbiBpcyB0eXBpY2FsbHkgcHJvdmlkZWQgaW4gdGhlCiAgICAgICAgICBzZXJ2 aWNlIGRvY3VtZW50YXRpb24uCiAgICAgICAgPC90PgogICAgICAgIDx0PgogICAgICAgICAgVGhl IGVuZHBvaW50IFVSSSBNQVkgaW5jbHVkZSBhbgogICAgICAgICAgPHNwYW54IHN0eWxlPSd2ZXJi Jz5hcHBsaWNhdGlvbi94LXd3dy1mb3JtLXVybGVuY29kZWQ8L3NwYW54PiBmb3JtYXR0ZWQKICAg ICAgICAgICg8eHJlZiB0YXJnZXQ9J1czQy5SRUMtaHRtbDQwMS0xOTk5MTIyNCcgLz4pIHF1ZXJ5 IGNvbXBvbmVudCAoPHhyZWYgdGFyZ2V0PSdSRkMzOTg2JyAvPgogICAgICAgICAgc2VjdGlvbiAz LjQpLCB3aGljaCBNVVNUIGJlIHJldGFpbmVkIHdoZW4gYWRkaW5nIGFkZGl0aW9uYWwgcXVlcnkg cGFyYW1ldGVycy4gVGhlCiAgICAgICAgICBlbmRwb2ludCBVUkkgTVVTVCBOT1QgaW5jbHVkZSBh IGZyYWdtZW50IGNvbXBvbmVudC4KICAgICAgICA8L3Q+CiAgICAgICAgPHQ+CiAgICAgICAgICBT aW5jZSByZXF1ZXN0cyB0byB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludCByZXN1bHQgaW4gdXNl ciBhdXRoZW50aWNhdGlvbiBhbmQgdGhlCiAgICAgICAgICB0cmFuc21pc3Npb24gb2YgY2xlYXIt dGV4dCBjcmVkZW50aWFscyAoaW4gdGhlIEhUVFAgcmVzcG9uc2UpLCB0aGUgYXV0aG9yaXphdGlv biBzZXJ2ZXIKICAgICAgICAgIE1VU1QgcmVxdWlyZSB0aGUgdXNlIG9mIFRMUyBhcyBkZXNjcmli ZWQgaW4gPHhyZWYgdGFyZ2V0PSd0bHMnIC8+IHdoZW4gc2VuZGluZyByZXF1ZXN0cwogICAgICAg ICAgdG8gdGhlIGF1dGhvcml6YXRpb24gZW5kcG9pbnQuCiAgICAgICAgPC90PgogICAgICAgIDx0 PgogICAgICAgICAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIE1VU1Qgc3VwcG9ydCB0aGUgdXNl IG9mIHRoZSBIVFRQIDxzcGFueCBzdHlsZT0ndmVyYic+R0VUPC9zcGFueD4KICAgICAgICAgIG1l dGhvZCA8eHJlZiB0YXJnZXQ9J1JGQzI2MTYnIC8+IGZvciB0aGUgYXV0aG9yaXphdGlvbiBlbmRw b2ludCwgYW5kIE1BWSBzdXBwb3J0IHRoZSB1c2UKICAgICAgICAgIG9mIHRoZSA8c3Bhbnggc3R5 bGU9J3ZlcmInPlBPU1Q8L3NwYW54PiBtZXRob2QgYXMgd2VsbC4KICAgICAgICA8L3Q+CiAgICAg ICAgPHQ+CiAgICAgICAgICBQYXJhbWV0ZXJzIHNlbnQgd2l0aG91dCBhIHZhbHVlIE1VU1QgYmUg dHJlYXRlZCBhcyBpZiB0aGV5IHdlcmUgb21pdHRlZCBmcm9tIHRoZSByZXF1ZXN0LgogICAgICAg ICAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIE1VU1QgaWdub3JlIHVucmVjb2duaXplZCByZXF1 ZXN0IHBhcmFtZXRlcnMuIFJlcXVlc3QgYW5kCiAgICAgICAgICByZXNwb25zZSBwYXJhbWV0ZXJz IE1VU1QgTk9UIGJlIGluY2x1ZGVkIG1vcmUgdGhhbiBvbmNlLgogICAgICAgIDwvdD4KCiAgICAg ICAgPHNlY3Rpb24gdGl0bGU9J1Jlc3BvbnNlIFR5cGUnIGFuY2hvcj0icmVzcG9uc2UtdHlwZSI+ CiAgICAgICAgICA8dD4KICAgICAgICAgICAgVGhlIGF1dGhvcml6YXRpb24gZW5kcG9pbnQgaXMg dXNlZCBieSB0aGUgYXV0aG9yaXphdGlvbiBjb2RlIGdyYW50IHR5cGUgYW5kIGltcGxpY2l0CiAg ICAgICAgICAgIGdyYW50IHR5cGUgZmxvd3MuIFRoZSBjbGllbnQgaW5mb3JtcyB0aGUgYXV0aG9y aXphdGlvbiBzZXJ2ZXIgb2YgdGhlIGRlc2lyZWQgZ3JhbnQKICAgICAgICAgICAgdHlwZSB1c2lu ZyB0aGUgZm9sbG93aW5nIHBhcmFtZXRlcjoKICAgICAgICAgIDwvdD4KICAgICAgICAgIDx0Pgog ICAgICAgICAgICA8bGlzdCBzdHlsZT0naGFuZ2luZycgaGFuZ0luZGVudD0nNic+CiAgICAgICAg ICAgICAgPHQgaGFuZ1RleHQ9J3Jlc3BvbnNlX3R5cGUnPgogICAgICAgICAgICAgICAgPHZzcGFj ZSAvPgogICAgICAgICAgICAgICAgUkVRVUlSRUQuIFRoZSB2YWx1ZSBNVVNUIGJlIG9uZSBvZiA8 c3Bhbnggc3R5bGU9J3ZlcmInPmNvZGU8L3NwYW54PiBmb3IgcmVxdWVzdGluZwogICAgICAgICAg ICAgICAgYW4gYXV0aG9yaXphdGlvbiBjb2RlIGFzIGRlc2NyaWJlZCBieSA8eHJlZiB0YXJnZXQ9 J2NvZGUtYXV0aHotcmVxJyAvPiwKICAgICAgICAgICAgICAgIDxzcGFueCBzdHlsZT0ndmVyYic+ dG9rZW48L3NwYW54PiBmb3IgcmVxdWVzdGluZyBhbiBhY2Nlc3MgdG9rZW4gKGltcGxpY2l0IGdy YW50KQogICAgICAgICAgICAgICAgYXMgZGVzY3JpYmVkIGJ5IDx4cmVmIHRhcmdldD0naW1wbGlj aXQtYXV0aHotcmVxJyAvPiwgb3IgYSByZWdpc3RlcmVkIGV4dGVuc2lvbgogICAgICAgICAgICAg ICAgdmFsdWUgYXMgZGVzY3JpYmVkIGJ5IDx4cmVmIHRhcmdldD0ncmVzcG9uc2UtdHlwZS1leHQn IC8+LgogICAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAgPC9saXN0PgogICAgICAgICAgPC90 PgogICAgICAgICAgPHQ+CiAgICAgICAgICAgIEV4dGVuc2lvbiByZXNwb25zZSB0eXBlcyBNQVkg Y29udGFpbiBhIHNwYWNlLWRlbGltaXRlZCAoJXgyMCkgbGlzdCBvZiB2YWx1ZXMsIHdoZXJlIHRo ZQogICAgICAgICAgICBvcmRlciBvZiB2YWx1ZXMgZG9lcyBub3QgbWF0dGVyIChlLmcuIHJlc3Bv bnNlIHR5cGUgPHNwYW54IHN0eWxlPSd2ZXJiJz5hIGI8L3NwYW54PiBpcwogICAgICAgICAgICB0 aGUgc2FtZSBhcyA8c3Bhbnggc3R5bGU9J3ZlcmInPmIgYTwvc3Bhbng+KS4gVGhlIG1lYW5pbmcg b2Ygc3VjaCBjb21wb3NpdGUgcmVzcG9uc2UKICAgICAgICAgICAgdHlwZXMgaXMgZGVmaW5lZCBi eSB0aGVpciByZXNwZWN0aXZlIHNwZWNpZmljYXRpb25zLgogICAgICAgICAgPC90PgogICAgICAg ICAgPHQ+CiAgICAgICAgICAgIElmIGFuIGF1dGhvcml6YXRpb24gcmVxdWVzdCBpcyBtaXNzaW5n IHRoZSA8c3Bhbnggc3R5bGU9J3ZlcmInPnJlc3BvbnNlX3R5cGU8L3NwYW54PgogICAgICAgICAg ICBwYXJhbWV0ZXIsIG9yIGlmIHRoZSByZXNwb25zZSB0eXBlIGlzIG5vdCB1bmRlcnN0b29kLCB0 aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVTVAogICAgICAgICAgICByZXR1cm4gYW4gZXJyb3Ig cmVzcG9uc2UgYXMgZGVzY3JpYmVkIGluIDx4cmVmIHRhcmdldD0nY29kZS1hdXRoei1lcnJvcicg Lz4uCiAgICAgICAgICA8L3Q+CiAgICAgICAgPC9zZWN0aW9uPgoKICAgICAgICA8c2VjdGlvbiB0 aXRsZT0nUmVkaXJlY3Rpb24gRW5kcG9pbnQnIGFuY2hvcj0ncmVkaXJlY3QtdXJpJz4KICAgICAg ICAgIDx0PgogICAgICAgICAgICBBZnRlciBjb21wbGV0aW5nIGl0cyBpbnRlcmFjdGlvbiB3aXRo IHRoZSByZXNvdXJjZSBvd25lciwgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyCiAgICAgICAgICAg IGRpcmVjdHMgdGhlIHJlc291cmNlIG93bmVyJ3MgdXNlci1hZ2VudCBiYWNrIHRvIHRoZSBjbGll bnQuIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlcgogICAgICAgICAgICByZWRpcmVjdHMgdGhlIHVz ZXItYWdlbnQgdG8gdGhlIGNsaWVudCdzIHJlZGlyZWN0aW9uIGVuZHBvaW50IHByZXZpb3VzbHkg ZXN0YWJsaXNoZWQKICAgICAgICAgICAgd2l0aCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgZHVy aW5nIHRoZSBjbGllbnQgcmVnaXN0cmF0aW9uIHByb2Nlc3Mgb3Igd2hlbiBtYWtpbmcKICAgICAg ICAgICAgdGhlIGF1dGhvcml6YXRpb24gcmVxdWVzdC4KICAgICAgICAgIDwvdD4KICAgICAgICAg IDx0PgogICAgICAgICAgICBUaGUgcmVkaXJlY3Rpb24gZW5kcG9pbnQgVVJJIE1VU1QgYmUgYW4g YWJzb2x1dGUgVVJJIGFzIGRlZmluZWQgYnkKICAgICAgICAgICAgPHhyZWYgdGFyZ2V0PSdSRkMz OTg2JyAvPiBzZWN0aW9uIDQuMy4gVGhlIGVuZHBvaW50IFVSSSBNQVkgaW5jbHVkZSBhbgogICAg ICAgICAgICA8c3Bhbnggc3R5bGU9J3ZlcmInPmFwcGxpY2F0aW9uL3gtd3d3LWZvcm0tdXJsZW5j b2RlZDwvc3Bhbng+IGZvcm1hdHRlZAogICAgICAgICAgICAoPHhyZWYgdGFyZ2V0PSdXM0MuUkVD LWh0bWw0MDEtMTk5OTEyMjQnIC8+KSBxdWVyeSBjb21wb25lbnQgKDx4cmVmIHRhcmdldD0nUkZD Mzk4NicgLz4KICAgICAgICAgICAgc2VjdGlvbiAzLjQpLCB3aGljaCBNVVNUIGJlIHJldGFpbmVk IHdoZW4gYWRkaW5nIGFkZGl0aW9uYWwgcXVlcnkgcGFyYW1ldGVycy4gVGhlCiAgICAgICAgICAg IGVuZHBvaW50IFVSSSBNVVNUIE5PVCBpbmNsdWRlIGEgZnJhZ21lbnQgY29tcG9uZW50LgogICAg ICAgICAgPC90PgoKICAgICAgICAgIDxzZWN0aW9uIHRpdGxlPSdFbmRwb2ludCBSZXF1ZXN0IENv bmZpZGVudGlhbGl0eSc+CiAgICAgICAgICAgIDx0PgogICAgICAgICAgICAgIFRoZSByZWRpcmVj dGlvbiBlbmRwb2ludCBTSE9VTEQgcmVxdWlyZSB0aGUgdXNlIG9mIFRMUyBhcyBkZXNjcmliZWQg aW4KICAgICAgICAgICAgICA8eHJlZiB0YXJnZXQ9J3RscycgLz4gd2hlbiB0aGUgcmVxdWVzdGVk IHJlc3BvbnNlIHR5cGUgaXMKICAgICAgICAgICAgICA8c3Bhbnggc3R5bGU9J3ZlcmInPmNvZGU8 L3NwYW54PiBvciA8c3Bhbnggc3R5bGU9J3ZlcmInPnRva2VuPC9zcGFueD4sIG9yCiAgICAgICAg ICAgICAgd2hlbiB0aGUgcmVkaXJlY3Rpb24gcmVxdWVzdCB3aWxsIHJlc3VsdCBpbiB0aGUgdHJh bnNtaXNzaW9uIG9mIHNlbnNpdGl2ZSBjcmVkZW50aWFscwogICAgICAgICAgICAgIG92ZXIgYW4g b3BlbiBuZXR3b3JrLiBUaGlzIHNwZWNpZmljYXRpb24gZG9lcyBub3QgbWFuZGF0ZSB0aGUgdXNl IG9mIFRMUyBiZWNhdXNlIGF0CiAgICAgICAgICAgICAgdGhlIHRpbWUgb2YgdGhpcyB3cml0aW5n LCByZXF1aXJpbmcgY2xpZW50cyB0byBkZXBsb3kgVExTIGlzIGEgc2lnbmlmaWNhbnQgaHVyZGxl IGZvcgogICAgICAgICAgICAgIG1hbnkgY2xpZW50IGRldmVsb3BlcnMuIElmIFRMUyBpcyBub3Qg YXZhaWxhYmxlLCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgU0hPVUxEIHdhcm4KICAgICAgICAg ICAgICB0aGUgcmVzb3VyY2Ugb3duZXIgYWJvdXQgdGhlIGluc2VjdXJlIGVuZHBvaW50IHByaW9y IHRvIHJlZGlyZWN0aW9uIChlLmcuIGRpc3BsYXkgYQogICAgICAgICAgICAgIG1lc3NhZ2UgZHVy aW5nIHRoZSBhdXRob3JpemF0aW9uIHJlcXVlc3QpLgogICAgICAgICAgICA8L3Q+CiAgICAgICAg ICAgIDx0PgogICAgICAgICAgICAgIExhY2sgb2YgdHJhbnNwb3J0LWxheWVyIHNlY3VyaXR5IGNh biBoYXZlIGEgc2V2ZXJlIGltcGFjdCBvbiB0aGUgc2VjdXJpdHkgb2YgdGhlCiAgICAgICAgICAg ICAgY2xpZW50IGFuZCB0aGUgcHJvdGVjdGVkIHJlc291cmNlcyBpdCBpcyBhdXRob3JpemVkIHRv IGFjY2Vzcy4gVGhlIHVzZSBvZgogICAgICAgICAgICAgIHRyYW5zcG9ydC1sYXllciBzZWN1cml0 eSBpcyBwYXJ0aWN1bGFybHkgY3JpdGljYWwgd2hlbiB0aGUgYXV0aG9yaXphdGlvbiBwcm9jZXNz IGlzCiAgICAgICAgICAgICAgdXNlZCBhcyBhIGZvcm0gb2YgZGVsZWdhdGVkIGVuZC11c2VyIGF1 dGhlbnRpY2F0aW9uIGJ5IHRoZSBjbGllbnQgKGUuZy4gdGhpcmQtcGFydHkKICAgICAgICAgICAg ICBzaWduLWluIHNlcnZpY2UpLgogICAgICAgICAgICA8L3Q+CiAgICAgICAgICA8L3NlY3Rpb24+ CgogICAgICAgICAgPHNlY3Rpb24gdGl0bGU9J1JlZ2lzdHJhdGlvbiBSZXF1aXJlbWVudHMnPgog ICAgICAgICAgICA8dD4KICAgICAgICAgICAgICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVT VCByZXF1aXJlIHRoZSBmb2xsb3dpbmcgY2xpZW50cyB0byByZWdpc3RlciB0aGVpcgogICAgICAg ICAgICAgIHJlZGlyZWN0aW9uIGVuZHBvaW50OgogICAgICAgICAgICA8L3Q+CiAgICAgICAgICAg IDx0PgogICAgICAgICAgICAgIDxsaXN0IHN0eWxlPSdzeW1ib2xzJz4KICAgICAgICAgICAgICAg IDx0PgogICAgICAgICAgICAgICAgICBQdWJsaWMgY2xpZW50cy4KICAgICAgICAgICAgICAgIDwv dD4KICAgICAgICAgICAgICAgIDx0PgogICAgICAgICAgICAgICAgICBDb25maWRlbnRpYWwgY2xp ZW50cyB1dGlsaXppbmcgdGhlIGltcGxpY2l0IGdyYW50IHR5cGUuCiAgICAgICAgICAgICAgICA8 L3Q+CiAgICAgICAgICAgICAgPC9saXN0PgogICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgIDx0 PgogICAgICAgICAgICAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBTSE9VTEQgcmVxdWlyZSBh bGwgY2xpZW50cyB0byByZWdpc3RlciB0aGVpciByZWRpcmVjdGlvbgogICAgICAgICAgICAgIGVu ZHBvaW50IHByaW9yIHRvIHV0aWxpemluZyB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludC4KICAg ICAgICAgICAgPC90PgogICAgICAgICAgICA8dD4KICAgICAgICAgICAgICBUaGUgYXV0aG9yaXph dGlvbiBzZXJ2ZXIgU0hPVUxEIHJlcXVpcmUgdGhlIGNsaWVudCB0byBwcm92aWRlIHRoZSBjb21w bGV0ZQogICAgICAgICAgICAgIHJlZGlyZWN0aW9uIFVSSSAodGhlIGNsaWVudCBNQVkgdXNlIHRo ZSA8c3Bhbnggc3R5bGU9J3ZlcmInPnN0YXRlPC9zcGFueD4gcmVxdWVzdAogICAgICAgICAgICAg IHBhcmFtZXRlciB0byBhY2hpZXZlIHBlci1yZXF1ZXN0IGN1c3RvbWl6YXRpb24pLiBJZiByZXF1 aXJpbmcgdGhlIHJlZ2lzdHJhdGlvbiBvZgogICAgICAgICAgICAgIHRoZSBjb21wbGV0ZSByZWRp cmVjdGlvbiBVUkkgaXMgbm90IHBvc3NpYmxlLCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgU0hP VUxEIHJlcXVpcmUKICAgICAgICAgICAgICB0aGUgcmVnaXN0cmF0aW9uIG9mIHRoZSBVUkkgc2No ZW1lLCBhdXRob3JpdHksIGFuZCBwYXRoIChhbGxvd2luZyB0aGUgY2xpZW50IHRvCiAgICAgICAg ICAgICAgZHluYW1pY2FsbHkgdmFyeSBvbmx5IHRoZSBxdWVyeSBjb21wb25lbnQgb2YgdGhlIHJl ZGlyZWN0aW9uIFVSSSB3aGVuIHJlcXVlc3RpbmcKICAgICAgICAgICAgICBhdXRob3JpemF0aW9u KS4KICAgICAgICAgICAgPC90PgogICAgICAgICAgICA8dD4KICAgICAgICAgICAgICBUaGUgYXV0 aG9yaXphdGlvbiBzZXJ2ZXIgTUFZIGFsbG93IHRoZSBjbGllbnQgdG8gcmVnaXN0ZXIgbXVsdGlw bGUgcmVkaXJlY3Rpb24KICAgICAgICAgICAgICBlbmRwb2ludHMuCiAgICAgICAgICAgIDwvdD4K ICAgICAgICAgICAgPHQ+CiAgICAgICAgICAgICAgTGFjayBvZiBhIHJlZGlyZWN0aW9uIFVSSSBy ZWdpc3RyYXRpb24gcmVxdWlyZW1lbnQgY2FuIGVuYWJsZSBhbiBhdHRhY2tlciB0byB1c2UKICAg ICAgICAgICAgICB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludCBhcyBvcGVuIHJlZGlyZWN0b3Ig YXMgZGVzY3JpYmVkIGluCiAgICAgICAgICAgICAgPHhyZWYgdGFyZ2V0PSdvcGVuLXJlZGlyZWN0 JyAvPi4KICAgICAgICAgICAgPC90PgogICAgICAgICAgPC9zZWN0aW9uPgoKICAgICAgICAgIDxz ZWN0aW9uIHRpdGxlPSdEeW5hbWljIENvbmZpZ3VyYXRpb24nPgogICAgICAgICAgICA8dD4KICAg ICAgICAgICAgICBJZiBtdWx0aXBsZSByZWRpcmVjdGlvbiBVUklzIGhhdmUgYmVlbiByZWdpc3Rl cmVkLCBpZiBvbmx5IHBhcnQgb2YgdGhlIHJlZGlyZWN0aW9uCiAgICAgICAgICAgICAgVVJJIGhh cyBiZWVuIHJlZ2lzdGVyZWQsIG9yIGlmIG5vIHJlZGlyZWN0aW9uIFVSSSBoYXMgYmVlbiByZWdp c3RlcmVkLCB0aGUgY2xpZW50CiAgICAgICAgICAgICAgTVVTVCBpbmNsdWRlIGEgcmVkaXJlY3Rp b24gVVJJIHdpdGggdGhlIGF1dGhvcml6YXRpb24gcmVxdWVzdCB1c2luZyB0aGUKICAgICAgICAg ICAgICA8c3Bhbnggc3R5bGU9J3ZlcmInPnJlZGlyZWN0X3VyaTwvc3Bhbng+IHJlcXVlc3QgcGFy YW1ldGVyLgogICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgIDx0PgogICAgICAgICAgICAgIFdo ZW4gYSByZWRpcmVjdGlvbiBVUkkgaXMgaW5jbHVkZWQgaW4gYW4gYXV0aG9yaXphdGlvbiByZXF1 ZXN0LCB0aGUgYXV0aG9yaXphdGlvbgogICAgICAgICAgICAgIHNlcnZlciBNVVNUIGNvbXBhcmUg YW5kIG1hdGNoIHRoZSB2YWx1ZSByZWNlaXZlZCBhZ2FpbnN0IGF0IGxlYXN0IG9uZSBvZiB0aGUK ICAgICAgICAgICAgICByZWdpc3RlcmVkIHJlZGlyZWN0aW9uIFVSSXMgKG9yIFVSSSBjb21wb25l bnRzKSBhcyBkZWZpbmVkIGluCiAgICAgICAgICAgICAgPHhyZWYgdGFyZ2V0PSdSRkMzOTg2JyAv PiBzZWN0aW9uIDYsIGlmIGFueSByZWRpcmVjdGlvbiBVUklzIHdlcmUgcmVnaXN0ZXJlZC4KICAg ICAgICAgICAgICBJZiB0aGUgY2xpZW50IHJlZ2lzdHJhdGlvbiBpbmNsdWRlZCB0aGUgZnVsbCBy ZWRpcmVjdGlvbiBVUkksIHRoZSBhdXRob3JpemF0aW9uCiAgICAgICAgICAgICAgc2VydmVyIE1V U1QgY29tcGFyZSB0aGUgdHdvIFVSSXMgdXNpbmcgc2ltcGxlIHN0cmluZyBjb21wYXJpc29uIGFz IGRlZmluZWQKICAgICAgICAgICAgICBpbiA8eHJlZiB0YXJnZXQ9J1JGQzM5ODYnIC8+IHNlY3Rp b24gNi4yLjEuCiAgICAgICAgICAgIDwvdD4KICAgICAgICAgPC9zZWN0aW9uPgoKICAgICAgICAg IDxzZWN0aW9uIHRpdGxlPSdJbnZhbGlkIEVuZHBvaW50Jz4KICAgICAgICAgICAgPHQ+CiAgICAg ICAgICAgICAgSWYgYW4gYXV0aG9yaXphdGlvbiByZXF1ZXN0IGZhaWxzIHZhbGlkYXRpb24gZHVl IHRvIGEgbWlzc2luZywgaW52YWxpZCwgb3IKICAgICAgICAgICAgICBtaXNtYXRjaGluZyByZWRp cmVjdGlvbiBVUkksIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBTSE9VTEQgaW5mb3JtIHRoZSBy ZXNvdXJjZQogICAgICAgICAgICAgIG93bmVyIG9mIHRoZSBlcnJvciwgYW5kIE1VU1QgTk9UIGF1 dG9tYXRpY2FsbHkgcmVkaXJlY3QgdGhlIHVzZXItYWdlbnQgdG8gdGhlIGludmFsaWQKICAgICAg ICAgICAgICByZWRpcmVjdGlvbiBVUkkuCiAgICAgICAgICAgIDwvdD4KICAgICAgICAgIDwvc2Vj dGlvbj4KCiAgICAgICAgICA8c2VjdGlvbiB0aXRsZT0nRW5kcG9pbnQgQ29udGVudCc+CiAgICAg ICAgICAgIDx0PgogICAgICAgICAgICAgIFRoZSByZWRpcmVjdGlvbiByZXF1ZXN0IHRvIHRoZSBj bGllbnQncyBlbmRwb2ludCB0eXBpY2FsbHkgcmVzdWx0cyBpbiBhbiBIVE1MCiAgICAgICAgICAg ICAgZG9jdW1lbnQgcmVzcG9uc2UsIHByb2Nlc3NlZCBieSB0aGUgdXNlci1hZ2VudC4gSWYgdGhl IEhUTUwgcmVzcG9uc2UgaXMgc2VydmVkCiAgICAgICAgICAgICAgZGlyZWN0bHkgYXMgdGhlIHJl c3VsdCBvZiB0aGUgcmVkaXJlY3Rpb24gcmVxdWVzdCwgYW55IHNjcmlwdCBpbmNsdWRlZCBpbiB0 aGUgSFRNTAogICAgICAgICAgICAgIGRvY3VtZW50IHdpbGwgZXhlY3V0ZSB3aXRoIGZ1bGwgYWNj ZXNzIHRvIHRoZSByZWRpcmVjdGlvbiBVUkkgYW5kIHRoZSBjcmVkZW50aWFscyBpdAogICAgICAg ICAgICAgIGNvbnRhaW5zLgogICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgIDx0PgogICAgICAg ICAgICAgIFRoZSBjbGllbnQgU0hPVUxEIE5PVCBpbmNsdWRlIGFueSB0aGlyZC1wYXJ0eSBzY3Jp cHRzIChlLmcuIHRoaXJkLXBhcnR5IGFuYWx5dGljcywKICAgICAgICAgICAgICBzb2NpYWwgcGx1 Zy1pbnMsIGFkIG5ldHdvcmtzKSBpbiB0aGUgcmVkaXJlY3Rpb24gZW5kcG9pbnQgcmVzcG9uc2Uu IEluc3RlYWQsIGl0CiAgICAgICAgICAgICAgU0hPVUxEIGV4dHJhY3QgdGhlIGNyZWRlbnRpYWxz IGZyb20gdGhlIFVSSSBhbmQgcmVkaXJlY3QgdGhlIHVzZXItYWdlbnQgYWdhaW4gdG8KICAgICAg ICAgICAgICBhbm90aGVyIGVuZHBvaW50IHdpdGhvdXQgZXhwb3NpbmcgdGhlIGNyZWRlbnRpYWxz IChpbiB0aGUgVVJJIG9yIGVsc2V3aGVyZSkuIElmCiAgICAgICAgICAgICAgdGhpcmQtcGFydHkg c2NyaXB0cyBhcmUgaW5jbHVkZWQsIHRoZSBjbGllbnQgTVVTVCBlbnN1cmUgdGhhdCBpdHMgb3du IHNjcmlwdHMKICAgICAgICAgICAgICAodXNlZCB0byBleHRyYWN0IGFuZCByZW1vdmUgdGhlIGNy ZWRlbnRpYWxzIGZyb20gdGhlIFVSSSkgd2lsbCBleGVjdXRlIGZpcnN0LgogICAgICAgICAgICA8 L3Q+CiAgICAgICAgICA8L3NlY3Rpb24+CiAgICAgICAgICAKICAgICAgICA8L3NlY3Rpb24+Cgog ICAgICA8L3NlY3Rpb24+CgogICAgICA8c2VjdGlvbiB0aXRsZT0nVG9rZW4gRW5kcG9pbnQnPgog ICAgICAgIDx0PgogICAgICAgICAgVGhlIHRva2VuIGVuZHBvaW50IGlzIHVzZWQgYnkgdGhlIGNs aWVudCB0byBvYnRhaW4gYW4gYWNjZXNzIHRva2VuIGJ5IHByZXNlbnRpbmcgaXRzCiAgICAgICAg ICBhdXRob3JpemF0aW9uIGdyYW50IG9yIHJlZnJlc2ggdG9rZW4uIFRoZSB0b2tlbiBlbmRwb2lu dCBpcyB1c2VkIHdpdGggZXZlcnkgYXV0aG9yaXphdGlvbgogICAgICAgICAgZ3JhbnQgZXhjZXB0 IGZvciB0aGUgaW1wbGljaXQgZ3JhbnQgdHlwZSAoc2luY2UgYW4gYWNjZXNzIHRva2VuIGlzIGlz c3VlZCBkaXJlY3RseSkuCiAgICAgICAgPC90PgogICAgICAgIDx0PgogICAgICAgICAgVGhlIG1l YW5zIHRocm91Z2ggd2hpY2ggdGhlIGNsaWVudCBvYnRhaW5zIHRoZSBsb2NhdGlvbiBvZiB0aGUg dG9rZW4gZW5kcG9pbnQgYXJlCiAgICAgICAgICBiZXlvbmQgdGhlIHNjb3BlIG9mIHRoaXMgc3Bl Y2lmaWNhdGlvbiBidXQgaXMgdHlwaWNhbGx5IHByb3ZpZGVkIGluIHRoZSBzZXJ2aWNlCiAgICAg ICAgICBkb2N1bWVudGF0aW9uLgogICAgICAgIDwvdD4KICAgICAgICA8dD4KICAgICAgICAgIFRo ZSBlbmRwb2ludCBVUkkgTUFZIGluY2x1ZGUgYW4KICAgICAgICAgIDxzcGFueCBzdHlsZT0ndmVy Yic+YXBwbGljYXRpb24veC13d3ctZm9ybS11cmxlbmNvZGVkPC9zcGFueD4gZm9ybWF0dGVkCiAg ICAgICAgICAoPHhyZWYgdGFyZ2V0PSdXM0MuUkVDLWh0bWw0MDEtMTk5OTEyMjQnIC8+KSBxdWVy eSBjb21wb25lbnQgKDx4cmVmIHRhcmdldD0nUkZDMzk4NicgLz4KICAgICAgICAgIHNlY3Rpb24g My40KSwgd2hpY2ggTVVTVCBiZSByZXRhaW5lZCB3aGVuIGFkZGluZyBhZGRpdGlvbmFsIHF1ZXJ5 IHBhcmFtZXRlcnMuIFRoZQogICAgICAgICAgZW5kcG9pbnQgVVJJIE1VU1QgTk9UIGluY2x1ZGUg YSBmcmFnbWVudCBjb21wb25lbnQuCiAgICAgICAgPC90PgogICAgICAgIDx0PgogICAgICAgICAg U2luY2UgcmVxdWVzdHMgdG8gdGhlIHRva2VuIGVuZHBvaW50IHJlc3VsdCBpbiB0aGUgdHJhbnNt aXNzaW9uIG9mIGNsZWFyLXRleHQgY3JlZGVudGlhbHMKICAgICAgICAgIChpbiB0aGUgSFRUUCBy ZXF1ZXN0IGFuZCByZXNwb25zZSksIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBNVVNUIHJlcXVp cmUgdGhlIHVzZSBvZiBUTFMKICAgICAgICAgIGFzIGRlc2NyaWJlZCBpbiA8eHJlZiB0YXJnZXQ9 J3RscycgLz4gd2hlbiBzZW5kaW5nIHJlcXVlc3RzIHRvIHRoZSB0b2tlbiBlbmRwb2ludC4KICAg ICAgICA8L3Q+CiAgICAgICAgPHQ+CiAgICAgICAgICBUaGUgY2xpZW50IE1VU1QgdXNlIHRoZSBI VFRQIDxzcGFueCBzdHlsZT0ndmVyYic+UE9TVDwvc3Bhbng+IG1ldGhvZCB3aGVuIG1ha2luZyBh Y2Nlc3MKICAgICAgICAgIHRva2VuIHJlcXVlc3RzLgogICAgICAgIDwvdD4KICAgICAgICA8dD4K ICAgICAgICAgIFBhcmFtZXRlcnMgc2VudCB3aXRob3V0IGEgdmFsdWUgTVVTVCBiZSB0cmVhdGVk IGFzIGlmIHRoZXkgd2VyZSBvbWl0dGVkIGZyb20gdGhlIHJlcXVlc3QuCiAgICAgICAgICBUaGUg YXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVTVCBpZ25vcmUgdW5yZWNvZ25pemVkIHJlcXVlc3QgcGFy YW1ldGVycy4gUmVxdWVzdCBhbmQKICAgICAgICAgIHJlc3BvbnNlIHBhcmFtZXRlcnMgTVVTVCBO T1QgYmUgaW5jbHVkZWQgbW9yZSB0aGFuIG9uY2UuCiAgICAgICAgPC90PgoKICAgICAgICA8c2Vj dGlvbiB0aXRsZT0nQ2xpZW50IEF1dGhlbnRpY2F0aW9uJyBhbmNob3I9J3Rva2VuLWVuZHBvaW50 LWF1dGgnPgogICAgICAgICAgPHQ+CiAgICAgICAgICAgIENvbmZpZGVudGlhbCBjbGllbnRzIG9y IG90aGVyIGNsaWVudHMgaXNzdWVkIGNsaWVudCBjcmVkZW50aWFscyBNVVNUIGF1dGhlbnRpY2F0 ZSB3aXRoCiAgICAgICAgICAgIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBhcyBkZXNjcmliZWQg aW4gPHhyZWYgdGFyZ2V0PSdjbGllbnQtYXV0aGVudGljYXRpb24nIC8+IHdoZW4KICAgICAgICAg ICAgbWFraW5nIHJlcXVlc3RzIHRvIHRoZSB0b2tlbiBlbmRwb2ludC4gQ2xpZW50IGF1dGhlbnRp Y2F0aW9uIGlzIHVzZWQgZm9yOgogICAgICAgICAgPC90PgogICAgICAgICAgPHQ+CiAgICAgICAg ICAgIDxsaXN0IHN0eWxlPSdzeW1ib2xzJz4KICAgICAgICAgICAgICA8dD4KICAgICAgICAgICAg ICAgIEVuZm9yY2luZyB0aGUgYmluZGluZyBvZiByZWZyZXNoIHRva2VucyBhbmQgYXV0aG9yaXph dGlvbiBjb2RlcyB0byB0aGUgY2xpZW50IHRoZXkKICAgICAgICAgICAgICAgIHdlcmUgaXNzdWVk IHRvLiBDbGllbnQgYXV0aGVudGljYXRpb24gaXMgY3JpdGljYWwgd2hlbiBhbiBhdXRob3JpemF0 aW9uIGNvZGUgaXMKICAgICAgICAgICAgICAgIHRyYW5zbWl0dGVkIHRvIHRoZSByZWRpcmVjdGlv biBlbmRwb2ludCBvdmVyIGFuIGluc2VjdXJlIGNoYW5uZWwsIG9yIHdoZW4gdGhlCiAgICAgICAg ICAgICAgICByZWRpcmVjdGlvbiBVUkkgaGFzIG5vdCBiZWVuIHJlZ2lzdGVyZWQgaW4gZnVsbC4K ICAgICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgICAgPHQ+CiAgICAgICAgICAgICAgICBSZWNv dmVyaW5nIGZyb20gYSBjb21wcm9taXNlZCBjbGllbnQgYnkgZGlzYWJsaW5nIHRoZSBjbGllbnQg b3IgY2hhbmdpbmcgaXRzCiAgICAgICAgICAgICAgICBjcmVkZW50aWFscywgdGh1cyBwcmV2ZW50 aW5nIGFuIGF0dGFja2VyIGZyb20gYWJ1c2luZyBzdG9sZW4gcmVmcmVzaCB0b2tlbnMuIENoYW5n aW5nCiAgICAgICAgICAgICAgICBhIHNpbmdsZSBzZXQgb2YgY2xpZW50IGNyZWRlbnRpYWxzIGlz IHNpZ25pZmljYW50bHkgZmFzdGVyIHRoYW4gcmV2b2tpbmcgYW4gZW50aXJlCiAgICAgICAgICAg ICAgICBzZXQgb2YgcmVmcmVzaCB0b2tlbnMuCiAgICAgICAgICAgICAgPC90PgogICAgICAgICAg ICAgIDx0PgogICAgICAgICAgICAgICAgSW1wbGVtZW50aW5nIGF1dGhlbnRpY2F0aW9uIG1hbmFn ZW1lbnQgYmVzdCBwcmFjdGljZXMgd2hpY2ggcmVxdWlyZSBwZXJpb2RpYwogICAgICAgICAgICAg ICAgY3JlZGVudGlhbCByb3RhdGlvbi4gUm90YXRpb24gb2YgYW4gZW50aXJlIHNldCBvZiByZWZy ZXNoIHRva2VucyBjYW4gYmUKICAgICAgICAgICAgICAgIGNoYWxsZW5naW5nLCB3aGlsZSByb3Rh dGlvbiBvZiBhIHNpbmdsZSBzZXQgb2YgY2xpZW50IGNyZWRlbnRpYWxzIGlzIHNpZ25pZmljYW50 bHkKICAgICAgICAgICAgICAgIGVhc2llci4KICAgICAgICAgICAgICA8L3Q+CiAgICAgICAgICAg IDwvbGlzdD4KICAgICAgICAgIDwvdD4KICAgICAgICAgIDx0PgogICAgICAgICAgICBBIHB1Ymxp YyBjbGllbnQgdGhhdCB3YXMgbm90IGlzc3VlZCBhIGNsaWVudCBwYXNzd29yZCBNQVkgdXNlIHRo ZQogICAgICAgICAgICA8c3Bhbnggc3R5bGU9J3ZlcmInPmNsaWVudF9pZDwvc3Bhbng+IHJlcXVl c3QgcGFyYW1ldGVyIHRvIGlkZW50aWZ5IGl0c2VsZiB3aGVuIHNlbmRpbmcKICAgICAgICAgICAg cmVxdWVzdHMgdG8gdGhlIHRva2VuIGVuZHBvaW50IChlLmcuIGZvciB0aGUgcHVycG9zZSBvZiBw cm92aWRpbmcgZW5kLXVzZXIgY29udGV4dCwKICAgICAgICAgICAgY2xpZW50IHVzYWdlIHN0YXRp c3RpY3MpLgogICAgICAgICAgPC90PgogICAgICAgIDwvc2VjdGlvbj4KCiAgICAgIDwvc2VjdGlv bj4KCiAgICAgIDxzZWN0aW9uIHRpdGxlPSdBY2Nlc3MgVG9rZW4gU2NvcGUnIGFuY2hvcj0nc2Nv cGUnPgogICAgICAgIDx0PgogICAgICAgICAgVGhlIGF1dGhvcml6YXRpb24gYW5kIHRva2VuIGVu ZHBvaW50cyBhbGxvdyB0aGUgY2xpZW50IHRvIHNwZWNpZnkgdGhlIHNjb3BlIG9mIHRoZSBhY2Nl c3MKICAgICAgICAgIHJlcXVlc3QgdXNpbmcgdGhlIDxzcGFueCBzdHlsZT0ndmVyYic+c2NvcGU8 L3NwYW54PiByZXF1ZXN0IHBhcmFtZXRlci4gSW4gdHVybiwgdGhlCiAgICAgICAgICBhdXRob3Jp emF0aW9uIHNlcnZlciB1c2VzIHRoZSA8c3Bhbnggc3R5bGU9J3ZlcmInPnNjb3BlPC9zcGFueD4g cmVzcG9uc2UgcGFyYW1ldGVyIHRvCiAgICAgICAgICBpbmZvcm0gdGhlIGNsaWVudCBvZiB0aGUg c2NvcGUgb2YgdGhlIGFjY2VzcyB0b2tlbiBpc3N1ZWQuCiAgICAgICAgPC90PgogICAgICAgIDx0 PgogICAgICAgICAgVGhlIHZhbHVlIG9mIHRoZSBzY29wZSBwYXJhbWV0ZXIgaXMgZXhwcmVzc2Vk IGFzIGEgbGlzdCBvZiBzcGFjZS1kZWxpbWl0ZWQsIGNhc2UKICAgICAgICAgIHNlbnNpdGl2ZSBz dHJpbmdzLiBUaGUgc3RyaW5ncyBhcmUgZGVmaW5lZCBieSB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2 ZXIuIElmIHRoZSB2YWx1ZQogICAgICAgICAgY29udGFpbnMgbXVsdGlwbGUgc3BhY2UtZGVsaW1p dGVkIHN0cmluZ3MsIHRoZWlyIG9yZGVyIGRvZXMgbm90IG1hdHRlciwgYW5kIGVhY2ggc3RyaW5n CiAgICAgICAgICBhZGRzIGFuIGFkZGl0aW9uYWwgYWNjZXNzIHJhbmdlIHRvIHRoZSByZXF1ZXN0 ZWQgc2NvcGUuCiAgICAgICAgPC90PgogICAgICAgIDxmaWd1cmU+CiAgICAgICAgICA8YXJ0d29y az4KICAgICAgICAgICAgPCFbQ0RBVEFbCiAgc2NvcGUgICAgICAgPSBzY29wZS10b2tlbiAqKCBT UCBzY29wZS10b2tlbiApCiAgc2NvcGUtdG9rZW4gPSAxKiggJXgyMSAvICV4MjMtNUIgLyAleDVE LTdFICkKXV0+CiAgICAgICAgICA8L2FydHdvcms+CiAgICAgICAgPC9maWd1cmU+CiAgICAgICAg PHQ+CiAgICAgICAgICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTUFZIGZ1bGx5IG9yIHBhcnRp YWxseSBpZ25vcmUgdGhlIHNjb3BlIHJlcXVlc3RlZCBieSB0aGUgY2xpZW50CiAgICAgICAgICBi YXNlZCBvbiB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgcG9saWN5IG9yIHRoZSByZXNvdXJjZSBv d25lcidzIGluc3RydWN0aW9ucy4gSWYgdGhlCiAgICAgICAgICBpc3N1ZWQgYWNjZXNzIHRva2Vu IHNjb3BlIGlzIGRpZmZlcmVudCBmcm9tIHRoZSBvbmUgcmVxdWVzdGVkIGJ5IHRoZSBjbGllbnQs IHRoZQogICAgICAgICAgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVTVCBpbmNsdWRlIHRoZSA8c3Bh bnggc3R5bGU9J3ZlcmInPnNjb3BlPC9zcGFueD4gcmVzcG9uc2UKICAgICAgICAgIHBhcmFtZXRl ciB0byBpbmZvcm0gdGhlIGNsaWVudCBvZiB0aGUgYWN0dWFsIHNjb3BlIGdyYW50ZWQuCiAgICAg ICAgPC90PgogICAgICAgIDx0PgogICAgICAgICAgSWYgdGhlIGNsaWVudCBvbWl0cyB0aGUgc2Nv cGUgcGFyYW1ldGVyIHdoZW4gcmVxdWVzdGluZyBhdXRob3JpemF0aW9uLCB0aGUgYXV0aG9yaXph dGlvbgogICAgICAgICAgc2VydmVyIE1VU1QgZWl0aGVyIHByb2Nlc3MgdGhlIHJlcXVlc3QgdXNp bmcgYSBwcmUtZGVmaW5lZCBkZWZhdWx0IHZhbHVlLCBvciBmYWlsIHRoZQogICAgICAgICAgcmVx dWVzdCBpbmRpY2F0aW5nIGFuIGludmFsaWQgc2NvcGUuIFRoZSBhdXRob3JpemF0aW9uIHNlcnZl ciBTSE9VTEQgZG9jdW1lbnQgaXRzIHNjb3BlCiAgICAgICAgICByZXF1aXJlbWVudHMgYW5kIGRl ZmF1bHQgdmFsdWUgKGlmIGRlZmluZWQpLgogICAgICAgIDwvdD4KICAgICAgPC9zZWN0aW9uPgoK ICAgIDwvc2VjdGlvbj4KCiAgICA8c2VjdGlvbiB0aXRsZT0nT2J0YWluaW5nIEF1dGhvcml6YXRp b24nPgogICAgICA8dD4KICAgICAgICBUbyByZXF1ZXN0IGFuIGFjY2VzcyB0b2tlbiwgdGhlIGNs aWVudCBvYnRhaW5zIGF1dGhvcml6YXRpb24gZnJvbSB0aGUgcmVzb3VyY2Ugb3duZXIuIFRoZQog ICAgICAgIGF1dGhvcml6YXRpb24gaXMgZXhwcmVzc2VkIGluIHRoZSBmb3JtIG9mIGFuIGF1dGhv cml6YXRpb24gZ3JhbnQgd2hpY2ggdGhlIGNsaWVudCB1c2VzIHRvCiAgICAgICAgcmVxdWVzdCB0 aGUgYWNjZXNzIHRva2VuLiBPQXV0aCBkZWZpbmVzIGZvdXIgZ3JhbnQgdHlwZXM6IGF1dGhvcml6 YXRpb24gY29kZSwgaW1wbGljaXQsCiAgICAgICAgcmVzb3VyY2Ugb3duZXIgcGFzc3dvcmQgY3Jl ZGVudGlhbHMsIGFuZCBjbGllbnQgY3JlZGVudGlhbHMuIEl0IGFsc28gcHJvdmlkZXMgYW4gZXh0 ZW5zaW9uCiAgICAgICAgbWVjaGFuaXNtIGZvciBkZWZpbmluZyBhZGRpdGlvbmFsIGdyYW50IHR5 cGVzLgogICAgICA8L3Q+CgogICAgICA8c2VjdGlvbiB0aXRsZT0nQXV0aG9yaXphdGlvbiBDb2Rl IEdyYW50JyBhbmNob3I9J2dyYW50LWNvZGUnPgogICAgICAgIDx0PgogICAgICAgICAgVGhlIGF1 dGhvcml6YXRpb24gY29kZSBncmFudCB0eXBlIGlzIHVzZWQgdG8gb2J0YWluIGJvdGggYWNjZXNz IHRva2VucyBhbmQgcmVmcmVzaAogICAgICAgICAgdG9rZW5zIGFuZCBpcyBvcHRpbWl6ZWQgZm9y IGNvbmZpZGVudGlhbCBjbGllbnRzLiBBcyBhIHJlZGlyZWN0aW9uLWJhc2VkIGZsb3csIHRoZSBj bGllbnQKICAgICAgICAgIG11c3QgYmUgY2FwYWJsZSBvZiBpbnRlcmFjdGluZyB3aXRoIHRoZSBy ZXNvdXJjZSBvd25lcidzIHVzZXItYWdlbnQgKHR5cGljYWxseSBhIHdlYgogICAgICAgICAgYnJv d3NlcikgYW5kIGNhcGFibGUgb2YgcmVjZWl2aW5nIGluY29taW5nIHJlcXVlc3RzICh2aWEgcmVk aXJlY3Rpb24pIGZyb20gdGhlCiAgICAgICAgICBhdXRob3JpemF0aW9uIHNlcnZlci4KICAgICAg ICA8L3Q+CiAgICAgICAgPGZpZ3VyZSB0aXRsZT0nQXV0aG9yaXphdGlvbiBDb2RlIEZsb3cnIGFu Y2hvcj0nRmlndXJlLTMnPgogICAgICAgICAgPGFydHdvcms+CiAgICAgICAgICAgIDwhW0NEQVRB WwogICstLS0tLS0tLS0tKwogIHwgcmVzb3VyY2UgfAogIHwgICBvd25lciAgfAogIHwgICAgICAg ICAgfAogICstLS0tLS0tLS0tKwogICAgICAgXgogICAgICAgfAogICAgICAoQikgICAgICAKICAr LS0tLXwtLS0tLSsgICAgICAgICAgQ2xpZW50IElkZW50aWZpZXIgICAgICArLS0tLS0tLS0tLS0t LS0tKwogIHwgICAgICAgICAtKy0tLS0oQSktLSAmIFJlZGlyZWN0aW9uIFVSSSAtLS0tPnwgICAg ICAgICAgICAgICB8CiAgfCAgVXNlci0gICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgfCBBdXRob3JpemF0aW9uIHwKICB8ICBBZ2VudCAgLSstLS0tKEIpLS0gVXNlciBhdXRoZW50 aWNhdGVzIC0tLT58ICAgICBTZXJ2ZXIgICAgfAogIHwgICAgICAgICAgfCAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICB8CiAgfCAgICAgICAgIC0rLS0tLShD KS0tIEF1dGhvcml6YXRpb24gQ29kZSAtLS08fCAgICAgICAgICAgICAgIHwKICArLXwtLS0tfC0t LSsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tKwogICAg fCAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBeICAgICAgdgog ICAoQSkgIChDKSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAg fAogICAgfCAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAg ICAgfAogICAgXiAgICB2ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8 ICAgICAgfAogICstLS0tLS0tLS0rICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB8ICAgICAgfAogIHwgICAgICAgICB8Pi0tLShEKS0tIEF1dGhvcml6YXRpb24gQ29kZSAtLS0t LS0tLS0nICAgICAgfAogIHwgIENsaWVudCB8ICAgICAgICAgICYgUmVkaXJlY3Rpb24gVVJJICAg ICAgICAgICAgICAgICAgfAogIHwgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgfAogIHwgICAgICAgICB8PC0tLShFKS0tLS0tIEFjY2VzcyBUb2tl biAtLS0tLS0tLS0tLS0tLS0tLS0tJwogICstLS0tLS0tLS0rICAgICAgICh3LyBPcHRpb25hbCBS ZWZyZXNoIFRva2VuKQpdXT4KICAgICAgICAgIDwvYXJ0d29yaz4KICAgICAgICAgIDxwb3N0YW1i bGU+CiAgICAgICAgICAgIE5vdGU6IFRoZSBsaW5lcyBpbGx1c3RyYXRpbmcgc3RlcHMgQSwgQiwg YW5kIEMgYXJlIGJyb2tlbiBpbnRvIHR3byBwYXJ0cyBhcyB0aGV5IHBhc3MKICAgICAgICAgICAg dGhyb3VnaCB0aGUgdXNlci1hZ2VudC4KICAgICAgICAgIDwvcG9zdGFtYmxlPgogICAgICAgIDwv ZmlndXJlPgogICAgICAgIDx0PgogICAgICAgICAgVGhlIGZsb3cgaWxsdXN0cmF0ZWQgaW4gPHhy ZWYgdGFyZ2V0PSdGaWd1cmUtMycgLz4gaW5jbHVkZXMgdGhlIGZvbGxvd2luZyBzdGVwczoKICAg ICAgICA8L3Q+CiAgICAgICAgPHQ+CiAgICAgICAgICA8bGlzdCBzdHlsZT0nZm9ybWF0ICglQykn PgogICAgICAgICAgICA8dD4KICAgICAgICAgICAgICBUaGUgY2xpZW50IGluaXRpYXRlcyB0aGUg ZmxvdyBieSBkaXJlY3RpbmcgdGhlIHJlc291cmNlIG93bmVyJ3MgdXNlci1hZ2VudCB0byB0aGUK ICAgICAgICAgICAgICBhdXRob3JpemF0aW9uIGVuZHBvaW50LiBUaGUgY2xpZW50IGluY2x1ZGVz IGl0cyBjbGllbnQgaWRlbnRpZmllciwgcmVxdWVzdGVkCiAgICAgICAgICAgICAgc2NvcGUsIGxv Y2FsIHN0YXRlLCBhbmQgYSByZWRpcmVjdGlvbiBVUkkgdG8gd2hpY2ggdGhlIGF1dGhvcml6YXRp b24gc2VydmVyIHdpbGwgc2VuZAogICAgICAgICAgICAgIHRoZSB1c2VyLWFnZW50IGJhY2sgb25j ZSBhY2Nlc3MgaXMgZ3JhbnRlZCAob3IgZGVuaWVkKS4KICAgICAgICAgICAgPC90PgogICAgICAg ICAgICA8dD4KICAgICAgICAgICAgICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYXV0aGVudGlj YXRlcyB0aGUgcmVzb3VyY2Ugb3duZXIgKHZpYSB0aGUgdXNlci1hZ2VudCkgYW5kCiAgICAgICAg ICAgICAgZXN0YWJsaXNoZXMgd2hldGhlciB0aGUgcmVzb3VyY2Ugb3duZXIgZ3JhbnRzIG9yIGRl bmllcyB0aGUgY2xpZW50J3MgYWNjZXNzIHJlcXVlc3QuCiAgICAgICAgICAgIDwvdD4KICAgICAg ICAgICAgPHQ+CiAgICAgICAgICAgICAgQXNzdW1pbmcgdGhlIHJlc291cmNlIG93bmVyIGdyYW50 cyBhY2Nlc3MsIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciByZWRpcmVjdHMgdGhlCiAgICAgICAg ICAgICAgdXNlci1hZ2VudCBiYWNrIHRvIHRoZSBjbGllbnQgdXNpbmcgdGhlIHJlZGlyZWN0aW9u IFVSSSBwcm92aWRlZCBlYXJsaWVyIChpbiB0aGUKICAgICAgICAgICAgICByZXF1ZXN0IG9yIGR1 cmluZyBjbGllbnQgcmVnaXN0cmF0aW9uKS4gVGhlIHJlZGlyZWN0aW9uIFVSSSBpbmNsdWRlcyBh biBhdXRob3JpemF0aW9uCiAgICAgICAgICAgICAgY29kZSBhbmQgYW55IGxvY2FsIHN0YXRlIHBy b3ZpZGVkIGJ5IHRoZSBjbGllbnQgZWFybGllci4KICAgICAgICAgICAgPC90PgogICAgICAgICAg ICA8dD4KICAgICAgICAgICAgICBUaGUgY2xpZW50IHJlcXVlc3RzIGFuIGFjY2VzcyB0b2tlbiBm cm9tIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlcidzIHRva2VuIGVuZHBvaW50CiAgICAgICAgICAg ICAgYnkgaW5jbHVkaW5nIHRoZSBhdXRob3JpemF0aW9uIGNvZGUgcmVjZWl2ZWQgaW4gdGhlIHBy ZXZpb3VzIHN0ZXAuIFdoZW4gbWFraW5nIHRoZQogICAgICAgICAgICAgIHJlcXVlc3QsIHRoZSBj bGllbnQgYXV0aGVudGljYXRlcyB3aXRoIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlci4gVGhlIGNs aWVudCBpbmNsdWRlcwogICAgICAgICAgICAgIHRoZSByZWRpcmVjdGlvbiBVUkkgdXNlZCB0byBv YnRhaW4gdGhlIGF1dGhvcml6YXRpb24gY29kZSBmb3IgdmVyaWZpY2F0aW9uLgogICAgICAgICAg ICA8L3Q+CiAgICAgICAgICAgIDx0PgogICAgICAgICAgICAgIFRoZSBhdXRob3JpemF0aW9uIHNl cnZlciBhdXRoZW50aWNhdGVzIHRoZSBjbGllbnQsIHZhbGlkYXRlcyB0aGUgYXV0aG9yaXphdGlv biBjb2RlLAogICAgICAgICAgICAgIGFuZCBlbnN1cmVzIHRoZSByZWRpcmVjdGlvbiBVUkkgcmVj ZWl2ZWQgbWF0Y2hlcyB0aGUgVVJJIHVzZWQgdG8gcmVkaXJlY3QgdGhlIGNsaWVudAogICAgICAg ICAgICAgIGluIHN0ZXAgKEMpLiBJZiB2YWxpZCwgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHJl c3BvbmRzIGJhY2sgd2l0aCBhbiBhY2Nlc3MgdG9rZW4KICAgICAgICAgICAgICBhbmQgb3B0aW9u YWxseSwgYSByZWZyZXNoIHRva2VuLgogICAgICAgICAgICA8L3Q+CiAgICAgICAgICA8L2xpc3Q+ CiAgICAgICAgPC90PgoKICAgICAgICA8c2VjdGlvbiB0aXRsZT0nQXV0aG9yaXphdGlvbiBSZXF1 ZXN0JyBhbmNob3I9J2NvZGUtYXV0aHotcmVxJz4KICAgICAgICAgIDx0PgogICAgICAgICAgICBU aGUgY2xpZW50IGNvbnN0cnVjdHMgdGhlIHJlcXVlc3QgVVJJIGJ5IGFkZGluZyB0aGUgZm9sbG93 aW5nIHBhcmFtZXRlcnMgdG8gdGhlCiAgICAgICAgICAgIHF1ZXJ5IGNvbXBvbmVudCBvZiB0aGUg YXV0aG9yaXphdGlvbiBlbmRwb2ludCBVUkkgdXNpbmcgdGhlCiAgICAgICAgICAgIDxzcGFueCBz dHlsZT0ndmVyYic+YXBwbGljYXRpb24veC13d3ctZm9ybS11cmxlbmNvZGVkPC9zcGFueD4gZm9y bWF0IGFzIGRlZmluZWQgYnkKICAgICAgICAgICAgPHhyZWYgdGFyZ2V0PSdXM0MuUkVDLWh0bWw0 MDEtMTk5OTEyMjQnIC8+OgogICAgICAgICAgPC90PgogICAgICAgICAgPHQ+CiAgICAgICAgICAg IDxsaXN0IHN0eWxlPSdoYW5naW5nJyBoYW5nSW5kZW50PSc2Jz4KICAgICAgICAgICAgICA8dCBo YW5nVGV4dD0ncmVzcG9uc2VfdHlwZSc+CiAgICAgICAgICAgICAgICA8dnNwYWNlIC8+CiAgICAg ICAgICAgICAgICBSRVFVSVJFRC4gVmFsdWUgTVVTVCBiZSBzZXQgdG8gPHNwYW54IHN0eWxlPSd2 ZXJiJz5jb2RlPC9zcGFueD4uCiAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICAgIDx0IGhh bmdUZXh0PSdjbGllbnRfaWQnPgogICAgICAgICAgICAgICAgPHZzcGFjZSAvPgogICAgICAgICAg ICAgICAgUkVRVUlSRUQuIFRoZSBjbGllbnQgaWRlbnRpZmllciBhcyBkZXNjcmliZWQgaW4KICAg ICAgICAgICAgICAgIDx4cmVmIHRhcmdldD0nY2xpZW50LWlkZW50aWZpZXInIC8+LgogICAgICAg ICAgICAgIDwvdD4KICAgICAgICAgICAgICA8dCBoYW5nVGV4dD0ncmVkaXJlY3RfdXJpJz4KICAg ICAgICAgICAgICAgIDx2c3BhY2UgLz4KICAgICAgICAgICAgICAgIE9QVElPTkFMLiBBcyBkZXNj cmliZWQgaW4gPHhyZWYgdGFyZ2V0PSdyZWRpcmVjdC11cmknIC8+LgogICAgICAgICAgICAgIDwv dD4KICAgICAgICAgICAgICA8dCBoYW5nVGV4dD0nc2NvcGUnPgogICAgICAgICAgICAgICAgPHZz cGFjZSAvPgogICAgICAgICAgICAgICAgT1BUSU9OQUwuIFRoZSBzY29wZSBvZiB0aGUgYWNjZXNz IHJlcXVlc3QgYXMgZGVzY3JpYmVkIGJ5IDx4cmVmIHRhcmdldD0nc2NvcGUnIC8+LgogICAgICAg ICAgICAgIDwvdD4KICAgICAgICAgICAgICA8dCBoYW5nVGV4dD0nc3RhdGUnPgogICAgICAgICAg ICAgICAgPHZzcGFjZSAvPgogICAgICAgICAgICAgICAgUkVDT01NRU5ERUQuIEFuIG9wYXF1ZSB2 YWx1ZSB1c2VkIGJ5IHRoZSBjbGllbnQgdG8gbWFpbnRhaW4gc3RhdGUgYmV0d2VlbiB0aGUgcmVx dWVzdAogICAgICAgICAgICAgICAgYW5kIGNhbGxiYWNrLiBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2 ZXIgaW5jbHVkZXMgdGhpcyB2YWx1ZSB3aGVuIHJlZGlyZWN0aW5nIHRoZQogICAgICAgICAgICAg ICAgdXNlci1hZ2VudCBiYWNrIHRvIHRoZSBjbGllbnQuIFRoZSBwYXJhbWV0ZXIgU0hPVUxEIGJl IHVzZWQgZm9yIHByZXZlbnRpbmcKICAgICAgICAgICAgICAgIGNyb3NzLXNpdGUgcmVxdWVzdCBm b3JnZXJ5IGFzIGRlc2NyaWJlZCBpbiA8eHJlZiB0YXJnZXQ9J0NTUkYnIC8+LgogICAgICAgICAg ICAgIDwvdD4KICAgICAgICAgICAgPC9saXN0PgogICAgICAgICAgPC90PgogICAgICAgICAgPHQ+ CiAgICAgICAgICAgIFRoZSBjbGllbnQgZGlyZWN0cyB0aGUgcmVzb3VyY2Ugb3duZXIgdG8gdGhl IGNvbnN0cnVjdGVkIFVSSSB1c2luZyBhbiBIVFRQIHJlZGlyZWN0aW9uCiAgICAgICAgICAgIHJl c3BvbnNlLCBvciBieSBvdGhlciBtZWFucyBhdmFpbGFibGUgdG8gaXQgdmlhIHRoZSB1c2VyLWFn ZW50LgogICAgICAgICAgPC90PgogICAgICAgICAgPGZpZ3VyZT4KICAgICAgICAgICAgPHByZWFt YmxlPgogICAgICAgICAgICAgIEZvciBleGFtcGxlLCB0aGUgY2xpZW50IGRpcmVjdHMgdGhlIHVz ZXItYWdlbnQgdG8gbWFrZSB0aGUgZm9sbG93aW5nIEhUVFAgcmVxdWVzdAogICAgICAgICAgICAg IHVzaW5nIFRMUyAoZXh0cmEgbGluZSBicmVha3MgYXJlIGZvciBkaXNwbGF5IHB1cnBvc2VzIG9u bHkpOgogICAgICAgICAgICA8L3ByZWFtYmxlPgogICAgICAgICAgICA8YXJ0d29yaz4KICAgICAg ICAgICAgICA8IVtDREFUQVsKICBHRVQgL2F1dGhvcml6ZT9yZXNwb25zZV90eXBlPWNvZGUmY2xp ZW50X2lkPXM2QmhkUmtxdDMmc3RhdGU9eHl6CiAgICAgICZyZWRpcmVjdF91cmk9aHR0cHMlM0El MkYlMkZjbGllbnQlMkVleGFtcGxlJTJFY29tJTJGY2IgSFRUUC8xLjEKICBIb3N0OiBzZXJ2ZXIu ZXhhbXBsZS5jb20KXV0+CiAgICAgICAgICAgIDwvYXJ0d29yaz4KICAgICAgICAgIDwvZmlndXJl PgogICAgICAgICAgPHQ+CiAgICAgICAgICAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciB2YWxp ZGF0ZXMgdGhlIHJlcXVlc3QgdG8gZW5zdXJlIGFsbCByZXF1aXJlZCBwYXJhbWV0ZXJzIGFyZQog ICAgICAgICAgICBwcmVzZW50IGFuZCB2YWxpZC4gSWYgdGhlIHJlcXVlc3QgaXMgdmFsaWQsIHRo ZSBhdXRob3JpemF0aW9uIHNlcnZlciBhdXRoZW50aWNhdGVzIHRoZQogICAgICAgICAgICByZXNv dXJjZSBvd25lciBhbmQgb2J0YWlucyBhbiBhdXRob3JpemF0aW9uIGRlY2lzaW9uIChieSBhc2tp bmcgdGhlIHJlc291cmNlIG93bmVyIG9yCiAgICAgICAgICAgIGJ5IGVzdGFibGlzaGluZyBhcHBy b3ZhbCB2aWEgb3RoZXIgbWVhbnMpLgogICAgICAgICAgPC90PgogICAgICAgICAgPHQ+CiAgICAg ICAgICAgIFdoZW4gYSBkZWNpc2lvbiBpcyBlc3RhYmxpc2hlZCwgdGhlIGF1dGhvcml6YXRpb24g c2VydmVyIGRpcmVjdHMgdGhlIHVzZXItYWdlbnQgdG8gdGhlCiAgICAgICAgICAgIHByb3ZpZGVk IGNsaWVudCByZWRpcmVjdGlvbiBVUkkgdXNpbmcgYW4gSFRUUCByZWRpcmVjdGlvbiByZXNwb25z ZSwgb3IgYnkgb3RoZXIgbWVhbnMKICAgICAgICAgICAgYXZhaWxhYmxlIHRvIGl0IHZpYSB0aGUg dXNlci1hZ2VudC4KICAgICAgICAgIDwvdD4KICAgICAgICA8L3NlY3Rpb24+CgogICAgICAgIDxz ZWN0aW9uIHRpdGxlPSdBdXRob3JpemF0aW9uIFJlc3BvbnNlJyBhbmNob3I9ImNvZGUtYXV0aHot cmVzcCI+CiAgICAgICAgICA8dD4KICAgICAgICAgICAgSWYgdGhlIHJlc291cmNlIG93bmVyIGdy YW50cyB0aGUgYWNjZXNzIHJlcXVlc3QsIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBpc3N1ZXMg YW4KICAgICAgICAgICAgYXV0aG9yaXphdGlvbiBjb2RlIGFuZCBkZWxpdmVycyBpdCB0byB0aGUg Y2xpZW50IGJ5IGFkZGluZyB0aGUgZm9sbG93aW5nIHBhcmFtZXRlcnMgdG8KICAgICAgICAgICAg dGhlIHF1ZXJ5IGNvbXBvbmVudCBvZiB0aGUgcmVkaXJlY3Rpb24gVVJJIHVzaW5nIHRoZQogICAg ICAgICAgICA8c3Bhbnggc3R5bGU9J3ZlcmInPmFwcGxpY2F0aW9uL3gtd3d3LWZvcm0tdXJsZW5j b2RlZDwvc3Bhbng+IGZvcm1hdDoKICAgICAgICAgIDwvdD4KICAgICAgICAgIDx0PgogICAgICAg ICAgICA8bGlzdCBzdHlsZT0naGFuZ2luZycgaGFuZ0luZGVudD0nNic+CiAgICAgICAgICAgICAg PHQgaGFuZ1RleHQ9J2NvZGUnPgogICAgICAgICAgICAgICAgPHZzcGFjZSAvPgogICAgICAgICAg ICAgICAgUkVRVUlSRUQuIFRoZSBhdXRob3JpemF0aW9uIGNvZGUgZ2VuZXJhdGVkIGJ5IHRoZSBh dXRob3JpemF0aW9uIHNlcnZlci4gVGhlCiAgICAgICAgICAgICAgICBhdXRob3JpemF0aW9uIGNv ZGUgTVVTVCBleHBpcmUgc2hvcnRseSBhZnRlciBpdCBpcyBpc3N1ZWQgdG8gbWl0aWdhdGUgdGhl IHJpc2sgb2YKICAgICAgICAgICAgICAgIGxlYWtzLiBBIG1heGltdW0gYXV0aG9yaXphdGlvbiBj b2RlIGxpZmV0aW1lIG9mIDEwIG1pbnV0ZXMgaXMgUkVDT01NRU5ERUQuIFRoZQogICAgICAgICAg ICAgICAgY2xpZW50IE1VU1QgTk9UIHVzZSB0aGUgYXV0aG9yaXphdGlvbiBjb2RlIG1vcmUgdGhh biBvbmNlLiBJZiBhbiBhdXRob3JpemF0aW9uIGNvZGUKICAgICAgICAgICAgICAgIGlzIHVzZWQg bW9yZSB0aGFuIG9uY2UsIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBNVVNUIGRlbnkgdGhlIHJl cXVlc3QgYW5kIFNIT1VMRAogICAgICAgICAgICAgICAgcmV2b2tlICh3aGVuIHBvc3NpYmxlKSBh bGwgdG9rZW5zIHByZXZpb3VzbHkgaXNzdWVkIGJhc2VkIG9uIHRoYXQgYXV0aG9yaXphdGlvbgog ICAgICAgICAgICAgICAgY29kZS4gVGhlIGF1dGhvcml6YXRpb24gY29kZSBpcyBib3VuZCB0byB0 aGUgY2xpZW50IGlkZW50aWZpZXIgYW5kIHJlZGlyZWN0aW9uIFVSSS4KICAgICAgICAgICAgICA8 L3Q+CiAgICAgICAgICAgICAgPHQgaGFuZ1RleHQ9J3N0YXRlJz4KICAgICAgICAgICAgICAgIDx2 c3BhY2UgLz4KICAgICAgICAgICAgICAgIFJFUVVJUkVEIGlmIHRoZSA8c3Bhbnggc3R5bGU9J3Zl cmInPnN0YXRlPC9zcGFueD4gcGFyYW1ldGVyIHdhcyBwcmVzZW50IGluIHRoZQogICAgICAgICAg ICAgICAgY2xpZW50IGF1dGhvcml6YXRpb24gcmVxdWVzdC4gVGhlIGV4YWN0IHZhbHVlIHJlY2Vp dmVkIGZyb20gdGhlIGNsaWVudC4KICAgICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgIDwvbGlz dD4KICAgICAgICAgIDwvdD4KICAgICAgICAgIDxmaWd1cmU+CiAgICAgICAgICAgIDxwcmVhbWJs ZT4KICAgICAgICAgICAgICBGb3IgZXhhbXBsZSwgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHJl ZGlyZWN0cyB0aGUgdXNlci1hZ2VudCBieSBzZW5kaW5nIHRoZQogICAgICAgICAgICAgIGZvbGxv d2luZyBIVFRQIHJlc3BvbnNlOgogICAgICAgICAgICA8L3ByZWFtYmxlPgogICAgICAgICAgICA8 YXJ0d29yaz4KICAgICAgICAgICAgICA8IVtDREFUQVsKICBIVFRQLzEuMSAzMDIgRm91bmQKICBM b2NhdGlvbjogaHR0cHM6Ly9jbGllbnQuZXhhbXBsZS5jb20vY2I/Y29kZT1TcGx4bE9CZVpRUVli WVM2V3hTYklBCiAgICAgICAgICAgICZzdGF0ZT14eXoKXV0+CiAgICAgICAgICAgIDwvYXJ0d29y az4KICAgICAgICAgIDwvZmlndXJlPgogICAgICAgICAgPHQ+CiAgICAgICAgICAgIFRoZSBjbGll bnQgTVVTVCBpZ25vcmUgdW5yZWNvZ25pemVkIHJlc3BvbnNlIHBhcmFtZXRlcnMuIFRoZSBhdXRo b3JpemF0aW9uIGNvZGUKICAgICAgICAgICAgc3RyaW5nIHNpemUgaXMgbGVmdCB1bmRlZmluZWQg YnkgdGhpcyBzcGVjaWZpY2F0aW9uLiBUaGUgY2xpZW50IHNob3VsZCBhdm9pZCBtYWtpbmcKICAg ICAgICAgICAgYXNzdW1wdGlvbnMgYWJvdXQgY29kZSB2YWx1ZSBzaXplcy4gVGhlIGF1dGhvcml6 YXRpb24gc2VydmVyIFNIT1VMRCBkb2N1bWVudCB0aGUgc2l6ZQogICAgICAgICAgICBvZiBhbnkg dmFsdWUgaXQgaXNzdWVzLgogICAgICAgICAgPC90PgoKICAgICAgICAgIDxzZWN0aW9uIHRpdGxl PSdFcnJvciBSZXNwb25zZScgYW5jaG9yPSdjb2RlLWF1dGh6LWVycm9yJz4KICAgICAgICAgICAg PHQ+CiAgICAgICAgICAgICAgSWYgdGhlIHJlcXVlc3QgZmFpbHMgZHVlIHRvIGEgbWlzc2luZywg aW52YWxpZCwgb3IgbWlzbWF0Y2hpbmcgcmVkaXJlY3Rpb24gVVJJLCBvciBpZgogICAgICAgICAg ICAgIHRoZSBjbGllbnQgaWRlbnRpZmllciBpcyBtaXNzaW5nIG9yIGludmFsaWQsIHRoZSBhdXRo b3JpemF0aW9uIHNlcnZlciBTSE9VTEQgaW5mb3JtCiAgICAgICAgICAgICAgdGhlIHJlc291cmNl IG93bmVyIG9mIHRoZSBlcnJvciwgYW5kIE1VU1QgTk9UIGF1dG9tYXRpY2FsbHkgcmVkaXJlY3Qg dGhlIHVzZXItYWdlbnQKICAgICAgICAgICAgICB0byB0aGUgaW52YWxpZCByZWRpcmVjdGlvbiBV UkkuCiAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAgPHQ+CiAgICAgICAgICAgICAgSWYgdGhl IHJlc291cmNlIG93bmVyIGRlbmllcyB0aGUgYWNjZXNzIHJlcXVlc3Qgb3IgaWYgdGhlIHJlcXVl c3QgZmFpbHMgZm9yIHJlYXNvbnMKICAgICAgICAgICAgICBvdGhlciB0aGFuIGEgbWlzc2luZyBv ciBpbnZhbGlkIHJlZGlyZWN0aW9uIFVSSSwgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGluZm9y bXMgdGhlCiAgICAgICAgICAgICAgY2xpZW50IGJ5IGFkZGluZyB0aGUgZm9sbG93aW5nIHBhcmFt ZXRlcnMgdG8gdGhlIHF1ZXJ5IGNvbXBvbmVudCBvZiB0aGUgcmVkaXJlY3Rpb24KICAgICAgICAg ICAgICBVUkkgdXNpbmcgdGhlIDxzcGFueCBzdHlsZT0ndmVyYic+YXBwbGljYXRpb24veC13d3ct Zm9ybS11cmxlbmNvZGVkPC9zcGFueD4gZm9ybWF0OgogICAgICAgICAgICA8L3Q+CiAgICAgICAg ICAgIDx0PgogICAgICAgICAgICAgIDxsaXN0IHN0eWxlPSdoYW5naW5nJyBoYW5nSW5kZW50PSc2 Jz4KICAgICAgICAgICAgICAgIDx0IGhhbmdUZXh0PSdlcnJvcic+CiAgICAgICAgICAgICAgICAg IDx2c3BhY2UgLz4KICAgICAgICAgICAgICAgICAgUkVRVUlSRUQuIEEgc2luZ2xlIEFTQ0lJIDx4 cmVmIHRhcmdldD0iVVNBU0NJSSIgLz4gZXJyb3IgY29kZSBmcm9tIHRoZSBmb2xsb3dpbmc6Cgog ICAgICAgICAgICAgICAgICA8bGlzdCBzdHlsZT0naGFuZ2luZycgaGFuZ0luZGVudD0nNic+CiAg ICAgICAgICAgICAgICAgICAgPHQgaGFuZ1RleHQ9J2ludmFsaWRfcmVxdWVzdCc+CiAgICAgICAg ICAgICAgICAgICAgICA8dnNwYWNlIC8+CiAgICAgICAgICAgICAgICAgICAgICBUaGUgcmVxdWVz dCBpcyBtaXNzaW5nIGEgcmVxdWlyZWQgcGFyYW1ldGVyLCBpbmNsdWRlcyBhbiBpbnZhbGlkCiAg ICAgICAgICAgICAgICAgICAgICBwYXJhbWV0ZXIgdmFsdWUsIGluY2x1ZGVzIGEgcGFyYW1ldGVy IG1vcmUgdGhhbiBvbmNlLCBvciBpcyBvdGhlcndpc2UKICAgICAgICAgICAgICAgICAgICAgIG1h bGZvcm1lZC4KICAgICAgICAgICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgICAgICAgICAgPHQg aGFuZ1RleHQ9J3VuYXV0aG9yaXplZF9jbGllbnQnPgogICAgICAgICAgICAgICAgICAgICAgPHZz cGFjZSAvPgogICAgICAgICAgICAgICAgICAgICAgVGhlIGNsaWVudCBpcyBub3QgYXV0aG9yaXpl ZCB0byByZXF1ZXN0IGFuIGF1dGhvcml6YXRpb24gY29kZSB1c2luZyB0aGlzCiAgICAgICAgICAg ICAgICAgICAgICBtZXRob2QuCiAgICAgICAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICAg ICAgICAgIDx0IGhhbmdUZXh0PSdhY2Nlc3NfZGVuaWVkJz4KICAgICAgICAgICAgICAgICAgICAg IDx2c3BhY2UgLz4KICAgICAgICAgICAgICAgICAgICAgIFRoZSByZXNvdXJjZSBvd25lciBvciBh dXRob3JpemF0aW9uIHNlcnZlciBkZW5pZWQgdGhlIHJlcXVlc3QuCiAgICAgICAgICAgICAgICAg ICAgPC90PgogICAgICAgICAgICAgICAgICAgIDx0IGhhbmdUZXh0PSd1bnN1cHBvcnRlZF9yZXNw b25zZV90eXBlJz4KICAgICAgICAgICAgICAgICAgICAgIDx2c3BhY2UgLz4KICAgICAgICAgICAg ICAgICAgICAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBkb2VzIG5vdCBzdXBwb3J0IG9idGFp bmluZyBhbiBhdXRob3JpemF0aW9uIGNvZGUKICAgICAgICAgICAgICAgICAgICAgIHVzaW5nIHRo aXMgbWV0aG9kLgogICAgICAgICAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAgICAgICAgICA8 dCBoYW5nVGV4dD0naW52YWxpZF9zY29wZSc+CiAgICAgICAgICAgICAgICAgICAgICA8dnNwYWNl IC8+CiAgICAgICAgICAgICAgICAgICAgICBUaGUgcmVxdWVzdGVkIHNjb3BlIGlzIGludmFsaWQs IHVua25vd24sIG9yIG1hbGZvcm1lZC4KICAgICAgICAgICAgICAgICAgICA8L3Q+CiAgICAgICAg ICAgICAgICAgICAgPHQgaGFuZ1RleHQ9J3NlcnZlcl9lcnJvcic+CiAgICAgICAgICAgICAgICAg ICAgICA8dnNwYWNlIC8+CiAgICAgICAgICAgICAgICAgICAgICBUaGUgYXV0aG9yaXphdGlvbiBz ZXJ2ZXIgZW5jb3VudGVyZWQgYW4gdW5leHBlY3RlZCBjb25kaXRpb24gd2hpY2ggcHJldmVudGVk CiAgICAgICAgICAgICAgICAgICAgICBpdCBmcm9tIGZ1bGZpbGxpbmcgdGhlIHJlcXVlc3QuCiAg ICAgICAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICAgICAgICAgIDx0IGhhbmdUZXh0PSd0 ZW1wb3JhcmlseV91bmF2YWlsYWJsZSc+CiAgICAgICAgICAgICAgICAgICAgICA8dnNwYWNlIC8+ CiAgICAgICAgICAgICAgICAgICAgICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgaXMgY3VycmVu dGx5IHVuYWJsZSB0byBoYW5kbGUgdGhlIHJlcXVlc3QgZHVlIHRvIGEKICAgICAgICAgICAgICAg ICAgICAgIHRlbXBvcmFyeSBvdmVybG9hZGluZyBvciBtYWludGVuYW5jZSBvZiB0aGUgc2VydmVy LgogICAgICAgICAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAgICAgICAgPC9saXN0PgoKCQkg IFZhbHVlcyBmb3IgdGhlIDxzcGFueCBzdHlsZT0ndmVyYic+ZXJyb3I8L3NwYW54PiBwYXJhbWV0 ZXIgTVVTVCBOT1QgaW5jbHVkZQoJCSAgY2hhcmFjdGVycyBvdXRzaWRlIHRoZSBzZXQgJXgyMC0y MSAvICV4MjMtNUIgLyAleDVELTdFLgogICAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICAg ICAgPHQgaGFuZ1RleHQ9J2Vycm9yX2Rlc2NyaXB0aW9uJz4KICAgICAgICAgICAgICAgICAgPHZz cGFjZSAvPgogICAgICAgICAgICAgICAgICBPUFRJT05BTC4gQSBodW1hbi1yZWFkYWJsZSBBU0NJ SSA8eHJlZiB0YXJnZXQ9IlVTQVNDSUkiIC8+IHRleHQgcHJvdmlkaW5nIGFkZGl0aW9uYWwgaW5m b3JtYXRpb24sCiAgICAgICAgICAgICAgICAgIHVzZWQgdG8gYXNzaXN0IHRoZSBjbGllbnQgZGV2 ZWxvcGVyIGluIHVuZGVyc3RhbmRpbmcgdGhlIGVycm9yIHRoYXQgb2NjdXJyZWQuCgkJICA8dnNw YWNlLz4KCQkgIFZhbHVlcyBmb3IgdGhlIDxzcGFueCBzdHlsZT0ndmVyYic+ZXJyb3JfZGVzY3Jp cHRpb248L3NwYW54PiBwYXJhbWV0ZXIgTVVTVCBOT1QgaW5jbHVkZQoJCSAgY2hhcmFjdGVycyBv dXRzaWRlIHRoZSBzZXQgJXgyMC0yMSAvICV4MjMtNUIgLyAleDVELTdFLgogICAgICAgICAgICAg ICAgPC90PgogICAgICAgICAgICAgICAgPHQgaGFuZ1RleHQ9J2Vycm9yX3VyaSc+CiAgICAgICAg ICAgICAgICAgIDx2c3BhY2UgLz4KICAgICAgICAgICAgICAgICAgT1BUSU9OQUwuIEEgVVJJIGlk ZW50aWZ5aW5nIGEgaHVtYW4tcmVhZGFibGUgd2ViIHBhZ2Ugd2l0aCBpbmZvcm1hdGlvbiBhYm91 dCB0aGUKICAgICAgICAgICAgICAgICAgZXJyb3IsIHVzZWQgdG8gcHJvdmlkZSB0aGUgY2xpZW50 IGRldmVsb3BlciB3aXRoIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gYWJvdXQgdGhlCiAgICAgICAg ICAgICAgICAgIGVycm9yLgoJCSAgPHZzcGFjZS8+CgkJICBWYWx1ZXMgZm9yIHRoZSA8c3Bhbngg c3R5bGU9J3ZlcmInPmVycm9yX3VyaTwvc3Bhbng+IHBhcmFtZXRlcgoJCSAgTVVTVCBjb25mb3Jt IHRvIHRoZSBVUkktUmVmZXJlbmNlIHN5bnRheCwgYW5kIHRodXMgTVVTVCBOT1QgaW5jbHVkZQoJ CSAgY2hhcmFjdGVycyBvdXRzaWRlIHRoZSBzZXQgJXgyMSAvICV4MjMtNUIgLyAleDVELTdFLgog ICAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICAgICAgPHQgaGFuZ1RleHQ9J3N0YXRlJz4K ICAgICAgICAgICAgICAgICAgPHZzcGFjZSAvPgogICAgICAgICAgICAgICAgICBSRVFVSVJFRCBp ZiBhIDxzcGFueCBzdHlsZT0ndmVyYic+c3RhdGU8L3NwYW54PiBwYXJhbWV0ZXIgd2FzIHByZXNl bnQgaW4gdGhlCiAgICAgICAgICAgICAgICAgIGNsaWVudCBhdXRob3JpemF0aW9uIHJlcXVlc3Qu IFRoZSBleGFjdCB2YWx1ZSByZWNlaXZlZCBmcm9tIHRoZSBjbGllbnQuCiAgICAgICAgICAgICAg ICA8L3Q+CiAgICAgICAgICAgICAgPC9saXN0PgogICAgICAgICAgICA8L3Q+CiAgICAgICAgICAg IDxmaWd1cmU+CiAgICAgICAgICAgICAgPHByZWFtYmxlPgogICAgICAgICAgICAgICAgRm9yIGV4 YW1wbGUsIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciByZWRpcmVjdHMgdGhlIHVzZXItYWdlbnQg Ynkgc2VuZGluZyB0aGUKICAgICAgICAgICAgICAgIGZvbGxvd2luZyBIVFRQIHJlc3BvbnNlOgog ICAgICAgICAgICAgIDwvcHJlYW1ibGU+CiAgICAgICAgICAgICAgPGFydHdvcms+CiAgICAgICAg ICAgICAgICA8IVtDREFUQVsKICBIVFRQLzEuMSAzMDIgRm91bmQKICBMb2NhdGlvbjogaHR0cHM6 Ly9jbGllbnQuZXhhbXBsZS5jb20vY2I/ZXJyb3I9YWNjZXNzX2RlbmllZCZzdGF0ZT14eXoKXV0+ CiAgICAgICAgICAgICAgPC9hcnR3b3JrPgogICAgICAgICAgICA8L2ZpZ3VyZT4KICAgICAgICAg IDwvc2VjdGlvbj4KCiAgICAgICAgPC9zZWN0aW9uPgoKICAgICAgICA8c2VjdGlvbiB0aXRsZT0n QWNjZXNzIFRva2VuIFJlcXVlc3QnIGFuY2hvcj0idG9rZW4tcmVxIj4KICAgICAgICAgIDx0Pgog ICAgICAgICAgICBUaGUgY2xpZW50IG1ha2VzIGEgcmVxdWVzdCB0byB0aGUgdG9rZW4gZW5kcG9p bnQgYnkgYWRkaW5nIHRoZSBmb2xsb3dpbmcgcGFyYW1ldGVycwogICAgICAgICAgICB1c2luZyB0 aGUgPHNwYW54IHN0eWxlPSd2ZXJiJz5hcHBsaWNhdGlvbi94LXd3dy1mb3JtLXVybGVuY29kZWQ8 L3NwYW54PiBmb3JtYXQgaW4gdGhlCiAgICAgICAgICAgIEhUVFAgcmVxdWVzdCBlbnRpdHktYm9k eToKICAgICAgICAgIDwvdD4KICAgICAgICAgIDx0PgogICAgICAgICAgICA8bGlzdCBzdHlsZT0n aGFuZ2luZycgaGFuZ0luZGVudD0nNic+CiAgICAgICAgICAgICAgPHQgaGFuZ1RleHQ9J2dyYW50 X3R5cGUnPgogICAgICAgICAgICAgICAgPHZzcGFjZSAvPgogICAgICAgICAgICAgICAgUkVRVUlS RUQuIFZhbHVlIE1VU1QgYmUgc2V0IHRvIDxzcGFueCBzdHlsZT0ndmVyYic+YXV0aG9yaXphdGlv bl9jb2RlPC9zcGFueD4uCiAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICAgIDx0IGhhbmdU ZXh0PSdjb2RlJz4KICAgICAgICAgICAgICAgIDx2c3BhY2UgLz4KICAgICAgICAgICAgICAgIFJF UVVJUkVELiBUaGUgYXV0aG9yaXphdGlvbiBjb2RlIHJlY2VpdmVkIGZyb20gdGhlIGF1dGhvcml6 YXRpb24gc2VydmVyLgogICAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAgICA8dCBoYW5nVGV4 dD0ncmVkaXJlY3RfdXJpJz4KICAgICAgICAgICAgICAgIDx2c3BhY2UgLz4KICAgICAgICAgICAg ICAgIFJFUVVJUkVELCBpZiB0aGUgPHNwYW54IHN0eWxlPSd2ZXJiJz5yZWRpcmVjdF91cmk8L3Nw YW54PiBwYXJhbWV0ZXIgd2FzIGluY2x1ZGVkIGluCiAgICAgICAgICAgICAgICB0aGUgYXV0aG9y aXphdGlvbiByZXF1ZXN0IGFzIGRlc2NyaWJlZCBpbiA8eHJlZiB0YXJnZXQ9J2NvZGUtYXV0aHot cmVxJyAvPiwgYW5kCiAgICAgICAgICAgICAgICB0aGVpciB2YWx1ZXMgTVVTVCBiZSBpZGVudGlj YWwuCiAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICA8L2xpc3Q+CiAgICAgICAgICA8L3Q+ CiAgICAgICAgICA8dD4KICAgICAgICAgICAgSWYgdGhlIGNsaWVudCB0eXBlIGlzIGNvbmZpZGVu dGlhbCBvciB0aGUgY2xpZW50IHdhcyBpc3N1ZWQgY2xpZW50IGNyZWRlbnRpYWxzIChvcgogICAg ICAgICAgICBhc3NpZ25lZCBvdGhlciBhdXRoZW50aWNhdGlvbiByZXF1aXJlbWVudHMpLCB0aGUg Y2xpZW50IE1VU1QgYXV0aGVudGljYXRlIHdpdGggdGhlCiAgICAgICAgICAgIGF1dGhvcml6YXRp b24gc2VydmVyIGFzIGRlc2NyaWJlZCBpbiA8eHJlZiB0YXJnZXQ9J3Rva2VuLWVuZHBvaW50LWF1 dGgnIC8+LgogICAgICAgICAgPC90PgogICAgICAgICAgPGZpZ3VyZT4KICAgICAgICAgICAgPHBy ZWFtYmxlPgogICAgICAgICAgICAgIEZvciBleGFtcGxlLCB0aGUgY2xpZW50IG1ha2VzIHRoZSBm b2xsb3dpbmcgSFRUUCByZXF1ZXN0IHVzaW5nIFRMUyAoZXh0cmEgbGluZSBicmVha3MKICAgICAg ICAgICAgICBhcmUgZm9yIGRpc3BsYXkgcHVycG9zZXMgb25seSk6CiAgICAgICAgICAgIDwvcHJl YW1ibGU+CiAgICAgICAgICAgIDxhcnR3b3JrPgogICAgICAgICAgICAgIDwhW0NEQVRBWwogIFBP U1QgL3Rva2VuIEhUVFAvMS4xCiAgSG9zdDogc2VydmVyLmV4YW1wbGUuY29tCiAgQXV0aG9yaXph dGlvbjogQmFzaWMgY3paQ2FHUlNhM0YwTXpwbldERm1RbUYwTTJKVwogIENvbnRlbnQtVHlwZTog YXBwbGljYXRpb24veC13d3ctZm9ybS11cmxlbmNvZGVkO2NoYXJzZXQ9VVRGLTgKCiAgZ3JhbnRf dHlwZT1hdXRob3JpemF0aW9uX2NvZGUmY29kZT1TcGx4bE9CZVpRUVliWVM2V3hTYklBCiAgJnJl ZGlyZWN0X3VyaT1odHRwcyUzQSUyRiUyRmNsaWVudCUyRWV4YW1wbGUlMkVjb20lMkZjYgpdXT4K ICAgICAgICAgICAgPC9hcnR3b3JrPgogICAgICAgICAgPC9maWd1cmU+CiAgICAgICAgICA8dD4K ICAgICAgICAgICAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIE1VU1Q6CiAgICAgICAgICA8L3Q+ CiAgICAgICAgICA8dD4KICAgICAgICAgICAgPGxpc3Qgc3R5bGU9J3N5bWJvbHMnPgogICAgICAg ICAgICAgIDx0PgogICAgICAgICAgICAgICAgcmVxdWlyZSBjbGllbnQgYXV0aGVudGljYXRpb24g Zm9yIGNvbmZpZGVudGlhbCBjbGllbnRzIG9yIGZvciBhbnkgY2xpZW50IHRoYXQgd2FzCiAgICAg ICAgICAgICAgICBpc3N1ZWQgY2xpZW50IGNyZWRlbnRpYWxzIChvciB3aXRoIG90aGVyIGF1dGhl bnRpY2F0aW9uIHJlcXVpcmVtZW50cyksCiAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICAg IDx0PgogICAgICAgICAgICAgICAgYXV0aGVudGljYXRlIHRoZSBjbGllbnQgaWYgY2xpZW50IGF1 dGhlbnRpY2F0aW9uIGlzIGluY2x1ZGVkIGFuZCBlbnN1cmUgdGhlCiAgICAgICAgICAgICAgICBh dXRob3JpemF0aW9uIGNvZGUgd2FzIGlzc3VlZCB0byB0aGUgYXV0aGVudGljYXRlZCBjbGllbnQs CiAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICAgIDx0PgogICAgICAgICAgICAgICAgdmVy aWZ5IHRoYXQgdGhlIGF1dGhvcml6YXRpb24gY29kZSBpcyB2YWxpZCwgYW5kCiAgICAgICAgICAg ICAgPC90PgogICAgICAgICAgICAgIDx0PgogICAgICAgICAgICAgICAgZW5zdXJlIHRoYXQgdGhl IDxzcGFueCBzdHlsZT0ndmVyYic+cmVkaXJlY3RfdXJpPC9zcGFueD4gcGFyYW1ldGVyIGlzIHBy ZXNlbnQgaWYKICAgICAgICAgICAgICAgIHRoZSA8c3Bhbnggc3R5bGU9J3ZlcmInPnJlZGlyZWN0 X3VyaTwvc3Bhbng+IHBhcmFtZXRlciB3YXMgaW5jbHVkZWQgaW4gdGhlIGluaXRpYWwKICAgICAg ICAgICAgICAgIGF1dGhvcml6YXRpb24gcmVxdWVzdCBhcyBkZXNjcmliZWQgaW4gPHhyZWYgdGFy Z2V0PSdjb2RlLWF1dGh6LXJlcScgLz4sIGFuZCBpZgogICAgICAgICAgICAgICAgaW5jbHVkZWQg ZW5zdXJlIHRoZWlyIHZhbHVlcyBhcmUgaWRlbnRpY2FsLgogICAgICAgICAgICAgIDwvdD4KICAg ICAgICAgICAgPC9saXN0PgogICAgICAgICAgPC90PgogICAgICAgIDwvc2VjdGlvbj4KCiAgICAg ICAgPHNlY3Rpb24gdGl0bGU9J0FjY2VzcyBUb2tlbiBSZXNwb25zZSc+CiAgICAgICAgICA8dD4K ICAgICAgICAgICAgSWYgdGhlIGFjY2VzcyB0b2tlbiByZXF1ZXN0IGlzIHZhbGlkIGFuZCBhdXRo b3JpemVkLCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgaXNzdWVzIGFuCiAgICAgICAgICAgIGFj Y2VzcyB0b2tlbiBhbmQgb3B0aW9uYWwgcmVmcmVzaCB0b2tlbiBhcyBkZXNjcmliZWQgaW4gPHhy ZWYgdGFyZ2V0PSd0b2tlbi1yZXNwb25zZScgLz4uCiAgICAgICAgICAgIElmIHRoZSByZXF1ZXN0 IGNsaWVudCBhdXRoZW50aWNhdGlvbiBmYWlsZWQgb3IgaXMgaW52YWxpZCwgdGhlIGF1dGhvcml6 YXRpb24gc2VydmVyIHJldHVybnMKICAgICAgICAgICAgYW4gZXJyb3IgcmVzcG9uc2UgYXMgZGVz Y3JpYmVkIGluIDx4cmVmIHRhcmdldD0ndG9rZW4tZXJyb3JzJyAvPi4KICAgICAgICAgIDwvdD4K ICAgICAgICAgIDxmaWd1cmU+CiAgICAgICAgICAgIDxwcmVhbWJsZT4KICAgICAgICAgICAgICBB biBleGFtcGxlIHN1Y2Nlc3NmdWwgcmVzcG9uc2U6CiAgICAgICAgICAgIDwvcHJlYW1ibGU+CiAg ICAgICAgICAgIDxhcnR3b3JrPgogICAgICAgICAgICAgIDwhW0NEQVRBWwogIEhUVFAvMS4xIDIw MCBPSwogIENvbnRlbnQtVHlwZTogYXBwbGljYXRpb24vanNvbjtjaGFyc2V0PVVURi04CiAgQ2Fj aGUtQ29udHJvbDogbm8tc3RvcmUKICBQcmFnbWE6IG5vLWNhY2hlCgogIHsKICAgICJhY2Nlc3Nf dG9rZW4iOiIyWW90bkZaRkVqcjF6Q3NpY01XcEFBIiwKICAgICJ0b2tlbl90eXBlIjoiZXhhbXBs ZSIsCiAgICAiZXhwaXJlc19pbiI6MzYwMCwKICAgICJyZWZyZXNoX3Rva2VuIjoidEd6djNKT2tG MFhHNVF4MlRsS1dJQSIsCiAgICAiZXhhbXBsZV9wYXJhbWV0ZXIiOiJleGFtcGxlX3ZhbHVlIgog IH0KXV0+CiAgICAgICAgICAgIDwvYXJ0d29yaz4KICAgICAgICAgIDwvZmlndXJlPgogICAgICAg IDwvc2VjdGlvbj4KCiAgICAgIDwvc2VjdGlvbj4KCiAgICAgIDxzZWN0aW9uIHRpdGxlPSdJbXBs aWNpdCBHcmFudCcgYW5jaG9yPSdncmFudC1pbXBsaWNpdCc+CiAgICAgICAgPHQ+CiAgICAgICAg ICBUaGUgaW1wbGljaXQgZ3JhbnQgdHlwZSBpcyB1c2VkIHRvIG9idGFpbiBhY2Nlc3MgdG9rZW5z IChpdCBkb2VzIG5vdCBzdXBwb3J0IHRoZSBpc3N1YW5jZQogICAgICAgICAgb2YgcmVmcmVzaCB0 b2tlbnMpIGFuZCBpcyBvcHRpbWl6ZWQgZm9yIHB1YmxpYyBjbGllbnRzIGtub3duIHRvIG9wZXJh dGUgYSBwYXJ0aWN1bGFyCiAgICAgICAgICByZWRpcmVjdGlvbiBVUkkuIFRoZXNlIGNsaWVudHMg YXJlIHR5cGljYWxseSBpbXBsZW1lbnRlZCBpbiBhIGJyb3dzZXIgdXNpbmcgYSBzY3JpcHRpbmcK ICAgICAgICAgIGxhbmd1YWdlIHN1Y2ggYXMgSmF2YVNjcmlwdC4KICAgICAgICA8L3Q+CiAgICAg ICAgPHQ+CiAgICAgICAgICBBcyBhIHJlZGlyZWN0aW9uLWJhc2VkIGZsb3csIHRoZSBjbGllbnQg bXVzdCBiZSBjYXBhYmxlIG9mIGludGVyYWN0aW5nIHdpdGggdGhlCiAgICAgICAgICByZXNvdXJj ZSBvd25lcidzIHVzZXItYWdlbnQgKHR5cGljYWxseSBhIHdlYiBicm93c2VyKSBhbmQgY2FwYWJs ZSBvZiByZWNlaXZpbmcgaW5jb21pbmcKICAgICAgICAgIHJlcXVlc3RzICh2aWEgcmVkaXJlY3Rp b24pIGZyb20gdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLgogICAgICAgIDwvdD4KICAgICAgICA8 dD4KICAgICAgICAgIFVubGlrZSB0aGUgYXV0aG9yaXphdGlvbiBjb2RlIGdyYW50IHR5cGUgaW4g d2hpY2ggdGhlIGNsaWVudCBtYWtlcyBzZXBhcmF0ZSByZXF1ZXN0cyBmb3IKICAgICAgICAgIGF1 dGhvcml6YXRpb24gYW5kIGFjY2VzcyB0b2tlbiwgdGhlIGNsaWVudCByZWNlaXZlcyB0aGUgYWNj ZXNzIHRva2VuIGFzIHRoZSByZXN1bHQgb2YgdGhlCiAgICAgICAgICBhdXRob3JpemF0aW9uIHJl cXVlc3QuCiAgICAgICAgPC90PgogICAgICAgIDx0PgogICAgICAgICAgVGhlIGltcGxpY2l0IGdy YW50IHR5cGUgZG9lcyBub3QgaW5jbHVkZSBjbGllbnQgYXV0aGVudGljYXRpb24sIGFuZCByZWxp ZXMgb24gdGhlCiAgICAgICAgICBwcmVzZW5jZSBvZiB0aGUgcmVzb3VyY2Ugb3duZXIgYW5kIHRo ZSByZWdpc3RyYXRpb24gb2YgdGhlIHJlZGlyZWN0aW9uIFVSSS4gQmVjYXVzZSB0aGUKICAgICAg ICAgIGFjY2VzcyB0b2tlbiBpcyBlbmNvZGVkIGludG8gdGhlIHJlZGlyZWN0aW9uIFVSSSwgaXQg bWF5IGJlIGV4cG9zZWQgdG8gdGhlIHJlc291cmNlIG93bmVyCiAgICAgICAgICBhbmQgb3RoZXIg YXBwbGljYXRpb25zIHJlc2lkaW5nIG9uIHRoZSBzYW1lIGRldmljZS4KICAgICAgICA8L3Q+CiAg ICAgICAgPGZpZ3VyZSB0aXRsZT0nSW1wbGljaXQgR3JhbnQgRmxvdycgYW5jaG9yPSdGaWd1cmUt NCc+CiAgICAgICAgICA8YXJ0d29yaz4KICAgICAgICAgICAgPCFbQ0RBVEFbCiAgKy0tLS0tLS0t LS0rCiAgfCBSZXNvdXJjZSB8CiAgfCAgT3duZXIgICB8CiAgfCAgICAgICAgICB8CiAgKy0tLS0t LS0tLS0rCiAgICAgICBeCiAgICAgICB8CiAgICAgIChCKSAgICAgIAogICstLS0tfC0tLS0tKyAg ICAgICAgICBDbGllbnQgSWRlbnRpZmllciAgICAgKy0tLS0tLS0tLS0tLS0tLSsKICB8ICAgICAg ICAgLSstLS0tKEEpLS0gJiBSZWRpcmVjdGlvbiBVUkkgLS0tPnwgICAgICAgICAgICAgICB8CiAg fCAgVXNlci0gICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IEF1dGhvcml6YXRp b24gfAogIHwgIEFnZW50ICAtfC0tLS0oQiktLSBVc2VyIGF1dGhlbnRpY2F0ZXMgLS0+fCAgICAg U2VydmVyICAgIHwKICB8ICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHwgICAgICAgICAgICAgICB8CiAgfCAgICAgICAgICB8PC0tLShDKS0tLSBSZWRpcmVjdGlvbiBV UkkgLS0tLTx8ICAgICAgICAgICAgICAgfAogIHwgICAgICAgICAgfCAgICAgICAgICB3aXRoIEFj Y2VzcyBUb2tlbiAgICAgKy0tLS0tLS0tLS0tLS0tLSsKICB8ICAgICAgICAgIHwgICAgICAgICAg ICBpbiBGcmFnbWVudAogIHwgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgKy0tLS0tLS0tLS0tLS0tLSsKICB8ICAgICAgICAgIHwtLS0tKEQpLS0tIFJlZGlyZWN0aW9u IFVSSSAtLS0tPnwgICBXZWItSG9zdGVkICB8CiAgfCAgICAgICAgICB8ICAgICAgICAgIHdpdGhv dXQgRnJhZ21lbnQgICAgICB8ICAgICBDbGllbnQgICAgfAogIHwgICAgICAgICAgfCAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgfCAgICBSZXNvdXJjZSAgIHwKICB8ICAgICAoRikgIHw8 LS0tKEUpLS0tLS0tLSBTY3JpcHQgLS0tLS0tLS0tPHwgICAgICAgICAgICAgICB8CiAgfCAgICAg ICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tKwog ICstfC0tLS0tLS0tKwogICAgfCAgICB8ICAgIAogICAoQSkgIChHKSBBY2Nlc3MgVG9rZW4KICAg IHwgICAgfAogICAgXiAgICB2CiAgKy0tLS0tLS0tLSsKICB8ICAgICAgICAgfAogIHwgIENsaWVu dCB8CiAgfCAgICAgICAgIHwKICArLS0tLS0tLS0tKwpdXT4KICAgICAgICAgIDwvYXJ0d29yaz4K ICAgICAgICAgIDxwb3N0YW1ibGU+CiAgICAgICAgICAgIE5vdGU6IFRoZSBsaW5lcyBpbGx1c3Ry YXRpbmcgc3RlcHMgQSBhbmQgQiBhcmUgYnJva2VuIGludG8gdHdvIHBhcnRzIGFzIHRoZXkgcGFz cwogICAgICAgICAgICB0aHJvdWdoIHRoZSB1c2VyLWFnZW50LgogICAgICAgICAgPC9wb3N0YW1i bGU+CiAgICAgICAgPC9maWd1cmU+CiAgICAgICAgPHQ+CiAgICAgICAgICBUaGUgZmxvdyBpbGx1 c3RyYXRlZCBpbiA8eHJlZiB0YXJnZXQ9J0ZpZ3VyZS00JyAvPiBpbmNsdWRlcyB0aGUgZm9sbG93 aW5nIHN0ZXBzOgogICAgICAgIDwvdD4KICAgICAgICA8dD4KICAgICAgICAgIDxsaXN0IHN0eWxl PSdmb3JtYXQgKCVDKSc+CiAgICAgICAgICAgIDx0PgogICAgICAgICAgICAgIFRoZSBjbGllbnQg aW5pdGlhdGVzIHRoZSBmbG93IGJ5IGRpcmVjdGluZyB0aGUgcmVzb3VyY2Ugb3duZXIncyB1c2Vy LWFnZW50IHRvIHRoZQogICAgICAgICAgICAgIGF1dGhvcml6YXRpb24gZW5kcG9pbnQuIFRoZSBj bGllbnQgaW5jbHVkZXMgaXRzIGNsaWVudCBpZGVudGlmaWVyLCByZXF1ZXN0ZWQKICAgICAgICAg ICAgICBzY29wZSwgbG9jYWwgc3RhdGUsIGFuZCBhIHJlZGlyZWN0aW9uIFVSSSB0byB3aGljaCB0 aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgd2lsbCBzZW5kCiAgICAgICAgICAgICAgdGhlIHVzZXIt YWdlbnQgYmFjayBvbmNlIGFjY2VzcyBpcyBncmFudGVkIChvciBkZW5pZWQpLgogICAgICAgICAg ICA8L3Q+CiAgICAgICAgICAgIDx0PgogICAgICAgICAgICAgIFRoZSBhdXRob3JpemF0aW9uIHNl cnZlciBhdXRoZW50aWNhdGVzIHRoZSByZXNvdXJjZSBvd25lciAodmlhIHRoZSB1c2VyLWFnZW50 KSBhbmQKICAgICAgICAgICAgICBlc3RhYmxpc2hlcyB3aGV0aGVyIHRoZSByZXNvdXJjZSBvd25l ciBncmFudHMgb3IgZGVuaWVzIHRoZSBjbGllbnQncyBhY2Nlc3MgcmVxdWVzdC4KICAgICAgICAg ICAgPC90PgogICAgICAgICAgICA8dD4KICAgICAgICAgICAgICBBc3N1bWluZyB0aGUgcmVzb3Vy Y2Ugb3duZXIgZ3JhbnRzIGFjY2VzcywgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHJlZGlyZWN0 cyB0aGUKICAgICAgICAgICAgICB1c2VyLWFnZW50IGJhY2sgdG8gdGhlIGNsaWVudCB1c2luZyB0 aGUgcmVkaXJlY3Rpb24gVVJJIHByb3ZpZGVkIGVhcmxpZXIuIFRoZQogICAgICAgICAgICAgIHJl ZGlyZWN0aW9uIFVSSSBpbmNsdWRlcyB0aGUgYWNjZXNzIHRva2VuIGluIHRoZSBVUkkgZnJhZ21l bnQuCiAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAgPHQ+CiAgICAgICAgICAgICAgVGhlIHVz ZXItYWdlbnQgZm9sbG93cyB0aGUgcmVkaXJlY3Rpb24gaW5zdHJ1Y3Rpb25zIGJ5IG1ha2luZyBh IHJlcXVlc3QgdG8gdGhlCiAgICAgICAgICAgICAgd2ViLWhvc3RlZCBjbGllbnQgcmVzb3VyY2Ug KHdoaWNoIGRvZXMgbm90IGluY2x1ZGUgdGhlIGZyYWdtZW50IHBlcgogICAgICAgICAgICAgIDx4 cmVmIHRhcmdldD0nUkZDMjYxNicgLz4pLiBUaGUgdXNlci1hZ2VudCByZXRhaW5zIHRoZSBmcmFn bWVudCBpbmZvcm1hdGlvbiBsb2NhbGx5LgogICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgIDx0 PgogICAgICAgICAgICAgIFRoZSB3ZWItaG9zdGVkIGNsaWVudCByZXNvdXJjZSByZXR1cm5zIGEg d2ViIHBhZ2UgKHR5cGljYWxseSBhbiBIVE1MIGRvY3VtZW50IHdpdGggYW4KICAgICAgICAgICAg ICBlbWJlZGRlZCBzY3JpcHQpIGNhcGFibGUgb2YgYWNjZXNzaW5nIHRoZSBmdWxsIHJlZGlyZWN0 aW9uIFVSSSBpbmNsdWRpbmcgdGhlIGZyYWdtZW50CiAgICAgICAgICAgICAgcmV0YWluZWQgYnkg dGhlIHVzZXItYWdlbnQsIGFuZCBleHRyYWN0aW5nIHRoZSBhY2Nlc3MgdG9rZW4gKGFuZCBvdGhl ciBwYXJhbWV0ZXJzKQogICAgICAgICAgICAgIGNvbnRhaW5lZCBpbiB0aGUgZnJhZ21lbnQuCiAg ICAgICAgICAgIDwvdD4KICAgICAgICAgICAgPHQ+CiAgICAgICAgICAgICAgVGhlIHVzZXItYWdl bnQgZXhlY3V0ZXMgdGhlIHNjcmlwdCBwcm92aWRlZCBieSB0aGUgd2ViLWhvc3RlZCBjbGllbnQg cmVzb3VyY2UKICAgICAgICAgICAgICBsb2NhbGx5LCB3aGljaCBleHRyYWN0cyB0aGUgYWNjZXNz IHRva2VuIGFuZCBwYXNzZXMgaXQgdG8gdGhlIGNsaWVudC4KICAgICAgICAgICAgPC90PgogICAg ICAgICAgPC9saXN0PgogICAgICAgIDwvdD4KCiAgICAgICAgPHNlY3Rpb24gdGl0bGU9J0F1dGhv cml6YXRpb24gUmVxdWVzdCcgYW5jaG9yPSdpbXBsaWNpdC1hdXRoei1yZXEnPgogICAgICAgICAg PHQ+CiAgICAgICAgICAgIFRoZSBjbGllbnQgY29uc3RydWN0cyB0aGUgcmVxdWVzdCBVUkkgYnkg YWRkaW5nIHRoZSBmb2xsb3dpbmcgcGFyYW1ldGVycyB0byB0aGUKICAgICAgICAgICAgcXVlcnkg Y29tcG9uZW50IG9mIHRoZSBhdXRob3JpemF0aW9uIGVuZHBvaW50IFVSSSB1c2luZyB0aGUKICAg ICAgICAgICAgPHNwYW54IHN0eWxlPSd2ZXJiJz5hcHBsaWNhdGlvbi94LXd3dy1mb3JtLXVybGVu Y29kZWQ8L3NwYW54PiBmb3JtYXQ6CiAgICAgICAgICA8L3Q+CiAgICAgICAgICA8dD4KICAgICAg ICAgICAgPGxpc3Qgc3R5bGU9J2hhbmdpbmcnIGhhbmdJbmRlbnQ9JzYnPgogICAgICAgICAgICAg IDx0IGhhbmdUZXh0PSdyZXNwb25zZV90eXBlJz4KICAgICAgICAgICAgICAgIDx2c3BhY2UgLz4K ICAgICAgICAgICAgICAgIFJFUVVJUkVELiBWYWx1ZSBNVVNUIGJlIHNldCB0byA8c3Bhbnggc3R5 bGU9J3ZlcmInPnRva2VuPC9zcGFueD4uCiAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICAg IDx0IGhhbmdUZXh0PSdjbGllbnRfaWQnPgogICAgICAgICAgICAgICAgPHZzcGFjZSAvPgogICAg ICAgICAgICAgICAgUkVRVUlSRUQuIFRoZSBjbGllbnQgaWRlbnRpZmllciBhcyBkZXNjcmliZWQg aW4KICAgICAgICAgICAgICAgIDx4cmVmIHRhcmdldD0nY2xpZW50LWlkZW50aWZpZXInIC8+Lgog ICAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAgICA8dCBoYW5nVGV4dD0ncmVkaXJlY3RfdXJp Jz4KICAgICAgICAgICAgICAgIDx2c3BhY2UgLz4KICAgICAgICAgICAgICAgIE9QVElPTkFMLiBB cyBkZXNjcmliZWQgaW4gPHhyZWYgdGFyZ2V0PSdyZWRpcmVjdC11cmknIC8+LgogICAgICAgICAg ICAgIDwvdD4KICAgICAgICAgICAgICA8dCBoYW5nVGV4dD0nc2NvcGUnPgogICAgICAgICAgICAg ICAgPHZzcGFjZSAvPgogICAgICAgICAgICAgICAgT1BUSU9OQUwuIFRoZSBzY29wZSBvZiB0aGUg YWNjZXNzIHJlcXVlc3QgYXMgZGVzY3JpYmVkIGJ5IDx4cmVmIHRhcmdldD0nc2NvcGUnIC8+Lgog ICAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAgICA8dCBoYW5nVGV4dD0nc3RhdGUnPgogICAg ICAgICAgICAgICAgPHZzcGFjZSAvPgogICAgICAgICAgICAgICAgUkVDT01NRU5ERUQuIEFuIG9w YXF1ZSB2YWx1ZSB1c2VkIGJ5IHRoZSBjbGllbnQgdG8gbWFpbnRhaW4gc3RhdGUgYmV0d2VlbiB0 aGUgcmVxdWVzdAogICAgICAgICAgICAgICAgYW5kIGNhbGxiYWNrLiBUaGUgYXV0aG9yaXphdGlv biBzZXJ2ZXIgaW5jbHVkZXMgdGhpcyB2YWx1ZSB3aGVuIHJlZGlyZWN0aW5nIHRoZQogICAgICAg ICAgICAgICAgdXNlci1hZ2VudCBiYWNrIHRvIHRoZSBjbGllbnQuIFRoZSBwYXJhbWV0ZXIgU0hP VUxEIGJlIHVzZWQgZm9yIHByZXZlbnRpbmcKICAgICAgICAgICAgICAgIGNyb3NzLXNpdGUgcmVx dWVzdCBmb3JnZXJ5IGFzIGRlc2NyaWJlZCBpbiA8eHJlZiB0YXJnZXQ9J0NTUkYnIC8+LgogICAg ICAgICAgICAgIDwvdD4KICAgICAgICAgICAgPC9saXN0PgogICAgICAgICAgPC90PgogICAgICAg ICAgPHQ+CiAgICAgICAgICAgIFRoZSBjbGllbnQgZGlyZWN0cyB0aGUgcmVzb3VyY2Ugb3duZXIg dG8gdGhlIGNvbnN0cnVjdGVkIFVSSSB1c2luZyBhbiBIVFRQIHJlZGlyZWN0aW9uCiAgICAgICAg ICAgIHJlc3BvbnNlLCBvciBieSBvdGhlciBtZWFucyBhdmFpbGFibGUgdG8gaXQgdmlhIHRoZSB1 c2VyLWFnZW50LgogICAgICAgICAgPC90PgogICAgICAgICAgPGZpZ3VyZT4KICAgICAgICAgICAg PHByZWFtYmxlPgogICAgICAgICAgICAgIEZvciBleGFtcGxlLCB0aGUgY2xpZW50IGRpcmVjdHMg dGhlIHVzZXItYWdlbnQgdG8gbWFrZSB0aGUgZm9sbG93aW5nIEhUVFAgcmVxdWVzdAogICAgICAg ICAgICAgIHVzaW5nIFRMUyAoZXh0cmEgbGluZSBicmVha3MgYXJlIGZvciBkaXNwbGF5IHB1cnBv c2VzIG9ubHkpOgogICAgICAgICAgICA8L3ByZWFtYmxlPgogICAgICAgICAgICA8YXJ0d29yaz4K ICAgICAgICAgICAgICA8IVtDREFUQVsKICBHRVQgL2F1dGhvcml6ZT9yZXNwb25zZV90eXBlPXRv a2VuJmNsaWVudF9pZD1zNkJoZFJrcXQzJnN0YXRlPXh5egogICAgICAmcmVkaXJlY3RfdXJpPWh0 dHBzJTNBJTJGJTJGY2xpZW50JTJFZXhhbXBsZSUyRWNvbSUyRmNiIEhUVFAvMS4xCiAgSG9zdDog c2VydmVyLmV4YW1wbGUuY29tCl1dPgogICAgICAgICAgICA8L2FydHdvcms+CiAgICAgICAgICA8 L2ZpZ3VyZT4KICAgICAgICAgIDx0PgogICAgICAgICAgICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2 ZXIgdmFsaWRhdGVzIHRoZSByZXF1ZXN0IHRvIGVuc3VyZSBhbGwgcmVxdWlyZWQgcGFyYW1ldGVy cyBhcmUKICAgICAgICAgICAgcHJlc2VudCBhbmQgdmFsaWQuIFRoZSBhdXRob3JpemF0aW9uIHNl cnZlciBNVVNUIHZlcmlmeSB0aGF0IHRoZSByZWRpcmVjdGlvbiBVUkkgdG8gd2hpY2gKICAgICAg ICAgICAgaXQgd2lsbCByZWRpcmVjdCB0aGUgYWNjZXNzIHRva2VuIG1hdGNoZXMgYSByZWRpcmVj dGlvbiBVUkkgcmVnaXN0ZXJlZCBieSB0aGUgY2xpZW50IGFzCiAgICAgICAgICAgIGRlc2NyaWJl ZCBpbiA8eHJlZiB0YXJnZXQ9J3JlZGlyZWN0LXVyaScgLz4uCiAgICAgICAgICA8L3Q+CiAgICAg ICAgICA8dD4KICAgICAgICAgICAgSWYgdGhlIHJlcXVlc3QgaXMgdmFsaWQsIHRoZSBhdXRob3Jp emF0aW9uIHNlcnZlciBhdXRoZW50aWNhdGVzIHRoZSByZXNvdXJjZSBvd25lciBhbmQKICAgICAg ICAgICAgb2J0YWlucyBhbiBhdXRob3JpemF0aW9uIGRlY2lzaW9uIChieSBhc2tpbmcgdGhlIHJl c291cmNlIG93bmVyIG9yIGJ5IGVzdGFibGlzaGluZwogICAgICAgICAgICBhcHByb3ZhbCB2aWEg b3RoZXIgbWVhbnMpLgogICAgICAgICAgPC90PgogICAgICAgICAgPHQ+CiAgICAgICAgICAgIFdo ZW4gYSBkZWNpc2lvbiBpcyBlc3RhYmxpc2hlZCwgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGRp cmVjdHMgdGhlIHVzZXItYWdlbnQgdG8gdGhlCiAgICAgICAgICAgIHByb3ZpZGVkIGNsaWVudCBy ZWRpcmVjdGlvbiBVUkkgdXNpbmcgYW4gSFRUUCByZWRpcmVjdGlvbiByZXNwb25zZSwgb3IgYnkg b3RoZXIgbWVhbnMKICAgICAgICAgICAgYXZhaWxhYmxlIHRvIGl0IHZpYSB0aGUgdXNlci1hZ2Vu dC4KICAgICAgICAgIDwvdD4KICAgICAgICA8L3NlY3Rpb24+CgogICAgICAgIDxzZWN0aW9uIHRp dGxlPSdBY2Nlc3MgVG9rZW4gUmVzcG9uc2UnIGFuY2hvcj0iaW1wbGljaXQtYXV0aHotcmVzcCI+ CiAgICAgICAgICA8dD4KICAgICAgICAgICAgSWYgdGhlIHJlc291cmNlIG93bmVyIGdyYW50cyB0 aGUgYWNjZXNzIHJlcXVlc3QsIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBpc3N1ZXMgYW4KICAg ICAgICAgICAgYWNjZXNzIHRva2VuIGFuZCBkZWxpdmVycyBpdCB0byB0aGUgY2xpZW50IGJ5IGFk ZGluZyB0aGUgZm9sbG93aW5nIHBhcmFtZXRlcnMgdG8KICAgICAgICAgICAgdGhlIGZyYWdtZW50 IGNvbXBvbmVudCBvZiB0aGUgcmVkaXJlY3Rpb24gVVJJIHVzaW5nIHRoZQogICAgICAgICAgICA8 c3Bhbnggc3R5bGU9J3ZlcmInPmFwcGxpY2F0aW9uL3gtd3d3LWZvcm0tdXJsZW5jb2RlZDwvc3Bh bng+IGZvcm1hdDoKICAgICAgICAgIDwvdD4KICAgICAgICAgIDx0PgogICAgICAgICAgICA8bGlz dCBzdHlsZT0naGFuZ2luZycgaGFuZ0luZGVudD0nNic+CiAgICAgICAgICAgICAgPHQgaGFuZ1Rl eHQ9J2FjY2Vzc190b2tlbic+CiAgICAgICAgICAgICAgICA8dnNwYWNlIC8+CiAgICAgICAgICAg ICAgICBSRVFVSVJFRC4gVGhlIGFjY2VzcyB0b2tlbiBpc3N1ZWQgYnkgdGhlIGF1dGhvcml6YXRp b24gc2VydmVyLgogICAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAgICA8dCBoYW5nVGV4dD0n dG9rZW5fdHlwZSc+CiAgICAgICAgICAgICAgICA8dnNwYWNlIC8+CiAgICAgICAgICAgICAgICBS RVFVSVJFRC4gVGhlIHR5cGUgb2YgdGhlIHRva2VuIGlzc3VlZCBhcyBkZXNjcmliZWQgaW4KICAg ICAgICAgICAgICAgIDx4cmVmIHRhcmdldD0ndG9rZW4tdHlwZXMnIC8+LiBWYWx1ZSBpcyBjYXNl IGluc2Vuc2l0aXZlLgogICAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAgICA8dCBoYW5nVGV4 dD0nZXhwaXJlc19pbic+CiAgICAgICAgICAgICAgICA8dnNwYWNlIC8+CiAgICAgICAgICAgICAg ICBSRUNPTU1FTkRFRC4gVGhlIGxpZmV0aW1lIGluIHNlY29uZHMgb2YgdGhlIGFjY2VzcyB0b2tl bi4gRm9yIGV4YW1wbGUsIHRoZSB2YWx1ZQogICAgICAgICAgICAgICAgPHNwYW54IHN0eWxlPSd2 ZXJiJz4zNjAwPC9zcGFueD4gZGVub3RlcyB0aGF0IHRoZSBhY2Nlc3MgdG9rZW4gd2lsbCBleHBp cmUgaW4gb25lCiAgICAgICAgICAgICAgICBob3VyIGZyb20gdGhlIHRpbWUgdGhlIHJlc3BvbnNl IHdhcyBnZW5lcmF0ZWQuIElmIG9taXR0ZWQsIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlcgogICAg ICAgICAgICAgICAgU0hPVUxEIHByb3ZpZGUgdGhlIGV4cGlyYXRpb24gdGltZSB2aWEgb3RoZXIg bWVhbnMgb3IgZG9jdW1lbnQgdGhlIGRlZmF1bHQgdmFsdWUuCiAgICAgICAgICAgICAgPC90Pgog ICAgICAgICAgICAgIDx0IGhhbmdUZXh0PSdzY29wZSc+CiAgICAgICAgICAgICAgICA8dnNwYWNl IC8+CiAgICAgICAgICAgICAgICBPUFRJT05BTCwgaWYgaWRlbnRpY2FsIHRvIHRoZSBzY29wZSBy ZXF1ZXN0ZWQgYnkgdGhlIGNsaWVudCwgb3RoZXJ3aXNlIFJFUVVJUkVELiBUaGUKICAgICAgICAg ICAgICAgIHNjb3BlIG9mIHRoZSBhY2Nlc3MgdG9rZW4gYXMgZGVzY3JpYmVkIGJ5IDx4cmVmIHRh cmdldD0nc2NvcGUnIC8+LgogICAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAgICA8dCBoYW5n VGV4dD0nc3RhdGUnPgogICAgICAgICAgICAgICAgPHZzcGFjZSAvPgogICAgICAgICAgICAgICAg UkVRVUlSRUQgaWYgdGhlIDxzcGFueCBzdHlsZT0ndmVyYic+c3RhdGU8L3NwYW54PiBwYXJhbWV0 ZXIgd2FzIHByZXNlbnQgaW4gdGhlCiAgICAgICAgICAgICAgICBjbGllbnQgYXV0aG9yaXphdGlv biByZXF1ZXN0LiBUaGUgZXhhY3QgdmFsdWUgcmVjZWl2ZWQgZnJvbSB0aGUgY2xpZW50LgogICAg ICAgICAgICAgIDwvdD4KICAgICAgICAgICAgPC9saXN0PgogICAgICAgICAgPC90PgogICAgICAg ICAgPHQ+CiAgICAgICAgICAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBNVVNUIE5PVCBpc3N1 ZSBhIHJlZnJlc2ggdG9rZW4uCiAgICAgICAgICA8L3Q+CiAgICAgICAgICA8ZmlndXJlPgogICAg ICAgICAgICA8cHJlYW1ibGU+CiAgICAgICAgICAgICAgRm9yIGV4YW1wbGUsIHRoZSBhdXRob3Jp emF0aW9uIHNlcnZlciByZWRpcmVjdHMgdGhlIHVzZXItYWdlbnQgYnkgc2VuZGluZyB0aGUKICAg ICAgICAgICAgICBmb2xsb3dpbmcgSFRUUCByZXNwb25zZSAoVVJJIGV4dHJhIGxpbmUgYnJlYWtz IGFyZSBmb3IgZGlzcGxheSBwdXJwb3NlcyBvbmx5KToKICAgICAgICAgICAgPC9wcmVhbWJsZT4K ICAgICAgICAgICAgPGFydHdvcms+CiAgICAgICAgICAgICAgPCFbQ0RBVEFbCiAgSFRUUC8xLjEg MzAyIEZvdW5kCiAgTG9jYXRpb246IGh0dHA6Ly9leGFtcGxlLmNvbS9jYiNhY2Nlc3NfdG9rZW49 MllvdG5GWkZFanIxekNzaWNNV3BBQQogICAgICAgICAgICAmc3RhdGU9eHl6JnRva2VuX3R5cGU9 ZXhhbXBsZSZleHBpcmVzX2luPTM2MDAKXV0+CiAgICAgICAgICAgIDwvYXJ0d29yaz4KICAgICAg ICAgICAgPHBvc3RhbWJsZT4KICAgICAgICAgICAgICBEZXZlbG9wZXJzIHNob3VsZCBub3RlIHRo YXQgc29tZSB1c2VyLWFnZW50cyBkbyBub3Qgc3VwcG9ydCB0aGUgaW5jbHVzaW9uIG9mIGEKICAg ICAgICAgICAgICBmcmFnbWVudCBjb21wb25lbnQgaW4gdGhlIEhUVFAgPHNwYW54IHN0eWxlPSd2 ZXJiJz5Mb2NhdGlvbjwvc3Bhbng+IHJlc3BvbnNlIGhlYWRlcgogICAgICAgICAgICAgIGZpZWxk LiBTdWNoIGNsaWVudHMgd2lsbCByZXF1aXJlIHVzaW5nIG90aGVyIG1ldGhvZHMgZm9yIHJlZGly ZWN0aW5nIHRoZSBjbGllbnQgdGhhbgogICAgICAgICAgICAgIGEgM3h4IHJlZGlyZWN0aW9uIHJl c3BvbnNlLiBGb3IgZXhhbXBsZSwgcmV0dXJuaW5nIGFuIEhUTUwgcGFnZSB3aGljaCBpbmNsdWRl cyBhCiAgICAgICAgICAgICAgJ2NvbnRpbnVlJyBidXR0b24gd2l0aCBhbiBhY3Rpb24gbGlua2Vk IHRvIHRoZSByZWRpcmVjdGlvbiBVUkkuCiAgICAgICAgICAgIDwvcG9zdGFtYmxlPgogICAgICAg ICAgPC9maWd1cmU+CiAgICAgICAgICA8dD4KICAgICAgICAgICAgVGhlIGNsaWVudCBNVVNUIGln bm9yZSB1bnJlY29nbml6ZWQgcmVzcG9uc2UgcGFyYW1ldGVycy4gVGhlIGFjY2VzcyB0b2tlbiBz dHJpbmcgc2l6ZQogICAgICAgICAgICBpcyBsZWZ0IHVuZGVmaW5lZCBieSB0aGlzIHNwZWNpZmlj YXRpb24uIFRoZSBjbGllbnQgc2hvdWxkIGF2b2lkIG1ha2luZyBhc3N1bXB0aW9ucwogICAgICAg ICAgICBhYm91dCB2YWx1ZSBzaXplcy4gVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIFNIT1VMRCBk b2N1bWVudCB0aGUgc2l6ZSBvZiBhbnkgdmFsdWUgaXQKICAgICAgICAgICAgaXNzdWVzLgogICAg ICAgICAgPC90PgoKICAgICAgICAgIDxzZWN0aW9uIHRpdGxlPSdFcnJvciBSZXNwb25zZScgYW5j aG9yPSdpbXBsaWNpdC1hdXRoei1lcnJvcic+CiAgICAgICAgICAgIDx0PgogICAgICAgICAgICAg IElmIHRoZSByZXF1ZXN0IGZhaWxzIGR1ZSB0byBhIG1pc3NpbmcsIGludmFsaWQsIG9yIG1pc21h dGNoaW5nIHJlZGlyZWN0aW9uIFVSSSwgb3IgaWYKICAgICAgICAgICAgICB0aGUgY2xpZW50IGlk ZW50aWZpZXIgaXMgbWlzc2luZyBvciBpbnZhbGlkLCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIg U0hPVUxEIGluZm9ybQogICAgICAgICAgICAgIHRoZSByZXNvdXJjZSBvd25lciBvZiB0aGUgZXJy b3IsIGFuZCBNVVNUIE5PVCBhdXRvbWF0aWNhbGx5IHJlZGlyZWN0IHRoZSB1c2VyLWFnZW50CiAg ICAgICAgICAgICAgdG8gdGhlIGludmFsaWQgcmVkaXJlY3Rpb24gVVJJLgogICAgICAgICAgICA8 L3Q+CiAgICAgICAgICAgIDx0PgogICAgICAgICAgICAgIElmIHRoZSByZXNvdXJjZSBvd25lciBk ZW5pZXMgdGhlIGFjY2VzcyByZXF1ZXN0IG9yIGlmIHRoZSByZXF1ZXN0IGZhaWxzIGZvciByZWFz b25zCiAgICAgICAgICAgICAgb3RoZXIgdGhhbiBhIG1pc3Npbmcgb3IgaW52YWxpZCByZWRpcmVj dGlvbiBVUkksIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBpbmZvcm1zIHRoZQogICAgICAgICAg ICAgIGNsaWVudCBieSBhZGRpbmcgdGhlIGZvbGxvd2luZyBwYXJhbWV0ZXJzIHRvIHRoZSBmcmFn bWVudCBjb21wb25lbnQgb2YgdGhlCiAgICAgICAgICAgICAgcmVkaXJlY3Rpb24gVVJJIHVzaW5n IHRoZQogICAgICAgICAgICAgIDxzcGFueCBzdHlsZT0ndmVyYic+YXBwbGljYXRpb24veC13d3ct Zm9ybS11cmxlbmNvZGVkPC9zcGFueD4gZm9ybWF0OgogICAgICAgICAgICA8L3Q+CiAgICAgICAg ICAgIDx0PgogICAgICAgICAgICAgIDxsaXN0IHN0eWxlPSdoYW5naW5nJyBoYW5nSW5kZW50PSc2 Jz4KICAgICAgICAgICAgICAgIDx0IGhhbmdUZXh0PSdlcnJvcic+CiAgICAgICAgICAgICAgICAg IDx2c3BhY2UgLz4KICAgICAgICAgICAgICAgICAgUkVRVUlSRUQuIEEgc2luZ2xlIEFTQ0lJIDx4 cmVmIHRhcmdldD0iVVNBU0NJSSIgLz4gZXJyb3IgY29kZSBmcm9tIHRoZSBmb2xsb3dpbmc6Cgog ICAgICAgICAgICAgICAgICA8bGlzdCBzdHlsZT0naGFuZ2luZycgaGFuZ0luZGVudD0nNic+CiAg ICAgICAgICAgICAgICAgICAgPHQgaGFuZ1RleHQ9J2ludmFsaWRfcmVxdWVzdCc+CiAgICAgICAg ICAgICAgICAgICAgICA8dnNwYWNlIC8+CiAgICAgICAgICAgICAgICAgICAgICBUaGUgcmVxdWVz dCBpcyBtaXNzaW5nIGEgcmVxdWlyZWQgcGFyYW1ldGVyLCBpbmNsdWRlcyBhbiBpbnZhbGlkCiAg ICAgICAgICAgICAgICAgICAgICBwYXJhbWV0ZXIgdmFsdWUsIGluY2x1ZGVzIGEgcGFyYW1ldGVy IG1vcmUgdGhhbiBvbmNlLCBvciBpcyBvdGhlcndpc2UgbWFsZm9ybWVkLgogICAgICAgICAgICAg ICAgICAgIDwvdD4KICAgICAgICAgICAgICAgICAgICA8dCBoYW5nVGV4dD0ndW5hdXRob3JpemVk X2NsaWVudCc+CiAgICAgICAgICAgICAgICAgICAgICA8dnNwYWNlIC8+CiAgICAgICAgICAgICAg ICAgICAgICBUaGUgY2xpZW50IGlzIG5vdCBhdXRob3JpemVkIHRvIHJlcXVlc3QgYW4gYWNjZXNz IHRva2VuIHVzaW5nIHRoaXMgbWV0aG9kLgogICAgICAgICAgICAgICAgICAgIDwvdD4KICAgICAg ICAgICAgICAgICAgICA8dCBoYW5nVGV4dD0nYWNjZXNzX2RlbmllZCc+CiAgICAgICAgICAgICAg ICAgICAgICA8dnNwYWNlIC8+CiAgICAgICAgICAgICAgICAgICAgICBUaGUgcmVzb3VyY2Ugb3du ZXIgb3IgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgZGVuaWVkIHRoZSByZXF1ZXN0LgogICAgICAgICAg ICAgICAgICAgIDwvdD4KICAgICAgICAgICAgICAgICAgICA8dCBoYW5nVGV4dD0ndW5zdXBwb3J0 ZWRfcmVzcG9uc2VfdHlwZSc+CiAgICAgICAgICAgICAgICAgICAgICA8dnNwYWNlIC8+CiAgICAg ICAgICAgICAgICAgICAgICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgZG9lcyBub3Qgc3VwcG9y dCBvYnRhaW5pbmcgYW4gYWNjZXNzIHRva2VuIHVzaW5nCiAgICAgICAgICAgICAgICAgICAgICB0 aGlzIG1ldGhvZC4KICAgICAgICAgICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgICAgICAgICAg PHQgaGFuZ1RleHQ9J2ludmFsaWRfc2NvcGUnPgogICAgICAgICAgICAgICAgICAgICAgPHZzcGFj ZSAvPgogICAgICAgICAgICAgICAgICAgICAgVGhlIHJlcXVlc3RlZCBzY29wZSBpcyBpbnZhbGlk LCB1bmtub3duLCBvciBtYWxmb3JtZWQuCiAgICAgICAgICAgICAgICAgICAgPC90PgogICAgICAg ICAgICAgICAgICAgIDx0IGhhbmdUZXh0PSdzZXJ2ZXJfZXJyb3InPgogICAgICAgICAgICAgICAg ICAgICAgPHZzcGFjZSAvPgogICAgICAgICAgICAgICAgICAgICAgVGhlIGF1dGhvcml6YXRpb24g c2VydmVyIGVuY291bnRlcmVkIGFuIHVuZXhwZWN0ZWQgY29uZGl0aW9uIHdoaWNoIHByZXZlbnRl ZAogICAgICAgICAgICAgICAgICAgICAgaXQgZnJvbSBmdWxmaWxsaW5nIHRoZSByZXF1ZXN0Lgog ICAgICAgICAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAgICAgICAgICA8dCBoYW5nVGV4dD0n dGVtcG9yYXJpbHlfdW5hdmFpbGFibGUnPgogICAgICAgICAgICAgICAgICAgICAgPHZzcGFjZSAv PgogICAgICAgICAgICAgICAgICAgICAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGlzIGN1cnJl bnRseSB1bmFibGUgdG8gaGFuZGxlIHRoZSByZXF1ZXN0IGR1ZSB0byBhCiAgICAgICAgICAgICAg ICAgICAgICB0ZW1wb3Jhcnkgb3ZlcmxvYWRpbmcgb3IgbWFpbnRlbmFuY2Ugb2YgdGhlIHNlcnZl ci4KICAgICAgICAgICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgICAgICAgIDwvbGlzdD4KCgkJ ICBWYWx1ZXMgZm9yIHRoZSA8c3Bhbnggc3R5bGU9J3ZlcmInPmVycm9yPC9zcGFueD4gcGFyYW1l dGVyIE1VU1QgTk9UIGluY2x1ZGUKCQkgIGNoYXJhY3RlcnMgb3V0c2lkZSB0aGUgc2V0ICV4MjAt MjEgLyAleDIzLTVCIC8gJXg1RC03RS4KICAgICAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAg ICAgIDx0IGhhbmdUZXh0PSdlcnJvcl9kZXNjcmlwdGlvbic+CiAgICAgICAgICAgICAgICAgIDx2 c3BhY2UgLz4KICAgICAgICAgICAgICAgICAgT1BUSU9OQUwuIEEgaHVtYW4tcmVhZGFibGUgQVND SUkgPHhyZWYgdGFyZ2V0PSJVU0FTQ0lJIiAvPiB0ZXh0IHByb3ZpZGluZyBhZGRpdGlvbmFsIGlu Zm9ybWF0aW9uLAogICAgICAgICAgICAgICAgICB1c2VkIHRvIGFzc2lzdCB0aGUgY2xpZW50IGRl dmVsb3BlciBpbiB1bmRlcnN0YW5kaW5nIHRoZSBlcnJvciB0aGF0IG9jY3VycmVkLgoJCSAgPHZz cGFjZS8+CgkJICBWYWx1ZXMgZm9yIHRoZSA8c3Bhbnggc3R5bGU9J3ZlcmInPmVycm9yX2Rlc2Ny aXB0aW9uPC9zcGFueD4gcGFyYW1ldGVyIE1VU1QgTk9UIGluY2x1ZGUKCQkgIGNoYXJhY3RlcnMg b3V0c2lkZSB0aGUgc2V0ICV4MjAtMjEgLyAleDIzLTVCIC8gJXg1RC03RS4KICAgICAgICAgICAg ICAgIDwvdD4KICAgICAgICAgICAgICAgIDx0IGhhbmdUZXh0PSdlcnJvcl91cmknPgogICAgICAg ICAgICAgICAgICA8dnNwYWNlIC8+CiAgICAgICAgICAgICAgICAgIE9QVElPTkFMLiBBIFVSSSBp ZGVudGlmeWluZyBhIGh1bWFuLXJlYWRhYmxlIHdlYiBwYWdlIHdpdGggaW5mb3JtYXRpb24gYWJv dXQgdGhlCiAgICAgICAgICAgICAgICAgIGVycm9yLCB1c2VkIHRvIHByb3ZpZGUgdGhlIGNsaWVu dCBkZXZlbG9wZXIgd2l0aCBhZGRpdGlvbmFsIGluZm9ybWF0aW9uIGFib3V0IHRoZQogICAgICAg ICAgICAgICAgICBlcnJvci4KCQkgIDx2c3BhY2UvPgoJCSAgVmFsdWVzIGZvciB0aGUgPHNwYW54 IHN0eWxlPSd2ZXJiJz5lcnJvcl91cmk8L3NwYW54PiBwYXJhbWV0ZXIKCQkgIE1VU1QgY29uZm9y bSB0byB0aGUgVVJJLVJlZmVyZW5jZSBzeW50YXgsIGFuZCB0aHVzIE1VU1QgTk9UIGluY2x1ZGUK CQkgIGNoYXJhY3RlcnMgb3V0c2lkZSB0aGUgc2V0ICV4MjEgLyAleDIzLTVCIC8gJXg1RC03RS4K ICAgICAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAgICAgIDx0IGhhbmdUZXh0PSdzdGF0ZSc+ CiAgICAgICAgICAgICAgICAgIDx2c3BhY2UgLz4KICAgICAgICAgICAgICAgICAgUkVRVUlSRUQg aWYgYSA8c3Bhbnggc3R5bGU9J3ZlcmInPnN0YXRlPC9zcGFueD4gcGFyYW1ldGVyIHdhcyBwcmVz ZW50IGluIHRoZQogICAgICAgICAgICAgICAgICBjbGllbnQgYXV0aG9yaXphdGlvbiByZXF1ZXN0 LiBUaGUgZXhhY3QgdmFsdWUgcmVjZWl2ZWQgZnJvbSB0aGUgY2xpZW50LgogICAgICAgICAgICAg ICAgPC90PgogICAgICAgICAgICAgIDwvbGlzdD4KICAgICAgICAgICAgPC90PgogICAgICAgICAg ICA8ZmlndXJlPgogICAgICAgICAgICAgIDxwcmVhbWJsZT4KICAgICAgICAgICAgICAgIEZvciBl eGFtcGxlLCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgcmVkaXJlY3RzIHRoZSB1c2VyLWFnZW50 IGJ5IHNlbmRpbmcgdGhlCiAgICAgICAgICAgICAgICBmb2xsb3dpbmcgSFRUUCByZXNwb25zZToK ICAgICAgICAgICAgICA8L3ByZWFtYmxlPgogICAgICAgICAgICAgIDxhcnR3b3JrPgogICAgICAg ICAgICAgICAgPCFbQ0RBVEFbCiAgSFRUUC8xLjEgMzAyIEZvdW5kCiAgTG9jYXRpb246IGh0dHBz Oi8vY2xpZW50LmV4YW1wbGUuY29tL2NiI2Vycm9yPWFjY2Vzc19kZW5pZWQmc3RhdGU9eHl6Cl1d PgogICAgICAgICAgICAgIDwvYXJ0d29yaz4KICAgICAgICAgICAgPC9maWd1cmU+CiAgICAgICAg ICA8L3NlY3Rpb24+CgogICAgICAgIDwvc2VjdGlvbj4KCiAgICAgIDwvc2VjdGlvbj4KCiAgICAg IDxzZWN0aW9uIHRpdGxlPSdSZXNvdXJjZSBPd25lciBQYXNzd29yZCBDcmVkZW50aWFscyBHcmFu dCcgYW5jaG9yPSdncmFudC1wYXNzd29yZCc+CiAgICAgICAgPHQ+CiAgICAgICAgICBUaGUgcmVz b3VyY2Ugb3duZXIgcGFzc3dvcmQgY3JlZGVudGlhbHMgZ3JhbnQgdHlwZSBpcyBzdWl0YWJsZSBp biBjYXNlcyB3aGVyZSB0aGUKICAgICAgICAgIHJlc291cmNlIG93bmVyIGhhcyBhIHRydXN0IHJl bGF0aW9uc2hpcCB3aXRoIHRoZSBjbGllbnQsIHN1Y2ggYXMgdGhlIGRldmljZSBvcGVyYXRpbmcK ICAgICAgICAgIHN5c3RlbSBvciBhIGhpZ2hseSBwcml2aWxlZ2VkIGFwcGxpY2F0aW9uLiBUaGUg YXV0aG9yaXphdGlvbiBzZXJ2ZXIgc2hvdWxkIHRha2Ugc3BlY2lhbAogICAgICAgICAgY2FyZSB3 aGVuIGVuYWJsaW5nIHRoaXMgZ3JhbnQgdHlwZSwgYW5kIG9ubHkgYWxsb3cgaXQgd2hlbiBvdGhl ciBmbG93cyBhcmUgbm90IHZpYWJsZS4KICAgICAgICA8L3Q+CiAgICAgICAgPHQ+CiAgICAgICAg ICBUaGUgZ3JhbnQgdHlwZSBpcyBzdWl0YWJsZSBmb3IgY2xpZW50cyBjYXBhYmxlIG9mIG9idGFp bmluZyB0aGUgcmVzb3VyY2Ugb3duZXIncwogICAgICAgICAgY3JlZGVudGlhbHMgKHVzZXJuYW1l IGFuZCBwYXNzd29yZCwgdHlwaWNhbGx5IHVzaW5nIGFuIGludGVyYWN0aXZlIGZvcm0pLiBJdCBp cyBhbHNvIHVzZWQKICAgICAgICAgIHRvIG1pZ3JhdGUgZXhpc3RpbmcgY2xpZW50cyB1c2luZyBk aXJlY3QgYXV0aGVudGljYXRpb24gc2NoZW1lcyBzdWNoIGFzIEhUVFAgQmFzaWMgb3IKICAgICAg ICAgIERpZ2VzdCBhdXRoZW50aWNhdGlvbiB0byBPQXV0aCBieSBjb252ZXJ0aW5nIHRoZSBzdG9y ZWQgY3JlZGVudGlhbHMgdG8gYW4gYWNjZXNzIHRva2VuLgogICAgICAgIDwvdD4KICAgICAgICA8 ZmlndXJlIHRpdGxlPSdSZXNvdXJjZSBPd25lciBQYXNzd29yZCBDcmVkZW50aWFscyBGbG93JyBh bmNob3I9J0ZpZ3VyZS01Jz4KICAgICAgICAgIDxhcnR3b3JrPgogICAgICAgICAgICA8IVtDREFU QVsKICArLS0tLS0tLS0tLSsKICB8IFJlc291cmNlIHwKICB8ICBPd25lciAgIHwKICB8ICAgICAg ICAgIHwKICArLS0tLS0tLS0tLSsKICAgICAgIHYKICAgICAgIHwgICAgUmVzb3VyY2UgT3duZXIK ICAgICAgKEEpIFBhc3N3b3JkIENyZWRlbnRpYWxzCiAgICAgICB8CiAgICAgICB2CiAgKy0tLS0t LS0tLSsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLSsK ICB8ICAgICAgICAgfD4tLShCKS0tLS0gUmVzb3VyY2UgT3duZXIgLS0tLS0tLT58ICAgICAgICAg ICAgICAgfAogIHwgICAgICAgICB8ICAgICAgICAgUGFzc3dvcmQgQ3JlZGVudGlhbHMgICAgIHwg QXV0aG9yaXphdGlvbiB8CiAgfCBDbGllbnQgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgfCAgICAgU2VydmVyICAgIHwKICB8ICAgICAgICAgfDwtLShDKS0tLS0gQWNjZXNzIFRv a2VuIC0tLS0tLS0tLTx8ICAgICAgICAgICAgICAgfAogIHwgICAgICAgICB8ICAgICh3LyBPcHRp b25hbCBSZWZyZXNoIFRva2VuKSAgIHwgICAgICAgICAgICAgICB8CiAgKy0tLS0tLS0tLSsgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLSsKXV0+CiAgICAg ICAgICA8L2FydHdvcms+CiAgICAgICAgPC9maWd1cmU+CiAgICAgICAgPHQ+CiAgICAgICAgICBU aGUgZmxvdyBpbGx1c3RyYXRlZCBpbiA8eHJlZiB0YXJnZXQ9J0ZpZ3VyZS01JyAvPiBpbmNsdWRl cyB0aGUgZm9sbG93aW5nIHN0ZXBzOgogICAgICAgIDwvdD4KICAgICAgICA8dD4KICAgICAgICAg IDxsaXN0IHN0eWxlPSdmb3JtYXQgKCVDKSc+CiAgICAgICAgICAgIDx0PgogICAgICAgICAgICAg IFRoZSByZXNvdXJjZSBvd25lciBwcm92aWRlcyB0aGUgY2xpZW50IHdpdGggaXRzIHVzZXJuYW1l IGFuZCBwYXNzd29yZC4KICAgICAgICAgICAgPC90PgogICAgICAgICAgICA8dD4KICAgICAgICAg ICAgICBUaGUgY2xpZW50IHJlcXVlc3RzIGFuIGFjY2VzcyB0b2tlbiBmcm9tIHRoZSBhdXRob3Jp emF0aW9uIHNlcnZlcidzIHRva2VuIGVuZHBvaW50IGJ5CiAgICAgICAgICAgICAgaW5jbHVkaW5n IHRoZSBjcmVkZW50aWFscyByZWNlaXZlZCBmcm9tIHRoZSByZXNvdXJjZSBvd25lci4gV2hlbiBt YWtpbmcgdGhlIHJlcXVlc3QsCiAgICAgICAgICAgICAgdGhlIGNsaWVudCBhdXRoZW50aWNhdGVz IHdpdGggdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLgogICAgICAgICAgICA8L3Q+CiAgICAgICAg ICAgIDx0PgogICAgICAgICAgICAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBhdXRoZW50aWNh dGVzIHRoZSBjbGllbnQgYW5kIHZhbGlkYXRlcyB0aGUgcmVzb3VyY2Ugb3duZXIKICAgICAgICAg ICAgICBjcmVkZW50aWFscywgYW5kIGlmIHZhbGlkIGlzc3VlcyBhbiBhY2Nlc3MgdG9rZW4uCiAg ICAgICAgICAgIDwvdD4KICAgICAgICAgIDwvbGlzdD4KICAgICAgICA8L3Q+CgogICAgICAgIDxz ZWN0aW9uIHRpdGxlPSdBdXRob3JpemF0aW9uIFJlcXVlc3QgYW5kIFJlc3BvbnNlJz4KICAgICAg ICAgIDx0PgogICAgICAgICAgICBUaGUgbWV0aG9kIHRocm91Z2ggd2hpY2ggdGhlIGNsaWVudCBv YnRhaW5zIHRoZSByZXNvdXJjZSBvd25lciBjcmVkZW50aWFscyBpcyBiZXlvbmQKICAgICAgICAg ICAgdGhlIHNjb3BlIG9mIHRoaXMgc3BlY2lmaWNhdGlvbi4gVGhlIGNsaWVudCBNVVNUIGRpc2Nh cmQgdGhlIGNyZWRlbnRpYWxzIG9uY2UgYW4gYWNjZXNzCiAgICAgICAgICAgIHRva2VuIGhhcyBi ZWVuIG9idGFpbmVkLgogICAgICAgICAgPC90PgogICAgICAgIDwvc2VjdGlvbj4KCiAgICAgICAg PHNlY3Rpb24gdGl0bGU9J0FjY2VzcyBUb2tlbiBSZXF1ZXN0JyBhbmNob3I9InBhc3N3b3JkLXRv ay1yZXEiPgogICAgICAgICAgPHQ+CiAgICAgICAgICAgIFRoZSBjbGllbnQgbWFrZXMgYSByZXF1 ZXN0IHRvIHRoZSB0b2tlbiBlbmRwb2ludCBieSBhZGRpbmcgdGhlIGZvbGxvd2luZyBwYXJhbWV0 ZXJzCiAgICAgICAgICAgIHVzaW5nIHRoZSA8c3Bhbnggc3R5bGU9J3ZlcmInPmFwcGxpY2F0aW9u L3gtd3d3LWZvcm0tdXJsZW5jb2RlZDwvc3Bhbng+IGZvcm1hdCBpbiB0aGUKICAgICAgICAgICAg SFRUUCByZXF1ZXN0IGVudGl0eS1ib2R5OgogICAgICAgICAgPC90PgogICAgICAgICAgPHQ+CiAg ICAgICAgICAgIDxsaXN0IHN0eWxlPSdoYW5naW5nJyBoYW5nSW5kZW50PSc2Jz4KICAgICAgICAg ICAgICA8dCBoYW5nVGV4dD0nZ3JhbnRfdHlwZSc+CiAgICAgICAgICAgICAgICA8dnNwYWNlIC8+ CiAgICAgICAgICAgICAgICBSRVFVSVJFRC4gVmFsdWUgTVVTVCBiZSBzZXQgdG8gPHNwYW54IHN0 eWxlPSd2ZXJiJz5wYXNzd29yZDwvc3Bhbng+LgogICAgICAgICAgICAgIDwvdD4KICAgICAgICAg ICAgICA8dCBoYW5nVGV4dD0ndXNlcm5hbWUnPgogICAgICAgICAgICAgICAgPHZzcGFjZSAvPgog ICAgICAgICAgICAgICAgUkVRVUlSRUQuIFRoZSByZXNvdXJjZSBvd25lciB1c2VybmFtZS4KICAg ICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgICAgPHQgaGFuZ1RleHQ9J3Bhc3N3b3JkJz4KICAg ICAgICAgICAgICAgIDx2c3BhY2UgLz4KICAgICAgICAgICAgICAgIFJFUVVJUkVELiBUaGUgcmVz b3VyY2Ugb3duZXIgcGFzc3dvcmQuCiAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICAgIDx0 IGhhbmdUZXh0PSdzY29wZSc+CiAgICAgICAgICAgICAgICA8dnNwYWNlIC8+CiAgICAgICAgICAg ICAgICBPUFRJT05BTC4gVGhlIHNjb3BlIG9mIHRoZSBhY2Nlc3MgcmVxdWVzdCBhcyBkZXNjcmli ZWQgYnkgPHhyZWYgdGFyZ2V0PSdzY29wZScgLz4uCiAgICAgICAgICAgICAgPC90PgogICAgICAg ICAgICA8L2xpc3Q+CiAgICAgICAgICA8L3Q+CiAgICAgICAgICA8dD4KICAgICAgICAgICAgSWYg dGhlIGNsaWVudCB0eXBlIGlzIGNvbmZpZGVudGlhbCBvciB0aGUgY2xpZW50IHdhcyBpc3N1ZWQg Y2xpZW50IGNyZWRlbnRpYWxzIChvcgogICAgICAgICAgICBhc3NpZ25lZCBvdGhlciBhdXRoZW50 aWNhdGlvbiByZXF1aXJlbWVudHMpLCB0aGUgY2xpZW50IE1VU1QgYXV0aGVudGljYXRlIHdpdGgg dGhlCiAgICAgICAgICAgIGF1dGhvcml6YXRpb24gc2VydmVyIGFzIGRlc2NyaWJlZCBpbiA8eHJl ZiB0YXJnZXQ9J3Rva2VuLWVuZHBvaW50LWF1dGgnIC8+LgogICAgICAgICAgPC90PgogICAgICAg ICAgPGZpZ3VyZT4KICAgICAgICAgICAgPHByZWFtYmxlPgogICAgICAgICAgICAgIEZvciBleGFt cGxlLCB0aGUgY2xpZW50IG1ha2VzIHRoZSBmb2xsb3dpbmcgSFRUUCByZXF1ZXN0IHVzaW5nIHRy YW5zcG9ydC1sYXllcgogICAgICAgICAgICAgIHNlY3VyaXR5IChleHRyYSBsaW5lIGJyZWFrcyBh cmUgZm9yIGRpc3BsYXkgcHVycG9zZXMgb25seSk6CiAgICAgICAgICAgIDwvcHJlYW1ibGU+CiAg ICAgICAgICAgIDxhcnR3b3JrPgogICAgICAgICAgICAgIDwhW0NEQVRBWwogIFBPU1QgL3Rva2Vu IEhUVFAvMS4xCiAgSG9zdDogc2VydmVyLmV4YW1wbGUuY29tCiAgQXV0aG9yaXphdGlvbjogQmFz aWMgY3paQ2FHUlNhM0YwTXpwbldERm1RbUYwTTJKVwogIENvbnRlbnQtVHlwZTogYXBwbGljYXRp b24veC13d3ctZm9ybS11cmxlbmNvZGVkO2NoYXJzZXQ9VVRGLTgKICAKICBncmFudF90eXBlPXBh c3N3b3JkJnVzZXJuYW1lPWpvaG5kb2UmcGFzc3dvcmQ9QTNkZGozdwpdXT4KICAgICAgICAgICAg PC9hcnR3b3JrPgogICAgICAgICAgPC9maWd1cmU+CiAgICAgICAgICA8dD4KICAgICAgICAgICAg VGhlIGF1dGhvcml6YXRpb24gc2VydmVyIE1VU1Q6CiAgICAgICAgICA8L3Q+CiAgICAgICAgICA8 dD4KICAgICAgICAgICAgPGxpc3Qgc3R5bGU9J3N5bWJvbHMnPgogICAgICAgICAgICAgIDx0Pgog ICAgICAgICAgICAgICAgcmVxdWlyZSBjbGllbnQgYXV0aGVudGljYXRpb24gZm9yIGNvbmZpZGVu dGlhbCBjbGllbnRzIG9yIGZvciBhbnkgY2xpZW50IHRoYXQgd2FzCiAgICAgICAgICAgICAgICBp c3N1ZWQgY2xpZW50IGNyZWRlbnRpYWxzIChvciB3aXRoIG90aGVyIGF1dGhlbnRpY2F0aW9uIHJl cXVpcmVtZW50cyksCiAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICAgIDx0PgogICAgICAg ICAgICAgICAgYXV0aGVudGljYXRlIHRoZSBjbGllbnQgaWYgY2xpZW50IGF1dGhlbnRpY2F0aW9u IGlzIGluY2x1ZGVkLCBhbmQKICAgICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgICAgPHQ+CiAg ICAgICAgICAgICAgICB2YWxpZGF0ZSB0aGUgcmVzb3VyY2Ugb3duZXIgcGFzc3dvcmQgY3JlZGVu dGlhbHMgdXNpbmcgaXRzIGV4aXN0aW5nIHBhc3N3b3JkCiAgICAgICAgICAgICAgICB2YWxpZGF0 aW9uIGFsZ29yaXRobS4KICAgICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgIDwvbGlzdD4KICAg ICAgICAgIDwvdD4KICAgICAgICAgIDx0PgogICAgICAgICAgICBTaW5jZSB0aGlzIGFjY2VzcyB0 b2tlbiByZXF1ZXN0IHV0aWxpemVzIHRoZSByZXNvdXJjZSBvd25lcidzIHBhc3N3b3JkLCB0aGUK ICAgICAgICAgICAgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVTVCBwcm90ZWN0IHRoZSBlbmRwb2lu dCBhZ2FpbnN0IGJydXRlIGZvcmNlIGF0dGFja3MgKGUuZy4gdXNpbmcKICAgICAgICAgICAgcmF0 ZS1saW1pdGF0aW9uIG9yIGdlbmVyYXRpbmcgYWxlcnRzKS4KICAgICAgICAgIDwvdD4KICAgICAg ICA8L3NlY3Rpb24+CgogICAgICAgIDxzZWN0aW9uIHRpdGxlPSdBY2Nlc3MgVG9rZW4gUmVzcG9u c2UnPgogICAgICAgICAgPHQ+CiAgICAgICAgICAgIElmIHRoZSBhY2Nlc3MgdG9rZW4gcmVxdWVz dCBpcyB2YWxpZCBhbmQgYXV0aG9yaXplZCwgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGlzc3Vl cyBhbgogICAgICAgICAgICBhY2Nlc3MgdG9rZW4gYW5kIG9wdGlvbmFsIHJlZnJlc2ggdG9rZW4g YXMgZGVzY3JpYmVkIGluIDx4cmVmIHRhcmdldD0ndG9rZW4tcmVzcG9uc2UnIC8+LgogICAgICAg ICAgICBJZiB0aGUgcmVxdWVzdCBmYWlsZWQgY2xpZW50IGF1dGhlbnRpY2F0aW9uIG9yIGlzIGlu dmFsaWQsIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciByZXR1cm5zCiAgICAgICAgICAgIGFuIGVy cm9yIHJlc3BvbnNlIGFzIGRlc2NyaWJlZCBpbiA8eHJlZiB0YXJnZXQ9J3Rva2VuLWVycm9ycycg Lz4uCiAgICAgICAgICA8L3Q+CiAgICAgICAgICA8ZmlndXJlPgogICAgICAgICAgICA8cHJlYW1i bGU+CiAgICAgICAgICAgICAgQW4gZXhhbXBsZSBzdWNjZXNzZnVsIHJlc3BvbnNlOgogICAgICAg ICAgICA8L3ByZWFtYmxlPgogICAgICAgICAgICA8YXJ0d29yaz4KICAgICAgICAgICAgICA8IVtD REFUQVsKICBIVFRQLzEuMSAyMDAgT0sKICBDb250ZW50LVR5cGU6IGFwcGxpY2F0aW9uL2pzb247 Y2hhcnNldD1VVEYtOAogIENhY2hlLUNvbnRyb2w6IG5vLXN0b3JlCiAgUHJhZ21hOiBuby1jYWNo ZQoKICB7CiAgICAiYWNjZXNzX3Rva2VuIjoiMllvdG5GWkZFanIxekNzaWNNV3BBQSIsCiAgICAi dG9rZW5fdHlwZSI6ImV4YW1wbGUiLAogICAgImV4cGlyZXNfaW4iOjM2MDAsCiAgICAicmVmcmVz aF90b2tlbiI6InRHenYzSk9rRjBYRzVReDJUbEtXSUEiLAogICAgImV4YW1wbGVfcGFyYW1ldGVy IjoiZXhhbXBsZV92YWx1ZSIKICB9Cl1dPgogICAgICAgICAgICA8L2FydHdvcms+CiAgICAgICAg ICA8L2ZpZ3VyZT4KICAgICAgICA8L3NlY3Rpb24+CgogICAgICA8L3NlY3Rpb24+CgogICAgICA8 c2VjdGlvbiB0aXRsZT0nQ2xpZW50IENyZWRlbnRpYWxzIEdyYW50JyBhbmNob3I9J2dyYW50LWNs aWVudCc+CiAgICAgICAgPHQ+CiAgICAgICAgICBUaGUgY2xpZW50IGNhbiByZXF1ZXN0IGFuIGFj Y2VzcyB0b2tlbiB1c2luZyBvbmx5IGl0cyBjbGllbnQgY3JlZGVudGlhbHMgKG9yIG90aGVyCiAg ICAgICAgICBzdXBwb3J0ZWQgbWVhbnMgb2YgYXV0aGVudGljYXRpb24pIHdoZW4gdGhlIGNsaWVu dCBpcyByZXF1ZXN0aW5nIGFjY2VzcyB0byB0aGUKICAgICAgICAgIHByb3RlY3RlZCByZXNvdXJj ZXMgdW5kZXIgaXRzIGNvbnRyb2wsIG9yIHRob3NlIG9mIGFub3RoZXIgcmVzb3VyY2Ugb3duZXIg d2hpY2ggaGFzIGJlZW4KICAgICAgICAgIHByZXZpb3VzbHkgYXJyYW5nZWQgd2l0aCB0aGUgYXV0 aG9yaXphdGlvbiBzZXJ2ZXIgKHRoZSBtZXRob2Qgb2Ygd2hpY2ggaXMgYmV5b25kIHRoZQogICAg ICAgICAgc2NvcGUgb2YgdGhpcyBzcGVjaWZpY2F0aW9uKS4KICAgICAgICA8L3Q+CiAgICAgICAg PHQ+CiAgICAgICAgICBUaGUgY2xpZW50IGNyZWRlbnRpYWxzIGdyYW50IHR5cGUgTVVTVCBvbmx5 IGJlIHVzZWQgYnkgY29uZmlkZW50aWFsIGNsaWVudHMuCiAgICAgICAgPC90PgogICAgICAgIDxm aWd1cmUgdGl0bGU9J0NsaWVudCBDcmVkZW50aWFscyBGbG93JyBhbmNob3I9J0ZpZ3VyZS02Jz4K ICAgICAgICAgIDxhcnR3b3JrPgogICAgICAgICAgICA8IVtDREFUQVsKICArLS0tLS0tLS0tKyAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tKwogIHwgICAg ICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICB8 CiAgfCAgICAgICAgIHw+LS0oQSktIENsaWVudCBBdXRoZW50aWNhdGlvbiAtLS0+fCBBdXRob3Jp emF0aW9uIHwKICB8IENsaWVudCAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8 ICAgICBTZXJ2ZXIgICAgfAogIHwgICAgICAgICB8PC0tKEIpLS0tLSBBY2Nlc3MgVG9rZW4gLS0t LS0tLS0tPHwgICAgICAgICAgICAgICB8CiAgfCAgICAgICAgIHwgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgIHwKICArLS0tLS0tLS0tKyAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tKwpdXT4KICAgICAgICAgIDwv YXJ0d29yaz4KICAgICAgICA8L2ZpZ3VyZT4KICAgICAgICA8dD4KICAgICAgICAgIFRoZSBmbG93 IGlsbHVzdHJhdGVkIGluIDx4cmVmIHRhcmdldD0nRmlndXJlLTYnIC8+IGluY2x1ZGVzIHRoZSBm b2xsb3dpbmcgc3RlcHM6CiAgICAgICAgPC90PgogICAgICAgIDx0PgogICAgICAgICAgPGxpc3Qg c3R5bGU9J2Zvcm1hdCAoJUMpJz4KICAgICAgICAgICAgPHQ+CiAgICAgICAgICAgICAgVGhlIGNs aWVudCBhdXRoZW50aWNhdGVzIHdpdGggdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGFuZCByZXF1 ZXN0cyBhbiBhY2Nlc3MgdG9rZW4KICAgICAgICAgICAgICBmcm9tIHRoZSB0b2tlbiBlbmRwb2lu dC4KICAgICAgICAgICAgPC90PgogICAgICAgICAgICA8dD4KICAgICAgICAgICAgICBUaGUgYXV0 aG9yaXphdGlvbiBzZXJ2ZXIgYXV0aGVudGljYXRlcyB0aGUgY2xpZW50LCBhbmQgaWYgdmFsaWQg aXNzdWVzIGFuIGFjY2VzcwogICAgICAgICAgICAgIHRva2VuLgogICAgICAgICAgICA8L3Q+CiAg ICAgICAgICA8L2xpc3Q+CiAgICAgICAgPC90PgoKICAgICAgICA8c2VjdGlvbiB0aXRsZT0nQXV0 aG9yaXphdGlvbiBSZXF1ZXN0IGFuZCBSZXNwb25zZSc+CiAgICAgICAgICA8dD4KICAgICAgICAg ICAgU2luY2UgdGhlIGNsaWVudCBhdXRoZW50aWNhdGlvbiBpcyB1c2VkIGFzIHRoZSBhdXRob3Jp emF0aW9uIGdyYW50LCBubyBhZGRpdGlvbmFsCiAgICAgICAgICAgIGF1dGhvcml6YXRpb24gcmVx dWVzdCBpcyBuZWVkZWQuCiAgICAgICAgICA8L3Q+CiAgICAgICAgPC9zZWN0aW9uPgoKICAgICAg ICA8c2VjdGlvbiB0aXRsZT0nQWNjZXNzIFRva2VuIFJlcXVlc3QnIGFuY2hvcj0iY2xpZW50LXJl cSI+CiAgICAgICAgICA8dD4KICAgICAgICAgICAgVGhlIGNsaWVudCBtYWtlcyBhIHJlcXVlc3Qg dG8gdGhlIHRva2VuIGVuZHBvaW50IGJ5IGFkZGluZyB0aGUgZm9sbG93aW5nIHBhcmFtZXRlcnMK ICAgICAgICAgICAgdXNpbmcgdGhlIDxzcGFueCBzdHlsZT0ndmVyYic+YXBwbGljYXRpb24veC13 d3ctZm9ybS11cmxlbmNvZGVkPC9zcGFueD4gZm9ybWF0IGluIHRoZQogICAgICAgICAgICBIVFRQ IHJlcXVlc3QgZW50aXR5LWJvZHk6CiAgICAgICAgICA8L3Q+CiAgICAgICAgICA8dD4KICAgICAg ICAgICAgPGxpc3Qgc3R5bGU9J2hhbmdpbmcnIGhhbmdJbmRlbnQ9JzYnPgogICAgICAgICAgICAg IDx0IGhhbmdUZXh0PSdncmFudF90eXBlJz4KICAgICAgICAgICAgICAgIDx2c3BhY2UgLz4KICAg ICAgICAgICAgICAgIFJFUVVJUkVELiBWYWx1ZSBNVVNUIGJlIHNldCB0byA8c3Bhbnggc3R5bGU9 J3ZlcmInPmNsaWVudF9jcmVkZW50aWFsczwvc3Bhbng+LgogICAgICAgICAgICAgIDwvdD4KICAg ICAgICAgICAgICA8dCBoYW5nVGV4dD0nc2NvcGUnPgogICAgICAgICAgICAgICAgPHZzcGFjZSAv PgogICAgICAgICAgICAgICAgT1BUSU9OQUwuIFRoZSBzY29wZSBvZiB0aGUgYWNjZXNzIHJlcXVl c3QgYXMgZGVzY3JpYmVkIGJ5IDx4cmVmIHRhcmdldD0nc2NvcGUnIC8+LgogICAgICAgICAgICAg IDwvdD4KICAgICAgICAgICAgPC9saXN0PgogICAgICAgICAgPC90PgogICAgICAgICAgPHQ+CiAg ICAgICAgICAgIFRoZSBjbGllbnQgTVVTVCBhdXRoZW50aWNhdGUgd2l0aCB0aGUgYXV0aG9yaXph dGlvbiBzZXJ2ZXIgYXMgZGVzY3JpYmVkIGluCiAgICAgICAgICAgIDx4cmVmIHRhcmdldD0ndG9r ZW4tZW5kcG9pbnQtYXV0aCcgLz4uCiAgICAgICAgICA8L3Q+CiAgICAgICAgICA8ZmlndXJlPgog ICAgICAgICAgICA8cHJlYW1ibGU+CiAgICAgICAgICAgICAgRm9yIGV4YW1wbGUsIHRoZSBjbGll bnQgbWFrZXMgdGhlIGZvbGxvd2luZyBIVFRQIHJlcXVlc3QgdXNpbmcgdHJhbnNwb3J0LWxheWVy CiAgICAgICAgICAgICAgc2VjdXJpdHkgKGV4dHJhIGxpbmUgYnJlYWtzIGFyZSBmb3IgZGlzcGxh eSBwdXJwb3NlcyBvbmx5KToKICAgICAgICAgICAgPC9wcmVhbWJsZT4KICAgICAgICAgICAgPGFy dHdvcms+CiAgICAgICAgICAgICAgPCFbQ0RBVEFbCiAgUE9TVCAvdG9rZW4gSFRUUC8xLjEKICBI b3N0OiBzZXJ2ZXIuZXhhbXBsZS5jb20KICBBdXRob3JpemF0aW9uOiBCYXNpYyBjelpDYUdSU2Ez RjBNenBuV0RGbVFtRjBNMkpXCiAgQ29udGVudC1UeXBlOiBhcHBsaWNhdGlvbi94LXd3dy1mb3Jt LXVybGVuY29kZWQ7Y2hhcnNldD1VVEYtOAogIAogIGdyYW50X3R5cGU9Y2xpZW50X2NyZWRlbnRp YWxzCl1dPgogICAgICAgICAgICA8L2FydHdvcms+CiAgICAgICAgICA8L2ZpZ3VyZT4KICAgICAg ICAgIDx0PgogICAgICAgICAgICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVTVCBhdXRoZW50 aWNhdGUgdGhlIGNsaWVudC4KICAgICAgICAgIDwvdD4KICAgICAgICA8L3NlY3Rpb24+CgogICAg ICAgIDxzZWN0aW9uIHRpdGxlPSdBY2Nlc3MgVG9rZW4gUmVzcG9uc2UnPgogICAgICAgICAgPHQ+ CiAgICAgICAgICAgIElmIHRoZSBhY2Nlc3MgdG9rZW4gcmVxdWVzdCBpcyB2YWxpZCBhbmQgYXV0 aG9yaXplZCwgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGlzc3VlcyBhbgogICAgICAgICAgICBh Y2Nlc3MgdG9rZW4gYXMgZGVzY3JpYmVkIGluIDx4cmVmIHRhcmdldD0ndG9rZW4tcmVzcG9uc2Un IC8+LiBBIHJlZnJlc2ggdG9rZW4gU0hPVUxECiAgICAgICAgICAgIE5PVCBiZSBpbmNsdWRlZC4g SWYgdGhlIHJlcXVlc3QgZmFpbGVkIGNsaWVudCBhdXRoZW50aWNhdGlvbiBvciBpcyBpbnZhbGlk LCB0aGUKICAgICAgICAgICAgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgcmV0dXJucyBhbiBlcnJvciBy ZXNwb25zZSBhcyBkZXNjcmliZWQgaW4KICAgICAgICAgICAgPHhyZWYgdGFyZ2V0PSd0b2tlbi1l cnJvcnMnIC8+LgogICAgICAgICAgPC90PgogICAgICAgICAgPGZpZ3VyZT4KICAgICAgICAgICAg PHByZWFtYmxlPgogICAgICAgICAgICAgIEFuIGV4YW1wbGUgc3VjY2Vzc2Z1bCByZXNwb25zZToK ICAgICAgICAgICAgPC9wcmVhbWJsZT4KICAgICAgICAgICAgPGFydHdvcms+CiAgICAgICAgICAg ICAgPCFbQ0RBVEFbCiAgSFRUUC8xLjEgMjAwIE9LCiAgQ29udGVudC1UeXBlOiBhcHBsaWNhdGlv bi9qc29uO2NoYXJzZXQ9VVRGLTgKICBDYWNoZS1Db250cm9sOiBuby1zdG9yZQogIFByYWdtYTog bm8tY2FjaGUKICAKICB7CiAgICAiYWNjZXNzX3Rva2VuIjoiMllvdG5GWkZFanIxekNzaWNNV3BB QSIsCiAgICAidG9rZW5fdHlwZSI6ImV4YW1wbGUiLAogICAgImV4cGlyZXNfaW4iOjM2MDAsCiAg ICAiZXhhbXBsZV9wYXJhbWV0ZXIiOiJleGFtcGxlX3ZhbHVlIgogIH0KXV0+CiAgICAgICAgICAg IDwvYXJ0d29yaz4KICAgICAgICAgIDwvZmlndXJlPgogICAgICAgIDwvc2VjdGlvbj4KCiAgICAg IDwvc2VjdGlvbj4KCiAgICAgIDxzZWN0aW9uIHRpdGxlPSdFeHRlbnNpb24gR3JhbnRzJyBhbmNo b3I9ImV4dC1ncmFudCI+CiAgICAgICAgPHQ+CiAgICAgICAgICBUaGUgY2xpZW50IHVzZXMgYW4g ZXh0ZW5zaW9uIGdyYW50IHR5cGUgYnkgc3BlY2lmeWluZyB0aGUgZ3JhbnQgdHlwZSB1c2luZyBh bgogICAgICAgICAgYWJzb2x1dGUgVVJJIChkZWZpbmVkIGJ5IHRoZSBhdXRob3JpemF0aW9uIHNl cnZlcikgYXMgdGhlIHZhbHVlIG9mIHRoZQogICAgICAgICAgPHNwYW54IHN0eWxlPSd2ZXJiJz5n cmFudF90eXBlPC9zcGFueD4gcGFyYW1ldGVyIG9mIHRoZSB0b2tlbiBlbmRwb2ludCwgYW5kIGJ5 CiAgICAgICAgICBhZGRpbmcgYW55IGFkZGl0aW9uYWwgcGFyYW1ldGVycyBuZWNlc3NhcnkuCiAg ICAgICAgPC90PgogICAgICAgIDxmaWd1cmU+CiAgICAgICAgICA8cHJlYW1ibGU+CiAgICAgICAg ICAgIEZvciBleGFtcGxlLCB0byByZXF1ZXN0IGFuIGFjY2VzcyB0b2tlbiB1c2luZyBhIFNBTUwg Mi4wIGFzc2VydGlvbiBncmFudCB0eXBlIGFzCiAgICAgICAgICAgIGRlZmluZWQgYnkgPHhyZWYg dGFyZ2V0PSdJLUQuaWV0Zi1vYXV0aC1zYW1sMi1iZWFyZXInIC8+LCB0aGUgY2xpZW50IG1ha2Vz IHRoZQogICAgICAgICAgICBmb2xsb3dpbmcgSFRUUCByZXF1ZXN0IHVzaW5nIFRMUyAobGluZSBi cmVha3MgYXJlIGZvciBkaXNwbGF5IHB1cnBvc2VzIG9ubHkpOgogICAgICAgICAgPC9wcmVhbWJs ZT4KICAgICAgICAgIDxhcnR3b3JrPgogICAgICAgICAgICA8IVtDREFUQVsKICBQT1NUIC90b2tl biBIVFRQLzEuMQogIEhvc3Q6IHNlcnZlci5leGFtcGxlLmNvbQogIENvbnRlbnQtVHlwZTogYXBw bGljYXRpb24veC13d3ctZm9ybS11cmxlbmNvZGVkO2NoYXJzZXQ9VVRGLTgKCiAgZ3JhbnRfdHlw ZT11cm4lM0FpZXRmJTNBcGFyYW1zJTNBb2F1dGglM0FncmFudC10eXBlJTNBc2FtbDItCiAgYmVh cmVyJmFzc2VydGlvbj1QRUZ6YzJWeWRHbHZiaUJKYzNOMVpVbHVjM1JoYm5ROUlqSXdNVEV0TURV CiAgWy4uLm9taXR0ZWQgZm9yIGJyZXZpdHkuLi5dYUc1VGRHRjBaVzFsYm5RLVBDOUJjM05sY25S cGIyNC0KXV0+CiAgICAgICAgICA8L2FydHdvcms+CiAgICAgICAgPC9maWd1cmU+CiAgICAgICAg PHQ+CiAgICAgICAgICBJZiB0aGUgYWNjZXNzIHRva2VuIHJlcXVlc3QgaXMgdmFsaWQgYW5kIGF1 dGhvcml6ZWQsIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBpc3N1ZXMgYW4KICAgICAgICAgIGFj Y2VzcyB0b2tlbiBhbmQgb3B0aW9uYWwgcmVmcmVzaCB0b2tlbiBhcyBkZXNjcmliZWQgaW4gPHhy ZWYgdGFyZ2V0PSd0b2tlbi1yZXNwb25zZScgLz4uCiAgICAgICAgICBJZiB0aGUgcmVxdWVzdCBm YWlsZWQgY2xpZW50IGF1dGhlbnRpY2F0aW9uIG9yIGlzIGludmFsaWQsIHRoZSBhdXRob3JpemF0 aW9uIHNlcnZlciByZXR1cm5zCiAgICAgICAgICBhbiBlcnJvciByZXNwb25zZSBhcyBkZXNjcmli ZWQgaW4gPHhyZWYgdGFyZ2V0PSd0b2tlbi1lcnJvcnMnIC8+LgogICAgICAgIDwvdD4KICAgICAg PC9zZWN0aW9uPgoKICAgIDwvc2VjdGlvbj4KCiAgICA8c2VjdGlvbiB0aXRsZT0nSXNzdWluZyBh biBBY2Nlc3MgVG9rZW4nIGFuY2hvcj0ndG9rZW4taXNzdWUnPgogICAgICA8dD4KICAgICAgICBJ ZiB0aGUgYWNjZXNzIHRva2VuIHJlcXVlc3QgaXMgdmFsaWQgYW5kIGF1dGhvcml6ZWQsIHRoZSBh dXRob3JpemF0aW9uIHNlcnZlciBpc3N1ZXMgYW4KICAgICAgICBhY2Nlc3MgdG9rZW4gYW5kIG9w dGlvbmFsIHJlZnJlc2ggdG9rZW4gYXMgZGVzY3JpYmVkIGluIDx4cmVmIHRhcmdldD0ndG9rZW4t cmVzcG9uc2UnIC8+LgogICAgICAgIElmIHRoZSByZXF1ZXN0IGZhaWxlZCBjbGllbnQgYXV0aGVu dGljYXRpb24gb3IgaXMgaW52YWxpZCwgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHJldHVybnMK ICAgICAgICBhbiBlcnJvciByZXNwb25zZSBhcyBkZXNjcmliZWQgaW4gPHhyZWYgdGFyZ2V0PSd0 b2tlbi1lcnJvcnMnIC8+LgogICAgICA8L3Q+CgogICAgICA8c2VjdGlvbiB0aXRsZT0nU3VjY2Vz c2Z1bCBSZXNwb25zZScgYW5jaG9yPSd0b2tlbi1yZXNwb25zZSc+CiAgICAgICAgPHQ+CiAgICAg ICAgICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgaXNzdWVzIGFuIGFjY2VzcyB0b2tlbiBhbmQg b3B0aW9uYWwgcmVmcmVzaCB0b2tlbiwgYW5kCiAgICAgICAgICBjb25zdHJ1Y3RzIHRoZSByZXNw b25zZSBieSBhZGRpbmcgdGhlIGZvbGxvd2luZyBwYXJhbWV0ZXJzIHRvIHRoZSBlbnRpdHkgYm9k eSBvZiB0aGUgSFRUUAogICAgICAgICAgcmVzcG9uc2Ugd2l0aCBhIDIwMCAoT0spIHN0YXR1cyBj b2RlOgogICAgICAgIDwvdD4KICAgICAgICA8dD4KICAgICAgICAgIDxsaXN0IHN0eWxlPSdoYW5n aW5nJyBoYW5nSW5kZW50PSc2Jz4KICAgICAgICAgICAgPHQgaGFuZ1RleHQ9J2FjY2Vzc190b2tl bic+CiAgICAgICAgICAgICAgPHZzcGFjZSAvPgogICAgICAgICAgICAgIFJFUVVJUkVELiBUaGUg YWNjZXNzIHRva2VuIGlzc3VlZCBieSB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIuCiAgICAgICAg ICAgIDwvdD4KICAgICAgICAgICAgPHQgaGFuZ1RleHQ9J3Rva2VuX3R5cGUnPgogICAgICAgICAg ICAgIDx2c3BhY2UgLz4KICAgICAgICAgICAgICBSRVFVSVJFRC4gVGhlIHR5cGUgb2YgdGhlIHRv a2VuIGlzc3VlZCBhcyBkZXNjcmliZWQgaW4gPHhyZWYgdGFyZ2V0PSd0b2tlbi10eXBlcycgLz4u CiAgICAgICAgICAgICAgVmFsdWUgaXMgY2FzZSBpbnNlbnNpdGl2ZS4KICAgICAgICAgICAgPC90 PgogICAgICAgICAgICA8dCBoYW5nVGV4dD0nZXhwaXJlc19pbic+CiAgICAgICAgICAgICAgPHZz cGFjZSAvPgogICAgICAgICAgICAgIFJFQ09NTUVOREVELiBUaGUgbGlmZXRpbWUgaW4gc2Vjb25k cyBvZiB0aGUgYWNjZXNzIHRva2VuLiBGb3IgZXhhbXBsZSwgdGhlIHZhbHVlCiAgICAgICAgICAg ICAgPHNwYW54IHN0eWxlPSd2ZXJiJz4zNjAwPC9zcGFueD4gZGVub3RlcyB0aGF0IHRoZSBhY2Nl c3MgdG9rZW4gd2lsbCBleHBpcmUgaW4gb25lCiAgICAgICAgICAgICAgaG91ciBmcm9tIHRoZSB0 aW1lIHRoZSByZXNwb25zZSB3YXMgZ2VuZXJhdGVkLiBJZiBvbWl0dGVkLCB0aGUgYXV0aG9yaXph dGlvbiBzZXJ2ZXIKICAgICAgICAgICAgICBTSE9VTEQgcHJvdmlkZSB0aGUgZXhwaXJhdGlvbiB0 aW1lIHZpYSBvdGhlciBtZWFucyBvciBkb2N1bWVudCB0aGUgZGVmYXVsdCB2YWx1ZS4KICAgICAg ICAgICAgPC90PgogICAgICAgICAgICA8dCBoYW5nVGV4dD0ncmVmcmVzaF90b2tlbic+CiAgICAg ICAgICAgICAgPHZzcGFjZSAvPgogICAgICAgICAgICAgIE9QVElPTkFMLiBUaGUgcmVmcmVzaCB0 b2tlbiB3aGljaCBjYW4gYmUgdXNlZCB0byBvYnRhaW4gbmV3IGFjY2VzcyB0b2tlbnMgdXNpbmcg dGhlCiAgICAgICAgICAgICAgc2FtZSBhdXRob3JpemF0aW9uIGdyYW50IGFzIGRlc2NyaWJlZCBp biA8eHJlZiB0YXJnZXQ9J3Rva2VuLXJlZnJlc2gnIC8+LgogICAgICAgICAgICA8L3Q+CiAgICAg ICAgICAgIDx0IGhhbmdUZXh0PSdzY29wZSc+CiAgICAgICAgICAgICAgPHZzcGFjZSAvPgogICAg ICAgICAgICAgIE9QVElPTkFMLCBpZiBpZGVudGljYWwgdG8gdGhlIHNjb3BlIHJlcXVlc3RlZCBi eSB0aGUgY2xpZW50LCBvdGhlcndpc2UgUkVRVUlSRUQuIFRoZQogICAgICAgICAgICAgIHNjb3Bl IG9mIHRoZSBhY2Nlc3MgdG9rZW4gYXMgZGVzY3JpYmVkIGJ5IDx4cmVmIHRhcmdldD0nc2NvcGUn IC8+LgogICAgICAgICAgICA8L3Q+CiAgICAgICAgICA8L2xpc3Q+CiAgICAgICAgPC90PgogICAg ICAgIDx0PgogICAgICAgICAgVGhlIHBhcmFtZXRlcnMgYXJlIGluY2x1ZGVkIGluIHRoZSBlbnRp dHkgYm9keSBvZiB0aGUgSFRUUCByZXNwb25zZSB1c2luZyB0aGUKICAgICAgICAgIDxzcGFueCBz dHlsZT0ndmVyYic+YXBwbGljYXRpb24vanNvbjwvc3Bhbng+IG1lZGlhIHR5cGUgYXMgZGVmaW5l ZCBieQogICAgICAgICAgPHhyZWYgdGFyZ2V0PSdSRkM0NjI3JyAvPi4gVGhlIHBhcmFtZXRlcnMg YXJlIHNlcmlhbGl6ZWQgaW50byBhIEpTT04gc3RydWN0dXJlIGJ5CiAgICAgICAgICBhZGRpbmcg ZWFjaCBwYXJhbWV0ZXIgYXQgdGhlIGhpZ2hlc3Qgc3RydWN0dXJlIGxldmVsLiBQYXJhbWV0ZXIg bmFtZXMgYW5kIHN0cmluZyB2YWx1ZXMKICAgICAgICAgIGFyZSBpbmNsdWRlZCBhcyBKU09OIHN0 cmluZ3MuIE51bWVyaWNhbCB2YWx1ZXMgYXJlIGluY2x1ZGVkIGFzIEpTT04gbnVtYmVycy4gVGhl IG9yZGVyIG9mCiAgICAgICAgICBwYXJhbWV0ZXJzIGRvZXMgbm90IG1hdHRlciBhbmQgY2FuIHZh cnkuCiAgICAgICAgPC90PgogICAgICAgIDx0PgogICAgICAgICAgVGhlIGF1dGhvcml6YXRpb24g c2VydmVyIE1VU1QgaW5jbHVkZSB0aGUgSFRUUAogICAgICAgICAgPHNwYW54IHN0eWxlPSd2ZXJi Jz5DYWNoZS1Db250cm9sPC9zcGFueD4gcmVzcG9uc2UgaGVhZGVyIGZpZWxkIDx4cmVmIHRhcmdl dD0nUkZDMjYxNicgLz4KICAgICAgICAgIHdpdGggYSB2YWx1ZSBvZiA8c3Bhbnggc3R5bGU9J3Zl cmInPm5vLXN0b3JlPC9zcGFueD4gaW4gYW55IHJlc3BvbnNlIGNvbnRhaW5pbmcgdG9rZW5zLAog ICAgICAgICAgY3JlZGVudGlhbHMsIG9yIG90aGVyIHNlbnNpdGl2ZSBpbmZvcm1hdGlvbiwgYXMg d2VsbCBhcyB0aGUKICAgICAgICAgIDxzcGFueCBzdHlsZT0ndmVyYic+UHJhZ21hPC9zcGFueD4g cmVzcG9uc2UgaGVhZGVyIGZpZWxkIDx4cmVmIHRhcmdldD0nUkZDMjYxNicgLz4gd2l0aCBhCiAg ICAgICAgICB2YWx1ZSBvZiA8c3Bhbnggc3R5bGU9J3ZlcmInPm5vLWNhY2hlPC9zcGFueD4uCiAg ICAgICAgPC90PgogICAgICAgIDxmaWd1cmU+CiAgICAgICAgICA8cHJlYW1ibGU+CiAgICAgICAg ICAgIEZvciBleGFtcGxlOgogICAgICAgICAgPC9wcmVhbWJsZT4KICAgICAgICAgIDxhcnR3b3Jr PgogICAgICAgICAgICA8IVtDREFUQVsKICBIVFRQLzEuMSAyMDAgT0sKICBDb250ZW50LVR5cGU6 IGFwcGxpY2F0aW9uL2pzb247Y2hhcnNldD1VVEYtOAogIENhY2hlLUNvbnRyb2w6IG5vLXN0b3Jl CiAgUHJhZ21hOiBuby1jYWNoZQoKICB7CiAgICAiYWNjZXNzX3Rva2VuIjoiMllvdG5GWkZFanIx ekNzaWNNV3BBQSIsCiAgICAidG9rZW5fdHlwZSI6ImV4YW1wbGUiLAogICAgImV4cGlyZXNfaW4i OjM2MDAsCiAgICAicmVmcmVzaF90b2tlbiI6InRHenYzSk9rRjBYRzVReDJUbEtXSUEiLAogICAg ImV4YW1wbGVfcGFyYW1ldGVyIjoiZXhhbXBsZV92YWx1ZSIKICB9Cl1dPgogICAgICAgICAgPC9h cnR3b3JrPgogICAgICAgIDwvZmlndXJlPgogICAgICAgIDx0PgogICAgICAgICAgVGhlIGNsaWVu dCBNVVNUIGlnbm9yZSB1bnJlY29nbml6ZWQgdmFsdWUgbmFtZXMgaW4gdGhlIHJlc3BvbnNlLiBU aGUgc2l6ZXMgb2YgdG9rZW5zIGFuZAogICAgICAgICAgb3RoZXIgdmFsdWVzIHJlY2VpdmVkIGZy b20gdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGFyZSBsZWZ0IHVuZGVmaW5lZC4gVGhlIGNsaWVu dCBzaG91bGQKICAgICAgICAgIGF2b2lkIG1ha2luZyBhc3N1bXB0aW9ucyBhYm91dCB2YWx1ZSBz aXplcy4gVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIFNIT1VMRCBkb2N1bWVudCB0aGUKICAgICAg ICAgIHNpemUgb2YgYW55IHZhbHVlIGl0IGlzc3Vlcy4KICAgICAgICA8L3Q+CiAgICAgIDwvc2Vj dGlvbj4KCiAgICAgIDxzZWN0aW9uIHRpdGxlPSdFcnJvciBSZXNwb25zZScgYW5jaG9yPSd0b2tl bi1lcnJvcnMnPgogICAgICAgIDx0PgogICAgICAgICAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVy IHJlc3BvbmRzIHdpdGggYW4gSFRUUCA0MDAgKEJhZCBSZXF1ZXN0KSBzdGF0dXMgY29kZSAodW5s ZXNzCiAgICAgICAgICBzcGVjaWZpZWQgb3RoZXJ3aXNlKSBhbmQgaW5jbHVkZXMgdGhlIGZvbGxv d2luZyBwYXJhbWV0ZXJzIHdpdGggdGhlIHJlc3BvbnNlOgogICAgICAgIDwvdD4KICAgICAgICA8 dD4KICAgICAgICAgIDxsaXN0IHN0eWxlPSdoYW5naW5nJyBoYW5nSW5kZW50PSc2Jz4KICAgICAg ICAgICAgPHQgaGFuZ1RleHQ9J2Vycm9yJz4KICAgICAgICAgICAgICA8dnNwYWNlIC8+CiAgICAg ICAgICAgICAgUkVRVUlSRUQuIEEgc2luZ2xlIEFTQ0lJIDx4cmVmIHRhcmdldD0iVVNBU0NJSSIg Lz4gZXJyb3IgY29kZSBmcm9tIHRoZSBmb2xsb3dpbmc6CgogICAgICAgICAgICAgIDxsaXN0IHN0 eWxlPSdoYW5naW5nJyBoYW5nSW5kZW50PSc2Jz4KICAgICAgICAgICAgICAgIDx0IGhhbmdUZXh0 PSdpbnZhbGlkX3JlcXVlc3QnPgogICAgICAgICAgICAgICAgICA8dnNwYWNlIC8+CiAgICAgICAg ICAgICAgICAgIFRoZSByZXF1ZXN0IGlzIG1pc3NpbmcgYSByZXF1aXJlZCBwYXJhbWV0ZXIsIGlu Y2x1ZGVzIGFuIHVuc3VwcG9ydGVkCiAgICAgICAgICAgICAgICAgIHBhcmFtZXRlciB2YWx1ZSAo b3RoZXIgdGhhbiBncmFudCB0eXBlKSwgcmVwZWF0cyBhIHBhcmFtZXRlciwgaW5jbHVkZXMgbXVs dGlwbGUKICAgICAgICAgICAgICAgICAgY3JlZGVudGlhbHMsIHV0aWxpemVzIG1vcmUgdGhhbiBv bmUgbWVjaGFuaXNtIGZvciBhdXRoZW50aWNhdGluZyB0aGUgY2xpZW50LAogICAgICAgICAgICAg ICAgICBvciBpcyBvdGhlcndpc2UgbWFsZm9ybWVkLgogICAgICAgICAgICAgICAgPC90PgogICAg ICAgICAgICAgICAgPHQgaGFuZ1RleHQ9J2ludmFsaWRfY2xpZW50Jz4KICAgICAgICAgICAgICAg ICAgPHZzcGFjZSAvPgogICAgICAgICAgICAgICAgICBDbGllbnQgYXV0aGVudGljYXRpb24gZmFp bGVkIChlLmcuIHVua25vd24gY2xpZW50LCBubyBjbGllbnQgYXV0aGVudGljYXRpb24KICAgICAg ICAgICAgICAgICAgaW5jbHVkZWQsIG9yIHVuc3VwcG9ydGVkIGF1dGhlbnRpY2F0aW9uIG1ldGhv ZCkuIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBNQVkKICAgICAgICAgICAgICAgICAgcmV0dXJu IGFuIEhUVFAgNDAxIChVbmF1dGhvcml6ZWQpIHN0YXR1cyBjb2RlIHRvIGluZGljYXRlIHdoaWNo IEhUVFAKICAgICAgICAgICAgICAgICAgYXV0aGVudGljYXRpb24gc2NoZW1lcyBhcmUgc3VwcG9y dGVkLiBJZiB0aGUgY2xpZW50IGF0dGVtcHRlZCB0byBhdXRoZW50aWNhdGUgdmlhCiAgICAgICAg ICAgICAgICAgIHRoZSA8c3Bhbnggc3R5bGU9J3ZlcmInPkF1dGhvcml6YXRpb248L3NwYW54PiBy ZXF1ZXN0IGhlYWRlciBmaWVsZCwKICAgICAgICAgICAgICAgICAgdGhlIGF1dGhvcml6YXRpb24g c2VydmVyIE1VU1QgcmVzcG9uZCB3aXRoIGFuIEhUVFAgNDAxIChVbmF1dGhvcml6ZWQpIHN0YXR1 cwogICAgICAgICAgICAgICAgICBjb2RlLCBhbmQgaW5jbHVkZSB0aGUgPHNwYW54IHN0eWxlPSd2 ZXJiJz5XV1ctQXV0aGVudGljYXRlPC9zcGFueD4gcmVzcG9uc2UKICAgICAgICAgICAgICAgICAg aGVhZGVyIGZpZWxkIG1hdGNoaW5nIHRoZSBhdXRoZW50aWNhdGlvbiBzY2hlbWUgdXNlZCBieSB0 aGUgY2xpZW50LgogICAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICAgICAgPHQgaGFuZ1Rl eHQ9J2ludmFsaWRfZ3JhbnQnPgogICAgICAgICAgICAgICAgICA8dnNwYWNlIC8+CiAgICAgICAg ICAgICAgICAgIFRoZSBwcm92aWRlZCBhdXRob3JpemF0aW9uIGdyYW50IChlLmcuIGF1dGhvcml6 YXRpb24gY29kZSwgcmVzb3VyY2Ugb3duZXIKICAgICAgICAgICAgICAgICAgY3JlZGVudGlhbHMp IG9yIHJlZnJlc2ggdG9rZW4gaXMgaW52YWxpZCwgZXhwaXJlZCwgcmV2b2tlZCwgZG9lcyBub3Qg bWF0Y2ggdGhlCiAgICAgICAgICAgICAgICAgIHJlZGlyZWN0aW9uIFVSSSB1c2VkIGluIHRoZSBh dXRob3JpemF0aW9uIHJlcXVlc3QsIG9yIHdhcyBpc3N1ZWQgdG8gYW5vdGhlcgogICAgICAgICAg ICAgICAgICBjbGllbnQuCiAgICAgICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgICAgICA8dCBo YW5nVGV4dD0ndW5hdXRob3JpemVkX2NsaWVudCc+CiAgICAgICAgICAgICAgICAgIDx2c3BhY2Ug Lz4KICAgICAgICAgICAgICAgICAgVGhlIGF1dGhlbnRpY2F0ZWQgY2xpZW50IGlzIG5vdCBhdXRo b3JpemVkIHRvIHVzZSB0aGlzIGF1dGhvcml6YXRpb24gZ3JhbnQgdHlwZS4KICAgICAgICAgICAg ICAgIDwvdD4KICAgICAgICAgICAgICAgIDx0IGhhbmdUZXh0PSd1bnN1cHBvcnRlZF9ncmFudF90 eXBlJz4KICAgICAgICAgICAgICAgICAgPHZzcGFjZSAvPgogICAgICAgICAgICAgICAgICBUaGUg YXV0aG9yaXphdGlvbiBncmFudCB0eXBlIGlzIG5vdCBzdXBwb3J0ZWQgYnkgdGhlIGF1dGhvcml6 YXRpb24gc2VydmVyLgogICAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICAgICAgPHQgaGFu Z1RleHQ9J2ludmFsaWRfc2NvcGUnPgogICAgICAgICAgICAgICAgICA8dnNwYWNlIC8+CiAgICAg ICAgICAgICAgICAgIFRoZSByZXF1ZXN0ZWQgc2NvcGUgaXMgaW52YWxpZCwgdW5rbm93biwgbWFs Zm9ybWVkLCBvciBleGNlZWRzIHRoZSBzY29wZSBncmFudGVkCiAgICAgICAgICAgICAgICAgIGJ5 IHRoZSByZXNvdXJjZSBvd25lci4KICAgICAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAgICA8 L2xpc3Q+CgoJICAgICAgVmFsdWVzIGZvciB0aGUgPHNwYW54IHN0eWxlPSd2ZXJiJz5lcnJvcjwv c3Bhbng+IHBhcmFtZXRlciBNVVNUIE5PVCBpbmNsdWRlCgkgICAgICBjaGFyYWN0ZXJzIG91dHNp ZGUgdGhlIHNldCAleDIwLTIxIC8gJXgyMy01QiAvICV4NUQtN0UuCiAgICAgICAgICAgIDwvdD4K ICAgICAgICAgICAgPHQgaGFuZ1RleHQ9J2Vycm9yX2Rlc2NyaXB0aW9uJz4KICAgICAgICAgICAg ICA8dnNwYWNlIC8+CiAgICAgICAgICAgICAgT1BUSU9OQUwuIEEgaHVtYW4tcmVhZGFibGUgQVND SUkgPHhyZWYgdGFyZ2V0PSJVU0FTQ0lJIiAvPiB0ZXh0IHByb3ZpZGluZyBhZGRpdGlvbmFsIGlu Zm9ybWF0aW9uLAogICAgICAgICAgICAgIHVzZWQgdG8gYXNzaXN0IHRoZSBjbGllbnQgZGV2ZWxv cGVyIGluIHVuZGVyc3RhbmRpbmcgdGhlIGVycm9yIHRoYXQgb2NjdXJyZWQuCgkgICAgICA8dnNw YWNlLz4KCSAgICAgIFZhbHVlcyBmb3IgdGhlIDxzcGFueCBzdHlsZT0ndmVyYic+ZXJyb3JfZGVz Y3JpcHRpb248L3NwYW54PiBwYXJhbWV0ZXIgTVVTVCBOT1QgaW5jbHVkZQoJICAgICAgY2hhcmFj dGVycyBvdXRzaWRlIHRoZSBzZXQgJXgyMC0yMSAvICV4MjMtNUIgLyAleDVELTdFLgogICAgICAg ICAgICA8L3Q+CiAgICAgICAgICAgIDx0IGhhbmdUZXh0PSdlcnJvcl91cmknPgogICAgICAgICAg ICAgIDx2c3BhY2UgLz4KICAgICAgICAgICAgICBPUFRJT05BTC4gQSBVUkkgaWRlbnRpZnlpbmcg YSBodW1hbi1yZWFkYWJsZSB3ZWIgcGFnZSB3aXRoIGluZm9ybWF0aW9uIGFib3V0IHRoZQogICAg ICAgICAgICAgIGVycm9yLCB1c2VkIHRvIHByb3ZpZGUgdGhlIGNsaWVudCBkZXZlbG9wZXIgd2l0 aCBhZGRpdGlvbmFsIGluZm9ybWF0aW9uIGFib3V0IHRoZQogICAgICAgICAgICAgIGVycm9yLgoJ ICAgICAgPHZzcGFjZS8+CgkgICAgICBWYWx1ZXMgZm9yIHRoZSA8c3Bhbnggc3R5bGU9J3ZlcmIn PmVycm9yX3VyaTwvc3Bhbng+IHBhcmFtZXRlcgoJICAgICAgTVVTVCBjb25mb3JtIHRvIHRoZSBV UkktUmVmZXJlbmNlIHN5bnRheCwgYW5kIHRodXMgTVVTVCBOT1QgaW5jbHVkZQoJICAgICAgY2hh cmFjdGVycyBvdXRzaWRlIHRoZSBzZXQgJXgyMSAvICV4MjMtNUIgLyAleDVELTdFLgogICAgICAg ICAgICA8L3Q+CiAgICAgICAgICA8L2xpc3Q+CiAgICAgICAgPC90PgogICAgICAgIDx0PgogICAg ICAgICAgVGhlIHBhcmFtZXRlcnMgYXJlIGluY2x1ZGVkIGluIHRoZSBlbnRpdHkgYm9keSBvZiB0 aGUgSFRUUCByZXNwb25zZSB1c2luZyB0aGUKICAgICAgICAgIDxzcGFueCBzdHlsZT0ndmVyYic+ YXBwbGljYXRpb24vanNvbjwvc3Bhbng+IG1lZGlhIHR5cGUgYXMgZGVmaW5lZCBieQogICAgICAg ICAgPHhyZWYgdGFyZ2V0PSdSRkM0NjI3JyAvPi4gVGhlIHBhcmFtZXRlcnMgYXJlIHNlcmlhbGl6 ZWQgaW50byBhIEpTT04gc3RydWN0dXJlIGJ5CiAgICAgICAgICBhZGRpbmcgZWFjaCBwYXJhbWV0 ZXIgYXQgdGhlIGhpZ2hlc3Qgc3RydWN0dXJlIGxldmVsLiBQYXJhbWV0ZXIgbmFtZXMgYW5kIHN0 cmluZyB2YWx1ZXMKICAgICAgICAgIGFyZSBpbmNsdWRlZCBhcyBKU09OIHN0cmluZ3MuIE51bWVy aWNhbCB2YWx1ZXMgYXJlIGluY2x1ZGVkIGFzIEpTT04gbnVtYmVycy4gVGhlIG9yZGVyIG9mCiAg ICAgICAgICBwYXJhbWV0ZXJzIGRvZXMgbm90IG1hdHRlciBhbmQgY2FuIHZhcnkuCiAgICAgICAg PC90PgogICAgICAgIDxmaWd1cmU+CiAgICAgICAgICA8cHJlYW1ibGU+CiAgICAgICAgICAgIEZv ciBleGFtcGxlOgogICAgICAgICAgPC9wcmVhbWJsZT4KICAgICAgICAgIDxhcnR3b3JrPgogICAg ICAgICAgICA8IVtDREFUQVsKICBIVFRQLzEuMSA0MDAgQmFkIFJlcXVlc3QKICBDb250ZW50LVR5 cGU6IGFwcGxpY2F0aW9uL2pzb247Y2hhcnNldD1VVEYtOAogIENhY2hlLUNvbnRyb2w6IG5vLXN0 b3JlCiAgUHJhZ21hOiBuby1jYWNoZQoKICB7CiAgICAiZXJyb3IiOiJpbnZhbGlkX3JlcXVlc3Qi CiAgfQpdXT4KICAgICAgICAgIDwvYXJ0d29yaz4KICAgICAgICA8L2ZpZ3VyZT4KICAgICAgPC9z ZWN0aW9uPgoKICAgIDwvc2VjdGlvbj4KCiAgICA8c2VjdGlvbiB0aXRsZT0nUmVmcmVzaGluZyBh biBBY2Nlc3MgVG9rZW4nIGFuY2hvcj0ndG9rZW4tcmVmcmVzaCc+CiAgICAgIDx0PgogICAgICAg IElmIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBpc3N1ZWQgYSByZWZyZXNoIHRva2VuIHRvIHRo ZSBjbGllbnQsIHRoZSBjbGllbnQgbWFrZXMgYQogICAgICAgIHJlZnJlc2ggcmVxdWVzdCB0byB0 aGUgdG9rZW4gZW5kcG9pbnQgYnkgYWRkaW5nIHRoZSBmb2xsb3dpbmcgcGFyYW1ldGVycyB1c2lu ZyB0aGUKICAgICAgICA8c3Bhbnggc3R5bGU9J3ZlcmInPmFwcGxpY2F0aW9uL3gtd3d3LWZvcm0t dXJsZW5jb2RlZDwvc3Bhbng+IGZvcm1hdCBpbiB0aGUgSFRUUCByZXF1ZXN0CiAgICAgICAgZW50 aXR5LWJvZHk6CiAgICAgIDwvdD4KICAgICAgPHQ+CiAgICAgICAgPGxpc3Qgc3R5bGU9J2hhbmdp bmcnIGhhbmdJbmRlbnQ9JzYnPgogICAgICAgICAgPHQgaGFuZ1RleHQ9J2dyYW50X3R5cGUnPgog ICAgICAgICAgICA8dnNwYWNlIC8+CiAgICAgICAgICAgIFJFUVVJUkVELiBWYWx1ZSBNVVNUIGJl IHNldCB0byA8c3Bhbnggc3R5bGU9J3ZlcmInPnJlZnJlc2hfdG9rZW48L3NwYW54Pi4KICAgICAg ICAgIDwvdD4KICAgICAgICAgIDx0IGhhbmdUZXh0PSdyZWZyZXNoX3Rva2VuJz4KICAgICAgICAg ICAgPHZzcGFjZSAvPgogICAgICAgICAgICBSRVFVSVJFRC4gVGhlIHJlZnJlc2ggdG9rZW4gaXNz dWVkIHRvIHRoZSBjbGllbnQuCiAgICAgICAgICA8L3Q+CiAgICAgICAgICA8dCBoYW5nVGV4dD0n c2NvcGUnPgogICAgICAgICAgICA8dnNwYWNlIC8+CiAgICAgICAgICAgIE9QVElPTkFMLiBUaGUg c2NvcGUgb2YgdGhlIGFjY2VzcyByZXF1ZXN0IGFzIGRlc2NyaWJlZCBieSA8eHJlZiB0YXJnZXQ9 J3Njb3BlJyAvPi4KICAgICAgICAgICAgVGhlIHJlcXVlc3RlZCBzY29wZSBNVVNUIE5PVCBpbmNs dWRlIGFueSBzY29wZSBub3Qgb3JpZ2luYWxseSBncmFudGVkIGJ5IHRoZSByZXNvdXJjZQogICAg ICAgICAgICBvd25lciwgYW5kIGlmIG9taXR0ZWQgaXMgdHJlYXRlZCBhcyBlcXVhbCB0byB0aGUg c2NvcGUgb3JpZ2luYWxseSBncmFudGVkIGJ5IHRoZQogICAgICAgICAgICByZXNvdXJjZSBvd25l ci4KICAgICAgICAgIDwvdD4KICAgICAgICA8L2xpc3Q+CiAgICAgIDwvdD4KICAgICAgPHQ+CiAg ICAgICAgQmVjYXVzZSByZWZyZXNoIHRva2VucyBhcmUgdHlwaWNhbGx5IGxvbmctbGFzdGluZyBj cmVkZW50aWFscyB1c2VkIHRvIHJlcXVlc3QgYWRkaXRpb25hbAogICAgICAgIGFjY2VzcyB0b2tl bnMsIHRoZSByZWZyZXNoIHRva2VuIGlzIGJvdW5kIHRvIHRoZSBjbGllbnQgdG8gd2hpY2ggaXQg d2FzIGlzc3VlZC4gSWYgdGhlIGNsaWVudCB0eXBlCiAgICAgICAgaXMgY29uZmlkZW50aWFsIG9y IHRoZSBjbGllbnQgd2FzIGlzc3VlZCBjbGllbnQgY3JlZGVudGlhbHMgKG9yIGFzc2lnbmVkIG90 aGVyCiAgICAgICAgYXV0aGVudGljYXRpb24gcmVxdWlyZW1lbnRzKSwgdGhlIGNsaWVudCBNVVNU IGF1dGhlbnRpY2F0ZSB3aXRoIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBhcwogICAgICAgIGRl c2NyaWJlZCBpbiA8eHJlZiB0YXJnZXQ9J3Rva2VuLWVuZHBvaW50LWF1dGgnIC8+LgogICAgICA8 L3Q+CiAgICAgIDxmaWd1cmU+CiAgICAgICAgPHByZWFtYmxlPgogICAgICAgICAgRm9yIGV4YW1w bGUsIHRoZSBjbGllbnQgbWFrZXMgdGhlIGZvbGxvd2luZyBIVFRQIHJlcXVlc3QgdXNpbmcgdHJh bnNwb3J0LWxheWVyCiAgICAgICAgICBzZWN1cml0eSAoZXh0cmEgbGluZSBicmVha3MgYXJlIGZv ciBkaXNwbGF5IHB1cnBvc2VzIG9ubHkpOgogICAgICAgIDwvcHJlYW1ibGU+CiAgICAgICAgPGFy dHdvcms+CiAgICAgICAgICA8IVtDREFUQVsKICBQT1NUIC90b2tlbiBIVFRQLzEuMQogIEhvc3Q6 IHNlcnZlci5leGFtcGxlLmNvbQogIEF1dGhvcml6YXRpb246IEJhc2ljIGN6WkNhR1JTYTNGME16 cG5XREZtUW1GME0ySlcKICBDb250ZW50LVR5cGU6IGFwcGxpY2F0aW9uL3gtd3d3LWZvcm0tdXJs ZW5jb2RlZDtjaGFyc2V0PVVURi04CiAgCiAgZ3JhbnRfdHlwZT1yZWZyZXNoX3Rva2VuJnJlZnJl c2hfdG9rZW49dEd6djNKT2tGMFhHNVF4MlRsS1dJQQpdXT4KICAgICAgICA8L2FydHdvcms+CiAg ICAgIDwvZmlndXJlPgogICAgICA8dD4KICAgICAgICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIg TVVTVDoKICAgICAgPC90PgogICAgICA8dD4KICAgICAgICA8bGlzdCBzdHlsZT0nc3ltYm9scyc+ CiAgICAgICAgICA8dD4KICAgICAgICAgICAgcmVxdWlyZSBjbGllbnQgYXV0aGVudGljYXRpb24g Zm9yIGNvbmZpZGVudGlhbCBjbGllbnRzIG9yIGZvciBhbnkgY2xpZW50IHRoYXQgd2FzCiAgICAg ICAgICAgIGlzc3VlZCBjbGllbnQgY3JlZGVudGlhbHMgKG9yIHdpdGggb3RoZXIgYXV0aGVudGlj YXRpb24gcmVxdWlyZW1lbnRzKSwKICAgICAgICAgIDwvdD4KICAgICAgICAgIDx0PgogICAgICAg ICAgICBhdXRoZW50aWNhdGUgdGhlIGNsaWVudCBpZiBjbGllbnQgYXV0aGVudGljYXRpb24gaXMg aW5jbHVkZWQgYW5kIGVuc3VyZSB0aGUKICAgICAgICAgICAgcmVmcmVzaCB0b2tlbiB3YXMgaXNz dWVkIHRvIHRoZSBhdXRoZW50aWNhdGVkIGNsaWVudCwgYW5kCiAgICAgICAgICA8L3Q+CiAgICAg ICAgICA8dD4KICAgICAgICAgICAgdmFsaWRhdGUgdGhlIHJlZnJlc2ggdG9rZW4uCiAgICAgICAg ICA8L3Q+CiAgICAgICAgPC9saXN0PgogICAgICA8L3Q+CiAgICAgIDx0PgogICAgICAgIElmIHZh bGlkIGFuZCBhdXRob3JpemVkLCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgaXNzdWVzIGFuIGFj Y2VzcyB0b2tlbiBhcyBkZXNjcmliZWQgaW4KICAgICAgICA8eHJlZiB0YXJnZXQ9J3Rva2VuLXJl c3BvbnNlJyAvPi4gSWYgdGhlIHJlcXVlc3QgZmFpbGVkIHZlcmlmaWNhdGlvbiBvciBpcyBpbnZh bGlkLCB0aGUKICAgICAgICBhdXRob3JpemF0aW9uIHNlcnZlciByZXR1cm5zIGFuIGVycm9yIHJl c3BvbnNlIGFzIGRlc2NyaWJlZCBpbgogICAgICAgIDx4cmVmIHRhcmdldD0ndG9rZW4tZXJyb3Jz JyAvPi4KICAgICAgPC90PgogICAgICA8dD4KICAgICAgICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2 ZXIgTUFZIGlzc3VlIGEgbmV3IHJlZnJlc2ggdG9rZW4sIGluIHdoaWNoIGNhc2UgdGhlIGNsaWVu dCBNVVNUCiAgICAgICAgZGlzY2FyZCB0aGUgb2xkIHJlZnJlc2ggdG9rZW4gYW5kIHJlcGxhY2Ug aXQgd2l0aCB0aGUgbmV3IHJlZnJlc2ggdG9rZW4uIFRoZSBhdXRob3JpemF0aW9uCiAgICAgICAg c2VydmVyIE1BWSByZXZva2UgdGhlIG9sZCByZWZyZXNoIHRva2VuIGFmdGVyIGlzc3VpbmcgYSBu ZXcgcmVmcmVzaCB0b2tlbiB0byB0aGUgY2xpZW50LiBJZgogICAgICAgIGEgbmV3IHJlZnJlc2gg dG9rZW4gaXMgaXNzdWVkLCB0aGUgcmVmcmVzaCB0b2tlbiBzY29wZSBNVVNUIGJlIGlkZW50aWNh bCB0byB0aGF0IG9mIHRoZQogICAgICAgIHJlZnJlc2ggdG9rZW4gaW5jbHVkZWQgYnkgdGhlIGNs aWVudCBpbiB0aGUgcmVxdWVzdC4KICAgICAgPC90PgogICAgPC9zZWN0aW9uPgoKICAgIDxzZWN0 aW9uIHRpdGxlPSdBY2Nlc3NpbmcgUHJvdGVjdGVkIFJlc291cmNlcycgYW5jaG9yPSdhY2Nlc3Mt cmVzb3VyY2UnPgogICAgICA8dD4KICAgICAgICBUaGUgY2xpZW50IGFjY2Vzc2VzIHByb3RlY3Rl ZCByZXNvdXJjZXMgYnkgcHJlc2VudGluZyB0aGUgYWNjZXNzIHRva2VuIHRvIHRoZSByZXNvdXJj ZQogICAgICAgIHNlcnZlci4gVGhlIHJlc291cmNlIHNlcnZlciBNVVNUIHZhbGlkYXRlIHRoZSBh Y2Nlc3MgdG9rZW4gYW5kIGVuc3VyZSBpdCBoYXMgbm90IGV4cGlyZWQKICAgICAgICBhbmQgdGhh dCBpdHMgc2NvcGUgY292ZXJzIHRoZSByZXF1ZXN0ZWQgcmVzb3VyY2UuIFRoZSBtZXRob2RzIHVz ZWQgYnkgdGhlIHJlc291cmNlIHNlcnZlcgogICAgICAgIHRvIHZhbGlkYXRlIHRoZSBhY2Nlc3Mg dG9rZW4gKGFzIHdlbGwgYXMgYW55IGVycm9yIHJlc3BvbnNlcykgYXJlIGJleW9uZCB0aGUgc2Nv cGUgb2YgdGhpcwogICAgICAgIHNwZWNpZmljYXRpb24sIGJ1dCBnZW5lcmFsbHkgaW52b2x2ZSBh biBpbnRlcmFjdGlvbiBvciBjb29yZGluYXRpb24gYmV0d2VlbiB0aGUgcmVzb3VyY2UKICAgICAg ICBzZXJ2ZXIgYW5kIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlci4KICAgICAgPC90PgogICAgICA8 dD4KICAgICAgICBUaGUgbWV0aG9kIGluIHdoaWNoIHRoZSBjbGllbnQgdXRpbGl6ZXMgdGhlIGFj Y2VzcyB0b2tlbiB0byBhdXRoZW50aWNhdGUgd2l0aCB0aGUgcmVzb3VyY2UKICAgICAgICBzZXJ2 ZXIgZGVwZW5kcyBvbiB0aGUgdHlwZSBvZiBhY2Nlc3MgdG9rZW4gaXNzdWVkIGJ5IHRoZSBhdXRo b3JpemF0aW9uIHNlcnZlci4gVHlwaWNhbGx5LAogICAgICAgIGl0IGludm9sdmVzIHVzaW5nIHRo ZSBIVFRQIDxzcGFueCBzdHlsZT0ndmVyYic+QXV0aG9yaXphdGlvbjwvc3Bhbng+IHJlcXVlc3Qg aGVhZGVyIGZpZWxkCiAgICAgICAgPHhyZWYgdGFyZ2V0PSdSRkMyNjE3JyAvPiB3aXRoIGFuIGF1 dGhlbnRpY2F0aW9uIHNjaGVtZSBkZWZpbmVkIGJ5IHRoZSBhY2Nlc3MgdG9rZW4gdHlwZQogICAg ICAgIHNwZWNpZmljYXRpb24uCiAgICAgIDwvdD4KCiAgICAgIDxzZWN0aW9uIHRpdGxlPSdBY2Nl c3MgVG9rZW4gVHlwZXMnIGFuY2hvcj0ndG9rZW4tdHlwZXMnPgogICAgICAgIDx0PgogICAgICAg ICAgVGhlIGFjY2VzcyB0b2tlbiB0eXBlIHByb3ZpZGVzIHRoZSBjbGllbnQgd2l0aCB0aGUgaW5m b3JtYXRpb24gcmVxdWlyZWQgdG8gc3VjY2Vzc2Z1bGx5CiAgICAgICAgICB1dGlsaXplIHRoZSBh Y2Nlc3MgdG9rZW4gdG8gbWFrZSBhIHByb3RlY3RlZCByZXNvdXJjZSByZXF1ZXN0IChhbG9uZyB3 aXRoIHR5cGUtc3BlY2lmaWMKICAgICAgICAgIGF0dHJpYnV0ZXMpLiBUaGUgY2xpZW50IE1VU1Qg Tk9UIHVzZSBhbiBhY2Nlc3MgdG9rZW4gaWYgaXQgZG9lcyBub3QgdW5kZXJzdGFuZCB0aGUgdG9r ZW4KICAgICAgICAgIHR5cGUuCiAgICAgICAgPC90PgogICAgICAgIDxmaWd1cmU+CiAgICAgICAg ICA8cHJlYW1ibGU+CiAgICAgICAgICAgIEZvciBleGFtcGxlLCB0aGUgPHNwYW54IHN0eWxlPSd2 ZXJiJz5iZWFyZXI8L3NwYW54PiB0b2tlbiB0eXBlIGRlZmluZWQgaW4KICAgICAgICAgICAgPHhy ZWYgdGFyZ2V0PSdJLUQuaWV0Zi1vYXV0aC12Mi1iZWFyZXInIC8+IGlzIHV0aWxpemVkIGJ5IHNp bXBseSBpbmNsdWRpbmcgdGhlIGFjY2VzcwogICAgICAgICAgICB0b2tlbiBzdHJpbmcgaW4gdGhl IHJlcXVlc3Q6CiAgICAgICAgICA8L3ByZWFtYmxlPgogICAgICAgICAgPGFydHdvcms+CiAgICAg ICAgICAgIDwhW0NEQVRBWwogIEdFVCAvcmVzb3VyY2UvMSBIVFRQLzEuMQogIEhvc3Q6IGV4YW1w bGUuY29tCiAgQXV0aG9yaXphdGlvbjogQmVhcmVyIG1GXzkuQjVmLTQuMUpxTQpdXT4KICAgICAg ICAgIDwvYXJ0d29yaz4KICAgICAgICA8L2ZpZ3VyZT4KICAgICAgICA8ZmlndXJlPgogICAgICAg ICAgPHByZWFtYmxlPgogICAgICAgICAgICB3aGlsZSB0aGUgPHNwYW54IHN0eWxlPSd2ZXJiJz5t YWM8L3NwYW54PiB0b2tlbiB0eXBlIGRlZmluZWQgaW4KICAgICAgICAgICAgPHhyZWYgdGFyZ2V0 PSdJLUQuaWV0Zi1vYXV0aC12Mi1odHRwLW1hYycgLz4gaXMgdXRpbGl6ZWQgYnkgaXNzdWluZyBh IE1BQyBrZXkKICAgICAgICAgICAgdG9nZXRoZXIgd2l0aCB0aGUgYWNjZXNzIHRva2VuIHdoaWNo IGlzIHVzZWQgdG8gc2lnbiBjZXJ0YWluIGNvbXBvbmVudHMgb2YgdGhlIEhUVFAKICAgICAgICAg ICAgcmVxdWVzdHM6CiAgICAgICAgICA8L3ByZWFtYmxlPgogICAgICAgICAgPGFydHdvcms+CiAg ICAgICAgICAgIDwhW0NEQVRBWwogIEdFVCAvcmVzb3VyY2UvMSBIVFRQLzEuMQogIEhvc3Q6IGV4 YW1wbGUuY29tCiAgQXV0aG9yaXphdGlvbjogTUFDIGlkPSJoNDgwZGpzOTNoZDgiLAogICAgICAg ICAgICAgICAgICAgICBub25jZT0iMjc0MzEyOmRqODNoczlzIiwKICAgICAgICAgICAgICAgICAg ICAgbWFjPSJrRFp2ZGRrbmR4dmhHUlhaaHZ1RGpFV2hHZUU9IgpdXT4KICAgICAgICAgIDwvYXJ0 d29yaz4KICAgICAgICA8L2ZpZ3VyZT4KICAgICAgICA8dD4KICAgICAgICAgIFRoZSBhYm92ZSBl eGFtcGxlcyBhcmUgcHJvdmlkZWQgZm9yIGlsbHVzdHJhdGlvbiBwdXJwb3NlcyBvbmx5LiBEZXZl bG9wZXJzIGFyZSBhZHZpc2VkIHRvCiAgICAgICAgICBjb25zdWx0IHRoZSA8eHJlZiB0YXJnZXQ9 J0ktRC5pZXRmLW9hdXRoLXYyLWJlYXJlcicgLz4gYW5kCiAgICAgICAgICA8eHJlZiB0YXJnZXQ9 J0ktRC5pZXRmLW9hdXRoLXYyLWh0dHAtbWFjJyAvPiBzcGVjaWZpY2F0aW9ucyBiZWZvcmUgdXNl LgogICAgICAgIDwvdD4KICAgICAgICA8dD4KICAgICAgICAgIEVhY2ggYWNjZXNzIHRva2VuIHR5 cGUgZGVmaW5pdGlvbiBzcGVjaWZpZXMgdGhlIGFkZGl0aW9uYWwgYXR0cmlidXRlcyAoaWYgYW55 KSBzZW50IHRvCiAgICAgICAgICB0aGUgY2xpZW50IHRvZ2V0aGVyIHdpdGggdGhlIDxzcGFueCBz dHlsZT0ndmVyYic+YWNjZXNzX3Rva2VuPC9zcGFueD4gcmVzcG9uc2UgcGFyYW1ldGVyLgogICAg ICAgICAgSXQgYWxzbyBkZWZpbmVzIHRoZSBIVFRQIGF1dGhlbnRpY2F0aW9uIG1ldGhvZCB1c2Vk IHRvIGluY2x1ZGUgdGhlIGFjY2VzcyB0b2tlbiB3aGVuCiAgICAgICAgICBtYWtpbmcgYSBwcm90 ZWN0ZWQgcmVzb3VyY2UgcmVxdWVzdC4KICAgICAgICA8L3Q+CiAgICAgIDwvc2VjdGlvbj4KCiAg ICAgIDxzZWN0aW9uIHRpdGxlPSdFcnJvciBSZXNwb25zZScgYW5jaG9yPSdyZXNvdXJjZS1lcnJv cnMnPgoJPHQ+CgkgIElmIGEgcmVzb3VyY2UgYWNjZXNzIHJlcXVlc3QgZmFpbHMsIHRoZSByZXNv dXJjZSBzZXJ2ZXIgU0hPVUxEIGluZm9ybQoJICB0aGUgY2xpZW50IG9mIHRoZSBlcnJvci4gIFdo aWxlIHRoZSBzcGVjaWZpY3Mgb2Ygc3VjaCBlcnJvciByZXNwb25zZXMKCSAgYXJlIGJleW9uZCB0 aGUgc2NvcGUgb2YgdGhpcyBzcGVjaWZpY2F0aW9uLCB0aGlzIGRvY3VtZW50cyBlc3RhYmxpc2hl cwoJICBhIGNvbW1vbiByZWdpc3RyeSBpbiA8eHJlZiB0YXJnZXQ9J2Vycm9yLXJlZ2lzdHJ5JyAv PiBmb3IgZXJyb3IgdmFsdWVzCgkgIHRvIGJlIHNoYXJlZCBhbW9uZyBPQXV0aCB0b2tlbiBhdXRo ZW50aWNhdGlvbiBzY2hlbWVzLiAKCTwvdD4KCTx0PgoJICBOZXcgYXV0aGVudGljYXRpb24gc2No ZW1lcyBkZXNpZ25lZCBwcmltYXJpbHkgZm9yIE9BdXRoIHRva2VuCgkgIGF1dGhlbnRpY2F0aW9u IFNIT1VMRCBkZWZpbmUgYSBtZWNoYW5pc20gZm9yIHByb3ZpZGluZyBhbgoJICBlcnJvciBzdGF0 dXMgY29kZSB0byB0aGUgY2xpZW50LCBpbiB3aGljaCB0aGUgZXJyb3IgdmFsdWVzIGFsbG93ZWQg YXJlCgkgIHJlZ2lzdGVyZWQgaW4gdGhlIGVycm9yIHJlZ2lzdHJ5IGVzdGFibGlzaGVkIGJ5IHRo aXMgc3BlY2lmaWNhdGlvbi4gU3VjaAoJICBzY2hlbWVzIE1BWSBsaW1pdCB0aGUgc2V0IG9mIHZh bGlkIGVycm9yIGNvZGVzIHRvIGEgc3Vic2V0IG9mIHRoZQoJICByZWdpc3RlcmVkIHZhbHVlcy4g SWYgdGhlIGVycm9yIGNvZGUgaXMgcmV0dXJuZWQgdXNpbmcgYSBuYW1lZCBwYXJhbWV0ZXIsCgkg IHRoZSBwYXJhbWV0ZXIgbmFtZSBTSE9VTEQgYmUgPHNwYW54IHN0eWxlPSd2ZXJiJz5lcnJvcjwv c3Bhbng+LgoJPC90PgoJPHQ+CgkgIE90aGVyIHNjaGVtZXMgY2FwYWJsZSBvZiBiZWluZyB1c2Vk IGZvciBPQXV0aCB0b2tlbiBhdXRoZW50aWNhdGlvbiwgYnV0CgkgIG5vdCBwcmltYXJpbHkgZGVz aWduZWQgZm9yIHRoYXQgcHVycG9zZSwgTUFZIGJpbmQgdGhlaXIgZXJyb3IgdmFsdWVzIHRvIHRo ZQoJICByZWdpc3RyeSBpbiB0aGUgc2FtZSBtYW5uZXIuCgk8L3Q+Cgk8dD4KCSAgTmV3IGF1dGhl bnRpY2F0aW9uIHNjaGVtZXMgTUFZIGNob29zZSB0byBhbHNvIHNwZWNpZnkgdGhlIHVzZSBvZiB0 aGUKCSAgPHNwYW54IHN0eWxlPSd2ZXJiJz5lcnJvcl9kZXNjcmlwdGlvbjwvc3Bhbng+IGFuZCAK CSAgPHNwYW54IHN0eWxlPSd2ZXJiJz5lcnJvcl91cmk8L3NwYW54PgoJICBwYXJhbWV0ZXJzIHRv IHJldHVybiBlcnJvciBpbmZvcm1hdGlvbiBpbiBhIG1hbm5lciBwYXJhbGxlbAoJICB0byB0aGVp ciB1c2FnZSBpbiB0aGlzIHNwZWNpZmljYXRpb24uCgk8L3Q+CiAgICAgIDwvc2VjdGlvbj4KCiAg ICA8L3NlY3Rpb24+CgogICAgPHNlY3Rpb24gdGl0bGU9J0V4dGVuc2liaWxpdHknIGFuY2hvcj0n ZXh0ZW5zaW9ucyc+CgogICAgICA8c2VjdGlvbiB0aXRsZT0nRGVmaW5pbmcgQWNjZXNzIFRva2Vu IFR5cGVzJyBhbmNob3I9J25ldy10eXBlcyc+CiAgICAgICAgPHQ+CiAgICAgICAgICBBY2Nlc3Mg dG9rZW4gdHlwZXMgY2FuIGJlIGRlZmluZWQgaW4gb25lIG9mIHR3byB3YXlzOiByZWdpc3RlcmVk IGluIHRoZSBhY2Nlc3MgdG9rZW4gdHlwZQogICAgICAgICAgcmVnaXN0cnkgKGZvbGxvd2luZyB0 aGUgcHJvY2VkdXJlcyBpbiA8eHJlZiB0YXJnZXQ9J3R5cGUtcmVnaXN0cnknIC8+KSwgb3IgYnkg dXNpbmcgYQogICAgICAgICAgdW5pcXVlIGFic29sdXRlIFVSSSBhcyBpdHMgbmFtZS4KICAgICAg ICA8L3Q+CiAgICAgICAgPHQ+CiAgICAgICAgICBUeXBlcyB1dGlsaXppbmcgYSBVUkkgbmFtZSBT SE9VTEQgYmUgbGltaXRlZCB0byB2ZW5kb3Itc3BlY2lmaWMgaW1wbGVtZW50YXRpb25zIHRoYXQg YXJlCiAgICAgICAgICBub3QgY29tbW9ubHkgYXBwbGljYWJsZSwgYW5kIGFyZSBzcGVjaWZpYyB0 byB0aGUgaW1wbGVtZW50YXRpb24gZGV0YWlscyBvZiB0aGUgcmVzb3VyY2UKICAgICAgICAgIHNl cnZlciB3aGVyZSB0aGV5IGFyZSB1c2VkLgogICAgICAgIDwvdD4KICAgICAgICA8dD4KICAgICAg ICAgIEFsbCBvdGhlciB0eXBlcyBNVVNUIGJlIHJlZ2lzdGVyZWQuIFR5cGUgbmFtZXMgTVVTVCBj b25mb3JtIHRvIHRoZSB0eXBlLW5hbWUgQUJORi4gSWYgdGhlCiAgICAgICAgICB0eXBlIGRlZmlu aXRpb24gaW5jbHVkZXMgYSBuZXcgSFRUUCBhdXRoZW50aWNhdGlvbiBzY2hlbWUsIHRoZSB0eXBl IG5hbWUgU0hPVUxEIGJlCiAgICAgICAgICBpZGVudGljYWwgdG8gdGhlIEhUVFAgYXV0aGVudGlj YXRpb24gc2NoZW1lIG5hbWUgKGFzIGRlZmluZWQgYnkgPHhyZWYgdGFyZ2V0PSdSRkMyNjE3JyAv PikuCiAgICAgICAgICBUaGUgdG9rZW4gdHlwZSA8c3Bhbnggc3R5bGU9J3ZlcmInPmV4YW1wbGU8 L3NwYW54PiBpcyByZXNlcnZlZCBmb3IgdXNlIGluIGV4YW1wbGVzLgogICAgICAgIDwvdD4KICAg ICAgICA8ZmlndXJlPgogICAgICAgICAgPGFydHdvcms+CiAgICAgICAgICAgIDwhW0NEQVRBWwog IHR5cGUtbmFtZSAgPSAxKm5hbWUtY2hhcgogIG5hbWUtY2hhciAgPSAiLSIgLyAiLiIgLyAiXyIg LyBESUdJVCAvIEFMUEhBCl1dPgogICAgICAgICAgPC9hcnR3b3JrPgogICAgICAgIDwvZmlndXJl PgogICAgICA8L3NlY3Rpb24+CgogICAgICA8c2VjdGlvbiB0aXRsZT0nRGVmaW5pbmcgTmV3IEVu ZHBvaW50IFBhcmFtZXRlcnMnIGFuY2hvcj0iZW5kcG9pbnQtcGFyYW1zIj4KICAgICAgICA8dD4K ICAgICAgICAgIE5ldyByZXF1ZXN0IG9yIHJlc3BvbnNlIHBhcmFtZXRlcnMgZm9yIHVzZSB3aXRo IHRoZSBhdXRob3JpemF0aW9uIGVuZHBvaW50IG9yIHRoZSB0b2tlbgogICAgICAgICAgZW5kcG9p bnQgYXJlIGRlZmluZWQgYW5kIHJlZ2lzdGVyZWQgaW4gdGhlIHBhcmFtZXRlcnMgcmVnaXN0cnkg Zm9sbG93aW5nIHRoZSBwcm9jZWR1cmUgaW4KICAgICAgICAgIDx4cmVmIHRhcmdldD0ncGFyYW1l dGVycy1yZWdpc3RyeScgLz4uCiAgICAgICAgPC90PgogICAgICAgIDx0PgogICAgICAgICAgUGFy YW1ldGVyIG5hbWVzIE1VU1QgY29uZm9ybSB0byB0aGUgcGFyYW0tbmFtZSBBQk5GIGFuZCBwYXJh bWV0ZXIgdmFsdWVzIHN5bnRheCBNVVNUIGJlCiAgICAgICAgICB3ZWxsLWRlZmluZWQgKGUuZy4s IHVzaW5nIEFCTkYsIG9yIGEgcmVmZXJlbmNlIHRvIHRoZSBzeW50YXggb2YgYW4gZXhpc3Rpbmcg cGFyYW1ldGVyKS4KICAgICAgICA8L3Q+CiAgICAgICAgPGZpZ3VyZT4KICAgICAgICAgIDxhcnR3 b3JrPgogICAgICAgICAgICA8IVtDREFUQVsKICBwYXJhbS1uYW1lICA9IDEqbmFtZS1jaGFyCiAg bmFtZS1jaGFyICAgPSAiLSIgLyAiLiIgLyAiXyIgLyBESUdJVCAvIEFMUEhBCl1dPgogICAgICAg ICAgPC9hcnR3b3JrPgogICAgICAgIDwvZmlndXJlPgogICAgICAgIDx0PgogICAgICAgICAgVW5y ZWdpc3RlcmVkIHZlbmRvci1zcGVjaWZpYyBwYXJhbWV0ZXIgZXh0ZW5zaW9ucyB0aGF0IGFyZSBu b3QgY29tbW9ubHkgYXBwbGljYWJsZSwgYW5kCiAgICAgICAgICBhcmUgc3BlY2lmaWMgdG8gdGhl IGltcGxlbWVudGF0aW9uIGRldGFpbHMgb2YgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHdoZXJl IHRoZXkgYXJlCiAgICAgICAgICB1c2VkIFNIT1VMRCB1dGlsaXplIGEgdmVuZG9yLXNwZWNpZmlj IHByZWZpeCB0aGF0IGlzIG5vdCBsaWtlbHkgdG8gY29uZmxpY3Qgd2l0aCBvdGhlcgogICAgICAg ICAgcmVnaXN0ZXJlZCB2YWx1ZXMgKGUuZy4gYmVnaW4gd2l0aCAnY29tcGFueW5hbWVfJykuCiAg ICAgICAgPC90PgogICAgICA8L3NlY3Rpb24+CgogICAgICA8c2VjdGlvbiB0aXRsZT0nRGVmaW5p bmcgTmV3IEF1dGhvcml6YXRpb24gR3JhbnQgVHlwZXMnPgogICAgICAgIDx0PgogICAgICAgICAg TmV3IGF1dGhvcml6YXRpb24gZ3JhbnQgdHlwZXMgY2FuIGJlIGRlZmluZWQgYnkgYXNzaWduaW5n IHRoZW0gYSB1bmlxdWUgYWJzb2x1dGUgVVJJIGZvcgogICAgICAgICAgdXNlIHdpdGggdGhlIDxz cGFueCBzdHlsZT0ndmVyYic+Z3JhbnRfdHlwZTwvc3Bhbng+IHBhcmFtZXRlci4gSWYgdGhlIGV4 dGVuc2lvbiBncmFudAogICAgICAgICAgdHlwZSByZXF1aXJlcyBhZGRpdGlvbmFsIHRva2VuIGVu ZHBvaW50IHBhcmFtZXRlcnMsIHRoZXkgTVVTVCBiZSByZWdpc3RlcmVkIGluIHRoZSBPQXV0aAog ICAgICAgICAgcGFyYW1ldGVycyByZWdpc3RyeSBhcyBkZXNjcmliZWQgYnkgPHhyZWYgdGFyZ2V0 PSdwYXJhbWV0ZXJzLXJlZ2lzdHJ5JyAvPi4KICAgICAgICA8L3Q+CiAgICAgIDwvc2VjdGlvbj4K CiAgICAgIDxzZWN0aW9uIHRpdGxlPSdEZWZpbmluZyBOZXcgQXV0aG9yaXphdGlvbiBFbmRwb2lu dCBSZXNwb25zZSBUeXBlcycgYW5jaG9yPSdyZXNwb25zZS10eXBlLWV4dCc+CiAgICAgICAgPHQ+ CiAgICAgICAgICBOZXcgcmVzcG9uc2UgdHlwZXMgZm9yIHVzZSB3aXRoIHRoZSBhdXRob3JpemF0 aW9uIGVuZHBvaW50IGFyZSBkZWZpbmVkIGFuZCByZWdpc3RlcmVkIGluCiAgICAgICAgICB0aGUg YXV0aG9yaXphdGlvbiBlbmRwb2ludCByZXNwb25zZSB0eXBlIHJlZ2lzdHJ5IGZvbGxvd2luZyB0 aGUgcHJvY2VkdXJlIGluCiAgICAgICAgICA8eHJlZiB0YXJnZXQ9J3Jlc3BvbnNlLXR5cGUtcmVn aXN0cnknIC8+LiBSZXNwb25zZSB0eXBlIG5hbWVzIE1VU1QgY29uZm9ybSB0byB0aGUKICAgICAg ICAgIHJlc3BvbnNlLXR5cGUgQUJORi4KICAgICAgICA8L3Q+CiAgICAgICAgPGZpZ3VyZT4KICAg ICAgICAgIDxhcnR3b3JrPgogICAgICAgICAgICA8IVtDREFUQVsKICByZXNwb25zZS10eXBlICA9 IHJlc3BvbnNlLW5hbWUgKiggU1AgcmVzcG9uc2UtbmFtZSApCiAgcmVzcG9uc2UtbmFtZSAgPSAx KnJlc3BvbnNlLWNoYXIKICByZXNwb25zZS1jaGFyICA9ICJfIiAvIERJR0lUIC8gQUxQSEEKXV0+ CiAgICAgICAgICA8L2FydHdvcms+CiAgICAgICAgPC9maWd1cmU+CiAgICAgICAgPHQ+CiAgICAg ICAgICBJZiBhIHJlc3BvbnNlIHR5cGUgY29udGFpbnMgb25lIG9yIG1vcmUgc3BhY2UgY2hhcmFj dGVycyAoJXgyMCksIGl0IGlzIGNvbXBhcmVkIGFzIGEKICAgICAgICAgIHNwYWNlLWRlbGltaXRl ZCBsaXN0IG9mIHZhbHVlcyBpbiB3aGljaCB0aGUgb3JkZXIgb2YgdmFsdWVzIGRvZXMgbm90IG1h dHRlci4gT25seSBvbmUKICAgICAgICAgIG9yZGVyIG9mIHZhbHVlcyBjYW4gYmUgcmVnaXN0ZXJl ZCwgd2hpY2ggY292ZXJzIGFsbCBvdGhlciBhcnJhbmdlbWVudHMgb2YgdGhlIHNhbWUgc2V0IG9m CiAgICAgICAgICB2YWx1ZXMuCiAgICAgICAgPC90PgogICAgICAgIDx0PgogICAgICAgICAgRm9y IGV4YW1wbGUsIHRoZSByZXNwb25zZSB0eXBlIDxzcGFueCBzdHlsZT0ndmVyYic+dG9rZW4gY29k ZTwvc3Bhbng+IGlzIGxlZnQgdW5kZWZpbmVkCiAgICAgICAgICBieSB0aGlzIHNwZWNpZmljYXRp b24uIEhvd2V2ZXIsIGFuIGV4dGVuc2lvbiBjYW4gZGVmaW5lIGFuZCByZWdpc3RlciB0aGUKICAg ICAgICAgIDxzcGFueCBzdHlsZT0ndmVyYic+dG9rZW4gY29kZTwvc3Bhbng+IHJlc3BvbnNlIHR5 cGUuIE9uY2UgcmVnaXN0ZXJlZCwgdGhlIHNhbWUKICAgICAgICAgIGNvbWJpbmF0aW9uIGNhbm5v dCBiZSByZWdpc3RlcmVkIGFzIDxzcGFueCBzdHlsZT0ndmVyYic+Y29kZSB0b2tlbjwvc3Bhbng+ LCBidXQgYm90aAogICAgICAgICAgdmFsdWVzIGNhbiBiZSB1c2VkIHRvIGRlbm90ZSB0aGUgc2Ft ZSByZXNwb25zZSB0eXBlLgogICAgICAgIDwvdD4KICAgICAgPC9zZWN0aW9uPgoKICAgICAgPHNl Y3Rpb24gdGl0bGU9J0RlZmluaW5nIEFkZGl0aW9uYWwgRXJyb3IgQ29kZXMnIGFuY2hvcj0nbmV3 LWVycm9ycyc+CiAgICAgICAgPHQ+CiAgICAgICAgICBJbiBjYXNlcyB3aGVyZSBwcm90b2NvbCBl eHRlbnNpb25zIChpLmUuIGFjY2VzcyB0b2tlbiB0eXBlcywgZXh0ZW5zaW9uIHBhcmFtZXRlcnMs IG9yCiAgICAgICAgICBleHRlbnNpb24gZ3JhbnQgdHlwZXMpIHJlcXVpcmUgYWRkaXRpb25hbCBl cnJvciBjb2RlcyB0byBiZSB1c2VkIHdpdGggdGhlIGF1dGhvcml6YXRpb24KICAgICAgICAgIGNv ZGUgZ3JhbnQgZXJyb3IgcmVzcG9uc2UgKDx4cmVmIHRhcmdldD0nY29kZS1hdXRoei1lcnJvcicg Lz4pLCB0aGUgaW1wbGljaXQgZ3JhbnQgZXJyb3IKICAgICAgICAgIHJlc3BvbnNlICg8eHJlZiB0 YXJnZXQ9J2ltcGxpY2l0LWF1dGh6LWVycm9yJyAvPiksIHRoZSB0b2tlbiBlcnJvciByZXNwb25z ZQogICAgICAgICAgKDx4cmVmIHRhcmdldD0ndG9rZW4tZXJyb3JzJyAvPiksCgkgIG9yIHRoZSBy ZXNvdXJjZSBhY2Nlc3MgZXJyb3IgcmVzcG9uc2UgKDx4cmVmIHRhcmdldD0ncmVzb3VyY2UtZXJy b3JzJyAvPiksCgkgIHN1Y2ggZXJyb3IgY29kZXMgTUFZIGJlIGRlZmluZWQuCiAgICAgICAgPC90 PgogICAgICAgIDx0PgogICAgICAgICAgRXh0ZW5zaW9uIGVycm9yIGNvZGVzIE1VU1QgYmUgcmVn aXN0ZXJlZCAoZm9sbG93aW5nIHRoZSBwcm9jZWR1cmVzIGluCiAgICAgICAgICA8eHJlZiB0YXJn ZXQ9J2Vycm9yLXJlZ2lzdHJ5JyAvPikgaWYgdGhlIGV4dGVuc2lvbiB0aGV5IGFyZSB1c2VkIGlu IGNvbmp1bmN0aW9uIHdpdGggaXMKICAgICAgICAgIGEgcmVnaXN0ZXJlZCBhY2Nlc3MgdG9rZW4g dHlwZSwgYSByZWdpc3RlcmVkIGVuZHBvaW50IHBhcmFtZXRlciwgb3IgYW4gZXh0ZW5zaW9uIGdy YW50CiAgICAgICAgICB0eXBlLiBFcnJvciBjb2RlcyB1c2VkIHdpdGggdW5yZWdpc3RlcmVkIGV4 dGVuc2lvbnMgTUFZIGJlIHJlZ2lzdGVyZWQuCiAgICAgICAgPC90PgogICAgICAgIDx0PgogICAg ICAgICAgRXJyb3IgY29kZXMgTVVTVCBjb25mb3JtIHRvIHRoZSBlcnJvciBBQk5GLCBhbmQgU0hP VUxEIGJlIHByZWZpeGVkIGJ5IGFuIGlkZW50aWZ5aW5nCiAgICAgICAgICBuYW1lIHdoZW4gcG9z c2libGUuIEZvciBleGFtcGxlLCBhbiBlcnJvciBpZGVudGlmeWluZyBhbiBpbnZhbGlkIHZhbHVl IHNldCB0byB0aGUKICAgICAgICAgIGV4dGVuc2lvbiBwYXJhbWV0ZXIgPHNwYW54IHN0eWxlPSd2 ZXJiJz5leGFtcGxlPC9zcGFueD4gU0hPVUxEIGJlIG5hbWVkCiAgICAgICAgICA8c3Bhbnggc3R5 bGU9J3ZlcmInPmV4YW1wbGVfaW52YWxpZDwvc3Bhbng+LgogICAgICAgIDwvdD4KICAgICAgICA8 ZmlndXJlPgogICAgICAgICAgPGFydHdvcms+CiAgICAgICAgICAgIDwhW0NEQVRBWwogIGVycm9y ICAgICAgPSAxKmVycm9yLWNoYXIKICBlcnJvci1jaGFyID0gJXgyMC0yMSAvICV4MjMtNUIgLyAl eDVELTdFCl1dPgogICAgICAgICAgPC9hcnR3b3JrPgogICAgICAgIDwvZmlndXJlPgogICAgICA8 L3NlY3Rpb24+CgogICAgPC9zZWN0aW9uPgoKICAgIDxzZWN0aW9uIHRpdGxlPSdOYXRpdmUgQXBw bGljYXRpb25zJz4KICAgICAgPHQ+CiAgICAgICAgTmF0aXZlIGFwcGxpY2F0aW9ucyBhcmUgY2xp ZW50cyBpbnN0YWxsZWQgYW5kIGV4ZWN1dGVkIG9uIHRoZSBkZXZpY2UgdXNlZCBieSB0aGUgcmVz b3VyY2UKICAgICAgICBvd25lciAoaS5lLiBkZXNrdG9wIGFwcGxpY2F0aW9uLCBuYXRpdmUgbW9i aWxlIGFwcGxpY2F0aW9uKS4gTmF0aXZlIGFwcGxpY2F0aW9ucyByZXF1aXJlCiAgICAgICAgc3Bl Y2lhbCBjb25zaWRlcmF0aW9uIHJlbGF0ZWQgdG8gc2VjdXJpdHksIHBsYXRmb3JtIGNhcGFiaWxp dGllcywgYW5kIG92ZXJhbGwgZW5kLXVzZXIKICAgICAgICBleHBlcmllbmNlLgogICAgICA8L3Q+ CiAgICAgIDx0PgogICAgICAgIFRoZSBhdXRob3JpemF0aW9uIGVuZHBvaW50IHJlcXVpcmVzIGlu dGVyYWN0aW9uIGJldHdlZW4gdGhlIGNsaWVudCBhbmQgdGhlIHJlc291cmNlCiAgICAgICAgb3du ZXIncyB1c2VyLWFnZW50LiBOYXRpdmUgYXBwbGljYXRpb25zIGNhbiBpbnZva2UgYW4gZXh0ZXJu YWwgdXNlci1hZ2VudCBvciBlbWJlZCBhCiAgICAgICAgdXNlci1hZ2VudCB3aXRoaW4gdGhlIGFw cGxpY2F0aW9uLiBGb3IgZXhhbXBsZToKICAgICAgPC90PgogICAgICA8dD4KICAgICAgICA8bGlz dCBzdHlsZT0nc3ltYm9scyc+CiAgICAgICAgICA8dD4KICAgICAgICAgICAgRXh0ZXJuYWwgdXNl ci1hZ2VudCAtIHRoZSBuYXRpdmUgYXBwbGljYXRpb24gY2FuIGNhcHR1cmUgdGhlIHJlc3BvbnNl IGZyb20gdGhlCiAgICAgICAgICAgIGF1dGhvcml6YXRpb24gc2VydmVyIHVzaW5nIGEgcmVkaXJl Y3Rpb24gVVJJIHdpdGggYSBzY2hlbWUgcmVnaXN0ZXJlZCB3aXRoIHRoZQogICAgICAgICAgICBv cGVyYXRpbmcgc3lzdGVtIHRvIGludm9rZSB0aGUgY2xpZW50IGFzIHRoZSBoYW5kbGVyLCBtYW51 YWwgY29weS1hbmQtcGFzdGUgb2YgdGhlCiAgICAgICAgICAgIGNyZWRlbnRpYWxzLCBydW5uaW5n IGEgbG9jYWwgd2ViIHNlcnZlciwgaW5zdGFsbGluZyBhIHVzZXItYWdlbnQgZXh0ZW5zaW9uLCBv ciBieQogICAgICAgICAgICBwcm92aWRpbmcgYSByZWRpcmVjdGlvbiBVUkkgaWRlbnRpZnlpbmcg YSBzZXJ2ZXItaG9zdGVkIHJlc291cmNlIHVuZGVyIHRoZSBjbGllbnQncwogICAgICAgICAgICBj b250cm9sLCB3aGljaCBpbiB0dXJuIG1ha2VzIHRoZSByZXNwb25zZSBhdmFpbGFibGUgdG8gdGhl IG5hdGl2ZSBhcHBsaWNhdGlvbi4KICAgICAgICAgIDwvdD4KICAgICAgICAgIDx0PgogICAgICAg ICAgICBFbWJlZGRlZCB1c2VyLWFnZW50IC0gdGhlIG5hdGl2ZSBhcHBsaWNhdGlvbiBvYnRhaW5z IHRoZSByZXNwb25zZSBieSBkaXJlY3RseQogICAgICAgICAgICBjb21tdW5pY2F0aW5nIHdpdGgg dGhlIGVtYmVkZGVkIHVzZXItYWdlbnQgYnkgbW9uaXRvcmluZyBzdGF0ZSBjaGFuZ2VzIGVtaXR0 ZWQgZHVyaW5nCiAgICAgICAgICAgIHRoZSByZXNvdXJjZSBsb2FkLCBvciBhY2Nlc3NpbmcgdGhl IHVzZXItYWdlbnQncyBjb29raWVzIHN0b3JhZ2UuCiAgICAgICAgICA8L3Q+CiAgICAgICAgPC9s aXN0PgogICAgICA8L3Q+CiAgICAgIDx0PgogICAgICAgIFdoZW4gY2hvb3NpbmcgYmV0d2VlbiBh biBleHRlcm5hbCBvciBlbWJlZGRlZCB1c2VyLWFnZW50LCBkZXZlbG9wZXJzIHNob3VsZCBjb25z aWRlcjoKICAgICAgPC90PgogICAgICA8dD4KICAgICAgICA8bGlzdCBzdHlsZT0nc3ltYm9scyc+ CiAgICAgICAgICA8dD4KICAgICAgICAgICAgQW4gRXh0ZXJuYWwgdXNlci1hZ2VudCBtYXkgaW1w cm92ZSBjb21wbGV0aW9uIHJhdGUgYXMgdGhlIHJlc291cmNlIG93bmVyIG1heSBhbHJlYWR5IGhh dmUKICAgICAgICAgICAgYW4gYWN0aXZlIHNlc3Npb24gd2l0aCB0aGUgYXV0aG9yaXphdGlvbiBz ZXJ2ZXIgcmVtb3ZpbmcgdGhlIG5lZWQgdG8gcmUtYXV0aGVudGljYXRlLiBJdAogICAgICAgICAg ICBwcm92aWRlcyBhIGZhbWlsaWFyIGVuZC11c2VyIGV4cGVyaWVuY2UgYW5kIGZ1bmN0aW9uYWxp dHkuIFRoZSByZXNvdXJjZSBvd25lciBtYXkgYWxzbwogICAgICAgICAgICByZWx5IG9uIHVzZXIt YWdlbnQgZmVhdHVyZXMgb3IgZXh0ZW5zaW9ucyB0byBhc3Npc3Qgd2l0aCBhdXRoZW50aWNhdGlv biAoZS5nLiBwYXNzd29yZAogICAgICAgICAgICBtYW5hZ2VyLCAyLWZhY3RvciBkZXZpY2UgcmVh ZGVyKS4KICAgICAgICAgIDwvdD4KICAgICAgICAgIDx0PgogICAgICAgICAgICBBbiBlbWJlZGRl ZCB1c2VyLWFnZW50IG1heSBvZmZlciBpbXByb3ZlZCB1c2FiaWxpdHksIGFzIGl0IHJlbW92ZXMg dGhlIG5lZWQgdG8gc3dpdGNoCiAgICAgICAgICAgIGNvbnRleHQgYW5kIG9wZW4gbmV3IHdpbmRv d3MuCiAgICAgICAgICA8L3Q+CiAgICAgICAgICA8dD4KICAgICAgICAgICAgQW4gZW1iZWRkZWQg dXNlci1hZ2VudCBwb3NlcyBhIHNlY3VyaXR5IGNoYWxsZW5nZSBiZWNhdXNlIHJlc291cmNlIG93 bmVycyBhcmUKICAgICAgICAgICAgYXV0aGVudGljYXRpbmcgaW4gYW4gdW5pZGVudGlmaWVkIHdp bmRvdyB3aXRob3V0IGFjY2VzcyB0byB0aGUgdmlzdWFsIHByb3RlY3Rpb25zIGZvdW5kCiAgICAg ICAgICAgIGluIG1vc3QgZXh0ZXJuYWwgdXNlci1hZ2VudHMuIEFuIGVtYmVkZGVkIHVzZXItYWdl bnQgZWR1Y2F0ZXMgZW5kLXVzZXJzIHRvIHRydXN0CiAgICAgICAgICAgIHVuaWRlbnRpZmllZCBy ZXF1ZXN0cyBmb3IgYXV0aGVudGljYXRpb24gKG1ha2luZyBwaGlzaGluZyBhdHRhY2tzIGVhc2ll ciB0byBleGVjdXRlKS4KICAgICAgICAgIDwvdD4KICAgICAgICA8L2xpc3Q+CiAgICAgIDwvdD4K ICAgICAgPHQ+CiAgICAgICAgV2hlbiBjaG9vc2luZyBiZXR3ZWVuIHRoZSBpbXBsaWNpdCBncmFu dCB0eXBlIGFuZCB0aGUgYXV0aG9yaXphdGlvbiBjb2RlIGdyYW50IHR5cGUsIHRoZQogICAgICAg IGZvbGxvd2luZyBzaG91bGQgYmUgY29uc2lkZXJlZDoKICAgICAgPC90PgogICAgICA8dD4KICAg ICAgICA8bGlzdCBzdHlsZT0nc3ltYm9scyc+CiAgICAgICAgICA8dD4KICAgICAgICAgICAgTmF0 aXZlIGFwcGxpY2F0aW9ucyB0aGF0IHVzZSB0aGUgYXV0aG9yaXphdGlvbiBjb2RlIGdyYW50IHR5 cGUgU0hPVUxEIGRvIHNvIHdpdGhvdXQKICAgICAgICAgICAgdXNpbmcgY2xpZW50IGNyZWRlbnRp YWxzLCBkdWUgdG8gdGhlIG5hdGl2ZSBhcHBsaWNhdGlvbidzIGluYWJpbGl0eSB0byBrZWVwIGNs aWVudAogICAgICAgICAgICBjcmVkZW50aWFscyBjb25maWRlbnRpYWwuCiAgICAgICAgICA8L3Q+ CiAgICAgICAgICA8dD4KICAgICAgICAgICAgV2hlbiB1c2luZyB0aGUgaW1wbGljaXQgZ3JhbnQg dHlwZSBmbG93IGEgcmVmcmVzaCB0b2tlbiBpcyBub3QgcmV0dXJuZWQgd2hpY2ggcmVxdWlyZXMK ICAgICAgICAgICAgcmVwZWF0aW5nIHRoZSBhdXRob3JpemF0aW9uIHByb2Nlc3Mgb25jZSB0aGUg YWNjZXNzIHRva2VuIGV4cGlyZXMuCiAgICAgICAgICA8L3Q+CiAgICAgICAgPC9saXN0PgogICAg ICA8L3Q+CiAgICA8L3NlY3Rpb24+CgogICAgPHNlY3Rpb24gdGl0bGU9J1NlY3VyaXR5IENvbnNp ZGVyYXRpb25zJz4KICAgICAgPHQ+CiAgICAgICAgQXMgYSBmbGV4aWJsZSBhbmQgZXh0ZW5zaWJs ZSBmcmFtZXdvcmssIE9BdXRoJ3Mgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgZGVwZW5kIG9uIG1h bnkKICAgICAgICBmYWN0b3JzLiBUaGUgZm9sbG93aW5nIHNlY3Rpb25zIHByb3ZpZGUgaW1wbGVt ZW50ZXJzIHdpdGggc2VjdXJpdHkgZ3VpZGVsaW5lcyBmb2N1c2VkIG9uCiAgICAgICAgdGhlIHRo cmVlIGNsaWVudCBwcm9maWxlcyBkZXNjcmliZWQgaW4gPHhyZWYgdGFyZ2V0PSdjbGllbnQtdHlw ZXMnIC8+OiB3ZWIgYXBwbGljYXRpb24sCiAgICAgICAgdXNlci1hZ2VudC1iYXNlZCBhcHBsaWNh dGlvbiwgYW5kIG5hdGl2ZSBhcHBsaWNhdGlvbi4KICAgICAgPC90PgogICAgICA8dD4KICAgICAg ICBBIGNvbXByZWhlbnNpdmUgT0F1dGggc2VjdXJpdHkgbW9kZWwgYW5kIGFuYWx5c2lzLCBhcyB3 ZWxsIGFzIGJhY2tncm91bmQgZm9yIHRoZSBwcm90b2NvbAogICAgICAgIGRlc2lnbiwgaXMgcHJv dmlkZWQgYnkgPHhyZWYgdGFyZ2V0PSdJLUQuaWV0Zi1vYXV0aC12Mi10aHJlYXRtb2RlbCcgLz4u CiAgICAgIDwvdD4KCiAgICAgIDxzZWN0aW9uIHRpdGxlPSdDbGllbnQgQXV0aGVudGljYXRpb24n PgogICAgICAgIDx0PgogICAgICAgICAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGVzdGFibGlz aGVzIGNsaWVudCBjcmVkZW50aWFscyB3aXRoIHdlYiBhcHBsaWNhdGlvbiBjbGllbnRzIGZvcgog ICAgICAgICAgdGhlIHB1cnBvc2Ugb2YgY2xpZW50IGF1dGhlbnRpY2F0aW9uLiBUaGUgYXV0aG9y aXphdGlvbiBzZXJ2ZXIgaXMgZW5jb3VyYWdlZCB0byBjb25zaWRlcgogICAgICAgICAgc3Ryb25n ZXIgY2xpZW50IGF1dGhlbnRpY2F0aW9uIG1lYW5zIHRoYW4gYSBjbGllbnQgcGFzc3dvcmQuIFdl YiBhcHBsaWNhdGlvbiBjbGllbnRzIE1VU1QKICAgICAgICAgIGVuc3VyZSBjb25maWRlbnRpYWxp dHkgb2YgY2xpZW50IHBhc3N3b3JkcyBhbmQgb3RoZXIgY2xpZW50IGNyZWRlbnRpYWxzLgogICAg ICAgIDwvdD4KICAgICAgICA8dD4KICAgICAgICAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBN VVNUIE5PVCBpc3N1ZSBjbGllbnQgcGFzc3dvcmRzIG9yIG90aGVyIGNsaWVudCBjcmVkZW50aWFs cyB0bwogICAgICAgICAgbmF0aXZlIGFwcGxpY2F0aW9uIG9yIHVzZXItYWdlbnQtYmFzZWQgYXBw bGljYXRpb24gY2xpZW50cyBmb3IgdGhlIHB1cnBvc2Ugb2YgY2xpZW50CiAgICAgICAgICBhdXRo ZW50aWNhdGlvbi4gVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIE1BWSBpc3N1ZSBhIGNsaWVudCBw YXNzd29yZCBvciBvdGhlciBjcmVkZW50aWFscwogICAgICAgICAgZm9yIGEgc3BlY2lmaWMgaW5z dGFsbGF0aW9uIG9mIGEgbmF0aXZlIGFwcGxpY2F0aW9uIGNsaWVudCBvbiBhIHNwZWNpZmljIGRl dmljZS4KICAgICAgICA8L3Q+CiAgICAgICAgPHQ+CiAgICAgICAgICBXaGVuIGNsaWVudCBhdXRo ZW50aWNhdGlvbiBpcyBub3QgcG9zc2libGUsIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBTSE9V TEQgZW1wbG95IG90aGVyCiAgICAgICAgICBtZWFucyB0byB2YWxpZGF0ZSB0aGUgY2xpZW50J3Mg aWRlbnRpdHkuIEZvciBleGFtcGxlLCBieSByZXF1aXJpbmcgdGhlIHJlZ2lzdHJhdGlvbiBvZgog ICAgICAgICAgdGhlIGNsaWVudCByZWRpcmVjdGlvbiBVUkkgb3IgZW5saXN0aW5nIHRoZSByZXNv dXJjZSBvd25lciB0byBjb25maXJtIGlkZW50aXR5LiBBIHZhbGlkCiAgICAgICAgICByZWRpcmVj dGlvbiBVUkkgaXMgbm90IHN1ZmZpY2llbnQgdG8gdmVyaWZ5IHRoZSBjbGllbnQncyBpZGVudGl0 eSB3aGVuIGFza2luZyBmb3IKICAgICAgICAgIHJlc291cmNlIG93bmVyIGF1dGhvcml6YXRpb24s IGJ1dCBjYW4gYmUgdXNlZCB0byBwcmV2ZW50IGRlbGl2ZXJpbmcgY3JlZGVudGlhbHMgdG8gYQog ICAgICAgICAgY291bnRlcmZlaXQgY2xpZW50IGFmdGVyIG9idGFpbmluZyByZXNvdXJjZSBvd25l ciBhdXRob3JpemF0aW9uLgogICAgICAgIDwvdD4KICAgICAgICA8dD4KICAgICAgICAgIFRoZSBh dXRob3JpemF0aW9uIHNlcnZlciBtdXN0IGNvbnNpZGVyIHRoZSBzZWN1cml0eSBpbXBsaWNhdGlv bnMgb2YgaW50ZXJhY3Rpbmcgd2l0aAogICAgICAgICAgdW5hdXRoZW50aWNhdGVkIGNsaWVudHMg YW5kIHRha2UgbWVhc3VyZXMgdG8gbGltaXQgdGhlIHBvdGVudGlhbCBleHBvc3VyZSBvZiBvdGhl cgogICAgICAgICAgY3JlZGVudGlhbHMgKGUuZy4gcmVmcmVzaCB0b2tlbnMpIGlzc3VlZCB0byBz dWNoIGNsaWVudHMuCiAgICAgICAgPC90PgogICAgICA8L3NlY3Rpb24+CgogICAgICA8c2VjdGlv biB0aXRsZT0nQ2xpZW50IEltcGVyc29uYXRpb24nPgogICAgICAgIDx0PgogICAgICAgICAgQSBt YWxpY2lvdXMgY2xpZW50IGNhbiBpbXBlcnNvbmF0ZSBhbm90aGVyIGNsaWVudCBhbmQgb2J0YWlu IGFjY2VzcyB0byBwcm90ZWN0ZWQKICAgICAgICAgIHJlc291cmNlcywgaWYgdGhlIGltcGVyc29u YXRlZCBjbGllbnQgZmFpbHMgdG8sIG9yIGlzIHVuYWJsZSB0bywga2VlcCBpdHMgY2xpZW50CiAg ICAgICAgICBjcmVkZW50aWFscyBjb25maWRlbnRpYWwuCiAgICAgICAgPC90PgogICAgICAgIDx0 PgogICAgICAgICAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIE1VU1QgYXV0aGVudGljYXRlIHRo ZSBjbGllbnQgd2hlbmV2ZXIgcG9zc2libGUuIElmIHRoZQogICAgICAgICAgYXV0aG9yaXphdGlv biBzZXJ2ZXIgY2Fubm90IGF1dGhlbnRpY2F0ZSB0aGUgY2xpZW50IGR1ZSB0byB0aGUgY2xpZW50 J3MgbmF0dXJlLCB0aGUKICAgICAgICAgIGF1dGhvcml6YXRpb24gc2VydmVyIE1VU1QgcmVxdWly ZSB0aGUgcmVnaXN0cmF0aW9uIG9mIGFueSByZWRpcmVjdGlvbiBVUkkgdXNlZCBmb3IKICAgICAg ICAgIHJlY2VpdmluZyBhdXRob3JpemF0aW9uIHJlc3BvbnNlcywgYW5kIFNIT1VMRCB1dGlsaXpl IG90aGVyIG1lYW5zIHRvIHByb3RlY3QgcmVzb3VyY2UKICAgICAgICAgIG93bmVycyBmcm9tIHN1 Y2ggcG90ZW50aWFsbHkgbWFsaWNpb3VzIGNsaWVudHMuIEZvciBleGFtcGxlLCB0aGUgYXV0aG9y aXphdGlvbiBzZXJ2ZXIKICAgICAgICAgIGNhbiBlbmdhZ2UgdGhlIHJlc291cmNlIG93bmVyIHRv IGFzc2lzdCBpbiBpZGVudGlmeWluZyB0aGUgY2xpZW50IGFuZCBpdHMgb3JpZ2luLgogICAgICAg IDwvdD4KICAgICAgICA8dD4KICAgICAgICAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBTSE9V TEQgZW5mb3JjZSBleHBsaWNpdCByZXNvdXJjZSBvd25lciBhdXRoZW50aWNhdGlvbiBhbmQKICAg ICAgICAgIHByb3ZpZGUgdGhlIHJlc291cmNlIG93bmVyIHdpdGggaW5mb3JtYXRpb24gYWJvdXQg dGhlIGNsaWVudCBhbmQgdGhlIHJlcXVlc3RlZAogICAgICAgICAgYXV0aG9yaXphdGlvbiBzY29w ZSBhbmQgbGlmZXRpbWUuIEl0IGlzIHVwIHRvIHRoZSByZXNvdXJjZSBvd25lciB0byByZXZpZXcg dGhlCiAgICAgICAgICBpbmZvcm1hdGlvbiBpbiB0aGUgY29udGV4dCBvZiB0aGUgY3VycmVudCBj bGllbnQsIGFuZCBhdXRob3JpemUgb3IgZGVueSB0aGUgcmVxdWVzdC4KICAgICAgICA8L3Q+CiAg ICAgICAgPHQ+CiAgICAgICAgICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgU0hPVUxEIE5PVCBw cm9jZXNzIHJlcGVhdGVkIGF1dGhvcml6YXRpb24gcmVxdWVzdHMKICAgICAgICAgIGF1dG9tYXRp Y2FsbHkgKHdpdGhvdXQgYWN0aXZlIHJlc291cmNlIG93bmVyIGludGVyYWN0aW9uKSB3aXRob3V0 IGF1dGhlbnRpY2F0aW5nIHRoZQogICAgICAgICAgY2xpZW50IG9yIHJlbHlpbmcgb24gb3RoZXIg bWVhc3VyZXMgdG8gZW5zdXJlIHRoZSByZXBlYXRlZCByZXF1ZXN0IGNvbWVzIGZyb20gdGhlCiAg ICAgICAgICBvcmlnaW5hbCBjbGllbnQgYW5kIG5vdCBhbiBpbXBlcnNvbmF0b3IuCiAgICAgICAg PC90PgogICAgICA8L3NlY3Rpb24+CgogICAgICA8c2VjdGlvbiB0aXRsZT0nQWNjZXNzIFRva2Vu cyc+CiAgICAgICAgPHQ+CiAgICAgICAgICBBY2Nlc3MgdG9rZW4gY3JlZGVudGlhbHMgKGFzIHdl bGwgYXMgYW55IGNvbmZpZGVudGlhbCBhY2Nlc3MgdG9rZW4gYXR0cmlidXRlcykgTVVTVCBiZQog ICAgICAgICAga2VwdCBjb25maWRlbnRpYWwgaW4gdHJhbnNpdCBhbmQgc3RvcmFnZSwgYW5kIG9u bHkgc2hhcmVkIGFtb25nIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciwKICAgICAgICAgIHRoZSBy ZXNvdXJjZSBzZXJ2ZXJzIHRoZSBhY2Nlc3MgdG9rZW4gaXMgdmFsaWQgZm9yLCBhbmQgdGhlIGNs aWVudCB0byB3aG9tIHRoZSBhY2Nlc3MKICAgICAgICAgIHRva2VuIGlzIGlzc3VlZC4gQWNjZXNz IHRva2VuIGNyZWRlbnRpYWxzIE1VU1Qgb25seSBiZSB0cmFuc21pdHRlZCB1c2luZyBUTFMgYXMg ZGVzY3JpYmVkCiAgICAgICAgICBpbiA8eHJlZiB0YXJnZXQ9J3RscycgLz4gd2l0aCBzZXJ2ZXIg YXV0aGVudGljYXRpb24gYXMgZGVmaW5lZCBieQogICAgICAgICAgPHhyZWYgdGFyZ2V0PSdSRkMy ODE4JyAvPi4KICAgICAgICA8L3Q+CiAgICAgICAgPHQ+CiAgICAgICAgICBXaGVuIHVzaW5nIHRo ZSBpbXBsaWNpdCBncmFudCB0eXBlLCB0aGUgYWNjZXNzIHRva2VuIGlzIHRyYW5zbWl0dGVkIGlu IHRoZSBVUkkgZnJhZ21lbnQsCiAgICAgICAgICB3aGljaCBjYW4gZXhwb3NlIGl0IHRvIHVuYXV0 aG9yaXplZCBwYXJ0aWVzLgogICAgICAgIDwvdD4KICAgICAgICA8dD4KICAgICAgICAgIFRoZSBh dXRob3JpemF0aW9uIHNlcnZlciBNVVNUIGVuc3VyZSB0aGF0IGFjY2VzcyB0b2tlbnMgY2Fubm90 IGJlIGdlbmVyYXRlZCwgbW9kaWZpZWQsIG9yCiAgICAgICAgICBndWVzc2VkIHRvIHByb2R1Y2Ug dmFsaWQgYWNjZXNzIHRva2VucyBieSB1bmF1dGhvcml6ZWQgcGFydGllcy4KICAgICAgICA8L3Q+ CiAgICAgICAgPHQ+CiAgICAgICAgICBUaGUgY2xpZW50IFNIT1VMRCByZXF1ZXN0IGFjY2VzcyB0 b2tlbnMgd2l0aCB0aGUgbWluaW1hbCBzY29wZSBuZWNlc3NhcnkuIFRoZQogICAgICAgICAgYXV0 aG9yaXphdGlvbiBzZXJ2ZXIgU0hPVUxEIHRha2UgdGhlIGNsaWVudCBpZGVudGl0eSBpbnRvIGFj Y291bnQgd2hlbiBjaG9vc2luZyBob3cKICAgICAgICAgIHRvIGhvbm9yIHRoZSByZXF1ZXN0ZWQg c2NvcGUsIGFuZCBNQVkgaXNzdWUgYW4gYWNjZXNzIHRva2VuIHdpdGggYSBsZXNzIHJpZ2h0cyB0 aGFuCiAgICAgICAgICByZXF1ZXN0ZWQuCiAgICAgICAgPC90PgogICAgICAgIDx0PgogICAgICAg ICAgVGhpcyBzcGVjaWZpY2F0aW9uIGRvZXMgbm90IHByb3ZpZGUgYW55IG1ldGhvZHMgZm9yIHRo ZSByZXNvdXJjZSBzZXJ2ZXIgdG8gZW5zdXJlIHRoYXQgYW4KICAgICAgICAgIGFjY2VzcyB0b2tl biBwcmVzZW50ZWQgdG8gaXQgYnkgYSBnaXZlbiBjbGllbnQgd2FzIGlzc3VlZCB0byB0aGF0IGNs aWVudCBieSB0aGUKICAgICAgICAgIGF1dGhvcml6YXRpb24gc2VydmVyLgogICAgICAgIDwvdD4K ICAgICAgPC9zZWN0aW9uPgoKICAgICAgPHNlY3Rpb24gdGl0bGU9J1JlZnJlc2ggVG9rZW5zJz4K ICAgICAgICA8dD4KICAgICAgICAgIEF1dGhvcml6YXRpb24gc2VydmVycyBNQVkgaXNzdWUgcmVm cmVzaCB0b2tlbnMgdG8gd2ViIGFwcGxpY2F0aW9uIGNsaWVudHMgYW5kIG5hdGl2ZQogICAgICAg ICAgYXBwbGljYXRpb24gY2xpZW50cy4KICAgICAgICA8L3Q+CiAgICAgICAgPHQ+CiAgICAgICAg ICBSZWZyZXNoIHRva2VucyBNVVNUIGJlIGtlcHQgY29uZmlkZW50aWFsIGluIHRyYW5zaXQgYW5k IHN0b3JhZ2UsIGFuZCBzaGFyZWQgb25seSBhbW9uZwogICAgICAgICAgdGhlIGF1dGhvcml6YXRp b24gc2VydmVyIGFuZCB0aGUgY2xpZW50IHRvIHdob20gdGhlIHJlZnJlc2ggdG9rZW5zIHdlcmUg aXNzdWVkLiBUaGUKICAgICAgICAgIGF1dGhvcml6YXRpb24gc2VydmVyIE1VU1QgbWFpbnRhaW4g dGhlIGJpbmRpbmcgYmV0d2VlbiBhIHJlZnJlc2ggdG9rZW4gYW5kIHRoZSBjbGllbnQgdG8KICAg ICAgICAgIHdob20gaXQgd2FzIGlzc3VlZC4gUmVmcmVzaCB0b2tlbnMgTVVTVCBvbmx5IGJlIHRy YW5zbWl0dGVkIHVzaW5nIFRMUyBhcyBkZXNjcmliZWQgaW4KICAgICAgICAgIDx4cmVmIHRhcmdl dD0ndGxzJyAvPiB3aXRoIHNlcnZlciBhdXRoZW50aWNhdGlvbiBhcyBkZWZpbmVkIGJ5IDx4cmVm IHRhcmdldD0nUkZDMjgxOCcgLz4uCiAgICAgICAgPC90PgogICAgICAgIDx0PgogICAgICAgICAg VGhlIGF1dGhvcml6YXRpb24gc2VydmVyIE1VU1QgdmVyaWZ5IHRoZSBiaW5kaW5nIGJldHdlZW4g dGhlIHJlZnJlc2ggdG9rZW4gYW5kIGNsaWVudAogICAgICAgICAgaWRlbnRpdHkgd2hlbmV2ZXIg dGhlIGNsaWVudCBpZGVudGl0eSBjYW4gYmUgYXV0aGVudGljYXRlZC4gV2hlbiBjbGllbnQgYXV0 aGVudGljYXRpb24gaXMKICAgICAgICAgIG5vdCBwb3NzaWJsZSwgdGhlIGF1dGhvcml6YXRpb24g c2VydmVyIFNIT1VMRCBkZXBsb3kgb3RoZXIgbWVhbnMgdG8gZGV0ZWN0IHJlZnJlc2ggdG9rZW4K ICAgICAgICAgIGFidXNlLgogICAgICAgIDwvdD4KICAgICAgICA8dD4KICAgICAgICAgIEZvciBl eGFtcGxlLCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgY291bGQgZW1wbG95IHJlZnJlc2ggdG9r ZW4gcm90YXRpb24gaW4gd2hpY2ggYSBuZXcKICAgICAgICAgIHJlZnJlc2ggdG9rZW4gaXMgaXNz dWVkIHdpdGggZXZlcnkgYWNjZXNzIHRva2VuIHJlZnJlc2ggcmVzcG9uc2UuIFRoZSBwcmV2aW91 cyByZWZyZXNoCiAgICAgICAgICB0b2tlbiBpcyBpbnZhbGlkYXRlZCBidXQgcmV0YWluZWQgYnkg dGhlIGF1dGhvcml6YXRpb24gc2VydmVyLiBJZiBhIHJlZnJlc2ggdG9rZW4gaXMKICAgICAgICAg IGNvbXByb21pc2VkIGFuZCBzdWJzZXF1ZW50bHkgdXNlZCBieSBib3RoIHRoZSBhdHRhY2tlciBh bmQgdGhlIGxlZ2l0aW1hdGUgY2xpZW50LCBvbmUgb2YKICAgICAgICAgIHRoZW0gd2lsbCBwcmVz ZW50IGFuIGludmFsaWRhdGVkIHJlZnJlc2ggdG9rZW4gd2hpY2ggd2lsbCBpbmZvcm0gdGhlIGF1 dGhvcml6YXRpb24gc2VydmVyCiAgICAgICAgICBvZiB0aGUgYnJlYWNoLgogICAgICAgIDwvdD4K ICAgICAgICA8dD4KICAgICAgICAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBNVVNUIGVuc3Vy ZSB0aGF0IHJlZnJlc2ggdG9rZW5zIGNhbm5vdCBiZSBnZW5lcmF0ZWQsIG1vZGlmaWVkLAogICAg ICAgICAgb3IgZ3Vlc3NlZCB0byBwcm9kdWNlIHZhbGlkIHJlZnJlc2ggdG9rZW5zIGJ5IHVuYXV0 aG9yaXplZCBwYXJ0aWVzLgogICAgICAgIDwvdD4KICAgICAgPC9zZWN0aW9uPgoKICAgICAgPHNl Y3Rpb24gdGl0bGU9J0F1dGhvcml6YXRpb24gQ29kZXMnPgogICAgICAgIDx0PgogICAgICAgICAg VGhlIHRyYW5zbWlzc2lvbiBvZiBhdXRob3JpemF0aW9uIGNvZGVzIFNIT1VMRCBiZSBtYWRlIG92 ZXIgYSBzZWN1cmUgY2hhbm5lbCwgYW5kIHRoZQogICAgICAgICAgY2xpZW50IFNIT1VMRCByZXF1 aXJlIHRoZSB1c2Ugb2YgVExTIHdpdGggaXRzIHJlZGlyZWN0aW9uIFVSSSBpZiB0aGUgVVJJIGlk ZW50aWZpZXMgYQogICAgICAgICAgbmV0d29yayByZXNvdXJjZS4gU2luY2UgYXV0aG9yaXphdGlv biBjb2RlcyBhcmUgdHJhbnNtaXR0ZWQgdmlhIHVzZXItYWdlbnQgcmVkaXJlY3Rpb25zLAogICAg ICAgICAgdGhleSBjb3VsZCBwb3RlbnRpYWxseSBiZSBkaXNjbG9zZWQgdGhyb3VnaCB1c2VyLWFn ZW50IGhpc3RvcnkgYW5kIEhUVFAgcmVmZXJyZXIgaGVhZGVycy4KICAgICAgICA8L3Q+CiAgICAg ICAgPHQ+CiAgICAgICAgICBBdXRob3JpemF0aW9uIGNvZGVzIG9wZXJhdGUgYXMgcGxhaW50ZXh0 IGJlYXJlciBjcmVkZW50aWFscywgdXNlZCB0byB2ZXJpZnkgdGhhdCB0aGUKICAgICAgICAgIHJl c291cmNlIG93bmVyIHdobyBncmFudGVkIGF1dGhvcml6YXRpb24gYXQgdGhlIGF1dGhvcml6YXRp b24gc2VydmVyIGlzIHRoZSBzYW1lCiAgICAgICAgICByZXNvdXJjZSBvd25lciByZXR1cm5pbmcg dG8gdGhlIGNsaWVudCB0byBjb21wbGV0ZSB0aGUgcHJvY2Vzcy4gVGhlcmVmb3JlLCBpZiB0aGUg Y2xpZW50CiAgICAgICAgICByZWxpZXMgb24gdGhlIGF1dGhvcml6YXRpb24gY29kZSBmb3IgaXRz IG93biByZXNvdXJjZSBvd25lciBhdXRoZW50aWNhdGlvbiwgdGhlIGNsaWVudAogICAgICAgICAg cmVkaXJlY3Rpb24gZW5kcG9pbnQgTVVTVCByZXF1aXJlIHRoZSB1c2Ugb2YgVExTLgogICAgICAg IDwvdD4KICAgICAgICA8dD4KICAgICAgICAgIEF1dGhvcml6YXRpb24gY29kZXMgTVVTVCBiZSBz aG9ydCBsaXZlZCBhbmQgc2luZ2xlIHVzZS4gSWYgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyCiAg ICAgICAgICBvYnNlcnZlcyBtdWx0aXBsZSBhdHRlbXB0cyB0byBleGNoYW5nZSBhbiBhdXRob3Jp emF0aW9uIGNvZGUgZm9yIGFuIGFjY2VzcyB0b2tlbiwgdGhlCiAgICAgICAgICBhdXRob3JpemF0 aW9uIHNlcnZlciBTSE9VTEQgYXR0ZW1wdCB0byByZXZva2UgYWxsIGFjY2VzcyB0b2tlbnMgYWxy ZWFkeSBncmFudGVkIGJhc2VkIG9uCiAgICAgICAgICB0aGUgY29tcHJvbWlzZWQgYXV0aG9yaXph dGlvbiBjb2RlLgogICAgICAgIDwvdD4KICAgICAgICA8dD4KICAgICAgICAgIElmIHRoZSBjbGll bnQgY2FuIGJlIGF1dGhlbnRpY2F0ZWQsIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlcnMgTVVTVCBh dXRoZW50aWNhdGUgdGhlCiAgICAgICAgICBjbGllbnQgYW5kIGVuc3VyZSB0aGF0IHRoZSBhdXRo b3JpemF0aW9uIGNvZGUgd2FzIGlzc3VlZCB0byB0aGUgc2FtZSBjbGllbnQuCiAgICAgICAgPC90 PgogICAgICA8L3NlY3Rpb24+CgogICAgICA8c2VjdGlvbiB0aXRsZT0nQXV0aG9yaXphdGlvbiBD b2RlIFJlZGlyZWN0aW9uIFVSSSBNYW5pcHVsYXRpb24nPgogICAgICAgIDx0PgogICAgICAgICAg V2hlbiByZXF1ZXN0aW5nIGF1dGhvcml6YXRpb24gdXNpbmcgdGhlIGF1dGhvcml6YXRpb24gY29k ZSBncmFudCB0eXBlLCB0aGUgY2xpZW50IGNhbgogICAgICAgICAgc3BlY2lmeSBhIHJlZGlyZWN0 aW9uIFVSSSB2aWEgdGhlIDxzcGFueCBzdHlsZT0ndmVyYic+cmVkaXJlY3RfdXJpPC9zcGFueD4g cGFyYW1ldGVyLgogICAgICAgICAgSWYgYW4gYXR0YWNrZXIgY2FuIG1hbmlwdWxhdGUgdGhlIHZh bHVlIG9mIHRoZSByZWRpcmVjdGlvbiBVUkksIGl0IGNhbiBjYXVzZSB0aGUKICAgICAgICAgIGF1 dGhvcml6YXRpb24gc2VydmVyIHRvIHJlZGlyZWN0IHRoZSByZXNvdXJjZSBvd25lciB1c2VyLWFn ZW50IHRvIGEgVVJJIHVuZGVyIHRoZSBjb250cm9sCiAgICAgICAgICBvZiB0aGUgYXR0YWNrZXIg d2l0aCB0aGUgYXV0aG9yaXphdGlvbiBjb2RlLgogICAgICAgIDwvdD4KICAgICAgICA8dD4KICAg ICAgICAgIEFuIGF0dGFja2VyIGNhbiBjcmVhdGUgYW4gYWNjb3VudCBhdCBhIGxlZ2l0aW1hdGUg Y2xpZW50IGFuZCBpbml0aWF0ZSB0aGUgYXV0aG9yaXphdGlvbgogICAgICAgICAgZmxvdy4gV2hl biB0aGUgYXR0YWNrZXIncyB1c2VyLWFnZW50IGlzIHNlbnQgdG8gdGhlIGF1dGhvcml6YXRpb24g c2VydmVyIHRvIGdyYW50IGFjY2VzcywKICAgICAgICAgIHRoZSBhdHRhY2tlciBncmFicyB0aGUg YXV0aG9yaXphdGlvbiBVUkkgcHJvdmlkZWQgYnkgdGhlIGxlZ2l0aW1hdGUgY2xpZW50LCBhbmQg cmVwbGFjZXMKICAgICAgICAgIHRoZSBjbGllbnQncyByZWRpcmVjdGlvbiBVUkkgd2l0aCBhIFVS SSB1bmRlciB0aGUgY29udHJvbCBvZiB0aGUgYXR0YWNrZXIuIFRoZSBhdHRhY2tlcgogICAgICAg ICAgdGhlbiB0cmlja3MgdGhlIHZpY3RpbSBpbnRvIGZvbGxvd2luZyB0aGUgbWFuaXB1bGF0ZWQg bGluayB0byBhdXRob3JpemUgYWNjZXNzIHRvIHRoZQogICAgICAgICAgbGVnaXRpbWF0ZSBjbGll bnQuCiAgICAgICAgPC90PgogICAgICAgIDx0PgogICAgICAgICAgT25jZSBhdCB0aGUgYXV0aG9y aXphdGlvbiBzZXJ2ZXIsIHRoZSB2aWN0aW0gaXMgcHJvbXB0ZWQgd2l0aCBhIG5vcm1hbCwgdmFs aWQgcmVxdWVzdCBvbgogICAgICAgICAgYmVoYWxmIG9mIGEgbGVnaXRpbWF0ZSBhbmQgdHJ1c3Rl ZCBjbGllbnQsIGFuZCBhdXRob3JpemVzIHRoZSByZXF1ZXN0LiBUaGUgdmljdGltIGlzCiAgICAg ICAgICB0aGVuIHJlZGlyZWN0ZWQgdG8gYW4gZW5kcG9pbnQgdW5kZXIgdGhlIGNvbnRyb2wgb2Yg dGhlIGF0dGFja2VyIHdpdGggdGhlIGF1dGhvcml6YXRpb24KICAgICAgICAgIGNvZGUuIFRoZSBh dHRhY2tlciBjb21wbGV0ZXMgdGhlIGF1dGhvcml6YXRpb24gZmxvdyBieSBzZW5kaW5nIHRoZSBh dXRob3JpemF0aW9uIGNvZGUgdG8KICAgICAgICAgIHRoZSBjbGllbnQgdXNpbmcgdGhlIG9yaWdp bmFsIHJlZGlyZWN0aW9uIFVSSSBwcm92aWRlZCBieSB0aGUgY2xpZW50LiBUaGUgY2xpZW50CiAg ICAgICAgICBleGNoYW5nZXMgdGhlIGF1dGhvcml6YXRpb24gY29kZSB3aXRoIGFuIGFjY2VzcyB0 b2tlbiBhbmQgbGlua3MgaXQgdG8gdGhlIGF0dGFja2VyJ3MKICAgICAgICAgIGNsaWVudCBhY2Nv dW50IHdoaWNoIGNhbiBub3cgZ2FpbiBhY2Nlc3MgdG8gdGhlIHByb3RlY3RlZCByZXNvdXJjZXMg YXV0aG9yaXplZCBieSB0aGUKICAgICAgICAgIHZpY3RpbSAodmlhIHRoZSBjbGllbnQpLgogICAg ICAgIDwvdD4KICAgICAgICA8dD4KICAgICAgICAgIEluIG9yZGVyIHRvIHByZXZlbnQgc3VjaCBh biBhdHRhY2ssIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBNVVNUIGVuc3VyZSB0aGF0IHRoZQog ICAgICAgICAgcmVkaXJlY3Rpb24gVVJJIHVzZWQgdG8gb2J0YWluIHRoZSBhdXRob3JpemF0aW9u IGNvZGUgaXMgaWRlbnRpY2FsIHRvIHRoZSByZWRpcmVjdGlvbiBVUkkKICAgICAgICAgIHByb3Zp ZGVkIHdoZW4gZXhjaGFuZ2luZyB0aGUgYXV0aG9yaXphdGlvbiBjb2RlIGZvciBhbiBhY2Nlc3Mg dG9rZW4uIFRoZSBhdXRob3JpemF0aW9uCiAgICAgICAgICBzZXJ2ZXIgTVVTVCByZXF1aXJlIHB1 YmxpYyBjbGllbnRzIGFuZCBTSE9VTEQgcmVxdWlyZSBjb25maWRlbnRpYWwgY2xpZW50cyB0byBy ZWdpc3RlcgogICAgICAgICAgdGhlaXIgcmVkaXJlY3Rpb24gVVJJcy4gSWYgYSByZWRpcmVjdGlv biBVUkkgaXMgcHJvdmlkZWQgaW4gdGhlIHJlcXVlc3QsIHRoZQogICAgICAgICAgYXV0aG9yaXph dGlvbiBzZXJ2ZXIgTVVTVCB2YWxpZGF0ZSBpdCBhZ2FpbnN0IHRoZSByZWdpc3RlcmVkIHZhbHVl LgogICAgICAgIDwvdD4KICAgICAgPC9zZWN0aW9uPgoKICAgICAgPHNlY3Rpb24gdGl0bGU9J1Jl c291cmNlIE93bmVyIFBhc3N3b3JkIENyZWRlbnRpYWxzJz4KICAgICAgICA8dD4KICAgICAgICAg IFRoZSByZXNvdXJjZSBvd25lciBwYXNzd29yZCBjcmVkZW50aWFscyBncmFudCB0eXBlIGlzIG9m dGVuIHVzZWQgZm9yIGxlZ2FjeSBvciBtaWdyYXRpb24KICAgICAgICAgIHJlYXNvbnMuIEl0IHJl ZHVjZXMgdGhlIG92ZXJhbGwgcmlzayBvZiBzdG9yaW5nIHVzZXJuYW1lIGFuZCBwYXNzd29yZCBi eSB0aGUgY2xpZW50LCBidXQKICAgICAgICAgIGRvZXMgbm90IGVsaW1pbmF0ZSB0aGUgbmVlZCB0 byBleHBvc2UgaGlnaGx5IHByaXZpbGVnZWQgY3JlZGVudGlhbHMgdG8gdGhlIGNsaWVudC4KICAg ICAgICA8L3Q+CiAgICAgICAgPHQ+CiAgICAgICAgICBUaGlzIGdyYW50IHR5cGUgY2FycmllcyBh IGhpZ2hlciByaXNrIHRoYW4gb3RoZXIgZ3JhbnQgdHlwZXMgYmVjYXVzZSBpdCBtYWludGFpbnMg dGhlCiAgICAgICAgICBwYXNzd29yZCBhbnRpLXBhdHRlcm4gdGhpcyBwcm90b2NvbCBzZWVrcyB0 byBhdm9pZC4gVGhlIGNsaWVudCBjb3VsZCBhYnVzZSB0aGUgcGFzc3dvcmQKICAgICAgICAgIG9y IHRoZSBwYXNzd29yZCBjb3VsZCB1bmludGVudGlvbmFsbHkgYmUgZGlzY2xvc2VkIHRvIGFuIGF0 dGFja2VyIChlLmcuIHZpYSBsb2cgZmlsZXMgb3IKICAgICAgICAgIG90aGVyIHJlY29yZHMga2Vw dCBieSB0aGUgY2xpZW50KS4KICAgICAgICA8L3Q+CiAgICAgICAgPHQ+CiAgICAgICAgICBBZGRp dGlvbmFsbHksIGJlY2F1c2UgdGhlIHJlc291cmNlIG93bmVyIGRvZXMgbm90IGhhdmUgY29udHJv bCBvdmVyIHRoZSBhdXRob3JpemF0aW9uCiAgICAgICAgICBwcm9jZXNzICh0aGUgcmVzb3VyY2Ug b3duZXIgaW52b2x2ZW1lbnQgZW5kcyB3aGVuIGl0IGhhbmRzIG92ZXIgaXRzIGNyZWRlbnRpYWxz IHRvIHRoZQogICAgICAgICAgY2xpZW50KSwgdGhlIGNsaWVudCBjYW4gb2J0YWluIGFjY2VzcyB0 b2tlbnMgd2l0aCBhIGJyb2FkZXIgc2NvcGUgdGhhbiBkZXNpcmVkIGJ5IHRoZQogICAgICAgICAg cmVzb3VyY2Ugb3duZXIuIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBzaG91bGQgY29uc2lkZXIg dGhlIHNjb3BlIGFuZCBsaWZldGltZSBvZgogICAgICAgICAgYWNjZXNzIHRva2VucyBpc3N1ZWQg dmlhIHRoaXMgZ3JhbnQgdHlwZS4KICAgICAgICA8L3Q+CiAgICAgICAgPHQ+CiAgICAgICAgICBU aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYW5kIGNsaWVudCBTSE9VTEQgbWluaW1pemUgdXNlIG9m IHRoaXMgZ3JhbnQgdHlwZSBhbmQgdXRpbGl6ZQogICAgICAgICAgb3RoZXIgZ3JhbnQgdHlwZXMg d2hlbmV2ZXIgcG9zc2libGUuCiAgICAgICAgPC90PgogICAgICA8L3NlY3Rpb24+CgogICAgICA8 c2VjdGlvbiB0aXRsZT0nUmVxdWVzdCBDb25maWRlbnRpYWxpdHknPgogICAgICAgIDx0PgogICAg ICAgICAgQWNjZXNzIHRva2VucywgcmVmcmVzaCB0b2tlbnMsIHJlc291cmNlIG93bmVyIHBhc3N3 b3JkcywgYW5kIGNsaWVudCBjcmVkZW50aWFscyBNVVNUIE5PVAogICAgICAgICAgYmUgdHJhbnNt aXR0ZWQgaW4gdGhlIGNsZWFyLiBBdXRob3JpemF0aW9uIGNvZGVzIFNIT1VMRCBOT1QgYmUgdHJh bnNtaXR0ZWQgaW4gdGhlIGNsZWFyLgogICAgICAgIDwvdD4KICAgICAgICA8dD4KICAgICAgICAg IFRoZSA8c3Bhbnggc3R5bGU9J3ZlcmInPnN0YXRlPC9zcGFueD4gYW5kIDxzcGFueCBzdHlsZT0n dmVyYic+c2NvcGU8L3NwYW54PiBwYXJhbWV0ZXJzCiAgICAgICAgICBTSE9VTEQgTk9UIGluY2x1 ZGUgc2Vuc2l0aXZlIGNsaWVudCBvciByZXNvdXJjZSBvd25lciBpbmZvcm1hdGlvbiBpbiBwbGFp biB0ZXh0IGFzIHRoZXkKICAgICAgICAgIGNhbiBiZSB0cmFuc21pdHRlZCBvdmVyIGluc2VjdXJl IGNoYW5uZWxzIG9yIHN0b3JlZCBpbnNlY3VyZWx5LgogICAgICAgIDwvdD4KICAgICAgPC9zZWN0 aW9uPgoKICAgICAgPHNlY3Rpb24gdGl0bGU9J0VuZHBvaW50cyBBdXRoZW50aWNpdHknPgogICAg ICAgIDx0PgogICAgICAgICAgSW4gb3JkZXIgdG8gcHJldmVudCBtYW4taW4tdGhlLW1pZGRsZSBh dHRhY2tzLCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVTVCByZXF1aXJlIHRoZQogICAgICAg ICAgdXNlIG9mIFRMUyB3aXRoIHNlcnZlciBhdXRoZW50aWNhdGlvbiBhcyBkZWZpbmVkIGJ5IDx4 cmVmIHRhcmdldD0nUkZDMjgxOCcgLz4gZm9yCiAgICAgICAgICBhbnkgcmVxdWVzdCBzZW50IHRv IHRoZSBhdXRob3JpemF0aW9uIGFuZCB0b2tlbiBlbmRwb2ludHMuIFRoZSBjbGllbnQgTVVTVCB2 YWxpZGF0ZSB0aGUKICAgICAgICAgIGF1dGhvcml6YXRpb24gc2VydmVyJ3MgVExTIGNlcnRpZmlj YXRlIGFzIGRlZmluZWQgYnkgPHhyZWYgdGFyZ2V0PSdSRkM2MTI1JyAvPiwgYW5kIGluCiAgICAg ICAgICBhY2NvcmRhbmNlIHdpdGggaXRzIHJlcXVpcmVtZW50cyBmb3Igc2VydmVyIGlkZW50aXR5 IGF1dGhlbnRpY2F0aW9uLgogICAgICAgIDwvdD4KICAgICAgPC9zZWN0aW9uPgoKICAgICAgPHNl Y3Rpb24gdGl0bGU9J0NyZWRlbnRpYWxzIEd1ZXNzaW5nIEF0dGFja3MnIGFuY2hvcj0nYW50aHJv cHknPgogICAgICAgIDx0PgogICAgICAgICAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIE1VU1Qg cHJldmVudCBhdHRhY2tlcnMgZnJvbSBndWVzc2luZyBhY2Nlc3MgdG9rZW5zLAogICAgICAgICAg YXV0aG9yaXphdGlvbiBjb2RlcywgcmVmcmVzaCB0b2tlbnMsIHJlc291cmNlIG93bmVyIHBhc3N3 b3JkcywgYW5kIGNsaWVudCBjcmVkZW50aWFscy4KICAgICAgICA8L3Q+CiAgICAgICAgPHQ+CiAg ICAgICAgICBUaGUgcHJvYmFiaWxpdHkgb2YgYW4gYXR0YWNrZXIgZ3Vlc3NpbmcgZ2VuZXJhdGVk IHRva2VucyAoYW5kIG90aGVyIGNyZWRlbnRpYWxzIG5vdAogICAgICAgICAgaW50ZW5kZWQgZm9y IGhhbmRsaW5nIGJ5IGVuZC11c2VycykgTVVTVCBiZSBsZXNzIHRoYW4gb3IgZXF1YWwgdG8gMl4o LTEyOCkgYW5kIFNIT1VMRCBiZQogICAgICAgICAgbGVzcyB0aGFuIG9yIGVxdWFsIHRvIDJeKC0x NjApLgogICAgICAgIDwvdD4KICAgICAgICA8dD4KICAgICAgICAgIFRoZSBhdXRob3JpemF0aW9u IHNlcnZlciBNVVNUIHV0aWxpemUgb3RoZXIgbWVhbnMgdG8gcHJvdGVjdCBjcmVkZW50aWFscyBp bnRlbmRlZCBmb3IKICAgICAgICAgIGVuZC11c2VyIHVzYWdlLgogICAgICAgIDwvdD4KICAgICAg PC9zZWN0aW9uPgoKICAgICAgPHNlY3Rpb24gdGl0bGU9J1BoaXNoaW5nIEF0dGFja3MnPgogICAg ICAgIDx0PgogICAgICAgICAgV2lkZSBkZXBsb3ltZW50IG9mIHRoaXMgYW5kIHNpbWlsYXIgcHJv dG9jb2xzIG1heSBjYXVzZSBlbmQtdXNlcnMgdG8gYmVjb21lIGludXJlZAogICAgICAgICAgdG8g dGhlIHByYWN0aWNlIG9mIGJlaW5nIHJlZGlyZWN0ZWQgdG8gd2Vic2l0ZXMgd2hlcmUgdGhleSBh cmUgYXNrZWQgdG8gZW50ZXIgdGhlaXIKICAgICAgICAgIHBhc3N3b3Jkcy4gSWYgZW5kLXVzZXJz IGFyZSBub3QgY2FyZWZ1bCB0byB2ZXJpZnkgdGhlIGF1dGhlbnRpY2l0eSBvZiB0aGVzZSB3ZWJz aXRlcwogICAgICAgICAgYmVmb3JlIGVudGVyaW5nIHRoZWlyIGNyZWRlbnRpYWxzLCBpdCB3aWxs IGJlIHBvc3NpYmxlIGZvciBhdHRhY2tlcnMgdG8gZXhwbG9pdCB0aGlzCiAgICAgICAgICBwcmFj dGljZSB0byBzdGVhbCByZXNvdXJjZSBvd25lcnMnIHBhc3N3b3Jkcy4KICAgICAgICA8L3Q+CiAg ICAgICAgPHQ+CiAgICAgICAgICBTZXJ2aWNlIHByb3ZpZGVycyBzaG91bGQgYXR0ZW1wdCB0byBl ZHVjYXRlIGVuZC11c2VycyBhYm91dCB0aGUgcmlza3MgcGhpc2hpbmcgYXR0YWNrcwogICAgICAg ICAgcG9zZSwgYW5kIHNob3VsZCBwcm92aWRlIG1lY2hhbmlzbXMgdGhhdCBtYWtlIGl0IGVhc3kg Zm9yIGVuZC11c2VycyB0byBjb25maXJtIHRoZQogICAgICAgICAgYXV0aGVudGljaXR5IG9mIHRo ZWlyIHNpdGVzLiBDbGllbnQgZGV2ZWxvcGVycyBzaG91bGQgY29uc2lkZXIgdGhlIHNlY3VyaXR5 IGltcGxpY2F0aW9ucwogICAgICAgICAgb2YgaG93IHRoZXkgaW50ZXJhY3Qgd2l0aCB0aGUgdXNl ci1hZ2VudCAoZS5nLiwgZXh0ZXJuYWwsIGVtYmVkZGVkKSwgYW5kIHRoZSBhYmlsaXR5IG9mCiAg ICAgICAgICB0aGUgZW5kLXVzZXIgdG8gdmVyaWZ5IHRoZSBhdXRoZW50aWNpdHkgb2YgdGhlIGF1 dGhvcml6YXRpb24gc2VydmVyLgogICAgICAgIDwvdD4KICAgICAgICA8dD4KICAgICAgICAgIFRv IHJlZHVjZSB0aGUgcmlzayBvZiBwaGlzaGluZyBhdHRhY2tzLCB0aGUgYXV0aG9yaXphdGlvbiBz ZXJ2ZXJzIE1VU1QgcmVxdWlyZSB0aGUgdXNlIG9mCiAgICAgICAgICBUTFMgb24gZXZlcnkgZW5k cG9pbnQgdXNlZCBmb3IgZW5kLXVzZXIgaW50ZXJhY3Rpb24uCiAgICAgICAgPC90PgogICAgICA8 L3NlY3Rpb24+CgogICAgICA8c2VjdGlvbiB0aXRsZT0nQ3Jvc3MtU2l0ZSBSZXF1ZXN0IEZvcmdl cnknIGFuY2hvcj0nQ1NSRic+CiAgICAgICAgPHQ+CiAgICAgICAgICBDcm9zcy1zaXRlIHJlcXVl c3QgZm9yZ2VyeSAoQ1NSRikgaXMgYW4gZXhwbG9pdCBpbiB3aGljaCBhbiBhdHRhY2tlciBjYXVz ZXMgdGhlCiAgICAgICAgICB1c2VyLWFnZW50IG9mIGEgdmljdGltIGVuZC11c2VyIHRvIGZvbGxv dyBhIG1hbGljaW91cyBVUkkgKGUuZy4gcHJvdmlkZWQgdG8gdGhlCiAgICAgICAgICB1c2VyLWFn ZW50IGFzIGEgbWlzbGVhZGluZyBsaW5rLCBpbWFnZSwgb3IgcmVkaXJlY3Rpb24pIHRvIGEgdHJ1 c3Rpbmcgc2VydmVyICh1c3VhbGx5CiAgICAgICAgICBlc3RhYmxpc2hlZCB2aWEgdGhlIHByZXNl bmNlIG9mIGEgdmFsaWQgc2Vzc2lvbiBjb29raWUpLgogICAgICAgIDwvdD4KICAgICAgICA8dD4K ICAgICAgICAgIEEgQ1NSRiBhdHRhY2sgYWdhaW5zdCB0aGUgY2xpZW50J3MgcmVkaXJlY3Rpb24g VVJJIGFsbG93cyBhbiBhdHRhY2tlciB0byBpbmplY3QgdGhlaXIgb3duCiAgICAgICAgICBhdXRo b3JpemF0aW9uIGNvZGUgb3IgYWNjZXNzIHRva2VuLCB3aGljaCBjYW4gcmVzdWx0IGluIHRoZSBj bGllbnQgdXNpbmcgYW4gYWNjZXNzIHRva2VuCiAgICAgICAgICBhc3NvY2lhdGVkIHdpdGggdGhl IGF0dGFja2VyJ3MgcHJvdGVjdGVkIHJlc291cmNlcyByYXRoZXIgdGhhbiB0aGUgdmljdGltJ3Mg KGUuZy4gc2F2ZQogICAgICAgICAgdGhlIHZpY3RpbSdzIGJhbmsgYWNjb3VudCBpbmZvcm1hdGlv biB0byBhIHByb3RlY3RlZCByZXNvdXJjZSBjb250cm9sbGVkIGJ5IHRoZQogICAgICAgICAgYXR0 YWNrZXIpLgogICAgICAgIDwvdD4KICAgICAgICA8dD4KICAgICAgICAgIFRoZSBjbGllbnQgTVVT VCBpbXBsZW1lbnQgQ1NSRiBwcm90ZWN0aW9uIGZvciBpdHMgcmVkaXJlY3Rpb24gVVJJLiBUaGlz IGlzIHR5cGljYWxseQogICAgICAgICAgYWNjb21wbGlzaGVkIGJ5IHJlcXVpcmluZyBhbnkgcmVx dWVzdCBzZW50IHRvIHRoZSByZWRpcmVjdGlvbiBVUkkgZW5kcG9pbnQgdG8gaW5jbHVkZSBhCiAg ICAgICAgICB2YWx1ZSB0aGF0IGJpbmRzIHRoZSByZXF1ZXN0IHRvIHRoZSB1c2VyLWFnZW50J3Mg YXV0aGVudGljYXRlZCBzdGF0ZSAoZS5nLiBhIGhhc2ggb2YgdGhlCiAgICAgICAgICBzZXNzaW9u IGNvb2tpZSB1c2VkIHRvIGF1dGhlbnRpY2F0ZSB0aGUgdXNlci1hZ2VudCkuIFRoZSBjbGllbnQg U0hPVUxEIHV0aWxpemUgdGhlCiAgICAgICAgICA8c3Bhbnggc3R5bGU9J3ZlcmInPnN0YXRlPC9z cGFueD4gcmVxdWVzdCBwYXJhbWV0ZXIgdG8gZGVsaXZlciB0aGlzIHZhbHVlIHRvIHRoZQogICAg ICAgICAgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgd2hlbiBtYWtpbmcgYW4gYXV0aG9yaXphdGlvbiBy ZXF1ZXN0LgogICAgICAgIDwvdD4KICAgICAgICA8dD4KICAgICAgICAgIE9uY2UgYXV0aG9yaXph dGlvbiBoYXMgYmVlbiBvYnRhaW5lZCBmcm9tIHRoZSBlbmQtdXNlciwgdGhlIGF1dGhvcml6YXRp b24gc2VydmVyCiAgICAgICAgICByZWRpcmVjdHMgdGhlIGVuZC11c2VyJ3MgdXNlci1hZ2VudCBi YWNrIHRvIHRoZSBjbGllbnQgd2l0aCB0aGUgcmVxdWlyZWQgYmluZGluZyB2YWx1ZQogICAgICAg ICAgY29udGFpbmVkIGluIHRoZSA8c3Bhbnggc3R5bGU9J3ZlcmInPnN0YXRlPC9zcGFueD4gcGFy YW1ldGVyLiBUaGUgYmluZGluZyB2YWx1ZSBlbmFibGVzCiAgICAgICAgICB0aGUgY2xpZW50IHRv IHZlcmlmeSB0aGUgdmFsaWRpdHkgb2YgdGhlIHJlcXVlc3QgYnkgbWF0Y2hpbmcgdGhlIGJpbmRp bmcgdmFsdWUgdG8gdGhlCiAgICAgICAgICB1c2VyLWFnZW50J3MgYXV0aGVudGljYXRlZCBzdGF0 ZS4gVGhlIGJpbmRpbmcgdmFsdWUgdXNlZCBmb3IgQ1NSRiBwcm90ZWN0aW9uIE1VU1QgY29udGFp bgogICAgICAgICAgYSBub24tZ3Vlc3NhYmxlIHZhbHVlIChhcyBkZXNjcmliZWQgaW4gPHhyZWYg dGFyZ2V0PSdhbnRocm9weScgLz4pLCBhbmQgdGhlIHVzZXItYWdlbnQncwogICAgICAgICAgYXV0 aGVudGljYXRlZCBzdGF0ZSAoZS5nLiBzZXNzaW9uIGNvb2tpZSwgSFRNTDUgbG9jYWwgc3RvcmFn ZSkgTVVTVCBiZSBrZXB0IGluIGEgbG9jYXRpb24KICAgICAgICAgIGFjY2Vzc2libGUgb25seSB0 byB0aGUgY2xpZW50IGFuZCB0aGUgdXNlci1hZ2VudCAoaS5lLiwgcHJvdGVjdGVkIGJ5IHNhbWUt b3JpZ2luIHBvbGljeSkuCiAgICAgICAgPC90PgogICAgICAgIDx0PgogICAgICAgICAgQSBDU1JG IGF0dGFjayBhZ2FpbnN0IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlcidzIGF1dGhvcml6YXRpb24g ZW5kcG9pbnQgY2FuIHJlc3VsdCBpbiBhbgogICAgICAgICAgYXR0YWNrZXIgb2J0YWluaW5nIGVu ZC11c2VyIGF1dGhvcml6YXRpb24gZm9yIGEgbWFsaWNpb3VzIGNsaWVudCB3aXRob3V0IGludm9s dmluZyBvcgogICAgICAgICAgYWxlcnRpbmcgdGhlIGVuZC11c2VyLgogICAgICAgIDwvdD4KICAg ICAgICA8dD4KICAgICAgICAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBNVVNUIGltcGxlbWVu dCBDU1JGIHByb3RlY3Rpb24gZm9yIGl0cyBhdXRob3JpemF0aW9uIGVuZHBvaW50LAogICAgICAg ICAgYW5kIGVuc3VyZSB0aGF0IGEgbWFsaWNpb3VzIGNsaWVudCBjYW5ub3Qgb2J0YWluIGF1dGhv cml6YXRpb24gd2l0aG91dCB0aGUgYXdhcmVuZXNzIGFuZAogICAgICAgICAgZXhwbGljaXQgY29u c2VudCBvZiB0aGUgcmVzb3VyY2Ugb3duZXIuCiAgICAgICAgPC90PgogICAgICA8L3NlY3Rpb24+ CgogICAgICA8c2VjdGlvbiB0aXRsZT0nQ2xpY2tqYWNraW5nJz4KICAgICAgICA8dD4KICAgICAg ICAgIEluIGEgY2xpY2tqYWNraW5nIGF0dGFjaywgYW4gYXR0YWNrZXIgcmVnaXN0ZXJzIGEgbGVn aXRpbWF0ZSBjbGllbnQgYW5kIHRoZW4gY29uc3RydWN0cyBhCiAgICAgICAgICBtYWxpY2lvdXMg c2l0ZSBpbiB3aGljaCBpdCBsb2FkcyB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIncyBhdXRob3Jp emF0aW9uIGVuZHBvaW50IHdlYgogICAgICAgICAgcGFnZSBpbiBhIHRyYW5zcGFyZW50IGlmcmFt ZSBvdmVybGFpZCBvbiB0b3Agb2YgYSBzZXQgb2YgZHVtbXkgYnV0dG9ucyB3aGljaCBhcmUKICAg ICAgICAgIGNhcmVmdWxseSBjb25zdHJ1Y3RlZCB0byBiZSBwbGFjZWQgZGlyZWN0bHkgdW5kZXIg aW1wb3J0YW50IGJ1dHRvbnMgb24gdGhlIGF1dGhvcml6YXRpb24KICAgICAgICAgIHBhZ2UuIFdo ZW4gYW4gZW5kLXVzZXIgY2xpY2tzIGEgbWlzbGVhZGluZyB2aXNpYmxlIGJ1dHRvbiwgdGhlIGVu ZC11c2VyIGlzIGFjdHVhbGx5CiAgICAgICAgICBjbGlja2luZyBhbiBpbnZpc2libGUgYnV0dG9u IG9uIHRoZSBhdXRob3JpemF0aW9uIHBhZ2UgKHN1Y2ggYXMgYW4gIkF1dGhvcml6ZSIgYnV0dG9u KS4KICAgICAgICAgIFRoaXMgYWxsb3dzIGFuIGF0dGFja2VyIHRvIHRyaWNrIGEgcmVzb3VyY2Ug b3duZXIgaW50byBncmFudGluZyBpdHMgY2xpZW50IGFjY2VzcyB3aXRob3V0CiAgICAgICAgICB0 aGVpciBrbm93bGVkZ2UuCiAgICAgICAgPC90PgogICAgICAgIDx0PgogICAgICAgICAgVG8gcHJl dmVudCB0aGlzIGZvcm0gb2YgYXR0YWNrLCBuYXRpdmUgYXBwbGljYXRpb25zIFNIT1VMRCB1c2Ug ZXh0ZXJuYWwgYnJvd3NlcnMgaW5zdGVhZAogICAgICAgICAgb2YgZW1iZWRkaW5nIGJyb3dzZXJz IHdpdGhpbiB0aGUgYXBwbGljYXRpb24gd2hlbiByZXF1ZXN0aW5nIGVuZC11c2VyIGF1dGhvcml6 YXRpb24uIEZvcgogICAgICAgICAgbW9zdCBuZXdlciBicm93c2VycywgYXZvaWRhbmNlIG9mIGlm cmFtZXMgY2FuIGJlIGVuZm9yY2VkIGJ5IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlcgogICAgICAg ICAgdXNpbmcgdGhlIChub24tc3RhbmRhcmQpIDxzcGFueCBzdHlsZT0ndmVyYic+eC1mcmFtZS1v cHRpb25zPC9zcGFueD4gaGVhZGVyLiBUaGlzIGhlYWRlcgogICAgICAgICAgY2FuIGhhdmUgdHdv IHZhbHVlcywgPHNwYW54IHN0eWxlPSd2ZXJiJz5kZW55PC9zcGFueD4gYW5kCiAgICAgICAgICA8 c3Bhbnggc3R5bGU9J3ZlcmInPnNhbWVvcmlnaW48L3NwYW54Piwgd2hpY2ggd2lsbCBibG9jayBh bnkgZnJhbWluZywgb3IgZnJhbWluZyBieSBzaXRlcwogICAgICAgICAgd2l0aCBhIGRpZmZlcmVu dCBvcmlnaW4sIHJlc3BlY3RpdmVseS4gRm9yIG9sZGVyIGJyb3dzZXJzLCBKYXZhU2NyaXB0IGZy YW1lYnVzdGluZwogICAgICAgICAgdGVjaG5pcXVlcyBjYW4gYmUgdXNlZCBidXQgbWF5IG5vdCBi ZSBlZmZlY3RpdmUgaW4gYWxsIGJyb3dzZXJzLgogICAgICAgIDwvdD4KICAgICAgPC9zZWN0aW9u PgoKICAgICAgPHNlY3Rpb24gdGl0bGU9J0NvZGUgSW5qZWN0aW9uIGFuZCBJbnB1dCBWYWxpZGF0 aW9uJz4KICAgICAgICA8dD4KICAgICAgICAgIEEgY29kZSBpbmplY3Rpb24gYXR0YWNrIG9jY3Vy cyB3aGVuIGFuIGlucHV0IG9yIG90aGVyd2lzZSBleHRlcm5hbCB2YXJpYWJsZSBpcyB1c2VkIGJ5 IGFuCiAgICAgICAgICBhcHBsaWNhdGlvbiB1bnNhbml0aXplZCBhbmQgY2F1c2VzIG1vZGlmaWNh dGlvbiB0byB0aGUgYXBwbGljYXRpb24gbG9naWMuIFRoaXMgbWF5IGFsbG93CiAgICAgICAgICBh biBhdHRhY2tlciB0byBnYWluIGFjY2VzcyB0byB0aGUgYXBwbGljYXRpb24gZGV2aWNlIG9yIGl0 cyBkYXRhLCBjYXVzZSBkZW5pYWwgb2YKICAgICAgICAgIHNlcnZpY2UsIG9yIGEgd2lkZSByYW5n ZSBvZiBtYWxpY2lvdXMgc2lkZS1lZmZlY3RzLgogICAgICAgIDwvdD4KICAgICAgICA8dD4KICAg ICAgICAgIFRoZSBBdXRob3JpemF0aW9uIHNlcnZlciBhbmQgY2xpZW50IE1VU1Qgc2FuaXRpemUg KGFuZCB2YWxpZGF0ZSB3aGVuIHBvc3NpYmxlKSBhbnkgdmFsdWUKICAgICAgICAgIHJlY2VpdmVk LCBpbiBwYXJ0aWN1bGFyLCB0aGUgdmFsdWUgb2YgdGhlIDxzcGFueCBzdHlsZT0ndmVyYic+c3Rh dGU8L3NwYW54PiBhbmQKICAgICAgICAgIDxzcGFueCBzdHlsZT0ndmVyYic+cmVkaXJlY3RfdXJp PC9zcGFueD4gcGFyYW1ldGVycy4KICAgICAgICA8L3Q+CiAgICAgIDwvc2VjdGlvbj4KCiAgICAg IDxzZWN0aW9uIHRpdGxlPSdPcGVuIFJlZGlyZWN0b3JzJyBhbmNob3I9J29wZW4tcmVkaXJlY3Qn PgogICAgICAgIDx0PgogICAgICAgICAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGF1dGhvcml6 YXRpb24gZW5kcG9pbnQgYW5kIHRoZSBjbGllbnQgcmVkaXJlY3Rpb24gZW5kcG9pbnQgY2FuCiAg ICAgICAgICBiZSBpbXByb3Blcmx5IGNvbmZpZ3VyZWQgYW5kIG9wZXJhdGUgYXMgb3BlbiByZWRp cmVjdG9ycy4gQW4gb3BlbiByZWRpcmVjdG9yIGlzIGFuCiAgICAgICAgICBlbmRwb2ludCB1c2lu ZyBhIHBhcmFtZXRlciB0byBhdXRvbWF0aWNhbGx5IHJlZGlyZWN0IGEgdXNlci1hZ2VudCB0byB0 aGUgbG9jYXRpb24KICAgICAgICAgIHNwZWNpZmllZCBieSB0aGUgcGFyYW1ldGVyIHZhbHVlIHdp dGhvdXQgYW55IHZhbGlkYXRpb24uCiAgICAgICAgPC90PgogICAgICAgIDx0PgogICAgICAgICAg T3BlbiByZWRpcmVjdG9ycyBjYW4gYmUgdXNlZCBpbiBwaGlzaGluZyBhdHRhY2tzLCBvciBieSBh biBhdHRhY2tlciB0byBnZXQgZW5kLXVzZXJzIHRvCiAgICAgICAgICB2aXNpdCBtYWxpY2lvdXMg c2l0ZXMgYnkgbWFraW5nIHRoZSBVUkkncyBhdXRob3JpdHkgbG9vayBsaWtlIGEgZmFtaWxpYXIg YW5kIHRydXN0ZWQKICAgICAgICAgIGRlc3RpbmF0aW9uLiBJbiBhZGRpdGlvbiwgaWYgdGhlIGF1 dGhvcml6YXRpb24gc2VydmVyIGFsbG93cyB0aGUgY2xpZW50IHRvIHJlZ2lzdGVyIG9ubHkKICAg ICAgICAgIHBhcnQgb2YgdGhlIHJlZGlyZWN0aW9uIFVSSSwgYW4gYXR0YWNrZXIgY2FuIHVzZSBh biBvcGVuIHJlZGlyZWN0b3Igb3BlcmF0ZWQgYnkgdGhlCiAgICAgICAgICBjbGllbnQgdG8gY29u c3RydWN0IGEgcmVkaXJlY3Rpb24gVVJJIHRoYXQgd2lsbCBwYXNzIHRoZSBhdXRob3JpemF0aW9u IHNlcnZlciB2YWxpZGF0aW9uCiAgICAgICAgICBidXQgd2lsbCBzZW5kIHRoZSBhdXRob3JpemF0 aW9uIGNvZGUgb3IgYWNjZXNzIHRva2VuIHRvIGFuIGVuZHBvaW50IHVuZGVyIHRoZSBjb250cm9s IG9mCiAgICAgICAgICB0aGUgYXR0YWNrZXIuCiAgICAgICAgPC90PgogICAgICA8L3NlY3Rpb24+ CgogICAgPC9zZWN0aW9uPgoKICAgIDxzZWN0aW9uIHRpdGxlPSdJQU5BIENvbnNpZGVyYXRpb25z Jz4KCiAgICAgIDxzZWN0aW9uIHRpdGxlPSdUaGUgT0F1dGggQWNjZXNzIFRva2VuIFR5cGUgUmVn aXN0cnknIGFuY2hvcj0ndHlwZS1yZWdpc3RyeSc+CiAgICAgICAgPHQ+CiAgICAgICAgICBUaGlz IHNwZWNpZmljYXRpb24gZXN0YWJsaXNoZXMgdGhlIE9BdXRoIGFjY2VzcyB0b2tlbiB0eXBlIHJl Z2lzdHJ5LgogICAgICAgIDwvdD4KICAgICAgICA8dD4KICAgICAgICAgIEFjY2VzcyB0b2tlbiB0 eXBlcyBhcmUgcmVnaXN0ZXJlZCB3aXRoIGEgU3BlY2lmaWNhdGlvbiBSZXF1aXJlZAogICAgICAg ICAgKDx4cmVmIHRhcmdldD0nUkZDNTIyNicgLz4pIGFmdGVyIGEgdHdvIHdlZWsgcmV2aWV3IHBl cmlvZCBvbiB0aGUgW1RCRF1AaWV0Zi5vcmcgbWFpbGluZwogICAgICAgICAgbGlzdCwgb24gdGhl IGFkdmljZSBvZiBvbmUgb3IgbW9yZSBEZXNpZ25hdGVkIEV4cGVydHMuIEhvd2V2ZXIsIHRvIGFs bG93IGZvciB0aGUKICAgICAgICAgIGFsbG9jYXRpb24gb2YgdmFsdWVzIHByaW9yIHRvIHB1Ymxp Y2F0aW9uLCB0aGUgRGVzaWduYXRlZCBFeHBlcnQocykgbWF5IGFwcHJvdmUKICAgICAgICAgIHJl Z2lzdHJhdGlvbiBvbmNlIHRoZXkgYXJlIHNhdGlzZmllZCB0aGF0IHN1Y2ggYSBzcGVjaWZpY2F0 aW9uIHdpbGwgYmUgcHVibGlzaGVkLgogICAgICAgIDwvdD4KICAgICAgICA8dD4KICAgICAgICAg IFJlZ2lzdHJhdGlvbiByZXF1ZXN0cyBtdXN0IGJlIHNlbnQgdG8gdGhlIFtUQkRdQGlldGYub3Jn IG1haWxpbmcgbGlzdCBmb3IgcmV2aWV3IGFuZAogICAgICAgICAgY29tbWVudCwgd2l0aCBhbiBh cHByb3ByaWF0ZSBzdWJqZWN0IChlLmcuLCAiUmVxdWVzdCBmb3IgYWNjZXNzIHRva2VuIHR5cGU6 IGV4YW1wbGUiKS4KICAgICAgICAgIFtbIE5vdGUgdG8gUkZDLUVESVRPUjogVGhlIG5hbWUgb2Yg dGhlIG1haWxpbmcgbGlzdCBzaG91bGQgYmUgZGV0ZXJtaW5lZCBpbiBjb25zdWx0YXRpb24KICAg ICAgICAgIHdpdGggdGhlIElFU0cgYW5kIElBTkEuIFN1Z2dlc3RlZCBuYW1lOiBvYXV0aC1leHQt cmV2aWV3LiBdXQogICAgICAgIDwvdD4KICAgICAgICA8dD4KICAgICAgICAgIFdpdGhpbiB0aGUg cmV2aWV3IHBlcmlvZCwgdGhlIERlc2lnbmF0ZWQgRXhwZXJ0KHMpIHdpbGwgZWl0aGVyIGFwcHJv dmUgb3IKICAgICAgICAgIGRlbnkgdGhlIHJlZ2lzdHJhdGlvbiByZXF1ZXN0LCBjb21tdW5pY2F0 aW5nIHRoaXMgZGVjaXNpb24gdG8gdGhlIHJldmlldyBsaXN0IGFuZCBJQU5BLgogICAgICAgICAg RGVuaWFscyBzaG91bGQgaW5jbHVkZSBhbiBleHBsYW5hdGlvbiBhbmQsIGlmIGFwcGxpY2FibGUs IHN1Z2dlc3Rpb25zIGFzIHRvIGhvdyB0byBtYWtlCiAgICAgICAgICB0aGUgcmVxdWVzdCBzdWNj ZXNzZnVsLgogICAgICAgIDwvdD4KICAgICAgICA8dD4KICAgICAgICAgIElBTkEgbXVzdCBvbmx5 IGFjY2VwdCByZWdpc3RyeSB1cGRhdGVzIGZyb20gdGhlIERlc2lnbmF0ZWQgRXhwZXJ0KHMpLCBh bmQgc2hvdWxkIGRpcmVjdAogICAgICAgICAgYWxsIHJlcXVlc3RzIGZvciByZWdpc3RyYXRpb24g dG8gdGhlIHJldmlldyBtYWlsaW5nIGxpc3QuCiAgICAgICAgPC90PgoKICAgICAgICA8c2VjdGlv biB0aXRsZT0nUmVnaXN0cmF0aW9uIFRlbXBsYXRlJz4KICAgICAgICAgIDx0PgogICAgICAgICAg ICA8bGlzdCBzdHlsZT0naGFuZ2luZyc+CiAgICAgICAgICAgICAgPHQgaGFuZ1RleHQ9J1R5cGUg bmFtZTonPgogICAgICAgICAgICAgICAgPHZzcGFjZSAvPgogICAgICAgICAgICAgICAgVGhlIG5h bWUgcmVxdWVzdGVkIChlLmcuLCAiZXhhbXBsZSIpLgogICAgICAgICAgICAgIDwvdD4KICAgICAg ICAgICAgICA8dCBoYW5nVGV4dD0nQWRkaXRpb25hbCBUb2tlbiBFbmRwb2ludCBSZXNwb25zZSBQ YXJhbWV0ZXJzOic+CiAgICAgICAgICAgICAgICA8dnNwYWNlIC8+CiAgICAgICAgICAgICAgICBB ZGRpdGlvbmFsIHJlc3BvbnNlIHBhcmFtZXRlcnMgcmV0dXJuZWQgdG9nZXRoZXIgd2l0aCB0aGUK ICAgICAgICAgICAgICAgIDxzcGFueCBzdHlsZT0ndmVyYic+YWNjZXNzX3Rva2VuPC9zcGFueD4g cGFyYW1ldGVyLiBOZXcgcGFyYW1ldGVycyBNVVNUIGJlCiAgICAgICAgICAgICAgICBzZXBhcmF0 ZWx5IHJlZ2lzdGVyZWQgaW4gdGhlIE9BdXRoIHBhcmFtZXRlcnMgcmVnaXN0cnkgYXMgZGVzY3Jp YmVkIGJ5CiAgICAgICAgICAgICAgICA8eHJlZiB0YXJnZXQ9J3BhcmFtZXRlcnMtcmVnaXN0cnkn IC8+LgogICAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAgICA8dCBoYW5nVGV4dD0nSFRUUCBB dXRoZW50aWNhdGlvbiBTY2hlbWUocyk6Jz4KICAgICAgICAgICAgICAgIDx2c3BhY2UgLz4KICAg ICAgICAgICAgICAgIFRoZSBIVFRQIGF1dGhlbnRpY2F0aW9uIHNjaGVtZSBuYW1lKHMpLCBpZiBh bnksIHVzZWQgdG8gYXV0aGVudGljYXRlIHByb3RlY3RlZAogICAgICAgICAgICAgICAgcmVzb3Vy Y2VzIHJlcXVlc3RzIHVzaW5nIGFjY2VzcyB0b2tlbnMgb2YgdGhpcyB0eXBlLgogICAgICAgICAg ICAgIDwvdD4KICAgICAgICAgICAgICA8dCBoYW5nVGV4dD0nQ2hhbmdlIGNvbnRyb2xsZXI6Jz4K ICAgICAgICAgICAgICAgIDx2c3BhY2UgLz4KICAgICAgICAgICAgICAgIEZvciBzdGFuZGFyZHMt dHJhY2sgUkZDcywgc3RhdGUgIklFVEYiLiBGb3Igb3RoZXJzLCBnaXZlIHRoZSBuYW1lIG9mIHRo ZQogICAgICAgICAgICAgICAgcmVzcG9uc2libGUgcGFydHkuIE90aGVyIGRldGFpbHMgKGUuZy4s IHBvc3RhbCBhZGRyZXNzLCBlLW1haWwgYWRkcmVzcywgaG9tZSBwYWdlCiAgICAgICAgICAgICAg ICBVUkkpIG1heSBhbHNvIGJlIGluY2x1ZGVkLgogICAgICAgICAgICAgIDwvdD4KICAgICAgICAg ICAgICA8dCBoYW5nVGV4dD0nU3BlY2lmaWNhdGlvbiBkb2N1bWVudChzKTonPgogICAgICAgICAg ICAgICAgPHZzcGFjZSAvPgogICAgICAgICAgICAgICAgUmVmZXJlbmNlIHRvIHRoZSBkb2N1bWVu dCB0aGF0IHNwZWNpZmllcyB0aGUgcGFyYW1ldGVyLCBwcmVmZXJhYmx5IGluY2x1ZGluZyBhIFVS SSB0aGF0CiAgICAgICAgICAgICAgICBjYW4gYmUgdXNlZCB0byByZXRyaWV2ZSBhIGNvcHkgb2Yg dGhlIGRvY3VtZW50LiBBbiBpbmRpY2F0aW9uIG9mIHRoZSByZWxldmFudAogICAgICAgICAgICAg ICAgc2VjdGlvbnMgbWF5IGFsc28gYmUgaW5jbHVkZWQsIGJ1dCBpcyBub3QgcmVxdWlyZWQuCiAg ICAgICAgICAgICAgPC90PgogICAgICAgICAgICA8L2xpc3Q+CiAgICAgICAgICA8L3Q+CiAgICAg ICAgPC9zZWN0aW9uPgoKICAgICAgPC9zZWN0aW9uPgoKICAgICAgPHNlY3Rpb24gdGl0bGU9J1Ro ZSBPQXV0aCBQYXJhbWV0ZXJzIFJlZ2lzdHJ5JyBhbmNob3I9J3BhcmFtZXRlcnMtcmVnaXN0cnkn PgogICAgICAgIDx0PgogICAgICAgICAgVGhpcyBzcGVjaWZpY2F0aW9uIGVzdGFibGlzaGVzIHRo ZSBPQXV0aCBwYXJhbWV0ZXJzIHJlZ2lzdHJ5LgogICAgICAgIDwvdD4KICAgICAgICA8dD4KICAg ICAgICAgIEFkZGl0aW9uYWwgcGFyYW1ldGVycyBmb3IgaW5jbHVzaW9uIGluIHRoZSBhdXRob3Jp emF0aW9uIGVuZHBvaW50IHJlcXVlc3QsIHRoZQogICAgICAgICAgYXV0aG9yaXphdGlvbiBlbmRw b2ludCByZXNwb25zZSwgdGhlIHRva2VuIGVuZHBvaW50IHJlcXVlc3QsIG9yIHRoZSB0b2tlbiBl bmRwb2ludAogICAgICAgICAgcmVzcG9uc2UgYXJlIHJlZ2lzdGVyZWQgd2l0aCBhIFNwZWNpZmlj YXRpb24gUmVxdWlyZWQKICAgICAgICAgICg8eHJlZiB0YXJnZXQ9J1JGQzUyMjYnIC8+KSBhZnRl ciBhIHR3byB3ZWVrIHJldmlldyBwZXJpb2Qgb24gdGhlIFtUQkRdQGlldGYub3JnIG1haWxpbmcK ICAgICAgICAgIGxpc3QsIG9uIHRoZSBhZHZpY2Ugb2Ygb25lIG9yIG1vcmUgRGVzaWduYXRlZCBF eHBlcnRzLiBIb3dldmVyLCB0byBhbGxvdyBmb3IgdGhlCiAgICAgICAgICBhbGxvY2F0aW9uIG9m IHZhbHVlcyBwcmlvciB0byBwdWJsaWNhdGlvbiwgdGhlIERlc2lnbmF0ZWQgRXhwZXJ0KHMpIG1h eSBhcHByb3ZlCiAgICAgICAgICByZWdpc3RyYXRpb24gb25jZSB0aGV5IGFyZSBzYXRpc2ZpZWQg dGhhdCBzdWNoIGEgc3BlY2lmaWNhdGlvbiB3aWxsIGJlIHB1Ymxpc2hlZC4KICAgICAgICA8L3Q+ CiAgICAgICAgPHQ+CiAgICAgICAgICBSZWdpc3RyYXRpb24gcmVxdWVzdHMgbXVzdCBiZSBzZW50 IHRvIHRoZSBbVEJEXUBpZXRmLm9yZyBtYWlsaW5nIGxpc3QgZm9yIHJldmlldyBhbmQKICAgICAg ICAgIGNvbW1lbnQsIHdpdGggYW4gYXBwcm9wcmlhdGUgc3ViamVjdCAoZS5nLiwgIlJlcXVlc3Qg Zm9yIHBhcmFtZXRlcjogZXhhbXBsZSIpLgogICAgICAgICAgW1sgTm90ZSB0byBSRkMtRURJVE9S OiBUaGUgbmFtZSBvZiB0aGUgbWFpbGluZyBsaXN0IHNob3VsZCBiZSBkZXRlcm1pbmVkIGluIGNv bnN1bHRhdGlvbgogICAgICAgICAgd2l0aCB0aGUgSUVTRyBhbmQgSUFOQS4gU3VnZ2VzdGVkIG5h bWU6IG9hdXRoLWV4dC1yZXZpZXcuIF1dCiAgICAgICAgPC90PgogICAgICAgIDx0PgogICAgICAg ICAgV2l0aGluIHRoZSByZXZpZXcgcGVyaW9kLCB0aGUgRGVzaWduYXRlZCBFeHBlcnQocykgd2ls bCBlaXRoZXIgYXBwcm92ZSBvcgogICAgICAgICAgZGVueSB0aGUgcmVnaXN0cmF0aW9uIHJlcXVl c3QsIGNvbW11bmljYXRpbmcgdGhpcyBkZWNpc2lvbiB0byB0aGUgcmV2aWV3IGxpc3QgYW5kIElB TkEuCiAgICAgICAgICBEZW5pYWxzIHNob3VsZCBpbmNsdWRlIGFuIGV4cGxhbmF0aW9uIGFuZCwg aWYgYXBwbGljYWJsZSwgc3VnZ2VzdGlvbnMgYXMgdG8gaG93IHRvIG1ha2UKICAgICAgICAgIHRo ZSByZXF1ZXN0IHN1Y2Nlc3NmdWwuCiAgICAgICAgPC90PgogICAgICAgIDx0PgogICAgICAgICAg SUFOQSBtdXN0IG9ubHkgYWNjZXB0IHJlZ2lzdHJ5IHVwZGF0ZXMgZnJvbSB0aGUgRGVzaWduYXRl ZCBFeHBlcnQocyksIGFuZCBzaG91bGQgZGlyZWN0CiAgICAgICAgICBhbGwgcmVxdWVzdHMgZm9y IHJlZ2lzdHJhdGlvbiB0byB0aGUgcmV2aWV3IG1haWxpbmcgbGlzdC4KICAgICAgICA8L3Q+Cgog ICAgICAgIDxzZWN0aW9uIHRpdGxlPSdSZWdpc3RyYXRpb24gVGVtcGxhdGUnPgogICAgICAgICAg PHQ+CiAgICAgICAgICAgIDxsaXN0IHN0eWxlPSdoYW5naW5nJz4KICAgICAgICAgICAgICA8dCBo YW5nVGV4dD0nUGFyYW1ldGVyIG5hbWU6Jz4KICAgICAgICAgICAgICAgIDx2c3BhY2UgLz4KICAg ICAgICAgICAgICAgIFRoZSBuYW1lIHJlcXVlc3RlZCAoZS5nLiwgImV4YW1wbGUiKS4KICAgICAg ICAgICAgICA8L3Q+CiAgICAgICAgICAgICAgPHQgaGFuZ1RleHQ9J1BhcmFtZXRlciB1c2FnZSBs b2NhdGlvbjonPgogICAgICAgICAgICAgICAgPHZzcGFjZSAvPgogICAgICAgICAgICAgICAgVGhl IGxvY2F0aW9uKHMpIHdoZXJlIHBhcmFtZXRlciBjYW4gYmUgdXNlZC4gVGhlIHBvc3NpYmxlIGxv Y2F0aW9ucyBhcmU6CiAgICAgICAgICAgICAgICBhdXRob3JpemF0aW9uIHJlcXVlc3QsIGF1dGhv cml6YXRpb24gcmVzcG9uc2UsIHRva2VuIHJlcXVlc3QsIG9yIHRva2VuIHJlc3BvbnNlLgogICAg ICAgICAgICAgIDwvdD4KICAgICAgICAgICAgICA8dCBoYW5nVGV4dD0nQ2hhbmdlIGNvbnRyb2xs ZXI6Jz4KICAgICAgICAgICAgICAgIDx2c3BhY2UgLz4KICAgICAgICAgICAgICAgIEZvciBzdGFu ZGFyZHMtdHJhY2sgUkZDcywgc3RhdGUgIklFVEYiLiBGb3Igb3RoZXJzLCBnaXZlIHRoZSBuYW1l IG9mIHRoZQogICAgICAgICAgICAgICAgcmVzcG9uc2libGUgcGFydHkuIE90aGVyIGRldGFpbHMg KGUuZy4sIHBvc3RhbCBhZGRyZXNzLCBlLW1haWwgYWRkcmVzcywgaG9tZSBwYWdlCiAgICAgICAg ICAgICAgICBVUkkpIG1heSBhbHNvIGJlIGluY2x1ZGVkLgogICAgICAgICAgICAgIDwvdD4KICAg ICAgICAgICAgICA8dCBoYW5nVGV4dD0nU3BlY2lmaWNhdGlvbiBkb2N1bWVudChzKTonPgogICAg ICAgICAgICAgICAgPHZzcGFjZSAvPgogICAgICAgICAgICAgICAgUmVmZXJlbmNlIHRvIHRoZSBk b2N1bWVudCB0aGF0IHNwZWNpZmllcyB0aGUgcGFyYW1ldGVyLCBwcmVmZXJhYmx5IGluY2x1ZGlu ZyBhIFVSSSB0aGF0CiAgICAgICAgICAgICAgICBjYW4gYmUgdXNlZCB0byByZXRyaWV2ZSBhIGNv cHkgb2YgdGhlIGRvY3VtZW50LiBBbiBpbmRpY2F0aW9uIG9mIHRoZSByZWxldmFudAogICAgICAg ICAgICAgICAgc2VjdGlvbnMgbWF5IGFsc28gYmUgaW5jbHVkZWQsIGJ1dCBpcyBub3QgcmVxdWly ZWQuCiAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICA8L2xpc3Q+CiAgICAgICAgICA8L3Q+ CiAgICAgICAgPC9zZWN0aW9uPgoKICAgICAgICA8c2VjdGlvbiB0aXRsZT0nSW5pdGlhbCBSZWdp c3RyeSBDb250ZW50cyc+CiAgICAgICAgICA8dD4KICAgICAgICAgICAgVGhlIE9BdXRoIFBhcmFt ZXRlcnMgUmVnaXN0cnkncyBpbml0aWFsIGNvbnRlbnRzIGFyZToKICAgICAgICAgIDwvdD4KICAg ICAgICAgIDx0PgogICAgICAgICAgICA8bGlzdCBzdHlsZT0nc3ltYm9scyc+CiAgICAgICAgICAg ICAgPHQ+CiAgICAgICAgICAgICAgICBQYXJhbWV0ZXIgbmFtZTogY2xpZW50X2lkCiAgICAgICAg ICAgICAgPC90PgogICAgICAgICAgICAgIDx0PgogICAgICAgICAgICAgICAgUGFyYW1ldGVyIHVz YWdlIGxvY2F0aW9uOiBhdXRob3JpemF0aW9uIHJlcXVlc3QsIHRva2VuIHJlcXVlc3QKICAgICAg ICAgICAgICA8L3Q+CiAgICAgICAgICAgICAgPHQ+CiAgICAgICAgICAgICAgICBDaGFuZ2UgY29u dHJvbGxlcjogSUVURgogICAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAgICA8dD4KICAgICAg ICAgICAgICAgIFNwZWNpZmljYXRpb24gZG9jdW1lbnQocyk6IFtbIHRoaXMgZG9jdW1lbnQgXV0K ICAgICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgIDwvbGlzdD4KICAgICAgICAgIDwvdD4KICAg ICAgICAgIDx0PgogICAgICAgICAgICA8bGlzdCBzdHlsZT0nc3ltYm9scyc+CiAgICAgICAgICAg ICAgPHQ+CiAgICAgICAgICAgICAgICBQYXJhbWV0ZXIgbmFtZTogY2xpZW50X3NlY3JldAogICAg ICAgICAgICAgIDwvdD4KICAgICAgICAgICAgICA8dD4KICAgICAgICAgICAgICAgIFBhcmFtZXRl ciB1c2FnZSBsb2NhdGlvbjogdG9rZW4gcmVxdWVzdAogICAgICAgICAgICAgIDwvdD4KICAgICAg ICAgICAgICA8dD4KICAgICAgICAgICAgICAgIENoYW5nZSBjb250cm9sbGVyOiBJRVRGCiAgICAg ICAgICAgICAgPC90PgogICAgICAgICAgICAgIDx0PgogICAgICAgICAgICAgICAgU3BlY2lmaWNh dGlvbiBkb2N1bWVudChzKTogW1sgdGhpcyBkb2N1bWVudCBdXQogICAgICAgICAgICAgIDwvdD4K ICAgICAgICAgICAgPC9saXN0PgogICAgICAgICAgPC90PgogICAgICAgICAgPHQ+CiAgICAgICAg ICAgIDxsaXN0IHN0eWxlPSdzeW1ib2xzJz4KICAgICAgICAgICAgICA8dD4KICAgICAgICAgICAg ICAgIFBhcmFtZXRlciBuYW1lOiByZXNwb25zZV90eXBlCiAgICAgICAgICAgICAgPC90PgogICAg ICAgICAgICAgIDx0PgogICAgICAgICAgICAgICAgUGFyYW1ldGVyIHVzYWdlIGxvY2F0aW9uOiBh dXRob3JpemF0aW9uIHJlcXVlc3QKICAgICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgICAgPHQ+ CiAgICAgICAgICAgICAgICBDaGFuZ2UgY29udHJvbGxlcjogSUVURgogICAgICAgICAgICAgIDwv dD4KICAgICAgICAgICAgICA8dD4KICAgICAgICAgICAgICAgIFNwZWNpZmljYXRpb24gZG9jdW1l bnQocyk6IFtbIHRoaXMgZG9jdW1lbnQgXV0KICAgICAgICAgICAgICA8L3Q+CiAgICAgICAgICAg IDwvbGlzdD4KICAgICAgICAgIDwvdD4KICAgICAgICAgIDx0PgogICAgICAgICAgICA8bGlzdCBz dHlsZT0nc3ltYm9scyc+CiAgICAgICAgICAgICAgPHQ+CiAgICAgICAgICAgICAgICBQYXJhbWV0 ZXIgbmFtZTogcmVkaXJlY3RfdXJpCiAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICAgIDx0 PgogICAgICAgICAgICAgICAgUGFyYW1ldGVyIHVzYWdlIGxvY2F0aW9uOiBhdXRob3JpemF0aW9u IHJlcXVlc3QsIHRva2VuIHJlcXVlc3QKICAgICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgICAg PHQ+CiAgICAgICAgICAgICAgICBDaGFuZ2UgY29udHJvbGxlcjogSUVURgogICAgICAgICAgICAg IDwvdD4KICAgICAgICAgICAgICA8dD4KICAgICAgICAgICAgICAgIFNwZWNpZmljYXRpb24gZG9j dW1lbnQocyk6IFtbIHRoaXMgZG9jdW1lbnQgXV0KICAgICAgICAgICAgICA8L3Q+CiAgICAgICAg ICAgIDwvbGlzdD4KICAgICAgICAgIDwvdD4KICAgICAgICAgIDx0PgogICAgICAgICAgICA8bGlz dCBzdHlsZT0nc3ltYm9scyc+CiAgICAgICAgICAgICAgPHQ+CiAgICAgICAgICAgICAgICBQYXJh bWV0ZXIgbmFtZTogc2NvcGUKICAgICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgICAgPHQ+CiAg ICAgICAgICAgICAgICBQYXJhbWV0ZXIgdXNhZ2UgbG9jYXRpb246IGF1dGhvcml6YXRpb24gcmVx dWVzdCwgYXV0aG9yaXphdGlvbiByZXNwb25zZSwgdG9rZW4KICAgICAgICAgICAgICAgIHJlcXVl c3QsIHRva2VuIHJlc3BvbnNlCiAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICAgIDx0Pgog ICAgICAgICAgICAgICAgQ2hhbmdlIGNvbnRyb2xsZXI6IElFVEYKICAgICAgICAgICAgICA8L3Q+ CiAgICAgICAgICAgICAgPHQ+CiAgICAgICAgICAgICAgICBTcGVjaWZpY2F0aW9uIGRvY3VtZW50 KHMpOiBbWyB0aGlzIGRvY3VtZW50IF1dCiAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICA8 L2xpc3Q+CiAgICAgICAgICA8L3Q+CiAgICAgICAgICA8dD4KICAgICAgICAgICAgPGxpc3Qgc3R5 bGU9J3N5bWJvbHMnPgogICAgICAgICAgICAgIDx0PgogICAgICAgICAgICAgICAgUGFyYW1ldGVy IG5hbWU6IHN0YXRlCiAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICAgIDx0PgogICAgICAg ICAgICAgICAgUGFyYW1ldGVyIHVzYWdlIGxvY2F0aW9uOiBhdXRob3JpemF0aW9uIHJlcXVlc3Qs IGF1dGhvcml6YXRpb24gcmVzcG9uc2UKICAgICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgICAg PHQ+CiAgICAgICAgICAgICAgICBDaGFuZ2UgY29udHJvbGxlcjogSUVURgogICAgICAgICAgICAg IDwvdD4KICAgICAgICAgICAgICA8dD4KICAgICAgICAgICAgICAgIFNwZWNpZmljYXRpb24gZG9j dW1lbnQocyk6IFtbIHRoaXMgZG9jdW1lbnQgXV0KICAgICAgICAgICAgICA8L3Q+CiAgICAgICAg ICAgIDwvbGlzdD4KICAgICAgICAgIDwvdD4KICAgICAgICAgIDx0PgogICAgICAgICAgICA8bGlz dCBzdHlsZT0nc3ltYm9scyc+CiAgICAgICAgICAgICAgPHQ+CiAgICAgICAgICAgICAgICBQYXJh bWV0ZXIgbmFtZTogY29kZQogICAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAgICA8dD4KICAg ICAgICAgICAgICAgIFBhcmFtZXRlciB1c2FnZSBsb2NhdGlvbjogYXV0aG9yaXphdGlvbiByZXNw b25zZSwgdG9rZW4gcmVxdWVzdAogICAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAgICA8dD4K ICAgICAgICAgICAgICAgIENoYW5nZSBjb250cm9sbGVyOiBJRVRGCiAgICAgICAgICAgICAgPC90 PgogICAgICAgICAgICAgIDx0PgogICAgICAgICAgICAgICAgU3BlY2lmaWNhdGlvbiBkb2N1bWVu dChzKTogW1sgdGhpcyBkb2N1bWVudCBdXQogICAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAg PC9saXN0PgogICAgICAgICAgPC90PgogICAgICAgICAgPHQ+CiAgICAgICAgICAgIDxsaXN0IHN0 eWxlPSdzeW1ib2xzJz4KICAgICAgICAgICAgICA8dD4KICAgICAgICAgICAgICAgIFBhcmFtZXRl ciBuYW1lOiBlcnJvcl9kZXNjcmlwdGlvbgogICAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAg ICA8dD4KICAgICAgICAgICAgICAgIFBhcmFtZXRlciB1c2FnZSBsb2NhdGlvbjogYXV0aG9yaXph dGlvbiByZXNwb25zZSwgdG9rZW4gcmVzcG9uc2UKICAgICAgICAgICAgICA8L3Q+CiAgICAgICAg ICAgICAgPHQ+CiAgICAgICAgICAgICAgICBDaGFuZ2UgY29udHJvbGxlcjogSUVURgogICAgICAg ICAgICAgIDwvdD4KICAgICAgICAgICAgICA8dD4KICAgICAgICAgICAgICAgIFNwZWNpZmljYXRp b24gZG9jdW1lbnQocyk6IFtbIHRoaXMgZG9jdW1lbnQgXV0KICAgICAgICAgICAgICA8L3Q+CiAg ICAgICAgICAgIDwvbGlzdD4KICAgICAgICAgIDwvdD4KICAgICAgICAgIDx0PgogICAgICAgICAg ICA8bGlzdCBzdHlsZT0nc3ltYm9scyc+CiAgICAgICAgICAgICAgPHQ+CiAgICAgICAgICAgICAg ICBQYXJhbWV0ZXIgbmFtZTogZXJyb3JfdXJpCiAgICAgICAgICAgICAgPC90PgogICAgICAgICAg ICAgIDx0PgogICAgICAgICAgICAgICAgUGFyYW1ldGVyIHVzYWdlIGxvY2F0aW9uOiBhdXRob3Jp emF0aW9uIHJlc3BvbnNlLCB0b2tlbiByZXNwb25zZQogICAgICAgICAgICAgIDwvdD4KICAgICAg ICAgICAgICA8dD4KICAgICAgICAgICAgICAgIENoYW5nZSBjb250cm9sbGVyOiBJRVRGCiAgICAg ICAgICAgICAgPC90PgogICAgICAgICAgICAgIDx0PgogICAgICAgICAgICAgICAgU3BlY2lmaWNh dGlvbiBkb2N1bWVudChzKTogW1sgdGhpcyBkb2N1bWVudCBdXQogICAgICAgICAgICAgIDwvdD4K ICAgICAgICAgICAgPC9saXN0PgogICAgICAgICAgPC90PgogICAgICAgICAgPHQ+CiAgICAgICAg ICAgIDxsaXN0IHN0eWxlPSdzeW1ib2xzJz4KICAgICAgICAgICAgICA8dD4KICAgICAgICAgICAg ICAgIFBhcmFtZXRlciBuYW1lOiBncmFudF90eXBlCiAgICAgICAgICAgICAgPC90PgogICAgICAg ICAgICAgIDx0PgogICAgICAgICAgICAgICAgUGFyYW1ldGVyIHVzYWdlIGxvY2F0aW9uOiB0b2tl biByZXF1ZXN0CiAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICAgIDx0PgogICAgICAgICAg ICAgICAgQ2hhbmdlIGNvbnRyb2xsZXI6IElFVEYKICAgICAgICAgICAgICA8L3Q+CiAgICAgICAg ICAgICAgPHQ+CiAgICAgICAgICAgICAgICBTcGVjaWZpY2F0aW9uIGRvY3VtZW50KHMpOiBbWyB0 aGlzIGRvY3VtZW50IF1dCiAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICA8L2xpc3Q+CiAg ICAgICAgICA8L3Q+CiAgICAgICAgICA8dD4KICAgICAgICAgICAgPGxpc3Qgc3R5bGU9J3N5bWJv bHMnPgogICAgICAgICAgICAgIDx0PgogICAgICAgICAgICAgICAgUGFyYW1ldGVyIG5hbWU6IGFj Y2Vzc190b2tlbgogICAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAgICA8dD4KICAgICAgICAg ICAgICAgIFBhcmFtZXRlciB1c2FnZSBsb2NhdGlvbjogYXV0aG9yaXphdGlvbiByZXNwb25zZSwg dG9rZW4gcmVzcG9uc2UKICAgICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgICAgPHQ+CiAgICAg ICAgICAgICAgICBDaGFuZ2UgY29udHJvbGxlcjogSUVURgogICAgICAgICAgICAgIDwvdD4KICAg ICAgICAgICAgICA8dD4KICAgICAgICAgICAgICAgIFNwZWNpZmljYXRpb24gZG9jdW1lbnQocyk6 IFtbIHRoaXMgZG9jdW1lbnQgXV0KICAgICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgIDwvbGlz dD4KICAgICAgICAgIDwvdD4KICAgICAgICAgIDx0PgogICAgICAgICAgICA8bGlzdCBzdHlsZT0n c3ltYm9scyc+CiAgICAgICAgICAgICAgPHQ+CiAgICAgICAgICAgICAgICBQYXJhbWV0ZXIgbmFt ZTogdG9rZW5fdHlwZQogICAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAgICA8dD4KICAgICAg ICAgICAgICAgIFBhcmFtZXRlciB1c2FnZSBsb2NhdGlvbjogYXV0aG9yaXphdGlvbiByZXNwb25z ZSwgdG9rZW4gcmVzcG9uc2UKICAgICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgICAgPHQ+CiAg ICAgICAgICAgICAgICBDaGFuZ2UgY29udHJvbGxlcjogSUVURgogICAgICAgICAgICAgIDwvdD4K ICAgICAgICAgICAgICA8dD4KICAgICAgICAgICAgICAgIFNwZWNpZmljYXRpb24gZG9jdW1lbnQo cyk6IFtbIHRoaXMgZG9jdW1lbnQgXV0KICAgICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgIDwv bGlzdD4KICAgICAgICAgIDwvdD4KICAgICAgICAgIDx0PgogICAgICAgICAgICA8bGlzdCBzdHls ZT0nc3ltYm9scyc+CiAgICAgICAgICAgICAgPHQ+CiAgICAgICAgICAgICAgICBQYXJhbWV0ZXIg bmFtZTogZXhwaXJlc19pbgogICAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAgICA8dD4KICAg ICAgICAgICAgICAgIFBhcmFtZXRlciB1c2FnZSBsb2NhdGlvbjogYXV0aG9yaXphdGlvbiByZXNw b25zZSwgdG9rZW4gcmVzcG9uc2UKICAgICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgICAgPHQ+ CiAgICAgICAgICAgICAgICBDaGFuZ2UgY29udHJvbGxlcjogSUVURgogICAgICAgICAgICAgIDwv dD4KICAgICAgICAgICAgICA8dD4KICAgICAgICAgICAgICAgIFNwZWNpZmljYXRpb24gZG9jdW1l bnQocyk6IFtbIHRoaXMgZG9jdW1lbnQgXV0KICAgICAgICAgICAgICA8L3Q+CiAgICAgICAgICAg IDwvbGlzdD4KICAgICAgICAgIDwvdD4KICAgICAgICAgIDx0PgogICAgICAgICAgICA8bGlzdCBz dHlsZT0nc3ltYm9scyc+CiAgICAgICAgICAgICAgPHQ+CiAgICAgICAgICAgICAgICBQYXJhbWV0 ZXIgbmFtZTogdXNlcm5hbWUKICAgICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgICAgPHQ+CiAg ICAgICAgICAgICAgICBQYXJhbWV0ZXIgdXNhZ2UgbG9jYXRpb246IHRva2VuIHJlcXVlc3QKICAg ICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgICAgPHQ+CiAgICAgICAgICAgICAgICBDaGFuZ2Ug Y29udHJvbGxlcjogSUVURgogICAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAgICA8dD4KICAg ICAgICAgICAgICAgIFNwZWNpZmljYXRpb24gZG9jdW1lbnQocyk6IFtbIHRoaXMgZG9jdW1lbnQg XV0KICAgICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgIDwvbGlzdD4KICAgICAgICAgIDwvdD4K ICAgICAgICAgIDx0PgogICAgICAgICAgICA8bGlzdCBzdHlsZT0nc3ltYm9scyc+CiAgICAgICAg ICAgICAgPHQ+CiAgICAgICAgICAgICAgICBQYXJhbWV0ZXIgbmFtZTogcGFzc3dvcmQKICAgICAg ICAgICAgICA8L3Q+CiAgICAgICAgICAgICAgPHQ+CiAgICAgICAgICAgICAgICBQYXJhbWV0ZXIg dXNhZ2UgbG9jYXRpb246IHRva2VuIHJlcXVlc3QKICAgICAgICAgICAgICA8L3Q+CiAgICAgICAg ICAgICAgPHQ+CiAgICAgICAgICAgICAgICBDaGFuZ2UgY29udHJvbGxlcjogSUVURgogICAgICAg ICAgICAgIDwvdD4KICAgICAgICAgICAgICA8dD4KICAgICAgICAgICAgICAgIFNwZWNpZmljYXRp b24gZG9jdW1lbnQocyk6IFtbIHRoaXMgZG9jdW1lbnQgXV0KICAgICAgICAgICAgICA8L3Q+CiAg ICAgICAgICAgIDwvbGlzdD4KICAgICAgICAgIDwvdD4KICAgICAgICAgIDx0PgogICAgICAgICAg ICA8bGlzdCBzdHlsZT0nc3ltYm9scyc+CiAgICAgICAgICAgICAgPHQ+CiAgICAgICAgICAgICAg ICBQYXJhbWV0ZXIgbmFtZTogcmVmcmVzaF90b2tlbgogICAgICAgICAgICAgIDwvdD4KICAgICAg ICAgICAgICA8dD4KICAgICAgICAgICAgICAgIFBhcmFtZXRlciB1c2FnZSBsb2NhdGlvbjogdG9r ZW4gcmVxdWVzdCwgdG9rZW4gcmVzcG9uc2UKICAgICAgICAgICAgICA8L3Q+CiAgICAgICAgICAg ICAgPHQ+CiAgICAgICAgICAgICAgICBDaGFuZ2UgY29udHJvbGxlcjogSUVURgogICAgICAgICAg ICAgIDwvdD4KICAgICAgICAgICAgICA8dD4KICAgICAgICAgICAgICAgIFNwZWNpZmljYXRpb24g ZG9jdW1lbnQocyk6IFtbIHRoaXMgZG9jdW1lbnQgXV0KICAgICAgICAgICAgICA8L3Q+CiAgICAg ICAgICAgIDwvbGlzdD4KICAgICAgICAgIDwvdD4KICAgICAgICA8L3NlY3Rpb24+CgogICAgICA8 L3NlY3Rpb24+CgogICAgICA8c2VjdGlvbiB0aXRsZT0nVGhlIE9BdXRoIEF1dGhvcml6YXRpb24g RW5kcG9pbnQgUmVzcG9uc2UgVHlwZSBSZWdpc3RyeScgYW5jaG9yPSdyZXNwb25zZS10eXBlLXJl Z2lzdHJ5Jz4KICAgICAgICA8dD4KICAgICAgICAgIFRoaXMgc3BlY2lmaWNhdGlvbiBlc3RhYmxp c2hlcyB0aGUgT0F1dGggYXV0aG9yaXphdGlvbiBlbmRwb2ludCByZXNwb25zZSB0eXBlIHJlZ2lz dHJ5LgogICAgICAgIDwvdD4KICAgICAgICA8dD4KICAgICAgICAgICAgQWRkaXRpb25hbCByZXNw b25zZSB0eXBlIGZvciB1c2Ugd2l0aCB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludCBhcmUgcmVn aXN0ZXJlZCB3aXRoIGEKICAgICAgICAgICAgU3BlY2lmaWNhdGlvbiBSZXF1aXJlZCAoPHhyZWYg dGFyZ2V0PSdSRkM1MjI2JyAvPikgYWZ0ZXIgYSB0d28gd2VlayByZXZpZXcgcGVyaW9kIG9uCiAg ICAgICAgICAgIHRoZSBbVEJEXUBpZXRmLm9yZyBtYWlsaW5nIGxpc3QsIG9uIHRoZSBhZHZpY2Ug b2Ygb25lIG9yIG1vcmUgRGVzaWduYXRlZCBFeHBlcnRzLgogICAgICAgICAgICBIb3dldmVyLCB0 byBhbGxvdyBmb3IgdGhlIGFsbG9jYXRpb24gb2YgdmFsdWVzIHByaW9yIHRvIHB1YmxpY2F0aW9u LCB0aGUgRGVzaWduYXRlZAogICAgICAgICAgICBFeHBlcnQocykgbWF5IGFwcHJvdmUgcmVnaXN0 cmF0aW9uIG9uY2UgdGhleSBhcmUgc2F0aXNmaWVkIHRoYXQgc3VjaCBhIHNwZWNpZmljYXRpb24K ICAgICAgICAgICAgd2lsbCBiZSBwdWJsaXNoZWQuCiAgICAgICAgICA8L3Q+CiAgICAgICAgICA8 dD4KICAgICAgICAgICAgUmVnaXN0cmF0aW9uIHJlcXVlc3RzIG11c3QgYmUgc2VudCB0byB0aGUg W1RCRF1AaWV0Zi5vcmcgbWFpbGluZyBsaXN0IGZvciByZXZpZXcgYW5kCiAgICAgICAgICAgIGNv bW1lbnQsIHdpdGggYW4gYXBwcm9wcmlhdGUgc3ViamVjdCAoZS5nLiwgIlJlcXVlc3QgZm9yIHJl c3BvbnNlIHR5cGU6IGV4YW1wbGUiKS4KICAgICAgICAgICAgW1sgTm90ZSB0byBSRkMtRURJVE9S OiBUaGUgbmFtZSBvZiB0aGUgbWFpbGluZyBsaXN0IHNob3VsZCBiZSBkZXRlcm1pbmVkIGluIGNv bnN1bHRhdGlvbgogICAgICAgICAgICB3aXRoIHRoZSBJRVNHIGFuZCBJQU5BLiBTdWdnZXN0ZWQg bmFtZTogb2F1dGgtZXh0LXJldmlldy4gXV0KICAgICAgICAgIDwvdD4KICAgICAgICAgIDx0Pgog ICAgICAgICAgICBXaXRoaW4gdGhlIHJldmlldyBwZXJpb2QsIHRoZSBEZXNpZ25hdGVkIEV4cGVy dChzKSB3aWxsIGVpdGhlciBhcHByb3ZlIG9yCiAgICAgICAgICAgIGRlbnkgdGhlIHJlZ2lzdHJh dGlvbiByZXF1ZXN0LCBjb21tdW5pY2F0aW5nIHRoaXMgZGVjaXNpb24gdG8gdGhlIHJldmlldyBs aXN0IGFuZCBJQU5BLgogICAgICAgICAgICBEZW5pYWxzIHNob3VsZCBpbmNsdWRlIGFuIGV4cGxh bmF0aW9uIGFuZCwgaWYgYXBwbGljYWJsZSwgc3VnZ2VzdGlvbnMgYXMgdG8gaG93IHRvIG1ha2UK ICAgICAgICAgICAgdGhlIHJlcXVlc3Qgc3VjY2Vzc2Z1bC4KICAgICAgICAgIDwvdD4KICAgICAg ICAgIDx0PgogICAgICAgICAgICBJQU5BIG11c3Qgb25seSBhY2NlcHQgcmVnaXN0cnkgdXBkYXRl cyBmcm9tIHRoZSBEZXNpZ25hdGVkIEV4cGVydChzKSwgYW5kIHNob3VsZCBkaXJlY3QKICAgICAg ICAgICAgYWxsIHJlcXVlc3RzIGZvciByZWdpc3RyYXRpb24gdG8gdGhlIHJldmlldyBtYWlsaW5n IGxpc3QuCiAgICAgICAgICA8L3Q+CgoKICAgICAgICAgIDxzZWN0aW9uIHRpdGxlPSdSZWdpc3Ry YXRpb24gVGVtcGxhdGUnPgogICAgICAgICAgPHQ+CiAgICAgICAgICAgIDxsaXN0IHN0eWxlPSdo YW5naW5nJz4KICAgICAgICAgICAgICA8dCBoYW5nVGV4dD0nUmVzcG9uc2UgdHlwZSBuYW1lOic+ CiAgICAgICAgICAgICAgICA8dnNwYWNlIC8+CiAgICAgICAgICAgICAgICBUaGUgbmFtZSByZXF1 ZXN0ZWQgKGUuZy4sICJleGFtcGxlIikuCiAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICAg IDx0IGhhbmdUZXh0PSdDaGFuZ2UgY29udHJvbGxlcjonPgogICAgICAgICAgICAgICAgPHZzcGFj ZSAvPgogICAgICAgICAgICAgICAgRm9yIHN0YW5kYXJkcy10cmFjayBSRkNzLCBzdGF0ZSAiSUVU RiIuIEZvciBvdGhlcnMsIGdpdmUgdGhlIG5hbWUgb2YgdGhlCiAgICAgICAgICAgICAgICByZXNw b25zaWJsZSBwYXJ0eS4gT3RoZXIgZGV0YWlscyAoZS5nLiwgcG9zdGFsIGFkZHJlc3MsIGUtbWFp bCBhZGRyZXNzLCBob21lIHBhZ2UKICAgICAgICAgICAgICAgIFVSSSkgbWF5IGFsc28gYmUgaW5j bHVkZWQuCiAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICAgIDx0IGhhbmdUZXh0PSdTcGVj aWZpY2F0aW9uIGRvY3VtZW50KHMpOic+CiAgICAgICAgICAgICAgICA8dnNwYWNlIC8+CiAgICAg ICAgICAgICAgICBSZWZlcmVuY2UgdG8gdGhlIGRvY3VtZW50IHRoYXQgc3BlY2lmaWVzIHRoZSB0 eXBlLCBwcmVmZXJhYmx5IGluY2x1ZGluZyBhIFVSSSB0aGF0CiAgICAgICAgICAgICAgICBjYW4g YmUgdXNlZCB0byByZXRyaWV2ZSBhIGNvcHkgb2YgdGhlIGRvY3VtZW50LiBBbiBpbmRpY2F0aW9u IG9mIHRoZSByZWxldmFudAogICAgICAgICAgICAgICAgc2VjdGlvbnMgbWF5IGFsc28gYmUgaW5j bHVkZWQsIGJ1dCBpcyBub3QgcmVxdWlyZWQuCiAgICAgICAgICAgICAgPC90PgogICAgICAgICAg ICA8L2xpc3Q+CiAgICAgICAgICA8L3Q+CiAgICAgICAgPC9zZWN0aW9uPgoKICAgICAgICA8c2Vj dGlvbiB0aXRsZT0nSW5pdGlhbCBSZWdpc3RyeSBDb250ZW50cyc+CiAgICAgICAgICA8dD4KICAg ICAgICAgICAgVGhlIE9BdXRoIEF1dGhvcml6YXRpb24gRW5kcG9pbnQgUmVzcG9uc2UgVHlwZSBS ZWdpc3RyeSdzIGluaXRpYWwgY29udGVudHMgYXJlOgogICAgICAgICAgPC90PgogICAgICAgICAg PHQ+CiAgICAgICAgICAgIDxsaXN0IHN0eWxlPSdzeW1ib2xzJz4KICAgICAgICAgICAgICA8dD4K ICAgICAgICAgICAgICAgIFJlc3BvbnNlIHR5cGUgbmFtZTogY29kZQogICAgICAgICAgICAgIDwv dD4KICAgICAgICAgICAgICA8dD4KICAgICAgICAgICAgICAgIENoYW5nZSBjb250cm9sbGVyOiBJ RVRGCiAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICAgIDx0PgogICAgICAgICAgICAgICAg U3BlY2lmaWNhdGlvbiBkb2N1bWVudChzKTogW1sgdGhpcyBkb2N1bWVudCBdXQogICAgICAgICAg ICAgIDwvdD4KICAgICAgICAgICAgPC9saXN0PgogICAgICAgICAgPC90PgogICAgICAgICAgPHQ+ CiAgICAgICAgICAgIDxsaXN0IHN0eWxlPSdzeW1ib2xzJz4KICAgICAgICAgICAgICA8dD4KICAg ICAgICAgICAgICAgIFJlc3BvbnNlIHR5cGUgbmFtZTogdG9rZW4KICAgICAgICAgICAgICA8L3Q+ CiAgICAgICAgICAgICAgPHQ+CiAgICAgICAgICAgICAgICBDaGFuZ2UgY29udHJvbGxlcjogSUVU RgogICAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAgICA8dD4KICAgICAgICAgICAgICAgIFNw ZWNpZmljYXRpb24gZG9jdW1lbnQocyk6IFtbIHRoaXMgZG9jdW1lbnQgXV0KICAgICAgICAgICAg ICA8L3Q+CiAgICAgICAgICAgIDwvbGlzdD4KICAgICAgICAgIDwvdD4KICAgICAgICA8L3NlY3Rp b24+CgogICAgICA8L3NlY3Rpb24+CgogICAgICA8c2VjdGlvbiB0aXRsZT0nVGhlIE9BdXRoIEV4 dGVuc2lvbnMgRXJyb3IgUmVnaXN0cnknIGFuY2hvcj0nZXJyb3ItcmVnaXN0cnknPgogICAgICAg IDx0PgogICAgICAgICAgVGhpcyBzcGVjaWZpY2F0aW9uIGVzdGFibGlzaGVzIHRoZSBPQXV0aCBl eHRlbnNpb25zIGVycm9yIHJlZ2lzdHJ5LgogICAgICAgIDwvdD4KICAgICAgICA8dD4KICAgICAg ICAgIEFkZGl0aW9uYWwgZXJyb3IgY29kZXMgdXNlZCB0b2dldGhlciB3aXRoIG90aGVyIHByb3Rv Y29sIGV4dGVuc2lvbnMgKGkuZS4gZXh0ZW5zaW9uIGdyYW50CiAgICAgICAgICB0eXBlcywgYWNj ZXNzIHRva2VuIHR5cGVzLCBvciBleHRlbnNpb24gcGFyYW1ldGVycykgYXJlIHJlZ2lzdGVyZWQg d2l0aCBhIFNwZWNpZmljYXRpb24KICAgICAgICAgIFJlcXVpcmVkICg8eHJlZiB0YXJnZXQ9J1JG QzUyMjYnIC8+KSBhZnRlciBhIHR3byB3ZWVrIHJldmlldyBwZXJpb2Qgb24gdGhlCiAgICAgICAg ICBbVEJEXUBpZXRmLm9yZyBtYWlsaW5nIGxpc3QsIG9uIHRoZSBhZHZpY2Ugb2Ygb25lIG9yIG1v cmUgRGVzaWduYXRlZCBFeHBlcnRzLiBIb3dldmVyLCB0bwogICAgICAgICAgYWxsb3cgZm9yIHRo ZSBhbGxvY2F0aW9uIG9mIHZhbHVlcyBwcmlvciB0byBwdWJsaWNhdGlvbiwgdGhlIERlc2lnbmF0 ZWQgRXhwZXJ0KHMpIG1heQogICAgICAgICAgYXBwcm92ZSByZWdpc3RyYXRpb24gb25jZSB0aGV5 IGFyZSBzYXRpc2ZpZWQgdGhhdCBzdWNoIGEgc3BlY2lmaWNhdGlvbiB3aWxsIGJlIHB1Ymxpc2hl ZC4KICAgICAgICA8L3Q+CiAgICAgICAgPHQ+CiAgICAgICAgICBSZWdpc3RyYXRpb24gcmVxdWVz dHMgbXVzdCBiZSBzZW50IHRvIHRoZSBbVEJEXUBpZXRmLm9yZyBtYWlsaW5nIGxpc3QgZm9yIHJl dmlldyBhbmQKICAgICAgICAgIGNvbW1lbnQsIHdpdGggYW4gYXBwcm9wcmlhdGUgc3ViamVjdCAo ZS5nLiwgIlJlcXVlc3QgZm9yIGVycm9yIGNvZGU6IGV4YW1wbGUiKS4KICAgICAgICAgIFtbIE5v dGUgdG8gUkZDLUVESVRPUjogVGhlIG5hbWUgb2YgdGhlIG1haWxpbmcgbGlzdCBzaG91bGQgYmUg ZGV0ZXJtaW5lZCBpbiBjb25zdWx0YXRpb24KICAgICAgICAgIHdpdGggdGhlIElFU0cgYW5kIElB TkEuIFN1Z2dlc3RlZCBuYW1lOiBvYXV0aC1leHQtcmV2aWV3LiBdXQogICAgICAgIDwvdD4KICAg ICAgICA8dD4KICAgICAgICAgIFdpdGhpbiB0aGUgcmV2aWV3IHBlcmlvZCwgdGhlIERlc2lnbmF0 ZWQgRXhwZXJ0KHMpIHdpbGwgZWl0aGVyIGFwcHJvdmUgb3IKICAgICAgICAgIGRlbnkgdGhlIHJl Z2lzdHJhdGlvbiByZXF1ZXN0LCBjb21tdW5pY2F0aW5nIHRoaXMgZGVjaXNpb24gdG8gdGhlIHJl dmlldyBsaXN0IGFuZCBJQU5BLgogICAgICAgICAgRGVuaWFscyBzaG91bGQgaW5jbHVkZSBhbiBl eHBsYW5hdGlvbiBhbmQsIGlmIGFwcGxpY2FibGUsIHN1Z2dlc3Rpb25zIGFzIHRvIGhvdyB0byBt YWtlCiAgICAgICAgICB0aGUgcmVxdWVzdCBzdWNjZXNzZnVsLgogICAgICAgIDwvdD4KICAgICAg ICA8dD4KICAgICAgICAgIElBTkEgbXVzdCBvbmx5IGFjY2VwdCByZWdpc3RyeSB1cGRhdGVzIGZy b20gdGhlIERlc2lnbmF0ZWQgRXhwZXJ0KHMpLCBhbmQgc2hvdWxkIGRpcmVjdAogICAgICAgICAg YWxsIHJlcXVlc3RzIGZvciByZWdpc3RyYXRpb24gdG8gdGhlIHJldmlldyBtYWlsaW5nIGxpc3Qu CiAgICAgICAgPC90PgoKCiAgICAgICAgPHNlY3Rpb24gdGl0bGU9J1JlZ2lzdHJhdGlvbiBUZW1w bGF0ZSc+CiAgICAgICAgICA8dD4KICAgICAgICAgICAgPGxpc3Qgc3R5bGU9J2hhbmdpbmcnPgog ICAgICAgICAgICAgIDx0IGhhbmdUZXh0PSdFcnJvciBuYW1lOic+CiAgICAgICAgICAgICAgICA8 dnNwYWNlIC8+CiAgICAgICAgICAgICAgICBUaGUgbmFtZSByZXF1ZXN0ZWQgKGUuZy4sICJleGFt cGxlIikuCgkJVmFsdWVzIGZvciB0aGUgZXJyb3IgbmFtZSBNVVNUIE5PVCBpbmNsdWRlCgkJY2hh cmFjdGVycyBvdXRzaWRlIHRoZSBzZXQgJXgyMC0yMSAvICV4MjMtNUIgLyAleDVELTdFLgogICAg ICAgICAgICAgIDwvdD4KICAgICAgICAgICAgICA8dCBoYW5nVGV4dD0nRXJyb3IgdXNhZ2UgbG9j YXRpb246Jz4KICAgICAgICAgICAgICAgIDx2c3BhY2UgLz4KICAgICAgICAgICAgICAgIFRoZSBs b2NhdGlvbihzKSB3aGVyZSB0aGUgZXJyb3IgY2FuIGJlIHVzZWQuIFRoZSBwb3NzaWJsZSBsb2Nh dGlvbnMgYXJlOgogICAgICAgICAgICAgICAgYXV0aG9yaXphdGlvbiBjb2RlIGdyYW50IGVycm9y IHJlc3BvbnNlICg8eHJlZiB0YXJnZXQ9J2NvZGUtYXV0aHotZXJyb3InIC8+KSwKICAgICAgICAg ICAgICAgIGltcGxpY2l0IGdyYW50IGVycm9yIHJlc3BvbnNlICg8eHJlZiB0YXJnZXQ9J2ltcGxp Y2l0LWF1dGh6LWVycm9yJyAvPiksCgkJdG9rZW4gZXJyb3IgcmVzcG9uc2UgKDx4cmVmIHRhcmdl dD0ndG9rZW4tZXJyb3JzJyAvPiksIG9yCgkJcmVzb3VyY2UgYWNjZXNzIGVycm9yIHJlc3BvbnNl ICg8eHJlZiB0YXJnZXQ9J3Jlc291cmNlLWVycm9ycycgLz4pLgogICAgICAgICAgICAgIDwvdD4K ICAgICAgICAgICAgICA8dCBoYW5nVGV4dD0nUmVsYXRlZCBwcm90b2NvbCBleHRlbnNpb246Jz4K ICAgICAgICAgICAgICAgIDx2c3BhY2UgLz4KICAgICAgICAgICAgICAgIFRoZSBuYW1lIG9mIHRo ZSBleHRlbnNpb24gZ3JhbnQgdHlwZSwgYWNjZXNzIHRva2VuIHR5cGUsIG9yIGV4dGVuc2lvbiBw YXJhbWV0ZXIsCiAgICAgICAgICAgICAgICB0aGUgZXJyb3IgY29kZSBpcyB1c2VkIGluIGNvbmp1 bmN0aW9uIHdpdGguCiAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICAgIDx0IGhhbmdUZXh0 PSdDaGFuZ2UgY29udHJvbGxlcjonPgogICAgICAgICAgICAgICAgPHZzcGFjZSAvPgogICAgICAg ICAgICAgICAgRm9yIHN0YW5kYXJkcy10cmFjayBSRkNzLCBzdGF0ZSAiSUVURiIuIEZvciBvdGhl cnMsIGdpdmUgdGhlIG5hbWUgb2YgdGhlCiAgICAgICAgICAgICAgICByZXNwb25zaWJsZSBwYXJ0 eS4gT3RoZXIgZGV0YWlscyAoZS5nLiwgcG9zdGFsIGFkZHJlc3MsIGUtbWFpbCBhZGRyZXNzLCBo b21lIHBhZ2UKICAgICAgICAgICAgICAgIFVSSSkgbWF5IGFsc28gYmUgaW5jbHVkZWQuCiAgICAg ICAgICAgICAgPC90PgogICAgICAgICAgICAgIDx0IGhhbmdUZXh0PSdTcGVjaWZpY2F0aW9uIGRv Y3VtZW50KHMpOic+CiAgICAgICAgICAgICAgICA8dnNwYWNlIC8+CiAgICAgICAgICAgICAgICBS ZWZlcmVuY2UgdG8gdGhlIGRvY3VtZW50IHRoYXQgc3BlY2lmaWVzIHRoZSBlcnJvciBjb2RlLCBw cmVmZXJhYmx5IGluY2x1ZGluZyBhIFVSSQogICAgICAgICAgICAgICAgdGhhdCBjYW4gYmUgdXNl ZCB0byByZXRyaWV2ZSBhIGNvcHkgb2YgdGhlIGRvY3VtZW50LiBBbiBpbmRpY2F0aW9uIG9mIHRo ZSByZWxldmFudAogICAgICAgICAgICAgICAgc2VjdGlvbnMgbWF5IGFsc28gYmUgaW5jbHVkZWQs IGJ1dCBpcyBub3QgcmVxdWlyZWQuCiAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICA8L2xp c3Q+CiAgICAgICAgICA8L3Q+CiAgICAgICAgPC9zZWN0aW9uPgoKICAgICAgPC9zZWN0aW9uPgoK ICAgIDwvc2VjdGlvbj4KCiAgPC9taWRkbGU+CgogIDxiYWNrPgoKICAgIDxyZWZlcmVuY2VzIHRp dGxlPSdOb3JtYXRpdmUgUmVmZXJlbmNlcyc+CgogICAgICA8P3JmYyBpbmNsdWRlPSdodHRwOi8v eG1sLnJlc291cmNlLm9yZy9wdWJsaWMvcmZjL2JpYnhtbC9yZWZlcmVuY2UuUkZDLjIxMTkueG1s JyA/PgogICAgICA8P3JmYyBpbmNsdWRlPSdodHRwOi8veG1sLnJlc291cmNlLm9yZy9wdWJsaWMv cmZjL2JpYnhtbC9yZWZlcmVuY2UuUkZDLjIyNDYueG1sJyA/PgogICAgICA8P3JmYyBpbmNsdWRl PSdodHRwOi8veG1sLnJlc291cmNlLm9yZy9wdWJsaWMvcmZjL2JpYnhtbC9yZWZlcmVuY2UuUkZD LjI2MTYueG1sJyA/PgogICAgICA8P3JmYyBpbmNsdWRlPSdodHRwOi8veG1sLnJlc291cmNlLm9y Zy9wdWJsaWMvcmZjL2JpYnhtbC9yZWZlcmVuY2UuUkZDLjI2MTcueG1sJyA/PgogICAgICA8P3Jm YyBpbmNsdWRlPSdodHRwOi8veG1sLnJlc291cmNlLm9yZy9wdWJsaWMvcmZjL2JpYnhtbC9yZWZl cmVuY2UuUkZDLjI4MTgueG1sJyA/PgogICAgICA8P3JmYyBpbmNsdWRlPSdodHRwOi8veG1sLnJl c291cmNlLm9yZy9wdWJsaWMvcmZjL2JpYnhtbC9yZWZlcmVuY2UuUkZDLjM5ODYueG1sJyA/Pgog ICAgICA8P3JmYyBpbmNsdWRlPSdodHRwOi8veG1sLnJlc291cmNlLm9yZy9wdWJsaWMvcmZjL2Jp YnhtbC9yZWZlcmVuY2UuUkZDLjQ2MjcueG1sJyA/PgogICAgICA8P3JmYyBpbmNsdWRlPSdodHRw Oi8veG1sLnJlc291cmNlLm9yZy9wdWJsaWMvcmZjL2JpYnhtbC9yZWZlcmVuY2UuUkZDLjQ5NDku eG1sJyA/PgogICAgICA8P3JmYyBpbmNsdWRlPSdodHRwOi8veG1sLnJlc291cmNlLm9yZy9wdWJs aWMvcmZjL2JpYnhtbC9yZWZlcmVuY2UuUkZDLjUyMjYueG1sJyA/PgogICAgICA8P3JmYyBpbmNs dWRlPSdodHRwOi8veG1sLnJlc291cmNlLm9yZy9wdWJsaWMvcmZjL2JpYnhtbC9yZWZlcmVuY2Uu UkZDLjUyMzQueG1sJyA/PgogICAgICA8P3JmYyBpbmNsdWRlPSdodHRwOi8veG1sLnJlc291cmNl Lm9yZy9wdWJsaWMvcmZjL2JpYnhtbC9yZWZlcmVuY2UuUkZDLjUyNDYueG1sJyA/PgogICAgICA8 P3JmYyBpbmNsdWRlPSdodHRwOi8veG1sLnJlc291cmNlLm9yZy9wdWJsaWMvcmZjL2JpYnhtbC9y ZWZlcmVuY2UuUkZDLjYxMjUueG1sJyA/PgogICAgICA8P3JmYyBpbmNsdWRlPSdodHRwOi8veG1s LnJlc291cmNlLm9yZy9wdWJsaWMvcmZjL2JpYnhtbDQvcmVmZXJlbmNlLlczQy5SRUMtaHRtbDQw MS0xOTk5MTIyNC54bWwnID8+CgogICAgICA8cmVmZXJlbmNlIGFuY2hvcj0iVVNBU0NJSSI+Cgk8 ZnJvbnQ+CgkgIDx0aXRsZT5Db2RlZCBDaGFyYWN0ZXIgU2V0IC0tIDctYml0IEFtZXJpY2FuIFN0 YW5kYXJkIENvZGUgZm9yIEluZm9ybWF0aW9uIEludGVyY2hhbmdlPC90aXRsZT4KCSAgPGF1dGhv cj4KCSAgICA8b3JnYW5pemF0aW9uPkFtZXJpY2FuIE5hdGlvbmFsIFN0YW5kYXJkcyBJbnN0aXR1 dGU8L29yZ2FuaXphdGlvbj4KCSAgPC9hdXRob3I+CgkgIDxkYXRlIHllYXI9IjE5ODYiLz4KCTwv ZnJvbnQ+Cgk8c2VyaWVzSW5mbyBuYW1lPSJBTlNJIiB2YWx1ZT0iWDMuNCIvPgogICAgICA8L3Jl ZmVyZW5jZT4KCiAgICA8L3JlZmVyZW5jZXM+CgogICAgPHJlZmVyZW5jZXMgdGl0bGU9J0luZm9y bWF0aXZlIFJlZmVyZW5jZXMnPgoKICAgICAgPD9yZmMgaW5jbHVkZT0naHR0cDovL3htbC5yZXNv dXJjZS5vcmcvcHVibGljL3JmYy9iaWJ4bWwvcmVmZXJlbmNlLlJGQy41ODQ5LnhtbCcgPz4KICAg ICAgPD9yZmMgaW5jbHVkZT0naHR0cDovL3htbC5yZXNvdXJjZS5vcmcvcHVibGljL3JmYy9iaWJ4 bWwzL3JlZmVyZW5jZS5JLUQuZHJhZnQtaWV0Zi1vYXV0aC12Mi1iZWFyZXItMjAueG1sJyA/Pgog ICAgICA8P3JmYyBpbmNsdWRlPSdodHRwOi8veG1sLnJlc291cmNlLm9yZy9wdWJsaWMvcmZjL2Jp YnhtbDMvcmVmZXJlbmNlLkktRC5kcmFmdC1pZXRmLW9hdXRoLXNhbWwyLWJlYXJlci0xMi54bWwn ID8+CiAgICAgIDw/cmZjIGluY2x1ZGU9J2h0dHA6Ly94bWwucmVzb3VyY2Uub3JnL3B1YmxpYy9y ZmMvYmlieG1sMy9yZWZlcmVuY2UuSS1ELmRyYWZ0LWlldGYtb2F1dGgtdjItaHR0cC1tYWMtMDEu eG1sJyA/PgogICAgICA8P3JmYyBpbmNsdWRlPSdodHRwOi8veG1sLnJlc291cmNlLm9yZy9wdWJs aWMvcmZjL2JpYnhtbDMvcmVmZXJlbmNlLkktRC5kcmFmdC1pZXRmLW9hdXRoLXYyLXRocmVhdG1v ZGVsLTA1LnhtbCcgPz4KCiAgICAgIDw/cmZjIGluY2x1ZGU9J2h0dHA6Ly94bWwucmVzb3VyY2Uu b3JnL3B1YmxpYy9yZmMvYmlieG1sMy9yZWZlcmVuY2UuSS1ELmRyYWZ0LWlldGYtaHR0cGJpcy1w Ny1hdXRoLTE5LnhtbCc/PgoKICAgICAgPHJlZmVyZW5jZSBhbmNob3I9IkktRC5kcmFmdC1oYXJk dC1vYXV0aC0wMSI+CiAgICAgICAgPGZyb250PgogICAgICAgICAgPHRpdGxlPk9BdXRoIFdlYiBS ZXNvdXJjZSBBdXRob3JpemF0aW9uIFByb2ZpbGVzPC90aXRsZT4KICAgICAgICAgIDxhdXRob3Ig aW5pdGlhbHM9IkQiIHN1cm5hbWU9IkhhcmR0IiBmdWxsbmFtZT0iRGljayBIYXJkdCIgcm9sZT0i ZWRpdG9yIiAvPgogICAgICAgICAgPGF1dGhvciBpbml0aWFscz0iQSIgc3VybmFtZT0iVG9tIiBm dWxsbmFtZT0iQWxsZW4gVG9tIiAvPgogICAgICAgICAgPGF1dGhvciBpbml0aWFscz0iQiIgc3Vy bmFtZT0iRWF0b24iIGZ1bGxuYW1lPSJCcmlhbiBFYXRvbiIgLz4KICAgICAgICAgIDxhdXRob3Ig aW5pdGlhbHM9IlkiIHN1cm5hbWU9IkdvbGFuZCIgZnVsbG5hbWU9Illhcm9uIEdvbGFuZCIgLz4K ICAgICAgICAgIDxkYXRlIG1vbnRoPSJKYW51YXJ5IiBkYXk9IjE1IiB5ZWFyPSIyMDEwIiAvPgog ICAgICAgIDwvZnJvbnQ+CiAgICAgICAgPGZvcm1hdCB0YXJnZXQ9Imh0dHA6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWhhcmR0LW9hdXRoLTAxIiB0eXBlPSJIVE1MIiAvPgogICAgICA8L3Jl ZmVyZW5jZT4KCiAgICA8L3JlZmVyZW5jZXM+CgogICAgPHNlY3Rpb24gdGl0bGU9IkF1Z21lbnRl ZCBCYWNrdXMtTmF1ciBGb3JtIChBQk5GKSBTeW50YXgiPgogICAgICA8dD4KCVRoaXMgc2VjdGlv biBwcm92aWRlcyBBdWdtZW50ZWQgQmFja3VzLU5hdXIgRm9ybSAoQUJORikgc3ludGF4CglkZXNj cmlwdGlvbnMgZm9yIHRoZSBlbGVtZW50cyBkZWZpbmVkIGluIHRoaXMgc3BlY2lmaWNhdGlvbgoJ dXNpbmcgdGhlIG5vdGF0aW9uIG9mIDx4cmVmIHRhcmdldD0nUkZDNTIzNCcgLz4uCglFbGVtZW50 cyBhcmUgcHJlc2VudGVkIGluIHRoZSBvcmRlciBmaXJzdCBkZWZpbmVkLgogICAgICA8L3Q+CiAg ICAgIDx0PgoJU29tZSBvZiB0aGUgZGVmaW5pdGlvbnMgdGhhdCBmb2xsb3cgdXNlIHRoZQoJPHNw YW54IHN0eWxlPSd2ZXJiJz5VUkktcmVmZXJlbmNlPC9zcGFueD4KCWRlZmluaXRpb24gZnJvbSA8 eHJlZiB0YXJnZXQ9IlJGQzM5ODYiLz4uCiAgICAgIDwvdD4KCiAgICAgIDxmaWd1cmU+Cgk8cHJl YW1ibGU+CgkgIFNvbWUgb2YgdGhlIGRlZmluaXRpb25zIHRoYXQgZm9sbG93IHVzZSB0aGVzZSBj b21tb24gZGVmaW5pdGlvbnM6Cgk8L3ByZWFtYmxlPgoJPGFydHdvcms+PCFbQ0RBVEFbClZTQ0hB UiAgICAgPSAlMjAtN0UKTlFDSEFSICAgICA9ICV4MjEgLyAleDIzLTVCIC8gJXg1RC03RQpOUVND SEFSICAgID0gJXgyMC0yMSAvICV4MjMtNUIgLyAleDVELTdFClVOSUNPREVOT0NUUkxDSEFSID0g PEFueSBVbmljb2RlIGNoYXJhY3RlciBvdGhlciB0aGFuICggJXgwLTFGIC8gJXg3RiApPgpdXT48 L2FydHdvcms+CiAgICAgIDwvZmlndXJlPgoKICAgICAgPHNlY3Rpb24gdGl0bGU9JyJjbGllbnRf aWQiIFN5bnRheCc+CgoJPGZpZ3VyZT4KCSAgPHByZWFtYmxlPgoJICAgIFRoZSA8c3Bhbnggc3R5 bGU9J3ZlcmInPmNsaWVudF9pZDwvc3Bhbng+IGVsZW1lbnQgaXMgZGVmaW5lZCBpbgoJICAgIDx4 cmVmIHRhcmdldD0iY2xpZW50LXBhc3N3b3JkIi8+OgoJICA8L3ByZWFtYmxlPgoJICA8YXJ0d29y az48IVtDREFUQVsKY2xpZW50LWlkICAgICA9ICpWU0NIQVIKXV0+PC9hcnR3b3JrPgoJPC9maWd1 cmU+CiAgICAgIDwvc2VjdGlvbj4KCiAgICAgIDxzZWN0aW9uIHRpdGxlPSciY2xpZW50X3NlY3Jl dCIgU3ludGF4Jz4KCgk8ZmlndXJlPgoJICA8cHJlYW1ibGU+CgkgICAgVGhlIDxzcGFueCBzdHls ZT0ndmVyYic+Y2xpZW50X3NlY3JldDwvc3Bhbng+IGVsZW1lbnQgaXMgZGVmaW5lZCBpbgoJICAg IDx4cmVmIHRhcmdldD0iY2xpZW50LXBhc3N3b3JkIi8+OgoJICA8L3ByZWFtYmxlPgoJICA8YXJ0 d29yaz48IVtDREFUQVsKY2xpZW50LXNlY3JldCA9ICpWU0NIQVIKXV0+PC9hcnR3b3JrPgoJPC9m aWd1cmU+CiAgICAgIDwvc2VjdGlvbj4KCiAgICAgIDxzZWN0aW9uIHRpdGxlPScicmVzcG9uc2Vf dHlwZSIgU3ludGF4Jz4KCgk8ZmlndXJlPgoJICA8cHJlYW1ibGU+CgkgICAgVGhlIDxzcGFueCBz dHlsZT0ndmVyYic+cmVzcG9uc2VfdHlwZTwvc3Bhbng+IGVsZW1lbnQgaXMgZGVmaW5lZCBpbgoJ ICAgIDx4cmVmIHRhcmdldD0icmVzcG9uc2UtdHlwZSIvPiBhbmQKCSAgICA8eHJlZiB0YXJnZXQ9 InJlc3BvbnNlLXR5cGUtZXh0Ii8+OgoJICA8L3ByZWFtYmxlPgoJICA8YXJ0d29yaz48IVtDREFU QVsKcmVzcG9uc2UtdHlwZSA9IHJlc3BvbnNlLW5hbWUgKiggU1AgcmVzcG9uc2UtbmFtZSApCnJl c3BvbnNlLW5hbWUgPSAxKnJlc3BvbnNlLWNoYXIKcmVzcG9uc2UtY2hhciA9ICJfIiAvIERJR0lU IC8gQUxQSEEKXV0+PC9hcnR3b3JrPgoJPC9maWd1cmU+CiAgICAgIDwvc2VjdGlvbj4KCiAgICAg IDxzZWN0aW9uIHRpdGxlPScic2NvcGUiIFN5bnRheCc+CgoJPGZpZ3VyZT4KCSAgPHByZWFtYmxl PgoJICAgIFRoZSA8c3Bhbnggc3R5bGU9J3ZlcmInPnNjb3BlPC9zcGFueD4gZWxlbWVudCBpcyBk ZWZpbmVkIGluCgkgICAgPHhyZWYgdGFyZ2V0PSJzY29wZSIvPjoKCSAgPC9wcmVhbWJsZT4KCSAg PGFydHdvcms+PCFbQ0RBVEFbCnNjb3BlICAgICAgID0gc2NvcGUtdG9rZW4gKiggU1Agc2NvcGUt dG9rZW4gKQpzY29wZS10b2tlbiA9IDEqTlFDSEFSCl1dPjwvYXJ0d29yaz4KCTwvZmlndXJlPgog ICAgICA8L3NlY3Rpb24+CgogICAgICA8c2VjdGlvbiB0aXRsZT0nInN0YXRlIiBTeW50YXgnPgoK CTxmaWd1cmU+CgkgIDxwcmVhbWJsZT4KCSAgICBUaGUgPHNwYW54IHN0eWxlPSd2ZXJiJz5zdGF0 ZTwvc3Bhbng+IGVsZW1lbnQgaXMgZGVmaW5lZCBpbgoJICAgIDx4cmVmIHRhcmdldD0iY29kZS1h dXRoei1yZXEiLz4sCgkgICAgPHhyZWYgdGFyZ2V0PSJjb2RlLWF1dGh6LXJlc3AiLz4sCgkgICAg PHhyZWYgdGFyZ2V0PSJjb2RlLWF1dGh6LWVycm9yIi8+LAoJICAgIDx4cmVmIHRhcmdldD0iaW1w bGljaXQtYXV0aHotcmVxIi8+LAoJICAgIDx4cmVmIHRhcmdldD0iaW1wbGljaXQtYXV0aHotcmVz cCIvPiwgYW5kCgkgICAgPHhyZWYgdGFyZ2V0PSJpbXBsaWNpdC1hdXRoei1lcnJvciIvPjoKCSAg PC9wcmVhbWJsZT4KCSAgPGFydHdvcms+PCFbQ0RBVEFbCnN0YXRlICAgICAgPSAxKlZTQ0hBUgpd XT48L2FydHdvcms+Cgk8L2ZpZ3VyZT4KICAgICAgPC9zZWN0aW9uPgoKICAgICAgPHNlY3Rpb24g dGl0bGU9JyJyZWRpcmVjdF91cmkiIFN5bnRheCc+CgoJPGZpZ3VyZT4KCSAgPHByZWFtYmxlPgoJ ICAgIFRoZSA8c3Bhbnggc3R5bGU9J3ZlcmInPnJlZGlyZWN0X3VyaTwvc3Bhbng+IGVsZW1lbnQg aXMgZGVmaW5lZCBpbgoJICAgIDx4cmVmIHRhcmdldD0iY29kZS1hdXRoei1yZXEiLz4sCgkgICAg PHhyZWYgdGFyZ2V0PSJ0b2tlbi1yZXEiLz4sIGFuZAoJICAgIDx4cmVmIHRhcmdldD0iaW1wbGlj aXQtYXV0aHotcmVxIi8+OgoJICA8L3ByZWFtYmxlPgoJICA8YXJ0d29yaz48IVtDREFUQVsKcmVk aXJlY3QtdXJpICAgICAgPSBVUkktcmVmZXJlbmNlCl1dPjwvYXJ0d29yaz4KCTwvZmlndXJlPgog ICAgICA8L3NlY3Rpb24+CgogICAgICA8c2VjdGlvbiB0aXRsZT0nImVycm9yIiBTeW50YXgnPgoK CTxmaWd1cmU+CgkgIDxwcmVhbWJsZT4KCSAgICBUaGUgPHNwYW54IHN0eWxlPSd2ZXJiJz5lcnJv cjwvc3Bhbng+IGVsZW1lbnQgaXMgZGVmaW5lZCBpbgoJICAgIDx4cmVmIHRhcmdldD0iY29kZS1h dXRoei1lcnJvciIvPiwKCSAgICA8eHJlZiB0YXJnZXQ9J2ltcGxpY2l0LWF1dGh6LWVycm9yJy8+ LAoJICAgIDx4cmVmIHRhcmdldD0ndG9rZW4tZXJyb3JzJy8+LAoJICAgIDx4cmVmIHRhcmdldD0n cmVzb3VyY2UtZXJyb3JzJy8+LCBhbmQKCSAgICA8eHJlZiB0YXJnZXQ9Im5ldy1lcnJvcnMiLz46 CgkgIDwvcHJlYW1ibGU+CgkgIDxhcnR3b3JrPjwhW0NEQVRBWwplcnJvciAgICAgICAgICAgICA9 IDEqTlFTQ0hBUgpdXT48L2FydHdvcms+Cgk8L2ZpZ3VyZT4KICAgICAgPC9zZWN0aW9uPgoKICAg ICAgPHNlY3Rpb24gdGl0bGU9JyJlcnJvcl9kZXNjcmlwdGlvbiIgU3ludGF4Jz4KCgk8ZmlndXJl PgoJICA8cHJlYW1ibGU+CgkgICAgVGhlIDxzcGFueCBzdHlsZT0ndmVyYic+ZXJyb3JfZGVzY3Jp cHRpb248L3NwYW54PiBlbGVtZW50IGlzIGRlZmluZWQgaW4KCSAgICA8eHJlZiB0YXJnZXQ9ImNv ZGUtYXV0aHotZXJyb3IiLz4sCgkgICAgPHhyZWYgdGFyZ2V0PSdpbXBsaWNpdC1hdXRoei1lcnJv cicvPiwKCSAgICA8eHJlZiB0YXJnZXQ9J3Rva2VuLWVycm9ycycvPiwgYW5kCgkgICAgPHhyZWYg dGFyZ2V0PSdyZXNvdXJjZS1lcnJvcnMnLz46CgkgIDwvcHJlYW1ibGU+CgkgIDxhcnR3b3JrPjwh W0NEQVRBWwplcnJvci1kZXNjcmlwdGlvbiA9IDEqTlFTQ0hBUgpdXT48L2FydHdvcms+Cgk8L2Zp Z3VyZT4KICAgICAgPC9zZWN0aW9uPgoKICAgICAgPHNlY3Rpb24gdGl0bGU9JyJlcnJvcl91cmki IFN5bnRheCc+CgoJPGZpZ3VyZT4KCSAgPHByZWFtYmxlPgoJICAgIFRoZSA8c3Bhbnggc3R5bGU9 J3ZlcmInPmVycm9yX3VyaTwvc3Bhbng+IGVsZW1lbnQgaXMgZGVmaW5lZCBpbgoJICAgIDx4cmVm IHRhcmdldD0iY29kZS1hdXRoei1lcnJvciIvPiwKCSAgICA8eHJlZiB0YXJnZXQ9J2ltcGxpY2l0 LWF1dGh6LWVycm9yJy8+LAoJICAgIDx4cmVmIHRhcmdldD0ndG9rZW4tZXJyb3JzJy8+LCBhbmQK CSAgICA8eHJlZiB0YXJnZXQ9J3Jlc291cmNlLWVycm9ycycvPjoKCSAgPC9wcmVhbWJsZT4KCSAg PGFydHdvcms+PCFbQ0RBVEFbCmVycm9yLXVyaSAgICAgICAgID0gVVJJLXJlZmVyZW5jZQpdXT48 L2FydHdvcms+Cgk8L2ZpZ3VyZT4KICAgICAgPC9zZWN0aW9uPgoKICAgICAgPHNlY3Rpb24gdGl0 bGU9JyJncmFudF90eXBlIiBTeW50YXgnPgoKCTxmaWd1cmU+CgkgIDxwcmVhbWJsZT4KCSAgICBU aGUgPHNwYW54IHN0eWxlPSd2ZXJiJz5ncmFudF90eXBlPC9zcGFueD4gZWxlbWVudCBpcyBkZWZp bmVkIGluCgkgICAgPHhyZWYgdGFyZ2V0PSJ0b2tlbi1yZXEiLz4sCgkgICAgPHhyZWYgdGFyZ2V0 PSdwYXNzd29yZC10b2stcmVxJy8+LAoJICAgIDx4cmVmIHRhcmdldD0nY2xpZW50LXJlcScvPiwK CSAgICA8eHJlZiB0YXJnZXQ9InRva2VuLXJlZnJlc2giLz4sIGFuZAoJICAgIDx4cmVmIHRhcmdl dD0nZXh0LWdyYW50Jy8+OgoJICA8L3ByZWFtYmxlPgoJICA8YXJ0d29yaz48IVtDREFUQVsKZ3Jh bnQtdHlwZSA9IGdyYW50LW5hbWUgLyBVUkktcmVmZXJlbmNlCmdyYW50LW5hbWUgPSAxKm5hbWUt Y2hhcgpuYW1lLWNoYXIgID0gIi0iIC8gIi4iIC8gIl8iIC8gRElHSVQgLyBBTFBIQQpdXT48L2Fy dHdvcms+Cgk8L2ZpZ3VyZT4KICAgICAgPC9zZWN0aW9uPgoKICAgICAgPHNlY3Rpb24gdGl0bGU9 JyJjb2RlIiBTeW50YXgnPgoKCTxmaWd1cmU+CgkgIDxwcmVhbWJsZT4KCSAgICBUaGUgPHNwYW54 IHN0eWxlPSd2ZXJiJz5jb2RlPC9zcGFueD4gZWxlbWVudCBpcyBkZWZpbmVkIGluCgkgICAgPHhy ZWYgdGFyZ2V0PSJ0b2tlbi1yZXEiLz46CgkgIDwvcHJlYW1ibGU+CgkgIDxhcnR3b3JrPjwhW0NE QVRBWwpjb2RlICAgICAgID0gMSpWU0NIQVIKXV0+PC9hcnR3b3JrPgoJPC9maWd1cmU+CiAgICAg IDwvc2VjdGlvbj4KCiAgICAgIDxzZWN0aW9uIHRpdGxlPSciYWNjZXNzX3Rva2VuIiBTeW50YXgn PgoKCTxmaWd1cmU+CgkgIDxwcmVhbWJsZT4KCSAgICBUaGUgPHNwYW54IHN0eWxlPSd2ZXJiJz5h Y2Nlc3NfdG9rZW48L3NwYW54PiBlbGVtZW50IGlzIGRlZmluZWQgaW4KCSAgICA8eHJlZiB0YXJn ZXQ9ImltcGxpY2l0LWF1dGh6LXJlc3AiLz4gYW5kCgkgICAgPHhyZWYgdGFyZ2V0PSJ0b2tlbi1y ZXNwb25zZSIvPjoKCSAgPC9wcmVhbWJsZT4KCSAgPGFydHdvcms+PCFbQ0RBVEFbCmFjY2Vzcy10 b2tlbiA9IDEqVlNDSEFSCl1dPjwvYXJ0d29yaz4KCTwvZmlndXJlPgogICAgICA8L3NlY3Rpb24+ CgogICAgICA8c2VjdGlvbiB0aXRsZT0nInRva2VuX3R5cGUiIFN5bnRheCc+CgoJPGZpZ3VyZT4K CSAgPHByZWFtYmxlPgoJICAgIFRoZSA8c3Bhbnggc3R5bGU9J3ZlcmInPnRva2VuX3R5cGU8L3Nw YW54PiBlbGVtZW50IGlzIGRlZmluZWQgaW4KCSAgICA8eHJlZiB0YXJnZXQ9ImltcGxpY2l0LWF1 dGh6LXJlc3AiLz4sCgkgICAgPHhyZWYgdGFyZ2V0PSJ0b2tlbi1yZXNwb25zZSIvPiwgYW5kCgkg ICAgPHhyZWYgdGFyZ2V0PSJuZXctdHlwZXMiLz46CgkgIDwvcHJlYW1ibGU+CgkgIDxhcnR3b3Jr PjwhW0NEQVRBWwp0b2tlbi10eXBlID0gdHlwZS1uYW1lIC8gVVJJLXJlZmVyZW5jZQp0eXBlLW5h bWUgID0gMSpuYW1lLWNoYXIKbmFtZS1jaGFyICA9ICItIiAvICIuIiAvICJfIiAvIERJR0lUIC8g QUxQSEEKXV0+PC9hcnR3b3JrPgoJPC9maWd1cmU+CiAgICAgIDwvc2VjdGlvbj4KCiAgICAgIDxz ZWN0aW9uIHRpdGxlPSciZXhwaXJlc19pbiIgU3ludGF4Jz4KCgk8ZmlndXJlPgoJICA8cHJlYW1i bGU+CgkgICAgVGhlIDxzcGFueCBzdHlsZT0ndmVyYic+ZXhwaXJlc19pbjwvc3Bhbng+IGVsZW1l bnQgaXMgZGVmaW5lZCBpbgoJICAgIDx4cmVmIHRhcmdldD0iaW1wbGljaXQtYXV0aHotcmVzcCIv PiBhbmQKCSAgICA8eHJlZiB0YXJnZXQ9InRva2VuLXJlc3BvbnNlIi8+OgoJICA8L3ByZWFtYmxl PgoJICA8YXJ0d29yaz48IVtDREFUQVsKZXhwaXJlcy1pbiA9IDEqRElHSVQKXV0+PC9hcnR3b3Jr PgoJPC9maWd1cmU+CiAgICAgIDwvc2VjdGlvbj4KCiAgICAgIDxzZWN0aW9uIHRpdGxlPScidXNl cm5hbWUiIFN5bnRheCc+CgoJPGZpZ3VyZT4KCSAgPHByZWFtYmxlPgoJICAgIFRoZSA8c3Bhbngg c3R5bGU9J3ZlcmInPnVzZXJuYW1lPC9zcGFueD4gZWxlbWVudCBpcyBkZWZpbmVkIGluCgkgICAg PHhyZWYgdGFyZ2V0PSJwYXNzd29yZC10b2stcmVxIi8+OgoJICA8L3ByZWFtYmxlPgoJICA8YXJ0 d29yaz48IVtDREFUQVsKdXNlcm5hbWUgPSAqVU5JQ09ERU5PQ1RSTENIQVIKXV0+PC9hcnR3b3Jr PgoJPC9maWd1cmU+CiAgICAgIDwvc2VjdGlvbj4KCiAgICAgIDxzZWN0aW9uIHRpdGxlPScicGFz c3dvcmQiIFN5bnRheCc+CgoJPGZpZ3VyZT4KCSAgPHByZWFtYmxlPgoJICAgIFRoZSA8c3Bhbngg c3R5bGU9J3ZlcmInPnBhc3N3b3JkPC9zcGFueD4gZWxlbWVudCBpcyBkZWZpbmVkIGluCgkgICAg PHhyZWYgdGFyZ2V0PSJwYXNzd29yZC10b2stcmVxIi8+OgoJICA8L3ByZWFtYmxlPgoJICA8YXJ0 d29yaz48IVtDREFUQVsKcGFzc3dvcmQgPSAqVU5JQ09ERU5PQ1RSTENIQVIKXV0+PC9hcnR3b3Jr PgoJPC9maWd1cmU+CiAgICAgIDwvc2VjdGlvbj4KCiAgICAgIDxzZWN0aW9uIHRpdGxlPScicmVm cmVzaF90b2tlbiIgU3ludGF4Jz4KCgk8ZmlndXJlPgoJICA8cHJlYW1ibGU+CgkgICAgVGhlIDxz cGFueCBzdHlsZT0ndmVyYic+cmVmcmVzaF90b2tlbjwvc3Bhbng+IGVsZW1lbnQgaXMgZGVmaW5l ZCBpbgoJICAgIDx4cmVmIHRhcmdldD0idG9rZW4tcmVzcG9uc2UiLz4gYW5kCgkgICAgPHhyZWYg dGFyZ2V0PSJ0b2tlbi1yZWZyZXNoIi8+OgoJICA8L3ByZWFtYmxlPgoJICA8YXJ0d29yaz48IVtD REFUQVsKcmVmcmVzaC10b2tlbiA9IDEqVlNDSEFSCl1dPjwvYXJ0d29yaz4KCTwvZmlndXJlPgog ICAgICA8L3NlY3Rpb24+CgogICAgICA8c2VjdGlvbiB0aXRsZT0nRW5kcG9pbnQgUGFyYW1ldGVy IFN5bnRheCc+CgoJPGZpZ3VyZT4KCSAgPHByZWFtYmxlPgoJICAgIFRoZSBzeW50YXggZm9yIG5l dyBlbmRwb2ludCBwYXJhbWV0ZXJzIGlzIGRlZmluZWQgaW4KCSAgICA8eHJlZiB0YXJnZXQ9ImVu ZHBvaW50LXBhcmFtcyIvPjoKCSAgPC9wcmVhbWJsZT4KCSAgPGFydHdvcms+PCFbQ0RBVEFbCnBh cmFtLW5hbWUgPSAxKm5hbWUtY2hhcgpuYW1lLWNoYXIgID0gIi0iIC8gIi4iIC8gIl8iIC8gRElH SVQgLyBBTFBIQQpdXT48L2FydHdvcms+Cgk8L2ZpZ3VyZT4KICAgICAgPC9zZWN0aW9uPgoKICAg IDwvc2VjdGlvbj4KCiAgICA8c2VjdGlvbiB0aXRsZT0nQWNrbm93bGVkZ2VtZW50cyc+CiAgICAg IDx0PgogICAgICAgIFRoZSBpbml0aWFsIE9BdXRoIDIuMCBwcm90b2NvbCBzcGVjaWZpY2F0aW9u IHdhcyBlZGl0ZWQgYnkgRGF2aWQgUmVjb3Jkb24sIGJhc2VkIG9uIHR3bwogICAgICAgIHByZXZp b3VzIHB1YmxpY2F0aW9uczogdGhlIE9BdXRoIDEuMCBjb21tdW5pdHkgc3BlY2lmaWNhdGlvbiA8 eHJlZiB0YXJnZXQ9J1JGQzU4NDknIC8+LCBhbmQKICAgICAgICBPQXV0aCBXUkFQIChPQXV0aCBX ZWIgUmVzb3VyY2UgQXV0aG9yaXphdGlvbiBQcm9maWxlcykKICAgICAgICA8eHJlZiB0YXJnZXQ9 J0ktRC5kcmFmdC1oYXJkdC1vYXV0aC0wMScgLz4uIFRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9u cyBzZWN0aW9uIHdhcyBkcmFmdGVkCiAgICAgICAgYnkgVG9yc3RlbiBMb2RkZXJzdGVkdCwgTWFy ayBNY0dsb2luLCBQaGlsIEh1bnQsIGFuZCBBbnRob255IE5hZGFsaW4uCglUaGUgQUJORiBzZWN0 aW9uIHdhcyBkcmFmdGVkIGJ5IE1pY2hhZWwgQi4gSm9uZXMuCiAgICAgIDwvdD4KICAgICAgPHQ+ CiAgICAgICAgVGhlIE9BdXRoIDEuMCBjb21tdW5pdHkgc3BlY2lmaWNhdGlvbiB3YXMgZWRpdGVk IGJ5IEVyYW4gSGFtbWVyIGFuZCBhdXRob3JlZCBieQogICAgICAgIE1hcmsgQXR3b29kLCBEaXJr IEJhbGZhbnosIERhcnJlbiBCb3VuZHMsIFJpY2hhcmQgTS4gQ29ubGFuLCBCbGFpbmUgQ29vaywg TGVhaCBDdWx2ZXIsCiAgICAgICAgQnJlbm8gZGUgTWVkZWlyb3MsIEJyaWFuIEVhdG9uLCBLZWxs YW4gRWxsaW90dC1NY0NyZWEsIExhcnJ5IEhhbGZmLCBFcmFuIEhhbW1lciwKICAgICAgICBCZW4g TGF1cmllLCBDaHJpcyBNZXNzaW5hLCBKb2huIFBhbnplciwgU2FtIFF1aWdsZXksIERhdmlkIFJl Y29yZG9uLCBFcmFuIFNhbmRsZXIsCiAgICAgICAgSm9uYXRoYW4gU2VyZ2VudCwgVG9kZCBTaWVs aW5nLCBCcmlhbiBTbGVzaW5za3ksIGFuZCBBbmR5IFNtaXRoLgogICAgICA8L3Q+CiAgICAgIDx0 PgogICAgICAgIFRoZSBPQXV0aCBXUkFQIHNwZWNpZmljYXRpb24gd2FzIGVkaXRlZCBieSBEaWNr IEhhcmR0IGFuZCBhdXRob3JlZCBieSBCcmlhbiBFYXRvbiwKICAgICAgICBZYXJvbiBZLiBHb2xh bmQsIERpY2sgSGFyZHQsIGFuZCBBbGxlbiBUb20uCiAgICAgIDwvdD4KICAgICAgPHQ+CiAgICAg ICAgVGhpcyBzcGVjaWZpY2F0aW9uIGlzIHRoZSB3b3JrIG9mIHRoZSBPQXV0aCBXb3JraW5nIEdy b3VwIHdoaWNoIGluY2x1ZGVzIGRvemVucyBvZiBhY3RpdmUKICAgICAgICBhbmQgZGVkaWNhdGVk IHBhcnRpY2lwYW50cy4gSW4gcGFydGljdWxhciwgdGhlIGZvbGxvd2luZyBpbmRpdmlkdWFscyBj b250cmlidXRlZCBpZGVhcywKICAgICAgICBmZWVkYmFjaywgYW5kIHdvcmRpbmcgd2hpY2ggc2hh cGVkIGFuZCBmb3JtZWQgdGhlIGZpbmFsIHNwZWNpZmljYXRpb246CiAgICAgIDwvdD4KICAgICAg PHQ+CiAgICAgICAgTWljaGFlbCBBZGFtcywgQW1hbmRhIEFuZ2FuZXMsIEFuZHJldyBBcm5vdHQs IERpcmsgQmFsZmFueiwgQWlkZW4gQmVsbCwgSm9obiBCcmFkbGV5LCBCcmlhbiBDYW1wYmVsbCwK ICAgICAgICBTY290dCBDYW50b3IsIE1hcmNvcyBDYWNlcmVzLCBCbGFpbmUgQ29vaywgUm9nZXIg Q3JldywgQnJpYW4gRWF0b24sIFdlc2xleSBFZGR5LCBMZWFoIEN1bHZlciwKICAgICAgICBCaWxs IGRlIGhPcmEsIEFuZHJlIERlTWFycmUsIEJyaWFuIEVhdG9uLCBXb2x0ZXIgRWxkZXJpbmcsIEJy aWFuIEVsbGluLCBJZ29yIEZheW5iZXJnLAogICAgICAgIEdlb3JnZSBGbGV0Y2hlciwgVGltIEZy ZWVtYW4sIEx1Y2EgRnJvc2luaSwgRXZhbiBHaWxiZXJ0LCBZYXJvbiBZLiBHb2xhbmQsIEJyZW50 IEdvbGRtYW4sCiAgICAgICAgS3Jpc3RvZmZlciBHcm9ub3dza2ksIEp1c3RpbiBIYXJ0LCBEaWNr IEhhcmR0LCBDcmFpZyBIZWF0aCwgUGhpbCBIdW50LCBNaWNoYWVsIEIuIEpvbmVzLAogICAgICAg IFRlcnJ5IEpvbmVzLCBKb2huIEtlbXAsIE1hcmsgS2VudCwgUmFmZmkgS3Jpa29yaWFuLCBDaGFz ZW4gTGUgSGFyYSwgUmFzbXVzIExlcmRvcmYsCiAgICAgICAgVG9yc3RlbiBMb2RkZXJzdGVkdCwg SHVpLUxhbiBMdSwgQ2FzZXkgTHVjYXMsIFBhdWwgTWFkc2VuLCBBbGFzdGFpciBNYWlyLCBFdmUg TWFsZXIsCiAgICAgICAgSmFtZXMgTWFuZ2VyLCBNYXJrIE1jR2xvaW4sIExhdXJlbmNlIE1pYW8s IFdpbGxpYW0gTWlsbHMsIENodWNrIE1vcnRpbW9yZSwgQW50aG9ueSBOYWRhbGluLAogICAgICAg IEp1bGlhbiBSZXNjaGtlLCBKdXN0aW4gUmljaGVyLCBQZXRlciBTYWludC1BbmRyZSwgTmF0IFNh a2ltdXJhLCBSb2IgU2F5cmUsCiAgICAgICAgTWFyaXVzIFNjdXJ0ZXNjdSwgTmFpdGlrIFNoYWgs IEx1a2UgU2hlcGFyZCwgVmxhZCBTa3ZvcnRzb3YsIEp1c3RpbiBTbWl0aCwgSGFpYmluIFNvbmcs CiAgICAgICAgTml2IFN0ZWluZ2FydGVuLCBDaHJpc3RpYW4gU3R1ZWJuZXIsIEplcmVteSBTdXJp ZWwsIFBhdWwgVGFyamFuLCBDaHJpc3RvcGhlciBUaG9tYXMsCiAgICAgICAgSGVucnkgUy4gVGhv bXBzb24sIEFsbGVuIFRvbSwgRnJhbmtsaW4gVHNlLCBOaWNrIFdhbGtlciwgU2hhbmUgV2VlZGVu LCBhbmQgU2t5bGFyIFdvb2R3YXJkLgogICAgICA8L3Q+CiAgICAgIDx0PgogICAgICAgIFRoaXMg ZG9jdW1lbnQgd2FzIHByb2R1Y2VkIHVuZGVyIHRoZSBjaGFpcm1hbnNoaXAgb2YgQmxhaW5lIENv b2ssIFBldGVyIFNhaW50LUFuZHJlLAogICAgICAgIEhhbm5lcyBUc2Nob2ZlbmlnLCBCYXJyeSBM ZWliYSwgYW5kIERlcmVrIEF0a2lucy4gVGhlIGFyZWEgZGlyZWN0b3JzIGluY2x1ZGVkIExpc2Eg RHVzc2VhdWx0LAogICAgICAgIFBldGVyIFNhaW50LUFuZHJlLCBhbmQgU3RlcGhlbiBGYXJyZWxs LgogICAgICA8L3Q+CiAgICA8L3NlY3Rpb24+CgogICAgPHNlY3Rpb24gdGl0bGU9IkVkaXRvcidz IE5vdGVzIj4KICAgICAgPHQ+CiAgICAgICAgV2hpbGUgbWFueSBwZW9wbGUgY29udHJpYnV0ZWQg dG8gdGhpcyBzcGVjaWZpY2F0aW9uIHRocm91Z2hvdXQgaXRzIGxvbmcgam91cm5leSwgdGhlIGVk aXRvcgogICAgICAgIHdvdWxkIGxpa2UgdG8gYWNrbm93bGVkZ2UgYW5kIHRoYW5rIGEgZmV3IGlu ZGl2aWR1YWxzIGZvciB0aGVpciBvdXRzdGFuZGluZyBhbmQgaW52YWx1YWJsZQogICAgICAgIGVm Zm9ydHMgbGVhZGluZyB1cCB0byB0aGUgcHVibGljYXRpb24gb2YgdGhpcyBzcGVjaWZpY2F0aW9u LgogICAgICA8L3Q+CiAgICAgIDx0PgogICAgICAgIERhdmlkIFJlY29yZG9uIGZvciBjb250aW51 b3VzbHkgYmVpbmcgb25lIG9mIE9BdXRoJ3MgbW9zdCB2YWx1YWJsZSBhc3NldHMsIGJyaW5naW5n CiAgICAgICAgcHJhZ21hdGlzbSBhbmQgdXJnZW5jeSB0byB0aGUgd29yaywgYW5kIGhlbHBpbmcg c2hhcGUgaXQgZnJvbSBpdHMgdmVyeSBiZWdpbm5pbmcsIGFzIHdlbGwKICAgICAgICBhcyBiZWlu ZyBvbmUgb2YgdGhlIGJlc3QgY29sbGFib3JhdG9ycyBJIGhhZCB0aGUgcGxlYXN1cmUgb2Ygd29y a2luZyB3aXRoLgogICAgICA8L3Q+CiAgICAgIDx0PgogICAgICAgIEphbWVzIE1hbmdlciBmb3Ig aGlzIGNyZWF0aXZlIGlkZWFzIGFuZCBhbHdheXMgaW5zaWdodGZ1bCBmZWVkYmFjay4gQnJpYW4g Q2FtcGJlbGwsCiAgICAgICAgVG9yc3RlbiBMb2RkZXJzdGVkdCwgQ2h1Y2sgTW9ydGltb3JlLCBK dXN0aW4gUmljaGVyLCBNYXJpdXMgU2N1cnRlc2N1LCBhbmQgTHVrZSBTaGVwYXJkIGZvcgogICAg ICAgIHRoZWlyIGNvbnRpbnVlZCBwYXJ0aWNpcGF0aW9uIGFuZCB2YWx1YWJsZSBmZWVkYmFjay4K ICAgICAgPC90PgogICAgICA8dD4KICAgICAgICBTcGVjaWFsIHRoYW5rcyBnb2VzIHRvIE1pa2Ug Q3VydGlzIGFuZCBZYWhvbyEgZm9yIHRoZWlyIHVuY29uZGl0aW9uYWwgc3VwcG9ydCBvZiB0aGlz IHdvcmsKICAgICAgICBmb3Igb3ZlciB0aHJlZSB5ZWFycy4KICAgICAgPC90PgogICAgPC9zZWN0 aW9uPgoKICA8L2JhY2s+Cgo8L3JmYz4K --_007_4E1F6AAD24975D4BA5B16804296739436655A85ETK5EX14MBXC283r_-- From dick.hardt@gmail.com Mon Jun 18 17:20:41 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7E3F11E80DC for ; Mon, 18 Jun 2012 17:20:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.465 X-Spam-Level: X-Spam-Status: No, score=-3.465 tagged_above=-999 required=5 tests=[AWL=-0.467, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_65=0.6, 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 siagWNFSvmUw for ; Mon, 18 Jun 2012 17:20:40 -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 1CA1A11E8073 for ; Mon, 18 Jun 2012 17:20:40 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so8952852pbc.31 for ; Mon, 18 Jun 2012 17:20:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=ahjMTR2Fq74ahFuPyT4kJ2qQPC/KQDXXc6W/6o9UpYw=; b=veQ49k3o8cicAQPVjf97IZsUc4xwT2BI2T+CVIatroN0HIrxh9SMW5vG2K/lQq8hd8 J8mbZF8oYnPnQ5zsazDkyR7lMw22UuIdFOjnCiF654CtsJL7X2kD3umf0b461Y6S26L9 VBlaafiVeWZ4LicAsOLA3Lv+6ehy9S8DTqtszRt/wG7bF+YDK7LLwN47A8nJU89GVDTT ORn/APlOPENrEwhl4Lx2nljmoOyzggJOFVHSmmOnyCr+dAj0k6eX8C0vc26afa/yM5OX HERjOTDZ2of33AbfYnthOL267GqiGJFe/olrL+b11gIH0Me6VYxMY1JjZzJzYpJ6ddMV 1rfA== Received: by 10.68.201.9 with SMTP id jw9mr57881639pbc.28.1340065239584; Mon, 18 Jun 2012 17:20:39 -0700 (PDT) Received: from [10.0.0.4] (c-24-5-69-173.hsd1.ca.comcast.net. [24.5.69.173]) by mx.google.com with ESMTPS id vp4sm25641188pbc.61.2012.06.18.17.20.37 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 18 Jun 2012 17:20:38 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_534F4347-E749-4C50-BD42-7CA6D09F3EB0" From: Dick Hardt In-Reply-To: <484A13D0-7C9A-42CC-BB94-3657741834DE@ve7jtb.com> Date: Mon, 18 Jun 2012 17:20:35 -0700 Message-Id: <82D95BA2-1697-4441-BBB3-B2AE480DC39E@gmail.com> References: <854774286EF8A240BACC342973A86EAC016693D6@BL2PRD0310MB387.namprd03.prod.outlook.com> <484A13D0-7C9A-42CC-BB94-3657741834DE@ve7jtb.com> To: John Bradley X-Mailer: Apple Mail (2.1278) Cc: Yuchen Zhou , rui wang , Derek Atkins , "oauth@ietf.org" , "Shuo Chen \(MSR\)" Subject: Re: [OAUTH-WG] proposal of a paragraph to add to the security considerations section X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 00:20:42 -0000 --Apple-Mail=_534F4347-E749-4C50-BD42-7CA6D09F3EB0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 John Do you have suggested text per your suggestion below? -- Dick On Jun 18, 2012, at 2:04 PM, John Bradley wrote: > I blogged about this in the hypothetical several months ago. = http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.h= tml >=20 > Nov Matake and others built some tests and found quite a number of = deployments vulnerable.=20 > = http://www.thread-safe.com/2012/02/more-on-oauth-implicit-flow-application= .html >=20 > The bottom line is that OAuth has no explicit audience restriction for = tokens, hence accepting any token outside of the code flow is subject = to attack. >=20 > In general it is not a issue for authorization, it is however a big = issue then there is a presumption that the presenter of a token that = grants a client access to resource x is the "resource owner" of resource = x, when it is possible that the presenter is any client who has ever had = a access token for resource x. >=20 > We might want to include the why it is insecure in the security = consideration, otherwise people reading the below will likely ignore = the advice as it seems on the surface a touch extreme. >=20 > There are certainly OAuth flows that allow you to do authentication = safely, just not all of them without additional precautions. >=20 > That is why openID Connect has a audience restricted id_token similar = to Facebook's signed request to allow the implicit flows to be safely = used for authentication. >=20 > John B. >=20 >=20 >=20 >=20 > On 2012-06-18, at 4:19 PM, Shuo Chen (MSR) wrote: >=20 >> Hi OAuth group, >> =20 >> This is regarding the recent discussion about an implementation issue = of some cloud services using OAuth for authentication. >> Derek Atkins and Dick Hardt suggested the possibility to discuss with = the group a paragraph to add to the security considerations section. >> =20 >> Derek=92s suggestion: >> =3D=3D=3D=3D =3D=3D=3D =3D=3D=3D =3D=3D=3D >> >> Perhaps you could boil it down to a paragraph >> >> or two for addition to the security considerations section that = basically says >> >> "beware of implementing it *this* way because it leads to *that* = attack vector", etc. >> =3D=3D=3D=3D =3D=3D=3D =3D=3D=3D =3D=3D=3D >> =20 >> =20 >> Here is out suggested text: >> =3D=3D=3D=3D =3D=3D=3D =3D=3D=3D =3D=3D=3D >> It has been observed that in multiple occasions that the server-side >> authentication logic takes an access token from the client, then >> queries the user's profile data from the IdP in order to >> "authenticate" the user. This implementation must be forbidden. It >> will allow an untrusted app running on a victim=92s client device to >> work with an attacker=92s device to sign into the victim=92s account = on the server side. >> =3D=3D=3D=3D =3D=3D=3D =3D=3D=3D =3D=3D=3D >> =20 >> =20 >> Thank you. >> -Shuo >> p.s. below is the email thread giving a better context of the = discussion. >> =20 >> =20 >> > -----Original Message----- >> > From: Derek Atkins [mailto:derek@ihtfp.com] >> > Sent: Monday, June 18, 2012 11:25 AM >> > To: Shuo Chen (MSR) >> > Cc: Hannes Tschofenig; rui wang; Stephen Farrell; Yuchen Zhou; = Derek >> > Atkins; Dick Hardt >> > Subject: Re: [OAUTH-WG] web sso study... >> >=20 >> > Hi, >> >=20 >> > "Shuo Chen (MSR)" writes: >> >=20 >> >> Hi Hannes, Derek and Stephen, >> >>=20 >> >> Thank you for your replies. >> >>=20 >> >>> First, let me ask whether it is OK if I share your post with the >> >>> OAuth WG >> >>=20 >> >> Yes, please feel free to share it. >> >>=20 >> >>> Second, could you describe the attack in more details to me? >> >>=20 >> >> Let's consider the mobile+cloud scenario for concreteness = (although >> >> some other scenarios are also applicable). The attack steps are = the >> >> following: suppose Alice's tablet runs a Windows 8 Metro app = written >> >> by attacker Bob. This app is able to request and obtain an access >> >> token from the IdP (associated with Alice). The app can then send = the >> >> access token to Bob's own tablet. Note that there is no security >> >> problem up to this point. However the real problem is that some = cloud >> >> services use the access token to query the user's profile data = from >> >> the IdP in order to "authenticate" the user. In this case, Bob's >> >> tablet will be able to sign into the cloud service as Alice. We = have >> >> confirmed that the cloud services for Soluto Metro App, Givit = Metro >> >> App and EuroCup2012 Metro App make this mistake. These are apps in >> >> the official Windows 8 App Store. We actually sampled only a small = portion of the available apps, but believe this is a vulnerability = pattern. >> >>=20 >> >> We don=92t think there is anything wrong in the OAuth spec. It is >> >> developers who didn=92t comprehensively understand the usage of = the >> >> access token. In the meanwhile, this vulnerability pattern is not = explicitly excluded by the spec. >> >> More importantly, it has been seen in the wild. >> >>=20 >> >>> [from Derek's email] Perhaps you could boil it down to a = paragraph >> >>> or two for >> >> addition to the security considerations section that basically = says >> >> "beware of implementing it *this* way because it leads to *that* = attack vector", etc. >> >>=20 >> >> This is a great idea. I think that although it is difficult to >> >> anticipate in general all kinds of incomprehensive understandings = of >> >> average developers, it is very worthwhile to take any common = existing >> >> vulnerability pattern as a precious feedback to improve the >> >> specification text. In this case, since we have already seen this >> >> vulnerability pattern on multiple services in the wild, certainly = we >> >> should be explicit about it in the security considerations = section. >> >>=20 >> >> Our suggested text: >> >>=20 >> >> It has been observed that in multiple occasions that the = server-side >> >> authentication logic takes an access token from the client, then >> >> queries the user's profile data from the IdP in order to >> >> "authenticate" the user. This implementation must be forbidden. It >> >> will allow an untrusted app running on a victim=92s client device = to >> >> work with an attacker=92s device to sign into the victim=92s = account on the server side. >> >>=20 >> >> Any questions or suggestions? >> >=20 >> > Could you please send this to the oauth@ietf.org mailing list? >> >=20 >> >> Thanks a lot. >> >>=20 >> >> -Shuo >> >=20 >> > -derek >> >=20 >> >> -----Original Message----- >> >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> >> Sent: Friday, June 15, 2012 11:36 AM >> >> To: rui wang >> >> Cc: Hannes Tschofenig; Stephen Farrell; Shuo Chen (MSR); Yuchen = Zhou; >> >> Derek Atkins >> >> Subject: Re: [OAUTH-WG] web sso study... >> >>=20 >> >> Hi Rui, >> >>=20 >> >> let me independently respond (in addition to the previous = responses >> >> you had already gotten). >> >>=20 >> >> First, let me ask whether it is OK if I share your post with the >> >> OAuth WG since it is more detailed than the one you distributed on = the list mid April. >> >>=20 >> >> Second, could you describe the attack in more details to me? What = I >> >> would like to better understand whether this the raised issue is a >> >> problem with one of our specifications, with a specific >> >> implementation of the IETF OAuth specifications, a problem with = other >> >> OAuth related work (Facebook, as you know, implements far more = than >> >> just the IETF OAuth specifications), a violation of the IETF OAuth >> >> specification in the way how the Websites use OAuth, whether this = is >> >> a configuration related aspect, or an aspect we already documented = in the threats document. >> >>=20 >> >> The reason why I am so specific is to know where to put text to >> >> address this issue or whether this is even an issue beyond the = IETF >> >> OAuth working group and needs to be tackled somewhere else. >> >>=20 >> >> Ciao >> >>=20 >> >> Hannes >> >> >> _______________________________________________ >> 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=_534F4347-E749-4C50-BD42-7CA6D09F3EB0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
I = blogged about this in the hypothetical several months ago. http://www.thread-safe.com/2012/01/problem-with-oauth-for-aut= hentication.html

Nov Matake and others built some = tests and found quite a number of deployments = vulnerable. 

The bottom line is = that OAuth has no explicit audience restriction for tokens,  hence = accepting any token outside of the code flow is subject to = attack.

In general it is not a issue for = authorization,  it is however a big issue then there is a = presumption that the presenter of a token that grants a client access to = resource x is the "resource owner" of resource x, when it is possible = that the presenter is any client who has ever had a access token for = resource x.

We might want to include the why it = is insecure in the security consideration,  otherwise people = reading the below will likely ignore the advice as it seems on the = surface a touch extreme.

There are certainly = OAuth flows that allow you to do authentication safely,  just not = all of them without additional = precautions.

That is why openID Connect has a = audience restricted id_token similar to Facebook's signed request to = allow the implicit flows to be safely used for = authentication.

John = B.




On = 2012-06-18, at 4:19 PM, Shuo Chen (MSR) wrote:

Hi OAuth = group,
 
This is regarding = the recent discussion about an implementation issue of some cloud = services using OAuth for authentication.
Derek Atkins and Dick Hardt suggested the possibility to = discuss with the group a paragraph to add to the security considerations = section.
 
Derek=92s suggestion:
=3D=3D=3D=3D   =3D=3D=3D  =3D=3D=3D  = =3D=3D=3D
>> Perhaps you could boil it = down to a paragraph
>> or two for addition = to the security considerations section that basically = says
>> "beware of implementing it *this* way = because it leads to *that* attack vector", etc.
=3D=3D=3D=3D   =3D=3D=3D  =3D=3D=3D  = =3D=3D=3D
 
 
Here is out suggested = text:
=3D=3D=3D=3D   =3D=3D=3D  = =3D=3D=3D  =3D=3D=3D
It has been observed that in = multiple occasions that the server-side
authentication logic takes an access token from the = client, then
queries the user's profile = data from the IdP in order to
"authenticate" the = user. This implementation must be forbidden. It
will allow an untrusted app running on a victim=92s client = device to
work with an attacker=92s device to = sign into the victim=92s account on the server = side.
=3D=3D=3D=3D   =3D=3D=3D  = =3D=3D=3D  =3D=3D=3D
 
 
Thank = you.
-Shuo
p.s. below is the = email thread giving a better context of the = discussion.
 
 
> -----Original = Message-----
> From: Derek Atkins = [mailto:derek@ihtfp.com]
> Sent: Monday, June 18, = 2012 11:25 AM
> To: Shuo Chen = (MSR)
> Cc: Hannes Tschofenig; rui wang; Stephen = Farrell; Yuchen Zhou; Derek
> Atkins; Dick = Hardt
> Subject: Re: [OAUTH-WG] web sso = study...
> 
> Hi,
> "Shuo Chen (MSR)" <shuochen@microsoft.com> = writes:
> 
>> Hi Hannes, Derek and = Stephen,
>> 
>> Thank you for your replies.
>> 
>>> First, = let me ask whether it is OK if I share your post with = the
>>> OAuth WG
>> 
>> Yes, = please feel free to share it.
>>> Second, could you = describe the attack in more details to me?
>> 
>> Let's = consider the mobile+cloud scenario for concreteness = (although
>> some other scenarios are = also applicable). The attack steps are the
>> following: suppose Alice's tablet runs a Windows = 8 Metro app written
>> by attacker Bob. This = app is able to request and obtain an access
>> token from the IdP (associated with Alice). The = app can then send the
>> access token to Bob's = own tablet. Note that there is no security
>> problem up to this point. However the real = problem is that some cloud
>> services = use the access token to query the user's profile data = from
>> the IdP in order to "authenticate" the = user. In this case, Bob's
>> tablet will be able = to sign into the cloud service as Alice. We have
>> confirmed that the cloud services for Soluto = Metro App, Givit Metro
>> App and EuroCup2012 = Metro App make this mistake. These are apps in
>> the official Windows 8 App Store. We actually = sampled only a small portion of the available apps, but believe this is = a vulnerability pattern.
>> We don=92t think = there is anything wrong in the OAuth spec. It is
>> developers who didn=92t comprehensively = understand the usage of the
>> access = token. In the meanwhile, this vulnerability pattern is not explicitly = excluded by the spec.
>> More importantly, it = has been seen in the wild.
>>> [from Derek's = email] Perhaps you could boil it down to a = paragraph
>>> or two = for
>> addition to the security considerations = section that basically says
>> "beware of = implementing it *this* way because it leads to *that* attack vector", = etc.
>> 
>> This is a great idea. I think that although it is = difficult to
>> anticipate in general = all kinds of incomprehensive understandings of
>> average developers, it is very worthwhile to take = any common existing
>> vulnerability pattern = as a precious feedback to improve the
>> specification text. In this case, since we have = already seen this
>> vulnerability pattern = on multiple services in the wild, certainly we
>> should be explicit about it in the security = considerations section.
>> Our suggested = text:
>> 
>> It has been observed that in multiple occasions = that the server-side
>> authentication logic = takes an access token from the client, then
>> queries the user's profile data from the IdP in = order to
>> "authenticate" the user. = This implementation must be forbidden. It
>> will allow an untrusted app running on a victim=92s= client device to
>> work with an = attacker=92s device to sign into the victim=92s account on the server = side.
>> 
>> Any questions or = suggestions?
> Could you please send = this to the oauth@ietf.org mailing = list?
> 
>> Thanks a lot.
>> 
>> = -Shuo
> 
> -derek
>> -----Original = Message-----
>> From: Hannes = Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
>> Sent: Friday, June 15, 2012 11:36 = AM
>> To: rui wang
>> Cc: Hannes Tschofenig; Stephen Farrell; Shuo Chen = (MSR); Yuchen Zhou;
>> Derek = Atkins
>> Subject: Re: [OAUTH-WG] web sso = study...
>> 
>> Hi Rui,
>> let me independently = respond (in addition to the previous responses
>> you had already gotten).
>> 
>> First, let = me ask whether it is OK if I share your post with = the
>> OAuth WG since it is more detailed than = the one you distributed on the list mid April.
>> 
>> Second, = could you describe the attack in more details to me? What = I
>> would like to better understand whether = this the raised issue is a
>> problem = with one of our specifications, with a specific
>> implementation of the IETF OAuth specifications, = a problem with other
>> OAuth related work = (Facebook, as you know, implements far more than
>> just the IETF OAuth specifications), a violation = of the IETF OAuth
>> specification in the = way how the Websites use OAuth, whether this is
>> a configuration related aspect, or an aspect we = already documented in the threats document.
>> 
>> The reason = why I am so specific is to know where to put text = to
>> address this issue or whether this is = even an issue beyond the IETF
>> OAuth = working group and needs to be tackled somewhere = else.
>> 
>> Ciao
>> = Hannes
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth

= --Apple-Mail=_534F4347-E749-4C50-BD42-7CA6D09F3EB0-- From Michael.Jones@microsoft.com Mon Jun 18 17:54:40 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBEC421F8602 for ; Mon, 18 Jun 2012 17:54:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.821 X-Spam-Level: X-Spam-Status: No, score=-3.821 tagged_above=-999 required=5 tests=[AWL=-0.222, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oIIRWcS9qWkB for ; Mon, 18 Jun 2012 17:54:39 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe003.messaging.microsoft.com [216.32.181.183]) by ietfa.amsl.com (Postfix) with ESMTP id BE18C21F85FF for ; Mon, 18 Jun 2012 17:54:38 -0700 (PDT) Received: from mail51-ch1-R.bigfish.com (10.43.68.253) by CH1EHSOBE012.bigfish.com (10.43.70.62) with Microsoft SMTP Server id 14.1.225.23; Tue, 19 Jun 2012 00:53:18 +0000 Received: from mail51-ch1 (localhost [127.0.0.1]) by mail51-ch1-R.bigfish.com (Postfix) with ESMTP id 6761C1C0370; Tue, 19 Jun 2012 00:53:18 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -40 X-BigFish: VS-40(zzbb2dI98dI9371Ic89bh936eI14ffI168aJ542Mdf9M1432I4015I111aIzz1202hzz1033IL8275dhz2fh2a8h668h839h93fhd25hf0ah) Received-SPF: pass (mail51-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC103.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail51-ch1 (localhost.localdomain [127.0.0.1]) by mail51-ch1 (MessageSwitch) id 134006719688613_28585; Tue, 19 Jun 2012 00:53:16 +0000 (UTC) Received: from CH1EHSMHS013.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.239]) by mail51-ch1.bigfish.com (Postfix) with ESMTP id 0A1FD460048; Tue, 19 Jun 2012 00:53:16 +0000 (UTC) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS013.bigfish.com (10.43.70.13) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 19 Jun 2012 00:53:15 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.53]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.02.0309.003; Tue, 19 Jun 2012 00:54:32 +0000 From: Mike Jones To: Torsten Lodderstedt , Phil Hunt Thread-Topic: [OAUTH-WG] Cache-Control headers for Bearer URI Query Parameter method Thread-Index: AQHNSGGUIW5j2JcxmkOEdZoo7nevTJcA2tQw Date: Tue, 19 Jun 2012 00:54:30 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436655AB5B@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739436652FBFC@TK5EX14MBXC284.redmond.corp.microsoft.com> <4FD6445B.8020904@lodderstedt.net> <2FCFF7EB-7E34-49F7-93EE-F57729E420F2@oracle.com> <4FD6DC6E.80408@lodderstedt.net> In-Reply-To: <4FD6DC6E.80408@lodderstedt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.70] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Cache-Control headers for Bearer URI Query Parameter method X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2012 00:54:40 -0000 Q291bGQgdGhlIGV4cGVydHMgb24gdGhpcyB0aHJlYWQgcGxlYXNlIHN1bW1hcml6ZSB0aGUgb3V0 Y29tZSBvZiB0aGlzIHRocmVhZD8gIFdhcyB0aGUgY29uY2x1c2lvbiB0aGF0IG5vIGNoYW5nZXMg d2VyZSByZXF1aXJlZCB0byBlaXRoZXIgQ29yZSBvciBCZWFyZXI/ICBPciBpZiB5b3UgYmVsaWV2 ZSB0aGF0IGNoYW5nZXMgYXJlIHJlcXVpcmVkIHRvIG9uZSBvciBib3RoIGRyYWZ0cywgY291bGQg eW91IHBsZWFzZSBwcm9wb3NlIGV4YWN0IHdvcmRpbmcgY2hhbmdlcyBmb3IgcmV2aWV3IGJ5IHRo ZSB3b3JraW5nIGdyb3VwPw0KDQoJCQkJVGhhbmtzLA0KCQkJCS0tIE1pa2UNCg0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpv YXV0aC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgVG9yc3RlbiBMb2RkZXJzdGVkdA0K U2VudDogTW9uZGF5LCBKdW5lIDExLCAyMDEyIDExOjA3IFBNDQpUbzogUGhpbCBIdW50DQpDYzog b2F1dGhAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIENhY2hlLUNvbnRyb2wgaGVh ZGVycyBmb3IgQmVhcmVyIFVSSSBRdWVyeSBQYXJhbWV0ZXIgbWV0aG9kDQoNCnRoYW5rcyBhIGxv dA0KDQpBbSAxMi4wNi4yMDEyIDAxOjAzLCBzY2hyaWViIFBoaWwgSHVudDoNCj4gVGhhbmtzLiBU aGF0IG1ha2VzIHNlbnNlLg0KPg0KPiBQaGlsDQo+DQo+IE9uIDIwMTItMDYtMTEsIGF0IDE1OjM5 LCBBbW9zIEplZmZyaWVzPHNxdWlkM0B0cmVlbmV0LmNvLm56PiAgd3JvdGU6DQo+DQo+PiBPbiAx Mi4wNi4yMDEyIDA3OjIzLCBQaGlsIEh1bnQgd3JvdGU6DQo+Pj4gUHJpdmF0ZSBhbHNvIHNlZW1z IGluYXBwcm9wcmlhdGUgc2luY2Ugbm8gb3BlcmF0aW9uIHNob3VsZCBiZSBjYWNoZWQgDQo+Pj4g Zm9yIG9hdXRoIGFzIGV2ZW4gd2hlbiB0aGUgc2FtZSByZXF1ZXN0b3IuDQo+Pj4NCj4+PiBQaGls DQo+Pj4NCj4+IFRoZXJlIGlzIGEgZGlmZmVyZW5jZSBpbiBIVFRQIHVzZS1jYXNlIGJldHdlZW4g d2hhdCB0aGUgQmVhcmVyIGFuZCBjb3JlIHNwZWNzIGFyZSBjb3ZlcmluZy4NCj4+DQo+PiBUaGUg Y29yZSBzcGVjIGFwcGVhcnMgdG8gYmUgY292ZXJpbmcgdGhlIHJlcXVlc3QvcmVzcG9uc2UgbWVz c2FnZXMgdHJhbnNmZXJyaW5nIGNyZWRlbnRpYWxzIGluIHRoZSByZXNwb25zZSBlbnRpdHkuIFRo ZXNlIG1hbmRhdGUgIm5vLXN0b3JlIiwgd2hpY2ggYWRkcyBzdHJpY3QgZXJhc3VyZSByZXF1aXJl bWVudHMgZm9yIGFueSBtaWRkbGV3YXJlIGFuZCBicm93c2VyIGNhY2hlcyBoYW5kbGluZyB0aGUg cmVzcG9uc2UuIEV2ZW4gc2luZ2xlLXVzZXIgY2FjaGVzIGxpa2UgYSBicm93c2VyIGFyZSBub3Qg YWxsb3dlZCB0byBzdG9yZSB0aGUgSFRUUCBjb3B5IG9mIHRoZSBjcmVkZW50aWFscyByZXNwb25z ZS4NCj4+DQo+PiBCZWFyZXIgaXMgcmVxdWlyaW5nICJwcml2YXRlIiBvbmx5IGluIHRoZSBzcGVj aWZpYyBIVFRQIGNhc2Ugd2hlcmUgdGhlIHRva2VuIGlzIGluIHF1ZXJ5IHBhcmFtcyBhbmQgcmVz cG9uc2UgaXMgc29tZSBkYXRhIG9iamVjdCAoaWUgaW1hZ2VzIG9yIEhUTUwgcGFnZSkuIFN1Y2gg dGhhdCB0cnVzdGVkIHByb3hpZXMgYW5kIG90aGVyIHRoaXJkLXBhcnRpZXMgd2hvIGRvIG5vdCBp bXBsZW1lbnQgT0F1dGggYnV0IGRvIHJlbGF5IEhUVFAgdHJlYXQgdGhlIHJlcXVlc3QgYW5kIHJl cGx5IHNlY3VyZWx5LiBXaXRoIHVzZXMgb2YgQmVhcmVyIHZpYSBIVFRQIGF1dGhlbnRpY2F0aW9u IGZyYW1ld29yayB0aGlzICJwcml2YXRlIiBpcyBpbXBsaWNpdC4NCj4+ICAgSW4gdGhlc2UgY2Fz ZXMgdGhlIHJlc3BvbnNlIE1BWSBiZSBjYWNoZWQgYnkgYSBwcml2YXRlIGJyb3dzZXIgY2FjaGUs IGJ1dCBub3QgYnkgdGhpcmQtcGFydHkgcHJveGllcy4gbm8tc3RvcmUgaXMgb3ZlcmtpbGwgYW5k IHdhc3RlcyBiYW5kd2lkdGggaW4gdGhpcyBjYXNlLg0KPj4NCj4+DQo+PiBJIGhvcGUgdGhpcyBj bGFyaWZpZXMuDQo+Pg0KPj4NCj4+IEFZSg0KPj4NCj4+DQo+Pj4gT24gMjAxMi0wNi0xMSwgYXQg MTI6MTcsIFRvcnN0ZW4gTG9kZGVyc3RlZHQgd3JvdGU6DQo+Pj4NCj4+Pj4gSGkgYWxsLA0KPj4+ Pg0KPj4+PiBJIG5vdGljZWQgYSBkaWZmZXJlbmNlIGluIHVzYWdlIG9mIGNhY2hlIGNvbnRyb2wg aGVhZGVycyBiZXR3ZWVuIGJlYXJlciBhbmQgY29yZSBzcGVjLg0KPj4+Pg0KPj4+PiBjb3JlIC0y NyBzdGF0ZXM6DQo+Pj4+DQo+Pj4+ICAgIiBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVTVCBp bmNsdWRlIHRoZSBIVFRQICJDYWNoZS1Db250cm9sIg0KPj4+PiAgICByZXNwb25zZSBoZWFkZXIg ZmllbGQgW1JGQzI2MTZdIHdpdGggYSB2YWx1ZSBvZiAibm8tc3RvcmUiIGluIGFueQ0KPj4+PiAg ICByZXNwb25zZSBjb250YWluaW5nIHRva2VucywgY3JlZGVudGlhbHMsIG9yIG90aGVyIHNlbnNp dGl2ZQ0KPj4+PiAgICBpbmZvcm1hdGlvbiwgYXMgd2VsbCBhcyB0aGUgIlByYWdtYSIgcmVzcG9u c2UgaGVhZGVyIGZpZWxkIFtSRkMyNjE2XQ0KPj4+PiAgICB3aXRoIGEgdmFsdWUgb2YgIm5vLWNh Y2hlIi4iDQo+Pj4+DQo+Pj4+IFNvIGEgIlByYWdtYSIgcmVzcG9uc2UgaGVhZGVyIGZpZWxkIGlz IHJlcXVpcmVkIGluc3RlYWQgb2YgdGhlICJDYWNoZS1Db250cm9sIiBoZWFkZXIgInByaXZhdGUi Lg0KPj4gTm90IGluc3RlYWQgb2YuICpBcyB3ZWxsIGFzKi4gIFByYWdtYSAibm8tY2FjaGUiIG9u bHkgdGVsbHMgdGhlIHRoaXJkLXBhcnR5IHRvIHJldmFsaWRhdGUgYmVmb3JlIHVzaW5nIHRoZSBy ZXNwb25zZSwgaXQgZG9lcyBub3QgcHJldmVudCBzdG9yYWdlIGFuZCB0aHVzIHBvdGVudGlhbCBk YXRhIGxlYWthZ2UuDQo+Pg0KPj4NCj4+Pj4gQXMgZmFyIGFzIEkgdW5kZXJzdGFuZCwgYm90aCBz cGVjcyBhcmUgbmVhcmx5IGJ1dCBub3QgZnVsbHkgZXF1aXZhbGVudC4gRG8gd2UgbmVlZCB0byBh bGlnbiBib3RoPw0KPj4+Pg0KPj4+PiByZWdhcmRzLA0KPj4+PiBUb3JzdGVuLg0KPj4+Pg0KPj4+ PiBBbSAwOS4wNi4yMDEyIDAwOjIwLCBzY2hyaWViIE1pa2UgSm9uZXM6DQo+Pj4+PiBIaSBBbW9z LA0KPj4+Pj4NCj4+Pj4+IFRoZSBPQXV0aCBCZWFyZXIgc3BlY2lmaWNhdGlvbiBub3cgaW5jbHVk ZXMgdGhlIENhY2hlLUNvbnRyb2wgbGFuZ3VhZ2Ugd2XigJlkIGRpc2N1c3NlZC4NCj4+Pj4+DQo+ Pj4+PiBTZWUgdGhlIGZpZnRoIHBhcmFncmFwaCBvZiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLW9hdXRoLXYyLWJlYXJlci0yMCNzZWN0aW9uLTIuMy4NCj4+Pj4+DQo+Pj4+ PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBUaGFua3MgYWdhaW4sDQo+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSANCj4+Pj4+IE1pa2UNCj4+Pj4+DQo+Pj4+ Pg0KPj4+Pj4gRnJvbTogb2F1dGgtYm91bmNlc0BpZXRmLm9yZyBPbiBCZWhhbGYgT2YgTWlrZSBK b25lcw0KPj4+Pj4gU2VudDogVGh1cnNkYXksIE1heSAxNywgMjAxMiAzOjEyIFBNDQo+Pj4+PiBT dWJqZWN0OiBbT0FVVEgtV0ddIENhY2hlLUNvbnRyb2wgaGVhZGVycyBmb3IgQmVhcmVyIFVSSSBR dWVyeSANCj4+Pj4+IFBhcmFtZXRlciBtZXRob2QNCj4+Pj4+DQo+Pj4+PiBEZWFyIHdvcmtpbmcg Z3JvdXAgbWVtYmVyczoNCj4+Pj4+DQo+Pj4+PiBJJ20gZ29pbmcgdGhyb3VnaCB0aGUgcmVtYWlu aW5nIG9wZW4gaXNzdWVzIHRoYXQgaGF2ZSBiZWVuIHJhaXNlZCBhYm91dCB0aGUgQmVhcmVyIHNw ZWMgc28gYXMgdG8gYmUgcmVhZHkgdG8gcHVibGlzaCBhbiB1cGRhdGVkIGRyYWZ0IG9uY2UgdGhl IG91dHN0YW5kaW5nIGNvbnNlbnN1cyBjYWxsIGlzc3VlcyBhcmUgcmVzb2x2ZWQuDQo+Pj4+Pg0K Pj4+Pj4gQW1vcyBKZWZmcmllcyBoYWQgY2l0ZWQgdGhpcyByZXF1aXJlbWVudCBpbiB0aGUgSFRU UGJpcyBzcGVjICggaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1odHRwYmlz LXA3LWF1dGgtMTkjc2VjdGlvbi0yLjMuMSk6DQo+Pj4+Pg0KPj4+Pj4gICAgbyAgVGhlIGNyZWRl bnRpYWxzIGNhcnJpZWQgaW4gYW4gQXV0aG9yaXphdGlvbiBoZWFkZXIgZmllbGQgYXJlDQo+Pj4+ PiAgICAgICBzcGVjaWZpYyB0byB0aGUgVXNlciBBZ2VudCwgYW5kIHRoZXJlZm9yZSBoYXZlIHRo ZSBzYW1lIGVmZmVjdCBvbg0KPj4+Pj4gICAgICAgSFRUUCBjYWNoZXMgYXMgdGhlICJwcml2YXRl IiBDYWNoZS1Db250cm9sIHJlc3BvbnNlIGRpcmVjdGl2ZSwNCj4+Pj4+ICAgICAgIHdpdGhpbiB0 aGUgc2NvcGUgb2YgdGhlIHJlcXVlc3QgdGhleSBhcHBlYXIgaW4uDQo+Pj4+Pg0KPj4+Pj4gICAg ICAgVGhlcmVmb3JlLCBuZXcgYXV0aGVudGljYXRpb24gc2NoZW1lcyB3aGljaCBjaG9vc2Ugbm90 IHRvIGNhcnJ5DQo+Pj4+PiAgICAgICBjcmVkZW50aWFscyBpbiB0aGUgQXV0aG9yaXphdGlvbiBo ZWFkZXIgKGUuZy4sIHVzaW5nIGEgbmV3bHkNCj4+Pj4+ICAgICAgIGRlZmluZWQgaGVhZGVyKSB3 aWxsIG5lZWQgdG8gZXhwbGljaXRseSBkaXNhbGxvdyBjYWNoaW5nLCBieQ0KPj4+Pj4gICAgICAg bWFuZGF0aW5nIHRoZSB1c2Ugb2YgZWl0aGVyIENhY2hlLUNvbnRyb2wgcmVxdWVzdCBkaXJlY3Rp dmVzDQo+Pj4+PiAgICAgICAoZS5nLiwgIm5vLXN0b3JlIikgb3IgcmVzcG9uc2UgZGlyZWN0aXZl cyAoZS5nLiwgInByaXZhdGUiKS4NCj4+Pj4+DQo+Pj4+PiBJIHByb3Bvc2UgdG8gYWRkIHRoZSBm b2xsb3dpbmcgdGV4dCBpbiBvcmRlciB0byBzYXRpc2Z5IHRoaXMgcmVxdWlyZW1lbnQuICBJIGhh dmUgY2hhbmdlZCBBbW9zJyBNVVNUcyB0byBTSE9VTERzIGJlY2F1c2UsIGluIHByYWN0aWNlLCBh cHBsaWNhdGlvbnMgdGhhdCBoYXZlIG5vIG9wdGlvbiBidXQgdG8gdXNlIHRoZSBVUkkgUXVlcnkg UGFyYW1ldGVyIG1ldGhvZCBhcmUgbGlrZWx5IHRvIGFsc28gbm90IGhhdmUgY29udHJvbCBvdmVy IHRoZSByZXF1ZXN0J3MgQ2FjaGUtQ29udHJvbCBkaXJlY3RpdmVzIChqdXN0IGFzIHRoZXkgZG8g bm90IGhhdmUgdGhlIGFiaWxpdHkgdG8gdXNlIGFuICJBdXRob3JpemF0aW9uOiBCZWFyZXIiIGhl YWRlciB2YWx1ZSk6DQo+Pj4+Pg0KPj4+Pj4gICAgIENsaWVudHMgdXNpbmcgdGhlIFVSSSBRdWVy eSBQYXJhbWV0ZXIgbWV0aG9kIFNIT1VMRCBhbHNvIHNlbmQgYQ0KPj4+Pj4gICAgIENhY2hlLUNv bnRyb2wgaGVhZGVyIGNvbnRhaW5pbmcgdGhlICJuby1zdG9yZSIgb3B0aW9uLiAgU2VydmVyIHN1 Y2Nlc3MNCj4+Pj4+ICAgICAoMlhYIHN0YXR1cykgcmVzcG9uc2VzIHRvIHRoZXNlIHJlcXVlc3Rz IFNIT1VMRCBjb250YWluIGEgQ2FjaGUtQ29udHJvbA0KPj4+Pj4gICAgIGhlYWRlciB3aXRoIHRo ZSAicHJpdmF0ZSIgb3B0aW9uLg0KPj4+Pj4NCj4+Pj4+IENvbW1lbnRzPw0KPj4+Pj4NCj4+Pj4+ ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAtLSANCj4+Pj4+IE1pa2UNCj4+Pj4+DQo+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPj4+Pj4gRnJvbTogQW1vcyBKZWZmcmllcw0KPj4+Pj4NCj4+Pj4+IE9uIDI0LzA0 LzIwMTIgNDozMyBwLm0uLCBNaWtlIEpvbmVzIHdyb3RlOg0KPj4+Pj4+IFdoYXQgc3BlY2lmaWMg bGFuZ3VhZ2Ugd291bGQgeW91IHN1Z2dlc3QgYmUgYWRkZWQgdG8gd2hhdCBzZWN0aW9uKHMpPw0K Pj4+Pj4+DQo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIC0tICAgICAgICAgIE1pa2UNCj4+Pj4+DQo+Pj4+PiBQZXJoYXBz ZSB0aGUgbGFzdCBwYXJhZ3JhcGggYXBwZW5kZWQ6DQo+Pj4+PiAiDQo+Pj4+Pg0KPj4+Pj4gICAg IEJlY2F1c2Ugb2YgdGhlIHNlY3VyaXR5IHdlYWtuZXNzZXMgYXNzb2NpYXRlZCB3aXRoIHRoZSBV UkkgbWV0aG9kDQo+Pj4+PiAgICAgKHNlZSBTZWN0aW9uIDUpLCBpbmNsdWRpbmcgdGhlIGhpZ2gg bGlrZWxpaG9vZCB0aGF0IHRoZSBVUkwNCj4+Pj4+ICAgICBjb250YWluaW5nIHRoZSBhY2Nlc3Mg dG9rZW4gd2lsbCBiZSBsb2dnZWQsIGl0IFNIT1VMRCBOT1QgYmUgdXNlZA0KPj4+Pj4gICAgIHVu bGVzcyBpdCBpcyBpbXBvc3NpYmxlIHRvIHRyYW5zcG9ydCB0aGUgYWNjZXNzIHRva2VuIGluIHRo ZQ0KPj4+Pj4gICAgICJBdXRob3JpemF0aW9uIiByZXF1ZXN0IGhlYWRlciBmaWVsZCBvciB0aGUg SFRUUCByZXF1ZXN0IGVudGl0eS1ib2R5Lg0KPj4+Pj4gICAgIFJlc291cmNlIHNlcnZlcnMgY29t cGxpYW50IHdpdGggdGhpcyBzcGVjaWZpY2F0aW9uIE1BWSBzdXBwb3J0IHRoaXMNCj4+Pj4+ICAg ICBtZXRob2QuDQo+Pj4+Pg0KPj4+Pj4gICAgIENsaWVudHMgcmVxdWVzdGluZyBVUkwgY29udGFp bmluZyB0aGUgYWNjZXNzIHRva2VuIE1VU1QgYWxzbyBzZW5kIGENCj4+Pj4+ICAgICBDYWNoZS1D b250cm9sIGhlYWRlciBjb250YWluaW5nIHRoZSAibm8tc3RvcmUiIG9wdGlvbi4gU2VydmVyIHN1 Y2Nlc3MNCj4+Pj4+ICAgICAoMnh4IHN0YXR1cykgcmVzcG9uc2VzIHRvIHRoZXNlIHJlcXVlc3Rz IE1VU1QgY29udGFpbiBhIENhY2hlLUNvbnRyb2wNCj4+Pj4+ICAgICBoZWFkZXIgd2l0aCB0aGUg InByaXZhdGUiIG9wdGlvbi4NCj4+Pj4+DQo+Pj4+PiAiDQo+Pj4+Pg0KPj4+Pj4gSSdtIGEgbGl0 dGxlIHN1c3BpY2lvdXMgdGhhdCB0aGUgIlNIT1VETCBOT1QiIGluIHRoYXQgdG9wIHBhcmFncmFw aCBsaWtlbHkgc2hvdWxkIGJlIGEgTVVTVCBOT1QgdG8gZnVydGhlciBkaXNjb3VyYWdlIG5lZWRs ZXNzIHVzZS4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4gQVlKDQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+PiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4+IEZyb206IG9hdXRoLWJvdW5jZXNAaWV0 Zi5vcmcgT24gQmVoYWxmIE9mIEFtb3MgSmVmZnJpZXMNCj4+Pj4+Pg0KPj4+Pj4+IE9uIDI0LjA0 LjIwMTIgMTM6NDYsIGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyB3cm90ZToNCj4+Pj4+Pj4gQSBO ZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgDQo+Pj4+Pj4+ IEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4gVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBv ZiB0aGUgDQo+Pj4+Pj4+IFdlYiBBdXRob3JpemF0aW9uIFByb3RvY29sIFdvcmtpbmcgR3JvdXAg b2YgdGhlIElFVEYuDQo+Pj4+Pj4+DQo+Pj4+Pj4+ICAgICAgICAgICAgVGl0bGUgICAgICAgICAg IDogVGhlIE9BdXRoIDIuMCBBdXRob3JpemF0aW9uIFByb3RvY29sOiBCZWFyZXINCj4+Pj4+Pj4g VG9rZW5zDQo+Pj4+Pj4+ICAgICAgICAgICAgQXV0aG9yKHMpICAgICAgIDogTWljaGFlbCBCLiBK b25lcw0KPj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRGljayBIYXJkdA0KPj4+ Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRGF2aWQgUmVjb3Jkb24NCj4+Pj4+Pj4g ICAgICAgICAgICBGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLW9hdXRoLXYyLWJlYXJlci0x OS50eHQNCj4+Pj4+Pj4gICAgICAgICAgICBQYWdlcyAgICAgICAgICAgOiAyNA0KPj4+Pj4+PiAg ICAgICAgICAgIERhdGUgICAgICAgICAgICA6IDIwMTItMDQtMjMNCj4+Pj4+Pj4NCj4+Pj4+Pj4g ICAgICBUaGlzIHNwZWNpZmljYXRpb24gZGVzY3JpYmVzIGhvdyB0byB1c2UgYmVhcmVyIHRva2Vu cyBpbiBIVFRQDQo+Pj4+Pj4+ICAgICAgcmVxdWVzdHMgdG8gYWNjZXNzIE9BdXRoIDIuMCBwcm90 ZWN0ZWQgcmVzb3VyY2VzLiAgQW55IHBhcnR5IGluDQo+Pj4+Pj4+ICAgICAgcG9zc2Vzc2lvbiBv ZiBhIGJlYXJlciB0b2tlbiAoYSAiYmVhcmVyIikgY2FuIHVzZSBpdCB0byBnZXQgDQo+Pj4+Pj4+ IGFjY2VzcyB0bw0KPj4+Pj4+PiAgICAgIHRoZSBhc3NvY2lhdGVkIHJlc291cmNlcyAod2l0aG91 dCBkZW1vbnN0cmF0aW5nIHBvc3Nlc3Npb24gb2YgYQ0KPj4+Pj4+PiAgICAgIGNyeXB0b2dyYXBo aWMga2V5KS4gIFRvIHByZXZlbnQgbWlzdXNlLCBiZWFyZXIgdG9rZW5zIG5lZWQgdG8gYmUNCj4+ Pj4+Pj4gICAgICBwcm90ZWN0ZWQgZnJvbSBkaXNjbG9zdXJlIGluIHN0b3JhZ2UgYW5kIGluIHRy YW5zcG9ydC4NCj4+Pj4+Pj4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gQSBVUkwgZm9yIHRoaXMgSW50ZXJu ZXQtRHJhZnQgaXM6DQo+Pj4+Pj4+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRz L2RyYWZ0LWlldGYtb2F1dGgtdjItYmVhcmVyLTENCj4+Pj4+Pj4gOS50eHQNCj4+Pj4+Pg0KPj4+ Pj4+IFRoZSBzZWN0aW9uIDIuMyAoVVJMIFF1ZXJ5IFBhcmFtZXRlcikgdGV4dCBpcyBzdGlsbCBs YWNraW5nIGV4cGxpY2l0IGFuZCBzcGVjaWZpYyBzZWN1cml0eSByZXF1aXJlbWVudHMuIFRoZSBv dmVyYXJjaGluZyBUTFMgcmVxdWlyZW1lbnQgaXMgZ29vZCBpbiBnZW5lcmFsLCBidXQgaW5zdWZm aWNpZW50IGluIHRoZSBwcmVzZW5jZSBvZiBIVFRQIGludGVybWVkaWFyaWVzIG9uIHRoZSBUTFMg Y29ubmVjdGlvbiBwYXRoIGFzIGlzIGJlY29taW5nIGEgY29tbW9uIHByYWN0aWNlLg0KPj4+Pj4+ DQo+Pj4+Pj4gVGhlIHVwY29taW5nIEhUVFBiaXMgc3BlY3MgZG9jdW1lbnQgdGhpcyBpc3N1ZSBh cyBhIHJlcXVpcmVtZW50IGZvciBuZXcgYXV0aCBzY2hlbWVzIHN1Y2ggYXMgQmVhcmVyOg0KPj4+ Pj4+DQo+Pj4+Pj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1odHRwYmlz LXA3LWF1dGgtMTkjc2VjdGlvbi0NCj4+Pj4+PiAyLjMuMQ0KPj4+Pj4+ICINCj4+Pj4+PiAgICAg ICAgICBUaGVyZWZvcmUsIG5ldyBhdXRoZW50aWNhdGlvbiBzY2hlbWVzIHdoaWNoIGNob29zZSBu b3QgdG8gY2FycnkNCj4+Pj4+PiAgICAgICAgICBjcmVkZW50aWFscyBpbiB0aGUgQXV0aG9yaXph dGlvbiBoZWFkZXIgKGUuZy4sIHVzaW5nIGEgbmV3bHkNCj4+Pj4+PiAgICAgICAgICBkZWZpbmVk IGhlYWRlcikgd2lsbCBuZWVkIHRvIGV4cGxpY2l0bHkgZGlzYWxsb3cgY2FjaGluZywgYnkNCj4+ Pj4+PiAgICAgICAgICBtYW5kYXRpbmcgdGhlIHVzZSBvZiBlaXRoZXIgQ2FjaGUtQ29udHJvbCBy ZXF1ZXN0IGRpcmVjdGl2ZXMNCj4+Pj4+PiAgICAgICAgICAoZS5nLiwgIm5vLXN0b3JlIikgb3Ig cmVzcG9uc2UgZGlyZWN0aXZlcyAoZS5nLiwgInByaXZhdGUiKS4NCj4+Pj4+PiAiDQo+Pj4+Pj4N Cj4+Pj4+Pg0KPj4+Pj4+IEFZSg0KPj4+Pj4+DQo+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+PiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4+ Pj4+PiBPQXV0aEBpZXRmLm9yZw0KPj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vb2F1dGgNCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+ PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4g T0F1dGggbWFpbGluZyBsaXN0DQo+Pj4+PiBPQXV0aEBpZXRmLm9yZw0KPj4+Pj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KPj4+PiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+PiBPQXV0aCBtYWlsaW5nIGxpc3QN Cj4+Pj4gT0F1dGhAaWV0Zi5vcmcNCj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9vYXV0aA0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4+IE9BdXRoIG1haWxpbmcgbGlzdA0KPj4gT0F1dGhAaWV0Zi5vcmcNCj4+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gT0F1dGggbWFpbGluZyBsaXN0 DQo+IE9BdXRoQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vb2F1dGgNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQo= From ve7jtb@ve7jtb.com Mon Jun 18 19:51:52 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44D4911E8080 for ; Mon, 18 Jun 2012 19:51:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.238 X-Spam-Level: X-Spam-Status: No, score=-3.238 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_65=0.6, 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 L01lL3GSwCox for ; Mon, 18 Jun 2012 19:51:49 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9EAEE21F8512 for ; Mon, 18 Jun 2012 19:51:49 -0700 (PDT) Received: by yhq56 with SMTP id 56so4845324yhq.31 for ; Mon, 18 Jun 2012 19:51:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=lW3px70BKGAKbRtgutgKhOJMrVHx3umsWpoQG68nObE=; b=EDMCybYplzE9HqNb3tJheNuC7cZyB0Ururp7NFek7DhiTe0d+LmxnOCzRNhoAAGyfo dP3I9LUTPIG9ZRjxL2KqClnn1Sc4zJB+Zr0w1T2b+XDXg5iBgKPxos6kXzn5MCw9MdJ6 D/FQNwl0tToBU3JxfD56fLsmsbStBy57JE5KZuHVXUEk4idV8+TD+Eu0i1VD5B6hxT7Z Cuw3bZcOf55VuJDOr0euXmafSeuj+LNq8p+K2CyUPwpBZyTkiCpnoWp9isu8JAUXah2Z U+7ll6ufpa2iKKURJDHcbTck4Or6R6ZI/ptIFSOT/st5kL1d1/Uui4cS8rGk1U8UrQu7 wPag== Received: by 10.236.75.227 with SMTP id z63mr20734062yhd.27.1340074309053; Mon, 18 Jun 2012 19:51:49 -0700 (PDT) Received: from [192.168.1.213] (190-20-29-46.baf.movistar.cl. [190.20.29.46]) by mx.google.com with ESMTPS id r45sm72775442yhg.18.2012.06.18.19.51.17 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 18 Jun 2012 19:51:47 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_686BA05C-6FCE-4AF9-81DE-93508A50C3C4"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <82D95BA2-1697-4441-BBB3-B2AE480DC39E@gmail.com> Date: Mon, 18 Jun 2012 22:50:51 -0400 Message-Id: References: <854774286EF8A240BACC342973A86EAC016693D6@BL2PRD0310MB387.namprd03.prod.outlook.com> <484A13D0-7C9A-42CC-BB94-3657741834DE@ve7jtb.com> <82D95BA2-1697-4441-BBB3-B2AE480DC39E@gmail.com> To: Dick Hardt X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQn+IltzqYYWH1L56BbQhJw/iZIjfBzpbm1RU0aj91iiz9J62liL0upd+8sTrF1NfuvIXhWs Cc: Yuchen Zhou , rui wang , Derek Atkins , "oauth@ietf.org" , "Shuo Chen \(MSR\)" Subject: Re: [OAUTH-WG] proposal of a paragraph to add to the security considerations section X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 02:51:52 -0000 --Apple-Mail=_686BA05C-6FCE-4AF9-81DE-93508A50C3C4 Content-Type: multipart/alternative; boundary="Apple-Mail=_26943525-3CF1-4CE6-8DB2-F33A768A3239" --Apple-Mail=_26943525-3CF1-4CE6-8DB2-F33A768A3239 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I can put something together. =20 It is mostly a warning about the token substitution attack that any = implicit flow is vulnerable to if used for authentication of the = presenter. Otherwise known as why audience restriction is a good thing. John B. On 2012-06-18, at 8:20 PM, Dick Hardt wrote: > John >=20 > Do you have suggested text per your suggestion below? >=20 > -- Dick >=20 > On Jun 18, 2012, at 2:04 PM, John Bradley wrote: >=20 >> I blogged about this in the hypothetical several months ago. = http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.h= tml >>=20 >> Nov Matake and others built some tests and found quite a number of = deployments vulnerable.=20 >> = http://www.thread-safe.com/2012/02/more-on-oauth-implicit-flow-application= .html >>=20 >> The bottom line is that OAuth has no explicit audience restriction = for tokens, hence accepting any token outside of the code flow is = subject to attack. >>=20 >> In general it is not a issue for authorization, it is however a big = issue then there is a presumption that the presenter of a token that = grants a client access to resource x is the "resource owner" of resource = x, when it is possible that the presenter is any client who has ever had = a access token for resource x. >>=20 >> We might want to include the why it is insecure in the security = consideration, otherwise people reading the below will likely ignore = the advice as it seems on the surface a touch extreme. >>=20 >> There are certainly OAuth flows that allow you to do authentication = safely, just not all of them without additional precautions. >>=20 >> That is why openID Connect has a audience restricted id_token similar = to Facebook's signed request to allow the implicit flows to be safely = used for authentication. >>=20 >> John B. >>=20 >>=20 >>=20 >>=20 >> On 2012-06-18, at 4:19 PM, Shuo Chen (MSR) wrote: >>=20 >>> Hi OAuth group, >>> =20 >>> This is regarding the recent discussion about an implementation = issue of some cloud services using OAuth for authentication. >>> Derek Atkins and Dick Hardt suggested the possibility to discuss = with the group a paragraph to add to the security considerations = section. >>> =20 >>> Derek=92s suggestion: >>> =3D=3D=3D=3D =3D=3D=3D =3D=3D=3D =3D=3D=3D >>> >> Perhaps you could boil it down to a paragraph >>> >> or two for addition to the security considerations section that = basically says >>> >> "beware of implementing it *this* way because it leads to *that* = attack vector", etc. >>> =3D=3D=3D=3D =3D=3D=3D =3D=3D=3D =3D=3D=3D >>> =20 >>> =20 >>> Here is out suggested text: >>> =3D=3D=3D=3D =3D=3D=3D =3D=3D=3D =3D=3D=3D >>> It has been observed that in multiple occasions that the server-side >>> authentication logic takes an access token from the client, then >>> queries the user's profile data from the IdP in order to >>> "authenticate" the user. This implementation must be forbidden. It >>> will allow an untrusted app running on a victim=92s client device to >>> work with an attacker=92s device to sign into the victim=92s account = on the server side. >>> =3D=3D=3D=3D =3D=3D=3D =3D=3D=3D =3D=3D=3D >>> =20 >>> =20 >>> Thank you. >>> -Shuo >>> p.s. below is the email thread giving a better context of the = discussion. >>> =20 >>> =20 >>> > -----Original Message----- >>> > From: Derek Atkins [mailto:derek@ihtfp.com] >>> > Sent: Monday, June 18, 2012 11:25 AM >>> > To: Shuo Chen (MSR) >>> > Cc: Hannes Tschofenig; rui wang; Stephen Farrell; Yuchen Zhou; = Derek >>> > Atkins; Dick Hardt >>> > Subject: Re: [OAUTH-WG] web sso study... >>> >=20 >>> > Hi, >>> >=20 >>> > "Shuo Chen (MSR)" writes: >>> >=20 >>> >> Hi Hannes, Derek and Stephen, >>> >>=20 >>> >> Thank you for your replies. >>> >>=20 >>> >>> First, let me ask whether it is OK if I share your post with the >>> >>> OAuth WG >>> >>=20 >>> >> Yes, please feel free to share it. >>> >>=20 >>> >>> Second, could you describe the attack in more details to me? >>> >>=20 >>> >> Let's consider the mobile+cloud scenario for concreteness = (although >>> >> some other scenarios are also applicable). The attack steps are = the >>> >> following: suppose Alice's tablet runs a Windows 8 Metro app = written >>> >> by attacker Bob. This app is able to request and obtain an access >>> >> token from the IdP (associated with Alice). The app can then send = the >>> >> access token to Bob's own tablet. Note that there is no security >>> >> problem up to this point. However the real problem is that some = cloud >>> >> services use the access token to query the user's profile data = from >>> >> the IdP in order to "authenticate" the user. In this case, Bob's >>> >> tablet will be able to sign into the cloud service as Alice. We = have >>> >> confirmed that the cloud services for Soluto Metro App, Givit = Metro >>> >> App and EuroCup2012 Metro App make this mistake. These are apps = in >>> >> the official Windows 8 App Store. We actually sampled only a = small portion of the available apps, but believe this is a vulnerability = pattern. >>> >>=20 >>> >> We don=92t think there is anything wrong in the OAuth spec. It is >>> >> developers who didn=92t comprehensively understand the usage of = the >>> >> access token. In the meanwhile, this vulnerability pattern is not = explicitly excluded by the spec. >>> >> More importantly, it has been seen in the wild. >>> >>=20 >>> >>> [from Derek's email] Perhaps you could boil it down to a = paragraph >>> >>> or two for >>> >> addition to the security considerations section that basically = says >>> >> "beware of implementing it *this* way because it leads to *that* = attack vector", etc. >>> >>=20 >>> >> This is a great idea. I think that although it is difficult to >>> >> anticipate in general all kinds of incomprehensive understandings = of >>> >> average developers, it is very worthwhile to take any common = existing >>> >> vulnerability pattern as a precious feedback to improve the >>> >> specification text. In this case, since we have already seen this >>> >> vulnerability pattern on multiple services in the wild, certainly = we >>> >> should be explicit about it in the security considerations = section. >>> >>=20 >>> >> Our suggested text: >>> >>=20 >>> >> It has been observed that in multiple occasions that the = server-side >>> >> authentication logic takes an access token from the client, then >>> >> queries the user's profile data from the IdP in order to >>> >> "authenticate" the user. This implementation must be forbidden. = It >>> >> will allow an untrusted app running on a victim=92s client device = to >>> >> work with an attacker=92s device to sign into the victim=92s = account on the server side. >>> >>=20 >>> >> Any questions or suggestions? >>> >=20 >>> > Could you please send this to the oauth@ietf.org mailing list? >>> >=20 >>> >> Thanks a lot. >>> >>=20 >>> >> -Shuo >>> >=20 >>> > -derek >>> >=20 >>> >> -----Original Message----- >>> >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>> >> Sent: Friday, June 15, 2012 11:36 AM >>> >> To: rui wang >>> >> Cc: Hannes Tschofenig; Stephen Farrell; Shuo Chen (MSR); Yuchen = Zhou; >>> >> Derek Atkins >>> >> Subject: Re: [OAUTH-WG] web sso study... >>> >>=20 >>> >> Hi Rui, >>> >>=20 >>> >> let me independently respond (in addition to the previous = responses >>> >> you had already gotten). >>> >>=20 >>> >> First, let me ask whether it is OK if I share your post with the >>> >> OAuth WG since it is more detailed than the one you distributed = on the list mid April. >>> >>=20 >>> >> Second, could you describe the attack in more details to me? What = I >>> >> would like to better understand whether this the raised issue is = a >>> >> problem with one of our specifications, with a specific >>> >> implementation of the IETF OAuth specifications, a problem with = other >>> >> OAuth related work (Facebook, as you know, implements far more = than >>> >> just the IETF OAuth specifications), a violation of the IETF = OAuth >>> >> specification in the way how the Websites use OAuth, whether this = is >>> >> a configuration related aspect, or an aspect we already = documented in the threats document. >>> >>=20 >>> >> The reason why I am so specific is to know where to put text to >>> >> address this issue or whether this is even an issue beyond the = IETF >>> >> OAuth working group and needs to be tackled somewhere else. >>> >>=20 >>> >> Ciao >>> >>=20 >>> >> Hannes >>> >> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 --Apple-Mail=_26943525-3CF1-4CE6-8DB2-F33A768A3239 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I can = put something together.   

It is mostly a = warning about the token substitution attack that any implicit flow is = vulnerable to if used for authentication of the presenter.
Otherwise = known as why audience restriction is a good = thing.

John = B.

On 2012-06-18, at 8:20 PM, Dick = Hardt wrote:

I = blogged about this in the hypothetical several months ago. http://www.thread-safe.com/2012/01/problem-with-oauth-for-aut= hentication.html

Nov Matake and others built some = tests and found quite a number of deployments = vulnerable. 

The bottom line is = that OAuth has no explicit audience restriction for tokens,  hence = accepting any token outside of the code flow is subject to = attack.

In general it is not a issue for = authorization,  it is however a big issue then there is a = presumption that the presenter of a token that grants a client access to = resource x is the "resource owner" of resource x, when it is possible = that the presenter is any client who has ever had a access token for = resource x.

We might want to include the why it = is insecure in the security consideration,  otherwise people = reading the below will likely ignore the advice as it seems on the = surface a touch extreme.

There are certainly = OAuth flows that allow you to do authentication safely,  just not = all of them without additional = precautions.

That is why openID Connect has a = audience restricted id_token similar to Facebook's signed request to = allow the implicit flows to be safely used for = authentication.

John = B.




On = 2012-06-18, at 4:19 PM, Shuo Chen (MSR) wrote:

Hi OAuth = group,
 
This is regarding = the recent discussion about an implementation issue of some cloud = services using OAuth for authentication.
Derek Atkins and Dick Hardt suggested the possibility to = discuss with the group a paragraph to add to the security considerations = section.
 
Derek=92s suggestion:
=3D=3D=3D=3D   =3D=3D=3D  =3D=3D=3D  = =3D=3D=3D
>> Perhaps you could boil it = down to a paragraph
>> or two for addition = to the security considerations section that basically = says
>> "beware of implementing it *this* way = because it leads to *that* attack vector", etc.
=3D=3D=3D=3D   =3D=3D=3D  =3D=3D=3D  = =3D=3D=3D
 
 
Here is out suggested = text:
=3D=3D=3D=3D   =3D=3D=3D  = =3D=3D=3D  =3D=3D=3D
It has been observed that in = multiple occasions that the server-side
authentication logic takes an access token from the = client, then
queries the user's profile = data from the IdP in order to
"authenticate" the = user. This implementation must be forbidden. It
will allow an untrusted app running on a victim=92s client = device to
work with an attacker=92s device to = sign into the victim=92s account on the server = side.
=3D=3D=3D=3D   =3D=3D=3D  = =3D=3D=3D  =3D=3D=3D
 
 
Thank = you.
-Shuo
p.s. below is the = email thread giving a better context of the = discussion.
 
 
> -----Original = Message-----
> From: Derek Atkins = [mailto:derek@ihtfp.com]
> Sent: Monday, June 18, = 2012 11:25 AM
> To: Shuo Chen = (MSR)
> Cc: Hannes Tschofenig; rui wang; Stephen = Farrell; Yuchen Zhou; Derek
> Atkins; Dick = Hardt
> Subject: Re: [OAUTH-WG] web sso = study...
> 
> Hi,
> "Shuo Chen (MSR)" <shuochen@microsoft.com> = writes:
> 
>> Hi Hannes, Derek and = Stephen,
>> 
>> Thank you for your replies.
>> 
>>> First, = let me ask whether it is OK if I share your post with = the
>>> OAuth WG
>> 
>> Yes, = please feel free to share it.
>>> Second, could you = describe the attack in more details to me?
>> 
>> Let's = consider the mobile+cloud scenario for concreteness = (although
>> some other scenarios are = also applicable). The attack steps are the
>> following: suppose Alice's tablet runs a Windows = 8 Metro app written
>> by attacker Bob. This = app is able to request and obtain an access
>> token from the IdP (associated with Alice). The = app can then send the
>> access token to Bob's = own tablet. Note that there is no security
>> problem up to this point. However the real = problem is that some cloud
>> services = use the access token to query the user's profile data = from
>> the IdP in order to "authenticate" the = user. In this case, Bob's
>> tablet will be able = to sign into the cloud service as Alice. We have
>> confirmed that the cloud services for Soluto = Metro App, Givit Metro
>> App and EuroCup2012 = Metro App make this mistake. These are apps in
>> the official Windows 8 App Store. We actually = sampled only a small portion of the available apps, but believe this is = a vulnerability pattern.
>> We don=92t think = there is anything wrong in the OAuth spec. It is
>> developers who didn=92t comprehensively = understand the usage of the
>> access = token. In the meanwhile, this vulnerability pattern is not explicitly = excluded by the spec.
>> More importantly, it = has been seen in the wild.
>>> [from Derek's = email] Perhaps you could boil it down to a = paragraph
>>> or two = for
>> addition to the security considerations = section that basically says
>> "beware of = implementing it *this* way because it leads to *that* attack vector", = etc.
>> 
>> This is a great idea. I think that although it is = difficult to
>> anticipate in general = all kinds of incomprehensive understandings of
>> average developers, it is very worthwhile to take = any common existing
>> vulnerability pattern = as a precious feedback to improve the
>> specification text. In this case, since we have = already seen this
>> vulnerability pattern = on multiple services in the wild, certainly we
>> should be explicit about it in the security = considerations section.
>> Our suggested = text:
>> 
>> It has been observed that in multiple occasions = that the server-side
>> authentication logic = takes an access token from the client, then
>> queries the user's profile data from the IdP in = order to
>> "authenticate" the user. = This implementation must be forbidden. It
>> will allow an untrusted app running on a victim=92s= client device to
>> work with an = attacker=92s device to sign into the victim=92s account on the server = side.
>> 
>> Any questions or = suggestions?
> Could you please send = this to the oauth@ietf.org mailing = list?
> 
>> Thanks a lot.
>> 
>> = -Shuo
> 
> -derek
>> -----Original = Message-----
>> From: Hannes = Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
>> Sent: Friday, June 15, 2012 11:36 = AM
>> To: rui wang
>> Cc: Hannes Tschofenig; Stephen Farrell; Shuo Chen = (MSR); Yuchen Zhou;
>> Derek = Atkins
>> Subject: Re: [OAUTH-WG] web sso = study...
>> 
>> Hi Rui,
>> let me independently = respond (in addition to the previous responses
>> you had already gotten).
>> 
>> First, let = me ask whether it is OK if I share your post with = the
>> OAuth WG since it is more detailed than = the one you distributed on the list mid April.
>> 
>> Second, = could you describe the attack in more details to me? What = I
>> would like to better understand whether = this the raised issue is a
>> problem = with one of our specifications, with a specific
>> implementation of the IETF OAuth specifications, = a problem with other
>> OAuth related work = (Facebook, as you know, implements far more than
>> just the IETF OAuth specifications), a violation = of the IETF OAuth
>> specification in the = way how the Websites use OAuth, whether this is
>> a configuration related aspect, or an aspect we = already documented in the threats document.
>> 
>> The reason = why I am so specific is to know where to put text = to
>> address this issue or whether this is = even an issue beyond the IETF
>> OAuth = working group and needs to be tackled somewhere = else.
>> 
>> Ciao
>> = Hannes


= --Apple-Mail=_26943525-3CF1-4CE6-8DB2-F33A768A3239-- --Apple-Mail=_686BA05C-6FCE-4AF9-81DE-93508A50C3C4 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw 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+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDYx OTAyNTA1MlowIwYJKoZIhvcNAQkEMRYEFHbLpCzbwLwgja//ILWHr5j/MAGEMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB AHj7FM4D/AYxly/Wv7DX+Pd2ECEkJZTFnEbVdXaebfzse7p8jBcL/LpTBdyMAxQYnFf0+YZlrliM XmBtxmSKGw2JfOaCzfhGMXyD9RUnsAv9otsZzUfivmcK2Z+PwbgHeyWgxp0fymMNGBFEOYeGeKQU mFU/gT2R/0jnbFD4A9cDlSBtRzeDVvi0ISMFVXp25O6eBDcnAR4IZbRGxEeoY24kCBx23WMRUQ1z UEwODpekGF9VOdi0WBSkb4411FExBti3j9XCCuiH1LwREkZfdycjTA8tAZLUli4wOI6lCIlPoRmN 49k8efUy9yCWcf/rqCux6brkl9nv2gUp+MrlmhcAAAAAAAA= --Apple-Mail=_686BA05C-6FCE-4AF9-81DE-93508A50C3C4-- From squid3@treenet.co.nz Mon Jun 18 21:59:05 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AC3121F863D for ; Mon, 18 Jun 2012 21:59:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.63 X-Spam-Level: X-Spam-Status: No, score=-5.63 tagged_above=-999 required=5 tests=[AWL=-4.968, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_EQ_STATIC=1.172] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IeVUZQD4XvtJ for ; Mon, 18 Jun 2012 21:58:59 -0700 (PDT) Received: from treenet.co.nz (ip-58-28-153-233.static-xdsl.xnet.co.nz [58.28.153.233]) by ietfa.amsl.com (Postfix) with ESMTP id 2488721F8615 for ; Mon, 18 Jun 2012 21:58:56 -0700 (PDT) Received: from [192.168.1.100] (unknown [101.98.102.102]) by treenet.co.nz (Postfix) with ESMTP id B26FEE6E89 for ; Tue, 19 Jun 2012 16:58:53 +1200 (NZST) Message-ID: <4FE00704.5080900@treenet.co.nz> Date: Tue, 19 Jun 2012 16:58:44 +1200 From: Amos Jeffries User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: oauth@ietf.org References: <4E1F6AAD24975D4BA5B16804296739436652FBFC@TK5EX14MBXC284.redmond.corp.microsoft.com> <4FD6445B.8020904@lodderstedt.net> <2FCFF7EB-7E34-49F7-93EE-F57729E420F2@oracle.com> <4FD6DC6E.80408@lodderstedt.net> <4E1F6AAD24975D4BA5B16804296739436655AB5B@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436655AB5B@TK5EX14MBXC283.redmond.corp.microsoft.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [OAUTH-WG] Cache-Control headers for Bearer URI Query Parameter method X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2012 04:59:05 -0000 On 19/06/2012 12:54 p.m., Mike Jones wrote: > Could the experts on this thread please summarize the outcome of this thread? Was the conclusion that no changes were required to either Core or Bearer? Or if you believe that changes are required to one or both drafts, could you please propose exact wording changes for review by the working group? IMHO they are correct as-is. No changes need be made to either. AYJ > > Thanks, > -- Mike > > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Torsten Lodderstedt > Sent: Monday, June 11, 2012 11:07 PM > To: Phil Hunt > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] Cache-Control headers for Bearer URI Query Parameter method > > thanks a lot > > Am 12.06.2012 01:03, schrieb Phil Hunt: >> Thanks. That makes sense. >> >> Phil >> >> On 2012-06-11, at 15:39, Amos Jeffries wrote: >> >>> On 12.06.2012 07:23, Phil Hunt wrote: >>>> Private also seems inappropriate since no operation should be cached >>>> for oauth as even when the same requestor. >>>> >>>> Phil >>>> >>> There is a difference in HTTP use-case between what the Bearer and core specs are covering. >>> >>> The core spec appears to be covering the request/response messages transferring credentials in the response entity. These mandate "no-store", which adds strict erasure requirements for any middleware and browser caches handling the response. Even single-user caches like a browser are not allowed to store the HTTP copy of the credentials response. >>> >>> Bearer is requiring "private" only in the specific HTTP case where the token is in query params and response is some data object (ie images or HTML page). Such that trusted proxies and other third-parties who do not implement OAuth but do relay HTTP treat the request and reply securely. With uses of Bearer via HTTP authentication framework this "private" is implicit. >>> In these cases the response MAY be cached by a private browser cache, but not by third-party proxies. no-store is overkill and wastes bandwidth in this case. >>> >>> >>> I hope this clarifies. >>> >>> >>> AYJ >>> >>> >>>> On 2012-06-11, at 12:17, Torsten Lodderstedt wrote: >>>> >>>>> Hi all, >>>>> >>>>> I noticed a difference in usage of cache control headers between bearer and core spec. >>>>> >>>>> core -27 states: >>>>> >>>>> " The authorization server MUST include the HTTP "Cache-Control" >>>>> response header field [RFC2616] with a value of "no-store" in any >>>>> response containing tokens, credentials, or other sensitive >>>>> information, as well as the "Pragma" response header field [RFC2616] >>>>> with a value of "no-cache"." >>>>> >>>>> So a "Pragma" response header field is required instead of the "Cache-Control" header "private". >>> Not instead of. *As well as*. Pragma "no-cache" only tells the third-party to revalidate before using the response, it does not prevent storage and thus potential data leakage. >>> >>> >>>>> As far as I understand, both specs are nearly but not fully equivalent. Do we need to align both? >>>>> >>>>> regards, >>>>> Torsten. >>>>> >>>>> Am 09.06.2012 00:20, schrieb Mike Jones: >>>>>> Hi Amos, >>>>>> >>>>>> The OAuth Bearer specification now includes the Cache-Control language we’d discussed. >>>>>> >>>>>> See the fifth paragraph of http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-20#section-2.3. >>>>>> >>>>>> Thanks again, >>>>>> -- >>>>>> Mike >>>>>> >>>>>> >>>>>> From: oauth-bounces@ietf.org On Behalf Of Mike Jones >>>>>> Sent: Thursday, May 17, 2012 3:12 PM >>>>>> Subject: [OAUTH-WG] Cache-Control headers for Bearer URI Query >>>>>> Parameter method >>>>>> >>>>>> Dear working group members: >>>>>> >>>>>> I'm going through the remaining open issues that have been raised about the Bearer spec so as to be ready to publish an updated draft once the outstanding consensus call issues are resolved. >>>>>> >>>>>> Amos Jeffries had cited this requirement in the HTTPbis spec ( http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-19#section-2.3.1): >>>>>> >>>>>> o The credentials carried in an Authorization header field are >>>>>> specific to the User Agent, and therefore have the same effect on >>>>>> HTTP caches as the "private" Cache-Control response directive, >>>>>> within the scope of the request they appear in. >>>>>> >>>>>> Therefore, new authentication schemes which choose not to carry >>>>>> credentials in the Authorization header (e.g., using a newly >>>>>> defined header) will need to explicitly disallow caching, by >>>>>> mandating the use of either Cache-Control request directives >>>>>> (e.g., "no-store") or response directives (e.g., "private"). >>>>>> >>>>>> I propose to add the following text in order to satisfy this requirement. I have changed Amos' MUSTs to SHOULDs because, in practice, applications that have no option but to use the URI Query Parameter method are likely to also not have control over the request's Cache-Control directives (just as they do not have the ability to use an "Authorization: Bearer" header value): >>>>>> >>>>>> Clients using the URI Query Parameter method SHOULD also send a >>>>>> Cache-Control header containing the "no-store" option. Server success >>>>>> (2XX status) responses to these requests SHOULD contain a Cache-Control >>>>>> header with the "private" option. >>>>>> >>>>>> Comments? >>>>>> >>>>>> -- >>>>>> Mike >>>>>> >>>>>> -----Original Message----- >>>>>> From: Amos Jeffries >>>>>> >>>>>> On 24/04/2012 4:33 p.m., Mike Jones wrote: >>>>>>> What specific language would you suggest be added to what section(s)? >>>>>>> >>>>>>> -- Mike >>>>>> Perhapse the last paragraph appended: >>>>>> " >>>>>> >>>>>> Because of the security weaknesses associated with the URI method >>>>>> (see Section 5), including the high likelihood that the URL >>>>>> containing the access token will be logged, it SHOULD NOT be used >>>>>> unless it is impossible to transport the access token in the >>>>>> "Authorization" request header field or the HTTP request entity-body. >>>>>> Resource servers compliant with this specification MAY support this >>>>>> method. >>>>>> >>>>>> Clients requesting URL containing the access token MUST also send a >>>>>> Cache-Control header containing the "no-store" option. Server success >>>>>> (2xx status) responses to these requests MUST contain a Cache-Control >>>>>> header with the "private" option. >>>>>> >>>>>> " >>>>>> >>>>>> I'm a little suspicious that the "SHOUDL NOT" in that top paragraph likely should be a MUST NOT to further discourage needless use. >>>>>> >>>>>> >>>>>> AYJ >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: oauth-bounces@ietf.org On Behalf Of Amos Jeffries >>>>>>> >>>>>>> On 24.04.2012 13:46, 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 : The OAuth 2.0 Authorization Protocol: Bearer >>>>>>>> Tokens >>>>>>>> Author(s) : Michael B. Jones >>>>>>>> Dick Hardt >>>>>>>> David Recordon >>>>>>>> Filename : draft-ietf-oauth-v2-bearer-19.txt >>>>>>>> Pages : 24 >>>>>>>> Date : 2012-04-23 >>>>>>>> >>>>>>>> This specification describes how to use bearer tokens in HTTP >>>>>>>> requests to access OAuth 2.0 protected resources. Any party in >>>>>>>> possession of a bearer token (a "bearer") can use it to get >>>>>>>> access to >>>>>>>> the associated resources (without demonstrating possession of a >>>>>>>> cryptographic key). To prevent misuse, bearer tokens need to be >>>>>>>> protected from disclosure in storage and in transport. >>>>>>>> >>>>>>>> >>>>>>>> A URL for this Internet-Draft is: >>>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-1 >>>>>>>> 9.txt >>>>>>> The section 2.3 (URL Query Parameter) text is still lacking explicit and specific security requirements. The overarching TLS requirement is good in general, but insufficient in the presence of HTTP intermediaries on the TLS connection path as is becoming a common practice. >>>>>>> >>>>>>> The upcoming HTTPbis specs document this issue as a requirement for new auth schemes such as Bearer: >>>>>>> >>>>>>> http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-19#section- >>>>>>> 2.3.1 >>>>>>> " >>>>>>> Therefore, new authentication schemes which choose not to carry >>>>>>> credentials in the Authorization header (e.g., using a newly >>>>>>> defined header) will need to explicitly disallow caching, by >>>>>>> mandating the use of either Cache-Control request directives >>>>>>> (e.g., "no-store") or response directives (e.g., "private"). >>>>>>> " >>>>>>> >>>>>>> >>>>>>> AYJ >>>>>>> >>>>>>> _______________________________________________ >>>>>>> OAuth mailing 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 From julian.reschke@gmx.de Mon Jun 18 23:07:05 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F06E221F85E1 for ; Mon, 18 Jun 2012 23:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.639 X-Spam-Level: X-Spam-Status: No, score=-105.639 tagged_above=-999 required=5 tests=[AWL=-3.040, 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 YX6Qcx+GIWMM for ; Mon, 18 Jun 2012 23:07:05 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 7EC0921F85E5 for ; Mon, 18 Jun 2012 23:07:04 -0700 (PDT) Received: (qmail invoked by alias); 19 Jun 2012 06:07:02 -0000 Received: from p5DD95DFC.dip.t-dialin.net (EHLO [192.168.178.36]) [93.217.93.252] by mail.gmx.net (mp040) with SMTP; 19 Jun 2012 08:07:02 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19KrxlhHddK7wi+NxjZUqq3u+5YkvlSdOHvTwxbAs BdNC9VYNGJgSzq Message-ID: <4FE01704.50007@gmx.de> Date: Tue, 19 Jun 2012 08:07:00 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Mike Jones References: <4FD70812.6040108@gmx.de> <4E1F6AAD24975D4BA5B16804296739436655A58E@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436655A58E@TK5EX14MBXC283.redmond.corp.microsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] nits about definition of using form parameters X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 06:07:06 -0000 On 2012-06-18 23:48, Mike Jones wrote: > Hi Julian, > > Both the Core and Bearer specs already reference W3C.REC-html401-19991224 for the definition of application/x-www-form-urlencoded. That definition is useless because it doesn't specify character encoding. > I'll leave it up to others to comment on whether the ;charset=UTF-8 parameter is correct or not. I think the specification is quite clear on that. Best regards, Julian From julian.reschke@gmx.de Mon Jun 18 23:17:45 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7181211E8083 for ; Mon, 18 Jun 2012 23:17:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.466 X-Spam-Level: X-Spam-Status: No, score=-105.466 tagged_above=-999 required=5 tests=[AWL=-2.867, 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 7GjOhYmQX4Qv for ; Mon, 18 Jun 2012 23:17:44 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 5070811E8073 for ; Mon, 18 Jun 2012 23:17:44 -0700 (PDT) Received: (qmail invoked by alias); 19 Jun 2012 06:17:42 -0000 Received: from p5DD95DFC.dip.t-dialin.net (EHLO [192.168.178.36]) [93.217.93.252] by mail.gmx.net (mp024) with SMTP; 19 Jun 2012 08:17:42 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+itVNdnZuiKXYSlj0sA7GTXTtCn+cC7y6TEbeVVu oVlZrpGqtIxcdY Message-ID: <4FE01984.50603@gmx.de> Date: Tue, 19 Jun 2012 08:17:40 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Mike Jones References: <4E1F6AAD24975D4BA5B16804296739436655A85E@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436655A85E@TK5EX14MBXC283.redmond.corp.microsoft.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Proposed OAuth Core -28 X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 06:17:45 -0000 On 2012-06-19 02:03, Mike Jones wrote: > In cooperation with the chairs and Eran, I’ve produced the attached > proposed OAuth Core -28 version. It updates the ABNF in the manner > discussed by the working group, allowing username and password to be > Unicode and restricting client_id and client_secret to ASCII. It > specifies the use of the application/x-www-form-urlencoded content-type > encoding method to encode the client_id when used as the password for > HTTP Basic. A few minor grammar errors encountered were also > corrected. Normative changes are in sections 2.3.1, A.1, A.2, A.15, and > A.16. Unless I hear objections, I’ll use the publication tool to post > this as -28 at close of business tomorrow, with Eran being the one to > give approval in the tool for publication. I note that the ABNF is still unchanged with respect to the confusion about octets vs characters. You can't silently mix both. If the ABNF defines character sequences, you should say that upfront, and then need to specify how to map to octet sequences on the wire. If it's a mix, you need to mark the special cases. Again, an example for a spec doing this here: Best regards, Julian From julian.reschke@gmx.de Mon Jun 18 23:18:55 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C717811E8083 for ; Mon, 18 Jun 2012 23:18:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.245 X-Spam-Level: X-Spam-Status: No, score=-105.245 tagged_above=-999 required=5 tests=[AWL=-2.646, 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 pu3c73HVFsxw for ; Mon, 18 Jun 2012 23:18:55 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id CB48311E8073 for ; Mon, 18 Jun 2012 23:18:54 -0700 (PDT) Received: (qmail invoked by alias); 19 Jun 2012 06:18:53 -0000 Received: from p5DD95DFC.dip.t-dialin.net (EHLO [192.168.178.36]) [93.217.93.252] by mail.gmx.net (mp017) with SMTP; 19 Jun 2012 08:18:53 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+BFFA90PGBzKkDgNlpDvVcWeAsBbJnMwTXgJFUIV ItomaYQ0ZdiPkw Message-ID: <4FE019CC.1050609@gmx.de> Date: Tue, 19 Jun 2012 08:18:52 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Eran Hammer References: <4FD70812.6040108@gmx.de> <4E1F6AAD24975D4BA5B16804296739436655A58E@TK5EX14MBXC283.redmond.corp.microsoft.com> <0CBAEB56DDB3A140BA8E8C124C04ECA201077978@P3PWEX2MB008.ex2.secureserver.net> In-Reply-To: <0CBAEB56DDB3A140BA8E8C124C04ECA201077978@P3PWEX2MB008.ex2.secureserver.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] nits about definition of using form parameters X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 06:18:55 -0000 On 2012-06-19 00:17, Eran Hammer wrote: > I believe the UTF-8 piece came from Brian Eaton a while back because of some security issue identified at Google. > ... If there are security reasons to send an undefined media type parameter then they really should be spelled out. Best regards, Julian From internet-drafts@ietf.org Tue Jun 19 21:50:39 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6C3621F86F0; Tue, 19 Jun 2012 21:50:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.441 X-Spam-Level: X-Spam-Status: No, score=-102.441 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nQB6gQblPrP9; Tue, 19 Jun 2012 21:50:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EA8721F86EA; Tue, 19 Jun 2012 21:50:35 -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.20 Message-ID: <20120620045035.19569.23598.idtracker@ietfa.amsl.com> Date: Tue, 19 Jun 2012 21:50:35 -0700 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-28.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2012 04:50:39 -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 : The OAuth 2.0 Authorization Framework Author(s) : Eran Hammer David Recordon Dick Hardt Filename : draft-ietf-oauth-v2-28.txt Pages : 70 Date : 2012-06-19 Abstract: The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-v2 There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-v2-28 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-v2-28 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Tue Jun 19 21:55:43 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E733121F86FF; Tue, 19 Jun 2012 21:55:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.488 X-Spam-Level: X-Spam-Status: No, score=-102.488 tagged_above=-999 required=5 tests=[AWL=0.111, 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 CHP8o2tsF7DR; Tue, 19 Jun 2012 21:55:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8F5921F86F3; Tue, 19 Jun 2012 21:55:41 -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.20 Message-ID: <20120620045541.29351.62466.idtracker@ietfa.amsl.com> Date: Tue, 19 Jun 2012 21:55:41 -0700 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-21.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2012 04:55:43 -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 : The OAuth 2.0 Authorization Framework: Bearer Token Usage Author(s) : Michael B. Jones Dick Hardt David Recordon Filename : draft-ietf-oauth-v2-bearer-21.txt Pages : 26 Date : 2012-06-19 Abstract: This specification describes how to use bearer tokens in HTTP requests to access OAuth 2.0 protected resources. Any party in possession of a bearer token (a "bearer") can use it to get access to the associated resources (without demonstrating possession of a cryptographic key). To prevent misuse, bearer tokens need to be protected from disclosure in storage and in transport. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-bearer There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-21 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-v2-bearer-21 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Michael.Jones@microsoft.com Tue Jun 19 21:57:24 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A58E621F8735 for ; Tue, 19 Jun 2012 21:57:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.813 X-Spam-Level: X-Spam-Status: No, score=-3.813 tagged_above=-999 required=5 tests=[AWL=-0.215, 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 MxzZD5xER7c9 for ; Tue, 19 Jun 2012 21:57:20 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe003.messaging.microsoft.com [213.199.154.206]) by ietfa.amsl.com (Postfix) with ESMTP id C8BA821F8731 for ; Tue, 19 Jun 2012 21:57:19 -0700 (PDT) Received: from mail118-am1-R.bigfish.com (10.3.201.239) by AM1EHSOBE005.bigfish.com (10.3.204.25) with Microsoft SMTP Server id 14.1.225.23; Wed, 20 Jun 2012 04:55:55 +0000 Received: from mail118-am1 (localhost [127.0.0.1]) by mail118-am1-R.bigfish.com (Postfix) with ESMTP id 5BB771A012A for ; Wed, 20 Jun 2012 04:55:55 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -19 X-BigFish: VS-19(zzc85fhzz1202hzz1033IL8275eh8275bh8275dha1495iz2fh2a8h668h839hd25hf0ah) Received-SPF: pass (mail118-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail118-am1 (localhost.localdomain [127.0.0.1]) by mail118-am1 (MessageSwitch) id 1340168153208707_28739; Wed, 20 Jun 2012 04:55:53 +0000 (UTC) Received: from AM1EHSMHS001.bigfish.com (unknown [10.3.201.245]) by mail118-am1.bigfish.com (Postfix) with ESMTP id 3136D200047 for ; Wed, 20 Jun 2012 04:55:53 +0000 (UTC) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS001.bigfish.com (10.3.207.101) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 20 Jun 2012 04:55:52 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.53]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.02.0298.005; Wed, 20 Jun 2012 04:57:11 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: OAuth Core -28 and Bearer -21 specs published Thread-Index: Ac1OoSGuaSOU0vo6TGKJuu+TMXt96w== Date: Wed, 20 Jun 2012 04:57:10 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436655E392@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.36] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436655E392TK5EX14MBXC283r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: [OAUTH-WG] OAuth Core -28 and Bearer -21 specs 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: Wed, 20 Jun 2012 04:57:24 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436655E392TK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable OAuth Core draft -28 has been published. Changes were: * Updated the ABNF in the manner discussed by the working group, all= owing username and password to be Unicode and restricting client_id and cli= ent_secret to ASCII. * Specifies the use of the application/x-www-form-urlencoded content= -type encoding method to encode the client_id when used as the password for= HTTP Basic. OAuth Bearer draft -21 has also been published. Changes were: * Changed "NOT RECOMMENDED" to "not recommended" in caveat about the= URI Query Parameter method. * Changed "other specifications may extend this specification for us= e with other transport protocols" to "other specifications may extend this = specification for use with other protocols". * Changed Acknowledgements to use only ASCII characters, per the RFC= style guide. The drafts are available at: * http://tools.ietf.org/html/draft-ietf-oauth-v2-28 * http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-21 HTML-formatted versions are available at: * http://self-issued.info/docs/draft-ietf-oauth-v2-28.html * http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-21.html Thanks to Eran Hammer for approving the Core draft posting. -- Mike --_000_4E1F6AAD24975D4BA5B16804296739436655E392TK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

OAuth Core draft -28 has been published.  Chang= es were:

·        Updated the ABNF in the manner discussed by = the working group, allowing username and password to be Unicode and restricting client_id and cl= ient_secret to ASCII.

·        Specifies the use of the application/x-www-f= orm-urlencoded content-type encoding method to encode the client_id when u= sed as the password for HTTP Basic.

 

OAuth Bearer draft -21 has also been published. = ; Changes were:

·        Changed "NOT RECOMMENDED" to "= ;not recommended" in caveat about the URI Query Parameter method.=

·        Changed "other specifications may exten= d this specification for use with other transport protocols" to "= other specifications may extend this specification for use with other proto= cols".

·        Changed Acknowledgements to use only ASCII c= haracters, per the RFC style guide.

The drafts are available at:

·        http://tools.ietf.org/html/draft-ietf-oauth-v2-28

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

 

HTML-formatted versions are available at:=

·        http://self-issued.info/docs/draft-ietf-oauth-v2-2= 8.html

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

 

Thanks to Eran Hammer for approving the Core draft p= osting.

 

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

 

--_000_4E1F6AAD24975D4BA5B16804296739436655E392TK5EX14MBXC283r_-- From julian.reschke@gmx.de Wed Jun 20 00:13:07 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1B8D21F86F5 for ; Wed, 20 Jun 2012 00:13:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.916 X-Spam-Level: X-Spam-Status: No, score=-103.916 tagged_above=-999 required=5 tests=[AWL=-1.317, 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 1qqq5UAdajnA for ; Wed, 20 Jun 2012 00:13:07 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 767A521F86E0 for ; Wed, 20 Jun 2012 00:13:06 -0700 (PDT) Received: (qmail invoked by alias); 20 Jun 2012 07:13:04 -0000 Received: from p54BB341D.dip.t-dialin.net (EHLO [192.168.178.36]) [84.187.52.29] by mail.gmx.net (mp041) with SMTP; 20 Jun 2012 09:13:04 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+NGQZZ3/+NTXbQDqlepHTMUpQFCYr+kQgAsZK9wy RaVf1FKPtgjhzI Message-ID: <4FE177FE.6000106@gmx.de> Date: Wed, 20 Jun 2012 09:13:02 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Mike Jones References: <4E1F6AAD24975D4BA5B16804296739436655E392@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436655E392@TK5EX14MBXC283.redmond.corp.microsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth Core -28 and Bearer -21 specs 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: Wed, 20 Jun 2012 07:13:08 -0000 On 2012-06-20 06:57, Mike Jones wrote: > OAuth Core draft -28 has been published. Changes were: > > ·Updated the ABNF in the manner discussed by the working group, allowing > username and password to be Unicode and restricting client_id and > client_secret to ASCII. > > ·Specifies the use of the application/x-www-form-urlencoded content-type > encoding method to encode the client_id when used as the password for > HTTP Basic. > ... Well, you asked for feedback, you got it (repeatedly), and you ignore it. This is getting frustrating. Best regards, Julian From eran@hueniverse.com Wed Jun 20 04:07:31 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B10221F85DD for ; Wed, 20 Jun 2012 04:07:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vFNnJoL2qng8 for ; Wed, 20 Jun 2012 04:07:30 -0700 (PDT) Received: from p3plex2out03.prod.phx3.secureserver.net (p3plex2out03.prod.phx3.secureserver.net [184.168.131.16]) by ietfa.amsl.com (Postfix) with ESMTP id C70B021F85C9 for ; Wed, 20 Jun 2012 04:07:30 -0700 (PDT) Received: from P3PWEX2HT001.ex2.secureserver.net ([184.168.131.9]) by p3plex2out03.prod.phx3.secureserver.net with bizsmtp id Qb7W1j0030CJzpC01b7WNl; Wed, 20 Jun 2012 04:07:30 -0700 Received: from P3PWEX2MB008.ex2.secureserver.net ([169.254.8.66]) by P3PWEX2HT001.ex2.secureserver.net ([184.168.131.9]) with mapi id 14.02.0247.003; Wed, 20 Jun 2012 04:07:29 -0700 From: Eran Hammer To: Julian Reschke , Mike Jones Thread-Topic: [OAUTH-WG] OAuth Core -28 and Bearer -21 specs published Thread-Index: Ac1OoSGuaSOU0vo6TGKJuu+TMXt96wATavIAAAaHFUA= Date: Wed, 20 Jun 2012 11:07:29 +0000 Message-ID: <0CBAEB56DDB3A140BA8E8C124C04ECA20107A348@P3PWEX2MB008.ex2.secureserver.net> References: <4E1F6AAD24975D4BA5B16804296739436655E392@TK5EX14MBXC283.redmond.corp.microsoft.com> <4FE177FE.6000106@gmx.de> In-Reply-To: <4FE177FE.6000106@gmx.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [217.130.139.163] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth Core -28 and Bearer -21 specs 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: Wed, 20 Jun 2012 11:07:31 -0000 Julian - This is not the final draft. Mike pushed an update with the inform= ation available while I'm away. Another draft will follow next week. I will= review the list and propose text (or ask questions) early next week. EH > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Julian Reschke > Sent: Wednesday, June 20, 2012 12:13 AM > To: Mike Jones > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] OAuth Core -28 and Bearer -21 specs published >=20 > On 2012-06-20 06:57, Mike Jones wrote: > > OAuth Core draft -28 has been published. Changes were: > > > > *Updated the ABNF in the manner discussed by the working group, > > allowing username and password to be Unicode and restricting client_id > > and client_secret to ASCII. > > > > *Specifies the use of the application/x-www-form-urlencoded > > content-type encoding method to encode the client_id when used as the > > password for HTTP Basic. > > ... >=20 > Well, you asked for feedback, you got it (repeatedly), and you ignore it.= This > is getting frustrating. >=20 > Best regards, Julian > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From julian.reschke@gmx.de Wed Jun 20 04:19:15 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34F6F21F85DB for ; Wed, 20 Jun 2012 04:19:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.258 X-Spam-Level: X-Spam-Status: No, score=-105.258 tagged_above=-999 required=5 tests=[AWL=-2.659, 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 3m7nKVN8SrjD for ; Wed, 20 Jun 2012 04:19:14 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 37C9021F85D7 for ; Wed, 20 Jun 2012 04:19:13 -0700 (PDT) Received: (qmail invoked by alias); 20 Jun 2012 11:19:12 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp035) with SMTP; 20 Jun 2012 13:19:12 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18Ex8ZVTwkEoym8ePR3gTJ4Bw5RuBPZzFu9CpswgI JGTt+6QMmxhSSI Message-ID: <4FE1B1AD.6070802@gmx.de> Date: Wed, 20 Jun 2012 13:19:09 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Eran Hammer References: <4E1F6AAD24975D4BA5B16804296739436655E392@TK5EX14MBXC283.redmond.corp.microsoft.com> <4FE177FE.6000106@gmx.de> <0CBAEB56DDB3A140BA8E8C124C04ECA20107A348@P3PWEX2MB008.ex2.secureserver.net> In-Reply-To: <0CBAEB56DDB3A140BA8E8C124C04ECA20107A348@P3PWEX2MB008.ex2.secureserver.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth Core -28 and Bearer -21 specs 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: Wed, 20 Jun 2012 11:19:15 -0000 On 2012-06-20 13:07, Eran Hammer wrote: > Julian - This is not the final draft. Mike pushed an update with the information available while I'm away. Another draft will follow next week. I will review the list and propose text (or ask questions) early next week. > > EH > ... OK, thanks for the update! From stephen.farrell@cs.tcd.ie Wed Jun 20 05:26:24 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77D5321F86EC for ; Wed, 20 Jun 2012 05:26:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.207 X-Spam-Level: X-Spam-Status: No, score=-102.207 tagged_above=-999 required=5 tests=[AWL=-0.208, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ht6mC6fedzre for ; Wed, 20 Jun 2012 05:26:23 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id C1A9C21F8549 for ; Wed, 20 Jun 2012 05:26:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 3576B153B9E for ; Wed, 20 Jun 2012 13:26:23 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:subject:mime-version :user-agent:from:date:message-id:received:received: x-virus-scanned; s=cs; t=1340195182; bh=DHetAHm4jFVOmJ3idkT6T5Yt uY9lIybzRgLql1lBvbc=; b=J5bvyi+uNOdOeTq2w06qCEhzRuYL8+AhmTLZihDM xSOLyNx/eJgJjQDtfHYeBEQNunxd0IVdOjb7wHmt/FsB/n8flt3FQqajYf8GwZqt FtQCXcLcFMdtsATQ7dtiIHgji/gt4KEhiyC7fKMuettA9iREnECvuokjvbeU9DpM CqQUBCXZV13QUACNPCQycEJQb7ji62bLEO3EEIO2vMpA8H98MhIgqNxulOAeeb9U O3Q/tJ7FA7Zd7gaGFO8nIFFd7ZEovNgkMQdZujkA91DFHxvpsViskqZaL7XynGPU PRXCDfGDQtCLGHfrlVj9Et7uBXgpP8MM6ArHRVuf1NEc8Q== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id 2o9BmyXS1S88 for ; Wed, 20 Jun 2012 13:26:22 +0100 (IST) Received: from [IPv6:2001:770:10:203:e59b:9b9d:9813:95ed] (unknown [IPv6:2001:770:10:203:e59b:9b9d:9813:95ed]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 9927A153B9D for ; Wed, 20 Jun 2012 13:26:21 +0100 (IST) Message-ID: <4FE1C16D.6010602@cs.tcd.ie> Date: Wed, 20 Jun 2012 13:26:21 +0100 From: Stephen Farrell 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" X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [OAUTH-WG] AD review of draft-ietf-oauth-urn-sub-ns-02 X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 12:26:24 -0000 Hi, Many thanks for a nice short document! I've a few questions though and suspect that a quick re-spin might be needed, but let's see what the wg think about 'em first. (1) Why Informational? Everything else at that level seems to be specified in a standards track or BCP level RFC, and IETF Consensus is required. [1] I think you have to do this as standards track. Did I miss something? [1] http://www.iana.org/assignments/params/params.xml (2) Do you *really* want RFC or specification required for all registrations? I don't care, but there is a trend away from that at the moment since its been found to discourage registrations in a lot of cases. Perhaps expert review would be ok? No trying to push you one way or the other, I just wanted to check. (3) If answer to (2) is yes: Section 5.1 says "Specification Required" but section 3 said "RFC Required" and those differ. For example, an OASIS spec would not be ok if you say RFC required. I don't know if you care, but you need to be consistent. (Or else I've misread something;-) (4) Isn't the template missing the reference to the RFC or other specification that defines the URN? (5) I don't get section 3, sorry;-) Can you give an example of a class:id pair that'd be registered? Asking IANA to generate the id part seems odd. nits: s3: s/generally referred/generally known/ s4: Might be worth pointing at the security considerations section of draft-ietf-oauth-v2? I'd say that text would be good to have read to know about the security considerations for the use of these URNs, before you go making one up. Cheers, Stephen. From stpeter@stpeter.im Wed Jun 20 05:40:04 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 127A221F8744 for ; Wed, 20 Jun 2012 05:40:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.224 X-Spam-Level: X-Spam-Status: No, score=-102.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HvUi4xFZ5kBl for ; Wed, 20 Jun 2012 05:40:03 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 1CC3B21F8742 for ; Wed, 20 Jun 2012 05:40:03 -0700 (PDT) Received: from [192.168.0.9] (unknown [216.17.179.227]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 86E2840075; Wed, 20 Jun 2012 06:57:36 -0600 (MDT) Message-ID: <4FE1C4A3.4090808@stpeter.im> Date: Wed, 20 Jun 2012 06:40:03 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120601 Thunderbird/13.0 MIME-Version: 1.0 To: Stephen Farrell References: <4FE1C16D.6010602@cs.tcd.ie> In-Reply-To: <4FE1C16D.6010602@cs.tcd.ie> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-urn-sub-ns-02 X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 12:40:04 -0000 On 6/20/12 6:26 AM, Stephen Farrell wrote: > > Hi, > > Many thanks for a nice short document! > > I've a few questions though and suspect that a quick re-spin > might be needed, but let's see what the wg think about 'em > first. > > (1) Why Informational? Everything else at that level seems to > be specified in a standards track or BCP level RFC, and IETF > Consensus is required. [1] I think you have to do this as > standards track. Did I miss something? > > [1] http://www.iana.org/assignments/params/params.xml I think you're right that standards-track makes sense here. > (2) Do you *really* want RFC or specification required for all > registrations? I don't care, but there is a trend away from > that at the moment since its been found to discourage > registrations in a lot of cases. Perhaps expert review would > be ok? No trying to push you one way or the other, I just > wanted to check. Expert review seems fine; lighter processes are better here. If folks really want a spec, I'd prefer Specification Required to RFC Required or IETF Review. > (3) If answer to (2) is yes: Section 5.1 says "Specification > Required" but section 3 said "RFC Required" and those differ. > For example, an OASIS spec would not be ok if you say RFC > required. I don't know if you care, but you need to be > consistent. (Or else I've misread something;-) > > (4) Isn't the template missing the reference to the RFC or > other specification that defines the URN? > > (5) I don't get section 3, sorry;-) Can you give an example of > a class:id pair that'd be registered? Asking IANA to generate > the id part seems odd. It's also not clear to me what is meant by "The token URI that identifies the registered component." Peter -- Peter Saint-Andre https://stpeter.im/ From Adam.Lewis@motorolasolutions.com Wed Jun 20 07:04:00 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10E8121F85BB for ; Wed, 20 Jun 2012 07:04:00 -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 X0Sxi9hQBrhm for ; Wed, 20 Jun 2012 07:03:53 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe005.messaging.microsoft.com [216.32.180.31]) by ietfa.amsl.com (Postfix) with ESMTP id 48AC721F85B8 for ; Wed, 20 Jun 2012 07:03:52 -0700 (PDT) Received: from mail218-va3-R.bigfish.com (10.7.14.251) by VA3EHSOBE002.bigfish.com (10.7.40.22) with Microsoft SMTP Server id 14.1.225.23; Wed, 20 Jun 2012 14:02:20 +0000 Received: from mail218-va3 (localhost [127.0.0.1]) by mail218-va3-R.bigfish.com (Postfix) with ESMTP id 7618D10029F for ; Wed, 20 Jun 2012 14:02:20 +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: -17 X-BigFish: VPS-17(zzbb2dI98dI9371Ic85fhb457nzz1202hzz1033IL8275bh8275dhz2fh2a8h683h839hd25hf0ah) Received-SPF: pass (mail218-va3: 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.240.85; KIP:(null); UIP:(null); (null); H:BL2PRD0410HT004.namprd04.prod.outlook.com; R:internal; EFV:INT Received: from mail218-va3 (localhost.localdomain [127.0.0.1]) by mail218-va3 (MessageSwitch) id 1340200938848157_29680; Wed, 20 Jun 2012 14:02:18 +0000 (UTC) Received: from VA3EHSMHS026.bigfish.com (unknown [10.7.14.238]) by mail218-va3.bigfish.com (Postfix) with ESMTP id CD11514008B for ; Wed, 20 Jun 2012 14:02:18 +0000 (UTC) Received: from il06msg01.mot-solutions.com (129.188.136.17) by VA3EHSMHS026.bigfish.com (10.7.99.36) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 20 Jun 2012 14:02:09 +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 q5KEnSHl001549 for ; Wed, 20 Jun 2012 09:49:28 -0500 (CDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe001.messaging.microsoft.com [213.199.154.139]) by il06msg01.mot-solutions.com (8.14.3/8.14.3) with ESMTP id q5KEnQna001512 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 20 Jun 2012 09:49:28 -0500 (CDT) Received: from mail42-db3-R.bigfish.com (10.3.81.232) by DB3EHSOBE005.bigfish.com (10.3.84.25) with Microsoft SMTP Server id 14.1.225.23; Wed, 20 Jun 2012 14:02:06 +0000 Received: from mail42-db3 (localhost [127.0.0.1]) by mail42-db3-R.bigfish.com (Postfix) with ESMTP id D7BA348030D for ; Wed, 20 Jun 2012 14:02:06 +0000 (UTC) Received: from mail42-db3 (localhost.localdomain [127.0.0.1]) by mail42-db3 (MessageSwitch) id 1340200924884066_20270; Wed, 20 Jun 2012 14:02:04 +0000 (UTC) Received: from DB3EHSMHS010.bigfish.com (unknown [10.3.81.245]) by mail42-db3.bigfish.com (Postfix) with ESMTP id CB24510024B; Wed, 20 Jun 2012 14:02:04 +0000 (UTC) Received: from BL2PRD0410HT004.namprd04.prod.outlook.com (157.56.240.85) by DB3EHSMHS010.bigfish.com (10.3.87.110) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 20 Jun 2012 14:02:02 +0000 Received: from BL2PRD0410MB363.namprd04.prod.outlook.com ([169.254.3.137]) by BL2PRD0410HT004.namprd04.prod.outlook.com ([10.255.99.39]) with mapi id 14.16.0164.004; Wed, 20 Jun 2012 14:03:26 +0000 From: Lewis Adam-CAL022 To: Kristofor Selden , nov matake , oauth Thread-Topic: [OAUTH-WG] Report an authentication issue Thread-Index: AQHNS93DPYgWszx0V0aoRqTD+I6nupcDQuAg Date: Wed, 20 Jun 2012 14:03:25 +0000 Message-ID: <59E470B10C4630419ED717AC79FCF9A9108898EE@BL2PRD0410MB363.namprd04.prod.outlook.com> References: <1339792496.52712.YahooMailNeo@web125501.mail.ne1.yahoo.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.2.83] Content-Type: multipart/alternative; boundary="_000_59E470B10C4630419ED717AC79FCF9A9108898EEBL2PRD0410MB363_" 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%MATAKE.JP$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-FOPE-CONNECTOR: Id%1294$Dn%MICROSOFT.COM$RO%2$TLS%3$FQDN%msgate.mot-solutions.com$TlsDn% X-FOPE-CONNECTOR: Id%1294$Dn%YAPP.US$RO%2$TLS%3$FQDN%msgate.mot-solutions.com$TlsDn% X-CFilter-Loop: Reflected X-OriginatorOrg: motorolasolutions.com Cc: Yuchen Zhou , Luke Melia , "Shuo Chen \(MSR\)" Subject: Re: [OAUTH-WG] Report an authentication issue X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 14:04:00 -0000 --_000_59E470B10C4630419ED717AC79FCF9A9108898EEBL2PRD0410MB363_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am entirely confused. I understand what everybody is saying for confidential clients, no problem = here. I fall apart when thinking of iPhone apps. Consider the scenario where I d= eploy a video server, and write an iPhone app to talk to the video server. = The video server is under the control of a police agency, and police offic= ers must logon to the video server in order to access video content. So th= e police office launches their iPhone video client app. 1) If I wanted to solve authentication using "traditional" client-serv= er authentication, the user enters their username / password into the clien= t, and the client sends the username / password off to the server, which au= thenticates it, or possibly uses HTTP digest. 2) If I wanted to use OpenID, the client would attempt to reach the vi= deo server (RP), the server would redirect the client to the OP, OP authent= icates user, and OP redirects client back to the server/RP with an assertio= n that primary authentication was successful. 3) If I wanted to use OAuth, the client would send an authorization re= quest to the server's AS, which would authenticate the user of the client, = and ultimately result in the client possessing an access-token. My thinkin= g is that this access token (let's assume it's a JWT) would contain the use= r's identity, a statement of what type of primary authentication was used (= auth context), an expiration, and an audience claim. This sounds a lot lik= e authentication to me, and it's where I get confused. Is it just because = OAuth does not explicitly define this? Is there a threat in using OAuth as= I describe? 4) If I wanted to use Connect, well I'm not even sure how the id_token= as defined by Connect helps this use case. The id_token seems to make sen= se when the client is a confidential web server, but it's not clear what an= iPhone app would do with the id_token ... it's the server in the backend t= hat needs to authenticate the user, the iPhone app is just an interface to = talk to the server. And it seems as I learn more about connect that the id= _token is not meant to be sent from the iPhone app to the server, just the = access token. So it's really not clear how Connect helps solve authenticat= ion for an iPhone client app talking to a video server. If I'm sending acc= ess-tokens, it's just OAuth again. What am I still missing? adam From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of K= ristofor Selden Sent: Saturday, June 16, 2012 11:33 AM To: nov matake; oauth Cc: Yuchen Zhou; Luke Melia; Shuo Chen (MSR) Subject: Re: [OAUTH-WG] Report an authentication issue Nov demonstrated the problem to us at Yapp and we used solution 4 (because = the solution is server side and our app was in the app store). FB Connect is authentication and authorization, where OAuth 2 is concerned = only with authorization - I'm not sure that app developers appreciate this = subtlety. With OAuth 2 you authorize an app to use a protected resource. With FB Con= nect, you do that, but also authenticate with the app you are authorizing. So the access_token protects not just the FB resources but the auth end poi= nt of the authorized app (very common with apps that use the iOS SDK). So = now the app needs a way to verify that it was the app that was authorized t= o FB. Solution 4 explanation: on FB you can register a iPhone app and a server ap= p with the same client_id and get a client_secret for use on the server. T= he server side API posts the access_token, client_id, and client_secret to = https://graph.facebook.com/app to verify that the bearer token actually belongs to the app = that is being authenticated before assuming they are authorized to the app'= s protected resources. Kris On Jun 15, 2012, at 8:22 PM, nov matake wrote: There are 4 ways to fix this issue. 1. Use response_type=3Dtoken%20code (It's not in OAuth 2.0 Core, but seems = best way for interoperability) 2. Use singed_request (or some signed token like JWT) 3. Use grant_type=3Dfb_exchange_token (Facebook custom way) 4. Access to https://graph.facebook.com/app?access_token=3DYOUR_TOKEN (Face= book custom way, moreover undocumented API) Two iPhone app developers I reported this issue fixed it by using (4). I also tried to use (1) for my own iPhone app implementation, but unfortuna= tely it doesn't work when using authorization codes obtained via FB iOS SDK= . So I'm using (3) in my case. nov On 2012/06/16, at 9:16, Nat Sakimura wrote: As to how the fix was done, Nov can provide more detail, but ... 1. Properly verify the signature/HMAC of the "signed_request". This will es= sentially audience restricts the token. 2. There is an undocumented API for Facebook which returns to whom the toke= n was issued. This also audience restricts the token. The service that fixed took these measures. Note that none of the above is = defined in OAuth. The same facility was called "id_token" and "check ID endpoint" for OpenID = Connect. The scale of the impact is large, too large to disclose the actual names in= the public list, though, eventually, we would publish them in a paper. Nat On Sat, Jun 16, 2012 at 5:34 AM, Francisco Corella > wrote: Hi Nat and Rui, Rui, you say that the vulnerability that you found was due to a "common misunderstanding among developers", but the attack you describe can be carried out against any app that uses the OAuth "implicit grant flow", which Facebook calls "client-side authentication". No misunderstanding seems necessary. What misunderstanding are you referring to? I followed the link in your message to the Sophos post, and from there the link to the article in The Register. The article in The Register says that Facebook had "fixed the vulnerability promptly". How did they fix it? The instructions that Facebook provides for implementing "Client-side authentication without the JS SDK" at https://developers.facebook.com/docs/authentication/client-side/#no-jssdk still allows the attack. Nat, I agree that the blog post by John Bradley that you link to refers to the same vulnerability reported by Rui. You say that some apps have issued a patch to fix it. Could you explain what the fix was? Francisco ________________________________ From: Nat Sakimura > To: rui wang > Cc: matake nov >; Yuchen Zhou >; oauth >; Shuo Chen (MSR) > Sent: Thursday, June 14, 2012 1:50 PM Subject: Re: [OAUTH-WG] Report an authentication issue This is a fairly well known (hopefully by now) issue. We, at the OpenID Fou= ndation, call it "access_token phishing" attack these days. See: http://www= .thread-safe.com/2012/01/problem-with-oauth-for-authentication.html Nov Matake has actually built the code on iPhone to verify the problem, and= has notified bunch of parties back in February including Facebook and Appl= e. We have the code that actually runs on a phone, and we have successfully= logged in to bunch of apps, including very well known ones. They were all = informed of the issue. Some immediately issued a patch to fix it while othe= rs have not. The problem is that even if these apps gets fixed, the problem does not go = away. As long as the attacker has the vulnerable version of the app, he sti= ll can impersonate the victim. To stop it, the server side has to completel= y disable the older version, which means the service has to cut off many us= ers pausing business problems. Nat On Fri, Jun 15, 2012 at 2:18 AM, rui wang > wrote: Dear Facebook Security Team and OAuth Standard group, We are a research team in Microsoft Research. In January, 2011, we reported= a vulnerability in Facebook Connect which allowed everyone to sign into Fa= cebook-secured relying parties without password. It was promptly fixed afte= r reporting. (http://nakedsecurity.sophos.com/2011/02/02/facebook-flaw-webs= ites-steal-personal-data/) Recently, we found a common misunderstanding among developers of mobile/met= ro apps when using OAuth (including Facebook's OAuth) for authentication. T= he vulnerability resulted from this misunderstanding also allows an attacke= r to log into a victim user's account without password. Let's take Soluto's metro app as an example to describe the problem. The ap= p supports Facebook Login. As an attacker, we can write a regular Facebook = app. Once the victim user allows our app to access her Facebook data, we re= ceive an access_token from the traffic. Then, on our own machine (i.e., the= "attacker" machine), we run the metro app of Soluto, and use a HTTP proxy = to insert the victim's access_token into the traffic of Facebook login. Thr= ough this way, we are able to log into the victim's Soluto account from our= machine. Other than Soluto, we also have confirmed the same issue on anoth= er Windows 8 metro-app Givit. The Facebook SDK for Android apps (https://developers.facebook.com/docs/mob= ile/android/build/#sdk) seems to have the possibility to mislead developers= too. At least, the issue that we found is not clearly mentioned. In the SD= K, we ran the sample code called "Hackbook" using Android Emulator (imagine= it is an attacker device). Note that we have already received the access t= oken of the victim user from our regular Facebook app. We then inject the t= oken to the traffic of Hackbook. Through this way, Hackbook app on our own = machine recognizes us as the victim. Note that this is not a convincing sec= urity exploit yet, because this sample code does not include the server-sid= e code. However, given that we have seen real server-side code having this = problem, such as Soluto, Givit and others, we do believe that the sample co= de can mislead mobile/metro developers. We also suspect that this may be a = general issue of many OAuth implementations on mobile platforms, so we send= this message to OAuth Standard group as well. We have contacted the vendors of the two vulnerable metro-apps, Soluto and = Gavit. Please kindly give us an ack when you receive this message. If you want to = know more details, please let us know. Best Regards, Yuchen Zhou, Rui Wang, and Shuo Chen _______________________________________________ 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 -- 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_59E470B10C4630419ED717AC79FCF9A9108898EEBL2PRD0410MB363_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am entirely confused.

 

I understand what everybody is saying for co= nfidential clients, no problem here.

 

I fall apart when thinking of iPhone apps.&n= bsp; Consider the scenario where I deploy a video server, and write an iPho= ne app to talk to the video server.  The video server is under the control of a police agency, and police officers must logon to the vide= o server in order to access video content.  So the police office launc= hes their iPhone video client app.

 

1)    =   If I wanted to solve authentication = using “traditional” client-server authentication, the user ente= rs their username / password into the client, and the client sends the username / password off to the server, which authenticates it, or poss= ibly uses HTTP digest. 

2)    =   If I wanted to use OpenID, the clien= t would attempt to reach the video server (RP), the server would redirect t= he client to the OP, OP authenticates user, and OP redirects client back to the server/RP with an assertion that primary authentication= was successful. 

3)    =   If I wanted to use OAuth, the client= would send an authorization request to the server’s AS, which would = authenticate the user of the client, and ultimately result in the client possessing an access-token.  My thinking is that this acce= ss token (let’s assume it’s a JWT) would contain the user’= ;s identity, a statement of what type of primary authentication was used (a= uth context), an expiration, and an audience claim.  This sounds a lot like authentication to me, and it’s where I get confuse= d.  Is it just because OAuth does not explicitly define this?  Is= there a threat in using OAuth as I describe? 

4)    =   If I wanted to use Connect, well I&#= 8217;m not even sure how the id_token as defined by Connect helps this use = case.  The id_token seems to make sense when the client is a confidential web server, but it’s not clear what an iPhone app would= do with the id_token … it’s the server in the backend that nee= ds to authenticate the user, the iPhone app is just an interface to talk to= the server.  And it seems as I learn more about connect that the id_token is not meant to be sent from the iPhone app to the serve= r, just the access token.  So it’s really not clear how Connect = helps solve authentication for an iPhone client app talking to a video serv= er.  If I’m sending access-tokens, it’s just OAuth again.

 

What am I still missing?

adam

 

 

From: oauth-bo= unces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Kristofor Selden
Sent: Saturday, June 16, 2012 11:33 AM
To: nov matake; oauth
Cc: Yuchen Zhou; Luke Melia; Shuo Chen (MSR)
Subject: Re: [OAUTH-WG] Report an authentication issue

 

Nov demonstrated the problem to us at Yapp and we us= ed solution 4 (because the solution is server side and our app was in the a= pp store).

 

FB Connect is authentication and authorizatio= n, where OAuth 2 is concerned only with authorization – I'm not sure = that app developers appreciate this subtlety.

 

With OAuth 2 you authorize an app to use a protected= resource.  With FB Connect, you do that, but also authenticate with the app you are authorizing.

 

So the access_token protects not just the FB resourc= es but the auth end point of the authorized app (very common with apps that= use the iOS SDK).  So now the app needs a way to verify that it was t= he app that was authorized to FB.

 

Solution 4 explanation: on FB you can register a iPh= one app and a server app with the same client_id and get a client_secret fo= r use on the server.  The server side API posts the access_token, = ;client_id, and client_secret to https://graph.facebook.com/app&nbs= p;to verify that the bearer token actually belongs to the app that is being authentica= ted before assuming they are authorized to the app's protected resources.

 

Kris

 

On Jun 15, 2012, at 8:22 PM, nov matake wrote:<= /o:p>



There are 4 ways to fix this issue.

 

1. Use response_type=3Dtoken%20code (It's not i= n OAuth 2.0 Core, but seems best way for interoperability)

2. Use singed_request (or some signed token like JWT= )

3. Use grant_type=3Dfb_exchange_token (Facebook cust= om way)

4. Access to https://graph.facebook.com/app?access_token=3DYOUR_TOKEN (Facebook cust= om way, moreover undocumented API)

 

Two iPhone app developers I reported this issue fixe= d it by using (4).

 

I also tried to use (1) for my own iPhone app implem= entation, but unfortunately it doesn't work when using authorization codes = obtained via FB iOS SDK.

So I'm using (3) in my case.

 

nov

 

On 2012/06/16, at 9:16, Nat Sakimura wrote:



As to how the fix was done, Nov can provide more det= ail, but ... 

 

1. Properly verify the signature/HMAC of the "s= igned_request". This will essentially audience restricts the token.&nb= sp;

2. There is an undocumented API for Facebook which r= eturns to whom the token was issued. This also audience restricts the token= . 

 

The service that fixed took these measures. Note tha= t none of the above is defined in OAuth. 

The same facility was called "id_token" an= d "check ID endpoint" for OpenID Connect. 

 

The scale of the impact is large, too large to discl= ose the actual names in the public list, though, eventually, we would publi= sh them in a paper. 

 

Nat

On Sat, Jun 16, 2012 at 5:34 AM, Francisco Corella &= lt;fcorella@pomcor= .com> wrote:

Hi Nat and Rui,

Rui, you say that the vulnerability that you found was due to a
"common misunderstanding among developers", but the attack you describe can be carried out against any app that uses the OAuth
"implicit grant flow", which Facebook calls "client-side
authentication".  No misunderstanding seems necessary.  What=
misunderstanding are you referring to?  I followed the link in your message to the Sophos post, and from there the link to the article in
The Register.  The article in The Register says that Facebook had
"fixed the vulnerability promptly".  How did they fix it?&nb= sp; The
instructions that Facebook provides for implementing "Client-side
authentication without the JS SDK" at
https://developers.facebook.com/docs/authentic= ation/client-side/#no-jssdk
still allows the attack.

Nat, I agree that the blog post by John Bradley that you link to
refers to the same vulnerability reported by Rui.  You say that some apps have issued a patch to fix it.  Could you explain what the fix was?

Francisco

 

From: Nat Sakimura <sakimura@gmail.com>
To: rui wang <ruiwangwarm@gmail.com>
Cc: matake nov <nov@matake.jp>; Yuchen Zhou <t-yuzhou@microsoft.com>; oauth <oauth@ietf.org>; Shuo Chen (MSR) <shuochen@microsoft.com>
Sent: Thursday, June 14, 2012 1:50 PM
Subject: Re: [OAUTH-WG] Report an authentication issue

 

This is a fairly well known (hopefully by now) issue= . We, at the OpenID Foundation, call it "access_token phishing" a= ttack these days. See: http://www.thr= ead-safe.com/2012/01/problem-with-oauth-for-authentication.html

 

Nov Matake has actually built the code on iPhone to = verify the problem, and has notified bunch of parties back in February incl= uding Facebook and Apple. We have the code that actually runs on a phone, a= nd we have successfully logged in to bunch of apps, including very well known ones. They were all informed o= f the issue. Some immediately issued a patch to fix it while others have no= t.  

 

The problem is that even if these apps gets fixed, t= he problem does not go away. As long as the attacker has the vulnerable ver= sion of the app, he still can impersonate the victim. To stop it, the serve= r side has to completely disable the older version, which means the service has to cut off many users pausing b= usiness problems. 

 

Nat

On Fri, Jun 15, 2012 at 2:18 AM, rui wang <ruiwangwarm@gmail.com<= /a>> wrote:

Dear Facebook Security Team and OAuth Standard group= ,

Recently, we found a common misunderstanding among d= evelopers of mobile/metro apps when using OAuth (including Facebook’s= OAuth) for authentication. The vulnerability resulted from this misunderst= anding also allows an attacker to log into a victim user's account without password.

Let's take Soluto's metro app as an example to descr= ibe the problem. The app supports Facebook Login. As an attacker, we can wr= ite a regular Facebook app. Once the victim user allows our app to access h= er Facebook data, we receive an access_token from the traffic. Then, on our own machine (i.e., the "attacker"= machine), we run the metro app of Soluto, and use a HTTP proxy to insert t= he victim's access_token into the traffic of Facebook login. Through this w= ay, we are able to log into the victim's Soluto account from our machine. Other than Soluto, we also have confirmed the sa= me issue on another Windows 8 metro-app Givit.

The Facebook SDK for Android apps (https://developers.facebook.com/docs/mobile/android/build/#sdk) seems = to have the possibility to mislead developers too. At least, the issue that we found is not clearly mentioned. In the SD= K, we ran the sample code called "Hackbook" using Android Emulato= r (imagine it is an attacker device). Note that we have already received th= e access token of the victim user from our regular Facebook app. We then inject the token to the traffic of Hackbook.= Through this way, Hackbook app on our own machine recognizes us as the vic= tim. Note that this is not a convincing security exploit yet, because this = sample code does not include the server-side code. However, given that we have seen real server-side code h= aving this problem, such as Soluto, Givit and others, we do believe that th= e sample code can mislead mobile/metro developers. We also suspect that thi= s may be a general issue of many OAuth implementations on mobile platforms, so we send this message to OAut= h Standard group as well.

We have contacted the vendors of the two vulnerable = metro-apps, Soluto and Gavit.

Please kindly give us an ack when you receive this m= essage. If you want to know more details, please let us know.

Best Regards,
Yuchen Zhou, Rui Wang, and Shuo Chen


_______________________________________________
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
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.org/mailman/listinfo/oauth

 

--_000_59E470B10C4630419ED717AC79FCF9A9108898EEBL2PRD0410MB363_-- From Michael.Jones@microsoft.com Wed Jun 20 07:52:10 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D01521F866A for ; Wed, 20 Jun 2012 07:52:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.806 X-Spam-Level: X-Spam-Status: No, score=-3.806 tagged_above=-999 required=5 tests=[AWL=-0.207, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kSD2bcgtgtdl for ; Wed, 20 Jun 2012 07:52:09 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe003.messaging.microsoft.com [213.199.154.206]) by ietfa.amsl.com (Postfix) with ESMTP id 4977721F864B for ; Wed, 20 Jun 2012 07:52:08 -0700 (PDT) Received: from mail104-am1-R.bigfish.com (10.3.201.242) by AM1EHSOBE005.bigfish.com (10.3.204.25) with Microsoft SMTP Server id 14.1.225.23; Wed, 20 Jun 2012 14:50:43 +0000 Received: from mail104-am1 (localhost [127.0.0.1]) by mail104-am1-R.bigfish.com (Postfix) with ESMTP id 140B24A034E; Wed, 20 Jun 2012 14:50:43 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -29 X-BigFish: VS-29(zz98dI9371I936eI542M1432Izz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25hf0ah) Received-SPF: pass (mail104-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC101.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail104-am1 (localhost.localdomain [127.0.0.1]) by mail104-am1 (MessageSwitch) id 1340203841382941_17818; Wed, 20 Jun 2012 14:50:41 +0000 (UTC) Received: from AM1EHSMHS014.bigfish.com (unknown [10.3.201.234]) by mail104-am1.bigfish.com (Postfix) with ESMTP id 5127614004B; Wed, 20 Jun 2012 14:50:41 +0000 (UTC) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS014.bigfish.com (10.3.207.152) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 20 Jun 2012 14:50:39 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.53]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi id 14.02.0298.005; Wed, 20 Jun 2012 14:51:48 +0000 From: Mike Jones To: Julian Reschke , Eran Hammer Thread-Topic: [OAUTH-WG] OAuth Core -28 and Bearer -21 specs published Thread-Index: Ac1OoSGuaSOU0vo6TGKJuu+TMXt96wAEv9oAAAgwJoAAB57EgA== Date: Wed, 20 Jun 2012 14:51:47 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436655F81F@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739436655E392@TK5EX14MBXC283.redmond.corp.microsoft.com> <4FE177FE.6000106@gmx.de> <0CBAEB56DDB3A140BA8E8C124C04ECA20107A348@P3PWEX2MB008.ex2.secureserver.net> In-Reply-To: <0CBAEB56DDB3A140BA8E8C124C04ECA20107A348@P3PWEX2MB008.ex2.secureserver.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.32] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth Core -28 and Bearer -21 specs 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: Wed, 20 Jun 2012 14:52:10 -0000 Julian, I don't believe that it's the intent of either Eran or myself to ig= nore your concerns - far from it. That being said, what's frustrating from= my personal perspective is that we've asked you to provide specific propos= ed text changes that would address your concerns several times and you don'= t do it. It's probably just me, but I personally find the descriptions of = your concerns vague and unclear - making it hard to make them actionable. = Specific proposed text changes would make them actionable. Could you please provide specific changes for Eran's use for when he consid= ers them on Monday? I think it would help a lot. Thank you, -- Mike -----Original Message----- From: Eran Hammer [mailto:eran@hueniverse.com]=20 Sent: Wednesday, June 20, 2012 4:07 AM To: Julian Reschke; Mike Jones Cc: oauth@ietf.org Subject: RE: [OAUTH-WG] OAuth Core -28 and Bearer -21 specs published Julian - This is not the final draft. Mike pushed an update with the inform= ation available while I'm away. Another draft will follow next week. I will= review the list and propose text (or ask questions) early next week. EH > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf=20 > Of Julian Reschke > Sent: Wednesday, June 20, 2012 12:13 AM > To: Mike Jones > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] OAuth Core -28 and Bearer -21 specs published >=20 > On 2012-06-20 06:57, Mike Jones wrote: > > OAuth Core draft -28 has been published. Changes were: > > > > *Updated the ABNF in the manner discussed by the working group,=20 > > allowing username and password to be Unicode and restricting=20 > > client_id and client_secret to ASCII. > > > > *Specifies the use of the application/x-www-form-urlencoded=20 > > content-type encoding method to encode the client_id when used as=20 > > the password for HTTP Basic. > > ... >=20 > Well, you asked for feedback, you got it (repeatedly), and you ignore=20 > it. This is getting frustrating. >=20 > Best regards, Julian > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From julian.reschke@gmx.de Wed Jun 20 08:01:24 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C39E21F8745 for ; Wed, 20 Jun 2012 08:01:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.137 X-Spam-Level: X-Spam-Status: No, score=-105.137 tagged_above=-999 required=5 tests=[AWL=-2.538, 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 DSRIESxYFYpU for ; Wed, 20 Jun 2012 08:01:24 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 9811E21F8743 for ; Wed, 20 Jun 2012 08:01:23 -0700 (PDT) Received: (qmail invoked by alias); 20 Jun 2012 15:01:21 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp001) with SMTP; 20 Jun 2012 17:01:21 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+ybVc3VFWytRMO2mbJ2gDGmgoKBm4xaymgXq/k0k a95eeSQWUyho5Z Message-ID: <4FE1E5BD.9070008@gmx.de> Date: Wed, 20 Jun 2012 17:01:17 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Mike Jones References: <4E1F6AAD24975D4BA5B16804296739436655E392@TK5EX14MBXC283.redmond.corp.microsoft.com> <4FE177FE.6000106@gmx.de> <0CBAEB56DDB3A140BA8E8C124C04ECA20107A348@P3PWEX2MB008.ex2.secureserver.net> <4E1F6AAD24975D4BA5B16804296739436655F81F@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436655F81F@TK5EX14MBXC283.redmond.corp.microsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] OAuth Core -28 and Bearer -21 specs 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: Wed, 20 Jun 2012 15:01:24 -0000 On 2012-06-20 16:51, Mike Jones wrote: > Julian, I don't believe that it's the intent of either Eran or myself to ignore your concerns - far from it. That being said, what's frustrating from my personal perspective is that we've asked you to provide specific proposed text changes that would address your concerns several times and you don't do it. It's probably just me, but I personally find the descriptions of your concerns vague and unclear - making it hard to make them actionable. Specific proposed text changes would make them actionable. > > Could you please provide specific changes for Eran's use for when he considers them on Monday? I think it would help a lot. > > Thank you, > -- Mike Sorry, can't do that; not just because I don't have time but also because I don't understand the spec sufficiently do decide what needs to be done. What's clear is that you can't silently mix ABNFs for byte sequences and character sequences. You need to be clear about what is what. I can't answer that. I provided you with a reference to similar text in a spec I wrote a few years ago; please borrow from it. With respect to the POST/media-type/encoding issue I *did* make a concrete proposal. Best regards, Julian From Michael.Jones@microsoft.com Wed Jun 20 09:14:29 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 346AB21F86D1 for ; Wed, 20 Jun 2012 09:14:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, 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 tTB83ZpaPMSt for ; Wed, 20 Jun 2012 09:14:28 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe002.messaging.microsoft.com [216.32.180.12]) by ietfa.amsl.com (Postfix) with ESMTP id 4940C21F86B6 for ; Wed, 20 Jun 2012 09:14:28 -0700 (PDT) Received: from mail81-va3-R.bigfish.com (10.7.14.236) by VA3EHSOBE007.bigfish.com (10.7.40.11) with Microsoft SMTP Server id 14.1.225.23; Wed, 20 Jun 2012 16:13:02 +0000 Received: from mail81-va3 (localhost [127.0.0.1]) by mail81-va3-R.bigfish.com (Postfix) with ESMTP id BE03E4C0347; Wed, 20 Jun 2012 16:13:02 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -33 X-BigFish: VS-33(zzbb2dI98dI9371I1431J542M1432I1a09Jzz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25hf0ah) Received-SPF: pass (mail81-va3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC103.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail81-va3 (localhost.localdomain [127.0.0.1]) by mail81-va3 (MessageSwitch) id 1340208780704195_17422; Wed, 20 Jun 2012 16:13:00 +0000 (UTC) Received: from VA3EHSMHS002.bigfish.com (unknown [10.7.14.252]) by mail81-va3.bigfish.com (Postfix) with ESMTP id 9F249240050; Wed, 20 Jun 2012 16:13:00 +0000 (UTC) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS002.bigfish.com (10.7.99.12) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 20 Jun 2012 16:12:59 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.53]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.02.0309.003; Wed, 20 Jun 2012 16:14:07 +0000 From: Mike Jones To: Peter Saint-Andre , Stephen Farrell Thread-Topic: [OAUTH-WG] AD review of draft-ietf-oauth-urn-sub-ns-02 Thread-Index: AQHNTt/sWKdca/SRw0Gp10lpJtZuBZcDJeCAgAA46HA= Date: Wed, 20 Jun 2012 16:14:05 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436655FAA8@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <4FE1C16D.6010602@cs.tcd.ie> <4FE1C4A3.4090808@stpeter.im> In-Reply-To: <4FE1C4A3.4090808@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.32] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-urn-sub-ns-02 X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 16:14:29 -0000 I agree that this should be standards track. I agree that RFC Required is severe overkill. Specification required or ex= pert review would be fine. I believe that we should delete the "please assign" functionality and requi= re the registration to include the URN. The defining specification should = contain the URI to be registered. I also agree that we need the "Specification document(s)" section of the te= mplate. Authors, possibly see http://tools.ietf.org/html/draft-ietf-oauth-= v2-28#section-11.1.1 for example wording to use. The template is also missing the standard "Change controller" section. Per your question (5) Stephen, possibly see the registrations in http://too= ls.ietf.org/html/draft-ietf-oauth-saml2-bearer-12#section-6. Authors, mayb= e using one of these as an example would help? -- Mike -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of P= eter Saint-Andre Sent: Wednesday, June 20, 2012 5:40 AM To: Stephen Farrell Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-urn-sub-ns-02 On 6/20/12 6:26 AM, Stephen Farrell wrote: >=20 > Hi, >=20 > Many thanks for a nice short document! >=20 > I've a few questions though and suspect that a quick re-spin might be=20 > needed, but let's see what the wg think about 'em first. >=20 > (1) Why Informational? Everything else at that level seems to be=20 > specified in a standards track or BCP level RFC, and IETF Consensus is=20 > required. [1] I think you have to do this as standards track. Did I=20 > miss something? >=20 > [1] http://www.iana.org/assignments/params/params.xml I think you're right that standards-track makes sense here. > (2) Do you *really* want RFC or specification required for all=20 > registrations? I don't care, but there is a trend away from that at=20 > the moment since its been found to discourage registrations in a lot=20 > of cases. Perhaps expert review would be ok? No trying to push you=20 > one way or the other, I just wanted to check. Expert review seems fine; lighter processes are better here. If folks reall= y want a spec, I'd prefer Specification Required to RFC Required or IETF Re= view. > (3) If answer to (2) is yes: Section 5.1 says "Specification Required"=20 > but section 3 said "RFC Required" and those differ. > For example, an OASIS spec would not be ok if you say RFC required. I=20 > don't know if you care, but you need to be consistent. (Or else I've=20 > misread something;-) >=20 > (4) Isn't the template missing the reference to the RFC or other=20 > specification that defines the URN? >=20 > (5) I don't get section 3, sorry;-) Can you give an example of a=20 > class:id pair that'd be registered? Asking IANA to generate the id=20 > part seems odd. It's also not clear to me what is meant by "The token URI that identifies t= he registered component." Peter -- Peter Saint-Andre https://stpeter.im/ _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From stephen.farrell@cs.tcd.ie Wed Jun 20 09:18:19 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EB5021F85FC for ; Wed, 20 Jun 2012 09:18:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rbHszKsi0Djv for ; Wed, 20 Jun 2012 09:18:18 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 6CFE121F85B6 for ; Wed, 20 Jun 2012 09:18:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id B7497171483; Wed, 20 Jun 2012 17:18:15 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1340209095; bh=cK6dUU8/q6AvLB AlzCIr9lwrWUcUKjxfVhmyuXvIk4I=; b=b0i0iaeoQG+TMt1NLB6AWqYqEsVyOG V3q0cpTGOeAAGoYefMFhhrkcGZWnMee8JsKxEm6zrq2O9LpFnZt5IEGmyLHoUJuV WBkvkyRw+YlX3BGd6dyRZWpwENvRemQNHhioc9YynEcee5C3mxb21F7cCydRISng SX/F5PK90M/BcODR6Qts9DyMNdmY25uqYkAma/jGU/GHVKt5YbeDcpo2uf5/v1a+ IFkIKuDosKmHMjc6Xsdmd7VjmSQfx7WzAAExV/X5rpyKm5gjLre0YWB2028FraYA MTBIEh13MOQOrqSrLzQ78I3dmdz6JNDRRlfCfgs3LNmlf4AvBAc1JvlQ== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id ebq7DAORne-g; Wed, 20 Jun 2012 17:18:15 +0100 (IST) Received: from [IPv6:2001:770:10:203:e59b:9b9d:9813:95ed] (unknown [IPv6:2001:770:10:203:e59b:9b9d:9813:95ed]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 959EC171482; Wed, 20 Jun 2012 17:18:14 +0100 (IST) Message-ID: <4FE1F7C6.1010005@cs.tcd.ie> Date: Wed, 20 Jun 2012 17:18:14 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Mike Jones References: <4FE1C16D.6010602@cs.tcd.ie> <4FE1C4A3.4090808@stpeter.im> <4E1F6AAD24975D4BA5B16804296739436655FAA8@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436655FAA8@TK5EX14MBXC283.redmond.corp.microsoft.com> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-urn-sub-ns-02 X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 16:18:19 -0000 On 06/20/2012 05:14 PM, Mike Jones wrote: > Per your question (5) Stephen, possibly see the registrations in http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-12#section-6. Authors, maybe using one of these as an example would help? Thanks Mike, that answers the question. I can't see IANA picking that id part but we can ask if the WG want to ask. S. From bcampbell@pingidentity.com Wed Jun 20 09:26:36 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B51921F8713 for ; Wed, 20 Jun 2012 09:26:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.677 X-Spam-Level: X-Spam-Status: No, score=-5.677 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_52=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 QK865Fa+uCH0 for ; Wed, 20 Jun 2012 09:26:35 -0700 (PDT) Received: from na3sys009aog126.obsmtp.com (na3sys009aog126.obsmtp.com [74.125.149.155]) by ietfa.amsl.com (Postfix) with ESMTP id 7C32B21F8711 for ; Wed, 20 Jun 2012 09:26:35 -0700 (PDT) Received: from mail-qc0-f177.google.com ([209.85.216.177]) (using TLSv1) by na3sys009aob126.postini.com ([74.125.148.12]) with SMTP ID DSNKT+H5uqTBZrWHFfIHwHZ0eGZn0n5nzKIW@postini.com; Wed, 20 Jun 2012 09:26:35 PDT Received: by qcsu28 with SMTP id u28so5539340qcs.22 for ; Wed, 20 Jun 2012 09:26:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=I0cwl+QUHBqBb5xVI2Pv3h55CtJbFk1nIdVMMrjmmDA=; b=d0dH6c1nUBrBqKOSgkcDTkquKt/dn7rbIAhUcA61MEMEw4aOxeZ3Tvwr1llvdEFw08 m5dUd3/hsjhTwUB4Nnknlxrvu+1RU7Yh4ve5Qd/BJdshDX1p0zPp1R9PEihO3LBkyEkt cMfwh3QtPYcF/OqxuB/bCV1ggmGOh0oxFth1vTXUus5Z3970tL9pPrR40HzaZVq39siR VJf+TcE5G8Rbm6PYNwHW4LY0isbTeDkJSfUQx8G0VzY6dQyDdseyY5wbfdz+RWy9jWBZ l41iPajJEEDjjJdCf8mS+Dzln0jEDTIT4nZXzZpESXg6XFfV0WprsFInjU1ETKdy3wLn 82LQ== Received: by 10.224.212.1 with SMTP id gq1mr42339368qab.54.1340209594028; Wed, 20 Jun 2012 09:26:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.87.142 with HTTP; Wed, 20 Jun 2012 09:26:03 -0700 (PDT) In-Reply-To: <4FE1C16D.6010602@cs.tcd.ie> References: <4FE1C16D.6010602@cs.tcd.ie> From: Brian Campbell Date: Wed, 20 Jun 2012 10:26:03 -0600 Message-ID: To: Stephen Farrell Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQn6w2s2rPb46rfFlXuYQ5apzmXa/QFzw7K0Mn4nea/kIg5H0KZ25HOAr2N95MUzzjYBMqCx Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-urn-sub-ns-02 X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 16:26:36 -0000 Thanks Stephen (also Peter) for the review and feedback. Responses are inli= ne. On Wed, Jun 20, 2012 at 6:26 AM, Stephen Farrell wrote: > > Hi, > > Many thanks for a nice short document! If only they could all be so short right? :) > I've a few questions though and suspect that a quick re-spin > might be needed, but let's see what the wg think about 'em > first. > > (1) Why Informational? Everything else at that level seems to > be specified in a standards track or BCP level RFC, and IETF > Consensus is required. [1] I think you have to do this as > standards track. Did I miss something? I'm pretty sure that was just an oversight when using some boilerplate xml to get the document started. I agree with you and Peter that standards track makes more sense and I've updated my local copy of the source to reflect that. > > (2) Do you *really* want RFC or specification required for all > registrations? =A0I don't care, but there is a trend away from > that at the moment since its been found to discourage > registrations in a lot of cases. Perhaps expert review would > be ok? =A0No trying to push you one way or the other, I just > wanted to check. Again I agree with you and Peter - lighter is preferred. Though Hannes wrote the original text for this so I'd ask that he please speak up if there was some reason to require RFC here that we aren't aware of. Can you help me with the proper text for this? Is it sufficient to drop the "NOTE: in order for a URN of this type to be assigned, the item being registered MUST be documented in a RFC" text from the 1st paragraph of =A73 and change "New entries to the registry are Specification Required" to "New entries to the registry require expert review" in =A75.1? > (3) If answer to (2) is yes: Section 5.1 says "Specification > Required" but section 3 said "RFC Required" and those differ. > For example, an OASIS spec would not be ok if you say RFC > required. I don't know if you care, but you need to be > consistent. (Or else I've misread something;-) Having chaired an OASIS TC for 2 years I probably should care :) See the previous comment/question about relaxing this. Expert review seems good or maybe Specification Required but not RFC Required. Regardless, your are right, it should at very least be consistent :) > (4) Isn't the template missing the reference to the RFC or > other specification that defines the URN? I believe the "Description" portion of the template was intended to capture that. Or that's how it's kinds been used by specs that use it anyway. Should we add a "Specification document(s):" to the template? > (5) I don't get section 3, sorry;-) Can you give an example of > a class:id pair that'd be registered? http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-12#section-6 and http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-00#section-6 are real examples that *hopefully* do the registration correctly. Do you think I should add an example registration directly to draft-ietf-oauth-urn-sub-ns? > Asking IANA to generate > the id part seems odd. Agreed. The "please assign" text should probably be removed. It's really up to the defining spec to say what the class and id are/ > nits: > > s3: s/generally referred/generally known/ Will do. > s4: Might be worth pointing at the security considerations > section of draft-ietf-oauth-v2? I'd say that text would be > good to have read to know about the security considerations > for the use of these URNs, before you go making one up. Is just referencing it sufficient? From julian.reschke@gmx.de Wed Jun 20 09:40:43 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1341F21F8763 for ; Wed, 20 Jun 2012 09:40:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.027 X-Spam-Level: X-Spam-Status: No, score=-105.027 tagged_above=-999 required=5 tests=[AWL=-2.428, 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 3V785QWZNQcp for ; Wed, 20 Jun 2012 09:40:42 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 2491D21F8759 for ; Wed, 20 Jun 2012 09:40:41 -0700 (PDT) Received: (qmail invoked by alias); 20 Jun 2012 16:40:40 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp041) with SMTP; 20 Jun 2012 18:40:40 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+FTBMoh+6FpCbMYGccb2l6dIO6/nXdu/x9tEVzHx w4m2qpeUPiUgx1 Message-ID: <4FE1FD04.1000801@gmx.de> Date: Wed, 20 Jun 2012 18:40:36 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Mike Jones References: <4E1F6AAD24975D4BA5B16804296739436655E392@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436655E392@TK5EX14MBXC283.redmond.corp.microsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth Core -28 and Bearer -21 specs 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: Wed, 20 Jun 2012 16:40:43 -0000 On 2012-06-20 06:57, Mike Jones wrote: > OAuth Core draft -28 has been published. Changes were: > > ·Updated the ABNF in the manner discussed by the working group, allowing > username and password to be Unicode and restricting client_id and > client_secret to ASCII. > ... VSCHAR = %20-7E needs to be VSCHAR = %x20-7E (note the missing "x"). Best regards, Julian From stephen.farrell@cs.tcd.ie Wed Jun 20 09:41:05 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C84321F8775 for ; Wed, 20 Jun 2012 09:41:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.205 X-Spam-Level: X-Spam-Status: No, score=-102.205 tagged_above=-999 required=5 tests=[AWL=-0.206, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3AXhCEDeefX2 for ; Wed, 20 Jun 2012 09:41:04 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 8630721F8770 for ; Wed, 20 Jun 2012 09:41:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id EEB9D171484; Wed, 20 Jun 2012 17:41:02 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1340210462; bh=Xdj0bFLMxH3++/ gkZVMl66E0BG8FpWSrW2jOh3BKcz0=; b=wsg7cHx2cFxNTgwZ/qOBMZRSxzrFKN ZTSL31fK87htnXHVHT4CRWeqb+lTKtSc04gFL+UXkZl0Wu+RRu6Vz6IMolMlZ1c+ nghITLVftiAqQi66kzADq8SVrw93NqXme3NywGrr29HPNGij6YWiKUFU9Dm28x0+ FunIbjWapl/IrUpovEJSOBEzfpgD8ZJo13j7hAF7eeS40uziN4unK08QLmy90QMp w8LMheUWQIcoVvide8VV55z7xBeF95io7G7yi2Ej1lVo48eC6tSnmwjHaWkSs+Em wtKYXPlkL1o4yVFsREDON1yN3ajAiPUnNwPEpMGzXgbAqqvb17LpTZGQ== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id gndMt+btDHTk; Wed, 20 Jun 2012 17:41:02 +0100 (IST) Received: from [IPv6:2001:770:10:203:e59b:9b9d:9813:95ed] (unknown [IPv6:2001:770:10:203:e59b:9b9d:9813:95ed]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 80DD8171482; Wed, 20 Jun 2012 17:41:02 +0100 (IST) Message-ID: <4FE1FD1E.1060601@cs.tcd.ie> Date: Wed, 20 Jun 2012 17:41:02 +0100 From: Stephen Farrell 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: <4FE1C16D.6010602@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-urn-sub-ns-02 X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 16:41:05 -0000 Hi Brian, That all looks fine. I'd say start from the expert review text from the oauth base IANA considerations if that's what you think the WG want. Posting that to the list for checking would seem worthwhile, its common to need a minor tweak or two. I'm ok with having or not having the reference to oauth base security considerations - whatever you prefer. I'll mark this as revised I-D needed. Soon's that's out I'll start IETF LC. Thanks, S. On 06/20/2012 05:26 PM, Brian Campbell wrote: > Thanks Stephen (also Peter) for the review and feedback. Responses are inline. > > On Wed, Jun 20, 2012 at 6:26 AM, Stephen Farrell > wrote: >> >> Hi, >> >> Many thanks for a nice short document! > > If only they could all be so short right? :) > >> I've a few questions though and suspect that a quick re-spin >> might be needed, but let's see what the wg think about 'em >> first. >> >> (1) Why Informational? Everything else at that level seems to >> be specified in a standards track or BCP level RFC, and IETF >> Consensus is required. [1] I think you have to do this as >> standards track. Did I miss something? > > I'm pretty sure that was just an oversight when using some boilerplate > xml to get the document started. I agree with you and Peter that > standards track makes more sense and I've updated my local copy of the > source to reflect that. > >> >> (2) Do you *really* want RFC or specification required for all >> registrations? I don't care, but there is a trend away from >> that at the moment since its been found to discourage >> registrations in a lot of cases. Perhaps expert review would >> be ok? No trying to push you one way or the other, I just >> wanted to check. > > Again I agree with you and Peter - lighter is preferred. Though > Hannes wrote the original text for this so I'd ask that he please > speak up if there was some reason to require RFC here that we aren't > aware of. > > Can you help me with the proper text for this? Is it sufficient to > drop the "NOTE: in order for a URN of this type to be assigned, the > item being registered MUST be documented in a RFC" text from the 1st > paragraph of §3 and change "New entries to the registry are > Specification Required" to "New entries to the registry require expert > review" in §5.1? > > >> (3) If answer to (2) is yes: Section 5.1 says "Specification >> Required" but section 3 said "RFC Required" and those differ. >> For example, an OASIS spec would not be ok if you say RFC >> required. I don't know if you care, but you need to be >> consistent. (Or else I've misread something;-) > > Having chaired an OASIS TC for 2 years I probably should care :) See > the previous comment/question about relaxing this. Expert review > seems good or maybe Specification Required but not RFC Required. > Regardless, your are right, it should at very least be consistent :) > >> (4) Isn't the template missing the reference to the RFC or >> other specification that defines the URN? > > I believe the "Description" portion of the template was intended to > capture that. Or that's how it's kinds been used by specs that use it > anyway. Should we add a "Specification document(s):" to the template? > >> (5) I don't get section 3, sorry;-) Can you give an example of >> a class:id pair that'd be registered? > > http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-12#section-6 > and http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-00#section-6 > are real examples that *hopefully* do the registration correctly. > > Do you think I should add an example registration directly to > draft-ietf-oauth-urn-sub-ns? > >> Asking IANA to generate >> the id part seems odd. > > Agreed. The "please assign" text should probably be removed. It's > really up to the defining spec to say what the class and id are/ > >> nits: >> >> s3: s/generally referred/generally known/ > > Will do. > >> s4: Might be worth pointing at the security considerations >> section of draft-ietf-oauth-v2? I'd say that text would be >> good to have read to know about the security considerations >> for the use of these URNs, before you go making one up. > > Is just referencing it sufficient? > > From bcampbell@pingidentity.com Wed Jun 20 11:13:36 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFF5F21F876D for ; Wed, 20 Jun 2012 11:13:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.577 X-Spam-Level: X-Spam-Status: No, score=-5.577 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_52=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 96d2TvmGL6T9 for ; Wed, 20 Jun 2012 11:13:35 -0700 (PDT) Received: from na3sys009aog121.obsmtp.com (na3sys009aog121.obsmtp.com [74.125.149.145]) by ietfa.amsl.com (Postfix) with ESMTP id 3108C21F8766 for ; Wed, 20 Jun 2012 11:13:34 -0700 (PDT) Received: from mail-qa0-f52.google.com ([209.85.216.52]) (using TLSv1) by na3sys009aob121.postini.com ([74.125.148.12]) with SMTP ID DSNKT+ISzT2vsVyudcdHruZfuJtyrJi7PLD/@postini.com; Wed, 20 Jun 2012 11:13:35 PDT Received: by qabj34 with SMTP id j34so731676qab.4 for ; Wed, 20 Jun 2012 11:13:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=LzkK1uZ2fbeqziUsbTi4sciFja1ReDuQVe5IzIWQtro=; b=jC5bVcx/4/HE8fuO43dGMPx5NfqtSOoF1pPr4tY7RrRech+/+ZAAEZHc8rfMsQhh3K 0FUGLWuxIU2eXJEvTmN+SCh0Py+IH/NiBonh0p1k5k+m4BmSUWPy0orFEYX/YPDoH0WH 7JRwR8D8Jgsl4FlQxa0qFRjkIzeOzr+/vU5Dn1ftOMdOjhL/EaieSWQRmw9LvLWqIxgs iLYSNgOwDtg6klDyD917n9kaT9sWcmHqnh/aUyQ7ZeLVsXvYTXnKEdj5TKwZFwE2FMBc Gv/fJZh5sdWU+ShrZWCgFocU23vTV8+usm2elZFv4zinFC90U0VoHtJPJWMhGibiw+4I Ed1A== Received: by 10.224.212.1 with SMTP id gq1mr42996188qab.54.1340216012988; Wed, 20 Jun 2012 11:13:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.87.142 with HTTP; Wed, 20 Jun 2012 11:13:02 -0700 (PDT) In-Reply-To: <4FE1FD1E.1060601@cs.tcd.ie> References: <4FE1C16D.6010602@cs.tcd.ie> <4FE1FD1E.1060601@cs.tcd.ie> From: Brian Campbell Date: Wed, 20 Jun 2012 12:13:02 -0600 Message-ID: To: Stephen Farrell Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkG1WdQXhqFO76tuaO4sxqcSCRw4LKBoy+6g4FdzTzavZyqD+o6GzFQwVdBQRVCFAnw/VGV Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-urn-sub-ns-02 X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 18:13:37 -0000 Thanks Stephen, I'll try and get all that done soon. On Wed, Jun 20, 2012 at 10:41 AM, Stephen Farrell wrote: > > Hi Brian, > > That all looks fine. > > I'd say start from the expert review text from the oauth base > IANA considerations if that's what you think the WG want. Posting > that to the list for checking would seem worthwhile, its common > to need a minor tweak or two. > > I'm ok with having or not having the reference to oauth > base security considerations - whatever you prefer. > > I'll mark this as revised I-D needed. > > Soon's that's out I'll start IETF LC. > > Thanks, > S. > > > On 06/20/2012 05:26 PM, Brian Campbell wrote: >> Thanks Stephen (also Peter) for the review and feedback. Responses are i= nline. >> >> On Wed, Jun 20, 2012 at 6:26 AM, Stephen Farrell >> wrote: >>> >>> Hi, >>> >>> Many thanks for a nice short document! >> >> If only they could all be so short right? :) >> >>> I've a few questions though and suspect that a quick re-spin >>> might be needed, but let's see what the wg think about 'em >>> first. >>> >>> (1) Why Informational? Everything else at that level seems to >>> be specified in a standards track or BCP level RFC, and IETF >>> Consensus is required. [1] I think you have to do this as >>> standards track. Did I miss something? >> >> I'm pretty sure that was just an oversight when using some boilerplate >> xml to get the document started. I agree with you and Peter that >> standards track makes more sense and I've updated my local copy of the >> source to reflect that. >> >>> >>> (2) Do you *really* want RFC or specification required for all >>> registrations? =A0I don't care, but there is a trend away from >>> that at the moment since its been found to discourage >>> registrations in a lot of cases. Perhaps expert review would >>> be ok? =A0No trying to push you one way or the other, I just >>> wanted to check. >> >> Again I agree with you and Peter - lighter is preferred. =A0Though >> Hannes wrote the original text for this so I'd ask that he please >> speak up if there was some reason to require RFC here that we aren't >> aware of. >> >> Can you help me with the proper text for this? Is it sufficient to >> drop the "NOTE: in =A0order for a URN of this type to be assigned, the >> item being registered MUST be documented in a RFC" text from the 1st >> paragraph of =A73 and change "New entries to the registry are >> Specification Required" to "New entries to the registry require expert >> review" in =A75.1? >> >> >>> (3) If answer to (2) is yes: Section 5.1 says "Specification >>> Required" but section 3 said "RFC Required" and those differ. >>> For example, an OASIS spec would not be ok if you say RFC >>> required. I don't know if you care, but you need to be >>> consistent. (Or else I've misread something;-) >> >> Having chaired an OASIS TC for 2 years I probably should care :) =A0See >> the previous comment/question about relaxing this. =A0Expert review >> seems good or maybe Specification Required but not RFC Required. >> Regardless, your are right, it should at very least be consistent :) >> >>> (4) Isn't the template missing the reference to the RFC or >>> other specification that defines the URN? >> >> I believe the "Description" portion of the template was intended to >> capture that. Or that's how it's kinds been used by specs that use it >> anyway. Should we add a "Specification document(s):" to the template? >> >>> (5) I don't get section 3, sorry;-) Can you give an example of >>> a class:id pair that'd be registered? >> >> http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-12#section-6 >> and http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-00#section-6 >> are real examples that *hopefully* do the registration correctly. >> >> Do you think I should add an example registration directly to >> draft-ietf-oauth-urn-sub-ns? >> >>> Asking IANA to generate >>> the id part seems odd. >> >> Agreed. The "please assign" text should probably be removed. It's >> really up to the defining spec to say what the class and id are/ >> >>> nits: >>> >>> s3: s/generally referred/generally known/ >> >> Will do. >> >>> s4: Might be worth pointing at the security considerations >>> section of draft-ietf-oauth-v2? I'd say that text would be >>> good to have read to know about the security considerations >>> for the use of these URNs, before you go making one up. >> >> Is just referencing it sufficient? >> >> From barryleiba.mailing.lists@gmail.com Wed Jun 20 11:34:55 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFCE421F8773 for ; Wed, 20 Jun 2012 11:34:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.914 X-Spam-Level: X-Spam-Status: No, score=-102.914 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ZtMJFxvoc3l for ; Wed, 20 Jun 2012 11:34:54 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id BF8BD21F8768 for ; Wed, 20 Jun 2012 11:34:53 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so1091107lbb.31 for ; Wed, 20 Jun 2012 11:34:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=9HMoTtKba3MKrEm4pzMk5tLj+eqVurhOAk9iHj+kRhE=; b=vTH+VQXaKWHR/PkQ6PpZENU2kQwS+T2mx63czCQKkPsm0qnir1+4KkVzoC9sdOMEka UmEQVmCnx2nrURLPtwVepANZZoViykAUNG4U0B5sQaOWovTN6jNPB9VyHzz7YHUbEUJQ 3ajehFPAcGdr4v/mjWvwIXO9yTU53yJCebUe8BeEZ3knXDofsjYaTUGbGH2OJcP2PyQi 3m5BZ7UcP1nMoNU/vVDrDCBJdgnVIShoR0xujtQSU/fwKpjuJ83mYHbtBTb+RSFW6ibt ui4VKDHj1S3ABpPCnxlaAmVYPct7xEfsWAPQzwDvMd2IryjJgsaVTcuAxQwcVdD13lQT JwFQ== MIME-Version: 1.0 Received: by 10.152.113.199 with SMTP id ja7mr12950126lab.10.1340217292582; Wed, 20 Jun 2012 11:34:52 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.48.104 with HTTP; Wed, 20 Jun 2012 11:34:52 -0700 (PDT) In-Reply-To: References: <4FE1C16D.6010602@cs.tcd.ie> <4FE1FD1E.1060601@cs.tcd.ie> Date: Wed, 20 Jun 2012 14:34:52 -0400 X-Google-Sender-Auth: Hb_S29IlPn3aGUeqa_DKKgjK-fc Message-ID: From: Barry Leiba To: Brian Campbell Content-Type: text/plain; charset=ISO-8859-1 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-urn-sub-ns-02 X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 18:34:55 -0000 I'd like to see the new version, since there appear to be a bunch of changes, but first here are some issues that I don't think have been brought up yet: The URN registration stuff seems very incompletely baked. The title of 5.1 correctly says it's registering a sub-namespace, but the text incorrectly says that it's creating a registry. Perhaps IANA will understand, but I think you need to do this in two parts. The first part would register the "oauth" sub-namespace, and the second would create a new registry for the things that go into it. Now, as to what goes into it: What is "class"? Is there meant to be a registry of classes? Is that what section 5.1 is trying to create (which should be done in a new section 5.2)? What initial values are registered there? Barry From igor.faynberg@alcatel-lucent.com Wed Jun 20 12:06:57 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15F3B21F85F8 for ; Wed, 20 Jun 2012 12:06:57 -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=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D7z0fIHZnCPv for ; Wed, 20 Jun 2012 12:06:52 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id ACE3921F85F1 for ; Wed, 20 Jun 2012 12:06:51 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id q5KJ6o77011150 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 20 Jun 2012 14:06:50 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q5KJ6otd005503 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 20 Jun 2012 14:06:50 -0500 Received: from [135.244.39.63] (faynberg.lra.lucent.com [135.244.39.63]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q5KJ6ni2020497; Wed, 20 Jun 2012 14:06:49 -0500 (CDT) Message-ID: <4FE21F48.2040806@alcatel-lucent.com> Date: Wed, 20 Jun 2012 15:06:48 -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: <1339792496.52712.YahooMailNeo@web125501.mail.ne1.yahoo.com> <59E470B10C4630419ED717AC79FCF9A9108898EE@BL2PRD0410MB363.namprd04.prod.outlook.com> In-Reply-To: <59E470B10C4630419ED717AC79FCF9A9108898EE@BL2PRD0410MB363.namprd04.prod.outlook.com> Content-Type: multipart/alternative; boundary="------------050802000906080502010209" X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Subject: Re: [OAUTH-WG] Report an authentication issue X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2012 19:06:57 -0000 This is a multi-part message in MIME format. --------------050802000906080502010209 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 6/20/2012 10:03 AM, Lewis Adam-CAL022 wrote ... > > Consider the scenario where I deploy a video server, and write an > iPhone app to talk to the video server. The video server is under the > control of a police agency, and police officers must logon to the > video server in order to access video content. So the police office > launches their iPhone video client app. > > 1)... > > 3)If I wanted to use OAuth, the client would send an authorization > request to the server's AS, which would authenticate the user of the > client, and ultimately result in the client possessing an > access-token. My thinking is that this access token (let's assume > it's a JWT) would contain the user's identity, a statement of what > type of primary authentication was used (auth context), an expiration, > and an audience claim. This sounds a lot like authentication to me, > and it's where I get confused. Is it just because OAuth does not > explicitly define this? Is there a threat in using OAuth as I describe? > > 4) ... > Adam, The problem is that the video server that you described, according to the two options needs specific authentication of the user. OAuth was not designed for this purpose; it was designed for delegating access. In your use case, there is no delegation. The only legitimate users are police officers and they "must logon to the video server in order to access video content." And so the server must authenticate them. There is no need for OAuth in this scenario. Igor > > *From:*oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On > Behalf Of *Kristofor Selden > *Sent:* Saturday, June 16, 2012 11:33 AM > *To:* nov matake; oauth > *Cc:* Yuchen Zhou; Luke Melia; Shuo Chen (MSR) > *Subject:* Re: [OAUTH-WG] Report an authentication issue > > Nov demonstrated the problem to us at Yapp and we used solution 4 > (because the solution is server side and our app was in the app store). > > FB Connect is authentication /and/ authorization, where OAuth 2 is > concerned only with authorization -- I'm not sure that app developers > appreciate this subtlety. > > With OAuth 2 you authorize an app to use a protected resource. With > FB Connect, you do that, but /also/ authenticate with the app you are > authorizing. > > So the access_token protects not just the FB resources but the auth > end point of the authorized app (very common with apps that use the > iOS SDK). So now the app needs a way to verify that it was the app > that was authorized to FB. > > Solution 4 explanation: on FB you can register a iPhone app and a > server app with the same client_id and get a client_secret for use on > the server. The server side API posts the access_token, client_id, > and client_secret to https://graph.facebook.com/app > to verify > that the bearer token actually belongs to the app that is being > authenticated before assuming they are authorized to the app's > protected resources. > > Kris > > On Jun 15, 2012, at 8:22 PM, nov matake wrote: > > > > There are 4 ways to fix this issue. > > 1. Use response_type=token%20code (It's not in OAuth 2.0 Core, but > seems best way for interoperability) > > 2. Use singed_request (or some signed token like JWT) > > 3. Use grant_type=fb_exchange_token (Facebook custom way) > > 4. Access to https://graph.facebook.com/app?access_token=YOUR_TOKEN > (Facebook custom way, moreover undocumented API) > > Two iPhone app developers I reported this issue fixed it by using (4). > > I also tried to use (1) for my own iPhone app implementation, but > unfortunately it doesn't work when using authorization codes obtained > via FB iOS SDK. > > So I'm using (3) in my case. > > nov > > On 2012/06/16, at 9:16, Nat Sakimura wrote: > > > > As to how the fix was done, Nov can provide more detail, but ... > > 1. Properly verify the signature/HMAC of the "signed_request". This > will essentially audience restricts the token. > > 2. There is an undocumented API for Facebook which returns to whom the > token was issued. This also audience restricts the token. > > The service that fixed took these measures. Note that none of the > above is defined in OAuth. > > The same facility was called "id_token" and "check ID endpoint" for > OpenID Connect. > > The scale of the impact is large, too large to disclose the actual > names in the public list, though, eventually, we would publish them in > a paper. > > Nat > > On Sat, Jun 16, 2012 at 5:34 AM, Francisco Corella > > wrote: > > Hi Nat and Rui, > > Rui, you say that the vulnerability that you found was due to a > "common misunderstanding among developers", but the attack you > describe can be carried out against any app that uses the OAuth > "implicit grant flow", which Facebook calls "client-side > authentication". No misunderstanding seems necessary. What > misunderstanding are you referring to? I followed the link in your > message to the Sophos post, and from there the link to the article in > The Register. The article in The Register says that Facebook had > "fixed the vulnerability promptly". How did they fix it? The > instructions that Facebook provides for implementing "Client-side > authentication without the JS SDK" at > https://developers.facebook.com/docs/authentication/client-side/#no-jssdk > still allows the attack. > > Nat, I agree that the blog post by John Bradley that you link to > refers to the same vulnerability reported by Rui. You say that some > apps have issued a patch to fix it. Could you explain what the fix > was? > > Francisco > > ------------------------------------------------------------------------ > > *From:*Nat Sakimura > > *To:* rui wang > > *Cc:* matake nov >; Yuchen > Zhou >; > oauth >; Shuo Chen (MSR) > > > *Sent:* Thursday, June 14, 2012 1:50 PM > *Subject:* Re: [OAUTH-WG] Report an authentication issue > > This is a fairly well known (hopefully by now) issue. We, at the > OpenID Foundation, call it "access_token phishing" attack these > days. See: > http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.html > > Nov Matake has actually built the code on iPhone to verify the > problem, and has notified bunch of parties back in February > including Facebook and Apple. We have the code that actually runs > on a phone, and we have successfully logged in to bunch of apps, > including very well known ones. They were all informed of the > issue. Some immediately issued a patch to fix it while others have > not. > > The problem is that even if these apps gets fixed, the problem > does not go away. As long as the attacker has the vulnerable > version of the app, he still can impersonate the victim. To stop > it, the server side has to completely disable the older version, > which means the service has to cut off many users pausing business > problems. > > Nat > > On Fri, Jun 15, 2012 at 2:18 AM, rui wang > wrote: > > Dear Facebook Security Team and OAuth Standard group, > > We are a research team in Microsoft Research. In January, 2011, we > reported a vulnerability in Facebook Connect which allowed > everyone to sign into Facebook-secured relying parties without > password. It was promptly fixed after reporting. > (http://nakedsecurity.sophos.com/2011/02/02/facebook-flaw-websites-steal-personal-data/) > > Recently, we found a common misunderstanding among developers of > mobile/metro apps when using OAuth (including Facebook's OAuth) > for authentication. The vulnerability resulted from this > misunderstanding also allows an attacker to log into a victim > user's account without password. > > Let's take Soluto's metro app as an example to describe the > problem. The app supports Facebook Login. As an attacker, we can > write a regular Facebook app. Once the victim user allows our app > to access her Facebook data, we receive an access_token from the > traffic. Then, on our own machine (i.e., the "attacker" machine), > we run the metro app of Soluto, and use a HTTP proxy to insert the > victim's access_token into the traffic of Facebook login. Through > this way, we are able to log into the victim's Soluto account from > our machine. Other than Soluto, we also have confirmed the same > issue on another Windows 8 metro-app Givit. > > The Facebook SDK for Android apps > (https://developers.facebook.com/docs/mobile/android/build/#sdk) > seems to have the possibility to mislead developers too. At least, > the issue that we found is not clearly mentioned. In the SDK, we > ran the sample code called "Hackbook" using Android Emulator > (imagine it is an attacker device). Note that we have already > received the access token of the victim user from our regular > Facebook app. We then inject the token to the traffic of Hackbook. > Through this way, Hackbook app on our own machine recognizes us as > the victim. Note that this is not a convincing security exploit > yet, because this sample code does not include the server-side > code. However, given that we have seen real server-side code > having this problem, such as Soluto, Givit and others, we do > believe that the sample code can mislead mobile/metro developers. > We also suspect that this may be a general issue of many OAuth > implementations on mobile platforms, so we send this message to > OAuth Standard group as well. > > We have contacted the vendors of the two vulnerable metro-apps, > Soluto and Gavit. > > Please kindly give us an ack when you receive this message. If you > want to know more details, please let us know. > > Best Regards, > Yuchen Zhou, Rui Wang, and Shuo Chen > > > _______________________________________________ > 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 > > > > -- > 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 --------------050802000906080502010209 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

On 6/20/2012 10:03 AM, Lewis Adam-CAL022 wrote
...

Consider the scenario where I deploy a video server, and write an iPhone app to talk to the video server.  The video server is under the control of a police agency, and police officers must logon to the video server in order to access video content.  So the police office launches their iPhone video client app.

 

1)     ...

3)      If I wanted to use OAuth, the client would send an authorization request to the server’s AS, which would authenticate the user of the client, and ultimately result in the client possessing an access-token.  My thinking is that this access token (let’s assume it’s a JWT) would contain the user’s identity, a statement of what type of primary authentication was used (auth context), an expiration, and an audience claim.  This sounds a lot like authentication to me, and it’s where I get confused.  Is it just because OAuth does not explicitly define this?  Is there a threat in using OAuth as I describe? 

4)     ...

Adam,
 

The problem is that the video server that you described, according to the two options needs specific authentication of the user.  OAuth was not designed for this purpose; it was designed for delegating access.  In your use case,  there is no delegation. The only legitimate users are police officers and they "must logon to the video server in order to access video content."  And so the server must authenticate them. There is no need for OAuth in this scenario.

Igor

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Kristofor Selden
Sent: Saturday, June 16, 2012 11:33 AM
To: nov matake; oauth
Cc: Yuchen Zhou; Luke Melia; Shuo Chen (MSR)
Subject: Re: [OAUTH-WG] Report an authentication issue

 

Nov demonstrated the problem to us at Yapp and we used solution 4 (because the solution is server side and our app was in the app store).

 

FB Connect is authentication and authorization, where OAuth 2 is concerned only with authorization – I'm not sure that app developers appreciate this subtlety.

 

With OAuth 2 you authorize an app to use a protected resource.  With FB Connect, you do that, but also authenticate with the app you are authorizing.

 

So the access_token protects not just the FB resources but the auth end point of the authorized app (very common with apps that use the iOS SDK).  So now the app needs a way to verify that it was the app that was authorized to FB.

 

Solution 4 explanation: on FB you can register a iPhone app and a server app with the same client_id and get a client_secret for use on the server.  The server side API posts the access_token, client_id, and client_secret to https://graph.facebook.com/app to verify that the bearer token actually belongs to the app that is being authenticated before assuming they are authorized to the app's protected resources.

 

Kris

 

On Jun 15, 2012, at 8:22 PM, nov matake wrote:



There are 4 ways to fix this issue.

 

1. Use response_type=token%20code (It's not in OAuth 2.0 Core, but seems best way for interoperability)

2. Use singed_request (or some signed token like JWT)

3. Use grant_type=fb_exchange_token (Facebook custom way)

4. Access to https://graph.facebook.com/app?access_token=YOUR_TOKEN (Facebook custom way, moreover undocumented API)

 

Two iPhone app developers I reported this issue fixed it by using (4).

 

I also tried to use (1) for my own iPhone app implementation, but unfortunately it doesn't work when using authorization codes obtained via FB iOS SDK.

So I'm using (3) in my case.

 

nov

 

On 2012/06/16, at 9:16, Nat Sakimura wrote:



As to how the fix was done, Nov can provide more detail, but ... 

 

1. Properly verify the signature/HMAC of the "signed_request". This will essentially audience restricts the token. 

2. There is an undocumented API for Facebook which returns to whom the token was issued. This also audience restricts the token. 

 

The service that fixed took these measures. Note that none of the above is defined in OAuth. 

The same facility was called "id_token" and "check ID endpoint" for OpenID Connect. 

 

The scale of the impact is large, too large to disclose the actual names in the public list, though, eventually, we would publish them in a paper. 

 

Nat

On Sat, Jun 16, 2012 at 5:34 AM, Francisco Corella <fcorella@pomcor.com> wrote:

Hi Nat and Rui,

Rui, you say that the vulnerability that you found was due to a
"common misunderstanding among developers", but the attack you
describe can be carried out against any app that uses the OAuth
"implicit grant flow", which Facebook calls "client-side
authentication".  No misunderstanding seems necessary.  What
misunderstanding are you referring to?  I followed the link in your
message to the Sophos post, and from there the link to the article in
The Register.  The article in The Register says that Facebook had
"fixed the vulnerability promptly".  How did they fix it?  The
instructions that Facebook provides for implementing "Client-side
authentication without the JS SDK" at
https://developers.facebook.com/docs/authentication/client-side/#no-jssdk
still allows the attack.

Nat, I agree that the blog post by John Bradley that you link to
refers to the same vulnerability reported by Rui.  You say that some
apps have issued a patch to fix it.  Could you explain what the fix
was?

Francisco

 

From: Nat Sakimura <sakimura@gmail.com>
To: rui wang <ruiwangwarm@gmail.com>
Cc: matake nov <nov@matake.jp>; Yuchen Zhou <t-yuzhou@microsoft.com>; oauth <oauth@ietf.org>; Shuo Chen (MSR) <shuochen@microsoft.com>
Sent: Thursday, June 14, 2012 1:50 PM
Subject: Re: [OAUTH-WG] Report an authentication issue

 

This is a fairly well known (hopefully by now) issue. We, at the OpenID Foundation, call it "access_token phishing" attack these days. See: http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.html

 

Nov Matake has actually built the code on iPhone to verify the problem, and has notified bunch of parties back in February including Facebook and Apple. We have the code that actually runs on a phone, and we have successfully logged in to bunch of apps, including very well known ones. They were all informed of the issue. Some immediately issued a patch to fix it while others have not.  

 

The problem is that even if these apps gets fixed, the problem does not go away. As long as the attacker has the vulnerable version of the app, he still can impersonate the victim. To stop it, the server side has to completely disable the older version, which means the service has to cut off many users pausing business problems. 

 

Nat

On Fri, Jun 15, 2012 at 2:18 AM, rui wang <ruiwangwarm@gmail.com> wrote:

Dear Facebook Security Team and OAuth Standard group,

We are a research team in Microsoft Research. In January, 2011, we reported a vulnerability in Facebook Connect which allowed everyone to sign into Facebook-secured relying parties without password. It was promptly fixed after reporting. (http://nakedsecurity.sophos.com/2011/02/02/facebook-flaw-websites-steal-personal-data/)

Recently, we found a common misunderstanding among developers of mobile/metro apps when using OAuth (including Facebook’s OAuth) for authentication. The vulnerability resulted from this misunderstanding also allows an attacker to log into a victim user's account without password.

Let's take Soluto's metro app as an example to describe the problem. The app supports Facebook Login. As an attacker, we can write a regular Facebook app. Once the victim user allows our app to access her Facebook data, we receive an access_token from the traffic. Then, on our own machine (i.e., the "attacker" machine), we run the metro app of Soluto, and use a HTTP proxy to insert the victim's access_token into the traffic of Facebook login. Through this way, we are able to log into the victim's Soluto account from our machine. Other than Soluto, we also have confirmed the same issue on another Windows 8 metro-app Givit.

The Facebook SDK for Android apps (https://developers.facebook.com/docs/mobile/android/build/#sdk) seems to have the possibility to mislead developers too. At least, the issue that we found is not clearly mentioned. In the SDK, we ran the sample code called "Hackbook" using Android Emulator (imagine it is an attacker device). Note that we have already received the access token of the victim user from our regular Facebook app. We then inject the token to the traffic of Hackbook. Through this way, Hackbook app on our own machine recognizes us as the victim. Note that this is not a convincing security exploit yet, because this sample code does not include the server-side code. However, given that we have seen real server-side code having this problem, such as Soluto, Givit and others, we do believe that the sample code can mislead mobile/metro developers. We also suspect that this may be a general issue of many OAuth implementations on mobile platforms, so we send this message to OAuth Standard group as well.

We have contacted the vendors of the two vulnerable metro-apps, Soluto and Gavit.

Please kindly give us an ack when you receive this message. If you want to know more details, please let us know.

Best Regards,
Yuchen Zhou, Rui Wang, and Shuo Chen


_______________________________________________
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



 

--
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
--------------050802000906080502010209-- From jricher@mitre.org Wed Jun 20 12:10:58 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5357621F87D7 for ; Wed, 20 Jun 2012 12:10:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.478 X-Spam-Level: X-Spam-Status: No, score=-6.478 tagged_above=-999 required=5 tests=[AWL=0.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 zAnLruBmPCWM for ; Wed, 20 Jun 2012 12:10:56 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 7F9DC21F87D4 for ; Wed, 20 Jun 2012 12:10:56 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 78F1521B15CC for ; Wed, 20 Jun 2012 15:10:51 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 6018A21B15A2 for ; Wed, 20 Jun 2012 15:10:51 -0400 (EDT) Received: from [129.83.50.26] (129.83.31.51) by IMCCAS02.MITRE.ORG (129.83.29.79) with Microsoft SMTP Server (TLS) id 14.2.283.3; Wed, 20 Jun 2012 15:10:50 -0400 Message-ID: <4FE22028.8090903@mitre.org> Date: Wed, 20 Jun 2012 15:10:32 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: References: <1339792496.52712.YahooMailNeo@web125501.mail.ne1.yahoo.com> <59E470B10C4630419ED717AC79FCF9A9108898EE@BL2PRD0410MB363.namprd04.prod.outlook.com> In-Reply-To: <59E470B10C4630419ED717AC79FCF9A9108898EE@BL2PRD0410MB363.namprd04.prod.outlook.com> Content-Type: multipart/alternative; boundary="------------000104000507040301020002" X-Originating-IP: [129.83.31.51] Subject: Re: [OAUTH-WG] Report an authentication issue X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 19:10:58 -0000 --------------000104000507040301020002 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit > > 3)If I wanted to use OAuth, the client would send an authorization > request to the server's AS, which would authenticate the user of the > client, and ultimately result in the client possessing an > access-token. My thinking is that this access token (let's assume > it's a JWT) would contain the user's identity, a statement of what > type of primary authentication was used (auth context), an expiration, > and an audience claim. This sounds a lot like authentication to me, > and it's where I get confused. Is it just because OAuth does not > explicitly define this? Is there a threat in using OAuth as I describe? > You've hit on it here -- you're using OAuth *plus* a few other bits to accomplish this. Using a JWT lets you do things like signed tokens and audience restriction so that clients won't just take *any* token. > 4)If I wanted to use Connect, well I'm not even sure how the id_token > as defined by Connect helps this use case. The id_token seems to make > sense when the client is a confidential web server, but it's not clear > what an iPhone app would do with the id_token ... it's the server in > the backend that needs to authenticate the user, the iPhone app is > just an interface to talk to the server. And it seems as I learn more > about connect that the id_token is not meant to be sent from the > iPhone app to the server, just the access token. So it's really not > clear how Connect helps solve authentication for an iPhone client app > talking to a video server. If I'm sending access-tokens, it's just > OAuth again. > Connect adds a few things on top of OAuth to make authentication possible, and one of these is the id_token. But what you're really after in your scenario isn't authentication at the RS per se -- it's authorization for accessing it. -- Justin --------------000104000507040301020002 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit


3)      If I wanted to use OAuth, the client would send an authorization request to the server’s AS, which would authenticate the user of the client, and ultimately result in the client possessing an access-token.  My thinking is that this access token (let’s assume it’s a JWT) would contain the user’s identity, a statement of what type of primary authentication was used (auth context), an expiration, and an audience claim.  This sounds a lot like authentication to me, and it’s where I get confused.  Is it just because OAuth does not explicitly define this?  Is there a threat in using OAuth as I describe? 


You've hit on it here -- you're using OAuth *plus* a few other bits to accomplish this. Using a JWT lets you do things like signed tokens and audience restriction so that clients won't just take *any* token.

4)      If I wanted to use Connect, well I’m not even sure how the id_token as defined by Connect helps this use case.  The id_token seems to make sense when the client is a confidential web server, but it’s not clear what an iPhone app would do with the id_token … it’s the server in the backend that needs to authenticate the user, the iPhone app is just an interface to talk to the server.  And it seems as I learn more about connect that the id_token is not meant to be sent from the iPhone app to the server, just the access token.  So it’s really not clear how Connect helps solve authentication for an iPhone client app talking to a video server.  If I’m sending access-tokens, it’s just OAuth again.


Connect adds a few things on top of OAuth to make authentication possible, and one of these is the id_token. But what you're really after in your scenario isn't authentication at the RS per se -- it's authorization for accessing it.

 -- Justin
--------------000104000507040301020002-- From jricher@mitre.org Wed Jun 20 12:26:55 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A99621F8644 for ; Wed, 20 Jun 2012 12:26:55 -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 bmt+ISoX0hIG for ; Wed, 20 Jun 2012 12:26:49 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id CDE3A21F86C8 for ; Wed, 20 Jun 2012 12:26:48 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 7CF7B21B15A7; Wed, 20 Jun 2012 15:26:48 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 5229C21B15C7; Wed, 20 Jun 2012 15:26:48 -0400 (EDT) Received: from [129.83.50.26] (129.83.31.51) by IMCCAS01.MITRE.ORG (129.83.29.78) with Microsoft SMTP Server (TLS) id 14.2.283.3; Wed, 20 Jun 2012 15:26:47 -0400 Message-ID: <4FE223E4.6060307@mitre.org> Date: Wed, 20 Jun 2012 15:26:28 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Lewis Adam-CAL022 References: <1339792496.52712.YahooMailNeo@web125501.mail.ne1.yahoo.com> <59E470B10C4630419ED717AC79FCF9A9108898EE@BL2PRD0410MB363.namprd04.prod.outlook.com> In-Reply-To: <59E470B10C4630419ED717AC79FCF9A9108898EE@BL2PRD0410MB363.namprd04.prod.outlook.com> Content-Type: multipart/alternative; boundary="------------030308000703090707020903" X-Originating-IP: [129.83.31.51] Cc: Luke Melia , nov matake , Yuchen Zhou , "Shuo Chen \(MSR\)" , Kristofor Selden , oauth Subject: Re: [OAUTH-WG] Report an authentication issue X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 19:26:55 -0000 --------------030308000703090707020903 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit In case it wasn't clear, I want to restate the original problem as best as I understand it in a way that hopefully clears it up: App A and app B are both valid registered OAuth clients to an OAuth protected service. The problem starts when app A gets handed a token that was issued for app B and uses it to call an identity API on the OAuth service. Since app B can get tokens just fine, they're bearer tokens, this is a fairly basic api call, this function works just fine and returns the user info. This makes sense, since anyone who holds A's tokens can do whatever A can do on behalf of that user. The issues start when app B then decides that since they can make a call to the identity API with a token then the user *must* be present. In other words, app B is confusing authorization to call an API with authentication of the session. OpenID Connect fixes this missed assumption by binding the ID Token to the session and sending it along side the access token, but as you pointed out, it's meant for consumption at the client, not the resource server, in general. That doesn't mean you can't send it to a resource server for your own purposes, of course. That's actually how the session management endpoint works in Connect. This isn't the only way to handle this problem -- if you put some structure in your tokens, such as with JWT or SAML, then app A can tell that this isn't a token issued to app A, but to app B, so it can call shenanigans and reject it then and there. -- Justin On 06/20/2012 10:03 AM, Lewis Adam-CAL022 wrote: > > I am entirely confused. > > I understand what everybody is saying for confidential clients, no > problem here. > > I fall apart when thinking of iPhone apps. Consider the scenario > where I deploy a video server, and write an iPhone app to talk to the > video server. The video server is under the control of a police > agency, and police officers must logon to the video server in order to > access video content. So the police office launches their iPhone > video client app. > > 1)If I wanted to solve authentication using "traditional" > client-server authentication, the user enters their username / > password into the client, and the client sends the username / password > off to the server, which authenticates it, or possibly uses HTTP digest. > > 2)If I wanted to use OpenID, the client would attempt to reach the > video server (RP), the server would redirect the client to the OP, OP > authenticates user, and OP redirects client back to the server/RP with > an assertion that primary authentication was successful. > > 3)If I wanted to use OAuth, the client would send an authorization > request to the server's AS, which would authenticate the user of the > client, and ultimately result in the client possessing an > access-token. My thinking is that this access token (let's assume > it's a JWT) would contain the user's identity, a statement of what > type of primary authentication was used (auth context), an expiration, > and an audience claim. This sounds a lot like authentication to me, > and it's where I get confused. Is it just because OAuth does not > explicitly define this? Is there a threat in using OAuth as I describe? > > 4)If I wanted to use Connect, well I'm not even sure how the id_token > as defined by Connect helps this use case. The id_token seems to make > sense when the client is a confidential web server, but it's not clear > what an iPhone app would do with the id_token ... it's the server in > the backend that needs to authenticate the user, the iPhone app is > just an interface to talk to the server. And it seems as I learn more > about connect that the id_token is not meant to be sent from the > iPhone app to the server, just the access token. So it's really not > clear how Connect helps solve authentication for an iPhone client app > talking to a video server. If I'm sending access-tokens, it's just > OAuth again. > > What am I still missing? > > adam > > *From:*oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On > Behalf Of *Kristofor Selden > *Sent:* Saturday, June 16, 2012 11:33 AM > *To:* nov matake; oauth > *Cc:* Yuchen Zhou; Luke Melia; Shuo Chen (MSR) > *Subject:* Re: [OAUTH-WG] Report an authentication issue > > Nov demonstrated the problem to us at Yapp and we used solution 4 > (because the solution is server side and our app was in the app store). > > FB Connect is authentication /and/ authorization, where OAuth 2 is > concerned only with authorization -- I'm not sure that app developers > appreciate this subtlety. > > With OAuth 2 you authorize an app to use a protected resource. With > FB Connect, you do that, but /also/ authenticate with the app you are > authorizing. > > So the access_token protects not just the FB resources but the auth > end point of the authorized app (very common with apps that use the > iOS SDK). So now the app needs a way to verify that it was the app > that was authorized to FB. > > Solution 4 explanation: on FB you can register a iPhone app and a > server app with the same client_id and get a client_secret for use on > the server. The server side API posts the access_token, client_id, > and client_secret to https://graph.facebook.com/app > to verify > that the bearer token actually belongs to the app that is being > authenticated before assuming they are authorized to the app's > protected resources. > > Kris > > On Jun 15, 2012, at 8:22 PM, nov matake wrote: > > > > There are 4 ways to fix this issue. > > 1. Use response_type=token%20code (It's not in OAuth 2.0 Core, but > seems best way for interoperability) > > 2. Use singed_request (or some signed token like JWT) > > 3. Use grant_type=fb_exchange_token (Facebook custom way) > > 4. Access to https://graph.facebook.com/app?access_token=YOUR_TOKEN > (Facebook custom way, moreover undocumented API) > > Two iPhone app developers I reported this issue fixed it by using (4). > > I also tried to use (1) for my own iPhone app implementation, but > unfortunately it doesn't work when using authorization codes obtained > via FB iOS SDK. > > So I'm using (3) in my case. > > nov > > On 2012/06/16, at 9:16, Nat Sakimura wrote: > > > > As to how the fix was done, Nov can provide more detail, but ... > > 1. Properly verify the signature/HMAC of the "signed_request". This > will essentially audience restricts the token. > > 2. There is an undocumented API for Facebook which returns to whom the > token was issued. This also audience restricts the token. > > The service that fixed took these measures. Note that none of the > above is defined in OAuth. > > The same facility was called "id_token" and "check ID endpoint" for > OpenID Connect. > > The scale of the impact is large, too large to disclose the actual > names in the public list, though, eventually, we would publish them in > a paper. > > Nat > > On Sat, Jun 16, 2012 at 5:34 AM, Francisco Corella > > wrote: > > Hi Nat and Rui, > > Rui, you say that the vulnerability that you found was due to a > "common misunderstanding among developers", but the attack you > describe can be carried out against any app that uses the OAuth > "implicit grant flow", which Facebook calls "client-side > authentication". No misunderstanding seems necessary. What > misunderstanding are you referring to? I followed the link in your > message to the Sophos post, and from there the link to the article in > The Register. The article in The Register says that Facebook had > "fixed the vulnerability promptly". How did they fix it? The > instructions that Facebook provides for implementing "Client-side > authentication without the JS SDK" at > https://developers.facebook.com/docs/authentication/client-side/#no-jssdk > still allows the attack. > > Nat, I agree that the blog post by John Bradley that you link to > refers to the same vulnerability reported by Rui. You say that some > apps have issued a patch to fix it. Could you explain what the fix > was? > > Francisco > > ------------------------------------------------------------------------ > > *From:*Nat Sakimura > > *To:* rui wang > > *Cc:* matake nov >; Yuchen > Zhou >; > oauth >; Shuo Chen (MSR) > > > *Sent:* Thursday, June 14, 2012 1:50 PM > *Subject:* Re: [OAUTH-WG] Report an authentication issue > > This is a fairly well known (hopefully by now) issue. We, at the > OpenID Foundation, call it "access_token phishing" attack these > days. See: > http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.html > > Nov Matake has actually built the code on iPhone to verify the > problem, and has notified bunch of parties back in February > including Facebook and Apple. We have the code that actually runs > on a phone, and we have successfully logged in to bunch of apps, > including very well known ones. They were all informed of the > issue. Some immediately issued a patch to fix it while others have > not. > > The problem is that even if these apps gets fixed, the problem > does not go away. As long as the attacker has the vulnerable > version of the app, he still can impersonate the victim. To stop > it, the server side has to completely disable the older version, > which means the service has to cut off many users pausing business > problems. > > Nat > > On Fri, Jun 15, 2012 at 2:18 AM, rui wang > wrote: > > Dear Facebook Security Team and OAuth Standard group, > > We are a research team in Microsoft Research. In January, 2011, we > reported a vulnerability in Facebook Connect which allowed > everyone to sign into Facebook-secured relying parties without > password. It was promptly fixed after reporting. > (http://nakedsecurity.sophos.com/2011/02/02/facebook-flaw-websites-steal-personal-data/) > > Recently, we found a common misunderstanding among developers of > mobile/metro apps when using OAuth (including Facebook's OAuth) > for authentication. The vulnerability resulted from this > misunderstanding also allows an attacker to log into a victim > user's account without password. > > Let's take Soluto's metro app as an example to describe the > problem. The app supports Facebook Login. As an attacker, we can > write a regular Facebook app. Once the victim user allows our app > to access her Facebook data, we receive an access_token from the > traffic. Then, on our own machine (i.e., the "attacker" machine), > we run the metro app of Soluto, and use a HTTP proxy to insert the > victim's access_token into the traffic of Facebook login. Through > this way, we are able to log into the victim's Soluto account from > our machine. Other than Soluto, we also have confirmed the same > issue on another Windows 8 metro-app Givit. > > The Facebook SDK for Android apps > (https://developers.facebook.com/docs/mobile/android/build/#sdk) > seems to have the possibility to mislead developers too. At least, > the issue that we found is not clearly mentioned. In the SDK, we > ran the sample code called "Hackbook" using Android Emulator > (imagine it is an attacker device). Note that we have already > received the access token of the victim user from our regular > Facebook app. We then inject the token to the traffic of Hackbook. > Through this way, Hackbook app on our own machine recognizes us as > the victim. Note that this is not a convincing security exploit > yet, because this sample code does not include the server-side > code. However, given that we have seen real server-side code > having this problem, such as Soluto, Givit and others, we do > believe that the sample code can mislead mobile/metro developers. > We also suspect that this may be a general issue of many OAuth > implementations on mobile platforms, so we send this message to > OAuth Standard group as well. > > We have contacted the vendors of the two vulnerable metro-apps, > Soluto and Gavit. > > Please kindly give us an ack when you receive this message. If you > want to know more details, please let us know. > > Best Regards, > Yuchen Zhou, Rui Wang, and Shuo Chen > > > _______________________________________________ > 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 > > > > -- > 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 --------------030308000703090707020903 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit In case it wasn't clear, I want to restate the original problem as best as I understand it in a way that hopefully clears it up:

App A and app B are both valid registered OAuth clients to an OAuth protected service.

The problem starts when app A gets handed a token that was issued for app B and uses it to call an identity API on the OAuth service. Since app B can get tokens just fine, they're bearer tokens, this is a fairly basic api call, this function works just fine and returns the user info. This makes sense, since anyone who holds A's tokens can do whatever A can do on behalf of that user. The issues start when app B then decides that since they can make a call to the identity API with a token then the user *must* be present. In other words, app B is confusing authorization to call an API with authentication of the session.

OpenID Connect fixes this missed assumption by binding the ID Token to the session and sending it along side the access token, but as you pointed out, it's meant for consumption at the client, not the resource server, in general. That doesn't mean you can't send it to a resource server for your own purposes, of course. That's actually how the session management endpoint works in Connect.

This isn't the only way to handle this problem -- if you put some structure in your tokens, such as with JWT or SAML, then app A can tell that this isn't a token issued to app A, but to app B, so it can call shenanigans and reject it then and there.

 -- Justin

On 06/20/2012 10:03 AM, Lewis Adam-CAL022 wrote:

I am entirely confused.

 

I understand what everybody is saying for confidential clients, no problem here.

 

I fall apart when thinking of iPhone apps.  Consider the scenario where I deploy a video server, and write an iPhone app to talk to the video server.  The video server is under the control of a police agency, and police officers must logon to the video server in order to access video content.  So the police office launches their iPhone video client app.

 

1)      If I wanted to solve authentication using “traditional” client-server authentication, the user enters their username / password into the client, and the client sends the username / password off to the server, which authenticates it, or possibly uses HTTP digest. 

2)      If I wanted to use OpenID, the client would attempt to reach the video server (RP), the server would redirect the client to the OP, OP authenticates user, and OP redirects client back to the server/RP with an assertion that primary authentication was successful. 

3)      If I wanted to use OAuth, the client would send an authorization request to the server’s AS, which would authenticate the user of the client, and ultimately result in the client possessing an access-token.  My thinking is that this access token (let’s assume it’s a JWT) would contain the user’s identity, a statement of what type of primary authentication was used (auth context), an expiration, and an audience claim.  This sounds a lot like authentication to me, and it’s where I get confused.  Is it just because OAuth does not explicitly define this?  Is there a threat in using OAuth as I describe? 

4)      If I wanted to use Connect, well I’m not even sure how the id_token as defined by Connect helps this use case.  The id_token seems to make sense when the client is a confidential web server, but it’s not clear what an iPhone app would do with the id_token … it’s the server in the backend that needs to authenticate the user, the iPhone app is just an interface to talk to the server.  And it seems as I learn more about connect that the id_token is not meant to be sent from the iPhone app to the server, just the access token.  So it’s really not clear how Connect helps solve authentication for an iPhone client app talking to a video server.  If I’m sending access-tokens, it’s just OAuth again.

 

What am I still missing?

adam

 

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Kristofor Selden
Sent: Saturday, June 16, 2012 11:33 AM
To: nov matake; oauth
Cc: Yuchen Zhou; Luke Melia; Shuo Chen (MSR)
Subject: Re: [OAUTH-WG] Report an authentication issue

 

Nov demonstrated the problem to us at Yapp and we used solution 4 (because the solution is server side and our app was in the app store).

 

FB Connect is authentication and authorization, where OAuth 2 is concerned only with authorization – I'm not sure that app developers appreciate this subtlety.

 

With OAuth 2 you authorize an app to use a protected resource.  With FB Connect, you do that, but also authenticate with the app you are authorizing.

 

So the access_token protects not just the FB resources but the auth end point of the authorized app (very common with apps that use the iOS SDK).  So now the app needs a way to verify that it was the app that was authorized to FB.

 

Solution 4 explanation: on FB you can register a iPhone app and a server app with the same client_id and get a client_secret for use on the server.  The server side API posts the access_token, client_id, and client_secret to https://graph.facebook.com/app to verify that the bearer token actually belongs to the app that is being authenticated before assuming they are authorized to the app's protected resources.

 

Kris

 

On Jun 15, 2012, at 8:22 PM, nov matake wrote:



There are 4 ways to fix this issue.

 

1. Use response_type=token%20code (It's not in OAuth 2.0 Core, but seems best way for interoperability)

2. Use singed_request (or some signed token like JWT)

3. Use grant_type=fb_exchange_token (Facebook custom way)

4. Access to https://graph.facebook.com/app?access_token=YOUR_TOKEN (Facebook custom way, moreover undocumented API)

 

Two iPhone app developers I reported this issue fixed it by using (4).

 

I also tried to use (1) for my own iPhone app implementation, but unfortunately it doesn't work when using authorization codes obtained via FB iOS SDK.

So I'm using (3) in my case.

 

nov

 

On 2012/06/16, at 9:16, Nat Sakimura wrote:



As to how the fix was done, Nov can provide more detail, but ... 

 

1. Properly verify the signature/HMAC of the "signed_request". This will essentially audience restricts the token. 

2. There is an undocumented API for Facebook which returns to whom the token was issued. This also audience restricts the token. 

 

The service that fixed took these measures. Note that none of the above is defined in OAuth. 

The same facility was called "id_token" and "check ID endpoint" for OpenID Connect. 

 

The scale of the impact is large, too large to disclose the actual names in the public list, though, eventually, we would publish them in a paper. 

 

Nat

On Sat, Jun 16, 2012 at 5:34 AM, Francisco Corella <fcorella@pomcor.com> wrote:

Hi Nat and Rui,

Rui, you say that the vulnerability that you found was due to a
"common misunderstanding among developers", but the attack you
describe can be carried out against any app that uses the OAuth
"implicit grant flow", which Facebook calls "client-side
authentication".  No misunderstanding seems necessary.  What
misunderstanding are you referring to?  I followed the link in your
message to the Sophos post, and from there the link to the article in
The Register.  The article in The Register says that Facebook had
"fixed the vulnerability promptly".  How did they fix it?  The
instructions that Facebook provides for implementing "Client-side
authentication without the JS SDK" at
https://developers.facebook.com/docs/authentication/client-side/#no-jssdk
still allows the attack.

Nat, I agree that the blog post by John Bradley that you link to
refers to the same vulnerability reported by Rui.  You say that some
apps have issued a patch to fix it.  Could you explain what the fix
was?

Francisco

 

From: Nat Sakimura <sakimura@gmail.com>
To: rui wang <ruiwangwarm@gmail.com>
Cc: matake nov <nov@matake.jp>; Yuchen Zhou <t-yuzhou@microsoft.com>; oauth <oauth@ietf.org>; Shuo Chen (MSR) <shuochen@microsoft.com>
Sent: Thursday, June 14, 2012 1:50 PM
Subject: Re: [OAUTH-WG] Report an authentication issue

 

This is a fairly well known (hopefully by now) issue. We, at the OpenID Foundation, call it "access_token phishing" attack these days. See: http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.html

 

Nov Matake has actually built the code on iPhone to verify the problem, and has notified bunch of parties back in February including Facebook and Apple. We have the code that actually runs on a phone, and we have successfully logged in to bunch of apps, including very well known ones. They were all informed of the issue. Some immediately issued a patch to fix it while others have not.  

 

The problem is that even if these apps gets fixed, the problem does not go away. As long as the attacker has the vulnerable version of the app, he still can impersonate the victim. To stop it, the server side has to completely disable the older version, which means the service has to cut off many users pausing business problems. 

 

Nat

On Fri, Jun 15, 2012 at 2:18 AM, rui wang <ruiwangwarm@gmail.com> wrote:

Dear Facebook Security Team and OAuth Standard group,

We are a research team in Microsoft Research. In January, 2011, we reported a vulnerability in Facebook Connect which allowed everyone to sign into Facebook-secured relying parties without password. It was promptly fixed after reporting. (http://nakedsecurity.sophos.com/2011/02/02/facebook-flaw-websites-steal-personal-data/)

Recently, we found a common misunderstanding among developers of mobile/metro apps when using OAuth (including Facebook’s OAuth) for authentication. The vulnerability resulted from this misunderstanding also allows an attacker to log into a victim user's account without password.

Let's take Soluto's metro app as an example to describe the problem. The app supports Facebook Login. As an attacker, we can write a regular Facebook app. Once the victim user allows our app to access her Facebook data, we receive an access_token from the traffic. Then, on our own machine (i.e., the "attacker" machine), we run the metro app of Soluto, and use a HTTP proxy to insert the victim's access_token into the traffic of Facebook login. Through this way, we are able to log into the victim's Soluto account from our machine. Other than Soluto, we also have confirmed the same issue on another Windows 8 metro-app Givit.

The Facebook SDK for Android apps (https://developers.facebook.com/docs/mobile/android/build/#sdk) seems to have the possibility to mislead developers too. At least, the issue that we found is not clearly mentioned. In the SDK, we ran the sample code called "Hackbook" using Android Emulator (imagine it is an attacker device). Note that we have already received the access token of the victim user from our regular Facebook app. We then inject the token to the traffic of Hackbook. Through this way, Hackbook app on our own machine recognizes us as the victim. Note that this is not a convincing security exploit yet, because this sample code does not include the server-side code. However, given that we have seen real server-side code having this problem, such as Soluto, Givit and others, we do believe that the sample code can mislead mobile/metro developers. We also suspect that this may be a general issue of many OAuth implementations on mobile platforms, so we send this message to OAuth Standard group as well.

We have contacted the vendors of the two vulnerable metro-apps, Soluto and Gavit.

Please kindly give us an ack when you receive this message. If you want to know more details, please let us know.

Best Regards,
Yuchen Zhou, Rui Wang, and Shuo Chen


_______________________________________________
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



 

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

--------------030308000703090707020903-- From igor.faynberg@alcatel-lucent.com Wed Jun 20 12:38:47 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3980B21F8681 for ; Wed, 20 Jun 2012 12:38:47 -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=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F0KsZ5TXSQMQ for ; Wed, 20 Jun 2012 12:38:41 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id C174C21F8674 for ; Wed, 20 Jun 2012 12:38:39 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q5KJccN8019650 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 20 Jun 2012 14:38:38 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q5KJcbkH012356 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 20 Jun 2012 14:38:38 -0500 Received: from [135.244.39.63] (faynberg.lra.lucent.com [135.244.39.63]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q5KJca5G015082; Wed, 20 Jun 2012 14:38:36 -0500 (CDT) Message-ID: <4FE226BC.6010403@alcatel-lucent.com> Date: Wed, 20 Jun 2012 15:38:36 -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: <1339792496.52712.YahooMailNeo@web125501.mail.ne1.yahoo.com> <59E470B10C4630419ED717AC79FCF9A9108898EE@BL2PRD0410MB363.namprd04.prod.outlook.com> <4FE223E4.6060307@mitre.org> In-Reply-To: <4FE223E4.6060307@mitre.org> Content-Type: multipart/alternative; boundary="------------040204060605080606010304" X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Subject: Re: [OAUTH-WG] Report an authentication issue X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2012 19:38:47 -0000 This is a multi-part message in MIME format. --------------040204060605080606010304 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit But this use case does need OAuth, period: The video server is under the control of a police agency, and police officers must logon to the video server in order to access video content. There is no delegation here, and there is no need to use third party for authentication. Igor On 6/20/2012 3:26 PM, Justin Richer wrote: > In case it wasn't clear, I want to restate the original problem as > best as I understand it in a way that hopefully clears it up: > > App A and app B are both valid registered OAuth clients to an OAuth > protected service. > > The problem starts when app A gets handed a token that was issued for > app B and uses it to call an identity API on the OAuth service. Since > app B can get tokens just fine, they're bearer tokens, this is a > fairly basic api call, this function works just fine and returns the > user info. This makes sense, since anyone who holds A's tokens can do > whatever A can do on behalf of that user. The issues start when app B > then decides that since they can make a call to the identity API with > a token then the user *must* be present. In other words, app B is > confusing authorization to call an API with authentication of the session. > > OpenID Connect fixes this missed assumption by binding the ID Token to > the session and sending it along side the access token, but as you > pointed out, it's meant for consumption at the client, not the > resource server, in general. That doesn't mean you can't send it to a > resource server for your own purposes, of course. That's actually how > the session management endpoint works in Connect. > > This isn't the only way to handle this problem -- if you put some > structure in your tokens, such as with JWT or SAML, then app A can > tell that this isn't a token issued to app A, but to app B, so it can > call shenanigans and reject it then and there. > > -- Justin > > On 06/20/2012 10:03 AM, Lewis Adam-CAL022 wrote: >> >> I am entirely confused. >> >> I understand what everybody is saying for confidential clients, no >> problem here. >> >> I fall apart when thinking of iPhone apps. Consider the scenario >> where I deploy a video server, and write an iPhone app to talk to the >> video server. The video server is under the control of a police >> agency, and police officers must logon to the video server in order >> to access video content. So the police office launches their iPhone >> video client app. >> >> 1)If I wanted to solve authentication using "traditional" >> client-server authentication, the user enters their username / >> password into the client, and the client sends the username / >> password off to the server, which authenticates it, or possibly uses >> HTTP digest. >> >> 2)If I wanted to use OpenID, the client would attempt to reach the >> video server (RP), the server would redirect the client to the OP, OP >> authenticates user, and OP redirects client back to the server/RP >> with an assertion that primary authentication was successful. >> >> 3)If I wanted to use OAuth, the client would send an authorization >> request to the server's AS, which would authenticate the user of the >> client, and ultimately result in the client possessing an >> access-token. My thinking is that this access token (let's assume >> it's a JWT) would contain the user's identity, a statement of what >> type of primary authentication was used (auth context), an >> expiration, and an audience claim. This sounds a lot like >> authentication to me, and it's where I get confused. Is it just >> because OAuth does not explicitly define this? Is there a threat in >> using OAuth as I describe? >> >> 4)If I wanted to use Connect, well I'm not even sure how the id_token >> as defined by Connect helps this use case. The id_token seems to >> make sense when the client is a confidential web server, but it's not >> clear what an iPhone app would do with the id_token ... it's the >> server in the backend that needs to authenticate the user, the iPhone >> app is just an interface to talk to the server. And it seems as I >> learn more about connect that the id_token is not meant to be sent >> from the iPhone app to the server, just the access token. So it's >> really not clear how Connect helps solve authentication for an iPhone >> client app talking to a video server. If I'm sending access-tokens, >> it's just OAuth again. >> >> What am I still missing? >> >> adam >> >> *From:*oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On >> Behalf Of *Kristofor Selden >> *Sent:* Saturday, June 16, 2012 11:33 AM >> *To:* nov matake; oauth >> *Cc:* Yuchen Zhou; Luke Melia; Shuo Chen (MSR) >> *Subject:* Re: [OAUTH-WG] Report an authentication issue >> >> Nov demonstrated the problem to us at Yapp and we used solution 4 >> (because the solution is server side and our app was in the app store). >> >> FB Connect is authentication /and/ authorization, where OAuth 2 is >> concerned only with authorization -- I'm not sure that app developers >> appreciate this subtlety. >> >> With OAuth 2 you authorize an app to use a protected resource. With >> FB Connect, you do that, but /also/ authenticate with the app you are >> authorizing. >> >> So the access_token protects not just the FB resources but the auth >> end point of the authorized app (very common with apps that use the >> iOS SDK). So now the app needs a way to verify that it was the app >> that was authorized to FB. >> >> Solution 4 explanation: on FB you can register a iPhone app and a >> server app with the same client_id and get a client_secret for use on >> the server. The server side API posts the access_token, client_id, >> and client_secret to https://graph.facebook.com/app >> to verify >> that the bearer token actually belongs to the app that is being >> authenticated before assuming they are authorized to the app's >> protected resources. >> >> Kris >> >> On Jun 15, 2012, at 8:22 PM, nov matake wrote: >> >> >> >> There are 4 ways to fix this issue. >> >> 1. Use response_type=token%20code (It's not in OAuth 2.0 Core, but >> seems best way for interoperability) >> >> 2. Use singed_request (or some signed token like JWT) >> >> 3. Use grant_type=fb_exchange_token (Facebook custom way) >> >> 4. Access to https://graph.facebook.com/app?access_token=YOUR_TOKEN >> (Facebook custom way, moreover undocumented API) >> >> Two iPhone app developers I reported this issue fixed it by using (4). >> >> I also tried to use (1) for my own iPhone app implementation, but >> unfortunately it doesn't work when using authorization codes obtained >> via FB iOS SDK. >> >> So I'm using (3) in my case. >> >> nov >> >> On 2012/06/16, at 9:16, Nat Sakimura wrote: >> >> >> >> As to how the fix was done, Nov can provide more detail, but ... >> >> 1. Properly verify the signature/HMAC of the "signed_request". This >> will essentially audience restricts the token. >> >> 2. There is an undocumented API for Facebook which returns to whom >> the token was issued. This also audience restricts the token. >> >> The service that fixed took these measures. Note that none of the >> above is defined in OAuth. >> >> The same facility was called "id_token" and "check ID endpoint" for >> OpenID Connect. >> >> The scale of the impact is large, too large to disclose the actual >> names in the public list, though, eventually, we would publish them >> in a paper. >> >> Nat >> >> On Sat, Jun 16, 2012 at 5:34 AM, Francisco Corella >> > wrote: >> >> Hi Nat and Rui, >> >> Rui, you say that the vulnerability that you found was due to a >> "common misunderstanding among developers", but the attack you >> describe can be carried out against any app that uses the OAuth >> "implicit grant flow", which Facebook calls "client-side >> authentication". No misunderstanding seems necessary. What >> misunderstanding are you referring to? I followed the link in your >> message to the Sophos post, and from there the link to the article in >> The Register. The article in The Register says that Facebook had >> "fixed the vulnerability promptly". How did they fix it? The >> instructions that Facebook provides for implementing "Client-side >> authentication without the JS SDK" at >> https://developers.facebook.com/docs/authentication/client-side/#no-jssdk >> still allows the attack. >> >> Nat, I agree that the blog post by John Bradley that you link to >> refers to the same vulnerability reported by Rui. You say that some >> apps have issued a patch to fix it. Could you explain what the fix >> was? >> >> Francisco >> >> ------------------------------------------------------------------------ >> >> *From:*Nat Sakimura > >> *To:* rui wang > > >> *Cc:* matake nov >; Yuchen >> Zhou >; >> oauth >; Shuo Chen (MSR) >> > >> *Sent:* Thursday, June 14, 2012 1:50 PM >> *Subject:* Re: [OAUTH-WG] Report an authentication issue >> >> This is a fairly well known (hopefully by now) issue. We, at the >> OpenID Foundation, call it "access_token phishing" attack these >> days. See: >> http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.html >> >> Nov Matake has actually built the code on iPhone to verify the >> problem, and has notified bunch of parties back in February >> including Facebook and Apple. We have the code that actually runs >> on a phone, and we have successfully logged in to bunch of apps, >> including very well known ones. They were all informed of the >> issue. Some immediately issued a patch to fix it while others >> have not. >> >> The problem is that even if these apps gets fixed, the problem >> does not go away. As long as the attacker has the vulnerable >> version of the app, he still can impersonate the victim. To stop >> it, the server side has to completely disable the older version, >> which means the service has to cut off many users pausing >> business problems. >> >> Nat >> >> On Fri, Jun 15, 2012 at 2:18 AM, rui wang > > wrote: >> >> Dear Facebook Security Team and OAuth Standard group, >> >> We are a research team in Microsoft Research. In January, 2011, >> we reported a vulnerability in Facebook Connect which allowed >> everyone to sign into Facebook-secured relying parties without >> password. It was promptly fixed after reporting. >> (http://nakedsecurity.sophos.com/2011/02/02/facebook-flaw-websites-steal-personal-data/) >> >> Recently, we found a common misunderstanding among developers of >> mobile/metro apps when using OAuth (including Facebook's OAuth) >> for authentication. The vulnerability resulted from this >> misunderstanding also allows an attacker to log into a victim >> user's account without password. >> >> Let's take Soluto's metro app as an example to describe the >> problem. The app supports Facebook Login. As an attacker, we can >> write a regular Facebook app. Once the victim user allows our app >> to access her Facebook data, we receive an access_token from the >> traffic. Then, on our own machine (i.e., the "attacker" machine), >> we run the metro app of Soluto, and use a HTTP proxy to insert >> the victim's access_token into the traffic of Facebook login. >> Through this way, we are able to log into the victim's Soluto >> account from our machine. Other than Soluto, we also have >> confirmed the same issue on another Windows 8 metro-app Givit. >> >> The Facebook SDK for Android apps >> (https://developers.facebook.com/docs/mobile/android/build/#sdk) >> seems to have the possibility to mislead developers too. At >> least, the issue that we found is not clearly mentioned. In the >> SDK, we ran the sample code called "Hackbook" using Android >> Emulator (imagine it is an attacker device). Note that we have >> already received the access token of the victim user from our >> regular Facebook app. We then inject the token to the traffic of >> Hackbook. Through this way, Hackbook app on our own machine >> recognizes us as the victim. Note that this is not a convincing >> security exploit yet, because this sample code does not include >> the server-side code. However, given that we have seen real >> server-side code having this problem, such as Soluto, Givit and >> others, we do believe that the sample code can mislead >> mobile/metro developers. We also suspect that this may be a >> general issue of many OAuth implementations on mobile platforms, >> so we send this message to OAuth Standard group as well. >> >> We have contacted the vendors of the two vulnerable metro-apps, >> Soluto and Gavit. >> >> Please kindly give us an ack when you receive this message. If >> you want to know more details, please let us know. >> >> Best Regards, >> Yuchen Zhou, Rui Wang, and Shuo Chen >> >> >> _______________________________________________ >> 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 >> >> >> >> -- >> 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 > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------040204060605080606010304 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit But this use case  does need OAuth, period:

The video server is under the control of a police agency, and police officers must logon to the video server in order to access video content.

There is no delegation here, and there is no need to use third party for authentication. 

Igor

On 6/20/2012 3:26 PM, Justin Richer wrote:
In case it wasn't clear, I want to restate the original problem as best as I understand it in a way that hopefully clears it up:

App A and app B are both valid registered OAuth clients to an OAuth protected service.

The problem starts when app A gets handed a token that was issued for app B and uses it to call an identity API on the OAuth service. Since app B can get tokens just fine, they're bearer tokens, this is a fairly basic api call, this function works just fine and returns the user info. This makes sense, since anyone who holds A's tokens can do whatever A can do on behalf of that user. The issues start when app B then decides that since they can make a call to the identity API with a token then the user *must* be present. In other words, app B is confusing authorization to call an API with authentication of the session.

OpenID Connect fixes this missed assumption by binding the ID Token to the session and sending it along side the access token, but as you pointed out, it's meant for consumption at the client, not the resource server, in general. That doesn't mean you can't send it to a resource server for your own purposes, of course. That's actually how the session management endpoint works in Connect.

This isn't the only way to handle this problem -- if you put some structure in your tokens, such as with JWT or SAML, then app A can tell that this isn't a token issued to app A, but to app B, so it can call shenanigans and reject it then and there.

 -- Justin

On 06/20/2012 10:03 AM, Lewis Adam-CAL022 wrote:

I am entirely confused.

 

I understand what everybody is saying for confidential clients, no problem here.

 

I fall apart when thinking of iPhone apps.  Consider the scenario where I deploy a video server, and write an iPhone app to talk to the video server.  The video server is under the control of a police agency, and police officers must logon to the video server in order to access video content.  So the police office launches their iPhone video client app.

 

1)      If I wanted to solve authentication using “traditional” client-server authentication, the user enters their username / password into the client, and the client sends the username / password off to the server, which authenticates it, or possibly uses HTTP digest. 

2)      If I wanted to use OpenID, the client would attempt to reach the video server (RP), the server would redirect the client to the OP, OP authenticates user, and OP redirects client back to the server/RP with an assertion that primary authentication was successful. 

3)      If I wanted to use OAuth, the client would send an authorization request to the server’s AS, which would authenticate the user of the client, and ultimately result in the client possessing an access-token.  My thinking is that this access token (let’s assume it’s a JWT) would contain the user’s identity, a statement of what type of primary authentication was used (auth context), an expiration, and an audience claim.  This sounds a lot like authentication to me, and it’s where I get confused.  Is it just because OAuth does not explicitly define this?  Is there a threat in using OAuth as I describe? 

4)      If I wanted to use Connect, well I’m not even sure how the id_token as defined by Connect helps this use case.  The id_token seems to make sense when the client is a confidential web server, but it’s not clear what an iPhone app would do with the id_token … it’s the server in the backend that needs to authenticate the user, the iPhone app is just an interface to talk to the server.  And it seems as I learn more about connect that the id_token is not meant to be sent from the iPhone app to the server, just the access token.  So it’s really not clear how Connect helps solve authentication for an iPhone client app talking to a video server.  If I’m sending access-tokens, it’s just OAuth again.

 

What am I still missing?

adam

 

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Kristofor Selden
Sent: Saturday, June 16, 2012 11:33 AM
To: nov matake; oauth
Cc: Yuchen Zhou; Luke Melia; Shuo Chen (MSR)
Subject: Re: [OAUTH-WG] Report an authentication issue

 

Nov demonstrated the problem to us at Yapp and we used solution 4 (because the solution is server side and our app was in the app store).

 

FB Connect is authentication and authorization, where OAuth 2 is concerned only with authorization – I'm not sure that app developers appreciate this subtlety.

 

With OAuth 2 you authorize an app to use a protected resource.  With FB Connect, you do that, but also authenticate with the app you are authorizing.

 

So the access_token protects not just the FB resources but the auth end point of the authorized app (very common with apps that use the iOS SDK).  So now the app needs a way to verify that it was the app that was authorized to FB.

 

Solution 4 explanation: on FB you can register a iPhone app and a server app with the same client_id and get a client_secret for use on the server.  The server side API posts the access_token, client_id, and client_secret to https://graph.facebook.com/app to verify that the bearer token actually belongs to the app that is being authenticated before assuming they are authorized to the app's protected resources.

 

Kris

 

On Jun 15, 2012, at 8:22 PM, nov matake wrote:



There are 4 ways to fix this issue.

 

1. Use response_type=token%20code (It's not in OAuth 2.0 Core, but seems best way for interoperability)

2. Use singed_request (or some signed token like JWT)

3. Use grant_type=fb_exchange_token (Facebook custom way)

4. Access to https://graph.facebook.com/app?access_token=YOUR_TOKEN (Facebook custom way, moreover undocumented API)

 

Two iPhone app developers I reported this issue fixed it by using (4).

 

I also tried to use (1) for my own iPhone app implementation, but unfortunately it doesn't work when using authorization codes obtained via FB iOS SDK.

So I'm using (3) in my case.

 

nov

 

On 2012/06/16, at 9:16, Nat Sakimura wrote:



As to how the fix was done, Nov can provide more detail, but ... 

 

1. Properly verify the signature/HMAC of the "signed_request". This will essentially audience restricts the token. 

2. There is an undocumented API for Facebook which returns to whom the token was issued. This also audience restricts the token. 

 

The service that fixed took these measures. Note that none of the above is defined in OAuth. 

The same facility was called "id_token" and "check ID endpoint" for OpenID Connect. 

 

The scale of the impact is large, too large to disclose the actual names in the public list, though, eventually, we would publish them in a paper. 

 

Nat

On Sat, Jun 16, 2012 at 5:34 AM, Francisco Corella <fcorella@pomcor.com> wrote:

Hi Nat and Rui,

Rui, you say that the vulnerability that you found was due to a
"common misunderstanding among developers", but the attack you
describe can be carried out against any app that uses the OAuth
"implicit grant flow", which Facebook calls "client-side
authentication".  No misunderstanding seems necessary.  What
misunderstanding are you referring to?  I followed the link in your
message to the Sophos post, and from there the link to the article in
The Register.  The article in The Register says that Facebook had
"fixed the vulnerability promptly".  How did they fix it?  The
instructions that Facebook provides for implementing "Client-side
authentication without the JS SDK" at
https://developers.facebook.com/docs/authentication/client-side/#no-jssdk
still allows the attack.

Nat, I agree that the blog post by John Bradley that you link to
refers to the same vulnerability reported by Rui.  You say that some
apps have issued a patch to fix it.  Could you explain what the fix
was?

Francisco

 

From: Nat Sakimura <sakimura@gmail.com>
To: rui wang <ruiwangwarm@gmail.com>
Cc: matake nov <nov@matake.jp>; Yuchen Zhou <t-yuzhou@microsoft.com>; oauth <oauth@ietf.org>; Shuo Chen (MSR) <shuochen@microsoft.com>
Sent: Thursday, June 14, 2012 1:50 PM
Subject: Re: [OAUTH-WG] Report an authentication issue

 

This is a fairly well known (hopefully by now) issue. We, at the OpenID Foundation, call it "access_token phishing" attack these days. See: http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.html

 

Nov Matake has actually built the code on iPhone to verify the problem, and has notified bunch of parties back in February including Facebook and Apple. We have the code that actually runs on a phone, and we have successfully logged in to bunch of apps, including very well known ones. They were all informed of the issue. Some immediately issued a patch to fix it while others have not.  

 

The problem is that even if these apps gets fixed, the problem does not go away. As long as the attacker has the vulnerable version of the app, he still can impersonate the victim. To stop it, the server side has to completely disable the older version, which means the service has to cut off many users pausing business problems. 

 

Nat

On Fri, Jun 15, 2012 at 2:18 AM, rui wang <ruiwangwarm@gmail.com> wrote:

Dear Facebook Security Team and OAuth Standard group,

We are a research team in Microsoft Research. In January, 2011, we reported a vulnerability in Facebook Connect which allowed everyone to sign into Facebook-secured relying parties without password. It was promptly fixed after reporting. (http://nakedsecurity.sophos.com/2011/02/02/facebook-flaw-websites-steal-personal-data/)

Recently, we found a common misunderstanding among developers of mobile/metro apps when using OAuth (including Facebook’s OAuth) for authentication. The vulnerability resulted from this misunderstanding also allows an attacker to log into a victim user's account without password.

Let's take Soluto's metro app as an example to describe the problem. The app supports Facebook Login. As an attacker, we can write a regular Facebook app. Once the victim user allows our app to access her Facebook data, we receive an access_token from the traffic. Then, on our own machine (i.e., the "attacker" machine), we run the metro app of Soluto, and use a HTTP proxy to insert the victim's access_token into the traffic of Facebook login. Through this way, we are able to log into the victim's Soluto account from our machine. Other than Soluto, we also have confirmed the same issue on another Windows 8 metro-app Givit.

The Facebook SDK for Android apps (https://developers.facebook.com/docs/mobile/android/build/#sdk) seems to have the possibility to mislead developers too. At least, the issue that we found is not clearly mentioned. In the SDK, we ran the sample code called "Hackbook" using Android Emulator (imagine it is an attacker device). Note that we have already received the access token of the victim user from our regular Facebook app. We then inject the token to the traffic of Hackbook. Through this way, Hackbook app on our own machine recognizes us as the victim. Note that this is not a convincing security exploit yet, because this sample code does not include the server-side code. However, given that we have seen real server-side code having this problem, such as Soluto, Givit and others, we do believe that the sample code can mislead mobile/metro developers. We also suspect that this may be a general issue of many OAuth implementations on mobile platforms, so we send this message to OAuth Standard group as well.

We have contacted the vendors of the two vulnerable metro-apps, Soluto and Gavit.

Please kindly give us an ack when you receive this message. If you want to know more details, please let us know.

Best Regards,
Yuchen Zhou, Rui Wang, and Shuo Chen


_______________________________________________
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



 

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



_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--------------040204060605080606010304-- From jricher@mitre.org Wed Jun 20 13:00:12 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B998C21F864D for ; Wed, 20 Jun 2012 13:00:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.512 X-Spam-Level: X-Spam-Status: No, score=-6.512 tagged_above=-999 required=5 tests=[AWL=0.086, 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 0I7c2Tsjj03u for ; Wed, 20 Jun 2012 13:00:06 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 9296A21F8667 for ; Wed, 20 Jun 2012 13:00:05 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 1E3DF21B08E2; Wed, 20 Jun 2012 16:00:05 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id C465921B09BF; Wed, 20 Jun 2012 16:00:04 -0400 (EDT) Received: from [129.83.50.26] (129.83.31.51) by IMCCAS02.MITRE.ORG (129.83.29.79) with Microsoft SMTP Server (TLS) id 14.2.283.3; Wed, 20 Jun 2012 16:00:04 -0400 Message-ID: <4FE22BB1.1070304@mitre.org> Date: Wed, 20 Jun 2012 15:59:45 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: References: <1339792496.52712.YahooMailNeo@web125501.mail.ne1.yahoo.com> <59E470B10C4630419ED717AC79FCF9A9108898EE@BL2PRD0410MB363.namprd04.prod.outlook.com> <4FE223E4.6060307@mitre.org> <4FE226BC.6010403@alcatel-lucent.com> In-Reply-To: <4FE226BC.6010403@alcatel-lucent.com> Content-Type: multipart/alternative; boundary="------------000608050906000809020506" X-Originating-IP: [129.83.31.51] Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Report an authentication issue X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 20:00:13 -0000 --------------000608050906000809020506 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit That's a red herring -- the use case is that whatever the police officer is using needs to be authorized to access the video service, not that the police officer needs to "log in" necessarily. Adam has pointed out in another thread that the services that users use to log in are in a different security domain from the video servers, too -- so it's classic federated authorization, using a native client. -- Justin On 06/20/2012 03:38 PM, Igor Faynberg wrote: > But this use case does need OAuth, period: > > The video server is under the control of a police agency, and police > officers must logon to the video server in order to access video content. > > There is no delegation here, and there is no need to use third party > for authentication. > > Igor > > On 6/20/2012 3:26 PM, Justin Richer wrote: >> In case it wasn't clear, I want to restate the original problem as >> best as I understand it in a way that hopefully clears it up: >> >> App A and app B are both valid registered OAuth clients to an OAuth >> protected service. >> >> The problem starts when app A gets handed a token that was issued for >> app B and uses it to call an identity API on the OAuth service. Since >> app B can get tokens just fine, they're bearer tokens, this is a >> fairly basic api call, this function works just fine and returns the >> user info. This makes sense, since anyone who holds A's tokens can do >> whatever A can do on behalf of that user. The issues start when app B >> then decides that since they can make a call to the identity API with >> a token then the user *must* be present. In other words, app B is >> confusing authorization to call an API with authentication of the >> session. >> >> OpenID Connect fixes this missed assumption by binding the ID Token >> to the session and sending it along side the access token, but as you >> pointed out, it's meant for consumption at the client, not the >> resource server, in general. That doesn't mean you can't send it to a >> resource server for your own purposes, of course. That's actually how >> the session management endpoint works in Connect. >> >> This isn't the only way to handle this problem -- if you put some >> structure in your tokens, such as with JWT or SAML, then app A can >> tell that this isn't a token issued to app A, but to app B, so it can >> call shenanigans and reject it then and there. >> >> -- Justin >> >> On 06/20/2012 10:03 AM, Lewis Adam-CAL022 wrote: >>> >>> I am entirely confused. >>> >>> I understand what everybody is saying for confidential clients, no >>> problem here. >>> >>> I fall apart when thinking of iPhone apps. Consider the scenario >>> where I deploy a video server, and write an iPhone app to talk to >>> the video server. The video server is under the control of a police >>> agency, and police officers must logon to the video server in order >>> to access video content. So the police office launches their iPhone >>> video client app. >>> >>> 1)If I wanted to solve authentication using "traditional" >>> client-server authentication, the user enters their username / >>> password into the client, and the client sends the username / >>> password off to the server, which authenticates it, or possibly uses >>> HTTP digest. >>> >>> 2)If I wanted to use OpenID, the client would attempt to reach the >>> video server (RP), the server would redirect the client to the OP, >>> OP authenticates user, and OP redirects client back to the server/RP >>> with an assertion that primary authentication was successful. >>> >>> 3)If I wanted to use OAuth, the client would send an authorization >>> request to the server's AS, which would authenticate the user of the >>> client, and ultimately result in the client possessing an >>> access-token. My thinking is that this access token (let's assume >>> it's a JWT) would contain the user's identity, a statement of what >>> type of primary authentication was used (auth context), an >>> expiration, and an audience claim. This sounds a lot like >>> authentication to me, and it's where I get confused. Is it just >>> because OAuth does not explicitly define this? Is there a threat in >>> using OAuth as I describe? >>> >>> 4)If I wanted to use Connect, well I'm not even sure how the >>> id_token as defined by Connect helps this use case. The id_token >>> seems to make sense when the client is a confidential web server, >>> but it's not clear what an iPhone app would do with the id_token ... >>> it's the server in the backend that needs to authenticate the user, >>> the iPhone app is just an interface to talk to the server. And it >>> seems as I learn more about connect that the id_token is not meant >>> to be sent from the iPhone app to the server, just the access >>> token. So it's really not clear how Connect helps solve >>> authentication for an iPhone client app talking to a video server. >>> If I'm sending access-tokens, it's just OAuth again. >>> >>> What am I still missing? >>> >>> adam >>> >>> *From:*oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On >>> Behalf Of *Kristofor Selden >>> *Sent:* Saturday, June 16, 2012 11:33 AM >>> *To:* nov matake; oauth >>> *Cc:* Yuchen Zhou; Luke Melia; Shuo Chen (MSR) >>> *Subject:* Re: [OAUTH-WG] Report an authentication issue >>> >>> Nov demonstrated the problem to us at Yapp and we used solution 4 >>> (because the solution is server side and our app was in the app store). >>> >>> FB Connect is authentication /and/ authorization, where OAuth 2 is >>> concerned only with authorization -- I'm not sure that app >>> developers appreciate this subtlety. >>> >>> With OAuth 2 you authorize an app to use a protected resource. With >>> FB Connect, you do that, but /also/ authenticate with the app you >>> are authorizing. >>> >>> So the access_token protects not just the FB resources but the auth >>> end point of the authorized app (very common with apps that use the >>> iOS SDK). So now the app needs a way to verify that it was the app >>> that was authorized to FB. >>> >>> Solution 4 explanation: on FB you can register a iPhone app and a >>> server app with the same client_id and get a client_secret for use >>> on the server. The server side API posts the >>> access_token, client_id, and client_secret to >>> https://graph.facebook.com/app >>> to verify >>> that the bearer token actually belongs to the app that is being >>> authenticated before assuming they are authorized to the app's >>> protected resources. >>> >>> Kris >>> >>> On Jun 15, 2012, at 8:22 PM, nov matake wrote: >>> >>> >>> >>> There are 4 ways to fix this issue. >>> >>> 1. Use response_type=token%20code (It's not in OAuth 2.0 Core, but >>> seems best way for interoperability) >>> >>> 2. Use singed_request (or some signed token like JWT) >>> >>> 3. Use grant_type=fb_exchange_token (Facebook custom way) >>> >>> 4. Access to https://graph.facebook.com/app?access_token=YOUR_TOKEN >>> (Facebook custom way, moreover undocumented API) >>> >>> Two iPhone app developers I reported this issue fixed it by using (4). >>> >>> I also tried to use (1) for my own iPhone app implementation, but >>> unfortunately it doesn't work when using authorization codes >>> obtained via FB iOS SDK. >>> >>> So I'm using (3) in my case. >>> >>> nov >>> >>> On 2012/06/16, at 9:16, Nat Sakimura wrote: >>> >>> >>> >>> As to how the fix was done, Nov can provide more detail, but ... >>> >>> 1. Properly verify the signature/HMAC of the "signed_request". This >>> will essentially audience restricts the token. >>> >>> 2. There is an undocumented API for Facebook which returns to whom >>> the token was issued. This also audience restricts the token. >>> >>> The service that fixed took these measures. Note that none of the >>> above is defined in OAuth. >>> >>> The same facility was called "id_token" and "check ID endpoint" for >>> OpenID Connect. >>> >>> The scale of the impact is large, too large to disclose the actual >>> names in the public list, though, eventually, we would publish them >>> in a paper. >>> >>> Nat >>> >>> On Sat, Jun 16, 2012 at 5:34 AM, Francisco Corella >>> > wrote: >>> >>> Hi Nat and Rui, >>> >>> Rui, you say that the vulnerability that you found was due to a >>> "common misunderstanding among developers", but the attack you >>> describe can be carried out against any app that uses the OAuth >>> "implicit grant flow", which Facebook calls "client-side >>> authentication". No misunderstanding seems necessary. What >>> misunderstanding are you referring to? I followed the link in your >>> message to the Sophos post, and from there the link to the article in >>> The Register. The article in The Register says that Facebook had >>> "fixed the vulnerability promptly". How did they fix it? The >>> instructions that Facebook provides for implementing "Client-side >>> authentication without the JS SDK" at >>> https://developers.facebook.com/docs/authentication/client-side/#no-jssdk >>> still allows the attack. >>> >>> Nat, I agree that the blog post by John Bradley that you link to >>> refers to the same vulnerability reported by Rui. You say that some >>> apps have issued a patch to fix it. Could you explain what the fix >>> was? >>> >>> Francisco >>> >>> ------------------------------------------------------------------------ >>> >>> *From:*Nat Sakimura > >>> *To:* rui wang >> > >>> *Cc:* matake nov >; Yuchen >>> Zhou >; >>> oauth >; Shuo Chen (MSR) >>> > >>> *Sent:* Thursday, June 14, 2012 1:50 PM >>> *Subject:* Re: [OAUTH-WG] Report an authentication issue >>> >>> This is a fairly well known (hopefully by now) issue. We, at the >>> OpenID Foundation, call it "access_token phishing" attack these >>> days. See: >>> http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.html >>> >>> Nov Matake has actually built the code on iPhone to verify the >>> problem, and has notified bunch of parties back in February >>> including Facebook and Apple. We have the code that actually >>> runs on a phone, and we have successfully logged in to bunch of >>> apps, including very well known ones. They were all informed of >>> the issue. Some immediately issued a patch to fix it while >>> others have not. >>> >>> The problem is that even if these apps gets fixed, the problem >>> does not go away. As long as the attacker has the vulnerable >>> version of the app, he still can impersonate the victim. To stop >>> it, the server side has to completely disable the older version, >>> which means the service has to cut off many users pausing >>> business problems. >>> >>> Nat >>> >>> On Fri, Jun 15, 2012 at 2:18 AM, rui wang >> > wrote: >>> >>> Dear Facebook Security Team and OAuth Standard group, >>> >>> We are a research team in Microsoft Research. In January, 2011, >>> we reported a vulnerability in Facebook Connect which allowed >>> everyone to sign into Facebook-secured relying parties without >>> password. It was promptly fixed after reporting. >>> (http://nakedsecurity.sophos.com/2011/02/02/facebook-flaw-websites-steal-personal-data/) >>> >>> Recently, we found a common misunderstanding among developers of >>> mobile/metro apps when using OAuth (including Facebook's OAuth) >>> for authentication. The vulnerability resulted from this >>> misunderstanding also allows an attacker to log into a victim >>> user's account without password. >>> >>> Let's take Soluto's metro app as an example to describe the >>> problem. The app supports Facebook Login. As an attacker, we can >>> write a regular Facebook app. Once the victim user allows our >>> app to access her Facebook data, we receive an access_token from >>> the traffic. Then, on our own machine (i.e., the "attacker" >>> machine), we run the metro app of Soluto, and use a HTTP proxy >>> to insert the victim's access_token into the traffic of Facebook >>> login. Through this way, we are able to log into the victim's >>> Soluto account from our machine. Other than Soluto, we also have >>> confirmed the same issue on another Windows 8 metro-app Givit. >>> >>> The Facebook SDK for Android apps >>> (https://developers.facebook.com/docs/mobile/android/build/#sdk) >>> seems to have the possibility to mislead developers too. At >>> least, the issue that we found is not clearly mentioned. In the >>> SDK, we ran the sample code called "Hackbook" using Android >>> Emulator (imagine it is an attacker device). Note that we have >>> already received the access token of the victim user from our >>> regular Facebook app. We then inject the token to the traffic of >>> Hackbook. Through this way, Hackbook app on our own machine >>> recognizes us as the victim. Note that this is not a convincing >>> security exploit yet, because this sample code does not include >>> the server-side code. However, given that we have seen real >>> server-side code having this problem, such as Soluto, Givit and >>> others, we do believe that the sample code can mislead >>> mobile/metro developers. We also suspect that this may be a >>> general issue of many OAuth implementations on mobile platforms, >>> so we send this message to OAuth Standard group as well. >>> >>> We have contacted the vendors of the two vulnerable metro-apps, >>> Soluto and Gavit. >>> >>> Please kindly give us an ack when you receive this message. If >>> you want to know more details, please let us know. >>> >>> Best Regards, >>> Yuchen Zhou, Rui Wang, and Shuo Chen >>> >>> >>> _______________________________________________ >>> 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 >>> >>> >>> >>> -- >>> 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 >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------000608050906000809020506 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit That's a red herring -- the use case is that whatever the police officer is using needs to be authorized to access the video service, not that the police officer needs to "log in" necessarily. Adam has pointed out in another thread that the services that users use to log in are in a different security domain from the video servers, too -- so it's classic federated authorization, using a native client.

 -- Justin

On 06/20/2012 03:38 PM, Igor Faynberg wrote:
But this use case  does need OAuth, period:

The video server is under the control of a police agency, and police officers must logon to the video server in order to access video content.

There is no delegation here, and there is no need to use third party for authentication. 

Igor

On 6/20/2012 3:26 PM, Justin Richer wrote:
In case it wasn't clear, I want to restate the original problem as best as I understand it in a way that hopefully clears it up:

App A and app B are both valid registered OAuth clients to an OAuth protected service.

The problem starts when app A gets handed a token that was issued for app B and uses it to call an identity API on the OAuth service. Since app B can get tokens just fine, they're bearer tokens, this is a fairly basic api call, this function works just fine and returns the user info. This makes sense, since anyone who holds A's tokens can do whatever A can do on behalf of that user. The issues start when app B then decides that since they can make a call to the identity API with a token then the user *must* be present. In other words, app B is confusing authorization to call an API with authentication of the session.

OpenID Connect fixes this missed assumption by binding the ID Token to the session and sending it along side the access token, but as you pointed out, it's meant for consumption at the client, not the resource server, in general. That doesn't mean you can't send it to a resource server for your own purposes, of course. That's actually how the session management endpoint works in Connect.

This isn't the only way to handle this problem -- if you put some structure in your tokens, such as with JWT or SAML, then app A can tell that this isn't a token issued to app A, but to app B, so it can call shenanigans and reject it then and there.

 -- Justin

On 06/20/2012 10:03 AM, Lewis Adam-CAL022 wrote:

I am entirely confused.

 

I understand what everybody is saying for confidential clients, no problem here.

 

I fall apart when thinking of iPhone apps.  Consider the scenario where I deploy a video server, and write an iPhone app to talk to the video server.  The video server is under the control of a police agency, and police officers must logon to the video server in order to access video content.  So the police office launches their iPhone video client app.

 

1)      If I wanted to solve authentication using “traditional” client-server authentication, the user enters their username / password into the client, and the client sends the username / password off to the server, which authenticates it, or possibly uses HTTP digest. 

2)      If I wanted to use OpenID, the client would attempt to reach the video server (RP), the server would redirect the client to the OP, OP authenticates user, and OP redirects client back to the server/RP with an assertion that primary authentication was successful. 

3)      If I wanted to use OAuth, the client would send an authorization request to the server’s AS, which would authenticate the user of the client, and ultimately result in the client possessing an access-token.  My thinking is that this access token (let’s assume it’s a JWT) would contain the user’s identity, a statement of what type of primary authentication was used (auth context), an expiration, and an audience claim.  This sounds a lot like authentication to me, and it’s where I get confused.  Is it just because OAuth does not explicitly define this?  Is there a threat in using OAuth as I describe? 

4)      If I wanted to use Connect, well I’m not even sure how the id_token as defined by Connect helps this use case.  The id_token seems to make sense when the client is a confidential web server, but it’s not clear what an iPhone app would do with the id_token … it’s the server in the backend that needs to authenticate the user, the iPhone app is just an interface to talk to the server.  And it seems as I learn more about connect that the id_token is not meant to be sent from the iPhone app to the server, just the access token.  So it’s really not clear how Connect helps solve authentication for an iPhone client app talking to a video server.  If I’m sending access-tokens, it’s just OAuth again.

 

What am I still missing?

adam

 

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Kristofor Selden
Sent: Saturday, June 16, 2012 11:33 AM
To: nov matake; oauth
Cc: Yuchen Zhou; Luke Melia; Shuo Chen (MSR)
Subject: Re: [OAUTH-WG] Report an authentication issue

 

Nov demonstrated the problem to us at Yapp and we used solution 4 (because the solution is server side and our app was in the app store).

 

FB Connect is authentication and authorization, where OAuth 2 is concerned only with authorization – I'm not sure that app developers appreciate this subtlety.

 

With OAuth 2 you authorize an app to use a protected resource.  With FB Connect, you do that, but also authenticate with the app you are authorizing.

 

So the access_token protects not just the FB resources but the auth end point of the authorized app (very common with apps that use the iOS SDK).  So now the app needs a way to verify that it was the app that was authorized to FB.

 

Solution 4 explanation: on FB you can register a iPhone app and a server app with the same client_id and get a client_secret for use on the server.  The server side API posts the access_token, client_id, and client_secret to https://graph.facebook.com/app to verify that the bearer token actually belongs to the app that is being authenticated before assuming they are authorized to the app's protected resources.

 

Kris

 

On Jun 15, 2012, at 8:22 PM, nov matake wrote:



There are 4 ways to fix this issue.

 

1. Use response_type=token%20code (It's not in OAuth 2.0 Core, but seems best way for interoperability)

2. Use singed_request (or some signed token like JWT)

3. Use grant_type=fb_exchange_token (Facebook custom way)

4. Access to https://graph.facebook.com/app?access_token=YOUR_TOKEN (Facebook custom way, moreover undocumented API)

 

Two iPhone app developers I reported this issue fixed it by using (4).

 

I also tried to use (1) for my own iPhone app implementation, but unfortunately it doesn't work when using authorization codes obtained via FB iOS SDK.

So I'm using (3) in my case.

 

nov

 

On 2012/06/16, at 9:16, Nat Sakimura wrote:



As to how the fix was done, Nov can provide more detail, but ... 

 

1. Properly verify the signature/HMAC of the "signed_request". This will essentially audience restricts the token. 

2. There is an undocumented API for Facebook which returns to whom the token was issued. This also audience restricts the token. 

 

The service that fixed took these measures. Note that none of the above is defined in OAuth. 

The same facility was called "id_token" and "check ID endpoint" for OpenID Connect. 

 

The scale of the impact is large, too large to disclose the actual names in the public list, though, eventually, we would publish them in a paper. 

 

Nat

On Sat, Jun 16, 2012 at 5:34 AM, Francisco Corella <fcorella@pomcor.com> wrote:

Hi Nat and Rui,

Rui, you say that the vulnerability that you found was due to a
"common misunderstanding among developers", but the attack you
describe can be carried out against any app that uses the OAuth
"implicit grant flow", which Facebook calls "client-side
authentication".  No misunderstanding seems necessary.  What
misunderstanding are you referring to?  I followed the link in your
message to the Sophos post, and from there the link to the article in
The Register.  The article in The Register says that Facebook had
"fixed the vulnerability promptly".  How did they fix it?  The
instructions that Facebook provides for implementing "Client-side
authentication without the JS SDK" at
https://developers.facebook.com/docs/authentication/client-side/#no-jssdk
still allows the attack.

Nat, I agree that the blog post by John Bradley that you link to
refers to the same vulnerability reported by Rui.  You say that some
apps have issued a patch to fix it.  Could you explain what the fix
was?

Francisco

 

From: Nat Sakimura <sakimura@gmail.com>
To: rui wang <ruiwangwarm@gmail.com>
Cc: matake nov <nov@matake.jp>; Yuchen Zhou <t-yuzhou@microsoft.com>; oauth <oauth@ietf.org>; Shuo Chen (MSR) <shuochen@microsoft.com>
Sent: Thursday, June 14, 2012 1:50 PM
Subject: Re: [OAUTH-WG] Report an authentication issue

 

This is a fairly well known (hopefully by now) issue. We, at the OpenID Foundation, call it "access_token phishing" attack these days. See: http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.html

 

Nov Matake has actually built the code on iPhone to verify the problem, and has notified bunch of parties back in February including Facebook and Apple. We have the code that actually runs on a phone, and we have successfully logged in to bunch of apps, including very well known ones. They were all informed of the issue. Some immediately issued a patch to fix it while others have not.  

 

The problem is that even if these apps gets fixed, the problem does not go away. As long as the attacker has the vulnerable version of the app, he still can impersonate the victim. To stop it, the server side has to completely disable the older version, which means the service has to cut off many users pausing business problems. 

 

Nat

On Fri, Jun 15, 2012 at 2:18 AM, rui wang <ruiwangwarm@gmail.com> wrote:

Dear Facebook Security Team and OAuth Standard group,

We are a research team in Microsoft Research. In January, 2011, we reported a vulnerability in Facebook Connect which allowed everyone to sign into Facebook-secured relying parties without password. It was promptly fixed after reporting. (http://nakedsecurity.sophos.com/2011/02/02/facebook-flaw-websites-steal-personal-data/)

Recently, we found a common misunderstanding among developers of mobile/metro apps when using OAuth (including Facebook’s OAuth) for authentication. The vulnerability resulted from this misunderstanding also allows an attacker to log into a victim user's account without password.

Let's take Soluto's metro app as an example to describe the problem. The app supports Facebook Login. As an attacker, we can write a regular Facebook app. Once the victim user allows our app to access her Facebook data, we receive an access_token from the traffic. Then, on our own machine (i.e., the "attacker" machine), we run the metro app of Soluto, and use a HTTP proxy to insert the victim's access_token into the traffic of Facebook login. Through this way, we are able to log into the victim's Soluto account from our machine. Other than Soluto, we also have confirmed the same issue on another Windows 8 metro-app Givit.

The Facebook SDK for Android apps (https://developers.facebook.com/docs/mobile/android/build/#sdk) seems to have the possibility to mislead developers too. At least, the issue that we found is not clearly mentioned. In the SDK, we ran the sample code called "Hackbook" using Android Emulator (imagine it is an attacker device). Note that we have already received the access token of the victim user from our regular Facebook app. We then inject the token to the traffic of Hackbook. Through this way, Hackbook app on our own machine recognizes us as the victim. Note that this is not a convincing security exploit yet, because this sample code does not include the server-side code. However, given that we have seen real server-side code having this problem, such as Soluto, Givit and others, we do believe that the sample code can mislead mobile/metro developers. We also suspect that this may be a general issue of many OAuth implementations on mobile platforms, so we send this message to OAuth Standard group as well.

We have contacted the vendors of the two vulnerable metro-apps, Soluto and Gavit.

Please kindly give us an ack when you receive this message. If you want to know more details, please let us know.

Best Regards,
Yuchen Zhou, Rui Wang, and Shuo Chen


_______________________________________________
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



 

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



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



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

--------------000608050906000809020506-- From Adam.Lewis@motorolasolutions.com Wed Jun 20 13:21:35 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2878B11E808E for ; Wed, 20 Jun 2012 13:21:35 -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 gcKdSucWt0Jq for ; Wed, 20 Jun 2012 13:21:26 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe003.messaging.microsoft.com [216.32.180.13]) by ietfa.amsl.com (Postfix) with ESMTP id 1439E11E8083 for ; Wed, 20 Jun 2012 13:21:25 -0700 (PDT) Received: from mail11-va3-R.bigfish.com (10.7.14.242) by VA3EHSOBE003.bigfish.com (10.7.40.23) with Microsoft SMTP Server id 14.1.225.23; Wed, 20 Jun 2012 20:20:00 +0000 Received: from mail11-va3 (localhost [127.0.0.1]) by mail11-va3-R.bigfish.com (Postfix) with ESMTP id E84F72A007B for ; Wed, 20 Jun 2012 20:19:59 +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: -17 X-BigFish: VPS-17(zzbb2dI98dI9371Ic85fhb457nzz1202hzz1033IL8275bh8275dhz2fh2a8h683h839hd25hf0ah) Received-SPF: pass (mail11-va3: 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.240.85; KIP:(null); UIP:(null); (null); H:BL2PRD0410HT001.namprd04.prod.outlook.com; R:internal; EFV:INT Received: from mail11-va3 (localhost.localdomain [127.0.0.1]) by mail11-va3 (MessageSwitch) id 1340223595768001_25169; Wed, 20 Jun 2012 20:19:55 +0000 (UTC) Received: from VA3EHSMHS045.bigfish.com (unknown [10.7.14.236]) by mail11-va3.bigfish.com (Postfix) with ESMTP id B794AC0047 for ; Wed, 20 Jun 2012 20:19:55 +0000 (UTC) Received: from il06msg01.mot-solutions.com (129.188.136.17) by VA3EHSMHS045.bigfish.com (10.7.99.55) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 20 Jun 2012 20:19:52 +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 q5KL7CDm014251 for ; Wed, 20 Jun 2012 16:07:12 -0500 (CDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe003.messaging.microsoft.com [216.32.180.13]) by il06msg01.mot-solutions.com (8.14.3/8.14.3) with ESMTP id q5KL7C8g014248 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 20 Jun 2012 16:07:12 -0500 (CDT) Received: from mail170-va3-R.bigfish.com (10.7.14.239) by VA3EHSOBE008.bigfish.com (10.7.40.28) with Microsoft SMTP Server id 14.1.225.23; Wed, 20 Jun 2012 20:19:50 +0000 Received: from mail170-va3 (localhost [127.0.0.1]) by mail170-va3-R.bigfish.com (Postfix) with ESMTP id 98EF93E024B for ; Wed, 20 Jun 2012 20:19:50 +0000 (UTC) Received: from mail170-va3 (localhost.localdomain [127.0.0.1]) by mail170-va3 (MessageSwitch) id 1340223587354607_7993; Wed, 20 Jun 2012 20:19:47 +0000 (UTC) Received: from VA3EHSMHS032.bigfish.com (unknown [10.7.14.237]) by mail170-va3.bigfish.com (Postfix) with ESMTP id 496082A0049; Wed, 20 Jun 2012 20:19:47 +0000 (UTC) Received: from BL2PRD0410HT001.namprd04.prod.outlook.com (157.56.240.85) by VA3EHSMHS032.bigfish.com (10.7.99.42) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 20 Jun 2012 20:19:44 +0000 Received: from BL2PRD0410MB363.namprd04.prod.outlook.com ([169.254.3.137]) by BL2PRD0410HT001.namprd04.prod.outlook.com ([10.255.99.36]) with mapi id 14.16.0164.004; Wed, 20 Jun 2012 20:21:07 +0000 From: Lewis Adam-CAL022 To: "igor.faynberg@alcatel-lucent.com" , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Report an authentication issue Thread-Index: AQHNTxxduvk01SyG0Ui6TU3PR/zdbJcDoQkw Date: Wed, 20 Jun 2012 20:21:06 +0000 Message-ID: <59E470B10C4630419ED717AC79FCF9A910889AB5@BL2PRD0410MB363.namprd04.prod.outlook.com> References: <1339792496.52712.YahooMailNeo@web125501.mail.ne1.yahoo.com> <59E470B10C4630419ED717AC79FCF9A9108898EE@BL2PRD0410MB363.namprd04.prod.outlook.com> <4FE223E4.6060307@mitre.org> <4FE226BC.6010403@alcatel-lucent.com> In-Reply-To: <4FE226BC.6010403@alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [150.130.40.179] Content-Type: multipart/alternative; boundary="_000_59E470B10C4630419ED717AC79FCF9A910889AB5BL2PRD0410MB363_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%1294$Dn%ALCATEL-LUCENT.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] Report an authentication issue X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 20:21:35 -0000 --_000_59E470B10C4630419ED717AC79FCF9A910889AB5BL2PRD0410MB363_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Igor, As Justin just pointed out, consider the case where the video server is hos= ted by the state (e.g. California) and is accessed by police agencies in Lo= s Angeles, San Francisco, and San Diego. The State of California's video s= erver is the RS. Each local police agency (LA/SF/SD) hosts an AS. So when= a police officer from LAPD launches the video client app on the iPhone, th= e client makes an OAuth request to the LAPD's AS, which authenticates the p= olice officer using agency level credentials. The access token issued to t= he video client app on the iPhone is a JWT, signed by the agency AS, which = might look something like this: {"typ":"JWT","alg":"ES256"} {"iss":"https://as.lapd.california.gov", "prn":"alice@lapd.california.gov", "aud":" https://video_server1@state.california.gov", "iat":1300815780, "exp":1300819380, "acr":"password"} hq4zk+ZknjggCQgZm7ea8fI79gJEsRy3E8LHDpYXWQIgZpkJN9CMLG8ENR4Nrw+n7iyzixBvKXX= 8P53BTCT4VghPBWhFYSt9tHWu/AtJfOTh6qaAsNdeCyG86jmtp3TDMwuL/cBUj2OtBZOQMFn7jQ= 9YB7klIz3RqVL+wNmeWI4=3D The JWT might be optionally encrypted using JWE. I think what is becoming clear (and this is what I'm trying to vet) is that= while there is nothing in OAuth that specifies authentication, it *can* be= used for Authentication, if done in the way that I describe. If I'm wrong= about this, I really need to know. I've vetted this idea of mine with qui= te of few people now - both within context of the list and off-line - and I= think I'm okay. If you see any holes in what I describe, please point them= out as I would prefer to uncover them now rather than after implementation= or deployment! Essentially I'm using OAuth as a RESTful version of WS-Trust, where my clie= nt can exchange primary credentials for a token (JWT) and present that toke= n to a server as secondary authentication. It's just that it's RESTful ins= tead of SOAP :-) As Justin as pointed out ... I've basically made the access-token look like= the id_token of Connect. I was actually hoping to lay a path to Connect, = and use the id_token ... until it was also pointed out that the id_token is= really meant for the consumption of the client, not the RS :-( From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of I= gor Faynberg Sent: Wednesday, June 20, 2012 2:39 PM To: oauth@ietf.org Subject: Re: [OAUTH-WG] Report an authentication issue But this use case does need OAuth, period: The video server is under the control of a police agency, and police office= rs must logon to the video server in order to access video content. There is no delegation here, and there is no need to use third party for au= thentication. Igor On 6/20/2012 3:26 PM, Justin Richer wrote: In case it wasn't clear, I want to restate the original problem as best as = I understand it in a way that hopefully clears it up: App A and app B are both valid registered OAuth clients to an OAuth protect= ed service. The problem starts when app A gets handed a token that was issued for app B= and uses it to call an identity API on the OAuth service. Since app B can = get tokens just fine, they're bearer tokens, this is a fairly basic api cal= l, this function works just fine and returns the user info. This makes sens= e, since anyone who holds A's tokens can do whatever A can do on behalf of = that user. The issues start when app B then decides that since they can mak= e a call to the identity API with a token then the user *must* be present. = In other words, app B is confusing authorization to call an API with authen= tication of the session. OpenID Connect fixes this missed assumption by binding the ID Token to the = session and sending it along side the access token, but as you pointed out,= it's meant for consumption at the client, not the resource server, in gene= ral. That doesn't mean you can't send it to a resource server for your own = purposes, of course. That's actually how the session management endpoint wo= rks in Connect. This isn't the only way to handle this problem -- if you put some structure= in your tokens, such as with JWT or SAML, then app A can tell that this is= n't a token issued to app A, but to app B, so it can call shenanigans and r= eject it then and there. -- Justin On 06/20/2012 10:03 AM, Lewis Adam-CAL022 wrote: I am entirely confused. I understand what everybody is saying for confidential clients, no problem = here. I fall apart when thinking of iPhone apps. Consider the scenario where I d= eploy a video server, and write an iPhone app to talk to the video server. = The video server is under the control of a police agency, and police offic= ers must logon to the video server in order to access video content. So th= e police office launches their iPhone video client app. If I wanted to solve authentication using "traditional" client-server authe= ntication, the user enters their username / password into the client, and t= he client sends the username / password off to the server, which authentica= tes it, or possibly uses HTTP digest. If I wanted to use OpenID, the client would attempt to reach the video serv= er (RP), the server would redirect the client to the OP, OP authenticates u= ser, and OP redirects client back to the server/RP with an assertion that p= rimary authentication was successful. If I wanted to use OAuth, the client would send an authorization request to= the server's AS, which would authenticate the user of the client, and ulti= mately result in the client possessing an access-token. My thinking is tha= t this access token (let's assume it's a JWT) would contain the user's iden= tity, a statement of what type of primary authentication was used (auth con= text), an expiration, and an audience claim. This sounds a lot like authen= tication to me, and it's where I get confused. Is it just because OAuth do= es not explicitly define this? Is there a threat in using OAuth as I descr= ibe? If I wanted to use Connect, well I'm not even sure how the id_token as defi= ned by Connect helps this use case. The id_token seems to make sense when = the client is a confidential web server, but it's not clear what an iPhone = app would do with the id_token ... it's the server in the backend that need= s to authenticate the user, the iPhone app is just an interface to talk to = the server. And it seems as I learn more about connect that the id_token i= s not meant to be sent from the iPhone app to the server, just the access t= oken. So it's really not clear how Connect helps solve authentication for = an iPhone client app talking to a video server. If I'm sending access-toke= ns, it's just OAuth again. What am I still missing? adam From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Kristofor Selden Sent: Saturday, June 16, 2012 11:33 AM To: nov matake; oauth Cc: Yuchen Zhou; Luke Melia; Shuo Chen (MSR) Subject: Re: [OAUTH-WG] Report an authentication issue Nov demonstrated the problem to us at Yapp and we used solution 4 (because = the solution is server side and our app was in the app store). FB Connect is authentication and authorization, where OAuth 2 is concerned = only with authorization - I'm not sure that app developers appreciate this = subtlety. With OAuth 2 you authorize an app to use a protected resource. With FB Con= nect, you do that, but also authenticate with the app you are authorizing. So the access_token protects not just the FB resources but the auth end poi= nt of the authorized app (very common with apps that use the iOS SDK). So = now the app needs a way to verify that it was the app that was authorized t= o FB. Solution 4 explanation: on FB you can register a iPhone app and a server ap= p with the same client_id and get a client_secret for use on the server. T= he server side API posts the access_token, client_id, and client_secret to = https://graph.facebook.com/app to verify that the bearer token actually belongs to the app = that is being authenticated before assuming they are authorized to the app'= s protected resources. Kris On Jun 15, 2012, at 8:22 PM, nov matake wrote: There are 4 ways to fix this issue. 1. Use response_type=3Dtoken%20code (It's not in OAuth 2.0 Core, but seems = best way for interoperability) 2. Use singed_request (or some signed token like JWT) 3. Use grant_type=3Dfb_exchange_token (Facebook custom way) 4. Access to https://graph.facebook.com/app?access_token=3DYOUR_TOKEN (Face= book custom way, moreover undocumented API) Two iPhone app developers I reported this issue fixed it by using (4). I also tried to use (1) for my own iPhone app implementation, but unfortuna= tely it doesn't work when using authorization codes obtained via FB iOS SDK= . So I'm using (3) in my case. nov On 2012/06/16, at 9:16, Nat Sakimura wrote: As to how the fix was done, Nov can provide more detail, but ... 1. Properly verify the signature/HMAC of the "signed_request". This will es= sentially audience restricts the token. 2. There is an undocumented API for Facebook which returns to whom the toke= n was issued. This also audience restricts the token. The service that fixed took these measures. Note that none of the above is = defined in OAuth. The same facility was called "id_token" and "check ID endpoint" for OpenID = Connect. The scale of the impact is large, too large to disclose the actual names in= the public list, though, eventually, we would publish them in a paper. Nat On Sat, Jun 16, 2012 at 5:34 AM, Francisco Corella > wrote: Hi Nat and Rui, Rui, you say that the vulnerability that you found was due to a "common misunderstanding among developers", but the attack you describe can be carried out against any app that uses the OAuth "implicit grant flow", which Facebook calls "client-side authentication". No misunderstanding seems necessary. What misunderstanding are you referring to? I followed the link in your message to the Sophos post, and from there the link to the article in The Register. The article in The Register says that Facebook had "fixed the vulnerability promptly". How did they fix it? The instructions that Facebook provides for implementing "Client-side authentication without the JS SDK" at https://developers.facebook.com/docs/authentication/client-side/#no-jssdk still allows the attack. Nat, I agree that the blog post by John Bradley that you link to refers to the same vulnerability reported by Rui. You say that some apps have issued a patch to fix it. Could you explain what the fix was? Francisco ________________________________ From: Nat Sakimura > To: rui wang > Cc: matake nov >; Yuchen Zhou >; oauth >; Shuo Chen (MSR) > Sent: Thursday, June 14, 2012 1:50 PM Subject: Re: [OAUTH-WG] Report an authentication issue This is a fairly well known (hopefully by now) issue. We, at the OpenID Fou= ndation, call it "access_token phishing" attack these days. See: http://www= .thread-safe.com/2012/01/problem-with-oauth-for-authentication.html Nov Matake has actually built the code on iPhone to verify the problem, and= has notified bunch of parties back in February including Facebook and Appl= e. We have the code that actually runs on a phone, and we have successfully= logged in to bunch of apps, including very well known ones. They were all = informed of the issue. Some immediately issued a patch to fix it while othe= rs have not. The problem is that even if these apps gets fixed, the problem does not go = away. As long as the attacker has the vulnerable version of the app, he sti= ll can impersonate the victim. To stop it, the server side has to completel= y disable the older version, which means the service has to cut off many us= ers pausing business problems. Nat On Fri, Jun 15, 2012 at 2:18 AM, rui wang > wrote: Dear Facebook Security Team and OAuth Standard group, We are a research team in Microsoft Research. In January, 2011, we reported= a vulnerability in Facebook Connect which allowed everyone to sign into Fa= cebook-secured relying parties without password. It was promptly fixed afte= r reporting. (http://nakedsecurity.sophos.com/2011/02/02/facebook-flaw-webs= ites-steal-personal-data/) Recently, we found a common misunderstanding among developers of mobile/met= ro apps when using OAuth (including Facebook's OAuth) for authentication. T= he vulnerability resulted from this misunderstanding also allows an attacke= r to log into a victim user's account without password. Let's take Soluto's metro app as an example to describe the problem. The ap= p supports Facebook Login. As an attacker, we can write a regular Facebook = app. Once the victim user allows our app to access her Facebook data, we re= ceive an access_token from the traffic. Then, on our own machine (i.e., the= "attacker" machine), we run the metro app of Soluto, and use a HTTP proxy = to insert the victim's access_token into the traffic of Facebook login. Thr= ough this way, we are able to log into the victim's Soluto account from our= machine. Other than Soluto, we also have confirmed the same issue on anoth= er Windows 8 metro-app Givit. The Facebook SDK for Android apps (https://developers.facebook.com/docs/mob= ile/android/build/#sdk) seems to have the possibility to mislead developers= too. At least, the issue that we found is not clearly mentioned. In the SD= K, we ran the sample code called "Hackbook" using Android Emulator (imagine= it is an attacker device). Note that we have already received the access t= oken of the victim user from our regular Facebook app. We then inject the t= oken to the traffic of Hackbook. Through this way, Hackbook app on our own = machine recognizes us as the victim. Note that this is not a convincing sec= urity exploit yet, because this sample code does not include the server-sid= e code. However, given that we have seen real server-side code having this = problem, such as Soluto, Givit and others, we do believe that the sample co= de can mislead mobile/metro developers. We also suspect that this may be a = general issue of many OAuth implementations on mobile platforms, so we send= this message to OAuth Standard group as well. We have contacted the vendors of the two vulnerable metro-apps, Soluto and = Gavit. Please kindly give us an ack when you receive this message. If you want to = know more details, please let us know. Best Regards, Yuchen Zhou, Rui Wang, and Shuo Chen _______________________________________________ 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 -- 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 _______________________________________________ OAuth mailing 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_59E470B10C4630419ED717AC79FCF9A910889AB5BL2PRD0410MB363_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Igor,

 

As Justin just pointed out, consider the cas= e where the video server is hosted by the state (e.g. California) and is ac= cessed by police agencies in Los Angeles, San Francisco, and San Diego.  The State of California’s video server is the R= S.  Each local police agency (LA/SF/SD) hosts an AS.  So when a p= olice officer from LAPD launches the video client app on the iPhone, the cl= ient makes an OAuth request to the LAPD’s AS, which authenticates the police officer using agency level credentials.  The access token = issued to the video client app on the iPhone is a JWT, signed by the agency= AS, which might look something like this:

 

{“typ”:”JWT”,"a= lg":"ES256"}

{"iss":"https://as.lapd.california.gov",
  "prn":"alice@lapd.california.gov",
  "aud":" https://video_server1@state.california.gov",
  "iat":1300815780,
  "exp":1300819380,
  "acr":”password”}

hq4zk+Zknj= ggCQgZm7ea8fI79gJEsRy3E8LHDpYXWQIgZpkJN9CMLG8ENR4Nrw+n7iyzixBvKXX8P53BT= CT4VghPBWhFYSt9tHWu/AtJfOTh6qaAsNdeCyG86jmtp3TDMwuL/cBUj2OtBZOQMFn7jQ9YB7kl= Iz3RqVL+wNmeWI4=3D

 

The JWT might = be optionally encrypted using JWE. 

 

I think what i= s becoming clear (and this is what I’m trying to vet) is that while t= here is nothing in OAuth that specifies authentication, it *can* be used for Authentication, if done in the way that I describe.  If I= ’m wrong about this, I really need to know.  I’ve vetted t= his idea of mine with quite of few people now – both within context o= f the list and off-line – and I think I’m okay. If you see any holes in what I describe, please point them out as I would prefer to uncov= er them now rather than after implementation or deployment!

 

Essentially I&= #8217;m using OAuth as a RESTful version of WS-Trust, where my client can e= xchange primary credentials for a token (JWT) and present that token to a server as secondary authentication.  It’s just that itR= 17;s RESTful instead of SOAP :-)

 

As Justin as p= ointed out … I’ve basically made the access-token look like the= id_token of Connect.  I was actually hoping to lay a path to Connect, and use the id_token … until it was also pointed out that the id_tok= en is really meant for the consumption of the client, not the RS :-(

 

 

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf= .org] On Behalf Of Igor Faynberg
Sent: Wednesday, June 20, 2012 2:39 PM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] Report an authentication issue

 

But this use case  does need OAuth, period:

The video server is under the control of a police agency, and polic= e officers must logon to the video server in order to access video content.=

There is no delegation here, and there is no need to use third party for au= thentication. 

Igor

On 6/20/2012 3:26 PM, Justin Richer wrote:

In case it wasn't clear, I want to restate the origi= nal problem as best as I understand it in a way that hopefully clears it up= :

App A and app B are both valid registered OAuth clients to an OAuth protect= ed service.

The problem starts when app A gets handed a token that was issued for app B= and uses it to call an identity API on the OAuth service. Since app B can = get tokens just fine, they're bearer tokens, this is a fairly basic api cal= l, this function works just fine and returns the user info. This makes sense, since anyone who holds A's to= kens can do whatever A can do on behalf of that user. The issues start when= app B then decides that since they can make a call to the identity API wit= h a token then the user *must* be present. In other words, app B is confusing authorization to call an API w= ith authentication of the session.

OpenID Connect fixes this missed assumption by binding the ID Token to the = session and sending it along side the access token, but as you pointed out,= it's meant for consumption at the client, not the resource server, in gene= ral. That doesn't mean you can't send it to a resource server for your own purposes, of course. That's actu= ally how the session management endpoint works in Connect.

This isn't the only way to handle this problem -- if you put some structure= in your tokens, such as with JWT or SAML, then app A can tell that this is= n't a token issued to app A, but to app B, so it can call shenanigans and r= eject it then and there.

 -- Justin

On 06/20/2012 10:03 AM, Lewis Adam-CAL022 wrote:

I am entirely confused.

 

I understand what everybody is saying for co= nfidential clients, no problem here.

 

I fall apart when thinking of iPhone apps.&n= bsp; Consider the scenario where I deploy a video server, and write an iPho= ne app to talk to the video server.  The video server is under the control of a police agency, and police officers must logon to the vide= o server in order to access video content.  So the police office launc= hes their iPhone video client app.

 

If I wan= ted to solve authentication using “traditional” client-server a= uthentication, the user enters their username / password into the client, and the client sends the username / password off to the server, which auth= enticates it, or possibly uses HTTP digest. 


If I wan= ted to use OpenID, the client would attempt to reach the video server (RP),= the server would redirect the client to the OP, OP authenticates user, and OP redirects client back to the server/RP with an assertion that= primary authentication was successful. 


If I wan= ted to use OAuth, the client would send an authorization request to the ser= ver’s AS, which would authenticate the user of the client, and ultimately result in the client possessing an access-token.  My t= hinking is that this access token (let’s assume it’s a JWT) wou= ld contain the user’s identity, a statement of what type of primary a= uthentication was used (auth context), an expiration, and an audience claim.  This sounds a lot like authentication to me, and = it’s where I get confused.  Is it just because OAuth does not ex= plicitly define this?  Is there a threat in using OAuth as I describe?=  


If I wan= ted to use Connect, well I’m not even sure how the id_token as define= d by Connect helps this use case.  The id_token seems to make sense when the client is a confidential web server, but it’s not clear wha= t an iPhone app would do with the id_token … it’s the server in= the backend that needs to authenticate the user, the iPhone app is just an= interface to talk to the server.  And it seems as I learn more about connect that the id_token is not meant to be sent from = the iPhone app to the server, just the access token.  So it’s re= ally not clear how Connect helps solve authentication for an iPhone client = app talking to a video server.  If I’m sending access-tokens, it’s just OAuth again.

 

What am I still missing?

adam

 

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Kristofor Selden
Sent: Saturday, June 16, 2012 11:33 AM
To: nov matake; oauth
Cc: Yuchen Zhou; Luke Melia; Shuo Chen (MSR)
Subject: Re: [OAUTH-WG] Report an authentication issue

 

Nov demonstrated the problem to us at Yapp and we us= ed solution 4 (because the solution is server side and our app was in the a= pp store).

 

FB Connect is authentication and authorizatio= n, where OAuth 2 is concerned only with authorization – I'm not sure = that app developers appreciate this subtlety.

 

With OAuth 2 you authorize an app to use a protected= resource.  With FB Connect, you do that, but also authenticate with the app you are authorizing.

 

So the access_token protects not just the FB resourc= es but the auth end point of the authorized app (very common with apps that= use the iOS SDK).  So now the app needs a way to verify that it was t= he app that was authorized to FB.

 

Solution 4 explanation: on FB you can register a iPh= one app and a server app with the same client_id and get a client_secret fo= r use on the server.  The server side API posts the access_token, = ;client_id, and client_secret to https://graph.facebook.com/app&nbs= p;to verify that the bearer token actually belongs to the app that is being authentica= ted before assuming they are authorized to the app's protected resources.

 

Kris

 

On Jun 15, 2012, at 8:22 PM, nov matake wrote:<= /o:p>




There are 4 ways to fix this issue.

 

1. Use response_type=3Dtoken%20code (It's not i= n OAuth 2.0 Core, but seems best way for interoperability)

2. Use singed_request (or some signed token like JWT= )

3. Use grant_type=3Dfb_exchange_token (Facebook cust= om way)

4. Access to https://graph.facebook.com/app?access_token=3DYOUR_TOKEN (Facebook cust= om way, moreover undocumented API)

 

Two iPhone app developers I reported this issue fixe= d it by using (4).

 

I also tried to use (1) for my own iPhone app implem= entation, but unfortunately it doesn't work when using authorization codes = obtained via FB iOS SDK.

So I'm using (3) in my case.

 

nov

 

On 2012/06/16, at 9:16, Nat Sakimura wrote:




As to how the fix was done, Nov can provide more det= ail, but ... 

 

1. Properly verify the signature/HMAC of the "s= igned_request". This will essentially audience restricts the token.&nb= sp;

2. There is an undocumented API for Facebook which r= eturns to whom the token was issued. This also audience restricts the token= . 

 

The service that fixed took these measures. Note tha= t none of the above is defined in OAuth. 

The same facility was called "id_token" an= d "check ID endpoint" for OpenID Connect. 

 

The scale of the impact is large, too large to discl= ose the actual names in the public list, though, eventually, we would publi= sh them in a paper. 

 

Nat

On Sat, Jun 16, 2012 at 5:34 AM, Francisco Corella &= lt;fcorella@pomcor= .com> wrote:


Hi Nat and Rui,

Rui, you say that the vulnerability that you found was due to a
"common misunderstanding among developers", but the attack you describe can be carried out against any app that uses the OAuth
"implicit grant flow", which Facebook calls "client-side
authentication".  No misunderstanding seems necessary.  What=
misunderstanding are you referring to?  I followed the link in your message to the Sophos post, and from there the link to the article in
The Register.  The article in The Register says that Facebook had
"fixed the vulnerability promptly".  How did they fix it?&nb= sp; The
instructions that Facebook provides for implementing "Client-side
authentication without the JS SDK" at
https://developers.facebook.com/docs/authentic= ation/client-side/#no-jssdk
still allows the attack.

Nat, I agree that the blog post by John Bradley that you link to
refers to the same vulnerability reported by Rui.  You say that some apps have issued a patch to fix it.  Could you explain what the fix was?

Francisco

 

From: Nat Sakimura <sakimura@gmail.com>
To: rui wang <ruiwangwarm@gmail.com>
Cc: matake nov <nov@matake.jp>; Yuchen Zhou <t-yuzhou@microsoft.com>; oauth <oauth@ietf.org>; Shuo Chen (MSR) <shuochen@microsoft.com>
Sent: Thursday, June 14, 2012 1:50 PM
Subject: Re: [OAUTH-WG] Report an authentication issue

 

This is a fairly well known (hopefully by now) issue= . We, at the OpenID Foundation, call it "access_token phishing" a= ttack these days. See: http://www.thr= ead-safe.com/2012/01/problem-with-oauth-for-authentication.html

 

Nov Matake has actually built the code on iPhone to = verify the problem, and has notified bunch of parties back in February incl= uding Facebook and Apple. We have the code that actually runs on a phone, a= nd we have successfully logged in to bunch of apps, including very well known ones. They were all informed o= f the issue. Some immediately issued a patch to fix it while others have no= t.  

 

The problem is that even if these apps gets fixed, t= he problem does not go away. As long as the attacker has the vulnerable ver= sion of the app, he still can impersonate the victim. To stop it, the serve= r side has to completely disable the older version, which means the service has to cut off many users pausing b= usiness problems. 

 

Nat

On Fri, Jun 15, 2012 at 2:18 AM, rui wang <ruiwangwarm@gmail.com<= /a>> wrote:

Dear Facebook Security Team and OAuth Standard group= ,

Recently, we found a common misunderstanding among d= evelopers of mobile/metro apps when using OAuth (including Facebook’s= OAuth) for authentication. The vulnerability resulted from this misunderst= anding also allows an attacker to log into a victim user's account without password.

Let's take Soluto's metro app as an example to descr= ibe the problem. The app supports Facebook Login. As an attacker, we can wr= ite a regular Facebook app. Once the victim user allows our app to access h= er Facebook data, we receive an access_token from the traffic. Then, on our own machine (i.e., the "attacker"= machine), we run the metro app of Soluto, and use a HTTP proxy to insert t= he victim's access_token into the traffic of Facebook login. Through this w= ay, we are able to log into the victim's Soluto account from our machine. Other than Soluto, we also have confirmed the sa= me issue on another Windows 8 metro-app Givit.

The Facebook SDK for Android apps (https://developers.facebook.com/docs/mobile/android/build/#sdk) seems = to have the possibility to mislead developers too. At least, the issue that we found is not clearly mentioned. In the SD= K, we ran the sample code called "Hackbook" using Android Emulato= r (imagine it is an attacker device). Note that we have already received th= e access token of the victim user from our regular Facebook app. We then inject the token to the traffic of Hackbook.= Through this way, Hackbook app on our own machine recognizes us as the vic= tim. Note that this is not a convincing security exploit yet, because this = sample code does not include the server-side code. However, given that we have seen real server-side code h= aving this problem, such as Soluto, Givit and others, we do believe that th= e sample code can mislead mobile/metro developers. We also suspect that thi= s may be a general issue of many OAuth implementations on mobile platforms, so we send this message to OAut= h Standard group as well.

We have contacted the vendors of the two vulnerable = metro-apps, Soluto and Gavit.

Please kindly give us an ack when you receive this m= essage. If you want to know more details, please let us know.

Best Regards,
Yuchen Zhou, Rui Wang, and Shuo Chen


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

 




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



 
 
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ie=
tf.org/mailman/listinfo/oauth
--_000_59E470B10C4630419ED717AC79FCF9A910889AB5BL2PRD0410MB363_-- From bcampbell@pingidentity.com Wed Jun 20 13:36:49 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D53B821F85AE for ; Wed, 20 Jun 2012 13:36:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.827 X-Spam-Level: X-Spam-Status: No, score=-5.827 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oMIdn78Xncai for ; Wed, 20 Jun 2012 13:36:49 -0700 (PDT) Received: from na3sys009aog126.obsmtp.com (na3sys009aog126.obsmtp.com [74.125.149.155]) by ietfa.amsl.com (Postfix) with ESMTP id CE8E921F85A4 for ; Wed, 20 Jun 2012 13:36:48 -0700 (PDT) Received: from mail-qc0-f172.google.com ([209.85.216.172]) (using TLSv1) by na3sys009aob126.postini.com ([74.125.148.12]) with SMTP ID DSNKT+I0X4EwMe4PlgnS/11be2p55UYCMbT2@postini.com; Wed, 20 Jun 2012 13:36:48 PDT Received: by qcsq13 with SMTP id q13so5371724qcs.3 for ; Wed, 20 Jun 2012 13:36:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=1zqcV0Uw3fwwhNfyay3KHu2xtmGC+hUkjk3vMyn+SHU=; b=bhMg3KT7T+acBWZ0SIKQak+T29G/MqG5++nt2/ARE6WwsE5FzglPbhmCxokRtMevej Y4vgxnMgfOXRRtL+9HDUkgSPUeNJDGsJZymAvT76zilDhMbeZo/Elq38lunkN8ESqMHk mwiL/2ZrjzNa3iD25h9GrpCLXHyrxBav+XtqHJYBb+qqEEyCIllaNaDdo3uZXausUDuW Q5j0nGda6NaWK8STG3AlBhL1MYsfmgdC0wLdk4GnFUWyRR3Oj9bKMab0bJMIVRISTilf L63jHyXzGZlz3uyjDCLlz+sZGigPOWfkpc1zTqwtRglTNIda4AH2T7yBgC9fBXreDVr9 4vgg== Received: by 10.229.135.141 with SMTP id n13mr5615863qct.105.1340224606481; Wed, 20 Jun 2012 13:36:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.87.142 with HTTP; Wed, 20 Jun 2012 13:36:16 -0700 (PDT) In-Reply-To: References: <4FE1C16D.6010602@cs.tcd.ie> <4FE1FD1E.1060601@cs.tcd.ie> From: Brian Campbell Date: Wed, 20 Jun 2012 14:36:16 -0600 Message-ID: To: Barry Leiba Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQk1UeivFNx3x+KZKzi/jntj3spFEQ0PODNKsN9bQ+9ypvvEua/4WUaLkcDf9wVgo+btwDs9 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-urn-sub-ns-02 X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 20:36:50 -0000 After looking at the text again, I think you're right Barry. It's a bit confusing as the establishment of the sub-namespace and the registry for it go somewhat hand in hand. But I agree that it's not well baked and I'm in the process of reworking it to try and address your concerns as well as the things Stephen, Mike and Peter have brought up. The new version will be substantially different (in its from and text but not its intent) from -02 and I would really appreciate another review when I get that published (hopefully soon). Thanks, Brian On Wed, Jun 20, 2012 at 12:34 PM, Barry Leiba wro= te: > I'd like to see the new version, since there appear to be a bunch of > changes, but first here are some issues that I don't think have been > brought up yet: > > The URN registration stuff seems very incompletely baked. =A0The title > of 5.1 correctly says it's registering a sub-namespace, but the text > incorrectly says that it's creating a registry. =A0Perhaps IANA will > understand, but I think you need to do this in two parts. =A0The first > part would register the "oauth" sub-namespace, and the second would > create a new registry for the things that go into it. > > Now, as to what goes into it: What is "class"? =A0Is there meant to be a > registry of classes? =A0Is that what section 5.1 is trying to create > (which should be done in a new section 5.2)? =A0What initial values are > registered there? > > Barry From igor.faynberg@alcatel-lucent.com Wed Jun 20 13:50:22 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5856E11E8093 for ; Wed, 20 Jun 2012 13:50:22 -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=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S1l5h+EgZmtZ for ; Wed, 20 Jun 2012 13:50:16 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 89DC711E8096 for ; Wed, 20 Jun 2012 13:50:11 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q5KKoAGi011857 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 20 Jun 2012 15:50:10 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q5KKo9Fl022803 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 20 Jun 2012 15:50:10 -0500 Received: from [135.244.39.63] (faynberg.lra.lucent.com [135.244.39.63]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q5KKo8cU011210; Wed, 20 Jun 2012 15:50:08 -0500 (CDT) Message-ID: <4FE2377F.6040902@alcatel-lucent.com> Date: Wed, 20 Jun 2012 16:50:07 -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: Lewis Adam-CAL022 References: <1339792496.52712.YahooMailNeo@web125501.mail.ne1.yahoo.com> <59E470B10C4630419ED717AC79FCF9A9108898EE@BL2PRD0410MB363.namprd04.prod.outlook.com> <4FE223E4.6060307@mitre.org> <4FE226BC.6010403@alcatel-lucent.com> <59E470B10C4630419ED717AC79FCF9A910889AB5@BL2PRD0410MB363.namprd04.prod.outlook.com> In-Reply-To: <59E470B10C4630419ED717AC79FCF9A910889AB5@BL2PRD0410MB363.namprd04.prod.outlook.com> Content-Type: multipart/alternative; boundary="------------010605090004000207060701" X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Report an authentication issue X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2012 20:50:22 -0000 This is a multi-part message in MIME format. --------------010605090004000207060701 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Adam, Now I think I understand the use case. I agree with you that if the token is made specifically out to authenticate the user, it is an entirely different matter. (In the early OAuth days, I was suggesting to consider structuring a token simliarly to a Kerberos ticket, which is more or less what would serve the use case you propose.) Igor On 6/20/2012 4:21 PM, Lewis Adam-CAL022 wrote: > > Hi Igor, > > As Justin just pointed out, consider the case where the video server > is hosted by the state (e.g. California) and is accessed by police > agencies in Los Angeles, San Francisco, and San Diego. The State of > California's video server is the RS. Each local police agency > (LA/SF/SD) hosts an AS. So when a police officer from LAPD launches > the video client app on the iPhone, the client makes an OAuth request > to the LAPD's AS, which authenticates the police officer using agency > level credentials. The access token issued to the video client app on > the iPhone is a JWT, signed by the agency AS, which might look > something like this: > > {"typ":"JWT","alg":"ES256"} > > {"iss":"https://as.lapd.california.gov", > "prn":"alice@lapd.california.gov", > "aud":" https://video_server1@state.california.gov", > "iat":1300815780, > "exp":1300819380, > "acr":"password"} > > hq4zk+ZknjggCQgZm7ea8fI79gJEsRy3E8LHDpYXWQIgZpkJN9CMLG8ENR4Nrw+n7iyzixBvKXX8P53BTCT4VghPBWhFYSt9tHWu/AtJfOTh6qaAsNdeCyG86jmtp3TDMwuL/cBUj2OtBZOQMFn7jQ9YB7klIz3RqVL+wNmeWI4= > > The JWT might be optionally encrypted using JWE. > > I think what is becoming clear (and this is what I'm trying to vet) is > that while there is nothing in OAuth that specifies authentication, it > **can** be used for Authentication, if done in the way that I > describe. If I'm wrong about this, I really need to know. I've > vetted this idea of mine with quite of few people now -- both within > context of the list and off-line -- and I think I'm okay. If you see > any holes in what I describe, please point them out as I would prefer > to uncover them now rather than after implementation or deployment! > > Essentially I'm using OAuth as a RESTful version of WS-Trust, where my > client can exchange primary credentials for a token (JWT) and present > that token to a server as secondary authentication. It's just that > it's RESTful instead of SOAP :-) > > As Justin as pointed out ... I've basically made the access-token look > like the id_token of Connect. I was actually hoping to lay a path to > Connect, and use the id_token ... until it was also pointed out that > the id_token is really meant for the consumption of the client, not > the RS :-( > > *From:*oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On > Behalf Of *Igor Faynberg > *Sent:* Wednesday, June 20, 2012 2:39 PM > *To:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Report an authentication issue > > But this use case does need OAuth, period: > > The video server is under the control of a police agency, and police > officers must logon to the video server in order to access video content. > > There is no delegation here, and there is no need to use third party > for authentication. > > Igor > > On 6/20/2012 3:26 PM, Justin Richer wrote: > > In case it wasn't clear, I want to restate the original problem as > best as I understand it in a way that hopefully clears it up: > > App A and app B are both valid registered OAuth clients to an OAuth > protected service. > > The problem starts when app A gets handed a token that was issued for > app B and uses it to call an identity API on the OAuth service. Since > app B can get tokens just fine, they're bearer tokens, this is a > fairly basic api call, this function works just fine and returns the > user info. This makes sense, since anyone who holds A's tokens can do > whatever A can do on behalf of that user. The issues start when app B > then decides that since they can make a call to the identity API with > a token then the user *must* be present. In other words, app B is > confusing authorization to call an API with authentication of the session. > > OpenID Connect fixes this missed assumption by binding the ID Token to > the session and sending it along side the access token, but as you > pointed out, it's meant for consumption at the client, not the > resource server, in general. That doesn't mean you can't send it to a > resource server for your own purposes, of course. That's actually how > the session management endpoint works in Connect. > > This isn't the only way to handle this problem -- if you put some > structure in your tokens, such as with JWT or SAML, then app A can > tell that this isn't a token issued to app A, but to app B, so it can > call shenanigans and reject it then and there. > > -- Justin > > On 06/20/2012 10:03 AM, Lewis Adam-CAL022 wrote: > > I am entirely confused. > > I understand what everybody is saying for confidential clients, no > problem here. > > I fall apart when thinking of iPhone apps. Consider the scenario > where I deploy a video server, and write an iPhone app to talk to the > video server. The video server is under the control of a police > agency, and police officers must logon to the video server in order to > access video content. So the police office launches their iPhone > video client app. > > If I wanted to solve authentication using "traditional" client-server > authentication, the user enters their username / password into the > client, and the client sends the username / password off to the > server, which authenticates it, or possibly uses HTTP digest. > > > If I wanted to use OpenID, the client would attempt to reach the video > server (RP), the server would redirect the client to the OP, OP > authenticates user, and OP redirects client back to the server/RP with > an assertion that primary authentication was successful. > > > If I wanted to use OAuth, the client would send an authorization > request to the server's AS, which would authenticate the user of the > client, and ultimately result in the client possessing an > access-token. My thinking is that this access token (let's assume > it's a JWT) would contain the user's identity, a statement of what > type of primary authentication was used (auth context), an expiration, > and an audience claim. This sounds a lot like authentication to me, > and it's where I get confused. Is it just because OAuth does not > explicitly define this? Is there a threat in using OAuth as I describe? > > > If I wanted to use Connect, well I'm not even sure how the id_token as > defined by Connect helps this use case. The id_token seems to make > sense when the client is a confidential web server, but it's not clear > what an iPhone app would do with the id_token ... it's the server in > the backend that needs to authenticate the user, the iPhone app is > just an interface to talk to the server. And it seems as I learn more > about connect that the id_token is not meant to be sent from the > iPhone app to the server, just the access token. So it's really not > clear how Connect helps solve authentication for an iPhone client app > talking to a video server. If I'm sending access-tokens, it's just > OAuth again. > > What am I still missing? > > adam > > *From:*oauth-bounces@ietf.org > [mailto:oauth-bounces@ietf.org] *On Behalf Of *Kristofor Selden > *Sent:* Saturday, June 16, 2012 11:33 AM > *To:* nov matake; oauth > *Cc:* Yuchen Zhou; Luke Melia; Shuo Chen (MSR) > *Subject:* Re: [OAUTH-WG] Report an authentication issue > > Nov demonstrated the problem to us at Yapp and we used solution 4 > (because the solution is server side and our app was in the app store). > > FB Connect is authentication /and/ authorization, where OAuth 2 is > concerned only with authorization -- I'm not sure that app developers > appreciate this subtlety. > > With OAuth 2 you authorize an app to use a protected resource. With > FB Connect, you do that, but /also/ authenticate with the app you are > authorizing. > > So the access_token protects not just the FB resources but the auth > end point of the authorized app (very common with apps that use the > iOS SDK). So now the app needs a way to verify that it was the app > that was authorized to FB. > > Solution 4 explanation: on FB you can register a iPhone app and a > server app with the same client_id and get a client_secret for use on > the server. The server side API posts the access_token, client_id, > and client_secret to https://graph.facebook.com/app > to verify > that the bearer token actually belongs to the app that is being > authenticated before assuming they are authorized to the app's > protected resources. > > Kris > > On Jun 15, 2012, at 8:22 PM, nov matake wrote: > > > > > There are 4 ways to fix this issue. > > 1. Use response_type=token%20code (It's not in OAuth 2.0 Core, but > seems best way for interoperability) > > 2. Use singed_request (or some signed token like JWT) > > 3. Use grant_type=fb_exchange_token (Facebook custom way) > > 4. Access to https://graph.facebook.com/app?access_token=YOUR_TOKEN > (Facebook custom way, moreover undocumented API) > > Two iPhone app developers I reported this issue fixed it by using (4). > > I also tried to use (1) for my own iPhone app implementation, but > unfortunately it doesn't work when using authorization codes obtained > via FB iOS SDK. > > So I'm using (3) in my case. > > nov > > On 2012/06/16, at 9:16, Nat Sakimura wrote: > > > > > As to how the fix was done, Nov can provide more detail, but ... > > 1. Properly verify the signature/HMAC of the "signed_request". This > will essentially audience restricts the token. > > 2. There is an undocumented API for Facebook which returns to whom the > token was issued. This also audience restricts the token. > > The service that fixed took these measures. Note that none of the > above is defined in OAuth. > > The same facility was called "id_token" and "check ID endpoint" for > OpenID Connect. > > The scale of the impact is large, too large to disclose the actual > names in the public list, though, eventually, we would publish them in > a paper. > > Nat > > On Sat, Jun 16, 2012 at 5:34 AM, Francisco Corella > > wrote: > > > Hi Nat and Rui, > > Rui, you say that the vulnerability that you found was due to a > "common misunderstanding among developers", but the attack you > describe can be carried out against any app that uses the OAuth > "implicit grant flow", which Facebook calls "client-side > authentication". No misunderstanding seems necessary. What > misunderstanding are you referring to? I followed the link in your > message to the Sophos post, and from there the link to the article in > The Register. The article in The Register says that Facebook had > "fixed the vulnerability promptly". How did they fix it? The > instructions that Facebook provides for implementing "Client-side > authentication without the JS SDK" at > https://developers.facebook.com/docs/authentication/client-side/#no-jssdk > still allows the attack. > > Nat, I agree that the blog post by John Bradley that you link to > refers to the same vulnerability reported by Rui. You say that some > apps have issued a patch to fix it. Could you explain what the fix > was? > > Francisco > > ------------------------------------------------------------------------ > > *From:*Nat Sakimura > > *To:* rui wang > > *Cc:* matake nov >; Yuchen > Zhou >; > oauth >; Shuo Chen (MSR) > > > *Sent:* Thursday, June 14, 2012 1:50 PM > *Subject:* Re: [OAUTH-WG] Report an authentication issue > > This is a fairly well known (hopefully by now) issue. We, at the > OpenID Foundation, call it "access_token phishing" attack these > days. See: > http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.html > > Nov Matake has actually built the code on iPhone to verify the > problem, and has notified bunch of parties back in February > including Facebook and Apple. We have the code that actually runs > on a phone, and we have successfully logged in to bunch of apps, > including very well known ones. They were all informed of the > issue. Some immediately issued a patch to fix it while others have > not. > > The problem is that even if these apps gets fixed, the problem > does not go away. As long as the attacker has the vulnerable > version of the app, he still can impersonate the victim. To stop > it, the server side has to completely disable the older version, > which means the service has to cut off many users pausing business > problems. > > Nat > > On Fri, Jun 15, 2012 at 2:18 AM, rui wang > wrote: > > Dear Facebook Security Team and OAuth Standard group, > > We are a research team in Microsoft Research. In January, 2011, we > reported a vulnerability in Facebook Connect which allowed > everyone to sign into Facebook-secured relying parties without > password. It was promptly fixed after reporting. > (http://nakedsecurity.sophos.com/2011/02/02/facebook-flaw-websites-steal-personal-data/) > > Recently, we found a common misunderstanding among developers of > mobile/metro apps when using OAuth (including Facebook's OAuth) > for authentication. The vulnerability resulted from this > misunderstanding also allows an attacker to log into a victim > user's account without password. > > Let's take Soluto's metro app as an example to describe the > problem. The app supports Facebook Login. As an attacker, we can > write a regular Facebook app. Once the victim user allows our app > to access her Facebook data, we receive an access_token from the > traffic. Then, on our own machine (i.e., the "attacker" machine), > we run the metro app of Soluto, and use a HTTP proxy to insert the > victim's access_token into the traffic of Facebook login. Through > this way, we are able to log into the victim's Soluto account from > our machine. Other than Soluto, we also have confirmed the same > issue on another Windows 8 metro-app Givit. > > The Facebook SDK for Android apps > (https://developers.facebook.com/docs/mobile/android/build/#sdk) > seems to have the possibility to mislead developers too. At least, > the issue that we found is not clearly mentioned. In the SDK, we > ran the sample code called "Hackbook" using Android Emulator > (imagine it is an attacker device). Note that we have already > received the access token of the victim user from our regular > Facebook app. We then inject the token to the traffic of Hackbook. > Through this way, Hackbook app on our own machine recognizes us as > the victim. Note that this is not a convincing security exploit > yet, because this sample code does not include the server-side > code. However, given that we have seen real server-side code > having this problem, such as Soluto, Givit and others, we do > believe that the sample code can mislead mobile/metro developers. > We also suspect that this may be a general issue of many OAuth > implementations on mobile platforms, so we send this message to > OAuth Standard group as well. > > We have contacted the vendors of the two vulnerable metro-apps, > Soluto and Gavit. > > Please kindly give us an ack when you receive this message. If you > want to know more details, please let us know. > > Best Regards, > Yuchen Zhou, Rui Wang, and Shuo Chen > > > _______________________________________________ > 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 > > > > > -- > 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 > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------010605090004000207060701 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Adam,

Now I think I understand the use case. I agree with you that if the token is made specifically out to authenticate the user, it is an entirely different matter. 

(In the early OAuth days, I was suggesting to consider structuring a token simliarly to a Kerberos ticket, which is more or less what would serve the use case you propose.)

Igor

On 6/20/2012 4:21 PM, Lewis Adam-CAL022 wrote:

Hi Igor,

 

As Justin just pointed out, consider the case where the video server is hosted by the state (e.g. California) and is accessed by police agencies in Los Angeles, San Francisco, and San Diego.  The State of California’s video server is the RS.  Each local police agency (LA/SF/SD) hosts an AS.  So when a police officer from LAPD launches the video client app on the iPhone, the client makes an OAuth request to the LAPD’s AS, which authenticates the police officer using agency level credentials.  The access token issued to the video client app on the iPhone is a JWT, signed by the agency AS, which might look something like this:

 

{“typ”:”JWT”,"alg":"ES256"}

{"iss":"https://as.lapd.california.gov",
  "prn":"alice@lapd.california.gov",
  "aud":" https://video_server1@state.california.gov",
  "iat":1300815780,
  "exp":1300819380,
  "acr":”password”}

hq4zk+ZknjggCQgZm7ea8fI79gJEsRy3E8LHDpYXWQIgZpkJN9CMLG8ENR4Nrw+n7iyzixBvKXX8P53BTCT4VghPBWhFYSt9tHWu/AtJfOTh6qaAsNdeCyG86jmtp3TDMwuL/cBUj2OtBZOQMFn7jQ9YB7klIz3RqVL+wNmeWI4=

 

The JWT might be optionally encrypted using JWE. 

 

I think what is becoming clear (and this is what I’m trying to vet) is that while there is nothing in OAuth that specifies authentication, it *can* be used for Authentication, if done in the way that I describe.  If I’m wrong about this, I really need to know.  I’ve vetted this idea of mine with quite of few people now – both within context of the list and off-line – and I think I’m okay. If you see any holes in what I describe, please point them out as I would prefer to uncover them now rather than after implementation or deployment!

 

Essentially I’m using OAuth as a RESTful version of WS-Trust, where my client can exchange primary credentials for a token (JWT) and present that token to a server as secondary authentication.  It’s just that it’s RESTful instead of SOAP :-)

 

As Justin as pointed out … I’ve basically made the access-token look like the id_token of Connect.  I was actually hoping to lay a path to Connect, and use the id_token … until it was also pointed out that the id_token is really meant for the consumption of the client, not the RS :-(

 

 

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Igor Faynberg
Sent: Wednesday, June 20, 2012 2:39 PM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] Report an authentication issue

 

But this use case  does need OAuth, period:

The video server is under the control of a police agency, and police officers must logon to the video server in order to access video content.

There is no delegation here, and there is no need to use third party for authentication. 

Igor

On 6/20/2012 3:26 PM, Justin Richer wrote:

In case it wasn't clear, I want to restate the original problem as best as I understand it in a way that hopefully clears it up:

App A and app B are both valid registered OAuth clients to an OAuth protected service.

The problem starts when app A gets handed a token that was issued for app B and uses it to call an identity API on the OAuth service. Since app B can get tokens just fine, they're bearer tokens, this is a fairly basic api call, this function works just fine and returns the user info. This makes sense, since anyone who holds A's tokens can do whatever A can do on behalf of that user. The issues start when app B then decides that since they can make a call to the identity API with a token then the user *must* be present. In other words, app B is confusing authorization to call an API with authentication of the session.

OpenID Connect fixes this missed assumption by binding the ID Token to the session and sending it along side the access token, but as you pointed out, it's meant for consumption at the client, not the resource server, in general. That doesn't mean you can't send it to a resource server for your own purposes, of course. That's actually how the session management endpoint works in Connect.

This isn't the only way to handle this problem -- if you put some structure in your tokens, such as with JWT or SAML, then app A can tell that this isn't a token issued to app A, but to app B, so it can call shenanigans and reject it then and there.

 -- Justin

On 06/20/2012 10:03 AM, Lewis Adam-CAL022 wrote:

I am entirely confused.

 

I understand what everybody is saying for confidential clients, no problem here.

 

I fall apart when thinking of iPhone apps.  Consider the scenario where I deploy a video server, and write an iPhone app to talk to the video server.  The video server is under the control of a police agency, and police officers must logon to the video server in order to access video content.  So the police office launches their iPhone video client app.

 

If I wanted to solve authentication using “traditional” client-server authentication, the user enters their username / password into the client, and the client sends the username / password off to the server, which authenticates it, or possibly uses HTTP digest. 


If I wanted to use OpenID, the client would attempt to reach the video server (RP), the server would redirect the client to the OP, OP authenticates user, and OP redirects client back to the server/RP with an assertion that primary authentication was successful. 


If I wanted to use OAuth, the client would send an authorization request to the server’s AS, which would authenticate the user of the client, and ultimately result in the client possessing an access-token.  My thinking is that this access token (let’s assume it’s a JWT) would contain the user’s identity, a statement of what type of primary authentication was used (auth context), an expiration, and an audience claim.  This sounds a lot like authentication to me, and it’s where I get confused.  Is it just because OAuth does not explicitly define this?  Is there a threat in using OAuth as I describe? 


If I wanted to use Connect, well I’m not even sure how the id_token as defined by Connect helps this use case.  The id_token seems to make sense when the client is a confidential web server, but it’s not clear what an iPhone app would do with the id_token … it’s the server in the backend that needs to authenticate the user, the iPhone app is just an interface to talk to the server.  And it seems as I learn more about connect that the id_token is not meant to be sent from the iPhone app to the server, just the access token.  So it’s really not clear how Connect helps solve authentication for an iPhone client app talking to a video server.  If I’m sending access-tokens, it’s just OAuth again.

 

What am I still missing?

adam

 

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Kristofor Selden
Sent: Saturday, June 16, 2012 11:33 AM
To: nov matake; oauth
Cc: Yuchen Zhou; Luke Melia; Shuo Chen (MSR)
Subject: Re: [OAUTH-WG] Report an authentication issue

 

Nov demonstrated the problem to us at Yapp and we used solution 4 (because the solution is server side and our app was in the app store).

 

FB Connect is authentication and authorization, where OAuth 2 is concerned only with authorization – I'm not sure that app developers appreciate this subtlety.

 

With OAuth 2 you authorize an app to use a protected resource.  With FB Connect, you do that, but also authenticate with the app you are authorizing.

 

So the access_token protects not just the FB resources but the auth end point of the authorized app (very common with apps that use the iOS SDK).  So now the app needs a way to verify that it was the app that was authorized to FB.

 

Solution 4 explanation: on FB you can register a iPhone app and a server app with the same client_id and get a client_secret for use on the server.  The server side API posts the access_token, client_id, and client_secret to https://graph.facebook.com/app to verify that the bearer token actually belongs to the app that is being authenticated before assuming they are authorized to the app's protected resources.

 

Kris

 

On Jun 15, 2012, at 8:22 PM, nov matake wrote:




There are 4 ways to fix this issue.

 

1. Use response_type=token%20code (It's not in OAuth 2.0 Core, but seems best way for interoperability)

2. Use singed_request (or some signed token like JWT)

3. Use grant_type=fb_exchange_token (Facebook custom way)

4. Access to https://graph.facebook.com/app?access_token=YOUR_TOKEN (Facebook custom way, moreover undocumented API)

 

Two iPhone app developers I reported this issue fixed it by using (4).

 

I also tried to use (1) for my own iPhone app implementation, but unfortunately it doesn't work when using authorization codes obtained via FB iOS SDK.

So I'm using (3) in my case.

 

nov

 

On 2012/06/16, at 9:16, Nat Sakimura wrote:




As to how the fix was done, Nov can provide more detail, but ... 

 

1. Properly verify the signature/HMAC of the "signed_request". This will essentially audience restricts the token. 

2. There is an undocumented API for Facebook which returns to whom the token was issued. This also audience restricts the token. 

 

The service that fixed took these measures. Note that none of the above is defined in OAuth. 

The same facility was called "id_token" and "check ID endpoint" for OpenID Connect. 

 

The scale of the impact is large, too large to disclose the actual names in the public list, though, eventually, we would publish them in a paper. 

 

Nat

On Sat, Jun 16, 2012 at 5:34 AM, Francisco Corella <fcorella@pomcor.com> wrote:


Hi Nat and Rui,

Rui, you say that the vulnerability that you found was due to a
"common misunderstanding among developers", but the attack you
describe can be carried out against any app that uses the OAuth
"implicit grant flow", which Facebook calls "client-side
authentication".  No misunderstanding seems necessary.  What
misunderstanding are you referring to?  I followed the link in your
message to the Sophos post, and from there the link to the article in
The Register.  The article in The Register says that Facebook had
"fixed the vulnerability promptly".  How did they fix it?  The
instructions that Facebook provides for implementing "Client-side
authentication without the JS SDK" at
https://developers.facebook.com/docs/authentication/client-side/#no-jssdk
still allows the attack.

Nat, I agree that the blog post by John Bradley that you link to
refers to the same vulnerability reported by Rui.  You say that some
apps have issued a patch to fix it.  Could you explain what the fix
was?

Francisco

 

From: Nat Sakimura <sakimura@gmail.com>
To: rui wang <ruiwangwarm@gmail.com>
Cc: matake nov <nov@matake.jp>; Yuchen Zhou <t-yuzhou@microsoft.com>; oauth <oauth@ietf.org>; Shuo Chen (MSR) <shuochen@microsoft.com>
Sent: Thursday, June 14, 2012 1:50 PM
Subject: Re: [OAUTH-WG] Report an authentication issue

 

This is a fairly well known (hopefully by now) issue. We, at the OpenID Foundation, call it "access_token phishing" attack these days. See: http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.html

 

Nov Matake has actually built the code on iPhone to verify the problem, and has notified bunch of parties back in February including Facebook and Apple. We have the code that actually runs on a phone, and we have successfully logged in to bunch of apps, including very well known ones. They were all informed of the issue. Some immediately issued a patch to fix it while others have not.  

 

The problem is that even if these apps gets fixed, the problem does not go away. As long as the attacker has the vulnerable version of the app, he still can impersonate the victim. To stop it, the server side has to completely disable the older version, which means the service has to cut off many users pausing business problems. 

 

Nat

On Fri, Jun 15, 2012 at 2:18 AM, rui wang <ruiwangwarm@gmail.com> wrote:

Dear Facebook Security Team and OAuth Standard group,

We are a research team in Microsoft Research. In January, 2011, we reported a vulnerability in Facebook Connect which allowed everyone to sign into Facebook-secured relying parties without password. It was promptly fixed after reporting. (http://nakedsecurity.sophos.com/2011/02/02/facebook-flaw-websites-steal-personal-data/)

Recently, we found a common misunderstanding among developers of mobile/metro apps when using OAuth (including Facebook’s OAuth) for authentication. The vulnerability resulted from this misunderstanding also allows an attacker to log into a victim user's account without password.

Let's take Soluto's metro app as an example to describe the problem. The app supports Facebook Login. As an attacker, we can write a regular Facebook app. Once the victim user allows our app to access her Facebook data, we receive an access_token from the traffic. Then, on our own machine (i.e., the "attacker" machine), we run the metro app of Soluto, and use a HTTP proxy to insert the victim's access_token into the traffic of Facebook login. Through this way, we are able to log into the victim's Soluto account from our machine. Other than Soluto, we also have confirmed the same issue on another Windows 8 metro-app Givit.

The Facebook SDK for Android apps (https://developers.facebook.com/docs/mobile/android/build/#sdk) seems to have the possibility to mislead developers too. At least, the issue that we found is not clearly mentioned. In the SDK, we ran the sample code called "Hackbook" using Android Emulator (imagine it is an attacker device). Note that we have already received the access token of the victim user from our regular Facebook app. We then inject the token to the traffic of Hackbook. Through this way, Hackbook app on our own machine recognizes us as the victim. Note that this is not a convincing security exploit yet, because this sample code does not include the server-side code. However, given that we have seen real server-side code having this problem, such as Soluto, Givit and others, we do believe that the sample code can mislead mobile/metro developers. We also suspect that this may be a general issue of many OAuth implementations on mobile platforms, so we send this message to OAuth Standard group as well.

We have contacted the vendors of the two vulnerable metro-apps, Soluto and Gavit.

Please kindly give us an ack when you receive this message. If you want to know more details, please let us know.

Best Regards,
Yuchen Zhou, Rui Wang, and Shuo Chen


_______________________________________________
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




 

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



 
 
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--------------010605090004000207060701-- From sakimura@gmail.com Wed Jun 20 18:08:45 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16FF221F858F for ; Wed, 20 Jun 2012 18:08:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.381 X-Spam-Level: X-Spam-Status: No, score=-3.381 tagged_above=-999 required=5 tests=[AWL=0.217, 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 t5gaG9EzSBt7 for ; Wed, 20 Jun 2012 18:08:42 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 42BD221F858E for ; Wed, 20 Jun 2012 18:08:41 -0700 (PDT) Received: by bkty8 with SMTP id y8so60757bkt.31 for ; Wed, 20 Jun 2012 18:08:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=I7Ij/Yd1vXROHjxEvyEfMjuJxdOzevsXlvPS7va7Sig=; b=dazu0MMX2lRw2OFbo4Q4MNHn9YZT2oaH1+oM5E5eVNK2Z1FNgemlM0rSNTBCTFPV0w du4hZ/behAT++sOky5Ari57mnoCTIXkQHl+gCB0xB0EEgSUm5rtbRLKN/hA1njbX+5hG VTxSNUEnuCjaw8IdPSBAQT3om2fsAo6Zeqrcp5I/zvTC7Ie/0LMQQNi9nwuweSsAiN3j z+shNmSzGLit0xyqhTRqtw1jn2xXB8XPonUS1VR6q5GGJ33xxZZnQ15OkOhryQ6EUw58 FoKI9+yGmi8lNcoJKhpIuwwd8sIvZEcGt8ZCSSHUoN7ZAkovIoUGs0MnGxfJ51etRgdY WSBw== MIME-Version: 1.0 Received: by 10.205.133.13 with SMTP id hw13mr10847114bkc.30.1340240919651; Wed, 20 Jun 2012 18:08:39 -0700 (PDT) Received: by 10.204.240.143 with HTTP; Wed, 20 Jun 2012 18:08:39 -0700 (PDT) In-Reply-To: <59E470B10C4630419ED717AC79FCF9A910889AB5@BL2PRD0410MB363.namprd04.prod.outlook.com> References: <1339792496.52712.YahooMailNeo@web125501.mail.ne1.yahoo.com> <59E470B10C4630419ED717AC79FCF9A9108898EE@BL2PRD0410MB363.namprd04.prod.outlook.com> <4FE223E4.6060307@mitre.org> <4FE226BC.6010403@alcatel-lucent.com> <59E470B10C4630419ED717AC79FCF9A910889AB5@BL2PRD0410MB363.namprd04.prod.outlook.com> Date: Thu, 21 Jun 2012 10:08:39 +0900 Message-ID: From: Nat Sakimura To: Lewis Adam-CAL022 Content-Type: multipart/alternative; boundary=000e0ce0d672ede81704c2f12719 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Report an authentication issue X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 01:08:45 -0000 --000e0ce0d672ede81704c2f12719 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Yes, OAuth can be profiled to enable authentication. In fact, initial draft of OpenID Connect was just like you described. Essentially, we were using structured access_token. Later, we decided to separate the access token and id_token for several reasons such as: 1. Better interop with existing OAuth implementations: by introducing id_token, they do not need to touch the supposedly opaque (which means AS-RS may be doing some proprietary thing inside it) access token. 2. Mixing up the audience (for id_token aka authn =3D client, and for access_token aka authz =3D resource server) probably is expanding the at= tack surface for security and privacy. Although we separated them out, a signed id_token includes the left hash of access_token so access_token is also protected. Best, Nat On Thu, Jun 21, 2012 at 5:21 AM, Lewis Adam-CAL022 < Adam.Lewis@motorolasolutions.com> wrote: > Hi Igor,**** > > ** ** > > As Justin just pointed out, consider the case where the video server is > hosted by the state (e.g. California) and is accessed by police agencies = in > Los Angeles, San Francisco, and San Diego. The State of California=92s v= ideo > server is the RS. Each local police agency (LA/SF/SD) hosts an AS. So > when a police officer from LAPD launches the video client app on the > iPhone, the client makes an OAuth request to the LAPD=92s AS, which > authenticates the police officer using agency level credentials. The > access token issued to the video client app on the iPhone is a JWT, signe= d > by the agency AS, which might look something like this:**** > > ** ** > > {=93typ=94:=94JWT=94,"alg":"ES256"}**** > > {"iss":"https://as.lapd.california.gov", > "prn":"alice@lapd.california.gov", > "aud":" https://video_server1@state.california.gov", > "iat":1300815780, > "exp":1300819380, > "acr":=94password=94}**** > > > hq4zk+ZknjggCQgZm7ea8fI79gJEsRy3E8LHDpYXWQIgZpkJN9CMLG8ENR4Nrw+n7iyzixBvK= XX8P53BTCT4VghPBWhFYSt9tHWu/AtJfOTh6qaAsNdeCyG86jmtp3TDMwuL/cBUj2OtBZOQMFn7= jQ9YB7klIz3RqVL+wNmeWI4=3D > **** > > ** ** > > The JWT might be optionally encrypted using JWE. **** > > ** ** > > I think what is becoming clear (and this is what I=92m trying to vet) is > that while there is nothing in OAuth that specifies authentication, it ** > can** be used for Authentication, if done in the way that I describe. If > I=92m wrong about this, I really need to know. I=92ve vetted this idea o= f mine > with quite of few people now =96 both within context of the list and off-= line > =96 and I think I=92m okay. If you see any holes in what I describe, plea= se > point them out as I would prefer to uncover them now rather than after > implementation or deployment!**** > > ** ** > > Essentially I=92m using OAuth as a RESTful version of WS-Trust, where my > client can exchange primary credentials for a token (JWT) and present tha= t > token to a server as secondary authentication. It=92s just that it=92s R= ESTful > instead of SOAP :-)**** > > ** ** > > As Justin as pointed out =85 I=92ve basically made the access-token look = like > the id_token of Connect. I was actually hoping to lay a path to Connect, > and use the id_token =85 until it was also pointed out that the id_token = is > really meant for the consumption of the client, not the RS :-(**** > > ** ** > > ** ** > > ** ** > > *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behalf > Of *Igor Faynberg > *Sent:* Wednesday, June 20, 2012 2:39 PM > *To:* oauth@ietf.org > > *Subject:* Re: [OAUTH-WG] Report an authentication issue**** > > ** ** > > But this use case does need OAuth, period: > > > The video server is under the control of a police agency, and police > officers must logon to the video server in order to access video content. > > There is no delegation here, and there is no need to use third party for > authentication. > > Igor > > On 6/20/2012 3:26 PM, Justin Richer wrote: **** > > In case it wasn't clear, I want to restate the original problem as best a= s > I understand it in a way that hopefully clears it up: > > App A and app B are both valid registered OAuth clients to an OAuth > protected service. > > The problem starts when app A gets handed a token that was issued for app > B and uses it to call an identity API on the OAuth service. Since app B c= an > get tokens just fine, they're bearer tokens, this is a fairly basic api > call, this function works just fine and returns the user info. This makes > sense, since anyone who holds A's tokens can do whatever A can do on beha= lf > of that user. The issues start when app B then decides that since they ca= n > make a call to the identity API with a token then the user *must* be > present. In other words, app B is confusing authorization to call an API > with authentication of the session. > > OpenID Connect fixes this missed assumption by binding the ID Token to th= e > session and sending it along side the access token, but as you pointed ou= t, > it's meant for consumption at the client, not the resource server, in > general. That doesn't mean you can't send it to a resource server for you= r > own purposes, of course. That's actually how the session management > endpoint works in Connect. > > This isn't the only way to handle this problem -- if you put some > structure in your tokens, such as with JWT or SAML, then app A can tell > that this isn't a token issued to app A, but to app B, so it can call > shenanigans and reject it then and there. > > -- Justin > > On 06/20/2012 10:03 AM, Lewis Adam-CAL022 wrote: **** > > I am entirely confused.**** > > **** > > I understand what everybody is saying for confidential clients, no proble= m > here.**** > > **** > > I fall apart when thinking of iPhone apps. Consider the scenario where I > deploy a video server, and write an iPhone app to talk to the video > server. The video server is under the control of a police agency, and > police officers must logon to the video server in order to access video > content. So the police office launches their iPhone video client app.***= * > > **** > > If I wanted to solve authentication using =93traditional=94 client-server > authentication, the user enters their username / password into the client= , > and the client sends the username / password off to the server, which > authenticates it, or possibly uses HTTP digest. > > > **** > > If I wanted to use OpenID, the client would attempt to reach the video > server (RP), the server would redirect the client to the OP, OP > authenticates user, and OP redirects client back to the server/RP with an > assertion that primary authentication was successful. > > > **** > > If I wanted to use OAuth, the client would send an authorization request > to the server=92s AS, which would authenticate the user of the client, an= d > ultimately result in the client possessing an access-token. My thinking = is > that this access token (let=92s assume it=92s a JWT) would contain the us= er=92s > identity, a statement of what type of primary authentication was used (au= th > context), an expiration, and an audience claim. This sounds a lot like > authentication to me, and it=92s where I get confused. Is it just becaus= e > OAuth does not explicitly define this? Is there a threat in using OAuth = as > I describe? > > > **** > > If I wanted to use Connect, well I=92m not even sure how the id_token as > defined by Connect helps this use case. The id_token seems to make sense > when the client is a confidential web server, but it=92s not clear what a= n > iPhone app would do with the id_token =85 it=92s the server in the backen= d that > needs to authenticate the user, the iPhone app is just an interface to ta= lk > to the server. And it seems as I learn more about connect that the > id_token is not meant to be sent from the iPhone app to the server, just > the access token. So it=92s really not clear how Connect helps solve > authentication for an iPhone client app talking to a video server. If I= =92m > sending access-tokens, it=92s just OAuth again.**** > > **** > > What am I still missing?**** > > adam**** > > **** > > **** > > *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] > *On Behalf Of *Kristofor Selden > *Sent:* Saturday, June 16, 2012 11:33 AM > *To:* nov matake; oauth > *Cc:* Yuchen Zhou; Luke Melia; Shuo Chen (MSR) > *Subject:* Re: [OAUTH-WG] Report an authentication issue**** > > **** > > Nov demonstrated the problem to us at Yapp and we used solution 4 (becaus= e > the solution is server side and our app was in the app store).**** > > **** > > FB Connect is authentication *and* authorization, where OAuth 2 is > concerned only with authorization =96 I'm not sure that app developers > appreciate this subtlety.**** > > **** > > With OAuth 2 you authorize an app to use a protected resource. With FB > Connect, you do that, but *also* authenticate with the app you are > authorizing.**** > > **** > > So the access_token protects not just the FB resources but the auth end > point of the authorized app (very common with apps that use the iOS SDK). > So now the app needs a way to verify that it was the app that was > authorized to FB.**** > > **** > > Solution 4 explanation: on FB you can register a iPhone app and a server > app with the same client_id and get a client_secret for use on the server= . > The server side API posts the access_token, client_id, and client_secret > to https://graph.facebook.com/app to verify > that the bearer token actually belongs to the app that is being > authenticated before assuming they are authorized to the app's protected > resources.**** > > **** > > Kris**** > > **** > > On Jun 15, 2012, at 8:22 PM, nov matake wrote:**** > > > > > **** > > There are 4 ways to fix this issue.**** > > **** > > 1. Use response_type=3Dtoken%20code (It's not in OAuth 2.0 Core, but seem= s > best way for interoperability)**** > > 2. Use singed_request (or some signed token like JWT)**** > > 3. Use grant_type=3Dfb_exchange_token (Facebook custom way)**** > > 4. Access to https://graph.facebook.com/app?access_token=3DYOUR_TOKEN(Fac= ebook custom way, moreover undocumented API) > **** > > **** > > Two iPhone app developers I reported this issue fixed it by using (4).***= * > > **** > > I also tried to use (1) for my own iPhone app implementation, but > unfortunately it doesn't work when using authorization codes obtained via > FB iOS SDK.**** > > So I'm using (3) in my case.**** > > **** > > nov**** > > **** > > On 2012/06/16, at 9:16, Nat Sakimura wrote:**** > > > > > **** > > As to how the fix was done, Nov can provide more detail, but ... **** > > **** > > 1. Properly verify the signature/HMAC of the "signed_request". This will > essentially audience restricts the token. **** > > 2. There is an undocumented API for Facebook which returns to whom the > token was issued. This also audience restricts the token. **** > > **** > > The service that fixed took these measures. Note that none of the above i= s > defined in OAuth. **** > > The same facility was called "id_token" and "check ID endpoint" for OpenI= D > Connect. **** > > **** > > The scale of the impact is large, too large to disclose the actual names > in the public list, though, eventually, we would publish them in a paper. > **** > > **** > > Nat**** > > On Sat, Jun 16, 2012 at 5:34 AM, Francisco Corella > wrote: > > > **** > > Hi Nat and Rui, > > Rui, you say that the vulnerability that you found was due to a > "common misunderstanding among developers", but the attack you > describe can be carried out against any app that uses the OAuth > "implicit grant flow", which Facebook calls "client-side > authentication". No misunderstanding seems necessary. What > misunderstanding are you referring to? I followed the link in your > message to the Sophos post, and from there the link to the article in > The Register. The article in The Register says that Facebook had > "fixed the vulnerability promptly". How did they fix it? The > instructions that Facebook provides for implementing "Client-side > authentication without the JS SDK" at > https://developers.facebook.com/docs/authentication/client-side/#no-jssdk > still allows the attack. > > Nat, I agree that the blog post by John Bradley that you link to > refers to the same vulnerability reported by Rui. You say that some > apps have issued a patch to fix it. Could you explain what the fix > was? > > Francisco**** > > **** > ------------------------------ > > *From:* Nat Sakimura > *To:* rui wang > *Cc:* matake nov ; Yuchen Zhou ; > oauth ; Shuo Chen (MSR) > *Sent:* Thursday, June 14, 2012 1:50 PM > *Subject:* Re: [OAUTH-WG] Report an authentication issue**** > > **** > > This is a fairly well known (hopefully by now) issue. We, at the OpenID > Foundation, call it "access_token phishing" attack these days. See: > http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.= html > **** > > **** > > Nov Matake has actually built the code on iPhone to verify the problem, > and has notified bunch of parties back in February including Facebook and > Apple. We have the code that actually runs on a phone, and we have > successfully logged in to bunch of apps, including very well known ones. > They were all informed of the issue. Some immediately issued a patch to f= ix > it while others have not. **** > > **** > > The problem is that even if these apps gets fixed, the problem does not g= o > away. As long as the attacker has the vulnerable version of the app, he > still can impersonate the victim. To stop it, the server side has to > completely disable the older version, which means the service has to cut > off many users pausing business problems. **** > > **** > > Nat**** > > On Fri, Jun 15, 2012 at 2:18 AM, rui wang wrote:*= * > ** > > Dear Facebook Security Team and OAuth Standard group,**** > > We are a research team in Microsoft Research. In January, 2011, we > reported a vulnerability in Facebook Connect which allowed everyone to si= gn > into Facebook-secured relying parties without password. It was promptly > fixed after reporting. ( > http://nakedsecurity.sophos.com/2011/02/02/facebook-flaw-websites-steal-p= ersonal-data/ > )**** > > Recently, we found a common misunderstanding among developers of > mobile/metro apps when using OAuth (including Facebook=92s OAuth) for > authentication. The vulnerability resulted from this misunderstanding als= o > allows an attacker to log into a victim user's account without password.*= * > ** > > Let's take Soluto's metro app as an example to describe the problem. The > app supports Facebook Login. As an attacker, we can write a regular > Facebook app. Once the victim user allows our app to access her Facebook > data, we receive an access_token from the traffic. Then, on our own machi= ne > (i.e., the "attacker" machine), we run the metro app of Soluto, and use a > HTTP proxy to insert the victim's access_token into the traffic of Facebo= ok > login. Through this way, we are able to log into the victim's Soluto > account from our machine. Other than Soluto, we also have confirmed the > same issue on another Windows 8 metro-app Givit.**** > > The Facebook SDK for Android apps ( > https://developers.facebook.com/docs/mobile/android/build/#sdk) seems to > have the possibility to mislead developers too. At least, the issue that = we > found is not clearly mentioned. In the SDK, we ran the sample code called > "Hackbook" using Android Emulator (imagine it is an attacker device). Not= e > that we have already received the access token of the victim user from ou= r > regular Facebook app. We then inject the token to the traffic of Hackbook= . > Through this way, Hackbook app on our own machine recognizes us as the > victim. Note that this is not a convincing security exploit yet, because > this sample code does not include the server-side code. However, given th= at > we have seen real server-side code having this problem, such as Soluto, > Givit and others, we do believe that the sample code can mislead > mobile/metro developers. We also suspect that this may be a general issue > of many OAuth implementations on mobile platforms, so we send this messag= e > to OAuth Standard group as well.**** > > We have contacted the vendors of the two vulnerable metro-apps, Soluto an= d > Gavit.**** > > Please kindly give us an ack when you receive this message. If you want t= o > know more details, please let us know.**** > > Best Regards, > Yuchen Zhou, Rui Wang, and Shuo Chen**** > > > _______________________________________________ > 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 > > > **** > > > > **** > > **** > > -- > 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**** > > **** > > > > > **** > > _______________________________________________**** > > OAuth mailing 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 --000e0ce0d672ede81704c2f12719 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Yes, OAuth can be profiled to enable authentication.=A0
In fact, initia= l draft of OpenID Connect was just like you described.=A0
Essenti= ally, we were using structured access_token.=A0
Later, we decided= to separate the access token and id_token for several reasons such as:=A0<= /div>

  1. Better interop with existing OAuth implementati= ons: by introducing id_token, they do not need to touch the supposedly opaq= ue (which means AS-RS may be doing some proprietary thing inside it) access= token.=A0
  2. Mixing up the audience (for id_token aka authn =3D client, and for acce= ss_token aka authz =3D resource server) probably is expanding the attack su= rface for security and privacy.=A0
Although we separate= d them out, a signed id_token includes the left hash of access_token so acc= ess_token is also protected.=A0

Best,=A0

Nat

On Thu, Jun 21, 2012 at 5:21 AM, Lewis Adam-CAL022 = <Adam.Lewis@motorolasolutions.com> wrote:

Hi Igor,

=A0

As Justin just pointed out, consider the cas= e where the video server is hosted by the state (e.g. California) and is ac= cessed by police agencies in Los Angeles, San Francisco, and San Diego.=A0 The State of California=92s video server is the RS.=A0 E= ach local police agency (LA/SF/SD) hosts an AS.=A0 So when a police officer= from LAPD launches the video client app on the iPhone, the client makes an= OAuth request to the LAPD=92s AS, which authenticates the police officer using agency level credentials.=A0 The access token iss= ued to the video client app on the iPhone is a JWT, signed by the agency AS= , which might look something like this:

=A0

{=93typ=94:=94JWT=94,"alg":"E= S256"}

{"iss":"https://as.lapd.california.gov&= quot;,
=A0=A0"prn":"alice@lapd.california.gov",
=A0 "aud":" https://video_server1@state.california.gov&quo= t;,
=A0 "iat":1300815780,
=A0 "exp":1300819380,
=A0 "acr":=94password=94}

hq4zk+ZknjggCQ= gZm7ea8fI79gJEsRy3E8LHDpYXWQIgZpkJN9CMLG8ENR4Nrw+n7iyzixBvKXX8P53BTCT4VghPB= WhFYSt9tHWu/AtJfOTh6qaAsNdeCyG86jmtp3TDMwuL/cBUj2OtBZOQMFn7jQ9YB7klIz3RqVL+= wNmeWI4=3D

=A0<= /u>

The JWT might = be optionally encrypted using JWE.=A0

=A0<= /u>

I think what i= s becoming clear (and this is what I=92m trying to vet) is that while there= is nothing in OAuth that specifies authentication, it *can* be used for Authentication, if done in the way that I describe.=A0 If I=92= m wrong about this, I really need to know.=A0 I=92ve vetted this idea of mi= ne with quite of few people now =96 both within context of the list and off= -line =96 and I think I=92m okay. If you see any holes in what I describe, please point them out as I would prefer to uncov= er them now rather than after implementation or deployment!

=A0<= /u>

Essentially I= =92m using OAuth as a RESTful version of WS-Trust, where my client can exch= ange primary credentials for a token (JWT) and present that token to a server as secondary authentication.=A0 It=92s just that it=92s RESTfu= l instead of SOAP :-)

=A0<= /u>

As Justin as p= ointed out =85 I=92ve basically made the access-token look like the id_toke= n of Connect.=A0 I was actually hoping to lay a path to Connect, and use the id_token =85 until it was also pointed out that the id_token i= s really meant for the consumption of the client, not the RS :-(<= /u>

=A0<= /u>

=A0

=A0

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Igor Faynberg
Sent: Wednesday, June 20, 2012 2:39 PM
To: oauth@ietf.o= rg


Subject: Re: [OAUTH-WG] Report an authentication issue=

=A0

But this use case=A0 does need OAuth, period:



The video server is under the control of a police agency, and polic= e officers must logon to the video server in order to access video content.=

There is no delegation here, and there is no need to use third party for au= thentication.=A0

Igor

On 6/20/2012 3:26 PM, Justin Richer wrote:

In case it wasn't clear, I want to restate the o= riginal problem as best as I understand it in a way that hopefully clears i= t up:

App A and app B are both valid registered OAuth clients to an OAuth protect= ed service.

The problem starts when app A gets handed a token that was issued for app B= and uses it to call an identity API on the OAuth service. Since app B can = get tokens just fine, they're bearer tokens, this is a fairly basic api= call, this function works just fine and returns the user info. This makes sense, since anyone who holds A'= s tokens can do whatever A can do on behalf of that user. The issues start = when app B then decides that since they can make a call to the identity API= with a token then the user *must* be present. In other words, app B is confusing authorization to call an API w= ith authentication of the session.

OpenID Connect fixes this missed assumption by binding the ID Token to the = session and sending it along side the access token, but as you pointed out,= it's meant for consumption at the client, not the resource server, in = general. That doesn't mean you can't send it to a resource server for your own purposes, of course. That's = actually how the session management endpoint works in Connect.

This isn't the only way to handle this problem -- if you put some struc= ture in your tokens, such as with JWT or SAML, then app A can tell that thi= s isn't a token issued to app A, but to app B, so it can call shenaniga= ns and reject it then and there.

=A0-- Justin

On 06/20/2012 10:03 AM, Lewis Adam-CAL022 wrote:

I am entirely confused.=

=A0

I understand what everybody is saying for co= nfidential clients, no problem here.

=A0

I fall apart when thinking of iPhone apps.= =A0 Consider the scenario where I deploy a video server, and write an iPhon= e app to talk to the video server.=A0 The video server is under the control of a police agency, and police officers must logon to the vide= o server in order to access video content.=A0 So the police office launches= their iPhone video client app.

=A0

If I wanted to solve authentication using =93traditional= =94 client-server authentication, the user enters their username / password= into the client, and the client sends the username / password off to the server, which auth= enticates it, or possibly uses HTTP digest.=A0


If I wanted to use OpenID, the client would attempt to reach the= video server (RP), the server would redirect the client to the OP, OP auth= enticates user, and OP redirects client back to the server/RP with an assertion that= primary authentication was successful.=A0


If I wanted to use OAuth, the client wou= ld send an authorization request to the server=92s AS, which would authenti= cate the user of the client, and ultimately result in the client possessing an access-token.=A0 My thin= king is that this access token (let=92s assume it=92s a JWT) would contain = the user=92s identity, a statement of what type of primary authentication w= as used (auth context), an expiration, and an audience claim.=A0 This sounds a lot like authentication to me, and it= =92s where I get confused.=A0 Is it just because OAuth does not explicitly = define this?=A0 Is there a threat in using OAuth as I describe?=A0


If I wanted to use Connect, well I= =92m not even sure how the id_token as defined by Connect helps this use ca= se.=A0 The id_token seems to make sense when the client is a confidential web server, but it=92s not clear what an= iPhone app would do with the id_token =85 it=92s the server in the backend= that needs to authenticate the user, the iPhone app is just an interface t= o talk to the server.=A0 And it seems as I learn more about connect that the id_token is not meant to be sent from = the iPhone app to the server, just the access token.=A0 So it=92s really no= t clear how Connect helps solve authentication for an iPhone client app tal= king to a video server.=A0 If I=92m sending access-tokens, it=92s just OAuth again.

=A0

What am I still missing?

adam

=A0

=A0

From: oauth-bounces@i= etf.org [ma= ilto:oauth-bounces@ietf.org] On Behalf Of Kristofor Selden
Sent: Saturday, June 16, 2012 11:33 AM
To: nov matake; oauth
Cc: Yuchen Zhou; Luke Melia; Shuo Chen (MSR)
Subject: Re: [OAUTH-WG] Report an authentication issue=

=A0

Nov demonstrated the problem to us at Yapp and we us= ed solution 4 (because the solution is server side and our app was in the a= pp store).

=A0

FB Connect is authentication and authorizatio= n, where OAuth 2 is concerned only with authorization =96 I'm not sure = that app developers appreciate this subtlety.

=A0

With OAuth 2 you authorize an app to use a protected= resource. =A0With FB Connect, you do that, but also authenticate with the app you are authorizing.

=A0

So the access_token protects not just the FB resourc= es but the auth end point of the authorized app (very common with apps that= use the iOS SDK). =A0So now the app needs a way to verify that it was the = app that was authorized to FB.

=A0

Solution 4 explanation: on FB you can register a iPh= one app and a server app with the same client_id and get a client_secret fo= r use on the server. =A0The server side API posts the access_token,=A0clien= t_id, and=A0client_secret to=A0https://graph.facebook.com/app=A0to=A0verify that the bearer token actually belongs to the app that is being authentica= ted before assuming they are authorized to the app's protected resource= s.

=A0

Kris

=A0

On Jun 15, 2012, at 8:22 PM, nov matake wrote:




There are 4 ways to fix this issue.

=A0

1. Use response_type=3Dtoken%20code (It's=A0not = in OAuth 2.0 Core, but seems best way for interoperability)

2. Use singed_request (or some signed token like JWT= )

3. Use grant_type=3Dfb_exchange_token (Facebook cust= om way)

4. Access to https://graph.facebook.com/app?access_token=3DYOUR_TOKEN (Facebook cust= om way, moreover undocumented API)

=A0

Two iPhone app developers I reported this issue fixe= d it by using (4).

=A0

I also tried to use (1) for my own iPhone app implem= entation, but unfortunately it doesn't work when using authorization co= des obtained via FB iOS SDK.

So I'm using (3) in my case.

=A0

nov

=A0

On 2012/06/16, at 9:16, Nat Sakimura wrote:




As to how the fix was done, Nov can provide more det= ail, but ...=A0

=A0

1. Properly verify the signature/HMAC of the "s= igned_request". This will essentially audience restricts the token.=A0=

2. There is an undocumented API for Facebook which r= eturns to whom the token was issued. This also audience restricts the token= .=A0

=A0

The service that fixed took these measures. Note tha= t none of the above is defined in OAuth.=A0

The same facility was called "id_token" an= d "check ID endpoint" for OpenID Connect.=A0

=A0

The scale of the impact is large, too large to discl= ose the actual names in the public list, though, eventually, we would publi= sh them in a paper.=A0

=A0

Nat

On Sat, Jun 16, 2012 at 5:34 AM, Francisco Corella &= lt;fcorella@pomcor= .com> wrote:


Hi Nat and Rui,

Rui, you say that the vulnerability that you found was due to a
"common misunderstanding among developers", but the attack you describe can be carried out against any app that uses the OAuth
"implicit grant flow", which Facebook calls "client-side
authentication".=A0 No misunderstanding seems necessary.=A0 What
misunderstanding are you referring to?=A0 I followed the link in your
message to the Sophos post, and from there the link to the article in
The Register.=A0 The article in The Register says that Facebook had
"fixed the vulnerability promptly".=A0 How did they fix it?=A0 Th= e
instructions that Facebook provides for implementing "Client-side
authentication without the JS SDK" at
https://developers.facebook.com/docs/authentic= ation/client-side/#no-jssdk
still allows the attack.

Nat, I agree that the blog post by John Bradley that you link to
refers to the same vulnerability reported by Rui.=A0 You say that some
apps have issued a patch to fix it.=A0 Could you explain what the fix
was?

Francisco

=A0

From: Nat Sakimura <sakimura@gmail.com>
To: rui wang <ruiwangwarm@gmail.com>
Cc: matake nov <nov@matake.jp>; Yuchen Zhou <t-yuzhou@microsoft.com>; oauth <oauth@ietf.org>; Shuo Chen (MSR) <shuochen@microsoft.com>
Sent: Thursday, June 14, 2012 1:50 PM
Subject: Re: [OAUTH-WG] Report an authentication issue=

=A0

This is a fairly well known (hopefully by now) issue= . We, at the OpenID Foundation, call it "access_token phishing" a= ttack these days. See:=A0http://www.thread= -safe.com/2012/01/problem-with-oauth-for-authentication.html<= /u>

=A0

Nov Matake has actually built the code on iPhone to = verify the problem, and has notified bunch of parties back in February incl= uding Facebook and Apple. We have the code that actually runs on a phone, a= nd we have successfully logged in to bunch of apps, including very well known ones. They were all informed o= f the issue. Some immediately issued a patch to fix it while others have no= t. =A0

=A0

The problem is that even if these apps gets fixed, t= he problem does not go away. As long as the attacker has the vulnerable ver= sion of the app, he still can impersonate the victim. To stop it, the serve= r side has to completely disable the older version, which means the service has to cut off many users pausing b= usiness problems.=A0

=A0

Nat

On Fri, Jun 15, 2012 at 2:18 AM, rui wang <ruiwangwarm@gmail.com<= /a>> wrote:

Dear Facebook Security Team and OAuth Standard group= ,

Recently, we found a common misunderstanding among d= evelopers of mobile/metro apps when using OAuth (including Facebook=92s OAu= th) for authentication. The vulnerability resulted from this misunderstandi= ng also allows an attacker to log into a victim user's account without password.

Let's take Soluto's metro app as an example = to describe the problem. The app supports Facebook Login. As an attacker, w= e can write a regular Facebook app. Once the victim user allows our app to = access her Facebook data, we receive an access_token from the traffic. Then, on our own machine (i.e., the "attacker"= machine), we run the metro app of Soluto, and use a HTTP proxy to insert t= he victim's access_token into the traffic of Facebook login. Through th= is way, we are able to log into the victim's Soluto account from our machine. Other than Soluto, we also have confirmed the sa= me issue on another Windows 8 metro-app Givit.

The Facebook SDK for Android apps (https://developers.facebook.com/docs/mobile/android/build/#sdk) seems = to have the possibility to mislead developers too. At least, the issue that we found is not clearly mentioned. In the SD= K, we ran the sample code called "Hackbook" using Android Emulato= r (imagine it is an attacker device). Note that we have already received th= e access token of the victim user from our regular Facebook app. We then inject the token to the traffic of Hackbook.= Through this way, Hackbook app on our own machine recognizes us as the vic= tim. Note that this is not a convincing security exploit yet, because this = sample code does not include the server-side code. However, given that we have seen real server-side code h= aving this problem, such as Soluto, Givit and others, we do believe that th= e sample code can mislead mobile/metro developers. We also suspect that thi= s may be a general issue of many OAuth implementations on mobile platforms, so we send this message to OAut= h Standard group as well.

We have contacted the vendors of the two vulnerable = metro-apps, Soluto and Gavit.

Please kindly give us an ack when you receive this m= essage. If you want to know more details, please let us know.=

Best Regards,
Yuchen Zhou, Rui Wang, and Shuo Chen


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



=A0

--
Nat Sakimura (=3Dnat)

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

=A0


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




=A0

--
Nat Sakimura (=3Dnat)

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

=A0

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

=A0

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

=A0




_______________________________________________
OAuth mailing list
OAuth@ietf.org=

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



=A0
=A0
_______________________________________________
OAuth mailing list
OAuth@ietf.org=

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

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




--
Nat Saki= mura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
=
--000e0ce0d672ede81704c2f12719-- From hannes.tschofenig@gmx.net Thu Jun 21 02:27:44 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7137421F85B1 for ; Thu, 21 Jun 2012 02:27:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.206 X-Spam-Level: X-Spam-Status: No, score=-102.206 tagged_above=-999 required=5 tests=[AWL=-0.207, BAYES_00=-2.599, J_CHICKENPOX_65=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qAFOByfOxQuP for ; Thu, 21 Jun 2012 02:27:43 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id D490721F8592 for ; Thu, 21 Jun 2012 02:27:42 -0700 (PDT) Received: (qmail invoked by alias); 21 Jun 2012 09:27:40 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.101]) [88.115.216.191] by mail.gmx.net (mp035) with SMTP; 21 Jun 2012 11:27:40 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19z2HYeW71zkLPeVNXYyd72WyBECF/JC8nZBvz3BE +NFW23fR26WKEI Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Hannes Tschofenig In-Reply-To: Date: Thu, 21 Jun 2012 12:27:36 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <854774286EF8A240BACC342973A86EAC016693D6@BL2PRD0310MB387.namprd03.prod.outlook.com> <484A13D0-7C9A-42CC-BB94-3657741834DE@ve7jtb.com> <82D95BA2-1697-4441-BBB3-B2AE480DC39E@gmail.com> To: John Bradley X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: rui wang , Yuchen Zhou , "Shuo Chen \(MSR\)" , Derek Atkins , "oauth@ietf.org" Subject: Re: [OAUTH-WG] proposal of a paragraph to add to the security considerations section X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 09:27:44 -0000 Hi John,=20 I read through your blog post. I am not sure whether I can entirely = agree with your separation between authentication and authorization. I = believe the core issue here is that=20 * anyone who has the token will get access to whatever the token = entitles him or her to do (unless there are restrictions in the token) * some attributes are different than others. With authentication you = typically associate that the process took place recently (i.e., it is = fresh) while other attributes do not require the user (as resource = owner) to actively participate in the exchange and the same level of = freshness is not implied. For authentication in a three party protocol = to be useful the three parties have to participate (see = http://tools.ietf.org/id/draft-tschofenig-oauth-signature-thoughts-00.txt)= .=20 I understand that one wants to avoid having tokens passed around from = one application to the other one, as it is happening here.=20 I remember having some of these discussions with Eran a long time ago. = He anticipated that implementers will not put any constraints in the = tokens and hence they will be misused. This serves as an argument for = him to propose the MAC token specification.=20 I proposed text for the security consideration section of the bearer = document a while ago and it even talks about audience restriction as a = recommendation.=20 There are two problems with the audience restriction:=20 1) There is no mandatory token format defined nor do we mandate token = content either. Hence we do not strongly require anything specifically = to be put into the tokens.=20 2) In the implicit grant flow the client isn't authenticated and hence = what do you want to put into a token as an audience restriction?=20 Finally, I think that the "audience restriction" terminology is a bit = fuzzy for this discussion either.=20 Audience restriction can mean two things: * Allowing the client to verify that the access token has indeed been = issued for him / her.=20 * Allowing the resource server verify that the received access token = from a specific client has indeed been provided by that client.=20 My current believe is that the implicit grant flow is unsuitable for = providing authentication functionality.=20 Ciao Hannes On Jun 19, 2012, at 5:50 AM, John Bradley wrote: > I can put something together. =20 >=20 > It is mostly a warning about the token substitution attack that any = implicit flow is vulnerable to if used for authentication of the = presenter. > Otherwise known as why audience restriction is a good thing. >=20 > John B. >=20 > On 2012-06-18, at 8:20 PM, Dick Hardt wrote: >=20 >> John >>=20 >> Do you have suggested text per your suggestion below? >>=20 >> -- Dick >>=20 >> On Jun 18, 2012, at 2:04 PM, John Bradley wrote: >>=20 >>> I blogged about this in the hypothetical several months ago. = http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.h= tml >>>=20 >>> Nov Matake and others built some tests and found quite a number of = deployments vulnerable.=20 >>> = http://www.thread-safe.com/2012/02/more-on-oauth-implicit-flow-application= .html >>>=20 >>> The bottom line is that OAuth has no explicit audience restriction = for tokens, hence accepting any token outside of the code flow is = subject to attack. >>>=20 >>> In general it is not a issue for authorization, it is however a big = issue then there is a presumption that the presenter of a token that = grants a client access to resource x is the "resource owner" of resource = x, when it is possible that the presenter is any client who has ever had = a access token for resource x. >>>=20 >>> We might want to include the why it is insecure in the security = consideration, otherwise people reading the below will likely ignore = the advice as it seems on the surface a touch extreme. >>>=20 >>> There are certainly OAuth flows that allow you to do authentication = safely, just not all of them without additional precautions. >>>=20 >>> That is why openID Connect has a audience restricted id_token = similar to Facebook's signed request to allow the implicit flows to be = safely used for authentication. >>>=20 >>> John B. >>>=20 >>>=20 >>>=20 >>>=20 >>> On 2012-06-18, at 4:19 PM, Shuo Chen (MSR) wrote: >>>=20 >>>> Hi OAuth group, >>>> =20 >>>> This is regarding the recent discussion about an implementation = issue of some cloud services using OAuth for authentication. >>>> Derek Atkins and Dick Hardt suggested the possibility to discuss = with the group a paragraph to add to the security considerations = section. >>>> =20 >>>> Derek=92s suggestion: >>>> =3D=3D=3D=3D =3D=3D=3D =3D=3D=3D =3D=3D=3D >>>> >> Perhaps you could boil it down to a paragraph >>>> >> or two for addition to the security considerations section that = basically says >>>> >> "beware of implementing it *this* way because it leads to *that* = attack vector", etc. >>>> =3D=3D=3D=3D =3D=3D=3D =3D=3D=3D =3D=3D=3D >>>> =20 >>>> =20 >>>> Here is out suggested text: >>>> =3D=3D=3D=3D =3D=3D=3D =3D=3D=3D =3D=3D=3D >>>> It has been observed that in multiple occasions that the = server-side >>>> authentication logic takes an access token from the client, then >>>> queries the user's profile data from the IdP in order to >>>> "authenticate" the user. This implementation must be forbidden. It >>>> will allow an untrusted app running on a victim=92s client device = to >>>> work with an attacker=92s device to sign into the victim=92s = account on the server side. >>>> =3D=3D=3D=3D =3D=3D=3D =3D=3D=3D =3D=3D=3D >>>> =20 >>>> =20 >>>> Thank you. >>>> -Shuo >>>> p.s. below is the email thread giving a better context of the = discussion. >>>> =20 >>>> =20 >>>> > -----Original Message----- >>>> > From: Derek Atkins [mailto:derek@ihtfp.com] >>>> > Sent: Monday, June 18, 2012 11:25 AM >>>> > To: Shuo Chen (MSR) >>>> > Cc: Hannes Tschofenig; rui wang; Stephen Farrell; Yuchen Zhou; = Derek >>>> > Atkins; Dick Hardt >>>> > Subject: Re: [OAUTH-WG] web sso study... >>>> >=20 >>>> > Hi, >>>> >=20 >>>> > "Shuo Chen (MSR)" writes: >>>> >=20 >>>> >> Hi Hannes, Derek and Stephen, >>>> >>=20 >>>> >> Thank you for your replies. >>>> >>=20 >>>> >>> First, let me ask whether it is OK if I share your post with = the >>>> >>> OAuth WG >>>> >>=20 >>>> >> Yes, please feel free to share it. >>>> >>=20 >>>> >>> Second, could you describe the attack in more details to me? >>>> >>=20 >>>> >> Let's consider the mobile+cloud scenario for concreteness = (although >>>> >> some other scenarios are also applicable). The attack steps are = the >>>> >> following: suppose Alice's tablet runs a Windows 8 Metro app = written >>>> >> by attacker Bob. This app is able to request and obtain an = access >>>> >> token from the IdP (associated with Alice). The app can then = send the >>>> >> access token to Bob's own tablet. Note that there is no security >>>> >> problem up to this point. However the real problem is that some = cloud >>>> >> services use the access token to query the user's profile data = from >>>> >> the IdP in order to "authenticate" the user. In this case, Bob's >>>> >> tablet will be able to sign into the cloud service as Alice. We = have >>>> >> confirmed that the cloud services for Soluto Metro App, Givit = Metro >>>> >> App and EuroCup2012 Metro App make this mistake. These are apps = in >>>> >> the official Windows 8 App Store. We actually sampled only a = small portion of the available apps, but believe this is a vulnerability = pattern. >>>> >>=20 >>>> >> We don=92t think there is anything wrong in the OAuth spec. It = is >>>> >> developers who didn=92t comprehensively understand the usage of = the >>>> >> access token. In the meanwhile, this vulnerability pattern is = not explicitly excluded by the spec. >>>> >> More importantly, it has been seen in the wild. >>>> >>=20 >>>> >>> [from Derek's email] Perhaps you could boil it down to a = paragraph >>>> >>> or two for >>>> >> addition to the security considerations section that basically = says >>>> >> "beware of implementing it *this* way because it leads to *that* = attack vector", etc. >>>> >>=20 >>>> >> This is a great idea. I think that although it is difficult to >>>> >> anticipate in general all kinds of incomprehensive = understandings of >>>> >> average developers, it is very worthwhile to take any common = existing >>>> >> vulnerability pattern as a precious feedback to improve the >>>> >> specification text. In this case, since we have already seen = this >>>> >> vulnerability pattern on multiple services in the wild, = certainly we >>>> >> should be explicit about it in the security considerations = section. >>>> >>=20 >>>> >> Our suggested text: >>>> >>=20 >>>> >> It has been observed that in multiple occasions that the = server-side >>>> >> authentication logic takes an access token from the client, then >>>> >> queries the user's profile data from the IdP in order to >>>> >> "authenticate" the user. This implementation must be forbidden. = It >>>> >> will allow an untrusted app running on a victim=92s client = device to >>>> >> work with an attacker=92s device to sign into the victim=92s = account on the server side. >>>> >>=20 >>>> >> Any questions or suggestions? >>>> >=20 >>>> > Could you please send this to the oauth@ietf.org mailing list? >>>> >=20 >>>> >> Thanks a lot. >>>> >>=20 >>>> >> -Shuo >>>> >=20 >>>> > -derek >>>> >=20 >>>> >> -----Original Message----- >>>> >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>> >> Sent: Friday, June 15, 2012 11:36 AM >>>> >> To: rui wang >>>> >> Cc: Hannes Tschofenig; Stephen Farrell; Shuo Chen (MSR); Yuchen = Zhou; >>>> >> Derek Atkins >>>> >> Subject: Re: [OAUTH-WG] web sso study... >>>> >>=20 >>>> >> Hi Rui, >>>> >>=20 >>>> >> let me independently respond (in addition to the previous = responses >>>> >> you had already gotten). >>>> >>=20 >>>> >> First, let me ask whether it is OK if I share your post with the >>>> >> OAuth WG since it is more detailed than the one you distributed = on the list mid April. >>>> >>=20 >>>> >> Second, could you describe the attack in more details to me? = What I >>>> >> would like to better understand whether this the raised issue is = a >>>> >> problem with one of our specifications, with a specific >>>> >> implementation of the IETF OAuth specifications, a problem with = other >>>> >> OAuth related work (Facebook, as you know, implements far more = than >>>> >> just the IETF OAuth specifications), a violation of the IETF = OAuth >>>> >> specification in the way how the Websites use OAuth, whether = this is >>>> >> a configuration related aspect, or an aspect we already = documented in the threats document. >>>> >>=20 >>>> >> The reason why I am so specific is to know where to put text to >>>> >> address this issue or whether this is even an issue beyond the = IETF >>>> >> OAuth working group and needs to be tackled somewhere else. >>>> >>=20 >>>> >> Ciao >>>> >>=20 >>>> >> Hannes >>>> >> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From ve7jtb@ve7jtb.com Thu Jun 21 06:47:40 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D26B21F8655 for ; Thu, 21 Jun 2012 06:47:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.208 X-Spam-Level: X-Spam-Status: No, score=-3.208 tagged_above=-999 required=5 tests=[AWL=-0.210, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_65=0.6, 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 Gesedbhg3ER3 for ; Thu, 21 Jun 2012 06:47:38 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id D03D821F8646 for ; Thu, 21 Jun 2012 06:47:37 -0700 (PDT) Received: by ggnc4 with SMTP id c4so527334ggn.31 for ; Thu, 21 Jun 2012 06:47:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=HfrJ9aMmvVEYSIJIEpkRtRoXVLcBadEtk8Wk+qv5W/E=; b=fYFz6nUdoJm4K5v1utx62hfKbOzV1Dm2/9aw86CgUKrt6pQ1AQ7xVhfwJ9NLllqPEq qkoBh7NQxBHPdmF+vFqsn14L55rMxWQ8yrJgdd/o9KgIUjyIqnQzjw87W8x/9qJxNdMS W5/zC+j08G4KU8O2lIUd+M2d7PVKA/n+RFbV1t4JEodFdoc6wlPjM4DOGSUZlcAQbZT7 NEtx5VNSkG8npC8kaS1NVkK9kP/ROPE8ikL8sERFrdCLQeIXSngV2OqNTexfeSCYFFuS pte03eiInMM+KfLYgZc+glTe3bokHUOKOVMxgPtzXdST+XZ6KtHxfMtvdWOjjW8luRSu vgKA== Received: by 10.236.184.170 with SMTP id s30mr21531397yhm.122.1340286457265; Thu, 21 Jun 2012 06:47:37 -0700 (PDT) Received: from [192.168.1.213] ([190.20.13.0]) by mx.google.com with ESMTPS id b58sm107396722yhh.16.2012.06.21.06.47.30 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 21 Jun 2012 06:47:36 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_F6FE03F2-F07D-428B-A233-4250B1F54163"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: Date: Thu, 21 Jun 2012 09:47:23 -0400 Message-Id: References: <854774286EF8A240BACC342973A86EAC016693D6@BL2PRD0310MB387.namprd03.prod.outlook.com> <484A13D0-7C9A-42CC-BB94-3657741834DE@ve7jtb.com> <82D95BA2-1697-4441-BBB3-B2AE480DC39E@gmail.com> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQmN/UTvrR9lbFAnA9Nle66kb+Rjfhl3RN13nzSom55ez4+WbIUO7KilyCcMpO/J7s+X4rN9 Cc: rui wang , Yuchen Zhou , "Shuo Chen \(MSR\)" , Derek Atkins , "oauth@ietf.org" Subject: Re: [OAUTH-WG] proposal of a paragraph to add to the security considerations section X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 13:47:40 -0000 --Apple-Mail=_F6FE03F2-F07D-428B-A233-4250B1F54163 Content-Type: multipart/alternative; boundary="Apple-Mail=_980B3851-3CF3-4DF6-880F-5DBE9FFC1C87" --Apple-Mail=_980B3851-3CF3-4DF6-880F-5DBE9FFC1C87 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Hannes, MAC tokens protect resources against token leakage to third parties. = That is useful but a different threat. =20 The easiest way to get a access token for someone is to have them log = into your site. =20 If you can do that the token type makes no difference unless we move to = a asymmetric holder of key token (different discussion). The bad client gets the access MAC token and token secret and can re use = it just as it would a bearer token. The origin of the post was a contention by someone at Facebook that = profiling OAuth 2.0 on its own is sufficient to produce an = Authentication protocol. I was trying to point out that OAuth 2 without any extensions, only = profiling is difficult to impossible to use for authentication as the = attack surface and security considerations are different. As it turned out Facebook had extended OAuth 2 with signed requests and = token introspection techniques to address these issues for themselves. =20= The problem as it turned out was that individual apps and app = frameworks like the iOS one made some bad mistakes, by not using the = perhaps under documented extensions. The problem is not unique to Facebook in any way they are just a = convenient example. Oauth 2 is not surprisingly mostly about protecting the resource. =20 Authentication is about protecting the client. Audience restriction from openID 2, SAML, WS* etc prevents replay of = tokens issued to one RP/SP at another. =20 That is sort of authentication protocol threat number 1. OAuth has no way to do that with access tokens. It can however do it with "code" if the client is confidential. So my recommendation is that without extensions to OAuth like structured = tokens (signed_request, id_token) or token introspection endpoints like=20= Facebook ( https://graph.facebook.com/app?access_token=3D[The Access = Token]), there is no safe way to use an implicit flow for = authentication. A code flow where a native app exchanges code for the access token and = then passes the access token back to it's server is also vulnerable = (lots of this in circulation I understand) The only safe flow (without extensions) is the code flow where the = client is confidential and the code is directly exchanged for the access = token. This also requires the definition of a identity API that is protected by = the access token, and out of scope for OAuth. So at the end of the day the rational conclusion is that OAuth 2 is a = authorization protocol. =20 It may be used by Authentication protocols, but it is up to other specs = to define the security considerations for that. That however doesn't remove the need to mention the token substitution = attack that non confidential clients are subject to, do to there being = no other mechanism for the client to know who the token was issued to. John B. On 2012-06-21, at 5:27 AM, Hannes Tschofenig wrote: > Hi John,=20 >=20 > I read through your blog post. I am not sure whether I can entirely = agree with your separation between authentication and authorization. I = believe the core issue here is that=20 >=20 > * anyone who has the token will get access to whatever the token = entitles him or her to do (unless there are restrictions in the token) >=20 > * some attributes are different than others. With authentication you = typically associate that the process took place recently (i.e., it is = fresh) while other attributes do not require the user (as resource = owner) to actively participate in the exchange and the same level of = freshness is not implied. For authentication in a three party protocol = to be useful the three parties have to participate (see = http://tools.ietf.org/id/draft-tschofenig-oauth-signature-thoughts-00.txt)= .=20 >=20 > I understand that one wants to avoid having tokens passed around from = one application to the other one, as it is happening here.=20 >=20 > I remember having some of these discussions with Eran a long time ago. = He anticipated that implementers will not put any constraints in the = tokens and hence they will be misused. This serves as an argument for = him to propose the MAC token specification.=20 >=20 > I proposed text for the security consideration section of the bearer = document a while ago and it even talks about audience restriction as a = recommendation.=20 >=20 > There are two problems with the audience restriction:=20 >=20 > 1) There is no mandatory token format defined nor do we mandate token = content either. Hence we do not strongly require anything specifically = to be put into the tokens.=20 >=20 > 2) In the implicit grant flow the client isn't authenticated and hence = what do you want to put into a token as an audience restriction?=20 >=20 > Finally, I think that the "audience restriction" terminology is a bit = fuzzy for this discussion either.=20 > Audience restriction can mean two things: >=20 > * Allowing the client to verify that the access token has indeed been = issued for him / her.=20 > * Allowing the resource server verify that the received access token = from a specific client has indeed been provided by that client.=20 >=20 > My current believe is that the implicit grant flow is unsuitable for = providing authentication functionality.=20 >=20 > Ciao > Hannes >=20 > On Jun 19, 2012, at 5:50 AM, John Bradley wrote: >=20 >> I can put something together. =20 >>=20 >> It is mostly a warning about the token substitution attack that any = implicit flow is vulnerable to if used for authentication of the = presenter. >> Otherwise known as why audience restriction is a good thing. >>=20 >> John B. >>=20 >> On 2012-06-18, at 8:20 PM, Dick Hardt wrote: >>=20 >>> John >>>=20 >>> Do you have suggested text per your suggestion below? >>>=20 >>> -- Dick >>>=20 >>> On Jun 18, 2012, at 2:04 PM, John Bradley wrote: >>>=20 >>>> I blogged about this in the hypothetical several months ago. = http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.h= tml >>>>=20 >>>> Nov Matake and others built some tests and found quite a number of = deployments vulnerable.=20 >>>> = http://www.thread-safe.com/2012/02/more-on-oauth-implicit-flow-application= .html >>>>=20 >>>> The bottom line is that OAuth has no explicit audience restriction = for tokens, hence accepting any token outside of the code flow is = subject to attack. >>>>=20 >>>> In general it is not a issue for authorization, it is however a = big issue then there is a presumption that the presenter of a token that = grants a client access to resource x is the "resource owner" of resource = x, when it is possible that the presenter is any client who has ever had = a access token for resource x. >>>>=20 >>>> We might want to include the why it is insecure in the security = consideration, otherwise people reading the below will likely ignore = the advice as it seems on the surface a touch extreme. >>>>=20 >>>> There are certainly OAuth flows that allow you to do authentication = safely, just not all of them without additional precautions. >>>>=20 >>>> That is why openID Connect has a audience restricted id_token = similar to Facebook's signed request to allow the implicit flows to be = safely used for authentication. >>>>=20 >>>> John B. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On 2012-06-18, at 4:19 PM, Shuo Chen (MSR) wrote: >>>>=20 >>>>> Hi OAuth group, >>>>>=20 >>>>> This is regarding the recent discussion about an implementation = issue of some cloud services using OAuth for authentication. >>>>> Derek Atkins and Dick Hardt suggested the possibility to discuss = with the group a paragraph to add to the security considerations = section. >>>>>=20 >>>>> Derek=92s suggestion: >>>>> =3D=3D=3D=3D =3D=3D=3D =3D=3D=3D =3D=3D=3D >>>>>>> Perhaps you could boil it down to a paragraph >>>>>>> or two for addition to the security considerations section that = basically says >>>>>>> "beware of implementing it *this* way because it leads to *that* = attack vector", etc. >>>>> =3D=3D=3D=3D =3D=3D=3D =3D=3D=3D =3D=3D=3D >>>>>=20 >>>>>=20 >>>>> Here is out suggested text: >>>>> =3D=3D=3D=3D =3D=3D=3D =3D=3D=3D =3D=3D=3D >>>>> It has been observed that in multiple occasions that the = server-side >>>>> authentication logic takes an access token from the client, then >>>>> queries the user's profile data from the IdP in order to >>>>> "authenticate" the user. This implementation must be forbidden. It >>>>> will allow an untrusted app running on a victim=92s client device = to >>>>> work with an attacker=92s device to sign into the victim=92s = account on the server side. >>>>> =3D=3D=3D=3D =3D=3D=3D =3D=3D=3D =3D=3D=3D >>>>>=20 >>>>>=20 >>>>> Thank you. >>>>> -Shuo >>>>> p.s. below is the email thread giving a better context of the = discussion. >>>>>=20 >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Derek Atkins [mailto:derek@ihtfp.com] >>>>>> Sent: Monday, June 18, 2012 11:25 AM >>>>>> To: Shuo Chen (MSR) >>>>>> Cc: Hannes Tschofenig; rui wang; Stephen Farrell; Yuchen Zhou; = Derek >>>>>> Atkins; Dick Hardt >>>>>> Subject: Re: [OAUTH-WG] web sso study... >>>>>>=20 >>>>>> Hi, >>>>>>=20 >>>>>> "Shuo Chen (MSR)" writes: >>>>>>=20 >>>>>>> Hi Hannes, Derek and Stephen, >>>>>>>=20 >>>>>>> Thank you for your replies. >>>>>>>=20 >>>>>>>> First, let me ask whether it is OK if I share your post with = the >>>>>>>> OAuth WG >>>>>>>=20 >>>>>>> Yes, please feel free to share it. >>>>>>>=20 >>>>>>>> Second, could you describe the attack in more details to me? >>>>>>>=20 >>>>>>> Let's consider the mobile+cloud scenario for concreteness = (although >>>>>>> some other scenarios are also applicable). The attack steps are = the >>>>>>> following: suppose Alice's tablet runs a Windows 8 Metro app = written >>>>>>> by attacker Bob. This app is able to request and obtain an = access >>>>>>> token from the IdP (associated with Alice). The app can then = send the >>>>>>> access token to Bob's own tablet. Note that there is no security >>>>>>> problem up to this point. However the real problem is that some = cloud >>>>>>> services use the access token to query the user's profile data = from >>>>>>> the IdP in order to "authenticate" the user. In this case, Bob's >>>>>>> tablet will be able to sign into the cloud service as Alice. We = have >>>>>>> confirmed that the cloud services for Soluto Metro App, Givit = Metro >>>>>>> App and EuroCup2012 Metro App make this mistake. These are apps = in >>>>>>> the official Windows 8 App Store. We actually sampled only a = small portion of the available apps, but believe this is a vulnerability = pattern. >>>>>>>=20 >>>>>>> We don=92t think there is anything wrong in the OAuth spec. It = is >>>>>>> developers who didn=92t comprehensively understand the usage of = the >>>>>>> access token. In the meanwhile, this vulnerability pattern is = not explicitly excluded by the spec. >>>>>>> More importantly, it has been seen in the wild. >>>>>>>=20 >>>>>>>> [from Derek's email] Perhaps you could boil it down to a = paragraph >>>>>>>> or two for >>>>>>> addition to the security considerations section that basically = says >>>>>>> "beware of implementing it *this* way because it leads to *that* = attack vector", etc. >>>>>>>=20 >>>>>>> This is a great idea. I think that although it is difficult to >>>>>>> anticipate in general all kinds of incomprehensive = understandings of >>>>>>> average developers, it is very worthwhile to take any common = existing >>>>>>> vulnerability pattern as a precious feedback to improve the >>>>>>> specification text. In this case, since we have already seen = this >>>>>>> vulnerability pattern on multiple services in the wild, = certainly we >>>>>>> should be explicit about it in the security considerations = section. >>>>>>>=20 >>>>>>> Our suggested text: >>>>>>>=20 >>>>>>> It has been observed that in multiple occasions that the = server-side >>>>>>> authentication logic takes an access token from the client, then >>>>>>> queries the user's profile data from the IdP in order to >>>>>>> "authenticate" the user. This implementation must be forbidden. = It >>>>>>> will allow an untrusted app running on a victim=92s client = device to >>>>>>> work with an attacker=92s device to sign into the victim=92s = account on the server side. >>>>>>>=20 >>>>>>> Any questions or suggestions? >>>>>>=20 >>>>>> Could you please send this to the oauth@ietf.org mailing list? >>>>>>=20 >>>>>>> Thanks a lot. >>>>>>>=20 >>>>>>> -Shuo >>>>>>=20 >>>>>> -derek >>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>>>> Sent: Friday, June 15, 2012 11:36 AM >>>>>>> To: rui wang >>>>>>> Cc: Hannes Tschofenig; Stephen Farrell; Shuo Chen (MSR); Yuchen = Zhou; >>>>>>> Derek Atkins >>>>>>> Subject: Re: [OAUTH-WG] web sso study... >>>>>>>=20 >>>>>>> Hi Rui, >>>>>>>=20 >>>>>>> let me independently respond (in addition to the previous = responses >>>>>>> you had already gotten). >>>>>>>=20 >>>>>>> First, let me ask whether it is OK if I share your post with the >>>>>>> OAuth WG since it is more detailed than the one you distributed = on the list mid April. >>>>>>>=20 >>>>>>> Second, could you describe the attack in more details to me? = What I >>>>>>> would like to better understand whether this the raised issue is = a >>>>>>> problem with one of our specifications, with a specific >>>>>>> implementation of the IETF OAuth specifications, a problem with = other >>>>>>> OAuth related work (Facebook, as you know, implements far more = than >>>>>>> just the IETF OAuth specifications), a violation of the IETF = OAuth >>>>>>> specification in the way how the Websites use OAuth, whether = this is >>>>>>> a configuration related aspect, or an aspect we already = documented in the threats document. >>>>>>>=20 >>>>>>> The reason why I am so specific is to know where to put text to >>>>>>> address this issue or whether this is even an issue beyond the = IETF >>>>>>> OAuth working group and needs to be tackled somewhere else. >>>>>>>=20 >>>>>>> Ciao >>>>>>>=20 >>>>>>> Hannes >>>>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 --Apple-Mail=_980B3851-3CF3-4DF6-880F-5DBE9FFC1C87 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = Hannes,

MAC tokens protect resources against token = leakage to third parties.  That is useful but a different threat. =  

The easiest way to get a access token = for someone is to have them log into your site. =   

If you can do that the token type = makes no difference unless we move to a asymmetric holder of key token = (different discussion).

The bad client gets the = access MAC token and token secret and can re use it just as it would a = bearer token.

The origin of the post was a = contention by someone at Facebook that profiling OAuth 2.0 on its own is = sufficient to produce an Authentication = protocol.

I was trying to point out that OAuth = 2 without any extensions, only profiling is difficult to impossible to = use for authentication as the attack surface and security considerations = are different.

As it turned out Facebook had = extended OAuth 2 with signed requests and token introspection techniques = to address these issues for themselves. =   

The problem as it turned out was = that individual apps and  app frameworks like the iOS one made some = bad mistakes, by not using the perhaps under documented = extensions.

The problem is not unique to = Facebook in any way they are just a convenient = example.

Oauth 2  is not = surprisingly mostly about protecting the resource. =  

Authentication is about protecting the = client.

Audience restriction from openID 2, = SAML,  WS* etc prevents replay of tokens issued to one RP/SP at = another.  
That is sort of authentication protocol threat = number 1.

OAuth has no way to do that with = access tokens.

It can however do it with "code" = if the client is confidential.

So my = recommendation is that without extensions to OAuth like structured = tokens (signed_request, id_token) or token introspection endpoints = like 
Facebook ( https://graph.= facebook.com/app?access_token=3D[The Access Token]), there is no safe way to use an implicit flow for = authentication.
A code flow where a native app exchanges = code for the access token and then passes the access token back to it's = server is also vulnerable (lots of this in circulation I = understand)

The only safe = flow (without extensions) is the code flow where the client is = confidential and the code is directly exchanged for the access = token.
This also requires the definition of a = identity API that is protected by the access token, and out of scope for = OAuth.

So at the end of = the day the rational conclusion is that OAuth 2 is a authorization = protocol.   
It may be used by Authentication protocols, = but it is up to other specs to define the security considerations for = that.

That however = doesn't remove the need to mention the token substitution attack that = non confidential clients are subject to, do to there being no other = mechanism for the client to know who the token was issued = to.

John = B.





On 2012-06-21, at 5:27 AM, Hannes Tschofenig = wrote:

Hi John,

I read through your blog post. I am = not sure whether I can entirely agree with your separation between = authentication and authorization. I believe the core issue here is that =

* anyone who has the token will get access to whatever the token = entitles him or her to do (unless there are restrictions in the = token)

* some attributes are different than others. With = authentication you typically associate that the process took place = recently (i.e., it is fresh) while other attributes do not require the = user (as resource owner) to actively participate in the exchange and the = same level of freshness is not implied.  For authentication in a = three party protocol to be useful the three parties have to participate = (see http://tools.ietf.org/id/draft-tschofenig-oauth-signature-thought= s-00.txt).

I understand that one wants to avoid having = tokens passed around from one application to the other one, as it is = happening here.

I remember having some of these discussions with = Eran a long time ago. He anticipated that implementers will not put any = constraints in the tokens and hence they will be misused. This serves as = an argument for him to propose the MAC token specification.

I = proposed text for the security consideration section of the bearer = document a while ago and it even talks about audience restriction as a = recommendation.

There are two problems with the audience = restriction:

1) There is no mandatory token format defined nor = do we mandate token content either. Hence we do not strongly require = anything specifically to be put into the tokens.

2) In the = implicit grant flow the client isn't authenticated and hence what do you = want to put into a token as an audience restriction?

Finally, I = think that the "audience restriction" terminology is a bit fuzzy for = this discussion either.
Audience restriction can mean two = things:

* Allowing the client to verify that the access token has = indeed been issued for him / her.
* Allowing the resource server = verify that the received access token from a specific client has indeed = been provided by that client.

My current believe is that the = implicit grant flow is unsuitable for providing authentication = functionality.

Ciao
Hannes

On Jun 19, 2012, at 5:50 = AM, John Bradley wrote:

I can put = something together.   

It is mostly a = warning about the token substitution attack that any implicit flow is = vulnerable to if used for authentication of the = presenter.
Otherwise known as = why audience restriction is a good thing.

John = B.

On 2012-06-18, at 8:20 PM, Dick Hardt = wrote:

John

Do you have suggested text per = your suggestion below?

-- = Dick

On Jun 18, 2012, at 2:04 PM, = John Bradley wrote:

I = blogged about this in the hypothetical several months ago. http://www.thread-safe.com/2012/01/problem-with-oauth-for-aut= hentication.html

Nov = Matake and others built some tests and found quite a number of = deployments vulnerable. =
http://www.thread-safe.com/2012/02/more-on-oauth-implicit-f= low-application.html

The = bottom line is that OAuth has no explicit audience restriction for = tokens,  hence accepting any token outside of the code flow is = subject to attack.

In = general it is not a issue for authorization,  it is however a big = issue then there is a presumption that the presenter of a token that = grants a client access to resource x is the "resource owner" of resource = x, when it is possible that the presenter is any client who has ever had = a access token for resource = x.

We = might want to include the why it is insecure in the security = consideration,  otherwise people reading the below will likely = ignore the advice as it seems on the surface a touch = extreme.

There = are certainly OAuth flows that allow you to do authentication safely, =  just not all of them without additional = precautions.

That = is why openID Connect has a audience restricted id_token similar to = Facebook's signed request to allow the implicit flows to be safely used = for = authentication.

John = B.




On = 2012-06-18, at 4:19 PM, Shuo Chen (MSR) = wrote:

Hi OAuth = group,

This is regarding the recent = discussion about an implementation issue of some cloud services using = OAuth for = authentication.
Derek Atkins and Dick Hardt = suggested the possibility to discuss with the group a paragraph to add = to the security considerations = section.

Derek=92s = suggestion:
=3D=3D=3D=3D   =3D=3D=3D=  =3D=3D=3D =  =3D=3D=3D
Perhaps you could boil it down = to a = paragraph
or two = for addition to the security considerations section that basically = says
<= /blockquote>
"beware = of implementing it *this* way because it leads to *that* attack vector", = etc.
<= /blockquote>
=3D=3D=3D= =3D   =3D=3D=3D  =3D=3D=3D =  =3D=3D=3D


Here is out suggested = text:
=3D=3D=3D=3D   =3D=3D=3D=  =3D=3D=3D =  =3D=3D=3D
It has been observed that in = multiple occasions that the = server-side
authentication logic takes an = access token from the client, = then
queries the user's profile data = from the IdP in order = to
"authenticate" the user. This = implementation must be forbidden. = It
will allow an untrusted app = running on a victim=92s client device = to
work with an attacker=92s device = to sign into the victim=92s account on the server = side.
=3D=3D=3D=3D   =3D=3D=3D=  =3D=3D=3D =  =3D=3D=3D


Thank = you.
-Shuo
p.s. below is the email thread = giving a better context of the = discussion.


-----Original = Message-----
From: = Derek Atkins = [mailto:derek@ihtfp.com]
Sent: Monday, June 18, 2012 = 11:25 = AM
To: = Shuo Chen = (MSR)
=
Cc: = Hannes Tschofenig; rui wang; Stephen Farrell; Yuchen Zhou; = Derek
=
Atkins; = Dick = Hardt
=
Subject:= Re: [OAUTH-WG] web sso = study...

Hi,
<= /blockquote>

"Shuo = Chen (MSR)" <shuochen@microsoft.com> = writes:

Hi Hannes, Derek and = Stephen,

Thank = you for your = replies.

First, let me ask whether it is = OK if I share your post with = the
OAuth = WG

Yes, = please feel free to share = it.

Second, could you describe the = attack in more details to = me?

Let's = consider the mobile+cloud scenario for concreteness = (although
some = other scenarios are also applicable). The attack steps are = the
following: suppose Alice's = tablet runs a Windows 8 Metro app = written
by = attacker Bob. This app is able to request and obtain an = access
token = from the IdP (associated with Alice). The app can then send = the
access token to Bob's own = tablet. Note that there is no = security
problem = up to this point. However the real problem is that some = cloud
=
services= use the access token to query the user's profile data = from
<= /blockquote>
the = IdP in order to "authenticate" the user. In this case, = Bob's
=
tablet = will be able to sign into the cloud service as Alice. We = have
<= /blockquote>
confirmed that the cloud services for Soluto Metro App, = Givit = Metro
=
App = and EuroCup2012 Metro App make this mistake. These are apps = in
the official Windows 8 App = Store. We actually sampled only a small portion of the available apps, = but believe this is a vulnerability = pattern.

We = don=92t think there is anything wrong in the OAuth spec. It = is
developers who didn=92t = comprehensively understand the usage of = the
access token. In the meanwhile, = this vulnerability pattern is not explicitly excluded by the = spec.
=
More = importantly, it has been seen in the = wild.
=

[from Derek's email] Perhaps you = could boil it down to a = paragraph
or two = for
addition= to the security considerations section that basically = says
<= /blockquote>
"beware = of implementing it *this* way because it leads to *that* attack vector", = etc.
<= /blockquote>

This = is a great idea. I think that although it is difficult = to
anticipate in general all kinds = of incomprehensive understandings = of
average developers, it is very = worthwhile to take any common = existing
vulnerability pattern as a precious feedback to improve = the
specification text. In this = case, since we have already seen = this
<= /blockquote>
vulnerability pattern on multiple services in the wild, = certainly = we
should be explicit about it in = the security considerations = section.

Our = suggested = text:
=

It has = been observed that in multiple occasions that the = server-side
authentication logic takes an access token from the = client, = then
<= /blockquote>
queries = the user's profile data from the IdP in order = to
"authenticate" the user. This = implementation must be forbidden. = It
will allow an untrusted app = running on a victim=92s client device = to
work with an attacker=92s device = to sign into the victim=92s account on the server = side.
=

Any = questions or = suggestions?

Could = you please send this to the oauth@ietf.org mailing = list?
=

Thanks a = lot.
<= /blockquote>

-Shuo

-derek

-----Original = Message-----
From: = Hannes Tschofenig = [mailto:Hannes.Tschofenig@gmx.net]
Sent: Friday, June 15, 2012 = 11:36 = AM
To: rui = wang
<= /blockquote>
Cc: = Hannes Tschofenig; Stephen Farrell; Shuo Chen (MSR); Yuchen = Zhou;
=
Derek = Atkins
Subject:= Re: [OAUTH-WG] web sso = study...

Hi = Rui,
<= /blockquote>

let me = independently respond (in addition to the previous = responses
you = had already = gotten).

First, = let me ask whether it is OK if I share your post with = the
OAuth WG since it is more = detailed than the one you distributed on the list mid = April.

Second, = could you describe the attack in more details to me? What = I
would like to better understand = whether this the raised issue is = a
problem with one of our = specifications, with a = specific
implementation of the IETF OAuth specifications, a problem = with = other
=
OAuth = related work (Facebook, as you know, implements far more = than
<= /blockquote>
just = the IETF OAuth specifications), a violation of the IETF = OAuth
=
specification in the way how the Websites use OAuth, = whether this = is
a configuration related aspect, = or an aspect we already documented in the threats = document.

The = reason why I am so specific is to know where to put text = to
address this issue or whether = this is even an issue beyond the = IETF
<= /blockquote>
OAuth = working group and needs to be tackled somewhere = else.
=

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

= --Apple-Mail=_980B3851-3CF3-4DF6-880F-5DBE9FFC1C87-- --Apple-Mail=_F6FE03F2-F07D-428B-A233-4250B1F54163 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw 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+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDYy MTEzNDcyNFowIwYJKoZIhvcNAQkEMRYEFMfgRb1+BuJzcUkHqJ04/cOiEFShMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB AFo/enkIBCxEuoUeKBr8Wvyi73Ay9BfajP/UJ0G4RPES5wPmT0Rcbei64+SMpQtzx6FiBOGDk18S O30rlBrRo6Z7ScMxkJ6V1QFstWzsTgm9q3xLLqKu/XyMaqNfSSIE90advwrzKhbnNGy9N3ZXtRU6 db497SBy0A03EPFBsF2LLcZjE4Nd/3TojIofznjxc/DEEbNP4oomSyb8BceNW07pKxcG/3arcgzV sPNTPzerngViMe4rUao6829vhJZHKn9KOGB3cOtwemY+XTA/vY5Ma4vh1bHBKL8aLoNGwNfuFCSU QxnCt2xg+6X1vkTJcTkIqG27TONU2Z84ZZLBjaoAAAAAAAA= --Apple-Mail=_F6FE03F2-F07D-428B-A233-4250B1F54163-- From eran@hueniverse.com Thu Jun 21 07:17:18 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 694DE21F86C8 for ; Thu, 21 Jun 2012 07:17:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.68 X-Spam-Level: X-Spam-Status: No, score=-1.68 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_65=0.6, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j3g+6xzcbLkD for ; Thu, 21 Jun 2012 07:17:10 -0700 (PDT) Received: from p3plex2out03.prod.phx3.secureserver.net (p3plex2out03.prod.phx3.secureserver.net [184.168.131.16]) by ietfa.amsl.com (Postfix) with ESMTP id 38D0F21F85F6 for ; Thu, 21 Jun 2012 07:17:10 -0700 (PDT) Received: from P3PWEX2HT002.ex2.secureserver.net ([184.168.131.10]) by p3plex2out03.prod.phx3.secureserver.net with bizsmtp id R2H91j0030Dcg9U012H9zZ; Thu, 21 Jun 2012 07:17:09 -0700 Received: from P3PWEX2MB008.ex2.secureserver.net ([169.254.8.66]) by P3PWEX2HT002.ex2.secureserver.net ([184.168.131.10]) with mapi id 14.02.0247.003; Thu, 21 Jun 2012 07:17:08 -0700 From: Eran Hammer To: John Bradley , Hannes Tschofenig Thread-Topic: [OAUTH-WG] proposal of a paragraph to add to the security considerations section Thread-Index: AQHNT5AXwXFae/xfYU2UL7te1W8/5pcFPv2A//+SQXA= Date: Thu, 21 Jun 2012 14:17:08 +0000 Message-ID: <0CBAEB56DDB3A140BA8E8C124C04ECA20107B405@P3PWEX2MB008.ex2.secureserver.net> References: <854774286EF8A240BACC342973A86EAC016693D6@BL2PRD0310MB387.namprd03.prod.outlook.com> <484A13D0-7C9A-42CC-BB94-3657741834DE@ve7jtb.com> <82D95BA2-1697-4441-BBB3-B2AE480DC39E@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.163.44.6] Content-Type: multipart/alternative; boundary="_000_0CBAEB56DDB3A140BA8E8C124C04ECA20107B405P3PWEX2MB008ex2_" MIME-Version: 1.0 Cc: Yuchen Zhou , Derek Atkins , "Shuo Chen \(MSR\)" , rui wang , "oauth@ietf.org" Subject: Re: [OAUTH-WG] proposal of a paragraph to add to the security considerations section X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 14:17:18 -0000 --_000_0CBAEB56DDB3A140BA8E8C124C04ECA20107B405P3PWEX2MB008ex2_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The sad reality is, we've spent 3 years producing a specification that is l= ess secure, more complex, and does not interoperate the way OAuth 1.0 does. It does scale better for huge companies like Google, Microsoft, and Yahoo. = No wonder they wanted it this way. When asked, I tend to advise people using OAuth 1.0 to just keep using it. Oh well. EH From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of J= ohn Bradley Sent: Thursday, June 21, 2012 6:47 AM To: Hannes Tschofenig Cc: rui wang; Yuchen Zhou; Shuo Chen (MSR); Derek Atkins; oauth@ietf.org Subject: Re: [OAUTH-WG] proposal of a paragraph to add to the security cons= iderations section Hi Hannes, MAC tokens protect resources against token leakage to third parties. That = is useful but a different threat. The easiest way to get a access token for someone is to have them log into = your site. If you can do that the token type makes no difference unless we move to a a= symmetric holder of key token (different discussion). The bad client gets the access MAC token and token secret and can re use it= just as it would a bearer token. The origin of the post was a contention by someone at Facebook that profili= ng OAuth 2.0 on its own is sufficient to produce an Authentication protocol= . I was trying to point out that OAuth 2 without any extensions, only profili= ng is difficult to impossible to use for authentication as the attack surfa= ce and security considerations are different. As it turned out Facebook had extended OAuth 2 with signed requests and tok= en introspection techniques to address these issues for themselves. The problem as it turned out was that individual apps and app frameworks l= ike the iOS one made some bad mistakes, by not using the perhaps under docu= mented extensions. The problem is not unique to Facebook in any way they are just a convenient= example. Oauth 2 is not surprisingly mostly about protecting the resource. Authentication is about protecting the client. Audience restriction from openID 2, SAML, WS* etc prevents replay of token= s issued to one RP/SP at another. That is sort of authentication protocol threat number 1. OAuth has no way to do that with access tokens. It can however do it with "code" if the client is confidential. So my recommendation is that without extensions to OAuth like structured to= kens (signed_request, id_token) or token introspection endpoints like Facebook ( https://graph.facebook.com/app?access_token=3D[The Access Token]), there is no safe w= ay to use an implicit flow for authentication. A code flow where a native app exchanges code for the access token and then= passes the access token back to it's server is also vulnerable (lots of th= is in circulation I understand) The only safe flow (without extensions) is the code flow where the client i= s confidential and the code is directly exchanged for the access token. This also requires the definition of a identity API that is protected by th= e access token, and out of scope for OAuth. So at the end of the day the rational conclusion is that OAuth 2 is a autho= rization protocol. It may be used by Authentication protocols, but it is up to other specs to = define the security considerations for that. That however doesn't remove the need to mention the token substitution atta= ck that non confidential clients are subject to, do to there being no other= mechanism for the client to know who the token was issued to. John B. On 2012-06-21, at 5:27 AM, Hannes Tschofenig wrote: Hi John, I read through your blog post. I am not sure whether I can entirely agree w= ith your separation between authentication and authorization. I believe the= core issue here is that * anyone who has the token will get access to whatever the token entitles h= im or her to do (unless there are restrictions in the token) * some attributes are different than others. With authentication you typica= lly associate that the process took place recently (i.e., it is fresh) whil= e other attributes do not require the user (as resource owner) to actively = participate in the exchange and the same level of freshness is not implied.= For authentication in a three party protocol to be useful the three parti= es have to participate (see http://tools.ietf.org/id/draft-tschofenig-oauth= -signature-thoughts-00.txt). I understand that one wants to avoid having tokens passed around from one a= pplication to the other one, as it is happening here. I remember having some of these discussions with Eran a long time ago. He a= nticipated that implementers will not put any constraints in the tokens and= hence they will be misused. This serves as an argument for him to propose = the MAC token specification. I proposed text for the security consideration section of the bearer docume= nt a while ago and it even talks about audience restriction as a recommenda= tion. There are two problems with the audience restriction: 1) There is no mandatory token format defined nor do we mandate token conte= nt either. Hence we do not strongly require anything specifically to be put= into the tokens. 2) In the implicit grant flow the client isn't authenticated and hence what= do you want to put into a token as an audience restriction? Finally, I think that the "audience restriction" terminology is a bit fuzzy= for this discussion either. Audience restriction can mean two things: * Allowing the client to verify that the access token has indeed been issue= d for him / her. * Allowing the resource server verify that the received access token from a= specific client has indeed been provided by that client. My current believe is that the implicit grant flow is unsuitable for provid= ing authentication functionality. Ciao Hannes On Jun 19, 2012, at 5:50 AM, John Bradley wrote: I can put something together. It is mostly a warning about the token substitution attack that any implici= t flow is vulnerable to if used for authentication of the presenter. Otherwise known as why audience restriction is a good thing. John B. On 2012-06-18, at 8:20 PM, Dick Hardt wrote: John Do you have suggested text per your suggestion below? -- Dick On Jun 18, 2012, at 2:04 PM, John Bradley wrote: I blogged about this in the hypothetical several months ago. http://www.thr= ead-safe.com/2012/01/problem-with-oauth-for-authentication.html Nov Matake and others built some tests and found quite a number of deployme= nts vulnerable. http://www.thread-safe.com/2012/02/more-on-oauth-implicit-flow-application.= html The bottom line is that OAuth has no explicit audience restriction for toke= ns, hence accepting any token outside of the code flow is subject to attac= k. In general it is not a issue for authorization, it is however a big issue = then there is a presumption that the presenter of a token that grants a cli= ent access to resource x is the "resource owner" of resource x, when it is = possible that the presenter is any client who has ever had a access token f= or resource x. We might want to include the why it is insecure in the security considerati= on, otherwise people reading the below will likely ignore the advice as it= seems on the surface a touch extreme. There are certainly OAuth flows that allow you to do authentication safely,= just not all of them without additional precautions. That is why openID Connect has a audience restricted id_token similar to Fa= cebook's signed request to allow the implicit flows to be safely used for a= uthentication. John B. On 2012-06-18, at 4:19 PM, Shuo Chen (MSR) wrote: Hi OAuth group, This is regarding the recent discussion about an implementation issue of so= me cloud services using OAuth for authentication. Derek Atkins and Dick Hardt suggested the possibility to discuss with the g= roup a paragraph to add to the security considerations section. Derek's suggestion: =3D=3D=3D=3D =3D=3D=3D =3D=3D=3D =3D=3D=3D Perhaps you could boil it down to a paragraph or two for addition to the security considerations section that basically s= ays "beware of implementing it *this* way because it leads to *that* attack vec= tor", etc. =3D=3D=3D=3D =3D=3D=3D =3D=3D=3D =3D=3D=3D Here is out suggested text: =3D=3D=3D=3D =3D=3D=3D =3D=3D=3D =3D=3D=3D It has been observed that in multiple occasions that the server-side authentication logic takes an access token from the client, then queries the user's profile data from the IdP in order to "authenticate" the user. This implementation must be forbidden. It will allow an untrusted app running on a victim's client device to work with an attacker's device to sign into the victim's account on the ser= ver side. =3D=3D=3D=3D =3D=3D=3D =3D=3D=3D =3D=3D=3D Thank you. -Shuo p.s. below is the email thread giving a better context of the discussion. -----Original Message----- From: Derek Atkins [mailto:derek@ihtfp.com] Sent: Monday, June 18, 2012 11:25 AM To: Shuo Chen (MSR) Cc: Hannes Tschofenig; rui wang; Stephen Farrell; Yuchen Zhou; Derek Atkins; Dick Hardt Subject: Re: [OAUTH-WG] web sso study... Hi, "Shuo Chen (MSR)" > w= rites: Hi Hannes, Derek and Stephen, Thank you for your replies. First, let me ask whether it is OK if I share your post with the OAuth WG Yes, please feel free to share it. Second, could you describe the attack in more details to me? Let's consider the mobile+cloud scenario for concreteness (although some other scenarios are also applicable). The attack steps are the following: suppose Alice's tablet runs a Windows 8 Metro app written by attacker Bob. This app is able to request and obtain an access token from the IdP (associated with Alice). The app can then send the access token to Bob's own tablet. Note that there is no security problem up to this point. However the real problem is that some cloud services use the access token to query the user's profile data from the IdP in order to "authenticate" the user. In this case, Bob's tablet will be able to sign into the cloud service as Alice. We have confirmed that the cloud services for Soluto Metro App, Givit Metro App and EuroCup2012 Metro App make this mistake. These are apps in the official Windows 8 App Store. We actually sampled only a small portion = of the available apps, but believe this is a vulnerability pattern. We don't think there is anything wrong in the OAuth spec. It is developers who didn't comprehensively understand the usage of the access token. In the meanwhile, this vulnerability pattern is not explicitl= y excluded by the spec. More importantly, it has been seen in the wild. [from Derek's email] Perhaps you could boil it down to a paragraph or two for addition to the security considerations section that basically says "beware of implementing it *this* way because it leads to *that* attack vec= tor", etc. This is a great idea. I think that although it is difficult to anticipate in general all kinds of incomprehensive understandings of average developers, it is very worthwhile to take any common existing vulnerability pattern as a precious feedback to improve the specification text. In this case, since we have already seen this vulnerability pattern on multiple services in the wild, certainly we should be explicit about it in the security considerations section. Our suggested text: It has been observed that in multiple occasions that the server-side authentication logic takes an access token from the client, then queries the user's profile data from the IdP in order to "authenticate" the user. This implementation must be forbidden. It will allow an untrusted app running on a victim's client device to work with an attacker's device to sign into the victim's account on the ser= ver side. Any questions or suggestions? Could you please send this to the oauth@ietf.org mai= ling list? Thanks a lot. -Shuo -derek -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] Sent: Friday, June 15, 2012 11:36 AM To: rui wang Cc: Hannes Tschofenig; Stephen Farrell; Shuo Chen (MSR); Yuchen Zhou; Derek Atkins Subject: Re: [OAUTH-WG] web sso study... Hi Rui, let me independently respond (in addition to the previous responses you had already gotten). First, let me ask whether it is OK if I share your post with the OAuth WG since it is more detailed than the one you distributed on the list= mid April. Second, could you describe the attack in more details to me? What I would like to better understand whether this the raised issue is a problem with one of our specifications, with a specific implementation of the IETF OAuth specifications, a problem with other OAuth related work (Facebook, as you know, implements far more than just the IETF OAuth specifications), a violation of the IETF OAuth specification in the way how the Websites use OAuth, whether this is a configuration related aspect, or an aspect we already documented in the t= hreats document. The reason why I am so specific is to know where to put text to address this issue or whether this is even an issue beyond the IETF OAuth working group and needs to be tackled somewhere else. 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 --_000_0CBAEB56DDB3A140BA8E8C124C04ECA20107B405P3PWEX2MB008ex2_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The sad reality is, we've= spent 3 years producing a specification that is less secure, more complex,= and does not interoperate the way OAuth 1.0 does.

 <= /p>

It does scale better for = huge companies like Google, Microsoft, and Yahoo. No wonder they wanted it = this way.

 <= /p>

When asked, I tend to adv= ise people using OAuth 1.0 to just keep using it.

 <= /p>

Oh well.

 <= /p>

EH

 <= /p>

From: oauth-bo= unces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley
Sent: Thursday, June 21, 2012 6:47 AM
To: Hannes Tschofenig
Cc: rui wang; Yuchen Zhou; Shuo Chen (MSR); Derek Atkins; oauth@ietf= .org
Subject: Re: [OAUTH-WG] proposal of a paragraph to add to the securi= ty considerations section

 

Hi Hannes,

 

MAC tokens protect resources against token leakage t= o third parties.  That is useful but a different threat.  

 

The easiest way to get a access token for someone is= to have them log into your site.   

 

If you can do that the token type makes no differenc= e unless we move to a asymmetric holder of key token (different discussion)= .

 

The bad client gets the access MAC token and token s= ecret and can re use it just as it would a bearer token.

 

The origin of the post was a contention by someone a= t Facebook that profiling OAuth 2.0 on its own is sufficient to produce an = Authentication protocol.

 

I was trying to point out that OAuth 2 without any e= xtensions, only profiling is difficult to impossible to use for authenticat= ion as the attack surface and security considerations are different.

 

As it turned out Facebook had extended OAuth 2 with = signed requests and token introspection techniques to address these issues = for themselves.   

 

The problem as it turned out was that individual app= s and  app frameworks like the iOS one made some bad mistakes, by not = using the perhaps under documented extensions.

 

The problem is not unique to Facebook in any way the= y are just a convenient example.

 

Oauth 2  is not surprisingly mostly a= bout protecting the resource.  

 

Authentication is about protecting the client.<= /o:p>

 

Audience restriction from openID 2, SAML,  WS* = etc prevents replay of tokens issued to one RP/SP at another.  

That is sort of authentication protocol threat numbe= r 1.

 

OAuth has no way to do that with access tokens.=

 

It can however do it with "code" if the cl= ient is confidential.

 

So my recommendation is that without extensions to O= Auth like structured tokens (signed_request, id_token) or token introspecti= on endpoints like 

Facebook ( https= ://graph.facebook.com/app?access_token=3D[The Access Token]), there is no safe way to use an implicit flow for authentication.

A code flow where a= native app exchanges code for the access token and then passes the access = token back to it's server is also vulnerable (lots of this in circulation I= understand)

 

The only safe flow = (without extensions) is the code flow where the client is confidential and = the code is directly exchanged for the access token.

This also requires = the definition of a identity API that is protected by the access token, and= out of scope for OAuth.

 

So at the end of th= e day the rational conclusion is that OAuth 2 is a authorization protocol. =   

It may be used by A= uthentication protocols, but it is up to other specs to define the security= considerations for that.

 

That however doesn'= t remove the need to mention the token substitution attack that non confide= ntial clients are subject to, do to there being no other mechanism for the = client to know who the token was issued to.

 

John B.=

 

 

 

 

 

On 2012-06-21, at 5:27 AM, Hannes Tschofenig wrote:<= o:p>



Hi John,

I read through your blog post. I am not sure whether I can entirely agree w= ith your separation between authentication and authorization. I believe the= core issue here is that

* anyone who has the token will get access to whatever the token entitles h= im or her to do (unless there are restrictions in the token)

* some attributes are different than others. With authentication you typica= lly associate that the process took place recently (i.e., it is fresh) whil= e other attributes do not require the user (as resource owner) to actively = participate in the exchange and the same level of freshness is not implied.  For authentication in a = three party protocol to be useful the three parties have to participate (se= e http://tools.ietf.org/id/draft-tschofenig-oauth-signature-thoughts-00.txt).

I understand that one wants to avoid having tokens passed around from one a= pplication to the other one, as it is happening here.

I remember having some of these discussions with Eran a long time ago. He a= nticipated that implementers will not put any constraints in the tokens and= hence they will be misused. This serves as an argument for him to propose = the MAC token specification.

I proposed text for the security consideration section of the bearer docume= nt a while ago and it even talks about audience restriction as a recommenda= tion.

There are two problems with the audience restriction:

1) There is no mandatory token format defined nor do we mandate token conte= nt either. Hence we do not strongly require anything specifically to be put= into the tokens.

2) In the implicit grant flow the client isn't authenticated and hence what= do you want to put into a token as an audience restriction?

Finally, I think that the "audience restriction" terminology is a= bit fuzzy for this discussion either.
Audience restriction can mean two things:

* Allowing the client to verify that the access token has indeed been issue= d for him / her.
* Allowing the resource server verify that the received access token from a= specific client has indeed been provided by that client.

My current believe is that the implicit grant flow is unsuitable for provid= ing authentication functionality.

Ciao
Hannes

On Jun 19, 2012, at 5:50 AM, John Bradley wrote:


I can put something together.   

 

It is mostly a warning about the token substitution = attack that any implicit flow is vulnerable to if used for authentication o= f the presenter.

Otherwise known as why audience restriction is a goo= d thing.

 

John B.

 

On 2012-06-18, at 8:20 PM, Dick Hardt wrote:

 

John

 

Do you have suggested text per your suggestion below= ?

 

-- Dick

 

On Jun 18, 2012, at 2:04 PM, John Bradley wrote:

 

I blogged about this in the hypothetical several mon= ths ago. http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.ht= ml

 

Nov Matake and others built some tests and found qui= te a number of deployments vulnerable.

http://www.thread-safe.com/2012/02/= more-on-oauth-implicit-flow-application.html

 

The bottom line is that OAuth has no explicit audien= ce restriction for tokens,  hence accepting any token outside of the c= ode flow is subject to attack.

 

In general it is not a issue for authorization, &nbs= p;it is however a big issue then there is a presumption that the presenter = of a token that grants a client access to resource x is the "resource = owner" of resource x, when it is possible that the presenter is any client who has ever had a access token for resource x= .

 

We might want to include the why it is insecure in t= he security consideration,  otherwise people reading the below will li= kely ignore the advice as it seems on the surface a touch extreme.

 

There are certainly OAuth flows that allow you to do= authentication safely,  just not all of them without additional preca= utions.

 

That is why openID Connect has a audience restricted= id_token similar to Facebook's signed request to allow the implicit flows = to be safely used for authentication.

 

John B.

 

 

 

 

On 2012-06-18, at 4:19 PM, Shuo Chen (MSR) wrote:

 

Hi OAuth group,

 

This is regarding the recent discussion about an imp= lementation issue of some cloud services using OAuth for authentication.

Derek Atkins and Dick Hardt suggested the possibilit= y to discuss with the group a paragraph to add to the security consideratio= ns section.

 

Derek’s suggestion:

=3D=3D=3D=3D   =3D=3D=3D  =3D=3D=3D &= nbsp;=3D=3D=3D

Perhaps you could boil it down to a paragraph

or two for addition to the security considerations s= ection that basically says

"beware of implementing it *this* way because i= t leads to *that* attack vector", etc.

=3D=3D=3D=3D   =3D=3D=3D  =3D=3D=3D &= nbsp;=3D=3D=3D

 

 

Here is out suggested text:

=3D=3D=3D=3D   =3D=3D=3D  =3D=3D=3D &= nbsp;=3D=3D=3D

It has been observed that in multiple occasions that= the server-side

authentication logic takes an access token from the = client, then

queries the user's profile data from the IdP in orde= r to

"authenticate" the user. This implementati= on must be forbidden. It

will allow an untrusted app running on a victim̵= 7;s client device to

work with an attacker’s device to sign into th= e victim’s account on the server side.

=3D=3D=3D=3D   =3D=3D=3D  =3D=3D=3D &= nbsp;=3D=3D=3D

 

 

Thank you.

-Shuo

p.s. below is the email thread giving a better conte= xt of the discussion.

 

 

-----Original Message-----

From: Derek Atkins [mailto:derek@ihtfp.com]

Sent: Monday, June 18, 2012 11:25 AM

To: Shuo Chen (MSR)

Cc: Hannes Tschofenig; rui wang; Stephen Farrell; Yu= chen Zhou; Derek

Atkins; Dick Hardt

Subject: Re: [OAUTH-WG] web sso study...<= /p>

 

Hi,

 

"Shuo Chen (MSR)" <shuochen@microsoft.com> writes:

 

Hi Hannes, Derek and Stephen,

 

Thank you for your replies.

 

First, let me ask whether it is OK if I share your p= ost with the

OAuth WG

 

Yes, please feel free to share it.

 

Second, could you describe the attack in more detail= s to me?

 

Let's consider the mobile+cloud scenario for con= creteness (although

some other scenarios are also applicable). The attac= k steps are the

following: suppose Alice's tablet runs a Windows 8 M= etro app written

by attacker Bob. This app is able to request and obt= ain an access

token from the IdP (associated with Alice). The app = can then send the

access token to Bob's own tablet. Note that there is= no security

problem up to this point. However the real problem i= s that some cloud

services use the access token to query the user's pr= ofile data from

the IdP in order to "authenticate" the use= r. In this case, Bob's

tablet will be able to sign into the cloud service a= s Alice. We have

confirmed that the cloud services for Soluto Metro A= pp, Givit Metro

App and EuroCup2012 Metro App make this mistake. The= se are apps in

the official Windows 8 App Store. We actually sample= d only a small portion of the available apps, but believe this is a vulnera= bility pattern.

 

We don’t think there is anything wrong in the = OAuth spec. It is

developers who didn’t comprehensively understa= nd the usage of the

access token. In the meanwhile, this vulnerability p= attern is not explicitly excluded by the spec.

More importantly, it has been seen in the wild.=

 

[from Derek's email] Perhaps you could boil it down = to a paragraph

or two for

addition to the security considerations section that= basically says

"beware of implementing it *this* way because i= t leads to *that* attack vector", etc.

 

This is a great idea. I think that although it is di= fficult to

anticipate in general all kinds of incomprehensive u= nderstandings of

average developers, it is very worthwhile to take an= y common existing

vulnerability pattern as a precious feedback to impr= ove the

specification text. In this case, since we have alre= ady seen this

vulnerability pattern on multiple services in the wi= ld, certainly we

should be explicit about it in the security consider= ations section.

 

Our suggested text:

 

It has been observed that in multiple occasions that= the server-side

authentication logic takes an access token from the = client, then

queries the user's profile data from the IdP in orde= r to

"authenticate" the user. This implementati= on must be forbidden. It

will allow an untrusted app running on a victim̵= 7;s client device to

work with an attacker’s device to sign into th= e victim’s account on the server side.

 

Any questions or suggestions?

 

Could you please send this to the oauth@ietf.org mailing list?

 

Thanks a lot.

 

-Shuo

 

-derek

 

-----Original Message-----

From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]

Sent: Friday, June 15, 2012 11:36 AM

To: rui wang

Cc: Hannes Tschofenig; Stephen Farrell; Shuo Chen (M= SR); Yuchen Zhou;

Derek Atkins

Subject: Re: [OAUTH-WG] web sso study...<= /p>

 

Hi Rui,

 

let me independently respond (in addition to the pre= vious responses

you had already gotten).

 

First, let me ask whether it is OK if I share your p= ost with the

OAuth WG since it is more detailed than the one you = distributed on the list mid April.

 

Second, could you describe the attack in more detail= s to me? What I

would like to better understand whether this the rai= sed issue is a

problem with one of our specifications, with a speci= fic

implementation of the IETF OAuth specifications, a p= roblem with other

OAuth related work (Facebook, as you know, implement= s far more than

just the IETF OAuth specifications), a violation of = the IETF OAuth

specification in the way how the Websites use OAuth,= whether this is

a configuration related aspect, or an aspect we alre= ady documented in the threats document.

 

The reason why I am so specific is to know where to = put text to

address this issue or whether this is even an issue = beyond the IETF

OAuth working group and needs to be tackled somewher= e else.

 

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

 

 

--_000_0CBAEB56DDB3A140BA8E8C124C04ECA20107B405P3PWEX2MB008ex2_-- From Adam.Lewis@motorolasolutions.com Thu Jun 21 09:02:01 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6C7521F8658 for ; Thu, 21 Jun 2012 09:02:01 -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 p2RC-tYc0xJB for ; Thu, 21 Jun 2012 09:01:49 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe003.messaging.microsoft.com [213.199.154.206]) by ietfa.amsl.com (Postfix) with ESMTP id 87C0721F8458 for ; Thu, 21 Jun 2012 09:01:48 -0700 (PDT) Received: from mail111-am1-R.bigfish.com (10.3.201.252) by AM1EHSOBE003.bigfish.com (10.3.204.23) with Microsoft SMTP Server id 14.1.225.23; Thu, 21 Jun 2012 16:00:15 +0000 Received: from mail111-am1 (localhost [127.0.0.1]) by mail111-am1-R.bigfish.com (Postfix) with ESMTP id D149734023F for ; Thu, 21 Jun 2012 16:00:15 +0000 (UTC) X-Forefront-Antispam-Report: CIP:129.188.136.18; KIP:(null); UIP:(null); IPV:NLI; H:il06msg02.am.mot-solutions.com; RD:none; EFVD:NLI X-SpamScore: -18 X-BigFish: VPS-18(zzbb2dI98dI9371Ic85fh1418Ib457nzz1202hzz1033IL8275bh8275dhz2fh2a8h683h839hd25hf0ah) Received-SPF: pass (mail111-am1: domain of motorolasolutions.com designates 129.188.136.18 as permitted sender) client-ip=129.188.136.18; envelope-from=Adam.Lewis@motorolasolutions.com; helo=il06msg02.am.mot-solutions.com ; olutions.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.234.85; KIP:(null); UIP:(null); (null); H:SN2PRD0410HT002.namprd04.prod.outlook.com; R:internal; EFV:INT Received: from mail111-am1 (localhost.localdomain [127.0.0.1]) by mail111-am1 (MessageSwitch) id 134029441284285_11391; Thu, 21 Jun 2012 16:00:12 +0000 (UTC) Received: from AM1EHSMHS015.bigfish.com (unknown [10.3.201.236]) by mail111-am1.bigfish.com (Postfix) with ESMTP id DD76FA0048 for ; Thu, 21 Jun 2012 16:00:11 +0000 (UTC) Received: from il06msg02.am.mot-solutions.com (129.188.136.18) by AM1EHSMHS015.bigfish.com (10.3.207.153) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 21 Jun 2012 16:00:09 +0000 Received: from il06msg02.am.mot-solutions.com (il06vts03.mot.com [129.188.137.143]) by il06msg02.am.mot-solutions.com (8.14.3/8.14.3) with ESMTP id q5LG1XpP004098 for ; Thu, 21 Jun 2012 12:01:33 -0400 (EDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe005.messaging.microsoft.com [213.199.154.143]) by il06msg02.am.mot-solutions.com (8.14.3/8.14.3) with ESMTP id q5LG1VnL004076 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 21 Jun 2012 12:01:32 -0400 (EDT) Received: from mail99-db3-R.bigfish.com (10.3.81.238) by DB3EHSOBE003.bigfish.com (10.3.84.23) with Microsoft SMTP Server id 14.1.225.23; Thu, 21 Jun 2012 16:00:04 +0000 Received: from mail99-db3 (localhost [127.0.0.1]) by mail99-db3-R.bigfish.com (Postfix) with ESMTP id 189AF1803A1 for ; Thu, 21 Jun 2012 16:00:04 +0000 (UTC) Received: from mail99-db3 (localhost.localdomain [127.0.0.1]) by mail99-db3 (MessageSwitch) id 1340294400727580_25198; Thu, 21 Jun 2012 16:00:00 +0000 (UTC) Received: from DB3EHSMHS016.bigfish.com (unknown [10.3.81.228]) by mail99-db3.bigfish.com (Postfix) with ESMTP id A4B59A0048; Thu, 21 Jun 2012 16:00:00 +0000 (UTC) Received: from SN2PRD0410HT002.namprd04.prod.outlook.com (157.56.234.85) by DB3EHSMHS016.bigfish.com (10.3.87.116) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 21 Jun 2012 15:59:58 +0000 Received: from SN2PRD0410MB370.namprd04.prod.outlook.com ([169.254.7.46]) by SN2PRD0410HT002.namprd04.prod.outlook.com ([10.255.115.37]) with mapi id 14.16.0164.004; Thu, 21 Jun 2012 16:01:24 +0000 From: Lewis Adam-CAL022 To: Nat Sakimura Thread-Topic: [OAUTH-WG] Report an authentication issue Thread-Index: AQHNT0pvhTnXb3MtGkWmLvJyYY7auJcE72EA Date: Thu, 21 Jun 2012 16:01:23 +0000 Message-ID: <59E470B10C4630419ED717AC79FCF9A917052BC8@SN2PRD0410MB370.namprd04.prod.outlook.com> References: <1339792496.52712.YahooMailNeo@web125501.mail.ne1.yahoo.com> <59E470B10C4630419ED717AC79FCF9A9108898EE@BL2PRD0410MB363.namprd04.prod.outlook.com> <4FE223E4.6060307@mitre.org> <4FE226BC.6010403@alcatel-lucent.com> <59E470B10C4630419ED717AC79FCF9A910889AB5@BL2PRD0410MB363.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.45.131] Content-Type: multipart/alternative; boundary="_000_59E470B10C4630419ED717AC79FCF9A917052BC8SN2PRD0410MB370_" 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%ALCATEL-LUCENT.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] Report an authentication issue X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 16:02:01 -0000 --_000_59E470B10C4630419ED717AC79FCF9A917052BC8SN2PRD0410MB370_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Nat, I'm beginning to wonder what it would take to add a new profile of sorts to= either OAuth or Connect. In the beginning there was SOAP, and the preferred method to secure SOAP AP= I calls was WS-Trust. Now the world is moving toward RESTful APIs ... and the preferred means to = secure RESTful APIs is OAuth. Except that OAuth is clearly written with the idea that the protected resou= rces belong to the end user. My use cases - and I imagine the use cases of many other enterprises - is t= hat the Owner of the resources is the Enterprise. An employee is trying to= access a database or video resources. The enterprise RS needs to be able = to 1) identify the user, and 2) make authorization decisions based on what = roles that user has within the enterprise. So in my scenario, when a polic= e officer attempts to access a criminal records database, the database need= s to know who that officer is, and then decide if they have privilege to ac= cess the database, and at what level (e.g. CRUD). WS-Trust fits this model well. The user performs primary authentication to= the enterprise STS, which then grants the application client a SAML assert= ion. When the user attempts to access a records database, the SAML asserti= on is included in the SOAP message. The records server authenticates the u= ser based on the SAML assertion and makes its authorization decisions. This is the world I'm trying to migrate from, and it really seems like I'm = sometimes trying to make a square peg fit in a round hole. I'm looking for= OAuth/Connect to do for REST what WS-TRUST did for SOAP. I would like a n= ative client talking to a RS to be able to ask for an id_token, and then pa= ss that id_token to the RS when making its RESTful API calls, to enable the= RS to authenticate the user. I think that this would be really useful for= a lot of people besides me. I keep hearing that there is nothing "prevent= ing" me from doing this ... but it hardly seems within the spirit of what O= Auth was meant to do. The id_token was clearly meant to enable a user to a= uthenticate to a confidential client / web server ... but was not meant fo= r a native client to identity / authenticate the user to a RS. Would there be any interest in exploring this further? -adam From: Nat Sakimura [mailto:sakimura@gmail.com] Sent: Wednesday, June 20, 2012 8:09 PM To: Lewis Adam-CAL022 Cc: igor.faynberg@alcatel-lucent.com; oauth@ietf.org Subject: Re: [OAUTH-WG] Report an authentication issue Yes, OAuth can be profiled to enable authentication. In fact, initial draft of OpenID Connect was just like you described. Essentially, we were using structured access_token. Later, we decided to separate the access token and id_token for several rea= sons such as: 1. Better interop with existing OAuth implementations: by introducing id= _token, they do not need to touch the supposedly opaque (which means AS-RS = may be doing some proprietary thing inside it) access token. 2. Mixing up the audience (for id_token aka authn =3D client, and for ac= cess_token aka authz =3D resource server) probably is expanding the attack = surface for security and privacy. Although we separated them out, a signed id_token includes the left hash of= access_token so access_token is also protected. Best, Nat On Thu, Jun 21, 2012 at 5:21 AM, Lewis Adam-CAL022 > wrote: Hi Igor, As Justin just pointed out, consider the case where the video server is hos= ted by the state (e.g. California) and is accessed by police agencies in Lo= s Angeles, San Francisco, and San Diego. The State of California's video s= erver is the RS. Each local police agency (LA/SF/SD) hosts an AS. So when= a police officer from LAPD launches the video client app on the iPhone, th= e client makes an OAuth request to the LAPD's AS, which authenticates the p= olice officer using agency level credentials. The access token issued to t= he video client app on the iPhone is a JWT, signed by the agency AS, which = might look something like this: {"typ":"JWT","alg":"ES256"} {"iss":"https://as.lapd.california.gov", "prn":"alice@lapd.california.gov", "aud":" https://video_server1@state.california.gov", "iat":1300815780, "exp":1300819380, "acr":"password"} hq4zk+ZknjggCQgZm7ea8fI79gJEsRy3E8LHDpYXWQIgZpkJN9CMLG8ENR4Nrw+n7iyzixBvKXX= 8P53BTCT4VghPBWhFYSt9tHWu/AtJfOTh6qaAsNdeCyG86jmtp3TDMwuL/cBUj2OtBZOQMFn7jQ= 9YB7klIz3RqVL+wNmeWI4=3D The JWT might be optionally encrypted using JWE. I think what is becoming clear (and this is what I'm trying to vet) is that= while there is nothing in OAuth that specifies authentication, it *can* be= used for Authentication, if done in the way that I describe. If I'm wrong= about this, I really need to know. I've vetted this idea of mine with qui= te of few people now - both within context of the list and off-line - and I= think I'm okay. If you see any holes in what I describe, please point them= out as I would prefer to uncover them now rather than after implementation= or deployment! Essentially I'm using OAuth as a RESTful version of WS-Trust, where my clie= nt can exchange primary credentials for a token (JWT) and present that toke= n to a server as secondary authentication. It's just that it's RESTful ins= tead of SOAP :-) As Justin as pointed out ... I've basically made the access-token look like= the id_token of Connect. I was actually hoping to lay a path to Connect, = and use the id_token ... until it was also pointed out that the id_token is= really meant for the consumption of the client, not the RS :-( From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Igor Faynberg Sent: Wednesday, June 20, 2012 2:39 PM To: oauth@ietf.org Subject: Re: [OAUTH-WG] Report an authentication issue But this use case does need OAuth, period: The video server is under the control of a police agency, and police office= rs must logon to the video server in order to access video content. There is no delegation here, and there is no need to use third party for au= thentication. Igor On 6/20/2012 3:26 PM, Justin Richer wrote: In case it wasn't clear, I want to restate the original problem as best as = I understand it in a way that hopefully clears it up: App A and app B are both valid registered OAuth clients to an OAuth protect= ed service. The problem starts when app A gets handed a token that was issued for app B= and uses it to call an identity API on the OAuth service. Since app B can = get tokens just fine, they're bearer tokens, this is a fairly basic api cal= l, this function works just fine and returns the user info. This makes sens= e, since anyone who holds A's tokens can do whatever A can do on behalf of = that user. The issues start when app B then decides that since they can mak= e a call to the identity API with a token then the user *must* be present. = In other words, app B is confusing authorization to call an API with authen= tication of the session. OpenID Connect fixes this missed assumption by binding the ID Token to the = session and sending it along side the access token, but as you pointed out,= it's meant for consumption at the client, not the resource server, in gene= ral. That doesn't mean you can't send it to a resource server for your own = purposes, of course. That's actually how the session management endpoint wo= rks in Connect. This isn't the only way to handle this problem -- if you put some structure= in your tokens, such as with JWT or SAML, then app A can tell that this is= n't a token issued to app A, but to app B, so it can call shenanigans and r= eject it then and there. -- Justin On 06/20/2012 10:03 AM, Lewis Adam-CAL022 wrote: I am entirely confused. I understand what everybody is saying for confidential clients, no problem = here. I fall apart when thinking of iPhone apps. Consider the scenario where I d= eploy a video server, and write an iPhone app to talk to the video server. = The video server is under the control of a police agency, and police offic= ers must logon to the video server in order to access video content. So th= e police office launches their iPhone video client app. If I wanted to solve authentication using "traditional" client-server authe= ntication, the user enters their username / password into the client, and t= he client sends the username / password off to the server, which authentica= tes it, or possibly uses HTTP digest. If I wanted to use OpenID, the client would attempt to reach the video serv= er (RP), the server would redirect the client to the OP, OP authenticates u= ser, and OP redirects client back to the server/RP with an assertion that p= rimary authentication was successful. If I wanted to use OAuth, the client would send an authorization request to= the server's AS, which would authenticate the user of the client, and ulti= mately result in the client possessing an access-token. My thinking is tha= t this access token (let's assume it's a JWT) would contain the user's iden= tity, a statement of what type of primary authentication was used (auth con= text), an expiration, and an audience claim. This sounds a lot like authen= tication to me, and it's where I get confused. Is it just because OAuth do= es not explicitly define this? Is there a threat in using OAuth as I descr= ibe? If I wanted to use Connect, well I'm not even sure how the id_token as defi= ned by Connect helps this use case. The id_token seems to make sense when = the client is a confidential web server, but it's not clear what an iPhone = app would do with the id_token ... it's the server in the backend that need= s to authenticate the user, the iPhone app is just an interface to talk to = the server. And it seems as I learn more about connect that the id_token i= s not meant to be sent from the iPhone app to the server, just the access t= oken. So it's really not clear how Connect helps solve authentication for = an iPhone client app talking to a video server. If I'm sending access-toke= ns, it's just OAuth again. What am I still missing? adam From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Kristofor Selden Sent: Saturday, June 16, 2012 11:33 AM To: nov matake; oauth Cc: Yuchen Zhou; Luke Melia; Shuo Chen (MSR) Subject: Re: [OAUTH-WG] Report an authentication issue Nov demonstrated the problem to us at Yapp and we used solution 4 (because = the solution is server side and our app was in the app store). FB Connect is authentication and authorization, where OAuth 2 is concerned = only with authorization - I'm not sure that app developers appreciate this = subtlety. With OAuth 2 you authorize an app to use a protected resource. With FB Con= nect, you do that, but also authenticate with the app you are authorizing. So the access_token protects not just the FB resources but the auth end poi= nt of the authorized app (very common with apps that use the iOS SDK). So = now the app needs a way to verify that it was the app that was authorized t= o FB. Solution 4 explanation: on FB you can register a iPhone app and a server ap= p with the same client_id and get a client_secret for use on the server. T= he server side API posts the access_token, client_id, and client_secret to = https://graph.facebook.com/app to verify that the bearer token actually belongs to the app = that is being authenticated before assuming they are authorized to the app'= s protected resources. Kris On Jun 15, 2012, at 8:22 PM, nov matake wrote: There are 4 ways to fix this issue. 1. Use response_type=3Dtoken%20code (It's not in OAuth 2.0 Core, but seems = best way for interoperability) 2. Use singed_request (or some signed token like JWT) 3. Use grant_type=3Dfb_exchange_token (Facebook custom way) 4. Access to https://graph.facebook.com/app?access_token=3DYOUR_TOKEN (Face= book custom way, moreover undocumented API) Two iPhone app developers I reported this issue fixed it by using (4). I also tried to use (1) for my own iPhone app implementation, but unfortuna= tely it doesn't work when using authorization codes obtained via FB iOS SDK= . So I'm using (3) in my case. nov On 2012/06/16, at 9:16, Nat Sakimura wrote: As to how the fix was done, Nov can provide more detail, but ... 1. Properly verify the signature/HMAC of the "signed_request". This will es= sentially audience restricts the token. 2. There is an undocumented API for Facebook which returns to whom the toke= n was issued. This also audience restricts the token. The service that fixed took these measures. Note that none of the above is = defined in OAuth. The same facility was called "id_token" and "check ID endpoint" for OpenID = Connect. The scale of the impact is large, too large to disclose the actual names in= the public list, though, eventually, we would publish them in a paper. Nat On Sat, Jun 16, 2012 at 5:34 AM, Francisco Corella > wrote: Hi Nat and Rui, Rui, you say that the vulnerability that you found was due to a "common misunderstanding among developers", but the attack you describe can be carried out against any app that uses the OAuth "implicit grant flow", which Facebook calls "client-side authentication". No misunderstanding seems necessary. What misunderstanding are you referring to? I followed the link in your message to the Sophos post, and from there the link to the article in The Register. The article in The Register says that Facebook had "fixed the vulnerability promptly". How did they fix it? The instructions that Facebook provides for implementing "Client-side authentication without the JS SDK" at https://developers.facebook.com/docs/authentication/client-side/#no-jssdk still allows the attack. Nat, I agree that the blog post by John Bradley that you link to refers to the same vulnerability reported by Rui. You say that some apps have issued a patch to fix it. Could you explain what the fix was? Francisco ________________________________ From: Nat Sakimura > To: rui wang > Cc: matake nov >; Yuchen Zhou >; oauth >; Shuo Chen (MSR) > Sent: Thursday, June 14, 2012 1:50 PM Subject: Re: [OAUTH-WG] Report an authentication issue This is a fairly well known (hopefully by now) issue. We, at the OpenID Fou= ndation, call it "access_token phishing" attack these days. See: http://www= .thread-safe.com/2012/01/problem-with-oauth-for-authentication.html Nov Matake has actually built the code on iPhone to verify the problem, and= has notified bunch of parties back in February including Facebook and Appl= e. We have the code that actually runs on a phone, and we have successfully= logged in to bunch of apps, including very well known ones. They were all = informed of the issue. Some immediately issued a patch to fix it while othe= rs have not. The problem is that even if these apps gets fixed, the problem does not go = away. As long as the attacker has the vulnerable version of the app, he sti= ll can impersonate the victim. To stop it, the server side has to completel= y disable the older version, which means the service has to cut off many us= ers pausing business problems. Nat On Fri, Jun 15, 2012 at 2:18 AM, rui wang > wrote: Dear Facebook Security Team and OAuth Standard group, We are a research team in Microsoft Research. In January, 2011, we reported= a vulnerability in Facebook Connect which allowed everyone to sign into Fa= cebook-secured relying parties without password. It was promptly fixed afte= r reporting. (http://nakedsecurity.sophos.com/2011/02/02/facebook-flaw-webs= ites-steal-personal-data/) Recently, we found a common misunderstanding among developers of mobile/met= ro apps when using OAuth (including Facebook's OAuth) for authentication. T= he vulnerability resulted from this misunderstanding also allows an attacke= r to log into a victim user's account without password. Let's take Soluto's metro app as an example to describe the problem. The ap= p supports Facebook Login. As an attacker, we can write a regular Facebook = app. Once the victim user allows our app to access her Facebook data, we re= ceive an access_token from the traffic. Then, on our own machine (i.e., the= "attacker" machine), we run the metro app of Soluto, and use a HTTP proxy = to insert the victim's access_token into the traffic of Facebook login. Thr= ough this way, we are able to log into the victim's Soluto account from our= machine. Other than Soluto, we also have confirmed the same issue on anoth= er Windows 8 metro-app Givit. The Facebook SDK for Android apps (https://developers.facebook.com/docs/mob= ile/android/build/#sdk) seems to have the possibility to mislead developers= too. At least, the issue that we found is not clearly mentioned. In the SD= K, we ran the sample code called "Hackbook" using Android Emulator (imagine= it is an attacker device). Note that we have already received the access t= oken of the victim user from our regular Facebook app. We then inject the t= oken to the traffic of Hackbook. Through this way, Hackbook app on our own = machine recognizes us as the victim. Note that this is not a convincing sec= urity exploit yet, because this sample code does not include the server-sid= e code. However, given that we have seen real server-side code having this = problem, such as Soluto, Givit and others, we do believe that the sample co= de can mislead mobile/metro developers. We also suspect that this may be a = general issue of many OAuth implementations on mobile platforms, so we send= this message to OAuth Standard group as well. We have contacted the vendors of the two vulnerable metro-apps, Soluto and = Gavit. Please kindly give us an ack when you receive this message. If you want to = know more details, please let us know. Best Regards, Yuchen Zhou, Rui Wang, and Shuo Chen _______________________________________________ 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 -- 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 _______________________________________________ OAuth mailing 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 --_000_59E470B10C4630419ED717AC79FCF9A917052BC8SN2PRD0410MB370_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Nat,

 

I’m beginning to wonder what it would = take to add a new profile of sorts to either OAuth or Connect. 

 

In the beginning there was SOAP, and the pre= ferred method to secure SOAP API calls was WS-Trust.

 

Now the world is moving toward RESTful APIs = … and the preferred means to secure RESTful APIs is OAuth.=

 

Except that OAuth is clearly written with th= e idea that the protected resources belong to the end user.

 

My use cases – and I imagine the use c= ases of many other enterprises – is that the Owner of the resources i= s the Enterprise.  An employee is trying to access a database or video resources.  The enterprise RS needs to be able to 1) identify the use= r, and 2) make authorization decisions based on what roles that user has wi= thin the enterprise.  So in my scenario, when a police officer attempt= s to access a criminal records database, the database needs to know who that officer is, and then decide if they have p= rivilege to access the database, and at what level (e.g. CRUD). 

 

WS-Trust fits this model well.  The use= r performs primary authentication to the enterprise STS, which then grants = the application client a SAML assertion.  When the user attempts to access a records database, the SAML assertion is included in the SOAP m= essage.  The records server authenticates the user based on the SAML a= ssertion and makes its authorization decisions.

 

This is the world I’m trying to migrat= e from, and it really seems like I’m sometimes trying to make a squar= e peg fit in a round hole.  I’m looking for OAuth/Connect to do = for REST what WS-TRUST did for SOAP.  I would like a native client talkin= g to a RS to be able to ask for an id_token, and then pass that id_token to= the RS when making its RESTful API calls, to enable the RS to authenticate= the user.  I think that this would be really useful for a lot of people besides me.  I keep hearing that th= ere is nothing “preventing” me from doing this … but it h= ardly seems within the spirit of what OAuth was meant to do.  The id_t= oken was clearly meant to enable a user to authenticate to a confidential client  / web server … but was not meant for a nat= ive client to identity / authenticate the user to a RS. 

 

 

Would there be any interest in exploring thi= s further?

-adam

 

 

From: Nat Saki= mura [mailto:sakimura@gmail.com]
Sent: Wednesday, June 20, 2012 8:09 PM
To: Lewis Adam-CAL022
Cc: igor.faynberg@alcatel-lucent.com; oauth@ietf.org
Subject: Re: [OAUTH-WG] Report an authentication issue

 

Yes, OAuth can be profiled to enable authentication.=  

In fact, initial draft of OpenID Connect was just li= ke you described. 

Essentially, we were using structured access_token.&= nbsp;

Later, we decided to separate the access token and i= d_token for several reasons such as: 

 

  1. Better interop with existing OAuth implementations: by introducing id_token= , they do not need to touch the supposedly opaque (which means AS-RS may be= doing some proprietary thing inside it) access token. 
  2. Mixing up the audience (for id_token aka authn =3D client, and for access_t= oken aka authz =3D resource server) probably is expanding the attack surfac= e for security and privacy. 

Although we separated them out, a signed id_token in= cludes the left hash of access_token so access_token is also protected.&nbs= p;

 

Best, 

 

Nat

 

On Thu, Jun 21, 2012 at 5:21 AM, Lewis Adam-CAL022 &= lt;Ad= am.Lewis@motorolasolutions.com> wrote:

Hi Igor,

 

As Justin just pointed out, consider the case where the vi= deo server is hosted by the state (e.g. California) and is accessed by police agencies in Los Angeles, San Francisco, and San Diego.&= nbsp; The State of California’s video server is the RS.  Each lo= cal police agency (LA/SF/SD) hosts an AS.  So when a police officer fr= om LAPD launches the video client app on the iPhone, the client makes an OAuth request to the LAPD’s AS, which authentica= tes the police officer using agency level credentials.  The access tok= en issued to the video client app on the iPhone is a JWT, signed by the age= ncy AS, which might look something like this:

 

{“typ”:”JWT”,"alg":"= ;ES256"}

{"iss":"https://as.lapd.california.gov",
  "prn":"alice@lapd.california.gov",
  "aud":" https://video_server1@state.california.gov&= quot;,
  "iat":1300815780,
  "exp":1300819380,
  "acr":”password”}

hq4zk+ZknjggCQgZm7ea8fI79gJEsRy3E8LHDpYXWQIgZpkJN9CMLG8ENR4Nrw&= #43;n7iyzixBvKXX8P53BTCT4VghPBWhFYSt9tHWu/AtJfOTh6qaAsNdeCyG86jmtp3TDMwuL/c= BUj2OtBZOQMFn7jQ9YB7klIz3RqVL+wNmeWI4=3D

 

The JWT might be optionally encrypted using JWE. 

 

I think what is becoming clear (and this is what I’m trying t= o vet) is that while there is nothing in OAuth that specifies authenticatio= n, it *can* be used for Authentication, if done in the way that I describe.  If I’m wrong about this, I really need to= know.  I’ve vetted this idea of mine with quite of few people n= ow – both within context of the list and off-line – and I think= I’m okay. If you see any holes in what I describe, please point them out as I would prefer to uncover them now rather than after implementation= or deployment!

 

Essentially I’m using OAuth as a RESTful version of WS-Trust,= where my client can exchange primary credentials for a token (JWT) and pre= sent that token to a server as secondary authentication.  It’s just that it’s RESTful instead of SOAP :-)

 

As Justin as pointed out … I’ve basically made the acce= ss-token look like the id_token of Connect.  I was actually hoping to = lay a path to Connect, and use the id_token … until it was also point= ed out that the id_token is really meant for the consumption of the client, n= ot the RS :-(

 

 

 

From: oauth-bounces@i= etf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Igor Faynberg
Sent: Wednesday, June 20, 2012 2:39 PM
To: oauth@ietf.o= rg


Subject: Re: [OAUTH-WG] Report an authentication issue

 

But this use case  does need OAuth, period:



The video server is under the control of a police agency, and polic= e officers must logon to the video server in order to access video content.=

There is no delegation here, and there is no need to use third party for au= thentication. 

Igor

On 6/20/2012 3:26 PM, Justin Richer wrote:

In case it wasn't clear, I want to restate the original problem as= best as I understand it in a way that hopefully clears it up:

App A and app B are both valid registered OAuth clients to an OAuth protect= ed service.

The problem starts when app A gets handed a token that was issued for app B= and uses it to call an identity API on the OAuth service. Since app B can = get tokens just fine, they're bearer tokens, this is a fairly basic api cal= l, this function works just fine and returns the user info. This makes sense, since anyone who holds A's to= kens can do whatever A can do on behalf of that user. The issues start when= app B then decides that since they can make a call to the identity API wit= h a token then the user *must* be present. In other words, app B is confusing authorization to call an API w= ith authentication of the session.

OpenID Connect fixes this missed assumption by binding the ID Token to the = session and sending it along side the access token, but as you pointed out,= it's meant for consumption at the client, not the resource server, in gene= ral. That doesn't mean you can't send it to a resource server for your own purposes, of course. That's actu= ally how the session management endpoint works in Connect.

This isn't the only way to handle this problem -- if you put some structure= in your tokens, such as with JWT or SAML, then app A can tell that this is= n't a token issued to app A, but to app B, so it can call shenanigans and r= eject it then and there.

 -- Justin

On 06/20/2012 10:03 AM, Lewis Adam-CAL022 wrote:

I am entirely confused.

 

I understand what everybody is saying for confidential cli= ents, no problem here.

 

I fall apart when thinking of iPhone apps.  Consider = the scenario where I deploy a video server, and write an iPhone app to talk to the video server.  The video server is under the contr= ol of a police agency, and police officers must logon to the video server i= n order to access video content.  So the police office launches their = iPhone video client app.

 

If I wanted to solve authenticati= on using “traditional” client-server authentication, the user e= nters their username / password into the client, and the client sends the username / password off to the server, which authenticates it, or poss= ibly uses HTTP digest. 

If I wanted to use OpenID, the cl= ient would attempt to reach the video server (RP), the server would redirec= t the client to the OP, OP authenticates user, and OP redirects client back to the server/RP with an assertion that primary authentication= was successful. 

If I wanted to use OAuth, the cli= ent would send an authorization request to the server’s AS, which wou= ld authenticate the user of the client, and ultimately result in the client possessing an access-token.  My thinking is that this a= ccess token (let’s assume it’s a JWT) would contain the user= 217;s identity, a statement of what type of primary authentication was used= (auth context), an expiration, and an audience claim.  This sounds a lot like authentication to me, and it’s where I get co= nfused.  Is it just because OAuth does not explicitly define this?&nbs= p; Is there a threat in using OAuth as I describe? 

If I wanted to use Connect, well I’m not even sure how the= id_token as defined by Connect helps this use case.  The id_token see= ms to make sense when the client is a confidential web server, but it’s not clear what an iPhone app would do with the id_token …= it’s the server in the backend that needs to authenticate the user, = the iPhone app is just an interface to talk to the server.  And it see= ms as I learn more about connect that the id_token is not meant to be sent from the iPhone app to the server, just the access token.=   So it’s really not clear how Connect helps solve authenticatio= n for an iPhone client app talking to a video server.  If I’m se= nding access-tokens, it’s just OAuth again.

 

What am I still missing?

adam

 

 

From: oauth-bounces@i= etf.org [ma= ilto:oauth-bounces@ietf.org] On Behalf Of Kristofor Selden
Sent: Saturday, June 16, 2012 11:33 AM
To: nov matake; oauth
Cc: Yuchen Zhou; Luke Melia; Shuo Chen (MSR)
Subject: Re: [OAUTH-WG] Report an authentication issue

 

Nov demonstrated the problem to us at Yapp and we used solution 4 = (because the solution is server side and our app was in the app store).

 

FB Connect is authentication and authorization, where OAuth 2 is concerned only with authorizatio= n – I'm not sure that app developers appreciate this subtlety.

 

With OAuth 2 you authorize an app to use a protected resource. &nb= sp;With FB Connect, you do that, but also authenticate with the app you are authorizing.

 

So the access_token protects not just the FB resources but the aut= h end point of the authorized app (very common with apps that use the iOS S= DK).  So now the app needs a way to verify that it was the app that was authorized to FB.

 

Solution 4 explanation: on FB you can register a iPhone app and a = server app with the same client_id and get a client_secret for use on the s= erver.  The server side API posts the access_token, client_id, and client_secret to h= ttps://graph.facebook.com/app to verify that the bearer token= actually belongs to the app that is being authenticated before assuming they are authorized to the app's protected resources.<= /p>

 

Kris

 

On Jun 15, 2012, at 8:22 PM, nov matake wrote:



There are 4 ways to fix this issue.

 

1. Use response_type=3Dtoken%20code (It's not in OAuth 2.0 Co= re, but seems best way for interoperability)

2. Use singed_request (or some signed token like JWT)

3. Use grant_type=3Dfb_exchange_token (Facebook custom way)

4. Access to https://graph.facebook.com/app?access_token=3DYOUR_TOKEN (Facebook cust= om way, moreover undocumented API)

 

Two iPhone app developers I reported this issue fixed it by using = (4).

 

I also tried to use (1) for my own iPhone app implementation, but = unfortunately it doesn't work when using authorization codes obtained via F= B iOS SDK.

So I'm using (3) in my case.

 

nov

 

On 2012/06/16, at 9:16, Nat Sakimura wrote:



As to how the fix was done, Nov can provide more detail, but ...&n= bsp;

 

1. Properly verify the signature/HMAC of the "signed_request&= quot;. This will essentially audience restricts the token. =

2. There is an undocumented API for Facebook which returns to whom= the token was issued. This also audience restricts the token. 

 

The service that fixed took these measures. Note that none of the = above is defined in OAuth. 

The same facility was called "id_token" and "check = ID endpoint" for OpenID Connect. 

 

The scale of the impact is large, too large to disclose the actual= names in the public list, though, eventually, we would publish them in a p= aper. 

 

Nat

On Sat, Jun 16, 2012 at 5:34 AM, Francisco Corella <fcorella@pomcor.com> wrote:<= br>

Hi Nat and Rui,

Rui, you say that the vulnerability that you found was due to a
"common misunderstanding among developers", but the attack you describe can be carried out against any app that uses the OAuth
"implicit grant flow", which Facebook calls "client-side
authentication".  No misunderstanding seems necessary.  What=
misunderstanding are you referring to?  I followed the link in your message to the Sophos post, and from there the link to the article in
The Register.  The article in The Register says that Facebook had
"fixed the vulnerability promptly".  How did they fix it?&nb= sp; The
instructions that Facebook provides for implementing "Client-side
authentication without the JS SDK" at
https://developers.facebook.com/docs/authentic= ation/client-side/#no-jssdk
still allows the attack.

Nat, I agree that the blog post by John Bradley that you link to
refers to the same vulnerability reported by Rui.  You say that some apps have issued a patch to fix it.  Could you explain what the fix was?

Francisco

 

From: Nat Sakimura <sakimura@gmail.com>
To: rui wang <ruiwangwarm@gmail.com>
Cc: matake nov <nov@matake.jp>; Yuchen Zhou <t-yuzhou@microsoft.com>; oauth <oauth@ietf.org>; Shuo Chen (MSR) <shuochen@microsoft.com>
Sent: Thursday, June 14, 2012 1:50 PM
Subject: Re: [OAUTH-WG] Report an authentication issue

 

This is a fairly well known (hopefully by now) issue. We, at the O= penID Foundation, call it "access_token phishing" attack these da= ys. See: http://www.thread-safe.com/2= 012/01/problem-with-oauth-for-authentication.html

 

Nov Matake has actually built the code on iPhone to verify the pro= blem, and has notified bunch of parties back in February including Facebook= and Apple. We have the code that actually runs on a phone, and we have successfully logged in to bunch of apps, incl= uding very well known ones. They were all informed of the issue. Some immed= iately issued a patch to fix it while others have not.  

 

The problem is that even if these apps gets fixed, the problem doe= s not go away. As long as the attacker has the vulnerable version of the ap= p, he still can impersonate the victim. To stop it, the server side has to completely disable the older version, w= hich means the service has to cut off many users pausing business problems.=  

 

Nat

On Fri, Jun 15, 2012 at 2:18 AM, rui wang <ruiwangwarm@gmail.com> wrote:=

Dear Facebook Security Team and OAuth Standard group,

We are a research team in Microsoft Research. In January, 2011, we= reported a vulnerability in Facebook Connect which allowed everyone to sig= n into Facebook-secured relying parties without password. It was promptly fixed after reporting. (http://nakedsecurity.sophos.com/2011/02/02/facebo= ok-flaw-websites-steal-personal-data/)

Recently, we found a common misunderstanding among developers of m= obile/metro apps when using OAuth (including Facebook’s OAuth) for au= thentication. The vulnerability resulted from this misunderstanding also allows an attacker to log into a victim user's = account without password.

Let's take Soluto's metro app as an example to describe the proble= m. The app supports Facebook Login. As an attacker, we can write a regular = Facebook app. Once the victim user allows our app to access her Facebook data, we receive an access_token from the t= raffic. Then, on our own machine (i.e., the "attacker" machine), = we run the metro app of Soluto, and use a HTTP proxy to insert the victim's= access_token into the traffic of Facebook login. Through this way, we are able to log into the victim's Soluto accou= nt from our machine. Other than Soluto, we also have confirmed the same iss= ue on another Windows 8 metro-app Givit.

The Facebook SDK for Android apps (https://devel= opers.facebook.com/docs/mobile/android/build/#sdk) seems to have the possibility to mislead developers too. At least, the iss= ue that we found is not clearly mentioned. In the SDK, we ran the sample co= de called "Hackbook" using Android Emulator (imagine it is an att= acker device). Note that we have already received the access token of the victim user from our regular Facebook app. We then= inject the token to the traffic of Hackbook. Through this way, Hackbook ap= p on our own machine recognizes us as the victim. Note that this is not a c= onvincing security exploit yet, because this sample code does not include the server-side code. However, g= iven that we have seen real server-side code having this problem, such as S= oluto, Givit and others, we do believe that the sample code can mislead mob= ile/metro developers. We also suspect that this may be a general issue of many OAuth implementations on mobile p= latforms, so we send this message to OAuth Standard group as well.

We have contacted the vendors of the two vulnerable metro-apps, So= luto and Gavit.

Please kindly give us an ack when you receive this message. If you= want to know more details, please let us know.

Best Regards,
Yuchen Zhou, Rui Wang, and Shuo Chen


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

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



 

--
Nat Sakimura (=3Dnat)

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

 

--_000_59E470B10C4630419ED717AC79FCF9A917052BC8SN2PRD0410MB370_-- From igor.faynberg@alcatel-lucent.com Thu Jun 21 09:28:31 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48C0B21F8755 for ; Thu, 21 Jun 2012 09:28:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[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 q02orz1WoZTH for ; Thu, 21 Jun 2012 09:28:24 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 39C8C21F8751 for ; Thu, 21 Jun 2012 09:28:24 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q5LGSF4b023142 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 21 Jun 2012 11:28:15 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q5LGSEZc017473 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 21 Jun 2012 11:28:14 -0500 Received: from [135.222.232.88] (USMUYN0L055118.mh.lucent.com [135.222.232.88]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q5LGSDWU017333; Thu, 21 Jun 2012 11:28:13 -0500 (CDT) Message-ID: <4FE34B9D.1040200@alcatel-lucent.com> Date: Thu, 21 Jun 2012 12:28:13 -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: Lewis Adam-CAL022 References: <1339792496.52712.YahooMailNeo@web125501.mail.ne1.yahoo.com> <59E470B10C4630419ED717AC79FCF9A9108898EE@BL2PRD0410MB363.namprd04.prod.outlook.com> <4FE223E4.6060307@mitre.org> <4FE226BC.6010403@alcatel-lucent.com> <59E470B10C4630419ED717AC79FCF9A910889AB5@BL2PRD0410MB363.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A917052BC8@SN2PRD0410MB370.namprd04.prod.outlook.com> In-Reply-To: <59E470B10C4630419ED717AC79FCF9A917052BC8@SN2PRD0410MB370.namprd04.prod.outlook.com> Content-Type: multipart/alternative; boundary="------------070209060208070007000900" X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Report an authentication issue 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 Jun 2012 16:28:31 -0000 This is a multi-part message in MIME format. --------------070209060208070007000900 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit +1 for exploring. Igor On 6/21/2012 12:01 PM, Lewis Adam-CAL022 wrote: > ... > > This is the world I'm trying to migrate from, and it really seems like > I'm sometimes trying to make a square peg fit in a round hole. I'm > looking for OAuth/Connect to do for REST what WS-TRUST did for SOAP. > I would like a native client talking to a RS to be able to ask for an > id_token, and then pass that id_token to the RS when making its > RESTful API calls, to enable the RS to authenticate the user. I think > that this would be really useful for a lot of people besides me. I > keep hearing that there is nothing "preventing" me from doing this ... > but it hardly seems within the spirit of what OAuth was meant to do. > The id_token was clearly meant to enable a user to authenticate to a > confidential client / web server ... but was not meant for a native > client to identity / authenticate the user to a RS. > > Would there be any interest in exploring this further? > > -adam > > *From:*Nat Sakimura [mailto:sakimura@gmail.com] > *Sent:* Wednesday, June 20, 2012 8:09 PM > *To:* Lewis Adam-CAL022 > *Cc:* igor.faynberg@alcatel-lucent.com; oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Report an authentication issue > > Yes, OAuth can be profiled to enable authentication. > > In fact, initial draft of OpenID Connect was just like you described. > > Essentially, we were using structured access_token. > > Later, we decided to separate the access token and id_token for > several reasons such as: > > 1. Better interop with existing OAuth implementations: by > introducing id_token, they do not need to touch the supposedly > opaque (which means AS-RS may be doing some proprietary thing > inside it) access token. > 2. Mixing up the audience (for id_token aka authn = client, and for > access_token aka authz = resource server) probably is expanding > the attack surface for security and privacy. > > Although we separated them out, a signed id_token includes the left > hash of access_token so access_token is also protected. > > Best, > > Nat > > On Thu, Jun 21, 2012 at 5:21 AM, Lewis Adam-CAL022 > > wrote: > > Hi Igor, > > As Justin just pointed out, consider the case where the video server > is hosted by the state (e.g. California) and is accessed by police > agencies in Los Angeles, San Francisco, and San Diego. The State of > California's video server is the RS. Each local police agency > (LA/SF/SD) hosts an AS. So when a police officer from LAPD launches > the video client app on the iPhone, the client makes an OAuth request > to the LAPD's AS, which authenticates the police officer using agency > level credentials. The access token issued to the video client app on > the iPhone is a JWT, signed by the agency AS, which might look > something like this: > > {"typ":"JWT","alg":"ES256"} > > {"iss":"https://as.lapd.california.gov", > "prn":"alice@lapd.california.gov ", > "aud":" https://video_server1@state.california.gov", > "iat":1300815780, > "exp":1300819380, > "acr":"password"} > > hq4zk+ZknjggCQgZm7ea8fI79gJEsRy3E8LHDpYXWQIgZpkJN9CMLG8ENR4Nrw+n7iyzixBvKXX8P53BTCT4VghPBWhFYSt9tHWu/AtJfOTh6qaAsNdeCyG86jmtp3TDMwuL/cBUj2OtBZOQMFn7jQ9YB7klIz3RqVL+wNmeWI4= > > The JWT might be optionally encrypted using JWE. > > I think what is becoming clear (and this is what I'm trying to vet) is > that while there is nothing in OAuth that specifies authentication, it > **can** be used for Authentication, if done in the way that I > describe. If I'm wrong about this, I really need to know. I've > vetted this idea of mine with quite of few people now -- both within > context of the list and off-line -- and I think I'm okay. If you see > any holes in what I describe, please point them out as I would prefer > to uncover them now rather than after implementation or deployment! > > Essentially I'm using OAuth as a RESTful version of WS-Trust, where my > client can exchange primary credentials for a token (JWT) and present > that token to a server as secondary authentication. It's just that > it's RESTful instead of SOAP :-) > > As Justin as pointed out ... I've basically made the access-token look > like the id_token of Connect. I was actually hoping to lay a path to > Connect, and use the id_token ... until it was also pointed out that > the id_token is really meant for the consumption of the client, not > the RS :-( > > *From:*oauth-bounces@ietf.org > [mailto:oauth-bounces@ietf.org ] *On > Behalf Of *Igor Faynberg > *Sent:* Wednesday, June 20, 2012 2:39 PM > *To:* oauth@ietf.org > > > *Subject:* Re: [OAUTH-WG] Report an authentication issue > > But this use case does need OAuth, period: > > > > The video server is under the control of a police agency, and police > officers must logon to the video server in order to access video content. > > There is no delegation here, and there is no need to use third party > for authentication. > > Igor > > On 6/20/2012 3:26 PM, Justin Richer wrote: > > In case it wasn't clear, I want to restate the original problem as > best as I understand it in a way that hopefully clears it up: > > App A and app B are both valid registered OAuth clients to an OAuth > protected service. > > The problem starts when app A gets handed a token that was issued for > app B and uses it to call an identity API on the OAuth service. Since > app B can get tokens just fine, they're bearer tokens, this is a > fairly basic api call, this function works just fine and returns the > user info. This makes sense, since anyone who holds A's tokens can do > whatever A can do on behalf of that user. The issues start when app B > then decides that since they can make a call to the identity API with > a token then the user *must* be present. In other words, app B is > confusing authorization to call an API with authentication of the session. > > OpenID Connect fixes this missed assumption by binding the ID Token to > the session and sending it along side the access token, but as you > pointed out, it's meant for consumption at the client, not the > resource server, in general. That doesn't mean you can't send it to a > resource server for your own purposes, of course. That's actually how > the session management endpoint works in Connect. > > This isn't the only way to handle this problem -- if you put some > structure in your tokens, such as with JWT or SAML, then app A can > tell that this isn't a token issued to app A, but to app B, so it can > call shenanigans and reject it then and there. > > -- Justin > > On 06/20/2012 10:03 AM, Lewis Adam-CAL022 wrote: > > I am entirely confused. > > I understand what everybody is saying for confidential clients, no > problem here. > > I fall apart when thinking of iPhone apps. Consider the scenario > where I deploy a video server, and write an iPhone app to talk to the > video server. The video server is under the control of a police > agency, and police officers must logon to the video server in order to > access video content. So the police office launches their iPhone > video client app. > > If I wanted to solve authentication using "traditional" client-server > authentication, the user enters their username / password into the > client, and the client sends the username / password off to the > server, which authenticates it, or possibly uses HTTP digest. > > If I wanted to use OpenID, the client would attempt to reach the video > server (RP), the server would redirect the client to the OP, OP > authenticates user, and OP redirects client back to the server/RP with > an assertion that primary authentication was successful. > > If I wanted to use OAuth, the client would send an authorization > request to the server's AS, which would authenticate the user of the > client, and ultimately result in the client possessing an > access-token. My thinking is that this access token (let's assume > it's a JWT) would contain the user's identity, a statement of what > type of primary authentication was used (auth context), an expiration, > and an audience claim. This sounds a lot like authentication to me, > and it's where I get confused. Is it just because OAuth does not > explicitly define this? Is there a threat in using OAuth as I describe? > > If I wanted to use Connect, well I'm not even sure how the id_token as > defined by Connect helps this use case. The id_token seems to make > sense when the client is a confidential web server, but it's not clear > what an iPhone app would do with the id_token ... it's the server in > the backend that needs to authenticate the user, the iPhone app is > just an interface to talk to the server. And it seems as I learn more > about connect that the id_token is not meant to be sent from the > iPhone app to the server, just the access token. So it's really not > clear how Connect helps solve authentication for an iPhone client app > talking to a video server. If I'm sending access-tokens, it's just > OAuth again. > > What am I still missing? > > adam > > *From:*oauth-bounces@ietf.org > [mailto:oauth-bounces@ietf.org] *On Behalf Of *Kristofor Selden > *Sent:* Saturday, June 16, 2012 11:33 AM > *To:* nov matake; oauth > *Cc:* Yuchen Zhou; Luke Melia; Shuo Chen (MSR) > *Subject:* Re: [OAUTH-WG] Report an authentication issue > > Nov demonstrated the problem to us at Yapp and we used solution 4 > (because the solution is server side and our app was in the app store). > > FB Connect is authentication /and/ authorization, where OAuth 2 is > concerned only with authorization -- I'm not sure that app developers > appreciate this subtlety. > > With OAuth 2 you authorize an app to use a protected resource. With > FB Connect, you do that, but /also/ authenticate with the app you are > authorizing. > > So the access_token protects not just the FB resources but the auth > end point of the authorized app (very common with apps that use the > iOS SDK). So now the app needs a way to verify that it was the app > that was authorized to FB. > > Solution 4 explanation: on FB you can register a iPhone app and a > server app with the same client_id and get a client_secret for use on > the server. The server side API posts the access_token, client_id, > and client_secret to https://graph.facebook.com/app > to verify > that the bearer token actually belongs to the app that is being > authenticated before assuming they are authorized to the app's > protected resources. > > Kris > > On Jun 15, 2012, at 8:22 PM, nov matake wrote: > > > > There are 4 ways to fix this issue. > > 1. Use response_type=token%20code (It's not in OAuth 2.0 Core, but > seems best way for interoperability) > > 2. Use singed_request (or some signed token like JWT) > > 3. Use grant_type=fb_exchange_token (Facebook custom way) > > 4. Access to https://graph.facebook.com/app?access_token=YOUR_TOKEN > (Facebook custom way, moreover undocumented API) > > Two iPhone app developers I reported this issue fixed it by using (4). > > I also tried to use (1) for my own iPhone app implementation, but > unfortunately it doesn't work when using authorization codes obtained > via FB iOS SDK. > > So I'm using (3) in my case. > > nov > > On 2012/06/16, at 9:16, Nat Sakimura wrote: > > > > As to how the fix was done, Nov can provide more detail, but ... > > 1. Properly verify the signature/HMAC of the "signed_request". This > will essentially audience restricts the token. > > 2. There is an undocumented API for Facebook which returns to whom the > token was issued. This also audience restricts the token. > > The service that fixed took these measures. Note that none of the > above is defined in OAuth. > > The same facility was called "id_token" and "check ID endpoint" for > OpenID Connect. > > The scale of the impact is large, too large to disclose the actual > names in the public list, though, eventually, we would publish them in > a paper. > > Nat > > On Sat, Jun 16, 2012 at 5:34 AM, Francisco Corella > > wrote: > > Hi Nat and Rui, > > Rui, you say that the vulnerability that you found was due to a > "common misunderstanding among developers", but the attack you > describe can be carried out against any app that uses the OAuth > "implicit grant flow", which Facebook calls "client-side > authentication". No misunderstanding seems necessary. What > misunderstanding are you referring to? I followed the link in your > message to the Sophos post, and from there the link to the article in > The Register. The article in The Register says that Facebook had > "fixed the vulnerability promptly". How did they fix it? The > instructions that Facebook provides for implementing "Client-side > authentication without the JS SDK" at > https://developers.facebook.com/docs/authentication/client-side/#no-jssdk > still allows the attack. > > Nat, I agree that the blog post by John Bradley that you link to > refers to the same vulnerability reported by Rui. You say that some > apps have issued a patch to fix it. Could you explain what the fix > was? > > Francisco > > ------------------------------------------------------------------------ > > *From:*Nat Sakimura > > *To:* rui wang > > *Cc:* matake nov >; Yuchen > Zhou >; > oauth >; Shuo Chen (MSR) > > > *Sent:* Thursday, June 14, 2012 1:50 PM > *Subject:* Re: [OAUTH-WG] Report an authentication issue > > This is a fairly well known (hopefully by now) issue. We, at the > OpenID Foundation, call it "access_token phishing" attack these > days. See: > http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.html > > Nov Matake has actually built the code on iPhone to verify the > problem, and has notified bunch of parties back in February > including Facebook and Apple. We have the code that actually runs > on a phone, and we have successfully logged in to bunch of apps, > including very well known ones. They were all informed of the > issue. Some immediately issued a patch to fix it while others have > not. > > The problem is that even if these apps gets fixed, the problem > does not go away. As long as the attacker has the vulnerable > version of the app, he still can impersonate the victim. To stop > it, the server side has to completely disable the older version, > which means the service has to cut off many users pausing business > problems. > > Nat > > On Fri, Jun 15, 2012 at 2:18 AM, rui wang > wrote: > > Dear Facebook Security Team and OAuth Standard group, > > We are a research team in Microsoft Research. In January, 2011, we > reported a vulnerability in Facebook Connect which allowed > everyone to sign into Facebook-secured relying parties without > password. It was promptly fixed after reporting. > (http://nakedsecurity.sophos.com/2011/02/02/facebook-flaw-websites-steal-personal-data/) > > Recently, we found a common misunderstanding among developers of > mobile/metro apps when using OAuth (including Facebook's OAuth) > for authentication. The vulnerability resulted from this > misunderstanding also allows an attacker to log into a victim > user's account without password. > > Let's take Soluto's metro app as an example to describe the > problem. The app supports Facebook Login. As an attacker, we can > write a regular Facebook app. Once the victim user allows our app > to access her Facebook data, we receive an access_token from the > traffic. Then, on our own machine (i.e., the "attacker" machine), > we run the metro app of Soluto, and use a HTTP proxy to insert the > victim's access_token into the traffic of Facebook login. Through > this way, we are able to log into the victim's Soluto account from > our machine. Other than Soluto, we also have confirmed the same > issue on another Windows 8 metro-app Givit. > > The Facebook SDK for Android apps > (https://developers.facebook.com/docs/mobile/android/build/#sdk) > seems to have the possibility to mislead developers too. At least, > the issue that we found is not clearly mentioned. In the SDK, we > ran the sample code called "Hackbook" using Android Emulator > (imagine it is an attacker device). Note that we have already > received the access token of the victim user from our regular > Facebook app. We then inject the token to the traffic of Hackbook. > Through this way, Hackbook app on our own machine recognizes us as > the victim. Note that this is not a convincing security exploit > yet, because this sample code does not include the server-side > code. However, given that we have seen real server-side code > having this problem, such as Soluto, Givit and others, we do > believe that the sample code can mislead mobile/metro developers. > We also suspect that this may be a general issue of many OAuth > implementations on mobile platforms, so we send this message to > OAuth Standard group as well. > > We have contacted the vendors of the two vulnerable metro-apps, > Soluto and Gavit. > > Please kindly give us an ack when you receive this message. If you > want to know more details, please let us know. > > Best Regards, > Yuchen Zhou, Rui Wang, and Shuo Chen > > > _______________________________________________ > 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 > > > > -- > 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 > > > > _______________________________________________ > OAuth mailing 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 > --------------070209060208070007000900 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
+1 for exploring.

Igor

On 6/21/2012 12:01 PM, Lewis Adam-CAL022 wrote:
...

This is the world I’m trying to migrate from, and it really seems like I’m sometimes trying to make a square peg fit in a round hole.  I’m looking for OAuth/Connect to do for REST what WS-TRUST did for SOAP.  I would like a native client talking to a RS to be able to ask for an id_token, and then pass that id_token to the RS when making its RESTful API calls, to enable the RS to authenticate the user.  I think that this would be really useful for a lot of people besides me.  I keep hearing that there is nothing “preventing” me from doing this … but it hardly seems within the spirit of what OAuth was meant to do.  The id_token was clearly meant to enable a user to authenticate to a confidential client  / web server … but was not meant for a native client to identity / authenticate the user to a RS. 

 

 

Would there be any interest in exploring this further?

-adam

 

 

From: Nat Sakimura [mailto:sakimura@gmail.com]
Sent: Wednesday, June 20, 2012 8:09 PM
To: Lewis Adam-CAL022
Cc: igor.faynberg@alcatel-lucent.com; oauth@ietf.org
Subject: Re: [OAUTH-WG] Report an authentication issue

 

Yes, OAuth can be profiled to enable authentication. 

In fact, initial draft of OpenID Connect was just like you described. 

Essentially, we were using structured access_token. 

Later, we decided to separate the access token and id_token for several reasons such as: 

 

  1. Better interop with existing OAuth implementations: by introducing id_token, they do not need to touch the supposedly opaque (which means AS-RS may be doing some proprietary thing inside it) access token. 
  2. Mixing up the audience (for id_token aka authn = client, and for access_token aka authz = resource server) probably is expanding the attack surface for security and privacy. 

Although we separated them out, a signed id_token includes the left hash of access_token so access_token is also protected. 

 

Best, 

 

Nat

 

On Thu, Jun 21, 2012 at 5:21 AM, Lewis Adam-CAL022 <Adam.Lewis@motorolasolutions.com> wrote:

Hi Igor,

 

As Justin just pointed out, consider the case where the video server is hosted by the state (e.g. California) and is accessed by police agencies in Los Angeles, San Francisco, and San Diego.  The State of California’s video server is the RS.  Each local police agency (LA/SF/SD) hosts an AS.  So when a police officer from LAPD launches the video client app on the iPhone, the client makes an OAuth request to the LAPD’s AS, which authenticates the police officer using agency level credentials.  The access token issued to the video client app on the iPhone is a JWT, signed by the agency AS, which might look something like this:

 

{“typ”:”JWT”,"alg":"ES256"}

{"iss":"https://as.lapd.california.gov",
  "prn":"alice@lapd.california.gov",
  "aud":" https://video_server1@state.california.gov",
  "iat":1300815780,
  "exp":1300819380,
  "acr":”password”}

hq4zk+ZknjggCQgZm7ea8fI79gJEsRy3E8LHDpYXWQIgZpkJN9CMLG8ENR4Nrw+n7iyzixBvKXX8P53BTCT4VghPBWhFYSt9tHWu/AtJfOTh6qaAsNdeCyG86jmtp3TDMwuL/cBUj2OtBZOQMFn7jQ9YB7klIz3RqVL+wNmeWI4=

 

The JWT might be optionally encrypted using JWE. 

 

I think what is becoming clear (and this is what I’m trying to vet) is that while there is nothing in OAuth that specifies authentication, it *can* be used for Authentication, if done in the way that I describe.  If I’m wrong about this, I really need to know.  I’ve vetted this idea of mine with quite of few people now – both within context of the list and off-line – and I think I’m okay. If you see any holes in what I describe, please point them out as I would prefer to uncover them now rather than after implementation or deployment!

 

Essentially I’m using OAuth as a RESTful version of WS-Trust, where my client can exchange primary credentials for a token (JWT) and present that token to a server as secondary authentication.  It’s just that it’s RESTful instead of SOAP :-)

 

As Justin as pointed out … I’ve basically made the access-token look like the id_token of Connect.  I was actually hoping to lay a path to Connect, and use the id_token … until it was also pointed out that the id_token is really meant for the consumption of the client, not the RS :-(

 

 

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Igor Faynberg
Sent: Wednesday, June 20, 2012 2:39 PM
To: oauth@ietf.org


Subject: Re: [OAUTH-WG] Report an authentication issue

 

But this use case  does need OAuth, period:



The video server is under the control of a police agency, and police officers must logon to the video server in order to access video content.

There is no delegation here, and there is no need to use third party for authentication. 

Igor

On 6/20/2012 3:26 PM, Justin Richer wrote:

In case it wasn't clear, I want to restate the original problem as best as I understand it in a way that hopefully clears it up:

App A and app B are both valid registered OAuth clients to an OAuth protected service.

The problem starts when app A gets handed a token that was issued for app B and uses it to call an identity API on the OAuth service. Since app B can get tokens just fine, they're bearer tokens, this is a fairly basic api call, this function works just fine and returns the user info. This makes sense, since anyone who holds A's tokens can do whatever A can do on behalf of that user. The issues start when app B then decides that since they can make a call to the identity API with a token then the user *must* be present. In other words, app B is confusing authorization to call an API with authentication of the session.

OpenID Connect fixes this missed assumption by binding the ID Token to the session and sending it along side the access token, but as you pointed out, it's meant for consumption at the client, not the resource server, in general. That doesn't mean you can't send it to a resource server for your own purposes, of course. That's actually how the session management endpoint works in Connect.

This isn't the only way to handle this problem -- if you put some structure in your tokens, such as with JWT or SAML, then app A can tell that this isn't a token issued to app A, but to app B, so it can call shenanigans and reject it then and there.

 -- Justin

On 06/20/2012 10:03 AM, Lewis Adam-CAL022 wrote:

I am entirely confused.

 

I understand what everybody is saying for confidential clients, no problem here.

 

I fall apart when thinking of iPhone apps.  Consider the scenario where I deploy a video server, and write an iPhone app to talk to the video server.  The video server is under the control of a police agency, and police officers must logon to the video server in order to access video content.  So the police office launches their iPhone video client app.

 

If I wanted to solve authentication using “traditional” client-server authentication, the user enters their username / password into the client, and the client sends the username / password off to the server, which authenticates it, or possibly uses HTTP digest. 

If I wanted to use OpenID, the client would attempt to reach the video server (RP), the server would redirect the client to the OP, OP authenticates user, and OP redirects client back to the server/RP with an assertion that primary authentication was successful. 

If I wanted to use OAuth, the client would send an authorization request to the server’s AS, which would authenticate the user of the client, and ultimately result in the client possessing an access-token.  My thinking is that this access token (let’s assume it’s a JWT) would contain the user’s identity, a statement of what type of primary authentication was used (auth context), an expiration, and an audience claim.  This sounds a lot like authentication to me, and it’s where I get confused.  Is it just because OAuth does not explicitly define this?  Is there a threat in using OAuth as I describe? 

If I wanted to use Connect, well I’m not even sure how the id_token as defined by Connect helps this use case.  The id_token seems to make sense when the client is a confidential web server, but it’s not clear what an iPhone app would do with the id_token … it’s the server in the backend that needs to authenticate the user, the iPhone app is just an interface to talk to the server.  And it seems as I learn more about connect that the id_token is not meant to be sent from the iPhone app to the server, just the access token.  So it’s really not clear how Connect helps solve authentication for an iPhone client app talking to a video server.  If I’m sending access-tokens, it’s just OAuth again.

 

What am I still missing?

adam

 

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Kristofor Selden
Sent: Saturday, June 16, 2012 11:33 AM
To: nov matake; oauth
Cc: Yuchen Zhou; Luke Melia; Shuo Chen (MSR)
Subject: Re: [OAUTH-WG] Report an authentication issue

 

Nov demonstrated the problem to us at Yapp and we used solution 4 (because the solution is server side and our app was in the app store).

 

FB Connect is authentication and authorization, where OAuth 2 is concerned only with authorization – I'm not sure that app developers appreciate this subtlety.

 

With OAuth 2 you authorize an app to use a protected resource.  With FB Connect, you do that, but also authenticate with the app you are authorizing.

 

So the access_token protects not just the FB resources but the auth end point of the authorized app (very common with apps that use the iOS SDK).  So now the app needs a way to verify that it was the app that was authorized to FB.

 

Solution 4 explanation: on FB you can register a iPhone app and a server app with the same client_id and get a client_secret for use on the server.  The server side API posts the access_token, client_id, and client_secret to https://graph.facebook.com/app to verify that the bearer token actually belongs to the app that is being authenticated before assuming they are authorized to the app's protected resources.

 

Kris

 

On Jun 15, 2012, at 8:22 PM, nov matake wrote:



There are 4 ways to fix this issue.

 

1. Use response_type=token%20code (It's not in OAuth 2.0 Core, but seems best way for interoperability)

2. Use singed_request (or some signed token like JWT)

3. Use grant_type=fb_exchange_token (Facebook custom way)

4. Access to https://graph.facebook.com/app?access_token=YOUR_TOKEN (Facebook custom way, moreover undocumented API)

 

Two iPhone app developers I reported this issue fixed it by using (4).

 

I also tried to use (1) for my own iPhone app implementation, but unfortunately it doesn't work when using authorization codes obtained via FB iOS SDK.

So I'm using (3) in my case.

 

nov

 

On 2012/06/16, at 9:16, Nat Sakimura wrote:



As to how the fix was done, Nov can provide more detail, but ... 

 

1. Properly verify the signature/HMAC of the "signed_request". This will essentially audience restricts the token. 

2. There is an undocumented API for Facebook which returns to whom the token was issued. This also audience restricts the token. 

 

The service that fixed took these measures. Note that none of the above is defined in OAuth. 

The same facility was called "id_token" and "check ID endpoint" for OpenID Connect. 

 

The scale of the impact is large, too large to disclose the actual names in the public list, though, eventually, we would publish them in a paper. 

 

Nat

On Sat, Jun 16, 2012 at 5:34 AM, Francisco Corella <fcorella@pomcor.com> wrote:

Hi Nat and Rui,

Rui, you say that the vulnerability that you found was due to a
"common misunderstanding among developers", but the attack you
describe can be carried out against any app that uses the OAuth
"implicit grant flow", which Facebook calls "client-side
authentication".  No misunderstanding seems necessary.  What
misunderstanding are you referring to?  I followed the link in your
message to the Sophos post, and from there the link to the article in
The Register.  The article in The Register says that Facebook had
"fixed the vulnerability promptly".  How did they fix it?  The
instructions that Facebook provides for implementing "Client-side
authentication without the JS SDK" at
https://developers.facebook.com/docs/authentication/client-side/#no-jssdk
still allows the attack.

Nat, I agree that the blog post by John Bradley that you link to
refers to the same vulnerability reported by Rui.  You say that some
apps have issued a patch to fix it.  Could you explain what the fix
was?

Francisco

 

From: Nat Sakimura <sakimura@gmail.com>
To: rui wang <ruiwangwarm@gmail.com>
Cc: matake nov <nov@matake.jp>; Yuchen Zhou <t-yuzhou@microsoft.com>; oauth <oauth@ietf.org>; Shuo Chen (MSR) <shuochen@microsoft.com>
Sent: Thursday, June 14, 2012 1:50 PM
Subject: Re: [OAUTH-WG] Report an authentication issue

 

This is a fairly well known (hopefully by now) issue. We, at the OpenID Foundation, call it "access_token phishing" attack these days. See: http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.html

 

Nov Matake has actually built the code on iPhone to verify the problem, and has notified bunch of parties back in February including Facebook and Apple. We have the code that actually runs on a phone, and we have successfully logged in to bunch of apps, including very well known ones. They were all informed of the issue. Some immediately issued a patch to fix it while others have not.  

 

The problem is that even if these apps gets fixed, the problem does not go away. As long as the attacker has the vulnerable version of the app, he still can impersonate the victim. To stop it, the server side has to completely disable the older version, which means the service has to cut off many users pausing business problems. 

 

Nat

On Fri, Jun 15, 2012 at 2:18 AM, rui wang <ruiwangwarm@gmail.com> wrote:

Dear Facebook Security Team and OAuth Standard group,

We are a research team in Microsoft Research. In January, 2011, we reported a vulnerability in Facebook Connect which allowed everyone to sign into Facebook-secured relying parties without password. It was promptly fixed after reporting. (http://nakedsecurity.sophos.com/2011/02/02/facebook-flaw-websites-steal-personal-data/)

Recently, we found a common misunderstanding among developers of mobile/metro apps when using OAuth (including Facebook’s OAuth) for authentication. The vulnerability resulted from this misunderstanding also allows an attacker to log into a victim user's account without password.

Let's take Soluto's metro app as an example to describe the problem. The app supports Facebook Login. As an attacker, we can write a regular Facebook app. Once the victim user allows our app to access her Facebook data, we receive an access_token from the traffic. Then, on our own machine (i.e., the "attacker" machine), we run the metro app of Soluto, and use a HTTP proxy to insert the victim's access_token into the traffic of Facebook login. Through this way, we are able to log into the victim's Soluto account from our machine. Other than Soluto, we also have confirmed the same issue on another Windows 8 metro-app Givit.

The Facebook SDK for Android apps (https://developers.facebook.com/docs/mobile/android/build/#sdk) seems to have the possibility to mislead developers too. At least, the issue that we found is not clearly mentioned. In the SDK, we ran the sample code called "Hackbook" using Android Emulator (imagine it is an attacker device). Note that we have already received the access token of the victim user from our regular Facebook app. We then inject the token to the traffic of Hackbook. Through this way, Hackbook app on our own machine recognizes us as the victim. Note that this is not a convincing security exploit yet, because this sample code does not include the server-side code. However, given that we have seen real server-side code having this problem, such as Soluto, Givit and others, we do believe that the sample code can mislead mobile/metro developers. We also suspect that this may be a general issue of many OAuth implementations on mobile platforms, so we send this message to OAuth Standard group as well.

We have contacted the vendors of the two vulnerable metro-apps, Soluto and Gavit.

Please kindly give us an ack when you receive this message. If you want to know more details, please let us know.

Best Regards,
Yuchen Zhou, Rui Wang, and Shuo Chen


_______________________________________________
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



 

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

 

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

 

--------------070209060208070007000900-- From phil.hunt@oracle.com Thu Jun 21 09:33:31 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A657421F86EF for ; Thu, 21 Jun 2012 09:33:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.365 X-Spam-Level: X-Spam-Status: No, score=-10.365 tagged_above=-999 required=5 tests=[AWL=0.232, 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 Qnln3O8nCVj7 for ; Thu, 21 Jun 2012 09:33:28 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id 4ECF521F86DF for ; Thu, 21 Jun 2012 09:33:28 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q5LGXKsS026877 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 21 Jun 2012 16:33:21 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q5LGXJsM009269 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jun 2012 16:33:20 GMT Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q5LGXJKP032465; Thu, 21 Jun 2012 11:33:19 -0500 Received: from [192.168.1.7] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 21 Jun 2012 09:33:17 -0700 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_EA662110-4B00-431A-9F27-D1506F88D68F" From: Phil Hunt In-Reply-To: <4FE34B9D.1040200@alcatel-lucent.com> Date: Thu, 21 Jun 2012 09:33:05 -0700 Message-Id: References: <1339792496.52712.YahooMailNeo@web125501.mail.ne1.yahoo.com> <59E470B10C4630419ED717AC79FCF9A9108898EE@BL2PRD0410MB363.namprd04.prod.outlook.com> <4FE223E4.6060307@mitre.org> <4FE226BC.6010403@alcatel-lucent.com> <59E470B10C4630419ED717AC79FCF9A910889AB5@BL2PRD0410MB363.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A917052BC8@SN2PRD0410MB370.namprd04.prod.outlook.com> <4FE34B9D.1040200@alcatel-lucent.com> To: igor.faynberg@alcatel-lucent.com X-Mailer: Apple Mail (2.1278) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Report an authentication issue X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 16:33:31 -0000 --Apple-Mail=_EA662110-4B00-431A-9F27-D1506F88D68F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I see elements of improper use of OAuth flows as well as improper use of = bearer tokens. We have to keep it a simple comment in both specs. As for exploration, I would support it being explored more in the next = OAuthWG charter (if it can be fit in). Phil @independentid www.independentid.com phil.hunt@oracle.com On 2012-06-21, at 9:28 AM, Igor Faynberg wrote: >=20 > +1 for exploring. >=20 > Igor >=20 > On 6/21/2012 12:01 PM, Lewis Adam-CAL022 wrote: >>=20 >> ... >> This is the world I=92m trying to migrate from, and it really seems = like I=92m sometimes trying to make a square peg fit in a round hole. = I=92m looking for OAuth/Connect to do for REST what WS-TRUST did for = SOAP. I would like a native client talking to a RS to be able to ask = for an id_token, and then pass that id_token to the RS when making its = RESTful API calls, to enable the RS to authenticate the user. I think = that this would be really useful for a lot of people besides me. I keep = hearing that there is nothing =93preventing=94 me from doing this =85 = but it hardly seems within the spirit of what OAuth was meant to do. = The id_token was clearly meant to enable a user to authenticate to a = confidential client / web server =85 but was not meant for a native = client to identity / authenticate the user to a RS.=20 >> =20 >> =20 >> Would there be any interest in exploring this further? >> -adam >> =20 >> =20 >> From: Nat Sakimura [mailto:sakimura@gmail.com]=20 >> Sent: Wednesday, June 20, 2012 8:09 PM >> To: Lewis Adam-CAL022 >> Cc: igor.faynberg@alcatel-lucent.com; oauth@ietf.org >> Subject: Re: [OAUTH-WG] Report an authentication issue >> =20 >> Yes, OAuth can be profiled to enable authentication.=20 >> In fact, initial draft of OpenID Connect was just like you described.=20= >> Essentially, we were using structured access_token.=20 >> Later, we decided to separate the access token and id_token for = several reasons such as:=20 >> =20 >> Better interop with existing OAuth implementations: by introducing = id_token, they do not need to touch the supposedly opaque (which means = AS-RS may be doing some proprietary thing inside it) access token.=20 >> Mixing up the audience (for id_token aka authn =3D client, and for = access_token aka authz =3D resource server) probably is expanding the = attack surface for security and privacy.=20 >> Although we separated them out, a signed id_token includes the left = hash of access_token so access_token is also protected.=20 >> =20 >> Best,=20 >> =20 >> Nat >> =20 >> On Thu, Jun 21, 2012 at 5:21 AM, Lewis Adam-CAL022 = wrote: >> Hi Igor, >> =20 >> As Justin just pointed out, consider the case where the video server = is hosted by the state (e.g. California) and is accessed by police = agencies in Los Angeles, San Francisco, and San Diego. The State of = California=92s video server is the RS. Each local police agency = (LA/SF/SD) hosts an AS. So when a police officer from LAPD launches the = video client app on the iPhone, the client makes an OAuth request to the = LAPD=92s AS, which authenticates the police officer using agency level = credentials. The access token issued to the video client app on the = iPhone is a JWT, signed by the agency AS, which might look something = like this: >> =20 >> {=93typ=94:=94JWT=94,"alg":"ES256"} >> {"iss":"https://as.lapd.california.gov",=20 >> "prn":"alice@lapd.california.gov", >> "aud":" https://video_server1@state.california.gov", >> "iat":1300815780, >> "exp":1300819380, >> "acr":=94password=94} >> = hq4zk+ZknjggCQgZm7ea8fI79gJEsRy3E8LHDpYXWQIgZpkJN9CMLG8ENR4Nrw+n7iyzixBvKX= X8P53BTCT4VghPBWhFYSt9tHWu/AtJfOTh6qaAsNdeCyG86jmtp3TDMwuL/cBUj2OtBZOQMFn7= jQ9YB7klIz3RqVL+wNmeWI4=3D >> =20 >> The JWT might be optionally encrypted using JWE.=20 >> =20 >> I think what is becoming clear (and this is what I=92m trying to vet) = is that while there is nothing in OAuth that specifies authentication, = it *can* be used for Authentication, if done in the way that I describe. = If I=92m wrong about this, I really need to know. I=92ve vetted this = idea of mine with quite of few people now =96 both within context of the = list and off-line =96 and I think I=92m okay. If you see any holes in = what I describe, please point them out as I would prefer to uncover them = now rather than after implementation or deployment! >> =20 >> Essentially I=92m using OAuth as a RESTful version of WS-Trust, where = my client can exchange primary credentials for a token (JWT) and present = that token to a server as secondary authentication. = It=92s just that it=92s RESTful instead of SOAP :-) >> =20 >> As Justin as pointed out =85 I=92ve basically made the access-token = look like the id_token of Connect. I was actually hoping to lay a path = to Connect, and use the id_token =85 until it was also pointed out that = the id_token is really meant for the consumption of the client, not the = RS :-( >> =20 >> =20 >> =20 >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf Of Igor Faynberg >> Sent: Wednesday, June 20, 2012 2:39 PM >> To: oauth@ietf.org >>=20 >> Subject: Re: [OAUTH-WG] Report an authentication issue >> =20 >> But this use case does need OAuth, period: >>=20 >>=20 >> The video server is under the control of a police agency, and police = officers must logon to the video server in order to access video = content. >>=20 >> There is no delegation here, and there is no need to use third party = for authentication. =20 >>=20 >> Igor >>=20 >> On 6/20/2012 3:26 PM, Justin Richer wrote: >> In case it wasn't clear, I want to restate the original problem as = best as I understand it in a way that hopefully clears it up: >>=20 >> App A and app B are both valid registered OAuth clients to an OAuth = protected service.=20 >>=20 >> The problem starts when app A gets handed a token that was issued for = app B and uses it to call an identity API on the OAuth service. Since = app B can get tokens just fine, they're bearer tokens, this is a fairly = basic api call, this function works just fine and returns the user info. = This makes sense, since anyone who holds A's tokens can do whatever A = can do on behalf of that user. The issues start when app B then decides = that since they can make a call to the identity API with a token then = the user *must* be present. In other words, app B is confusing = authorization to call an API with authentication of the session. >>=20 >> OpenID Connect fixes this missed assumption by binding the ID Token = to the session and sending it along side the access token, but as you = pointed out, it's meant for consumption at the client, not the resource = server, in general. That doesn't mean you can't send it to a resource = server for your own purposes, of course. That's actually how the session = management endpoint works in Connect. >>=20 >> This isn't the only way to handle this problem -- if you put some = structure in your tokens, such as with JWT or SAML, then app A can tell = that this isn't a token issued to app A, but to app B, so it can call = shenanigans and reject it then and there. >>=20 >> -- Justin >>=20 >> On 06/20/2012 10:03 AM, Lewis Adam-CAL022 wrote: >> I am entirely confused. >> =20 >> I understand what everybody is saying for confidential clients, no = problem here. >> =20 >> I fall apart when thinking of iPhone apps. Consider the scenario = where I deploy a video server, and write an iPhone app to talk to the = video server. The video server is under the control of a police agency, = and police officers must logon to the video server in order to access = video content. So the police office launches their iPhone video client = app. >> =20 >> If I wanted to solve authentication using =93traditional=94 = client-server authentication, the user enters their username / password = into the client, and the client sends the username / password off to the = server, which authenticates it, or possibly uses HTTP digest. =20 >>=20 >>=20 >> If I wanted to use OpenID, the client would attempt to reach the = video server (RP), the server would redirect the client to the OP, OP = authenticates user, and OP redirects client back to the server/RP with = an assertion that primary authentication was successful. =20 >>=20 >>=20 >> If I wanted to use OAuth, the client would send an authorization = request to the server=92s AS, which would authenticate the user of the = client, and ultimately result in the client possessing an access-token. = My thinking is that this access token (let=92s assume it=92s a JWT) = would contain the user=92s identity, a statement = of what type of primary authentication was used (auth context), an = expiration, and an audience claim. This sounds a lot like = authentication to me, and it=92s where I get confused. Is it just = because OAuth does not explicitly define this? Is there a threat in = using OAuth as I describe? =20 >>=20 >>=20 >> If I wanted to use Connect, well I=92m not even sure how the id_token = as defined by Connect helps this use case. The id_token seems to make = sense when the client is a confidential web server, but it=92s not clear = what an iPhone app would do with the id_token =85 it=92s the server in = the backend that needs to authenticate the user, the iPhone app is just = an interface to talk to the server. And it seems as I learn more about = connect that the id_token is not meant to be sent from the iPhone app to = the server, just the access token. So it=92s really not clear how = Connect helps solve authentication for an iPhone client app talking to a = video server. If I=92m sending access-tokens, it=92s just OAuth again. >>=20 >> =20 >> What am I still missing? >> adam >> =20 >> =20 >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf Of Kristofor Selden >> Sent: Saturday, June 16, 2012 11:33 AM >> To: nov matake; oauth >> Cc: Yuchen Zhou; Luke Melia; Shuo Chen (MSR) >> Subject: Re: [OAUTH-WG] Report an authentication issue >> =20 >> Nov demonstrated the problem to us at Yapp and we used solution 4 = (because the solution is server side and our app was in the app store). >> =20 >> FB Connect is authentication and authorization, where OAuth 2 is = concerned only with authorization =96 I'm not sure that app developers = appreciate this subtlety. >> =20 >> With OAuth 2 you authorize an app to use a protected resource. With = FB Connect, you do that, but also authenticate with the app you are = authorizing. >> =20 >> So the access_token protects not just the FB resources but the auth = end point of the authorized app (very common with apps that use the iOS = SDK). So now the app needs a way to verify that it was the app that was = authorized to FB. >> =20 >> Solution 4 explanation: on FB you can register a iPhone app and a = server app with the same client_id and get a client_secret for use on = the server. The server side API posts the access_token, client_id, and = client_secret to https://graph.facebook.com/app to verify that the = bearer token actually belongs to the app that is being authenticated = before assuming they are authorized to the app's protected resources. >> =20 >> Kris >> =20 >> On Jun 15, 2012, at 8:22 PM, nov matake wrote: >>=20 >>=20 >>=20 >> There are 4 ways to fix this issue. >> =20 >> 1. Use response_type=3Dtoken%20code (It's not in OAuth 2.0 Core, but = seems best way for interoperability) >> 2. Use singed_request (or some signed token like JWT) >> 3. Use grant_type=3Dfb_exchange_token (Facebook custom way) >> 4. Access to https://graph.facebook.com/app?access_token=3DYOUR_TOKEN = (Facebook custom way, moreover undocumented API) >> =20 >> Two iPhone app developers I reported this issue fixed it by using = (4). >> =20 >> I also tried to use (1) for my own iPhone app implementation, but = unfortunately it doesn't work when using authorization codes obtained = via FB iOS SDK. >> So I'm using (3) in my case. >> =20 >> nov >> =20 >> On 2012/06/16, at 9:16, Nat Sakimura wrote: >>=20 >>=20 >>=20 >> As to how the fix was done, Nov can provide more detail, but ...=20 >> =20 >> 1. Properly verify the signature/HMAC of the "signed_request". This = will essentially audience restricts the token.=20 >> 2. There is an undocumented API for Facebook which returns to whom = the token was issued. This also audience restricts the token.=20 >> =20 >> The service that fixed took these measures. Note that none of the = above is defined in OAuth.=20 >> The same facility was called "id_token" and "check ID endpoint" for = OpenID Connect.=20 >> =20 >> The scale of the impact is large, too large to disclose the actual = names in the public list, though, eventually, we would publish them in a = paper.=20 >> =20 >> Nat >>=20 >> On Sat, Jun 16, 2012 at 5:34 AM, Francisco Corella = wrote: >>=20 >>=20 >> Hi Nat and Rui, >>=20 >> Rui, you say that the vulnerability that you found was due to a >> "common misunderstanding among developers", but the attack you >> describe can be carried out against any app that uses the OAuth >> "implicit grant flow", which Facebook calls "client-side >> authentication". No misunderstanding seems necessary. What >> misunderstanding are you referring to? I followed the link in your >> message to the Sophos post, and from there the link to the article in >> The Register. The article in The Register says that Facebook had >> "fixed the vulnerability promptly". How did they fix it? The >> instructions that Facebook provides for implementing "Client-side >> authentication without the JS SDK" at >> = https://developers.facebook.com/docs/authentication/client-side/#no-jssdk >> still allows the attack. >>=20 >> Nat, I agree that the blog post by John Bradley that you link to >> refers to the same vulnerability reported by Rui. You say that some >> apps have issued a patch to fix it. Could you explain what the fix >> was? >>=20 >> Francisco >> =20 >> From: Nat Sakimura >> To: rui wang =20 >> Cc: matake nov ; Yuchen Zhou ; = oauth ; Shuo Chen (MSR) =20 >> Sent: Thursday, June 14, 2012 1:50 PM >> Subject: Re: [OAUTH-WG] Report an authentication issue >> =20 >> This is a fairly well known (hopefully by now) issue. We, at the = OpenID Foundation, call it "access_token phishing" attack these days. = See: = http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.h= tml >> =20 >> Nov Matake has actually built the code on iPhone to verify the = problem, and has notified bunch of parties back in February including = Facebook and Apple. We have the code that actually runs on a phone, and = we have successfully logged in to bunch of apps, including very well = known ones. They were all informed of the issue. Some immediately issued = a patch to fix it while others have not. =20 >> =20 >> The problem is that even if these apps gets fixed, the problem does = not go away. As long as the attacker has the vulnerable version of the = app, he still can impersonate the victim. To stop it, the server side = has to completely disable the older version, which means the service has = to cut off many users pausing business problems.=20 >> =20 >> Nat >>=20 >> On Fri, Jun 15, 2012 at 2:18 AM, rui wang = wrote: >> Dear Facebook Security Team and OAuth Standard group, >> We are a research team in Microsoft Research. In January, 2011, we = reported a vulnerability in Facebook Connect which allowed everyone to = sign into Facebook-secured relying parties without password. It was = promptly fixed after reporting. = (http://nakedsecurity.sophos.com/2011/02/02/facebook-flaw-websites-steal-p= ersonal-data/) >> Recently, we found a common misunderstanding among developers of = mobile/metro apps when using OAuth (including Facebook=92s OAuth) for = authentication. The vulnerability resulted from this misunderstanding = also allows an attacker to log into a victim user's account = without password. >> Let's take Soluto's metro app as an example to describe the problem. = The app supports Facebook Login. As an attacker, we can write a regular = Facebook app. Once the victim user allows our app to access her Facebook = data, we receive an access_token from the traffic. Then, on our own = machine (i.e., the "attacker" machine), we run the metro app of Soluto, = and use a HTTP proxy to insert the victim's access_token into the = traffic of Facebook login. Through this way, we are able to log into the = victim's Soluto account from our machine. Other than Soluto, we also = have confirmed the same issue on another Windows 8 metro-app Givit. >> The Facebook SDK for Android apps = (https://developers.facebook.com/docs/mobile/android/build/#sdk) seems = to have the possibility to mislead developers too. At least, the issue = that we found is not clearly mentioned. In the SDK, we ran the sample = code called "Hackbook" = using Android Emulator (imagine it is an attacker device). Note = that we have already received the access token of the victim user from = our regular = Facebook app. We then inject the token to the traffic of Hackbook. = Through this way, Hackbook app on our own machine recognizes us as the = victim. Note that this is not a convincing security exploit yet, because = this sample code does not include the server-side code. However, given = that we have seen real server-side code having this problem, such as = Soluto, Givit and others, we do believe that the sample code can mislead = mobile/metro developers. We also suspect that this may be a general = issue of many OAuth implementations on mobile platforms, so we send this = message to OAuth Standard group as well. >> We have contacted the vendors of the two vulnerable metro-apps, = Soluto and Gavit. >> Please kindly give us an ack when you receive this message. If you = want to know more details, please let us know. >> Best Regards, >> Yuchen Zhou, Rui Wang, and Shuo Chen >>=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 >> =20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >>=20 >>=20 >> =20 >> --=20 >> Nat Sakimura (=3Dnat) >> Chairman, OpenID Foundation >> http://nat.sakimura.org/ >> @_nat_en >> =20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> =20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> =20 >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> =20 >>=20 >> =20 >> =20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >>=20 >> =20 >> --=20 >> Nat Sakimura (=3Dnat) >> Chairman, OpenID Foundation >> http://nat.sakimura.org/ >> @_nat_en >> =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_EA662110-4B00-431A-9F27-D1506F88D68F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Phil

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





On 2012-06-21, at 9:28 AM, Igor Faynberg wrote:

=20 =20

+1 for exploring.

Igor

On 6/21/2012 12:01 PM, Lewis Adam-CAL022 wrote:
...

This is the world I=92m trying to migrate from, and it really = seems like I=92m sometimes trying to make a square peg fit in a round hole.  I=92m looking for OAuth/Connect to do for = REST what WS-TRUST did for SOAP.  I would like a native = client talking to a RS to be able to ask for an id_token, and then pass that id_token to the RS when making its RESTful API calls, to enable the RS to authenticate the user.  I = think that this would be really useful for a lot of people besides me.  I keep hearing that there is nothing =93preventing=94= me from doing this =85 but it hardly seems within the spirit of what OAuth was meant to do.  The id_token was clearly = meant to enable a user to authenticate to a confidential client =  / web server =85 but was not meant for a native client to identity / authenticate the user to a RS. 

 

 

Would there be any interest in exploring this = further?

-adam

 

 

From: Nat Sakimura [mailto:sakimura@gmail.com]
Sent: Wednesday, June 20, 2012 8:09 PM
To: Lewis Adam-CAL022
Cc: igor.faynberg@alcatel-luc= ent.com; oauth@ietf.org
Subject: Re: [OAUTH-WG] Report an authentication issue

 

Yes, OAuth can be profiled to enable authentication. 

In fact, initial draft of OpenID = Connect was just like you described. 

Essentially, we were using = structured access_token. 

Later, we decided to separate the = access token and id_token for several reasons such = as: 

 

  1. Better interop with existing OAuth implementations: by introducing id_token, they do not need to touch the supposedly opaque (which means AS-RS may be doing some proprietary thing inside it) access = token. 
  2. Mixing up the audience (for id_token aka authn =3D client, and for access_token aka authz =3D resource server) = probably is expanding the attack surface for security and = privacy. 

Although we separated them out, a = signed id_token includes the left hash of access_token so access_token is also protected. 

 

Best, 

 

Nat

 

On Thu, Jun 21, 2012 at 5:21 AM, = Lewis Adam-CAL022 <Adam.Lewis@motorolasolutions.com> wrote:

Hi Igor,

 

As Justin just pointed out, consider the case where the video server is hosted by the state (e.g. California) and is accessed by police agencies in Los Angeles, San Francisco, and San Diego.  = The State of California=92s video server is the = RS.  Each local police agency (LA/SF/SD) hosts an AS.  So = when a police officer from LAPD launches the video client app on the iPhone, the client makes an OAuth request to the LAPD=92s AS, which authenticates the police officer using agency level credentials.  The = access token issued to the video client app on the iPhone is a JWT, signed by the agency AS, which might look something like this:

 

{=93typ=94:=94JWT=94,"alg":"ES256"}

{"iss":"https://as.lapd.california.gov",
  "prn":"alice@lapd.california.gov",
  "aud":" https://video_server1@state.california.gov",
  "iat":1300815780,
  "exp":1300819380,
  "acr":=94password=94}

hq4zk+ZknjggCQgZm7ea8fI79gJEsRy3E8LHDpYXWQIgZpkJN9CMLG8ENR4Nrw+n7i= yzixBvKXX8P53BTCT4VghPBWhFYSt9tHWu/AtJfOTh6qaAsNdeCyG86jmtp3TDMwuL/cBUj2Ot= BZOQMFn7jQ9YB7klIz3RqVL+wNmeWI4=3D

 

The JWT might be optionally encrypted using JWE. 

=  

I think what is becoming clear (and this is what I=92m trying to vet) is that while there is nothing in OAuth that specifies authentication, it = *can* be used for Authentication, if done in the way that I describe.  If I=92m wrong about this, I = really need to know.  I=92ve vetted this idea of mine with = quite of few people now =96 both within context of the = list and off-line =96 and I think I=92m okay. If you see = any holes in what I describe, please point them out as I would prefer to uncover them now rather than after implementation or = deployment!

 

Essentially I=92m using OAuth as a RESTful version of WS-Trust, where my client can exchange primary credentials for a token (JWT) and present that token to a server as secondary = authentication.  It=92s just that it=92s RESTful instead of SOAP = :-)

 

As Justin as pointed out =85 I=92ve = basically made the access-token look like the id_token of Connect.  I was actually hoping to lay a path = to Connect, and use the id_token =85 until it was also pointed out that the id_token is really meant for the consumption of the client, not the RS = :-(

 

 

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Igor Faynberg
Sent: Wednesday, June 20, 2012 2:39 = PM
To: oauth@ietf.org


Subject: Re: [OAUTH-WG] Report an authentication issue

 

But = this use case  does need OAuth, period:



The video server is under the control of a police agency, and police officers must logon to the video server in order to access video = content.

There is no delegation here, and there is no need to use third party for authentication. 

Igor

On 6/20/2012 3:26 PM, Justin Richer wrote: =

In case it wasn't = clear, I want to restate the original problem as best as I understand it in a way that hopefully clears it = up:

App A and app B are both valid registered OAuth clients to an OAuth protected service.

The problem starts when app A gets handed a token that was issued for app B and uses it to call an identity API on the OAuth service. Since app B can get tokens just fine, they're bearer tokens, this is a fairly basic api call, this function works just fine and returns the user info. This makes sense, since anyone who holds A's tokens can do whatever A can do on behalf of that user. The issues start when app B then decides that since they can make a call to the identity API with a token then the user *must* be present. In other words, app B is confusing authorization to call an API with authentication of the session.

OpenID Connect fixes this missed assumption by binding the ID Token to the session and sending it along side the access token, but as you pointed out, it's meant for consumption at the client, not the resource server, in general. That doesn't mean you can't send it to a resource server for your own purposes, of course. That's actually how the session management endpoint works in Connect.

This isn't the only way to handle this problem -- if you put some structure in your tokens, such as with JWT or SAML, then app A can tell that this isn't a token issued to app A, but to app B, so it can call shenanigans and reject it then and there.

 -- Justin

On 06/20/2012 10:03 AM, Lewis Adam-CAL022 wrote: =

I am entirely = confused.

 

I understand what everybody is saying for confidential clients, no problem = here.

 

I fall apart when thinking of iPhone apps.  Consider the scenario where I deploy a video server, and write an iPhone app to talk to the video server.  The video server is under = the control of a police agency, and police officers must logon to the video server in order to access video content.  So the police office launches their iPhone video client = app.

 

If I wanted to solve authentication using =93traditional=94 client-server authentication, the = user enters their username / password into the client, and the client sends the username / password off to the server, which authenticates it, or possibly uses HTTP digest. 

If I wanted to use OpenID, the client would attempt to reach the video server (RP), the server would redirect the client to the OP, OP authenticates user, and OP redirects client back to the server/RP with an assertion that primary authentication was successful. 

If I wanted to use OAuth, the client would send an authorization request to the server=92s = AS, which would authenticate the user of the client, and ultimately result in the client possessing an access-token.  My thinking is that this = access token (let=92s assume it=92s a JWT) would contain = the user=92s identity, a statement of what type of primary authentication was used (auth context), an expiration, and an audience claim.  This = sounds a lot like authentication to me, and it=92s where I get confused.  Is it just because OAuth does = not explicitly define this?  Is there a threat in using OAuth as I describe? 

If I wanted to use Connect, well I=92m not even sure how the id_token as defined = by Connect helps this use case.  The id_token = seems to make sense when the client is a confidential web server, but it=92s not clear what an iPhone app would do with the id_token =85 it=92s the = server in the backend that needs to authenticate the user, the iPhone app is just an interface to talk to the server.  And it seems as I = learn more about connect that the id_token is not meant to be sent from the iPhone app to the server, just the access token.  So it=92s = really not clear how Connect helps solve authentication for an iPhone client app talking to a video server.  If I=92m sending access-tokens, = it=92s just OAuth again.

 

What am I still = missing?

adam

 

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Kristofor Selden
Sent: Saturday, June 16, 2012 11:33 AM
To: nov matake; oauth
Cc: Yuchen Zhou; Luke Melia; Shuo Chen (MSR)
Subject: Re: [OAUTH-WG] Report an authentication issue

 

Nov = demonstrated the problem to us at Yapp and we used solution 4 (because the solution is server side and our app was in the app store).

 

FB Connect is authentication and authorization, where OAuth 2 is concerned only with authorization =96 I'm not = sure that app developers appreciate this = subtlety.

 

With OAuth 2 = you authorize an app to use a protected resource.  With FB Connect, you do that, but also authenticate with the app you are authorizing.

 

So the = access_token protects not just the FB resources but the auth end point of the authorized app (very common with apps that use the iOS SDK).  So now = the app needs a way to verify that it was the app that was authorized to FB.

 

Solution 4 explanation: on FB you can register a iPhone app and a server app with the same client_id and get a client_secret for use on the server.  The server side API posts the access_token, client_id, = and client_secret to https://graph.facebook.com/app to verify that the bearer token actually belongs to the app that is being authenticated before assuming they are authorized to the app's protected resources.

 

Kris

 

On Jun 15, = 2012, at 8:22 PM, nov matake wrote:



There are = 4 ways to fix this issue.

 

1. Use response_type=3Dtoken%20code (It's not = in OAuth 2.0 Core, but seems best way for interoperability)

2. Use singed_request (or some signed token like JWT)

3. Use grant_type=3Dfb_exchange_token (Facebook custom way)

4. = Access to https://graph.facebook.com/app?access_token=3DYOUR_TOKEN (Facebook custom way, moreover undocumented = API)

 

Two = iPhone app developers I reported this issue fixed it by using (4).

 

I also = tried to use (1) for my own iPhone app implementation, but unfortunately it doesn't work when using authorization codes obtained via FB iOS = SDK.

So I'm = using (3) in my case.

 

nov

 

On 2012/06/16, at 9:16, Nat Sakimura wrote:



As to how the fix was done, Nov can provide more detail, but ... 

 

1. Properly verify the signature/HMAC of the "signed_request". This will essentially audience restricts the token. 

2. = There is an undocumented API for Facebook which returns to whom the token was issued. This also audience restricts the token. 

 

The= service that fixed took these measures. Note that none of the above is defined in = OAuth. 

The= same facility was called "id_token" and "check ID endpoint" for OpenID Connect. 

 

The= scale of the impact is large, too large to disclose the actual names in the public list, though, eventually, we would publish them in a paper. 

 

Nat

On Sat, Jun 16, 2012 at 5:34 AM, Francisco Corella <fcorella@pomcor.com> wrote:

Hi Nat and Rui,

Rui, you say that the vulnerability that you found was due to a
"common misunderstanding among developers", but the attack you
describe can be carried out against any app that uses the OAuth
"implicit grant flow", which Facebook calls = "client-side
authentication".  No misunderstanding seems necessary.  What
misunderstanding are you referring to?  I followed = the link in your
message to the Sophos post, and from there the link to the article in
The Register.  The = article in The Register says that Facebook had
"fixed the vulnerability promptly".  How did they = fix it?  The
instructions that Facebook provides for implementing "Client-side
authentication without the JS SDK" at
https://developers.facebook.com/docs/authentication/clie= nt-side/#no-jssdk
still allows the attack.

Nat, I agree that the blog post by John Bradley that you link to
refers to the same vulnerability reported by Rui.  You say that = some
apps have issued a patch to fix it.  Could you = explain what the fix
was?

Francisco

 

From: Nat Sakimura <sakimura@gmail.com>
To: rui wang <ruiwangwarm@gmail.com>
Cc: matake nov <nov@matake.jp>; Yuchen Zhou <t-yuzhou@microsoft.com>; oauth <oauth@ietf.org>; Shuo Chen (MSR) <shuochen@microsoft.com>
Sent: Thursday, June 14, 2012 1:50 PM
Subject: Re: [OAUTH-WG] Report an authentication = issue

 

This is a fairly well known (hopefully by now) issue. We, at the OpenID Foundation, call it "access_token phishing" attack these days. See: http://www.thread-safe.com/2012/01/problem-with-oauth-fo= r-authentication.html

 

Nov Matake has actually built the code on iPhone to verify the problem, and has notified bunch of parties back in February including Facebook and Apple. We have the code that actually runs on a phone, and we have successfully logged in to bunch of apps, including very well known ones. They were all informed of the issue. Some immediately issued a patch to fix it while others have not. =  

 

The problem is that even if these apps gets fixed, the problem does not go away. As long as the attacker has the vulnerable version of the app, he still can impersonate the victim. To stop it, the server side has to completely disable the older version, which means the service has to cut off many users pausing business = problems. 

 

Nat

On Fri, Jun 15, 2012 at 2:18 AM, rui wang <ruiwangwarm@gmail.com> = wrote:

Dear Facebook Security Team and OAuth Standard = group,

We are a research team in Microsoft Research. In January, 2011, we reported a vulnerability in Facebook Connect which allowed everyone to sign into = Facebook-secured relying parties without password. It was promptly fixed after reporting. (http://nakedsecurity.sophos.com/2011/02/02/facebook-flaw= -websites-steal-personal-data/)

Recently, we found a common = misunderstanding among developers of mobile/metro apps when using OAuth (including Facebook=92s OAuth) for = authentication. The vulnerability resulted from this = misunderstanding also allows an attacker to log into a victim user's account without = password.

Let's take Soluto's metro app as an example to describe the problem. The app supports Facebook Login. As an attacker, we can write a regular Facebook app. Once the victim user allows our app to access her Facebook data, we receive an access_token from the traffic. Then, on our own machine (i.e., the "attacker" machine), we run the metro app of Soluto, and use a HTTP proxy to insert the victim's access_token into the traffic of Facebook login. Through this way, we are able to log into the victim's Soluto account from our machine. Other than Soluto, we also have confirmed the same issue on another Windows 8 metro-app = Givit.

The Facebook SDK for Android apps (https://developers.facebook.com/docs/mobile/android/buil= d/#sdk) seems to have the possibility to mislead developers too. At least, the issue that we found is not clearly mentioned. In the SDK, we ran the sample code called "Hackbook" using Android Emulator (imagine it is an attacker device). Note that we have already received the access token of the victim user from our regular Facebook app. We then inject the token to the traffic of Hackbook. Through this way, Hackbook app on our own machine recognizes us as the victim. Note that this is not a convincing security exploit yet, because this sample code does not include the server-side code. However, given that we have seen real server-side code having this problem, such as Soluto, Givit and others, we do believe that the sample code can mislead mobile/metro developers. We also suspect that this may be a general issue of many OAuth = implementations on mobile platforms, so we send this message to OAuth Standard group as = well.

We have contacted the vendors of the two vulnerable metro-apps, Soluto and = Gavit.

Please kindly give us an ack when you receive this message. If you want to know more details, please let us = know.

Best Regards,
Yuchen Zhou, Rui Wang, and Shuo = Chen


_______________________________________________
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



 

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

 



= 
_______________________________________________
OAuth mailing 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=_EA662110-4B00-431A-9F27-D1506F88D68F-- From sakimura@gmail.com Thu Jun 21 09:37:55 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7583821F8767 for ; Thu, 21 Jun 2012 09:37:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.136 X-Spam-Level: X-Spam-Status: No, score=-3.136 tagged_above=-999 required=5 tests=[AWL=-0.138, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, 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 fnFlpvzA2xdR for ; Thu, 21 Jun 2012 09:37:52 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 82FC121F8656 for ; Thu, 21 Jun 2012 09:37:51 -0700 (PDT) Received: by bkty8 with SMTP id y8so835523bkt.31 for ; Thu, 21 Jun 2012 09:37:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qTimnrF1AxGR67Uguy3X6pzH16NHzzaUAybozCIaH1Q=; b=q/fnIyYyyW8Fdwky7Yeeo4x+AxkTWArZuj5xITM14aYHVEBIK1KhSc/YwMrGkWuzMU 0oQV0GFF4p4eIFlMJjRV6ccEWEU0+V+cpOA8geRfEyzuq6YxReexC6w8CSbHfwzSjooq Hhc1w3Od5YxOcqIGnVLiOZWKQtWUvjxxh5XqT/73r4bxdefoo0yJQuTHL6tqoLDhZap3 PqaE34bzbxEsOdY1w0eBnCcw5gHpTFKItmqIxSsKpuscVfpM6RmdOlpKXzEIWLnj0MW2 Y63uJEZfm2ap0vPjoJPYimaUkmxNysdYPOS+EoaiWhq5AZK6ccwRIIndq/FIAQHlLphj mMNQ== MIME-Version: 1.0 Received: by 10.204.151.81 with SMTP id b17mr12300387bkw.52.1340296670394; Thu, 21 Jun 2012 09:37:50 -0700 (PDT) Received: by 10.204.240.143 with HTTP; Thu, 21 Jun 2012 09:37:50 -0700 (PDT) In-Reply-To: <59E470B10C4630419ED717AC79FCF9A917052BC8@SN2PRD0410MB370.namprd04.prod.outlook.com> References: <1339792496.52712.YahooMailNeo@web125501.mail.ne1.yahoo.com> <59E470B10C4630419ED717AC79FCF9A9108898EE@BL2PRD0410MB363.namprd04.prod.outlook.com> <4FE223E4.6060307@mitre.org> <4FE226BC.6010403@alcatel-lucent.com> <59E470B10C4630419ED717AC79FCF9A910889AB5@BL2PRD0410MB363.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A917052BC8@SN2PRD0410MB370.namprd04.prod.outlook.com> Date: Fri, 22 Jun 2012 01:37:50 +0900 Message-ID: From: Nat Sakimura To: Lewis Adam-CAL022 Content-Type: multipart/alternative; boundary=0015175cabaeeeb92104c2fe2210 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Report an authentication issue X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 16:37:55 -0000 --0015175cabaeeeb92104c2fe2210 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I think you are way beyond what OAuth provides. OpenID Connect probably is a better fit. id_token was built with non-confidential client in mind. That was in our use case from the beginning. Supporting apps was also in our use case, and doing Holder of key was also. With a native client, you might as well want to do HoK. I also strongly believe that a secure native client should generate key pairs and leverage it. Re: your question: > 1) identify the user, and Use the id_token. > 2) make authorization decisions based on what roles that user has within the enterprise. It depends on where the policy decision point is. Authorization server can be the PDP, then it issues the id_token for the APP and access token for the RS. RS will be a pure play PEP. For additional security, the APP could present id_token together with access_token. OR use id_token as access token. The id_token may include the public key of the App, and the video can be encrypted using that essentially audience restricting the video. It could also be that RS is the PDP+PEP. Your model seem to fit this one. Then, you just take id_token there and PDP portion of the RS gives you the access token, which you present it to the PEP portion of the RS. In this case, I think id_token should be audience restricted to the RS. It should carry the public key of the APP inside it. The RS may encrypt the data using it, so the video data is actually transmitted only to the intended client. Best, Nat On Fri, Jun 22, 2012 at 1:01 AM, Lewis Adam-CAL022 < Adam.Lewis@motorolasolutions.com> wrote: > Hi Nat,**** > > ** ** > > I=92m beginning to wonder what it would take to add a new profile of sort= s > to either OAuth or Connect. **** > > ** ** > > In the beginning there was SOAP, and the preferred method to secure SOAP > API calls was WS-Trust.**** > > ** ** > > Now the world is moving toward RESTful APIs =85 and the preferred means t= o > secure RESTful APIs is OAuth.**** > > ** ** > > Except that OAuth is clearly written with the idea that the protected > resources belong to the end user.**** > > ** ** > > My use cases =96 and I imagine the use cases of many other enterprises = =96 is > that the Owner of the resources is the Enterprise. An employee is trying > to access a database or video resources. The enterprise RS needs to be > able to 1) identify the user, and 2) make authorization decisions based o= n > what roles that user has within the enterprise. So in my scenario, when = a > police officer attempts to access a criminal records database, the databa= se > needs to know who that officer is, and then decide if they have privilege > to access the database, and at what level (e.g. CRUD). **** > > ** ** > > WS-Trust fits this model well. The user performs primary authentication > to the enterprise STS, which then grants the application client a SAML > assertion. When the user attempts to access a records database, the SAML > assertion is included in the SOAP message. The records server > authenticates the user based on the SAML assertion and makes its > authorization decisions.**** > > ** ** > > This is the world I=92m trying to migrate from, and it really seems like = I=92m > sometimes trying to make a square peg fit in a round hole. I=92m looking= for > OAuth/Connect to do for REST what WS-TRUST did for SOAP. I would like a > native client talking to a RS to be able to ask for an id_token, and then > pass that id_token to the RS when making its RESTful API calls, to enable > the RS to authenticate the user. I think that this would be really usefu= l > for a lot of people besides me. I keep hearing that there is nothing > =93preventing=94 me from doing this =85 but it hardly seems within the sp= irit of > what OAuth was meant to do. The id_token was clearly meant to enable a > user to authenticate to a confidential client / web server =85 but was n= ot > meant for a native client to identity / authenticate the user to a RS. *= * > ** > > ** ** > > ** ** > > Would there be any interest in exploring this further?**** > > -adam**** > > ** ** > > ** ** > > *From:* Nat Sakimura [mailto:sakimura@gmail.com] > *Sent:* Wednesday, June 20, 2012 8:09 PM > *To:* Lewis Adam-CAL022 > *Cc:* igor.faynberg@alcatel-lucent.com; oauth@ietf.org > > *Subject:* Re: [OAUTH-WG] Report an authentication issue**** > > ** ** > > Yes, OAuth can be profiled to enable authentication. **** > > In fact, initial draft of OpenID Connect was just like you described. ***= * > > Essentially, we were using structured access_token. **** > > Later, we decided to separate the access token and id_token for several > reasons such as: **** > > ** ** > > 1. Better interop with existing OAuth implementations: by introducing > id_token, they do not need to touch the supposedly opaque (which means > AS-RS may be doing some proprietary thing inside it) access token. ***= * > 2. Mixing up the audience (for id_token aka authn =3D client, and for > access_token aka authz =3D resource server) probably is expanding the = attack > surface for security and privacy. **** > > Although we separated them out, a signed id_token includes the left hash > of access_token so access_token is also protected. **** > > ** ** > > Best, **** > > ** ** > > Nat**** > > ** ** > > On Thu, Jun 21, 2012 at 5:21 AM, Lewis Adam-CAL022 < > Adam.Lewis@motorolasolutions.com> wrote:**** > > Hi Igor,**** > > **** > > As Justin just pointed out, consider the case where the video server is > hosted by the state (e.g. California) and is accessed by police agencies = in > Los Angeles, San Francisco, and San Diego. The State of California=92s v= ideo > server is the RS. Each local police agency (LA/SF/SD) hosts an AS. So > when a police officer from LAPD launches the video client app on the > iPhone, the client makes an OAuth request to the LAPD=92s AS, which > authenticates the police officer using agency level credentials. The > access token issued to the video client app on the iPhone is a JWT, signe= d > by the agency AS, which might look something like this:**** > > **** > > {=93typ=94:=94JWT=94,"alg":"ES256"}**** > > {"iss":"https://as.lapd.california.gov", > "prn":"alice@lapd.california.gov", > "aud":" https://video_server1@state.california.gov", > "iat":1300815780, > "exp":1300819380, > "acr":=94password=94}**** > > > hq4zk+ZknjggCQgZm7ea8fI79gJEsRy3E8LHDpYXWQIgZpkJN9CMLG8ENR4Nrw+n7iyzixBvK= XX8P53BTCT4VghPBWhFYSt9tHWu/AtJfOTh6qaAsNdeCyG86jmtp3TDMwuL/cBUj2OtBZOQMFn7= jQ9YB7klIz3RqVL+wNmeWI4=3D > **** > > **** > > The JWT might be optionally encrypted using JWE. **** > > **** > > I think what is becoming clear (and this is what I=92m trying to vet) is > that while there is nothing in OAuth that specifies authentication, it ** > can** be used for Authentication, if done in the way that I describe. If > I=92m wrong about this, I really need to know. I=92ve vetted this idea o= f mine > with quite of few people now =96 both within context of the list and off-= line > =96 and I think I=92m okay. If you see any holes in what I describe, plea= se > point them out as I would prefer to uncover them now rather than after > implementation or deployment!**** > > **** > > Essentially I=92m using OAuth as a RESTful version of WS-Trust, where my > client can exchange primary credentials for a token (JWT) and present tha= t > token to a server as secondary authentication. It=92s just that it=92s R= ESTful > instead of SOAP :-)**** > > **** > > As Justin as pointed out =85 I=92ve basically made the access-token look = like > the id_token of Connect. I was actually hoping to lay a path to Connect, > and use the id_token =85 until it was also pointed out that the id_token = is > really meant for the consumption of the client, not the RS :-(**** > > **** > > **** > > **** > > *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behalf > Of *Igor Faynberg > *Sent:* Wednesday, June 20, 2012 2:39 PM > *To:* oauth@ietf.org**** > > > *Subject:* Re: [OAUTH-WG] Report an authentication issue**** > > **** > > But this use case does need OAuth, period:**** > > > > The video server is under the control of a police agency, and police > officers must logon to the video server in order to access video content. > > There is no delegation here, and there is no need to use third party for > authentication. > > Igor > > On 6/20/2012 3:26 PM, Justin Richer wrote: **** > > In case it wasn't clear, I want to restate the original problem as best a= s > I understand it in a way that hopefully clears it up: > > App A and app B are both valid registered OAuth clients to an OAuth > protected service. > > The problem starts when app A gets handed a token that was issued for app > B and uses it to call an identity API on the OAuth service. Since app B c= an > get tokens just fine, they're bearer tokens, this is a fairly basic api > call, this function works just fine and returns the user info. This makes > sense, since anyone who holds A's tokens can do whatever A can do on beha= lf > of that user. The issues start when app B then decides that since they ca= n > make a call to the identity API with a token then the user *must* be > present. In other words, app B is confusing authorization to call an API > with authentication of the session. > > OpenID Connect fixes this missed assumption by binding the ID Token to th= e > session and sending it along side the access token, but as you pointed ou= t, > it's meant for consumption at the client, not the resource server, in > general. That doesn't mean you can't send it to a resource server for you= r > own purposes, of course. That's actually how the session management > endpoint works in Connect. > > This isn't the only way to handle this problem -- if you put some > structure in your tokens, such as with JWT or SAML, then app A can tell > that this isn't a token issued to app A, but to app B, so it can call > shenanigans and reject it then and there. > > -- Justin > > On 06/20/2012 10:03 AM, Lewis Adam-CAL022 wrote: **** > > I am entirely confused.**** > > **** > > I understand what everybody is saying for confidential clients, no proble= m > here.**** > > **** > > I fall apart when thinking of iPhone apps. Consider the scenario where I > deploy a video server, and write an iPhone app to talk to the video > server. The video server is under the control of a police agency, and > police officers must logon to the video server in order to access video > content. So the police office launches their iPhone video client app.***= * > > **** > > If I wanted to solve authentication using =93traditional=94 client-server > authentication, the user enters their username / password into the client= , > and the client sends the username / password off to the server, which > authenticates it, or possibly uses HTTP digest. > > **** > > If I wanted to use OpenID, the client would attempt to reach the video > server (RP), the server would redirect the client to the OP, OP > authenticates user, and OP redirects client back to the server/RP with an > assertion that primary authentication was successful. > > **** > > If I wanted to use OAuth, the client would send an authorization request > to the server=92s AS, which would authenticate the user of the client, an= d > ultimately result in the client possessing an access-token. My thinking = is > that this access token (let=92s assume it=92s a JWT) would contain the us= er=92s > identity, a statement of what type of primary authentication was used (au= th > context), an expiration, and an audience claim. This sounds a lot like > authentication to me, and it=92s where I get confused. Is it just becaus= e > OAuth does not explicitly define this? Is there a threat in using OAuth = as > I describe? > > **** > > If I wanted to use Connect, well I=92m not even sure how the id_token as > defined by Connect helps this use case. The id_token seems to make sense > when the client is a confidential web server, but it=92s not clear what a= n > iPhone app would do with the id_token =85 it=92s the server in the backen= d that > needs to authenticate the user, the iPhone app is just an interface to ta= lk > to the server. And it seems as I learn more about connect that the > id_token is not meant to be sent from the iPhone app to the server, just > the access token. So it=92s really not clear how Connect helps solve > authentication for an iPhone client app talking to a video server. If I= =92m > sending access-tokens, it=92s just OAuth again.**** > > **** > > What am I still missing?**** > > adam**** > > **** > > **** > > *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] > *On Behalf Of *Kristofor Selden > *Sent:* Saturday, June 16, 2012 11:33 AM > *To:* nov matake; oauth > *Cc:* Yuchen Zhou; Luke Melia; Shuo Chen (MSR) > *Subject:* Re: [OAUTH-WG] Report an authentication issue**** > > **** > > Nov demonstrated the problem to us at Yapp and we used solution 4 (becaus= e > the solution is server side and our app was in the app store).**** > > **** > > FB Connect is authentication *and* authorization, where OAuth 2 is > concerned only with authorization =96 I'm not sure that app developers > appreciate this subtlety.**** > > **** > > With OAuth 2 you authorize an app to use a protected resource. With FB > Connect, you do that, but *also* authenticate with the app you are > authorizing.**** > > **** > > So the access_token protects not just the FB resources but the auth end > point of the authorized app (very common with apps that use the iOS SDK). > So now the app needs a way to verify that it was the app that was > authorized to FB.**** > > **** > > Solution 4 explanation: on FB you can register a iPhone app and a server > app with the same client_id and get a client_secret for use on the server= . > The server side API posts the access_token, client_id, and client_secret > to https://graph.facebook.com/app to verify > that the bearer token actually belongs to the app that is being > authenticated before assuming they are authorized to the app's protected > resources.**** > > **** > > Kris**** > > **** > > On Jun 15, 2012, at 8:22 PM, nov matake wrote:**** > > > > **** > > There are 4 ways to fix this issue.**** > > **** > > 1. Use response_type=3Dtoken%20code (It's not in OAuth 2.0 Core, but seem= s > best way for interoperability)**** > > 2. Use singed_request (or some signed token like JWT)**** > > 3. Use grant_type=3Dfb_exchange_token (Facebook custom way)**** > > 4. Access to https://graph.facebook.com/app?access_token=3DYOUR_TOKEN(Fac= ebook custom way, moreover undocumented API) > **** > > **** > > Two iPhone app developers I reported this issue fixed it by using (4).***= * > > **** > > I also tried to use (1) for my own iPhone app implementation, but > unfortunately it doesn't work when using authorization codes obtained via > FB iOS SDK.**** > > So I'm using (3) in my case.**** > > **** > > nov**** > > **** > > On 2012/06/16, at 9:16, Nat Sakimura wrote:**** > > > > **** > > As to how the fix was done, Nov can provide more detail, but ... **** > > **** > > 1. Properly verify the signature/HMAC of the "signed_request". This will > essentially audience restricts the token. **** > > 2. There is an undocumented API for Facebook which returns to whom the > token was issued. This also audience restricts the token. **** > > **** > > The service that fixed took these measures. Note that none of the above i= s > defined in OAuth. **** > > The same facility was called "id_token" and "check ID endpoint" for OpenI= D > Connect. **** > > **** > > The scale of the impact is large, too large to disclose the actual names > in the public list, though, eventually, we would publish them in a paper. > **** > > **** > > Nat**** > > On Sat, Jun 16, 2012 at 5:34 AM, Francisco Corella > wrote: > > **** > > Hi Nat and Rui, > > Rui, you say that the vulnerability that you found was due to a > "common misunderstanding among developers", but the attack you > describe can be carried out against any app that uses the OAuth > "implicit grant flow", which Facebook calls "client-side > authentication". No misunderstanding seems necessary. What > misunderstanding are you referring to? I followed the link in your > message to the Sophos post, and from there the link to the article in > The Register. The article in The Register says that Facebook had > "fixed the vulnerability promptly". How did they fix it? The > instructions that Facebook provides for implementing "Client-side > authentication without the JS SDK" at > https://developers.facebook.com/docs/authentication/client-side/#no-jssdk > still allows the attack. > > Nat, I agree that the blog post by John Bradley that you link to > refers to the same vulnerability reported by Rui. You say that some > apps have issued a patch to fix it. Could you explain what the fix > was? > > Francisco**** > > **** > ------------------------------ > > *From:* Nat Sakimura > *To:* rui wang > *Cc:* matake nov ; Yuchen Zhou ; > oauth ; Shuo Chen (MSR) > *Sent:* Thursday, June 14, 2012 1:50 PM > *Subject:* Re: [OAUTH-WG] Report an authentication issue**** > > **** > > This is a fairly well known (hopefully by now) issue. We, at the OpenID > Foundation, call it "access_token phishing" attack these days. See: > http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.= html > **** > > **** > > Nov Matake has actually built the code on iPhone to verify the problem, > and has notified bunch of parties back in February including Facebook and > Apple. We have the code that actually runs on a phone, and we have > successfully logged in to bunch of apps, including very well known ones. > They were all informed of the issue. Some immediately issued a patch to f= ix > it while others have not. **** > > **** > > The problem is that even if these apps gets fixed, the problem does not g= o > away. As long as the attacker has the vulnerable version of the app, he > still can impersonate the victim. To stop it, the server side has to > completely disable the older version, which means the service has to cut > off many users pausing business problems. **** > > **** > > Nat**** > > On Fri, Jun 15, 2012 at 2:18 AM, rui wang wrote:*= * > ** > > Dear Facebook Security Team and OAuth Standard group,**** > > We are a research team in Microsoft Research. In January, 2011, we > reported a vulnerability in Facebook Connect which allowed everyone to si= gn > into Facebook-secured relying parties without password. It was promptly > fixed after reporting. ( > http://nakedsecurity.sophos.com/2011/02/02/facebook-flaw-websites-steal-p= ersonal-data/ > )**** > > Recently, we found a common misunderstanding among developers of > mobile/metro apps when using OAuth (including Facebook=92s OAuth) for > authentication. The vulnerability resulted from this misunderstanding als= o > allows an attacker to log into a victim user's account without password.*= * > ** > > Let's take Soluto's metro app as an example to describe the problem. The > app supports Facebook Login. As an attacker, we can write a regular > Facebook app. Once the victim user allows our app to access her Facebook > data, we receive an access_token from the traffic. Then, on our own machi= ne > (i.e., the "attacker" machine), we run the metro app of Soluto, and use a > HTTP proxy to insert the victim's access_token into the traffic of Facebo= ok > login. Through this way, we are able to log into the victim's Soluto > account from our machine. Other than Soluto, we also have confirmed the > same issue on another Windows 8 metro-app Givit.**** > > The Facebook SDK for Android apps ( > https://developers.facebook.com/docs/mobile/android/build/#sdk) seems to > have the possibility to mislead developers too. At least, the issue that = we > found is not clearly mentioned. In the SDK, we ran the sample code called > "Hackbook" using Android Emulator (imagine it is an attacker device). Not= e > that we have already received the access token of the victim user from ou= r > regular Facebook app. We then inject the token to the traffic of Hackbook= . > Through this way, Hackbook app on our own machine recognizes us as the > victim. Note that this is not a convincing security exploit yet, because > this sample code does not include the server-side code. However, given th= at > we have seen real server-side code having this problem, such as Soluto, > Givit and others, we do believe that the sample code can mislead > mobile/metro developers. We also suspect that this may be a general issue > of many OAuth implementations on mobile platforms, so we send this messag= e > to OAuth Standard group as well.**** > > We have contacted the vendors of the two vulnerable metro-apps, Soluto an= d > Gavit.**** > > Please kindly give us an ack when you receive this message. If you want t= o > know more details, please let us know.**** > > Best Regards, > Yuchen Zhou, Rui Wang, and Shuo Chen**** > > > _______________________________________________ > 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 > > **** > > > > **** > > **** > > -- > 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**** > > **** > > > > **** > > _______________________________________________**** > > OAuth mailing 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**** > > ** ** > --=20 Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --0015175cabaeeeb92104c2fe2210 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
I think you are way beyond what OAuth provides.=A0

OpenID Connect probably is a better fit.=A0
id_token was built w= ith non-confidential client in mind.=A0
That was in our use case from t= he beginning.=A0
Supporting apps was also in our use case, and doing Holder of key was = also.=A0
With a native client, you might as well want to do HoK.= =A0
I also strongly believe that a secure native client should ge= nerate key pairs and leverage it.=A0

Re: your question:=A0

> 1) identify the user, and=A0

Use the id_token.=A0
=
> 2) make authorization decisions based on what= roles that user has within the enterprise.

It depends on where the policy decision point is.=A0
Authorization server can be the PDP, then it issues the id_token = for the APP and access token for the RS. RS will be a pure play PEP. For ad= ditional security, the APP could present id_token together with access_toke= n. OR use id_token as access token. The id_token may include the public key= of the App, and the video can be encrypted using that essentially audience= restricting the video.=A0

It could al= so be that RS is the PDP+PEP. Your model seem to fit this one. Then, you ju= st take id_token there and PDP portion of the RS gives you the access token= , which you present it to the PEP portion of the RS. In this case, I think = id_token should be audience restricted to the RS. It should carry the publi= c key of the APP inside it. The RS may encrypt the data using it, so the vi= deo data is actually transmitted only to the intended client.=A0

Best,=A0

Nat
On Fri, Jun 22, 2012 at 1:01 AM, Lewis Adam-CAL= 022 <Adam.Lewis@motorolasolutions.com> wrote:=

Hi Nat,

=A0

I=92m beginning to wonder what it would take= to add a new profile of sorts to either OAuth or Connect.=A0

=A0

In the beginning there was SOAP, and the pre= ferred method to secure SOAP API calls was WS-Trust.

=A0

Now the world is moving toward RESTful APIs = =85 and the preferred means to secure RESTful APIs is OAuth.<= /span>

=A0

Except that OAuth is clearly written with th= e idea that the protected resources belong to the end user.

=A0

My use cases =96 and I imagine the use cases= of many other enterprises =96 is that the Owner of the resources is the En= terprise.=A0 An employee is trying to access a database or video resources.=A0 The enterprise RS needs to be able to 1) identify the user, = and 2) make authorization decisions based on what roles that user has withi= n the enterprise.=A0 So in my scenario, when a police officer attempts to a= ccess a criminal records database, the database needs to know who that officer is, and then decide if they have p= rivilege to access the database, and at what level (e.g. CRUD).=A0

=A0

WS-Trust fits this model well.=A0 The user p= erforms primary authentication to the enterprise STS, which then grants the= application client a SAML assertion.=A0 When the user attempts to access a records database, the SAML assertion is included in the SOAP m= essage.=A0 The records server authenticates the user based on the SAML asse= rtion and makes its authorization decisions.

=A0

This is the world I=92m trying to migrate fr= om, and it really seems like I=92m sometimes trying to make a square peg fi= t in a round hole.=A0 I=92m looking for OAuth/Connect to do for REST what WS-TRUST did for SOAP.=A0 I would like a native client talking t= o a RS to be able to ask for an id_token, and then pass that id_token to th= e RS when making its RESTful API calls, to enable the RS to authenticate th= e user.=A0 I think that this would be really useful for a lot of people besides me.=A0 I keep hearing that there= is nothing =93preventing=94 me from doing this =85 but it hardly seems wit= hin the spirit of what OAuth was meant to do.=A0 The id_token was clearly m= eant to enable a user to authenticate to a confidential client =A0/ web server =85 but was not meant for a native cli= ent to identity / authenticate the user to a RS.=A0

=A0

=A0

Would there be any interest in exploring thi= s further?

-adam

=A0

=A0

From: Nat Saki= mura [mailto:sakimu= ra@gmail.com]
Sent: Wednesday, June 20, 2012 8:09 PM
To: Lewis Adam-CAL022
Cc: igor.faynberg@alcatel-lucent.com; oauth@ietf.org

Subject: Re: [OAUTH-WG] Report an authentication issue=

=A0

Yes, OAuth can be profiled to enable authentication.= =A0

In fact, initial draft of OpenID Connect was just li= ke you described.=A0

Essentially, we were using structured access_token.= =A0

Later, we decided to separate the access token and i= d_token for several reasons such as:=A0

=A0

  1. Better interop with existing OAuth implementations: by introducing id_token= , they do not need to touch the supposedly opaque (which means AS-RS may be= doing some proprietary thing inside it) access token.=A0
  2. Mixing up the audience (for id_token aka authn =3D client, and for access_t= oken aka authz =3D resource server) probably is expanding the attack surfac= e for security and privacy.=A0

Although we separated them out, a signed id_token in= cludes the left hash of access_token so access_token is also protected.=A0<= u>

=A0

Best,=A0

=A0

Nat

=A0

On Thu, Jun 21, 2012 at 5:21 AM, Lewis Adam-CAL022 &= lt;Ad= am.Lewis@motorolasolutions.com> wrote:

Hi Igor,

=A0

As Justin just pointed out, consider the cas= e where the video server is hosted by the state (e.g. California) and is accessed by police agencies in Los Angeles, San Francisco, and San Diego.= =A0 The State of California=92s video server is the RS.=A0 Each local polic= e agency (LA/SF/SD) hosts an AS.=A0 So when a police officer from LAPD laun= ches the video client app on the iPhone, the client makes an OAuth request to the LAPD=92s AS, which authenticates = the police officer using agency level credentials.=A0 The access token issu= ed to the video client app on the iPhone is a JWT, signed by the agency AS,= which might look something like this:

=A0

{=93typ=94:=94JWT=94,"alg":"E= S256"}

{"iss":"https://as.lapd.california.gov&= quot;,
=A0=A0"prn":"alice@lapd.california.gov",
=A0 "aud":" https://video_server1@state.california.gov&quo= t;,
=A0 "iat":1300815780,
=A0 "exp":1300819380,
=A0 "acr":=94password=94}

hq4zk+ZknjggCQgZm7ea8fI79gJEsRy3E8LHDpYXWQIgZpkJN9CMLG8ENR4Nrw+n7iy= zixBvKXX8P53BTCT4VghPBWhFYSt9tHWu/AtJfOTh6qaAsNdeCyG86jmtp3TDMwuL/cBUj2OtBZ= OQMFn7jQ9YB7klIz3RqVL+wNmeWI4=3D

=A0

The JWT might be optionally encrypted using JWE.=A0

=A0

I think what is becoming clear (and this is what I=92m trying to ve= t) is that while there is nothing in OAuth that specifies authentication, i= t *can* be used for Authentication, if done in the way that I describe.=A0 If I=92m wrong about this, I really need to know.= =A0 I=92ve vetted this idea of mine with quite of few people now =96 both w= ithin context of the list and off-line =96 and I think I=92m okay. If you s= ee any holes in what I describe, please point them out as I would prefer to uncover them now rather than after implementation= or deployment!

=A0

Essentially I=92m using OAuth as a RESTful version of WS-Trust, whe= re my client can exchange primary credentials for a token (JWT) and present= that token to a server as secondary authentication.=A0 It=92s just that it=92s RESTful instead of SOAP :-)

=A0

As Justin as pointed out =85 I=92ve basically made the access-token= look like the id_token of Connect.=A0 I was actually hoping to lay a path = to Connect, and use the id_token =85 until it was also pointed out that the id_token is really meant for the consumption of the client, n= ot the RS :-(

=A0

=A0

=A0

From: oauth-bounces@i= etf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Igor Faynberg
Sent: Wednesday, June 20, 2012 2:39 PM
To: oauth@ietf.o= rg


Subject: Re: [OAUTH-WG] Report an authentication issue=

=A0

But this use case=A0 does need OAuth, period:=



The video server is under the control of a police agency, and polic= e officers must logon to the video server in order to access video content.=

There is no delegation here, and there is no need to use third party for au= thentication.=A0

Igor

On 6/20/2012 3:26 PM, Justin Richer wrote:

In case it wasn't clear, I want to restate the o= riginal problem as best as I understand it in a way that hopefully clears i= t up:

App A and app B are both valid registered OAuth clients to an OAuth protect= ed service.

The problem starts when app A gets handed a token that was issued for app B= and uses it to call an identity API on the OAuth service. Since app B can = get tokens just fine, they're bearer tokens, this is a fairly basic api= call, this function works just fine and returns the user info. This makes sense, since anyone who holds A'= s tokens can do whatever A can do on behalf of that user. The issues start = when app B then decides that since they can make a call to the identity API= with a token then the user *must* be present. In other words, app B is confusing authorization to call an API w= ith authentication of the session.

OpenID Connect fixes this missed assumption by binding the ID Token to the = session and sending it along side the access token, but as you pointed out,= it's meant for consumption at the client, not the resource server, in = general. That doesn't mean you can't send it to a resource server for your own purposes, of course. That's = actually how the session management endpoint works in Connect.

This isn't the only way to handle this problem -- if you put some struc= ture in your tokens, such as with JWT or SAML, then app A can tell that thi= s isn't a token issued to app A, but to app B, so it can call shenaniga= ns and reject it then and there.

=A0-- Justin

On 06/20/2012 10:03 AM, Lewis Adam-CAL022 wrote:

I am entirely confused.=

=A0

I understand what everybody is saying for co= nfidential clients, no problem here.

=A0

I fall apart when thinking of iPhone apps.= =A0 Consider the scenario where I deploy a video server, and write an iPhon= e app to talk to the video server.=A0 The video server is under the control = of a police agency, and police officers must logon to the video server in o= rder to access video content.=A0 So the police office launches their iPhone= video client app.

=A0

If I wanted to solve authenticati= on using =93traditional=94 client-server authentication, the user enters th= eir username / password into the client, and the client sends the username / password off to the server, which authenticates it, or poss= ibly uses HTTP digest.=A0

If I wanted to use OpenID, the cl= ient would attempt to reach the video server (RP), the server would redirec= t the client to the OP, OP authenticates user, and OP redirects client back to the server/RP with an assertion that primary authentication= was successful.=A0

If I wanted to use OAuth, the cli= ent would send an authorization request to the server=92s AS, which would a= uthenticate the user of the client, and ultimately result in the client possessing an access-token.=A0 My thinking is that this acce= ss token (let=92s assume it=92s a JWT) would contain the user=92s identity,= a statement of what type of primary authentication was used (auth context)= , an expiration, and an audience claim.=A0 This sounds a lot like authentication to me, and it=92s where I get confus= ed.=A0 Is it just because OAuth does not explicitly define this?=A0 Is ther= e a threat in using OAuth as I describe?=A0

If I wanted to use Connect, well I=92m not even sure how the id_= token as defined by Connect helps this use case.=A0 The id_token seems to m= ake sense when the client is a confidential web server, but it=92s not clear what an iPhone app would do with the id_token =85 it=92s = the server in the backend that needs to authenticate the user, the iPhone a= pp is just an interface to talk to the server.=A0 And it seems as I learn m= ore about connect that the id_token is not meant to be sent from the iPhone app to the server, just the access token.= =A0 So it=92s really not clear how Connect helps solve authentication for a= n iPhone client app talking to a video server.=A0 If I=92m sending access-t= okens, it=92s just OAuth again.

=A0

What am I still missing?

adam

=A0

=A0

From: oauth-bounces@i= etf.org [ma= ilto:oauth-bounces@ietf.org] On Behalf Of Kristofor Selden
Sent: Saturday, June 16, 2012 11:33 AM
To: nov matake; oauth
Cc: Yuchen Zhou; Luke Melia; Shuo Chen (MSR)
Subject: Re: [OAUTH-WG] Report an authentication issue=

=A0

Nov demonstrated the problem to us at Yapp and we us= ed solution 4 (because the solution is server side and our app was in the a= pp store).

=A0

FB Connect is authentication and authorization, where OAuth 2 is concerned only with authorizatio= n =96 I'm not sure that app developers appreciate this subtlety.=

=A0

With OAuth 2 you authorize an app to use a protected= resource. =A0With FB Connect, you do that, but also authenticate with the app you are authorizing.

=A0

So the access_token protects not just the FB resourc= es but the auth end point of the authorized app (very common with apps that= use the iOS SDK). =A0So now the app needs a way to verify that it was the app that was authorized to FB.

=A0

Solution 4 explanation: on FB you can register a iPh= one app and a server app with the same client_id and get a client_secret fo= r use on the server. =A0The server side API posts the access_token,=A0client_id, and=A0client_secret to=A0https://gr= aph.facebook.com/app=A0to=A0verify that the bearer token actually belon= gs to the app that is being authenticated before assuming they are authorized to the app's protected resources.<= u>

=A0

Kris

=A0

On Jun 15, 2012, at 8:22 PM, nov matake wrote:



There are 4 ways to fix this issue.

=A0

1. Use response_type=3Dtoken%20code (It's=A0not = in OAuth 2.0 Core, but seems best way for interoperability)

2. Use singed_request (or some signed token like JWT= )

3. Use grant_type=3Dfb_exchange_token (Facebook cust= om way)

4. Access to https://graph.facebook.com/app?access_token=3DYOUR_TOKEN (Facebook cust= om way, moreover undocumented API)

=A0

Two iPhone app developers I reported this issue fixe= d it by using (4).

=A0

I also tried to use (1) for my own iPhone app implem= entation, but unfortunately it doesn't work when using authorization co= des obtained via FB iOS SDK.

So I'm using (3) in my case.

=A0

nov

=A0

On 2012/06/16, at 9:16, Nat Sakimura wrote:



As to how the fix was done, Nov can provide more det= ail, but ...=A0

=A0

1. Properly verify the signature/HMAC of the "s= igned_request". This will essentially audience restricts the token.=A0=

2. There is an undocumented API for Facebook which r= eturns to whom the token was issued. This also audience restricts the token= .=A0

=A0

The service that fixed took these measures. Note tha= t none of the above is defined in OAuth.=A0

The same facility was called "id_token" an= d "check ID endpoint" for OpenID Connect.=A0

=A0

The scale of the impact is large, too large to discl= ose the actual names in the public list, though, eventually, we would publi= sh them in a paper.=A0

=A0

Nat

On Sat, Jun 16, 2012 = at 5:34 AM, Francisco Corella <fcorella@pomcor.com> wrote:

Hi Nat and Rui,

Rui, you say that the vulnerability that you found was due to a
"common misunderstanding among developers", but the attack you describe can be carried out against any app that uses the OAuth
"implicit grant flow", which Facebook calls "client-side
authentication".=A0 No misunderstanding seems necessary.=A0 What
misunderstanding are you referring to?=A0 I followed the link in your
message to the Sophos post, and from there the link to the article in
The Register.=A0 The article in The Register says that Facebook had
"fixed the vulnerability promptly".=A0 How did they fix it?=A0 Th= e
instructions that Facebook provides for implementing "Client-side
authentication without the JS SDK" at
https://developers.facebook.com/docs/authentic= ation/client-side/#no-jssdk
still allows the attack.

Nat, I agree that the blog post by John Bradley that you link to
refers to the same vulnerability reported by Rui.=A0 You say that some
apps have issued a patch to fix it.=A0 Could you explain what the fix
was?

Francisco

=A0

From: Nat Sakimura <sakimura@gmail.com>
To: rui wang <ruiwangwarm@gmail.com>
Cc: matake nov <nov@matake.jp>; Yuchen Zhou <t-yuzhou@microsoft.com>; oauth <oauth@ietf.org>; Shuo Chen (MSR) <shuochen@microsoft.com>
Sent: Thursday, June 14, 2012 1:50 PM
Subject: Re: [OAUTH-WG] Report an authentication issue=

=A0

This is a fairly well known (hopefully by now) issue= . We, at the OpenID Foundation, call it "access_token phishing" a= ttack these days. See:=A0http://www.thread= -safe.com/2012/01/problem-with-oauth-for-authentication.html<= /u>

=A0

Nov Matake has actually built the code on iPhone to = verify the problem, and has notified bunch of parties back in February incl= uding Facebook and Apple. We have the code that actually runs on a phone, and we have successfully logged in to bunch of apps, incl= uding very well known ones. They were all informed of the issue. Some immed= iately issued a patch to fix it while others have not. =A0

=A0

The problem is that even if these apps gets fixed, t= he problem does not go away. As long as the attacker has the vulnerable ver= sion of the app, he still can impersonate the victim. To stop it, the server side has to completely disable the older version, w= hich means the service has to cut off many users pausing business problems.= =A0

=A0

Nat

On Fri, Jun 15, 2012 at 2:18 AM, rui wang <ruiwangwarm@gmail.com<= /a>> wrote:

Dear Facebook Security Team and OAuth Standard group= ,

Recently, we found a common misunderstanding among d= evelopers of mobile/metro apps when using OAuth (including Facebook=92s OAu= th) for authentication. The vulnerability resulted from this misunderstanding also allows an attacker to log into a victim user= 9;s account without password.

Let's take Soluto's metro app as an example = to describe the problem. The app supports Facebook Login. As an attacker, w= e can write a regular Facebook app. Once the victim user allows our app to access her Facebook data, we receive an access_token from the t= raffic. Then, on our own machine (i.e., the "attacker" machine), = we run the metro app of Soluto, and use a HTTP proxy to insert the victim&#= 39;s access_token into the traffic of Facebook login. Through this way, we are able to log into the victim's Soluto a= ccount from our machine. Other than Soluto, we also have confirmed the same= issue on another Windows 8 metro-app Givit.

The Facebook SDK for Android apps (https://developers.facebook.com/docs/mobile/android/build/#sdk) seems to have the possibility to mislead developers too. At least, the iss= ue that we found is not clearly mentioned. In the SDK, we ran the sample co= de called "Hackbook" using Android Emulator (imagine it is an att= acker device). Note that we have already received the access token of the victim user from our regular Facebook app. We then= inject the token to the traffic of Hackbook. Through this way, Hackbook ap= p on our own machine recognizes us as the victim. Note that this is not a c= onvincing security exploit yet, because this sample code does not include the server-side code. However, g= iven that we have seen real server-side code having this problem, such as S= oluto, Givit and others, we do believe that the sample code can mislead mob= ile/metro developers. We also suspect that this may be a general issue of many OAuth implementations on mobile p= latforms, so we send this message to OAuth Standard group as well.

We have contacted the vendors of the two vulnerable = metro-apps, Soluto and Gavit.

Please kindly give us an ack when you receive this m= essage. If you want to know more details, please let us know.=

Best Regards,
Yuchen Zhou, Rui Wang, and Shuo Chen


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



=A0

--
Nat Sakimura (=3Dnat)

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

=A0


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



=A0

--
Nat Sakimura (=3Dnat)

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

=A0

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

=A0

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

=A0



_______________________________________________
OAuth mailing list
OAuth@ietf.org=

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

=A0

=A0
=A0
_______________________________________________
OAuth mailing list
OAuth@ietf.org=

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


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



=A0

--
Nat Sakimura (=3Dnat)

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

=A0




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

--0015175cabaeeeb92104c2fe2210-- From asanso@adobe.com Thu Jun 21 10:05:05 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C36921F875A for ; Thu, 21 Jun 2012 10:05:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.998 X-Spam-Level: X-Spam-Status: No, score=-105.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8D6bUDfQM1-y for ; Thu, 21 Jun 2012 10:05:02 -0700 (PDT) Received: from exprod6og102.obsmtp.com (exprod6og102.obsmtp.com [64.18.1.183]) by ietfa.amsl.com (Postfix) with ESMTP id 9073721F85E0 for ; Thu, 21 Jun 2012 10:04:51 -0700 (PDT) Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob102.postini.com ([64.18.5.12]) with SMTP ID DSNKT+NULGgyqRSv/xqSSzHwnRWp4ajVkuUB@postini.com; Thu, 21 Jun 2012 10:04:57 PDT Received: from inner-relay-4.eur.adobe.com (inner-relay-4b [10.128.4.237]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id q5LH4hX9000488; Thu, 21 Jun 2012 10:04:43 -0700 (PDT) Received: from nacas02.corp.adobe.com (nacas02.corp.adobe.com [10.8.189.100]) by inner-relay-4.eur.adobe.com (8.12.10/8.12.9) with ESMTP id q5LH4bYt007537; Thu, 21 Jun 2012 10:04:41 -0700 (PDT) Received: from eurcas01.eur.adobe.com (10.128.4.27) by nacas02.corp.adobe.com (10.8.189.100) with Microsoft SMTP Server (TLS) id 8.3.192.1; Thu, 21 Jun 2012 10:04:39 -0700 Received: from eurmbx01.eur.adobe.com ([10.128.4.32]) by eurcas01.eur.adobe.com ([10.128.4.27]) with mapi; Thu, 21 Jun 2012 18:04:37 +0100 From: Antonio Sanso To: Eran Hammer Date: Thu, 21 Jun 2012 18:04:35 +0100 Thread-Topic: [OAUTH-WG] proposal of a paragraph to add to the security considerations section Thread-Index: Ac1Pz/A7LNaG+PzWSeKdTJkACLV6gw== Message-ID: <059A62F5-A2F8-4274-A5A8-E36B5A9BBC78@adobe.com> References: <854774286EF8A240BACC342973A86EAC016693D6@BL2PRD0310MB387.namprd03.prod.outlook.com> <484A13D0-7C9A-42CC-BB94-3657741834DE@ve7jtb.com> <82D95BA2-1697-4441-BBB3-B2AE480DC39E@gmail.com> <0CBAEB56DDB3A140BA8E8C124C04ECA20107B405@P3PWEX2MB008.ex2.secureserver.net> In-Reply-To: <0CBAEB56DDB3A140BA8E8C124C04ECA20107B405@P3PWEX2MB008.ex2.secureserver.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_059A62F5A2F84274A5A8E36B5A9BBC78adobecom_" MIME-Version: 1.0 Cc: rui wang , Yuchen Zhou , "Shuo Chen \(MSR\)" , Derek Atkins , "oauth@ietf.org" Subject: Re: [OAUTH-WG] proposal of a paragraph to add to the security considerations section X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 17:05:05 -0000 --_000_059A62F5A2F84274A5A8E36B5A9BBC78adobecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Eran, as a potential user of the specification this is bit sad as well to hear. If you really think this, being on of the editors, you might take a stab an= d trying to improve it (but I guess it is too late ....) Regards Antonio On Jun 21, 2012, at 4:17 PM, Eran Hammer wrote: The sad reality is, we've spent 3 years producing a specification that is l= ess secure, more complex, and does not interoperate the way OAuth 1.0 does. It does scale better for huge companies like Google, Microsoft, and Yahoo. = No wonder they wanted it this way. When asked, I tend to advise people using OAuth 1.0 to just keep using it. Oh well. EH From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of John Bradley Sent: Thursday, June 21, 2012 6:47 AM To: Hannes Tschofenig Cc: rui wang; Yuchen Zhou; Shuo Chen (MSR); Derek Atkins; oauth@ietf.org Subject: Re: [OAUTH-WG] proposal of a paragraph to add to the security cons= iderations section Hi Hannes, MAC tokens protect resources against token leakage to third parties. That = is useful but a different threat. The easiest way to get a access token for someone is to have them log into = your site. If you can do that the token type makes no difference unless we move to a a= symmetric holder of key token (different discussion). The bad client gets the access MAC token and token secret and can re use it= just as it would a bearer token. The origin of the post was a contention by someone at Facebook that profili= ng OAuth 2.0 on its own is sufficient to produce an Authentication protocol= . I was trying to point out that OAuth 2 without any extensions, only profili= ng is difficult to impossible to use for authentication as the attack surfa= ce and security considerations are different. As it turned out Facebook had extended OAuth 2 with signed requests and tok= en introspection techniques to address these issues for themselves. The problem as it turned out was that individual apps and app frameworks l= ike the iOS one made some bad mistakes, by not using the perhaps under docu= mented extensions. The problem is not unique to Facebook in any way they are just a convenient= example. Oauth 2 is not surprisingly mostly about protecting the resource. Authentication is about protecting the client. Audience restriction from openID 2, SAML, WS* etc prevents replay of token= s issued to one RP/SP at another. That is sort of authentication protocol threat number 1. OAuth has no way to do that with access tokens. It can however do it with "code" if the client is confidential. So my recommendation is that without extensions to OAuth like structured to= kens (signed_request, id_token) or token introspection endpoints like Facebook ( https://graph.facebook.com/app?access_token=3D[The Access Token]), there is no safe w= ay to use an implicit flow for authentication. A code flow where a native app exchanges code for the access token and then= passes the access token back to it's server is also vulnerable (lots of th= is in circulation I understand) The only safe flow (without extensions) is the code flow where the client i= s confidential and the code is directly exchanged for the access token. This also requires the definition of a identity API that is protected by th= e access token, and out of scope for OAuth. So at the end of the day the rational conclusion is that OAuth 2 is a autho= rization protocol. It may be used by Authentication protocols, but it is up to other specs to = define the security considerations for that. That however doesn't remove the need to mention the token substitution atta= ck that non confidential clients are subject to, do to there being no other= mechanism for the client to know who the token was issued to. John B. On 2012-06-21, at 5:27 AM, Hannes Tschofenig wrote: Hi John, I read through your blog post. I am not sure whether I can entirely agree w= ith your separation between authentication and authorization. I believe the= core issue here is that * anyone who has the token will get access to whatever the token entitles h= im or her to do (unless there are restrictions in the token) * some attributes are different than others. With authentication you typica= lly associate that the process took place recently (i.e., it is fresh) whil= e other attributes do not require the user (as resource owner) to actively = participate in the exchange and the same level of freshness is not implied.= For authentication in a three party protocol to be useful the three parti= es have to participate (see http://tools.ietf.org/id/draft-tschofenig-oauth= -signature-thoughts-00.txt). I understand that one wants to avoid having tokens passed around from one a= pplication to the other one, as it is happening here. I remember having some of these discussions with Eran a long time ago. He a= nticipated that implementers will not put any constraints in the tokens and= hence they will be misused. This serves as an argument for him to propose = the MAC token specification. I proposed text for the security consideration section of the bearer docume= nt a while ago and it even talks about audience restriction as a recommenda= tion. There are two problems with the audience restriction: 1) There is no mandatory token format defined nor do we mandate token conte= nt either. Hence we do not strongly require anything specifically to be put= into the tokens. 2) In the implicit grant flow the client isn't authenticated and hence what= do you want to put into a token as an audience restriction? Finally, I think that the "audience restriction" terminology is a bit fuzzy= for this discussion either. Audience restriction can mean two things: * Allowing the client to verify that the access token has indeed been issue= d for him / her. * Allowing the resource server verify that the received access token from a= specific client has indeed been provided by that client. My current believe is that the implicit grant flow is unsuitable for provid= ing authentication functionality. Ciao Hannes On Jun 19, 2012, at 5:50 AM, John Bradley wrote: I can put something together. It is mostly a warning about the token substitution attack that any implici= t flow is vulnerable to if used for authentication of the presenter. Otherwise known as why audience restriction is a good thing. John B. On 2012-06-18, at 8:20 PM, Dick Hardt wrote: John Do you have suggested text per your suggestion below? -- Dick On Jun 18, 2012, at 2:04 PM, John Bradley wrote: I blogged about this in the hypothetical several months ago. http://www.thr= ead-safe.com/2012/01/problem-with-oauth-for-authentication.html Nov Matake and others built some tests and found quite a number of deployme= nts vulnerable. http://www.thread-safe.com/2012/02/more-on-oauth-implicit-flow-application.= html The bottom line is that OAuth has no explicit audience restriction for toke= ns, hence accepting any token outside of the code flow is subject to attac= k. In general it is not a issue for authorization, it is however a big issue = then there is a presumption that the presenter of a token that grants a cli= ent access to resource x is the "resource owner" of resource x, when it is = possible that the presenter is any client who has ever had a access token f= or resource x. We might want to include the why it is insecure in the security considerati= on, otherwise people reading the below will likely ignore the advice as it= seems on the surface a touch extreme. There are certainly OAuth flows that allow you to do authentication safely,= just not all of them without additional precautions. That is why openID Connect has a audience restricted id_token similar to Fa= cebook's signed request to allow the implicit flows to be safely used for a= uthentication. John B. On 2012-06-18, at 4:19 PM, Shuo Chen (MSR) wrote: Hi OAuth group, This is regarding the recent discussion about an implementation issue of so= me cloud services using OAuth for authentication. Derek Atkins and Dick Hardt suggested the possibility to discuss with the g= roup a paragraph to add to the security considerations section. Derek=92s suggestion: =3D=3D=3D=3D =3D=3D=3D =3D=3D=3D =3D=3D=3D Perhaps you could boil it down to a paragraph or two for addition to the security considerations section that basically s= ays "beware of implementing it *this* way because it leads to *that* attack vec= tor", etc. =3D=3D=3D=3D =3D=3D=3D =3D=3D=3D =3D=3D=3D Here is out suggested text: =3D=3D=3D=3D =3D=3D=3D =3D=3D=3D =3D=3D=3D It has been observed that in multiple occasions that the server-side authentication logic takes an access token from the client, then queries the user's profile data from the IdP in order to "authenticate" the user. This implementation must be forbidden. It will allow an untrusted app running on a victim=92s client device to work with an attacker=92s device to sign into the victim=92s account on the= server side. =3D=3D=3D=3D =3D=3D=3D =3D=3D=3D =3D=3D=3D Thank you. -Shuo p.s. below is the email thread giving a better context of the discussion. -----Original Message----- From: Derek Atkins [mailto:derek@ihtfp.com] Sent: Monday, June 18, 2012 11:25 AM To: Shuo Chen (MSR) Cc: Hannes Tschofenig; rui wang; Stephen Farrell; Yuchen Zhou; Derek Atkins; Dick Hardt Subject: Re: [OAUTH-WG] web sso study... Hi, "Shuo Chen (MSR)" > w= rites: Hi Hannes, Derek and Stephen, Thank you for your replies. First, let me ask whether it is OK if I share your post with the OAuth WG Yes, please feel free to share it. Second, could you describe the attack in more details to me? Let's consider the mobile+cloud scenario for concreteness (although some other scenarios are also applicable). The attack steps are the following: suppose Alice's tablet runs a Windows 8 Metro app written by attacker Bob. This app is able to request and obtain an access token from the IdP (associated with Alice). The app can then send the access token to Bob's own tablet. Note that there is no security problem up to this point. However the real problem is that some cloud services use the access token to query the user's profile data from the IdP in order to "authenticate" the user. In this case, Bob's tablet will be able to sign into the cloud service as Alice. We have confirmed that the cloud services for Soluto Metro App, Givit Metro App and EuroCup2012 Metro App make this mistake. These are apps in the official Windows 8 App Store. We actually sampled only a small portion = of the available apps, but believe this is a vulnerability pattern. We don=92t think there is anything wrong in the OAuth spec. It is developers who didn=92t comprehensively understand the usage of the access token. In the meanwhile, this vulnerability pattern is not explicitl= y excluded by the spec. More importantly, it has been seen in the wild. [from Derek's email] Perhaps you could boil it down to a paragraph or two for addition to the security considerations section that basically says "beware of implementing it *this* way because it leads to *that* attack vec= tor", etc. This is a great idea. I think that although it is difficult to anticipate in general all kinds of incomprehensive understandings of average developers, it is very worthwhile to take any common existing vulnerability pattern as a precious feedback to improve the specification text. In this case, since we have already seen this vulnerability pattern on multiple services in the wild, certainly we should be explicit about it in the security considerations section. Our suggested text: It has been observed that in multiple occasions that the server-side authentication logic takes an access token from the client, then queries the user's profile data from the IdP in order to "authenticate" the user. This implementation must be forbidden. It will allow an untrusted app running on a victim=92s client device to work with an attacker=92s device to sign into the victim=92s account on the= server side. Any questions or suggestions? Could you please send this to the oauth@ietf.org mai= ling list? Thanks a lot. -Shuo -derek -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] Sent: Friday, June 15, 2012 11:36 AM To: rui wang Cc: Hannes Tschofenig; Stephen Farrell; Shuo Chen (MSR); Yuchen Zhou; Derek Atkins Subject: Re: [OAUTH-WG] web sso study... Hi Rui, let me independently respond (in addition to the previous responses you had already gotten). First, let me ask whether it is OK if I share your post with the OAuth WG since it is more detailed than the one you distributed on the list= mid April. Second, could you describe the attack in more details to me? What I would like to better understand whether this the raised issue is a problem with one of our specifications, with a specific implementation of the IETF OAuth specifications, a problem with other OAuth related work (Facebook, as you know, implements far more than just the IETF OAuth specifications), a violation of the IETF OAuth specification in the way how the Websites use OAuth, whether this is a configuration related aspect, or an aspect we already documented in the t= hreats document. The reason why I am so specific is to know where to put text to address this issue or whether this is even an issue beyond the IETF OAuth working group and needs to be tackled somewhere else. 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 --_000_059A62F5A2F84274A5A8E36B5A9BBC78adobecom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
The sad reality i= s, we've spent 3 years producing a specification that is less secure, more = complex, and does not interoperate the way OAuth 1.0 does.
 
= It does scale better for huge companies like Google, Microsoft, and Yahoo. = No wonder they wanted it this way.
When asked, I tend to ad= vise people using OAuth 1.0 to just keep using it.
<= div style=3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; m= argin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; ">=  
Oh well.=
 
<= span style=3D"font-size: 11pt; font-family: Calibri, sans-serif; color: rgb= (31, 73, 125); ">EH
 
From: = oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley
Sent: Thursday, June 21, 2012 6:47 AM
To: Hannes Tschofenig
Cc:=  rui wang; Yuchen Zho= u; Shuo Chen (MSR); Derek Atkins;&nbs= p;oauth@ietf.org
Subject: Re: [OAUTH-WG] proposal of a paragraph to = add to the security considerations section
 
Hi Hannes,
 
MAC tokens protect resources against token leakage to = third parties.  That is useful but a different threat.  
 
The easiest way to g= et a access token for someone is to have them log into your site.  &nb= sp;
 
If you c= an do that the token type makes no difference unless we move to a asymmetri= c holder of key token (different discussion).
<= o:p> 
The bad client gets the access MAC token = and token secret and can re use it just as it would a bearer token.
 
The origin of the p= ost was a contention by someone at Facebook that profiling OAuth 2.0 on its= own is sufficient to produce an Authentication protocol.
<= /div>
 
I was trying to point out tha= t OAuth 2 without any extensions, only profiling is difficult to impossible= to use for authentication as the attack surface and security consideration= s are different.
 
<= div>
As it turned out Facebook had extended OAuth 2 with signed requests an= d token introspection techniques to address these issues for themselves. &n= bsp; 
 
T= he problem as it turned out was that individual apps and  app framewor= ks like the iOS one made some bad mistakes, by not using the perhaps under = documented extensions.
 
<= /div>
The problem is not unique to Facebook in any way they are just a= convenient example.
 
Oauth 2  is not surprisingly mostly about protectin= g the resource.  
 
<= /div>
Authentication is about protecting the client.
<= /div>
 
Audience restriction from ope= nID 2, SAML,  WS* etc prevents replay of tokens issued to one RP/SP at= another.  
That is sort of authentication= protocol threat number 1.
 
OAuth has no way to do that with access tokens.
 
It can however do it wit= h "code" if the client is confidential.
&n= bsp;
So my recommendation is that without extensions= to OAuth like structured tokens (signed_request, id_token) or token intros= pection endpoints like 
Facebook ( https://graph.facebook.com/app?access_token=3D[The Access Token]), there is no safe way to use an implicit flow f= or authentication.
A code flow where a native app exchanges code for the access to= ken and then passes the access token back to it's server is also vulnerable= (lots of this in circulation I understand)
 
The= only safe flow (without extensions) is the code flow where the client is c= onfidential and the code is directly exchanged for the access token.=
This also req= uires the definition of a identity API that is protected by the access toke= n, and out of scope for OAuth.
&nbs= p;
So at the end of= the day the rational conclusion is that OAuth 2 is a authorization protoco= l.   
It may be used by Authentication protocols, but it is up to other = specs to define the security considerations for that.
 
That however doesn't remove the need to mention the token substituti= on attack that non confidential clients are subject to, do to there being n= o other mechanism for the client to know who the token was issued to.
 
John B.
&nb= sp;
 
 
 
 <= /div>
On 2012-06-21, at 5:27 AM, Hannes Tschofenig wrote:


Hi John, 

I read through your blog post. I am = not sure whether I can entirely agree with your separation between authenti= cation and authorization. I believe the core issue here is that 

* anyone who has the token = will get access to whatever the token entitles him or her to do (unless the= re are restrictions in the token)

* some attributes are different th= an others. With authentication you typically associate that the process too= k place recently (i.e., it is fresh) while other attributes do not require = the user (as resource owner) to actively participate in the exchange and th= e same level of freshness is not implied.  For authentication in a thr= ee party protocol to be useful the three parties have to participate (see http://tools.ietf.org/id/draft-tschofe= nig-oauth-signature-thoughts-00.txt). 

I understand that one wants to avoid having tokens= passed around from one application to the other one, as it is happening he= re. 

I remember ha= ving some of these discussions with Eran a long time ago. He anticipated th= at implementers will not put any constraints in the tokens and hence they w= ill be misused. This serves as an argument for him to propose the MAC token= specification. 

I= proposed text for the security consideration section of the bearer documen= t a while ago and it even talks about audience restriction as a recommendat= ion. 

There are tw= o problems with the audience restriction: 

1) There is no mandatory token format defined nor = do we mandate token content either. Hence we do not strongly require anythi= ng specifically to be put into the tokens. 

2) In the implicit grant flow the client isn't au= thenticated and hence what do you want to put into a token as an audience r= estriction? 

Final= ly, I think that the "audience restriction" terminology is a bit fuzzy for = this discussion either. <= br>Audience restriction can mean two things:

* Allowing the client t= o verify that the access token has indeed been issued for him / her. 
* Allowing the resource ser= ver verify that the received access token from a specific client has indeed= been provided by that client. <= /span>

My current believe is that the implicit grant flow is unsuita= ble for providing authentication functionality. 

Ciao
Hannes

On Jun 19, 2012, at 5:= 50 AM, John Bradley wrote:


I can put something= together.   
 
It is mostly a warning abou= t the token substitution attack that any implicit flow is vulnerable to if = used for authentication of the presenter.
Otherwise known as= why audience restriction is a good thing.
 =
John B.
 
On 2012-06-18, at 8:20 PM= , Dick Hardt wrote:
 
John
 
Do you have suggested text per your suggestion below?
<= o:p> 
-- Dick
 
<= blockquote style=3D"margin-top: 5pt; margin-bottom: 5pt; ">
On Jun 18, 2012= , at 2:04 PM, John Bradley wrote:
 
I blogged about this in= the hypothetical several months ago.=  http://www.thread-safe.com/2012/01/problem-with-oauth-for-authenticati= on.html
 
Nov Matake and others built some t= ests and found quite a number of deployments vulnerable.
 
The bottom line is that OAuth has no explicit audi= ence restriction for tokens,  hence accepting any token outside of the= code flow is subject to attack.
=
 
In general it= is not a issue for authorization,  it is however a big issue then the= re is a presumption that the presenter of a token that grants a client acce= ss to resource x is the "resource owner" of resource x, when it is possible= that the presenter is any client who has ever had a access token for resou= rce x.
 
We might want to include the why it is = insecure in the security consideration,  otherwise people reading the = below will likely ignore the advice as it seems on the surface a touch extr= eme.
 
There are certainly OAuth flows that allo= w you to do authentication safely,  just not all of them without addit= ional precautions.
<= blockquote style=3D"margin-top: 5pt; margin-bottom: 5pt; ">
 
That is why openID Connect = has a audience restricted id_token similar to Facebook's signed request to = allow the implicit flows to be safely used for authentication.
<= o:p> 
John B.
 
 
 
 
On 2012-06-18, at 4:19 PM, Shuo Chen (MSR)= wrote:
 
Hi OAuth group,
 
This is rega= rding the recent discussion about an implementation issue of some cloud ser= vices using OAuth for authentication.
Derek Atkins and Dick Hardt = suggested the possibility to discuss with the group a paragraph to add to t= he security considerations section.
<= blockquote style=3D"margin-top: 5pt; margin-bottom: 5pt; ">
 
=
Derek=92s sugg= estion:
=3D=3D=3D=3D   =3D=3D=3D  =3D=3D=3D  = =3D=3D=3D
Perhaps y= ou could boil it down to a paragraph
or two for addition to the secu= rity considerations section that basically says
"beware of implementin= g it *this* way because it leads to *that* attack vector", etc.<= /div>
=3D=3D=3D=3D   =3D=3D=3D  =3D=3D=3D =  =3D=3D=3D
 
<= /blockquote>
 
Here is out sugges= ted text:
=3D=3D=3D=3D   =3D=3D=3D  =3D=3D=3D  = ;=3D=3D=3D
It has been observed that in multiple occasions that th= e server-side
authentication logic takes an access token from the = client, then
queries the user's profile data from the IdP in order= to
"authenticate" the user. This implementation must be forbidde= n. It
<= blockquote style=3D"margin-top: 5pt; margin-bottom: 5pt; ">
will allow an untrusted app running on a victim=92s client d= evice to
work with an attacker=92s device to sign into the victim= =92s account on the server side.
=
=3D=3D=3D=3D   =3D=3D= =3D  =3D=3D=3D  =3D=3D=3D
<= blockquote style=3D"margin-top: 5pt; margin-bottom: 5pt; ">
 
=
 
-Shuo
p.s. below is the email thread giving = a better context of the discussion.
<= blockquote style=3D"margin-top: 5pt; margin-bottom: 5pt; ">
 
=
 
-----Original= Message-----
From: Derek Atkins [mailto:derek@ihtfp.com]=
S= ent: Monday, June 18, 2012 11:25 AM
To: Shuo Chen (MSR)<= /div>
Cc: = Hannes Tschofenig; rui wang; Stephen Farrell; Yuchen Zhou; Derek=
A= tkins; Dick Hardt
Subject: Re: [OAUTH-WG] web sso study...
<= o:p> 
<= /blockquote>
Hi,
 
<= /blockquote>
"Shuo Chen (MSR)" <shuochen@microsoft.com> writes:
 
<= /blockquote>
Hi Hannes, Derek and Step= hen,
 
Thank you for your replies.
 
First, let me ask wheth= er it is OK if I share your post with the
<= blockquote style=3D"margin-top: 5pt; margin-bottom: 5pt; ">
<= blockquote style=3D"margin-top: 5pt; margin-bottom: 5pt; ">
OAuth WG
<= o:p> 
<= /blockquote>
Yes, please feel free to share it.
=
 
<= /blockquote>
Second, could you describe = the attack in more details to me?
 
=
Let's con= sider the mobile+cloud scenario for concreteness (although
=
some othe= r scenarios are also applicable). The attack steps are the
=
following= : suppose Alice's tablet runs a Windows 8 Metro app written
by attack= er Bob. This app is able to request and obtain an access
token from th= e IdP (associated with Alice). The app can then send the
access token = to Bob's own tablet. Note that there is no security
problem up to th= is point. However the real problem is that some cloud
services use the= access token to query the user's profile data from
the IdP in order= to "authenticate" the user. In this case, Bob's
tablet will be able t= o sign into the cloud service as Alice. We have
confirmed that the clo= ud services for Soluto Metro App, Givit Metro
=
App and EuroCup2012 Metr= o App make this mistake. These are apps in
the official Windows 8 App = Store. We actually sampled only a small portion of the available apps, but = believe this is a vulnerability pattern.
=
 
We don=92t think= there is anything wrong in the OAuth spec. It is
developers who didn= =92t comprehensively understand the usage of the
access token. In the = meanwhile, this vulnerability pattern is not explicitly excluded by the spe= c.
More importantly, it has been seen in the wild.
=
=
 
<= /blockquote>
[from Derek's em= ail] Perhaps you could boil it down to a paragraph
or two for=
addition to the security considerations section that basically says=
"beware of implementing it *this* way because it leads to *that* atta= ck vector", etc.
 
This is a great idea. I think that althou= gh it is difficult to
anticipate in general all kinds of incomprehen= sive understandings of
average developers, it is very worthwhile to t= ake any common existing
vulnerability pattern as a precious feedback t= o improve the
specification text. In this case, since we have already = seen this
<= blockquote style=3D"margin-top: 5pt; margin-bottom: 5pt; ">
vulnerability pattern on multiple services in the wild, cert= ainly we
should be explicit about it in the security considerations se= ction.
=
 
Our suggested text:
=
 
<= /blockquote>
It has been = observed that in multiple occasions that the server-side
authenticatio= n logic takes an access token from the client, then
queries the user= 's profile data from the IdP in order to
=
"authenticate" the user. This= implementation must be forbidden. It
will allow an untrusted app run= ning on a victim=92s client device to
work with an attacker=92s devic= e to sign into the victim=92s account on the server side.
<= /blockquote>
 <= /o:p>
<= blockquote style=3D"margin-top: 5pt; margin-bottom: 5pt; ">
<= div style=3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; m= argin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; ">= Any questions or suggestions?
 
Could you= please send this to the = oauth@ietf.org mailing list?
<= /blockquote>
 
=
Thanks a lot.
 
-Shuo
 
-derek
 
-----Original Message-----
From: Han= nes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
Sent: Fri= day, June 15, 2012 11:36 AM
To: rui wang
=
Cc: Hannes Tschofenig; S= tephen Farrell; Shuo Chen (MSR); Yuchen Zhou;
=
Derek Atkins<= /div>
Subjec= t: Re: [OAUTH-WG] web sso study...
 
Hi Rui,
&nbs= p;
=
=
you had already gotten).
=
 
First, let me ask whether it is= OK if I share your post with the
OAuth WG since it is more detailed t= han the one you distributed on the list mid April.
 
Second,= could you describe the attack in more details to me? What I
would lik= e to better understand whether this the raised issue is a
<= /blockquote>
problem with= one of our specifications, with a specific
implementation of the IETF= OAuth specifications, a problem with other
OAuth related work (Facebo= ok, as you know, implements far more than
just the IETF OAuth specific= ations), a violation of the IETF OAuth
specification in the way how th= e Websites use OAuth, whether this is
a configuration related aspect,= or an aspect we already documented in the threats document.
&nbs= p;
a= ddress this issue or whether this is even an issue beyond the IETF
O= Auth working group and needs to be tackled somewhere else.
=
&nbs= p;
 
Hannes
=
 
<= /blockquote>
_______________________________________________
OAuth mailing= list
<= blockquote style=3D"margin-top: 5pt; margin-bottom: 5pt; ">
<= /blockquote>
 
______________________________________________= _
OAuth mailing list
=
 
 
_______________________________________________
OAuth mailing list
 
 
___________________= ____________________________
OAuth mailing list
OAuth@ietf= .org
https://www.ietf.org/mailman= /listinfo/oauth

= --_000_059A62F5A2F84274A5A8E36B5A9BBC78adobecom_-- From internet-drafts@ietf.org Thu Jun 21 10:53:17 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FFFE21F86F8; Thu, 21 Jun 2012 10:53:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.371 X-Spam-Level: X-Spam-Status: No, score=-102.371 tagged_above=-999 required=5 tests=[AWL=0.228, 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 T27soS7Jlrvt; Thu, 21 Jun 2012 10:53:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11F9721F86DF; Thu, 21 Jun 2012 10:53:17 -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.20 Message-ID: <20120621175317.32545.76545.idtracker@ietfa.amsl.com> Date: Thu, 21 Jun 2012 10:53:17 -0700 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-urn-sub-ns-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2012 17:53:17 -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 : An IETF URN Sub-Namespace for OAuth Author(s) : Brian Campbell Hannes Tschofenig Filename : draft-ietf-oauth-urn-sub-ns-03.txt Pages : 7 Date : 2012-06-21 Abstract: This document establishes an IETF URN Sub-namespace for use with OAuth related specifications. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-urn-sub-ns There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-urn-sub-ns-03 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-urn-sub-ns-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From hannes.tschofenig@gmx.net Thu Jun 21 11:14:22 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E99E21F876A for ; Thu, 21 Jun 2012 11:14:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.192 X-Spam-Level: X-Spam-Status: No, score=-102.192 tagged_above=-999 required=5 tests=[AWL=-0.193, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dy1uA0akZvL9 for ; Thu, 21 Jun 2012 11:14:21 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 0E48F21F875A for ; Thu, 21 Jun 2012 11:14:19 -0700 (PDT) Received: (qmail invoked by alias); 21 Jun 2012 18:14:08 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.101]) [88.115.216.191] by mail.gmx.net (mp036) with SMTP; 21 Jun 2012 20:14:08 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX188r8UwD2s8K1F3ujyHT7+bhftMZ7IkWScxTcwMYf 2seio0C9DjY0CO Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <4FE1C16D.6010602@cs.tcd.ie> Date: Thu, 21 Jun 2012 21:13:56 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4FE1C16D.6010602@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-urn-sub-ns-02 X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 18:14:22 -0000 Hi Stephen,=20 thanks for the review comments. ; On Jun 20, 2012, at 3:26 PM, Stephen Farrell wrote: >=20 > Hi, >=20 > Many thanks for a nice short document! >=20 > I've a few questions though and suspect that a quick re-spin > might be needed, but let's see what the wg think about 'em > first. >=20 > (1) Why Informational? Everything else at that level seems to > be specified in a standards track or BCP level RFC, and IETF > Consensus is required. [1] I think you have to do this as > standards track. Did I miss something? >=20 Standards Track is OK.=20 > [1] http://www.iana.org/assignments/params/params.xml >=20 > (2) Do you *really* want RFC or specification required for all > registrations? I don't care, but there is a trend away from > that at the moment since its been found to discourage > registrations in a lot of cases. Perhaps expert review would > be ok? No trying to push you one way or the other, I just > wanted to check. That's a good question.=20 There are a few documents in the OAuth WG that define new sub-namespaces = under urn:ietf:params:oauth.=20 It would be good to get the policy for creating new extensions inline = with what the registry demands.=20 So, for example if I look at the extension policy for 'grant-types' of = http://datatracker.ietf.org/doc/draft-ietf-oauth-v2/ says 'Specification = Required'.=20 On the other hand OAuth core has an interesting policy here since = specification required is not enough but it has to be followed by a call = for review on some IETF mailing list.=20 If the goal is to get this document inline with what our existing = documents say then 'Specification Required' would be the right policy = here as well. >=20 > (3) If answer to (2) is yes: Section 5.1 says "Specification > Required" but section 3 said "RFC Required" and those differ. > For example, an OASIS spec would not be ok if you say RFC > required. I don't know if you care, but you need to be > consistent. (Or else I've misread something;-) Of course it is nice to keep the overhead low to define new extensions = but the consequence then is that some of these extensions will have very = dubious quality. As an example of this have a look at the EAP methods.=20= So, I am curious where to hit the right level of process here to find = the sweetspot between low overhead and high quality specifications.=20 >=20 > (4) Isn't the template missing the reference to the RFC or > other specification that defines the URN? Not sure what you mean.=20 >=20 > (5) I don't get section 3, sorry;-) Can you give an example of > a class:id pair that'd be registered? Asking IANA to generate > the id part seems odd. http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-12, for = example, asks for registration of = urn:ietf:params:oauth:grant-type:saml2-bearer. Ciao Hannes From Michael.Jones@microsoft.com Thu Jun 21 11:14:43 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E275321F877E for ; Thu, 21 Jun 2012 11:14:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.824 X-Spam-Level: X-Spam-Status: No, score=-3.824 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XMUP35khtFIz for ; Thu, 21 Jun 2012 11:14:41 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe005.messaging.microsoft.com [216.32.181.185]) by ietfa.amsl.com (Postfix) with ESMTP id C7F8121F875A for ; Thu, 21 Jun 2012 11:14:34 -0700 (PDT) Received: from mail140-ch1-R.bigfish.com (10.43.68.251) by CH1EHSOBE013.bigfish.com (10.43.70.63) with Microsoft SMTP Server id 14.1.225.23; Thu, 21 Jun 2012 18:13:07 +0000 Received: from mail140-ch1 (localhost [127.0.0.1]) by mail140-ch1-R.bigfish.com (Postfix) with ESMTP id 9AAF980384; Thu, 21 Jun 2012 18:13:06 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -28 X-BigFish: VS-28(zz9371I936eI542M1447Izz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25hf0ah) Received-SPF: pass (mail140-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail140-ch1 (localhost.localdomain [127.0.0.1]) by mail140-ch1 (MessageSwitch) id 1340302384990439_10242; Thu, 21 Jun 2012 18:13:04 +0000 (UTC) Received: from CH1EHSMHS003.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.232]) by mail140-ch1.bigfish.com (Postfix) with ESMTP id E5F2D400062; Thu, 21 Jun 2012 18:13:04 +0000 (UTC) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS003.bigfish.com (10.43.70.3) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 21 Jun 2012 18:13:04 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.53]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.02.0309.003; Thu, 21 Jun 2012 18:14:18 +0000 From: Mike Jones To: Brian Campbell Thread-Topic: [OAUTH-WG] I-D Action: draft-ietf-oauth-urn-sub-ns-03.txt Thread-Index: AQHNT9bbR+7wOx82f0K640qXd1uXTpcFEcsQ Date: Thu, 21 Jun 2012 18:14:16 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436656323F@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <20120621175317.32545.76545.idtracker@ietfa.amsl.com> In-Reply-To: <20120621175317.32545.76545.idtracker@ietfa.amsl.com> 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-urn-sub-ns-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2012 18:14:43 -0000 This draft is much clearer. Thanks for the quick turn-around. One question: You added: *Index value: values subordinate to urn:ietf:params:oauth are of the from= urn:ietf:params:oauth:: with : as the index value Why bake the assumption of a two-level structure into the registry? For instance, you could easily imagine legal and useful registrations of th= e form ::, etc. Maybe change this to say: *Index value: values subordinate to urn:ietf:params:oauth are of the from= urn:ietf:params:oauth: with as the index value. It is sugg= ested that include both a "class" and an "identifier-within-class" = component, with the two components being separated by a colon (":"); other = compositions of the may also be used. -- Mike -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of i= nternet-drafts@ietf.org Sent: Thursday, June 21, 2012 10:53 AM To: i-d-announce@ietf.org Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-urn-sub-ns-03.txt 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 : An IETF URN Sub-Namespace for OAuth Author(s) : Brian Campbell Hannes Tschofenig Filename : draft-ietf-oauth-urn-sub-ns-03.txt Pages : 7 Date : 2012-06-21 Abstract: This document establishes an IETF URN Sub-namespace for use with OAuth related specifications. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-urn-sub-ns There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-urn-sub-ns-03 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-urn-sub-ns-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 From barryleiba.mailing.lists@gmail.com Thu Jun 21 11:29:40 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3CF421F8768 for ; Thu, 21 Jun 2012 11:29:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.932 X-Spam-Level: X-Spam-Status: No, score=-102.932 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pZ9jlil1KSp9 for ; Thu, 21 Jun 2012 11:29:39 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id BAA1921F8763 for ; Thu, 21 Jun 2012 11:29:38 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so2735317lbb.31 for ; Thu, 21 Jun 2012 11:29:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=dHuORRvNurQRxCk+y7FXz3gbnavaBSXLp3QYzEXVSlQ=; b=I9NaXEMtKoIKAO8hWJsRUF9O3s6AtXUpY29tXZdZfI4fLnAO0KYzb9DBDmLSreH0hW 38rtproqnxrTV+/LE4lbaZ8lo/qaiFcjBfBOJv/4WeRdU2GPro93/c/T3o3FkKpjOTt1 ON7FDyPCsPRpG47Z44N9e4lA5RQS1OI0mRgdIurPpnY0mVymzjP8zicC4KmLHTWJJqti hPqla7I+JlYCl9hh82Td8A4S/kP4ZNIAeVsq0F8e+DcWxujDpno06XfdjTWxPRvQ+WhT fNzO4zNDRcXHJaW/rGckCy/dgP/Sjkad+K8nWXUiAAR9Phn0NKvrSnq8RHJp8b+tHl5p TGsQ== MIME-Version: 1.0 Received: by 10.152.103.11 with SMTP id fs11mr27325699lab.23.1340303377596; Thu, 21 Jun 2012 11:29:37 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.48.104 with HTTP; Thu, 21 Jun 2012 11:29:37 -0700 (PDT) In-Reply-To: References: <4FE1C16D.6010602@cs.tcd.ie> Date: Thu, 21 Jun 2012 14:29:37 -0400 X-Google-Sender-Auth: _5htFmsu_ZmG0mRrVoP_UX4Qfa8 Message-ID: From: Barry Leiba To: Hannes Tschofenig Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-urn-sub-ns-02 X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 18:29:40 -0000 >> (1) Why Informational? Everything else at that level seems to >> be specified in a standards track or BCP level RFC, and IETF >> Consensus is required. [1] I think you have to do this as >> standards track. Did I miss something? >> > Standards Track is OK. Stephen: Yeah, I'm not sure Standards Track is needed. Other than "Other documents like it are Standards Track," explain why Informational doesn't work. Is there some procedural reason that these IANA actions can't be done with an Informational document? Is there any expectation that this will be reviewed and modified and progress along any sort of track at all? Certainly, this doesn't define any sort of "standard" that I can see. Informational documents in the IETF Stream *do* have "IETF Consensus". >> (2) Do you *really* want RFC or specification required for all >> registrations? =A0I don't care, but there is a trend away from >> that at the moment since its been found to discourage >> registrations in a lot of cases. Perhaps expert review would >> be ok? =A0No trying to push you one way or the other, I just >> wanted to check. ... > If the goal is to get this document inline with what our existing documen= ts say > then 'Specification Required' would be the right policy here as well. Hannes: I'm going to really push hard on this point: the goal is *NOT* to make all the registration policies the same, and I will resist that strongly. The *goal* is to use for each registry a registration policy that makes sense for *that* registry. That means that you (well, someone) need to tell me why *this* registry needs the strictness that you pick for it. What will the harm be in leaving it to Expert Review, and letting the designated expert decide how much documentation to require? And remember, you can document guidelines for the designated expert. For that matter, what will the *harm* be in simply letting it be First Come First Served? We have far too many too-strict registration policies in effect, and they often come back and bite on the ass the very people who picked the policies. > So, I am curious where to hit the right level of process here to find the= sweetspot > between low overhead and high quality specifications. You also need to consider whether poorly documented and unused extensions really cause any *harm*. If some bozo writes a bad spec for a stupid idea, and no one implements it because the spec is bad and the idea is stupid, so what? On the other hand, if some big company decides it's too much trouble to follow IETF procedures and chooses not to register their extension, but everyone winds up using it because they're big and it's necessary, what was the point of making the registration hard? That's the real balance we have to look at. Barry From bcampbell@pingidentity.com Thu Jun 21 11:35:28 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA9F021F877D for ; Thu, 21 Jun 2012 11:35:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.877 X-Spam-Level: X-Spam-Status: No, score=-5.877 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WQHBRib9nMI6 for ; Thu, 21 Jun 2012 11:35:28 -0700 (PDT) Received: from na3sys009aog107.obsmtp.com (na3sys009aog107.obsmtp.com [74.125.149.197]) by ietfa.amsl.com (Postfix) with ESMTP id C12FD21F8768 for ; Thu, 21 Jun 2012 11:35:27 -0700 (PDT) Received: from mail-qa0-f48.google.com ([209.85.216.48]) (using TLSv1) by na3sys009aob107.postini.com ([74.125.148.12]) with SMTP ID DSNKT+Npb+ZTN/yzgxQ4MN4Wox6+Olm37WxV@postini.com; Thu, 21 Jun 2012 11:35:27 PDT Received: by qadz32 with SMTP id z32so960782qad.14 for ; Thu, 21 Jun 2012 11:35:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type :x-gm-message-state; bh=DmUyiJJiCJT9A5hpw8gHvYBa2dDTm41HHxnAj8bHFJk=; b=b9i6nI6beRS+WWr4QgHItGHAuVhCsM8rpXuHu4CRhR2S7+nYCuNsywqqNZnV1O3vGw aNSDXySKz4HlTx0hFD/fXj9ER3Fr60qVX9sE+E2GyBZWqm+XRievr50z8WGywnAS7zz7 /Qv5/R3s6R4DM3+ipOoCSLNfl2zzQbRMN0xBBBtjfY/24gpqK7C4SJ38yh9tk4ncQR98 lbBaUM1utTU4xKjbw3DLBpb8C1eR6VZdeRqQnJrsZ8OoFbFPPeaD1RGXBkxqSQGns6eZ wTqL1ejJMQykPqGlEq+YWT3khXWOQLOlfvetbH5nO0k+RHkiq3D6QVlLYlzf46KO3GFw K3Cw== Received: by 10.224.182.13 with SMTP id ca13mr1051157qab.60.1340303726573; Thu, 21 Jun 2012 11:35:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.87.142 with HTTP; Thu, 21 Jun 2012 11:34:56 -0700 (PDT) From: Brian Campbell Date: Thu, 21 Jun 2012 12:34:56 -0600 Message-ID: To: oauth Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlCHGxMJOMLpz2QZePLF/EJaZWX7XmUsVr2rTlbf/DIMP8q8KhjN0T5Vcfo8hlk7oF92ln6 Cc: Barry Leiba Subject: [OAUTH-WG] -03 IETF URN Sub-Namespace for OAuth 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: Thu, 21 Jun 2012 18:35:28 -0000 "An IETF URN Sub-Namespace for OAuth" draft -03 has been published and is available at http://tools.ietf.org/html/draft-ietf-oauth-urn-sub-ns-03 Changes (listed below as well as in the document history) from the previous version were made in response to AD review and the subsequent discussion prompted by that review. The intent of the document remains unchanged (to create and register an IETF URN Sub-namespace of urn:ietf:params:oauth and allow OAuth related specs to establish and use URIs underneath it) but the actual text in the doc has changed significantly. So additional review (particularly by those involved in the discussion yesterday) would be very much appreciated. draft-ietf-oauth-urn-sub-ns-03 changes: o Changes to address comments in the message "AD review of draft-ietf-oauth-urn-sub-ns-02" at http://www.ietf.org/mail-archive/web/oauth/current/msg09350.html and subsequent messages in that thread o Update area and workgroup (now Security and OAuth was Internet and nothing) o Change from informational to standards-track o Requesting new URNs now more lightweight by changing from 'RFC Required' to 'Expert Review' (RFC5226) o Rework much of the document to be more clear about it registering the urn:ietf:params:oauth URN sub-namespace and separately how other documents are to request URNs under that sub-namespace. o Removed everything about asking the IANA to generate any part of the URN. o Added an Example Registration Request o Added reference to OAuth security considerations in security considerations. o Added Acknowledgements Thanks, Brian From hannes.tschofenig@gmx.net Thu Jun 21 11:44:46 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 558A211E808D for ; Thu, 21 Jun 2012 11:44:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.48 X-Spam-Level: X-Spam-Status: No, score=-102.48 tagged_above=-999 required=5 tests=[AWL=0.119, 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 pAG-Ju5xdU9u for ; Thu, 21 Jun 2012 11:44:45 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 4C1DA11E808A for ; Thu, 21 Jun 2012 11:44:45 -0700 (PDT) Received: (qmail invoked by alias); 21 Jun 2012 18:44:43 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.101]) [88.115.216.191] by mail.gmx.net (mp038) with SMTP; 21 Jun 2012 20:44:43 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+E0AM4dhCEMLlDQ5ixC1sXwwJbQUXMAHGZgfGG0Z G9WxJtYapvt7Km Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: Date: Thu, 21 Jun 2012 21:44:40 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <5001A039-3459-45C3-B295-FAC0957CDE00@gmx.net> References: <4FE1C16D.6010602@cs.tcd.ie> <4FE1FD1E.1060601@cs.tcd.ie> To: Barry Leiba X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-urn-sub-ns-02 X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 18:44:46 -0000 Hi Barry,=20 let me describe what we are trying to do here: 1.) This document creates a new URN with urn:ietf:params:oauth.=20 There are procedures for creating new entries under urn:ietf:params, as = described in RFC 3553, and we have them in the document.=20 2.) We provide guidance on how others then define new sub-registries = under urn:ietf:params:oauth.=20 Class refers to concepts like 'grant-type'.=20 This document does not create these sub-registries. Instead, it only = provides guidance for doing that and leaves it to other documents, such = as to the bearer document.=20 [Note: We should have created these child registries in the document = ourselves as well.] Ciao Hannes On Jun 20, 2012, at 9:34 PM, Barry Leiba wrote: > I'd like to see the new version, since there appear to be a bunch of > changes, but first here are some issues that I don't think have been > brought up yet: >=20 > The URN registration stuff seems very incompletely baked. The title > of 5.1 correctly says it's registering a sub-namespace, but the text > incorrectly says that it's creating a registry. Perhaps IANA will > understand, but I think you need to do this in two parts. The first > part would register the "oauth" sub-namespace, and the second would > create a new registry for the things that go into it. >=20 > Now, as to what goes into it: What is "class"? Is there meant to be a > registry of classes? Is that what section 5.1 is trying to create > (which should be done in a new section 5.2)? What initial values are > registered there? >=20 > Barry > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From hannes.tschofenig@gmx.net Thu Jun 21 11:48:28 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DB0721F8718 for ; Thu, 21 Jun 2012 11:48:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.487 X-Spam-Level: X-Spam-Status: No, score=-102.487 tagged_above=-999 required=5 tests=[AWL=0.112, 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 XP30txHMW+VU for ; Thu, 21 Jun 2012 11:48:27 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 396BE21F8726 for ; Thu, 21 Jun 2012 11:48:26 -0700 (PDT) Received: (qmail invoked by alias); 21 Jun 2012 18:48:25 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.101]) [88.115.216.191] by mail.gmx.net (mp027) with SMTP; 21 Jun 2012 20:48:25 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+N2YdXbLWNnQvfSi/dodRCukxFJvhpHqmlmJ84b3 c+yXlwNLmgbbtn Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: Date: Thu, 21 Jun 2012 21:48:22 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <7B2933AE-CD33-4DF7-9C8A-2DE44D3E8F06@gmx.net> References: <4FE1C16D.6010602@cs.tcd.ie> To: Barry Leiba X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-urn-sub-ns-02 X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 18:48:28 -0000 Hi Barry,=20 On Jun 21, 2012, at 9:29 PM, Barry Leiba wrote: >>> (1) Why Informational? Everything else at that level seems to >>> be specified in a standards track or BCP level RFC, and IETF >>> Consensus is required. [1] I think you have to do this as >>> standards track. Did I miss something? >>>=20 >> Standards Track is OK. >=20 > Stephen: > Yeah, I'm not sure Standards Track is needed. Other than "Other > documents like it are Standards Track," explain why Informational > doesn't work. Is there some procedural reason that these IANA actions > can't be done with an Informational document? Is there any > expectation that this will be reviewed and modified and progress along > any sort of track at all? Certainly, this doesn't define any sort of > "standard" that I can see. >=20 > Informational documents in the IETF Stream *do* have "IETF Consensus". On our status call on Monday you explained me that both types of = documents have IETF last calls these days.=20 Hence, I wonder whether there is any practical difference?=20 >=20 >>> (2) Do you *really* want RFC or specification required for all >>> registrations? I don't care, but there is a trend away from >>> that at the moment since its been found to discourage >>> registrations in a lot of cases. Perhaps expert review would >>> be ok? No trying to push you one way or the other, I just >>> wanted to check. > ... >> If the goal is to get this document inline with what our existing = documents say >> then 'Specification Required' would be the right policy here as well. >=20 > Hannes: > I'm going to really push hard on this point: the goal is *NOT* to make > all the registration policies the same, and I will resist that > strongly. The *goal* is to use for each registry a registration > policy that makes sense for *that* registry. That means that you > (well, someone) need to tell me why *this* registry needs the > strictness that you pick for it. What will the harm be in leaving it > to Expert Review, and letting the designated expert decide how much > documentation to require? And remember, you can document guidelines > for the designated expert. For that matter, what will the *harm* be > in simply letting it be First Come First Served? >=20 > We have far too many too-strict registration policies in effect, and > they often come back and bite on the ass the very people who picked > the policies. I made a mistake here and responded too quickly. I will respond to that = issue in my mail to Mike since it very much relates to an issue he = raised.=20 >=20 >> So, I am curious where to hit the right level of process here to find = the sweetspot >> between low overhead and high quality specifications. >=20 > You also need to consider whether poorly documented and unused > extensions really cause any *harm*. If some bozo writes a bad spec > for a stupid idea, and no one implements it because the spec is bad > and the idea is stupid, so what? On the other hand, if some big > company decides it's too much trouble to follow IETF procedures and > chooses not to register their extension, but everyone winds up using > it because they're big and it's necessary, what was the point of > making the registration hard? >=20 > That's the real balance we have to look at. >=20 > Barry Ciao Hannes From bcampbell@pingidentity.com Thu Jun 21 11:50:24 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D92621F873C for ; Thu, 21 Jun 2012 11:50:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.891 X-Spam-Level: X-Spam-Status: No, score=-5.891 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 049QXMpfD-Cu for ; Thu, 21 Jun 2012 11:50:23 -0700 (PDT) Received: from na3sys009aog129.obsmtp.com (na3sys009aog129.obsmtp.com [74.125.149.142]) by ietfa.amsl.com (Postfix) with ESMTP id 54AC121F8726 for ; Thu, 21 Jun 2012 11:50:23 -0700 (PDT) Received: from mail-qc0-f180.google.com ([209.85.216.180]) (using TLSv1) by na3sys009aob129.postini.com ([74.125.148.12]) with SMTP ID DSNKT+Ns7QUaXG7YvbTYtmCnZUOhPZuHzbvG@postini.com; Thu, 21 Jun 2012 11:50:23 PDT Received: by qcmv28 with SMTP id v28so736826qcm.39 for ; Thu, 21 Jun 2012 11:50:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=i8FCCy26p2gHSZNVpoGBzZ1tMJke1fB7/yWTWORKWdg=; b=V5HIN0YTWnyDv++9okIBgnQM8pD9OeCYiIjNxr0BHosYfRfQusMJWAMTkHvATEq8Wa xxpUpfaeqA0GngWYzmVXoR0Ti0YW9wQkSZfu8y79Q7IN/7BnHqVeqQN3RxPuF/x7t4ng PiuR8ypiFk0uwWACwNzOLcPApjUKeV2uXrLFaWG7jqgViwSfi2KTqZM4fqZCjz6577uM bOwunVpdahESN7y9u4nP8GZ++2RjmPMBkOpDsh1PTRsW6wpFfCw/4WJSq3S3Xqu8JWDb N2kBCFvdvxYf5E9qUnKuKWpquhoJaxFqmbGuRBZ8x7ub3zX2ZB92yJ4U9DGX84JxApWe Aq/Q== Received: by 10.224.217.67 with SMTP id hl3mr1079537qab.75.1340304620595; Thu, 21 Jun 2012 11:50:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.87.142 with HTTP; Thu, 21 Jun 2012 11:49:50 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436656323F@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <20120621175317.32545.76545.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B16804296739436656323F@TK5EX14MBXC283.redmond.corp.microsoft.com> From: Brian Campbell Date: Thu, 21 Jun 2012 12:49:50 -0600 Message-ID: To: Mike Jones Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQk9GnRXA/Ftw6p7SfRqBy+gfpR+z/Ozvqx5K1TBpy7yoSikjKTUBqa5/olhQZI87WJj2m8v Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-urn-sub-ns-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2012 18:50:24 -0000 I was trying to write something useful for the "Index value" while still staying in-line with the previous revisions of doc as well as the URNs that we've used in the SAML and JWT profiles. But I agree that there's no need to unnecessarily restrict it to a two level structure. On Thu, Jun 21, 2012 at 12:14 PM, Mike Jones wrote: > This draft is much clearer. =A0Thanks for the quick turn-around. > > One question: =A0You added: > =A0*Index value: values subordinate to urn:ietf:params:oauth are of the f= rom urn:ietf:params:oauth:: with : as the index value > Why bake the assumption of a two-level structure into the registry? > > For instance, you could easily imagine legal and useful registrations of = the form ::, etc. > > Maybe change this to say: > =A0*Index value: values subordinate to urn:ietf:params:oauth are of the f= rom urn:ietf:params:oauth: with as the index value. =A0It is= suggested that include both a "class" and an "identifier-within-cl= ass" component, with the two components being separated by a colon (":"); o= ther compositions of the may also be used. > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-- Mike > > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of= internet-drafts@ietf.org > Sent: Thursday, June 21, 2012 10:53 AM > To: i-d-announce@ietf.org > Cc: oauth@ietf.org > Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-urn-sub-ns-03.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > =A0This draft is a work item of the Web Authorization Protocol Working Gr= oup of the IETF. > > =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : An IETF URN Sub-Namespace for = OAuth > =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Brian Campbell > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Hannes Tschofenig > =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-oauth-urn-sub-ns-03.t= xt > =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 7 > =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-06-21 > > Abstract: > =A0 This document establishes an IETF URN Sub-namespace for use with > =A0 OAuth related specifications. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-urn-sub-ns > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-oauth-urn-sub-ns-03 > > A diff from previous version is available at: > http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-urn-sub-ns-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 > > From bcampbell@pingidentity.com Thu Jun 21 12:04:53 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E7C111E808D for ; Thu, 21 Jun 2012 12:04:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.902 X-Spam-Level: X-Spam-Status: No, score=-5.902 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pvAB7VEMgCTt for ; Thu, 21 Jun 2012 12:04:52 -0700 (PDT) Received: from na3sys009aog120.obsmtp.com (na3sys009aog120.obsmtp.com [74.125.149.140]) by ietfa.amsl.com (Postfix) with ESMTP id 5D17021F8622 for ; Thu, 21 Jun 2012 12:04:52 -0700 (PDT) Received: from mail-qa0-f51.google.com ([209.85.216.51]) (using TLSv1) by na3sys009aob120.postini.com ([74.125.148.12]) with SMTP ID DSNKT+NwUyz+rSXY2r9Av97dBj4v8oxEchX7@postini.com; Thu, 21 Jun 2012 12:04:52 PDT Received: by qaea16 with SMTP id a16so1868535qae.3 for ; Thu, 21 Jun 2012 12:04:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=qYbqy0FvFgEeOHXX/+10jK3v2ohhA0isZpmCPk8wGbI=; b=iMovIB4nVLDrdXfC06LJl38d2Dl1OYS5xcmd/oQd1EwVjyUAfGJaevUihPj7smiqaJ FvlsGzv0DBFMkVoZnVeScKnkdmkMabeVw6JC9S/Dia8vIh3//bSqi7puyxSEhnBLVZTh ANPUBg5rhT1S3TiBboZUEPASuiqk9s/RTZWY8ly+pvC6HV61solhImGCUGe3L8D1z3rN YSnIYktQ5yRYYhTdmQZ9qrjmIa/haMaQ4g8zC9FOuRwciscyEdI70L/68ah5ApjSmzGc z+4KMJn3x5r3NiC+55DMu6TbSR2KBHEjMKqYn56tIN75AR5Q9NO+wzKrAC8H4fjJb9cm 7+Xg== Received: by 10.229.135.68 with SMTP id m4mr2593432qct.70.1340305490854; Thu, 21 Jun 2012 12:04:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.87.142 with HTTP; Thu, 21 Jun 2012 12:04:20 -0700 (PDT) In-Reply-To: References: <20120621175317.32545.76545.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B16804296739436656323F@TK5EX14MBXC283.redmond.corp.microsoft.com> From: Brian Campbell Date: Thu, 21 Jun 2012 13:04:20 -0600 Message-ID: To: Mike Jones Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQn/CsfpnIeypV47ZZLUguvHFpcwPV4VZXhS9ht6Lp6iMttxgAJbNxaM6Ggbt0nWp8PECYhh Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-urn-sub-ns-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2012 19:04:53 -0000 Assuming that change is made (and I think it should be), the text in the first paragraph of =A73 should be similarly reworked. http://tools.ietf.org/html/draft-ietf-oauth-urn-sub-ns-03#section-3 On Thu, Jun 21, 2012 at 12:49 PM, Brian Campbell wrote: > I was trying to write something useful for the "Index value" while > still staying in-line with the previous revisions of doc as well as the > URNs that we've used in the SAML and JWT profiles. =A0But I agree that > there's no need to unnecessarily restrict it to a two level structure. > > On Thu, Jun 21, 2012 at 12:14 PM, Mike Jones > wrote: >> This draft is much clearer. =A0Thanks for the quick turn-around. >> >> One question: =A0You added: >> =A0*Index value: values subordinate to urn:ietf:params:oauth are of the = from urn:ietf:params:oauth:: with : as the index valu= e >> Why bake the assumption of a two-level structure into the registry? >> >> For instance, you could easily imagine legal and useful registrations of= the form ::, etc. >> >> Maybe change this to say: >> =A0*Index value: values subordinate to urn:ietf:params:oauth are of the = from urn:ietf:params:oauth: with as the index value. =A0It i= s suggested that include both a "class" and an "identifier-within-c= lass" component, with the two components being separated by a colon (":"); = other compositions of the may also be used. >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-- Mike >> >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf O= f internet-drafts@ietf.org >> Sent: Thursday, June 21, 2012 10:53 AM >> To: i-d-announce@ietf.org >> Cc: oauth@ietf.org >> Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-urn-sub-ns-03.txt >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts direc= tories. >> =A0This draft is a work item of the Web Authorization Protocol Working G= roup of the IETF. >> >> =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : An IETF URN Sub-Namespace for= OAuth >> =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Brian Campbell >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Hannes Tschofenig >> =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-oauth-urn-sub-ns-03.= txt >> =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 7 >> =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-06-21 >> >> Abstract: >> =A0 This document establishes an IETF URN Sub-namespace for use with >> =A0 OAuth related specifications. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-oauth-urn-sub-ns >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-oauth-urn-sub-ns-03 >> >> A diff from previous version is available at: >> http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-urn-sub-ns-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 >> >> From Adam.Lewis@motorolasolutions.com Thu Jun 21 12:06:00 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6744111E80BC for ; Thu, 21 Jun 2012 12:06:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.166 X-Spam-Level: X-Spam-Status: No, score=-0.166 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=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 B+t95Vp0LpCd for ; Thu, 21 Jun 2012 12:05:59 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe001.messaging.microsoft.com [213.199.154.139]) by ietfa.amsl.com (Postfix) with ESMTP id 95E3E21F8622 for ; Thu, 21 Jun 2012 12:05:58 -0700 (PDT) Received: from mail120-db3-R.bigfish.com (10.3.81.237) by DB3EHSOBE003.bigfish.com (10.3.84.23) with Microsoft SMTP Server id 14.1.225.23; Thu, 21 Jun 2012 19:04:29 +0000 Received: from mail120-db3 (localhost [127.0.0.1]) by mail120-db3-R.bigfish.com (Postfix) with ESMTP id AECFF1004C5 for ; Thu, 21 Jun 2012 19:04:29 +0000 (UTC) X-Forefront-Antispam-Report: CIP:192.160.210.12; KIP:(null); UIP:(null); IPV:NLI; H:CT11GSG01.am.mot-solutions.com; RD:ct11gsg01.mot-solutions.com; EFVD:NLI X-SpamScore: 0 X-BigFish: VPS0(zzc85fhzz1202hzz8275bh8275dhz2fh2a8h683h839hd25hf0ah) Received-SPF: pass (mail120-db3: domain of motorolasolutions.com designates 192.160.210.12 as permitted sender) client-ip=192.160.210.12; envelope-from=Adam.Lewis@motorolasolutions.com; helo=CT11GSG01.am.mot-solutions.com ; olutions.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.234.85; KIP:(null); UIP:(null); (null); H:SN2PRD0410HT005.namprd04.prod.outlook.com; R:internal; EFV:INT Received: from mail120-db3 (localhost.localdomain [127.0.0.1]) by mail120-db3 (MessageSwitch) id 1340305467301618_8022; Thu, 21 Jun 2012 19:04:27 +0000 (UTC) Received: from DB3EHSMHS007.bigfish.com (unknown [10.3.81.233]) by mail120-db3.bigfish.com (Postfix) with ESMTP id 47B983A0259 for ; Thu, 21 Jun 2012 19:04:27 +0000 (UTC) Received: from CT11GSG01.am.mot-solutions.com (192.160.210.12) by DB3EHSMHS007.bigfish.com (10.3.87.107) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 21 Jun 2012 19:04:25 +0000 Received: from CT11GSG01.am.mot-solutions.com (ct11vts02.am.mot.com [10.177.16.160]) by CT11GSG01.am.mot-solutions.com (8.14.3/8.14.3) with ESMTP id q5LJ9IP7019211 for ; Thu, 21 Jun 2012 15:09:18 -0400 (EDT) Received: from CH1EHSOBE003.bigfish.com (ch1ehsobe005.messaging.microsoft.com [216.32.181.185]) by CT11GSG01.am.mot-solutions.com (8.14.3/8.14.3) with ESMTP id q5LJ9IcX019205 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 21 Jun 2012 15:09:18 -0400 (EDT) Received: from mail187-ch1-R.bigfish.com (10.43.68.235) by CH1EHSOBE003.bigfish.com (10.43.70.53) with Microsoft SMTP Server id 14.1.225.23; Thu, 21 Jun 2012 19:04:22 +0000 Received: from mail187-ch1 (localhost [127.0.0.1]) by mail187-ch1-R.bigfish.com (Postfix) with ESMTP id 09EB43C00B5 for ; Thu, 21 Jun 2012 19:04:22 +0000 (UTC) Received: from mail187-ch1 (localhost.localdomain [127.0.0.1]) by mail187-ch1 (MessageSwitch) id 1340305461379409_22093; Thu, 21 Jun 2012 19:04:21 +0000 (UTC) Received: from CH1EHSMHS004.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.246]) by mail187-ch1.bigfish.com (Postfix) with ESMTP id 5A7D6E0061; Thu, 21 Jun 2012 19:04:21 +0000 (UTC) Received: from SN2PRD0410HT005.namprd04.prod.outlook.com (157.56.234.85) by CH1EHSMHS004.bigfish.com (10.43.70.4) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 21 Jun 2012 19:04:20 +0000 Received: from SN2PRD0410MB370.namprd04.prod.outlook.com ([169.254.7.46]) by SN2PRD0410HT005.namprd04.prod.outlook.com ([10.255.115.40]) with mapi id 14.16.0164.004; Thu, 21 Jun 2012 19:05:47 +0000 From: Lewis Adam-CAL022 To: Nat Sakimura Thread-Topic: [OAUTH-WG] Report an authentication issue Thread-Index: AQHNT8xFtcJvIS3+iUqysAsMD9SHi5cFHAEA Date: Thu, 21 Jun 2012 19:05:46 +0000 Message-ID: <59E470B10C4630419ED717AC79FCF9A917054D88@SN2PRD0410MB370.namprd04.prod.outlook.com> References: <1339792496.52712.YahooMailNeo@web125501.mail.ne1.yahoo.com> <59E470B10C4630419ED717AC79FCF9A9108898EE@BL2PRD0410MB363.namprd04.prod.outlook.com> <4FE223E4.6060307@mitre.org> <4FE226BC.6010403@alcatel-lucent.com> <59E470B10C4630419ED717AC79FCF9A910889AB5@BL2PRD0410MB363.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A917052BC8@SN2PRD0410MB370.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.45.131] Content-Type: multipart/alternative; boundary="_000_59E470B10C4630419ED717AC79FCF9A917054D88SN2PRD0410MB370_" 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%ALCATEL-LUCENT.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] Report an authentication issue X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 19:06:00 -0000 --_000_59E470B10C4630419ED717AC79FCF9A917054D88SN2PRD0410MB370_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Nat ... It could also be that RS is the PDP+PEP. Your model seem to fit this one. Yes, exactly! Then, you just take id_token there and PDP portion of the RS gives you the = access token, which you present it to the PEP portion of the RS. if by "you" you're referring to the native client, the this is EXACTL= Y what I want to do. 1. User launches native client on iPhone 2. Native client (via UA) triggers Authorization Request (response_typ= e=3Did_token) to OpenID Connect provider. 3. OpenID Connect provider authenticates user 4. Id_token is returned to the native client via the UA in Response me= ssage 5. Native client includes id_token in RESTful API calls to the RS 6. RS uses subject of id_token to make authorization decision. It seems that every time I describe this, I get a mix of responses ranging = from "that's not the intended usage of the id_token" to "sounds like that s= hould work." This is giving me a great deal of pause. In this case, I think id_token should be audience restricted to the RS. absolutely! --_000_59E470B10C4630419ED717AC79FCF9A917054D88SN2PRD0410MB370_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Nat …

 =

It could also be that RS is the PDP+PEP. Your mo= del seem to fit this one.

 

<acl> Yes, exactly!<= /p>

 

Then, you just take id_token there and PDP portion o= f the RS gives you the access token, which you present it to the PEP portio= n of the RS.

 

<acl> if by “you” you̵= 7;re referring to the native client, the this is EXACTLY what I want to do.=  

 

1.    =   User launches native client on iPhon= e

2.    =   Native client (via UA) triggers Auth= orization Request (response_type=3Did_token) to OpenID Connect provider.

3.    =   OpenID Connect provider authenticate= s user

4.    =   Id_token is returned to the native c= lient via the UA in Response message

5.    =   Native client includes id_token in R= ESTful API calls to the RS

6.    =   RS uses subject of id_token to make = authorization decision.


It seems that every time I describe this, I get a mix of responses ranging = from “that’s not the intended usage of the id_token” to &= #8220;sounds like that should work.”  This is giving me a great = deal of pause. 

 

 

 

In this case, I think id_token should be audience re= stricted to the RS.

 

<acl> absolutely!

 

 

 

--_000_59E470B10C4630419ED717AC79FCF9A917054D88SN2PRD0410MB370_-- From hannes.tschofenig@gmx.net Thu Jun 21 12:12:36 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CCCF21F8799 for ; Thu, 21 Jun 2012 12:12:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.493 X-Spam-Level: X-Spam-Status: No, score=-102.493 tagged_above=-999 required=5 tests=[AWL=0.106, 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 YiEgv9HzKMcJ for ; Thu, 21 Jun 2012 12:12:35 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 06A4621F851C for ; Thu, 21 Jun 2012 12:12:34 -0700 (PDT) Received: (qmail invoked by alias); 21 Jun 2012 19:12:33 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.101]) [88.115.216.191] by mail.gmx.net (mp012) with SMTP; 21 Jun 2012 21:12:33 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/BvDZyNBXBZKOhQQ4CYxTw5dz38uc2qemJJtT6El Gm6IMefPkx2tcA Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436656323F@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Thu, 21 Jun 2012 22:12:31 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <0F4BC83D-9C3E-44CD-9D8C-5784A7495486@gmx.net> References: <20120621175317.32545.76545.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B16804296739436656323F@TK5EX14MBXC283.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-urn-sub-ns-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2012 19:12:36 -0000 Hi Mike,=20 Thanks for your mail.=20 First, I would like to argue for a registry that has more than one = level. We need a two level registry because the different extensions = have (and will also in the future) have different extension policies.=20 The structure of the registry is: urn:ietf:params:oauth:: On the first level, the part, we have high level functionality = that was defined in the core specification. This includes things like=20 1) authorization grants (which you call grant-type in your registration = request in http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-12)=20= So, this would be urn:ietf:params:oauth:grant-type 2) client authentication mechanism (which you call client-assertion-type = in http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-12 but = should rather mean something like client-auth-type)=20 So, this could be something like urn:ietf:params:oauth:client-auth-type 3) Access Token Types (which is called 'token-type' in = http://www.ietf.org/id/draft-ietf-oauth-json-web-token-00.txt) This is urn:ietf:params:oauth:token-type.=20 [PS: The text in the = http://tools.ietf.org/html/draft-ietf-oauth-v2-28#section-8.1 for = registering new access token types is a bit confusing and I am not sure = whether an absolute URI would actually be required even though it makes = a lot of sense.] While I believe that our initial requirement for "RFC required" for = adding these top level classes makes sense since these basic extension = features to OAuth are really core to the protocol functionality it is = good that the group checks them carefully.=20 Then, at the level the individual values reside. For the = authorization grant this is 'saml2-bearer' as defined in = http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-12#section-6.=20= So, what is the right policy for adding values under = urn:ietf:params:oauth:grant-type? = http://tools.ietf.org/html/draft-ietf-oauth-v2-28#section-8.3 says what = the policy is. So, instead of re-deciding a new policy for adding = entries here it would be good to get it inline with what the policy is = in the core spec.=20 What could go wrong if the two are not aligned? I actually had that case = in the DIME working group. Without going into the details the registry = had a much stronger policy (RFC required) than the protocol = specification (which only required a specification, if I remember it). = The consequence was that people couldn't easily register new values from = other organizations since they would fail in the last step when a new = registry value had to be created (since IANA then told them 'RFC = Required'). Consequently, these other organizations who wanted to get = their work done then avoided doing so by misusing other extensions, = which was really not good. =20 Mike, you have actually been suggesting that a three level category for = certain classes of sub-registries is actually OK as well. That may be = true and we could relax the text to say that whoever defines the class = also decides about the structure of the child elements underneath it. =20= What I believe we need to add in the document is to populate the = registry with the three URIs (from above; referring to the classes) and = pointing to the policy from the core specification. Then, other docs = (like draft-ietf-oauth-json-web-token-00.txt) can just put their values = in there.=20 Ciao Hannes On Jun 21, 2012, at 9:14 PM, Mike Jones wrote: > This draft is much clearer. Thanks for the quick turn-around. >=20 > One question: You added: > *Index value: values subordinate to urn:ietf:params:oauth are of the = from urn:ietf:params:oauth:: with : as the index = value > Why bake the assumption of a two-level structure into the registry? >=20 > For instance, you could easily imagine legal and useful registrations = of the form ::, etc. >=20 > Maybe change this to say: > *Index value: values subordinate to urn:ietf:params:oauth are of the = from urn:ietf:params:oauth: with as the index value. It = is suggested that include both a "class" and an = "identifier-within-class" component, with the two components being = separated by a colon (":"); other compositions of the may also = be used. >=20 > -- Mike >=20 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf = Of internet-drafts@ietf.org > Sent: Thursday, June 21, 2012 10:53 AM > To: i-d-announce@ietf.org > Cc: oauth@ietf.org > Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-urn-sub-ns-03.txt >=20 >=20 > 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 : An IETF URN Sub-Namespace for OAuth > Author(s) : Brian Campbell > Hannes Tschofenig > Filename : draft-ietf-oauth-urn-sub-ns-03.txt > Pages : 7 > Date : 2012-06-21 >=20 > Abstract: > This document establishes an IETF URN Sub-namespace for use with > OAuth related specifications. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-urn-sub-ns >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-oauth-urn-sub-ns-03 >=20 > A diff from previous version is available at: > http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-urn-sub-ns-03 >=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 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From stephen.farrell@cs.tcd.ie Thu Jun 21 12:27:06 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFF8621F8542 for ; Thu, 21 Jun 2012 12:27:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.751 X-Spam-Level: X-Spam-Status: No, score=-101.751 tagged_above=-999 required=5 tests=[AWL=-0.548, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JMXvrRpyQYAJ for ; Thu, 21 Jun 2012 12:27:06 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 8784721F85CE for ; Thu, 21 Jun 2012 12:27:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 26650171C1E; Thu, 21 Jun 2012 20:27:04 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h=date :subject:from:x-mailer:message-id:content-type :content-transfer-encoding:mime-version:in-reply-to:references :received:received:x-virus-scanned; s=cs; t=1340306823; bh=MLbeV oOdf1TUcrgq7WFhHX0Q3GCj7v+6qh6r+GQ5sHQ=; b=W0LF62jzvspXVgIpDbALG N4TMdRUTF6b1jMDfMzJGA6NKGgraiRchSAIYB2P6+MwFmCdK+aNJoZjCMzZwC2W/ RnpWTcEXBvel9Y+w9pwD4P5foBoioL4IYef6ctq88L9ibN6lgFddOBxXgp5Sq0ST CYcG5lOIIjq8ukhvSHR5lujQJKnybz5KuP+yG8vekCZug23C4CjiqjH2QadXEZ7Q YyO4itVfdoX+7itkT9Z7JfUQuI5wVArtxQI9P5T3TnLgzel1qeikXnO4BvTiiyu/ 9h/wAsf4zeUF5nx8Ps5EduBDnWWf1jEJbN1hXZL24JkNw6VmMA7zUxf3SW4pUHq8 g== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id DAKJBwkg7cPA; Thu, 21 Jun 2012 20:27:03 +0100 (IST) Received: from [10.87.48.9] (unknown [86.46.17.239]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 114D617147E; Thu, 21 Jun 2012 20:27:03 +0100 (IST) References: <4FE1C16D.6010602@cs.tcd.ie> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <4CD0B85C-C88D-4B52-81E4-5D53A25E60EF@cs.tcd.ie> X-Mailer: iPhone Mail (9B206) From: Stephen Farrell Date: Thu, 21 Jun 2012 20:27:02 +0100 To: Barry Leiba Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-urn-sub-ns-02 X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 19:27:07 -0000 On 21 Jun 2012, at 19:29, Barry Leiba wrote: >>> (1) Why Informational? Everything else at that level seems to >>> be specified in a standards track or BCP level RFC, and IETF >>> Consensus is required. [1] I think you have to do this as >>> standards track. Did I miss something? >>>=20 >> Standards Track is OK. >=20 > Stephen: > Yeah, I'm not sure Standards Track is needed. =20 On this bit: I personally don't care, except that we don't have to do it twi= ce because someone later on thinks the opposite and wins that argument, whic= h I'd rather not have at all (My one-track mind:-) Doing the 4 week last ca= ll means once is enough. But I'm ok with whatever the WG want. S > Other than "Other > documents like it are Standards Track," explain why Informational > doesn't work. Is there some procedural reason that these IANA actions > can't be done with an Informational document? Is there any > expectation that this will be reviewed and modified and progress along > any sort of track at all? Certainly, this doesn't define any sort of > "standard" that I can see. >=20 > Informational documents in the IETF Stream *do* have "IETF Consensus". >=20 >>> (2) Do you *really* want RFC or specification required for all >>> registrations? I don't care, but there is a trend away from >>> that at the moment since its been found to discourage >>> registrations in a lot of cases. Perhaps expert review would >>> be ok? No trying to push you one way or the other, I just >>> wanted to check. > ... >> If the goal is to get this document inline with what our existing documen= ts say >> then 'Specification Required' would be the right policy here as well. >=20 > Hannes: > I'm going to really push hard on this point: the goal is *NOT* to make > all the registration policies the same, and I will resist that > strongly. The *goal* is to use for each registry a registration > policy that makes sense for *that* registry. That means that you > (well, someone) need to tell me why *this* registry needs the > strictness that you pick for it. What will the harm be in leaving it > to Expert Review, and letting the designated expert decide how much > documentation to require? And remember, you can document guidelines > for the designated expert. For that matter, what will the *harm* be > in simply letting it be First Come First Served? >=20 > We have far too many too-strict registration policies in effect, and > they often come back and bite on the ass the very people who picked > the policies. >=20 >> So, I am curious where to hit the right level of process here to find the= sweetspot >> between low overhead and high quality specifications. >=20 > You also need to consider whether poorly documented and unused > extensions really cause any *harm*. If some bozo writes a bad spec > for a stupid idea, and no one implements it because the spec is bad > and the idea is stupid, so what? On the other hand, if some big > company decides it's too much trouble to follow IETF procedures and > chooses not to register their extension, but everyone winds up using > it because they're big and it's necessary, what was the point of > making the registration hard? >=20 > That's the real balance we have to look at. >=20 > Barry From barryleiba.mailing.lists@gmail.com Thu Jun 21 12:28:26 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44F1821F86DD for ; Thu, 21 Jun 2012 12:28:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.934 X-Spam-Level: X-Spam-Status: No, score=-102.934 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4So7QS9X1qe8 for ; Thu, 21 Jun 2012 12:28:25 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1E80221F86C3 for ; Thu, 21 Jun 2012 12:28:24 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so2805340lbb.31 for ; Thu, 21 Jun 2012 12:28:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=6kudO4jogEPZH7TDfxI/N20rKzLiPrlk+FxY3t6gooE=; b=BjbMI12aWAOwDtxLHaEWHJ1HK6Z8+eDx4N7H4pwqXKIdQsdzICj1iCkoIoaIDIvt8u 4U33ipT170bnG4Pp+G2A5SqQW71qPQmPe7yIPt4MSdj7/FdX3a7VoUNf6BZ9s7eD01V7 xygFJjpz3/ALKkYwAbixXGzfaAzjaOoVLDvRs5suCQ/fLn8+72FJM/q243P2Fy4sT7If gw/5Uv1d2Sq2FsS+utJ0Ubupy6HREMtvF950lenyGimVFLiwe7Fhuk5McKW7po/6Q6QT xypa0QvxP+UlQ3uUfGd2GDXlad8CK5UAQToIWEtl/I5iAPXB5BaMbWzWhx/4/VrWMeiC syIg== MIME-Version: 1.0 Received: by 10.112.83.169 with SMTP id r9mr274852lby.66.1340306904046; Thu, 21 Jun 2012 12:28:24 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.48.104 with HTTP; Thu, 21 Jun 2012 12:28:23 -0700 (PDT) In-Reply-To: <20120621175317.32545.76545.idtracker@ietfa.amsl.com> References: <20120621175317.32545.76545.idtracker@ietfa.amsl.com> Date: Thu, 21 Jun 2012 15:28:23 -0400 X-Google-Sender-Auth: wx7TYHGVED09rZtx6f8jgRcJW9A Message-ID: From: Barry Leiba To: OAuth WG Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-urn-sub-ns-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2012 19:28:26 -0000 This one's mostly there. As Mike and Hannes are discussing, the WG needs to sort out exactly what goes under "oauth" here. Here's a suggestion: Have Section 3 specify that what comes after "oauth" are one or more tokens, delimited by ":". Have Section 3 create the registry for the first-level token, "class". In your example, that's "grant-type". Have Section 3 specify that the definition of each "class" token specifies what comes after it -- how many tokens, and the meaning(s). Have Section 3 note that certain classes might create new sub-registries for what goes under them, if necessary. Have Section 3 note that certain classes might have *no* further tokens under them. I realize that there might not be any use cases envisioned right now for that last one, but it might be a bad idea to forbid it. Section 5: o Repository: [[not sure about this? this document or http://www.iana.org/assignments/oauth]] Yeh, I've never been sure about that either. I think what you want here is "[[The registry created in Section 3.]]". See RFC 6134 for how I did this with the "sieve" namespace. Barry From barryleiba.mailing.lists@gmail.com Thu Jun 21 12:31:12 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C85ED11E80C1 for ; Thu, 21 Jun 2012 12:31:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.935 X-Spam-Level: X-Spam-Status: No, score=-102.935 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zNxVFqaQb9aR for ; Thu, 21 Jun 2012 12:31:11 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id A821111E80BC for ; Thu, 21 Jun 2012 12:31:07 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so2809089lbb.31 for ; Thu, 21 Jun 2012 12:31:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=0dZHNRnDwlLdzm3nq1Z/fxF6NRRTFavkJgiyu+mjrsM=; b=mb9Md7TvbdDrmAfyrFHW1QNBkkMxXZsG6tDPApVQXyCnCYDMuWtle8NlGlNj4qkgXW CLoM/Bs1VGd4fXo+jHVKGIKLzE/PGZUUtZaQ1pmzd8utFA+PaNGoyHc/36nYnY/K5jqF 0YfKRdnBcOH9qCq7xCf33Q0TOle58oIcbbxRbo54+TsGM1bpHamR7fBCFMHl6FEmEKMe 6d6jfOl6RkVLd/cbWaKBAtPbVFqXmIEqw37IUbaDWUssSi/gw4UiGOKlZIyI+lj8kA/j DuKfB0Tixm2VAeRcsF/ES+JgkB1PDrjBlLZnRX0B+6fnEGBeYfGUtZrhJ/dPjuISmME4 yL8g== MIME-Version: 1.0 Received: by 10.152.103.11 with SMTP id fs11mr27496962lab.23.1340307066570; Thu, 21 Jun 2012 12:31:06 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.48.104 with HTTP; Thu, 21 Jun 2012 12:31:06 -0700 (PDT) In-Reply-To: <4CD0B85C-C88D-4B52-81E4-5D53A25E60EF@cs.tcd.ie> References: <4FE1C16D.6010602@cs.tcd.ie> <4CD0B85C-C88D-4B52-81E4-5D53A25E60EF@cs.tcd.ie> Date: Thu, 21 Jun 2012 15:31:06 -0400 X-Google-Sender-Auth: lueS0gwWR5sDKiyMNLykjqElxiA Message-ID: From: Barry Leiba To: Stephen Farrell Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-urn-sub-ns-02 X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 19:31:12 -0000 >> Stephen: >> Yeah, I'm not sure Standards Track is needed. > > On this bit: I personally don't care, except that we don't have to do it = twice > because someone later on thinks the opposite and wins that argument, whic= h > I'd rather not have at all =A0(My one-track mind:-) Doing the 4 week last= call means > once is enough. But I'm ok with whatever the WG want. Well, it's not a 4-week LC, but a 2-week one. Anyway, yes, I see your point, and I've done that with other documents. Better to make it Standards Track for now, note in the shepherd writeup that Informational is probably OK, and let the IESG decide. b From leleuj@gmail.com Thu Jun 21 12:40:58 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49C8611E80C5 for ; Thu, 21 Jun 2012 12:40:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15lyeBdjknpM for ; Thu, 21 Jun 2012 12:40:57 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3852711E808E for ; Thu, 21 Jun 2012 12:40:57 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so2821003lbb.31 for ; Thu, 21 Jun 2012 12:40:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=BgFMqggjrTe3jmhswtCKNTsf2ECyK66CabnTUM+/Djo=; b=kldejn+2YtcYBeMrvd8xEDLh5JY4JHcsDWe65FH3EBmCaq72OYts0pntIhPuKyDDwp WvB+rZ5JPO6K4VFXoCJU/c8Zfba/qP4lRp1Owp7QvtlY+SW8yhqLbQG/lX17G8ISlp6/ c4UmfPuKprOVtuDdJ9RWrU/JqX0gMBp+oYd86cQg2hxjjevZbLEGZKNjRb6ddM/05YbM 6YVEiLG/lVGwa/GD+7DzcQxuDTRlisb4/IsMOP2qErl4M6TxcbMUX8/RlEsQYV22C/gg vYEZ9mVRGdAgRGeisj1biOIfRPCam78sqTjRN0495Ighwc+lBhkdpydlbamVplcjb579 +18Q== MIME-Version: 1.0 Received: by 10.152.46.6 with SMTP id r6mr27933720lam.7.1340307656202; Thu, 21 Jun 2012 12:40:56 -0700 (PDT) Received: by 10.112.106.166 with HTTP; Thu, 21 Jun 2012 12:40:56 -0700 (PDT) Date: Thu, 21 Jun 2012 21:40:56 +0200 Message-ID: From: =?ISO-8859-1?B?Suly9G1lIExFTEVV?= To: oauth@ietf.org Content-Type: multipart/alternative; boundary=bcaec550ace6bcd88b04c300b103 Subject: [OAUTH-WG] Authorization request errors X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 19:40:58 -0000 --bcaec550ace6bcd88b04c300b103 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, I'm trying to implement OAuth 2.0 provider support and, in particular, right handling of errors. Following OAuth 2.0 spec : http://tools.ietf.org/html/draft-ietf-oauth-v2-2= 8, I don't understand the authorization request errors : part 4.1.2.1. If I have a valid redirection url, I understand that an error should be returned with GET parameters (error, error_description...) in the redirected url as shown in example. But in case of invalid redirection url or unknown client_id (which makes validation of redirection url impossible), what http code should I return ? 500 ? 400 ? What should be the format of the error message ? Json ? plaintext ? like a POST body ? I'm certainly misunderstanding OAuth spec, but I would appreciate any help. Thanks. Best regards, J=E9r=F4me --bcaec550ace6bcd88b04c300b103 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

I'm trying to implement OAuth 2.0 provider suppo= rt and, in particular, right handling of errors.

F= ollowing OAuth 2.0 spec :=A0http://tools.ietf.org/html/draft-ietf-oauth-v2-28, I don= 't understand the authorization request errors : part 4.1.2.1.
If I have a valid redirection url, I understand that an error should b= e returned with GET parameters (error, error_description...) in the redirec= ted url as shown in example.
But in case of invalid redirection u= rl or unknown client_id (which makes validation of redirection url impossib= le), what http code should I return ? 500 ? 400 ? What should be the format= of the error message ? Json ? plaintext ? like a POST body ?

I'm certainly misunderstanding OAuth spec, but I wo= uld appreciate any help.
Thanks.
Best regards,
J=E9r=F4me

--bcaec550ace6bcd88b04c300b103-- From hannes.tschofenig@gmx.net Thu Jun 21 12:48:10 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94E2121F85FC for ; Thu, 21 Jun 2012 12:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I+XiZSIrwsdS for ; Thu, 21 Jun 2012 12:48:09 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 1E87121F85D4 for ; Thu, 21 Jun 2012 12:48:08 -0700 (PDT) Received: (qmail invoked by alias); 21 Jun 2012 19:48:07 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.101]) [88.115.216.191] by mail.gmx.net (mp040) with SMTP; 21 Jun 2012 21:48:07 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/kiFQjAiLkfPd4MvPJ4V9ZS0Cypm1eywnERAq1IE /Yd168PDQ4vFQy Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <0F4BC83D-9C3E-44CD-9D8C-5784A7495486@gmx.net> Date: Thu, 21 Jun 2012 22:48:05 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120621175317.32545.76545.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B16804296739436656323F@TK5EX14MBXC283.redmond.corp.microsoft.com> <0F4BC83D-9C3E-44CD-9D8C-5784A7495486@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-urn-sub-ns-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2012 19:48:10 -0000 Btw, in a discussion with Brian we check the policies for the three = extensions in the OAuth core specification 1) Section 8.3. Defining New Authorization Grant Types If you don't define additional token endpoint parameters then there is = actually no requirement for expert review or a specification.=20 It is probably FCFS.=20 2) Section 8.1. Defining Access Token Types For URIs there seems to be no constraint either although the text talks = about limited to vendor-specific implementations.=20 3) client_assertion_type is created in = http://tools.ietf.org/html/draft-ietf-oauth-assertions-03#section-8.3=20 There is no description either for what is required to register a new = assertion type into the URN class client_assertion_type.=20 (For client authentication mechanisms there is actually no registry in = core and therefore there is no policy either.) Ciao Hannes On Jun 21, 2012, at 10:12 PM, Hannes Tschofenig wrote: > Hi Mike,=20 >=20 > Thanks for your mail.=20 >=20 > First, I would like to argue for a registry that has more than one = level. We need a two level registry because the different extensions = have (and will also in the future) have different extension policies.=20 >=20 > The structure of the registry is: urn:ietf:params:oauth:: >=20 > On the first level, the part, we have high level functionality = that was defined in the core specification. This includes things like=20 >=20 > 1) authorization grants (which you call grant-type in your = registration request in = http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-12)=20 >=20 > So, this would be urn:ietf:params:oauth:grant-type >=20 > 2) client authentication mechanism (which you call = client-assertion-type in = http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-12 but should = rather mean something like client-auth-type)=20 >=20 > So, this could be something like = urn:ietf:params:oauth:client-auth-type >=20 > 3) Access Token Types (which is called 'token-type' in = http://www.ietf.org/id/draft-ietf-oauth-json-web-token-00.txt) >=20 > This is urn:ietf:params:oauth:token-type.=20 >=20 > [PS: The text in the = http://tools.ietf.org/html/draft-ietf-oauth-v2-28#section-8.1 for = registering new access token types is a bit confusing and I am not sure = whether an absolute URI would actually be required even though it makes = a lot of sense.] >=20 > While I believe that our initial requirement for "RFC required" for = adding these top level classes makes sense since these basic extension = features to OAuth are really core to the protocol functionality it is = good that the group checks them carefully.=20 >=20 > Then, at the level the individual values reside. For the = authorization grant this is 'saml2-bearer' as defined in = http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-12#section-6.=20= >=20 > So, what is the right policy for adding values under = urn:ietf:params:oauth:grant-type? = http://tools.ietf.org/html/draft-ietf-oauth-v2-28#section-8.3 says what = the policy is. So, instead of re-deciding a new policy for adding = entries here it would be good to get it inline with what the policy is = in the core spec.=20 >=20 > What could go wrong if the two are not aligned? I actually had that = case in the DIME working group. Without going into the details the = registry had a much stronger policy (RFC required) than the protocol = specification (which only required a specification, if I remember it). = The consequence was that people couldn't easily register new values from = other organizations since they would fail in the last step when a new = registry value had to be created (since IANA then told them 'RFC = Required'). Consequently, these other organizations who wanted to get = their work done then avoided doing so by misusing other extensions, = which was really not good. =20 >=20 > Mike, you have actually been suggesting that a three level category = for certain classes of sub-registries is actually OK as well. That may = be true and we could relax the text to say that whoever defines the = class also decides about the structure of the child elements underneath = it. =20 >=20 > What I believe we need to add in the document is to populate the = registry with the three URIs (from above; referring to the classes) and = pointing to the policy from the core specification. Then, other docs = (like draft-ietf-oauth-json-web-token-00.txt) can just put their values = in there.=20 >=20 > Ciao > Hannes >=20 >=20 > On Jun 21, 2012, at 9:14 PM, Mike Jones wrote: >=20 >> This draft is much clearer. Thanks for the quick turn-around. >>=20 >> One question: You added: >> *Index value: values subordinate to urn:ietf:params:oauth are of the = from urn:ietf:params:oauth:: with : as the index = value >> Why bake the assumption of a two-level structure into the registry? >>=20 >> For instance, you could easily imagine legal and useful registrations = of the form ::, etc. >>=20 >> Maybe change this to say: >> *Index value: values subordinate to urn:ietf:params:oauth are of the = from urn:ietf:params:oauth: with as the index value. It = is suggested that include both a "class" and an = "identifier-within-class" component, with the two components being = separated by a colon (":"); other compositions of the may also = be used. >>=20 >> -- Mike >>=20 >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf Of internet-drafts@ietf.org >> Sent: Thursday, June 21, 2012 10:53 AM >> To: i-d-announce@ietf.org >> Cc: oauth@ietf.org >> Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-urn-sub-ns-03.txt >>=20 >>=20 >> 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 : An IETF URN Sub-Namespace for OAuth >> Author(s) : Brian Campbell >> Hannes Tschofenig >> Filename : draft-ietf-oauth-urn-sub-ns-03.txt >> Pages : 7 >> Date : 2012-06-21 >>=20 >> Abstract: >> This document establishes an IETF URN Sub-namespace for use with >> OAuth related specifications. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-oauth-urn-sub-ns >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-oauth-urn-sub-ns-03 >>=20 >> A diff from previous version is available at: >> http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-urn-sub-ns-03 >>=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 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 From Michael.Jones@microsoft.com Thu Jun 21 12:49:25 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A404321F85FC for ; Thu, 21 Jun 2012 12:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.098 X-Spam-Level: X-Spam-Status: No, score=-4.098 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XGMm1WTPNd7V for ; Thu, 21 Jun 2012 12:49:24 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe002.messaging.microsoft.com [213.199.154.140]) by ietfa.amsl.com (Postfix) with ESMTP id 4843B21F85D4 for ; Thu, 21 Jun 2012 12:49:23 -0700 (PDT) Received: from mail122-db3-R.bigfish.com (10.3.81.251) by DB3EHSOBE001.bigfish.com (10.3.84.21) with Microsoft SMTP Server id 14.1.225.23; Thu, 21 Jun 2012 19:47:55 +0000 Received: from mail122-db3 (localhost [127.0.0.1]) by mail122-db3-R.bigfish.com (Postfix) with ESMTP id ED4574C009C; Thu, 21 Jun 2012 19:47:54 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: VS-24(zzbb2dI9371I146fIc85dh1432Izz1202hzz1033IL8275dhz2fh2a8h668h839hd25hf0ah) Received-SPF: pass (mail122-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail122-db3 (localhost.localdomain [127.0.0.1]) by mail122-db3 (MessageSwitch) id 1340308073342089_31008; Thu, 21 Jun 2012 19:47:53 +0000 (UTC) Received: from DB3EHSMHS001.bigfish.com (unknown [10.3.81.234]) by mail122-db3.bigfish.com (Postfix) with ESMTP id 51B1F1C004A; Thu, 21 Jun 2012 19:47:53 +0000 (UTC) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS001.bigfish.com (10.3.87.101) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 21 Jun 2012 19:47:48 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.53]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.02.0298.005; Thu, 21 Jun 2012 19:49:13 +0000 From: Mike Jones To: Barry Leiba , Stephen Farrell Thread-Topic: [OAUTH-WG] AD review of draft-ietf-oauth-urn-sub-ns-02 Thread-Index: AQHNTt/sWKdca/SRw0Gp10lpJtZuBZcFFX4AgAAEYoCAABAKAIAAASMAgAAFEZs= Date: Thu, 21 Jun 2012 19:49:12 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436656365A@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <4FE1C16D.6010602@cs.tcd.ie> <4CD0B85C-C88D-4B52-81E4-5D53A25E60EF@cs.tcd.ie>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436656365ATK5EX14MBXC283r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-urn-sub-ns-02 X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 19:49:25 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436656365ATK5EX14MBXC283r_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I'd argue that the registration regime chosen should be flexible enough to = permit OASIS or OpenID specs to use it. Otherwise, as someone else pointed,= people will work around the limitation by using unregistered values - whic= h helps no one. -- Mike ________________________________ From: Barry Leiba Sent: 6/21/2012 12:31 PM To: Stephen Farrell Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-urn-sub-ns-02 >> Stephen: >> Yeah, I'm not sure Standards Track is needed. > > On this bit: I personally don't care, except that we don't have to do it = twice > because someone later on thinks the opposite and wins that argument, whic= h > I'd rather not have at all (My one-track mind:-) Doing the 4 week last c= all means > once is enough. But I'm ok with whatever the WG want. Well, it's not a 4-week LC, but a 2-week one. Anyway, yes, I see your point, and I've done that with other documents. Better to make it Standards Track for now, note in the shepherd writeup that Informational is probably OK, and let the IESG decide. b _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_4E1F6AAD24975D4BA5B16804296739436656365ATK5EX14MBXC283r_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I'd argue tha= t the registration regime chosen should be flexible enough to permit OASIS = or OpenID specs to use it. Otherwise, as someone else pointed, people will = work around the limitation by using unregistered values - which helps no one.

-- Mike

From: Barry = Leiba
Sent: 6/21/2= 012 12:31 PM
To: Stephe= n Farrell
Cc: oauth@= ietf.org
Subject: Re: [O= AUTH-WG] AD review of draft-ietf-oauth-urn-sub-ns-02

>> Stephen:
>> Yeah, I'm not sure Standards Track is needed.
>
> On this bit: I personally don't care, except that we don't have to do = it twice
> because someone later on thinks the opposite and wins that argument, w= hich
> I'd rather not have at all  (My one-track mind:-) Doing the 4 wee= k last call means
> once is enough. But I'm ok with whatever the WG want.

Well, it's not a 4-week LC, but a 2-week one.  Anyway, yes, I see your=
point, and I've done that with other documents.  Better to make it
Standards Track for now, note in the shepherd writeup that
Informational is probably OK, and let the IESG decide.

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

 --_000_4E1F6AAD24975D4BA5B16804296739436656365ATK5EX14MBXC283r_-- From bcampbell@pingidentity.com Thu Jun 21 12:55:46 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F1CA21F85FC for ; Thu, 21 Jun 2012 12:55:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.91 X-Spam-Level: X-Spam-Status: No, score=-5.91 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O1+0I-d3LnBV for ; Thu, 21 Jun 2012 12:55:44 -0700 (PDT) Received: from na3sys009aog122.obsmtp.com (na3sys009aog122.obsmtp.com [74.125.149.147]) by ietfa.amsl.com (Postfix) with ESMTP id 91E3121F85D4 for ; Thu, 21 Jun 2012 12:55:44 -0700 (PDT) Received: from mail-qa0-f49.google.com ([209.85.216.49]) (using TLSv1) by na3sys009aob122.postini.com ([74.125.148.12]) with SMTP ID DSNKT+N8QISt5TnWJAamsuonfeZdlPO1Kvth@postini.com; Thu, 21 Jun 2012 12:55:44 PDT Received: by qabj40 with SMTP id j40so1800327qab.15 for ; Thu, 21 Jun 2012 12:55:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=zcbJKPBu/VHf6ZFoE77ANv30ielQN2TMWt1MNX5ayAM=; b=B3qujLN10uqVxSVvCxmje7P5rYBsgkVhrjJis4HlO1af5ciZj3++wfDDfABIwBqrnD ZXanjELGksQYmDcenL9ljbOFJQtTBnYpEFhJtsBv0K/J5C3PTxMMNOfKM8tgxR2Kcc25 +WYU7Zfr8gKEf5k+QnbTZqSDKuJzy7sLEKL/B7JkZhnIFKUBE0vWZYBISWDl0TyxrOlD QGo0nrmq+b3lRbjTJ/cRNywqcIeLyGOTXacWqkn1Oz/MAZSmKmUjwCQc8nvoHbnTreEv Sqf+LYLvLT59qSrJmiH/+hhg9SLfLKi8TaT8rWHCjX+JK4l5UGq0Otr+0owCby0AcrSG v1gw== Received: by 10.224.201.136 with SMTP id fa8mr1712834qab.20.1340308543373; Thu, 21 Jun 2012 12:55:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.87.142 with HTTP; Thu, 21 Jun 2012 12:55:13 -0700 (PDT) In-Reply-To: References: <20120621175317.32545.76545.idtracker@ietfa.amsl.com> From: Brian Campbell Date: Thu, 21 Jun 2012 13:55:13 -0600 Message-ID: To: Barry Leiba Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkLEqUJq4bnLUCp7IXys8fA+K6L+Rsj+c3AhsjzjbiZ28gBJTZ4xJKbPrxouJYPITCcldBR Cc: OAuth WG Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-urn-sub-ns-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2012 19:55:46 -0000 I honestly don't understand the push to have additional registries under urn:ietf:params:oauth? On Thu, Jun 21, 2012 at 1:28 PM, Barry Leiba wrot= e: > This one's mostly there. =A0As Mike and Hannes are discussing, the WG > needs to sort out exactly what goes under "oauth" here. > > Here's a suggestion: > Have Section 3 specify that what comes after "oauth" are one or more > tokens, delimited by ":". > Have Section 3 create the registry for the first-level token, "class". > =A0In your example, that's "grant-type". > Have Section 3 specify that the definition of each "class" token > specifies what comes after it -- how many tokens, and the meaning(s). > Have Section 3 note that certain classes might create new > sub-registries for what goes under them, if necessary. > Have Section 3 note that certain classes might have *no* further > tokens under them. > > I realize that there might not be any use cases envisioned right now > for that last one, but it might be a bad idea to forbid it. > > Section 5: > > =A0 o =A0Repository: [[not sure about this? this document or > =A0 =A0 =A0http://www.iana.org/assignments/oauth]] > > Yeh, I've never been sure about that either. =A0I think what you want > here is "[[The registry created in Section 3.]]". > See RFC 6134 for how I did this with the "sieve" namespace. > > Barry > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From paul.madsen@gmail.com Thu Jun 21 13:00:09 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0DE521F86FC for ; Thu, 21 Jun 2012 13:00:09 -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 4NgWl29j6N1V for ; Thu, 21 Jun 2012 13:00:01 -0700 (PDT) Received: from mail-yw0-f53.google.com (mail-yw0-f53.google.com [209.85.213.53]) by ietfa.amsl.com (Postfix) with ESMTP id 1508F21F862F for ; Thu, 21 Jun 2012 12:59:57 -0700 (PDT) Received: by yhp26 with SMTP id 26so1471742yhp.26 for ; Thu, 21 Jun 2012 12:59:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=fvwSILADEGI35hhbaQGQcyrs5ZMu21c8BJJmJ8kEXx8=; b=0Q0PngTtxeeI/IuhJGjIH71IElfnEwLEIrjTyCqeiODBVi0uyUk7vIdYGFG5MaesY7 w1Jhfaf7xWRiKz9rRCdTvIW8j/QUZ/VHHlS7taRJWCMrS5Ge7jXh75cscZCYXVFJqx+7 gnaWKiULM3L5wfHMW7RvGhD36fzn3GbaISNT7Uk/bt9xgqtgzfYBqlVUH8QZsFNpKBwG /nDUrcAPLOBPDaloRgQ/JG32yE5RWankuVtNlk9dBtxgPSZG345UhXyc3ogRtvEvCd39 tc/nidCB2/pKpQy8gchDE8YdTWvcCJEs1HAbcG3S2YnxS66ePWA4Ixf/cCdZg3GU7IUW kqwg== Received: by 10.50.203.98 with SMTP id kp2mr8811969igc.42.1340308796236; Thu, 21 Jun 2012 12:59:56 -0700 (PDT) Received: from pmadsen-mbp.local (CPE0022b0cb82b4-CM0012256eb4b4.cpe.net.cable.rogers.com. [99.224.20.155]) by mx.google.com with ESMTPS id yg6sm1279971igb.6.2012.06.21.12.59.53 (version=SSLv3 cipher=OTHER); Thu, 21 Jun 2012 12:59:55 -0700 (PDT) Message-ID: <4FE37D38.1030407@gmail.com> Date: Thu, 21 Jun 2012 15:59:52 -0400 From: Paul Madsen User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.28) Gecko/20120306 Thunderbird/3.1.20 MIME-Version: 1.0 To: Lewis Adam-CAL022 References: <1339792496.52712.YahooMailNeo@web125501.mail.ne1.yahoo.com> <59E470B10C4630419ED717AC79FCF9A9108898EE@BL2PRD0410MB363.namprd04.prod.outlook.com> <4FE223E4.6060307@mitre.org> <4FE226BC.6010403@alcatel-lucent.com> <59E470B10C4630419ED717AC79FCF9A910889AB5@BL2PRD0410MB363.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A917052BC8@SN2PRD0410MB370.namprd04.prod.outlook.com> In-Reply-To: <59E470B10C4630419ED717AC79FCF9A917052BC8@SN2PRD0410MB370.namprd04.prod.outlook.com> Content-Type: multipart/alternative; boundary="------------010801020709000701020008" Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Report an authentication issue X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 20:00:09 -0000 This is a multi-part message in MIME format. --------------010801020709000701020008 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Lewis, I think you are perhaps conflating the token model (whether it has inherent structure or is merely a pointer to user info) and who the RO owner is - user or enterprise. Nothing prevents you today from using OAuth as is to issue a token to the officer on the tablet, having the app use that token on API calls, and the API making an authz decision based solely on enterprise policy, with no consent figuring in. Neither do you need a structured token (like id_token). The token issued can merely be a pointer/artifact to the officer's actual roles, these obtained by the API/RS by sending the tokens for 'validation' or 'introspection' This doesnt sound like a Connect Use Case to me - rather a pretty standard OAuth use case - albeit with no need to get user's consent (so actually simpler). paul On 6/21/12 12:01 PM, Lewis Adam-CAL022 wrote: > > Hi Nat, > > I'm beginning to wonder what it would take to add a new profile of > sorts to either OAuth or Connect. > > In the beginning there was SOAP, and the preferred method to secure > SOAP API calls was WS-Trust. > > Now the world is moving toward RESTful APIs ... and the preferred > means to secure RESTful APIs is OAuth. > > Except that OAuth is clearly written with the idea that the protected > resources belong to the end user. > > My use cases -- and I imagine the use cases of many other enterprises > -- is that the Owner of the resources is the Enterprise. An employee > is trying to access a database or video resources. The enterprise RS > needs to be able to 1) identify the user, and 2) make authorization > decisions based on what roles that user has within the enterprise. So > in my scenario, when a police officer attempts to access a criminal > records database, the database needs to know who that officer is, and > then decide if they have privilege to access the database, and at what > level (e.g. CRUD). > > WS-Trust fits this model well. The user performs primary > authentication to the enterprise STS, which then grants the > application client a SAML assertion. When the user attempts to access > a records database, the SAML assertion is included in the SOAP > message. The records server authenticates the user based on the SAML > assertion and makes its authorization decisions. > > This is the world I'm trying to migrate from, and it really seems like > I'm sometimes trying to make a square peg fit in a round hole. I'm > looking for OAuth/Connect to do for REST what WS-TRUST did for SOAP. > I would like a native client talking to a RS to be able to ask for an > id_token, and then pass that id_token to the RS when making its > RESTful API calls, to enable the RS to authenticate the user. I think > that this would be really useful for a lot of people besides me. I > keep hearing that there is nothing "preventing" me from doing this ... > but it hardly seems within the spirit of what OAuth was meant to do. > The id_token was clearly meant to enable a user to authenticate to a > confidential client / web server ... but was not meant for a native > client to identity / authenticate the user to a RS. > > Would there be any interest in exploring this further? > > -adam > > *From:*Nat Sakimura [mailto:sakimura@gmail.com] > *Sent:* Wednesday, June 20, 2012 8:09 PM > *To:* Lewis Adam-CAL022 > *Cc:* igor.faynberg@alcatel-lucent.com; oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Report an authentication issue > > Yes, OAuth can be profiled to enable authentication. > > In fact, initial draft of OpenID Connect was just like you described. > > Essentially, we were using structured access_token. > > Later, we decided to separate the access token and id_token for > several reasons such as: > > 1. Better interop with existing OAuth implementations: by > introducing id_token, they do not need to touch the supposedly > opaque (which means AS-RS may be doing some proprietary thing > inside it) access token. > 2. Mixing up the audience (for id_token aka authn = client, and for > access_token aka authz = resource server) probably is expanding > the attack surface for security and privacy. > > Although we separated them out, a signed id_token includes the left > hash of access_token so access_token is also protected. > > Best, > > Nat > > On Thu, Jun 21, 2012 at 5:21 AM, Lewis Adam-CAL022 > > wrote: > > Hi Igor, > > As Justin just pointed out, consider the case where the video server > is hosted by the state (e.g. California) and is accessed by police > agencies in Los Angeles, San Francisco, and San Diego. The State of > California's video server is the RS. Each local police agency > (LA/SF/SD) hosts an AS. So when a police officer from LAPD launches > the video client app on the iPhone, the client makes an OAuth request > to the LAPD's AS, which authenticates the police officer using agency > level credentials. The access token issued to the video client app on > the iPhone is a JWT, signed by the agency AS, which might look > something like this: > > {"typ":"JWT","alg":"ES256"} > > {"iss":"https://as.lapd.california.gov", > "prn":"alice@lapd.california.gov ", > "aud":" https://video_server1@state.california.gov", > "iat":1300815780, > "exp":1300819380, > "acr":"password"} > > hq4zk+ZknjggCQgZm7ea8fI79gJEsRy3E8LHDpYXWQIgZpkJN9CMLG8ENR4Nrw+n7iyzixBvKXX8P53BTCT4VghPBWhFYSt9tHWu/AtJfOTh6qaAsNdeCyG86jmtp3TDMwuL/cBUj2OtBZOQMFn7jQ9YB7klIz3RqVL+wNmeWI4= > > The JWT might be optionally encrypted using JWE. > > I think what is becoming clear (and this is what I'm trying to vet) is > that while there is nothing in OAuth that specifies authentication, it > **can** be used for Authentication, if done in the way that I > describe. If I'm wrong about this, I really need to know. I've > vetted this idea of mine with quite of few people now -- both within > context of the list and off-line -- and I think I'm okay. If you see > any holes in what I describe, please point them out as I would prefer > to uncover them now rather than after implementation or deployment! > > Essentially I'm using OAuth as a RESTful version of WS-Trust, where my > client can exchange primary credentials for a token (JWT) and present > that token to a server as secondary authentication. It's just that > it's RESTful instead of SOAP :-) > > As Justin as pointed out ... I've basically made the access-token look > like the id_token of Connect. I was actually hoping to lay a path to > Connect, and use the id_token ... until it was also pointed out that > the id_token is really meant for the consumption of the client, not > the RS :-( > > *From:*oauth-bounces@ietf.org > [mailto:oauth-bounces@ietf.org ] *On > Behalf Of *Igor Faynberg > *Sent:* Wednesday, June 20, 2012 2:39 PM > *To:* oauth@ietf.org > > > *Subject:* Re: [OAUTH-WG] Report an authentication issue > > But this use case does need OAuth, period: > > > > The video server is under the control of a police agency, and police > officers must logon to the video server in order to access video content. > > There is no delegation here, and there is no need to use third party > for authentication. > > Igor > > On 6/20/2012 3:26 PM, Justin Richer wrote: > > In case it wasn't clear, I want to restate the original problem as > best as I understand it in a way that hopefully clears it up: > > App A and app B are both valid registered OAuth clients to an OAuth > protected service. > > The problem starts when app A gets handed a token that was issued for > app B and uses it to call an identity API on the OAuth service. Since > app B can get tokens just fine, they're bearer tokens, this is a > fairly basic api call, this function works just fine and returns the > user info. This makes sense, since anyone who holds A's tokens can do > whatever A can do on behalf of that user. The issues start when app B > then decides that since they can make a call to the identity API with > a token then the user *must* be present. In other words, app B is > confusing authorization to call an API with authentication of the session. > > OpenID Connect fixes this missed assumption by binding the ID Token to > the session and sending it along side the access token, but as you > pointed out, it's meant for consumption at the client, not the > resource server, in general. That doesn't mean you can't send it to a > resource server for your own purposes, of course. That's actually how > the session management endpoint works in Connect. > > This isn't the only way to handle this problem -- if you put some > structure in your tokens, such as with JWT or SAML, then app A can > tell that this isn't a token issued to app A, but to app B, so it can > call shenanigans and reject it then and there. > > -- Justin > > On 06/20/2012 10:03 AM, Lewis Adam-CAL022 wrote: > > I am entirely confused. > > I understand what everybody is saying for confidential clients, no > problem here. > > I fall apart when thinking of iPhone apps. Consider the scenario > where I deploy a video server, and write an iPhone app to talk to the > video server. The video server is under the control of a police > agency, and police officers must logon to the video server in order to > access video content. So the police office launches their iPhone > video client app. > > If I wanted to solve authentication using "traditional" client-server > authentication, the user enters their username / password into the > client, and the client sends the username / password off to the > server, which authenticates it, or possibly uses HTTP digest. > > If I wanted to use OpenID, the client would attempt to reach the video > server (RP), the server would redirect the client to the OP, OP > authenticates user, and OP redirects client back to the server/RP with > an assertion that primary authentication was successful. > > If I wanted to use OAuth, the client would send an authorization > request to the server's AS, which would authenticate the user of the > client, and ultimately result in the client possessing an > access-token. My thinking is that this access token (let's assume > it's a JWT) would contain the user's identity, a statement of what > type of primary authentication was used (auth context), an expiration, > and an audience claim. This sounds a lot like authentication to me, > and it's where I get confused. Is it just because OAuth does not > explicitly define this? Is there a threat in using OAuth as I describe? > > If I wanted to use Connect, well I'm not even sure how the id_token as > defined by Connect helps this use case. The id_token seems to make > sense when the client is a confidential web server, but it's not clear > what an iPhone app would do with the id_token ... it's the server in > the backend that needs to authenticate the user, the iPhone app is > just an interface to talk to the server. And it seems as I learn more > about connect that the id_token is not meant to be sent from the > iPhone app to the server, just the access token. So it's really not > clear how Connect helps solve authentication for an iPhone client app > talking to a video server. If I'm sending access-tokens, it's just > OAuth again. > > What am I still missing? > > adam > > *From:*oauth-bounces@ietf.org > [mailto:oauth-bounces@ietf.org] *On Behalf Of *Kristofor Selden > *Sent:* Saturday, June 16, 2012 11:33 AM > *To:* nov matake; oauth > *Cc:* Yuchen Zhou; Luke Melia; Shuo Chen (MSR) > *Subject:* Re: [OAUTH-WG] Report an authentication issue > > Nov demonstrated the problem to us at Yapp and we used solution 4 > (because the solution is server side and our app was in the app store). > > FB Connect is authentication /and/ authorization, where OAuth 2 is > concerned only with authorization -- I'm not sure that app developers > appreciate this subtlety. > > With OAuth 2 you authorize an app to use a protected resource. With > FB Connect, you do that, but /also/ authenticate with the app you are > authorizing. > > So the access_token protects not just the FB resources but the auth > end point of the authorized app (very common with apps that use the > iOS SDK). So now the app needs a way to verify that it was the app > that was authorized to FB. > > Solution 4 explanation: on FB you can register a iPhone app and a > server app with the same client_id and get a client_secret for use on > the server. The server side API posts the access_token, client_id, > and client_secret to https://graph.facebook.com/app > to verify > that the bearer token actually belongs to the app that is being > authenticated before assuming they are authorized to the app's > protected resources. > > Kris > > On Jun 15, 2012, at 8:22 PM, nov matake wrote: > > > > There are 4 ways to fix this issue. > > 1. Use response_type=token%20code (It's not in OAuth 2.0 Core, but > seems best way for interoperability) > > 2. Use singed_request (or some signed token like JWT) > > 3. Use grant_type=fb_exchange_token (Facebook custom way) > > 4. Access to https://graph.facebook.com/app?access_token=YOUR_TOKEN > (Facebook custom way, moreover undocumented API) > > Two iPhone app developers I reported this issue fixed it by using (4). > > I also tried to use (1) for my own iPhone app implementation, but > unfortunately it doesn't work when using authorization codes obtained > via FB iOS SDK. > > So I'm using (3) in my case. > > nov > > On 2012/06/16, at 9:16, Nat Sakimura wrote: > > > > As to how the fix was done, Nov can provide more detail, but ... > > 1. Properly verify the signature/HMAC of the "signed_request". This > will essentially audience restricts the token. > > 2. There is an undocumented API for Facebook which returns to whom the > token was issued. This also audience restricts the token. > > The service that fixed took these measures. Note that none of the > above is defined in OAuth. > > The same facility was called "id_token" and "check ID endpoint" for > OpenID Connect. > > The scale of the impact is large, too large to disclose the actual > names in the public list, though, eventually, we would publish them in > a paper. > > Nat > > On Sat, Jun 16, 2012 at 5:34 AM, Francisco Corella > > wrote: > > Hi Nat and Rui, > > Rui, you say that the vulnerability that you found was due to a > "common misunderstanding among developers", but the attack you > describe can be carried out against any app that uses the OAuth > "implicit grant flow", which Facebook calls "client-side > authentication". No misunderstanding seems necessary. What > misunderstanding are you referring to? I followed the link in your > message to the Sophos post, and from there the link to the article in > The Register. The article in The Register says that Facebook had > "fixed the vulnerability promptly". How did they fix it? The > instructions that Facebook provides for implementing "Client-side > authentication without the JS SDK" at > https://developers.facebook.com/docs/authentication/client-side/#no-jssdk > still allows the attack. > > Nat, I agree that the blog post by John Bradley that you link to > refers to the same vulnerability reported by Rui. You say that some > apps have issued a patch to fix it. Could you explain what the fix > was? > > Francisco > > ------------------------------------------------------------------------ > > *From:*Nat Sakimura > > *To:* rui wang > > *Cc:* matake nov >; Yuchen > Zhou >; > oauth >; Shuo Chen (MSR) > > > *Sent:* Thursday, June 14, 2012 1:50 PM > *Subject:* Re: [OAUTH-WG] Report an authentication issue > > This is a fairly well known (hopefully by now) issue. We, at the > OpenID Foundation, call it "access_token phishing" attack these > days. See: > http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.html > > Nov Matake has actually built the code on iPhone to verify the > problem, and has notified bunch of parties back in February > including Facebook and Apple. We have the code that actually runs > on a phone, and we have successfully logged in to bunch of apps, > including very well known ones. They were all informed of the > issue. Some immediately issued a patch to fix it while others have > not. > > The problem is that even if these apps gets fixed, the problem > does not go away. As long as the attacker has the vulnerable > version of the app, he still can impersonate the victim. To stop > it, the server side has to completely disable the older version, > which means the service has to cut off many users pausing business > problems. > > Nat > > On Fri, Jun 15, 2012 at 2:18 AM, rui wang > wrote: > > Dear Facebook Security Team and OAuth Standard group, > > We are a research team in Microsoft Research. In January, 2011, we > reported a vulnerability in Facebook Connect which allowed > everyone to sign into Facebook-secured relying parties without > password. It was promptly fixed after reporting. > (http://nakedsecurity.sophos.com/2011/02/02/facebook-flaw-websites-steal-personal-data/) > > Recently, we found a common misunderstanding among developers of > mobile/metro apps when using OAuth (including Facebook's OAuth) > for authentication. The vulnerability resulted from this > misunderstanding also allows an attacker to log into a victim > user's account without password. > > Let's take Soluto's metro app as an example to describe the > problem. The app supports Facebook Login. As an attacker, we can > write a regular Facebook app. Once the victim user allows our app > to access her Facebook data, we receive an access_token from the > traffic. Then, on our own machine (i.e., the "attacker" machine), > we run the metro app of Soluto, and use a HTTP proxy to insert the > victim's access_token into the traffic of Facebook login. Through > this way, we are able to log into the victim's Soluto account from > our machine. Other than Soluto, we also have confirmed the same > issue on another Windows 8 metro-app Givit. > > The Facebook SDK for Android apps > (https://developers.facebook.com/docs/mobile/android/build/#sdk) > seems to have the possibility to mislead developers too. At least, > the issue that we found is not clearly mentioned. In the SDK, we > ran the sample code called "Hackbook" using Android Emulator > (imagine it is an attacker device). Note that we have already > received the access token of the victim user from our regular > Facebook app. We then inject the token to the traffic of Hackbook. > Through this way, Hackbook app on our own machine recognizes us as > the victim. Note that this is not a convincing security exploit > yet, because this sample code does not include the server-side > code. However, given that we have seen real server-side code > having this problem, such as Soluto, Givit and others, we do > believe that the sample code can mislead mobile/metro developers. > We also suspect that this may be a general issue of many OAuth > implementations on mobile platforms, so we send this message to > OAuth Standard group as well. > > We have contacted the vendors of the two vulnerable metro-apps, > Soluto and Gavit. > > Please kindly give us an ack when you receive this message. If you > want to know more details, please let us know. > > Best Regards, > Yuchen Zhou, Rui Wang, and Shuo Chen > > > _______________________________________________ > 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 > > > > -- > 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 > > > > _______________________________________________ > OAuth mailing 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 --------------010801020709000701020008 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Lewis, I think you are perhaps conflating the token model (whether it has inherent structure or is merely a pointer to user info) and who the RO owner is - user or enterprise.

Nothing prevents you today from using OAuth as is to issue a token to the officer on the tablet, having the app use that token on API calls, and the API making an authz decision based solely on enterprise policy, with no consent figuring in.

Neither do you need a structured token (like id_token). The token issued can merely be a pointer/artifact to the officer's actual roles, these obtained by the API/RS by sending the tokens for 'validation' or 'introspection'

This doesnt sound like a Connect Use Case to me - rather a pretty standard OAuth use case - albeit with no need to get user's consent (so actually simpler).
 
paul

On 6/21/12 12:01 PM, Lewis Adam-CAL022 wrote:

Hi Nat,

 

I’m beginning to wonder what it would take to add a new profile of sorts to either OAuth or Connect. 

 

In the beginning there was SOAP, and the preferred method to secure SOAP API calls was WS-Trust.

 

Now the world is moving toward RESTful APIs … and the preferred means to secure RESTful APIs is OAuth.

 

Except that OAuth is clearly written with the idea that the protected resources belong to the end user.

 

My use cases – and I imagine the use cases of many other enterprises – is that the Owner of the resources is the Enterprise.  An employee is trying to access a database or video resources.  The enterprise RS needs to be able to 1) identify the user, and 2) make authorization decisions based on what roles that user has within the enterprise.  So in my scenario, when a police officer attempts to access a criminal records database, the database needs to know who that officer is, and then decide if they have privilege to access the database, and at what level (e.g. CRUD). 

 

WS-Trust fits this model well.  The user performs primary authentication to the enterprise STS, which then grants the application client a SAML assertion.  When the user attempts to access a records database, the SAML assertion is included in the SOAP message.  The records server authenticates the user based on the SAML assertion and makes its authorization decisions.

 

This is the world I’m trying to migrate from, and it really seems like I’m sometimes trying to make a square peg fit in a round hole.  I’m looking for OAuth/Connect to do for REST what WS-TRUST did for SOAP.  I would like a native client talking to a RS to be able to ask for an id_token, and then pass that id_token to the RS when making its RESTful API calls, to enable the RS to authenticate the user.  I think that this would be really useful for a lot of people besides me.  I keep hearing that there is nothing “preventing” me from doing this … but it hardly seems within the spirit of what OAuth was meant to do.  The id_token was clearly meant to enable a user to authenticate to a confidential client  / web server … but was not meant for a native client to identity / authenticate the user to a RS. 

 

 

Would there be any interest in exploring this further?

-adam

 

 

From: Nat Sakimura [mailto:sakimura@gmail.com]
Sent: Wednesday, June 20, 2012 8:09 PM
To: Lewis Adam-CAL022
Cc: igor.faynberg@alcatel-lucent.com; oauth@ietf.org
Subject: Re: [OAUTH-WG] Report an authentication issue

 

Yes, OAuth can be profiled to enable authentication. 

In fact, initial draft of OpenID Connect was just like you described. 

Essentially, we were using structured access_token. 

Later, we decided to separate the access token and id_token for several reasons such as: 

 

  1. Better interop with existing OAuth implementations: by introducing id_token, they do not need to touch the supposedly opaque (which means AS-RS may be doing some proprietary thing inside it) access token. 
  2. Mixing up the audience (for id_token aka authn = client, and for access_token aka authz = resource server) probably is expanding the attack surface for security and privacy. 

Although we separated them out, a signed id_token includes the left hash of access_token so access_token is also protected. 

 

Best, 

 

Nat

 

On Thu, Jun 21, 2012 at 5:21 AM, Lewis Adam-CAL022 <Adam.Lewis@motorolasolutions.com> wrote:

Hi Igor,

 

As Justin just pointed out, consider the case where the video server is hosted by the state (e.g. California) and is accessed by police agencies in Los Angeles, San Francisco, and San Diego.  The State of California’s video server is the RS.  Each local police agency (LA/SF/SD) hosts an AS.  So when a police officer from LAPD launches the video client app on the iPhone, the client makes an OAuth request to the LAPD’s AS, which authenticates the police officer using agency level credentials.  The access token issued to the video client app on the iPhone is a JWT, signed by the agency AS, which might look something like this:

 

{“typ”:”JWT”,"alg":"ES256"}

{"iss":"https://as.lapd.california.gov",
  "prn":"alice@lapd.california.gov",
  "aud":" https://video_server1@state.california.gov",
  "iat":1300815780,
  "exp":1300819380,
  "acr":”password”}

hq4zk+ZknjggCQgZm7ea8fI79gJEsRy3E8LHDpYXWQIgZpkJN9CMLG8ENR4Nrw+n7iyzixBvKXX8P53BTCT4VghPBWhFYSt9tHWu/AtJfOTh6qaAsNdeCyG86jmtp3TDMwuL/cBUj2OtBZOQMFn7jQ9YB7klIz3RqVL+wNmeWI4=

 

The JWT might be optionally encrypted using JWE. 

 

I think what is becoming clear (and this is what I’m trying to vet) is that while there is nothing in OAuth that specifies authentication, it *can* be used for Authentication, if done in the way that I describe.  If I’m wrong about this, I really need to know.  I’ve vetted this idea of mine with quite of few people now – both within context of the list and off-line – and I think I’m okay. If you see any holes in what I describe, please point them out as I would prefer to uncover them now rather than after implementation or deployment!

 

Essentially I’m using OAuth as a RESTful version of WS-Trust, where my client can exchange primary credentials for a token (JWT) and present that token to a server as secondary authentication.  It’s just that it’s RESTful instead of SOAP :-)

 

As Justin as pointed out … I’ve basically made the access-token look like the id_token of Connect.  I was actually hoping to lay a path to Connect, and use the id_token … until it was also pointed out that the id_token is really meant for the consumption of the client, not the RS :-(

 

 

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Igor Faynberg
Sent: Wednesday, June 20, 2012 2:39 PM
To: oauth@ietf.org


Subject: Re: [OAUTH-WG] Report an authentication issue

 

But this use case  does need OAuth, period:



The video server is under the control of a police agency, and police officers must logon to the video server in order to access video content.

There is no delegation here, and there is no need to use third party for authentication. 

Igor

On 6/20/2012 3:26 PM, Justin Richer wrote:

In case it wasn't clear, I want to restate the original problem as best as I understand it in a way that hopefully clears it up:

App A and app B are both valid registered OAuth clients to an OAuth protected service.

The problem starts when app A gets handed a token that was issued for app B and uses it to call an identity API on the OAuth service. Since app B can get tokens just fine, they're bearer tokens, this is a fairly basic api call, this function works just fine and returns the user info. This makes sense, since anyone who holds A's tokens can do whatever A can do on behalf of that user. The issues start when app B then decides that since they can make a call to the identity API with a token then the user *must* be present. In other words, app B is confusing authorization to call an API with authentication of the session.

OpenID Connect fixes this missed assumption by binding the ID Token to the session and sending it along side the access token, but as you pointed out, it's meant for consumption at the client, not the resource server, in general. That doesn't mean you can't send it to a resource server for your own purposes, of course. That's actually how the session management endpoint works in Connect.

This isn't the only way to handle this problem -- if you put some structure in your tokens, such as with JWT or SAML, then app A can tell that this isn't a token issued to app A, but to app B, so it can call shenanigans and reject it then and there.

 -- Justin

On 06/20/2012 10:03 AM, Lewis Adam-CAL022 wrote:

I am entirely confused.

 

I understand what everybody is saying for confidential clients, no problem here.

 

I fall apart when thinking of iPhone apps.  Consider the scenario where I deploy a video server, and write an iPhone app to talk to the video server.  The video server is under the control of a police agency, and police officers must logon to the video server in order to access video content.  So the police office launches their iPhone video client app.

 

If I wanted to solve authentication using “traditional” client-server authentication, the user enters their username / password into the client, and the client sends the username / password off to the server, which authenticates it, or possibly uses HTTP digest. 

If I wanted to use OpenID, the client would attempt to reach the video server (RP), the server would redirect the client to the OP, OP authenticates user, and OP redirects client back to the server/RP with an assertion that primary authentication was successful. 

If I wanted to use OAuth, the client would send an authorization request to the server’s AS, which would authenticate the user of the client, and ultimately result in the client possessing an access-token.  My thinking is that this access token (let’s assume it’s a JWT) would contain the user’s identity, a statement of what type of primary authentication was used (auth context), an expiration, and an audience claim.  This sounds a lot like authentication to me, and it’s where I get confused.  Is it just because OAuth does not explicitly define this?  Is there a threat in using OAuth as I describe? 

If I wanted to use Connect, well I’m not even sure how the id_token as defined by Connect helps this use case.  The id_token seems to make sense when the client is a confidential web server, but it’s not clear what an iPhone app would do with the id_token … it’s the server in the backend that needs to authenticate the user, the iPhone app is just an interface to talk to the server.  And it seems as I learn more about connect that the id_token is not meant to be sent from the iPhone app to the server, just the access token.  So it’s really not clear how Connect helps solve authentication for an iPhone client app talking to a video server.  If I’m sending access-tokens, it’s just OAuth again.

 

What am I still missing?

adam

 

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Kristofor Selden
Sent: Saturday, June 16, 2012 11:33 AM
To: nov matake; oauth
Cc: Yuchen Zhou; Luke Melia; Shuo Chen (MSR)
Subject: Re: [OAUTH-WG] Report an authentication issue

 

Nov demonstrated the problem to us at Yapp and we used solution 4 (because the solution is server side and our app was in the app store).

 

FB Connect is authentication and authorization, where OAuth 2 is concerned only with authorization – I'm not sure that app developers appreciate this subtlety.

 

With OAuth 2 you authorize an app to use a protected resource.  With FB Connect, you do that, but also authenticate with the app you are authorizing.

 

So the access_token protects not just the FB resources but the auth end point of the authorized app (very common with apps that use the iOS SDK).  So now the app needs a way to verify that it was the app that was authorized to FB.

 

Solution 4 explanation: on FB you can register a iPhone app and a server app with the same client_id and get a client_secret for use on the server.  The server side API posts the access_token, client_id, and client_secret to https://graph.facebook.com/app to verify that the bearer token actually belongs to the app that is being authenticated before assuming they are authorized to the app's protected resources.

 

Kris

 

On Jun 15, 2012, at 8:22 PM, nov matake wrote:



There are 4 ways to fix this issue.

 

1. Use response_type=token%20code (It's not in OAuth 2.0 Core, but seems best way for interoperability)

2. Use singed_request (or some signed token like JWT)

3. Use grant_type=fb_exchange_token (Facebook custom way)

4. Access to https://graph.facebook.com/app?access_token=YOUR_TOKEN (Facebook custom way, moreover undocumented API)

 

Two iPhone app developers I reported this issue fixed it by using (4).

 

I also tried to use (1) for my own iPhone app implementation, but unfortunately it doesn't work when using authorization codes obtained via FB iOS SDK.

So I'm using (3) in my case.

 

nov

 

On 2012/06/16, at 9:16, Nat Sakimura wrote:



As to how the fix was done, Nov can provide more detail, but ... 

 

1. Properly verify the signature/HMAC of the "signed_request". This will essentially audience restricts the token. 

2. There is an undocumented API for Facebook which returns to whom the token was issued. This also audience restricts the token. 

 

The service that fixed took these measures. Note that none of the above is defined in OAuth. 

The same facility was called "id_token" and "check ID endpoint" for OpenID Connect. 

 

The scale of the impact is large, too large to disclose the actual names in the public list, though, eventually, we would publish them in a paper. 

 

Nat

On Sat, Jun 16, 2012 at 5:34 AM, Francisco Corella <fcorella@pomcor.com> wrote:

Hi Nat and Rui,

Rui, you say that the vulnerability that you found was due to a
"common misunderstanding among developers", but the attack you
describe can be carried out against any app that uses the OAuth
"implicit grant flow", which Facebook calls "client-side
authentication".  No misunderstanding seems necessary.  What
misunderstanding are you referring to?  I followed the link in your
message to the Sophos post, and from there the link to the article in
The Register.  The article in The Register says that Facebook had
"fixed the vulnerability promptly".  How did they fix it?  The
instructions that Facebook provides for implementing "Client-side
authentication without the JS SDK" at
https://developers.facebook.com/docs/authentication/client-side/#no-jssdk
still allows the attack.

Nat, I agree that the blog post by John Bradley that you link to
refers to the same vulnerability reported by Rui.  You say that some
apps have issued a patch to fix it.  Could you explain what the fix
was?

Francisco

 

From: Nat Sakimura <sakimura@gmail.com>
To: rui wang <ruiwangwarm@gmail.com>
Cc: matake nov <nov@matake.jp>; Yuchen Zhou <t-yuzhou@microsoft.com>; oauth <oauth@ietf.org>; Shuo Chen (MSR) <shuochen@microsoft.com>
Sent: Thursday, June 14, 2012 1:50 PM
Subject: Re: [OAUTH-WG] Report an authentication issue

 

This is a fairly well known (hopefully by now) issue. We, at the OpenID Foundation, call it "access_token phishing" attack these days. See: http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.html

 

Nov Matake has actually built the code on iPhone to verify the problem, and has notified bunch of parties back in February including Facebook and Apple. We have the code that actually runs on a phone, and we have successfully logged in to bunch of apps, including very well known ones. They were all informed of the issue. Some immediately issued a patch to fix it while others have not.  

 

The problem is that even if these apps gets fixed, the problem does not go away. As long as the attacker has the vulnerable version of the app, he still can impersonate the victim. To stop it, the server side has to completely disable the older version, which means the service has to cut off many users pausing business problems. 

 

Nat

On Fri, Jun 15, 2012 at 2:18 AM, rui wang <ruiwangwarm@gmail.com> wrote:

Dear Facebook Security Team and OAuth Standard group,

We are a research team in Microsoft Research. In January, 2011, we reported a vulnerability in Facebook Connect which allowed everyone to sign into Facebook-secured relying parties without password. It was promptly fixed after reporting. (http://nakedsecurity.sophos.com/2011/02/02/facebook-flaw-websites-steal-personal-data/)

Recently, we found a common misunderstanding among developers of mobile/metro apps when using OAuth (including Facebook’s OAuth) for authentication. The vulnerability resulted from this misunderstanding also allows an attacker to log into a victim user's account without password.

Let's take Soluto's metro app as an example to describe the problem. The app supports Facebook Login. As an attacker, we can write a regular Facebook app. Once the victim user allows our app to access her Facebook data, we receive an access_token from the traffic. Then, on our own machine (i.e., the "attacker" machine), we run the metro app of Soluto, and use a HTTP proxy to insert the victim's access_token into the traffic of Facebook login. Through this way, we are able to log into the victim's Soluto account from our machine. Other than Soluto, we also have confirmed the same issue on another Windows 8 metro-app Givit.

The Facebook SDK for Android apps (https://developers.facebook.com/docs/mobile/android/build/#sdk) seems to have the possibility to mislead developers too. At least, the issue that we found is not clearly mentioned. In the SDK, we ran the sample code called "Hackbook" using Android Emulator (imagine it is an attacker device). Note that we have already received the access token of the victim user from our regular Facebook app. We then inject the token to the traffic of Hackbook. Through this way, Hackbook app on our own machine recognizes us as the victim. Note that this is not a convincing security exploit yet, because this sample code does not include the server-side code. However, given that we have seen real server-side code having this problem, such as Soluto, Givit and others, we do believe that the sample code can mislead mobile/metro developers. We also suspect that this may be a general issue of many OAuth implementations on mobile platforms, so we send this message to OAuth Standard group as well.

We have contacted the vendors of the two vulnerable metro-apps, Soluto and Gavit.

Please kindly give us an ack when you receive this message. If you want to know more details, please let us know.

Best Regards,
Yuchen Zhou, Rui Wang, and Shuo Chen


_______________________________________________
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



 

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

 

 
 
_______________________________________________
OAuth mailing 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
--------------010801020709000701020008-- From bcampbell@pingidentity.com Thu Jun 21 13:23:01 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97FF421F855E for ; Thu, 21 Jun 2012 13:23:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.917 X-Spam-Level: X-Spam-Status: No, score=-5.917 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IIzX+7J2DKk8 for ; Thu, 21 Jun 2012 13:23:00 -0700 (PDT) Received: from na3sys009aog138.obsmtp.com (na3sys009aog138.obsmtp.com [74.125.149.19]) by ietfa.amsl.com (Postfix) with ESMTP id 4D7B621F8510 for ; Thu, 21 Jun 2012 13:23:00 -0700 (PDT) Received: from mail-qc0-f182.google.com ([209.85.216.182]) (using TLSv1) by na3sys009aob138.postini.com ([74.125.148.12]) with SMTP ID DSNKT+OCo3jIwcPBXyTFSIrLgnRENuCx214p@postini.com; Thu, 21 Jun 2012 13:23:00 PDT Received: by qcsg15 with SMTP id g15so817900qcs.27 for ; Thu, 21 Jun 2012 13:22:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=B1jJCDgd2km0YGgey2zSnA+B4J6hFtVFY8WRSTgxqEE=; b=E4ZVcYIaK9IILmWPyApJKp/NRqlbaSsAPngFctnilrd1MrJnwvHpQ7fbjBiRGfaln2 O0TI+aUF3QfKa0//cXX0Hz2DfHPMBm/iHa3rmfSpPZVwSfMMO6a20+5fcXf08BWNkJRW 60ER9YXKbjno/KG4ZZHdnhX5aUHl65jU4LSoNogibCFTwN5OlbBXKjGb7a2PhPA222tb yInTdyuNAdVft3YjwrFoyrDG60W/u1gTd3KwAfxPaMh8z8MVHLd5KoeSR1ZXAOPGqCQy RmuUeAjihcBiZF73uobgFCOpn4i4B4sHFQikXslC2t1tOWlhi6GuGE4V2Z8AnPini6cL /unA== Received: by 10.229.135.146 with SMTP id n18mr11325160qct.138.1340310178792; Thu, 21 Jun 2012 13:22:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.87.142 with HTTP; Thu, 21 Jun 2012 13:22:28 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436656365A@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <4FE1C16D.6010602@cs.tcd.ie> <4CD0B85C-C88D-4B52-81E4-5D53A25E60EF@cs.tcd.ie> <4E1F6AAD24975D4BA5B16804296739436656365A@TK5EX14MBXC283.redmond.corp.microsoft.com> From: Brian Campbell Date: Thu, 21 Jun 2012 14:22:28 -0600 Message-ID: To: Mike Jones Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmII/IfrTZTDEyrQ7/EB0DbFzvcC3JJ6IxAIhQIgdaIYFKVXg39CrbKDHDLGgkU/bF9/LM5 Cc: Barry Leiba , "oauth@ietf.org" Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-urn-sub-ns-02 X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 20:23:01 -0000 I agree there but does that have anything to do with the track of this doc (standards vs info)? Isn't that defined in the doc itself? i.e. "The registration procedure for new entries requires a request in the form of the following template and is subject to Expert Review per RFC 5226 [RFC5226]." On Thu, Jun 21, 2012 at 1:49 PM, Mike Jones w= rote: > I'd argue that the registration regime chosen should be flexible enough t= o > permit OASIS or OpenID specs to use it. Otherwise, as someone else pointe= d, > people will work around the limitation by using unregistered values - whi= ch > helps no one. > > -- Mike > > ________________________________ > From: Barry Leiba > Sent: 6/21/2012 12:31 PM > > To: Stephen Farrell > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-urn-sub-ns-02 > >>> Stephen: >>> Yeah, I'm not sure Standards Track is needed. >> >> On this bit: I personally don't care, except that we don't have to do it >> twice >> because someone later on thinks the opposite and wins that argument, whi= ch >> I'd rather not have at all =A0(My one-track mind:-) Doing the 4 week las= t >> call means >> once is enough. But I'm ok with whatever the WG want. > > Well, it's not a 4-week LC, but a 2-week one.=A0 Anyway, yes, I see your > point, and I've done that with other documents.=A0 Better to make it > Standards Track for now, note in the shepherd writeup that > Informational is probably OK, and let the IESG decide. > > b > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From Michael.Jones@microsoft.com Thu Jun 21 13:29:42 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E2C321F8655 for ; Thu, 21 Jun 2012 13:29:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.317 X-Spam-Level: X-Spam-Status: No, score=-5.317 tagged_above=-999 required=5 tests=[AWL=1.282, 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 KhknaZIQgLR9 for ; Thu, 21 Jun 2012 13:29:41 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by ietfa.amsl.com (Postfix) with ESMTP id B6F0121F8652 for ; Thu, 21 Jun 2012 13:29:41 -0700 (PDT) Received: from mail63-tx2-R.bigfish.com (10.9.14.235) by TX2EHSOBE008.bigfish.com (10.9.40.28) with Microsoft SMTP Server id 14.1.225.23; Thu, 21 Jun 2012 20:28:13 +0000 Received: from mail63-tx2 (localhost [127.0.0.1]) by mail63-tx2-R.bigfish.com (Postfix) with ESMTP id 7EB2C3204AB; Thu, 21 Jun 2012 20:28:13 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC105.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -28 X-BigFish: VS-28(zz98dI9371I542M1432Izz1202hzz1033IL8275dhz2fh2a8h668h839hd25hf0ah) Received-SPF: pass (mail63-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC105.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail63-tx2 (localhost.localdomain [127.0.0.1]) by mail63-tx2 (MessageSwitch) id 1340310491770507_20837; Thu, 21 Jun 2012 20:28:11 +0000 (UTC) Received: from TX2EHSMHS026.bigfish.com (unknown [10.9.14.237]) by mail63-tx2.bigfish.com (Postfix) with ESMTP id AF9C122004C; Thu, 21 Jun 2012 20:28:11 +0000 (UTC) Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS026.bigfish.com (10.9.99.126) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 21 Jun 2012 20:28:09 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.53]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.02.0309.003; Thu, 21 Jun 2012 20:29:36 +0000 From: Mike Jones To: Brian Campbell , Barry Leiba Thread-Topic: [OAUTH-WG] I-D Action: draft-ietf-oauth-urn-sub-ns-03.txt Thread-Index: AQHNT9bbR+7wOx82f0K640qXd1uXTpcFKF2AgAAHf4CAAAlvMA== Date: Thu, 21 Jun 2012 20:29:35 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943665637A0@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <20120621175317.32545.76545.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.72] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: OAuth WG Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-urn-sub-ns-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2012 20:29:42 -0000 I agree that one registry is sufficient. The number of registrations won't= be huge and so having sub-registries seems like overkill. -- Mike -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of B= rian Campbell Sent: Thursday, June 21, 2012 12:55 PM To: Barry Leiba Cc: OAuth WG Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-urn-sub-ns-03.txt I honestly don't understand the push to have additional registries under ur= n:ietf:params:oauth? On Thu, Jun 21, 2012 at 1:28 PM, Barry Leiba wrot= e: > This one's mostly there. =A0As Mike and Hannes are discussing, the WG=20 > needs to sort out exactly what goes under "oauth" here. > > Here's a suggestion: > Have Section 3 specify that what comes after "oauth" are one or more=20 > tokens, delimited by ":". > Have Section 3 create the registry for the first-level token, "class". > =A0In your example, that's "grant-type". > Have Section 3 specify that the definition of each "class" token=20 > specifies what comes after it -- how many tokens, and the meaning(s). > Have Section 3 note that certain classes might create new=20 > sub-registries for what goes under them, if necessary. > Have Section 3 note that certain classes might have *no* further=20 > tokens under them. > > I realize that there might not be any use cases envisioned right now=20 > for that last one, but it might be a bad idea to forbid it. > > Section 5: > > =A0 o =A0Repository: [[not sure about this? this document or > =A0 =A0 =A0http://www.iana.org/assignments/oauth]] > > Yeh, I've never been sure about that either. =A0I think what you want=20 > here is "[[The registry created in Section 3.]]". > See RFC 6134 for how I did this with the "sieve" namespace. > > Barry > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From bcampbell@pingidentity.com Thu Jun 21 13:49:13 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4854C21F85A1 for ; Thu, 21 Jun 2012 13:49:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.922 X-Spam-Level: X-Spam-Status: No, score=-6.922 tagged_above=-999 required=5 tests=[AWL=1.055, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, 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 fN3kDYDN4G1G for ; Thu, 21 Jun 2012 13:49:12 -0700 (PDT) Received: from na3sys009aog132.obsmtp.com (na3sys009aog132.obsmtp.com [74.125.149.250]) by ietfa.amsl.com (Postfix) with ESMTP id 070C421F859F for ; Thu, 21 Jun 2012 13:49:11 -0700 (PDT) Received: from mail-qc0-f171.google.com ([209.85.216.171]) (using TLSv1) by na3sys009aob132.postini.com ([74.125.148.12]) with SMTP ID DSNKT+OIxyN7vRzEsaBh8jZY8yGZ8MJ/sP4k@postini.com; Thu, 21 Jun 2012 13:49:12 PDT Received: by qcsp15 with SMTP id p15so993842qcs.16 for ; Thu, 21 Jun 2012 13:49:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=oOBdtv6sg6cxC8irT4ebqBNK1GEEbpJwNxSYcnDED68=; b=PdEMGs6g3Blj+zbCM9HXbPymVUrBr2k2pvn7H3pVUVxbrBSruo2yz9u6BvDTOk0K2+ 669KL5s3Rtoqr1Fbq5qIvLfxxmWrinYCPYd85KhIVsY/VgM+oCkQ2++8dhV6nuG13zCh nAnITJtqDbW9mLCju4PwFdKbwRr6oDm8+7DNUm7asEc1t+n+2vDjgCC2PeOp0fByN4+a yjLLbnhKNRgOHjh5iOZ5ftdgTs9EIyDVfpZF1A2O9ZthNtxFQG8L7zDAFhr53Kgcny/f CYF/L7QlYdmRe+AiEfgO6peJq3e3WlPOmEQKWmbJX0X28FY2POnUYM45UDSZtpdMNCCZ EJHw== Received: by 10.229.135.141 with SMTP id n13mr7838833qct.105.1340311750776; Thu, 21 Jun 2012 13:49:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.87.142 with HTTP; Thu, 21 Jun 2012 13:48:39 -0700 (PDT) In-Reply-To: References: <20120621175317.32545.76545.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B16804296739436656323F@TK5EX14MBXC283.redmond.corp.microsoft.com> <0F4BC83D-9C3E-44CD-9D8C-5784A7495486@gmx.net> From: Brian Campbell Date: Thu, 21 Jun 2012 14:48:39 -0600 Message-ID: To: Hannes Tschofenig Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQn6LH/TsQS1DlBrcVWSHSjZ6vfu0KQMz93kN4cMJ4Blu7vV9VLT1Imp+4+5PD/SmXbVcQR6 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-urn-sub-ns-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2012 20:49:13 -0000 On Thu, Jun 21, 2012 at 1:48 PM, Hannes Tschofenig wrote: > Btw, in a discussion with Brian we check the policies for the three exten= sions in the OAuth core specification > > 1) Section 8.3. Defining New Authorization Grant Types > > If you don't define additional token endpoint parameters then there is ac= tually no requirement for expert review or a specification. > It is probably FCFS. That raises a different question/issue. My understanding of the core spec was that it used URIs in extension points that might be profiled by actual specifications as well as by vendor-specific or other less rigorous implementations. To the extent that's true, =A78.3 of OAuth core[1] is problematic in that it allows for any URI defining the grant type but requires additional parameters the grant type might use to be registered in the The OAuth Parameters Registry (and new grant types will most likely need additional parameters). Inf fact, I've already got a vendor-specific grant type that uses an unregistered parameter on the token endpoint - it's a simple grant type for access token introspection [2]. At the time I was thinking the parameter was implicitly qualified by the grant type and this was all okay. But looking at it again, per the letter of the spec, this would seem to be a violation. But what should we have done? How does a vendor-specific extension go about registering a parameter? Would that even be a good idea? [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-28#section-8.3 [2] http://documentation.pingidentity.com/display/PF66/Grant+Type+Parameter= s#GrantTypeParameters-1079271 From bcampbell@pingidentity.com Thu Jun 21 14:07:34 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3969121F8679 for ; Thu, 21 Jun 2012 14:07:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.01 X-Spam-Level: X-Spam-Status: No, score=-6.01 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hWpYrN6mqBax for ; Thu, 21 Jun 2012 14:07:33 -0700 (PDT) Received: from na3sys009aog103.obsmtp.com (na3sys009aog103.obsmtp.com [74.125.149.71]) by ietfa.amsl.com (Postfix) with ESMTP id 889B221F8674 for ; Thu, 21 Jun 2012 14:07:32 -0700 (PDT) Received: from mail-qc0-f179.google.com ([209.85.216.179]) (using TLSv1) by na3sys009aob103.postini.com ([74.125.148.12]) with SMTP ID DSNKT+ONFLOwvES0OFABJCr8k4VoZjP07mQH@postini.com; Thu, 21 Jun 2012 14:07:32 PDT Received: by qcse14 with SMTP id e14so647324qcs.38 for ; Thu, 21 Jun 2012 14:07:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=6ODo7rBkkH4cqsuzJvethI3WXlggbGA8xqiYtPZ6R4A=; b=iX5gGdqv/RU5f8sC4+lneo4uwWazivkp3e8n9kCUUAsO0HnBOIDXrSue1Q2+v2QMcw q5pq6JwUPBnN4r4mCh7JlEeECT52nclKKV/vzclmgNmWfY+Nbvw2p1xz6Bux7HoljupL p96K3CmT930WdmzI4mUFgZwIf5aWTKrkjEAH0Svp5SDqdSixMy7OpQ4Nj/y8wPlps0IZ qV3POW9UKLxd4FyuwyAOPUGbg3m1SGXTshjEbh1m9YubMvVog1Ij/ZEf4f5VXMzuaAtD ODPVhRFFPW0q80WqZ8pbMmeLbxbBfih/tU0TlCSdHU/RlEOsqgs3d/g/pdhUrlzW0h0O 1mpQ== Received: by 10.224.185.148 with SMTP id co20mr2190823qab.4.1340312851425; Thu, 21 Jun 2012 14:07:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.87.142 with HTTP; Thu, 21 Jun 2012 14:07:01 -0700 (PDT) In-Reply-To: References: <20120621175317.32545.76545.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B16804296739436656323F@TK5EX14MBXC283.redmond.corp.microsoft.com> <0F4BC83D-9C3E-44CD-9D8C-5784A7495486@gmx.net> From: Brian Campbell Date: Thu, 21 Jun 2012 15:07:01 -0600 Message-ID: To: Hannes Tschofenig Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQk+80RYy6tFEb/3FwWUUFK9iyvw3DfuBs7z0wMPPNtt5GSmmyLjOrh58GaxAcQu8rqKN/fX Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-urn-sub-ns-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2012 21:07:34 -0000 As far as the rest of the policy discussion, I have no interest or intent to define policy for this stuff. A year+ ago I needed a URI for the SAML grant type. It could be anything but it should be something stable. And it'd be nice if it was semi-meaningful. I was using http://openid.net or something for a while and there were concerns about ownership and stability. Also because SAML grant was an IETF draft, it seed to make sense to have an IETF URI. I didn't know how to get one so I asked. Eventually Hannes suggested the text that became draft-ietf-oauth-urn-sub-ns. A few more things came along that similarly needed URIs (JWT grant and client assertion auth) so it seemed to be working out well. Very little changed in that draft for nearly a year until the AD review yesterday brought up some deficiencies. I tried to address those in -03 today (and would like to do a -04 soon with the minor changes Mike suggested). With that said, all I really wanted was an easy way to reserve or register a stable and somewhat meaningful URI. It's proven not to be easy, however. Adding additional sub-registries and policy to urn:ietf:params:oauth, which will probably only ever have a few values in it, seems to me to be unnecessarily adding a lot of overhead to it all. Perhaps I'm mistaken but wouldn't Expert Review catch URIs that are just wrong prior to registration? And even if it didn't, what really is the harm? On Thu, Jun 21, 2012 at 1:48 PM, Hannes Tschofenig wrote: > Btw, in a discussion with Brian we check the policies for the three exten= sions in the OAuth core specification > > 1) Section 8.3. =A0Defining New Authorization Grant Types > > If you don't define additional token endpoint parameters then there is ac= tually no requirement for expert review or a specification. > It is probably FCFS. > > 2) Section 8.1. =A0Defining Access Token Types > > For URIs there seems to be no constraint either although the text talks a= bout limited to vendor-specific implementations. > > 3) client_assertion_type is created in http://tools.ietf.org/html/draft-i= etf-oauth-assertions-03#section-8.3 > > There is no description either for what is required to register a new ass= ertion type into the URN class client_assertion_type. > > (For client authentication mechanisms there is actually no registry in co= re and therefore there is no policy either.) > > Ciao > Hannes > > On Jun 21, 2012, at 10:12 PM, Hannes Tschofenig wrote: > >> Hi Mike, >> >> Thanks for your mail. >> >> First, I would like to argue for a registry that has more than one level= . We need a two level registry because the different extensions have (and w= ill also in the future) have different extension policies. >> >> The structure of the registry is: urn:ietf:params:oauth:: >> >> On the first level, the part, we have high level functionality t= hat was defined in the core specification. This includes things like >> >> 1) authorization grants (which you call grant-type in your registration = request in http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-12) >> >> So, this would be urn:ietf:params:oauth:grant-type >> >> 2) client authentication mechanism (which you call client-assertion-type= in http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-12 but should = rather mean something like client-auth-type) >> >> So, this could be something like urn:ietf:params:oauth:client-auth-type >> >> 3) Access Token Types (which is called 'token-type' in http://www.ietf.o= rg/id/draft-ietf-oauth-json-web-token-00.txt) >> >> This is urn:ietf:params:oauth:token-type. >> >> [PS: The text in the http://tools.ietf.org/html/draft-ietf-oauth-v2-28#s= ection-8.1 for registering new access token types is a bit confusing and I = am not sure whether an absolute URI would actually be required even though = it makes a lot of sense.] >> >> While I believe that our initial requirement for "RFC required" for addi= ng these top level classes makes sense since these basic extension features= to OAuth are really core to the protocol functionality it is good that the= group checks them carefully. >> >> Then, at the level the individual values reside. For the authorizat= ion grant this is 'saml2-bearer' as defined in http://tools.ietf.org/html/d= raft-ietf-oauth-saml2-bearer-12#section-6. >> >> So, what is the right policy for adding values under urn:ietf:params:oau= th:grant-type? http://tools.ietf.org/html/draft-ietf-oauth-v2-28#section-8.= 3 says what the policy is. So, instead of re-deciding a new policy for addi= ng entries here it would be good to get it inline with what the policy is i= n the core spec. >> >> What could go wrong if the two are not aligned? I actually had that case= in the DIME working group. Without going into the details the registry had= a much stronger policy (RFC required) than the protocol specification (whi= ch only required a specification, if I remember it). The consequence was th= at people couldn't easily register new values from other organizations sinc= e they would fail in the last step when a new registry value had to be crea= ted (since IANA then told them 'RFC Required'). Consequently, these other o= rganizations who wanted to get their work done then avoided doing so by mis= using other extensions, which was really not good. >> >> Mike, you have actually been suggesting that a three level category for = certain classes of sub-registries is actually OK as well. That may be true = and we could relax the text to say that whoever defines the class also deci= des about the structure of the child elements underneath it. >> >> What I believe we need to add in the document is to populate the registr= y with the three URIs (from above; referring to the classes) and pointing t= o the policy from the core specification. Then, other docs (like draft-ietf= -oauth-json-web-token-00.txt) can just put their values in there. >> >> Ciao >> Hannes >> >> >> On Jun 21, 2012, at 9:14 PM, Mike Jones wrote: >> >>> This draft is much clearer. =A0Thanks for the quick turn-around. >>> >>> One question: =A0You added: >>> *Index value: values subordinate to urn:ietf:params:oauth are of the fr= om urn:ietf:params:oauth:: with : as the index value >>> Why bake the assumption of a two-level structure into the registry? >>> >>> For instance, you could easily imagine legal and useful registrations o= f the form ::, etc. >>> >>> Maybe change this to say: >>> *Index value: values subordinate to urn:ietf:params:oauth are of the fr= om urn:ietf:params:oauth: with as the index value. =A0It is = suggested that include both a "class" and an "identifier-within-cla= ss" component, with the two components being separated by a colon (":"); ot= her compositions of the may also be used. >>> >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-- Mike >>> >>> -----Original Message----- >>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf = Of internet-drafts@ietf.org >>> Sent: Thursday, June 21, 2012 10:53 AM >>> To: i-d-announce@ietf.org >>> Cc: oauth@ietf.org >>> Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-urn-sub-ns-03.txt >>> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. >>> This draft is a work item of the Web Authorization Protocol Working Gro= up of the IETF. >>> >>> =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : An IETF URN Sub-Namespace for OA= uth >>> =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Brian Campbell >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Hannes Tschofenig >>> =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-oauth-urn-sub-ns-03.txt >>> =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 7 >>> =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-06-21 >>> >>> Abstract: >>> =A0This document establishes an IETF URN Sub-namespace for use with >>> =A0OAuth related specifications. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-oauth-urn-sub-ns >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-oauth-urn-sub-ns-03 >>> >>> A diff from previous version is available at: >>> http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-urn-sub-ns-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 >> > From barryleiba@gmail.com Thu Jun 21 14:10:13 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5C3C21F8679 for ; Thu, 21 Jun 2012 14:10:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.937 X-Spam-Level: X-Spam-Status: No, score=-102.937 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0pucoACVyNGC for ; Thu, 21 Jun 2012 14:10:13 -0700 (PDT) Received: from mail-qa0-f52.google.com (mail-qa0-f52.google.com [209.85.216.52]) by ietfa.amsl.com (Postfix) with ESMTP id 34BEE21F8659 for ; Thu, 21 Jun 2012 14:10:13 -0700 (PDT) Received: by qabj34 with SMTP id j34so1905265qab.4 for ; Thu, 21 Jun 2012 14:10:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Snx0dotaiiCuFNhplZiLql9unIaLlEdrSWJew8d31Lk=; b=cjx3pIrAk0uXQbZiJNHbYPFPfKSqumgQejpLeV6PVAriBJBoSjn4LQxpp2dKt65uRl fnhtoIY7YJFi1jDZjsJ2QUKEuf6IaupAWOV0MzEHajOLtykYZgs1HMsToZhYVYPRQTiv p4qqPLxZKW4hCppEBAySmyAdN3f9qlPuwQmHC6wOn5PbAatNfpvTj4sr+VgIpzPJfBlv Cnm5xj7WwFDL0nrZcDv72UpfMSXH9/h4lB7F7oobmNw/f83fdTHkwqCEglGYFNcVutF9 hiW0U1mvG7baWPi3/vAv+LjcLl1HUW8sjtPxRYZ3kX3/RlZ8GuRHH96q8aB91pgx0cAm 0VaQ== MIME-Version: 1.0 Received: by 10.224.40.2 with SMTP id i2mr1963755qae.62.1340313012530; Thu, 21 Jun 2012 14:10:12 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.229.245.85 with HTTP; Thu, 21 Jun 2012 14:10:12 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943665637A0@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <20120621175317.32545.76545.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B1680429673943665637A0@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Thu, 21 Jun 2012 17:10:12 -0400 X-Google-Sender-Auth: NA5qXw4IFR8it7JSgLX2dBPsbx4 Message-ID: From: Barry Leiba To: Brian Campbell Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: OAuth WG Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-urn-sub-ns-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2012 21:10:14 -0000 >>> Have Section 3 note that certain classes might create new >>> sub-registries for what goes under them, if necessary. >> >> I honestly don't understand the push to have additional registries under >> urn:ietf:params:oauth? > > I agree that one registry is sufficient. =A0The number of registrations w= on't be > huge and so having sub-registries seems like overkill. No, there was no "push"; I was just making a suggestion for how things might be set up. If there's no need envisoned for sub-registries, that's fine. b From bcampbell@pingidentity.com Thu Jun 21 14:18:37 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAD3121F852A for ; Thu, 21 Jun 2012 14:18:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.008 X-Spam-Level: X-Spam-Status: No, score=-6.008 tagged_above=-999 required=5 tests=[AWL=-0.031, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bdfyz9SOTXoP for ; Thu, 21 Jun 2012 14:18:36 -0700 (PDT) Received: from na3sys009aog131.obsmtp.com (na3sys009aog131.obsmtp.com [74.125.149.247]) by ietfa.amsl.com (Postfix) with ESMTP id 6E85721F851C for ; Thu, 21 Jun 2012 14:18:36 -0700 (PDT) Received: from mail-qa0-f43.google.com ([209.85.216.43]) (using TLSv1) by na3sys009aob131.postini.com ([74.125.148.12]) with SMTP ID DSNKT+OPrHJ7VU83mqFtDO5VqwgQjvV9uUs5@postini.com; Thu, 21 Jun 2012 14:18:36 PDT Received: by qadb33 with SMTP id b33so4278165qad.2 for ; Thu, 21 Jun 2012 14:18:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=wOdso3CA/HRtPLZWNRMjUOduhnXw9dQMMwZXW7z5WaY=; b=lx9xmX5Qivuuk2FrpAaM+5u+ldHS7vFNO2lhCBC5BE1ABD/eT9pIsVEGH5F+Grx8Ru fYzpKo0P9ayW1vFAEdmmGsmsTUIiyTiVfreHTulkeArh9jBB9mJ7NoBoc9DTQFZnttV1 I5986/45lyKgEFqQR4npCzgEsfeHF9JNnlThDodoIO+JEe/sANTVw+wa7Rr132IecRme f83N883NNDG7B41CpYdoPHOgoUY5EWn9oZa/wlE83ARMZH1z92T3bq3AMBuoZLAKCYT5 KV+2V19G24ZTSIbKK6i/U9pnQTh91wR0xVkKN3cIqMhDxGjQN+QNB1VevW7r3+LY/qE5 P78A== Received: by 10.224.116.143 with SMTP id m15mr2067312qaq.50.1340313515407; Thu, 21 Jun 2012 14:18:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.87.142 with HTTP; Thu, 21 Jun 2012 14:18:01 -0700 (PDT) In-Reply-To: References: <20120621175317.32545.76545.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B1680429673943665637A0@TK5EX14MBXC283.redmond.corp.microsoft.com> From: Brian Campbell Date: Thu, 21 Jun 2012 15:18:01 -0600 Message-ID: To: Barry Leiba Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkVcqTUCocCpnpTe5oZGkPE1cWlFGStJpZPQ9RBC6pnXF4UGu8siRVQchDK5IwrayLJgvBn Cc: OAuth WG Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-urn-sub-ns-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2012 21:18:37 -0000 Thanks for clarifying Barry. And my apologies if I interpreted more "push" in your comments than there really was. I honestly can't envision the need for sub-registries so believe that a single one is more than sufficient. On Thu, Jun 21, 2012 at 3:10 PM, Barry Leiba wrot= e: > No, there was no "push"; I was just making a suggestion for how things > might be set up. =A0If there's no need envisoned for sub-registries, > that's fine. > > b From James.H.Manger@team.telstra.com Thu Jun 21 23:09:06 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49FA421F8602 for ; Thu, 21 Jun 2012 23:09:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.197 X-Spam-Level: X-Spam-Status: No, score=-1.197 tagged_above=-999 required=5 tests=[AWL=-0.296, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q-ZVt4ccIFjq for ; Thu, 21 Jun 2012 23:09:05 -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 45EA921F8570 for ; Thu, 21 Jun 2012 23:09:04 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,456,1336312800"; d="scan'208";a="81224880" Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipocvi.tcif.telstra.com.au with ESMTP; 22 Jun 2012 16:09:03 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6749"; a="79885929" Received: from wsmsg3705.srv.dir.telstra.com ([172.49.40.203]) by ipcavi.tcif.telstra.com.au with ESMTP; 22 Jun 2012 16:09:04 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3705.srv.dir.telstra.com ([172.49.40.203]) with mapi; Fri, 22 Jun 2012 16:09:03 +1000 From: "Manger, James H" To: Brian Campbell Date: Fri, 22 Jun 2012 16:09:02 +1000 Thread-Topic: [OAUTH-WG] I-D Action: draft-ietf-oauth-urn-sub-ns-03.txt Thread-Index: Ac1P71SR3EnYAulRTVeLP3uKcQ4oXQATPeQA Message-ID: <255B9BB34FB7D647A506DC292726F6E114F59AB0AD@WSMSG3153V.srv.dir.telstra.com> References: <20120621175317.32545.76545.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B16804296739436656323F@TK5EX14MBXC283.redmond.corp.microsoft.com> <0F4BC83D-9C3E-44CD-9D8C-5784A7495486@gmx.net> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-urn-sub-ns-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, 22 Jun 2012 06:09:06 -0000 PiBJbiBmYWN0LCBJJ3ZlIGFscmVhZHkgZ290IGEgdmVuZG9yLXNwZWNpZmljIGdyYW50IHR5cGUg dGhhdCB1c2VzIGFuDQo+IHVucmVnaXN0ZXJlZCBwYXJhbWV0ZXIgb24gdGhlIHRva2VuIGVuZHBv aW50IC0gaXQncyBhIHNpbXBsZSBncmFudA0KPiB0eXBlIGZvciBhY2Nlc3MgdG9rZW4gaW50cm9z cGVjdGlvbiBbMl0uDQo+DQo+IFsyXQ0KPiBodHRwOi8vZG9jdW1lbnRhdGlvbi5waW5naWRlbnRp dHkuY29tL2Rpc3BsYXkvUEY2Ni9HcmFudCtUeXBlK1BhcmFtZXRlcg0KPiBzI0dyYW50VHlwZVBh cmFtZXRlcnMtMTA3OTI3MQ0KDQoNCldoeSBhcmUgeW91IHRyeWluZyB0byBvdmVybG9hZCB0aGlz IG5ldyBmdW5jdGlvbmFsaXR5IG9udG8gYSBVUkkgdXNlZCBmb3Igb3RoZXIgcHVycG9zZXM/DQpX aHkgbm90IGp1c3QgcGljayBhIFVSSSBzcGVjaWZpY2FsbHkgZm9yIHlvdXIgcHVycG9zZSwgZWcg L2FzL3ZhbGlkYXRlPw0KDQotLQ0KSmFtZXMgTWFuZ2VyDQo= From hannes.tschofenig@gmx.net Fri Jun 22 00:08:00 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0E1A11E8083 for ; Fri, 22 Jun 2012 00:08:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.504 X-Spam-Level: X-Spam-Status: No, score=-102.504 tagged_above=-999 required=5 tests=[AWL=0.095, 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 MnIzLWHXXP4U for ; Fri, 22 Jun 2012 00:07:59 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 42F3911E8080 for ; Fri, 22 Jun 2012 00:07:59 -0700 (PDT) Received: (qmail invoked by alias); 22 Jun 2012 07:07:57 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.101]) [88.115.216.191] by mail.gmx.net (mp041) with SMTP; 22 Jun 2012 09:07:57 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19Vp5ZY0PFVv3iP83bXR1wRgePH5GosfYy5980uSZ 0oUDJBhYa08C/U From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 22 Jun 2012 10:07:56 +0300 Message-Id: <970540AE-E139-424E-BC90-F04113F7D53A@gmx.net> To: "oauth@ietf.org WG (oauth@ietf.org)" Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Subject: [OAUTH-WG] Use case document X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 07:08:00 -0000 Hi all,=20 I just looked at the use case document and a few questions came to my = mind: * Who is the lead editor?=20 * The abstract and the introduction explain the history of why the = document exists. You may want to change that to an introduction that = describes what use cases are in the document and why you have chosen = them instead of thousands of others, and why the reader should look = into them. After some time (and particularly after the publication as an = RFC) it does not matter whether the use cases got collected between IETF = 77 and IETF 78. =20 * The reference to RFC 2119 is not needed and Section 2 is not needed.=20= * More important, however, is the question of what use cases should be = covered in the document and how you call them. Needless to say that = there are many use cases for OAuth. For example, I believe it makes = little sense to list use cases according to what data is exchanged = (social networking information vs. travel plans vs. payment = information). So, what are the distinguishing aspects that make it = worthwhile for a use cases to be included?=20 I would say that the different protocol profiles somehow have to be = covered. This includes the different cases for the various authorization = grants. I would also say that different security levels matter. If you = do that then it would also be useful to connect the individual use cases = back to the other working group documents via references.=20 Other aspects that could matter are different implementation strategies = or different user appearance. On the latter the device flow is an = example.=20 In any case, you have to decide what the criteria are since this = determines your target audience. Who do you expect will most likely = benefit from reading this document?=20 There are various use cases in the document that are not sufficiently = different from the rest unless you highlight some aspects that you think = are really essential.=20 Ciao Hannes From hannes.tschofenig@nsn.com Fri Jun 22 01:29:21 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DAA421F867B for ; Fri, 22 Jun 2012 01:29:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.202 X-Spam-Level: X-Spam-Status: No, score=-105.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, 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 4c702YRCfe77 for ; Fri, 22 Jun 2012 01:29:11 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 0510F21F8674 for ; Fri, 22 Jun 2012 01:29:09 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q5M8T4jY020814 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 22 Jun 2012 10:29:04 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q5M8T4EW024718; Fri, 22 Jun 2012 10:29:04 +0200 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 22 Jun 2012 10:29:04 +0200 Received: from 10.144.251.144 ([10.144.251.144]) by FIESEXC035.nsn-intra.net ([10.159.0.182]) via Exchange Front-End Server webmail.nsn-intra.net ([10.150.128.36]) with Microsoft Exchange Server HTTP-DAV ; Fri, 22 Jun 2012 08:29:03 +0000 User-Agent: Microsoft-Entourage/12.33.0.120411 Date: Fri, 22 Jun 2012 11:28:59 +0300 From: Hannes Tschofenig To: ext Lewis Adam-CAL022 , Nat Sakimura Message-ID: Thread-Topic: [OAUTH-WG] Report an authentication issue Thread-Index: AQHNT0pvhTnXb3MtGkWmLvJyYY7auJcE72EAgAEULrM= In-Reply-To: <59E470B10C4630419ED717AC79FCF9A917052BC8@SN2PRD0410MB370.namprd04.prod.outlook.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3423209341_55113855" X-OriginalArrivalTime: 22 Jun 2012 08:29:04.0194 (UTC) FILETIME=[15346220:01CD5051] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 57906 X-purgate-ID: 151667::1340353744-0000425E-68A2266F/0-0/0-0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Report an authentication issue X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 08:29:21 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3423209341_55113855 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Adam,=20 It takes a document to add new functionality to Oauth. Just write one and submit it to the group. Ciao Hannes On 6/21/12 7:01 PM, "ext Lewis Adam-CAL022" wrote: > Hi Nat, > =20 > I=B9m beginning to wonder what it would take to add a new profile of sorts = to > either OAuth or Connect. > =20 > In the beginning there was SOAP, and the preferred method to secure SOAP = API > calls was WS-Trust. > =20 > Now the world is moving toward RESTful APIs =8A and the preferred means to > secure RESTful APIs is OAuth. > =20 > Except that OAuth is clearly written with the idea that the protected > resources belong to the end user. > =20 > My use cases =AD and I imagine the use cases of many other enterprises =AD is= that > the Owner of the resources is the Enterprise. An employee is trying to a= ccess > a database or video resources. The enterprise RS needs to be able to 1) > identify the user, and 2) make authorization decisions based on what role= s > that user has within the enterprise. So in my scenario, when a police of= ficer > attempts to access a criminal records database, the database needs to kno= w who > that officer is, and then decide if they have privilege to access the > database, and at what level (e.g. CRUD). > =20 > WS-Trust fits this model well. The user performs primary authentication = to > the enterprise STS, which then grants the application client a SAML asser= tion. > When the user attempts to access a records database, the SAML assertion i= s > included in the SOAP message. The records server authenticates the user = based > on the SAML assertion and makes its authorization decisions. > =20 > This is the world I=B9m trying to migrate from, and it really seems like I=B9= m > sometimes trying to make a square peg fit in a round hole. I=B9m looking f= or > OAuth/Connect to do for REST what WS-TRUST did for SOAP. I would like a > native client talking to a RS to be able to ask for an id_token, and then= pass > that id_token to the RS when making its RESTful API calls, to enable the = RS to > authenticate the user. I think that this would be really useful for a lo= t of > people besides me. I keep hearing that there is nothing =B3preventing=B2 me = from > doing this =8A but it hardly seems within the spirit of what OAuth was mean= t to > do. The id_token was clearly meant to enable a user to authenticate to a > confidential client / web server =8A but was not meant for a native client= to > identity / authenticate the user to a RS. > =20 > =20 > Would there be any interest in exploring this further? > -adam > =20 > =20 >=20 > From: Nat Sakimura [mailto:sakimura@gmail.com] > Sent: Wednesday, June 20, 2012 8:09 PM > To: Lewis Adam-CAL022 > Cc: igor.faynberg@alcatel-lucent.com; oauth@ietf.org > Subject: Re: [OAUTH-WG] Report an authentication issue > =20 > Yes, OAuth can be profiled to enable authentication. >=20 > In fact, initial draft of OpenID Connect was just like you described. >=20 > Essentially, we were using structured access_token. >=20 > Later, we decided to separate the access token and id_token for several > reasons such as:=20 >=20 > =20 > 1. Better interop with existing OAuth implementations: by introducing > id_token, they do not need to touch the supposedly opaque (which means AS= -RS > may be doing some proprietary thing inside it) access token. > 2. Mixing up the audience (for id_token aka authn =3D client, and for > access_token aka authz =3D resource server) probably is expanding the attac= k > surface for security and privacy. > Although we separated them out, a signed id_token includes the left hash = of > access_token so access_token is also protected. >=20 > =20 >=20 > Best,=20 >=20 > =20 >=20 > Nat >=20 > =20 >=20 > On Thu, Jun 21, 2012 at 5:21 AM, Lewis Adam-CAL022 > wrote: >=20 > Hi Igor, > =20 > As Justin just pointed out, consider the case where the video server is h= osted > by the state (e.g. California) and is accessed by police agencies in Los > Angeles, San Francisco, and San Diego. The State of California=B9s video s= erver > is the RS. Each local police agency (LA/SF/SD) hosts an AS. So when a p= olice > officer from LAPD launches the video client app on the iPhone, the client > makes an OAuth request to the LAPD=B9s AS, which authenticates the police > officer using agency level credentials. The access token issued to the v= ideo > client app on the iPhone is a JWT, signed by the agency AS, which might l= ook > something like this: > =20 > {=B3typ=B2:=B2JWT=B2,"alg":"ES256"} > {"iss":"https://as.lapd.california.gov", > "prn":"alice@lapd.california.gov", > "aud":" https://video_server1@state.california.gov", > "iat":1300815780, > "exp":1300819380, > "acr":=B2password=B2} > hq4zk+ZknjggCQgZm7ea8fI79gJEsRy3E8LHDpYXWQIgZpkJN9CMLG8ENR4Nrw+n7iyzixBvK= XX8P5 > 3BTCT4VghPBWhFYSt9tHWu/AtJfOTh6qaAsNdeCyG86jmtp3TDMwuL/cBUj2OtBZOQMFn7jQ9= YB7kl > Iz3RqVL+wNmeWI4=3D > =20 > The JWT might be optionally encrypted using JWE. > =20 > I think what is becoming clear (and this is what I=B9m trying to vet) is th= at > while there is nothing in OAuth that specifies authentication, it *can* b= e > used for Authentication, if done in the way that I describe. If I=B9m wron= g > about this, I really need to know. I=B9ve vetted this idea of mine with qu= ite > of few people now =AD both within context of the list and off-line =AD and I = think > I=B9m okay. If you see any holes in what I describe, please point them out = as I > would prefer to uncover them now rather than after implementation or > deployment! > =20 > Essentially I=B9m using OAuth as a RESTful version of WS-Trust, where my cl= ient > can exchange primary credentials for a token (JWT) and present that token= to a > server as secondary authentication. It=B9s just that it=B9s RESTful instead = of > SOAP :-) > =20 > As Justin as pointed out =8A I=B9ve basically made the access-token look like= the > id_token of Connect. I was actually hoping to lay a path to Connect, and= use > the id_token =8A until it was also pointed out that the id_token is really = meant > for the consumption of the client, not the RS :-( > =20 > =20 > =20 >=20 > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of= Igor > Faynberg > Sent: Wednesday, June 20, 2012 2:39 PM > To: oauth@ietf.org >=20 >=20 > Subject: Re: [OAUTH-WG] Report an authentication issue > =20 > But this use case does need OAuth, period: >=20 >=20 >=20 > The video server is under the control of a police agency, and police offi= cers > must logon to the video server in order to access video content. >=20 > There is no delegation here, and there is no need to use third party for > authentication.=20 >=20 > Igor >=20 > On 6/20/2012 3:26 PM, Justin Richer wrote: >=20 > In case it wasn't clear, I want to restate the original problem as best a= s I > understand it in a way that hopefully clears it up: >=20 > App A and app B are both valid registered OAuth clients to an OAuth prote= cted > service.=20 >=20 > The problem starts when app A gets handed a token that was issued for app= B > and uses it to call an identity API on the OAuth service. Since app B can= get > tokens just fine, they're bearer tokens, this is a fairly basic api call,= this > function works just fine and returns the user info. This makes sense, sin= ce > anyone who holds A's tokens can do whatever A can do on behalf of that us= er. > The issues start when app B then decides that since they can make a call = to > the identity API with a token then the user *must* be present. In other w= ords, > app B is confusing authorization to call an API with authentication of th= e > session. >=20 > OpenID Connect fixes this missed assumption by binding the ID Token to th= e > session and sending it along side the access token, but as you pointed ou= t, > it's meant for consumption at the client, not the resource server, in gen= eral. > That doesn't mean you can't send it to a resource server for your own > purposes, of course. That's actually how the session management endpoint = works > in Connect. >=20 > This isn't the only way to handle this problem -- if you put some structu= re in > your tokens, such as with JWT or SAML, then app A can tell that this isn'= t a > token issued to app A, but to app B, so it can call shenanigans and rejec= t it > then and there. >=20 > -- Justin >=20 > On 06/20/2012 10:03 AM, Lewis Adam-CAL022 wrote: > I am entirely confused. > =20 > I understand what everybody is saying for confidential clients, no proble= m > here. > =20 > I fall apart when thinking of iPhone apps. Consider the scenario where I > deploy a video server, and write an iPhone app to talk to the video serve= r. > The video server is under the control of a police agency, and police offi= cers > must logon to the video server in order to access video content. So the > police office launches their iPhone video client app. > =20 > If I wanted to solve authentication using =B3traditional=B2 client-server > authentication, the user enters their username / password into the client= , and > the client sends the username / password off to the server, which > authenticates it, or possibly uses HTTP digest. >=20 > If I wanted to use OpenID, the client would attempt to reach the video se= rver > (RP), the server would redirect the client to the OP, OP authenticates us= er, > and OP redirects client back to the server/RP with an assertion that prim= ary > authentication was successful. >=20 > If I wanted to use OAuth, the client would send an authorization request = to > the server=B9s AS, which would authenticate the user of the client, and > ultimately result in the client possessing an access-token. My thinking = is > that this access token (let=B9s assume it=B9s a JWT) would contain the user=B9s > identity, a statement of what type of primary authentication was used (au= th > context), an expiration, and an audience claim. This sounds a lot like > authentication to me, and it=B9s where I get confused. Is it just because = OAuth > does not explicitly define this? Is there a threat in using OAuth as I > describe?=20 >=20 > If I wanted to use Connect, well I=B9m not even sure how the id_token as de= fined > by Connect helps this use case. The id_token seems to make sense when th= e > client is a confidential web server, but it=B9s not clear what an iPhone ap= p > would do with the id_token =8A it=B9s the server in the backend that needs to > authenticate the user, the iPhone app is just an interface to talk to the > server. And it seems as I learn more about connect that the id_token is = not > meant to be sent from the iPhone app to the server, just the access token= . So > it=B9s really not clear how Connect helps solve authentication for an iPhon= e > client app talking to a video server. If I=B9m sending access-tokens, it=B9s= just > OAuth again. >=20 > =20 > What am I still missing? > adam > =20 > =20 >=20 > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of > Kristofor Selden > Sent: Saturday, June 16, 2012 11:33 AM > To: nov matake; oauth > Cc: Yuchen Zhou; Luke Melia; Shuo Chen (MSR) > Subject: Re: [OAUTH-WG] Report an authentication issue > =20 >=20 > Nov demonstrated the problem to us at Yapp and we used solution 4 (becaus= e the > solution is server side and our app was in the app store). >=20 > =20 >=20 > FB Connect is authentication and authorization, where OAuth 2 is concerne= d > only with authorization =AD I'm not sure that app developers appreciate thi= s > subtlety. >=20 > =20 >=20 > With OAuth 2 you authorize an app to use a protected resource. With FB > Connect, you do that, but also authenticate with the app you are authoriz= ing. >=20 > =20 >=20 > So the access_token protects not just the FB resources but the auth end p= oint > of the authorized app (very common with apps that use the iOS SDK). So n= ow > the app needs a way to verify that it was the app that was authorized to = FB. >=20 > =20 >=20 > Solution 4 explanation: on FB you can register a iPhone app and a server = app > with the same client_id and get a client_secret for use on the server. T= he > server side API posts the access_token, client_id, and client_secret to > https://graph.facebook.com/app > to verify that = the > bearer token actually belongs to the app that is being authenticated befo= re > assuming they are authorized to the app's protected resources. >=20 > =20 >=20 > Kris > =20 >=20 > On Jun 15, 2012, at 8:22 PM, nov matake wrote: >=20 >=20 > There are 4 ways to fix this issue. >=20 > =20 >=20 > 1. Use response_type=3Dtoken%20code (It's not in OAuth 2.0 Core, but seems = best > way for interoperability) >=20 > 2. Use singed_request (or some signed token like JWT) >=20 > 3. Use grant_type=3Dfb_exchange_token (Facebook custom way) >=20 > 4. Access to https://graph.facebook.com/app?access_token=3DYOUR_TOKEN (Face= book > custom way, moreover undocumented API) >=20 > =20 >=20 > Two iPhone app developers I reported this issue fixed it by using (4). >=20 > =20 >=20 > I also tried to use (1) for my own iPhone app implementation, but > unfortunately it doesn't work when using authorization codes obtained via= FB > iOS SDK. >=20 > So I'm using (3) in my case. >=20 > =20 >=20 > nov >=20 > =20 >=20 > On 2012/06/16, at 9:16, Nat Sakimura wrote: >=20 >=20 >=20 > As to how the fix was done, Nov can provide more detail, but ... >=20 > =20 >=20 > 1. Properly verify the signature/HMAC of the "signed_request". This will > essentially audience restricts the token. >=20 > 2. There is an undocumented API for Facebook which returns to whom the to= ken > was issued. This also audience restricts the token. >=20 > =20 >=20 > The service that fixed took these measures. Note that none of the above i= s > defined in OAuth. >=20 > The same facility was called "id_token" and "check ID endpoint" for OpenI= D > Connect.=20 >=20 > =20 >=20 > The scale of the impact is large, too large to disclose the actual names = in > the public list, though, eventually, we would publish them in a paper. >=20 > =20 >=20 > Nat >=20 > On Sat, Jun 16, 2012 at 5:34 AM, Francisco Corella > wrote: >=20 > Hi Nat and Rui, >=20 > Rui, you say that the vulnerability that you found was due to a > "common misunderstanding among developers", but the attack you > describe can be carried out against any app that uses the OAuth > "implicit grant flow", which Facebook calls "client-side > authentication". No misunderstanding seems necessary. What > misunderstanding are you referring to? I followed the link in your > message to the Sophos post, and from there the link to the article in > The Register. The article in The Register says that Facebook had > "fixed the vulnerability promptly". How did they fix it? The > instructions that Facebook provides for implementing "Client-side > authentication without the JS SDK" at > https://developers.facebook.com/docs/authentication/client-side/#no-jssdk > still allows the attack. >=20 > Nat, I agree that the blog post by John Bradley that you link to > refers to the same vulnerability reported by Rui. You say that some > apps have issued a patch to fix it. Could you explain what the fix > was? >=20 > Francisco >>=20 >> =20 >>=20 >>=20 >> From: Nat Sakimura >> To: rui wang >> Cc: matake nov ; Yuchen Zhou ; oa= uth >> ; Shuo Chen (MSR) >> Sent: Thursday, June 14, 2012 1:50 PM >> Subject: Re: [OAUTH-WG] Report an authentication issue >>=20 >> =20 >>=20 >> This is a fairly well known (hopefully by now) issue. We, at the OpenID >> Foundation, call it "access_token phishing" attack these days. See: >> http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication= .html >>=20 >> =20 >>=20 >> Nov Matake has actually built the code on iPhone to verify the problem, = and >> has notified bunch of parties back in February including Facebook and Ap= ple. >> We have the code that actually runs on a phone, and we have successfully >> logged in to bunch of apps, including very well known ones. They were al= l >> informed of the issue. Some immediately issued a patch to fix it while o= thers >> have not. =20 >>=20 >> =20 >>=20 >> The problem is that even if these apps gets fixed, the problem does not = go >> away. As long as the attacker has the vulnerable version of the app, he = still >> can impersonate the victim. To stop it, the server side has to completel= y >> disable the older version, which means the service has to cut off many u= sers >> pausing business problems. >>=20 >> =20 >>=20 >> Nat >>=20 >> On Fri, Jun 15, 2012 at 2:18 AM, rui wang wrote: >>=20 >> Dear Facebook Security Team and OAuth Standard group, >>=20 >> We are a research team in Microsoft Research. In January, 2011, we repor= ted a >> vulnerability in Facebook Connect which allowed everyone to sign into >> Facebook-secured relying parties without password. It was promptly fixed >> after reporting. >> (http://nakedsecurity.sophos.com/2011/02/02/facebook-flaw-websites-steal= -pers >> onal-data/) >>=20 >> Recently, we found a common misunderstanding among developers of mobile/= metro >> apps when using OAuth (including Facebook=B9s OAuth) for authentication. T= he >> vulnerability resulted from this misunderstanding also allows an attacke= r to >> log into a victim user's account without password. >>=20 >> Let's take Soluto's metro app as an example to describe the problem. The= app >> supports Facebook Login. As an attacker, we can write a regular Facebook= app. >> Once the victim user allows our app to access her Facebook data, we rece= ive >> an access_token from the traffic. Then, on our own machine (i.e., the >> "attacker" machine), we run the metro app of Soluto, and use a HTTP prox= y to >> insert the victim's access_token into the traffic of Facebook login. Thr= ough >> this way, we are able to log into the victim's Soluto account from our >> machine. Other than Soluto, we also have confirmed the same issue on ano= ther >> Windows 8 metro-app Givit. >>=20 >> The Facebook SDK for Android apps >> (https://developers.facebook.com/docs/mobile/android/build/#sdk) seems t= o >> have the possibility to mislead developers too. At least, the issue that= we >> found is not clearly mentioned. In the SDK, we ran the sample code calle= d >> "Hackbook" using Android Emulator (imagine it is an attacker device). No= te >> that we have already received the access token of the victim user from o= ur >> regular Facebook app. We then inject the token to the traffic of Hackboo= k. >> Through this way, Hackbook app on our own machine recognizes us as the >> victim. Note that this is not a convincing security exploit yet, because= this >> sample code does not include the server-side code. However, given that w= e >> have seen real server-side code having this problem, such as Soluto, Giv= it >> and others, we do believe that the sample code can mislead mobile/metro >> developers. We also suspect that this may be a general issue of many OAu= th >> implementations on mobile platforms, so we send this message to OAuth >> Standard group as well. >>=20 >> We have contacted the vendors of the two vulnerable metro-apps, Soluto a= nd >> Gavit. >>=20 >> Please kindly give us an ack when you receive this message. If you want = to >> know more details, please let us know. >>=20 >> Best Regards, >> Yuchen Zhou, Rui Wang, and Shuo Chen >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >> =20 --B_3423209341_55113855 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [OAUTH-WG] Report an authentication issue Hi Adam,

It takes a document to add new functionality to Oauth. Just write one and s= ubmit it to the group.

Ciao
Hannes


On 6/21/12 7:01 PM, "ext Lewis Adam-CAL022" <Adam.Lewis@motorolasolutions.com> wrote:
<= SPAN STYLE=3D'font-size:12pt'>Hi Nat,
 
I’m beginning to wonder what it would take to add a new profile of so= rts to either OAuth or Connect.
 
In the beginning there was SOAP, and the preferred method to secure SOAP AP= I calls was WS-Trust.
 
Now the world is moving toward RESTful APIs … and the preferred means= to secure RESTful APIs is OAuth.
 
Except that OAuth is clearly written with the idea that the protected resou= rces belong to the end user.
 
My use cases – and I imagine the use cases of many other enterprises = – is that the Owner of the resources is the Enterprise.  An emplo= yee is trying to access a database or video resources.  The enterprise = RS needs to be able to 1) identify the user, and 2) make authorization decis= ions based on what roles that user has within the enterprise.  So in my= scenario, when a police officer attempts to access a criminal records datab= ase, the database needs to know who that officer is, and then decide if they= have privilege to access the database, and at what level (e.g. CRUD).
 
WS-Trust fits this model well.  The user performs primary authenticati= on to the enterprise STS, which then grants the application client a SAML as= sertion.  When the user attempts to access a records database, the SAML= assertion is included in the SOAP message.  The records server authent= icates the user based on the SAML assertion and makes its authorization deci= sions.
 
This is the world I’m trying to migrate from, and it really seems lik= e I’m sometimes trying to make a square peg fit in a round hole.  = ;I’m looking for OAuth/Connect to do for REST what WS-TRUST did for SO= AP.  I would like a native client talking to a RS to be able to ask for= an id_token, and then pass that id_token to the RS when making its RESTful = API calls, to enable the RS to authenticate the user.  I think that thi= s would be really useful for a lot of people besides me.  I keep hearin= g that there is nothing “preventing” me from doing this … = but it hardly seems within the spirit of what OAuth was meant to do.  T= he id_token was clearly meant to enable a user to authenticate to a confiden= tial client  / web server … but was not meant for a native client= to identity / authenticate the user to a RS.
 
 
Would there be any interest in exploring this further?
-adam
 
 

From: Nat Sakimur= a [mailto:sakimura@gmail.com]
Sent: Wednesday, June 20, 2012 8:09 PM
To: Lewis Adam-CAL022
Cc: igor.faynberg@alcatel= -lucent.com; oauth@ietf.org
Subject: Re: [OAUTH-WG] Report an authentication issue
Yes, OAuth can be profiled to enable authentication.

In = fact, initial draft of OpenID Connect was just like you described.

Ess= entially, we were using structured access_token.

Lat= er, we decided to separate the access token and id_token for several reasons= such as:

  1. Better interop with existing OAuth implementations: by introducing id_t= oken, they do not need to touch the supposedly opaque (which means AS-RS may= be doing some proprietary thing inside it) access token.=20
  2. Mixing up the audience (for id_token aka authn =3D client, and for access_tok= en aka authz =3D resource server) probably is expanding the attack surface for= security and privacy.
Although we separated them out, a signed id_token includes the left hash o= f access_token so access_token is also protected.


Bes= t,


Nat=


On = Thu, Jun 21, 2012 at 5:21 AM, Lewis Adam-CAL022 <Adam.Lewis@motorolasolutions.com> wrote:

Hi Igor,
 
As Justin just pointed out, consider the case where the video server is hos= ted by the state (e.g. California) and is accessed by police agencies in Los= Angeles, San Francisco, and San Diego.  The State of California’= s video server is the RS.  Each local police agency (LA/SF/SD) hosts an= AS.  So when a police officer from LAPD launches the video client app = on the iPhone, the client makes an OAuth request to the LAPD’s AS, whi= ch authenticates the police officer using agency level credentials.  Th= e access token issued to the video client app on the iPhone is a JWT, signed= by the agency AS, which might look something like this:
 
{“typ”:”JWT”,"alg":"ES256"}
{"iss":"https://as.= lapd.california.gov",
  "prn":"alice= @lapd.california.gov",
  "aud":" https://video_server1@state.california.gov",
  "iat":1300815780,
  "exp":1300819380,
  "acr":”password”}
hq4zk+ZknjggCQgZm7ea8fI79gJEsRy3E8LHDpYXWQIgZpkJN9CMLG8ENR4Nrw+n7iyzixBvKXX= 8P53BTCT4VghPBWhFYSt9tHWu/AtJfOTh6qaAsNdeCyG86jmtp3TDMwuL/cBUj2OtBZOQMFn7jQ9= YB7klIz3RqVL+wNmeWI4=3D
 
The JWT might be optionally encrypted using JWE.
 
I think what is becoming clear (and this is what I’m trying to vet) i= s that while there is nothing in OAuth that specifies authentication, it *can* be used for Authentication, if done in the way that I describe. &n= bsp;If I’m wrong about this, I really need to know.  I’ve v= etted this idea of mine with quite of few people now – both within con= text of the list and off-line – and I think I’m okay. If you see= any holes in what I describe, please point them out as I would prefer to un= cover them now rather than after implementation or deployment!
 
Essentially I’m using OAuth as a RESTful version of WS-Trust, where m= y client can exchange primary credentials for a token (JWT) and present that= token to a server as secondary authentication.  It’s just that i= t’s RESTful instead of SOAP :-)
 
As Justin as pointed out … I’ve basically made the access-token= look like the id_token of Connect.  I was actually hoping to lay a pat= h to Connect, and use the id_token … until it was also pointed out tha= t the id_token is really meant for the consumption of the client, not the RS= :-(
 
 
 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Igor Fa= ynberg
Sent: Wednesday, June 20, 2012 2:39 PM
To: oauth@ietf.org

 Subject: Re: [OAUTH-WG] Report an authentication issue
 
But this use case  does need OAuth, period:
The video server is under the control of a police agency, an= d police officers must logon to the video server in order to access video co= ntent.

There is no delegation here, and there is no need to use third party for au= thentication.

Igor

On 6/20/2012 3:26 PM, Justin Richer wrote:

In = case it wasn't clear, I want to restate the original problem as best as I un= derstand it in a way that hopefully clears it up:

App A and app B are both valid registered OAuth clients to an OAuth protect= ed service.

The problem starts when app A gets handed a token that was issued for app B= and uses it to call an identity API on the OAuth service. Since app B can g= et tokens just fine, they're bearer tokens, this is a fairly basic api call,= this function works just fine and returns the user info. This makes sense, = since anyone who holds A's tokens can do whatever A can do on behalf of that= user. The issues start when app B then decides that since they can make a c= all to the identity API with a token then the user *must* be present. In oth= er words, app B is confusing authorization to call an API with authenticatio= n of the session.

OpenID Connect fixes this missed assumption by binding the ID Token to the = session and sending it along side the access token, but as you pointed out, = it's meant for consumption at the client, not the resource server, in genera= l. That doesn't mean you can't send it to a resource server for your own pur= poses, of course. That's actually how the session management endpoint works = in Connect.

This isn't the only way to handle this problem -- if you put some structure= in your tokens, such as with JWT or SAML, then app A can tell that this isn= 't a token issued to app A, but to app B, so it can call shenanigans and rej= ect it then and there.

 -- Justin

On 06/20/2012 10:03 AM, Lewis Adam-CAL022 wrote:
I am entirely confused.
 
I understand what everybody is saying for confidential clients, no problem = here.
 
I fall apart when thinking of iPhone apps.  Consider the scenario wher= e I deploy a video server, and write an iPhone app to talk to the video serv= er.  The video server is under the control of a police agency, and poli= ce officers must logon to the video server in order to access video content.=  So the police office launches their iPhone video client app.
 
If I wanted to solve authentication using “traditional” client-= server authentication, the user enters their username / password into the cl= ient, and the client sends the username / password off to the server, which = authenticates it, or possibly uses HTTP digest.

If I wanted to use OpenID, the client would attempt to reach the video serv= er (RP), the server would redirect the client to the OP, OP authenticates us= er, and OP redirects client back to the server/RP with an assertion that pri= mary authentication was successful.

If I wanted to use OAuth, the client would send an authorization request to= the server’s AS, which would authenticate the user of the client, and= ultimately result in the client possessing an access-token.  My thinki= ng is that this access token (let’s assume it’s a JWT) would con= tain the user’s identity, a statement of what type of primary authenti= cation was used (auth context), an expiration, and an audience claim.  = This sounds a lot like authentication to me, and it’s where I get conf= used.  Is it just because OAuth does not explicitly define this?  = Is there a threat in using OAuth as I describe?

If I wanted to use Connect, well I’m not even sure how the id_token a= s defined by Connect helps this use case.  The id_token seems to make s= ense when the client is a confidential web server, but it’s not clear = what an iPhone app would do with the id_token … it’s the server = in the backend that needs to authenticate the user, the iPhone app is just a= n interface to talk to the server.  And it seems as I learn more about = connect that the id_token is not meant to be sent from the iPhone app to the= server, just the access token.  So it’s really not clear how Con= nect helps solve authentication for an iPhone client app talking to a video = server.  If I’m sending access-tokens, it’s just OAuth agai= n.
What am I still missing?
adam
 
 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Kristof= or Selden
Sent: Saturday, June 16, 2012 11:33 AM
To: nov matake; oauth
Cc: Yuchen Zhou; Luke Melia; Shuo Chen (MSR)
Subject: Re: [OAUTH-WG] Report an authentication issue

Nov= demonstrated the problem to us at Yapp and we used solution 4 (because the = solution is server side and our app was in the app store).
FB = Connect is authentication and authorization, where OAuth 2 is concern= ed only with authorization – I'm not sure that app developers apprecia= te this subtlety.
Wit= h OAuth 2 you authorize an app to use a protected resource.  With FB Co= nnect, you do that, but also authenticate with the app you are author= izing.
So = the access_token protects not just the FB resources but the auth end point o= f the authorized app (very common with apps that use the iOS SDK).  So = now the app needs a way to verify that it was the app that was authorized to= FB.
Sol= ution 4 explanation: on FB you can register a iPhone app and a server app wi= th the same client_id and get a client_secret for use on the server.  T= he server side API posts the access_token, client_id, and client_secret to <= a href=3D"https://graph.facebook.com/app">https://graph.facebook.com/app &= lt;https://= graph.facebook.com/app?access_token=3DYOUR_TOKEN>  to verify that = the bearer token actually belongs to the app that is being authenticated bef= ore assuming they are authorized to the app's protected resources.
Kri= s
 

On = Jun 15, 2012, at 8:22 PM, nov matake wrote:


There are 4 ways to fix this issue.
1. = Use response_type=3Dtoken%20code (It's not in OAuth 2.0 Core, but seems best w= ay for interoperability)

2. = Use singed_request (or some signed token like JWT)

3. = Use grant_type=3Dfb_exchange_token (Facebook custom way)

4. = Access to h= ttps://graph.facebook.com/app?access_token=3DYOUR_TOKEN (Facebook custom w= ay, moreover undocumented API)
Two= iPhone app developers I reported this issue fixed it by using (4).
I a= lso tried to use (1) for my own iPhone app implementation, but unfortunately= it doesn't work when using authorization codes obtained via FB iOS SDK.

So = I'm using (3) in my case.
nov=


On = 2012/06/16, at 9:16, Nat Sakimura wrote:



As = to how the fix was done, Nov can provide more detail, but ...


1. = Properly verify the signature/HMAC of the "signed_request". This w= ill essentially audience restricts the token.

2. = There is an undocumented API for Facebook which returns to whom the token wa= s issued. This also audience restricts the token.


The= service that fixed took these measures. Note that none of the above is defi= ned in OAuth.

The= same facility was called "id_token" and "check ID endpoint&q= uot; for OpenID Connect.


The= scale of the impact is large, too large to disclose the actual names in the= public list, though, eventually, we would publish them in a paper.


Nat=

On = Sat, Jun 16, 2012 at 5:34 AM, Francisco Corella <fcorella@pomcor.com> wrote:

Hi Nat and Rui,

Rui, you say that the vulnerability that you found was due to a
"common misunderstanding among developers", but the attack you describe can be carried out against any app that uses the OAuth
"implicit grant flow", which Facebook calls "client-side
authentication".  No misunderstanding seems necessary.  What=
misunderstanding are you referring to?  I followed the link in your message to the Sophos post, and from there the link to the article in
The Register.  The article in The Register says that Facebook had
"fixed the vulnerability promptly".  How did they fix it? &n= bsp;The
instructions that Facebook provides for implementing "Client-side
authentication without the JS SDK" at
https://developers.facebook.com/docs/authentication/client-side/#no= -jssdk
still allows the attack.

Nat, I agree that the blog post by John Bradley that you link to
refers to the same vulnerability reported by Rui.  You say that some apps have issued a patch to fix it.  Could you explain what the fix was?

Francisco
<= SPAN STYLE=3D'font-size:11pt'>

From: Nat Sakimura <sakimura@gmail.= com>
To: rui wang <ruiwangwarm@gmail.c= om>
Cc: matake nov <nov@matake.jp>; Yu= chen Zhou <t-yuzhou@microsoft.com>= ;; oauth <oauth@ietf.org>; Shuo Chen (MSR= ) <shuochen@microsoft.com>
Sent: Thursday, June 14, 2012 1:50 PM
Subject: Re: [OAUTH-WG] Report an authentication issue
Thi= s is a fairly well known (hopefully by now) issue. We, at the OpenID Foundat= ion, call it "access_token phishing" attack these days. See: http://www.thread-safe.com/2012/01/problem-with-oauth-for-authenticat= ion.html
Nov= Matake has actually built the code on iPhone to verify the problem, and has= notified bunch of parties back in February including Facebook and Apple. We= have the code that actually runs on a phone, and we have successfully logge= d in to bunch of apps, including very well known ones. They were all informe= d of the issue. Some immediately issued a patch to fix it while others have = not.  
The= problem is that even if these apps gets fixed, the problem does not go away= . As long as the attacker has the vulnerable version of the app, he still ca= n impersonate the victim. To stop it, the server side has to completely disa= ble the older version, which means the service has to cut off many users pau= sing business problems.


Nat=

On = Fri, Jun 15, 2012 at 2:18 AM, rui wang <r= uiwangwarm@gmail.com> wrote:

Dea= r Facebook Security Team and OAuth Standard group,

We = are a research team in Microsoft Research. In January, 2011, we reported a v= ulnerability in Facebook Connect which allowed everyone to sign into Faceboo= k-secured relying parties without password. It was promptly fixed after repo= rting. (http://nakedsecurity.sophos.com/2011/02/02/face= book-flaw-websites-steal-personal-data/)

Rec= ently, we found a common misunderstanding among developers of mobile/metro a= pps when using OAuth (including Facebook’s OAuth) for authentication. = The vulnerability resulted from this misunderstanding also allows an attacke= r to log into a victim user's account without password.

Let= 's take Soluto's metro app as an example to describe the problem. The app su= pports Facebook Login. As an attacker, we can write a regular Facebook app. = Once the victim user allows our app to access her Facebook data, we receive = an access_token from the traffic. Then, on our own machine (i.e., the "= attacker" machine), we run the metro app of Soluto, and use a HTTP prox= y to insert the victim's access_token into the traffic of Facebook login. Th= rough this way, we are able to log into the victim's Soluto account from our= machine. Other than Soluto, we also have confirmed the same issue on anothe= r Windows 8 metro-app Givit.

The= Facebook SDK for Android apps (https://developers.facebook.com/docs/mobile/and= roid/build/#sdk) seems to have the possibility to mislead developers too= . At least, the issue that we found is not clearly mentioned. In the SDK, we= ran the sample code called "Hackbook" using Android Emulator (ima= gine it is an attacker device). Note that we have already received the acces= s token of the victim user from our regular Facebook app. We then inject the= token to the traffic of Hackbook. Through this way, Hackbook app on our own= machine recognizes us as the victim. Note that this is not a convincing sec= urity exploit yet, because this sample code does not include the server-side= code. However, given that we have seen real server-side code having this pr= oblem, such as Soluto, Givit and others, we do believe that the sample code = can mislead mobile/metro developers. We also suspect that this may be a gene= ral issue of many OAuth implementations on mobile platforms, so we send this= message to OAuth Standard group as well.

We = have contacted the vendors of the two vulnerable metro-apps, Soluto and Gavi= t.

Ple= ase kindly give us an ack when you receive this message. If you want to know= more details, please let us know.

Bes= t Regards,
Yuchen Zhou, Rui Wang, and Shuo Chen

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


 

--B_3423209341_55113855-- From stephen.farrell@cs.tcd.ie Fri Jun 22 05:06:26 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2EEB21F86C3 for ; Fri, 22 Jun 2012 05:06:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lXl+XGnDu7zW for ; Fri, 22 Jun 2012 05:06:25 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id B436321F86B0 for ; Fri, 22 Jun 2012 05:06:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id F4031153673 for ; Fri, 22 Jun 2012 13:06:24 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1340366784; bh=DmgqJmBY9s9oDp 1G3ma96ok5LHrLOqz6LZxN8nWeu8M=; b=VZXTuO+ulOB49PxjM1k92kwezeFd/C R15/WjTFVPLLJL+clclaekOK0Qg9GXW+/LTBuQIAG5+U/TuYMCCk3SpG6PNIBndr sFgKvyXFBSz79kOnLvXc31jy7Hf8IwOJ/OyI6U0bMf7vafZsRqCog7jKvxeFFBlA 99xVXyE51fn5XtjtW4IYw1DU9EmVqytCzYKHzk5pqdUtFNklefORPkAZSobVddVX 8ghhkVAMttQ1B98C2FqJVTYltrB2ljp3ijhjEI8G/E7JUugt4lWzaJVufatLmVOu o3wocZo4vozJHZFi8xOyabpqBufslsR4OZh6WEcZHirgqxpFHfwy0y4Q== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id SrSO0nsjn+aD for ; Fri, 22 Jun 2012 13:06:24 +0100 (IST) Received: from [IPv6:2001:770:10:203:f0f5:71b4:f3f4:1af1] (unknown [IPv6:2001:770:10:203:f0f5:71b4:f3f4:1af1]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id AD399153672 for ; Fri, 22 Jun 2012 13:06:24 +0100 (IST) Message-ID: <4FE45FC1.3030007@cs.tcd.ie> Date: Fri, 22 Jun 2012 13:06:25 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: OAuth WG References: <20120621175317.32545.76545.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B1680429673943665637A0@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-urn-sub-ns-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, 22 Jun 2012 12:06:26 -0000 I'll wait until the chairs tell me what you want but I'm fine with doing the IETF LC on -03 now, or with waiting if the chairs reckon that's better. So just let me know. Cheers, S. From bcampbell@pingidentity.com Fri Jun 22 06:40:17 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C6AC21F8613 for ; Fri, 22 Jun 2012 06:40:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.006 X-Spam-Level: X-Spam-Status: No, score=-6.006 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id skspX+7y00tX for ; Fri, 22 Jun 2012 06:40:16 -0700 (PDT) Received: from na3sys009aog117.obsmtp.com (na3sys009aog117.obsmtp.com [74.125.149.242]) by ietfa.amsl.com (Postfix) with ESMTP id 9C79E21F85EA for ; Fri, 22 Jun 2012 06:40:16 -0700 (PDT) Received: from mail-qc0-f176.google.com ([209.85.216.176]) (using TLSv1) by na3sys009aob117.postini.com ([74.125.148.12]) with SMTP ID DSNKT+R1wOCVz5p932swyJUMRTt1rMec0l5X@postini.com; Fri, 22 Jun 2012 06:40:16 PDT Received: by qcsc21 with SMTP id c21so1079702qcs.35 for ; Fri, 22 Jun 2012 06:40:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=dQdTi9iKZBpGsHg+MOTpKVXdCuGc26Q7ZaLuUtRdFZ0=; b=O3/4+vYqDmdirkQ7elcyL2vNl89PdPUVZTNmyawFefZeO6eLbI2LUcQ1grubqsmQ6R AgER4kZluPMMiJqbtKShJq0x26h4mSGkclJKeeYEzE849lZYB4TjVRfb1EKf+mqnboRW uGRaxs4kwy1bzEE0paf141ZXznJbwkxqhogtQykXXOg58A2z8nMF6n7q8nT//yGWMcJy YdEjG70w3hGPSvKDMy64M1tkhzgnWi2JM3RHpX4gZ/dNPpgeGl/QMCQ1gJb7mDF+hB/R U68TVbEk+Rl2QV4JoE1vU98XMRZ8piioD4G2aHlY3KfLpNhovFYbHUl8fY1x7xfIB8hh botQ== Received: by 10.224.182.13 with SMTP id ca13mr6332702qab.60.1340372415447; Fri, 22 Jun 2012 06:40:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.87.142 with HTTP; Fri, 22 Jun 2012 06:39:45 -0700 (PDT) In-Reply-To: <4FE45FC1.3030007@cs.tcd.ie> References: <20120621175317.32545.76545.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B1680429673943665637A0@TK5EX14MBXC283.redmond.corp.microsoft.com> <4FE45FC1.3030007@cs.tcd.ie> From: Brian Campbell Date: Fri, 22 Jun 2012 07:39:45 -0600 Message-ID: To: Stephen Farrell Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlJSyIXW+d/lmJWeyAVWfjEvL95x3iMSBzUvw5Aom9bkPwSu7TOUDb00q4vp0G7TE/cGwhb Cc: OAuth WG Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-urn-sub-ns-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, 22 Jun 2012 13:40:17 -0000 Unless there are objections from the WG, I'd like to publish -04 today with two smallish changes (new text listed below) to address the question raised yesterday in http://www.ietf.org/mail-archive/web/oauth/current/msg09381.html and have -04 be the draft for LC. First paragraph of =A73: "If a registrant wishes to have a OAuth URI registered, then a URN of the form urn:ietf:params:oauth: will be requested where is a suitable representation of the functionality or concept being registered." Index value bullet of =A75.1 "Index value: values subordinate to urn:ietf:params:oauth are of the from urn:ietf:params:oauth: with as the index value. It is suggested that include both a "class" and an "identifier-within-class" component, with the two components being separated by a colon (":"); other compositions of the may also be used. Thanks, Brian On Fri, Jun 22, 2012 at 6:06 AM, Stephen Farrell wrote: > > I'll wait until the chairs tell me what you want > but I'm fine with doing the IETF LC on -03 now, or > with waiting if the chairs reckon that's better. > So just let me know. > > Cheers, > S. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From stpeter@stpeter.im Fri Jun 22 08:13:04 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5509921F8724 for ; Fri, 22 Jun 2012 08:12:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.457 X-Spam-Level: X-Spam-Status: No, score=-102.457 tagged_above=-999 required=5 tests=[AWL=0.142, 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 6sF0MaIrx9nv for ; Fri, 22 Jun 2012 08:12:58 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 1E84B21F8715 for ; Fri, 22 Jun 2012 08:12:58 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 8A91040092; Fri, 22 Jun 2012 09:30:38 -0600 (MDT) Message-ID: <4FE48B78.3000405@stpeter.im> Date: Fri, 22 Jun 2012 09:12:56 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120601 Thunderbird/13.0 MIME-Version: 1.0 To: Brian Campbell References: <20120621175317.32545.76545.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B1680429673943665637A0@TK5EX14MBXC283.redmond.corp.microsoft.com> <4FE45FC1.3030007@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: OAuth WG Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-urn-sub-ns-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, 22 Jun 2012 15:13:04 -0000 On 6/22/12 7:39 AM, Brian Campbell wrote: > Unless there are objections from the WG, I'd like to publish -04 today > with two smallish changes (new text listed below) to address the > question raised yesterday in > http://www.ietf.org/mail-archive/web/oauth/current/msg09381.html and > have -04 be the draft for LC. > > First paragraph of §3: > "If a registrant wishes to have a OAuth URI registered, then a URN of > the form urn:ietf:params:oauth: will be requested where > is a suitable representation of the functionality or concept > being registered." > > Index value bullet of §5.1 > "Index value: values subordinate to urn:ietf:params:oauth are of > the from urn:ietf:params:oauth: with as the index > value. It is suggested that include both a "class" and an > "identifier-within-class" component, with the two components being > separated by a colon (":"); other compositions of the may > also be used. WFM. Peter -- Peter Saint-Andre https://stpeter.im/ From cmortimore@salesforce.com Fri Jun 22 08:15:20 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4677821F8747 for ; Fri, 22 Jun 2012 08:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id unt1lFrHXeI7 for ; Fri, 22 Jun 2012 08:15:10 -0700 (PDT) Received: from psmtp.com (exprod8ob105.obsmtp.com [64.18.3.89]) by ietfa.amsl.com (Postfix) with SMTP id 949DE21F8743 for ; Fri, 22 Jun 2012 08:15:09 -0700 (PDT) Received: from exsfm-hub5.internal.salesforce.com ([204.14.239.233]) by exprod8ob105.postini.com ([64.18.7.12]) with SMTP ID DSNKT+SL/cKK0zHiLjuUCNHAcgfp6jjafRwO@postini.com; Fri, 22 Jun 2012 08:15:09 PDT Received: from EXSFM-MB03.internal.salesforce.com ([10.1.127.58]) by exsfm-hub5.internal.salesforce.com ([10.1.127.5]) with mapi; Fri, 22 Jun 2012 08:15:09 -0700 From: Chuck Mortimore To: Hannes Tschofenig Date: Fri, 22 Jun 2012 08:15:02 -0700 Thread-Topic: [OAUTH-WG] Report an authentication issue Thread-Index: Ac1Qic7mQ6l+bX+OSkGiyy7VSGUjQQ== 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_B8063282B7CD4C80ADE9FE23ED3289F5salesforcecom_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Report an authentication issue X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 15:15:20 -0000 --_000_B8063282B7CD4C80ADE9FE23ED3289F5salesforcecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSdtIG5vdCBjb252aW5jZWQgYSBuZXcgZG9jdW1lbnQgaXMgcmVxdWlyZWQuICAgVGhpcyBpcyBi YXNpY2FsbHkgZGVzY3JpYmluZyBob3cgb3V0IE9BdXRoIGRlcGxveW1lbnQgd29ya3MsIHdpdGgg dGhlIGV4Y2VwdGlvbiB0aGF0IG91ciB0b2tlbiBmb3JtYXQgaXMgb3BhcXVlLg0KDQpOb3RoaW5n IHNlZW1zIG5ldy4NCg0KLSBjbW9ydA0KDQpPbiBKdW4gMjIsIDIwMTIsIGF0IDE6MjkgQU0sICJI YW5uZXMgVHNjaG9mZW5pZyIgPGhhbm5lcy50c2Nob2ZlbmlnQG5zbi5jb208bWFpbHRvOmhhbm5l cy50c2Nob2ZlbmlnQG5zbi5jb20+PiB3cm90ZToNCg0KSGkgQWRhbSwNCg0KSXQgdGFrZXMgYSBk b2N1bWVudCB0byBhZGQgbmV3IGZ1bmN0aW9uYWxpdHkgdG8gT2F1dGguIEp1c3Qgd3JpdGUgb25l IGFuZCBzdWJtaXQgaXQgdG8gdGhlIGdyb3VwLg0KDQpDaWFvDQpIYW5uZXMNCg0KDQpPbiA2LzIx LzEyIDc6MDEgUE0sICJleHQgTGV3aXMgQWRhbS1DQUwwMjIiIDxBZGFtLkxld2lzQG1vdG9yb2xh c29sdXRpb25zLmNvbT4gd3JvdGU6DQoNCkhpIE5hdCwNCg0KSeKAmW0gYmVnaW5uaW5nIHRvIHdv bmRlciB3aGF0IGl0IHdvdWxkIHRha2UgdG8gYWRkIGEgbmV3IHByb2ZpbGUgb2Ygc29ydHMgdG8g ZWl0aGVyIE9BdXRoIG9yIENvbm5lY3QuDQoNCkluIHRoZSBiZWdpbm5pbmcgdGhlcmUgd2FzIFNP QVAsIGFuZCB0aGUgcHJlZmVycmVkIG1ldGhvZCB0byBzZWN1cmUgU09BUCBBUEkgY2FsbHMgd2Fz IFdTLVRydXN0Lg0KDQpOb3cgdGhlIHdvcmxkIGlzIG1vdmluZyB0b3dhcmQgUkVTVGZ1bCBBUElz IOKApiBhbmQgdGhlIHByZWZlcnJlZCBtZWFucyB0byBzZWN1cmUgUkVTVGZ1bCBBUElzIGlzIE9B dXRoLg0KDQpFeGNlcHQgdGhhdCBPQXV0aCBpcyBjbGVhcmx5IHdyaXR0ZW4gd2l0aCB0aGUgaWRl YSB0aGF0IHRoZSBwcm90ZWN0ZWQgcmVzb3VyY2VzIGJlbG9uZyB0byB0aGUgZW5kIHVzZXIuDQoN Ck15IHVzZSBjYXNlcyDigJMgYW5kIEkgaW1hZ2luZSB0aGUgdXNlIGNhc2VzIG9mIG1hbnkgb3Ro ZXIgZW50ZXJwcmlzZXMg4oCTIGlzIHRoYXQgdGhlIE93bmVyIG9mIHRoZSByZXNvdXJjZXMgaXMg dGhlIEVudGVycHJpc2UuICBBbiBlbXBsb3llZSBpcyB0cnlpbmcgdG8gYWNjZXNzIGEgZGF0YWJh c2Ugb3IgdmlkZW8gcmVzb3VyY2VzLiAgVGhlIGVudGVycHJpc2UgUlMgbmVlZHMgdG8gYmUgYWJs ZSB0byAxKSBpZGVudGlmeSB0aGUgdXNlciwgYW5kIDIpIG1ha2UgYXV0aG9yaXphdGlvbiBkZWNp c2lvbnMgYmFzZWQgb24gd2hhdCByb2xlcyB0aGF0IHVzZXIgaGFzIHdpdGhpbiB0aGUgZW50ZXJw cmlzZS4gIFNvIGluIG15IHNjZW5hcmlvLCB3aGVuIGEgcG9saWNlIG9mZmljZXIgYXR0ZW1wdHMg dG8gYWNjZXNzIGEgY3JpbWluYWwgcmVjb3JkcyBkYXRhYmFzZSwgdGhlIGRhdGFiYXNlIG5lZWRz IHRvIGtub3cgd2hvIHRoYXQgb2ZmaWNlciBpcywgYW5kIHRoZW4gZGVjaWRlIGlmIHRoZXkgaGF2 ZSBwcml2aWxlZ2UgdG8gYWNjZXNzIHRoZSBkYXRhYmFzZSwgYW5kIGF0IHdoYXQgbGV2ZWwgKGUu Zy4gQ1JVRCkuDQoNCldTLVRydXN0IGZpdHMgdGhpcyBtb2RlbCB3ZWxsLiAgVGhlIHVzZXIgcGVy Zm9ybXMgcHJpbWFyeSBhdXRoZW50aWNhdGlvbiB0byB0aGUgZW50ZXJwcmlzZSBTVFMsIHdoaWNo IHRoZW4gZ3JhbnRzIHRoZSBhcHBsaWNhdGlvbiBjbGllbnQgYSBTQU1MIGFzc2VydGlvbi4gIFdo ZW4gdGhlIHVzZXIgYXR0ZW1wdHMgdG8gYWNjZXNzIGEgcmVjb3JkcyBkYXRhYmFzZSwgdGhlIFNB TUwgYXNzZXJ0aW9uIGlzIGluY2x1ZGVkIGluIHRoZSBTT0FQIG1lc3NhZ2UuICBUaGUgcmVjb3Jk cyBzZXJ2ZXIgYXV0aGVudGljYXRlcyB0aGUgdXNlciBiYXNlZCBvbiB0aGUgU0FNTCBhc3NlcnRp b24gYW5kIG1ha2VzIGl0cyBhdXRob3JpemF0aW9uIGRlY2lzaW9ucy4NCg0KVGhpcyBpcyB0aGUg d29ybGQgSeKAmW0gdHJ5aW5nIHRvIG1pZ3JhdGUgZnJvbSwgYW5kIGl0IHJlYWxseSBzZWVtcyBs aWtlIEnigJltIHNvbWV0aW1lcyB0cnlpbmcgdG8gbWFrZSBhIHNxdWFyZSBwZWcgZml0IGluIGEg cm91bmQgaG9sZS4gIEnigJltIGxvb2tpbmcgZm9yIE9BdXRoL0Nvbm5lY3QgdG8gZG8gZm9yIFJF U1Qgd2hhdCBXUy1UUlVTVCBkaWQgZm9yIFNPQVAuICBJIHdvdWxkIGxpa2UgYSBuYXRpdmUgY2xp ZW50IHRhbGtpbmcgdG8gYSBSUyB0byBiZSBhYmxlIHRvIGFzayBmb3IgYW4gaWRfdG9rZW4sIGFu ZCB0aGVuIHBhc3MgdGhhdCBpZF90b2tlbiB0byB0aGUgUlMgd2hlbiBtYWtpbmcgaXRzIFJFU1Rm dWwgQVBJIGNhbGxzLCB0byBlbmFibGUgdGhlIFJTIHRvIGF1dGhlbnRpY2F0ZSB0aGUgdXNlci4g IEkgdGhpbmsgdGhhdCB0aGlzIHdvdWxkIGJlIHJlYWxseSB1c2VmdWwgZm9yIGEgbG90IG9mIHBl b3BsZSBiZXNpZGVzIG1lLiAgSSBrZWVwIGhlYXJpbmcgdGhhdCB0aGVyZSBpcyBub3RoaW5nIOKA nHByZXZlbnRpbmfigJ0gbWUgZnJvbSBkb2luZyB0aGlzIOKApiBidXQgaXQgaGFyZGx5IHNlZW1z IHdpdGhpbiB0aGUgc3Bpcml0IG9mIHdoYXQgT0F1dGggd2FzIG1lYW50IHRvIGRvLiAgVGhlIGlk X3Rva2VuIHdhcyBjbGVhcmx5IG1lYW50IHRvIGVuYWJsZSBhIHVzZXIgdG8gYXV0aGVudGljYXRl IHRvIGEgY29uZmlkZW50aWFsIGNsaWVudCAgLyB3ZWIgc2VydmVyIOKApiBidXQgd2FzIG5vdCBt ZWFudCBmb3IgYSBuYXRpdmUgY2xpZW50IHRvIGlkZW50aXR5IC8gYXV0aGVudGljYXRlIHRoZSB1 c2VyIHRvIGEgUlMuDQoNCg0KV291bGQgdGhlcmUgYmUgYW55IGludGVyZXN0IGluIGV4cGxvcmlu ZyB0aGlzIGZ1cnRoZXI/DQotYWRhbQ0KDQoNCg0KRnJvbTogTmF0IFNha2ltdXJhIFttYWlsdG86 c2FraW11cmFAZ21haWwuY29tXQ0KU2VudDogV2VkbmVzZGF5LCBKdW5lIDIwLCAyMDEyIDg6MDkg UE0NClRvOiBMZXdpcyBBZGFtLUNBTDAyMg0KQ2M6IGlnb3IuZmF5bmJlcmdAYWxjYXRlbC1sdWNl bnQuY29tOyBvYXV0aEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gUmVwb3J0IGFu IGF1dGhlbnRpY2F0aW9uIGlzc3VlDQoNClllcywgT0F1dGggY2FuIGJlIHByb2ZpbGVkIHRvIGVu YWJsZSBhdXRoZW50aWNhdGlvbi4NCg0KSW4gZmFjdCwgaW5pdGlhbCBkcmFmdCBvZiBPcGVuSUQg Q29ubmVjdCB3YXMganVzdCBsaWtlIHlvdSBkZXNjcmliZWQuDQoNCkVzc2VudGlhbGx5LCB3ZSB3 ZXJlIHVzaW5nIHN0cnVjdHVyZWQgYWNjZXNzX3Rva2VuLg0KDQpMYXRlciwgd2UgZGVjaWRlZCB0 byBzZXBhcmF0ZSB0aGUgYWNjZXNzIHRva2VuIGFuZCBpZF90b2tlbiBmb3Igc2V2ZXJhbCByZWFz b25zIHN1Y2ggYXM6DQoNCg0KDQogMS4gIEJldHRlciBpbnRlcm9wIHdpdGggZXhpc3RpbmcgT0F1 dGggaW1wbGVtZW50YXRpb25zOiBieSBpbnRyb2R1Y2luZyBpZF90b2tlbiwgdGhleSBkbyBub3Qg bmVlZCB0byB0b3VjaCB0aGUgc3VwcG9zZWRseSBvcGFxdWUgKHdoaWNoIG1lYW5zIEFTLVJTIG1h eSBiZSBkb2luZyBzb21lIHByb3ByaWV0YXJ5IHRoaW5nIGluc2lkZSBpdCkgYWNjZXNzIHRva2Vu Lg0KIDIuICBNaXhpbmcgdXAgdGhlIGF1ZGllbmNlIChmb3IgaWRfdG9rZW4gYWthIGF1dGhuID0g Y2xpZW50LCBhbmQgZm9yIGFjY2Vzc190b2tlbiBha2EgYXV0aHogPSByZXNvdXJjZSBzZXJ2ZXIp IHByb2JhYmx5IGlzIGV4cGFuZGluZyB0aGUgYXR0YWNrIHN1cmZhY2UgZm9yIHNlY3VyaXR5IGFu ZCBwcml2YWN5Lg0KDQpBbHRob3VnaCB3ZSBzZXBhcmF0ZWQgdGhlbSBvdXQsIGEgc2lnbmVkIGlk X3Rva2VuIGluY2x1ZGVzIHRoZSBsZWZ0IGhhc2ggb2YgYWNjZXNzX3Rva2VuIHNvIGFjY2Vzc190 b2tlbiBpcyBhbHNvIHByb3RlY3RlZC4NCg0KDQoNCkJlc3QsDQoNCg0KDQpOYXQNCg0KDQoNCk9u IFRodSwgSnVuIDIxLCAyMDEyIGF0IDU6MjEgQU0sIExld2lzIEFkYW0tQ0FMMDIyIDxBZGFtLkxl d2lzQG1vdG9yb2xhc29sdXRpb25zLmNvbT4gd3JvdGU6DQoNCkhpIElnb3IsDQoNCkFzIEp1c3Rp biBqdXN0IHBvaW50ZWQgb3V0LCBjb25zaWRlciB0aGUgY2FzZSB3aGVyZSB0aGUgdmlkZW8gc2Vy dmVyIGlzIGhvc3RlZCBieSB0aGUgc3RhdGUgKGUuZy4gQ2FsaWZvcm5pYSkgYW5kIGlzIGFjY2Vz c2VkIGJ5IHBvbGljZSBhZ2VuY2llcyBpbiBMb3MgQW5nZWxlcywgU2FuIEZyYW5jaXNjbywgYW5k IFNhbiBEaWVnby4gIFRoZSBTdGF0ZSBvZiBDYWxpZm9ybmlh4oCZcyB2aWRlbyBzZXJ2ZXIgaXMg dGhlIFJTLiAgRWFjaCBsb2NhbCBwb2xpY2UgYWdlbmN5IChMQS9TRi9TRCkgaG9zdHMgYW4gQVMu ICBTbyB3aGVuIGEgcG9saWNlIG9mZmljZXIgZnJvbSBMQVBEIGxhdW5jaGVzIHRoZSB2aWRlbyBj bGllbnQgYXBwIG9uIHRoZSBpUGhvbmUsIHRoZSBjbGllbnQgbWFrZXMgYW4gT0F1dGggcmVxdWVz dCB0byB0aGUgTEFQROKAmXMgQVMsIHdoaWNoIGF1dGhlbnRpY2F0ZXMgdGhlIHBvbGljZSBvZmZp Y2VyIHVzaW5nIGFnZW5jeSBsZXZlbCBjcmVkZW50aWFscy4gIFRoZSBhY2Nlc3MgdG9rZW4gaXNz dWVkIHRvIHRoZSB2aWRlbyBjbGllbnQgYXBwIG9uIHRoZSBpUGhvbmUgaXMgYSBKV1QsIHNpZ25l ZCBieSB0aGUgYWdlbmN5IEFTLCB3aGljaCBtaWdodCBsb29rIHNvbWV0aGluZyBsaWtlIHRoaXM6 DQoNCnvigJx0eXDigJ064oCdSldU4oCdLCJhbGciOiJFUzI1NiJ9DQp7ImlzcyI6Imh0dHBzOi8v YXMubGFwZC5jYWxpZm9ybmlhLmdvdiIsDQogICJwcm4iOiJhbGljZUBsYXBkLmNhbGlmb3JuaWEu Z292IiwNCiAgImF1ZCI6IiBodHRwczovL3ZpZGVvX3NlcnZlcjFAc3RhdGUuY2FsaWZvcm5pYS5n b3YiLA0KICAiaWF0IjoxMzAwODE1NzgwLA0KICAiZXhwIjoxMzAwODE5MzgwLA0KICAiYWNyIjri gJ1wYXNzd29yZOKAnX0NCmhxNHprK1prbmpnZ0NRZ1ptN2VhOGZJNzlnSkVzUnkzRThMSERwWVhX UUlnWnBrSk45Q01MRzhFTlI0TnJ3K243aXl6aXhCdktYWDhQNTNCVENUNFZnaFBCV2hGWVN0OXRI V3UvQXRKZk9UaDZxYUFzTmRlQ3lHODZqbXRwM1RETXd1TC9jQlVqMk90QlpPUU1GbjdqUTlZQjdr bEl6M1JxVkwrd05tZVdJND0NCg0KVGhlIEpXVCBtaWdodCBiZSBvcHRpb25hbGx5IGVuY3J5cHRl ZCB1c2luZyBKV0UuDQoNCkkgdGhpbmsgd2hhdCBpcyBiZWNvbWluZyBjbGVhciAoYW5kIHRoaXMg aXMgd2hhdCBJ4oCZbSB0cnlpbmcgdG8gdmV0KSBpcyB0aGF0IHdoaWxlIHRoZXJlIGlzIG5vdGhp bmcgaW4gT0F1dGggdGhhdCBzcGVjaWZpZXMgYXV0aGVudGljYXRpb24sIGl0ICpjYW4qIGJlIHVz ZWQgZm9yIEF1dGhlbnRpY2F0aW9uLCBpZiBkb25lIGluIHRoZSB3YXkgdGhhdCBJIGRlc2NyaWJl LiAgSWYgSeKAmW0gd3JvbmcgYWJvdXQgdGhpcywgSSByZWFsbHkgbmVlZCB0byBrbm93LiAgSeKA mXZlIHZldHRlZCB0aGlzIGlkZWEgb2YgbWluZSB3aXRoIHF1aXRlIG9mIGZldyBwZW9wbGUgbm93 IOKAkyBib3RoIHdpdGhpbiBjb250ZXh0IG9mIHRoZSBsaXN0IGFuZCBvZmYtbGluZSDigJMgYW5k IEkgdGhpbmsgSeKAmW0gb2theS4gSWYgeW91IHNlZSBhbnkgaG9sZXMgaW4gd2hhdCBJIGRlc2Ny aWJlLCBwbGVhc2UgcG9pbnQgdGhlbSBvdXQgYXMgSSB3b3VsZCBwcmVmZXIgdG8gdW5jb3ZlciB0 aGVtIG5vdyByYXRoZXIgdGhhbiBhZnRlciBpbXBsZW1lbnRhdGlvbiBvciBkZXBsb3ltZW50IQ0K DQpFc3NlbnRpYWxseSBJ4oCZbSB1c2luZyBPQXV0aCBhcyBhIFJFU1RmdWwgdmVyc2lvbiBvZiBX Uy1UcnVzdCwgd2hlcmUgbXkgY2xpZW50IGNhbiBleGNoYW5nZSBwcmltYXJ5IGNyZWRlbnRpYWxz IGZvciBhIHRva2VuIChKV1QpIGFuZCBwcmVzZW50IHRoYXQgdG9rZW4gdG8gYSBzZXJ2ZXIgYXMg c2Vjb25kYXJ5IGF1dGhlbnRpY2F0aW9uLiAgSXTigJlzIGp1c3QgdGhhdCBpdOKAmXMgUkVTVGZ1 bCBpbnN0ZWFkIG9mIFNPQVAgOi0pDQoNCkFzIEp1c3RpbiBhcyBwb2ludGVkIG91dCDigKYgSeKA mXZlIGJhc2ljYWxseSBtYWRlIHRoZSBhY2Nlc3MtdG9rZW4gbG9vayBsaWtlIHRoZSBpZF90b2tl biBvZiBDb25uZWN0LiAgSSB3YXMgYWN0dWFsbHkgaG9waW5nIHRvIGxheSBhIHBhdGggdG8gQ29u bmVjdCwgYW5kIHVzZSB0aGUgaWRfdG9rZW4g4oCmIHVudGlsIGl0IHdhcyBhbHNvIHBvaW50ZWQg b3V0IHRoYXQgdGhlIGlkX3Rva2VuIGlzIHJlYWxseSBtZWFudCBmb3IgdGhlIGNvbnN1bXB0aW9u IG9mIHRoZSBjbGllbnQsIG5vdCB0aGUgUlMgOi0oDQoNCg0KDQoNCkZyb206IG9hdXRoLWJvdW5j ZXNAaWV0Zi5vcmcgW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg SWdvciBGYXluYmVyZw0KU2VudDogV2VkbmVzZGF5LCBKdW5lIDIwLCAyMDEyIDI6MzkgUE0NClRv OiBvYXV0aEBpZXRmLm9yZw0KDQoNClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIFJlcG9ydCBhbiBh dXRoZW50aWNhdGlvbiBpc3N1ZQ0KDQpCdXQgdGhpcyB1c2UgY2FzZSAgZG9lcyBuZWVkIE9BdXRo LCBwZXJpb2Q6DQoNCg0KDQpUaGUgdmlkZW8gc2VydmVyIGlzIHVuZGVyIHRoZSBjb250cm9sIG9m IGEgcG9saWNlIGFnZW5jeSwgYW5kIHBvbGljZSBvZmZpY2VycyBtdXN0IGxvZ29uIHRvIHRoZSB2 aWRlbyBzZXJ2ZXIgaW4gb3JkZXIgdG8gYWNjZXNzIHZpZGVvIGNvbnRlbnQuDQoNClRoZXJlIGlz IG5vIGRlbGVnYXRpb24gaGVyZSwgYW5kIHRoZXJlIGlzIG5vIG5lZWQgdG8gdXNlIHRoaXJkIHBh cnR5IGZvciBhdXRoZW50aWNhdGlvbi4NCg0KSWdvcg0KDQpPbiA2LzIwLzIwMTIgMzoyNiBQTSwg SnVzdGluIFJpY2hlciB3cm90ZToNCg0KSW4gY2FzZSBpdCB3YXNuJ3QgY2xlYXIsIEkgd2FudCB0 byByZXN0YXRlIHRoZSBvcmlnaW5hbCBwcm9ibGVtIGFzIGJlc3QgYXMgSSB1bmRlcnN0YW5kIGl0 IGluIGEgd2F5IHRoYXQgaG9wZWZ1bGx5IGNsZWFycyBpdCB1cDoNCg0KQXBwIEEgYW5kIGFwcCBC IGFyZSBib3RoIHZhbGlkIHJlZ2lzdGVyZWQgT0F1dGggY2xpZW50cyB0byBhbiBPQXV0aCBwcm90 ZWN0ZWQgc2VydmljZS4NCg0KVGhlIHByb2JsZW0gc3RhcnRzIHdoZW4gYXBwIEEgZ2V0cyBoYW5k ZWQgYSB0b2tlbiB0aGF0IHdhcyBpc3N1ZWQgZm9yIGFwcCBCIGFuZCB1c2VzIGl0IHRvIGNhbGwg YW4gaWRlbnRpdHkgQVBJIG9uIHRoZSBPQXV0aCBzZXJ2aWNlLiBTaW5jZSBhcHAgQiBjYW4gZ2V0 IHRva2VucyBqdXN0IGZpbmUsIHRoZXkncmUgYmVhcmVyIHRva2VucywgdGhpcyBpcyBhIGZhaXJs eSBiYXNpYyBhcGkgY2FsbCwgdGhpcyBmdW5jdGlvbiB3b3JrcyBqdXN0IGZpbmUgYW5kIHJldHVy bnMgdGhlIHVzZXIgaW5mby4gVGhpcyBtYWtlcyBzZW5zZSwgc2luY2UgYW55b25lIHdobyBob2xk cyBBJ3MgdG9rZW5zIGNhbiBkbyB3aGF0ZXZlciBBIGNhbiBkbyBvbiBiZWhhbGYgb2YgdGhhdCB1 c2VyLiBUaGUgaXNzdWVzIHN0YXJ0IHdoZW4gYXBwIEIgdGhlbiBkZWNpZGVzIHRoYXQgc2luY2Ug dGhleSBjYW4gbWFrZSBhIGNhbGwgdG8gdGhlIGlkZW50aXR5IEFQSSB3aXRoIGEgdG9rZW4gdGhl biB0aGUgdXNlciAqbXVzdCogYmUgcHJlc2VudC4gSW4gb3RoZXIgd29yZHMsIGFwcCBCIGlzIGNv bmZ1c2luZyBhdXRob3JpemF0aW9uIHRvIGNhbGwgYW4gQVBJIHdpdGggYXV0aGVudGljYXRpb24g b2YgdGhlIHNlc3Npb24uDQoNCk9wZW5JRCBDb25uZWN0IGZpeGVzIHRoaXMgbWlzc2VkIGFzc3Vt cHRpb24gYnkgYmluZGluZyB0aGUgSUQgVG9rZW4gdG8gdGhlIHNlc3Npb24gYW5kIHNlbmRpbmcg aXQgYWxvbmcgc2lkZSB0aGUgYWNjZXNzIHRva2VuLCBidXQgYXMgeW91IHBvaW50ZWQgb3V0LCBp dCdzIG1lYW50IGZvciBjb25zdW1wdGlvbiBhdCB0aGUgY2xpZW50LCBub3QgdGhlIHJlc291cmNl IHNlcnZlciwgaW4gZ2VuZXJhbC4gVGhhdCBkb2Vzbid0IG1lYW4geW91IGNhbid0IHNlbmQgaXQg dG8gYSByZXNvdXJjZSBzZXJ2ZXIgZm9yIHlvdXIgb3duIHB1cnBvc2VzLCBvZiBjb3Vyc2UuIFRo YXQncyBhY3R1YWxseSBob3cgdGhlIHNlc3Npb24gbWFuYWdlbWVudCBlbmRwb2ludCB3b3JrcyBp biBDb25uZWN0Lg0KDQpUaGlzIGlzbid0IHRoZSBvbmx5IHdheSB0byBoYW5kbGUgdGhpcyBwcm9i bGVtIC0tIGlmIHlvdSBwdXQgc29tZSBzdHJ1Y3R1cmUgaW4geW91ciB0b2tlbnMsIHN1Y2ggYXMg d2l0aCBKV1Qgb3IgU0FNTCwgdGhlbiBhcHAgQSBjYW4gdGVsbCB0aGF0IHRoaXMgaXNuJ3QgYSB0 b2tlbiBpc3N1ZWQgdG8gYXBwIEEsIGJ1dCB0byBhcHAgQiwgc28gaXQgY2FuIGNhbGwgc2hlbmFu aWdhbnMgYW5kIHJlamVjdCBpdCB0aGVuIGFuZCB0aGVyZS4NCg0KIC0tIEp1c3Rpbg0KDQpPbiAw Ni8yMC8yMDEyIDEwOjAzIEFNLCBMZXdpcyBBZGFtLUNBTDAyMiB3cm90ZToNCkkgYW0gZW50aXJl bHkgY29uZnVzZWQuDQoNCkkgdW5kZXJzdGFuZCB3aGF0IGV2ZXJ5Ym9keSBpcyBzYXlpbmcgZm9y IGNvbmZpZGVudGlhbCBjbGllbnRzLCBubyBwcm9ibGVtIGhlcmUuDQoNCkkgZmFsbCBhcGFydCB3 aGVuIHRoaW5raW5nIG9mIGlQaG9uZSBhcHBzLiAgQ29uc2lkZXIgdGhlIHNjZW5hcmlvIHdoZXJl IEkgZGVwbG95IGEgdmlkZW8gc2VydmVyLCBhbmQgd3JpdGUgYW4gaVBob25lIGFwcCB0byB0YWxr IHRvIHRoZSB2aWRlbyBzZXJ2ZXIuICBUaGUgdmlkZW8gc2VydmVyIGlzIHVuZGVyIHRoZSBjb250 cm9sIG9mIGEgcG9saWNlIGFnZW5jeSwgYW5kIHBvbGljZSBvZmZpY2VycyBtdXN0IGxvZ29uIHRv IHRoZSB2aWRlbyBzZXJ2ZXIgaW4gb3JkZXIgdG8gYWNjZXNzIHZpZGVvIGNvbnRlbnQuICBTbyB0 aGUgcG9saWNlIG9mZmljZSBsYXVuY2hlcyB0aGVpciBpUGhvbmUgdmlkZW8gY2xpZW50IGFwcC4N Cg0KSWYgSSB3YW50ZWQgdG8gc29sdmUgYXV0aGVudGljYXRpb24gdXNpbmcg4oCcdHJhZGl0aW9u YWzigJ0gY2xpZW50LXNlcnZlciBhdXRoZW50aWNhdGlvbiwgdGhlIHVzZXIgZW50ZXJzIHRoZWly IHVzZXJuYW1lIC8gcGFzc3dvcmQgaW50byB0aGUgY2xpZW50LCBhbmQgdGhlIGNsaWVudCBzZW5k cyB0aGUgdXNlcm5hbWUgLyBwYXNzd29yZCBvZmYgdG8gdGhlIHNlcnZlciwgd2hpY2ggYXV0aGVu dGljYXRlcyBpdCwgb3IgcG9zc2libHkgdXNlcyBIVFRQIGRpZ2VzdC4NCg0KSWYgSSB3YW50ZWQg dG8gdXNlIE9wZW5JRCwgdGhlIGNsaWVudCB3b3VsZCBhdHRlbXB0IHRvIHJlYWNoIHRoZSB2aWRl byBzZXJ2ZXIgKFJQKSwgdGhlIHNlcnZlciB3b3VsZCByZWRpcmVjdCB0aGUgY2xpZW50IHRvIHRo ZSBPUCwgT1AgYXV0aGVudGljYXRlcyB1c2VyLCBhbmQgT1AgcmVkaXJlY3RzIGNsaWVudCBiYWNr IHRvIHRoZSBzZXJ2ZXIvUlAgd2l0aCBhbiBhc3NlcnRpb24gdGhhdCBwcmltYXJ5IGF1dGhlbnRp Y2F0aW9uIHdhcyBzdWNjZXNzZnVsLg0KDQpJZiBJIHdhbnRlZCB0byB1c2UgT0F1dGgsIHRoZSBj bGllbnQgd291bGQgc2VuZCBhbiBhdXRob3JpemF0aW9uIHJlcXVlc3QgdG8gdGhlIHNlcnZlcuKA mXMgQVMsIHdoaWNoIHdvdWxkIGF1dGhlbnRpY2F0ZSB0aGUgdXNlciBvZiB0aGUgY2xpZW50LCBh bmQgdWx0aW1hdGVseSByZXN1bHQgaW4gdGhlIGNsaWVudCBwb3NzZXNzaW5nIGFuIGFjY2Vzcy10 b2tlbi4gIE15IHRoaW5raW5nIGlzIHRoYXQgdGhpcyBhY2Nlc3MgdG9rZW4gKGxldOKAmXMgYXNz dW1lIGl04oCZcyBhIEpXVCkgd291bGQgY29udGFpbiB0aGUgdXNlcuKAmXMgaWRlbnRpdHksIGEg c3RhdGVtZW50IG9mIHdoYXQgdHlwZSBvZiBwcmltYXJ5IGF1dGhlbnRpY2F0aW9uIHdhcyB1c2Vk IChhdXRoIGNvbnRleHQpLCBhbiBleHBpcmF0aW9uLCBhbmQgYW4gYXVkaWVuY2UgY2xhaW0uICBU aGlzIHNvdW5kcyBhIGxvdCBsaWtlIGF1dGhlbnRpY2F0aW9uIHRvIG1lLCBhbmQgaXTigJlzIHdo ZXJlIEkgZ2V0IGNvbmZ1c2VkLiAgSXMgaXQganVzdCBiZWNhdXNlIE9BdXRoIGRvZXMgbm90IGV4 cGxpY2l0bHkgZGVmaW5lIHRoaXM/ICBJcyB0aGVyZSBhIHRocmVhdCBpbiB1c2luZyBPQXV0aCBh cyBJIGRlc2NyaWJlPw0KDQpJZiBJIHdhbnRlZCB0byB1c2UgQ29ubmVjdCwgd2VsbCBJ4oCZbSBu b3QgZXZlbiBzdXJlIGhvdyB0aGUgaWRfdG9rZW4gYXMgZGVmaW5lZCBieSBDb25uZWN0IGhlbHBz IHRoaXMgdXNlIGNhc2UuICBUaGUgaWRfdG9rZW4gc2VlbXMgdG8gbWFrZSBzZW5zZSB3aGVuIHRo ZSBjbGllbnQgaXMgYSBjb25maWRlbnRpYWwgd2ViIHNlcnZlciwgYnV0IGl04oCZcyBub3QgY2xl YXIgd2hhdCBhbiBpUGhvbmUgYXBwIHdvdWxkIGRvIHdpdGggdGhlIGlkX3Rva2VuIOKApiBpdOKA mXMgdGhlIHNlcnZlciBpbiB0aGUgYmFja2VuZCB0aGF0IG5lZWRzIHRvIGF1dGhlbnRpY2F0ZSB0 aGUgdXNlciwgdGhlIGlQaG9uZSBhcHAgaXMganVzdCBhbiBpbnRlcmZhY2UgdG8gdGFsayB0byB0 aGUgc2VydmVyLiAgQW5kIGl0IHNlZW1zIGFzIEkgbGVhcm4gbW9yZSBhYm91dCBjb25uZWN0IHRo YXQgdGhlIGlkX3Rva2VuIGlzIG5vdCBtZWFudCB0byBiZSBzZW50IGZyb20gdGhlIGlQaG9uZSBh cHAgdG8gdGhlIHNlcnZlciwganVzdCB0aGUgYWNjZXNzIHRva2VuLiAgU28gaXTigJlzIHJlYWxs eSBub3QgY2xlYXIgaG93IENvbm5lY3QgaGVscHMgc29sdmUgYXV0aGVudGljYXRpb24gZm9yIGFu IGlQaG9uZSBjbGllbnQgYXBwIHRhbGtpbmcgdG8gYSB2aWRlbyBzZXJ2ZXIuICBJZiBJ4oCZbSBz ZW5kaW5nIGFjY2Vzcy10b2tlbnMsIGl04oCZcyBqdXN0IE9BdXRoIGFnYWluLg0KDQoNCldoYXQg YW0gSSBzdGlsbCBtaXNzaW5nPw0KYWRhbQ0KDQoNCg0KRnJvbTogb2F1dGgtYm91bmNlc0BpZXRm Lm9yZyBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBLcmlzdG9m b3IgU2VsZGVuDQpTZW50OiBTYXR1cmRheSwgSnVuZSAxNiwgMjAxMiAxMTozMyBBTQ0KVG86IG5v diBtYXRha2U7IG9hdXRoDQpDYzogWXVjaGVuIFpob3U7IEx1a2UgTWVsaWE7IFNodW8gQ2hlbiAo TVNSKQ0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gUmVwb3J0IGFuIGF1dGhlbnRpY2F0aW9uIGlz c3VlDQoNCg0KTm92IGRlbW9uc3RyYXRlZCB0aGUgcHJvYmxlbSB0byB1cyBhdCBZYXBwIGFuZCB3 ZSB1c2VkIHNvbHV0aW9uIDQgKGJlY2F1c2UgdGhlIHNvbHV0aW9uIGlzIHNlcnZlciBzaWRlIGFu ZCBvdXIgYXBwIHdhcyBpbiB0aGUgYXBwIHN0b3JlKS4NCg0KDQoNCkZCIENvbm5lY3QgaXMgYXV0 aGVudGljYXRpb24gYW5kIGF1dGhvcml6YXRpb24sIHdoZXJlIE9BdXRoIDIgaXMgY29uY2VybmVk IG9ubHkgd2l0aCBhdXRob3JpemF0aW9uIOKAkyBJJ20gbm90IHN1cmUgdGhhdCBhcHAgZGV2ZWxv cGVycyBhcHByZWNpYXRlIHRoaXMgc3VidGxldHkuDQoNCg0KDQpXaXRoIE9BdXRoIDIgeW91IGF1 dGhvcml6ZSBhbiBhcHAgdG8gdXNlIGEgcHJvdGVjdGVkIHJlc291cmNlLiAgV2l0aCBGQiBDb25u ZWN0LCB5b3UgZG8gdGhhdCwgYnV0IGFsc28gYXV0aGVudGljYXRlIHdpdGggdGhlIGFwcCB5b3Ug YXJlIGF1dGhvcml6aW5nLg0KDQoNCg0KU28gdGhlIGFjY2Vzc190b2tlbiBwcm90ZWN0cyBub3Qg anVzdCB0aGUgRkIgcmVzb3VyY2VzIGJ1dCB0aGUgYXV0aCBlbmQgcG9pbnQgb2YgdGhlIGF1dGhv cml6ZWQgYXBwICh2ZXJ5IGNvbW1vbiB3aXRoIGFwcHMgdGhhdCB1c2UgdGhlIGlPUyBTREspLiAg U28gbm93IHRoZSBhcHAgbmVlZHMgYSB3YXkgdG8gdmVyaWZ5IHRoYXQgaXQgd2FzIHRoZSBhcHAg dGhhdCB3YXMgYXV0aG9yaXplZCB0byBGQi4NCg0KDQoNClNvbHV0aW9uIDQgZXhwbGFuYXRpb246 IG9uIEZCIHlvdSBjYW4gcmVnaXN0ZXIgYSBpUGhvbmUgYXBwIGFuZCBhIHNlcnZlciBhcHAgd2l0 aCB0aGUgc2FtZSBjbGllbnRfaWQgYW5kIGdldCBhIGNsaWVudF9zZWNyZXQgZm9yIHVzZSBvbiB0 aGUgc2VydmVyLiAgVGhlIHNlcnZlciBzaWRlIEFQSSBwb3N0cyB0aGUgYWNjZXNzX3Rva2VuLCBj bGllbnRfaWQsIGFuZCBjbGllbnRfc2VjcmV0IHRvIGh0dHBzOi8vZ3JhcGguZmFjZWJvb2suY29t L2FwcCA8aHR0cHM6Ly9ncmFwaC5mYWNlYm9vay5jb20vYXBwP2FjY2Vzc190b2tlbj1ZT1VSX1RP S0VOPiAgdG8gdmVyaWZ5IHRoYXQgdGhlIGJlYXJlciB0b2tlbiBhY3R1YWxseSBiZWxvbmdzIHRv IHRoZSBhcHAgdGhhdCBpcyBiZWluZyBhdXRoZW50aWNhdGVkIGJlZm9yZSBhc3N1bWluZyB0aGV5 IGFyZSBhdXRob3JpemVkIHRvIHRoZSBhcHAncyBwcm90ZWN0ZWQgcmVzb3VyY2VzLg0KDQoNCg0K S3Jpcw0KDQoNCk9uIEp1biAxNSwgMjAxMiwgYXQgODoyMiBQTSwgbm92IG1hdGFrZSB3cm90ZToN Cg0KDQpUaGVyZSBhcmUgNCB3YXlzIHRvIGZpeCB0aGlzIGlzc3VlLg0KDQoNCg0KMS4gVXNlIHJl c3BvbnNlX3R5cGU9dG9rZW4lMjBjb2RlIChJdCdzIG5vdCBpbiBPQXV0aCAyLjAgQ29yZSwgYnV0 IHNlZW1zIGJlc3Qgd2F5IGZvciBpbnRlcm9wZXJhYmlsaXR5KQ0KDQoyLiBVc2Ugc2luZ2VkX3Jl cXVlc3QgKG9yIHNvbWUgc2lnbmVkIHRva2VuIGxpa2UgSldUKQ0KDQozLiBVc2UgZ3JhbnRfdHlw ZT1mYl9leGNoYW5nZV90b2tlbiAoRmFjZWJvb2sgY3VzdG9tIHdheSkNCg0KNC4gQWNjZXNzIHRv IGh0dHBzOi8vZ3JhcGguZmFjZWJvb2suY29tL2FwcD9hY2Nlc3NfdG9rZW49WU9VUl9UT0tFTiAo RmFjZWJvb2sgY3VzdG9tIHdheSwgbW9yZW92ZXIgdW5kb2N1bWVudGVkIEFQSSkNCg0KDQoNClR3 byBpUGhvbmUgYXBwIGRldmVsb3BlcnMgSSByZXBvcnRlZCB0aGlzIGlzc3VlIGZpeGVkIGl0IGJ5 IHVzaW5nICg0KS4NCg0KDQoNCkkgYWxzbyB0cmllZCB0byB1c2UgKDEpIGZvciBteSBvd24gaVBo b25lIGFwcCBpbXBsZW1lbnRhdGlvbiwgYnV0IHVuZm9ydHVuYXRlbHkgaXQgZG9lc24ndCB3b3Jr IHdoZW4gdXNpbmcgYXV0aG9yaXphdGlvbiBjb2RlcyBvYnRhaW5lZCB2aWEgRkIgaU9TIFNESy4N Cg0KU28gSSdtIHVzaW5nICgzKSBpbiBteSBjYXNlLg0KDQoNCg0Kbm92DQoNCg0KDQpPbiAyMDEy LzA2LzE2LCBhdCA5OjE2LCBOYXQgU2FraW11cmEgd3JvdGU6DQoNCg0KDQpBcyB0byBob3cgdGhl IGZpeCB3YXMgZG9uZSwgTm92IGNhbiBwcm92aWRlIG1vcmUgZGV0YWlsLCBidXQgLi4uDQoNCg0K DQoxLiBQcm9wZXJseSB2ZXJpZnkgdGhlIHNpZ25hdHVyZS9ITUFDIG9mIHRoZSAic2lnbmVkX3Jl cXVlc3QiLiBUaGlzIHdpbGwgZXNzZW50aWFsbHkgYXVkaWVuY2UgcmVzdHJpY3RzIHRoZSB0b2tl bi4NCg0KMi4gVGhlcmUgaXMgYW4gdW5kb2N1bWVudGVkIEFQSSBmb3IgRmFjZWJvb2sgd2hpY2gg cmV0dXJucyB0byB3aG9tIHRoZSB0b2tlbiB3YXMgaXNzdWVkLiBUaGlzIGFsc28gYXVkaWVuY2Ug cmVzdHJpY3RzIHRoZSB0b2tlbi4NCg0KDQoNClRoZSBzZXJ2aWNlIHRoYXQgZml4ZWQgdG9vayB0 aGVzZSBtZWFzdXJlcy4gTm90ZSB0aGF0IG5vbmUgb2YgdGhlIGFib3ZlIGlzIGRlZmluZWQgaW4g T0F1dGguDQoNClRoZSBzYW1lIGZhY2lsaXR5IHdhcyBjYWxsZWQgImlkX3Rva2VuIiBhbmQgImNo ZWNrIElEIGVuZHBvaW50IiBmb3IgT3BlbklEIENvbm5lY3QuDQoNCg0KDQpUaGUgc2NhbGUgb2Yg dGhlIGltcGFjdCBpcyBsYXJnZSwgdG9vIGxhcmdlIHRvIGRpc2Nsb3NlIHRoZSBhY3R1YWwgbmFt ZXMgaW4gdGhlIHB1YmxpYyBsaXN0LCB0aG91Z2gsIGV2ZW50dWFsbHksIHdlIHdvdWxkIHB1Ymxp c2ggdGhlbSBpbiBhIHBhcGVyLg0KDQoNCg0KTmF0DQoNCk9uIFNhdCwgSnVuIDE2LCAyMDEyIGF0 IDU6MzQgQU0sIEZyYW5jaXNjbyBDb3JlbGxhIDxmY29yZWxsYUBwb21jb3IuY29tPiB3cm90ZToN Cg0KSGkgTmF0IGFuZCBSdWksDQoNClJ1aSwgeW91IHNheSB0aGF0IHRoZSB2dWxuZXJhYmlsaXR5 IHRoYXQgeW91IGZvdW5kIHdhcyBkdWUgdG8gYQ0KImNvbW1vbiBtaXN1bmRlcnN0YW5kaW5nIGFt b25nIGRldmVsb3BlcnMiLCBidXQgdGhlIGF0dGFjayB5b3UNCmRlc2NyaWJlIGNhbiBiZSBjYXJy aWVkIG91dCBhZ2FpbnN0IGFueSBhcHAgdGhhdCB1c2VzIHRoZSBPQXV0aA0KImltcGxpY2l0IGdy YW50IGZsb3ciLCB3aGljaCBGYWNlYm9vayBjYWxscyAiY2xpZW50LXNpZGUNCmF1dGhlbnRpY2F0 aW9uIi4gIE5vIG1pc3VuZGVyc3RhbmRpbmcgc2VlbXMgbmVjZXNzYXJ5LiAgV2hhdA0KbWlzdW5k ZXJzdGFuZGluZyBhcmUgeW91IHJlZmVycmluZyB0bz8gIEkgZm9sbG93ZWQgdGhlIGxpbmsgaW4g eW91cg0KbWVzc2FnZSB0byB0aGUgU29waG9zIHBvc3QsIGFuZCBmcm9tIHRoZXJlIHRoZSBsaW5r IHRvIHRoZSBhcnRpY2xlIGluDQpUaGUgUmVnaXN0ZXIuICBUaGUgYXJ0aWNsZSBpbiBUaGUgUmVn aXN0ZXIgc2F5cyB0aGF0IEZhY2Vib29rIGhhZA0KImZpeGVkIHRoZSB2dWxuZXJhYmlsaXR5IHBy b21wdGx5Ii4gIEhvdyBkaWQgdGhleSBmaXggaXQ/ICBUaGUNCmluc3RydWN0aW9ucyB0aGF0IEZh Y2Vib29rIHByb3ZpZGVzIGZvciBpbXBsZW1lbnRpbmcgIkNsaWVudC1zaWRlDQphdXRoZW50aWNh dGlvbiB3aXRob3V0IHRoZSBKUyBTREsiIGF0DQpodHRwczovL2RldmVsb3BlcnMuZmFjZWJvb2su Y29tL2RvY3MvYXV0aGVudGljYXRpb24vY2xpZW50LXNpZGUvI25vLWpzc2RrDQpzdGlsbCBhbGxv d3MgdGhlIGF0dGFjay4NCg0KTmF0LCBJIGFncmVlIHRoYXQgdGhlIGJsb2cgcG9zdCBieSBKb2hu IEJyYWRsZXkgdGhhdCB5b3UgbGluayB0bw0KcmVmZXJzIHRvIHRoZSBzYW1lIHZ1bG5lcmFiaWxp dHkgcmVwb3J0ZWQgYnkgUnVpLiAgWW91IHNheSB0aGF0IHNvbWUNCmFwcHMgaGF2ZSBpc3N1ZWQg YSBwYXRjaCB0byBmaXggaXQuICBDb3VsZCB5b3UgZXhwbGFpbiB3aGF0IHRoZSBmaXgNCndhcz8N Cg0KRnJhbmNpc2NvDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpG cm9tOiBOYXQgU2FraW11cmEgPHNha2ltdXJhQGdtYWlsLmNvbT4NClRvOiBydWkgd2FuZyA8cnVp d2FuZ3dhcm1AZ21haWwuY29tPg0KQ2M6IG1hdGFrZSBub3YgPG5vdkBtYXRha2UuanA+OyBZdWNo ZW4gWmhvdSA8dC15dXpob3VAbWljcm9zb2Z0LmNvbT47IG9hdXRoIDxvYXV0aEBpZXRmLm9yZz47 IFNodW8gQ2hlbiAoTVNSKSA8c2h1b2NoZW5AbWljcm9zb2Z0LmNvbT4NClNlbnQ6IFRodXJzZGF5 LCBKdW5lIDE0LCAyMDEyIDE6NTAgUE0NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIFJlcG9ydCBh biBhdXRoZW50aWNhdGlvbiBpc3N1ZQ0KDQoNCg0KVGhpcyBpcyBhIGZhaXJseSB3ZWxsIGtub3du IChob3BlZnVsbHkgYnkgbm93KSBpc3N1ZS4gV2UsIGF0IHRoZSBPcGVuSUQgRm91bmRhdGlvbiwg Y2FsbCBpdCAiYWNjZXNzX3Rva2VuIHBoaXNoaW5nIiBhdHRhY2sgdGhlc2UgZGF5cy4gU2VlOiBo dHRwOi8vd3d3LnRocmVhZC1zYWZlLmNvbS8yMDEyLzAxL3Byb2JsZW0td2l0aC1vYXV0aC1mb3It YXV0aGVudGljYXRpb24uaHRtbA0KDQoNCg0KTm92IE1hdGFrZSBoYXMgYWN0dWFsbHkgYnVpbHQg dGhlIGNvZGUgb24gaVBob25lIHRvIHZlcmlmeSB0aGUgcHJvYmxlbSwgYW5kIGhhcyBub3RpZmll ZCBidW5jaCBvZiBwYXJ0aWVzIGJhY2sgaW4gRmVicnVhcnkgaW5jbHVkaW5nIEZhY2Vib29rIGFu ZCBBcHBsZS4gV2UgaGF2ZSB0aGUgY29kZSB0aGF0IGFjdHVhbGx5IHJ1bnMgb24gYSBwaG9uZSwg YW5kIHdlIGhhdmUgc3VjY2Vzc2Z1bGx5IGxvZ2dlZCBpbiB0byBidW5jaCBvZiBhcHBzLCBpbmNs dWRpbmcgdmVyeSB3ZWxsIGtub3duIG9uZXMuIFRoZXkgd2VyZSBhbGwgaW5mb3JtZWQgb2YgdGhl IGlzc3VlLiBTb21lIGltbWVkaWF0ZWx5IGlzc3VlZCBhIHBhdGNoIHRvIGZpeCBpdCB3aGlsZSBv dGhlcnMgaGF2ZSBub3QuDQoNCg0KDQpUaGUgcHJvYmxlbSBpcyB0aGF0IGV2ZW4gaWYgdGhlc2Ug YXBwcyBnZXRzIGZpeGVkLCB0aGUgcHJvYmxlbSBkb2VzIG5vdCBnbyBhd2F5LiBBcyBsb25nIGFz IHRoZSBhdHRhY2tlciBoYXMgdGhlIHZ1bG5lcmFibGUgdmVyc2lvbiBvZiB0aGUgYXBwLCBoZSBz dGlsbCBjYW4gaW1wZXJzb25hdGUgdGhlIHZpY3RpbS4gVG8gc3RvcCBpdCwgdGhlIHNlcnZlciBz aWRlIGhhcyB0byBjb21wbGV0ZWx5IGRpc2FibGUgdGhlIG9sZGVyIHZlcnNpb24sIHdoaWNoIG1l YW5zIHRoZSBzZXJ2aWNlIGhhcyB0byBjdXQgb2ZmIG1hbnkgdXNlcnMgcGF1c2luZyBidXNpbmVz cyBwcm9ibGVtcy4NCg0KDQoNCk5hdA0KDQpPbiBGcmksIEp1biAxNSwgMjAxMiBhdCAyOjE4IEFN LCBydWkgd2FuZyA8cnVpd2FuZ3dhcm1AZ21haWwuY29tPiB3cm90ZToNCg0KRGVhciBGYWNlYm9v ayBTZWN1cml0eSBUZWFtIGFuZCBPQXV0aCBTdGFuZGFyZCBncm91cCwNCg0KV2UgYXJlIGEgcmVz ZWFyY2ggdGVhbSBpbiBNaWNyb3NvZnQgUmVzZWFyY2guIEluIEphbnVhcnksIDIwMTEsIHdlIHJl cG9ydGVkIGEgdnVsbmVyYWJpbGl0eSBpbiBGYWNlYm9vayBDb25uZWN0IHdoaWNoIGFsbG93ZWQg ZXZlcnlvbmUgdG8gc2lnbiBpbnRvIEZhY2Vib29rLXNlY3VyZWQgcmVseWluZyBwYXJ0aWVzIHdp dGhvdXQgcGFzc3dvcmQuIEl0IHdhcyBwcm9tcHRseSBmaXhlZCBhZnRlciByZXBvcnRpbmcuICho dHRwOi8vbmFrZWRzZWN1cml0eS5zb3Bob3MuY29tLzIwMTEvMDIvMDIvZmFjZWJvb2stZmxhdy13 ZWJzaXRlcy1zdGVhbC1wZXJzb25hbC1kYXRhLykNCg0KUmVjZW50bHksIHdlIGZvdW5kIGEgY29t bW9uIG1pc3VuZGVyc3RhbmRpbmcgYW1vbmcgZGV2ZWxvcGVycyBvZiBtb2JpbGUvbWV0cm8gYXBw cyB3aGVuIHVzaW5nIE9BdXRoIChpbmNsdWRpbmcgRmFjZWJvb2vigJlzIE9BdXRoKSBmb3IgYXV0 aGVudGljYXRpb24uIFRoZSB2dWxuZXJhYmlsaXR5IHJlc3VsdGVkIGZyb20gdGhpcyBtaXN1bmRl cnN0YW5kaW5nIGFsc28gYWxsb3dzIGFuIGF0dGFja2VyIHRvIGxvZyBpbnRvIGEgdmljdGltIHVz ZXIncyBhY2NvdW50IHdpdGhvdXQgcGFzc3dvcmQuDQoNCkxldCdzIHRha2UgU29sdXRvJ3MgbWV0 cm8gYXBwIGFzIGFuIGV4YW1wbGUgdG8gZGVzY3JpYmUgdGhlIHByb2JsZW0uIFRoZSBhcHAgc3Vw cG9ydHMgRmFjZWJvb2sgTG9naW4uIEFzIGFuIGF0dGFja2VyLCB3ZSBjYW4gd3JpdGUgYSByZWd1 bGFyIEZhY2Vib29rIGFwcC4gT25jZSB0aGUgdmljdGltIHVzZXIgYWxsb3dzIG91ciBhcHAgdG8g YWNjZXNzIGhlciBGYWNlYm9vayBkYXRhLCB3ZSByZWNlaXZlIGFuIGFjY2Vzc190b2tlbiBmcm9t IHRoZSB0cmFmZmljLiBUaGVuLCBvbiBvdXIgb3duIG1hY2hpbmUgKGkuZS4sIHRoZSAiYXR0YWNr ZXIiIG1hY2hpbmUpLCB3ZSBydW4gdGhlIG1ldHJvIGFwcCBvZiBTb2x1dG8sIGFuZCB1c2UgYSBI VFRQIHByb3h5IHRvIGluc2VydCB0aGUgdmljdGltJ3MgYWNjZXNzX3Rva2VuIGludG8gdGhlIHRy YWZmaWMgb2YgRmFjZWJvb2sgbG9naW4uIFRocm91Z2ggdGhpcyB3YXksIHdlIGFyZSBhYmxlIHRv IGxvZyBpbnRvIHRoZSB2aWN0aW0ncyBTb2x1dG8gYWNjb3VudCBmcm9tIG91ciBtYWNoaW5lLiBP dGhlciB0aGFuIFNvbHV0bywgd2UgYWxzbyBoYXZlIGNvbmZpcm1lZCB0aGUgc2FtZSBpc3N1ZSBv biBhbm90aGVyIFdpbmRvd3MgOCBtZXRyby1hcHAgR2l2aXQuDQoNClRoZSBGYWNlYm9vayBTREsg Zm9yIEFuZHJvaWQgYXBwcyAoaHR0cHM6Ly9kZXZlbG9wZXJzLmZhY2Vib29rLmNvbS9kb2NzL21v YmlsZS9hbmRyb2lkL2J1aWxkLyNzZGspIHNlZW1zIHRvIGhhdmUgdGhlIHBvc3NpYmlsaXR5IHRv IG1pc2xlYWQgZGV2ZWxvcGVycyB0b28uIEF0IGxlYXN0LCB0aGUgaXNzdWUgdGhhdCB3ZSBmb3Vu ZCBpcyBub3QgY2xlYXJseSBtZW50aW9uZWQuIEluIHRoZSBTREssIHdlIHJhbiB0aGUgc2FtcGxl IGNvZGUgY2FsbGVkICJIYWNrYm9vayIgdXNpbmcgQW5kcm9pZCBFbXVsYXRvciAoaW1hZ2luZSBp dCBpcyBhbiBhdHRhY2tlciBkZXZpY2UpLiBOb3RlIHRoYXQgd2UgaGF2ZSBhbHJlYWR5IHJlY2Vp dmVkIHRoZSBhY2Nlc3MgdG9rZW4gb2YgdGhlIHZpY3RpbSB1c2VyIGZyb20gb3VyIHJlZ3VsYXIg RmFjZWJvb2sgYXBwLiBXZSB0aGVuIGluamVjdCB0aGUgdG9rZW4gdG8gdGhlIHRyYWZmaWMgb2Yg SGFja2Jvb2suIFRocm91Z2ggdGhpcyB3YXksIEhhY2tib29rIGFwcCBvbiBvdXIgb3duIG1hY2hp bmUgcmVjb2duaXplcyB1cyBhcyB0aGUgdmljdGltLiBOb3RlIHRoYXQgdGhpcyBpcyBub3QgYSBj b252aW5jaW5nIHNlY3VyaXR5IGV4cGxvaXQgeWV0LCBiZWNhdXNlIHRoaXMgc2FtcGxlIGNvZGUg ZG9lcyBub3QgaW5jbHVkZSB0aGUgc2VydmVyLXNpZGUgY29kZS4gSG93ZXZlciwgZ2l2ZW4gdGhh dCB3ZSBoYXZlIHNlZW4gcmVhbCBzZXJ2ZXItc2lkZSBjb2RlIGhhdmluZyB0aGlzIHByb2JsZW0s IHN1Y2ggYXMgU29sdXRvLCBHaXZpdCBhbmQgb3RoZXJzLCB3ZSBkbyBiZWxpZXZlIHRoYXQgdGhl IHNhbXBsZSBjb2RlIGNhbiBtaXNsZWFkIG1vYmlsZS9tZXRybyBkZXZlbG9wZXJzLiBXZSBhbHNv IHN1c3BlY3QgdGhhdCB0aGlzIG1heSBiZSBhIGdlbmVyYWwgaXNzdWUgb2YgbWFueSBPQXV0aCBp bXBsZW1lbnRhdGlvbnMgb24gbW9iaWxlIHBsYXRmb3Jtcywgc28gd2Ugc2VuZCB0aGlzIG1lc3Nh Z2UgdG8gT0F1dGggU3RhbmRhcmQgZ3JvdXAgYXMgd2VsbC4NCg0KV2UgaGF2ZSBjb250YWN0ZWQg dGhlIHZlbmRvcnMgb2YgdGhlIHR3byB2dWxuZXJhYmxlIG1ldHJvLWFwcHMsIFNvbHV0byBhbmQg R2F2aXQuDQoNClBsZWFzZSBraW5kbHkgZ2l2ZSB1cyBhbiBhY2sgd2hlbiB5b3UgcmVjZWl2ZSB0 aGlzIG1lc3NhZ2UuIElmIHlvdSB3YW50IHRvIGtub3cgbW9yZSBkZXRhaWxzLCBwbGVhc2UgbGV0 IHVzIGtub3cuDQoNCkJlc3QgUmVnYXJkcywNCll1Y2hlbiBaaG91LCBSdWkgV2FuZywgYW5kIFNo dW8gQ2hlbg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRm Lm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL29hdXRoDQo= --_000_B8063282B7CD4C80ADE9FE23ED3289F5salesforcecom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PC9oZWFkPjxib2R5IGJnY29sb3I9IiNGRkZGRkYiPjxkaXY+SSdtIG5vdCBj b252aW5jZWQgYSBuZXcgZG9jdW1lbnQgaXMgcmVxdWlyZWQuICZuYnNwOyBUaGlzIGlzIGJhc2lj YWxseSBkZXNjcmliaW5nIGhvdyBvdXQgT0F1dGggZGVwbG95bWVudCB3b3Jrcywgd2l0aCB0aGUg ZXhjZXB0aW9uIHRoYXQgb3VyIHRva2VuIGZvcm1hdCBpcyBvcGFxdWUuICZuYnNwOyZuYnNwOzwv ZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+Tm90aGluZyBzZWVtcyBuZXcuICZuYnNwOzxicj48YnI+ LSBjbW9ydDwvZGl2PjxkaXY+PGJyPk9uIEp1biAyMiwgMjAxMiwgYXQgMToyOSBBTSwgIkhhbm5l cyBUc2Nob2ZlbmlnIiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmhhbm5lcy50c2Nob2ZlbmlnQG5zbi5j b20iPmhhbm5lcy50c2Nob2ZlbmlnQG5zbi5jb208L2E+Jmd0OyB3cm90ZTo8YnI+PGJyPjwvZGl2 PjxkaXY+PC9kaXY+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGRpdj4NCjxtZXRhIGh0dHAtZXF1 aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PVdpbmRvd3MtMTI1 MiI+PHRpdGxlPlJlOiBbT0FVVEgtV0ddIFJlcG9ydCBhbiBhdXRoZW50aWNhdGlvbiBpc3N1ZTwv dGl0bGU+DQoNCg0KPGZvbnQgZmFjZT0iQ2FsaWJyaSwgVmVyZGFuYSwgSGVsdmV0aWNhLCBBcmlh bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMXB0Ij5IaSBBZGFtLCA8YnI+DQo8YnI+DQpJdCB0 YWtlcyBhIGRvY3VtZW50IHRvIGFkZCBuZXcgZnVuY3Rpb25hbGl0eSB0byBPYXV0aC4gSnVzdCB3 cml0ZSBvbmUgYW5kIHN1Ym1pdCBpdCB0byB0aGUgZ3JvdXAuIDxicj4NCjxicj4NCkNpYW88YnI+ DQpIYW5uZXM8YnI+DQo8YnI+DQo8YnI+DQpPbiA2LzIxLzEyIDc6MDEgUE0sICJleHQgTGV3aXMg QWRhbS1DQUwwMjIiICZsdDs8YSBocmVmPSJBZGFtLkxld2lzQG1vdG9yb2xhc29sdXRpb25zLmNv bSI+QWRhbS5MZXdpc0Btb3Rvcm9sYXNvbHV0aW9ucy5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQo8 YnI+DQo8L3NwYW4+PC9mb250PjxibG9ja3F1b3RlPjxmb250IGZhY2U9IkNhbGlicmksIFZlcmRh bmEsIEhlbHZldGljYSwgQXJpYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTJwdCI+SGkgTmF0 LDxicj4NCiZuYnNwOzxicj4NCknigJltIGJlZ2lubmluZyB0byB3b25kZXIgd2hhdCBpdCB3b3Vs ZCB0YWtlIHRvIGFkZCBhIG5ldyBwcm9maWxlIG9mIHNvcnRzIHRvIGVpdGhlciBPQXV0aCBvciBD b25uZWN0LiA8YnI+DQombmJzcDs8YnI+DQpJbiB0aGUgYmVnaW5uaW5nIHRoZXJlIHdhcyBTT0FQ LCBhbmQgdGhlIHByZWZlcnJlZCBtZXRob2QgdG8gc2VjdXJlIFNPQVAgQVBJIGNhbGxzIHdhcyBX Uy1UcnVzdC48YnI+DQombmJzcDs8YnI+DQpOb3cgdGhlIHdvcmxkIGlzIG1vdmluZyB0b3dhcmQg UkVTVGZ1bCBBUElzIOKApiBhbmQgdGhlIHByZWZlcnJlZCBtZWFucyB0byBzZWN1cmUgUkVTVGZ1 bCBBUElzIGlzIE9BdXRoLjxicj4NCiZuYnNwOzxicj4NCkV4Y2VwdCB0aGF0IE9BdXRoIGlzIGNs ZWFybHkgd3JpdHRlbiB3aXRoIHRoZSBpZGVhIHRoYXQgdGhlIHByb3RlY3RlZCByZXNvdXJjZXMg YmVsb25nIHRvIHRoZSBlbmQgdXNlci48YnI+DQombmJzcDs8YnI+DQpNeSB1c2UgY2FzZXMg4oCT IGFuZCBJIGltYWdpbmUgdGhlIHVzZSBjYXNlcyBvZiBtYW55IG90aGVyIGVudGVycHJpc2VzIOKA kyBpcyB0aGF0IHRoZSBPd25lciBvZiB0aGUgcmVzb3VyY2VzIGlzIHRoZSBFbnRlcnByaXNlLiAm bmJzcDtBbiBlbXBsb3llZSBpcyB0cnlpbmcgdG8gYWNjZXNzIGEgZGF0YWJhc2Ugb3IgdmlkZW8g cmVzb3VyY2VzLiAmbmJzcDtUaGUgZW50ZXJwcmlzZSBSUyBuZWVkcyB0byBiZSBhYmxlIHRvIDEp IGlkZW50aWZ5IHRoZSB1c2VyLCBhbmQgMikgbWFrZSBhdXRob3JpemF0aW9uIGRlY2lzaW9ucyBi YXNlZCBvbiB3aGF0IHJvbGVzIHRoYXQgdXNlciBoYXMgd2l0aGluIHRoZSBlbnRlcnByaXNlLiAm bmJzcDtTbyBpbiBteSBzY2VuYXJpbywgd2hlbiBhIHBvbGljZSBvZmZpY2VyIGF0dGVtcHRzIHRv IGFjY2VzcyBhIGNyaW1pbmFsIHJlY29yZHMgZGF0YWJhc2UsIHRoZSBkYXRhYmFzZSBuZWVkcyB0 byBrbm93IHdobyB0aGF0IG9mZmljZXIgaXMsIGFuZCB0aGVuIGRlY2lkZSBpZiB0aGV5IGhhdmUg cHJpdmlsZWdlIHRvIGFjY2VzcyB0aGUgZGF0YWJhc2UsIGFuZCBhdCB3aGF0IGxldmVsIChlLmcu IENSVUQpLiA8YnI+DQombmJzcDs8YnI+DQpXUy1UcnVzdCBmaXRzIHRoaXMgbW9kZWwgd2VsbC4g Jm5ic3A7VGhlIHVzZXIgcGVyZm9ybXMgcHJpbWFyeSBhdXRoZW50aWNhdGlvbiB0byB0aGUgZW50 ZXJwcmlzZSBTVFMsIHdoaWNoIHRoZW4gZ3JhbnRzIHRoZSBhcHBsaWNhdGlvbiBjbGllbnQgYSBT QU1MIGFzc2VydGlvbi4gJm5ic3A7V2hlbiB0aGUgdXNlciBhdHRlbXB0cyB0byBhY2Nlc3MgYSBy ZWNvcmRzIGRhdGFiYXNlLCB0aGUgU0FNTCBhc3NlcnRpb24gaXMgaW5jbHVkZWQgaW4gdGhlIFNP QVAgbWVzc2FnZS4gJm5ic3A7VGhlIHJlY29yZHMgc2VydmVyIGF1dGhlbnRpY2F0ZXMgdGhlIHVz ZXIgYmFzZWQgb24gdGhlIFNBTUwgYXNzZXJ0aW9uIGFuZCBtYWtlcyBpdHMgYXV0aG9yaXphdGlv biBkZWNpc2lvbnMuPGJyPg0KJm5ic3A7PGJyPg0KVGhpcyBpcyB0aGUgd29ybGQgSeKAmW0gdHJ5 aW5nIHRvIG1pZ3JhdGUgZnJvbSwgYW5kIGl0IHJlYWxseSBzZWVtcyBsaWtlIEnigJltIHNvbWV0 aW1lcyB0cnlpbmcgdG8gbWFrZSBhIHNxdWFyZSBwZWcgZml0IGluIGEgcm91bmQgaG9sZS4gJm5i c3A7SeKAmW0gbG9va2luZyBmb3IgT0F1dGgvQ29ubmVjdCB0byBkbyBmb3IgUkVTVCB3aGF0IFdT LVRSVVNUIGRpZCBmb3IgU09BUC4gJm5ic3A7SSB3b3VsZCBsaWtlIGEgbmF0aXZlIGNsaWVudCB0 YWxraW5nIHRvIGEgUlMgdG8gYmUgYWJsZSB0byBhc2sgZm9yIGFuIGlkX3Rva2VuLCBhbmQgdGhl biBwYXNzIHRoYXQgaWRfdG9rZW4gdG8gdGhlIFJTIHdoZW4gbWFraW5nIGl0cyBSRVNUZnVsIEFQ SSBjYWxscywgdG8gZW5hYmxlIHRoZSBSUyB0byBhdXRoZW50aWNhdGUgdGhlIHVzZXIuICZuYnNw O0kgdGhpbmsgdGhhdCB0aGlzIHdvdWxkIGJlIHJlYWxseSB1c2VmdWwgZm9yIGEgbG90IG9mIHBl b3BsZSBiZXNpZGVzIG1lLiAmbmJzcDtJIGtlZXAgaGVhcmluZyB0aGF0IHRoZXJlIGlzIG5vdGhp bmcg4oCccHJldmVudGluZ+KAnSBtZSBmcm9tIGRvaW5nIHRoaXMg4oCmIGJ1dCBpdCBoYXJkbHkg c2VlbXMgd2l0aGluIHRoZSBzcGlyaXQgb2Ygd2hhdCBPQXV0aCB3YXMgbWVhbnQgdG8gZG8uICZu YnNwO1RoZSBpZF90b2tlbiB3YXMgY2xlYXJseSBtZWFudCB0byBlbmFibGUgYSB1c2VyIHRvIGF1 dGhlbnRpY2F0ZSB0byBhIGNvbmZpZGVudGlhbCBjbGllbnQgJm5ic3A7LyB3ZWIgc2VydmVyIOKA piBidXQgd2FzIG5vdCBtZWFudCBmb3IgYSBuYXRpdmUgY2xpZW50IHRvIGlkZW50aXR5IC8gYXV0 aGVudGljYXRlIHRoZSB1c2VyIHRvIGEgUlMuIDxicj4NCiZuYnNwOzxicj4NCiZuYnNwOzxicj4N CldvdWxkIHRoZXJlIGJlIGFueSBpbnRlcmVzdCBpbiBleHBsb3JpbmcgdGhpcyBmdXJ0aGVyPzxi cj4NCi1hZGFtPGJyPg0KJm5ic3A7PGJyPg0KJm5ic3A7PGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTFwdCI+PGJyPg0KPC9zcGFuPjxmb250IHNpemU9IjIiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTBwdCI+PGI+RnJvbTo8L2I+IE5hdCBTYWtpbXVyYSBbPGEgaHJlZj0ibWFp bHRvOnNha2ltdXJhQGdtYWlsLmNvbSI+bWFpbHRvOnNha2ltdXJhQGdtYWlsLmNvbTwvYT5dIDxi cj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEp1bmUgMjAsIDIwMTIgODowOSBQTTxicj4NCjxi PlRvOjwvYj4gTGV3aXMgQWRhbS1DQUwwMjI8YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Imlnb3Iu ZmF5bmJlcmdAYWxjYXRlbC1sdWNlbnQuY29tIj5pZ29yLmZheW5iZXJnQGFsY2F0ZWwtbHVjZW50 LmNvbTwvYT47IDxhIGhyZWY9Im9hdXRoQGlldGYub3JnIj5vYXV0aEBpZXRmLm9yZzwvYT48YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gUmVwb3J0IGFuIGF1dGhlbnRpY2F0aW9u IGlzc3VlPGJyPg0KPC9zcGFuPjwvZm9udD48L2ZvbnQ+PGZvbnQgZmFjZT0iVGltZXMgTmV3IFJv bWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEycHQiPiA8YnI+DQpZZXMsIE9BdXRoIGNhbiBi ZSBwcm9maWxlZCB0byBlbmFibGUgYXV0aGVudGljYXRpb24uIDxicj4NCjwvc3Bhbj48L2ZvbnQ+ PGZvbnQgZmFjZT0iQ2FsaWJyaSwgVmVyZGFuYSwgSGVsdmV0aWNhLCBBcmlhbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMXB0Ij48YnI+DQo8L3NwYW4+PC9mb250Pjxmb250IGZhY2U9IlRpbWVz IE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMnB0Ij5JbiBmYWN0LCBpbml0aWFs IGRyYWZ0IG9mIE9wZW5JRCBDb25uZWN0IHdhcyBqdXN0IGxpa2UgeW91IGRlc2NyaWJlZC4gPGJy Pg0KPC9zcGFuPjwvZm9udD48Zm9udCBmYWNlPSJDYWxpYnJpLCBWZXJkYW5hLCBIZWx2ZXRpY2Es IEFyaWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExcHQiPjxicj4NCjwvc3Bhbj48L2ZvbnQ+ PGZvbnQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEycHQi PkVzc2VudGlhbGx5LCB3ZSB3ZXJlIHVzaW5nIHN0cnVjdHVyZWQgYWNjZXNzX3Rva2VuLiA8YnI+ DQo8L3NwYW4+PC9mb250Pjxmb250IGZhY2U9IkNhbGlicmksIFZlcmRhbmEsIEhlbHZldGljYSwg QXJpYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTFwdCI+PGJyPg0KPC9zcGFuPjwvZm9udD48 Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTJwdCI+ TGF0ZXIsIHdlIGRlY2lkZWQgdG8gc2VwYXJhdGUgdGhlIGFjY2VzcyB0b2tlbiBhbmQgaWRfdG9r ZW4gZm9yIHNldmVyYWwgcmVhc29ucyBzdWNoIGFzOiA8YnI+DQo8L3NwYW4+PC9mb250Pjxmb250 IGZhY2U9IkNhbGlicmksIFZlcmRhbmEsIEhlbHZldGljYSwgQXJpYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTFwdCI+PGJyPg0KPC9zcGFuPjwvZm9udD48Zm9udCBmYWNlPSJUaW1lcyBOZXcg Um9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTJwdCI+IDxicj4NCjwvc3Bhbj48L2ZvbnQ+ PG9sPjxsaT48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTJwdCI+QmV0dGVyIGludGVyb3Agd2l0aCBleGlzdGluZyBPQXV0aCBpbXBsZW1lbnRhdGlv bnM6IGJ5IGludHJvZHVjaW5nIGlkX3Rva2VuLCB0aGV5IGRvIG5vdCBuZWVkIHRvIHRvdWNoIHRo ZSBzdXBwb3NlZGx5IG9wYXF1ZSAod2hpY2ggbWVhbnMgQVMtUlMgbWF5IGJlIGRvaW5nIHNvbWUg cHJvcHJpZXRhcnkgdGhpbmcgaW5zaWRlIGl0KSBhY2Nlc3MgdG9rZW4uIA0KPC9zcGFuPjwvZm9u dD48L2xpPjxsaT48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTJwdCI+TWl4aW5nIHVwIHRoZSBhdWRpZW5jZSAoZm9yIGlkX3Rva2VuIGFrYSBhdXRo biA9IGNsaWVudCwgYW5kIGZvciBhY2Nlc3NfdG9rZW4gYWthIGF1dGh6ID0gcmVzb3VyY2Ugc2Vy dmVyKSBwcm9iYWJseSBpcyBleHBhbmRpbmcgdGhlIGF0dGFjayBzdXJmYWNlIGZvciBzZWN1cml0 eSBhbmQgcHJpdmFjeS4gPGJyPg0KPC9zcGFuPjwvZm9udD48L2xpPjwvb2w+PGZvbnQgZmFjZT0i VGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEycHQiPkFsdGhvdWdoIHdl IHNlcGFyYXRlZCB0aGVtIG91dCwgYSBzaWduZWQgaWRfdG9rZW4gaW5jbHVkZXMgdGhlIGxlZnQg aGFzaCBvZiBhY2Nlc3NfdG9rZW4gc28gYWNjZXNzX3Rva2VuIGlzIGFsc28gcHJvdGVjdGVkLiA8 YnI+DQo8L3NwYW4+PC9mb250Pjxmb250IGZhY2U9IkNhbGlicmksIFZlcmRhbmEsIEhlbHZldGlj YSwgQXJpYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTFwdCI+PGJyPg0KPC9zcGFuPjwvZm9u dD48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTJw dCI+IDxicj4NCjwvc3Bhbj48L2ZvbnQ+PGZvbnQgZmFjZT0iQ2FsaWJyaSwgVmVyZGFuYSwgSGVs dmV0aWNhLCBBcmlhbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMXB0Ij48YnI+DQo8L3NwYW4+ PC9mb250Pjxmb250IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMnB0Ij5CZXN0LCA8YnI+DQo8L3NwYW4+PC9mb250Pjxmb250IGZhY2U9IkNhbGlicmksIFZl cmRhbmEsIEhlbHZldGljYSwgQXJpYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTFwdCI+PGJy Pg0KPC9zcGFuPjwvZm9udD48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTJwdCI+IDxicj4NCjwvc3Bhbj48L2ZvbnQ+PGZvbnQgZmFjZT0iQ2FsaWJy aSwgVmVyZGFuYSwgSGVsdmV0aWNhLCBBcmlhbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMXB0 Ij48YnI+DQo8L3NwYW4+PC9mb250Pjxmb250IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMnB0Ij5OYXQ8YnI+DQo8L3NwYW4+PC9mb250Pjxmb250IGZhY2U9 IkNhbGlicmksIFZlcmRhbmEsIEhlbHZldGljYSwgQXJpYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTFwdCI+PGJyPg0KPC9zcGFuPjwvZm9udD48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTJwdCI+IDxicj4NCjwvc3Bhbj48L2ZvbnQ+PGZvbnQg ZmFjZT0iQ2FsaWJyaSwgVmVyZGFuYSwgSGVsdmV0aWNhLCBBcmlhbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMXB0Ij48YnI+DQo8L3NwYW4+PC9mb250Pjxmb250IGZhY2U9IlRpbWVzIE5ldyBS b21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMnB0Ij5PbiBUaHUsIEp1biAyMSwgMjAxMiBh dCA1OjIxIEFNLCBMZXdpcyBBZGFtLUNBTDAyMiAmbHQ7PGEgaHJlZj0iQWRhbS5MZXdpc0Btb3Rv cm9sYXNvbHV0aW9ucy5jb20iPkFkYW0uTGV3aXNAbW90b3JvbGFzb2x1dGlvbnMuY29tPC9hPiZn dDsgd3JvdGU6PGJyPg0KPC9zcGFuPjwvZm9udD48Zm9udCBmYWNlPSJDYWxpYnJpLCBWZXJkYW5h LCBIZWx2ZXRpY2EsIEFyaWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExcHQiPjxicj4NCjwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEycHQiPkhpIElnb3IsPGJyPg0KJm5ic3A7PGJy Pg0KQXMgSnVzdGluIGp1c3QgcG9pbnRlZCBvdXQsIGNvbnNpZGVyIHRoZSBjYXNlIHdoZXJlIHRo ZSB2aWRlbyBzZXJ2ZXIgaXMgaG9zdGVkIGJ5IHRoZSBzdGF0ZSAoZS5nLiBDYWxpZm9ybmlhKSBh bmQgaXMgYWNjZXNzZWQgYnkgcG9saWNlIGFnZW5jaWVzIGluIExvcyBBbmdlbGVzLCBTYW4gRnJh bmNpc2NvLCBhbmQgU2FuIERpZWdvLiAmbmJzcDtUaGUgU3RhdGUgb2YgQ2FsaWZvcm5pYeKAmXMg dmlkZW8gc2VydmVyIGlzIHRoZSBSUy4gJm5ic3A7RWFjaCBsb2NhbCBwb2xpY2UgYWdlbmN5IChM QS9TRi9TRCkgaG9zdHMgYW4gQVMuICZuYnNwO1NvIHdoZW4gYSBwb2xpY2Ugb2ZmaWNlciBmcm9t IExBUEQgbGF1bmNoZXMgdGhlIHZpZGVvIGNsaWVudCBhcHAgb24gdGhlIGlQaG9uZSwgdGhlIGNs aWVudCBtYWtlcyBhbiBPQXV0aCByZXF1ZXN0IHRvIHRoZSBMQVBE4oCZcyBBUywgd2hpY2ggYXV0 aGVudGljYXRlcyB0aGUgcG9saWNlIG9mZmljZXIgdXNpbmcgYWdlbmN5IGxldmVsIGNyZWRlbnRp YWxzLiAmbmJzcDtUaGUgYWNjZXNzIHRva2VuIGlzc3VlZCB0byB0aGUgdmlkZW8gY2xpZW50IGFw cCBvbiB0aGUgaVBob25lIGlzIGEgSldULCBzaWduZWQgYnkgdGhlIGFnZW5jeSBBUywgd2hpY2gg bWlnaHQgbG9vayBzb21ldGhpbmcgbGlrZSB0aGlzOjxicj4NCiZuYnNwOzxicj4NCnvigJx0eXDi gJ064oCdSldU4oCdLCJhbGciOiJFUzI1NiJ9PGJyPg0KeyJpc3MiOiI8YSBocmVmPSJodHRwczov L2FzLmxhcGQuY2FsaWZvcm5pYS5nb3YiPmh0dHBzOi8vYXMubGFwZC5jYWxpZm9ybmlhLmdvdjwv YT4iLCA8YnI+DQombmJzcDsmbmJzcDsicHJuIjoiPGEgaHJlZj0iYWxpY2VAbGFwZC5jYWxpZm9y bmlhLmdvdiI+YWxpY2VAbGFwZC5jYWxpZm9ybmlhLmdvdjwvYT4iLDxicj4NCiZuYnNwOyZuYnNw OyJhdWQiOiIgPGEgaHJlZj0iaHR0cHM6Ly92aWRlb19zZXJ2ZXIxQHN0YXRlLmNhbGlmb3JuaWEu Z292Ij5odHRwczovL3ZpZGVvX3NlcnZlcjFAc3RhdGUuY2FsaWZvcm5pYS5nb3Y8L2E+Iiw8YnI+ DQombmJzcDsmbmJzcDsiaWF0IjoxMzAwODE1NzgwLDxicj4NCiZuYnNwOyZuYnNwOyJleHAiOjEz MDA4MTkzODAsPGJyPg0KJm5ic3A7Jm5ic3A7ImFjciI64oCdcGFzc3dvcmTigJ19PGJyPg0KaHE0 emsrWmtuamdnQ1FnWm03ZWE4Zkk3OWdKRXNSeTNFOExIRHBZWFdRSWdacGtKTjlDTUxHOEVOUjRO cncrbjdpeXppeEJ2S1hYOFA1M0JUQ1Q0VmdoUEJXaEZZU3Q5dEhXdS9BdEpmT1RoNnFhQXNOZGVD eUc4NmptdHAzVERNd3VML2NCVWoyT3RCWk9RTUZuN2pROVlCN2tsSXozUnFWTCt3Tm1lV0k0PTxi cj4NCiZuYnNwOzxicj4NClRoZSBKV1QgbWlnaHQgYmUgb3B0aW9uYWxseSBlbmNyeXB0ZWQgdXNp bmcgSldFLiA8YnI+DQombmJzcDs8YnI+DQpJIHRoaW5rIHdoYXQgaXMgYmVjb21pbmcgY2xlYXIg KGFuZCB0aGlzIGlzIHdoYXQgSeKAmW0gdHJ5aW5nIHRvIHZldCkgaXMgdGhhdCB3aGlsZSB0aGVy ZSBpcyBub3RoaW5nIGluIE9BdXRoIHRoYXQgc3BlY2lmaWVzIGF1dGhlbnRpY2F0aW9uLCBpdCAq PGI+Y2FuPC9iPiogYmUgdXNlZCBmb3IgQXV0aGVudGljYXRpb24sIGlmIGRvbmUgaW4gdGhlIHdh eSB0aGF0IEkgZGVzY3JpYmUuICZuYnNwO0lmIEnigJltIHdyb25nIGFib3V0IHRoaXMsIEkgcmVh bGx5IG5lZWQgdG8ga25vdy4gJm5ic3A7SeKAmXZlIHZldHRlZCB0aGlzIGlkZWEgb2YgbWluZSB3 aXRoIHF1aXRlIG9mIGZldyBwZW9wbGUgbm93IOKAkyBib3RoIHdpdGhpbiBjb250ZXh0IG9mIHRo ZSBsaXN0IGFuZCBvZmYtbGluZSDigJMgYW5kIEkgdGhpbmsgSeKAmW0gb2theS4gSWYgeW91IHNl ZSBhbnkgaG9sZXMgaW4gd2hhdCBJIGRlc2NyaWJlLCBwbGVhc2UgcG9pbnQgdGhlbSBvdXQgYXMg SSB3b3VsZCBwcmVmZXIgdG8gdW5jb3ZlciB0aGVtIG5vdyByYXRoZXIgdGhhbiBhZnRlciBpbXBs ZW1lbnRhdGlvbiBvciBkZXBsb3ltZW50ITxicj4NCiZuYnNwOzxicj4NCkVzc2VudGlhbGx5IEni gJltIHVzaW5nIE9BdXRoIGFzIGEgUkVTVGZ1bCB2ZXJzaW9uIG9mIFdTLVRydXN0LCB3aGVyZSBt eSBjbGllbnQgY2FuIGV4Y2hhbmdlIHByaW1hcnkgY3JlZGVudGlhbHMgZm9yIGEgdG9rZW4gKEpX VCkgYW5kIHByZXNlbnQgdGhhdCB0b2tlbiB0byBhIHNlcnZlciBhcyBzZWNvbmRhcnkgYXV0aGVu dGljYXRpb24uICZuYnNwO0l04oCZcyBqdXN0IHRoYXQgaXTigJlzIFJFU1RmdWwgaW5zdGVhZCBv ZiBTT0FQIDotKTxicj4NCiZuYnNwOzxicj4NCkFzIEp1c3RpbiBhcyBwb2ludGVkIG91dCDigKYg SeKAmXZlIGJhc2ljYWxseSBtYWRlIHRoZSBhY2Nlc3MtdG9rZW4gbG9vayBsaWtlIHRoZSBpZF90 b2tlbiBvZiBDb25uZWN0LiAmbmJzcDtJIHdhcyBhY3R1YWxseSBob3BpbmcgdG8gbGF5IGEgcGF0 aCB0byBDb25uZWN0LCBhbmQgdXNlIHRoZSBpZF90b2tlbiDigKYgdW50aWwgaXQgd2FzIGFsc28g cG9pbnRlZCBvdXQgdGhhdCB0aGUgaWRfdG9rZW4gaXMgcmVhbGx5IG1lYW50IGZvciB0aGUgY29u c3VtcHRpb24gb2YgdGhlIGNsaWVudCwgbm90IHRoZSBSUyA6LSg8YnI+DQombmJzcDs8YnI+DQom bmJzcDs8YnI+DQombmJzcDs8YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMXB0 Ij48YnI+DQo8L3NwYW4+PGZvbnQgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMHB0 Ij48Yj5Gcm9tOjwvYj4gPGEgaHJlZj0ib2F1dGgtYm91bmNlc0BpZXRmLm9yZyI+b2F1dGgtYm91 bmNlc0BpZXRmLm9yZzwvYT4gWzxhIGhyZWY9Im1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3Jn Ij5tYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwvYT5dIDxiPk9uIEJlaGFsZiBPZiA8L2I+ SWdvciBGYXluYmVyZzxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEp1bmUgMjAsIDIwMTIg MjozOSBQTTxicj4NCjxiPlRvOjwvYj4gPGEgaHJlZj0ib2F1dGhAaWV0Zi5vcmciPm9hdXRoQGll dGYub3JnPC9hPjxicj4NCjwvc3Bhbj48L2ZvbnQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMXB0 Ij48YnI+DQo8L3NwYW4+PC9mb250Pjxmb250IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMnB0Ij48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1X R10gUmVwb3J0IGFuIGF1dGhlbnRpY2F0aW9uIGlzc3VlPGJyPg0KJm5ic3A7PGJyPg0KQnV0IHRo aXMgdXNlIGNhc2UgJm5ic3A7ZG9lcyBuZWVkIE9BdXRoLCBwZXJpb2Q6PGJyPg0KPC9zcGFuPjwv Zm9udD48Zm9udCBmYWNlPSJDYWxpYnJpLCBWZXJkYW5hLCBIZWx2ZXRpY2EsIEFyaWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExcHQiPjxicj4NCjwvc3Bhbj48L2ZvbnQ+PGZvbnQgZmFjZT0i VGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEycHQiPjxicj4NCjxicj4N Cjwvc3Bhbj48L2ZvbnQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMnB0Ij48Zm9udCBmYWNlPSJD YWxpYnJpLCBWZXJkYW5hLCBIZWx2ZXRpY2EsIEFyaWFsIj5UaGUgdmlkZW8gc2VydmVyIGlzIHVu ZGVyIHRoZSBjb250cm9sIG9mIGEgcG9saWNlIGFnZW5jeSwgYW5kIHBvbGljZSBvZmZpY2VycyBt dXN0IGxvZ29uIHRvIHRoZSB2aWRlbyBzZXJ2ZXIgaW4gb3JkZXIgdG8gYWNjZXNzIHZpZGVvIGNv bnRlbnQuPGJyPg0KPC9mb250Pjxmb250IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PGJyPg0KVGhl cmUgaXMgbm8gZGVsZWdhdGlvbiBoZXJlLCBhbmQgdGhlcmUgaXMgbm8gbmVlZCB0byB1c2UgdGhp cmQgcGFydHkgZm9yIGF1dGhlbnRpY2F0aW9uLiA8YnI+DQo8YnI+DQpJZ29yPGJyPg0KPGJyPg0K T24gNi8yMC8yMDEyIDM6MjYgUE0sIEp1c3RpbiBSaWNoZXIgd3JvdGU6IDxicj4NCjwvZm9udD48 L3NwYW4+PGZvbnQgZmFjZT0iQ2FsaWJyaSwgVmVyZGFuYSwgSGVsdmV0aWNhLCBBcmlhbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMXB0Ij48YnI+DQo8L3NwYW4+PC9mb250Pjxmb250IGZhY2U9 IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMnB0Ij5JbiBjYXNlIGl0 IHdhc24ndCBjbGVhciwgSSB3YW50IHRvIHJlc3RhdGUgdGhlIG9yaWdpbmFsIHByb2JsZW0gYXMg YmVzdCBhcyBJIHVuZGVyc3RhbmQgaXQgaW4gYSB3YXkgdGhhdCBob3BlZnVsbHkgY2xlYXJzIGl0 IHVwOjxicj4NCjxicj4NCkFwcCBBIGFuZCBhcHAgQiBhcmUgYm90aCB2YWxpZCByZWdpc3RlcmVk IE9BdXRoIGNsaWVudHMgdG8gYW4gT0F1dGggcHJvdGVjdGVkIHNlcnZpY2UuIDxicj4NCjxicj4N ClRoZSBwcm9ibGVtIHN0YXJ0cyB3aGVuIGFwcCBBIGdldHMgaGFuZGVkIGEgdG9rZW4gdGhhdCB3 YXMgaXNzdWVkIGZvciBhcHAgQiBhbmQgdXNlcyBpdCB0byBjYWxsIGFuIGlkZW50aXR5IEFQSSBv biB0aGUgT0F1dGggc2VydmljZS4gU2luY2UgYXBwIEIgY2FuIGdldCB0b2tlbnMganVzdCBmaW5l LCB0aGV5J3JlIGJlYXJlciB0b2tlbnMsIHRoaXMgaXMgYSBmYWlybHkgYmFzaWMgYXBpIGNhbGws IHRoaXMgZnVuY3Rpb24gd29ya3MganVzdCBmaW5lIGFuZCByZXR1cm5zIHRoZSB1c2VyIGluZm8u IFRoaXMgbWFrZXMgc2Vuc2UsIHNpbmNlIGFueW9uZSB3aG8gaG9sZHMgQSdzIHRva2VucyBjYW4g ZG8gd2hhdGV2ZXIgQSBjYW4gZG8gb24gYmVoYWxmIG9mIHRoYXQgdXNlci4gVGhlIGlzc3VlcyBz dGFydCB3aGVuIGFwcCBCIHRoZW4gZGVjaWRlcyB0aGF0IHNpbmNlIHRoZXkgY2FuIG1ha2UgYSBj YWxsIHRvIHRoZSBpZGVudGl0eSBBUEkgd2l0aCBhIHRva2VuIHRoZW4gdGhlIHVzZXIgKm11c3Qq IGJlIHByZXNlbnQuIEluIG90aGVyIHdvcmRzLCBhcHAgQiBpcyBjb25mdXNpbmcgYXV0aG9yaXph dGlvbiB0byBjYWxsIGFuIEFQSSB3aXRoIGF1dGhlbnRpY2F0aW9uIG9mIHRoZSBzZXNzaW9uLjxi cj4NCjxicj4NCk9wZW5JRCBDb25uZWN0IGZpeGVzIHRoaXMgbWlzc2VkIGFzc3VtcHRpb24gYnkg YmluZGluZyB0aGUgSUQgVG9rZW4gdG8gdGhlIHNlc3Npb24gYW5kIHNlbmRpbmcgaXQgYWxvbmcg c2lkZSB0aGUgYWNjZXNzIHRva2VuLCBidXQgYXMgeW91IHBvaW50ZWQgb3V0LCBpdCdzIG1lYW50 IGZvciBjb25zdW1wdGlvbiBhdCB0aGUgY2xpZW50LCBub3QgdGhlIHJlc291cmNlIHNlcnZlciwg aW4gZ2VuZXJhbC4gVGhhdCBkb2Vzbid0IG1lYW4geW91IGNhbid0IHNlbmQgaXQgdG8gYSByZXNv dXJjZSBzZXJ2ZXIgZm9yIHlvdXIgb3duIHB1cnBvc2VzLCBvZiBjb3Vyc2UuIFRoYXQncyBhY3R1 YWxseSBob3cgdGhlIHNlc3Npb24gbWFuYWdlbWVudCBlbmRwb2ludCB3b3JrcyBpbiBDb25uZWN0 Ljxicj4NCjxicj4NClRoaXMgaXNuJ3QgdGhlIG9ubHkgd2F5IHRvIGhhbmRsZSB0aGlzIHByb2Js ZW0gLS0gaWYgeW91IHB1dCBzb21lIHN0cnVjdHVyZSBpbiB5b3VyIHRva2Vucywgc3VjaCBhcyB3 aXRoIEpXVCBvciBTQU1MLCB0aGVuIGFwcCBBIGNhbiB0ZWxsIHRoYXQgdGhpcyBpc24ndCBhIHRv a2VuIGlzc3VlZCB0byBhcHAgQSwgYnV0IHRvIGFwcCBCLCBzbyBpdCBjYW4gY2FsbCBzaGVuYW5p Z2FucyBhbmQgcmVqZWN0IGl0IHRoZW4gYW5kIHRoZXJlLjxicj4NCjxicj4NCiZuYnNwOy0tIEp1 c3Rpbjxicj4NCjxicj4NCk9uIDA2LzIwLzIwMTIgMTA6MDMgQU0sIExld2lzIEFkYW0tQ0FMMDIy IHdyb3RlOiA8YnI+DQo8L3NwYW4+PC9mb250PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTJwdCI+ PGZvbnQgZmFjZT0iQ2FsaWJyaSwgVmVyZGFuYSwgSGVsdmV0aWNhLCBBcmlhbCI+SSBhbSBlbnRp cmVseSBjb25mdXNlZC48YnI+DQombmJzcDs8YnI+DQpJIHVuZGVyc3RhbmQgd2hhdCBldmVyeWJv ZHkgaXMgc2F5aW5nIGZvciBjb25maWRlbnRpYWwgY2xpZW50cywgbm8gcHJvYmxlbSBoZXJlLjxi cj4NCiZuYnNwOzxicj4NCkkgZmFsbCBhcGFydCB3aGVuIHRoaW5raW5nIG9mIGlQaG9uZSBhcHBz LiAmbmJzcDtDb25zaWRlciB0aGUgc2NlbmFyaW8gd2hlcmUgSSBkZXBsb3kgYSB2aWRlbyBzZXJ2 ZXIsIGFuZCB3cml0ZSBhbiBpUGhvbmUgYXBwIHRvIHRhbGsgdG8gdGhlIHZpZGVvIHNlcnZlci4g Jm5ic3A7VGhlIHZpZGVvIHNlcnZlciBpcyB1bmRlciB0aGUgY29udHJvbCBvZiBhIHBvbGljZSBh Z2VuY3ksIGFuZCBwb2xpY2Ugb2ZmaWNlcnMgbXVzdCBsb2dvbiB0byB0aGUgdmlkZW8gc2VydmVy IGluIG9yZGVyIHRvIGFjY2VzcyB2aWRlbyBjb250ZW50LiAmbmJzcDtTbyB0aGUgcG9saWNlIG9m ZmljZSBsYXVuY2hlcyB0aGVpciBpUGhvbmUgdmlkZW8gY2xpZW50IGFwcC48YnI+DQombmJzcDs8 YnI+DQpJZiBJIHdhbnRlZCB0byBzb2x2ZSBhdXRoZW50aWNhdGlvbiB1c2luZyDigJx0cmFkaXRp b25hbOKAnSBjbGllbnQtc2VydmVyIGF1dGhlbnRpY2F0aW9uLCB0aGUgdXNlciBlbnRlcnMgdGhl aXIgdXNlcm5hbWUgLyBwYXNzd29yZCBpbnRvIHRoZSBjbGllbnQsIGFuZCB0aGUgY2xpZW50IHNl bmRzIHRoZSB1c2VybmFtZSAvIHBhc3N3b3JkIG9mZiB0byB0aGUgc2VydmVyLCB3aGljaCBhdXRo ZW50aWNhdGVzIGl0LCBvciBwb3NzaWJseSB1c2VzIEhUVFAgZGlnZXN0LiA8YnI+DQo8YnI+DQpJ ZiBJIHdhbnRlZCB0byB1c2UgT3BlbklELCB0aGUgY2xpZW50IHdvdWxkIGF0dGVtcHQgdG8gcmVh Y2ggdGhlIHZpZGVvIHNlcnZlciAoUlApLCB0aGUgc2VydmVyIHdvdWxkIHJlZGlyZWN0IHRoZSBj bGllbnQgdG8gdGhlIE9QLCBPUCBhdXRoZW50aWNhdGVzIHVzZXIsIGFuZCBPUCByZWRpcmVjdHMg Y2xpZW50IGJhY2sgdG8gdGhlIHNlcnZlci9SUCB3aXRoIGFuIGFzc2VydGlvbiB0aGF0IHByaW1h cnkgYXV0aGVudGljYXRpb24gd2FzIHN1Y2Nlc3NmdWwuIDxicj4NCjxicj4NCklmIEkgd2FudGVk IHRvIHVzZSBPQXV0aCwgdGhlIGNsaWVudCB3b3VsZCBzZW5kIGFuIGF1dGhvcml6YXRpb24gcmVx dWVzdCB0byB0aGUgc2VydmVy4oCZcyBBUywgd2hpY2ggd291bGQgYXV0aGVudGljYXRlIHRoZSB1 c2VyIG9mIHRoZSBjbGllbnQsIGFuZCB1bHRpbWF0ZWx5IHJlc3VsdCBpbiB0aGUgY2xpZW50IHBv c3Nlc3NpbmcgYW4gYWNjZXNzLXRva2VuLiAmbmJzcDtNeSB0aGlua2luZyBpcyB0aGF0IHRoaXMg YWNjZXNzIHRva2VuIChsZXTigJlzIGFzc3VtZSBpdOKAmXMgYSBKV1QpIHdvdWxkIGNvbnRhaW4g dGhlIHVzZXLigJlzIGlkZW50aXR5LCBhIHN0YXRlbWVudCBvZiB3aGF0IHR5cGUgb2YgcHJpbWFy eSBhdXRoZW50aWNhdGlvbiB3YXMgdXNlZCAoYXV0aCBjb250ZXh0KSwgYW4gZXhwaXJhdGlvbiwg YW5kIGFuIGF1ZGllbmNlIGNsYWltLiAmbmJzcDtUaGlzIHNvdW5kcyBhIGxvdCBsaWtlIGF1dGhl bnRpY2F0aW9uIHRvIG1lLCBhbmQgaXTigJlzIHdoZXJlIEkgZ2V0IGNvbmZ1c2VkLiAmbmJzcDtJ cyBpdCBqdXN0IGJlY2F1c2UgT0F1dGggZG9lcyBub3QgZXhwbGljaXRseSBkZWZpbmUgdGhpcz8g Jm5ic3A7SXMgdGhlcmUgYSB0aHJlYXQgaW4gdXNpbmcgT0F1dGggYXMgSSBkZXNjcmliZT8gPGJy Pg0KPGJyPg0KSWYgSSB3YW50ZWQgdG8gdXNlIENvbm5lY3QsIHdlbGwgSeKAmW0gbm90IGV2ZW4g c3VyZSBob3cgdGhlIGlkX3Rva2VuIGFzIGRlZmluZWQgYnkgQ29ubmVjdCBoZWxwcyB0aGlzIHVz ZSBjYXNlLiAmbmJzcDtUaGUgaWRfdG9rZW4gc2VlbXMgdG8gbWFrZSBzZW5zZSB3aGVuIHRoZSBj bGllbnQgaXMgYSBjb25maWRlbnRpYWwgd2ViIHNlcnZlciwgYnV0IGl04oCZcyBub3QgY2xlYXIg d2hhdCBhbiBpUGhvbmUgYXBwIHdvdWxkIGRvIHdpdGggdGhlIGlkX3Rva2VuIOKApiBpdOKAmXMg dGhlIHNlcnZlciBpbiB0aGUgYmFja2VuZCB0aGF0IG5lZWRzIHRvIGF1dGhlbnRpY2F0ZSB0aGUg dXNlciwgdGhlIGlQaG9uZSBhcHAgaXMganVzdCBhbiBpbnRlcmZhY2UgdG8gdGFsayB0byB0aGUg c2VydmVyLiAmbmJzcDtBbmQgaXQgc2VlbXMgYXMgSSBsZWFybiBtb3JlIGFib3V0IGNvbm5lY3Qg dGhhdCB0aGUgaWRfdG9rZW4gaXMgbm90IG1lYW50IHRvIGJlIHNlbnQgZnJvbSB0aGUgaVBob25l IGFwcCB0byB0aGUgc2VydmVyLCBqdXN0IHRoZSBhY2Nlc3MgdG9rZW4uICZuYnNwO1NvIGl04oCZ cyByZWFsbHkgbm90IGNsZWFyIGhvdyBDb25uZWN0IGhlbHBzIHNvbHZlIGF1dGhlbnRpY2F0aW9u IGZvciBhbiBpUGhvbmUgY2xpZW50IGFwcCB0YWxraW5nIHRvIGEgdmlkZW8gc2VydmVyLiAmbmJz cDtJZiBJ4oCZbSBzZW5kaW5nIGFjY2Vzcy10b2tlbnMsIGl04oCZcyBqdXN0IE9BdXRoIGFnYWlu Ljxicj4NCjwvZm9udD48L3NwYW4+PGZvbnQgZmFjZT0iQ2FsaWJyaSwgVmVyZGFuYSwgSGVsdmV0 aWNhLCBBcmlhbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMXB0Ij48YnI+DQo8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMnB0Ij4gPGJyPg0KV2hhdCBhbSBJIHN0aWxsIG1pc3Npbmc/ PGJyPg0KYWRhbTxicj4NCiZuYnNwOzxicj4NCiZuYnNwOzxicj4NCjwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExcHQiPjxicj4NCjwvc3Bhbj48Zm9udCBzaXplPSIyIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwcHQiPjxiPkZyb206PC9iPiA8YSBocmVmPSJvYXV0aC1ib3VuY2VzQGll dGYub3JnIj5vYXV0aC1ib3VuY2VzQGlldGYub3JnPC9hPiBbPGEgaHJlZj0ibWFpbHRvOm9hdXRo LWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnPC9hPl0gPGI+ T24gQmVoYWxmIE9mIDwvYj5LcmlzdG9mb3IgU2VsZGVuPGJyPg0KPGI+U2VudDo8L2I+IFNhdHVy ZGF5LCBKdW5lIDE2LCAyMDEyIDExOjMzIEFNPGJyPg0KPGI+VG86PC9iPiBub3YgbWF0YWtlOyBv YXV0aDxicj4NCjxiPkNjOjwvYj4gWXVjaGVuIFpob3U7IEx1a2UgTWVsaWE7IFNodW8gQ2hlbiAo TVNSKTxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBSZXBvcnQgYW4gYXV0aGVu dGljYXRpb24gaXNzdWU8YnI+DQo8L3NwYW4+PC9mb250PjwvZm9udD48Zm9udCBmYWNlPSJUaW1l cyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTJwdCI+IDxicj4NCjwvc3Bhbj48 L2ZvbnQ+PGZvbnQgZmFjZT0iQ2FsaWJyaSwgVmVyZGFuYSwgSGVsdmV0aWNhLCBBcmlhbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMXB0Ij48YnI+DQo8L3NwYW4+PC9mb250Pjxmb250IGZhY2U9 IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMnB0Ij5Ob3YgZGVtb25z dHJhdGVkIHRoZSBwcm9ibGVtIHRvIHVzIGF0IFlhcHAgYW5kIHdlIHVzZWQgc29sdXRpb24gNCAo YmVjYXVzZSB0aGUgc29sdXRpb24gaXMgc2VydmVyIHNpZGUgYW5kIG91ciBhcHAgd2FzIGluIHRo ZSBhcHAgc3RvcmUpLjxicj4NCjwvc3Bhbj48L2ZvbnQ+PGZvbnQgZmFjZT0iQ2FsaWJyaSwgVmVy ZGFuYSwgSGVsdmV0aWNhLCBBcmlhbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMXB0Ij48YnI+ DQo8L3NwYW4+PC9mb250Pjxmb250IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMnB0Ij4gPGJyPg0KPC9zcGFuPjwvZm9udD48Zm9udCBmYWNlPSJDYWxpYnJp LCBWZXJkYW5hLCBIZWx2ZXRpY2EsIEFyaWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExcHQi Pjxicj4NCjwvc3Bhbj48L2ZvbnQ+PGZvbnQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEycHQiPkZCIENvbm5lY3QgaXMgYXV0aGVudGljYXRpb24gPGk+YW5k PC9pPiBhdXRob3JpemF0aW9uLCB3aGVyZSBPQXV0aCAyIGlzIGNvbmNlcm5lZCBvbmx5IHdpdGgg YXV0aG9yaXphdGlvbiDigJMgSSdtIG5vdCBzdXJlIHRoYXQgYXBwIGRldmVsb3BlcnMgYXBwcmVj aWF0ZSB0aGlzIHN1YnRsZXR5Ljxicj4NCjwvc3Bhbj48L2ZvbnQ+PGZvbnQgZmFjZT0iQ2FsaWJy aSwgVmVyZGFuYSwgSGVsdmV0aWNhLCBBcmlhbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMXB0 Ij48YnI+DQo8L3NwYW4+PC9mb250Pjxmb250IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMnB0Ij4gPGJyPg0KPC9zcGFuPjwvZm9udD48Zm9udCBmYWNlPSJD YWxpYnJpLCBWZXJkYW5hLCBIZWx2ZXRpY2EsIEFyaWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExcHQiPjxicj4NCjwvc3Bhbj48L2ZvbnQ+PGZvbnQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEycHQiPldpdGggT0F1dGggMiB5b3UgYXV0aG9yaXplIGFu IGFwcCB0byB1c2UgYSBwcm90ZWN0ZWQgcmVzb3VyY2UuICZuYnNwO1dpdGggRkIgQ29ubmVjdCwg eW91IGRvIHRoYXQsIGJ1dCA8aT5hbHNvPC9pPiBhdXRoZW50aWNhdGUgd2l0aCB0aGUgYXBwIHlv dSBhcmUgYXV0aG9yaXppbmcuPGJyPg0KPC9zcGFuPjwvZm9udD48Zm9udCBmYWNlPSJDYWxpYnJp LCBWZXJkYW5hLCBIZWx2ZXRpY2EsIEFyaWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExcHQi Pjxicj4NCjwvc3Bhbj48L2ZvbnQ+PGZvbnQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEycHQiPiA8YnI+DQo8L3NwYW4+PC9mb250Pjxmb250IGZhY2U9IkNh bGlicmksIFZlcmRhbmEsIEhlbHZldGljYSwgQXJpYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTFwdCI+PGJyPg0KPC9zcGFuPjwvZm9udD48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTJwdCI+U28gdGhlIGFjY2Vzc190b2tlbiBwcm90ZWN0cyBu b3QganVzdCB0aGUgRkIgcmVzb3VyY2VzIGJ1dCB0aGUgYXV0aCBlbmQgcG9pbnQgb2YgdGhlIGF1 dGhvcml6ZWQgYXBwICh2ZXJ5IGNvbW1vbiB3aXRoIGFwcHMgdGhhdCB1c2UgdGhlIGlPUyBTREsp LiAmbmJzcDtTbyBub3cgdGhlIGFwcCBuZWVkcyBhIHdheSB0byB2ZXJpZnkgdGhhdCBpdCB3YXMg dGhlIGFwcCB0aGF0IHdhcyBhdXRob3JpemVkIHRvIEZCLjxicj4NCjwvc3Bhbj48L2ZvbnQ+PGZv bnQgZmFjZT0iQ2FsaWJyaSwgVmVyZGFuYSwgSGVsdmV0aWNhLCBBcmlhbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMXB0Ij48YnI+DQo8L3NwYW4+PC9mb250Pjxmb250IGZhY2U9IlRpbWVzIE5l dyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMnB0Ij4gPGJyPg0KPC9zcGFuPjwvZm9u dD48Zm9udCBmYWNlPSJDYWxpYnJpLCBWZXJkYW5hLCBIZWx2ZXRpY2EsIEFyaWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExcHQiPjxicj4NCjwvc3Bhbj48L2ZvbnQ+PGZvbnQgZmFjZT0iVGlt ZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEycHQiPlNvbHV0aW9uIDQgZXhw bGFuYXRpb246IG9uIEZCIHlvdSBjYW4gcmVnaXN0ZXIgYSBpUGhvbmUgYXBwIGFuZCBhIHNlcnZl ciBhcHAgd2l0aCB0aGUgc2FtZSBjbGllbnRfaWQgYW5kIGdldCBhIGNsaWVudF9zZWNyZXQgZm9y IHVzZSBvbiB0aGUgc2VydmVyLiAmbmJzcDtUaGUgc2VydmVyIHNpZGUgQVBJIHBvc3RzIHRoZSBh Y2Nlc3NfdG9rZW4sIGNsaWVudF9pZCwgYW5kIGNsaWVudF9zZWNyZXQgdG8gPGEgaHJlZj0iaHR0 cHM6Ly9ncmFwaC5mYWNlYm9vay5jb20vYXBwIj5odHRwczovL2dyYXBoLmZhY2Vib29rLmNvbS9h cHA8L2E+ICZsdDs8YSBocmVmPSJodHRwczovL2dyYXBoLmZhY2Vib29rLmNvbS9hcHA/YWNjZXNz X3Rva2VuPVlPVVJfVE9LRU4iPmh0dHBzOi8vZ3JhcGguZmFjZWJvb2suY29tL2FwcD9hY2Nlc3Nf dG9rZW49WU9VUl9UT0tFTjwvYT4mZ3Q7ICZuYnNwO3RvIHZlcmlmeSB0aGF0IHRoZSBiZWFyZXIg dG9rZW4gYWN0dWFsbHkgYmVsb25ncyB0byB0aGUgYXBwIHRoYXQgaXMgYmVpbmcgYXV0aGVudGlj YXRlZCBiZWZvcmUgYXNzdW1pbmcgdGhleSBhcmUgYXV0aG9yaXplZCB0byB0aGUgYXBwJ3MgcHJv dGVjdGVkIHJlc291cmNlcy48YnI+DQo8L3NwYW4+PC9mb250Pjxmb250IGZhY2U9IkNhbGlicmks IFZlcmRhbmEsIEhlbHZldGljYSwgQXJpYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTFwdCI+ PGJyPg0KPC9zcGFuPjwvZm9udD48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTJwdCI+IDxicj4NCjwvc3Bhbj48L2ZvbnQ+PGZvbnQgZmFjZT0iQ2Fs aWJyaSwgVmVyZGFuYSwgSGVsdmV0aWNhLCBBcmlhbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MXB0Ij48YnI+DQo8L3NwYW4+PC9mb250Pjxmb250IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMnB0Ij5LcmlzPGJyPg0KJm5ic3A7PGJyPg0KPC9zcGFuPjwv Zm9udD48Zm9udCBmYWNlPSJDYWxpYnJpLCBWZXJkYW5hLCBIZWx2ZXRpY2EsIEFyaWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExcHQiPjxicj4NCjwvc3Bhbj48L2ZvbnQ+PGZvbnQgZmFjZT0i VGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEycHQiPk9uIEp1biAxNSwg MjAxMiwgYXQgODoyMiBQTSwgbm92IG1hdGFrZSB3cm90ZTo8YnI+DQo8YnI+DQo8YnI+DQpUaGVy ZSBhcmUgNCB3YXlzIHRvIGZpeCB0aGlzIGlzc3VlLjxicj4NCjwvc3Bhbj48L2ZvbnQ+PGZvbnQg ZmFjZT0iQ2FsaWJyaSwgVmVyZGFuYSwgSGVsdmV0aWNhLCBBcmlhbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMXB0Ij48YnI+DQo8L3NwYW4+PC9mb250Pjxmb250IGZhY2U9IlRpbWVzIE5ldyBS b21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMnB0Ij4gPGJyPg0KPC9zcGFuPjwvZm9udD48 Zm9udCBmYWNlPSJDYWxpYnJpLCBWZXJkYW5hLCBIZWx2ZXRpY2EsIEFyaWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExcHQiPjxicj4NCjwvc3Bhbj48L2ZvbnQ+PGZvbnQgZmFjZT0iVGltZXMg TmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEycHQiPjEuIFVzZSByZXNwb25zZV90 eXBlPXRva2VuJTIwY29kZSAoSXQncyBub3QgaW4gT0F1dGggMi4wIENvcmUsIGJ1dCBzZWVtcyBi ZXN0IHdheSBmb3IgaW50ZXJvcGVyYWJpbGl0eSk8YnI+DQo8L3NwYW4+PC9mb250Pjxmb250IGZh Y2U9IkNhbGlicmksIFZlcmRhbmEsIEhlbHZldGljYSwgQXJpYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTFwdCI+PGJyPg0KPC9zcGFuPjwvZm9udD48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9t YW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTJwdCI+Mi4gVXNlIHNpbmdlZF9yZXF1ZXN0IChv ciBzb21lIHNpZ25lZCB0b2tlbiBsaWtlIEpXVCk8YnI+DQo8L3NwYW4+PC9mb250Pjxmb250IGZh Y2U9IkNhbGlicmksIFZlcmRhbmEsIEhlbHZldGljYSwgQXJpYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTFwdCI+PGJyPg0KPC9zcGFuPjwvZm9udD48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9t YW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTJwdCI+My4gVXNlIGdyYW50X3R5cGU9ZmJfZXhj aGFuZ2VfdG9rZW4gKEZhY2Vib29rIGN1c3RvbSB3YXkpPGJyPg0KPC9zcGFuPjwvZm9udD48Zm9u dCBmYWNlPSJDYWxpYnJpLCBWZXJkYW5hLCBIZWx2ZXRpY2EsIEFyaWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExcHQiPjxicj4NCjwvc3Bhbj48L2ZvbnQ+PGZvbnQgZmFjZT0iVGltZXMgTmV3 IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEycHQiPjQuIEFjY2VzcyB0byA8YSBocmVm PSJodHRwczovL2dyYXBoLmZhY2Vib29rLmNvbS9hcHA/YWNjZXNzX3Rva2VuPVlPVVJfVE9LRU4i Pmh0dHBzOi8vZ3JhcGguZmFjZWJvb2suY29tL2FwcD9hY2Nlc3NfdG9rZW49WU9VUl9UT0tFTjwv YT4gKEZhY2Vib29rIGN1c3RvbSB3YXksIG1vcmVvdmVyIHVuZG9jdW1lbnRlZCBBUEkpPGJyPg0K PC9zcGFuPjwvZm9udD48Zm9udCBmYWNlPSJDYWxpYnJpLCBWZXJkYW5hLCBIZWx2ZXRpY2EsIEFy aWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExcHQiPjxicj4NCjwvc3Bhbj48L2ZvbnQ+PGZv bnQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEycHQiPiA8 YnI+DQo8L3NwYW4+PC9mb250Pjxmb250IGZhY2U9IkNhbGlicmksIFZlcmRhbmEsIEhlbHZldGlj YSwgQXJpYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTFwdCI+PGJyPg0KPC9zcGFuPjwvZm9u dD48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTJw dCI+VHdvIGlQaG9uZSBhcHAgZGV2ZWxvcGVycyBJIHJlcG9ydGVkIHRoaXMgaXNzdWUgZml4ZWQg aXQgYnkgdXNpbmcgKDQpLjxicj4NCjwvc3Bhbj48L2ZvbnQ+PGZvbnQgZmFjZT0iQ2FsaWJyaSwg VmVyZGFuYSwgSGVsdmV0aWNhLCBBcmlhbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMXB0Ij48 YnI+DQo8L3NwYW4+PC9mb250Pjxmb250IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMnB0Ij4gPGJyPg0KPC9zcGFuPjwvZm9udD48Zm9udCBmYWNlPSJDYWxp YnJpLCBWZXJkYW5hLCBIZWx2ZXRpY2EsIEFyaWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx cHQiPjxicj4NCjwvc3Bhbj48L2ZvbnQ+PGZvbnQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEycHQiPkkgYWxzbyB0cmllZCB0byB1c2UgKDEpIGZvciBteSBv d24gaVBob25lIGFwcCBpbXBsZW1lbnRhdGlvbiwgYnV0IHVuZm9ydHVuYXRlbHkgaXQgZG9lc24n dCB3b3JrIHdoZW4gdXNpbmcgYXV0aG9yaXphdGlvbiBjb2RlcyBvYnRhaW5lZCB2aWEgRkIgaU9T IFNESy48YnI+DQo8L3NwYW4+PC9mb250Pjxmb250IGZhY2U9IkNhbGlicmksIFZlcmRhbmEsIEhl bHZldGljYSwgQXJpYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTFwdCI+PGJyPg0KPC9zcGFu PjwvZm9udD48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTJwdCI+U28gSSdtIHVzaW5nICgzKSBpbiBteSBjYXNlLjxicj4NCjwvc3Bhbj48L2ZvbnQ+ PGZvbnQgZmFjZT0iQ2FsaWJyaSwgVmVyZGFuYSwgSGVsdmV0aWNhLCBBcmlhbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMXB0Ij48YnI+DQo8L3NwYW4+PC9mb250Pjxmb250IGZhY2U9IlRpbWVz IE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMnB0Ij4gPGJyPg0KPC9zcGFuPjwv Zm9udD48Zm9udCBmYWNlPSJDYWxpYnJpLCBWZXJkYW5hLCBIZWx2ZXRpY2EsIEFyaWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExcHQiPjxicj4NCjwvc3Bhbj48L2ZvbnQ+PGZvbnQgZmFjZT0i VGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEycHQiPm5vdjxicj4NCjwv c3Bhbj48L2ZvbnQ+PGZvbnQgZmFjZT0iQ2FsaWJyaSwgVmVyZGFuYSwgSGVsdmV0aWNhLCBBcmlh bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMXB0Ij48YnI+DQo8L3NwYW4+PC9mb250Pjxmb250 IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMnB0Ij4gPGJy Pg0KPC9zcGFuPjwvZm9udD48Zm9udCBmYWNlPSJDYWxpYnJpLCBWZXJkYW5hLCBIZWx2ZXRpY2Es IEFyaWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExcHQiPjxicj4NCjwvc3Bhbj48L2ZvbnQ+ PGZvbnQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEycHQi Pk9uIDIwMTIvMDYvMTYsIGF0IDk6MTYsIE5hdCBTYWtpbXVyYSB3cm90ZTo8YnI+DQo8YnI+DQo8 YnI+DQo8L3NwYW4+PC9mb250Pjxmb250IGZhY2U9IkNhbGlicmksIFZlcmRhbmEsIEhlbHZldGlj YSwgQXJpYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTFwdCI+PGJyPg0KPC9zcGFuPjwvZm9u dD48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTJw dCI+QXMgdG8gaG93IHRoZSBmaXggd2FzIGRvbmUsIE5vdiBjYW4gcHJvdmlkZSBtb3JlIGRldGFp bCwgYnV0IC4uLiA8YnI+DQo8L3NwYW4+PC9mb250Pjxmb250IGZhY2U9IkNhbGlicmksIFZlcmRh bmEsIEhlbHZldGljYSwgQXJpYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTFwdCI+PGJyPg0K PC9zcGFuPjwvZm9udD48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTJwdCI+IDxicj4NCjwvc3Bhbj48L2ZvbnQ+PGZvbnQgZmFjZT0iQ2FsaWJyaSwg VmVyZGFuYSwgSGVsdmV0aWNhLCBBcmlhbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMXB0Ij48 YnI+DQo8L3NwYW4+PC9mb250Pjxmb250IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMnB0Ij4xLiBQcm9wZXJseSB2ZXJpZnkgdGhlIHNpZ25hdHVyZS9ITUFD IG9mIHRoZSAic2lnbmVkX3JlcXVlc3QiLiBUaGlzIHdpbGwgZXNzZW50aWFsbHkgYXVkaWVuY2Ug cmVzdHJpY3RzIHRoZSB0b2tlbi4gPGJyPg0KPC9zcGFuPjwvZm9udD48Zm9udCBmYWNlPSJDYWxp YnJpLCBWZXJkYW5hLCBIZWx2ZXRpY2EsIEFyaWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx cHQiPjxicj4NCjwvc3Bhbj48L2ZvbnQ+PGZvbnQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEycHQiPjIuIFRoZXJlIGlzIGFuIHVuZG9jdW1lbnRlZCBBUEkg Zm9yIEZhY2Vib29rIHdoaWNoIHJldHVybnMgdG8gd2hvbSB0aGUgdG9rZW4gd2FzIGlzc3VlZC4g VGhpcyBhbHNvIGF1ZGllbmNlIHJlc3RyaWN0cyB0aGUgdG9rZW4uIDxicj4NCjwvc3Bhbj48L2Zv bnQ+PGZvbnQgZmFjZT0iQ2FsaWJyaSwgVmVyZGFuYSwgSGVsdmV0aWNhLCBBcmlhbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMXB0Ij48YnI+DQo8L3NwYW4+PC9mb250Pjxmb250IGZhY2U9IlRp bWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMnB0Ij4gPGJyPg0KPC9zcGFu PjwvZm9udD48Zm9udCBmYWNlPSJDYWxpYnJpLCBWZXJkYW5hLCBIZWx2ZXRpY2EsIEFyaWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExcHQiPjxicj4NCjwvc3Bhbj48L2ZvbnQ+PGZvbnQgZmFj ZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEycHQiPlRoZSBzZXJ2 aWNlIHRoYXQgZml4ZWQgdG9vayB0aGVzZSBtZWFzdXJlcy4gTm90ZSB0aGF0IG5vbmUgb2YgdGhl IGFib3ZlIGlzIGRlZmluZWQgaW4gT0F1dGguIDxicj4NCjwvc3Bhbj48L2ZvbnQ+PGZvbnQgZmFj ZT0iQ2FsaWJyaSwgVmVyZGFuYSwgSGVsdmV0aWNhLCBBcmlhbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMXB0Ij48YnI+DQo8L3NwYW4+PC9mb250Pjxmb250IGZhY2U9IlRpbWVzIE5ldyBSb21h biI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMnB0Ij5UaGUgc2FtZSBmYWNpbGl0eSB3YXMgY2Fs bGVkICJpZF90b2tlbiIgYW5kICJjaGVjayBJRCBlbmRwb2ludCIgZm9yIE9wZW5JRCBDb25uZWN0 LiA8YnI+DQo8L3NwYW4+PC9mb250Pjxmb250IGZhY2U9IkNhbGlicmksIFZlcmRhbmEsIEhlbHZl dGljYSwgQXJpYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTFwdCI+PGJyPg0KPC9zcGFuPjwv Zm9udD48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTJwdCI+IDxicj4NCjwvc3Bhbj48L2ZvbnQ+PGZvbnQgZmFjZT0iQ2FsaWJyaSwgVmVyZGFuYSwg SGVsdmV0aWNhLCBBcmlhbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMXB0Ij48YnI+DQo8L3Nw YW4+PC9mb250Pjxmb250IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMnB0Ij5UaGUgc2NhbGUgb2YgdGhlIGltcGFjdCBpcyBsYXJnZSwgdG9vIGxhcmdlIHRv IGRpc2Nsb3NlIHRoZSBhY3R1YWwgbmFtZXMgaW4gdGhlIHB1YmxpYyBsaXN0LCB0aG91Z2gsIGV2 ZW50dWFsbHksIHdlIHdvdWxkIHB1Ymxpc2ggdGhlbSBpbiBhIHBhcGVyLiA8YnI+DQo8L3NwYW4+ PC9mb250Pjxmb250IGZhY2U9IkNhbGlicmksIFZlcmRhbmEsIEhlbHZldGljYSwgQXJpYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTFwdCI+PGJyPg0KPC9zcGFuPjwvZm9udD48Zm9udCBmYWNl PSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTJwdCI+IDxicj4NCjwv c3Bhbj48L2ZvbnQ+PGZvbnQgZmFjZT0iQ2FsaWJyaSwgVmVyZGFuYSwgSGVsdmV0aWNhLCBBcmlh bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMXB0Ij48YnI+DQo8L3NwYW4+PC9mb250Pjxmb250 IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMnB0Ij5OYXQ8 YnI+DQo8L3NwYW4+PC9mb250Pjxmb250IGZhY2U9IkNhbGlicmksIFZlcmRhbmEsIEhlbHZldGlj YSwgQXJpYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTFwdCI+PGJyPg0KPC9zcGFuPjwvZm9u dD48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTJw dCI+T24gU2F0LCBKdW4gMTYsIDIwMTIgYXQgNTozNCBBTSwgRnJhbmNpc2NvIENvcmVsbGEgJmx0 OzxhIGhyZWY9ImZjb3JlbGxhQHBvbWNvci5jb20iPmZjb3JlbGxhQHBvbWNvci5jb208L2E+Jmd0 OyB3cm90ZTo8YnI+DQo8YnI+DQpIaSBOYXQgYW5kIFJ1aSw8YnI+DQo8YnI+DQpSdWksIHlvdSBz YXkgdGhhdCB0aGUgdnVsbmVyYWJpbGl0eSB0aGF0IHlvdSBmb3VuZCB3YXMgZHVlIHRvIGE8YnI+ DQoiY29tbW9uIG1pc3VuZGVyc3RhbmRpbmcgYW1vbmcgZGV2ZWxvcGVycyIsIGJ1dCB0aGUgYXR0 YWNrIHlvdTxicj4NCmRlc2NyaWJlIGNhbiBiZSBjYXJyaWVkIG91dCBhZ2FpbnN0IGFueSBhcHAg dGhhdCB1c2VzIHRoZSBPQXV0aDxicj4NCiJpbXBsaWNpdCBncmFudCBmbG93Iiwgd2hpY2ggRmFj ZWJvb2sgY2FsbHMgImNsaWVudC1zaWRlPGJyPg0KYXV0aGVudGljYXRpb24iLiAmbmJzcDtObyBt aXN1bmRlcnN0YW5kaW5nIHNlZW1zIG5lY2Vzc2FyeS4gJm5ic3A7V2hhdDxicj4NCm1pc3VuZGVy c3RhbmRpbmcgYXJlIHlvdSByZWZlcnJpbmcgdG8/ICZuYnNwO0kgZm9sbG93ZWQgdGhlIGxpbmsg aW4geW91cjxicj4NCm1lc3NhZ2UgdG8gdGhlIFNvcGhvcyBwb3N0LCBhbmQgZnJvbSB0aGVyZSB0 aGUgbGluayB0byB0aGUgYXJ0aWNsZSBpbjxicj4NClRoZSBSZWdpc3Rlci4gJm5ic3A7VGhlIGFy dGljbGUgaW4gVGhlIFJlZ2lzdGVyIHNheXMgdGhhdCBGYWNlYm9vayBoYWQ8YnI+DQoiZml4ZWQg dGhlIHZ1bG5lcmFiaWxpdHkgcHJvbXB0bHkiLiAmbmJzcDtIb3cgZGlkIHRoZXkgZml4IGl0PyAm bmJzcDtUaGU8YnI+DQppbnN0cnVjdGlvbnMgdGhhdCBGYWNlYm9vayBwcm92aWRlcyBmb3IgaW1w bGVtZW50aW5nICJDbGllbnQtc2lkZTxicj4NCmF1dGhlbnRpY2F0aW9uIHdpdGhvdXQgdGhlIEpT IFNESyIgYXQ8YnI+DQo8YSBocmVmPSJodHRwczovL2RldmVsb3BlcnMuZmFjZWJvb2suY29tL2Rv Y3MvYXV0aGVudGljYXRpb24vY2xpZW50LXNpZGUvI25vLWpzc2RrIj5odHRwczovL2RldmVsb3Bl cnMuZmFjZWJvb2suY29tL2RvY3MvYXV0aGVudGljYXRpb24vY2xpZW50LXNpZGUvI25vLWpzc2Rr PC9hPjxicj4NCnN0aWxsIGFsbG93cyB0aGUgYXR0YWNrLjxicj4NCjxicj4NCk5hdCwgSSBhZ3Jl ZSB0aGF0IHRoZSBibG9nIHBvc3QgYnkgSm9obiBCcmFkbGV5IHRoYXQgeW91IGxpbmsgdG88YnI+ DQpyZWZlcnMgdG8gdGhlIHNhbWUgdnVsbmVyYWJpbGl0eSByZXBvcnRlZCBieSBSdWkuICZuYnNw O1lvdSBzYXkgdGhhdCBzb21lPGJyPg0KYXBwcyBoYXZlIGlzc3VlZCBhIHBhdGNoIHRvIGZpeCBp dC4gJm5ic3A7Q291bGQgeW91IGV4cGxhaW4gd2hhdCB0aGUgZml4PGJyPg0Kd2FzPzxicj4NCjxi cj4NCkZyYW5jaXNjbzxicj4NCjwvc3Bhbj48L2ZvbnQ+PGJsb2NrcXVvdGU+PGZvbnQgZmFjZT0i Q2FsaWJyaSwgVmVyZGFuYSwgSGVsdmV0aWNhLCBBcmlhbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMXB0Ij48YnI+DQo8L3NwYW4+PC9mb250Pjxmb250IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMnB0Ij4gPGJyPg0KPC9zcGFuPjwvZm9udD48Zm9udCBm YWNlPSJDYWxpYnJpLCBWZXJkYW5hLCBIZWx2ZXRpY2EsIEFyaWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExcHQiPg0KPC9zcGFuPjwvZm9udD4NCjxwIGFsaWduPSJDRU5URVIiPg0KPGZvbnQg ZmFjZT0iQ2FsaWJyaSwgVmVyZGFuYSwgSGVsdmV0aWNhLCBBcmlhbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMnB0Ij48L3NwYW4+PC9mb250PjwvcD48aHIgYWxpZ249IkNFTlRFUiIgc2l6ZT0i MSIgd2lkdGg9IjEwMCUiPg0KPHA+DQo8Zm9udCBmYWNlPSJDYWxpYnJpLCBWZXJkYW5hLCBIZWx2 ZXRpY2EsIEFyaWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEycHQiPjxiPkZyb206PC9iPiBO YXQgU2FraW11cmEgJmx0OzxhIGhyZWY9InNha2ltdXJhQGdtYWlsLmNvbSI+c2FraW11cmFAZ21h aWwuY29tPC9hPiZndDs8YnI+DQo8Yj5Ubzo8L2I+IHJ1aSB3YW5nICZsdDs8YSBocmVmPSJydWl3 YW5nd2FybUBnbWFpbC5jb20iPnJ1aXdhbmd3YXJtQGdtYWlsLmNvbTwvYT4mZ3Q7IDxicj4NCjxi PkNjOjwvYj4gbWF0YWtlIG5vdiAmbHQ7PGEgaHJlZj0ibm92QG1hdGFrZS5qcCI+bm92QG1hdGFr ZS5qcDwvYT4mZ3Q7OyBZdWNoZW4gWmhvdSAmbHQ7PGEgaHJlZj0idC15dXpob3VAbWljcm9zb2Z0 LmNvbSI+dC15dXpob3VAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7OyBvYXV0aCAmbHQ7PGEgaHJlZj0i b2F1dGhAaWV0Zi5vcmciPm9hdXRoQGlldGYub3JnPC9hPiZndDs7IFNodW8gQ2hlbiAoTVNSKSAm bHQ7PGEgaHJlZj0ic2h1b2NoZW5AbWljcm9zb2Z0LmNvbSI+c2h1b2NoZW5AbWljcm9zb2Z0LmNv bTwvYT4mZ3Q7IDxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgSnVuZSAxNCwgMjAxMiAxOjUw IFBNPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIFJlcG9ydCBhbiBhdXRoZW50 aWNhdGlvbiBpc3N1ZTxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExcHQiPjxi cj4NCjwvc3Bhbj48L2ZvbnQ+PGZvbnQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEycHQiPiA8YnI+DQo8L3NwYW4+PC9mb250Pjxmb250IGZhY2U9IkNhbGli cmksIFZlcmRhbmEsIEhlbHZldGljYSwgQXJpYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTFw dCI+PGJyPg0KPC9zcGFuPjwvZm9udD48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTJwdCI+VGhpcyBpcyBhIGZhaXJseSB3ZWxsIGtub3duIChob3Bl ZnVsbHkgYnkgbm93KSBpc3N1ZS4gV2UsIGF0IHRoZSBPcGVuSUQgRm91bmRhdGlvbiwgY2FsbCBp dCAiYWNjZXNzX3Rva2VuIHBoaXNoaW5nIiBhdHRhY2sgdGhlc2UgZGF5cy4gU2VlOiA8YSBocmVm PSJodHRwOi8vd3d3LnRocmVhZC1zYWZlLmNvbS8yMDEyLzAxL3Byb2JsZW0td2l0aC1vYXV0aC1m b3ItYXV0aGVudGljYXRpb24uaHRtbCI+aHR0cDovL3d3dy50aHJlYWQtc2FmZS5jb20vMjAxMi8w MS9wcm9ibGVtLXdpdGgtb2F1dGgtZm9yLWF1dGhlbnRpY2F0aW9uLmh0bWw8L2E+PGJyPg0KPC9z cGFuPjwvZm9udD48Zm9udCBmYWNlPSJDYWxpYnJpLCBWZXJkYW5hLCBIZWx2ZXRpY2EsIEFyaWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExcHQiPjxicj4NCjwvc3Bhbj48L2ZvbnQ+PGZvbnQg ZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEycHQiPiA8YnI+ DQo8L3NwYW4+PC9mb250Pjxmb250IGZhY2U9IkNhbGlicmksIFZlcmRhbmEsIEhlbHZldGljYSwg QXJpYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTFwdCI+PGJyPg0KPC9zcGFuPjwvZm9udD48 Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTJwdCI+ Tm92IE1hdGFrZSBoYXMgYWN0dWFsbHkgYnVpbHQgdGhlIGNvZGUgb24gaVBob25lIHRvIHZlcmlm eSB0aGUgcHJvYmxlbSwgYW5kIGhhcyBub3RpZmllZCBidW5jaCBvZiBwYXJ0aWVzIGJhY2sgaW4g RmVicnVhcnkgaW5jbHVkaW5nIEZhY2Vib29rIGFuZCBBcHBsZS4gV2UgaGF2ZSB0aGUgY29kZSB0 aGF0IGFjdHVhbGx5IHJ1bnMgb24gYSBwaG9uZSwgYW5kIHdlIGhhdmUgc3VjY2Vzc2Z1bGx5IGxv Z2dlZCBpbiB0byBidW5jaCBvZiBhcHBzLCBpbmNsdWRpbmcgdmVyeSB3ZWxsIGtub3duIG9uZXMu IFRoZXkgd2VyZSBhbGwgaW5mb3JtZWQgb2YgdGhlIGlzc3VlLiBTb21lIGltbWVkaWF0ZWx5IGlz c3VlZCBhIHBhdGNoIHRvIGZpeCBpdCB3aGlsZSBvdGhlcnMgaGF2ZSBub3QuICZuYnNwOzxicj4N Cjwvc3Bhbj48L2ZvbnQ+PGZvbnQgZmFjZT0iQ2FsaWJyaSwgVmVyZGFuYSwgSGVsdmV0aWNhLCBB cmlhbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMXB0Ij48YnI+DQo8L3NwYW4+PC9mb250Pjxm b250IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMnB0Ij4g PGJyPg0KPC9zcGFuPjwvZm9udD48Zm9udCBmYWNlPSJDYWxpYnJpLCBWZXJkYW5hLCBIZWx2ZXRp Y2EsIEFyaWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExcHQiPjxicj4NCjwvc3Bhbj48L2Zv bnQ+PGZvbnQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy cHQiPlRoZSBwcm9ibGVtIGlzIHRoYXQgZXZlbiBpZiB0aGVzZSBhcHBzIGdldHMgZml4ZWQsIHRo ZSBwcm9ibGVtIGRvZXMgbm90IGdvIGF3YXkuIEFzIGxvbmcgYXMgdGhlIGF0dGFja2VyIGhhcyB0 aGUgdnVsbmVyYWJsZSB2ZXJzaW9uIG9mIHRoZSBhcHAsIGhlIHN0aWxsIGNhbiBpbXBlcnNvbmF0 ZSB0aGUgdmljdGltLiBUbyBzdG9wIGl0LCB0aGUgc2VydmVyIHNpZGUgaGFzIHRvIGNvbXBsZXRl bHkgZGlzYWJsZSB0aGUgb2xkZXIgdmVyc2lvbiwgd2hpY2ggbWVhbnMgdGhlIHNlcnZpY2UgaGFz IHRvIGN1dCBvZmYgbWFueSB1c2VycyBwYXVzaW5nIGJ1c2luZXNzIHByb2JsZW1zLiA8YnI+DQo8 L3NwYW4+PC9mb250Pjxmb250IGZhY2U9IkNhbGlicmksIFZlcmRhbmEsIEhlbHZldGljYSwgQXJp YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTFwdCI+PGJyPg0KPC9zcGFuPjwvZm9udD48Zm9u dCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTJwdCI+IDxi cj4NCjwvc3Bhbj48L2ZvbnQ+PGZvbnQgZmFjZT0iQ2FsaWJyaSwgVmVyZGFuYSwgSGVsdmV0aWNh LCBBcmlhbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMXB0Ij48YnI+DQo8L3NwYW4+PC9mb250 Pjxmb250IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMnB0 Ij5OYXQ8YnI+DQo8L3NwYW4+PC9mb250Pjxmb250IGZhY2U9IkNhbGlicmksIFZlcmRhbmEsIEhl bHZldGljYSwgQXJpYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTFwdCI+PGJyPg0KPC9zcGFu PjwvZm9udD48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTJwdCI+T24gRnJpLCBKdW4gMTUsIDIwMTIgYXQgMjoxOCBBTSwgcnVpIHdhbmcgJmx0Ozxh IGhyZWY9InJ1aXdhbmd3YXJtQGdtYWlsLmNvbSI+cnVpd2FuZ3dhcm1AZ21haWwuY29tPC9hPiZn dDsgd3JvdGU6PGJyPg0KPC9zcGFuPjwvZm9udD48Zm9udCBmYWNlPSJDYWxpYnJpLCBWZXJkYW5h LCBIZWx2ZXRpY2EsIEFyaWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExcHQiPjxicj4NCjwv c3Bhbj48L2ZvbnQ+PGZvbnQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEycHQiPkRlYXIgRmFjZWJvb2sgU2VjdXJpdHkgVGVhbSBhbmQgT0F1dGggU3RhbmRh cmQgZ3JvdXAsPGJyPg0KPC9zcGFuPjwvZm9udD48Zm9udCBmYWNlPSJDYWxpYnJpLCBWZXJkYW5h LCBIZWx2ZXRpY2EsIEFyaWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExcHQiPjxicj4NCjwv c3Bhbj48L2ZvbnQ+PGZvbnQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEycHQiPldlIGFyZSBhIHJlc2VhcmNoIHRlYW0gaW4gTWljcm9zb2Z0IFJlc2VhcmNo LiBJbiBKYW51YXJ5LCAyMDExLCB3ZSByZXBvcnRlZCBhIHZ1bG5lcmFiaWxpdHkgaW4gRmFjZWJv b2sgQ29ubmVjdCB3aGljaCBhbGxvd2VkIGV2ZXJ5b25lIHRvIHNpZ24gaW50byBGYWNlYm9vay1z ZWN1cmVkIHJlbHlpbmcgcGFydGllcyB3aXRob3V0IHBhc3N3b3JkLiBJdCB3YXMgcHJvbXB0bHkg Zml4ZWQgYWZ0ZXIgcmVwb3J0aW5nLiAoPGEgaHJlZj0iaHR0cDovL25ha2Vkc2VjdXJpdHkuc29w aG9zLmNvbS8yMDExLzAyLzAyL2ZhY2Vib29rLWZsYXctd2Vic2l0ZXMtc3RlYWwtcGVyc29uYWwt ZGF0YS8iPmh0dHA6Ly9uYWtlZHNlY3VyaXR5LnNvcGhvcy5jb20vMjAxMS8wMi8wMi9mYWNlYm9v ay1mbGF3LXdlYnNpdGVzLXN0ZWFsLXBlcnNvbmFsLWRhdGEvPC9hPik8YnI+DQo8L3NwYW4+PC9m b250Pjxmb250IGZhY2U9IkNhbGlicmksIFZlcmRhbmEsIEhlbHZldGljYSwgQXJpYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTFwdCI+PGJyPg0KPC9zcGFuPjwvZm9udD48Zm9udCBmYWNlPSJU aW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTJwdCI+UmVjZW50bHksIHdl IGZvdW5kIGEgY29tbW9uIG1pc3VuZGVyc3RhbmRpbmcgYW1vbmcgZGV2ZWxvcGVycyBvZiBtb2Jp bGUvbWV0cm8gYXBwcyB3aGVuIHVzaW5nIE9BdXRoIChpbmNsdWRpbmcgRmFjZWJvb2vigJlzIE9B dXRoKSBmb3IgYXV0aGVudGljYXRpb24uIFRoZSB2dWxuZXJhYmlsaXR5IHJlc3VsdGVkIGZyb20g dGhpcyBtaXN1bmRlcnN0YW5kaW5nIGFsc28gYWxsb3dzIGFuIGF0dGFja2VyIHRvIGxvZyBpbnRv IGEgdmljdGltIHVzZXIncyBhY2NvdW50IHdpdGhvdXQgcGFzc3dvcmQuPGJyPg0KPC9zcGFuPjwv Zm9udD48Zm9udCBmYWNlPSJDYWxpYnJpLCBWZXJkYW5hLCBIZWx2ZXRpY2EsIEFyaWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExcHQiPjxicj4NCjwvc3Bhbj48L2ZvbnQ+PGZvbnQgZmFjZT0i VGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEycHQiPkxldCdzIHRha2Ug U29sdXRvJ3MgbWV0cm8gYXBwIGFzIGFuIGV4YW1wbGUgdG8gZGVzY3JpYmUgdGhlIHByb2JsZW0u IFRoZSBhcHAgc3VwcG9ydHMgRmFjZWJvb2sgTG9naW4uIEFzIGFuIGF0dGFja2VyLCB3ZSBjYW4g d3JpdGUgYSByZWd1bGFyIEZhY2Vib29rIGFwcC4gT25jZSB0aGUgdmljdGltIHVzZXIgYWxsb3dz IG91ciBhcHAgdG8gYWNjZXNzIGhlciBGYWNlYm9vayBkYXRhLCB3ZSByZWNlaXZlIGFuIGFjY2Vz c190b2tlbiBmcm9tIHRoZSB0cmFmZmljLiBUaGVuLCBvbiBvdXIgb3duIG1hY2hpbmUgKGkuZS4s IHRoZSAiYXR0YWNrZXIiIG1hY2hpbmUpLCB3ZSBydW4gdGhlIG1ldHJvIGFwcCBvZiBTb2x1dG8s IGFuZCB1c2UgYSBIVFRQIHByb3h5IHRvIGluc2VydCB0aGUgdmljdGltJ3MgYWNjZXNzX3Rva2Vu IGludG8gdGhlIHRyYWZmaWMgb2YgRmFjZWJvb2sgbG9naW4uIFRocm91Z2ggdGhpcyB3YXksIHdl IGFyZSBhYmxlIHRvIGxvZyBpbnRvIHRoZSB2aWN0aW0ncyBTb2x1dG8gYWNjb3VudCBmcm9tIG91 ciBtYWNoaW5lLiBPdGhlciB0aGFuIFNvbHV0bywgd2UgYWxzbyBoYXZlIGNvbmZpcm1lZCB0aGUg c2FtZSBpc3N1ZSBvbiBhbm90aGVyIFdpbmRvd3MgOCBtZXRyby1hcHAgR2l2aXQuPGJyPg0KPC9z cGFuPjwvZm9udD48Zm9udCBmYWNlPSJDYWxpYnJpLCBWZXJkYW5hLCBIZWx2ZXRpY2EsIEFyaWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExcHQiPjxicj4NCjwvc3Bhbj48L2ZvbnQ+PGZvbnQg ZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEycHQiPlRoZSBG YWNlYm9vayBTREsgZm9yIEFuZHJvaWQgYXBwcyAoPGEgaHJlZj0iaHR0cHM6Ly9kZXZlbG9wZXJz LmZhY2Vib29rLmNvbS9kb2NzL21vYmlsZS9hbmRyb2lkL2J1aWxkLyNzZGsiPmh0dHBzOi8vZGV2 ZWxvcGVycy5mYWNlYm9vay5jb20vZG9jcy9tb2JpbGUvYW5kcm9pZC9idWlsZC8jc2RrPC9hPikg c2VlbXMgdG8gaGF2ZSB0aGUgcG9zc2liaWxpdHkgdG8gbWlzbGVhZCBkZXZlbG9wZXJzIHRvby4g QXQgbGVhc3QsIHRoZSBpc3N1ZSB0aGF0IHdlIGZvdW5kIGlzIG5vdCBjbGVhcmx5IG1lbnRpb25l ZC4gSW4gdGhlIFNESywgd2UgcmFuIHRoZSBzYW1wbGUgY29kZSBjYWxsZWQgIkhhY2tib29rIiB1 c2luZyBBbmRyb2lkIEVtdWxhdG9yIChpbWFnaW5lIGl0IGlzIGFuIGF0dGFja2VyIGRldmljZSku IE5vdGUgdGhhdCB3ZSBoYXZlIGFscmVhZHkgcmVjZWl2ZWQgdGhlIGFjY2VzcyB0b2tlbiBvZiB0 aGUgdmljdGltIHVzZXIgZnJvbSBvdXIgcmVndWxhciBGYWNlYm9vayBhcHAuIFdlIHRoZW4gaW5q ZWN0IHRoZSB0b2tlbiB0byB0aGUgdHJhZmZpYyBvZiBIYWNrYm9vay4gVGhyb3VnaCB0aGlzIHdh eSwgSGFja2Jvb2sgYXBwIG9uIG91ciBvd24gbWFjaGluZSByZWNvZ25pemVzIHVzIGFzIHRoZSB2 aWN0aW0uIE5vdGUgdGhhdCB0aGlzIGlzIG5vdCBhIGNvbnZpbmNpbmcgc2VjdXJpdHkgZXhwbG9p dCB5ZXQsIGJlY2F1c2UgdGhpcyBzYW1wbGUgY29kZSBkb2VzIG5vdCBpbmNsdWRlIHRoZSBzZXJ2 ZXItc2lkZSBjb2RlLiBIb3dldmVyLCBnaXZlbiB0aGF0IHdlIGhhdmUgc2VlbiByZWFsIHNlcnZl ci1zaWRlIGNvZGUgaGF2aW5nIHRoaXMgcHJvYmxlbSwgc3VjaCBhcyBTb2x1dG8sIEdpdml0IGFu ZCBvdGhlcnMsIHdlIGRvIGJlbGlldmUgdGhhdCB0aGUgc2FtcGxlIGNvZGUgY2FuIG1pc2xlYWQg bW9iaWxlL21ldHJvIGRldmVsb3BlcnMuIFdlIGFsc28gc3VzcGVjdCB0aGF0IHRoaXMgbWF5IGJl IGEgZ2VuZXJhbCBpc3N1ZSBvZiBtYW55IE9BdXRoIGltcGxlbWVudGF0aW9ucyBvbiBtb2JpbGUg cGxhdGZvcm1zLCBzbyB3ZSBzZW5kIHRoaXMgbWVzc2FnZSB0byBPQXV0aCBTdGFuZGFyZCBncm91 cCBhcyB3ZWxsLjxicj4NCjwvc3Bhbj48L2ZvbnQ+PGZvbnQgZmFjZT0iQ2FsaWJyaSwgVmVyZGFu YSwgSGVsdmV0aWNhLCBBcmlhbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMXB0Ij48YnI+DQo8 L3NwYW4+PC9mb250Pjxmb250IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMnB0Ij5XZSBoYXZlIGNvbnRhY3RlZCB0aGUgdmVuZG9ycyBvZiB0aGUgdHdvIHZ1 bG5lcmFibGUgbWV0cm8tYXBwcywgU29sdXRvIGFuZCBHYXZpdC48YnI+DQo8L3NwYW4+PC9mb250 Pjxmb250IGZhY2U9IkNhbGlicmksIFZlcmRhbmEsIEhlbHZldGljYSwgQXJpYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTFwdCI+PGJyPg0KPC9zcGFuPjwvZm9udD48Zm9udCBmYWNlPSJUaW1l cyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTJwdCI+UGxlYXNlIGtpbmRseSBn aXZlIHVzIGFuIGFjayB3aGVuIHlvdSByZWNlaXZlIHRoaXMgbWVzc2FnZS4gSWYgeW91IHdhbnQg dG8ga25vdyBtb3JlIGRldGFpbHMsIHBsZWFzZSBsZXQgdXMga25vdy48YnI+DQo8L3NwYW4+PC9m b250Pjxmb250IGZhY2U9IkNhbGlicmksIFZlcmRhbmEsIEhlbHZldGljYSwgQXJpYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTFwdCI+PGJyPg0KPC9zcGFuPjwvZm9udD48Zm9udCBmYWNlPSJU aW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTJwdCI+QmVzdCBSZWdhcmRz LDxicj4NCll1Y2hlbiBaaG91LCBSdWkgV2FuZywgYW5kIFNodW8gQ2hlbjxicj4NCjxicj4NCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGgg bWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0iT0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3Jn PC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v b2F1dGgiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PGJy Pg0KPGJyPg0KPGJyPg0KJm5ic3A7PGJyPg0KPC9zcGFuPjwvZm9udD48L3A+PC9ibG9ja3F1b3Rl PjwvYmxvY2txdW90ZT4NCg0KDQoNCjwvZGl2PjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBl PSJjaXRlIj48ZGl2PjxzcGFuPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPC9zcGFuPjxicj48c3Bhbj5PQXV0aCBtYWlsaW5nIGxpc3Q8L3NwYW4+PGJyPjxz cGFuPjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0Zi5vcmc8L2E+PC9z cGFuPjxicj48c3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL29hdXRoIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9h Pjwvc3Bhbj48YnI+PC9kaXY+PC9ibG9ja3F1b3RlPjwvYm9keT48L2h0bWw+ --_000_B8063282B7CD4C80ADE9FE23ED3289F5salesforcecom_-- From bcampbell@pingidentity.com Fri Jun 22 08:50:10 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34EFE21F8767 for ; Fri, 22 Jun 2012 08:50:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.854 X-Spam-Level: X-Spam-Status: No, score=-5.854 tagged_above=-999 required=5 tests=[AWL=-0.177, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, 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 T4zDXpnUUadW for ; Fri, 22 Jun 2012 08:50:09 -0700 (PDT) Received: from na3sys009aog109.obsmtp.com (na3sys009aog109.obsmtp.com [74.125.149.201]) by ietfa.amsl.com (Postfix) with ESMTP id 25F2B21F86FE for ; Fri, 22 Jun 2012 08:50:08 -0700 (PDT) Received: from mail-qa0-f50.google.com ([209.85.216.50]) (using TLSv1) by na3sys009aob109.postini.com ([74.125.148.12]) with SMTP ID DSNKT+SUMIXbuzKgTK3rZLmglLcETenRnZs2@postini.com; Fri, 22 Jun 2012 08:50:09 PDT Received: by qafl39 with SMTP id l39so638655qaf.16 for ; Fri, 22 Jun 2012 08:50:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=FX5RaRcF+oMVB6D324kcp6KHevT7//KOqAmZ/13LT7U=; b=QTt3Co10AM/3EpNIF2QJ3csfq+AuC7oCrkR+9IYOeBF2nhgjI23UR60lSbYeq3wnDD bfxq5VT0oGuwmKwVg0VaM+Dv10SRnyCCiDqwggDC26WHY50YPlqpaiddfUHKAg1etwNg AjSk2gjc7oC7tKLBG2pEKrnOEbj7+YnxancM7lqde3oHxo2dg9+oteodMZkleEQxEjVH 8V8qXLj4GZur169vJMGTzRmNHI/ofszoWR2jK17HC0R+Q4IbkuUIp6B3ylRU6snkneyD k8K0JVCzRABuzn3gsfI84vUmVyVTRW3Wjuh2K958e14T3KuQMJvhUI1SpFh4343Px3ra QuIA== Received: by 10.224.212.1 with SMTP id gq1mr7227236qab.54.1340380207739; Fri, 22 Jun 2012 08:50:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.87.142 with HTTP; Fri, 22 Jun 2012 08:49:37 -0700 (PDT) From: Brian Campbell Date: Fri, 22 Jun 2012 09:49:37 -0600 Message-ID: To: "Manger, James H" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmF36Y8hDcyXFQ+3MBzvaA5jlkwtSudDGsq4vvfnupbDFelWssIp+6sh5vGACJ4cUD4EXAP Cc: "oauth@ietf.org" Subject: [OAUTH-WG] =?iso-8859-1?q?issues_with_=A78=2E3_grant_type_paramet?= =?iso-8859-1?q?ers=3F_=28was_=2E=2E=2E_draft-ietf-oauth-urn-sub-ns?= =?iso-8859-1?q?-03=2Etxt=29?= X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 15:50:10 -0000 It was a design decision that seemed most appropriate given the various factors and goals of my application at the time. My goal in pointing to that was not to elicit feedback on the design itself but to show that 'vendor-specific' extension grants will happen, and already have happened, and that that might suggest a problem with the text in =A78.3 of the core spec. Do others see an issue here? http://tools.ietf.org/html/draft-ietf-oauth-v2-28#section-8.3 We can discuses the merits of the introspection as a grant type approach if/when the WG chooses to take that on as a work item and to the extent that approach is of interest. My colleague posted an early/rough draft of that approach as an attachment to http://www.ietf.org/mail-archive/web/oauth/current/msg08607.html On Fri, Jun 22, 2012 at 12:09 AM, Manger, James H wrote: >> In fact, I've already got a vendor-specific grant type that uses an >> unregistered parameter on the token endpoint - it's a simple grant >> type for access token introspection [2]. >> >> [2] >> http://documentation.pingidentity.com/display/PF66/Grant+Type+Parameter >> s#GrantTypeParameters-1079271 > > > Why are you trying to overload this new functionality onto a URI used for= other purposes? > Why not just pick a URI specifically for your purpose, eg /as/validate? > > -- > James Manger From zachary.zeltsan@alcatel-lucent.com Fri Jun 22 09:53:34 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4870321F86C6 for ; Fri, 22 Jun 2012 09:53:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DJO1vaZIiMN2 for ; Fri, 22 Jun 2012 09:53:32 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id D9A4621F86B4 for ; Fri, 22 Jun 2012 09:53:25 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q5MGrJ7I027918 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 22 Jun 2012 11:53:19 -0500 (CDT) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q5MGrJVK018737 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 22 Jun 2012 11:53:19 -0500 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.127]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Fri, 22 Jun 2012 11:53:19 -0500 From: "Zeltsan, Zachary (Zachary)" To: "'Hannes Tschofenig'" , "'oauth@ietf.org WG (oauth@ietf.org)'" Date: Fri, 22 Jun 2012 11:53:15 -0500 Thread-Topic: [OAUTH-WG] Use case document Thread-Index: Ac1QRcXDmBFpqxinT4KSYdJpnH1v+QASojKA Message-ID: <5710F82C0E73B04FA559560098BF95B129E9A2943F@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> References: <970540AE-E139-424E-BC90-F04113F7D53A@gmx.net> In-Reply-To: <970540AE-E139-424E-BC90-F04113F7D53A@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Subject: Re: [OAUTH-WG] Use case document X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 16:53:34 -0000 Hannes, Thank you for the review and comments. My responses (which start with Z:) a= re below. -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of H= annes Tschofenig Sent: Friday, June 22, 2012 3:08 AM To: oauth@ietf.org WG (oauth@ietf.org) Subject: [OAUTH-WG] Use case document Hi all,=20 I just looked at the use case document and a few questions came to my mind: * Who is the lead editor?=20 Z: I have been doing most of the editing. * The abstract and the introduction explain the history of why the document= exists. You may want to change that to an introduction that describes what= use cases are in the document and why you have chosen them instead of thou= sands of others, and why the reader should look into them. After some time= (and particularly after the publication as an RFC) it does not matter whet= her the use cases got collected between IETF 77 and IETF 78. =20 Z: This part will be revised. The cases were chosen of those that had been = discussed on the list (are there are less than thousands of such cases :)). * The reference to RFC 2119 is not needed and Section 2 is not needed.=20 Z: I will remove that. * More important, however, is the question of what use cases should be cove= red in the document and how you call them. Needless to say that there are m= any use cases for OAuth. For example, I believe it makes little sense to li= st use cases according to what data is exchanged (social networking informa= tion vs. travel plans vs. payment information). So, what are the distinguis= hing aspects that make it worthwhile for a use cases to be included?=20 Z: I agree with these statements. I am not sure that I understand which tex= t in the draft has generated your comment " it makes little sense to list = use cases according to what data is exchanged (social networking informatio= n vs. travel plans vs. payment information)", but I agree with this. The in= tent was to provide the use cases that cover the OAuth flows (i.e., the var= ious uses of OAuth). There are also use cases that have been discussed duri= ng the specification development, but are not supported by OAuth 2.0. I would say that the different protocol profiles somehow have to be covered= . This includes the different cases for the various authorization grants. I= would also say that different security levels matter. If you do that then= it would also be useful to connect the individual use cases back to the ot= her working group documents via references.=20 Z: That was an intent - to describe the use cases that employ different aut= horization grants. For example, the use cases "Web server" and " Client pas= sword (shared secret) credentials" aim at doing just that.=20 Other aspects that could matter are different implementation strategies or = different user appearance. On the latter the device flow is an example.=20 In any case, you have to decide what the criteria are since this determines= your target audience. Who do you expect will most likely benefit from read= ing this document?=20 Z: I believe that the use cases are helpful for understanding a protocol. I= t is useful to map a particular OAuth flow to a use case. There are various use cases in the document that are not sufficiently diffe= rent from the rest unless you highlight some aspects that you think are rea= lly essential.=20 Z: I plan to address this your comment (and others too) in the next version= . It would be helpful to know which cases appear to you not sufficiently di= fferent. Ciao Hannes Zachary _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From internet-drafts@ietf.org Fri Jun 22 12:52:54 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77B6D21F86B7; Fri, 22 Jun 2012 12:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.483 X-Spam-Level: X-Spam-Status: No, score=-102.483 tagged_above=-999 required=5 tests=[AWL=0.116, 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 5h11nGTCOpRD; Fri, 22 Jun 2012 12:52:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2F8C21F8602; Fri, 22 Jun 2012 12:52: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.21 Message-ID: <20120622195253.25511.91297.idtracker@ietfa.amsl.com> Date: Fri, 22 Jun 2012 12:52:53 -0700 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-urn-sub-ns-04.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, 22 Jun 2012 19:52: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 : An IETF URN Sub-Namespace for OAuth Author(s) : Brian Campbell Hannes Tschofenig Filename : draft-ietf-oauth-urn-sub-ns-04.txt Pages : 7 Date : 2012-06-22 Abstract: This document establishes an IETF URN Sub-namespace for use with OAuth related specifications. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-urn-sub-ns There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-urn-sub-ns-04 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-urn-sub-ns-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From bcampbell@pingidentity.com Fri Jun 22 13:04:12 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7140811E807F for ; Fri, 22 Jun 2012 13:04:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.993 X-Spam-Level: X-Spam-Status: No, score=-5.993 tagged_above=-999 required=5 tests=[AWL=-0.016, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nbjJcJTuFi0d for ; Fri, 22 Jun 2012 13:04:12 -0700 (PDT) Received: from na3sys009aog118.obsmtp.com (na3sys009aog118.obsmtp.com [74.125.149.244]) by ietfa.amsl.com (Postfix) with ESMTP id D137311E8079 for ; Fri, 22 Jun 2012 13:04:08 -0700 (PDT) Received: from mail-vb0-f42.google.com ([209.85.212.42]) (using TLSv1) by na3sys009aob118.postini.com ([74.125.148.12]) with SMTP ID DSNKT+TPuNyxlc0vmhyKXnm1Fj+Mzf989iim@postini.com; Fri, 22 Jun 2012 13:04:11 PDT Received: by vbbfs19 with SMTP id fs19so1307027vbb.29 for ; Fri, 22 Jun 2012 13:04:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding:x-gm-message-state; bh=/XDF56J4Toj/nuuIn8Rro2n6IS2QRy/zuorlcRfansg=; b=kLrbjq3EUAmMA/Q3/2v2NKch1YBqomhBlOoRY9DryDcXCs787rMzNAdYOy6+VV2MOU 3qkTs/hj6PbQil9YcoWpqC8UId2jAhfgfQEaAB6IWFt2Pq1qNHQjktPEQH+ZDsIefuox wVcERuX5TMsEdw1YpLg1O2k1uNJ4O7CjoJVKelqH3LG1MImzdP5WKkZopTijvFDjTV8f LYF3PIIsSeZEQfURqMPUnWoHt50nDZz84xqw5Kx9pvotcXQSCwvVrAIbcaI3ezpu5ogS CT2CAtlZkt6gIbS4RJ9GhUZakb+XcCZkkhMNkUVQ87S25X1hzLE4PrlKcVnWlXjsqEIP o8Fw== Received: by 10.220.115.147 with SMTP id i19mr1705225vcq.68.1340395447301; Fri, 22 Jun 2012 13:04:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.109.170 with HTTP; Fri, 22 Jun 2012 13:03:36 -0700 (PDT) In-Reply-To: <20120622195253.25511.91297.idtracker@ietfa.amsl.com> References: <20120622195253.25511.91297.idtracker@ietfa.amsl.com> From: Brian Campbell Date: Fri, 22 Jun 2012 14:03:36 -0600 Message-ID: To: oauth Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmxhbpufl7O5qmxGHsPwVS9X3Qg/ZmKnQdhoqLnY+fdby+mQ0JKR5JzYlaQWi8XHJTIsS1Z Subject: [OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-urn-sub-ns-04.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, 22 Jun 2012 20:04:12 -0000 Draft -04 of "An IETF URN Sub-Namespace for OAuth" has been published and is available at http://tools.ietf.org/html/draft-ietf-oauth-urn-sub-ns-04 - the changes from the previous version are listed below. Per http://www.ietf.org/mail-archive/web/oauth/current/msg09407.html and barring any objections, I'd ask the Chairs to give the AD the okay to move this to LC. draft-ietf-oauth-urn-sub-ns-04 o Changed the Index value (and Registration Template into paragraph) from to just with a suggestion that it have both a "class" and an "identifier-within-class" parts per http://www.ietf.org/mail-archive/web/oauth/current/msg09381.html so as to be less restrictive Thanks, Brian ---------- Forwarded message ---------- From: Date: Fri, Jun 22, 2012 at 1:52 PM Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-urn-sub-ns-04.txt To: i-d-announce@ietf.org Cc: oauth@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts director= ies. =A0This draft is a work item of the Web Authorization Protocol Working Group of the IETF. =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : An IETF URN Sub-Namespace for OA= uth =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Brian Campbell =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Hannes Tschofenig =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-oauth-urn-sub-ns-04.txt =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 7 =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-06-22 Abstract: =A0 This document establishes an IETF URN Sub-namespace for use with =A0 OAuth related specifications. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-urn-sub-ns There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-urn-sub-ns-04 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-urn-sub-ns-04 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 prateek.mishra@oracle.com Fri Jun 22 14:11:27 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD48D11E80BC for ; Fri, 22 Jun 2012 14:11:27 -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 Aj-KvW4HSTFW for ; Fri, 22 Jun 2012 14:11:18 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id 69EC411E80A3 for ; Fri, 22 Jun 2012 14:11:17 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q5MLBFcW003468 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 22 Jun 2012 21:11:16 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 q5MLBFlx029017 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Jun 2012 21:11:15 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 q5MLBFR3002472; Fri, 22 Jun 2012 16:11:15 -0500 Received: from [192.168.2.3] (/66.31.108.94) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 22 Jun 2012 14:11:14 -0700 Message-ID: <4FE4DF71.7080206@oracle.com> Date: Fri, 22 Jun 2012 17:11:13 -0400 From: prateek mishra Organization: Oracle Corporation User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Lewis Adam-CAL022 , oauth@ietf.org References: <1339792496.52712.YahooMailNeo@web125501.mail.ne1.yahoo.com> <59E470B10C4630419ED717AC79FCF9A9108898EE@BL2PRD0410MB363.namprd04.prod.outlook.com> <4FE223E4.6060307@mitre.org> <4FE226BC.6010403@alcatel-lucent.com> <59E470B10C4630419ED717AC79FCF9A910889AB5@BL2PRD0410MB363.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A917052BC8@SN2PRD0410MB370.namprd04.prod.outlook.com> In-Reply-To: <59E470B10C4630419ED717AC79FCF9A917052BC8@SN2PRD0410MB370.namprd04.prod.outlook.com> Content-Type: multipart/alternative; boundary="------------040802060209030301090100" X-Source-IP: acsinet21.oracle.com [141.146.126.237] Subject: Re: [OAUTH-WG] Report an authentication issue X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 21:11:27 -0000 This is a multi-part message in MIME format. --------------040802060209030301090100 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Adam, I agree with you that this is a significant use-case, one that is of particular interest for enterprise deployments. My impression is that the fully specified OAuth flows to date focus on certain key consumer-centred use-cases and that important enterprise flows such as the one you have described are yet to be profiled. We havent looked at OpenID Connect yet, but I dont believe this was the main use-case for that effort either. I support your call for a broader discussion of this issue. - prateek > Hi Nat, > > I'm beginning to wonder what it would take to add a new profile of > sorts to either OAuth or Connect. > > In the beginning there was SOAP, and the preferred method to secure > SOAP API calls was WS-Trust. > > Now the world is moving toward RESTful APIs ... and the preferred > means to secure RESTful APIs is OAuth. > > Except that OAuth is clearly written with the idea that the protected > resources belong to the end user. > > My use cases -- and I imagine the use cases of many other enterprises > -- is that the Owner of the resources is the Enterprise. An employee > is trying to access a database or video resources. The enterprise RS > needs to be able to 1) identify the user, and 2) make authorization > decisions based on what roles that user has within the enterprise. So > in my scenario, when a police officer attempts to access a criminal > records database, the database needs to know who that officer is, and > then decide if they have privilege to access the database, and at what > level (e.g. CRUD). > > WS-Trust fits this model well. The user performs primary > authentication to the enterprise STS, which then grants the > application client a SAML assertion. When the user attempts to access > a records database, the SAML assertion is included in the SOAP > message. The records server authenticates the user based on the SAML > assertion and makes its authorization decisions. > > This is the world I'm trying to migrate from, and it really seems like > I'm sometimes trying to make a square peg fit in a round hole. I'm > looking for OAuth/Connect to do for REST what WS-TRUST did for SOAP. > I would like a native client talking to a RS to be able to ask for an > id_token, and then pass that id_token to the RS when making its > RESTful API calls, to enable the RS to authenticate the user. I think > that this would be really useful for a lot of people besides me. I > keep hearing that there is nothing "preventing" me from doing this ... > but it hardly seems within the spirit of what OAuth was meant to do. > The id_token was clearly meant to enable a user to authenticate to a > confidential client / web server ... but was not meant for a native > client to identity / authenticate the user to a RS. > > Would there be any interest in exploring this further? > > -adam > > *From:*Nat Sakimura [mailto:sakimura@gmail.com] > *Sent:* Wednesday, June 20, 2012 8:09 PM > *To:* Lewis Adam-CAL022 > *Cc:* igor.faynberg@alcatel-lucent.com; oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Report an authentication issue > > Yes, OAuth can be profiled to enable authentication. > > In fact, initial draft of OpenID Connect was just like you described. > > Essentially, we were using structured access_token. > > Later, we decided to separate the access token and id_token for > several reasons such as: > > 1. Better interop with existing OAuth implementations: by introducing > id_token, they do not need to touch the supposedly opaque (which > means AS-RS may be doing some proprietary thing inside it) access > token. > 2. Mixing up the audience (for id_token aka authn = client, and for > access_token aka authz = resource server) probably is expanding > the attack surface for security and privacy. > > Although we separated them out, a signed id_token includes the left > hash of access_token so access_token is also protected. > > Best, > > Nat > > On Thu, Jun 21, 2012 at 5:21 AM, Lewis Adam-CAL022 > > wrote: > > Hi Igor, > > As Justin just pointed out, consider the case where the video server > is hosted by the state (e.g. California) and is accessed by police > agencies in Los Angeles, San Francisco, and San Diego. The State of > California's video server is the RS. Each local police agency > (LA/SF/SD) hosts an AS. So when a police officer from LAPD launches > the video client app on the iPhone, the client makes an OAuth request > to the LAPD's AS, which authenticates the police officer using agency > level credentials. The access token issued to the video client app on > the iPhone is a JWT, signed by the agency AS, which might look > something like this: > > {"typ":"JWT","alg":"ES256"} > > {"iss":"https://as.lapd.california.gov", > "prn":"alice@lapd.california.gov ", > "aud":" https://video_server1@state.california.gov", > "iat":1300815780, > "exp":1300819380, > "acr":"password"} > > hq4zk+ZknjggCQgZm7ea8fI79gJEsRy3E8LHDpYXWQIgZpkJN9CMLG8ENR4Nrw+n7iyzixBvKXX8P53BTCT4VghPBWhFYSt9tHWu/AtJfOTh6qaAsNdeCyG86jmtp3TDMwuL/cBUj2OtBZOQMFn7jQ9YB7klIz3RqVL+wNmeWI4= > > The JWT might be optionally encrypted using JWE. > > I think what is becoming clear (and this is what I'm trying to vet) is > that while there is nothing in OAuth that specifies authentication, it > **can** be used for Authentication, if done in the way that I > describe. If I'm wrong about this, I really need to know. I've > vetted this idea of mine with quite of few people now -- both within > context of the list and off-line -- and I think I'm okay. If you see > any holes in what I describe, please point them out as I would prefer > to uncover them now rather than after implementation or deployment! > > Essentially I'm using OAuth as a RESTful version of WS-Trust, where my > client can exchange primary credentials for a token (JWT) and present > that token to a server as secondary authentication. It's just that > it's RESTful instead of SOAP :-) > > As Justin as pointed out ... I've basically made the access-token look > like the id_token of Connect. I was actually hoping to lay a path to > Connect, and use the id_token ... until it was also pointed out that > the id_token is really meant for the consumption of the client, not > the RS :-( > > *From:*oauth-bounces@ietf.org > [mailto:oauth-bounces@ietf.org ] *On > Behalf Of *Igor Faynberg > *Sent:* Wednesday, June 20, 2012 2:39 PM > *To:* oauth@ietf.org > > > *Subject:* Re: [OAUTH-WG] Report an authentication issue > > But this use case does need OAuth, period: > > > > The video server is under the control of a police agency, and police > officers must logon to the video server in order to access video content. > > There is no delegation here, and there is no need to use third party > for authentication. > > Igor > > On 6/20/2012 3:26 PM, Justin Richer wrote: > > In case it wasn't clear, I want to restate the original problem as > best as I understand it in a way that hopefully clears it up: > > App A and app B are both valid registered OAuth clients to an OAuth > protected service. > > The problem starts when app A gets handed a token that was issued for > app B and uses it to call an identity API on the OAuth service. Since > app B can get tokens just fine, they're bearer tokens, this is a > fairly basic api call, this function works just fine and returns the > user info. This makes sense, since anyone who holds A's tokens can do > whatever A can do on behalf of that user. The issues start when app B > then decides that since they can make a call to the identity API with > a token then the user *must* be present. In other words, app B is > confusing authorization to call an API with authentication of the session. > > OpenID Connect fixes this missed assumption by binding the ID Token to > the session and sending it along side the access token, but as you > pointed out, it's meant for consumption at the client, not the > resource server, in general. That doesn't mean you can't send it to a > resource server for your own purposes, of course. That's actually how > the session management endpoint works in Connect. > > This isn't the only way to handle this problem -- if you put some > structure in your tokens, such as with JWT or SAML, then app A can > tell that this isn't a token issued to app A, but to app B, so it can > call shenanigans and reject it then and there. > > -- Justin > > On 06/20/2012 10:03 AM, Lewis Adam-CAL022 wrote: > > I am entirely confused. > > I understand what everybody is saying for confidential clients, no > problem here. > > I fall apart when thinking of iPhone apps. Consider the scenario > where I deploy a video server, and write an iPhone app to talk to the > video server. The video server is under the control of a police > agency, and police officers must logon to the video server in order to > access video content. So the police office launches their iPhone > video client app. > > If I wanted to solve authentication using "traditional" client-server > authentication, the user enters their username / password into the > client, and the client sends the username / password off to the > server, which authenticates it, or possibly uses HTTP digest. > > If I wanted to use OpenID, the client would attempt to reach the video > server (RP), the server would redirect the client to the OP, OP > authenticates user, and OP redirects client back to the server/RP with > an assertion that primary authentication was successful. > > If I wanted to use OAuth, the client would send an authorization > request to the server's AS, which would authenticate the user of the > client, and ultimately result in the client possessing an > access-token. My thinking is that this access token (let's assume > it's a JWT) would contain the user's identity, a statement of what > type of primary authentication was used (auth context), an expiration, > and an audience claim. This sounds a lot like authentication to me, > and it's where I get confused. Is it just because OAuth does not > explicitly define this? Is there a threat in using OAuth as I describe? > > If I wanted to use Connect, well I'm not even sure how the id_token as > defined by Connect helps this use case. The id_token seems to make > sense when the client is a confidential web server, but it's not clear > what an iPhone app would do with the id_token ... it's the server in > the backend that needs to authenticate the user, the iPhone app is > just an interface to talk to the server. And it seems as I learn more > about connect that the id_token is not meant to be sent from the > iPhone app to the server, just the access token. So it's really not > clear how Connect helps solve authentication for an iPhone client app > talking to a video server. If I'm sending access-tokens, it's just > OAuth again. > > What am I still missing? > > adam > > *From:*oauth-bounces@ietf.org > [mailto:oauth-bounces@ietf.org] *On Behalf Of *Kristofor Selden > *Sent:* Saturday, June 16, 2012 11:33 AM > *To:* nov matake; oauth > *Cc:* Yuchen Zhou; Luke Melia; Shuo Chen (MSR) > *Subject:* Re: [OAUTH-WG] Report an authentication issue > > Nov demonstrated the problem to us at Yapp and we used solution 4 > (because the solution is server side and our app was in the app store). > > FB Connect is authentication /and/ authorization, where OAuth 2 is > concerned only with authorization -- I'm not sure that app developers > appreciate this subtlety. > > With OAuth 2 you authorize an app to use a protected resource. With > FB Connect, you do that, but /also/ authenticate with the app you are > authorizing. > > So the access_token protects not just the FB resources but the auth > end point of the authorized app (very common with apps that use the > iOS SDK). So now the app needs a way to verify that it was the app > that was authorized to FB. > > Solution 4 explanation: on FB you can register a iPhone app and a > server app with the same client_id and get a client_secret for use on > the server. The server side API posts the access_token, client_id, > and client_secret to https://graph.facebook.com/app > to verify > that the bearer token actually belongs to the app that is being > authenticated before assuming they are authorized to the app's > protected resources. > > Kris > > On Jun 15, 2012, at 8:22 PM, nov matake wrote: > > > > There are 4 ways to fix this issue. > > 1. Use response_type=token%20code (It's not in OAuth 2.0 Core, but > seems best way for interoperability) > > 2. Use singed_request (or some signed token like JWT) > > 3. Use grant_type=fb_exchange_token (Facebook custom way) > > 4. Access to https://graph.facebook.com/app?access_token=YOUR_TOKEN > (Facebook custom way, moreover undocumented API) > > Two iPhone app developers I reported this issue fixed it by using (4). > > I also tried to use (1) for my own iPhone app implementation, but > unfortunately it doesn't work when using authorization codes obtained > via FB iOS SDK. > > So I'm using (3) in my case. > > nov > > On 2012/06/16, at 9:16, Nat Sakimura wrote: > > > > As to how the fix was done, Nov can provide more detail, but ... > > 1. Properly verify the signature/HMAC of the "signed_request". This > will essentially audience restricts the token. > > 2. There is an undocumented API for Facebook which returns to whom the > token was issued. This also audience restricts the token. > > The service that fixed took these measures. Note that none of the > above is defined in OAuth. > > The same facility was called "id_token" and "check ID endpoint" for > OpenID Connect. > > The scale of the impact is large, too large to disclose the actual > names in the public list, though, eventually, we would publish them in > a paper. > > Nat > > On Sat, Jun 16, 2012 at 5:34 AM, Francisco Corella > > wrote: > > Hi Nat and Rui, > > Rui, you say that the vulnerability that you found was due to a > "common misunderstanding among developers", but the attack you > describe can be carried out against any app that uses the OAuth > "implicit grant flow", which Facebook calls "client-side > authentication". No misunderstanding seems necessary. What > misunderstanding are you referring to? I followed the link in your > message to the Sophos post, and from there the link to the article in > The Register. The article in The Register says that Facebook had > "fixed the vulnerability promptly". How did they fix it? The > instructions that Facebook provides for implementing "Client-side > authentication without the JS SDK" at > https://developers.facebook.com/docs/authentication/client-side/#no-jssdk > still allows the attack. > > Nat, I agree that the blog post by John Bradley that you link to > refers to the same vulnerability reported by Rui. You say that some > apps have issued a patch to fix it. Could you explain what the fix > was? > > Francisco > > ------------------------------------------------------------------------ > > *From:*Nat Sakimura > > *To:* rui wang > > *Cc:* matake nov >; Yuchen > Zhou >; > oauth >; Shuo Chen (MSR) > > > *Sent:* Thursday, June 14, 2012 1:50 PM > *Subject:* Re: [OAUTH-WG] Report an authentication issue > > This is a fairly well known (hopefully by now) issue. We, at the > OpenID Foundation, call it "access_token phishing" attack these > days. See: > http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.html > > Nov Matake has actually built the code on iPhone to verify the > problem, and has notified bunch of parties back in February > including Facebook and Apple. We have the code that actually runs > on a phone, and we have successfully logged in to bunch of apps, > including very well known ones. They were all informed of the > issue. Some immediately issued a patch to fix it while others have > not. > > The problem is that even if these apps gets fixed, the problem > does not go away. As long as the attacker has the vulnerable > version of the app, he still can impersonate the victim. To stop > it, the server side has to completely disable the older version, > which means the service has to cut off many users pausing business > problems. > > Nat > > On Fri, Jun 15, 2012 at 2:18 AM, rui wang > wrote: > > Dear Facebook Security Team and OAuth Standard group, > > We are a research team in Microsoft Research. In January, 2011, we > reported a vulnerability in Facebook Connect which allowed > everyone to sign into Facebook-secured relying parties without > password. It was promptly fixed after reporting. > (http://nakedsecurity.sophos.com/2011/02/02/facebook-flaw-websites-steal-personal-data/) > > Recently, we found a common misunderstanding among developers of > mobile/metro apps when using OAuth (including Facebook's OAuth) > for authentication. The vulnerability resulted from this > misunderstanding also allows an attacker to log into a victim > user's account without password. > > Let's take Soluto's metro app as an example to describe the > problem. The app supports Facebook Login. As an attacker, we can > write a regular Facebook app. Once the victim user allows our app > to access her Facebook data, we receive an access_token from the > traffic. Then, on our own machine (i.e., the "attacker" machine), > we run the metro app of Soluto, and use a HTTP proxy to insert the > victim's access_token into the traffic of Facebook login. Through > this way, we are able to log into the victim's Soluto account from > our machine. Other than Soluto, we also have confirmed the same > issue on another Windows 8 metro-app Givit. > > The Facebook SDK for Android apps > (https://developers.facebook.com/docs/mobile/android/build/#sdk) > seems to have the possibility to mislead developers too. At least, > the issue that we found is not clearly mentioned. In the SDK, we > ran the sample code called "Hackbook" using Android Emulator > (imagine it is an attacker device). Note that we have already > received the access token of the victim user from our regular > Facebook app. We then inject the token to the traffic of Hackbook. > Through this way, Hackbook app on our own machine recognizes us as > the victim. Note that this is not a convincing security exploit > yet, because this sample code does not include the server-side > code. However, given that we have seen real server-side code > having this problem, such as Soluto, Givit and others, we do > believe that the sample code can mislead mobile/metro developers. > We also suspect that this may be a general issue of many OAuth > implementations on mobile platforms, so we send this message to > OAuth Standard group as well. > > We have contacted the vendors of the two vulnerable metro-apps, > Soluto and Gavit. > > Please kindly give us an ack when you receive this message. If you > want to know more details, please let us know. > > Best Regards, > Yuchen Zhou, Rui Wang, and Shuo Chen > > > _______________________________________________ > 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 > > > > -- > 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 > > > > _______________________________________________ > OAuth mailing 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 --------------040802060209030301090100 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Adam,

I agree with you that this is a significant use-case, one that is of particular interest for enterprise deployments.

My impression is that the fully specified OAuth flows to date focus on certain key consumer-centred use-cases and that important enterprise flows such as the one you have
described are yet to be profiled. We havent looked at OpenID Connect yet, but I dont believe  this was the main use-case for that effort either.

I support your call for a broader discussion of this issue.


- prateek



Hi Nat,

 

I’m beginning to wonder what it would take to add a new profile of sorts to either OAuth or Connect. 

 

In the beginning there was SOAP, and the preferred method to secure SOAP API calls was WS-Trust.

 

Now the world is moving toward RESTful APIs … and the preferred means to secure RESTful APIs is OAuth.

 

Except that OAuth is clearly written with the idea that the protected resources belong to the end user.

 

My use cases – and I imagine the use cases of many other enterprises – is that the Owner of the resources is the Enterprise.  An employee is trying to access a database or video resources.  The enterprise RS needs to be able to 1) identify the user, and 2) make authorization decisions based on what roles that user has within the enterprise.  So in my scenario, when a police officer attempts to access a criminal records database, the database needs to know who that officer is, and then decide if they have privilege to access the database, and at what level (e.g. CRUD). 

 

WS-Trust fits this model well.  The user performs primary authentication to the enterprise STS, which then grants the application client a SAML assertion.  When the user attempts to access a records database, the SAML assertion is included in the SOAP message.  The records server authenticates the user based on the SAML assertion and makes its authorization decisions.

 

This is the world I’m trying to migrate from, and it really seems like I’m sometimes trying to make a square peg fit in a round hole.  I’m looking for OAuth/Connect to do for REST what WS-TRUST did for SOAP.  I would like a native client talking to a RS to be able to ask for an id_token, and then pass that id_token to the RS when making its RESTful API calls, to enable the RS to authenticate the user.  I think that this would be really useful for a lot of people besides me.  I keep hearing that there is nothing “preventing” me from doing this … but it hardly seems within the spirit of what OAuth was meant to do.  The id_token was clearly meant to enable a user to authenticate to a confidential client  / web server … but was not meant for a native client to identity / authenticate the user to a RS. 

 

 

Would there be any interest in exploring this further?

-adam

 

 

From: Nat Sakimura [mailto:sakimura@gmail.com]
Sent: Wednesday, June 20, 2012 8:09 PM
To: Lewis Adam-CAL022
Cc: igor.faynberg@alcatel-lucent.com; oauth@ietf.org
Subject: Re: [OAUTH-WG] Report an authentication issue

 

Yes, OAuth can be profiled to enable authentication. 

In fact, initial draft of OpenID Connect was just like you described. 

Essentially, we were using structured access_token. 

Later, we decided to separate the access token and id_token for several reasons such as: 

 

  1. Better interop with existing OAuth implementations: by introducing id_token, they do not need to touch the supposedly opaque (which means AS-RS may be doing some proprietary thing inside it) access token. 
  2. Mixing up the audience (for id_token aka authn = client, and for access_token aka authz = resource server) probably is expanding the attack surface for security and privacy. 

Although we separated them out, a signed id_token includes the left hash of access_token so access_token is also protected. 

 

Best, 

 

Nat

 

On Thu, Jun 21, 2012 at 5:21 AM, Lewis Adam-CAL022 <Adam.Lewis@motorolasolutions.com> wrote:

Hi Igor,

 

As Justin just pointed out, consider the case where the video server is hosted by the state (e.g. California) and is accessed by police agencies in Los Angeles, San Francisco, and San Diego.  The State of California’s video server is the RS.  Each local police agency (LA/SF/SD) hosts an AS.  So when a police officer from LAPD launches the video client app on the iPhone, the client makes an OAuth request to the LAPD’s AS, which authenticates the police officer using agency level credentials.  The access token issued to the video client app on the iPhone is a JWT, signed by the agency AS, which might look something like this:

 

{“typ”:”JWT”,"alg":"ES256"}

{"iss":"https://as.lapd.california.gov",
  "prn":"alice@lapd.california.gov",
  "aud":" https://video_server1@state.california.gov",
  "iat":1300815780,
  "exp":1300819380,
  "acr":”password”}

hq4zk+ZknjggCQgZm7ea8fI79gJEsRy3E8LHDpYXWQIgZpkJN9CMLG8ENR4Nrw+n7iyzixBvKXX8P53BTCT4VghPBWhFYSt9tHWu/AtJfOTh6qaAsNdeCyG86jmtp3TDMwuL/cBUj2OtBZOQMFn7jQ9YB7klIz3RqVL+wNmeWI4=

 

The JWT might be optionally encrypted using JWE. 

 

I think what is becoming clear (and this is what I’m trying to vet) is that while there is nothing in OAuth that specifies authentication, it *can* be used for Authentication, if done in the way that I describe.  If I’m wrong about this, I really need to know.  I’ve vetted this idea of mine with quite of few people now – both within context of the list and off-line – and I think I’m okay. If you see any holes in what I describe, please point them out as I would prefer to uncover them now rather than after implementation or deployment!

 

Essentially I’m using OAuth as a RESTful version of WS-Trust, where my client can exchange primary credentials for a token (JWT) and present that token to a server as secondary authentication.  It’s just that it’s RESTful instead of SOAP :-)

 

As Justin as pointed out … I’ve basically made the access-token look like the id_token of Connect.  I was actually hoping to lay a path to Connect, and use the id_token … until it was also pointed out that the id_token is really meant for the consumption of the client, not the RS :-(

 

 

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Igor Faynberg
Sent: Wednesday, June 20, 2012 2:39 PM
To: oauth@ietf.org


Subject: Re: [OAUTH-WG] Report an authentication issue

 

But this use case  does need OAuth, period:



The video server is under the control of a police agency, and police officers must logon to the video server in order to access video content.

There is no delegation here, and there is no need to use third party for authentication. 

Igor

On 6/20/2012 3:26 PM, Justin Richer wrote:

In case it wasn't clear, I want to restate the original problem as best as I understand it in a way that hopefully clears it up:

App A and app B are both valid registered OAuth clients to an OAuth protected service.

The problem starts when app A gets handed a token that was issued for app B and uses it to call an identity API on the OAuth service. Since app B can get tokens just fine, they're bearer tokens, this is a fairly basic api call, this function works just fine and returns the user info. This makes sense, since anyone who holds A's tokens can do whatever A can do on behalf of that user. The issues start when app B then decides that since they can make a call to the identity API with a token then the user *must* be present. In other words, app B is confusing authorization to call an API with authentication of the session.

OpenID Connect fixes this missed assumption by binding the ID Token to the session and sending it along side the access token, but as you pointed out, it's meant for consumption at the client, not the resource server, in general. That doesn't mean you can't send it to a resource server for your own purposes, of course. That's actually how the session management endpoint works in Connect.

This isn't the only way to handle this problem -- if you put some structure in your tokens, such as with JWT or SAML, then app A can tell that this isn't a token issued to app A, but to app B, so it can call shenanigans and reject it then and there.

 -- Justin

On 06/20/2012 10:03 AM, Lewis Adam-CAL022 wrote:

I am entirely confused.

 

I understand what everybody is saying for confidential clients, no problem here.

 

I fall apart when thinking of iPhone apps.  Consider the scenario where I deploy a video server, and write an iPhone app to talk to the video server.  The video server is under the control of a police agency, and police officers must logon to the video server in order to access video content.  So the police office launches their iPhone video client app.

 

If I wanted to solve authentication using “traditional” client-server authentication, the user enters their username / password into the client, and the client sends the username / password off to the server, which authenticates it, or possibly uses HTTP digest. 

If I wanted to use OpenID, the client would attempt to reach the video server (RP), the server would redirect the client to the OP, OP authenticates user, and OP redirects client back to the server/RP with an assertion that primary authentication was successful. 

If I wanted to use OAuth, the client would send an authorization request to the server’s AS, which would authenticate the user of the client, and ultimately result in the client possessing an access-token.  My thinking is that this access token (let’s assume it’s a JWT) would contain the user’s identity, a statement of what type of primary authentication was used (auth context), an expiration, and an audience claim.  This sounds a lot like authentication to me, and it’s where I get confused.  Is it just because OAuth does not explicitly define this?  Is there a threat in using OAuth as I describe? 

If I wanted to use Connect, well I’m not even sure how the id_token as defined by Connect helps this use case.  The id_token seems to make sense when the client is a confidential web server, but it’s not clear what an iPhone app would do with the id_token … it’s the server in the backend that needs to authenticate the user, the iPhone app is just an interface to talk to the server.  And it seems as I learn more about connect that the id_token is not meant to be sent from the iPhone app to the server, just the access token.  So it’s really not clear how Connect helps solve authentication for an iPhone client app talking to a video server.  If I’m sending access-tokens, it’s just OAuth again.

 

What am I still missing?

adam

 

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Kristofor Selden
Sent: Saturday, June 16, 2012 11:33 AM
To: nov matake; oauth
Cc: Yuchen Zhou; Luke Melia; Shuo Chen (MSR)
Subject: Re: [OAUTH-WG] Report an authentication issue

 

Nov demonstrated the problem to us at Yapp and we used solution 4 (because the solution is server side and our app was in the app store).

 

FB Connect is authentication and authorization, where OAuth 2 is concerned only with authorization – I'm not sure that app developers appreciate this subtlety.

 

With OAuth 2 you authorize an app to use a protected resource.  With FB Connect, you do that, but also authenticate with the app you are authorizing.

 

So the access_token protects not just the FB resources but the auth end point of the authorized app (very common with apps that use the iOS SDK).  So now the app needs a way to verify that it was the app that was authorized to FB.

 

Solution 4 explanation: on FB you can register a iPhone app and a server app with the same client_id and get a client_secret for use on the server.  The server side API posts the access_token, client_id, and client_secret to https://graph.facebook.com/app to verify that the bearer token actually belongs to the app that is being authenticated before assuming they are authorized to the app's protected resources.

 

Kris

 

On Jun 15, 2012, at 8:22 PM, nov matake wrote:



There are 4 ways to fix this issue.

 

1. Use response_type=token%20code (It's not in OAuth 2.0 Core, but seems best way for interoperability)

2. Use singed_request (or some signed token like JWT)

3. Use grant_type=fb_exchange_token (Facebook custom way)

4. Access to https://graph.facebook.com/app?access_token=YOUR_TOKEN (Facebook custom way, moreover undocumented API)

 

Two iPhone app developers I reported this issue fixed it by using (4).

 

I also tried to use (1) for my own iPhone app implementation, but unfortunately it doesn't work when using authorization codes obtained via FB iOS SDK.

So I'm using (3) in my case.

 

nov

 

On 2012/06/16, at 9:16, Nat Sakimura wrote:



As to how the fix was done, Nov can provide more detail, but ... 

 

1. Properly verify the signature/HMAC of the "signed_request". This will essentially audience restricts the token. 

2. There is an undocumented API for Facebook which returns to whom the token was issued. This also audience restricts the token. 

 

The service that fixed took these measures. Note that none of the above is defined in OAuth. 

The same facility was called "id_token" and "check ID endpoint" for OpenID Connect. 

 

The scale of the impact is large, too large to disclose the actual names in the public list, though, eventually, we would publish them in a paper. 

 

Nat

On Sat, Jun 16, 2012 at 5:34 AM, Francisco Corella <fcorella@pomcor.com> wrote:

Hi Nat and Rui,

Rui, you say that the vulnerability that you found was due to a
"common misunderstanding among developers", but the attack you
describe can be carried out against any app that uses the OAuth
"implicit grant flow", which Facebook calls "client-side
authentication".  No misunderstanding seems necessary.  What
misunderstanding are you referring to?  I followed the link in your
message to the Sophos post, and from there the link to the article in
The Register.  The article in The Register says that Facebook had
"fixed the vulnerability promptly".  How did they fix it?  The
instructions that Facebook provides for implementing "Client-side
authentication without the JS SDK" at
https://developers.facebook.com/docs/authentication/client-side/#no-jssdk
still allows the attack.

Nat, I agree that the blog post by John Bradley that you link to
refers to the same vulnerability reported by Rui.  You say that some
apps have issued a patch to fix it.  Could you explain what the fix
was?

Francisco

 

From: Nat Sakimura <sakimura@gmail.com>
To: rui wang <ruiwangwarm@gmail.com>
Cc: matake nov <nov@matake.jp>; Yuchen Zhou <t-yuzhou@microsoft.com>; oauth <oauth@ietf.org>; Shuo Chen (MSR) <shuochen@microsoft.com>
Sent: Thursday, June 14, 2012 1:50 PM
Subject: Re: [OAUTH-WG] Report an authentication issue

 

This is a fairly well known (hopefully by now) issue. We, at the OpenID Foundation, call it "access_token phishing" attack these days. See: http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.html

 

Nov Matake has actually built the code on iPhone to verify the problem, and has notified bunch of parties back in February including Facebook and Apple. We have the code that actually runs on a phone, and we have successfully logged in to bunch of apps, including very well known ones. They were all informed of the issue. Some immediately issued a patch to fix it while others have not.  

 

The problem is that even if these apps gets fixed, the problem does not go away. As long as the attacker has the vulnerable version of the app, he still can impersonate the victim. To stop it, the server side has to completely disable the older version, which means the service has to cut off many users pausing business problems. 

 

Nat

On Fri, Jun 15, 2012 at 2:18 AM, rui wang <ruiwangwarm@gmail.com> wrote:

Dear Facebook Security Team and OAuth Standard group,

We are a research team in Microsoft Research. In January, 2011, we reported a vulnerability in Facebook Connect which allowed everyone to sign into Facebook-secured relying parties without password. It was promptly fixed after reporting. (http://nakedsecurity.sophos.com/2011/02/02/facebook-flaw-websites-steal-personal-data/)

Recently, we found a common misunderstanding among developers of mobile/metro apps when using OAuth (including Facebook’s OAuth) for authentication. The vulnerability resulted from this misunderstanding also allows an attacker to log into a victim user's account without password.

Let's take Soluto's metro app as an example to describe the problem. The app supports Facebook Login. As an attacker, we can write a regular Facebook app. Once the victim user allows our app to access her Facebook data, we receive an access_token from the traffic. Then, on our own machine (i.e., the "attacker" machine), we run the metro app of Soluto, and use a HTTP proxy to insert the victim's access_token into the traffic of Facebook login. Through this way, we are able to log into the victim's Soluto account from our machine. Other than Soluto, we also have confirmed the same issue on another Windows 8 metro-app Givit.

The Facebook SDK for Android apps (https://developers.facebook.com/docs/mobile/android/build/#sdk) seems to have the possibility to mislead developers too. At least, the issue that we found is not clearly mentioned. In the SDK, we ran the sample code called "Hackbook" using Android Emulator (imagine it is an attacker device). Note that we have already received the access token of the victim user from our regular Facebook app. We then inject the token to the traffic of Hackbook. Through this way, Hackbook app on our own machine recognizes us as the victim. Note that this is not a convincing security exploit yet, because this sample code does not include the server-side code. However, given that we have seen real server-side code having this problem, such as Soluto, Givit and others, we do believe that the sample code can mislead mobile/metro developers. We also suspect that this may be a general issue of many OAuth implementations on mobile platforms, so we send this message to OAuth Standard group as well.

We have contacted the vendors of the two vulnerable metro-apps, Soluto and Gavit.

Please kindly give us an ack when you receive this message. If you want to know more details, please let us know.

Best Regards,
Yuchen Zhou, Rui Wang, and Shuo Chen


_______________________________________________
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



 

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

 

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


--------------040802060209030301090100-- From Michael.Jones@microsoft.com Fri Jun 22 14:33:42 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12B7F21F85A1 for ; Fri, 22 Jun 2012 14:33:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.855 X-Spam-Level: X-Spam-Status: No, score=-3.855 tagged_above=-999 required=5 tests=[AWL=-0.256, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QSzXODit-aVw for ; Fri, 22 Jun 2012 14:33:41 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe010.messaging.microsoft.com [216.32.180.30]) by ietfa.amsl.com (Postfix) with ESMTP id 2147521F859E for ; Fri, 22 Jun 2012 14:33:41 -0700 (PDT) Received: from mail151-va3-R.bigfish.com (10.7.14.244) by VA3EHSOBE009.bigfish.com (10.7.40.29) with Microsoft SMTP Server id 14.1.225.23; Fri, 22 Jun 2012 21:32:09 +0000 Received: from mail151-va3 (localhost [127.0.0.1]) by mail151-va3-R.bigfish.com (Postfix) with ESMTP id 411593A0130; Fri, 22 Jun 2012 21:32:09 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC106.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -39 X-BigFish: VS-39(zf7Iz9371I8f9R936eI542M4015Izz1202hzz1033IL8275dhz2fh2a8h668h839hd25hf0ah) Received-SPF: pass (mail151-va3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC106.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail151-va3 (localhost.localdomain [127.0.0.1]) by mail151-va3 (MessageSwitch) id 1340400727726722_26823; Fri, 22 Jun 2012 21:32:07 +0000 (UTC) Received: from VA3EHSMHS011.bigfish.com (unknown [10.7.14.248]) by mail151-va3.bigfish.com (Postfix) with ESMTP id AE58D2004B; Fri, 22 Jun 2012 21:32:07 +0000 (UTC) Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS011.bigfish.com (10.7.99.21) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 22 Jun 2012 21:32:07 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.53]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.02.0309.003; Fri, 22 Jun 2012 21:33:29 +0000 From: Mike Jones To: Brian Campbell , oauth Thread-Topic: [OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-urn-sub-ns-04.txt Thread-Index: AQHNULI2JUDlvyeQX0a2G9sKKbr+GJcG27yA Date: Fri, 22 Jun 2012 21:33:28 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943665652FA@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <20120622195253.25511.91297.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.76] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-urn-sub-ns-04.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, 22 Jun 2012 21:33:42 -0000 Good - thanks. I'll personally say that I believe this is ready for IETF L= C now. -- Mike -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of B= rian Campbell Sent: Friday, June 22, 2012 1:04 PM To: oauth Subject: [OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-urn-sub-ns-04.txt Draft -04 of "An IETF URN Sub-Namespace for OAuth" has been published and i= s available at http://tools.ietf.org/html/draft-ietf-oauth-urn-sub-ns-04 - the changes fro= m the previous version are listed below. Per http://www.ietf.org/mail-archive/web/oauth/current/msg09407.html and barring any objections, I'd ask the Chairs to give the AD the okay to m= ove this to LC. draft-ietf-oauth-urn-sub-ns-04 o Changed the Index value (and Registration Template into paragraph) from to just with a suggestion that it have both a "class" and an "identifier-within-class" parts per http://www.ietf.org/mail-archive/web/oauth/current/msg09381.html so as to be less restrictive Thanks, Brian ---------- Forwarded message ---------- From: Date: Fri, Jun 22, 2012 at 1:52 PM Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-urn-sub-ns-04.txt To: i-d-announce@ietf.org Cc: oauth@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts director= ies. =A0This draft is a work item of the Web Authorization Protocol Working Grou= p of the IETF. =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : An IETF URN Sub-Namespace for OA= uth =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Brian Campbell =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Hannes Tschofenig =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-oauth-urn-sub-ns-04.txt =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 7 =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-06-22 Abstract: =A0 This document establishes an IETF URN Sub-namespace for use with =A0 OAuth related specifications. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-urn-sub-ns There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-urn-sub-ns-04 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-urn-sub-ns-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From barryleiba.mailing.lists@gmail.com Sat Jun 23 04:53:35 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36D4621F84FF for ; Sat, 23 Jun 2012 04:53:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.946 X-Spam-Level: X-Spam-Status: No, score=-102.946 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 2UQieS1egRTK for ; Sat, 23 Jun 2012 04:53:34 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6878C21F84D0 for ; Sat, 23 Jun 2012 04:53:34 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so5028623lbb.31 for ; Sat, 23 Jun 2012 04:53:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=wlst4aVHISRphchLOe6A4nbV4UMqey2/doFjUfkW59Q=; b=RTnsttT8WPsnOyhQRafiTesYfxR+I5ffyTEt6ww4OkKLqXePJK4klI5ItQSXKjMzt+ hzjgYen+uT9lrH8RGfLokr4b7j4a3PGxdEIoTcDcOtaiFhSxGWzkiC37juoHPyi5nYa/ 8NRjwBzAuIQgt81yVsmBf5imXO7Ev/DcHZoh064qD8OOQlXAgyWyyPynehIZVW6nRq7h GeB93jeUa8Q+uyKMsvKR1UGlKZz0LYDuT+tv8gi38LBwUSv4dqNo9UWqsCuFX7eq5ioA gJYJN4Aw9iY8Hm9o0RliBObR3jcKUi57lUb/B0S44jNR8zbFmAu83sY9XG5i87l/dOSK H/Dw== MIME-Version: 1.0 Received: by 10.152.103.11 with SMTP id fs11mr5366350lab.23.1340452413380; Sat, 23 Jun 2012 04:53:33 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.48.104 with HTTP; Sat, 23 Jun 2012 04:53:33 -0700 (PDT) In-Reply-To: References: <20120622195253.25511.91297.idtracker@ietfa.amsl.com> Date: Sat, 23 Jun 2012 13:53:33 +0200 X-Google-Sender-Auth: PrYMn2V_HHIpHSBOoRDLQ0uIi2w Message-ID: From: Barry Leiba To: Brian Campbell Content-Type: multipart/alternative; boundary=f46d040715c5f0198804c3226501 Cc: oauth Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-urn-sub-ns-04.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, 23 Jun 2012 11:53:35 -0000 --f46d040715c5f0198804c3226501 Content-Type: text/plain; charset=ISO-8859-1 > > Per http://www.ietf.org/mail-archive/web/oauth/current/msg09407.html > and barring any objections, I'd ask the Chairs to give the AD the okay > to move this to LC. The irresponsible AD from Apps thinks this s a fine idea, and that this version is ready. Barry --f46d040715c5f0198804c3226501 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Per http://www.ietf.org/= mail-archive/web/oauth/current/msg09407.html
and barring any objections, I'd ask the Chairs to give the AD the okay<= br> to move this to LC.

The irresponsible AD fr= om Apps thinks this s a fine idea, and that this version is ready.

Barry=A0
--f46d040715c5f0198804c3226501-- From hannes.tschofenig@gmx.net Sat Jun 23 05:31:51 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45EEC21F8437 for ; Sat, 23 Jun 2012 05:31:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.509 X-Spam-Level: X-Spam-Status: No, score=-102.509 tagged_above=-999 required=5 tests=[AWL=0.090, 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 NdEun1CZDyfz for ; Sat, 23 Jun 2012 05:31:50 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 3D50121F8435 for ; Sat, 23 Jun 2012 05:31:49 -0700 (PDT) Received: (qmail invoked by alias); 23 Jun 2012 12:31:47 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.109]) [88.115.216.191] by mail.gmx.net (mp034) with SMTP; 23 Jun 2012 14:31:47 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/fOiZx7iLfylfqkzpi8Mc3LNFxz/BTYcIvp2EQNO ckFPDEcA0aeHDM Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436656365A@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Sat, 23 Jun 2012 15:31:45 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4FE1C16D.6010602@cs.tcd.ie> <4CD0B85C-C88D-4B52-81E4-5D53A25E60EF@cs.tcd.ie>, <4E1F6AAD24975D4BA5B16804296739436656365A@TK5EX14MBXC283.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: "oauth@ietf.org" , Barry Leiba Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-urn-sub-ns-02 X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 12:31:51 -0000 Hi Mike,=20 the point is not that other groups, like OASIS, cannot use them. They = can use the extensions.=20 The question is more what process and documentation is needed to allow = OASIS (and others) to define their own extensions.=20 So far, OASIS had not been interested for any extension (at least from = what I know). The OpenID community, to which you also belong, had = defined extensions (and brought some of them to the IETF) but had been = quite careful themselves to ensure proper review and documentation.=20 So, if you look at the most important decision points then you have:=20 1) do you want a requirement for a specification, i.e., when someone = defines an extension do you want it to be documented somewhere?=20 2) do you envision a review from experts (e.g., checking whether the = stuff makes any sense or conflicts with some other already available = extensions)?=20 http://tools.ietf.org/html/rfc5226 provides a good discussion about this = topic.=20 If the answer to the above-listed questions is YES then you probably at = least want 'Specification Required' as a policy.=20 Ciao Hannes On Jun 21, 2012, at 10:49 PM, Mike Jones wrote: > I'd argue that the registration regime chosen should be flexible = enough to permit OASIS or OpenID specs to use it. Otherwise, as someone = else pointed, people will work around the limitation by using = unregistered values - which helps no one. >=20 > -- Mike >=20 > From: Barry Leiba > Sent: 6/21/2012 12:31 PM > To: Stephen Farrell > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-urn-sub-ns-02 >=20 > >> Stephen: > >> Yeah, I'm not sure Standards Track is needed. > > > > On this bit: I personally don't care, except that we don't have to = do it twice > > because someone later on thinks the opposite and wins that argument, = which > > I'd rather not have at all (My one-track mind:-) Doing the 4 week = last call means > > once is enough. But I'm ok with whatever the WG want. >=20 > Well, it's not a 4-week LC, but a 2-week one. Anyway, yes, I see your > point, and I've done that with other documents. Better to make it > Standards Track for now, note in the shepherd writeup that > Informational is probably OK, and let the IESG decide. >=20 > b > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From hannes.tschofenig@gmx.net Sat Jun 23 05:38:18 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1088621F8507 for ; Sat, 23 Jun 2012 05:38:18 -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.086, 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 r0hloxL+FS1A for ; Sat, 23 Jun 2012 05:38:17 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id CA8F121F8503 for ; Sat, 23 Jun 2012 05:38:16 -0700 (PDT) Received: (qmail invoked by alias); 23 Jun 2012 12:38:15 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.109]) [88.115.216.191] by mail.gmx.net (mp017) with SMTP; 23 Jun 2012 14:38:15 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19xARB6QiVxiYQQJvQEHGI4olL0HujN7Dhr77B8wq 36OfErIwvWOoN7 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: Date: Sat, 23 Jun 2012 15:38:14 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <32567D79-0412-42FB-8D4C-4ECD33D54E3C@gmx.net> References: <20120621175317.32545.76545.idtracker@ietfa.amsl.com> To: Brian Campbell X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: OAuth WG , Barry Leiba Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-urn-sub-ns-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: Sat, 23 Jun 2012 12:38:18 -0000 Hi Brian,=20 you typically do not dump unrelated parameters into the same registry.=20= Think of a registry as a table. A table has a policy that is executed = when IANA gets a request for adding a new row to the table. A table also = has columns, namely those that we define in our documents. An example of such a table can be found here:=20 http://www.iana.org/assignments/params/params.xml The policy for adding new rows is 'IETF Consensus'.=20 Now, it would have been possible to dump all the values from the = sub-registries (XML, sieve, etc.) into this table. Since each of these = sub-registries have different policies for adding new values this would = have been totally confusing for readers and for IANA.=20 It would also be confusing for the reader when it looks for XML schema = registries (see = http://www.iana.org/assignments/xml-registry/schema.html) to also find = the sieve registry values in there (see = http://www.iana.org/assignments/sieve-extensions/sieve-extensions.xml).=20= You are essentially suggesting to dump everything into the same table. = While this is theoretically possible it does not offer any obvious = advantage. Creating sub-registries in the draft-ietf-oauth-urn-sub-ns = just requires a few more lines of text and we will manage to write that = text.=20 Ciao Hannes On Jun 21, 2012, at 10:55 PM, Brian Campbell wrote: > I honestly don't understand the push to have additional registries > under urn:ietf:params:oauth? >=20 > On Thu, Jun 21, 2012 at 1:28 PM, Barry Leiba = wrote: >> This one's mostly there. As Mike and Hannes are discussing, the WG >> needs to sort out exactly what goes under "oauth" here. >>=20 >> Here's a suggestion: >> Have Section 3 specify that what comes after "oauth" are one or more >> tokens, delimited by ":". >> Have Section 3 create the registry for the first-level token, = "class". >> In your example, that's "grant-type". >> Have Section 3 specify that the definition of each "class" token >> specifies what comes after it -- how many tokens, and the meaning(s). >> Have Section 3 note that certain classes might create new >> sub-registries for what goes under them, if necessary. >> Have Section 3 note that certain classes might have *no* further >> tokens under them. >>=20 >> I realize that there might not be any use cases envisioned right now >> for that last one, but it might be a bad idea to forbid it. >>=20 >> Section 5: >>=20 >> o Repository: [[not sure about this? this document or >> http://www.iana.org/assignments/oauth]] >>=20 >> Yeh, I've never been sure about that either. I think what you want >> here is "[[The registry created in Section 3.]]". >> See RFC 6134 for how I did this with the "sieve" namespace. >>=20 >> Barry >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From hannes.tschofenig@gmx.net Sat Jun 23 05:39:11 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 875BE21F8503 for ; Sat, 23 Jun 2012 05:39:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.516 X-Spam-Level: X-Spam-Status: No, score=-102.516 tagged_above=-999 required=5 tests=[AWL=0.083, 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 73dWSqYrHAXY for ; Sat, 23 Jun 2012 05:39:10 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 709FA21F8507 for ; Sat, 23 Jun 2012 05:39:10 -0700 (PDT) Received: (qmail invoked by alias); 23 Jun 2012 12:39:09 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.109]) [88.115.216.191] by mail.gmx.net (mp017) with SMTP; 23 Jun 2012 14:39:09 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/2N2l3cPP2oy+BdowkJM0K5uf8z08Kd5OWL/+Z3h RqWbXxYVP+TDF2 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943665637A0@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Sat, 23 Jun 2012 15:39:08 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <1555CD18-316D-4293-9D13-8BC241F6CB38@gmx.net> References: <20120621175317.32545.76545.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B1680429673943665637A0@TK5EX14MBXC283.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: OAuth WG , Barry Leiba Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-urn-sub-ns-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: Sat, 23 Jun 2012 12:39:11 -0000 Hi Mike,=20 in a previous mail you wanted to even be more flexible by having not = only two levels but potentially three levels.=20 Now, you say one registry is sufficient.=20 That does not make sense.=20 Ciao Hannes On Jun 21, 2012, at 11:29 PM, Mike Jones wrote: > I agree that one registry is sufficient. The number of registrations = won't be huge and so having sub-registries seems like overkill. >=20 > -- Mike >=20 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf = Of Brian Campbell > Sent: Thursday, June 21, 2012 12:55 PM > To: Barry Leiba > Cc: OAuth WG > Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-urn-sub-ns-03.txt >=20 > I honestly don't understand the push to have additional registries = under urn:ietf:params:oauth? >=20 > On Thu, Jun 21, 2012 at 1:28 PM, Barry Leiba = wrote: >> This one's mostly there. As Mike and Hannes are discussing, the WG=20= >> needs to sort out exactly what goes under "oauth" here. >>=20 >> Here's a suggestion: >> Have Section 3 specify that what comes after "oauth" are one or more=20= >> tokens, delimited by ":". >> Have Section 3 create the registry for the first-level token, = "class". >> In your example, that's "grant-type". >> Have Section 3 specify that the definition of each "class" token=20 >> specifies what comes after it -- how many tokens, and the meaning(s). >> Have Section 3 note that certain classes might create new=20 >> sub-registries for what goes under them, if necessary. >> Have Section 3 note that certain classes might have *no* further=20 >> tokens under them. >>=20 >> I realize that there might not be any use cases envisioned right now=20= >> for that last one, but it might be a bad idea to forbid it. >>=20 >> Section 5: >>=20 >> o Repository: [[not sure about this? this document or >> http://www.iana.org/assignments/oauth]] >>=20 >> Yeh, I've never been sure about that either. I think what you want=20= >> here is "[[The registry created in Section 3.]]". >> See RFC 6134 for how I did this with the "sieve" namespace. >>=20 >> Barry >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From hannes.tschofenig@gmx.net Sat Jun 23 07:30:24 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25DF321F8507 for ; Sat, 23 Jun 2012 07:30:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.52 X-Spam-Level: X-Spam-Status: No, score=-103.52 tagged_above=-999 required=5 tests=[AWL=1.079, BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9TBA+cyhxiLH for ; Sat, 23 Jun 2012 07:30:22 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 52EA521F842B for ; Sat, 23 Jun 2012 07:30:22 -0700 (PDT) Received: (qmail invoked by alias); 23 Jun 2012 14:30:20 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.109]) [88.115.216.191] by mail.gmx.net (mp033) with SMTP; 23 Jun 2012 16:30:20 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19/DLZgC2R/8P+C1G6P1DZzqJfg+MDn79/R5Tr0kV OqM3lePUMkirZo Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Hannes Tschofenig In-Reply-To: Date: Sat, 23 Jun 2012 17:30:19 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120621175317.32545.76545.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B16804296739436656323F@TK5EX14MBXC283.redmond.corp.microsoft.com> <0F4BC83D-9C3E-44CD-9D8C-5784A7495486@gmx.net> To: Brian Campbell X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-urn-sub-ns-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: Sat, 23 Jun 2012 14:30:24 -0000 Hi Brian,=20 Hi Brian,=20 On Jun 21, 2012, at 11:48 PM, Brian Campbell wrote: > On Thu, Jun 21, 2012 at 1:48 PM, Hannes Tschofenig > wrote: >> Btw, in a discussion with Brian we check the policies for the three = extensions in the OAuth core specification >>=20 >> 1) Section 8.3. Defining New Authorization Grant Types >>=20 >> If you don't define additional token endpoint parameters then there = is actually no requirement for expert review or a specification. >> It is probably FCFS. >=20 >=20 > That raises a different question/issue. It is a related issue.=20 The core document says you need an URI for defining new extensions and = that means everyone can almost do whatever they want (as I tried to = explain in this mail). Note that I saw "almost" -- as you will see = below. =20 >=20 > My understanding of the core spec was that it used URIs in extension > points that might be profiled by actual specifications as well as by > vendor-specific or other less rigorous implementations. Correct.=20 For the extensions that are registered under urn:ietf:params:oauth we = do, however, need to define the policy.=20 >=20 > To the extent that's true, =A78.3 of OAuth core[1] is problematic in > that it allows for any URI defining the grant type but requires > additional parameters the grant type might use to be registered in the > The OAuth Parameters Registry (and new grant types will most likely > need additional parameters). I agree with you.=20 >=20 > Inf fact, I've already got a vendor-specific grant type that uses an > unregistered parameter on the token endpoint - it's a simple grant > type for access token introspection [2]. At the time I was thinking > the parameter was implicitly qualified by the grant type and this was > all okay. But looking at it again, per the letter of the spec, this > would seem to be a violation. But what should we have done? How does a > vendor-specific extension go about registering a parameter? Would that > even be a good idea? The URN you have chosen for your product = (urn:pingidentity.com:oauth2:validated_token) is, however, IMHO = incorrect. There is no URN registered that starts with = urn:pingidentity.com (see = http://www.iana.org/assignments/urn-namespaces/urn-namespaces.xml) but I = am happy to be educated otherwise.=20 You could have just used = http://www.pingidentity.com/oauth2/validated_token (or anything like = that). The problem with that is that some folks will then try to do a = lookup on this URI and will, surprise - surprise, not find anything = because this URI is just meant for a different purpose. That's the only = problem.=20 Of course we could also allow a vendor specific branch in the URN we are = defining (something which uses a enterprise id, see = http://www.iana.org/assignments/enterprise-numbers).=20 Ciao Hannes >=20 > [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-28#section-8.3 > [2] = http://documentation.pingidentity.com/display/PF66/Grant+Type+Parameters#G= rantTypeParameters-1079271 From hannes.tschofenig@gmx.net Sat Jun 23 07:41:28 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFB6621F84CD for ; Sat, 23 Jun 2012 07:41:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.036, 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 vbP+iN10Mkc3 for ; Sat, 23 Jun 2012 07:41:26 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 6437621F8480 for ; Sat, 23 Jun 2012 07:41:26 -0700 (PDT) Received: (qmail invoked by alias); 23 Jun 2012 14:41:24 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.109]) [88.115.216.191] by mail.gmx.net (mp070) with SMTP; 23 Jun 2012 16:41:24 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+gDn0Gg9mgNkP/GYPs7fQrwBW4AN/en3YIqn/jIb +EPkpF2+hGGFFe Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: Date: Sat, 23 Jun 2012 17:41:23 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120621175317.32545.76545.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B16804296739436656323F@TK5EX14MBXC283.redmond.corp.microsoft.com> <0F4BC83D-9C3E-44CD-9D8C-5784A7495486@gmx.net> To: Brian Campbell X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-urn-sub-ns-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: Sat, 23 Jun 2012 14:41:28 -0000 Hi Brian,=20 On Jun 22, 2012, at 12:07 AM, Brian Campbell wrote: > As far as the rest of the policy discussion, I have no interest or > intent to define policy for this stuff. A year+ ago I needed a URI for > the SAML grant type. It could be anything but it should be something > stable. And it'd be nice if it was semi-meaningful. I was using > http://openid.net or something for a while and there were concerns > about ownership and stability. Also because SAML grant was an IETF > draft, it seed to make sense to have an IETF URI. I didn't know how to > get one so I asked. This all makes sense.=20 > Eventually Hannes suggested the text that became > draft-ietf-oauth-urn-sub-ns. A few more things came along that > similarly needed URIs (JWT grant and client assertion auth) so it > seemed to be working out well. It indeed does work in the way you had envisioned.=20 > Very little changed in that draft for > nearly a year until the AD review yesterday brought up some > deficiencies. I tried to address those in -03 today (and would like to > do a -04 soon with the minor changes Mike suggested). Fully understand that.=20 With many drafts few people read through them in detail only when the = last call for comment starts.=20 >=20 > With that said, all I really wanted was an easy way to reserve or > register a stable and somewhat meaningful URI. It's proven not to be > easy, however. Adding additional sub-registries and policy to > urn:ietf:params:oauth, which will probably only ever have a few values > in it, seems to me to be unnecessarily adding a lot of overhead to it > all. What is the overhead?=20 If you want a new URN for a new grant type then you=20 1) pick an string that has not been used before (you see in the registry = what others had put in there already.=20 Example: foo-bar=20 2) you stick it to urn:ietf:params:oauth:grant-type:=20 Example: urn:ietf:params:oauth:grant-type:foo-bar If you instead want to define a new assertion type you will have to = stick it to urn:ietf:params:oauth:client-assertion-type: Then, you send that request to IANA (with the template we defined in the = draft).=20 The only discussion point we are having is whether=20 * you have to add a link to the specification that defines what this = foo-bar grant type is,=20 * whether there is any review following the registration.=20 That's all. Does not sound very complicated to me.=20 >=20 > Perhaps I'm mistaken but wouldn't Expert Review catch URIs that are > just wrong prior to registration? And even if it didn't, what really > is the harm? With expert review you, for example, do not have to add a pointer to the = specification to the registry.=20 The expert obviously has to get the document since otherwise he wouldn't = know what to do.=20 In your example from above would you be OK to stick the link to the = document into the registry?=20 Ciao Hannes >=20 >=20 >=20 >=20 >=20 > On Thu, Jun 21, 2012 at 1:48 PM, Hannes Tschofenig > wrote: >> Btw, in a discussion with Brian we check the policies for the three = extensions in the OAuth core specification >>=20 >> 1) Section 8.3. Defining New Authorization Grant Types >>=20 >> If you don't define additional token endpoint parameters then there = is actually no requirement for expert review or a specification. >> It is probably FCFS. >>=20 >> 2) Section 8.1. Defining Access Token Types >>=20 >> For URIs there seems to be no constraint either although the text = talks about limited to vendor-specific implementations. >>=20 >> 3) client_assertion_type is created in = http://tools.ietf.org/html/draft-ietf-oauth-assertions-03#section-8.3 >>=20 >> There is no description either for what is required to register a new = assertion type into the URN class client_assertion_type. >>=20 >> (For client authentication mechanisms there is actually no registry = in core and therefore there is no policy either.) >>=20 >> Ciao >> Hannes >>=20 >> On Jun 21, 2012, at 10:12 PM, Hannes Tschofenig wrote: >>=20 >>> Hi Mike, >>>=20 >>> Thanks for your mail. >>>=20 >>> First, I would like to argue for a registry that has more than one = level. We need a two level registry because the different extensions = have (and will also in the future) have different extension policies. >>>=20 >>> The structure of the registry is: urn:ietf:params:oauth:: >>>=20 >>> On the first level, the part, we have high level = functionality that was defined in the core specification. This includes = things like >>>=20 >>> 1) authorization grants (which you call grant-type in your = registration request in = http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-12) >>>=20 >>> So, this would be urn:ietf:params:oauth:grant-type >>>=20 >>> 2) client authentication mechanism (which you call = client-assertion-type in = http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-12 but should = rather mean something like client-auth-type) >>>=20 >>> So, this could be something like = urn:ietf:params:oauth:client-auth-type >>>=20 >>> 3) Access Token Types (which is called 'token-type' in = http://www.ietf.org/id/draft-ietf-oauth-json-web-token-00.txt) >>>=20 >>> This is urn:ietf:params:oauth:token-type. >>>=20 >>> [PS: The text in the = http://tools.ietf.org/html/draft-ietf-oauth-v2-28#section-8.1 for = registering new access token types is a bit confusing and I am not sure = whether an absolute URI would actually be required even though it makes = a lot of sense.] >>>=20 >>> While I believe that our initial requirement for "RFC required" for = adding these top level classes makes sense since these basic extension = features to OAuth are really core to the protocol functionality it is = good that the group checks them carefully. >>>=20 >>> Then, at the level the individual values reside. For the = authorization grant this is 'saml2-bearer' as defined in = http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-12#section-6. >>>=20 >>> So, what is the right policy for adding values under = urn:ietf:params:oauth:grant-type? = http://tools.ietf.org/html/draft-ietf-oauth-v2-28#section-8.3 says what = the policy is. So, instead of re-deciding a new policy for adding = entries here it would be good to get it inline with what the policy is = in the core spec. >>>=20 >>> What could go wrong if the two are not aligned? I actually had that = case in the DIME working group. Without going into the details the = registry had a much stronger policy (RFC required) than the protocol = specification (which only required a specification, if I remember it). = The consequence was that people couldn't easily register new values from = other organizations since they would fail in the last step when a new = registry value had to be created (since IANA then told them 'RFC = Required'). Consequently, these other organizations who wanted to get = their work done then avoided doing so by misusing other extensions, = which was really not good. >>>=20 >>> Mike, you have actually been suggesting that a three level category = for certain classes of sub-registries is actually OK as well. That may = be true and we could relax the text to say that whoever defines the = class also decides about the structure of the child elements underneath = it. >>>=20 >>> What I believe we need to add in the document is to populate the = registry with the three URIs (from above; referring to the classes) and = pointing to the policy from the core specification. Then, other docs = (like draft-ietf-oauth-json-web-token-00.txt) can just put their values = in there. >>>=20 >>> Ciao >>> Hannes >>>=20 >>>=20 >>> On Jun 21, 2012, at 9:14 PM, Mike Jones wrote: >>>=20 >>>> This draft is much clearer. Thanks for the quick turn-around. >>>>=20 >>>> One question: You added: >>>> *Index value: values subordinate to urn:ietf:params:oauth are of = the from urn:ietf:params:oauth:: with : as the = index value >>>> Why bake the assumption of a two-level structure into the registry? >>>>=20 >>>> For instance, you could easily imagine legal and useful = registrations of the form ::, etc. >>>>=20 >>>> Maybe change this to say: >>>> *Index value: values subordinate to urn:ietf:params:oauth are of = the from urn:ietf:params:oauth: with as the index value. = It is suggested that include both a "class" and an = "identifier-within-class" component, with the two components being = separated by a colon (":"); other compositions of the may also = be used. >>>>=20 >>>> -- Mike >>>>=20 >>>> -----Original Message----- >>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf Of internet-drafts@ietf.org >>>> Sent: Thursday, June 21, 2012 10:53 AM >>>> To: i-d-announce@ietf.org >>>> Cc: oauth@ietf.org >>>> Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-urn-sub-ns-03.txt >>>>=20 >>>>=20 >>>> 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 : An IETF URN Sub-Namespace for OAuth >>>> Author(s) : Brian Campbell >>>> Hannes Tschofenig >>>> Filename : draft-ietf-oauth-urn-sub-ns-03.txt >>>> Pages : 7 >>>> Date : 2012-06-21 >>>>=20 >>>> Abstract: >>>> This document establishes an IETF URN Sub-namespace for use with >>>> OAuth related specifications. >>>>=20 >>>>=20 >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-urn-sub-ns >>>>=20 >>>> There's also a htmlized version available at: >>>> http://tools.ietf.org/html/draft-ietf-oauth-urn-sub-ns-03 >>>>=20 >>>> A diff from previous version is available at: >>>> http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-urn-sub-ns-03 >>>>=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 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>=20 From hannes.tschofenig@gmx.net Sat Jun 23 07:58:10 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C6FD21F84D9 for ; Sat, 23 Jun 2012 07:58:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.564 X-Spam-Level: X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.035, 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 raLsxMfwvR0m for ; Sat, 23 Jun 2012 07:58:09 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 9B85021F8496 for ; Sat, 23 Jun 2012 07:58:08 -0700 (PDT) Received: (qmail invoked by alias); 23 Jun 2012 14:58:07 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.109]) [88.115.216.191] by mail.gmx.net (mp041) with SMTP; 23 Jun 2012 16:58:07 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19DW8lFqjJDoyYvU1zu7OQ3kmuJa2+cAHiXm0OQ5y Xspg5LRW0zbXTg Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <1555CD18-316D-4293-9D13-8BC241F6CB38@gmx.net> Date: Sat, 23 Jun 2012 17:58:04 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120621175317.32545.76545.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B1680429673943665637A0@TK5EX14MBXC283.redmond.corp.microsoft.com> <1555CD18-316D-4293-9D13-8BC241F6CB38@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: OAuth WG , Barry Leiba Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-urn-sub-ns-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: Sat, 23 Jun 2012 14:58:10 -0000 I read through the mails exchanges again and I believe I understand what = you want.=20 You like the idea of hierarchies in the identifiers (which is what the = URNs you are using in your documents actually do right now) but you = don't want to call them hierarchies (because it sounds complex).=20 Have a look what Section 3 of http://tools.ietf.org/html/rfc3553 says = about the colon character (":"). You conceptually want to exactly use = that concept but you refuse to call it in that way. So, you want to register all grant types under = urn:ietf:params:oauth:grant-type, such as=20 * urn:ietf:params:oauth:grant-type:saml2-bearer, and=20 urn:ietf:params:oauth:grant-type:jwt-bearer=20 instead of registering them all in one bucket, such as = urn:ietf:params:oauth:saml2-bearer and urn:ietf:params:oauth:jwt-bearer Ciao Hannes On Jun 23, 2012, at 3:39 PM, Hannes Tschofenig wrote: > Hi Mike,=20 >=20 > in a previous mail you wanted to even be more flexible by having not = only two levels but potentially three levels.=20 > Now, you say one registry is sufficient.=20 >=20 > That does not make sense.=20 >=20 > Ciao > Hannes >=20 > On Jun 21, 2012, at 11:29 PM, Mike Jones wrote: >=20 >> I agree that one registry is sufficient. The number of registrations = won't be huge and so having sub-registries seems like overkill. >>=20 >> -- Mike >>=20 >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf Of Brian Campbell >> Sent: Thursday, June 21, 2012 12:55 PM >> To: Barry Leiba >> Cc: OAuth WG >> Subject: Re: [OAUTH-WG] I-D Action: = draft-ietf-oauth-urn-sub-ns-03.txt >>=20 >> I honestly don't understand the push to have additional registries = under urn:ietf:params:oauth? >>=20 >> On Thu, Jun 21, 2012 at 1:28 PM, Barry Leiba = wrote: >>> This one's mostly there. As Mike and Hannes are discussing, the WG=20= >>> needs to sort out exactly what goes under "oauth" here. >>>=20 >>> Here's a suggestion: >>> Have Section 3 specify that what comes after "oauth" are one or more=20= >>> tokens, delimited by ":". >>> Have Section 3 create the registry for the first-level token, = "class". >>> In your example, that's "grant-type". >>> Have Section 3 specify that the definition of each "class" token=20 >>> specifies what comes after it -- how many tokens, and the = meaning(s). >>> Have Section 3 note that certain classes might create new=20 >>> sub-registries for what goes under them, if necessary. >>> Have Section 3 note that certain classes might have *no* further=20 >>> tokens under them. >>>=20 >>> I realize that there might not be any use cases envisioned right now=20= >>> for that last one, but it might be a bad idea to forbid it. >>>=20 >>> Section 5: >>>=20 >>> o Repository: [[not sure about this? this document or >>> http://www.iana.org/assignments/oauth]] >>>=20 >>> Yeh, I've never been sure about that either. I think what you want=20= >>> here is "[[The registry created in Section 3.]]". >>> See RFC 6134 for how I did this with the "sieve" namespace. >>>=20 >>> Barry >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 From hannes.tschofenig@gmx.net Sat Jun 23 08:17:18 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A01E221F84A2 for ; Sat, 23 Jun 2012 08:17:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 rzSJ6dwQ-eOE for ; Sat, 23 Jun 2012 08:17:18 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id A5DFB21F8499 for ; Sat, 23 Jun 2012 08:17:17 -0700 (PDT) Received: (qmail invoked by alias); 23 Jun 2012 15:17:16 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.109]) [88.115.216.191] by mail.gmx.net (mp010) with SMTP; 23 Jun 2012 17:17:16 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+bl6g2CyubVzOglY11a/gUJ0Wrhz0l94jnjTTBdx eTM8LUaAnaWSiQ From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 23 Jun 2012 18:17:15 +0300 Message-Id: <575E933A-6FEF-4821-8677-319FE72564D7@gmx.net> To: OAuth WG Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Subject: [OAUTH-WG] OAuth URN Registry Discussion Summary X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 15:17:18 -0000 As you have seen I have responded to various mails and I believe I = understand what people want.=20 Some of you obviously have plans to write extensions (in other = organizations outside the IETF, and as vendor-specific extensions). = That's fine.=20 You want something really lightweight (in terms of process) that does = not require you to come to the IETF to write an RFC and get the entire = working group excited about your hobby project. Clearly, this makes = sense to me.=20 So, the policy for adding new extensions has to be either 'Specification = Required' or 'Expert Review' with the difference being about the = information that goes into the registry. For the cases I have seen on = the list it will not make a huge difference. It may make a difference = for an organization where their final specifications are not publically = available. Yes, these organizations still exist today.... Then, there is the question about how the identifier that gets = registered should look like. You seem to like the idea of concept of a = structured identifier (since otherwise you wouldn't be using it in = various working group drafts already, including the example in = draft-ietf-oauth-urn-sub-ns itself!) but you don't like to call it = hierarchy because you fear that you will not be allowed to do whatever = you want. An unjustified concern. In that sense version -03 of the draft (see = http://tools.ietf.org/id/draft-ietf-oauth-urn-sub-ns-03.txt) pretty much = does already everything you want already do. As a policy it says "Expert = Review" and it has the structure in the ID that you guys are using in = your current drafts! There are two options to go forward.=20 The first one is to roll-back to version -03.=20 Another option is to take version -04 and add text that explains the = a bit further by saying that it may contain a structure and other = documents populating the registry will define the detailed structure of = the part.=20 In http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ we would = then add a section to the IANA consideration section saying that any new = extensions for client assertions needs to be registered under = urn:ietf:params:oauth:client-assertion-type: The same for urn:ietf:params:oauth:grant-type: in some other document = and so on.=20 Ciao Hannes From ve7jtb@ve7jtb.com Sat Jun 23 08:35:48 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9599A21F846B for ; Sat, 23 Jun 2012 08:35:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.739 X-Spam-Level: X-Spam-Status: No, score=-2.739 tagged_above=-999 required=5 tests=[AWL=-0.536, 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 5VoNFmLJvY+8 for ; Sat, 23 Jun 2012 08:35:48 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id B487021F846A for ; Sat, 23 Jun 2012 08:35:47 -0700 (PDT) Received: by yenq13 with SMTP id q13so2373548yen.31 for ; Sat, 23 Jun 2012 08:35:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to :x-gm-message-state; bh=xXyFimCUk4SZ2RBTBakuVxI3uVnTbaHvzEJY8wAnwaA=; b=Pt26iPrQRD2ugqI3mSm5x0M3uDFYj+b6Fkaxjd2ewwIoJa+fagcMMBxu2J00r29D4a XFk1B0TQayFg4Z0gep+J32KvFnMtQOYD+GUNUliY9GFV9Pwdh7o2Ykg/y0PTrqe3+hiJ DOHIoAztIccNNIatusqAw4ot3hmVudA/kp+9tYHpEjQ3WHtsqDCQlraQFMgpFMfzzbVx F0HW76tgLnGd6JFGi/PafCJnYJC31lClUIppNlaJmxOky3bgPzg51yKu2gSv2/6evAS3 fGEwxWLaTnKp49MEC6MKF2/rSEVZM6RUauibxIRDPEj4o+f8BS0RGdGSe0YLL4k2x2cf NSPA== Received: by 10.236.76.233 with SMTP id b69mr6873523yhe.52.1340465747116; Sat, 23 Jun 2012 08:35:47 -0700 (PDT) Received: from [192.168.1.41] (190-20-54-57.baf.movistar.cl. [190.20.54.57]) by mx.google.com with ESMTPS id p29sm121581588yhl.19.2012.06.23.08.35.43 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 23 Jun 2012 08:35:46 -0700 (PDT) References: <4FE1C16D.6010602@cs.tcd.ie> <4CD0B85C-C88D-4B52-81E4-5D53A25E60EF@cs.tcd.ie> <4E1F6AAD24975D4BA5B16804296739436656365A@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-4F7079D0-D7BA-4867-9080-DB3E08442017; protocol="application/pkcs7-signature" Message-Id: X-Mailer: iPad Mail (9B206) From: John Bradley Date: Sat, 23 Jun 2012 11:35:40 -0400 To: Hannes Tschofenig X-Gm-Message-State: ALoCoQm7kMlOV0sa+vRzg/HWiurEUu4ZUhr8ZMe6ImGIbaumprmqbOqASabnmGB0ZUAWvrzeEj0O Cc: Barry Leiba , "oauth@ietf.org" Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-urn-sub-ns-02 X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 15:35:48 -0000 --Apple-Mail-4F7079D0-D7BA-4867-9080-DB3E08442017 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I think Specification required is fine. It allows a OIDF or OASIS spec to b= e used as the basis for the registration withh appropriate expert review. John B. Sent from my iPad On 2012-06-23, at 8:31 AM, Hannes Tschofenig wro= te: > Hi Mike,=20 >=20 > the point is not that other groups, like OASIS, cannot use them. They can u= se the extensions.=20 >=20 > The question is more what process and documentation is needed to allow OAS= IS (and others) to define their own extensions.=20 >=20 > So far, OASIS had not been interested for any extension (at least from wha= t I know). The OpenID community, to which you also belong, had defined exten= sions (and brought some of them to the IETF) but had been quite careful them= selves to ensure proper review and documentation.=20 >=20 > So, if you look at the most important decision points then you have:=20 >=20 > 1) do you want a requirement for a specification, i.e., when someone defin= es an extension do you want it to be documented somewhere?=20 >=20 > 2) do you envision a review from experts (e.g., checking whether the stuff= makes any sense or conflicts with some other already available extensions)?= =20 >=20 > http://tools.ietf.org/html/rfc5226 provides a good discussion about this t= opic.=20 >=20 > If the answer to the above-listed questions is YES then you probably at le= ast want 'Specification Required' as a policy.=20 >=20 > Ciao > Hannes >=20 >=20 > On Jun 21, 2012, at 10:49 PM, Mike Jones wrote: >=20 >> I'd argue that the registration regime chosen should be flexible enough t= o permit OASIS or OpenID specs to use it. Otherwise, as someone else pointed= , people will work around the limitation by using unregistered values - whic= h helps no one. >>=20 >> -- Mike >>=20 >> From: Barry Leiba >> Sent: 6/21/2012 12:31 PM >> To: Stephen Farrell >> Cc: oauth@ietf.org >> Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-urn-sub-ns-02 >>=20 >>>> Stephen: >>>> Yeah, I'm not sure Standards Track is needed. >>>=20 >>> On this bit: I personally don't care, except that we don't have to do it= twice >>> because someone later on thinks the opposite and wins that argument, whi= ch >>> I'd rather not have at all (My one-track mind:-) Doing the 4 week last c= all means >>> once is enough. But I'm ok with whatever the WG want. >>=20 >> Well, it's not a 4-week LC, but a 2-week one. Anyway, yes, I see your >> point, and I've done that with other documents. Better to make it >> Standards Track for now, note in the shepherd writeup that >> Informational is probably OK, and let the IESG decide. >>=20 >> b >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-4F7079D0-D7BA-4867-9080-DB3E08442017 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIVvjCCBjQw 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/d1WwqI26kFo5k7686AmpUMIIHyTCCBbGgAwIBAgIBATANBgkqhkiG9w0B AQUFADB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlm aWNhdGlvbiBBdXRob3JpdHkwHhcNMDYwOTE3MTk0NjM2WhcNMzYwOTE3MTk0NjM2WjB9MQswCQYD VQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwg Q2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRo b3JpdHkwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDBiNsJvGxGfHiflXu1M5DycmLW wTYgIiRezul38kMKogZkpMyONvg45iPwbm2xPN1yo4UcodM9tDMr0y+v/uqwQVlntsQGfQqedIXW eUyAN3rfOQVSWff0G0ZDpNKFhdLDcfN1YjS6LIp/Ho/u7TTQEceWzVI9ujPW3U3eCztKS5/CJi/6 tRYccjV3yjxd5srhJosaNnZcAdt0FCX+7bWgiA/deMotHweXMAEtcnn6RtYTKqi5pquDSR3l8u/d 5AGOGAqPY1MWhWKpDhk6zLVmpsJrdAfkK+F2PrRt2PZE4XNiHzvEvqBTViVsUQn3qqvKv3b9bZvz ndu/PWa8DFaqr5hIlTpL36dYUNk4dalb6kMMAv+Z6+hsTXBbKWWc3apdzK8BMewM69KN6Oqce+Zu 9ydmDBpI125C4z/eIT574Q1w+2OqqGwaVLRcJXrJosmLFqa7LH4XXgVNWG4SHQHuEhANxjJ/GP/8 9PrNbpHoNkm+Gkhpi8KWTRoSsmkXwQqQ1vp5Iki/untp+HDH+no32NgN0nZPV/+Qt+OR0t3vwmC3 Zzrd/qqc8NSLf3Iizsafl7b4r4qgEKjZ+xjGtrVcUjyJthkqcwEKDwOzEmDyei+B26Nu/yYwl/WL 3YlXtq09s68rxbd2AvCl1iuahhQqcvbjM4xdCUsT37uMdBNSSwIDAQABo4ICUjCCAk4wDAYDVR0T BAUwAwEB/zALBgNVHQ8EBAMCAa4wHQYDVR0OBBYEFE4L7xqkQFulF2mHMMo0aEPQQa7yMGQGA1Ud HwRdMFswLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwuY3JsMCugKaAn hiVodHRwOi8vY3JsLnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwuY3JsMIIBXQYDVR0gBIIBVDCCAVAw ggFMBgsrBgEEAYG1NwEBATCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9y Zy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50ZXJt ZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQgQ29tbWVyY2lhbCAoU3RhcnRDb20p IEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBM aW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGlj eSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZI AYb4QgEBBAQDAgAHMDgGCWCGSAGG+EIBDQQrFilTdGFydENvbSBGcmVlIFNTTCBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTANBgkqhkiG9w0BAQUFAAOCAgEAFmyZ9GYMNPXQhV59CuzaEE44HF7fpiUF S5Eyweg78T3dRAlbB0mKKctmArexmvclmAk8jhvh3TaHK0u7aNM5Zj2gJsfyOZEdUauCe37Vzlrk 4gNXcGmXCPleWKYK34wGmkUWFjgKXlf2Ysd6AgXmvB618p70qSmD+LIU424oh0TDkBreOKk8rENN ZEXO3SipXPJzewT4F+irsfMuXGRuczE6Eri8sxHkfY+BUZo7jYn0TZNmezwD7dOaHZrzZVD1oNB1 ny+v8OqCQ5j4aZyJecRDjkZy42Q2Eq/3JR44iZB3fsNrarnDy0RLrHiQi+fHLB5LEUTINFInzQpd n4XBidUaePKVEFMy3YCEZnXZtWgo+2EuvoSoOMCZEoalHmdkrQYuL6lwhceWD3yJZfWOQ1QOq92l gDmUYMA0yZZwLKMS9R9Ie70cfmu3nZD0Ijuu+PwqyvqCUqDvr0tVk+vBtfAii6w0TiYiBKGHLHVK t+V9E9e4DGTANtLJL4YSjCMJwRuCO3NJo2pXh5Tl1njFmUNj403gdy3hZZlyaQQaRwnmDwFWJPsf vw55qVguucQJAX6Vum0ABj6y6koQOdjQK/W/7HW/lwLFCRsI3FU34oH7N4RDYiDK51ZLZer+bMEk kyShNOsF/5oirpt9P/FlUQqmMGqz9IgcgA38corog14xggNsMIIDaAIBATCBkzCBjDELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENl cnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRl cm1lZGlhdGUgQ2xpZW50IENBAgIeXDAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjA2MjMxNTM1NDRaMCMGCSqGSIb3DQEJBDEWBBSC8jra GwmWeIi8v3I1pr1FWl+/RTCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQG A1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBD bGllbnQgQ0ECAh5cMIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDANBgkqhkiG9w0BAQEFAASCAQA99TNpfANt+UrzjqmHtz+6gVA9bL99vcmQFE88 LY5DWkf2dbDRsJpQx4tE9jzmoEHSinDAhqv8XbcbFILSDRn+Tfg9L+tx/aWJ3ZcpVRL3hf4Lfo91 ym2rkF2i1V1z+prIROqst8TvhCdoW0g5W6nI+SWj3apZ83DH+44+fyyLlT+gPLXdawiITgeAqwxW r977xhdGzWjHf4AYpxXyggsHNTfdBkCd3Jd2Ymvd3kf3vOqTDMJn8XXGyxgeKfWOpTe1HZTR5td2 G06zsF7Y+Z2aW5kWQURyzidkElXK7pUWbZaUPRM6mz9nsXj5AZsOToaHxr5H7nmmrwDOE+t6SwEv AAAAAAAA --Apple-Mail-4F7079D0-D7BA-4867-9080-DB3E08442017-- From torsten@lodderstedt.net Sat Jun 23 09:52:42 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D3BA21F848A for ; Sat, 23 Jun 2012 09:52:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.928 X-Spam-Level: X-Spam-Status: No, score=-1.928 tagged_above=-999 required=5 tests=[AWL=0.321, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pRM6-RVojpkV for ; Sat, 23 Jun 2012 09:52:34 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.24]) by ietfa.amsl.com (Postfix) with ESMTP id 15A1721F844E for ; Sat, 23 Jun 2012 09:52:32 -0700 (PDT) Received: from [79.253.60.161] (helo=[192.168.71.36]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1SiTZW-0006yE-3V; Sat, 23 Jun 2012 18:52:30 +0200 Message-ID: <4FE5F446.2010905@lodderstedt.net> Date: Sat, 23 Jun 2012 18:52:22 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Lewis Adam-CAL022 References: <1339792496.52712.YahooMailNeo@web125501.mail.ne1.yahoo.com> <59E470B10C4630419ED717AC79FCF9A9108898EE@BL2PRD0410MB363.namprd04.prod.outlook.com> <4FE223E4.6060307@mitre.org> <4FE226BC.6010403@alcatel-lucent.com> <59E470B10C4630419ED717AC79FCF9A910889AB5@BL2PRD0410MB363.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A917052BC8@SN2PRD0410MB370.namprd04.prod.outlook.com> In-Reply-To: <59E470B10C4630419ED717AC79FCF9A917052BC8@SN2PRD0410MB370.namprd04.prod.outlook.com> Content-Type: multipart/alternative; boundary="------------090709050806090202080303" X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Report an authentication issue X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 16:52:42 -0000 This is a multi-part message in MIME format. --------------090709050806090202080303 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Adam, let me explain why I don't see a need for a new profile. As far as I understand your scenario, you want to give users from different security domains access to the same RS. I see two ways to handle this without any need to extend OAuth: 1) multiple AS (also performing authentication) You already mentioned this option. Every department runs its AS, which authenticates and authorizes access to the RS for the particular officer. As a pre-requisite, RS and ASs must use the same token design (self-contained vs. handle-based), token format (e.g. SAML or JWT) and the RS must _rely_ multiple ASs. This will be possible to implement with the drafts under consideration (namely JWT), but I consider this a substantial restrictions on the design of the RS! 2) single AS relying on multiple IDPs for authenticaton The alternative is to let a dedicated AS issue the tokens for the central RS. This AS uses the IDPs of the different security domain for the purpose of authenticating the officers (e.g. using SAML or OpenID). The difference is that the RS only trusts this single AS, which is easier to implement because it is a nearly private relationship. best regards, Torsten. Am 21.06.2012 18:01, schrieb Lewis Adam-CAL022: > > Hi Nat, > > I'm beginning to wonder what it would take to add a new profile of > sorts to either OAuth or Connect. > > In the beginning there was SOAP, and the preferred method to secure > SOAP API calls was WS-Trust. > > Now the world is moving toward RESTful APIs ... and the preferred > means to secure RESTful APIs is OAuth. > > Except that OAuth is clearly written with the idea that the protected > resources belong to the end user. > > My use cases -- and I imagine the use cases of many other enterprises > -- is that the Owner of the resources is the Enterprise. An employee > is trying to access a database or video resources. The enterprise RS > needs to be able to 1) identify the user, and 2) make authorization > decisions based on what roles that user has within the enterprise. So > in my scenario, when a police officer attempts to access a criminal > records database, the database needs to know who that officer is, and > then decide if they have privilege to access the database, and at what > level (e.g. CRUD). > > WS-Trust fits this model well. The user performs primary > authentication to the enterprise STS, which then grants the > application client a SAML assertion. When the user attempts to access > a records database, the SAML assertion is included in the SOAP > message. The records server authenticates the user based on the SAML > assertion and makes its authorization decisions. > > This is the world I'm trying to migrate from, and it really seems like > I'm sometimes trying to make a square peg fit in a round hole. I'm > looking for OAuth/Connect to do for REST what WS-TRUST did for SOAP. > I would like a native client talking to a RS to be able to ask for an > id_token, and then pass that id_token to the RS when making its > RESTful API calls, to enable the RS to authenticate the user. I think > that this would be really useful for a lot of people besides me. I > keep hearing that there is nothing "preventing" me from doing this ... > but it hardly seems within the spirit of what OAuth was meant to do. > The id_token was clearly meant to enable a user to authenticate to a > confidential client / web server ... but was not meant for a native > client to identity / authenticate the user to a RS. > > Would there be any interest in exploring this further? > > -adam > > *From:*Nat Sakimura [mailto:sakimura@gmail.com] > *Sent:* Wednesday, June 20, 2012 8:09 PM > *To:* Lewis Adam-CAL022 > *Cc:* igor.faynberg@alcatel-lucent.com; oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Report an authentication issue > > Yes, OAuth can be profiled to enable authentication. > > In fact, initial draft of OpenID Connect was just like you described. > > Essentially, we were using structured access_token. > > Later, we decided to separate the access token and id_token for > several reasons such as: > > 1. Better interop with existing OAuth implementations: by introducing > id_token, they do not need to touch the supposedly opaque (which > means AS-RS may be doing some proprietary thing inside it) access > token. > 2. Mixing up the audience (for id_token aka authn = client, and for > access_token aka authz = resource server) probably is expanding > the attack surface for security and privacy. > > Although we separated them out, a signed id_token includes the left > hash of access_token so access_token is also protected. > > Best, > > Nat > > On Thu, Jun 21, 2012 at 5:21 AM, Lewis Adam-CAL022 > > wrote: > > Hi Igor, > > As Justin just pointed out, consider the case where the video server > is hosted by the state (e.g. California) and is accessed by police > agencies in Los Angeles, San Francisco, and San Diego. The State of > California's video server is the RS. Each local police agency > (LA/SF/SD) hosts an AS. So when a police officer from LAPD launches > the video client app on the iPhone, the client makes an OAuth request > to the LAPD's AS, which authenticates the police officer using agency > level credentials. The access token issued to the video client app on > the iPhone is a JWT, signed by the agency AS, which might look > something like this: > > {"typ":"JWT","alg":"ES256"} > > {"iss":"https://as.lapd.california.gov", > "prn":"alice@lapd.california.gov ", > "aud":" https://video_server1@state.california.gov", > "iat":1300815780, > "exp":1300819380, > "acr":"password"} > > hq4zk+ZknjggCQgZm7ea8fI79gJEsRy3E8LHDpYXWQIgZpkJN9CMLG8ENR4Nrw+n7iyzixBvKXX8P53BTCT4VghPBWhFYSt9tHWu/AtJfOTh6qaAsNdeCyG86jmtp3TDMwuL/cBUj2OtBZOQMFn7jQ9YB7klIz3RqVL+wNmeWI4= > > The JWT might be optionally encrypted using JWE. > > I think what is becoming clear (and this is what I'm trying to vet) is > that while there is nothing in OAuth that specifies authentication, it > **can** be used for Authentication, if done in the way that I > describe. If I'm wrong about this, I really need to know. I've > vetted this idea of mine with quite of few people now -- both within > context of the list and off-line -- and I think I'm okay. If you see > any holes in what I describe, please point them out as I would prefer > to uncover them now rather than after implementation or deployment! > > Essentially I'm using OAuth as a RESTful version of WS-Trust, where my > client can exchange primary credentials for a token (JWT) and present > that token to a server as secondary authentication. It's just that > it's RESTful instead of SOAP :-) > > As Justin as pointed out ... I've basically made the access-token look > like the id_token of Connect. I was actually hoping to lay a path to > Connect, and use the id_token ... until it was also pointed out that > the id_token is really meant for the consumption of the client, not > the RS :-( > > *From:*oauth-bounces@ietf.org > [mailto:oauth-bounces@ietf.org ] *On > Behalf Of *Igor Faynberg > *Sent:* Wednesday, June 20, 2012 2:39 PM > *To:* oauth@ietf.org > > > *Subject:* Re: [OAUTH-WG] Report an authentication issue > > But this use case does need OAuth, period: > > > > The video server is under the control of a police agency, and police > officers must logon to the video server in order to access video content. > > There is no delegation here, and there is no need to use third party > for authentication. > > Igor > > On 6/20/2012 3:26 PM, Justin Richer wrote: > > In case it wasn't clear, I want to restate the original problem as > best as I understand it in a way that hopefully clears it up: > > App A and app B are both valid registered OAuth clients to an OAuth > protected service. > > The problem starts when app A gets handed a token that was issued for > app B and uses it to call an identity API on the OAuth service. Since > app B can get tokens just fine, they're bearer tokens, this is a > fairly basic api call, this function works just fine and returns the > user info. This makes sense, since anyone who holds A's tokens can do > whatever A can do on behalf of that user. The issues start when app B > then decides that since they can make a call to the identity API with > a token then the user *must* be present. In other words, app B is > confusing authorization to call an API with authentication of the session. > > OpenID Connect fixes this missed assumption by binding the ID Token to > the session and sending it along side the access token, but as you > pointed out, it's meant for consumption at the client, not the > resource server, in general. That doesn't mean you can't send it to a > resource server for your own purposes, of course. That's actually how > the session management endpoint works in Connect. > > This isn't the only way to handle this problem -- if you put some > structure in your tokens, such as with JWT or SAML, then app A can > tell that this isn't a token issued to app A, but to app B, so it can > call shenanigans and reject it then and there. > > -- Justin > > On 06/20/2012 10:03 AM, Lewis Adam-CAL022 wrote: > > I am entirely confused. > > I understand what everybody is saying for confidential clients, no > problem here. > > I fall apart when thinking of iPhone apps. Consider the scenario > where I deploy a video server, and write an iPhone app to talk to the > video server. The video server is under the control of a police > agency, and police officers must logon to the video server in order to > access video content. So the police office launches their iPhone > video client app. > > If I wanted to solve authentication using "traditional" client-server > authentication, the user enters their username / password into the > client, and the client sends the username / password off to the > server, which authenticates it, or possibly uses HTTP digest. > > If I wanted to use OpenID, the client would attempt to reach the video > server (RP), the server would redirect the client to the OP, OP > authenticates user, and OP redirects client back to the server/RP with > an assertion that primary authentication was successful. > > If I wanted to use OAuth, the client would send an authorization > request to the server's AS, which would authenticate the user of the > client, and ultimately result in the client possessing an > access-token. My thinking is that this access token (let's assume > it's a JWT) would contain the user's identity, a statement of what > type of primary authentication was used (auth context), an expiration, > and an audience claim. This sounds a lot like authentication to me, > and it's where I get confused. Is it just because OAuth does not > explicitly define this? Is there a threat in using OAuth as I describe? > > If I wanted to use Connect, well I'm not even sure how the id_token as > defined by Connect helps this use case. The id_token seems to make > sense when the client is a confidential web server, but it's not clear > what an iPhone app would do with the id_token ... it's the server in > the backend that needs to authenticate the user, the iPhone app is > just an interface to talk to the server. And it seems as I learn more > about connect that the id_token is not meant to be sent from the > iPhone app to the server, just the access token. So it's really not > clear how Connect helps solve authentication for an iPhone client app > talking to a video server. If I'm sending access-tokens, it's just > OAuth again. > > What am I still missing? > > adam > > *From:*oauth-bounces@ietf.org > [mailto:oauth-bounces@ietf.org] *On Behalf Of *Kristofor Selden > *Sent:* Saturday, June 16, 2012 11:33 AM > *To:* nov matake; oauth > *Cc:* Yuchen Zhou; Luke Melia; Shuo Chen (MSR) > *Subject:* Re: [OAUTH-WG] Report an authentication issue > > Nov demonstrated the problem to us at Yapp and we used solution 4 > (because the solution is server side and our app was in the app store). > > FB Connect is authentication /and/ authorization, where OAuth 2 is > concerned only with authorization -- I'm not sure that app developers > appreciate this subtlety. > > With OAuth 2 you authorize an app to use a protected resource. With > FB Connect, you do that, but /also/ authenticate with the app you are > authorizing. > > So the access_token protects not just the FB resources but the auth > end point of the authorized app (very common with apps that use the > iOS SDK). So now the app needs a way to verify that it was the app > that was authorized to FB. > > Solution 4 explanation: on FB you can register a iPhone app and a > server app with the same client_id and get a client_secret for use on > the server. The server side API posts the access_token, client_id, > and client_secret to https://graph.facebook.com/app > to verify > that the bearer token actually belongs to the app that is being > authenticated before assuming they are authorized to the app's > protected resources. > > Kris > > On Jun 15, 2012, at 8:22 PM, nov matake wrote: > > > > There are 4 ways to fix this issue. > > 1. Use response_type=token%20code (It's not in OAuth 2.0 Core, but > seems best way for interoperability) > > 2. Use singed_request (or some signed token like JWT) > > 3. Use grant_type=fb_exchange_token (Facebook custom way) > > 4. Access to https://graph.facebook.com/app?access_token=YOUR_TOKEN > (Facebook custom way, moreover undocumented API) > > Two iPhone app developers I reported this issue fixed it by using (4). > > I also tried to use (1) for my own iPhone app implementation, but > unfortunately it doesn't work when using authorization codes obtained > via FB iOS SDK. > > So I'm using (3) in my case. > > nov > > On 2012/06/16, at 9:16, Nat Sakimura wrote: > > > > As to how the fix was done, Nov can provide more detail, but ... > > 1. Properly verify the signature/HMAC of the "signed_request". This > will essentially audience restricts the token. > > 2. There is an undocumented API for Facebook which returns to whom the > token was issued. This also audience restricts the token. > > The service that fixed took these measures. Note that none of the > above is defined in OAuth. > > The same facility was called "id_token" and "check ID endpoint" for > OpenID Connect. > > The scale of the impact is large, too large to disclose the actual > names in the public list, though, eventually, we would publish them in > a paper. > > Nat > > On Sat, Jun 16, 2012 at 5:34 AM, Francisco Corella > > wrote: > > Hi Nat and Rui, > > Rui, you say that the vulnerability that you found was due to a > "common misunderstanding among developers", but the attack you > describe can be carried out against any app that uses the OAuth > "implicit grant flow", which Facebook calls "client-side > authentication". No misunderstanding seems necessary. What > misunderstanding are you referring to? I followed the link in your > message to the Sophos post, and from there the link to the article in > The Register. The article in The Register says that Facebook had > "fixed the vulnerability promptly". How did they fix it? The > instructions that Facebook provides for implementing "Client-side > authentication without the JS SDK" at > https://developers.facebook.com/docs/authentication/client-side/#no-jssdk > still allows the attack. > > Nat, I agree that the blog post by John Bradley that you link to > refers to the same vulnerability reported by Rui. You say that some > apps have issued a patch to fix it. Could you explain what the fix > was? > > Francisco > > ------------------------------------------------------------------------ > > *From:*Nat Sakimura > > *To:* rui wang > > *Cc:* matake nov >; Yuchen > Zhou >; > oauth >; Shuo Chen (MSR) > > > *Sent:* Thursday, June 14, 2012 1:50 PM > *Subject:* Re: [OAUTH-WG] Report an authentication issue > > This is a fairly well known (hopefully by now) issue. We, at the > OpenID Foundation, call it "access_token phishing" attack these > days. See: > http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.html > > Nov Matake has actually built the code on iPhone to verify the > problem, and has notified bunch of parties back in February > including Facebook and Apple. We have the code that actually runs > on a phone, and we have successfully logged in to bunch of apps, > including very well known ones. They were all informed of the > issue. Some immediately issued a patch to fix it while others have > not. > > The problem is that even if these apps gets fixed, the problem > does not go away. As long as the attacker has the vulnerable > version of the app, he still can impersonate the victim. To stop > it, the server side has to completely disable the older version, > which means the service has to cut off many users pausing business > problems. > > Nat > > On Fri, Jun 15, 2012 at 2:18 AM, rui wang > wrote: > > Dear Facebook Security Team and OAuth Standard group, > > We are a research team in Microsoft Research. In January, 2011, we > reported a vulnerability in Facebook Connect which allowed > everyone to sign into Facebook-secured relying parties without > password. It was promptly fixed after reporting. > (http://nakedsecurity.sophos.com/2011/02/02/facebook-flaw-websites-steal-personal-data/) > > Recently, we found a common misunderstanding among developers of > mobile/metro apps when using OAuth (including Facebook's OAuth) > for authentication. The vulnerability resulted from this > misunderstanding also allows an attacker to log into a victim > user's account without password. > > Let's take Soluto's metro app as an example to describe the > problem. The app supports Facebook Login. As an attacker, we can > write a regular Facebook app. Once the victim user allows our app > to access her Facebook data, we receive an access_token from the > traffic. Then, on our own machine (i.e., the "attacker" machine), > we run the metro app of Soluto, and use a HTTP proxy to insert the > victim's access_token into the traffic of Facebook login. Through > this way, we are able to log into the victim's Soluto account from > our machine. Other than Soluto, we also have confirmed the same > issue on another Windows 8 metro-app Givit. > > The Facebook SDK for Android apps > (https://developers.facebook.com/docs/mobile/android/build/#sdk) > seems to have the possibility to mislead developers too. At least, > the issue that we found is not clearly mentioned. In the SDK, we > ran the sample code called "Hackbook" using Android Emulator > (imagine it is an attacker device). Note that we have already > received the access token of the victim user from our regular > Facebook app. We then inject the token to the traffic of Hackbook. > Through this way, Hackbook app on our own machine recognizes us as > the victim. Note that this is not a convincing security exploit > yet, because this sample code does not include the server-side > code. However, given that we have seen real server-side code > having this problem, such as Soluto, Givit and others, we do > believe that the sample code can mislead mobile/metro developers. > We also suspect that this may be a general issue of many OAuth > implementations on mobile platforms, so we send this message to > OAuth Standard group as well. > > We have contacted the vendors of the two vulnerable metro-apps, > Soluto and Gavit. > > Please kindly give us an ack when you receive this message. If you > want to know more details, please let us know. > > Best Regards, > Yuchen Zhou, Rui Wang, and Shuo Chen > > > _______________________________________________ > 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 > > > > -- > 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 > > > > _______________________________________________ > OAuth mailing 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 --------------090709050806090202080303 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Adam,

let me explain why I don't see a need for a new profile.

As far as I understand your scenario, you want to give users from different security domains access to the same RS.

I see two ways to handle this without any need to extend OAuth:

1) multiple AS (also performing authentication)

You already mentioned this option. Every department runs its AS, which authenticates and authorizes access to the RS for the particular officer. As a pre-requisite, RS and ASs must use the same token design (self-contained vs. handle-based), token format (e.g. SAML or JWT) and the RS must _rely_ multiple ASs. This will be possible to implement with the drafts under consideration (namely JWT), but I consider this a substantial restrictions on the design of the RS!

2) single AS relying on multiple IDPs for authenticaton

The alternative is to let a dedicated AS issue the tokens for the central RS. This AS uses the IDPs of the different security domain for the purpose of authenticating the officers (e.g. using SAML or OpenID). The difference is that the RS only trusts this single AS, which is easier to implement because it is a nearly private relationship.

best regards,
Torsten.

Am 21.06.2012 18:01, schrieb Lewis Adam-CAL022:

Hi Nat,

 

I’m beginning to wonder what it would take to add a new profile of sorts to either OAuth or Connect. 

 

In the beginning there was SOAP, and the preferred method to secure SOAP API calls was WS-Trust.

 

Now the world is moving toward RESTful APIs … and the preferred means to secure RESTful APIs is OAuth.

 

Except that OAuth is clearly written with the idea that the protected resources belong to the end user.

 

My use cases – and I imagine the use cases of many other enterprises – is that the Owner of the resources is the Enterprise.  An employee is trying to access a database or video resources.  The enterprise RS needs to be able to 1) identify the user, and 2) make authorization decisions based on what roles that user has within the enterprise.  So in my scenario, when a police officer attempts to access a criminal records database, the database needs to know who that officer is, and then decide if they have privilege to access the database, and at what level (e.g. CRUD). 

 

WS-Trust fits this model well.  The user performs primary authentication to the enterprise STS, which then grants the application client a SAML assertion.  When the user attempts to access a records database, the SAML assertion is included in the SOAP message.  The records server authenticates the user based on the SAML assertion and makes its authorization decisions.

 

This is the world I’m trying to migrate from, and it really seems like I’m sometimes trying to make a square peg fit in a round hole.  I’m looking for OAuth/Connect to do for REST what WS-TRUST did for SOAP.  I would like a native client talking to a RS to be able to ask for an id_token, and then pass that id_token to the RS when making its RESTful API calls, to enable the RS to authenticate the user.  I think that this would be really useful for a lot of people besides me.  I keep hearing that there is nothing “preventing” me from doing this … but it hardly seems within the spirit of what OAuth was meant to do.  The id_token was clearly meant to enable a user to authenticate to a confidential client  / web server … but was not meant for a native client to identity / authenticate the user to a RS. 

 

 

Would there be any interest in exploring this further?

-adam

 

 

From: Nat Sakimura [mailto:sakimura@gmail.com]
Sent: Wednesday, June 20, 2012 8:09 PM
To: Lewis Adam-CAL022
Cc: igor.faynberg@alcatel-lucent.com; oauth@ietf.org
Subject: Re: [OAUTH-WG] Report an authentication issue

 

Yes, OAuth can be profiled to enable authentication. 

In fact, initial draft of OpenID Connect was just like you described. 

Essentially, we were using structured access_token. 

Later, we decided to separate the access token and id_token for several reasons such as: 

 

  1. Better interop with existing OAuth implementations: by introducing id_token, they do not need to touch the supposedly opaque (which means AS-RS may be doing some proprietary thing inside it) access token. 
  2. Mixing up the audience (for id_token aka authn = client, and for access_token aka authz = resource server) probably is expanding the attack surface for security and privacy. 

Although we separated them out, a signed id_token includes the left hash of access_token so access_token is also protected. 

 

Best, 

 

Nat

 

On Thu, Jun 21, 2012 at 5:21 AM, Lewis Adam-CAL022 <Adam.Lewis@motorolasolutions.com> wrote:

Hi Igor,

 

As Justin just pointed out, consider the case where the video server is hosted by the state (e.g. California) and is accessed by police agencies in Los Angeles, San Francisco, and San Diego.  The State of California’s video server is the RS.  Each local police agency (LA/SF/SD) hosts an AS.  So when a police officer from LAPD launches the video client app on the iPhone, the client makes an OAuth request to the LAPD’s AS, which authenticates the police officer using agency level credentials.  The access token issued to the video client app on the iPhone is a JWT, signed by the agency AS, which might look something like this:

 

{“typ”:”JWT”,"alg":"ES256"}

{"iss":"https://as.lapd.california.gov",
  "prn":"alice@lapd.california.gov",
  "aud":" https://video_server1@state.california.gov",
  "iat":1300815780,
  "exp":1300819380,
  "acr":”password”}

hq4zk+ZknjggCQgZm7ea8fI79gJEsRy3E8LHDpYXWQIgZpkJN9CMLG8ENR4Nrw+n7iyzixBvKXX8P53BTCT4VghPBWhFYSt9tHWu/AtJfOTh6qaAsNdeCyG86jmtp3TDMwuL/cBUj2OtBZOQMFn7jQ9YB7klIz3RqVL+wNmeWI4=

 

The JWT might be optionally encrypted using JWE. 

 

I think what is becoming clear (and this is what I’m trying to vet) is that while there is nothing in OAuth that specifies authentication, it *can* be used for Authentication, if done in the way that I describe.  If I’m wrong about this, I really need to know.  I’ve vetted this idea of mine with quite of few people now – both within context of the list and off-line – and I think I’m okay. If you see any holes in what I describe, please point them out as I would prefer to uncover them now rather than after implementation or deployment!

 

Essentially I’m using OAuth as a RESTful version of WS-Trust, where my client can exchange primary credentials for a token (JWT) and present that token to a server as secondary authentication.  It’s just that it’s RESTful instead of SOAP :-)

 

As Justin as pointed out … I’ve basically made the access-token look like the id_token of Connect.  I was actually hoping to lay a path to Connect, and use the id_token … until it was also pointed out that the id_token is really meant for the consumption of the client, not the RS :-(

 

 

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Igor Faynberg
Sent: Wednesday, June 20, 2012 2:39 PM
To: oauth@ietf.org


Subject: Re: [OAUTH-WG] Report an authentication issue

 

But this use case  does need OAuth, period:



The video server is under the control of a police agency, and police officers must logon to the video server in order to access video content.

There is no delegation here, and there is no need to use third party for authentication. 

Igor

On 6/20/2012 3:26 PM, Justin Richer wrote:

In case it wasn't clear, I want to restate the original problem as best as I understand it in a way that hopefully clears it up:

App A and app B are both valid registered OAuth clients to an OAuth protected service.

The problem starts when app A gets handed a token that was issued for app B and uses it to call an identity API on the OAuth service. Since app B can get tokens just fine, they're bearer tokens, this is a fairly basic api call, this function works just fine and returns the user info. This makes sense, since anyone who holds A's tokens can do whatever A can do on behalf of that user. The issues start when app B then decides that since they can make a call to the identity API with a token then the user *must* be present. In other words, app B is confusing authorization to call an API with authentication of the session.

OpenID Connect fixes this missed assumption by binding the ID Token to the session and sending it along side the access token, but as you pointed out, it's meant for consumption at the client, not the resource server, in general. That doesn't mean you can't send it to a resource server for your own purposes, of course. That's actually how the session management endpoint works in Connect.

This isn't the only way to handle this problem -- if you put some structure in your tokens, such as with JWT or SAML, then app A can tell that this isn't a token issued to app A, but to app B, so it can call shenanigans and reject it then and there.

 -- Justin

On 06/20/2012 10:03 AM, Lewis Adam-CAL022 wrote:

I am entirely confused.

 

I understand what everybody is saying for confidential clients, no problem here.

 

I fall apart when thinking of iPhone apps.  Consider the scenario where I deploy a video server, and write an iPhone app to talk to the video server.  The video server is under the control of a police agency, and police officers must logon to the video server in order to access video content.  So the police office launches their iPhone video client app.

 

If I wanted to solve authentication using “traditional” client-server authentication, the user enters their username / password into the client, and the client sends the username / password off to the server, which authenticates it, or possibly uses HTTP digest. 

If I wanted to use OpenID, the client would attempt to reach the video server (RP), the server would redirect the client to the OP, OP authenticates user, and OP redirects client back to the server/RP with an assertion that primary authentication was successful. 

If I wanted to use OAuth, the client would send an authorization request to the server’s AS, which would authenticate the user of the client, and ultimately result in the client possessing an access-token.  My thinking is that this access token (let’s assume it’s a JWT) would contain the user’s identity, a statement of what type of primary authentication was used (auth context), an expiration, and an audience claim.  This sounds a lot like authentication to me, and it’s where I get confused.  Is it just because OAuth does not explicitly define this?  Is there a threat in using OAuth as I describe? 

If I wanted to use Connect, well I’m not even sure how the id_token as defined by Connect helps this use case.  The id_token seems to make sense when the client is a confidential web server, but it’s not clear what an iPhone app would do with the id_token … it’s the server in the backend that needs to authenticate the user, the iPhone app is just an interface to talk to the server.  And it seems as I learn more about connect that the id_token is not meant to be sent from the iPhone app to the server, just the access token.  So it’s really not clear how Connect helps solve authentication for an iPhone client app talking to a video server.  If I’m sending access-tokens, it’s just OAuth again.

 

What am I still missing?

adam

 

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Kristofor Selden
Sent: Saturday, June 16, 2012 11:33 AM
To: nov matake; oauth
Cc: Yuchen Zhou; Luke Melia; Shuo Chen (MSR)
Subject: Re: [OAUTH-WG] Report an authentication issue

 

Nov demonstrated the problem to us at Yapp and we used solution 4 (because the solution is server side and our app was in the app store).

 

FB Connect is authentication and authorization, where OAuth 2 is concerned only with authorization – I'm not sure that app developers appreciate this subtlety.

 

With OAuth 2 you authorize an app to use a protected resource.  With FB Connect, you do that, but also authenticate with the app you are authorizing.

 

So the access_token protects not just the FB resources but the auth end point of the authorized app (very common with apps that use the iOS SDK).  So now the app needs a way to verify that it was the app that was authorized to FB.

 

Solution 4 explanation: on FB you can register a iPhone app and a server app with the same client_id and get a client_secret for use on the server.  The server side API posts the access_token, client_id, and client_secret to https://graph.facebook.com/app to verify that the bearer token actually belongs to the app that is being authenticated before assuming they are authorized to the app's protected resources.

 

Kris

 

On Jun 15, 2012, at 8:22 PM, nov matake wrote:



There are 4 ways to fix this issue.

 

1. Use response_type=token%20code (It's not in OAuth 2.0 Core, but seems best way for interoperability)

2. Use singed_request (or some signed token like JWT)

3. Use grant_type=fb_exchange_token (Facebook custom way)

4. Access to https://graph.facebook.com/app?access_token=YOUR_TOKEN (Facebook custom way, moreover undocumented API)

 

Two iPhone app developers I reported this issue fixed it by using (4).

 

I also tried to use (1) for my own iPhone app implementation, but unfortunately it doesn't work when using authorization codes obtained via FB iOS SDK.

So I'm using (3) in my case.

 

nov

 

On 2012/06/16, at 9:16, Nat Sakimura wrote:



As to how the fix was done, Nov can provide more detail, but ... 

 

1. Properly verify the signature/HMAC of the "signed_request". This will essentially audience restricts the token. 

2. There is an undocumented API for Facebook which returns to whom the token was issued. This also audience restricts the token. 

 

The service that fixed took these measures. Note that none of the above is defined in OAuth. 

The same facility was called "id_token" and "check ID endpoint" for OpenID Connect. 

 

The scale of the impact is large, too large to disclose the actual names in the public list, though, eventually, we would publish them in a paper. 

 

Nat

On Sat, Jun 16, 2012 at 5:34 AM, Francisco Corella <fcorella@pomcor.com> wrote:

Hi Nat and Rui,

Rui, you say that the vulnerability that you found was due to a
"common misunderstanding among developers", but the attack you
describe can be carried out against any app that uses the OAuth
"implicit grant flow", which Facebook calls "client-side
authentication".  No misunderstanding seems necessary.  What
misunderstanding are you referring to?  I followed the link in your
message to the Sophos post, and from there the link to the article in
The Register.  The article in The Register says that Facebook had
"fixed the vulnerability promptly".  How did they fix it?  The
instructions that Facebook provides for implementing "Client-side
authentication without the JS SDK" at
https://developers.facebook.com/docs/authentication/client-side/#no-jssdk
still allows the attack.

Nat, I agree that the blog post by John Bradley that you link to
refers to the same vulnerability reported by Rui.  You say that some
apps have issued a patch to fix it.  Could you explain what the fix
was?

Francisco

 

From: Nat Sakimura <sakimura@gmail.com>
To: rui wang <ruiwangwarm@gmail.com>
Cc: matake nov <nov@matake.jp>; Yuchen Zhou <t-yuzhou@microsoft.com>; oauth <oauth@ietf.org>; Shuo Chen (MSR) <shuochen@microsoft.com>
Sent: Thursday, June 14, 2012 1:50 PM
Subject: Re: [OAUTH-WG] Report an authentication issue

 

This is a fairly well known (hopefully by now) issue. We, at the OpenID Foundation, call it "access_token phishing" attack these days. See: http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.html

 

Nov Matake has actually built the code on iPhone to verify the problem, and has notified bunch of parties back in February including Facebook and Apple. We have the code that actually runs on a phone, and we have successfully logged in to bunch of apps, including very well known ones. They were all informed of the issue. Some immediately issued a patch to fix it while others have not.  

 

The problem is that even if these apps gets fixed, the problem does not go away. As long as the attacker has the vulnerable version of the app, he still can impersonate the victim. To stop it, the server side has to completely disable the older version, which means the service has to cut off many users pausing business problems. 

 

Nat

On Fri, Jun 15, 2012 at 2:18 AM, rui wang <ruiwangwarm@gmail.com> wrote:

Dear Facebook Security Team and OAuth Standard group,

We are a research team in Microsoft Research. In January, 2011, we reported a vulnerability in Facebook Connect which allowed everyone to sign into Facebook-secured relying parties without password. It was promptly fixed after reporting. (http://nakedsecurity.sophos.com/2011/02/02/facebook-flaw-websites-steal-personal-data/)

Recently, we found a common misunderstanding among developers of mobile/metro apps when using OAuth (including Facebook’s OAuth) for authentication. The vulnerability resulted from this misunderstanding also allows an attacker to log into a victim user's account without password.

Let's take Soluto's metro app as an example to describe the problem. The app supports Facebook Login. As an attacker, we can write a regular Facebook app. Once the victim user allows our app to access her Facebook data, we receive an access_token from the traffic. Then, on our own machine (i.e., the "attacker" machine), we run the metro app of Soluto, and use a HTTP proxy to insert the victim's access_token into the traffic of Facebook login. Through this way, we are able to log into the victim's Soluto account from our machine. Other than Soluto, we also have confirmed the same issue on another Windows 8 metro-app Givit.

The Facebook SDK for Android apps (https://developers.facebook.com/docs/mobile/android/build/#sdk) seems to have the possibility to mislead developers too. At least, the issue that we found is not clearly mentioned. In the SDK, we ran the sample code called "Hackbook" using Android Emulator (imagine it is an attacker device). Note that we have already received the access token of the victim user from our regular Facebook app. We then inject the token to the traffic of Hackbook. Through this way, Hackbook app on our own machine recognizes us as the victim. Note that this is not a convincing security exploit yet, because this sample code does not include the server-side code. However, given that we have seen real server-side code having this problem, such as Soluto, Givit and others, we do believe that the sample code can mislead mobile/metro developers. We also suspect that this may be a general issue of many OAuth implementations on mobile platforms, so we send this message to OAuth Standard group as well.

We have contacted the vendors of the two vulnerable metro-apps, Soluto and Gavit.

Please kindly give us an ack when you receive this message. If you want to know more details, please let us know.

Best Regards,
Yuchen Zhou, Rui Wang, and Shuo Chen


_______________________________________________
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



 

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

 

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


--------------090709050806090202080303-- From torsten@lodderstedt.net Sat Jun 23 11:24:25 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9533E21F84E6 for ; Sat, 23 Jun 2012 11:24:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.788 X-Spam-Level: X-Spam-Status: No, score=-1.788 tagged_above=-999 required=5 tests=[AWL=-0.140, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_65=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 B6Qe4QTb1mhi for ; Sat, 23 Jun 2012 11:24:20 -0700 (PDT) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.37]) by ietfa.amsl.com (Postfix) with ESMTP id ED98721F8448 for ; Sat, 23 Jun 2012 11:24:18 -0700 (PDT) Received: from [79.253.60.161] (helo=[192.168.71.36]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1SiV0J-0005Dc-4n; Sat, 23 Jun 2012 20:24:15 +0200 Message-ID: <4FE609C6.9020902@lodderstedt.net> Date: Sat, 23 Jun 2012 20:24:06 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: John Bradley References: <854774286EF8A240BACC342973A86EAC016693D6@BL2PRD0310MB387.namprd03.prod.outlook.com> <484A13D0-7C9A-42CC-BB94-3657741834DE@ve7jtb.com> <82D95BA2-1697-4441-BBB3-B2AE480DC39E@gmail.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040008050904000605080802" X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Cc: rui wang , Yuchen Zhou , "Shuo Chen \(MSR\)" , Derek Atkins , "oauth@ietf.org" Subject: Re: [OAUTH-WG] proposal of a paragraph to add to the security considerations section X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 18:24:25 -0000 This is a multi-part message in MIME format. --------------040008050904000605080802 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi John, I fully agree with your assessment. This attack utilizes the fact that some clients rely on the result of a resource server request to login an user. It is not an attack on the OAuth protocol. And even if a similar attack on authorization codes will happen to fail for confidential clients does not mean OAuth is supposed to solve this problem. We nevertheless should mention it in the security considerations section. To make things simple, I suggest to describe and ban this anti-pattern _in general_ in the security consideration section (similar to Shuo's initial proposal but more generalized). Additionally, the text should recommend to use an appropriate technique for id providing such as OpenID or SAML. We also could add a detailed analaysis to the security document. best regards, Torsten. Am 21.06.2012 15:47, schrieb John Bradley: > Hi Hannes, > > MAC tokens protect resources against token leakage to third parties. > That is useful but a different threat. > > The easiest way to get a access token for someone is to have them log > into your site. > > If you can do that the token type makes no difference unless we move > to a asymmetric holder of key token (different discussion). > > The bad client gets the access MAC token and token secret and can re > use it just as it would a bearer token. > > The origin of the post was a contention by someone at Facebook that > profiling OAuth 2.0 on its own is sufficient to produce an > Authentication protocol. > > I was trying to point out that OAuth 2 without any extensions, only > profiling is difficult to impossible to use for authentication as the > attack surface and security considerations are different. > > As it turned out Facebook had extended OAuth 2 with signed requests > and token introspection techniques to address these issues for > themselves. > > The problem as it turned out was that individual apps and app > frameworks like the iOS one made some bad mistakes, by not using the > perhaps under documented extensions. > > The problem is not unique to Facebook in any way they are just a > convenient example. > > Oauth 2 is not surprisingly mostly about protecting the resource. > > Authentication is about protecting the client. > > Audience restriction from openID 2, SAML, WS* etc prevents replay of > tokens issued to one RP/SP at another. > That is sort of authentication protocol threat number 1. > > OAuth has no way to do that with access tokens. > > It can however do it with "code" if the client is confidential. > > So my recommendation is that without extensions to OAuth like > structured tokens (signed_request, id_token) or token introspection > endpoints like > Facebook ( https://graph.facebook.com/app?access_token=[The Access > Token]), there is no safe way to use an implicit flow for authentication. > A code flow where a native app exchanges code for the access token and > then passes the access token back to it's server is also vulnerable > (lots of this in circulation I understand) > > The only safe flow (without extensions) is the code flow where the > client is confidential and the code is directly exchanged for the > access token. > This also requires the definition of a identity API that is protected > by the access token, and out of scope for OAuth. > > So at the end of the day the rational conclusion is that OAuth 2 is a > authorization protocol. > It may be used by Authentication protocols, but it is up to other > specs to define the security considerations for that. > > That however doesn't remove the need to mention the token substitution > attack that non confidential clients are subject to, do to there being > no other mechanism for the client to know who the token was issued to. > > John B. > > > > > > On 2012-06-21, at 5:27 AM, Hannes Tschofenig wrote: > >> Hi John, >> >> I read through your blog post. I am not sure whether I can entirely >> agree with your separation between authentication and authorization. >> I believe the core issue here is that >> >> * anyone who has the token will get access to whatever the token >> entitles him or her to do (unless there are restrictions in the token) >> >> * some attributes are different than others. With authentication you >> typically associate that the process took place recently (i.e., it is >> fresh) while other attributes do not require the user (as resource >> owner) to actively participate in the exchange and the same level of >> freshness is not implied. For authentication in a three party >> protocol to be useful the three parties have to participate (see >> http://tools.ietf.org/id/draft-tschofenig-oauth-signature-thoughts-00.txt). >> >> >> I understand that one wants to avoid having tokens passed around from >> one application to the other one, as it is happening here. >> >> I remember having some of these discussions with Eran a long time >> ago. He anticipated that implementers will not put any constraints in >> the tokens and hence they will be misused. This serves as an argument >> for him to propose the MAC token specification. >> >> I proposed text for the security consideration section of the bearer >> document a while ago and it even talks about audience restriction as >> a recommendation. >> >> There are two problems with the audience restriction: >> >> 1) There is no mandatory token format defined nor do we mandate token >> content either. Hence we do not strongly require anything >> specifically to be put into the tokens. >> >> 2) In the implicit grant flow the client isn't authenticated and >> hence what do you want to put into a token as an audience restriction? >> >> Finally, I think that the "audience restriction" terminology is a bit >> fuzzy for this discussion either. >> Audience restriction can mean two things: >> >> * Allowing the client to verify that the access token has indeed been >> issued for him / her. >> * Allowing the resource server verify that the received access token >> from a specific client has indeed been provided by that client. >> >> My current believe is that the implicit grant flow is unsuitable for >> providing authentication functionality. >> >> Ciao >> Hannes >> >> On Jun 19, 2012, at 5:50 AM, John Bradley wrote: >> >>> I can put something together. >>> >>> It is mostly a warning about the token substitution attack that any >>> implicit flow is vulnerable to if used for authentication of the >>> presenter. >>> Otherwise known as why audience restriction is a good thing. >>> >>> John B. >>> >>> On 2012-06-18, at 8:20 PM, Dick Hardt wrote: >>> >>>> John >>>> >>>> Do you have suggested text per your suggestion below? >>>> >>>> -- Dick >>>> >>>> On Jun 18, 2012, at 2:04 PM, John Bradley wrote: >>>> >>>>> I blogged about this in the hypothetical several months ago. >>>>> http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.html >>>>> >>>>> Nov Matake and others built some tests and found quite a number of >>>>> deployments vulnerable. >>>>> http://www.thread-safe.com/2012/02/more-on-oauth-implicit-flow-application.html >>>>> >>>>> The bottom line is that OAuth has no explicit audience restriction >>>>> for tokens, hence accepting any token outside of the code flow is >>>>> subject to attack. >>>>> >>>>> In general it is not a issue for authorization, it is however a >>>>> big issue then there is a presumption that the presenter of a >>>>> token that grants a client access to resource x is the "resource >>>>> owner" of resource x, when it is possible that the presenter is >>>>> any client who has ever had a access token for resource x. >>>>> >>>>> We might want to include the why it is insecure in the security >>>>> consideration, otherwise people reading the below will likely >>>>> ignore the advice as it seems on the surface a touch extreme. >>>>> >>>>> There are certainly OAuth flows that allow you to do >>>>> authentication safely, just not all of them without additional >>>>> precautions. >>>>> >>>>> That is why openID Connect has a audience restricted id_token >>>>> similar to Facebook's signed request to allow the implicit flows >>>>> to be safely used for authentication. >>>>> >>>>> John B. >>>>> >>>>> >>>>> >>>>> >>>>> On 2012-06-18, at 4:19 PM, Shuo Chen (MSR) wrote: >>>>> >>>>>> Hi OAuth group, >>>>>> >>>>>> This is regarding the recent discussion about an implementation >>>>>> issue of some cloud services using OAuth for authentication. >>>>>> Derek Atkins and Dick Hardt suggested the possibility to discuss >>>>>> with the group a paragraph to add to the security considerations >>>>>> section. >>>>>> >>>>>> Derek's suggestion: >>>>>> ==== === === === >>>>>>>> Perhaps you could boil it down to a paragraph >>>>>>>> or two for addition to the security considerations section that >>>>>>>> basically says >>>>>>>> "beware of implementing it *this* way because it leads to >>>>>>>> *that* attack vector", etc. >>>>>> ==== === === === >>>>>> >>>>>> >>>>>> Here is out suggested text: >>>>>> ==== === === === >>>>>> It has been observed that in multiple occasions that the server-side >>>>>> authentication logic takes an access token from the client, then >>>>>> queries the user's profile data from the IdP in order to >>>>>> "authenticate" the user. This implementation must be forbidden. It >>>>>> will allow an untrusted app running on a victim's client device to >>>>>> work with an attacker's device to sign into the victim's account >>>>>> on the server side. >>>>>> ==== === === === >>>>>> >>>>>> >>>>>> Thank you. >>>>>> -Shuo >>>>>> p.s. below is the email thread giving a better context of the >>>>>> discussion. >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Derek Atkins [mailto:derek@ihtfp.com] >>>>>>> Sent: Monday, June 18, 2012 11:25 AM >>>>>>> To: Shuo Chen (MSR) >>>>>>> Cc: Hannes Tschofenig; rui wang; Stephen Farrell; Yuchen Zhou; Derek >>>>>>> Atkins; Dick Hardt >>>>>>> Subject: Re: [OAUTH-WG] web sso study... >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> "Shuo Chen (MSR)" >>>>>> > writes: >>>>>>> >>>>>>>> Hi Hannes, Derek and Stephen, >>>>>>>> >>>>>>>> Thank you for your replies. >>>>>>>> >>>>>>>>> First, let me ask whether it is OK if I share your post with the >>>>>>>>> OAuth WG >>>>>>>> >>>>>>>> Yes, please feel free to share it. >>>>>>>> >>>>>>>>> Second, could you describe the attack in more details to me? >>>>>>>> >>>>>>>> Let's consider the mobile+cloud scenario for concreteness (although >>>>>>>> some other scenarios are also applicable). The attack steps are the >>>>>>>> following: suppose Alice's tablet runs a Windows 8 Metro app >>>>>>>> written >>>>>>>> by attacker Bob. This app is able to request and obtain an access >>>>>>>> token from the IdP (associated with Alice). The app can then >>>>>>>> send the >>>>>>>> access token to Bob's own tablet. Note that there is no security >>>>>>>> problem up to this point. However the real problem is that some >>>>>>>> cloud >>>>>>>> services use the access token to query the user's profile data from >>>>>>>> the IdP in order to "authenticate" the user. In this case, Bob's >>>>>>>> tablet will be able to sign into the cloud service as Alice. We >>>>>>>> have >>>>>>>> confirmed that the cloud services for Soluto Metro App, Givit Metro >>>>>>>> App and EuroCup2012 Metro App make this mistake. These are apps in >>>>>>>> the official Windows 8 App Store. We actually sampled only a >>>>>>>> small portion of the available apps, but believe this is a >>>>>>>> vulnerability pattern. >>>>>>>> >>>>>>>> We don't think there is anything wrong in the OAuth spec. It is >>>>>>>> developers who didn't comprehensively understand the usage of the >>>>>>>> access token. In the meanwhile, this vulnerability pattern is >>>>>>>> not explicitly excluded by the spec. >>>>>>>> More importantly, it has been seen in the wild. >>>>>>>> >>>>>>>>> [from Derek's email] Perhaps you could boil it down to a paragraph >>>>>>>>> or two for >>>>>>>> addition to the security considerations section that basically says >>>>>>>> "beware of implementing it *this* way because it leads to >>>>>>>> *that* attack vector", etc. >>>>>>>> >>>>>>>> This is a great idea. I think that although it is difficult to >>>>>>>> anticipate in general all kinds of incomprehensive >>>>>>>> understandings of >>>>>>>> average developers, it is very worthwhile to take any common >>>>>>>> existing >>>>>>>> vulnerability pattern as a precious feedback to improve the >>>>>>>> specification text. In this case, since we have already seen this >>>>>>>> vulnerability pattern on multiple services in the wild, >>>>>>>> certainly we >>>>>>>> should be explicit about it in the security considerations section. >>>>>>>> >>>>>>>> Our suggested text: >>>>>>>> >>>>>>>> It has been observed that in multiple occasions that the >>>>>>>> server-side >>>>>>>> authentication logic takes an access token from the client, then >>>>>>>> queries the user's profile data from the IdP in order to >>>>>>>> "authenticate" the user. This implementation must be forbidden. It >>>>>>>> will allow an untrusted app running on a victim's client device to >>>>>>>> work with an attacker's device to sign into the victim's >>>>>>>> account on the server side. >>>>>>>> >>>>>>>> Any questions or suggestions? >>>>>>> >>>>>>> Could you please send this to the oauth@ietf.org >>>>>>> mailing list? >>>>>>> >>>>>>>> Thanks a lot. >>>>>>>> >>>>>>>> -Shuo >>>>>>> >>>>>>> -derek >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>>>>> Sent: Friday, June 15, 2012 11:36 AM >>>>>>>> To: rui wang >>>>>>>> Cc: Hannes Tschofenig; Stephen Farrell; Shuo Chen (MSR); Yuchen >>>>>>>> Zhou; >>>>>>>> Derek Atkins >>>>>>>> Subject: Re: [OAUTH-WG] web sso study... >>>>>>>> >>>>>>>> Hi Rui, >>>>>>>> >>>>>>>> let me independently respond (in addition to the previous responses >>>>>>>> you had already gotten). >>>>>>>> >>>>>>>> First, let me ask whether it is OK if I share your post with the >>>>>>>> OAuth WG since it is more detailed than the one you distributed >>>>>>>> on the list mid April. >>>>>>>> >>>>>>>> Second, could you describe the attack in more details to me? What I >>>>>>>> would like to better understand whether this the raised issue is a >>>>>>>> problem with one of our specifications, with a specific >>>>>>>> implementation of the IETF OAuth specifications, a problem with >>>>>>>> other >>>>>>>> OAuth related work (Facebook, as you know, implements far more than >>>>>>>> just the IETF OAuth specifications), a violation of the IETF OAuth >>>>>>>> specification in the way how the Websites use OAuth, whether >>>>>>>> this is >>>>>>>> a configuration related aspect, or an aspect we already >>>>>>>> documented in the threats document. >>>>>>>> >>>>>>>> The reason why I am so specific is to know where to put text to >>>>>>>> address this issue or whether this is even an issue beyond the IETF >>>>>>>> OAuth working group and needs to be tackled somewhere else. >>>>>>>> >>>>>>>> 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 --------------040008050904000605080802 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi John,

I fully agree with your assessment. This attack utilizes the fact that some clients rely on the result of a resource server request to login an user. It is not an attack on the OAuth protocol. And even if a similar attack on authorization codes will happen to fail for confidential clients does not mean OAuth is supposed to solve this problem.

We nevertheless should mention it in the security considerations section. To make things simple, I suggest to describe and ban this anti-pattern _in general_ in the security consideration section (similar to Shuo's initial proposal but more generalized). Additionally, the text should recommend to use an appropriate technique for id providing such as OpenID or SAML.

We also could add a detailed analaysis to the security document.

best regards,
Torsten.


Am 21.06.2012 15:47, schrieb John Bradley:
Hi Hannes,

MAC tokens protect resources against token leakage to third parties.  That is useful but a different threat.  

The easiest way to get a access token for someone is to have them log into your site.   

If you can do that the token type makes no difference unless we move to a asymmetric holder of key token (different discussion).

The bad client gets the access MAC token and token secret and can re use it just as it would a bearer token.

The origin of the post was a contention by someone at Facebook that profiling OAuth 2.0 on its own is sufficient to produce an Authentication protocol.

I was trying to point out that OAuth 2 without any extensions, only profiling is difficult to impossible to use for authentication as the attack surface and security considerations are different.

As it turned out Facebook had extended OAuth 2 with signed requests and token introspection techniques to address these issues for themselves.   

The problem as it turned out was that individual apps and  app frameworks like the iOS one made some bad mistakes, by not using the perhaps under documented extensions.

The problem is not unique to Facebook in any way they are just a convenient example.

Oauth 2  is not surprisingly mostly about protecting the resource.  

Authentication is about protecting the client.

Audience restriction from openID 2, SAML,  WS* etc prevents replay of tokens issued to one RP/SP at another.  
That is sort of authentication protocol threat number 1.

OAuth has no way to do that with access tokens.

It can however do it with "code" if the client is confidential.

So my recommendation is that without extensions to OAuth like structured tokens (signed_request, id_token) or token introspection endpoints like 
Facebook ( https://graph.facebook.com/app?access_token=[The Access Token]), there is no safe way to use an implicit flow for authentication.
A code flow where a native app exchanges code for the access token and then passes the access token back to it's server is also vulnerable (lots of this in circulation I understand)

The only safe flow (without extensions) is the code flow where the client is confidential and the code is directly exchanged for the access token.
This also requires the definition of a identity API that is protected by the access token, and out of scope for OAuth.

So at the end of the day the rational conclusion is that OAuth 2 is a authorization protocol.   
It may be used by Authentication protocols, but it is up to other specs to define the security considerations for that.

That however doesn't remove the need to mention the token substitution attack that non confidential clients are subject to, do to there being no other mechanism for the client to know who the token was issued to.

John B.





On 2012-06-21, at 5:27 AM, Hannes Tschofenig wrote:

Hi John,

I read through your blog post. I am not sure whether I can entirely agree with your separation between authentication and authorization. I believe the core issue here is that

* anyone who has the token will get access to whatever the token entitles him or her to do (unless there are restrictions in the token)

* some attributes are different than others. With authentication you typically associate that the process took place recently (i.e., it is fresh) while other attributes do not require the user (as resource owner) to actively participate in the exchange and the same level of freshness is not implied.  For authentication in a three party protocol to be useful the three parties have to participate (see http://tools.ietf.org/id/draft-tschofenig-oauth-signature-thoughts-00.txt).

I understand that one wants to avoid having tokens passed around from one application to the other one, as it is happening here.

I remember having some of these discussions with Eran a long time ago. He anticipated that implementers will not put any constraints in the tokens and hence they will be misused. This serves as an argument for him to propose the MAC token specification.

I proposed text for the security consideration section of the bearer document a while ago and it even talks about audience restriction as a recommendation.

There are two problems with the audience restriction:

1) There is no mandatory token format defined nor do we mandate token content either. Hence we do not strongly require anything specifically to be put into the tokens.

2) In the implicit grant flow the client isn't authenticated and hence what do you want to put into a token as an audience restriction?

Finally, I think that the "audience restriction" terminology is a bit fuzzy for this discussion either.
Audience restriction can mean two things:

* Allowing the client to verify that the access token has indeed been issued for him / her.
* Allowing the resource server verify that the received access token from a specific client has indeed been provided by that client.

My current believe is that the implicit grant flow is unsuitable for providing authentication functionality.

Ciao
Hannes

On Jun 19, 2012, at 5:50 AM, John Bradley wrote:

I can put something together.   

It is mostly a warning about the token substitution attack that any implicit flow is vulnerable to if used for authentication of the presenter.
Otherwise known as why audience restriction is a good thing.

John B.

On 2012-06-18, at 8:20 PM, Dick Hardt wrote:

John

Do you have suggested text per your suggestion below?

-- Dick

On Jun 18, 2012, at 2:04 PM, John Bradley wrote:

I blogged about this in the hypothetical several months ago. http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.html

Nov Matake and others built some tests and found quite a number of deployments vulnerable.
http://www.thread-safe.com/2012/02/more-on-oauth-implicit-flow-application.html

The bottom line is that OAuth has no explicit audience restriction for tokens,  hence accepting any token outside of the code flow is subject to attack.

In general it is not a issue for authorization,  it is however a big issue then there is a presumption that the presenter of a token that grants a client access to resource x is the "resource owner" of resource x, when it is possible that the presenter is any client who has ever had a access token for resource x.

We might want to include the why it is insecure in the security consideration,  otherwise people reading the below will likely ignore the advice as it seems on the surface a touch extreme.

There are certainly OAuth flows that allow you to do authentication safely,  just not all of them without additional precautions.

That is why openID Connect has a audience restricted id_token similar to Facebook's signed request to allow the implicit flows to be safely used for authentication.

John B.




On 2012-06-18, at 4:19 PM, Shuo Chen (MSR) wrote:

Hi OAuth group,

This is regarding the recent discussion about an implementation issue of some cloud services using OAuth for authentication.
Derek Atkins and Dick Hardt suggested the possibility to discuss with the group a paragraph to add to the security considerations section.

Derek’s suggestion:
====   ===  ===  ===
Perhaps you could boil it down to a paragraph
or two for addition to the security considerations section that basically says
"beware of implementing it *this* way because it leads to *that* attack vector", etc.
====   ===  ===  ===


Here is out suggested text:
====   ===  ===  ===
It has been observed that in multiple occasions that the server-side
authentication logic takes an access token from the client, then
queries the user's profile data from the IdP in order to
"authenticate" the user. This implementation must be forbidden. It
will allow an untrusted app running on a victim’s client device to
work with an attacker’s device to sign into the victim’s account on the server side.
====   ===  ===  ===


Thank you.
-Shuo
p.s. below is the email thread giving a better context of the discussion.


-----Original Message-----
From: Derek Atkins [mailto:derek@ihtfp.com]
Sent: Monday, June 18, 2012 11:25 AM
To: Shuo Chen (MSR)
Cc: Hannes Tschofenig; rui wang; Stephen Farrell; Yuchen Zhou; Derek
Atkins; Dick Hardt
Subject: Re: [OAUTH-WG] web sso study...

Hi,

"Shuo Chen (MSR)" <shuochen@microsoft.com> writes:

Hi Hannes, Derek and Stephen,

Thank you for your replies.

First, let me ask whether it is OK if I share your post with the
OAuth WG

Yes, please feel free to share it.

Second, could you describe the attack in more details to me?

Let's consider the mobile+cloud scenario for concreteness (although
some other scenarios are also applicable). The attack steps are the
following: suppose Alice's tablet runs a Windows 8 Metro app written
by attacker Bob. This app is able to request and obtain an access
token from the IdP (associated with Alice). The app can then send the
access token to Bob's own tablet. Note that there is no security
problem up to this point. However the real problem is that some cloud
services use the access token to query the user's profile data from
the IdP in order to "authenticate" the user. In this case, Bob's
tablet will be able to sign into the cloud service as Alice. We have
confirmed that the cloud services for Soluto Metro App, Givit Metro
App and EuroCup2012 Metro App make this mistake. These are apps in
the official Windows 8 App Store. We actually sampled only a small portion of the available apps, but believe this is a vulnerability pattern.

We don’t think there is anything wrong in the OAuth spec. It is
developers who didn’t comprehensively understand the usage of the
access token. In the meanwhile, this vulnerability pattern is not explicitly excluded by the spec.
More importantly, it has been seen in the wild.

[from Derek's email] Perhaps you could boil it down to a paragraph
or two for
addition to the security considerations section that basically says
"beware of implementing it *this* way because it leads to *that* attack vector", etc.

This is a great idea. I think that although it is difficult to
anticipate in general all kinds of incomprehensive understandings of
average developers, it is very worthwhile to take any common existing
vulnerability pattern as a precious feedback to improve the
specification text. In this case, since we have already seen this
vulnerability pattern on multiple services in the wild, certainly we
should be explicit about it in the security considerations section.

Our suggested text:

It has been observed that in multiple occasions that the server-side
authentication logic takes an access token from the client, then
queries the user's profile data from the IdP in order to
"authenticate" the user. This implementation must be forbidden. It
will allow an untrusted app running on a victim’s client device to
work with an attacker’s device to sign into the victim’s account on the server side.

Any questions or suggestions?

Could you please send this to the oauth@ietf.org mailing list?

Thanks a lot.

-Shuo

-derek

-----Original Message-----
From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
Sent: Friday, June 15, 2012 11:36 AM
To: rui wang
Cc: Hannes Tschofenig; Stephen Farrell; Shuo Chen (MSR); Yuchen Zhou;
Derek Atkins
Subject: Re: [OAUTH-WG] web sso study...

Hi Rui,

let me independently respond (in addition to the previous responses
you had already gotten).

First, let me ask whether it is OK if I share your post with the
OAuth WG since it is more detailed than the one you distributed on the list mid April.

Second, could you describe the attack in more details to me? What I
would like to better understand whether this the raised issue is a
problem with one of our specifications, with a specific
implementation of the IETF OAuth specifications, a problem with other
OAuth related work (Facebook, as you know, implements far more than
just the IETF OAuth specifications), a violation of the IETF OAuth
specification in the way how the Websites use OAuth, whether this is
a configuration related aspect, or an aspect we already documented in the threats document.

The reason why I am so specific is to know where to put text to
address this issue or whether this is even an issue beyond the IETF
OAuth working group and needs to be tackled somewhere else.

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


--------------040008050904000605080802-- From Michael.Jones@microsoft.com Sat Jun 23 11:31:12 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F3F921F8513 for ; Sat, 23 Jun 2012 11:31:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.847 X-Spam-Level: X-Spam-Status: No, score=-3.847 tagged_above=-999 required=5 tests=[AWL=-0.248, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1fdyhppLMAfp for ; Sat, 23 Jun 2012 11:31:08 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe001.messaging.microsoft.com [216.32.181.181]) by ietfa.amsl.com (Postfix) with ESMTP id D177121F8512 for ; Sat, 23 Jun 2012 11:31:07 -0700 (PDT) Received: from mail11-ch1-R.bigfish.com (10.43.68.240) by CH1EHSOBE013.bigfish.com (10.43.70.63) with Microsoft SMTP Server id 14.1.225.23; Sat, 23 Jun 2012 18:29:34 +0000 Received: from mail11-ch1 (localhost [127.0.0.1]) by mail11-ch1-R.bigfish.com (Postfix) with ESMTP id 2F15A140530; Sat, 23 Jun 2012 18:29:34 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -31 X-BigFish: VS-31(zzbb2dI98dI9371I936eI146fI542M1432Izz1202hzz8275ch1033IL8275dhz2fh2a8h668h839h944hd25hf0ah) Received-SPF: pass (mail11-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail11-ch1 (localhost.localdomain [127.0.0.1]) by mail11-ch1 (MessageSwitch) id 1340476172960755_1223; Sat, 23 Jun 2012 18:29:32 +0000 (UTC) Received: from CH1EHSMHS012.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.229]) by mail11-ch1.bigfish.com (Postfix) with ESMTP id E7F25400046; Sat, 23 Jun 2012 18:29:32 +0000 (UTC) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS012.bigfish.com (10.43.70.12) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 23 Jun 2012 18:29:32 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.53]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.02.0298.005; Sat, 23 Jun 2012 18:31:04 +0000 From: Mike Jones To: John Bradley , Hannes Tschofenig Thread-Topic: [OAUTH-WG] AD review of draft-ietf-oauth-urn-sub-ns-02 Thread-Index: AQHNTt/sWKdca/SRw0Gp10lpJtZuBZcFFX4AgAAEYoCAABAKAIAAASMAgAAFEZuAAqpvgIAAM2IAgAAwscA= Date: Sat, 23 Jun 2012 18:31:04 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366565C12@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <4FE1C16D.6010602@cs.tcd.ie> <4CD0B85C-C88D-4B52-81E4-5D53A25E60EF@cs.tcd.ie> <4E1F6AAD24975D4BA5B16804296739436656365A@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: Barry Leiba , "oauth@ietf.org" Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-urn-sub-ns-02 X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 18:31:12 -0000 I agree that Specification Required would be fine. I'd rather that there b= e a publicly available specification defining the URN than one potentially = available only to the expert reviewers. -- Mike -----Original Message----- From: John Bradley [mailto:ve7jtb@ve7jtb.com]=20 Sent: Saturday, June 23, 2012 8:36 AM To: Hannes Tschofenig Cc: Mike Jones; oauth@ietf.org; Barry Leiba Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-urn-sub-ns-02 I think Specification required is fine. It allows a OIDF or OASIS spec to = be used as the basis for the registration withh appropriate expert review. John B. Sent from my iPad On 2012-06-23, at 8:31 AM, Hannes Tschofenig wr= ote: > Hi Mike,=20 >=20 > the point is not that other groups, like OASIS, cannot use them. They can= use the extensions.=20 >=20 > The question is more what process and documentation is needed to allow OA= SIS (and others) to define their own extensions.=20 >=20 > So far, OASIS had not been interested for any extension (at least from wh= at I know). The OpenID community, to which you also belong, had defined ext= ensions (and brought some of them to the IETF) but had been quite careful t= hemselves to ensure proper review and documentation.=20 >=20 > So, if you look at the most important decision points then you have:=20 >=20 > 1) do you want a requirement for a specification, i.e., when someone defi= nes an extension do you want it to be documented somewhere?=20 >=20 > 2) do you envision a review from experts (e.g., checking whether the stuf= f makes any sense or conflicts with some other already available extensions= )?=20 >=20 > http://tools.ietf.org/html/rfc5226 provides a good discussion about this = topic.=20 >=20 > If the answer to the above-listed questions is YES then you probably at l= east want 'Specification Required' as a policy.=20 >=20 > Ciao > Hannes >=20 >=20 > On Jun 21, 2012, at 10:49 PM, Mike Jones wrote: >=20 >> I'd argue that the registration regime chosen should be flexible enough = to permit OASIS or OpenID specs to use it. Otherwise, as someone else point= ed, people will work around the limitation by using unregistered values - w= hich helps no one. >>=20 >> -- Mike >>=20 >> From: Barry Leiba >> Sent: 6/21/2012 12:31 PM >> To: Stephen Farrell >> Cc: oauth@ietf.org >> Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-urn-sub-ns-02 >>=20 >>>> Stephen: >>>> Yeah, I'm not sure Standards Track is needed. >>>=20 >>> On this bit: I personally don't care, except that we don't have to do i= t twice >>> because someone later on thinks the opposite and wins that argument, wh= ich >>> I'd rather not have at all (My one-track mind:-) Doing the 4 week last= call means >>> once is enough. But I'm ok with whatever the WG want. >>=20 >> Well, it's not a 4-week LC, but a 2-week one. Anyway, yes, I see your >> point, and I've done that with other documents. Better to make it >> Standards Track for now, note in the shepherd writeup that >> Informational is probably OK, and let the IESG decide. >>=20 >> b >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From Michael.Jones@microsoft.com Sat Jun 23 11:41:37 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2839021F84FF for ; Sat, 23 Jun 2012 11:41:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.841 X-Spam-Level: X-Spam-Status: No, score=-3.841 tagged_above=-999 required=5 tests=[AWL=-0.241, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9eJVtx5v-tZK for ; Sat, 23 Jun 2012 11:41:36 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe001.messaging.microsoft.com [216.32.180.11]) by ietfa.amsl.com (Postfix) with ESMTP id 4209121F84CD for ; Sat, 23 Jun 2012 11:41:36 -0700 (PDT) Received: from mail59-va3-R.bigfish.com (10.7.14.253) by VA3EHSOBE005.bigfish.com (10.7.40.25) with Microsoft SMTP Server id 14.1.225.23; Sat, 23 Jun 2012 18:40:02 +0000 Received: from mail59-va3 (localhost [127.0.0.1]) by mail59-va3-R.bigfish.com (Postfix) with ESMTP id 3EE132201A5; Sat, 23 Jun 2012 18:40:02 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -26 X-BigFish: VS-26(zz9371I542Mzz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25hf0ah) Received-SPF: pass (mail59-va3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail59-va3 (localhost.localdomain [127.0.0.1]) by mail59-va3 (MessageSwitch) id 1340476800102220_28617; Sat, 23 Jun 2012 18:40:00 +0000 (UTC) Received: from VA3EHSMHS029.bigfish.com (unknown [10.7.14.238]) by mail59-va3.bigfish.com (Postfix) with ESMTP id 0FB2920009E; Sat, 23 Jun 2012 18:40:00 +0000 (UTC) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS029.bigfish.com (10.7.99.39) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 23 Jun 2012 18:39:59 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.53]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.02.0309.003; Sat, 23 Jun 2012 18:41:31 +0000 From: Mike Jones To: Hannes Tschofenig , OAuth WG Thread-Topic: [OAUTH-WG] OAuth URN Registry Discussion Summary Thread-Index: AQHNUVNNJXjHlh1ykkGDwKOQHsi2XpcIOhvw Date: Sat, 23 Jun 2012 18:41:30 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366565C40@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <575E933A-6FEF-4821-8677-319FE72564D7@gmx.net> In-Reply-To: <575E933A-6FEF-4821-8677-319FE72564D7@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [OAUTH-WG] OAuth URN Registry Discussion Summary X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 18:41:37 -0000 I'd rather that we did the review based upon the current draft rather than = rolling back. Hannes, my point about three levels was that we can't necessarily know up f= ront what the structure of URNs would be that might make sense to register = in the future. I was using that possibility as an example to object to a s= trict two-level hierarchy. Sometimes a one-level name may make sense as we= ll. I agree with you that Section 3 of http://tools.ietf.org/html/rfc3553 says = about the colon character (":") defines a lightweight syntax for hexarchies= to use when they make sense. I just think it's overkill to put the hierar= chy in the registry, per se. I agree that in http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions= we should add IANA considerations text saying that any new extensions for = client assertions should be registered with the name client-assertion-type:= *. Likewise we should figure out the right place to say that new grant typ= es should be registered as grant-type:*. These would be naming conventions= though - not something that's a part of the registry. Cheers, -- Mike -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of H= annes Tschofenig Sent: Saturday, June 23, 2012 8:17 AM To: OAuth WG Subject: [OAUTH-WG] OAuth URN Registry Discussion Summary As you have seen I have responded to various mails and I believe I understa= nd what people want.=20 Some of you obviously have plans to write extensions (in other organization= s outside the IETF, and as vendor-specific extensions). That's fine.=20 You want something really lightweight (in terms of process) that does not r= equire you to come to the IETF to write an RFC and get the entire working g= roup excited about your hobby project. Clearly, this makes sense to me.=20 So, the policy for adding new extensions has to be either 'Specification Re= quired' or 'Expert Review' with the difference being about the information = that goes into the registry. For the cases I have seen on the list it will = not make a huge difference. It may make a difference for an organization wh= ere their final specifications are not publically available. Yes, these org= anizations still exist today.... Then, there is the question about how the identifier that gets registered s= hould look like. You seem to like the idea of concept of a structured ident= ifier (since otherwise you wouldn't be using it in various working group dr= afts already, including the example in draft-ietf-oauth-urn-sub-ns itself!)= but you don't like to call it hierarchy because you fear that you will not= be allowed to do whatever you want. An unjustified concern. In that sense version -03 of the draft (see http://tools.ietf.org/id/draft-= ietf-oauth-urn-sub-ns-03.txt) pretty much does already everything you want = already do. As a policy it says "Expert Review" and it has the structure in= the ID that you guys are using in your current drafts! There are two options to go forward.=20 The first one is to roll-back to version -03.=20 Another option is to take version -04 and add text that explains the a= bit further by saying that it may contain a structure and other documents = populating the registry will define the detailed structure of the part= .=20 In http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ we would th= en add a section to the IANA consideration section saying that any new exte= nsions for client assertions needs to be registered under urn:ietf:params:o= auth:client-assertion-type: The same for urn:ietf:params:oauth:grant-type: in some other document and s= o on.=20 Ciao Hannes _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From ve7jtb@ve7jtb.com Sat Jun 23 11:55:24 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CD4721F84FA for ; Sat, 23 Jun 2012 11:55:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.101 X-Spam-Level: X-Spam-Status: No, score=-3.101 tagged_above=-999 required=5 tests=[AWL=-0.103, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_65=0.6, 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 OF2svFdeyUeP for ; Sat, 23 Jun 2012 11:55:21 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5972621F848A for ; Sat, 23 Jun 2012 11:55:21 -0700 (PDT) Received: by ghbg16 with SMTP id g16so2438941ghb.31 for ; Sat, 23 Jun 2012 11:55:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=SzRt+2JOXANha7LBTaFmaEr//kEITWpY47zCeNY1bpY=; b=mMWZ2wzUkPGmu9ce/qySpMslLCJB9xAahGDHC1URvH0H9rcLwLZnYPH+vmnybjgtDG gOoA1f2qBN5/7dv3n6n7uv0KfU+c8zzy8K0trOtzolCHBxkX82ONnbEV4Q0Qy3jqlJUv 94hTRCexHbV2rEX8TipFsAiJneLGspQIkHBoDmoKNP5SnYkNIN0jVSDXKi1QCBh07a70 Za//3Jip+NTyRytSbcAw7Cht8jjNoBhNAOTeMuU0rzbh3S6rUhYTqlexE4d2PXAAvmBa 5hWzj/34HZqQ4DkijpQzBW19/rPuFpcXiNWQ3kNA55rcVFzv4tQe+RyrFkzQyT14LUqK zINg== Received: by 10.236.180.40 with SMTP id i28mr7384620yhm.22.1340477720410; Sat, 23 Jun 2012 11:55:20 -0700 (PDT) Received: from [192.168.1.213] (190-20-54-57.baf.movistar.cl. [190.20.54.57]) by mx.google.com with ESMTPS id d10sm52489934anm.17.2012.06.23.11.54.55 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 23 Jun 2012 11:55:19 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_746DF497-8603-4970-8284-A57BB7EF6F7F"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <4FE609C6.9020902@lodderstedt.net> Date: Sat, 23 Jun 2012 14:54:43 -0400 Message-Id: <7F9928C8-9B11-4F3B-93A0-2469403F6569@ve7jtb.com> References: <854774286EF8A240BACC342973A86EAC016693D6@BL2PRD0310MB387.namprd03.prod.outlook.com> <484A13D0-7C9A-42CC-BB94-3657741834DE@ve7jtb.com> <82D95BA2-1697-4441-BBB3-B2AE480DC39E@gmail.com> <4FE609C6.9020902@lodderstedt.net> To: Torsten Lodderstedt X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQmV2cm1uAS+0jteplQ/3DZKMHCqiRidQq6szLVqv4i9sZZKgMJVTSCAfGHRQodM+dYABEok Cc: rui wang , Yuchen Zhou , "Shuo Chen \(MSR\)" , Derek Atkins , "oauth@ietf.org" Subject: Re: [OAUTH-WG] proposal of a paragraph to add to the security considerations section X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 18:55:24 -0000 --Apple-Mail=_746DF497-8603-4970-8284-A57BB7EF6F7F Content-Type: multipart/alternative; boundary="Apple-Mail=_52D110EC-F11B-43B1-8280-E39A51E283ED" --Apple-Mail=_52D110EC-F11B-43B1-8280-E39A51E283ED Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Yes it is probably best to keep it short in the main spec, but go into = more detail in the security document. OAuth is fine as it is. If you use OAuth as part of another protocol = that protocol should be taking responsibility for it's own security = considerations and not assuming that OAuth will cover everything you are = doing. Like it or not once you do federated authentication with OAuth you have = created a different protocol that needs different security = considerations. We all sort of know that, the problem is that some people confuse = authentication and authorization as the same thing, so it is worth point = ing out. John B. On 2012-06-23, at 2:24 PM, Torsten Lodderstedt wrote: > Hi John, >=20 > I fully agree with your assessment. This attack utilizes the fact that = some clients rely on the result of a resource server request to login an = user. It is not an attack on the OAuth protocol. And even if a similar = attack on authorization codes will happen to fail for confidential = clients does not mean OAuth is supposed to solve this problem. >=20 > We nevertheless should mention it in the security considerations = section. To make things simple, I suggest to describe and ban this = anti-pattern _in general_ in the security consideration section (similar = to Shuo's initial proposal but more generalized). Additionally, the text = should recommend to use an appropriate technique for id providing such = as OpenID or SAML. >=20 > We also could add a detailed analaysis to the security document. >=20 > best regards, > Torsten. >=20 >=20 > Am 21.06.2012 15:47, schrieb John Bradley: >> Hi Hannes, >>=20 >> MAC tokens protect resources against token leakage to third parties. = That is useful but a different threat. =20 >>=20 >> The easiest way to get a access token for someone is to have them log = into your site. =20 >>=20 >> If you can do that the token type makes no difference unless we move = to a asymmetric holder of key token (different discussion). >>=20 >> The bad client gets the access MAC token and token secret and can re = use it just as it would a bearer token. >>=20 >> The origin of the post was a contention by someone at Facebook that = profiling OAuth 2.0 on its own is sufficient to produce an = Authentication protocol. >>=20 >> I was trying to point out that OAuth 2 without any extensions, only = profiling is difficult to impossible to use for authentication as the = attack surface and security considerations are different. >>=20 >> As it turned out Facebook had extended OAuth 2 with signed requests = and token introspection techniques to address these issues for = themselves. =20 >>=20 >> The problem as it turned out was that individual apps and app = frameworks like the iOS one made some bad mistakes, by not using the = perhaps under documented extensions. >>=20 >> The problem is not unique to Facebook in any way they are just a = convenient example. >>=20 >> Oauth 2 is not surprisingly mostly about protecting the resource. =20= >>=20 >> Authentication is about protecting the client. >>=20 >> Audience restriction from openID 2, SAML, WS* etc prevents replay of = tokens issued to one RP/SP at another. =20 >> That is sort of authentication protocol threat number 1. >>=20 >> OAuth has no way to do that with access tokens. >>=20 >> It can however do it with "code" if the client is confidential. >>=20 >> So my recommendation is that without extensions to OAuth like = structured tokens (signed_request, id_token) or token introspection = endpoints like=20 >> Facebook ( https://graph.facebook.com/app?access_token=3D[The Access = Token]), there is no safe way to use an implicit flow for = authentication. >> A code flow where a native app exchanges code for the access token = and then passes the access token back to it's server is also vulnerable = (lots of this in circulation I understand) >>=20 >> The only safe flow (without extensions) is the code flow where the = client is confidential and the code is directly exchanged for the access = token. >> This also requires the definition of a identity API that is protected = by the access token, and out of scope for OAuth. >>=20 >> So at the end of the day the rational conclusion is that OAuth 2 is a = authorization protocol. =20 >> It may be used by Authentication protocols, but it is up to other = specs to define the security considerations for that. >>=20 >> That however doesn't remove the need to mention the token = substitution attack that non confidential clients are subject to, do to = there being no other mechanism for the client to know who the token was = issued to. >>=20 >> John B. >>=20 >>=20 >>=20 >>=20 >>=20 >> On 2012-06-21, at 5:27 AM, Hannes Tschofenig wrote: >>=20 >>> Hi John,=20 >>>=20 >>> I read through your blog post. I am not sure whether I can entirely = agree with your separation between authentication and authorization. I = believe the core issue here is that=20 >>>=20 >>> * anyone who has the token will get access to whatever the token = entitles him or her to do (unless there are restrictions in the token) >>>=20 >>> * some attributes are different than others. With authentication you = typically associate that the process took place recently (i.e., it is = fresh) while other attributes do not require the user (as resource = owner) to actively participate in the exchange and the same level of = freshness is not implied. For authentication in a three party protocol = to be useful the three parties have to participate (see = http://tools.ietf.org/id/draft-tschofenig-oauth-signature-thoughts-00.txt)= .=20 >>>=20 >>> I understand that one wants to avoid having tokens passed around = from one application to the other one, as it is happening here.=20 >>>=20 >>> I remember having some of these discussions with Eran a long time = ago. He anticipated that implementers will not put any constraints in = the tokens and hence they will be misused. This serves as an argument = for him to propose the MAC token specification.=20 >>>=20 >>> I proposed text for the security consideration section of the bearer = document a while ago and it even talks about audience restriction as a = recommendation.=20 >>>=20 >>> There are two problems with the audience restriction:=20 >>>=20 >>> 1) There is no mandatory token format defined nor do we mandate = token content either. Hence we do not strongly require anything = specifically to be put into the tokens.=20 >>>=20 >>> 2) In the implicit grant flow the client isn't authenticated and = hence what do you want to put into a token as an audience restriction?=20= >>>=20 >>> Finally, I think that the "audience restriction" terminology is a = bit fuzzy for this discussion either.=20 >>> Audience restriction can mean two things: >>>=20 >>> * Allowing the client to verify that the access token has indeed = been issued for him / her.=20 >>> * Allowing the resource server verify that the received access token = from a specific client has indeed been provided by that client.=20 >>>=20 >>> My current believe is that the implicit grant flow is unsuitable for = providing authentication functionality.=20 >>>=20 >>> Ciao >>> Hannes >>>=20 >>> On Jun 19, 2012, at 5:50 AM, John Bradley wrote: >>>=20 >>>> I can put something together. =20 >>>>=20 >>>> It is mostly a warning about the token substitution attack that any = implicit flow is vulnerable to if used for authentication of the = presenter. >>>> Otherwise known as why audience restriction is a good thing. >>>>=20 >>>> John B. >>>>=20 >>>> On 2012-06-18, at 8:20 PM, Dick Hardt wrote: >>>>=20 >>>>> John >>>>>=20 >>>>> Do you have suggested text per your suggestion below? >>>>>=20 >>>>> -- Dick >>>>>=20 >>>>> On Jun 18, 2012, at 2:04 PM, John Bradley wrote: >>>>>=20 >>>>>> I blogged about this in the hypothetical several months ago. = http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.h= tml >>>>>>=20 >>>>>> Nov Matake and others built some tests and found quite a number = of deployments vulnerable.=20 >>>>>> = http://www.thread-safe.com/2012/02/more-on-oauth-implicit-flow-application= .html >>>>>>=20 >>>>>> The bottom line is that OAuth has no explicit audience = restriction for tokens, hence accepting any token outside of the code = flow is subject to attack. >>>>>>=20 >>>>>> In general it is not a issue for authorization, it is however a = big issue then there is a presumption that the presenter of a token that = grants a client access to resource x is the "resource owner" of resource = x, when it is possible that the presenter is any client who has ever had = a access token for resource x. >>>>>>=20 >>>>>> We might want to include the why it is insecure in the security = consideration, otherwise people reading the below will likely ignore = the advice as it seems on the surface a touch extreme. >>>>>>=20 >>>>>> There are certainly OAuth flows that allow you to do = authentication safely, just not all of them without additional = precautions. >>>>>>=20 >>>>>> That is why openID Connect has a audience restricted id_token = similar to Facebook's signed request to allow the implicit flows to be = safely used for authentication. >>>>>>=20 >>>>>> John B. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On 2012-06-18, at 4:19 PM, Shuo Chen (MSR) wrote: >>>>>>=20 >>>>>>> Hi OAuth group, >>>>>>>=20 >>>>>>> This is regarding the recent discussion about an implementation = issue of some cloud services using OAuth for authentication. >>>>>>> Derek Atkins and Dick Hardt suggested the possibility to discuss = with the group a paragraph to add to the security considerations = section. >>>>>>>=20 >>>>>>> Derek=92s suggestion: >>>>>>> =3D=3D=3D=3D =3D=3D=3D =3D=3D=3D =3D=3D=3D >>>>>>>>> Perhaps you could boil it down to a paragraph >>>>>>>>> or two for addition to the security considerations section = that basically says >>>>>>>>> "beware of implementing it *this* way because it leads to = *that* attack vector", etc. >>>>>>> =3D=3D=3D=3D =3D=3D=3D =3D=3D=3D =3D=3D=3D >>>>>>>=20 >>>>>>>=20 >>>>>>> Here is out suggested text: >>>>>>> =3D=3D=3D=3D =3D=3D=3D =3D=3D=3D =3D=3D=3D >>>>>>> It has been observed that in multiple occasions that the = server-side >>>>>>> authentication logic takes an access token from the client, then >>>>>>> queries the user's profile data from the IdP in order to >>>>>>> "authenticate" the user. This implementation must be forbidden. = It >>>>>>> will allow an untrusted app running on a victim=92s client = device to >>>>>>> work with an attacker=92s device to sign into the victim=92s = account on the server side. >>>>>>> =3D=3D=3D=3D =3D=3D=3D =3D=3D=3D =3D=3D=3D >>>>>>>=20 >>>>>>>=20 >>>>>>> Thank you. >>>>>>> -Shuo >>>>>>> p.s. below is the email thread giving a better context of the = discussion. >>>>>>>=20 >>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: Derek Atkins [mailto:derek@ihtfp.com] >>>>>>>> Sent: Monday, June 18, 2012 11:25 AM >>>>>>>> To: Shuo Chen (MSR) >>>>>>>> Cc: Hannes Tschofenig; rui wang; Stephen Farrell; Yuchen Zhou; = Derek >>>>>>>> Atkins; Dick Hardt >>>>>>>> Subject: Re: [OAUTH-WG] web sso study... >>>>>>>>=20 >>>>>>>> Hi, >>>>>>>>=20 >>>>>>>> "Shuo Chen (MSR)" writes: >>>>>>>>=20 >>>>>>>>> Hi Hannes, Derek and Stephen, >>>>>>>>>=20 >>>>>>>>> Thank you for your replies. >>>>>>>>>=20 >>>>>>>>>> First, let me ask whether it is OK if I share your post with = the >>>>>>>>>> OAuth WG >>>>>>>>>=20 >>>>>>>>> Yes, please feel free to share it. >>>>>>>>>=20 >>>>>>>>>> Second, could you describe the attack in more details to me? >>>>>>>>>=20 >>>>>>>>> Let's consider the mobile+cloud scenario for concreteness = (although >>>>>>>>> some other scenarios are also applicable). The attack steps = are the >>>>>>>>> following: suppose Alice's tablet runs a Windows 8 Metro app = written >>>>>>>>> by attacker Bob. This app is able to request and obtain an = access >>>>>>>>> token from the IdP (associated with Alice). The app can then = send the >>>>>>>>> access token to Bob's own tablet. Note that there is no = security >>>>>>>>> problem up to this point. However the real problem is that = some cloud >>>>>>>>> services use the access token to query the user's profile data = from >>>>>>>>> the IdP in order to "authenticate" the user. In this case, = Bob's >>>>>>>>> tablet will be able to sign into the cloud service as Alice. = We have >>>>>>>>> confirmed that the cloud services for Soluto Metro App, Givit = Metro >>>>>>>>> App and EuroCup2012 Metro App make this mistake. These are = apps in >>>>>>>>> the official Windows 8 App Store. We actually sampled only a = small portion of the available apps, but believe this is a vulnerability = pattern. >>>>>>>>>=20 >>>>>>>>> We don=92t think there is anything wrong in the OAuth spec. It = is >>>>>>>>> developers who didn=92t comprehensively understand the usage = of the >>>>>>>>> access token. In the meanwhile, this vulnerability pattern is = not explicitly excluded by the spec. >>>>>>>>> More importantly, it has been seen in the wild. >>>>>>>>>=20 >>>>>>>>>> [from Derek's email] Perhaps you could boil it down to a = paragraph >>>>>>>>>> or two for >>>>>>>>> addition to the security considerations section that basically = says >>>>>>>>> "beware of implementing it *this* way because it leads to = *that* attack vector", etc. >>>>>>>>>=20 >>>>>>>>> This is a great idea. I think that although it is difficult to >>>>>>>>> anticipate in general all kinds of incomprehensive = understandings of >>>>>>>>> average developers, it is very worthwhile to take any common = existing >>>>>>>>> vulnerability pattern as a precious feedback to improve the >>>>>>>>> specification text. In this case, since we have already seen = this >>>>>>>>> vulnerability pattern on multiple services in the wild, = certainly we >>>>>>>>> should be explicit about it in the security considerations = section. >>>>>>>>>=20 >>>>>>>>> Our suggested text: >>>>>>>>>=20 >>>>>>>>> It has been observed that in multiple occasions that the = server-side >>>>>>>>> authentication logic takes an access token from the client, = then >>>>>>>>> queries the user's profile data from the IdP in order to >>>>>>>>> "authenticate" the user. This implementation must be = forbidden. It >>>>>>>>> will allow an untrusted app running on a victim=92s client = device to >>>>>>>>> work with an attacker=92s device to sign into the victim=92s = account on the server side. >>>>>>>>>=20 >>>>>>>>> Any questions or suggestions? >>>>>>>>=20 >>>>>>>> Could you please send this to the oauth@ietf.org mailing list? >>>>>>>>=20 >>>>>>>>> Thanks a lot. >>>>>>>>>=20 >>>>>>>>> -Shuo >>>>>>>>=20 >>>>>>>> -derek >>>>>>>>=20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>>>>>> Sent: Friday, June 15, 2012 11:36 AM >>>>>>>>> To: rui wang >>>>>>>>> Cc: Hannes Tschofenig; Stephen Farrell; Shuo Chen (MSR); = Yuchen Zhou; >>>>>>>>> Derek Atkins >>>>>>>>> Subject: Re: [OAUTH-WG] web sso study... >>>>>>>>>=20 >>>>>>>>> Hi Rui, >>>>>>>>>=20 >>>>>>>>> let me independently respond (in addition to the previous = responses >>>>>>>>> you had already gotten). >>>>>>>>>=20 >>>>>>>>> First, let me ask whether it is OK if I share your post with = the >>>>>>>>> OAuth WG since it is more detailed than the one you = distributed on the list mid April. >>>>>>>>>=20 >>>>>>>>> Second, could you describe the attack in more details to me? = What I >>>>>>>>> would like to better understand whether this the raised issue = is a >>>>>>>>> problem with one of our specifications, with a specific >>>>>>>>> implementation of the IETF OAuth specifications, a problem = with other >>>>>>>>> OAuth related work (Facebook, as you know, implements far more = than >>>>>>>>> just the IETF OAuth specifications), a violation of the IETF = OAuth >>>>>>>>> specification in the way how the Websites use OAuth, whether = this is >>>>>>>>> a configuration related aspect, or an aspect we already = documented in the threats document. >>>>>>>>>=20 >>>>>>>>> The reason why I am so specific is to know where to put text = to >>>>>>>>> address this issue or whether this is even an issue beyond the = IETF >>>>>>>>> OAuth working group and needs to be tackled somewhere else. >>>>>>>>>=20 >>>>>>>>> Ciao >>>>>>>>>=20 >>>>>>>>> Hannes >>>>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 --Apple-Mail=_52D110EC-F11B-43B1-8280-E39A51E283ED Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Yes = it is probably best to keep it short in the main spec, but go into more = detail in the security document.

OAuth is fine as it = is.  If you use OAuth as part of another protocol that protocol = should be taking responsibility for it's own security considerations and = not assuming that OAuth will cover everything you are = doing.

Like it or not once you do federated = authentication with OAuth you have created a different protocol that = needs different security considerations.

We all = sort of know that, the problem is that some people confuse = authentication and authorization as the same thing, so it is worth point = ing out.

John B.

On = 2012-06-23, at 2:24 PM, Torsten Lodderstedt wrote:

=20 =20
Hi John,

I fully agree with your assessment. This attack utilizes the fact that some clients rely on the result of a resource server request to login an user. It is not an attack on the OAuth protocol. And even if a similar attack on authorization codes will happen to fail for confidential clients does not mean OAuth is supposed to solve this problem.

We nevertheless should mention it in the security considerations section. To make things simple, I suggest to describe and ban this anti-pattern _in general_ in the security consideration section (similar to Shuo's initial proposal but more generalized). Additionally, the text should recommend to use an appropriate technique for id providing such as OpenID or SAML.

We also could add a detailed analaysis to the security document.

best regards,
Torsten.


Am 21.06.2012 15:47, schrieb John Bradley:
Hi Hannes,

MAC tokens protect resources against token leakage to third parties.  That is useful but a different threat. =  

The easiest way to get a access token for someone is to have them log into your site.   

If you can do that the token type makes no difference unless we move to a asymmetric holder of key token (different discussion).

The bad client gets the access MAC token and token secret and can re use it just as it would a bearer token.

The origin of the post was a contention by someone at Facebook that profiling OAuth 2.0 on its own is sufficient to produce an Authentication protocol.

I was trying to point out that OAuth 2 without any extensions, only profiling is difficult to impossible to use for authentication as the attack surface and security considerations are different.

As it turned out Facebook had extended OAuth 2 with signed requests and token introspection techniques to address these issues for themselves.   

The problem as it turned out was that individual apps and  app frameworks like the iOS one made some bad mistakes, by = not using the perhaps under documented extensions.

The problem is not unique to Facebook in any way they are just a convenient example.

Oauth 2  is not surprisingly mostly about = protecting the resource.  

Authentication is about protecting the client.

Audience restriction from openID 2, SAML,  WS* etc = prevents replay of tokens issued to one RP/SP at another.  
That is sort of authentication protocol threat number = 1.

OAuth has no way to do that with access tokens.

It can however do it with "code" if the client is confidential.

So my recommendation is that without extensions to OAuth like structured tokens (signed_request, id_token) or token introspection endpoints like 
Facebook ( https://graph.= facebook.com/app?access_token=3D[The Access Token]), there is no safe way to use an implicit flow for authentication.
A code flow where a native app exchanges code for the access token and then passes the access token back to it's server is also vulnerable (lots of this in circulation I = understand)

The only safe flow (without extensions) is the code flow where the client is confidential and the code is directly exchanged for the access token.
This also requires the definition of a identity API that is protected by the access token, and out of scope for = OAuth.

So at the end of the day the rational conclusion is that OAuth 2 is a authorization protocol.   
It may be used by Authentication protocols, but it is up to other specs to define the security considerations for = that.

That however doesn't remove the need to mention the token substitution attack that non confidential clients are subject to, do to there being no other mechanism for the client to know who the token was issued to.

John B.





On 2012-06-21, at 5:27 AM, Hannes Tschofenig wrote:

Hi John,

I read through your blog post. I am not sure whether I can entirely agree with your separation between authentication and authorization. I believe the core issue here is that =

* anyone who has the token will get access to whatever the token entitles him or her to do (unless there are restrictions in the token)

* some attributes are different than others. With authentication you typically associate that the process took place recently (i.e., it is fresh) while other attributes do not require the user (as resource owner) to actively participate in the exchange and the same level of freshness is not implied.  For authentication in a = three party protocol to be useful the three parties have to participate (see http://tools.ietf.org/id/draft-tschofenig-oauth-signature-thought= s-00.txt).

I understand that one wants to avoid having tokens passed around from one application to the other one, as it is happening here.

I remember having some of these discussions with Eran a long time ago. He anticipated that implementers will not put any constraints in the tokens and hence they will be misused. This serves as an argument for him to propose the MAC token specification.

I proposed text for the security consideration section of the bearer document a while ago and it even talks about audience restriction as a recommendation.

There are two problems with the audience restriction:

1) There is no mandatory token format defined nor do we mandate token content either. Hence we do not strongly require anything specifically to be put into the tokens. =

2) In the implicit grant flow the client isn't authenticated and hence what do you want to put into a token as an audience restriction?

Finally, I think that the "audience restriction" terminology is a bit fuzzy for this discussion either. =
Audience restriction can mean two things:

* Allowing the client to verify that the access token has indeed been issued for him / her.
* Allowing the resource server verify that the received access token from a specific client has indeed been provided by that client.

My current believe is that the implicit grant flow is unsuitable for providing authentication functionality. =

Ciao
Hannes

On Jun 19, 2012, at 5:50 AM, John Bradley wrote:

I can put something together. =   

It is mostly a warning about the token substitution attack that any implicit flow is vulnerable to if used for authentication of the presenter.
Otherwise known as why audience restriction is a good thing.

John B.

On 2012-06-18, at 8:20 PM, Dick Hardt wrote:

John

Do you have suggested text per your suggestion below?

-- Dick

On Jun 18, 2012, at 2:04 PM, John Bradley wrote:

I blogged about this in the hypothetical several months ago. http://www.thread-safe.com/2012/01/problem-with-oauth-for-aut= hentication.html

Nov Matake and others built some tests and found quite a number of deployments vulnerable.
http://www.thread-safe.com/2012/02/more-on-oauth-implicit-f= low-application.html

The bottom line is that = OAuth has no explicit audience restriction for tokens,  hence accepting any token outside of the code = flow is subject to attack.

In general it is not a issue for authorization,  it is however a big issue = then there is a presumption that the presenter of a token that grants a client access to resource x is the "resource owner" of resource x, when it is possible that the presenter is any client who has ever had a access token for resource x.

We might want to include the why it is insecure in the security consideration,  otherwise people reading the below will likely ignore the advice as it seems on the surface a touch extreme.

There are certainly OAuth flows that allow you to do authentication safely,  just not all of them without additional precautions.

That is why openID Connect = has a audience restricted id_token similar to Facebook's signed request to allow the implicit flows to be safely used for authentication.

John B.




On 2012-06-18, at 4:19 PM, Shuo Chen (MSR) wrote:

Hi OAuth group,

This is regarding the = recent discussion about an implementation issue of some cloud services using OAuth for authentication.
Derek Atkins and Dick = Hardt suggested the possibility to discuss with the group a paragraph to add to the security considerations section.

Derek=92s suggestion:
=3D=3D=3D=3D =   =3D=3D=3D  =3D=3D=3D  =3D=3D=3D
Perhaps you could boil it down to a paragraph
or two for addition to the security considerations section that basically says
"beware of = implementing it *this* way because it leads to *that* attack vector", etc.
=3D=3D=3D=3D =   =3D=3D=3D  =3D=3D=3D  =3D=3D=3D


Here is out suggested = text:
=3D=3D=3D=3D =   =3D=3D=3D  =3D=3D=3D  =3D=3D=3D
It has been observed that = in multiple occasions that the server-side
authentication logic takes an access token from the client, then
queries the user's profile data from the IdP in order to
"authenticate" the user. This implementation must be forbidden. It
will allow an untrusted = app running on a victim=92s client device to
work with an attacker=92s device to sign into the victim=92s account on the server side.
=3D=3D=3D=3D =   =3D=3D=3D  =3D=3D=3D  =3D=3D=3D


Thank you.
-Shuo
p.s. below is the email thread giving a better context of the = discussion.


-----Original = Message-----
From: Derek Atkins [mailto:derek@ihtfp.com]
Sent: Monday, June 18, 2012 11:25 AM
To: Shuo Chen (MSR)
Cc: Hannes Tschofenig; = rui wang; Stephen Farrell; Yuchen Zhou; Derek
Atkins; Dick Hardt
Subject: Re: [OAUTH-WG] web sso study...

Hi,

"Shuo Chen (MSR)" <shuochen@microsoft.com> writes:

Hi Hannes, Derek and Stephen,

Thank you for your replies.

First, let me ask whether it is OK if I share your post with the
OAuth WG

Yes, please feel free = to share it.

Second, could you describe the attack in more details to = me?

Let's consider the mobile+cloud scenario for concreteness (although
some other scenarios = are also applicable). The attack steps are the
following: suppose Alice's tablet runs a Windows 8 Metro app written
by attacker Bob. This app is able to request and obtain an = access
token from the IdP (associated with Alice). The app can then send the
access token to Bob's own tablet. Note that there is no security
problem up to this point. However the real problem is that some cloud
services use the = access token to query the user's profile data = from
the IdP in order to "authenticate" the user. In this case, = Bob's
tablet will be able to sign into the cloud service as Alice. We = have
confirmed that the = cloud services for Soluto Metro App, Givit Metro
App and EuroCup2012 Metro App make this mistake. These are apps = in
the official Windows 8 App Store. We actually sampled only a small portion of the available apps, but believe this is a vulnerability pattern.

We don=92t think there = is anything wrong in the OAuth spec. It is
developers who didn=92t comprehensively understand the usage of = the
access token. In the meanwhile, this vulnerability pattern is not explicitly excluded by the spec.
More importantly, it = has been seen in the wild.

[from Derek's email] Perhaps you could boil it down to a paragraph
or two for
addition to the = security considerations section that basically says
"beware of = implementing it *this* way because it leads to *that* attack vector", etc.

This is a great idea. = I think that although it is difficult to
anticipate in general all kinds of incomprehensive understandings = of
average developers, it is very worthwhile to take any common = existing
vulnerability pattern = as a precious feedback to improve the
specification text. In this case, since we have already seen this
vulnerability pattern = on multiple services in the wild, certainly = we
should be explicit = about it in the security considerations section.

Our suggested = text:

It has been observed that in multiple occasions that the server-side
authentication logic takes an access token from the client, = then
queries the user's profile data from the IdP in order to
"authenticate" the = user. This implementation must be forbidden. It
will allow an = untrusted app running on a victim=92s client device = to
work with an = attacker=92s device to sign into the victim=92s account on the server side.

Any questions or suggestions?

Could you please send = this to the oauth@ietf.org mailing list?

Thanks a lot.

-Shuo

-derek

-----Original Message-----
From: Hannes = Tschofenig [mailto:Hannes.Tschofenig@gmx.net= ]
Sent: Friday, June 15, 2012 11:36 AM
To: rui wang
Cc: Hannes Tschofenig; Stephen Farrell; Shuo Chen (MSR); Yuchen = Zhou;
Derek Atkins
Subject: Re: = [OAUTH-WG] web sso study...

Hi Rui,

let me independently respond (in addition to the previous = responses
you had already = gotten).

First, let me ask whether it is OK if I share your post with = the
OAuth WG since it is more detailed than the one you distributed on the list mid April.

Second, could you describe the attack in more details to me? What I
would like to better understand whether this the raised issue is = a
problem with one of = our specifications, with a specific
implementation of the IETF OAuth specifications, a problem with other
OAuth related work (Facebook, as you know, implements far more than
just the IETF OAuth specifications), a violation of the IETF = OAuth
specification in the = way how the Websites use OAuth, whether this = is
a configuration = related aspect, or an aspect we already documented in the threats document.

The reason why I am so specific is to know where to put text to
address this issue or whether this is even an issue beyond the = IETF
OAuth working group = and needs to be tackled somewhere else.

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



= --Apple-Mail=_52D110EC-F11B-43B1-8280-E39A51E283ED-- --Apple-Mail=_746DF497-8603-4970-8284-A57BB7EF6F7F Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw 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+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDYy MzE4NTQ0NFowIwYJKoZIhvcNAQkEMRYEFOaMptU7/lXH2MuGS14CnuOJeZxzMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB ABEZW/LBkjRcA8EuYl4cBv9MUZH9OPosUq6IpnJtq2vgTonxt18JNLQaNIZYsQ2tLIOfRsfoexYg BbKmAFvwSH+xL/AuviN2um6jfZDZTnxUXBksSjyFa0Z9LiNv+OquWAYCCb91ka3UprQSr+x9Uu/o wLXLEhflYjtQlbFPA7U7o35+p2K2vftl25zInXeOiymcMI10IQcrEgU2f+zNYHSFF0ZeUvnfXPBE wnWOMERGe6iKLq6NnWVRYLoxVrc1HsQIlxXCSX0SR9/BCFtRx9h8GktFCyx/qJcwqlRO4ZI3F+Pr R69wOFJ8AapQcvA/ZWOyjIxjGo2ZUT4SFQIYitQAAAAAAAA= --Apple-Mail=_746DF497-8603-4970-8284-A57BB7EF6F7F-- From dick.hardt@gmail.com Sat Jun 23 20:14:58 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9339E21F86B9 for ; Sat, 23 Jun 2012 20:14:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.398 X-Spam-Level: X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_65=0.6, 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 rpUusvld0pzp for ; Sat, 23 Jun 2012 20:14:55 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0599B21F86B5 for ; Sat, 23 Jun 2012 20:14:54 -0700 (PDT) Received: by dacx6 with SMTP id x6so3925276dac.31 for ; Sat, 23 Jun 2012 20:14:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=AJBEkjCCaLAONel4AOmhHYDyMuX51NGHomvuEOSK2+s=; b=QvOu12V8ivwt8eN+I/b0pFCRLh607Li6mj4Uf6EuGKuLlenabuAnvdmKWUh7j4DCCA xDPTsWBmHhbZHkdKaICSwXATnjN59hwTuFGG8eCT9y5c6kNtFwXlRNl+YzhoSQv8EgL4 ICw8Wr3fGIkJgVMfiS0q1PFbwUAzIlHXTnZxn8PIGYbwijGBVicRFUvRYQ1smq12B1AI HzRu7mXT0dP3Pf5GwzTxrZk6I6wtBXs5y+ptQpZpDiuCxiqwizNgXUIVk/7b5Vy0NGKt BNhKXTWvX3b2SmYpT+LNrn52I7PHIT/JToT91H1kntUgn3HN+VNj4HGhNCGtn9OfcgJD s3DA== Received: by 10.68.225.101 with SMTP id rj5mr25844084pbc.103.1340507694511; Sat, 23 Jun 2012 20:14:54 -0700 (PDT) Received: from [10.0.0.4] (c-24-5-69-173.hsd1.ca.comcast.net. [24.5.69.173]) by mx.google.com with ESMTPS id tq4sm4065588pbc.11.2012.06.23.20.14.51 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 23 Jun 2012 20:14:52 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_12FFBE21-87A0-4CA6-BC67-DF0AC179DDDE" From: Dick Hardt In-Reply-To: <7F9928C8-9B11-4F3B-93A0-2469403F6569@ve7jtb.com> Date: Sat, 23 Jun 2012 20:14:50 -0700 Message-Id: References: <854774286EF8A240BACC342973A86EAC016693D6@BL2PRD0310MB387.namprd03.prod.outlook.com> <484A13D0-7C9A-42CC-BB94-3657741834DE@ve7jtb.com> <82D95BA2-1697-4441-BBB3-B2AE480DC39E@gmail.com> <4FE609C6.9020902@lodderstedt.net> <7F9928C8-9B11-4F3B-93A0-2469403F6569@ve7jtb.com> To: John Bradley X-Mailer: Apple Mail (2.1278) Cc: rui wang , Yuchen Zhou , "Shuo Chen \(MSR\)" , Derek Atkins , "oauth@ietf.org" Subject: Re: [OAUTH-WG] proposal of a paragraph to add to the security considerations section X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 03:14:58 -0000 --Apple-Mail=_12FFBE21-87A0-4CA6-BC67-DF0AC179DDDE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Would someone enlighten me on why the implicit flow is needed? Is it the = extra round trip? If so, I think that would be useful to call out both = the advantages and disadvantages in the spec. (I did not realize this = flow was in OAuth -- it was not in WRAP because of the security issue) -- Dick On Jun 23, 2012, at 11:54 AM, John Bradley wrote: > Yes it is probably best to keep it short in the main spec, but go into = more detail in the security document. >=20 > OAuth is fine as it is. If you use OAuth as part of another protocol = that protocol should be taking responsibility for it's own security = considerations and not assuming that OAuth will cover everything you are = doing. >=20 > Like it or not once you do federated authentication with OAuth you = have created a different protocol that needs different security = considerations. >=20 > We all sort of know that, the problem is that some people confuse = authentication and authorization as the same thing, so it is worth point = ing out. >=20 > John B. >=20 > On 2012-06-23, at 2:24 PM, Torsten Lodderstedt wrote: >=20 >> Hi John, >>=20 >> I fully agree with your assessment. This attack utilizes the fact = that some clients rely on the result of a resource server request to = login an user. It is not an attack on the OAuth protocol. And even if a = similar attack on authorization codes will happen to fail for = confidential clients does not mean OAuth is supposed to solve this = problem. >>=20 >> We nevertheless should mention it in the security considerations = section. To make things simple, I suggest to describe and ban this = anti-pattern _in general_ in the security consideration section (similar = to Shuo's initial proposal but more generalized). Additionally, the text = should recommend to use an appropriate technique for id providing such = as OpenID or SAML. >>=20 >> We also could add a detailed analaysis to the security document. >>=20 >> best regards, >> Torsten. >>=20 >>=20 >> Am 21.06.2012 15:47, schrieb John Bradley: >>> Hi Hannes, >>>=20 >>> MAC tokens protect resources against token leakage to third parties. = That is useful but a different threat. =20 >>>=20 >>> The easiest way to get a access token for someone is to have them = log into your site. =20 >>>=20 >>> If you can do that the token type makes no difference unless we move = to a asymmetric holder of key token (different discussion). >>>=20 >>> The bad client gets the access MAC token and token secret and can re = use it just as it would a bearer token. >>>=20 >>> The origin of the post was a contention by someone at Facebook that = profiling OAuth 2.0 on its own is sufficient to produce an = Authentication protocol. >>>=20 >>> I was trying to point out that OAuth 2 without any extensions, only = profiling is difficult to impossible to use for authentication as the = attack surface and security considerations are different. >>>=20 >>> As it turned out Facebook had extended OAuth 2 with signed requests = and token introspection techniques to address these issues for = themselves. =20 >>>=20 >>> The problem as it turned out was that individual apps and app = frameworks like the iOS one made some bad mistakes, by not using the = perhaps under documented extensions. >>>=20 >>> The problem is not unique to Facebook in any way they are just a = convenient example. >>>=20 >>> Oauth 2 is not surprisingly mostly about protecting the resource. =20= >>>=20 >>> Authentication is about protecting the client. >>>=20 >>> Audience restriction from openID 2, SAML, WS* etc prevents replay = of tokens issued to one RP/SP at another. =20 >>> That is sort of authentication protocol threat number 1. >>>=20 >>> OAuth has no way to do that with access tokens. >>>=20 >>> It can however do it with "code" if the client is confidential. >>>=20 >>> So my recommendation is that without extensions to OAuth like = structured tokens (signed_request, id_token) or token introspection = endpoints like=20 >>> Facebook ( https://graph.facebook.com/app?access_token=3D[The Access = Token]), there is no safe way to use an implicit flow for = authentication. >>> A code flow where a native app exchanges code for the access token = and then passes the access token back to it's server is also vulnerable = (lots of this in circulation I understand) >>>=20 >>> The only safe flow (without extensions) is the code flow where the = client is confidential and the code is directly exchanged for the access = token. >>> This also requires the definition of a identity API that is = protected by the access token, and out of scope for OAuth. >>>=20 >>> So at the end of the day the rational conclusion is that OAuth 2 is = a authorization protocol. =20 >>> It may be used by Authentication protocols, but it is up to other = specs to define the security considerations for that. >>>=20 >>> That however doesn't remove the need to mention the token = substitution attack that non confidential clients are subject to, do to = there being no other mechanism for the client to know who the token was = issued to. >>>=20 >>> John B. >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> On 2012-06-21, at 5:27 AM, Hannes Tschofenig wrote: >>>=20 >>>> Hi John,=20 >>>>=20 >>>> I read through your blog post. I am not sure whether I can entirely = agree with your separation between authentication and authorization. I = believe the core issue here is that=20 >>>>=20 >>>> * anyone who has the token will get access to whatever the token = entitles him or her to do (unless there are restrictions in the token) >>>>=20 >>>> * some attributes are different than others. With authentication = you typically associate that the process took place recently (i.e., it = is fresh) while other attributes do not require the user (as resource = owner) to actively participate in the exchange and the same level of = freshness is not implied. For authentication in a three party protocol = to be useful the three parties have to participate (see = http://tools.ietf.org/id/draft-tschofenig-oauth-signature-thoughts-00.txt)= .=20 >>>>=20 >>>> I understand that one wants to avoid having tokens passed around = from one application to the other one, as it is happening here.=20 >>>>=20 >>>> I remember having some of these discussions with Eran a long time = ago. He anticipated that implementers will not put any constraints in = the tokens and hence they will be misused. This serves as an argument = for him to propose the MAC token specification.=20 >>>>=20 >>>> I proposed text for the security consideration section of the = bearer document a while ago and it even talks about audience restriction = as a recommendation.=20 >>>>=20 >>>> There are two problems with the audience restriction:=20 >>>>=20 >>>> 1) There is no mandatory token format defined nor do we mandate = token content either. Hence we do not strongly require anything = specifically to be put into the tokens.=20 >>>>=20 >>>> 2) In the implicit grant flow the client isn't authenticated and = hence what do you want to put into a token as an audience restriction?=20= >>>>=20 >>>> Finally, I think that the "audience restriction" terminology is a = bit fuzzy for this discussion either.=20 >>>> Audience restriction can mean two things: >>>>=20 >>>> * Allowing the client to verify that the access token has indeed = been issued for him / her.=20 >>>> * Allowing the resource server verify that the received access = token from a specific client has indeed been provided by that client.=20 >>>>=20 >>>> My current believe is that the implicit grant flow is unsuitable = for providing authentication functionality.=20 >>>>=20 >>>> Ciao >>>> Hannes >>>>=20 >>>> On Jun 19, 2012, at 5:50 AM, John Bradley wrote: >>>>=20 >>>>> I can put something together. =20 >>>>>=20 >>>>> It is mostly a warning about the token substitution attack that = any implicit flow is vulnerable to if used for authentication of the = presenter. >>>>> Otherwise known as why audience restriction is a good thing. >>>>>=20 >>>>> John B. >>>>>=20 >>>>> On 2012-06-18, at 8:20 PM, Dick Hardt wrote: >>>>>=20 >>>>>> John >>>>>>=20 >>>>>> Do you have suggested text per your suggestion below? >>>>>>=20 >>>>>> -- Dick >>>>>>=20 >>>>>> On Jun 18, 2012, at 2:04 PM, John Bradley wrote: >>>>>>=20 >>>>>>> I blogged about this in the hypothetical several months ago. = http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.h= tml >>>>>>>=20 >>>>>>> Nov Matake and others built some tests and found quite a number = of deployments vulnerable.=20 >>>>>>> = http://www.thread-safe.com/2012/02/more-on-oauth-implicit-flow-application= .html >>>>>>>=20 >>>>>>> The bottom line is that OAuth has no explicit audience = restriction for tokens, hence accepting any token outside of the code = flow is subject to attack. >>>>>>>=20 >>>>>>> In general it is not a issue for authorization, it is however a = big issue then there is a presumption that the presenter of a token that = grants a client access to resource x is the "resource owner" of resource = x, when it is possible that the presenter is any client who has ever had = a access token for resource x. >>>>>>>=20 >>>>>>> We might want to include the why it is insecure in the security = consideration, otherwise people reading the below will likely ignore = the advice as it seems on the surface a touch extreme. >>>>>>>=20 >>>>>>> There are certainly OAuth flows that allow you to do = authentication safely, just not all of them without additional = precautions. >>>>>>>=20 >>>>>>> That is why openID Connect has a audience restricted id_token = similar to Facebook's signed request to allow the implicit flows to be = safely used for authentication. >>>>>>>=20 >>>>>>> John B. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> On 2012-06-18, at 4:19 PM, Shuo Chen (MSR) wrote: >>>>>>>=20 >>>>>>>> Hi OAuth group, >>>>>>>>=20 >>>>>>>> This is regarding the recent discussion about an implementation = issue of some cloud services using OAuth for authentication. >>>>>>>> Derek Atkins and Dick Hardt suggested the possibility to = discuss with the group a paragraph to add to the security considerations = section. >>>>>>>>=20 >>>>>>>> Derek=92s suggestion: >>>>>>>> =3D=3D=3D=3D =3D=3D=3D =3D=3D=3D =3D=3D=3D >>>>>>>>>> Perhaps you could boil it down to a paragraph >>>>>>>>>> or two for addition to the security considerations section = that basically says >>>>>>>>>> "beware of implementing it *this* way because it leads to = *that* attack vector", etc. >>>>>>>> =3D=3D=3D=3D =3D=3D=3D =3D=3D=3D =3D=3D=3D >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Here is out suggested text: >>>>>>>> =3D=3D=3D=3D =3D=3D=3D =3D=3D=3D =3D=3D=3D >>>>>>>> It has been observed that in multiple occasions that the = server-side >>>>>>>> authentication logic takes an access token from the client, = then >>>>>>>> queries the user's profile data from the IdP in order to >>>>>>>> "authenticate" the user. This implementation must be forbidden. = It >>>>>>>> will allow an untrusted app running on a victim=92s client = device to >>>>>>>> work with an attacker=92s device to sign into the victim=92s = account on the server side. >>>>>>>> =3D=3D=3D=3D =3D=3D=3D =3D=3D=3D =3D=3D=3D >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Thank you. >>>>>>>> -Shuo >>>>>>>> p.s. below is the email thread giving a better context of the = discussion. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: Derek Atkins [mailto:derek@ihtfp.com] >>>>>>>>> Sent: Monday, June 18, 2012 11:25 AM >>>>>>>>> To: Shuo Chen (MSR) >>>>>>>>> Cc: Hannes Tschofenig; rui wang; Stephen Farrell; Yuchen Zhou; = Derek >>>>>>>>> Atkins; Dick Hardt >>>>>>>>> Subject: Re: [OAUTH-WG] web sso study... >>>>>>>>>=20 >>>>>>>>> Hi, >>>>>>>>>=20 >>>>>>>>> "Shuo Chen (MSR)" writes: >>>>>>>>>=20 >>>>>>>>>> Hi Hannes, Derek and Stephen, >>>>>>>>>>=20 >>>>>>>>>> Thank you for your replies. >>>>>>>>>>=20 >>>>>>>>>>> First, let me ask whether it is OK if I share your post with = the >>>>>>>>>>> OAuth WG >>>>>>>>>>=20 >>>>>>>>>> Yes, please feel free to share it. >>>>>>>>>>=20 >>>>>>>>>>> Second, could you describe the attack in more details to me? >>>>>>>>>>=20 >>>>>>>>>> Let's consider the mobile+cloud scenario for concreteness = (although >>>>>>>>>> some other scenarios are also applicable). The attack steps = are the >>>>>>>>>> following: suppose Alice's tablet runs a Windows 8 Metro app = written >>>>>>>>>> by attacker Bob. This app is able to request and obtain an = access >>>>>>>>>> token from the IdP (associated with Alice). The app can then = send the >>>>>>>>>> access token to Bob's own tablet. Note that there is no = security >>>>>>>>>> problem up to this point. However the real problem is that = some cloud >>>>>>>>>> services use the access token to query the user's profile = data from >>>>>>>>>> the IdP in order to "authenticate" the user. In this case, = Bob's >>>>>>>>>> tablet will be able to sign into the cloud service as Alice. = We have >>>>>>>>>> confirmed that the cloud services for Soluto Metro App, Givit = Metro >>>>>>>>>> App and EuroCup2012 Metro App make this mistake. These are = apps in >>>>>>>>>> the official Windows 8 App Store. We actually sampled only a = small portion of the available apps, but believe this is a vulnerability = pattern. >>>>>>>>>>=20 >>>>>>>>>> We don=92t think there is anything wrong in the OAuth spec. = It is >>>>>>>>>> developers who didn=92t comprehensively understand the usage = of the >>>>>>>>>> access token. In the meanwhile, this vulnerability pattern is = not explicitly excluded by the spec. >>>>>>>>>> More importantly, it has been seen in the wild. >>>>>>>>>>=20 >>>>>>>>>>> [from Derek's email] Perhaps you could boil it down to a = paragraph >>>>>>>>>>> or two for >>>>>>>>>> addition to the security considerations section that = basically says >>>>>>>>>> "beware of implementing it *this* way because it leads to = *that* attack vector", etc. >>>>>>>>>>=20 >>>>>>>>>> This is a great idea. I think that although it is difficult = to >>>>>>>>>> anticipate in general all kinds of incomprehensive = understandings of >>>>>>>>>> average developers, it is very worthwhile to take any common = existing >>>>>>>>>> vulnerability pattern as a precious feedback to improve the >>>>>>>>>> specification text. In this case, since we have already seen = this >>>>>>>>>> vulnerability pattern on multiple services in the wild, = certainly we >>>>>>>>>> should be explicit about it in the security considerations = section. >>>>>>>>>>=20 >>>>>>>>>> Our suggested text: >>>>>>>>>>=20 >>>>>>>>>> It has been observed that in multiple occasions that the = server-side >>>>>>>>>> authentication logic takes an access token from the client, = then >>>>>>>>>> queries the user's profile data from the IdP in order to >>>>>>>>>> "authenticate" the user. This implementation must be = forbidden. It >>>>>>>>>> will allow an untrusted app running on a victim=92s client = device to >>>>>>>>>> work with an attacker=92s device to sign into the victim=92s = account on the server side. >>>>>>>>>>=20 >>>>>>>>>> Any questions or suggestions? >>>>>>>>>=20 >>>>>>>>> Could you please send this to the oauth@ietf.org mailing list? >>>>>>>>>=20 >>>>>>>>>> Thanks a lot. >>>>>>>>>>=20 >>>>>>>>>> -Shuo >>>>>>>>>=20 >>>>>>>>> -derek >>>>>>>>>=20 >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>>>>>>> Sent: Friday, June 15, 2012 11:36 AM >>>>>>>>>> To: rui wang >>>>>>>>>> Cc: Hannes Tschofenig; Stephen Farrell; Shuo Chen (MSR); = Yuchen Zhou; >>>>>>>>>> Derek Atkins >>>>>>>>>> Subject: Re: [OAUTH-WG] web sso study... >>>>>>>>>>=20 >>>>>>>>>> Hi Rui, >>>>>>>>>>=20 >>>>>>>>>> let me independently respond (in addition to the previous = responses >>>>>>>>>> you had already gotten). >>>>>>>>>>=20 >>>>>>>>>> First, let me ask whether it is OK if I share your post with = the >>>>>>>>>> OAuth WG since it is more detailed than the one you = distributed on the list mid April. >>>>>>>>>>=20 >>>>>>>>>> Second, could you describe the attack in more details to me? = What I >>>>>>>>>> would like to better understand whether this the raised issue = is a >>>>>>>>>> problem with one of our specifications, with a specific >>>>>>>>>> implementation of the IETF OAuth specifications, a problem = with other >>>>>>>>>> OAuth related work (Facebook, as you know, implements far = more than >>>>>>>>>> just the IETF OAuth specifications), a violation of the IETF = OAuth >>>>>>>>>> specification in the way how the Websites use OAuth, whether = this is >>>>>>>>>> a configuration related aspect, or an aspect we already = documented in the threats document. >>>>>>>>>>=20 >>>>>>>>>> The reason why I am so specific is to know where to put text = to >>>>>>>>>> address this issue or whether this is even an issue beyond = the IETF >>>>>>>>>> OAuth working group and needs to be tackled somewhere else. >>>>>>>>>>=20 >>>>>>>>>> Ciao >>>>>>>>>>=20 >>>>>>>>>> Hannes >>>>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_12FFBE21-87A0-4CA6-BC67-DF0AC179DDDE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Yes it is probably best to keep = it short in the main spec, but go into more detail in the security = document.

OAuth is fine as it is.  If you use = OAuth as part of another protocol that protocol should be taking = responsibility for it's own security considerations and not assuming = that OAuth will cover everything you are = doing.

Like it or not once you do federated = authentication with OAuth you have created a different protocol that = needs different security considerations.

We all = sort of know that, the problem is that some people confuse = authentication and authorization as the same thing, so it is worth point = ing out.

John B.

On = 2012-06-23, at 2:24 PM, Torsten Lodderstedt wrote:

=20 =20
Hi John,

I fully agree with your assessment. This attack utilizes the fact that some clients rely on the result of a resource server request to login an user. It is not an attack on the OAuth protocol. And even if a similar attack on authorization codes will happen to fail for confidential clients does not mean OAuth is supposed to solve this problem.

We nevertheless should mention it in the security considerations section. To make things simple, I suggest to describe and ban this anti-pattern _in general_ in the security consideration section (similar to Shuo's initial proposal but more generalized). Additionally, the text should recommend to use an appropriate technique for id providing such as OpenID or SAML.

We also could add a detailed analaysis to the security document.

best regards,
Torsten.


Am 21.06.2012 15:47, schrieb John Bradley:
Hi Hannes,

MAC tokens protect resources against token leakage to third parties.  That is useful but a different threat. =  

The easiest way to get a access token for someone is to have them log into your site.   

If you can do that the token type makes no difference unless we move to a asymmetric holder of key token (different discussion).

The bad client gets the access MAC token and token secret and can re use it just as it would a bearer token.

The origin of the post was a contention by someone at Facebook that profiling OAuth 2.0 on its own is sufficient to produce an Authentication protocol.

I was trying to point out that OAuth 2 without any extensions, only profiling is difficult to impossible to use for authentication as the attack surface and security considerations are different.

As it turned out Facebook had extended OAuth 2 with signed requests and token introspection techniques to address these issues for themselves.   

The problem as it turned out was that individual apps and  app frameworks like the iOS one made some bad mistakes, by = not using the perhaps under documented extensions.

The problem is not unique to Facebook in any way they are just a convenient example.

Oauth 2  is not surprisingly mostly about = protecting the resource.  

Authentication is about protecting the client.

Audience restriction from openID 2, SAML,  WS* etc = prevents replay of tokens issued to one RP/SP at another.  
That is sort of authentication protocol threat number = 1.

OAuth has no way to do that with access tokens.

It can however do it with "code" if the client is confidential.

So my recommendation is that without extensions to OAuth like structured tokens (signed_request, id_token) or token introspection endpoints like 
Facebook ( https://graph.= facebook.com/app?access_token=3D[The Access Token]), there is no safe way to use an implicit flow for authentication.
A code flow where a native app exchanges code for the access token and then passes the access token back to it's server is also vulnerable (lots of this in circulation I = understand)

The only safe flow (without extensions) is the code flow where the client is confidential and the code is directly exchanged for the access token.
This also requires the definition of a identity API that is protected by the access token, and out of scope for = OAuth.

So at the end of the day the rational conclusion is that OAuth 2 is a authorization protocol.   
It may be used by Authentication protocols, but it is up to other specs to define the security considerations for = that.

That however doesn't remove the need to mention the token substitution attack that non confidential clients are subject to, do to there being no other mechanism for the client to know who the token was issued to.

John B.





On 2012-06-21, at 5:27 AM, Hannes Tschofenig wrote:

Hi John,

I read through your blog post. I am not sure whether I can entirely agree with your separation between authentication and authorization. I believe the core issue here is that =

* anyone who has the token will get access to whatever the token entitles him or her to do (unless there are restrictions in the token)

* some attributes are different than others. With authentication you typically associate that the process took place recently (i.e., it is fresh) while other attributes do not require the user (as resource owner) to actively participate in the exchange and the same level of freshness is not implied.  For authentication in a = three party protocol to be useful the three parties have to participate (see http://tools.ietf.org/id/draft-tschofenig-oauth-signature-thought= s-00.txt).

I understand that one wants to avoid having tokens passed around from one application to the other one, as it is happening here.

I remember having some of these discussions with Eran a long time ago. He anticipated that implementers will not put any constraints in the tokens and hence they will be misused. This serves as an argument for him to propose the MAC token specification.

I proposed text for the security consideration section of the bearer document a while ago and it even talks about audience restriction as a recommendation.

There are two problems with the audience restriction:

1) There is no mandatory token format defined nor do we mandate token content either. Hence we do not strongly require anything specifically to be put into the tokens. =

2) In the implicit grant flow the client isn't authenticated and hence what do you want to put into a token as an audience restriction?

Finally, I think that the "audience restriction" terminology is a bit fuzzy for this discussion either. =
Audience restriction can mean two things:

* Allowing the client to verify that the access token has indeed been issued for him / her.
* Allowing the resource server verify that the received access token from a specific client has indeed been provided by that client.

My current believe is that the implicit grant flow is unsuitable for providing authentication functionality. =

Ciao
Hannes

On Jun 19, 2012, at 5:50 AM, John Bradley wrote:

I can put something together. =   

It is mostly a warning about the token substitution attack that any implicit flow is vulnerable to if used for authentication of the presenter.
Otherwise known as why audience restriction is a good thing.

John B.

On 2012-06-18, at 8:20 PM, Dick Hardt wrote:

John

Do you have suggested text per your suggestion below?

-- Dick

On Jun 18, 2012, at 2:04 PM, John Bradley wrote:

I blogged about this in the hypothetical several months ago. http://www.thread-safe.com/2012/01/problem-with-oauth-for-aut= hentication.html

Nov Matake and others built some tests and found quite a number of deployments vulnerable.
http://www.thread-safe.com/2012/02/more-on-oauth-implicit-f= low-application.html

The bottom line is that = OAuth has no explicit audience restriction for tokens,  hence accepting any token outside of the code = flow is subject to attack.

In general it is not a issue for authorization,  it is however a big issue = then there is a presumption that the presenter of a token that grants a client access to resource x is the "resource owner" of resource x, when it is possible that the presenter is any client who has ever had a access token for resource x.

We might want to include the why it is insecure in the security consideration,  otherwise people reading the below will likely ignore the advice as it seems on the surface a touch extreme.

There are certainly OAuth flows that allow you to do authentication safely,  just not all of them without additional precautions.

That is why openID Connect = has a audience restricted id_token similar to Facebook's signed request to allow the implicit flows to be safely used for authentication.

John B.




On 2012-06-18, at 4:19 PM, Shuo Chen (MSR) wrote:

Hi OAuth group,

This is regarding the = recent discussion about an implementation issue of some cloud services using OAuth for authentication.
Derek Atkins and Dick = Hardt suggested the possibility to discuss with the group a paragraph to add to the security considerations section.

Derek=92s suggestion:
=3D=3D=3D=3D =   =3D=3D=3D  =3D=3D=3D  =3D=3D=3D
Perhaps you could boil it down to a paragraph
or two for addition to the security considerations section that basically says
"beware of = implementing it *this* way because it leads to *that* attack vector", etc.
=3D=3D=3D=3D =   =3D=3D=3D  =3D=3D=3D  =3D=3D=3D


Here is out suggested = text:
=3D=3D=3D=3D =   =3D=3D=3D  =3D=3D=3D  =3D=3D=3D
It has been observed that = in multiple occasions that the server-side
authentication logic takes an access token from the client, then
queries the user's profile data from the IdP in order to
"authenticate" the user. This implementation must be forbidden. It
will allow an untrusted = app running on a victim=92s client device to
work with an attacker=92s device to sign into the victim=92s account on the server side.
=3D=3D=3D=3D =   =3D=3D=3D  =3D=3D=3D  =3D=3D=3D


Thank you.
-Shuo
p.s. below is the email thread giving a better context of the = discussion.


-----Original = Message-----
From: Derek Atkins [mailto:derek@ihtfp.com]
Sent: Monday, June 18, 2012 11:25 AM
To: Shuo Chen (MSR)
Cc: Hannes Tschofenig; = rui wang; Stephen Farrell; Yuchen Zhou; Derek
Atkins; Dick Hardt
Subject: Re: [OAUTH-WG] web sso study...

Hi,

"Shuo Chen (MSR)" <shuochen@microsoft.com> writes:

Hi Hannes, Derek and Stephen,

Thank you for your replies.

First, let me ask whether it is OK if I share your post with the
OAuth WG

Yes, please feel free = to share it.

Second, could you describe the attack in more details to = me?

Let's consider the mobile+cloud scenario for concreteness (although
some other scenarios = are also applicable). The attack steps are the
following: suppose Alice's tablet runs a Windows 8 Metro app written
by attacker Bob. This app is able to request and obtain an = access
token from the IdP (associated with Alice). The app can then send the
access token to Bob's own tablet. Note that there is no security
problem up to this point. However the real problem is that some cloud
services use the = access token to query the user's profile data = from
the IdP in order to "authenticate" the user. In this case, = Bob's
tablet will be able to sign into the cloud service as Alice. We = have
confirmed that the = cloud services for Soluto Metro App, Givit Metro
App and EuroCup2012 Metro App make this mistake. These are apps = in
the official Windows 8 App Store. We actually sampled only a small portion of the available apps, but believe this is a vulnerability pattern.

We don=92t think there = is anything wrong in the OAuth spec. It is
developers who didn=92t comprehensively understand the usage of = the
access token. In the meanwhile, this vulnerability pattern is not explicitly excluded by the spec.
More importantly, it = has been seen in the wild.

[from Derek's email] Perhaps you could boil it down to a paragraph
or two for
addition to the = security considerations section that basically says
"beware of = implementing it *this* way because it leads to *that* attack vector", etc.

This is a great idea. = I think that although it is difficult to
anticipate in general all kinds of incomprehensive understandings = of
average developers, it is very worthwhile to take any common = existing
vulnerability pattern = as a precious feedback to improve the
specification text. In this case, since we have already seen this
vulnerability pattern = on multiple services in the wild, certainly = we
should be explicit = about it in the security considerations section.

Our suggested = text:

It has been observed that in multiple occasions that the server-side
authentication logic takes an access token from the client, = then
queries the user's profile data from the IdP in order to
"authenticate" the = user. This implementation must be forbidden. It
will allow an = untrusted app running on a victim=92s client device = to
work with an = attacker=92s device to sign into the victim=92s account on the server side.

Any questions or suggestions?

Could you please send = this to the oauth@ietf.org mailing list?

Thanks a lot.

-Shuo

-derek

-----Original Message-----
From: Hannes = Tschofenig [mailto:Hannes.Tschofenig@gmx.net= ]
Sent: Friday, June 15, 2012 11:36 AM
To: rui wang
Cc: Hannes Tschofenig; Stephen Farrell; Shuo Chen (MSR); Yuchen = Zhou;
Derek Atkins
Subject: Re: = [OAUTH-WG] web sso study...

Hi Rui,

let me independently respond (in addition to the previous = responses
you had already = gotten).

First, let me ask whether it is OK if I share your post with = the
OAuth WG since it is more detailed than the one you distributed on the list mid April.

Second, could you describe the attack in more details to me? What I
would like to better understand whether this the raised issue is = a
problem with one of = our specifications, with a specific
implementation of the IETF OAuth specifications, a problem with other
OAuth related work (Facebook, as you know, implements far more than
just the IETF OAuth specifications), a violation of the IETF = OAuth
specification in the = way how the Websites use OAuth, whether this = is
a configuration = related aspect, or an aspect we already documented in the threats document.

The reason why I am so specific is to know where to put text to
address this issue or whether this is even an issue beyond the = IETF
OAuth working group = and needs to be tackled somewhere else.

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


=

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

= --Apple-Mail=_12FFBE21-87A0-4CA6-BC67-DF0AC179DDDE-- From eran@hueniverse.com Sun Jun 24 00:19:34 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93A7621F867B for ; Sun, 24 Jun 2012 00:19:34 -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, J_CHICKENPOX_65=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 ZtQ5WKft7tCp for ; Sun, 24 Jun 2012 00:19:24 -0700 (PDT) Received: from p3plex2out02.prod.phx3.secureserver.net (p3plex2out02.prod.phx3.secureserver.net [184.168.131.14]) by ietfa.amsl.com (Postfix) with ESMTP id 3408D21F8669 for ; Sun, 24 Jun 2012 00:19:24 -0700 (PDT) Received: from P3PWEX2HT003.ex2.secureserver.net ([184.168.131.11]) by p3plex2out02.prod.phx3.secureserver.net with bizsmtp id S7KP1j0010EuLVk017KPa3; Sun, 24 Jun 2012 00:19:23 -0700 Received: from P3PWEX2MB008.ex2.secureserver.net ([169.254.8.66]) by P3PWEX2HT003.ex2.secureserver.net ([184.168.131.11]) with mapi id 14.02.0247.003; Sun, 24 Jun 2012 00:19:22 -0700 From: Eran Hammer To: Dick Hardt , John Bradley Thread-Topic: [OAUTH-WG] proposal of a paragraph to add to the security considerations section Thread-Index: AQHNUXHCGK+yJ6bYjkeNnemGwRp+D5cJQX0A///OfJA= Date: Sun, 24 Jun 2012 07:19:22 +0000 Message-ID: <0CBAEB56DDB3A140BA8E8C124C04ECA20107E583@P3PWEX2MB008.ex2.secureserver.net> References: <854774286EF8A240BACC342973A86EAC016693D6@BL2PRD0310MB387.namprd03.prod.outlook.com> <484A13D0-7C9A-42CC-BB94-3657741834DE@ve7jtb.com> <82D95BA2-1697-4441-BBB3-B2AE480DC39E@gmail.com> <4FE609C6.9020902@lodderstedt.net> <7F9928C8-9B11-4F3B-93A0-2469403F6569@ve7jtb.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [37.46.45.33] Content-Type: multipart/alternative; boundary="_000_0CBAEB56DDB3A140BA8E8C124C04ECA20107E583P3PWEX2MB008ex2_" MIME-Version: 1.0 Cc: Yuchen Zhou , Derek Atkins , "Shuo Chen \(MSR\)" , rui wang , "oauth@ietf.org" Subject: Re: [OAUTH-WG] proposal of a paragraph to add to the security considerations section X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 07:19:34 -0000 --_000_0CBAEB56DDB3A140BA8E8C124C04ECA20107E583P3PWEX2MB008ex2_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable You must be joking. Have you ever read the spec? It has been there from draft -00: http://tools.ietf.org/html/draft-ietf-oauth-v2-00#section-3.5.1 EH From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of D= ick Hardt Sent: Saturday, June 23, 2012 8:15 PM To: John Bradley Cc: rui wang; Yuchen Zhou; Shuo Chen (MSR); Derek Atkins; oauth@ietf.org Subject: Re: [OAUTH-WG] proposal of a paragraph to add to the security cons= iderations section Would someone enlighten me on why the implicit flow is needed? Is it the ex= tra round trip? If so, I think that would be useful to call out both the ad= vantages and disadvantages in the spec. (I did not realize this flow was in= OAuth -- it was not in WRAP because of the security issue) -- Dick On Jun 23, 2012, at 11:54 AM, John Bradley wrote: Yes it is probably best to keep it short in the main spec, but go into more= detail in the security document. OAuth is fine as it is. If you use OAuth as part of another protocol that = protocol should be taking responsibility for it's own security consideratio= ns and not assuming that OAuth will cover everything you are doing. Like it or not once you do federated authentication with OAuth you have cre= ated a different protocol that needs different security considerations. We all sort of know that, the problem is that some people confuse authentic= ation and authorization as the same thing, so it is worth point ing out. John B. On 2012-06-23, at 2:24 PM, Torsten Lodderstedt wrote: Hi John, I fully agree with your assessment. This attack utilizes the fact that some= clients rely on the result of a resource server request to login an user. = It is not an attack on the OAuth protocol. And even if a similar attack on = authorization codes will happen to fail for confidential clients does not m= ean OAuth is supposed to solve this problem. We nevertheless should mention it in the security considerations section. T= o make things simple, I suggest to describe and ban this anti-pattern _in g= eneral_ in the security consideration section (similar to Shuo's initial pr= oposal but more generalized). Additionally, the text should recommend to us= e an appropriate technique for id providing such as OpenID or SAML. We also could add a detailed analaysis to the security document. best regards, Torsten. Am 21.06.2012 15:47, schrieb John Bradley: Hi Hannes, MAC tokens protect resources against token leakage to third parties. That = is useful but a different threat. The easiest way to get a access token for someone is to have them log into = your site. If you can do that the token type makes no difference unless we move to a a= symmetric holder of key token (different discussion). The bad client gets the access MAC token and token secret and can re use it= just as it would a bearer token. The origin of the post was a contention by someone at Facebook that profili= ng OAuth 2.0 on its own is sufficient to produce an Authentication protocol= . I was trying to point out that OAuth 2 without any extensions, only profili= ng is difficult to impossible to use for authentication as the attack surfa= ce and security considerations are different. As it turned out Facebook had extended OAuth 2 with signed requests and tok= en introspection techniques to address these issues for themselves. The problem as it turned out was that individual apps and app frameworks l= ike the iOS one made some bad mistakes, by not using the perhaps under docu= mented extensions. The problem is not unique to Facebook in any way they are just a convenient= example. Oauth 2 is not surprisingly mostly about protecting the resource. Authentication is about protecting the client. Audience restriction from openID 2, SAML, WS* etc prevents replay of token= s issued to one RP/SP at another. That is sort of authentication protocol threat number 1. OAuth has no way to do that with access tokens. It can however do it with "code" if the client is confidential. So my recommendation is that without extensions to OAuth like structured to= kens (signed_request, id_token) or token introspection endpoints like Facebook ( https://graph.facebook.com/app?access_token=3D[The Access Token]), there is no safe w= ay to use an implicit flow for authentication. A code flow where a native app exchanges code for the access token and then= passes the access token back to it's server is also vulnerable (lots of th= is in circulation I understand) The only safe flow (without extensions) is the code flow where the client i= s confidential and the code is directly exchanged for the access token. This also requires the definition of a identity API that is protected by th= e access token, and out of scope for OAuth. So at the end of the day the rational conclusion is that OAuth 2 is a autho= rization protocol. It may be used by Authentication protocols, but it is up to other specs to = define the security considerations for that. That however doesn't remove the need to mention the token substitution atta= ck that non confidential clients are subject to, do to there being no other= mechanism for the client to know who the token was issued to. John B. On 2012-06-21, at 5:27 AM, Hannes Tschofenig wrote: Hi John, I read through your blog post. I am not sure whether I can entirely agree w= ith your separation between authentication and authorization. I believe the= core issue here is that * anyone who has the token will get access to whatever the token entitles h= im or her to do (unless there are restrictions in the token) * some attributes are different than others. With authentication you typica= lly associate that the process took place recently (i.e., it is fresh) whil= e other attributes do not require the user (as resource owner) to actively = participate in the exchange and the same level of freshness is not implied.= For authentication in a three party protocol to be useful the three parti= es have to participate (see http://tools.ietf.org/id/draft-tschofenig-oauth= -signature-thoughts-00.txt). I understand that one wants to avoid having tokens passed around from one a= pplication to the other one, as it is happening here. I remember having some of these discussions with Eran a long time ago. He a= nticipated that implementers will not put any constraints in the tokens and= hence they will be misused. This serves as an argument for him to propose = the MAC token specification. I proposed text for the security consideration section of the bearer docume= nt a while ago and it even talks about audience restriction as a recommenda= tion. There are two problems with the audience restriction: 1) There is no mandatory token format defined nor do we mandate token conte= nt either. Hence we do not strongly require anything specifically to be put= into the tokens. 2) In the implicit grant flow the client isn't authenticated and hence what= do you want to put into a token as an audience restriction? Finally, I think that the "audience restriction" terminology is a bit fuzzy= for this discussion either. Audience restriction can mean two things: * Allowing the client to verify that the access token has indeed been issue= d for him / her. * Allowing the resource server verify that the received access token from a= specific client has indeed been provided by that client. My current believe is that the implicit grant flow is unsuitable for provid= ing authentication functionality. Ciao Hannes On Jun 19, 2012, at 5:50 AM, John Bradley wrote: I can put something together. It is mostly a warning about the token substitution attack that any implici= t flow is vulnerable to if used for authentication of the presenter. Otherwise known as why audience restriction is a good thing. John B. On 2012-06-18, at 8:20 PM, Dick Hardt wrote: John Do you have suggested text per your suggestion below? -- Dick On Jun 18, 2012, at 2:04 PM, John Bradley wrote: I blogged about this in the hypothetical several months ago. http://www.thr= ead-safe.com/2012/01/problem-with-oauth-for-authentication.html Nov Matake and others built some tests and found quite a number of deployme= nts vulnerable. http://www.thread-safe.com/2012/02/more-on-oauth-implicit-flow-application.= html The bottom line is that OAuth has no explicit audience restriction for toke= ns, hence accepting any token outside of the code flow is subject to attac= k. In general it is not a issue for authorization, it is however a big issue = then there is a presumption that the presenter of a token that grants a cli= ent access to resource x is the "resource owner" of resource x, when it is = possible that the presenter is any client who has ever had a access token f= or resource x. We might want to include the why it is insecure in the security considerati= on, otherwise people reading the below will likely ignore the advice as it= seems on the surface a touch extreme. There are certainly OAuth flows that allow you to do authentication safely,= just not all of them without additional precautions. That is why openID Connect has a audience restricted id_token similar to Fa= cebook's signed request to allow the implicit flows to be safely used for a= uthentication. John B. On 2012-06-18, at 4:19 PM, Shuo Chen (MSR) wrote: Hi OAuth group, This is regarding the recent discussion about an implementation issue of so= me cloud services using OAuth for authentication. Derek Atkins and Dick Hardt suggested the possibility to discuss with the g= roup a paragraph to add to the security considerations section. Derek's suggestion: =3D=3D=3D=3D =3D=3D=3D =3D=3D=3D =3D=3D=3D Perhaps you could boil it down to a paragraph or two for addition to the security considerations section that basically s= ays "beware of implementing it *this* way because it leads to *that* attack vec= tor", etc. =3D=3D=3D=3D =3D=3D=3D =3D=3D=3D =3D=3D=3D Here is out suggested text: =3D=3D=3D=3D =3D=3D=3D =3D=3D=3D =3D=3D=3D It has been observed that in multiple occasions that the server-side authentication logic takes an access token from the client, then queries the user's profile data from the IdP in order to "authenticate" the user. This implementation must be forbidden. It will allow an untrusted app running on a victim's client device to work with an attacker's device to sign into the victim's account on the ser= ver side. =3D=3D=3D=3D =3D=3D=3D =3D=3D=3D =3D=3D=3D Thank you. -Shuo p.s. below is the email thread giving a better context of the discussion. -----Original Message----- From: Derek Atkins [mailto:derek@ihtfp.com] Sent: Monday, June 18, 2012 11:25 AM To: Shuo Chen (MSR) Cc: Hannes Tschofenig; rui wang; Stephen Farrell; Yuchen Zhou; Derek Atkins; Dick Hardt Subject: Re: [OAUTH-WG] web sso study... Hi, "Shuo Chen (MSR)" > w= rites: Hi Hannes, Derek and Stephen, Thank you for your replies. First, let me ask whether it is OK if I share your post with the OAuth WG Yes, please feel free to share it. Second, could you describe the attack in more details to me? Let's consider the mobile+cloud scenario for concreteness (although some other scenarios are also applicable). The attack steps are the following: suppose Alice's tablet runs a Windows 8 Metro app written by attacker Bob. This app is able to request and obtain an access token from the IdP (associated with Alice). The app can then send the access token to Bob's own tablet. Note that there is no security problem up to this point. However the real problem is that some cloud services use the access token to query the user's profile data from the IdP in order to "authenticate" the user. In this case, Bob's tablet will be able to sign into the cloud service as Alice. We have confirmed that the cloud services for Soluto Metro App, Givit Metro App and EuroCup2012 Metro App make this mistake. These are apps in the official Windows 8 App Store. We actually sampled only a small portion = of the available apps, but believe this is a vulnerability pattern. We don't think there is anything wrong in the OAuth spec. It is developers who didn't comprehensively understand the usage of the access token. In the meanwhile, this vulnerability pattern is not explicitl= y excluded by the spec. More importantly, it has been seen in the wild. [from Derek's email] Perhaps you could boil it down to a paragraph or two for addition to the security considerations section that basically says "beware of implementing it *this* way because it leads to *that* attack vec= tor", etc. This is a great idea. I think that although it is difficult to anticipate in general all kinds of incomprehensive understandings of average developers, it is very worthwhile to take any common existing vulnerability pattern as a precious feedback to improve the specification text. In this case, since we have already seen this vulnerability pattern on multiple services in the wild, certainly we should be explicit about it in the security considerations section. Our suggested text: It has been observed that in multiple occasions that the server-side authentication logic takes an access token from the client, then queries the user's profile data from the IdP in order to "authenticate" the user. This implementation must be forbidden. It will allow an untrusted app running on a victim's client device to work with an attacker's device to sign into the victim's account on the ser= ver side. Any questions or suggestions? Could you please send this to the oauth@ietf.org mai= ling list? Thanks a lot. -Shuo -derek -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] Sent: Friday, June 15, 2012 11:36 AM To: rui wang Cc: Hannes Tschofenig; Stephen Farrell; Shuo Chen (MSR); Yuchen Zhou; Derek Atkins Subject: Re: [OAUTH-WG] web sso study... Hi Rui, let me independently respond (in addition to the previous responses you had already gotten). First, let me ask whether it is OK if I share your post with the OAuth WG since it is more detailed than the one you distributed on the list= mid April. Second, could you describe the attack in more details to me? What I would like to better understand whether this the raised issue is a problem with one of our specifications, with a specific implementation of the IETF OAuth specifications, a problem with other OAuth related work (Facebook, as you know, implements far more than just the IETF OAuth specifications), a violation of the IETF OAuth specification in the way how the Websites use OAuth, whether this is a configuration related aspect, or an aspect we already documented in the t= hreats document. The reason why I am so specific is to know where to put text to address this issue or whether this is even an issue beyond the IETF OAuth working group and needs to be tackled somewhere else. 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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_0CBAEB56DDB3A140BA8E8C124C04ECA20107E583P3PWEX2MB008ex2_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

You must be joking. Have = you ever read the spec?

 <= /p>

It has been there from dr= aft -00:

 <= /p>

http://tools.ietf.org/ht= ml/draft-ietf-oauth-v2-00#section-3.5.1

 <= /p>

EH

 <= /p>

 <= /p>

From: oauth-bo= unces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Dick Hardt
Sent: Saturday, June 23, 2012 8:15 PM
To: John Bradley
Cc: rui wang; Yuchen Zhou; Shuo Chen (MSR); Derek Atkins; oauth@ietf= .org
Subject: Re: [OAUTH-WG] proposal of a paragraph to add to the securi= ty considerations section

 

Would someone enlighten me on why the implicit flow = is needed? Is it the extra round trip? If so, I think that would be useful = to call out both the advantages and disadvantages in the spec. (I did not r= ealize this flow was in OAuth -- it was not in WRAP because of the security issue)

 

-- Dick

 

On Jun 23, 2012, at 11:54 AM, John Bradley wrote:



Yes it is probably best to keep it short in the main= spec, but go into more detail in the security document.

 

OAuth is fine as it is.  If you use OAuth as pa= rt of another protocol that protocol should be taking responsibility for it= 's own security considerations and not assuming that OAuth will cover every= thing you are doing.

 

Like it or not once you do federated authentication = with OAuth you have created a different protocol that needs different secur= ity considerations.

 

We all sort of know that, the problem is that some p= eople confuse authentication and authorization as the same thing, so it is = worth point ing out.

 

John B.

 

On 2012-06-23, at 2:24 PM, Torsten Lodderstedt wrote= :



Hi John,

I fully agree with your assessment. This attack utilizes the fact that some= clients rely on the result of a resource server request to login an user. = It is not an attack on the OAuth protocol. And even if a similar attack on = authorization codes will happen to fail for confidential clients does not mean OAuth is supposed to solve = this problem.

We nevertheless should mention it in the security considerations section. T= o make things simple, I suggest to describe and ban this anti-pattern _in g= eneral_ in the security consideration section (similar to Shuo's initial pr= oposal but more generalized). Additionally, the text should recommend to use an appropriate technique for id providing= such as OpenID or SAML.

We also could add a detailed analaysis to the security document.

best regards,
Torsten.

Am 21.06.2012 15:47, schrieb John Bradley:

Hi Hannes,

 

MAC tokens protect resources against token leakage t= o third parties.  That is useful but a different threat.  

 

The easiest way to get a access token for someone is= to have them log into your site.   

 

If you can do that the token type makes no differenc= e unless we move to a asymmetric holder of key token (different discussion)= .

 

The bad client gets the access MAC token and token s= ecret and can re use it just as it would a bearer token.

 

The origin of the post was a contention by someone a= t Facebook that profiling OAuth 2.0 on its own is sufficient to produce an = Authentication protocol.

 

I was trying to point out that OAuth 2 without any e= xtensions, only profiling is difficult to impossible to use for authenticat= ion as the attack surface and security considerations are different.

 

As it turned out Facebook had extended OAuth 2 with = signed requests and token introspection techniques to address these issues = for themselves.   

 

The problem as it turned out was that individual app= s and  app frameworks like the iOS one made some bad mistakes, by not = using the perhaps under documented extensions.

 

The problem is not unique to Facebook in any way the= y are just a convenient example.

 

Oauth 2  is not surprisingly mostly a= bout protecting the resource.  

 

Authentication is about protecting the client.<= /o:p>

 

Audience restriction from openID 2, SAML,  WS* = etc prevents replay of tokens issued to one RP/SP at another.  

That is sort of authentication protocol threat numbe= r 1.

 

OAuth has no way to do that with access tokens.=

 

It can however do it with "code" if the cl= ient is confidential.

 

So my recommendation is that without extensions to O= Auth like structured tokens (signed_request, id_token) or token introspecti= on endpoints like 

Facebook ( https= ://graph.facebook.com/app?access_token=3D[The Access Token]), there is no safe way to use an implicit flow for authentication.

A code flow where a= native app exchanges code for the access token and then passes the access = token back to it's server is also vulnerable (lots of this in circulation I= understand)

 

The only safe flow = (without extensions) is the code flow where the client is confidential and = the code is directly exchanged for the access token.

This also requires = the definition of a identity API that is protected by the access token, and= out of scope for OAuth.

 

So at the end of th= e day the rational conclusion is that OAuth 2 is a authorization protocol. =   

It may be used by A= uthentication protocols, but it is up to other specs to define the security= considerations for that.

 

That however doesn'= t remove the need to mention the token substitution attack that non confide= ntial clients are subject to, do to there being no other mechanism for the = client to know who the token was issued to.

 

John B.=

 

 

 

 

 

On 2012-06-21, at 5:27 AM, Hannes Tschofenig wrote:<= o:p>



Hi John,

I read through your blog post. I am not sure whether I can entirely agree w= ith your separation between authentication and authorization. I believe the= core issue here is that

* anyone who has the token will get access to whatever the token entitles h= im or her to do (unless there are restrictions in the token)

* some attributes are different than others. With authentication you typica= lly associate that the process took place recently (i.e., it is fresh) whil= e other attributes do not require the user (as resource owner) to actively = participate in the exchange and the same level of freshness is not implied.  For authentication in a = three party protocol to be useful the three parties have to participate (se= e http://tools.ietf.org/id/draft-tschofenig-oauth-signature-thoughts-00.txt).

I understand that one wants to avoid having tokens passed around from one a= pplication to the other one, as it is happening here.

I remember having some of these discussions with Eran a long time ago. He a= nticipated that implementers will not put any constraints in the tokens and= hence they will be misused. This serves as an argument for him to propose = the MAC token specification.

I proposed text for the security consideration section of the bearer docume= nt a while ago and it even talks about audience restriction as a recommenda= tion.

There are two problems with the audience restriction:

1) There is no mandatory token format defined nor do we mandate token conte= nt either. Hence we do not strongly require anything specifically to be put= into the tokens.

2) In the implicit grant flow the client isn't authenticated and hence what= do you want to put into a token as an audience restriction?

Finally, I think that the "audience restriction" terminology is a= bit fuzzy for this discussion either.
Audience restriction can mean two things:

* Allowing the client to verify that the access token has indeed been issue= d for him / her.
* Allowing the resource server verify that the received access token from a= specific client has indeed been provided by that client.

My current believe is that the implicit grant flow is unsuitable for provid= ing authentication functionality.

Ciao
Hannes

On Jun 19, 2012, at 5:50 AM, John Bradley wrote:


I can put something together.   

 

It is mostly a warning about the token substitution = attack that any implicit flow is vulnerable to if used for authentication o= f the presenter.

Otherwise known as why audience restriction is a goo= d thing.

 

John B.

 

On 2012-06-18, at 8:20 PM, Dick Hardt wrote:

 

John

 

Do you have suggested text per your suggestion below= ?

 

-- Dick

 

On Jun 18, 2012, at 2:04 PM, John Bradley wrote:

 

I blogged about this in the hypothetical several mon= ths ago. http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.ht= ml

 

Nov Matake and others built some tests and found qui= te a number of deployments vulnerable.

http://www.thread-safe.com/2012/02/= more-on-oauth-implicit-flow-application.html

 

The bottom line is that OAuth has no explicit audien= ce restriction for tokens,  hence accepting any token outside of the c= ode flow is subject to attack.

 

In general it is not a issue for authorization, &nbs= p;it is however a big issue then there is a presumption that the presenter = of a token that grants a client access to resource x is the "resource = owner" of resource x, when it is possible that the presenter is any client who has ever had a access token for resource x= .

 

We might want to include the why it is insecure in t= he security consideration,  otherwise people reading the below will li= kely ignore the advice as it seems on the surface a touch extreme.

 

There are certainly OAuth flows that allow you to do= authentication safely,  just not all of them without additional preca= utions.

 

That is why openID Connect has a audience restricted= id_token similar to Facebook's signed request to allow the implicit flows = to be safely used for authentication.

 

John B.

 

 

 

 

On 2012-06-18, at 4:19 PM, Shuo Chen (MSR) wrote:

 

Hi OAuth group,

 

This is regarding the recent discussion about an imp= lementation issue of some cloud services using OAuth for authentication.

Derek Atkins and Dick Hardt suggested the possibilit= y to discuss with the group a paragraph to add to the security consideratio= ns section.

 

Derek’s suggestion:

=3D=3D=3D=3D   =3D=3D=3D  =3D=3D=3D &= nbsp;=3D=3D=3D

Perhaps you could boil it down to a paragraph

or two for addition to the security considerations s= ection that basically says

"beware of implementing it *this* way because i= t leads to *that* attack vector", etc.

=3D=3D=3D=3D   =3D=3D=3D  =3D=3D=3D &= nbsp;=3D=3D=3D

 

 

Here is out suggested text:

=3D=3D=3D=3D   =3D=3D=3D  =3D=3D=3D &= nbsp;=3D=3D=3D

It has been observed that in multiple occasions that= the server-side

authentication logic takes an access token from the = client, then

queries the user's profile data from the IdP in orde= r to

"authenticate" the user. This implementati= on must be forbidden. It

will allow an untrusted app running on a victim̵= 7;s client device to

work with an attacker’s device to sign into th= e victim’s account on the server side.

=3D=3D=3D=3D   =3D=3D=3D  =3D=3D=3D &= nbsp;=3D=3D=3D

 

 

Thank you.

-Shuo

p.s. below is the email thread giving a better conte= xt of the discussion.

 

 

-----Original Message-----

From: Derek Atkins [mailto:derek@ihtfp.com]

Sent: Monday, June 18, 2012 11:25 AM

To: Shuo Chen (MSR)

Cc: Hannes Tschofenig; rui wang; Stephen Farrell; Yu= chen Zhou; Derek

Atkins; Dick Hardt

Subject: Re: [OAUTH-WG] web sso study...<= /p>

 

Hi,

 

"Shuo Chen (MSR)" <shuochen@microsoft.com> writes:

 

Hi Hannes, Derek and Stephen,

 

Thank you for your replies.

 

First, let me ask whether it is OK if I share your p= ost with the

OAuth WG

 

Yes, please feel free to share it.

 

Second, could you describe the attack in more detail= s to me?

 

Let's consider the mobile+cloud scenario for con= creteness (although

some other scenarios are also applicable). The attac= k steps are the

following: suppose Alice's tablet runs a Windows 8 M= etro app written

by attacker Bob. This app is able to request and obt= ain an access

token from the IdP (associated with Alice). The app = can then send the

access token to Bob's own tablet. Note that there is= no security

problem up to this point. However the real problem i= s that some cloud

services use the access token to query the user's pr= ofile data from

the IdP in order to "authenticate" the use= r. In this case, Bob's

tablet will be able to sign into the cloud service a= s Alice. We have

confirmed that the cloud services for Soluto Metro A= pp, Givit Metro

App and EuroCup2012 Metro App make this mistake. The= se are apps in

the official Windows 8 App Store. We actually sample= d only a small portion of the available apps, but believe this is a vulnera= bility pattern.

 

We don’t think there is anything wrong in the = OAuth spec. It is

developers who didn’t comprehensively understa= nd the usage of the

access token. In the meanwhile, this vulnerability p= attern is not explicitly excluded by the spec.

More importantly, it has been seen in the wild.=

 

[from Derek's email] Perhaps you could boil it down = to a paragraph

or two for

addition to the security considerations section that= basically says

"beware of implementing it *this* way because i= t leads to *that* attack vector", etc.

 

This is a great idea. I think that although it is di= fficult to

anticipate in general all kinds of incomprehensive u= nderstandings of

average developers, it is very worthwhile to take an= y common existing

vulnerability pattern as a precious feedback to impr= ove the

specification text. In this case, since we have alre= ady seen this

vulnerability pattern on multiple services in the wi= ld, certainly we

should be explicit about it in the security consider= ations section.

 

Our suggested text:

 

It has been observed that in multiple occasions that= the server-side

authentication logic takes an access token from the = client, then

queries the user's profile data from the IdP in orde= r to

"authenticate" the user. This implementati= on must be forbidden. It

will allow an untrusted app running on a victim̵= 7;s client device to

work with an attacker’s device to sign into th= e victim’s account on the server side.

 

Any questions or suggestions?

 

Could you please send this to the oauth@ietf.org mailing list?

 

Thanks a lot.

 

-Shuo

 

-derek

 

-----Original Message-----

From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]

Sent: Friday, June 15, 2012 11:36 AM

To: rui wang

Cc: Hannes Tschofenig; Stephen Farrell; Shuo Chen (M= SR); Yuchen Zhou;

Derek Atkins

Subject: Re: [OAUTH-WG] web sso study...<= /p>

 

Hi Rui,

 

let me independently respond (in addition to the pre= vious responses

you had already gotten).

 

First, let me ask whether it is OK if I share your p= ost with the

OAuth WG since it is more detailed than the one you = distributed on the list mid April.

 

Second, could you describe the attack in more detail= s to me? What I

would like to better understand whether this the rai= sed issue is a

problem with one of our specifications, with a speci= fic

implementation of the IETF OAuth specifications, a p= roblem with other

OAuth related work (Facebook, as you know, implement= s far more than

just the IETF OAuth specifications), a violation of = the IETF OAuth

specification in the way how the Websites use OAuth,= whether this is

a configuration related aspect, or an aspect we alre= ady documented in the threats document.

 

The reason why I am so specific is to know where to = put text to

address this issue or whether this is even an issue = beyond the IETF

OAuth working group and needs to be tackled somewher= e else.

 

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.ie=
tf.org/mailman/listinfo/oauth

 

 

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

 

--_000_0CBAEB56DDB3A140BA8E8C124C04ECA20107E583P3PWEX2MB008ex2_-- From eran@hueniverse.com Sun Jun 24 00:22:38 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E006A21F86A4 for ; Sun, 24 Jun 2012 00:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 QWEC4YZpDRMF for ; Sun, 24 Jun 2012 00:22:38 -0700 (PDT) Received: from p3plex2out01.prod.phx3.secureserver.net (p3plex2out01.prod.phx3.secureserver.net [184.168.131.12]) by ietfa.amsl.com (Postfix) with ESMTP id 1FB9B21F867B for ; Sun, 24 Jun 2012 00:22:38 -0700 (PDT) Received: from P3PWEX2HT002.ex2.secureserver.net ([184.168.131.10]) by p3plex2out01.prod.phx3.secureserver.net with bizsmtp id S7Nd1j0010Dcg9U017Nd0b; Sun, 24 Jun 2012 00:22:37 -0700 Received: from P3PWEX2MB008.ex2.secureserver.net ([169.254.8.66]) by P3PWEX2HT002.ex2.secureserver.net ([184.168.131.10]) with mapi id 14.02.0247.003; Sun, 24 Jun 2012 00:22:37 -0700 From: Eran Hammer To: Mike Jones , John Bradley , Hannes Tschofenig Thread-Topic: [OAUTH-WG] AD review of draft-ietf-oauth-urn-sub-ns-02 Thread-Index: AQHNUTwtCrebtMS7nE6G5+mCBYXjyZcIfpAAgAAxAQCAAGIR0A== Date: Sun, 24 Jun 2012 07:22:37 +0000 Message-ID: <0CBAEB56DDB3A140BA8E8C124C04ECA20107E5A6@P3PWEX2MB008.ex2.secureserver.net> References: <4FE1C16D.6010602@cs.tcd.ie> <4CD0B85C-C88D-4B52-81E4-5D53A25E60EF@cs.tcd.ie> <4E1F6AAD24975D4BA5B16804296739436656365A@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B168042967394366565C12@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366565C12@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [37.46.45.33] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Barry Leiba , "oauth@ietf.org" Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-urn-sub-ns-02 X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 07:22:39 -0000 This boils down to whether the registration template can contain all the de= tailes required for interoperability or not. If not, you need a specificati= on. EH > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Mike Jones > Sent: Saturday, June 23, 2012 11:31 AM > To: John Bradley; Hannes Tschofenig > Cc: Barry Leiba; oauth@ietf.org > Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-urn-sub-ns-02 >=20 > I agree that Specification Required would be fine. I'd rather that there= be a > publicly available specification defining the URN than one potentially > available only to the expert reviewers. >=20 > -- Mike >=20 > -----Original Message----- > From: John Bradley [mailto:ve7jtb@ve7jtb.com] > Sent: Saturday, June 23, 2012 8:36 AM > To: Hannes Tschofenig > Cc: Mike Jones; oauth@ietf.org; Barry Leiba > Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-urn-sub-ns-02 >=20 > I think Specification required is fine. It allows a OIDF or OASIS spec t= o be > used as the basis for the registration withh appropriate expert review. >=20 > John B. >=20 > Sent from my iPad >=20 > On 2012-06-23, at 8:31 AM, Hannes Tschofenig > wrote: >=20 > > Hi Mike, > > > > the point is not that other groups, like OASIS, cannot use them. They c= an > use the extensions. > > > > The question is more what process and documentation is needed to allow > OASIS (and others) to define their own extensions. > > > > So far, OASIS had not been interested for any extension (at least from > what I know). The OpenID community, to which you also belong, had defined > extensions (and brought some of them to the IETF) but had been quite > careful themselves to ensure proper review and documentation. > > > > So, if you look at the most important decision points then you have: > > > > 1) do you want a requirement for a specification, i.e., when someone > defines an extension do you want it to be documented somewhere? > > > > 2) do you envision a review from experts (e.g., checking whether the st= uff > makes any sense or conflicts with some other already available extensions= )? > > > > http://tools.ietf.org/html/rfc5226 provides a good discussion about thi= s > topic. > > > > If the answer to the above-listed questions is YES then you probably at > least want 'Specification Required' as a policy. > > > > Ciao > > Hannes > > > > > > On Jun 21, 2012, at 10:49 PM, Mike Jones wrote: > > > >> I'd argue that the registration regime chosen should be flexible enoug= h to > permit OASIS or OpenID specs to use it. Otherwise, as someone else > pointed, people will work around the limitation by using unregistered val= ues > - which helps no one. > >> > >> -- Mike > >> > >> From: Barry Leiba > >> Sent: 6/21/2012 12:31 PM > >> To: Stephen Farrell > >> Cc: oauth@ietf.org > >> Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-urn-sub-ns-02 > >> > >>>> Stephen: > >>>> Yeah, I'm not sure Standards Track is needed. > >>> > >>> On this bit: I personally don't care, except that we don't have to > >>> do it twice because someone later on thinks the opposite and wins > >>> that argument, which I'd rather not have at all (My one-track > >>> mind:-) Doing the 4 week last call means once is enough. But I'm ok w= ith > whatever the WG want. > >> > >> Well, it's not a 4-week LC, but a 2-week one. Anyway, yes, I see > >> your point, and I've done that with other documents. Better to make > >> it Standards Track for now, note in the shepherd writeup that > >> Informational is probably OK, and let the IESG decide. > >> > >> b > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > >> > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From hannes.tschofenig@gmx.net Sun Jun 24 06:17:52 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A3E821F8617 for ; Sun, 24 Jun 2012 06:17:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ttL2twGwuz9v for ; Sun, 24 Jun 2012 06:17:51 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id EC5DE21F85D2 for ; Sun, 24 Jun 2012 06:17:50 -0700 (PDT) Received: (qmail invoked by alias); 24 Jun 2012 13:17:49 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.109]) [88.115.216.191] by mail.gmx.net (mp002) with SMTP; 24 Jun 2012 15:17:49 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+92xlQQLu929OSiaPrgxSGkU9IWf6OvMr86ay0PB z5yVU3dOa05jFV From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 24 Jun 2012 16:17:48 +0300 Message-Id: <4F1F7754-CF91-4C07-A4B6-20AB94C2E2B2@gmx.net> To: OAuth WG Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Subject: [OAUTH-WG] OAuth Parameter Registration Template X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 13:17:52 -0000 Hi all,=20 working on the proposed text for the OAuth assertions draft I noticed an = interesting aspect in the core specification regarding Section 11.2.1, = which defines the registration template for OAuth parameters.=20 The template lists all possible usage locations of parameters, namely = authorization request, authorization response, token request, or token = response. Here is the first issue: these locations are not defined anywhere in the = document and so one can only guess to what part of the protocol exchange = they belong.=20 I agree that it may not be very difficult to guess but obviously it is = not completely obvious. It would have been nice if there is actually a = match with Figure 1, for example.=20 http://tools.ietf.org/html/draft-ietf-oauth-assertions-03, for example, = uses a location that is not in the above list, namely 'client = authentication'.=20 Client authentication can also happen in the interaction between the = client and the resource server but the exchanges are not part of the = allowed list of usage locations.=20 Ciao Hannes From sakimura@gmail.com Sun Jun 24 06:29:23 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 776E821F8634 for ; Sun, 24 Jun 2012 06:29:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.42 X-Spam-Level: X-Spam-Status: No, score=-3.42 tagged_above=-999 required=5 tests=[AWL=0.178, 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 xUIYzVxy+MaC for ; Sun, 24 Jun 2012 06:29:20 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id F173021F862F for ; Sun, 24 Jun 2012 06:29:18 -0700 (PDT) Received: by bkty8 with SMTP id y8so2877499bkt.31 for ; Sun, 24 Jun 2012 06:29:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=c981Mfeg68ZyphjiWiIulPwJR1apzq/w69LswgKW8eg=; b=kFgd15x6Bz+t3WwQh9NxMgHZvfDSMZrxU/JYao/v+k0KW1P26Zy2mZzPjU+XAlawIm 3pLcN9wMyzM1JGd9Gf1RVyI5eiQTQlegWWyT3bu5t3AVZg2XIC5D7SyqIUi1QcPTwzS9 F5jtQu7dDAb6Y+RrwZtuHxFAFKPkUSgZbKlUuQ62CWCdPb+Z3pKOJ4PF6QtcCmxphZui rYirqV9YHjLI8DfUVoGmZ8T1t3vuQEiEB6ze0ZcwdHzVdAm6fLqYMh/PXj+/LCITYc+6 1SwlpQib6srQBXKYYC10GXXqSika8jE4IzQf5MYQAu4zfEWJYvXY1/XbJLlxraCDowwx agaw== MIME-Version: 1.0 Received: by 10.205.139.81 with SMTP id iv17mr2996922bkc.118.1340544557416; Sun, 24 Jun 2012 06:29:17 -0700 (PDT) Received: by 10.204.240.143 with HTTP; Sun, 24 Jun 2012 06:29:17 -0700 (PDT) In-Reply-To: <4FE37D38.1030407@gmail.com> References: <1339792496.52712.YahooMailNeo@web125501.mail.ne1.yahoo.com> <59E470B10C4630419ED717AC79FCF9A9108898EE@BL2PRD0410MB363.namprd04.prod.outlook.com> <4FE223E4.6060307@mitre.org> <4FE226BC.6010403@alcatel-lucent.com> <59E470B10C4630419ED717AC79FCF9A910889AB5@BL2PRD0410MB363.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A917052BC8@SN2PRD0410MB370.namprd04.prod.outlook.com> <4FE37D38.1030407@gmail.com> Date: Sun, 24 Jun 2012 22:29:17 +0900 Message-ID: From: Nat Sakimura To: Paul Madsen Content-Type: multipart/alternative; boundary=001517402de626811804c337daae Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Report an authentication issue X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 13:29:23 -0000 --001517402de626811804c337daae Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Fri, Jun 22, 2012 at 4:59 AM, Paul Madsen wrote: > ** > Lewis, I think you are perhaps conflating the token model (whether it has > inherent structure or is merely a pointer to user info) and who the RO > owner is - user or enterprise. > > Nothing prevents you today from using OAuth as is to issue a token to the > officer on the tablet, having the app use that token on API calls, and th= e > API making an authz decision based solely on enterprise policy, with no > consent figuring in. > Indeed, though I usually envisage that there is invisible consent authority a.k.a. corporate policy engine. > > Neither do you need a structured token (like id_token). The token issued > can merely be a pointer/artifact to the officer's actual roles, these > obtained by the API/RS by sending the tokens for 'validation' or > 'introspection' > If RS can reach AS through network, yes, the access token can act as an artifact that you do artifact resolve. That would have a nice property of audit logging at the AS. It is not always true though. In one of my use case, RS was not able to directly talk to AS, in which case, you need a structured token. > > This doesnt sound like a Connect Use Case to me - rather a pretty standar= d > OAuth use case - albeit with no need to get user's consent (so actually > simpler). > If authentication and the identity of the accessor matters, yes. If it does not, maybe not. > > paul > > > On 6/21/12 12:01 PM, Lewis Adam-CAL022 wrote: > > Hi Nat,**** > > ** ** > > I=92m beginning to wonder what it would take to add a new profile of sort= s > to either OAuth or Connect. **** > > ** ** > > In the beginning there was SOAP, and the preferred method to secure SOAP > API calls was WS-Trust.**** > > ** ** > > Now the world is moving toward RESTful APIs =85 and the preferred means t= o > secure RESTful APIs is OAuth.**** > > ** ** > > Except that OAuth is clearly written with the idea that the protected > resources belong to the end user.**** > > ** ** > > My use cases =96 and I imagine the use cases of many other enterprises = =96 is > that the Owner of the resources is the Enterprise. An employee is trying > to access a database or video resources. The enterprise RS needs to be > able to 1) identify the user, and 2) make authorization decisions based o= n > what roles that user has within the enterprise. So in my scenario, when = a > police officer attempts to access a criminal records database, the databa= se > needs to know who that officer is, and then decide if they have privilege > to access the database, and at what level (e.g. CRUD). **** > > ** ** > > WS-Trust fits this model well. The user performs primary authentication > to the enterprise STS, which then grants the application client a SAML > assertion. When the user attempts to access a records database, the SAML > assertion is included in the SOAP message. The records server > authenticates the user based on the SAML assertion and makes its > authorization decisions.**** > > ** ** > > This is the world I=92m trying to migrate from, and it really seems like = I=92m > sometimes trying to make a square peg fit in a round hole. I=92m looking= for > OAuth/Connect to do for REST what WS-TRUST did for SOAP. I would like a > native client talking to a RS to be able to ask for an id_token, and then > pass that id_token to the RS when making its RESTful API calls, to enable > the RS to authenticate the user. I think that this would be really usefu= l > for a lot of people besides me. I keep hearing that there is nothing > =93preventing=94 me from doing this =85 but it hardly seems within the sp= irit of > what OAuth was meant to do. The id_token was clearly meant to enable a > user to authenticate to a confidential client / web server =85 but was n= ot > meant for a native client to identity / authenticate the user to a RS. *= * > ** > > ** ** > > ** ** > > Would there be any interest in exploring this further?**** > > -adam**** > > ** ** > > ** ** > > *From:* Nat Sakimura [mailto:sakimura@gmail.com ] > *Sent:* Wednesday, June 20, 2012 8:09 PM > *To:* Lewis Adam-CAL022 > *Cc:* igor.faynberg@alcatel-lucent.com; oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Report an authentication issue**** > > ** ** > > Yes, OAuth can be profiled to enable authentication. **** > > In fact, initial draft of OpenID Connect was just like you described. ***= * > > Essentially, we were using structured access_token. **** > > Later, we decided to separate the access token and id_token for several > reasons such as: **** > > ** ** > > 1. Better interop with existing OAuth implementations: by introducing > id_token, they do not need to touch the supposedly opaque (which means > AS-RS may be doing some proprietary thing inside it) access token. ***= * > 2. Mixing up the audience (for id_token aka authn =3D client, and for > access_token aka authz =3D resource server) probably is expanding the = attack > surface for security and privacy. **** > > Although we separated them out, a signed id_token includes the left hash > of access_token so access_token is also protected. **** > > ** ** > > Best, **** > > ** ** > > Nat**** > > ** ** > > On Thu, Jun 21, 2012 at 5:21 AM, Lewis Adam-CAL022 < > Adam.Lewis@motorolasolutions.com> wrote:**** > > Hi Igor,**** > > **** > > As Justin just pointed out, consider the case where the video server is > hosted by the state (e.g. California) and is accessed by police agencies = in > Los Angeles, San Francisco, and San Diego. The State of California=92s v= ideo > server is the RS. Each local police agency (LA/SF/SD) hosts an AS. So > when a police officer from LAPD launches the video client app on the > iPhone, the client makes an OAuth request to the LAPD=92s AS, which > authenticates the police officer using agency level credentials. The > access token issued to the video client app on the iPhone is a JWT, signe= d > by the agency AS, which might look something like this:**** > > **** > > {=93typ=94:=94JWT=94,"alg":"ES256"}**** > > {"iss":"https://as.lapd.california.gov", > "prn":"alice@lapd.california.gov", > "aud":" https://video_server1@state.california.gov", > "iat":1300815780, > "exp":1300819380, > "acr":=94password=94}**** > > > hq4zk+ZknjggCQgZm7ea8fI79gJEsRy3E8LHDpYXWQIgZpkJN9CMLG8ENR4Nrw+n7iyzixBvK= XX8P53BTCT4VghPBWhFYSt9tHWu/AtJfOTh6qaAsNdeCyG86jmtp3TDMwuL/cBUj2OtBZOQMFn7= jQ9YB7klIz3RqVL+wNmeWI4=3D > **** > > **** > > The JWT might be optionally encrypted using JWE. **** > > **** > > I think what is becoming clear (and this is what I=92m trying to vet) is > that while there is nothing in OAuth that specifies authentication, it ** > can** be used for Authentication, if done in the way that I describe. If > I=92m wrong about this, I really need to know. I=92ve vetted this idea o= f mine > with quite of few people now =96 both within context of the list and off-= line > =96 and I think I=92m okay. If you see any holes in what I describe, plea= se > point them out as I would prefer to uncover them now rather than after > implementation or deployment!**** > > **** > > Essentially I=92m using OAuth as a RESTful version of WS-Trust, where my > client can exchange primary credentials for a token (JWT) and present tha= t > token to a server as secondary authentication. It=92s just that it=92s R= ESTful > instead of SOAP :-)**** > > **** > > As Justin as pointed out =85 I=92ve basically made the access-token look = like > the id_token of Connect. I was actually hoping to lay a path to Connect, > and use the id_token =85 until it was also pointed out that the id_token = is > really meant for the consumption of the client, not the RS :-(**** > > **** > > **** > > **** > > *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behalf > Of *Igor Faynberg > *Sent:* Wednesday, June 20, 2012 2:39 PM > *To:* oauth@ietf.org**** > > > *Subject:* Re: [OAUTH-WG] Report an authentication issue**** > > **** > > But this use case does need OAuth, period:**** > > > > The video server is under the control of a police agency, and police > officers must logon to the video server in order to access video content. > > There is no delegation here, and there is no need to use third party for > authentication. > > Igor > > On 6/20/2012 3:26 PM, Justin Richer wrote: **** > > In case it wasn't clear, I want to restate the original problem as best a= s > I understand it in a way that hopefully clears it up: > > App A and app B are both valid registered OAuth clients to an OAuth > protected service. > > The problem starts when app A gets handed a token that was issued for app > B and uses it to call an identity API on the OAuth service. Since app B c= an > get tokens just fine, they're bearer tokens, this is a fairly basic api > call, this function works just fine and returns the user info. This makes > sense, since anyone who holds A's tokens can do whatever A can do on beha= lf > of that user. The issues start when app B then decides that since they ca= n > make a call to the identity API with a token then the user *must* be > present. In other words, app B is confusing authorization to call an API > with authentication of the session. > > OpenID Connect fixes this missed assumption by binding the ID Token to th= e > session and sending it along side the access token, but as you pointed ou= t, > it's meant for consumption at the client, not the resource server, in > general. That doesn't mean you can't send it to a resource server for you= r > own purposes, of course. That's actually how the session management > endpoint works in Connect. > > This isn't the only way to handle this problem -- if you put some > structure in your tokens, such as with JWT or SAML, then app A can tell > that this isn't a token issued to app A, but to app B, so it can call > shenanigans and reject it then and there. > > -- Justin > > On 06/20/2012 10:03 AM, Lewis Adam-CAL022 wrote: **** > > I am entirely confused.**** > > **** > > I understand what everybody is saying for confidential clients, no proble= m > here.**** > > **** > > I fall apart when thinking of iPhone apps. Consider the scenario where I > deploy a video server, and write an iPhone app to talk to the video > server. The video server is under the control of a police agency, and > police officers must logon to the video server in order to access video > content. So the police office launches their iPhone video client app.***= * > > **** > > If I wanted to solve authentication using =93traditional=94 client-server > authentication, the user enters their username / password into the client= , > and the client sends the username / password off to the server, which > authenticates it, or possibly uses HTTP digest. > > **** > > If I wanted to use OpenID, the client would attempt to reach the video > server (RP), the server would redirect the client to the OP, OP > authenticates user, and OP redirects client back to the server/RP with an > assertion that primary authentication was successful. > > **** > > If I wanted to use OAuth, the client would send an authorization request > to the server=92s AS, which would authenticate the user of the client, an= d > ultimately result in the client possessing an access-token. My thinking = is > that this access token (let=92s assume it=92s a JWT) would contain the us= er=92s > identity, a statement of what type of primary authentication was used (au= th > context), an expiration, and an audience claim. This sounds a lot like > authentication to me, and it=92s where I get confused. Is it just becaus= e > OAuth does not explicitly define this? Is there a threat in using OAuth = as > I describe? > > **** > > If I wanted to use Connect, well I=92m not even sure how the id_token as > defined by Connect helps this use case. The id_token seems to make sense > when the client is a confidential web server, but it=92s not clear what a= n > iPhone app would do with the id_token =85 it=92s the server in the backen= d that > needs to authenticate the user, the iPhone app is just an interface to ta= lk > to the server. And it seems as I learn more about connect that the > id_token is not meant to be sent from the iPhone app to the server, just > the access token. So it=92s really not clear how Connect helps solve > authentication for an iPhone client app talking to a video server. If I= =92m > sending access-tokens, it=92s just OAuth again.**** > > **** > > What am I still missing?**** > > adam**** > > **** > > **** > > *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] > *On Behalf Of *Kristofor Selden > *Sent:* Saturday, June 16, 2012 11:33 AM > *To:* nov matake; oauth > *Cc:* Yuchen Zhou; Luke Melia; Shuo Chen (MSR) > *Subject:* Re: [OAUTH-WG] Report an authentication issue**** > > **** > > Nov demonstrated the problem to us at Yapp and we used solution 4 (becaus= e > the solution is server side and our app was in the app store).**** > > **** > > FB Connect is authentication *and* authorization, where OAuth 2 is > concerned only with authorization =96 I'm not sure that app developers > appreciate this subtlety.**** > > **** > > With OAuth 2 you authorize an app to use a protected resource. With FB > Connect, you do that, but *also* authenticate with the app you are > authorizing.**** > > **** > > So the access_token protects not just the FB resources but the auth end > point of the authorized app (very common with apps that use the iOS SDK). > So now the app needs a way to verify that it was the app that was > authorized to FB.**** > > **** > > Solution 4 explanation: on FB you can register a iPhone app and a server > app with the same client_id and get a client_secret for use on the server= . > The server side API posts the access_token, client_id, and client_secret > to https://graph.facebook.com/app to verify > that the bearer token actually belongs to the app that is being > authenticated before assuming they are authorized to the app's protected > resources.**** > > **** > > Kris**** > > **** > > On Jun 15, 2012, at 8:22 PM, nov matake wrote:**** > > > > **** > > There are 4 ways to fix this issue.**** > > **** > > 1. Use response_type=3Dtoken%20code (It's not in OAuth 2.0 Core, but seem= s > best way for interoperability)**** > > 2. Use singed_request (or some signed token like JWT)**** > > 3. Use grant_type=3Dfb_exchange_token (Facebook custom way)**** > > 4. Access to https://graph.facebook.com/app?access_token=3DYOUR_TOKEN(Fac= ebook custom way, moreover undocumented API) > **** > > **** > > Two iPhone app developers I reported this issue fixed it by using (4).***= * > > **** > > I also tried to use (1) for my own iPhone app implementation, but > unfortunately it doesn't work when using authorization codes obtained via > FB iOS SDK.**** > > So I'm using (3) in my case.**** > > **** > > nov**** > > **** > > On 2012/06/16, at 9:16, Nat Sakimura wrote:**** > > > > **** > > As to how the fix was done, Nov can provide more detail, but ... **** > > **** > > 1. Properly verify the signature/HMAC of the "signed_request". This will > essentially audience restricts the token. **** > > 2. There is an undocumented API for Facebook which returns to whom the > token was issued. This also audience restricts the token. **** > > **** > > The service that fixed took these measures. Note that none of the above i= s > defined in OAuth. **** > > The same facility was called "id_token" and "check ID endpoint" for OpenI= D > Connect. **** > > **** > > The scale of the impact is large, too large to disclose the actual names > in the public list, though, eventually, we would publish them in a paper. > **** > > **** > > Nat**** > > On Sat, Jun 16, 2012 at 5:34 AM, Francisco Corella > wrote: > > **** > > Hi Nat and Rui, > > Rui, you say that the vulnerability that you found was due to a > "common misunderstanding among developers", but the attack you > describe can be carried out against any app that uses the OAuth > "implicit grant flow", which Facebook calls "client-side > authentication". No misunderstanding seems necessary. What > misunderstanding are you referring to? I followed the link in your > message to the Sophos post, and from there the link to the article in > The Register. The article in The Register says that Facebook had > "fixed the vulnerability promptly". How did they fix it? The > instructions that Facebook provides for implementing "Client-side > authentication without the JS SDK" at > https://developers.facebook.com/docs/authentication/client-side/#no-jssdk > still allows the attack. > > Nat, I agree that the blog post by John Bradley that you link to > refers to the same vulnerability reported by Rui. You say that some > apps have issued a patch to fix it. Could you explain what the fix > was? > > Francisco**** > > **** > ------------------------------ > > *From:* Nat Sakimura > *To:* rui wang > *Cc:* matake nov ; Yuchen Zhou ; > oauth ; Shuo Chen (MSR) > *Sent:* Thursday, June 14, 2012 1:50 PM > *Subject:* Re: [OAUTH-WG] Report an authentication issue**** > > **** > > This is a fairly well known (hopefully by now) issue. We, at the OpenID > Foundation, call it "access_token phishing" attack these days. See: > http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.= html > **** > > **** > > Nov Matake has actually built the code on iPhone to verify the problem, > and has notified bunch of parties back in February including Facebook and > Apple. We have the code that actually runs on a phone, and we have > successfully logged in to bunch of apps, including very well known ones. > They were all informed of the issue. Some immediately issued a patch to f= ix > it while others have not. **** > > **** > > The problem is that even if these apps gets fixed, the problem does not g= o > away. As long as the attacker has the vulnerable version of the app, he > still can impersonate the victim. To stop it, the server side has to > completely disable the older version, which means the service has to cut > off many users pausing business problems. **** > > **** > > Nat**** > > On Fri, Jun 15, 2012 at 2:18 AM, rui wang wrote:*= * > ** > > Dear Facebook Security Team and OAuth Standard group,**** > > We are a research team in Microsoft Research. In January, 2011, we > reported a vulnerability in Facebook Connect which allowed everyone to si= gn > into Facebook-secured relying parties without password. It was promptly > fixed after reporting. ( > http://nakedsecurity.sophos.com/2011/02/02/facebook-flaw-websites-steal-p= ersonal-data/ > )**** > > Recently, we found a common misunderstanding among developers of > mobile/metro apps when using OAuth (including Facebook=92s OAuth) for > authentication. The vulnerability resulted from this misunderstanding als= o > allows an attacker to log into a victim user's account without password.*= * > ** > > Let's take Soluto's metro app as an example to describe the problem. The > app supports Facebook Login. As an attacker, we can write a regular > Facebook app. Once the victim user allows our app to access her Facebook > data, we receive an access_token from the traffic. Then, on our own machi= ne > (i.e., the "attacker" machine), we run the metro app of Soluto, and use a > HTTP proxy to insert the victim's access_token into the traffic of Facebo= ok > login. Through this way, we are able to log into the victim's Soluto > account from our machine. Other than Soluto, we also have confirmed the > same issue on another Windows 8 metro-app Givit.**** > > The Facebook SDK for Android apps ( > https://developers.facebook.com/docs/mobile/android/build/#sdk) seems to > have the possibility to mislead developers too. At least, the issue that = we > found is not clearly mentioned. In the SDK, we ran the sample code called > "Hackbook" using Android Emulator (imagine it is an attacker device). Not= e > that we have already received the access token of the victim user from ou= r > regular Facebook app. We then inject the token to the traffic of Hackbook= . > Through this way, Hackbook app on our own machine recognizes us as the > victim. Note that this is not a convincing security exploit yet, because > this sample code does not include the server-side code. However, given th= at > we have seen real server-side code having this problem, such as Soluto, > Givit and others, we do believe that the sample code can mislead > mobile/metro developers. We also suspect that this may be a general issue > of many OAuth implementations on mobile platforms, so we send this messag= e > to OAuth Standard group as well.**** > > We have contacted the vendors of the two vulnerable metro-apps, Soluto an= d > Gavit.**** > > Please kindly give us an ack when you receive this message. If you want t= o > know more details, please let us know.**** > > Best Regards, > Yuchen Zhou, Rui Wang, and Shuo Chen**** > > > _______________________________________________ > 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 > > **** > > > > **** > > **** > > -- > 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**** > > **** > > > > **** > > _______________________________________________**** > > OAuth mailing 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 listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau= th > > --=20 Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --001517402de626811804c337daae Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On Fri, Jun 22, 2012 at 4:59 AM, Paul Ma= dsen <paul.madsen@gmail.com> wrote:
=20 =20 =20 =20
Lewis, I think you are perhaps conflating the token model (whether it has inherent structure or is merely a pointer to user info) and who the RO owner is - user or enterprise.

Nothing prevents you today from using OAuth as is to issue a token to the officer on the tablet, having the app use that token on API calls, and the API making an authz decision based solely on enterprise policy, with no consent figuring in.
<= div>
Indeed, though I usually envisage that there is invisibl= e consent authority a.k.a. corporate policy engine.=A0
=A0

Neither do you need a structured token (like id_token). The token issued can merely be a pointer/artifact to the officer's actual roles, these obtained by the API/RS by sending the tokens for 'validation' or 'introspection'
<= div>
If RS can reach AS through network, yes, the access toke= n can act as an artifact that you do artifact resolve. That would have a ni= ce property of audit logging at the AS. It is not always true though. In on= e of my use case, RS was not able to directly talk to AS, in which case, yo= u need a structured token.=A0
=A0

This doesnt sound like a Connect Use Case to me - rather a pretty standard OAuth use case - albeit with no need to get user's consent (so actually simpler).

If authent= ication and the identity of the accessor matters, yes.=A0
If it d= oes not, maybe not. =A0


=A0
paul


On 6/21/12 12:01 PM, Lewis Adam-CAL022 wrote:
=20 =20 =20 =20

Hi Nat,

=A0

I=92m beginning to wonder what it would take to add a new profile of sorts to either OAuth or Connect.=A0

=A0

In the beginning there was SOAP, and the preferred method to secure SOAP API calls was WS-Trust.

=A0

Now the world is moving toward RESTful APIs =85 and the preferred means to secure RESTful APIs is OAuth.

=A0

Except that OAuth is clearly written with the idea that the protected resources belong to the end user.

=A0

My use cases =96 and I imagine the use cases of many other enterprises =96 is that the Owner of the resources is the Enterprise.=A0 An employee is trying to access a database or video resources.=A0 The enterprise RS needs to be able to 1) identify the user, and 2) make authorization decisions based on what roles that user has within the enterprise.=A0 So in my scenario, when a police officer attempts to access a criminal records database, the database needs to know who that officer is, and then decide if they have privilege to access the database, and at what level (e.g. CRUD).=A0

=A0

WS-Trust fits this model well.=A0 The user performs primary authentication to the enterprise STS, which then grants the application client a SAML assertion.=A0 When the user attempts to access a records database, the SAML assertion is included in the SOAP message.=A0 The records server authenticates the user based on the SAML assertion and makes its authorization decisions.

=A0

This is the world I=92m trying to migrate from, and it really seems like I=92m sometimes trying to make a square peg fit in a round hole.=A0 I=92m looking for OAuth/Connect to do for REST what WS-TRUST did for SOAP.=A0 I would like a native client talking to a RS to be able to ask for an id_token, and then pass that id_token to the RS when making its RESTful API calls, to enable the RS to authenticate the user.=A0 I think that this would be really useful for a lot of people besides me.=A0 I keep hearing that there is nothing =93preventing=94 me from doing this =85 but it hardly seems within the spirit of what OAuth was meant to do.=A0 The id_token was clearly meant to enable a user to authenticate to a confidential client =A0/ web server =85 but was not meant for a native client to identity / authenticate the user to a RS.=A0

=A0

=A0

Would there be any interest in exploring this further?<= /span>

-adam

=A0

=A0

From: = Nat Sakimura [mail= to:sakimura@gmail.com]
Sent: Wednesday, June 20, 2012 8:09 PM
To: Lewis Adam-CAL022
Cc: igor.faynberg@alcatel-lucent.com; oauth@iet= f.org
Subject: Re: [OAUTH-WG] Report an authentication issue

=A0

Yes, OAuth can be profiled to enable authentication.=A0

In fact, initial draft of OpenID Connect was just like you described.=A0

Essentially, we were using structured access_token.=A0

Later, we decided to separate the access token and id_token for several reasons such as:=A0

=A0

  1. Better interop with existing OAuth implementations: by introducing id_token, they do not need to touch the supposedly opaque (which means AS-RS may be doing some proprietary thing inside it) access token.=A0
  2. Mixing up the audience (for id_token aka authn =3D client, and for access_token aka authz =3D resource server) probably is expanding the attack surface for security and privacy.=A0<= u>

Although we separated them out, a signed id_token includes the left hash of access_token so access_token is also protected.=A0

=A0

Best,=A0

=A0

Nat

=A0

On Thu, Jun 21, 2012 at 5:21 AM, Lewis Adam-CAL022 <Adam.Lewis@motorolasolutions.com> wrote:

Hi Igor,

=A0

As Justin just pointed out, = consider the case where the video server is hosted by the state (e.g. California) and is accessed by police agencies in Los Angeles, San Francisco, and San Diego.=A0 The State of California=92s video server is the RS.=A0 Each local police agency (LA/SF/SD) hosts an AS.=A0 So when a police officer from LAPD launches the video client app on the iPhone, the client makes an OAuth request to the LAPD=92s AS, which authenticates the police officer using agency level credentials.=A0 The access token issued to the video client app on the iPhone is a JWT, signed by the agency AS, which might look something like this:

=A0

{=93typ=94:=94JWT=94,"a= lg":"ES256"}

{"iss":"https://as.lapd.cal= ifornia.gov",
=A0=A0"prn":"alice@lapd.california.gov", =A0 "aud":" https://video_server1@state.ca= lifornia.gov",
=A0 "iat":1300815780,
=A0 "exp":1300819380,
=A0 "acr":=94password=94}

hq4zk+ZknjggCQgZm7ea8fI79gJEsRy3E8LHDpYXWQIgZpkJN= 9CMLG8ENR4Nrw+n7iyzixBvKXX8P53BTCT4VghPBWhFYSt9tHWu/AtJfOTh6qaAsNdeCyG86jmt= p3TDMwuL/cBUj2OtBZOQMFn7jQ9YB7klIz3RqVL+wNmeWI4=3D

=A0

The JWT might be optionally encrypted using JWE.=A0

=A0

I think what is becoming clear (and this is what I=92m trying to vet) is that while there is nothing in OAuth that specifies authentication, it *= can* be used for Authentication, if done in the way that I describe.=A0 If I=92m wrong about this, I really need to know.=A0 I=92ve vetted this idea of mine with quite of few people now =96 both within context of the list and off-line =96 and I think I=92m okay. If you see any holes in what I describe, please point them out as I would prefer to uncover them now rather than after implementation or deployment!

=A0

Essentially I=92m using OAuth as a RESTful version of WS-Trust, where my client can exchange primary credentials for a token (JWT) and present that token to a server as secondary authentication.=A0 It=92s just that it=92s RESTful instead of SOAP :-)

=A0

As Justin as pointed out =85 I=92ve basically made the access-token look like the id_token of Connect.=A0 I was actually hoping to lay a path to Connect, and use the id_token =85 until it was also pointed out that the id_token is really meant for the consumption of the client, not the RS :-(=

=A0

=A0

=A0

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Igor Faynberg
Sent: Wednesday, June 20, 2012 2:39 PM
To: oauth@ietf.org


Subject: Re: [OAUTH-WG] Report an authentication issue

=A0

But this use case=A0 does need OAuth, period:



The video server is under the control of a police agency, and police officers must logon to the video server in order to access video content.

There is no delegation here, and there is no need to use third party for authentication.=A0

Igor

On 6/20/2012 3:26 PM, Justin Richer wrote:

In case it wasn't clear, I want to restate the original problem as best as I understand it in a way that hopefully clears it up:

App A and app B are both valid registered OAuth clients to an OAuth protected service.

The problem starts when app A gets handed a token that was issued for app B and uses it to call an identity API on the OAuth service. Since app B can get tokens just fine, they're bearer tokens, this i= s a fairly basic api call, this function works just fine and returns the user info. This makes sense, since anyone who holds A's tokens can do whatever A can do on behalf of that user. The issues start when app B then decides that since they can make a call to the identity API with a token then the user *must* be present. In other words, app B is confusing authorization to call an API with authentication of the session.

OpenID Connect fixes this missed assumption by binding the ID Token to the session and sending it along side the access token, but as you pointed out, it's meant for consumption at the client, not the resource server, in general. That doesn't mean you can't send it to a resource server for your own purposes, of course. That's actually how the sessio= n management endpoint works in Connect.

This isn't the only way to handle this problem -- i= f you put some structure in your tokens, such as with JWT or SAML, then app A can tell that this isn't a token issued to app A, but to app B, so it can call shenanigans and reject it then and there.

=A0-- Justin

On 06/20/2012 10:03 AM, Lewis Adam-CAL022 wrote:

I am entirely confused.

=A0

I understand what everybod= y is saying for confidential clients, no problem here.<= u>

=A0

I fall apart when thinking= of iPhone apps.=A0 Consider the scenario where I deploy a video server, and write an iPhone app to talk to the video server.=A0 The video server is under the control of a police agency, and police officers must logon to the video server in order to access video content.=A0 So the police office launches their iPhone video client app.

=A0

If I wanted to solv= e authentication using =93traditional=94 client-server authentication, the use= r enters their username / password into the client, and the client sends the username / password off to the server, which authenticates it, or possibly uses HTTP digest.=A0

If I wanted to us= e OpenID, the client would attempt to reach the video server (RP), the server would redirect the client to the OP, OP authenticates user, and OP redirects client back to the server/RP with an assertion that primary authentication was successful.=A0

If I wanted to us= e OAuth, the client would send an authorization request to the server=92s AS, which would authenticate the user of the client, and ultimately result in the client possessing an access-token.=A0 My thinking is that this access token (let=92s assume it=92s a JWT) would contain the user=92s identity, a statement of what type of primary authentication was used (auth context), an expiration, and an audience claim.=A0 This sounds a lot like authentication to me, and it=92s where I get confused.=A0 Is it just because OAuth does not explicitly define this?=A0 Is there a threat in using OAuth as I describe?=A0

If I wanted to use Connect, well I=92m not even sure how the id_token as defined by Connect helps this use case.=A0 The id_token seems to make sense when the client is a confidential web server, but it=92s not clear what an iPhone app would do with the id_token =85 it=92s the serve= r in the backend that needs to authenticate the user, the iPhone app is just an interface to talk to the server.=A0 And it seems as I learn more about connect that the id_token is not meant to be sent from the iPhone app to the server, just the access token.=A0 So it=92s really not clear how Connect helps solve authentication for an iPhone client app talking to a video server.=A0 If I=92m sending access-tokens, it=92s j= ust OAuth again.

=A0=

What am I still missing?=

adam

=A0=

=A0=

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Kristofor Selden
Sent: Saturday, June 16, 2012 11:33 AM
To: nov matake; oauth
Cc: Yuchen Zhou; Luke Melia; Shuo Chen (MSR)
Subject: Re: [OAUTH-WG] Report an authentication issue

=A0

Nov demonstrated the problem to us at Yapp and we used solution 4 (because the solution is server side and our app was in the app store).

=A0

FB Connect is authentication and authorization, where OAuth 2 is concerned only with authorization =96 I'm not s= ure that app developers appreciate this subtlety.

=A0

With OAuth 2 you authorize an app to use a protected resource. =A0With FB Connect, you do that, but also authenticate with the app you are authorizing.

=A0

So the access_token protects not just the FB resources but the auth end point of the authorized app (very common with apps that use the iOS SDK). =A0So now the app needs a way to verify that it was the app that was authorized to FB.

=A0

Solution 4 explanation: on FB you can register a iPhone app and a server app with the same client_id and get a client_secret for use on the server. =A0The server side API posts the access_token,=A0client_id, and=A0client_secret to= =A0https://graph.facebook.com/app=A0to=A0verify that the bearer token actually belongs to the app that is being authenticated before assuming they are authorized to the app's protected resources.

=A0

Kris

=A0

On Jun 15, 2012, at 8:22 PM, nov matake wrote:

<= br>

There are 4 ways to fix this issue.

=A0

1. Use response_type=3Dtoken%20code (It's=A0not in OAuth 2.0 Core, but seems best way for interoperability)

2. Use singed_request (or some signed token like JWT)

3. Use grant_type=3Dfb_exchange_token (Facebook custom way)

4. Access to https://graph.facebook.com/app?access_token=3DYOUR_TOKEN (Facebook custom way, moreover undocumented API)=

=A0

Two iPhone app developers I reported this issue fixed it by using (4).

=A0

I also tried to use (1) for my own iPhone app implementation, but unfortunately it doesn't work when using authorization codes obtained via FB iOS SDK.<= /p>

So I'm using (3) in my case.

=A0

nov

=A0

On 2012/06/16, at 9:16, Nat Sakimura wrote:



As to how the fix was done, Nov can provide more detail, but ...=A0

=A0<= /p>

1. Properly verify the signature/HMAC of the "signed_request". This= will essentially audience restricts the token.=A0

2. There is an undocumented API for Facebook which returns to whom the token was issued. This also audience restricts the token.=A0

=A0<= /p>

The service that fixed took these measures. Note that none of the above is defined in OAuth.=A0=

The same facility was called "id_token"= ; and "check ID endpoint" for OpenI= D Connect.=A0

=A0<= /p>

The scale of the impact is large, too large to disclose the actual names in the public list, though, eventually, we would publish them in a paper.=A0

=A0<= /p>

Nat

On Sat, Jun 16, 2012 at 5:34 AM, Francisco Corella <fcorella@pomcor.com> wrote:

Hi Nat and Rui,

Rui, you say that the vulnerability that you found was due to a
"common misunderstanding amo= ng developers", but the attack you
describe can be carried out against any app that uses the OAuth
"implicit grant flow", = which Facebook calls "client-side<= br> authentication".=A0 No misunderstanding seems necessary.=A0 What
misunderstanding are you referring to?=A0 I followed the link in your
message to the Sophos post, and from there the link to the article in
The Register.=A0 The article in The Register says that Facebook had
"fixed the vulnerability promptly".=A0 How did they f= ix it?=A0 The
instructions that Facebook provides for implementing "Client-side
authentication without the JS SDK" at
http= s://developers.facebook.com/docs/authentication/client-side/#no-jssdk still allows the attack.

Nat, I agree that the blog post by John Bradley that you link to
refers to the same vulnerability reported by Rui.=A0 You say that some
apps have issued a patch to fix it.=A0 Could you explain what the fix
was?

Francisco

=A0

From:= Nat Sakimura <sakimura@gmail.com>
To: rui wang <ruiwangwarm@gmail.com>= ;
Cc: matake nov <nov@matake.jp>; Yuchen Zhou <t-yuzhou@microsoft.c= om>; oauth <oauth@ietf.org>; Shuo Chen (MSR) <shuochen@microsoft.com>
Sent: Thursday, June 14, 2012 1:50 PM
Subject: Re: [OAUTH-WG] Report an authentication issue

= =A0

This is a fairly well known (hopefully by now) issue. We, at the OpenID Foundation, call it "access_tok= en phishing" atta= ck these days. See:=A0http://www.thread-safe.com/2012/01/problem-with-oauth-= for-authentication.html

=A0

Nov Matake has actually built the code on iPhone to verify the problem, and has notified bunch of parties back in February including Facebook and Apple. We have the code that actually runs on a phone, and we have successfully logged in to bunch of apps, including very well known ones. They were all informed of the issue. Some immediately issued a patch to fix it while others have not. =A0<= /u>

=A0

The problem is that even if these apps gets fixed, the problem does not go away. As long as the attacker has the vulnerable version of the app, he still can impersonate the victim. To stop it, the server side has to completely disable the older version, which means the service has to cut off many users pausing business problems.=A0

=A0

Nat

On Fri, Jun 15, 2012 at 2:18 AM, rui wang <ruiwangwarm@gmail.com> wrote:<= /u>

Dear Facebook Security Team and OAuth Standard group,<= /u>

We are a research team in Microsoft Research. In January, 2011, we reported a vulnerability in Facebook Connect which allowed everyone to sign into Facebook-secured relying parties without password. It was promptly fixed after reporting. (http://nakedsecurity.sophos.com/2011/0= 2/02/facebook-flaw-websites-steal-personal-data/)

Recently, we found a common misunderstanding among developers of mobile/metro apps when using OAuth (including Facebook=92s OAuth) for authentication. The vulnerability resulted from this misunderstanding also allows an attacker to log into a victim user's account without password.<= u>

Let's take Soluto's metro app as an example to describe the problem. The app supports Facebook Login. As an attacker, we can write a regular Facebook app. Once the victim user allows our app to access her Facebook data, we receive an access_token from the traffic. Then, on our own machine (i.e., the "attacke= r" machine), we run the metro app of Soluto, and use a HTTP proxy to insert the victim's access_token into the traffic of Facebook login. Through this way, we are able to log into the victim's Soluto account from our machine. Other than Soluto, we also have confirmed the same issue on another Windows 8 metro-app Givit.<= /u>

The Facebook SDK for Android apps (https://developers.facebook.com/docs/mobile/android/build/#sdk) seems to have the possibility to mislead developers too. At least, the issue that we found is not clearly mentioned. In the SDK, we ran the sample code called "Hackbook&qu= ot; using Android Emulator (imagine it is an attacker device). Note that we have already received the access token of the victim user from our regular Facebook app. We then inject the token to the traffic of Hackbook. Through this way, Hackbook app on our own machine recognizes us as the victim. Note that this is not a convincing security exploit yet, because this sample code does not include the server-side code. However, given that we have seen real server-side code having this problem, such as Soluto, Givit and others, we do believe that the sample code can mislead mobile/metro developers. We also suspect that this may be a general issue of many OAuth implementations on mobile platforms, so we send this message to OAuth Standard group as well.=

We have contacted the vendors of the two vulnerable metro-apps, Soluto and Gavit.<= /u>

Please kindly give us an ack when you receive this message. If you want to know more details, please let us know.

Best Regards,
Yuchen Zhou, Rui Wang, and Shuo Chen<= u>


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



=A0

--
Nat Sakimura (=3Dnat)

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

=A0


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



=A0

--
Nat Sakimura (=3Dnat)

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

=A0<= /p>

____________________= ___________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oaut= h

=A0

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

=A0


_______________________________________________=

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

= =A0

=A0
=A0
_______________________________________________=

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


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



=A0

--
Nat Sakimura (=3Dnat)

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

=A0


_______________________________________________
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

--001517402de626811804c337daae-- From eran@hueniverse.com Sun Jun 24 06:34:59 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D87B421F8697 for ; Sun, 24 Jun 2012 06:34:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 xziu54hiw-iB for ; Sun, 24 Jun 2012 06:34:59 -0700 (PDT) Received: from p3plex2out01.prod.phx3.secureserver.net (p3plex2out01.prod.phx3.secureserver.net [184.168.131.12]) by ietfa.amsl.com (Postfix) with ESMTP id 1328E21F867D for ; Sun, 24 Jun 2012 06:34:59 -0700 (PDT) Received: from P3PWEX2HT003.ex2.secureserver.net ([184.168.131.11]) by p3plex2out01.prod.phx3.secureserver.net with bizsmtp id SDay1j0040EuLVk01DayWN; Sun, 24 Jun 2012 06:34:58 -0700 Received: from P3PWEX2MB008.ex2.secureserver.net ([169.254.8.66]) by P3PWEX2HT003.ex2.secureserver.net ([184.168.131.11]) with mapi id 14.02.0247.003; Sun, 24 Jun 2012 06:34:58 -0700 From: Eran Hammer To: Hannes Tschofenig , OAuth WG Thread-Topic: [OAUTH-WG] OAuth Parameter Registration Template Thread-Index: AQHNUgvE5MIjNXPlmk2UuemCkhv0oJcJd39A Date: Sun, 24 Jun 2012 13:34:58 +0000 Message-ID: <0CBAEB56DDB3A140BA8E8C124C04ECA20107EC1F@P3PWEX2MB008.ex2.secureserver.net> References: <4F1F7754-CF91-4C07-A4B6-20AB94C2E2B2@gmx.net> In-Reply-To: <4F1F7754-CF91-4C07-A4B6-20AB94C2E2B2@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [37.46.44.161] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] OAuth Parameter Registration Template X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 13:35:00 -0000 It is pretty obvious these refer to the two well defined endpoints in secti= on 3. I will add a reference next to the locations to make this even cleare= r. There is no such endpoint as client authentication as a location. OAuth cor= e clearly defines three endpoints for which two are extensible via regisrat= ion. Anything else is out of scope. No other changes are needed or appropriate. EH > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Hannes Tschofenig > Sent: Sunday, June 24, 2012 6:18 AM > To: OAuth WG > Subject: [OAUTH-WG] OAuth Parameter Registration Template >=20 > Hi all, >=20 > working on the proposed text for the OAuth assertions draft I noticed an > interesting aspect in the core specification regarding Section 11.2.1, wh= ich > defines the registration template for OAuth parameters. >=20 > The template lists all possible usage locations of parameters, namely > authorization request, authorization response, token request, or token > response. >=20 > Here is the first issue: these locations are not defined anywhere in the > document and so one can only guess to what part of the protocol exchange > they belong. >=20 > I agree that it may not be very difficult to guess but obviously it is no= t > completely obvious. It would have been nice if there is actually a match = with > Figure 1, for example. >=20 > http://tools.ietf.org/html/draft-ietf-oauth-assertions-03, for example, u= ses a > location that is not in the above list, namely 'client authentication'. >=20 > Client authentication can also happen in the interaction between the clie= nt > and the resource server but the exchanges are not part of the allowed lis= t of > usage locations. >=20 > Ciao > Hannes >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From Hannes.Tschofenig@gmx.net Sun Jun 24 06:42:40 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E4DF21F868A for ; Sun, 24 Jun 2012 06:42:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.031, 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 iTLe3oYXy21v for ; Sun, 24 Jun 2012 06:42:39 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id B0ECA21F8680 for ; Sun, 24 Jun 2012 06:42:38 -0700 (PDT) Received: (qmail invoked by alias); 24 Jun 2012 13:42:37 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.109]) [88.115.216.191] by mail.gmx.net (mp033) with SMTP; 24 Jun 2012 15:42:37 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+WXp5aUJeWtm4o9XAqsQYZMVTxpCYsbfHo+/KOvW I4BaXOzpWsU64g Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Hannes Tschofenig In-Reply-To: Date: Sun, 24 Jun 2012 16:42:36 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <12F7B6DB-A371-4C53-8B5B-B34F3750E507@gmx.net> References: <699C916A-F8B1-40E8-8C3B-FCC9CBCC2C9F@gmx.net> To: Brian Campbell X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-assertions-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: Sun, 24 Jun 2012 13:42:40 -0000 Hi Brian,=20 thanks for your response. I have tried to put additional text into = version -04 of the draft to address my earlier comments.=20 The most recent version of the updated document is there: = https://github.com/hannestschofenig/tschofenig-ids/blob/master/oauth-asser= tions/draft-ietf-oauth-assertions-04.txt Here is the XML:=20 = https://github.com/hannestschofenig/tschofenig-ids/blob/master/oauth-asser= tions/draft-ietf-oauth-assertions-04.xml It took me a little while to make these changes, as you can imagine. I = hope I was able to improve the quality and clarity of the document.=20 I still have to respond to your second mail about the relaxed usage of = the RFC 2119 language. Will do that asap.=20 Ciao Hannes On May 30, 2012, at 11:46 PM, Brian Campbell wrote: > Thanks for the comments Hannes. I've attempted to answer some of your = questions/comments inline below (or at least provide some additional = info, context or explanation). >=20 > On Thu, May 24, 2012 at 12:39 PM, Hannes Tschofenig = wrote: > Hi Chuck, Mike, Brian, and Yaron, >=20 > I reviewed the document as part of my shepherding role and I believe = there is still room for improvement with the document. I think the = document suffers from the problem that you essentially want to cover = every possible use case in a single document. So, let me start with a = high-level mail. >=20 > You are covering two quite different usage scenarios that are only = related to each other by the usage of assertions, namely >=20 > 1. Using Assertions for Client Authentication >=20 > 2. Using Assertions as Authorization Grants >=20 > (Of course these two usages can happen in the same protocol exchange; = this means that you have two assertions in the same message obtained = from different entities with potentially very different properties.) >=20 > It is OK to have these two cases in a single document but the = introduction and section 3 need to untangle them and to describe the use = cases to the reader. In fact, the second part of the document (from = section 4 onwards) does a better job in separating the two cases. >=20 > Yeah, putting them together has its advantages and disadvantages and = causing confusing between the two cases is one of the biggest downsides. = Proposed text that helps untangle the two usages for the = reader/implementer would most definitely be welcomed.=20 >=20 > =20 > I was also wondering what use cases you guys find most interested = among all the options I list below? What have you implemented and = deployed (I need that info for the shepherd writeup)? Maybe we should = highlight them in the intro. >=20 >=20 > The primary case I've seen deployed is in an "enterprise to SaaS" = model using SAML assertions as authorization grants. The enterprise has = some kind of STS that can issue assertions and trust has been = established between the STS and the enterprise's accounts at the SaaS. = The client presents some kind local authentication/authorization to the = STS and receives a suitable assertion in exchange. That exchange is via = WS-Trust in the deployments I've seen but that's far from the only way = it can be done. Once the client has the assertion, the OAuth assertion = profile/grant type can be employed to get an OAuth access token from the = AS at the SaaS. Then that token be used to access the SaaS's protected = resources/APIs. The trust established between the enterprise STS and the = SaaS is usually already in place and being used to facilitate Web SSO = traffic. >=20 > For the sake of disclosure, my company offers a product that acts in = the STS role described above and one of my co-author's companies is very = often the SaaS. Our product also supports the AS role in that exchange = to help enable organizations to do what the aforementioned SaaS is = doing. =20 >=20 > In my experience there has been more initial interest in assertions as = grants than for client authentication. But I'll note that OpenID Connect = specifically calls out the JWT assertion profile as one option for = client authentication. >=20 > =20 >=20 > Regarding the security aspects: I assume that the assertions is always = signed. (I guess you make this assumption as well.) >=20 > Yes and the draft should say as much. The end of =A75.2 explicit says = "The Authorization Server MUST validate the assertion's signature..." = and there are a number of other places where the text would seem to = imply that the token/assertion is always singed. Do you think it needs = to be made more explicit? >=20 >=20 > There are a few considerations: >=20 > a) Who creates and signs the assertion? >=20 > It really depends on the situation. The draft in =A75.1 defines it as = the Issuer and attempts to give some ideas about how that might work = without being overly prescriptive or restrictive. > =20 >=20 > You sometimes use the term "Security Token Service (STS)" but it is = not introduced in the terminology. Let us assume that this is a third = party entity (and not a role the client can take). >=20 > So, we have two cases: >=20 > -- Assertions obtained from the STS >=20 > -- Assertions self-generated by the client >=20 > Needless to say that the security properties are different between the = two. In the second case the party receiving the assertion cannot trust = the content in the assertion since it had been minted by the client, an = untrusted party. >=20 > The client is not necessarily untrusted. In the case where the client = is the issuer, it really needs to be trusted for it to work. That = probably makes the most sense when using assertions as client = authentication where the client sends an assertion that demonstrates = possession of a (symmetric or asymmetric) secret. But it really depends = on the situation so that's just one possibility.=20 > =20 >=20 > Also note that the protocol for obtaining the assertion from the STS = may not have been standardized, which consequently does not necessarily = increase interoperability when deploying such a solution. Any story for = this? How did you handle this in your implementations & deployments? >=20 > Interoperability between the client and the AS is the primary goal of = this spec (and the SAML/JWT incarnations of it). That may impose some = requirements on the STS with respect to the actual content and format of = the assertion. However, the rest of the client <-> STS exchange should = have no bearing on interop (other than between those two parties but = that is out of scope here). =20 >=20 > For what it's worth, as I mentioned earlier, my product offers = WS-Trust as a means for obtaining the assertion. It's not the only way = and it's arguably not ideal. But it is a standard for token exchange and = it was something we already had a lot of infrastructure in place to = support in our product. > =20 >=20 > Let us focus on the cases where the assertion is obtained from an STS. = Then, the assertion is signed by the STS (hopefully) and if the client = presents it then it can do that in two ways: >=20 > -- Conveying the assertion as a Bearer Assertion (i.e., possession is = the security) and hopefully the exchange runs over TLS. Replay = protection can be provided via the parameters in the assertion assuming = the client has a capability to obtain assertions on the fly using some = protocol to essentially present a refresh assertion with (almost) every = exchange since otherwise the provided security really suffers. >=20 > FWIW, this whole document more or less assumes that the assertion will = be a bearer assertion. I don't think there's anything necessarily = preventing a holder of key profile from being written on top of it but = the SAML/JWT realizations of this draft are explicitly and intentionally = limited in scope to the bearer case. >=20 > And yes, this exchange must run over TLS (OAuth core at = http://tools.ietf.org/html/draft-ietf-oauth-v2-26#section-3.2 mandates = it for the token endpoint which then is inherited by this spec). > =20 >=20 > -- Using the assertion together with a holder-of-the-key concept. In = this case the assertion would be signed by the STS and then the client = in addition needs to show possession of a secret (which is bound to the = token). This secret (either a shared key or a public/private key pair = had been obtained somehow). >=20 > Again, I think a HoK assertion/confirmation could be profiled from = this draft but it hasn't been done yet and I really haven't heard anyone = asking for it. > =20 >=20 > Furthermore, the document at various places talks about the great = security properties and I believe that this is a bit misleading. The = great security properties are only there when you either use >=20 > * a STS obtained assertion with a holder-of-a-key assertion, or >=20 > * let the client sign the assertion (in which case the assertion is = quite degenerated*). >=20 > I believe those security benefits are really only particularly = relevant for [H]MAC'd assertion being used for client authentication as = an alternative to sending the client secret directly via HTTP Basic or = as a parameter. This should probably be made more clear so as not to be = misleading. >=20 >=20 > It may also be worth noting that not all assertions can be signed with = symmetric as well as asymmetric credentials. A SAML assertion, for = example, can only be signed with an asymmetric credential (at last to my = knowledge). >=20 >=20 >=20 > That is standard practice with SAML and the only thing I've ever seen = implemented/deployed but there is nothing that actually mandates = asymmetric signatures in SAML. >=20 > =20 > Ciao > Hannes > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 From bcampbell@pingidentity.com Sun Jun 24 06:45:12 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DAE621F868A for ; Sun, 24 Jun 2012 06:45:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.992 X-Spam-Level: X-Spam-Status: No, score=-5.992 tagged_above=-999 required=5 tests=[AWL=-0.015, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZWZAZZ3Rp0EY for ; Sun, 24 Jun 2012 06:45:11 -0700 (PDT) Received: from na3sys009aog118.obsmtp.com (na3sys009aog118.obsmtp.com [74.125.149.244]) by ietfa.amsl.com (Postfix) with ESMTP id 69BDB21F8680 for ; Sun, 24 Jun 2012 06:45:11 -0700 (PDT) Received: from mail-ob0-f170.google.com ([209.85.214.170]) (using TLSv1) by na3sys009aob118.postini.com ([74.125.148.12]) with SMTP ID DSNKT+cZ5g0rrpYqERzFlFf9ftbmV+16lkNR@postini.com; Sun, 24 Jun 2012 06:45:11 PDT Received: by obfk16 with SMTP id k16so6000265obf.29 for ; Sun, 24 Jun 2012 06:45:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=AJyjt4LdHXdeodkDwwa/vwZZ49r4iTrZZtEFYPBCWRk=; b=olKA92ZsE9dpGt/IBxYPUgichI2emZWgPaVhVZqOXWH6xHAJMDez6dPF4dFbVraDtj 7YCfC2Vk3gLIt2mfQPudIkNInOZU7q6kfcH4mwSwFTlddG7s9QnlTRdfGgM/UvppdXaX wOctzUDlUyH7kS23wEy/1ngwK/HNhSO8624WnzXteodoqwwZChglw9VvoNOjwapsXw4V PlcTHD5G6EWpls/tFDNvTbAHOXbbRdGpCTo7CaLrhSjG8HYpxpcGjHlSJSR1AP/Yh6/A wem/+xXZ1lvByhU2i1E+G7ftySYmpK7D5+ttcXO53neohyEzDeDf7iuPLB9YqI/gQZ+q j7GA== Received: by 10.60.19.34 with SMTP id b2mr4772600oee.41.1340545510285; Sun, 24 Jun 2012 06:45:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.174.98 with HTTP; Sun, 24 Jun 2012 06:44:40 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366565C40@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <575E933A-6FEF-4821-8677-319FE72564D7@gmx.net> <4E1F6AAD24975D4BA5B168042967394366565C40@TK5EX14MBXC283.redmond.corp.microsoft.com> From: Brian Campbell Date: Sun, 24 Jun 2012 07:44:40 -0600 Message-ID: To: Mike Jones Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnrKlHLZ/SAdYvAiEq/c2jt+HzVLc5Q+rtDG0Of1/tmBDbEQMMqbOYsVg2RMRyTkQNXNO7n Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth URN Registry Discussion Summary X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 13:45:12 -0000 I concur. RFC 3553 does say the "colon character (":") is used to denote a very limited concept of hierarchy" and the current text in -04 uses the colon consistent with that limited concept of hierarchy. However, as Mike already said, the intent of http://tools.ietf.org/html/draft-ietf-oauth-urn-sub-ns is that it be a general naming convention and not something that need be part of the registry. On Sat, Jun 23, 2012 at 12:41 PM, Mike Jones wrote: > I'd rather that we did the review based upon the current draft rather tha= n rolling back. > > Hannes, my point about three levels was that we can't necessarily know up= front what the structure of URNs would be that might make sense to registe= r in the future. =A0I was using that possibility as an example to object to= a strict two-level hierarchy. =A0Sometimes a one-level name may make sense= as well. > > I agree with you that Section 3 of http://tools.ietf.org/html/rfc3553 say= s about the colon character (":") defines a lightweight syntax for hexarchi= es to use when they make sense. =A0I just think it's overkill to put the hi= erarchy in the registry, per se. > > I agree that in http://datatracker.ietf.org/doc/draft-ietf-oauth-assertio= ns we should add IANA considerations text saying that any new extensions fo= r client assertions should be registered with the name client-assertion-typ= e:*. =A0Likewise we should figure out the right place to say that new grant= types should be registered as grant-type:*. =A0These would be naming conve= ntions though - not something that's a part of the registry. > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Cheers, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-- Mike > > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of= Hannes Tschofenig > Sent: Saturday, June 23, 2012 8:17 AM > To: OAuth WG > Subject: [OAUTH-WG] OAuth URN Registry Discussion Summary > > As you have seen I have responded to various mails and I believe I unders= tand what people want. > > Some of you obviously have plans to write extensions (in other organizati= ons outside the IETF, and as vendor-specific extensions). =A0That's fine. > > You want something really lightweight (in terms of process) that does not= require you to come to the IETF to write an RFC and get the entire working= group excited about your hobby project. Clearly, this makes sense to me. > > So, the policy for adding new extensions has to be either 'Specification = Required' or 'Expert Review' with the difference being about the informatio= n that goes into the registry. For the cases I have seen on the list it wil= l not make a huge difference. It may make a difference for an organization = where their final specifications are not publically available. Yes, these o= rganizations still exist today.... > > Then, there is the question about how the identifier that gets registered= should look like. You seem to like the idea of concept of a structured ide= ntifier (since otherwise you wouldn't be using it in various working group = drafts already, including the example in draft-ietf-oauth-urn-sub-ns itself= !) but you don't like to call it hierarchy because you fear that you will n= ot be allowed to do whatever you want. An unjustified concern. > > In that sense version -03 of the draft (see http://tools.ietf.org/id/draf= t-ietf-oauth-urn-sub-ns-03.txt) pretty much does already everything you wan= t already do. As a policy it says "Expert Review" and it has the structure = in the ID that you guys are using in your current drafts! > > There are two options to go forward. > > The first one is to roll-back to version -03. > > Another option is to take version -04 and add text that explains the = a bit further by saying that it may contain a structure and other document= s populating the registry will define the detailed structure of the pa= rt. > > In http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ we would = then add a section to the IANA consideration section saying that any new ex= tensions for client assertions needs to be registered under urn:ietf:params= :oauth:client-assertion-type: > > The same for urn:ietf:params:oauth:grant-type: in some other document and= so on. > > 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 From bcampbell@pingidentity.com Sun Jun 24 07:02:34 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BA2121F861A for ; Sun, 24 Jun 2012 07:02:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.991 X-Spam-Level: X-Spam-Status: No, score=-5.991 tagged_above=-999 required=5 tests=[AWL=-0.014, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jeJNp-g-dUEa for ; Sun, 24 Jun 2012 07:02:33 -0700 (PDT) Received: from na3sys009aog108.obsmtp.com (na3sys009aog108.obsmtp.com [74.125.149.199]) by ietfa.amsl.com (Postfix) with ESMTP id 1535621F8609 for ; Sun, 24 Jun 2012 07:02:33 -0700 (PDT) Received: from mail-ob0-f177.google.com ([209.85.214.177]) (using TLSv1) by na3sys009aob108.postini.com ([74.125.148.12]) with SMTP ID DSNKT+cd+PsHaxAMFNYlOgXiz3iqFika7qYO@postini.com; Sun, 24 Jun 2012 07:02:33 PDT Received: by obbta17 with SMTP id ta17so6096962obb.8 for ; Sun, 24 Jun 2012 07:02:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=AyA0coHvHJUzUNMi1cnJChV7uTzfp40FSdRamFy15Po=; b=TtLXEkjyclXVQrSrUYocKnZRO+1Crry9z5Zt0bCKlMpiWxYBNQCrHeJSzxXDRvR4Ym ShsExDP+s+7utTD6l2CXfVgS5PChWqWAaaoeDlQbDFlRDSsiCR1jWbion5EtzubHzJun fFZ52kXnM+Zd6Pi4kLXsPCVLBWSWzPJTGTTl5ZvyN/L7Nv9Y+G9NEzWtW7pPuQY9ZZVi lMHzygodrJR5QlsRY8z5GNUI02VHjP1SRS635svM9dpB5sDxECO+dqy8bqlI9ktZCEzX iO1wDHtXU+6KYiXpCkQlYs1FulcLkMVhGhzJCK0XNRjQqXgs4P9zd478hlXEslILo/oc 9oig== Received: by 10.60.170.203 with SMTP id ao11mr9066972oec.25.1340546552223; Sun, 24 Jun 2012 07:02:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.174.98 with HTTP; Sun, 24 Jun 2012 07:02:02 -0700 (PDT) In-Reply-To: <4F1F7754-CF91-4C07-A4B6-20AB94C2E2B2@gmx.net> References: <4F1F7754-CF91-4C07-A4B6-20AB94C2E2B2@gmx.net> From: Brian Campbell Date: Sun, 24 Jun 2012 08:02:02 -0600 Message-ID: To: Hannes Tschofenig Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmendYg+Je1nOKkT6PJXpLmdLQsGbIfR7wgFASRpCRsF/7Lkqab4kB8xccO+uqyuV2SLEx/ Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth Parameter Registration Template X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 14:02:34 -0000 On Sun, Jun 24, 2012 at 7:17 AM, Hannes Tschofenig wrote: > > http://tools.ietf.org/html/draft-ietf-oauth-assertions-03, for example, uses a location that is not in the above list, namely 'client authentication'. That's a mistake in http://tools.ietf.org/html/draft-ietf-oauth-assertions-03 - I actually thought I'd reconciled all the parameter usage location registry stuff in that latest draft but apparently it still needs some work. From hannes.tschofenig@gmx.net Sun Jun 24 09:41:26 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACB1621F85D5 for ; Sun, 24 Jun 2012 09:41:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 WA95LmuBOuGe for ; Sun, 24 Jun 2012 09:41:26 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 370F521F85D3 for ; Sun, 24 Jun 2012 09:41:23 -0700 (PDT) Received: (qmail invoked by alias); 24 Jun 2012 16:41:22 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.109]) [88.115.216.191] by mail.gmx.net (mp028) with SMTP; 24 Jun 2012 18:41:22 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19JGtdpOWJJymNn9apfg9HKNAD8aKfVvAaq3LXujv jZRF/M/aKrnGHu Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <0CBAEB56DDB3A140BA8E8C124C04ECA20107EC1F@P3PWEX2MB008.ex2.secureserver.net> Date: Sun, 24 Jun 2012 19:41:20 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F1F7754-CF91-4C07-A4B6-20AB94C2E2B2@gmx.net> <0CBAEB56DDB3A140BA8E8C124C04ECA20107EC1F@P3PWEX2MB008.ex2.secureserver.net> To: Eran Hammer X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth Parameter Registration Template X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 16:41:26 -0000 Hi Eran,=20 On Jun 24, 2012, at 4:34 PM, Eran Hammer wrote: > It is pretty obvious these refer to the two well defined endpoints in = section 3. True. The first few paragraphs of Section 3 lists the available end = points.=20 Btw, the section headings are a bit strange:=20 3. Protocol Endpoints=20 3.1 Authorization Endpoint 3.2 Token Endpoint 3.3 Access Token Scope=20 > I will add a reference next to the locations to make this even = clearer. >=20 Thanks.=20 Maybe you want to add that this specification only defines these usage = locations for parameter (based on the defined endpoints) and other = documents may define new end points and extend the list of possible = parameter usage locations.=20 > There is no such endpoint as client authentication as a location. Notice that.=20 > OAuth core clearly defines three endpoints for which two are = extensible via regisration. Anything else is out of scope. While the specification says that you can define new endpoints it may be = useful to link that statement with the usage location for the = parameters.=20 >=20 > No other changes are needed or appropriate. >=20 Ciao Hannes > EH >=20 >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf >> Of Hannes Tschofenig >> Sent: Sunday, June 24, 2012 6:18 AM >> To: OAuth WG >> Subject: [OAUTH-WG] OAuth Parameter Registration Template >>=20 >> Hi all, >>=20 >> working on the proposed text for the OAuth assertions draft I noticed = an >> interesting aspect in the core specification regarding Section = 11.2.1, which >> defines the registration template for OAuth parameters. >>=20 >> The template lists all possible usage locations of parameters, namely >> authorization request, authorization response, token request, or = token >> response. >>=20 >> Here is the first issue: these locations are not defined anywhere in = the >> document and so one can only guess to what part of the protocol = exchange >> they belong. >>=20 >> I agree that it may not be very difficult to guess but obviously it = is not >> completely obvious. It would have been nice if there is actually a = match with >> Figure 1, for example. >>=20 >> http://tools.ietf.org/html/draft-ietf-oauth-assertions-03, for = example, uses a >> location that is not in the above list, namely 'client = authentication'. >>=20 >> Client authentication can also happen in the interaction between the = client >> and the resource server but the exchanges are not part of the allowed = list of >> usage locations. >>=20 >> Ciao >> Hannes >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth From dick.hardt@gmail.com Sun Jun 24 11:38:50 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37E0321F85D2 for ; Sun, 24 Jun 2012 11:38:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.348 X-Spam-Level: X-Spam-Status: No, score=-3.348 tagged_above=-999 required=5 tests=[AWL=-0.350, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_65=0.6, 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 hMHfVyKg0u2P for ; Sun, 24 Jun 2012 11:38:47 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0D0DA21F85BB for ; Sun, 24 Jun 2012 11:38:47 -0700 (PDT) Received: by dacx6 with SMTP id x6so4395957dac.31 for ; Sun, 24 Jun 2012 11:38:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=5xSwNezQ4IvRCvbgGBdmIOYApQk875G+movJAnqmdgQ=; b=suPjlmKQGs32Gf0fI4WxGNj7/zD8zSktgROYA/e2HIvK04IgVxXy0m/s4djPqvTLX9 9AOOmKpiAcM17OEDy+7VYNfx0Nil5HFEXU9ElqVaNwAyywXsVSFxKSN07vduFBz3xGnM l2ZS9ATS2aAbodMavqPLUB8DxIaH2ZSoZQ7uOZGTDPNohIQUJs0KHeb735pZYanEE/Nw im8ICJdygs2pgm6r3u1hYRhqD7dR3xvm7O+ibyFZT5VJL5C+98FHNvZexCOvnk7KSgSg /rWBFNwdNnOosMhlcEJW3shocX6pCqevT4bS/2jOjRYqL8tuaC7wfKixd5qwcQEsSTu/ w6jg== Received: by 10.68.136.68 with SMTP id py4mr31711654pbb.151.1340563126182; Sun, 24 Jun 2012 11:38:46 -0700 (PDT) Received: from [10.0.0.58] (c-24-5-69-173.hsd1.ca.comcast.net. [24.5.69.173]) by mx.google.com with ESMTPS id ux8sm5121713pbc.5.2012.06.24.11.38.42 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 24 Jun 2012 11:38:44 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_F13DA233-34C8-49EB-B147-4F8F8CD9F4D6" From: Dick Hardt In-Reply-To: <0CBAEB56DDB3A140BA8E8C124C04ECA20107E583@P3PWEX2MB008.ex2.secureserver.net> Date: Sun, 24 Jun 2012 11:38:41 -0700 Message-Id: References: <854774286EF8A240BACC342973A86EAC016693D6@BL2PRD0310MB387.namprd03.prod.outlook.com> <484A13D0-7C9A-42CC-BB94-3657741834DE@ve7jtb.com> <82D95BA2-1697-4441-BBB3-B2AE480DC39E@gmail.com> <4FE609C6.9020902@lodderstedt.net> <7F9928C8-9B11-4F3B-93A0-2469403F6569@ve7jtb.com> <0CBAEB56DDB3A140BA8E8C124C04ECA20107E583@P3PWEX2MB008.ex2.secureserver.net> To: Eran Hammer X-Mailer: Apple Mail (2.1278) Cc: rui wang , Yuchen Zhou , "Shuo Chen \(MSR\)" , Derek Atkins , "oauth@ietf.org" Subject: Re: [OAUTH-WG] proposal of a paragraph to add to the security considerations section X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 18:38:50 -0000 --Apple-Mail=_F13DA233-34C8-49EB-B147-4F8F8CD9F4D6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 No. Not joking. I thought that concept had been removed from David's draft. Given all = the rearrangements you did to the specs, what was in and out was = difficult to track. I have been focusing on ensuring the key features = that were in WRAP continued to be in the spec. Clearly the implicit flow can only be used for authorization to the = resources and not as an identity mechanism. That should be added in. = Would you not agree with me on that and do something as editor to = resolve? -- Dick On Jun 24, 2012, at 12:19 AM, Eran Hammer wrote: > You must be joking. Have you ever read the spec? > =20 > It has been there from draft -00: > =20 > http://tools.ietf.org/html/draft-ietf-oauth-v2-00#section-3.5.1 > =20 > EH > =20 > =20 > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf = Of Dick Hardt > Sent: Saturday, June 23, 2012 8:15 PM > To: John Bradley > Cc: rui wang; Yuchen Zhou; Shuo Chen (MSR); Derek Atkins; = oauth@ietf.org > Subject: Re: [OAUTH-WG] proposal of a paragraph to add to the security = considerations section > =20 > Would someone enlighten me on why the implicit flow is needed? Is it = the extra round trip? If so, I think that would be useful to call out = both the advantages and disadvantages in the spec. (I did not realize = this flow was in OAuth -- it was not in WRAP because of the security = issue) > =20 > -- Dick > =20 > On Jun 23, 2012, at 11:54 AM, John Bradley wrote: >=20 >=20 > Yes it is probably best to keep it short in the main spec, but go into = more detail in the security document. > =20 > OAuth is fine as it is. If you use OAuth as part of another protocol = that protocol should be taking responsibility for it's own security = considerations and not assuming that OAuth will cover everything you are = doing. > =20 > Like it or not once you do federated authentication with OAuth you = have created a different protocol that needs different security = considerations. > =20 > We all sort of know that, the problem is that some people confuse = authentication and authorization as the same thing, so it is worth point = ing out. > =20 > John B. > =20 > On 2012-06-23, at 2:24 PM, Torsten Lodderstedt wrote: >=20 >=20 > Hi John, >=20 > I fully agree with your assessment. This attack utilizes the fact that = some clients rely on the result of a resource server request to login an = user. It is not an attack on the OAuth protocol. And even if a similar = attack on authorization codes will happen to fail for confidential = clients does not mean OAuth is supposed to solve this problem. >=20 > We nevertheless should mention it in the security considerations = section. To make things simple, I suggest to describe and ban this = anti-pattern _in general_ in the security consideration section (similar = to Shuo's initial proposal but more generalized). Additionally, the text = should recommend to use an appropriate technique for id providing such = as OpenID or SAML. >=20 > We also could add a detailed analaysis to the security document. >=20 > best regards, > Torsten. >=20 >=20 > Am 21.06.2012 15:47, schrieb John Bradley: > Hi Hannes, > =20 > MAC tokens protect resources against token leakage to third parties. = That is useful but a different threat. =20 > =20 > The easiest way to get a access token for someone is to have them log = into your site. =20 > =20 > If you can do that the token type makes no difference unless we move = to a asymmetric holder of key token (different discussion). > =20 > The bad client gets the access MAC token and token secret and can re = use it just as it would a bearer token. > =20 > The origin of the post was a contention by someone at Facebook that = profiling OAuth 2.0 on its own is sufficient to produce an = Authentication protocol. > =20 > I was trying to point out that OAuth 2 without any extensions, only = profiling is difficult to impossible to use for authentication as the = attack surface and security considerations are different. > =20 > As it turned out Facebook had extended OAuth 2 with signed requests = and token introspection techniques to address these issues for = themselves. =20 > =20 > The problem as it turned out was that individual apps and app = frameworks like the iOS one made some bad mistakes, by not using the = perhaps under documented extensions. > =20 > The problem is not unique to Facebook in any way they are just a = convenient example. > =20 > Oauth 2 is not surprisingly mostly about protecting the resource. =20 > =20 > Authentication is about protecting the client. > =20 > Audience restriction from openID 2, SAML, WS* etc prevents replay of = tokens issued to one RP/SP at another. =20 > That is sort of authentication protocol threat number 1. > =20 > OAuth has no way to do that with access tokens. > =20 > It can however do it with "code" if the client is confidential. > =20 > So my recommendation is that without extensions to OAuth like = structured tokens (signed_request, id_token) or token introspection = endpoints like=20 > Facebook ( https://graph.facebook.com/app?access_token=3D[The Access = Token]), there is no safe way to use an implicit flow for = authentication. > A code flow where a native app exchanges code for the access token and = then passes the access token back to it's server is also vulnerable = (lots of this in circulation I understand) > =20 > The only safe flow (without extensions) is the code flow where the = client is confidential and the code is directly exchanged for the access = token. > This also requires the definition of a identity API that is protected = by the access token, and out of scope for OAuth. > =20 > So at the end of the day the rational conclusion is that OAuth 2 is a = authorization protocol. =20 > It may be used by Authentication protocols, but it is up to other = specs to define the security considerations for that. > =20 > That however doesn't remove the need to mention the token substitution = attack that non confidential clients are subject to, do to there being = no other mechanism for the client to know who the token was issued to. > =20 > John B. > =20 > =20 > =20 > =20 > =20 > On 2012-06-21, at 5:27 AM, Hannes Tschofenig wrote: >=20 >=20 > Hi John,=20 >=20 > I read through your blog post. I am not sure whether I can entirely = agree with your separation between authentication and authorization. I = believe the core issue here is that=20 >=20 > * anyone who has the token will get access to whatever the token = entitles him or her to do (unless there are restrictions in the token) >=20 > * some attributes are different than others. With authentication you = typically associate that the process took place recently (i.e., it is = fresh) while other attributes do not require the user (as resource = owner) to actively participate in the exchange and the same level of = freshness is not implied. For authentication in a three party protocol = to be useful the three parties have to participate (see = http://tools.ietf.org/id/draft-tschofenig-oauth-signature-thoughts-00.txt)= .=20 >=20 > I understand that one wants to avoid having tokens passed around from = one application to the other one, as it is happening here.=20 >=20 > I remember having some of these discussions with Eran a long time ago. = He anticipated that implementers will not put any constraints in the = tokens and hence they will be misused. This serves as an argument for = him to propose the MAC token specification.=20 >=20 > I proposed text for the security consideration section of the bearer = document a while ago and it even talks about audience restriction as a = recommendation.=20 >=20 > There are two problems with the audience restriction:=20 >=20 > 1) There is no mandatory token format defined nor do we mandate token = content either. Hence we do not strongly require anything specifically = to be put into the tokens.=20 >=20 > 2) In the implicit grant flow the client isn't authenticated and hence = what do you want to put into a token as an audience restriction?=20 >=20 > Finally, I think that the "audience restriction" terminology is a bit = fuzzy for this discussion either.=20 > Audience restriction can mean two things: >=20 > * Allowing the client to verify that the access token has indeed been = issued for him / her.=20 > * Allowing the resource server verify that the received access token = from a specific client has indeed been provided by that client.=20 >=20 > My current believe is that the implicit grant flow is unsuitable for = providing authentication functionality.=20 >=20 > Ciao > Hannes >=20 > On Jun 19, 2012, at 5:50 AM, John Bradley wrote: >=20 >=20 > I can put something together. =20 > =20 > It is mostly a warning about the token substitution attack that any = implicit flow is vulnerable to if used for authentication of the = presenter. > Otherwise known as why audience restriction is a good thing. > =20 > John B. > =20 > On 2012-06-18, at 8:20 PM, Dick Hardt wrote: > =20 > John > =20 > Do you have suggested text per your suggestion below? > =20 > -- Dick > =20 > On Jun 18, 2012, at 2:04 PM, John Bradley wrote: > =20 > I blogged about this in the hypothetical several months = ago.http://www.thread-safe.com/2012/01/problem-with-oauth-for-authenticati= on.html > =20 > Nov Matake and others built some tests and found quite a number of = deployments vulnerable. > = http://www.thread-safe.com/2012/02/more-on-oauth-implicit-flow-application= .html > =20 > The bottom line is that OAuth has no explicit audience restriction for = tokens, hence accepting any token outside of the code flow is subject = to attack. > =20 > In general it is not a issue for authorization, it is however a big = issue then there is a presumption that the presenter of a token that = grants a client access to resource x is the "resource owner" of resource = x, when it is possible that the presenter is any client who has ever had = a access token for resource x. > =20 > We might want to include the why it is insecure in the security = consideration, otherwise people reading the below will likely ignore = the advice as it seems on the surface a touch extreme. > =20 > There are certainly OAuth flows that allow you to do authentication = safely, just not all of them without additional precautions. > =20 > That is why openID Connect has a audience restricted id_token similar = to Facebook's signed request to allow the implicit flows to be safely = used for authentication. > =20 > John B. > =20 > =20 > =20 > =20 > On 2012-06-18, at 4:19 PM, Shuo Chen (MSR) wrote: > =20 > Hi OAuth group, > =20 > This is regarding the recent discussion about an implementation issue = of some cloud services using OAuth for authentication. > Derek Atkins and Dick Hardt suggested the possibility to discuss with = the group a paragraph to add to the security considerations section. > =20 > Derek=92s suggestion: > =3D=3D=3D=3D =3D=3D=3D =3D=3D=3D =3D=3D=3D > Perhaps you could boil it down to a paragraph > or two for addition to the security considerations section that = basically says > "beware of implementing it *this* way because it leads to *that* = attack vector", etc. > =3D=3D=3D=3D =3D=3D=3D =3D=3D=3D =3D=3D=3D > =20 > =20 > Here is out suggested text: > =3D=3D=3D=3D =3D=3D=3D =3D=3D=3D =3D=3D=3D > It has been observed that in multiple occasions that the server-side > authentication logic takes an access token from the client, then > queries the user's profile data from the IdP in order to > "authenticate" the user. This implementation must be forbidden. It > will allow an untrusted app running on a victim=92s client device to > work with an attacker=92s device to sign into the victim=92s account = on the server side. > =3D=3D=3D=3D =3D=3D=3D =3D=3D=3D =3D=3D=3D > =20 > =20 > Thank you. > -Shuo > p.s. below is the email thread giving a better context of the = discussion. > =20 > =20 > -----Original Message----- > From: Derek Atkins [mailto:derek@ihtfp.com] > Sent: Monday, June 18, 2012 11:25 AM > To: Shuo Chen (MSR) > Cc: Hannes Tschofenig; rui wang; Stephen Farrell; Yuchen Zhou; Derek > Atkins; Dick Hardt > Subject: Re: [OAUTH-WG] web sso study... > =20 > Hi, > =20 > "Shuo Chen (MSR)" writes: > =20 > Hi Hannes, Derek and Stephen, > =20 > Thank you for your replies. > =20 > First, let me ask whether it is OK if I share your post with the > OAuth WG > =20 > Yes, please feel free to share it. > =20 > Second, could you describe the attack in more details to me? > =20 > Let's consider the mobile+cloud scenario for concreteness (although > some other scenarios are also applicable). The attack steps are the > following: suppose Alice's tablet runs a Windows 8 Metro app written > by attacker Bob. This app is able to request and obtain an access > token from the IdP (associated with Alice). The app can then send the > access token to Bob's own tablet. Note that there is no security > problem up to this point. However the real problem is that some cloud > services use the access token to query the user's profile data from > the IdP in order to "authenticate" the user. In this case, Bob's > tablet will be able to sign into the cloud service as Alice. We have > confirmed that the cloud services for Soluto Metro App, Givit Metro > App and EuroCup2012 Metro App make this mistake. These are apps in > the official Windows 8 App Store. We actually sampled only a small = portion of the available apps, but believe this is a vulnerability = pattern. > =20 > We don=92t think there is anything wrong in the OAuth spec. It is > developers who didn=92t comprehensively understand the usage of the > access token. In the meanwhile, this vulnerability pattern is not = explicitly excluded by the spec. > More importantly, it has been seen in the wild. > =20 > [from Derek's email] Perhaps you could boil it down to a paragraph > or two for > addition to the security considerations section that basically says > "beware of implementing it *this* way because it leads to *that* = attack vector", etc. > =20 > This is a great idea. I think that although it is difficult to > anticipate in general all kinds of incomprehensive understandings of > average developers, it is very worthwhile to take any common existing > vulnerability pattern as a precious feedback to improve the > specification text. In this case, since we have already seen this > vulnerability pattern on multiple services in the wild, certainly we > should be explicit about it in the security considerations section. > =20 > Our suggested text: > =20 > It has been observed that in multiple occasions that the server-side > authentication logic takes an access token from the client, then > queries the user's profile data from the IdP in order to > "authenticate" the user. This implementation must be forbidden. It > will allow an untrusted app running on a victim=92s client device to > work with an attacker=92s device to sign into the victim=92s account = on the server side. > =20 > Any questions or suggestions? > =20 > Could you please send this to the oauth@ietf.orgmailing list? > =20 > Thanks a lot. > =20 > -Shuo > =20 > -derek > =20 > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Friday, June 15, 2012 11:36 AM > To: rui wang > Cc: Hannes Tschofenig; Stephen Farrell; Shuo Chen (MSR); Yuchen Zhou; > Derek Atkins > Subject: Re: [OAUTH-WG] web sso study... > =20 > Hi Rui, > =20 > let me independently respond (in addition to the previous responses > you had already gotten). > =20 > First, let me ask whether it is OK if I share your post with the > OAuth WG since it is more detailed than the one you distributed on the = list mid April. > =20 > Second, could you describe the attack in more details to me? What I > would like to better understand whether this the raised issue is a > problem with one of our specifications, with a specific > implementation of the IETF OAuth specifications, a problem with other > OAuth related work (Facebook, as you know, implements far more than > just the IETF OAuth specifications), a violation of the IETF OAuth > specification in the way how the Websites use OAuth, whether this is > a configuration related aspect, or an aspect we already documented in = the threats document. > =20 > The reason why I am so specific is to know where to put text to > address this issue or whether this is even an issue beyond the IETF > OAuth working group and needs to be tackled somewhere else. > =20 > Ciao > =20 > Hannes > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > =20 > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > =20 > =20 >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > =20 >=20 > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_F13DA233-34C8-49EB-B147-4F8F8CD9F4D6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 No. Not joking.

I thought that = concept had been removed from David's draft. Given all the = rearrangements you did to the specs, what was in and out was difficult = to track. I have been focusing on ensuring the key features that were in = WRAP continued to be in the spec.

Clearly = the implicit flow can only be used for authorization to the resources = and not as an identity mechanism. That should be added in. Would you not = agree with me on that and do something as editor to = resolve?

-- Dick

On Jun = 24, 2012, at 12:19 AM, Eran Hammer wrote:

You = must be joking. Have you ever read the spec?
It = has been there from draft -00:
 oauth-bounces@ietf.org = [mailto:oauth-bounces@ietf.org] On Behalf Of Dick = Hardt
Sent: Saturday, June 23, 2012 = 8:15 PM
To: John = Bradley
Cc: rui wang; Yuchen Zhou; Shuo = Chen (MSR); Derek Atkins; oauth@ietf.org
Subject: Re: [OAUTH-WG] proposal of = a paragraph to add to the security considerations = section
Would someone enlighten = me on why the implicit flow is needed? Is it the extra round trip? If = so, I think that would be useful to call out both the advantages and = disadvantages in the spec. (I did not realize this flow was in OAuth -- = it was not in WRAP because of the security = issue)
-- = Dick
On Jun 23, 2012, at 11:54 = AM, John Bradley wrote:
Yes it is probably best = to keep it short in the main spec, but go into more detail in the = security document.
OAuth is fine as it is. =  If you use OAuth as part of another protocol that protocol should = be taking responsibility for it's own security considerations and not = assuming that OAuth will cover everything you are = doing.
Like it or not once you = do federated authentication with OAuth you have created a different = protocol that needs different security = considerations.
We all sort of know that, = the problem is that some people confuse authentication and authorization = as the same thing, so it is worth point ing = out.
John = B.
On 2012-06-23, at 2:24 = PM, Torsten Lodderstedt wrote:


Hi John,

I fully agree with your assessment. This attack = utilizes the fact that some clients rely on the result of a resource = server request to login an user. It is not an attack on the OAuth = protocol. And even if a similar attack on authorization codes will = happen to fail for confidential clients does not mean OAuth is supposed = to solve this problem.

We nevertheless should mention it in the = security considerations section. To make things simple, I suggest to = describe and ban this anti-pattern _in general_ in the security = consideration section (similar to Shuo's initial proposal but more = generalized). Additionally, the text should recommend to use an = appropriate technique for id providing such as OpenID or SAML.

We = also could add a detailed analaysis to the security = document.

best = regards,
Torsten.

Am 21.06.2012 = 15:47, schrieb John Bradley:
Hi = Hannes,
MAC tokens protect = resources against token leakage to third parties.  That is useful = but a different threat.  
 
The easiest way to get a access token for someone is to = have them log into your site. =   
If you can do that the = token type makes no difference unless we move to a asymmetric holder of = key token (different discussion).
 
The bad client gets the access MAC token and token = secret and can re use it just as it would a bearer = token.
The origin of the post = was a contention by someone at Facebook that profiling OAuth 2.0 on its = own is sufficient to produce an Authentication = protocol.
I was trying to point out = that OAuth 2 without any extensions, only profiling is difficult to = impossible to use for authentication as the attack surface and security = considerations are different.
 
As it turned out Facebook had extended OAuth 2 with = signed requests and token introspection techniques to address these = issues for themselves.   
 
The problem as it turned out was that individual apps = and  app frameworks like the iOS one made some bad mistakes, by not = using the perhaps under documented = extensions.
The problem is not unique = to Facebook in any way they are just a convenient = example.
Oauth 2  is not = surprisingly mostly about protecting the resource. =  
Authentication is about = protecting the client.
 
Audience restriction from openID 2, SAML,  WS* etc = prevents replay of tokens issued to one RP/SP at another. =  
That is sort of = authentication protocol threat number 1.
 
OAuth has no way to do that with access = tokens.
It can however do it with = "code" if the client is confidential.
 
So my recommendation is that without extensions to = OAuth like structured tokens (signed_request, id_token) or token = introspection endpoints like 


Hi John, 

I read through your = blog post. I am not sure whether I can entirely agree with your = separation between authentication and authorization. I believe the core = issue here is that 

* anyone who has = the token will get access to whatever the token entitles him or her to = do (unless there are restrictions in the token)

* some attributes = are different than others. With authentication you typically associate = that the process took place recently (i.e., it is fresh) while other = attributes do not require the user (as resource owner) to actively = participate in the exchange and the same level of freshness is not = implied.  For authentication in a three party protocol to be useful = the three parties have to participate (see  

I = understand that one wants to avoid having tokens passed around from one = application to the other one, as it is happening here. 

I remember having = some of these discussions with Eran a long time ago. He anticipated that = implementers will not put any constraints in the tokens and hence they = will be misused. This serves as an argument for him to propose the MAC = token specification. 

I proposed text for = the security consideration section of the bearer document a while ago = and it even talks about audience restriction as a recommendation. 

There are two = problems with the audience restriction: 

1) There is no = mandatory token format defined nor do we mandate token content either. = Hence we do not strongly require anything specifically to be put into = the tokens. 

2) = In the implicit grant flow the client isn't authenticated and hence what = do you want to put into a token as an audience restriction? 

Finally, I think = that the "audience restriction" terminology is a bit fuzzy for this = discussion either. 
Audience restriction = can mean two things:

* Allowing the client to verify that the = access token has indeed been issued for him / her. 
* Allowing the resource = server verify that the received access token from a specific client has = indeed been provided by that client. 

My current believe = is that the implicit grant flow is unsuitable for providing = authentication functionality. 

Ciao
Hannes
On Jun 19, 2012, at 5:50 AM, John Bradley = wrote:


I blogged = about this in the hypothetical several months ago.
Nov Matake and = others built some tests and found quite a number of deployments = vulnerable.
The bottom = line is that OAuth has no explicit audience restriction for tokens, =  hence accepting any token outside of the code flow is subject to = attack.
In general it = is not a issue for authorization,  it is however a big issue then = there is a presumption that the presenter of a token that grants a = client access to resource x is the "resource owner" of resource x, when = it is possible that the presenter is any client who has ever had a = access token for resource = x.
We might want = to include the why it is insecure in the security consideration, =  otherwise people reading the below will likely ignore the advice = as it seems on the surface a touch = extreme.
There are = certainly OAuth flows that allow you to do authentication safely, =  just not all of them without additional = precautions.
That is why = openID Connect has a audience restricted id_token similar to Facebook's = signed request to allow the implicit flows to be safely used for = authentication.
John = B.
On 2012-06-18, = at 4:19 PM, Shuo Chen (MSR) = wrote:
Hi OAuth = group,
This is regarding the recent discussion about an = implementation issue of some cloud services using OAuth for = authentication.
Derek Atkins and Dick Hardt suggested the possibility = to discuss with the group a paragraph to add to the security = considerations = section.
Derek=92s = suggestion:
=3D=3D=3D=3D   =3D=3D=3D  =3D=3D=3D =  =3D=3D=3D
Perhaps you could boil it down to a = paragraph
or two for addition to the security = considerations section that basically = says
<= /blockquote>
"beware of implementing it *this* way = because it leads to *that* attack vector", = etc.
<= /blockquote>
=3D=3D=3D=3D   =3D=3D=3D  =3D=3D= =3D =  =3D=3D=3D
Here is out suggested = text:
=
=3D=3D=3D=3D =   =3D=3D=3D  =3D=3D=3D =  =3D=3D=3D
It has been observed that in multiple occasions that = the = server-side
authentication logic takes an access token from the = client, = then
<= blockquote style=3D"margin-top: 5pt; margin-bottom: 5pt; ">
queries the = user's profile data from the IdP in order = to
"authenticate" = the user. This implementation must be forbidden. = It
will allow an = untrusted app running on a victim=92s client device = to
work with an = attacker=92s device to sign into the victim=92s account on the server = side.
=
=3D=3D=3D=3D =   =3D=3D=3D  =3D=3D=3D =  =3D=3D=3D
Thank = you.
<= blockquote style=3D"margin-top: 5pt; margin-bottom: 5pt; ">
p.s. below is the email thread giving a better context = of the = discussion.
-----Original = Message-----
=
=
=
Subject: Re: [OAUTH-WG] web sso = study...
=
<= /blockquote>
=
<= /blockquote>
=
=
=
<= /blockquote>
<= /blockquote>
<= /blockquote>
<= /blockquote>
=
<= /blockquote>
-----Original = Message-----
From: Hannes Tschofenig [
Sent: Friday, = June 15, 2012 11:36 = AM
To: rui = wang
<= /blockquote>
Cc: Hannes Tschofenig; Stephen Farrell; Shuo = Chen (MSR); Yuchen = Zhou;
=
Derek = Atkins
Subject: Re: [OAUTH-WG] web sso = study...
Hi = Rui,
<= /blockquote>
let me independently respond (in addition to = the previous = responses
you had already = gotten).
First, let me ask whether it is OK if I = share your post with = the
OAuth WG since it is more detailed than the = one you distributed on the list mid = April.
Second, could you describe the attack in = more details to me? What = I
would like to better understand whether this = the raised issue is = a
problem with one of our specifications, with = a = specific
implementation of the IETF OAuth = specifications, a problem with = other
=
OAuth related work (Facebook, as you know, = implements far more = than
<= /blockquote>
just the IETF OAuth specifications), a = violation of the IETF = OAuth
=
specification in the way how the Websites = use OAuth, whether this = is
a configuration related aspect, or an aspect = we already documented in the threats = document.
The reason why I am so specific is to know = where to put text = to
address this issue or whether this is even = an issue beyond the = IETF
<= /blockquote>
OAuth working group and needs to be tackled = somewhere = else.
=
OAuth mailing = list
<= blockquote style=3D"margin-top: 5pt; margin-bottom: 5pt; ">
OAuth@ietf.org
In-Reply-To: <0CBAEB56DDB3A140BA8E8C124C04ECA20107B405@P3PWEX2MB008.ex2.secureserver.net> Date: Sun, 24 Jun 2012 11:41:25 -0700 Message-Id: <4A92359B-6A50-451A-A232-0D7C647B80FD@gmail.com> References: <854774286EF8A240BACC342973A86EAC016693D6@BL2PRD0310MB387.namprd03.prod.outlook.com> <484A13D0-7C9A-42CC-BB94-3657741834DE@ve7jtb.com> <82D95BA2-1697-4441-BBB3-B2AE480DC39E@gmail.com> <0CBAEB56DDB3A140BA8E8C124C04ECA20107B405@P3PWEX2MB008.ex2.secureserver.net> To: Eran Hammer X-Mailer: Apple Mail (2.1278) Cc: rui wang , Yuchen Zhou , "Shuo Chen \(MSR\)" , Derek Atkins , "oauth@ietf.org" Subject: Re: [OAUTH-WG] proposal of a paragraph to add to the security considerations section X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 18:41:34 -0000 --Apple-Mail=_D209B7E5-DF2F-4C2B-8FE9-DD39F185E0EB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Speaking from personal experience, OAuth 1.0 sucks to implement -- even = with libraries, stupid shit happens and it is a bitch to debug. Implementing and exploring an API with OAuth 2.0 (well, the good = features that came from WRAP) is a dream in comparison. The implicit flow is evil -- why did you put that in? -- Dick On Jun 21, 2012, at 7:17 AM, Eran Hammer wrote: > The sad reality is, we've spent 3 years producing a specification that = is less secure, more complex, and does not interoperate the way OAuth = 1.0 does. > =20 > It does scale better for huge companies like Google, Microsoft, and = Yahoo. No wonder they wanted it this way. > =20 > When asked, I tend to advise people using OAuth 1.0 to just keep using = it. > =20 > Oh well. > =20 > EH > =20 > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf = Of John Bradley > Sent: Thursday, June 21, 2012 6:47 AM > To: Hannes Tschofenig > Cc: rui wang; Yuchen Zhou; Shuo Chen (MSR); Derek Atkins; = oauth@ietf.org > Subject: Re: [OAUTH-WG] proposal of a paragraph to add to the security = considerations section > =20 > Hi Hannes, > =20 > MAC tokens protect resources against token leakage to third parties. = That is useful but a different threat. =20 > =20 > The easiest way to get a access token for someone is to have them log = into your site. =20 > =20 > If you can do that the token type makes no difference unless we move = to a asymmetric holder of key token (different discussion). > =20 > The bad client gets the access MAC token and token secret and can re = use it just as it would a bearer token. > =20 > The origin of the post was a contention by someone at Facebook that = profiling OAuth 2.0 on its own is sufficient to produce an = Authentication protocol. > =20 > I was trying to point out that OAuth 2 without any extensions, only = profiling is difficult to impossible to use for authentication as the = attack surface and security considerations are different. > =20 > As it turned out Facebook had extended OAuth 2 with signed requests = and token introspection techniques to address these issues for = themselves. =20 > =20 > The problem as it turned out was that individual apps and app = frameworks like the iOS one made some bad mistakes, by not using the = perhaps under documented extensions. > =20 > The problem is not unique to Facebook in any way they are just a = convenient example. > =20 > Oauth 2 is not surprisingly mostly about protecting the resource. =20 > =20 > Authentication is about protecting the client. > =20 > Audience restriction from openID 2, SAML, WS* etc prevents replay of = tokens issued to one RP/SP at another. =20 > That is sort of authentication protocol threat number 1. > =20 > OAuth has no way to do that with access tokens. > =20 > It can however do it with "code" if the client is confidential. > =20 > So my recommendation is that without extensions to OAuth like = structured tokens (signed_request, id_token) or token introspection = endpoints like=20 > Facebook ( https://graph.facebook.com/app?access_token=3D[The Access = Token]), there is no safe way to use an implicit flow for = authentication. > A code flow where a native app exchanges code for the access token and = then passes the access token back to it's server is also vulnerable = (lots of this in circulation I understand) > =20 > The only safe flow (without extensions) is the code flow where the = client is confidential and the code is directly exchanged for the access = token. > This also requires the definition of a identity API that is protected = by the access token, and out of scope for OAuth. > =20 > So at the end of the day the rational conclusion is that OAuth 2 is a = authorization protocol. =20 > It may be used by Authentication protocols, but it is up to other = specs to define the security considerations for that. > =20 > That however doesn't remove the need to mention the token substitution = attack that non confidential clients are subject to, do to there being = no other mechanism for the client to know who the token was issued to. > =20 > John B. > =20 > =20 > =20 > =20 > =20 > On 2012-06-21, at 5:27 AM, Hannes Tschofenig wrote: >=20 >=20 > Hi John,=20 >=20 > I read through your blog post. I am not sure whether I can entirely = agree with your separation between authentication and authorization. I = believe the core issue here is that=20 >=20 > * anyone who has the token will get access to whatever the token = entitles him or her to do (unless there are restrictions in the token) >=20 > * some attributes are different than others. With authentication you = typically associate that the process took place recently (i.e., it is = fresh) while other attributes do not require the user (as resource = owner) to actively participate in the exchange and the same level of = freshness is not implied. For authentication in a three party protocol = to be useful the three parties have to participate = (seehttp://tools.ietf.org/id/draft-tschofenig-oauth-signature-thoughts-00.= txt).=20 >=20 > I understand that one wants to avoid having tokens passed around from = one application to the other one, as it is happening here.=20 >=20 > I remember having some of these discussions with Eran a long time ago. = He anticipated that implementers will not put any constraints in the = tokens and hence they will be misused. This serves as an argument for = him to propose the MAC token specification.=20 >=20 > I proposed text for the security consideration section of the bearer = document a while ago and it even talks about audience restriction as a = recommendation.=20 >=20 > There are two problems with the audience restriction:=20 >=20 > 1) There is no mandatory token format defined nor do we mandate token = content either. Hence we do not strongly require anything specifically = to be put into the tokens.=20 >=20 > 2) In the implicit grant flow the client isn't authenticated and hence = what do you want to put into a token as an audience restriction?=20 >=20 > Finally, I think that the "audience restriction" terminology is a bit = fuzzy for this discussion either.=20 > Audience restriction can mean two things: >=20 > * Allowing the client to verify that the access token has indeed been = issued for him / her.=20 > * Allowing the resource server verify that the received access token = from a specific client has indeed been provided by that client. >=20 > My current believe is that the implicit grant flow is unsuitable for = providing authentication functionality.=20 >=20 > Ciao > Hannes >=20 > On Jun 19, 2012, at 5:50 AM, John Bradley wrote: >=20 >=20 > I can put something together. =20 > =20 > It is mostly a warning about the token substitution attack that any = implicit flow is vulnerable to if used for authentication of the = presenter. > Otherwise known as why audience restriction is a good thing. > =20 > John B. > =20 > On 2012-06-18, at 8:20 PM, Dick Hardt wrote: > =20 > John > =20 > Do you have suggested text per your suggestion below? > =20 > -- Dick > =20 > On Jun 18, 2012, at 2:04 PM, John Bradley wrote: > =20 > I blogged about this in the hypothetical several months ago. = http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.h= tml > =20 > Nov Matake and others built some tests and found quite a number of = deployments vulnerable. > = http://www.thread-safe.com/2012/02/more-on-oauth-implicit-flow-application= .html > =20 > The bottom line is that OAuth has no explicit audience restriction for = tokens, hence accepting any token outside of the code flow is subject = to attack. > =20 > In general it is not a issue for authorization, it is however a big = issue then there is a presumption that the presenter of a token that = grants a client access to resource x is the "resource owner" of resource = x, when it is possible that the presenter is any client who has ever had = a access token for resource x. > =20 > We might want to include the why it is insecure in the security = consideration, otherwise people reading the below will likely ignore = the advice as it seems on the surface a touch extreme. > =20 > There are certainly OAuth flows that allow you to do authentication = safely, just not all of them without additional precautions. > =20 > That is why openID Connect has a audience restricted id_token similar = to Facebook's signed request to allow the implicit flows to be safely = used for authentication. > =20 > John B. > =20 > =20 > =20 > =20 > On 2012-06-18, at 4:19 PM, Shuo Chen (MSR) wrote: > =20 > Hi OAuth group, > =20 > This is regarding the recent discussion about an implementation issue = of some cloud services using OAuth for authentication. > Derek Atkins and Dick Hardt suggested the possibility to discuss with = the group a paragraph to add to the security considerations section. > =20 > Derek=92s suggestion: > =3D=3D=3D=3D =3D=3D=3D =3D=3D=3D =3D=3D=3D > Perhaps you could boil it down to a paragraph > or two for addition to the security considerations section that = basically says > "beware of implementing it *this* way because it leads to *that* = attack vector", etc. > =3D=3D=3D=3D =3D=3D=3D =3D=3D=3D =3D=3D=3D > =20 > =20 > Here is out suggested text: > =3D=3D=3D=3D =3D=3D=3D =3D=3D=3D =3D=3D=3D > It has been observed that in multiple occasions that the server-side > authentication logic takes an access token from the client, then > queries the user's profile data from the IdP in order to > "authenticate" the user. This implementation must be forbidden. It > will allow an untrusted app running on a victim=92s client device to > work with an attacker=92s device to sign into the victim=92s account = on the server side. > =3D=3D=3D=3D =3D=3D=3D =3D=3D=3D =3D=3D=3D > =20 > =20 > Thank you. > -Shuo > p.s. below is the email thread giving a better context of the = discussion. > =20 > =20 > -----Original Message----- > From: Derek Atkins [mailto:derek@ihtfp.com] > Sent: Monday, June 18, 2012 11:25 AM > To: Shuo Chen (MSR) > Cc: Hannes Tschofenig; rui wang; Stephen Farrell; Yuchen Zhou; Derek > Atkins; Dick Hardt > Subject: Re: [OAUTH-WG] web sso study... > =20 > Hi, > =20 > "Shuo Chen (MSR)" writes: > =20 > Hi Hannes, Derek and Stephen, > =20 > Thank you for your replies. > =20 > First, let me ask whether it is OK if I share your post with the > OAuth WG > =20 > Yes, please feel free to share it. > =20 > Second, could you describe the attack in more details to me? > =20 > Let's consider the mobile+cloud scenario for concreteness (although > some other scenarios are also applicable). The attack steps are the > following: suppose Alice's tablet runs a Windows 8 Metro app written > by attacker Bob. This app is able to request and obtain an access > token from the IdP (associated with Alice). The app can then send the > access token to Bob's own tablet. Note that there is no security > problem up to this point. However the real problem is that some cloud > services use the access token to query the user's profile data from > the IdP in order to "authenticate" the user. In this case, Bob's > tablet will be able to sign into the cloud service as Alice. We have > confirmed that the cloud services for Soluto Metro App, Givit Metro > App and EuroCup2012 Metro App make this mistake. These are apps in > the official Windows 8 App Store. We actually sampled only a small = portion of the available apps, but believe this is a vulnerability = pattern. > =20 > We don=92t think there is anything wrong in the OAuth spec. It is > developers who didn=92t comprehensively understand the usage of the > access token. In the meanwhile, this vulnerability pattern is not = explicitly excluded by the spec. > More importantly, it has been seen in the wild. > =20 > [from Derek's email] Perhaps you could boil it down to a paragraph > or two for > addition to the security considerations section that basically says > "beware of implementing it *this* way because it leads to *that* = attack vector", etc. > =20 > This is a great idea. I think that although it is difficult to > anticipate in general all kinds of incomprehensive understandings of > average developers, it is very worthwhile to take any common existing > vulnerability pattern as a precious feedback to improve the > specification text. In this case, since we have already seen this > vulnerability pattern on multiple services in the wild, certainly we > should be explicit about it in the security considerations section. > =20 > Our suggested text: > =20 > It has been observed that in multiple occasions that the server-side > authentication logic takes an access token from the client, then > queries the user's profile data from the IdP in order to > "authenticate" the user. This implementation must be forbidden. It > will allow an untrusted app running on a victim=92s client device to > work with an attacker=92s device to sign into the victim=92s account = on the server side. > =20 > Any questions or suggestions? > =20 > Could you please send this to the oauth@ietf.org mailing list? > =20 > Thanks a lot. > =20 > -Shuo > =20 > -derek > =20 > -----Original Message----- > From: Hannes Tschofenig[mailto:Hannes.Tschofenig@gmx.net] > Sent: Friday, June 15, 2012 11:36 AM > To: rui wang > Cc: Hannes Tschofenig; Stephen Farrell; Shuo Chen (MSR); Yuchen Zhou; > Derek Atkins > Subject: Re: [OAUTH-WG] web sso study... > =20 > Hi Rui, > =20 > let me independently respond (in addition to the previous responses > you had already gotten). > =20 > First, let me ask whether it is OK if I share your post with the > OAuth WG since it is more detailed than the one you distributed on the = list mid April. > =20 > Second, could you describe the attack in more details to me? What I > would like to better understand whether this the raised issue is a > problem with one of our specifications, with a specific > implementation of the IETF OAuth specifications, a problem with other > OAuth related work (Facebook, as you know, implements far more than > just the IETF OAuth specifications), a violation of the IETF OAuth > specification in the way how the Websites use OAuth, whether this is > a configuration related aspect, or an aspect we already documented in = the threats document. > =20 > The reason why I am so specific is to know where to put text to > address this issue or whether this is even an issue beyond the IETF > OAuth working group and needs to be tackled somewhere else. > =20 > Ciao > =20 > Hannes > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > =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=_D209B7E5-DF2F-4C2B-8FE9-DD39F185E0EB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Speaking from personal experience, OAuth 1.0 sucks = to implement -- even with libraries, stupid shit happens and it is a = bitch to debug.

Implementing and exploring an API = with OAuth 2.0 (well, the good features that came from WRAP) is a dream = in comparison.

The implicit flow is evil -- why = did you put that in?

-- = Dick


On Jun 21, 2012, at 7:17 AM, Eran = Hammer wrote:

The = sad reality is, we've spent 3 years producing a specification that is = less secure, more complex, and does not interoperate the way OAuth 1.0 = does.
It = does scale better for huge companies like Google, Microsoft, and Yahoo. = No wonder they wanted it this way.
When = asked, I tend to advise people using OAuth 1.0 to just keep using = it.
Oh = well.
Hi = Hannes,
MAC tokens protect = resources against token leakage to third parties.  That is useful = but a different threat.  
 
The easiest way to get a access token for someone is to = have them log into your site. =   
If you can do that the = token type makes no difference unless we move to a asymmetric holder of = key token (different discussion).
 
The bad client gets the access MAC token and token = secret and can re use it just as it would a bearer = token.
The origin of the post = was a contention by someone at Facebook that profiling OAuth 2.0 on its = own is sufficient to produce an Authentication = protocol.
I was trying to point out = that OAuth 2 without any extensions, only profiling is difficult to = impossible to use for authentication as the attack surface and security = considerations are different.
 
As it turned out Facebook had extended OAuth 2 with = signed requests and token introspection techniques to address these = issues for themselves.   
 
The problem as it turned out was that individual apps = and  app frameworks like the iOS one made some bad mistakes, by not = using the perhaps under documented = extensions.
The problem is not unique = to Facebook in any way they are just a convenient = example.
Oauth 2  is not = surprisingly mostly about protecting the resource. =  
Authentication is about = protecting the client.
 
Audience restriction from openID 2, SAML,  WS* etc = prevents replay of tokens issued to one RP/SP at another. =  
That is sort of = authentication protocol threat number 1.
 
OAuth has no way to do that with access = tokens.
It can however do it with = "code" if the client is confidential.
 
So my recommendation is that without extensions to = OAuth like structured tokens (signed_request, id_token) or token = introspection endpoints like 


Hi John, 

I read through your = blog post. I am not sure whether I can entirely agree with your = separation between authentication and authorization. I believe the core = issue here is that 

* anyone who has = the token will get access to whatever the token entitles him or her to = do (unless there are restrictions in the token)

* some attributes = are different than others. With authentication you typically associate = that the process took place recently (i.e., it is fresh) while other = attributes do not require the user (as resource owner) to actively = participate in the exchange and the same level of freshness is not = implied.  For authentication in a three party protocol to be useful = the three parties have to participate (see 

I = understand that one wants to avoid having tokens passed around from one = application to the other one, as it is happening here. 

I remember having = some of these discussions with Eran a long time ago. He anticipated that = implementers will not put any constraints in the tokens and hence they = will be misused. This serves as an argument for him to propose the MAC = token specification. 

I proposed text for = the security consideration section of the bearer document a while ago = and it even talks about audience restriction as a recommendation. 

There are two = problems with the audience restriction: 

1) There is no = mandatory token format defined nor do we mandate token content either. = Hence we do not strongly require anything specifically to be put into = the tokens. 

2) = In the implicit grant flow the client isn't authenticated and hence what = do you want to put into a token as an audience restriction? 

Finally, I think = that the "audience restriction" terminology is a bit fuzzy for this = discussion either. 
Audience restriction = can mean two things:

* Allowing the client to verify that the = access token has indeed been issued for him / her. 
* Allowing the resource = server verify that the received access token from a specific client has = indeed been provided by that client.

My current believe is that = the implicit grant flow is unsuitable for providing authentication = functionality. 

Ciao
Hannes
On Jun 19, 2012, at 5:50 AM, John Bradley = wrote:


I blogged = about this in the hypothetical several months ago. 
Nov Matake and = others built some tests and found quite a number of deployments = vulnerable.
The bottom = line is that OAuth has no explicit audience restriction for tokens, =  hence accepting any token outside of the code flow is subject to = attack.
In general it = is not a issue for authorization,  it is however a big issue then = there is a presumption that the presenter of a token that grants a = client access to resource x is the "resource owner" of resource x, when = it is possible that the presenter is any client who has ever had a = access token for resource = x.
We might want = to include the why it is insecure in the security consideration, =  otherwise people reading the below will likely ignore the advice = as it seems on the surface a touch = extreme.
There are = certainly OAuth flows that allow you to do authentication safely, =  just not all of them without additional = precautions.
That is why = openID Connect has a audience restricted id_token similar to Facebook's = signed request to allow the implicit flows to be safely used for = authentication.
John = B.
On 2012-06-18, = at 4:19 PM, Shuo Chen (MSR) = wrote:
Hi OAuth = group,
This is regarding the recent discussion about an = implementation issue of some cloud services using OAuth for = authentication.
Derek Atkins and Dick Hardt suggested the possibility = to discuss with the group a paragraph to add to the security = considerations = section.
Derek=92s = suggestion:
=3D=3D=3D=3D   =3D=3D=3D  =3D=3D=3D =  =3D=3D=3D
Perhaps you could boil it down to a = paragraph
or two for addition to the security = considerations section that basically = says
<= /blockquote>
"beware of implementing it *this* way = because it leads to *that* attack vector", = etc.
<= /blockquote>
=3D=3D=3D=3D   =3D=3D=3D  =3D=3D= =3D =  =3D=3D=3D
Here is out suggested = text:
=
=3D=3D=3D=3D =   =3D=3D=3D  =3D=3D=3D =  =3D=3D=3D
It has been observed that in multiple occasions that = the = server-side
authentication logic takes an access token from the = client, = then
<= blockquote style=3D"margin-top: 5pt; margin-bottom: 5pt; ">
queries the = user's profile data from the IdP in order = to
"authenticate" = the user. This implementation must be forbidden. = It
will allow an = untrusted app running on a victim=92s client device = to
work with an = attacker=92s device to sign into the victim=92s account on the server = side.
=
=3D=3D=3D=3D =   =3D=3D=3D  =3D=3D=3D =  =3D=3D=3D
Thank = you.
<= blockquote style=3D"margin-top: 5pt; margin-bottom: 5pt; ">
p.s. below is the email thread giving a better context = of the = discussion.
-----Original = Message-----
=
=
=
Hi Hannes, Derek and = Stephen,
Thank you for your = replies.
First, let me ask whether it is OK if I = share your post with = the
OAuth = WG
Yes, please feel free to share = it.
Second, could you describe the attack in = more details to = me?
Let's consider the mobile+cloud scenario for = concreteness = (although
some other scenarios are also applicable). = The attack steps are = the
following: suppose Alice's tablet runs a = Windows 8 Metro app = written
by attacker Bob. This app is able to request = and obtain an = access
token from the IdP (associated with Alice). = The app can then send = the
access token to Bob's own tablet. Note that = there is no = security
problem up to this point. However the real = problem is that some = cloud
=
services use the access token to query the = user's profile data = from
<= /blockquote>
the IdP in order to "authenticate" the user. = In this case, = Bob's
=
tablet will be able to sign into the cloud = service as Alice. We = have
<= /blockquote>
confirmed that the cloud services for Soluto = Metro App, Givit = Metro
=
App and EuroCup2012 Metro App make this = mistake. These are apps = in
the official Windows 8 App Store. We = actually sampled only a small portion of the available apps, but believe = this is a vulnerability = pattern.
We don=92t think there is anything wrong in = the OAuth spec. It = is
developers who didn=92t comprehensively = understand the usage of = the
access token. In the meanwhile, this = vulnerability pattern is not explicitly excluded by the = spec.
=
More importantly, it has been seen in the = wild.
=
[from Derek's email] Perhaps you could boil = it down to a = paragraph
or two = for
addition to the security considerations = section that basically = says
<= /blockquote>
"beware of implementing it *this* way = because it leads to *that* attack vector", = etc.
<= /blockquote>
This is a great idea. I think that although = it is difficult = to
anticipate in general all kinds of = incomprehensive understandings = of
average developers, it is very worthwhile to = take any common = existing
vulnerability pattern as a precious feedback = to improve = the
specification text. In this case, since we = have already seen = this
<= /blockquote>
vulnerability pattern on multiple services = in the wild, certainly = we
should be explicit about it in the security = considerations = section.
Our suggested = text:
=
It has been observed that in multiple = occasions that the = server-side
authentication logic takes an access token = from the client, = then
<= /blockquote>
queries the user's profile data from the IdP = in order = to
"authenticate" the user. This implementation = must be forbidden. = It
will allow an untrusted app running on a = victim=92s client device = to
work with an attacker=92s device to sign = into the victim=92s account on the server = side.
=
Any questions or = suggestions?
Could you please send this to the oauth@ietf.org mailing = list?
=
Thanks a = lot.
<= /blockquote>
-----Original = Message-----
From: Hannes Tschofenig
Sent: Friday, = June 15, 2012 11:36 = AM
To: rui = wang
<= /blockquote>
Cc: Hannes Tschofenig; Stephen Farrell; Shuo = Chen (MSR); Yuchen = Zhou;
=
Derek = Atkins
Subject: Re: [OAUTH-WG] web sso = study...
Hi = Rui,
<= /blockquote>
let me independently respond (in addition to = the previous = responses
you had already = gotten).
First, let me ask whether it is OK if I = share your post with = the
OAuth WG since it is more detailed than the = one you distributed on the list mid = April.
Second, could you describe the attack in = more details to me? What = I
would like to better understand whether this = the raised issue is = a
problem with one of our specifications, with = a = specific
implementation of the IETF OAuth = specifications, a problem with = other
=
OAuth related work (Facebook, as you know, = implements far more = than
<= /blockquote>
just the IETF OAuth specifications), a = violation of the IETF = OAuth
=
specification in the way how the Websites = use OAuth, whether this = is
a configuration related aspect, or an aspect = we already documented in the threats = document.
The reason why I am so specific is to know = where to put text = to
address this issue or whether this is even = an issue beyond the = IETF
<= /blockquote>
OAuth working group and needs to be tackled = somewhere = else.
=
OAuth mailing = list
<= blockquote style=3D"margin-top: 5pt; margin-bottom: 5pt; ">
OAuth mailing = list
OAuth@ietf.org
X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3486E21F8562 for ; Mon, 25 Jun 2012 09:55:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.466 X-Spam-Level: X-Spam-Status: No, score=-3.466 tagged_above=-999 required=5 tests=[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 UC9rnwj7v6Vq for ; Mon, 25 Jun 2012 09:55:04 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe005.messaging.microsoft.com [65.55.88.15]) by ietfa.amsl.com (Postfix) with ESMTP id 4BA6521F855B for ; Mon, 25 Jun 2012 09:55:02 -0700 (PDT) Received: from mail51-tx2-R.bigfish.com (10.9.14.237) by TX2EHSOBE010.bigfish.com (10.9.40.30) with Microsoft SMTP Server id 14.1.225.23; Mon, 25 Jun 2012 16:53:23 +0000 Received: from mail51-tx2 (localhost [127.0.0.1]) by mail51-tx2-R.bigfish.com (Postfix) with ESMTP id D537C8031E for ; Mon, 25 Jun 2012 16:53:23 +0000 (UTC) X-Forefront-Antispam-Report: CIP:192.160.210.12; KIP:(null); UIP:(null); IPV:NLI; H:CT11GSG01.am.mot-solutions.com; RD:ct11gsg01.mot-solutions.com; EFVD:NLI X-SpamScore: -18 X-BigFish: VPS-18(zzbb2dI98dI9371Ic85fh1418Ib457nzz1202hzz1033IL8275bh8275dhz2fh2a8h683h839hd25hf0ah) Received-SPF: pass (mail51-tx2: domain of motorolasolutions.com designates 192.160.210.12 as permitted sender) client-ip=192.160.210.12; envelope-from=Adam.Lewis@motorolasolutions.com; helo=CT11GSG01.am.mot-solutions.com ; olutions.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.244.181; KIP:(null); UIP:(null); (null); H:CH1PRD0410HT004.namprd04.prod.outlook.com; R:internal; EFV:INT Received: from mail51-tx2 (localhost.localdomain [127.0.0.1]) by mail51-tx2 (MessageSwitch) id 1340643198953523_6865; Mon, 25 Jun 2012 16:53:18 +0000 (UTC) Received: from TX2EHSMHS035.bigfish.com (unknown [10.9.14.246]) by mail51-tx2.bigfish.com (Postfix) with ESMTP id E4D45160046 for ; Mon, 25 Jun 2012 16:53:18 +0000 (UTC) Received: from CT11GSG01.am.mot-solutions.com (192.160.210.12) by TX2EHSMHS035.bigfish.com (10.9.99.135) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 25 Jun 2012 16:53:17 +0000 Received: from CT11GSG01.am.mot-solutions.com (ct11vts01.am.mot.com [10.177.16.159]) by CT11GSG01.am.mot-solutions.com (8.14.3/8.14.3) with ESMTP id q5PGwPSm016792 for ; Mon, 25 Jun 2012 12:58:25 -0400 (EDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe004.messaging.microsoft.com [216.32.180.14]) by CT11GSG01.am.mot-solutions.com (8.14.3/8.14.3) with ESMTP id q5PGwOHE016784 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 25 Jun 2012 12:58:24 -0400 (EDT) Received: from mail9-va3-R.bigfish.com (10.7.14.253) by VA3EHSOBE014.bigfish.com (10.7.40.64) with Microsoft SMTP Server id 14.1.225.23; Mon, 25 Jun 2012 16:53:15 +0000 Received: from mail9-va3 (localhost [127.0.0.1]) by mail9-va3-R.bigfish.com (Postfix) with ESMTP id 195362A00B7 for ; Mon, 25 Jun 2012 16:53:15 +0000 (UTC) Received: from mail9-va3 (localhost.localdomain [127.0.0.1]) by mail9-va3 (MessageSwitch) id 1340643191160507_7914; Mon, 25 Jun 2012 16:53:11 +0000 (UTC) Received: from VA3EHSMHS019.bigfish.com (unknown [10.7.14.251]) by mail9-va3.bigfish.com (Postfix) with ESMTP id 2153D260047; Mon, 25 Jun 2012 16:53:11 +0000 (UTC) Received: from CH1PRD0410HT004.namprd04.prod.outlook.com (157.56.244.181) by VA3EHSMHS019.bigfish.com (10.7.99.29) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 25 Jun 2012 16:53:09 +0000 Received: from CH1PRD0410MB369.namprd04.prod.outlook.com ([169.254.12.121]) by CH1PRD0410HT004.namprd04.prod.outlook.com ([10.255.147.39]) with mapi id 14.16.0164.004; Mon, 25 Jun 2012 16:54:45 +0000 From: Lewis Adam-CAL022 To: Nat Sakimura , Paul Madsen Thread-Topic: [OAUTH-WG] Report an authentication issue Thread-Index: AQHNUg1aQ6l+bX+OSkGiyy7VSGUjQZcLPjvA Date: Mon, 25 Jun 2012 16:54:45 +0000 Message-ID: <59E470B10C4630419ED717AC79FCF9A91A2C8949@CH1PRD0410MB369.namprd04.prod.outlook.com> References: <1339792496.52712.YahooMailNeo@web125501.mail.ne1.yahoo.com> <59E470B10C4630419ED717AC79FCF9A9108898EE@BL2PRD0410MB363.namprd04.prod.outlook.com> <4FE223E4.6060307@mitre.org> <4FE226BC.6010403@alcatel-lucent.com> <59E470B10C4630419ED717AC79FCF9A910889AB5@BL2PRD0410MB363.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A917052BC8@SN2PRD0410MB370.namprd04.prod.outlook.com> <4FE37D38.1030407@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.167.129.37] Content-Type: multipart/alternative; boundary="_000_59E470B10C4630419ED717AC79FCF9A91A2C8949CH1PRD0410MB369_" 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 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Report an authentication issue X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 16:55:18 -0000 --_000_59E470B10C4630419ED717AC79FCF9A91A2C8949CH1PRD0410MB369_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Okay :-) I've gotten lot of feedback ... consider a few snippets below, all part of = this thread and in response to my question: Igor said: OAuth was not designed for this purpose; it was designed for del= egating access. In your use case, there is no delegation. The only legiti= mate users are police officers and they "must logon to the video server in = order to access video content." And so the server must authenticate them. = There is no need for OAuth in this scenario. Nat said: Yes, OAuth can be profiled to enable authentication. In fact, ini= tial draft of OpenID Connect was just like you described. Phil said: I see elements of improper use of OAuth flows as well as imprope= r use of bearer tokens. We have to keep it a simple comment in both specs. Nat said: "I think you are way beyond what OAuth provides." Paul said: Nothing prevents you today from using OAuth as is to issue a tok= en to the officer on the tablet, having the app use that token on API calls= , and the API making an authz decision based solely on enterprise policy, w= ith no consent figuring in. ... This doesnt sound like a Connect Use Case t= o me - rather a pretty standard OAuth use case - albeit with no need to get= user's consent (so actually simpler). Chuck said: This is basically describing how our OAuth deployment works, wi= th the exception that our token format is opaque. Patreek said: My impression is that the fully specified OAuth flows to date= focus on certain key consumer-centred use-cases and that important enterpr= ise flows such as the one you have described are yet to be profiled. I think the above just really drives home the fact that if OAuth is to be u= sed for securing enterprise API calls in a post-SOAP world, something needs= to be stated more explicitly. OAuth was not designed to provide authentic= ation of the user to the RS. But it seems we all agree that it can be prof= iled to do so. Connect is supposed to address authentication, but only fro= m the view of the client, and not the RS. Only the access token goes to th= e RS, so if we want to authenticate a user to the RS, then we're back to OA= uth, since Connect doesn't intend to send the id_token to the RS. Nat ment= ioned that it "could," but I haven't seen that as part of the Connect specs= thus far. There is *clearly* confusion around whether OAuth is to be used as authenti= cation or not, and I think this thread has shown that. If I'm going to dep= loy OAuth for Authentication, then I really need a spec to point to (when m= y customers ask) that says it can be used that way, especially with all the= "OAuth is NOT authentication" blog posts floating around in cyberspace the= se days. I'm thinking two things: 1) it would at least be worthwhile to document this use case, and mayb= e the OAuth use cases draft would be a good place to capture it. 2) maybe a stand alone, informational draft would also be a good idea,= especially if we all agree that it's only a profile of OAuth, and does not= require any technical changes to the core draft. Something that talks out= right about an enterprise-centric world, rather than the user RO-centric wo= rld that OAuth was really written around. This might give future generatio= n of Enterprise folks like myself an easier time. Thoughts? -adam From: Nat Sakimura [mailto:sakimura@gmail.com] Sent: Sunday, June 24, 2012 8:29 AM To: Paul Madsen Cc: Lewis Adam-CAL022; oauth@ietf.org Subject: Re: [OAUTH-WG] Report an authentication issue On Fri, Jun 22, 2012 at 4:59 AM, Paul Madsen > wrote: Lewis, I think you are perhaps conflating the token model (whether it has i= nherent structure or is merely a pointer to user info) and who the RO owner= is - user or enterprise. Nothing prevents you today from using OAuth as is to issue a token to the o= fficer on the tablet, having the app use that token on API calls, and the A= PI making an authz decision based solely on enterprise policy, with no cons= ent figuring in. Indeed, though I usually envisage that there is invisible consent authority= a.k.a. corporate policy engine. Neither do you need a structured token (like id_token). The token issued ca= n merely be a pointer/artifact to the officer's actual roles, these obtaine= d by the API/RS by sending the tokens for 'validation' or 'introspection' If RS can reach AS through network, yes, the access token can act as an art= ifact that you do artifact resolve. That would have a nice property of audi= t logging at the AS. It is not always true though. In one of my use case, R= S was not able to directly talk to AS, in which case, you need a structured= token. This doesnt sound like a Connect Use Case to me - rather a pretty standard = OAuth use case - albeit with no need to get user's consent (so actually sim= pler). If authentication and the identity of the accessor matters, yes. If it does not, maybe not. paul On 6/21/12 12:01 PM, Lewis Adam-CAL022 wrote: Hi Nat, I'm beginning to wonder what it would take to add a new profile of sorts to= either OAuth or Connect. In the beginning there was SOAP, and the preferred method to secure SOAP AP= I calls was WS-Trust. Now the world is moving toward RESTful APIs ... and the preferred means to = secure RESTful APIs is OAuth. Except that OAuth is clearly written with the idea that the protected resou= rces belong to the end user. My use cases - and I imagine the use cases of many other enterprises - is t= hat the Owner of the resources is the Enterprise. An employee is trying to= access a database or video resources. The enterprise RS needs to be able = to 1) identify the user, and 2) make authorization decisions based on what = roles that user has within the enterprise. So in my scenario, when a polic= e officer attempts to access a criminal records database, the database need= s to know who that officer is, and then decide if they have privilege to ac= cess the database, and at what level (e.g. CRUD). WS-Trust fits this model well. The user performs primary authentication to= the enterprise STS, which then grants the application client a SAML assert= ion. When the user attempts to access a records database, the SAML asserti= on is included in the SOAP message. The records server authenticates the u= ser based on the SAML assertion and makes its authorization decisions. This is the world I'm trying to migrate from, and it really seems like I'm = sometimes trying to make a square peg fit in a round hole. I'm looking for= OAuth/Connect to do for REST what WS-TRUST did for SOAP. I would like a n= ative client talking to a RS to be able to ask for an id_token, and then pa= ss that id_token to the RS when making its RESTful API calls, to enable the= RS to authenticate the user. I think that this would be really useful for= a lot of people besides me. I keep hearing that there is nothing "prevent= ing" me from doing this ... but it hardly seems within the spirit of what O= Auth was meant to do. The id_token was clearly meant to enable a user to a= uthenticate to a confidential client / web server ... but was not meant fo= r a native client to identity / authenticate the user to a RS. Would there be any interest in exploring this further? -adam From: Nat Sakimura [mailto:sakimura@gmail.com] Sent: Wednesday, June 20, 2012 8:09 PM To: Lewis Adam-CAL022 Cc: igor.faynberg@alcatel-lucent.com; oauth@ietf.org Subject: Re: [OAUTH-WG] Report an authentication issue Yes, OAuth can be profiled to enable authentication. In fact, initial draft of OpenID Connect was just like you described. Essentially, we were using structured access_token. Later, we decided to separate the access token and id_token for several rea= sons such as: 1. Better interop with existing OAuth implementations: by introducing id= _token, they do not need to touch the supposedly opaque (which means AS-RS = may be doing some proprietary thing inside it) access token. 2. Mixing up the audience (for id_token aka authn =3D client, and for ac= cess_token aka authz =3D resource server) probably is expanding the attack = surface for security and privacy. Although we separated them out, a signed id_token includes the left hash of= access_token so access_token is also protected. Best, Nat On Thu, Jun 21, 2012 at 5:21 AM, Lewis Adam-CAL022 > wrote: Hi Igor, As Justin just pointed out, consider the case where the video server is hos= ted by the state (e.g. California) and is accessed by police agencies in Lo= s Angeles, San Francisco, and San Diego. The State of California's video s= erver is the RS. Each local police agency (LA/SF/SD) hosts an AS. So when= a police officer from LAPD launches the video client app on the iPhone, th= e client makes an OAuth request to the LAPD's AS, which authenticates the p= olice officer using agency level credentials. The access token issued to t= he video client app on the iPhone is a JWT, signed by the agency AS, which = might look something like this: {"typ":"JWT","alg":"ES256"} {"iss":"https://as.lapd.california.gov", "prn":"alice@lapd.california.gov", "aud":" https://video_server1@state.california.gov", "iat":1300815780, "exp":1300819380, "acr":"password"} hq4zk+ZknjggCQgZm7ea8fI79gJEsRy3E8LHDpYXWQIgZpkJN9CMLG8ENR4Nrw+n7iyzixBvKXX= 8P53BTCT4VghPBWhFYSt9tHWu/AtJfOTh6qaAsNdeCyG86jmtp3TDMwuL/cBUj2OtBZOQMFn7jQ= 9YB7klIz3RqVL+wNmeWI4=3D The JWT might be optionally encrypted using JWE. I think what is becoming clear (and this is what I'm trying to vet) is that= while there is nothing in OAuth that specifies authentication, it *can* be= used for Authentication, if done in the way that I describe. If I'm wrong= about this, I really need to know. I've vetted this idea of mine with qui= te of few people now - both within context of the list and off-line - and I= think I'm okay. If you see any holes in what I describe, please point them= out as I would prefer to uncover them now rather than after implementation= or deployment! Essentially I'm using OAuth as a RESTful version of WS-Trust, where my clie= nt can exchange primary credentials for a token (JWT) and present that toke= n to a server as secondary authentication. It's just that it's RESTful ins= tead of SOAP :-) As Justin as pointed out ... I've basically made the access-token look like= the id_token of Connect. I was actually hoping to lay a path to Connect, = and use the id_token ... until it was also pointed out that the id_token is= really meant for the consumption of the client, not the RS :-( From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Igor Faynberg Sent: Wednesday, June 20, 2012 2:39 PM To: oauth@ietf.org Subject: Re: [OAUTH-WG] Report an authentication issue But this use case does need OAuth, period: The video server is under the control of a police agency, and police office= rs must logon to the video server in order to access video content. There is no delegation here, and there is no need to use third party for au= thentication. Igor On 6/20/2012 3:26 PM, Justin Richer wrote: In case it wasn't clear, I want to restate the original problem as best as = I understand it in a way that hopefully clears it up: App A and app B are both valid registered OAuth clients to an OAuth protect= ed service. The problem starts when app A gets handed a token that was issued for app B= and uses it to call an identity API on the OAuth service. Since app B can = get tokens just fine, they're bearer tokens, this is a fairly basic api cal= l, this function works just fine and returns the user info. This makes sens= e, since anyone who holds A's tokens can do whatever A can do on behalf of = that user. The issues start when app B then decides that since they can mak= e a call to the identity API with a token then the user *must* be present. = In other words, app B is confusing authorization to call an API with authen= tication of the session. OpenID Connect fixes this missed assumption by binding the ID Token to the = session and sending it along side the access token, but as you pointed out,= it's meant for consumption at the client, not the resource server, in gene= ral. That doesn't mean you can't send it to a resource server for your own = purposes, of course. That's actually how the session management endpoint wo= rks in Connect. This isn't the only way to handle this problem -- if you put some structure= in your tokens, such as with JWT or SAML, then app A can tell that this is= n't a token issued to app A, but to app B, so it can call shenanigans and r= eject it then and there. -- Justin On 06/20/2012 10:03 AM, Lewis Adam-CAL022 wrote: I am entirely confused. I understand what everybody is saying for confidential clients, no problem = here. I fall apart when thinking of iPhone apps. Consider the scenario where I d= eploy a video server, and write an iPhone app to talk to the video server. = The video server is under the control of a police agency, and police offic= ers must logon to the video server in order to access video content. So th= e police office launches their iPhone video client app. If I wanted to solve authentication using "traditional" client-server authe= ntication, the user enters their username / password into the client, and t= he client sends the username / password off to the server, which authentica= tes it, or possibly uses HTTP digest. If I wanted to use OpenID, the client would attempt to reach the video serv= er (RP), the server would redirect the client to the OP, OP authenticates u= ser, and OP redirects client back to the server/RP with an assertion that p= rimary authentication was successful. If I wanted to use OAuth, the client would send an authorization request to= the server's AS, which would authenticate the user of the client, and ulti= mately result in the client possessing an access-token. My thinking is tha= t this access token (let's assume it's a JWT) would contain the user's iden= tity, a statement of what type of primary authentication was used (auth con= text), an expiration, and an audience claim. This sounds a lot like authen= tication to me, and it's where I get confused. Is it just because OAuth do= es not explicitly define this? Is there a threat in using OAuth as I descr= ibe? If I wanted to use Connect, well I'm not even sure how the id_token as defi= ned by Connect helps this use case. The id_token seems to make sense when = the client is a confidential web server, but it's not clear what an iPhone = app would do with the id_token ... it's the server in the backend that need= s to authenticate the user, the iPhone app is just an interface to talk to = the server. And it seems as I learn more about connect that the id_token i= s not meant to be sent from the iPhone app to the server, just the access t= oken. So it's really not clear how Connect helps solve authentication for = an iPhone client app talking to a video server. If I'm sending access-toke= ns, it's just OAuth again. What am I still missing? adam From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Kristofor Selden Sent: Saturday, June 16, 2012 11:33 AM To: nov matake; oauth Cc: Yuchen Zhou; Luke Melia; Shuo Chen (MSR) Subject: Re: [OAUTH-WG] Report an authentication issue Nov demonstrated the problem to us at Yapp and we used solution 4 (because = the solution is server side and our app was in the app store). FB Connect is authentication and authorization, where OAuth 2 is concerned = only with authorization - I'm not sure that app developers appreciate this = subtlety. With OAuth 2 you authorize an app to use a protected resource. With FB Con= nect, you do that, but also authenticate with the app you are authorizing. So the access_token protects not just the FB resources but the auth end poi= nt of the authorized app (very common with apps that use the iOS SDK). So = now the app needs a way to verify that it was the app that was authorized t= o FB. Solution 4 explanation: on FB you can register a iPhone app and a server ap= p with the same client_id and get a client_secret for use on the server. T= he server side API posts the access_token, client_id, and client_secret to = https://graph.facebook.com/app to verify that the bearer token actually belongs to the app = that is being authenticated before assuming they are authorized to the app'= s protected resources. Kris On Jun 15, 2012, at 8:22 PM, nov matake wrote: There are 4 ways to fix this issue. 1. Use response_type=3Dtoken%20code (It's not in OAuth 2.0 Core, but seems = best way for interoperability) 2. Use singed_request (or some signed token like JWT) 3. Use grant_type=3Dfb_exchange_token (Facebook custom way) 4. Access to https://graph.facebook.com/app?access_token=3DYOUR_TOKEN (Face= book custom way, moreover undocumented API) Two iPhone app developers I reported this issue fixed it by using (4). I also tried to use (1) for my own iPhone app implementation, but unfortuna= tely it doesn't work when using authorization codes obtained via FB iOS SDK= . So I'm using (3) in my case. nov On 2012/06/16, at 9:16, Nat Sakimura wrote: As to how the fix was done, Nov can provide more detail, but ... 1. Properly verify the signature/HMAC of the "signed_request". This will es= sentially audience restricts the token. 2. There is an undocumented API for Facebook which returns to whom the toke= n was issued. This also audience restricts the token. The service that fixed took these measures. Note that none of the above is = defined in OAuth. The same facility was called "id_token" and "check ID endpoint" for OpenID = Connect. The scale of the impact is large, too large to disclose the actual names in= the public list, though, eventually, we would publish them in a paper. Nat On Sat, Jun 16, 2012 at 5:34 AM, Francisco Corella > wrote: Hi Nat and Rui, Rui, you say that the vulnerability that you found was due to a "common misunderstanding among developers", but the attack you describe can be carried out against any app that uses the OAuth "implicit grant flow", which Facebook calls "client-side authentication". No misunderstanding seems necessary. What misunderstanding are you referring to? I followed the link in your message to the Sophos post, and from there the link to the article in The Register. The article in The Register says that Facebook had "fixed the vulnerability promptly". How did they fix it? The instructions that Facebook provides for implementing "Client-side authentication without the JS SDK" at https://developers.facebook.com/docs/authentication/client-side/#no-jssdk still allows the attack. Nat, I agree that the blog post by John Bradley that you link to refers to the same vulnerability reported by Rui. You say that some apps have issued a patch to fix it. Could you explain what the fix was? Francisco ________________________________ From: Nat Sakimura > To: rui wang > Cc: matake nov >; Yuchen Zhou >; oauth >; Shuo Chen (MSR) > Sent: Thursday, June 14, 2012 1:50 PM Subject: Re: [OAUTH-WG] Report an authentication issue This is a fairly well known (hopefully by now) issue. We, at the OpenID Fou= ndation, call it "access_token phishing" attack these days. See: http://www= .thread-safe.com/2012/01/problem-with-oauth-for-authentication.html Nov Matake has actually built the code on iPhone to verify the problem, and= has notified bunch of parties back in February including Facebook and Appl= e. We have the code that actually runs on a phone, and we have successfully= logged in to bunch of apps, including very well known ones. They were all = informed of the issue. Some immediately issued a patch to fix it while othe= rs have not. The problem is that even if these apps gets fixed, the problem does not go = away. As long as the attacker has the vulnerable version of the app, he sti= ll can impersonate the victim. To stop it, the server side has to completel= y disable the older version, which means the service has to cut off many us= ers pausing business problems. Nat On Fri, Jun 15, 2012 at 2:18 AM, rui wang > wrote: Dear Facebook Security Team and OAuth Standard group, We are a research team in Microsoft Research. In January, 2011, we reported= a vulnerability in Facebook Connect which allowed everyone to sign into Fa= cebook-secured relying parties without password. It was promptly fixed afte= r reporting. (http://nakedsecurity.sophos.com/2011/02/02/facebook-flaw-webs= ites-steal-personal-data/) Recently, we found a common misunderstanding among developers of mobile/met= ro apps when using OAuth (including Facebook's OAuth) for authentication. T= he vulnerability resulted from this misunderstanding also allows an attacke= r to log into a victim user's account without password. Let's take Soluto's metro app as an example to describe the problem. The ap= p supports Facebook Login. As an attacker, we can write a regular Facebook = app. Once the victim user allows our app to access her Facebook data, we re= ceive an access_token from the traffic. Then, on our own machine (i.e., the= "attacker" machine), we run the metro app of Soluto, and use a HTTP proxy = to insert the victim's access_token into the traffic of Facebook login. Thr= ough this way, we are able to log into the victim's Soluto account from our= machine. Other than Soluto, we also have confirmed the same issue on anoth= er Windows 8 metro-app Givit. The Facebook SDK for Android apps (https://developers.facebook.com/docs/mob= ile/android/build/#sdk) seems to have the possibility to mislead developers= too. At least, the issue that we found is not clearly mentioned. In the SD= K, we ran the sample code called "Hackbook" using Android Emulator (imagine= it is an attacker device). Note that we have already received the access t= oken of the victim user from our regular Facebook app. We then inject the t= oken to the traffic of Hackbook. Through this way, Hackbook app on our own = machine recognizes us as the victim. Note that this is not a convincing sec= urity exploit yet, because this sample code does not include the server-sid= e code. However, given that we have seen real server-side code having this = problem, such as Soluto, Givit and others, we do believe that the sample co= de can mislead mobile/metro developers. We also suspect that this may be a = general issue of many OAuth implementations on mobile platforms, so we send= this message to OAuth Standard group as well. We have contacted the vendors of the two vulnerable metro-apps, Soluto and = Gavit. Please kindly give us an ack when you receive this message. If you want to = know more details, please let us know. Best Regards, Yuchen Zhou, Rui Wang, and Shuo Chen _______________________________________________ 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 -- 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 _______________________________________________ OAuth mailing 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 -- Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --_000_59E470B10C4630419ED717AC79FCF9A91A2C8949CH1PRD0410MB369_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Okay :-)

 

I’ve gotten lot of feedback … co= nsider a few snippets below, all part of this thread and in response to my = question:

 

 

Igor said: OAuth was not designed for this purpose; it was designe= d for delegating access.  In your use case,  there is no delegati= on. The only legitimate users are police officers and they "must logon to the video server in order to access video content."  An= d so the server must authenticate them. There is no need for OAuth in this = scenario.

 

Nat said: Ye= s, OAuth can be profiled to enable authentication. In fact, initial dr= aft of OpenID Connect was just like you described. 

 

Phil said: I see elements of improper use of OAuth flows as well a= s improper use of bearer tokens. We have to keep it a simple comment in bot= h specs.

 

Nat said: &#= 8220;I think you are way beyond what OAuth provides.”

 

Paul said: Nothing prevents you today from using OAuth as is to is= sue a token to the officer on the tablet, having the app use that token on = API calls, and the API making an authz decision based solely on enterprise policy, with no consent figuring in. … This doe= snt sound like a Connect Use Case to me - rather a pretty standard OAuth us= e case - albeit with no need to get user's consent (so actually simpler).

 

Chuck said: = This is basically describing how our OAuth deployment works, with the excep= tion that our token format is opaque.

 

Patreek said: My impression is that the fully specified OAuth flows to date focus on = certain key consumer-centred use-cases and that important enterprise flows such as= the one you have described are yet to be profiled.

 

I think the above just really drives home th= e fact that if OAuth is to be used for securing enterprise API calls in a p= ost-SOAP world, something needs to be stated more explicitly.  OAuth was not designed to provide authentication of the user to the RS.&nb= sp; But it seems we all agree that it can be profiled to do so.  Conne= ct is supposed to address authentication, but only from the view of the cli= ent, and not the RS.  Only the access token goes to the RS, so if we want to authenticate a user to the RS, then we= 217;re back to OAuth, since Connect doesn’t intend to send the id_tok= en to the RS.  Nat mentioned that it “could,” but I haven&= #8217;t seen that as part of the Connect specs thus far. 

 

There is *clearly* confusion around w= hether OAuth is to be used as authentication or not, and I think this threa= d has shown that.  If I’m going to deploy OAuth for Authenticati= on, then I really need a spec to point to (when my customers ask) that says it= can be used that way, especially with all the “OAuth is NOT authenti= cation” blog posts floating around in cyberspace these days. 

 

I’m thinking two things:

1)    =   it would at least be worthwhile to d= ocument this use case, and maybe the OAuth use cases draft would be a good = place to capture it. 

2)    =   maybe a stand alone, informational d= raft would also be a good idea, especially if we all agree that it’s = only a profile of OAuth, and does not require any technical changes to the core draft.  Something that talks outright about an en= terprise-centric world, rather than the user RO-centric world that OAuth wa= s really written around.  This might give future generation of Enterpr= ise folks like myself an easier time. 

 

 

Thoughts?

-adam

 

 

 

From: Nat Saki= mura [mailto:sakimura@gmail.com]
Sent: Sunday, June 24, 2012 8:29 AM
To: Paul Madsen
Cc: Lewis Adam-CAL022; oauth@ietf.org
Subject: Re: [OAUTH-WG] Report an authentication issue

 

 

On Fri, Jun 22, 2012 at 4:59 AM, Paul Madsen <paul.madsen@gmail.c= om> wrote:

Lewis, I think you are perhaps conflating the token = model (whether it has inherent structure or is merely a pointer to user inf= o) and who the RO owner is - user or enterprise.

Nothing prevents you today from using OAuth as is to issue a token to the o= fficer on the tablet, having the app use that token on API calls, and the A= PI making an authz decision based solely on enterprise policy, with no cons= ent figuring in.

 

Indeed, though I usually envisage that there is invi= sible consent authority a.k.a. corporate policy engine. 

 


Neither do you need a structured token (like id_token). The token issued ca= n merely be a pointer/artifact to the officer's actual roles, these obtaine= d by the API/RS by sending the tokens for 'validation' or 'introspection'

 

If RS can reach AS through network, yes, the access = token can act as an artifact that you do artifact resolve. That would have = a nice property of audit logging at the AS. It is not always true though. I= n one of my use case, RS was not able to directly talk to AS, in which case, you need a structured token. <= o:p>

 


This doesnt sound like a Connect Use Case to me - rather a pretty standard = OAuth use case - albeit with no need to get user's consent (so actually sim= pler).

 

If authentication and the identity of the accessor m= atters, yes. 

If it does not, maybe not.  

 


 
paul



On 6/21/12 12:01 PM, Lewis Adam-CAL022 wrote:

Hi Nat,

 

I’m beginning to wonder what it would take to add a = new profile of sorts to either OAuth or Connect. 

 

In the beginning there was SOAP, and the preferred method = to secure SOAP API calls was WS-Trust.

 

Now the world is moving toward RESTful APIs … and th= e preferred means to secure RESTful APIs is OAuth.

 

Except that OAuth is clearly written with the idea that th= e protected resources belong to the end user.

 

My use cases – and I imagine the use cases of many o= ther enterprises – is that the Owner of the resources is the Enterpri= se.  An employee is trying to access a database or video resources.  The e= nterprise RS needs to be able to 1) identify the user, and 2) make authoriz= ation decisions based on what roles that user has within the enterprise.&nb= sp; So in my scenario, when a police officer attempts to access a criminal records database, the database needs to know= who that officer is, and then decide if they have privilege to access the = database, and at what level (e.g. CRUD). 

 

WS-Trust fits this model well.  The user performs pri= mary authentication to the enterprise STS, which then grants the application client a SAML assertion.  When the user attempts to acces= s a records database, the SAML assertion is included in the SOAP message.&n= bsp; The records server authenticates the user based on the SAML assertion = and makes its authorization decisions.

 

This is the world I’m trying to migrate from, and it= really seems like I’m sometimes trying to make a square peg fit in a round hole.  I’m looking for OAuth/Connect to do for REST = what WS-TRUST did for SOAP.  I would like a native client talking to a= RS to be able to ask for an id_token, and then pass that id_token to the R= S when making its RESTful API calls, to enable the RS to authenticate the user.  I think that this would be really usefu= l for a lot of people besides me.  I keep hearing that there is nothin= g “preventing” me from doing this … but it hardly seems w= ithin the spirit of what OAuth was meant to do.  The id_token was clearly meant to enable a user to authenticate to a confidential clien= t  / web server … but was not meant for a native client to ident= ity / authenticate the user to a RS. 

 

 

Would there be any interest in exploring this further?

-adam

 

 

 

Yes, OAuth can be profiled to enable authentication. 

In fact, initial draft of OpenID Connect was just like you describ= ed. 

Essentially, we were using structured access_token. 

Later, we decided to separate the access token and id_token for se= veral reasons such as: 

 

  1. Better interop with existing OAuth implementations: by introducing id_token= , they do not need to touch the supposedly opaque (which means AS-RS may be= doing some proprietary thing inside it) access token. 
  2. Mixing up the audience (for id_token aka authn =3D client, and for access_t= oken aka authz =3D resource server) probably is expanding the attack surfac= e for security and privacy. 

Although we separated them out, a signed id_token includes the lef= t hash of access_token so access_token is also protected. <= /p>

 

Best, 

 

Nat

 

On Thu, Jun 21, 2012 at 5:21 AM, Lewis Adam-CAL022 <Adam.Lewis@motor= olasolutions.com> wrote:

Hi Igor,

 

As Justin just pointed out, consider the case where the vi= deo server is hosted by the state (e.g. California) and is accessed by police agencies in Los Angeles, San Francisco, and San Diego.&= nbsp; The State of California’s video server is the RS.  Each lo= cal police agency (LA/SF/SD) hosts an AS.  So when a police officer fr= om LAPD launches the video client app on the iPhone, the client makes an OAuth request to the LAPD’s AS, which authentica= tes the police officer using agency level credentials.  The access tok= en issued to the video client app on the iPhone is a JWT, signed by the age= ncy AS, which might look something like this:

 

{“typ”:”JWT”,"alg":"= ;ES256"}

{"iss":"https://as.lapd.california.gov",
  "prn":"alice@lapd.california.gov",
  "aud":" https://video_server1@state.california.gov&= quot;,
  "iat":1300815780,
  "exp":1300819380,
  "acr":”password”}

hq4zk+ZknjggCQgZm7ea8fI79gJEsRy3E8LHDpYXWQIgZpkJN9CMLG= 8ENR4Nrw+n7iyzixBvKXX8P53BTCT4VghPBWhFYSt9tHWu/AtJfOTh6qaAsNdeCyG86jmtp= 3TDMwuL/cBUj2OtBZOQMFn7jQ9YB7klIz3RqVL+wNmeWI4=3D

 

The JWT might be optionally encrypted using JWE. 

 

I think what is becoming clear (and this is what I’m= trying to vet) is that while there is nothing in OAuth that specifies authentication, it *can* be used for Authentication, if done in the= way that I describe.  If I’m wrong about this, I really need to= know.  I’ve vetted this idea of mine with quite of few people n= ow – both within context of the list and off-line – and I think I’m okay. If you see any holes in what I describe, please po= int them out as I would prefer to uncover them now rather than after implem= entation or deployment!

 

Essentially I’m using OAuth as a RESTful version of = WS-Trust, where my client can exchange primary credentials for a token (JWT) and present that token to a server as secondary authentication= .  It’s just that it’s RESTful instead of SOAP :-)<= o:p>

 

As Justin as pointed out … I’ve basically made= the access-token look like the id_token of Connect.  I was actually h= oping to lay a path to Connect, and use the id_token … until it was also p= ointed out that the id_token is really meant for the consumption of the cli= ent, not the RS :-(

 

 

 

From: oauth-bounces@i= etf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Igor Faynberg
Sent: Wednesday, June 20, 2012 2:39 PM
To: oauth@ietf.o= rg


Subject: Re: [OAUTH-WG] Report an authentication issue

 

But this use case  does need OAuth, period:



The video server is under the control of a police agency, and polic= e officers must logon to the video server in order to access video content.=

There is no delegation here, and there is no need to use third party for au= thentication. 

Igor

On 6/20/2012 3:26 PM, Justin Richer wrote:

In case it wasn't clear, I want to restate the original problem as= best as I understand it in a way that hopefully clears it up:

App A and app B are both valid registered OAuth clients to an OAuth protect= ed service.

The problem starts when app A gets handed a token that was issued for app B= and uses it to call an identity API on the OAuth service. Since app B can = get tokens just fine, they're bearer tokens, this is a fairly basic api cal= l, this function works just fine and returns the user info. This makes sense, since anyone who holds A's to= kens can do whatever A can do on behalf of that user. The issues start when= app B then decides that since they can make a call to the identity API wit= h a token then the user *must* be present. In other words, app B is confusing authorization to call an API w= ith authentication of the session.

OpenID Connect fixes this missed assumption by binding the ID Token to the = session and sending it along side the access token, but as you pointed out,= it's meant for consumption at the client, not the resource server, in gene= ral. That doesn't mean you can't send it to a resource server for your own purposes, of course. That's actu= ally how the session management endpoint works in Connect.

This isn't the only way to handle this problem -- if you put some structure= in your tokens, such as with JWT or SAML, then app A can tell that this is= n't a token issued to app A, but to app B, so it can call shenanigans and r= eject it then and there.

 -- Justin

On 06/20/2012 10:03 AM, Lewis Adam-CAL022 wrote:

I am entirely confused.

 

I understand what everybody is saying for confidential cli= ents, no problem here.

 

I fall apart when thinking of iPhone apps.  Consider = the scenario where I deploy a video server, and write an iPhone app to talk to the video server.  The video server is under the contr= ol of a police agency, and police officers must logon to the video server i= n order to access video content.  So the police office launches their = iPhone video client app.

 

If I wanted to solve authenticati= on using “traditional” client-server authentication, the user e= nters their username / password into the client, and the client sends the username / password off to the server, which authenticates it, or poss= ibly uses HTTP digest. 

If I wanted to use OpenID, the cl= ient would attempt to reach the video server (RP), the server would redirec= t the client to the OP, OP authenticates user, and OP redirects client back to the server/RP with an assertion that primary authentication= was successful. 

If I wanted to use OAuth, the cli= ent would send an authorization request to the server’s AS, which wou= ld authenticate the user of the client, and ultimately result in the client possessing an access-token.  My thinking is that this a= ccess token (let’s assume it’s a JWT) would contain the user= 217;s identity, a statement of what type of primary authentication was used= (auth context), an expiration, and an audience claim.  This sounds a lot like authentication to me, and it’s where I get co= nfused.  Is it just because OAuth does not explicitly define this?&nbs= p; Is there a threat in using OAuth as I describe? 

If I wanted to use Connect, well I’m not even sure how the= id_token as defined by Connect helps this use case.  The id_token see= ms to make sense when the client is a confidential web server, but it’s not clear what an iPhone app would do with the id_token …= it’s the server in the backend that needs to authenticate the user, = the iPhone app is just an interface to talk to the server.  And it see= ms as I learn more about connect that the id_token is not meant to be sent from the iPhone app to the server, just the access token.=   So it’s really not clear how Connect helps solve authenticatio= n for an iPhone client app talking to a video server.  If I’m se= nding access-tokens, it’s just OAuth again.

 

What am I still missing?

adam

 

 

From: oauth-bounces@i= etf.org [ma= ilto:oauth-bounces@ietf.org] On Behalf Of Kristofor Selden
Sent: Saturday, June 16, 2012 11:33 AM
To: nov matake; oauth
Cc: Yuchen Zhou; Luke Melia; Shuo Chen (MSR)
Subject: Re: [OAUTH-WG] Report an authentication issue

 

Nov demonstrated the problem to us at Yapp and we used solution 4 = (because the solution is server side and our app was in the app store).

 

FB Connect is authentication and authorization, where OAuth 2 is concerned only with authorizatio= n – I'm not sure that app developers appreciate this subtlety.

 

With OAuth 2 you authorize an app to use a protected resource. &nb= sp;With FB Connect, you do that, but also authenticate with the app you are authorizing.

 

So the access_token protects not just the FB resources but the aut= h end point of the authorized app (very common with apps that use the iOS S= DK).  So now the app needs a way to verify that it was the app that was authorized to FB.

 

Solution 4 explanation: on FB you can register a iPhone app and a = server app with the same client_id and get a client_secret for use on the s= erver.  The server side API posts the access_token, client_id, and client_secret to h= ttps://graph.facebook.com/app to verify that the bearer token= actually belongs to the app that is being authenticated before assuming they are authorized to the app's protected resources.<= /p>

 

Kris

 

On Jun 15, 2012, at 8:22 PM, nov matake wrote:

 

There are 4 ways to fix this issue.

 

1. Use response_type=3Dtoken%20code (It's not in OAuth 2.0 Co= re, but seems best way for interoperability)

2. Use singed_request (or some signed token like JWT)

3. Use grant_type=3Dfb_exchange_token (Facebook custom way)

4. Access to https://graph.facebook.com/app?access_token=3DYOUR_TOKEN (Facebook cust= om way, moreover undocumented API)

 

Two iPhone app developers I reported this issue fixed it by using = (4).

 

I also tried to use (1) for my own iPhone app implementation, but = unfortunately it doesn't work when using authorization codes obtained via F= B iOS SDK.

So I'm using (3) in my case.

 

nov

 

On 2012/06/16, at 9:16, Nat Sakimura wrote:

 

As to how the fix was done, Nov can provide more detail, but ...&n= bsp;

 

1. Properly verify the signature/HMAC of the "signed_request&= quot;. This will essentially audience restricts the token. =

2. There is an undocumented API for Facebook which returns to whom= the token was issued. This also audience restricts the token. 

 

The service that fixed took these measures. Note that none of the = above is defined in OAuth. 

The same facility was called "id_token" and "check = ID endpoint" for OpenID Connect. 

 

The scale of the impact is large, too large to disclose the actual= names in the public list, though, eventually, we would publish them in a p= aper. 

 

Nat

On Sat, Jun 16, 2012 at 5:34 AM, Francisco Corella <fcorella@pomcor.com> wrote:<= o:p>

Hi Nat and Rui,

Rui, you say that the vulnerability that you found was due to a
"common misunderstanding among developers", but the attack you describe can be carried out against any app that uses the OAuth
"implicit grant flow", which Facebook calls "client-side
authentication".  No misunderstanding seems necessary.  What=
misunderstanding are you referring to?  I followed the link in your message to the Sophos post, and from there the link to the article in
The Register.  The article in The Register says that Facebook had
"fixed the vulnerability promptly".  How did they fix it?&nb= sp; The
instructions that Facebook provides for implementing "Client-side
authentication without the JS SDK" at
https://developers.facebook.com/docs/authentic= ation/client-side/#no-jssdk
still allows the attack.

Nat, I agree that the blog post by John Bradley that you link to
refers to the same vulnerability reported by Rui.  You say that some apps have issued a patch to fix it.  Could you explain what the fix was?

Francisco

 

From: Nat Sakimura <sakimura@gmail.com>
To: rui wang <ruiwangwarm@gmail.com>
Cc: matake nov <nov@matake.jp>; Yuchen Zhou <t-yuzhou@microsoft.com>; oauth <oauth@ietf.org>; Shuo Chen (MSR) <shuochen@microsoft.com>
Sent: Thursday, June 14, 2012 1:50 PM
Subject: Re: [OAUTH-WG] Report an authentication issue

 

This is a fairly well known (hopefully by now) issue. We, at the O= penID Foundation, call it "access_token phishing" attack these da= ys. See: http://www.thread-safe.com/2= 012/01/problem-with-oauth-for-authentication.html

 

Nov Matake has actually built the code on iPhone to verify the pro= blem, and has notified bunch of parties back in February including Facebook= and Apple. We have the code that actually runs on a phone, and we have successfully logged in to bunch of apps, incl= uding very well known ones. They were all informed of the issue. Some immed= iately issued a patch to fix it while others have not.  

 

The problem is that even if these apps gets fixed, the problem doe= s not go away. As long as the attacker has the vulnerable version of the ap= p, he still can impersonate the victim. To stop it, the server side has to completely disable the older version, w= hich means the service has to cut off many users pausing business problems.=  

 

Nat

On Fri, Jun 15, 2012 at 2:18 AM, rui wang <ruiwangwarm@gmail.com> wrote:=

Dear Facebook Security Team and OAuth Standard group,

We are a research team in Microsoft Research. In January, 2011, we= reported a vulnerability in Facebook Connect which allowed everyone to sig= n into Facebook-secured relying parties without password. It was promptly fixed after reporting. (http://nakedsecurity.sophos.com/2011/02/02/facebo= ok-flaw-websites-steal-personal-data/)

Recently, we found a common misunderstanding among developers of m= obile/metro apps when using OAuth (including Facebook’s OAuth) for au= thentication. The vulnerability resulted from this misunderstanding also allows an attacker to log into a victim user's = account without password.

Let's take Soluto's metro app as an example to describe the proble= m. The app supports Facebook Login. As an attacker, we can write a regular = Facebook app. Once the victim user allows our app to access her Facebook data, we receive an access_token from the t= raffic. Then, on our own machine (i.e., the "attacker" machine), = we run the metro app of Soluto, and use a HTTP proxy to insert the victim's= access_token into the traffic of Facebook login. Through this way, we are able to log into the victim's Soluto accou= nt from our machine. Other than Soluto, we also have confirmed the same iss= ue on another Windows 8 metro-app Givit.

The Facebook SDK for Android apps (https://devel= opers.facebook.com/docs/mobile/android/build/#sdk) seems to have the possibility to mislead developers too. At least, the iss= ue that we found is not clearly mentioned. In the SDK, we ran the sample co= de called "Hackbook" using Android Emulator (imagine it is an att= acker device). Note that we have already received the access token of the victim user from our regular Facebook app. We then= inject the token to the traffic of Hackbook. Through this way, Hackbook ap= p on our own machine recognizes us as the victim. Note that this is not a c= onvincing security exploit yet, because this sample code does not include the server-side code. However, g= iven that we have seen real server-side code having this problem, such as S= oluto, Givit and others, we do believe that the sample code can mislead mob= ile/metro developers. We also suspect that this may be a general issue of many OAuth implementations on mobile p= latforms, so we send this message to OAuth Standard group as well.

We have contacted the vendors of the two vulnerable metro-apps, So= luto and Gavit.

Please kindly give us an ack when you receive this message. If you= want to know more details, please let us know.

Best Regards,
Yuchen Zhou, Rui Wang, and Shuo Chen


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

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



 

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



 

--
Nat Sakimura (=3Dnat)

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

 

--_000_59E470B10C4630419ED717AC79FCF9A91A2C8949CH1PRD0410MB369_-- From bcampbell@pingidentity.com Mon Jun 25 11:16:52 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E22DD21F845D for ; Mon, 25 Jun 2012 11:16:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.99 X-Spam-Level: X-Spam-Status: No, score=-5.99 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id efxC6DQU-PKX for ; Mon, 25 Jun 2012 11:16:52 -0700 (PDT) Received: from na3sys009aog106.obsmtp.com (na3sys009aob106.obsmtp.com [74.125.149.76]) by ietfa.amsl.com (Postfix) with ESMTP id 822DD21F8468 for ; Mon, 25 Jun 2012 11:16:50 -0700 (PDT) Received: from mail-gg0-f177.google.com ([209.85.161.177]) (using TLSv1) by na3sys009aob106.postini.com ([74.125.148.12]) with SMTP ID DSNKT+irEtmKWzMA5mp5bJQzcHu6Hv7vbqol@postini.com; Mon, 25 Jun 2012 11:16:51 PDT Received: by ggcs5 with SMTP id s5so3331880ggc.36 for ; Mon, 25 Jun 2012 11:16:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=bVGJgywR/2aqOSFQJCiCC1xNpv96xfmJHeqodU8geco=; b=PQqV5B/6e6FeTZfpLuea7sQiFrQKFITKpdsibLIgvlvaSqOW2cYs8BbLP6XcyMNBlw lTdkkFwkqLdZBIv0gjMLqka3grbrdKyp8egwnEB91O30+ZZOxiH3dg2rJjyZi2FcFw+Q 8bHLD9BMbQfrJrVp3fB9jEmeiAnqKEZmDyJEVrKMoGUqQrAzChBlplpryuIMc8g9lDw6 wOnY9SgMh58EX8LPMYrxkmpd968ltl64BGvFBcrCa9xfh7GYDyH8yVixM0sHDrs1KBCb VxnRXgQD0L8ZPLXgRDuQuKd9KdgSn0570YIC6ebB3FZLoS7XZTh5sjXGxPBgkETY+Ger I0uA== Received: by 10.60.29.72 with SMTP id i8mr13134608oeh.26.1340648208649; Mon, 25 Jun 2012 11:16:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.174.98 with HTTP; Mon, 25 Jun 2012 11:16:18 -0700 (PDT) In-Reply-To: <0CBAEB56DDB3A140BA8E8C124C04ECA20107E5A6@P3PWEX2MB008.ex2.secureserver.net> References: <4FE1C16D.6010602@cs.tcd.ie> <4CD0B85C-C88D-4B52-81E4-5D53A25E60EF@cs.tcd.ie> <4E1F6AAD24975D4BA5B16804296739436656365A@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B168042967394366565C12@TK5EX14MBXC283.redmond.corp.microsoft.com> <0CBAEB56DDB3A140BA8E8C124C04ECA20107E5A6@P3PWEX2MB008.ex2.secureserver.net> From: Brian Campbell Date: Mon, 25 Jun 2012 12:16:18 -0600 Message-ID: To: Eran Hammer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlQKQeAkHI0P96dOnhBxANPqr8jmiAhth3/SjDCKUptPWKfs9UiSNN5OC/yoQe9ny2f7pA8 Cc: "oauth@ietf.org" , Barry Leiba Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-urn-sub-ns-02 X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 18:16:53 -0000 The sentiment of the WG seems to be leaning towards Specification Required rather than Expert Review. Barring any objections, I'll update the draft to reflect that and publish a new version later today. On Sun, Jun 24, 2012 at 1:22 AM, Eran Hammer wrote: > This boils down to whether the registration template can contain all the = detailes required for interoperability or not. If not, you need a specifica= tion. > > EH > >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> Of Mike Jones >> Sent: Saturday, June 23, 2012 11:31 AM >> To: John Bradley; Hannes Tschofenig >> Cc: Barry Leiba; oauth@ietf.org >> Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-urn-sub-ns-02 >> >> I agree that Specification Required would be fine. =A0I'd rather that th= ere be a >> publicly available specification defining the URN than one potentially >> available only to the expert reviewers. >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 -- Mike >> >> -----Original Message----- >> From: John Bradley [mailto:ve7jtb@ve7jtb.com] >> Sent: Saturday, June 23, 2012 8:36 AM >> To: Hannes Tschofenig >> Cc: Mike Jones; oauth@ietf.org; Barry Leiba >> Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-urn-sub-ns-02 >> >> I think Specification required is fine. =A0It allows a OIDF or OASIS spe= c to be >> used as the basis for the registration withh appropriate expert review. >> >> John B. >> >> Sent from my iPad >> >> On 2012-06-23, at 8:31 AM, Hannes Tschofenig >> wrote: >> >> > Hi Mike, >> > >> > the point is not that other groups, like OASIS, cannot use them. They = can >> use the extensions. >> > >> > The question is more what process and documentation is needed to allow >> OASIS (and others) to define their own extensions. >> > >> > So far, OASIS had not been interested for any extension (at least from >> what I know). The OpenID community, to which you also belong, had define= d >> extensions (and brought some of them to the IETF) but had been quite >> careful themselves to ensure proper review and documentation. >> > >> > So, if you look at the most important decision points then you have: >> > >> > 1) do you want a requirement for a specification, i.e., when someone >> defines an extension do you want it to be documented somewhere? >> > >> > 2) do you envision a review from experts (e.g., checking whether the s= tuff >> makes any sense or conflicts with some other already available extension= s)? >> > >> > http://tools.ietf.org/html/rfc5226 provides a good discussion about th= is >> topic. >> > >> > If the answer to the above-listed questions is YES then you probably a= t >> least want 'Specification Required' as a policy. >> > >> > Ciao >> > Hannes >> > >> > >> > On Jun 21, 2012, at 10:49 PM, Mike Jones wrote: >> > >> >> I'd argue that the registration regime chosen should be flexible enou= gh to >> permit OASIS or OpenID specs to use it. Otherwise, as someone else >> pointed, people will work around the limitation by using unregistered va= lues >> - which helps no one. >> >> >> >> -- Mike >> >> >> >> From: Barry Leiba >> >> Sent: 6/21/2012 12:31 PM >> >> To: Stephen Farrell >> >> Cc: oauth@ietf.org >> >> Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-urn-sub-ns-02 >> >> >> >>>> Stephen: >> >>>> Yeah, I'm not sure Standards Track is needed. >> >>> >> >>> On this bit: I personally don't care, except that we don't have to >> >>> do it twice because someone later on thinks the opposite and wins >> >>> that argument, which I'd rather not have at all =A0(My one-track >> >>> mind:-) Doing the 4 week last call means once is enough. But I'm ok = with >> whatever the WG want. >> >> >> >> Well, it's not a 4-week LC, but a 2-week one. =A0Anyway, yes, I see >> >> your point, and I've done that with other documents. =A0Better to mak= e >> >> it Standards Track for now, note in the shepherd writeup that >> >> Informational is probably OK, and let the IESG decide. >> >> >> >> b >> >> _______________________________________________ >> >> OAuth mailing 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 Adam.Lewis@motorolasolutions.com Mon Jun 25 11:31:30 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 424D711E80AA for ; Mon, 25 Jun 2012 11:31:30 -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_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 dJoGhCdrhwS6 for ; Mon, 25 Jun 2012 11:31:18 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe010.messaging.microsoft.com [216.32.180.30]) by ietfa.amsl.com (Postfix) with ESMTP id 1717311E80B7 for ; Mon, 25 Jun 2012 11:31:17 -0700 (PDT) Received: from mail76-va3-R.bigfish.com (10.7.14.235) by VA3EHSOBE009.bigfish.com (10.7.40.29) with Microsoft SMTP Server id 14.1.225.23; Mon, 25 Jun 2012 18:29:38 +0000 Received: from mail76-va3 (localhost [127.0.0.1]) by mail76-va3-R.bigfish.com (Postfix) with ESMTP id A0E3A2002AC for ; Mon, 25 Jun 2012 18:29:38 +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: -18 X-BigFish: VPS-18(zzbb2dI98dI9371Ic85fh1418Ib457nzz1202hzz1033IL8275bh8275dhz2fh2a8h683h839hd25hf0ah) Received-SPF: pass (mail76-va3: 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.244.181; KIP:(null); UIP:(null); (null); H:CH1PRD0410HT005.namprd04.prod.outlook.com; R:internal; EFV:INT Received: from mail76-va3 (localhost.localdomain [127.0.0.1]) by mail76-va3 (MessageSwitch) id 1340648974815857_14153; Mon, 25 Jun 2012 18:29:34 +0000 (UTC) Received: from VA3EHSMHS003.bigfish.com (unknown [10.7.14.238]) by mail76-va3.bigfish.com (Postfix) with ESMTP id C26E9100154 for ; Mon, 25 Jun 2012 18:29:34 +0000 (UTC) Received: from il06msg01.mot-solutions.com (129.188.136.17) by VA3EHSMHS003.bigfish.com (10.7.99.13) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 25 Jun 2012 18:29:33 +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 q5PJHKsZ028540 for ; Mon, 25 Jun 2012 14:17:20 -0500 (CDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe002.messaging.microsoft.com [216.32.180.185]) by il06msg01.mot-solutions.com (8.14.3/8.14.3) with ESMTP id q5PJHJh7028534 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 25 Jun 2012 14:17:19 -0500 (CDT) Received: from mail152-co1-R.bigfish.com (10.243.78.238) by CO1EHSOBE002.bigfish.com (10.243.66.65) with Microsoft SMTP Server id 14.1.225.23; Mon, 25 Jun 2012 18:29:30 +0000 Received: from mail152-co1 (localhost [127.0.0.1]) by mail152-co1-R.bigfish.com (Postfix) with ESMTP id 7ED1C880109 for ; Mon, 25 Jun 2012 18:29:30 +0000 (UTC) Received: from mail152-co1 (localhost.localdomain [127.0.0.1]) by mail152-co1 (MessageSwitch) id 1340648965793516_25946; Mon, 25 Jun 2012 18:29:25 +0000 (UTC) Received: from CO1EHSMHS009.bigfish.com (unknown [10.243.78.236]) by mail152-co1.bigfish.com (Postfix) with ESMTP id B51B1A00044; Mon, 25 Jun 2012 18:29:25 +0000 (UTC) Received: from CH1PRD0410HT005.namprd04.prod.outlook.com (157.56.244.181) by CO1EHSMHS009.bigfish.com (10.243.66.19) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 25 Jun 2012 18:29:25 +0000 Received: from CH1PRD0410MB369.namprd04.prod.outlook.com ([169.254.12.121]) by CH1PRD0410HT005.namprd04.prod.outlook.com ([10.255.147.40]) with mapi id 14.16.0164.004; Mon, 25 Jun 2012 18:31:02 +0000 From: Lewis Adam-CAL022 To: Torsten Lodderstedt Thread-Topic: [OAUTH-WG] Report an authentication issue Thread-Index: AQHNUWCOQ6l+bX+OSkGiyy7VSGUjQZcLXEdA Date: Mon, 25 Jun 2012 18:31:01 +0000 Message-ID: <59E470B10C4630419ED717AC79FCF9A91A2CC980@CH1PRD0410MB369.namprd04.prod.outlook.com> References: <1339792496.52712.YahooMailNeo@web125501.mail.ne1.yahoo.com> <59E470B10C4630419ED717AC79FCF9A9108898EE@BL2PRD0410MB363.namprd04.prod.outlook.com> <4FE223E4.6060307@mitre.org> <4FE226BC.6010403@alcatel-lucent.com> <59E470B10C4630419ED717AC79FCF9A910889AB5@BL2PRD0410MB363.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A917052BC8@SN2PRD0410MB370.namprd04.prod.outlook.com> <4FE5F446.2010905@lodderstedt.net> In-Reply-To: <4FE5F446.2010905@lodderstedt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.167.129.37] Content-Type: multipart/alternative; boundary="_000_59E470B10C4630419ED717AC79FCF9A91A2CC980CH1PRD0410MB369_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%1294$Dn%LODDERSTEDT.NET$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] Report an authentication issue X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 18:31:30 -0000 --_000_59E470B10C4630419ED717AC79FCF9A91A2CC980CH1PRD0410MB369_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Torsten, Your option #2 below is the model I was first attracted to. The architectu= re as you mention is clean. But the need to run multiple round trips (one = to get the SAML assertion, another to get the access token), plus the inher= ently large size of a SAML assertion (compared to an unstructured access to= ken, or even a JWT), was producing too much latency. Hence I have moved my interest to option #1. I think the easiest thing to = do is have the user authenticate to the local AS, get in return a structure= d JWT access token (which will look a lot like the Connect id_token) and pr= esent that JWT access token to the RS in the different domain, and that RS = will use that JWT access token to authenticate the user. Ideally I would l= ike to use the id_token from Connect, but I'm getting push back on that ide= a since the id_token has really been profiled for the client, not the RS. -adam From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] Sent: Saturday, June 23, 2012 11:52 AM To: Lewis Adam-CAL022 Cc: Nat Sakimura; oauth@ietf.org Subject: Re: [OAUTH-WG] Report an authentication issue Hi Adam, let me explain why I don't see a need for a new profile. As far as I understand your scenario, you want to give users from different= security domains access to the same RS. I see two ways to handle this without any need to extend OAuth: 1) multiple AS (also performing authentication) You already mentioned this option. Every department runs its AS, which auth= enticates and authorizes access to the RS for the particular officer. As a = pre-requisite, RS and ASs must use the same token design (self-contained vs= . handle-based), token format (e.g. SAML or JWT) and the RS must _rely_ mul= tiple ASs. This will be possible to implement with the drafts under conside= ration (namely JWT), but I consider this a substantial restrictions on the = design of the RS! 2) single AS relying on multiple IDPs for authenticaton The alternative is to let a dedicated AS issue the tokens for the central R= S. This AS uses the IDPs of the different security domain for the purpose o= f authenticating the officers (e.g. using SAML or OpenID). The difference i= s that the RS only trusts this single AS, which is easier to implement beca= use it is a nearly private relationship. best regards, Torsten. Am 21.06.2012 18:01, schrieb Lewis Adam-CAL022: Hi Nat, I'm beginning to wonder what it would take to add a new profile of sorts to= either OAuth or Connect. In the beginning there was SOAP, and the preferred method to secure SOAP AP= I calls was WS-Trust. Now the world is moving toward RESTful APIs ... and the preferred means to = secure RESTful APIs is OAuth. Except that OAuth is clearly written with the idea that the protected resou= rces belong to the end user. My use cases - and I imagine the use cases of many other enterprises - is t= hat the Owner of the resources is the Enterprise. An employee is trying to= access a database or video resources. The enterprise RS needs to be able = to 1) identify the user, and 2) make authorization decisions based on what = roles that user has within the enterprise. So in my scenario, when a polic= e officer attempts to access a criminal records database, the database need= s to know who that officer is, and then decide if they have privilege to ac= cess the database, and at what level (e.g. CRUD). WS-Trust fits this model well. The user performs primary authentication to= the enterprise STS, which then grants the application client a SAML assert= ion. When the user attempts to access a records database, the SAML asserti= on is included in the SOAP message. The records server authenticates the u= ser based on the SAML assertion and makes its authorization decisions. This is the world I'm trying to migrate from, and it really seems like I'm = sometimes trying to make a square peg fit in a round hole. I'm looking for= OAuth/Connect to do for REST what WS-TRUST did for SOAP. I would like a n= ative client talking to a RS to be able to ask for an id_token, and then pa= ss that id_token to the RS when making its RESTful API calls, to enable the= RS to authenticate the user. I think that this would be really useful for= a lot of people besides me. I keep hearing that there is nothing "prevent= ing" me from doing this ... but it hardly seems within the spirit of what O= Auth was meant to do. The id_token was clearly meant to enable a user to a= uthenticate to a confidential client / web server ... but was not meant fo= r a native client to identity / authenticate the user to a RS. Would there be any interest in exploring this further? -adam From: Nat Sakimura [mailto:sakimura@gmail.com] Sent: Wednesday, June 20, 2012 8:09 PM To: Lewis Adam-CAL022 Cc: igor.faynberg@alcatel-lucent.com; oauth@ietf.org Subject: Re: [OAUTH-WG] Report an authentication issue Yes, OAuth can be profiled to enable authentication. In fact, initial draft of OpenID Connect was just like you described. Essentially, we were using structured access_token. Later, we decided to separate the access token and id_token for several rea= sons such as: 1. Better interop with existing OAuth implementations: by introducing id= _token, they do not need to touch the supposedly opaque (which means AS-RS = may be doing some proprietary thing inside it) access token. 2. Mixing up the audience (for id_token aka authn =3D client, and for ac= cess_token aka authz =3D resource server) probably is expanding the attack = surface for security and privacy. Although we separated them out, a signed id_token includes the left hash of= access_token so access_token is also protected. Best, Nat On Thu, Jun 21, 2012 at 5:21 AM, Lewis Adam-CAL022 > wrote: Hi Igor, As Justin just pointed out, consider the case where the video server is hos= ted by the state (e.g. California) and is accessed by police agencies in Lo= s Angeles, San Francisco, and San Diego. The State of California's video s= erver is the RS. Each local police agency (LA/SF/SD) hosts an AS. So when= a police officer from LAPD launches the video client app on the iPhone, th= e client makes an OAuth request to the LAPD's AS, which authenticates the p= olice officer using agency level credentials. The access token issued to t= he video client app on the iPhone is a JWT, signed by the agency AS, which = might look something like this: {"typ":"JWT","alg":"ES256"} {"iss":"https://as.lapd.california.gov", "prn":"alice@lapd.california.gov", "aud":" https://video_server1@state.california.gov", "iat":1300815780, "exp":1300819380, "acr":"password"} hq4zk+ZknjggCQgZm7ea8fI79gJEsRy3E8LHDpYXWQIgZpkJN9CMLG8ENR4Nrw+n7iyzixBvKXX= 8P53BTCT4VghPBWhFYSt9tHWu/AtJfOTh6qaAsNdeCyG86jmtp3TDMwuL/cBUj2OtBZOQMFn7jQ= 9YB7klIz3RqVL+wNmeWI4=3D The JWT might be optionally encrypted using JWE. I think what is becoming clear (and this is what I'm trying to vet) is that= while there is nothing in OAuth that specifies authentication, it *can* be= used for Authentication, if done in the way that I describe. If I'm wrong= about this, I really need to know. I've vetted this idea of mine with qui= te of few people now - both within context of the list and off-line - and I= think I'm okay. If you see any holes in what I describe, please point them= out as I would prefer to uncover them now rather than after implementation= or deployment! Essentially I'm using OAuth as a RESTful version of WS-Trust, where my clie= nt can exchange primary credentials for a token (JWT) and present that toke= n to a server as secondary authentication. It's just that it's RESTful ins= tead of SOAP :-) As Justin as pointed out ... I've basically made the access-token look like= the id_token of Connect. I was actually hoping to lay a path to Connect, = and use the id_token ... until it was also pointed out that the id_token is= really meant for the consumption of the client, not the RS :-( From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Igor Faynberg Sent: Wednesday, June 20, 2012 2:39 PM To: oauth@ietf.org Subject: Re: [OAUTH-WG] Report an authentication issue But this use case does need OAuth, period: The video server is under the control of a police agency, and police office= rs must logon to the video server in order to access video content. There is no delegation here, and there is no need to use third party for au= thentication. Igor On 6/20/2012 3:26 PM, Justin Richer wrote: In case it wasn't clear, I want to restate the original problem as best as = I understand it in a way that hopefully clears it up: App A and app B are both valid registered OAuth clients to an OAuth protect= ed service. The problem starts when app A gets handed a token that was issued for app B= and uses it to call an identity API on the OAuth service. Since app B can = get tokens just fine, they're bearer tokens, this is a fairly basic api cal= l, this function works just fine and returns the user info. This makes sens= e, since anyone who holds A's tokens can do whatever A can do on behalf of = that user. The issues start when app B then decides that since they can mak= e a call to the identity API with a token then the user *must* be present. = In other words, app B is confusing authorization to call an API with authen= tication of the session. OpenID Connect fixes this missed assumption by binding the ID Token to the = session and sending it along side the access token, but as you pointed out,= it's meant for consumption at the client, not the resource server, in gene= ral. That doesn't mean you can't send it to a resource server for your own = purposes, of course. That's actually how the session management endpoint wo= rks in Connect. This isn't the only way to handle this problem -- if you put some structure= in your tokens, such as with JWT or SAML, then app A can tell that this is= n't a token issued to app A, but to app B, so it can call shenanigans and r= eject it then and there. -- Justin On 06/20/2012 10:03 AM, Lewis Adam-CAL022 wrote: I am entirely confused. I understand what everybody is saying for confidential clients, no problem = here. I fall apart when thinking of iPhone apps. Consider the scenario where I d= eploy a video server, and write an iPhone app to talk to the video server. = The video server is under the control of a police agency, and police offic= ers must logon to the video server in order to access video content. So th= e police office launches their iPhone video client app. If I wanted to solve authentication using "traditional" client-server authe= ntication, the user enters their username / password into the client, and t= he client sends the username / password off to the server, which authentica= tes it, or possibly uses HTTP digest. If I wanted to use OpenID, the client would attempt to reach the video serv= er (RP), the server would redirect the client to the OP, OP authenticates u= ser, and OP redirects client back to the server/RP with an assertion that p= rimary authentication was successful. If I wanted to use OAuth, the client would send an authorization request to= the server's AS, which would authenticate the user of the client, and ulti= mately result in the client possessing an access-token. My thinking is tha= t this access token (let's assume it's a JWT) would contain the user's iden= tity, a statement of what type of primary authentication was used (auth con= text), an expiration, and an audience claim. This sounds a lot like authen= tication to me, and it's where I get confused. Is it just because OAuth do= es not explicitly define this? Is there a threat in using OAuth as I descr= ibe? If I wanted to use Connect, well I'm not even sure how the id_token as defi= ned by Connect helps this use case. The id_token seems to make sense when = the client is a confidential web server, but it's not clear what an iPhone = app would do with the id_token ... it's the server in the backend that need= s to authenticate the user, the iPhone app is just an interface to talk to = the server. And it seems as I learn more about connect that the id_token i= s not meant to be sent from the iPhone app to the server, just the access t= oken. So it's really not clear how Connect helps solve authentication for = an iPhone client app talking to a video server. If I'm sending access-toke= ns, it's just OAuth again. What am I still missing? adam From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Kristofor Selden Sent: Saturday, June 16, 2012 11:33 AM To: nov matake; oauth Cc: Yuchen Zhou; Luke Melia; Shuo Chen (MSR) Subject: Re: [OAUTH-WG] Report an authentication issue Nov demonstrated the problem to us at Yapp and we used solution 4 (because = the solution is server side and our app was in the app store). FB Connect is authentication and authorization, where OAuth 2 is concerned = only with authorization - I'm not sure that app developers appreciate this = subtlety. With OAuth 2 you authorize an app to use a protected resource. With FB Con= nect, you do that, but also authenticate with the app you are authorizing. So the access_token protects not just the FB resources but the auth end poi= nt of the authorized app (very common with apps that use the iOS SDK). So = now the app needs a way to verify that it was the app that was authorized t= o FB. Solution 4 explanation: on FB you can register a iPhone app and a server ap= p with the same client_id and get a client_secret for use on the server. T= he server side API posts the access_token, client_id, and client_secret to = https://graph.facebook.com/app to verify that the bearer token actually belongs to the app = that is being authenticated before assuming they are authorized to the app'= s protected resources. Kris On Jun 15, 2012, at 8:22 PM, nov matake wrote: There are 4 ways to fix this issue. 1. Use response_type=3Dtoken%20code (It's not in OAuth 2.0 Core, but seems = best way for interoperability) 2. Use singed_request (or some signed token like JWT) 3. Use grant_type=3Dfb_exchange_token (Facebook custom way) 4. Access to https://graph.facebook.com/app?access_token=3DYOUR_TOKEN (Face= book custom way, moreover undocumented API) Two iPhone app developers I reported this issue fixed it by using (4). I also tried to use (1) for my own iPhone app implementation, but unfortuna= tely it doesn't work when using authorization codes obtained via FB iOS SDK= . So I'm using (3) in my case. nov On 2012/06/16, at 9:16, Nat Sakimura wrote: As to how the fix was done, Nov can provide more detail, but ... 1. Properly verify the signature/HMAC of the "signed_request". This will es= sentially audience restricts the token. 2. There is an undocumented API for Facebook which returns to whom the toke= n was issued. This also audience restricts the token. The service that fixed took these measures. Note that none of the above is = defined in OAuth. The same facility was called "id_token" and "check ID endpoint" for OpenID = Connect. The scale of the impact is large, too large to disclose the actual names in= the public list, though, eventually, we would publish them in a paper. Nat On Sat, Jun 16, 2012 at 5:34 AM, Francisco Corella > wrote: Hi Nat and Rui, Rui, you say that the vulnerability that you found was due to a "common misunderstanding among developers", but the attack you describe can be carried out against any app that uses the OAuth "implicit grant flow", which Facebook calls "client-side authentication". No misunderstanding seems necessary. What misunderstanding are you referring to? I followed the link in your message to the Sophos post, and from there the link to the article in The Register. The article in The Register says that Facebook had "fixed the vulnerability promptly". How did they fix it? The instructions that Facebook provides for implementing "Client-side authentication without the JS SDK" at https://developers.facebook.com/docs/authentication/client-side/#no-jssdk still allows the attack. Nat, I agree that the blog post by John Bradley that you link to refers to the same vulnerability reported by Rui. You say that some apps have issued a patch to fix it. Could you explain what the fix was? Francisco ________________________________ From: Nat Sakimura > To: rui wang > Cc: matake nov >; Yuchen Zhou >; oauth >; Shuo Chen (MSR) > Sent: Thursday, June 14, 2012 1:50 PM Subject: Re: [OAUTH-WG] Report an authentication issue This is a fairly well known (hopefully by now) issue. We, at the OpenID Fou= ndation, call it "access_token phishing" attack these days. See: http://www= .thread-safe.com/2012/01/problem-with-oauth-for-authentication.html Nov Matake has actually built the code on iPhone to verify the problem, and= has notified bunch of parties back in February including Facebook and Appl= e. We have the code that actually runs on a phone, and we have successfully= logged in to bunch of apps, including very well known ones. They were all = informed of the issue. Some immediately issued a patch to fix it while othe= rs have not. The problem is that even if these apps gets fixed, the problem does not go = away. As long as the attacker has the vulnerable version of the app, he sti= ll can impersonate the victim. To stop it, the server side has to completel= y disable the older version, which means the service has to cut off many us= ers pausing business problems. Nat On Fri, Jun 15, 2012 at 2:18 AM, rui wang > wrote: Dear Facebook Security Team and OAuth Standard group, We are a research team in Microsoft Research. In January, 2011, we reported= a vulnerability in Facebook Connect which allowed everyone to sign into Fa= cebook-secured relying parties without password. It was promptly fixed afte= r reporting. (http://nakedsecurity.sophos.com/2011/02/02/facebook-flaw-webs= ites-steal-personal-data/) Recently, we found a common misunderstanding among developers of mobile/met= ro apps when using OAuth (including Facebook's OAuth) for authentication. T= he vulnerability resulted from this misunderstanding also allows an attacke= r to log into a victim user's account without password. Let's take Soluto's metro app as an example to describe the problem. The ap= p supports Facebook Login. As an attacker, we can write a regular Facebook = app. Once the victim user allows our app to access her Facebook data, we re= ceive an access_token from the traffic. Then, on our own machine (i.e., the= "attacker" machine), we run the metro app of Soluto, and use a HTTP proxy = to insert the victim's access_token into the traffic of Facebook login. Thr= ough this way, we are able to log into the victim's Soluto account from our= machine. Other than Soluto, we also have confirmed the same issue on anoth= er Windows 8 metro-app Givit. The Facebook SDK for Android apps (https://developers.facebook.com/docs/mob= ile/android/build/#sdk) seems to have the possibility to mislead developers= too. At least, the issue that we found is not clearly mentioned. In the SD= K, we ran the sample code called "Hackbook" using Android Emulator (imagine= it is an attacker device). Note that we have already received the access t= oken of the victim user from our regular Facebook app. We then inject the t= oken to the traffic of Hackbook. Through this way, Hackbook app on our own = machine recognizes us as the victim. Note that this is not a convincing sec= urity exploit yet, because this sample code does not include the server-sid= e code. However, given that we have seen real server-side code having this = problem, such as Soluto, Givit and others, we do believe that the sample co= de can mislead mobile/metro developers. We also suspect that this may be a = general issue of many OAuth implementations on mobile platforms, so we send= this message to OAuth Standard group as well. We have contacted the vendors of the two vulnerable metro-apps, Soluto and = Gavit. Please kindly give us an ack when you receive this message. If you want to = know more details, please let us know. Best Regards, Yuchen Zhou, Rui Wang, and Shuo Chen _______________________________________________ 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 -- 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 _______________________________________________ OAuth mailing 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_59E470B10C4630419ED717AC79FCF9A91A2CC980CH1PRD0410MB369_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Torsten,

 

Your option #2 below is the model I was firs= t attracted to.  The architecture as you mention is clean.  But t= he need to run multiple round trips (one to get the SAML assertion, another to get the access token), plus the inherently large size of a SAML= assertion (compared to an unstructured access token, or even a JWT), was p= roducing too much latency. 

 

Hence I have moved my interest to option #1.=   I think the easiest thing to do is have the user authenticate to the= local AS, get in return a structured JWT access token (which will look a lot like the Connect id_token) and present that JWT access tok= en to the RS in the different domain, and that RS will use that JWT access = token to authenticate the user.  Ideally I would like to use the id_to= ken from Connect, but I’m getting push back on that idea since the id_token has really been profiled for the clie= nt, not the RS.

 

-adam

 

From: Torsten Lodderstedt [mailto:torsten@lodderstedt.n= et]
Sent: Saturday, June 23, 2012 11:52 AM
To: Lewis Adam-CAL022
Cc: Nat Sakimura; oauth@ietf.org
Subject: Re: [OAUTH-WG] Report an authentication issue

 

Hi Adam,

let me explain why I don't see a need for a new profile.

As far as I understand your scenario, you want to give users from different= security domains access to the same RS.

I see two ways to handle this without any need to extend OAuth:

1) multiple AS (also performing authentication)

You already mentioned this option. Every department runs its AS, which auth= enticates and authorizes access to the RS for the particular officer. As a = pre-requisite, RS and ASs must use the same token design (self-contained vs= . handle-based), token format (e.g. SAML or JWT) and the RS must _rely_ multiple ASs. This will be possible to= implement with the drafts under consideration (namely JWT), but I consider= this a substantial restrictions on the design of the RS!

2) single AS relying on multiple IDPs for authenticaton

The alternative is to let a dedicated AS issue the tokens for the central R= S. This AS uses the IDPs of the different security domain for the purpose o= f authenticating the officers (e.g. using SAML or OpenID). The difference i= s that the RS only trusts this single AS, which is easier to implement because it is a nearly private relationsh= ip.

best regards,
Torsten.

Am 21.06.2012 18:01, schrieb Lewis Adam-CAL022:=

Hi Nat,

 

I’m beginning to wonder what it would = take to add a new profile of sorts to either OAuth or Connect. 

 

In the beginning there was SOAP, and the pre= ferred method to secure SOAP API calls was WS-Trust.

 

Now the world is moving toward RESTful APIs = … and the preferred means to secure RESTful APIs is OAuth.

 

Except that OAuth is clearly written with th= e idea that the protected resources belong to the end user.

 

My use cases – and I imagine the use c= ases of many other enterprises – is that the Owner of the resources i= s the Enterprise.  An employee is trying to access a database or video resources.  The enterprise RS needs to be able to 1) identify the use= r, and 2) make authorization decisions based on what roles that user has wi= thin the enterprise.  So in my scenario, when a police officer attempt= s to access a criminal records database, the database needs to know who that officer is, and then decide if they have p= rivilege to access the database, and at what level (e.g. CRUD). 

 

WS-Trust fits this model well.  The use= r performs primary authentication to the enterprise STS, which then grants = the application client a SAML assertion.  When the user attempts to access a records database, the SAML assertion is included in the SOAP m= essage.  The records server authenticates the user based on the SAML a= ssertion and makes its authorization decisions.

 

This is the world I’m trying to migrat= e from, and it really seems like I’m sometimes trying to make a squar= e peg fit in a round hole.  I’m looking for OAuth/Connect to do = for REST what WS-TRUST did for SOAP.  I would like a native client talkin= g to a RS to be able to ask for an id_token, and then pass that id_token to= the RS when making its RESTful API calls, to enable the RS to authenticate= the user.  I think that this would be really useful for a lot of people besides me.  I keep hearing that th= ere is nothing “preventing” me from doing this … but it h= ardly seems within the spirit of what OAuth was meant to do.  The id_t= oken was clearly meant to enable a user to authenticate to a confidential client  / web server … but was not meant for a nat= ive client to identity / authenticate the user to a RS. 

 

 

Would there be any interest in exploring thi= s further?

-adam

 

 

From: Nat Saki= mura [mailto:sakimura@gmail.com]
Sent: Wednesday, June 20, 2012 8:09 PM
To: Lewis Adam-CAL022
Cc: igor.faynber= g@alcatel-lucent.com; oauth@ietf.org
Subject: Re: [OAUTH-WG] Report an authentication issue

 

Yes, OAuth can be profiled to enable authentication.=  

In fact, initial draft of OpenID Connect was just li= ke you described. 

Essentially, we were using structured access_token.&= nbsp;

Later, we decided to separate the access token and i= d_token for several reasons such as: 

 

  1. Better interop with existing OAuth implementations: by introducing id_token= , they do not need to touch the supposedly opaque (which means AS-RS may be= doing some proprietary thing inside it) access token. 
  2. Mixing up the audience (for id_token aka authn =3D client, and for access_t= oken aka authz =3D resource server) probably is expanding the attack surfac= e for security and privacy. 

Although we separated them out, a signed id_token in= cludes the left hash of access_token so access_token is also protected.&nbs= p;

 

Best, 

 

Nat

 

On Thu, Jun 21, 2012 at 5:21 AM, Lewis Adam-CAL022 &= lt;Ad= am.Lewis@motorolasolutions.com> wrote:

Hi Igor,

 

As Justin just pointed out, consider the case where the vi= deo server is hosted by the state (e.g. California) and is accessed by police agencies in Los Angeles, San Francisco, and San Diego.&= nbsp; The State of California’s video server is the RS.  Each lo= cal police agency (LA/SF/SD) hosts an AS.  So when a police officer fr= om LAPD launches the video client app on the iPhone, the client makes an OAuth request to the LAPD’s AS, which authentica= tes the police officer using agency level credentials.  The access tok= en issued to the video client app on the iPhone is a JWT, signed by the age= ncy AS, which might look something like this:

 

{“typ”:”JWT”,"alg":"= ;ES256"}

{"iss":"https://as.lapd.california.gov",
  "prn":"alice@lapd.california.gov",
  "aud":" https://video_server1@state.california.gov&= quot;,
  "iat":1300815780,
  "exp":1300819380,
  "acr":”password”}

hq4zk+ZknjggCQgZm7ea8fI79gJEsRy3E8LHDpYXWQIgZpkJN9CMLG8ENR4Nrw&= #43;n7iyzixBvKXX8P53BTCT4VghPBWhFYSt9tHWu/AtJfOTh6qaAsNdeCyG86jmtp3TDMwuL/c= BUj2OtBZOQMFn7jQ9YB7klIz3RqVL+wNmeWI4=3D

 

The JWT might be optionally encrypted using JWE. 

 

I think what is becoming clear (and this is what I’m trying t= o vet) is that while there is nothing in OAuth that specifies authenticatio= n, it *can* be used for Authentication, if done in the way that I describe.  If I’m wrong about this, I really need to= know.  I’ve vetted this idea of mine with quite of few people n= ow – both within context of the list and off-line – and I think= I’m okay. If you see any holes in what I describe, please point them out as I would prefer to uncover them now rather than after implementation= or deployment!

 

Essentially I’m using OAuth as a RESTful version of WS-Trust,= where my client can exchange primary credentials for a token (JWT) and pre= sent that token to a server as secondary authentication.  It’s just that it’s RESTful instead of SOAP :-)

 

As Justin as pointed out … I’ve basically made the acce= ss-token look like the id_token of Connect.  I was actually hoping to = lay a path to Connect, and use the id_token … until it was also point= ed out that the id_token is really meant for the consumption of the client, n= ot the RS :-(

 

 

 

From: oauth-bounces@i= etf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Igor Faynberg
Sent: Wednesday, June 20, 2012 2:39 PM
To: oauth@ietf.o= rg


Subject: Re: [OAUTH-WG] Report an authentication issue

 

But this use case  does need OAuth, period:



The video server is under the control of a police agency, and polic= e officers must logon to the video server in order to access video content.=

There is no delegation here, and there is no need to use third party for au= thentication. 

Igor

On 6/20/2012 3:26 PM, Justin Richer wrote:

In case it wasn't clear, I want to restate the original problem as= best as I understand it in a way that hopefully clears it up:

App A and app B are both valid registered OAuth clients to an OAuth protect= ed service.

The problem starts when app A gets handed a token that was issued for app B= and uses it to call an identity API on the OAuth service. Since app B can = get tokens just fine, they're bearer tokens, this is a fairly basic api cal= l, this function works just fine and returns the user info. This makes sense, since anyone who holds A's to= kens can do whatever A can do on behalf of that user. The issues start when= app B then decides that since they can make a call to the identity API wit= h a token then the user *must* be present. In other words, app B is confusing authorization to call an API w= ith authentication of the session.

OpenID Connect fixes this missed assumption by binding the ID Token to the = session and sending it along side the access token, but as you pointed out,= it's meant for consumption at the client, not the resource server, in gene= ral. That doesn't mean you can't send it to a resource server for your own purposes, of course. That's actu= ally how the session management endpoint works in Connect.

This isn't the only way to handle this problem -- if you put some structure= in your tokens, such as with JWT or SAML, then app A can tell that this is= n't a token issued to app A, but to app B, so it can call shenanigans and r= eject it then and there.

 -- Justin

On 06/20/2012 10:03 AM, Lewis Adam-CAL022 wrote:

I am entirely confused.

 

I understand what everybody is saying for confidential cli= ents, no problem here.

 

I fall apart when thinking of iPhone apps.  Consider = the scenario where I deploy a video server, and write an iPhone app to talk to the video server.  The video server is under the contr= ol of a police agency, and police officers must logon to the video server i= n order to access video content.  So the police office launches their = iPhone video client app.

 

If I wanted to solve authenticati= on using “traditional” client-server authentication, the user e= nters their username / password into the client, and the client sends the username / password off to the server, which authenticates it, or poss= ibly uses HTTP digest. 


If I wanted to use OpenID, the cl= ient would attempt to reach the video server (RP), the server would redirec= t the client to the OP, OP authenticates user, and OP redirects client back to the server/RP with an assertion that primary authentication= was successful. 


If I wanted to use OAuth, the cli= ent would send an authorization request to the server’s AS, which wou= ld authenticate the user of the client, and ultimately result in the client possessing an access-token.  My thinking is that this a= ccess token (let’s assume it’s a JWT) would contain the user= 217;s identity, a statement of what type of primary authentication was used= (auth context), an expiration, and an audience claim.  This sounds a lot like authentication to me, and it’s where I get co= nfused.  Is it just because OAuth does not explicitly define this?&nbs= p; Is there a threat in using OAuth as I describe? 


If I wanted to use Connect, well I’m not even sure how the= id_token as defined by Connect helps this use case.  The id_token see= ms to make sense when the client is a confidential web server, but it’s not clear what an iPhone app would do with the id_token …= it’s the server in the backend that needs to authenticate the user, = the iPhone app is just an interface to talk to the server.  And it see= ms as I learn more about connect that the id_token is not meant to be sent from the iPhone app to the server, just the access token.=   So it’s really not clear how Connect helps solve authenticatio= n for an iPhone client app talking to a video server.  If I’m se= nding access-tokens, it’s just OAuth again.

 

What am I still missing?

adam

 

 

From: oauth-bounces@i= etf.org [ma= ilto:oauth-bounces@ietf.org] On Behalf Of Kristofor Selden
Sent: Saturday, June 16, 2012 11:33 AM
To: nov matake; oauth
Cc: Yuchen Zhou; Luke Melia; Shuo Chen (MSR)
Subject: Re: [OAUTH-WG] Report an authentication issue

 

Nov demonstrated the problem to us at Yapp and we used solution 4 = (because the solution is server side and our app was in the app store).

 

FB Connect is authentication and authorization, where OAuth 2 is concerned only with authorizatio= n – I'm not sure that app developers appreciate this subtlety.

 

With OAuth 2 you authorize an app to use a protected resource. &nb= sp;With FB Connect, you do that, but also authenticate with the app you are authorizing.

 

So the access_token protects not just the FB resources but the aut= h end point of the authorized app (very common with apps that use the iOS S= DK).  So now the app needs a way to verify that it was the app that was authorized to FB.

 

Solution 4 explanation: on FB you can register a iPhone app and a = server app with the same client_id and get a client_secret for use on the s= erver.  The server side API posts the access_token, client_id, and client_secret to h= ttps://graph.facebook.com/app to verify that the bearer token= actually belongs to the app that is being authenticated before assuming they are authorized to the app's protected resources.<= /p>

 

Kris

 

On Jun 15, 2012, at 8:22 PM, nov matake wrote:




There are 4 ways to fix this issue.

 

1. Use response_type=3Dtoken%20code (It's not in OAuth 2.0 Co= re, but seems best way for interoperability)

2. Use singed_request (or some signed token like JWT)

3. Use grant_type=3Dfb_exchange_token (Facebook custom way)

4. Access to https://graph.facebook.com/app?access_token=3DYOUR_TOKEN (Facebook cust= om way, moreover undocumented API)

 

Two iPhone app developers I reported this issue fixed it by using = (4).

 

I also tried to use (1) for my own iPhone app implementation, but = unfortunately it doesn't work when using authorization codes obtained via F= B iOS SDK.

So I'm using (3) in my case.

 

nov

 

On 2012/06/16, at 9:16, Nat Sakimura wrote:




As to how the fix was done, Nov can provide more detail, but ...&n= bsp;

 

1. Properly verify the signature/HMAC of the "signed_request&= quot;. This will essentially audience restricts the token. =

2. There is an undocumented API for Facebook which returns to whom= the token was issued. This also audience restricts the token. 

 

The service that fixed took these measures. Note that none of the = above is defined in OAuth. 

The same facility was called "id_token" and "check = ID endpoint" for OpenID Connect. 

 

The scale of the impact is large, too large to disclose the actual= names in the public list, though, eventually, we would publish them in a p= aper. 

 

Nat

On Sat, Jun 16, 2012 at 5:34 AM, Francisco Corella <fcorella@pomcor.com> wrote:<= br>

Hi Nat and Rui,

Rui, you say that the vulnerability that you found was due to a
"common misunderstanding among developers", but the attack you describe can be carried out against any app that uses the OAuth
"implicit grant flow", which Facebook calls "client-side
authentication".  No misunderstanding seems necessary.  What=
misunderstanding are you referring to?  I followed the link in your message to the Sophos post, and from there the link to the article in
The Register.  The article in The Register says that Facebook had
"fixed the vulnerability promptly".  How did they fix it?&nb= sp; The
instructions that Facebook provides for implementing "Client-side
authentication without the JS SDK" at
https://developers.facebook.com/docs/authentic= ation/client-side/#no-jssdk
still allows the attack.

Nat, I agree that the blog post by John Bradley that you link to
refers to the same vulnerability reported by Rui.  You say that some apps have issued a patch to fix it.  Could you explain what the fix was?

Francisco

 

From: Nat Sakimura <sakimura@gmail.com>
To: rui wang <ruiwangwarm@gmail.com>
Cc: matake nov <nov@matake.jp>; Yuchen Zhou <t-yuzhou@microsoft.com>; oauth <oauth@ietf.org>; Shuo Chen (MSR) <shuochen@microsoft.com>
Sent: Thursday, June 14, 2012 1:50 PM
Subject: Re: [OAUTH-WG] Report an authentication issue

 

This is a fairly well known (hopefully by now) issue. We, at the O= penID Foundation, call it "access_token phishing" attack these da= ys. See: http://www.thread-safe.com/2= 012/01/problem-with-oauth-for-authentication.html

 

Nov Matake has actually built the code on iPhone to verify the pro= blem, and has notified bunch of parties back in February including Facebook= and Apple. We have the code that actually runs on a phone, and we have successfully logged in to bunch of apps, incl= uding very well known ones. They were all informed of the issue. Some immed= iately issued a patch to fix it while others have not.  

 

The problem is that even if these apps gets fixed, the problem doe= s not go away. As long as the attacker has the vulnerable version of the ap= p, he still can impersonate the victim. To stop it, the server side has to completely disable the older version, w= hich means the service has to cut off many users pausing business problems.=  

 

Nat

On Fri, Jun 15, 2012 at 2:18 AM, rui wang <ruiwangwarm@gmail.com> wrote:=

Dear Facebook Security Team and OAuth Standard group,

We are a research team in Microsoft Research. In January, 2011, we= reported a vulnerability in Facebook Connect which allowed everyone to sig= n into Facebook-secured relying parties without password. It was promptly fixed after reporting. (http://nakedsecurity.sophos.com/2011/02/02/facebo= ok-flaw-websites-steal-personal-data/)

Recently, we found a common misunderstanding among developers of m= obile/metro apps when using OAuth (including Facebook’s OAuth) for au= thentication. The vulnerability resulted from this misunderstanding also allows an attacker to log into a victim user's = account without password.

Let's take Soluto's metro app as an example to describe the proble= m. The app supports Facebook Login. As an attacker, we can write a regular = Facebook app. Once the victim user allows our app to access her Facebook data, we receive an access_token from the t= raffic. Then, on our own machine (i.e., the "attacker" machine), = we run the metro app of Soluto, and use a HTTP proxy to insert the victim's= access_token into the traffic of Facebook login. Through this way, we are able to log into the victim's Soluto accou= nt from our machine. Other than Soluto, we also have confirmed the same iss= ue on another Windows 8 metro-app Givit.

The Facebook SDK for Android apps (https://devel= opers.facebook.com/docs/mobile/android/build/#sdk) seems to have the possibility to mislead developers too. At least, the iss= ue that we found is not clearly mentioned. In the SDK, we ran the sample co= de called "Hackbook" using Android Emulator (imagine it is an att= acker device). Note that we have already received the access token of the victim user from our regular Facebook app. We then= inject the token to the traffic of Hackbook. Through this way, Hackbook ap= p on our own machine recognizes us as the victim. Note that this is not a c= onvincing security exploit yet, because this sample code does not include the server-side code. However, g= iven that we have seen real server-side code having this problem, such as S= oluto, Givit and others, we do believe that the sample code can mislead mob= ile/metro developers. We also suspect that this may be a general issue of many OAuth implementations on mobile p= latforms, so we send this message to OAuth Standard group as well.

We have contacted the vendors of the two vulnerable metro-apps, So= luto and Gavit.

Please kindly give us an ack when you receive this message. If you= want to know more details, please let us know.

Best Regards,
Yuchen Zhou, Rui Wang, and Shuo Chen


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

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



 

--
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_59E470B10C4630419ED717AC79FCF9A91A2CC980CH1PRD0410MB369_-- From igor.faynberg@alcatel-lucent.com Mon Jun 25 11:34:45 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D543511E8104 for ; Mon, 25 Jun 2012 11:34:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.598 X-Spam-Level: X-Spam-Status: No, score=-8.598 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MCPhvBcao-Ws for ; Mon, 25 Jun 2012 11:34:43 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id A1ED811E8102 for ; Mon, 25 Jun 2012 11:34:42 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id q5PIYfgC016933 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 25 Jun 2012 13:34:42 -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 q5PIYfe1020585 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 25 Jun 2012 13:34:41 -0500 Received: from [135.222.232.88] (USMUYN0L055118.mh.lucent.com [135.222.232.88]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q5PIYfw2003919; Mon, 25 Jun 2012 13:34:41 -0500 (CDT) Message-ID: <4FE8AF41.4020205@alcatel-lucent.com> Date: Mon, 25 Jun 2012 14:34:41 -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: <1339792496.52712.YahooMailNeo@web125501.mail.ne1.yahoo.com> <59E470B10C4630419ED717AC79FCF9A9108898EE@BL2PRD0410MB363.namprd04.prod.outlook.com> <4FE223E4.6060307@mitre.org> <4FE226BC.6010403@alcatel-lucent.com> <59E470B10C4630419ED717AC79FCF9A910889AB5@BL2PRD0410MB363.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A917052BC8@SN2PRD0410MB370.namprd04.prod.outlook.com> <4FE37D38.1030407@gmail.com> <59E470B10C4630419ED717AC79FCF9A91A2C8949@CH1PRD0410MB369.namprd04.prod.outlook.com> In-Reply-To: <59E470B10C4630419ED717AC79FCF9A91A2C8949@CH1PRD0410MB369.namprd04.prod.outlook.com> Content-Type: multipart/alternative; boundary="------------080502030303090100090501" X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: Re: [OAUTH-WG] Report an authentication issue X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2012 18:34:45 -0000 This is a multi-part message in MIME format. --------------080502030303090100090501 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Well, actually Igor missed a larger context when he said that. But when this context was pointed out to him, he humbly stood corrected and expressed interest in addressing this matter in OAuth! Igor On 6/25/2012 12:54 PM, Lewis Adam-CAL022 wrote: > > Okay :-) > > I've gotten lot of feedback ... consider a few snippets below, all > part of this thread and in response to my question: > > *Igor said*: OAuth was not designed for this purpose; it was designed > for delegating access. In your use case, there is no delegation. The > only legitimate users are police officers and they "must logon to the > video server in order to access video content." And so the server > must authenticate them. There is no need for OAuth in this scenario. > > ... --------------080502030303090100090501 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Well, actually Igor missed a larger context when he said that. But when  this context was pointed out to him, he humbly stood corrected and expressed interest in addressing this matter in OAuth!

Igor

On 6/25/2012 12:54 PM, Lewis Adam-CAL022 wrote:

Okay :-)

 

I’ve gotten lot of feedback … consider a few snippets below, all part of this thread and in response to my question:

 

 

Igor said: OAuth was not designed for this purpose; it was designed for delegating access.  In your use case,  there is no delegation. The only legitimate users are police officers and they "must logon to the video server in order to access video content."  And so the server must authenticate them. There is no need for OAuth in this scenario.

 

...
--------------080502030303090100090501-- From torsten@lodderstedt.net Mon Jun 25 14:43:49 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CABEF11E808E for ; Mon, 25 Jun 2012 14:43:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.042 X-Spam-Level: X-Spam-Status: No, score=-2.042 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Js8gvsg9JSFr for ; Mon, 25 Jun 2012 14:43:48 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.39]) by ietfa.amsl.com (Postfix) with ESMTP id 3FABB11E808C for ; Mon, 25 Jun 2012 14:43:47 -0700 (PDT) Received: from [79.253.14.67] (helo=android-7b8e761b2a5c1607.fritz.box) by smtprelay01.ispgateway.de with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.68) (envelope-from ) id 1SjH4T-00022f-7K; Mon, 25 Jun 2012 23:43:45 +0200 References: User-Agent: K-9 Mail for Android In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Torsten Lodderstedt Date: Mon, 25 Jun 2012 23:43:41 +0200 To: Lewis Adam-CAL022 Message-ID: X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Report an authentication issue X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 21:43:49 -0000 Hi Adam, what you describe is essentially a combination of Lewis Adam-CAL022 schrieb: >Hi Torsten, > >Your option #2 below is the model I was first attracted to. The >architecture as you mention is clean. But the need to run multiple >round trips (one to get the SAML assertion, another to get the access >token), plus the inherently large size of a SAML assertion (compared to >an unstructured access token, or even a JWT), was producing too much >latency. Use OpenId Connect between IDPs and central AS. > >Hence I have moved my interest to option #1. I think the easiest thing >to do is have the user authenticate to the local AS, get in return a >structured JWT access token (which will look a lot like the Connect >id_token) and present that JWT access token to the RS in the different >domain, and that RS will use that JWT access token to authenticate the >user. Ideally I would like to use the id_token from Connect, but I'm >getting push back on that idea since the id_token has really been >profiled for the client, not the RS. You could even combine both ideas by using the central AS of option #2 as an intermediary. The local AS can issue a JWT token, which in turn is accepted by the central AS to authenticate the user. The JWT assertion profile can be used for that purpose. This is more or a less a I variant of my option #2. Instead of using SAML to transfer identity data from IDP to AS you use access tokens to do the same between your local AS (== IDP) and the central AS. regards, Torsten. > >-adam > >From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] >Sent: Saturday, June 23, 2012 11:52 AM >To: Lewis Adam-CAL022 >Cc: Nat Sakimura; oauth@ietf.org >Subject: Re: [OAUTH-WG] Report an authentication issue > >Hi Adam, > >let me explain why I don't see a need for a new profile. > >As far as I understand your scenario, you want to give users from >different security domains access to the same RS. > >I see two ways to handle this without any need to extend OAuth: > >1) multiple AS (also performing authentication) > >You already mentioned this option. Every department runs its AS, which >authenticates and authorizes access to the RS for the particular >officer. As a pre-requisite, RS and ASs must use the same token design >(self-contained vs. handle-based), token format (e.g. SAML or JWT) and >the RS must _rely_ multiple ASs. This will be possible to implement >with the drafts under consideration (namely JWT), but I consider this a >substantial restrictions on the design of the RS! > >2) single AS relying on multiple IDPs for authenticaton > >The alternative is to let a dedicated AS issue the tokens for the >central RS. This AS uses the IDPs of the different security domain for >the purpose of authenticating the officers (e.g. using SAML or OpenID). >The difference is that the RS only trusts this single AS, which is >easier to implement because it is a nearly private relationship. > >best regards, >Torsten. >Am 21.06.2012 18:01, schrieb Lewis Adam-CAL022: >Hi Nat, > >I'm beginning to wonder what it would take to add a new profile of >sorts to either OAuth or Connect. > >In the beginning there was SOAP, and the preferred method to secure >SOAP API calls was WS-Trust. > >Now the world is moving toward RESTful APIs ... and the preferred means >to secure RESTful APIs is OAuth. > >Except that OAuth is clearly written with the idea that the protected >resources belong to the end user. > >My use cases - and I imagine the use cases of many other enterprises - >is that the Owner of the resources is the Enterprise. An employee is >trying to access a database or video resources. The enterprise RS >needs to be able to 1) identify the user, and 2) make authorization >decisions based on what roles that user has within the enterprise. So >in my scenario, when a police officer attempts to access a criminal >records database, the database needs to know who that officer is, and >then decide if they have privilege to access the database, and at what >level (e.g. CRUD). > >WS-Trust fits this model well. The user performs primary >authentication to the enterprise STS, which then grants the application >client a SAML assertion. When the user attempts to access a records >database, the SAML assertion is included in the SOAP message. The >records server authenticates the user based on the SAML assertion and >makes its authorization decisions. > >This is the world I'm trying to migrate from, and it really seems like >I'm sometimes trying to make a square peg fit in a round hole. I'm >looking for OAuth/Connect to do for REST what WS-TRUST did for SOAP. I >would like a native client talking to a RS to be able to ask for an >id_token, and then pass that id_token to the RS when making its RESTful >API calls, to enable the RS to authenticate the user. I think that >this would be really useful for a lot of people besides me. I keep >hearing that there is nothing "preventing" me from doing this ... but >it hardly seems within the spirit of what OAuth was meant to do. The >id_token was clearly meant to enable a user to authenticate to a >confidential client / web server ... but was not meant for a native >client to identity / authenticate the user to a RS. > > >Would there be any interest in exploring this further? >-adam > > >From: Nat Sakimura [mailto:sakimura@gmail.com] >Sent: Wednesday, June 20, 2012 8:09 PM >To: Lewis Adam-CAL022 >Cc: >igor.faynberg@alcatel-lucent.com; >oauth@ietf.org >Subject: Re: [OAUTH-WG] Report an authentication issue > >Yes, OAuth can be profiled to enable authentication. >In fact, initial draft of OpenID Connect was just like you described. >Essentially, we were using structured access_token. >Later, we decided to separate the access token and id_token for several >reasons such as: > > >1. Better interop with existing OAuth implementations: by introducing >id_token, they do not need to touch the supposedly opaque (which means >AS-RS may be doing some proprietary thing inside it) access token. >2. Mixing up the audience (for id_token aka authn = client, and for >access_token aka authz = resource server) probably is expanding the >attack surface for security and privacy. >Although we separated them out, a signed id_token includes the left >hash of access_token so access_token is also protected. > >Best, > >Nat > >On Thu, Jun 21, 2012 at 5:21 AM, Lewis Adam-CAL022 >> >wrote: >Hi Igor, > >As Justin just pointed out, consider the case where the video server is >hosted by the state (e.g. California) and is accessed by police >agencies in Los Angeles, San Francisco, and San Diego. The State of >California's video server is the RS. Each local police agency >(LA/SF/SD) hosts an AS. So when a police officer from LAPD launches >the video client app on the iPhone, the client makes an OAuth request >to the LAPD's AS, which authenticates the police officer using agency >level credentials. The access token issued to the video client app on >the iPhone is a JWT, signed by the agency AS, which might look >something like this: > >{"typ":"JWT","alg":"ES256"} >{"iss":"https://as.lapd.california.gov", > "prn":"alice@lapd.california.gov", > "aud":" https://video_server1@state.california.gov", > "iat":1300815780, > "exp":1300819380, > "acr":"password"} >hq4zk+ZknjggCQgZm7ea8fI79gJEsRy3E8LHDpYXWQIgZpkJN9CMLG8ENR4Nrw+n7iyzixBvKXX8P53BTCT4VghPBWhFYSt9tHWu/AtJfOTh6qaAsNdeCyG86jmtp3TDMwuL/cBUj2OtBZOQMFn7jQ9YB7klIz3RqVL+wNmeWI4= > >The JWT might be optionally encrypted using JWE. > >I think what is becoming clear (and this is what I'm trying to vet) is >that while there is nothing in OAuth that specifies authentication, it >*can* be used for Authentication, if done in the way that I describe. >If I'm wrong about this, I really need to know. I've vetted this idea >of mine with quite of few people now - both within context of the list >and off-line - and I think I'm okay. If you see any holes in what I >describe, please point them out as I would prefer to uncover them now >rather than after implementation or deployment! > >Essentially I'm using OAuth as a RESTful version of WS-Trust, where my >client can exchange primary credentials for a token (JWT) and present >that token to a server as secondary authentication. It's just that >it's RESTful instead of SOAP :-) > >As Justin as pointed out ... I've basically made the access-token look >like the id_token of Connect. I was actually hoping to lay a path to >Connect, and use the id_token ... until it was also pointed out that >the id_token is really meant for the consumption of the client, not the >RS :-( > > > >From: oauth-bounces@ietf.org >[mailto:oauth-bounces@ietf.org] On >Behalf Of Igor Faynberg >Sent: Wednesday, June 20, 2012 2:39 PM >To: oauth@ietf.org > >Subject: Re: [OAUTH-WG] Report an authentication issue > >But this use case does need OAuth, period: > > >The video server is under the control of a police agency, and police >officers must logon to the video server in order to access video >content. > >There is no delegation here, and there is no need to use third party >for authentication. > >Igor > >On 6/20/2012 3:26 PM, Justin Richer wrote: >In case it wasn't clear, I want to restate the original problem as best >as I understand it in a way that hopefully clears it up: > >App A and app B are both valid registered OAuth clients to an OAuth >protected service. > >The problem starts when app A gets handed a token that was issued for >app B and uses it to call an identity API on the OAuth service. Since >app B can get tokens just fine, they're bearer tokens, this is a fairly >basic api call, this function works just fine and returns the user >info. This makes sense, since anyone who holds A's tokens can do >whatever A can do on behalf of that user. The issues start when app B >then decides that since they can make a call to the identity API with a >token then the user *must* be present. In other words, app B is >confusing authorization to call an API with authentication of the >session. > >OpenID Connect fixes this missed assumption by binding the ID Token to >the session and sending it along side the access token, but as you >pointed out, it's meant for consumption at the client, not the resource >server, in general. That doesn't mean you can't send it to a resource >server for your own purposes, of course. That's actually how the >session management endpoint works in Connect. > >This isn't the only way to handle this problem -- if you put some >structure in your tokens, such as with JWT or SAML, then app A can tell >that this isn't a token issued to app A, but to app B, so it can call >shenanigans and reject it then and there. > > -- Justin > >On 06/20/2012 10:03 AM, Lewis Adam-CAL022 wrote: >I am entirely confused. > >I understand what everybody is saying for confidential clients, no >problem here. > >I fall apart when thinking of iPhone apps. Consider the scenario where >I deploy a video server, and write an iPhone app to talk to the video >server. The video server is under the control of a police agency, and >police officers must logon to the video server in order to access video >content. So the police office launches their iPhone video client app. > > >If I wanted to solve authentication using "traditional" client-server >authentication, the user enters their username / password into the >client, and the client sends the username / password off to the server, >which authenticates it, or possibly uses HTTP digest. > > > >If I wanted to use OpenID, the client would attempt to reach the video >server (RP), the server would redirect the client to the OP, OP >authenticates user, and OP redirects client back to the server/RP with >an assertion that primary authentication was successful. > > > >If I wanted to use OAuth, the client would send an authorization >request to the server's AS, which would authenticate the user of the >client, and ultimately result in the client possessing an access-token. >My thinking is that this access token (let's assume it's a JWT) would >contain the user's identity, a statement of what type of primary >authentication was used (auth context), an expiration, and an audience >claim. This sounds a lot like authentication to me, and it's where I >get confused. Is it just because OAuth does not explicitly define >this? Is there a threat in using OAuth as I describe? > > > >If I wanted to use Connect, well I'm not even sure how the id_token as >defined by Connect helps this use case. The id_token seems to make >sense when the client is a confidential web server, but it's not clear >what an iPhone app would do with the id_token ... it's the server in >the backend that needs to authenticate the user, the iPhone app is just >an interface to talk to the server. And it seems as I learn more about >connect that the id_token is not meant to be sent from the iPhone app >to the server, just the access token. So it's really not clear how >Connect helps solve authentication for an iPhone client app talking to >a video server. If I'm sending access-tokens, it's just OAuth again. > >What am I still missing? >adam > > >From: oauth-bounces@ietf.org >[mailto:oauth-bounces@ietf.org] On Behalf Of Kristofor Selden >Sent: Saturday, June 16, 2012 11:33 AM >To: nov matake; oauth >Cc: Yuchen Zhou; Luke Melia; Shuo Chen (MSR) >Subject: Re: [OAUTH-WG] Report an authentication issue > >Nov demonstrated the problem to us at Yapp and we used solution 4 >(because the solution is server side and our app was in the app store). > >FB Connect is authentication and authorization, where OAuth 2 is >concerned only with authorization - I'm not sure that app developers >appreciate this subtlety. > >With OAuth 2 you authorize an app to use a protected resource. With FB >Connect, you do that, but also authenticate with the app you are >authorizing. > >So the access_token protects not just the FB resources but the auth end >point of the authorized app (very common with apps that use the iOS >SDK). So now the app needs a way to verify that it was the app that >was authorized to FB. > >Solution 4 explanation: on FB you can register a iPhone app and a >server app with the same client_id and get a client_secret for use on >the server. The server side API posts the access_token, client_id, and >client_secret to >https://graph.facebook.com/app >to verify that the bearer token actually belongs to the app that is >being authenticated before assuming they are authorized to the app's >protected resources. > >Kris > >On Jun 15, 2012, at 8:22 PM, nov matake wrote: > > > >There are 4 ways to fix this issue. > >1. Use response_type=token%20code (It's not in OAuth 2.0 Core, but >seems best way for interoperability) >2. Use singed_request (or some signed token like JWT) >3. Use grant_type=fb_exchange_token (Facebook custom way) >4. Access to https://graph.facebook.com/app?access_token=YOUR_TOKEN >(Facebook custom way, moreover undocumented API) > >Two iPhone app developers I reported this issue fixed it by using (4). > >I also tried to use (1) for my own iPhone app implementation, but >unfortunately it doesn't work when using authorization codes obtained >via FB iOS SDK. >So I'm using (3) in my case. > >nov > >On 2012/06/16, at 9:16, Nat Sakimura wrote: > > > >As to how the fix was done, Nov can provide more detail, but ... > >1. Properly verify the signature/HMAC of the "signed_request". This >will essentially audience restricts the token. >2. There is an undocumented API for Facebook which returns to whom the >token was issued. This also audience restricts the token. > >The service that fixed took these measures. Note that none of the above >is defined in OAuth. >The same facility was called "id_token" and "check ID endpoint" for >OpenID Connect. > >The scale of the impact is large, too large to disclose the actual >names in the public list, though, eventually, we would publish them in >a paper. > >Nat >On Sat, Jun 16, 2012 at 5:34 AM, Francisco Corella >> wrote: > > >Hi Nat and Rui, > >Rui, you say that the vulnerability that you found was due to a >"common misunderstanding among developers", but the attack you >describe can be carried out against any app that uses the OAuth >"implicit grant flow", which Facebook calls "client-side >authentication". No misunderstanding seems necessary. What >misunderstanding are you referring to? I followed the link in your >message to the Sophos post, and from there the link to the article in >The Register. The article in The Register says that Facebook had >"fixed the vulnerability promptly". How did they fix it? The >instructions that Facebook provides for implementing "Client-side >authentication without the JS SDK" at >https://developers.facebook.com/docs/authentication/client-side/#no-jssdk >still allows the attack. > >Nat, I agree that the blog post by John Bradley that you link to >refers to the same vulnerability reported by Rui. You say that some >apps have issued a patch to fix it. Could you explain what the fix >was? > >Francisco > >________________________________ >From: Nat Sakimura > >To: rui wang > >Cc: matake nov >; Yuchen Zhou >>; oauth >>; Shuo Chen (MSR) >> >Sent: Thursday, June 14, 2012 1:50 PM >Subject: Re: [OAUTH-WG] Report an authentication issue > >This is a fairly well known (hopefully by now) issue. We, at the OpenID >Foundation, call it "access_token phishing" attack these days. See: >http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.html > >Nov Matake has actually built the code on iPhone to verify the problem, >and has notified bunch of parties back in February including Facebook >and Apple. We have the code that actually runs on a phone, and we have >successfully logged in to bunch of apps, including very well known >ones. They were all informed of the issue. Some immediately issued a >patch to fix it while others have not. > >The problem is that even if these apps gets fixed, the problem does not >go away. As long as the attacker has the vulnerable version of the app, >he still can impersonate the victim. To stop it, the server side has to >completely disable the older version, which means the service has to >cut off many users pausing business problems. > >Nat >On Fri, Jun 15, 2012 at 2:18 AM, rui wang >> wrote: >Dear Facebook Security Team and OAuth Standard group, >We are a research team in Microsoft Research. In January, 2011, we >reported a vulnerability in Facebook Connect which allowed everyone to >sign into Facebook-secured relying parties without password. It was >promptly fixed after reporting. >(http://nakedsecurity.sophos.com/2011/02/02/facebook-flaw-websites-steal-personal-data/) >Recently, we found a common misunderstanding among developers of >mobile/metro apps when using OAuth (including Facebook's OAuth) for >authentication. The vulnerability resulted from this misunderstanding >also allows an attacker to log into a victim user's account without >password. >Let's take Soluto's metro app as an example to describe the problem. >The app supports Facebook Login. As an attacker, we can write a regular >Facebook app. Once the victim user allows our app to access her >Facebook data, we receive an access_token from the traffic. Then, on >our own machine (i.e., the "attacker" machine), we run the metro app of >Soluto, and use a HTTP proxy to insert the victim's access_token into >the traffic of Facebook login. Through this way, we are able to log >into the victim's Soluto account from our machine. Other than Soluto, >we also have confirmed the same issue on another Windows 8 metro-app >Givit. >The Facebook SDK for Android apps >(https://developers.facebook.com/docs/mobile/android/build/#sdk) seems >to have the possibility to mislead developers too. At least, the issue >that we found is not clearly mentioned. In the SDK, we ran the sample >code called "Hackbook" using Android Emulator (imagine it is an >attacker device). Note that we have already received the access token >of the victim user from our regular Facebook app. We then inject the >token to the traffic of Hackbook. Through this way, Hackbook app on our >own machine recognizes us as the victim. Note that this is not a >convincing security exploit yet, because this sample code does not >include the server-side code. However, given that we have seen real >server-side code having this problem, such as Soluto, Givit and others, >we do believe that the sample code can mislead mobile/metro developers. >We also suspect that this may be a general issue of many OAuth >implementations on mobile platforms, so we send this message to OAuth >Standard group as well. >We have contacted the vendors of the two vulnerable metro-apps, Soluto >and Gavit. >Please kindly give us an ack when you receive this message. If you want >to know more details, please let us know. >Best Regards, >Yuchen Zhou, Rui Wang, and Shuo Chen > >_______________________________________________ >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 > > > > > >-- >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 > > > > > > >_______________________________________________ > >OAuth mailing 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 From internet-drafts@ietf.org Mon Jun 25 20:43:11 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77A0521F8589; Mon, 25 Jun 2012 20:43:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.488 X-Spam-Level: X-Spam-Status: No, score=-102.488 tagged_above=-999 required=5 tests=[AWL=0.111, 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 lZb0ukzJ9SwK; Mon, 25 Jun 2012 20:43:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A46521F856F; Mon, 25 Jun 2012 20:43:11 -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.21 Message-ID: <20120626034311.27720.72160.idtracker@ietfa.amsl.com> Date: Mon, 25 Jun 2012 20:43:11 -0700 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-urn-sub-ns-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: Tue, 26 Jun 2012 03:43:11 -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 : An IETF URN Sub-Namespace for OAuth Author(s) : Brian Campbell Hannes Tschofenig Filename : draft-ietf-oauth-urn-sub-ns-05.txt Pages : 7 Date : 2012-06-25 Abstract: This document establishes an IETF URN Sub-namespace for use with OAuth related specifications. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-urn-sub-ns There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-urn-sub-ns-05 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-urn-sub-ns-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From bcampbell@pingidentity.com Mon Jun 25 20:46:48 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCC4311E8079 for ; Mon, 25 Jun 2012 20:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.99 X-Spam-Level: X-Spam-Status: No, score=-5.99 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4AwohyvySahS for ; Mon, 25 Jun 2012 20:46:48 -0700 (PDT) Received: from na3sys009aog108.obsmtp.com (na3sys009aog108.obsmtp.com [74.125.149.199]) by ietfa.amsl.com (Postfix) with ESMTP id 2125121F855F for ; Mon, 25 Jun 2012 20:46:48 -0700 (PDT) Received: from mail-ob0-f169.google.com ([209.85.214.169]) (using TLSv1) by na3sys009aob108.postini.com ([74.125.148.12]) with SMTP ID DSNKT+kwp0vfl6sXv83w7jwh12PDYwTQ4iZd@postini.com; Mon, 25 Jun 2012 20:46:48 PDT Received: by obhx4 with SMTP id x4so9596954obh.14 for ; Mon, 25 Jun 2012 20:46:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding:x-gm-message-state; bh=Y0IQN9rEWdkRW7XQs9jt7JlZMJ3mslo6Hx5bztycLR8=; b=auNCLGGizpg7m6X/RHm4Q9obbGFcum+dF650xHFtQ4f3c739Dw3oj5YXHoJ0ir71qb 1OVQpqbJA2MyT6k/sUzx/LnAIHwwUkb9vP3pxP7oa35qn3dSci7UhTcE1H/JofWGEuvf qtiGfIZhuyUknQnVBRYmwwVA4j08X7rk15zywmlwF7YmT7DDHbmU+PzE5A2r8p9qZAF0 S03YwokVKFbM//rApkpdnoeD7Hn4iLXc9AuEXWvpCu8sGYetG0ruS1TPAfpgZF2pe/JG MpXRTfxSk+ULTJwhBVYhpFnV3cv4UEPKLP5bMNKTYxbGBajivImiAropGhtAf7NUSRNc SanQ== Received: by 10.182.216.68 with SMTP id oo4mr14513934obc.55.1340682407038; Mon, 25 Jun 2012 20:46:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.174.98 with HTTP; Mon, 25 Jun 2012 20:46:16 -0700 (PDT) In-Reply-To: <20120626034311.27720.72160.idtracker@ietfa.amsl.com> References: <20120626034311.27720.72160.idtracker@ietfa.amsl.com> From: Brian Campbell Date: Mon, 25 Jun 2012 21:46:16 -0600 Message-ID: To: oauth Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlzD/YiT/2veOtbV/wwpF5a1s5ylrlKAdOQHn+C+ISahLGYzVyJQ+RPKvVVjXfM43ww54an Subject: [OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-urn-sub-ns-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: Tue, 26 Jun 2012 03:46:48 -0000 -05 changes the registration procedure for urn:ietf:params:oauth:* URNs from Expert Review to Specification Required. ---------- Forwarded message ---------- From: Date: Mon, Jun 25, 2012 at 9:43 PM Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-urn-sub-ns-05.txt To: i-d-announce@ietf.org Cc: oauth@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts director= ies. =A0This draft is a work item of the Web Authorization Protocol Working Group of the IETF. =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : An IETF URN Sub-Namespace for OA= uth =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Brian Campbell =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Hannes Tschofenig =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-oauth-urn-sub-ns-05.txt =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 7 =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-06-25 Abstract: =A0 This document establishes an IETF URN Sub-namespace for use with =A0 OAuth related specifications. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-urn-sub-ns There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-urn-sub-ns-05 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-urn-sub-ns-05 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 Michael.Jones@microsoft.com Mon Jun 25 22:09:28 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FF8321F851B for ; Mon, 25 Jun 2012 22:09:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.185 X-Spam-Level: X-Spam-Status: No, score=-4.185 tagged_above=-999 required=5 tests=[AWL=-0.587, 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 EG8O1OOF18NM for ; Mon, 25 Jun 2012 22:09:27 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe001.messaging.microsoft.com [216.32.181.181]) by ietfa.amsl.com (Postfix) with ESMTP id 238A121F847F for ; Mon, 25 Jun 2012 22:09:27 -0700 (PDT) Received: from mail58-ch1-R.bigfish.com (10.43.68.241) by CH1EHSOBE011.bigfish.com (10.43.70.61) with Microsoft SMTP Server id 14.1.225.23; Tue, 26 Jun 2012 05:07:47 +0000 Received: from mail58-ch1 (localhost [127.0.0.1]) by mail58-ch1-R.bigfish.com (Postfix) with ESMTP id DBAA8400209; Tue, 26 Jun 2012 05:07:46 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -37 X-BigFish: VS-37(zf7Izbb2dI9371I8f9R936eI103dKc85dhzz1202hzz1033IL8275dhz2fh2a8h668h839hd25hf0ah) Received-SPF: pass (mail58-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC107.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail58-ch1 (localhost.localdomain [127.0.0.1]) by mail58-ch1 (MessageSwitch) id 1340687265688_1734; Tue, 26 Jun 2012 05:07:44 +0000 (UTC) Received: from CH1EHSMHS014.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.237]) by mail58-ch1.bigfish.com (Postfix) with ESMTP id E8294E0047; Tue, 26 Jun 2012 05:07:44 +0000 (UTC) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS014.bigfish.com (10.43.70.14) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 26 Jun 2012 05:07:44 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.53]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.02.0309.003; Tue, 26 Jun 2012 05:09:23 +0000 From: Mike Jones To: Brian Campbell , oauth Thread-Topic: [OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-urn-sub-ns-05.txt Thread-Index: AQHNU05U4fT+H4T1K0SdMhwMcKrqJZcMDRca Date: Tue, 26 Jun 2012 05:09:23 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943665689F2@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <20120626034311.27720.72160.idtracker@ietfa.amsl.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943665689F2TK5EX14MBXC283r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-urn-sub-ns-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: Tue, 26 Jun 2012 05:09:28 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943665689F2TK5EX14MBXC283r_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks! ________________________________ From: Brian Campbell Sent: 6/25/2012 8:46 PM To: oauth Subject: [OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-urn-sub-ns-05.txt -05 changes the registration procedure for urn:ietf:params:oauth:* URNs from Expert Review to Specification Required. ---------- Forwarded message ---------- From: Date: Mon, Jun 25, 2012 at 9:43 PM Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-urn-sub-ns-05.txt To: i-d-announce@ietf.org Cc: oauth@ietf.org 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 : An IETF URN Sub-Namespace for OAuth Author(s) : Brian Campbell Hannes Tschofenig Filename : draft-ietf-oauth-urn-sub-ns-05.txt Pages : 7 Date : 2012-06-25 Abstract: This document establishes an IETF URN Sub-namespace for use with OAuth related specifications. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-urn-sub-ns There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-urn-sub-ns-05 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-urn-sub-ns-05 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 --_000_4E1F6AAD24975D4BA5B1680429673943665689F2TK5EX14MBXC283r_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Thanks!

From: Brian = Campbell
Sent: 6/25/2= 012 8:46 PM
To: oauth<= /span>
Subject: [OAUTH= -WG] Fwd:  I-D Action: draft-ietf-oauth-urn-sub-ns-05.txt

-05 changes the registration procedure for urn:iet= f:params:oauth:*
URNs from Expert Review to Specification Required.


---------- Forwarded message ----------
From:  <internet-drafts@ietf.org>
Date: Mon, Jun 25, 2012 at 9:43 PM
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-urn-sub-ns-05.txt
To: i-d-announce@ietf.org
Cc: oauth@ietf.org



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           : An IE= TF URN Sub-Namespace for OAuth
       Author(s)       : Brian Campbell<= br>                      = ;    Hannes Tschofenig
       Filename        : draft-ietf= -oauth-urn-sub-ns-05.txt
       Pages           : 7
       Date            : = 2012-06-25

Abstract:
  This document establishes an IETF URN Sub-namespace for use with
  OAuth related specifications.


The IETF datatracker status page for this draft is:
ht= tps://datatracker.ietf.org/doc/draft-ietf-oauth-urn-sub-ns

There's also a htmlized version available at:
http:= //tools.ietf.org/html/draft-ietf-oauth-urn-sub-ns-05

A diff from previous version is available at:
http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-urn-sub-ns-05


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

_______________________________________________
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_4E1F6AAD24975D4BA5B1680429673943665689F2TK5EX14MBXC283r_-- From eran@hueniverse.com Tue Jun 26 04:35:30 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8961921F8610 for ; Tue, 26 Jun 2012 04:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.020, 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 Z-81+CuOn5yJ for ; Tue, 26 Jun 2012 04:35:29 -0700 (PDT) Received: from p3plex2out04.prod.phx3.secureserver.net (p3plex2out04.prod.phx3.secureserver.net [184.168.131.18]) by ietfa.amsl.com (Postfix) with ESMTP id 755B021F8625 for ; Tue, 26 Jun 2012 04:35:29 -0700 (PDT) Received: from P3PWEX2HT002.ex2.secureserver.net ([184.168.131.10]) by p3plex2out04.prod.phx3.secureserver.net with bizsmtp id SzbU1j0030Dcg9U01zbU9w; Tue, 26 Jun 2012 04:35:28 -0700 Received: from P3PWEX2MB008.ex2.secureserver.net ([169.254.8.66]) by P3PWEX2HT002.ex2.secureserver.net ([184.168.131.10]) with mapi id 14.02.0247.003; Tue, 26 Jun 2012 04:35:28 -0700 From: Eran Hammer To: "oauth@ietf.org WG (oauth@ietf.org)" Thread-Topic: [comment] The OAuth 2.0 Authorization Framework draft-ietf-oauth-v2-28 Thread-Index: AQHNT0ZgDkNvJuccbUCBFb4sA3UmT5cMgOdg Date: Tue, 26 Jun 2012 11:35:27 +0000 Message-ID: <0CBAEB56DDB3A140BA8E8C124C04ECA2010815F5@P3PWEX2MB008.ex2.secureserver.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [37.46.40.97] Content-Type: multipart/alternative; boundary="_000_0CBAEB56DDB3A140BA8E8C124C04ECA2010815F5P3PWEX2MB008ex2_" MIME-Version: 1.0 Cc: "shiufunpoon@gmail.com" Subject: [OAUTH-WG] FW: [comment] The OAuth 2.0 Authorization Framework draft-ietf-oauth-v2-28 X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 11:35:30 -0000 --_000_0CBAEB56DDB3A140BA8E8C124C04ECA2010815F5P3PWEX2MB008ex2_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sending to the right place. From: Shiu Fun Poon [mailto:shiufunpoon@gmail.com] Sent: Wednesday, June 20, 2012 5:40 PM To: draft-ietf-oauth-v2@tools.ietf.org Subject: [comment] The OAuth 2.0 Authorization Framework draft-ietf-oauth-v= 2-28 I am not sure whether you are accepting comments for the draft or not. Her= e are two for your consideration. 1. 2.3.1, it started with "Client Password", and it switches gear to "clie= nt_secret" in the "alternative" section. In the description for client_sec= ret, the wording should be changed to "REQUIRED. The client secret. This = is the client password and client MAY omit the parameter if the client pass= word is an empty string" 2. 3.1.2.2 (actually the 3.1.2 section). It may worth to call out that th= is only applies to the authorization code grant or implicit grant, when red= irect_uri is used. Since the SHOULD part in 3.1.2.2 does not make sense fo= r client credential, nor resource owner password grant . Regards. Shiufun --_000_0CBAEB56DDB3A140BA8E8C124C04ECA2010815F5P3PWEX2MB008ex2_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sending to the right plac= e.

 <= /p>

From: Shiu Fun= Poon [mailto:shiufunpoon@gmail.com]
Sent: Wednesday, June 20, 2012 5:40 PM
To: draft-ietf-oauth-v2@tools.ietf.org
Subject: [comment] The OAuth 2.0 Authorization Framework draft-ietf-= oauth-v2-28

 

I am not sure whether you are accepting comments for= the draft or not.  Here are two for your consideration.

1.  2.3.1, it started with "Client Password", and it switche= s gear to "client_secret" in the "alternative" section.=   In the description for client_secret, the wording should be changed = to "REQUIRED.  The client secret.  This is the client passwo= rd and client MAY omit the parameter if the client password is an empty string"

2.  3.1.2.2 (actually the 3.1.2 section).  It may worth to call o= ut that this only applies to the authorization code grant or implicit grant= , when redirect_uri is used.  Since the SHOULD part in 3.1.2.2 does no= t make sense for client credential, nor resource owner password grant .

Regards.
Shiufun

--_000_0CBAEB56DDB3A140BA8E8C124C04ECA2010815F5P3PWEX2MB008ex2_-- From eran@hueniverse.com Tue Jun 26 04:38:10 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9E7D21F8589 for ; Tue, 26 Jun 2012 04:38:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.019, 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 KPwHBfAGARTr for ; Tue, 26 Jun 2012 04:38:10 -0700 (PDT) Received: from p3plex2out02.prod.phx3.secureserver.net (p3plex2out02.prod.phx3.secureserver.net [184.168.131.14]) by ietfa.amsl.com (Postfix) with ESMTP id 2A21621F855A for ; Tue, 26 Jun 2012 04:38:10 -0700 (PDT) Received: from P3PWEX2HT002.ex2.secureserver.net ([184.168.131.10]) by p3plex2out02.prod.phx3.secureserver.net with bizsmtp id Sze91j0020Dcg9U01ze97e; Tue, 26 Jun 2012 04:38:09 -0700 Received: from P3PWEX2MB008.ex2.secureserver.net ([169.254.8.66]) by P3PWEX2HT002.ex2.secureserver.net ([184.168.131.10]) with mapi id 14.02.0247.003; Tue, 26 Jun 2012 04:38:09 -0700 From: Eran Hammer To: "oauth@ietf.org WG (oauth@ietf.org)" Thread-Topic: typo in OAuth 2.0 spec draft v25 Thread-Index: Ac0ddSUhU9qODrmJTMaXQRxtcSPjQg2Gu3+g Date: Tue, 26 Jun 2012 11:38:09 +0000 Message-ID: <0CBAEB56DDB3A140BA8E8C124C04ECA201081667@P3PWEX2MB008.ex2.secureserver.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [37.46.40.97] Content-Type: multipart/alternative; boundary="_000_0CBAEB56DDB3A140BA8E8C124C04ECA201081667P3PWEX2MB008ex2_" MIME-Version: 1.0 Cc: "artem.oboturov@orange.com" Subject: [OAUTH-WG] FW: typo in OAuth 2.0 spec draft v25 X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 11:38:10 -0000 --_000_0CBAEB56DDB3A140BA8E8C124C04ECA201081667P3PWEX2MB008ex2_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: artem.oboturov@orange.com [mailto:artem.oboturov@orange.com] Sent: Wednesday, April 18, 2012 8:09 AM To: Eran Hammer Subject: typo in OAuth 2.0 spec draft v25 Dear Eran. In draft v25 of The OAuth 2.0 spec on Figure 4 : Implicit Grant Flow, step = G is not documented among steps. This is a minor remark. Best regards, Artem Oboturov --_000_0CBAEB56DDB3A140BA8E8C124C04ECA201081667P3PWEX2MB008ex2_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

From: artem.ob= oturov@orange.com [mailto:artem.oboturov@orange.com]
Sent: Wednesday, April 18, 2012 8:09 AM
To: Eran Hammer
Subject: typo in OAuth 2.0 spec draft v25

 

Dear Eran.

 

In draft v25 of The OAuth 2.0 spec on Figure 4 = : Implicit Grant Flow, step G is not documented among steps. This is a mino= r remark.

 

Best regards,

Artem Oboturov

--_000_0CBAEB56DDB3A140BA8E8C124C04ECA201081667P3PWEX2MB008ex2_-- From stpeter@stpeter.im Tue Jun 26 07:41:16 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76ED821F8564 for ; Tue, 26 Jun 2012 07:41:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.477 X-Spam-Level: X-Spam-Status: No, score=-102.477 tagged_above=-999 required=5 tests=[AWL=0.122, 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 iz0Xy12GuGJ0 for ; Tue, 26 Jun 2012 07:41:16 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 10F6221F855F for ; Tue, 26 Jun 2012 07:41:16 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id F3ADA4005A; Tue, 26 Jun 2012 08:59:08 -0600 (MDT) Message-ID: <4FE9CA0A.7080205@stpeter.im> Date: Tue, 26 Jun 2012 08:41:14 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120601 Thunderbird/13.0 MIME-Version: 1.0 To: Brian Campbell References: <20120626034311.27720.72160.idtracker@ietfa.amsl.com> In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: oauth Subject: Re: [OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-urn-sub-ns-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: Tue, 26 Jun 2012 14:41:16 -0000 On 6/25/12 9:46 PM, Brian Campbell wrote: > -05 changes the registration procedure for urn:ietf:params:oauth:* > URNs from Expert Review to Specification Required. I've reviewed this version and it seems fine. /psa From iesg-secretary@ietf.org Wed Jun 27 06:47:46 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45C4A21F86E8; Wed, 27 Jun 2012 06:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.525 X-Spam-Level: X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.074, 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 SwT1a1HbP1pM; Wed, 27 Jun 2012 06:47:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B0CE21F86BD; Wed, 27 Jun 2012 06:47:45 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.21 Message-ID: <20120627134745.6549.44652.idtracker@ietfa.amsl.com> Date: Wed, 27 Jun 2012 06:47:45 -0700 Cc: oauth@ietf.org Subject: [OAUTH-WG] Last Call: (An IETF URN Sub-Namespace for OAuth) to Informational RFC X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 13:47:46 -0000 The IESG has received a request from the Web Authorization Protocol WG (oauth) to consider the following document: - 'An IETF URN Sub-Namespace for OAuth' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-07-11. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document establishes an IETF URN Sub-namespace for use with OAuth related specifications. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-oauth-urn-sub-ns/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-oauth-urn-sub-ns/ballot/ No IPR declarations have been submitted directly on this I-D. From internet-drafts@ietf.org Wed Jun 27 10:58:35 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8383A21F86A7; Wed, 27 Jun 2012 10:58:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 s4bthS9xnsJC; Wed, 27 Jun 2012 10:58:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D97E21F8652; Wed, 27 Jun 2012 10:58:35 -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.21 Message-ID: <20120627175835.26644.13000.idtracker@ietfa.amsl.com> Date: Wed, 27 Jun 2012 10:58:35 -0700 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-threatmodel-06.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 17:58:35 -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 Threat Model and Security Considerations Author(s) : Torsten Lodderstedt Mark McGloin Phil Hunt Filename : draft-ietf-oauth-v2-threatmodel-06.txt Pages : 68 Date : 2012-06-27 Abstract: This document gives additional security considerations for OAuth, beyond those in the OAuth specification, based on a comprehensive threat model for the OAuth 2.0 Protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-threatmodel There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-06 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-v2-threatmodel-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From torsten@lodderstedt.net Wed Jun 27 11:04:15 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02ACC11E8073 for ; Wed, 27 Jun 2012 11:04:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.493 X-Spam-Level: X-Spam-Status: No, score=-1.493 tagged_above=-999 required=5 tests=[AWL=-0.445, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, J_CHICKENPOX_52=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 YBnpquMtK7L9 for ; Wed, 27 Jun 2012 11:04:02 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.18.14]) by ietfa.amsl.com (Postfix) with ESMTP id 8F1DB11E8072 for ; Wed, 27 Jun 2012 11:04:01 -0700 (PDT) Received: from [79.253.58.22] (helo=[192.168.71.36]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1Sjwas-0005Mu-1s; Wed, 27 Jun 2012 20:03:58 +0200 Message-ID: <4FEB4B0C.2030700@lodderstedt.net> Date: Wed, 27 Jun 2012 20:03:56 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Stephen Farrell References: <4FC3C53E.8020704@cs.tcd.ie> In-Reply-To: <4FC3C53E.8020704@cs.tcd.ie> Content-Type: multipart/alternative; boundary="------------080906020204060909020802" X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Cc: Barry Leiba , Derek Atkins , "oauth@ietf.org" Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-threatmodel-05 X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 18:04:15 -0000 This is a multi-part message in MIME format. --------------080906020204060909020802 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Stephen, I just submitted a new revision of the security document incorporating your review comments. Please find answers to your comments below. Thank you again for your detailed review. You helped us to significantly improve the document's quality. best regards, Torsten. Am 28.05.2012 20:34, schrieb Stephen Farrell: > Hi all, > > I've gotten the publication request for oauth-threatmodel > so here's my AD review of -05. > > Its quite a read (and a good one) but I've a bunch of > questions. Some of these will need fixing I suspect > but a lot are ok to fix later after IETF LC, depending > on whether the authors want to re-spin it before then > or not. But I'd like to at least see reactions to the > questions before I start IETF LC. > > Although there are many many nits and typos, those > don't actually make the document unreadable so > though I'd prefer to see 'em fixed now, I'm ok with > that happening later if its a problem to get it > all done now. > > If you want to argue for going ahead with IETF LC > now please do so, but I suspect that this might need > a revised ID to fix at least a couple of the points > raised below. If nobody does argue to go ahead now, > I'll mark it as revised ID needed, but first let's > see what the answers are to the questions. > > Cheers, > S. > > > (1) s/RFC1750/RFC4086/ is needed as noted in the write-up. done > (2) You don't say anything about the probability of > occurrence of the various threats. I realise that you > can't be precise but it seems wrong to say nothing. Would > it be worth at least saying that that's not done here and > that readers of this document need to do their own risk > analysis including that aspect? That's correct - I added the following paragraph to the introduction: "Note: This document cannot assess the probability nor the risk associated with a particular threat because those aspects strongly depend on the particular application and deployment OAuth is used to protect. Similar, impacts are given on a rather abstract level. But the information given here may serve as a foundation for deployment-specific threat models. Implementors may refine and detail the abstract threat model in order to account for the specific properties of their deployment and to come up with a risk analysis." > (3) Many deployments will use TLS accelerators. That > means that TLS isn't fully e2e, and that opens up some > (mainly) insider attacks or attacks that can be launched > from within a compromised DMZ, but from outside the server > applications. Does that need a mention somewhere? (I've > seen systems like that deployed and a lot could go wrong > from the inside, so I think this is a real threat.) I added another paragraph to section 5.1.1: "Note: this document assumes end-to-end TLS protected connections between the respective protocol entities. Deployments deviating from this assumption by offloading TLS in between (e.g. on the data center edge) must refine this threat model in order to account for the additional (mainly insider) threat this may cause." > (4) Could you use just one of "client identity" or "client > identifier" consistently? I'd much prefer the latter, > which has also been the outcome of various discussions on > this topic elsewhere. For example you say "revocation of > such an identity" at the end of p13, and that's a > potential rathole, better to say "revocation of the rights > associated with a client identifier" or similar I think. > And similar changes throughout. Replaced client identity by client identifier in most places and incorporated your proposed text > (5) 4.4.2.2: Here you recommend native applications should > use an embedded browser, but earlier you said that was a > bad idea. I think you need to be consistent or else > provide more about when its ok to embed and when its not. > Did I misread it or does that need a change? removed 3rd bullet as native apps should use code flow We also removed the 1st bullet in 4.4.1.9 > (6) 4.4.3.1: This calls for "obfuscation" of passwords in > logs. I think you ought be stronger there and call for > strong encryption of passwords wherever they are stored, > be that logs or DBs or whatever. Would'nt that be reasonable? This section is about preventing accidential exposure by the client. I think encryption is not appropriate here since the password is entered in the clear by the user. I added the advice to encrypt credentials as alternative means to salted hashes to 5.1.4.1.3. > (7) 4.6.4: 1st countermeasure: I don't think you mean > address here (in the sense of an IP address, which is what > that means) but rather the domain name or FQDN or URL. In > any case, you need to say what is meant clearly. (Also in > 5.1.5.6 and elsewhere when you use the term "address".) replaced address in most cases by URL and in some place by FDQN > (8) 4.6.6: You say to use Cache-Control, but don't say > how. Is more needed really? Maybe there's a good document > you could reference for that? (I'm not suggesting you add > a lecture on caching btw:-) Added text from core spec describing usage of Cache-Control and Pragma response header fields > (9) 5.1.1: needs a reference to RFC 5246 (and better to > just say TLS and not say SSL, at least for me :-) done > (10) 5.1.1: needs a reference to whatever you mean by > "VPN" since there are many types of VPN. I assume you mean > an IPsec VPN? But even if not, saying more would be good. Extended description and added reference to RFC 4301. > (11) 5.1.2: needs a reference to RFC 5280 and/or RFC 6125 > and/or RFC 2818. Bascially, you need to say how this is > done (by reference). Added reference to RFC 2818 since it seems to be closest to the problem > (12) 5.1.4.1: Isn't there some good reference you can give > here? (Having said that, I'd have to go look myself, but > I'd maybe start with owasp or sans.) added reference to OWASP > (13) 5.1.4.2.2: if p(collision) should be <=2^(-160) then > what's the point of saying it ought be <= 2^(-128)? Also > if sha-1 were perfect, then the 160 bits output would > really have a collision probability of about 2^(-80) with > many many tokens, but not 2^(-160). I think you need > to fix something there. Perhaps you're really saying that > all high-entropy secrets should be >=128 bits long and > constructed with a good (P)RNG? If so, saying so more > clearly would be better. Not everyone will get the > collision probability way of saying that even when its > properly stated. (This text is also repeated, be better if > you just said this once I think.) modified text as follows "When creating secrets not intended for usage by human users (e.g. client secrets or token handles), the authorization server should include a reasonable level of entropy in order to mitigate the risk of guessing attacks. The token value should be >=128 bits long and constructed from a cryptographically strong random or pseudo-random number sequence (see [RFC4086] for best current practice) generated by the Authorization Server." removed 5.1.5.11. (redundant text) and updated references accordingly > (14) 5.1.5.2: what is a "reasonable duration" - I don't > think its ok to say that but nothing else. Can't you give > some "reasonable" examples based on current usage? added examples and explanation of factors determining reasonable expiration time "Tokens should generally expire after a reasonable duration. This complements and strengthens other security measures (such as signatures) and reduces the impact of all kinds of token leaks. Depending on the risk associated with a token leakage, tokens may expire after a few minutes (e.g. for payment transactions) or stay valid for hours (e.g. read access to contacts). The expiration time is determined by a couple of factors, including: - risk associated to a token leakage - duration of the underlying access grant, - duration until the modification of an access grant should take effect, and - time required for an attacker to guess or produce valid token." > (15) 5.1.5.5: needs a reference to SAML assertions with > the current text. done - also added reference to RFC4120 in section 3.1 > (16) 5.2.2.3: this describes a refresh token rotation > scheme that I don't recall being discussed on the list, so > this is just to check that that rotation scheme, as > described, doesn't ring any alarms bells for the WG. If > not, that's fine. And if it was discussed on the list and > I've forgotten, then sorry about that:-) It has been discussed, the first time with the introduction of the option to return a new referesh token value in response to a refresh token grant request. A more recent discussion can be found here: http://www.ietf.org/mail-archive/web/oauth/current/msg06974.html > (17) 5.2.2.5: Using IMEI's like this has privacy > implications that I think you ought call out. A single > sentence and a reference to something that says "be > careful about privacy here" would be fine I'd say. (And > you need a reference for "IMEI" and to expand the term.) added note and reference to respective 3gpp spec > (18) 5.2.2.6: needs a reference for X-FRAME-OPTION. > There's a websec draft about that I think. added reference to http://tools.ietf.org/html/draft-gondrom-x-frame-options/ > (19) 5.2.3.4: what do you mean when you say "for different > deployments of a client"? That could be one secret per > install or one secret for all customers of a mobile > operator and those are radically different. I think you > need to be clear and hope you mean the former. That's > almost cleared up in the 3rd paragraph of the section but > I wanted to just check. Not sure "deployment" is the best > term there really - what's wrong with "installation"? nothing is wrong with "installation" :-) replaced deployment by installation and partially re-phrased section > (many:-) nits and typos: > > 2.3.1: maybe explain "handle-based design" or give a > reference? (Or maybe just a forward ref to 3.1?) added ref to 3.1 > 2.3.3: It might be worth re-iterating that the term > "client" in oauth is used differently, e.g. by copying a > bit of text from the base spec. I can see folks being > confused by this otherwise. copied a sentence from base spec and extended description > 3.1: "is digitally signed" - do you mean it has data > integrity and origin authentication? If MACs are commonly > used (or maybe authenticated encryption), and not > necessarily signatures, then saying that would be better. we mean data integrity and origin authentication - added some text to explain this > 3.1.2: typo: s/this mechanisms/this mechanism/ > > 3.1.2: maybe s/Expires_In/expires_in/ to match the case in > the base spec? I think it'd be better not to capitalise > this in case it finds its way into someone's code. You > could also use "Expires In" in the title and then say that > its "expires_in" in the protocol. Might be worth doing > something generic to call out when you're talking about > specific things from the protocol, e.g. use a convention > like ``expires_in'' or "expires_in" consistently and say > that in the intro. Renamed section to "Limited access token limetime" and changed wording to explicitely distinct between concept and protocol parameter. > 3.4: typo: s/the later/the latter/ > > 3.4: bullet item 1 isn't really a reason for anything but > a downside of doing this, at least as written. Maybe this > needs to be tweaked? tweaked it > 3.6: expand CSRF on 1st use and maybe give a reference > CSRF is expanded in 4.4.1.8 which is a good bit later, > and also in 4.4.2.5 which could presumably be > shortened a bit by removing the repetition. expanded CSRF a bit, added forward reference to 4.4.1.8 and shortened 4.4.2.5 > 3.7: typo: s/collage associated request/collate associated > requests/ > > 3.7: Maybe give a pointer to the definition of "native > application" in the base spec (Its section 9 of that.) > 2nd last para of p13 would be a good place for that. added pointer > section 4: maybe s/Security Threat Model/Threat Model/ > in the section title - what other kind of threat > model is there? changed to Threat Model > section 4: I wondered how we know the threat model > is "comprehensive"? Perhaps "detailed" is better? We are rather confident because we created the threat model a systematic way and had it reviewed by a lot of security folks > 4.2.1: typo: s/Users/users/g unless you mean something > special? > > 4.2.2: typo: s/a understandable/an understandable/ > > 4.2.2: "...based on who the client is." is unclear > and not gramatically nice:-) "...based on the client > identifier." would seem better. > > 4.3.1: typo? s/on transit/in transit/ Or did you > mean something else? and s/may attempts/may attempt/ > > 4.3.3: maybe s/Revelation/Disclosure/ to be a tad > less biblical:-) changed to "Revelation of client credentials during transmission" > 4.3.3: typo? 1st countermeasure reads oddly and > refers to a different place than other references > to TLS - is that correct? changed to standard wording > 4.3.3: digest auth is nearly the same as sending > credentials over the wire, TLS client auth based > on certificates would be a better example, even > if its not often done. Isn't TLS client authentication always combined with TLS protected communication? So this would merly be an additional and not alternative mechanism. > 4.3.4: 4.3.2 points to 5.1.4.1.2 but this doesn't. > Maybe it ought to? Sorry, don't understand this comment. Are you saying 5.1.4.1.2 should point back to 4.3.2? > 4.3.6: typo s/an authorization servers/an authorization > server/ > > 4.3.6: 4.3.5 refers to 5.1.4.2.2 wrt entropy. Is there > a reason to not do that here too? this section discussed a potential threat on dynamic client registration. Wen decided to remove the whole section as dynamic client registration is subject of current charter and respective security considerations should delt with in this context. > 4.4: typo? s/tokens endpoint/token endpoint/ ? > > 4.4.1.1: typo: s/by different ways/in different ways/ > > 4.4.1.1: typo-fix-typo? HTTP has a "Referer" header field, > but you fixed their typo here - might be better to live > with the bad spelling, in which case > s/referrer/referer/g;-) ok :-) > 4.4.1.1: Is there no better way to reference these > OASIS docs? More importantly, is there no better (more > stable) reference than thomasgross.net for the > PDF you reference? Tidying this up would be good. added references to OASIS documents and stable reference to 3rd document in proceedings of Computer Security Applications Conference > 4.4.1.1 and elsewhere: a few times you say "such as > TLS or SSL," I think it'd be better to just say TLS > there and do it consistently everwhere. In other > places (e.g. 4.4.1.5) you say "HTTPS" - again that'd > be better done consistently. removed SSL - would you expect us to replace HTTPS by TLS? We used HTTPS for the more specific case of HTTP+TLS > 4.4.1.1: typo: s/redeem a authorization code/redeem > an authorizatio code/ > > 4.4.1.4: "counterfeit a valid client" reads oddly, > do you mean "pretend to be a valid client"? If so, > I think that'd be clearer. > > 4.4.1.4: "and to prevent unauthorized access to > them" - I think you might add "via the oauth > protocol" there since the AS isn't responsible for > all possible ways of preventing unauthorized access. > > 4.4.1.4: typo: s/not neccesserily indicates/doesn't > necessarily indicate/ > > 4.4.1.4: typo: s/user should be explained the purpose/ > something better/ :-) tried my best: "In this context, the authorization server should explain to the end-user the purpose, scope, and duration of the authorization the client asked for. " > 4.4.1.4: expand/define CAPTCHA on 1st use. Give a > reference for this too. Especially since you also > have 5.1.4.2.5, which is maybe the best place for > the reference. Changed counter measure paragraph from: "If the authorization server automatically authenticates the end- user, it may nevertheless require some user input in order to prevent screen scraping. Examples are CAPTCHAs or user-specific secrets like PIN codes." to: "If the authorization server automatically authenticates the end-user, it may nevertheless require some user input in order to prevent screen scraping. Examples are CAPTCHAs (Completely Automated Public Turing test to tell Computers and Humans Apart) or other multi-factor authentication techniques such as random questions, token code generators, etc." > 4.4.1.4: isn't a PIN code another user authentiation? > Seems like a bad example of automatic authentication, > since it isn't automatic if the user has to enter a > PIN. see above > 4.4.1.6: Is Facebook a trademark? Maybe better to not > use that if so? Changed Facebook reference section to: (e.g. as in the implementation of "Login" button to a third-party social network site) > 4.4.1.7: typo: s/achieve that goal/achieves that goal/ > > 4.4.1.7: typo: s/victims resources/victim's resources/ > > 4.4.1.7: typo: s/The attackers gains/The attacker gains/ > > 4.4.1.7: typo: s/then the target web site/rather than > the target web site/ > > 4.4.1.7: "session fixation" could do with a reference > or definition, and that might be better earlier in > this section and not just in the countermeasures > part. changed "The authorization server may also enforce the usage and validation of pre-registered redirect URIs (see Section 5.2.3.5). This will allow for an early recognition of session fixation attempts." to: "The authorization server may also enforce the usage and validation of pre-registered redirect URIs (see Section 5.2.3.5). This will allow for an early recognition of authorization code disclosure to counterfeit clients." > 4.4.1.7: typo: s/kind of attacks/kind of attack/ > > 4.4.1.8: typo: s/not follow untrusted/to not follow > untrusted/ > > 4.4.1.9: maybe add a reference for "iframe"? And > you say "iFrames" later, better to be consistent. > > 4.4.1.9: 1st countermeasure - do you mean end-user > authorization here or end-user authentication? And > would it be better to say "system browser" or > something rather than "external browser"? (I forget > what phrase you used for that earlier but there > was something bettter:-) We mean "authorization" We came to the conclusion that it does not matter in which browser the page is loaded - removed 1st bullet > 4.4.1.9: "javascript framebusting" really needs > a reference added > 4.4.1.10: typo: s/the victims resources/the victim's > resources/ > > 4.4.1.10: typo: s/or split the/or splits the/ > > 4.4.1.10: "corresponding form post requests" isn't > clear to me - does that need rephrasing or is it > just me? > > 4.4.1.10: this is the first mention of cookies, which > I found surprising, but that's all;-) > > 4.4.1.10: the 2nd "ways to achieve this" bullet is > a bit unclear - which "It" and whose browser? I > think this could be clearer. > > 4.4.1.10: typo: s/as native app/as a native application/ > > 4.4.1.10: what does "assume" the threat mean? > > 4.4.1.10: typo: s/an user interaction/a user interaction/ > > 4.4.1.10: typo: s/CAPTCAs, or/CAPTCHAs/ or else get > rid of the "or" from the last bullet > > 4.4.1.10: typo: s/send out of bound/sent out of band/ > > 4.4.1.10: typo: s/instance message/instant message/ considerably re-worded this section > 4.4.1.11: typo? s/directing user(s) browser/directing > the user's browser/ ? > > 4.4.1.11: I don't get the explanation here. Are you > assuming (but not saying) that generating non-trivial > entropy is a slow process? (e.g. /dev/random blocking?) > Its also not clear what "pool" you mean? This probably > needs a bit of tweaking. > > 4.4.1.12: semicomplete.com may not be a sufficiently > stable reference - can't you find a better one? unfortunately not > 4.4.1.12: typo: s/Defenses such rate limiting/Defenses > such as rate limiting/ > > 4.4.1.12: typo: s/an anonymizing systems/an anonymizing > system/ > > 4.4.1.12: nicest typo yet! s/annoying system/anonymizing > system/ :-) > > 4.4.1.12: typo? maybe s/iframe/iFrame/ again? > > 4.4.1.12: 1st reference to "the CSRF token" here? That > might warrant a reference of some sort? (Maybe to > a later section?) > > 4.4.1.12: Facebook again. > > 4.4.1.12: Signing the code seems like a bit of a hack. Do > you really want to recommend this here? I suspect it'd end > up different if you actually tried it out aiming for an > interoperable solution. I'd suggest deleting this, or > maybe make it less specific, e.g. saying if origin > authentication for authorization codes could be validated > by clients, then that'd be a countermeasure, but that > there's no current spec for that. (And doing that might > just move the DoS to somewhere else depending how you > did it.) > > 4.4.2: typo: s/and It cannot/and it cannot/ > > 4.4.2.1: Is the countermeasure here TLS? If so, better to > say so. > > 4.4.2.2: requests aren't cached are they but rather > responses? > > 4.4.2.3: typo: s/An malicious/A malicious/ > > 4.4.2.3: The reference back to 4.4.1.4 isn't very > clear since a lot of the countermeasures there > mention authentication. It'd be better to explicitly > list things here or else if you stick with the > backwards reference to be more explicit about whic > exactly apply. > > 4.4.2.5: Is this entirely identical to 4.4.1.8? That > doesn't seem right. If it is, then say so explicitly. > If not, then say what's different. > > 4.4.3: 1st mention of username/password anti-pattern, > so you could add a reference > > 4.4.3: Be good to metion here that passwords are often > used for >1 service, so this anti-pattern risks whatever > else is accessible with that credential or an > algorithmically derivable equivalent (e.g. > joe@example.com/pwd might easily allow someone to guess > that the same pwd is used forjoe.user@example.net) and > then another countermeasure is to educate users to > not use the same pwd for multiple services (hard as > that is to really do;-) > > 4.4.3.4: again digest auth isn't a good example > here, but client certs are. > > 4.4.3.6: What does "Abandon on grant type..." mean? > If you mean "don't do this" then say that more > clearly. Changed to "Consider not to use grant type "password"" > 4.6.2: typo: s/transport security measure/transport > security measures/ or maybe just say TLS > > 4.6.2: typo: s/nounces/nonces/ > > 4.6.3: 1st countermeasure: maybe s/difficult/infeasible/ > I don't see why "difficult" guessing is hard enough? > > 4.6.4: typo: s/a valid access tokens/a valid access token/ > > 4.6.4: Do you mean the IP address in the 2nd > countermeasure? I'm not sure, esp. given the above. > > 4.6.4: typo: s/miss the capabilities/lack the capability/ > > 4.6.6: reference to 2616 is broken > > 4.6.6: Should you reference httpbis drafts? Just asking, I > can see arguments for referencing just 2616 or just > httpbis or both, given that this'll be read for hopefully > a while after httpbis is done. > > 4.6.7: referrer vs. referer again > > 4.6.7: What is an appropriat logging configuration? Can > you give a reference maybe or is it really that well > known? > > 4.6.7: Reloading the target page again? Are you really > recommending that? > > 5.1: typo: s/consideratios/considerations/ > > 5.1.3: I think you should note the email notifications > can be a phishing vector so don't make your emails > such that lookalike phish messages can easily be > derived from them. > > 5.1.3: Don't you need to say something about getting > email notifications delivered and not treated as spam? > Maybe you could recommend dkim here or other ways to > get better delivery. (Not sure myself, probably best > to ask someone who operates like this so see if there's > stuff to be said.) > > 5.1.4.1.3: typo: s/not store credential/not store > credentials/ > > 5.1.4.1.4: salted hashes don't prevent offline > dictionary attacks, they just increase the workload > > 5.1.5.1.4: would it be worthwhile recommending that > different client credentials be used in development > or integration mode vs. when operational? I've seen > a bunch of times when programmers were given "live" > API keys when that could've been avoided. > > 5.1.4.1.5: I don't get this. If it was only that > easy:-) I think you need to say which private keys > are used here and for what for this section to be > useful. > > 5.1.4.2.1: I think you could note that complex password > policies can also increase the liklihood that users > re-use passwords or write them down or store them > somewhere not so good, if e.g. the entropy required > over all the user's passwords (dozens usually) is > too great for long-term memory. > > 5.1.5.1: typo: s/Basis of/The basis of/ > > 5.1.5.1: typo: s/sensible service/sensitive service/ > (2nd best typo:-) > > 5.1.5.3: typo: s/preciser/more precise/ > > 5.1.5.3: typo: s/refreshments/refreshes/ > > 5.1.5.4: 2nd bullet is not a threat but a goal > > 5.1.5.4: typo: s/redeem a/redeem an/ > > 5.1.5.5: what is a "rough" server? Do you mean rogue? > > 5.5.5.6: I think you need to clarify what "address" > means here too. > > 5.1.5.9: please clarify if you mean digitally signed > (asymmetric) or also include MACing here > > 5.1.5.10: typo: s/Self-contained/Self-contained tokens/ > > 5.1.5.10: s/privacy/confidentiality/ ? > > 5.1.5.10: this (typically, I'd guess) requires sharing > symmetric keys between server nodes, so you should > say that as its a bunch of work. > > 5.1.5.11: I don't get why you want to repeat this > text (and its error:-) better to refer back to > the earlier section I think. > > 5.1.5.12: Another place where a SAML reference would > be needed. > > 5.1.6: 2nd bullet is not a "measure" but a goal. If > you had something in mind, it doesn't come out from > that text. > > 5.2.2.2: You say the binding should be protected, but > don't say how. I think you ought. > > 5.2.3: typo: s/sub-sequent/subsequent/ but maybe > better to delete the word > > 5.2.3: 2nd bullet - "trustworthiness" has gotta > be the wrong word there, what did you mean? > > 5.2.3: typo: s/statics/statistics/ > > 5.2.3: typo: s/support achieve objectives/achieve these > objectives/ ? > > 5.2.3: typo: s/by hand of an administrator/something > better/ > > 5.2.3.1: "prevents...overestimating" seems wrong, I think > you mean it reduces the probability of mistakenly treating > a useless authentication as a good one. (The point is > that servers don't "overestimate," only people do that.) > > 5.2.3.1: "cannot be entirely protected" seems like > understatement - the reality is any such secret will > leak out from anything that's any way successful. It > only protects stuff that *nobody* cares about. > > 5.2.3.1: typo: s/trust on/trust/ But I'd rephrase it > to not use the terms "trust" nor "identity" and then > it'd be better I think. > > 5.2.3.2: typo? s/The authorization may/The authrozation > server may/ ? Not sure what "issue a cliend id" means > either. (Same in 5.2.3.3) > > 5.2.3.4: typo: s/A authorization server/An authorization > server/ > > 5.2.3.5: what are "validated properties"? > > 5.2.3.5: what is the 1st bullet list on p57? there's > no introductory text? > > 5.2.3.5: the "it" in "it only works" in the last > paragraph isn't clear - which "it" do you mean? > > 5.2.3.5: saying discovery "gets involved" seems > wrong - do you mean "is used"? And what is the > "that" in "that's no longer feasible"? > > 5.2.3.6: typo: s/be unintentionally for/unintentionally > affect/? > > 5.2.3.7: typo: s/to distribute client_secret/to > distribute a client_secret/ > > 5.2.4.1: Is a "security certificate" a public key > certificate? If so, saying that is better. > > 5.2.4.1: the references to 5.7.2.x are wrong and > look like you're missing some xref's in the xml > maybe > > 5.2.4.2: you said "address" again, so the usual > question arises :-) > > 5.2.4.3: typo: s/in all situation/in situations/ > (not sure "all" is right so suggest deleting it) > > 5.2.4.4: again, be good to say how to protect > the binding > > 5.2.4.5: as for 5.2.4.4 say how binding is done > > 5.3.1: typo: s/a associated/an associated/ > > 5.3.1: "entirely protected" is (again:-) understatement > see above for a suggestion > > 5.3.1: what does "trust on the client's identity" mean? > Its not clear anyway > > 5.3.3: typo: s/operation systems/operating systems/ > (enrire 2nd & 3rd paras could do with re-phrasing) > > 5.3.4: typo: s/their level/the level/ > > 5.3.5: this is too terse - is it really finished? I'd > say there's a sentence or two missing. > > 5.4.2: what does it mean to "encourage resource > servers" to do something? I guess you mean to encourage > the people deploying those to pick resource servers > with that capability and to turn that on. > > 5.4.2: not sure if everyone will know what a > "distinguished name" is, maybe add a reference to > rfc 5280? > > 5.4.2: token-bound secrets would be used to MAC > the request and not to sign, be better to make that > clear even if you still call that "signing" here > (its not really, if we're being pedantic) > > 5.4.2: typo: s/This mechanisms/This mechanism/ > > 5.4.2 and 5.4.3: I forget - where are the protocol > mechanisms for this defined? Can you give a reference > or say that its future stuff if there aren't any > good ones? > > 5.5: typo: s/capable to validate/capable of validating/ > > 8.1: Is the base spec really normative? I'd say you're > fine with that as informative too. > > 8.2: there are a bunch of references missing as per > the questions above > > 8.2: is there no better (more stable) reference than > portablecontacts.net? > > > > > > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------080906020204060909020802 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Stephen,

I just submitted a new revision of the security document incorporating your review comments.

Please find answers to your comments below.

Thank you again for your detailed review. You helped us to significantly improve the document's quality.

best regards,
Torsten. 

Am 28.05.2012 20:34, schrieb Stephen Farrell: 
Hi all,

I've gotten the publication request for oauth-threatmodel
so here's my AD review of -05.

Its quite a read (and a good one) but I've a bunch of
questions. Some of these will need fixing I suspect
but a lot are ok to fix later after IETF LC, depending
on whether the authors want to re-spin it before then
or not. But I'd like to at least see reactions to the
questions before I start IETF LC.

Although there are many many nits and typos, those
don't actually make the document unreadable so
though I'd prefer to see 'em fixed now, I'm ok with
that happening later if its a problem to get it
all done now.

If you want to argue for going ahead with IETF LC
now please do so, but I suspect that this might need
a revised ID to fix at least a couple of the points
raised below. If nobody does argue to go ahead now,
I'll mark it as revised ID needed, but first let's
see what the answers are to the questions.

Cheers,
S.


(1) s/RFC1750/RFC4086/ is needed as noted in the write-up.
done
(2) You don't say anything about the probability of
occurrence of the various threats. I realise that you
can't be precise but it seems wrong to say nothing.  Would
it be worth at least saying that that's not done here and
that readers of this document need to do their own risk
analysis including that aspect?

That's correct - I added the following paragraph to the introduction:

"Note: This document cannot assess the probability nor the risk associated with a particular threat because those aspects strongly depend on the particular application and deployment OAuth is used to protect. Similar, impacts are given on a rather abstract level. But the information given here may serve as a foundation for deployment-specific threat models. Implementors may refine and detail the abstract threat model in order to account for the specific properties of their deployment and to come up with a risk analysis."

(3) Many deployments will use TLS accelerators.  That
means that TLS isn't fully e2e, and that opens up some
(mainly) insider attacks or attacks that can be launched
from within a compromised DMZ, but from outside the server
applications. Does that need a mention somewhere? (I've
seen systems like that deployed and a lot could go wrong
from the inside, so I think this is a real threat.)

I added another paragraph to section 5.1.1:

"Note: this document assumes end-to-end TLS protected connections between the respective protocol entities. Deployments deviating from this assumption by offloading TLS in between (e.g. on the data center edge) must refine this threat model in order to account for the additional (mainly insider) threat this may cause."

(4) Could you use just one of "client identity" or "client
identifier" consistently? I'd much prefer the latter,
which has also been the outcome of various discussions on
this topic elsewhere. For example you say "revocation of
such an identity" at the end of p13, and that's a
potential rathole, better to say "revocation of the rights
associated with a client identifier" or similar I think.
And similar changes throughout.

Replaced client identity by client identifier in most places and incorporated your proposed text

(5) 4.4.2.2: Here you recommend native applications should
use an embedded browser, but earlier you said that was a
bad idea. I think you need to be consistent or else
provide more about when its ok to embed and when its not.
Did I misread it or does that need a change?

removed 3rd bullet as native apps should use code flow

We also removed the 1st bullet in 4.4.1.9

(6) 4.4.3.1: This calls for "obfuscation" of passwords in
logs. I think you ought be stronger there and call for
strong encryption of passwords wherever they are stored,
be that logs or DBs or whatever. Would'nt that be reasonable?

This section is about preventing accidential exposure by the client. I think encryption is not appropriate here since the password is entered in the clear by the user. I added the advice to encrypt credentials as alternative means to salted hashes to 5.1.4.1.3.

(7) 4.6.4: 1st countermeasure: I don't think you mean
address here (in the sense of an IP address, which is what
that means) but rather the domain name or FQDN or URL.  In
any case, you need to say what is meant clearly.  (Also in
5.1.5.6 and elsewhere when you use the term "address".)

replaced address in most cases by URL and in some place by FDQN

(8) 4.6.6: You say to use Cache-Control, but don't say
how.  Is more needed really? Maybe there's a good document
you could reference for that? (I'm not suggesting you add
a lecture on caching btw:-)

Added text from core spec describing usage of Cache-Control and Pragma response header fields

(9) 5.1.1: needs a reference to RFC 5246 (and better to
just say TLS and not say SSL, at least for me :-)

done
(10) 5.1.1: needs a reference to whatever you mean by
"VPN" since there are many types of VPN. I assume you mean
an IPsec VPN? But even if not, saying more would be good.

Extended description and added reference to RFC 4301.
(11) 5.1.2: needs a reference to RFC 5280 and/or RFC 6125
and/or RFC 2818. Bascially, you need to say how this is
done (by reference).

Added reference to RFC 2818 since it seems to be closest to the problem

(12) 5.1.4.1: Isn't there some good reference you can give
here? (Having said that, I'd have to go look myself, but
I'd maybe start with owasp or sans.)

added reference to OWASP

(13) 5.1.4.2.2: if p(collision) should be <=2^(-160) then
what's the point of saying it ought be <= 2^(-128)? Also
if sha-1 were perfect, then the 160 bits output would
really have a collision probability of about 2^(-80) with
many many tokens, but not 2^(-160). I think you need
to fix something there.  Perhaps you're really saying that
all high-entropy secrets should be >=128 bits long and
constructed with a good (P)RNG? If so, saying so more
clearly would be better. Not everyone will get the
collision probability way of saying that even when its
properly stated. (This text is also repeated, be better if
you just said this once I think.)

modified text as follows

"When creating secrets not intended for usage by human users (e.g. client secrets or token handles), the authorization server should include a reasonable level of entropy in order to mitigate the risk of guessing attacks. The token value should be >=128 bits long and constructed from a cryptographically strong random or pseudo-random number sequence (see [RFC4086] for best current practice) generated by the Authorization Server."

removed 5.1.5.11. (redundant text) and updated references accordingly

(14) 5.1.5.2: what is a "reasonable duration" - I don't
think its ok to say that but nothing else. Can't you give
some "reasonable" examples based on current usage?

added examples and explanation of factors determining reasonable expiration time

"Tokens should generally expire after a reasonable duration. This complements and strengthens other security measures (such as signatures) and reduces the impact of all kinds of token leaks. Depending on the risk associated with a token leakage, tokens may expire after a few minutes (e.g. for payment transactions) or stay valid for hours (e.g. read access to contacts).

The expiration time is determined by a couple of factors, including:

- risk associated to a token leakage
- duration of the underlying access grant,
- duration until the modification of an access grant should take effect, and
- time required for an attacker to guess or produce valid token."

(15) 5.1.5.5: needs a reference to SAML assertions with
the current text.

done - also added reference to RFC4120 in section 3.1
(16) 5.2.2.3: this describes a refresh token rotation
scheme that I don't recall being discussed on the list, so
this is just to check that that rotation scheme, as
described, doesn't ring any alarms bells for the WG. If
not, that's fine. And if it was discussed on the list and
I've forgotten, then sorry about that:-)

It has been discussed, the first time with the introduction of the option to return a new referesh token value in response to a refresh token grant request. A more recent discussion can be found here: http://www.ietf.org/mail-archive/web/oauth/current/msg06974.html

(17) 5.2.2.5: Using IMEI's like this has privacy
implications that I think you ought call out. A single
sentence and a reference to something that says "be
careful about privacy here" would be fine I'd say. (And
you need a reference for "IMEI" and to expand the term.)

added note and reference to respective 3gpp spec

(18) 5.2.2.6: needs a reference for X-FRAME-OPTION.
There's a websec draft about that I think.

added reference to http://tools.ietf.org/html/draft-gondrom-x-frame-options/ 
(19) 5.2.3.4: what do you mean when you say "for different
deployments of a client"? That could be one secret per
install or one secret for all customers of a mobile
operator and those are radically different. I think you
need to be clear and hope you mean the former. That's
almost cleared up in the 3rd paragraph of the section but
I wanted to just check. Not sure "deployment" is the best
term there really - what's wrong with "installation"?

nothing is wrong with "installation" :-)

replaced deployment by installation and partially re-phrased section

(many:-) nits and typos:

2.3.1: maybe explain "handle-based design" or give a
reference? (Or maybe just a forward ref to 3.1?)

added ref to 3.1
2.3.3: It might be worth re-iterating that the term
"client" in oauth is used differently, e.g.  by copying a
bit of text from the base spec. I can see folks being
confused by this otherwise.

copied a sentence from base spec and extended description

3.1: "is digitally signed" - do you mean it has data
integrity and origin authentication?  If MACs are commonly
used (or maybe authenticated encryption), and not
necessarily signatures, then saying that would be better.

we mean data integrity and origin authentication - added some text to explain this

3.1.2: typo: s/this mechanisms/this mechanism/

3.1.2: maybe s/Expires_In/expires_in/ to match the case in
the base spec? I think it'd be better not to capitalise
this in case it finds its way into someone's code. You
could also use "Expires In" in the title and then say that
its "expires_in" in the protocol. Might be worth doing
something generic to call out when you're talking about
specific things from the protocol, e.g. use a convention
like ``expires_in'' or "expires_in" consistently and say
that in the intro.

Renamed section to "Limited access token limetime" and changed wording to explicitely distinct between concept and protocol parameter.
 
3.4: typo: s/the later/the latter/

3.4: bullet item 1 isn't really a reason for anything but
a downside of doing this, at least as written. Maybe this
needs to be tweaked?

tweaked it
3.6: expand CSRF on 1st use and maybe give a reference
CSRF is expanded in 4.4.1.8 which is a good bit later,
and also in 4.4.2.5 which could presumably be
shortened a bit by removing the repetition.

expanded CSRF a bit, added forward reference to 4.4.1.8 and shortened 4.4.2.5

3.7: typo: s/collage associated request/collate associated
requests/

3.7: Maybe give a pointer to the definition of "native
application" in the base spec (Its section 9 of that.)
2nd last para of p13 would be a good place for that.

added pointer

section 4: maybe s/Security Threat Model/Threat Model/
in the section title - what other kind of threat
model is there?

changed to Threat Model

section 4: I wondered how we know the threat model
is "comprehensive"? Perhaps "detailed" is better?

We are rather confident because we created the threat model a systematic way and had it reviewed by a lot of security folks

4.2.1: typo: s/Users/users/g unless you mean something
special?

4.2.2: typo: s/a understandable/an understandable/

4.2.2: "...based on who the client is." is unclear
and not gramatically nice:-) "...based on the client
identifier." would seem better.

4.3.1: typo? s/on transit/in transit/ Or did you
mean something else? and s/may attempts/may attempt/

4.3.3: maybe s/Revelation/Disclosure/ to be a tad
less biblical:-)

changed to "Revelation of client credentials during transmission"

4.3.3: typo? 1st countermeasure reads oddly and
refers to a different place than other references
to TLS - is that correct?

changed to standard wording

4.3.3: digest auth is nearly the same as sending
credentials over the wire, TLS client auth based
on certificates would be a better example, even
if its not often done.

Isn't TLS client authentication always combined with TLS protected communication? So this would merly be an additional and not alternative mechanism.

4.3.4: 4.3.2 points to 5.1.4.1.2 but this doesn't.
Maybe it ought to?

Sorry, don't understand this comment. Are you saying 5.1.4.1.2 should point back to 4.3.2?

4.3.6: typo s/an authorization servers/an authorization
server/

4.3.6: 4.3.5 refers to 5.1.4.2.2 wrt entropy. Is there
a reason to not do that here too?

this section discussed a potential threat on dynamic client registration. Wen decided to remove the whole section as dynamic client registration is subject of current charter and respective security considerations should delt with in this context.

4.4: typo? s/tokens endpoint/token endpoint/ ?

4.4.1.1: typo: s/by different ways/in different ways/

4.4.1.1: typo-fix-typo? HTTP has a "Referer" header field,
but you fixed their typo here - might be better to live
with the bad spelling, in which case
s/referrer/referer/g;-)

ok :-)

4.4.1.1: Is there no better way to reference these
OASIS docs? More importantly, is there no better (more
stable) reference than thomasgross.net for the
PDF you reference? Tidying this up would be good.

added references to OASIS documents and stable reference to 3rd document in proceedings of Computer Security Applications Conference

4.4.1.1 and elsewhere: a few times you say "such as
TLS or SSL," I think it'd be better to just say TLS
there and do it consistently everwhere. In other
places (e.g. 4.4.1.5) you say "HTTPS" - again that'd
be better done consistently.

removed SSL - would you expect us to replace HTTPS by TLS? We used HTTPS for the more specific case of HTTP+TLS

4.4.1.1: typo: s/redeem a authorization code/redeem
an authorizatio code/

4.4.1.4: "counterfeit a valid client" reads oddly,
do you mean "pretend to be a valid client"? If so,
I think that'd be clearer.

4.4.1.4: "and to prevent unauthorized access to
them" - I think you might add "via the oauth
protocol" there since the AS isn't responsible for
all possible ways of preventing unauthorized access.

4.4.1.4: typo: s/not neccesserily indicates/doesn't
necessarily indicate/

4.4.1.4: typo: s/user should be explained the purpose/
something better/ :-)

tried my best:

"In this context, the authorization server should explain to the end-user the purpose, scope, and duration of the authorization the client asked for. "


4.4.1.4: expand/define CAPTCHA on 1st use. Give a
reference for this too. Especially since you also
have 5.1.4.2.5, which is maybe the best place for
the reference.

Changed counter measure paragraph from:
"If the authorization server automatically authenticates the end-
      user, it may nevertheless require some user input in order to
      prevent screen scraping.  Examples are CAPTCHAs or user-specific
      secrets like PIN codes."
 to:
"If the authorization server automatically authenticates the end-user, it may nevertheless require some user input in order to prevent screen scraping. Examples are CAPTCHAs (Completely Automated Public Turing test to tell Computers and Humans Apart) or other multi-factor authentication techniques such as random questions, token code generators, etc."

4.4.1.4: isn't a PIN code another user authentiation?
Seems like a bad example of automatic authentication,
since it isn't automatic if the user has to enter a
PIN.

see above
4.4.1.6: Is Facebook a trademark? Maybe better to not
use that if so?

Changed Facebook reference section to:
(e.g. as in the implementation of "Login" button to a third-party social network site)

4.4.1.7: typo: s/achieve that goal/achieves that goal/

4.4.1.7: typo: s/victims resources/victim's resources/

4.4.1.7: typo: s/The attackers gains/The attacker gains/

4.4.1.7: typo: s/then the target web site/rather than
the target web site/

4.4.1.7: "session fixation" could do with a reference
or definition, and that might be better earlier in
this section and not just in the countermeasures
part.

changed
"The authorization server may also enforce the usage and validation of pre-registered redirect URIs (see Section 5.2.3.5).  This will allow for an early recognition of session fixation attempts."
to:
"The authorization server may also enforce the usage and validation of pre-registered redirect URIs (see Section 5.2.3.5).  This will allow for an early recognition of authorization code disclosure to counterfeit clients."



4.4.1.7: typo: s/kind of attacks/kind of attack/

4.4.1.8: typo: s/not follow untrusted/to not follow
untrusted/

4.4.1.9: maybe add a reference for "iframe"? And
you say "iFrames" later, better to be consistent.

4.4.1.9: 1st countermeasure - do you mean end-user
authorization here or end-user authentication? And
would it be better to say "system browser" or
something rather than "external browser"? (I forget
what phrase you used for that earlier but there
was something bettter:-)

We mean "authorization"

We came to the conclusion that it does not matter in which browser the page is loaded - removed 1st bullet

4.4.1.9: "javascript framebusting" really needs
a reference
added
4.4.1.10: typo: s/the victims resources/the victim's
resources/

4.4.1.10: typo: s/or split the/or splits the/

4.4.1.10: "corresponding form post requests" isn't
clear to me - does that need rephrasing or is it
just me?

4.4.1.10: this is the first mention of cookies, which
I found surprising, but that's all;-)

4.4.1.10: the 2nd "ways to achieve this" bullet is
a bit unclear - which "It" and whose browser? I
think this could be clearer.

4.4.1.10: typo: s/as native app/as a native application/

4.4.1.10: what does "assume" the threat mean?

4.4.1.10: typo: s/an user interaction/a user interaction/

4.4.1.10: typo: s/CAPTCAs, or/CAPTCHAs/ or else get
rid of the "or" from the last bullet

4.4.1.10: typo: s/send out of bound/sent out of band/

4.4.1.10: typo: s/instance message/instant message/

considerably re-worded this section

4.4.1.11: typo? s/directing user(s) browser/directing
the user's browser/ ?

4.4.1.11: I don't get the explanation here. Are you
assuming (but not saying) that generating non-trivial
entropy is a slow process? (e.g. /dev/random blocking?)
Its also not clear what "pool" you mean? This probably
needs a bit of tweaking.

4.4.1.12: semicomplete.com may not be a sufficiently
stable reference - can't you find a better one?

unfortunately not
4.4.1.12: typo: s/Defenses such rate limiting/Defenses
such as rate limiting/

4.4.1.12: typo: s/an anonymizing systems/an anonymizing
system/

4.4.1.12: nicest typo yet! s/annoying system/anonymizing
system/ :-)

4.4.1.12: typo? maybe s/iframe/iFrame/ again?

4.4.1.12: 1st reference to "the CSRF token" here? That
might warrant a reference of some sort? (Maybe to
a later section?)

4.4.1.12: Facebook again.

4.4.1.12: Signing the code seems like a bit of a hack.  Do
you really want to recommend this here? I suspect it'd end
up different if you actually tried it out aiming for an
interoperable solution. I'd suggest deleting this, or
maybe make it less specific, e.g. saying if origin
authentication for authorization codes could be validated
by clients, then that'd be a countermeasure, but that
there's no current spec for that. (And doing that might
just move the DoS to somewhere else depending how you
did it.)

4.4.2: typo: s/and It cannot/and it cannot/

4.4.2.1: Is the countermeasure here TLS? If so, better to
say so.

4.4.2.2: requests aren't cached are they but rather
responses?

4.4.2.3: typo: s/An malicious/A malicious/

4.4.2.3: The reference back to 4.4.1.4 isn't very
clear since a lot of the countermeasures there
mention authentication. It'd be better to explicitly
list things here or else if you stick with the
backwards reference to be more explicit about whic
exactly apply.

4.4.2.5: Is this entirely identical to 4.4.1.8? That
doesn't seem right. If it is, then say so explicitly.
If not, then say what's different.

4.4.3: 1st mention of username/password anti-pattern,
so you could add a reference

4.4.3: Be good to metion here that passwords are often
used for >1 service, so this anti-pattern risks whatever
else is accessible with that credential or an
algorithmically derivable equivalent (e.g.
joe@example.com/pwd might easily allow someone to guess
that the same pwd is used for joe.user@example.net) and
then another countermeasure is to educate users to
not use the same pwd for multiple services (hard as
that is to really do;-)

4.4.3.4: again digest auth isn't a good example
here, but client certs are.

4.4.3.6: What does "Abandon on grant type..." mean?
If you mean "don't do this" then say that more
clearly.

Changed to "Consider not to use grant type "password“"

 
4.6.2: typo: s/transport security measure/transport
security measures/ or maybe just say TLS

4.6.2: typo: s/nounces/nonces/

4.6.3: 1st countermeasure: maybe s/difficult/infeasible/
I don't see why "difficult" guessing is hard enough?

4.6.4: typo: s/a valid access tokens/a valid access token/

4.6.4: Do you mean the IP address in the 2nd
countermeasure?  I'm not sure, esp. given the above.

4.6.4: typo: s/miss the capabilities/lack the capability/

4.6.6: reference to 2616 is broken

4.6.6: Should you reference httpbis drafts? Just asking, I
can see arguments for referencing just 2616 or just
httpbis or both, given that this'll be read for hopefully
a while after httpbis is done.

4.6.7: referrer vs. referer again

4.6.7: What is an appropriat logging configuration? Can
you give a reference maybe or is it really that well
known?

4.6.7: Reloading the target page again? Are you really
recommending that?

5.1: typo: s/consideratios/considerations/

5.1.3: I think you should note the email notifications
can be a phishing vector so don't make your emails
such that lookalike phish messages can easily be
derived from them.

5.1.3: Don't you need to say something about getting
email notifications delivered and not treated as spam?
Maybe you could recommend dkim here or other ways to
get better delivery. (Not sure myself, probably best
to ask someone who operates like this so see if there's
stuff to be said.)

5.1.4.1.3: typo: s/not store credential/not store
credentials/

5.1.4.1.4: salted hashes don't prevent offline
dictionary attacks, they just increase the workload

5.1.5.1.4: would it be worthwhile recommending that
different client credentials be used in development
or integration mode vs. when operational? I've seen
a bunch of times when programmers were given "live"
API keys when that could've been avoided.

5.1.4.1.5: I don't get this. If it was only that
easy:-) I think you need to say which private keys
are used here and for what for this section to be
useful.

5.1.4.2.1: I think you could note that complex password
policies can also increase the liklihood that users
re-use passwords or write them down or store them
somewhere not so good, if e.g. the entropy required
over all the user's passwords (dozens usually) is
too great for long-term memory.

5.1.5.1: typo: s/Basis of/The basis of/

5.1.5.1: typo: s/sensible service/sensitive service/
(2nd best typo:-)

5.1.5.3: typo: s/preciser/more precise/

5.1.5.3: typo: s/refreshments/refreshes/

5.1.5.4: 2nd bullet is not a threat but a goal

5.1.5.4: typo: s/redeem a/redeem an/

5.1.5.5: what is a "rough" server? Do you mean rogue?

5.5.5.6: I think you need to clarify what "address"
means here too.

5.1.5.9: please clarify if you mean digitally signed
(asymmetric) or also include MACing here

5.1.5.10: typo: s/Self-contained/Self-contained tokens/

5.1.5.10: s/privacy/confidentiality/ ?

5.1.5.10: this (typically, I'd guess) requires sharing
symmetric keys between server nodes, so you should
say that as its a bunch of work.

5.1.5.11: I don't get why you want to repeat this
text (and its error:-) better to refer back to
the earlier section I think.

5.1.5.12: Another place where a SAML reference would
be needed.

5.1.6: 2nd bullet is not a "measure" but a goal. If
you had something in mind, it doesn't come out from
that text.

5.2.2.2: You say the binding should be protected, but
don't say how. I think you ought.

5.2.3: typo: s/sub-sequent/subsequent/ but maybe
better to delete the word

5.2.3: 2nd bullet - "trustworthiness" has gotta
be the wrong word there, what did you mean?

5.2.3: typo: s/statics/statistics/

5.2.3: typo: s/support achieve objectives/achieve these
objectives/ ?

5.2.3: typo: s/by hand of an administrator/something
better/

5.2.3.1: "prevents...overestimating" seems wrong, I think
you mean it reduces the probability of mistakenly treating
a useless authentication as a good one. (The point is
that servers don't "overestimate," only people do that.)

5.2.3.1: "cannot be entirely protected" seems like
understatement - the reality is any such secret will
leak out from anything that's any way successful. It
only protects stuff that *nobody* cares about.

5.2.3.1: typo: s/trust on/trust/ But I'd rephrase it
to not use the terms "trust" nor "identity" and then
it'd be better I think.

5.2.3.2: typo? s/The authorization may/The authrozation
server may/ ? Not sure what "issue a cliend id" means
either. (Same in 5.2.3.3)

5.2.3.4: typo: s/A authorization server/An authorization
server/

5.2.3.5: what are "validated properties"?

5.2.3.5: what is the 1st bullet list on p57? there's
no introductory text?

5.2.3.5: the "it" in "it only works" in the last
paragraph isn't clear - which "it" do you mean?

5.2.3.5: saying discovery "gets involved" seems
wrong - do you mean "is used"? And what is the
"that" in "that's no longer feasible"?

5.2.3.6: typo: s/be unintentionally for/unintentionally
affect/?

5.2.3.7: typo: s/to distribute client_secret/to
distribute a client_secret/

5.2.4.1: Is a "security certificate" a public key
certificate? If so, saying that is better.

5.2.4.1: the references to 5.7.2.x are wrong and
look like you're missing some xref's in the xml
maybe

5.2.4.2: you said "address" again, so the usual
question arises :-)

5.2.4.3: typo: s/in all situation/in situations/
(not sure "all" is right so suggest deleting it)

5.2.4.4: again, be good to say how to protect
the binding

5.2.4.5: as for 5.2.4.4 say how binding is done

5.3.1: typo: s/a associated/an associated/

5.3.1: "entirely protected" is (again:-) understatement
see above for a suggestion

5.3.1: what does "trust on the client's identity" mean?
Its not clear anyway

5.3.3: typo: s/operation systems/operating systems/
(enrire 2nd & 3rd paras could do with re-phrasing)

5.3.4: typo: s/their level/the level/

5.3.5: this is too terse - is it really finished? I'd
say there's a sentence or two missing.

5.4.2: what does it mean to "encourage resource
servers" to do something? I guess you mean to encourage
the people deploying those to pick resource servers
with that capability and to turn that on.

5.4.2: not sure if everyone will know what a
"distinguished name" is, maybe add a reference to
rfc 5280?

5.4.2: token-bound secrets would be used to MAC
the request and not to sign, be better to make that
clear even if you still call that "signing" here
(its not really, if we're being pedantic)

5.4.2: typo: s/This mechanisms/This mechanism/

5.4.2 and 5.4.3: I forget - where are the protocol
mechanisms for this defined? Can you give a reference
or say that its future stuff if there aren't any
good ones?

5.5: typo: s/capable to validate/capable of validating/

8.1: Is the base spec really normative? I'd say you're
fine with that as informative too.

8.2: there are a bunch of references missing as per
the questions above

8.2: is there no better (more stable) reference than
portablecontacts.net?










_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--------------080906020204060909020802-- From stephen.farrell@cs.tcd.ie Wed Jun 27 17:17:25 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3D6011E8150 for ; Wed, 27 Jun 2012 17:17:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.939 X-Spam-Level: X-Spam-Status: No, score=-101.939 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, J_CHICKENPOX_52=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2vayRtzycvel for ; Wed, 27 Jun 2012 17:17:22 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 0E6C411E814C for ; Wed, 27 Jun 2012 17:17:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 0E2EC153B8D; Thu, 28 Jun 2012 01:17:17 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1340842634; bh=DKv3dz3e6fp850 OHpg8oHHIEtSH+B6BlQ5uRjfSqoeM=; b=MQVlZcff7wKVz2zNUXJFJv1cSTyUQc wA3mmLBOdCDZFhSN65ZG4gZ9GEpyYeS4uNUeHHmc2KasFEjOy9GC6mJaQmhFfX0R V+fiA1Ag+qVcePn7V/xgmxQi9LQrqalvgKNFgVCvaRQ7o1uY/lknBCi6lExMAbsQ jbtxj+ePrQUdQwktFA7DxUGnoxitjoHtHlYTktzKhx35JPVQoM6zImUAQPdcNKfq jViWcakXPTqAPa2DQqoCaCiwaXY3MezNZslhIMnNa1LhvV9JBtC8VsLy3SOwtEoS xpnSTCnGgwSnN0nnaTXPaXsHqR8z+kS6PmOQhYy4/wp4iLv02FsJ6taQ== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id IIFfYZaScj3O; Thu, 28 Jun 2012 01:17:14 +0100 (IST) Received: from [10.87.48.11] (unknown [86.46.28.136]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id CD5F1171481; Thu, 28 Jun 2012 01:17:10 +0100 (IST) Message-ID: <4FEBA286.6020003@cs.tcd.ie> Date: Thu, 28 Jun 2012 01:17:10 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Torsten Lodderstedt References: <4FC3C53E.8020704@cs.tcd.ie> <4FEB4B0C.2030700@lodderstedt.net> In-Reply-To: <4FEB4B0C.2030700@lodderstedt.net> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Barry Leiba , Derek Atkins , "oauth@ietf.org" Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-threatmodel-05 X-BeenThere: oauth@ietf.org X-Mailman-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, 28 Jun 2012 00:17:25 -0000 Hiya, Great. I've asked for IETF LC to start. I'll go through the changes below during that in case there's some more follow up. Thanks, S. On 06/27/2012 07:03 PM, Torsten Lodderstedt wrote: > Hi Stephen, > > I just submitted a new revision of the security document incorporating > your review comments. > > Please find answers to your comments below. > > Thank you again for your detailed review. You helped us to significantly > improve the document's quality. > > best regards, > Torsten. > > Am 28.05.2012 20:34, schrieb Stephen Farrell: >> Hi all, >> >> I've gotten the publication request for oauth-threatmodel >> so here's my AD review of -05. >> >> Its quite a read (and a good one) but I've a bunch of >> questions. Some of these will need fixing I suspect >> but a lot are ok to fix later after IETF LC, depending >> on whether the authors want to re-spin it before then >> or not. But I'd like to at least see reactions to the >> questions before I start IETF LC. >> >> Although there are many many nits and typos, those >> don't actually make the document unreadable so >> though I'd prefer to see 'em fixed now, I'm ok with >> that happening later if its a problem to get it >> all done now. >> >> If you want to argue for going ahead with IETF LC >> now please do so, but I suspect that this might need >> a revised ID to fix at least a couple of the points >> raised below. If nobody does argue to go ahead now, >> I'll mark it as revised ID needed, but first let's >> see what the answers are to the questions. >> >> Cheers, >> S. >> >> >> (1) s/RFC1750/RFC4086/ is needed as noted in the write-up. > done >> (2) You don't say anything about the probability of >> occurrence of the various threats. I realise that you >> can't be precise but it seems wrong to say nothing. Would >> it be worth at least saying that that's not done here and >> that readers of this document need to do their own risk >> analysis including that aspect? > > That's correct - I added the following paragraph to the introduction: > > "Note: This document cannot assess the probability nor the risk > associated with a particular threat because those aspects strongly > depend on the particular application and deployment OAuth is used to > protect. Similar, impacts are given on a rather abstract level. But the > information given here may serve as a foundation for deployment-specific > threat models. Implementors may refine and detail the abstract threat > model in order to account for the specific properties of their > deployment and to come up with a risk analysis." > >> (3) Many deployments will use TLS accelerators. That >> means that TLS isn't fully e2e, and that opens up some >> (mainly) insider attacks or attacks that can be launched >> from within a compromised DMZ, but from outside the server >> applications. Does that need a mention somewhere? (I've >> seen systems like that deployed and a lot could go wrong >> from the inside, so I think this is a real threat.) > > I added another paragraph to section 5.1.1: > > "Note: this document assumes end-to-end TLS protected connections > between the respective protocol entities. Deployments deviating from > this assumption by offloading TLS in between (e.g. on the data center > edge) must refine this threat model in order to account for the > additional (mainly insider) threat this may cause." > >> (4) Could you use just one of "client identity" or "client >> identifier" consistently? I'd much prefer the latter, >> which has also been the outcome of various discussions on >> this topic elsewhere. For example you say "revocation of >> such an identity" at the end of p13, and that's a >> potential rathole, better to say "revocation of the rights >> associated with a client identifier" or similar I think. >> And similar changes throughout. > > Replaced client identity by client identifier in most places and > incorporated your proposed text > >> (5) 4.4.2.2: Here you recommend native applications should >> use an embedded browser, but earlier you said that was a >> bad idea. I think you need to be consistent or else >> provide more about when its ok to embed and when its not. >> Did I misread it or does that need a change? > > removed 3rd bullet as native apps should use code flow > > We also removed the 1st bullet in 4.4.1.9 > >> (6) 4.4.3.1: This calls for "obfuscation" of passwords in >> logs. I think you ought be stronger there and call for >> strong encryption of passwords wherever they are stored, >> be that logs or DBs or whatever. Would'nt that be reasonable? > > This section is about preventing accidential exposure by the client. I > think encryption is not appropriate here since the password is entered > in the clear by the user. I added the advice to encrypt credentials as > alternative means to salted hashes to 5.1.4.1.3. > >> (7) 4.6.4: 1st countermeasure: I don't think you mean >> address here (in the sense of an IP address, which is what >> that means) but rather the domain name or FQDN or URL. In >> any case, you need to say what is meant clearly. (Also in >> 5.1.5.6 and elsewhere when you use the term "address".) > > replaced address in most cases by URL and in some place by FDQN > >> (8) 4.6.6: You say to use Cache-Control, but don't say >> how. Is more needed really? Maybe there's a good document >> you could reference for that? (I'm not suggesting you add >> a lecture on caching btw:-) > > Added text from core spec describing usage of Cache-Control and Pragma > response header fields > >> (9) 5.1.1: needs a reference to RFC 5246 (and better to >> just say TLS and not say SSL, at least for me :-) > > done >> (10) 5.1.1: needs a reference to whatever you mean by >> "VPN" since there are many types of VPN. I assume you mean >> an IPsec VPN? But even if not, saying more would be good. > > Extended description and added reference to RFC 4301. >> (11) 5.1.2: needs a reference to RFC 5280 and/or RFC 6125 >> and/or RFC 2818. Bascially, you need to say how this is >> done (by reference). > > Added reference to RFC 2818 since it seems to be closest to the problem > >> (12) 5.1.4.1: Isn't there some good reference you can give >> here? (Having said that, I'd have to go look myself, but >> I'd maybe start with owasp or sans.) > > added reference to OWASP > >> (13) 5.1.4.2.2: if p(collision) should be <=2^(-160) then >> what's the point of saying it ought be <= 2^(-128)? Also >> if sha-1 were perfect, then the 160 bits output would >> really have a collision probability of about 2^(-80) with >> many many tokens, but not 2^(-160). I think you need >> to fix something there. Perhaps you're really saying that >> all high-entropy secrets should be >=128 bits long and >> constructed with a good (P)RNG? If so, saying so more >> clearly would be better. Not everyone will get the >> collision probability way of saying that even when its >> properly stated. (This text is also repeated, be better if >> you just said this once I think.) > > modified text as follows > > "When creating secrets not intended for usage by human users (e.g. > client secrets or token handles), the authorization server should > include a reasonable level of entropy in order to mitigate the risk of > guessing attacks. The token value should be >=128 bits long and > constructed from a cryptographically strong random or pseudo-random > number sequence (see [RFC4086] for best current practice) generated by > the Authorization Server." > > removed 5.1.5.11. (redundant text) and updated references accordingly > >> (14) 5.1.5.2: what is a "reasonable duration" - I don't >> think its ok to say that but nothing else. Can't you give >> some "reasonable" examples based on current usage? > > added examples and explanation of factors determining reasonable > expiration time > > "Tokens should generally expire after a reasonable duration. This > complements and strengthens other security measures (such as signatures) > and reduces the impact of all kinds of token leaks. Depending on the > risk associated with a token leakage, tokens may expire after a few > minutes (e.g. for payment transactions) or stay valid for hours (e.g. > read access to contacts). > > The expiration time is determined by a couple of factors, including: > > - risk associated to a token leakage > - duration of the underlying access grant, > - duration until the modification of an access grant should take effect, > and > - time required for an attacker to guess or produce valid token." > >> (15) 5.1.5.5: needs a reference to SAML assertions with >> the current text. > > done - also added reference to RFC4120 in section 3.1 >> (16) 5.2.2.3: this describes a refresh token rotation >> scheme that I don't recall being discussed on the list, so >> this is just to check that that rotation scheme, as >> described, doesn't ring any alarms bells for the WG. If >> not, that's fine. And if it was discussed on the list and >> I've forgotten, then sorry about that:-) > > It has been discussed, the first time with the introduction of the > option to return a new referesh token value in response to a refresh > token grant request. A more recent discussion can be found here: > http://www.ietf.org/mail-archive/web/oauth/current/msg06974.html > >> (17) 5.2.2.5: Using IMEI's like this has privacy >> implications that I think you ought call out. A single >> sentence and a reference to something that says "be >> careful about privacy here" would be fine I'd say. (And >> you need a reference for "IMEI" and to expand the term.) > > added note and reference to respective 3gpp spec > >> (18) 5.2.2.6: needs a reference for X-FRAME-OPTION. >> There's a websec draft about that I think. > > added reference to > http://tools.ietf.org/html/draft-gondrom-x-frame-options/ >> (19) 5.2.3.4: what do you mean when you say "for different >> deployments of a client"? That could be one secret per >> install or one secret for all customers of a mobile >> operator and those are radically different. I think you >> need to be clear and hope you mean the former. That's >> almost cleared up in the 3rd paragraph of the section but >> I wanted to just check. Not sure "deployment" is the best >> term there really - what's wrong with "installation"? > > nothing is wrong with "installation" :-) > > replaced deployment by installation and partially re-phrased section > >> (many:-) nits and typos: >> >> 2.3.1: maybe explain "handle-based design" or give a >> reference? (Or maybe just a forward ref to 3.1?) > > added ref to 3.1 >> 2.3.3: It might be worth re-iterating that the term >> "client" in oauth is used differently, e.g. by copying a >> bit of text from the base spec. I can see folks being >> confused by this otherwise. > > copied a sentence from base spec and extended description > >> 3.1: "is digitally signed" - do you mean it has data >> integrity and origin authentication? If MACs are commonly >> used (or maybe authenticated encryption), and not >> necessarily signatures, then saying that would be better. > > we mean data integrity and origin authentication - added some text to > explain this > >> 3.1.2: typo: s/this mechanisms/this mechanism/ >> >> 3.1.2: maybe s/Expires_In/expires_in/ to match the case in >> the base spec? I think it'd be better not to capitalise >> this in case it finds its way into someone's code. You >> could also use "Expires In" in the title and then say that >> its "expires_in" in the protocol. Might be worth doing >> something generic to call out when you're talking about >> specific things from the protocol, e.g. use a convention >> like ``expires_in'' or "expires_in" consistently and say >> that in the intro. > > Renamed section to "Limited access token limetime" and changed wording > to explicitely distinct between concept and protocol parameter. > >> 3.4: typo: s/the later/the latter/ >> >> 3.4: bullet item 1 isn't really a reason for anything but >> a downside of doing this, at least as written. Maybe this >> needs to be tweaked? > > tweaked it >> 3.6: expand CSRF on 1st use and maybe give a reference >> CSRF is expanded in 4.4.1.8 which is a good bit later, >> and also in 4.4.2.5 which could presumably be >> shortened a bit by removing the repetition. > > expanded CSRF a bit, added forward reference to 4.4.1.8 and shortened > 4.4.2.5 > >> 3.7: typo: s/collage associated request/collate associated >> requests/ >> >> 3.7: Maybe give a pointer to the definition of "native >> application" in the base spec (Its section 9 of that.) >> 2nd last para of p13 would be a good place for that. > > added pointer > >> section 4: maybe s/Security Threat Model/Threat Model/ >> in the section title - what other kind of threat >> model is there? > > changed to Threat Model > >> section 4: I wondered how we know the threat model >> is "comprehensive"? Perhaps "detailed" is better? > > We are rather confident because we created the threat model a systematic > way and had it reviewed by a lot of security folks > >> 4.2.1: typo: s/Users/users/g unless you mean something >> special? >> >> 4.2.2: typo: s/a understandable/an understandable/ >> >> 4.2.2: "...based on who the client is." is unclear >> and not gramatically nice:-) "...based on the client >> identifier." would seem better. >> >> 4.3.1: typo? s/on transit/in transit/ Or did you >> mean something else? and s/may attempts/may attempt/ >> >> 4.3.3: maybe s/Revelation/Disclosure/ to be a tad >> less biblical:-) > > changed to "Revelation of client credentials during transmission" > >> 4.3.3: typo? 1st countermeasure reads oddly and >> refers to a different place than other references >> to TLS - is that correct? > > changed to standard wording > >> 4.3.3: digest auth is nearly the same as sending >> credentials over the wire, TLS client auth based >> on certificates would be a better example, even >> if its not often done. > > Isn't TLS client authentication always combined with TLS protected > communication? So this would merly be an additional and not alternative > mechanism. > >> 4.3.4: 4.3.2 points to 5.1.4.1.2 but this doesn't. >> Maybe it ought to? > > Sorry, don't understand this comment. Are you saying 5.1.4.1.2 should > point back to 4.3.2? > >> 4.3.6: typo s/an authorization servers/an authorization >> server/ >> >> 4.3.6: 4.3.5 refers to 5.1.4.2.2 wrt entropy. Is there >> a reason to not do that here too? > > this section discussed a potential threat on dynamic client > registration. Wen decided to remove the whole section as dynamic client > registration is subject of current charter and respective security > considerations should delt with in this context. > >> 4.4: typo? s/tokens endpoint/token endpoint/ ? >> >> 4.4.1.1: typo: s/by different ways/in different ways/ >> >> 4.4.1.1: typo-fix-typo? HTTP has a "Referer" header field, >> but you fixed their typo here - might be better to live >> with the bad spelling, in which case >> s/referrer/referer/g;-) > > ok :-) > >> 4.4.1.1: Is there no better way to reference these >> OASIS docs? More importantly, is there no better (more >> stable) reference than thomasgross.net for the >> PDF you reference? Tidying this up would be good. > > added references to OASIS documents and stable reference to 3rd document > in proceedings of Computer Security Applications Conference > >> 4.4.1.1 and elsewhere: a few times you say "such as >> TLS or SSL," I think it'd be better to just say TLS >> there and do it consistently everwhere. In other >> places (e.g. 4.4.1.5) you say "HTTPS" - again that'd >> be better done consistently. > > removed SSL - would you expect us to replace HTTPS by TLS? We used HTTPS > for the more specific case of HTTP+TLS > >> 4.4.1.1: typo: s/redeem a authorization code/redeem >> an authorizatio code/ >> >> 4.4.1.4: "counterfeit a valid client" reads oddly, >> do you mean "pretend to be a valid client"? If so, >> I think that'd be clearer. >> >> 4.4.1.4: "and to prevent unauthorized access to >> them" - I think you might add "via the oauth >> protocol" there since the AS isn't responsible for >> all possible ways of preventing unauthorized access. >> >> 4.4.1.4: typo: s/not neccesserily indicates/doesn't >> necessarily indicate/ >> >> 4.4.1.4: typo: s/user should be explained the purpose/ >> something better/ :-) > > tried my best: > > "In this context, the authorization server should explain to the > end-user the purpose, scope, and duration of the authorization the > client asked for. " > > >> 4.4.1.4: expand/define CAPTCHA on 1st use. Give a >> reference for this too. Especially since you also >> have 5.1.4.2.5, which is maybe the best place for >> the reference. > > Changed counter measure paragraph from: > "If the authorization server automatically authenticates the end- > user, it may nevertheless require some user input in order to > prevent screen scraping. Examples are CAPTCHAs or user-specific > secrets like PIN codes." > to: > "If the authorization server automatically authenticates the end-user, > it may nevertheless require some user input in order to prevent screen > scraping. Examples are CAPTCHAs (Completely Automated Public Turing test > to tell Computers and Humans Apart) or other multi-factor authentication > techniques such as random questions, token code generators, etc." > > >> 4.4.1.4: isn't a PIN code another user authentiation? >> Seems like a bad example of automatic authentication, >> since it isn't automatic if the user has to enter a >> PIN. > > see above >> 4.4.1.6: Is Facebook a trademark? Maybe better to not >> use that if so? > > Changed Facebook reference section to: > (e.g. as in the implementation of "Login" button to a third-party social > network site) > > >> 4.4.1.7: typo: s/achieve that goal/achieves that goal/ >> >> 4.4.1.7: typo: s/victims resources/victim's resources/ >> >> 4.4.1.7: typo: s/The attackers gains/The attacker gains/ >> >> 4.4.1.7: typo: s/then the target web site/rather than >> the target web site/ >> >> 4.4.1.7: "session fixation" could do with a reference >> or definition, and that might be better earlier in >> this section and not just in the countermeasures >> part. > > changed > > "The authorization server may also enforce the usage and validation of > pre-registered redirect URIs (see Section 5.2.3.5). This will allow for > an early recognition of session fixation attempts." > to: > "The authorization server may also enforce the usage and validation of > pre-registered redirect URIs (see Section 5.2.3.5). This will allow for > an early recognition of authorization code disclosure to counterfeit > clients." > > >> 4.4.1.7: typo: s/kind of attacks/kind of attack/ >> >> 4.4.1.8: typo: s/not follow untrusted/to not follow >> untrusted/ >> >> 4.4.1.9: maybe add a reference for "iframe"? And >> you say "iFrames" later, better to be consistent. >> >> 4.4.1.9: 1st countermeasure - do you mean end-user >> authorization here or end-user authentication? And >> would it be better to say "system browser" or >> something rather than "external browser"? (I forget >> what phrase you used for that earlier but there >> was something bettter:-) > > We mean "authorization" > > We came to the conclusion that it does not matter in which browser the > page is loaded - removed 1st bullet > >> 4.4.1.9: "javascript framebusting" really needs >> a reference > added >> 4.4.1.10: typo: s/the victims resources/the victim's >> resources/ >> >> 4.4.1.10: typo: s/or split the/or splits the/ >> >> 4.4.1.10: "corresponding form post requests" isn't >> clear to me - does that need rephrasing or is it >> just me? >> >> 4.4.1.10: this is the first mention of cookies, which >> I found surprising, but that's all;-) >> >> 4.4.1.10: the 2nd "ways to achieve this" bullet is >> a bit unclear - which "It" and whose browser? I >> think this could be clearer. >> >> 4.4.1.10: typo: s/as native app/as a native application/ >> >> 4.4.1.10: what does "assume" the threat mean? >> >> 4.4.1.10: typo: s/an user interaction/a user interaction/ >> >> 4.4.1.10: typo: s/CAPTCAs, or/CAPTCHAs/ or else get >> rid of the "or" from the last bullet >> >> 4.4.1.10: typo: s/send out of bound/sent out of band/ >> >> 4.4.1.10: typo: s/instance message/instant message/ > > considerably re-worded this section > >> 4.4.1.11: typo? s/directing user(s) browser/directing >> the user's browser/ ? >> >> 4.4.1.11: I don't get the explanation here. Are you >> assuming (but not saying) that generating non-trivial >> entropy is a slow process? (e.g. /dev/random blocking?) >> Its also not clear what "pool" you mean? This probably >> needs a bit of tweaking. >> >> 4.4.1.12: semicomplete.com may not be a sufficiently >> stable reference - can't you find a better one? > > unfortunately not >> 4.4.1.12: typo: s/Defenses such rate limiting/Defenses >> such as rate limiting/ >> >> 4.4.1.12: typo: s/an anonymizing systems/an anonymizing >> system/ >> >> 4.4.1.12: nicest typo yet! s/annoying system/anonymizing >> system/ :-) >> >> 4.4.1.12: typo? maybe s/iframe/iFrame/ again? >> >> 4.4.1.12: 1st reference to "the CSRF token" here? That >> might warrant a reference of some sort? (Maybe to >> a later section?) >> >> 4.4.1.12: Facebook again. >> >> 4.4.1.12: Signing the code seems like a bit of a hack. Do >> you really want to recommend this here? I suspect it'd end >> up different if you actually tried it out aiming for an >> interoperable solution. I'd suggest deleting this, or >> maybe make it less specific, e.g. saying if origin >> authentication for authorization codes could be validated >> by clients, then that'd be a countermeasure, but that >> there's no current spec for that. (And doing that might >> just move the DoS to somewhere else depending how you >> did it.) >> >> 4.4.2: typo: s/and It cannot/and it cannot/ >> >> 4.4.2.1: Is the countermeasure here TLS? If so, better to >> say so. >> >> 4.4.2.2: requests aren't cached are they but rather >> responses? >> >> 4.4.2.3: typo: s/An malicious/A malicious/ >> >> 4.4.2.3: The reference back to 4.4.1.4 isn't very >> clear since a lot of the countermeasures there >> mention authentication. It'd be better to explicitly >> list things here or else if you stick with the >> backwards reference to be more explicit about whic >> exactly apply. >> >> 4.4.2.5: Is this entirely identical to 4.4.1.8? That >> doesn't seem right. If it is, then say so explicitly. >> If not, then say what's different. >> >> 4.4.3: 1st mention of username/password anti-pattern, >> so you could add a reference >> >> 4.4.3: Be good to metion here that passwords are often >> used for >1 service, so this anti-pattern risks whatever >> else is accessible with that credential or an >> algorithmically derivable equivalent (e.g. >> joe@example.com/pwd might easily allow someone to guess >> that the same pwd is used forjoe.user@example.net) and >> then another countermeasure is to educate users to >> not use the same pwd for multiple services (hard as >> that is to really do;-) >> >> 4.4.3.4: again digest auth isn't a good example >> here, but client certs are. >> >> 4.4.3.6: What does "Abandon on grant type..." mean? >> If you mean "don't do this" then say that more >> clearly. > > Changed to "Consider not to use grant type "password"" > >> 4.6.2: typo: s/transport security measure/transport >> security measures/ or maybe just say TLS >> >> 4.6.2: typo: s/nounces/nonces/ >> >> 4.6.3: 1st countermeasure: maybe s/difficult/infeasible/ >> I don't see why "difficult" guessing is hard enough? >> >> 4.6.4: typo: s/a valid access tokens/a valid access token/ >> >> 4.6.4: Do you mean the IP address in the 2nd >> countermeasure? I'm not sure, esp. given the above. >> >> 4.6.4: typo: s/miss the capabilities/lack the capability/ >> >> 4.6.6: reference to 2616 is broken >> >> 4.6.6: Should you reference httpbis drafts? Just asking, I >> can see arguments for referencing just 2616 or just >> httpbis or both, given that this'll be read for hopefully >> a while after httpbis is done. >> >> 4.6.7: referrer vs. referer again >> >> 4.6.7: What is an appropriat logging configuration? Can >> you give a reference maybe or is it really that well >> known? >> >> 4.6.7: Reloading the target page again? Are you really >> recommending that? >> >> 5.1: typo: s/consideratios/considerations/ >> >> 5.1.3: I think you should note the email notifications >> can be a phishing vector so don't make your emails >> such that lookalike phish messages can easily be >> derived from them. >> >> 5.1.3: Don't you need to say something about getting >> email notifications delivered and not treated as spam? >> Maybe you could recommend dkim here or other ways to >> get better delivery. (Not sure myself, probably best >> to ask someone who operates like this so see if there's >> stuff to be said.) >> >> 5.1.4.1.3: typo: s/not store credential/not store >> credentials/ >> >> 5.1.4.1.4: salted hashes don't prevent offline >> dictionary attacks, they just increase the workload >> >> 5.1.5.1.4: would it be worthwhile recommending that >> different client credentials be used in development >> or integration mode vs. when operational? I've seen >> a bunch of times when programmers were given "live" >> API keys when that could've been avoided. >> >> 5.1.4.1.5: I don't get this. If it was only that >> easy:-) I think you need to say which private keys >> are used here and for what for this section to be >> useful. >> >> 5.1.4.2.1: I think you could note that complex password >> policies can also increase the liklihood that users >> re-use passwords or write them down or store them >> somewhere not so good, if e.g. the entropy required >> over all the user's passwords (dozens usually) is >> too great for long-term memory. >> >> 5.1.5.1: typo: s/Basis of/The basis of/ >> >> 5.1.5.1: typo: s/sensible service/sensitive service/ >> (2nd best typo:-) >> >> 5.1.5.3: typo: s/preciser/more precise/ >> >> 5.1.5.3: typo: s/refreshments/refreshes/ >> >> 5.1.5.4: 2nd bullet is not a threat but a goal >> >> 5.1.5.4: typo: s/redeem a/redeem an/ >> >> 5.1.5.5: what is a "rough" server? Do you mean rogue? >> >> 5.5.5.6: I think you need to clarify what "address" >> means here too. >> >> 5.1.5.9: please clarify if you mean digitally signed >> (asymmetric) or also include MACing here >> >> 5.1.5.10: typo: s/Self-contained/Self-contained tokens/ >> >> 5.1.5.10: s/privacy/confidentiality/ ? >> >> 5.1.5.10: this (typically, I'd guess) requires sharing >> symmetric keys between server nodes, so you should >> say that as its a bunch of work. >> >> 5.1.5.11: I don't get why you want to repeat this >> text (and its error:-) better to refer back to >> the earlier section I think. >> >> 5.1.5.12: Another place where a SAML reference would >> be needed. >> >> 5.1.6: 2nd bullet is not a "measure" but a goal. If >> you had something in mind, it doesn't come out from >> that text. >> >> 5.2.2.2: You say the binding should be protected, but >> don't say how. I think you ought. >> >> 5.2.3: typo: s/sub-sequent/subsequent/ but maybe >> better to delete the word >> >> 5.2.3: 2nd bullet - "trustworthiness" has gotta >> be the wrong word there, what did you mean? >> >> 5.2.3: typo: s/statics/statistics/ >> >> 5.2.3: typo: s/support achieve objectives/achieve these >> objectives/ ? >> >> 5.2.3: typo: s/by hand of an administrator/something >> better/ >> >> 5.2.3.1: "prevents...overestimating" seems wrong, I think >> you mean it reduces the probability of mistakenly treating >> a useless authentication as a good one. (The point is >> that servers don't "overestimate," only people do that.) >> >> 5.2.3.1: "cannot be entirely protected" seems like >> understatement - the reality is any such secret will >> leak out from anything that's any way successful. It >> only protects stuff that *nobody* cares about. >> >> 5.2.3.1: typo: s/trust on/trust/ But I'd rephrase it >> to not use the terms "trust" nor "identity" and then >> it'd be better I think. >> >> 5.2.3.2: typo? s/The authorization may/The authrozation >> server may/ ? Not sure what "issue a cliend id" means >> either. (Same in 5.2.3.3) >> >> 5.2.3.4: typo: s/A authorization server/An authorization >> server/ >> >> 5.2.3.5: what are "validated properties"? >> >> 5.2.3.5: what is the 1st bullet list on p57? there's >> no introductory text? >> >> 5.2.3.5: the "it" in "it only works" in the last >> paragraph isn't clear - which "it" do you mean? >> >> 5.2.3.5: saying discovery "gets involved" seems >> wrong - do you mean "is used"? And what is the >> "that" in "that's no longer feasible"? >> >> 5.2.3.6: typo: s/be unintentionally for/unintentionally >> affect/? >> >> 5.2.3.7: typo: s/to distribute client_secret/to >> distribute a client_secret/ >> >> 5.2.4.1: Is a "security certificate" a public key >> certificate? If so, saying that is better. >> >> 5.2.4.1: the references to 5.7.2.x are wrong and >> look like you're missing some xref's in the xml >> maybe >> >> 5.2.4.2: you said "address" again, so the usual >> question arises :-) >> >> 5.2.4.3: typo: s/in all situation/in situations/ >> (not sure "all" is right so suggest deleting it) >> >> 5.2.4.4: again, be good to say how to protect >> the binding >> >> 5.2.4.5: as for 5.2.4.4 say how binding is done >> >> 5.3.1: typo: s/a associated/an associated/ >> >> 5.3.1: "entirely protected" is (again:-) understatement >> see above for a suggestion >> >> 5.3.1: what does "trust on the client's identity" mean? >> Its not clear anyway >> >> 5.3.3: typo: s/operation systems/operating systems/ >> (enrire 2nd & 3rd paras could do with re-phrasing) >> >> 5.3.4: typo: s/their level/the level/ >> >> 5.3.5: this is too terse - is it really finished? I'd >> say there's a sentence or two missing. >> >> 5.4.2: what does it mean to "encourage resource >> servers" to do something? I guess you mean to encourage >> the people deploying those to pick resource servers >> with that capability and to turn that on. >> >> 5.4.2: not sure if everyone will know what a >> "distinguished name" is, maybe add a reference to >> rfc 5280? >> >> 5.4.2: token-bound secrets would be used to MAC >> the request and not to sign, be better to make that >> clear even if you still call that "signing" here >> (its not really, if we're being pedantic) >> >> 5.4.2: typo: s/This mechanisms/This mechanism/ >> >> 5.4.2 and 5.4.3: I forget - where are the protocol >> mechanisms for this defined? Can you give a reference >> or say that its future stuff if there aren't any >> good ones? >> >> 5.5: typo: s/capable to validate/capable of validating/ >> >> 8.1: Is the base spec really normative? I'd say you're >> fine with that as informative too. >> >> 8.2: there are a bunch of references missing as per >> the questions above >> >> 8.2: is there no better (more stable) reference than >> portablecontacts.net? >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > From phil.hunt@oracle.com Wed Jun 27 20:22:25 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7668221F871E for ; Wed, 27 Jun 2012 20:22:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.003 X-Spam-Level: X-Spam-Status: No, score=-8.003 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_43=0.6, J_CHICKENPOX_52=0.6, MIME_QP_LONG_LINE=1.396, 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 oj-6pfaXBUNU for ; Wed, 27 Jun 2012 20:22:23 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id B717621F871D for ; Wed, 27 Jun 2012 20:22:22 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q5S3M5eu017669 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 28 Jun 2012 03:22:05 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q5S3M24E005402 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Jun 2012 03:22:03 GMT Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q5S3M0ik023698; Wed, 27 Jun 2012 22:22:01 -0500 Received: from [25.36.28.229] (/74.198.164.229) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 27 Jun 2012 20:21:59 -0700 References: <4FC3C53E.8020704@cs.tcd.ie> <4FEB4B0C.2030700@lodderstedt.net> <4FEBA286.6020003@cs.tcd.ie> In-Reply-To: <4FEBA286.6020003@cs.tcd.ie> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (9B206) From: Phil Hunt Date: Wed, 27 Jun 2012 20:21:54 -0700 To: Stephen Farrell X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: Derek Atkins , "oauth@ietf.org" , Barry Leiba Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-threatmodel-05 X-BeenThere: oauth@ietf.org X-Mailman-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, 28 Jun 2012 03:22:25 -0000 Stephen One more threat has come up in the core spec that is being looked at. As Tor= sten is heading out on vacation I have agreed to augment if needed with any s= upplementary text to the threat model. Will keep you informed.=20 Phil On 2012-06-27, at 17:17, Stephen Farrell wrote: >=20 > Hiya, >=20 > Great. I've asked for IETF LC to start. I'll go through > the changes below during that in case there's some more > follow up. >=20 > Thanks, > S. >=20 > On 06/27/2012 07:03 PM, Torsten Lodderstedt wrote: >> Hi Stephen, >>=20 >> I just submitted a new revision of the security document incorporating >> your review comments. >>=20 >> Please find answers to your comments below. >>=20 >> Thank you again for your detailed review. You helped us to significantly >> improve the document's quality. >>=20 >> best regards, >> Torsten. >>=20 >> Am 28.05.2012 20:34, schrieb Stephen Farrell: >>> Hi all, >>>=20 >>> I've gotten the publication request for oauth-threatmodel >>> so here's my AD review of -05. >>>=20 >>> Its quite a read (and a good one) but I've a bunch of >>> questions. Some of these will need fixing I suspect >>> but a lot are ok to fix later after IETF LC, depending >>> on whether the authors want to re-spin it before then >>> or not. But I'd like to at least see reactions to the >>> questions before I start IETF LC. >>>=20 >>> Although there are many many nits and typos, those >>> don't actually make the document unreadable so >>> though I'd prefer to see 'em fixed now, I'm ok with >>> that happening later if its a problem to get it >>> all done now. >>>=20 >>> If you want to argue for going ahead with IETF LC >>> now please do so, but I suspect that this might need >>> a revised ID to fix at least a couple of the points >>> raised below. If nobody does argue to go ahead now, >>> I'll mark it as revised ID needed, but first let's >>> see what the answers are to the questions. >>>=20 >>> Cheers, >>> S. >>>=20 >>>=20 >>> (1) s/RFC1750/RFC4086/ is needed as noted in the write-up. >> done >>> (2) You don't say anything about the probability of >>> occurrence of the various threats. I realise that you >>> can't be precise but it seems wrong to say nothing. Would >>> it be worth at least saying that that's not done here and >>> that readers of this document need to do their own risk >>> analysis including that aspect? >>=20 >> That's correct - I added the following paragraph to the introduction: >>=20 >> "Note: This document cannot assess the probability nor the risk >> associated with a particular threat because those aspects strongly >> depend on the particular application and deployment OAuth is used to >> protect. Similar, impacts are given on a rather abstract level. But the >> information given here may serve as a foundation for deployment-specific >> threat models. Implementors may refine and detail the abstract threat >> model in order to account for the specific properties of their >> deployment and to come up with a risk analysis." >>=20 >>> (3) Many deployments will use TLS accelerators. That >>> means that TLS isn't fully e2e, and that opens up some >>> (mainly) insider attacks or attacks that can be launched >>> from within a compromised DMZ, but from outside the server >>> applications. Does that need a mention somewhere? (I've >>> seen systems like that deployed and a lot could go wrong >>> from the inside, so I think this is a real threat.) >>=20 >> I added another paragraph to section 5.1.1: >>=20 >> "Note: this document assumes end-to-end TLS protected connections >> between the respective protocol entities. Deployments deviating from >> this assumption by offloading TLS in between (e.g. on the data center >> edge) must refine this threat model in order to account for the >> additional (mainly insider) threat this may cause." >>=20 >>> (4) Could you use just one of "client identity" or "client >>> identifier" consistently? I'd much prefer the latter, >>> which has also been the outcome of various discussions on >>> this topic elsewhere. For example you say "revocation of >>> such an identity" at the end of p13, and that's a >>> potential rathole, better to say "revocation of the rights >>> associated with a client identifier" or similar I think. >>> And similar changes throughout. >>=20 >> Replaced client identity by client identifier in most places and >> incorporated your proposed text >>=20 >>> (5) 4.4.2.2: Here you recommend native applications should >>> use an embedded browser, but earlier you said that was a >>> bad idea. I think you need to be consistent or else >>> provide more about when its ok to embed and when its not. >>> Did I misread it or does that need a change? >>=20 >> removed 3rd bullet as native apps should use code flow >>=20 >> We also removed the 1st bullet in 4.4.1.9 >>=20 >>> (6) 4.4.3.1: This calls for "obfuscation" of passwords in >>> logs. I think you ought be stronger there and call for >>> strong encryption of passwords wherever they are stored, >>> be that logs or DBs or whatever. Would'nt that be reasonable? >>=20 >> This section is about preventing accidential exposure by the client. I >> think encryption is not appropriate here since the password is entered >> in the clear by the user. I added the advice to encrypt credentials as >> alternative means to salted hashes to 5.1.4.1.3. >>=20 >>> (7) 4.6.4: 1st countermeasure: I don't think you mean >>> address here (in the sense of an IP address, which is what >>> that means) but rather the domain name or FQDN or URL. In >>> any case, you need to say what is meant clearly. (Also in >>> 5.1.5.6 and elsewhere when you use the term "address".) >>=20 >> replaced address in most cases by URL and in some place by FDQN >>=20 >>> (8) 4.6.6: You say to use Cache-Control, but don't say >>> how. Is more needed really? Maybe there's a good document >>> you could reference for that? (I'm not suggesting you add >>> a lecture on caching btw:-) >>=20 >> Added text from core spec describing usage of Cache-Control and Pragma >> response header fields >>=20 >>> (9) 5.1.1: needs a reference to RFC 5246 (and better to >>> just say TLS and not say SSL, at least for me :-) >>=20 >> done >>> (10) 5.1.1: needs a reference to whatever you mean by >>> "VPN" since there are many types of VPN. I assume you mean >>> an IPsec VPN? But even if not, saying more would be good. >>=20 >> Extended description and added reference to RFC 4301. >>> (11) 5.1.2: needs a reference to RFC 5280 and/or RFC 6125 >>> and/or RFC 2818. Bascially, you need to say how this is >>> done (by reference). >>=20 >> Added reference to RFC 2818 since it seems to be closest to the problem >>=20 >>> (12) 5.1.4.1: Isn't there some good reference you can give >>> here? (Having said that, I'd have to go look myself, but >>> I'd maybe start with owasp or sans.) >>=20 >> added reference to OWASP >>=20 >>> (13) 5.1.4.2.2: if p(collision) should be <=3D2^(-160) then >>> what's the point of saying it ought be <=3D 2^(-128)? Also >>> if sha-1 were perfect, then the 160 bits output would >>> really have a collision probability of about 2^(-80) with >>> many many tokens, but not 2^(-160). I think you need >>> to fix something there. Perhaps you're really saying that >>> all high-entropy secrets should be >=3D128 bits long and >>> constructed with a good (P)RNG? If so, saying so more >>> clearly would be better. Not everyone will get the >>> collision probability way of saying that even when its >>> properly stated. (This text is also repeated, be better if >>> you just said this once I think.) >>=20 >> modified text as follows >>=20 >> "When creating secrets not intended for usage by human users (e.g. >> client secrets or token handles), the authorization server should >> include a reasonable level of entropy in order to mitigate the risk of >> guessing attacks. The token value should be >=3D128 bits long and >> constructed from a cryptographically strong random or pseudo-random >> number sequence (see [RFC4086] for best current practice) generated by >> the Authorization Server." >>=20 >> removed 5.1.5.11. (redundant text) and updated references accordingly >>=20 >>> (14) 5.1.5.2: what is a "reasonable duration" - I don't >>> think its ok to say that but nothing else. Can't you give >>> some "reasonable" examples based on current usage? >>=20 >> added examples and explanation of factors determining reasonable >> expiration time >>=20 >> "Tokens should generally expire after a reasonable duration. This >> complements and strengthens other security measures (such as signatures) >> and reduces the impact of all kinds of token leaks. Depending on the >> risk associated with a token leakage, tokens may expire after a few >> minutes (e.g. for payment transactions) or stay valid for hours (e.g. >> read access to contacts). >>=20 >> The expiration time is determined by a couple of factors, including: >>=20 >> - risk associated to a token leakage >> - duration of the underlying access grant, >> - duration until the modification of an access grant should take effect, >> and >> - time required for an attacker to guess or produce valid token." >>=20 >>> (15) 5.1.5.5: needs a reference to SAML assertions with >>> the current text. >>=20 >> done - also added reference to RFC4120 in section 3.1 >>> (16) 5.2.2.3: this describes a refresh token rotation >>> scheme that I don't recall being discussed on the list, so >>> this is just to check that that rotation scheme, as >>> described, doesn't ring any alarms bells for the WG. If >>> not, that's fine. And if it was discussed on the list and >>> I've forgotten, then sorry about that:-) >>=20 >> It has been discussed, the first time with the introduction of the >> option to return a new referesh token value in response to a refresh >> token grant request. A more recent discussion can be found here: >> http://www.ietf.org/mail-archive/web/oauth/current/msg06974.html >>=20 >>> (17) 5.2.2.5: Using IMEI's like this has privacy >>> implications that I think you ought call out. A single >>> sentence and a reference to something that says "be >>> careful about privacy here" would be fine I'd say. (And >>> you need a reference for "IMEI" and to expand the term.) >>=20 >> added note and reference to respective 3gpp spec >>=20 >>> (18) 5.2.2.6: needs a reference for X-FRAME-OPTION. >>> There's a websec draft about that I think. >>=20 >> added reference to >> http://tools.ietf.org/html/draft-gondrom-x-frame-options/ >>> (19) 5.2.3.4: what do you mean when you say "for different >>> deployments of a client"? That could be one secret per >>> install or one secret for all customers of a mobile >>> operator and those are radically different. I think you >>> need to be clear and hope you mean the former. That's >>> almost cleared up in the 3rd paragraph of the section but >>> I wanted to just check. Not sure "deployment" is the best >>> term there really - what's wrong with "installation"? >>=20 >> nothing is wrong with "installation" :-) >>=20 >> replaced deployment by installation and partially re-phrased section >>=20 >>> (many:-) nits and typos: >>>=20 >>> 2.3.1: maybe explain "handle-based design" or give a >>> reference? (Or maybe just a forward ref to 3.1?) >>=20 >> added ref to 3.1 >>> 2.3.3: It might be worth re-iterating that the term >>> "client" in oauth is used differently, e.g. by copying a >>> bit of text from the base spec. I can see folks being >>> confused by this otherwise. >>=20 >> copied a sentence from base spec and extended description >>=20 >>> 3.1: "is digitally signed" - do you mean it has data >>> integrity and origin authentication? If MACs are commonly >>> used (or maybe authenticated encryption), and not >>> necessarily signatures, then saying that would be better. >>=20 >> we mean data integrity and origin authentication - added some text to >> explain this >>=20 >>> 3.1.2: typo: s/this mechanisms/this mechanism/ >>>=20 >>> 3.1.2: maybe s/Expires_In/expires_in/ to match the case in >>> the base spec? I think it'd be better not to capitalise >>> this in case it finds its way into someone's code. You >>> could also use "Expires In" in the title and then say that >>> its "expires_in" in the protocol. Might be worth doing >>> something generic to call out when you're talking about >>> specific things from the protocol, e.g. use a convention >>> like ``expires_in'' or "expires_in" consistently and say >>> that in the intro. >>=20 >> Renamed section to "Limited access token limetime" and changed wording >> to explicitely distinct between concept and protocol parameter. >>=20 >>> 3.4: typo: s/the later/the latter/ >>>=20 >>> 3.4: bullet item 1 isn't really a reason for anything but >>> a downside of doing this, at least as written. Maybe this >>> needs to be tweaked? >>=20 >> tweaked it >>> 3.6: expand CSRF on 1st use and maybe give a reference >>> CSRF is expanded in 4.4.1.8 which is a good bit later, >>> and also in 4.4.2.5 which could presumably be >>> shortened a bit by removing the repetition. >>=20 >> expanded CSRF a bit, added forward reference to 4.4.1.8 and shortened >> 4.4.2.5 >>=20 >>> 3.7: typo: s/collage associated request/collate associated >>> requests/ >>>=20 >>> 3.7: Maybe give a pointer to the definition of "native >>> application" in the base spec (Its section 9 of that.) >>> 2nd last para of p13 would be a good place for that. >>=20 >> added pointer >>=20 >>> section 4: maybe s/Security Threat Model/Threat Model/ >>> in the section title - what other kind of threat >>> model is there? >>=20 >> changed to Threat Model >>=20 >>> section 4: I wondered how we know the threat model >>> is "comprehensive"? Perhaps "detailed" is better? >>=20 >> We are rather confident because we created the threat model a systematic >> way and had it reviewed by a lot of security folks >>=20 >>> 4.2.1: typo: s/Users/users/g unless you mean something >>> special? >>>=20 >>> 4.2.2: typo: s/a understandable/an understandable/ >>>=20 >>> 4.2.2: "...based on who the client is." is unclear >>> and not gramatically nice:-) "...based on the client >>> identifier." would seem better. >>>=20 >>> 4.3.1: typo? s/on transit/in transit/ Or did you >>> mean something else? and s/may attempts/may attempt/ >>>=20 >>> 4.3.3: maybe s/Revelation/Disclosure/ to be a tad >>> less biblical:-) >>=20 >> changed to "Revelation of client credentials during transmission" >>=20 >>> 4.3.3: typo? 1st countermeasure reads oddly and >>> refers to a different place than other references >>> to TLS - is that correct? >>=20 >> changed to standard wording >>=20 >>> 4.3.3: digest auth is nearly the same as sending >>> credentials over the wire, TLS client auth based >>> on certificates would be a better example, even >>> if its not often done. >>=20 >> Isn't TLS client authentication always combined with TLS protected >> communication? So this would merly be an additional and not alternative >> mechanism. >>=20 >>> 4.3.4: 4.3.2 points to 5.1.4.1.2 but this doesn't. >>> Maybe it ought to? >>=20 >> Sorry, don't understand this comment. Are you saying 5.1.4.1.2 should >> point back to 4.3.2? >>=20 >>> 4.3.6: typo s/an authorization servers/an authorization >>> server/ >>>=20 >>> 4.3.6: 4.3.5 refers to 5.1.4.2.2 wrt entropy. Is there >>> a reason to not do that here too? >>=20 >> this section discussed a potential threat on dynamic client >> registration. Wen decided to remove the whole section as dynamic client >> registration is subject of current charter and respective security >> considerations should delt with in this context. >>=20 >>> 4.4: typo? s/tokens endpoint/token endpoint/ ? >>>=20 >>> 4.4.1.1: typo: s/by different ways/in different ways/ >>>=20 >>> 4.4.1.1: typo-fix-typo? HTTP has a "Referer" header field, >>> but you fixed their typo here - might be better to live >>> with the bad spelling, in which case >>> s/referrer/referer/g;-) >>=20 >> ok :-) >>=20 >>> 4.4.1.1: Is there no better way to reference these >>> OASIS docs? More importantly, is there no better (more >>> stable) reference than thomasgross.net for the >>> PDF you reference? Tidying this up would be good. >>=20 >> added references to OASIS documents and stable reference to 3rd document >> in proceedings of Computer Security Applications Conference >>=20 >>> 4.4.1.1 and elsewhere: a few times you say "such as >>> TLS or SSL," I think it'd be better to just say TLS >>> there and do it consistently everwhere. In other >>> places (e.g. 4.4.1.5) you say "HTTPS" - again that'd >>> be better done consistently. >>=20 >> removed SSL - would you expect us to replace HTTPS by TLS? We used HTTPS >> for the more specific case of HTTP+TLS >>=20 >>> 4.4.1.1: typo: s/redeem a authorization code/redeem >>> an authorizatio code/ >>>=20 >>> 4.4.1.4: "counterfeit a valid client" reads oddly, >>> do you mean "pretend to be a valid client"? If so, >>> I think that'd be clearer. >>>=20 >>> 4.4.1.4: "and to prevent unauthorized access to >>> them" - I think you might add "via the oauth >>> protocol" there since the AS isn't responsible for >>> all possible ways of preventing unauthorized access. >>>=20 >>> 4.4.1.4: typo: s/not neccesserily indicates/doesn't >>> necessarily indicate/ >>>=20 >>> 4.4.1.4: typo: s/user should be explained the purpose/ >>> something better/ :-) >>=20 >> tried my best: >>=20 >> "In this context, the authorization server should explain to the >> end-user the purpose, scope, and duration of the authorization the >> client asked for. " >>=20 >>=20 >>> 4.4.1.4: expand/define CAPTCHA on 1st use. Give a >>> reference for this too. Especially since you also >>> have 5.1.4.2.5, which is maybe the best place for >>> the reference. >>=20 >> Changed counter measure paragraph from: >> "If the authorization server automatically authenticates the end- >> user, it may nevertheless require some user input in order to >> prevent screen scraping. Examples are CAPTCHAs or user-specific >> secrets like PIN codes." >> to: >> "If the authorization server automatically authenticates the end-user, >> it may nevertheless require some user input in order to prevent screen >> scraping. Examples are CAPTCHAs (Completely Automated Public Turing test >> to tell Computers and Humans Apart) or other multi-factor authentication >> techniques such as random questions, token code generators, etc." >>=20 >>=20 >>> 4.4.1.4: isn't a PIN code another user authentiation? >>> Seems like a bad example of automatic authentication, >>> since it isn't automatic if the user has to enter a >>> PIN. >>=20 >> see above >>> 4.4.1.6: Is Facebook a trademark? Maybe better to not >>> use that if so? >>=20 >> Changed Facebook reference section to: >> (e.g. as in the implementation of "Login" button to a third-party social >> network site) >>=20 >>=20 >>> 4.4.1.7: typo: s/achieve that goal/achieves that goal/ >>>=20 >>> 4.4.1.7: typo: s/victims resources/victim's resources/ >>>=20 >>> 4.4.1.7: typo: s/The attackers gains/The attacker gains/ >>>=20 >>> 4.4.1.7: typo: s/then the target web site/rather than >>> the target web site/ >>>=20 >>> 4.4.1.7: "session fixation" could do with a reference >>> or definition, and that might be better earlier in >>> this section and not just in the countermeasures >>> part. >>=20 >> changed >>=20 >> "The authorization server may also enforce the usage and validation of >> pre-registered redirect URIs (see Section 5.2.3.5). This will allow for >> an early recognition of session fixation attempts." >> to: >> "The authorization server may also enforce the usage and validation of >> pre-registered redirect URIs (see Section 5.2.3.5). This will allow for >> an early recognition of authorization code disclosure to counterfeit >> clients." >>=20 >>=20 >>> 4.4.1.7: typo: s/kind of attacks/kind of attack/ >>>=20 >>> 4.4.1.8: typo: s/not follow untrusted/to not follow >>> untrusted/ >>>=20 >>> 4.4.1.9: maybe add a reference for "iframe"? And >>> you say "iFrames" later, better to be consistent. >>>=20 >>> 4.4.1.9: 1st countermeasure - do you mean end-user >>> authorization here or end-user authentication? And >>> would it be better to say "system browser" or >>> something rather than "external browser"? (I forget >>> what phrase you used for that earlier but there >>> was something bettter:-) >>=20 >> We mean "authorization" >>=20 >> We came to the conclusion that it does not matter in which browser the >> page is loaded - removed 1st bullet >>=20 >>> 4.4.1.9: "javascript framebusting" really needs >>> a reference >> added >>> 4.4.1.10: typo: s/the victims resources/the victim's >>> resources/ >>>=20 >>> 4.4.1.10: typo: s/or split the/or splits the/ >>>=20 >>> 4.4.1.10: "corresponding form post requests" isn't >>> clear to me - does that need rephrasing or is it >>> just me? >>>=20 >>> 4.4.1.10: this is the first mention of cookies, which >>> I found surprising, but that's all;-) >>>=20 >>> 4.4.1.10: the 2nd "ways to achieve this" bullet is >>> a bit unclear - which "It" and whose browser? I >>> think this could be clearer. >>>=20 >>> 4.4.1.10: typo: s/as native app/as a native application/ >>>=20 >>> 4.4.1.10: what does "assume" the threat mean? >>>=20 >>> 4.4.1.10: typo: s/an user interaction/a user interaction/ >>>=20 >>> 4.4.1.10: typo: s/CAPTCAs, or/CAPTCHAs/ or else get >>> rid of the "or" from the last bullet >>>=20 >>> 4.4.1.10: typo: s/send out of bound/sent out of band/ >>>=20 >>> 4.4.1.10: typo: s/instance message/instant message/ >>=20 >> considerably re-worded this section >>=20 >>> 4.4.1.11: typo? s/directing user(s) browser/directing >>> the user's browser/ ? >>>=20 >>> 4.4.1.11: I don't get the explanation here. Are you >>> assuming (but not saying) that generating non-trivial >>> entropy is a slow process? (e.g. /dev/random blocking?) >>> Its also not clear what "pool" you mean? This probably >>> needs a bit of tweaking. >>>=20 >>> 4.4.1.12: semicomplete.com may not be a sufficiently >>> stable reference - can't you find a better one? >>=20 >> unfortunately not >>> 4.4.1.12: typo: s/Defenses such rate limiting/Defenses >>> such as rate limiting/ >>>=20 >>> 4.4.1.12: typo: s/an anonymizing systems/an anonymizing >>> system/ >>>=20 >>> 4.4.1.12: nicest typo yet! s/annoying system/anonymizing >>> system/ :-) >>>=20 >>> 4.4.1.12: typo? maybe s/iframe/iFrame/ again? >>>=20 >>> 4.4.1.12: 1st reference to "the CSRF token" here? That >>> might warrant a reference of some sort? (Maybe to >>> a later section?) >>>=20 >>> 4.4.1.12: Facebook again. >>>=20 >>> 4.4.1.12: Signing the code seems like a bit of a hack. Do >>> you really want to recommend this here? I suspect it'd end >>> up different if you actually tried it out aiming for an >>> interoperable solution. I'd suggest deleting this, or >>> maybe make it less specific, e.g. saying if origin >>> authentication for authorization codes could be validated >>> by clients, then that'd be a countermeasure, but that >>> there's no current spec for that. (And doing that might >>> just move the DoS to somewhere else depending how you >>> did it.) >>>=20 >>> 4.4.2: typo: s/and It cannot/and it cannot/ >>>=20 >>> 4.4.2.1: Is the countermeasure here TLS? If so, better to >>> say so. >>>=20 >>> 4.4.2.2: requests aren't cached are they but rather >>> responses? >>>=20 >>> 4.4.2.3: typo: s/An malicious/A malicious/ >>>=20 >>> 4.4.2.3: The reference back to 4.4.1.4 isn't very >>> clear since a lot of the countermeasures there >>> mention authentication. It'd be better to explicitly >>> list things here or else if you stick with the >>> backwards reference to be more explicit about whic >>> exactly apply. >>>=20 >>> 4.4.2.5: Is this entirely identical to 4.4.1.8? That >>> doesn't seem right. If it is, then say so explicitly. >>> If not, then say what's different. >>>=20 >>> 4.4.3: 1st mention of username/password anti-pattern, >>> so you could add a reference >>>=20 >>> 4.4.3: Be good to metion here that passwords are often >>> used for >1 service, so this anti-pattern risks whatever >>> else is accessible with that credential or an >>> algorithmically derivable equivalent (e.g. >>> joe@example.com/pwd might easily allow someone to guess >>> that the same pwd is used forjoe.user@example.net) and >>> then another countermeasure is to educate users to >>> not use the same pwd for multiple services (hard as >>> that is to really do;-) >>>=20 >>> 4.4.3.4: again digest auth isn't a good example >>> here, but client certs are. >>>=20 >>> 4.4.3.6: What does "Abandon on grant type..." mean? >>> If you mean "don't do this" then say that more >>> clearly. >>=20 >> Changed to "Consider not to use grant type "password"" >>=20 >>> 4.6.2: typo: s/transport security measure/transport >>> security measures/ or maybe just say TLS >>>=20 >>> 4.6.2: typo: s/nounces/nonces/ >>>=20 >>> 4.6.3: 1st countermeasure: maybe s/difficult/infeasible/ >>> I don't see why "difficult" guessing is hard enough? >>>=20 >>> 4.6.4: typo: s/a valid access tokens/a valid access token/ >>>=20 >>> 4.6.4: Do you mean the IP address in the 2nd >>> countermeasure? I'm not sure, esp. given the above. >>>=20 >>> 4.6.4: typo: s/miss the capabilities/lack the capability/ >>>=20 >>> 4.6.6: reference to 2616 is broken >>>=20 >>> 4.6.6: Should you reference httpbis drafts? Just asking, I >>> can see arguments for referencing just 2616 or just >>> httpbis or both, given that this'll be read for hopefully >>> a while after httpbis is done. >>>=20 >>> 4.6.7: referrer vs. referer again >>>=20 >>> 4.6.7: What is an appropriat logging configuration? Can >>> you give a reference maybe or is it really that well >>> known? >>>=20 >>> 4.6.7: Reloading the target page again? Are you really >>> recommending that? >>>=20 >>> 5.1: typo: s/consideratios/considerations/ >>>=20 >>> 5.1.3: I think you should note the email notifications >>> can be a phishing vector so don't make your emails >>> such that lookalike phish messages can easily be >>> derived from them. >>>=20 >>> 5.1.3: Don't you need to say something about getting >>> email notifications delivered and not treated as spam? >>> Maybe you could recommend dkim here or other ways to >>> get better delivery. (Not sure myself, probably best >>> to ask someone who operates like this so see if there's >>> stuff to be said.) >>>=20 >>> 5.1.4.1.3: typo: s/not store credential/not store >>> credentials/ >>>=20 >>> 5.1.4.1.4: salted hashes don't prevent offline >>> dictionary attacks, they just increase the workload >>>=20 >>> 5.1.5.1.4: would it be worthwhile recommending that >>> different client credentials be used in development >>> or integration mode vs. when operational? I've seen >>> a bunch of times when programmers were given "live" >>> API keys when that could've been avoided. >>>=20 >>> 5.1.4.1.5: I don't get this. If it was only that >>> easy:-) I think you need to say which private keys >>> are used here and for what for this section to be >>> useful. >>>=20 >>> 5.1.4.2.1: I think you could note that complex password >>> policies can also increase the liklihood that users >>> re-use passwords or write them down or store them >>> somewhere not so good, if e.g. the entropy required >>> over all the user's passwords (dozens usually) is >>> too great for long-term memory. >>>=20 >>> 5.1.5.1: typo: s/Basis of/The basis of/ >>>=20 >>> 5.1.5.1: typo: s/sensible service/sensitive service/ >>> (2nd best typo:-) >>>=20 >>> 5.1.5.3: typo: s/preciser/more precise/ >>>=20 >>> 5.1.5.3: typo: s/refreshments/refreshes/ >>>=20 >>> 5.1.5.4: 2nd bullet is not a threat but a goal >>>=20 >>> 5.1.5.4: typo: s/redeem a/redeem an/ >>>=20 >>> 5.1.5.5: what is a "rough" server? Do you mean rogue? >>>=20 >>> 5.5.5.6: I think you need to clarify what "address" >>> means here too. >>>=20 >>> 5.1.5.9: please clarify if you mean digitally signed >>> (asymmetric) or also include MACing here >>>=20 >>> 5.1.5.10: typo: s/Self-contained/Self-contained tokens/ >>>=20 >>> 5.1.5.10: s/privacy/confidentiality/ ? >>>=20 >>> 5.1.5.10: this (typically, I'd guess) requires sharing >>> symmetric keys between server nodes, so you should >>> say that as its a bunch of work. >>>=20 >>> 5.1.5.11: I don't get why you want to repeat this >>> text (and its error:-) better to refer back to >>> the earlier section I think. >>>=20 >>> 5.1.5.12: Another place where a SAML reference would >>> be needed. >>>=20 >>> 5.1.6: 2nd bullet is not a "measure" but a goal. If >>> you had something in mind, it doesn't come out from >>> that text. >>>=20 >>> 5.2.2.2: You say the binding should be protected, but >>> don't say how. I think you ought. >>>=20 >>> 5.2.3: typo: s/sub-sequent/subsequent/ but maybe >>> better to delete the word >>>=20 >>> 5.2.3: 2nd bullet - "trustworthiness" has gotta >>> be the wrong word there, what did you mean? >>>=20 >>> 5.2.3: typo: s/statics/statistics/ >>>=20 >>> 5.2.3: typo: s/support achieve objectives/achieve these >>> objectives/ ? >>>=20 >>> 5.2.3: typo: s/by hand of an administrator/something >>> better/ >>>=20 >>> 5.2.3.1: "prevents...overestimating" seems wrong, I think >>> you mean it reduces the probability of mistakenly treating >>> a useless authentication as a good one. (The point is >>> that servers don't "overestimate," only people do that.) >>>=20 >>> 5.2.3.1: "cannot be entirely protected" seems like >>> understatement - the reality is any such secret will >>> leak out from anything that's any way successful. It >>> only protects stuff that *nobody* cares about. >>>=20 >>> 5.2.3.1: typo: s/trust on/trust/ But I'd rephrase it >>> to not use the terms "trust" nor "identity" and then >>> it'd be better I think. >>>=20 >>> 5.2.3.2: typo? s/The authorization may/The authrozation >>> server may/ ? Not sure what "issue a cliend id" means >>> either. (Same in 5.2.3.3) >>>=20 >>> 5.2.3.4: typo: s/A authorization server/An authorization >>> server/ >>>=20 >>> 5.2.3.5: what are "validated properties"? >>>=20 >>> 5.2.3.5: what is the 1st bullet list on p57? there's >>> no introductory text? >>>=20 >>> 5.2.3.5: the "it" in "it only works" in the last >>> paragraph isn't clear - which "it" do you mean? >>>=20 >>> 5.2.3.5: saying discovery "gets involved" seems >>> wrong - do you mean "is used"? And what is the >>> "that" in "that's no longer feasible"? >>>=20 >>> 5.2.3.6: typo: s/be unintentionally for/unintentionally >>> affect/? >>>=20 >>> 5.2.3.7: typo: s/to distribute client_secret/to >>> distribute a client_secret/ >>>=20 >>> 5.2.4.1: Is a "security certificate" a public key >>> certificate? If so, saying that is better. >>>=20 >>> 5.2.4.1: the references to 5.7.2.x are wrong and >>> look like you're missing some xref's in the xml >>> maybe >>>=20 >>> 5.2.4.2: you said "address" again, so the usual >>> question arises :-) >>>=20 >>> 5.2.4.3: typo: s/in all situation/in situations/ >>> (not sure "all" is right so suggest deleting it) >>>=20 >>> 5.2.4.4: again, be good to say how to protect >>> the binding >>>=20 >>> 5.2.4.5: as for 5.2.4.4 say how binding is done >>>=20 >>> 5.3.1: typo: s/a associated/an associated/ >>>=20 >>> 5.3.1: "entirely protected" is (again:-) understatement >>> see above for a suggestion >>>=20 >>> 5.3.1: what does "trust on the client's identity" mean? >>> Its not clear anyway >>>=20 >>> 5.3.3: typo: s/operation systems/operating systems/ >>> (enrire 2nd & 3rd paras could do with re-phrasing) >>>=20 >>> 5.3.4: typo: s/their level/the level/ >>>=20 >>> 5.3.5: this is too terse - is it really finished? I'd >>> say there's a sentence or two missing. >>>=20 >>> 5.4.2: what does it mean to "encourage resource >>> servers" to do something? I guess you mean to encourage >>> the people deploying those to pick resource servers >>> with that capability and to turn that on. >>>=20 >>> 5.4.2: not sure if everyone will know what a >>> "distinguished name" is, maybe add a reference to >>> rfc 5280? >>>=20 >>> 5.4.2: token-bound secrets would be used to MAC >>> the request and not to sign, be better to make that >>> clear even if you still call that "signing" here >>> (its not really, if we're being pedantic) >>>=20 >>> 5.4.2: typo: s/This mechanisms/This mechanism/ >>>=20 >>> 5.4.2 and 5.4.3: I forget - where are the protocol >>> mechanisms for this defined? Can you give a reference >>> or say that its future stuff if there aren't any >>> good ones? >>>=20 >>> 5.5: typo: s/capable to validate/capable of validating/ >>>=20 >>> 8.1: Is the base spec really normative? I'd say you're >>> fine with that as informative too. >>>=20 >>> 8.2: there are a bunch of references missing as per >>> the questions above >>>=20 >>> 8.2: is there no better (more stable) reference than >>> portablecontacts.net? >>>=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 From sakimura@gmail.com Wed Jun 27 20:34:00 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86A9F21F87C0 for ; Wed, 27 Jun 2012 20:34:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.438 X-Spam-Level: X-Spam-Status: No, score=-3.438 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v8iGIwBUSLAd for ; Wed, 27 Jun 2012 20:33:59 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3FA1521F87C7 for ; Wed, 27 Jun 2012 20:33:59 -0700 (PDT) Received: by bkty8 with SMTP id y8so1713198bkt.31 for ; Wed, 27 Jun 2012 20:33:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=y4Xqgxt/DzltDpZrqBPlMjLze7pLRGpFK8sU4tIDhDY=; b=iPamiAd/J/iqNBzeWm1++mB0a57zQHiI2OYOLET5eetxJ7pIqSslS8vxSrxY6p+TRF N1raxAGS1DOcMKqOGW3dOZVk9y3/H0YD1IzGjH/kXJyoskRk7GCHmh3euZQ5+kADv1Uw J077c1FgR0tHIomSzUDEgDzsY3Ovl0TQOApXdghYt1+NwhHKksoonKsEaWevelYUDq/p CQpqjUlaY7dCpCGrBpbJdEjARlG0MeCnuJDij4uM353lmc01DXnxRNRmLJMtFSzS3j0U D40SINT0U398/bc7gEB29+jUFJ9bAo5Kjbhtal8djQhPLEbcqUJ0Ca9XNEKkJRDOeoEd 668g== MIME-Version: 1.0 Received: by 10.205.139.81 with SMTP id iv17mr73208bkc.118.1340854438247; Wed, 27 Jun 2012 20:33:58 -0700 (PDT) Received: by 10.204.124.13 with HTTP; Wed, 27 Jun 2012 20:33:58 -0700 (PDT) In-Reply-To: <59E470B10C4630419ED717AC79FCF9A91A2C8949@CH1PRD0410MB369.namprd04.prod.outlook.com> References: <1339792496.52712.YahooMailNeo@web125501.mail.ne1.yahoo.com> <59E470B10C4630419ED717AC79FCF9A9108898EE@BL2PRD0410MB363.namprd04.prod.outlook.com> <4FE223E4.6060307@mitre.org> <4FE226BC.6010403@alcatel-lucent.com> <59E470B10C4630419ED717AC79FCF9A910889AB5@BL2PRD0410MB363.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A917052BC8@SN2PRD0410MB370.namprd04.prod.outlook.com> <4FE37D38.1030407@gmail.com> <59E470B10C4630419ED717AC79FCF9A91A2C8949@CH1PRD0410MB369.namprd04.prod.outlook.com> Date: Thu, 28 Jun 2012 12:33:58 +0900 Message-ID: From: Nat Sakimura To: Lewis Adam-CAL022 Content-Type: multipart/alternative; boundary=001517402de67cbdb504c380009f Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Report an authentication issue X-BeenThere: oauth@ietf.org X-Mailman-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, 28 Jun 2012 03:34:00 -0000 --001517402de67cbdb504c380009f Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Tue, Jun 26, 2012 at 1:54 AM, Lewis Adam-CAL022 < Adam.Lewis@motorolasolutions.com> wrote: [...snip...] > ** ** > > I think the above just really drives home the fact that if OAuth is to be > used for securing enterprise API calls in a post-SOAP world, something > needs to be stated more explicitly. OAuth was not designed to provide > authentication of the user to the RS. But it seems we all agree that it > can be profiled to do so. Connect is supposed to address authentication, > but only from the view of the client, and not the RS. Only the access > token goes to the RS, so if we want to authenticate a user to the RS, the= n > we=92re back to OAuth, since Connect doesn=92t intend to send the id_toke= n to > the RS. Nat mentioned that it =93could,=94 but I haven=92t seen that as = part of > the Connect specs thus far. **** > > ** ** > > There is **clearly** confusion around whether OAuth is to be used as > authentication or not, and I think this > thread has shown that. If I=92m going to deploy OAuth for Authentication, > then I really need a spec to point to (when my customers ask) that says i= t > can be used that way, especially with all the =93OAuth is NOT authenticat= ion=94 > blog posts floating around in cyberspace these days. > Confusion is true. The fact is that OAuth by itself is incapable of providing user authentication result to the resource server (nor the client for that matter). It in fact is completely out of scope. OAuth is an access delegation (aka authorization) mechanism. It has nothing to say about who uses the token. Assuming the user of the access token is the resource owner is a false assumption. > **** > > ** ** > > I=92m thinking two things: **** > > **1) **it would at least be worthwhile to document this use case, > and maybe the OAuth use cases draft would be a good place to capture it. > Starting from a stand alone use case would be good. My impression (I may be wrong) is that your requirement is to be able to (1) Log the user identifier of the person who is accessing the resource at the resource server for the audit etc. purposes. (2) Do the holder of the key so that the RS is sure that the person accessing with the access token is really the person. (3) In addition, the RS may not be able to talk to AS directly. [Well, this is one of my use case anyways.] (4) In some cases, the client may not be able to communicate with AS directly at the time of RS access. [ditto] Are these correct? FYI, (2) has been a work item for John Bradley for sometime. For (1), (3), (4), OIDF's CX working group has been working on it. The Working Group currently is dormant waiting for the Connect to finish so that it can leverage it. (Good portion of Connect actually came from CX work results.) **** > > **2) **maybe a stand alone, informational draft would also be a good > idea, especially if we all agree that it=92s only a profile of OAuth, and > does not require any technical changes to the core draft. Something that > talks outright about an enterprise-centric world, rather than the user > RO-centric world that OAuth was really written around. This might give > future generation of Enterprise folks like myself an easier time. > That's essentially what we are doing with OpenID Connect, though not informational document but as a normative standard at OIDF. Best, Nat > **** > > ** ** > > ** ** > > Thoughts?**** > > -adam**** > > ** ** > > ** > --001517402de67cbdb504c380009f Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On Tue, Jun 26, 2012 at 1:54 AM, Lewis A= dam-CAL022 <Adam.Lewis@motorolasolutions.com>= wrote:
[...snip...]=A0

=A0

I think the above just really drives home th= e fact that if OAuth is to be used for securing enterprise API calls in a p= ost-SOAP world, something needs to be stated more explicitly.=A0 OAuth was not designed to provide authentication of the user to the RS.=A0= But it seems we all agree that it can be profiled to do so.=A0 Connect is = supposed to address authentication, but only from the view of the client, a= nd not the RS.=A0 Only the access token goes to the RS, so if we want to authenticate a user to the RS, then we=92= re back to OAuth, since Connect doesn=92t intend to send the id_token to th= e RS.=A0 Nat mentioned that it =93could,=94 but I haven=92t seen that as pa= rt of the Connect specs thus far.=A0

=A0

There is *clearly* confusion around w= hether OAuth is to be used as authentication or not, and I think this

thread = has shown that.=A0 If I=92m going to deploy OAuth for Authentication, then I really need a spec to point to (when my customers ask) that says it= can be used that way, especially with all the =93OAuth is NOT authenticati= on=94 blog posts floating around in cyberspace these days.=A0


Confusion is true. The fact is that = OAuth by itself is incapable of providing user authentication result to the= resource server (nor the client for that matter). It in fact is completely= out of scope. OAuth is an access delegation (aka authorization) mechanism.= It has nothing to say about who uses the token. Assuming the user of the a= ccess token is the resource owner is a false assumption. =A0
=A0

=A0

I=92m thinking two things:

1)=A0=A0=A0=A0=A0 it would at least be worthwhile to docu= ment this use case, and maybe the OAuth use cases draft would be a good pla= ce to capture it.=A0

Starting from a stand alone use case would be= good.=A0
My impression (I may be wrong) is that your requirement= is to be able to=A0

(1) Log the user identifier o= f the person who is accessing the resource at the resource server for the a= udit etc. purposes.=A0
(2) Do the holder of the key so that the RS is sure that the person ac= cessing with the access token=A0
=A0 =A0 =A0is really the person.= =A0
(3) In addition, the RS may not be able to talk to AS directl= y.
=A0 =A0 =A0[Well, this is one of my use case anyways.]=A0
(4= ) In some cases, the client may not be able to communicate with AS directly= at the time of RS access. [ditto]

Are these corre= ct?=A0

FYI, (2) has been a work item for John Bradley for some= time.=A0
For (1), (3), (4), OIDF's CX working group has been = working on it.=A0
The Working Group currently is dormant waiting = for the Connect to finish=A0
so that it can leverage it. (Good portion of Connect actually came fro= m CX work results.)=A0


2)=A0=A0=A0=A0=A0 maybe a stand alone, informational draf= t would also be a good idea, especially if we all agree that it=92s only a = profile of OAuth, and does not require any technical changes to the core draft.=A0 Something that talks outright about an enter= prise-centric world, rather than the user RO-centric world that OAuth was r= eally written around.=A0 This might give future generation of Enterprise fo= lks like myself an easier time.=A0

That's essentially what we are doing with= OpenID Connect, though not informational document but as a normative stand= ard at OIDF. =A0


Best,=A0

Nat

=A0

=A0

Thoughts?

-adam

=A0

=A0

--001517402de67cbdb504c380009f-- From iesg-secretary@ietf.org Wed Jun 27 22:08:16 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97E8D21F8554; Wed, 27 Jun 2012 22:08:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.525 X-Spam-Level: X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.074, 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 fx1OEa+M9Tly; Wed, 27 Jun 2012 22:08:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA70621F8528; Wed, 27 Jun 2012 22:08:14 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.21p1 Message-ID: <20120628050814.22367.47575.idtracker@ietfa.amsl.com> Date: Wed, 27 Jun 2012 22:08:14 -0700 Cc: oauth@ietf.org Subject: [OAUTH-WG] Last Call: (OAuth 2.0 Threat Model and Security Considerations) to Informational RFC X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 05:08:16 -0000 The IESG has received a request from the Web Authorization Protocol WG (oauth) to consider the following document: - 'OAuth 2.0 Threat Model and Security Considerations' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-07-11. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document gives additional security considerations for OAuth, beyond those in the OAuth specification, based on a comprehensive threat model for the OAuth 2.0 Protocol. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-oauth-v2-threatmodel/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-oauth-v2-threatmodel/ballot/ No IPR declarations have been submitted directly on this I-D. From iesg-secretary@ietf.org Wed Jun 27 22:10:35 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFBA421F8643; Wed, 27 Jun 2012 22:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.525 X-Spam-Level: X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.074, 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 UfaI49CTRLq9; Wed, 27 Jun 2012 22:10:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD95E21F863D; Wed, 27 Jun 2012 22:10:35 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.21p1 Message-ID: <20120628051035.23280.59329.idtracker@ietfa.amsl.com> Date: Wed, 27 Jun 2012 22:10:35 -0700 Cc: oauth@ietf.org Subject: [OAUTH-WG] Last Call: (OAuth 2.0 Threat Model and Security Considerations) to Informational RFC X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 05:10:36 -0000 The IESG has received a request from the Web Authorization Protocol WG (oauth) to consider the following document: - 'OAuth 2.0 Threat Model and Security Considerations' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-07-11. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document gives additional security considerations for OAuth, beyond those in the OAuth specification, based on a comprehensive threat model for the OAuth 2.0 Protocol. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-oauth-v2-threatmodel/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-oauth-v2-threatmodel/ballot/ No IPR declarations have been submitted directly on this I-D. From Michael.Jones@microsoft.com Thu Jun 28 08:43:56 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0C0C21F85AC for ; Thu, 28 Jun 2012 08:43:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.778 X-Spam-Level: X-Spam-Status: No, score=-3.778 tagged_above=-999 required=5 tests=[AWL=-0.179, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xxPeIhGEet8F for ; Thu, 28 Jun 2012 08:43:56 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe006.messaging.microsoft.com [213.199.154.144]) by ietfa.amsl.com (Postfix) with ESMTP id 81E3021F85A3 for ; Thu, 28 Jun 2012 08:43:55 -0700 (PDT) Received: from mail59-db3-R.bigfish.com (10.3.81.254) by DB3EHSOBE001.bigfish.com (10.3.84.21) with Microsoft SMTP Server id 14.1.225.23; Thu, 28 Jun 2012 15:42:07 +0000 Received: from mail59-db3 (localhost [127.0.0.1]) by mail59-db3-R.bigfish.com (Postfix) with ESMTP id 590961C03C9; Thu, 28 Jun 2012 15:42:07 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -31 X-BigFish: VS-31(zzbb2dI98dI9371I1454I542M1432I111aIzz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25hf0ah) Received-SPF: pass (mail59-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC107.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail59-db3 (localhost.localdomain [127.0.0.1]) by mail59-db3 (MessageSwitch) id 1340898125505581_21102; Thu, 28 Jun 2012 15:42:05 +0000 (UTC) Received: from DB3EHSMHS002.bigfish.com (unknown [10.3.81.240]) by mail59-db3.bigfish.com (Postfix) with ESMTP id 6F12B300091; Thu, 28 Jun 2012 15:42:05 +0000 (UTC) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS002.bigfish.com (10.3.87.102) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 28 Jun 2012 15:42:03 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.53]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.02.0309.003; Thu, 28 Jun 2012 15:43:43 +0000 From: Mike Jones To: Pete Resnick Thread-Topic: FW: Pete Resnick's Discuss on draft-ietf-oauth-v2-bearer-20: (with DISCUSS and COMMENT) Thread-Index: Ac1NfVJ2/vngAAOnQsWKq1/c+fOMkQADcmWAAe5hroA= Date: Thu, 28 Jun 2012 15:43:41 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436656C96C@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B168042967394366558C4C@TK5EX14MBXC283.redmond.corp.microsoft.com> <4FDF85AD.8040706@cs.tcd.ie> In-Reply-To: <4FDF85AD.8040706@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.36] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: Mark Nottingham , "oauth@ietf.org" Subject: Re: [OAUTH-WG] FW: Pete Resnick's Discuss on draft-ietf-oauth-v2-bearer-20: (with DISCUSS and 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: Thu, 28 Jun 2012 15:43:57 -0000 Pete, can you now please clear this DISCUSS? The W3C review period conclud= ed yesterday and no issues have been brought to my attention. Thank you, -- Mike -----Original Message----- From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie]=20 Sent: Monday, June 18, 2012 12:47 PM To: Mike Jones Cc: Pete Resnick; Mark Nottingham; oauth@ietf.org Subject: Re: FW: Pete Resnick's Discuss on draft-ietf-oauth-v2-bearer-20: (= with DISCUSS and COMMENT) Hi Mike, As you noted this is under way. When I mailed tlr I asked for two weeks fro= m the 13th, which co-incides with the end of the IETF LC caused by the IPR = declaration, so it should be fine. Cheers, S. On 06/18/2012 07:08 PM, Mike Jones wrote: > Hi Stephen, >=20 > Pete is holding his DISCUSS on Bearer open until the current text on the = URI query parameter http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-2= 0#section-2.3 receives W3C review. Can you try to have that review happen = this week, hopefully finishing sometime next week? >=20 > I'm cc:'ing Mark in his role as W3C liaison. >=20 > Thanks again, > -- Mike >=20 > -----Original Message----- > From: Pete Resnick [mailto:presnick@qualcomm.com] > Sent: Tuesday, June 12, 2012 1:40 PM > To: The IESG > Cc: oauth-chairs@tools.ietf.org;=20 > draft-ietf-oauth-v2-bearer@tools.ietf.org > Subject: Pete Resnick's Discuss on draft-ietf-oauth-v2-bearer-20:=20 > (with DISCUSS and COMMENT) >=20 > Pete Resnick has entered the following ballot position for > draft-ietf-oauth-v2-bearer-20: Discuss >=20 > When responding, please keep the subject line intact and reply to all=20 > email addresses included in the To and CC lines. (Feel free to cut=20 > this introductory paragraph, however.) >=20 >=20 > Please refer to=20 > http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > Mark Nottingham's Applications Area review=20 > ml> identified the issue of URI query parameters in section 2.3: URI=20 > query parameters are normally locally scoped. In this document, a=20 > query parameter (access_token) is being defined as applying to all=20 > URIs. This is (relatively) novel. A few people in the HTTP community=20 > (including > Mark) have expressed concerns. (See also=20 > http://www.ietf.org/mail-archive/web/apps-discuss/current/msg04932.htm > l > and > http://www.ietf.org/mail-archive/web/apps-discuss/current/msg04933.htm > l from the apps-discuss archive.) This issue should probably be=20 > further reviewed by W3C folks. I'm holding the DISCUSS as per Stephen to = make sure we get that review. >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > In section 2.3, the new last paragraph starts: >=20 > This method is included to document current use; its use is NOT > RECOMMENDED... >=20 > NOT RECOMMENDED is not defined by 2119, and the language is redundant wit= h the previous paragraph and potentially confusing. I suggest replacing it = with simply: >=20 > This method is included to document current use; as indicated > in the previous paragraph, the use of this method is not > recommended... >=20 > BTW: The "SHOULD NOT unless..." in the previous paragraph is itself redun= dant. I think you mean "MUST NOT unless...". SHOULD NOT *means* MUST NOT un= less you understand what you're doing. >=20 > Mark Nottingham's Applications Area review=20 > ml> has a couple of comments that I think deserve further reply: >=20 > * Section 1: Introduction >=20 > The introduction explains oauth, but it doesn't fully explain the > relationship of this specification to OAuth 2.0. E.g., can it be > used independently from the rest of OAuth? Likewise, the overview > (section 1.3) seems more specific to the OAuth specification than > this document. As I read it, this mechanism could be used for ANY > bearer token, not just one generated through OAuth flows. >=20 > If it is indeed more general, I'd recommend minimising the > discussion of OAuth, perhaps even removing it from the document > title. >=20 > I agree that the title would be better simply as "HTTP Bearer Tokens", an= d then explain in the Abstract and Intro that the motivation and intended u= se of these Bearer Tokens is the OAuth 2.0 specification. A possibly useful= side effect of this change might be that you can make OAuth 2.0 an informa= tive (as against a normative) reference, and that these things could be reu= sed for other purposes in the future. Not a huge deal, but I (like Mark) wa= s unconvinced that the reference to OAuth in the title was necessary. >=20 > * Section 3 The WWW-Authenticate Response Header Field >=20 > The difference between a realm and a scope is not explained. Are the > functionally equivalent, just a single value vs. a list? >=20 > Some text, and probably an example, might help explain this a bit better. >=20 > One of his comments asked for some additional review. I don't have a=20 > personal opinion whether this is needed, but perhaps you should pursue > this: >=20 > * General >=20 > The draft currently doesn't mention whether Bearer is suitable for > use as a proxy authentication scheme. I suspect it *may*; it would > be worth discussing this with some proxy implementers to gauge their > interest (e.g., Squid). >=20 >=20 >=20 From Adam.Lewis@motorolasolutions.com Thu Jun 28 13:13:33 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 031DB11E8098 for ; Thu, 28 Jun 2012 13:13:33 -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 qzI++Gm9hq-O for ; Thu, 28 Jun 2012 13:13:31 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe001.messaging.microsoft.com [216.32.180.11]) by ietfa.amsl.com (Postfix) with ESMTP id 5B8AD11E80B3 for ; Thu, 28 Jun 2012 13:13:29 -0700 (PDT) Received: from mail139-va3-R.bigfish.com (10.7.14.250) by VA3EHSOBE007.bigfish.com (10.7.40.11) with Microsoft SMTP Server id 14.1.225.23; Thu, 28 Jun 2012 20:11:42 +0000 Received: from mail139-va3 (localhost [127.0.0.1]) by mail139-va3-R.bigfish.com (Postfix) with ESMTP id 55F47E0807 for ; Thu, 28 Jun 2012 20:11:42 +0000 (UTC) X-Forefront-Antispam-Report: CIP:129.188.136.16; KIP:(null); UIP:(null); IPV:NLI; H:il06gsg01.am.mot-solutions.com; RD:none; EFVD:NLI X-SpamScore: 0 X-BigFish: VPS0(zzc85fhzz1202hzz8275bh8275dhz2fh2a8h683h839hd25hf0ah) Received-SPF: pass (mail139-va3: domain of motorolasolutions.com designates 129.188.136.16 as permitted sender) client-ip=129.188.136.16; envelope-from=Adam.Lewis@motorolasolutions.com; helo=il06gsg01.am.mot-solutions.com ; olutions.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.244.181; KIP:(null); UIP:(null); (null); H:CH1PRD0410HT003.namprd04.prod.outlook.com; R:internal; EFV:INT Received: from mail139-va3 (localhost.localdomain [127.0.0.1]) by mail139-va3 (MessageSwitch) id 1340914300104858_27080; Thu, 28 Jun 2012 20:11:40 +0000 (UTC) Received: from VA3EHSMHS019.bigfish.com (unknown [10.7.14.235]) by mail139-va3.bigfish.com (Postfix) with ESMTP id 0C36D3C0127 for ; Thu, 28 Jun 2012 20:11:40 +0000 (UTC) Received: from il06gsg01.am.mot-solutions.com (129.188.136.16) by VA3EHSMHS019.bigfish.com (10.7.99.29) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 28 Jun 2012 20:11:39 +0000 Received: from il06gsg01.am.mot-solutions.com (il06vts01.mot.com [129.188.137.141]) by il06gsg01.am.mot-solutions.com (8.14.3/8.14.3) with ESMTP id q5SK5TpZ009182 for ; Thu, 28 Jun 2012 16:05:30 -0400 (EDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe004.messaging.microsoft.com [213.199.154.142]) by il06gsg01.am.mot-solutions.com (8.14.3/8.14.3) with ESMTP id q5SK5Rjo009179 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 28 Jun 2012 16:05:28 -0400 (EDT) Received: from mail32-db3-R.bigfish.com (10.3.81.251) by DB3EHSOBE001.bigfish.com (10.3.84.21) with Microsoft SMTP Server id 14.1.225.23; Thu, 28 Jun 2012 20:11:35 +0000 Received: from mail32-db3 (localhost [127.0.0.1]) by mail32-db3-R.bigfish.com (Postfix) with ESMTP id 60EA0160B7C for ; Thu, 28 Jun 2012 20:11:35 +0000 (UTC) Received: from mail32-db3 (localhost.localdomain [127.0.0.1]) by mail32-db3 (MessageSwitch) id 13409142946403_25780; Thu, 28 Jun 2012 20:11:34 +0000 (UTC) Received: from DB3EHSMHS002.bigfish.com (unknown [10.3.81.233]) by mail32-db3.bigfish.com (Postfix) with ESMTP id F3B314600BF; Thu, 28 Jun 2012 20:11:33 +0000 (UTC) Received: from CH1PRD0410HT003.namprd04.prod.outlook.com (157.56.244.181) by DB3EHSMHS002.bigfish.com (10.3.87.102) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 28 Jun 2012 20:11:33 +0000 Received: from CH1PRD0410MB369.namprd04.prod.outlook.com ([169.254.12.121]) by CH1PRD0410HT003.namprd04.prod.outlook.com ([10.255.147.38]) with mapi id 14.16.0164.004; Thu, 28 Jun 2012 20:13:16 +0000 From: Lewis Adam-CAL022 To: Nat Sakimura Thread-Topic: [OAUTH-WG] Report an authentication issue Thread-Index: AQHNVN7pP3aOaLD8E0OCNoiB4+A1+JcQJVig Date: Thu, 28 Jun 2012 20:13:12 +0000 Message-ID: <59E470B10C4630419ED717AC79FCF9A91A2D1309@CH1PRD0410MB369.namprd04.prod.outlook.com> References: <1339792496.52712.YahooMailNeo@web125501.mail.ne1.yahoo.com> <59E470B10C4630419ED717AC79FCF9A9108898EE@BL2PRD0410MB363.namprd04.prod.outlook.com> <4FE223E4.6060307@mitre.org> <4FE226BC.6010403@alcatel-lucent.com> <59E470B10C4630419ED717AC79FCF9A910889AB5@BL2PRD0410MB363.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A917052BC8@SN2PRD0410MB370.namprd04.prod.outlook.com> <4FE37D38.1030407@gmail.com> <59E470B10C4630419ED717AC79FCF9A91A2C8949@CH1PRD0410MB369.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: [184.78.105.93] Content-Type: multipart/alternative; boundary="_000_59E470B10C4630419ED717AC79FCF9A91A2D1309CH1PRD0410MB369_" 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 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Report an authentication issue X-BeenThere: oauth@ietf.org X-Mailman-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, 28 Jun 2012 20:13:33 -0000 --_000_59E470B10C4630419ED717AC79FCF9A91A2D1309CH1PRD0410MB369_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Nat, Starting from a standalone use case would be good. My impression (I may be wrong) is that your requirement is to be able to (1) Log the user identifier of the person who is accessing the resource at = the resource server for the audit etc. purposes. yes ... that *and* to authenticate the user in the first place. So a= gain, my access_token will actually look like the Connect id_token. I woul= d even prefer to use the id_token, except that it violate the spirit of Con= nect to pass the id_token to the RS (e.g. it was only meant for consumption= by the client). My problem space can be distilled to something very simple. - We come from a SOAP API world where we use WS-Trust to secure th= e SOAP API calls. WS-Trust makes it very simple for a WS-* client to colle= ct the user's primary credentials, exchange it for a (SAML) bearer token vi= a the STS, and embed that bearer token in SOAP-based API calls to the WS-* = server. This is most definitely *authentication* - We are moving to a RESTful API world. I just want to be able to= do the same thing as above. How do I enable my REST-based client to collec= t the user's password, exchange it for a (JWT) bearer token via the STS, an= d embed that bearer token in RESTful API calls to the REST-based server, su= ch that the REST-based server can *authenticate* the client? (2) Do the holder of the key so that the RS is sure that the person accessi= ng with the access token is really the person. that would be nice, but most of my users will be using passwords in t= he beginning, so this is not an option. I'm using the literal definition o= f bearer token here, taken straight out of the OAuth bearer token spec, e.g= . "Any party in possession of a bearer token (a "bearer") can use it to get access to the associated resources (without demonstrating possession of a c= ryptographic key)." (3) In addition, the RS may not be able to talk to AS directly. [Well, this is one of my use case anyways.] Right ... this is why I am now looking at structured JWTs. (4) In some cases, the client may not be able to communicate with AS direct= ly at the time of RS access. [ditto] Right again, we have disaster scenarios to think about where the AS m= ight not be reachable. but this is a use case for next steps. Trying to w= alk before we fly here :-) --_000_59E470B10C4630419ED717AC79FCF9A91A2D1309CH1PRD0410MB369_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Nat,

 

Starting from a standalone use case would be good.&n= bsp;

My impression (I may be wrong) is that your requirem= ent is to be able to 

 

(1) Log the user identifier of the person who is acc= essing the resource at the resource server for the audit etc. purposes.&nbs= p;


<acl> yes … that *and* to authenticate th= e user in the first place.  So again, my access_token will actually lo= ok like the Connect id_token.  I would even prefer to use the id_token= , except that it violate the spirit of Connect to pass the id_token to the R= S (e.g. it was only meant for consumption by the client).=

 

My problem space can be distilled to somethi= ng very simple. 

-    &= nbsp;     We come from a SOAP API world where = we use WS-Trust to secure the SOAP API calls.  WS-Trust makes it very = simple for a WS-* client to collect the user’s primary credentials, exchange it for a (SAML) bearer token via the STS, and embed that bearer t= oken in SOAP-based API calls to the WS-* server. This is most definitely *<= b>authentication*

-    &= nbsp;     We are moving to a RESTful API world= .  I just want to be able to do the same thing as above. How do I enab= le my REST-based client to collect the user’s password, exchange it for a (JWT) bearer token via the STS, and embed that bearer token in RE= STful API calls to the REST-based server, such that the REST-based server c= an *authenticate* the client? 

(2) Do the holder of the key so that the RS is sure = that the person accessing with the access token 

     is really the person. =

 

<acl> th= at would be nice, but most of my users will be using passwords in the begin= ning, so this is not an option.  I’m using the literal definitio= n of bearer token here, taken straight out of the OAuth bearer token spec, e= .g. “Any party in possession of a bearer token (a "bearer") = can use it to get

access t= o the associated resources (without demonstrating possession of a cryptogra= phic key).”

 

(3) In addition, the RS may not be able to talk to A= S directly.

     [Well, this is one of my use cas= e anyways.] 

 

<acl> Right … this is why I am n= ow looking at structured JWTs.

 

(4) In some cases, the client may not be able to com= municate with AS directly at the time of RS access. [ditto]

 

<acl> Right again, we have disaster sc= enarios to think about where the AS might not be reachable.  but this = is a use case for next steps.  Trying to walk before we fly here :-)

--_000_59E470B10C4630419ED717AC79FCF9A91A2D1309CH1PRD0410MB369_-- From ve7jtb@ve7jtb.com Thu Jun 28 13:48:05 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF31921F8513 for ; Thu, 28 Jun 2012 13:48:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.436 X-Spam-Level: X-Spam-Status: No, score=-3.436 tagged_above=-999 required=5 tests=[AWL=0.162, 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 ec78y4ACIQJK for ; Thu, 28 Jun 2012 13:48:04 -0700 (PDT) Received: from mail-yw0-f42.google.com (mail-yw0-f42.google.com [209.85.213.42]) by ietfa.amsl.com (Postfix) with ESMTP id 573E121F8512 for ; Thu, 28 Jun 2012 13:48:03 -0700 (PDT) Received: by yhfq11 with SMTP id q11so2738999yhf.15 for ; Thu, 28 Jun 2012 13:48:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=SnfyFwmcB0D1z1MAP4Jxjg6ClE5LyaUV7atiNQ4+gU4=; b=HiIgr4k1y0czTX2eKCnhMN41QmPpn5O4hg+7Ra4XThRzzBTaDwIDIOFfSH9daaQ0Bm mu4UFj8h2i5OTj3wnALFLBik//hSCKWarKoaSA6m/+P15NOx/4o329V83ViWIFOjpx9r hJ0OtdtOtJoNnsbNM7CzIBxHiC9d3QTVyiCr+LU4ka2e39hTgMyCE66GAKzUFv8pLgxl TJtwYpHor5oDWDlc7qHhe21Os7hpoxCkdbHmIiJBdriLKXU9aCboKTt7MwNh8e1b/VW2 phDMsyAPVJB1tbU9tSmBLbVsc4eJ5PSVIswD3gqDVDgCR3/GYG+jiYRmYPQ2ia2kJajq 9/Lw== Received: by 10.236.152.97 with SMTP id c61mr5702578yhk.130.1340916483056; Thu, 28 Jun 2012 13:48:03 -0700 (PDT) Received: from [192.168.1.213] (190-20-45-203.baf.movistar.cl. [190.20.45.203]) by mx.google.com with ESMTPS id d10sm528709anm.17.2012.06.28.13.48.00 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 28 Jun 2012 13:48:01 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_6681819B-FB75-4043-A2FD-4872338C9CEF"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <59E470B10C4630419ED717AC79FCF9A91A2D1309@CH1PRD0410MB369.namprd04.prod.outlook.com> Date: Thu, 28 Jun 2012 16:47:54 -0400 Message-Id: <496AFB1D-A609-4188-B92D-2185E8880388@ve7jtb.com> References: <1339792496.52712.YahooMailNeo@web125501.mail.ne1.yahoo.com> <59E470B10C4630419ED717AC79FCF9A9108898EE@BL2PRD0410MB363.namprd04.prod.outlook.com> <4FE223E4.6060307@mitre.org> <4FE226BC.6010403@alcatel-lucent.com> <59E470B10C4630419ED717AC79FCF9A910889AB5@BL2PRD0410MB363.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A917052BC8@SN2PRD0410MB370.namprd04.prod.outlook.com> <4FE37D38.1030407@gmail.com> <59E470B10C4630419ED717AC79FCF9A91A2C8949@CH1PRD0410MB369.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A91A2D1309@CH1PRD0410MB369.namprd04.prod.outlook.com> To: Lewis Adam-CAL022 X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQk/z12DOVUeEXs2vqyN8B1POtBIxuhY6K6Z0y1+0f2bn1nxYe78o9hG5IYLpwYXHYCfOXk4 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Report an authentication issue X-BeenThere: oauth@ietf.org X-Mailman-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, 28 Jun 2012 20:48:05 -0000 --Apple-Mail=_6681819B-FB75-4043-A2FD-4872338C9CEF Content-Type: multipart/alternative; boundary="Apple-Mail=_AFD7E9E0-A7A4-4A97-BFF4-704142D0E8E7" --Apple-Mail=_AFD7E9E0-A7A4-4A97-BFF4-704142D0E8E7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Adam, This is getting tangled up in semantics. The AS authenticates the user and Authorizes the client (native App) to = access the protected resource (video server) via issuing it a access = token, or a authorization code that it can trade at a token endpoint for = a refresh_token and access_token. At that point the client has no notion of who the user is unless a = openID Connect id_token was also sent. I suspect that the video player = app may not care who the person, only what it can access. The App then uses its access token to prove that it was delegated access = to the server by some person (Resource owner in OAuth speak). =20 In your STS example you call this Authentication, but in OAuth it is = Authorization. The client is the one being authenticated to the = resource via the token. The User is Authenticated to the AS. The same trust chain exists it = just uses different terms. That token can be structured like the id_token is, but there is an = important difference. The access token's audience is the resource = server and the id_token's audience is the client. That is one of the reasons they are separate. This looks like a relatively strait forward OAuth use case to me, you = can probably also use opaque tokens with a AS STS and some caching logic = at the RS if you want to keep the token size down. John B. On 2012-06-28, at 4:13 PM, Lewis Adam-CAL022 wrote: > Hi Nat, > =20 > Starting from a standalone use case would be good.=20 > My impression (I may be wrong) is that your requirement is to be able = to=20 > =20 > (1) Log the user identifier of the person who is accessing the = resource at the resource server for the audit etc. purposes.=20 >=20 > yes =85 that *and* to authenticate the user in the first place. = So again, my access_token will actually look like the Connect id_token. = I would even prefer to use the id_token, except that it violate the = spirit of Connect to pass the id_token to the RS (e.g. it was only meant = for consumption by the client). > =20 > My problem space can be distilled to something very simple. =20 >=20 > - We come from a SOAP API world where we use WS-Trust to = secure the SOAP API calls. WS-Trust makes it very simple for a WS-* = client to collect the user=92s primary credentials, exchange it for a = (SAML) bearer token via the STS, and embed that bearer token in = SOAP-based API calls to the WS-* server. This is most definitely = *authentication* >=20 > - We are moving to a RESTful API world. I just want to be = able to do the same thing as above. How do I enable my REST-based client = to collect the user=92s password, exchange it for a (JWT) bearer token = via the STS, and embed that bearer token in RESTful API calls to the = REST-based server, such that the REST-based server can *authenticate* = the client? =20 >=20 > (2) Do the holder of the key so that the RS is sure that the person = accessing with the access token=20 > is really the person.=20 > =20 > that would be nice, but most of my users will be using passwords = in the beginning, so this is not an option. I=92m using the literal = definition of bearer token here, taken straight out of the OAuth bearer = token spec, e.g. =93Any party in possession of a bearer token (a = "bearer") can use it to get > access to the associated resources (without demonstrating possession = of a cryptographic key).=94 > =20 > (3) In addition, the RS may not be able to talk to AS directly. > [Well, this is one of my use case anyways.]=20 > =20 > Right =85 this is why I am now looking at structured JWTs. > =20 > (4) In some cases, the client may not be able to communicate with AS = directly at the time of RS access. [ditto] > =20 > Right again, we have disaster scenarios to think about where the = AS might not be reachable. but this is a use case for next steps. = Trying to walk before we fly here :-) > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_AFD7E9E0-A7A4-4A97-BFF4-704142D0E8E7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Adam,

This is getting = tangled up in semantics.

The AS authenticates the = user and Authorizes the client (native App) to access the protected = resource (video server) via issuing it a access token, or a = authorization code that it can trade at a token endpoint for a = refresh_token and access_token.

At that point = the client has no notion of who the user is unless a openID Connect = id_token was also sent.  I suspect that the video player app may = not care who the person, only what it can = access.

The App then uses its access token to = prove that it was delegated access to the server by some person = (Resource owner in OAuth speak).  
In your STS example = you call this Authentication, but in OAuth it is Authorization. =  The client is the one being authenticated to the resource via the = token.
The User is Authenticated to the AS.   The same = trust chain exists it just uses different = terms.

That token can be structured like the = id_token is, but there is an important difference.  The access = token's audience is the resource server and the id_token's audience is = the client.
That is one of the reasons they are = separate.

This looks like a relatively strait = forward OAuth use case to me,  you can probably also use opaque = tokens with a AS STS and some caching logic at the RS if you want to = keep the token size down.

John = B.


On 2012-06-28, at 4:13 PM, = Lewis Adam-CAL022 wrote:

Hi = Nat,
Starting from a = standalone use case would be good. 
My impression (I may be wrong) is that your requirement is = to be able to 
(1) Log the user = identifier of the person who is accessing the resource at the resource = server for the audit etc. purposes. 

<acl> = yes =85 that *and* to authenticate the user in the first = place.  So again, my access_token will actually look like the = Connect id_token.  I would even prefer to use the id_token, except = that it violate the spirit of Connect to pass the id_token to the RS = (e.g. it was only meant for consumption by the = client).
My problem = space can be distilled to something very simple.  

- We come from = a SOAP API world where we use WS-Trust to secure the SOAP API = calls.  WS-Trust makes it very simple for a WS-* client to collect = the user=92s primary credentials, exchange it for a (SAML) bearer token = via the STS, and embed that bearer token in SOAP-based API calls to the = WS-* server. This is most definitely = *authentication*

- We are moving = to a RESTful API world.  I just want to be able to do the same = thing as above. How do I enable my REST-based client to collect the = user=92s password, exchange it for a (JWT) bearer token via the STS, and = embed that bearer token in RESTful API calls to the REST-based server, = such that the REST-based server can *authenticate* the = client?  

(2) Do the holder of the key so that the RS = is sure that the person accessing with the access = token 
    =  is really the person. 
 
<acl> = that would be nice, but most of my users will be using passwords in the = beginning, so this is not an option.  I=92m using the literal = definition of bearer token here, taken straight out of the OAuth bearer = token spec, e.g. =93Any party in = possession of a bearer token (a "bearer") can use it to = get
access to the = associated resources (without demonstrating possession of a = cryptographic key).=94
 
(3) In addition, the RS may not be able to talk to AS = directly.
    =  [Well, this is one of my use case = anyways.] 
<acl> = Right =85 this is why I am now looking at structured = JWTs.
(4) In some cases, = the client may not be able to communicate with AS directly at the time = of RS access. [ditto]
<acl> = Right again, we have disaster scenarios to think about where the AS = might not be reachable.  but this is a use case for next = steps.  Trying to walk before we fly here = :-)
_____________________________= __________________
OAuth mailing list
OAuth@ietf.org
Subject: Re: [OAUTH-WG] Report an authentication issue X-BeenThere: oauth@ietf.org X-Mailman-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, 28 Jun 2012 22:35:18 -0000 --_000_59E470B10C4630419ED717AC79FCF9A91A2D13C9CH1PRD0410MB369_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi John, It may be semantics, but in my use cases, the AS is not "authorizing" anyth= ing. It's 1) authenticating the user, and 2) issuing a structured JWT acce= ss_token which contains claims about the user (again, just like the id_toke= n, but as you said, aud=3DRS). The video client on the iPhone/Android uses this as a bearer token, and inc= ludes it an a request to the video server. The video server uses the claim= s in the JWT access_token to authenticate the user, and then makes its own = authorization decisions (e.g. maps user id to app-centric roles, etc.) If you still feel this is within the spirit of OAuth, then great :-) My concern is still that one of our customer's will read your blog and fire= back at us ... "but John says OAuth is not for authentication" ;) This is why I would like to explore the idea of putting out an informationa= l draft profiling OAuth for authentication, since everybody seems to at lea= st agree that it can be profiled to do so. Tx! adam From: John Bradley [mailto:ve7jtb@ve7jtb.com] Sent: Thursday, June 28, 2012 3:48 PM To: Lewis Adam-CAL022 Cc: Nat Sakimura; oauth@ietf.org Subject: Re: [OAUTH-WG] Report an authentication issue Adam, This is getting tangled up in semantics. The AS authenticates the user and Authorizes the client (native App) to acc= ess the protected resource (video server) via issuing it a access token, or= a authorization code that it can trade at a token endpoint for a refresh_t= oken and access_token. At that point the client has no notion of who the user is unless a openID C= onnect id_token was also sent. I suspect that the video player app may not= care who the person, only what it can access. The App then uses its access token to prove that it was delegated access to= the server by some person (Resource owner in OAuth speak). In your STS example you call this Authentication, but in OAuth it is Author= ization. The client is the one being authenticated to the resource via the= token. The User is Authenticated to the AS. The same trust chain exists it just = uses different terms. That token can be structured like the id_token is, but there is an importan= t difference. The access token's audience is the resource server and the i= d_token's audience is the client. That is one of the reasons they are separate. This looks like a relatively strait forward OAuth use case to me, you can = probably also use opaque tokens with a AS STS and some caching logic at the= RS if you want to keep the token size down. John B. On 2012-06-28, at 4:13 PM, Lewis Adam-CAL022 wrote: Hi Nat, Starting from a standalone use case would be good. My impression (I may be wrong) is that your requirement is to be able to (1) Log the user identifier of the person who is accessing the resource at = the resource server for the audit etc. purposes. yes ... that *and* to authenticate the user in the first place. So a= gain, my access_token will actually look like the Connect id_token. I woul= d even prefer to use the id_token, except that it violate the spirit of Con= nect to pass the id_token to the RS (e.g. it was only meant for consumption= by the client). My problem space can be distilled to something very simple. - We come from a SOAP API world where we use WS-Trust to secure th= e SOAP API calls. WS-Trust makes it very simple for a WS-* client to colle= ct the user's primary credentials, exchange it for a (SAML) bearer token vi= a the STS, and embed that bearer token in SOAP-based API calls to the WS-* = server. This is most definitely *authentication* - We are moving to a RESTful API world. I just want to be able to= do the same thing as above. How do I enable my REST-based client to collec= t the user's password, exchange it for a (JWT) bearer token via the STS, an= d embed that bearer token in RESTful API calls to the REST-based server, su= ch that the REST-based server can *authenticate* the client? (2) Do the holder of the key so that the RS is sure that the person accessi= ng with the access token is really the person. that would be nice, but most of my users will be using passwords in t= he beginning, so this is not an option. I'm using the literal definition o= f bearer token here, taken straight out of the OAuth bearer token spec, e.g= . "Any party in possession of a bearer token (a "bearer") can use it to get access to the associated resources (without demonstrating possession of a c= ryptographic key)." (3) In addition, the RS may not be able to talk to AS directly. [Well, this is one of my use case anyways.] Right ... this is why I am now looking at structured JWTs. (4) In some cases, the client may not be able to communicate with AS direct= ly at the time of RS access. [ditto] Right again, we have disaster scenarios to think about where the AS m= ight not be reachable. but this is a use case for next steps. Trying to w= alk before we fly here :-) _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_59E470B10C4630419ED717AC79FCF9A91A2D13C9CH1PRD0410MB369_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi John,

 

It may be semantics, but in my use cases, th= e AS is not “authorizing” anything.  It’s 1) authent= icating the user, and 2) issuing a structured JWT access_token which contai= ns claims about the user (again, just like the id_token, but as you said, aud=3DRS).=  

 

The video client on the iPhone/Android uses = this as a bearer token, and includes it an a request to the video server.&n= bsp; The video server uses the claims in the JWT access_token to authenticate the user, and then makes its own authorization decisions (= e.g. maps user id to app-centric roles, etc.)

 

If you still feel this is within the spirit = of OAuth, then great :-)

 

My concern is still that one of our customer= ’s will read your blog and fire back at us … “but John sa= ys OAuth is not for authentication”  ;)

 

This is why I would like to explore the idea= of putting out an informational draft profiling OAuth for authentication, = since everybody seems to at least agree that it can be profiled to do so.

 

Tx!

adam

 

From: John Bra= dley [mailto:ve7jtb@ve7jtb.com]
Sent: Thursday, June 28, 2012 3:48 PM
To: Lewis Adam-CAL022
Cc: Nat Sakimura; oauth@ietf.org
Subject: Re: [OAUTH-WG] Report an authentication issue

 

Adam,

 

This is getting tangled up in semantics.<= /p>

 

The AS authenticates the user and Authorizes the cli= ent (native App) to access the protected resource (video server) via issuin= g it a access token, or a authorization code that it can trade at a token e= ndpoint for a refresh_token and access_token.

 

At that point the client has no notion of who the us= er is unless a openID Connect id_token was also sent.  I suspect that = the video player app may not care who the person, only what it can access.<= o:p>

 

The App then uses its access token to prove that it = was delegated access to the server by some person (Resource owner in OAuth = speak).  

In your STS example you call this Authentication, bu= t in OAuth it is Authorization.  The client is the one being authentic= ated to the resource via the token.

The User is Authenticated to the AS.   The same= trust chain exists it just uses different terms.

 

That token can be structured like the id_token is, b= ut there is an important difference.  The access token's audience is t= he resource server and the id_token's audience is the client.

That is one of the reasons they are separate.

 

This looks like a relatively strait forward OAuth us= e case to me,  you can probably also use opaque tokens with a AS STS a= nd some caching logic at the RS if you want to keep the token size down.

 

John B.

 

 

On 2012-06-28, at 4:13 PM, Lewis Adam-CAL022 wrote:<= o:p>



Hi Nat,

 

Starting from a standalone use case would be good.&n= bsp;

My impression (I may be wrong) is that your requirem= ent is to be able to 

 

(1) Log the user identifier of the person who is acc= essing the resource at the resource server for the audit etc. purposes.&nbs= p;


<acl> yes … that *and* to authenticate th= e user in the first place.  So again, my access_token will actually lo= ok like the Connect id_token.  I would even prefer to use the id_token= , except that it violate the spirit of Connect to pass the id_token to the R= S (e.g. it was only meant for consumption by the client).=

 

My problem space can be distilled to somethi= ng very simple.  

-      &n= bsp;   <= span style=3D"font-family:"Calibri","sans-serif";color:= olive">We come from a SOAP API world where we use WS-Trust to secure the SOAP API ca= lls.  WS-Trust makes it very simple for a WS-* client to collect the u= ser’s primary credentials, exchange it for a (SAML) bearer token via = the STS, and embed that bearer token in SOAP-based API calls to the WS-* server. This is most definitely *authentication*


-      &n= bsp;   <= span style=3D"font-family:"Calibri","sans-serif";color:= olive">We are moving to a RESTful API world.  I just want to be able to do the = same thing as above. How do I enable my REST-based client to collect the us= er’s password, exchange it for a (JWT) bearer token via the STS, and = embed that bearer token in RESTful API calls to the REST-based server, such that the REST-based server can *authenti= cate* the client?  


(2) Do the holder of the key so that the RS is sure = that the person accessing with the access token 

     is really the person. =

 

<acl> that would be nice, but most of = my users will be using passwords in the beginning, so this is not an option= .  I’m using the literal definition of bearer token here, taken straight out of the OAuth bearer token spec, e.g. “Any party in possession of a bearer = token (a "bearer") can use it to get

access to the associated resources (wi= thout demonstrating possession of a cryptographic key).”

 

(3) In addition, the RS may not be able to talk to A= S directly.

     [Well, this is one of my use cas= e anyways.] 

 

<acl> Right … this is why I am n= ow looking at structured JWTs.

 

(4) In some cases, the client may not be able to com= municate with AS directly at the time of RS access. [ditto]

 

<acl> Right again, we have disaster sc= enarios to think about where the AS might not be reachable.  but this = is a use case for next steps.  Trying to walk before we fly here :-)

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

 

--_000_59E470B10C4630419ED717AC79FCF9A91A2D13C9CH1PRD0410MB369_-- From bcampbell@pingidentity.com Thu Jun 28 15:57:41 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A10721F84DA for ; Thu, 28 Jun 2012 15:57:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.988 X-Spam-Level: X-Spam-Status: No, score=-5.988 tagged_above=-999 required=5 tests=[AWL=-0.012, 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 VjHeOZGSChsS for ; Thu, 28 Jun 2012 15:57:40 -0700 (PDT) Received: from na3sys009aog128.obsmtp.com (na3sys009aog128.obsmtp.com [74.125.149.141]) by ietfa.amsl.com (Postfix) with ESMTP id 9F0A521F84D3 for ; Thu, 28 Jun 2012 15:57:39 -0700 (PDT) Received: from mail-vc0-f170.google.com ([209.85.220.170]) (using TLSv1) by na3sys009aob128.postini.com ([74.125.148.12]) with SMTP ID DSNKT+zhYirvDm2bZBFzXIl4zUKCA4oaSqtf@postini.com; Thu, 28 Jun 2012 15:57:39 PDT Received: by vcbgb22 with SMTP id gb22so2206638vcb.29 for ; Thu, 28 Jun 2012 15:57:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=KtiUngnk1b8eudPFfcx+wTrTH8zjt8FhtIIX0ENFPsk=; b=OfmuLWYgZoEhMkB9spDOoaNSwXOZ9kFfiDb9IC0CHgbPlVa9vX7gnXDdczKlBIwcAz 5xZWif9MlSRPTcketyb4f1GZ9H/qGxK0gvOnnZbPqqlwR/aYUFY76zcLxaEU3Qtr3nha MLJYXfdQtc58tPHGvAxeDjBYVtp/Q4DYsk+Cy4e2H18JuSCQVpkQtRAcg6wl6YRG9sxQ cLmUcyyoYbIny7MjS3w4xFGHrWNV2I80giat0qmPrEHX1M3uCvveNpWbzzpjnisNvB0D jGtATuoWH+vZe0asKwL0EHb2yulUYGOM5cxqbshy7DU8iUIUQxddLWVM7nIG2nAOVEsT VUtg== Received: by 10.52.156.47 with SMTP id wb15mr2484324vdb.53.1340924258232; Thu, 28 Jun 2012 15:57:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.34.107 with HTTP; Thu, 28 Jun 2012 15:57:07 -0700 (PDT) In-Reply-To: <12F7B6DB-A371-4C53-8B5B-B34F3750E507@gmx.net> References: <699C916A-F8B1-40E8-8C3B-FCC9CBCC2C9F@gmx.net> <12F7B6DB-A371-4C53-8B5B-B34F3750E507@gmx.net> From: Brian Campbell Date: Thu, 28 Jun 2012 16:57:07 -0600 Message-ID: To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=bcaec53aef5815291304c390424f X-Gm-Message-State: ALoCoQlHiLZUj3wMpqG3jJUPNNEWIhuDlVIc2Wt7VU7P2ebLplBSG5c71+8X2zYYIcGD1ZmXqPBb Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-assertions-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, 28 Jun 2012 22:57:41 -0000 --bcaec53aef5815291304c390424f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Hannes, Near the end of =A71 of your draft -04 you discuss client authentication wi= th the Resource Server by saying that the client authentication concerns steps (E) and (F) in figure 1. However, my reading of =A72.3 of the core OAuth Framework[1] was that only client authentication to the AS was in scope for the spec. Following from that, my assumption and intent with the assertion spec was that client assertion authentication is only defined for a client authenticating to the token endpoint of an AS. =A73 of the -03 of the assertions doc[2] even says, "This specification provides a model for using assertions for authentication of an OAuth client during interactions with an Authorization Server". Was there something in the -03 draft (or the core spec for that matter) that suggested it was intended for client to RS authentication? I don't think specifying that (other than in defining how an access token is presented like draft-ietf-oauth-v2-bearer does) that would be appropriate. Maybe some clarification is needed? Thanks, Brian [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-28#section-2.3 [2] http://tools.ietf.org/html/draft-ietf-oauth-assertions-03#section-3 On Sun, Jun 24, 2012 at 7:42 AM, Hannes Tschofenig < Hannes.Tschofenig@gmx.net> wrote: > Hi Brian, > > thanks for your response. I have tried to put additional text into versio= n > -04 of the draft to address my earlier comments. > > The most recent version of the updated document is there: > > https://github.com/hannestschofenig/tschofenig-ids/blob/master/oauth-asse= rtions/draft-ietf-oauth-assertions-04.txt > > Here is the XML: > > https://github.com/hannestschofenig/tschofenig-ids/blob/master/oauth-asse= rtions/draft-ietf-oauth-assertions-04.xml > > It took me a little while to make these changes, as you can imagine. I > hope I was able to improve the quality and clarity of the document. > > I still have to respond to your second mail about the relaxed usage of th= e > RFC 2119 language. Will do that asap. > > Ciao > Hannes > > --bcaec53aef5815291304c390424f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Hannes,

Near the end of =A71 of your draft -04 you discuss clien= t authentication with the Resource Server by saying that the client authent= ication concerns steps (E) and (F) in figure 1. However, my reading of =A72= .3 of the core OAuth Framework[1] was that only client authentication to th= e AS was in scope for the spec. Following from that, my assumption and inte= nt with the assertion spec was that client assertion authentication is only= defined for a client authenticating to the token endpoint of an AS. =A73 o= f the -03 of the assertions doc[2] even says, "This specification prov= ides a model for using assertions for authentication of an OAuth client dur= ing interactions with an Authorization Server".

Was there something in the -03 draft (or the core spec for that matter)= that suggested it was intended for client to RS authentication? I don'= t think specifying that (other than in defining how an access token is pres= ented like draft-ietf-oauth-v2-bearer does) that would be appropriate. Mayb= e some clarification is needed?

Thanks,
Brian

[1] http://tools.ietf.org/html/draft-ietf-oauth-= v2-28#section-2.3
[2] http://tools.ietf.org/html/draft-ietf-oau= th-assertions-03#section-3

On Sun, Jun 24, 2012 at 7:42 AM, Hannes Tsch= ofenig <Hannes.Tschofenig@gmx.net> wrote:
Hi Brian,

thanks for your response. I have tried to put additional text into version = -04 of the draft to address my earlier comments.

The most recent version of the updated document is there:
https= ://github.com/hannestschofenig/tschofenig-ids/blob/master/oauth-assertions/= draft-ietf-oauth-assertions-04.txt

Here is the XML:
https= ://github.com/hannestschofenig/tschofenig-ids/blob/master/oauth-assertions/= draft-ietf-oauth-assertions-04.xml

It took me a little while to make these changes, as you can imagine. I hope= I was able to improve the quality and clarity of the document.

I still have to respond to your second mail about the relaxed usage of the = RFC 2119 language. Will do that asap.

Ciao
Hannes


--bcaec53aef5815291304c390424f-- From ve7jtb@ve7jtb.com Thu Jun 28 16:44:00 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F7CE21F8645 for ; Thu, 28 Jun 2012 16:44:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.441 X-Spam-Level: X-Spam-Status: No, score=-3.441 tagged_above=-999 required=5 tests=[AWL=0.157, 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 dHKfqkNZhZnc for ; Thu, 28 Jun 2012 16:43:58 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 44C2521F8624 for ; Thu, 28 Jun 2012 16:43:58 -0700 (PDT) Received: by ghbg16 with SMTP id g16so2587409ghb.31 for ; Thu, 28 Jun 2012 16:43:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=y0aptBFSEmgQ4Hlf2YvkwSrqS7StaRZZjq2O1zmqNgs=; b=iU9XxgGRIXUYZDTZF0uTalRNnL5E9sr4WKaMhXQx3EPeRed6zUod8j9syGA9yG+vup YCA+RbBjkiHVAA84m+cMAY1xmNaXmoqzDYerf+or/xE4NKonGqpc+XX8iBO+r/3uRZTG cuVaOlc4ORq0yEKqznzuYxqbBkjytSj5siMzMxTpeyafDqggebQfF1yuxCQ6K91xz0wj jEEGLbNfdXqjJsB2vYAMEPR1zMu7pvMwJUdQk4fT0uSTHQz5DU6xY7Yx8wWiPOwLgsIO BGWVPZC709DzPUgOmJZQTPdfJSTbCuKX311G+xZzOLhJQhuyJiRGsKUmq5eHnJHVrfeL uT/w== Received: by 10.236.191.131 with SMTP id g3mr6369683yhn.59.1340927037660; Thu, 28 Jun 2012 16:43:57 -0700 (PDT) Received: from [192.168.1.211] (190-20-45-203.baf.movistar.cl. [190.20.45.203]) by mx.google.com with ESMTPS id p14sm1003821ani.8.2012.06.28.16.43.54 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 28 Jun 2012 16:43:56 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_8F802F55-481D-47F6-89B8-C3DE1E7310E0"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <59E470B10C4630419ED717AC79FCF9A91A2D13C9@CH1PRD0410MB369.namprd04.prod.outlook.com> Date: Thu, 28 Jun 2012 19:43:47 -0400 Message-Id: <67F8B633-E4C8-42F6-B84C-FDBC337B7EEA@ve7jtb.com> References: <1339792496.52712.YahooMailNeo@web125501.mail.ne1.yahoo.com> <59E470B10C4630419ED717AC79FCF9A9108898EE@BL2PRD0410MB363.namprd04.prod.outlook.com> <4FE223E4.6060307@mitre.org> <4FE226BC.6010403@alcatel-lucent.com> <59E470B10C4630419ED717AC79FCF9A910889AB5@BL2PRD0410MB363.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A917052BC8@SN2PRD0410MB370.namprd04.prod.outlook.com> <4FE37D38.1030407@gmail.com> <59E470B10C4630419ED717AC79FCF9A91A2C8949@CH1PRD0410MB369.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A91A2D1309@CH1PRD0410MB369.namprd04.prod.outlook.com> <496AFB1D-A609-4188-B92D-2185E8880388@ve7jtb.com> <59E470B10C4630419ED717AC79FCF9A91A2D13C9@CH1PRD0410MB369.namprd04.prod.outlook.com> To: Lewis Adam-CAL022 X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQkWaCx1tgtlezDkynALi/o2A32UEgkN3M0zdmXwRt7XjZq+Z3EWN+9/aYBR3MQzgyolYI17 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Report an authentication issue X-BeenThere: oauth@ietf.org X-Mailman-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, 28 Jun 2012 23:44:00 -0000 --Apple-Mail=_8F802F55-481D-47F6-89B8-C3DE1E7310E0 Content-Type: multipart/alternative; boundary="Apple-Mail=_649FA8F1-8918-405E-A47E-E8B29F6E32D1" --Apple-Mail=_649FA8F1-8918-405E-A47E-E8B29F6E32D1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Adam, I am working on an additional security concern around Authentication for = the spec. The OAuth spec is about protecting the "Protected Resource" in your case = a video server. =20 That is exactly what OAuth is intended to do. The reason the term authorization is used is that the client can be a = 3rd party web service, a native app, or a JavaScript client in a user = Agent. In the case of the user granting a 3rd party service access to the video = server via the same OAuth mechanism you probably would not say that the = video server is authenticating the user as the user may well not be = present. The protected resource is validating that the 3rd party = service has been delegated access by the user (resource owner) via the = authorization server. In the case where you have a client that by design is running on a = device that is controlled by a single person and the person is = authenticating themselves to the authorization server and granting the = app access to the resource, you have crated a greatly constrained = profile that is effectively the same as Authentication of the device = holder to the resource. You are however doing that by using a = authorization mechanism and leveraging the constraints of your profile. There are however places you can get into trouble if you don't have the = correct profile and environment. The Authentication that openID Connect, Facebook and others are doing is = Authentication of the user to the client. You see this in a native App = like foursquare. In that case I use Facebook's Authorization server (same apples to = twitter) to identify myself to the app and give it access to push = notifications. I Authorize the App to access the Facebook graph API so it can get my = name and other information, so In some sense I have Authenticated to it, = and am logged in. That is all well and good. The problem comes in when the App passes the access token back to it's = own servers and they assume that I am logged into the app and can let it = post location information and get location history. This all works perfectly fine, on the face of it. The problem is that I also grant other clients access to my Facebook = graph API and they have valid access tokens to get my information. Any one of those sites that have access_tokens for my account can pass = that to foursquare over the API they have for their client and get my = information at foursquare. (I believe forsquare is now using a proprietary Facebook API to validate = that the token was issued to it's client_id to stop this attack now.) All public clients are susceptible to this not just Apps. The OAuth model works for you because you are using it the correct way = to protect the resource. Once you start using OAuth in ways not anticipated by the core spec, you = need to consider the new attack surface. Authenticating to the client is NOT safe with all of the flows unless = additional security mechanisms are in place like the openID Connect = id_token, or facebooks introspection endpoint, or facebooks's signed_request. =20 There are ways that OAuth can be used safely for Authentication to the = client but it requires profiling and extension. My concern is that inexperienced people not use OAuth to create simple = SSO flows with public clients, that are insecure for that purpose. So Adam the bottom line is you are good to go because you are using = OAuth as it is intended to be used. You can call it Authentication if you like, but that authentication is = based on a constrained profile of OAuth and tokens. It is a subset of = the general Authorization mechanism. While using JWT tokens brought to you by OpenID Connect may work as = access tokens, I don't see needing id_tokens or user_info endpoints. There may be other applications that you develop in the future that = might need them. I hope that helps. John B. On 2012-06-28, at 6:34 PM, Lewis Adam-CAL022 wrote: > Hi John, > =20 > It may be semantics, but in my use cases, the AS is not =93authorizing=94= anything. It=92s 1) authenticating the user, and 2) issuing a = structured JWT access_token which contains claims about the user (again, = just like the id_token, but as you said, aud=3DRS).=20 > =20 > The video client on the iPhone/Android uses this as a bearer token, = and includes it an a request to the video server. The video server uses = the claims in the JWT access_token to authenticate the user, and then = makes its own authorization decisions (e.g. maps user id to app-centric = roles, etc.) > =20 > If you still feel this is within the spirit of OAuth, then great :-) > =20 > My concern is still that one of our customer=92s will read your blog = and fire back at us =85 =93but John says OAuth is not for = authentication=94 ;) > =20 > This is why I would like to explore the idea of putting out an = informational draft profiling OAuth for authentication, since everybody = seems to at least agree that it can be profiled to do so. > =20 > Tx! > adam > =20 > From: John Bradley [mailto:ve7jtb@ve7jtb.com]=20 > Sent: Thursday, June 28, 2012 3:48 PM > To: Lewis Adam-CAL022 > Cc: Nat Sakimura; oauth@ietf.org > Subject: Re: [OAUTH-WG] Report an authentication issue > =20 > Adam, > =20 > This is getting tangled up in semantics. > =20 > The AS authenticates the user and Authorizes the client (native App) = to access the protected resource (video server) via issuing it a access = token, or a authorization code that it can trade at a token endpoint for = a refresh_token and access_token. > =20 > At that point the client has no notion of who the user is unless a = openID Connect id_token was also sent. I suspect that the video player = app may not care who the person, only what it can access. > =20 > The App then uses its access token to prove that it was delegated = access to the server by some person (Resource owner in OAuth speak). =20 > In your STS example you call this Authentication, but in OAuth it is = Authorization. The client is the one being authenticated to the = resource via the token. > The User is Authenticated to the AS. The same trust chain exists it = just uses different terms. > =20 > That token can be structured like the id_token is, but there is an = important difference. The access token's audience is the resource = server and the id_token's audience is the client. > That is one of the reasons they are separate. > =20 > This looks like a relatively strait forward OAuth use case to me, you = can probably also use opaque tokens with a AS STS and some caching logic = at the RS if you want to keep the token size down. > =20 > John B. > =20 > =20 > On 2012-06-28, at 4:13 PM, Lewis Adam-CAL022 wrote: >=20 >=20 > Hi Nat, > =20 > Starting from a standalone use case would be good.=20 > My impression (I may be wrong) is that your requirement is to be able = to=20 > =20 > (1) Log the user identifier of the person who is accessing the = resource at the resource server for the audit etc. purposes.=20 >=20 > yes =85 that *and* to authenticate the user in the first place. = So again, my access_token will actually look like the Connect id_token. = I would even prefer to use the id_token, except that it violate the = spirit of Connect to pass the id_token to the RS (e.g. it was only meant = for consumption by the client). > =20 > My problem space can be distilled to something very simple. =20 >=20 >=20 > - We come from a SOAP API world where we use WS-Trust to = secure the SOAP API calls. WS-Trust makes it very simple for a WS-* = client to collect the user=92s primary credentials, exchange it for a = (SAML) bearer token via the STS, and embed that bearer token in = SOAP-based API calls to the WS-* server. This is most definitely = *authentication* >=20 >=20 > - We are moving to a RESTful API world. I just want to be = able to do the same thing as above. How do I enable my REST-based client = to collect the user=92s password, exchange it for a (JWT) bearer token = via the STS, and embed that bearer token in RESTful API calls to the = REST-based server, such that the REST-based server can *authenticate* = the client? =20 >=20 >=20 > (2) Do the holder of the key so that the RS is sure that the person = accessing with the access token=20 > is really the person.=20 > =20 > that would be nice, but most of my users will be using passwords = in the beginning, so this is not an option. I=92m using the literal = definition of bearer token here, taken straight out of the OAuth bearer = token spec, e.g. =93Any party in possession of a bearer token (a = "bearer") can use it to get > access to the associated resources (without demonstrating possession = of a cryptographic key).=94 > =20 > (3) In addition, the RS may not be able to talk to AS directly. > [Well, this is one of my use case anyways.]=20 > =20 > Right =85 this is why I am now looking at structured JWTs. > =20 > (4) In some cases, the client may not be able to communicate with AS = directly at the time of RS access. [ditto] > =20 > Right again, we have disaster scenarios to think about where the = AS might not be reachable. but this is a use case for next steps. = Trying to walk before we fly here :-) > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_649FA8F1-8918-405E-A47E-E8B29F6E32D1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi Adam,

I am working on an = additional security concern around Authentication for the = spec.

The OAuth spec is about protecting the = "Protected Resource" in your case a video server.  
That = is exactly what OAuth is intended to do.

The = reason the term authorization is used is that the client can be a 3rd = party web service,  a native app, or a JavaScript client in a user = Agent.

In the case of the user granting a 3rd = party service access to the video server via the same OAuth mechanism = you probably would not say that the video server is authenticating the = user as the user may well not be present.   The protected resource = is validating that the 3rd party service has been delegated access by = the user (resource owner) via the authorization = server.

In the case where you have a client = that by design is running on a device that is controlled by a single = person and the person is authenticating themselves to the authorization = server and granting the app access to the resource, you have crated a = greatly constrained profile that is effectively the same as = Authentication of the device holder to the resource.   You are = however doing that by using a authorization mechanism and leveraging the = constraints of your profile.

There are however = places you can get into trouble if you don't have the correct profile = and environment.

The Authentication that openID = Connect, Facebook and others are doing is Authentication of the user to = the client.   You see this in a native App like = foursquare.

In that case I use Facebook's = Authorization server (same apples to twitter) to identify myself to the = app and give it access to push notifications.
I Authorize the = App to access the Facebook graph API so it can get my name and other = information, so In some sense I have Authenticated to it, and am logged = in.
That is all well and good.

The = problem comes in when the App passes the access token back to it's own = servers and they assume that I am logged into the app and can let it = post location information and get location history.
This all = works perfectly fine, on the face of it.

The = problem is that I also grant other clients access to my Facebook graph = API and they have valid access tokens to get my = information.

Any one of those sites that have = access_tokens for my account can pass that to foursquare over the API = they have for their client and get my information at = foursquare.
(I believe forsquare is now using a proprietary = Facebook API to validate that the token was issued to it's client_id to = stop this attack now.)

All public clients are = susceptible to this not just Apps.

The OAuth = model works for you because you are using it the correct way to protect = the resource.

Once you start using OAuth in = ways not anticipated by the core spec, you need to consider the new = attack surface.
Authenticating to the client is NOT safe with = all of the flows unless additional security mechanisms are in place like = the openID Connect id_token,  or facebooks introspection = endpoint,
or facebooks's signed_request. =   

There are ways that OAuth can be = used safely for Authentication to the client but it requires profiling = and extension.

My concern is that inexperienced = people not use OAuth to create simple SSO flows with public clients, = that are insecure for that purpose.

So Adam the = bottom line is you are good to go because you are using OAuth as it is = intended to be used.
You can call it Authentication if you = like, but that authentication is based on a constrained profile of OAuth = and tokens. It is a subset of the general Authorization = mechanism.
While using JWT tokens brought to you by OpenID = Connect may work as access tokens,  I don't see needing id_tokens = or user_info endpoints.
There may be other applications that = you develop in the future that might need = them.

I hope that helps.
John = B.




<= br>
On 2012-06-28, at 6:34 PM, Lewis Adam-CAL022 = wrote:

Hi John,
 
It may be semantics, but in my use = cases, the AS is not =93authorizing=94 anything.  It=92s 1) = authenticating the user, and 2) issuing a structured JWT access_token = which contains claims about the user (again, just like the id_token, but = as you said, aud=3DRS). 
 
The video client on the = iPhone/Android uses this as a bearer token, and includes it an a request = to the video server.  The video server uses the claims in the JWT = access_token to authenticate the user, and then makes its own = authorization decisions (e.g. maps user id to app-centric roles, = etc.)
 
If you still feel this is within the spirit of OAuth, then = great :-)
 
My concern is still that one of our customer=92s will read your = blog and fire back at us =85 =93but John says OAuth is not for = authentication=94  ;)
 
This is why I would like to = explore the idea of putting out an informational draft profiling OAuth = for authentication, since everybody seems to at least agree that it can = be profiled to do so.
Tx!
adam
From: John Bradley = [mailto:ve7jtb@ve7jtb.com] 
Sent: Thursday, June 28, 2012 = 3:48 PM
To: Lewis = Adam-CAL022
Cc: Nat Sakimura; oauth@ietf.org
Subject: Re: [OAUTH-WG] Report an = authentication issue
 
This is getting tangled = up in semantics.
The AS authenticates the = user and Authorizes the client (native App) to access the protected = resource (video server) via issuing it a access token, or a = authorization code that it can trade at a token endpoint for a = refresh_token and access_token.
 
At that point the client has no notion of who the user = is unless a openID Connect id_token was also sent.  I suspect that = the video player app may not care who the person, only what it can = access.
The App then uses its = access token to prove that it was delegated access to the server by some = person (Resource owner in OAuth speak). =  
In your STS example you = call this Authentication, but in OAuth it is Authorization.  The = client is the one being authenticated to the resource via the = token.
The User is Authenticated = to the AS.   The same trust chain exists it just uses different = terms.
That token can be = structured like the id_token is, but there is an important difference. =  The access token's audience is the resource server and the = id_token's audience is the client.
That is one of the reasons they are = separate.
This looks like a = relatively strait forward OAuth use case to me,  you can probably = also use opaque tokens with a AS STS and some caching logic at the RS if = you want to keep the token size down.
 
John B.
 
 
On 2012-06-28, at 4:13 PM, Lewis Adam-CAL022 = wrote:
Hi = Nat,
Starting from = a standalone use case would be = good. 
My impression (I may be wrong) is that your requirement = is to be able to 
 
(1) Log the user identifier of the person who is = accessing the resource at the resource server for the audit etc. = purposes. 

<acl> yes =85 that *and* to = authenticate the user in the first place.  So again, my = access_token will actually look like the Connect id_token.  I would = even prefer to use the id_token, except that it violate the spirit of = Connect to pass the id_token to the RS (e.g. it was only meant for = consumption by the client).
 
My problem space can be distilled to something very = simple.  


- We come from = a SOAP API world where we use WS-Trust to secure the SOAP API = calls.  WS-Trust makes it very simple for a WS-* client to collect = the user=92s primary credentials, exchange it for a (SAML) bearer token = via the STS, and embed that bearer token in SOAP-based API calls to the = WS-* server. This is most definitely = *authentication*


 We are moving = to a RESTful API world.  I just want to be able to do the same = thing as above. How do I enable my REST-based client to collect the = user=92s password, exchange it for a (JWT) bearer token via the STS, and = embed that bearer token in RESTful API calls to the REST-based server, = such that the REST-based server can *authenticate* the = client?  


(2) Do the holder of the = key so that the RS is sure that the person accessing with the access = token 
     is really the = person. 
<acl> = that would be nice, but most of my users will be using passwords in the = beginning, so this is not an option.  I=92m using the literal = definition of bearer token here, taken straight out of the OAuth bearer = token spec, e.g. =93Any party in = possession of a bearer token (a "bearer") can use it to = get
access to the = associated resources (without demonstrating possession of a = cryptographic key).=94
 
(3) In addition, the RS may not be able to talk to AS = directly.
    =  [Well, this is one of my use case = anyways.] 
<acl> = Right =85 this is why I am now looking at structured = JWTs.
(4) In some cases, the client may not be able to = communicate with AS directly at the time of RS access. = [ditto]
<acl> = Right again, we have disaster scenarios to think about where the AS = might not be reachable.  but this is a use case for next = steps.  Trying to walk before we fly here = :-)
OAuth@ietf.org

I have a question in the example for section 1.2 in the OAuth 1.0= RFC 5849. The example in the API calling to access the protected resource.=

Where it =A0reads:


With a set of token= credentials, the client is now ready to request
=A0 the private photo:

=A0 =A0 GET /photos?file=3Dvacation.jpg&= ;size=3Doriginal HTTP/1.1
=A0 =A0 Host: photos.example.net
=A0 =A0 Authorization: OAuth realm=3D&quo= t;Photos",
=A0 =A0 =A0 =A0oauth_consumer_key=3D"dpf43f3p2l4k3l03",
=A0 = =A0 =A0 =A0oauth_token=3D"nnch734d00sl2jdk",
=A0 =A0 =A0 =A0o= auth_signature_method=3D"HMAC-SHA1",
=A0 =A0 =A0 =A0oauth_tim= estamp=3D"137131202",
=A0 =A0 =A0 =A0oauth_nonce=3D"chapoH",
=A0 =A0 =A0 =A0oauth_signature=3D"MdpQcU8iPSUjWoN%2FUDMsK2sui9I%3D&qu= ot;

I don't know how does the client know the parame= ter value "vacation.jpg" in the API "http://photos.example.net/photos". =A0The qu= estion is, how does the client can get the name(s) of protected=A0resource?= The use Jane gave it or the server gave?

Best regards,

J. Lu
--f46d040838d3ca6d9804c393d785-- From asanso@adobe.com Fri Jun 29 09:53:37 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07EF221F861F for ; Fri, 29 Jun 2012 09:53:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SGWR4w7RSRbp for ; Fri, 29 Jun 2012 09:53:35 -0700 (PDT) Received: from exprod6og113.obsmtp.com (exprod6og113.obsmtp.com [64.18.1.31]) by ietfa.amsl.com (Postfix) with ESMTP id 967BA21F86FD for ; Fri, 29 Jun 2012 09:53:33 -0700 (PDT) Received: from outbound-smtp-1.corp.adobe.com ([192.150.11.134]) by exprod6ob113.postini.com ([64.18.5.12]) with SMTP ID DSNKT+3djN0CRKmVEHyNdMzG6uYPsSuClSu0@postini.com; Fri, 29 Jun 2012 09:53:35 PDT Received: from inner-relay-4.eur.adobe.com (inner-relay-4.adobe.com [193.104.215.14]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id q5TGpBJ0017112; Fri, 29 Jun 2012 09:51:12 -0700 (PDT) Received: from nacas03.corp.adobe.com (nacas03.corp.adobe.com [10.8.189.121]) by inner-relay-4.eur.adobe.com (8.12.10/8.12.9) with ESMTP id q5TGq3ZX014184; Fri, 29 Jun 2012 09:53:30 -0700 (PDT) Received: from eurcas01.eur.adobe.com (10.128.4.27) by nacas03.corp.adobe.com (10.8.189.121) with Microsoft SMTP Server (TLS) id 8.3.192.1; Fri, 29 Jun 2012 09:53:22 -0700 Received: from eurmbx01.eur.adobe.com ([10.128.4.32]) by eurcas01.eur.adobe.com ([10.128.4.27]) with mapi; Fri, 29 Jun 2012 17:53:20 +0100 From: Antonio Sanso To: John Bradley Date: Fri, 29 Jun 2012 17:53:14 +0100 Thread-Topic: [OAUTH-WG] Report an authentication issue Thread-Index: Ac1WF6+J+JhwG8+BS4CG6sEXesvAUQ== Message-ID: <04C05FAA-63BC-4441-8540-36280E40DB98@adobe.com> References: <1339792496.52712.YahooMailNeo@web125501.mail.ne1.yahoo.com> <59E470B10C4630419ED717AC79FCF9A9108898EE@BL2PRD0410MB363.namprd04.prod.outlook.com> <4FE223E4.6060307@mitre.org> <4FE226BC.6010403@alcatel-lucent.com> <59E470B10C4630419ED717AC79FCF9A910889AB5@BL2PRD0410MB363.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A917052BC8@SN2PRD0410MB370.namprd04.prod.outlook.com> <4FE37D38.1030407@gmail.com> <59E470B10C4630419ED717AC79FCF9A91A2C8949@CH1PRD0410MB369.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A91A2D1309@CH1PRD0410MB369.namprd04.prod.outlook.com> <496AFB1D-A609-4188-B92D-2185E8880388@ve7jtb.com> <59E470B10C4630419ED717AC79FCF9A91A2D13C9@CH1PRD0410MB369.namprd04.prod.outlook.com> <67F8B633-E4C8-42F6-B84C-FDBC337B7EEA@ve7jtb.com> In-Reply-To: <67F8B633-E4C8-42F6-B84C-FDBC337B7EEA@ve7jtb.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Report an authentication issue X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 16:53:37 -0000 Hi John On Jun 29, 2012, at 1:43 AM, John Bradley wrote: > Authenticating to the client is NOT safe with all of the flows you are perfectly right here. At the begin of this discussion and reading y= our blog post I was under the impression that this "attack" was tight to th= e use of the implicit grant flaw. But this is not actually the case as I could reproduce the same scenario ag= ainst a client using the Authorization Code flaw. Regards Antonio From jricher@mitre.org Fri Jun 29 10:24:31 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0011821F860E for ; Fri, 29 Jun 2012 10:24:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 qhkCP5-x80Tc for ; Fri, 29 Jun 2012 10:24:30 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 40F4221F864B for ; Fri, 29 Jun 2012 10:24:30 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 60BFA21B13BC; Fri, 29 Jun 2012 13:24:29 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 4F3A121B08F0; Fri, 29 Jun 2012 13:24:29 -0400 (EDT) Received: from [129.83.50.26] (129.83.31.51) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.2.283.3; Fri, 29 Jun 2012 13:24:28 -0400 Message-ID: <4FEDE4AF.9030107@mitre.org> Date: Fri, 29 Jun 2012 13:23:59 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Antonio Sanso References: <4FE223E4.6060307@mitre.org> <4FE226BC.6010403@alcatel-lucent.com> <59E470B10C4630419ED717AC79FCF9A910889AB5@BL2PRD0410MB363.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A917052BC8@SN2PRD0410MB370.namprd04.prod.outlook.com> <4FE37D38.1030407@gmail.com> <59E470B10C4630419ED717AC79FCF9A91A2C8949@CH1PRD0410MB369.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A91A2D1309@CH1PRD0410MB369.namprd04.prod.outlook.com> <496AFB1D-A609-4188-B92D-2185E8880388@ve7jtb.com> <59E470B10C4630419ED717AC79FCF9A91A2D13C9@CH1PRD0410MB369.namprd04.prod.outlook.com> <67F8B633-E4C8-42F6-B84C-FDBC337B7EEA@ve7jtb.com> <04C05FAA-63BC-4441-8540-36280E40DB98@adobe.com> In-Reply-To: <04C05FAA-63BC-4441-8540-36280E40DB98@adobe.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [129.83.31.51] Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Report an authentication issue X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 17:24:31 -0000 It's all about how you can swipe a token and inject it into another application. It's easier to trap and inject a token in the implicit flow because it's exposed to the user agent and there's no client secret tied to the token's issuance. To get the same trick to work with the code flow on server-based confidential clients, you'd need to inject your rogue token into the client's configuration or state. With the implicit flow and on devices, it's a bit easier just because the parts of the system that need access to the token are more accessible. -- Justin On 06/29/2012 12:53 PM, Antonio Sanso wrote: > Hi John > > On Jun 29, 2012, at 1:43 AM, John Bradley wrote: > >> Authenticating to the client is NOT safe with all of the flows > you are perfectly right here. At the begin of this discussion and reading your blog post I was under the impression that this "attack" was tight to the use of the implicit grant flaw. > But this is not actually the case as I could reproduce the same scenario against a client using the Authorization Code flaw. > > Regards > > Antonio > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From ve7jtb@ve7jtb.com Fri Jun 29 11:06:56 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0286621F8831 for ; Fri, 29 Jun 2012 11:06:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.445 X-Spam-Level: X-Spam-Status: No, score=-3.445 tagged_above=-999 required=5 tests=[AWL=0.153, 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 pPXmmZgo46Ff for ; Fri, 29 Jun 2012 11:06:54 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id A6B7F21F8821 for ; Fri, 29 Jun 2012 11:06:54 -0700 (PDT) Received: by yenq13 with SMTP id q13so3342726yen.31 for ; Fri, 29 Jun 2012 11:06:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=esRoBC0aH4zwAeVDBLItHDcx/ufo22zrCN1WF4PQAws=; b=iovvqkZE4UHd6UgQKTkKrlHciPcWDvPolOjvgM4ejiQkpdcpj/dR33F7o+0gPC3S2G hWo22olFU90v3FtqSib/2E2PArAyTMJfFW2IlC0/uGuwzOBGQ15PPqCysCK0zMMuAhb5 2awETztpXi5NlN/m9mKvWK2lKkHskxAl4wySjMq0Wp38K6t2tlKvvU5rYEBOThP9P2VO XTDO9iC9d6CQLYHmvGuoZ5gC6e/3KI0rVD1itvByPu/kOTlA96di9BEwRnb0CSLfgBUr jU+7M8ByV8paRsJYHqP/Y6uNqV44Hl6douS8D124JrpnRz89AlZCHWZZAJ3F5YPjxKAl dnQw== Received: by 10.236.192.162 with SMTP id i22mr4256744yhn.83.1340993214189; Fri, 29 Jun 2012 11:06:54 -0700 (PDT) Received: from [192.168.1.211] (190-20-59-251.baf.movistar.cl. [190.20.59.251]) by mx.google.com with ESMTPS id e19sm3735455ann.10.2012.06.29.11.06.51 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 29 Jun 2012 11:06:53 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_9ED9E059-97AB-4048-9D3A-1BBC9C6F9425"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <4FEDE4AF.9030107@mitre.org> Date: Fri, 29 Jun 2012 14:06:44 -0400 Message-Id: <4DD23AA1-C319-477A-B0CB-34E558EB7FCC@ve7jtb.com> References: <4FE223E4.6060307@mitre.org> <4FE226BC.6010403@alcatel-lucent.com> <59E470B10C4630419ED717AC79FCF9A910889AB5@BL2PRD0410MB363.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A917052BC8@SN2PRD0410MB370.namprd04.prod.outlook.com> <4FE37D38.1030407@gmail.com> <59E470B10C4630419ED717AC79FCF9A91A2C8949@CH1PRD0410MB369.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A91A2D1309@CH1PRD0410MB369.namprd04.prod.outlook.com> <496AFB1D-A609-4188-B92D-2185E8880388@ve7jtb.com> <59E470B10C4630419ED717AC79FCF9A91A2D13C9@CH1PRD0410MB369.namprd04.prod.outlook.com> <67F8B633-E4C8-42F6-B84C-FDBC337B7EEA@ve7jtb.com> <04C05FAA-63BC-4441-8540-36280E40DB98@adobe.com> <4FEDE4AF.9030107@mitre.org> To: Justin Richer X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQmXJiVwIrLuaIXwqSWUtJgpT4qZBkY+455NPtmchCmPMcX/DU9WaRHR6GDTrAU1ACdtfLT5 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Report an authentication issue X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 18:06:56 -0000 --Apple-Mail=_9ED9E059-97AB-4048-9D3A-1BBC9C6F9425 Content-Type: multipart/alternative; boundary="Apple-Mail=_7F5B4325-3BEE-4BC3-8DAD-E278E3AD052F" --Apple-Mail=_7F5B4325-3BEE-4BC3-8DAD-E278E3AD052F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 It is nice to know that I may occasionally be correct:) For Server based confidential clients the risks are quite minimal as = Justin points out. There are likely other more interesting things you = could do if you already have the ability to run arbitrary code on the = server. No matter what flow or client you are using, passing the access token = from that client to some other server as a method of authentication is = not a good idea unless you have some way to guarantee that it is a = legitimate client that hasn't been compromised. Creating a fake App = with a stolen client ID is trivial. So passing access tokens as a = proxy for authentication between unauthenticated apps is a recopy for = disaster. It sort of falls under the category of bad things that can happen if you = just make up new flows for tokens that are not in the spec. Where it gets a bit grey is public clients using the code flow. =20 If you look at Sec 3.2.1 only confidential clients Must Authenticate to = the token endpoint. A public client like a native app: A public client that was not issued a client password MAY use the "client_id" request parameter to identify itself when sending requests to the token endpoint (e.g. for the purpose of providing end-user context, client usage statistics). While you may assume that it is reasonable for a client with a code to = make a request to the token endpoint including it's client_id and the = server to only give out the access token if the client_id in the token = request matches the one in the original authorization request. However = the spec specifically doesn't require that. I think that it has to do with the precept of threat. If you are simply using OAuth strictly for Authorization then it would = make mo sense for an attacker who gets a valid code to not use it = directly to access the protected resource. However if you can escalate the codes privilege by impersonating the = resource owner at a legitimate public client then an attacker might do = it to get into another system. So if the public client is perhaps vulnerable. Now I can't imagine = someone running a public client on a web server, but this would be a = good reason not to. =20 In general the public client would be a native app, and not easy to = inject a stolen code into. I don't have a explanation as to why public clients using the code flow = are not minimally identified via their client_id. =20 I suspect most implementations are doing that if they have public = clients using the code flow, but I have not tested that theory. So the code flow is safer but there are some things you need to be = careful of with any public client. John B. On 2012-06-29, at 1:23 PM, Justin Richer wrote: > It's all about how you can swipe a token and inject it into another = application. It's easier to trap and inject a token in the implicit flow = because it's exposed to the user agent and there's no client secret tied = to the token's issuance. To get the same trick to work with the code = flow on server-based confidential clients, you'd need to inject your = rogue token into the client's configuration or state. With the implicit = flow and on devices, it's a bit easier just because the parts of the = system that need access to the token are more accessible. >=20 > -- Justin >=20 > On 06/29/2012 12:53 PM, Antonio Sanso wrote: >> Hi John >>=20 >> On Jun 29, 2012, at 1:43 AM, John Bradley wrote: >>=20 >>> Authenticating to the client is NOT safe with all of the flows >> you are perfectly right here. At the begin of this discussion and = reading your blog post I was under the impression that this "attack" was = tight to the use of the implicit grant flaw. >> But this is not actually the case as I could reproduce the same = scenario against a client using the Authorization Code flaw. >>=20 >> Regards >>=20 >> Antonio >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 --Apple-Mail=_7F5B4325-3BEE-4BC3-8DAD-E278E3AD052F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 It is = nice to know that I may occasionally be correct:)

For = Server based confidential clients the risks are quite minimal as Justin = points out.   There are likely other more interesting things you = could do if you already have the ability to run arbitrary code on the = server.

No matter what flow or client you are = using, passing the access token from that client to some other server as = a method of authentication is not a good idea unless you have some way = to guarantee that it is a legitimate client that hasn't been = compromised.   Creating a fake App with a stolen client ID is = trivial.   So passing access tokens as a proxy for authentication = between unauthenticated apps is a recopy for disaster.
It sort = of falls under the category of bad things that can happen if you just = make up new flows for tokens that are not in the = spec.

Where it gets a bit grey is public = clients using the code flow.  
If you look at Sec 3.2.1 = only confidential clients Must Authenticate to the token = endpoint.

A public client like a native = app:
A public client that was not issued a client =
password MAY use the
   "client_id" request parameter to identify itself when sending
   requests to the token endpoint (e.g. for the purpose of providing
   end-user context, client usage =
statistics).

While you may = assume that it is reasonable for a client with a code to make a request = to the token endpoint including it's client_id and the server to only = give out the access token if the client_id in the token request matches = the one in the original authorization request.   However the spec = specifically doesn't require that.

I think that = it has to do with the precept of threat.

If you = are simply using OAuth strictly for Authorization then it would make mo = sense for an attacker who gets a valid code to not use it directly to = access the protected resource.

However if you = can escalate the codes privilege by impersonating the resource owner at = a legitimate public client then an attacker might do it to get into = another system.

So if the public client is = perhaps vulnerable.  Now I can't imagine someone running a public = client on a web server, but this would be a good reason not to. =  
In general the public client would be a native app, and = not easy to inject a stolen code into.

I don't = have a explanation as to why public clients using the code flow are not = minimally identified via their client_id.  
I suspect = most implementations are doing that if they have public clients using = the code flow, but I have not tested that = theory.

So the code flow is safer but there are = some things you need to be careful of with any public = client.

John = B.

On 2012-06-29, at 1:23 PM, Justin = Richer wrote:

It's all about how you can swipe a token and inject = it into another application. It's easier to trap and inject a token in = the implicit flow because it's exposed to the user agent and there's no = client secret tied to the token's issuance. To get the same trick to = work with the code flow on server-based confidential clients, you'd need = to inject your rogue token into the client's configuration or state. = With the implicit flow and on devices, it's a bit easier just because = the parts of the system that need access to the token are more = accessible.

-- Justin

On 06/29/2012 12:53 PM, Antonio = Sanso wrote:
Hi = John

On Jun 29, = 2012, at 1:43 AM, John Bradley wrote:

Authenticating to the client is NOT safe with all of the = flows
you are = perfectly right here. At the begin of this discussion and reading your = blog post I was under the impression that this "attack" was tight to the = use of the implicit grant flaw.
But this is not actually the case as I could reproduce the = same scenario against a client using the Authorization Code = flaw.

Regards

Antonio

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



= --Apple-Mail=_7F5B4325-3BEE-4BC3-8DAD-E278E3AD052F-- --Apple-Mail=_9ED9E059-97AB-4048-9D3A-1BBC9C6F9425 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw 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+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDYy OTE4MDY0NVowIwYJKoZIhvcNAQkEMRYEFBYpbfnva2hDWEY007dyQI9+SelQMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB ADcmOj0grHTmM5lx7v9z7FrVNyyBvAy0guZy61n3T8s13IVHt0NpEHXDcnQTBGsz0vgjvb0UfJAu xV8rb1hu8TKEiuL1j714yIrSlfshukyLjwdBDwXKMGb0Ycx5y5IUNvAiNTp7jWDOLMUIb2yIa0sD AR9sBCR5+ELGPMg/W/z712iLP4GA2rfDzfdhjgsbzoARe7WKTUJyZX3AEZUQ8PqPrHF4pRkwsXpt kMQnbvMKd4e5NS+xCfLYU0W3+JSW6xCNxCLYmMhcCUowgiOGXZmBn8VlESq7YAyYJQBHLqNLbjO2 rW7Z2aMb+2RBHoQa0OYGa+cXFPaDrpLelYIZAewAAAAAAAA= --Apple-Mail=_9ED9E059-97AB-4048-9D3A-1BBC9C6F9425-- From dick.hardt@gmail.com Fri Jun 29 11:14:16 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50D6521F884A for ; Fri, 29 Jun 2012 11:14:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.579 X-Spam-Level: X-Spam-Status: No, score=-3.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rGjbldLG6Fn4 for ; Fri, 29 Jun 2012 11:14:15 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 92E0321F86F4 for ; Fri, 29 Jun 2012 11:14:15 -0700 (PDT) Received: by dacx6 with SMTP id x6so4885502dac.31 for ; Fri, 29 Jun 2012 11:14:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=pWGrLYi8Kv7DgJNpo3BkBPpXY2QmPZqpu+T88IKwKF0=; b=0Rn7reFup2k5TYYktlfj0HLzpRbCz9cyOXRKUZIn9bZ96jRHeANnD5aFM3Gs5AhVl/ DPIUX6nLoIaK872fZJ1+R/l7AJxqheCmXqlXK1PvUFHagwtvFY8QZaru4yoeDVmBSUOm Y06mIk4BVEhHdrjUczjKVJbcTrJDd9TCzQhs7SgjnBDP/rQWnU/JbzigC5B28/g1Y4JA VzGgFKq17n/nXxz86a5dyAnLQkVyTvgwy3BzJ3ofkAJi2/9enDGLgXD4FACcNB2SEbJR ibdX7xaOQ/9nx4KH4UaTtDUGdCOm8D6/MbK+2zlmOAI78Wqw7+1XncOsGUH0FK5Ruvrv yR+A== Received: by 10.68.226.65 with SMTP id rq1mr8765457pbc.25.1340993655399; Fri, 29 Jun 2012 11:14:15 -0700 (PDT) Received: from [10.0.0.4] (c-24-5-69-173.hsd1.ca.comcast.net. [24.5.69.173]) by mx.google.com with ESMTPS id mt9sm6120323pbb.14.2012.06.29.11.14.12 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 29 Jun 2012 11:14:13 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Dick Hardt In-Reply-To: <4DD23AA1-C319-477A-B0CB-34E558EB7FCC@ve7jtb.com> Date: Fri, 29 Jun 2012 11:14:09 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8C18C43D-AC63-465A-ADC2-966CE7F38685@gmail.com> References: <4FE223E4.6060307@mitre.org> <4FE226BC.6010403@alcatel-lucent.com> <59E470B10C4630419ED717AC79FCF9A910889AB5@BL2PRD0410MB363.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A917052BC8@SN2PRD0410MB370.namprd04.prod.outlook.com> <4FE37D38.1030407@gmail.com> <59E470B10C4630419ED717AC79FCF9A91A2C8949@CH1PRD0410MB369.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A91A2D1309@CH1PRD0410MB369.namprd04.prod.outlook.com> <496AFB1D-A609-4188-B92D-2185E8880388@ve7jtb.com> <59E470B10C4630419ED717AC79FCF9A91A2D13C9@CH1PRD0410MB369.namprd04.prod.outlook.com> <67F8B633-E4C8-42F6-B84C-FDBC337B7EEA@ve7jtb.com> <04C05FAA-63BC-4441-8540-36280E40DB98@adobe.com> <4FEDE4AF.9030107@mitre.org> <4 DD23AA1-C319-477A-B0CB-34E558EB7FCC@ve7jtb.com> To: John Bradley X-Mailer: Apple Mail (2.1278) Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Report an authentication issue X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 18:14:16 -0000 On Jun 29, 2012, at 11:06 AM, John Bradley wrote: > It is nice to know that I may occasionally be correct:) You must be delighted when it happens! ;) > While you may assume that it is reasonable for a client with a code to = make a request to the token endpoint including it's client_id and the = server to only give out the access token if the client_id in the token = request matches the one in the original authorization request. However = the spec specifically doesn't require that. I think that is an error in the spec and should be changed, or text = adding saying that the client_id SHOULD be checked. -- Dick= From Michael.Jones@microsoft.com Fri Jun 29 11:19:30 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B269421F884B for ; Fri, 29 Jun 2012 11:19:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.74 X-Spam-Level: X-Spam-Status: No, score=-3.74 tagged_above=-999 required=5 tests=[AWL=-0.141, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ibVEw+Jur48l for ; Fri, 29 Jun 2012 11:19:29 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe002.messaging.microsoft.com [216.32.180.12]) by ietfa.amsl.com (Postfix) with ESMTP id 6AA9A21F8820 for ; Fri, 29 Jun 2012 11:19:29 -0700 (PDT) Received: from mail168-va3-R.bigfish.com (10.7.14.236) by VA3EHSOBE009.bigfish.com (10.7.40.29) with Microsoft SMTP Server id 14.1.225.23; Fri, 29 Jun 2012 18:17:39 +0000 Received: from mail168-va3 (localhost [127.0.0.1]) by mail168-va3-R.bigfish.com (Postfix) with ESMTP id D9BDD6056A; Fri, 29 Jun 2012 18:17:38 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC105.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -28 X-BigFish: VS-28(zz98dI9371I542M1418Izz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25hf0ah) Received-SPF: pass (mail168-va3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC105.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail168-va3 (localhost.localdomain [127.0.0.1]) by mail168-va3 (MessageSwitch) id 1340993857463278_27090; Fri, 29 Jun 2012 18:17:37 +0000 (UTC) Received: from VA3EHSMHS024.bigfish.com (unknown [10.7.14.254]) by mail168-va3.bigfish.com (Postfix) with ESMTP id 63B4638008E; Fri, 29 Jun 2012 18:17:37 +0000 (UTC) Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS024.bigfish.com (10.7.99.34) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 29 Jun 2012 18:17:34 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.53]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.02.0309.003; Fri, 29 Jun 2012 18:19:21 +0000 From: Mike Jones To: Dick Hardt , John Bradley Thread-Topic: [OAUTH-WG] Report an authentication issue Thread-Index: AQHNSlHaFIGJ2TaCYUay3+9BxGDympb6Sh8AgAGN4wCAAD32AIAAM+GAgADc54CABh+HgIAAWkIAgAADZACAAAvgAIAAUFeAgAD5bYCAAEKiAIAESd6AgAHLvYCAA9dCAIABFy4AgAAJsgCAAB3qAIAAEzuAgAEfoACAAAiXgIAAC/IAgAACEoCAAAFbAA== Date: Fri, 29 Jun 2012 18:19:20 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436656ED42@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <4FE223E4.6060307@mitre.org> <4FE226BC.6010403@alcatel-lucent.com> <59E470B10C4630419ED717AC79FCF9A910889AB5@BL2PRD0410MB363.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A917052BC8@SN2PRD0410MB370.namprd04.prod.outlook.com> <4FE37D38.1030407@gmail.com> <59E470B10C4630419ED717AC79FCF9A91A2C8949@CH1PRD0410MB369.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A91A2D1309@CH1PRD0410MB369.namprd04.prod.outlook.com> <496AFB1D-A609-4188-B92D-2185E8880388@ve7jtb.com> <59E470B10C4630419ED717AC79FCF9A91A2D13C9@CH1PRD0410MB369.namprd04.prod.outlook.com> <67F8B633-E4C8-42F6-B84C-FDBC337B7EEA@ve7jtb.com> <04C05FAA-63BC-4441-8540-36280E40DB98@adobe.com> <4FEDE4AF.9030107@mitre.org> <4 DD23AA1-C319-477A-B0CB-34E558EB7FCC@ve7jtb.com> <8C18C43D-AC63-465A-ADC2-966CE7F38685@gmail.com> In-Reply-To: <8C18C43D-AC63-465A-ADC2-966CE7F38685@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.74] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Report an authentication issue X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 18:19:31 -0000 +1 to Dick's suggestion -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of D= ick Hardt Sent: Friday, June 29, 2012 11:14 AM To: John Bradley Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Report an authentication issue On Jun 29, 2012, at 11:06 AM, John Bradley wrote: > It is nice to know that I may occasionally be correct:) You must be delighted when it happens! ;) > While you may assume that it is reasonable for a client with a code to ma= ke a request to the token endpoint including it's client_id and the server = to only give out the access token if the client_id in the token request mat= ches the one in the original authorization request. However the spec spec= ifically doesn't require that. I think that is an error in the spec and should be changed, or text adding = saying that the client_id SHOULD be checked. -- Dick _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From phil.hunt@oracle.com Fri Jun 29 11:22:47 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EA9A21F867A for ; Fri, 29 Jun 2012 11:22:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.491 X-Spam-Level: X-Spam-Status: No, score=-10.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GWNyhT4o4FHJ for ; Fri, 29 Jun 2012 11:22:46 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id 05A0821F86A7 for ; Fri, 29 Jun 2012 11:22:45 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q5TIMhQD027433 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 29 Jun 2012 18:22: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 q5TIMhh1008304 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Jun 2012 18:22:43 GMT Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q5TIMh8W011931; Fri, 29 Jun 2012 13:22:43 -0500 Received: from [192.168.1.8] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 29 Jun 2012 11:22:42 -0700 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Phil Hunt In-Reply-To: <8C18C43D-AC63-465A-ADC2-966CE7F38685@gmail.com> Date: Fri, 29 Jun 2012 11:22:42 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <71899C6B-40A6-46E8-BCF8-BF9C43B83C64@oracle.com> References: <4FE223E4.6060307@mitre.org> <4FE226BC.6010403@alcatel-lucent.com> <59E470B10C4630419ED717AC79FCF9A910889AB5@BL2PRD0410MB363.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A917052BC8@SN2PRD0410MB370.namprd04.prod.outlook.com> <4FE37D38.1030407@gmail.com> <59E470B10C4630419ED717AC79FCF9A91A2C8949@CH1PRD0410MB369.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A91A2D1309@CH1PRD0410MB369.namprd04.prod.outlook.com> <496AFB1D-A609-4188-B92D-2185E8880388@ve7jtb.com> <59E470B10C4630419ED717AC79FCF9A91A2D13C9@CH1PRD0410MB369.namprd04.prod.outlook.com> <67F8B633-E4C8-42F6-B84C-FDBC337B7EEA@ve7jtb.com> <04C05FAA-63BC-4441-8540-36280E40DB98@adobe.com> <4FEDE4AF.9030107@mitre.org> <8C18C43D-AC63-465A-ADC2-966CE7F38685@gmail.com> To: Dick Hardt X-Mailer: Apple Mail (2.1278) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Report an authentication issue X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 18:22:47 -0000 I'm not clear whether the MS Security Researcher hack was with the = authorization code or the access token. If the latter, the client_id is = out of the picture isn't it? Phil @independentid www.independentid.com phil.hunt@oracle.com On 2012-06-29, at 11:14 AM, Dick Hardt wrote: >=20 > On Jun 29, 2012, at 11:06 AM, John Bradley wrote: >=20 >> It is nice to know that I may occasionally be correct:) >=20 > You must be delighted when it happens! ;) >=20 >> While you may assume that it is reasonable for a client with a code = to make a request to the token endpoint including it's client_id and the = server to only give out the access token if the client_id in the token = request matches the one in the original authorization request. However = the spec specifically doesn't require that. >=20 > I think that is an error in the spec and should be changed, or text = adding saying that the client_id SHOULD be checked. >=20 > -- Dick > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From ve7jtb@ve7jtb.com Fri Jun 29 11:25:24 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B452121F882E for ; Fri, 29 Jun 2012 11:25:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.45 X-Spam-Level: X-Spam-Status: No, score=-3.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IhfkhytsL+s8 for ; Fri, 29 Jun 2012 11:25:23 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 998CC21F8859 for ; Fri, 29 Jun 2012 11:25:23 -0700 (PDT) Received: by ghbg16 with SMTP id g16so3387740ghb.31 for ; Fri, 29 Jun 2012 11:25:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=aaud+JE3XMTtFk0tcJqazUyHgRUpSQ0EDMyKHuuqSPE=; b=Qbqn3QR4B1bKnLramDzuAbm9gsG5ePqEE9Dj0186Mon/tiux7megVYgUXugbS5dZR4 6DjppW4QzPoakjYMeAu+BKScpsv0qGm4oWX84XoqJze1nte/gGrOX2gAbF/nVZtjHUjj 7A9i0IxjHcW4XzUVu05Yx+d18xjOO6Kz4dmaSe4aToYcdGY13aJz1jtc0w+gkrmLgGt3 kgM/EFca5wj3Cny2ioAUN3Qvaf08m4+2x7vw0pIdKC+NT8jfPNmbZQq/owqpQogdjIUC weaCOPuFVJ8/82cDQ7zipppRZ2s2pjG0/XIQqjPSpPKhr6552KQ4e5VYvAPMHu/kgnql kHcw== Received: by 10.236.136.8 with SMTP id v8mr4353794yhi.101.1340994323054; Fri, 29 Jun 2012 11:25:23 -0700 (PDT) Received: from [192.168.1.211] (190-20-59-251.baf.movistar.cl. [190.20.59.251]) by mx.google.com with ESMTPS id c28sm7380739yhk.2.2012.06.29.11.25.19 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 29 Jun 2012 11:25:21 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_CB862F05-5EFC-4A14-9FEE-6963AD225956"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <8C18C43D-AC63-465A-ADC2-966CE7F38685@gmail.com> Date: Fri, 29 Jun 2012 14:25:12 -0400 Message-Id: <795DFC7B-9218-40E2-871D-E52B07C1B718@ve7jtb.com> References: <4FE223E4.6060307@mitre.org> <4FE226BC.6010403@alcatel-lucent.com> <59E470B10C4630419ED717AC79FCF9A910889AB5@BL2PRD0410MB363.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A917052BC8@SN2PRD0410MB370.namprd04.prod.outlook.com> <4FE37D38.1030407@gmail.com> <59E470B10C4630419ED717AC79FCF9A91A2C8949@CH1PRD0410MB369.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A91A2D1309@CH1PRD0410MB369.namprd04.prod.outlook.com> <496AFB1D-A609-4188-B92D-2185E8880388@ve7jtb.com> <59E470B10C4630419ED717AC79FCF9A91A2D13C9@CH1PRD0410MB369.namprd04.prod.outlook.com> <67F8B633-E4C8-42F6-B84C-FDBC337B7EEA@ve7jtb.com> <04C05FAA-63BC-4441-8540-36280E40DB98@adobe.com> <4FEDE4AF.9030107@mitre.org> <4 DD23AA1-C319-477A-B0CB-34E558EB7FCC@ve7jtb.com> <8C18C43D-AC63-465A-ADC2-966CE7F38685@gmail.com> To: Dick Hardt X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQnmo0pCWsK8R1LWahEHS7a6h2KckuCvCP7vSRBfjnbCoDAYID7Wdh9Ek/C0/svanqQS5F2x Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Report an authentication issue X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 18:25:24 -0000 --Apple-Mail=_CB862F05-5EFC-4A14-9FEE-6963AD225956 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 I agree, If there is no good reason for the token endpoint not to check = the client_id with public clients then we should add that it SHOULD or = MUST be checked for authorization_code and refresh_token grant_type. Though I don't know if we want to get carried away with the whole = agreeing thing. John B. On 2012-06-29, at 2:14 PM, Dick Hardt wrote: >=20 > On Jun 29, 2012, at 11:06 AM, John Bradley wrote: >=20 >> It is nice to know that I may occasionally be correct:) >=20 > You must be delighted when it happens! ;) >=20 >> While you may assume that it is reasonable for a client with a code = to make a request to the token endpoint including it's client_id and the = server to only give out the access token if the client_id in the token = request matches the one in the original authorization request. However = the spec specifically doesn't require that. >=20 > I think that is an error in the spec and should be changed, or text = adding saying that the client_id SHOULD be checked. >=20 > -- Dick --Apple-Mail=_CB862F05-5EFC-4A14-9FEE-6963AD225956 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw 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+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDYy OTE4MjUxM1owIwYJKoZIhvcNAQkEMRYEFN9MaUk3XZpsGDUN+v3aivB+jlSiMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB ADWsqVJE2KGcqgZEqWqH++ZBhtUzusPbcr0X6LX0uCAYU0L7Sj/J3M6RpuAI4ESZezLS4BQiROOn GSG0et8HLmvNlQebKFD3a6yD1dIKv3/MS+yRubIATdICRoQ4I4pgxG0321AQpx++BWgfUfj4EAtB x74EAxGj/G17kb61lhv2hTYgsLkm7xOTrQthSAh0LtnkZ6NcHhJv5fO4ab7HPOH54nwv8HTBZ3dm TKY3Xi5+995VXDl2OEkuKDt0qIiobw5BTEZqNcCq1LyXQ1UpPwi4Pb0NqdyKRxx3BwY+GbWl0frm LnA8519qw8NSnsNC1ddHP+MUe7uXw0yQuQ1PbLcAAAAAAAA= --Apple-Mail=_CB862F05-5EFC-4A14-9FEE-6963AD225956-- From ve7jtb@ve7jtb.com Fri Jun 29 11:31:11 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 256EA21F87AE for ; Fri, 29 Jun 2012 11:31:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.454 X-Spam-Level: X-Spam-Status: No, score=-3.454 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wc4tfcgH6K5Z for ; Fri, 29 Jun 2012 11:31:10 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1FE4121F8812 for ; Fri, 29 Jun 2012 11:31:10 -0700 (PDT) Received: by yenq13 with SMTP id q13so3368256yen.31 for ; Fri, 29 Jun 2012 11:31:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=LtdA7PUOSq/xbQVC97YecLFJgXvpc4kq+zaz9wK+wwQ=; b=SO1WuqgAqkV7pGOS/1nXgWXcRWUjovitOXV0KjDphyu2IUAZPUJ7f8A/T5Z6wgM77r 9DfvYMw9CUaBMNhqwifRk2O25GiMH0NfQua4z59OKpJ1a+16HxSj7dj6BF+qXu+r83QS /Fho9i71iuFeROqLqOxLCwK1XEdF3On6v8v8PRbp421ebHqszfov+j4hqQLfOfIFLLqF n0ucvJ9dwuhPqkQbRwNQtrwXP8x2gXHmm0jbD7/WIPd8dPy1aC5xREDXtf/ee/WSi1ST VaETCtHoVa3cRNXtpE+1wZJCpISO3jcEo1kABK3Bc+EJ4PK4oBgR094GKBLkUAsFX7Q2 jOzg== Received: by 10.236.79.74 with SMTP id h50mr4353983yhe.104.1340994669584; Fri, 29 Jun 2012 11:31:09 -0700 (PDT) Received: from [192.168.1.211] (190-20-59-251.baf.movistar.cl. [190.20.59.251]) by mx.google.com with ESMTPS id c70sm2294138yhk.12.2012.06.29.11.31.05 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 29 Jun 2012 11:31:07 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_B64B3BB2-03B5-4F35-8086-357BFEB648E8"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <71899C6B-40A6-46E8-BCF8-BF9C43B83C64@oracle.com> Date: Fri, 29 Jun 2012 14:30:59 -0400 Message-Id: <83124DF5-8D21-4D63-9D37-BBFBA0932065@ve7jtb.com> References: <4FE223E4.6060307@mitre.org> <4FE226BC.6010403@alcatel-lucent.com> <59E470B10C4630419ED717AC79FCF9A910889AB5@BL2PRD0410MB363.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A917052BC8@SN2PRD0410MB370.namprd04.prod.outlook.com> <4FE37D38.1030407@gmail.com> <59E470B10C4630419ED717AC79FCF9A91A2C8949@CH1PRD0410MB369.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A91A2D1309@CH1PRD0410MB369.namprd04.prod.outlook.com> <496AFB1D-A609-4188-B92D-2185E8880388@ve7jtb.com> <59E470B10C4630419ED717AC79FCF9A91A2D13C9@CH1PRD0410MB369.namprd04.prod.outlook.com> <67F8B633-E4C8-42F6-B84C-FDBC337B7EEA@ve7jtb.com> <04C05FAA-63BC-4441-8540-36280E40DB98@adobe.com> <4FEDE4AF.9030107@mitre.org> <8C18C43D-AC63-465A-ADC2-966CE7F38685@gmail.com> <71899C6B-40A6-46E8-BCF8-BF9C43B83C64@oracle.com> To: Phil Hunt X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQl2+XSqx47JdLMXP7lCTsWOzX4FVOgaqsM0Y5gdgm4MPHL311+qVLgiA/s4kCiJpcgRyAxM Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Report an authentication issue X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 18:31:11 -0000 --Apple-Mail=_B64B3BB2-03B5-4F35-8086-357BFEB648E8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I think they only exploited the implicit flow. =20 My point was that there is a way you could do the same thing with code = if it is a public client that is not authenticating to the token = endpoint. In general making identity assumptions in the client based on a code or = access_token has risks that are out of scope for OAuth. We do however want to provide good advice about specific things that can = leave systems insecure when using OAuth. John B. On 2012-06-29, at 2:22 PM, Phil Hunt wrote: > I'm not clear whether the MS Security Researcher hack was with the = authorization code or the access token. If the latter, the client_id is = out of the picture isn't it? >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 >=20 >=20 > On 2012-06-29, at 11:14 AM, Dick Hardt wrote: >=20 >>=20 >> On Jun 29, 2012, at 11:06 AM, John Bradley wrote: >>=20 >>> It is nice to know that I may occasionally be correct:) >>=20 >> You must be delighted when it happens! ;) >>=20 >>> While you may assume that it is reasonable for a client with a code = to make a request to the token endpoint including it's client_id and the = server to only give out the access token if the client_id in the token = request matches the one in the original authorization request. However = the spec specifically doesn't require that. >>=20 >> I think that is an error in the spec and should be changed, or text = adding saying that the client_id SHOULD be checked. >>=20 >> -- Dick >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 --Apple-Mail=_B64B3BB2-03B5-4F35-8086-357BFEB648E8 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw 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+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDYy OTE4MzA1OVowIwYJKoZIhvcNAQkEMRYEFLDfFjnfZ0qLAbapk4Sytwu2GM7oMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB AGUsYi5Ff7Z5vF7KSdc3AELhPAeTevpo0vpNnW5qQZ4GcN/KFWeidsYqr/Sm9HZeB3K1DboNkMGB iRatBNhXg51OCv/etSCve4sgj1MCuW9GRCofmiD88rghyMY0uup+QM5+Tk61njX4RY9Pz4IMFqX3 wmpYAUimkIWyVeW39ogRZpTg4WyBFip1xV8UWXcX3Ka/CDUVNIgrRLY5IXJWtgsrVKX6PLuk44sm V4API3CTkGTfmdAYbqCzWGcrk5IGeJics6auOI+J1Swi0SoN5SG1GiyvxCVQNA5fJKagyhqrJ5d7 6/Fs2zC/XWCN1hafnmD1omayaKSSSHYUBL7iQUYAAAAAAAA= --Apple-Mail=_B64B3BB2-03B5-4F35-8086-357BFEB648E8-- From phil.hunt@oracle.com Fri Jun 29 11:53:31 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1586921F8685 for ; Fri, 29 Jun 2012 11:53:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.801 X-Spam-Level: X-Spam-Status: No, score=-9.801 tagged_above=-999 required=5 tests=[AWL=-0.598, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 IA4g69u1W+Qa for ; Fri, 29 Jun 2012 11:53:30 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id 1F18221F87BC for ; Fri, 29 Jun 2012 11:53:30 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q5TIrRmJ024622 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 29 Jun 2012 18:53:27 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 q5TIrQjr017749 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Jun 2012 18:53:26 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 q5TIrQ7u001089; Fri, 29 Jun 2012 13:53:26 -0500 Received: from [192.168.1.125] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 29 Jun 2012 11:53:26 -0700 References: <4FE223E4.6060307@mitre.org> <4FE226BC.6010403@alcatel-lucent.com> <59E470B10C4630419ED717AC79FCF9A910889AB5@BL2PRD0410MB363.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A917052BC8@SN2PRD0410MB370.namprd04.prod.outlook.com> <4FE37D38.1030407@gmail.com> <59E470B10C4630419ED717AC79FCF9A91A2C8949@CH1PRD0410MB369.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A91A2D1309@CH1PRD0410MB369.namprd04.prod.outlook.com> <496AFB1D-A609-4188-B92D-2185E8880388@ve7jtb.com> <59E470B10C4630419ED717AC79FCF9A91A2D13C9@CH1PRD0410MB369.namprd04.prod.outlook.com> <67F8B633-E4C8-42F6-B84C-FDBC337B7EEA@ve7jtb.com> <04C05FAA-63BC-4441-8540-36280E40DB98@adobe.com> <4FEDE4AF.9030107@mitre.org> <8C18C43D-AC63-465A-ADC2-966CE7F38685@gmail.com> <71899C6B-40A6-46E8-BCF8-BF9C43B83C64@oracle.com> <83124DF5-8D21-4D63-9D37-BBFBA0932065@ve7jtb.com> In-Reply-To: <83124DF5-8D21-4D63-9D37-BBFBA0932065@ve7jtb.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <353091D2-F63F-4D48-A49B-99E53FE31954@oracle.com> X-Mailer: iPhone Mail (9B206) From: Phil Hunt Date: Fri, 29 Jun 2012 11:53:25 -0700 To: John Bradley X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Report an authentication issue X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 18:53:31 -0000 I'm not seeing how client id helps if a proxy server is somehow involved wit= h inserting the bearer token as the researchers suggested.=20 Phil On 2012-06-29, at 11:30, John Bradley wrote: > I think they only exploited the implicit flow. =20 >=20 > My point was that there is a way you could do the same thing with code if i= t is a public client that is not authenticating to the token endpoint. >=20 > In general making identity assumptions in the client based on a code or ac= cess_token has risks that are out of scope for OAuth. >=20 > We do however want to provide good advice about specific things that can l= eave systems insecure when using OAuth. >=20 > John B. >=20 > On 2012-06-29, at 2:22 PM, Phil Hunt wrote: >=20 >> I'm not clear whether the MS Security Researcher hack was with the author= ization code or the access token. If the latter, the client_id is out of the= picture isn't it? >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >>=20 >>=20 >> On 2012-06-29, at 11:14 AM, Dick Hardt wrote: >>=20 >>>=20 >>> On Jun 29, 2012, at 11:06 AM, John Bradley wrote: >>>=20 >>>> It is nice to know that I may occasionally be correct:) >>>=20 >>> You must be delighted when it happens! ;) >>>=20 >>>> While you may assume that it is reasonable for a client with a code to m= ake a request to the token endpoint including it's client_id and the server t= o only give out the access token if the client_id in the token request match= es the one in the original authorization request. However the spec specifi= cally doesn't require that. >>>=20 >>> I think that is an error in the spec and should be changed, or text addi= ng saying that the client_id SHOULD be checked. >>>=20 >>> -- Dick >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >=20 From ve7jtb@ve7jtb.com Fri Jun 29 12:16:35 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D42E021F8883 for ; Fri, 29 Jun 2012 12:16:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.46 X-Spam-Level: X-Spam-Status: No, score=-3.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 81VC0Sdy-1xs for ; Fri, 29 Jun 2012 12:16:34 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9E8A621F8885 for ; Fri, 29 Jun 2012 12:16:34 -0700 (PDT) Received: by ggnc4 with SMTP id c4so3419763ggn.31 for ; Fri, 29 Jun 2012 12:16:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=zOUMe6wRbRgPWvgkUcyR3OaTGUbbcFiF8uEPJtEJspY=; b=BDL3IbQaXCQf1+wzPFDXm4s4W3xritDROWJIw5MnreqOJZCNHekvlixA0OW42noHCR 4uW5s/o2cGNRgdr5f+eS1q/qVIvEX8VDF1Bz0XoLK5X7ARjea0hvgqcmgZV3vtB9MgSr /KrShu86FYSSaM6q2spFekQCW4ZKanBTS/2BpOHMtve5Bp/VUPgA0udCraaBcHZpQ7Rl IBGZE5VTFFuOb8c664E+WPCr7NjXPTbq+kAfBtBuGgA4e4PuAPowgicZcYZ2XZ6Eksp1 xgtxHvNkdFuIkrc1uGKj9IEA+2UVrTJUNu591UWiENRWv8oyzARPn9uSIS1vZrx8d2IH kAMw== Received: by 10.236.156.5 with SMTP id l5mr4579414yhk.94.1340997394176; Fri, 29 Jun 2012 12:16:34 -0700 (PDT) Received: from [192.168.1.211] (190-20-59-251.baf.movistar.cl. [190.20.59.251]) by mx.google.com with ESMTPS id c12sm3994464ank.14.2012.06.29.12.16.31 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 29 Jun 2012 12:16:33 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_AB6E7700-E217-4574-916A-01DFFA095E43"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <353091D2-F63F-4D48-A49B-99E53FE31954@oracle.com> Date: Fri, 29 Jun 2012 15:16:25 -0400 Message-Id: <7ED8AA4B-85D0-4D60-AFB6-C50503042A52@ve7jtb.com> References: <4FE223E4.6060307@mitre.org> <4FE226BC.6010403@alcatel-lucent.com> <59E470B10C4630419ED717AC79FCF9A910889AB5@BL2PRD0410MB363.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A917052BC8@SN2PRD0410MB370.namprd04.prod.outlook.com> <4FE37D38.1030407@gmail.com> <59E470B10C4630419ED717AC79FCF9A91A2C8949@CH1PRD0410MB369.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A91A2D1309@CH1PRD0410MB369.namprd04.prod.outlook.com> <496AFB1D-A609-4188-B92D-2185E8880388@ve7jtb.com> <59E470B10C4630419ED717AC79FCF9A91A2D13C9@CH1PRD0410MB369.namprd04.prod.outlook.com> <67F8B633-E4C8-42F6-B84C-FDBC337B7EEA@ve7jtb.com> <04C05FAA-63BC-4441-8540-36280E40DB98@adobe.com> <4FEDE4AF.9030107@mitre.org> <8C18C43D-AC63-465A-ADC2-966CE7F38685@gmail.com> <71899C6B-40A6-46E8-BCF8-BF9C43B83C64@oracle.com> <83124DF5-8D21-4D63-9D37-BBFBA0932065@ve7jtb.com> <353091D2-F63F-4D48-A49B-99E53FE31954@oracle.com> To: Phil Hunt X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQmiF388tkA6zlWKSEB87ZQxjoG+apojU2XodRWUmp922BVEITyerqvpkTn/KVW97FDdpVEV Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Report an authentication issue X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 19:16:36 -0000 --Apple-Mail=_AB6E7700-E217-4574-916A-01DFFA095E43 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The same thing can be done with code. If the token endpoint checks the client_id before giving out the access = token then the attack on code can be prevented, as the token endpoint = won't return the access token. The spec dosen't require authenticating public clients currently so it = is a slightly more difficult attack but possible. Dick and I are suggesting closing the hole at the token endpoint so that = nether confidential nor public clients using the code flow are = susceptible to this substitution attack. John B. On 2012-06-29, at 2:53 PM, PhiIt helps with the code flow when l Hunt = wrote: > I'm not seeing how client id helps if a proxy server is somehow = involved with inserting the bearer token as the researchers suggested.=20= >=20 > Phil >=20 > On 2012-06-29, at 11:30, John Bradley wrote: >=20 >> I think they only exploited the implicit flow. =20 >>=20 >> My point was that there is a way you could do the same thing with = code if it is a public client that is not authenticating to the token = endpoint. >>=20 >> In general making identity assumptions in the client based on a code = or access_token has risks that are out of scope for OAuth. >>=20 >> We do however want to provide good advice about specific things that = can leave systems insecure when using OAuth. >>=20 >> John B. >>=20 >> On 2012-06-29, at 2:22 PM, Phil Hunt wrote: >>=20 >>> I'm not clear whether the MS Security Researcher hack was with the = authorization code or the access token. If the latter, the client_id is = out of the picture isn't it? >>>=20 >>> Phil >>>=20 >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> On 2012-06-29, at 11:14 AM, Dick Hardt wrote: >>>=20 >>>>=20 >>>> On Jun 29, 2012, at 11:06 AM, John Bradley wrote: >>>>=20 >>>>> It is nice to know that I may occasionally be correct:) >>>>=20 >>>> You must be delighted when it happens! ;) >>>>=20 >>>>> While you may assume that it is reasonable for a client with a = code to make a request to the token endpoint including it's client_id = and the server to only give out the access token if the client_id in the = token request matches the one in the original authorization request. = However the spec specifically doesn't require that. >>>>=20 >>>> I think that is an error in the spec and should be changed, or text = adding saying that the client_id SHOULD be checked. >>>>=20 >>>> -- Dick >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>=20 --Apple-Mail=_AB6E7700-E217-4574-916A-01DFFA095E43 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw 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+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDYy OTE5MTYyNVowIwYJKoZIhvcNAQkEMRYEFGIMq0vw43QQ/S2zAkHdBCMz0S6uMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB ACQu0ttAxipDODAQdDW+KWpAqwwOe5l4SgJeoD1ynlB7qihcjNDa0m7kt0x3EWvjtDRda8LhCmTJ LoU4o06clPEfnlxQCJLepQH7vWLhXLUTFhAq4Cq/L2NOlkoOOUK8OdeHDlYb8ThHX1viowLN5Q9I zcs/yTMp3P3uyIdrmZomxtJ3jxQyKJdD/MK2TG85dxtNHCeckViphaX4vUiSemn88p4C7SAU6jYY h8fkakcXC0+9GivRKJUZHmpUmA5W7atTft4r+LLeokLbMjAjAmBYW9I1DxJNkeyjs2pVcr8B0sis pXyLb3zxrDt5icHdorqA8iNCSbWXqpjdx2FhIJoAAAAAAAA= --Apple-Mail=_AB6E7700-E217-4574-916A-01DFFA095E43-- From phil.hunt@oracle.com Fri Jun 29 12:29:31 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1968921F8892 for ; Fri, 29 Jun 2012 12:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.761 X-Spam-Level: X-Spam-Status: No, score=-9.761 tagged_above=-999 required=5 tests=[AWL=-0.558, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 5R8ZYb62ELbu for ; Fri, 29 Jun 2012 12:29:30 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id D511F21F888E for ; Fri, 29 Jun 2012 12:29:29 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q5TJTQO3023232 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 29 Jun 2012 19:29:27 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 q5TJTOHC005870 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Jun 2012 19:29:25 GMT Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q5TJTO7i029608; Fri, 29 Jun 2012 14:29:24 -0500 Received: from [192.168.1.125] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 29 Jun 2012 12:29:24 -0700 References: <4FE223E4.6060307@mitre.org> <4FE226BC.6010403@alcatel-lucent.com> <59E470B10C4630419ED717AC79FCF9A910889AB5@BL2PRD0410MB363.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A917052BC8@SN2PRD0410MB370.namprd04.prod.outlook.com> <4FE37D38.1030407@gmail.com> <59E470B10C4630419ED717AC79FCF9A91A2C8949@CH1PRD0410MB369.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A91A2D1309@CH1PRD0410MB369.namprd04.prod.outlook.com> <496AFB1D-A609-4188-B92D-2185E8880388@ve7jtb.com> <59E470B10C4630419ED717AC79FCF9A91A2D13C9@CH1PRD0410MB369.namprd04.prod.outlook.com> <67F8B633-E4C8-42F6-B84C-FDBC337B7EEA@ve7jtb.com> <04C05FAA-63BC-4441-8540-36280E40DB98@adobe.com> <4FEDE4AF.9030107@mitre.org> <8C18C43D-AC63-465A-ADC2-966CE7F38685@gmail.com> <71899C6B-40A6-46E8-BCF8-BF9C43B83C64@oracle.com> <83124DF5-8D21-4D63-9D37-BBFBA0932065@ve7jtb.com> <353091D2-F63F-4D48-A49B-99E53FE31954@oracle.com> <7ED8AA4B-85D0-4D60-AFB6-C50503042A52@ve7jtb.com> In-Reply-To: <7ED8AA4B-85D0-4D60-AFB6-C50503042A52@ve7jtb.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <9DFCB89E-39E2-4F70-A9F8-4D245800D798@oracle.com> X-Mailer: iPhone Mail (9B206) From: Phil Hunt Date: Fri, 29 Jun 2012 12:29:24 -0700 To: John Bradley X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Report an authentication issue X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 19:29:31 -0000 We need more info on the inject method the researchers used before we can ac= count for it.=20 Phil On 2012-06-29, at 12:16, John Bradley wrote: > The same thing can be done with code. >=20 > If the token endpoint checks the client_id before giving out the access to= ken then the attack on code can be prevented, as the token endpoint won't re= turn the access token. >=20 > The spec dosen't require authenticating public clients currently so it is a= slightly more difficult attack but possible. >=20 > Dick and I are suggesting closing the hole at the token endpoint so that n= ether confidential nor public clients using the code flow are susceptible to= this substitution attack. >=20 > John B. >=20 > On 2012-06-29, at 2:53 PM, PhiIt helps with the code flow when l Hunt wrot= e: >=20 >> I'm not seeing how client id helps if a proxy server is somehow involved w= ith inserting the bearer token as the researchers suggested.=20 >>=20 >> Phil >>=20 >> On 2012-06-29, at 11:30, John Bradley wrote: >>=20 >>> I think they only exploited the implicit flow. =20 >>>=20 >>> My point was that there is a way you could do the same thing with code i= f it is a public client that is not authenticating to the token endpoint. >>>=20 >>> In general making identity assumptions in the client based on a code or a= ccess_token has risks that are out of scope for OAuth. >>>=20 >>> We do however want to provide good advice about specific things that can= leave systems insecure when using OAuth. >>>=20 >>> John B. >>>=20 >>> On 2012-06-29, at 2:22 PM, Phil Hunt wrote: >>>=20 >>>> I'm not clear whether the MS Security Researcher hack was with the auth= orization code or the access token. If the latter, the client_id is out of t= he picture isn't it? >>>>=20 >>>> Phil >>>>=20 >>>> @independentid >>>> www.independentid.com >>>> phil.hunt@oracle.com >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On 2012-06-29, at 11:14 AM, Dick Hardt wrote: >>>>=20 >>>>>=20 >>>>> On Jun 29, 2012, at 11:06 AM, John Bradley wrote: >>>>>=20 >>>>>> It is nice to know that I may occasionally be correct:) >>>>>=20 >>>>> You must be delighted when it happens! ;) >>>>>=20 >>>>>> While you may assume that it is reasonable for a client with a code t= o make a request to the token endpoint including it's client_id and the serv= er to only give out the access token if the client_id in the token request m= atches the one in the original authorization request. However the spec spe= cifically doesn't require that. >>>>>=20 >>>>> I think that is an error in the spec and should be changed, or text ad= ding saying that the client_id SHOULD be checked. >>>>>=20 >>>>> -- Dick >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>=20 >=20 From dick.hardt@gmail.com Fri Jun 29 12:38:09 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A2ED21F8619 for ; Fri, 29 Jun 2012 12:38:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.581 X-Spam-Level: X-Spam-Status: No, score=-3.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lf3UvJ-Ef1ho for ; Fri, 29 Jun 2012 12:38:08 -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 850D121F8610 for ; Fri, 29 Jun 2012 12:38:08 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so5129079pbc.31 for ; Fri, 29 Jun 2012 12:38:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=G7P+yt0Lw6OQfIb1kR5AJEwwS4ol2s/YaKjWIe7Rddo=; b=dji0sPF9HR3qS2D518XQwUEGy2OkSgSkevEtibBPJWIEBKDYIyFtLD9UrypnQgKaNT 1/1nC4hDam5CaiivZ3VIuLlXAGxAc4+UpqAz+opIG1U6oqcVnpUXDBYKPWgplBm4t7DI BnDkU0uM0A6u4AImNbVzSfp5At4YSviFfFWEyXzZIXrXKsuqjILVpDbT7dEcKB1flkux m6Kjj7SzFc/ujq9JjvyjE5V5RwyFai+jh7PiCCtRb0OzqSHQBqp25pRxgQu2eI2FSIY0 HD47ZtoWB8ZMT8dvbTUSf57pQwl6RqVOdtAj6ztXkEaaDSEaGsHIc7WHHyMJQbX4H89t 5zFQ== Received: by 10.66.79.40 with SMTP id g8mr2879765pax.27.1340998688307; Fri, 29 Jun 2012 12:38:08 -0700 (PDT) Received: from [10.0.0.4] (c-24-5-69-173.hsd1.ca.comcast.net. [24.5.69.173]) by mx.google.com with ESMTPS id hw6sm6281049pbc.73.2012.06.29.12.38.06 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 29 Jun 2012 12:38:07 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Dick Hardt In-Reply-To: <353091D2-F63F-4D48-A49B-99E53FE31954@oracle.com> Date: Fri, 29 Jun 2012 12:38:04 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1BAB3182-5072-4703-92A5-FDA482D79FCA@gmail.com> References: <4FE223E4.6060307@mitre.org> <4FE226BC.6010403@alcatel-lucent.com> <59E470B10C4630419ED717AC79FCF9A910889AB5@BL2PRD0410MB363.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A917052BC8@SN2PRD0410MB370.namprd04.prod.outlook.com> <4FE37D38.1030407@gmail.com> <59E470B10C4630419ED717AC79FCF9A91A2C8949@CH1PRD0410MB369.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A91A2D1309@CH1PRD0410MB369.namprd04.prod.outlook.com> <496AFB1D-A609-4188-B92D-2185E8880388@ve7jtb.com> <59E470B10C4630419ED717AC79FCF9A91A2D13C9@CH1PRD0410MB369.namprd04.prod.outlook.com> <67F8B633-E4C8-42F6-B84C-FDBC337B7EEA@ve7jtb.com> <04C05FAA-63BC-4441-8540-36280E40DB98@adobe.com> <4FEDE4AF.9030107@mitre.org> <8C18C43D-AC63-465A-ADC2-966CE7F38685@gmail.com> <71899C6B-40A6-46E8-BCF8-BF9C43B83C64@oracle.com> <83124DF5-8D21-4D63-9D37-BBFBA0932065@ve7jtb.com> <353091D2-F63F-4D48-A49B-99E53FE31954@oracle.com> To: Phil Hunt X-Mailer: Apple Mail (2.1278) Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Report an authentication issue X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 19:38:09 -0000 If an attacked can modify the communications over TLS between the client = and the authorization server, then I think there are many other options = open to the attacker. -- Dick On Jun 29, 2012, at 11:53 AM, Phil Hunt wrote: > I'm not seeing how client id helps if a proxy server is somehow = involved with inserting the bearer token as the researchers suggested.=20= >=20 > Phil >=20 > On 2012-06-29, at 11:30, John Bradley wrote: >=20 >> I think they only exploited the implicit flow. =20 >>=20 >> My point was that there is a way you could do the same thing with = code if it is a public client that is not authenticating to the token = endpoint. >>=20 >> In general making identity assumptions in the client based on a code = or access_token has risks that are out of scope for OAuth. >>=20 >> We do however want to provide good advice about specific things that = can leave systems insecure when using OAuth. >>=20 >> John B. >>=20 >> On 2012-06-29, at 2:22 PM, Phil Hunt wrote: >>=20 >>> I'm not clear whether the MS Security Researcher hack was with the = authorization code or the access token. If the latter, the client_id is = out of the picture isn't it? >>>=20 >>> Phil >>>=20 >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> On 2012-06-29, at 11:14 AM, Dick Hardt wrote: >>>=20 >>>>=20 >>>> On Jun 29, 2012, at 11:06 AM, John Bradley wrote: >>>>=20 >>>>> It is nice to know that I may occasionally be correct:) >>>>=20 >>>> You must be delighted when it happens! ;) >>>>=20 >>>>> While you may assume that it is reasonable for a client with a = code to make a request to the token endpoint including it's client_id = and the server to only give out the access token if the client_id in the = token request matches the one in the original authorization request. = However the spec specifically doesn't require that. >>>>=20 >>>> I think that is an error in the spec and should be changed, or text = adding saying that the client_id SHOULD be checked. >>>>=20 >>>> -- Dick >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>=20 From ve7jtb@ve7jtb.com Fri Jun 29 13:00:54 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51B7621F8890 for ; Fri, 29 Jun 2012 13:00:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.165 X-Spam-Level: X-Spam-Status: No, score=-3.165 tagged_above=-999 required=5 tests=[AWL=-0.166, BAYES_00=-2.599, J_CHICKENPOX_66=0.6, 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 fTRzdUCIwq-C for ; Fri, 29 Jun 2012 13:00:53 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 33E5B21F885C for ; Fri, 29 Jun 2012 13:00:53 -0700 (PDT) Received: by yenq13 with SMTP id q13so3458651yen.31 for ; Fri, 29 Jun 2012 13:00:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=FiFgjejxZzD9ICIVpU/RaUUncN1lWIyoX2MosnhfJ0w=; b=bjQO6uV/T+1IW2bQTNwrLeI9eZW0hkkR+FMZCYM7QUpsV1oGlMEKvBlzNq0LFZWWT/ n7txqIzaEfAfqi3MCfU1L8tmR2KreJJGF+Mdmq8GmRmoYSNAjhZqrXpKo5dwxuqDbaSj 93U68OlL9jpUCo97gvg2PdBx/Z3YX1W+8Zgm7GlUc5YVMF2zTyNxKedop5Yf2LegoWuH FaTTbnzF2xbDXK95DEGpriPnmCuDz9HHQDXkkwXzMIinTLrBl0DJQ/vlnLxpdNt6sMsA 90uw8Sys/RqoxjtblI1E7fugVkADuUot0XzWvs3lAVJ1GpII7HT/+fDV96EtC7kksWx8 Expg== Received: by 10.101.141.21 with SMTP id t21mr1370641ann.34.1341000052569; Fri, 29 Jun 2012 13:00:52 -0700 (PDT) Received: from [192.168.1.211] (190-20-59-251.baf.movistar.cl. [190.20.59.251]) by mx.google.com with ESMTPS id y63sm7941824yha.9.2012.06.29.13.00.50 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 29 Jun 2012 13:00:51 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_7F64469D-2E39-4C2A-885A-5FDC6971FDA3"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <9DFCB89E-39E2-4F70-A9F8-4D245800D798@oracle.com> Date: Fri, 29 Jun 2012 16:00:42 -0400 Message-Id: References: <4FE223E4.6060307@mitre.org> <4FE226BC.6010403@alcatel-lucent.com> <59E470B10C4630419ED717AC79FCF9A910889AB5@BL2PRD0410MB363.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A917052BC8@SN2PRD0410MB370.namprd04.prod.outlook.com> <4FE37D38.1030407@gmail.com> <59E470B10C4630419ED717AC79FCF9A91A2C8949@CH1PRD0410MB369.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A91A2D1309@CH1PRD0410MB369.namprd04.prod.outlook.com> <496AFB1D-A609-4188-B92D-2185E8880388@ve7jtb.com> <59E470B10C4630419ED717AC79FCF9A91A2D13C9@CH1PRD0410MB369.namprd04.prod.outlook.com> <67F8B633-E4C8-42F6-B84C-FDBC337B7EEA@ve7jtb.com> <04C05FAA-63BC-4441-8540-36280E40DB98@adobe.com> <4FEDE4AF.9030107@mitre.org> <8C18C43D-AC63-465A-ADC2-966CE7F38685@gmail.com> <71899C6B-40A6-46E8-BCF8-BF9C43B83C64@oracle.com> <83124DF5-8D21-4D63-9D37-BBFBA0932065@ve7jtb.com> <353091D2-F63F-4D48-A49B-99E53FE31954@oracle.com> <7ED8AA4B-85D0-4D60-AFB6-C50503042A52@ve7jtb.com> <9DFCB89E-39E2-4F70-A9F8-4D245800D798@oracle.com> To: Phil Hunt X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQmLsYshdl7cA1BlOTYot7YvoiKkH81GeyhbQ6P/+BxDwoZMt7X6mkn2EgHkrBMq3dZTR9NR Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Report an authentication issue X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 20:00:54 -0000 --Apple-Mail=_7F64469D-2E39-4C2A-885A-5FDC6971FDA3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The attack requires a web browser that allows modifying the value of the = of the redirect URI. It is dead simple cut token or code from the = string and paste in the token or code that was granted by the user you = want to impersonate. OAuth responses are not signed or audience restricted to the = client(except confidential clients using the code flow). =20 In cases where the code or token is passed over a back channel to a = server, faking the entire client is the easiest thing for the attacker. I don't consider these to be authorization attacks, rather attacks on a = client that is inappropariatly making unwarranted assumptions about the = presenter of the token. John B. On 2012-06-29, at 3:29 PM, Phil Hunt wrote: > We need more info on the inject method the researchers used before we = can account for it.=20 >=20 > Phil >=20 > On 2012-06-29, at 12:16, John Bradley wrote: >=20 >> The same thing can be done with code. >>=20 >> If the token endpoint checks the client_id before giving out the = access token then the attack on code can be prevented, as the token = endpoint won't return the access token. >>=20 >> The spec dosen't require authenticating public clients currently so = it is a slightly more difficult attack but possible. >>=20 >> Dick and I are suggesting closing the hole at the token endpoint so = that nether confidential nor public clients using the code flow are = susceptible to this substitution attack. >>=20 >> John B. >>=20 >> On 2012-06-29, at 2:53 PM, PhiIt helps with the code flow when l Hunt = wrote: >>=20 >>> I'm not seeing how client id helps if a proxy server is somehow = involved with inserting the bearer token as the researchers suggested.=20= >>>=20 >>> Phil >>>=20 >>> On 2012-06-29, at 11:30, John Bradley wrote: >>>=20 >>>> I think they only exploited the implicit flow. =20 >>>>=20 >>>> My point was that there is a way you could do the same thing with = code if it is a public client that is not authenticating to the token = endpoint. >>>>=20 >>>> In general making identity assumptions in the client based on a = code or access_token has risks that are out of scope for OAuth. >>>>=20 >>>> We do however want to provide good advice about specific things = that can leave systems insecure when using OAuth. >>>>=20 >>>> John B. >>>>=20 >>>> On 2012-06-29, at 2:22 PM, Phil Hunt wrote: >>>>=20 >>>>> I'm not clear whether the MS Security Researcher hack was with the = authorization code or the access token. If the latter, the client_id is = out of the picture isn't it? >>>>>=20 >>>>> Phil >>>>>=20 >>>>> @independentid >>>>> www.independentid.com >>>>> phil.hunt@oracle.com >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On 2012-06-29, at 11:14 AM, Dick Hardt wrote: >>>>>=20 >>>>>>=20 >>>>>> On Jun 29, 2012, at 11:06 AM, John Bradley wrote: >>>>>>=20 >>>>>>> It is nice to know that I may occasionally be correct:) >>>>>>=20 >>>>>> You must be delighted when it happens! ;) >>>>>>=20 >>>>>>> While you may assume that it is reasonable for a client with a = code to make a request to the token endpoint including it's client_id = and the server to only give out the access token if the client_id in the = token request matches the one in the original authorization request. = However the spec specifically doesn't require that. >>>>>>=20 >>>>>> I think that is an error in the spec and should be changed, or = text adding saying that the client_id SHOULD be checked. >>>>>>=20 >>>>>> -- Dick >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>>=20 >>=20 --Apple-Mail=_7F64469D-2E39-4C2A-885A-5FDC6971FDA3 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw 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+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDYy OTIwMDA0M1owIwYJKoZIhvcNAQkEMRYEFEMePSruGFo5eUwzm6MyCl1HP721MIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB AEdBN0MJNLngKNz3EU6eiPOHocPEoGtQlxf1zjrPpgQlL+sUHv0A4KBT0U/H1M2gYOEFnuxc7ryf aD+IvO6qDiQwEP7E4g2giqiY0NNZGRvnP9M4KjFU1WexEnJm66+fjhwRtqM7RSpQiSZpQzNZgN2V Xbul3Zq9JYwHXoA3kLijbEMgXmAMv5NI96yr4KGBTUC6KZFFeKC/S+GfOvFnOyUaYxexx+uiRdhd bdyg1UGmbC7ewSWfJxkiDWCmKH3G5sq+eRT618tDvz3AeuLa7JLr/NSfk60cJV0UIDK6lT9J2+f4 PT5XR9PU6zvvLhOwKc1iCzaxdaoy1P4J11uoc/QAAAAAAAA= --Apple-Mail=_7F64469D-2E39-4C2A-885A-5FDC6971FDA3-- From phil.hunt@oracle.com Fri Jun 29 13:16:12 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FC0521F88A0 for ; Fri, 29 Jun 2012 13:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.124 X-Spam-Level: X-Spam-Status: No, score=-10.124 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, J_CHICKENPOX_66=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 zbsafBNRyqDV for ; Fri, 29 Jun 2012 13:16:11 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id CB33D21F8857 for ; Fri, 29 Jun 2012 13:16:10 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q5TKG7L3032358 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 29 Jun 2012 20:16:08 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q5TKG6UJ027238 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Jun 2012 20:16:06 GMT Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q5TKG5WF021061; Fri, 29 Jun 2012 15:16:05 -0500 Received: from [192.168.1.8] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 29 Jun 2012 13:16:05 -0700 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Phil Hunt In-Reply-To: Date: Fri, 29 Jun 2012 13:16:03 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4FE223E4.6060307@mitre.org> <4FE226BC.6010403@alcatel-lucent.com> <59E470B10C4630419ED717AC79FCF9A910889AB5@BL2PRD0410MB363.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A917052BC8@SN2PRD0410MB370.namprd04.prod.outlook.com> <4FE37D38.1030407@gmail.com> <59E470B10C4630419ED717AC79FCF9A91A2C8949@CH1PRD0410MB369.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A91A2D1309@CH1PRD0410MB369.namprd04.prod.outlook.com> <496AFB1D-A609-4188-B92D-2185E8880388@ve7jtb.com> <59E470B10C4630419ED717AC79FCF9A91A2D13C9@CH1PRD0410MB369.namprd04.prod.outlook.com> <67F8B633-E4C8-42F6-B84C-FDBC337B7EEA@ve7jtb.com> <04C05FAA-63BC-4441-8540-36280E40DB98@adobe.com> <4FEDE4AF.9030107@mitre.org> <8C18C43D-AC63-465A-ADC2-966CE7F38685@gmail.com> <71899C6B-40A6-46E8-BCF8-BF9C43B83C64@oracle.com> <83124DF5-8D21-4D63-9D37-BBFBA0932065@ve7jtb.com> <353091D2-F63F-4D48-A49B-99E53FE31954@oracle.com> <7ED8AA4B-85D0-4D60-AFB6-C50503042A52@ve7jtb.com> <9DFCB89E-39E2-4F70-A9F8-4D245800D798@oracle.com> To: John Bradley X-Mailer: Apple Mail (2.1278) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Report an authentication issue X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 20:16:12 -0000 John, I think that helps to clarify the authorize issue. But they were talking about a phishing site obtaining a legit access = token from Facebook. > Let's take Soluto's metro app as an example to describe the problem. = The app supports Facebook Login. As an attacker, we can write a regular = Facebook app. Once the victim user allows our app to access her Facebook = data, we receive an access_token from the traffic. Then, on our own = machine (i.e., the "attacker" machine), we run the metro app of Soluto, = and use a HTTP proxy to insert the victim's access_token into the = traffic of Facebook login. Through this way, we are able to log into the = victim's Soluto account from our machine. Other than Soluto, we also = have confirmed the same issue on another Windows 8 metro-app Givit. Important: the attack works because the researchers had control of the = client application. And thus they were able to insert the token between = the metro client app and the server because they are able to get in the = communications path. All bets are off. If the attacker can insert a = token then can insert appropriate client_id's and responses in the = stream as well. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2012-06-29, at 1:00 PM, John Bradley wrote: > The attack requires a web browser that allows modifying the value of = the of the redirect URI. It is dead simple cut token or code from the = string and paste in the token or code that was granted by the user you = want to impersonate. >=20 > OAuth responses are not signed or audience restricted to the = client(except confidential clients using the code flow). =20 >=20 > In cases where the code or token is passed over a back channel to a = server, faking the entire client is the easiest thing for the attacker. >=20 > I don't consider these to be authorization attacks, rather attacks on = a client that is inappropariatly making unwarranted assumptions about = the presenter of the token. >=20 > John B. > On 2012-06-29, at 3:29 PM, Phil Hunt wrote: >=20 >> We need more info on the inject method the researchers used before we = can account for it.=20 >>=20 >> Phil >>=20 >> On 2012-06-29, at 12:16, John Bradley wrote: >>=20 >>> The same thing can be done with code. >>>=20 >>> If the token endpoint checks the client_id before giving out the = access token then the attack on code can be prevented, as the token = endpoint won't return the access token. >>>=20 >>> The spec dosen't require authenticating public clients currently so = it is a slightly more difficult attack but possible. >>>=20 >>> Dick and I are suggesting closing the hole at the token endpoint so = that nether confidential nor public clients using the code flow are = susceptible to this substitution attack. >>>=20 >>> John B. >>>=20 >>> On 2012-06-29, at 2:53 PM, PhiIt helps with the code flow when l = Hunt wrote: >>>=20 >>>> I'm not seeing how client id helps if a proxy server is somehow = involved with inserting the bearer token as the researchers suggested.=20= >>>>=20 >>>> Phil >>>>=20 >>>> On 2012-06-29, at 11:30, John Bradley wrote: >>>>=20 >>>>> I think they only exploited the implicit flow. =20 >>>>>=20 >>>>> My point was that there is a way you could do the same thing with = code if it is a public client that is not authenticating to the token = endpoint. >>>>>=20 >>>>> In general making identity assumptions in the client based on a = code or access_token has risks that are out of scope for OAuth. >>>>>=20 >>>>> We do however want to provide good advice about specific things = that can leave systems insecure when using OAuth. >>>>>=20 >>>>> John B. >>>>>=20 >>>>> On 2012-06-29, at 2:22 PM, Phil Hunt wrote: >>>>>=20 >>>>>> I'm not clear whether the MS Security Researcher hack was with = the authorization code or the access token. If the latter, the client_id = is out of the picture isn't it? >>>>>>=20 >>>>>> Phil >>>>>>=20 >>>>>> @independentid >>>>>> www.independentid.com >>>>>> phil.hunt@oracle.com >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On 2012-06-29, at 11:14 AM, Dick Hardt wrote: >>>>>>=20 >>>>>>>=20 >>>>>>> On Jun 29, 2012, at 11:06 AM, John Bradley wrote: >>>>>>>=20 >>>>>>>> It is nice to know that I may occasionally be correct:) >>>>>>>=20 >>>>>>> You must be delighted when it happens! ;) >>>>>>>=20 >>>>>>>> While you may assume that it is reasonable for a client with a = code to make a request to the token endpoint including it's client_id = and the server to only give out the access token if the client_id in the = token request matches the one in the original authorization request. = However the spec specifically doesn't require that. >>>>>>>=20 >>>>>>> I think that is an error in the spec and should be changed, or = text adding saying that the client_id SHOULD be checked. >>>>>>>=20 >>>>>>> -- Dick >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>=20 >>>>>=20 >>>=20 >=20 From ve7jtb@ve7jtb.com Fri Jun 29 13:54:44 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FDFF11E807F for ; Fri, 29 Jun 2012 13:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.163 X-Spam-Level: X-Spam-Status: No, score=-3.163 tagged_above=-999 required=5 tests=[AWL=-0.164, BAYES_00=-2.599, J_CHICKENPOX_66=0.6, 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 cNwbvgErFQzw for ; Fri, 29 Jun 2012 13:54:42 -0700 (PDT) Received: from mail-yw0-f42.google.com (mail-yw0-f42.google.com [209.85.213.42]) by ietfa.amsl.com (Postfix) with ESMTP id 7956C11E8073 for ; Fri, 29 Jun 2012 13:54:39 -0700 (PDT) Received: by yhfq11 with SMTP id q11so3827186yhf.15 for ; Fri, 29 Jun 2012 13:54:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=t7/1ZnLGotk+3AdjfISjWu5VMLEzjJ73ypPn69UbeWk=; b=U/ew/UVBTkqI7v+LyH96QHB5hPPS0oFwJmq5VyeTJ6rYbw3/r7Ia2QLhYthcXj/EQw +zhQOyL0DL41cPhGpr60VEDY6I29fb/fv8gts9qmg+icyd8KGQ+VlbnJLxqPeFOQEBhJ 7ZuQfR6miZs+o36fq+ipYSB35mDEC6HiqbvorcQRPKs19DUxJAZ5q0lug2sbMkh8iKEq Jbea1O4Nsf/hNJlrazDede9lxOskxUHRIfLvzaf5eXgewOKTrUuyew61ngT9t4yxYY3m ZYPwvC+WS3M5jjZk48XbIKls4VsZ8QCPBw2tZEcv8BtPEd2I7oae3DhL6AJ6wMy18FOF YK7w== Received: by 10.236.146.97 with SMTP id q61mr5096595yhj.113.1341003278871; Fri, 29 Jun 2012 13:54:38 -0700 (PDT) Received: from [192.168.1.211] (190-20-59-251.baf.movistar.cl. [190.20.59.251]) by mx.google.com with ESMTPS id y63sm8265682yha.9.2012.06.29.13.54.35 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 29 Jun 2012 13:54:37 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_EAD4554A-404E-40A6-B7D9-74BA49ACC6FC"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: Date: Fri, 29 Jun 2012 16:54:29 -0400 Message-Id: References: <4FE223E4.6060307@mitre.org> <4FE226BC.6010403@alcatel-lucent.com> <59E470B10C4630419ED717AC79FCF9A910889AB5@BL2PRD0410MB363.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A917052BC8@SN2PRD0410MB370.namprd04.prod.outlook.com> <4FE37D38.1030407@gmail.com> <59E470B10C4630419ED717AC79FCF9A91A2C8949@CH1PRD0410MB369.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A91A2D1309@CH1PRD0410MB369.namprd04.prod.outlook.com> <496AFB1D-A609-4188-B92D-2185E8880388@ve7jtb.com> <59E470B10C4630419ED717AC79FCF9A91A2D13C9@CH1PRD0410MB369.namprd04.prod.outlook.com> <67F8B633-E4C8-42F6-B84C-FDBC337B7EEA@ve7jtb.com> <04C05FAA-63BC-4441-8540-36280E40DB98@adobe.com> <4FEDE4AF.9030107@mitre.org> <8C18C43D-AC63-465A-ADC2-966CE7F38685@gmail.com> <71899C6B-40A6-46E8-BCF8-BF9C43B83C64@oracle.com> <83124DF5-8D21-4D63-9D37-BBFBA0932065@ve7jtb.com> <353091D2-F63F-4D48-A49B-99E53FE31954@oracle.com> <7ED8AA4B-85D0-4D60-AFB6-C50503042A52@ve7jtb.com> <9DFCB89E-39E2-4F70-A9F8-4D245800D798@oracle.com> To: Phil Hunt X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQmPk83pTXKpOUyktSEhK1/qFN/PVTzk1Mw+FuN+6INv/aYLw7aALeEL/KOuEFq/0yRDP+2y Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Report an authentication issue X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 20:54:44 -0000 --Apple-Mail=_EAD4554A-404E-40A6-B7D9-74BA49ACC6FC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii No, Trying to explain this over email is a challenge:) This apples to both native apps and Web Servers who are OAuth Clients. Imagine there are two web servers that authenticate people with Facebook = Connect (just an example). Site A is I love Puppies (An evil site) Site B is I Hate Larry Ellison (A good site) You as a chocolate lover go to Site A and login to get some cool free = screensaver of Puppies. Site A gets a token for your social graph no big deal mostly public = stuff. However they discovery you work for Mr Evil who they think is = purchasing paradise to put up a parking lot. They then go to site B who is using the implicit flow for Facebook = authentication. They login using a web browser but using any one of a = number of browser plugins modify the response to have the access_token = that they got from you when you logged into their site. They now post = as you telling everyone that Larry can't sail and has bad fashion sense. = (Perhaps true) You might now have some explaining to do! It would be worse if Site B had some PII about you or could transfer the = money from your bank based on that authentication. The same thing could happen with the code flow if the client is public = and doesn't have a secret. Site A doesn't use the code themselves when = you login, they just let you through to get the puppy photos. They immediately take the token to site B and paste it into a legitimate = response (note the client_id is not in the response or code ) the public = client then presents that to the token endpoint with it's client_id to = get the access_token. The token endpoint just hands it over because = without a client_secret it is not required to authenticate the client. What Dick and I are saying is that we don't see the need not to verify = the client_id in the request to the token endpoint. If it were required = clients would not be able to mistakenly accept codes issued to diffrent = clients. I strongly suspect most implementations do that already, so why not = clarify the spec on that point. =20 That won't stop the attack on implicit clients. This is why openID 2.0, openID Connect, SAML and every other identity = protocol I can think of audience restrict the assertion to the intended = recipient and sign or integrity protect the response. That is not needed for the typical authorization use case of OAuth, but = is a really good idea if you are asserting Authentication information to = the client. No puppies were hurt in the creation of this message. John B. On 2012-06-29, at 4:16 PM, Phil Hunt wrote: > John, >=20 > I think that helps to clarify the authorize issue. >=20 > But they were talking about a phishing site obtaining a legit access = token from Facebook. >> Let's take Soluto's metro app as an example to describe the problem. = The app supports Facebook Login. As an attacker, we can write a regular = Facebook app. Once the victim user allows our app to access her Facebook = data, we receive an access_token from the traffic. Then, on our own = machine (i.e., the "attacker" machine), we run the metro app of Soluto, = and use a HTTP proxy to insert the victim's access_token into the = traffic of Facebook login. Through this way, we are able to log into the = victim's Soluto account from our machine. Other than Soluto, we also = have confirmed the same issue on another Windows 8 metro-app Givit. >=20 >=20 > Important: the attack works because the researchers had control of the = client application. And thus they were able to insert the token between = the metro client app and the server because they are able to get in the = communications path. All bets are off. If the attacker can insert a = token then can insert appropriate client_id's and responses in the = stream as well. >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 >=20 >=20 > On 2012-06-29, at 1:00 PM, John Bradley wrote: >=20 >> The attack requires a web browser that allows modifying the value of = the of the redirect URI. It is dead simple cut token or code from the = string and paste in the token or code that was granted by the user you = want to impersonate. >>=20 >> OAuth responses are not signed or audience restricted to the = client(except confidential clients using the code flow). =20 >>=20 >> In cases where the code or token is passed over a back channel to a = server, faking the entire client is the easiest thing for the attacker. >>=20 >> I don't consider these to be authorization attacks, rather attacks = on a client that is inappropariatly making unwarranted assumptions about = the presenter of the token. >>=20 >> John B. >> On 2012-06-29, at 3:29 PM, Phil Hunt wrote: >>=20 >>> We need more info on the inject method the researchers used before = we can account for it.=20 >>>=20 >>> Phil >>>=20 >>> On 2012-06-29, at 12:16, John Bradley wrote: >>>=20 >>>> The same thing can be done with code. >>>>=20 >>>> If the token endpoint checks the client_id before giving out the = access token then the attack on code can be prevented, as the token = endpoint won't return the access token. >>>>=20 >>>> The spec dosen't require authenticating public clients currently so = it is a slightly more difficult attack but possible. >>>>=20 >>>> Dick and I are suggesting closing the hole at the token endpoint so = that nether confidential nor public clients using the code flow are = susceptible to this substitution attack. >>>>=20 >>>> John B. >>>>=20 >>>> On 2012-06-29, at 2:53 PM, PhiIt helps with the code flow when l = Hunt wrote: >>>>=20 >>>>> I'm not seeing how client id helps if a proxy server is somehow = involved with inserting the bearer token as the researchers suggested.=20= >>>>>=20 >>>>> Phil >>>>>=20 >>>>> On 2012-06-29, at 11:30, John Bradley wrote: >>>>>=20 >>>>>> I think they only exploited the implicit flow. =20 >>>>>>=20 >>>>>> My point was that there is a way you could do the same thing with = code if it is a public client that is not authenticating to the token = endpoint. >>>>>>=20 >>>>>> In general making identity assumptions in the client based on a = code or access_token has risks that are out of scope for OAuth. >>>>>>=20 >>>>>> We do however want to provide good advice about specific things = that can leave systems insecure when using OAuth. >>>>>>=20 >>>>>> John B. >>>>>>=20 >>>>>> On 2012-06-29, at 2:22 PM, Phil Hunt wrote: >>>>>>=20 >>>>>>> I'm not clear whether the MS Security Researcher hack was with = the authorization code or the access token. If the latter, the client_id = is out of the picture isn't it? >>>>>>>=20 >>>>>>> Phil >>>>>>>=20 >>>>>>> @independentid >>>>>>> www.independentid.com >>>>>>> phil.hunt@oracle.com >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> On 2012-06-29, at 11:14 AM, Dick Hardt wrote: >>>>>>>=20 >>>>>>>>=20 >>>>>>>> On Jun 29, 2012, at 11:06 AM, John Bradley wrote: >>>>>>>>=20 >>>>>>>>> It is nice to know that I may occasionally be correct:) >>>>>>>>=20 >>>>>>>> You must be delighted when it happens! ;) >>>>>>>>=20 >>>>>>>>> While you may assume that it is reasonable for a client with a = code to make a request to the token endpoint including it's client_id = and the server to only give out the access token if the client_id in the = token request matches the one in the original authorization request. = However the spec specifically doesn't require that. >>>>>>>>=20 >>>>>>>> I think that is an error in the spec and should be changed, or = text adding saying that the client_id SHOULD be checked. >>>>>>>>=20 >>>>>>>> -- Dick >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>=20 >>>>>>=20 >>>>=20 >>=20 >=20 --Apple-Mail=_EAD4554A-404E-40A6-B7D9-74BA49ACC6FC Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw 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+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDYy OTIwNTQzMFowIwYJKoZIhvcNAQkEMRYEFF6CJylhz7uh7P7asqhwnyU/mtGSMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB AAM4OZ/edSLpaYkyyniOt8TuMuAjrgMhvMz+teGowp6H/saMficrLsNGD6Wq9dDQrIqq0OPec1Za 9kduSyuNHVBU7LnhoVkKcRdPcYaTRqARnJERVttxEPXNCobRo1ddaFdn5+iuCq4S6NprbEnBGSF4 T0SRZ1Dk3dGHNxA+4QdI9PfEUiXghEq789KEd42rZa3lWXDvF0GwdyrFFf1cccIIHNsLhXKfzqIZ KBHHf0ut35IUu1stccwS08Z4L4YzkzCCgAXWWDoKSvD4I09MyvPyx3Fy9OC+qRcITVufOQ7qTw+H KQRhS57w/RIRvLZDjU6VXWe0SmMUPGeRuVEhGxMAAAAAAAA= --Apple-Mail=_EAD4554A-404E-40A6-B7D9-74BA49ACC6FC-- From phil.hunt@oracle.com Fri Jun 29 16:31:33 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE5ED21F8680 for ; Fri, 29 Jun 2012 16:31:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.117 X-Spam-Level: X-Spam-Status: No, score=-10.117 tagged_above=-999 required=5 tests=[AWL=-0.118, BAYES_00=-2.599, J_CHICKENPOX_66=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 TWPNknXukaVx for ; Fri, 29 Jun 2012 16:31:32 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id 53FEA21F8683 for ; Fri, 29 Jun 2012 16:31:32 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q5TNVTjj011126 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 29 Jun 2012 23:31:30 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 q5TNVTUZ016661 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Jun 2012 23:31:29 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 q5TNVTTX004015; Fri, 29 Jun 2012 18:31:29 -0500 Received: from [192.168.1.8] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 29 Jun 2012 16:31:28 -0700 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Phil Hunt In-Reply-To: Date: Fri, 29 Jun 2012 16:31:22 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7A8FC3E0-79E4-403D-8A4E-16CBCD55C565@oracle.com> References: <4FE223E4.6060307@mitre.org> <4FE226BC.6010403@alcatel-lucent.com> <59E470B10C4630419ED717AC79FCF9A910889AB5@BL2PRD0410MB363.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A917052BC8@SN2PRD0410MB370.namprd04.prod.outlook.com> <4FE37D38.1030407@gmail.com> <59E470B10C4630419ED717AC79FCF9A91A2C8949@CH1PRD0410MB369.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A91A2D1309@CH1PRD0410MB369.namprd04.prod.outlook.com> <496AFB1D-A609-4188-B92D-2185E8880388@ve7jtb.com> <59E470B10C4630419ED717AC79FCF9A91A2D13C9@CH1PRD0410MB369.namprd04.prod.outlook.com> <67F8B633-E4C8-42F6-B84C-FDBC337B7EEA@ve7jtb.com> <04C05FAA-63BC-4441-8540-36280E40DB98@adobe.com> <4FEDE4AF.9030107@mitre.org> <8C18C43D-AC63-465A-ADC2-966CE7F38685@gmail.com> <71899C6B-40A6-46E8-BCF8-BF9C43B83C64@oracle.com> <83124DF5-8D21-4D63-9D37-BBFBA0932065@ve7jtb.com> <353091D2-F63F-4D48-A49B-99E53FE31954@oracle.com> <7ED8AA4B-85D0-4D60-AFB6-C50503042A52@ve7jtb.com> <9DFCB89E-39E2-4F70-A9F8-4D245800D798@oracle.com> To: John Bradley X-Mailer: Apple Mail (2.1278) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Report an authentication issue X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 23:31:34 -0000 See below... Phil @independentid www.independentid.com phil.hunt@oracle.com On 2012-06-29, at 1:54 PM, John Bradley wrote: > No, >=20 > Trying to explain this over email is a challenge:) >=20 > This apples to both native apps and Web Servers who are OAuth Clients. >=20 > Imagine there are two web servers that authenticate people with = Facebook Connect (just an example). >=20 > Site A is I love Puppies (An evil site) > Site B is I Hate Larry Ellison (A good site) >=20 > You as a chocolate lover go to Site A and login to get some cool free = screensaver of Puppies. > Site A gets a token for your social graph no big deal mostly public = stuff. However they discovery you work for Mr Evil who they think is = purchasing paradise to put up a parking lot. Ummm....ok. I didn't want to go political on this. ;-) >=20 > They then go to site B who is using the implicit flow for Facebook = authentication. They login using a web browser but using any one of a = number of browser plugins modify the response to have the access_token = that they got from you when you logged into their site. They now post = as you telling everyone that Larry can't sail and has bad fashion sense. = (Perhaps true) You might now have some explaining to do! Soooo...according to the specs, there are now TWO mistakes: 1. Implicit is intended ONLY for java script clients in the browser. = Implicit clients shouldn't have any data of value (at least retained = data).=20 2. The MS example states that they have control of the client = application and its communications. Do we need to make #1 even more clearer -- an entire paragraph in all = caps maybe? ;-) Since the researchers put a proxy server in between the app and = Facebook. Therefore ANY OAUTH flow would be compromised since they are = able to insert tokens into the flow. Adding client id isn't going to = help (so I agree with you there). But I point out this hack only works if you can intercept the = communications path. If we were talking about some sports network on a public internet site, = this problem wouldn't come up unless that hackers have access to the web = sites physical network and can reconfigure the clients proxy server = settings. In the end, I don't think this is a valid *oauth* security issue since = the assumption is a compromised client and/or communications path. This = is a network security issue. > It would be worse if Site B had some PII about you or could transfer = the money from your bank based on that authentication. >=20 > The same thing could happen with the code flow if the client is public = and doesn't have a secret. Site A doesn't use the code themselves when = you login, they just let you through to get the puppy photos. Agreed. > They immediately take the token to site B and paste it into a = legitimate response (note the client_id is not in the response or code ) = the public client then presents that to the token endpoint with it's = client_id to get the access_token. The token endpoint just hands it = over because without a client_secret it is not required to authenticate = the client. >=20 > What Dick and I are saying is that we don't see the need not to verify = the client_id in the request to the token endpoint. If it were required = clients would not be able to mistakenly accept codes issued to diffrent = clients. >=20 > I strongly suspect most implementations do that already, so why not = clarify the spec on that point. =20 >=20 > That won't stop the attack on implicit clients. >=20 > This is why openID 2.0, openID Connect, SAML and every other identity = protocol I can think of audience restrict the assertion to the intended = recipient and sign or integrity protect the response. >=20 > That is not needed for the typical authorization use case of OAuth, = but is a really good idea if you are asserting Authentication = information to the client. >=20 > No puppies were hurt in the creation of this message. > John B. >=20 > On 2012-06-29, at 4:16 PM, Phil Hunt wrote: >=20 >> John, >>=20 >> I think that helps to clarify the authorize issue. >>=20 >> But they were talking about a phishing site obtaining a legit access = token from Facebook. >>> Let's take Soluto's metro app as an example to describe the problem. = The app supports Facebook Login. As an attacker, we can write a regular = Facebook app. Once the victim user allows our app to access her Facebook = data, we receive an access_token from the traffic. Then, on our own = machine (i.e., the "attacker" machine), we run the metro app of Soluto, = and use a HTTP proxy to insert the victim's access_token into the = traffic of Facebook login. Through this way, we are able to log into the = victim's Soluto account from our machine. Other than Soluto, we also = have confirmed the same issue on another Windows 8 metro-app Givit. >>=20 >>=20 >> Important: the attack works because the researchers had control of = the client application. And thus they were able to insert the token = between the metro client app and the server because they are able to get = in the communications path. All bets are off. If the attacker can insert = a token then can insert appropriate client_id's and responses in the = stream as well. >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >>=20 >>=20 >> On 2012-06-29, at 1:00 PM, John Bradley wrote: >>=20 >>> The attack requires a web browser that allows modifying the value of = the of the redirect URI. It is dead simple cut token or code from the = string and paste in the token or code that was granted by the user you = want to impersonate. >>>=20 >>> OAuth responses are not signed or audience restricted to the = client(except confidential clients using the code flow). =20 >>>=20 >>> In cases where the code or token is passed over a back channel to a = server, faking the entire client is the easiest thing for the attacker. >>>=20 >>> I don't consider these to be authorization attacks, rather attacks = on a client that is inappropariatly making unwarranted assumptions about = the presenter of the token. >>>=20 >>> John B. >>> On 2012-06-29, at 3:29 PM, Phil Hunt wrote: >>>=20 >>>> We need more info on the inject method the researchers used before = we can account for it.=20 >>>>=20 >>>> Phil >>>>=20 >>>> On 2012-06-29, at 12:16, John Bradley wrote: >>>>=20 >>>>> The same thing can be done with code. >>>>>=20 >>>>> If the token endpoint checks the client_id before giving out the = access token then the attack on code can be prevented, as the token = endpoint won't return the access token. >>>>>=20 >>>>> The spec dosen't require authenticating public clients currently = so it is a slightly more difficult attack but possible. >>>>>=20 >>>>> Dick and I are suggesting closing the hole at the token endpoint = so that nether confidential nor public clients using the code flow are = susceptible to this substitution attack. >>>>>=20 >>>>> John B. >>>>>=20 >>>>> On 2012-06-29, at 2:53 PM, PhiIt helps with the code flow when l = Hunt wrote: >>>>>=20 >>>>>> I'm not seeing how client id helps if a proxy server is somehow = involved with inserting the bearer token as the researchers suggested.=20= >>>>>>=20 >>>>>> Phil >>>>>>=20 >>>>>> On 2012-06-29, at 11:30, John Bradley wrote: >>>>>>=20 >>>>>>> I think they only exploited the implicit flow. =20 >>>>>>>=20 >>>>>>> My point was that there is a way you could do the same thing = with code if it is a public client that is not authenticating to the = token endpoint. >>>>>>>=20 >>>>>>> In general making identity assumptions in the client based on a = code or access_token has risks that are out of scope for OAuth. >>>>>>>=20 >>>>>>> We do however want to provide good advice about specific things = that can leave systems insecure when using OAuth. >>>>>>>=20 >>>>>>> John B. >>>>>>>=20 >>>>>>> On 2012-06-29, at 2:22 PM, Phil Hunt wrote: >>>>>>>=20 >>>>>>>> I'm not clear whether the MS Security Researcher hack was with = the authorization code or the access token. If the latter, the client_id = is out of the picture isn't it? >>>>>>>>=20 >>>>>>>> Phil >>>>>>>>=20 >>>>>>>> @independentid >>>>>>>> www.independentid.com >>>>>>>> phil.hunt@oracle.com >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On 2012-06-29, at 11:14 AM, Dick Hardt wrote: >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On Jun 29, 2012, at 11:06 AM, John Bradley wrote: >>>>>>>>>=20 >>>>>>>>>> It is nice to know that I may occasionally be correct:) >>>>>>>>>=20 >>>>>>>>> You must be delighted when it happens! ;) >>>>>>>>>=20 >>>>>>>>>> While you may assume that it is reasonable for a client with = a code to make a request to the token endpoint including it's client_id = and the server to only give out the access token if the client_id in the = token request matches the one in the original authorization request. = However the spec specifically doesn't require that. >>>>>>>>>=20 >>>>>>>>> I think that is an error in the spec and should be changed, or = text adding saying that the client_id SHOULD be checked. >>>>>>>>>=20 >>>>>>>>> -- Dick >>>>>>>>> _______________________________________________ >>>>>>>>> OAuth mailing list >>>>>>>>> OAuth@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>=20 >>>>>>>=20 >>>>>=20 >>>=20 >>=20 >=20 From ve7jtb@ve7jtb.com Fri Jun 29 20:35:50 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E2C621F8587 for ; Fri, 29 Jun 2012 20:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.159 X-Spam-Level: X-Spam-Status: No, score=-3.159 tagged_above=-999 required=5 tests=[AWL=-0.160, BAYES_00=-2.599, J_CHICKENPOX_66=0.6, 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 osX9CYxattqy for ; Fri, 29 Jun 2012 20:35:47 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id A407621F858F for ; Fri, 29 Jun 2012 20:35:47 -0700 (PDT) Received: by ggnc4 with SMTP id c4so3697826ggn.31 for ; Fri, 29 Jun 2012 20:35:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=AFCu8FCsm7YREkUig7GYLKdX9Oo0LXg5SEi22nMl1ao=; b=VWt9DO81PCf1yHrweQPLMXat+C4xtbzwrlNfdGIIjCtm5jfepaSxvkksly+1ndpQMY OdMB2YbFY6E5Zls1dzUUFb16hgXnvp5Pa7r60G+mzZ5VRKnO7pWckH8lBF8B7EFy0AlK yESXTj2Tr5YF910A4YfPtUc4Ttaf/2HyVp57iz4KGuVpT06LpmOKbop4phEMgoVEeXi3 f92MXr/zZPAigRDWkAgSj9Z1Y8QPJ+bEGfnaWHs3gvSOkB+yjnG/isH+0l9ebW9KSPBG UtGSLVAKs0iDoh1QhX8qiy+J4YzJzCloGE2s3HpGiIQqaT9nzh1CsXPV1gtFSqTBJm4U f9Iw== Received: by 10.236.73.4 with SMTP id u4mr6556730yhd.78.1341027346819; Fri, 29 Jun 2012 20:35:46 -0700 (PDT) Received: from [192.168.1.211] (190-20-59-251.baf.movistar.cl. [190.20.59.251]) by mx.google.com with ESMTPS id c12sm5406458ank.14.2012.06.29.20.35.18 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 29 Jun 2012 20:35:45 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_A14A1547-3EA8-4659-A486-63646BC5E40A"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <7A8FC3E0-79E4-403D-8A4E-16CBCD55C565@oracle.com> Date: Fri, 29 Jun 2012 23:34:42 -0400 Message-Id: <904BFB7C-0A84-427F-BA06-CBEE90FCCF53@ve7jtb.com> References: <4FE223E4.6060307@mitre.org> <4FE226BC.6010403@alcatel-lucent.com> <59E470B10C4630419ED717AC79FCF9A910889AB5@BL2PRD0410MB363.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A917052BC8@SN2PRD0410MB370.namprd04.prod.outlook.com> <4FE37D38.1030407@gmail.com> <59E470B10C4630419ED717AC79FCF9A91A2C8949@CH1PRD0410MB369.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A91A2D1309@CH1PRD0410MB369.namprd04.prod.outlook.com> <496AFB1D-A609-4188-B92D-2185E8880388@ve7jtb.com> <59E470B10C4630419ED717AC79FCF9A91A2D13C9@CH1PRD0410MB369.namprd04.prod.outlook.com> <67F8B633-E4C8-42F6-B84C-FDBC337B7EEA@ve7jtb.com> <04C05FAA-63BC-4441-8540-36280E40DB98@adobe.com> <4FEDE4AF.9030107@mitre.org> <8C18C43D-AC63-465A-ADC2-966CE7F38685@gmail.com> <71899C6B-40A6-46E8-BCF8-BF9C43B83C64@oracle.com> <83124DF5-8D21-4D63-9D37-BBFBA0932065@ve7jtb.com> <353091D2-F63F-4D48-A49B-99E53FE31954@oracle.com> <7ED8AA4B-85D0-4D60-AFB6-C50503042A52@ve7jtb.com> <9DFCB89E-39E2-4F70-A9F8-4D245800D798@oracle.com> <7A8FC3E0-79E4-403D-8A4E-16CBCD55C565@oracle.com> To: Phil Hunt X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQnDeJqsMRD+5JUh2cMgI71tRKtCZzFiKLQ1hY5C7+bpzOBftRoK2b/UVdNNeFtmPmtSiJQn Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Report an authentication issue X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 03:35:50 -0000 --Apple-Mail=_A14A1547-3EA8-4659-A486-63646BC5E40A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Phil, =20 You know not everyone gets a personalized example:) In the below examples there is no proxy or other compromise of the = client required only the ability to do what appears to be a SSO login = using OAuth. The attacker needs only a web browser. When they tales about compromised clients, they are not talking about = needing to compromise the app on the users phone. They can compromise a client on there platform e.g. load it into a = iPhone emulator, or just create a new client that emulates the backend = API. There are already script kits to exploit this. The vulnerability was = distributed in API kits from Faceboo, Apple and others. If it was just one developer getting it wrong that would be one thing, = hundreds getting it wrong by using the API in trusted development kits = is a much worse problem in my opinion. My hope is to at least make it clear to the library authors and tool = venders, what are unsafe patterns. This exploit is unfortunately not hypothetical. John B. On 2012-06-29, at 7:31 PM, Phil Hunt wrote: > See below... >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 >=20 >=20 > On 2012-06-29, at 1:54 PM, John Bradley wrote: >=20 >> No, >>=20 >> Trying to explain this over email is a challenge:) >>=20 >> This apples to both native apps and Web Servers who are OAuth = Clients. >>=20 >> Imagine there are two web servers that authenticate people with = Facebook Connect (just an example). >>=20 >> Site A is I love Puppies (An evil site) >> Site B is I Hate Larry Ellison (A good site) >>=20 >> You as a chocolate lover go to Site A and login to get some cool free = screensaver of Puppies. >> Site A gets a token for your social graph no big deal mostly public = stuff. However they discovery you work for Mr Evil who they think is = purchasing paradise to put up a parking lot. >=20 > Ummm....ok. I didn't want to go political on this. ;-) >>=20 >> They then go to site B who is using the implicit flow for Facebook = authentication. They login using a web browser but using any one of a = number of browser plugins modify the response to have the access_token = that they got from you when you logged into their site. They now post = as you telling everyone that Larry can't sail and has bad fashion sense. = (Perhaps true) You might now have some explaining to do! >=20 > Soooo...according to the specs, there are now TWO mistakes: >=20 > 1. Implicit is intended ONLY for java script clients in the browser. = Implicit clients shouldn't have any data of value (at least retained = data).=20 >=20 > 2. The MS example states that they have control of the client = application and its communications. >=20 > Do we need to make #1 even more clearer -- an entire paragraph in all = caps maybe? ;-) >=20 > Since the researchers put a proxy server in between the app and = Facebook. Therefore ANY OAUTH flow would be compromised since they are = able to insert tokens into the flow. Adding client id isn't going to = help (so I agree with you there). >=20 > But I point out this hack only works if you can intercept the = communications path. >=20 > If we were talking about some sports network on a public internet = site, this problem wouldn't come up unless that hackers have access to = the web sites physical network and can reconfigure the clients proxy = server settings. >=20 > In the end, I don't think this is a valid *oauth* security issue since = the assumption is a compromised client and/or communications path. This = is a network security issue. >=20 >=20 >> It would be worse if Site B had some PII about you or could transfer = the money from your bank based on that authentication. >=20 >>=20 >> The same thing could happen with the code flow if the client is = public and doesn't have a secret. Site A doesn't use the code = themselves when you login, they just let you through to get the puppy = photos. > Agreed. >> They immediately take the token to site B and paste it into a = legitimate response (note the client_id is not in the response or code ) = the public client then presents that to the token endpoint with it's = client_id to get the access_token. The token endpoint just hands it = over because without a client_secret it is not required to authenticate = the client. >>=20 >> What Dick and I are saying is that we don't see the need not to = verify the client_id in the request to the token endpoint. If it were = required clients would not be able to mistakenly accept codes issued to = diffrent clients. >=20 >>=20 >> I strongly suspect most implementations do that already, so why not = clarify the spec on that point. =20 >=20 >>=20 >> That won't stop the attack on implicit clients. >>=20 >> This is why openID 2.0, openID Connect, SAML and every other identity = protocol I can think of audience restrict the assertion to the intended = recipient and sign or integrity protect the response. >>=20 >> That is not needed for the typical authorization use case of OAuth, = but is a really good idea if you are asserting Authentication = information to the client. >>=20 >> No puppies were hurt in the creation of this message. >> John B. >>=20 >> On 2012-06-29, at 4:16 PM, Phil Hunt wrote: >>=20 >>> John, >>>=20 >>> I think that helps to clarify the authorize issue. >>>=20 >>> But they were talking about a phishing site obtaining a legit access = token from Facebook. >>>> Let's take Soluto's metro app as an example to describe the = problem. The app supports Facebook Login. As an attacker, we can write a = regular Facebook app. Once the victim user allows our app to access her = Facebook data, we receive an access_token from the traffic. Then, on our = own machine (i.e., the "attacker" machine), we run the metro app of = Soluto, and use a HTTP proxy to insert the victim's access_token into = the traffic of Facebook login. Through this way, we are able to log into = the victim's Soluto account from our machine. Other than Soluto, we also = have confirmed the same issue on another Windows 8 metro-app Givit. >>>=20 >>>=20 >>> Important: the attack works because the researchers had control of = the client application. And thus they were able to insert the token = between the metro client app and the server because they are able to get = in the communications path. All bets are off. If the attacker can insert = a token then can insert appropriate client_id's and responses in the = stream as well. >>>=20 >>> Phil >>>=20 >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> On 2012-06-29, at 1:00 PM, John Bradley wrote: >>>=20 >>>> The attack requires a web browser that allows modifying the value = of the of the redirect URI. It is dead simple cut token or code from = the string and paste in the token or code that was granted by the user = you want to impersonate. >>>>=20 >>>> OAuth responses are not signed or audience restricted to the = client(except confidential clients using the code flow). =20 >>>>=20 >>>> In cases where the code or token is passed over a back channel to a = server, faking the entire client is the easiest thing for the attacker. >>>>=20 >>>> I don't consider these to be authorization attacks, rather attacks = on a client that is inappropariatly making unwarranted assumptions about = the presenter of the token. >>>>=20 >>>> John B. >>>> On 2012-06-29, at 3:29 PM, Phil Hunt wrote: >>>>=20 >>>>> We need more info on the inject method the researchers used before = we can account for it.=20 >>>>>=20 >>>>> Phil >>>>>=20 >>>>> On 2012-06-29, at 12:16, John Bradley wrote: >>>>>=20 >>>>>> The same thing can be done with code. >>>>>>=20 >>>>>> If the token endpoint checks the client_id before giving out the = access token then the attack on code can be prevented, as the token = endpoint won't return the access token. >>>>>>=20 >>>>>> The spec dosen't require authenticating public clients currently = so it is a slightly more difficult attack but possible. >>>>>>=20 >>>>>> Dick and I are suggesting closing the hole at the token endpoint = so that nether confidential nor public clients using the code flow are = susceptible to this substitution attack. >>>>>>=20 >>>>>> John B. >>>>>>=20 >>>>>> On 2012-06-29, at 2:53 PM, PhiIt helps with the code flow when l = Hunt wrote: >>>>>>=20 >>>>>>> I'm not seeing how client id helps if a proxy server is somehow = involved with inserting the bearer token as the researchers suggested.=20= >>>>>>>=20 >>>>>>> Phil >>>>>>>=20 >>>>>>> On 2012-06-29, at 11:30, John Bradley wrote: >>>>>>>=20 >>>>>>>> I think they only exploited the implicit flow. =20 >>>>>>>>=20 >>>>>>>> My point was that there is a way you could do the same thing = with code if it is a public client that is not authenticating to the = token endpoint. >>>>>>>>=20 >>>>>>>> In general making identity assumptions in the client based on a = code or access_token has risks that are out of scope for OAuth. >>>>>>>>=20 >>>>>>>> We do however want to provide good advice about specific things = that can leave systems insecure when using OAuth. >>>>>>>>=20 >>>>>>>> John B. >>>>>>>>=20 >>>>>>>> On 2012-06-29, at 2:22 PM, Phil Hunt wrote: >>>>>>>>=20 >>>>>>>>> I'm not clear whether the MS Security Researcher hack was with = the authorization code or the access token. If the latter, the client_id = is out of the picture isn't it? >>>>>>>>>=20 >>>>>>>>> Phil >>>>>>>>>=20 >>>>>>>>> @independentid >>>>>>>>> www.independentid.com >>>>>>>>> phil.hunt@oracle.com >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On 2012-06-29, at 11:14 AM, Dick Hardt wrote: >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> On Jun 29, 2012, at 11:06 AM, John Bradley wrote: >>>>>>>>>>=20 >>>>>>>>>>> It is nice to know that I may occasionally be correct:) >>>>>>>>>>=20 >>>>>>>>>> You must be delighted when it happens! ;) >>>>>>>>>>=20 >>>>>>>>>>> While you may assume that it is reasonable for a client with = a code to make a request to the token endpoint including it's client_id = and the server to only give out the access token if the client_id in the = token request matches the one in the original authorization request. = However the spec specifically doesn't require that. >>>>>>>>>>=20 >>>>>>>>>> I think that is an error in the spec and should be changed, = or text adding saying that the client_id SHOULD be checked. >>>>>>>>>>=20 >>>>>>>>>> -- Dick >>>>>>>>>> _______________________________________________ >>>>>>>>>> OAuth mailing list >>>>>>>>>> OAuth@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>=20 >>>>>>>>=20 >>>>>>=20 >>>>=20 >>>=20 >>=20 >=20 --Apple-Mail=_A14A1547-3EA8-4659-A486-63646BC5E40A Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw 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+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDYz MDAzMzQ0M1owIwYJKoZIhvcNAQkEMRYEFP2SGSCdFeIc0mNsklI+QYzbBiA0MIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB AA0OEeMrv3WPM0Qan/OnJMuryeKnRw+xGKH6f0bUCKIvPoJHH7d8jyrfeagJKvfiGsxDPBVgsAZc MHYD/vC+l9A+WgvpM7gGrBs4/LKPb5lR0H9DeRIRR8skehLKYnCFG2KXqQPDFOicR76A7X5SvXuy XZsBBRtcTFcdNmcKMZ0xDNkSgb3jQiurNjZSuVZpw7Gg8RVH+ywb9ACxJqlkkHC1WIFNRODjfKoN uq3raBLjInTjWPdiS7EA7C8gaeZ+/hX1NqQyHKrBWzuEsuBamuyhCfSqTU27gv0JScUsHXbAfEK2 WDcT9CuaeBgEJVITcdIiGh9XxqL5mueNTEiRxsUAAAAAAAA= --Apple-Mail=_A14A1547-3EA8-4659-A486-63646BC5E40A-- From phil.hunt@oracle.com Sat Jun 30 01:11:25 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B786221F87A9 for ; Sat, 30 Jun 2012 01:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.412 X-Spam-Level: X-Spam-Status: No, score=-9.412 tagged_above=-999 required=5 tests=[AWL=-0.809, BAYES_00=-2.599, J_CHICKENPOX_66=0.6, MIME_QP_LONG_LINE=1.396, 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 w2YQ7gw4NE82 for ; Sat, 30 Jun 2012 01:11:20 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id A39CE21F87AF for ; Sat, 30 Jun 2012 01:11:18 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q5U8BFdL026993 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 30 Jun 2012 08:11:16 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 q5U8BEvW003289 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 30 Jun 2012 08:11:15 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 q5U8BETv003000; Sat, 30 Jun 2012 03:11:14 -0500 Received: from [192.168.1.125] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 30 Jun 2012 01:11:14 -0700 References: <4FE223E4.6060307@mitre.org> <4FE226BC.6010403@alcatel-lucent.com> <59E470B10C4630419ED717AC79FCF9A910889AB5@BL2PRD0410MB363.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A917052BC8@SN2PRD0410MB370.namprd04.prod.outlook.com> <4FE37D38.1030407@gmail.com> <59E470B10C4630419ED717AC79FCF9A91A2C8949@CH1PRD0410MB369.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A91A2D1309@CH1PRD0410MB369.namprd04.prod.outlook.com> <496AFB1D-A609-4188-B92D-2185E8880388@ve7jtb.com> <59E470B10C4630419ED717AC79FCF9A91A2D13C9@CH1PRD0410MB369.namprd04.prod.outlook.com> <67F8B633-E4C8-42F6-B84C-FDBC337B7EEA@ve7jtb.com> <04C05FAA-63BC-4441-8540-36280E40DB98@adobe.com> <4FEDE4AF.9030107@mitre.org> <8C18C43D-AC63-465A-ADC2-966CE7F38685@gmail.com> <71899C6B-40A6-46E8-BCF8-BF9C43B83C64@oracle.com> <83124DF5-8D21-4D63-9D37-BBFBA0932065@ve7jtb.com> <353091D2-F63F-4D48-A49B-99E53FE31954@oracle.com> <7ED8AA4B-85D0-4D60-AFB6-C50503042A52@ve7jtb.com> <9DFCB89E-39E2-4F70-A9F8-4D245800D798@oracle.com> <7A8FC3E0-79E4-403D-8A4E-16CBCD55C565@oracle.com> <904BFB7C-0A84-427F-BA06-CBEE90FCCF53@ve7jtb.com> In-Reply-To: <904BFB7C-0A84-427F-BA06-CBEE90FCCF53@ve7jtb.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (9B206) From: Phil Hunt Date: Sat, 30 Jun 2012 01:11:12 -0700 To: John Bradley X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Report an authentication issue X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 08:11:26 -0000 John, Thanks. I am not understanding yet. But if you believe there is a problem th= at is enough for me. I do not mean in any way dismiss it. Do you think the issue you described is different from the original message t= hat started this thread? It seems so to me. =20 Phil On 2012-06-29, at 20:34, John Bradley wrote: > Phil, =20 >=20 > You know not everyone gets a personalized example:) >=20 > In the below examples there is no proxy or other compromise of the client r= equired only the ability to do what appears to be a SSO login using OAuth. > The attacker needs only a web browser. >=20 > When they tales about compromised clients, they are not talking about nee= ding to compromise the app on the users phone. >=20 > They can compromise a client on there platform e.g. load it into a iPhone e= mulator, or just create a new client that emulates the backend API. >=20 > There are already script kits to exploit this. The vulnerability was dis= tributed in API kits from Faceboo, Apple and others. >=20 > If it was just one developer getting it wrong that would be one thing, hu= ndreds getting it wrong by using the API in trusted development kits is a mu= ch worse problem in my opinion. >=20 > My hope is to at least make it clear to the library authors and tool vende= rs, what are unsafe patterns. >=20 > This exploit is unfortunately not hypothetical. >=20 > John B. >=20 >=20 > On 2012-06-29, at 7:31 PM, Phil Hunt wrote: >=20 >> See below... >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >>=20 >>=20 >> On 2012-06-29, at 1:54 PM, John Bradley wrote: >>=20 >>> No, >>>=20 >>> Trying to explain this over email is a challenge:) >>>=20 >>> This apples to both native apps and Web Servers who are OAuth Clients. >>>=20 >>> Imagine there are two web servers that authenticate people with Facebook= Connect (just an example). >>>=20 >>> Site A is I love Puppies (An evil site) >>> Site B is I Hate Larry Ellison (A good site) >>>=20 >>> You as a chocolate lover go to Site A and login to get some cool free sc= reensaver of Puppies. >>> Site A gets a token for your social graph no big deal mostly public stuf= f. However they discovery you work for Mr Evil who they think is purchasing= paradise to put up a parking lot. >>=20 >> Ummm....ok. I didn't want to go political on this. ;-) >>>=20 >>> They then go to site B who is using the implicit flow for Facebook authe= ntication. They login using a web browser but using any one of a number of b= rowser plugins modify the response to have the access_token that they got fr= om you when you logged into their site. They now post as you telling every= one that Larry can't sail and has bad fashion sense. (Perhaps true) You mig= ht now have some explaining to do! >>=20 >> Soooo...according to the specs, there are now TWO mistakes: >>=20 >> 1. Implicit is intended ONLY for java script clients in the browser. Impl= icit clients shouldn't have any data of value (at least retained data).=20 >>=20 >> 2. The MS example states that they have control of the client application= and its communications. >>=20 >> Do we need to make #1 even more clearer -- an entire paragraph in all cap= s maybe? ;-) >>=20 >> Since the researchers put a proxy server in between the app and Facebook.= Therefore ANY OAUTH flow would be compromised since they are able to insert= tokens into the flow. Adding client id isn't going to help (so I agree wit= h you there). >>=20 >> But I point out this hack only works if you can intercept the communicati= ons path. >>=20 >> If we were talking about some sports network on a public internet site, t= his problem wouldn't come up unless that hackers have access to the web site= s physical network and can reconfigure the clients proxy server settings. >>=20 >> In the end, I don't think this is a valid *oauth* security issue since th= e assumption is a compromised client and/or communications path. This is a n= etwork security issue. >>=20 >>=20 >>> It would be worse if Site B had some PII about you or could transfer the= money from your bank based on that authentication. >>=20 >>>=20 >>> The same thing could happen with the code flow if the client is public a= nd doesn't have a secret. Site A doesn't use the code themselves when you l= ogin, they just let you through to get the puppy photos. >> Agreed. >>> They immediately take the token to site B and paste it into a legitimate= response (note the client_id is not in the response or code ) the public cl= ient then presents that to the token endpoint with it's client_id to get the= access_token. The token endpoint just hands it over because without a cli= ent_secret it is not required to authenticate the client. >>>=20 >>> What Dick and I are saying is that we don't see the need not to verify t= he client_id in the request to the token endpoint. If it were required clie= nts would not be able to mistakenly accept codes issued to diffrent clients.= >>=20 >>>=20 >>> I strongly suspect most implementations do that already, so why not clar= ify the spec on that point. =20 >>=20 >>>=20 >>> That won't stop the attack on implicit clients. >>>=20 >>> This is why openID 2.0, openID Connect, SAML and every other identity pr= otocol I can think of audience restrict the assertion to the intended recipi= ent and sign or integrity protect the response. >>>=20 >>> That is not needed for the typical authorization use case of OAuth, but i= s a really good idea if you are asserting Authentication information to the c= lient. >>>=20 >>> No puppies were hurt in the creation of this message. >>> John B. >>>=20 >>> On 2012-06-29, at 4:16 PM, Phil Hunt wrote: >>>=20 >>>> John, >>>>=20 >>>> I think that helps to clarify the authorize issue. >>>>=20 >>>> But they were talking about a phishing site obtaining a legit access to= ken from Facebook. >>>>> Let's take Soluto's metro app as an example to describe the problem. T= he app supports Facebook Login. As an attacker, we can write a regular Faceb= ook app. Once the victim user allows our app to access her Facebook data, we= receive an access_token from the traffic. Then, on our own machine (i.e., t= he "attacker" machine), we run the metro app of Soluto, and use a HTTP proxy= to insert the victim's access_token into the traffic of Facebook login. Thr= ough this way, we are able to log into the victim's Soluto account from our m= achine. Other than Soluto, we also have confirmed the same issue on another W= indows 8 metro-app Givit. >>>>=20 >>>>=20 >>>> Important: the attack works because the researchers had control of the c= lient application. And thus they were able to insert the token between the m= etro client app and the server because they are able to get in the communica= tions path. All bets are off. If the attacker can insert a token then can in= sert appropriate client_id's and responses in the stream as well. >>>>=20 >>>> Phil >>>>=20 >>>> @independentid >>>> www.independentid.com >>>> phil.hunt@oracle.com >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On 2012-06-29, at 1:00 PM, John Bradley wrote: >>>>=20 >>>>> The attack requires a web browser that allows modifying the value of t= he of the redirect URI. It is dead simple cut token or code from the strin= g and paste in the token or code that was granted by the user you want to im= personate. >>>>>=20 >>>>> OAuth responses are not signed or audience restricted to the client(ex= cept confidential clients using the code flow). =20 >>>>>=20 >>>>> In cases where the code or token is passed over a back channel to a se= rver, faking the entire client is the easiest thing for the attacker. >>>>>=20 >>>>> I don't consider these to be authorization attacks, rather attacks on= a client that is inappropariatly making unwarranted assumptions about the p= resenter of the token. >>>>>=20 >>>>> John B. >>>>> On 2012-06-29, at 3:29 PM, Phil Hunt wrote: >>>>>=20 >>>>>> We need more info on the inject method the researchers used before we= can account for it.=20 >>>>>>=20 >>>>>> Phil >>>>>>=20 >>>>>> On 2012-06-29, at 12:16, John Bradley wrote: >>>>>>=20 >>>>>>> The same thing can be done with code. >>>>>>>=20 >>>>>>> If the token endpoint checks the client_id before giving out the acc= ess token then the attack on code can be prevented, as the token endpoint wo= n't return the access token. >>>>>>>=20 >>>>>>> The spec dosen't require authenticating public clients currently so i= t is a slightly more difficult attack but possible. >>>>>>>=20 >>>>>>> Dick and I are suggesting closing the hole at the token endpoint so t= hat nether confidential nor public clients using the code flow are susceptib= le to this substitution attack. >>>>>>>=20 >>>>>>> John B. >>>>>>>=20 >>>>>>> On 2012-06-29, at 2:53 PM, PhiIt helps with the code flow when l Hun= t wrote: >>>>>>>=20 >>>>>>>> I'm not seeing how client id helps if a proxy server is somehow inv= olved with inserting the bearer token as the researchers suggested.=20 >>>>>>>>=20 >>>>>>>> Phil >>>>>>>>=20 >>>>>>>> On 2012-06-29, at 11:30, John Bradley wrote: >>>>>>>>=20 >>>>>>>>> I think they only exploited the implicit flow. =20 >>>>>>>>>=20 >>>>>>>>> My point was that there is a way you could do the same thing with c= ode if it is a public client that is not authenticating to the token endpoin= t. >>>>>>>>>=20 >>>>>>>>> In general making identity assumptions in the client based on a co= de or access_token has risks that are out of scope for OAuth. >>>>>>>>>=20 >>>>>>>>> We do however want to provide good advice about specific things th= at can leave systems insecure when using OAuth. >>>>>>>>>=20 >>>>>>>>> John B. >>>>>>>>>=20 >>>>>>>>> On 2012-06-29, at 2:22 PM, Phil Hunt wrote: >>>>>>>>>=20 >>>>>>>>>> I'm not clear whether the MS Security Researcher hack was with th= e authorization code or the access token. If the latter, the client_id is ou= t of the picture isn't it? >>>>>>>>>>=20 >>>>>>>>>> Phil >>>>>>>>>>=20 >>>>>>>>>> @independentid >>>>>>>>>> www.independentid.com >>>>>>>>>> phil.hunt@oracle.com >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> On 2012-06-29, at 11:14 AM, Dick Hardt wrote: >>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> On Jun 29, 2012, at 11:06 AM, John Bradley wrote: >>>>>>>>>>>=20 >>>>>>>>>>>> It is nice to know that I may occasionally be correct:) >>>>>>>>>>>=20 >>>>>>>>>>> You must be delighted when it happens! ;) >>>>>>>>>>>=20 >>>>>>>>>>>> While you may assume that it is reasonable for a client with a c= ode to make a request to the token endpoint including it's client_id and the= server to only give out the access token if the client_id in the token requ= est matches the one in the original authorization request. However the spe= c specifically doesn't require that. >>>>>>>>>>>=20 >>>>>>>>>>> I think that is an error in the spec and should be changed, or t= ext adding saying that the client_id SHOULD be checked. >>>>>>>>>>>=20 >>>>>>>>>>> -- Dick >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> OAuth mailing list >>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>=20 >>>>>=20 >>>>=20 >>>=20 >>=20 >=20 From ve7jtb@ve7jtb.com Sat Jun 30 10:46:27 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C1C821F8596 for ; Sat, 30 Jun 2012 10:46:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.156 X-Spam-Level: X-Spam-Status: No, score=-3.156 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, J_CHICKENPOX_66=0.6, 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 c02ThqtD8B-5 for ; Sat, 30 Jun 2012 10:46:26 -0700 (PDT) Received: from mail-yw0-f42.google.com (mail-yw0-f42.google.com [209.85.213.42]) by ietfa.amsl.com (Postfix) with ESMTP id ED1CD21F8593 for ; Sat, 30 Jun 2012 10:46:25 -0700 (PDT) Received: by yhfq11 with SMTP id q11so4208254yhf.15 for ; Sat, 30 Jun 2012 10:46:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=9SEo/Jx0VMt+fL0XF90kb8mSSq4NZklEEOApVrAr9V0=; b=AxmI0KU2uivzgnYIhY3nIFiAfu0ZPFTzSATEls5tA94O61O5SIEHZU5X1w3a7HtW4+ Y2wfAf3xXoOLk/bISrCTg/m5uZoIG0+3qgYNuhfko7rGbTuRgsUDab5LOTzqk9O7y3tA Oe+rpzXVFrQVEIMLGb+DLY4SR8W2h0O58vtt7RvzAhIHCKmrorsVILgs7tSKX+zn0hn7 OV26+W/C3alLhjDFi6HlU/m0MjupK9GW6+qRjyyrk474660dNjJOarZIRq27OcfA04Px fiGLMX/YZCROjHqQrTOO+ulqnE19UPROwtxkSSNdkRSCTC62R6L+LKpCa1W9F+X6KL+Q uziA== Received: by 10.236.175.226 with SMTP id z62mr8643529yhl.39.1341078386040; Sat, 30 Jun 2012 10:46:26 -0700 (PDT) Received: from [192.168.1.211] (190-20-59-251.baf.movistar.cl. [190.20.59.251]) by mx.google.com with ESMTPS id m43sm13818195yhi.13.2012.06.30.10.46.22 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 30 Jun 2012 10:46:24 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_9601C55E-0CF3-4873-8996-6F4EA59CD852"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: Date: Sat, 30 Jun 2012 13:46:15 -0400 Message-Id: References: <4FE223E4.6060307@mitre.org> <4FE226BC.6010403@alcatel-lucent.com> <59E470B10C4630419ED717AC79FCF9A910889AB5@BL2PRD0410MB363.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A917052BC8@SN2PRD0410MB370.namprd04.prod.outlook.com> <4FE37D38.1030407@gmail.com> <59E470B10C4630419ED717AC79FCF9A91A2C8949@CH1PRD0410MB369.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A91A2D1309@CH1PRD0410MB369.namprd04.prod.outlook.com> <496AFB1D-A609-4188-B92D-2185E8880388@ve7jtb.com> <59E470B10C4630419ED717AC79FCF9A91A2D13C9@CH1PRD0410MB369.namprd04.prod.outlook.com> <67F8B633-E4C8-42F6-B84C-FDBC337B7EEA@ve7jtb.com> <04C05FAA-63BC-4441-8540-36280E40DB98@adobe.com> <4FEDE4AF.9030107@mitre.org> <8C18C43D-AC63-465A-ADC2-966CE7F38685@gmail.com> <71899C6B-40A6-46E8-BCF8-BF9C43B83C64@oracle.com> <83124DF5-8D21-4D63-9D37-BBFBA0932065@ve7jtb.com> <353091D2-F63F-4D48-A49B-99E53FE31954@oracle.com> <7ED8AA4B-85D0-4D60-AFB6-C50503042A52@ve7jtb.com> <9DFCB89E-39E2-4F70-A9F8-4D245800D798@oracle.com> <7A8FC3E0-79E4-403D-8A4E-16CBCD55C565@oracle.com> <904BFB7C-0A84-427F-BA06-CBEE90FCCF53@ve7jtb.com> To: Phil Hunt X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQm0ygBrMduBLURUPQWyQSf6yMy9i+JyFDL0/burhrsdPYJcQAcmlDk5Hn0UDCT+05ziEAcT Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Report an authentication issue X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 17:46:27 -0000 --Apple-Mail=_9601C55E-0CF3-4873-8996-6F4EA59CD852 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii There is one Core issue.=20 Audience restriction of the grant for the client. This is mostly = important where the client is inferring from the grant what the identity = of the presenter is. This surfaces in slightly different ways depending on the use case. 1, Native apps passing a access token over a back channel API to = Authenticate the user of the App. This is not a OAuth flow itself but = is enabled by OAuth. 2, Web Applications using implicit flow. (there are mitigations but = they are not part of OAuth core)=20 3, Public clients using code flow. Bearer tokens & MAC with per token secrets are both vulnerable to this. One observation from the security concern text I proposed that Dick and = others received was that 3 could be fixed relatively simply in the spec. The first two are out of scope for OAuth core and can really only be = dealt with by documenting them as a security concern so that people = avoid doing those things without additional security like using token = introspection etc. So they are all just different attacks exploiting the same flaw. The MS researchers may have a different opinion, but I have yet to hear = it. John B. On 2012-06-30, at 4:11 AM, Phil Hunt wrote: > John, >=20 > Thanks. I am not understanding yet. But if you believe there is a = problem that is enough for me. I do not mean in any way dismiss it. >=20 > Do you think the issue you described is different from the original = message that started this thread? It seems so to me. =20 >=20 > Phil >=20 > On 2012-06-29, at 20:34, John Bradley wrote: >=20 >> Phil, =20 >>=20 >> You know not everyone gets a personalized example:) >>=20 >> In the below examples there is no proxy or other compromise of the = client required only the ability to do what appears to be a SSO login = using OAuth. >> The attacker needs only a web browser. >>=20 >> When they tales about compromised clients, they are not talking = about needing to compromise the app on the users phone. >>=20 >> They can compromise a client on there platform e.g. load it into a = iPhone emulator, or just create a new client that emulates the backend = API. >>=20 >> There are already script kits to exploit this. The vulnerability = was distributed in API kits from Faceboo, Apple and others. >>=20 >> If it was just one developer getting it wrong that would be one = thing, hundreds getting it wrong by using the API in trusted = development kits is a much worse problem in my opinion. >>=20 >> My hope is to at least make it clear to the library authors and tool = venders, what are unsafe patterns. >>=20 >> This exploit is unfortunately not hypothetical. >>=20 >> John B. >>=20 >>=20 >> On 2012-06-29, at 7:31 PM, Phil Hunt wrote: >>=20 >>> See below... >>>=20 >>> Phil >>>=20 >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> On 2012-06-29, at 1:54 PM, John Bradley wrote: >>>=20 >>>> No, >>>>=20 >>>> Trying to explain this over email is a challenge:) >>>>=20 >>>> This apples to both native apps and Web Servers who are OAuth = Clients. >>>>=20 >>>> Imagine there are two web servers that authenticate people with = Facebook Connect (just an example). >>>>=20 >>>> Site A is I love Puppies (An evil site) >>>> Site B is I Hate Larry Ellison (A good site) >>>>=20 >>>> You as a chocolate lover go to Site A and login to get some cool = free screensaver of Puppies. >>>> Site A gets a token for your social graph no big deal mostly public = stuff. However they discovery you work for Mr Evil who they think is = purchasing paradise to put up a parking lot. >>>=20 >>> Ummm....ok. I didn't want to go political on this. ;-) >>>>=20 >>>> They then go to site B who is using the implicit flow for Facebook = authentication. They login using a web browser but using any one of a = number of browser plugins modify the response to have the access_token = that they got from you when you logged into their site. They now post = as you telling everyone that Larry can't sail and has bad fashion sense. = (Perhaps true) You might now have some explaining to do! >>>=20 >>> Soooo...according to the specs, there are now TWO mistakes: >>>=20 >>> 1. Implicit is intended ONLY for java script clients in the browser. = Implicit clients shouldn't have any data of value (at least retained = data).=20 >>>=20 >>> 2. The MS example states that they have control of the client = application and its communications. >>>=20 >>> Do we need to make #1 even more clearer -- an entire paragraph in = all caps maybe? ;-) >>>=20 >>> Since the researchers put a proxy server in between the app and = Facebook. Therefore ANY OAUTH flow would be compromised since they are = able to insert tokens into the flow. Adding client id isn't going to = help (so I agree with you there). >>>=20 >>> But I point out this hack only works if you can intercept the = communications path. >>>=20 >>> If we were talking about some sports network on a public internet = site, this problem wouldn't come up unless that hackers have access to = the web sites physical network and can reconfigure the clients proxy = server settings. >>>=20 >>> In the end, I don't think this is a valid *oauth* security issue = since the assumption is a compromised client and/or communications path. = This is a network security issue. >>>=20 >>>=20 >>>> It would be worse if Site B had some PII about you or could = transfer the money from your bank based on that authentication. >>>=20 >>>>=20 >>>> The same thing could happen with the code flow if the client is = public and doesn't have a secret. Site A doesn't use the code = themselves when you login, they just let you through to get the puppy = photos. >>> Agreed. >>>> They immediately take the token to site B and paste it into a = legitimate response (note the client_id is not in the response or code ) = the public client then presents that to the token endpoint with it's = client_id to get the access_token. The token endpoint just hands it = over because without a client_secret it is not required to authenticate = the client. >>>>=20 >>>> What Dick and I are saying is that we don't see the need not to = verify the client_id in the request to the token endpoint. If it were = required clients would not be able to mistakenly accept codes issued to = diffrent clients. >>>=20 >>>>=20 >>>> I strongly suspect most implementations do that already, so why not = clarify the spec on that point. =20 >>>=20 >>>>=20 >>>> That won't stop the attack on implicit clients. >>>>=20 >>>> This is why openID 2.0, openID Connect, SAML and every other = identity protocol I can think of audience restrict the assertion to the = intended recipient and sign or integrity protect the response. >>>>=20 >>>> That is not needed for the typical authorization use case of OAuth, = but is a really good idea if you are asserting Authentication = information to the client. >>>>=20 >>>> No puppies were hurt in the creation of this message. >>>> John B. >>>>=20 >>>> On 2012-06-29, at 4:16 PM, Phil Hunt wrote: >>>>=20 >>>>> John, >>>>>=20 >>>>> I think that helps to clarify the authorize issue. >>>>>=20 >>>>> But they were talking about a phishing site obtaining a legit = access token from Facebook. >>>>>> Let's take Soluto's metro app as an example to describe the = problem. The app supports Facebook Login. As an attacker, we can write a = regular Facebook app. Once the victim user allows our app to access her = Facebook data, we receive an access_token from the traffic. Then, on our = own machine (i.e., the "attacker" machine), we run the metro app of = Soluto, and use a HTTP proxy to insert the victim's access_token into = the traffic of Facebook login. Through this way, we are able to log into = the victim's Soluto account from our machine. Other than Soluto, we also = have confirmed the same issue on another Windows 8 metro-app Givit. >>>>>=20 >>>>>=20 >>>>> Important: the attack works because the researchers had control of = the client application. And thus they were able to insert the token = between the metro client app and the server because they are able to get = in the communications path. All bets are off. If the attacker can insert = a token then can insert appropriate client_id's and responses in the = stream as well. >>>>>=20 >>>>> Phil >>>>>=20 >>>>> @independentid >>>>> www.independentid.com >>>>> phil.hunt@oracle.com >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On 2012-06-29, at 1:00 PM, John Bradley wrote: >>>>>=20 >>>>>> The attack requires a web browser that allows modifying the value = of the of the redirect URI. It is dead simple cut token or code from = the string and paste in the token or code that was granted by the user = you want to impersonate. >>>>>>=20 >>>>>> OAuth responses are not signed or audience restricted to the = client(except confidential clients using the code flow). =20 >>>>>>=20 >>>>>> In cases where the code or token is passed over a back channel to = a server, faking the entire client is the easiest thing for the = attacker. >>>>>>=20 >>>>>> I don't consider these to be authorization attacks, rather = attacks on a client that is inappropariatly making unwarranted = assumptions about the presenter of the token. >>>>>>=20 >>>>>> John B. >>>>>> On 2012-06-29, at 3:29 PM, Phil Hunt wrote: >>>>>>=20 >>>>>>> We need more info on the inject method the researchers used = before we can account for it.=20 >>>>>>>=20 >>>>>>> Phil >>>>>>>=20 >>>>>>> On 2012-06-29, at 12:16, John Bradley wrote: >>>>>>>=20 >>>>>>>> The same thing can be done with code. >>>>>>>>=20 >>>>>>>> If the token endpoint checks the client_id before giving out = the access token then the attack on code can be prevented, as the token = endpoint won't return the access token. >>>>>>>>=20 >>>>>>>> The spec dosen't require authenticating public clients = currently so it is a slightly more difficult attack but possible. >>>>>>>>=20 >>>>>>>> Dick and I are suggesting closing the hole at the token = endpoint so that nether confidential nor public clients using the code = flow are susceptible to this substitution attack. >>>>>>>>=20 >>>>>>>> John B. >>>>>>>>=20 >>>>>>>> On 2012-06-29, at 2:53 PM, PhiIt helps with the code flow when = l Hunt wrote: >>>>>>>>=20 >>>>>>>>> I'm not seeing how client id helps if a proxy server is = somehow involved with inserting the bearer token as the researchers = suggested.=20 >>>>>>>>>=20 >>>>>>>>> Phil >>>>>>>>>=20 >>>>>>>>> On 2012-06-29, at 11:30, John Bradley = wrote: >>>>>>>>>=20 >>>>>>>>>> I think they only exploited the implicit flow. =20 >>>>>>>>>>=20 >>>>>>>>>> My point was that there is a way you could do the same thing = with code if it is a public client that is not authenticating to the = token endpoint. >>>>>>>>>>=20 >>>>>>>>>> In general making identity assumptions in the client based on = a code or access_token has risks that are out of scope for OAuth. >>>>>>>>>>=20 >>>>>>>>>> We do however want to provide good advice about specific = things that can leave systems insecure when using OAuth. >>>>>>>>>>=20 >>>>>>>>>> John B. >>>>>>>>>>=20 >>>>>>>>>> On 2012-06-29, at 2:22 PM, Phil Hunt wrote: >>>>>>>>>>=20 >>>>>>>>>>> I'm not clear whether the MS Security Researcher hack was = with the authorization code or the access token. If the latter, the = client_id is out of the picture isn't it? >>>>>>>>>>>=20 >>>>>>>>>>> Phil >>>>>>>>>>>=20 >>>>>>>>>>> @independentid >>>>>>>>>>> www.independentid.com >>>>>>>>>>> phil.hunt@oracle.com >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> On 2012-06-29, at 11:14 AM, Dick Hardt wrote: >>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> On Jun 29, 2012, at 11:06 AM, John Bradley wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>>> It is nice to know that I may occasionally be correct:) >>>>>>>>>>>>=20 >>>>>>>>>>>> You must be delighted when it happens! ;) >>>>>>>>>>>>=20 >>>>>>>>>>>>> While you may assume that it is reasonable for a client = with a code to make a request to the token endpoint including it's = client_id and the server to only give out the access token if the = client_id in the token request matches the one in the original = authorization request. However the spec specifically doesn't require = that. >>>>>>>>>>>>=20 >>>>>>>>>>>> I think that is an error in the spec and should be changed, = or text adding saying that the client_id SHOULD be checked. >>>>>>>>>>>>=20 >>>>>>>>>>>> -- Dick >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>=20 >>>>>>=20 >>>>>=20 >>>>=20 >>>=20 >>=20 --Apple-Mail=_9601C55E-0CF3-4873-8996-6F4EA59CD852 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw 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+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDYz MDE3NDYxNlowIwYJKoZIhvcNAQkEMRYEFGFXhaklW9Q3YTl6eiZe038vWq4YMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB AKaU/rrNFmPQv8aghL3/yjnDVTBPcUc1oLyRZ6rbpx9zbr2rw89jNfVv1kGxukJooO/nMx+LXYXY I5L40AO7FtAra0/z++PAhxs05pC8wLZ4+wpA3IkSat6UoudaBTeFAJrZOeveK3upV2bXIzR4/Ucd 1QFK/csBQDlFBnda3WgZKu+ZCN15/t6G8fNCrEN0xLgraLQ4Jijh2tBSr88Z6/CQWiVDtlAqn1rm AND1skGjNbum4SWYkIYSeaeogG9rWNLTlUyBU5l2nEpqK/Eytj+R/r38cAvgBGdcAVFSY9VZTLND VRD/p7+Zri4i7REyk9kNQdEaghJcb7eneLPVEzoAAAAAAAA= --Apple-Mail=_9601C55E-0CF3-4873-8996-6F4EA59CD852-- From hannes.tschofenig@gmx.net Sat Jun 30 12:25:40 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2A2521F85E6 for ; Sat, 30 Jun 2012 12:25:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.024, 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 dbQb-WLVyxBY for ; Sat, 30 Jun 2012 12:25:40 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id BB50821F85E1 for ; Sat, 30 Jun 2012 12:25:39 -0700 (PDT) Received: (qmail invoked by alias); 30 Jun 2012 19:25:39 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.110]) [88.115.216.191] by mail.gmx.net (mp002) with SMTP; 30 Jun 2012 21:25:39 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19cKaBYbhRczdY/2NLW5wYPd9ApRUGSkoPkp/YAWI K30zg0IBndw13t From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 30 Jun 2012 22:25:37 +0300 Message-Id: <24C3FE82-ADAD-4B89-A71B-CCAB3766C776@gmx.net> To: OAuth WG Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Subject: [OAUTH-WG] "Finishing up design team" X-BeenThere: oauth@ietf.org X-Mailman-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 Jun 2012 19:25:41 -0000 Hi all,=20 as explained in an earlier message, see = http://www.ietf.org/mail-archive/web/oauth/current/msg09443.html, we = are scheduling weekly conference calls. Derek and myself would like to chat with the draft editors; but you are = all welcome to join the calls as well.=20 Next Monday we are going to have our next call and here is the = conference bridge/Webex info: Date: 02.07.2012 Time: 1pm EDT Meeting Number: 704 682 193 Meeting Password: ietf ------------------------------------------------------- To start the online meeting ------------------------------------------------------- 1. Go to = https://nsn.webex.com/nsn/j.php?ED=3D215966682&UID=3D483363472&PW=3DNNTNmN= jAwODkx&RT=3DMiMzMA%3D%3D 2. If you are not logged in, log in to your account. ------------------------------------------------------- Teleconference information ------------------------------------------------------- ID=3D21522, PIN=3D1697 Bridge Info - choose from: +1 202 552 4781 (Washington DC) +1 650 963 5005 (Mountain View) +1 718 521 5027 (New York) +49 89 5159 43800 (Germany) Ciao Hannes & Derek
Hi Rui, my= fault about the Sophos link.  I hadn't read your message carefully en= ough, otherwise I would have realized that it was unrelated.  &nb= sp; - Francisco
 

From: rui wang <ruiwangwarm@gmail.com>
To: Francisco Corella <fcorella@= pomcor.com>
Cc: Nat= Sakimura <sakimura@gmail.com>; matake nov <nov@matake.jp>; Yuchen Zhou = <t-yuzhou@microsoft.com>; oauth <oauth@ietf.org>; Shuo Chen (MS= R) <shuochen@microsoft.com>
Subject: Re: [OAUTH-WG] Report an authentication= issue

=0A
Hi, Francis= co
=0A
 
=0A
Thank you for your reply. Here is our r= esponse for your questions.

=C3=98  the attack you describe can= be carried out against any app that uses the OAuth "implicit grant flow", = which Facebook calls "client-side authentication".
=0A=0A
 =0A
The main concern we raised here is not = about attacking client-side apps. We don=E2=80=99t think it is a meaningful= security consequence when a client-side application (e.g., a Win8 Metro ap= p, iPhone/iPad app) on the attacker=E2=80=99s tablet misidentifies the user= as the victim user. Therefore, you are right about =E2=80=9Cthis kind of a= ttack can be carried out against any app  using the OAuth =E2=80=98imp= licit grant flow=E2=80=99=E2=80=9D. In fact we won=E2=80=99t even call this= consequence as an attack.
=0A=0A
= The real problem is that in multiple occasions, we found that the server-si= de authentication logic takes an access token from the client app, then que= ries the user's profile data from the IdP in order to "authenticate" the us= er into the server. We have confirmed that the servers for Soluto Metro App= , Givit Metro App and EuroCup2012 Metro App make this mistake. These are ap= ps in the official Windows 8 App Store. We only sampled a small portion of = the available apps, but believe this is a vulnerability pattern due to a co= mmon misunderstanding of the usage of the access token.
=0A=0A<= div> 
=0A
=C3=98  I followed the link in your message to= the Sophos post, and from there the link to the article in
The Register= .  The article in The Register says that Facebook had
"fixed the vu= lnerability promptly".  How did they fix it?  The
=0Ainstructi= ons that Facebook provides for implementing "Client-side
authentication = without the JS SDK" at
htt= ps://developers.facebook.com/docs/authentication/client-side/#no-jssdk<= br>=0Astill allows the attack.
=0A
 
=0A
I am very sorry for the confusion. The link to Sophos has noth= ing to do with this problem. It is about another issue we reported last yea= r. I mentioned this because the email yesterday was sent to Facebook and th= e OAuth mailing list at the same time. I was trying to let the Facebook tea= m know we had previous communication before. I should have removed this par= t in the version sent to OAuth. Again, sorry for not removing this referenc= e. Please ignore it.
=0A=0A
 
=0A
Thanks,=0A
Rui
=0A
On Fri, Jun 1= 5, 2012 at 1:34 PM, Francisco Corella <fcorella@pomcor.com> wrote:
=0A=0A
=0A
Hi Nat a= nd Rui,

Rui, you say that the vulnerability that you found was due t= o a
"common misunderstanding among developers", but the attack you
= =0Adescribe can be carried out against any app that uses the OAuth
"impl= icit grant flow", which Facebook calls "client-side
authentication".&nbs= p; No misunderstanding seems necessary.  What
misunderstanding are = you referring to?  I followed the link in your
=0Amessage to the So= phos post, and from there the link to the article in
The Register. = The article in The Register says that Facebook had
"fixed the vulnerabi= lity promptly".  How did they fix it?  The
instructions that F= acebook provides for implementing "Client-side
=0Aauthentication without= the JS SDK" at
https://de= velopers.facebook.com/docs/authentication/client-side/#no-jssdk
=0As= till allows the attack.

Nat, I agree that the blog post by John Brad= ley that you link to
refers to the same vulnerability reported by Rui.&n= bsp; You say that some
apps have issued a patch to fix it.  Could y= ou explain what the fix
=0Awas?

Francisco
=0A

=0A=0A
=0A
=0A
=0A
=0A
=0A
This is a fairly well known (hopefully by now) issue. We,= at the OpenID Foundation, call it "access_token phishing" attack these day= s. See: http://www.thread-safe.com/2012/01/problem-with-oauth-for-auth= entication.html =0A

=0A
Nov Matake has actually built the= code on iPhone to verify the problem, and has notified bunch of parties ba= ck in February including Facebook and Apple. We have the code that actually= runs on a phone, and we have successfully logged in to bunch of apps, incl= uding very well known ones. They were all informed of the issue. Some immed= iately issued a patch to fix it while others have not.  
=0A=0A
=0A
The problem is that even if these apps gets fixed, the= problem does not go away. As long as the attacker has the vulnerable versi= on of the app, he still can impersonate the victim. To stop it, the server = side has to completely disable the older version, which means the service h= as to cut off many users pausing business problems. 
=0A=0A
<= br>
=0A
Nat

=0A
On Fri, Jun 15, 2012 at 2:18 AM, rui wa= ng <ruiwangw= arm@gmail.com> wrote:
=0A
=0A
Dear Fac= ebook Security Team and OAuth Standard group,
=0A
We are a researc= h team in Microsoft Research. In January, 2011, we reported a vulnerability= in Facebook Connect which allowed everyone to sign into Facebook-secured r= elying parties without password. It was promptly fixed after reporting. (http://nakedsecuri= ty.sophos.com/2011/02/02/facebook-flaw-websites-steal-personal-data/)=0A=0A
Recently, we found a common misunderstanding among developer= s of mobile/metro apps when using OAuth (including Facebook=E2=80=99s OAuth= ) for authentication. The vulnerability resulted from this misunderstanding= also allows an attacker to log into a victim user's account without passwo= rd.
=0A=0A
Let's take Soluto's metro app as an example to describe= the problem. The app supports Facebook Login. As an attacker, we can write= a regular Facebook app. Once the victim user allows our app to access her = Facebook data, we receive an access_token from the traffic. Then, on our ow= n machine (i.e., the "attacker" machine), we run the metro app of Soluto, a= nd use a HTTP proxy to insert the victim's access_token into the traffic of= Facebook login. Through this way, we are able to log into the victim's Sol= uto account from our machine. Other than Soluto, we also have confirmed the= same issue on another Windows 8 metro-app Givit.
=0A=0A
The Faceb= ook SDK for Android apps (https://develo= pers.facebook.com/docs/mobile/android/build/#sdk) seems to have the pos= sibility to mislead developers too. At least, the issue that we found is no= t clearly mentioned. In the SDK, we ran the sample code called "Hackbook" u= sing Android Emulator (imagine it is an attacker device). Note that we have= already received the access token of the victim user from our regular Face= book app. We then inject the token to the traffic of Hackbook. Through this= way, Hackbook app on our own machine recognizes us as the victim. Note tha= t this is not a convincing security exploit yet, because this sample code d= oes not include the server-side code. However, given that we have seen real= server-side code having this problem, such as Soluto, Givit and others, we= do believe that the sample code can mislead mobile/metro developers. We also suspect that this may be a general issue of many OAuth= implementations on mobile platforms, so we send this message to OAuth Stan= dard group as well.
=0A=0A
We have contacted the vendors of the tw= o vulnerable metro-apps, Soluto and Gavit.
=0A
Please kindly give = us an ack when you receive this message. If you want to know more details, = please let us know.
=0A
Best Regards,
Yuchen Zhou, Rui Wang, an= d Shuo Chen

_______________________________________________
OAu= th mailing list
OAuth@ietf.org
=0Ahttps://www.ietf.org/mailman/listinfo/oauth



=0A

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


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


=0A